I wonder if I should rename this custom_component and call it zha_toolkit.
What do “you” think?
Also, some functions I have been thinking about (I implemented some):
Possibility to trigger events when the service completes, fails or succeeds. That could help setup an automation requiring that the ZHA operation succeeded;
Possibilty to designate a state to write the result from (some) ZHA commands to - that could help for reading more than one attribute from a cluster - done for attr_read/attr_write/conf_report - reading multiple attributes not done;
Consider that the write operation only succeeds if the readback is equal to the written value (and an option to disable that condition) - done (tested for string type);
Maximum retry count - available for conf_report;
Will not implement - Timeout (combined with retry) to retry for 2 minutes maximum for instance;
Possibly: an id for the operation to avoid running the same command twice at the same time.
Hello there, let me first say that I am amazed at the level of expertise in this thread. I am one of the users who has a keen interest in home assistant but is by far not advanced enough to do most of the things explained here. I believe some referred to the user in the beginning of this thread that will be me or one of me
I stumbled upon this thread because I was looking for a solution to go from cc2531 to sonoff v3 dongle without having to redo all my entities and with that automations and with that lovelace dashboard. So I’m hoping that at some point in time there will be a one on one or step by step solution to actually get that done. like a Zigbee backup for dummies (no point intended )
I did try the smarthomethings solution but eventually got stuck somehow.
Nevertheless the question was about the naming. With Zigbee being such a widely used and broad standard. I would call it something like “a ZIGnificant toolkit” or maybe even “THE ZIGnificant Toolkit”
My two cents and thank you so much for creating things that less IT apt people can use and enjoy
I did not entirely create this, but I extended, documented and made it easier and more flexible from the UI.
Regarding the name, I think it should not be too long. Having ‘zha’ in the name reminds that it’s to be used with ‘zha’ and not zigbee2mqtt. ‘zig_toolkit’ could be ok though, and to continu the play of works, “MAziGNIFICANT Toolkit” could be fun too.
There’s already a guide above how to backup and restore, but possibly not easy enough.
Just installed true HACS and added the zha_custom: to configuration.yaml, made a automation from the blueprint but after running i don’t find a nwk_backup.json anywhere in my /config folder?
So I too did the back up and found the backup file as advertised. I am missing a few entities and i’m not sure which ones. But ok a few is less than all 31 of them.
What’s the next step?
Remove the ZHA integration? remove the cc2531, restart, add sonoff v3 dongle and restore?
Did step 1. Made the backup.
Step 2 removed the CC2531 USB coordinator.
Step 3 inserted sonoff in same socket.
Step 4 rebooted HA (so platform reboot iow the PI that runs my instance)
After step 4 HA came back online but zha.custom did not load. so a restore was not possible. did I read a step wrong?
The previous ZHA integration was saying was not loaded. I removed it and reinstalled ZHA. Then sonoff became visible and also saw most if not all of my devices. However that did not help cause all references in Lovelace as well as automations were not functional anymore.
For now I placed back the cc2531 and did a complete restore of HA. Hope that will set everything back.
Sad to report that it didn’t work at my end. Not sure why. The one usb cc2531 is indeed try/ACM0 and the sonoff get tty/usb while they are both in the same socket.
I did manage to get zha_custom to keep running while exchanging the dongles but then on doing a restore it give me an error message.
I’ll have to postpone for now unless there will be a clear cut seamless exchange possibility. Although I realize that is was already quite clear cut
Device paths are not “hard” linked to the physical port, but rather to the type of device and the port type linked to the driver, and the order in which the devices are detected.
Probably somebody with more technical savvy will find a way to do it.
I had one more go at this trying to beat the system.
Installed the Sonoff. restarted HA and made a backup using the zha_custom intgr.
Then I figured I’d modify the new backup file (from the sonoff) by copying the actual texts with devices into the new backup file from the old backup file. Of course not the entire text but only the devices.
Curious I have a Linkind leak sensor and I know from z2m it’s configurable for siren/led I’ve tried to construct the service call to try and change it but haven’t had any luck. here’s what I know:
Endpoint 1
Cluster Basic (0x0000)
Attribute 0x400a
ACK request TRUE
Manuf. specific TRUE
Disable default response TRUE
Data type 8-bit unsigned int
Data:
Siren disabled, LED disabled 0 (0x00)
Siren disabled, LED enabled 1 (0x01)
Siren enabled, LED disabled 2 (0x02)
Siren enabled, LED enabled 3 (0x03)
The attr_write requires the attribute type (an unsigned 8 bit number).
In your case it an uint8 - which is cod 0x20 or 32 in decimal.
service: zha_toolkit.execute
data:
command: attr_write
# You could replace this with the entity name if you like:
ieee: cc:86:ec:ff:fe:d8:43:b6
# Endpoint can be omitted if there is only 1 cluster of the given type on the device
endpoint: 1
# A bit suprised that cluster 0 is used for enabling/disabling a siren, but that's the doc.
cluster: 0
# Ok, you could also write this directly as 0x400a
attribute: 16394
# Ok, you cuould also omit the quotes
attr_val: '1'
# The type is required when writing
attr_type: 0x20
# The attribute is manufacturer specific - fill in th emanufacturer id.
manf: 0x????
# Optioinal, setting an event to get an idea of what happened from the UI.
# You can "Listen" to the 'my_write_event' from Developer Tools > Events
event_done: my_write_event
service: zha_toolkit.execute
data:
command: ezsp_backup
# Optional command_data, string added to the basename.
# With this example the backup is written to `nwk_backup_20220105.json`
command_data: _20220105
The core of the backup “wrapper” in the toolkit is in ezsp.py/function ezsp_backup . It may need adjustments.
that will be me or one of me 
Quite funny. I think you meant “no pun intended”.
