Siconia T210-D Smart Meter Stromzähler auslesen

[Saghon]

hallo
wenn ich nun ein laie bin auf dem gebiet - wie komme ich gegen einwurf kleiner münzen bzw. scheinen zu der lösung?
am einfachsten wäre natürlich
PLUG ++ persönlichen schlüssel eingeben ++ PLAY

ich hab ein bisschen Ahnung von KNX und Loxone aber bei TSS721 und MQTT Broker ist es bei mir vorbei
und ich befürchte , dass auch andere daran scheitern, wenn man sich nicht mühsam in die ganze materie einliest.

wer könnte die komplettlösung (mit KNX oder ModbusTCP anbindung an Loxone) für einen MA309 von EVN anbieten
verkabelung und konfiguration von schlüssel und IP-Adressen würde ich mit einer kleinen anleitung schon schaffen

danke
peter

Hallo Peter,

darf ich fragen unter welchen Rahmenbedingungen deine Integration läuft?

Die Variante

PLUG ++ persönlichen schlüssel eingeben ++ PLAY

könnte funktionieren sofern du aus Loxone raus einen REST Aufruf direkt an das Modul absetzen kannst bei dem du die letzten Messwerte als JSon Struktur zurückbekommst.

Also so ein Aufruf:

http://192.168.1.124/getLastData?user=308398A1EA0D&password=10611213

würde so etwas zurückgeben:

Also letztendlich ein REST Aufruf so wie du vermutlich auch Wetterabfragen machst nur halt direkt an das Modul in deinem privaten Netzwerk.

[pessletz]

darf ich fragen unter welchen Rahmenbedingungen deine Integration läuft?

Rahmenbedingungen ?
mein EFH, Loxone Miniserver Gen1., Loxone und KNX Komponenten

ob dieser REST ? Aufruf funktioniert müsste man einen Loxonauten fragen
ich denke schon , da es einige http Requests gibt die verschiedene werte abfragen bei den Netzwerkgeräten

[L.X.]

Hi zusammen, wollte euch nur wissen lassen dass die EVN im März 2022 eine neue Version der Anleitung publiziert hat, welche auch ziemlich genau auf die Interpretation der Werte, der Entschlüsselung der APDU usw. eingeht. Ich dachte das interessiert vielleicht den einen oder anderen

Entnommen hab ich das Dokument von hier: Information zu Smart Meter - intelligente Stromzähler (evn.at)

[Saghon]

Hallo,

die von EVN verbauten Smartmeter scheinen nicht mehr alle die gleiche Firmwareversion zu haben.
Es fallen nun immer mehr Smartmeter auf, bei denen das Protokoll nicht mehr dem Standard folgt bzw. schlichtweg korrupte Daten liefert..

Zu erkennen ist das am L-Field welches die Länge des Frames beschreibt.
Korrekterweise ist es wie auch in deinem Dokument ersichtlich für den ersten Frame 250 Zeichen lang (0xFA)

Bei einem fehlerhaften Smartmeter steht hier jedoch eine eins drinnen (0x01) was natürlich nicht stimmt.
Wenn man sich diese Frames ansieht, merkt man das die tatsächliche Länge 257 Bytes beträgt.

Wandelt man nun die 257 Bytes in Hex um, ergibt das 0x101.
Jetzt lässt sich leicht vermuten, das man sich bei EVN anscheinend gedacht hat man macht den Frame etwas größer, hat dabei nicht bedacht das ein Frame maximal 250 Zeichen haben kann und man mit 257 Zeichen einen Speicherüberlauf bei der Berechnung der Anzahl der Bytes hat. (aus 0x101 wird nur mehr 0x01)

Hier ein Beispiel eines korrekten Streams mit einer Framegröße von 250 Bytes:
68FAFA6853FF000167DB084B464D65509CF14B81F8200003B26009E6D3 30D66BA9625F7F3A3FC578FE8D15AFA1D0341A27F08F1CDBD5 2E92BBE35C570E4FAD6F14059B4926DD3C5E026BB1B106D00C 16F94D1E9C8BE7CCA238D1E5E1A616B44D969DA60CBD7B577F B05ACA5DEA6A4E317DBCCD6248FC9B15F2705A88E2D35829C2 E0ECFABA870167D0BC935A1C7326A2B2F497E14CE3CFE3B605 FF50BAB8A81733E09984C28AF8FB5E11284A7AB5CC116668D2 5C92588A96FF24BBEC02C6B36AE32B81352812E1EB12796E94 0036D01AEBEF44679FB109961233403D65071436B1872A271A D31665D230B4A7974F966709AA80CA62775545E7909739BDD959166814146853FF1101676B8B5807ACD96FA53F1557927E2E 04A616

Hier das Beispiel einen korrupten Streams mit einer Framegröße von 257 Bytes:
6801016853FF000167DB085341475905EAEC7C81F820000061B6291BAF 5FC982A29505C316AC1E0E6BEE927DA107E4B36E1DF764B6E6 3F382D565DEB7C2D0D9BF2CF83D592640CC60363AA21A26B7E 2D75B583DE5871430527BA3FB30366A86E99D1258A8992B65E 85C62D5BC76D4DE74AA8D1E8B6F94BB86BCCBA3088E7F218C6 6DDB04D47A84E3D601918C980847EDE0F4B3DE9910D220C1FB E82001FC5BCFC9121105CD0C9F32EE7A51C52A9EF3EC59385B 49F7B49A49092DF344D1D65EAAA096515948098AD73E5CFE39 6EF4444266BDD6769E5EC1C468F565BEC988979C4ED4FF5351 A50FFCADBFDE1C5FF709828CE28CD33C89F04944052B9573DD 5CCC14E82662619516680D0D6853FF110167F4335CBC01FEA0903916

Das Problem ist bei EVN nicht mehr ganz unbekannt, wenn bei euch also solch eine Smartmeter-Firmware am Laufen sein sollte, solltet Ihr bei EVN eure Zählernummer bekannt geben.

[Saghon]

...noch eine Ergänzung dazu...



die Daten an sich sind bei diesen Smartmetern nicht korrupt, das heißt, eine Entschlüsselung ist an sich möglich wenn man die zwei Frames mit der tatsächlichen Länge verwendet.

Ein Problem ergibt sich erst bei Konsistenzprüfungen welche durch diesen Fehler nicht zur Gänze gemacht werden können und im schlimmsten Fall wenn wirklich korrupten Daten gesendet werden, nicht immer erkannt werden würden.

[acs999]

Hallo,

Worin genau ergeben sich die Probleme bei der Konsistenzprüfung? Wenn man die Checksumme über den Frame berechnet stimmt diese aber in dem Beispiel. Die Summation aller Zahlen ergeben hier die 95Hex. Das ist auch nach dem Frame eingetragen. Die Checksumme beim zweiten Frame stimmt ebenfalls mit 39Hex.
.......5CCC14E8266261(95)16680D0D6853FF110167F4335 CBC01FEA090(39)16

[Saghon]

Hallo acs999,

du hast schon Recht, die Checksummenberechnung funktioniert auch mit den 257 Bytes korrekt.
Sofern EVN die Implementierung nicht ändert und auch in Zukunft keine zusätzlichen Parameter schickt, kann man natürlich statisch die Position des Checksummen-Bytes aus dem Strom herauspicken und gegen die 257 Bytes von davor berechnen.
Auch kann man im Datenstrom nach den 1668 suchen und annehmen das davor das Checkzeichen ist und dieses dann verwenden.
Diese Art der Implementierung ist aber nur ein Workaround und kann bei einer potentiellen Änderung des Datenstroms dann zu Problemen führen (wenn EVN eventuell mehr Daten liefern würde)

[preslmayer]

Hallo

Ich habe bereits die Kundenschnittstelle am MBus bei meinem Smartmeter Sagemcom T210-D am laufen.

Ich bekomme auch am L-Field 0x01

Data Stream:
6801016853FF000167DB085341475805E891DC81F82000003844C389B6FD26475EF8AD46185C41B2768CE9E6A3AF4519AD2330 F29CCCBE01E803A1656B74578A65CE95D86844BDA0EDDEDE92 183C9E2CB3E0CC4F0A2FECA8BC490AB7B5FBAA7DF76E56C9B9 2509EA9E4FC7FEA92AA2BE27974D45B534B27627B854EEDF9A 8EA666DFC4341A033F4566F76DDC63815125B999F2D6F32052 633744841B3FE299EA3676BECCD5F361F6E82CA62449694832 0D884066760C7313494B754B1E85E0AEEECF6BC3B04417528F 7C0F5916B97DF37FA60630250375770B249F2F7EB718F011E5 2EB21625674BF94D743E889876D7951FD9D081DDE68CDE37BE B50B985C226EBCFD1AEC9A516680D0D6853FF1101676BC5423 20BB04151BC16

Gliederung: M-Bus Start System Title Frame Counter Data M-Bus Checksum M-Bus Stop

Weiß jemand, was genau die Daten vor dem System Titel (53FF000167DB08) und vor dem Frame Counter (81F820) im Detail bedeuten?

[Saghon]

Hallo

Ich habe bereits die Kundenschnittstelle am MBus bei meinem Smartmeter Sagemcom T210-D am laufen.

Ich bekomme auch am L-Field 0x01

Data Stream:
6801016853FF000167DB085341475805E891DC81F82000003844C389B6FD26475EF8AD46185C41B2768CE9E6A3AF4519AD2330 F29CCCBE01E803A1656B74578A65CE95D86844BDA0EDDEDE92 183C9E2CB3E0CC4F0A2FECA8BC490AB7B5FBAA7DF76E56C9B9 2509EA9E4FC7FEA92AA2BE27974D45B534B27627B854EEDF9A 8EA666DFC4341A033F4566F76DDC63815125B999F2D6F32052 633744841B3FE299EA3676BECCD5F361F6E82CA62449694832 0D884066760C7313494B754B1E85E0AEEECF6BC3B04417528F 7C0F5916B97DF37FA60630250375770B249F2F7EB718F011E5 2EB21625674BF94D743E889876D7951FD9D081DDE68CDE37BE B50B985C226EBCFD1AEC9A516680D0D6853FF1101676BC5423 20BB04151BC16

Gliederung: M-Bus Start System Title Frame Counter Data M-Bus Checksum M-Bus Stop

Weiß jemand, was genau die Daten vor dem System Titel (53FF000167DB08) und vor dem Frame Counter (81F820) im Detail bedeuten?

Hallo,

in deinem Fall wären das für..
53 = C Field, 0x53 sagt hier aus das es sich um einen Long Frame handelt
FF = ist die Adresse, im Fall von 0xFF ist kein spezieller Slave angesprochen (Multicast)
00 = CI für Control Information Field. Hätte die Nachricht nur einen Frame, würde hier 0x10 stehen. In deinem Fall hat die Nachricht aber 2 Frames was bedeutet das für den ersten Frame hier eine 0x00 steht
01 = Logische Deviec ID
67 = Client ID
DB = das genutzte Cyphering Service. DB steht für Global Glo Ciphering
08 = Trennzeichen

Bei dir handelt es sich daher übrigens um eine Nachricht die 2 Frames beinhaltet bei der der erste Frame nur bis hier geht ...EBCFD1AEC9.
danach folgt die erste Checksumme und ein neuer Frame startet wieder weiter hinten.

[thomasmitschke]

Hallo - wie wird denn die Checksumme berechnet? - Hier im Beispiel steht doch das BC die Checksumme ist?!?

[Noschvie]

Kann es sein, dass sich das Framing unterscheidet?
EVN / Kaifa is using M-Bus framing and Sagemcom HDLC. Kann das richtig sein ?

Meine Anfrage bezüglich Sagemcom T210-D wurde von der EVN mit "das hat schon seine Richtigkeit" beantwortet...

[Saghon]

Hallo,
an sich dürfte sich der Inhalt bzw. die Menge der gelieferten Daten schon unterscheiden solange das Protokoll eingehalten wird.
In dem Fall ist aber der erste Frame 257 Zeichen lang, was laut Spezifikation nicht erlaubt ist.
Das hat auch einen Grund da die Länge des Frames im L-Field hinterlegt ist welches nur ein Byte hat. Bei einer Framelänge von 257 ist aber ein Byte das nur einen Wert von max.255 haben kann, nicht mehr groß genug wodurch es wohl zu einem Speicherüberlauf kommt.
Die Information die ich von EVN mittlerweile bekommen habe ist das sie das Problem nachvollziehen können, dieses jetzt aber an die Spezialisten des Smartmeterherstellers zur Klärung weitergegeben haben.

[Celphor]

Hallo,
ich hab mich jetzt auch mal ans Auslesen meines EVN MA309M gemacht. Mit einem MBus-auf-TTL-Wandler und einem ESP32 dahinter. Leider erhalte ich nicht annährend die Struktur aus der EVN-Anleitung, und die Telegramme sind auch nicht 282 Bytes lang, sondern unterschiedlich zwischen 254 und 265 Byte. Beispiel:

C9D0D0492DFFFD6292EFD273CA355FC70321BFC0F3DDF38497 904CAB4A762E694EB7A546446B0F98B22C22A3E1D2500B95D2 5259EF31F38EB9B2D4F625282142F797264701A00A96AEF099 75EADE90350DAB4B49CA2D5DD112BD24DD614231AF65861535 AE9A387DDDABD21BCDE9FA67976832A4883A8CD25D097B6A37 274F28FEBEA62D618A6B161C381690ABF9F536FD5BDAB5A29C BEEC7EB25315510A67D606E57E8504B2C69AF2EF22069DF5E8 D609810ABF5B80CF96E668D0112A51F513E3D6F22B5BC1C5C1 4D25811B0136E2B52C0B5BC6CD6594D6A499A90A4F439595BA 352D31D5916933DBD1434C839D3AC9BDBD492DDDFD62F21FE6 241DD74F53ECBC686B13B4344D00

Die ersten ~20 Bytes sind immer gleich. Baudrate ist 2400, 8N1

Muss da vielleicht noch irgendwas freigeschaltet werden? Den AES-Key hab ich bekommen, aber der hilft mir hier natürlich nicht weiter. Das Webinterface ist aber nicht aktiv und in der Portalseite steht auch dass der Zähler nicht kommunikativ ist

Ideen?

VG

[Saghon]

Hallo Celphor,

welchen MBus-auf-TTL Wandler hast du denn...
den M-Bus Slave Click von MICROE?

Gruss
Saghon

[Celphor]

Diesen hier: TTL zu MBUS, Serial Port zu MBUS Slave Modul, Anstelle von TSS721A, Signal Isolation!|Instrument Parts & Accessories| - AliExpress

Das ist im Prinzip das selbe Frontend (bis zu den Optokopplern) wie bei den USB-Adaptern

[Saghon]

Bei einem M-Bus Save Click hätte ich auf den Pull-Up Widerstand getippt der dort Probleme macht und einfach entfernt werden müsste.
Dieser Adapter von AliExpress scheint eine ähnliche Schaltung zu haben.
Mangels besseren Wissens würde ich mal versuchsweise diesen Widerstand auslöten und schaun was passiert

[Celphor]

Da magst Du tatsächlich Recht haben. Ich hab mir den Ausgang mit einen billigen Oszi angesehen gehabt und mich über den Pegel gewundert. Das werde ich wohl nochmal vertiefen müssen. Zur Not brücke ich den Widerstand mal. Danke für den Input. Melde mich heute Abend mit den Erkenntnissen :-)

Edit: Natürlich nicht brücken, entfernen ^^

[Celphor]

Das mit dem Pullup war nicht das Problem. Der Ausgang liegt normal auf High und wird durch den Optokoppler bei Empfang auf Masse gezogen. Ohne den Widerstand wird aber auch der Ausgang vom Optokoppler nicht mit Strom versorgt => Es kommt gar kein Signal.

Das Problem war ein anderes: Offensichtlich hat die UART-Komponente von ESPHome ein Problem mit dem Invertieren der Pins. Nachdem ich auch das (unbenutzte) Tx Pin auch umgedreht habe, funktioniert es plötzlich :-)

16:06:34][D][espdm:044]: Handling packet of size 282
[16:06:34][D][espdm:066]: 68FAFA6853FF000167DB084B464D6550
[16:06:34][D][espdm:066]: 9CFE7A81F8200011B2F9826CF023B326
[16:06:34][D][espdm:066]: 669BF200A3E57BD6CA52AB3A5E049713
[16:06:34][D][espdm:066]: 6FF6FCF1F333B6A8DFD1EEC6F43A6DEC
[16:06:34][D][espdm:066]: 180045D07A4084C9EA1CD894DFFD6FFB
[16:06:34][D][espdm:066]: 5810C2E330680680D1D9D325AF8C6B7A
[16:06:34][D][espdm:066]: E2B7CB0B3F97267658117C64087F22D5
[16:06:34][D][espdm:066]: B0F85E5AC16049CB23269F2CBDCD8EA4
[16:06:34][D][espdm:066]: 922306B63C3F8C4BFCE2E4AAA094C21B
[16:06:34][D][espdm:066]: 63CBC19B17079E83D0D039D228862996
[16:06:34][D][espdm:066]: 855B865AC01280B3F51C2149BA2ED962
[16:06:34][D][espdm:066]: 34A4D092EBA36767C040BEB4810B3B80
[16:06:34][D][espdm:066]: 4CEBA4709A6E292D84CC95BAEEAAB125
[16:06:34][D][espdm:066]: 8B397480C6846A9B32FB9B8A3A8EF889
[16:06:34][D][espdm:066]: 17C95B149E0480C60DC4EFDD6C9874AD
[16:06:34][D][espdm:066]: 013C0494F6DDF79E8C8926BDA501F216
[16:06:34][D][espdm:066]: 6814146853FF1101673FD060DB4ED201
[16:06:34][D][espdm:066]: 3370FBFA6A519B91B516

Das sieht doch schon mal besser aus

Danke trotzdem, die Polarität war ja letztlich doch die Ursache

LG

[Saghon]

Hallo,

die von EVN verbauten Smartmeter scheinen nicht mehr alle die gleiche Firmwareversion zu haben.
Es fallen nun immer mehr Smartmeter auf, bei denen das Protokoll nicht mehr dem Standard folgt bzw. schlichtweg korrupte Daten liefert..

Zu erkennen ist das am L-Field welches die Länge des Frames beschreibt.
Korrekterweise ist es wie auch in deinem Dokument ersichtlich für den ersten Frame 250 Zeichen lang (0xFA)

Bei einem fehlerhaften Smartmeter steht hier jedoch eine eins drinnen (0x01) was natürlich nicht stimmt.
Wenn man sich diese Frames ansieht, merkt man das die tatsächliche Länge 257 Bytes beträgt.

Wandelt man nun die 257 Bytes in Hex um, ergibt das 0x101.
Jetzt lässt sich leicht vermuten, das man sich bei EVN anscheinend gedacht hat man macht den Frame etwas größer, hat dabei nicht bedacht das ein Frame maximal 250 Zeichen haben kann und man mit 257 Zeichen einen Speicherüberlauf bei der Berechnung der Anzahl der Bytes hat. (aus 0x101 wird nur mehr 0x01)

Hier ein Beispiel eines korrekten Streams mit einer Framegröße von 250 Bytes:
68FAFA6853FF000167DB084B464D65509CF14B81F8200003B26009E6D3 30D66BA9625F7F3A3FC578FE8D15AFA1D0341A27F08F1CDBD5 2E92BBE35C570E4FAD6F14059B4926DD3C5E026BB1B106D00C 16F94D1E9C8BE7CCA238D1E5E1A616B44D969DA60CBD7B577F B05ACA5DEA6A4E317DBCCD6248FC9B15F2705A88E2D35829C2 E0ECFABA870167D0BC935A1C7326A2B2F497E14CE3CFE3B605 FF50BAB8A81733E09984C28AF8FB5E11284A7AB5CC116668D2 5C92588A96FF24BBEC02C6B36AE32B81352812E1EB12796E94 0036D01AEBEF44679FB109961233403D65071436B1872A271A D31665D230B4A7974F966709AA80CA62775545E7909739BDD959166814146853FF1101676B8B5807ACD96FA53F1557927E2E 04A616

Hier das Beispiel einen korrupten Streams mit einer Framegröße von 257 Bytes:
6801016853FF000167DB085341475905EAEC7C81F820000061B6291BAF 5FC982A29505C316AC1E0E6BEE927DA107E4B36E1DF764B6E6 3F382D565DEB7C2D0D9BF2CF83D592640CC60363AA21A26B7E 2D75B583DE5871430527BA3FB30366A86E99D1258A8992B65E 85C62D5BC76D4DE74AA8D1E8B6F94BB86BCCBA3088E7F218C6 6DDB04D47A84E3D601918C980847EDE0F4B3DE9910D220C1FB E82001FC5BCFC9121105CD0C9F32EE7A51C52A9EF3EC59385B 49F7B49A49092DF344D1D65EAAA096515948098AD73E5CFE39 6EF4444266BDD6769E5EC1C468F565BEC988979C4ED4FF5351 A50FFCADBFDE1C5FF709828CE28CD33C89F04944052B9573DD 5CCC14E82662619516680D0D6853FF110167F4335CBC01FEA0903916

Das Problem ist bei EVN nicht mehr ganz unbekannt, wenn bei euch also solch eine Smartmeter-Firmware am Laufen sein sollte, solltet Ihr bei EVN eure Zählernummer bekannt geben.

Hallo,

nochmals zum Problem beim L-Field von den betroffenen Smartmetern.
Mittlerweile wurde bestätigt das dieses falsch gesetzt ist und an der Lösung gearbeitet wird.
Der Inhalt ist wie schon angesprochen auch jetzt verwertbar, durch die falsche Angabe der Framelänge ist aber eine Verwendung dieser Information um zB.: eine vollständige Konsistenzprüfung zu machen, eingeschränkt.

[acs999]

Hallo Saghon,
Gibt es diesbezüglich schon eine Rückmeldung seitens EVN?

[Saghon]

Hallo,
bisher keinerlei Information mehr von EVN bez. diesem Problem.

[Celphor]

Bei den MA309M stimmt die Anleitung auch nicht mehr. Die Zählernummer wird am Schluss nicht mehr mitgeschickt, zumindest nicht in dem angegeben Format. Nachdem diese Information aber ohnehin wenig hilfreich ist, kann man das verschmerzen

[acs999]

Hallo,

Hat jemand mit diesem M-Bus Slave Adapter schon Erfahrungen gemacht? Er ist bei RS-Online zu beziehen und die Kosten sind mit ca. 24 Euro inkl. Versand nur doppelt so hoch wie für die Adapter aus China. Lagernd wäre er auch.

https://at.rs-online.com/web/p/entwicklungstools-kommunikation-und-drahtlos/2167484