Fibaro FGFS-101PLUS and the missing WakeUp CC

[AlCalzone]

@hanskroner Here's our first case study. A battery-powered Fibaro FGFS-101PLUS Flood sensor which doesn't react to the WakeUp CC:

Protocol info:

13:44:28.663 CNTRLR « [Node 065] received response for protocol info:
                      basic device class:    Static Controller
                      generic device class:  Notification Sensor
                      specific device class: Notification Sensor
                      is a listening device: false
                      is frequent listening: false
                      is a routing device:   true
                      is a secure device:    unknown
                      is a beaming device:   true
                      maximum baud rate:     40000 kbps
                      version:               4

zwave-js assumes: the device is not listening and not FLiRS, so it must support Wake Up (which seems not to be correct).

The NIF looks like this (no Wake Up CC):

13:46:10.622 CNTRLR « [Node 065] node info received
                      supported CCs:
                      · Z-Wave Plus Info
                      · Application Status
                      · Association Group Information
                      · Battery
                      · CRC-16 Encapsulation
                      · Firmware Update Meta Data
                      · Manufacturer Specific
                      · Powerlevel
                      · Security
                      · Multilevel Sensor
                      · Version
                      controlled CCs: (none)

---

The manuals however mention support:

and the device claims it supports version 2 when requested:

13:46:20.864 DRIVER « [Node 065] [REQ] [ApplicationCommand]
                      └─[VersionCCCommandClassReport]
                          CC:      Wake Up
                          version: 2
13:46:20.865 CNTRLR   [Node 065]   supports CC Wake Up (0x84) in version 2

---

Querying the values fails:

13:46:21.275 CNTRLR » [Node 065] retrieving wakeup capabilities from the device...
13:46:21.276 SERIAL » 0x0109001341028409253e30                                            (11 bytes)
13:46:21.276 DRIVER » [Node 065] [REQ] [SendData]
                      │ transmit options: 0x25
                      │ callback id:      62
                      └─[WakeUpCCIntervalCapabilitiesGet]
13:46:21.282 SERIAL « [ACK]                                                                   (0x06)
13:46:21.288 SERIAL « 0x0104011301e8                                                       (6 bytes)
13:46:21.289 SERIAL » [ACK]                                                                   (0x06)
13:46:21.289 DRIVER « [RES] [SendData]
                        was sent: true
13:46:21.304 SERIAL « 0x010700133e000002d7                                                 (9 bytes)
13:46:21.305 SERIAL » [ACK]                                                                   (0x06)
13:46:21.305 DRIVER « [REQ] [SendData]
                        callback id:     62
                        transmit status: OK
...
13:46:31.308 CNTRLR   [Node 065] Wakeup capability query timed out - skipping because it is not crit
                      ical...
                      
                      
13:46:31.308 CNTRLR » [Node 065] retrieving wakeup interval from the device...
13:46:31.309 SERIAL » 0x0109001341028405253f3d                                            (11 bytes)
13:46:31.310 DRIVER » [Node 065] [REQ] [SendData]
                      │ transmit options: 0x25
                      │ callback id:      63
                      └─[WakeUpCCIntervalGet]
13:46:31.313 SERIAL « [ACK]                                                                   (0x06)
13:46:31.320 SERIAL « 0x0104011301e8                                                       (6 bytes)
13:46:31.320 SERIAL » [ACK]                                                                   (0x06)
13:46:31.321 DRIVER « [RES] [SendData]
                        was sent: true
13:46:31.336 SERIAL « 0x010700133f000002d6                                                 (9 bytes)
13:46:31.336 SERIAL » [ACK]                                                                   (0x06)
13:46:31.337 DRIVER « [REQ] [SendData]
                        callback id:     63
                        transmit status: OK

...

13:46:41.344 CNTRLR   [Node 065] Timeout while configuring wakeup - have to try again next time

A wake up notification is also never sent.

---

So tbh I'm a bit confused which information to trust and how to talk to this device when it comes to Wake Up.

[hanskroner]

I believe the source of the confusion in this scenario is that the Fibaro FGFS-101 supports two different powering modes.

The FGFS-101's user manual section 5, page 9 explains that the product can be powered either by a 12/24V DC power supply or a battery. I believe the traces you're showing here to be from a product configured to use a DC power supply, and thus "always on." What's interesting to me is seeing the product reporting its Basic Class as Static Controller. I'm not yet familiar with the output produced by node-zwave-js - could you post the NIF as a raw byte string?

Z-Wave requires a node's NIF to be static, so any configuration that would change a node's NIF requires that the node be excluded from the network before the change occurs, and re-included with the new values. The user manual correctly describes this procedure. It also mentions the Wake-Up Command Class will only be supported when the product is powered by a battery. There does seem to be a Z-Wave Certification non-compliance where the device answers a Version Command Class query for the Wake-Up Command Class when powered by a DC power supply and not listing the Command Class in its NIF - it shouldn't do this and I imagine it's an oversight from the manufacturer that's worth reporting to them.

Excluding the product from its current network, resetting it, powering it exclusively from a battery, and then including it into a Z-Wave network should show the Wake-Up Command class as supported in the NIF. For comparison, I'd also like to see the NIF as a raw byte string when the device is powered by a battery.

This scenario is great at exemplifying one of the pitfalls a Z-Wave Controller can fall into when trying to implement support for a Z-Wave product in a device-specific manner, rather than by the information in its NIF and (potentially) Z-Wave Plus Info Command Class. Some products behave and expose themselves differently to a network depending on configuration or conditions at inclusion, despite having the same firmware version and model number.

[AlCalzone]

So, I've verified with the user who reported this. The device was never mains powered, always with a battery. He did several inclusion attempts, always with the same result.

Here's the NIF in binary form:

13:46:10.441 SERIAL « 0x01090141539c010407017a                                            (11 bytes)
13:46:10.441 SERIAL » [ACK]                                                                   (0x06)

and this is what zwave-js makes of it:

13:46:10.441 DRIVER « [RES] [GetNodeProtocolInfo]
                        payload: 0x539c01040701
13:46:10.443 CNTRLR « [Node 065] received response for protocol info:
                      basic device class:    Static Controller
                      generic device class:  Notification Sensor
                      specific device class: Notification Sensor
                      is a listening device: false
                      is frequent listening: false
                      is a routing device:   true
                      is a secure device:    unknown
                      is a beaming device:   true
                      maximum baud rate:     40000 kbps
                      version:               4

[AlCalzone]

This scenario is great at exemplifying one of the pitfalls a Z-Wave Controller can fall into when trying to implement support for a Z-Wave product in a device-specific manner, rather than by the information in its NIF and (potentially) Z-Wave Plus Info Command Class. Some products behave and expose themselves differently to a network depending on configuration or conditions at inclusion, despite having the same firmware version and model number.

I think this is one thing we should talk about. I might misunderstand you here, but zwave-js should primarily look at the information the device reports. Config files are used for things that cannot be discovered (like config parameter names, which associations should be assigned besides the Lifelinie) and compatibility issues.

[hanskroner]

So, I've verified with the user who reported this. The device was never mains powered, always with a battery. He did several inclusion attempts, always with the same result.

Here's the NIF in binary form:

13:46:10.441 SERIAL « 0x01090141539c010407017a                                            (11 bytes)
13:46:10.441 SERIAL » [ACK]                                                                   (0x06)

Not trying to nitpick, but to establish terminology: 0x01 0x09 ... is not a NIF. A NIF would be 0x01 0x01 ... and while its contents will be similar to the above, they're used for different purposes. What you're showing above is what I would expect to see as part of a controller replication process - transferring the network details from one controller to another. That is, one controller telling another controller some of the information on a node. What we want is the actual node telling the controller all of its information. Are you asking the device for its NIF?

If that is indeed the information the product is sending out, it looks like this in a frame format like the documentation's:

┌───────────┬───────────┬───────────────────────────────────┬───────────────────────────────────┐
│ listening │  routing  │           max_baud_rate           │          protocol_version         │
│  (false)  │   (true)  │           40 kbps (0x02)          │    ZDK 4.5x and ZDK 6.0x (0x03)   │
├───────────┼───────────┼───────────┬───────────┬───────────┼───────────┬───────────┬───────────┤
│optional_f…│sensor_100…│sensor_250…│beam_capab…│routing_sl…│specific_d…│ controller│  security │
│   (true)  │  (false)  │  (false)  │   (true)  │   (true)  │   (true)  │  (false)  │  (false)  │
├───────────┴───────────┴───────────┴───────────┴───────────┼───────────┴───────────┴───────────┤
│                          reserved                         │          speed_extension          │
│                           (0x00)                          │          100 kbps (0x01)          │
└───────────────────────────────────────────────────────────┴───────────────────────────────────┘

Pretty standard for a 500-series battery-powered slave device. Note that the 'controller' flag on byte 2 is unset, which means the NIF will not include the Basic Device Class byte. Above, zwave-js seems to think the device is a Static Controller - it might be reading this information incorrectly.

[hanskroner]

I think this is one thing we should talk about. I might misunderstand you here, but zwave-js should primarily look at the information the device reports. Config files are used for things that cannot be discovered (like config parameter names, which associations should be assigned besides the Lifelinie) and compatibility issues.

Sounds like zwave-js is doing the right thing then. From a Z-Wave Certification point of view, supporting the Wake-Up Command Class is mandatory for "Notification Sensor" device types when they are Reporting Portable Controllers or Reporting Sleeping Slaves (which this product is) - so it should be there. Off the top of my head, I don't remember what the Z-Wave Certification requirements are for the Wake-Up Command Class when a device supports security. It might be allowed to only support the Wake-Up Command Class securely when the device was included securely. This product supports S0 security, so if zwave-js supports S0 as well, it might have been included securely and the Wake-Up Command Class might only be listed as supported under the "secure NIF." This list of Command Classes that are supported securely is requested via the S0 Command Class, using the "Security Command Supported Get" Command.

All the other Command Classes are listed in the NIF, so I don't think this is what's going on. I don't have a FGFS-101 to verify what its NIF looks like when battery powered - it would be great if you can get someone else who's running zwave-js and has this product to provide the NIF. This product has been out and working for a while, so I'm leaning towards this particular user's device not recognizing that it's being powered by the battery properly, and thus configuring itself "wrong".

[AlCalzone]

speed_extension

I can't find any mention of this in the PDFs I have access to. Can you point me in the right direction?

[AlCalzone]

The mystery is solved... after some more reset attempts, it finally seems to have worked. The node gets included with a new node ID and responds to the Wake Up CC, which is now also listed as supported:

19:43:38.022 CNTRLR « [Node 066] node info received
                      supported CCs:
                      · Z-Wave Plus Info
                      · Application Status
                      · Association
                      · Association Group Information
                      · Basic
                      · Battery
                      · Configuration
                      · CRC-16 Encapsulation
                      · Device Reset Locally
                      · Firmware Update Meta Data
                      · Manufacturer Specific
                      · Multi Channel Association
                      · Notification
                      · Powerlevel
                      · Security
                      · Alarm Sensor
                      · Multilevel Sensor
                      · Version
                      · Wake Up