I am quite new to OpenHAB and wonder whether there is a best practice to aggregate the state of two related contacts to a combined state. I have a rotary handle-operated turn/tilt window that is equipped with two reed contacts. A first reed contact is placed at the bottom of the window to detect whether the window is turned to be open or not. A second reed contact is placed at the top of the window to detect whether the window is tilted or not.
Clearly, I can check the status of each of the contacts individually based on the given items:
Number Window_tilt “Window tilt [MAP(en.map):TILT-%s]” { channel=“knx:device:bridge:Contacts:Window_tilt” }
Number Window_turn “Window turn [MAP(en.map):TURN-%s]” { channel=“knx:device:bridge:Contacts:Window_turn” }
However, in my sitemap, I would like to access a combined contact item that aggregates the TILTED/NOT_TILTED and OPEN/NOT_OPEN to OPEN/TILTED/CLOSED according to the following logic:
CLOSED: NOT_TILTED AND NOT_OPEN
TILTED: TILTED AND NOT_OPEN
OPEN: TILTED AND OPEN
DAMAGED: NOT_TILTED AND OPEN
What would be the best practice to aggregate the status of two items so that this aggregated status can be further processed and placed into a sitemap for visualization?
I would create a new proxy item for each window of type string, then a rule for each window which is triggered by the contact at the top of the window.
In the rule check for when the top contact changes, if it gets opened and at the same time the bottom contact is open as well then the string is set to OPEN, if the bottom contact is closed at this time set the string to TILTED, if the top contact gets closed set the string to CLOSED.
Just one approach, using groups with appropriate functions would be another direction.
P.S. depending on a possible small knx lag it might be advisable to introduce a short delay in checking for the state of the bottom contact.
I don’t think this is possible using Groups unless the DAMAGED state is really impossible.
If I assume that the Number Items use 0 to represent NOT_TILTED and NOT_OPEN and 1 to represent TILTED and OPEN than we would have the following Group states:
Tilt State
Open State
Group Value
Desired
NOT_TILTED
NOT_OPENED
0
CLOSED
TILTED
NOT_OPENED
1
TILTED
NOT_TILTED
OPENED
1
DAMAGED
TILTED
OPENED
2
OPEN
There is no way to tell the difference between TILTED and DAMAGED. But are there any safeguards in place to prevent the DAMAGED state? Can we assume that in normal operation that the DAMAGED state cannot be reached? If so we can do something like the following:
You are absolutely right with your assumption. I added the DAMAGED state just because of logical reasons of having two contacts with OPEN / CLOSE resulting in totally four states. I will never try to tilt the window on its bottom side…
In fact, my reed contacts use 0 for OPEN/TILTED and 1 for CLOSE, but this small difference does not alter the concept behind Rich’s solution.
@rlkoshak: Thank you very much for your precise guidance! Helped a lot!