Neues Modul für Geräte mit Modbus Schnittstelle über RS232 bzw. RS485

[BallaBalla]

Hallo in die Runde
An bei mein Code für einen Zähler ABB B23 112 100. Es sollte auch für Zähler ABB B21 und ABB B24 funktionieren.
Installationsanleitung mit Code-Tabelle gibt es auch in Deutsch bei ABB.

Wer den Code benutzen möchte, kann es tun.

Der Code ist nicht ganz vollständigt da ich bei einigen Punkten total auf dem Schlauch stehe.
Evtl. hat jemand die Zeit und die Lust daraus ein Modul zu erstellen. Das übersteigt derzeit noch mein können.

Gruß
Benno

[mba]

Hallo Stefan,

erstmal vielen Dank für das Modbus Modul.
Ich habe jetzt 9 Slaves per RS485 laufen.
Das funktioniert Prinzipiell auch, aber hin und wieder gibt es doch Probleme.
Das manchmal Werte aus falschen Registern gesetzt werden scheint gefixt zu sein.
Aber ich habe öfter das Problem das beim schreiben von Registern der RS485 Port einen disconnect bekommt, dadurch kommen nicht alle FHEM Befehle bei den Slaves an. Wenn ich den Verbose Wert der Slaves auf 3 setze bekomme ich jede menge "Send queue too long".
Da die Slaves ja nicht von sich aus senden können muss das modul eine art "Statemachine" abbilden, daher habe ich einen Interval von 1 und kurze Timeouts um die kontinuierlich zu pollen.
Ich bin kein Programmierer und kann den Code nur schwer nachvollziehen, daher meine Frage.
Besteht die Möglichkeit anstatt eines Intervals das polling Kontinuierlich laufen zu lassen, damit müsste sich die queue auch deutlich verkleinern da die gleiche abfrage nicht mehrfach existiert. Vielleicht auch mit einem Vorrang für schreibende Requests.
Ich habe die Slaves vorher mit einem Python Script angesprochen und bei 9 Slaves mit 160 Registern für einen kompletten Poll 1.2s benötigt. Jetzt mit FHEM und nur noch 50 Registern benötige ich mehr als das doppelte an Zeit, plus die manchmal verschluckten Writes.
Ach ja, läuft alles auf einem PI2.

Güße Marco

[StefanStrobel]

Hallo Marco,

ein "kontinuierliches Pollen" gibt es leider nicht. Modbus Slaves antworten immer erst wenn sie gefragt werden und Daher musst Du eben häufig fragen.

Du kannst aber vermutlich einiges optimieren.
Jeder Slave hat ein eigenes Maximum an Registern, die in einem Read per Function Code 3 gleichzeitig gelesen werden können. je höher Du das setzt (Combine) umso effizienter wird der Bus genutzt. Du darfst nur nicht über das Maximum gehen, sonst antworten die Slaves ggf. gar nicht. Das Maximum steht normalerweise in der Doku der Slaves.

Bei 9 Slaves und vielen Registern ist evt. auch die Default-Send-Queue zu kurz. Die kannst Du auch per Attribut vergrößern.

Wenn die serielle Schnittstelle auf Disconnected geht, klingt das nach Verkabelungsproblemen, die evt. erst bei einer intensiven Bus-Nutzung Auswirkungen zeigt. Durch Erhöhen von Combine wird das evt. besser.

Gruss
    Stefan

[mba]

Die Slaves habe ich selber gebaut, Arduinos mit Minimalmodbus. Die max. gleichzeitige Anzahl an Registern sind 25 schreibend oder 27 lesend, dann ist die FIFO Puffer voll. Mit dem Python Script habe ich immer 20er blöcke benutzt, das Funktioniert auch Problemlos ohne disconnects. Wenn ich mit FHEM mehr als 10 gleichzeitig hole gibts jede menge timeouts und disconnects.
Ich habe etliche konstellationen mit timeouts, combine und queue längen ausprobiert.
Jetzt habe ich combine 2, queue 100, commdelay 0, senddelay 0 und erreiche so ca. 2500 request die minute und manchmal einen timeout.
Da mit einem interval von 1 das abfragen der register immer sekündlich erfolgt, alle register aber abzufragen mehr als 1 sekunde dauert bring auch das erhöhen der queue nichts da sie immer überläuft.

Gibts keine möglichkeit z.B. die abfrage eines registers garnicht erst zu queuen falls diese abfrage schon in der queue ist?
Oder alternativ zu verhindern das schreibende anfragen aus der queue verworfen werden?
Das würde meine Probleme glaube ich schon beheben.

grüße
Marco

[StefanStrobel]

Hallo Marco,

das klingt seltsam. Es würde mich schon interessieren, wo der Unterschied zwischen dem Python-Script und den Requests von Fhem ist.
Hast Du eine Möglichkeit, die tatsächlich über die Leitung gehenden Daten aufzuzeichnen und zu vergleichen?

Das mit dem Droppen eines Requests, der schon in der Queue ist, ist eine gute Idee.
Ich pack das mal auf die Wunschliste.
In den letzten Monaten habe einiges an HTTPMOD weiterentwickelt und ein paar der Features davon möchte ich demnächst auch ins Modbus-Modul einbauen.

Gruss
    Stefan

[mba]

Hallo Stefan,

mit dem aufzeichnen habe ich mir auch schon Gedanken gemacht. Da das Problem der disconnects nur sporadisch auftritt müsste ein Langzeitlog her, aber bei den Unmengen an Daten die da anfallen sprengt das meinen PI.
Aber mit den jetzigen Einstellungen hält sich das ja in Grenzen, wenn bei 20000 Requests ein Disconnect auftritt ist die wahrscheinlichkeit das es ein write request war relativ gering. Ich denke aus der Queue werden vieeelmehr requests verworfen, und da ist die wahrscheinlichkeit hoch das es writes waren, und dann fahren meine rolladen halt nicht hoch oder runter.
Ich habe mit da schon mit doifs konstrukte gebaut um diese requests zu wiederholen bis der motor auch fährt, aber das wird immer komplizierter je mehr dazu kommt.
Als ich mir das pythonscript gebastelt habe konnte ich auch die passenden timeouts sauber ausmessen (mit dem ossi). Da ist mir aufgefallen das z.B. beim lesen verschiedener Register am gleichen Slave keine wartezeiten nötig waren, wenn aber ein anderer slave angesprochen wurde hat der bus eine weile benötigt bevor es funktionierte. Gleiches beim wechsel zwischen lesen und schreiben.
Also mit python habe ich das dann so gelöst das ich ein 50ms timeout benutze, aber erst beim 2. Timeout quasi die Fehlerbehandlung bzw. Protokolierung startete. Dadurch wurde der Bus von einem ausgefallenen Slave nicht blockiert, die Pollzeiten aber trotzdem niedrig gehalten. Soweit ich das nachlesen konnte hängt das auch stark von der eingesetzten Library ab, und der eingesetzen Hardware.

Ich hätte das Script auch weiterbenutzt, aber das ist viel einfacher wenn FHEM native Modbus spricht. Und mir ist es nicht gelungen eine vernünftige Schnittstelle zwischen dem Script und FHEM zu basteln. Dafür habe ich einfach keine Programmierkenntnisse, und jeden programmschritt zu googlen fehlt mir die Zeit.
Was ich wohl sagen kann, je mehr Last auf dem PI ist, desto eher gibt es timeouts, bzw. disconnects. Das python Script lief immer auf einem anderen Core als die FHEM Instanz, jetzt muss das alles über einen Core laufen, evtl. gibts dadurch timingprobleme.

grüße
Marco

[StefanStrobel]

Hi Marco,

Kannst Du mal testweise Combine auf 25 setzen, den Timeout dafür auf das doppelte und dabei mit verbose 5 loggen?

Gruß
   Stefan

[mba]

Hallo Stefan,

ich bin heute nicht dazu gekommen die logs zu ziehen.
Wenn ich früh genug zu hause bin reiche ich die morgen nach.

Grüße Marco

[mba]

Hallo Stefan,

ich hätte das log, sind ca. 10mb
https://www.dropbox.com/sh/3od3h0mvtse34uz/AAAnkcficAYJXfivDh8w1eHLa?dl=0

grüße Marco

[Bjoernar]

Hallo,

ist es auch möglich mit dem Modul ein Modbus Gerät zu erstellen?

Hintergrund ist das ich mehrere Modbus Geräte habe (Wechselrichter, Stromzähler, Lüftungsanlage) der Wechselrichter (Fronius) kann auch per Modbus auf einen Stromzähler zugreifen und liest dabei die Aktuelle Verbrauchsleistung aus. Jedoch funktioniert das nur mit dem von Fronius angebotenen Zähler da die Register bei meinem SDM630 andere sind. Nun würde ich die Werte meines SDM630 gerne auf einer neuen Adresse und mit anderen Registern wieder ausgeben. Somit würde der Fronius Wechselrichter über FHEM auch an die Werte kommen.

Gruß
Björnar.

[Bjoernar]

Hallo!

Ich habe eine Wohnraumlüftung von Systemair VR400DC. Derzeit steuere ich die Anlage über diverse Releais über deren Digitale Kontakte. Aber die Anlage kann mehr eben auch ModeBus.  Weiters habe ich einen USB-RS485 Adapter Von Circuit.
Der Adapter wird von Fhem gefunden.

define luftbus Modbus /dev/serial/by-id/usb-FTDI_FT232R_USB_UART_AL01GIJ7-if00-port0@19200,8,E,1

Leider habe ich keine Ahnung wie ich weiter machen soll und die Anlage in FHEm anzusprechen.
Lauft Beschreibung hat das Ding einige Werte die ich auslesen könnte.
Vielleicht kann mir bitte jemand hier weiterhelfen.

Kann ich dafür ein fertiges Modul verwenden oder muss dafür etwas programmiert werden? Leider bin ich kein Programmierer.

Hier die Modebusbeschreibung der Anlage.
intern.telso.at/ModbusD24810.pdf

lg
Wolfgang

Suchfunktion hätte dich darauf geführt:

https://forum.fhem.de/index.php/topic,54429.msg460088.html#msg460088

Bei mir Funktioniert es soweit gut. Ich steuer momentan aber nur die Stufen.
Aber man kann ja auch fast alles andere darüber festlegen.

Ich werde in Zukunft die Anlage auch Temperaturabhängig damit steuern.

Gruß
Bjrörnar

[StefanStrobel]

Hallo Marco,

Vielen Dank für die Logs und sorry für die späte Antwort.
So wie ich die Logs verstehe ist ein Hochsetzen von Combine prinzipiell schon der richtige Weg. Dadurch wird die Anzahl der Requests pro Sekunde deutlich reduziert. Allerdings haben Deine Geräte, wie Du es ja schon selbst erkannt hast, ein Problem wenn die nächste Anfrage an ein anderes Gerät zu früh nach der letzten Antwort auf den Bus kommt. Dann antwortet das Gerät nicht und der Timeout führt dazu dass der Bus lange nicht genutzt wird und während dieser Zeit läuft die Queue voll.

Ein Hochsetzen von commDelay oder sendDelay bringt möglicherweise auch nichts, da diese Delays bisher nur ein Gerät betrachten und nicht busbezogen arbeiten.

Für die nächste Modulversion würde auf jeden Fall einen weiteren Delay ermöglichen, der busbezogen dann greift wenn mit einem anderen Endgerät gesprochen werden soll. Zudem werde ich einbauen, dass Requests, die schon in der Queue stehen, gedroppt werden können.

In der Zwischenzeit könntest Du auch probieren, mit pollDelay nur die Register häufig zu Pollen, bei denen Du auch die Aktualität benötigst.

Gruß
     Stefan

[mba]

Hallo Stefan,

ich habe die Register schon reduziert, damit läufts auch.
Ich bin mal gespannt auf die neue Version.

Grüße Marco

[StefanStrobel]

Hallo,

anbei eine neue Version der Module Modbus und ModbusAttr zum Testen.
auf Ebene des physischen Device sind folgende Attribute neu:

• busDelay

grundsätzliche Verzögerung zwischen dem letzten Read und dem nächsten Send, auch Geräteübergreifend

• clientSwitchDelay

Verzögerung bevor ein Send an ein neues Gerät geht

• dropQueueDoubles

verwirft neue Requests falls der gleiche Request noch in der Queue steht

zudem wurden folgende Attribute von HTTPMOD übernommen.

• alignTime

wie bei at

• enableControlSet

vordefinierte Set-Befehle: reread, interval, start und stop

Gruss
    Stefan

EDIT 14.7.16: angehängte Dateien entfernt, neuere Version in späterem Post

[mba]

Hallo Stefan,

hab dein neues Modul mit ClientSwitchDelay und dropQueueDoubles laufen. Sieht alles gut aus.
Im laufe der Woche werde ich auch alle jetzt pausierten Register dazunehmen. Ich berichte dann davon.

Vielen Dank für deine Arbeit
Grüße Marco