Local MQTT Time Stamps
in Local MQTT
I note from the Blog https://medium.com/@joshua.cooper/glow-local-mqtt-f69b776b7af4 that the timestamp has a Z on the end to indicate UTC.
This is not part of the standard and several systems (notably PHP) do not process it correctly.
The timestamp should have "+00:00" on the end rather than the Z.
Comments
The timestamp is local (not Zulu) anyway.
Timestamp on mine seems to be Zulu time
Message 2 received on glow/xxxxx/STATE at 17:20:
{
"software": "v1.8.12",
"timestamp": "2022-06-13T16:20:32Z",
"hardware": "GLOW-IHD-01-1v4-SMETS2",
"ethmac": "xxxxx",
"smetsversion": "SMETS2",
"eui": "xxxxxx",
"zigbee": "1.2.5",
"han": {
"rssi": -63,
"status": "joined",
"lqi": 148
}
}
QoS: 0 - Retain: false
[quoting doesn't work for me]
"Timestamp on mine seems to be Zulu time"
The point is that timestamp with 'Z' is not correct vis the ISO standard - it is an option that many computer systems do not implement correctly.
The reply was to the comment from Dougie who stated that the timestamp is local time. Which it isn't on mine, it is UTC.
Are you referring to ISO 8601?
Sorry I was wrong. It is a Zulu timestamp so should be in the format yyyy-dd-mmThh:mm:ssZ.
And it seems that Z is acceptable in the ISO format as well.
And if PHP has an issue with it, then maybe this will help
https://php.watch/versions/8.0/date-utc-p-format#:~:text=The%20difference%20between%20P%20and,42%3A34%2B00%3A00
From Wikipedia ...
Coordinated Universal Time (UTC)[edit]
If the time is in UTC, add a Z directly after the time without a space. Z is the zone designator for the zero UTC offset. "09:30 UTC" is therefore represented as "09:30Z" or "T0930Z". "14:45:15 UTC" would be "14:45:15Z" or "T144515Z".
The Z suffix in the ISO 8601 time representation is sometimes referred to as "Zulu time" because the same letter is used to designate the Zulu time zone. However the ACP 121 standard that defines the list of military time zones makes no mention of UTC and derives the "Zulu time" from the Greenwich Mean Time[28] which was formerly used as the international civil time standard. GMT is no longer precisely defined by the scientific community and can refer to either UTC or UT1 depending on context.[29]
Not sure if this is helpful or not.
The Smart Meter isn't 'smart' enough to cope with BST so the time stamp is based on GMT so the timestamp is only correct during GMT and 1 hour out (behind) during BST. This isn't Hildebrand's fault as it originates from the meter. The 'day' reading starts when it's midnight for the meter not 'real' midnight so, at present, the day reading starts at 1am and finishes at 1am the following day so you need to be careful what you do with the data if you have something like Economy 7 and using a lot of electricity at night if you want the data to match.
Hi, I'm facing exactly the same issue. It's really annoying since it messes up the energy dashboards for half of the year. Any suggestions how to offset the BST timestamp - either when it's received by MQTT broker, or when it's pulled/digested by Home Assistant?
For ref, the simplest way to work around the UTC timestamp issue during BST ('Today'/'This Week'/'This Month' counters reset at 1am instead of at 12am) in Home Assistant is to configure a custom utility meter helper which is fed from the ...meter/energy/import/cumulative entry and resets every day (or every week, or every month). The reset time is then defined by the HA environment which is under your full control, i.e. stays at 12am the whole year. Simple but very effective. Significant if you use e.g. a cheaper nightly tariff starting at 0:30am which would be otherwise added to the previous day.
🙂@mydliar seems sensible - no idea how to do that!
@tobyt - do you have Home Assistant (home-assistant.io) running, connected to your Glow CAD through MQTT (Hildebrand Glow UPDATE! Local MQTT and Home Assistant « Speak to the Geek)?