Best way to create dedicated zwave instance

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
mqtt_eventstream:
  publish_topic: primary/topic
  subscribe_topic: secondary/#
  ignore_event:
    - state_changed

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

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

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

Primary HASS.io 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: https://github.com/blakeblackshear/rpi-zwave-hub/blob/master/homeassistant/custom_components/mqtt_control.py

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: https://github.com/blakeblackshear/rpi-zwave-hub

Everything you need should be in that repo.

2 Likes

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

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

mqtt_control:
  base_topic: homeassistant_hub/
  include:
    entities:
      - climate.thermostaat_huiskamer
      - cover.zonnescherm_computerkamer
      - cover.zonnescherm_huiskamer
    domains:
      - 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?

[Edit]
I see there are sections in the mqtt_control.py 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.

I’ve made some quick and dirty changes to your file now. It works with 0.94 now.

For everyone who doesn’t know how it works now.
Create a folder named “mqtt_control” under the “custom_components” folder. Create init.py and manifest.json under the newly created folder.

Copy the contents to the files from following link.

Hi,
there is a hassio addon called zwave2mqtt that even supports autodiscovery since the last update.
This would solve my original problem. However, I found out that thermostats are not really well supported. They have to be manually added with a special config to zwave2mqtt which is not apparent or easy to do for the average user. Since I use mostly thermostats, I was not too keen on doing that.

So I tried out a different solution I came across recently which seems to work very good:

It is a custom component that is much more elegant than mqtt based stuff. It grabs the states from one or more remote HA instances and forwards local service calls to the remote instance. No need to configure devices on the master instance. :slight_smile:

Let’s see how stable it works in the long run…