Fibaro FGSD-002 alarm Items invariably report NULL state

If I link an Item to any of the alarm channels of my Fibaro FGSD-002 smoke detectors (version 3.2), the state returned is always NULL.

This was already the case on openHAB 2.5 but it still remains true on openHAB 3.

See for instance the result of querying the REST API (as is done through nodeRED):

{
  "link": "http://localhost:8080/rest/items/ZWaveNode012FGSD002SmokeDetector_LowBatteryAlarm",
  "state": "NULL",
  "stateDescription": {
    "readOnly": true,
    "options": [
      {
        "value": "OFF",
        "label": "OK"
      },
      {
        "value": "ON",
        "label": "Alarm"
      }
    ]
  },
  "commandDescription": {
    "commandOptions": [
      {
        "command": "OFF",
        "label": "OK"
      },
      {
        "command": "ON",
        "label": "Alarm"
      }
    ]
  },
  "editable": true,
  "type": "Switch",
  "name": "ZWaveNode012FGSD002SmokeDetector_LowBatteryAlarm",
  "label": "Low Battery Alarm",
  "category": "LowBattery",
  "tags": [
    "Energy",
    "LowBattery"
  ],
  "groupNames": [
    "ZWaveNode012FGSD002SmokeDetector",
    "gPersistEveryChange"
  ]
}

For what it’s worth, the related Thing has the following configuration:

UID: zwave:device:controller:node12
label: "Z-Wave Node 012: FGSD002 Smoke Detector"
thingTypeUID: zwave:fibaro_fgsd002_03_002
configuration:
  action_failed: false
  action_heal: false
  action_reinit: false
  action_remove: false
  binding_cmdrepollperiod: 1500
  binding_pollperiod: 3600
  config_1_1: 2
  config_2_1: 3
  config_3_1: 7
  config_4_1: 3
  config_10_1: 0
  config_11_2: 255
  config_12_2: 0
  config_13_1: 0
  config_14_1: 15
  config_20_2: 3
  config_21_1: 1
  config_30_1: 55
  config_31_2: 1
  config_32_2: 180
  group_1:
    - controller
  group_2: []
  group_3: []
  group_4: []
  group_5: []
  node_id: 12
  wakeup_node: 1
  wakeup_interval: 21600
bridgeUID: zwave:serial_zstick:controller
location: Hall (1st floor)

I only use lifeline group 1, which works for reporting temperature updated and battery level.

How can this be solved?

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.

What are the available channels on the Thing?

Hi Rich,

The channels are given in the screenshot below:

Here’s a detail on the Heat Alarm channel (which is linked to Switch item L1_Hall_SmokeDetector_ZWave_HeatAlarm:

I believe that the Z-Wave binding never returns the actual alarm channel values. Maybe it is a misconfiguration issue, but I have no clue.

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.

Thanks @chris for this clarification.

Makes perfect sense.

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).

How each device behaves is up to the makers, often with some choices for the user. Zwave just provides the communication medium.

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’.