I’ve got 2 ZSE70s placed outdoors and while I’ve been playing with them since they first shipped, I haven’t found a good way to deal in a useful way with lux in automations, and worse for the zwave network, they become VERY chatty during the day if delta based reporting is used.
Today there are two settings for lux reporting – periodic and based on change against a single delta value.
For this reason alone, the default values in an outdoor install probably should be periodic reporting, say every minute to five minutes, and NOT based on change. The swing I can see in a single morning with the sensor on the east side of the house makes one question if the device is even working.
In my research (and real observations) during the daytime, values swing in the thousands based on actual light level changes, clouds moving across sky and likely many other non-comprehensible things. I might get 60 reports in a minute during the day if my lux change value is too low OR, at night, no reported changes past dusk because the value is too high.
From a human perspective, something called Weber-Fechner law boils it down to how intensity of light level changes how much more has to be added or subtracted from that baseline for humans to be able to tell it’s different. With many of our automations, we’re building for human perception, not for actual mechanical adjustments (say f stop on a camera) and triggering actions based on light levels (motion reports turn on/off spotlight if lux <500)
I think what we need is a delta report method that builds in certain assumptions given the baseline light levels. While Weber-Fechner yields a “S” or perception value, and allowing configuration of delta S values could potentially be more helpful than pure lux delta, it might very well be overkill to implement?? If not, certainly a potential useful experiment as a better report value.
However, since I’m not sure that’s the right answer, and by borrowing data from some web searches and aggregated AI bits, perhaps a something like a staircase reporting structure could be used.
Significant Lux Change Ranges (Outdoors)
< 50 Lux (Night/Darkness): Changes in this range are highly significant for security. A drop from 50 to 10 lux is considered a significant loss of visibility.
50 - 500 Lux (Dusk/Dawn): A change of 100-200 lux is considered significant in this range, often triggering automation (e.g., streetlights on/off).
500 - 10,000+ Lux (Daylight): Changes need to be much larger to be significant. A shift from a cloudy day (1,000 lux) to full, unobstructed daylight (10,000+ lux) is a significant change, whereas a 100-lux difference in bright daylight is not.
-
Report any light level change that crosses the “step boundary” - So crossing between 50.0 and 51 is an automaticly triggered level report.
-
If in Night/Darkness, perhaps use a delta of ± 2 for triggering a report
-
If in Dusk/Dawn or better yet, through Overcast (1000), perhaps use a delta of ± 100
-
If in Daylight, use a delta of 1000 until 10,000 (for “Full Daylight”)
-
Anything brighter than “Full Daylight” use delta reports over 5000
Lastly, allowing for time based in addition to step based, we can still guarentee “fresh” values when the outside lighting just isn’t changing enough to report in but for those extra “5 minute” time based reports.
Anyhow, I’m curious and interested in what anyone feels might be useful here, and what the ZooZ team thinks is an implemenation choice. Clearly delta based floods my zwave network during the day if configured for low night (significant) changes, or misses reports that make a difference at night. Right now, time based reporting is the only smart implementation choice.
Note: I am not sure my “deltas” above make sense. Maybe there needs to be parameters per step level to set appropriate values, or where we see larger swings in daylight or higher, a “report the value if we didn’t send one in the last 5 seconds” logic. Either way, a bit of a data capture exercise might yield more appropriate values, maybe even higher than 5000 for those bright daylight reports.
@barkis since I’ve been prattling on about this with him for a while now
