Network binding and basic-profile:debounce-timer

[daabm (Martin Binder)]

Hi all.

I’m trying to use the network binding to ping devices, and I apply a debounce-timer profile to the respective things.

Openhab is version 4.2.1.

The thing is quite basic:

Thing network:pingdevice:PresenceMartinHandy "Anwesenheit Martin Handy" @ "Wohngebäude" [
  hostname="iPhonevonMartin",
  refreshInterval=5000,
  retry=2,
  timeout=1000
]

The items as well have no frills. There’s one item that represents the real ping state and one that is debounced:

Switch PresenceMartin_Direct "Anwesenheit Martin Direct" <presence> ( Presence_DebounceTest ) { channel="network:pingdevice:PresenceMartinHandy:online" }
Switch PresenceMartin_Debounced "Anwesenheit Martin Debounced" <presence> ( Presence_DebounceTest ) { channel="network:pingdevice:PresenceMartinHandy:online" [profile="basic-profiles:debounce-time", toItemDelay=30000.0] }

But it does not work. The debounced item never receives any update. If I enable trace logging for the basic-profile, I see that my “Direct” item gets updated and that the debouncer schedules an update for the debounced item. But it never gets updated:

2024-08-19 14:13:56.306 [INFO ] [openhab.event.ItemStateUpdatedEvent ] - Item 'PresenceMartin_Direct' updated to ON
2024-08-19 14:13:56.306 [DEBUG] [al.profiles.DebounceTimeStateProfile] - Received state update from Handler
2024-08-19 14:13:56.306 [TRACE] [al.profiles.DebounceTimeStateProfile] - Scheduling state update 'ON' to item

This repeats over and over again on every update of the channel (each time a ping is sent). To me it seems the profile is resetting the debounce timer upon each update, thus never updating the item.

Can anyone confirm or am I doing something wrong here?

[rlkoshak (Rich Koshak)]

@daabm

To me it seems the profile is resetting the debounce timer upon each update, thus never updating the item.

That is exactly what’s happening and it’s working as designed. You need to set the debounce delay to be less than the refreshInterval. Debounce will wait 30 seconds after the last update before updating the Item. If the Item updates every five seconds there’s never a chance for debounce to happen.

[daabm (Martin Binder)]

I fail to understand… Debouncing is “after a change in a channel state, wait a defined amount of time for the new state to be stable, then update the item if the state doesn’t change again”.

This is exactly what’s happening here. The ping status changes from “OFF” to “ON”, then the debouncer kicks in and SHOULD update the item if the state stays “ON” for the debounce delay. But it seems to reset itself each time the channel updates to the same “ON” state again. It should not do that - if the channel updates to the same value as before, it should treat that as “expected” and not reset the debounce delay.

In addition, if I set the delay to be shorter than the refresh interval, no debouncing can happen at all and the whole technique of debouncing would be obsolete.

[daabm (Martin Binder)]

Just to add some Kudos to @rlkoshak - I currently use your debounce addon, which does exactly what I expect. But since this debounce-timer profile should be able to do the same, I tried to switch to it. To no avail currently
The ping status for your addon has a refresh interval of 30 seconds, and the debounce interval is 5 minutes. Meaning “if the state changes to a different state and stays there for 5 minutes, update the proxy item”. Regardless of how many updates the source item receives, as long as they result in the same state.

[rlkoshak (Rich Koshak)]

@daabm

Debouncing is “after a change in a channel state, wait a defined amount of time for the new state to be stable, then update the item if the state doesn’t change again”.

The docs for the profile says:

In LAST mode this profile delays commands or state updates for a configured number of milliseconds and only send the value if no other value is received with that timespan. In FIRST mode this profile discards values for the configured time after a value is sent.

Even if the value is the same as the last one, it’s still a value received.

@daabm

It should not do that - if the channel updates to the same value as before, it should treat that as “expected” and not reset the debounce delay.

That’s not typically how debounce is implement nor how it’s typically used. The whole concept comes from physical push buttons. It’s a time period where you simply ignore updates from the sensor until the sensor stops “bouncing” around. If you receive updates from the sensor before the end of the debounce period, that means the sensor is still bouncing around and the readings should be ignored.

@daabm

I currently use your debounce addon, which does exactly what I expect. But since this debounce-timer profile should be able to do the same

I didn’t implement the profile and my Debounce rule template does a lot of stuff that is outside a typical debounce bnehavior. For example, it can debounce only one state or a few states of the Item but immediately pass through others. If it were possible to set the trigger type as a property I would let you choose bewteen changes and updates too. But all that sort of thing is outside the scope of a standard debounce.

Don’t take my rule template to be how debounce is supposed to work. I’ve added features to it and implemented it in certain ways that are ouside the scope of a standard debounce algorithm.

[daabm (Martin Binder)]

@rlkoshak

In LAST mode this profile delays commands or state updates for a configured number of milliseconds and only send the value if no other value is received with that timespan. In FIRST mode this profile discards values for the configured time after a value is sent.

Even if the value is the same as the last one, it’s still a value received.

My point on that is “if no other value is received”. The channel does not send “other” values, it always sends “ON”. In my understanding, that is not an “other” value and should not re-trigger the debounce timer. Anyway, I’ll keep using your addon if no other answer sheds light on this behavior.