Can you explain how you did it?
Thank you
How would I do this if the instances were separated using nabu casa and not using a static IP or Duckdns?
I was using usbip on a VM (running hassio) and RPI for about 6 months, relatively successfully, but every reboot of hassio needed the rpi to reboot too, and every few occasions would need some kind of tinkering to make it work again. After a recent update, it finally gave up, and I couldn’t get any combinations of things to work. Also tried socat, ser2net etc.
I’m now using home-assistant-remote and I can’t believe I wasted so much time fiddling with usbip!
Fresh install of hassio on the rpi, import the zwave config from the primary hass instance, then create a long lived token.
On the primary instance, drop the component into custom_components (or create that folder if it doesn’t exist), then add your config.
remote_homeassistant:
instances:
- host: !secret secondary_ip
port: 8123
access_token: !secret secondary_token
entity_prefix: "usb_"
include:
domains:
- sensor
- switch
- group
- light
- climate
climate:
light:
I had to add climate and light into the config, because without zwave on the primary, I have no lights/climate devices, and the primary wouldn’t know to load these components without this.
The biggest benefit to this is that a reboot of the primary doesn’t mean having to reload the whole zwave network, and conversely, a reboot of the rpi means the entities show as unavailable on the primary, but they spring back to life without any manual intervention once the secondary instance is back up.
4 Likes
Hi,
I have one RPi 3B+ with Razberry Z-wave GPIO card that I now want to connect to a new HA instance that I’m running on a server.
I have installed HACS and home-assistant-remote on the server and the config looks like this:
remote_homeassistant:
instances:
- host: ip
port: 443
secure: true
verify_ssl: false
access_token: !secret rpi_access_token
entity_prefix: "zio_"
include:
domains:
- sensor
- switch
- light
- group
- zwave
subscribe_events:
- state_changed
- service_registered
- zwave.network_ready
- zwave.node_event
I can see my light on the server but I can’t turn then on or off the light.
I just got this error.
When I go in to the RPI i can turn on and off the lights.
Have I missed something?
From the documentation https://github.com/lukas-hetzenecker/home-assistant-remote#special-notes:
If you have remote domains (e.g. switch), that are not loaded on the master instance you need to add a dummy entry on the master, otherwise you'll get a Call service failed error.
Isn’t it your situation?
GV
Yeah, it’s easy to get caught out by this. When I was testing, I had it working, but then removed the only light from the main instance, and had to re-read the docs…
Once I get the automation logic figured out, I might do a bit of a write up on the redundancy side of my setup, but briefly, thanks to home-assistant-remote, connecting to secondary instances and failing over to backups is working very well!
I started thinking about redundancy when I realised you can backup the aeotec z-stick - due to the number of zwave devices I now have, I bought a spare thinking I’d apply the config and keep it handy in case it was ever required. Then I realised I may as well keep it plugged into a spare raspberry pi, ready to go.
My setup is a pair of NUCs running Windows server with Hyper-V role. VM running Hass.io. This vm is setup for failover to the other NUC hypervisor.
I then have 2 raspberry pis running hass.io - snapshot of one loaded onto the second, 2 zsticks (backup of the first loaded onto the second). Both have the same IP set (obviously being careful to never have both on simultaneously). Both pis are connected to wifi power sockets (not zwave, for obvious reasons…) so can be powered on (and off, if required) from the main hass.io instance.
Because I’ve loaded a snapshot of one of the rpi hass.io’s onto the second, the long-lived token is the same across both, so if I shut 1 pi down and power up the other, all the zwave devices come back online with no further interaction (there are rare occasions where even with one rpi, I’d need to reboot the main instance—i.e. taken the rpi down for a prolonged period—so that remains the same).
Next step is to work out some automations to check for zwave activity/network health and auto failover!
1 Like
Thanks, I did not read that.
It solved the issue just to add
switch:
In the config
did you get this working harry? I am at the same point as you where here. Not sure if I need to add something to my salve unit.
I did manage to get it to work locally and remotely.
Ill have to check my exact settings and come back to you though.
Oh…please do …very interested.
I this also working over WAN and not LAN only? I have tried a bit with a duckdns address but it doesn’t seem to work
I found that this line now have to be disabled
But still no luck in getting any response from my remote slave HA (on a duckdns link).
Hello,
Find below my working config. I don’t use the “api_password”. Note that I could not make work the “entity_prefix”. To replace that I add manually in my remote HA the prefix I want to use, in order to not mix the entities from the local HA and the remote HA.
remote_homeassistant:
instances:
- host: !secret HaSlave
port: 8124
secure: true
access_token: !secret haslave_access_token
#entity_prefix: "HAslave_"
1 Like
Thanks for your reply but do you connect over LAN or WAN? I’m trying over WAN and that could be the problem. I see you have another port no. for your Slave and that tells me you must use LAN.
Hello, so both are in the same LAN.
But using duckdns, this is the same as if you connect via WAN.
Well I tried with DuckDNS but I could not get it to work but now I’m using ZeroTier One addin and it works like a charm. I can highly recommend it.
Hi there,
How were you able to create the access token ?
thanks,
jens
I’ll latch on to this one. I have copied the folder to custom_component in one of my instances. The sensor.remote_connection_192_168_1_101_8123 shows “connected” as a status, with this info:
host: 192.168.1.101
port: 8123
secure: false
verify_ssl: true
entity_prefix: ''
And nothing populates. I have switches both places, but no extra switches shows up.It’s on an inaccessible internal network (behind a pfSense Firewall that doesn’t forward that port, so I have no security on it. Is that the problem?
If anyone else has issues here with switches from one HA instance not reliably being sent to the other: it seems like this is a problem with sending “toggle” specifically. Sending an on or off state change works as intended. Using a dummy switch to always send on or off instead of toggle dodges this bug.
So in my case, the local HA dashload has a boolean dummy switch (Configuration > Helpers > Boolean) with automations that trigger when that boolean turns on or off. Any further automations that need to toggle the light? Just point those at the boolean as well.