Add config flow for Rain Bird#85271
Conversation
Convert rainbird to a config flow. Still need to handle irrigation numbers.
|
Hey there @konikvranik, mind taking a look at this pull request as it has been labeled with an integration ( Code owner commandsCode owners of
|
| hass, "Rain delay", controller.get_rain_delay | ||
| ) | ||
|
|
||
| hass.data[DOMAIN][entry.entry_id] = { |
There was a problem hiding this comment.
I recommend using a dataclass to store multiple items in hass.data.
There was a problem hiding this comment.
Based on this comment and the comment about initializing the update coordinators in the platforms, I decided to just simplify the overall interactions between the device and the integration, moving all the rpcs into a single data update coordinator. This required changing the tests, so i added additional test fixtures to help manage the request setup and ordering expected by the integration.
The consequence of this is now a single update coordinator handles rpcs for all platforms so there isn't independence for each sensor, but in hindsight that is probably simpler overall (e.g. if the device is offline, there is just one coordinator trying to hit it rather than 3).
While I was here, I also removed some unnecessary duplicate sensors. Today there is a rain sensor and a rain delay sensor both exported as a sensor and binary sensor and it doesn't really make a lot of sense to me. I've just left the sensors that provide unique value and have updated the breaking changes in the description.
There was a problem hiding this comment.
If this is too much for a single PR, I can break into smaller chunks, or move into another branch to not have to worry about leaving dev in a bad state.
There was a problem hiding this comment.
It's not too much.
What did the four binary sensors and sensors represent? How would a user replace the removed sensors?
There was a problem hiding this comment.
There were four total sensors representing two values that were redundant. I updated the PR to describe but can reword if it is not clear.
The "rain" sensor was a binary sensor and a sensor with a string boolean value. This represents whether the device knows it is raining (I'm not sure if it's from a separate sensors only or also from a cloud weather report)
The "rain delay" represents the number of days that the sprinkler is paused due to rain. This is a sensor and also had a binary sensor when it was non-zero. The rain delay service can update this value so maybe this should just be a Number?
There was a problem hiding this comment.
Ok.
Yeah, if the rain delay service and sensor are in sync it should be a number entity.
There was a problem hiding this comment.
We can deprecate the service and raise a repair issue telling users to move to the number entity and service when that's in place.
Co-authored-by: Martin Hjelmare <marhje52@gmail.com>
…ssistant-core into rainbird-config-entry
Co-authored-by: Martin Hjelmare <marhje52@gmail.com>
Co-authored-by: Martin Hjelmare <marhje52@gmail.com>
MartinHjelmare
left a comment
There was a problem hiding this comment.
Great!
Further work is good to do in follow ups. 👍
Breaking change
Rainbird is now configured via the UI and configuration from YAML has been imported. However, there are a few notable changes:
binary_sensorthat duplicates the Rain delay timesensorhas been removed. You should move all uses to thesensorvalue and check for a non-zero value to get equivalent behavior.sensorthat duplicates the Rainbinary_sensorhas been removed. You may check thebinary_sensorstate to get equivalent behavior.set_rain_delaynow requires a configuration entry parameter. Previously the service had undefined behavior when multiple devices were configured.Note for release notes maintainer: The last bullet can be superseded by the breaking change note in #86208
Proposed change
Add a config flow for Rain Bird. Existing YAML configuration is imported, with the exception of per-zone overrides for irrigation time which are not supported. Irrigation times can be specified with a service call.
Type of change
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.To help with the load of incoming pull requests: