Willkommen im Loxone Community Forum. Um alle Funktionen nutzen und sehen zu können, registriere dich bitte zuerst. Dies gilt auch für das herunterladen von Dateien.
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.
Angehängte Dateien
Einen Kommentar schreiben:
Ein Gast antwortete
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 :-)
Danke trotzdem, die Polarität war ja letztlich doch die Ursache
LG
Einen Kommentar schreiben:
Ein Gast antwortete
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 :-)
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
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)
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
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:
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
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.
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.
Das github Projekt ist aktuell nicht mehr public und aktuell nur den Entwicklern zugängig.
Es gibt derzeit nur noch ein paar fertige Module auf willhaben.at die als Prototypen für einen reinen Smartmeter-Sensors entwickelt wurden und als Standalone-Gerät ohne zusätzliches Gateway eingesetzt werden können.
Das github-Projekt als alternative Sensor Plattform wird gerade neu strukturiert bzw. neu aufgesetzt.
Leider gibt es von SHRDZM nur den Source Code, zumindest zeitweise, aber kein How-to für's Compilieren usw...
Habe derzeit ein Python Lösung in Verwendung und möchte auf Basis von GuruxDLMS.c eine ESP32 Lösung implementieren.
Der von dir angegebene Link auf Github funktioniert nicht, bzw. ist das so nicht mehr vorhanden.
Der Code selbst ist unter "https://github.com/Noschvie/shrdzm/tree/master" zu finden, jedoch keine Anleitung zum kompilieren und flashen.
Danke, Andreas
Wir verarbeiten personenbezogene Daten über Nutzer unserer Website mithilfe von Cookies und anderen Technologien, um unsere Dienste bereitzustellen, Werbung zu personalisieren und Websiteaktivitäten zu analysieren. Wir können bestimmte Informationen über unsere Nutzer mit unseren Werbe- und Analysepartnern teilen. Weitere Einzelheiten finden Sie in unserer Datenschutzrichtlinie.
Wenn Sie unten auf "Einverstanden" klicken, stimmen Sie unserer Datenschutzrichtlinie und unseren Datenverarbeitungs- und Cookie-Praktiken wie dort beschrieben zu. Sie erkennen außerdem an, dass dieses Forum möglicherweise außerhalb Ihres Landes gehostet wird und Sie der Erhebung, Speicherung und Verarbeitung Ihrer Daten in dem Land, in dem dieses Forum gehostet wird, zustimmen.
Einen Kommentar schreiben: