Migrating Zigbee2MQTT and MariaDB to Home Assistant Yellow

Migrating from my HA Blue using Sonoff’s ZBDongle-P and Zigbee2MQTT as well as MariaDB failed.

I turned OFF the MariaDB add-on as suggested, performed a full backup, restored backup onto Yellow unit and MariaDB refuses to start. I could not get the Zigbee2MQTT add-on to see the new Zigbee module. I even tried the settings noted below:

data_path: /config/zigbee2mqtt
  enabled: false
  master: pty,raw,echo=0,link=/tmp/ttyZ2M,mode=777
  slave: tcp-listen:8485,keepalive,nodelay,reuseaddr,keepidle=1,keepintvl=1,keepcnt=5
   options: "-d -d"
  log: false
  base_topic: zigbee2mqtt
  port: /dev/ttyAMA1
  baudrate: 115200
  rtscts: false
  adapter: ezsp

Found on Reddit

No luck, then tried plugging in the Sonoff dongle and updated its ID in the configuration and a bunch of messages showed up, but failed to start Zigbee2MQTT.

Also, I could not figure out why MariaDB refused to start.

BTW: I did set the Yellow to the same Static IP address as the HA Blue unit was set to and I did shut down the Blue and unplugged it during the migration.

I have gone back to the Blue for now and will have to restart the Yellow to capture the logs for MariaDB and Zigbee2MQTT.

Very disappointed that this was not a smooth process or that there is not a step-by-step process to successfully migrate these over…

At this point I’m willing to give up and start over with adding all my 40+ Zigbee units to the new Yellow, but I would rather use Zigbee2MQTT on the Yellow.

Still, however, need MariaDB to startup after the migration.

OK… this is interesting…

I shut down my HA BLUE, moved the Sonoff Zigbee Dongle over to the HA YELLOW, plugged in the YELLOW, and it seems that after this reboot/power cycle, the MariaDB came up!

Also the Zigbee2MQTT addon this time started as well!

Many of the Zigbee units are reporting as OFFLINE, but some are starting to be seen and others not yet.

I now need to see if there is a way to heal the connections for units that I know are on and should not report as offline, but I could not find a way to force this using the add-on. Maybe time will heal these connections?

NOW, the challenge is how to migrate Zigbee2MQTT from the Sonoff dongle to the internal Zigbee router using Zigbee2MQTT and not ZHA…

I would leave it a while, then on any remaining I would push the pairing button to wake them up (and perhaps wait a while again) then re-pair them.

I wouldn’t, given the reports I have read about the range of the inbuilt zigbee co-ordinator.

1 Like

Well I gave it a while and then decided to re-pair the units reported as offline. This worked. As a matter of fact I did not even have to delete them first. They just readded with the same name. Makes sense as the system knows their ID.

As far as the internal Zigbee unit vs the external one… If I stay with the external one, then did I just waist money buying a Yellow and I should have just stayed with the HA Blue?

I’ll have to research the internal radio.

I would still like to be able to make the move to the internal using Zigbee2MQTT to try it out. I could always switch back to the external. So I’m still on the hunt on how to cleanly migrate from the external dongle to the internal Zigbee on the Yellow.

To be fair, HA added migration for ZHA roughly around the time Yellow started to ship. The HA devs can’t be responsible for a third party app.

EZSP (the Yellow chip) support in z2m is still labeled experimental and is without backup/restore of any kind.

There are enough tools out there to do it, if your comfortable hacking at the command line. I migrated from ezsp to znp when I was on ZHA before there was official support. Going the opposite direction could likely work.

No matter whether you use z2m or zha, it won’t fix the reports of poor range.

Well I had to make a choice when moving away from the HUE Zigbee install/Hub and when I checked online I found that Zigbee2MQTT exceeded the amount of devices it supported compared to ZHA. So the choice was made. I purchased the Sonoff dongle and installed Z2M and its been working great ever since.

Migrating it from the HA Blue to HA Yellow, adjusted config to point to the dongle’s new port, and at first it seemed not to working, but after a reboot / power cycle, it surprisingly came up. I had about 3 out of the 45 devices that needed to be re-paired to the dongle. The majority of the devices maintained their Location setting as well. Only about 5 had to have their location set.

I may someday move to ZHA once they are able to come closer to the number of devices it supports. I guess I could always check the devices I have against the ZHA list of supported devices and maybe migrate from Z2M to ZHA…

Love the amount of acronyms in this one :slight_smile:

Well, I guess I need to hunt for these tools…

So there are reported “range” issues with the internal Yellow Zigbee chip? Worse than a Hue Hub? Are the channels used and levels adjustable as with Z2M and the Sonoff dongle using ZHA and the Yellow Chip?

I would still like to try and see if it will meet my needs as is. I could always migrate back to the Sonoff dongle.

I have seen two Home Assistant Yellow - #276 by scator and Home Assistant Yellow - #278 by wout_PN

1 Like

Can’t speak directly to the Yellow since I don’t own one.

You can set the channel in ZHA. It might require yaml, but it’s been so long since I configured mine that may have changed.

I would expect the ability to change power level since it’s supported on the TI chips, but don’t really know.

My general advice when changing between ZHA and z2m is to run both side by side and migrate at your leisure. Its a much better approach than risking breaking everything and trying to fix it all in a mad rush.

Since you already have the coordinator sitting idle, setup ZHA and move a few devices over to test.

I don’t know if any real device count restraints in ZHA?

Certainly not in the 45 device range.

There isn’t really a list. Blakadder is about as good as it gets, but there has been discussion of creating one among the community.

With z2m, EVERYTHING needs a converter written, so updating the device list is just a pre-req of merging the device support.

ZHA was designed to be more standards compliant and to “just work” with standards compliant devices. I think in reality there may be more devices that require quirks than not, but there wasn’t the automatic list building from the start.

Its not the total number of active devices, its the number of “supported” devices that seems higher on Z2M.

Yes I have seen the Blakadder list…

There’s pros and cons to both and even a 3rd option… I read and watched a number of sources. This one was interesting:


Seems on Con for ZHA is that if HA goes down, so do all the Zigbee devices. Whereas Z2M seems to run independent of HA. Have not looked further into this. Is it possible the Dongle is uploaded with the Zigbee network like say a Hue Hub and can run independent and ZHA does not upload and keeps it all within HA and just uses the dongle as a radio? Not sure, as I need to look further into it.

Personally, I had only one initial installation issue with Z2M and that was the instructions I followed wrongly stated how to set the port ID. Then I found better help and it was:

port: >-
     /dev/serial/by-id/usb-ITead_Sonoff_Zigbee_3.0_USB_Dongle_Plus_....(bunch of random stuff here)

Adding devices and managing them has been easy as well.

Someone suggested I keep both and run them side-by-side and maybe move a few devices over to ZHA. I wonder how to Zigbee radios so close together would react. I assume I need to use a different channel on each, but it should work.

Newer devices may be supported marginally faster on z2m. Anything remotely popular will be added by both. Both dev teams seem pretty good about responding to new device requests.

Many new devices will work out of the box with ZHA without need of waiting for a converter or quirk to be written. I recently bought a newly released plug. It was standards compliant, so ZHA supported it automatically (as would have a months/years old ZHA install). With z2m, I had to wait for the converter.

The devices don’t really go down. Bound devices will continue to work if HA/ZHA and the coordinator are down. It’s more about missed events from battery devices while HA is down.

Missed event scenario:

  1. Door is closed.
  2. Restart HA.
  3. A door is opened during restart and remains open.
  4. HA restart completes.

After the restart, with ZHA, HA will still see the pre-restart “closed” status of the door. With z2m, HA query after restart z2m will update HA with the current status (assuming z2m remained running during the HA restart). Again, mostly applicable to battery devices, most mains devices will update when ZHA queries after restart. Battery devices won’t update until the state changes or next scheduled check-in from the device.

It will work either way.

If the intent is testing or long term coexistence, I’d keep the separate zigbee nets on separate channels. Always strive to to minimize interference.

Using the same channel for both will work, but I would only recommend it short term during a migration. If you’re migrating z2m to zha (or the reverse) where the current zigbee net is on channel 25 and channel 25 is the best option for your environment, go ahead and set the new integration to channel 25, migrate, and then re-configure or decommision the old integration. Long term keep things as clean as possible.

I mostly moved from ZHA to z2m, but have kept both running side by side for year or so.

My Z2M is already using channel 25. According to what I have found, the default ZHA channel is 15, so I’m leaving it at 15.

I have installed ZHA using the Yellow Zigbee radio and its up. No devices yet moved to it.

Hmmm, can I install Z2M on two different radios on the same HA installation? Hmmmm…

This has been a great discussion…

Looks like your actually using Z2M as well…