Skip to content
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

Add Broadlink time platform #121470

Merged
merged 3 commits into from
Jul 11, 2024
Merged

Conversation

eifinger
Copy link
Contributor

@eifinger eifinger commented Jul 7, 2024

Proposed change

Add the time platform for supported Broadlink devices.

Split from #115408

Type of change

  • Dependency upgrade
  • Bugfix (non-breaking change which fixes an issue)
  • New integration (thank you!)
  • New feature (which adds functionality to an existing integration)
  • Deprecation (breaking change to happen in the future)
  • Breaking change (fix/feature causing existing functionality to break)
  • Code quality improvements to existing code or addition of tests

Additional information

Checklist

  • The code change is tested and works locally.
  • Local tests pass. Your PR cannot be merged unless tests pass
  • There is no commented out code in this PR.
  • I have followed the development checklist
  • I have followed the perfect PR recommendations
  • The code has been formatted using Ruff (ruff format homeassistant tests)
  • Tests have been added to verify that the new code works.

If user exposed functionality or configuration variables are added/changed:

If the code communicates with devices, web services, or third-party tools:

  • The manifest file has all fields filled out correctly.
    Updated and included derived files by running: python3 -m script.hassfest.
  • New or updated dependencies have been added to requirements_all.txt.
    Updated by running python3 -m script.gen_requirements_all.
  • For the updated dependencies - a link to the changelog, or at minimum a diff between library versions is added to the PR description.

To help with the load of incoming pull requests:

@home-assistant
Copy link

home-assistant bot commented Jul 7, 2024

Hey there @Danielhiversen, @felipediel, @L-I-Am, mind taking a look at this pull request as it has been labeled with an integration (broadlink) you are listed as a code owner for? Thanks!

Code owner commands

Code owners of broadlink can trigger bot actions by commenting:

  • @home-assistant close Closes the pull request.
  • @home-assistant rename Awesome new title Renames the pull request.
  • @home-assistant reopen Reopen the pull request.
  • @home-assistant unassign broadlink Removes the current integration label and assignees on the pull request, add the integration domain after the command.
  • @home-assistant add-label needs-more-information Add a label (needs-more-information, problem in dependency, problem in custom component) to the pull request.
  • @home-assistant remove-label needs-more-information Remove a label (needs-more-information, problem in dependency, problem in custom component) on the pull request.

@@ -6,6 +6,7 @@

DOMAINS_AND_TYPES = {
Platform.CLIMATE: {"HYS"},
Platform.TIME: {"HYS"},
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Let's keep this alphabetical

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

What do we have Ruff for? 😅

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Done

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

For a lot of the checks. We also have a pylint rule that checks if PLATFORMS variables are alphabetical. But this is a dict, not a list, and it's called DOMAINS_AND_TYPED hence there is no check for this. But I personally do really like when these lists are neatly ordered to be consistent with the rest

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I added it as the datetime platform and later just renamed it. Shame on me^^

Comment on lines 56 to 60
if self._coordinator.data is None or "dayofweek" not in self._coordinator.data:
raise ServiceValidationError(
translation_domain=DOMAIN,
translation_key="request_failed_device_not_connected",
)
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Shouldn't the entity be unavailable in that moment? Or are there other moments when this can happen

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I had the direct service call in mind. And at least during testing the device when Homeassistant first connected to the device (after bootup) it was available but no time was displayed, meaning the coordinator had to data yet.

Something I want to investigate and possible fix in a separate PR

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

But why is that the case? you're now raising an issue that the device is not connected, but from your response I also guess that it already was connected, so what should the user do to get the data?

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Removed

"""Initialize the sensor."""
super().__init__(device)

self._attr_unique_id = f"{device.unique_id}-device-time"
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Suggested change
self._attr_unique_id = f"{device.unique_id}-device-time"
self._attr_unique_id = f"{device.unique_id}-device_time"

if you ever need to migrate you can just do .split("-")

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Done

@home-assistant
Copy link

home-assistant bot commented Jul 7, 2024

Please take a look at the requested changes, and use the Ready for review button when you are done, thanks 👍

Learn more about our pull request process.

@home-assistant home-assistant bot marked this pull request as draft July 7, 2024 20:43
@eifinger eifinger marked this pull request as ready for review July 7, 2024 20:49
@home-assistant home-assistant bot requested a review from joostlek July 7, 2024 20:49
Copy link
Contributor

@felipediel felipediel left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Looks very good! Here are a few suggestions...

async_add_entities([BroadlinkTime(device)])


class BroadlinkTime(BroadlinkEntity, TimeEntity):
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Let's name this entity BroadlinkHysenTime, as it is specific to the Hysen class, and we may want to add other types in the future.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Do you think other device types would have a fundamentally different time platform? The data used is retrieved via the broadlink api get_full_status

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Yes, although we currently only have this device with day of the week and time in the API today, this structure could vary depending on the type of device in the future. Some devices might include day, month, and year, while others might include timezone information.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Do we know of a device which is available today or will be available in the future? Or is this an assumption?

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

It's always an assumption when it comes to Broadlink. When we don't know what is going to happen, we better keep it flexible. But I am totally okay if you want to leave it as is and change it later if we need to.

Comment on lines +25 to +26
device = hass.data[DOMAIN].devices[config_entry.entry_id]
async_add_entities([BroadlinkTime(device)])
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Let's add some flow control to ensure that if the entity is of type 'HYS', then we add BroadlinkHysenTime entities. Otherwise, we do nothing.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

While I get the idea I think this would be different then how filtering is done for other platforms. E.g.

BroadlinkSensor(device, description)
for description in SENSOR_TYPES
if description.key in sensor_data
and (
# These devices have optional sensors.
# We don't create entities if the value is 0.
sensor_data[description.key] != 0
or device.api.type not in {"RM4PRO", "RM4MINI"}
)
]

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Even if we do a good job creating a unified interface in the library, we could still have at least two types of time devices: weekday/time and date/time.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Moreover we do already filter the platforms by device type: https://github.com/home-assistant/core/pull/121470/files#diff-de5887f91e2b6b4559fe8fe3c68b104fbbcc5048feb84a0db325be16527d87f0R39

Why should we do it again?

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

It's about making the code more robust. This function accepts a ConfigEntry in its signature. It should be able to handle any ConfigEntry, without depending on filtering or validation by a higher level module.

@MartinHjelmare MartinHjelmare changed the title Broadlink - Add time platform Add Broadlink time platform Jul 8, 2024
@joostlek
Copy link
Member

@felipediel Please let us know if you think think your concerns are addressed so we can start getting this feature in :)

@felipediel
Copy link
Contributor

They have not been addressed, but that's okay. Those were just suggestions. The code looks good to me; let's ship this thing.

@joostlek
Copy link
Member

🚀 Okay let's go!

@joostlek joostlek merged commit ea5eb0f into home-assistant:dev Jul 11, 2024
26 checks passed
@github-actions github-actions bot locked and limited conversation to collaborators Jul 12, 2024
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Projects
None yet
Development

Successfully merging this pull request may close these issues.

None yet

4 participants