Aggregate the states of a window contact at the bottom and at the top to identify OPEN/TILTED/CLOSED

Dear community,

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?

Thank you very much for your hints!

Best regards,
Peter

Hi,

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:

Group:Number:SUM Window "Window [MAP(window.map)%s]" 
Number Window_tilt “Window tilt [MAP(en.map):TILT-%s]” (Window) { channel=“knx:device:bridge:Contacts:Window_tilt” }
Number Window_turn “Window turn [MAP(en.map):TURN-%s]” (Window) { channel=“knx:device:bridge:Contacts:Window_turn” }

window.map:

0=CLOSED
1=TILTED
2=OPEN

sitemap

Text item=Window

But if the DAMAGED state is in fact reachable than a Rule and proxy Item is required.

I only saw the DAMAGED option after writing my reply. Assuming that Peter is somewhere in Europe as well, with the usual window types there, the

DAMAGED: NOT_TILTED AND OPEN

would be very rare and I assume it would be the case with the bottom contact being open, but the top contact closed, i.e. a VERY damaged window :wink:

@peter_tau - how likely do you think the DAMAGED option is, and is it that important for you?

Dear Hans,

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!

Thank you all for your comments. The Group and Sum feature gave me the full picture as how to handle similar situations…