Best way to create dedicated zwave instance

I’d like to create a separate HA instance next to my normal installation to handle everything zwave related.

HomeAssistant requires a lot of restarts, basically on every config change and on every update. And Every time it is a hassle to get zwave up and running again as it takes usually several healing attempts until all devices are available again. Letting it sit for a while does not fix it usually. So I’m avoiding restarts as much as possible.

What is the best / easiest way to achieve this?

I’ve read about state streams and event streams but those don’t really sound like what I’m looking for. Ideally I would want to have several ha instances that are acting as one - transparent to the user.


1 Like

You might want to look at the rest api to do this and/or mqtt. I did have it working for switches and sensor data but lights were a pain.

MQTT Eventstream

Set up your “primary” HASS and link it to the secondary z-wave/zigbee controller housed HASS.

Once you connect via eventstream, you never have to touch the other hass instance again, and all components show up in the primary HASS - transparent to the user.

# Example primary instance configuration.yaml entry
  publish_topic: primary/topic
  subscribe_topic: secondary/#
    - state_changed

# Example secondary instance configuration.yaml entry
  publish_topic: secondary/zwave
  subscribe_topic: primary/topic

@mike1237 are you using this yourself? I have thought of doing this but many report issues with the setup.

Yes I am - Zwave/Zigbee running on a Rpi with HUSBZB-1 stick as a secondary instance only for zwave/zigbee devices.

Primary running on a hyper-v linux virtual server

1 Like

Thank you for sharing this Mike!

From the docs and forum i got the impression that eventstreams were rather old and have been replaced by statestreams.

The pros and cons of both techniques were never really clear to me though…

I will try your approach!

I just set this up and I’m noticing that the entities aren’t pulled into the primary instance until the status changes in some way. Is there a way to get around that?

I’m curious, could you please elaborate on that behavior,? The feature is unfortunately not documented well.

Are the entities of the second instance automatically created in the master instance?
Is the entity ‘pulling’ done once, on demand or on every reboot from scratch?
How noticable is the delay of zwave events?

Thank you!

yes - but delayed or only when triggered

each event publishes to MQTT so it should be on demand (and appeared to be with minor delay in my testing)

None in my limited testing

What I found was the entities did not populate until their states changed. If I turned on a light, it would appear in the master. I would have expected they load immediately and stick around but other reports on the forum indicate that they start to disappear if they do not change for a while.

Newbie here. So I have installed hassio on new Pi. If I understand it correctly, I will have to do Zwave and ZigBee setup with new instance again right? Also do I have to migrate existing automation to Zwave/Zigbee host or it should work even if they are on main instance?

I setup a dedicated zwave instance and wrote a custom component to allow them to interface with my main instance as standard MQTT components. I also use it to run zigbee2mqtt. My main instance has no idea that the other devices are running in homeassistant and doesn’t care. No discovery support yet. See here:

I have this running in two houses. One of them has 2 separate zwave networks.

1 Like

Thank you for sharing this!

2 questions:

  1. How do you configure which entities should be published to Mqtt? It seems as the script does not filter out non-zwave-related entities.
  2. What is the difference to the MQTT eventstream method?

I used the same logic to include/exclude as the mqtt statestream component in the config file, so you can include and exclude however you see fit.

I started with eventstream, but didn’t like the implementation. It just felt messy and too tightly coupled. I use zigbee2mqtt for zigbee and wanted something similar for zwave. I didn’t want my primary homeassistant instance to know or care what was on the other end of the mqtt messages. This just felt cleaner to me.

This I great.

I moved from Hassio on a pi3 to Hassio on Hyper-V. I don’t want any USB devices in my Hyper-V machine.
So now I’m running USBIP (RPi as Z-Wave/ZigBee-over-IP server for Hass)
And it does work. But every time I have to reboot my Hyper-V machine I have to reconnect to the remote pi. Sometimes I have to reboot the pi. So it is a bit inconvenient.

So now I switched to a second instance of hassio on a pi. And running Zigbee2MQTT on that for Zigbee. And I’m looking for something similar for Z-Wave.
I tried Eventstream. I see all devices of my “slave” instance in my “master” instance. But I’m not able to control them. I don’t know if this is the nature of Eventstream?

I like your idea to make a similar solution as Zigbee2MQTT by making a custom component. Is this already a working solution? Can you please explain how this works?

It is a working solution, and I have been using it for months without any issues. I run all my zigbee/zwave devices on a separate pi3 with this config:

Everything you need should be in that repo.


Great! :smiley:
Can you please explain it a bit more for me? I’m not so good with MQTT yet.

I placed “” in the custom_components folder and added this to configuration.yaml on the dedicated zigbee/zwave pi

  base_topic: homeassistant_hub/
      - climate.thermostaat_huiskamer
      - cover.zonnescherm_computerkamer
      - cover.zonnescherm_huiskamer
      - cover
      - climate

rebooted to take effect.

I subscribed to “homeassistant_hub/#” in MQTT.fx to see if I see some messages. But I don’t see messages on that topic.

What do I have to do else?

I see there are sections in the for switch, light, lock and sensor.
Can you please add cover and climate? I’ll try to do it myself but I’m not familiar with scripting.

Thanks in advance.

Did you upgrade your mqtt_control component to support 0.94? :slight_smile:

I didn’t yet, but I will eventually. Still running an older version. Eventually I am hoping to move to the new Zwave2Mqtt project.

Ok, thank you for your answer. I had big hopes for zqave2mqtt but as of now it was to buggy to be used. I will try and fix your component, I think that is the only solution for me. I will post it here when done :slight_smile:

That’s unfortunate. I think the biggest challenge in using Zwave2Mqtt will be dealing with all the same workarounds for specific devices that are implemented in Homeassistant. It would be great if all of that logic was abstracted into a separate python package.