scheinbar nach jedem restart kommt:
Server started with 343 defined entities (fhem.pl:24810/2021-07-29 perl:5.028001 os:linux user:fhem pid:10936)
2021.08.10 09:10:33 1: CUL_HM start inital cleanup
2021.08.10 09:10:33 1: PERL WARNING: substr outside of string at ./FHEM/10_CUL_HM.pm line 10697.
2021.08.10 09:10:33 1: stacktrace:
2021.08.10 09:10:33 1: main::__ANON__ called by ./FHEM/10_CUL_HM.pm (10697)
2021.08.10 09:10:33 1: main::CUL_HM_UpdtCentral called by ./FHEM/10_CUL_HM.pm (345)
2021.08.10 09:10:33 1: main::CUL_HM_updateConfig called by fhem.pl (3426)
2021.08.10 09:10:33 1: main::HandleTimeout called by fhem.pl (695)
2021.08.10 09:10:33 1: PERL WARNING: Use of uninitialized value in hex at ./FHEM/10_CUL_HM.pm line 10697.
2021.08.10 09:10:33 1: stacktrace:
2021.08.10 09:10:33 1: main::__ANON__ called by ./FHEM/10_CUL_HM.pm (10697)
2021.08.10 09:10:33 1: main::CUL_HM_UpdtCentral called by ./FHEM/10_CUL_HM.pm (345)
2021.08.10 09:10:33 1: main::CUL_HM_updateConfig called by fhem.pl (3426)
2021.08.10 09:10:33 1: main::HandleTimeout called by fhem.pl (695)
2021.08.10 09:10:33 1: PERL WARNING: Use of uninitialized value $a[2] in uc at ./FHEM/10_CUL_HM.pm line 571.
2021.08.10 09:10:33 1: stacktrace:
2021.08.10 09:10:33 1: main::__ANON__ called by ./FHEM/10_CUL_HM.pm (571)
2021.08.10 09:10:33 1: main::CUL_HM_Define called by fhem.pl (3894)
2021.08.10 09:10:33 1: main::CallFn called by fhem.pl (2127)
2021.08.10 09:10:33 1: main::CommandDefine called by ./FHEM/10_CUL_HM.pm (10698)
2021.08.10 09:10:33 1: main::CUL_HM_UpdtCentral called by ./FHEM/10_CUL_HM.pm (345)
2021.08.10 09:10:33 1: main::CUL_HM_updateConfig called by fhem.pl (3426)
2021.08.10 09:10:33 1: main::HandleTimeout called by fhem.pl (695)
2021.08.10 09:10:33 1: define vccu_Btn0 CUL_HM : wrong syntax: define CUL_HM 6-digit-hex-code [Raw-Message]
2021.08.10 09:10:33 1: CUL_HM finished initial cleanupnur zur sicherheit, falls es noch nicht am radar ist ...
kann man mir wenigstens sagen, warum die warnings ausgelöst werden? bei mir kommt das immer noch nach jedem restart.
beim beliebten wettbewerb "sauberstes fhem.log des monats" hast du so natürlich keine chance. ;)
so lange keine "echten" probleme auftauchen, würde ich die warnings zunächst einfach ignorieren.
wenn martin zeit und diesen thread findet, wird er sicherlich nachbessern, denke ich.
vielleicht vor jedem wochenende nach vorne pushen?
*g*
hast ja recht.
das dumme bei mir: ich geh ja schon generell davon aus, daß der fehler bei mir liegt. da ist ne info beruhigend ...
...falls du (oder sonst wer) testen magst...
Die beigefügte Version sollte ("irgendwie") fixen:
- das "unitialized"-Problem (#571, Rest (und vermutlich teils auch https://forum.fhem.de/index.php/topic,122595.msg1171477.html#msg1171477 (https://forum.fhem.de/index.php/topic,122595.msg1171477.html#msg1171477)) war wohl ein Folgeproblem, siehe auch https://forum.fhem.de/index.php/topic,122485.msg1170459.html#msg1170459 (https://forum.fhem.de/index.php/topic,122485.msg1170459.html#msg1170459));
- stateFormat (u.a. https://forum.fhem.de/index.php/topic,122423.0.html (https://forum.fhem.de/index.php/topic,122423.0.html));
- Initialisierung der CCU-FHEM bzgl. der Attribute ergänzt (sollte IOList-Attribut ohne Neustart verfügbar machen, was in https://forum.fhem.de/index.php/topic,122595.msg1171477.html#msg1171477 (https://forum.fhem.de/index.php/topic,122595.msg1171477.html#msg1171477) als weiteres Problem noch nicht erkennbar war);
- Anzeige der commandref-Teile für mehr setter/getter/attr
Alles in allem nichts, was groß Probleme verursachen sollte, aber ich will auch nicht behaupten, dass man das nicht besser machen könnte oder dass es bzgl. der commandref vollständig wäre. Werde dann die Tage auch mal selbst im Hauptsystem testen, hatte aber noch keine Option, das in Ruhe anzugehen.
(Vielleicht, ungeprüft, und ohne Anspruch auf Vollständigkeit) noch eine Liste der offenen aktuelle Probleme:
- Probleme beim Empfang von AES-Sensoren (https://forum.fhem.de/index.php/topic,122507.0.html (https://forum.fhem.de/index.php/topic,122507.0.html), dazu kann ich nichts sagen, ich verwende das nicht)
- modelForce-Zwang für model CCU-FHEM (und eventuelle weitere Probleme aus https://forum.fhem.de/index.php/topic,122595.0.html (https://forum.fhem.de/index.php/topic,122595.0.html))
- (eventuell "verlorene IO's" bei Verwendung von HMUARTLGW (https://forum.fhem.de/index.php/topic,122541.msg1171511.html#msg1171511 (https://forum.fhem.de/index.php/topic,122541.msg1171511.html#msg1171511)), das aber durch den patch von noansi aus https://forum.fhem.de/index.php/topic,122160.msg1168679.html#msg1168679 (https://forum.fhem.de/index.php/topic,122160.msg1168679.html#msg1168679) (Vollversion: https://forum.fhem.de/index.php/topic,122160.msg1168661.html#msg1168661); (https://forum.fhem.de/index.php/topic,122160.msg1168661.html#msg1168661);) ich nehme an, dass mgernoth noch gar nicht mitbekommen hat, dass da was zu tun wäre - anpingen?)
hab mal pseudo-getestet - deine rein und fhem restart
irgendwie anders, aber ...
2021.08.25 14:52:59 0: Server started with 344 defined entities (fhem.pl:24810/2021-07-29 perl:5.028001 os:linux user:fhem pid:21279)
2021.08.25 14:53:00 1: CUL_HM start inital cleanup
2021.08.25 14:53:00 1: PERL WARNING: substr outside of string at ./FHEM/10_CUL_HM.pm line 10700.
2021.08.25 14:53:00 1: stacktrace:
2021.08.25 14:53:00 1: main::__ANON__ called by ./FHEM/10_CUL_HM.pm (10700)
2021.08.25 14:53:00 1: main::CUL_HM_UpdtCentral called by ./FHEM/10_CUL_HM.pm (345)
2021.08.25 14:53:00 1: main::CUL_HM_updateConfig called by fhem.pl (3426)
2021.08.25 14:53:00 1: main::HandleTimeout called by fhem.pl (695)
2021.08.25 14:53:00 1: PERL WARNING: Use of uninitialized value in hex at ./FHEM/10_CUL_HM.pm line 10700.
2021.08.25 14:53:00 1: stacktrace:
2021.08.25 14:53:00 1: main::__ANON__ called by ./FHEM/10_CUL_HM.pm (10700)
2021.08.25 14:53:00 1: main::CUL_HM_UpdtCentral called by ./FHEM/10_CUL_HM.pm (345)
2021.08.25 14:53:00 1: main::CUL_HM_updateConfig called by fhem.pl (3426)
2021.08.25 14:53:00 1: main::HandleTimeout called by fhem.pl (695)
2021.08.25 14:53:00 1: PERL WARNING: Use of uninitialized value $a[2] in uc at ./FHEM/10_CUL_HM.pm line 571.
2021.08.25 14:53:00 1: stacktrace:
2021.08.25 14:53:00 1: main::__ANON__ called by ./FHEM/10_CUL_HM.pm (571)
2021.08.25 14:53:00 1: main::CUL_HM_Define called by fhem.pl (3894)
2021.08.25 14:53:00 1: main::CallFn called by fhem.pl (2127)
2021.08.25 14:53:00 1: main::CommandDefine called by ./FHEM/10_CUL_HM.pm (10701)
2021.08.25 14:53:00 1: main::CUL_HM_UpdtCentral called by ./FHEM/10_CUL_HM.pm (345)
2021.08.25 14:53:00 1: main::CUL_HM_updateConfig called by fhem.pl (3426)
2021.08.25 14:53:00 1: main::HandleTimeout called by fhem.pl (695)
2021.08.25 14:53:00 1: define vccu_Btn0 CUL_HM : wrong syntax: define CUL_HM 6-digit-hex-code [Raw-Message]
2021.08.25 14:53:00 1: CUL_HM finished initial cleanup
Hmm, Danke für den Hinweis, da hatte ich wohl beim Reinsehen in das Logfile einen Wunschlesemodus aktiv ??? ::) ...
Habe die Datei nochmal angepaßt und wieder oben angehängt. Da ist jetzt eine kleine Plausibilitätsprüfung in CUL_HM_UpdtCentral() drin, damit läuft es ohne Eintrag bis "CUL_HM finished initial cleanup". Der Check dürfte m.E. keine zusätzlichen Probleme verursachen.
nu denne - wolle ma mal gucken ...
da hat er wohl diesmal die richtige brille an gehabt *g*
2021.08.25 16:05:48 0: Server started with 344 defined entities (fhem.pl:24810/2021-07-29 perl:5.028001 os:linux user:fhem pid:21841)
2021.08.25 16:05:48 1: CUL_HM start inital cleanup
2021.08.25 16:05:49 1: CUL_HM finished initial cleanup
die 2 meldungen waren früher zwar auch ned da, aber was solls?
kriegst du das ins update reingedrückt, oder muß ich die nächsten tage beim updaten aufpassen?
Martin hat diesen Teil wohl relativ frisch mit aufgenommen und den Log-Level möglicherweise bewußt so hoch gedreht, mAn. würde es auch "3" tun (wären zwei kleine Änderungen im Code). Es gilt aber die Regel, dass man nicht ungefragt in fremden Modulen "irgendwas" eincheckt, von daher würde ich nur auf ausdrücklichen Wunsch von Martin aktiv werden!
Vorläufig sollte hier nur eine (hoffentlich) funktionierende (und betr. der Probleme einigermaßen vollständige) Version auf Martins Code-Basis angeboten werden, daher auch der Weg über das vollständige Modul, damit eventuelle "Mutige" das eben schon mal austesten können. Ob und wie Martin dann was übernehmen will, wird er dann schon entscheiden; ich gehe jedenfalls davon aus, dass im Falle eines updates via svn dann auch wieder ein Stand erreicht sein wird, der diese Probleme (ggf. anders) löst...
Ansonsten kannst du ja ein "diff -u" machen und ggf. dann die fraglichen Stellen dann wieder selbst reinbasteln bzw. den so erstellten Patch anwenden ;) .
ach du ... ich hab's ja ned so eilig.
dein code wird jetzt getestet - deine arbeit und das bissl rumprüfen könnten martin ja auch helfen.
im endeffekt rennt ja alles, egal, mit welcher version. somit ist meine frage, ob ich blödsinn gemacht hab ja eh schon erledigt.
bleibt mir nur: danke dir für dein hirnschmalz und gleich martin - irgendwann in der zukunft - fürs übernehmen!
somit würd ich sagen: wir 2 moren haben unsere schuldigkeit getan *g*
Zitat von: the ratman am 25 August 2021, 18:22:25
das bissl rumprüfen könnten martin ja auch helfen.
...so war's gedacht...
Hier noch das ganze als patch.
Das ganze (samt gepatchtem HMUARTLGW-Code) läuft soweit erkennbar halbwegs stressfrei.
Auf dem Weg zu einem "mustergültigen" Logfile stört allerdings noch, dass HMinfo (aber schon seit mind. 06.08.) beim Serverstart eine "Unzahl" von "get:configCheck"-Einträgen schreibt. Auch da kann man sich über den verbose-Level streiten (2 finde ich hoch), aber jeweils dreifach für dieselben Geräte ist vermutlich nicht beabsichtigt...
(@frank: Hast du eine spontane Idee dazu? (98_HMinfo.pm 24824 2021-08-03 18:29:34Z martinp876))
bleibt mir nur mehr zu sagen:
deine änderungen haben grade nen morgendlichen "update reboot" überlebt und wies ausschaut, funzt auch alles, was mit hm zu tun hat soweit problemlos.
Danke für die Rückmeldung, hier dann auch noch die volle Fassung für einen weiteren Fix betr. "renamed a lot" (https://forum.fhem.de/index.php/topic,122552.0.html (https://forum.fhem.de/index.php/topic,122552.0.html)).
(kurze Erläuterung im verlinkten Thread folgt).
mal gestartet mit dem neuen patch.
jetzt steht mal gar nix mehr im log - uij, so saubär das ist! :P
geräte sind auch noch alle da - sitzt, paßt und hat luft.
Komisch, hätte nicht gedacht, dass dann gar nichts mehr im Log steht. Hast du keine HMinfo-Instanz definiert oder ist das eine "unbeabsichtigte" Nebenwirkung des "sauberen" notify-return, wenn nichts relevantes passiert ist?
ZitatAuf dem Weg zu einem "mustergültigen" Logfile stört allerdings noch, dass HMinfo (aber schon seit mind. 06.08.) beim Serverstart eine "Unzahl" von "get:configCheck"-Einträgen schreibt. Auch da kann man sich über den verbose-Level streiten (2 finde ich hoch), aber jeweils dreifach für dieselben Geräte ist vermutlich nicht beabsichtigt...
das gibt es aber schon "ewig". oder besser: immer mal wieder. ;)
das "problem" steckt aber in cul_hm.
nach diesem update war es mal ok, wie ich in diesem thread https://forum.fhem.de/index.php/topic,113931.msg1086604.html#msg1086604 (https://forum.fhem.de/index.php/topic,113931.msg1086604.html#msg1086604) sehen konnte:
@22806 20.09.2020 18:12:13 martinp876 CUL_HM:correct cfgState after reboot
Mit der 10_CUL_HM.pm:?/2021-08-26 UNSTABLE ist alles wieder sauber im Logfile. Sonst sind auch keine Auffälligkeiten zu beobachten.
Danke für die schnelle Abhilfe.
Das Log müßte unmittelbar durch #1260@HMinfo geschrieben werden.
sub HMinfo_GetFn($@) {#########################################################und nach der Formatierung meiner Einträge würde ich tippen, dass das durch sub HMinfo_getCfgDefere($) (#1237) aufgerufen wird, die halt ihrerseits "irgendwann" im Rahmen der HMinfo-Initialisierung aufgerufen wird.
Der einzige direkte Aufruf von HMinfo-Code aus CUL_HM sieht eigentlich auf den ersten Blick unverdächtig aus, aber zugegebenermaßen ist der Gesamtcode mind. 2 Stufen über meinem Niveau...
An sich hätte ich vermutet, dass ggf. auch einfach ein 60cm-Problem besteht, denn mit HMinfo habe ich mich bisher definitiv zu wenig beschäftigt ::) ... (Deinen js-Code ("große Schwester") habe ich aber im Einsatz, das ist wirklich hilfreich!)
Kann aber auch sein, dass es was damit zu tun hat, dass ich historisch noch Temperaturlisten-Daten via HMinfo hinterlegt hatte, die nicht zum erwarteten Format passen bzw. nicht mehr akutell sind (da durch weekprofile-Verwaltung ersetzt).
Da waren aber nicht nur Thermostate im Log...
Zitat von: BroPi am 26 August 2021, 12:44:01
Mit der 10_CUL_HM.pm:?/2021-08-26 UNSTABLE ist alles wieder sauber im Logfile. Sonst sind auch keine Auffälligkeiten zu beobachten.
Danke für die schnelle Abhilfe.
Thx für die Rückmeldung :) .
Wie ist das bei dir: HMinfo vorhanden?
Wie gesagt: Martin sollte (und wird das vermutlich) alles nochmal gegenchecken.
ZitatWie ist das bei dir: HMinfo vorhanden?
HMinfo wird auch verwendet, bringt bisher keine Auffälligkeiten.
Zitat von: Beta-User am 26 August 2021, 11:04:15
... Hast du keine HMinfo-Instanz definiert ...
doch. und aktiv seit uhrzeiten
und auch ein action detector - nur, falls die frage aufkommen sollte *g*
Danke euch beiden - demnach doch ein 60cm-Problem... ::)
Verdacht: sollte mal wieder die Konfiguration aus HMinfo rausspeichern und ggf. ein paar zwischenzeitlich wegen Defekten gar nicht mehr als Hardware vorhandene Devices auch aus FHEM entsorgen ::) ...
(Wobei mir die Zahl der Aufrufe trotzdem (zu) hoch vorkommt).
ich glaub, irgendwie solltest mit martin mal auf ein bier gehen. würde wohl viele wenn, vielleicht, könnte, sollte und müßte aus der gleichung raus nehmen.
vielleicht würdets ihr sogar sowas wie ein team ergeben? mein, so richtig als "ausfallssicherung" für den jeweils anderen. sowas würde mir und vor allem meinen nerven sowieso sehr gut tun *g* nicht nur bei hm ...
Gehe gerne mit Martin ein Bier trinken, wenn sich das ergibt oder hätte auch eine gute Flasche Wein im Keller, so ist es nicht ;D .
Fühle mich durch die Rückmeldung auch geehrt, ABER:
a) ist mir der Code zu hoch, und das ist kein Witz! Das bißchen hier ist reine Kosmetik (der patch hat nur wegen der commandref so einen Umfang, und das ist eine hoffentlich bald abgeschlossene Einmalaktion ohne Einfluss auf die Funktionalität); es gäbe ein, zwei Leute, von denen ich weiß, dass sie zum einen deutlich besser qualifiziert sind und sich auch im vorhandenen Code besser auskennen;
b) habe ich schon "genug" mit anderen Modulen und "add-ons";
c) würde ich ständig über Äußerlichkeiten stolpern, da ich zwischenzeitlich "meine Module" ohne Prototypes und gepackaged habe, damit ich sie problemlos durch Perlcritic bekomme...
Das hier war nur weil
a) hatte ich ein schlechtes Gewissen, weil mein letzter commandref-patch nicht hinreichend gewesen war => wollte "sowieso" was nachliefern,
b) waren die "Probleme" im Code relativ einfach und
c) mir selbst wichtig war upzudaten, ohne mir unbedingt gleich bekannte bzw. neue Probleme reinziehen ;) .
Hinreichend viele Gründe also, um aktiv zu werden, aber noch lange kein Anlass, mich komplett selbst zu überschätzen ;D .
jaja, wenn du nur halb so blöd wärst, wie du dich immer selber darstellst ... *bg*
war aber sowieso eher generell gedacht, weils halt grad gepaßt hat ...
[träumerei]
in meinen augen müßte jeder modulautor zwingend mindestens einen 2. haben, der eben als notfall funktioniert. könnte lustige synergien geben. was sich da auf einmal alles verknüpfen und vereinheitlichen würde in fhem ... *träum*
gutes und einfaches bspl.: die mittlerweile gefühlt 1000 weboberflächen, von denen jede irgendwas kann, das ich gerne hätte, aber keine alles. stell dir mal vor, du hast dann nur mehr 1 oder 2 oberflächen, die aber jedes stückerl spielen.
[/träumerei]
Zitat von: the ratman am 26 August 2021, 17:01:25
jaja, wenn du nur halb so blöd wärst, wie du dich immer selber darstellst ... *bg*
...ich mach' schon immer mal wieder richtig blöde Fehler, und "richtig" Programmieren gelernt habe ich nie, ist alles c/p...
Logisch denken klappt meistens, und ein ganz ordentliches Gespür für strukturelle Mängel sagen mir manche auch nach. Hier ist aber mehr gefordert...
Zitat
[träumerei]
in meinen augen müßte jeder modulautor zwingend mindestens einen 2. haben, der eben als notfall funktioniert. könnte lustige synergien geben.
Zum einen ist das nicht ganz selten offen oder verdeckt der Fall (ich kann die diesbezügliche Kritik eines bestimmten Youtubers und auch der "will github haben-Fraktion" nicht so ganz nachvollziehen!), zum anderen kann jeder hier patches zur öffentlichen Diskussion einreichen oder Wünsche äußern.
Das mag zwar von manchen als vorgestrig empfunden werden, aber wenn sich da manche (gerne auch auf der Plattform ihrer Wahl) zusammentun wollen, ist das ja nicht verboten, das Einchecken des (Zwischen-) Ergebnisses im svn ist letztendlich das wenigste...
Zitatwas sich da auf einmal alles verknüpfen und vereinheitlichen würde in fhem ... *träum*gutes und einfaches bspl.: die mittlerweile gefühlt 1000 weboberflächen, von denen jede irgendwas kann, das ich gerne hätte, aber keine alles. stell dir mal vor, du hast dann nur mehr 1 oder 2 oberflächen, die aber jedes stückerl spielen.
[/träumerei]
Zum einen glaube ich nicht daran, dass man manchen "historischen Zopf" (angefangen bei Reading-Benennungen...) einfach so "abschneiden" kann, weil immer die User (nicht: Entwickler!), die sich an "ihre" Readingnamen gewöhnt haben am lautesten schreien werden würden und updates von "habe ich vor 5 Jahren eingerichtet, jetzt ist mir die SD-Karte abgekachelt"-Usern praktisch unmöglich wären.
Und über GUI's kann man sich lange streiten (so man deren Nutzen überhaupt sieht, mein FHEM läuft auch zumeist einfach im Hintergrund so vor sich hin, und wenn ein UI genutzt wird, dann zwischenzeitlich zumeist RHASSPY...). Eigentlich finde ich es zwischenzeitlich kein Nachteil mehr, dass es keine "integrierte" 100%-Lösung gibt (mit f18 kann man schon einiges erreichen), und es dann immer mal wieder was neues gibt, wie jetzt z.B. mit FHEMApp.
Da wo es funktional Sinn macht, die "Bedienung" zu vereinheitlichen (z.B. Wochenprofil-Verwaltung für Thermostate, Multimedia-setter und Readings, Solaranlagen usw.) läuft einiges, teils im Hintergrund, teils ist es (soweit) fertig (z.B. ASC).
is eh alles klar. und gui war nur ein beispiel. wie gesagt: man träumt halt so vor sich hin als kleiner user, der weiß, dass er sich selber nie wird helfen können, wenns mal kracht.
zur träumerei, ein bissi weniger "härte":
man muß ja nicht gleich mit einem radikal-umbau von fhem beginnen. denke, je mehr die autoren miteinander reden würden, je mehr würd sich da ganz von alleine ergeben.
außerdem gäbs ja immer noch den großen cheffe im hintergrund. der würd schon sagen, was ihm paßt oder auch ned. da mach ich mir so überhaupt keine sorgen.
wäre generell vielleicht gar ned so schlecht, fhem als (vorsicht: ist nur ein arbeitstitel!) "pseudo-firma" aufzuziehen. natürlich alles freiwillig, ohne knete usw. nur eben ein bissi struktur. ganz oben mit dem gottgleichen chef und dann schön abteilungen mit festen ansprechpartnern drunter, wo sich jeder freiwillige mitarbeiter auch freiwillig einreihen kann. würd dann wohl von selber rennen, wenn die einzelkämpfer mitbekommen, wie viel fertige hilfe und wissen in den "abteilungen" für sie rum liegt, wenn sie einfach nur mitmachen.
jaja, ich weiß - alles nur kopfkino ...
"Abteilungsleiter" in einer echten Firma zu sein, ist nicht unbedingt immer vergnügungssteuerpflichtig, und ob jemand sich mit dem hier gewählten Vergleich anfreunden kann, bzw. was er mit einem solchen assoziiert, entzieht sich meiner Kenntnis...
Meine Erfahrung bisher war: wenn jemand nach support zu irgendeinem Thema gefragt hat, hat er Hilfe bekommen - vom "Cheffe" oder vielen (vielen!) anderen, ganz gleich, ob "Developer" oder "User" - manchmal eben auch in Form von: "Zeig mir, dass (bzw. warum) es wichtig ist!" oder (mehr oder minder freundlichem) RTFM...
Und manchem ist es eben wichtig die alleinige Hoheit über "seinen" Code zu haben und nicht von mehr als einer verlässlichen Basis (fhem.pl) abhängig zu sein. Auch ok und häufig genug zu unser aller Vorteil...
Von daher sehe ich den Vorteil der "Freiwilligen-Firma" nicht, aber vermutlich übersehe ich mal wieder was wesentliches ::) ;D ::) ...
du nimmst mich eh viel zu ernst ... ich spinn eben nur so vor mich, von der (für mich) idealen welt rum. wie sowas aussehen könnte - da müßten sehr viele sehr gute ideen haben.
btw- es gibt auch genug leute, die für den "untercheffe" morden würden.
und wenn wir vom verhältnis usr zu dev reden wollen. am anfang ist das schon extremst frustrierend. da rotierst eh schon ohne ahnung mit den einfachsten sachen und dann will dir wer (ich nenne jetzt keinen namen *fg*) hilfe zur selbsthilfe aufzwingen und quasselt da von sachen die du nicht verstehst. dein problem besteht weiter, die holde packt den schnitzelklopfer aus und dein tag ist im a.... oh mann, hab ich das gehaßt. aber gut, ich war auch ned kuschelweich.
und ja ... rtfm für anfänger - ich sag jetzt lieber nix *g*
Aus gegebenem Anlass nochmal eine Aktualisierung der "Komplettliste" aller derzeitigen Testversionen/hotfixes von hier:
Zitat von: Beta-User am 25 August 2021, 14:07:39
...falls du (oder sonst wer) testen magst...
Die beigefügte Version sollte ("irgendwie") fixen:
- das "unitialized"-Problem (#571, Rest (und vermutlich teils auch https://forum.fhem.de/index.php/topic,122595.msg1171477.html#msg1171477 (https://forum.fhem.de/index.php/topic,122595.msg1171477.html#msg1171477)) war wohl ein Folgeproblem, siehe auch https://forum.fhem.de/index.php/topic,122485.msg1170459.html#msg1170459 (https://forum.fhem.de/index.php/topic,122485.msg1170459.html#msg1170459));
- stateFormat (u.a. https://forum.fhem.de/index.php/topic,122423.0.html (https://forum.fhem.de/index.php/topic,122423.0.html));
- Initialisierung der CCU-FHEM bzgl. der Attribute ergänzt (sollte IOList-Attribut ohne Neustart verfügbar machen, was in https://forum.fhem.de/index.php/topic,122595.msg1171477.html#msg1171477 (https://forum.fhem.de/index.php/topic,122595.msg1171477.html#msg1171477) als weiteres Problem noch nicht erkennbar war);
- Anzeige der commandref-Teile für mehr setter/getter/attr
Alles in allem nichts, was groß Probleme verursachen sollte, aber ich will auch nicht behaupten, dass man das nicht besser machen könnte oder dass es bzgl. der commandref vollständig wäre. Werde dann die Tage auch mal selbst im Hauptsystem testen, hatte aber noch keine Option, das in Ruhe anzugehen.
(Vielleicht, ungeprüft, und ohne Anspruch auf Vollständigkeit) noch eine Liste der offenen aktuelle Probleme:
- Probleme beim Empfang von AES-Sensoren (https://forum.fhem.de/index.php/topic,122507.0.html (https://forum.fhem.de/index.php/topic,122507.0.html), dazu kann ich nichts sagen, ich verwende das nicht)
- modelForce-Zwang für model CCU-FHEM (und eventuelle weitere Probleme aus https://forum.fhem.de/index.php/topic,122595.0.html (https://forum.fhem.de/index.php/topic,122595.0.html))
- (eventuell "verlorene IO's" bei Verwendung von HMUARTLGW (https://forum.fhem.de/index.php/topic,122541.msg1171511.html#msg1171511 (https://forum.fhem.de/index.php/topic,122541.msg1171511.html#msg1171511)), das aber durch den patch von noansi aus https://forum.fhem.de/index.php/topic,122160.msg1168679.html#msg1168679 (https://forum.fhem.de/index.php/topic,122160.msg1168679.html#msg1168679) (Vollversion: https://forum.fhem.de/index.php/topic,122160.msg1168661.html#msg1168661); (https://forum.fhem.de/index.php/topic,122160.msg1168661.html#msg1168661);) ich nehme an, dass mgernoth noch gar nicht mitbekommen hat, dass da was zu tun wäre - anpingen?)
Zitat von: frank am 27 August 2021, 10:54:11
und die gepatchte 00_HMLAN.pm nutzen:
https://forum.fhem.de/index.php/topic,120600.msg1153590.html#msg1153590 (https://forum.fhem.de/index.php/topic,120600.msg1153590.html#msg1153590)
Da in
Zitat von: Beta-User am 26 August 2021, 10:00:14
hier dann auch noch die volle Fassung für einen weiteren Fix betr. "renamed a lot" (https://forum.fhem.de/index.php/topic,122552.0.html (https://forum.fhem.de/index.php/topic,122552.0.html)).
(kurze Erläuterung im verlinkten Thread folgt).
versehentlich auch das Loglevel für started/finished drin war, hier für alle nachfolgenden Tester nochmal die Vollversion (wer die aus dem obigen Thread schon hat, braucht nichts zu machen, die zwei Zeilen sind mehr oder weniger "wurst"...)
Patch liefere ich bei Gelegenheit nach.
EDIT: Patch anbei
sagts mal, hab ich was verpennt, oder muß man sich um martin sorgen machen?
Vermutlich wäre es besser, du würdest ihn das direkt fragen. Bis auf weiteres gehe ich davon aus, dass er schlicht und ergreifend irgendwann auch mal die Gelegenheit zum Urlaubmachen ergriffen hat und ohne Handwerkszeug und Muße eh' nicht helfen kann...
Ansonsten klangen die letzten Umbauten durchaus so, dass er sich weiter langfristig um die Module kümmern will. Da ging ja vieles auch eher in Richtung einer klaren Nutzerführung, was zulässig/sinnvoll ist usw..
Kleiner Hinweis am Rande noch: im "Nebenthread (https://forum.fhem.de/index.php/topic,122848.msg1174062.html#msg1174062)" bin ich vorhin noch über was gestolpert, das die Erstinitialisierung bei VCCU-Verwendung angeht. Mein Bauchgefühl sagt mir, dass es ggf. hilfreich wäre, wenn zumindest mutige Tester gleich diese letzte Version (mit vorgezogener Attributprüfung) verwenden würden ;) .
dank dir für die gedanken - wirst wohl recht haben.
vccu testen - nicht so meines. schon gar ned, wenn man mut braucht *g*
das dürfen dann doch gerne leute mit ahnung machen.
Zitatvccu testen - nicht so meines. schon gar ned, wenn man mut braucht *g*
das dürfen dann doch gerne leute mit ahnung machen.
ich behaupte, dass viele fehler eher durch leute mit weniger ahnung gefunden werden.
da werden "kombinationen" probiert, an die sonst keiner gedacht hätte. 8)
...sehe ich auch so, und bei meinen Modulen fühle ich mich auch eher wohl, wenn ein paar wenige Leute das schon mal vorab testen...
Wenn wir jetzt (aes ist noch unklar) auch noch dieses blöde Thema mit dem tempListTmpl in den Griff bekommen könnten, dann wäre ggf. auch alles wieder einigermaßen auf Stand. Leider will das überhaupt nicht so richtig, stattdessen habe ich mir mit einem set-Befehl (set therm_Clima tempTmplSet aa:bb) zuverlässig FHEM abschießen können, wenn HMinfo nicht definiert war (mit ist die Funktion da). Soviel zum Thema "Kombinationen"...
Dafür meine ich, noch einen Wackler bei der Erstinitialisierung gefunden zu haben, da müßte mAn. eigentlich ein anderer Startparameter übergeben werden, wenn wegen !$init_done getimert wird.
Damit wieder alle update-Angebote an einer Stelle (=hier) versammelt sind, und zumindest die Fehlermeldung aus dem Nachbarpost erledigt zu sein scheint, dieses update dann wieder hier (HMLAN nur der Vollständigkeit halber).
@frank: Nachdem ich jetzt einige Zeit durch den Code gestolpert bin auf der Suche danach, warum das mit dem Setzen von "tempListTmpl" nicht so recht will...: Kann es sein, dass das u.A. auch deswegen nicht klappt, weil auf meinem Testsystem keine HMinfo Instanz definiert ist?
Soweit ich den Code interpretiere, ist es (ab #1395) so, dass das Attribut nicht nur den setter voraussetzt, sondern auch das Vorhandensein eines Hashes unter $hash->{tempListTmplLst} (= $modules{CUL_HM}->{tempListTmplLst}). Den wiederrum setzt CUL_HM gar nicht selbst, sondern HMinfo.
Das ist jedenfalls dann "tödlich", wenn man ohne HMinfo nur mit einer cfg-file arbeitet...
Hier erst mal die angekündigten patches.
Zur Feier des Tages habe ich in meinem HMinfo alte templist-Files reaktiviert. Aber auch damit bekam ich keine tempList.*-Attribute angeboten....
Meinem Gefühl nach greift her der Versuch zu weit, das von dem betreffenden Hash und damit von HMinfo abhängig zu machen. Mal schauen, was Martin dann zu gegebener Zeit dazu meint.
sorry, late.
die VCCU ist scheinbar mit nichts gepeert - die Schleife ist mit "leerer peerID" gestartet.
Fange ich jetzt ab
meine nächste blöde frage:Revision 24961: CUL_HM:change IO clients support detection, ignore empty peerlist at ...auch noch kein grund, beta-users version zu überschreiben, oder?
Na ja, das Problem, dass hier zur Diskussion stand, ist damit gelöst.
Es macht auch Sinn, die einzelnen Themen gesondert im svn zu kennzeichnen, von daher gehe ich davon aus, dass Martin sich dann in den passenden Threads melden wird, wenn er die betreffenden Punkte angegangen war. Er wird schon besser wissen, was wie wichtig ist und wie herum es sinnvoll ist, das - unter Berücksichtigung seiner eigenen Ressourcen - jeweils anzugehen.
Falls das länger dauert, kann ich gerne versuchen, das vorläufig wieder soweit zusammenzuführen (und ggf. auch klarer zu machen, was wogegen gedacht war), dass die Tester aus diesem Thread weiter eine "hotfix"-Variante einsetzen können...
Falls jemand die "id"-Umstellung für HMLAN vorbereiten möchte: ich gehe mal davon aus,
dass Martin nichts dagegen hat, wenn ihm jemand da was vorbereiten würde? => Freiwillige vor (ich nutze das Modul nicht und bin raus, wie es geht, ist an dem patch gut zu erkennen, und man braucht 0 Programmiererfahrung, das ist reine Fleißarbeit!)
@Martin: Bitte um Rückmeldung, falls das (in Teilen) nicht gewünscht ist :) .
Nachdem ich grade beim Testen der neuen Version aus dem svn gesehen habe, dass tempListTmpl wieder da ist :) , bin ich's nochmal durchgegangen, was denn so an Änderungsvorschlägen da ist.
Manches ist aus sicher heraus vermutlich nicht verständlich bzw. nur mit etwas Zusatzinfo oder einer Referenz, wo es herkommt. Daher anbei eine konsolidierte Fassung samt patch, die dazu etwas weniger schweigsam ist und hoffentlich Arbeit spart...
EDIT: Einige Anmerkungen waren unnötig bzw. auch schlicht weil der Editor da irgendeine Formatierung scheinbar durcheinandergewürfelt hat; hier daher das nochmals aktualisierte Paket... Der besseren Übersichtlichkeit halber jetzt aufgeteilt in den Nachtrag zur commandref-Überarbeitung und die eigentlichen funktionalen Änderungen.
@Martin und andere interessierte Mitleser:
Die vorgeschlagenen Modifikationen zur Konfiguration der VCCU's@startup scheinen auch gegen das AES-Kommunikationsproblem (https://forum.fhem.de/index.php/topic,122507.msg1174535.html#msg1174535) zu helfen.
Anbei dann noch ein Fix für das tempListTempl-Attribut-Thema (hoffentlich).
@Martin: Ursache war m.E. ein Dreher in den Funktionsaufrufen bei CUL_HM_AttrCheck() (neue Fassung).
#529 (Beta-User-Version)
- delete $attr{$name}{$_} if (CUL_HM_AttrCheck('set',$name,$_,$attr{$name}{$_}));
+ delete $attr{$name}{$_} if (CUL_HM_AttrCheck($name,'set',$_,$attr{$name}{$_})); #Beta-User: fixes missing tempListTempl
EDIT: siehe auch @noansi in https://forum.fhem.de/index.php/topic,122107.msg1166930.html#msg1166930 (https://forum.fhem.de/index.php/topic,122107.msg1166930.html#msg1166930)
In dem o.g. Thread sind auch noch weitere Kleinigkeiten genannt, ich werde mal versuchen, auch das vollends zu konsolidieren, update + patch folgt.
Anbei die angekündigte "konsolidierte Fassung" mit den (hoffentlich soweit vollständigen) noch nicht durch martinp876 mit eingearbeiteten Anmerkungen von noansi aus dem bereits oben verlinkten Thread - diesmal wieder als "Einheitspatch".
Ein paar Sachen kommen mir noch seltsam vor:
zum einen gibt es viele Meldungen wie diese im Log:
2021.09.21 20:02:29 3: CUL_0: Unknown code ? (remove:332211 is unknown) Use one of A B b C e F G h i K k L l M m N R T t U u V W X x Y Z, help me!
Zum anderen behauptet die CUL_HM-commandref, man solle tempListTmpl auf "0" stellen, wenn man das feature deaktivieren will. Jedenfalls via FHEMWEB klappt das aber nicht, weder über das drop-down, noch über die Kommandozeile, sieht so aus, als wäre "none" gemeint, aber da meint configCheck danach immer noch, da würde was nicht zusammenpassen....
Für ersteres habe ich erst mal keine Idee, das Ding ist einfach ein VIRTUAL-model mit zwei Kanälen. Macht da HMinfo ein getConfig drauf...?
Beim zweiten paßt vermutlich irgendeine Kleinigkeit nicht, mal schauen, aber nicht mehr heute.
Zitat von: Beta-User am 21 September 2021, 21:12:25
zum einen gibt es viele Meldungen wie diese im Log:
2021.09.21 20:02:29 3: CUL_0: Unknown code ? (remove:332211 is unknown) Use one of A B b C e F G h i K k L l M m N R T t U u V W X x Y Z, help me!
Das scheint durch Zeile #10856 verursacht zu sein. Nach meinem Verständnis dürfte ein "remove"-Befehl nicht an CUL-TYPE "alte" IO's gehen, was sich durch Abfragen analog #10859 verhindern lassen sollte.
Und dann stellt sich weiter die Frage, warum das so oft durchlaufen wird. Da wurden in #10854 zwei Hash-Referenzen (?) mit != verglichen. Kommt mir komisch vor, ein "eq" sollte jedenfalls unschädlich sein.
Jedenfalls sind jetzt die unzähligen Einträge im Log passée.
Zitat
Zum anderen behauptet die CUL_HM-commandref, man solle tempListTmpl auf "0" stellen, wenn man das feature deaktivieren will. Jedenfalls via FHEMWEB klappt das aber nicht, weder über das drop-down, noch über die Kommandozeile, sieht so aus, als wäre "none" gemeint, aber da meint configCheck danach immer noch, da würde was nicht zusammenpassen....
Jedenfalls nach dem Code in #11332 ist die commandref nicht aktuell, das in FHEMWEB exklusiv angebotene "none" sollte genauso gehen.
Noch unklar ist mir aber, ob die Behandlung von "unused" überall paßt, für HMinfo wird es gebraucht.
Aktualisierte Fassung wieder anbei.
Bei der ist noch "merkwürdig", dass das tempListTmpl-Attribut jetzt bei einigen wenigen meiner HM-CC-RT-DN (und dem einen WT) verfügbar ist, aber (bei weitem) nicht bei allen...? Bisher bin ich noch nicht drauf gekommen, was die Logik dahinter ist, meine im Moment einzige Vermutung wäre: Das sind die Geräte, die die bei ihnen eingestellten Solltemperaturen verteilen?
@frank (und @noansi, falls ihr mitlest): Bitte um Rückmeldung, falls ich was schwerwiegendes übersehen haben sollte.
ZitatDas scheint durch Zeile #10856 verursacht zu sein. Nach meinem Verständnis dürfte ein "remove"-Befehl nicht an CUL-TYPE "alte" IO's gehen, was sich durch Abfragen analog #10859 verhindern lassen sollte.
sehe ich auch so.
homematic io werden prepariert, damit sie autonom mit bestimmten devices kommunizieren können (ACK, AES, ...).
für tscul io gilt es im prinzip auch, aber das handling ist teilweise unterschiedlich.
bei normalen cul werden alle messages über fhem initiiert.
für hmlan/hmuart sieht man die assigned devices über "get assignIDs". jedes device darf natürlich nur einmal assigned sein. diese listen müssen mit "get vccu listDevice" korrelieren.
ZitatUnd dann stellt sich weiter die Frage, warum das so oft durchlaufen wird.
meinst du beim start, oder grundsätzlich?
Zitat von: frank am 23 September 2021, 11:35:32
homematic io werden prepariert, damit sie autonom mit bestimmten devices kommunizieren können (ACK, AES, ...).
Das passt soweit zu meinem (möglicherweise unvollkommenen) Codeverständnis.
Zitat
für tscul io gilt es im prinzip auch, aber das handling ist teilweise unterschiedlich.
bei normalen cul werden alle messages über fhem initiiert.
Hmm, habe es erst mal so übernommen, wie es in der Folge auch drin war, also nur HMLAN/HMUARTLGW. Falls da (an beiden Stellen?) Anpassungen für TSCUL sinnvoll wären, kann das ja jemand vorschlagen, der diesen Teil dann auch nutzt (ich bin bis dato mit der Standard-fw gefahren, was (iV. einem USB-gemoddeten Pi-HM-UART-PCB) für mich ok war)?
Zitat
meinst du beim start, oder grundsätzlich?
Da die Log-Einträge auch im laufenden Betrieb zu hunderten aufgetreten sind, ist/war es m.E. ein grundsätzliches Thema. Ob das durch den !=-Vergleich verursacht wurde? So oder so ist es komisch, weil IODev nicht mehr als Attribut gesetzt war und das Reading eigentlich tendenziell bei denen überall auf das HMUARTLGW-IO zeigt...
ZitatBei der ist noch "merkwürdig", dass das tempListTmpl-Attribut jetzt bei einigen wenigen meiner HM-CC-RT-DN (und dem einen WT) verfügbar ist, aber (bei weitem) nicht bei allen...? Bisher bin ich noch nicht drauf gekommen, was die Logik dahinter ist, meine im Moment einzige Vermutung wäre: Das sind die Geräte, die die bei ihnen eingestellten Solltemperaturen verteilen?
Die lists habe ich jetzt mal verglichen, das könnte am (im "Fehlerfall" nicht vorhandenen) Internal "peerList" (Hauptdevice) liegen. Das wird über #4506 an #4992 übergeben wird. Aber irgendwie sind diese ganzen Zusammenhänge sehr indirekt und jedenfalls ich werde im Moment noch nicht schlau daraus...
Zitat von: Beta-User am 22 September 2021, 20:44:49
Bei der ist noch "merkwürdig", dass das tempListTmpl-Attribut jetzt bei einigen wenigen meiner HM-CC-RT-DN (und dem einen WT) verfügbar ist, aber (bei weitem) nicht bei allen...? Bisher bin ich noch nicht drauf gekommen, was die Logik dahinter ist, [...]
So!
Wenn etwas in Perl scheinbar keiner Logik folgt und zufällig wirkt, steckt in der Regel ein Hash-Zugriff dahinter :o . So müßte es sich mE. auch mit diesem dämlichen tempListTmp-Attribut verhalten.
Wer das nachvollziehen will, nehme am einfachsten ein "nackiges" Testsystem, definiere einen Fake-Thermostat (modelForce HM-CC-RT-DN), setze in keinem der Channel-Devices Peer-Attribute und starte dieses System einige Male. Dabei jedes Mal schauen, ob das Attribut im Clima-Channel verfügbar ist (und wie die setter aussehen), dabei bitte immer warten, bis die CUL_HM-interne Nach-Konfiguration wirklich komplett durch ist (man sieht sonst übergangsweise viel zu viel). "Würfelt" man auf diese Weise häufig genug, kann man hin und wieder auch das Attribut setzen, aber meistens ist es nicht da... (Drum dachte ich auch zunächst, das Problem sei gelöst, ohne einen Zusammenhang mit meinen Änderungen zu sehen... Jetzt scheint klar: es gab ihn auch nicht...!)
Also habe ich dann mal ein paar "sort" an den Stellen verteilt, die mir in diesem Sinne (unsortierter Hash-Zugriff) "verdächtig" aussahen, und siehe da: Man bekommt das Attribut damit scheinbar (würfelnd....) weg, dafür sind die "Tages-setter" da, die fehlten vorher auch immer mal wieder. Dann noch ein paar "reverse" dort, wo es mir am "dransten" an der Quelle erschien, und die Zahl meiner Stichproben mit "tempListTempl" Attribut erhöhte sich auf 100% 8) .
Kann natürlich sein, dass auch das Zufall ist oder die sort/reverse-Pflaster etwas großzügig gesetzt sind oder das sonst Nebenwirkungen hat, weil auf einmal die Prüfungsreihenfolge für das eine oder andere verdreht (genauer: festgelegt und nicht mehr zufällig) ist (Test im Echtsystem steht noch aus), aber ich wollte euch das nicht vorenhalten, vielleicht mag sich ja jemand mit Gedanken machen oder Testen.
Zitatsetze in keinem der Channel-Devices Peer-Attribute
das ist doch aber nicht praxis gerecht, oder?
peerbare channel haben doch mindestens immer "attr peerIDs unread". oder hat sich das auch geändert?
Zitat von: frank am 27 September 2021, 12:23:24
das ist doch aber nicht praxis gerecht, oder?
peerbare channel haben doch mindestens immer "attr peerIDs unread". oder hat sich das auch geändert?
Das kann schon sein...
In meiner "Praxis" ist es so, dass alle RT's Peers haben, aber nur zwei (von deulich mehr) geteamt sind. Und genau bei denen ist das Attribut setzbar, was ich jetzt auch beim Testen reproduzieren konnte. Jetzt können wir natürlich darüber diskutieren, ob man ein Peering braucht und sonst das Attribut sinnlos ist usw., aber irgendwie war ich bisher der Ansicht, dass man einen "einsamen" RT durchaus mit einer Temperaturliste aus dem Template-Satz verattributieren können sollte. Geht aber nicht (zuverlässig), siehe auch https://forum.fhem.de/index.php/topic,122726.0.html (https://forum.fhem.de/index.php/topic,122726.0.html).
Ob auch https://forum.fhem.de/index.php/topic,99579.msg1176312.html#msg1176312 (https://forum.fhem.de/index.php/topic,99579.msg1176312.html#msg1176312) damit zusammenhängt, kann ich nicht sagen, aber irgendwie klingt das auch in diese Richtung "verdächtig" und war der Anlass, warum ich überhaupt nochmal durch den Code "gehuscht" bin...
...und weil's grade so nett ist, hier noch eine Ergänzung betr. das deviceRename...
hast du mal mit "set hminfo simDev" gespielt?
damit kann man wohl devices simulieren.
in meiner version ist es aber noch etwas buggy, denke ich, da ich zb nach set simDev erst noch unnötigerweise attr modelForce setzen muss.
danach sind alle channel vorhanden.
attr peerIDs=peerUnread ist hier aber nur in chn1 anwesend.
ZitatIn meiner "Praxis" ist es so, dass alle RT's Peers haben, aber nur zwei (von deulich mehr) geteamt sind. Und genau bei denen ist das Attribut setzbar
das halte ich auch für falsch.
In der Testumgebung hatte ich bewußt kein HMinfo definiert, weil auch der eine oder andere User das (warum auch immer) nicht hat.
Via "Simulator" erzeugte Devices sind aber uU. "kompletter" als "reale", und im Moment kann ich auch nicht erkennen, wo die Frage hinführen soll. Fakt ist: in meiner realen Umgebung, in der auch ein HMinfo existiert, habe ich nicht (immer) die Möglichkeit, das fragliche Attribut zu setzen. "verbesserte" Testbedingungen, die das Problem direkt vermeiden würden, bringen daher m.E. keinen großen Erkenntnisgewinn.
Mein "Fake-RT" hatte aber schon alle Kanäle, falls das die Frage war. Nur eben ausdrücklich keine (manuell gesetzten) Peers.
:o ...soviel zu Theorie und Praxis:
Im Echtsystem mit HMinfo bringt die Sortiererei jedenfalls beim ersten und zweiten Test schlicht: nichts...
Kann jetzt an HMinfo liegen, oder auch an was ganz anderem. Seltsam, das...
Damit ist das mit dem sort wohl nicht der richtige Hebel, oder es ist in einem HMinfo-Umfeld (alleine) nicht ausreichend?
(Ansonsten scheint aber jedenfalls keine Verschlechterung eingetreten zu sein, von daher lasse ich das erst mal drin).
EDIT: Löschen der HMinfo-Instanz im Hauptsystem bringt keine Änderung, und mind. einer der weiteren RT's hat - eigentlich wenig überraschend - einen ClimaTeam-peer. Irgendwie kein Land in Sicht...
...damit alles an Code an einem Platz ist...
Vorab: kalte Dusche, es funktioniert sortiert bislang auch nicht besser.
Trotzdem wollte ich euch den aktuellen Zwischenstand nicht vorenthalten und bin weiter ziemlich sicher, dass man während der Initialisierungsphase "nur" in der richtigen Reihenfolge vorgehen muss, was derzeit eben nicht hinhaut...
Details siehe https://forum.fhem.de/index.php/topic,123136.msg1176837.html#msg1176837 (https://forum.fhem.de/index.php/topic,123136.msg1176837.html#msg1176837).
EDIT: Kleinigkeiten nachträglich geändert, aber nichts substantielles => geht immer noch nicht...
So, endlich...
Testsystem ohne HMinfo und Echtsystem mit liefern jeweils tempListTmpl als Attribut - bis dato zwar nur bei einigen bzw. genau zwei Neustarts, aber dieses Mal bin ich zuversichtlich, dass das kein Zufall mehr ist!
Vermutlich kann/muss man das ganze noch bereinigen, aber dazu fehlt mir jetzt grade Lust und Muße :) .
New news: Aktuelle "Beta-User"-patched Versionen gibt es ab jetzt hier: https://forum.fhem.de/index.php/topic,123198.msg1177351.html#msg1177351
Es MUSS dann auch HMinfo getauscht werden!