As you can see, there is a state topic and a separate command topic. To change the mode, you send a e.g. 0 to guard_mode/set, the other side picks that up, sends whatever has to be sent to the device, and when successfully changed, writes the current (new) mode into current_mode, which will also end up containing 0 (on success).
Now unfortunately, if there is a failure on the other end (= current_mode is not updated), in openHAB the new state will still be the new value. So from the item I can’t tell whether the operation was successful or not. Which is a bit sad, because the state topic would actually tell me if it was.
My workaround in the sitemap is now that I have two separate channels: one as a pure command channel to set the new mode, and another that only reads the state. While that works, it would be much nicer if it was fused into a single item. It looks like this in my sitemap:
The preferred behaviour would be that a click on one of the buttons would only send out the command, but not flip the state (as the current_mode didn’t change yet). The active button should always show the current_mode. If there was a failure on the other end the active button wouldn’t change and I would recognize it. If it was successful, the active button would change, and be a perfect visual confirmation that the command succeeded. The second row “Aktueller Modus”, which is the pure monitoring item, then would not be necessary anymore.
autoupdate works nice and the item itself shows now the desired behaviour. Unfortunately in the Sitemap the button still is immediately flipped. It seems the Sitemap doesn’t know about the autoupdate setting, right? Is there a workaround you know of?
Actually, there may be a bodgy workaround.
The problem is that after the UI has shown you which button you poked, there is no Item state update (when the command fails) which would usually prompt the buttons widget to refresh.
You may be able to have a little rule, triggered by command, that sets up a timer for say 1 second (allow long enough for the command to work), and then just updates Item with existing state. I’m not sure if update will prompt the UI, though, or if it needs change.
You can construct slightly more advanced rules to positively detect a failed command and set your Item state to, say, UNDEF to indicate it is broken.