Timestamp off by 170 seconds

Configuration
1 
- id: "bms_time_sync_mqtt_automation"
  alias: "Systemzeit per MQTT versenden"
  initial_state: true
  trigger:
    - platform: mqtt
      topic: bms/status
    - platform: time_pattern
      minutes: "/10"      
  condition: []
  action:
    - service: mqtt.publish
      data:
        topic: bms/time/set
        payload: "{{ as_timestamp(utcnow()) | int + 170 }}"
        qos: 1
        retain: false
  mode: single

Probably my mistake but given the fact that HA and EspHome ..... :-X

To me HomeAssistant itself is almost deprecated - a term the developers here seem to love :slight_smile:

2

Hello ViennaTom,
Do you have a question the community can help you with?
Or are you just sharing your automation?

If you are seeing a time problem make sure your HA, server, and Router are updating to a web NTP source.
I sync my firewall device to a network source for NTP and DNS, then sync all the stuff on my network to my firewall.
Keeps everything 'on the same page'.

3

HA use a SNTP client to keep the time in sync.
It is not perfect at that, but it is light on resources.
SNTP allow the time to drift or skew between syncs and that is especially dominant on virtual machines where the resources are shared between multiple VMs abd where there at times peak hours.

Switching to a NTP client instead will improve the time precision, but will also consume some resources.
The Chrony addon provides a NTP server and also enables the HA time sync to switch to NTP instead of SNTP.

4

Well i am developing in espidf 6.0.1. The sntp client (in espidf on esp32) blocks my various tasks even though i used a fixed ip for the ntp server and reduced sntp task priority.

The time is correct on my HA server but the timestamp send as above is constanty wrong by 170 seconds. Even good old DOS could handle that :wink:

5

Maybe clarify how something simple as a timestamp can be wrong ?

My HA is hosted by Proxmox - maybe that can be a reason ?

6

Honestly, time is one of the least simple things in automation.

I did provide some suggestions already, make sure everything is referencing the same device for time, no matter where it is. Otherwise one is asking Mommy and the other is asking Daddy and they get slightly different answers so no one is right.

7

You say the SNTP is using system resources? That should not be possible SNTP, ANTP is very simpla and cruding set s the clock one then quits. Then in the ESP-IDF implementation does this again about every hour. SNTP is typically good enough is "a second or so" to accurate enough.

Sune system that use SNTP use it only one when the system boots and then time just drifts

If you care at all about time, you need to use NTP. Not SNTP. Using NTP it is easy to keep time accurate to under a millisecond. The best way is to create a local NTP server and sync it to between three and five external NTP servers. You need enough external servers so that the NTP software can detect if one is wrong. Five is a good number, three is a minimum. NTP will compute "consensus time" from the pool of NTP serveres you give it.. If you are really nuts buy a GPS reciever and use that in addition to the external GPS receivers and then you get microsecond level accuracy.

Then you point all of the computers and routers and ESP devices to that local NTP server. Every system call you make, you need to check for an error.

But you are seeing a huge 170 second error? If so, then I suspect you are trying to use SNTP, it is failing and you are not checking for errors and wrongly assuming it is working.

8

HAUTC
HAUTC1068×633 44.5 KB

Maybe i did not describe my observation clearly enough and chose the wrong section as it is not a problem of automations but seems to be more a generic "bug" or intended "misbehaviour" ....

I DO know how to configure automations. I was implementing this MQTT-timesync method as my ESP32 based HV-battery controller can not use an ntp client nor an sntp client as both of them cause blocking timeouts in the espidf environment.

Those 170 seconds are the offset of the REAL time (which is correctly displayed and used in HA) and the WRONG raw value. I hope the attached screenshot describes ?!

9

To me it seems to be a slight bug. Should be fixable easily.

Wrong timestamp

I did not find a category to report bugs. The "deprecation" team seems to be so selfconfident :slight_smile:

10

Not really. You show an automation that uses a template to publish what HA thinks the current timestamp is. but the screenshot shows a sensor I assume? Where do you source the sensor "UTC Raw Value"?

This is unlikely a bug and more likely an issue with your environment.

11 
template:
  - trigger:
     - platform: time_pattern
       seconds: "/1"
  sensor:
     - name: "UTC raw"
       state: "{{ as_timestamp(utcnow()) | int }}"

What is supposed to be wrong here ?

I guess there is no timezone setting -170" :wink:

I only defined that template sensor to display the UTC value concurrently to the time. I could care less, i am just adding 170" to get the right value....

12

Bug reports go here: Issues · home-assistant/core · GitHub

13

There is no HA bug afaict.
Why you HA clock is off by 170 sec? I don't know, but mine is surely not:

image
image1493×224 18.9 KB

As said on the other thread, likely something wrong with your server.

14

But it is not the clock that is wrong. The clock is perfectly right and adjusted by ntp. It is only the utcnow() reporting a value 170" different !

Ok i see in your screen it seems to be correct - hmm ?

Tried in the template editor just as you did and still the offset. Well if it is only at my installation ... miraculeux !

15

Show us the same screenshot as I did :wink:

16

Ok - so you have showed us where the sensor value comes from - looks like HA itself has the wrong time? What does this template show:

{{ now() }}

2026-07-01 19:53:03.891417+10:00

By this I assume you mean your Proxmox server...

What do your region settings show under Settings | System | Home Information?

This is still looking like a problem with your time source rather than a HA issue...

17

UTCtime
UTCtime2158×874 70.5 KB

Hmm, so the utc value is the right one but the local time display not ? Crazy !

18

At the left side of the screenshot is a simple clock card (GMT+01:00) Vienna
it shows 11:58 and the same rawvalue (+/-1) right ?

19

Well to me it is proxmox hosting a HA-vm which to me is kind of a server. My Region settings are (GMT+01:00) Vienna.
I opened another thread sorry for such small issue !

20

Show us the actual time on your PC.
None of the timestamps is 11:58, for sure