2025.2 Duplicate ZWave Hubs

[hoyt]

I’ve disabled the z-wave integration that has my “prior” home_id. But now all of my z-wave devices are appearing offline in HA and labeled as Cannot change status. Disabled by Config entry.

I renamed the two integrations so I could easily tell them apart:

EDIT: And I’m not entirely sure this is right. The one with the home id that matches my add-on says this in the .data.entries file: "created_at": "2025-02-10T20:46:47.028216+00:00", that’s about when I enabled the “second” one. And further down: "source": "zeroconf",, which seems to indicate this is the one that HA auto discovered. So that seems a bit odd to me.

[GoodyGizmos]

Sorry, I kept meaning to post my results. Here you go:

➜  ~ jq '.data.entries = [.data.entries[] | select(.domain == "zwave_js") | .data |= with_entries(select(.key | endswith("_key") | not))]' /config/.storage/core.config_entries
{
  "version": 1,
  "minor_version": 4,
  "key": "core.config_entries",
  "data": {
    "entries": [
      {
        "created_at": "1970-01-01T00:00:00+00:00",
        "data": {
          "integration_created_addon": false,
          "url": "ws://a0d7b954-zwavejs2mqtt:3000",
          "usb_path": null,
          "use_addon": false
        },
        "disabled_by": null,
        "discovery_keys": {},
        "domain": "zwave_js",
        "entry_id": "25bdf550bb421ed76790464f978f909c",
        "minor_version": 1,
        "modified_at": "1970-01-01T00:00:00+00:00",
        "options": {},
        "pref_disable_new_entities": false,
        "pref_disable_polling": false,
        "source": "user",
        "title": "Z-Wave JS",
        "unique_id": "3558291041",
        "version": 1
      },
      {
        "created_at": "2025-02-08T01:03:48.125754+00:00",
        "data": {
          "integration_created_addon": false,
          "url": "ws://172.30.33.1:3000",
          "usb_path": null,
          "use_addon": false
        },
        "disabled_by": null,
        "discovery_keys": {
          "zeroconf": [
            {
              "domain": "zeroconf",
              "key": [
                "_zwave-js-server._tcp.local.",
                "3228873653._zwave-js-server._tcp.local."
              ],
              "version": 1
            }
          ]
        },
        "domain": "zwave_js",
        "entry_id": "01JKHHB3CXC3MFPWVKA7C05KEV",
        "minor_version": 1,
        "modified_at": "2025-02-08T01:03:48.125772+00:00",
        "options": {},
        "pref_disable_new_entities": false,
        "pref_disable_polling": false,
        "source": "zeroconf",
        "title": "Z-Wave JS",
        "unique_id": "3228873653",
        "version": 1
      }
    ]
  }
}

Z-Wave JS UI Add-on DNS Discovery is still enabled.

[freshcoast]

Same question, did you ever change controllers? Such as performing an NVM backup and restore?

[GoodyGizmos]

No, I have not done anything to change my Z-Wave configuration since initial setup a couple years ago.

[hoyt]

I had a thought that perhaps I needed to disable both integrations and then re-enable the correct one. Previously, I enabled both, then disabled one when flipping between them and trying to get the entities to re-enable.

This time I disabled both, waited a moment or two, and then re-enabled the one that matched my home_id in the z-wave js add-on. It appears my z-wave entities are now back to normal.

[hoyt]

Well, I just noticed one thing that isn’t working right. In my automations, I’m no longer seeing the proper options for scene triggers in the visual editor. This is a pre-existing automation built on an Inovelli Red (Z-Wave) switch:

If I flip to YAML, it seems fine and it triggers just fine too:

device_id: c3fa71c4f47ad0ae5fc23359f3391769
domain: zwave_js
type: event.value_notification.central_scene
property: scene
property_key: "001"
endpoint: 0
command_class: 91
subtype: Endpoint 0 Scene 001
trigger: device
value: 3

This is how it should look, example with an Inovelli Blue (Zigbee):

[hoyt]

I changed which integration is active as a test. Now I have an integration that is active that has the “wrong” home_id and all of these things came back to my automations. I’m not sure what that concludes, but several of my automations are failing because of this.

Automation Step:

device_id: 65516aad856232182a3108d7c73e90e1
domain: zwave_js
type: set_config_parameter
endpoint: 0
parameter: 16
bitmask: 255
subtype: '16[0xff] on endpoint 0 (LED Indicator: Effect Color) on endpoint 0'
value: 168

Log:

Error: No zwave_js nodes found for given targets

If I leave the “wrong” integration active, then none of my devices are actionable in the front end:

But I can execute the above automation (which is tied to the device in the screenshot) and it works.

EDIT: A reload of the “wrong” integration brought my entities back to life, so that’s good. Does it matter if the home_id is different?

[Hoobie7 (Tyler)]

I have also run into this issue since the 2025.2 update. I understand that one is the URL name and the other is the IP address but shouldn’t the URL simply resolve to the IP address and it should recognize that it is the same device?

While the “Server URL” path differs the “Home ID” is identical. What I also find odd is that while both controllers show all my devices duplicated, 21 in total. It has split the entities of those devices across both controllers, 450 for one and 221 for the other totaling 671 entities.

Should I just delete one? Will it move the entities to the other? Should I enter the name or IP in the Server Host field?

[GavinCampbell]

Having both enabled was causing issues with my zwave automations. Things like duplicate messages were getting sent which flooded the network at times and caused some automations to fail.

I finally spent a bit of time and cleaned it up by doing the following (these are just what I did I’m not responsible if it doesn’t work for you).

1. Created a backup.
2. Disabled both controllers.
3. Enabled the proper controller. In my case, it was the controller with the ip address and not the local dns name. I noticed all of the devices were enabled with the new controller and moved off of the other controller. If you have a few make note of them.
4. Deleted the bad controller (yolo!)

I did have to do a bit of cleanup as there were entities that were enabled that I had disabled in the past. But everything was still there and it has been running much better since I cleaned it up.

Just thought I would share in case it helps anybody.