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.
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.
+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.
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.
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.
ZHA page discusses the problem with WiFi interference, which has nothing to do with the current topic. So, linking that page as an argument to the topic starter confuses the readers (intentionally or unintentionally). Anyway, so far we have one working case and zero ones with failures 1:0.
WiFi can deffintly be compared to VPN over WAN when the reference is a local Zigbee Coordinator Serial-over-USB adapter.
I bet you would also argue that think if a one or two people manages to drive part of a Baja 1000 or Paris-Dakar rally in a modified Tesla Model 3 should recommend to do so despite many experiences drivers saying it is terrible idea and suggesting that no one should be recommending anyone to do so.
Just because something can be done does it mean that it should be done, nor that you should be recommend it.
Note! Using a IP-over-Serial proxy bridge over WiFi has nothing to do with interference, do read:
@user141 If you insist on recommending using a Zigbee Coordinator Serial-over-IP bridge via VPN over a WAN connection then you will probably be accused of trolling.
Not working when your provider is using CGNAT and when you don’t have public static IP. Was on trying to solve it together with SMLight but with no luck.
Funny, right? 