Closed andrewjswan closed 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!
(message by CodeOwnersMention)
time_date documentation time_date source (message by IssueLinks)
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
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.
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
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
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.
One of my dashboards
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.
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.
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.
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)?
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.
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
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.
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
For those who are looking for a solution, one of the options is a custom component
https://github.com/andrewjswan/SwatchTime
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 & DateExample YAML snippet
Anything in the logs that might be useful for us?
No response
Additional information
No response