Hedda
(Hedda)
May 2, 2022, 10:52am
30
Hedda:
btw, know that puddly who develops zigpy-znp is planing to implement unified backup into zigpy-cli that will mean that once implemented you can use same backup command to backup all radio brands. See:
https://github.com/zigpy/zigpy-cli/pull/2
FYI, many testers testing has confirmed that patches for the mentioned pull request work with ConBee:
https://github.com/zigpy/zigpy-cli/pull/2
Again, idea is backup and restore will work via “zigpy-cli” regardless of Zigbee Coordinator make/model.
Has there been any progress with zha coordinator backups?
I’m relatively new to ZIgbee and this would be a great feature to have.
Hedda
(Hedda)
June 23, 2022, 1:51pm
32
Yes, there has at least been a lot of progress on the underlying zigpy libraries that ZHA uses as a dependency and all zigpy libraries are currently in the process of being updated to a new radio API for zigpy which will once fully merged among other things introduce a new network backup/restore utility in " zigpy-cli " for any zigpy radio library for Zigbee Coordinator adapters/dongles that implementing that for the new radio API.
The initial support will include a unified radio command line interface and using standard network backup format for the zigpy radio libraries that support Zigbee Coordinator adapters/dongles based on Silicon Labs, Texas Instruments, and deconz (ConBee/RaspBee) serial protocols, (leaving someone else having to volunteer to add backup/restore code for XBee and ZiGate radio libraries when the new zigpy radio API is in place).
I also believe that once patches are merged on the zigpy side some other volunteering developer(s) would still have to step-up and implement the use of that new network backup/restore utility in “zigpy-cli ” in the ZHA integration (which is component part of Home Assistant core) and the Home Assistant frontend for the UI interface, (and the developers working on the zigpy part for this have in the past mostly worked on the core/backend parts and not the frontend UI/GUI parts).
To follow the status of the underlying zigpy development see patches and pull requests linked here:
https://github.com/zigpy/zigpy-cli/pull/2
zigpy:dev
← puddly:puddly/zigpy-radio-api
opened 05:12PM - 14 Nov 21 UTC
This change introduces a network backup/restore utility for any adapter implemen… ting the new radio API:
- [x] zigpy: https://github.com/zigpy/zigpy/pull/848
- [x] zigpy-znp: https://github.com/zigpy/zigpy-znp/pull/97
- [x] zigpy-deconz: https://github.com/zigpy/zigpy-deconz/pull/172
- [x] bellows: https://github.com/zigpy/bellows/pull/445
The following adapters also implement the new radio API but their firmware does not allow much network information to be read, making this form of migration impossible:
- [x] zigpy-zigate: https://github.com/zigpy/zigpy-zigate/pull/117
- [x] zigpy-xbee: https://github.com/zigpy/zigpy-xbee/pull/123
---
<h1 id="instructions">Instructions</h1>
You'll need access to a Python environment. zigpy-znp has documentation [that describes how to do this](https://github.com/zigpy/zigpy-znp/blob/dev/TOOLS.md#installation) for every common platform.
```bash
# Make a new venv, these packages are heavily modified
virtualenv -p 3 venv # Python 3.7 or above is required
# Or python3 -m venv venv (if `virtualenv` isn't installed)
source venv/bin/activate
# Install HA OS packages (only if using HA OS)
apk add gcc musl-dev libffi-dev
# Install zigpy-cli
pip install git+https://github.com/zigpy/zigpy-cli.git
# Back up the old radio. Note: this backup format will change in the future.
# Conbee/Raspbee
zigpy -vv radio deconz /dev/serial/by-id/... backup deconz.json
# CC2531, CC2652, etc.
# zigpy -vv radio znp /dev/serial/by-id/... backup znp.json
# HUSBZB-1, EFR32, etc.
# zigpy -vv radio ezsp /dev/serial/by-id/... backup ezsp.json
# Restore a backup to the new one
zigpy -vv radio znp /dev/serial/by-id/... restore deconz.json
# zigpy -vv radio ezsp /dev/serial/by-id/... restore deconz.json
# zigpy -vv radio deconz /dev/serial/by-id/... restore deconz.json
# Leave the virtualenv
deactivate
```
Once that's done, edit `/config/.storage/core.config_entries` (take a backup of the file first!) and change the coordinator's `path` to the new radio's `/dev/serial/by-id/...` path. If you're switching to a CC2652, make sure to delete the `flow_control` key and set the `baudrate` to `115200`.
and zigpy developers have discussed the concepts and ideas about unified backup CLI + format here:
https://github.com/zigpy/zigpy/issues/557
opened 08:16PM - 23 Nov 20 UTC
closed 03:36PM - 14 Jul 22 UTC
At the moment both [bellows](https://github.com/zigpy/bellows/) and [zigpy-znp](… https://github.com/zigpy/zigpy-znp/) have their own command line tools. I think it would be beneficial to replace both with a unified `zigpy` command that interfaces with new methods on `ControllerApplication`. This'll reduce duplicated code within the various radio libraries and make it easier to expose features that aren't yet available in ZHA's web interface.
I will have to test this more thoroughly but I believe the API-specific commands can actually be sent as ZDO requests to the coordinator, at least with ZNP, allowing for network scanning and channel changing to possibly be done in a radio-agnostic way.
For example:
```shell
$ zigpy [ezsp|znp|...] --device /dev/... --database ./zigbee.db [create|destroy|scan|...] [--arg1 ...]`
```
Some possible commands (most already exist as a part of `bellows`):
- `info` (all are properties exposed by `ControllerApplication`, with the exception of `network_key`)
- `create` (`ControllerApplication.form_network)`
- `destroy` (may require a new method, or we can combine `create/destroy` into `reset`)
- `backup`
- `restore`
- `scan` (and `scan -e`)
- `update` (channel the channel or the network key and broadcast it to all routers)
- `sniff` (only supported by bellows but it should be easy to support arbitrary additional commands)
- Some minimal interface for just running the base `ControllerApplication`, permitting joins, sending commands, and so on? `IPython` is now `asyncio`-based so it may be a good base.
The `bellows` backup JSON contains enough information to migrate networks between coordinators so I think we should also come up with a common JSON backup format as well:
- Since JSON doesn't support bytestrings, we have a few possible representations: `[222, 188, 58, 18]` is the easiest to serialize but decimal is unreadable when the common representation is hex everywhere else. Some alternatives are `"0x123ABCDE"` and `"12:3A:BC:DE"`. ZNP uses the former, but I sort of prefer the latter, as it can be pasted into Wireshark.
- Add a top-level `"radio"` key that identifies the generating radio library, its current version, and some hardware information. It may also be useful to hold radio-specific backup data (possibly NVRAM for Texas Instruments radios?).
I think ZiGate and possibly the Conbee II also expose enough network information to make this useful, though EZSP's inability to change the EPID more than once will be an issue. Is there a way to detect if this has never been done before on new hardware?
Any thoughts or suggestions?
Hedda
(Hedda)
June 30, 2022, 7:25pm
33
Hedda:
Yes, there has at least been a lot of progress on the underlying zigpy libraries that ZHA uses as a dependency and all zigpy libraries are currently in the process of being updated to a new radio API for zigpy which will once fully merged among other things introduce a new network backup/restore utility in " zigpy-cli " for any zigpy radio library for Zigbee Coordinator adapters/dongles that implementing that for the new radio API.
The initial support will include a unified radio command line interface and using standard network backup format for the zigpy radio libraries that support Zigbee Coordinator adapters/dongles based on Silicon Labs, Texas Instruments, and deconz (ConBee/RaspBee) serial protocols, (leaving someone else having to volunteer to add backup/restore code for XBee and ZiGate radio libraries when the new zigpy radio API is in place).
I also believe that once patches are merged on the zigpy side some other volunteering developer(s) would still have to step-up and implement the use of that new network backup/restore utility in “zigpy-cli ” in the ZHA integration (which is component part of Home Assistant core) and the Home Assistant frontend for the UI interface, (and the developers working on the zigpy part for this have in the past mostly worked on the core/backend parts and not the frontend UI/GUI parts).
FYI, ZHA’s zigpy dependencies have now been updated with the mentioned new zigpy radio API that introduces a network backup/restore utility via “zigpy-cli ” (initially for zigpy-znp, bellows, and zigpy-deconz radio libraries) and those libraries has been bumped in Home Assistant core and thus the backend side needed to make this happen will be available is the upcoming Home Assistant 2022.7 release.
https://github.com/home-assistant/core/pull/73964 has the comment “This incorporates the new radio API for zigpy, which will allow for network parameter changes and backup/restore in a future patchset. ”
Again, I still think that some other volunteering developer(s) might have to step up and implement the use of that new network backup/restore utility in “zigpy-cli ” in the ZHA integration (which is component part of Home Assistant core) and the Home Assistant frontend for the UI interface, (as as again gooing on historical UI features the developers working on the zigpy parts for this have in the past mostly worked on the core/backend parts and not the frontend UI/GUI parts). Read → https://github.com/zigpy/zigpy-cli/pull/2
1 Like
isibizi
(Ismail)
July 8, 2022, 10:43am
34
Is it possible now to move from CC2531 to ConBee II or RaspBee ? I cant find informations about that.
Hedda
(Hedda)
July 10, 2022, 9:31am
35
Yes I believe that should be possible now, however not yet from Home Assistant, but using zigpy-cli command-line tool for backup and restore, again see discussions in ZHA libraries will soon support ConBee/RaspBee backup and restore that can be used for Zigbee network migrations and https://github.com/zigpy/zigpy-cli/pull/2 (as well as https://github.com/zigpy/open-coordinator-backup ) so maybe post to zigpy-cli discussions if run into problems Discussions · zigpy/zigpy-cli · GitHub
Tip! If you have not yet purchased a replacement for that CC2530/CC2531 based adapter then keep in mind that TI CC2652 (CC2652P) or Silabs EFR32 (EFR32MG21) based adapters are generally recommended before ConBee/Raspbee for better performance when not using Dresden Elektronik’s official deCONZ/Phoscon Zigbee Gateway software for them. For CC2652 hardware links see → Supported Adapters | Zigbee2MQTT
Noto
(Maarten)
July 29, 2022, 11:56am
36
It’s possible but annoying to make the backup from HA. In my config I have this:
shell_command:
zigbee_backup: python -m zigpy_znp.tools.network_backup /dev/serial/by-id/usb-ITead_Sonoff_Zigbee_3.0_USB_Dongle_Plus_9493876151c9eb11b7dxxxxxxxx-if00-port0 -o network_backup-"`date +"%Y-%m-%d"`".json ; cp zigbee.db zigbee-"`date +"%Y-%m-%d"`".db
Then you’ll need to:
disable the ZHA integration
run the zigbee_backup from developer tools
enable the ZHA integration
reboot to get your zigbee up and running.
I haven’t found a way to disable or enable the integration using a HA service.
le_top
July 30, 2022, 9:35pm
37
You can backup znp using zha-toolkit - there is a blueprint for it - you have to install zha-toolkit of course which is easiest to do using HACS.
finity
July 31, 2022, 4:57pm
38
There are two blueprints for backups:
.
name: Daily Coordinator Backup - Monthly rotation
description: >-
Backup Zigbee Coordinator Configuration (ZNP/ezsp(bellows)),
monthly rotation
.
.
action:
- service: zha_toolkit.execute
data:
command: backup
and the other:
.
name: Daily ZNP Backup - Monthly rotation
description: Backup ZNP Zigbee configuration, monthly rotation
.
.
action:
- service: zha_toolkit.execute
data:
command: znp_backup
but in the docs the two commands are specified as either:
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
or:
service: zha_toolkit.znp_backup
data:
# Optional command_data, string added to the basename.
# With this example the backup is written to `nwk_backup_20220105.json`
command_data: _20220105
Which of the four should it be?
Hedda
(Hedda)
August 3, 2022, 2:28pm
39
FYI, zigpy and ZHA developer @puddly have now submitted initial patches for ZHA in Home Assistant core (backend) and frontend (GUI) for both automatic and manual Zigbee network backup + restore features/settings; “Implements the websocket API for listing, creating, and restoring ZHA network backups. This also adds a ZHA backup platform, which initiates network backup whenever a HA backup is created. ” + “Add a new tab to the ZHA interface to show the current network settings to allow them to be backed up/restored. ” See these pull requests for reference:
home-assistant:dev
← puddly:puddly/zha-backup-restore
opened 11:49PM - 26 Jul 22 UTC
<!--
You are amazing! Thanks for contributing to our project!
Please, DO N… OT DELETE ANY TEXT from this template! (unless instructed).
-->
## Proposed change
<!--
Describe the big picture of your changes here to communicate to the
maintainers why we should accept this pull request. If it fixes a bug
or resolves a feature request, be sure to link to that issue in the
additional information section.
-->
Implements the websocket API for listing, creating, and restoring ZHA network backups. This also adds a ZHA backup platform, which initiates network backup whenever a HA backup is created.
## Type of change
<!--
What type of change does your PR introduce to Home Assistant?
NOTE: Please, check only 1! box!
If your PR requires multiple boxes to be checked, you'll most likely need to
split it into multiple PRs. This makes things easier and faster to code review.
-->
- [ ] Dependency upgrade
- [ ] Bugfix (non-breaking change which fixes an issue)
- [ ] New integration (thank you!)
- [x] New feature (which adds functionality to an existing integration)
- [ ] Deprecation (breaking change to happen in the future)
- [ ] Breaking change (fix/feature causing existing functionality to break)
- [ ] Code quality improvements to existing code or addition of tests
## Additional information
<!--
Details are important, and help maintainers processing your PR.
Please be sure to fill out additional details, if applicable.
-->
- This PR fixes or closes issue: fixes #
- This PR is related to issue:
- Link to documentation pull request:
## Checklist
<!--
Put an `x` in the boxes that apply. You can also fill these out after
creating the PR. If you're unsure about any of them, don't hesitate to ask.
We're here to help! This is simply a reminder of what we are going to look
for before merging your code.
-->
- [x] The code change is tested and works locally.
- [x] Local tests pass. **Your PR cannot be merged unless tests pass**
- [x] There is no commented out code in this PR.
- [x] I have followed the [development checklist][dev-checklist]
- [x] The code has been formatted using Black (`black --fast homeassistant tests`)
- [x] Tests have been added to verify that the new code works.
If user exposed functionality or configuration variables are added/changed:
- [ ] Documentation added/updated for [www.home-assistant.io][docs-repository]
If the code communicates with devices, web services, or third-party tools:
- [ ] The [manifest file][manifest-docs] has all fields filled out correctly.
Updated and included derived files by running: `python3 -m script.hassfest`.
- [ ] New or updated dependencies have been added to `requirements_all.txt`.
Updated by running `python3 -m script.gen_requirements_all`.
- [ ] For the updated dependencies - a link to the changelog, or at minimum a diff between library versions is added to the PR description.
- [ ] Untested files have been added to `.coveragerc`.
The integration reached or maintains the following [Integration Quality Scale][quality-scale]:
<!--
The Integration Quality Scale scores an integration on the code quality
and user experience. Each level of the quality scale consists of a list
of requirements. We highly recommend getting your integration scored!
-->
- [ ] No score or internal
- [ ] 🥈 Silver
- [ ] 🥇 Gold
- [ ] 🏆 Platinum
<!--
This project is very active and we have a high turnover of pull requests.
Unfortunately, the number of incoming pull requests is higher than what our
reviewers can review and merge so there is a long backlog of pull requests
waiting for review. You can help here!
By reviewing another pull request, you will help raise the code quality of
that pull request and the final review will be faster. This way the general
pace of pull request reviews will go up and your wait time will go down.
When picking a pull request to review, try to choose one that hasn't yet
been reviewed.
Thanks for helping out!
-->
To help with the load of incoming pull requests:
- [ ] I have reviewed two other [open pull requests][prs] in this repository.
[prs]: https://github.com/home-assistant/core/pulls?q=is%3Aopen+is%3Apr+-author%3A%40me+-draft%3Atrue+-label%3Awaiting-for-upstream+sort%3Acreated-desc+review%3Anone+-status%3Afailure
<!--
Thank you for contributing <3
Below, some useful links you could explore:
-->
[dev-checklist]: https://developers.home-assistant.io/docs/en/development_checklist.html
[manifest-docs]: https://developers.home-assistant.io/docs/en/creating_integration_manifest.html
[quality-scale]: https://developers.home-assistant.io/docs/en/next/integration_quality_scale_index.html
[docs-repository]: https://github.com/home-assistant/home-assistant.io
home-assistant:dev
← puddly:puddly/zha-network-settings
opened 11:00PM - 27 Jul 22 UTC
<!--
You are amazing! Thanks for contributing to our project!
Please, DO N… OT DELETE ANY TEXT from this template! (unless instructed).
-->
## Proposed change
<!--
Describe the big picture of your changes here to communicate to the
maintainers why we should accept this pull request. If it fixes a bug
or resolves a feature request, be sure to link to that issue or discussion
in the additional information section.
-->
Add a new tab to the ZHA interface to show the current network settings to allow them to be backed up/restored.
Unmerged Core PR: https://github.com/home-assistant/core/pull/75791
## Type of change
<!--
What type of change does your PR introduce to the Home Assistant frontend?
NOTE: Please, check only 1! box!
If your PR requires multiple boxes to be checked, you'll most likely need to
split it into multiple PRs. This makes things easier and faster to code review.
-->
- [ ] Dependency upgrade
- [ ] Bugfix (non-breaking change which fixes an issue)
- [x] New feature (thank you!)
- [ ] Breaking change (fix/feature causing existing functionality to break)
- [ ] Code quality improvements to existing code or addition of tests
## Example configuration
<!--
Supplying a configuration snippet, makes it easier for a maintainer to test
your PR.
-->
Testing this requires ZHA to be set up with a Zigbee radio. I've included screenshots below of the various interactions (dialogs moved around with dev tools to show more elements at once):
<details>
<summary><strong>Expand screenshots</strong></summary>
<img width="735" alt="image" src="https://user-images.githubusercontent.com/32534428/181386101-0b66f7f5-a51a-49e6-9baa-1997ff648dbb.png">
<img width="561" alt="image" src="https://user-images.githubusercontent.com/32534428/181386433-34e4d002-2d7c-47e7-a255-fe38989cfa09.png">
<img width="420" alt="image" src="https://user-images.githubusercontent.com/32534428/181386493-833dfbf8-22b8-43b4-aaa2-205f3b20e068.png">
</details>
## Additional information
<!--
Details are important, and help maintainers processing your PR.
Please be sure to fill out additional details, if applicable.
-->
- This PR fixes or closes issue: fixes #
- This PR is related to issue or discussion:
- Link to documentation pull request:
## Checklist
<!--
Put an `x` in the boxes that apply. You can also fill these out after
creating the PR. If you're unsure about any of them, don't hesitate to ask.
We're here to help! This is simply a reminder of what we are going to look
for before merging your code.
-->
- [x] The code change is tested and works locally.
- [x] There is no commented out code in this PR.
- [ ] Tests have been added to verify that the new code works.
If user exposed functionality or configuration variables are added/changed:
- [ ] Documentation added/updated for [www.home-assistant.io][docs-repository]
<!--
Thank you for contributing <3
-->
[docs-repository]: https://github.com/home-assistant/home-assistant.io
zigpy:dev
← puddly:puddly/radio-backup-api
opened 10:47PM - 22 Jul 22 UTC
https://github.com/zigpy/zigpy/pull/1006
zigpy:dev
← puddly:puddly/automatic-radio-backups
opened 05:23PM - 06 Jul 22 UTC
Backups are performed asynchronously on startup and then once every 24 hours (co… nfigurable).
4 Likes
naijaping
(Naijaping)
August 4, 2022, 12:03am
40
Good news at last, soon I will be able to move to my Sonoff dongle plus
Hedda
(Hedda)
August 6, 2022, 9:15am
42
Suggest asking in the dedicated thread for that Blueprint or its GitHub reposiroty instead as kind of off-topic from the original post here which really just a feature request for ZHA devs to add this and not a support thread for workarounds.
Hedda
(Hedda)
August 19, 2022, 7:25pm
43
FYI, Display ZHA network settings and allow downloading backups by puddly · Pull Request #13415 · home-assistant/frontend · GitHub supersedes ZHA network settings and backup/restore interface by puddly · Pull Request #13295 · home-assistant/frontend · GitHub as the initial frontend UI part, and ZHA backup/restore config flow by puddly · Pull Request #77044 · home-assistant/core · GitHub will adds network formation options to ZHA’s config flow, (that will give you several different options to let you “decide how to handle network information when setting up ZHA”):
home-assistant:dev
← puddly:puddly/zha-download-backup
opened 05:59PM - 19 Aug 22 UTC
<!--
You are amazing! Thanks for contributing to our project!
Please, DO N… OT DELETE ANY TEXT from this template! (unless instructed).
-->
## Proposed change
<!--
Describe the big picture of your changes here to communicate to the
maintainers why we should accept this pull request. If it fixes a bug
or resolves a feature request, be sure to link to that issue or discussion
in the additional information section.
-->
This supersedes #13295 and provides a way to download backups. The websocket API is currently in Core so this is fully functional, there is just no way to restore network backups yet (https://github.com/home-assistant/core/pull/77044). A future PR will add a second button to change the radio type and/or migrate radios.
<img width="457" alt="image" src="https://user-images.githubusercontent.com/32534428/185678920-a2267161-ce2c-4187-95dc-8fdca94e12c1.png">
## Type of change
<!--
What type of change does your PR introduce to the Home Assistant frontend?
NOTE: Please, check only 1! box!
If your PR requires multiple boxes to be checked, you'll most likely need to
split it into multiple PRs. This makes things easier and faster to code review.
-->
- [ ] Dependency upgrade
- [ ] Bugfix (non-breaking change which fixes an issue)
- [x] New feature (thank you!)
- [ ] Breaking change (fix/feature causing existing functionality to break)
- [ ] Code quality improvements to existing code or addition of tests
## Additional information
<!--
Details are important, and help maintainers processing your PR.
Please be sure to fill out additional details, if applicable.
-->
- This PR fixes or closes issue: fixes #
- This PR is related to issue or discussion:
- Link to documentation pull request:
## Checklist
<!--
Put an `x` in the boxes that apply. You can also fill these out after
creating the PR. If you're unsure about any of them, don't hesitate to ask.
We're here to help! This is simply a reminder of what we are going to look
for before merging your code.
-->
- [x] The code change is tested and works locally.
- [x] There is no commented out code in this PR.
- [ ] Tests have been added to verify that the new code works.
If user exposed functionality or configuration variables are added/changed:
- [ ] Documentation added/updated for [www.home-assistant.io][docs-repository]
<!--
Thank you for contributing <3
-->
[docs-repository]: https://github.com/home-assistant/home-assistant.io
home-assistant:dev
← puddly:puddly/zha-new-config-flow
opened 05:14PM - 19 Aug 22 UTC
<!--
You are amazing! Thanks for contributing to our project!
Please, DO N… OT DELETE ANY TEXT from this template! (unless instructed).
-->
## Proposed change
<!--
Describe the big picture of your changes here to communicate to the
maintainers why we should accept this pull request. If it fixes a bug
or resolves a feature request, be sure to link to that issue in the
additional information section.
-->
Adds network formation options to ZHA's config flow. This lets you decide how to handle network information when setting up ZHA:
- Erase network settings and form a new network.
- Restore an automatic backup.
- Upload and restore a manual backup (frontend PR allows backup downloads).
- Continue with the existing settings on your stick.
## Type of change
<!--
What type of change does your PR introduce to Home Assistant?
NOTE: Please, check only 1! box!
If your PR requires multiple boxes to be checked, you'll most likely need to
split it into multiple PRs. This makes things easier and faster to code review.
-->
- [ ] Dependency upgrade
- [ ] Bugfix (non-breaking change which fixes an issue)
- [ ] New integration (thank you!)
- [x] New feature (which adds functionality to an existing integration)
- [ ] Deprecation (breaking change to happen in the future)
- [ ] Breaking change (fix/feature causing existing functionality to break)
- [ ] Code quality improvements to existing code or addition of tests
## Additional information
<!--
Details are important, and help maintainers processing your PR.
Please be sure to fill out additional details, if applicable.
-->
- This PR fixes or closes issue: fixes #
- This PR is related to issue:
- Link to documentation pull request:
## Checklist
<!--
Put an `x` in the boxes that apply. You can also fill these out after
creating the PR. If you're unsure about any of them, don't hesitate to ask.
We're here to help! This is simply a reminder of what we are going to look
for before merging your code.
-->
- [ ] The code change is tested and works locally.
- [ ] Local tests pass. **Your PR cannot be merged unless tests pass**
- [ ] There is no commented out code in this PR.
- [ ] I have followed the [development checklist][dev-checklist]
- [ ] The code has been formatted using Black (`black --fast homeassistant tests`)
- [ ] Tests have been added to verify that the new code works.
If user exposed functionality or configuration variables are added/changed:
- [ ] Documentation added/updated for [www.home-assistant.io][docs-repository]
If the code communicates with devices, web services, or third-party tools:
- [ ] The [manifest file][manifest-docs] has all fields filled out correctly.
Updated and included derived files by running: `python3 -m script.hassfest`.
- [ ] New or updated dependencies have been added to `requirements_all.txt`.
Updated by running `python3 -m script.gen_requirements_all`.
- [ ] For the updated dependencies - a link to the changelog, or at minimum a diff between library versions is added to the PR description.
- [ ] Untested files have been added to `.coveragerc`.
The integration reached or maintains the following [Integration Quality Scale][quality-scale]:
<!--
The Integration Quality Scale scores an integration on the code quality
and user experience. Each level of the quality scale consists of a list
of requirements. We highly recommend getting your integration scored!
-->
- [ ] No score or internal
- [ ] 🥈 Silver
- [ ] 🥇 Gold
- [ ] 🏆 Platinum
<!--
This project is very active and we have a high turnover of pull requests.
Unfortunately, the number of incoming pull requests is higher than what our
reviewers can review and merge so there is a long backlog of pull requests
waiting for review. You can help here!
By reviewing another pull request, you will help raise the code quality of
that pull request and the final review will be faster. This way the general
pace of pull request reviews will go up and your wait time will go down.
When picking a pull request to review, try to choose one that hasn't yet
been reviewed.
Thanks for helping out!
-->
To help with the load of incoming pull requests:
- [ ] I have reviewed two other [open pull requests][prs] in this repository.
[prs]: https://github.com/home-assistant/core/pulls?q=is%3Aopen+is%3Apr+-author%3A%40me+-draft%3Atrue+-label%3Awaiting-for-upstream+sort%3Acreated-desc+review%3Anone+-status%3Afailure
<!--
Thank you for contributing <3
Below, some useful links you could explore:
-->
[dev-checklist]: https://developers.home-assistant.io/docs/en/development_checklist.html
[manifest-docs]: https://developers.home-assistant.io/docs/en/creating_integration_manifest.html
[quality-scale]: https://developers.home-assistant.io/docs/en/next/integration_quality_scale_index.html
[docs-repository]: https://github.com/home-assistant/home-assistant.io
Hedda
(Hedda)
September 8, 2022, 8:02pm
44
2 Likes
alsFC
(Alex)
November 17, 2022, 7:59am
46
Unfortunately that doesn’t keep your custom device and entity id naming and area relations:
Hello guys,
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.
Hedda
(Hedda)
November 17, 2022, 11:42am
47
Not if restoring/migrating from third-party Zigbee solutions like Zigbee2MQTT (or IoBroker) to the ZHA integration , however it should keep it if the backup is made from the ZHA integration and migration is only from one supported Zigbee Coordinator adapter to a different supported Zigbee Coordinator adapter.
As in the current valid use-case is for a scenario when you are restoring/migrating from a backup made inside the ZHA integration from using for example an older CC2530/CC231 based Zigbee Coordinator adapter to a newer Zigbee Coordinator adapter like for example Home Assistant SkyConnect USB Stick or ITead’s “Sonoff Zigbee 3.0 USB Dongle Plus” (model “ZBDongle-P”) . See → https://www.home-assistant.io/integrations/zha#zigbee-backup-and-restore-in-zha
If that do not work then report ZHA integration issue to https://github.com/home-assistant/core/issues
alsFC
(Alex)
November 17, 2022, 11:51am
48
I backed up ZHA with ConBee II and restored to ZHA on internal chip in the Yellow. It didn’t keep custom naming as others report in this thread:
Hi,
After receiving a doom-laden email yesterday suggesting customs charges and UK VAT (Brexit - the gift they keeps giving ), my Home Assistant Yellow kit arrived unexpectedly TODAY!
Despite lots of great features recently added to HASS making the migration from a RPi4 to Yellow fine, the process was far from seamless, so thought a few learning points might help others.
TL;DR
Crowd Supply are delivering HASS Yellow hardware right now. (Nice case and PCB design :+…
1 Like
Hedda
(Hedda)
November 17, 2022, 12:00pm
49
Ah, that must be a bug that you need to report to → https://github.com/home-assistant/core/issues
alsFC
(Alex)
November 17, 2022, 12:32pm
50
Ok! Thanks! I will do that!