-
-
Notifications
You must be signed in to change notification settings - Fork 32.8k
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
Use EntityDescription - renault #55061
Use EntityDescription - renault #55061
Conversation
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 left some last formatting comments.
Aside from that, the overall structure LGTM. The details are a bit more difficult to review, especially since this is such a large PR. I trust that you tested it there.
Thanks @cdce8p I've fixed the formatting issue on my machine. |
@cdce8p would you mind taking a final look now that the value_lambda is in? |
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.
@epenet The last changes LGTM, too!
609d20f
to
fcc192b
Compare
Rebased the PR to deal with the CI issues |
If it reassures the team, I can split the "test" amends into a preliminary PR to show that functionnality hasn't been impacted at all by the release, and move the "state-class" amends into a subsequent PR afterwards... |
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, thanks! Unfortunately we missed the window for 2021.09
. Since this is a larger refactoring, I would like to wait until after the release (in a week) before merging it.
Marked the PR as draft to indicate that.
Wasn't aware of that. We had a small discussion on discord how to handle PRs with large refactorings shortly before the release. Turns out I was overly worried 🤷🏻♂️ Will merge it now. That should make things easier on your end. |
if self.coordinator.data | ||
else None | ||
) | ||
return {ATTR_LAST_UPDATE: last_update} |
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 don't include the item at all in the state attributes if the value is None.
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.
Hi @MartinHjelmare you told me the opposite on the original integration: an attribute should never "disappear".
So the way it is implemented is that sensor with battery
coordinator will always have the attribute (sometimes with value, and sometimes None) and other coordinators do not return any attributes return None
.
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.
Do you have a link to that discussion?
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 can't find it. I guess I was mistaken. I'll implement...
data_key="chargingStatus", | ||
device_class=DEVICE_CLASS_CHARGE_STATE, | ||
entity_class=RenaultSensor[KamereonVehicleBatteryStatusData], | ||
icon_lambda=lambda x: ( |
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 long expressions it's nicer to define a regular function and assign it here. It doesn't have to be a lambda.
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'll start work on that
state = hass.states.get(entity_id) | ||
assert state.state == STATE_OFF | ||
for attr in CHECK_ATTRIBUTES: | ||
if attr == ATTR_LAST_UPDATE: |
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 want to avoid if/else logic in tests.
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.
Was this OK in sensor.py
?
https://github.com/home-assistant/core/blob/dev/tests/components/renault/test_sensor.py#L34-L48
const.py
and the fixtures have all the values for when things are OK.
I wanted to avoid having to put in const.py
the "error" values.
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 like that assertion helper. Generally I try to avoid assertion helpers since I think they make it harder to read the test and see what the test is testing. My preference is to have all the setup code including mocking and patching in pytest fixtures but have the function call that is tested and assertions in the test body itself.
But regardless we should keep tests as simple as possible without branching logic as far as possible.
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'll work out a better split between fixed and dynamic attributes
Proposed change
Update renault to use EntityDescription for entity metadata, and add state class for sensors.
-> #53201
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
.The integration reached or maintains the following Integration Quality Scale:
To help with the load of incoming pull requests: