Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

New configuration flow for ZHA integration #35161

Conversation

Adminiuga
Copy link
Contributor

@Adminiuga Adminiuga commented May 4, 2020

Breaking change

Yes.
The following:

  • usb_path
  • baudrate
  • radio_type

configuration options for ZHA integration in configuration.yaml are deprecated and will be removed in 0.112.0

Proposed change

Deprecate manual ZHA configuration (Radio type and serial port settings) via yaml, while also trying to make integration configuration a bit more user friendly. In the new flow system presents a drop down of all available serial ports and user has to pick the right one:
image

For USB connected devices, there is going to be some extra information to narrow the choice
image

Once selected, the flow would try to detect the radio type automatically, which should take about 15s as it tries all radio types in sequence: EZSP, Deconz, TI_CC (ZNP), Zigate, Xbee

If successful, it's all done:
image

If none of the probe succeeds (e.g. Elelabs radios decided to change the default baudrate to 115200 for ezsp) then the "manual configuration" kicks in and user has to pick the radio type
image

And based on the radio type, user will be presented with settings specific for that radio type, as some radios don't care about "baudrate", or some radios may use a different "data flow control", Schema for this forms comes from the Radio and allows advanced radio configuration without any HA code modification. However ATM 99% should be covered by automatic radio detection, assuming user picks the right port.
image

Since this PR deprecates manual radio configuration via .yaml, the following options are deprecated in 0.112

  • usb_path
  • baudrate
  • radio_type

Type of change

  • Dependency upgrade
  • Bugfix (non-breaking change which fixes an issue)
  • New integration (thank you!)
  • New feature (which adds functionality to an existing integration)
  • Breaking change (fix/feature causing existing functionality to break)
  • Code quality improvements to existing code or addition of tests

Example entry for configuration.yaml:

n/a

Additional information

  • This PR fixes or closes issue: fixes #
  • This PR is related to issue:
  • Link to documentation pull request:

Checklist

  • 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
  • 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:

If the code communicates with devices, web services, or third-party tools:

  • The manifest file 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.
  • Untested files have been added to .coveragerc.

The integration reached or maintains the following Integration Quality Scale:

  • No score or internal
  • 🥈 Silver
  • 🥇 Gold
  • 🏆 Platinum

@probot-home-assistant
Copy link

Hey there @dmulcahey, @Adminiuga, mind taking a look at this pull request as its been labeled with a integration (zha) you are listed as a codeowner for? Thanks!
(message by CodeOwnersMention)

@Hedda
Copy link
Contributor

Hedda commented May 4, 2020

I don't have one but wondering how it works with IP-based / remote networked connected adapters?

Only know of the ZiGate Pack WiFi adapter now (but assume might be similar adapters in the future).

@doudz do you maybe have a ZiGate Pack WiFi so you can test this with your zigpy-zigate library or?

As I understand the ZiGate Pack WiFi adapter basically just has a serial port server forwarding service?

That is, it has a serial server software that just acts as a dumb Zigbee to WiFi bridge for zigpy-zigate or?

@Hedda
Copy link
Contributor

Hedda commented May 4, 2020

@doudz @Adminiuga It would be very nice from an end-users perspective if the serial server software in the firmware of "dumb" networked Zigbee bridge hardware like the ZiGate Pack WiFi adapter had some kind of features/functions for Zero-configuration networking (zeroconf) like mDNS for automatic-discovery that would allow projects like Home Assistant's ZHA to automatically discover the ZiGate Pack WiFi on the network to make drop-down-list installation and configurations on the client-side such as these as simple as possible for a more user-friendly experience.

Off-topic, think it's just a matter of time before there's a hacked firmware like that for Sonoff ZBBridge

@doudz
Copy link
Contributor

doudz commented May 4, 2020

@doudz @Adminiuga It would be very nice from an end-users perspective if the serial server software in the firmware of "dumb" networked Zigbee bridge hardware like the ZiGate Pack WiFi adapter had some kind of features/functions for Zero-configuration networking (zeroconf) like mDNS for automatic-discovery that would allow projects like Home Assistant's ZHA to automatically discover the ZiGate Pack WiFi on the network to make drop-down-list installation and configurations on the client-side such as these as simple as possible for a more user-friendly experience.

Off-topic, think it's just a matter of time before there's a hacked firmware like that for Sonoff ZBBridge

Firmware 2.0 of ZiGate WiFi adapter has mDNS
https://zigate.fr/documentation/description-du-firmware-v2-xx/

Copy link
Contributor

@dmulcahey dmulcahey left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

LGTM!

@Adminiuga Adminiuga force-pushed the experimental/reb-zha-new-config-entry branch from d8d1164 to 54bc471 Compare May 4, 2020 19:21
homeassistant/components/zha/config_flow.py Outdated Show resolved Hide resolved
homeassistant/components/zha/config_flow.py Outdated Show resolved Hide resolved
homeassistant/components/zha/config_flow.py Outdated Show resolved Hide resolved
tests/components/zha/test_config_flow.py Outdated Show resolved Hide resolved
tests/components/zha/test_config_flow.py Outdated Show resolved Hide resolved
tests/components/zha/test_config_flow.py Outdated Show resolved Hide resolved
tests/components/zha/test_config_flow.py Outdated Show resolved Hide resolved
tests/components/zha/test_config_flow.py Outdated Show resolved Hide resolved
@Adminiuga Adminiuga requested a review from MartinHjelmare May 5, 2020 04:49
tests/components/zha/test_config_flow.py Show resolved Hide resolved
tests/components/zha/test_config_flow.py Outdated Show resolved Hide resolved
tests/components/zha/test_config_flow.py Outdated Show resolved Hide resolved
tests/components/zha/test_init.py Outdated Show resolved Hide resolved
@Hedda
Copy link
Contributor

Hedda commented May 5, 2020

Firmware 2.0 of ZiGate WiFi adapter has mDNS
https://zigate.fr/documentation/description-du-firmware-v2-xx/

@doudz That sounds great! Any chance you have time + interest to look into automatic-discovery of that adapter for mDNS adapter detection and configuration flow for ZHA integration similar to this?

UPDATE: Submitted this as a separate discussion for zigpy here instead -> https://github.com/zigpy/zigpy/issues/405

@Adminiuga Adminiuga requested a review from MartinHjelmare May 5, 2020 16:44
Adminiuga added 6 commits May 5, 2020 14:48
Update config entry data  import.
Use new zigpy startup.
Fix config entry import without zha config section.
Auto form Zigbee network.
Use lightweight probe() method for ZHA config entry validation when
available. Failback to old behavior of setting up Zigpy app if radio lib
does not provide probing.
@Adminiuga Adminiuga requested a review from MartinHjelmare May 6, 2020 01:18
_LOGGER.debug("Migrating from version %s", config_entry.version)

if config_entry.version == 1:
config_entry.data = {
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

The data attribute should be considered read only. We set it to a mapping proxy when the config entry is defined. We should use hass.config_entries.async_update_entry to update the data.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

ok, i'll update it.
BTW this was copied that from axis integration, so that may need update too.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

ok, it's using async_update_entry() now. For config entry migration, i still have to set the config_entry.version attribute to the new version, right?

homeassistant/components/zha/__init__.py Outdated Show resolved Hide resolved
@Adminiuga Adminiuga requested a review from MartinHjelmare May 6, 2020 03:09
Copy link
Member

@MartinHjelmare MartinHjelmare left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Great!

@MartinHjelmare MartinHjelmare merged commit c71a7b9 into home-assistant:dev May 6, 2020
@MartinHjelmare
Copy link
Member

We usually add breaking change label when we deprecate things, and then another break when the deprecation expires.

@Adminiuga
Copy link
Contributor Author

Updated PR description to reflect breaking change.

Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Projects
None yet
Development

Successfully merging this pull request may close these issues.

7 participants