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?
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?
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 …
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.
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.
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
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.
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.