Neue Versionen und Support zum Modbus-Modul

[pejonp]

Hallo Stefan,

ein Hinweis kommt noch:

Code Auswählen Erweitern


PERL WARNING: Useless use of string in void context at ./FHEM/98_Modbus.pm line 2102, <$fh> line 1646.


2101 (Zeilenumbruch, fehlt Kommentarzeichen)

        #Log3 $name, 4, "$name: SkipGarbageCheck looking for start byte " . unpack ('H*', $startByte).
            " protocol is $hash->{PROTOCOL}, mode is $hash->{MODE}";

Die Module werden aber geladen. Fehler bis jetzt noch keine.

Grüße Jörg

[Funnel]

Hallo Stefan,

ein erstes Feedback von mir:

• Polldelay funktioniert jetzt wie gewünscht
• closeAfterResponse funktioniert jetzt ebenfalls
• Zum Thema "passive Listener" mache ich noch ein paar Dauertests, sieht aber gut aus

Gruß
Thomas

[StefanStrobel]

Hallo,

Ich habe inzwischen noch einige automatische Tests für das Modul geschrieben und dabei noch Fehler beim Handling von Modbus ASCII gefunden und hoffentlich behoben.
Hier die aktuelle Version.

Gruß
   Stefan

[Zwiebel]

Hallo Stefan,

danke für dein tolles Modul!
Ich habe 6 Modbus Strom Zähler (1xSDM630 und 5xSDM120) die seit etwa 4 Jahren so vor sich hin zählen. Es gab immer mal wieder timeouts und checksum Probleme die ich mit verbose 2 ignoriert habe weil immer ausreichende Werte gekommen sind.
Dann habe ich zwei weitere SDM120 Zähler installiert. Einer von den beiden (Trockner id 13) liefert aber kein "Power__W", es kommt aber "energyTotal".
Daraufhin hab ich den Modbus neu verkabelt und geschirmte Leitungen verwendet. Die Modbus Kabellänge ist etwa 6-7 Meter.

Leider hat das keine Veränderung gebracht, Trockner liefert automatisch kein "Power__W". Ein "get Trockner Power__W" liefert nach paar sekunden einen Wert.

So habe ich den Trockner definiert:

Code Auswählen Erweitern


define Trockner ModbusSDM220M 13 60
attr Trockner IODev modbus
attr Trockner dev-timing-commDelay 3
attr Trockner deleteattr dev-timing-timeout 6
attr Trockner poll-Energy_total__kwh 1


Ich habe seit gestern um 18 Uhr dein Modul upgedatet und FHEM neu gestartet.
In dem screenshot sieht man das die Requests weniger geworden sind. Ich habe aber nur das Modul ausgetauscht.

Ich kann sonnst keine Veränderung sehen, es kommen von allen anderen Zählern Werte bis auf "Power__W" vom Trockner.

fhem log (filter "modbus") und das pm sind im Anhang.

viele Dank und Grüße,
Zwiebel.

[StefanStrobel]

Hallo Zwiebel,

vielen Dank fürs Testen.
Dass die Anzahl der Requests zurückgegangen ist, liegt vermutlich an einem Bug in einer früheren Version, in der polldelay ignoriert wurde. Um das genau sagen zu können, müsste ich aber auch die Logs der logischen devices sehen und mit älteren Logs vergleichen. Wenn alle Werte wie erwartet kommen, ist es aber vermutlich ein behobener Bug.

Das mit dem Power-Reading des Trockners ist seltsam. Um das zu klären bräuchte ich aber auch ein Log, in dem ich auch das logische Device sehe und nicht nur das Modbus-Io-Device. Am besten während eines Updates und eines expliziten get.

Was mir sonst noch auffällt ist die Häufigkeit, mit der die Send-Queue abgearbeitet wird. Kann es sein, dass Du queueDelay auf 0 gesetzt hast?

Gruß
     Stefan

[Zwiebel]

Hallo Stefan,

du hast recht ich hatte queueDelay auf 0 gesetzt, in der Hoffnung das damit die Timeouts weniger werden. Das war aber nicht der Fall. Ich habe es jetzt wieder auf 1 abgeändert.

Im Anhang das log mit verbose 5. Um 13:53:58 hab ich einen manuellen get von Power__W gemacht. Das hat sehr schnell funktioniert. Wert war 0 Watt, was richtig ist.

vielen dank!
Zwiebel

[StefanStrobel]

Hallo Zwiebel,

ich vermute dass Deine Probleme von einem zu hohen Combine-Wert für die Input-Register kommen.
Überschrieb doch mal die 40 aus dem sdm220-Modul per

Code Auswählen Erweitern


attr Trockner dev-i-combine 20


und erzeuge dann wieder ein Log wie Du es gerade gepostet hast.

Gruß
    Stefan

[Zwiebel]

Hallo Stefan,

du hattes recht es war der "combine "Wert! Nach dem das Attribute funktioniert hat habe ich es im Modul übernommen.
Jetzt habe ich keine timeouts mehr, und ich kann alles in verbose 3 laufen lassen ohne Probleme.

Im Anhang die verbose 5 logs und das abgeänderte Modul.

vielen dank für deine Hilfe!

Gruß
Zwiebel

[StefanStrobel]

Hallo,

ich habe gerade die neue Version eingecheckt.
Meldet Euch bitte falls es doch noch Probleme damit gibt.

Gruss
   Stefan

[Funnel]

Ein "update" führt bei mir nicht zur Aktualisierung deiner Module

[laserrichi]

kann ich bestätigen in der controls_fhem.txt  steht noch 2019  drin

[StefanStrobel]

Das dauert immer bis zum nächsten Tag bis die neuen Sachen aus dem SVN per update verteilt werden.

Gruss
   Stefan

[holle75]

Bezugnehmend auf https://forum.fhem.de/index.php/topic,75638.msg1110251.html#msg1110251 habe ich die letzten Tage versucht, meine Solaranlage in fhem zu implementieren.

Selten in den letzten Dekaden mit einer selbst gestellten Aufgabe so dermaßen gescheitert
Das ist dann doch hochgradig komplex.

Mein Problem ist noch immer, den Ansatz zu finden. Ich weiß nichtmal wonach ich suchen kann. "modbus 16bit HEX" hat mich nicht wirklich weitergebracht.

Auf einem Testsystem steckt der USB-RS485 Adapter der mit der Solaranlage verbunden ist.
Definiert sind zwei Devices:

Code Auswählen Erweitern

Internals:
   DEF        /dev/ttyUSB0@9600,8,E,1
   DeviceName /dev/ttyUSB0@9600,8,E,1
   EXPECT     idle
   FD         4
   FUUID      5ff9c3ef-f33f-c138-67ef-7277e323cb47cd25
   IODev      ModbusLine
   LASTOPEN   1610212035.22143
   MODE       master
   NAME       ModbusLine
   NOTIFYDEV  global
   NR         15
   NTFY_ORDER 50-ModbusLine
   PARTIAL   
   PROTOCOL   RTU
   STATE      opened
   SerialConn 1
   TYPE       Modbus
   devioLoglevel 3
   nextOpenDelay 60
   READ:
     BUFFER     
   READINGS:
     2021-01-09 18:07:15   state           opened
   REMEMBER:
     lrecv      1610215927.04427
   defptr:
     Studer485  10
Attributes:

und das ModbusAttr

Code Auswählen Erweitern

Internals:
   DEF        1 10
   FUUID      5ff9d4f6-f33f-c138-b74c-0d17d513dd4c86d7
   IODev      ModbusLine
   Interval   10
   MODBUSID   1
   MODE       master
   MODULEVERSION Modbus 4.3.11 - 2.1.2021
   NAME       Studer485
   NOTIFYDEV  global
   NR         16
   NTFY_ORDER 50-Studer485
   PROTOCOL   RTU
   STATE      opened
   TYPE       ModbusAttr
   READINGS:
     2021-01-09 18:53:25   state           opened
   lastRead:
Attributes:

LEDS am USB Stick blinken unregelmäßig und sekündlich bekomme ich Fehlermeldungen im Log:

Code Auswählen Erweitern

2021.01.09 19:13:45 3: ModbusLine: readfn got data while EXPECT was set to idle: 00000000
2021.01.09 19:13:45 3: ModbusLine: readfn got data while EXPECT was set to idle: 00ff0000
2021.01.09 19:13:45 3: ModbusLine: readfn got data while EXPECT was set to idle: e0000000
2021.01.09 19:13:45 3: ModbusLine: readfn got data while EXPECT was set to idle: 0000ff00


das finde ich schonmal schön, weil irgendjemand redet ja mit irgendwem. Auch wenn falsch und ich es nicht verstehe.

Dass ich dem Device Studer485 sagen muß, was es tun soll vermute ich. Drehe mich hier mit Versuchen seit 6 Stunden im Kreis.

Wie muß ich eine Abfrage eines HEX-Wertes definieren? Was ich habe ist ein Auszug der Doku der Solaranlage die wohl sehr verständlich beschreibt, wie man Werte ausliest .... nur leider bekomme ich die Transferleistung zum modbus Modul nicht hin. Auch finde ich vermeintlich kein Beispiel in der commandref oder im Forum was mir verständlich aufzeigt, wie man Hex sendet.

Könnte mal jemand auf die zwei angehängten Bilder schauen und mir einen Tip geben, wie ich eine HEX-Abfrage für einen Wert aufzubauen habe?

Auch verstehe ich nicht, welche ID die Solaranlage am Bus hat.

Der Ordnung halber auch noch die kompletten pdf-Files aus denen die Bilder extrahiert sind.

Danke für eure Hilfe.
H.

[pejonp]

@holle75

schau mal hier (https://github.com/studer-innotec/xcom485i) gibt es ein phyton-script zum auslesen über rs485. Vielelicht kommt da ja schon was.

und hier etwas Doku --> Open STUDER  (https://www.studer-innotec.com/de/downloads/)

Du fragst aber per Modbus-Modul noch kein Register ab ?!
Das ist jetzt nur ein Beispiel das nicht stimmen muss ;-(

Code Auswählen Erweitern


dev-h-combine 10
dev-h-defPoll 1
dev-h-defShowGet 1
enableControlSet 1
attr <DEVICE-NAME> obj-h30001-len 4
attr <DEVICE-NAME> obj-h30001-Test1
attr <DEVICE-NAME> obj-h30001-unpack (a16)


pejonp

[pejonp]

@holle75

hattes du die Lösung von @satprofie schon mal bei dir am laufen ? Da werden doch schon Werte ausgelesen.
Diese könnte man doch versuchen über MQTT nach FHEM zu senden. So könnte man das pyhton-Modul weiter nehmen. Oder man versucht es über ModBus.

Versuche mal die 30001 über ModBus RTU auszulesen.

pejonp