I'll let you know how this goes...right now I'm betting a lightening storm would play havoc and cause false triggering on any rule not accommodating it (even if that means having current weather as a input to cause triggers to be disregarded).
Thus the challenge... is that first flash one from a flashlight, headlight, or lightening. Might be a matter of sussing out signature, duration & more importantly lux level; if that hysteresis doesn't muddle things. Certainly the lightening lux level is going to be above all else in the shortest amount of time. But all three sources could "flash" and be done in 3 seconds or less.
Am I being over simplistic, but wouldn't having more than one sensor make this more do-able?
A rule to compare the values of the two data sources in a set time period, and react accordingly?
Two carefully positioned sensors pointing "x" degrees away from each other. Lightning would trigger a massive lux increase on both sensors simultaneously. Headlamps would either trigger one more than the other, or (as the vehicle moved) would sweep across the two. A flashlight would probably be more random in its movement between the two.
Not sure where they ship from yet. The shipping charge was $9 for 1; $10 for 4. (I order 2 for myself and 2 for a friend). They are supposed to arrive sometime between Mon. 28 Feb. and Fri. 04 Mar.
That's an idea worth trying if @marcaronson408 has found a trust-able source for more of these!
One site is a greenhouse with a covering that readily disperses incident light, so it's not so clear as headlights being a "point source". The flashlight case would certainly be more localized.
I think you are absolutely onto something with respect to differentiating from lightening because as you said, it would light EVERYTHING equally in a high lux FLASH (so to speak). The problem there might be the time it takes the devices to recognize such a short change and report it. But then maybe that's one way to have lightening ignored
Never written a rule with such real time comparative value assessment. Fun to be had.
Tracking shows that they shipped from Spain and are now in the Netherlands. I'll post updates as things materially progress.
A bit more info - I just learned that the tracking number is recognized by USPS. So it looks like the package started in the postal system in Spain, is now in a centralize sorting station run by the Netherlands postal service and will ultimately be delivered by USPS.
I've registers with USPS to get regular updates on the package's progress.
Kind of interesting how well these various national postal systems are integrated...
Yes, that is where it could get hung up. I've had a couple of other international orders from various sources clear customs without a problem, including batteries from Hobbyking's international warehouse and items from Amazon Germany.
We shall see how this one goes.
Another tracking site ("Spring GDS") has more granular info, and shows it is now OTB (OuTward Bound). Hopefully that means enroute to the United States, but time will tell.
Just want to substantiate something that others have said, and for those that come behind.
I just switched this sensor to another hub running the latest FW and paired it. While it paired just as quickly as on the other hub (older FW) I experience the randomness seemingly delayed reactions in configuring this GZCGQ01LM device. [EDIT: It seems there is a good explanation]
The following is ALL that first showed up. It took the Battery data about an hour later to populate. Now that was after placing the sensor out of the proximity of the hub and likely now on an Ikea repeater (but I did not check) some 80' away from the device.
Just following up so that folks are aware of the Community efforts that have made some significant strides to facilitating the illumination anomaly identification use case I initially talked about in the post I'm replying to.
1st - @birdslikewires gets this driver working for the expanded collection of these GZCGQ01LM sensors
and
2nd - @bptworld does a retooling of his Averaging Plus app to accommodate a number of key features that allow the collection, averaging, and comparison of actionable data off such sensors.
boom. bada bing bada boom as she says in 5th Element. I'm error free!
(is it because the device isn't reporting any pressure and causing the line to fail? the If (x) returns false so the statement is skipped?)
I quick update on the Xiaomi light sensors I ordered from techinn. It took about 2.5 weeks for them to arrive. I've installed them and they are working well!
For those wondering, the package originated in Spain, then went to the Netherlands, then arrived in the US. They cleared customers without an issue.
@birdslikewires Thank you so much for the driver -- it worked perfectly the first time!
Awesome, thank you for the confirmation! I've never been personally been able to test one fresh out of the box, so it's good to know the driver is behaving correctly.
I'll add some checks as illustrated by @thebearmay to guard against null values in the future.
@birdslikewires Is there a way to control how often the light sensor reports lux changes? There are times when I get many events/minute, which results in rapid firing of one of my rules. It works, but I am concerned that it could overload the hub. Thanks!
