search

esphome / issues

Issue Tracker for ESPHome
https://esphome.io/
290 stars 36 forks source link

ESPHome Time Component - .timestamp not updating #2674

Open behnam85 opened 3 years ago

behnam85 commented 3 years ago

The problem

Time component .timestamp not updating. The .second is working fine. The .timestamp is working fine on ESP_LOGI and .timestamp updated. The .timestamp only updates every 128 seconds

Which version of ESPHome has the issue?

2021.10.3

What type of installation are you using?

Home Assistant Add-on

Which version of Home Assistant has the issue?

2021.10.7

What platform are you using?

ESP32

Board

No response

Component causing the issue

time

Example YAML snippet

substitutions:

  textname: templatexx
#globals:
#   - id: template_sens
#     type: float  
#    restore_value: no
#    initial_value: '000000000000000' 
#   - id: my_vmin_int
#     type: float
#     restore_value: no
#     initial_value: '250'   

esphome:
  name: esp321
  platform: ESP32
  board: lolin32

wifi:
  ssid: "Mi wifi"
  password: "behnam123"

  # Enable fallback hotspot (captive portal) in case wifi connection fails
  ap:
    ssid: "Esp321 Fallback Hotspot"
    password: "coCKxLsID1nI"

captive_portal:

# Enable logging
logger: 
  level: debug

# 6Enable Home Assistant API
mqtt:

  broker: 192.168.2.31
  username: homeassistant
  password: pho7weeN3Yie9ohNgoh8yeom5ou5iNgeichiNgaeheeneR1auhae8Vief6oophut
  keepalive: 30s
  reboot_timeout: 0s
ota:

uart:
  rx_pin: 32
  baud_rate: 9600
##########################################

# Declare GPS module
gps:
  latitude:
    name: "Latitude"
  longitude:
    name: "Longitude"
  altitude:
    name: "Altitude"
    id: a

# GPS as time source
time:
  - platform: gps
    id: gps_time

    on_time:
      - seconds: '*'
        then: 
          - lambda: |-
#             ESP_LOGI("gps", "%02d:%02d:%02d",id(gps_time).now().hour, id(gps_time).now().minute, id(gps_time).now().second);
#             ESP_LOGI("gphs","%02d-%02d-%02d %02d:%02d:%02d",  id(gps_time).now().timestamp);
#             ESP_LOGI("gps1" , "%02d-%02d-%02d %02d:%02d:%02d", id(gps_time).now().year, id(gps_time).now().month, id(gps_time).now().day_of_month, id(gps_time).now().hour, id(gps_time).now().minute, id(gps_time).now().second);             

          - sensor.template.publish:
             id: template_sens
             state: !lambda
               'return id(gps_time).now().timestamp;'
          - text_sensor.template.publish:
             id: last_bell_press
             state: !lambda |-
                char str[20];
                time_t currTime = id(gps_time).now().timestamp;
                strftime(str, sizeof(str), "%Y-%m-%d %H:%M:%S", localtime(&currTime));

                return  { str };

interval:
  - interval: 2s
    then:
      - lambda: |-
          auto time_t = id(gps_time).utcnow().timestamp;
          auto time_s = id(gps_time).utcnow().second;
          if (id(gps_time).utcnow().is_valid()) {
            id(timestamp_sec).publish_state(time_t);
            id(time_seconds).publish_state(time_s);
          }

sensor: 

  - platform: template
    name: "Current time stamp"
    id: timestamp_sec

  - platform: template
    name: "Current time"
    id: time_seconds

  - platform: template
    name: "Template Sensor"
    id: template_sens
#    accuracy_decimals: 0
#    update_interval: 1s  
#    device_class: timestamp
#######################################
text_sensor:
  - platform: template
    name: "Template Text Sensor"
    id: last_bell_press

Anything in the logs that might be useful for us?

[11:31:13][D][text_sensor:067]: 'Template Text Sensor': Sending state '2021-11-03 11:31:13'
[11:31:13][D][gps:040]: Location:
[11:31:13][D][gps:041]:   Lat: ****
[11:31:13][D][gps:042]:   Lon: ****
[11:31:13][D][gps:057]: Altitude:
[11:31:13][D][gps:058]:   1330.699951 m
[11:31:13][D][gps:062]: Satellites:
[11:31:13][D][gps:063]:   7
[11:31:13][D][sensor:113]: 'Current time stamp': Sending state 1635926528.00000  with 1 decimals of accuracy
[11:31:13][D][sensor:113]: 'Current time': Sending state 13.00000  with 1 decimals of accuracy
[11:31:13][D][sensor:113]: 'Current time stamp': Sending state 1635926528.00000  with 1 decimals of accuracy
[11:31:13][D][sensor:113]: 'Current time': Sending state 13.00000  with 1 decimals of accuracy
[11:31:14][D][gps:040]: Location:
[11:31:14][D][gps:041]:   Lat: ****
[11:31:14][D][gps:042]:   Lon: ****
[11:31:14][D][gps:047]: Speed:
[11:31:14][D][gps:048]:   0.111120 km/h
[11:31:14][D][gps:052]: Course:
[11:31:14][D][gps:053]:   0.000000 °
[11:31:14][I][gps:074]: 11:31:14:1635926474
[11:31:14][D][sensor:113]: 'Template Sensor': Sending state 1635926528.00000  with 0 decimals of accuracy
[11:31:14][D][text_sensor:067]: 'Template Text Sensor': Sending state '2021-11-03 11:31:14'
[11:31:14][D][gps:040]: Location:
[11:31:14][D][gps:041]:   Lat: ****
[11:31:14][D][gps:042]:   Lon: ****
[11:31:14][D][gps:057]: Altitude:
[11:31:14][D][gps:058]:   1330.699951 m
[11:31:14][D][gps:062]: Satellites:
[11:31:14][D][gps:063]:   7
[11:31:14][D][sensor:113]: 'Current time stamp': Sending state 1635926528.00000  with 1 decimals of accuracy
[11:31:14][D][sensor:113]: 'Current time': Sending state 14.00000  with 1 decimals of accuracy
[11:31:14][D][sensor:113]: 'Current time stamp': Sending state 1635926528.00000  with 1 decimals of accuracy
[11:31:14][D][sensor:113]: 'Current time': Sending state 14.00000  with 1 decimals of accuracy
[11:31:15][D][gps:040]: Location:
[11:31:15][D][gps:041]:   Lat: ****
[11:31:15][D][gps:042]:   Lon: ****
[11:31:15][D][gps:047]: Speed:
[11:31:15][D][gps:048]:   0.074080 km/h
[11:31:15][D][gps:052]: Course:
[11:31:15][D][gps:053]:   0.000000 °
[11:31:15][I][gps:074]: 11:31:15:1635926475
[11:31:15][D][text_sensor:067]: 'Template Text Sensor': Sending state '2021-11-03 11:31:15'
[11:31:15][D][gps:040]: Location:
[11:31:15][D][gps:041]:   Lat: ****
[11:31:15][D][gps:042]:   Lon: ****
[11:31:15][D][gps:057]: Altitude:
[11:31:15][D][gps:058]:   1330.699951 m
[11:31:15][D][gps:062]: Satellites:
[11:31:15][D][gps:063]:   7
[11:31:15][D][sensor:113]: 'Current time stamp': Sending state 1635926528.00000  with 1 decimals of accuracy
[11:31:15][D][sensor:113]: 'Current time': Sending state 15.00000  with 1 decimals of accuracy
[11:31:15][D][sensor:113]: 'Current time stamp': Sending state 1635926528.00000  with 1 decimals of accuracy
[11:31:15][D][sensor:113]: 'Current time': Sending state 15.00000  with 1 decimals of accuracy
[11:31:16][D][gps:040]: Location:
[11:31:16][D][gps:041]:   Lat: ****
[11:31:16][D][gps:042]:   Lon: ****
[11:31:16][D][gps:047]: Speed:
[11:31:16][D][gps:048]:   0.203720 km/h
[11:31:16][D][gps:052]: Course:
[11:31:16][D][gps:053]:   0.000000 °
[11:31:16][I][gps:074]: 11:31:16:1635926476
[11:31:16][D][sensor:113]: 'Template Sensor': Sending state 1635926528.00000  with 0 decimals of accuracy
[11:31:16][D][text_sensor:067]: 'Template Text Sensor': Sending state '2021-11-03 11:31:16'
[11:31:16][D][gps:040]: Location:
[11:31:16][D][gps:041]:   Lat: ****
[11:31:16][D][gps:042]:   Lon: ****
[11:31:16][D][gps:057]: Altitude:
[11:31:16][D][gps:058]:   1330.699951 m
[11:31:16][D][gps:062]: Satellites:
[11:31:16][D][gps:063]:   7
[11:31:16][D][sensor:113]: 'Current time stamp': Sending state 1635926528.00000  with 1 decimals of accuracy
[11:31:16][D][sensor:113]: 'Current time': Sending state 16.00000  with 1 decimals of accuracy
[11:31:16][D][sensor:113]: 'Current time stamp': Sending state 1635926528.00000  with 1 decimals of accuracy
[11:31:16][D][sensor:113]: 'Current time': Sending state 16.00000  with 1 decimals of accuracy
[11:31:17][D][gps:040]: Location:
[11:31:17][D][gps:041]:   Lat: ****
[11:31:17][D][gps:042]:   Lon: ****
[11:31:17][D][gps:047]: Speed:
[11:31:17][D][gps:048]:   0.092600 km/h
[11:31:17][D][gps:052]: Course:
[11:31:17][D][gps:053]:   0.000000 °
[11:31:17][I][gps:074]: 11:31:17:1635926477
[11:31:17][D][text_sensor:067]: 'Template Text Sensor': Sending state '2021-11-03 11:31:17'
[11:31:17][D][gps:040]: Location:
[11:31:17][D][gps:041]:   Lat: ****
[11:31:17][D][gps:042]:   Lon: ****
[11:31:17][D][gps:057]: Altitude:
[11:31:17][D][gps:058]:   1330.699951 m
[11:31:17][D][gps:062]: Satellites:
[11:31:17][D][gps:063]:   7
[11:31:17][D][sensor:113]: 'Current time stamp': Sending state 1635926528.00000  with 1 decimals of accuracy
[11:31:17][D][sensor:113]: 'Current time': Sending state 17.00000  with 1 decimals of accuracy
[11:31:17][D][sensor:113]: 'Current time stamp': Sending state 1635926528.00000  with 1 decimals of accuracy
[11:31:17][D][sensor:113]: 'Current time': Sending state 17.00000  with 1 decimals of accuracy
[11:31:18][D][gps:040]: Location:
[11:31:18][D][gps:041]:   Lat: ****
[11:31:18][D][gps:042]:   Lon: ****
[11:31:18][D][gps:047]: Speed:
[11:31:18][D][gps:048]:   0.037040 km/h
[11:31:18][D][gps:052]: Course:
[11:31:18][D][gps:053]:   0.000000 °
[11:31:18][I][gps:074]: 11:31:18:1635926478
[11:31:18][D][sensor:113]: 'Template Sensor': Sending state 1635926528.00000  with 0 decimals of accuracy
[11:31:18][D][sensor:113]: 'Current time stamp': Sending state 1635926528.00000  with 1 decimals of accuracy
[11:31:18][D][sensor:113]: 'Current time': Sending state 18.00000  with 1 decimals of accuracy
[11:31:19][D][gps:040]: Location:
[11:31:19][D][gps:041]:   Lat: ****
[11:31:19][D][gps:042]:   Lon: ****
[11:31:19][D][gps:047]: Speed:
[11:31:19][D][gps:048]:   0.129640 km/h
[11:31:19][D][gps:052]: Course:
[11:31:19][D][gps:053]:   0.000000 °
[11:31:19][I][gps:074]: 11:31:19:1635926479
[11:31:19][D][text_sensor:067]: 'Template Text Sensor': Sending state '2021-11-03 11:31:19'
[11:31:19][D][gps:040]: Location:
[11:31:19][D][gps:041]:   Lat: ****
[11:31:19][D][gps:042]:   Lon: ****
[11:31:19][D][gps:057]: Altitude:
[11:31:19][D][gps:058]:   1330.800049 m
[11:31:19][D][gps:062]: Satellites:
[11:31:19][D][gps:063]:   7
[11:31:19][D][sensor:113]: 'Current time stamp': Sending state 1635926528.00000  with 1 decimals of accuracy
[11:31:19][D][sensor:113]: 'Current time': Sending state 19.00000  with 1 decimals of accuracy
[11:31:19][D][sensor:113]: 'Current time stamp': Sending state 1635926528.00000  with 1 decimals of accuracy
[11:31:19][D][sensor:113]: 'Current time': Sending state 19.00000  with 1 decimals of accuracy
[11:31:20][D][gps:040]: Location:
[11:31:20][D][gps:041]:   Lat: ****
[11:31:20][D][gps:042]:   Lon: ****
[11:31:20][D][gps:047]: Speed:
[11:31:20][D][gps:048]:   0.203720 km/h
[11:31:20][D][gps:052]: Course:
[11:31:20][D][gps:053]:   0.000000 °
[11:31:20][I][gps:074]: 11:31:20:1635926480
[11:31:20][D][sensor:113]: 'Template Sensor': Sending state 1635926528.00000  with 0 decimals of accuracy
[11:31:20][D][text_sensor:067]: 'Template Text Sensor': Sending state '2021-11-03 11:31:20'
[11:31:20][D][gps:040]: Location:
[11:31:20][D][gps:041]:   Lat: ****
[11:31:20][D][gps:042]:   Lon: ****
[11:31:20][D][gps:057]: Altitude:
[11:31:20][D][gps:058]:   1330.800049 m
[11:31:20][D][gps:062]: Satellites:
[11:31:20][D][gps:063]:   7
[11:31:20][D][sensor:113]: 'Current time stamp': Sending state 1635926528.00000  with 1 decimals of accuracy
[11:31:20][D][sensor:113]: 'Current time': Sending state 20.00000  with 1 decimals of accuracy
[11:31:20][D][sensor:113]: 'Latitude': Sending state 38.43681 ° with 6 decimals of accuracy

Additional information

Untitled

OttoWinter commented 3 years ago

Try sending the value to a text sensor instead.

Sensor encodes the value as a float, likely the timestamp is large enough that floats can't represent the number accurately anymore.

Jpsy commented 3 years ago

I just worked on that same problem. It is definitely the result of the fact that publish_state uses a float input parameter and the 4 byte floats have not enough resolution to store all digits of a Unix epoche value measured in milliseconds. The quantization error is about +/- 64 seconds on the values that appear in HA.

A text_sensor is no replacement as it accepts no device_class. In HA this will only be a string, but never a timestamp.

I see two options, both being feature requests:

  1. Add device_class properties to text_sensors. From all possilble device classes I currently see "date" and "timestamp" as possible targets for this feature.
  2. Add a publish_state_double method to sensors which accepts doubles instead of floats. This would be helpful in many cases. The current publish_state is not capable of using HA's full state resolution.

If there is any chance that one of these options could be implemented I would be happy to issue a feature request. Could you give me some feedback?

Jpsy commented 3 years ago

Related to #1099

OttoWinter commented 3 years ago

Add a publish_state_double method to sensors which accepts doubles instead of floats. This would be helpful in many cases. The current publish_state is not capable of using HA's full state resolution.

Not really an option IMO. That would mean all internals like filters and so on would need to switch to double too. But that has substantial performance regressions when I last tested it on these constrained systems. For an edge case like this that wouldn't be worth it.

Add device_class properties to text_sensors. From all possilble device classes I currently see "date" and "timestamp" as possible targets for this feature.

Yeah that's probably the best way. For timestamp the value should be an ISO8601 string - which is what HA expects (for normal sensor the esphome HA integration does some conversion of the number to a iso8601 string, but for text sensor we shouldn't do that).

oxan commented 3 years ago

Sensor encodes the value as a float, likely the timestamp is large enough that floats can't represent the number accurately anymore.

Yes, this is the problem, we should probably add a note about it to the documentation though, not the first report of this (#1099).

OttoWinter commented 3 years ago

Sensor encodes the value as a float, likely the timestamp is large enough that floats can't represent the number accurately anymore.

Yes, this is the problem, we should probably add a note about it to the documentation though, not the first report of this (#1099).

Yeah probably we should even remove timestamp support from sensor completely (it's the only instance i know of where the values get that high) when we have device class support for text sensors (and perhaps integration in the uptime integration as well)

Jpsy commented 3 years ago

Yeah probably we should even remove timestamp support from sensor completely...

That would be a breaking change but much cleaner. The sensor for timestamps will probably continue to confuse users because of the quantization effects.

tungmeister commented 2 years ago

Is there a solution to this? I'm currently rendering a progress bar on a display, I'm calculating the position of the progress bar using the media_duration, media_position and media_position_updated_at (cast to a float) attributes from a media_player. because the timestamp is only updating every couple of minutes the position of the progress bar only updates comparably and I'd rather it be much more granular.

tungmeister commented 2 years ago

For anyone else having this issue, if you cast the timestamp to an int or double it will update correctly e.g:

static_cast<double>(id(esptime).timestamp_now())
akomelj commented 2 years ago

Yeah probably we should even remove timestamp support from sensor completely (it's the only instance i know of where the values get that high) when we have device class support for text sensors (and perhaps integration in the uptime integration as well)

Is anyone already working on the device class implementation for text sensors? I can implement underlying functionality (adding configuration key to schema & validations & publishing the setting to discovery topics) and submit a PR, however - before jumping in - I would just like to check if devs have bigger plans for this or someone is already working on it? Someone would probably still need to go through existing text sensor integrations and classify them accordingly afterwards...

mbuzina commented 2 years ago

The HASS API changed to allow python object (native objects). Maybe the best solution would be a dedicated sensor_timestamp which returns a python dateteime object to home assistant, taking in an esphome::time::ESPTime?

Snip from https://developers.home-assistant.io/docs/core/entity/sensor/#available-device-classes

timestamp |   | Timestamp. Requires native_value to return a Python datetime.datetime object, with time zone information, or None. -- | -- | --

I tried the sensor with device_class timestamp route, as I would not care too much about the precision and the log states that it sends the correct value in ms, but HA still displays epoch 0.

fakuivan commented 1 year ago

Any updates on this? It feels weird for the solution to be switching to text sensors. Are floats hardcoded into the filter code? Could templates be used for this?

ssieb commented 1 year ago

Nothing to do with filters. An esphome sensor: of whatever type holds a float value and the API to HA transfers a float value.

fakuivan commented 1 year ago

Thanks for clarifying, mind pointing to the code that defines how the sensor values are sent? How hard would it be to make it accept doubles or integral types too?

ssieb commented 1 year ago

It's in the protobuf I guess. But the state value that the sensor holds is a float, so you can't get past that. If you wanted to change it to other types, then you would have to modify everything about how sensors work and change the api protocol all the way to the HA integration.

dougiteixeira commented 9 months ago

I created a PR to add support for the TIMESTAMP and DATE device classes in the text sensor, reflecting in the API and MQTT: https://github.com/esphome/esphome/pull/6202

After starting the PR review, I will create the PR for the changes to the aioesphomeapi package and the ESPHome integration in Home Assistant, the changes are ready and tested locally.