Really interesting information. How long did the actual migration of the zigbee devices take as I assume you cannot have the old Deconz network running at the same time as the new one.
This?
Here it is showing up as a light in Phoscon:
Having said that, after checking, it comes across to HA as switch.xiaomi_1, so all good there.
1 Like
In the home assistant interface. Great that it works as expected!
You can run both at the same time, having the Deconz using the Conbee and Z2M with some other coordinator, like a Sonoff 3.0 Dongle. They can even share the same zigbee channel, you just need to make sure they have different PanID. Of course easier (to avoid errors) to have them on different channels.
I migrated over several weeks from ZHA to Z2M.
I recently went from decent to ZHA, why did you opt for zigbee2mqtt instead of ZHA? I use mqtt a lot, but didn’t see any benefits in this case. Is the device support better?
Suggest also recommend these tips and best patches regardless of which Zigbee solution you set up:
https://github.com/home-assistant/home-assistant.io/pull/18864
and
I think is important to understand Zigbee signals are weak and have poor penitration of common building materials so users have to rely on a strong Zigbee network mesh (meaning many Zigbee Router devices) and also keep in mind that Zigbee devices are very sensitive to RMF/EMI/RMI interference.
When in doubt, add more mains-powered Zigbee Router devices that act as good signal repeaters. Personally, I recommend “IKEA Trådfri Signal Repeater” as they are cheap and better than average.
It makes it much easier to troubleshoot and find the real root cause if have already optimized your setup and environment with the aim to work around interference and bad signal reception of a poor mesh.
For that specific dongle there are also more tips on updating firmware and the physical connection, etc.:
1 Like
As mentioned above, you can have deCONZ/Phoscon, Zigbee2MQTT, and the ZHA integration all running at the same time as long have they each have their own dedicated Zigbee Coordinator adapter.
That type of environment with separate Zigbee networks that are not aware of each other is no different from having Zigbee devices connected to several different proprietary Zigbee hubs/gateways/bridges like the Philips Hue Bridge, IKEA Trådfri Gateway, Samsung SmartThings Hub, Xiaomi Mi Smart Home Hub, Tuya Smart Life Zigbee Gateway, etc…
As long as they have different Zigbee PAN ID then they should not be aware of each over and not interact in any way, though as mentioned their signal can possibly interfere if using same radio channel.
Yes, much better device support although ZHA is getting better as well.
Personally I also like the Z2M dashboard, visualization and user experience much better than ZHA but that’s personal taste.
I kept both networks up on the same channel - 25. The coordinators were set apart by 3 ft or so, but I didn’t want to use an alternate channel like 15 for z2m, and then have to move it back for fear of having to repair a bunch of the sensors. It worked fine in my case. I did move the powered devices from the outside in (in terms of distance from the coordinators) after moving a couple repeaters at first. Seemed to go well over a few hours (I had family and work obligations to attend to, so could not do it all in one block).
Just wondering if this methode would also work: Backup and Migrate Your Home Assistant Zigbee Network! - YouTube
Moving it from ZHA to z2m
ZHA currently doesn’t support remote operation - you have to use ser2net to remote a stick, which isn’t actually documented. Also, that Tuya sensor I wanted to use isn’t currently supported by ZHA, at least as far as I the April release.
But the big issue is that I didn’t want to have to upgrade HA to get better device support in a new version of ZHA. I like having these functions be independently upgradeable. As I said in the note, new HA releases are often problematic, and I didn’t want to be forced into upgrades to get better device support.
Zigbee is and always will be a heavily human driven process in terms of getting specific devices with full functionality enabled because of the way the industry incentives drive proprietary behavior. Being fully zigbee spec compliant doesn’t seem to help that much. Z2M has has had years of tweaking that really enables great support. ZHA may get there, but it will take time, and given I needed remote support anyways, and wanted the release decoupling, Z2M was really the best choice for my complex network.
I’m sure ZHA will get better over time, but just as a user, since I was comfortable with the complexity of running with a remote Pi and running MQTT (I use zwave2mqtt as well), it was sort of the obvious choice for me.
Michael, one of the nice things about z2m is if you set permitjoin to true in the config, it comes up in inclusion mode without a time out. That enables you to add bunches of devices without having to turn it on for 5 minutes at a time. If you disable that through the webUI and turn it back on, it does make it temporary.
You can set the entity name explicitly by renaming the device and using the option to reset the home assistant entity name. Because the original deconz names I had were things like sensor_68, I chose to rename the devices, but you could change it to pretty much anything you like. You’d have to delete the old device with that name first though (I think).
Z2M does set the device type. With the new renaming function in HA, you can use it turn a switch into a light with a different entity name, and leave the original device as a hidden entity. That seems like a better way to solve your problem than depending on whatever device irregularity in the zigbee driver exists.
Rather than running z2m in another VM, I would encourage you to think about running it in a raspberry pi that is in the best location to talk to devices. That avoids all the USB passthrough issues, and gets you more optimum device routing. I use an old Rpi 3, and it’s plenty good enough for this function.
I use the builtin MQTT addon, but that’s not required by Z2M. That’s one of the nice things about the MQTT architecture.
+1 here. Z2M diagnostics and status info is VERY good. I really appreciate that the developers gave us so much information to help debug bad device behavior but also very explicit network routing information. I may be more sensitive to this because of the issues I have with the overtly wrong info the zwave2mqtt map displays, but for complex networks, you really need the diagnostics.
Is there not a problem of once you move any mains powered routers (bulbs etc) over to the new zigbee network that you destroy the mesh on the old zigbee neiwork?
Removing a device or two shouldn’t “destroy the mesh.” I did it moving from ZHA to Z2M.
You want to migrate logically enough to keep a functional mesh for both networks. There might be a brief window with less than ideal redundancy, but chances it shouldn’t too difficult to keep things functional for both networks.
Even if you have to buy an extra plug or two to bridge a gap, it is worth it to have the ability to migrate at your leisure vs trying to do everything overnight.
I did make a low key strategy. Started out with all devices west of the coordinator. Then those in north east to create a path to a remote building in east side. Then the remote building and finally the devices in south east. Not scientific, however worked.
If you have a less optimal way, get a few plugs to help creating the new mesh. You can later use them for christmas:-)
Some really good tips in this post.
Thanks.
Thank you - this was very helpful and encouraging. Looking down the barrel of doing this after a bit more than year with deconz.
I’m sure this is a stupid question, but do I have to start the new z2m setup with a fresh install of HA?
Ideally I’d like to transition using my existing install so I have all my automations and dashboards as a starting point, and can just select the new devices and entities in them?
If you set up z2m in parallell you should be able to migrate device per device
1 Like
Exactly right. Running them in parallel will work just fine, subject to the points I made in the original post. Also note deconz and z2m use somewhat different ways of naming devices, so by default they won’t be called the same entity name. That said, you can go ahead and rename the new entities so scripts etc… don’t have to change.
1 Like