Neue Versionen und Support zum Modbus-Modul

[Reinerlein]

Hallo Stefan, hallo Rainer,

also ich habe das bei mir über eine serielle Schnittstelle laufen, und dementsprechend zwei Devices wie folgt definiert:

Code Auswählen Erweitern


define modbus Modbus /dev/serial0@19200

define hwr_Heizungsanlage ModbusTrovis5576 240 300


Das funktioniert immer noch, zumindest mit folgender Version: Modbus 4.0.18 - 1.12.2018.
Es kommt nur eine Fehlermeldung, dass er ein Mapping nicht auflösen kann (weil bei einem Register plötzlich eine unerwartete "0" kommt). Das habe ich bei mir schon mal korrigiert, und beobachte es gerade... 

Grüße
Reiner

[StefanStrobel]

Hallo Rainer, hallo Reiner,

wenn es über RS485 funktioniert, sollte es auch über Modbus TCP weiterhin funktionieren. Vielen Dank für's Testen!
Bei RS485 oder RS232 ist ein Device vom Typ Modbus nötig, bei Verbindungen über Modbus TCP sollte das nicht der Fall sein.
Das Trovis-Modul sorgt selbst dafür, dass 98_Modbus.pm geladen wird.

Hintergrund ist der, dass bei Modbus TCP jedes Device eine eigene TCP-Verbindung öffnet und verwaltet. Bei RS485 / RS232 könnten mehrere Fhem-Geräte über die gleiche Schnittstelle kommunizieren wollen. Damit das kein Problem wird, gibt es das physische Modbus-Device in Fhem und die logischen Geräte verwenden dieses als IO-Device.

Für die Fehlersuche würde ich vorschlagen, verbose auf 5 zu setzen und dann das Log zu posten. Dann sollten wir sehen was tatsächlich passiert.

Gruss
   Stefan

[elektro_rainer]

Hallo Stefan,

wo und wie definiere ich die IP von meinem Gateway?

Danke und Grüße,
Rainer

[StefanStrobel]

Hallo Rainer,

die Syntax bei Modulen auf Basis von 98_Modbus.pm ist typischerweise identisch mit der Syntax von ModbusAttr.
Im Prinzip kann man sich die gerätespezifischen Modbus-Module wie ein ModbusAttr mit eingebauten Registerdefinitionen vorstellen.
Entsprechend kann man Register oder Details zur Ausgabe mit den Attributen wie sie in der Doku zu ModbusAttr stehen überschreiben.
Langer Rede kurzer Sinn:

define WP ModbusAttr 5 60 192.168.1.122:502 TCP
to talk Modbus TCP to a device with IP-Address 192.168.1.122 and the reserved port for Modbus TCP 502
Note that for Modbus over a TCP connection you don't need a basic Modbus device for the interface like ModbusLine above.

so steht es in der Doku zu ModbusAttr.
In Deinem Fall ist die IP-Adresse nicht die des Geräts (das hat ja keine sondern spricht Modbus-RTU) sondern die des Gateways:

Code Auswählen Erweitern


define modbustrovis ModbusTrovis5576 222 60 192.168.1.x:502 TCP


Gruss
    Stefan

[elektro_rainer]

Hallo Stefan,

danke für Deine Antwort,... genauso funktioniert's!

Vielen Dank!

[Roger]

Hi Stefan,
einen Nutzer von dem 98_Fronius_Modbus.pm Modul ist folgende Warnung aufgefallen:

Code Auswählen Erweitern

2019.01.01 13:58:16 3: Wechselrichter: MapConvert called from ModbusLD_ParseObj did not find 0 in map 1:aus, 2:AutoShutdown, 3:startet, 4:Normalbetrieb, 5:Leistungsreduktion, 6:abschalten, 7:Fehler, 8:Standby

Nun ist 0 bei Fronius nicht als Status definiert.
Kann man die Fehlermeldung unterdrücken/abstellen?

//Roger

[Reinerlein]

Hi Roger,

ich habe das auch in meinem Trovis-Modul festgestellt, und erstmal einfach ein Mapping für die 0 angegeben.

Das ist erst mit einer neuen Version irgendwann reingekommen. Anscheinend wird da etwas in der falschen Reihenfolge ausgewertet, da ich im Reading niemals diese 0 zu sehen bekomme...

Grüße
Reinerlein

[StefanStrobel]

Hallo,

ich könnte das LogLevel für diese Meldung generell auf 4 oder 5 erhöhen.
Andererseits wäre es interessant zu sehen, wie die Situation entsteht.
Wenn es sich also reproduzieren lässt, würde ich mich über ein Log mit Verbose 5 freuen

Gruss
   Stefan

[StefanStrobel]

Hallo,

anbei eine neue Version zum Testen.
Man kann jetzt auch dev-x-defSet, dev-x-defHint sowie
dev-type-[A-Za-z0-9_]+-hint  und dev-type-[A-Za-z0-9_]+-set verwenden

Wenn keine Beschwerden kommen, würde ich es demnächst einchecken

Gruss
   Stefan

[wthiess]

Hallo Stefan!
die neue Version läuft bei mir Ralais Lüftung und Thermostate wie gewohnt.

Aber ich hab unabhängig eine Frage. Seit geraumer Zeit habe ich immer wieder Timeoutfehler.
Meldung: Timeout waiting for a modbus response in ReadAnswer
Zu 90%Meistens schaltet er aber korrekt.
Welches attr kann ich da einsetzen.
lg
Wolfgang

[StefanStrobel]

Hallo Wolfgang,

Da würde ich zunächst nach der Ursache forschen.
Ein Log-Auszug bei verbose 5 wenn gerade ein Timout kommt, wäre hilfreich.

Gruß
   Stefan

[pejonp]

Hallo Stefan,

habe mal die neuen Module installiert. Werde testen und berichten.

Ein Frage habe ich aber noch. Wie kann ich die Abfrage von Reg nur einmal täglich machen. Bei meinem SolarEdge-Modul sind ja einige Reg nicht veränderlich. Die brauchen eigentlich nur einmal am Tag oder bei Neustart ausgelesen werden.

Code Auswählen Erweitern


C_DeviceAddress  3 2019-01-29 21:51:59
C_Manufacturer    SolarEdge 2019-01-29 21:51:59
C_Model                SE5K 2019-01-29 21:51:59
C_SerialNumber    7E1820EA 2019-01-29 21:51:59
C_SunSpec_DID    Dreiphasig 2019-01-29 21:51:59
C_SunSpec_ID      SunS 2019-01-29 21:51:59
C_Version              0002.1053 2019-01-29 21:51:59


Definition ist so.

Code Auswählen Erweitern


"type-VT_String" =>  { 
        'decode' => 'cp850',
        'encode' => 'utf8',
        'expr' => '$val =~ s/[\00]+//gr',
        'len' => '8',
        'revRegs' => '0',
        'unpack' => 'a16',
    },
....

"h40000" =>  {  # 40001 2 C_SunSpec_ID uint32 Wert = "SunS" (0x53756e53). Identifiziert dies eindeutig als eine SunSpec Modbus-Karte
                                   'len' => '2',
                               'reading' => 'C_SunSpec_ID',
                               'revRegs' => '0',
                                'unpack' => 'a4',
                               'defPoll' => '0',
                       },
          "h40004" =>  { # 40005 16 C_Hersteller String(32) Bei SunSpec eingetragener Wert = " SolarEdge "
                               'reading' => 'C_Manufacturer',
                                  'type' => 'VT_String',
                               'defPoll' => '0',
                       },
          "h40020" =>  {       'reading' => 'Block_C_Model',
                                  'type' => 'VT_String',
                               'defPoll' => '0',
                                  'expr' => 'ExprMppt($hash,$name,"C_Model",$val[0],0,0,0,0)', # conversion of raw value to visible value
                       },
          "h40044" =>  {       'reading' => 'C_Version',
                                  'type' => 'VT_String',
                               'defPoll' => '0',
                       },
          "h40052" =>  {       'reading' => 'C_SerialNumber',
                                  'type' => 'VT_String',
                               'defPoll' => '0',
                       },
          "h40068" =>  { #
                      'reading'  => 'C_DeviceAddress',
                               'defPoll' => '0',
                       },
          "h40069" => { # 40070 1 C_SunSpec_DID uint16 101 = Einphasig 102 = Spaltphase1 103 = Dreiphasig
                      'reading' => 'C_SunSpec_DID', # name of the reading for this value
                          'len' => '1' ,
                                  'map' => '101:Einphasig, 102:Spaltphase1, 103:Dreiphasig',
                              'defPoll' => '0',
                },



Gruß Jörg

[wthiess]

Hallo Stefan!

Hier einige Meldungen.

Code Auswählen Erweitern

2019.01.29 21:58:56 3: VR400Mod: Timeout waiting for a modbus response, request: id 1, fCode 3, type h, adr 800, len 1 for device Alarms reading REG_ALARMS_ALL, read buffer empty
2019.01.29 21:58:56 3: Zaehler: Timeout waiting for a modbus response, request: id 16, fCode 3, type h, adr 9, len 1 for device Birgit_Soll reading temperature, read buffer empty

2019.01.29 22:00:42 5: Zaehler: QueueRequest called from ModbusLD_DoRequest with c1, qlen 1
2019.01.29 22:00:42 5: Zaehler: StartQueueTimer called form QueueRequest has already set internal timer to call Modbus_ProcessRequestQueue in 0.991 seconds
2019.01.29 22:00:42 5: Zaehler: read buffer: 100302000ac440
2019.01.29 22:00:42 5: Zaehler: ParseFrameStart (RTU) extracted id 16, fCode 3 and data 02000a
2019.01.29 22:00:42 5: Zaehler: HandleResponse called from Read
2019.01.29 22:00:42 5: Zaehler: ParseResponse called from HandleResponse
2019.01.29 22:00:42 5: Zaehler: CheckChecksum (called from HandleResponse): c440 is valid
2019.01.29 22:00:42 5: Zaehler: HandleResponse now passing to logical device Birgit_Soll for parsing data
2019.01.29 22:00:42 5: Birgit_Soll: ParseObj called with data 000a, type h, adr 9, valuesLen 1, op read
2019.01.29 22:00:42 5: Birgit_Soll: ParseObj ObjInfo for h9: reading=temperature, unpack=n, expr=$val/2, format=%.1f, map=
2019.01.29 22:00:42 5: Birgit_Soll: ParseObj unpacked 000a with n to 10 hex 3130
2019.01.29 22:00:42 5: Birgit_Soll: CheckEval for ModbusLD_ParseObj evaluates expr for temperature, val=10, expr=$val/2
2019.01.29 22:00:42 5: Birgit_Soll: CheckEval for ModbusLD_ParseObj result is 5
2019.01.29 22:00:42 5: Birgit_Soll: ParseObj for temperature does sprintf with format %.1f, value is 5
2019.01.29 22:00:42 5: Birgit_Soll: ParseObj for temperature sprintf result is 5.0
2019.01.29 22:00:42 4: Birgit_Soll: ParseObj assigns value 5.0 to temperature



lg
Wolfgang

[wthiess]

Hallo Stefan!
Ich hab das auch wenn ich nichts ändere. DH auch beim auslesen dürfte hier ein Timingproblem vorliegen.
lg
Wolfgang

[StefanStrobel]

Hallo Wolfgang,

In Deinem Log-Ausschnitt kommt der Fehler als erstes, danach scheinen einige Zeilen zu fehlen und dann kommt ein erfolgreicher Request.
Um die Herkunft des Fehler zu sehen, bräuchte ich mehr Kontext, vor allem was vor dem Fehler passiert.
Bitte poste doch noch einen ungekürzten Log-Auszug beginnend mindestens 4 Sekunden vor der Fehlermeldung.

Gruss / Thanx
   Stefan