[Frage] Wie Devices beim "save config" sortieren?

Begonnen von betateilchen, 04 März 2014, 19:21:28

Vorheriges Thema - Nächstes Thema
Drucken
Nach unten Seiten 1 2 Alle
Benutzer-Aktionen

ntruchsess

#15
15 März 2014, 09:44:59 Letzte Bearbeitung: 15 März 2014, 10:23:44 von ntruchsess
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?
while (!asleep()) {sheep++};

ntruchsess

#16
15 März 2014, 12:11:50
mein FRM-modul kommt mit den Änderungen mittlerweile zurecht.

Aber elegant läßt sich AsignIOPort mittlerweile nicht mehr verwenden.
Mehrere Zeilen code nötig um mit den Seiteneffekten umzugehen.

while (!asleep()) {sheep++};

rudolfkoenig

#17
16 März 2014, 13:37:17
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.

ntruchsess

#18
16 März 2014, 14:02:08 Letzte Bearbeitung: 16 März 2014, 14:17:13 von ntruchsess
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 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?
while (!asleep()) {sheep++};

Benni

#19
12 Dezember 2016, 19:47:08 Letzte Bearbeitung: 18 Dezember 2016, 18:39:25 von Benni
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:

Code Auswählen

...
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:

Code Auswählen

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:

Code Auswählen

...
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:

Code Auswählen

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! :) ):

Code Auswählen

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, 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!)
Drucken
Nach oben Seiten 1 2 Alle
Benutzer-Aktionen