I just recently installed the Network Health Binding and was delighted to find it now has a “cache period”. Prior to the introduction of this every minute you would see an update for each item, even if the state did not change. With the new configuration you can set it to cache the state for a period of time and it will not update unless there is a state change, so instead of having an update every minute, you only get it every x minutes unless there is a change in state.
I was wondering if it’d be possible to add a similar function to the DSC binding for PANEL_CONNECTION and PANEL_MESSAGE?
What you are seeing are the results of the binding polling the DSC Alarm. The poll period defaults to 1 minute, but can be adjusted in your openhab.cfg file up to 15 minutes. This is necessary to keep the connection from being dropped by the alarm system.
You can also suppress the acknowledgement message you receive from polling by setting the suppressAcknowledgementMsgs option to true in the openhab.cfg file.
Here is a link to the wiki: https://github.com/openhab/openhab/wiki/DSC-Alarm-Binding
Hope this helps.
Thanks @rsstephens! That is exactly what I was looking for!
I understand your point, but it is in fact a good thing to know the accurate state of the “network health” of an item. What is probably not good is a log being appended every minute that reports the update, or a rule that triggers on “received update” when what you really want is to trigger on “changed.”
Updating the state of an item every minute—even when the state hasn’t changed—means that the binding is making sure you know the real state. In several cases where bindings are caching item states, they are in fact creating new negative side effects that weren’t apparent to the developer when the change was made (not saying that’s true in this case, just that I’ve seen it be true in other similar cases). For example, if the binding is suppressing updates, you have no way of knowing how recent the real state was known by the binding. It’s almost always better to fix the downstream side effects, like excessive logging and incorrectly triggered rules, than to cache item updates.