Neue Versionen und Support zum Modbus-Modul

[StefanStrobel]

Hallo privat58,

Entweder Du hast massive Störungen auf der Leitung oder Dein Adapter hängt auf einer falschen Leitung, über die ein anderes Gerät mit einem anderen Protokoll kommuniziert.
Evt. Ist auch de Adapter defekt.

Gruß
    Stefan

[privat58]

Danke Stefan, für die Antwort. Es geht wieder.
Ich hatte gestern noch einmal alles auseinander gerissen und habe die Zähler Stück für Stück wieder in Betrieb genommen. Als ich den letzten Zähler dran hatte ging wieder nichts. Es war der Teminierungswiderstand der sich verabschiedet hat. Danach hatte ich natürlich nicht gesucht und auch nicht damit gerechnet. Nachdem ich diesen ersetzt hatte, war alles wieder gut.
Vielen Dank.
Steffen

[Roger]

Hi Stefan,
Rudi ändert an den timern in fhem.pl --> die Daten meiner Modbus Geräte (über RS485) konnten nicht mehr ausgelesen werden.
Log.-Meldungen:

Code Auswählen Erweitern


2017.12.21 18:54:26 3: HA_Modbus_1: timeout waiting for fc 4 from id 1, Request was 010400c8002871ea (i200 / Voltage_L1_to_L2__V, len 40)
2017.12.21 18:54:24 3: HA_Modbus_1: timeout waiting for fc 4 from id 1, Request was 0104014e001e11e9 (i334 / THD_Voltage_L1_L2__prz, len 30)
2017.12.21 18:53:55 3: HA_Modbus_1: timeout waiting for fc 3 from id 2, Request was 02030058000245eb (h88 / Relay2_Energy_Type, len 2)
2017.12.21 18:53:53 3: HA_Modbus_1: timeout waiting for fc 3 from id 2, Request was 02030014000a85fa (h20 / Modbus_Node_adr, len 10)
2017.12.21 18:53:51 3: HA_Modbus_1: timeout waiting for fc 4 from id 2, Request was 02040050001cf1e1 (i80 / Energy_apparent__kVAh, len 28)
2017.12.21 18:53:49 3: HA_Modbus_1: timeout waiting for fc 4 from id 2, Request was 020400f0001e7002 (i240 / THD_Current_L1__prz, len 30)
2017.12.21 18:53:47 3: HA_Modbus_1: timeout waiting for fc 3 from id 2, Request was 0203002400080434 (h36 / System_Power__W, len 8)
2017.12.21 18:53:45 3: HA_Modbus_1: timeout waiting for fc 4 from id 2, Request was 020400000028f027 (i0 / Voltage_L1__V, len 40)
2017.12.21 18:53:43 3: HA_Modbus_1: timeout waiting for fc 4 from id 2, Request was 0204014e001e11da (i334 / THD_Voltage_L1_L2__prz, len 30)
2017.12.21 18:53:41 3: HA_Modbus_1: timeout waiting for fc 3 from id 2, Request was 0203000a000ae5fc (h10 / System_Type, len 10)
2017.12.21 18:53:39 3: HA_Modbus_1: timeout waiting for fc 4 from id 2, Request was 020400280028702f (i40 / CosPhi_L3__grd, len 40)
2017.12.21 18:53:37 3: HA_Modbus_1: timeout waiting for fc 4 from id 2, Request was 020400c8002871d9 (i200 / Voltage_L1_to_L2__V, len 40)
2017.12.21 18:53:35 3: HA_Modbus_1: timeout waiting for fc 4 from id 1, Request was 010400000028f014 (i0 / Voltage_L1__V, len 40)


Mit fhem.pl Version 15564 geht es noch.
Bitte schau es Dir mal an.

Roger

[noansi]

Hallo Stefan,

eventuell hängt Rogers Problem hiermit https://forum.fhem.de/index.php/topic,81365.msg734603.html#msg734603 und im SVN konkret https://svn.fhem.de/trac/changeset/15657/ worauf ich Dich ohnehin aufmerksam machen wollte wegen tiefgreifenderen Änderungsideen im Thread mit Änderungsbedarf bei 98_Modbus.pm.

Wie eng sind die Timinganforderungen und wie eng ist das Modbusmodul mit dem bisherigen Timerabarbeitungsverhalten verwoben?

Gruß, Ansgar.

[herrmannj]

@roger: in Arbeit.

[noansi]

Hallo Roger,

gibt es eventuell andere Gründe für Dein Problem?
Hast Du dem System was hinzu gefügt?

Mit mehr verbose könnte es klarer werden.

Gruß, Ansgar.

[crispyduck]

Hallo,

habe gerade ein Update ausgeführt und trotz fhem.pl 15657 bis jetzt keine Probleme.

Habe 3 Modbus Devices an einem USB-RS485 Adapter. 2xSDM630 wo ich alle Werte im 2 und 3 Minuten Takt abfrage und 1xArduino als Bewässerungscomputer.
Auf einem der SDM630 führe ich außerdem im 2 Sekundentakt ein get für einen Wert aus.

Lg,
crispyduck

[herrmannj]

Dankeschön!

Das entspricht auch eher dem erwarteten Verhalten

[StefanStrobel]

Hallo,

ich vermute dass das Problem nur auftritt wenn Daten mit "get" abgefragt werden. Dann läuft das in ModbusLD_ReadAnswer und dort wird der vorhandene Timer abgefragt.
Bei den normalen zyklischen Abfragen im Modbus-Modul geht alles über den regulären InternalTimer.

Gruss
   Stefan

[herrmannj]

hast Du eine Idee warum sich das Verhalten dort geändert hat ? 'Eigentlich' ist doch dort alles wie immer ?

[StefanStrobel]

Hallo,

anbei eine neue Version, bei der ich den Zugriff auf die intAt-Struktur ersetzt habe.
Damit sollte es hoffentlich keine Probleme mehr mit der Änderung bei internalTimer geben.
@Roger: kannst Du es trotz Weihnachtsvorbereitungen kurz testen?

Gruss / Thanx
   Stefan

[Roger]

Hi Stefan,
habe Deine neue Version, wo DU den Zugriff auf die intAt-Struktur ersetzt hast, eingespielt und auch die fhem.pl von heute (Version 15667) --> bisher läuft es. Aber der Abbruch kam auch nicht gleich.

Extra get-Befehle führe ich nicht durch, habe aber neben dem Modbus Modul für zwei SDM630 auch noch zwei Module für Modbus-Abfragen für einen Fronius-Wechselrichter über TCP am laufen.
siehe https://forum.fhem.de/index.php/topic,46685.0.html

Bisher lief es stabil 
aber wir/ihr werden es schon hinbekommen 
Roger

[Andy1981]

Hallo Zusammen und erstmal danke für die FHEM Modbus Module und den Support dazu.
Seit Juni habe ich das Modbus Modul mit einem Fronius WR über TCP am laufen, hat alles wunderbar und ohne Probleme funktioniert. Da es an Weihnachten ja meist etwas langweilig ist habe ich über die Feiertage 2 RS485 Zähler eingebaut (SDM220 und SDM630) Aufgrund eines fehlenden RS485 Adapters habe ich mir schnell einen Adapter aus einem FTDI232RL USB Modul und einem sn75176bp Transceiver zusammengebrutzelt. Das Ganze Gebilde habe ich dann an meinem Windows 10 PC mit einem Modbus Master Simulator getestet, erstaunlicherweise hat alles gleich funktioniert .
Also hab ich das ganze an meinen Raspi mit FHEM angeschlossen und konfiguriert und siehe da, die Daten Purzeln nur so herein .
Nach 3 Datenübertragungen dann auf einmal Funkstille . Sobald ich einen get Befehl abschicke wird dieser mit Timeout quittiert. In der Log Datei werden ebenfalls alle Zyklischen abfragen mit Timeout quittiert.

Also Oszi raus und mal schauen was am Bus so ab geht:
Zu meinem erstaunen sendet de Raspi Zyklisch die Anfragen und bekommt auch Antwort von den slaves, nur irgendwie bekommt der Raspi die Antwort nicht mit. Zum testen habe ich einen Slave mit FTDI232RL USB Modul und sn75176bp Transceiver auf einem Steckbrett gebastelt und in den Bus gehängt, diesen Slave habe ich jetzt wieder an meinem Windows 10 PC hängen. Mit HTerm sehe ich die Daten die von FHEM zyklisch gesendet werden und die Antworten der einzelnen slaves, die readings der slaves in FHEM werden jedoch nicht aktualisiert. Wenn ich bei FHEM das Modbus Device disable kurz auf "1" setzte und anschließend wieder auf "0", dann werden die readings der devices wieder für 2-3 Zyklen aktualisiert, so lange die Zyklische Abfrage funktioniert, geht auch die Abfrage über get. Anschließend fängt der Timeout wieder an.
Als weiteren Test habe ich das Modbus Device in FHEM deaktiviert und über die Konsole an den Anschlus ttyUSB0 geschickt:
Anfrage geht vom Raspberry raus, angesprochener Slave antwortet und die Antwort wird in der Raspberry Konsole angezeigt. Nach ca 2 Minuten geht zwar die Anfrage noch raus, der Slave antwortet auch weiterhin, aber es werden keine Daten mehr in der Konsole angezeigt.
So wie sich das ganze verhält würde ich sagen es gibt ein Problem mit dem FTDI Treiber am Raspberry. Momentan schließe ich einen Fehler im Modul oder meiner Hardware aus. Meine Linux Kenntnisse sind leider eher bescheiden, falls jemand eine Idee hat wie man das Problem weiter eingrenzen kann dann einfach melden, habe momentan noch alles als Testumgebung aufgebaut.

@Roger: Verwendest du ebenfalls einen FTDI Adapter?

Gestern bin ich mit FHEM vom Raspberry2 auf einen Raspberry3 umgezogen, das Problem ist genau das gleiche. FHEM und Betriebssytem sind auf dem aktuellen Stand vom 29.12.2017.
Ich habe jetzt mal ein paar verschiedene RS485 Adapter bestellt, mal schauen ob ich mit denen Erfolg habe. Werde mich melden sobald ich weitere Erkenntnisse zu dem Problem gesammelt habe.
Einen guten Rutsch in 2018 an alle

Gruß Andreas

[Andy1981]

Hallo Zusammen, ich habe noch ein paar gute Nachrichten (für mich) im alten Jahr .
Nach langem probieren und googeln bin ich auf das Problem mit den FTDI Chips gestoßen. Hier mal eine kurze Beschreibung wie ich das Problem umgehen konnte.
Putty Konsole öffnen und Befehl dmesg eingeben -> Solange die Kommunikation funktioniert steht hier noch nichts auffälliges drin, sobald die Readings in FHEM nicht mehr aktuallisiert wurden, wurde folgender Text ausgegeben:
ftdi_sio ttyUSB0: usb_serial_generic_read_bulk_callback - urb stopped: -32
Das Problem wird im Zusammenhang mit den FTDI Chips und Raspberry häufig diskutiert, als Workaround wird vorgeschlagen die USB Anschlüsse von USB2.0 auf USB1.1 Standard zu zwingen. Ich habe keine USB2.0 Geräte an meinem Raspberry hängen, also hab ich es gleich mal ausprobiert. Es muss nur in die /boot/cmdline.txt der Befehl dwc_otg.speed=1 eingefügt werden und anschließend ein reboot.
Seit der Änderung vor 5 Stunden quatscht FHEM im Intervall von 60s unaufhörlich mit den beiden Zählern, auch ein get zwischendurch bringt das System nicht aus dem Tritt.
In diesem Sinne nochmals einen guten Rutsch

Gruß Andreas

[crispyduck]

Hallo,

ja das Problem habe ich auch, allerdings nicht mit einem FTDI, sondern einem 3€ China RS485 Adapter. Siehe meinen Beitrag irgendwo weiter vorne in dem Thread.

Hab mit jetzt einen Digitus RS485 Adapter FTDI/FT232RL bestellt und eigentlich auch schon eine Woche hier rum liegen.

Bin gerade dabei auf diesen umzusteigen, aber irgendwie funktioniert momentan überhaupt nichts, bekomme keine Antwort. Eventuell liegt es daran das ich aktuell keine Abschlusswiderstände habe da damit der China Adapter überhaupt nicht ging. Mal schauen, was da los ist...

FYI: dwc_otg.speed=1, limits all USB devices (including the onboard network adaptor) to 12Mbps

Lg,
crispyduck



Am