Switch icon doesn't follow the switch item state correctly

Setup, Configuration and Use Items & Sitemaps
1

Using OH 2.4 on Synology.
For my garden I deleveloped an irrigation control system with 16 valves some years ago. Now I want to extend it in the way that I can control all valves additionally with OH. I use homematic 8-channel output devices which channels are wired-OR with the existing system. To check the current valve states I use homematic 8-channel input devices which control Contact items. The logic behind is: If a valve is not switched on by OH switch item but the state of the Contact item is CLOSED anyway then the external irrigation control has switched on that valve. To update the states I have a rule which triggers when any change in the Contact items occurs. So far it works fine.
Now I want to show and control the states in my sitemap (Basic UI). I use the visibility option to display either a switch when the valve is not activated by the external system or just a message when the valve is externally activated. Here is a code example with following items:
Ventil_A1 - switch item for switching on and off via OH
vc-A1 - Contact item showing the state of the line; is updated by the rule
ext_A1 - Auxiliary contact item which is CLOSED when the valve is switched on by the external system, used to control the visibility state.

inside the rule:

 if((Ventil_A1.state==OFF) && (vc_A1.state==CLOSED)) ext_A1.postUpdate("CLOSED") else ext_A1.postUpdate("OPEN")

In the sitemap:

Default item=Ventil_A1 label="A1: lawn" icon="switch" visibility=[ext_A1 == OPEN]
 Default item=ext_A1 label="A1: lawn - extern" labelcolor=["green"] icon="garden" visibility=[ext_A1 == CLOSED]

The problem: Switching the display works, but when the valve is switched on and then off externally the switch icon becomes green, although the switch Ventil_A1 is definitely OFF and displayed correctly in the switch symbol on the right. Obviously, icon state doesn’t follow the switch state. Any idea or workaround?

2

I think I’d go about this a different way.

You’d like to detect “manual” valve control in use,in order to change the UI. But you cannot sense that directly, you can only sense on/off. Because openHAB commands are transient, and have been and gone by the time you sense a valve change, it is difficult to determine if a valve change is manual or openHAB origins. You need to remember if you issued an OH command.

Since the main objective is to disable UI control when under manual control, I would take the “real” Switch (linked to device) off the sitemap altogether, have it purely under rule control.
Put a “dummy” Switch on the sitemap instead.

Let’s cheat a bit and use your dummy Switch Item with three states - ON, OFF as usual, and UNDEF to represent “manual”.
Disable autoupdate on this dummy, this will uncouple its state from commands.
In your case, “manual” always means “manually on”
Put this dummy on your sitemap.

You can use state UNDEF to control visibility, display dummy Switch normally when not-UNDEF and dislpay alternate “manually ON” message when UNDEF.

Scheduled rules etc. should also command the dummy switch.

A rule triggers from from commands to dummy Switch.
If dummy state not UNDEF, then pass commands to real Switch.
If dummy state is UNDEF then we’re in manual mode and do nothing.

A rule triggers from updates of real Contact, or System Started.
If Contact is equivalent to OFF, any “manual” is finished. Update dummy Switch to OFF.
If Contact is equivalent to ON and real Switch is not-ON, this will be a manual action, update dummy Switch to UNDEF.
If Contact is equivalent to ON and real Switch is ON, this should be a response to OH command, any “manual” is finished. Update dummy Switch to ON.

I think this will deal gracefully with someone manually turning ON while already ON via openHAB. That won’t get detected until later when openHAB commands OFF but valve remains ON.
Triggering the contact rule at system started should deal with startup conditions.

1 Like
3

thanks for your reply and your suggestions. Using the third state UNDEF is really a good idea. I will implement it next days and tell you how it works. Thanks again. - Ulrich