Support for Austrian smart meters

[PieKiu]

Hi,

I've written a python script that reads one brand of austrian smart meters and sends them to a influxdb. Looking at the way you parse telegrams it seems very similar. Would it be possible to alter your parser in such a manner that the datalogger component could also read my smart meter? Just to clarify, this smart meter is in use in many homes in Austria, not just at my place ;-) This way we could relay the data to dsmr-reader and display it.

I can provide my script that uses a serial connection over USB close to your setup. Of course I could also provide as many telegrams as needed to test the code.

[dennissiemensma]

Thanks for asking. Additional support in the datalogger may only be possible if the protocol is similar to the DSMR protocol we use here.

However, even if they do differ and I would not be able to natively support it, you could still parse the telegram yourself and use the API of DSMR-reader to insert the telegram on per-field basis. It only requires about six or seven fields to work at all:

---

Also, it would be great if you could provide a telegram. Be sure to strip any personal/unique meter ID's from it, like this example does with the "xxxx....".

[PieKiu]

Hi Dennis!

Thank you for the super fast response. Here is a telegram and my serial settings!

initial_baudrate: 300
baudrate: 9600

Get Data from USB Reader serial_port defaults to /dev/ttyUSB0

ser = serial.Serial(serial_port, initial_baudrate, serial.SEVENBITS, serial.PARITY_EVEN)

We ask the meter to provide the actual values

print("Asking for meter info...")
ser.write(b"\x2F\x3F\x21\x0D\x0A")

To wich the meter gives us some kind of response:

response = ser.readline().decode("ascii", "ignore")
print("Meter returns: " + response)

Meter returns: /ISk5MT174-0001

Then we sleep half a second time.sleep(0.5)

Now let's set a baudrate of 9600 so we speed up things ;-)

ser.write(b"\x06\x30\x35\x30\x0D\x0A")
time.sleep(0.5)
ser.baudrate = baudrate

And then we can read our telegram line by line :smile:

telegram.txt

Actually I have no clue if the numbers I "X"-ed out mean anything usefull at all, but they are the only ones that seem to fall out of the pattern ;-)

I think the telegram is really very close to what you already parse. The only difference in procedure might be the changing of baudrate after the first "handshake". And from what I see there are only 2 usable values:

1.8.1(029428.5*kWh) - total consumption
2.8.1(043516.2*kWh) - total production

This is all the information the meter provides. Deltas as well as actual consumption have to be calculated. Precision is also quite low, because the meter updates in 0.1kWh steps.

Do you need anything else? If you want, I can provide my whole script to you in order for you to further understand what I do.

It would be really nice, if I could use DSMR "out of the box" for my smart meter as my solution is fine but involves a lot of different components that in a normal home environment tend to fail from time to time.

Thank you!

[dennissiemensma]

Thanks for sharing. I see what you mean, as it looks similar yet seems a whole different protocol.

Do you happen to have a link to any documentation regarding the telegram specs? For example, our Dutch version is described in detail here. I'm looking for a similar doc/guide.

I might already see how it works though. It looks like the telegram keeps track of the current meter value values and also tracks historic value of the first day of every month, for the past 14 months or so.

0.1.2*76(2103010000)
0.1.2*75(2102010000)
0.1.2*74(2101010000)
0.1.2*73(2012010000)
0.1.2*72(2011010000)
0.1.2*71(2010010000)
0.1.2*70(2009010000)
0.1.2*69(2008010000)
0.1.2*68(2007010000)
0.1.2*67(2006010000)
0.1.2*66(2005010000)
0.1.2*65(2004010000)
0.1.2*64(2003010000)
0.1.2*63(2002010000)
0.1.2*62(2001010000)

This translates to midnight at 1st of March, 1st of February, all the way back to 1st of January 2020. The 76, 75, 74, etc map to similar fields further below in the telegram, indicating their values at that time.

Can you verify that these fields update often?

1.8.1(029428.5*kWh) - total consumption
2.8.1(043516.2*kWh) - total production

Because the value on 1st of March seems 029401 kWh and the current value is 029428 kWh, resulting in a 27 kWh usage in the past 3 to 4 days, which seems likely.

[dennissiemensma]

So I do not think I can support it in the native datalogger, since it's way too different.

However, it should work using the API. For example: https://github.com/dsmrreader/dsmr-reader/blob/v4/dsmr_api/tests/v2/test_dsmrreading.py#L42-L50 If you can set the timestamp, electricity_delivered_1, electricity_delivered_2 to the value read, and the other fields to 0, it might work.

And I can surely help in making sure the serial checkum is checked, since there every telegram may have some of its values flipped during transmission (due to interference), resulting in weird values read and stored (if not checked). This assumes that the C.1.6(FDF5) value is the checksum of the telegram.

[PieKiu]

I will install an instance of DSMR in Docker and try to sent the values accordingly. Let me get back to you with my findings. Eventually I could provide my script for any other user willing to try it!

[dennissiemensma]

@PieKiu did you manage to get it running in Docker? And are you running into any other issues?

[PieKiu]

Hi!

Yes, I got it running and I send values from my python application through the API as you suggested.

I like DSMR very much. It seems very convenient for your situation.

Having said that, sadly it doesn't give me any benefit over what I already know and save in my influx DB:

• Power in watts would need to be calculated in retrospective because the meter itself does not provide any such up-to-date value.
• I miss returned electricity reports (what I produce sometimes outweighs what I consume). Here the daily delta would be important for me. Because like that I know how much I owe the power company or vice versa.
• Your graphs and settings are great, but without the needed data they just can't do what they're supposed to do ;-)
• And so forth and so on.

I understand now that my needs are very diferent from yours and I don't think it is worth the effort to adapt DSMR that much. It would make things overly complicated and the benefit would be for (what I think) only a handful of people the most.

Therefore I would like to thank you very much for your very constructive help. I think the way DSMR works right now is not really usable for people with a configuration like mine or with the same smart meter I have, for the matter. I will try to write my own application inspired by the awesome work you guys are doing.

Thank you again!

[dennissiemensma]

Thanks for the update! It's a bummer that the Austrian telegrams seem to a lack a lot of information compared to the Dutch ones.

I understand your situation now and with the current data available DSMR-reader would be overkill. Also, if I would redesign DSMR-reader again (project is 5+ years old), I would totally go for an InfluxDB or ElasticSearch (any timeseries DB) instead, so you're good anyway.

If the Austrian telegrams (ever) happen to contain more useful information in the future, feel free to keep in touch!