Hue Motion sensors - motion staying active

📢 Feedback
1

I have 4 Hue motion sensors connected directly to HE. Generally they are pretty good, but a couple of times over the last week or so 2 off them have "stuck" in active mode. It takes either a refresh from the device page or another motion trigger to clear this. I don't know if it the devices themselves are not sending the inactive trigger correctly or HE is missing it somehow. This is the event list for one of them. It correctly triggered active at 1.49pm, then we were out all afternoon and I noticed the light in the bathroom was still on when we got back. I then tripped it at 5.30pm and that finally sent inactive once it cleared. I would have expected the sensor to report back that it was inactive every time it "checked in" with HE, but this doesn't seem to be the case as there are many updates of lux in between the motion status updates.

Has anyone else experienced this or have any thoughts/suggestions ? I'm on 2.0.6.112

motion inactive Bathroom Sensor is inactive DEVICE 2019-03-05 05:30:41.792 PM GMT
illuminance 44 Lux Bathroom Sensor illuminance is 44 Lux DEVICE 2019-03-05 05:30:32.367 PM GMT
illuminance 43 Lux Bathroom Sensor illuminance is 43 Lux DEVICE 2019-03-05 05:30:27.333 PM GMT
illuminance 44 Lux Bathroom Sensor illuminance is 44 Lux DEVICE 2019-03-05 05:24:26.309 PM GMT
illuminance 45 Lux Bathroom Sensor illuminance is 45 Lux DEVICE 2019-03-05 05:14:27.182 PM GMT
illuminance 46 Lux Bathroom Sensor illuminance is 46 Lux DEVICE 2019-03-05 05:09:27.592 PM GMT
illuminance 47 Lux Bathroom Sensor illuminance is 47 Lux DEVICE 2019-03-05 04:59:28.421 PM GMT
illuminance 48 Lux Bathroom Sensor illuminance is 48 Lux DEVICE 2019-03-05 04:54:28.815 PM GMT
illuminance 47 Lux Bathroom Sensor illuminance is 47 Lux DEVICE 2019-03-05 04:49:29.214 PM GMT
illuminance 50 Lux Bathroom Sensor illuminance is 50 Lux DEVICE 2019-03-05 04:44:29.579 PM GMT
illuminance 51 Lux Bathroom Sensor illuminance is 51 Lux DEVICE 2019-03-05 04:39:29.992 PM GMT
illuminance 48 Lux Bathroom Sensor illuminance is 48 Lux DEVICE 2019-03-05 04:34:30.402 PM GMT
illuminance 51 Lux Bathroom Sensor illuminance is 51 Lux DEVICE 2019-03-05 04:29:30.805 PM GMT
illuminance 50 Lux Bathroom Sensor illuminance is 50 Lux DEVICE 2019-03-05 04:19:31.644 PM GMT
illuminance 49 Lux Bathroom Sensor illuminance is 49 Lux DEVICE 2019-03-05 04:09:32.385 PM GMT
illuminance 56 Lux Bathroom Sensor illuminance is 56 Lux DEVICE 2019-03-05 04:04:32.774 PM GMT
illuminance 55 Lux Bathroom Sensor illuminance is 55 Lux DEVICE 2019-03-05 03:59:33.164 PM GMT
illuminance 54 Lux Bathroom Sensor illuminance is 54 Lux DEVICE 2019-03-05 03:49:33.927 PM GMT
illuminance 51 Lux Bathroom Sensor illuminance is 51 Lux DEVICE 2019-03-05 03:44:34.337 PM GMT
illuminance 57 Lux Bathroom Sensor illuminance is 57 Lux DEVICE 2019-03-05 03:39:34.706 PM GMT
illuminance 58 Lux Bathroom Sensor illuminance is 58 Lux DEVICE 2019-03-05 03:29:35.489 PM GMT
illuminance 53 Lux Bathroom Sensor illuminance is 53 Lux DEVICE 2019-03-05 03:24:35.867 PM GMT
illuminance 48 Lux Bathroom Sensor illuminance is 48 Lux DEVICE 2019-03-05 03:19:36.363 PM GMT
illuminance 51 Lux Bathroom Sensor illuminance is 51 Lux DEVICE 2019-03-05 03:14:36.775 PM GMT
illuminance 52 Lux Bathroom Sensor illuminance is 52 Lux DEVICE 2019-03-05 03:09:37.140 PM GMT
illuminance 57 Lux Bathroom Sensor illuminance is 57 Lux DEVICE 2019-03-05 03:04:37.536 PM GMT
illuminance 56 Lux Bathroom Sensor illuminance is 56 Lux DEVICE 2019-03-05 02:59:37.924 PM GMT
illuminance 54 Lux Bathroom Sensor illuminance is 54 Lux DEVICE 2019-03-05 02:54:38.288 PM GMT
illuminance 58 Lux Bathroom Sensor illuminance is 58 Lux DEVICE 2019-03-05 02:49:38.679 PM GMT
illuminance 62 Lux Bathroom Sensor illuminance is 62 Lux DEVICE 2019-03-05 02:44:39.079 PM GMT
illuminance 61 Lux Bathroom Sensor illuminance is 61 Lux DEVICE 2019-03-05 02:39:39.449 PM GMT
illuminance 74 Lux Bathroom Sensor illuminance is 74 Lux DEVICE 2019-03-05 02:34:39.865 PM GMT
illuminance 67 Lux Bathroom Sensor illuminance is 67 Lux DEVICE 2019-03-05 02:29:40.277 PM GMT
illuminance 65 Lux Bathroom Sensor illuminance is 65 Lux DEVICE 2019-03-05 02:14:41.512 PM GMT
illuminance 70 Lux Bathroom Sensor illuminance is 70 Lux DEVICE 2019-03-05 02:09:41.925 PM GMT
illuminance 63 Lux Bathroom Sensor illuminance is 63 Lux DEVICE 2019-03-05 02:04:42.298 PM GMT
illuminance 66 Lux Bathroom Sensor illuminance is 66 Lux DEVICE 2019-03-05 01:59:42.765 PM GMT
illuminance 76 Lux Bathroom Sensor illuminance is 76 Lux DEVICE 2019-03-05 01:54:43.135 PM GMT
illuminance 71 Lux Bathroom Sensor illuminance is 71 Lux DEVICE 2019-03-05 01:49:35.662 PM GMT
illuminance 70 Lux Bathroom Sensor illuminance is 70 Lux DEVICE 2019-03-05 01:49:30.633 PM GMT
motion active Bathroom Sensor is active DEVICE 2019-03-05 01:49:01.437 PM GMT
motion inactive Bathroom Sensor is inactive DEVICE 2019-03-05 01:49:00.492 PM GMT
illuminance 71 Lux Bathroom Sensor illuminance is 71 Lux DEVICE 2019-03-05 01:48:51.016 PM GMT
motion active Bathroom Sensor is active DEVICE 2019-03-05 01:48:45.958 PM GMT
motion inactive Bathroom Sensor is inactive DEVICE 2019-03-05 01:48:32.509 PM GMT
2

I have one of these sensors and it works all the time.
The only time there is an issue is after a reboot/power on.
After that lux does not report for anything up to 6 hours. As soon as motion is detected everything is hunky dory again.
I'm using the stoch device Type.

3

Mine have been OK mostly - it's only in the last week or so I've had 2 different ones stay active.

I should have said, I'm using the in-built driver.

4

This started after the update to the stock Hue Motion driver. I have multiple of these sensors and there was no issues before 2.0.5 which included a fix to the stock driver. The fix was to resolve the issue that when pairing a Hue motion with the stock driver the lux/motion would not refresh properly. Before this update I had to switch to a custom driver and use the "configure" option and then switch back to the stock driver. Most of the time they seem to work okay, but they do get "stuck" sometimes as you stated.

If you do not experience the issue then maybe you never ran a configure/refresh with the stock driver on your Hue motions after the 2.0.5 update.

5

Is this necessary when a new update comes out?

6

Tagging @mike.maxwell as I couldn't find any reference to this being reported previously.

7

I always configure/refresh the device if I change device drivers. Since the Hue motions were originally "configured" under a custom driver after I switched back to the stock I ran it again.

I do this in case there have been any parameter changes between drivers, to ensure best compatibility.

8

Make a note of the 16-bit address for each of the motion sensors and the next time you notice that HE has missed an event, check the 16-bit address.

If it's changed then the chances are that it's left and rejoined the ZigBee network and during the time that it did this (could be minutes or could be for several hours) HE won't receive events from it.

I put my findings on this here and @chuck.schwer said they'd look into it as it may well affect other Hue devices too, for example there are various reports on the forum that the Hue Dimmer suffers from similar symptoms.

9

Good suggestion and actually I happen to have a print from a couple of days back of my Zigbee devices address list (as you do!) so I checked on that and that sensor still has the same address so it isn't the issue in this case. It would have expected it to have a good connection as it's only about 3 metres from the hub, but I've just looked at the Zigbee logs for it and they do show a strange variance of lastHopRssi values between -59 and -91 and the lastHopLqi drops below 255 on a couple of the lines. I don't know what it means but the lines where destinationEndpoint is 255 or 0 all seem to have a worse signal quality than those where it's 1:

Bathroom Sensor2019-03-05 21:29:10.835 profileId:0x104, clusterId:0x406, sourceEndpoint:2, destinationEndpoint:255 , groupId:0, lastHopLqi:243, lastHopRssi:-91
Bathroom Sensor2019-03-05 21:29:09.324 profileId:0x104, clusterId:0x400, sourceEndpoint:2, destinationEndpoint:1 , groupId:0, lastHopLqi:255, lastHopRssi:-60
Bathroom Sensor2019-03-05 21:29:09.219 profileId:0x104, clusterId:0x406, sourceEndpoint:2, destinationEndpoint:1 , groupId:0, lastHopLqi:255, lastHopRssi:-59
Bathroom Sensor2019-03-05 21:29:08.410 profileId:0x0, clusterId:0x13, sourceEndpoint:0, destinationEndpoint:0 , groupId:0, lastHopLqi:239, lastHopRssi:-91
Bathroom Sensor2019-03-05 21:29:05.088 profileId:0x104, clusterId:0x400, sourceEndpoint:2, destinationEndpoint:1 , groupId:0, lastHopLqi:255, lastHopRssi:-59
Bathroom Sensor2019-03-05 21:29:00.057 profileId:0x104, clusterId:0x400, sourceEndpoint:2, destinationEndpoint:1 , groupId:0, lastHopLqi:255, lastHopRssi:-59
Bathroom Sensor2019-03-05 21:28:56.522 profileId:0x104, clusterId:0x406, sourceEndpoint:2, destinationEndpoint:255 , groupId:0, lastHopLqi:236, lastHopRssi:-91
Bathroom Sensor2019-03-05 21:28:55.014 profileId:0x104, clusterId:0x406, sourceEndpoint:2, destinationEndpoint:1 , groupId:0, lastHopLqi:255, lastHopRssi:-60

10

The 16-bit address change would have been a smoking gun, but it doesn't necessarily mean that it didn't leave and rejoin. From what I've seen an address change only occurs if it moves parent (i.e. changes router it's connected to), so in your case it may have stayed on the Hub and received the same address.

You can see from your ZigBee logs that you have the same issue I was reporting in the other thread, that the initial message is a unicast one (destinationEndpoint:1) but there's a repeat message which is a broadcast (destinationEndpoint:255).

It's this scenario that I suspect causes the problem as it's an indication that the device didn't get a response to the first unicast message, so it sends a broadcast. Eventually over a period of time it appears that it determines it's not getting a reply and so leaves the network and rejoins.

You would need a sniffer to determine that is definitely happening though as I'm not sure you can see it from the ZigBee logs - although you may be able to tell if you left the log open indefinitely and see big gaps in the timestamps. I don't recall how the built in device driver configures them to report, but if it's every 10 minutes for temperature & light level then you should see log entries every 10 minutes without fail.

11

Looking at the logs in my first post above there are some irregular time lapses. Most are at 5 minute intervals but there are some at 10 and some at 15 too. Does it only report if something has changed or should it report every 5 minutes regardless?

12

My understanding is that when you configure reporting on a ZigBee device you set it with Min / Max / Change values - so what that means is it will report on "Change" and will report at most on "Min" and at least on "Max".

So if that's set like 60 / 300 / 20 for a temperature sensor then that means it will report each time the temperature changes by .2 but only after 60 seconds have passed since the last report, but then every 300 seconds regardless.

So if you see 5 minute regular reports from cluster 0402 (temperature) then you can assume that it's set to 5 minutes and therefore that cluster report should appear in the logs at least every 5 minutes.

It may appear sooner if the temperature changes, but at most the gap between those cluster reports should be 5 minutes. So if that cluster misses a chunk of reports then you may well be seeing the device leave and rejoin.

(in your case this is circumstantial evidence as you'd really need to use a sniffer to confirm)

13

I've had another Hue sensor "lock" in active mode today. That's now 3 out of my 4 that have done this in the last few days. It's making motion lighting a real pain at the moment. @mike.maxwell @bravenel @patrick any thoughts?

14

Any updates on this or a possible fix in the next update? @mike.maxwell @bravenel

15

which specific issue?

16

The one with the Hue motion sensors staying active.

17

If this issue is what we think it is, that fix will be in 2.0.8, it's a rather fundamental change in the way that we reply to certain messages from devices, we were half way through 2.0.7 testing when we started working on this, so basically too late to include in 2.0.7.

18

Bummer cause it really causes issues with my motion lighting setup, lights end up staying on because the sensors do not reset back to "not active". Its not all the time but it does happen. I am glad though that it will be fixed at least in 2.0.8. Thanks.

19

well if we jacked these changes into 2.0.7 and broke all sorts of things, then you'd be more than bummed right?

20

No, and I understand it was just that the 2.0.6 update is what broke it, it was working before. I had numinous motion lighting apps that are used many times a day with these sensors so it made ML a pain to deal with lately. But yes its best to not push updates with out proper testing.

Edit: I think its more of that I get spoiled that lights just are always on when I need them, no need to touch switches.