Wer kann Helfen einen Modbus Fehler zu finden

[rico5588]

Hallo Ihr,

Ich betreibe seit 4 Wochen ein Modbus Netzwerk mit 3 Slave Geräten (2x Dimplex Lüftung und 1x Dimplex WPM2006)vor 3 Wochen hat ich schon einmal Probleme mit der Datenübertragung. Da hat ein Umstieg auf einen anderen USB Port am Raspi 2 geholfen (mir zwar unlogisch aber naja).
Seit dem 23.12. geht es nun wieder nicht mehr und ein Umstecken bringt nichts.
Hier mal eine Fehlermeldung aus dem Log.

Code Auswählen Erweitern

2016.12.27 09:48:32 5: ModbusLine: raw read: 53ff71fd87fb00
2016.12.27 09:48:32 5: ModbusLine: ParseFrames returned error: recieved frame from unexpected Modbus Id 83, expecting fc 3 from 100 for module DimplexWPManager
2016.12.27 09:48:32 4: ModbusLine: CheckDelay sendDelay for DimplexWPManager not over, try again in 0.687577962875366
2016.12.27 09:48:33 4: ModbusLine: HandleSendQueue sends fc 3 to 100, tid 0 for dimhp_time_hour (h133), len 1)
2016.12.27 09:48:33 5: SW: 6403008500019c16
2016.12.27 09:48:33 5: ModbusLine: raw read: 53fff5fdc73a
2016.12.27 09:48:33 5: ModbusLine: ParseFrames returned error: recieved frame from unexpected Modbus Id 83, expecting fc 3 from 100 for module DimplexWPManager
2016.12.27 09:48:33 4: ModbusLine: CheckDelay sendDelay for DimplexWPManager not over, try again in 0.687884092330933
2016.12.27 09:48:34 4: ModbusLine: HandleSendQueue sends fc 3 to 100, tid 0 for dimhp_trigger_starthour2 (h197), len 1)
2016.12.27 09:48:34 5: SW: 640300c500019dc2
2016.12.27 09:48:34 5: ModbusLine: raw read: 53ff75
2016.12.27 09:48:34 5: ModbusLine: raw read: fdc50f
2016.12.27 09:48:34 5: ModbusLine: ParseFrames returned error: recieved frame from unexpected Modbus Id 83, expecting fc 3 from 100 for module DimplexWPManager
2016.12.27 09:48:34 4: ModbusLine: CheckDelay sendDelay for DimplexWPManager not over, try again in 0.688215017318726
2016.12.27 09:48:34 4: ModbusLine: HandleSendQueue sends fc 3 to 100, tid 0 for dimhp_trigger_tuesday (h203), len 1)
2016.12.27 09:48:34 5: SW: 640300cb0001fc01

Code Auswählen Erweitern

2016.12.26 18:29:34 5: ModbusLine: raw read: 4c7f85fffd357f
2016.12.26 18:29:34 5: ModbusLine: ParseFrames returned error: recieved frame from unexpected Modbus Id 76, expecting fc 1 from 103 for module LueftungRico
2016.12.26 18:29:34 4: ModbusLine: CheckDelay sendDelay for LueftungRico not over, try again in 0.18903112411499
2016.12.26 18:29:35 4: ModbusLine: HandleSendQueue sends fc 1 to 103, tid 0 for dimzl_supplyairsensor_messages (c41), len 1)
2016.12.26 18:29:35 5: SW: 67010029000125c4

Komisch dabei ist, das die Modbus Adressen bei mir 101,102 und 103 sind und ich als Antwort scheinbar völlig komische werte erhalte (ID83, ID166 oder ID76).
Ich würde gern den Treiber neu Installieren, brauch dazu aber Hilfe!
Danke euch schonmal

Update:
Was alles nicht geholfen hat:
Neustart Fhem oder Raspi
Update Fhem oder Raspi
USb to RS485 Stick in neuen USB-Port
Neustart der Slave Devices (alle Dimplex Anlagen)

[OliWee]

Hm...

was passiert denn, wenn Du in der ModbusAttr-Konfig die ID mal auf 83 & Co. änderst?

[rico5588]

Die ID von der WPM ist auf 101 im Gerät eingestellt und auch auch in Fhem und ich erhalte die Antwort auf die ID 77.
Wenn ich die Id in Fhem auf 77 stelle erhalte ich ein Antwort von der ID 89.
Wenn ich die Id in Fhem auf 89 stelle erhalte ich ein Antwort von der ID 83.
.....

[StefanStrobel]

Sieht für mich wie ein Hardware-Problem aus.
Unabhängig von der Modbus-ID im ersten Bye der Antworten ist auch der Rest der Antworten nicht sinnvoll.
Vielleicht ist der RS 485 Adapter defekt oder die Verkabelung ist schuld.

Gruß
   Stefan

[rico5588]

Hallo Stefan,

da das aktuell meine einzige Chance ist habe ich mir 2 verschiedene neue USB Konverter bestellt. Eventuell könnt Ihr noch eine Empfehlung dazu abgeben. Gern auch eine Alternative dazu.
Typ1
http://www.ebay.de/itm/121974380677?_trksid=p2057872.m2749.l2649&ssPageName=STRK%3AMEBIDX%3AIT
Typ2
http://www.ebay.de/itm/181879799580?_trksid=p2057872.m2749.l2649&ssPageName=STRK%3AMEBIDX%3AIT

MFG Rico

[rico5588]

Problem Gelöst!!!!

Es war der USb to RS485 Stick.
Der neue geht einwandfrei....

Danke für die Hilfe.

[rico5588]

Leider Doch nicht...

Habe nun wieder jede menge Timeout reading answer fehler.
Habe eine andere Variante Sticks getestet aber irgentwie wird es nicht besser. Ich denke hier liegt ein Grundsätzliches Problem vor.
Nach einem Neustart von Fhem geht es mit dem neuen Stick ne Stunde...
Hier meine Konfikurierten Gerät in Fhem sowie meine Hardware.
Vielleicht erkennt jemand einen Grundsätzlichen Fehler.
Gerät1

Code Auswählen Erweitern

defmod DimplexWPManager ModbusRTUDimplexHP 101 250
attr DimplexWPManager userattr 1 IODev dev-timing-timeout event-on-change-reading maxTimeoutsToReconnect verbose
attr DimplexWPManager IODev ModbusLine
attr DimplexWPManager dev-timing-timeout 5
attr DimplexWPManager event-on-change-reading .*
attr DimplexWPManager maxTimeoutsToReconnect 3
attr DimplexWPManager room Dimplex,Modbus
attr DimplexWPManager verbose 0
Gerät 2

Code Auswählen Erweitern

defmod LueftungHermann ModbusRTUDimplexZL 102 300
attr LueftungHermann userattr 1 IODev dev-timing-timeout event-on-change-reading maxTimeoutsToReconnect verbose
attr LueftungHermann IODev ModbusLine
attr LueftungHermann dev-timing-timeout 5
attr LueftungHermann event-on-change-reading .*
attr LueftungHermann group LüftungHermann
attr LueftungHermann maxTimeoutsToReconnect 3
attr LueftungHermann room Dimplex,Modbus
attr LueftungHermann verbose 0
Gerät 3

Code Auswählen Erweitern

defmod LueftungRico ModbusRTUDimplexZL 103 300
attr LueftungRico userattr 1 IODev dev-timing-timeout event-on-change-reading maxTimeoutsToReconnect verbose
attr LueftungRico IODev ModbusLine
attr LueftungRico event-on-change-reading .*
attr LueftungRico group LüftungRico
attr LueftungRico maxTimeoutsToReconnect 3
attr LueftungRico room Dimplex
attr LueftungRico verbose 0
Modbusadapter

Code Auswählen Erweitern

defmod ModbusLine Modbus /dev/ttyUSB0@19200,8,N,1
attr ModbusLine queueDelay 3
attr ModbusLine queueMax 100
attr ModbusLine room Dimplex,Modbus
attr ModbusLine verbose 0

im Anhang noch mein  Verdrahtungsaufbau.
Und dieser USB to RS485 Wandler in den Einstellungen wie er gekommen ist...
Stick Versuch 1
http://www.ebay.de/itm/USB-to-RS485-RS-485-Converter-Adapter-fur-Arduino-Prototyping-Mikrocontroller-/272490914419?hash=item3f71b96273:g:pX8AAOSw44BYV6CZ
Und Versuch2
http://www.ebay.de/itm/USB-zu-RS485-TTL-Konverter-Adapter-FTDI-Schnittstelle-FT232RL-75-176-Module-/401195599350?_trksid=p2141725.m3641.l6368

Update1
im Log sind jetzt noch diese Fehler dazugekommen.
Diese waren mit dem alten Stick nicht da.

Code Auswählen Erweitern

2017.01.08 11:04:11 1: PERL WARNING: Use of uninitialized value $reqLen in multiplication (*) at ./FHEM/98_Modbus.pm line 652.
2017.01.08 11:04:11 1: PERL WARNING: Use of uninitialized value $proto in string eq at ./FHEM/98_Modbus.pm line 660.
2017.01.08 11:04:11 1: PERL WARNING: Use of uninitialized value $proto in string eq at ./FHEM/98_Modbus.pm line 669.
2017.01.08 11:04:11 1: PERL WARNING: Use of uninitialized value $proto in string eq at ./FHEM/98_Modbus.pm line 680.
2017.01.08 11:04:11 1: PERL WARNING: Use of uninitialized value in string eq at ./FHEM/98_Modbus.pm line 710.
2017.01.08 11:04:11 1: PERL WARNING: Use of uninitialized value $reqId in numeric ne (!=) at ./FHEM/98_Modbus.pm line 713.
2017.01.08 11:04:11 1: PERL WARNING: Use of uninitialized value $devAdr in numeric ne (!=) at ./FHEM/98_Modbus.pm line 713.
2017.01.08 11:04:11 1: PERL WARNING: Use of uninitialized value $fCode in numeric ne (!=) at ./FHEM/98_Modbus.pm line 717.
2017.01.08 11:04:11 1: PERL WARNING: Use of uninitialized value in numeric ne (!=) at ./FHEM/98_Modbus.pm line 717.
2017.01.08 11:04:11 1: PERL WARNING: Use of uninitialized value $fCode in numeric eq (==) at ./FHEM/98_Modbus.pm line 734.
2017.01.08 11:04:11 1: PERL WARNING: Use of uninitialized value $fCode in numeric eq (==) at ./FHEM/98_Modbus.pm line 738.
2017.01.08 11:04:11 1: PERL WARNING: Use of uninitialized value $fCode in numeric eq (==) at ./FHEM/98_Modbus.pm line 741.
2017.01.08 11:04:11 1: PERL WARNING: Use of uninitialized value $fCode in numeric eq (==) at ./FHEM/98_Modbus.pm line 746.
2017.01.08 11:04:11 1: PERL WARNING: Use of uninitialized value $fCode in numeric eq (==) at ./FHEM/98_Modbus.pm line 749.
2017.01.08 11:04:11 1: PERL WARNING: Use of uninitialized value $fCode in numeric lt (<) at ./FHEM/98_Modbus.pm line 753.
2017.01.08 11:04:11 1: PERL WARNING: Use of uninitialized value $fCode in concatenation (.) or string at ./FHEM/98_Modbus.pm line 754.
2017.01.08 11:04:11 1: PERL WARNING: Use of uninitialized value $fCode in concatenation (.) or string at ./FHEM/98_Modbus.pm line 755.

[StefanStrobel]

Hallo,

sorry für die späte Antwort. Ich schaue nur selten in dieses Unterforum, da die Modbus-Fragen meist unter "Sonstiges" kommen.

Hast Du in der Zwischenzeit mal ein update gemacht?
Die letzten Fehler in Deinem Log sehen nach einer älteren Modulversion aus.

Gruss
    Stefan

[fiedel]

Macht das Sinn direkt "defmod" anstatt "define" zu verwenden?
In der Ref. steht zwar "Define a device OR modify it", aber sowas habe ich noch nie gesehen...

Gruß
Frank

[rico5588]

Hallo Stefan,

ich hoffe/denke ich habe einen Teil vom Problem gelöst. Zumindest geht es seit einer Woche wieder...
Mein letzter Schritt war diesen Stick hier zu verwenden.
DIGITUS DA-70157
Dieser hat auch wie meine Slave Teilnehmer ein GND Anschluss (die vorherigen China Varianten hatte nur A+ und B-). Diesen habe ich jetzt noch mit angeschlossen.
Leider findet man im Netz sehr viele unterschiedliche Meinungen zum Aufbau einer Modbus Netzwerkes.
Z.B. gibt es noch den 5+ Anschluss, der aber nirgendwo beschrieben ist ob man den braucht oder nicht.
Ist also für nen Anfänger schwierig...
Updates mache ich regelmäsig( das letzte ist so 2 Tage her)

Dennoch passiert es immer wieder das befehle in einem Timeout nicht durchgestellt werden.
Eventuell die Warteschlange erhöhen (falls es das gibt)?
Könntest du diese beiden Attribute nochmal erklären (auf Deutsch)

Code Auswählen Erweitern

attr ModbusLine queueDelay 3
attr ModbusLine queueMax 100

MFG Rico

@fiedel
das mit dem Defmod liegt daran das ich es aus der RAW definition herauskopiert habe.
Richtig ist schon define...

[StefanStrobel]

Hallo Rico,

das klingt doch schon mal ganz gut.
Dass es gelegentlich mal einen Timeout gibt, ist vermutlich normal. Wenn es aber regelmäßig auftritt, würde ich das ModbusAttr-Gerät und das Modbus-Gerät auf Verbose 5 setzen und dann genau hinsehen, wann ein Request abgesetzt wird und ob / wann die Antwort kommt.
Manchmal steht dann ja im Log dass der Empfangspuffer doch schon etwas enthält.

queueDelay ist die Verzögerung, mit der das Gerät anstehende Requests in der Sende-Queue absendet, wenn es vorher keinen anderen Grund gab, die Queue weiter abzuarbeiten. Der Wert ist in der Praxis nicht wirklich relevant, da nach einem erfolgreichen oder mit Timeout / Fehler beendeten Empfang automatisch versucht wird die Queue weiter abzuarbeiten.

Relevanter sind da vor allem die Attribute clientSwitchDelay oder auf Ebene von ModbusAttr dev-timing-sendDelay und dev-timing-commDelay. Die werden tatsächlich geprüft und wenn die definierte Zeit nicht abgelaufen ist, wird mit dem nächsten Senden gewartet.

queueMax ist die Länger der Warteschlange für Requests, die gesendet werden sollen.

Gruss
    Stefan