During Sunrise and Sunset ramps all of my Xiaomi Light Sensors are very active and
occasionally could send messages few mS apart. During the day they are quite.
For my automations reporting light status every 30 sec should be sufficient.
I'm using Markus' driver for the a Xioami/Mija light sensor I have, and it allows you to control reporting frequency. The driver you're using for it does not allow control of reporting intervals? Maybe change drivers?
2 Likes
Even that seems excessive unless you actually NEED to register very small changes in light nearly instantly. Instead of having mine report every given time period in seconds or minutes, I have mine report once every half hour or any time the illuminance has changed more than 50lux since the last report.
1 Like
I am using this Driver:
Unfortunately this Driver does not have a setting for the reporting interval:
At a time (a year+ ago) when I installed these sensors the above driver was recommended
by community because with this driver Xiaomi sensors did not drop from the Zigbee Mesh.
Well, in my case they never dropped. But this driver does not have any control for
status reporting interval.
As I mentioned above, I already solved this problem by throttling a re-trigerring interval.
I guess, reducing a reporting interval will do a better job by reducing number of Events
which is obviously will be less load for the CPUs.
From my understanding the driver you're using shouldn't have an impact on whether or not your device stays connected.
2 Likes
Not near instantly but it must be fast enough because all these light sensors are in charge
with Lighting and Curtain automations. I am in South Florida (Sunny Isles Beach) and all
my windows are facing West. After about 1:30 pm Sun is shining directly into all my windows.
What is worst, there are many fast passing clouds. From one side I don't want the Curtains
to open/close very frequently but from the other side I don't want very bright Sun to shine
through the windows for a very long time. 30sec (experimental value) seems to be satisfactory
and has relatively high WAF.
Here is one of my modified (and significantly simplified) rule:
The delay for re-triggering depend on what to expect.
For Curtains Closing it is 30sec but for Opening it is 3min
PS.
My original rule was far more complicated.
It was some sort of PID loop which required very fast data reporting.
Somehow this was not a problem on C7.
This sounds very logical but according to what I was reading (long time ago) it somehow does.
I personally did not experiment with different Drivers. I simply picked one whichever was
recommended by community and never had a drop off problems.
Sounds like you've got something set up you like. If you ever want to play around to the drive that has the control over the reporting timing here's the link.
I have played that game myself I have to admit thinking hoping that a driver would help when things won't stay connected. But I've yet to find anything that proves that the driver has any impact.
Thank you for the link.
But yes, now I am all set with the driver I already have.
I am trying to understand what this app is doing.
Correct me if I am wrong (I am not a fluent SW person) but it looks like the app gets a state of
the physical device, waits number of mS and modifies accordingly a state of the virtual
output device. If during the delay physical device changes its state the delay restarts
without changing a state of the output device.
Another words, the output from physical device must stay unchanged for the specified
de-bounsing timeout. If I am correct this is exactly what I am doing in HW for filtering out
noise from Contacts or whatever devices with noisy output during its state transitions.
This filtering algorithm works very well for the devices with two (On/Off) states (like contacts).
However for the devices with analog output (like Light/Temp/Humidity sensors) the filtering
algorithm must be more complicated. First of all - analog device may not return the same
value from different sequential reports. Another words, output from analog device may never
be the same for the specified de-bouncing timeout. However output values may stay within
acceptable delta for a long time. So filtering for the analog device should take in account
multiple sequential data and make sure all these samples staying within the acceptable delta
during the predefined de-bouncing timeout. And if "yes" send out average value.
I can easily implement this in HW (actually already did it many times) but I am not sure I will
be able to modify yours code, designed for the de-bauncing Contact Sensor for the
de-bauncing analog device like Light Sensor, etc. I know what exactly what should be done
(create an array, fill it like a circular buffer, find min and max values, calculate a delta for the
min/max values, make sure delta is less than acceptable, calculate average, if everything is Ok
within de-bauncing timeout send average out) but my programming skills is not that good
for implementing this filtering algorithm in SW.
This is a completely different problem, as you define what should happen.
The problem addressed by the app is literally a bouncing sensor, where it mistakenly sends two or more events in quick succession (within a few milliseconds), for a single physical world event. I have a contact sensor on our office door that does this. The app also takes advantage of a property of the scheduler, that scheduling itself forces a single queue, so that multi-processor relative timing is removed as a consideration.
Use of Private Boolean in a rule with Required Expression, reduces the window of vulnerability to a very small period of time -- most likely less than the interval between bounces of a bouncing device. For these very short intervals, averaging data for analog devices is irrelevant.
I know you don't need any more help from me, but I can't help myself. Forgive me. 
I really think that the appropriate place to throttle reporting is on the device itself, rather than letting it bombard the hub and writing work-arounds to ignore the extraneous events in rules. Just seems like you're working at it from the wrong end. Totally your choice, of course, and I will go away now. 
2 Likes
Agreed! And, fixing it on the device will also dramatically improve battery life of the device.
4 Likes
For the Contact Sensors (specifically electromechanical devices like relays and
buttons) your statement is absolutely correct. Yes, these devices may generate
very huge amount of on/off events during transitioning between states.
This unwanted events is very easy to filter out. That is what denouncing for.
From the other side electronic sensors newer will send out anything by mistake.
All messages are absolutely valid. But yes, messages could come well too often
than desired. Xiaomi Light Sensors are very active during Sunrise and Sunset
ramps. Most likely they designed to send message when they see differential value
over predefined threshold. That is why they are sending a lot of messages during
fast changing ramps. The question is -is this threshold user configurable or not?
If yes then definitely right place to deal with this problem is to reconfigure a device.
Driver which I am using doesn't allow any device reconfiguration.
Maybe different driver has such an ability but device itself must have reconfiguration
capabilities in a first place. But if device cannot be reconfigured Driver or App can
simply srow away some data. This is not a fitering or denouncing but definitely will
reduce upstream processing and reduce hub load.
I will try to understand what your app is doing in details and potentially modify it
for the analog sensor throttling.
No doubts the absolutely right place for dealing with this problem is device itself.
The question is - is it possible to reconfigure this device?
If other driver has a configurable reporting interval it doesn't mean the device
itself will be sending less messages. But regardless this is better place than rm.
Because output of analog sensor is not like black or white the filtering algorithm
should make sure the data stays within acceptable min-max window longer
than desired timeout. But what data will be sent out? It could be anything
between min and max but average is more appropriate.
Markus’ driver sends a Zigbee configuration command to adjust the reporting interval. Thus, the device will actually send less frequent data, if desired.
3 Likes
So the device is actually configurable. Thank you for the info.
I will switch to Markus driver .
2 Likes
OK, I replaced driver for one light sensor with the one you suggested.
This driver has a setting for the reporting interval:
I checked a driver code and if I am not mistaken this parameter is written to the
device itself. So device must be quite during the specified timeout.
Is this true?
And if "yes" the suggested de-bouncing (i.e. filtering) app is not required.
I wonder, what is a factory default value for this setting?
It looks like it is zero because the device could generate messages too often.
1 Like
This topic was automatically closed 365 days after the last reply. New replies are no longer allowed.
