V2/V3 - Uptime type timestamp shown in integer scientific notation

[Cossid]

The uptime sensor when used as type timestamp shows as scientific notation in the web browser display.

Example:

Uptime    2e+09

Desired display may be debated (readable static date/time of boot time as represented by the timestamp, or a changing "ago" duration). Perhaps a display_type attribute could be added.

[RFDarter]

hi, could you provide the content of http://<device-name>.local/events

it should look something like this:

retry: 30000
id: 71784
event: ping
data: {"title":"webserver","comment":"","ota":true,"log":true,"lang":"en"}

event: sorting_group
data: {"name":"Valve","sorting_weight":-1}

event: sorting_group
data: {"name":"Cover","sorting_weight":-2}

event: sorting_group
data: {"name":"Lock","sorting_weight":-3}

event: state
data: {"id":"cover-template_cover","name":"Template Cover","icon":"","entity_category":0,"value":1,"state":"OPEN","current_operation":"IDLE","sorting_weight":50,"sorting_group":"Cover"}

event: state
data: {"id":"lock-template_lock","name":"Template Lock","icon":"","entity_category":0,"value":0,"state":"UNKNOWN","sorting_weight":50,"sorting_group":"Lock"}

event: state
data: {"id":"valve-template_valve","name":"Template Valve","icon":"","entity_category":0,"value":1,"state":"OPEN","current_operation":"IDLE","sorting_weight":50,"sorting_group":"Valve"}

[Cossid]

event: state
data: {"id":"sensor-uptime","name":"Uptime","icon":"mdi:timer-outline","entity_category":2,"value":1.739218e9,"state":"2e+09"}

Is an example of an uptime sensor set to timestamp. Since it is a timestamp, the data backing the sensor doesn't change unless the device reboots, since it's a timestamp instead of a counter.

I haven't had a chance to check it out yet, but https://esphome.io/components/text_sensor/uptime.html was added in the most recent release, but it's more of a display fix for the seconds version of the component than the timestamp version.

The text sensor may need a way to handle timestamp and then this would be pretty moot.

[RFDarter]

ok I think I understand it now.

You would want to display the timestamp sensor on the webserver, so you would like to see that date and time when the device started right?

I guess that is not easily possible, since it is a sensor and only consists of a number value. Making it human readable would be hard.
I think the best way would be to modify the text_sensor/uptime to allow the same modes as the sensor/uptime has.

[Cossid]

I'm not expecting anything like what uptime text sensor does (I'm assuming it constantly updates the human readable part to an "ago" timeframe), but rather just something that can easily be read as a non-changing value. 2e+09 is completely useless, but 2025-02-24T06-00-00 would at least be useful (which is similar to how it is converted in Home Assistant I guess HA actually converts it to the ago format updating periodically).

I'm assuming the number is an epoch that would need to be converted to a string. I'm not sure how it's getting converted to scientific notation, I'm guessing something is converting an epoch int to float or something.

[RFDarter]

I'm assuming the number is an epoch that would need to be converted to a string. I'm not sure how it's getting converted to scientific notation, I'm guessing something is converting an epoch int to float or something.

But how would the webserver know if it is an epoch or just a regular sensor containing the same value as an epoch?

I still think modifying the uptime text_sensor is the way to go.

I'm not expecting anything like what uptime text sensor does (I'm assuming it constantly updates the human readable part to an "ago" timeframe),

Thats what it does at the moment.
Adding a type timestamp like on the uptime sensor would allow it to update only once on startup converting the epoch to a human readable string like 2025-02-24T06-00-00

[Cossid]

No idea, perhaps the component and associated event need to be updated with additional metadata, so it knows which type it is. The text_sensor is brand new since creating this issue, so I haven't had time to check it out yet, I'm simply aware it exists, and doesn't have an option to distinguish between the two types.

In terms of data, the timestamp method still has the advantage of the sensor itself not changing frequently, and therefor has less logging overhead for external platforms like HA that would log the changes of it. The seconds and text_sensor version still would be constantly changing values instead of just the interpretation of them changing.

[RFDarter]

The seconds and text_sensor version still would be constantly changing values instead of just the interpretation of them changing.

exactly.
Thats why I suggested adding the type timestamp to the uptime text_sensor
I pinged the guy how added the uptime text_sensor. Let's see what his take is on this.

[Cossid]

Right, and as I mentioned, at the time I created this ticket, uptime text_sensor didn't exist at all. I'd be fine with this getting converted to a ticket of enhancing the new text sensor.

[clydebarrow]

Thats why I suggested adding the type timestamp to the uptime text_sensor

HA doesn't like that, it expects a timestamp to be a simple number.

[RFDarter]

Thats why I suggested adding the type timestamp to the uptime text_sensor

HA doesn't like that, it expects a timestamp to be a simple number.

a number on a text_sensor ?

Isn't your uptime text_sensor simply converting the uptime to a human readable string?
So i guess it should be possible to convert an epoch to a string.

[RFDarter]

To clarify

The uptime sensor
allows you to specify the type.
If you choose seconds the sensor will update at the given interval and set it state to the current uptime in seconds
If you choose timestamp the sensor will update only once and set it state to the epoch the esp started

The uptime text_sensor
will update at the given interval and set it state to current uptime as a sting

The idea was to also add the type to the uptime text_sensor
to allow the user to choose if the text_sensor should contain the seconds since the esp started or the date and time the esp started.

[jesserockz]

The problem here is that the code converting the float (all sensors are floats) to a string is doing the scientific notation

https://github.com/esphome/esphome/blob/dev/esphome/core/helpers.cpp#L436-L445

std::string value_accuracy_to_string(float value, int8_t accuracy_decimals) {
  if (accuracy_decimals < 0) {
    auto multiplier = powf(10.0f, accuracy_decimals);
    value = roundf(value * multiplier) / multiplier;
    accuracy_decimals = 0;
  }
  char tmp[32];  // should be enough, but we should maybe improve this at some point.
  snprintf(tmp, sizeof(tmp), "%.*f", accuracy_decimals, value);
  return std::string(tmp);
}

The problem is it simply doesnt handle the large numbers

[jesserockz]

Following up to my above, I just tested in regular c++ and it prints fine 🤔

#include <cstdio>

int main() { printf("%.*f\n", 0, 1740435445.0f); }

$ gcc accuracy.cpp -o accuracy && ./accuracy
1740435456