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

Need a name for sensor device class to show relative time #39

Closed
c727 opened this issue Jun 16, 2018 · 12 comments
Closed

Need a name for sensor device class to show relative time #39

c727 opened this issue Jun 16, 2018 · 12 comments

Comments

@c727
Copy link

c727 commented Jun 16, 2018

Background is this PR: home-assistant/core#14983 about the HA uptime sensor. Currently it's updating its state every 30 sec and flooding the state machine.

The state of the new sensor class will be an ISO formatted datetime (that you set once) and on the frontend we will show it as relative time like 3 days ago and keep it updated there. (balloobs's idea)

Class name suggestions:

  • period
@OttoWinter
Copy link
Member

OttoWinter commented Jun 16, 2018

I mean it might be appear as a period in the frontend, but in the back end it's just a timestamp, right?

If we were to call it "time period" I'm sure that could cause some confusion when someone tries to use this device class to show a static time period, like travel time to work.

So I would say "timestamp" would be more appropriate.

@c727
Copy link
Author

c727 commented Jun 16, 2018

Hmmm... Uptime: 3 hours ago is a bit strange. So I will also change the default name to something like Restarted or we create 2 new classes: one will show 3 hours and the other will show 3 hours ago

@OttoWinter
Copy link
Member

OttoWinter commented Jun 16, 2018

Ok so I think there are three types of times that could be represented by sensors:

  • "Static" time period, like the amount of time to get to work. 15 min. Suggestion: time_period (TBD)
  • A timestamp; an event at a specific time. As per @c727: 3 hours ago. Suggestion: timestamp (TBD)
  • Combination of the two. A time period that starts from a static timestamp like uptime. Suggestion: relative_timestamp (this issue)

Obviously, it won't be possible to accommodate all of these in a single device class and we don't need the other device classes yet, but naming these consistently from the start is definitely good 👍

@balloob
Copy link
Member

balloob commented Jun 16, 2018

I guess if we keep device classes to the content, timestamp is in this case the most appropriate. I guess the frontend will need to be updated to render it then both by showing the timestamp and showing how long it was ago. Depending on the data, one could be more important than the other.

@c727
Copy link
Author

c727 commented Jun 16, 2018

And do you think we should support both: uptime: 3 hours and restart: 3 hours _ago_ or is one enough?

@c727
Copy link
Author

c727 commented Jun 17, 2018

Otto, I think for the static example we don't need a class as the state would not be updated every interval

@exxamalte
Copy link

Displaying a timestamp as a relative time from now is very use-case dependent, so keeping data type and view type independent would be preferable.
Also, keep in mind that the timestamp can be in the future: "Next Bus: in 5 minutes"

@c727
Copy link
Author

c727 commented Jun 17, 2018

^it will only effect this one device_class

@awarecan
Copy link

awarecan commented Jun 18, 2018

I also need one to display timestamp in future. For example, ETA: in 5 minutes

Ha, just saw @exxamalte comment after submit my comment.

@balloob
Copy link
Member

balloob commented Jun 19, 2018

I think just making it device class timestamp is the way to go . If timestamp is in the future, we add "in X", else it's "X ago", depending on locale.

With experimental UI, people can choose if they want to see the relative time or the timestamp.

@balloob
Copy link
Member

balloob commented Nov 23, 2018

Okay, we're going for timestamp. UI support is landing in 0.84 for it: home-assistant/frontend#2087

UI will support all the different display options so we don't have to make a choice

@balloob
Copy link
Member

balloob commented Nov 23, 2018

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

5 participants