I have an out building that, despite being only 60ft from my main home, z wave simply will not reach.
I have looked at all the options to bridge two Hass boxes and frankly, none of them are good. MQTT has missing entities until they are seen (could be hours for a battery operated switch), using something like Vera is over priced, and having multiple Hass instance is pointless.
Therefore I’m looking for someone who knows the z-wave component well enough to tell me if this will work:
I want to duplicate the zwave component and name it zwave1 (python module and domain). Then I want to connect it to a “remote” zwave controller that will be serial over TCP (https://github.com/Tknika/serial2tcp-gateway).
Not sure why you call “having multiple Hass instances pointless”.
Have you tried ‘linking’ them together with an MQTT statestream, i.e. just having the one in the outbuilding report via MQTT?
My main HA RPi is too far away from the only ZWave device I have at the other end of my property on the garden gate. But as a second RPi3 only runs my Unifi Controller, I also installed a very low maintenance HA instance on it that has my ZWave USBstick connected to it and simply reports the state of the garden gate - quickly & reliably.
The point of home automation is to have a central controller with all devices integrated. Having a second “outbuilding” hass.io is contrary to this design and makes it more work to maintain HA (two configurations to deal with).
In the end I will have to try MQTT or go with buy some Vera controllers. Also I have read many more posts complaining about MQTT entities not showing up in the master hass.io because they only get created when they are seen on the broker. This could be hours for battery powered switches. Not to mention event stream and state stream don’t seem to have a lot of documentation.
It’s unfortunate the z wave implementation wasn’t created to support multiple networks from the start. I looked at the code and it would not be easy to change…
I think that’s only true if you are relying on discovery to see them. If you manually create them they will always be there even if the device itself is long extinct.
I have the same issue (because I’m an idiot that purchased both European and US sensors).
I think we can add support for multiple USB controllers rather easily (and hackily) like this:
Changing usb_path to support a string (like current implementation) or a string array.
Initiate a separate ZWaveNetwork for each usb_path value.
Every API action (add node, remove node, heal) will happen on all ZWaveNetwork instances (this is the hacky part).
Nodes returned by API actions will be a union of all nodes from all ZWaveNetwork instances.
Pros: Extremely easy to implement and fully backwards-compatible Cons: Security key, autoheal etc will be shared by all networks. Actions too (although they can be managed by running “cancel command” to clear the networks that you weren’t interested in operating on).
If this sounds reasonable, I think I can contribute this code.
Please LMK what you people think.
I recently tricked the insteon integration to let me run my insteon modem remotely. This only worked because the insteon backend library used pyserial, which supports a socket backend in addition to an actual serial port. (I used ser2sock on an RPI). It doesn’t appear that the zwave backend uses this, so it would be harder.
In theory if you used pyserial inside the zwave backend instead of whatever it uses to talk to the zwave device (presumably serial? I don’t own one) you can do the same thing, just give it a host:port and it magically works. For the definition of magic where you rewrite the backend library…
