my bad. had bellows on the mind.
you should be utilize the z2m backup in the data folder. but if you want some extra insurance you can use the zigpy-tools.
Puddly’s docs for the tools are excellent (and my goto for reference often) Using the virtual env is the way to go as described. then you’d want to do the network backup method:
https://github.com/zigpy/zigpy-znp/blob/d37ac29ea7f164e43445c0a87b5b85dd0067de0d/TOOLS.md#tools
Haven’t yet done the update, but another development - I’ve just had 2 battery remotes die (battery went dead). I’ve replaced with new batteries, and now they aren’t communicating either!
I also originally had issues when switching from my husbzb-1 coordinator to tube’s coordinator. even when everything was paired things kept dropping off. I eventually but the bullet and did an nvram reset and changed the zigbee channel to 25 ( based on a network scan). That seemed to fix everything for me. Planning to upgrade the firmware soon as well
I’ve now partially resolved this issue. By turning of all my zigbee devices I am now able to pair the problematic devices again, however once paired, they then remove themselves again. I’ve tried restarting the PoE coordinator (using the restart option in the webpage) and also stopping and starting zigbee2mqtt but it still happens. Am I missing something?
Are these end devices far from your coordinator? It’s possible that they would pair but drop off if there are not enough repeaters in your network.
In my experience, zigbee is always finicky no matter the platform you use. Sometimes it’s just best to reset everything (including the coordinator, integrations, and devices) and start from scratch to avoid problems in the future
No they are less then 30cm away!
This is almost always related to interference. I know you’ve had difficulty running the zigpy-znp tools but an energy scan would be really useful.
If you can post the output you get when trying to run them in the GitHub issue I or Puddly may be able to help.
@tube0013 - Just curious, what is the preferred/recommended method for changing the Zigbee channel on a CC2652P based coordinator? It seems like the ZigPy tools only allow for creating a new network using the default channel 15, and no obvious option for changing the channel on the fly.
The only possible procedure I can come up with is to nvram reset the coordinator so that it does not have a Zigbee network on it, then add to the Home Assistant configuration.yaml something like the following:
zha:
zigpy_config:
network:
channel: 20 # What channel the radio should try to use.
channels: [15, 20, 25] # Channel mask
Then, add the ZHA Integration in Home Assistant, and hopefully it will create a new Zigbee network using the channel specified above. Afterwards, re-pair all of the Zigbee devices.
Is this the recommended procedure? I haven’t tried it yet, so I just taking an educated guess at this point.
I find it a little disappointing that one cannot change the Zigbee channel on the fly, which is possible on other platforms like Hubitat, for example, without having to rebuild the entire network. Does Zigbee2MQTT allow for on-the-fly Zigbee channel changing? I have only messed around with ZHA to date.
Thanks!
I know it’s been talked about. puddly is working on a unified zigpy_cli which will work with all radio libs for a lot of these functions. once that is done it may be easier to bring into ZHA itself. One of the current issues is al the underlying radio libs do a lot of this differently.
Anyway the process I’d recommend:
Use the zigpy-znp tools and pull a Network backup.
Open the Network backup.json and modify the channel.
Restore the modified Network backup.json to the coordinator.
Restart mains powered devices - They may find the new channel themselves.
Then reset any other devices.
(probably most end devices and some mains powered ones - maybe all?).
Thank you for the quick reply!
FYI - anyone with one of my PoE coords purchased after December 15 - I’m finding the ESPHome FW build is not allowing successful flashing of the CC2652 - it will always crap out. rolling back the ESPHome FW to the bin here tube_gateways/tube_zb_gw_cc2652p2_oliemex_poe.bin at 0452c5d9fb7f6db2ac4dabc61f40c47416aaf62c · tube0013/tube_gateways · GitHub will let it complete fine. I’ve sent emails to anyone who has purchased since then. If you’ve manually updated this will likely cause issues as well
I’ve now solved my previous problems, so many thanks for your advice so far! By turning off my whole zigbee network I was able repair the devices successfully. Think I read somewhere about a constant remove command being sent until this was done, so shutting down the network and restarting it all worked. I also did an energy scan with my old USB coordinator which showed Channel 11 was very low interference (averaged about 4%). I was already using 11 so stuck with it at the moment.
However, overnight, a new problem has presented itself. Having got all devices repaired and working successfully, quite a few devices decided to stop communicating overnight. The only way to get them talking again was by removing and replacing the batteries (the batteries are not low, as they were new yesterday). All have strong links to coordinator or routers.
I have at least 8 routers + my PoE coordinator which are evenly spread in the house. My Zigbee network shows plenty of healthy links.
Any ideas?
Does anyone know how to access the espHome over serial on the cc2652p2 coordinator? I’m trying to update to the 20211217 firmware but I can’t enter bootloader mode. I moved the jumpers on the pins all the way out and even tried holding the BSL1 button before plugging in the coordinator. I know I identified the com port correctly the bsl tool reads the baud as 500000. The error I get when I try to flash is “Timeout waiting for ACK/NACK after Synch (0x55 0x55)”. My assumption is this error appears due to not being in bootloader mode.
This is the coordinator : CC2652P2 Zigbee to Ethernet Serial Coordinator | Tube's ZB Store
Jumpers on the middle 2 pins. (later rev of the board made this more clear).
https://github.com/tube0013/tube_gateways/tree/main/V2_tube_zb_gw_cc2652p2#zigbee-connection-via-usb
Hold BSL while plugging it in or just hold it down after plugged in and hit the ZRST button that should do the same thing.
Can one just backup the z2m folder and that is considered a good enough backup for the firmware update without having to re-pair devices afterwards? I’ve tried using bellows and also the zigpy-znp tools with python and both give errors trying to connect via the ip address.
I think you can confirm that a backup.json or similar is within the data folder.
If that is the case my understanding is when you plug in a coordinator that is “new” or erased which is what will happen during the FW update Z2M will just restore that backup when starting up.
I’d prefer someone who has done this successfully to confirm though as I have not.
Worked like a charm thanks!
I will try this tonight just to confirm for myself as well.
I always restart z2m via the frontend to ensure the coordinator_backup.json is up to date first.
then stop z2m, update firmware then start z2m.
Can confirm that stopping z2m, updating firmware and restarting z2m results in everything being restored to the controller.
