-
-
Notifications
You must be signed in to change notification settings - Fork 32.2k
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
New configuration flow for ZHA integration #35161
Conversation
Hey there @dmulcahey, @Adminiuga, mind taking a look at this pull request as its been labeled with a integration ( |
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? |
@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 |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
LGTM!
d8d1164
to
54bc471
Compare
@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 |
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.
Co-authored-by: Martin Hjelmare <[email protected]>
Co-authored-by: Martin Hjelmare <[email protected]>
Co-authored-by: Martin Hjelmare <[email protected]>
Use AsyncMock from tests.
5d40191
to
1b425b5
Compare
_LOGGER.debug("Migrating from version %s", config_entry.version) | ||
|
||
if config_entry.version == 1: | ||
config_entry.data = { |
There was a problem hiding this comment.
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.
There was a problem hiding this comment.
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.
There was a problem hiding this comment.
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?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Great!
We usually add breaking change label when we deprecate things, and then another break when the deprecation expires. |
Updated PR description to reflect breaking change. |
Breaking change
Yes.
The following:
usb_path
baudrate
radio_type
configuration options for ZHA integration in
configuration.yaml
are deprecated and will be removed in0.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:
For USB connected devices, there is going to be some extra information to narrow the choice
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:
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
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.
Since this PR deprecates manual radio configuration via
.yaml
, the following options are deprecated in0.112
usb_path
baudrate
radio_type
Type of change
Example entry for
configuration.yaml
:n/a
Additional information
Checklist
black --fast homeassistant tests
)If user exposed functionality or configuration variables are added/changed:
If the code communicates with devices, web services, or third-party tools:
Updated and included derived files by running:
python3 -m script.hassfest
.requirements_all.txt
.Updated by running
python3 -m script.gen_requirements_all
..coveragerc
.The integration reached or maintains the following Integration Quality Scale: