|
|
||
Ich glaub, du mußt den SDM nach Konfigänderungen nochmal neu starten/stromlos machen, damit die Änderungen aktiv werden. |
||
|
||
versuch mal ob "-0" was bringt (First reference is 0 (PDU addressing) instead 1)
bist du sicher dass der Wert "float" ist? lass mal das "-1" weg (ich hatte schon den Fall dass die erste Abfrage ins Leere ging, ab der zweiten hats dann funktioniert) häng ein "-v" (verbose) an dann siehst du was gesendet wird (und auch ggf. eine Antwort) ist dein Oszi-Bild "vollständig"? Mir kommt es zu kurz vor, selbst bei einer einfachen Abfrage sollten 8 Byte gesendet werden: -- Polling slave 2... Ctrl-C to stop)
|
||
|
||
Ich bin nicht sicher ob ich deine Oszi-Bilder richtig interpretiere: Welche Pegel-Differenz hast du zwischen den A/B Leitungen? "nur" 2 Volt? Das wäre zu wenig, soweit ich weiß muss der Pegel midestens +/- 1.5Volt sein, also 3 Volt Differenz |
||
|
||
|
||
Danke schonmal für die Antworten!! Das mit dem -0 habe ich zuvor eh auch schon probiert gehabt, ohne Erfolg leider. Ich habe jetzt nochmal getestet ob es etwas ändert wenn man nicht nur einmal eine Übertragung sendet (-1 weggelassen), leider auch ohne Erfolg. Die Übertragung ist zumindest im oberen Bild komplett. Mehr schickt der Raspberry nicht. Das mit dem -v kennt mein modpoll nicht. Welche Version hast du denn da? Ich bin bei modpoll v3.11. Zum Pegel der A/B Leitungen: Dieser ist halbwegs abhängig vom verwendeten Abschlusswiderstand: ohne Abschlusswiderstand habe ich +/- 5V, das Bild vom Originaleintrag wurde mit 333 Ohm gemacht mit ca. +0/- 2V. Das ist mitunter doch zu wenig. Ohne Abschlusswiderstand sind die Flanken auch schön und die Differenzspannung passt, also nehm ich mal das 👍 Zur Belegung nochmal: Auf A ist der Ruhepegel jetzt 5V, auf B 0V. Soweit ich das gelesen habe müsste das so stimmen, oder? Das Oszi hat eine Dekodierfunktion, allerdings nur für RS232. Aktuell scheint es so als würde es die 8 Bytes erkennen, wenn man allerdings am Oszi für die Dekodierung eine Baudrate von 19200 einstellt. Aber ich denk das funktioniert in dem Fall nicht richtig, weil es die Stop-Bits scheinbar nicht erkennt Laut dem Datenblatt des Zählers sollte der Parameter 30343 ein Float 4 Byte Wert sein: stromzähler . eu / media / 5f / b6 / aa / 1696582672 / sdm72dm-v2 . pdf Wobei mir nicht klar ist warum man die ersten beiden Ziffern weglassen kann (zumindest so in der Anleitung von kraweuschuasta at Liefert Modbus auch keine Fehlertelegramme? Wenn quasi die abgeholte Datenmenge nicht stimmt, würde ich mir Zumindest ein Error-Telegramm erwarten... |
||
|
||
sorry da hab ich mich verschaut: ich verwende nicht modpoll, sondern mbpoll (allerdings auch nicht auf einem Raspi, sondern auf einer "großen" Linux-Kiste mit Debian. https://github.com/epsilonrt/mbpoll Was meinst du mit "die ersten beiden Ziffern"? doch, modbus kennt schon Fehler, aber nur wenn die Abfrage auch ankommt / verstanden wird |
||
|
||
Das ist bei so Miniinstallationen meiner Erfahrung nach vernachlässigbar, kraweuschuasta hat gar keinen Abschlußwiderstand in seiner Teststellung verwendet. Baudraten funktionieren sowohl 9600 wie auch 19200...muß halt auf beiden Seiten gleich konfiguriert sein. Ich bin damals über den Adapter/Wandler gestolpert und hab zig Stunden investiert. Da gibts nämlich offensichtlich durchaus Unterschiede... Ich hab dann nochmal die paar Euro investiert und genau das Modell gekauft, das in der Anleitung oder dem Beispiel verwendet wurde. Das spart auf jedenfall Zeit und vor allem Nerven |
||
|
||
Hallo kljsfdkj, hier gibt es dazu Erfahrungen und Preise: Hilfe bei Modbus Anbindung von SDM72D-M Stromzähler |
||
|
||
Nach gefühlt tausendfachen Überprüfungen und Tests hab ich mir gedacht, ich probiers mal mit Windows: Programm Modbus Poll installiert, Parameter eingestellt: ZACK geht Das führt mal zu wertvollen Erkenntnissen: - USB-Serial Wandler geht - Stromzähler geht, ist ansprechbar und liefert per Modbus auch das was am Display steht - Pinbelegung passt - Kabel passt - Abschlusswiderstand stört nicht wenn er fehlt Wenn man die Telegramme vergleicht wunderts mich auch nicht warums mit dem Raspberry nicht geht. Jedoch bleibt die Frage warum! Du hattest recht @Benji, es sind 8 Byte die übertragen werden: mit dem Kommando modpoll -0 -b 9600 -p none -s 2 -m rtu -a 127 -c 2 -r 384 -t 3:float /dev/ttyUSB0 würde ich mir das gleiche Signal erwarten, jedoch leider nein Erstens sinds zu wenig bytes, zweitens sieht nur das erste Byte gleich aus, der Rest absolut nicht. Ideen, Vorschläge was es damit auf sich haben könnte? Vom Timing her müsste es passen, sonst würden die Flanken des Ersten bytes nicht fluchten. Btw: Ich hab zwischenzeitlich die Stop bits und die Adresse am Stromzähler geändert. Man wird ja direkt abergläubisch ;) @Benji: Wie sieht denn dein mbpoll Aufruf auf? die Programme scheinen sich ziemlich zu ähneln... |
||
|
||
Gratuliere, dann bist du wirklich mal einen großen Schritt weiter! Einer meinr Aufrufe lautet: mbpoll -m rtu -b 19200 -d 8 -s 1 -P none /dev/ttyUSB0 -a 2 -0 -r 200 -c 1 -t 4:int -B -v (in meinem Fall frage ich meine Heizung ab, und Register 200 ist die Raumtemperatur als int, multipliziert mit 1000) Falls du dann weiter kommst: man kann das natürlich so wie kraweuschuasta per bash-Skript machen, ich mach das zB in Perl, mit https://metacpan.org/pod/Device::Modbus::RTU::Client und schreib die Daten dann in eine PostgreSQL Datenbank Ich gehe davon aus dass es ähnlich komfortable Bibliotheken auch zB für Python (igitt!) usw. gibt, ich bin halt old-school mit Perl unterwegs |
||
|
||
Ich hab zwar nur die SDM630 im Einsatz, verwend dafür den ModBus Measurement Daemon (https://github.com/volkszaehler/mbmd) der auch den SDM72 laut Liste unterstützt. Evtl. damit probieren, ob hier die "scan" Option etwas zurückliefert? Läuft zuverlässig seit einigen Jahren und schickt die Daten an einen MQTT Broker. |
Beitrag schreiben oder Werbung ausblenden?
Einloggen
Kostenlos registrieren [Mehr Infos]