Hue Outdoor Motion Sending Messages every 3 or so seconds

🛎️ Get Help
, ,
1

I recently installed a new Hue Outdoor Motion Sensor and I am noticing some odd behavior. I noticed that the sensor was sending out Zigbee messages about every 3 seconds or so.. Otherwise the sensor is working fine, it's reporting motion, temperature, and lux all fine. It's just very chatty and I can't imagine that's going to be good for it's battery life.. I have two other Hue outdoor sensors, that I have had for years, which are not "pinging" like this.. Wondering if anyone know what's going on, and how to fix...

I turned on debug reporting to capture some details around the message(s) it's sending.. Here are a couple of examples..

dev:1652020-12-14 07:07:43.598 am [debug]
descMap:[raw:catchall: 0000 8004 00 00 0040 00 04EE 00 00 0000 00 00 C500EE041602040107010006000001000300060400040204011900, profileId:0000, clusterId:8004, clusterInt:32772, sourceEndpoint:00, destinationEndpoint:00, options:0040, messageType:00, dni:04EE, isClusterSpecific:false, isManufacturerSpecific:false, manufacturerId:0000, command:00, direction:00, data:[C5, 00, EE, 04, 16, 02, 04, 01, 07, 01, 00, 06, 00, 00, 01, 00, 03, 00, 06, 04, 00, 04, 02, 04, 01, 19, 00]]

dev:1652020-12-14 07:07:40.499 am [debug]
descMap:[raw:catchall: 0000 8004 00 00 0040 00 04EE 00 00 0000 00 00 C400EE041602040107010006000001000300060400040204011900, profileId:0000, clusterId:8004, clusterInt:32772, sourceEndpoint:00, destinationEndpoint:00, options:0040, messageType:00, dni:04EE, isClusterSpecific:false, isManufacturerSpecific:false, manufacturerId:0000, command:00, direction:00, data:[C4, 00, EE, 04, 16, 02, 04, 01, 07, 01, 00, 06, 00, 00, 01, 00, 03, 00, 06, 04, 00, 04, 02, 04, 01, 19, 00]]

dev:1652020-12-14 07:07:37.421 am [debug]
descMap:[raw:catchall: 0000 8004 00 00 0040 00 04EE 00 00 0000 00 00 C300EE041602040107010006000001000300060400040204011900, profileId:0000, clusterId:8004, clusterInt:32772, sourceEndpoint:00, destinationEndpoint:00, options:0040, messageType:00, dni:04EE, isClusterSpecific:false, isManufacturerSpecific:false, manufacturerId:0000, command:00, direction:00, data:[C3, 00, EE, 04, 16, 02, 04, 01, 07, 01, 00, 06, 00, 00, 01, 00, 03, 00, 06, 04, 00, 04, 02, 04, 01, 19, 00]]

dev:1652020-12-14 07:07:34.340 am [debug]
descMap:[raw:catchall: 0000 8004 00 00 0040 00 04EE 00 00 0000 00 00 C200EE041602040107010006000001000300060400040204011900, profileId:0000, clusterId:8004, clusterInt:32772, sourceEndpoint:00, destinationEndpoint:00, options:0040, messageType:00, dni:04EE, isClusterSpecific:false, isManufacturerSpecific:false, manufacturerId:0000, command:00, direction:00, data:[C2, 00, EE, 04, 16, 02, 04, 01, 07, 01, 00, 06, 00, 00, 01, 00, 03, 00, 06, 04, 00, 04, 02, 04, 01, 19, 00]]

I tired searching for what cluster 8004 means, but didn't find anything useful. Any help would be appreciated.

2

Have you tried resetting and including the device again?
If that doesn't fix it, bring it inside, then include it again, if the problem goes away then your zigbee mesh is weak at the exterior location.

2 Likes
3

OK, Clearly I have not been getting enough sleep as it didn't even occur to me to do basic troubleshooting 101, aka reset/rejoin.. That fixed it, thanks!

Out of curiosity do you know what is cluster 0x8004? Is that part of the paring/discovery process?

Thanks Again..

4

Yes it is, it's one of two clusters (0x8004, 0x8005) reported back when the hub acknowledges that it sees the newly discovered device, it is actually the footprint of the device so that the hub can match it to a device driver.

2 Likes
5

This topic was automatically closed 365 days after the last reply. New replies are no longer allowed.