Zwave migration to Zwave.JS/Zwave2MQTT

Well, I finished the conversion yesterday and got my automations and lovelace dashboards completely straightened out this morning.

A couple of things to note for those trying this in the future. If you have zwave devices setup and are controlling them via an MQTT integration and are not going to use MQTT moving forward (this is what I had and I had manually created all my MQTT yaml configurations) you need to remember to either comment out or delete those from your configuration file/files.

Because I was running this in parallel with Homeseer and you can’t have two controllers (zwave stick) with the same device, I would remove a node from Homeseer then add the node in Zwave.JS/Home Assistant. For the last couple of devices they were too far away from the controller to remove the nodes in Homeseer. So I just shut Homeseer down and went to add them to Home Assistant. They wouldn’t include until I excluded them first (even though they have never been included in this particular controller).

Everything seems to be reacting/controlling just fine now. I am happy with the results. With that said I have 3 issues left.

1.) I have (3) Jasco switches that won’t update the UI when they are manually operated at the switch. They update correctly when controlled by Home Assistant both in the UI and with automations. I was told that it was because they were probably older “classic” zwave devices and not zwave plus. If you look them up they are zwave plus and according to the Homeseer implementation they provide instant status updates. They don’t in Home Assistant. I had to setup polling which isn’t very instant :unamused: I have emailed Jasco support but have not received a response. At some point in the future I will probably change these to TP-Link Kasa WiFi switches.

2.) I have a Trane XR524 Thermostat. Everything seems to be working as it should with one exception. In the UI it reports the current temperature in Centigrade rather than Fahrenheit even though all other figures displayed are correct and in Fahrenheit. If anyone has a suggestion on how to fix this I am all ears. You can see a pic of what I am speaking about in one of my previous posts in this topic.

3.) I have several Homeseer brand WS-100, WS-200, and WD-200 switches and dimmers. They report to Zwave.JS that they are “scene capable”. Yet there is no entity created to control. In Homeseer it created a separate device (entity) and you had I think 6 combinations. 1 tap up turns the switch on, 2 taps up and 3 taps up could each trigger automations. 1 tap down turns the switch off, 2 taps down and 3 taps down each could also trigger automations. This was a really useful feature. I hope the developers are working on a way to make this available in Zwave.JS. I will miss it until they do.

So the steps I followed after I had ZWave.JS installed are:

  1. Open both Homeseer and Home Assistant in separage browser windows.

  2. In Homeseer find the device your going to move (I worked nearest to controller to farthest from controller) and exclude the node from Homeseer.

  3. In Home Assistant go to your configuration file and comment out the device’s configuration. Save the file.

  4. Go to Configuration, Server Controls, and re-load “manually created MQTT yaml”.

  5. Go to Configuration, Entities, filter on MQTT, and delete the entities you just commented out. If you want the new entities to be the same name as the old entities then make note of them before you delete them.

  6. Go to Configuration, Integrations, Zwave JS and click configure. Then click add node and decide whether it will be “secure” or not and click start. Go to the device and do as the mfg suggests to put it in inclusion mode.

  7. If it completes without error in the dialog click view device and then close.

  8. On the device page rename the device at the top of the page, I let it rename all the entities. Even after it renames the entities you may want to edit the entity names.

If you kept your entity names the same as they were before then your lovelace dashboards, your automations, and your scripts/scenes should be fine. If not you will need to edit them all for it to display and work correctly.

I was beginning to run into issues with Homeseer not updating the MQTT topics correctly. So this excercise is well worth it. The additional benefit is that I don’t have to keep 2 separate systems updated and Homeseer costs money and Home Assistant does not. Homeseer is designed to run in Windows and not as a service, so you had Windows issues to deal with also. I like my Home Assistant on my RP4.

If anyone has any questions regarding the new Zwave.JS implementation it is pretty good. I am sure as time goes on it will get even better. I wouldn’t hesitate to recommend someone install and use this for Zwave devices in Home Assistant.

Regards and thanks to all who responded to this post and provided input, I greatly appreciate it.

Good, glad you got it working

A switch will never include to a new network unless it is excluded from the old one or factory reset. There’s another quirky thing about zwave with excludion. If you activate “exclusion” on any zwave controller, and then exclude at the device, the device will exclude from whatever network it was in previously even if it never had any prior relationship to the new controller. I guess they do this in the event your old controller dies so you have a way to still exclude switches without factory resetting them, but it seems odd to many.

You should be able to create an entry in your config.yaml to override this - Setup basic information - Home Assistant

Scenes from Zwave devices don’t actually create new entities in Home Assistant. They fire “events” on the zwave_js_value_notification when they are activated. So you can listen to these events in developer tools, then create automations when these events happen to use the double, triple taps, etc. I actually use Node red for this - if you’re interested I can post the flows. Here’s more info in the documentation on it:

Yeah I posted that above. A couple other things could be going on here:

1- Jasco was notorious about reusing model numbers for different switches. Its possible they had a 14318 switch that was not zwave plus, then released a zwave plus switch and just reused the model number. Its very confusing, but their support hopefully can confirm for you.
2- It is a zwave plus switch, but the configuration being associated to the switch in zwavejs2mqtt is the wrong one. I used to work on device handlers in Smartthings for these switches and because of the way Jasco messes around with the model numbers it makes it very hard for software to identify exactly what kind of switch you have and match it to a configuration. If that’s the case there’s a way to override the configuration and use a “custom one”, but I’m not quite sure how to. There’s documentation on it in the zwavejs2mqtt website. https://zwave-js.github.io/zwavejs2mqtt/#/development/intro?id=testing-custom-devices-config

You could also try and listen to the zwave_js_value_notification event and see if anything happens when you click that Jasco switch on that even, and then do an automation to trigger a poll/refresh of the switch when the event is fired for faster updating.

First @mwav3 Tim, thanks for your help and explanations. 1 problem solved, 2 to go.

1.) On the Jasco 14318 Switch, trying to override the configuration with a “custom one” is way beyond my skills. I did however operate the switch while in Developer Tools listening to the zwave_js_value_notification event. Nothing posts when I turn the switch on or off manually at the switch.

2.) On the Homeseer switches and their use of the “Central Scene” command class. Listening to the zwave_js_value_notification event posted data :grinning: I was able to utilize this to create an automation on a double click that worked correctly :joy: So now I can recreate what I had setup in Homeseer. I also have some new ideas for this feature. Many thanks.

3.) Regarding the Thermostat. I have a custom config setup in my configuration file, just things like lat, long, time zone etc. I already had the line

unit_system: imperial

and I added the line

temperature_unit: F
to no avail.

What is interesting is that in the json that is sent from the thermostat to Home Assistant it has the line

current_temperature: 23

When you convert that to Fahrenheit it comes to 73.4

When including this device it created another entity that is

sensor.thermostat_air_temperature

and its state is 73.4

I am wondering how I might get the standard lovelace thermostat card or another to use this value instead of other. If I was able to do that I don’t think it would affect the operation as they should stay in sync, just one in C and the other in F.

Got any ideas?

Again thanks for your help!!!
Chuck

One last thing to try for the GE switch. Is node 1, which is the zstick, showing in the “lifeline” association group? That’s how it sends status to the hub and may not have been configured properly when it was included. It should be automatic, but sometimes it doesn’t. Go to the device, then groups. If not there, you can add it manually

@mwav3 Tim, your screen shot appears to possibly be the zwavejs2mqtt control panel. I did not install zwavejs2mqtt. I installed the official zwavejs add-on only.

Can I now (after I have already installed zwavejs) add the zwavejs2mqtt add-on without messing up my zwave setup?

Just as an aside still haven’t heard back from Jasco Customer Service.

Regards,

Chuck

Yes it is zwavejs2mqtt. The zwavejs interface does not yet have all the features, like setting associations, force removing nodes, and healing individual nodes that are available in the zwavejs2mqtt control panel. They are getting there with each new release, but you still cannot fully manage your zwave network through the zwavejs interface in Home Assistant.

We had a recent discussion about switching on this thread - it looks possible but you have to find some files and move them around

Update- looks like you can heal an individual node and force remove now, but I still don’t see association setting in zwavejs

Screenshot from 2021-09-02 15-30-57

@mwav3 Tim, Yeah I thought so. I think I am going to give up on the Jasco switch issue for now. I can get a 3 pack of TP-Link Kasa Wifi switches for $39.99 prime delivery tomorrow from Amazon. A 3 pack of new Jasco #14318 Z-wave plus would be $144.40. My preferred Zwave switch is Homeseer’s WS-200+ and a 3 pack from them would be $139.00.

With the proliferation of zigbee and wifi Home Automation products whomever is getting rich off of Zwave needs to re-think what they are doing. I can’t justify spending prox $150 vs $40 for the same functionality. I know that zwave and zigbee are more secure etc etc. But $100 premium is too much for me.

On another note. I contacted Trane customer support regarding my XR524 thermostat issue and the display of celsius vs fahrenheit. They have no technical support help either via phone or email. I was told to contact an authorized Trane installer. Unbelievable that they will sell these products through online resellers such as Amazon and Homeseer, big box stores such as Lowes and Home Depot yet not provide any tech support.
I had a new Trane HVAC system installed this year. We left my XR524 in place rather than install their Nexia tied thermostat. I guarantee you the technician they sent out to install my system did a great job putting in the furnace, coil, and condenser. I am sure he could have installed the Nexia thermostat. But he admitted that he didn’t know much about Z-wave. So how much help will they be for something they didn’t install???

Been frustrating for me today.

Regards

Chuck

Zwave does offer other advantages. It’s on a totally different frequency then zigbee and wifi, so less interference. It’s standardized and products need certification. This standardization allows for scene control, with the double and triple tap. You also have added range and devices mesh with eachother to form a solid and reliable network, where devices act as repeaters. I really like the Inovelli red switches- you get scene control, led notifications, and energy monitoring. They’re popular so sometimes tough to get a hold of.

https://inovelli.com/red-series-dimmer-switch-z-wave/

But with that certification comes licensing fees and added costs, and it’s becoming tough to justify the price difference. Many are buying cheap chips and flashing esphome. I am about to buy this zigbee sonoff mini. It goes behind a normal rocker switch, and is only $14.

https://www.amazon.com/dp/B08MJL8G3C/ref=cm_sw_r_apan_glt_fabc_KBEQSQ97B6AWEXAT4T2K?_encoding=UTF8&psc=1

It depends on what features you want and what’s important to you.

I have a feeling that can be fixed with a custom template or custom Lovelace card. Maybe you want to start another thread specifically on that issue to get some more ideas for a fix?

@mwav3 Tim, I had seen the name inovelli but never explored it. That Red Series switch and dimmer are very similar to Homeseer’s WS & WD 200 series and a little cheaper than Homeseer’s.

The only Zigbee I run is some Phillips Hue bulbs. I have their Gen2 (square) hub. I use them in floor, bed, and desk lamps that aren’t controlled by a wall switch. We mostly use Alexa voice control for on/off and dim control.

My concern with something like the Sonoff you show and also the Shelly wifi that I have some experience with is that I don’t think I could fit that in the same box as the switch. It is difficult enough to get a smart switche in there let alone a separate box behind a standard Decora switch with all the wire behind the switches. If you go up in this post you will see how I wired the Shelly’s into my new garage circuits. I put them in a separate box (plastic - trying to minimize interference of the wifi signal) so that the actual box with the outlet wouldn’t be too crowded.

I will start a new thread on my thermostat issue. See if anyone can help with that. I am not real good with templates. I also would think that the modification would have to be in the lovelace card yaml configuration as I don’t know where else you would do it.

Good to converse with you and thank you for your help with my issues. I learned something new from you:

Developer → Events → Listen → zwave_js_value_notification

I have already duplicated the setup I had before and am beginning to define new uses for the double and triple taps on my switches.

I don’t know what it would be but if I can ever try to help or answer a question just send me a PM.

Regards
Chuck

1 Like

This is wrong. The instant update patent was held by Insteon, and it expired before Plus came out. Smartthings just polls non-zwave plus devices (aggressively at that, every 5 seconds or so), which you can do in zwavejs too. There were no special arrangements with Smartthings or anyone else.

Our default is to not poll, but you can do it. You need to switch to the zwavejs2mqtt addon to access it. Or setup an automation that just refreshes the values on whatever schedule you like. They work the same way.

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.

If you’re interested the Hail CC is defined on page 111. https://www.silabs.com/documents/login/miscellaneous/SDS13782-Z-Wave-Management-Command-Class-Specification.pdf

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.

2 Likes

@crudolphy Actually, @mwav3 may not be crazy on the Lifeline group. There is a narrow chance we are missing that, but it is possible as we are relying on the device reporting the association group (Association Group Info CC). I suppose they could be just as wrong on that one as on the zwave plus one. https://github.com/zwave-js/node-zwave-js/blob/c0655be12a65f105fdc48986c4b7e858568acfce/packages/config/config/devices/0x0063/jasco_14318.json. The log file would tell us this.

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)

We may actually already do that, I’m just not sure.