Forwarding ZWave output to a separate HA instance

As part of a quest to improve reliability and WAF, I’d like to have 2 HASS.IO instances in separate VMs, one with the ZWave integration and one with everything else.

This should lead to being able to quickly restart HASS.IO (without waiting minutes for my ~40 device network to come fully online) as well as protect the “delicate flower” that is ZWave in HA (seriously, restarting while the ZWave network was still starting has been a cause of sooo many issues).

So, how could I achieve this?

I was thinking MQTT, but I don’t want to use the ZWave2MQTT addon, as from what I’ve seen it replaces the existing HA ZWave integration and looks much tougher to setup and maintain.

What I want is to not touch my existing ZWave config, only add something that can forward its states to my other HASS.IO instance, then move all my automations that rely on these states to the new instance…is such a thing possible?

Thanks in advance for any ideas!

1 Like

It would seem like this is what I want: Multiple instances of home assistant on different networks - might be simpler to implement, hopefully, since the 2 instances would actually be on the same network.

MQTT statestream, HA REST sensor component with API (What you found), or the ZWave2MQTT addon. I found a guide on how to migrate HA ZWave to ZWave2MQTT yesterday.

Read that ZWave2MQTT guide just a few mins ago, looks pretty daunting, at least with MQTT statestream I only take what exists already and use it, whenever I hear “ZWave” and “migration” I shudder instinctively :stuck_out_tongue: I really don’t want to mess with the current ZWave network at all, some of my stuff is behind wall switches, a total nightmare to reset or re-pair if anything goes wrong.

It looks like MQTT statestream does exactly what I want it to do, just gotta figure out where to keep that bridging broker, I hope I can just spin one up in the new Ubuntu instance.

agreed. I’m in a similar situation. I don’t want to touch my zwave network and whenever I do it usually means downtime for HA. I’ve had mine running since version 0.4x with a few hiccups along the way but generally stable. I think the most daunting part of that guide is identifying all of the sensors and creating the respective MQTT switch/light/lock, etc. But once you understand the format, the templating gets pretty easy. I need to read up more on MQTT to understand best practices with the the topic name configuration such as group/area/device/sensor/state.

Yep, it looks like I’ll have to create dozens of entities in MQTT, but that’s fine, as you say, it should become simple enough via repetition and it has the benefit that I don’t need to actually use the new instance in “production” until everything is ready.

Here is an example.

Zwave in Host/Master system:

  base_topic: ha_master_topic
  publish_attributes: true
  publish_timestamps: true
      - switch.double_relay_sprinkler_switch
      - switch.double_relay_sprinkler_switch_2
      - zwave.double_relay_sprinkler

Slave system:

  - platform: mqtt
    name: "tap1"
    icon: mdi:water-pump
    state_topic: "ha_master_topic/switch/double_relay_sprinkler_switch/state"
    command_topic: "ha_master_topic/switch/double_relay_sprinkler_switch/set"
    availability_topic: "ha_master_topic/zwave/double_relay_sprinkler/is_ready"
    payload_on: "on"
    payload_off: "off"
    state_on: "on"
    state_off: "off"
    payload_available: "true"
    payload_not_available: "false"
    optimistic: false
    qos: 0
    retain: true
  - platform: mqtt
    name: "tap2"
    icon: mdi:water-pump
    state_topic: "ha_master_topic/switch/double_relay_sprinkler_switch_2/state"
    command_topic: "ha_master_topic/switch/double_relay_sprinkler_switch_2/set"
    availability_topic: "ha_master_topic/zwave/double_relay_sprinkler/is_ready"
    payload_on: "on"
    payload_off: "off"
    state_on: "on"
    state_off: "off"
    payload_available: "true"
    payload_not_available: "false"
    optimistic: false
    qos: 0
    retain: true

Thanks a lot for that!

And what do I have to run on the 2 systems?

At the moment on my first (and so far only) HA I have the Mosquitto broker addon and the MQTT integration (both of which I’m using for connecting to a Pi that uses the Monitor presence script), can I just install the MQTT integration on the new slave system and tell it the topic?

You just need the Mosquitto broker addon (just one on any machine). I have it running (as Hassio add-on) on the Host system and it appears under -> Configuration -> Integration -> Configured

You need to add a user in HA “mqtt” / [any pwd]. It becomes your mqtt-user pwd for loging into Mosquitto.

No further configuration required in configurations.yaml in the Host system.

The Slave system has the following entry in configurations.yaml

  username: mqtt
  password: [your mqtt user pwd - see above]
  client_id: ha_virtualbox
  keepalive: 60

I use this setup as development environment on a Virtual Machine and still can access ZWave devices if required.

1 Like

Wow, this looks EXACTLY like what I need, thank you so much for explaining it so thoroughly!

Make sure to install mosquitto_sub. This helps a lot.

Run it on your cmd line to watch the MQTT messages.

mosquitto_sub -v -h -u mqtt -P [secret_PWD] -p 1883 -t 'ha_master_topic/#'

I just wanted to mention: since disabling the radio manager every restart has been flawless. No more z-wave issues. It’s described in the z-wave docs nowadays.

Interesting…I see a mention of the Modem Manager at, not the Radio Manager, is this what you mean?

Yes, sorry for the mix up.

I’ve also been exploring this. Was looking at zwave2mqtt mostly because i didn’t want to have to bother updating 2 HASS installs, though i suppose if both are in docker it’s not too bad.

Let me know how statestream works out for you.

Yep, will probably give it a go on Monday if I can contain the excitement till then :smiley: Updating 2 HASS installs is OK from my point of view because the plan is to keep one with ZWave, MQTT and literally nothing else, so that I’d only need to look out for ZWave breaking changes.

I will definitely be using this opportunity to create a 3rd VM, though, finally a DEV/TEST environment with all hardware accounted for!

Anybody know if zwave2mqtt can handle double taps? Like I have a few automations that run on double taps on my light switches. If not, guess my best best is statestream

I’m really curious about switch taps and lock control myself.

Right now I’m bashing my head against a wall with mqtt_statestream and mqtt_discovery not seeming to want to play nicely with each other. But yeah, if zwave2mqtt is “easier” i might be tempted.

I think it was on Reddit, but the developer said he just released a version of Zwave2MQTT that supported Home Assistant MQTT discovery. It sounded like more of a beta version, but worth checking out.