Yes, I recall that they pulled out most of the ZHA code from Home Assistant core and moved it to its own library within the last year and made a ton of changes during that transition.
Anyway, I’ve opened a few PRs to hopefully get all of this added to ZHA, but things seem to be moving slowly since the open Inovelli PR isn’t making its way through. For reference, here’s what I opened:
I have 13 blue switches installed for a while now. Using habitat. There’s been two separate instances where a switch gets stuck in occupied state, regardless of activity. Air gapping the switch is how I’ve fixed it. I see one other user (@steveflee ) report a similar behavior in the firmware thread. Any ideas?
I’m on HA latest update 2026.3.2,
After the most recent HA update which seems to have included an update to ZHA, my mmwave switch lost the capacity to sense occupancy.
It’s been working really well before that and ever since the update, I can’t get the occupancy to change, which is quite a bummer.
Is my switch broken or is it firmware related?
I’m using ZHA
I was about to make a full post about one of mine (5 total) doing maybe the same thing, and for me it started on March 8th (I don’t think that corresponds to an update?). I would think that if it was directly tied to a HA change it would have affected all five of mine though.
When you say the occupancy stops working do you mean it doesn’t control the load anymore, it doesn’t show occupied in the hub, or both? Also, does pulling the air gap and pushing it back in resolve the issue? I have about 15 blue and 3 red in my house and I have not experienced this issue at all on the blue. I am using z2m though. The red I think there is a memory exhaustion issue that can occur after several weeks that I am looking into.
The occupancy doesn’t show as occupied on the hub and it doesn’t control the load (since it doesn’t detect occupancy). Although I can manually control the switch.
I also tried to factory reset and to reset the mmwave sensor to no avail.
I’m starting to wonder if my mmwave sensor died
I have had to re-pair some of mine to get them working again.
Yep, this is the exact same behaviour that I’m seeing as well, it’s just weird to me because it’s only on one switch out of my five blue mmwave. If it was a function of the zigbee controller I’d expect the same behaviour across all five.
My switch from time to time seems to lose occupancy. I can be sitting in the room and my lights will just go out and it’ll show cleared. I can wave my hand in the air wildly and it still won’t find me. So I’ll pull out my phone and pull up home assistant and have it refresh the occupancy. I’ve got 4 other switches I’m just sitting on for now until I can figure out what is going on with this one. Not sure if I need to update stay life even more than I already have it or why it seems to lose the ability to detect in general so any thoughts would be appreciated.
I’ve done another factory reset and also pulled the air gap tab for about 6 hours since this last reply and one of my switches still can’t detect any motion at all. Do I need to email this one or something?
Tried the same and also installed the custom quirk which I hadn’t before, still no presence detected.
As others have mentioned here (and in the firmware update thread), I can also report that I am experiencing the same bug with stay area width/x-coordinates unexpectedly sign-inverting. I am confident that this is a firmware bug.
I enabled debug logging in Z2M, here’s the pertinent parts of the transaction.
Set command:
{“level”:“debug”,“message”:“z2m:mqtt: Received MQTT message on ‘zigbee2mqtt/Guest Bedroom Lights/set’ with data ‘{“mmwave_stay_areas”: {“area1”: {“depth_max”: 104, “depth_min”: 0, “height_max”: 128, “height_min”: -116, “width_max”: 0, “width_min”: -208}}}’”}
Transformed into a converter command:
{“level”:“debug”,“message”:“zh:controller:endpoint: ZCL command 0x0c2a6ffffef1b051/1 manuSpecificInovelliMMWave.setStayArea({“areaId”:0,“xMin”:-208,“xMax”:0,“yMin”:0,“yMax”:104,“zMin”:-116,“zMax”:128}, {“timeout”:10000,“disableResponse”:true,“disableRecovery”:false,“disableDefaultResponse”:true,“direction”:0,“reservedBits”:0,“manufacturerCode”:4655,“writeUndiv”:false})”}
I unfortunately don’t see the raw bytes of the transmitted payload in the message, but I set the exact same coordinates on a detection area and they worked successfully - so given that the detection and stay area implementations share the same code in zigbee-herdsman-converters (thanks @rohan!), I’m confident that the data was serialized correctly.
Here’s where the new parameters come back from the device:
{“level”:“debug”,“message”:“zh:ember:ezsp: ezspIncomingMessageHandler: type=UNICAST apsFrame={“profileId”:260,“clusterId”:64562,“sourceEndpoint”:1,“destinationEndpoint”:1,“options”:64,“groupId”:0,“sequence”:69} packetInfo:{“senderShortId”:19383,“senderLongId”:“0x0000000000000000”,“bindingIndex”:255,“addressIndex”:255,“lastHopLqi”:144,“lastHopRssi”:-75,“lastHopTimestamp”:191241502} messageContents=1d2f122204040000d000000068008cff80000000000000000000a8fd58020000000000000000a8fd58020000000000000000a8fd5802”}
In the payload, we can see d000 - the 16-bit hexadecimal representation of 208 (instead of -208)
The parsing code also extracts this value as 208, and it is also in the wrong coordinate (it’s been swapped with xmin):
{“level”:“debug”,“message”:“zh:controller: Received payload: clusterID=64562, address=19383, groupID=0, endpoint=1, destinationEndpoint=1, wasBroadcast=false, linkQuality=144, frame={“header”:{“frameControl”:{“frameType”:1,“manufacturerSpecific”:true,“direction”:1,“disableDefaultResponse”:true,“reservedBits”:0},“manufacturerCode”:4655,“transactionSequenceNumber”:34,“commandIdentifier”:4},“payload”:{“count”:4,“xMin1”:0,“xMax1”:208,“yMin1”:0,“yMax1”:104,“zMin1”:-116,“zMax1”:128,“xMin2”:0,“xMax2”:0,“yMin2”:0,“yMax2”:0,“zMin2”:-600,“zMax2”:600,“xMin3”:0,“xMax3”:0,“yMin3”:0,“yMax3”:0,“zMin3”:-600,“zMax3”:600,“xMin4”:0,“xMax4”:0,“yMin4”:0,“yMax4”:0,“zMin4”:-600,“zMax4”:600},“command”:{“name”:“reportStayArea”,“ID”:4,“parameters”:[{“name”:“count”,“type”:32},{“name”:“xMin1”,“type”:41},{“name”:“xMax1”,“type”:41},{“name”:“yMin1”,“type”:41},{“name”:“yMax1”,“type”:41},{“name”:“zMin1”,“type”:41},{“name”:“zMax1”,“type”:41},{“name”:“xMin2”,“type”:41},{“name”:“xMax2”,“type”:41},{“name”:“yMin2”,“type”:41},{“name”:“yMax2”,“type”:41},{“name”:“zMin2”,“type”:41},{“name”:“zMax2”,“type”:41},{“name”:“xMin3”,“type”:41},{“name”:“xMax3”,“type”:41},{“name”:“yMin3”,“type”:41},{“name”:“yMax3”,“type”:41},{“name”:“zMin3”,“type”:41},{“name”:“zMax3”,“type”:41},{“name”:“xMin4”,“type”:41},{“name”:“xMax4”,“type”:41},{“name”:“yMin4”,“type”:41},{“name”:“yMax4”,“type”:41},{“name”:“zMin4”,“type”:41},{“name”:“zMax4”,“type”:41}]}}”}
{“level”:“debug”,“message”:“z2m: Received Zigbee message from ‘Guest Bedroom Lights’, type ‘commandReportStayArea’, cluster ‘manuSpecificInovelliMMWave’, data ‘{“count”:4,“xMax1”:208,“xMax2”:0,“xMax3”:0,“xMax4”:0,“xMin1”:0,“xMin2”:0,“xMin3”:0,“xMin4”:0,“yMax1”:104,“yMax2”:0,“yMax3”:0,“yMax4”:0,“yMin1”:0,“yMin2”:0,“yMin3”:0,“yMin4”:0,“zMax1”:128,“zMax2”:600,“zMax3”:600,“zMax4”:600,“zMin1”:-116,“zMin2”:-600,“zMin3”:-600,“zMin4”:-600}’ from endpoint 1 with groupID 0”}
I was able to work around this bug by sign-inverting the x coordinates used for stay areas. However, this leaves me a bit worried about whether these coordinates are being correctly transmitted to the mmWave control chip.
Hey idk if this will work for you, but on a whim I tried re-interviewing the problem switch (not a full factory reset, ZHA calls it “reconfigure”) and that seems to have gotten me working again. I’m back to having functional occupancy sensing.