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.
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?
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 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.
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
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.
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
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.