I’m looking for a way to feedback errors with Items/Things with the UI. i.e. If I tell a light to turn on in the UI, and it doesn’t, there’s a problem. But I can’t see/find a way to feed the problem back to the user. For instance the UI Item could turn red.
I’m looking for any suggestions people have, or perhaps I’ve just missed the obvious?
In terms of which bindings, I’m currently using mainly MQTT with Raspberry pis on the remote end actuating whatever it is. I can’t see how I could do this without changing the MQTT binding, as it seems to be a fire-and-forget type of thing. So I was thinking of moving to using exec and just writing a script to send the instructions out to the end points from there, this way I could get feedback from the script in the form of output and/or exit code. Buuuuut I don’t see a way to display such information in the UI even if I could get it into OH to begin with.
Has anyone else tried to implement success/failure feedback? Any suggestions/hacks you can think of?
There is really no consistant way to do this. The reasons are:
Many if not most technologies provide no feedback that could be used to determine whether an error occured. Some provide no feedback at all. Some provide feedback but not in a timely manner.
For those that do provide feedback, it is difficult if not impossible to differentiate between a true error (i.e. I turned on the light and the command never was received by the device) and a manual override (i.e. I turned on the light with the sitemap and someone else immediately turned it off at the switch.
The UI elements do not have an “error” state, unless you count Undefined as an error state.
So, assuming you were able to provide a feedback loop (with MQTT you can make your code running on the remote Pis report the actual state of the relays on one topic and use a separate topic for commanding), you can set up some rules to set a Timer after sending a command. If you don’t get a state change message back on on the status topic before the timer goes off set the Switch to NULL.
However, consider the following:
MQTT is very reliable and can be configured to deliver exactly once. So you can be pretty certain that if there is a client on the other end to receive the message, it will get the message.
Given that, what you really need is something to detect when the client itself is offline. MQTT has a built in mechanism to do this with the Last-Will-And-Testamint message which the broker will send to the indicated topic when it detects the client goes offline.
If you create a Switch that gets set to ON whenever you receive a message from your status publishing topic and set to OFF when the LWT message is received you will know when your client is offline. Then you can send an alert, set the Switches to NULL, etc. You can even send an alert when you try to send a command to a client that is known to be down.