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.
I think I’ve encountered the same issue as jetpacktuxedo above but on Hubitat, and I can’t figure out where the problem is. On Hubitat, latest switch firmware (1.01) and switch driver (2026-05-16). The only two switches I’ve installed so far are both exhibiting this behavior, which sounds like an issue somewhere on the hub, but it’s not saying anything is wrong. It was working one night and then not the next morning.
Observed issue:
motion detected/stopped is not triggering scenes. Operating the buttons on the switch works as normal, only the motion triggering has stopped.
Observation details:
During the time motion was triggering the scenes OK, logging had trace events for “OCCUPANCY_SENSING_CLUSTER” (visible when trace logging enabled) and motion events were appearing in the device Events list. Both those are no longer appearing. I can see in the logs “ReportingArea” still being sent, so the mmwave sensor seems to be working.
Troubleshooting so far:
Nothing has restored motion triggering. I will try more destructive troubleshooting (configuring with defaults and/or factory reset) tomorrow when I have more time, but in the mean time does anyone have any ideas?
Additional troubleshooting and findings below. I have two switches and are referring to them by number to keep the story straight. I have only performed troubleshooting steps on Switch 1 (everything listed in the last post).
On the Switch 1 device Commands page, Configure(Defualt) did not result in any change of the motion reporting issue.
After factory resetting Switch 1 and re-pairing it (without deleting the device in Hubitat), it re-connected and operated OK but with no change to the motion reporting issue. Re-applying settings has also had no effect.
BUT, Switch 2 immediately started reporting motion after factory resetting Switch 1.
After poking around the logs trying to figure out where these reports are getting dropped, I found the Zigbee log (Settings > Zigbee > View logs), which looks like is showing the reports the hub is receiving. I can see clusterId FC32 (mmWave sensor) from both switches the entire time, and now clusterId 0406 (occupancy sensor) from Switch 2 only since factory resetting Switch 1 (before resetting Switch 1 there are no 0406 log items from either switch).
What could be going wrong here? It seems the switch itself is not sending the reports. I can see plenty of other reports for lux, power/energy, button presses, internal temp, etc.
Was finally able to flip the circuit for Switch 1 off and on, and Switch 1 is now reporting motion again. Still no idea what happened there.
Which raises another question: Is there a way to reboot the switch without power cycling it? The air gap seems to only cut the load.
The air gap will reboot the switch. If it is pulled out properly, you should note that the LED bar is no longer illuminated. After you push the air gap back in, you should see the LED bar cycle through blue and yellow during the boot process.
I finally installed one of the mmWave switches I ordered and I’m fairly happy with it. It reliably detects when I enter, stay, and leave my office, and the lux feature is nice too.
It’s not as important, but I’ve noticed that the exact location seems to change all the the time. In the below screen D2 is where I captured that I usually sit and D3 is where my wife usually sits. It was consistently that yesterday. But then twice today the locations were completely different. There were a couple minor (fun) automations I was thinking of creating based on detecting who exactly was sitting in the office, but I’m having trouble getting locations to be consistent.
The switch does face a big window, which could be part of it, but I’m wondering generally how big a variation is normal, or if it goes through any sort of “calibration” experience. I’m OK if I can’t ever get this to work as the overall experience works great for me, but would be great if I could use this functionality this way.
I have an automation that turns on the bathroom fan if you sit on the toilet for 5 minutes, but lights are on for anywhere in the bathroom. It seems reliable enough for me.
Yeah, I have different lights that come on based on presence in different zones of my kitchen and they also are extremely reliable.
