Is there a downside to Zwavejs2MQTT?

I have Zwave js working well finally. I need a few enhancements to make it better like: 1) kill dead nodes, 2) heal the zwave network, and 3) set a few parameters on an Aeotec TriSensor. I understand that Zwavejs2MQTT might take care of some of these needs. Is there a downside to installing Zwave2MQTT alongside zwave js? Is the installation of Zwave2MQTT any different if I already have zwave js installed and running?

I assume you are referring to having the zwavejs integration installed along with zwavejs2mqtt?

If so I don’t think there should be any issues.

But you can’t have the zwavejs add-on and the zwavejs2mqtt add-on running at the same time since you can only have one accessing the controller at a time.

THe only downside is if you already have all of your stuff renamed from the zwavejs add-on then you will have to repeat that when you switch to the zwavejs2mqtt add-on.

2 Likes

Renaming 15 devices and over 100 entities is a major deal.

Let’s say that I stop zwavejs and start zwavejs2mqtt. I then go through all the renaming in zwavejs2mqtt. Do I loose all of my zwavejs names? Let’s say that I then stop zwavejs2mqtt and start zwavejs, do I then have to rename the zwavejs devices and entities all over again?

TBH, I’m not sure. I only run the zwavejs2mqtt docker container.

in one of the other threads on the topic of zwavejs it was mentioned that you can copy over the db from one add-on to the other but I don’t think anyone ever definitively said where to find the files in the add-ons (I don’t run add-ons so I can’t help with that).

But, supposedly if you do that then you shouldn’t need to rename anything since the data supplied by both servers should be the same.

try a search for that to see what you can come up with.

Renaming 15 devices and over 100 entities is a major deal.

It is and it isn’t… if you have decent system/method it doesn’t take long (I’ve got 67 devices and 370 entities on my Z-Wave network)

ZWaveJSMQTT is the same backend/driver as ZwaveJS so if you’re not in a rush just sit tight and wait for the developers of the integration to implement the features that you’d like to have.

I run ZWaveJS2MQTT on a stand-alone PI as my Z-Wave Interface but from an integration standpoint I use the standard ZwaveJS integration in HA. The only reason I use ZWaveJS2MQTT is the GUI, logging, added functionalities for setting parameters, etc. I do not use the MQTT part of the integration (offers no benefits to me).

If you’re concerned about renaming, just make a backup and try it, worst case you can still set your parameters and kill the node and since that information resides on the controller/device themselves you won’t loose those changes by reverting back to your old backup.

You shouldn’t have to rename if you switch between them. You do have to go through the same process of waking each device up. In the end, if all the devices match your previous devices, then the unique_id’s under the hood should take over and link the new devices to the old devices. If you’re impatient and muck with things before zwavejs2mqtt finds all the devices, you’ll have to rename things.

If you’re running supervised (NOT HassOS), you can just move the cache file over before starting and it’ll just work as expected without any fixes.

2 Likes

@petro Do you think you could create a guide for switching from zwavej2 to zwavejs2mqtt when you have time? Specifically referring to these cache files? I had a real hard time finding these files and ultimately didn’t need them… Your other guides have been WONDERFUL. So many thanks.

FWIW, I just switched from zwavejs to zwavejs2mqtt for many of the same reasons others have quoted (specifically I had a dead node I needed to remove).

Anyway, I think I have the change complete, but for some reason, I cannot delete the original add-on. It keeps coming back from the dead, despite multiple host reboots, multiple deletes.
Does the zwavejs2mqtt add-on install two add-ons? I think not, but cannot figure out why I can’t get rid of the original zwavejs add-on.

The integration shows it’s referencing the zjs2m add-on.

After a reboot, there is no zjs add-on.
After about 5 minutes, the old zjs add-on just reappears.
(Have screenshots for this, but cannot add more than one to a post. Fun.)

Any experience with this?
Wondering if I need to get to the command line for HA and delete the old containers… ?

What steps did you do to install the zwavejs integration? Specifically did you check the box that says to use the supervisor add-on?

If so then that is the expected result.

If that’s the case then you need to uninstall the zwavejs integration and re-install it without checking that box.

Unfortunately it is not really up to par yet…

Note: every " Unknown manufacturer 0xXXXX / 0xXXXX / Unknown product 0xXXXX " should be "Fibargroup / Metered Wall Plug Switch / FGWP102 ". Scratching my head what the cause could be. I do have to reconfigure everything in HA again…

Thanks for the reply.
I did initially installed with the box checked, but updated it and it shows using the zjs2m addon ws:// address, not the zjs add-on
So you’re saying I have to fully delete the integration, then re-add it?

I assume that will wipe out all my entities again, and will have to recreate?
Arrrgggghh

As far as I understand it, yes.

I’m really not sure.

If it was me I think what I would do is to save my device config and entity config files from the hidden “.storage” folder before I delete the integration.

Then after you delete the integration, if the entities don’t get re-created in the same way you could try to restore those files (at your own risk and after taking a snapshot of the system just in case and after stopping HA) to see if they come back.

Did I mention only do this at your own risk and it only if it’s commensurate with your skill level? :wink:

Ha, of course. I’m a devops engineer, running on all virtualized hardware, fairly comfortable, just not as familiar with the backend of HA as much.

Your mention of the hidden config files gave me an idea. I went in and looked at the core.config_entries file and under the zwavejs entry, there’s a parameter for use_addon, which was set to true. I changed to false, and gave it a reboot. So far, it hasn’t come back. Fingers crossed that might’ve been it…

{
                (...)
                "title": "Z-Wave JS",
                "data": {
                    "url": "ws://a0d7b954-zwavejs2mqtt:3000",
                    "usb_path": "/dev/serial/by-id/usb-*REDACTED*",
                    "network_key": "*REDACTED*",
                    "use_addon": false,
                    "integration_created_addon": false
                },
               (...)
            }

I’m thinkin the network key and path parameters can also take a hike, since they’re set in the actual add-on. Gunna leave as is for now, wait and see what happens.

If you’re running zjs2mqtt, mind checking your file to see if they’re listed there for you?

1 Like

@rlems Have you checked the docs for ZWaveJS to see if the config files you’re looking for are listed?
https://zwave-js.github.io/node-zwave-js/#/config-files/overview

The pages there outline why some of the information may be missing. It requires external config files for devices. If yours is available in the repo, you have a different issue. If not, you can contribute to them. They’re easy to make if you can get the specs for your device.

Edit: I checked for you. There are two different firmware versions for the device you specified. Might be a device issue. Have you tried excluding, hard resetting the devices, and then re-adding them?

Here is my config_entries section:

{
                "entry_id": "589157556570580559554c7a78597a0b",
                "version": 1,
                "domain": "zwave_js",
                "title": "Z-Wave JS",
                "data": {
                    "url": "ws://192.168.1.11:3000",
                    "usb_path": null,
                    "network_key": null,
                    "use_addon": false,
                    "integration_created_addon": false
                },
                "options": {},
                "system_options": {
                    "disable_new_entities": false
                },
                "source": "user",
                "connection_class": "local_push",
                "unique_id": 3971937092,
                "disabled_by": null
            },

But you just pointed me to a new thing I need to look at myself.

I see in mine that the network Key is null but I have one actually setup in zwavejs2mqtt.

I hope it’s just because I use a separate container for zwavejs and not the add-on so HA itself doesn’t need it as long as zwavejs2mqtt has it. Otherwise I may have to look into that a bit further myself.

Everything did show up OK but I haven’t fully made the switch yet to js. I’m still on the old zwave but I’ve imported all of the entities from js so I can start making them match the old entity id’s from zwave.

So I don’t think it’s a concern. Maybe time will tell.

That’s my thought process as well. I redacted the network key in the config snip I included, but it was formatted in the 0x## format that I carried over from the previous. The key in the zjs2mqtt integration uses the ###### format instead, so I think it’s not being used by HA at all, since its set in the add-on instead of the integration.

1 Like

You don’t have to delete the integration to disable the auto-install. Just add it again and it’ll redo the config flow without deleting it.

Good to know.

Thanks.

I’m pretty sure I had tried this with other integrations in the past and I always get “you can only have one instance of this running” or something to that effect.

Maybe things have changed or is this just specific to zwavejs since you can have more than one instance?

Nope. It’s just how the integration is setup. They’re adding a config option for the auto-install I believe as well.

1 Like

This is exactly what I did, and it updated the url pointing to the add-on, but it did not set the “use_addon” field to false. I believe that is what was causing the old ZWaveJS add on to keep reinstalling itself despite uninstalling it repeatedly.

The solution that worked for me required me to also update the config file, as I noted above.