search

openhab / openhab-core

Core framework of openHAB
https://www.openhab.org/
Eclipse Public License 2.0
928 stars 428 forks source link

[profiles] Proposing debouncing profile #2172

Open curlyel opened 3 years ago

curlyel commented 3 years ago

The Problem in case of switchor contactchannels

If the channel switches a couple of times between the two states ON/OFF (or OPEN/CLOSED) before stabilizing, rules may get triggered multiple times, besides the fact, that the event bus and the logs gettin flooded unnecessarily.

The Problem with numberchannels

Some sensors don`t have the option to set a notification threshold for transmitting a changed value. If a thermometer transmits with a precision of 0.01 degrees, the reading bounces a lot without being relevant for some automation. Again: Rules may get fired unnecessarily and the log get flooded.

Proposal

I'd assume, that debouncing is widely needed feature and worth been implemented as early as possible in the event processing. Therefore, it should be provided in the form of an additional link profile.

This debouncing profile should limit the changes according to a timeoutfor contactand switchchannels and according to a timeoutand a value threshold for numberchannels.

Expected behavior

Contact/Switch channels

Number channels

openhab-bot commented 3 years ago

This issue has been mentioned on openHAB Community. There might be relevant details there:

https://community.openhab.org/t/design-pattern-debounce/101566/6

rkoshak commented 3 years ago

If a thermometer transmits with a precision of 0.01 degrees, the reading bounces a lot without being relevant for some automation.

This might be not the best example. For that case there is already a hysteresis profile that can handle that. In fact, debounce won't really help with that use case at all as the debounce is time based, not value based. So if the sensor keeps bouncing around, the debounce may never actually happen at all because the Item doesn't remain in the same state for long enough.

A better example would be something like presence detection, service offline detection (in cases where the network is iffy), and stuff like that. A case where we want an Item to remain in a given state for a certain amount of time before accepting the state change.

Beyond that, having implemented this using a Rule and Item metadata one additional feature would be to be able to define which states are debounced. For example, I implement my presence detection using debounce. I've a Group:Switch:OR(ON,OFF) Presence that represents whether or not someone is home. Each person has sensors that determine whether or not they are home and are members of Presence. When these sensors go to ON I do not want to debounce the state. When they change to OFF, I debounce the state for a couple of minutes to avoid bouncing caused by getting the mail or working in the back yard and such.

This would indeed be a nice addition as a Profile and someone has actually implemented it as a Profile using Python rules scripting. I've implemented it using a Rule, Item metadata, and proxy Items.

curlyel commented 3 years ago

Thanks Rich for sharing your thoughts 👍

Fully agree, the presence detection is a good example for justifying the need for a debouncing feature with contact/switch channels.

This might be not the best example. For that case there is already a hysteresis profile that can handle that.

Not quite sure I understand, how the hysteresis profile can solve this. Isn't the hysteresis profile intended to derive a switch state from a number channel? (BTW: How to get access the hysteresis profile? It's not listed here... ;-) )

I understand, that debouncing is usually needed for binary inputs. But on quickly changing numeric inputs, we sometimes require some thottling of the update rate as well...

Let me share another example to explain how I think debouncing on number channel would be quite helpful:

This is the voltage reading of my smart meter in the line to my wall charger:

2021-02-01 10:28:06.564 [INFO ] [openhab.event.ItemStateChangedEvent ] - Item 'TeslaWallcharger_Spannung2' changed from 231.4 V to 232.0 V
2021-02-01 10:28:06.576 [INFO ] [openhab.event.ItemStateChangedEvent ] - Item 'TeslaWallcharger_Spannung3' changed from 233.1 V to 232.3 V
2021-02-01 10:28:09.921 [INFO ] [openhab.event.ItemStateChangedEvent ] - Item 'TeslaWallcharger_Spannung1' changed from 232.3 V to 232.6 V
2021-02-01 10:28:09.955 [INFO ] [openhab.event.ItemStateChangedEvent ] - Item 'TeslaWallcharger_Spannung3' changed from 232.3 V to 232.2 V
2021-02-01 10:28:13.303 [INFO ] [openhab.event.ItemStateChangedEvent ] - Item 'TeslaWallcharger_Spannung1' changed from 232.6 V to 232.5 V
2021-02-01 10:28:13.338 [INFO ] [openhab.event.ItemStateChangedEvent ] - Item 'TeslaWallcharger_Spannung2' changed from 232.0 V to 232.2 V
2021-02-01 10:28:13.356 [INFO ] [openhab.event.ItemStateChangedEvent ] - Item 'TeslaWallcharger_Spannung3' changed from 232.2 V to 232.5 V
2021-02-01 10:28:15.954 [INFO ] [openhab.event.ItemStateChangedEvent ] - Item 'TeslaWallcharger_Spannung1' changed from 232.5 V to 232.3 V
2021-02-01 10:28:15.967 [INFO ] [openhab.event.ItemStateChangedEvent ] - Item 'TeslaWallcharger_Spannung2' changed from 232.2 V to 232.1 V
2021-02-01 10:28:15.972 [INFO ] [openhab.event.ItemStateChangedEvent ] - Item 'TeslaWallcharger_Spannung3' changed from 232.5 V to 232.7 V
2021-02-01 10:28:16.632 [INFO ] [openhab.event.ItemStateChangedEvent ] - Item 'TeslaWallcharger_Spannung3' changed from 232.7 V to 232.6 V
2021-02-01 10:28:19.910 [INFO ] [openhab.event.ItemStateChangedEvent ] - Item 'TeslaWallcharger_Spannung1' changed from 232.3 V to 232.4 V
2021-02-01 10:28:19.931 [INFO ] [openhab.event.ItemStateChangedEvent ] - Item 'TeslaWallcharger_Spannung2' changed from 232.1 V to 232.0 V

These are 13 events within 13 seconds. The voltage is floating up/down by just few hundred Millivolts. Neither relevant for persistence nor for reacting with a rule on a voltage drop.

BUT: A rule been triggered by the changing values will get fired almost once per second. My persistence will get an update once per second too ("every change").

With a debouncing feature as profile those plenty of events could be hold back. In this example I'd configure the profile to update the linked item at maximum once per minute or immediately in the case, that the voltage has dropped by more than a two Volts.

So I'd get good timeseries data persisted without consuming to much ressources (CPU/IO) and less flooding of my log. And I can still react immediatly with a rule on relevant Voltage changes.

rkoshak commented 3 years ago

Now that I see it, I'm not sure what I was thinking with hysteresis. It wouldn't work here at all. I have a recollection of seeing a github issue going by that would support a requirement that the Item change by a certain amount before updating it. That could be added to a debounce profile like this but it feels like something different. The configuration would be completely different for a numerical Item's debounce verses a binary Item's debounce.

(BTW: How to get access the hysteresis profile? It's not listed here... ;-)

I don't know. It's in the docs and has been for quite some time. I imagine it's been merged by now but maybe not?

curlyel commented 3 years ago

but it feels like something different. The configuration would be completely different for a numerical Item's debounce verses a binary Item's debounce

Yes, exactly.

Although there is the similarity of holding back unwanted "bouncing" item updates, debounceon binary has to work different from numeric channel.

From the configuration perspective, both require a timeoutparameter - with different meaning though:

The numeric debounce requires a second parameter, value("amount of change"):

Not sure, if it's good or bad to mix those two behavior into a single profile or if it should be split into separate profiles.

I think, I'd prefer a single profile which adopts to the type of channel it's applied to... ;-)

clinique commented 3 years ago

The problem I see in using profiles, as they can't be nested or do not recurse is that when we've got many kind of profiles available, you can only pick one, while it could be interesting to apply a threshold to a debounced value.

curlyel commented 3 years ago

Good point 👍

Similar problem would happen with the offsetprofile too ;-) Some might want to add an offset to a sensor reading after having debounced the value...

Only option in such cases is judging what hurts most and therefore benefit most from doing it as early as possible in the processing:

E.g. debounce with a profile first to reduce the flooding of the whole system with unwanted updates and then apply a threshold or the offset with a rule logic.

Alternatively, we could consider multiple common input filter functions to be consolidated into a universal input filter profile for numerical channels...

clinique commented 3 years ago

or else, don't know if it's easily feasible, but making profiles recursive would be great.

rkoshak commented 3 years ago

From the configuration perspective, both require a timeout parameter - with different meaning though:

I actually would not expect there to be a timeout parameter for a number Item. I'd expect there to only be threshold "the Item must change by X amount or more from the current state". For example, if it's a temp sensor it should have to change by 0.1 or more or else the update is ignored. Time wouldn't play into it.

That's what I mean by their working completely differently. A simple time based debounce of a number sensor doesn't seem right because it's not really the frequency of the reports that you care about, it's the noise in the readings. And once you have the threshold set the time between updates handles itself so it's not needed. Setting both seems redundant.

The problem I see in using profiles, as they can't be nested or do not recurse is that when we've got many kind of profiles available, you can only pick one, while it could be interesting to apply a threshold to a debounced value.

I think it's important to restate the purpose of Profiles. They are not intended to be comprehensive. Instead they are intended to be a convenient replacement for some simple rules . If you run into a case where you would want to apply more than one Profile, you've moved outside of the purpose of Profiles and need to move to a rules based approach.

So I think the threshold for creating a new profile would be whether or not it solves a common problem by itself. Maybe it doesn't solve all possible edge cases or use cases, but it covers enough to be useful. I think debounce meets that threshold. But I still think we might be dealing with two debounce patterns here. I'm not sure whether it makes the most sense to implement as two separate profiles or try to implement it in one.

curlyel commented 3 years ago

Hi @cweitkamp, I just noticed your recently added range profile (https://github.com/openhab/openhab-core/pull/2046)

A really nice extension to the list of profiles 👍 Many thanks.

May I drag your attention to the discussion here about a debouncingprofile for binary and numeric channels and share the idea with you too?

I think this would bring a quite beneficial addon for "filtering" quickly changing input channels and protecting the rest of the infrastructure from uneccessary load. WDYT?

openhab-bot commented 3 years ago

This issue has been mentioned on openHAB Community. There might be relevant details there:

https://community.openhab.org/t/heavy-disk-i-o-on-oh3-solved/118314/10

cweitkamp commented 3 years ago

Hi @curlyel,

Sry for my late response. Thank you for pointing me to this discussion and sharing your idea / information.

A debouncing Profile sounds like a nice addition for openHAB. Not only to save resources but to provide a clean output. I am not an electrical engineer but I hardly remember I learned some theory about software debouncing during my study. You already mentioned the most popular approaches: time-based and counting. There should be a lot of information on how to archive the expected results when using them on the internet but we have to find the best way for the framework to implement a solution. Most of the time the correct way depends on the purpose of the user. Thus an implementation should be flexible / configurable.

You are right with separating binary based and numerical types. A solution should handle them differently. I am wondering if we should write down some lines of code to give it a try - starting with binary types.

dae3 commented 3 years ago

@cweitkamp @curlyel I'd like to attempt this, it would resolve two problematic presence detection use-cases in my setup.

I'd also prefer to start with a simple time-based approach for binary items. If that works out well we could refine a counting-based design for Number items.

Has anyone else started work?

cweitkamp commented 3 years ago

Has anyone else started work?

No, I did not. Feel free to submit some code. :+1:

curlyel commented 3 years ago

I'd like to attempt this, it would resolve two problematic presence detection use-cases in my setup.

Many thanks for picking this! Looking forward to it ...

curlyel commented 3 years ago

I'd like to attempt this

@dae3 have you started working on it?

curlyel commented 3 years ago

Just noticed another issue/discussion aiming to "dynamic profiles" with the option of supplying own script code to create profiles tailored to the own use case:

https://github.com/openhab/openhab-core/issues/2201#issuecomment-782386174

Besides this, I also remember ideas/discussions on having a "ScriptProfile", which simply takes scripts as configuration parameters

There is even a bounty put on it ;-)

openhab-bot commented 3 years ago

This issue has been mentioned on openHAB Community. There might be relevant details there:

https://community.openhab.org/t/suggestions-for-improved-user-experience-with-timers/126469/12