Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
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
Refactor switch for vesync #134409
Refactor switch for vesync #134409
Changes from 28 commits
0d67c7b
033cac8
3a663de
6604d26
f4352fd
f143594
1337372
7b0510d
8db10fb
0ce2086
0fc9e81
4a2fa3f
0288768
c12b55d
9043ba7
ff5f13c
8f13594
5b08b11
e32f14f
139d4e1
10e9925
8b38c47
85fdfdd
70e2cdf
c6d2088
27c255e
1013880
51d1ead
d963ec7
b39778e
bde6507
765b86b
918ff0e
File filter
Filter by extension
Conversations
Jump to
There are no files selected for viewing
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.
Okay, but how come only these 2 are switches? As in,
is_wall_switch
doesnt sound to incorporate dimmingThere 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.
I thought I had handled this different maybe lost in a merge - so here is the challenge. The old lookup table takes two model of switches and calls them a dimmer switch. Goal is to not need that lookup table for models in the future.
https://github.com/cdnninja/core/blob/09ae388f4e947f508cedda70b806a839326ea4af/homeassistant/components/vesync/const.py#L51-L52
These devices in the old method didn't create a switch entity just a light entity. Currently with my code it would also get a switch. Should we leave it like that so if dimmable switch or outlet you still get a switch toggle? This is the easier way, other option is adjust the exists to exclude the type of VeSyncDimmerSwitch which is a type of switch within the library.
@iprak Thoughts?
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.
I don't think we need to provided a separate switch for dimmer. LightEntity extends from ToggleEntity and so it provided on/off capability natively.
This is what I see for a dimmer switch
![image](https://private-user-images.githubusercontent.com/6459774/404690541-9311d1f5-aa26-4c46-a578-a63e78adbc8e.png?jwt=eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9.eyJpc3MiOiJnaXRodWIuY29tIiwiYXVkIjoicmF3LmdpdGh1YnVzZXJjb250ZW50LmNvbSIsImtleSI6ImtleTUiLCJleHAiOjE3MzkxMzA4NjcsIm5iZiI6MTczOTEzMDU2NywicGF0aCI6Ii82NDU5Nzc0LzQwNDY5MDU0MS05MzExZDFmNS1hYTI2LTRjNDYtYTU3OC1hNjNlNzhhZGJjOGUucG5nP1gtQW16LUFsZ29yaXRobT1BV1M0LUhNQUMtU0hBMjU2JlgtQW16LUNyZWRlbnRpYWw9QUtJQVZDT0RZTFNBNTNQUUs0WkElMkYyMDI1MDIwOSUyRnVzLWVhc3QtMSUyRnMzJTJGYXdzNF9yZXF1ZXN0JlgtQW16LURhdGU9MjAyNTAyMDlUMTk0OTI3WiZYLUFtei1FeHBpcmVzPTMwMCZYLUFtei1TaWduYXR1cmU9NTk5YzJiMWE0MGVjNTUwYTNlYWNmMTQxODZmMGJhZTJjZDI1YmQ3NDYwY2Q4YTVjZTNhNTExZDFkZmViZTRlZCZYLUFtei1TaWduZWRIZWFkZXJzPWhvc3QifQ.O2pL9zi7hysMCIFPUq--evqtEJVk5wV99Q9fXxLmisI)
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.
Went back to fix this and realized I was correct up front. In pyvesync vesyncswitch has two child classes, VeSyncWallSwitch and VeSyncDimmerSwitch. The above filters to just wall switch so dimmer isn't used. As such this won't show for dimmers. No changes required. I updated the helper comment some to try make this more clear.
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.
We need to define
_attr_unique_id
otherwise adding another switch entity fails.Something like this will work -
self._attr_unique_id = f"{super().unique_id}-{description.key}"
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.
For the two devices exposed today if we change this it will be a breaking change. However I could add a filter to only do the above unique ID on ones other than the outlet and switch on we offer today. It would set us up for future.
Thoughts on that approach?
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.
I suppose that will work. @joostlek might have reviewed code which ran into similar shortcoming and if the _attr_unique_id was defined as a breaking change.
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.
Oh that is a good catch. If that is the case we should migrate first. I don't feel like merging this as it will create entities with not unique unique ids. So we should have a preliminary PR where we migrate all the unique ids of the switches to something else and then we can set up new ones
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.
Okay, today this code doesn't conflict or impact unique ID, however since trying to setup for growth makes sense we fix this now. I will update this code to have the unique ID as mentioned above and chat with iprak around getting a PR for that migration that will merge first.
Check warning on line 114 in homeassistant/components/vesync/switch.py
homeassistant/components/vesync/switch.py#L113-L114
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 that with the 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.
Without it HA toggles it back the other way until next scan interval which gives it a poor user experience as it appears to have not worked.
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.
Shouldn't schedule_update_ha_state be only called if turn_off succeeds?
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.
Some other spots have it this way - my theory was after touching devices we should check the source data regardless to ensure we are updated. Both approaches though in most cases would show correctly I would think. Which do you prefer?
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 turn_on/off return true if operation succeeds and I think that should be respected and used as the basis of state refresh. Yes I do see some integration call this all the time and I would like @joostlek 's input on this.
I think without this, the entity would show the new data when it is refreshed but I am not sure if the underlying framework does the same. Some other integrations invoke a refresh and I think that takes care of cases where multiple entities get updated in response to one action.
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.
Switch returns true if the web call succeeded, we should use that return value to schedule_update_ha_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.
Adjusted.
Check warning on line 119 in homeassistant/components/vesync/switch.py
homeassistant/components/vesync/switch.py#L118-L119