Hue motion sensor illuminance reporting expectations

Indoor

More of what the driver says is supposed to happen. According to Mike it should update on a change in level but this is not happening

log after hitting save (Dev:15)

Ive tried to piece the 2 logs together for the light and sensor
dev:2592020-12-17 08:53:04.149 am infoStairs Lower Light switch is off
dev:152020-12-17 08:54:03.250 am infoStairs Lower Motion illuminance is 4 Lux
dev:152020-12-17 08:54:03.217 am infoStairs Lower Motion is active
dev:2592020-12-17 08:53:04.149 am infoStairs Lower Light switch is off
dev:2592020-12-17 08:51:20.092 am infoStairs Lower Light level is 90 %
dev:152020-12-17 08:51:37.973 am infoStairs Lower Motion is inactive
dev:152020-12-17 08:51:19.819 am infoStairs Lower Motion illuminance is 20 Lux
dev:152020-12-17 08:51:19.758 am infoStairs Lower Motion is active
dev:2592020-12-17 08:49:25.924 am infoStairs Lower Light switch is on (this should make it jump around 20lux)
dev:2592020-12-17 08:48:33.134 am infoStairs Lower Light switch is off
dev:2592020-12-17 08:47:35.724 am infoStairs Lower Light switch is on (this should make it jump around 20lux)
dev:152020-12-17 08:47:04.468 am infoStairs Lower Motion is inactive
dev:152020-12-17 08:46:50.425 am infoStairs Lower Motion illuminance is 2 Lux
dev:152020-12-17 08:46:50.357 am infoStairs Lower Motion is active

without sitting around for change, it only seems to update on motion or some internal frequency

image
image

disabled logging on most of devices this is just turning light on and off, with no movment



my understanding is a soon (or within a few seconds of me turning the light off it should drop

timings look like 5 min intervals with no external stimulus
09:09:15.646 am infoStairs Lower Motion illuminance is 5 Lux
2020-12-17 09:04:16.173 am infoStairs Lower Motion illuminance is 25 Lux

So it's more about making sure the driver is correct than actually having a practical issue because of it?

The issue is when a light turns on, it may (does) throw the automation off.
Light turns on heigh lux
Automation turns light off due to inactivity
Walk back in lux reading is to heigh to trigger the automation because sensor hasn't reported the lux change when the light went off
Light does not come on when room is dark

But if you wait 5min its ok

2 Likes

Ah, that explains it! Thanks

That's why I made the suggestion to Mike about triggering the motion lighting app with a lux condition. If the automation can use the sensor reading that is sent at the time motion is triggered then the automation will fire correctly (at the moment it doesn't do that). Of course if you are using RM then it's simple to add a delay to test for this. However if the driver/device works as it should then all this is unnecessary, as you have pointed out.

OK, I'm starting to get to the bottom of this, well to get a better understanding of these anyway.

Leaving the driver options out of it for the moment, at the fundamental level what I'm observing alights with what you all are reporting.

The long and short is that the device isn't capable of honoring Lux threshold reporting settings in the expected manner.

OK, so what happens if we tell it to report lux every 60 seconds (or hit refresh every 60 seconds)?, it does return a value, however it does not take a current sample.

Without motion being triggered, the device only takes a Lux reading every 5 minutes, no matter what you configure for a reporting interval.

The device will immediately send a Lux event after it detects motion.
When motion goes inactive, the 5 minute sample timer starts, meaning if there's no further motion events, you'll get another Lux report in 5 minutes with a real sampled value.

OK, so if all the above weren't enough funk to make you start drinking today, here's the winner:
The device will respect configured Lux threshold reporting settings while the device is within the configured motion active window, so yeah...
If you set the motion timeout to five minutes (or just keep it active), then set the lux threshold to 1, it will indeed detect and report these levels of changes.
The motion active Lux report is not generated if the sensor value doesn't exceed the threshold set.
In other words, while motion is active the device respects the reporting settings, when it's inactive it defaults to a sample value updated every 5 minutes

Without a doubt the most bizarre implementation I've ever seen,
I'll need to digest all this for a bit so I can make the best use of this, but currently the Lux reporting options don't really align with the devices capabilities as you have noted.

3 Likes

I can tell you have done a a lot today, I would say this behaviour didn't occur say beginning this year, I'd started buying the as they worked well (but didn't have one in the location that brought it to my attention).
Could some config setting have changed the behaviour, as its a bit strange. I do have one in a box is there a way to link it say using last year's driver?

I've got 12 in a box.

I have to say I can't tell what difference Hue's 3/19 firmware "update" made on the sensor. It took about a little less than an hour to update. Not sure if I'll update the others.

5 minutes isn't so bad, but "reporting expectations", apparently don't match the sensor's actual capabilities.

its not an issue with the driver, I'm building custom config commands one at a time sending them and sniffing frames, though the current driver doesn't work as the reporting says on the tin, so it will get updated...

I also updated the firmware on the interior sample I have, it worked the exact same before and after the firmware update (from 6.1.0.18912 to 6.1.1.27575)

For the heck of it I also looked at what Hue sent to it config wise, just to be sure I wasn't missing anything, I'm not.
Their setting for lux is minimum 5 seconds, maximum 300 seconds and a .6Lux change

If we used these settings it would return a Lux value every 5 minutes no matter what, and a Lux report every 5 seconds while active if the value changed by more than .6Lux

I suppose it's possible the device worked differently with firmware versions prior to 6.1.0.18912, but I have no way of knowing this.

Does it send messages for lux and motion at same time? Could it have been a race to which got wrote to the DB first and now lux is slightly slower or motionhas been more efficient??

I've not changed any firmware, jut out of the box and use

I wish you luck with this as I briefly tried using lux on these as a ML restriction before deciding it was a rubbish idea. It seems that optimally these would report lux on the initial motion event, then again when the lights turn off (maybe something that could be called from the ML app).
They do work very reliably for motion and temperature, and battery life that is measured in years for mine.

zigbee on the wire is serial, and the attributes aren't part of the same cluster so they can't be reported in one command.
Per the packet sniffer, motion active is sent first, then ~50ms the lux value, the driver processes them in the same order.

not a rubbish idea, I have a few rules like that (using a dedicated exterior model mounted outside)

They do depending on the configuration settings, which as i mentioned aren't optimum with the current driver, in fact broken in some cases

i don't understand the use case for this

It’s been a while since I tried this, so I could be misremembering, but it seems that using lux (indoor) as a restriction resulted in the lights not coming back on as expected after the lights came on, triggered the high lux value, and then shut off per inactivity, unless enough time had passed.

Yes, I agree that that is a good use case for using lux. I will have to break down and get another outdoor sensor for this purpose. My current outdoor Hue was going to fill that role, but I ended up needing to place it below a 3000 lumen fixture so it wouldn’t pick up street traffic.

Right, thanks @mike.maxwell, this matches exactly my observations. Also I assume the outoor sensor works in the same way?

So will we be able get an update to the motion lighting app to take this into consideration?

(At least now I'll be able to get lux restrictions for my out door lights working via RM)

I don't fully understand what issue that would solve.

It is a very very specific device related situation, this is not something we would normally consider modifying an application to acomodate.

Once the driver is updated to update in a more understood way your rule will have a lux reading available that is no older than 5 minutes, I don't see a practical value in needing one more recent than that.

@mark.cockcroft summed it up here Hue motion sensor illuminance reporting expectations.

It's not a huge deal if it's not going to happen as it is 5 minutes, other than the minor annoyance factor in that use case (which is what I'm also doing).

Oic, honestly, having a rule control a light where an input to that rule is a lux sensor in view of that same light is always going to be interesting.

We know for a fact that turning a light on in a room will increase the brightness in that room. I don't see any value in needing to measure it to see if it's bright, since if the lights are on, then it is.

Deciding to turn on a light in a room if it's dark outside is the proper way to do it, since the exterior sensor isn't being affected by the room lighting.

Download the Hubitat app