Fibaro smoke sensor (FGSD-002) / Not getting all values from the device

Add-ons Bindings
61

You need to use a persistence system to save/restore item states on startup.

62

Thanks @chris! Iā€™m actually persisting the alarm states.

However, the problem is that upon restarting openHAB (or the Z-Wave binding) I have no clue about the current state of the alarm.

Should I assume that the alarm is always OFF unless it is turned ON? In other words, the Z-Wave sensor wonā€™t report any alarm upon system restart unless an alarm is currently active? In yet other words, NULL state is always equivalent to OFF state for the alarm?

63

Unfortunately itā€™s impossible to tell as itā€™s not possible to poll ā€œNotificationsā€ in ZWave - they are real time reports only. So if the state changes while the binding is offline, then itā€™s not possible to find out what the state is and the binding cannot, and does not update it for this reason.

64

I see. And probably:

  1. the notifications are sent only once
  2. thereā€™s no way to reset any notifications to force the sensor to re-fire notifications for active alarms

Would there be a way to use the ALARM command class and to query the alarm states through ALARM GET?

65

Correct.

There is no such thing. There is only the NOTIFICATION command class - the binding (for historical reasons) call this ALARM, but it changed names a long time ago.

66

I was looking into the Z-Wave documentation.

Although marked as DEPRECATED, the ALARM_SENSOR command class (which is supported by my smoke sensors) seems to do what I need: according to the documentation it can be used to query the alarm state of a given sensor node.

In the NOTIFICATIONS command class I see that there are 2 (3) basic operation modes: PUSH (1 mode) and PULL (2 modes):

  1. A Push node sends unsolicited Notifications. It is not possible to subsequently retrieve Notifications issued by a Push node.
  2. A Pull sensor collects events and state changes in a queue of pending Notifications. Notifications are retrieved one by one from the Pull sensor queue via the Notification Get Command.
  3. A persistent Pull Notification is not removed from the Pull sensor queue until it is actively cleared by a controlling node.

And I suppose that this is what youā€™re referring to. Only in the 3rd case could the binding query the notifications.

67

Iā€™m aware of the different modes defined in the documentation, but that doesnā€™t really help. I discussed this issue with the ZWave Alliance a couple of years back and it was stated that this was not possible and not planned to be added. Iā€™ve not checked all the changes, so maybe this has changed and if you want to investigate further and provide a PR that would be great.

In general, I try to use the modern functionality supported by ZWave where possible. There are hundreds of different options and if I try and support everything then Iā€™m forever trying to add things to work around obscure issues like this. I agree that the protocol is lacking here, and thatā€™s unfortunate.

Iā€™ve not checked this specific device - if you find a better approach for polling, then please feel free to provide a PR and Iā€™ll be happy to take a look at it.