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:
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
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.
Zitat von: Ralf9 am 17 Juli 2015, 12:06:52
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.
Zitat
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.
Zitat
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?
Zitat
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
Zitat von: Ralf9 am 17 Juli 2015, 12:06:52
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
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.
Zitat1. 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?
Zitat2. 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?
Zitat3. Ä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 ?
Zitat4."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
Zitat von: honk am 18 Juli 2015, 08:05:25Ich 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?
Zitat
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?
Zitat
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.
Zitat
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:
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.
Zitat
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.
Zitat
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.
ZitatDas 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.
ZitatDas 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
ich habe dazu auch einige Ideen und Wünsche, ich melde mich dazu heute Nachmittag nochmal.
Gruß Ralf
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 (https://github.com/hresalg/FHEM-HM485/tree/dev)
ZitatJa, 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
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
Zitat von: honk am 18 Juli 2015, 11:18:03es 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.
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
Zitat von: honk am 18 Juli 2015, 12:49:25wollte 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/ (https://github.com/kc-GitHub/FHEM-HM485/).
ZitatIch 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.
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
- // 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
Zitat von: Ralf9 am 18 Juli 2015, 19:45:55Eine 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.
ZitatBei 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.
ZitatWenn 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.
Zitat
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.
ZitatWenn 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.
Zitat von: Thorsten Pferdekaemper am 18 Juli 2015, 21:26:15
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?
ZitatWirklich? 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.
ZitatWenn 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.
ZitatSo 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.
ZitatAuch 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
ZitatFalls vor dem einlesen vom EEPROM schon bekannt ist ob das Modul peering kann, würde es bei Peering Modulen Sinn machen.
ist sowieso bekannt, steht ja im xmldevice.pm.
ZitatWenn dies auch nichts bringt nach einem konfigurierbarem Abstand regelmässig per Ping mit z.B. 68 prüfen ob das Modul wieder erreichbar ist.
Wenn es vom Bus getrennt war, wird es wohl auch in aller Regel auch vom Strom getrennt sein. Es meldet sich dann schon von selbst wieder wenn es wieder mit Strom versorgt wird. Ich finde das viel zu kompliziert.
Und wenn die 1024 Byte nicht nach spätestens sagen wir mal 5 maligen Versuchen (was es bei mir noch nie gebraucht hat, selbst wenn auf dem Bus die Hölle los war), nicht eingelesen werden konnte, finde ich, ist wohl am Bus etwas im Argen. Ebenso nur Teile davon beim Start einzulesen, finde ich total übertrieben. Und wenn, auch hier stünden die EEProm Addressen für einen, wie soll mann sagen "Notbetrieb" im xml.
Ich will eigentlich nur mein Haus steuern, kein Atomkraftwerk :-)
lg Harald
Zitat von: honk am 19 Juli 2015, 08:26:41
Wenn es vom Bus getrennt war, wird es wohl auch in aller Regel auch vom Strom getrennt sein. Es meldet sich dann schon von selbst wieder wenn es wieder mit Strom versorgt wird. Ich finde das viel zu kompliziert.
Ok, wenn jemand ein Modul vom Bus nimmt, kann er hinterher ja wieder ein "get config all" machen.
Das ist mir nicht klar, wie bekommt es fhem mit, wenn ein Modul wieder mit Strom versorgt wird.
Zitat
Und wenn die 1024 Byte nicht nach spätestens sagen wir mal 5 maligen Versuchen
Ich finde 3 mal dürften reichen. Oder falls der Aufwand nicht so groß ist, die Anzahl konfigurierbar machen, z.B. per Attribut.
ZitatEbenso nur Teile davon beim Start einzulesen, finde ich total übertrieben.
Wenn bei den Peering modulen die EEPROM Daten per E-Befehl eingelesen werden, ist das Einlesen früher fertig und schwächliche Rechner wie z.B. die Fritzbox oder der Raspi werden entlastet.
Das einlesen per E-Befehl dürfte nicht so aufwendig sein. Einfach die Bits vom E-Befehl Ergebnis per Schleife durchlaufen und dann bei 0 in den Block FF reinschreiben und bei 1 von EEPROM einlesen.
Wenn jemand z.B 5 Peering Module hat, ist es schon ein Unterschied ob 320 oder nur ca 30-50 EEPROM Blöcke eingelesen werden.
Gruß Ralf
Zitat von: Ralf9 am 19 Juli 2015, 09:05:20
Das ist mir nicht klar, wie bekommt es fhem mit, wenn ein Modul wieder mit Strom versorgt wird.
Zumindest "meine" Homebrew-Module schicken nach dem Einschalten eine Announce-Message (0x41). Ich habe aber auch schon gesehen, dass Geräte irgendwelche Zustände schicken ("ungefragte" 0x69).
Wenn das Gerät beim Einschalten nichts sendet, dann wird FHEM wohl nicht mitbekommen, wenn's wieder ans Netz geht.
Zitat von: Thorsten Pferdekaemper am 18 Juli 2015, 11:40:22
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, ich denke, dass das jetzt funktioniert. GetInfo, GetConfig und das WaitForConfig funktionieren jetzt nach dem Schema. Man kann damit Geräte beliebig vom Bus nehmen und wieder anschließen, ohne damit den Bus zu blockieren. Außerdem gibt es ein Internal CONFIG_STATUS, an dem man sehen kann, ob die Config richtig eingelesen wurde (Infos, EEPROM, Channels).
Könnte es mal jemand testen? Man muss nur die 10_HM485.pm ersetzen.
Vielleicht will auch mal jemand über's Coding schauen. Ich habe alle Änderungen mit #PFE markiert. Im Wesentlichen sind das die Queue-Funktionen am Ende, GetInfo, GetConfig und ein paar Kleinigkeiten an anderen Stellen.
Es besteht noch ein bisschen Optimierungsbedarf. Zum Beispiel versucht FHEM etwas zu oft, die Config zu lesen, wenn das Gerät offline ist. Autocreate geht auch noch nicht richtig, aber das war vorher auch so.
Gruß,
Thorsten
Hallo Thorsten,
ich bin so mutig und teste die Version ab jetzt produktiv.
Viele Grüße
Stephan
Zitat von: stephan-221 am 20 Juli 2015, 19:18:55ich bin so mutig und teste die Version ab jetzt produktiv.
Oha, Danke für Dein Vertrauen. Bei mir darf das bisher nur auf's Testsystem.
Sag' Bescheid, wie's läuft.
Der nächste Schritt für mich ist jetzt ein ordentliches Autocreate, das auch die Channels anlegt. Mal sehen, ob ich das hinbekomme.
Hi,
jetzt gibt es eine neue Version. Änderungen zu vorher:
1. CONFIG_STATUS wird am Anfang auf PENDING gesetzt. Das bedeutet, dass FHEM noch gar nicht versucht hat, die Konfigurationsdaten zu lesen. Möglicherweise fällt das aber nur auf, wenn man wirklich viele Geräte hat.
2. Nach einem Define klappt jetzt das automatische Lesen der Konfigurationsdaten, auch beim Autocreate!
Letzteres bedeutet, dass das Device nur mal irgendwas von sich geben muss und FHEM legt das Ding komplett automatisch an, mit allen Kanälen und ohne dass man "get config" machen muss.
Falls das Device nicht von sich aus sendet, dann kann man es auch per Define manuell anlegen. Dabei ist es erstmal egal, ob das Device am Bus hängt. Wenn man es einklinkt, dann holt sich FHEM, was es braucht automatisch.
Komisch ist nur, dass HM485 Devices, die per define manuell angelegt wurden, nicht unter HM485 erscheinen. Das ist wohl aber ein anderes Problem.
EDIT: Ist jetzt klar. Die automatische Room-Zuordnung passiert nur beim Autocreate.
Hallo Thorsten
Ich habs zwar noch nicht ausprobiert, aber schon mal reingesehen. Gefällt mir sehr gut Deine Lösung. Ich werde es, sobald ich Zeit habe testen. Es freut mich, daß es wieder ein Stück vorangeht.
lg Harald
Hallo Thorsten,
ich habe die erste Version von dir im Einsatz. Das Update von heute Nacht habe ich noch nicht eingespielt.
Betrieb läuft unauffällig. Autocreate funktioniert in der Tat nicht. Habe ein HBW Device kurz angeklemmt.
Man sieht Messages im Log, aber FHEM reagiert nicht drauf.
Ich werde heute Abend auf die neuere Version updaten und dann berichten.
Ich teste dann auch mal das temporäre Entfernen eines Devices.
Viele Grüße
Stephan
Hi,
ich hatte heute Nacht einen Fall, bei dem irgendwas falsch lief. Ich konnte es aber nicht reproduzieren. Das Blöde ist, dass es bewirkt, dass gar kein get config etc. mehr funktioniert. Ich vermute, dass es auftreten kann, wenn ein Gerät ziemlichen Blödsinn macht, wie z.B. ACKs oder Responses immer gerade eine bestimmte Zeit zu spät zu senden.
Falls jemand solcher "Hänger" sieht, dann wäre ich an den genauen Umständen interessiert.
Gruß,
Thorsten
Hallo Thorsten,
Autocreate funktioniert jetzt.
Habe damit jetzt 6 Module am laufen und werde es weiter durchtesten.
Beim Entfernen (Busunterbrechung) kommt das Device mit "Config status failed".
Beim Verbinden dann reading und anschließend OK.
Sehr schön! :-)
Die Meldungen sollten besser nur via verbose 5 sichtbar sein:
2015.07.21 20:28:43 3: HM485_QueueProcessStep: HASH(0x19cc980)
2015.07.21 20:28:43 3: HM485_QueueProcessStep: HASH(0x1818d90)
2015.07.21 20:28:43 3: HM485_QueueProcessStep: HASH(0x19edf18)
2015.07.21 20:28:44 3: HM485_QueueProcessStep: HASH(0x17fc320)
2015.07.21 20:28:44 3: HM485_QueueProcessStep: HASH(0x17e72c0)
2015.07.21 20:28:44 3: HM485_QueueProcessStep: HASH(0x19d5270)
2015.07.21 20:28:44 3: HM485_QueueProcessStep: HASH(0x91ed48)
2015.07.21 20:28:44 3: HM485_QueueProcessStep: HASH(0x15f26d0)
Sonst wird das Logfile seeehr schnell riesig.
Viele Grüße
Stephan
Zitat von: stephan-221 am 21 Juli 2015, 20:34:51Autocreate funktioniert jetzt.
Habe damit jetzt 6 Module am laufen und werde es weiter durchtesten.
Beim Entfernen (Busunterbrechung) kommt das Device mit "Config status failed".
Beim Verbinden dann reading und anschließend OK.
Sehr schön! :-)
Danke!
Zitat
Die Meldungen sollten besser nur via verbose 5 sichtbar sein:
Ja, das ändere ich noch.
Könntest Du mit Deinen 6 Devices mal ein "shutdown restart" in FHEM machen und dann posten, was das im Logfile hinterlässt? Ich bin mir nicht ganz sicher, ob das 100% richtig läuft. Es ist wahrscheinlich nichts schlimmes, da dann ein Device mal kurz in "FAILED" geht, aber nach 10 Sekunden versucht's FHEM nochmal. Aber ich würde gerne herausfinden, was da los ist.
Hallo Thorsten,
ZitatKönntest Du mit Deinen 6 Devices mal ein "shutdown restart" in FHEM machen und dann posten, was das im Logfile hinterlässt? Ich bin mir nicht ganz sicher, ob das 100% richtig läuft. Es ist wahrscheinlich nichts schlimmes, da dann ein Device mal kurz in "FAILED" geht, aber nach 10 Sekunden versucht's FHEM nochmal. Aber ich würde gerne herausfinden, was da los ist.
hängt das mit den Änderungen in hm485d.pl zusammen?
Ich habe die Logmeldungen jetzt nicht kopiert. Nach einem shutdown restart bleiben die Module in reading hängen. Die Module funktionieren soweit auch. Wenn ich manuell nochmal ein get config mache, gehen die Module auf CONFIG_OK.
Ich werde heute Abend die neue hm485d.pl einspielen.
Viele Grüße
Stephan
Zitat von: stephan-221 am 23 Juli 2015, 07:51:46
hängt das mit den Änderungen in hm485d.pl zusammen?
Es kann sein, ich bin mir aber nicht sicher. Siehe unten.
Zitat
Nach einem shutdown restart bleiben die Module in reading hängen. Die Module funktionieren soweit auch. Wenn ich manuell nochmal ein get config mache, gehen die Module auf CONFIG_OK.
Es kann gut sein, dass 6 Module reichen um über 252 Nachrichten zu kommen. Dann bleibt es hängen. Da sollte die neue HM485d.pl helfen. Allerdings wundere ich mich, dass es bei einem "get config" dann weitergeht. Bei mir ging es immer nur weiter, wenn ich irgendein anderes get oder set gemacht habe.
Zitat
Ich werde heute Abend die neue hm485d.pl einspielen.
Das wäre nett. Falls es dann immer noch in READING hängenbleibt, bitte mal die Log-Einträge schicken.
Noch etwas: Bei 6 Devices kann es schon ein bisschen dauern. Es ist auch nicht so, dass eins nach dem anderen abgearbeitet wird, sondern mehr oder weniger "parallel".
Gruß,
Thorsten
Hallo Thorsten,
Jetzt habe ich deine aktuelle Version im Test.
nach einem shutdown restart bleiben meine 6 Geräte auch nach 15 Minuten noch in "reading" stehen.
Hier die Logmeldungen:
2015.07.23 22:16:32 3: HM485: HM485: Loading available device files
2015.07.23 22:16:32 3: HM485: =====================================
2015.07.23 22:16:32 3: HM485: Loading device file: ./FHEM/lib/HM485/Devices/hbw_1w_t10.pm
2015.07.23 22:16:32 3: HM485: Loading device file: ./FHEM/lib/HM485/Devices/hbw_sen_ep.pm
2015.07.23 22:16:32 3: HM485: HM485: Error in device file: ./FHEM/lib/HM485/Devices/hbw_sen_ep.pm deactivated:
syntax error at ./FHEM/lib/HM485/Devices/hbw_sen_ep.pm line 51, near ""type""
2015.07.23 22:16:32 3: HM485: Loading device file: ./FHEM/lib/HM485/Devices/hmw-sen-sc-12.pm
2015.07.23 22:16:32 3: HM485: Loading device file: ./FHEM/lib/HM485/Devices/hmw_central.pm
2015.07.23 22:16:32 3: HM485: Loading device file: ./FHEM/lib/HM485/Devices/hmw_generic.pm
2015.07.23 22:16:32 3: HM485: Loading device file: ./FHEM/lib/HM485/Devices/hmw_io12_fm.pm
2015.07.23 22:16:32 3: HM485: Loading device file: ./FHEM/lib/HM485/Devices/hmw_io12_sw14_dr.pm
2015.07.23 22:16:32 3: HM485: Loading device file: ./FHEM/lib/HM485/Devices/hmw_io12_sw7_dr.pm
2015.07.23 22:16:32 3: HM485: Loading device file: ./FHEM/lib/HM485/Devices/hmw_io12_sw7_dr_V3_02.pm
2015.07.23 22:16:33 3: HM485: Loading device file: ./FHEM/lib/HM485/Devices/hmw_io_12_fm.pm
2015.07.23 22:16:33 3: HM485: Loading device file: ./FHEM/lib/HM485/Devices/hmw_io_4_fm.pm
2015.07.23 22:16:33 3: HM485: Loading device file: ./FHEM/lib/HM485/Devices/hmw_io_4_fm_V3_02.pm
2015.07.23 22:16:33 3: HM485: Loading device file: ./FHEM/lib/HM485/Devices/hmw_io_sr_fm.pm
2015.07.23 22:16:33 3: HM485: Loading device file: ./FHEM/lib/HM485/Devices/hmw_lc_bl1_dr.pm
2015.07.23 22:16:33 3: HM485: Loading device file: ./FHEM/lib/HM485/Devices/hmw_lc_bl1_dr_V3_02.pm
2015.07.23 22:16:33 3: HM485: Loading device file: ./FHEM/lib/HM485/Devices/hmw_lc_dim1l_dr.pm
2015.07.23 22:16:34 3: HM485: Loading device file: ./FHEM/lib/HM485/Devices/hmw_lc_sw2_dr.pm
2015.07.23 22:16:34 3: HM485: Loading device file: ./FHEM/lib/HM485/Devices/hmw_lc_sw2_dr_V3_02.pm
2015.07.23 22:16:34 3: HM485: Loading device file: ./FHEM/lib/HM485/Devices/hmw_sen_sc_12_dr.pm
2015.07.23 22:16:34 3: HM485: Loading device file: ./FHEM/lib/HM485/Devices/hmw_virtual.pm
2015.07.23 22:16:35 2: HM485: Assigned HMW_IO_12_Sw14_DR_LEQ0251870 (0000DBA7) to HM485_LAN
2015.07.23 22:16:35 3: HM485: Warte auf Initialisierung Gateway
2015.07.23 22:16:35 2: HM485: Assigned HMW_LC_Bl1_DR_LEQ0249184 (0000DEFE) to HM485_LAN
2015.07.23 22:16:35 3: HM485: Warte auf Initialisierung Gateway
2015.07.23 22:16:35 2: HM485: Assigned HMW_LC_Bl1_DR_LEQ0249544 (0000DD95) to HM485_LAN
2015.07.23 22:16:35 3: HM485: Warte auf Initialisierung Gateway
2015.07.23 22:16:35 2: HM485: Assigned HMW_LC_Bl1_DR_LEQ0249523 (0000DDA2) to HM485_LAN
2015.07.23 22:16:35 3: HM485: Warte auf Initialisierung Gateway
2015.07.23 22:16:39 2: HM485: Assigned HMW_Sen_SC_12_DR_LEQ1184592 (00010D21) to HM485_LAN
2015.07.23 22:16:39 3: HM485: Warte auf Initialisierung Gateway
2015.07.23 22:16:39 2: HM485: Assigned HBW_1W_T10_HBW7341310 (4200AFFE) to HM485_LAN
2015.07.23 22:16:39 3: HM485: Warte auf Initialisierung Gateway
2015.07.23 22:17:39 3: Opening HM485_LAN device localhost:2000
2015.07.23 22:17:39 3: HM485_LAN device opened
2015.07.23 22:17:39 3: HM485_LAN: connected to device localhost:2000
2015.07.23 22:17:42 3: HM485_QueueProcessStep: HASH(0x1d299c0)
2015.07.23 22:17:42 3: HM485: Initialisierung von Modul 0000DBA7
2015.07.23 22:17:42 3: HM485: Initialisierung von Modul 0000DEFE
2015.07.23 22:17:42 3: HM485: Initialisierung von Modul 0000DD95
2015.07.23 22:17:42 3: HM485: Initialisierung von Modul 0000DDA2
2015.07.23 22:17:42 3: HM485: Initialisierung von Modul 00010D21
2015.07.23 22:17:42 3: HM485: Initialisierung von Modul 4200AFFE
2015.07.23 22:17:42 3: HM485_LAN: Lan Device Information
2015.07.23 22:17:42 3: HM485_LAN: Protocol-Version: 01
2015.07.23 22:17:42 3: HM485_LAN: Interface-Type: HMW-SOFT-GW
2015.07.23 22:17:42 3: HM485_LAN: Firmware-Version: 0.2.2
2015.07.23 22:17:42 3: HM485_LAN: Serial-Number: SGW0123456
2015.07.23 22:17:42 3: HM485_LAN: Initialize the interface
2015.07.23 22:17:44 3: HM485_LAN: Event: I[0](3,Y,F,B)(F8) 4200AFFE -> FFFFFFFF [4] 69(i) 00
2015.07.23 22:17:44 3: HM485_LAN: Event: I[0](3,Y,F,B)(F8) 4200AFFE -> FFFFFFFF [4] 69(i) 01
2015.07.23 22:17:44 3: HM485_LAN: Event: I[0](3,Y,F,B)(F8) 4200AFFE -> FFFFFFFF [4] 69(i) 03
2015.07.23 22:17:44 3: HM485_LAN: Event: I[0](3,Y,F,B)(F8) 4200AFFE -> FFFFFFFF [4] 69(i) 06
2015.07.23 22:17:44 3: HM485_LAN: Event: I[0](3,Y,F,B)(F8) 4200AFFE -> FFFFFFFF [4] 69(i) 07
2015.07.23 22:17:44 3: HM485_LAN: Event: I[0](3,Y,F,B)(F8) 4200AFFE -> FFFFFFFF [4] 69(i) 08
2015.07.23 22:17:44 3: HM485_QueueProcessStep: HASH(0x1b62e18)
2015.07.23 22:17:44 3: HM485_LAN: Event: I[0](3,Y,F,B)(F8) 4200AFFE -> FFFFFFFF [4] 69(i) 09
2015.07.23 22:17:44 3: HM485: HBW_1W_T10_HBW7341310_04: temperature -> 22.56
2015.07.23 22:17:44 3: HM485: HBW_1W_T10_HBW7341310_07: temperature -> 29.50
2015.07.23 22:17:44 3: HM485: HBW_1W_T10_HBW7341310_08: temperature -> 24.93
2015.07.23 22:17:44 3: HM485: HBW_1W_T10_HBW7341310_10: temperature -> 25.56
2015.07.23 22:17:44 3: HM485_QueueProcessStep: HASH(0x1d2e198)
2015.07.23 22:17:45 3: HM485_QueueProcessStep: HASH(0x1d2e1b0)
2015.07.23 22:17:45 3: HM485: Request config for device 0000DBA7
2015.07.23 22:17:45 3: HM485: Lese Eeprom 0000DBA7
2015.07.23 22:17:45 3: HM485_LAN: Event: I[2](2,Y,F,B)(DC) 0000DBA7 -> FFFFFFFF [4] 69(i) 11
2015.07.23 22:17:45 3: HM485_QueueProcessStep: HASH(0x1d1e200)
2015.07.23 22:17:45 3: HM485_QueueProcessStep: HASH(0x1e6b808)
2015.07.23 22:17:45 3: HM485_QueueProcessStep: HASH(0x1ce9630)
2015.07.23 22:17:45 3: HM485: Request config for device 0000DEFE
2015.07.23 22:17:45 3: HM485: Lese Eeprom 0000DEFE
2015.07.23 22:17:45 3: HM485_QueueProcessStep: HASH(0x1e7f9a0)
2015.07.23 22:17:45 3: HM485_QueueProcessStep: HASH(0x1cea3b8)
2015.07.23 22:17:46 3: HM485_QueueProcessStep: HASH(0x1e607e8)
2015.07.23 22:17:46 3: HM485: Request config for device 0000DD95
2015.07.23 22:17:46 3: HM485: Lese Eeprom 0000DD95
2015.07.23 22:17:46 3: HM485_QueueProcessStep: HASH(0x1b61cd0)
2015.07.23 22:17:46 3: HM485_QueueProcessStep: HASH(0x1e6bc40)
2015.07.23 22:17:46 3: HM485_QueueProcessStep: HASH(0x1e7f9e8)
2015.07.23 22:17:46 3: HM485: Request config for device 0000DDA2
2015.07.23 22:17:46 3: HM485: Lese Eeprom 0000DDA2
2015.07.23 22:17:46 3: HM485_QueueProcessStep: HASH(0x1e6ba90)
2015.07.23 22:17:46 3: HM485_QueueProcessStep: HASH(0x1d3cc68)
2015.07.23 22:17:46 3: HM485_QueueProcessStep: HASH(0x1e7fb50)
2015.07.23 22:17:46 3: HM485: Request config for device 00010D21
2015.07.23 22:17:46 3: HM485: Lese Eeprom 00010D21
2015.07.23 22:17:47 3: HM485_QueueProcessStep: HASH(0x1e7fb08)
2015.07.23 22:17:47 3: HM485_QueueProcessStep: HASH(0x1e74198)
2015.07.23 22:17:47 3: HM485_QueueProcessStep: HASH(0x1a2a670)
2015.07.23 22:17:47 3: HM485: Request config for device 4200AFFE
2015.07.23 22:17:47 3: HM485: Lese Eeprom 4200AFFE
2015.07.23 22:17:47 3: HM485_QueueProcessStep: HASH(0x1e85848)
2015.07.23 22:17:47 3: HM485_QueueProcessStep: HASH(0x2050fa0)
2015.07.23 22:17:47 3: HM485: Channels initialisieren 0000DBA7
2015.07.23 22:17:48 3: HM485: State der Channels ermitteln 0000DBA7
2015.07.23 22:17:48 3: HM485_QueueProcessStep: HASH(0x2050fe8)
2015.07.23 22:17:48 3: HM485_QueueProcessStep: HASH(0x2051078)
2015.07.23 22:17:48 3: HM485_QueueProcessStep: HASH(0x2051108)
2015.07.23 22:17:48 3: HM485_QueueProcessStep: HASH(0x2051198)
2015.07.23 22:17:48 3: HM485_QueueProcessStep: HASH(0x2051228)
2015.07.23 22:17:48 3: HM485_QueueProcessStep: HASH(0x20512b8)
2015.07.23 22:17:48 3: HM485_QueueProcessStep: HASH(0x2051348)
2015.07.23 22:17:48 3: HM485_QueueProcessStep: HASH(0x20513d8)
2015.07.23 22:17:49 3: HM485_QueueProcessStep: HASH(0x2051468)
2015.07.23 22:17:49 3: HM485_QueueProcessStep: HASH(0x20514f8)
2015.07.23 22:17:49 3: HM485_QueueProcessStep: HASH(0x2054158)
2015.07.23 22:17:49 3: HM485_QueueProcessStep: HASH(0x20541e8)
2015.07.23 22:17:49 3: HM485_QueueProcessStep: HASH(0x2054278)
2015.07.23 22:17:49 3: HM485_QueueProcessStep: HASH(0x2054308)
2015.07.23 22:17:49 3: HM485_QueueProcessStep: HASH(0x2054398)
2015.07.23 22:17:49 3: HM485_QueueProcessStep: HASH(0x2054428)
2015.07.23 22:17:49 3: HM485_QueueProcessStep: HASH(0x20544b8)
2015.07.23 22:17:49 3: HM485_QueueProcessStep: HASH(0x2054548)
2015.07.23 22:17:50 3: HM485_QueueProcessStep: HASH(0x20545d8)
2015.07.23 22:17:50 3: HM485_QueueProcessStep: HASH(0x2054668)
2015.07.23 22:17:50 3: HM485_QueueProcessStep: HASH(0x20546f8)
2015.07.23 22:17:50 3: HM485_QueueProcessStep: HASH(0x2054788)
2015.07.23 22:17:50 3: HM485_QueueProcessStep: HASH(0x2054818)
2015.07.23 22:17:50 3: HM485_QueueProcessStep: HASH(0x20548a8)
2015.07.23 22:17:50 3: HM485_QueueProcessStep: HASH(0x2054938)
2015.07.23 22:17:50 3: HM485_QueueProcessStep: HASH(0x20549c8)
2015.07.23 22:17:50 3: HM485_QueueProcessStep: HASH(0x2054a58)
2015.07.23 22:17:50 3: HM485_QueueProcessStep: HASH(0x2054ae8)
2015.07.23 22:17:51 3: HM485_QueueProcessStep: HASH(0x2054b78)
2015.07.23 22:17:51 3: HM485_QueueProcessStep: HASH(0x2054c08)
2015.07.23 22:17:51 3: HM485_QueueProcessStep: HASH(0x2054c98)
2015.07.23 22:17:51 3: HM485_QueueProcessStep: HASH(0x2054d28)
2015.07.23 22:17:51 3: HM485_QueueProcessStep: HASH(0x207d070)
2015.07.23 22:17:51 3: HM485_QueueProcessStep: HASH(0x207d100)
2015.07.23 22:17:51 3: HM485_QueueProcessStep: HASH(0x207d190)
2015.07.23 22:17:51 3: HM485_QueueProcessStep: HASH(0x207d220)
2015.07.23 22:17:51 3: HM485_QueueProcessStep: HASH(0x207d2b0)
2015.07.23 22:17:52 3: HM485_QueueProcessStep: HASH(0x207d340)
2015.07.23 22:17:52 3: HM485_QueueProcessStep: HASH(0x207d3d0)
2015.07.23 22:17:52 3: HM485_QueueProcessStep: HASH(0x207d460)
2015.07.23 22:17:52 3: HM485_QueueProcessStep: HASH(0x207d4f0)
2015.07.23 22:17:52 3: HM485_QueueProcessStep: HASH(0x207d580)
2015.07.23 22:17:52 3: HM485_QueueProcessStep: HASH(0x207d610)
2015.07.23 22:17:52 3: HM485_QueueProcessStep: HASH(0x207d6a0)
2015.07.23 22:17:52 3: HM485_QueueProcessStep: HASH(0x207d730)
2015.07.23 22:17:53 3: HM485_QueueProcessStep: HASH(0x207d7c0)
2015.07.23 22:17:53 3: HM485_QueueProcessStep: HASH(0x207d850)
2015.07.23 22:17:53 3: HM485_QueueProcessStep: HASH(0x207d8e0)
2015.07.23 22:17:53 3: HM485_QueueProcessStep: HASH(0x207d970)
2015.07.23 22:17:53 3: HM485_QueueProcessStep: HASH(0x207da00)
2015.07.23 22:17:53 3: HM485_QueueProcessStep: HASH(0x207da90)
2015.07.23 22:17:53 3: HM485_QueueProcessStep: HASH(0x207db20)
2015.07.23 22:17:53 3: HM485_QueueProcessStep: HASH(0x207dbb0)
2015.07.23 22:17:53 3: HM485_QueueProcessStep: HASH(0x207dc40)
2015.07.23 22:17:53 3: HM485_QueueProcessStep: HASH(0x207dcd0)
2015.07.23 22:17:53 3: HM485_QueueProcessStep: HASH(0x207dd60)
2015.07.23 22:17:54 3: HM485_QueueProcessStep: HASH(0x207ddf0)
2015.07.23 22:17:54 3: HM485_QueueProcessStep: HASH(0x207de80)
2015.07.23 22:17:54 3: HM485_QueueProcessStep: HASH(0x207df10)
2015.07.23 22:17:54 3: HM485_QueueProcessStep: HASH(0x207dfa0)
2015.07.23 22:17:54 3: HM485_QueueProcessStep: HASH(0x207f678)
2015.07.23 22:17:54 3: HM485_QueueProcessStep: HASH(0x207f708)
2015.07.23 22:17:54 3: HM485_QueueProcessStep: HASH(0x207f798)
2015.07.23 22:17:54 3: HM485_QueueProcessStep: HASH(0x2050ec8)
2015.07.23 22:17:54 3: HM485: Channels initialisieren 0000DEFE
2015.07.23 22:17:54 3: HM485: State der Channels ermitteln 0000DEFE
2015.07.23 22:17:55 3: HM485_QueueProcessStep: HASH(0x2050f10)
2015.07.23 22:17:55 3: HM485_QueueProcessStep: HASH(0x207f828)
2015.07.23 22:17:55 3: HM485_QueueProcessStep: HASH(0x207f8d0)
2015.07.23 22:17:55 3: HM485_QueueProcessStep: HASH(0x207f960)
2015.07.23 22:17:55 3: HM485_QueueProcessStep: HASH(0x207f9f0)
2015.07.23 22:17:55 3: HM485_QueueProcessStep: HASH(0x207fa80)
2015.07.23 22:17:55 3: HM485_QueueProcessStep: HASH(0x207fb10)
2015.07.23 22:17:55 3: HM485_QueueProcessStep: HASH(0x207fba0)
2015.07.23 22:17:55 3: HM485_QueueProcessStep: HASH(0x207fc30)
2015.07.23 22:17:55 3: HM485_QueueProcessStep: HASH(0x207fcc0)
2015.07.23 22:17:56 3: HM485_QueueProcessStep: HASH(0x207fd50)
2015.07.23 22:17:56 3: HM485_QueueProcessStep: HASH(0x207fde0)
2015.07.23 22:17:56 3: HM485_QueueProcessStep: HASH(0x207fe70)
2015.07.23 22:17:56 3: HM485_QueueProcessStep: HASH(0x207ff00)
2015.07.23 22:17:56 3: HM485_QueueProcessStep: HASH(0x207ff90)
2015.07.23 22:17:56 3: HM485_QueueProcessStep: HASH(0x2080020)
2015.07.23 22:17:56 3: HM485_QueueProcessStep: HASH(0x20800b0)
2015.07.23 22:17:56 3: HM485_QueueProcessStep: HASH(0x2080140)
2015.07.23 22:17:56 3: HM485_QueueProcessStep: HASH(0x20801d0)
2015.07.23 22:17:56 3: HM485_QueueProcessStep: HASH(0x2080260)
2015.07.23 22:17:57 3: HM485_QueueProcessStep: HASH(0x20802f0)
2015.07.23 22:17:57 3: HM485_QueueProcessStep: HASH(0x2080380)
2015.07.23 22:17:57 3: HM485_QueueProcessStep: HASH(0x2080410)
2015.07.23 22:17:57 3: HM485_QueueProcessStep: HASH(0x20804a0)
2015.07.23 22:17:57 3: HM485_QueueProcessStep: HASH(0x2080530)
2015.07.23 22:17:57 3: HM485_QueueProcessStep: HASH(0x20805c0)
2015.07.23 22:17:57 3: HM485_QueueProcessStep: HASH(0x2083540)
2015.07.23 22:17:57 3: HM485_QueueProcessStep: HASH(0x20835d0)
2015.07.23 22:17:57 3: HM485_QueueProcessStep: HASH(0x2083660)
2015.07.23 22:17:58 3: HM485_QueueProcessStep: HASH(0x20836f0)
2015.07.23 22:17:58 3: HM485_QueueProcessStep: HASH(0x2083780)
2015.07.23 22:17:58 3: HM485_QueueProcessStep: HASH(0x2083810)
2015.07.23 22:17:58 3: HM485_QueueProcessStep: HASH(0x20838a0)
2015.07.23 22:17:58 3: HM485_QueueProcessStep: HASH(0x2083930)
2015.07.23 22:17:58 3: HM485_QueueProcessStep: HASH(0x20839c0)
2015.07.23 22:17:58 3: HM485_QueueProcessStep: HASH(0x2083a50)
2015.07.23 22:17:58 3: HM485_QueueProcessStep: HASH(0x2083ae0)
2015.07.23 22:17:58 3: HM485_QueueProcessStep: HASH(0x2083b70)
2015.07.23 22:17:58 3: HM485_QueueProcessStep: HASH(0x2083c00)
2015.07.23 22:17:59 3: HM485_QueueProcessStep: HASH(0x2083c90)
2015.07.23 22:17:59 3: HM485_QueueProcessStep: HASH(0x2083d20)
2015.07.23 22:17:59 3: HM485_QueueProcessStep: HASH(0x2083db0)
2015.07.23 22:17:59 3: HM485_QueueProcessStep: HASH(0x2083e40)
2015.07.23 22:17:59 3: HM485_QueueProcessStep: HASH(0x2083ed0)
2015.07.23 22:17:59 3: HM485_QueueProcessStep: HASH(0x2083f60)
2015.07.23 22:17:59 3: HM485_QueueProcessStep: HASH(0x2083ff0)
2015.07.23 22:17:59 3: HM485_QueueProcessStep: HASH(0x2084080)
2015.07.23 22:17:59 3: HM485_QueueProcessStep: HASH(0x2084110)
2015.07.23 22:18:00 3: HM485_QueueProcessStep: HASH(0x20841a0)
2015.07.23 22:18:00 3: HM485_QueueProcessStep: HASH(0x2084230)
2015.07.23 22:18:00 3: HM485_QueueProcessStep: HASH(0x20842c0)
2015.07.23 22:18:00 3: HM485_LAN: Event: I[1](0,Y,F,B)(9A) 0000DBA7 -> FFFFFFFF [4] 69(i) 11
2015.07.23 22:18:00 3: HM485: HMW_IO_12_Sw14_DR_LEQ0251870_18: state -> on
2015.07.23 22:18:00 3: HM485_QueueProcessStep: HASH(0x2084350)
2015.07.23 22:18:00 3: HM485_QueueProcessStep: HASH(0x20843e0)
2015.07.23 22:18:00 3: HM485_QueueProcessStep: HASH(0x2084470)
2015.07.23 22:18:00 3: HM485_QueueProcessStep: HASH(0x2084718)
2015.07.23 22:18:00 3: HM485_QueueProcessStep: HASH(0x20847a8)
2015.07.23 22:18:00 3: HM485_QueueProcessStep: HASH(0x2084838)
2015.07.23 22:18:00 3: HM485_QueueProcessStep: HASH(0x20848c8)
2015.07.23 22:18:01 3: HM485_QueueProcessStep: HASH(0x2084958)
2015.07.23 22:18:01 3: HM485_QueueProcessStep: HASH(0x20849e8)
2015.07.23 22:18:01 3: HM485_QueueProcessStep: HASH(0x2084a78)
2015.07.23 22:18:01 3: HM485_QueueProcessStep: HASH(0x2084b08)
2015.07.23 22:18:01 3: HM485_QueueProcessStep: HASH(0x2084b98)
2015.07.23 22:18:01 3: HM485_QueueProcessStep: HASH(0x2086a48)
2015.07.23 22:18:01 3: HM485: Channels initialisieren 0000DD95
2015.07.23 22:18:01 3: HM485: State der Channels ermitteln 0000DD95
2015.07.23 22:18:01 3: HM485_QueueProcessStep: HASH(0x2086a90)
2015.07.23 22:18:01 3: HM485_QueueProcessStep: HASH(0x2086b20)
2015.07.23 22:18:01 3: HM485_QueueProcessStep: HASH(0x2086bb0)
2015.07.23 22:18:01 3: HM485_QueueProcessStep: HASH(0x2086c40)
2015.07.23 22:18:02 3: HM485_QueueProcessStep: HASH(0x2086cd0)
2015.07.23 22:18:02 3: HM485_QueueProcessStep: HASH(0x2086d60)
2015.07.23 22:18:02 3: HM485_QueueProcessStep: HASH(0x2086df0)
2015.07.23 22:18:02 3: HM485_QueueProcessStep: HASH(0x2086e80)
2015.07.23 22:18:02 3: HM485_QueueProcessStep: HASH(0x2086f10)
2015.07.23 22:18:02 3: HM485_QueueProcessStep: HASH(0x2086fa0)
2015.07.23 22:18:02 3: HM485_QueueProcessStep: HASH(0x2087030)
2015.07.23 22:18:02 3: HM485_QueueProcessStep: HASH(0x20870c0)
2015.07.23 22:18:02 3: HM485_QueueProcessStep: HASH(0x1e7f9a0)
2015.07.23 22:18:03 3: HM485_QueueProcessStep: HASH(0x1cea3b8)
2015.07.23 22:18:03 3: HM485_QueueProcessStep: HASH(0x1afb0d0)
2015.07.23 22:18:03 3: HM485_QueueProcessStep: HASH(0x1d0d780)
2015.07.23 22:18:19 3: HM485_LAN: Event: I[3](0,Y,F,B)(9E) 0000DBA7 -> FFFFFFFF [4] 69(i) 11
2015.07.23 22:18:21 3: HM485_LAN: Event: I[0](3,Y,F,B)(F8) 4200AFFE -> FFFFFFFF [4] 69(i) 02
2015.07.23 22:18:21 3: HM485: HBW_1W_T10_HBW7341310_03: temperature -> 19.87
2015.07.23 22:18:23 3: HM485_LAN: Event: I[0](0,Y,F,B)(98) 0000DBA7 -> FFFFFFFF [4] 69(i) 11
2015.07.23 22:18:23 3: HM485: HMW_IO_12_Sw14_DR_LEQ0251870_18: state -> off
Danach sind nur noch normale Events. in der Queue wird nichts mehr abgearbeitet.
Ein Device bleibt die ganze Zeit in "Response Timeout".
Viele Grüße
Stephan
Zitat von: stephan-221 am 23 Juli 2015, 23:09:46nach einem shutdown restart bleiben meine 6 Geräte auch nach 15 Minuten noch in "reading" stehen.
Blöd...
Zitat
2015.07.23 22:18:03 3: HM485_QueueProcessStep: HASH(0x1cea3b8)
2015.07.23 22:18:03 3: HM485_QueueProcessStep: HASH(0x1afb0d0)
2015.07.23 22:18:03 3: HM485_QueueProcessStep: HASH(0x1d0d780)
2015.07.23 22:18:19 3: HM485_LAN: Event: I[3](0,Y,F,B)(9E) 0000DBA7 -> FFFFFFFF [4] 69(i) 11
2015.07.23 22:18:21 3: HM485_LAN: Event: I[0](3,Y,F,B)(F8) 4200AFFE -> FFFFFFFF [4] 69(i) 02
2015.07.23 22:18:21 3: HM485: HBW_1W_T10_HBW7341310_03: temperature -> 19.87
2015.07.23 22:18:23 3: HM485_LAN: Event: I[0](0,Y,F,B)(98) 0000DBA7 -> FFFFFFFF [4] 69(i) 11
2015.07.23 22:18:23 3: HM485: HMW_IO_12_Sw14_DR_LEQ0251870_18: state -> off
Danach sind nur noch normale Events. in der Queue wird nichts mehr abgearbeitet.
So etwas ähnliches habe ich bei mir auch schonmal gesehen. Ich glaube, dass es damit zusammenhängt. dass FHEM während diesen ganzen Konfigurations-Anforderungen auch noch "ungefragte" Events empfängt. In dem Fall sind das die Temperatur-Meldungen vom HBW_1W_T10. (Wo hatte es gestern Abend denn unter 20 Grad???)
Irgendwas geht da schief mit den Message-Ids. Ich hoffe, dass ich noch dazu komme, das zu knacken.
Zitat
Ein Device bleibt die ganze Zeit in "Response Timeout".
Warum es in den Zustand "Response Timeout" kommt kann viele Ursachen haben. Was ist das denn für ein Device?
Wenn es mal in "Response Timeout" ist, dann ändert sich das nur, wenn es wieder etwas empfängt. Normalerweise passiert das automatisch nach etwa 10 Sekunden durch den waitForConfig-Mechanismus. Wenn aber die Queue hängt, dann passiert einfach gar nichts mehr.
Man kann die Queue ggf. aus dem Schlaf holen, wenn man irgendeinem Device manuell was sendet, also einfach mal auf irgend einen Aktor ein "set ... level ..." machen.
Der Queue-Mechanismus verlässt sich momentan darauf, dass
jede Message in der Queue entweder mit einer Response beantwortet wird oder intern ein NACK erzeugt wird. Anscheinend funktioniert dieser Mechanismus manchmal nicht. Ich könnte jetzt irgendwas mit Timeouts in die Queue-Verarbeitung einbauen, aber ich bevorzuge, die dadurch gefundenen Bugs auszubauen.
Gruß,
Thorsten
Hallo Thorsten,
Zitatnach einem shutdown restart bleiben meine 6 Geräte auch nach 15 Minuten noch in "reading" stehen.
Update via Smartphone mal reingeschaut:
2 der 6 Geräte sind jetzt in OK.
Reading weiterhin bei HMW_LCBl1_DR und HMW_IO_12_Sw14_DR.
(IMHO die Geräte mit großem EEPROM?!)
ZitatWo hatte es gestern Abend denn unter 20 Grad???
In meinem Bastelkeller ;-)
Du hast ja auch von der Irritation der Message IDs gesprochen. Das könnte in der Tat eben ein Problem sein.
Ich kann das mal ohne HBW testen. HBW und IO12/14 sind die beiden Elemente, die von sich aus gerne quatschen.
Alle Devices sind übrigens wieder in ACK.
Viele Grüße
Stephan
Zitat von: stephan-221 am 24 Juli 2015, 11:31:26Reading weiterhin bei HMW_LCBl1_DR und HMW_IO_12_Sw14_DR.
(IMHO die Geräte mit großem EEPROM?!)
Es kann sein, dass Probleme bei Devices mit "großem EEPROM" mit höherer Wahrscheinlichkeit auftreten. Beim Konfig-Lesen gehen da einfach mehr Nachrichten über den Bus und es gibt damit auch mehr Chancen, dass irgendwas schief geht.
Zitat
Alle Devices sind übrigens wieder in ACK.
Ja, das "Response Timeout" löst sich in der Regel von selbst, wenn das Device was sendet. Dabei ist egal, ob als Response, Ack oder Event.
Zitat von: Thorsten Pferdekaemper am 24 Juli 2015, 10:18:22
Der Queue-Mechanismus verlässt sich momentan darauf, dass jede Message in der Queue entweder mit einer Response beantwortet wird oder intern ein NACK erzeugt wird. Anscheinend funktioniert dieser Mechanismus manchmal nicht. Ich könnte jetzt irgendwas mit Timeouts in die Queue-Verarbeitung einbauen, aber ich bevorzuge, die dadurch gefundenen Bugs auszubauen.
Hallo Thorsten,
Ich denke es ist trotzdem sinnvoll Timeouts in die Queue-Verarbeitung einzubauen, da man wahrscheinlich auch nach entfernung der Bugs nicht gänzlich ausschließen kann, das die Queue-Verarbeitung hängen bleibt.
Du kannst ja den timeout über Konstanten am Anfang der 10_HM485.pm konfigurierbar und deaktivierbar machen.
Der Timeout hätte auch den Vorteil, daß Du bei einem Timeout zusätzliche debug infos in den Log schreiben und den state auf timeout setzen kannst.
Beim Testen der Homebrew Module ist mir auch aufgefallen, daß es zu einer Endlosschleife kommt, wenn die DeviceId im Modul nicht zu der im Devicefile passt.
Könntest Du bitte auch mal bei Deiner Version die Versionsnr erhöhen (z.B. auf 150) und dann bei änderungen hochzählen?
Nachtrag: oder reinschreiben, daß es eine Testversion ist und dann eine eigene (Unter) Versionsnr.
Gruß Ralf
Zitat von: Ralf9 am 24 Juli 2015, 13:01:31Ich denke es ist trotzdem sinnvoll Timeouts in die Queue-Verarbeitung einzubauen, da man wahrscheinlich auch nach entfernung der Bugs nicht gänzlich ausschließen kann, das die Queue-Verarbeitung hängen bleibt.
Ja, aber erst kommen die Bugs raus. Sonst ist der Leidensdruck nicht groß genug...
Ein Timeout an der Stelle ist auch gar nicht so einfach. Es kann auch ganz normal recht lange dauern, bis eine Queue abgearbeitet ist. ...aber dazu wird mir auch noch was einfallen.
Zitat
Beim Testen der Homebrew Module ist mir auch aufgefallen, daß es zu einer Endlosschleife kommt, wenn die DeviceId im Modul nicht zu der im Devicefile passt.
Was meinst Du mit DeviceId?
Gruß,
Thorsten
Zitat von: Thorsten Pferdekaemper am 24 Juli 2015, 21:07:10
Was meinst Du mit DeviceId?
Ich habe es verwechselt, ich meinte eigentlich den Devicetype. z.B. 0x81 für HBW-1W-T10. Wenn es dann kein Devicefile mit 129 gibt, dann kommt es zur einer Endlosschleife.
Gruß Ralf
Hi,
ich habe den Bug gefunden, wo das Teil durcheinanderkommt, wenn das Device Events sendet, während eine "Konfig-Queue" abgearbeitet wird. Es kam vor, dass das Device eine Message sendet ganz kurz bevor FHEM einen Befehl schickt. Dann hat ein Teil in FHEM die Message vom Device als Response interpretiert, obwohl der Befehl eigentlich noch gar nicht richtig abgeschickt war.
...war ziemlich schwierig zu finden, sollte aber jetzt funktionieren.
Ein Teil der Probleme sind auch die Homebrew-Module, die sich nicht so 100% an die Timing-Vorgaben des Protokolls halten. Es kann passieren, dass ein Gerät sendet, obwohl der Bus anderweitig belegt ist.
Ich habe auch die vielen Log-Ausgaben auf Level 5 gesetzt, so dass das Log nicht ganz so zugemüllt wird.
Leider bin ich noch nicht dazugekommen, Ralfs Änderungen zu integrieren. Um das oben beschriebene Problem zu lösen braucht man aber die 10_HM485.pm gar nicht. Der Fix ist in den anderen beiden Dateien.
So, jetzt ist es wieder spät geworden. Vielleicht will das jemand testen.
Gruß,
Thorsten
Hallo Thorsten,
die Frühschicht meldet sich zum Dienst....
Ich habe die drei Files eingespielt.
Danach einen kompletten Reload gemacht und alle 7 Module sind in Config OK.
Mal gucken, was den Tag über passiert.
Viele Grüße
Stephan
Hi,
ich bin jetzt so langsam etwas durcheinander gekommen mit meinen eigenen Versionen und was denn noch so offen ist.
Es gibt im Git jetzt einen neuen (oder eher einen auferstandenen) Branch "dev". In den habe ich "meine" aktuelle Version reingepackt. Die Version heißt jetzt 0.6.0.
https://github.com/kc-GitHub/FHEM-HM485/tree/dev (https://github.com/kc-GitHub/FHEM-HM485/tree/dev)
Wenn die nächsten Tage dazu keine "Problemmeldungen kommen", dann packe ich das in den master-Branch.
Die folgenden Sachen sind noch offen:
1. Wenn ein Device auf eine Message tatsächlich mit einem ACK antwortet, dann kann es sein, dass die Queue hängenbleibt. Da bin ich mir aber nicht so ganz sicher, da meine Devices das nicht tun.
Prio niedrig, da es ein "kaputtes" Device voraussetzt.
2. Intelligenteres Lesen des EEPROM ("E-Befehl").
Prio niedrig, da es auch so ganz gut funktioniert. Außerdem: So oft passiert das dann doch nicht.
3. Wiederholen des Konfig-Lesens bzw. regelmäßige Konfig-Lesen-Versuche nach "Device vom Bus" abschaltbar machen.
Prio wird für mich höher, da ich ein Gerät plane, das öfter komplett abgeschaltet wird.
4. Irgendein Mechanismus, der das Ändern der Konfiguration in FHEM verhindert, wenn CONFIG_STATUS nicht auf ok.
Prio "ganz nett" und ich weiß noch nicht so recht, wie das elegant gelöst werden könnte.
5. Zeit bis zur Wiederholung des Konfig-Lesens vergrößern oder einstellbar machen.
Prio: Vielleicht brauchen wir das gar nicht. 10 Sekunden sind gar nicht sooo schlecht. Ansonsten kann man es dem Device überlassen, sich wieder zu melden.
6. Timeout-Lösung für die Konfig-Queue. Das wäre sozusagen für ungeklärte Hänger der Queue. Allerdings ist das gar nicht so einfach, da es auch ganz normal sein kann, dass es eine Weile dauert, bis die Queue abgearbeitet ist.
Prio: Da bin ich mir nicht so sicher. Besser ist manchmal ein hoher Leidensdruck, Bugs auszubauen.
7. Endlosschleife, wenn es zum Modul kein Device-File gibt. D.h. wenn ein Device einen Devicetype (so wie 0x81) zurückmeldet, zu dem es keine Datei gibt.
Prio: Mittel. Solche Devices sollte es nicht geben, aber es deutet auf ein Problem hin.
8. Probleme bei Key-Events. (http://forum.fhem.de/index.php/topic,39397.0 (http://forum.fhem.de/index.php/topic,39397.0)). Am besten Ralfs Coding testen und übernehmen.
Prio: Hoch, sonst kommen wir mit den Versionen durcheinander.
Wahrscheinlich ist da noch mehr, aber das ist erstmal, was ich aus dem Thread hier herauslese.
Ein Problem tritt auf, weil die Homebrew-Devices sich manchmal etwas frech verhalten. Das gehört aber nicht hier hin.
Gruß,
Thorsten
Zitat von: Thorsten Pferdekaemper am 25 Juli 2015, 11:54:548. Probleme bei Key-Events. (http://forum.fhem.de/index.php/topic,39397.0 (http://forum.fhem.de/index.php/topic,39397.0)). Am besten Ralfs Coding testen und übernehmen.
Prio: Hoch, sonst kommen wir mit den Versionen durcheinander.
Das ist jetzt erledigt, siehe http://forum.fhem.de/index.php/topic,39397.msg316063.html#msg316063 (http://forum.fhem.de/index.php/topic,39397.msg316063.html#msg316063)
Zitat von: Thorsten Pferdekaemper am 25 Juli 2015, 11:54:54
7. Endlosschleife, wenn es zum Modul kein Device-File gibt. D.h. wenn ein Device einen Devicetype (so wie 0x81) zurückmeldet, zu dem es keine Datei gibt.
Prio: Mittel. Solche Devices sollte es nicht geben, aber es deutet auf ein Problem hin.
So, das dürfte jetzt auch erledigt sein. (https://github.com/kc-GitHub/FHEM-HM485/tree/dev (https://github.com/kc-GitHub/FHEM-HM485/tree/dev).)
Wenn es zum Devicetype keine Datei gibt, dann wird das Teil als HMW_Generic angelegt. Außerdem erscheint eine Meldung im Log. HMW_Generic-Devices haben keine Kanäle, man kann aber raw-Befehle auf sie loslassen.
Gruß,
Thorsten
Beim Programmieren meines IO-Moduls bin ich auf ein Hardcoding in der sub getFrameInfos($$;$$$) in der device.pm gestossen:
my $frameTypeName = getValueFromDefinitions( $deviceKey . '/channels/' . $chTyp . '/paramset/values/parameter/frequency/physical/get/response');
Wenn man in einem Modul als response ein zusätzlichen info_level mit 2 oder 3 Byte benötigt, funktioniert dies nur wenn der frameTypeName vom entsprechenden response Eintrag im devicefile geholt wird.
Ich habe es so gelöst. Ich hoffe es ist so ok. Es müsste nocht getestet werden ob es mit dem frequenzeingang wie gewünscht funktioniert.
sub getFrameInfos($$;$$$) {
my ($deviceKey, $data, $event, $behaviour, $dir) = @_;
my $frameType = hex( substr( $data, 0, 2)); # 4B
my %retVal;
my $chNr = hex( substr( $data, 2, 2)) + 1;
my $chTyp = HM485::Device::getChannelType( $deviceKey, $chNr);
my $values;
my $frameTypeName = "info_level";
$values = getValueFromDefinitions($deviceKey . '/channels/' . $chTyp . '/paramset/values/parameter/');
if (defined($values)) {
foreach my $value (keys %{$values}) {
#HM485::Util::logger('HM485:Device: getFrameInfos = ', 3, ' $values = ' . $value);
if ( defined( $values->{$value}{physical}{get}{response})) {
$frameTypeName = $values->{$value}{physical}{get}{response};
last;
}
}
}
#HM485::Util::logger('HM485:Device:getFrameInfos', 3, ' frameTypeName = ' . $frameTypeName);
# my $frameTypeName = getValueFromDefinitions( $deviceKey . '/channels/' . $chTyp . '/paramset/values/parameter/frequency/physical/get/response');
# $frameTypeName = $frameTypeName ? $frameTypeName : 'info_level';
if ( $frameTypeName eq "info_frequency" && $behaviour eq "digital_input") {
$frameTypeName = "info_level";
}
..
Gibt es eigentlich im git auch die Möglichkeit die Dateien einzeln herunterzuladen, anstatt alles zusammen im Download.zip?
Gruß Ralf
Hi Ralf,
ich habe Deinen Änderungsvorschlag eingebaut und ins Git hochgeladen. Version ist jetzt 0.6.4.
Um nur eine Date vom Git zu holen gehe ich normalerweise folgendermaßen vor: Ich navigiere zu der Datei. Wenn die Datei angezeigt wird, dann sieht man über dem Text den Button "Raw". Auf der nächsten Seite dann einfach Rechtsklick und dann Datei-> Speichern unter.
..zumindest mit Internet Explorer.
Gruß,
Thorsten