NEWS
Modbus adapter
-
Bei mir schmiert wie bei t-henrichsmann die kommunikaton immer wieder ab.
Schon mehrere adapter probiert.
Geschwindigkeiten, parameter, etc.
mehr bekomme ich aus dem log nicht raus und werde nicht schlau.
modbus.0 2019-01-13 21:49:45.997 info Connected to slave
modbus.0 2019-01-13 21:49:45.989 debug connect to serial /dev/ttyUSB0 with 115200
modbus.0 2019-01-13 21:49:43.991 silly inMem message modbus.0.* modbus.0.info.connection
modbus.0 2019-01-13 21:49:43.991 debug Cleaning up request fifo.
modbus.0 2019-01-13 21:49:43.990 debug Clearing timeout of the current request.
modbus.0 2019-01-13 21:49:43.986 info Disconnected from slave
modbus.0 2019-01-13 21:49:42.989 silly inMem message modbus.0.* modbus.0.info.connection
modbus.0 2019-01-13 21:49:42.984 warn Poll error count: 3 code: {"err":"timeout"}
modbus.0 2019-01-13 21:49:42.984 error Request timed out.
modbus.0 2019-01-13 21:49:42.984 warn Error: undefined
modbus.0 2019-01-13 21:49:40.990 silly inMem message modbus.0.* modbus.0.info.connection
modbus.0 2019-01-13 21:49:40.986 debug Poll holdingRegs DevID(10) address 4354 - 1 bytes
modbus.0 2019-01-13 21:49:40.986 debug Poll device 10
modbus.0 2019-01-13 21:49:40.984 info Connected to slave
modbus.0 2019-01-13 21:49:40.976 debug connect to serial /dev/ttyUSB0 with 115200
modbus.0 2019-01-13 21:49:38.979 silly inMem message modbus.0.* modbus.0.info.connection
modbus.0 2019-01-13 21:49:38.979 debug Cleaning up request fifo.
modbus.0 2019-01-13 21:49:38.978 debug Clearing timeout of the current request.
modbus.0 2019-01-13 21:49:38.973 info Disconnected from slave
modbus.0 2019-01-13 21:49:37.977 silly inMem message modbus.0.* modbus.0.info.connection
modbus.0 2019-01-13 21:49:37.973 warn Poll error count: 2 code: {"err":"timeout"}
modbus.0 2019-01-13 21:49:37.973 error Request timed out.
modbus.0 2019-01-13 21:49:37.971 warn Error: undefined
modbus.0 2019-01-13 21:49:35.974 silly inMem message modbus.0.* modbus.0.info.connection
modbus.0 2019-01-13 21:49:35.969 debug Poll holdingRegs DevID(10) address 4354 - 1 bytes
modbus.0 2019-01-13 21:49:35.969 debug Poll device 10
modbus.0 2019-01-13 21:49:35.969 info Connected to slave
modbus.0 2019-01-13 21:49:35.967 debug connect to serial /dev/ttyUSB0 with 115200
modbus.0 2019-01-13 21:49:33.964 silly inMem message modbus.0.* modbus.0.info.connection
modbus.0 2019-01-13 21:49:33.964 debug Cleaning up request fifo.
modbus.0 2019-01-13 21:49:33.963 debug Clearing timeout of the current request.
modbus.0 2019-01-13 21:49:33.957 info Disconnected from slave
modbus.0 2019-01-13 21:49:32.958 silly inMem message modbus.0.* modbus.0.info.connection
modbus.0 2019-01-13 21:49:32.952 warn Poll error count: 1 code: {"err":"timeout"}
modbus.0 2019-01-13 21:49:32.952 error Request timed out.
modbus.0 2019-01-13 21:49:32.952 warn Error: undefined
modbus.0 2019-01-13 21:49:30.945 debug Poll holdingRegs DevID(10) address 20507 - 1 bytes
modbus.0 2019-01-13 21:49:30.936 silly inMem message modbus.0.* modbus.0.holdingRegisters.4362_SUPP_FAN_SPEED
modbus.0 2019-01-13 21:49:30.932 debug Poll holdingRegs DevID(10) address 4609 - 1 bytes
modbus.0 2019-01-13 21:49:30.914 debug Poll holdingRegs DevID(10) address 4362 - 1 bytes
modbus.0 2019-01-13 21:49:30.898 debug Poll holdingRegs DevID(10) address 4361 - 1 bytes
modbus.0 2019-01-13 21:49:30.881 debug Poll holdingRegs DevID(10) address 4360 - 1 bytes
modbus.0 2019-01-13 21:49:30.872 silly inMem message modbus.0.* modbus.0.holdingRegisters.4358_TEMP_SUPPLY_AIR
modbus.0 2019-01-13 21:49:30.868 debug Poll holdingRegs DevID(10) address 4359 - 1 bytes
modbus.0 2019-01-13 21:49:30.861 silly inMem message modbus.0.* modbus.0.holdingRegisters.4357_TEMP_SUPPLY_CELL_AIR
modbus.0 2019-01-13 21:49:30.860 silly inMem message modbus.0.* modbus.0.holdingRegisters.4356_TEMP_OUTDOOR_AIR
modbus.0 2019-01-13 21:49:30.852 debug Poll holdingRegs DevID(10) address 4358 - 1 bytes
modbus.0 2019-01-13 21:49:30.836 debug Poll holdingRegs DevID(10) address 4357 - 1 bytes
modbus.0 2019-01-13 21:49:30.818 debug Poll holdingRegs DevID(10) address 4356 - 1 bytes
modbus.0 2019-01-13 21:49:30.803 debug Poll holdingRegs DevID(10) address 4355 - 1 bytes
modbus.0 2019-01-13 21:49:30.794 debug Poll holdingRegs DevID(10) address 4354 - 1 bytes
modbus.0 2019-01-13 21:49:30.792 debug Poll device 10
modbus.0 2019-01-13 21:49:25.768 debug Poll holdingRegs DevID(10) address 20507 - 1 bytes
-
Hallo zusammen,
sorry für die späte Antwort, ich war jetzt eine Zeit lang raus. Leider gibt es auch nicht viel neues bei mir. Ich habe die Verbindung zu der Vallox Anlage noch nicht ans laufen bekommen. Gefühl läuft es besser, um so höher die Baud Rate ist. Aber selbst mit 115000 schmiert der Adapter nach max. 3 bis 4 Stunden ab. Manchmal dauert es aber auch nur 15 Minuten. Ich habe mir auch schon einen anderen USB Adapter besorgt, aber das brachte auch nichts. Evtl. versuche ich es die Tage nochmal mit einem CAT 7 Kabel. Im Moment habe ich ein geschirmtes J-Y(ST)Y Kabel. Ich glaube zwar nicht das es daran liegt, aber viel mehr fällt mir nicht mehr ein.
Eine Frage zum Adapter hätte ich noch. Wenn ich mit einem anderen Programm eine sekündliche Abfrage starte, habe ich bei ca. 50.000 Abfragen auch ca. 40 bis 50 Timeout Fehler. Das sind aber immer nur einzelne Abfragen die nicht funktionieren. Bedeutet, wenn in einer Sekunde keine Daten kommen, sind diese in der nächsten Sekunde wieder verfügbar. Der Modbus Adapter disconnected sich immer und verbindet sich aber anscheinend danach nicht wieder. Gibt es da evtl. noch eine Einstellung für, wie sich der Adapter bei einem Timeout/Reconnect verhält?
Viele Grüße
-
Hallo zusammen,
seid ein paar Tagen habe ich keine Verbindung des Modbus Adapter mehr zu meinem Wechselrichter.
modbus.0 2019-01-19 20:09:57.485 warn On error: {"code":"EHOSTUNREACH","errno":"EHOSTUNREACH","syscall":"connect","address":"192.168.1.165","port":1502}
modbus.0 2019-01-19 20:09:57.485 error Client in error state.
modbus.0 2019-01-19 20:09:57.484 error Socket Error
Das sind die Fehlermeldungen. Ich kann auf der entsprechenden Adresse mit anderen Tools die Register auslesen.
Jemand eine Idee?
Grüße,
Hideloop
(Adapter entfernt / neu installiert / mehrfach neu gestartet)
Hm … es liegt wohl an meiner IOBroker Installation bzw. der Modbus Installation auf diesem. Ich habe gerade einfach einen neuen auf meinem Win
System aufgesetzt und da kann ich die Werte auslesen.
-
Hallo.
Ich hänge mich auch mal hier rein.
Also ich habe gestern eine Modbus RTU Verbindung zu einem überlagerten System aufgebaut.
Testweise tausche ich erstmal nur ein Bit aus.
Das funktioniert. Am Raspberry betreibe ich den auch hier schon öfter genannten Digitus USB->RS485 Adapter.
Bei meiner Installation läuft der ioBroker derzeit als Master.
Ist das bei serieller Verbindung nicht möglich, den ioBroker als Slave zu betreiben?
-
Hallo.
Ich hänge mich auch mal hier rein.
Also ich habe gestern eine Modbus RTU Verbindung zu einem überlagerten System aufgebaut.
Testweise tausche ich erstmal nur ein Bit aus.
Das funktioniert. Am Raspberry betreibe ich den auch hier schon öfter genannten Digitus USB->RS485 Adapter.
Bei meiner Installation läuft der ioBroker derzeit als Master.
Ist das bei serieller Verbindung nicht möglich, den ioBroker als Slave zu betreiben? `
Ich habe zwei PI‘s als Slave die MODBUS RTU Seriel nutzen.
-
Bei mir kann ich, wenn ’Serial‘ gewählt ist, nicht von ’Master’ auf ’Slave’ umstellen.
18084_5545d6f6-a762-4ddd-9feb-43f9136ebdd4.jpeg -
Ok.
Dann reden wir über etwas anderes.
Bei mir ist die Modbus Instanz immer der MASTER und das Gerät welches ich Auslese quasi der Slave.
Meine PIs laufen als Slaves in einer ioBroker Multihost Umgebung.
Warum willst das die Instanz als Slave laufen lassen?
Gesendet von iPhone mit Tapatalk Pro
-
Ok. Danke für die Info.
Ich benutze ein übergeordnetes System, was ich lieber als Modbus-Master betreiben würde.
Ich möchte den ioBroker quasi als Datensammler bzw. Gateway benutzen. Sodass die eigentlichen Funktionen übergeordnet bearbeitet werden.
Wenn nun weitere Geräte/2.ioBroker dazu kommt, wird es schwieriger diese Signale an das übergeordnete System durchzureichen.
-
Hier ist ein ähnliches Problem.
Modbus Adapter in aktueller Version mit einem Energiezähler (SDM120 von B+G) (soll an sich mal mehr werden).
Die Kommunikation läuft auch nach dem Start des Adapters sauber. Irgendwann gibt es dann timeouts und nichts geht mehr. Lasse ich den Adapter einfach in Ruhe, wird irgendwann wieder kommuniziert. Die genauen Zeitlichen Abstände oder einen Zusammenhang konnte ich leider noch nicht ausmachen.
Hat dazu noch jemand eine Idee? Aufgrund der teilweise Stundenlangen funktionalität bin ich geneigt erst mal Kabel oder Widerstände auszuschließen. Oder denke ich da zu kurz?
Genutzt wird hier ein RS485 HAT auf einem Raspberry im Slave betrieb.
Ich habe jetzt auch mal einen RS485 USB Stick bestellt. Dann kann ich mal direkt an den Iobroker Master unter Debian gehen.
Haben die Leute mit den Verbindungsabbrüchen auch immer Raspberrys im Einsatz? Und was nutzen die, bei denen es problemlos läuft?
-
Ich habe PI's im Einsatz und immer den Stick von Digitus. Dazu Verbindung mit CAT6 Kabel und Anschlußwiderstände. `
Ich habe mir jetzt zusätzlich auch den Digitus Stick bestellt. Vielleicht muss ich auch noch 120 Ohm Widerstände besorgen. Ich habe momentan je 2 Widerstände mit rechnerisch 121 Ohm… aber das sollte ja nicht weiter relevant sein.
Ist es eigentlich egal welche Art Widerstand man verwendet?
-
Hi!
Der Modbus Adapter trennt ja relativ fix die Verbindung wenn ein Fehler aufgetreten ist. So auch bei Registern die aktuell nicht geschrieben werden können. Bei meinem Zähler muss vorher das Schreiben am Zähler temporär aktiviert werden.
Sobald der Schreibvorgang fehlschlägt, ist die Verbindung weg. Damit kann ich leben. Leider wird dann aber auch nicht neu verbunden. Erst wenn ich den Adapter neu starte, läuft die Kommunikation wieder.
Ist das beabsichtigt, bzw. muss das so? Ich glaube das dies auch bei jedem anderen Fehler der Fall ist. Das sorgt früher oder später zu einem Kommunikationsabbruch. Eventuell ist das ein Problem des Adapters? Oder Generell ein Modbus "Feature"?
Edit: Kann es sein, dass der Raspberry zwischendurch den /dev/ttyAMA0 für eine andere Anwendung missbraucht und deswegen die Verbindung abbricht? Und bei einem Neustart des Adapters holt sich iobroker das Interface wieder? die Serielle Konsole habe ich schon deaktiviert, aber sonst wüsste ich nicht wo und wie ich suchen soll….
-
Hallo Wendy!
Da ich so wie Du B+G Energiezähler abfrage, aber dabei leider nicht so erfolgreich bin:
Kannst Du hier nochmal deine aktuellen Einstellungen schicken? Einmal die Adaptereinstellungen und auch mal Beispielhaft die Register.
Ich habe in einem anderen Beitrag von dir gelesen, dass Du die "Holding register" nutzen musst damit es geht. Leider erhalte ich da zwar keine Fehler, aber auch nur "0" als Wert.
Mit den Input Registern erhalte ich Werte, aber nach einer gewissen Zeit verliert der Adapter die Verbindung und kann nicht neu verbinden.
Ich habe sämtliche Hardware Varianten durch. Den Digitus Adapter, diverse Kabel, Widerstände sind auch drin… Ich weiss einfach nicht mehr woran es liegen soll. Mittlerweile glaube ich schon an einen Fehler des Adapters, aber dann dürfte es bei Dir ja nicht gehen.
btw: Welchen Zähler genau liest Du aus? Ich habe hier aktuell diverse SDM120 zum testen...
Warum kann der Adapter sich nicht neu verbinden? Es gibt einen Fehler... OK... aber warum muss ich den kompletten Adapter neu starten? Was wird beim Neustart gemacht, was nicht auch beim wiederherstellen der Verbindung passieren kann?
-
Werde versuchen das morgen zu erledigen…
Hoffentlich vergesse ich das nicht [emoji51]
Gesendet von iPhone mit Tapatalk Pro `
Ich werde dich notfalls dezent erinnern! :lol:
Vielen Dank schon mal!
-
Danke für die Screenshots!
Läuft der Adapter bei Dir schmerzfrei durch, oder machst Du automatische Neustarts?
Ich bekomme einfach keine Kommunikation hin, die länger als ein paar Minuten steht.
Unter windows kann ich den Zähler abfragen wie ich will, das juckt den nicht. Der Adapter scheint irgendwo nicht ganz rund zu laufen. Ich habe nur keinen blassen Schimmer wo…
-
Ich habe jetzt mal einen RS485 Converter an meine Windows 10 VM durchgereicht und dort mit dem Tool QModMaster den Zähler permanent abgefragt.
Das klappt genauso wie in IOBroker eine Weile ohne Probleme. Irgendwann (einer in mehreren Minuten) ist mal ein Poll dazwischen, der in ein Timeout läuft. Hier pollt QModMaster aber einfach weiter und der nächste Poll ist direkt wieder erfolgreich.
An diesem Punkt scheint mit dem Modbus Adapter irgendwas falsch zu sein. Denn sobald hier ein Timeout erfolgt, gehen alle folgenden Abfragen schief und der Adapter muss erst neu gestartet werden.
Vielleicht kann ja einer der Entwickler mal was dazu sagen. Ist es wirklich ein "Design Problem" in dem Adapter? Ich habe mal bei Guthub ein Issue aufgemacht… Vielleicht ist es keiner, aber ich kann es anders nicht mehr erklären...
Lasse ich größere Abstände zwischen den Abfragen, läuft es tendenziell länger. Allerdings verringert das offensichtlich einfach nur die Wahrscheinlichkeit für ein Timeout.
415
Online32.4k
Benutzer81.4k
Themen1.3m
Beiträge