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.
I wonder if we may be misunderstanding each other here, I'm not interested in what happens after the light is turned on, rather to delay the actual turning on (or not) of the light unless the ambient light level measurement (sent 50ms after motion is detected) is below the set app threshold. This would overcome the issue that Mark raised in his post.
If this were some cheap xiaomi type device I'd understand but the hue is pretty much the Rolls Royce of zigbee motion sensors (at least price wise).
Anyway I'm not going to die in a ditch over this if there are no changes to the app. If it bugs me more I could probably slave yet another virtual sensor to achieve the desired end result. Thanks again for your efforts in confirming this device behaviour!
I can't make a device do something if it wont do it be that a $5 device or a $50 device...
Philips chose to not follow typical attribute reporting configuration settings, there's nothing I can do about that.
We aren't going to change the app, to deal with this.
In my opinion if one is serious about leveraging illuminance as a factor in controlling interior illumination then a sensor should be located apropriatly at an exterior location.
When implemented as such, interior levels can't effect sensor readings and the reporting interval is less import and as lux changes are much more gradual, particulary when the change interval is resolved with a log function.
I'm fooling around with aiming it at windows.
I've got a couple of Zooz ZSE29 exterior motion sensors, but it seems to me they're either on or off, lux wise, ...nothing much in the middle. The Hue interior (and exterior?) seem to be more granular (if that's the right term).
I have a lux sensor for each room which I use to make an average for each floor level. My current sensors are aeotec multisensor 6 which only report every 30 mins or 5 depending on battery or usb powered but the average works
FYI I've now slaved the hue sensor to a virtual sensor via node red to use the lux reading at the time motion occurs, so far it seems to trigger ML in the way I want it to. Trigger delay seems to be minimal on top of the 80ms I've allowed for the reading to become available (of course it's better to have an app do this but my groovy skills are still at kindergarten stage)
I have just finished reading through this thread and was thinking something similar (I think), if you could store the last lux reading when there were no lights on in the room, then as long as that wasn't too long ago, you could use that as the basis for rules. So for the earlier example of going in, out and back into a room, essentially the lux reading before entering the room the first time could potentially be used throughout.
Personally I wouldn't expect this to be handled by HE, but a custom app or RM rule may be useful, or Node Red as @rocketwiz has used.
But if you had a light level reading already being generated at the time you enter the room (before any light is turned on) wouldn't that be better though?
If the room is bright enough due to natural light being available or other lights being already on then you wouldn't want/need to turn on any additional light sources.
Yes, that part of the scenario still falls inside what I explained poorly
At that point you describe you are right, if you have a very recent reading before any lights were turned on then that is definitely the one you want to use. The comment I was making relates more to the second entry into the room where potentially the last lux reading had been taken before the lights were turned off. What I was suggesting was that in that case, use the reading before the first entry into the room, being the most recent reading without any lights on in the room. Perhaps this might illustrate it better:
Lux Reading A - low light, recorded with no lights on, stored in a variable or device, etc
Person enters the room
Lights turn on - based on motion and low light from Lux Reading A
Lux Reading B - bright light, recorded with lights on
Lux Reading C - bright light, recorded with lights on
Person leaves the room
Lights turn off
Person enters the room
Lights turn on - based on motion and value in variable for last Lux Reading with no lights on, i.e. reading A
If a lux reading D is recorded in between the lights being turned off and the second entry into the room, then the lux reading stored in the variable (A) would be overridden by D and that would be used when assessing whether to turn the lights on the second time, which I expect is what you were questioning in your last comment.
I'm not claiming it is a good solution or even a complete solution, just an idea. It would fall down in a number of areas, including if the natural light had increased in between the person leaving the room and re-entering and we were still relying on Reading A.
As the hue sensor (and Aqara motion sensor as I've just discovered elsewhere on the forum today) sends a new reading when motion is detected I just use this to determine whether to turn the light on. In node red this requires just a little bit of extra work to extract only the first reading sent (prior to the light being on) and ignore the rest (B/C in your example) while motion is active. That way no reading D is needed (in any case the hue can't do this until after 5 minutes).
I might add that the ML app behaves in the way you described, when used with a hue sensor. So it will work fine most of the time (just not 100% of the time)
