[gelöst] keine kommunikation zwischen vd und virtuellem tc nach fhem restart

frank · 02 Oktober 2021, 18:01:32

hallo beta-user,

jetzt hast du wohl wieder etwas voodoo eingebaut.

ZitatMeine virtuellen Temp-Sensoren werden aber auch nicht in der Initialisierung mit angefahren/geloggt, aber sowohl Werte wie Peers sind da; müßte daher ok sein.

genauso bei meinen vtc.

Code Auswählen

2021.10.02 16:57:43.524 1: CUL_HM start inital cleanup
2021.10.02 16:57:48.395 1: CUL_HM finished initial cleanup
2021.10.02 16:57:49.085 1: events: Can't open ./FHEM/holiday/events.holiday: No such file or directory
2021.10.02 16:57:50.238 0: HourCounter Pumpe.Garten.Brunnen.Cnt Run.598 first run done countsOverall:1579
2021.10.02 16:57:50.272 0: HourCounter hc_system_attak Run.598 first run done countsOverall:331
2021.10.02 16:57:50.584 3: CUL_HM set Thermostat.OZ_Climate statusRequest noArg
2021.10.02 16:57:50.720 1: HMLAN_Parse: hmlan1 new condition ok
2021.10.02 16:57:51.052 0: HMLAN_Parse: hmlan1 R:EB3B3B3   stat:0000 t:4A5385B5 d:FF r:FFD5     m:C2 A258 B3B3B3 193A9A 03DC
2021.10.02 16:57:51.056 0: HMLAN_Parse: hmlan1 R:EB1B1B1   stat:0000 t:4A538653 d:FF r:FFD5     m:48 A258 B1B1B1 1BFC52 03FD
2021.10.02 16:57:51.059 0: HMLAN_Parse: hmlan1 R:EB4B4B4   stat:0000 t:4A5386ED d:FF r:FFD5     m:86 A258 B4B4B4 1CE9F5 0300
2021.10.02 16:57:51.063 0: HMLAN_Parse: hmlan1 R:EB2B2B2   stat:0000 t:4A538751 d:FF r:FFD5     m:F5 A258 B2B2B2 1DFC2F 0300
2021.10.02 16:57:51.067 0: HMLAN_Parse: hmlan1 R:EB5B5B5   stat:0000 t:4A53880A d:FF r:FFD5     m:62 A258 B5B5B5 1C4E25 0300
2021.10.02 16:57:51.071 0: HMLAN_Parse: hmlan1 R:EB6B6B6   stat:0000 t:4A53886C d:FF r:FFD5     m:17 A258 B6B6B6 1F91AA 0300

warum auch immer werden nun knapp 3s nach initial cleanup trotzdem die ersten valvePos msgs rausgehauen und in der folge auch weiterhin regelmässig gesendet. vielleicht durch mein at, denn die fehlermeldungen wegen ungültigem cmd valvePos sind auch nicht mehr zu sehen. erstmal auch egal, prima so.

das internal .AttrList im channel vom vtc existiert weiterhin nicht, sodass ich das attr param msgReduce:2 weiterhin nach restart erneut setzen muss, damit es wirkung hat. das lässt sich aber erstmal über notify lösen.

Beta-User · 02 Oktober 2021, 18:10:25

Schade nur, dass ich das gar nicht so dolle finde. Gut, es ist besser wie nichts, aber eben Voodoo... (Und nicht so, wie es gedacht gewesen zu sein scheint.)

Beta-User · 03 Oktober 2021, 13:16:16

Kurze Zwischenmeldung - habe mir den Startvorgang jetzt nochmal angeschaut, und bin jetzt irgendwie ratlos:

Wenn HMinfo definiert ist, scheint das eine eigene Startlogik zu fahren, und dann scheint es auch richtig zu sein, dass die configCheck -f-Anfragen nicht mehr abgefeuert werden, schon gleich in der Menge.

Bin noch unsicher, ob es sinnvoll wäre, die configChecks für die Hauptkanäle beim "INITIALIZED"-Event durchzuführen. Beim Versuch, das reinzucoden habe ich dann aber festgestellt, dass jedenfalls das INITIALIZED-Event in der NotifyFn von CUL_HM gar nicht dazu führt, dass der Zweig überhaupt ausgeführt wird. Ergo muss der initDone-Marker für CUL_HM schon aktiviert worden sein. Nur: Wo...?!?

Jetzt bin ich irgendwie grade lost, wie das eigentlich gedacht ist.
Meine aktuellen - möglicherweise wieder völlig falschen - Gedanken:
Wenn HMinfo vorhanden ist, muss das bevorzugt benachrichtigt werden, und dann erst seine INIT-Funktion ausführen (im Moment: wohl früher/zu früh im Rahmen von DefFn?), und dann erst CUL_HM, das dann eigentlich nur noch sicherstellen muss, dass für die virtuellen Kanäle die Einstellungen passen (was derzeit keinen Ort zu haben scheint).
Defür müsste aber die Notify-Priorität von HMinfo erhöht werden, sonst kommt "50-C" vor "50-H". Oder man ruft die INIT-Fn aus CUL_HM heraus auf?

(Das muss niemand verstehen, ist nur, damit ich es irgendwo mal festgehalten habe).

frank · 04 Oktober 2021, 12:51:49

ZitatDas muss niemand verstehen

den zusammenhang von hminfo und vtc verstehe ich wirklich nicht.

durch hminfo werden zusätzliche funktionen bereitgestellt. aber selbstständig unternimmt es eigentlich nichts, ausser das attr autoupdate ist gesetzt.

alle basis funktionen von cul_hm sind doch hoffentlich unabhängig von hminfo. also auch der restart.

Beta-User · 04 Oktober 2021, 13:14:43

Hmm, irgendwie sind die Funktionsaufrufe teils so ineinander verschachtelt, dass ich ernsthafte Schwierigkeiten habe nachzuvollziehen, was wann aus welchem Anlass und mit welchem Ziel passiert.

Ich hab's jetzt nochmal versucht, auf einen für mich verständlichen Level runterzubrechen

. Danach würde ich mal folgenden "Soll-Ablauf" in den Raum werfen:

1. FHEM startet und liest alle Attribute und Readings ein. Bevor $init_done ist, werden v.a. auch die Attribute in den CUL_HM-entities nicht ausgewertet
2. Bevor irgendwas anderes mit den CUL_HM-Instanzen versucht zu arbeiten, müssen die fertig konfiguriert werden. Das kann unterstützt werden durch HMinfo, (v.a. wenn autoupdate gesetzt ist), diese Unterstützung ist aber kein Muss. Nur wenn eingesetzt, sollte HMinfo vor CUL_HM fertig sein.
Da die virtuellen entities von den realen abhängig sind, sollte man sicherheitshalber erst den configCheck über die realen laufen lassen, und dann erst danach die davon ggf. abhängigen (ist evtl. "too much").
3. Erst, wenn das durch ist, dürfen Timer, andere Eventhandler, usw. dann loslegen.

Anbei jetzt doch der Versuch, das event-basiert in den Griff zu bekommen, und zwar erst HMinfo, dann CUL_HM, dann whatever (was halt nicht mit Gewalt nach vorne gedrängt wird). Bitte ggf. das Loggen in msec aktivieren, sonst sieht das uU. von der Reihenfolge her komisch aus.
Ob das irgendwie weiterbringt im Hinblick auf die noch offenen Punkte kann ich aber im Moment nicht sagen...
Ein diff sollte die Stellschrauben offenbaren, damit du ggf. die Reihenfolge auch umdrehen kannst.

frank · 04 Oktober 2021, 14:50:22

ZitatHmm, irgendwie sind die Funktionsaufrufe teils so ineinander verschachtelt, dass ich ernsthafte Schwierigkeiten habe nachzuvollziehen, was wann aus welchem Anlass und mit welchem Ziel passiert.

nach meiner logik, ohne in den code zu schauen, muss hminfo so schnell wie möglich starten, damit die zusätzlichen "komfort" funktionen rechtzeitig existieren, punkt.

cul_hm muss natürlich selber wissen, wann der aufruf einer hminfo funktion sinn macht, logisch.
diese aufrufe können und dürfen aber eben nur zusätzliche infos liefern, da cul_hm auch ohne hminfo funktionieren soll.

ich habe zb den verdacht, dass die vielen doppelten "configCheck -f" aufrufe existieren, weil martin nicht den einen ultimativen zeitpunkt ermilttelt, wann alle voraussetzungen für einen endgültigen configcheck erledigt sind, sondern jeweils erneut nach diversen aktionen, die jeweils eine auswirkung auf configcheck haben könnten.

ein reading cfgState soll ja auch im normalen betrieb, nicht nur nach restart, zu jeder zeit immer das aktuelle configcheck ergebnis wiederspiegeln. diverse aktionen müssen also immer einen configcheck triggern.

ausserdem würde ich keine wette eingehen, dass ein "configcheck -f" in fhem log auch wirklich grundsätzlich zur ausführung kommt.

zumindestens statusrequest beim restart zeigt in fhem.log auch diverse fake einträge an.

ZitatDa die virtuellen entities von den realen abhängig sind,

das verstehe ich nicht.
virtuelle geràte müssen doch auch ohne reale geräte existieren können. ob es immer sinn macht ist doch erstmal egal.

Beta-User · 04 Oktober 2021, 15:29:08

Zitat von: frank am 04 Oktober 2021, 14:50:22
nach meiner logik, ohne in den code zu schauen, muss hminfo so schnell wie möglich starten, damit die zusätzlichen "komfort" funktionen rechtzeitig existieren, punkt.

Da sind wir uns einig. Für mich ist nur offen, ob erst CUL_HM fertig werden muss oder HMinfo. Hab's jetzt mal mit Prio HMinfo gelöst, aber es ist einfach, das umzudrehen ($hash->{NotifyOrderPrefix}).

Zitatcul_hm muss natürlich selber wissen, wann der aufruf einer hminfo funktion sinn macht, logisch.
diese aufrufe können und dürfen aber eben nur zusätzliche infos liefern, da cul_hm auch ohne hminfo funktionieren soll.

So sollte es sein. Mein Problem: eine gewisse Anzahl von verketteten Aufrufen kann ich nachvollziehen. Hier hat das aber teilweise Ausmaße, bei denen ich es aufschreiben müßte und ich hatte den Eindruck, dass es teils zufällig war, in welcher Reihenfolge auch an der Stelle dann was (wiederholt?) aufgerufen wurde.

Jetzt habe ich zumindest mal versucht, den "äußeren Rahmen" so festzuzurren, dass Zufälligkeiten weitestgehend eliminiert sein sollten. Was ich noch nicht weiß: ist es die richtige Reihenfolge...

Zitatich habe zb den verdacht, dass die vielen doppelten "configCheck -f" aufrufe existieren, weil martin nicht den einen ultimativen zeitpunkt ermilttelt, wann alle voraussetzungen für einen endgültigen configcheck erledigt sind, sondern jeweils erneut nach diversen aktionen, die jeweils eine auswirkung auf configcheck haben könnten.

Bei einem Teil bin ich einigermaßen sicher, dass das so nicht gedacht gewesen sein kann. Die denkbare (und definitiv nicht auszuschließende) Alternative ist in der Tat, dass es keine andere Möglichkeit gab, diese häufigen Aufrufe als "Nebenwirkung" zu vermeiden.
Da aber bisher so viel zufällig passiert ist, kann es natürlich sein, dass diese Art impliziter Reparaturversuch teilweise geholfen hat, diese Zufälligkeiten zu kompensieren, und der "sortierte Versuch" jetzt (erst mal!) im Ergebnis schlechter ist. ABER: bisher funktionierte die "sortierte Fassung" (ohne configCheck!) von vorgestern ja besser als die fuzzy-logic-repaired svn-Fassung. Von daher halte ich das Risiko an der Stelle für eher gering.

Zitat
ein reading cfgState soll ja auch im normalen betrieb, nicht nur nach restart, zu jeder zeit immer das aktuelle configcheck ergebnis wiederspiegeln. diverse aktionen müssen also immer einen configcheck triggern.

Klar, und die configChecks sind jetzt ja im laufenden Betrieb auch nicht ausgeschaltet, sondern sie müßten jetzt nur im Startvorgang an einer sehr bestimmten Stelle erfolgen (wenn das jetzt alles funktioniert wie gedacht).

Zitatausserdem würde ich keine wette eingehen, dass ein "configcheck -f" in fhem log auch wirklich grundsätzlich zur ausführung kommt.
zumindestens statusrequest beim restart zeigt in fhem.log auch diverse fake einträge an.

Das ist ein Punkt, über den ich lange gerätselt habe. Tatsächlich hat der Start aber lt. Log mit den 700+ "-f"-Einträgen ziemlich lange gedauert, ohne dass sonst was an erkennbarer Aktion im Log gestanden hätte. Von daher war an der Stelle meine Arbeitshypothese, dass die Aufrufe auf alle Fälle vorkommen müßten, und zwar
- reduziert auf 1x pro Hauptdevice (da sind dann sowieso alle Kanäle mit drin) und
- vor dem Start von irgendwas anderem (deinem at, z.B., oder dem notify, das das hier erzeugt: https://wiki.fhem.de/wiki/HM-Dis-WM55_Funk_Statusanzeige#fhemUser.cfg; das war btw. überhaupt der Anlaß, warum ich mir dann doch nochmal einen Ruck gegeben habe...).

Zitat
das verstehe ich nicht.
virtuelle geràte müssen doch auch ohne reale geräte existieren können. ob es immer sinn macht ist doch erstmal egal.

Das tun sie. Aber nur als Buttons. Um was anderes zu werden, brauchen sie "spezielle" Peers, und - soweit ich das jetzt verstanden habe - anhand des Peer-Typs wird ermittelt, welche Kommandos sie verstehen. Ergo sollte die endgültige Konfiguration einer virturellen entity erst erfolgen, wenn die übrige Hardware "bekannt" ist.

In der svn-Version ist das entweder zu früh oder timer-basiert geschehen, wenn meine Interpretation meiner Logs zutreffend ist.

frank · 04 Oktober 2021, 18:51:10

deine aktuelle cul_hm/hminfo kombi von hier hat bezüglich den vtc nicht neues gebracht.

Code Auswählen

2021.10.04 17:13:44.916 3: CUL_HM set Thermostat.WZ_Climate controlMode central
2021.10.04 17:13:45.606 3: CUL_HM set Thermostat.Bad.OG_Climate controlMode central
2021.10.04 17:13:46.427 3: CUL_HM set Thermostat.Keller_Climate controlMode central
2021.10.04 17:13:46.865 3: CUL_HM set Thermostat.SZ_Climate controlMode central
2021.10.04 17:13:49.646 1: CUL_HM start inital cleanup
2021.10.04 17:13:54.558 1: CUL_HM finished initial cleanup
2021.10.04 17:13:58.738 3: Opening SqueezeBoxServer device 192.168.1.10:9090
2021.10.04 17:14:01.743 1: SqueezeBoxServer: Can't connect to 192.168.1.10:9090: Connection timed out
2021.10.04 17:14:01.761 3: SB_SERVER_Notify(SqueezeBoxServer): DISCONNECTED - STATE: disconnected power: ?
2021.10.04 17:14:01.780 0: HMCCU: Start of RPC server after FHEM initialization in 12 seconds
2021.10.04 17:14:01.799 3: Opening hmuart1 device /dev/ttyAMA0
2021.10.04 17:14:01.801 3: Setting hmuart1 serial parameters to 115200,8,N,1
2021.10.04 17:14:01.805 3: hmuart1 device opened
2021.10.04 17:14:01.952 3: cul433 IT_set: IT09 on
2021.10.04 17:14:02.721 0: Featurelevel: 6
2021.10.04 17:14:02.722 0: Server started with 525 defined entities (fhem.pl:24776/2021-07-19 perl:5.028001 os:linux user:fhem pid:2394)
2021.10.04 17:14:03.475 1: events: Can't open ./FHEM/holiday/events.holiday: No such file or directory
2021.10.04 17:14:04.739 0: HourCounter Pumpe.Garten.Brunnen.Cnt Run.598 first run done countsOverall:1579
2021.10.04 17:14:04.775 0: HourCounter hc_system_attak Run.598 first run done countsOverall:331
2021.10.04 17:14:04.991 1: HMLAN_Parse: hmlan1 new condition ok
2021.10.04 17:14:05.086 3: CUL_HM set Thermostat.OZ_Climate statusRequest noArg
2021.10.04 17:14:05.290 3: CUL_HM set Thermostat.AZ_Climate statusRequest noArg
2021.10.04 17:14:05.399 3: CUL_HM set Thermostat.SZ_Climate statusRequest noArg
2021.10.04 17:14:05.629 0: HMLAN_Parse: hmlan1 R:EB3B3B3   stat:0000 t:54AF75F3 d:FF r:FFD3     m:37 A258 B3B3B3 193A9A 0330
2021.10.04 17:14:05.634 0: HMLAN_Parse: hmlan1 R:EB1B1B1   stat:0000 t:54AF76A2 d:FF r:FFD4     m:BF A258 B1B1B1 1BFC52 03FD
2021.10.04 17:14:05.638 0: HMLAN_Parse: hmlan1 R:EB4B4B4   stat:0000 t:54AF774C d:FF r:FFD4     m:FC A258 B4B4B4 1CE9F5 0300
2021.10.04 17:14:05.642 0: HMLAN_Parse: hmlan1 R:EB2B2B2   stat:0000 t:54AF77B7 d:FF r:FFD4     m:6C A258 B2B2B2 1DFC2F 0300
2021.10.04 17:14:05.646 0: HMLAN_Parse: hmlan1 R:EB5B5B5   stat:0000 t:54AF7868 d:FF r:FFD4     m:D9 A258 B5B5B5 1C4E25 0300
2021.10.04 17:14:05.650 0: HMLAN_Parse: hmlan1 R:EB6B6B6   stat:0000 t:54AF78CF d:FF r:FFD4     m:8E A258 B6B6B6 1F91AA 0300

wegen den fehlenden log einträgen während cleanup, starten die vtc immer noch über voodoo oder mein at.
jetzt allerdings ca 11 sec nach cleanup.
auch bzgl attr param msgReduce nichts neues.

weitere verbesserungen gab es bei den "falschen" configcheck meldungen https://forum.fhem.de/index.php/topic,123152.msg1176825.html#msg1176825. die punkte 1-3 haben sich nun wohl erledigt, wodurch kein manueller configcheck mehr nötig ist.

frank · 04 Oktober 2021, 19:05:39

noch vergessen: zeile 433 erzeugt ja ein event valveCtrl=restart.

nach meinen logs sehe ich das letzte auftreten am 27.09 12:43 uhr. das war vermutlich der restart nach dem update auf martins aktuelle version. siehe erster beitrag hier im thread.
anschliessend habe ich immer mit deinen versionen neu gestartet, die diesen code nicht mehr erreichen.

Beta-User · 04 Oktober 2021, 19:27:25

Kannst du bitte auch mal die Prio drehen ($hash->{NotifyOrderPrefix}-Wert in beiden Modulen einfach vertauschen)? (ich sehe dann zwar weiter keine Einträge von "Stufe 2", aber doppelt genäht...)

Das mit dem entfallenden manuellen configCheck würde ich mal auf das Verschieben in INITIALIZED-NotifyFn schieben.

Ich vermute, dass das mit dem internen vtc-Start noch nie funktioniert hat, aber wenn der Rest jetzt soweit paßt und nicht mehr Voodoo ist, finden wir vielleicht auch noch einen Hebel, um auch das noch zu fixen... (OK, deine Gegenthese betr. die korrekte Ausführung am 27.09. habe ich gesehen).

"11 sec nach cleanup" ist positiv gemeint, oder wie muss ich das deuten?

Zur Erläuterung des Logs: die controlMode-Anweisungen sind Folge der HMinfo-Initialisierung, und was mich etwas wundert, ist dass da zwischen init und finish nix von ActionDetector auftaucht, und auch keine configCheck-Messages (verbose jeweils auf 2, nehme ich an?).

Falls die kommende Stunde nichts gravierendes eintritt, würde ich dazu tendieren, das (mit umgedrehter Prio?) als neuen Komplettpatch in den Ring zu werfen, weil zumindest auch die Punkte 1-3 damit (so oder so?) erledigt sind...?

Beta-User · 04 Oktober 2021, 22:55:07

OK, jetzt zündet zwar auch Stufe 2, allerdings habe ich FHEM jetzt so oft gestartet, dass näherungsweise alle meine virtuellen Temp-Sensoren aus dem Tritt geraten zu sein scheinen. Oder liegt es am Code...? Oder an noch fehlenden "auto"-Einstellungen in HMinfo?

Na ja, hier jedenfalls mal (doch wieder erst zum Testen) der entsprechende Code - dieses Mal ist erst CUL_HM mit der Initialisierung fertig...

EDIT: nachdem sich meine Thermostate über Nacht beruhigt haben: https://forum.fhem.de/index.php/topic,123198.msg1177945.html#msg1177945

frank · 05 Oktober 2021, 13:49:43

mit den neuen versionen zündet stufe2 auch bei mir und alle ventile haben erneut den restart überlebt.

attr param msgreduce muss weiterhin manuell erfolgen.

für dich nun auch mal das log mit verbose=3 für hminfo und actiondetector:

Code Auswählen

2021.10.05 09:58:46.321 1: CUL_HM start inital cleanup
2021.10.05 09:58:46.471 3: Device DimUP01 added to ActionDetector with 024:00 time
2021.10.05 09:58:46.506 3: Device Fenster.Bad added to ActionDetector with 028:00 time
2021.10.05 09:58:46.541 3: Device SD.AZ added to ActionDetector with 099:00 time
2021.10.05 09:58:46.576 3: Device SD.SZ added to ActionDetector with 099:00 time
2021.10.05 09:58:46.610 3: Device SD.WZ added to ActionDetector with 099:00 time
2021.10.05 09:58:46.861 3: Device SwitchES01 added to ActionDetector with 000:15 time
2021.10.05 09:58:47.023 3: Device SwitchPBU01 added to ActionDetector with 000:10 time
2021.10.05 09:58:47.060 3: Device SwitchPBU03 added to ActionDetector with 028:00 time
2021.10.05 09:58:47.097 3: Device SwitchPBU05 added to ActionDetector with 024:00 time
2021.10.05 09:58:47.134 3: Device SwitchPBU06 added to ActionDetector with 024:00 time
2021.10.05 09:58:47.170 3: Device SwitchUP01 added to ActionDetector with 024:00 time
2021.10.05 09:58:47.206 3: Device SwitchUP02 added to ActionDetector with 024:00 time
2021.10.05 09:58:47.345 3: Device Thermostat.AZ added to ActionDetector with 000:10 time
2021.10.05 09:58:47.476 3: Device Thermostat.Bad added to ActionDetector with 000:10 time
2021.10.05 09:58:47.606 3: Device Thermostat.Bad.OG added to ActionDetector with 000:10 time
2021.10.05 09:58:47.736 3: Device Thermostat.GZ added to ActionDetector with 000:10 time
2021.10.05 09:58:47.867 3: Device Thermostat.Keller added to ActionDetector with 000:10 time
2021.10.05 09:58:47.997 3: Device Thermostat.Kueche added to ActionDetector with 000:10 time
2021.10.05 09:58:48.128 3: Device Thermostat.OZ added to ActionDetector with 000:10 time
2021.10.05 09:58:48.258 3: Device Thermostat.SZ added to ActionDetector with 000:10 time
2021.10.05 09:58:48.390 3: Device Thermostat.WZ added to ActionDetector with 000:10 time
2021.10.05 09:58:48.426 3: Device Tuer.SZ added to ActionDetector with 028:00 time
2021.10.05 09:58:48.462 3: Device Tuer.WZ.Terrasse added to ActionDetector with 028:00 time
2021.10.05 09:58:48.497 3: Device Ventil.AZ.Nord added to ActionDetector with 001:30 time
2021.10.05 09:58:48.533 3: Device Ventil.AZ.West added to ActionDetector with 001:30 time
2021.10.05 09:58:48.569 3: Device Ventil.Bad added to ActionDetector with 001:30 time
2021.10.05 09:58:48.604 3: Device Ventil.Kueche added to ActionDetector with 001:30 time
2021.10.05 09:58:48.640 3: Device Ventil.SZ added to ActionDetector with 001:30 time
2021.10.05 09:58:48.676 3: Device Ventil.WZ added to ActionDetector with 001:30 time
2021.10.05 09:58:48.875 3: Device Wetter.Sued added to ActionDetector with 000:10 time
2021.10.05 09:58:50.694 1: ----- test2 ----- -> n:VentilControler.AZ.Nord_Btn1
2021.10.05 09:58:50.886 3: set VentilControler.AZ.West_Btn1 valvePos 0 : Unknown argument valvePos, choose one of regSet peerChan clear:msgErrors,noArg,readings,trigger,register,oldRegs,rssi,msgEvents,attack,all press peerBulk regBulk postEvent:slider,0,1,255 getConfig:noArg getRegRaw peerSmart:DimPBU01_Dim,DimPBU01_Dim_V_01,DimPBU01_Dim_V_02,DimUP01,Fenster.Bad,SD.AZ,SD.SZ,SD.WZ,SDTeam_Btn1,SwitchES01_SenF,SwitchES01_SenI,SwitchES01_SenPwr,SwitchES01_SenU,SwitchES01_Sw,SwitchPBU01_Btn_01,SwitchPBU01_Btn_02,SwitchPBU01_Sw_01,SwitchPBU01_Sw_02,SwitchPBU02_Btn_01,SwitchPBU02_Btn_02,SwitchPBU02_Sw_01,SwitchPBU02_Sw_02,SwitchPBU03,SwitchPBU05,SwitchPBU06,SwitchUP01,SwitchUP02,Tuer.SZ,Tuer.WZ.Terrasse,VentilControler.AZ.Nord_Btn1,VentilControler.Bad_Btn1,VentilControler.Kueche_Btn1,VentilControler.SZ_Btn1,VentilControler.WZ_Btn1,ccu_Btn1,rssi_hmuart_Btn1,virtAktorAlarmOff_Btn1 
2021.10.05 09:58:50.887 3: n_set_VentilControler.AZ.West return value: Unknown argument valvePos, choose one of regSet peerChan clear:msgErrors,noArg,readings,trigger,register,oldRegs,rssi,msgEvents,attack,all press peerBulk regBulk postEvent:slider,0,1,255 getConfig:noArg getRegRaw peerSmart:DimPBU01_Dim,DimPBU01_Dim_V_01,DimPBU01_Dim_V_02,DimUP01,Fenster.Bad,SD.AZ,SD.SZ,SD.WZ,SDTeam_Btn1,SwitchES01_SenF,SwitchES01_SenI,SwitchES01_SenPwr,SwitchES01_SenU,SwitchES01_Sw,SwitchPBU01_Btn_01,SwitchPBU01_Btn_02,SwitchPBU01_Sw_01,SwitchPBU01_Sw_02,SwitchPBU02_Btn_01,SwitchPBU02_Btn_02,SwitchPBU02_Sw_01,SwitchPBU02_Sw_02,SwitchPBU03,SwitchPBU05,SwitchPBU06,SwitchUP01,SwitchUP02,Tuer.SZ,Tuer.WZ.Terrasse,VentilControler.AZ.Nord_Btn1,VentilControler.Bad_Btn1,VentilControler.Kueche_Btn1,VentilControler.SZ_Btn1,VentilControler.WZ_Btn1,ccu_Btn1,rssi_hmuart_Btn1,virtAktorAlarmOff_Btn1 
2021.10.05 09:58:50.994 1: ----- test2 ----- -> n:VentilControler.AZ.West_Btn1
2021.10.05 09:58:51.283 1: ----- test2 ----- -> n:VentilControler.Bad_Btn1
2021.10.05 09:58:51.572 1: ----- test2 ----- -> n:VentilControler.Kueche_Btn1
2021.10.05 09:58:51.862 1: ----- test2 ----- -> n:VentilControler.SZ_Btn1
2021.10.05 09:58:52.158 1: ----- test2 ----- -> n:VentilControler.WZ_Btn1
2021.10.05 09:58:53.080 1: CUL_HM finished initial cleanup
2021.10.05 09:58:53.101 3: HMinfo hminfo get:configCheck :-f,^(ActionDetector|ActionDetector)$
2021.10.05 09:58:53.102 3: HMinfo hminfo get:configCheck :-f,^(DimUP01|DimUP01)$
2021.10.05 09:58:53.102 3: HMinfo hminfo get:configCheck :-f,^(Fenster.Bad|Fenster.Bad)$
2021.10.05 09:58:53.103 3: HMinfo hminfo get:configCheck :-f,^(SD.AZ|SD.AZ)$
2021.10.05 09:58:53.104 3: HMinfo hminfo get:configCheck :-f,^(SD.SZ|SD.SZ)$
2021.10.05 09:58:53.104 3: HMinfo hminfo get:configCheck :-f,^(SD.WZ|SD.WZ)$
2021.10.05 09:58:53.105 3: HMinfo hminfo get:configCheck :-f,^(SwitchES01|SwitchES01_Pwr|SwitchES01_SenF|SwitchES01_SenI|SwitchES01_SenPwr|SwitchES01_SenU|SwitchES01_Sw|SwitchES01)$
2021.10.05 09:58:53.106 3: HMinfo hminfo get:configCheck :-f,^(SwitchPBU01|SwitchPBU01_Btn_01|SwitchPBU01_Btn_02|SwitchPBU01_Sw_01|SwitchPBU01_Sw_02|SwitchPBU01)$
2021.10.05 09:58:53.106 3: HMinfo hminfo get:configCheck :-f,^(SwitchPBU03|SwitchPBU03)$
2021.10.05 09:58:53.107 3: HMinfo hminfo get:configCheck :-f,^(SwitchPBU05|SwitchPBU05)$
2021.10.05 09:58:53.107 3: HMinfo hminfo get:configCheck :-f,^(SwitchPBU06|SwitchPBU06)$
2021.10.05 09:58:53.108 3: HMinfo hminfo get:configCheck :-f,^(SwitchUP01|SwitchUP01)$
2021.10.05 09:58:53.109 3: HMinfo hminfo get:configCheck :-f,^(SwitchUP02|SwitchUP02)$
2021.10.05 09:58:53.109 3: HMinfo hminfo get:configCheck :-f,^(Thermostat.AZ|Thermostat.AZ_Climate|Thermostat.AZ_Weather|Thermostat.AZ_WindowRec|Thermostat.AZ)$
2021.10.05 09:58:53.110 3: HMinfo hminfo get:configCheck :-f,^(Thermostat.Bad|Thermostat.Bad_Climate|Thermostat.Bad_Weather|Thermostat.Bad_WindowRec|Thermostat.Bad)$
2021.10.05 09:58:53.111 3: HMinfo hminfo get:configCheck :-f,^(Thermostat.Bad.OG|Thermostat.Bad.OG_Climate|Thermostat.Bad.OG_Weather|Thermostat.Bad.OG_WindowRec|Thermostat.Bad.OG)$
2021.10.05 09:58:53.111 3: HMinfo hminfo get:configCheck :-f,^(Thermostat.GZ|Thermostat.GZ_Climate|Thermostat.GZ_Weather|Thermostat.GZ_WindowRec|Thermostat.GZ)$
2021.10.05 09:58:53.112 3: HMinfo hminfo get:configCheck :-f,^(Thermostat.Keller|Thermostat.Keller_Climate|Thermostat.Keller_Weather|Thermostat.Keller_WindowRec|Thermostat.Keller)$
2021.10.05 09:58:53.112 3: HMinfo hminfo get:configCheck :-f,^(Thermostat.Kueche|Thermostat.Kueche_Climate|Thermostat.Kueche_Weather|Thermostat.Kueche_WindowRec|Thermostat.Kueche)$
2021.10.05 09:58:53.113 3: HMinfo hminfo get:configCheck :-f,^(Thermostat.OZ|Thermostat.OZ_Climate|Thermostat.OZ_Weather|Thermostat.OZ_WindowRec|Thermostat.OZ)$
2021.10.05 09:58:53.114 3: HMinfo hminfo get:configCheck :-f,^(Thermostat.SZ|Thermostat.SZ_Climate|Thermostat.SZ_Weather|Thermostat.SZ_WindowRec|Thermostat.SZ)$
2021.10.05 09:58:53.114 3: HMinfo hminfo get:configCheck :-f,^(Thermostat.WZ|Thermostat.WZ_Climate|Thermostat.WZ_Weather|Thermostat.WZ_WindowRec|Thermostat.WZ)$
2021.10.05 09:58:53.115 3: HMinfo hminfo get:configCheck :-f,^(Tuer.SZ|Tuer.SZ)$
2021.10.05 09:58:53.116 3: HMinfo hminfo get:configCheck :-f,^(Tuer.WZ.Terrasse|Tuer.WZ.Terrasse)$
2021.10.05 09:58:53.116 3: HMinfo hminfo get:configCheck :-f,^(Ventil.AZ.Nord|Ventil.AZ.Nord)$
2021.10.05 09:58:53.117 3: HMinfo hminfo get:configCheck :-f,^(Ventil.AZ.West|Ventil.AZ.West)$
2021.10.05 09:58:53.117 3: HMinfo hminfo get:configCheck :-f,^(Ventil.Bad|Ventil.Bad)$
2021.10.05 09:58:53.118 3: HMinfo hminfo get:configCheck :-f,^(Ventil.Kueche|Ventil.Kueche)$
2021.10.05 09:58:53.119 3: HMinfo hminfo get:configCheck :-f,^(Ventil.SZ|Ventil.SZ)$
2021.10.05 09:58:53.119 3: HMinfo hminfo get:configCheck :-f,^(Ventil.WZ|Ventil.WZ)$
2021.10.05 09:58:53.120 3: HMinfo hminfo get:configCheck :-f,^(Wetter.Sued|Wetter.Sued)$
2021.10.05 09:58:53.121 3: HMinfo hminfo get:configCheck :-f,^(ccu|ccu_Btn1|ccu_Btn2|ccu_Btn3|ccu_Btn4|ccu_Btn5|ccu)$
2021.10.05 09:58:53.121 3: HMinfo hminfo get:configCheck :-f,^(SDTeam|SDTeam_Btn1|SDTeam)$
2021.10.05 09:58:53.122 3: HMinfo hminfo get:configCheck :-f,^(VentilControler.AZ.Nord|VentilControler.AZ.Nord_Btn1|VentilControler.AZ.Nord)$
2021.10.05 09:58:53.123 3: HMinfo hminfo get:configCheck :-f,^(VentilControler.AZ.West|VentilControler.AZ.West_Btn1|VentilControler.AZ.West)$
2021.10.05 09:58:53.124 3: HMinfo hminfo get:configCheck :-f,^(VentilControler.Bad|VentilControler.Bad_Btn1|VentilControler.Bad)$
2021.10.05 09:58:53.124 3: HMinfo hminfo get:configCheck :-f,^(VentilControler.Kueche|VentilControler.Kueche_Btn1|VentilControler.Kueche)$
2021.10.05 09:58:53.125 3: HMinfo hminfo get:configCheck :-f,^(VentilControler.SZ|VentilControler.SZ_Btn1|VentilControler.SZ)$
2021.10.05 09:58:53.125 3: HMinfo hminfo get:configCheck :-f,^(VentilControler.WZ|VentilControler.WZ_Btn1|VentilControler.WZ)$
2021.10.05 09:58:53.126 3: HMinfo hminfo get:configCheck :-f,^(rssi_hmuart|rssi_hmuart_Btn1|rssi_hmuart)$
2021.10.05 09:58:53.127 3: HMinfo hminfo get:configCheck :-f,^(virtAktorAlarmOff|virtAktorAlarmOff_Btn1|virtAktorAlarmOff)$
2021.10.05 09:58:53.163 3: HMinfo hminfo get:loadConfig :
2021.10.05 09:58:53.632 3: HMinfo hminfo get:configCheck :
2021.10.05 09:58:55.237 3: Opening SqueezeBoxServer device 192.168.1.10:9090
2021.10.05 09:58:58.242 1: SqueezeBoxServer: Can't connect to 192.168.1.10:9090: Connection timed out
2021.10.05 09:58:58.260 3: SB_SERVER_Notify(SqueezeBoxServer): DISCONNECTED - STATE: disconnected power: ?
2021.10.05 09:58:58.278 0: HMCCU: Start of RPC server after FHEM initialization in 12 seconds
2021.10.05 09:58:58.297 3: Opening hmuart1 device /dev/ttyAMA0
2021.10.05 09:58:58.299 3: Setting hmuart1 serial parameters to 115200,8,N,1
2021.10.05 09:58:58.303 3: hmuart1 device opened
2021.10.05 09:58:58.448 3: cul433 IT_set: IT09 on
2021.10.05 09:58:59.191 0: Featurelevel: 6
2021.10.05 09:58:59.192 0: Server started with 524 defined entities (fhem.pl:24776/2021-07-19 perl:5.028001 os:linux user:fhem pid:4136)
2021.10.05 09:58:59.916 1: events: Can't open ./FHEM/holiday/events.holiday: No such file or directory
2021.10.05 09:59:00.754 0: HourCounter Pumpe.Garten.Brunnen.Cnt Run.598 first run done countsOverall:1579
2021.10.05 09:59:00.801 0: HourCounter hc_system_attak Run.598 first run done countsOverall:331
2021.10.05 09:59:01.368 4: CUL_Parse: cul868 A 14 17 805E 266EA5 1ACE1F 000000000000000000000023 -56.5
2021.10.05 09:59:01.511 1: HMLAN_Parse: hmlan1 new condition ok
2021.10.05 09:59:01.560 0: HMLAN_Parse: hmlan1 R:EB5B5B5   stat:0000 t:58477DDA d:FF r:FFD5     m:66 A258 B5B5B5 1C4E25 0300
2021.10.05 09:59:01.563 0: HMLAN_Parse: hmlan1 R:EB6B6B6   stat:0000 t:58477F04 d:FF r:FFD5     m:1A A258 B6B6B6 1F91AA 0300
2021.10.05 09:59:01.567 0: HMLAN_Parse: hmlan1 R:EB3B3B3   stat:0000 t:58478025 d:FF r:FFD5     m:C4 A258 B3B3B3 193A9A 034C
2021.10.05 09:59:01.571 0: HMLAN_Parse: hmlan1 R:EB1B1B1   stat:0000 t:58478147 d:FF r:FFD5     m:4C A258 B1B1B1 1BFC52 03FD
2021.10.05 09:59:01.574 0: HMLAN_Parse: hmlan1 R:EB2B2B2   stat:0000 t:58478268 d:FF r:FFD5     m:F8 A258 B2B2B2 1DFC2F 03FD
2021.10.05 09:59:01.578 0: HMLAN_Parse: hmlan1 R:EB4B4B4   stat:0000 t:58478390 d:FF r:FFD5     m:87 A258 B4B4B4 1CE9F5 03FD

anmerkungen:

1. durch die fehlermeldungen merke ich so langsam wieder, was da so alles läuft.

4/6 ventilen werden über mein at mit valvepos gefüttert. die anderen 2 ventile bekommen ihr valvepos über notify von 2 ventilen aus der ersten gruppe, da in 2 räumen jeweils 2 heizkörper existieren.
durch die reihenfolge der bearbeitung der devices in cul_hm_updateconfig wird hier nun einmal eine fehlermeldung durch dieses notify geworfen.
das notify n_set_VentilControler.AZ.West reagiert auf die neue valvepos von VentilControler.AZ.Nord_Btn1 und will VentilControler.AZ.West_Btn1 mit valvepos versorgen. das wird aber erst anschliessend konfiguriert und hat dadurch noch keinen gültigen cmd valvepos.

beim anderen pärchen (VentilControler.SZ_Btn1,VentilControler.WZ_Btn1) passt die reihenfolge zufällig.

Code Auswählen

2021.10.05 09:58:50.694 1: ----- test2 ----- -> n:VentilControler.AZ.Nord_Btn1
2021.10.05 09:58:50.886 3: set VentilControler.AZ.West_Btn1 valvePos 0 : Unknown argument valvePos, choose one of regSet peerChan clear:msgErrors,noArg,readings,trigger,register,oldRegs,rssi,msgEvents,attack,all press peerBulk regBulk postEvent:slider,0,1,255 getConfig:noArg getRegRaw peerSmart:DimPBU01_Dim,DimPBU01_Dim_V_01,DimPBU01_Dim_V_02,DimUP01,Fenster.Bad,SD.AZ,SD.SZ,SD.WZ,SDTeam_Btn1,SwitchES01_SenF,SwitchES01_SenI,SwitchES01_SenPwr,SwitchES01_SenU,SwitchES01_Sw,SwitchPBU01_Btn_01,SwitchPBU01_Btn_02,SwitchPBU01_Sw_01,SwitchPBU01_Sw_02,SwitchPBU02_Btn_01,SwitchPBU02_Btn_02,SwitchPBU02_Sw_01,SwitchPBU02_Sw_02,SwitchPBU03,SwitchPBU05,SwitchPBU06,SwitchUP01,SwitchUP02,Tuer.SZ,Tuer.WZ.Terrasse,VentilControler.AZ.Nord_Btn1,VentilControler.Bad_Btn1,VentilControler.Kueche_Btn1,VentilControler.SZ_Btn1,VentilControler.WZ_Btn1,ccu_Btn1,rssi_hmuart_Btn1,virtAktorAlarmOff_Btn1
2021.10.05 09:58:50.887 3: n_set_VentilControler.AZ.West return value: Unknown argument valvePos, choose one of regSet peerChan clear:msgErrors,noArg,readings,trigger,register,oldRegs,rssi,msgEvents,attack,all press peerBulk regBulk postEvent:slider,0,1,255 getConfig:noArg getRegRaw peerSmart:DimPBU01_Dim,DimPBU01_Dim_V_01,DimPBU01_Dim_V_02,DimUP01,Fenster.Bad,SD.AZ,SD.SZ,SD.WZ,SDTeam_Btn1,SwitchES01_SenF,SwitchES01_SenI,SwitchES01_SenPwr,SwitchES01_SenU,SwitchES01_Sw,SwitchPBU01_Btn_01,SwitchPBU01_Btn_02,SwitchPBU01_Sw_01,SwitchPBU01_Sw_02,SwitchPBU02_Btn_01,SwitchPBU02_Btn_02,SwitchPBU02_Sw_01,SwitchPBU02_Sw_02,SwitchPBU03,SwitchPBU05,SwitchPBU06,SwitchUP01,SwitchUP02,Tuer.SZ,Tuer.WZ.Terrasse,VentilControler.AZ.Nord_Btn1,VentilControler.Bad_Btn1,VentilControler.Kueche_Btn1,VentilControler.SZ_Btn1,VentilControler.WZ_Btn1,ccu_Btn1,rssi_hmuart_Btn1,virtAktorAlarmOff_Btn1 
2021.10.05 09:58:50.994 1: ----- test2 ----- -> n:VentilControler.AZ.West_Btn1

2. die configchecks sind jetzt zwar nicht mehr doppelt, aber noch viele sinnlos, denke ich.

wenn ich das richtig überblicke wird für alle devices (inklusive channel) ein "configcheck -f" ausgelöst.
anschliessend nach loadconfig gibt es noch einen "grossen" configcheck auf alles.
wenn es abschliessend den grossen configcheck gibt, sind die anderen vorher eigentlich alle überflüssig, oder?
ausserdem gibt es einen configcheck für den actiondetector, der sowieso sinnlos ist, oder übersehe ich hier etwas.

eigentlich wollte martin den automatischen configcheck so wenig wie nötig aufrufen, da er das system belastet.
daher gibt es "configcheck -f" aufrufe, denn diese checken ja nur einen kleinen teil des systems. über irgendeine logik wusste er beim restart welche devices zu checken sind. es gab also nicht "configcheck -f" für alle devices, sondern immer nur für einen teil aller devices.

etwa 60s nach dem loadconfig gibt es bei mir noch eine salve "configcheck -f" mit "ausgewählten" devices.
das könnte diese gruppe sein. diese gruppe ist scheinbar auch nach jedem restart anders zusammengesetzt.

vermutlich ist auch diese nachträgliche configcheck salve eigentlich überflüssig durch den bereits erfolgten "grossen" configcheck, den martin eigentlich vermeiden wollte, so wie ich es mal verstanden hatte.

aber wie schon spekuliert, gab es scheinbar ein paar configchecks als "pflaster".

Beta-User · 05 Oktober 2021, 15:32:19

Zitat von: frank am 05 Oktober 2021, 13:49:43
mit den neuen versionen zündet stufe2 auch bei mir und alle ventile haben erneut den restart überlebt.

So weit, so gut!

Zitat
attr param msgreduce muss weiterhin manuell erfolgen.

Das klingt danach, als wäre das Attribut zwischendurch mal "nicht erlaubt" (und folglich gelöscht). Stellt sich die Frage, ob man das ggf. (nur während der Initialisierung?) zuläßt (unschön, relativ viel Zusatzcode)? Besser wäre es, die Reihenfolge so zu fixieren, dass das gar nicht erst passiert - ich habe nur noch keine Idee, wo...

Zitat
4/6 ventilen werden über mein at mit valvepos gefüttert. die anderen 2 ventile bekommen ihr valvepos über notify von 2 ventilen aus der ersten gruppe, da in 2 räumen jeweils 2 heizkörper existieren.

OK, das erklärt das "unknown argument" und so langsam habe ich auch eine Idee, warum Martin das timer-basiert machen wollte. Dann wären nämlich alle Basiskonfigurationen durch, bevor "irgendwer anderes" Wind davon bekommt (z.B. dein notify), dass CUL_HM (in Teilen) wieder läuft. Das dürfte der Gedanke hinter der "Doppelverwendung" von $evtDly gewesen sein, aber irgendwo scheint es da noch eine Lücke zu geben. Leider klappt es dann wohl nicht, innerhalb der vorgezogenen event-loop andere Eventhandler erst dann abzuarbeiten, wenn die interne NotifyFn durch ist. Hmmm...

Nach meinen bisherigen Erfahrungen würde ich sagen, dass eine vollständige Rückkehr zu einer timer-Initialisierung keine gute Idee ist. Andere Meinungen?

Ergo brauchen wir sowas wie einen Mittelweg, wobei es zumindest zur Lösung des von dir aufgezeigten Abhängigkeitsproblems wahrscheinlich genügen würde, die Kommandos aus der Initialisierung der paar virtuellen Kanäle rauszunehmen und in eine gesonderte Timer-Funktion zu verlagern.
Dann sollte auch die "zufällige" Reihenfolge kein Problem mehr sein.
Werde ich angehen.

Zitat2. die configchecks sind jetzt zwar nicht mehr doppelt, aber noch viele sinnlos, denke ich.

Na ja, jetzt sind est erst mal "nur noch viele" statt bisher sehr, sehr viele (die wurden nämlich durch die svn-Version auch noch für alle Kanäle aufgerufen, wenn ich das damalige Log richtig im Kopf habe)...

Ob die vorher abgearbeitet wurden (bzw. jetzt, weil in INITIALIZED-loop, also nach $init_done), muss ich mir nochmal gesondert ansehen. Wie bereits mehrfach geschrieben, war diese Unmenge einer der Gründe, warum ich der festen Überzeugung war, dass das so nicht beabsichtigt gewesen sein konnte...
Die wurden zwar in Timer verpackt (die dann implizit zumeist wieder gelöscht wurden?), wenn ich das richtig gedeutet habe, aber die schiere Masse war für sich genommen schon irritierend.

Zitateigentlich wollte martin den automatischen configcheck so wenig wie nötig aufrufen, da er das system belastet.

Solche klaren Aussagen zu dem Thema fehlten mir bisher als Puzzleteilchen.

Zitatdaher gibt es "configcheck -f" aufrufe, denn diese checken ja nur einen kleinen teil des systems. über irgendeine logik wusste er beim restart welche devices zu checken sind. es gab also nicht "configcheck -f" für alle devices, sondern immer nur für einen teil aller devices.

Dann sollte es also wieder Ziel sein, dahin zurückzukommen, dass wir den Check dann abfeuern, wenn er gebraucht wird und den "großen" möglichst ganz vermeiden. Ich habe nur zu wenig Ahnung von den Zusammenhängen, um beurteilen zu können, wie wir das feststellen können, was wann dran ist... Generell irritiert es mich, dass das aus CUL_HM raus angestoßen wird und nicht in HMinfo autonom (zumindest während der Startphase).

Zitatetwa 60s nach dem loadconfig gibt es bei mir noch eine salve "configcheck -f" mit "ausgewählten" devices.

Das ist bei mir auch so, und das wird auch immer mal wieder wiederholt (ich sehe das für ein "kaputtes" Device, das grade nicht erreichbar ist).

frank · 05 Oktober 2021, 16:48:07

ZitatDas klingt danach, als wäre das Attribut zwischendurch mal "nicht erlaubt" (und folglich gelöscht). Stellt sich die Frage, ob man das ggf. (nur während der Initialisierung?) zuläßt (unschön, relativ viel Zusatzcode)? Besser wäre es, die Reihenfolge so zu fixieren, dass das gar nicht erst passiert - ich habe nur noch keine Idee, wo...

alle virtuellen channel entities besitzen weiterhin kein internal ".AttrList".
streng genommen fehlt dann nicht das attribut in der liste, sondern es gibt gar keine liste. somit fehlt es eigentlich auch nicht.
das attribut kann auch zwischenzeitlich nicht gelöscht worden sein, sonst wäre es ja nicht mehr vorhanden.

Beta-User · 05 Oktober 2021, 17:01:50

Zitat von: frank am 05 Oktober 2021, 13:49:43
attr param msgreduce muss weiterhin manuell erfolgen.

...so langsam dämmert mir auch, warum das so ist:
Setzt man das Attribut nach $init_done, werden auch die Werte im helper-Hash entsprechend angepaßt. Während der Start-Phase habe ich jetzt aber nirgends was gefunden, das das Attribut in irgendeiner Form auswerten würde. Da es eigentlich "obvious" ist, dass das irgendwo erfolgen müßte, bin ich immer davon ausgegangen, dass es auch gemacht wird. Da es jedenfalls jetzt nicht mehr der Fall ist:

Jetzt könnte man das ohne weiteres als weiteren individuellen Check auch noch irgendwie in CUL_HM_updateConfig() reinknödeln (wie im aktuellen Anhang), aber an sich ist es nur ein Symptom eines generellen Problems, das wir bisher nur gefühlt, aber nie direkt gesehen haben: Man müßte eigentlich noch eine Schleife basteln, die alle Attribute (in einer bestimmten Reihenfolge?) nochmal durchgeht, und für die Devices, die es nicht "sowieso" richtig machen/wissen dann auch die Auswertung durchführen, die eigentlich in CUL_HM_Attr() schon enthalten ist... Konkret betrifft das mind. bei den VIRTUALs die Attribute "peerIDs" und "param". Wenn es wirklich nur die beiden sind, kann es beim (ungetesteten) angehängten Provisorium bleiben, wenn es mehr ist, sollte man eine explizite Schleife bauen.

EDIT: evtl. ist das io-Problem aus https://forum.fhem.de/index.php/topic,123198.msg1178042.html#msg1178042 auch sowas...? (Ist nur ein erster Gedanke, muss nicht stimmen).

Zitataber wie schon spekuliert, gab es scheinbar ein paar configchecks als "pflaster".

Habe jetzt mal "mutig" die erste Salve deaktiviert, weiß aber noch nicht, ob das gut ist und wohin das ggf. führt...

Warum .AttrList gar nicht gesetzt wird, ist mir im Moment noch ein Rätsel, aber das lichtet sich vielleicht auch noch. Vorläufig bin ich dann froh, den schon fertigen "laß das durch"-Filter erst mal nur deaktiviert zu haben

. Vielleicht liegt das auch daran, dass "VIRTUAL" nicht explizit (nach-) gesetzt wird, und daher nicht klar ist, welche subType-spezifischen Werte eigentlich erlaubt sind...