SmartThings Community

Hub Firmware Beta 0.25.20

@Kianoosh_Karami, BUG-0045 just submitted.

I’m sitting here at work and got a push notification that my garage door opened, but it’s really closed (verified through other sensors). Here’s a snapshot of the device’s event log:

It’s as if the ping that triggered the offline status then triggered the open state, and then shortly after that an online status update triggered a closed state.

This happened 15 minutes ago btw.


Based on the radio logs. The device was pinged and responding with 0xFE status which means that the garage door is opening, but at a later ping, the device says that it is indeed closed.

That is what the device is reporting, so I am not sure what we can do with respect to faulty status.

1 Like

I tried this morning using the latest app and it did not work:

What would be ideal is if during a network repair, the hub also refreshed the device meta data, or if that can’t be done, having a separate “Refresh Z-Wave Device Info” utility that could be run across the network, or even better if per device.

It is my understanding that the device sends the node information frame only during inclusion so such a utility may not be possible. Also, it would be a patch to some other issue. In my case it may be traffic overload on the zwave mesh network. I’ve tried to limit it as much as possible but the inclusion issue still happens.

You can do a Scan General on a device with Z-Wave Tweaker and get up to date node metadata, so I know the info is available post inclusion. The main “non patch” use case being updating the device info on replaced devices.

I looked into it a bit more and found that it can be requested at any time by the controller as you were saying:

To obtain node-specific information, Z-Wave uses a node information frame . This frame is part of the Z-Wave protocol and specifies the capabilities of the node. These capabilities are the node type, whether the node is able to repeat frames, and other protocol-relevant issues. The node information frame also contains the Home ID and the Node ID.

It is possible for the application to ask for the node information frame from all nodes in the network and hence enable any node to acquire information regarding any node’s features in the network at any given time.


However, in my case, it is a sleepy battery operated device so it would likely be a hit and miss repair or worse. Still better than nothing…

While that is true that we can ask for the Node Information Frame at any given time past inclusion, we at some point have to create the device record and if we have exhausted all the attempts to get the node information frame or other commands without any luck, then we have to fill the fields with 0s unfortunately.

I am not saying it is ideal that we give up on the device after the inclusion, but I would like to solve the problem of why the device is not responding to messages at inclusion time.


Wholeheartedly agree. You mentioned to me that the hub missing the NIF might be due to excessive traffic on my network. While it may be obvious to your trained eye when looking at the logs, it may not be for the average user. Is there any way for the platform to rate the traffic level so the user can be aware, take corrective action and see its effects? This helps us help both you (less traffic) and ourselves (less issues).


Wow, that is a really good idea. I will make an internal ticket about your suggestion and perhaps find a way to expose that info to the user.


On a related note. If the DTH does request a NIF from the device, if that information wasn’t available while pairing you said it fills the info with 0000. If the NIF comes in later does the platform update the information? I’m thinking about FLiRS devices and listening devices. I have seen this happen in the past with switches, thermostat and locks also. However the DTH could be modified to send a NIF request after say 60 seconds if it detects that the information wasn’t available to it when configure was called. For sleepy devices it could be request at the next wake up event.

1 Like

This should be a simple thing to do. A small bit of logic added to the refresh() method that calls


anytime the MSR is all zero’s. (or possibly manufacturerSpecificV1 depending of the device)

That’s easy and many DTH’s do that already however he does not update the zwInfo field which still shows 0000.

So I was asking what command response would cause the zwInfo field to be updated?

Many DTH’s including the stock ST DTh’s use zwInfo to decide how to take actions for a range of things from security to model specific decisions.

1 Like

We currently do not support the ability to update the zwInfo field after the device has been created.

Having a “refresh” button under the device Data or Raw Description to force update of the data in the node frame would be great, aside from failed inclusions, it would also be helpful for replaces of similar devices, or out of band firmware updates.


Is it feasible to detect during inclusion that the NIF was missed (or corrupted) and send a request for it again before setting up the device?


With a sleepy device it may go to sleep before the request can be completed. I was suggesting that if a NIF is not received leave the configuration open to updates. At the next wake up send a NIF request or got active devices request it right away and the update zwInfo and the configuration once the response is received. Then close the configuration to prevent further updates. This would resolve the issue of missing information and also preserve the current logic of sealing the database, it’s just a delayed sealing until a valid NIF is received.

1 Like

What is the logic behind “sealing” the DB? How should firmware updates be handled that change the NIF or device replaces where a switch might be replaced by another switch, but from a different vendor?

I.e. Closing the DB to updates. This is the current logic as posted above:

I’m suggesting hold on until a NIF is received before closing it for updates.

Understand that they don’t support it… I’m just wondering if there is a rational why or it just hasn’t been something that was implemented.