home-assistant / core

:house_with_garden: Open source home automation that puts local control and privacy first.
https://www.home-assistant.io
Apache License 2.0
71.66k stars 29.95k forks source link

Deprecate `beat` display option in Time & Date #109963

Closed andrewjswan closed 7 months ago

andrewjswan commented 7 months ago

The problem

Deprecate beat display option in Time & Date - what’s wrong with this sensor? If it’s not needed, people don’t add it, and if people use it, they add it. Do a couple of lines of code really interfere with the HA architecture that much?

Of course, it can be replaced with a template sensor, but all the sensors of this integration can also be replaced with a template sensor, then why do we leave the others and remove this one?

If a person does not need this sensor, he does not add it to his configuration and does not use it. But if you need it, then it is more convenient to add it through the GUI than to create a template sensor that will not provide the required accuracy.

What version of Home Assistant Core has the issue?

core-2024.2.0

What was the last working version of Home Assistant Core?

core-2024.1.6

What type of installation are you running?

Home Assistant OS

Integration causing the issue

Time & Date

Link to integration documentation on our website

https://www.home-assistant.io/integrations/time_date/

Diagnostics information

Deprecate beat display option in Time & Date

Example YAML snippet

sensor:
  - platform: time_date
    display_options:
      - 'time'
      - 'date'
      - 'date_time'
      - 'date_time_utc'
      - 'date_time_iso'
      - 'time_date'
      - 'time_utc'
      - 'beat'

Anything in the logs that might be useful for us?

No response

Additional information

No response

home-assistant[bot] commented 7 months ago

Hey there @fabaff, mind taking a look at this issue as it has been labeled with an integration (time_date) you are listed as a code owner for? Thanks!

Code owner commands Code owners of `time_date` can trigger bot actions by commenting: - `@home-assistant close` Closes the issue. - `@home-assistant rename Awesome new title` Renames the issue. - `@home-assistant reopen` Reopen the issue. - `@home-assistant unassign time_date` Removes the current integration label and assignees on the issue, 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 issue. - `@home-assistant remove-label needs-more-information` Remove a label (needs-more-information, problem in dependency, problem in custom component) on the issue.

(message by CodeOwnersMention)


time_date documentation time_date source (message by IssueLinks)

frenck commented 7 months ago

Thanks, what is the use-case for keeping this at this point?

This integration has been moved to the UI; with that move, we have decided to remove the beat; as it was historical marketing stunt by Swatch. It was added for "fun" waaay back in the early days of Home Assistant.

I think keeping it can be considered if the use cases can be set out and carry significance.

../Frenck

andrewjswan commented 7 months ago

This integration has been moved to the UI; with that move, we have decided to remove the beat; as it was historical marketing stunt by Swatch. It was added for "fun" waaay back in the early days of Home Assistant.

Transferring to the GUI is good, each sensor is added separately there, i.e. we use those that are necessary, those that are not necessary we do not use (the same as in Yaml). Therefore, I don’t understand why they should delete Swatch time, which people use. Just leave it and give the opportunity to select it in the GUI, everything is already ready, and those who need it will select and add it.

Thanks, what is the use-case for keeping this at this point?

I have been using it since its appearance in 1998, I use it every day both at work and at home, it is very convenient especially when you are in different time zones. We schedule appointments, meetings online, etc. using it as an example.

frenck commented 7 months ago

I'm not aware of any calendar, online meeting software or any other systems that use beat. I'm happy to learn about them. Which ones do you use for this? And how does that related to integrating that in Home Assistant?

Can you describe a practical and common use case for Home Assistant itself for this?

../Frenck

andrewjswan commented 7 months ago

Can you describe a practical and common use case for Home Assistant itself for this?

Output to an indoor dashboard, output to a watch like Ulanzi TC001, display in messages including future ones. In principle, everything is the same as with a regular watch, but when family and work colleagues are in different time zones, it’s convenient.

Is it possible that a small part of the source code somehow interferes with the HA Core? It's simple math. And if you change it to a template, it is more complex than the current time sensor. https://github.com/home-assistant/core/blob/2d88b77813ac61adcb333f366aa9c61a6e0820ba/homeassistant/components/time_date/sensor.py#L203-L217

andrewjswan commented 7 months ago

Well, the difficulty of implementing this sensor in a template is that it must be updated once every 86.4 seconds, and as far as I know, the template engine cannot do this. Therefore, accuracy will suffer.

andrewjswan commented 7 months ago

One of my dashboards image

Petro31 commented 7 months ago
template:
- sensor:
  - name: Internet Time
    state: >
      {% set time_bmt = now() + timedelta(hours=1) %}
      {% set delta = timedelta(
                hours=time_bmt.hour,
                minutes=time_bmt.minute,
                seconds=time_bmt.second,
                microseconds=time_bmt.microsecond,
            ) %}
     {% set beat = (delta.total_seconds() * 10) | int // 864 %}
     {{ "@{0:03d}".format(beat) }}

EDIT: The previous implementation didn't update every 86.4 seconds it updated once a minute, but to do this with a template sensor... EDIT2: It did, looked in wrong spot on old code.

template:
- trigger:
  - platform: time_pattern
    microseconds: \600
  sensor:
  - name: Internet Time
    state: >
      {% set time_bmt = now() + timedelta(hours=1) %}
      {% set delta = timedelta(
                hours=time_bmt.hour,
                minutes=time_bmt.minute,
                seconds=time_bmt.second,
                microseconds=time_bmt.microsecond,
            ) %}
     {% set beat = (delta.total_seconds() * 10) | int // 864 %}
     {{ "@{0:03d}".format(beat) }}

This will force the entity to update every .6 seconds which will always fall on an increment of 86.4. IMO it's not necessary, and a 1 second interval would also get the job done. Or you can just leave it with the minutely updates.

andrewjswan commented 7 months ago

This will force the entity to update every .6 seconds which will always fall on an increment of 86.4

It is clear that any of the sensors that this integration provides can be replaced with a simple template (except for swatch time), you can also probably specify a time pattern in the form microseconds: \86400 (although I didn't find this in the documentation) or once per second or even once every half a second (although this will lead to additional load since the sensor is currently updated once every 86.4 seconds), but in the end we will get everything the same.

So why delete? Those who don’t need it don’t use it, and then the code for this sensor is not called; if it uses it, it’s called. Just leave the selection of this sensor in the GUI.

https://github.com/home-assistant/core/blob/2d88b77813ac61adcb333f366aa9c61a6e0820ba/homeassistant/components/time_date/sensor.py#L171-L174

Petro31 commented 7 months ago

So why delete?

The UI doesn't support variable update intervals. It had to be removed to bring it into the UI. There's your why, so please stop asking everywhere for the why.

andrewjswan commented 7 months ago

The UI doesn't support variable update intervals. It had to be removed to bring it into the UI.

This is the first, specific and sane answer to my question why. Due to the fact that the UI does not know how (although judging by the source code, only an entity needs to be created here, the internal mechanism already knows how to work with it, but here I could be wrong).

Can I use milliseconds in time_pattern? or only microseconds (but with such a large number, as I understand it, this does not work)?

parautenbach commented 7 months ago

How is Swatch beat time useful in any meaningful way, besides being an esoteric curiosity? It's use today seem to be pure novelty and hasn't survived concrete applicability.

andrewjswan commented 7 months ago

microseconds: \600

There are no microseconds in time_pattern, only seconds https://github.com/home-assistant/core/blob/69af00b36054032b3ffee063f0ec7f7effd4ab9e/homeassistant/components/homeassistant/triggers/time_pattern.py#L16-L18

andrewjswan commented 7 months ago

How is Swatch beat time useful in any meaningful way, besides being an esoteric curiosity? It's use today seem to be pure novelty and hasn't survived concrete applicability.

I use it at work and in my family, we are used to it and it’s convenient for us. Today I have a meeting at @750, no matter where the person is, in what time zone, he knows what time it will start, and in the same messenger or bot he simply sent @750:Text, and everyone knows when and what.

frenck commented 7 months ago

Hi @andrewjswan 👋

Based on this issue, the given description, and the use cases given in it, I've brought this up in a meeting I had earlier today with some of our Core maintainers. Together, we looked at this issue and talked about the case set out here.

I'm sorry to tell you that based on that discussion, we have unanimously decided not to bring this feature back in a future release and will continue the current deprecation period followed by the removal of it.

For that reason, I'm going to close this issue. Nevertheless, thanks for the suggestion and your views on the matter 👍

../Frenck

andrewjswan commented 7 months ago

For those who are looking for a solution, one of the options is a custom component https://github.com/andrewjswan/SwatchTime