Thanks for clarifying, then it makes total sense. I misinterpreted the device description, which sounded to me like it could work as a full Zigbee Router (see picture below).
Not really, the description is accurate. The SLZB-06 can as either coordinator or router, just like a USB dongle. I don’t think they make any claims it runs z2m.
I agree with others, using the serial over IP is not likely to be the most stable solution when used over a WAN.
Personally. I’d probably use a second HA instance on a Pi or similar, that way everything works with or without active internet. Otherwise, z2m at the remote site on a Pi like device (even a Pi Zero) with a VPN connection back to your house.
Hi Jerrm,
thank you! Agree, this seems to be the best option - will go with a second separate instance.
100% agree with Hedda - that’s a really bad Idea.
Im going with Remote Home Assistant with connection back to yours. It’s designed to handle the case of a loosely connected remote. Whereas Zigbee assumes it is local. By faking ot out you’re introducing unknowns and abnormal operating conditions (which make bad stuff happen)
I get you feel it’s overkill but it’s what you need to do to ensure reliability. You don’t want the internet between the devoand your database and event hub. Stuff will get lost and you will constantly fighting the install. (my time is worth money and constantly fighting an install is not what I want to be doing with that time)
Put zha or Z2M on a (older cheaper) Pi with a Zigbee stick and a small haos install and drop it right next to the sensors. The use remote ha to link it to yours. Won’t even need a powerful box so it should end up inline costwise with any other hub solutions (assuming you’re not deploying a brand new Pi5)
Ok, we all get it! I made a bad suggestions 
I just got that device and saw the Wireguard VPN option so I mentioned it. I did end with a disclaimer that I had no experience actually doing it.
Not sure exactly where you landed on this, but if you dont want to run a fully remote HA instance at your parents house, you could run sometihng a bit skinner, with zigbee2mqtt and a mqtt broker, acting as a local zigbee coordinator.
you can then setup an mqtt bridge between your parents local mqtt instance and a cloud hosted once (on a free tier vm, or there are free cloud mqtt brokers)
you could then setup a second bridge from your local mqtt broker at home, and the cloud one, in order to sync messages between your local HA instance, and the remote z2m controller at the remote location.
Downside – needs a cloud service.
Upside - no VPN required, no open ports or any sort of incoming connections
You are not alonne to misunderstand this. I understand this can be confiaing because it can be changed to be a Zigbee Router instead of a Zigbee Coordinator but in Zigbee Router mode it does not send any traffic from the Zigbee radio chip over over the LAN/IP network, so you can never route Zigbee Router traffic over a LAN or WAN. So in Zigbee Router mode you basically fully disconnect the Zigbee radio chip and that works completly stand-alone from the ESP32 chip that is running the serial-over-IP proxy server software.
Zigbee Router communication will only ever work over Zigbee, you can never bridge that over LAN/IP. Again, check out these community guides before buying anything:
You can review the Wireguard setup manual on the SMLight website.
1 Like
Again, as explained above, that is a terribly bad idea. Really stupid feature to have in a Zigbee Coordinator. No one should be using it like that, and anyone who do will be garanteed to have a bad experince.
1 Like
So I went with the “Second HA instance at parents house” in case anybody is interested. Thank you again to everybody!
Tested it today with Remote Homeassistant and so far all good.
Off-topic: My next issue is now how to make the second instance remotely available - What a bummer that one Nabu Casa account can only accomodate one instance. 
I was looking for some other topics related to Zigbee and accidentally stumbled upon this thread.
I have no idea why you think so - I’m running my second Zigbee network in a remote location with a connection over Wireguard, and I haven’t had any drops or issues with it. I’m managing 6 Zigbee sensors and 1 Zigbee relay remotely. I would say for me that’s the best solution - I don’t need to do anything - it’s just plug and play with a $30 incremental cost for a Zigbee network coordinator.
@manuscho If you have a network coordinator, try using network one like I did, so you’ll eliminate the need for access to another HA instance and incremental HA instance overall. If you don’t have Ethernet/WiFi Zigbee, you can use something like the duckDNS HA addon + duckDNS account. Installation is very simple - create a duckDNS account like manuscho.duckdns.com, install the duckDNS addon, link both, and that’s it, just go to manuscho.duckdns.com - and will get access to your second instance.
Again see link to other thread above as explained it in more detail there and linked to referense.
In summery the serial protocol that Zigbee Coordinator uses are only designed to work on a 100% stable connection to the host application, as such they have not been made to handle packet drops or higher latency. This is the reason why both Zigbee2MQTT and ZHA integration documentations specifically state that you should not connect a Zigbee Coordinator over WiFi.
So it should be understandable that a VPN connection over WAN should not be counted as any more stable than a local Wi-Fi connection.
2 Likes
Do you expect that I will read something and say, ‘Wow, really, it doesn’t work like that!!’, while looking at my server to which the remote Coordinator with seven zigbee devices is connected, and the uptime of that architecture is already over a month? 
Funny, right?
Just because something works doesn’t mean it’s working well, supported or advisable.
Im glad it works for you, and still - it should not be the recommendation because a supportable config that fits the use case is available. Instead, a workaround for fringe scenarios for people who go into the configuration with open eyes understanding what thier tradeoff is.
2 Likes
+1 and while it might work for some people sometimes it is absolutly not a solution that should be recommend but instead the oposite. I strongly recommend that no one use such a setup for anything they care to work in the long term. You have been warned:
”WARNING: WiFi-based Serial-to-IP bridges are not recommended as the serial protocol does not have enough fault-tolerance to handle packet loss or latency delays that can normally occur over WiFi connections.”
So no, recommending a poorly desiged solution just because it have worked for you for a month is not helping, nor funny for those who have to learn that the hard way instead of being warned in advance and learning from research others have done.
1 Like
Just wanted to share my experience with WireGuard.
I use it quite a lot for my remote houses. I have three remote sites all connecting to my home using wireguard. I have been running this config for a year now and never ever has lost the connection, other than a power failure at one of the locations.
But the wireguard connection came back instantly when the power came back on.
I run wifi management, and have a few mqtt-sending sensors remotely. Also at one site, I have a second HA instance running locally.
This has been working really well for me. For a long time.
The problem is not Wireguard or the WAN connection, those will work great if you use protocols such as MQTT that was designed to work over a TCP/IP connection.
The problem is that the native serial protocol interface that a Zigbee Coordinator provide over UART is not designed work over IP at all, it was desiged for direct local connection to a serial port.
What those remote network-attached adapters does is wrap the serial commication in a IP-tunnel to proxy the connection. Thus the Zigbee Coordinator itself is unaware it is not a local serial port connection.
Anyway, you guys can do whatever you like. All we tried to so it inform you that it is bad idea and encurage you to not suggest that others should also adopt such a solution.
2 Likes
Sorry, I thought you were wondering how reliable wireguard is. My bad.
Similarly, I can say that Just because something is written as ‘alert’ doesn’t mean it’s working badly, unsupported, or not-advisable. I’m not gonna prove something, I want to emphasize that writing “weird, won’t work, etc.” - without any actual proof of concept (and not just theory) - sounds questionable as well I have an actual case, it works. Ok. so why not.