Open homecineplexx opened 2 years ago
Dein Paket is zu kurz, schau dir mal die anderen Issues dazu an:
https://github.com/DomiStyle/esphome-dlms-meter/issues/2 https://github.com/DomiStyle/esphome-dlms-meter/issues/3
danke, bin ich schon dabei ;-)
ich verwende das board hier: https://www.azde.ly/products/esp32-developmentboard
ist da noch was umzustellen in der config?
ich hab alles mögliche versucht ausser das hier: https://github.com/DomiStyle/esphome-dlms-meter/issues/2#issuecomment-932205841
da weiß ich aber nicht so genau wie ich das machen soll/muss
Wie ist dein derzeitiger Aufbau? Welchen MBUS converter verwendest du?
Das mit den Widerständen ist nur ein Spannungsteiler damit ich keinen anderen Converter brauche.
Hilft dir dieses Foto? Ich dachte mir mit dem Spannungsteiler bekomme ich auch die kompletten Daten, denn meine sind scheinbar ebenfalls zu klein.
Hilft dir dieses Foto? Ich dachte mir mit dem Spannungsteiler bekomme ich auch die kompletten Daten, denn meine sind scheinbar ebenfalls zu klein.
Sorry für die späte Antwort, ist untergegangen. Lege mal den Tx auf GPIO36, Rx kannst du eigentlich weglassen.
Müsste auf deinem NodeMCU der SP Pin sein
ich hab den TX auf GPIO36 gehabt und RX auf GPIO4 so wie eigentlich in dem Projekt beschrieben, aber das macht keinen Unterschied
RX sollte fix auf 3.3V oder ganz offen, ansonsten wird der MBUS mit 15mA belastet, dass Kaifa kann laut Tinetz spec nur 6mA. Wenn UART richtig konfiguriert ist sollte dass aber sowieso auf 3.3V sein, da UART immer High ist wenn nichts gesendet wird.
Hat das Entfernen der 3.3V Verbindung zum Konverter einen Einfluss? Kann es mir zwar auch nicht recht erklären warum das geholfen hat. Siehe hier: https://github.com/DomiStyle/esphome-dlms-meter/issues/2#issuecomment-933011936
das mit dem weglassen von RX hat leider nichts gebracht!
Hello, ich bekomme mit dem MIKROE M-Bus Slave Click und SAGEMCOM T210-D ebenfalls keine sauberen Daten. Egal ob auf RaspberryPI oder PC. Die Records sind auch nicht immer gleich lang... Hat jemand für dieses Problem eine Lösung gefunden?
6801016853ff000167db0853414759c5fffffd85f9bf8ffc16fd3fea77e02d6edaf93e1eaac11526188051a14acd4e39d03f9d29b9d8419d3a0dea339f585faa164803ad641e82768b20705d746b3c97f92f8d8af8f5c889a94c44c09ca83cd7362935ca1c21985c9b058c8b75c231f44e2ac92ea3006a9fa7a17d960bf41c9e6ef319d71e4740d0f6aaf591239ec190e48cbf879cd250d21d8018c230085329fce75538029e689a5cb98e8ebea30c296a59d92d78506a11e81af5790d70a154a73dd90009e2ab57e8ff1e40ebf09d2c74ec1bb0f142d704bc9bac607cd4e704fb95ad64ea5d5de44f3862b33dbaa73b740f5e6b4c5a5ee516680d0d6853ff1101672e0dc5b8771040044e16
Thx Reini
Hallo Reini, Hast du das Parity Bit auf EVEN gesetzt? Mit None sahen meine Pakete auch so aus mit 68101068 als Start des 1.Frames und 680d0d68 als 2. Frame. der M-Bus Slave gibt das nämlich mit 24008E1 aus.
Hallo Mitsu, ich habe schon alles probiert - alle möglichen UART settings, Raspi, PC, Seriell direkt, via USB, ... Werde die Woche checken ob's bei einem KAIFA Smartmeter das gleiche Problem gibt wie beim SAGEMCOM... Besten Dank Reini
Schau dir mal das Projekt an https://github.com/schopenhauer/sage
Deine Daten schauen eigentlich nicht so schlecht aus, zumindest hast du den SAG
Klartext und das Startbyte 0xDB
und Stopbyte 0x16
.
Bin leider nicht wirklich versiert in der DLMS Thematik, aber hier habe ich hilfreiche Informationen bekommen:
Hallo, danke für die Links, die habe ich schon alle durch :-( Im Anhang ist das Logfile - nach 16 Bytes sind die Daten korrupt.
Ich werde schauen dass ich einen anderen MBUS-converter bekomme. Beste Grüße Reini SAGEMCOM-Output.txt i
Hallo zusammen,
die Lösung für das Problem mit den korrupten Daten über das MIKROE M-Bus Slave Click (MIKROE-4137) Modul war das entfernen von einem pull-up Wiederstand. Nach dem auslöten funktionieren die Module beim SAGEMCOM und KAIFA Smartmeter..
Beste Grüße
Reini
.
@ReiniNOE : hast du eine techn. Erklärung, warum das Auslöten des pull-up Widerstandes die Verbesserung brachte ? Wie bist du auf diese Lösung gekommen ? Habe auch dieses MIKROE M-Bus Slave Click Modul, kann es erst kommende Woche testen...
Hello,
für eine technische Erklärung bin ich leider nicht der Spezialist, der pull-up dürfte für'n UART störend sein.
Die Info kam von einem Elektroniker. Das verwirrende war dass die ersten ca 32 Bytes OK waren und dann Schrott kam...
Du wirst sehr schnell sehen ob die Daten passen.
Gruß
Hallo hast du vielleicht eine Ahnung, was ich umstellen könnte, damit es funktioniert?
[22:20:16][D][espdm:043]: Handling packet [22:20:16][V][espdm:457]: 68 FA FA 68 53 FF 00 01 67 DB 08 4B 46 4D 65 50 9A 17 77 81 F8 20 00 07 89 29 2F EF 02 13 A1 37 AD 6F 10 15 DD 92 FE 0B 9B 64 4B 61 2E 76 25 D1 1D 6F 67 54 E0 BF A6 E4 B3 66 08 8D 22 91 8B 2C 51 0C 2F 5D DA 8C 91 C2 46 D5 70 8E BC 1F 12 FB D4 F3 6C BF D5 49 1D 0A DB AA 14 F6 C6 32 DF C5 A1 43 6B B9 42 0F 20 01 B2 6A 3C 56 A9 AA 8E 23 53 A4 1D 6E 83 4D FE B4 AB 8F E9 40 B8 14 E9 90 4B E2 38 6C 18 DA 66 D9 16 87 A2 73 5B FD E4 74 80 24 6B 4E 78 50 7D 0A 13 D2 8E 64 30 77 C2 26 13 D0 0A 92 A2 96 B4 88 54 8D AD 19 A4 0D C8 4A 01 41 35 61 C6 7F D0 72 24 B2 D9 80 82 48 E5 AF E9 87 F9 04 4C C0 DB 97 97 B8 D6 9C 54 AB 36 A7 C6 E6 E6 E7 6D 09 1F 6E 21 90 E8 09 E1 6C 88 31 1C F9 1A 5A 1B F4 F8 D6 7B D5 AD 13 32 5E 48 1F 56 A0 52 FA 4B 76 39 26 BC 44 27 D9 3F E7 78 16 [22:20:16][E][espdm:054]: Payload length is too big for received data