Impressions from spending too much time on this forum and discord.
Not sure I have seen that, and 18 months is a long time in tech.
I agree with you about z2m vs zha, but @wbravin seems to want something simple to usr, and zha is built in and will just work.
Hello all
Thank you for your input. This will help.
Therefore I will be planing to use the sonoff usb along with the zha addon.
Since this will controll the hvac environment and the inverter for the solar pannels, I beleive this would be a simple and pragmatic solution.
Once again thank you all
I think ZHA will eventually move to being an addon, and decoupled from the core HA functionality, just like z2m is. I restart HA a lot, for many different reasons, and if if I were using ZHA, that would reset the zigbee mesh network and all the devices everytime. Not good.
Now, there no reason that ZHA can’t run more independently, and this would also allow you to run it on a remote RPI or other device more centrally located from a network coverage POV, which is rarely where core HA tends to run (e.g a server in the basement or colocated with a wiring panel). There is a reason why zwavejsqmqtt and zigbee2mqtt exist and are decoupled they way they are.
Esphome is going to support distributed BLE probes for the same reason, to get better coverage than where the core HA instance runs. Same principle.
z2m gives me that functionality now, and also enhanced functionality for many devices. ZHA will probably eventually catch up, but I think for more serious users, the choice is pretty clear now. We don’t have to wait for ZHA to mature to have a rock solid decoupled zigbee installation in HA.
Switching to Z2M (from ZHA) means i need to start from scratch again, Right? 
Using ZHA and it works quite ok. Sometimes some data is missing from battery powered devices but all works fine
There is some backup/restore method which allows to migrate from one control app to another. Z2M supports it. Don’t know if ZHA does
The official “Zigbee Home Automation” (ZHA) integration is the Zigbee gateway solution that is natively built into Home Assistant and is what is official supported by the Home Assistant founders + Nabu Casa (and really the Zigbee gateway solution that this specific forum is about other than Zigbee devices/hardware products that can possibly be used with this official ZHA integration).
Zigbee2MQTT (a.k.a. Z2M) is an alternative third-party Zigbee gateway that is available as a stand-alone application well as an add-on for Home Assistant. Zigbee2MQTT communicates via the MQTT protocol which makes it more flexible, however, you can not control everything from within Home Assistant’s own user interface and you need to go to Zigbee2MQTT GiHub repository for discussions and reporting issues.
Those two Zigbee gateway solutions have many different pros and cons. Since that official ZHA integration is embedded into Home Assistant’s core it is easy to get started with and feels more like it is a native part of the Home Assistant platform out-of-the-box, and the statistics in Home Assistant Analytics does today show quite a high percentage of installations of the “Zigbee Home Automation” (ZHA) integration, which is not surprising since this is the integration that is recommended for the official Home Assistant Skyconnect dongle/adapter and Home Assistant Yellow appliance’s Zigbee radios. And with Zigbee2MQTT using MQTT which is a widely adopted standard, it makes that compatible with most other home automation ecosystems but Zigbee device management needs to at least partially be handled outside of Home Assistant’s UI, still, together with the fact that it uses MQTT and can be said to be more mature as a complete gateway solution due to it being around for a longer time makes Zigbee2MQTT quite popular among many open-source developers from other projects too and thus it usually gets full support for newer Zigbee devices and unusual features quicker than what ZHA does (though because of how the zigpy library that ZHA’s depends on is designed it will the other hand get initial support even quicker if a device is only using standard Zigbee features and functions since they will in theory then just work without any code being modified).
ZHA docs explain most need to know about how Zigbee works (like how it depends on mesh network):
Especially read and try to understand all in these sections from the ZHA integrations documentation:
Regardless of solution used I highly recommend following the tips in my original post in this thread here:
If nothing else then avoiding interference remember network mesh is the key and simply adding more and more Zigbee Router devices to your network will make it more and more robust.
Maybe not quite…
FYI, the upcoming 2022.9 version of Home Assistant will feature a new UI and backend/core functions for backup and restore/recover in Home Assistant’s native ZHA integration to export/save or import/restore Zigbee network ZHA backup images from within Home Assistant’s UI (in the GUI for the ZHA integration) to make migration to a new adapter easy in ZHA.
It should even make migrations to or from ZHA and Zigbee2MQTT or vice versa between them relatively easy compared to how it has been in the past since both ZHA and Z2M now use support the same “Open ZigBee Coordinator Backup Format” standard that was developed in collaboration between ZHA/zigpy and Zigbee2MQTT developers.
I am however now sure if and how well Zigbee2MQTT itself handle migrations (backup and restore) between different radio adapters such as zstack/znp and ezsp when they are not of the same type to “upgrade” adapter in Z2M without migrating to ZHA.
Note that I do not mean to imply that the application level data would be migrated between the different applications (like Home Assistant and Zigbee2MQTT application layers and their databases) or that the Zigbee network backups contain data about what you named your devices in the application layers of Home Assistant or Zigbee2MQTT. This type of Zigbee network backup will only backups and restores the “Zigbee network” (Zigbee network layer), meaning the Zigbee devices already joined/paired to your Zigbee Coordinator, so you should at least not need to go around your house in order to re-join/re-pair all your Zigbee devices with the Zigbee Coordinator, but the ZHA backup files using this “Open Zigbee Coordinator Backup Format” so it does not contain any data about application layers which technically have nothing to do with the Zigbee networking parts.
Read primary use case / purose here → https://github.com/zigpy/open-coordinator-backup#rationale
Zigbee2MQTT and vice versa will only be able to restore the backup of the Zigbee level, not a backup at the application level. To clarify; this new backup feature in Home Assistant’s ZHA integration will obviously never be specifically made to be a “ZHA to Zigbee2MQTT migration tool” nor a “Zigbee2MQTT or ZHA migration tool”. It is only that ZHA and Zigbee2MQTT both support saving the Zigbee network part of their backups using the same “Open ZigBee Coordinator Backup Format” standard which makes their “Zigbee network backups” compatible with each other for restoring/recovering the “Zigbee network” without having to re-join/re-pair all Zigbee devices.
The fact remains that this will still make migration between ZHA to Zigbee2MQTT or vice versa much easier than before since you do not need to re-join/re-pair all your Zigbee devices, which is not something that would usually take a very long time if have many devices and you have to first reset them all to factory default and then re-join/re-pair them one by one.
FYI, I believe the development of that was temporarily put on hold earlier this year due to other things that took priority however one of the developers of Home Assistant’s ZHA integration (and the zigpy libraries/projects on which it depends) did begin working on separating the ZHA integration into a client-server model (distributed application structure) using websocket in a similar architecture and integration method to that of what the Z-Wave integration (and Z-Wave JS add-on for it) already uses. If you are interested then check out dmulcahey’s work on ZHA WebSocket Server (“zhaws”) which can run as an addon, see https://github.com/zigpy/zha-websocket-server/ as well as the Home Assistant fork itself with ZHA WS support at https://github.com/dmulcahey/home-assistant/tree/dm/zha-ws
Thank you all for the update it is gratly appreciated
FWI after 3 weeks of learning and installing VMware exsi 6.7 on the hp ml350g6 and the creating 2 vms one of which was HAOS. after installing ha i started to configure it and realized that exsi only allows 1 usb to passthrough to HA.
Therefore tomorrow i will be learning and istalling as i go proxmox and repeat this journey all over again… yuppie
You can backup and restore to the new instance.
This is really interesting to me. I wonder if the work done in ZHA will lead to Z2M gaining the ability to change adapters. I guess an easy path though could be loading the backup on ZHA, migrating to a new adapter, then loading that backup to Z2M. (Though I’m not sure how to get the backup on Z2M at the moment.)
FYI, HA 2022.9 has now been released and release notes on news blog mention the new ZHA feature:
https://www.home-assistant.io/blog/2022/09/07/release-20229/#zigbee-backup-and-restore–migration
They have however updated text a little removing the mentioning of Z2M since the version was in beta, but Everything Smart Home took a screenshot of the beta release notes which as seen did mention it:
Interesting topic. Had the same question.
Although I like Z2M I don’t like the fact I need MQTT as well. I like more direct approaches to reduce overhead. For now I will stick to Z2M as ZHA misses a good interface that gives a nice overview of all devices.
However, if ZHA interface get’s more improved, I might make the switch to ZHA.
I did the „migration“ the last days. In the end i just reinstalled it and renamed the devices to the old names. Happy for now. But OTA is a bit weird. Is there a way to integrate a remote index.json ?
You can if using the ota_notify feature from unofficial “zha-toolkit” which can be installed via HACS:
But not yet in ZHA or zigpy unless a skilled Python developer want to code for zigpy and ZHA. See:
I was asking about Z2M 
@wbravin - I have more than one USB passed to a VM from the days of ESXi 4.x
If you didn’t move to proxmox yet - make sure the USB arbitrator is running.
Turn on SSH, and terminal into your server and follow the USB arbitrator instructions. If it doesn’t persist over a reboot, you have to edit the config file to set the arbitrator to autostart.
vi /etc/vmware/esx.conf
I just spent a whole day figuring that out - so if you need help, ask away
Hello all
Thank you for your reply
I gave up on ESXI, and istalled proxmox 7.2.
To this environment i added Home Assistant OS and passthrough z-wave and wifi usb.
HA is working as a charm. I added all my zwave and shelly devices to itwithout any issues (except for the ones created by me)
I plan to add a BT and zigbee usb to this mix early next year
On the proxmox server i added to date OPNsense HAOS and now i’m adding adding truenas as VM.
Thiis will now allow me to sell one of my server.
Thank you all for your help
What does not appear is the option to restore backup, I have a Z2M backup that wants to load the ZHA to make a migration.
Thanks!
Migration between different applications is not supported out-of-the-box, as currently, meaning that you can only restore backups in ZHA that were made from ZHA, just as you can only restore backups in Zigbee2MQTT that were made from Zigbee2MQTT. So even though ZHA and Zigbee2MQTT are using the same backup format for Zigbee network layer part (i.e. “Open ZigBee Coordinator Backup Format”) neither of those applications today has built-in support to extract that part in order migrate a Zigbee newoork backup made in another application, so a user can currently not perform a backup in Zigbee2MQTT and then restore that backup image in ZHA or vice versa as such backup images from each application not only include the Zigbee network layer backup but also includes the application layer backup. Regardless I doubt that backups will ever become compatible at the application layer (which includes device configuration), so you would probably just ever get to restore the Zigbee network backup in a migration which only includes paired/joined devices and network security information so that you do not have to manually re-pair/re-join any devices. Suggest that you post a new discussion in zigpy and zigbee2mqtt repositories to start discussions if you have a specific use case → zigpy/zigpy · Discussions · GitHub and Koenkk/zigbee2mqtt · Discussions · GitHub
A Youtuber called “SmartHomeJunkie” found out that the Conbee2 isn’t quite well working with z2mqtt, it has no problems with ZHA. The problem shows up in race conditions, and I’m facing them some times in following situations: When an automation uses a motion sensor to switch on a light for a certain time (Sonoff) and is waiting for the state “clear” to switch it off, the critical moment is at the end of that delay: The sensor already has the status “clear”, the detected motion (status “detected”) switches on the light for next period, but in a part of a second later the former signal “clear” is processed and the light turns off in the end. And SmartHomeJunkie says that (for example) Sonoffs coordinator works faster without this race condition, the Conbee2 isn’t proper driven by z2mqtt.
Up to now I can’t confirm that it’s working better, but I bought a Sonoff Dongle plus (older version) and now I’m searching for an elegant way to migrate from ConBee2 to Sonoff, without repairing all devices.
