-
-
Notifications
You must be signed in to change notification settings - Fork 28.5k
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
Convert Anova to cloud push #109508
Convert Anova to cloud push #109508
Conversation
@@ -49,11 +52,15 @@ class AnovaSensorEntityDescription( | |||
AnovaSensorEntityDescription( | |||
key="state", | |||
translation_key="state", | |||
device_class=SensorDeviceClass.ENUM, | |||
options=[state.name for state in AnovaState], |
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.
What should we do in the case of "no_state"?
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.
That should be fine I think. "no_state" should get turned into "No state" through translations. It's why I use name instead of value.
I create the stateby doing AnovaState(response_from_api) - when state is "" - it sets state = AnovaState.no_state
Then the value is saved to AnovaUpdateSensor as the state.name
if f"{DOMAIN}.{SENSOR_DOMAIN}_{sensor.unique_id}" in ent_registry.entities: | ||
# If the entity has been added before - we know it is supported. | ||
valid_entities.add(sensor) |
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.
Why do we do this?
Why don't remove the non working ones and just setup like normal?
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.
So it's less about them not working. This is just a means of adding the existing entities even when the device is offline. Since the entities will exist, when the websocket ends up sending update data - the sensors should automatically update.
Basically - if we have added an entity before - it is supported and we should add it again, even if the device is offline.
Please take a look at the requested changes, and use the Ready for review button when you are done, thanks 👍 |
Co-authored-by: Joost Lekkerkerker <joostlek@outlook.com>
merging to attempt to fix failed test |
Co-authored-by: Erik Montnemery <erik@montnemery.com>
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.
Just fix the check for api.websocket_handler
, then this PR is good to go 👍
Done! Also gave it a small version bump to do a bit more error catching in ws creation. Thank you for the review! |
Breaking change
The
State
andMode
entities for Anova devices have been changed to match the new protocol messaging. Any automations based on these entities will need to be updated.Proposed change
This changes Anova to use websockets instead of the old REST api. It should allow support for a bunch of different devices including the Anova Oven.
Package update has to be included with this PR and not done separately as this is a major internal refactor.
Lash-L/anova_wifi@v0.10.0...v0.12.0
Type of change
Additional information
Checklist
ruff format 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: