[HM-Wired] Bus wird lahmgelegt, wenn ein Gerät ausfällt

[Thorsten Pferdekaemper]

Hi,
wenn auf dem HM-Wired-Bus ein Gerät ausfällt (bzw. absichtlich abgeschaltet wird) oder Übertragungsprobleme hat, wird der Bus komplett ausgebremst. Befehle an andere Geräte kommen zwar irgendwann an, aber das kann mehrere Minuten (!) dauern. Wenn das "kaputte" Gerät wieder aktiviert wird, dann fängt sich das ganze wieder nach einer gewissen Zeit.
Hier ist die Ausgabe vom HM485d mit hoher Verbosity:

Code Auswählen Erweitern


2015.07.17 11:01:21.344 4: HM485d: Rx: FD02AB4B
2015.07.17 11:01:21.347 4: HM485d: Tx: FD03AB6100
2015.07.17 11:01:21.732 4: HM485d: Rx: FD11AC53C8420000141E000000017300000000
2015.07.17 11:01:21.748 5: SW: fd420000141e00000001077300000000bd5c
2015.07.17 11:01:21.753 3: HM485d: Tx: (172:1) I[3](0,F,B)(1E) 00000001 -> 42000014 [7] 73(s) 00000000 {BD5C}
2015.07.17 11:01:21.961 5: SW: fd420000141e00000001077300000000bd5c
2015.07.17 11:01:21.971 3: HM485d: Tx: (172:2) I[3](0,F,B)(1E) 00000001 -> 42000014 [7] 73(s) 00000000 {BD5C}
2015.07.17 11:01:22.179 5: SW: fd420000141e00000001077300000000bd5c
2015.07.17 11:01:22.183 3: HM485d: Tx: (172:3) I[3](0,F,B)(1E) 00000001 -> 42000014 [7] 73(s) 00000000 {BD5C}
2015.07.17 11:01:22.387 4: HM485d: Tx: FD04AC613439
2015.07.17 11:01:36.429 4: HM485d: Rx: FD0DAD53C842000014180000000168
2015.07.17 11:01:36.435 5: SW: fd42000014180000000103680a7a
2015.07.17 11:01:36.447 3: HM485d: Tx: (173:1) I[0](0,F,B)(18) 00000001 -> 42000014 [3] 68(h)  {0A7A}
2015.07.17 11:01:36.653 5: SW: fd42000014180000000103680a7a
2015.07.17 11:01:36.658 3: HM485d: Tx: (173:2) I[0](0,F,B)(18) 00000001 -> 42000014 [3] 68(h)  {0A7A}
2015.07.17 11:01:36.865 5: SW: fd42000014180000000103680a7a
2015.07.17 11:01:36.870 3: HM485d: Tx: (173:3) I[0](0,F,B)(18) 00000001 -> 42000014 [3] 68(h)  {0A7A}
2015.07.17 11:01:37.074 4: HM485d: Tx: FD04AD613439
2015.07.17 11:01:37.086 4: HM485d: Rx: FD0DAE53C8420000141A000000016E
2015.07.17 11:01:37.092 5: SW: fd420000141a00000001036ec60a
2015.07.17 11:01:37.099 3: HM485d: Tx: (174:1) I[1](0,F,B)(1A) 00000001 -> 42000014 [3] 6E(n)  {C60A}
2015.07.17 11:01:37.305 5: SW: fd420000141a00000001036ec60a
2015.07.17 11:01:37.311 3: HM485d: Tx: (174:2) I[1](0,F,B)(1A) 00000001 -> 42000014 [3] 6E(n)  {C60A}
2015.07.17 11:01:37.517 5: SW: fd420000141a00000001036ec60a
2015.07.17 11:01:37.522 3: HM485d: Tx: (174:3) I[1](0,F,B)(1A) 00000001 -> 42000014 [3] 6E(n)  {C60A}
2015.07.17 11:01:37.727 4: HM485d: Tx: FD04AE613439
2015.07.17 11:01:37.739 4: HM485d: Rx: FD0DAF53C8420000141C0000000176
2015.07.17 11:01:37.745 5: SW: fd420000141c000000010376b2be
2015.07.17 11:01:37.752 3: HM485d: Tx: (175:1) I[2](0,F,B)(1C) 00000001 -> 42000014 [3] 76(v)  {B2BE}
2015.07.17 11:01:37.959 5: SW: fd420000141c000000010376b2be
2015.07.17 11:01:37.964 3: HM485d: Tx: (175:2) I[2](0,F,B)(1C) 00000001 -> 42000014 [3] 76(v)  {B2BE}
2015.07.17 11:01:38.170 5: SW: fd420000141c000000010376b2be
2015.07.17 11:01:38.175 3: HM485d: Tx: (175:3) I[2](0,F,B)(1C) 00000001 -> 42000014 [3] 76(v)  {B2BE}
2015.07.17 11:01:38.379 4: HM485d: Tx: FD04AF613439
2015.07.17 11:01:40.562 4: HM485d: Rx: FD10B053C8420000141E0000000152000010
2015.07.17 11:01:40.569 5: SW: fd420000141e00000001065200001010b2
2015.07.17 11:01:40.583 3: HM485d: Tx: (176:1) I[3](0,F,B)(1E) 00000001 -> 42000014 [6] 52(R) 000010 {10B2}
2015.07.17 11:01:40.790 5: SW: fd420000141e00000001065200001010b2
2015.07.17 11:01:40.795 3: HM485d: Tx: (176:2) I[3](0,F,B)(1E) 00000001 -> 42000014 [6] 52(R) 000010 {10B2}
2015.07.17 11:01:41.002 5: SW: fd420000141e00000001065200001010b2
2015.07.17 11:01:41.007 3: HM485d: Tx: (176:3) I[3](0,F,B)(1E) 00000001 -> 42000014 [6] 52(R) 000010 {10B2}
2015.07.17 11:01:41.210 4: HM485d: Tx: FD04B0613439
2015.07.17 11:01:41.222 4: HM485d: Rx: FD0EB153C84200001418000000015300
2015.07.17 11:01:41.229 5: SW: fd42000014180000000104530055f6
2015.07.17 11:01:41.236 3: HM485d: Tx: (177:1) I[0](0,F,B)(18) 00000001 -> 42000014 [4] 53(S) 00 {55F6}
2015.07.17 11:01:41.442 5: SW: fd42000014180000000104530055f6
2015.07.17 11:01:41.447 3: HM485d: Tx: (177:2) I[0](0,F,B)(18) 00000001 -> 42000014 [4] 53(S) 00 {55F6}
2015.07.17 11:01:41.654 5: SW: fd42000014180000000104530055f6
2015.07.17 11:01:41.659 3: HM485d: Tx: (177:3) I[0](0,F,B)(18) 00000001 -> 42000014 [4] 53(S) 00 {55F6}
2015.07.17 11:01:41.863 4: HM485d: Tx: FD04B1613439
2015.07.17 11:01:41.875 4: HM485d: Rx: FD0EB253C8420000141A000000015301
2015.07.17 11:01:41.881 5: SW: fd420000141a0000000104530158b8
2015.07.17 11:01:41.888 3: HM485d: Tx: (178:1) I[1](0,F,B)(1A) 00000001 -> 42000014 [4] 53(S) 01 {58B8}
2015.07.17 11:01:42.095 5: SW: fd420000141a0000000104530158b8
2015.07.17 11:01:42.100 3: HM485d: Tx: (178:2) I[1](0,F,B)(1A) 00000001 -> 42000014 [4] 53(S) 01 {58B8}
2015.07.17 11:01:42.306 5: SW: fd420000141a0000000104530158b8
2015.07.17 11:01:42.311 3: HM485d: Tx: (178:3) I[1](0,F,B)(1A) 00000001 -> 42000014 [4] 53(S) 01 {58B8}
2015.07.17 11:01:42.515 4: HM485d: Tx: FD04B2613439
2015.07.17 11:01:42.532 4: HM485d: Rx: FD0EB353C8420000141C000000015302
2015.07.17 11:01:42.541 5: SW: fd420000141c000000010453024f6a
2015.07.17 11:01:42.546 3: HM485d: Tx: (179:1) I[2](0,F,B)(1C) 00000001 -> 42000014 [4] 53(S) 02 {4F6A}
2015.07.17 11:01:42.753 5: SW: fd420000141c000000010453024f6a
2015.07.17 11:01:42.758 3: HM485d: Tx: (179:2) I[2](0,F,B)(1C) 00000001 -> 42000014 [4] 53(S) 02 {4F6A}
2015.07.17 11:01:42.964 5: SW: fd420000141c000000010453024f6a
2015.07.17 11:01:42.969 3: HM485d: Tx: (179:3) I[2](0,F,B)(1C) 00000001 -> 42000014 [4] 53(S) 02 {4F6A}
2015.07.17 11:01:43.173 4: HM485d: Tx: FD04B3613439
2015.07.17 11:01:43.185 4: HM485d: Rx: FD0EB453C8420000141E000000015303
2015.07.17 11:01:43.192 5: SW: fd420000141e000000010453034224
2015.07.17 11:01:43.199 3: HM485d: Tx: (180:1) I[3](0,F,B)(1E) 00000001 -> 42000014 [4] 53(S) 03 {4224}
2015.07.17 11:01:43.405 5: SW: fd420000141e000000010453034224
2015.07.17 11:01:43.410 3: HM485d: Tx: (180:2) I[3](0,F,B)(1E) 00000001 -> 42000014 [4] 53(S) 03 {4224}
2015.07.17 11:01:43.617 5: SW: fd420000141e000000010453034224
2015.07.17 11:01:43.622 3: HM485d: Tx: (180:3) I[3](0,F,B)(1E) 00000001 -> 42000014 [4] 53(S) 03 {4224}
2015.07.17 11:01:43.826 4: HM485d: Tx: FD04B4613439
2015.07.17 11:01:43.838 4: HM485d: Rx: FD0EB553C84200001418000000015304
2015.07.17 11:01:43.844 5: SW: fd42000014180000000104530415fc7e
2015.07.17 11:01:43.851 3: HM485d: Tx: (181:1) I[0](0,F,B)(18) 00000001 -> 42000014 [4] 53(S) 0415 {FC7E}
2015.07.17 11:01:44.058 5: SW: fd42000014180000000104530415fc7e
2015.07.17 11:01:44.063 3: HM485d: Tx: (181:2) I[0](0,F,B)(18) 00000001 -> 42000014 [4] 53(S) 0415 {FC7E}
2015.07.17 11:01:44.270 5: SW: fd42000014180000000104530415fc7e
2015.07.17 11:01:44.275 3: HM485d: Tx: (181:3) I[0](0,F,B)(18) 00000001 -> 42000014 [4] 53(S) 0415 {FC7E}
2015.07.17 11:01:44.479 4: HM485d: Tx: FD04B5613439
2015.07.17 11:01:44.490 4: HM485d: Rx: FD0EB653C8420000141A000000015305
2015.07.17 11:01:44.497 5: SW: fd420000141a0000000104530518b0
2015.07.17 11:01:44.504 3: HM485d: Tx: (182:1) I[1](0,F,B)(1A) 00000001 -> 42000014 [4] 53(S) 05 {18B0}
2015.07.17 11:01:44.710 5: SW: fd420000141a0000000104530518b0
2015.07.17 11:01:44.715 3: HM485d: Tx: (182:2) I[1](0,F,B)(1A) 00000001 -> 42000014 [4] 53(S) 05 {18B0}
2015.07.17 11:01:44.922 5: SW: fd420000141a0000000104530518b0
2015.07.17 11:01:44.927 3: HM485d: Tx: (182:3) I[1](0,F,B)(1A) 00000001 -> 42000014 [4] 53(S) 05 {18B0}
2015.07.17 11:01:45.131 4: HM485d: Tx: FD04B6613439
2015.07.17 11:01:45.142 4: HM485d: Rx: FD0EB753C8420000141C000000015306
2015.07.17 11:01:45.151 5: SW: fd420000141c000000010453060f62
2015.07.17 11:01:45.157 3: HM485d: Tx: (183:1) I[2](0,F,B)(1C) 00000001 -> 42000014 [4] 53(S) 06 {0F62}
2015.07.17 11:01:45.364 5: SW: fd420000141c000000010453060f62
2015.07.17 11:01:45.369 3: HM485d: Tx: (183:2) I[2](0,F,B)(1C) 00000001 -> 42000014 [4] 53(S) 06 {0F62}
2015.07.17 11:01:45.576 5: SW: fd420000141c000000010453060f62
2015.07.17 11:01:45.580 3: HM485d: Tx: (183:3) I[2](0,F,B)(1C) 00000001 -> 42000014 [4] 53(S) 06 {0F62}
2015.07.17 11:01:45.785 4: HM485d: Tx: FD04B7613439
2015.07.17 11:01:45.797 4: HM485d: Rx: FD0EB853C8420000141E000000015307
2015.07.17 11:01:45.803 5: SW: fd420000141e00000001045307022c
2015.07.17 11:01:45.810 3: HM485d: Tx: (184:1) I[3](0,F,B)(1E) 00000001 -> 42000014 [4] 53(S) 07 {022C}
2015.07.17 11:01:46.017 5: SW: fd420000141e00000001045307022c
2015.07.17 11:01:46.022 3: HM485d: Tx: (184:2) I[3](0,F,B)(1E) 00000001 -> 42000014 [4] 53(S) 07 {022C}
2015.07.17 11:01:46.229 5: SW: fd420000141e00000001045307022c
2015.07.17 11:01:46.233 3: HM485d: Tx: (184:3) I[3](0,F,B)(1E) 00000001 -> 42000014 [4] 53(S) 07 {022C}
2015.07.17 11:01:46.437 4: HM485d: Tx: FD04B8613439
2015.07.17 11:01:46.449 4: HM485d: Rx: FD0EB953C84200001418000000015308
2015.07.17 11:01:46.456 5: SW: fd420000141800000001045308d5e6
2015.07.17 11:01:46.463 3: HM485d: Tx: (185:1) I[0](0,F,B)(18) 00000001 -> 42000014 [4] 53(S) 08 {D5E6}
2015.07.17 11:01:46.670 5: SW: fd420000141800000001045308d5e6
2015.07.17 11:01:46.675 3: HM485d: Tx: (185:2) I[0](0,F,B)(18) 00000001 -> 42000014 [4] 53(S) 08 {D5E6}
2015.07.17 11:01:46.881 5: SW: fd420000141800000001045308d5e6
2015.07.17 11:01:46.886 3: HM485d: Tx: (185:3) I[0](0,F,B)(18) 00000001 -> 42000014 [4] 53(S) 08 {D5E6}
2015.07.17 11:01:47.090 4: HM485d: Tx: FD04B9613439
2015.07.17 11:01:47.101 4: HM485d: Rx: FD0EBA53C8420000141A000000015309
2015.07.17 11:01:47.108 5: SW: fd420000141a00000001045309d8a8
2015.07.17 11:01:47.115 3: HM485d: Tx: (186:1) I[1](0,F,B)(1A) 00000001 -> 42000014 [4] 53(S) 09 {D8A8}
2015.07.17 11:01:47.322 5: SW: fd420000141a00000001045309d8a8
2015.07.17 11:01:47.326 3: HM485d: Tx: (186:2) I[1](0,F,B)(1A) 00000001 -> 42000014 [4] 53(S) 09 {D8A8}
2015.07.17 11:01:47.533 5: SW: fd420000141a00000001045309d8a8
2015.07.17 11:01:47.538 3: HM485d: Tx: (186:3) I[1](0,F,B)(1A) 00000001 -> 42000014 [4] 53(S) 09 {D8A8}
2015.07.17 11:01:47.742 4: HM485d: Tx: FD04BA613439
2015.07.17 11:01:47.758 4: HM485d: Rx: FD0EBB53C8420000141C00000001530A
2015.07.17 11:01:47.769 5: SW: fd420000141c0000000104530acf7a
2015.07.17 11:01:47.775 3: HM485d: Tx: (187:1) I[2](0,F,B)(1C) 00000001 -> 42000014 [4] 53(S) 0A {CF7A}
2015.07.17 11:01:47.982 5: SW: fd420000141c0000000104530acf7a
2015.07.17 11:01:47.987 3: HM485d: Tx: (187:2) I[2](0,F,B)(1C) 00000001 -> 42000014 [4] 53(S) 0A {CF7A}
2015.07.17 11:01:48.194 5: SW: fd420000141c0000000104530acf7a
2015.07.17 11:01:48.199 3: HM485d: Tx: (187:3) I[2](0,F,B)(1C) 00000001 -> 42000014 [4] 53(S) 0A {CF7A}
2015.07.17 11:01:48.402 4: HM485d: Tx: FD04BB613439
2015.07.17 11:01:48.414 4: HM485d: Rx: FD0EBC53C8420000141E00000001530B
2015.07.17 11:01:48.421 5: SW: fd420000141e0000000104530bc234
2015.07.17 11:01:48.428 3: HM485d: Tx: (188:1) I[3](0,F,B)(1E) 00000001 -> 42000014 [4] 53(S) 0B {C234}
2015.07.17 11:01:48.634 5: SW: fd420000141e0000000104530bc234
2015.07.17 11:01:48.639 3: HM485d: Tx: (188:2) I[3](0,F,B)(1E) 00000001 -> 42000014 [4] 53(S) 0B {C234}
2015.07.17 11:01:48.846 5: SW: fd420000141e0000000104530bc234
2015.07.17 11:01:48.851 3: HM485d: Tx: (188:3) I[3](0,F,B)(1E) 00000001 -> 42000014 [4] 53(S) 0B {C234}


Man sieht, dass FHEM versucht, dreimal zu senden und dann aufgibt. Das ist zu erwarten und ok.
Ca. 14 Sekunden später geht's dann aber ab. FHEM sendet jeweils dreimal h (Modultyp abfragen), n (Seriennummer abfragen), v (Firmware-Version abfragen), R (EEPROM lesen), S (Zustand abfragen). Das geht ewig so weiter und endet erst, wenn man das Gerät wieder einstöpselt. (Oder in FHEM löscht, aber das ist ein anderes Problem...)

Ich denke, dass es immer mal passieren kann, dass ein Gerät Probleme hat. Das sollte nicht die komplette Installation lahmlegen.
Ich frage mich, warum bei Verbindungsproblemen, FHEM versucht, das Gerät neu "einzulesen". Das ist ja gerade bei Verbindungsproblemen nicht sehr sinnvoll, da es erst einmal eine hohe Last auf dem Bus erzeugt. Auf der anderen Seite ist es schon sinnvoll, dass sich FHEM wieder mit dem Gerät synchronisiert, wenn es mal eine Weile vom Bus weg war.

Könnten wir das folgendermaßen umbauen:
1. Mit der Re-Synchronisierung des Devices etwas länger warten. (Das ist für den ersten Versuch nicht unbedingt notwendig.)
2. Wenn währen der Re-Synchronisierung dreimal die Antwort des Geräts ausbleibt, dann abbrechen. Im obigen Beispiel würde dann nach den dreimal "h" abgebrochen.
3. Eine erneute Re-Synchronisierung sollte frühestens nach einer Minute oder wenn das Gerät sich von sich aus meldet, stattfinden. ("Von sich aus" kann auch als Antwort auf einen Befehl sein. Damit kann man dann die Re-Synchronsierung leicht manuell anstoßen.)

Gruß,
   Thorsten

[Ralf9]

Das Problem dürfte seit der gevoo Version 138 bestehen. Dort hat er die "sub HM485_WaitForConfig" eingebaut.
Dies ist einer der Gründe warum ich, honk und einige andere keine gevoo Version verwenden. Ich habe bisher den Aufwand für die notwendigen änderungen gescheut, die notwendig wären, damit die Version für mich brauchbar ist.

honk hat in seiner Version Prüfungen eingebaut, ob die Module erreichbar sind.

Hat Dirk seit seinem Umzug keine HM-wired Komponenten mehr inbetrieb?

Gruß Ralf

Nachtrag:
Ich sehe gerade, daß meine Aussage zu der Verwendung von gevoo Versionen so nicht ganz passt. Ich habe die aktuelle gevoo Version gemeint. Ich verwende noch eine Version von anfang März mit eigenen Ergänzungen und Anpassungen.

[Thorsten Pferdekaemper]

Das Problem dürfte seit der gevoo Version 138 bestehen. Dort hat er die "sub HM485_WaitForConfig" eingebaut.

Ah, ok. Da kann ich vielleicht mal weiterforschen.

Dies ist einer der Gründe warum ich, honk und einige andere keine gevoo Version verwenden. Ich habe bisher den Aufwand für die notwendigen änderungen gescheut, die notwendig wären, damit die Version für mich brauchbar ist.

Tja, für mich hat die alte Version von Dirk irgendwie gar nicht funktioniert.

honk hat in seiner Version Prüfungen eingebaut, ob die Module erreichbar sind.

Ich denke, da braucht man nicht extra Prüfungen. Das gibt das Protokoll ja schon her. Man darf halt nur nicht mit irgendwas weitermachen bis zum Kollaps des Universums. ...oder meinst Du das?

Hat Dirk seit seinem Umzug keine HM-wired Komponenten mehr inbetrieb?

Das weiß nur Dirk...

Wie auch immer gibt es wahrscheinlich in den verschiedenen Varianten verschiedene Vor- und Nachteile. Es wäre aber schön, wenn wir das ganze irgendwie zusammenführen könnten. Ansonsten kocht jeder sein eigenes Süppchen und davon hat dann keiner was.

Gruß,
   Thorsten

[Thorsten Pferdekaemper]

Das Problem dürfte seit der gevoo Version 138 bestehen. Dort hat er die "sub HM485_WaitForConfig" eingebaut.

Ich habe mir das jetzt mal im Detail angeschaut. Das Problem ist, dass HM485_WaitForConfig (bzw. HM485_GetInfos und HM485_GetConfig) einfach die ganzen Befehle absetzen und nicht auf die Antwort warten. Das ist ja auch klar, da kein Modul blockieren darf. Außerdem wäre das auch etwas schwierig.
Ich habe da gerade keine wirklich gute Idee. Vielleicht ein paar Ansätze:

1. Das automatische Aufrufen von WaitForConfig für Fehlerzustände komplett weglassen. Es müsste doch reichen, das beim Define (inklusive FHEM-Start) und bei manuellem Aufruf von "get config" zu machen. Naja, andererseits ist es schon nett, wenn sich ein Device ordentlich zurückmeldet.

2. In der Sende-Queue Bereiche einrichten, die bei einem erfolglosen Sendeversuch einfach gelöscht werden. Dort könnte man dann die ganzen get config/info/EEPROM/channels-Geschichte reinpacken und beim ersten "NACK" alles rauswerfen.

3. Ähnlich wie 2, aber in 10_HM485.pm. Wenn eine Funktion mehrere Befehle absetzen will, dann merkt man sich alle und schickt den jeweils nächsten erst, wenn die Response/ACK-Nachricht vom vorherigen eingetroffen ist. Bei einem Problem wird der ganze Stapel weggeworfen.

4. Soweit ich verstanden habe gibt es nur eine Sende-Queue in 00_HM485_LAN.pm. Ich glaube, dass das erst einmal ok ist, da das Bustiming gar nichts anderes erlaubt. (Ansonsten müsste ein Device "zwischen" einem Befehl und der Response senden dürfen und das geht eigentlich nicht.) Allerdings ist die Sortierung der Sende-Queue vielleicht etwas ungeschickt. Anstatt immer den Eintrag mit der niedrigsten Queue-Id zu schicken könnte man sozusagen eine Queue pro Device bilden und dann die Devices "round Robin" abarbeiten. D.h. einmal schnell Licht einschalten würde schnell abgearbeitet, auch wenn ein anderes Device gerade mit get config etc. beschäftigt ist.

Meinungen?

Gruß,
   Thorsten

[hglaser]

hallo thorsten

ich hab mich ja auch schon ein bisschen mit der Queue beschäftigt und bin nicht unbedingt begeistert von der Implementierung. Leider hatte ich bisher zuwenig Zeit mir das ganze genauer anzusehen.
Um ein Device erfolgreich anzulegen braucht man zuerst das "model" die "seriennummer" und bei manchen Devices die verschiedene xml Dateien pro Version haben (io12sw7), auch noch die "firmware-Version". Das passiert über HM485_GetInfos und funktioniert bisher schon mal schlecht weil die Daten wohl nicht gesammelt werden und dann erst das Device mit Channel 0 angelegt wird.
Ich verwende z.B. den 0x68 Befehl als ping um festzustellen, ob das Device am Bus hängt, und frage dann erst nach den restlichen Daten. (klappt noch nicht wirklich schön )

Das nächste Problem sind dann die restlichen Channels des Device, da es ja Devices gibt, die Ihre Channel ändern können, und das ist im eeprom hinterlegt, braucht man auch noch die eeprom Daten um den channel nun z.B beim io12fm als "input" oder "output" anzulegen.
Ich verwende einen Hash in dem alle gesendeten eeprom-zeilen adressen stehen und lösche die zeile, wenn die daten dafür ankommen. Wenn der hash Null ist sind alle eeprom Daten angekommen und es geht weiter mit HM485_CreateChannels, wenn nicht versuche ich noch bis zu 3 mal die restlichen zeilen anzufordern.

Das ganze ist nicht besonders elegant von mir gelöst, aber ist zumindest ein ansatz.

1. Das automatische Aufrufen von WaitForConfig für Fehlerzustände komplett weglassen. Es müsste doch reichen, das beim Define (inklusive FHEM-Start) und bei manuellem Aufruf von "get config" zu machen. Naja, andererseits ist es schon nett, wenn sich ein Device ordentlich zurückmeldet.

Verstehe ich leider nicht so recht. wird WaitForConfig auch noch wo anders als beim Define aufgerufen?

2. In der Sende-Queue Bereiche einrichten, die bei einem erfolglosen Sendeversuch einfach gelöscht werden. Dort könnte man dann die ganzen get config/info/EEPROM/channels-Geschichte reinpacken und beim ersten "NACK" alles rauswerfen.

Meinst du hier diesen .waitForResponse oder .waitForAck hash? der wird ja eigentlich gelöscht. oder verstehe ich das auch falsch?

3. Ähnlich wie 2, aber in 10_HM485.pm. Wenn eine Funktion mehrere Befehle absetzen will, dann merkt man sich alle und schickt den jeweils nächsten erst, wenn die Response/ACK-Nachricht vom vorherigen eingetroffen ist. Bei einem Problem wird der ganze Stapel weggeworfen.

Also so ähnlich, wie ich es bei den eeprom daten mache, nur halt ohne Wiederholungen. Das fände ich nicht schlecht. Fragt sich nur wer es macht ?

4."round Robin"

Das wäre dann eine Fleißaufgabe, wenn das System einmal eingerichtet ist, sollte es "get configs" nur beim Start und sonst doch eher selten geben.

lg harald

[Thorsten Pferdekaemper]

Ich verwende z.B. den 0x68 Befehl als ping um festzustellen, ob das Device am Bus hängt, und frage dann erst nach den restlichen Daten.

Das Problem dabei ist wahrscheinlich, dass die ganze Kommunikation bis in die oberen Schichten asynchron geht. FHEM kann ja schlecht bis zum Timeout warten. Kannst Du mir mal Dein Coding dazu schicken?

Ich verwende einen Hash in dem alle gesendeten eeprom-zeilen adressen stehen und lösche die zeile, wenn die daten dafür ankommen. Wenn der hash Null ist sind alle eeprom Daten angekommen und es geht weiter mit HM485_CreateChannels, wenn nicht versuche ich noch bis zu 3 mal die restlichen zeilen anzufordern.

Das Coding in 10_HM485.pm, das ich vor mir habe, macht etwas ähnliches, aber HM485_CreateChannels wird immer aufgerufen, auch wenn das Lesen des EEPROM noch nicht fertig ist. Könntest Du auch dazu mal Dein Coding schicken?

Das ganze ist nicht besonders elegant von mir gelöst, aber ist zumindest ein ansatz.

Was Du da machst, deckt sich einigermaßen mit meinen Ideen. Lass uns versuchen, das eleganter zu machen. Ich glaube, ich fange so langsam an zu verstehen, wie das ganze funktioniert.

Verstehe ich leider nicht so recht. wird WaitForConfig auch noch wo anders als beim Define aufgerufen?

Ja, zum Beispiel wenn eine Nachricht von der Zentrale dreimal nicht beantwortet wird. In 10_HM485.pm:

Code Auswählen Erweitern


sub HM485_SetStateNack($$) {
my ($hash, $msgData) = @_;
my $hmwId = substr( $msgData, 2, 8);

my $devHash = HM485_GetHashByHmwid($hmwId);

my $txt = 'RESPONSE TIMEOUT';
# $devHash->{STATE} = 'NACK';
readingsSingleUpdate($devHash, 'state', $txt, 1);

HM485::Util::logger(HM485::LOGTAG_HM485, 3, $txt . ' for ' . $hmwId);
if ( !exists( $devHash->{'.waitforConfig'}{'counter'})) {
$devHash->{'.waitforConfig'}{'hmwId'} = $hmwId;
$devHash->{'.waitforConfig'}{'counter'} = 10;
InternalTimer( gettimeofday() + $defStart + $defWait, 'HM485_WaitForConfig', $devHash, 0);
}
}

Das ist ja gerade das Problem. Wenn dann das Device immer noch nicht am Bus ist, dann geht das ganze wieder von vorne los bis in alle Ewigkeit.

Meinst du hier diesen .waitForResponse oder .waitForAck hash? der wird ja eigentlich gelöscht. oder verstehe ich das auch falsch?

Ich meine die Sende-Queue selbst in 00_HM485_LAN.pm. Sie wird gefüllt in HM485_LAN_SendQueue. Dadurch, dass HM485_GetInfos und HM485_GetConfig einfach alle Befehle senden, dürften in der Queue Nachrichten stehen für h, n, v, R für alle EEPROM-Adressen und S für alle Kanäle. Selbst wenn schon das h schief geht wird dann trotzdem die ganze Queue abgearbeitet. Das ist natürlich Blödsinn, da es unwahrscheinlich ist, dass der Bus plötzlich wieder funktioniert.
Meine Idee ist jetzt, dass man in solchen Fällen der Queue eine "Stapel"-Id mitgibt. Wenn eine Nachricht fehlschlägt (dreimal) und eine Stapel-Id hat, dann werden alle mit der gleichen Stapel-Id gelöscht.
Wie gesagt: Das ist nur eine Idee. Möglicherweise nicht die beste.

Also so ähnlich, wie ich es bei den eeprom daten mache, nur halt ohne Wiederholungen.

Wahrscheinlich meinen wir zumindest etwas ähnliches. Die Wiederholungen sollten Sache der Protokollschicht sein. Wenn das Device dreimal nicht antwortet, dann ist es auch nicht ganz so sinnvoll, es gleich nochmal zu probieren.
Wenn es beim EEPROM lesen spezielle Probleme gibt, dann kann ich mir vorstellen, dass manche Devices einfach zu langsam sind. Vielleicht sind die Timeouts etwas knapp bemessen. Allerdings habe ich bei mir solche Probleme noch nicht gesehen. Ich habe aber auch nicht wirklich danach gesucht, da ich momentan kein Gerät mit irgendwelchen Einstellungen habe, die mich interessieren würden.
Aber wie schon gesagt: Zeig mal Dein Coding dazu. Mir ist momentan noch nicht ganz klar, wie man in dem Umfeld ein "warten auf irgendwas" elegant implementiert.

Das fände ich nicht schlecht. Fragt sich nur wer es macht ?

Vielleicht kann ich da helfen. Aber zuerst würde ich gerne ein einigermaßen stabiles Konzept haben, deshalb mein ganzes Geschreibsel.
Wahrscheinlich würde mir Dein bisheriges Coding dazu etwas helfen.

Das wäre dann eine Fleißaufgabe, wenn das System einmal eingerichtet ist, sollte es "get configs" nur beim Start und sonst doch eher selten geben.

Wahrscheinlich hast Du Recht. Das gehört auch nicht wirklich hier hin. Allerdings kann ich mir schon vorstellen, dass ein Device, was an einer etwas "wackeligen" Verbindung hängt, große Probleme verursachen kann. Möglicherweise auch ohne den WitForConfig-Kram.

Gruß,
   Thorsten

[Ralf9]

ich habe dazu auch einige Ideen und Wünsche, ich melde mich dazu heute Nachmittag nochmal.

Gruß Ralf

[hglaser]

hallo thorsten

es freut mich, wenn Du Dich damit beschäftigen möchtest. Mein Coding ist auf Github aktuell.
https://github.com/hresalg/FHEM-HM485/tree/dev

Ja, zum Beispiel wenn eine Nachricht von der Zentrale dreimal nicht beantwortet wird. In 10_HM485.pm:

achso, das kannte ich noch nicht, Ich habe mir gevoos Version wohl schon länger nicht mehr angesehen.

lg Harald

[Thorsten Pferdekaemper]

Hi,
meine vorherige Antwort wurde schon etwas unübersichtlich...
Ich versuche jetzt mal ein Konzept zu beginnen, das ein paar Problemchen löst. Es sollte folgendes können:
1. Bei aufeinander folgenden Nachrichten abbrechen, wenn es Probleme auf dem Bus gibt. (...die nicht durch dreimaliges Senden lösbar sind.)
2. Bestimmte Aktionen (inklusive das Senden weiterer Befehle) sollten an die korrekte Response einer anderen Nachricht gekoppelt sein. Zum Beispiel: Das Auslesen der EEPROM-Daten sollte überhaupt erst anfangen, nachdem Modultyp etc. gelesen wurden. Das Anlegen/Konfigurieren der Kanäle sollte erst anfangen, nachdem das EEPROM erfolgreich gelesen wurde. (Das würde dann wahrscheinlich auch das Problem lösen, dass man am Anfang immer noch einmal get config machen muss, um die Kanäle einzulesen.)
3. Es sollte für den Benutzer klar sein, was gerade läuft. Zum Beispiel kann das im STATE passieren oder auch in einem eigenen Reading, das anzeigt, wie aktuell die Infos/Config gerade sind. Das könnte sowas sein wie "CONFIG_OK", "CONFIG_READING", "CONFIG_FAILED". Vielleicht gibt es das ja auch schon.
4. Es sollte keine Abhängigkeiten durch Timing gelöst werden. D.h. wir sollten uns nicht darauf verlassen, dass irgend ein Vorgang nach 5 Sekunden oder so beendet ist. Andererseits sollte es sofort weitergehen, wenn etwas schneller geht, als "geplant".

So, wie könnte man das jetzt machen...
1. Anstatt direkt HM485_SendCommand aufzurufen werden diese Aufrufe in eine eigene Queue eingetragen. Die Queue ist nicht unbedingt spezifisch für ein Device, aber sie existiert sozusagen nur solange ein "Stapel" von Befehlen abzuarbeiten ist.
2. Die Queue wird folgendermaßen abgearbeitet:
2.1. HM485_SendCommand für den ersten Eintrag wird aufgerufen.
2.2. Am Ende von HM485_ProcessResponse wird geprüft, ob es für die Response einen Queue-Eintrag gibt. Falls ja, dann wird der erste Eintrag gelöscht und der nächste bearbeitet.
2.3. In HM485_SetStateNack (oder da, wo es aufgerufen wird), wird geprüft, ob es für die Nachricht einen Queue-Eintrag gibt. Falls ja, dann wird die ganze Queue gelöscht.
3. Eine Queue hat zwei Callback-Funktionen: Eine für die erfolgreiche Abarbeitung und eine für den Fehlerfall. Letztere wird immer aus 2.3 oben aufgerufen. Erstere (der Erfolgsfall) wird aufgerufen, wenn die Queue in 2.2. leer ist.

Für HM485_WaitForConfig würde das folgendermaßen aussehen:
1. Der Status wird auf CONFIG_READING gesetzt.
2. Die h,n,v Messages werden in eine neue Queue geschrieben. Erfolgs-Callback ist sozusagen HM485_GetConfig.
3. In HM485_GetConfig werden die R-Befehle zum Lesen des EEPROMs in eine Queue geschrieben. Erfolgs-Callback ist das Anlegen/Lesen der Kanäle.
4. Beim Anlegen/Lesen der Kanäle werden die S-Befehle in eine Queue geschrieben. Erfolgs-Callback ist eine Funktion, die den Status auf CONFIG_OK setzt.
5. Für alle Schritte ist der NACK-Callback eine Funktion, die den Status auf CONFIG_FAILED setzt.

Teile davon können dann natürlich auch für ein "normales" get config etc. verwendet werden.

Meinungen?
Gruß,
  Thorsten

[Thorsten Pferdekaemper]

es freut mich, wenn Du Dich damit beschäftigen möchtest. Mein Coding ist auf Github aktuell.

Ich hab mir's mal angesehen. Den Ping-Pong-Mechanismus und das Warten auf's EEPROM habe ich gefunden. Das hilft schon mal. Ja, so kann man's auch machen, aber es wäre meiner Meinung nach schöner, wenn man da was allgemeines hätte. 
...und es wäre schön, wenn wir mal die verschiedenen Versionen zusammenführen könnten.

[hglaser]

ja. eine Vereinfachung wäre schön. Ich habs auch nur so gelöst, weil mir nichts besseres eingefallen ist, da ich mich zu dem Zeitpunkt mit dem peering beschäftigt habe und es eigentlich noch immer tue. Das ganze bis zum Device anlegen könnte wohl eine Auffrischung brauchen. Leider habe ich noch immer nicht ganz durchschaut wie so ein Device in FHEM wirklich angelegt werden soll und habs erst mal ignoriert.

Ich habe einmal Dirk und auch gevoo per PM kontaktiert. Dirk hat nicht geantworted und Gevoo hat meine Version übernommen wollte aber mit "git" wohl nichts zu tun haben. das wars dann eigentlich schon. also hab ichs gelassen und mein eigenes Süppchen gekocht. Ich bin gerne bereit mitzuarbeiten, arbeite jedoch in einer ganz anderen Branche, und das 6 Tage die Woche, habe daher nicht immer Zeit. (zurzeit 2 tage frei, und draussen ist es mir zu heiß )

lg Harald

[Thorsten Pferdekaemper]

wollte aber mit "git" wohl nichts zu tun haben. das wars dann eigentlich schon.

Ja, ich weiß. Deshalb habe ich das übernommen. Die aktuellste Version sollte immer hier sein: https://github.com/kc-GitHub/FHEM-HM485/.

Ich bin gerne bereit mitzuarbeiten, arbeite jedoch in einer ganz anderen Branche, und das 6 Tage die Woche, habe daher nicht immer Zeit. (zurzeit 2 tage frei, und draussen ist es mir zu heiß )

Ich langweile mich normalerweise auch nicht gerade, aber ich will bald einiges an "Wired"-Kram produktiv einsetzen und da hätte ich gerne eine Version, die läuft und die auch von mehreren Leuten benutzt wird. Daher will ich mich damit befassen.

[Ralf9]

Ich habe dazu noch folgende Ideen und Wünsche:

Eine Möglichkeit wäre nach dem erfolgreichen EEPROM lesen im Modul ein state (z.B. stateconfig ok) setzen. Bei einem Modul das auch peering kann, reicht es wenn das EEPROM bis zum beginn der peeringdaten erfolgreich eingelesen wurden.
Wenn das stateconfig nicht ok ist, dann sollte beim Drücken auf den "save config" Knopf eine Fehlermeldung kommen.

Beim peering dann genauso. Wenn die peering Daten erfolgreich eingelesen wurden, im Modul ein statepeering ok setzen.

Beim einlesen der EEPROM Daten kann evtl auch das "E" Kommando hilfreich sein:
https://github.com/kc-GitHub/HM485-Lib/blob/markus/HMWModule.cpp

Code Auswählen Erweitern


-        //       Der E-Befehl wird von der Zentrale beim Pairing geschickt
-        //       ganz klar ist aber nicht, was er macht. Bisher kam als
-        //       Daten immer 0x00001040 mit und das wurde von einem echten
-        //       Device mit einem e und 00 00 10 xx xx xx xx xx xx xx xx beantwortet.
-        //       Die x stehen fuer ein Bitmuster. Ein gesetztes Bit bedeutet, dass
-        //       die entsprechenden 16 Byte im EEPROM benutzt sind.


Wenn das Einlesen der Konfiguration nicht erfolgreich war, nach kurzer Zeit nach vorherigem Ping nochmals wiederholen.
Wenn dies auch nichts bringt nach einem konfigurierbarem Abstand regelmässig per Ping mit z.B. 68 prüfen ob das Modul wieder erreichbar ist. 

Gruß Ralf

[Thorsten Pferdekaemper]

Eine Möglichkeit wäre nach dem erfolgreichen EEPROM lesen im Modul ein state (z.B. stateconfig ok) setzen.

Ja, sowas in der Art habe ich mir auch schon gedacht, siehe oben.

Bei einem Modul das auch peering kann, reicht es wenn das EEPROM bis zum beginn der peeringdaten erfolgreich eingelesen wurden.

Das kann aber beliebig kompliziert werden, da die Peering-Daten nicht unbedingt nach dem Rest stehen müssen. Das kann beliebig gemischt sein.

Wenn das stateconfig nicht ok ist, dann sollte beim Drücken auf den "save config" Knopf eine Fehlermeldung kommen.

Wirklich? Das würde bedeuten, Du kannst kein save config mehr machen, wenn der RS485-Bus Probleme hat. Das würde ich nicht wollen.

Beim einlesen der EEPROM Daten kann evtl auch das "E" Kommando hilfreich sein:

Wenn Du genau wissen willst, wie das mit dem E wirklich funktioniert: Siehe Anhang.

Wenn das Einlesen der Konfiguration nicht erfolgreich war, nach kurzer Zeit nach vorherigem Ping nochmals wiederholen.
Wenn dies auch nichts bringt nach einem konfigurierbarem Abstand regelmässig per Ping mit z.B. 68 prüfen ob das Modul wieder erreichbar ist. 

So etwas ähnliches schwebt mir auch vor, nur das mit der kurzen Zeit am Anfang finde ich nicht so der Hit.

Auch hier habe ich den Eindruck, dass das Lesen der Konfigurationsdaten fehlerträchtig ist. Dass das Lesen des EEPROM schief geht sollte doch eigentlich der Ausnahmefall sein. Wenn das nicht so ist, dann sollten wir mal nachforschen, warum das problematisch ist.

[Ralf9]

Das kann aber beliebig kompliziert werden, da die Peering-Daten nicht unbedingt nach dem Rest stehen müssen. Das kann beliebig gemischt sein.

kennst Du ein Modul bei dem nach den den peering Daten noch config Daten kommen?

Wirklich? Das würde bedeuten, Du kannst kein save config mehr machen, wenn der RS485-Bus Probleme hat. Das würde ich nicht wollen.

Wenn die config Daten der Kanäle nicht vollständig eingelesen wurden und es sich in einem Byte die config mehrerer Kanäle befinden, kann es zu komischen Effekten kommen.

Wenn Du genau wissen willst, wie das mit dem E wirklich funktioniert: Siehe Anhang.

Danke für die Info. So in etwa habe ich es mir schon vorgestellt. Falls vor dem einlesen vom EEPROM schon bekannt ist ob das Modul peering kann, würde es bei Peering Modulen Sinn machen.
Nach der Antwort vom E-Befehl müssten dann z.B. anstatt 64 nur noch ca 3-10 EEPROM Blöcke eingelesen werden. 

So etwas ähnliches schwebt mir auch vor, nur das mit der kurzen Zeit am Anfang finde ich nicht so der Hit.

Die kurze Zeit kann z.B. auch 5-10 Sekunden sein.

Auch hier habe ich den Eindruck, dass das Lesen der Konfigurationsdaten fehlerträchtig ist. Dass das Lesen des EEPROM schief geht sollte doch eigentlich der Ausnahmefall sein. Wenn das nicht so ist, dann sollten wir mal nachforschen, warum das problematisch ist.

Ja, es sollte der Ausnahmefall sein, aber es kann vorkommen. Eine ursache könnte z.B. ein etwas schwächlicher Rechner wie z.B. ein Raspi oder eine Überlast von fhem beim starten sein.

Gruß Ralf