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

[wthiess]

Warum wird ein Gerät verwendet das erst in den Modus geschalten werden muss. Ein Modbus-USB Gerät kostet 2-20€-?

[doesel]

Auch ich habe nach Update ein volles Logfile, mit minütlicher Meldung:

Code Auswählen Erweitern

MyRS485: timeout waiting for fc 3 from id 1, (h63776), Request was 0103f9200002f55d, Buffer contains 0103040002
Nach mehreren erfolglosen Versuchen mit timeoutLogLevel und Verbose habe ich nunmehr eine ältere Version Modbus installiert. Nun ist Ruhe.
Doesel

[tante ju]

Ich hab mir das nochmal angesehen.
Das Modbus-Modul verwendet für die Kommunikation ja Fhem DevIO. Auch das Setzen der Baudrate, Parity etc. geht vom Modbus-Modul an Devio, und dort wird Device::SerialPort verwendet um die Schnittstellen-Parameter zu setzen. Wenn wir einen Weg finden, wie man Device::SerialPort dazu bringt, ein Interface in den RS485-Modus zu bringen, ist der Rest schnell gemacht. Device::SerialPort verwendet wohl termios recht ausführlich ...

Letztlich wird RS485 auch nur über TermIOs eingeschaltet. Das Problem ist nur, daß die Konstanten nicht in Perl definiert sind, wie zum Beispiel TIOCSERSETRS485.
Habe mal einen Artikel gesehen, in dem jemand die Konstanten in Perl definiert. Macht das ganze dann aber systemabhängig und ich finde den jetzt auch nicht wieder.

[Zwiebel]

Hallo,

ich habe die gleichen Fehler wie doesel seit meinem letzten Update im fhem.log!

Code Auswählen Erweitern


2017.01.19 15:13:14 3: modbus: timeout waiting for fc 4 from id 11, (i344), Request was 0b0401580002f14e, Buffer contains
2017.01.19 15:13:18 3: modbus: timeout waiting for fc 3 from id 11, (h63776), Request was 0b03f9200002f5f7, Buffer contains 0b03040002
2017.01.19 15:14:04 3: modbus: timeout waiting for fc 3 from id 21, (h63776), Request was 1503f9200002f649, Buffer contains 1503040002
2017.01.19 15:14:07 3: modbus: timeout waiting for fc 4 from id 20, (i342), Request was 14040156000412e0, Buffer contains
2017.01.19 15:14:09 3: modbus: timeout waiting for fc 3 from id 20, (h63776), Request was 1403f9200002f798, Buffer contains 1403040002


woran kann das liegen? Muß ich ein entsprechendes Attribut setzen?

viele Grüße
Zwiebel

[wthiess]

Hab ich auch. Aber alles läuft.
Lg

[StefanStrobel]

Hallo,

die Timeouts wurden in einer früheren Version des Modbus-Moduls nur auf Loglevel 4 protokolliert und deshalb haben die meisten Leute das gar nicht bemerkt, wenn verbose für das Modbus-Gerät wie üblich auf 3 steht.
In der neuen Version wird es per Default auf Ebene 3 protokolliert und dann sieht man es, es sei denn man setzt das Attribut timeoutLogLevel für das physische Device auf 4 (scheint im obigen Log "modbus" zu sein).

Wenn solche Timeouts nur selten auftreten würde ich mir keine Gedanken machen. Wenn es aber ständig kommt, sollte man nach der Ursache der Timeouts suchen - nicht nach dem Attribut zum Verhindern des Log-Eintrags

Nach "Buffer contains" im Log wird angezeigt, ob schon etwas empfangen wurde.
0b03040002 ist eine Modbus-Antwort von ID 11 auf function code 3, bei der nur noch wenige Bytes am Ende fehlen. Das Gerät hat also durchaus geantwortet. Ich würde mal testen ob eine Erhöhung des Timeouts die Lage verbessert.

Gruss
    Stefan

[cotecmania]

Hi,

benutze FTUI auf einem Tablet zur Visualisierung. Alles läuft stabil und das Einzige Problem ist folgendes :

In einem SimpleChart-Widget stelle ich 2 Werte eines ModBus-Devices dar (Solar-Laderegler)
Leider funktioniert der automatische Refresh (Longpoll?) bei diesem Chart NICHT. Nur wenn ich manuell einen Reload auslöse.
Ich habe noch andere Charts mit Werten aus Nicht-Modbus-Devices, die werden regelmässig aktualisiert.

An was kann das liegen ?

Gruss
Joe

[StefanStrobel]

Hallo Joe,

leider kenne ich das Widget nicht.

Gruss
    Stefan

[StefanStrobel]

Hallo,

anbei nochmal eine neue Version mit ein paar Neuen Features zum Testen.

Neu:
- Verbindungen werden jetzt generell erst geöffnet wenn Fhem mit der Initialisierung fertig ist.
   (auch bei seriellen Verbindungen über ein Modbus IODev)
   Damit ist auch das Logging klarer und es wird auch bei mehreren seriellen Adaptern korrekt beim Öffnen angezeigt,
   über welchen Adapter die Kommunikation gehen wird. Bei einem Disable werden auch serielle Verbindungen geschlossen
- Neues Attribut skipGarbage ignoriert führende Bytes, die nicht passen (bei Antworten über serielle Verbindungen)
- Neues Attribut ignoreExpr kann bei Objekten verwendet werden um das Updaten des Readings zu verhindern,
   wenn eine Bestimmte Bedingung erfüllt ist.
- Generell kann man jetzt auch die Adressen von Objekten mit führemdem Nullen definieren.
   Das macht die Liste der Attribute etwas lesbarer,
   verlangsamt aber auch die Verarbeitung wenn es verwendet wird.
- Alle Expressions in Attributen werden jetzt bei der Auswertung so abgearbeitet,
   dass Warnings sauber und mit Kontext im Fhem log erscheinen.
- Aktualisierung der Timeouts-Statistik funktioniert jetzt auch wenn keine Timeouts aufgetreten sind
- intern wird jetzt generell isDisabled verwendet und nicht mehr nur das Attribut "disabled" geprüft

Gruss
   Stefan

[ak323]

Hallo Stefan.
Basierend auf Deinem Modbus Modul (ältere Version ModbusSET) lese ich die Register meiner Waterkotte WP über RS485/RTU aus: https://forum.fhem.de/index.php/topic,52864.msg570369.html#msg570369

Leider kann ich keine Register größer als 255 auslesen. Ich bekomme die im link angegebene Fehlermeldung. Ein anderer Nutzer des Moduls nutzt Modbus TCP und kann die höheren Register ohne Probleme auslesen... hast Du (oder jemand anders) vielleicht nen Tipp der mir weiterhilft !?

Danke. ak323

[pejonp]

Hallo,

anbei nochmal eine neue Version mit ein paar Neuen Features zum Testen.
Neu....

Hallo Stefan,

habe die neue Version seit gestern im Einsatz und bis jetzt läuft alles. Danke.
Jörg

[StefanStrobel]

Hallo ak323,

die Fehlermeldung kommt vom Gerät und bedeutet, dass die Adresse nicht gültig bzw. nicht belegt ist.
Hast Du denn eine Anleitung, in der die belegten Register mit ihrer jeweiligen Bedeutung drinstehen?
Oder verwendest Du eventuell den falschen function code?
Vielleicht stehen die gesuchten Werte in input registern (function code 4) statt holding registern (function code 3)?
Oder es ist doch ein anderes Modell und hat eine geringfügig abweichende Registerbelegung.
Du könntest auch die neue Scan-Funktion ausprobieren um alle möglichen Register automatisch auszuprobieren. Ist weiter oben in diesem Thread beschrieben.

Gruss
    Stefan

[Allgaeuer]

Hallo Stefan,

bei mir läuft's ohne Probleme - Danke.

Gruß Allgäuer

[cotecmania]

Hi,

beim Befehl

Code Auswählen Erweitern

set LS2024B scanModbusObjects h100-120
bekomme ich

Code Auswählen Erweitern

Unknown argument scanModbusObjects ...

Code Auswählen Erweitern

ModuleVersion : 3.5.12 - 06.01.2017

Was mache ich falsch ?

Joe

[StefanStrobel]

hast Du die eingebauten set-Befehle mit attr LS2024B enableControlSet 1 aktiviert?

Gruss
    Stefan