Hi everyone, I’ll try to explain the issue I ran into, for which I couldn’t find any solution online, but maybe someone else has already faced it.
I created a ZHA network using the Sonoff device in object as the coordinator, but for weeks I experienced continuous disconnections of Aqara sensors. After doing some research and finding very positive reviews, I bought an SLZB-06 and used ZHA’s migration feature to avoid having to rejoin all the sensors.
To avoid leaving the Sonoff unused and to strengthen the network, I followed the procedure to replace the Sonoff firmware from coordinator to router. The procedure always completed successfully using different firmware versions, but when I enable ZHA to join new devices and try to connect the Sonoff as a repeater, it shows up as a “new device” to be paired — but the device that appears seems to be the same SLZB coordinator.
Reading around, I understood that the migration might transfer some information related to the old coordinator (PAN ID?), but I thought this information would be cleared when flashing the firmware.
Can someone of you help me understand what’s going on and if/how this can be fixed?
Hi, thanks for your reply.
Do you have any suggestion/link to follow about the IEEE address changing procedure for Dongle-P to understand if it’s applicable also on Dongle-E?
One additional info I missed on my first post: I actually have a second zigbee network based on zigbee2mqtt with a second SLZB as coordinator, I don’t know if this could simplify the IEEE address change process (joining the Dongle-E on the z2m network and changing the address via z2m funcionalities, if there are any existing one).
It’s not, the utilities are entirely different. TI chipsets/firmware have always been easier to manage in this regard.
Upgrades to the ezsp coordinator firmware removed most of the ezsp restrictions for coordinators, but I don’t know if any of that functionality ever made it to the router firmware.
I answered an identical question yesterday & it seems the question keeps popping up every day because there’s no warning about this when you migrate. The below is my understanding of how it works.
Basically, a zigbee coordinator has 2 IEEE slots available:
Slot 1 is written in the factory and can never be changed.
Slot 2 is empty (null) by default & can be populated once. After that, you cannot change it.
Migration process copies Slot 1 IEEE address from your old coordinator, then pastes it into Slot 2 of your new coordinator.
This means that the original IEEE address exists on both devices & that only one of them can ever be present in your mesh. Otherwise, you’ll get conflicts (even if you managed to populate Slot 2 on your old device).
Essentially, this means you cannot use the old Sonoff in your mesh any more. I suggest you sell it online or give it to a friend so at least it doesn’t go in the trash.
that have as main objective the process to copy the IEEE address when migrating from an old to a new coordinator seamlessly, but, in essence, provides for the IEEE overwriting process.
I managed to reach the goal using the XZG Multi-tool, but:
the tool correctly handles the ZBDongle-E only with the Coordinator fw, so I had to re-flash the dongle with the last coordinator fw (8.0.2)
once connected the dongle in BSL i launched the IEEE read function
I wrote the same IEEE in the “New IEEE” field changing only the last two digits (the ZBDongle-E requires the “Force” option)*
reset the device and re-flashed the dongle with the last router fw
put the ZHA again in joining mode and… et voilà!! Finally the ZBDongle-E is back alive as router!!
*far as I understood the change of IEEE for ZBDongle-E using “Force” option seems to be a “once only” solution
Hope this will help for others who find themselves in the same situation.