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.
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.
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.
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.
how can i sign in to have beta releases?
There’s a link in a previous beta thread
Cant find it(
The link is Hub Firmware 25.x Beta. However, we’ll be closing the beta soon and aren’t accepting new testers at the moment. Firmware 0.25.20 will be released to production shortly. Refer to Hub Firmware Release Notes - 25.20.
is anyone else seeing issues with z-wave thermostats updating the current temperature? Mine seems to be mirroring the setpoint.
Interesting - I think I did, but I literally just replaced both of my Evolve thermos with Pearls (zigbee thermos) about 4 hours ago.
Can you elaborate a little. Do you mean it’s setting the same for both heat and cool?
no, the actual temperature reported is the same as the setpoint. But i tested it some last night and it seems to be reflecting accurately what the thermostat says. So nothing weird going on after all.
Since 0.25.22 has now been released, please use this thread for future comments: