I have an intermittant problem where the commands in my rules sometimes don’t take. That is, OH THINKS a command was successfully sent but it wasn’t. Example:
An RH setpoint is reached so OH turns the dehumidifier switch off. Most of the time OH will show the switch as being off and the physical switch is off, but sometimes the physical switch never actually turned off. So OH says it’s off but the actual switch is still on and the dehumidifier is still running.
Should I add redundancy to the rule where it turns the switch off a couple of times or would increasing the command poll period fix this issue?
How does this device communicate with OPENHAB, especially does the device report its state back to openHAB?
If openHAB does get no state reported from the device it will show OFF after it has sent the command OFF, no matter whether the device got a command not.
Thanks rossko57, that’s a great explanation about how AutoUpdate works. I was aware of what it does and some of the effects that can occur (I’ve had the dimmer problem) but didn’t know all that background.
Oliver2, these are AC-powered Things. I do need to check the logs more closely. It’s tough becuase it’s not too common. I do have a report on one of our systems though, that some of the lights in a lighting group don’t go off with the others, on a fairly regular basis so hopefully I can use that to track this down.
opus, how do I know if a device reports back or not? I have looked at the config. for a couple of Things/Items & I don’t see anything about that.
To my original question:
Let’s say I have an Item that is turned off by a rule and the state is shown as off, but the Item is actually still on. Changing the command poll period to something longer is not going to result in the binding (or rule) seeing that and then turning the Item off again right? So if I’m having a problem where the communication doesn’t always get through to the Item the only way to address it is to add some redundancy like turn off and then turn off again in a minute or two as Oliver2 suggests. Does that sound right?
Please, don’t keep it a secret. We don’t even know what device or technology you are talking about. You need to understand if/when that is going to talk to you.
Sorry, we use primarily z-wave devices. I’ve seen this problem with in-wall switches and plug-in switches, and some MIMO2+ relays we use for dehumidifiers.
First instinct is “fix the failing network” rather than try to wallpaper over the cracks with openHAB.
There’s a bunch of posts about getting a reliable zwave mesh.
You might start here -
If this is actioned via an openHAB Group Item, that’s the kind of thing that tests a network. Send a command to a Group Item, and openHAB propagates it by issuing individual commands to member Items. You’ll see that in your events.log.
So a half-dozen commands arrive at the zwave binding - that’s fine, it keeps a queue, and should pop them off one at a time into the ether. Except that the devices now fire up and start routing these messages, the first device responds, and now there are messages going the other way, etc. It all gets very busy, and if a link in the mesh is a bit wonky, this will show it up.
