[ZWAVE] Why can a thing be ONLINE even though it's been unplugged for days?

[miwok (ND)]

The problem occurs not only at one node, but also at others. Battery-powered devides are a different matter.

OH 2.5.5
Z-Wave Controller: Aeotec AEOEZW090-C Gen5
About 15 Nodes (also battery devices)

For example: Node 2

This node has been in use for almost 2 years without any problems. It has been unplugged for several days and is recognized as ONLINE.

openhab> smarthome:things list | grep node2
zwave:device:ba89caaa:node2 (Type=Thing, Status=ONLINE, Label=Z-Wave Node 002: GWPN1 Single-socket PowerNode, Bridge=zwave:serial_zstick:ba89caaa)
openhab>

I use the status of a thing to set an “ONLINE” item, e.g. vZWaveNode2_Online. This is used in many other rules, which of course do not work reliably.

Example:

@rule("zwave node2 changed Status")
@when("Thing zwave:device:ba89caaa:node2 changed") 
def zwave_node2_erreichbar(event):
	LOG = logging.getLogger("{}.Jython_Andi.{}".format(LOG_PREFIX, rules_filename))
	if event.statusInfo.status.toString() == "ONLINE": events.postUpdate("vZWaveNode2_Online", "ON")
	else: events.postUpdate("vZWaveNode2_Online", "OFF")
	LOG.info("ZWAVE node2 - changed Status {}".format(event.statusInfo.status))

Is there an explanation for this unreliable determining the status of a thing? Is there perhaps someone who has or had the same or similar problem and maybe found a solution?

I am very grateful for every tip!

[rossko57]

@miwok

Is there an explanation for this unreliable determining the status of a thing?

Yes.
The Thing status does not represent the status of a real device. It represents the pathway to/from the device.
Thus, a battery device might be sleeping, but your zwave controller is alive, the configuration for this device is complete and error-free. Everything is in working order (Thing ONLINE) awaiting only the device to be awoken by an alarm or suchlike.

Never mind Things, what are you really wanting here? Do you want to know if you haven’t heard from a battery device for a long time, perhaps?

[miwok (ND)]

I don’t mean battery-powered devices. I’m just talking about mains-powered devices.

What I want:

• to know when my dehumidifier (controlled by Node 2) can no longer be switched on because Node 2 is broken, for example

As can be seen in the picture, Node 2 can be switched on, although it has not been connected to the power supply for several days. Is this behaviour normal and intentional?
It cannot be. I have no feedback from Node 2 as to whether the command was executed …

If this is the case, I can switch to 433mHz devices, then z-wave has not the slightest advantage …

[rossko57]

@miwok

As can be seen in the picture, Node 2 can be switched on, although it has not been connected to the power supply for several days. Is this behaviour normal and intentional?

Yes. perhaps its just sleeping, and will wake up when you send a command. This is a generic design philosophy, not all technologies are alike.

@miwok

It cannot be. I have no feedback from Node 2 as to whether the command was executed

That’s correct. But you do have autoupdate enabled on this Item. (It’s enabled by default).
In the interests of a snappy UI, it predicts the likely outcome of a command and updates the Item state.
If you don’t like that, disable autoupdate. The Item state will then only get updated when a “real” response arrives.

@miwok

to know when my dehumidifier (controlled by Node 2) can no longer be switched on because Node 2 is broken, for example

Is it polled regularly, or does it report unsolicited periodically? Then you can detect those periodic updates and ring a bell when one or more is missing.

The expire binding was created for this purpose, but there are other ways. The Item state UNDEF is useful in this context, to indicate “failed”.
This old thread covers the general idea

Expire binding does not expire when using longer intervals

Using openHAB 2.4.0 Release Build and Expire binding 1.13.0 which is just great! But, I have a z-wave wall socket that reports fine and has associations set and all …that has issues with the binding. When I set it to expire “2s, command=OFF” or 20m it just works. But 59m or 1h or more (longer intervals) it does not send command OFF it just keeps on going. I have looked in the logs and could not find anything suggesting it is updated during this period of time. Any tips ?

Or, you might start/restart a watchdog timer on each update. if that ever expires, ring a bell.

If you wanted, “ring a bell” action could include force disabling of your Thing. Might be useful where are several channels on a device, but the effect that has on any linked Items depends on the binding. You’d need to think about recovery too.

@miwok

If this is the case, I can switch to 433mHz devices, then z-wave has not the slightest advantage

If you like. It won’t change openHAB behaviour.

[miwok (ND)]

Many thanks rossko57! Some things are new for me, for example the thing with “autoupdate”. But I will have to think it all over again.

[rossko57]

Yeah, it seems like detecting a failed device ought to be easy, but accommodating things like sleeping battery devices means it is harder than you expect.
Even with using expire binding or rules, there is no easy-templating-generic method, again because of differences in technologies.

It’s a bit unfortunate that Thing status is represented as ONLINE/OFFLINE really, because that leads us to think it means something it does not. Not sure what else you could call it without the same suggestion though.
Let’s say we invent a Thing representing a wake-up WOL packet for a PC. So long as we have an ethernet connection, such a Thing should be ONLINE, ready to handle the wake-up command. Even if the PC has been stolen.