I feel like we are going around in circles here. I thought you said you were going to try to use ONE HA and zwave2mqtt?
If your other devices are on the network, zwave2mqtt and mqtt works fine.
I don’t understand why you are complicating the setup. Seriously. You keep insisting that you NEED multiple HA instances. You don’t. FULL STOP.
You’re not sharing some information here, and it’s making it impossible for me to see your layout and understand your logic.
So let’s get it straight here.
How many PIs are we talking about here?
How many Home Assistant instances are there?
How many zwave2mqtt instances are there?
How many MQTT Brokers?
Is everything on the same subnet?
Why do you feel the need to have more than one HA? I want to know why you think that because you have thick walls you need more than one HA. Is it because you don’t know how to run zwave2mqtt any other way? Is it because you don’t know that it’s not necessary?
It seems to me that @eeze2 has a problem with devices connecting throughout his house due to the construction blocking wireless communication. Therefore he has taken the view that having more than one home assistant machine will remedy that because the stuff in one end of the house can connect to HA one, and the stuff in the other end of the house can connect to HA two.
The solution for zwave is probably to have plenty of powered devices which should act as repeaters (or routers).
I understand how I may be confusing things. Let me try to explain.
The walls where I live are concrete and reinforced with rebar. I’ve tried to use Smartthings with zigbee, off the shelff controllers with z-wave and no matter how many repeaters I use (lights, plugs, etc) I cannot get the signal upstairs or to the balcony so I thought that I may just use a little raspberry PI with a z-wave USB to handle those special cases and figure out how to connect them to a central control (MQTT)
I think I need 2 z-wave networks because these issues.
2 Pi’s
Each PI with it’s on HA loaded and it’s own z-wave stick
zwave2mqtt - Likely just the one that’s remote.
1 MQTT Broker on my home server
Single subnet for my IoT devices (I have some esp8266’s and such)
I assumed 1 PI with 1 Z-wave USB = 1 HA installation. I’m using docker on it as I didn’t fancy the hass.io image.
Yes i’m probably overlooking something. Due to my issues mentioned above, I assumed I could use the remote PI and either a) Node-Red to send MQTT events, or b) the zwave2mqtt to notify the other PI of the events.
My wireless network is strong (multiple Meraki AP’s) but the zwave network isn’t hence reason for this.
Hopefully that clarifies my thoughts on the design. Cheers m0e!
We have never been in disagreement with this, based on previous comments stating you can’t get signal.
Why not the secondary pi just running zwave2mqtt?
zwave2mqtt puts your zwave on mqtt, and thus on your network.
If you are using zwave2mqtt, you do not need a second HA. Just run zwave2mqtt (run it in docker if you like) and point it to your broker, with both zwave2mqtt using the same settings (except for client id)
I feel like this entire time you have been disregarding the entire point of zwave2mqtt…
Right, but that still requires I install HA right? That’s why I’m confused why the big issues around “2” HA’s. I cannot install zwave2mqtt by itself right or did I miss something again?
Ahhh ok. This is the core piece I was missing. I thought that zwave2mqtt required HA as a plugin, i didn’t realize I can run it separate. This would mean a lot less configuration if I can just run docker with it and bring in all the events.
Only one issue though. What if I wanted to tell one of the devices on the remote PI to do something such as turn on. If I run zwave2mqtt in docker, that gets my messages from the remote PI to the central HA (NR too).
Edit Reason: Fixed my atrocious spelling and punctuation.
My house is mostly wired wherever possible, but I still have multiple AP’s broadcasting the same SSID without channel overlap, coverage hole detection, etc
All you need is to plug in your controller, pass that device through docker (if that’s the install method you choose), and set the container up… That’s it.
Nope.
From the main HA or even over MQTT, you send the command/push the button/switch. That’s it. It uses the topics that are published and subscribed and relays that to your other zwave network.
You’re overthinking this, and completely confused now.
Maybe I wasn’t clear in my previous post. I understand now that I don’t need HA to run zwave2mqtt. I thought I did. If it can run standalone as a docker instance, then I agree I don’t need HA as zwave2mqtt will handle the state changes and mqtt messages for me
Devices on remote PI are z-wave. Only thing running on Remote PI is OS, Docker, zwave2mqtt.
Between the PI’s is an IP network that can transport MQTT messages
On Central PI is OS, Docker, MQTT broker, Node Red, HA
In the beginning when playing around with z-wave that was also my first impression and I had similar problems. But after reading some z-wave docs I positioned the usb-controller central in the house under the ceiling, connected on an extension cable. This boosted my z-wave network 100%. I also use one z-wave repeater (you could use more and they work better as a usual wall plug repeater) and now I have a reliable z-wave network.
If there is no way for you to have a stable z-wave network you should use other wireless solutions and enjoy the convenience of homeassistant.
I find Node Red automations more enjoyable to create and debug than yaml. While not NEEDED it’s an excellent tool to have. Every automation I have is in Node Red, and is so dead simple to debug when I want to modify things.
I should have mentioned that I have Node-Red running on a VM doing automated daily tasks such as turning on outside lights (tuya), flipping on automated plant waterer (sonoff to a ESPP with a pump). This is why I was leaning towards PI+HA+NodeRed+MQTT was so that I can do all the logic in NodeRed
The only part I wasn’t clear was how to overcome my z-wave issues. I’ll see if I can try more repeaters and maybe reduce to a single PI.
Cheers everyone!
If not, I have a viable solution which seems easy to manage.