It’s disappointing to hear that you also lost location tagging of devices, and suggests there is a bug/ missing feature in the restore or migration tool.
Strangely, some of my Zigbee automations kept working as they remained linked to the device which is odd as I tend to use entity_id (name) rather than device_id (GUID) in automations.yaml. This might help you reinstate previous config, but it’s still a PITA to loose bulk config especially with a structured naming convention.
Thanks James, the positive aspects of this migration:
The zigbee device is far more powerful than the conbee device I had, the yellow is currently on the bench in my workshop which is at the back of the house and most connected straight away. The only issue with connection has been a bunch of Aqara leak sensors which are unavailable.
There some additional entities that were not there previously which need some investigation to understand their potential use.
The whole system is far more efficient with about one third of the power requirement my NUC expected.
All my entities had the format device_type.room_description e.g. binary_sensor.utility_co with the device name retaining whatever the default was e.g. HEIMAN COSensor-EM.
Migration resulted in my CO sensor entities from the device name: binary_sensor.heiman_cosensor_em_iaszone
It’s a shame the migration tool did not copy the entities names from the zigbee database as well. So a bit of effort required to go through the 340+ entitites to rename them so the automations continue to function as designed.
NVMe Storage
I bought a NVMe disk to supplement the storage provided by the Yellow, on booting I noticed the data was migrated to the eMMC storage. This can be corrected by going into “Settings” > “System” > “Storage”, clicking on the “:” top right of the screen and clicking “Move Datadisk” a dropdown should list the NVMe installed, a reboot and the storage is now on the much larger disk space.
As you experienced, only the data partition is moved, not the os. Much of these postings could be edited and added to the Community Guides where tutorials are hosted.
Update on progress, my Aqara devices (door and window sensors, leak sensors etc) are dropping off the network some hours after I have reconnected them. I saw this behaviour with my conbee in the early days, it takes multiple reconnections before the network stabilises. So probably not an issue with Yellow specifically.
Zigbee has a “network heal” process like Z-Wave doesn’t it?
The process isn’t mentioned in the ZHA docs, although the comment about pairing in the final destination (e.g. not next to the coordinator) was interesting - suggests the mesh is more fixed.
Z-Wave typically runs as a batch job at 02:00AM to avoid such disruption.
My engineer’s reading of the badge “SilLabs IoT Incubator” is still “beta firmware”, so as well as possible dual-stack Zigbee + Thread support (both IEEE 802.15.4), there’s no doubt some optimisations to land as well. I hope the apparent high demand for the Yellow and SkyConnect means Nabu Casa will have the resources they need to produce the best platform possible.
My experience with Conbee II was that I had better stability if I tried to onboard a new device through an existing router rather than through the co-ordinator. I don’t know about a “network heal” process. Zigbee I think reorganises itself over time to balance loads on various routers and the co-ordinator. With a max number of devices per router.
Looking into why my devices did not carry their entity names across, the json backup ZHA creates seems to only contain network attributes e.g. network key, node attributes and pan_id. I cannot see any device or entity information within the json. So maybe this is in the HA Backup but it does not seem to get to the new instance of HA. I wonder if you need to first load the ZHA backup to create the network then load the HA backup for entity and device data?
Update, I was away over the weekend and all the Xiaomi devices dropped off the network again. While I experienced this early in my HA career using Conbee II and phoscon, ZHA has been relatively solid since moving. Will start pairing them again and see what happens. Why is there no specific Yellow community section and somewhere to report issues?
Your Zigbee network mesh will repair itself automatically given time and I am not sure there is any way (e.g. zigbee or zigpy-cli commands) to manually trigger/initially or speed up the repair process, that would have to be a question for the zigpy/ZHA developers here → https://github.com/zigpy/zigpy/discussions/ and a related question was previously handled here but much have changed since then so might not be the same today → https://github.com/zigpy/zigpy/discussions/614
So I still do not know what to make of the built-in ZigBee module. Supposedly this is the non plus ultra, but compared to the old Smartlight Coordinator, I have significantly more problems
Does anyone know how I can disable the Zha Discovery? I use the module with Z2M, but get after each restart the ZHA integration offered to install. However, it can not be clicked away or deactivated
Any update on the issue on the issue that user defined entity id naming is lost after zigbee radio migration? I migrated to the yellow yesterday and migrated the radio from ConBee II to the internal chip and as others reported here: entity ids and names are set to default and area relation is gone. With ~60 devices and ~350 entities this is just not the way to go. So I switched back to ConBee for the moment which restored custom naming after restoring a HA backup.
Make sure got enough mains-powered Zigbee Router devices (as those act as Zigbee repeaters / range extenders) and wait around 24-hours for all Zigbee Router devices in the Zigbee network mesh to update connections. Generally, battery-powered devices should be paired/joined last when building a Zigbee network from scratch as they usually do not move to Zigbee Router devices connected after them, alternatively re-pair/re-join those battery-powered devices again lastly. Also be sure to follow best practice guidelines → Generic best practice tips on improving Zigbee network range and general stability · zigpy/zigpy Wiki · GitHub
See related new core and frontend pull requests adding unique ID to Yellow hardware for ZHA discovery
Use a unique ID for the config flow when the Yellow is discovered. With home-assistant/frontend#14281, this allows for the ZHA discovery entry to be ignored.
This also correctly sets the name of the discovery card:
Add hardware as a config flow discovery source.
Without this change, discovered Yellow cannot be ignored:
I received my yellow recently. I do not find an information how to import an existing mysql/mariadb.
My old system is a homeassistant.CORE installation which I still love. but is there a way currently how to connect to the mariadb-addon (docker) or an import mechanism?
otherwise I would love to install a standard raspian or something else and install homeassistant.CORE like the old way…
thanks
Marc
Sorry, i have removed my post and created another one… it was a long strech … (i’m migrating from supervised to HA OS and eventually hopefully to HA yellow
