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.
