DEBUG:smartmeter:No clock object found at 0.0.1.0.0.255. Using system time.

[kafisatz]

smartmeter.log

Hi do you have any idea, why the script is unable to parse the datetime? (see logfile above)

Nov 22 16:26:02 pi4 smartmeter-datacollector[423]: DEBUG:smartmeter:HDLC Buffer: 7E A0 84 CE FF 03 13 12 8B E6 E7 00 E0 40 00 01 00 00 70 0F 00 03 B5 33 0C 07 E6 0B 16 02 10 25 1E FF 80 00 00 02 0B 01 0B 02 04 12 00 28 09 06 00 08 19 09 00 FF 0F 02 12 ......

this is then parsed as <DateTime Value="07E60B16020F2005FF800000" />

which seems to be <!--2022-11-22 15:32:05-->

I am personally not quite sure about the 02 before 0F. Is "02" a marker (as in now comes the time?)

Also do you know why the datetime in the meter is about 8 minutes ahead. I am in Switzerland, thus the local time on the raspberry is UTC+1 (16:26 versus 15:32 on the Smartmeter)

[raymar9]

Hi kafisatz

I inserted one of your data samples from the log into a new unit test and run the software to reproduce the readout. Your meter sends an object-push-list in the beginning of every message which describes what data values are transmitted afterwards. This is all as expected. However, I can not find a entry for the timestamp value (OBIS code 0.0.1.0.0.255) in this list. Our software is only able to extract data values if they are declared in this object list. The timestamp in your example is somehow transmitted before the push-list and unfortunately I haven't seen this kind of message structure in other meters I encountered so far.

Could you give me more information about the smart meter type / model? Is it really a Landis+Gyr E450? What is your electricity provider?

I'm not sure how the time synchronization of the smart meters works here in Switzerland and whether the net frequency is used for that.

[kafisatz]

It is Energie Uster and yes it is an E450 See photo

[kafisatz]

For reference here is a description of the date format https://drive.google.com/file/d/1j4KHwcZreYAixuHT3fVgT5G0vut1BFSZ/view?usp=drivesdk

See last page. I think this is consistent with the message I copied above.

[raymar9]

About the timestamp: I found, while debugging with your example data, the timestamp in the parsed message. I'm going to integrate this into the application as a fallback time if no timestamp is found in the pushed object list like it works with other meters. So, the priority order is: 1) push-object timestamp, 2) message time, 3) system time For now, you have to cope with the system time of the RPi. The forwarded timestamp to MQTT should be UTC-time, don't confuse it with the logging timestamp date format (those are in local time).

Thanks for the document and your contribution!

Concerning the time synchronization: I suspect the meter got initially an incorrect time. And its clock is probably now only controlled by the net frequency (50Hz). But I'm not sure about this. You need to ask your electricity provider, Energie Uster. It's in their interest that the clocks of their meters are accurate.

[kafisatz]

Thanks. About the time offset of my meter. I may ask the provider. Given that the meter is pushing the live data, we actually know the "true timestamp", namely now(). Thus in my case the fallback using system time is actually my preference :)

[raymar9]

Hint: the new release v1.1.0 allows adding an optional boolean parameter systemtime in the configuration .ini file to override the message time by the system time of the Raspberry Pi (or other device you use for the datacollector). See https://github.com/scs/smartmeter-datacollector/blob/fd5d4a51220869b99b683bd14a97493ce03229b6/smartmeter_datacollector/factory.py#L35