Netz NOE #12
Comments
|
Mit genau diesem Programm: Nein. Habe ihn an einigen Stellen modifizieren müssen, aber im Prinzip funktioniert er für den Kaifa MA309 von NetzNÖ. Die Payload ist 228 und Index vom IV ist 22, das stimmt. Meine gesamte Payload ist 243. Die Pause zwischen den Paketen liegt bei mir auch so in dem Bereich, sollte aber kein Problem sein, da ja eh gewartet wird, bis das 2. Paket ankommt (bis timeout). Die Doku von EVN wirst du vielleicht schon kennen: 218_9_SmartMeter_Kundenschnittstelle_lektoriert MfG |
|
Danke für die Info. Die EVN Doku kenne ich schon und so kann ich die Daten auch Parsen. Scheinbar funktioniert der Code auch nicht für die entschlüsselte APDU zumindest bei mir gibt es Fehler. @mitsubishievo99 dein Code würde mich natürlich trotzdem interessieren. Ich werde aber wahrscheinlich mal das AmsToMqttBridge Projekt versuchen, das dürfte alles können was ich brauche. |
|
Meine modifizierte Version ist jetzt gepublished. Einheitlichkeit und Österreich? HAHA Vielleicht bringt dir mein Code was und nochmal Danke an @DomiStyle. |
|
Besten dank. Bei mir konnte ich mittlerweile auch die Energiedaten parsen, aber jetzt weiß ich auch wie man den Zeitstempel bekommt. |
|
Hab den Sagemcom T210-D von Netz-NOE Ich verstehe nicht ganz warum mein MBUS-Start mit 68:01:01:68 daher kommt payload kommt wie zu erwarten wie beim KAIFA mit 243 (235+8) |
|
Ich hab an einem ruhigem Wochenende eine angepasste Version auf einem EVN Kaifa zum laufen gebracht. Ziel wärs dass auf Dauer zu mergen, leider fehlt mir aktuell dazu die Zeit. Ich hab die Version allerdings mal hochgeladen, falls wer eine funktionierende Version braucht (hoffe das ist ok so wenn ich das hier so verlinke, soll ja auch dann gemerged werden). Getestet nur mit dem Kaifa MA309 EVN, ich nehm aber mal an dass die Sagecom die gleichen Daten zurückgeben. |
|
Decrypting habe ich noch geschafft. Das Decoding habe ich dann direkt von @firegore übernommen.
|
Das ist ein bei EVN / Netz-NOE bekanntes Problem: beim Sagemcom T210 wird das Längen-Feld nicht korrekt versorgt. |
@firegore ist da ein update geplant? seit dem esphome update 12.2022 gibts auch da fehler. |
danke für die Info, ich hab denselben Fix angewandt, sollte so funktionieren |
|
danke schon mal für den fix, bei mir scheitert das updaten auf die neueste esphome version leider immer noch - die fehler sind eine verständnisfrage hätte ich noch: gibt es allgemein gesprochen tiefergreifende änderungen und/oder abhängigkeiten bei der nö variante als die unterschiede im decrypting & decoding was payloadlength, offset etc. angeht? |
okay, grade gesehen, der Fehler tritt nur bei esp-idf auf, stell derweil mal auf arduino Framework um, esp-idf geht derweil bei meiner Version noch nicht.
Jaein, die Offsets sind anders, die EVN Meter geben aber auch (einen) zusätzlichen OBIS Code mit aus die in DomisCode fehlen (ich hab aber ehrlich gesagt vergessen welcher das war). Manchmal frage ich mich warum wir uns hier in Österreich um Standards bei den Zählern bemühen, bzw. diese als "Standardisiert" bezeichnet werden, wenn sowieso jedes Bundesland sein eigenes Süppchen kocht, obwohl die Hardware ja sogar gleich ist.. Die unterstützten OBIS Codes bzw. die offizielle EVN Doku mit mehr Infos gibts hier: https://www.netz-noe.at/Download-(1)/Smart-Meter/218_9_SmartMeter_Kundenschnittstelle_lektoriert_14.aspx |
wo und wie genau mach ich das? bin bis jetzt mit der noch laufenden version gut durchkommen, aber jetzt "erinnert" mich ja auch home assistent direkt an des update.. |
|
Habe es geschafft, die beiden SmartMeter Varianten der EVN mit der aktuellen Tasmota Version auszulesen. Der Langzeit-Test läuft nun... |
|
Ein großes DANKE an euch vorallem an Feuergore. Mit der Angepassten Firmware an den EVN Kaifa Smartmeter läufts perfekt. Hab den Code etwas geändert und es läuft. Für mein Energiemanagement verwende ich den vorhandenen Loxone Miniserver. Hab mal meine yaml angehängt. |
|
Hat vielleicht irgend jemand eine Idee was zu tun ist wenn man die Meldung bekommt:
Ich hab das Repo von @firegore genommen und ich hab auch einen Kaifa MA309M von der EVN. Die Keys hab ich mehrfach überprüft und auch im korrekten 0x.., 0x.. Format eingetragen. Leider bekomm ich trotzdem die oben genannte Meldung! |
|
Hmmn, ich hab die aktuelle 2024.03 Esphome Version bei mir getestet, der Code dürfte noch funktionieren. Dann sieht man zumindest mal ob das Datenformat passt, die EVN vllt. was an der Zählerfirmware geändert hat so dass die Daten jetzt anders sind oder ob sowieso nur Müll vom Zähler daherkommt. Beispiel vom Loglevel Verbose (du musst ebenfalls die tx_buffer_size auskommentieren/erhöhen) # Enable logging
logger:
level: VERBOSE
tx_buffer_size: 2048 # Only needed when logging large packets |
|
Was mich hier auch/eher stutzig macht ist der Buffer Overflow der zufällig bei dir Auftritt, das sollte eigentlich nicht passieren, die Pakete sollten 282~ Byte haben, der Buffer ist 1024 Byte groß. Das sieht aktuell danach aus als dass die Daten die beim ESP32 ankommen schon "Müll" sind und nichtmehr entschlüsselt werden können. Dazu wär ganz intressant:
Edit: Ansonsten auch gern mal deine verwendete .yaml als Gist/Pastebin posten (nicht vergessen vorher WLAN PW und DLMS Key zu ändern |
|
Hi Clemens @firegore. Exakt das gleiche Verhalten mit buffer overflow und daten die invalid sind habe ich auch. Hab mal bei der EVN nachgefragt ob die an der Schnittstelle was geändert haben jedoch ohne Erfolg. Hoffentlich kommt da bald jemand dahinter was hier nicht stimmt. |
|
@ColdFire1985 |
|
Ich hab’s mittlerweile zum laufen gebracht in dem ich auf meinem ESP den GPIO16 (RX2) verwendet hab. Seit dem läuft das bei mir eigentlich problemlos. Ich verwende aber einen normalen großen ESP! |
|
Hallo zusammen. Also mittlerweile habe ich auf ein ESP32 board (kein mini) getauscht mit gleichem Ergebnis. Ich hab sogar ein neues Projekt im ESP home angelegt und alles neu eingerichtet. Mit dem modbus board TSS721ADR gab es einen Hinweis der bei mir auch nicht funktioniert hat (#7 (comment)) ausgelötet kein Erfolg.
|
|
Wie hast du denn die Modbus Adapter mit dem ESP32 verbunden? (Welche Pins und vorallem was genau) Wenn ich mich recht erinner muss nur RX/TX/GND (theoretisch sogar nur TX und GND) verbunden werden. |
|
Hi, Also den modbus adapter habe ich vom esp mit den 3v versorgt sowie ground. Pins für rx bzw tx habe ich lt board beschreibung (1/3 bzw 16/17) verkabelt. Anbei noch einen DUMP:
|
|
Ich hab dir meine derzeit verwendete Config hochgeladen in die Repo. mein ESP32 ist ein Olimex ESP32-POE-ISO und ist per Ethernet angeschlossen, wird aber per USB per Strom versorgt. Ich hab auch definitiv nochmal nachgesehen und mein Mikroe Board hat nur RX/TX/GND verbunden, kein 3.3V. Deine Daten sind zwar konsistent haben aber den falschen Header am Anfang. M-Bus Pakete müssen immer mit 68 FA FA 68 anfangen. |
|
Danke für die Config. Ich werde mein Glück weiter versuchen. Hab natürlich am am P1 angeschlossen also unter dem gummi ding. Nochmals danke für deine Bemühungen. Wenn ich es diese Woche nicht hin bekomme dann lass ich es bleiben. Update: 240416. Ich bekomme korrekte daten! |
|
Für Interessierte: arbeite gerade an einer nativen esphome Integration: SimonFischer04/esphome#1 |
|
Nur als Anmerkung: Modbus und M-Bus sind "zwei paar Schuhe". Hier wird ein M-Bus Adapter benötigt und keine Modbus Schnittstelle. |
|
Hallo! Zwei Fragen an die Protokollprofis hier: |
|
@gitHelmut Bist du dir sicher, dass das doppelte FF (68 FA FA 68 53 FF FF 01 67...) vom Kaifa gesendet wird? Der Schlüssel ist davon unabhängig. |
|
@Noschvie Danke für die Anregung. Habs nun mit dem Oszi geprüft, sah nicht nach doppeltem FF FF aus. Habe dann meinen UART-Code von ein auf zwei Stop-Bits geändert, und siehe da, jetzt kommt FF 01 und die entschlüsselten Daten enthalten sinnvolle Werte. Freude |
|
Kennst du dies: https://github.com/Gurux Warum muss es ein Pico sein? |
Ich habe leider bei einem Netz NÖ Kaifa Zähler ein Problem.
Scheint das Timing hier etwas langsamer zu sein, die Pause zwischen erstem und zweitem Datensatz sind ca. 160ms:
Scheint auch das Datenformat etwas anders zu sein. Meine zwei Nachrichten sehen so aus:
Damit ist zB die ersten Payload 228 Byte lange und nicht 227 wie bei dir. Und der zweite Teil vom IV liegt bei Index 22
Mich würde vorallem interessieren, ob das schon wer erfolgreich mit diesem Code laufen hatte?
Gibt es eigentlich irgendwo eine frei verfügbare Spec von MBus und DLMS oder hat da sowieso wieder jeder sein eigenes Protokoll?
The text was updated successfully, but these errors were encountered: