Neues HM-CC-RT-DN flutet Log-Datei

[holmexx]

Hallo Ansgar,

Es ist nicht gut, wenn Du das mit den ... weg lässt, denn da steckt jeweils ein Stück Vorgeschichte im Log, was u.U. helfen kann, die Glaskugel zu erhellen.

Code Auswählen Erweitern

2024.09.19 18:46:23 3: LogHist Scully:  02847140 A F001 06790724 00 0F 24 8610 787FA4 000000 0AA8D20F1700 -46dB
2024.09.19 18:46:23 3: LogHist Scully:  02859995 A F001 06803576 00 27 10 008E 98FA3F 29F40A 0006FDF7B02F69F1513DFDA3F6AEE7B380E654E1D1DEA12B548C952AEA6F -100.5dB
2024.09.19 18:46:23 3: LogHist Scully:  02863053 A F001 06806636 00 21 10 008E AD12CF 29F40A 16123F7955C0D7EABE22265B2B91EB9DEA64C904164E3853 -102dB
2024.09.19 18:46:23 3: LogHist Scully:  02863239 A F001 06806824 00 21 10 008E AD12CF 29F40A 16123F7BC7A89B0E0CBBBDBA0915BC14B8D8D2B083B8907B -102.5dB
2024.09.19 18:46:23 3: LogHist Scully:  02889292 A F001 06832876 00 0F 62 8610 787C6F 000000 0A88D40A0040 -51dB
2024.09.19 18:46:23 3: LogHist Scully:  02977280 A F001 06920868 00 0D BC A610 48FAD6 250258 06010000 -50dB
2024.09.19 18:46:23 3: LogHist Scully:  02977552 A F001 06921140 00 0D BD A610 48FAD6 250258 06010000 -50dB
2024.09.19 18:46:23 3: LogHist Scully:  02978075 A F001 06921664 00 0D BE A610 48FAD6 250258 06010000 -50dB
2024.09.19 18:46:23 3: LogHist Scully:  02978920 A F001 06922508 00 0D BF A610 48FAD6 250258 06010000 -50dB
2024.09.19 18:46:23 3: LogHist Scully:  02980078 A F001 06923664 00 0D C0 A610 48FAD6 250258 06010000 -50dB
2024.09.19 18:46:23 3: LogHist Scully:  02980141 A F001 06923728 00 0F 25 8610 787FA4 000000 0AA8D20F1700 -46dB
2024.09.19 18:46:23 3: LogHist Scully:  358704                 As 10 26 A001 250258 787FA4 03055802250107
2024.09.19 18:46:23 3: LogHist Scully:  02980848 A F103 06924416 01 09 25 A112 250258 787FA4  _CCAdly:4 _dhmSt:688
2024.09.19 18:46:23 3: TSCUL_ParseTsHM: Scully HM repeat failed to 787FA4/th_Schlafzimmer:  02981087 A F109 06924676 00 09 25 A112 250258 787FA4  _sfail _noAnsw
2024.09.19 18:46:24 3: LogHist Scully:  02977280 A F001 06920868 00 0D BC A610 48FAD6 250258 06010000 -50dB
2024.09.19 18:46:24 3: LogHist Scully:  02977552 A F001 06921140 00 0D BD A610 48FAD6 250258 06010000 -50dB
2024.09.19 18:46:24 3: LogHist Scully:  02978075 A F001 06921664 00 0D BE A610 48FAD6 250258 06010000 -50dB
2024.09.19 18:46:24 3: LogHist Scully:  02978920 A F001 06922508 00 0D BF A610 48FAD6 250258 06010000 -50dB
2024.09.19 18:46:24 3: LogHist Scully:  02980078 A F001 06923664 00 0D C0 A610 48FAD6 250258 06010000 -50dB
2024.09.19 18:46:24 3: LogHist Scully:  02980141 A F001 06923728 00 0F 25 8610 787FA4 000000 0AA8D20F1700 -46dB
2024.09.19 18:46:24 3: LogHist Scully:  358704                 As 10 26 A001 250258 787FA4 03055802250107
2024.09.19 18:46:24 3: LogHist Scully:  02980848 A F103 06924416 01 09 25 A112 250258 787FA4  _CCAdly:4 _dhmSt:688
2024.09.19 18:46:24 3: LogHist Scully:  02981087 A F109 06924676 00 09 25 A112 250258 787FA4  _sfail _noAnsw
2024.09.19 18:46:24 3: LogHist Scully:  02981121 A F103 06924684 01 10 26 A001 250258 787FA4 03055802250107 _CCAdly:4 _dhmSt:956
2024.09.19 18:46:24 3: LogHist Scully:  02981389 A F103 06924952 01 10 26 A001 250258 787FA4 03055802250107 _CCAdly:4 _dhmSt:1224
2024.09.19 18:46:24 3: LogHist Scully:  02981496 A F101 06925084 00 0D C1 A610 48FAD6 250258 06010000 -50dB
2024.09.19 18:46:24 3: LogHist Scully:  02981657 A F103 06925220 01 10 26 A001 250258 787FA4 03055802250107 _CCAdly:4 _dhmSt:1492
2024.09.19 18:46:24 3: TSCUL_ParseTsHM: Scully HM repeat failed to 787FA4/th_Schlafzimmer:  02981895 A F109 06925484 00 10 26 A001 250258 787FA4 03055802250107 _sfail _noAnsw
2024.09.19 18:46:25 3: LogHist Scully:  02980141 A F001 06923728 00 0F 25 8610 787FA4 000000 0AA8D20F1700 -46dB
2024.09.19 18:46:25 3: LogHist Scully:  358704                 As 10 26 A001 250258 787FA4 03055802250107
2024.09.19 18:46:25 3: LogHist Scully:  02980848 A F103 06924416 01 09 25 A112 250258 787FA4  _CCAdly:4 _dhmSt:688
2024.09.19 18:46:25 3: LogHist Scully:  02981087 A F109 06924676 00 09 25 A112 250258 787FA4  _sfail _noAnsw
2024.09.19 18:46:25 3: LogHist Scully:  02981121 A F103 06924684 01 10 26 A001 250258 787FA4 03055802250107 _CCAdly:4 _dhmSt:956
2024.09.19 18:46:25 3: LogHist Scully:  02981389 A F103 06924952 01 10 26 A001 250258 787FA4 03055802250107 _CCAdly:4 _dhmSt:1224
2024.09.19 18:46:25 3: LogHist Scully:  02981496 A F101 06925084 00 0D C1 A610 48FAD6 250258 06010000 -50dB
2024.09.19 18:46:25 3: LogHist Scully:  02981657 A F103 06925220 01 10 26 A001 250258 787FA4 03055802250107 _CCAdly:4 _dhmSt:1492
2024.09.19 18:46:25 3: LogHist Scully:  02981895 A F109 06925484 00 10 26 A001 250258 787FA4 03055802250107 _sfail _noAnsw
2024.09.19 18:46:25 3: LogHist Scully:  361145                 As 0D 27 A001 250258 787FA4 03080510
2024.09.19 18:46:25 3: LogHist Scully:  02982614 A F103 06926176 01 0D 27 A001 250258 787FA4 03080510 _CCAdly:4 _dhmSt:2448
2024.09.19 18:46:25 3: LogHist Scully:  02982878 A F103 06926444 01 0D 27 A001 250258 787FA4 03080510 _CCAdly:4 _dhmSt:2716
2024.09.19 18:46:25 3: LogHist Scully:  02983146 A F103 06926712 01 0D 27 A001 250258 787FA4 03080510 _CCAdly:4 _dhmSt:2984
2024.09.19 18:46:25 3: TSCUL_ParseTsHM: Scully HM repeat failed to 787FA4/th_Schlafzimmer:  02983387 A F109 06926976 00 0D 27 A001 250258 787FA4 03080510 _sfail _noAnsw
Hinweis: 48FAD6 ist ein in der Zwischenzeit hinzugekommender Fensterkontakt, der aber keinerlei Probleme bereitet. Alle anderen hier auftauchenden Geräte gehören nicht zu mir.

ist beim RT ein set clear msgEvents damit die Befehls Queue geleert wird und dann ein getConfig. Und warten, bis der RT seinen Status an broadcast sendet

probiert? Ergebnis? Log? List?

Wie oben dargelegt, habe ich ausschließlich den aus dem ELV-Forum übernommenen umständlichen Pairing-Weg gewählt. Dieser hat zum Erfolg geführt (wie auch im CUL-Listing ersichtlich). Dadurch sind die Fragen entbehrlich.

Ein list vom CUL wäre noch interessant.

habe ich auch nicht grundlos geschrieben.

Dieser Ton ist arrogant und gefällt mir nicht. Das CUL-Listing befindet sich im Anhang.


Ich möchte keinerlei Schärfe einbringen und das auf sachlicher Ebene weiterführen. Seit ich den Forumspost vorhin abgeschickt habe (19:53 Uhr), habe ich mein FHEM-System nicht mehr angefasst und auch nicht beobachtet. Beim Erstellen des Listing des CUL ist mir folgendes aufgefallen:

Readings des th_Schlafzimmer_WindowRec

Code Auswählen Erweitern

RegL_01.                 00:00 08:00 2024-09-19 20:52:15
RegL_03.vfk_Schlafzimmer 00:00 04:32 2024-09-19 20:52:21
RegL_07.vfk_Schlafzimmer 00:00 05:10      2024-09-19 20:52:21
cfgState                 updating         2024-09-19 20:49:28
peerList                 vfk_Schlafzimmer 2024-09-19 20:52:15
state                    peered           2024-09-19 20:52:15

Vom Absetzen des "set vfk_Schlafzimmer peerChan 0 th_Schlafzimmer_WindowRec single set" bis sich das Peering in den Readings niederschlug, sind ~2 Stunden vergangen. Ist das ein normales Verhalten?

Gruß
Holger

[holmexx]

Nachtrag:

Der weiter oben angemahnte Befehl

Code Auswählen Erweitern

set th_Schlafzimmer_WindowRec regSet winOpnTemp 8 vfk_Schlafzimmer

hat jetzt scheinbar funktioniert. Scheinbar deshalb, weil es einerseits keine Fehlermeldung gab, andererseits mir eine Möglichkeit zum Überprüfen fehlt. Einen Hinweis darauf, ob das Rücklesen vielleicht gar nicht möglich ist, oder sich der Wert in den hexadezimalen Reg-Listings befindet, konnte ich im Wiki nicht finden.

Noch eine Beobachtung, da es zeitlich mit dem offenbar erfolgreichen Peering des WindowRec-Channels korreliert: es hat seit 20:49 Uhr keine "_sfail _noAnsw"-Nachricht des th-Schlafzimmer mehr gegeben (Stand 23:53 Uhr).

[noansi]

Hallo Holger,

48FAD6 ist ein in der Zwischenzeit hinzugekommender Fensterkontakt, der aber keinerlei Probleme bereitet. Alle anderen hier auftauchenden Geräte gehören nicht zu mir.

Nun, in ... hat er kurz davor gequasselt und damit indirekt zu _sfail _noAnsw beigetragen.

Code Auswählen Erweitern

2024.09.19 18:46:23 3: LogHist Scully:  02980141 A F001 06923728 00 0F 25 8610 787FA4 000000 0AA8D20F1700 -46dBIst ein Status an "alle", also nicht an deine Zentrale gerichtet.

Code Auswählen Erweitern

2024.09.19 18:46:23 3: LogHist Scully:  02980848 A F103 06924416 01 09 25 A112 250258 787FA4  _CCAdly:4 _dhmSt:688Kommt zu spät. Der RT ist wohl wieder eingeschlafen.
Das ist nicht das eingangs gezeigte Problem.

Dadurch sind die Fragen entbehrlich.

Das Einrichten einer VCCU hat dazu geführt, mehr Infos über Deine Umgebung zu liefern und einen Vergleich mit/ohne VCCU zu ermöglichen. Meine Vergleichsumgebung läuft schon lange mit VCCU, da kann die Variante ohne VCCU nicht betrachtete Code Schwächen aufzeigen.

List vom CUL zeigt mit scF dass Deine "CUL Clock" leicht vorgeht, damit also effektiv delays etwas kürzer ausführt, im Vergleich zu meinen IOs, die etwas "nachgehen". Wenn der RT etwas langsamer wäre und die Toleranz in Summe zu knapp wären, wären im ausführlichen Log häufiger überhörte CUL Antworten erkennbar. Ansatz wäre dann eine Firmware mit etwas mehr Antwort-Delay zu kompilieren.

Gelesene Register sind die Basis für Einstellungsänderungen. Von batteriebetriebenen devices können die nur gelesen werden, wenn sie wach sind, also nicht gerade strom sparen.

hat jetzt scheinbar funktioniert. Scheinbar deshalb, weil es einerseits keine Fehlermeldung gab, andererseits mir eine Möglichkeit zum Überprüfen fehlt. Einen Hinweis darauf, ob das Rücklesen vielleicht gar nicht möglich ist, oder sich der Wert in den hexadezimalen Reg-Listings befindet, konnte ich im Wiki nicht finden.

Code Auswählen Erweitern

cfgState  okIst meist ein gut verständlicher Hinweis, das alle Register gelesen wurden. Den muss man aber erst mal zu sehen bekommen haben.
Mit dem Attribut expert auf defReg,allReg,rawReg bekommst Du mehr von Registern zu sehen.

Wenn Dein Problem nur das "Fluten" des Logs darstellt, beim CUL kannst Du mit dem Attribut hmLogLev eindämmen, ab welchem verbose die kurze LogHist ins Log geschrieben werden soll default ist 3.

Gruß, Ansgar.

[holmexx]

Die meisten Meldungen sind ja von Geräten des Nachbars. Die Leute sind neu im Haus und ich weiß (noch) nicht viel. Ich habe bisher 22 Fremdgeräte identifiziert. Frage: da der CUL der 1%-Regel unterworfen ist, kann das ein Problem sein und vielleicht noch schlimmer werden, da ich alle meine MAXe (4 Thermostate und 5 Fensterkontakte) eigentlich auf HomeMatic umstellen wollte?

Zwischen Absetzen des Befehls und der sichtbaren Reaktion in den Readings (siehe obiger Post, letzte Zeilen) sind 2 Stunden vergangen. Frage: muss ich tatsächlich solange warten?


Seit dem erfolgreichen Pairing gestern tauchte eine "sfail _noAnsw"-Meldung vom th_Schlafzimmer bis jetzt (also gut 19 Stunden) nur ein einziges Mal auf. Das mag wohl dann dem ungünstigen Timing geschuldet sein. Der virtuelle Fensterkontakt ist nun eingebunden und funktioniert -> das Thermostat reagiert.

Das ist nicht das eingangs gezeigte Problem.

Welches ist denn das anfängliche Problem? Ich dachte, dass wäre das nicht erfolgreiche Pairing gewesen.

"cfgState ok" habe ich bei diesem Thermostat noch nie gesehen. Auch heute, jetzt, steht da cfgState updating". Allerdings, wie ich gerade feststelle, auch beim Fensterkontakt. Da dieses Konstrukt ja offenbar funktioniert (sprich das Thermostat regelt runter und wieder rauf passend zum Status des Fensterkontaktes), kann ich die ganzen Meldungen, nicht passenden Status etc. einfach ignorieren? Ich meine, das Heruntersetzen der Verbosity beseitigt ja eventuelle Probleme nicht.

Etwas ketzerisch: ist HomeMatic tatsächlich so schwierig? eq-3 wird sicherlich nicht sooo glücklich sein, dass nicht ihre Zentrale benutzt wird, sondern alles in einer betriebsfremden Umgebung betrieben wird. Was ich sagen will ist: muss ich mich, wenn ich HomeMatic mit FHEM benutzen will darauf einstellen, dass möglicherweise nicht alles rund läuft?

Gruß
Holger

[holmexx]

Ich lasse mir das alles gerade noch mal durch den Kopf gehen, u.a. CUL Clock. Ich betreibe FHEM exklusiv auf einem RaspPI 3B+ im Dauerbetrieb, der mitsamt seinem "originalen" Netzteil zig Jahre alt ist. Wie alt genau kann ich nicht mehr sagen. Der CUL (4 Jahre alt, allerdings bis vor Kurzem ungenutzt) sitzt direkt am USB-Port des RaspPI. Der RaspiPI selbst ist mit einem load von ~0,21 und ~0,8 GB von 4 GB RAM-Nutzung im Langeweile-Bereich. Könnte die Stromversorgung und/oder das allgemeine Alter des Ganzen eine Rolle spielen? Beherrscht Perl auf einem Raspbian Multi-Threading? Kann zu vieles Schreiben in die Logs auf eine vergleichsweise langsame SD-Karte zu Problemen führen?

Nur so allgemeine Gedanken.

[noansi]

Hallo Holger,

hier https://forum.fhem.de/index.php?msg=1320574 gibts den neueren Firmwarestand VTS0.42 nebst aktualiserten Modulen.
Wurde eh mal Zeit dafür.

Da Du beim CUL das Attribut hmForceLzyCfg nicht gesetzt hattest, ist der CUL_HM Code nicht passend gewesen, da der von gesetztem Attribut ausgeht.
getConfig zu einem RT läuft damit sauber durch (keine Störungen dur Zwischengeplapper vorraus gesetzt) mit CULV3 mehrfach wiederholt getestet.
Ich habe das Attribut nun aus TSCUL entfernt. Wakup und Lazy-Config verschleißen mehr das EEPROM. Und damit muss ein CULV3 oder nanoCUL Nutzer vorher überlegen wie viele EEPROM Zugriffe seine automatisierten Umkonfigurationsen von Wakeup und Lazy-Config devices verursachen. Reserve CUL parat zu haben kann nicht schaden.

Deine anderen roten Punkte habe ich auch gefixt, denke ich.

Gruß, Ansgar.

[noansi]

Hallo Holger,

durch den Kopf gehen, u.a. CUL Clock

Hat mein CULV3 genauso. Normal. Modell oder Serienstreuung.

Gruß, Ansgar.

[noansi]

Hallo Holger,

Frage: da der CUL der 1%-Regel unterworfen ist, kann das ein Problem sein und vielleicht noch schlimmer werden

Mit den Nachbarn redet der CUL nicht, wenn Du ihn nicht dazu aufforderst, verschwendet daher auch kein Sendebudget darauf.
Deine credits kannst Du jederzeit beim CUL anschauen. Bursts sind "teuer" und sollten daher sparsam verwendet werden. Dein virtueller Fensterkontakt muss die RTs mit Burst aufwecken, um den Öffnungsstatus übermitteln zu können. Fensterwedeln wäre ungünstig.

Mehr Sorgen würde mir das unerwartete geisterhafte Pairen ungepairter Geräte mit einer Nachbarzentrale machen.

Frage: muss ich tatsächlich solange warten?

Probier die neue Version aus.

Welches ist denn das anfängliche Problem?

Eine unerwartete Protokollmerkwürdigkeit beim Pairen im Vergleich zu Aufwachen mit wach halten hast Du eingangs präsentiert.

Was ich sagen will ist: muss ich mich, wenn ich HomeMatic mit FHEM benutzen will darauf einstellen, dass möglicherweise nicht alles rund läuft?

Meine Testumgebung umfasst u.a. 2 RTs die mit virtuellem TH Sensor und virtuellem Fensterkontakt laufen, jedoch mit CUNX oder SCC als HM IO, somit ohne EEPROM Verschleiß. Mein CULV3 läuft normalerweise an langem Kabel abgesetzt als RFR und spielt mittlerweile nach Abgleich auch Temperatursensor.
Läuft ganz gut, nur ab und zu haben die RTs besseres zu tun und antworten mit NACK statt ACK.
In größerer Entfernung gibt es wohl einen Nachbarn, von dem ab und zu leise ein HM Paket empfangen wird.
Probleme können andere FHEM Module mit langen Rechenzeiten bereiten, so dass Antworten von FHEM verzögert werden und damit insbesondere batteriebetriebene Gräte wieder einschlafen zum Strom sparen.

Funk kann generell Ärger bereiten.
Wie sind Deine Erfahrungen mit MAX?

Gruß, Ansgar.

[holmexx]

Hallo Ansgar,

der CUL ist neu geflasht und die neuen Perl-Module sind eingespielt. Alles verlief völlig unspektakulär. Die ersten 30 Minuten sehen gut aus, keine der vorher in Massen aufgetretenen Meldungen im Log (_sfail _noAnsw/NAME undef for did). Lediglich gleich nach dem Neustart hat mich PERL ein einziges Mal beschimpft:

Code Auswählen Erweitern

PERL WARNING: Use of uninitialized value $1 in addition (+) at ./FHEM/10_CUL_HM.pm line 2086.
Aber nach einem Neustart ist PERL wohl immer etwas aufgeregt. Danke für Arbeit!!

Ich hatte mal 5 MAX-Thermostate und 2 MAX-Fensterkontakte in Betrieb, anfangs an einem originalen MAX-Cube. Diesen hatte ich alsbald zu einem CUL umgeflasht. Elektrisch hat diese Mini-Umgebung zusammen mit FHEM nie Probleme bereitet. Dieses MAX-Alzheimer habe ich nie beobachtet. Mechanisch sieht es da ganz anders aus. Die MAX-Thermostate halten nicht allzulange durch. Relativ schnell schafft es der Motor nicht mehr, das Ventil zu schließen. Ich hatte Eines, das nur eine einzige Saison durchgehalten hat. Aber da ich mal eine ganze Kiste für das sprichwörtliche "Appel und Ei" erworben hatte, hat mich das nicht gestört. Nun sind sie alle.

Mehr Sorgen würde mir das unerwartete geisterhafte Pairen ungepairter Geräte mit einer Nachbarzentrale machen.

Kannst du das mal noch etwas näher erläutern, bitte? Ich habe noch nicht so viel Kontakt mit dem Nachbarn, aber möglicherweise hat er ja auch Probleme? Ich weiß auch nicht, in welcher Umgebung seine Geräte laufen.

Gruß
Holger

[noansi]

Hallo Holger,

Lediglich gleich nach dem Neustart hat mich PERL ein einziges Mal beschimpft:

Das gibt sich, kleine Umstellungsbeschwerde bestehender Readings... dafür kannst Du jetzt bei den unknowns in der VCCU sehen, wie oft und mit welchem RSSI die rein kommen, nebst letztem Ziel und Länge der message.

Ein getConfig zum RT endet nun im cfgState ok nach updating, nachdem die CMDs_pending abgearbeitet sind?

Kannst du das mal noch etwas näher erläutern, bitte?

Franks Feststellung https://forum.fhem.de/index.php?msg=1320458.
Selbst könntest Du es nur gewesen sein, wenn Du da mal das Attribut hmId beim CUL gelöscht und dann gepaired hättest.

Gruß, Ansgar.

[holmexx]

Hallo Ansgar,

Ein getConfig zum RT endet nun im cfgState ok nach updating, nachdem die CMDs_pending abgearbeitet sind?

Ich befürchte, leider nicht (der Neustart war gegen 14:16 Uhr):

Code Auswählen Erweitern

CommandAccepted yes                                                                                       2024-09-21 14:36:12
D-firmware      1.5                                                                                       2024-09-19 17:23:11
D-serialNr      TEQ0440385                                                                                2024-09-19 17:23:11
PairedTo        0x250258                                                                                  2024-09-21 14:16:30
RegL_00.        00:00 01:01 02:01 09:01 0A:25 0B:02 0C:58 0E:0A 0F:00 11:00 12:15 16:00 18:00 19:00 1A:00 2024-09-21 14:16:30
RegL_07.                                                                                                  2024-09-21 14:28:09
battery         ok                                                                                        2024-09-21 17:06:25
batteryLevel    3                                                                                         2024-09-21 17:06:25
cfgState        updating                                                                                  2024-09-21 14:16:29
commState       CMDs_done                                                                                 2024-09-21 14:54:24
motorErr        ok                                                                                        2024-09-21 17:06:25
powerOn         2024-09-18 15:20:52                                                                       2024-09-18 15:20:52
recentStateType info                                                                                      2024-09-18 15:20:52
state           CMDs_done                                                                                 2024-09-21 14:54:24
time-request    -                                                                                         2024-09-21 14:54:24
Lt. Log wurde um 14:34:02 "getConfig" für 787FA4/th_Schlafzimmer abgesetzt. Seitdem wurde nichts mehr geloggt.

Selbst könntest Du es nur gewesen sein, wenn Du da mal das Attribut hmId beim CUL gelöscht und dann gepaired hättest.

Au Mann, ich glaube, ich habe da einen bösen Fehler gemacht. Ich habe FHEM jetzt 3 Mal neu aufgesetzt; die ersten 2 Male allerdings nur die fhem.cfg und alle Log-Dateien weg geworfen. Ich denke, die fhem.save habe ich übersehen. Jetzt, beim 3. Mal, hatte ich kurzerhand den gesamten RaspPi neu aufgesetzt - inkl. neu formatierter SD-Karte. Und Franks Beobachtung ist vor dem kompletten Neumachen entstanden. Asche über mein Haupt.

Gruß
Holger

[holmexx]

... ach, so den Fensterkontakt haben wir ja auch noch:

Code Auswählen Erweitern

PairedTo  0x250258                      2024-09-18 19:28:16
RegL_00.
RegL_01.  00:00 08:01 20:9C 21:00 30:06 2024-09-21 15:18:56
aesKeyNbr 00                            2024-09-18 19:28:15
alive     yes                           2024-09-21 17:05:48
battery   ok                            2024-09-21 17:05:48
cfgState  updating                      2024-09-21 15:18:55
commState CMDs_done                     2024-09-21 17:05:48

Frage: müsste ein entprechendes "getConfig" im Log zu sehen sein, oder passiert das - da anderes Perl-Modul - hier stumm? Die Frage impliziert, dass nämlich kein entsprechender Log-Eintrag da ist. Grrr, das muss ich zurück nehmen. Die SSH-Verbindung zum Pi war unterbrochen.

[noansi]

Hallo Holger,

hast Du ein HMinfo definiert?
Wenn nicht, dann bleibt es bei updating, da die Überprüfung der config nur darin läuft.

Gruß, Ansgar.

[holmexx]

Sorry, immer noch kein Profi. Diese Neuinstallation hat noch kein HMInfo. Wirkt das rückwirkend?

[holmexx]

Meine Frage ist Unsinn, glaube ich. HMinfo ist eingerichtet, ein getConfig für den Fensterkontakt ausgelöst (18:05 Uhr) ...