Hub1200 clock deviating in "offline" mode

[nfocke]

Thanks to @reinhard-brandstaedter great work, I have been running my Hub1200 in offline mode with a local MQTT broker for some time now (about 8 weeks). I typically do my own processing of the Zendure payloads based on the "timestamp" provided by the hub's messages. I also forward to the "official" Zendure MQTT broker, to keep the hub "online" and visible in the app. This way, it was shown online and the app showed all the usual data. Only, control via app was not (yet) possible since I did not pass through the control messages from the app.

However, since 1-2 days ago the hub is now shown as offline in the app, and also on my local frontend. When investigating further, the issues seems to be that the timestamps provided by the hub are >5 minutes deviating form the "real" time / UTC timestamps (which was the cutoff also used in my frontend). For my local frontend, I can simply use the receiving timestamp. For the official Zendure broker/app, this does not work, Of course, I could simply overwrite the hub-provided timestamp with the real time, but this is just curing the symptom of timeshift, not the cause. It usually is not a good idea if any system time deviates to strongly from the reality...

Hence, the question: has anyone made similar experience? And if so, is anyone aware how Zendure "officially" does the time-syncs of the hub? Do they? I suspect there may be other communication channels / topics than the usual iot/#/#/properties/write/...

[reinhard-brandstaedter]

Interesting, indeed. I would assume that a IoT device would use a ntp server for time sync and not rely on any other way. Since I'm not using any time information I haven't had any issues. But I can confirm that my hub's time has deviated already by 12 minutes by checking the regular /../../properties/report message.

[reinhard-brandstaedter]

I can confirm that the hub publishes a time-sync message to MQTT which seems to indicate that it requests a time sync and expects another message to get the new timestamp.

[nfocke]

Interesting. I did not see such an MQTT topic yet, but is seems to be rare (12,000 property messages vs. just 2 time-sync). Will keep my MQTT explorer running for a bit longer... @reinhard-brandstaedter Did you record a response in the iot/* topics? Probably the sync back happens there?

[reinhard-brandstaedter]

@nfocke I found out how to set the time. Here is what you need to publish (timestamp is unix seconds in UTC)

Topic: iot/<product id>/<device id>/time-sync/reply

content:

{
  "zoneOffset": "+02:00",
  "messageId": 385978251794853888,
  "timestamp": 1715794789
}

Seems it doesn't matter if this is really a reply or sent any time. I'll build this into solarflow-control to sync the time every morning or so...

[nfocke]

@reinhard-brandstaedter Thx! Confirmed. Works for me as well. Even did a bug test, accidentally have used microseconds timestamp...the hub then switched to max timestamp (2038) but happily counted on from there... so we may be safe until even after UNIX timestamp overflow ;)

[tuxianerDE]

There is a fix implemented in the solarflow-control DEV branch of the main control skript that will set the timestamp now as well. Thus suggest either to close the issue as a clean up :)