Grundsätzliche Frage zur Diskussion:
Würde es nicht Sinn machen, bei einem "save config" automatisiert eine gewisse Reihenfolge einzuhalten?
- alles unter global
- alle Devices, die I/O Operationen ausführen
- alle anderen Devices
Auf das Thema gekommen bin ich durch diesen Thread und den darin gegebenen, durchaus nachvollziehbaren Hinweis.
http://forum.fhem.de/index.php/topic,20959.0.html
das löst das problem glaube ich nur zum teil. wenn plötzliche alle IODevs vorne stehen und es mehr als ein passendes gibt ist es dann nämlich auch falsch.
ich denke es wäre besser den mechanismus generell umzustellen und das IODev das beim autocreate als 'passend' gefunden wird immer ins attr IODev eintragen und speichern. (in verbindung mit dem $proposed parater verwende ich das schon für die HUEDevices und bin gerade dabei die jeelink module drauf umzustellen. das funktioniert sehr gut und zuverlässig vorhersehbar.)
dann würde es grundsätzlich keine überraschungen mehr geben weil beim neustart etwas nicht mehr passt. die zuordnung wäre fest und hängt nicht mehr von irgend einer reihenfolge ab.
Aber würde das nicht voraussetzen, dass jedes Modul dann im Bedarfsfall so lange warten und den Verbindungsaufbau verzögern/wiederholen muss, bis das IO-Device dann wirklich existiert? Soweit ich gesehen habe, gibt es durchaus Module, die das nicht tun.
wenn das IODev im define noch nicht vorhanden ist funktioniert das assignIodev nicht wirklich. das sollte auch jetzt schon probleme machen.
wenn es vorhanden ist wird er zustand beim anlegen festgeschrieben sofern es der anwender nicht überschreibt.
das sollte im fast allen fällen genau so gut sein wie es die automatische auswahl jetzt ist mit dem zusätzlichen vorteil das es konsistent erhalten bleibt so lange der anwender es nicht explizit ändert.
es sollte also in meinem fall schlechter sein als es jetzt ist und in fast allen fällen die jetzt proble machen deutlich besser.
Zitat von: justme1968 am 04 März 2014, 20:15:47
wenn das IODev im define noch nicht vorhanden ist funktioniert das assignIodev nicht wirklich.
Aber genau das ist doch der Hintergrund meiner Fragestellung...
ich meine dann funktioniert es auch jetzt schon nicht wirklich.
wenn du meinst das durch das nach vorne sortieren beim nächsten starten dann die automatische zuordnung funktioniert stimmt das vermutlich. dann wäre das noch vorne sortieren aller devices die Clients bzw MatchList gesetzt haben auch in verbindung mit dem festen zuweisen sinnvoll.
Zitat von: justme1968 am 04 März 2014, 20:56:03ich meine dann funktioniert es auch jetzt schon nicht wirklich.
So langsam kommst Du dahinter, worum es mir geht :P
das ändert aber nichts daran das mein vorschlag genau so sinnvoll ist :)
Das habe ich nie bestritten - in Kombination können diese beiden Maßnahmen eine erhebliche Stabilisierung bringen.
Zitaterhebliche Stabilisierung
Das klingt schlimmer als es ist, da mAn die Probleme selten auftauchen.
Bei der aktuellen Implementation gibt es ein Problem dann, wenn ein Benutzer sein FS20 vor dem CUL definiert, oder spaeter das CUL entfernt, und z.Bsp. ein neues CUNO anlegt. In diesem Fall schreien beim Anlegen alle FS20-Geraete "No I/O device found". Das IODev Attribut loest das eigentliche Problem, aber nicht die Fehlermeldung im Log, dies kann man z.Zt. nur durch verlegen des IODevs nach vorne machen. Dies ist bei fhem.cfg relativ einfach, bei der configDB vmtl. aufwendiger.
@beteteilchen: Dein Vorschlag wuerde dieses Problem loesen, im folgenden Fall aber Verwirrung stiften: man hat das Erdgeschoss mit CUL+FS20 abgedeckt, nun geht es mit CUNO+FS20 im dritten Stock weiter. Ploetzlich versucht FHEM alle nicht explizit zugeordnete FS20 im Erdgeschoss ueber das CUNO im dritten Stock zu erreichen. Dieser Fall funktioniert aktuell ohne Probleme, IODev Attribut braucht man auch nicht unbedigt.
Z.Zt gefaellt mir ein auf justme1968's Idee basierende Loesung am besten: AssignIoPort setzt das Attribut falls IODev vorhanden, warnt im Fehlerfall aber nur falls !$init_done. Fuer diesen Zweck gibt es eine Schleife nach dem Initalisieren.
Du hast recht, es klingt schlimmer als es ist.
Zitat@beteteilchen: Dein Vorschlag wuerde dieses Problem loesen, im folgenden Fall aber Verwirrung stiften:
Z.Zt gefaellt mir ein auf justme1968's Idee basierende Loesung
Ja, andres Idee mit AssignIoPort finde ich auch sehr gut - deshalb ja auch meine Bemerkung, dass die Kombination aus Sortieren + AssignIoPort wohl die beste Lösung wäre. Da dürfte eigentlich auch der von Dir beschriebene Fall keine Verwirrung mehr stiften.
ZitatDies ist bei fhem.cfg relativ einfach, bei der configDB vmtl. aufwendiger.
Nachdem ich eine Nacht über das ganze Thema geschlafen habe, stellt sich mir die Frage, ob das Problem derzeit ohnehin nicht nur dann auftreten kann, wenn der Benutzer die Einträge in der fhem.cfg von Hand vornimmt und nicht über das Frontend.
Denn:
- Beim "save config" wird die laufende Installation aus dem Speicher weggeschrieben. Man sollte davon ausgehen können, dass diese Konfiguration so funktioniert, wie der Anwender es gerne möchte
- Das Wegschreiben der define erfolgt derzeit numerisch sortiert nach der Reihenfolge der in der aktuellen Konfiguration angelegten define. Es kann also (für mein Verständnis: normalerweise) kein Client-Device VOR seinem zugehörigen IO-Device angelegt sein. Ausnahme: der beschriebene Sonderfall.
- Der beschriebene Sonderfall "mehrere passende IO Devices für das gleiche Client-Device" würde also nur dann zu Problemen führen, wenn die Zuordnung des IO am Client erst nachträglich geändert wird, z.B. weil ein zweites IO Device in Betrieb genommen wird.
- Der beschriebene Sonderfall ließe sich auch bei Verwendung von configDB durch AssignIoPort und korrektes Verhalten des Client-Device (warten bis $init_done) abfangen.
Dieses geforderte "nützliche" Client-Verhalten sollte dann aber irgendwann als wichtiger Entwicklungshinweis /-richtlinie publiziert werden, damit das in die hardwareabhängigen Module auch so eingebaut wird. Damit hätte man wieder einen tatsächlichen Grund weniger, die fhem.cfg "von Hand" ändern (Umstellen der Reihenfolge) zu müssen.
Hab den Vorschlag eingecheckt.
@Betateilchen: ein Problem kann weiterhin auftauchen, falls jemand das IODevice entfernt (delete CUL_0).
ja. Aber Dummheit muss und sollte bestraft werden... 8)
Zitat von: rudolfkoenig am 06 März 2014, 21:07:44
Hab den Vorschlag eingecheckt.
Damit scheint es irgendwelche Probleme zu geben:
http://forum.fhem.de/index.php/topic,21176.0.html
Danke fuer den Hinweis, da ist noch mehr im Argen, z.Bsp. verhaelt sich CUL_WS beim gesetzten IODev Attribut anders, als ohne, siehe http://forum.fhem.de/index.php?topic=21205.new#new
Das ist ein Hack, um Empfang der CUL_WS per 868MHz und 433MHZ parallel zu ermoeglichen, ich habe dafuer eine Ausnahme eingebaut. Auch das HM Problem sollte jetzt umschifft sein, obwohl ich die Ursache nicht verstehe. Die Fixes stehen ab sofort per update zu Verfuegung.
Danke schon mal, dass Ihr diese (doch substanzielle) Änderung unter einem so nichtssagenden Titel diskutiert.
Es macht keinen Sinn das IODev-attribute automatisch (und dauerhaft) zu setzen, weil AssignIOPort dabei auch temporär erzeugte Device eines ServerSockets referenzieren kann, die beim nächsten Reconnect wieder anders heißen.
Wieso überläßt man das dauerhafte Setzen des IODev-attributs nicht einfach dem Aufrufer von AssignIOPort?
mein FRM-modul kommt mit den Änderungen mittlerweile zurecht.
Aber elegant läßt sich AsignIOPort mittlerweile nicht mehr verwenden (https://github.com/ntruchsess/fhem-mirror/blob/master/fhem/FHEM/10_FRM.pm#L539).
Mehrere Zeilen code nötig um mit den Seiteneffekten umzugehen.
ZitatEs macht keinen Sinn das IODev-attribute automatisch (und dauerhaft) zu setzen, weil AssignIOPort dabei auch temporär erzeugte Device eines ServerSockets referenzieren kann, die beim nächsten Reconnect wieder anders heißen.
Sowas ist meiner Ansicht nach eine Ausnahme, ein ServerSocket muss nicht zwangsweise temporaer sein.
ZitatWieso überläßt man das dauerhafte Setzen des IODev-attributs nicht einfach dem Aufrufer von AssignIOPort?
Weil das erstens zu viele Aenderungen benoetigen wuerde, und es zweitens mAn zum Framework gehoert.
Zitat von: rudolfkoenig am 16 März 2014, 13:37:17
Sowas ist meiner Ansicht nach eine Ausnahme, ein ServerSocket muss nicht zwangsweise temporaer sein.
TcpServer_Accept gibt immer (nicht nur ausnahmsweise) ein temporäres Devices (https://github.com/ntruchsess/fhem-mirror/blob/master/fhem/FHEM/TcpServerUtils.pm#L117) zurück. Und es kann durchaus gewollt sein, an dieses (und nicht an das 'Eltern'-devices) als IODev zu koppeln, anders kann ein Modul das über Server-socket angesprochen wird, nie mehr als eine parallele Verbindung unterstützen.
Ich habe vor genau das in FRM zu implementieren, damit man nicht für jeden Network-arduino einen eigenen Port konfigurieren muss.
Zitat von: rudolfkoenig am 16 März 2014, 13:37:17
Weil das erstens zu viele Aenderungen benoetigen wuerde, und es zweitens mAn zum Framework gehoert.
Sehe ich durchaus auch so, aber semantische Veränderungen am Framework spielt man doch bitte nicht einfach mal so ad-hoc ein und wartet dann, welche Module damit nicht klarkommen.
P.S.: kannst Du den Threadtitel bitte in irgendwas ändern, das IODev und AssignIOPort enthält?
Hallo zusammen,
zunächst mal sorry, dass ich so einen alten Thread nochmal hoch hole, aber aus aktuellem Anlass und mit verweis auf diesem Thread: https://forum.fhem.de/index.php/topic,62354.msg538131.html#msg538131
[upd]: Scheint doch ein anderes Problem gewesen zu sein
scheint mir das durchaus Grund genug zu sein.
Ich schildere hier einfach mal chronologisch das Problem, das mich jetzt fast einen ganzen Tag lang beschäftigt hat:
Sichtbar ist das Problem zunächst aufgetreten, da die Fensterkontakte plötzlich relativ lange "nachleuchteten" und anschließend mit rot quittierten. Aufgefallen ist das zuerst meiner Frau an unserer Balkontür. Als ich dann mal ins Log-File schaute stellte ich folgendes fest:
...
2016.12.11 21:07:15 1: PERL WARNING: Use of uninitialized value in string eq at fhem.pl line 4638.
2016.12.11 21:07:30 1: Error: >< has no TYPE, but following keys: >helper<
2016.12.11 21:07:32 1: Error: >< has no TYPE, but following keys: >helper<
2016.12.11 21:07:32 1: PERL WARNING: Use of uninitialized value in string eq at fhem.pl line 4638.
2016.12.11 21:07:32 1: PERL WARNING: Use of uninitialized value in string eq at fhem.pl line 4638.
2016.12.11 21:07:37 1: PERL WARNING: Use of uninitialized value in string eq at fhem.pl line 4638.
2016.12.11 21:07:51 1: PERL WARNING: Use of uninitialized value in string eq at fhem.pl line 4638.
2016.12.11 21:07:57 1: Error: >< has no TYPE, but following keys: >helper<
2016.12.11 21:07:57 1: Error: >< has no TYPE, but following keys: >helper<
2016.12.11 21:08:27 1: PERL WARNING: Use of uninitialized value in string eq at fhem.pl line 4638.
2016.12.11 21:08:32 1: PERL WARNING: Use of uninitialized value in string eq at fhem.pl line 4638.
2016.12.11 21:08:37 1: PERL WARNING: Use of uninitialized value in string eq at fhem.pl line 4638.
2016.12.11 21:09:03 1: PERL WARNING: Use of uninitialized value in string eq at fhem.pl line 4638.
2016.12.11 21:09:37 1: PERL WARNING: Use of uninitialized value in string eq at fhem.pl line 4638.
2016.12.11 21:09:39 1: PERL WARNING: Use of uninitialized value in string eq at fhem.pl line 4638.
2016.12.11 21:10:01 1: Error: >< has no TYPE, but following keys: >helper<
2016.12.11 21:10:15 1: PERL WARNING: Use of uninitialized value in string eq at fhem.pl line 4638.
2016.12.11 21:10:37 1: PERL WARNING: Use of uninitialized value in string eq at fhem.pl line 4638.
2016.12.11 21:10:51 1: PERL WARNING: Use of uninitialized value in string eq at fhem.pl line 4638.
2016.12.11 21:11:27 1: PERL WARNING: Use of uninitialized value in string eq at fhem.pl line 4638.
2016.12.11 21:11:37 1: PERL WARNING: Use of uninitialized value in string eq at fhem.pl line 4638.
2016.12.11 21:12:03 1: PERL WARNING: Use of uninitialized value in string eq at fhem.pl line 4638.
2016.12.11 21:12:32 1: Error: >< has no TYPE, but following keys: >helper<
2016.12.11 21:12:32 1: PERL WARNING: Use of uninitialized value in string eq at fhem.pl line 4638.
2016.12.11 21:12:32 1: PERL WARNING: Use of uninitialized value in string eq at fhem.pl line 4638.
2016.12.11 21:12:37 1: PERL WARNING: Use of uninitialized value in string eq at fhem.pl line 4638.
...
... ohne Ende
Ok! Has "no TYPE" ist mir schon mal untergekommen, meist half ein Neustart.
Den habe ich durchgeführt und finde dabei dann folgendes im Log:
2016.12.11 21:21:03 3: telnetPort: port 7072 opened
2016.12.11 21:21:03 3: WEB: port 8083 opened
2016.12.11 21:21:03 3: WEBphone: port 8084 opened
2016.12.11 21:21:03 3: WEBtablet: port 8085 opened
2016.12.11 21:21:03 3: Opening OG.BU.CM.Fritz.Box.Calls device fritz.box:1012
2016.12.11 21:21:03 3: EG.EZ.SW.Licht.Telefon: unknown IODev HMLAN1 specified
2016.12.11 21:21:03 3: EG.WZ.SW.Subwoofer: unknown IODev HMLAN1 specified
2016.12.11 21:21:03 3: EG.TL.SW.Toilettenlicht: unknown IODev HMLAN1 specified
2016.12.11 21:21:03 3: EG.FL.SW.Flurlicht: unknown IODev HMLAN1 specified
2016.12.11 21:21:03 3: EG.KU.SW.Licht.Decke: unknown IODev HMLAN1 specified
2016.12.11 21:21:03 3: EG.BS.SW.Licht: unknown IODev HMLAN1 specified
2016.12.11 21:21:03 3: EG.BK.TK.Balkontuer.2: unknown IODev HMLAN1 specified
2016.12.11 21:21:03 3: EG.BK.SW.Licht.Balkon: unknown IODev HMLAN1 specified
2016.12.11 21:21:03 3: EG.BK.TK.Balkontuer: unknown IODev HMLAN1 specified
2016.12.11 21:21:03 3: EG.EZ.SW.Stehlampe: unknown IODev HMLAN1 specified
2016.12.11 21:21:03 3: EG.WZ.SW.Deckenfluter: unknown IODev HMLAN1 specified
2016.12.11 21:21:03 3: EG.WZ.SW.Licht.Schrankwand: unknown IODev HMLAN1 specified
2016.12.11 21:21:03 3: EG.BD.SW.Bad: unknown IODev HMLAN1 specified
2016.12.11 21:21:03 3: EG.TR.TK.Haustuere: unknown IODev HMLAN1 specified
2016.12.11 21:21:03 3: EG.EZ.SW.Licht.Tisch: unknown IODev HMLAN1 specified
2016.12.11 21:21:03 3: EG.WZ.SW.Licht.Tisch: unknown IODev HMLAN1 specified
...
u.s.w.
Ok, HMLAN1 hatte ich vor ein paar Wochen ausgemustert und durch einen neuen HMLAN3 ersetzt, der auch brav der ccu zugeordnet ist. Fand ich aber erst mal nicht sehr besorgniserregend, bestenfalls etwas irritierend.
Was danach kam fand ich dann aber schon etwas befremdlicher:
...
2016.12.11 21:21:08 3: No I/O device found for OG.FL.TK.Wohnungstuere
2016.12.11 21:21:08 3: No I/O device found for EG.SP.HZ.Heizung.rechts
2016.12.11 21:21:08 3: No I/O device found for OG.EZ.FK.Essen.hinten
2016.12.11 21:21:08 3: No I/O device found for EG.BK.TK.Balkontuer
2016.12.11 21:21:08 3: No I/O device found for OG.KU.SW.Licht
2016.12.11 21:21:08 3: No I/O device found for EG.TR.TK.Kellertuere
2016.12.11 21:21:08 3: No I/O device found for EG.SZ.HZ.Heizung
2016.12.11 21:21:08 3: No I/O device found for EG.EZ.HZ.Heizung
2016.12.11 21:21:08 3: No I/O device found for OG.FL.FB.Eingang
2016.12.11 21:21:08 3: No I/O device found for HG.XX.WS.Wetter
2016.12.11 21:21:08 3: No I/O device found for OG.WZ.FK.Fluegel.4
2016.12.11 21:21:08 3: No I/O device found for OG.SZ.SW.Licht
2016.12.11 21:21:08 3: No I/O device found for EG.TR.TK.Haustuere
2016.12.11 21:21:08 3: No I/O device found for OG.SZ.FK.links
2016.12.11 21:21:08 3: No I/O device found for OG.EZ.HZ.Heizung
2016.12.11 21:21:08 3: No I/O device found for CUL_HM_HM_SEC_SD_31122A
2016.12.11 21:21:08 3: No I/O device found for EG.KU.FK.Fenster
2016.12.11 21:21:08 3: No I/O device found for WW.Thermostat.Aussen
2016.12.11 21:21:08 3: No I/O device found for OG.BD.HZ.Heizung
2016.12.11 21:21:08 3: No I/O device found for HM_2061BC
2016.12.11 21:21:08 3: No I/O device found for HM_1D2909
2016.12.11 21:21:08 3: No I/O device found for OG.EZ.VA.Heizung
2016.12.11 21:21:08 3: No I/O device found for EG.BD.FK.Badfenster
2016.12.11 21:21:08 3: No I/O device found for EG.BS.SW.Board.links
...
u.s.w.
Klingt nach Problemen! Funktioniert hat dann aber erst mal alles eigentlich ganz normal, nachdem FHEM dann mal vollends oben war. Bis eben auf die Problematik mit den Fenster-/Türkontakten.
Kurz darauf ging es aber wieder mit folgenden Meldungen los:
2016.12.11 21:31:22 1: Error: >< has no TYPE, but following keys: ><
2016.12.11 21:31:23 1: PERL WARNING: Use of uninitialized value in string eq at fhem.pl line 4638.
2016.12.11 21:31:25 3: CUL_HM set OG.TL.SW.Licht on-for-timer 100
2016.12.11 21:31:34 1: Error: >< has no TYPE, but following keys: ><
2016.12.11 21:31:34 1: Error: >< has no TYPE, but following keys: ><
2016.12.11 21:31:34 1: Error: >< has no TYPE, but following keys: ><
2016.12.11 21:31:59 1: PERL WARNING: Use of uninitialized value in string eq at fhem.pl line 4638.
2016.12.11 21:32:00 3: CUL_HM set EG.TL.SW.Toilettenlicht off
2016.12.11 21:32:07 1: PERL WARNING: Use of uninitialized value in string eq at fhem.pl line 4638.
2016.12.11 21:32:08 1: Error: >< has no TYPE, but following keys: ><
2016.12.11 21:32:08 1: Error: >< has no TYPE, but following keys: ><
2016.12.11 21:32:22 1: Error: >< has no TYPE, but following keys: ><
2016.12.11 21:32:22 1: Error: >< has no TYPE, but following keys: ><
Also gut was tun? Erst mal FHEM auf den neusten Stand bringen. Letztes Update war am 28.11. also eigentlich noch nicht so lange her, nichts desto trotz update durchgeführt.
Nach dem Update und Neustart, gleiches Fehlerbild, nur neue Zeilennummern (Klar! :) ):
2016.12.11 21:44:44 3: telnetPort: port 7072 opened
2016.12.11 21:44:44 3: WEB: port 8083 opened
2016.12.11 21:44:44 3: WEBphone: port 8084 opened
2016.12.11 21:44:44 3: WEBtablet: port 8085 opened
2016.12.11 21:44:44 3: Opening OG.BU.CM.Fritz.Box.Calls device fritz.box:1012
2016.12.11 21:44:45 3: EG.EZ.SW.Licht.Telefon: unknown IODev HMLAN1 specified
2016.12.11 21:44:45 3: EG.WZ.SW.Subwoofer: unknown IODev HMLAN1 specified
2016.12.11 21:44:45 3: EG.TL.SW.Toilettenlicht: unknown IODev HMLAN1 specified
2016.12.11 21:44:45 3: EG.FL.SW.Flurlicht: unknown IODev HMLAN1 specified
2016.12.11 21:44:45 3: EG.KU.SW.Licht.Decke: unknown IODev HMLAN1 specified
2016.12.11 21:44:45 3: EG.BS.SW.Licht: unknown IODev HMLAN1 specified
2016.12.11 21:44:45 3: EG.BK.TK.Balkontuer.2: unknown IODev HMLAN1 specified
2016.12.11 21:44:45 3: EG.BK.SW.Licht.Balkon: unknown IODev HMLAN1 specified
...
2016.12.11 21:44:52 3: No I/O device found for OG.FL.TK.Wohnungstuere
2016.12.11 21:44:52 3: No I/O device found for EG.SP.HZ.Heizung.rechts
2016.12.11 21:44:52 3: No I/O device found for OG.EZ.FK.Essen.hinten
2016.12.11 21:44:52 3: No I/O device found for EG.BK.TK.Balkontuer
2016.12.11 21:44:52 3: No I/O device found for OG.KU.SW.Licht
2016.12.11 21:44:52 3: No I/O device found for EG.TR.TK.Kellertuere
2016.12.11 21:44:52 3: No I/O device found for EG.SZ.HZ.Heizung
2016.12.11 21:44:52 3: No I/O device found for EG.EZ.HZ.Heizung
2016.12.11 21:44:52 3: No I/O device found for OG.FL.FB.Eingang
2016.12.11 21:44:52 3: No I/O device found for HG.XX.WS.Wetter
2016.12.11 21:44:52 3: No I/O device found for OG.WZ.FK.Fluegel.4
2016.12.11 21:44:52 3: No I/O device found for OG.SZ.SW.Licht
...
2016.12.11 21:46:41 1: PERL WARNING: Use of uninitialized value in string eq at fhem.pl line 4671.
2016.12.11 21:46:45 3: CUL_HM set EG.TL.SW.Toilettenlicht on-for-timer 1800
2016.12.11 21:46:50 1: PERL WARNING: Use of uninitialized value in string eq at fhem.pl line 4671.
2016.12.11 21:47:17 1: PERL WARNING: Use of uninitialized value in string eq at fhem.pl line 4671.
2016.12.11 21:47:50 1: PERL WARNING: Use of uninitialized value in string eq at fhem.pl line 4671.
2016.12.11 21:47:53 1: PERL WARNING: Use of uninitialized value in string eq at fhem.pl line 4671.
2016.12.11 21:48:29 1: Error: >< has no TYPE, but following keys: ><
2016.12.11 21:48:29 1: Error: >< has no TYPE, but following keys: ><
2016.12.11 21:48:30 1: PERL WARNING: Use of uninitialized value in string eq at fhem.pl line 4671.
2016.12.11 21:48:41 1: Error: >< has no TYPE, but following keys: ><
2016.12.11 21:48:41 1: Error: >< has no TYPE, but following keys: ><
2016.12.11 21:48:41 1: Error: >< has no TYPE, but following keys: ><
Was nun? Stacktrace und verbose 5 war mir erst mal etwas zu viel an Information, außerdem war's mir für den Abend auch schon zu spät. Erst mal drüber schlafen, denn vielleicht kommt die Eingebung ja im Traum oder das Problem erledigt sich genau so plötzlich wieder, wie es aufgetreten ist. Aus Erfahrung weiß ich, dass beides meist leider nicht der Fall ist.
Heute Morgen also weiter geforscht. Problem war natürlich noch da und das Log "vollgemüllt". Ideen hatte ich auch keine neuen. Also erst mal Forum durchforstet. Dabei bin ich zum Einen über den o.g. Thread mit den Türkontakten gestolpert, der zwar ähnliche Symptomatik beschrieb wie bei mir, aber für mich keine zusätzlichen Hinweise lieferte.
Zum Anderen hat mich eine Suche nach "No I/O device found for" zu einem Hinweis von Rudi geführt (https://forum.fhem.de/index.php/topic,10455.msg59249.html#msg59249), der besagte, dass so etwas durch eine falsche Reihenfolge der IODev-Definition in der fhem.cfg hervorgerufen werden könnte. In dem speziellen Fall zwar auf IT gemünzt aber egal, die Grundproblematik bleibt ja die gleiche.
Mein erster Gedanke dazu war natürlich "Hey du benutzt ja configDB, da kann sowas doch eigentlich nicht vorkommen!"
Mein zweiter Gedanke war dann aber. "Nachschauen kostet ja nichts" Habe zwar keine fhem.cfg, aber das bisschen sql ist ja nicht allzu schwer, also mir mal die entsprechende Tabelle aus der configDB für meine aktuelle Version sortiert auflisten lassen und siehe da, was erblickt mein trübes Auge, fast ganz am Ende der Auflistung? Genau meinen neuen HMUART1 und meinen neuen HMLAN3, also weit nach allen anderen Definitionen. :o
Wie kann denn das sein? :-\
Hier meine Vermutung:
Ich hatte bisher 3 HMLANs: HMLAN1 und HMLAN2 zu denen gesellte sich jüngst (vor ca. 3-4 Wochen) ein HM-MOD-RPI-PCB, angebunden über ein WeMos (ESP8266) mittels Modul HMUARTLGW benannt als HMUART1 Der war im Testbetrieb so gut, dass ich relativ schnell feststellte, dass er quasi meine ganze Hütte abdeckt, dort wo er im Moment sitzt. Sollte also so bleiben. Meinen HMLAN2 habe ich abgebaut, da der sowieso gelegentlich disconnects hatte, was aber eher ein Problem mit der Powerline-Anbindung desselben war. HMLAN2 abgebaut und aus der vccu entfernt und aus fhem gelöscht. Alles läuft!
Ganz auf Ausfallsicherheit und auf bewährte HM-IOs wollte ich dennoch nicht ganz verzichten, und habe meinen HMLAN1 (war mein allererster HMLAN, den ich überhaupt hatte) durch ein noch unbenutztes, neues Gerät am selben Netzwerkanschluß ersetzt, in der Hoffnung, das der noch etwas mehr Lebenszeit hat, als der alte (Stichwort "geplante Obsoleszenz") neuer Name für das Gerät HMLAN3 den der vccu hinzugefügt, den alten entfernt und den alten auch aus fhem gelöscht. Alles läuft!
Wann genau nun die Problematik mit den Fensterkontakten und den IODev-Meldungen im Log angefangen hat, kann ich nicht mehr nachvollziehen.
Allerdings vermute ich, dass es nach Neudefinition der beiden neuen IOs und dem Entfernen aller zuvor vorhanden IOs dazu kam, dass die neuen einfach am Ende der Config-Liste gespeichert und ebenso auch eingelesen wurden und damit natürlich ein Reihenfolgen-Problem entstanden ist.
Wie gesagt, Datenbanken und sql sind mir jetzt nicht ganz fremd, also habe ich einfach die Definitionen der beiden IOs und die vccu in der configDB mal (fast) ganz nach vorne geholt, nämlich vor der definition des ersten CUL_HM-devices. Die IOs natürlich vor der vccu.
Anschließender Neustart von FHEM und ... ta-taaaa ... keine Fehlermeldungen mehr im Log und die Fenster- und Türkontakte arbeiteten auch wieder korrekt. 8)
Problem gelöst? Aus meiner Sicht ja! :D
Ich habe ja weiter oben schon auf den anderen Thread verwiesen, der wahrscheinlich die selbe Grundproblematik beschreibt.
[upd]: siehe oben!
Ich gehe auch mal davon aus, dass sich das Problem durch den vermehrten Einsatz des HM-MOD-RPI-PCB und den Ersatz von "alten" HM-IOs durch eben diesen in nächster Zeit etwas häufen wird.
Von daher denke ich könnte es schon sinnvoll sein, diese Diskussion noch mal aufleben zu lassen und eben doch eine gewisse Zwangsreihenfolge in der Config vorzugeben, sowieso wenn man configDB verwendet.
Einen konkreten Vorschlag kann ich dazu aber leider nicht machen.
Ich weiß, das war jetzt ziemlich viel Text (TL;DR? Sorry!)