This can’t happen with zwavejs…losing zwave plus due to the file. We poll the command classes from the device and query the parameters. Our device files don’t define whether they’re plus or not. Unlike the handlers you worked on, ours mainly just exist to change the labels to something more readable. Modern devices will even function equally if they still say Unknown.
We also don’t use the model number as part of the fingerprint. It does happen where they reuse the same productType/productId but then we distinguish by firmware version. Even if that was wrong, we’d get the parameters wrong but the device would still otherwise function the same way.
Apologies it looks like I might have mixed up companies here on the patent, but this was not just blindly pooling every 5 seconds by Smartthings. Those switches updated instant on Smartthings and even a 5 second poll, which is aggressive as you pointed out, would result in a delay. So my patent thing is off, but your blind polling explanation is not quite right either.
According to a very well respected poster and former network engineer “SmartThings added in a form of efficient communication specifically for those GE switches to keep the status current. It’s not quite polling because there’s an initiating event at the switch”
There are 2393 device config files in the .config-db database. You-re saying it’s impossible the software will pick the wrong one? How exactly does the software chose which config to apply to what device ?
What’s the point of having device configs If they have no effect on function? I’m sorry I’m not trying to spark an argument here, I’m just unclear on some of the things you mentioned here.
I’m trying to offer the OP suggestions on why a zwave plus switch wouldn’t update its status. I also suggested maybe the lifeline association wasn’t set right. Do you have any other potential solutions you can offer?
I’m sorry, but that is wrong. You’re misreading his post. He is talking about device manufacturers licensing the patent, which some did (GE did not). That was before the patent expired and had nothing to do with the controller.
It isn’t even the Hail command. Devices send Hails, and when they do we react to them and poll the device. The Hail is a spec provided command class. I know, because I helped write and test that particular code, and it was originally added at my request. feat(cc): implement and handle Hail CC by AlCalzone · Pull Request #1308 · zwave-js/node-zwave-js · GitHub. What JDRoberts is describing is this functionality being added to Smartthings (just like we did), not the polling used for devices that don’t send Hails, like OP’s. If it sent a Hail we would immediately poll the device and this would be reflected in the log.
I added many of those files. We select the file based on the manufacturerId, productType, productId, and firmware version reported by the device during the interview. It is possible that the manufacturer goofed and reported the the productType/productId for two generations of the same model, indeed that is somewhat common. It doesn’t matter because the parameters stay the same and we poll the command classes during the interview. It would matter if the parameters changed, but I’m not aware of any that have done so.
The files exist first and foremost because the spec doesn’t provide for a way for a device to provide its model name/number. We have no choice but to display Unknown, and users hate that. Cleaning up the labels and providing drop-down choices are very important for the UIs that use the driver, as the manufacturer provided ones are terrible. We also use them to house links to the manual and inclusion/exclusion/reset instructions. Finally, in the rare circumstance where we need one, they provide the compat flag that forces particular functionality (deletes a malfunctioning command class, etc.)
This is unlikely (but possible), as we automatically clear and re-establish the Lifeline group if need be. There is a very narrow circumstance where this could happen if the device did not support the right version of the Association Group Info and we missed including the association groups in the device file, but that is unlikely as we parse the files off the zwave alliance certification database to error check them. Edit: It is also possible the device is misreporting its association groups.
I did offer a solution in another post. The device needs to be polled. It isn’t zwave plus, and if its supposed to be, it isn’t advertising that command class as being supported.
I agree this is probably not a zwave plus switch, and jasco mislabeled products all the time. I still dont understand why this device updated instantly in Homeseer, and did in Smartthings. Polling, even if aggressive, doesn’t explain that. I originally thought it was a hail and JD corrected me that it wasn’t.
I feel we are both missing something here.
Also, I have a remotec zfm80 where I had to manually add association group 1 for status, so can confirm personally this happened.
As far as your other comments, I do appreciate them and the help on understanding more about what is going on “under the hood” in zwavejs2mqtt. I am impressed by the software and thanks for your contributions and hard work.
If you want, we can take a look at why this isn’t updating. We need a Silly level log from zwavejs during the device interview and during a manual operation of the switch. If a message comes in, we’d log it.
I’m happy to discuss, and I’m not trying to be a dick. There is a lot of misinformation about how zwave works that isn’t supported by the specs. Hubitat even says (or said) that zwave networks healed themselves over time, and that’s wrong too (as confirmed by SiLabs). If need be I can ask Aeotec how Smartthings handled it, as Aeotec now makes their hubs and we work closely with Aeotec’s engineers.
If OP wants to post a log we can take a look at what is going on. We log all incoming messages. It is strange, I agree.
It is possible they were cheating and associating the controller to Group 2, then reacting to the Basic Set. We don’t do device-specific workarounds like this, though it could be done in a custom configuration file telling zwavejs to treat the basic set like an event, then refreshing based on that event.
You can’t presently change associations in the straight zwavejs addon. You’d need to be running the zwavejs2mqtt one for us to take a look to see if its setup correctly (and to fix the file).
Would it make sense to just always attempt to add the hub to the lifeline association group 1 at inclusion, regardless of getting an association report or not? I think this is what most of the other hubs do. I’m sure devices are out there that don’t send the association report but have a group 1 association group. If it fails to add it just ignores it and moves on, but prevents the opposite situation where it isn’t associated
I know there’s some older switches that used group 1 for other things before lifeline came out this could mess up, but I think those are few and far between. The user could always change those later if they notice odd behavior ( with zwavejs2mqtt of course)
@blhoward2, I have a question. As stated I have installed and am running Zwave.JS not Zwave.JS2MQTT. Even though I have the Mosquitto broker setup I don’t want to subscribe/post to MQTT.
What process do I have to go through to install Zwave.JS2MQTT? Can it run in parallel with Zwave.JS or are they mutually exclusive. Do I have to un-install Zwave.JS and then install Zwave.JS2MQTT?
I don’t mean to be a pain but please be as detailed as you can.
You would run it instead of the zwavejs addon, but use the same integration. It’s the same zwavejs driver and socket server, it just adds a more developed UI and optional mqtt. It’s very little difference in overhead.
You would run it instead of the zwavejs addon, but use the same integration. It’s the same zwavejs driver and socket server, it just adds a more developed UI and optional mqtt. It’s very little difference in overhead.
Sorry for being thick headed. Do I need to un-install ZwaveJS first or can I install ZwaveJS2MQTT and leave the ZwaveJS installed?
Only one can talk to your stick at a time. You have to shutdown the zwavejs addon first and disable it. You won’t lose your current device naming as long as you don’t remove the integration. I believe someone may have linked to the instructions to switch earlier.
@blhoward2, OK, I found it after your Edit. It is not a gear but as far as I am concerned it is really buried in the UI. Can’t attach a file to these posts and can’t do a copy and paste of this log because it exceeds the 35000 character limit. My email is [email protected]. Email me and I will reply with the downloaded file attached.
Let’s just open an issue on this and you can post it there. Make sure it’s not the HA log as that’s not helpful. I edited as I’m not sure the gear one is right.