Hilfe zu Modbus Fehler

Begonnen von rico5588, 09 März 2018, 16:21:44

Vorheriges Thema - Nächstes Thema

rico5588

Hallo Helfer,

ich hatte vor längerer Zeit schon einmal ein Probleme mit meinem Modbus Netzwerk.
Da ich nach wie vor Aussetzer habe, möchte ich nun gern versuchen, mit eurer Hilfe, diese zu beseitigen.
Worum gehts:
Es treten immer mal wieder Fehler in der Modbus Kommunikation auf, das heißt es werden Befehle nicht richtig abgesetzt oder aber es werden diverse Fehler im Log gespeichert.
Nach langem hin und her vermute ich das zu viele Informationen auf einmal gesendet werden und das führt dann zu Fehlern.
Erhöhe ich den Timeout wert, treten weniger Fehler im Log auf aber es werden auch nicht alle Befehle/abfragen gesendet.
Des weiteren erhalte ich jede menge Freeze, vermutlich ausgelöst von Modbus wodurch das gesamte System zwischen 2 und 5 sec hängt.

Fehler 1 - Unabhängig vom Gerät kommen solche Fehler
ModbusLine: timeout waiting for fc 1 from id 103, Request was 6701001c000135ca (c28 / dimzl_balance_messages, len 1)

Fehler 2 alles so ca. 20 mal nacheinander
Begrenzt man die Warteschlange kommt dieser Fehler
LueftungHermann: Send queue too long (11), dropping new request
LueftungRico: Send queue too long (11), dropping new request


Modbusdevice
defmod ModbusLine Modbus /dev/serial/by-id/usb-FTDI_FT232R_USB_UART_A504YC9S-if00-port0@19200,8,N,1
attr ModbusLine dropQueueDoubles 1
attr ModbusLine group Modbus
attr ModbusLine maxTimeoutsToReconnect 5
attr ModbusLine profileInterval 60
attr ModbusLine room Technik--Dimplex


Gerät 1
defmod DimplexWPManager ModbusRTUDimplexHP 101 2000
attr DimplexWPManager userattr 1 DbLogInclude IODev dev-timing-timeout event-min-interval event-on-change-reading queueMax verbose
attr DimplexWPManager IODev ModbusLine
attr DimplexWPManager event-min-interval .*:10000,dimhp_input_sgready_red:600,dimhp_input_sgready_green:600,dimhp_temperature_dhw:600,dimhp_temperature_return:600,dimhp_temperature_returnset:600,dimhp_temperature_flow:600
attr DimplexWPManager event-on-change-reading dimhp_input_sgready_red,dimhp_input_sgready_green,dimhp_temperature_dhw,dimhp_temperature_return,dimhp_temperature_returnset,dimhp_temperature_flow
attr DimplexWPManager group Modbus
attr DimplexWPManager queueMax 40
attr DimplexWPManager room Technik--Dimplex


Gerät 2
defmod LueftungHermann ModbusRTUDimplexZL 102 86000
attr LueftungHermann userattr 1 DbLogInclude IODev dev-timing-timeout event-min-interval event-on-change-reading queueMax verbose
attr LueftungHermann IODev ModbusLine
attr LueftungHermann dev-timing-timeout 10
attr LueftungHermann event-min-interval .*:600
attr LueftungHermann event-on-change-reading dimzl_operatingmode.*
attr LueftungHermann group Modbus,LüftungHermann
attr LueftungHermann queueMax 10
attr LueftungHermann room Technik--Dimplex


Gerät 3
defmod LueftungRico ModbusRTUDimplexZL 103 86000
attr LueftungRico userattr 1 DbLogInclude IODev dev-timing-timeout event-min-interval event-on-change-reading queueMax verbose
attr LueftungRico IODev ModbusLine
attr LueftungRico event-min-interval .*:600
attr LueftungRico event-on-change-reading dimzl_operatingmode.*
attr LueftungRico group LüftungRico,Modbus
attr LueftungRico queueMax 10
attr LueftungRico room Technik--Dimplex


Update1
Habe nun festgestellt wenn Anfrage von 2 oder 3 Geräten gleichzeitig abgefragt werden endsteht ein Freez von bis zu 12 sec...
Anbei noch ein Log von Freezemon.

MFG Rico
Geht nicht gibt's nicht.
NUC-I3+Proxmox, Fritzbox 7590 AX, Synology DS414
Dimplex Wärmepumpe, Lüftungsanlage, Solarlog 1200
HM,IT,Lacross,EspEasy,Modbus,MQTT2, Freund von Shelly

StefanStrobel

Hallo Rico,

gelegentliche Timeouts kommen bei einer RS485-Verbindung schon vor. Das kann an Störungen, schlechter Terminierung, den Sticks, Timing o.ä. liegen.
Unabhängig davon denke ich dass bei Dir evt. zu viele Werte in einer zu kurzen Zeitspanne abgefragt werden. Auf was für eine Hardware läuft denn Dein Fhem? Eventuell hat das auch noch einen Einfluss, Insbesondere auf die "Freezes".

Ich habe mir das Modul gerade mal angesehen:
https://forum.fhem.de/index.php/topic,33086.45.html (ich hoffe das ist das aktuelle)
Da sind schon recht viele Register definiert. Wenn bei einem Update alle definierten Register durchgegangen und bei Bedarf in die Queue gestellt werden, dann kann das auf schwacher Hardware eine Weile dauern. Insbesondere wenn dann gleich zwei oder drei Geräte dran sind.

Die Warteschlange zu begrenzen ist da keine gute Idee. Wenn das Basismodul seinen zyklischen Update macht, kann es vorkommen, dass mehr Register in die Abfrage-Warteschlange müssen, als dort reinpassen. Dann kommen entsprechende Fehlermeldungen. Ich würde die Queue daher eher auf 200 hochsetzen als auf 10 begrenzen.

Im Modul sind einige Register mit pollDelay 30, 60 oder sogar 3600 definiert. Wenn Du nun aber das Abfrage-Intervall auf 86000 setzt, dann werden einmal am Tag auch alle bis dahin fälligen Register abgefragt.

Mir ist auch aufgefallen, dass im Modul kein "combine" für die Register erlaubt wird. Ich kenne das Gerät nicht, aber die meisten Geräte erlauben es in einem Modbus-Request gleich mehrere Register abzufragen. Das Modbus-Basis-Modul erlaubt das und dadurch wird alles ein wenig effizienter.
Mit den Attributen von ModbusAttr kannst Du das noch machen. Die sind alle auch für das ModbusRTUDimplexHP möglich.

Wenn Du verbose für Deine Modbus-Module und das Basis-Modul auf 5 setzt, dann kannst Du genau sehen, was wo wie lange dauert.

Gruss
  Stefan

rico5588

Hallo Stefan,

dank schon ml für deine Unterstützung....
Fhem läuft bei mir auf einem Raspi 2 (Server started with 681 defined entities)
Ich habe nun mal meinen Stresstestdoif gestartet und dabei alle 4 Geräte auf Verbose 5 gestellt. siehe Anhang.
Eventuell ist wirklich die Hardware am ende...ich habe bis jetzt am heutigen Tag 640 Freeze gehabt...
Kann ich das
ZitatMir ist auch aufgefallen, dass im Modul kein "combine" für die Register erlaubt wird.
selber anpassen um es zu testen?

--> Queuemax habe ich nun auf 200 in jedem Modbus Slvae Gerät.

MFG Rico

Geht nicht gibt's nicht.
NUC-I3+Proxmox, Fritzbox 7590 AX, Synology DS414
Dimplex Wärmepumpe, Lüftungsanlage, Solarlog 1200
HM,IT,Lacross,EspEasy,Modbus,MQTT2, Freund von Shelly

rico5588

#3
Habe Gerate noch etwas gefunden in der Anleitung von Dimplex WärmepumpenManager.
Zu beachten ist, dass an der Erweiterung über 100 Variablen übertragen werden können, die einzeln oder auch komplett ausgelesen an ein übergeordnetes Bus-System übergeben werden können.

Und hier ein auszug aus der Anleitung der Lüftungsgeräte Dimplex ZL Modbus.
Pro Telegramm können max. 64 Register abgefragt werden.

Wie kann ich "Combine" testen, was müsste im Modul geändert werden?
Geht nicht gibt's nicht.
NUC-I3+Proxmox, Fritzbox 7590 AX, Synology DS414
Dimplex Wärmepumpe, Lüftungsanlage, Solarlog 1200
HM,IT,Lacross,EspEasy,Modbus,MQTT2, Freund von Shelly

rico5588

Hallo Stefan,

ich glaube ich habe das Combine gefunden und zu Testzwecken mal auf 50 (in beiden Modulen und für c und h gesetzt.)

Anbei noch ein auszug aus dem log.
Geht nicht gibt's nicht.
NUC-I3+Proxmox, Fritzbox 7590 AX, Synology DS414
Dimplex Wärmepumpe, Lüftungsanlage, Solarlog 1200
HM,IT,Lacross,EspEasy,Modbus,MQTT2, Freund von Shelly

StefanStrobel

Hallo Rico,

im Log sieht alles was mit 98_Modbus.pm zusammen hängt gut aus. Die Zusammenfassung der Requests scheint gut zu funktionieren und es gehen deutlich weniger Anfragen an die Wärmepumpen.
Wenn Du die Zeiten im Log verfolgst, dann entstehen hier auch keine Freezes.

In der ersten Zeile des Logs siehst Du wie GetUpdate von einem internen Timer aus Fhem für das Gerät DimplexWPManager aufgerufen wird. Bis Zeile 146 im Log werden die verschiedenen Objekte durchgegangen und geprüft, ob sie abgefragt werden müssen. Ab 147 versucht das Modul dann Objekte in einen gemeinsamen Request zu kombinieren.
Ab 217 werden dann die Requests in die Send-Queue gestellt. Das geht bis Zeile 259 und hat insgesamt ca. eine halbe Sekunde gedauert. Insgesamt stehen dann nur 6 Requests in der Queue. Die anderen sind darin enthalten. Das Modbus-Modul gibt die Kontrolle an dieser Stelle an fhem.pl zurück.

In Zeile 260 ruft Fhem wieder GetUpdate aus einem Timer auf, diesmal für das Gerät LueftungHermann.
Dort wiederholt sich das obige Spiel bis Zeile 377. Es sind diesmal ca. 0,7 Sekunden vergangen.

Dann passiert das gleiche für das Gerät LueftungRico bis Zeile 499 bzw. in ca 0,2 Sekunden. Danach geht wie immer die Kontrolle an fhem.pl zurück.

In Zeile 503 (nochmal ca. 0,6 Sekunden später) wird die Read-Routine des Moduls von Fhem aus aufgerufen und die Antwort auf den ersten gesendeten Request wird gelesen. Dieser enthält 49 Register, die danach geparsed werden.

Das geht bis Zeile 633 im Log. Aus den gelesenen 49 Registern werden einige nicht benötigt und nur 9 Objekte Readings zugewiesen. Das ganze hat dann ca. 0,3 Sekunden gedauert. Hier sieht man den Effekt des Combine-Attributs gut. Statt 9 einzelnen Requests wurde ein einziger mit 49 Registern verwendet.

Danach wird die Send-Queue weiter abgearbeitet und der nächste Request gesendet.
Danach ist wieder fhem.pl dran.

In Zeile 646 ruft fhem wieder die Read-Routine auf und die nächste Antwort wird gelesen und geparsed.
In Zeile 724 wird geprüft ob der nächste Request schon gesendet werden kann. Die definierte Wrtezeit zwischen dem letzten Lesen und dem nächsten Senden ist jedoch noch nicht abgelaufen und deshalb setzt das Modul einen neuen Timer und gibt die Kontrolle wieder an fhem.pl zurück.

In Zeile 727 wird die Routine zum Abarbeiten der Queue dann wieder aufgerufen und jetzt kann gesendet werden.

In 728 meldet sich dann Dein Freeze Monitor.
Das Modbus-Modul hat bis hier immer brav innerhalb von weniger als einer Sekunde die Kontrolle an fhem zurück gegeben. Dazwischen waren andere Module dran.

In Zeile 729 werden andere Geräte / Module genannt:
2018.03.10 14:36:59 1: [Freezemon] myFreezemon: possible freeze starting at 14:36:58, delay is 1.76 possibly caused by ModbusTCPServer_Poll(N/A) WifiLight_HighLevelCmdQueue_Exec(LEDKueche) WifiLight_LowLevelCmdQueue_Send(LEDKueche) CUL_HM_procQs(N/A) HEOSMaster_FirstRun(DenonAVR2400RicoHEOSMaster) HEOSPlayer_GetPlayerInfo(HEOSPlayer696593224) HEOSPlayer_GetPlayState(HEOSPlayer696593224) HEOSPlayer_GetMute(HEOSPlayer696593224) Modbus_HandleSendQueue(N/A) HEOSPlayer_GetQueue(HEOSPlayer696593224) HttpUtils_Err(N/A) Modbus_TimeoutSend(N/A) HttpUtils_Err(N/A)

Die würde ich mal näher ansehen.

Gruss
   Stefan

rico5588

Hallo Stefan,

nach langem hin und her, Timeouts hoch und runter, anpassen von Quemax und Combine in beiden Richtungen....
Kann ich sagen das das alles mehr oder weniger nichts gebracht.(in meinem Fall)
Hatte dann noch einen Gedanke.
Ich hatte bei allen 3 Geräten im Define das Intervall immer auf gleichen werten.
Mal alle auf 2000 oder alle auf 3000 etc.
Und immer wieder Timeout Fehler.
Seit 1 Woche habe unterschiedliche Werte (2567 sec,2987 sec und 1700 sec) und siehe da keine Timeouts mehr.
(Fast keine, nur einmal nach einem Neustart von Fhem, danach nicht wieder.)
Ich vermute daher das Wiederkehrende Anfragen und diese auch noch immer zur selben Zeit von verschiedenen Geräten das Problem sind und somit das "Umstellen/Abfragen" von einem Gerät aufs andere nicht sauber geht...oder die Pause sehr viel länger sein muß.

Wie auch immer, für mich hoffentlich, hat sich der Fall gelöst.
MFG Rico
Geht nicht gibt's nicht.
NUC-I3+Proxmox, Fritzbox 7590 AX, Synology DS414
Dimplex Wärmepumpe, Lüftungsanlage, Solarlog 1200
HM,IT,Lacross,EspEasy,Modbus,MQTT2, Freund von Shelly

StefanStrobel

Hallo Rico,

hast Du auch die dafür vorgesehenen delay-Attribute getestet?

im logischen Device:
dev-timing-sendDelay
dev-timing-commDelay

im physischen Device:
busDelay
clientSwitchDelay

die sind eigentlich genau für solche Fälle da :-)

Gruss
   Stefan

rico5588

In welchen Größen gibt mann hier Werte an?
5,10,100,Sekunden?
Geht nicht gibt's nicht.
NUC-I3+Proxmox, Fritzbox 7590 AX, Synology DS414
Dimplex Wärmepumpe, Lüftungsanlage, Solarlog 1200
HM,IT,Lacross,EspEasy,Modbus,MQTT2, Freund von Shelly

StefanStrobel

Hallo Rico,

Die Attribute werden in Sekunden angegeben. Ich würde Werte zwischen 0,5 und 3 testen im im Log mit verbose 5 zusehen was passiert.

Gruß
    Stefan

rasti

Hallo,
ich bin auch gerade am rumspielen mit den Delay Parametern bei Modbus-Auslese.

Was ist denn jetzt der Unterschied zwischen den Delays dev-timing-sendDelay unf dev-timing-commDelay ?

Ich habe 6 Modbusteilnehmer (SDM 72 und SDM 230) wo ich alle 5 Sekunden 7 Register abfrage.

Was wären denn da sinnvolle Einstellungen für die Delayparameter ?
Nur dev-timing-sendDelay oder nur dev-timing-commDelay oder beides oder ???

Viele Grüße

Ralf

StefanStrobel

Hallo rasti,

sendDelay ist für eine garantierte Pause zwischen zwei Requests an den gleichen Slave (=Server)
commDelay ist für eine garantierte Pause zwischen der letzten Kommunikation mit dem selben Device, also typischerweise zwischen der letzten Antwort und dem nächsten Request.
Ob die Delays überhaupt nötig sind und wie groß sie sein sollten hängt vom Device ab. Da gibt es leider keine allgemeinen Regeln.

Gruss
   Stefan