Neue Versionen und Support zum Modbus-Modul

[olwaldi]

Mittlerweile läuft Modbus ohne disconnected/reappeared seit einem Tag im 30s-Intervall.

Offenbar verträgt es sich jetzt mit SIRD. Im Code von SIRD wird Blocking verwendet, was möglicherweise mein Problem mit Modbus auslösen mag. Zudem gibt es eine Timer-Abfrage mit 30s Wartezeit beim Discovern. Oder gar 300s beim HTTP::Daemon.

Und die 60..61s? Da habe ich DENON_AVR in Verdacht. Dort läuft per default ein ConnectionCheck alle 60s. Kann man via attr deaktivieren, was ich gerade getan habe.

Wie könnte man die "wahre" Ursache für mein Modbus-Problem gezielter 'rausfinden?


Grüßle, Michael

[Elektron]

Hallo zusammen,

Hat sich jemand die Modbus Anbindung eines Venus E von Marstek umgesetzt?
Wäre sehr interessiert, wenn das jemand teilen könnte?

Vielen Dank und Grüße Michael

[Elektron]

Hallo zusammen,

ich habe es geschafft meine Martek Venus E mit dem Modul per Modbus TCP anzubinden.
Seitdem habe ich zweimal beobachtet, dass FHEM in der Nacht blockiert (und morgens die Rolläden nicht hochgefahren sind).
Das Webinterface ist dann nicht mehr erreichbar, FHEM selber läuft noch. Wenn ich nun FHEM über:
"sudo systemctl stop fhem" beende, fahren die Rolladen (per knx angebunden) auf einmal hoch.
Wenn ich dann fhme neu starte ist alles gut.

Im FHEM Log habe ich den folgenden eintrag vor der Blockade gefunden (muss aber natürlich nicht die Ursache sein):

Code Auswählen Erweitern

2025.12.29 07:15:44 3: MB_Marstek_1: Timeout in Readanswer, current frame / read buffer: 00f900000007010304000004ad, id 1, fCode 3, tid 249,
request: id 1, read fc 3 h32202, len 2, tid 249, master device MB_Marstek_1, reading AC_Power (getUpdate for AC_Power len 2), queued 2.53 secs ago, sent 2.41 secs ago,
response: id 1, fc 3, h32202, len 2, values 000004ad
Den Timeout finde ich immer wieder im Log, ohne das FHEM blockiert. Könnte das die Ursache sein?
Hat jemand einen Tip?
Gibt es einen Timeout den ich setzen kann, damit die Blockade kontrolliert beendet wird?

Vielen Dank und Grüße Michael

[Rampler]

Erst mal ein gutes neues !!

Leider fehlt mir der get Button bei meinen Modbus Geräten.
ein "get device Registername" funktioniert aber noch, nur der get button fehlt.

Was habe ich da wieder verstellt ?
Leider kann ich nicht auf die alte Version, da diese mit Trixie nicht lauffähig ist.

Nachtrag:
Die Version:
98_Modbus.pm                28814 2024-04-21 14:12:59Z StefanStrobel
hat noch einen get button

[laserrichi]

Kann ich bestätigen, mit der letzten Version fehlt der get button

[laserrichi]

Ok ich habe den Fehler gefunden.
@stefanStrobel bitte im repository korrigieren:

Code Auswählen Erweitern

Zeile 1085 ist das showget falsch und muss showGet sein:

            $hash->{'.getList'} .= "$oi->{'reading'}:noArg " if ($oi->{'showGet'}); # sichtbares get
soweit ich das im code gesehen habe, war eine Variable alt in Zeile 1015 my $showge definiert gewesen, diese ist aber rausgefallen.

[thomasgloor]

Ich bin da mal etwas verwirrt...

Ich bin dran meine Stiebel-Eltron WPL19 mit ISG einzubinden. Gemäss Stiebel-Doku sollte die Adresse 507 die Aussentemperatur liefern. Also ein Attribut für 507 erstellt:

Code Auswählen Erweitern

attr WP_Modbus obj-i506 Aussentemperatur, expr=$val / 10Zurück kommt ein 3-Stelliger Wert, der der Isttemperatur HK1 entspricht. Der sollte Adresse 507 haben...
Mache ich ein Attribut für die Adresse 507, kommt die Aussentemperatur zurück...

Ein ScanModbusObjects laufen lassen, und die Werte etwas analysiert: Es sind ALLE Werte auf einer um Eins verschobenen Adresse zu finden!

Mach ich was falsch, oder ist das ein Bug?

FHEM habe ich vor etwae einer Woche aktualisiert...

[tobmaster1985]

Steht dazu evtl was in der Doku von deinem Gerät?

Bei Sungrow ist auch alles um 1 verschoben, steht aber auch so in der Doku.

[300P]

Das ist öfters schon mal so🤔
Die einen fangen bei ,,0" mit den Registern an zu zählen - die anderen ,,1".
Dann muss man halt ,,umrechnen".😇

[thomasgloor]

Echte Programmierer beginnen mit Null zu zählen!

In der Doku steht selbstverständlich nichts dazu.

Ist ja im Prinzip auch nur ein Schönheitsfehler. Etwas lästig beim Aufsetzen des Devices... 🤣

[Prof. Dr. Peter Henning]

Echte Programmierer beginnen mit Null zu zählen!

Das ist, pardon, granatenmäßiger Unsinn. Eine Zählung beginnt immer mit 1, eine Indizierung kann auch mit Null beginnen. Und genau das ist hier der Fall.

pah

[freetz]

Hallo zusammen,

ich habe versucht die Suche zu bemühen, aber wenn ich "Timeout" oben in der Suche für "Dieses Thema" eingebe, kommt nichts, obwohl Google mich (auch) auf diesen Thread gestoßen hat. Das nur zur Entschuldigung, falls ich etwas übersehen haben sollte.

Ich habe meinen SolarEdge Wechselrichter über ModbusAttr an FHEM angebunden. Das klappt grundsätzlich prima, es tauchen jedoch mit unterschiedlich langen (eher: kurzen) Unterbrechungen diese Timeout-Fehler auf:

Code Auswählen Erweitern

2026.03.02 01:40:55 3: BydBattery: Timeout in Readanswer, current frame / read buffer: 00d00000000d01030a2653cd6720a53848fffc, id 1, fCode 3, tid 208,
request: id 1, read fc 3 h40206, len 5, tid 208, master device BydBattery, reading Meter_Power (getUpdate for Meter_Power len 5), queued 2.30 secs ago, sent 2.05 secs ago,
response: id 1, fc 3, h40206, len 5, values 2653cd6720a53848fffc
2026.03.02 01:41:18 3: BydBattery: Timeout in Readanswer, current frame / read buffer: 00080000000d01030a12d8e9319d118c97fffd, id 1, fCode 3, tid 8,
request: id 1, read fc 3 h40206, len 5, tid 8, master device BydBattery, reading Meter_Power (getUpdate for Meter_Power len 5), queued 5.30 secs ago, sent 5.05 secs ago,
response: id 1, fc 3, h40206, len 5, values 12d8e9319d118c97fffdBeim ersten Abruf war dev-timing-timeout noch auf 2, beim zweiten Abruf auf 5. Das Seltsame ist, dass der Timeout zwar kurz nach dem Ende des Timeout-Intervalls kommt, aber in beiden Fällen der read buffer mit einem gültigen Wert zurück kommt, der dann auch einen gültigen "values" Wert erzeugt und dann auch im Modul der korrekte Wert angezeigt wird.
Ich frage mich, warum/woher dann dieser Timeout kommt?
Ich polle 5 Holding-Register alle 20 Sekunden, das sollte doch nicht zu viel sein?
Weil die Werte in der Anzeige im Modul wie gesagt problemlos aktualisiert werden, habe ich mich bisher nicht darum gekümmert, aber da das die Logfiles doch sehr start füllt, wollte ich fragen, ob das Problem bekannt ist, und wenn ja, wie ich es lösen kann.
Vielen Dank auf jeden Fall schon mal!

F.

[freetz]

Ergänzung:
Ich habe ein DOIF, das auf ModbusAttr Events reagiert, und das dann wiederum per "set" einen Parameter über ModbusAttr ändert (Beispiel: Wenn PV-Produktion sinkt unter einen bestimmten Wert -> wechsle von Export auf Eigenverbrauch). Sobald das passiert, kommt der Timeout oben. Aber wie gesagt, es wird sowohl der korrekte Wert abgerufen, als auch das Set korrekt ausgeführt...

[freetz]

Und die Lösung kommt nun auch schon hinterher: Das DOIF muss mit einer Sekunde verzögerung (Attribut: "wait" mit je einer Sekunde pro Zweig, also in meinem Fall: "1:1:1:1") ausgeführt werden, dann ist das Problem gelöst ...