Replies: 3 comments 2 replies
-
One potential issue with that is that we have seen that meter timestamp is sometimes not reliable, for instance regarding Daylight Saving Time. And some meters do not send a timestamp at all. But we could potentially publish it "as is" so that the user can attempt to use it (empty string if no timestamp from the meter). @gskjold may want to weigh in here! |
Beta Was this translation helpful? Give feedback.
-
That would be perfect! The Tibber Pulse didn't seem that responsive anyway, mqtt data normally came in 4 seconds after the meter issued the time stamp whereas the Pow-K+ is consistently below 2 seconds (and I am pretty sure my hourly NTP synced MQTT machine doesn't drift in seconds but rather milliseconds...). So anything would be better than that Pulse device IMHO. As a side note: For that hourly "total" reading I even saw 9 seconds delay on the pulse... |
Beta Was this translation helpful? Give feedback.
-
Meter timestamp is included in JSON sent to MQTT in the "rtc" field, or on the topic meter/clock if you use raw mode. But not all meters report their own time. The "t" field in JSON is the package timestamp, this is in some cases populated by the meter, but if not we substitute NTP timestamp into this field. Edit, search for "rtc" and "t" here: https://github.com/UtilitechAS/amsreader-firmware/wiki/Message-formats#list-1 |
Beta Was this translation helpful? Give feedback.
-
I use the AMS reader as the source of truth for electrical metering. Using a MQTT subscriber I republish the readings to other services (instead of lots of devices) e.g. Tibber Pulse :-) My issue is that I would like to avoid guessing the meter's time reading and use the actual meter datetime instead. The request is hence to add an attribute to MQTT (both topics power and energy) so I can use actual meter datetime (from the OBIS field)
I am fine with decoding and reencoding the 12 byte string myself if not sending the actual datetime string
Beta Was this translation helpful? Give feedback.
All reactions