Item update issue

Setup, Configuration and Use Installation
,
1

Hi, I’ve recently noticed some strange behaviour with the updating of channels.

I have a switch inside my boiler, I use this to control my heating and this usually works flawlessly, recently this node had been going offline randomly yet the item shows as OFF even though it is ON. Switching the node off and on has no effect on the switch, yet the GUI and the logs think the item has actually changed state. This triggers both the Item changed and the Item received update.

I cannot remember this being like that, surely the node (or thing if you prefer), should post it’s status instead of the engine just assuming it has changed.

Last night my heating stayed on all night because my rule checks for the state and doesn’t turn it off unless it is on, and it thought it was off even though it was on.

The only solution I can think of to work around this behaviour is to have a cron constantly switching the node depending on it’s assumed state. I would rather not do this. Fixing the node so it doesn’t go offline is, of course, another solution, but I am kinda glad this has happened.

I’d include logs, but those logs would only show the system working perfectly, because the system is not getting its state from actual node state changes.

I’m not 100% certain, but I am sure this never happened before, there was always a delay in the GUIs while nodes were switching, now there is no delay, the system just assumes things went well.

2

@psych which system do you use? does it have 2 way communication?

3

I am using Openhab 2.2, the switch is a Zwave Horstman ASR-ZW receiver.

If I manually press the on/off switch on the receiver, openhab sees it and updates.

I really do think this is a software issue, I mean, the GUI shouldn’t be updating node states unless it has at least received an ‘ACK’ from the node.

4

Not an issue, a feature called autouopdate, which is enabled by default. If you prefer to have your Item show the reported state of the device, rather than what OH guesses it ought to be, you need to set autoupdate false for that Item.

For many situations, its a usefule feature overcoming slow or non-existent feedback. In your case, it’s not useful - turn it off.

5

Where would I find this option?

6

The autoupdate feature is a kind of psuedo-binding. Like a regular binding, it listens out for commands to an Item, but then instead of sending them on to a device, it updates the Item directly.

So it’s applied per Item, as though it were a binding…
If using text file config, you put autoupdate=“false” in the binding parameters area { }.
https://docs.openhab.org/configuration/items.html#exception-autoupdate

What you do if using PaperUI, I do not know. I think you may be forced to used text files to get at this control.

7

Having looked at that, to my understanding it suspends the automatic updating of item states, instead offering only the event so rules can manually change the state via postUpdate() calls.

My issue is that the device reports a state change when actually no physical state change has occurred.

For example, the switch is ON according to OH (and physically on).

  • I turn OFF a switch that is currently ON, in the GUI or in a rule, it doesn’t matter.
  • Switch publishes a command event, an update event, and a change event.
  • Switch never turns OFF because it’s OFFLINE.
  • GUI and state of item shows as OFF even though it is ON.

Or, the switch is OFF according to OH (but physically ON)

  • I turn OFF a switch that is currently OFF, in the GUI or in a rule, it doesn’t matter.
  • Switch publishes a command event, and an update event, no change event.
  • Switch never turns OFF because it’s OFFLINE.
  • GUI and state of item shows as OFF even though it is ON.

There is no way for me to determine the correct state of the device, so any logic that relies on the state of the item is flawed.

When the node goes offline its channel states should all automatically change to undefined, or even better have a node offline event, this would at least give some clarity to persons trying to create rules based on item states.

8

Autoupdate : when a command is sent to an Item, originating from a user interface or from a rule, the Item gets automatically updated as though that command were an update instruction as well.

‘Ordinary’ update - when a binding receives or polls some information from a real world device, and updates an OH Item accordingly.

If you disable Autoupdate on an item, it will still be ‘ordinary’ updated by the real-world bindings (if any) that it is linked with.

If Autoupdate IS in effect, it will also generate an update from a command, which of course may trigger other rules.

It’s worth reviewing how your rules are triggered in this context. For example, with no autoupdate, a rule triggered on command is always in response to UI or another rule. And a rule triggered on update is always in response to binding/real-world change. That can be useful, and sounds like what you are looking for.

When autoupdate is still enabled, there can be problems with rules that look at the state of the same Item. For example, a rule triggered by a command to item X, might look at the state of X to decide what to do. But has the autoupdate happened already, or not? Sounds like you might be currently having this problem.

That’s up to the binding author. Not everyone wants that, and would rather some Items held their last-known state (e.g zwave battery devices reporting once per day and otherwise asleep). You can’t please everyone.

The new Modbus binding for example offers ‘last error’ channels which can be used to look for failed devices. You need to look at your particular binding closely.

People often make things work similar to the way you suggest with use of the expire binding, which can be used to set an Item to UNAV or similar if no updates arrive in a set time.

You’ll usually find you need to give some thought to startup conditions as well, when looking at this area. Is persistence restore on startup appropriate? What happens if the device is missing at startup?

I think there’s fair bit of useful talk to be found about detecting lost zwave devices in these forums.