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.
Was included with 2026.8
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?
If you mean still seeing the custom quirk even after removal on the switches you need to remove and add them again to zha.
Remove the switch from ZHA and add it again. ZHA caches the quirks so they will remain until you do that.
Ah…gotcha. I’ll have to give that a shot. Thanks.
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
I did some AI work and wound up with this command. It does not appear to work though and the light flashes green and not the expected orange:
action: zha.issue_zigbee_cluster_command
data:
ieee: “”
endpoint_id: 1
cluster_id: 64562
cluster_type: in
command: 0
command_type: server
params:
control_id: 1