UPDATE 31.10.: Amazon Alexa - ioBroker Skill läuft aus ?

[darkbrain85]

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…

[wendy2702]

Läuft seit Monaten ohne Probleme.

Versuche es erstmal mit nur einem Register und schaue ob das stabil läuft.

Wenn es Probleme mit mehreren hat vermute ich ein timing Problem.

Gesendet von iPhone mit Tapatalk Pro

[darkbrain85]

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.

[Frank_Reich]

@darkbrain85:

@wendy2702:

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? `

Die Art der Widerstände ist egal. Modbus kann auch mit 130 Ohm abgeschlossen werden. Es muss nicht präzise 120 Ohm sein.

Zur Verbindung benutze ich eine verdrillte Zweidrahtleitung ohne Schirm, verlegt im Verdrahtungskanal der Unterverteilung, teils gekreuzt mit div. Einzeladern, welche 230V führen.

Als Stick benutze ich den von Digitus.

[darkbrain85]

Ich starte jetzt automatisch alle 2 Minuten den Modbus Adapter neu. Das liefert zuverlässig Werte. Die Unterbrechung von 3-4 Sekunden für den Neustart kann man ja vernachlässigen…

Natürlich wäre eine Optimierung des Adapter trotzdem schön...

[bkuerby]

Hallo zusammen,

ich versuche gerade meine Wärmepumpe (Waterkotte Ai1+ mit WPCU-Regler) über Modbus RTU einzubinden.

Grundsätzlich funktioniert die Verbindung sowohl über ioBroker als auch testweise über qmodbus.

Zum Einen erhalte ich bei jeder Anfrage die timeout Meldung zum Anderen erhalte ich eine Meldung "unknown funktion code: 132".

Bei der ersten Abfrage nach dem Einschalten der Instanz erscheint nur die timeout Meldung. Dabei werden die Variablenwerte auch aktualisiert. Ab der zweiten Abfrage erfolgt keine Aktualisierung mehr.

modbus.0	2019-02-03 14:21:00.894	info	Disconnected from slave
modbus.0	2019-02-03 14:20:59.884	warn	Poll error count: 12 code: {"err":"timeout"}
modbus.0	2019-02-03 14:20:59.883	error	Request timed out.
modbus.0	2019-02-03 14:20:59.883	warn	Error: undefined
modbus.0	2019-02-03 14:20:54.984	error	unknown function code: 132
modbus.0	2019-02-03 14:20:54.865	info	Connected to slave
modbus.0	2019-02-03 14:19:57.610	info	Disconnected from slave
modbus.0	2019-02-03 14:19:56.602	warn	Poll error count: 11 code: {"err":"timeout"}
modbus.0	2019-02-03 14:19:56.602	error	Request timed out.
modbus.0	2019-02-03 14:19:56.601	warn	Error: undefined
modbus.0	2019-02-03 14:19:51.705	error	unknown function code: 132
modbus.0	2019-02-03 14:19:51.595	info	Connected to slave

Hat jemand eine Idee?

Viele Grüße

Bastian

[darkbrain85]

Hi!

Das steht bei mir auch noch auf dem Zettel… Aber erst muss die Waterkotte geliefert werden. Irgendwann Ende September/Anfang Oktober...

Zum Thema:

Versuch doch erstmal die Eingangsregister zu lesen. Das schreiben per Holding Register ist dann die nächste Hürde...

Funktioniert das dann sauber?

Wie ich oben schon schrieb, ist es aber ein generelles Problem, dass der Adapter bei einem Fehler keine Daten mehr abfragen kann. Das dürfte aus meiner Sicht so nicht passieren. Unabhängig ob nun eine Adresse falsch konfiguriert ist oder nicht...

[wendy2702]

Mir fällt noch ein das ich noch mit der Version 2.07 vom Adapter unterwegs bin. Und das bisher ohne Probleme.

[bkuerby]

Habe gerade auf ein Eingangsregister reduziert. Außerdem habe ich die max. Leseanforderung jeweils auf ein Register runtergesetzt. Irgendwo habe ich gelesen, dass es bei manchen Geräten Probleme gibt. Wobei ich aus meiner Erfahrung mit FHEM weiß, dass die Waterkotte damit klarkommen sollte.

Der Fehler im Log bleibt aber der gleiche. Ich verstehe den Funktion Code schon nicht.

Ich habe die aktuelle Version 2.0.9 installiert.

P.S.
> Aber erst muss die Waterkotte geliefert werden. Irgendwann Ende September/Anfang Oktober

Die arbeitet dann aber mit Modbus TCP, oder?

[darkbrain85]

@bkuerby:

Die arbeitet dann aber mit Modbus TCP, oder? `

Ich hoffe es. Allerdings muss trotzdem noch ein Modbus Interface dabei gekauft werden. Waterkotte hat wohl kein Interesse daran die Modbus TCP Funktion einfach über das bereits bestehende Webinterface bereitzustellen.

[bkuerby]

Im TCP-Modus habe ich den Adapter auch im Einsatz. Ich habe damit zwei Stromzähler angebunden. Das funktioniert auch einwandfrei. Die Kommunikation mit der Heizung über die serielle Schnittstelle macht Probleme

[darkbrain85]

@bkuerby:

Im TCP-Modus habe ich den Adapter auch im Einsatz. Ich habe damit zwei Stromzähler angebunden. Das funktioniert auch einwandfrei. Die Kommunikation mit der Heizung über die serielle Schnittstelle macht Probleme `

Irgendwas ist da nicht wie es soll beim Zugriff auf die Serielle Schnittstelle… Ich überlege schon ob ich ein Modbus TCP Gateway aufsetze und es damit nochmal probiere. Aber dann habe ich wieder ein System mehr zu "versorgen"...

[eLichte]

Hi,
ich habe jetzt auch den Modbus Adapter mit RS485 als Master im Einsatz.
Auch bei mir verabschiedet er sich regelmäßig mit timeout Fehlern.

Wenn er läuft sieht der log so aus:

modbus.0	2019-02-26 09:25:49.868	debug	Poll holdingRegs DevID(2) address 2051 - 12 bytes
modbus.0	2019-02-26 09:25:49.803	debug	Poll holdingRegs DevID(2) address 2003 - 27 bytes
modbus.0	2019-02-26 09:25:49.758	debug	Poll holdingRegs DevID(2) address 1000 - 1 bytes
modbus.0	2019-02-26 09:25:49.693	debug	Poll inputRegs DevID(2) address 2102 - 23 bytes
modbus.0	2019-02-26 09:25:49.601	debug	Poll inputRegs DevID(2) address 2006 - 53 bytes
modbus.0	2019-02-26 09:25:49.597	debug	Poll device 2

Jetzt hätte ich dazu ein paar Fragen:

1. Kann man die Zeit zwischen den Requests irgendwo einstellen. Also z.b. die Zeit zwischen Poll Input-Adress 2006 und Input-Adress 2102. Mein Client will eine definierte Wartezeit zwischen seiner Antwort und einer neuen Anfrage. Evtl. ist das auch der Grund für die Timeouts, wenn der Master manchmal zu schnell ist.

2. Eigentlich will ich die Holding Register nur schreiben.
   Dazu erschließt sich mir die Einstellungen Poll, WP und CW im Reiter "Holding Register" nicht. Ich dachte wenn ich Poll abwähle liest der Adapter die Register nicht mehr. Allerdings wird damit im iobroker das ganze Objekt gelöscht.
   Was ist der Unterschied von WP (schreibe bei Änderung?) zu CW (schreibe zyklsich?)? Es wird irgendwie immer bei Änderung geschrieben. Auch hier könnte ein Timing Problem auftreten.

Vielen Dank schon mal im vorraus für die Antworten.

[eLichte]

Der Verdacht zu Punkt 1 hat sich bestätigt. Der Master schickt zu schnell wieder eine Querry message an den Slave nach dessen Antwort. Wenn ich nur 5 zusammenhängende Register abfrage läuft die Kommunikation ohne Probleme.

modbus.0	2019-02-28 11:32:51.341	debug	Poll inputRegs DevID(2) address 2006 - 5 bytes
modbus.0	2019-02-28 11:32:51.341	debug	Poll device 2
modbus.0	2019-02-28 11:32:41.290	debug	Poll inputRegs DevID(2) address 2006 - 5 bytes
modbus.0	2019-02-28 11:32:41.290	debug	Poll device 2

Auszug aus dem Handbuch einer Daikin Klimaanlage:

(T1-T2-T3-T4) ist wie folgt definiert: 5ms bei 9600bps und 2,5ms bei 19200bps

Ich werde dazu einen Issue im Github erstellen. Evlt kann da jemand eine Verzögerungszeit einbauen. Meine Porgrammierkenntnisse reichen dafür leider nicht.

[darkbrain85]

Das kann tatsächlich ein Grund sein!
Bei meinem Modbus Stromzähler kann ich dazu nichts finden. Aber eine Danfoss Steuerung die mir die selben Probleme macht, hat im Handbuch etwas von "relaxed timing" stehen. Allerdings ohne weitere Angaben wie das timing sein muss.
Eventuell ist das aber ein Hinweis in die Richtige Richtung!
Wie ich sehe hat Bluefox das ganze auf Github ja schon mit einem Label versehen.

[wendy2702]

@eLichte sagte in Modbus:

Der Verdacht zu Punkt 1 hat sich bestätigt. Der Master schickt zu schnell wieder eine Querry message an den Slave nach dessen Antwort. Wenn ich nur 5 zusammenhängende Register abfrage läuft die Kommunikation ohne Probleme.

modbus.0	2019-02-28 11:32:51.341	debug	Poll inputRegs DevID(2) address 2006 - 5 bytes
modbus.0	2019-02-28 11:32:51.341	debug	Poll device 2
modbus.0	2019-02-28 11:32:41.290	debug	Poll inputRegs DevID(2) address 2006 - 5 bytes
modbus.0	2019-02-28 11:32:41.290	debug	Poll device 2

Auszug aus dem Handbuch einer Daikin Klimaanlage:

(T1-T2-T3-T4) ist wie folgt definiert: 5ms bei 9600bps und 2,5ms bei 19200bps

Ich werde dazu einen Issue im Github erstellen. Evlt kann da jemand eine Verzögerungszeit einbauen. Meine Porgrammierkenntnisse reichen dafür leider nicht.

Ich hatte ein ähnliches Problem mit einem Stromzähler.

Habe dann mal zum testen „alle“ lesbaren Register im Adapter eingetragen und seitdem läuft er.

[darkbrain85]

Interessanter Ansatz... Ich teste das mal hier mit meinem Zähler.
Da ist es noch überschaubar. Bei größeren Sachen wie meiner Danfoss Steuerung ist das aber quasi unmöglich. Die hat verdammt viele Register...

[KanteTaete]

Hallo zusammen,

ich habe Probleme mit dem Modbus Adapter, wenn ich mehr als einen Slave per Serial RTU abfragen möchte. Solange ich nur einen Slave abfrage (egal welchen der 3 möglichen), funktioniert das Ganze problemlos.

Meine Konfiguration:

• Raspi2 mit laufendem ioBroker
• USB-RS485-Adapter zum Zugriff auf den Bus
• Stromzähler, Typ ABB B23 (baugleich, auf Modbus-Adressen 1-3).

Bei der Konfiguration des Adapters habe ich folgendes eingestellt:

Bei den Holding Registern werden diverse (50-60) Register vom Slave 3 gepollt.
Die Abfrage dieser Register funktioniert problemlos, der "connection" Status bleibt immer auf true.
Die Polltime beträgt ca. 1,8s.

Sobald ich aber die Abfrage eines einzelnen Registers für Slave 1 oder 2 hinzufüge (ein Register vom Slave 3 verdoppelt auf den anderen Slave - die Slaves sind ja baugleich), erhalte ich timeouts.
Außerdem wechselt der "connection" Status häufig (vermutlich beim Timeout) auf "false", die Polltime wird mit ca. 120ms angegeben.

Hier die Logmeldungen:

modbus.0	2019-04-30 11:58:10.577	info	Disconnected from slave
modbus.0	2019-04-30 11:58:09.580	warn	Poll error count: 1 code: {"err":"timeout"}
modbus.0	2019-04-30 11:58:09.579	error	Request timed out.
modbus.0	2019-04-30 11:58:09.571	warn	Error: undefined
modbus.0	2019-04-30 11:57:47.923	info	List of port: [{"comName":"/dev/ttyAMA0"},{"manufacturer":"1a86","pnpId":"usb-1a86_USB2.0-Serial-if00-port0","vendorId":"1a86","productId":"7523","comName":"/dev/ttyUSB0"}]
modbus.0	2019-04-30 11:57:47.426	info	Connected to slave
modbus.0	2019-04-30 11:57:43.801	info	starting. Version 2.0.9 in /opt/iobroker/node_modules/iobroker.modbus, node: v8.16.0
host.myhost	2019-04-30 11:57:40.981	info	instance system.adapter.modbus.0 started with pid 16951

Kann es sein, dass der Adapter mit mehreren Slaves nicht zurecht kommt?
Müsste bei der Abfrage der beiden Slaves ggf. eine Wartezeit dazwischen eingebaut / diese vergrößert werden?

Kennt jemand das Problem bzw. hat jemand die Abfrage mehrerer baugleicher Slaves fehlerfrei am Laufen?

[Stefan_io]

@KanteTaete das gleiche Problem habe ich auch, einen Slave kann ich einlesen, füge ich einen weiteren hinzu gibt es Timeout.

hier meine Forumeintrag https://forum.iobroker.net/topic/22126/adapter-modbus-mehrere-geräte-ids-timeout-beim-auslesen-von-mehr-als-einen-teilnehmern

[eLichte]

@eLichte said in Modbus:

Der Verdacht zu Punkt 1 hat sich bestätigt. Der Master schickt zu schnell wieder eine Querry message an den Slave nach dessen Antwort. Wenn ich nur 5 zusammenhängende Register abfrage läuft die Kommunikation ohne Probleme.

modbus.0	2019-02-28 11:32:51.341	debug	Poll inputRegs DevID(2) address 2006 - 5 bytes
modbus.0	2019-02-28 11:32:51.341	debug	Poll device 2
modbus.0	2019-02-28 11:32:41.290	debug	Poll inputRegs DevID(2) address 2006 - 5 bytes
modbus.0	2019-02-28 11:32:41.290	debug	Poll device 2

Auszug aus dem Handbuch einer Daikin Klimaanlage:

(T1-T2-T3-T4) ist wie folgt definiert: 5ms bei 9600bps und 2,5ms bei 19200bps

Ich werde dazu einen Issue im Github erstellen. Evlt kann da jemand eine Verzögerungszeit einbauen. Meine Porgrammierkenntnisse reichen dafür leider nicht.

Ich habe im Github einen Fork gezogen und quick&dirty mit meinen bescheidenen Programmierkenntnissen eine sleep-Funktion eingebaut. Wollte nur mal testen ob das tatsächlich was bringt. Das log sieht jetzt so aus:

modbus.0	2019-05-10 10:26:07.043	debug	Poll holdingRegs DevID(2) address 2051 - 12 bytes
modbus.0	2019-05-10 10:26:06.836	debug	Wait: 100ms
modbus.0	2019-05-10 10:26:06.835	debug	Poll holdingRegs DevID(2) address 2003 - 27 bytes
modbus.0	2019-05-10 10:26:06.692	debug	Wait: 100ms
modbus.0	2019-05-10 10:26:06.692	debug	Poll holdingRegs DevID(2) address 1000 - 1 bytes
modbus.0	2019-05-10 10:26:06.517	debug	Wait: 100ms
modbus.0	2019-05-10 10:26:06.516	debug	Poll inputRegs DevID(2) address 3634 - 8 bytes
modbus.0	2019-05-10 10:26:06.324	debug	Wait: 100ms
modbus.0	2019-05-10 10:26:06.324	debug	Poll inputRegs DevID(2) address 3602 - 18 bytes
modbus.0	2019-05-10 10:26:06.119	debug	Wait: 100ms
modbus.0	2019-05-10 10:26:06.118	debug	Poll inputRegs DevID(2) address 2102 - 23 bytes
modbus.0	2019-05-10 10:26:05.844	debug	Wait: 100ms
modbus.0	2019-05-10 10:26:05.844	debug	Poll inputRegs DevID(2) address 2006 - 53 bytes
modbus.0	2019-05-10 10:26:05.700	debug	Wait: 100ms
modbus.0	2019-05-10 10:26:05.700	debug	Poll inputRegs DevID(2) address 0 - 1 bytes
modbus.0	2019-05-10 10:26:05.699	debug	Poll device 2

So läuft die Kommunikation seid ein paar Wochen ohne Fehler. Es ist also tatsächlich so, dass der Server für manche Clients zu schnell ist.