NULL is a special state that indicates that the Item has never received an update. So either the device has never returned a value for the alarm channel or the database entry for that device is wrong and it doesn’t really have an alarm channel. If I recall correctly, there is a generic alarm channel in zwave to indicate the device has been tampered with and another smoke alarm channel.
At this point I think you’ll need to put the binding into debug mode and capture some of the messages that are generated by this node and see what’s being sent.
You also might try manually pressing the test button on the alarm to make it go off. On some models that will cause it to report back to the controller even though it’s a test.
Is the device changing into alarm state? Ie is there a heat alarm active since the binding started? If not, then it’s not possible for the binding to get the state if the device doesn’t send the information to the binding. Unfortunately it’s not possible for the binding to poll for the state of alarms (on most devices) - they are only sent as notifications when the state changes. If the state is not received, then as Rich said, the state is null.
So any Z-Wave device that can generate an Alert will only send alert triggered and alert cleared messages. A NULL state simply means that no alert messages have been received yet.
That is of course a weak point of Z-Wave for alarms as there’s no way to know if an alert is active when a system restarts. Ideally such devices should report active alerts when polled or when they issue a message. I understand that this is not the case (likely by design of the Z-Wave standards).
I agree - I had this discussion with the guys at the Alliance a couple of years back and their opinion was “why is that a problem”. It’s not really nice not to be able to read the state, but unfortunately this is the way ZWave works.
That’s not really correct. ZWave defines how things work - not just the communication. It’s done this way to (try and) ensure that devices operate consistently.
Of course it’s possible that manufacturers can add their own manufacturer specific functionality to do whatever they like, but this won’t work with the majority of hubs if they don’t conform to the standard functionality.
Sure, but any serious “life safety” (e.g. fire alarm) system should provide integrity checks, or it’s just a toy. Note, that’s the system, not specifically the sensor. In openHAB then, it might be down to us to add the necessary smarts.
In the smoke alarm case, we can make inferences - if the device is making regular “battery OK” reports, even if we cannot read a “smoke OK” status we can make the inference that as the device and communication path is alive, then if it had something to say it would have said it.
It’s up to use to manage that with rules.
If you keep rebooting the system and are worried you might have missed an alarm event - that’s the fault of the overall system design or use, not the sensor. For example, maybe the sensor event should be directly setting off an alarm sounder over zwave. Can that sounder status be read from a rebooted openHAB?
“But I powered my zwave controller off as well!” - well don’t do that. If its that important (life safety) then the system design is at fault - it should be independently powered.
True, but that’s not the point here. IT has been stated many times, and I think written in the Z-Wave docs, that Z-Wave should NOT be used for safety of life applications. I think it’s also stated like this in OH documents. So it is supplementary information and should not be relied upon as the primary notification.
That doesn’t mean it shouldn’t work!!!
But again, that’s not the point. The point here is that it is not possible to read the state on startup, so the state is NULL. So you point is that if the device is sending battery notifications, we know it’s alive - true - but we still do not know if the door is open or closed, as we can’t read the state of the door sensor. If we miss the notification for some reason, then we just don’t know the state.
Sorry - I disagree. A sensor should have the ability to read its state.
No - this is the whole point that was made earlier. This is why the state is null - it is not possible to read the state back from the device.
That’s probably a liability problem. Sun Microsystems (now part of Oracle) also put a massive disclaimer on allowed uses of Java.
The smoke detector manufacturer must ensure their products comply with the regulations of the markets they serve. Fortunately there are widely adopted standards that define their operation.
If a smoke detector manufacturer decides to add Z-Wave to their detector, then the liability remains at the manufacturer, not the Z-Wave alliance.
On a personal note, I think Z-Wave not reporting alarm states can be overcome but it is rather a big nuisance: you need to manually inspect your entire home upon a systen restart to confirm alarm states and contact states. To my eyes this is a key requirement.
That nuisance may eventually result in me choosing a different wireless technology in the future.
But a smoke detector alone is not a “fire alarm” within the meaning of any regulations, any more than a fly detector would be. So there’s no ‘must’.
Topic touched on here -
It’s possible to make standalone units or sub-systems that comply, and happen to have zwave capability as an ‘extra’.