Just updated Home Assistant and removed the custom quirk. I was hoping to finally be able to set the interference area and block out my ceiling fans but it looks like two commands share the same id and I am unable to send the command because when I select “set_interference_area” it switches back to “report_target_info”
What version of HA did you upgrade to. I keep meaning to try removing the custom quirk to see if all the entities will show when using ZHA, and it would be nice to know that’s finally fixed.
After I updated to 2026.08 (still with quirk), I had lots of entities that are “no longer being provided by zha integration”. I might have to go through and delete each of those–even after removing the custom quirk, they are still there. Right now, it is just annoying, but maybe that is what is causing your issue, too?
So, the issue I described is actually a Home Assistant bug according to ChatGPT.
The actual Home Assistant bug
The ZHA backend handles this correctly. Its websocket API explicitly returns the client and server commands separately and attaches a type of “client” or “server” to each returned command. GitHub
But the current frontend then does this conceptually:
value: String(entry.id)
So both of these become exactly the same selector value:
report_target_info → “1”
set_interference_area → “1”
Worse, when determining which command was selected, it searches only by ID:
_commands.find(command => command.id === selectedCommandId)
It does not include command.type in the lookup. GitHub
That explains your symptom exactly.
The frontend sorts commands alphabetically first. Thus report_target_info occurs before set_interference_area. When the selected ID is 1, .find() returns the first ID 1 — report_target_info. GitHub
It also means this isn’t limited to set_interference_area. The same collision should affect:
Desired server command ID Colliding client command
mmwave_control_command 0x00 anyone_in_reporting_area
set_interference_area 0x01 report_target_info
set_detection_area 0x02 report_interference_area
set_stay_area 0x03 report_detection_area
The definitions themselves are therefore fine; I would file this against home-assistant/frontend, not zha-device-handlers
Just wanted to chime in, I’m in the same boat. The first two commands in the drop-down conflict with the same ID. I’ve got a mmwave in my bedroom that’s basically unusable from a presence POV as a result
I opened a bug against core, we’ll see where that leads. Hoping they may be able to fix whatever they changed since 2026.8.0 had a lot of ZHA UI tweaks
FWIW (I know this isn’t helpful to your immediate problem) - but I’ll recommend Zigbee2MQTT instead of ZHA again for situations like this.
We (Inovelli & contributors) are able to make much faster changes to Zigbee2MQTT and the platform doesn’t change out from under us anywhere near as quickly. We’ve also done a lot of work over the past year to expose all of the advanced functionality of the VZM32 using Zigbee2MQTT.
For other reasons, it’s helpful to not have your Zigbee mesh restart when you restart Home Assistant.
Good to know! I thought ZHA was the default when I set up my mesh so never bothered to go with Z2M. The 2026.8.0 update brought some major UI changes to Inovelli devices, but not all good unfortunately.
Most of the parameters are now actually exposed in the main config page, but inexplicably with sliders
The practical effect of the change is that I have to be extremely careful on mobile not to touch anything on this screen. Already had to factory reset once as a result of an inadvertent change.
Yeah, I won’t say the UI is perfect with Z2M either, but at least all of the advanced commands are exposed there and you can relatively easily configure multiple groups, etc.
