feat: support sensors which are timestamps (like uptime sensor) #677
Conversation
* use the default `filter` option for sensors * parse with `timeAgo` in case we have a timestamp * include the word `ago`, because timestamps are indeed ago * add hint how to exclude the word `ago` for the uptime sensor Localization should be handled separately, and globally for all places where `moment` is used. In order to allow the user to profit from this further localization, `moment()` should be then be made available by `utils.js`. closes resoai#671
| if (entity?.attributes?.device_class === 'timestamp') { | ||
| return timeAgo(value, false); | ||
| } |
There was a problem hiding this comment.
Just thinking aloud but I was wondering if device_class === timestamp implies that it's the "uptime" type of sensor? Because that change might not make sense for sensors other than uptime types.
But since I don't know the cases where those sensors are used, I won't argue with it and assume that it's a good default.
There was a problem hiding this comment.
We didn't want to argue. :-) Still...
I have not found any other standard HA integration with timestamp device class. So, uptime seems to be the most common use case.
However, there are people using custom sensors, such as "last time that file changed". Also for those sensors, timeAgo is a decent default for a dashboard display.
Then, there might be power users that really want to see the actual timestamp. They would have to change the filter then.
rchl
changed the title
filteroption for sensorstimeAgoin case we have a timestampago, because timestamps are indeed agoagofor the uptime sensorLocalization should be handled separately, and globally for all places where
momentis used.In order to allow the user to profit from this further localization,
moment()should be then be made available byutils.js.closes #671