[10.08.21] neues cul_hm schreibt ein paar warnings ...

[frank]

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

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 sehen konnte:

Code Auswählen Erweitern

@22806    20.09.2020 18:12:13 martinp876 CUL_HM:correct cfgState after reboot

[BroPi]

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.

[Beta-User]

Das Log müßte unmittelbar durch #1260@HMinfo geschrieben werden.

Code Auswählen Erweitern

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

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.

[BroPi]

Wie ist das bei dir: HMinfo vorhanden?

HMinfo wird auch verwendet, bringt bisher keine Auffälligkeiten.

[the ratman]

... Hast du keine HMinfo-Instanz definiert ...

doch. und aktiv seit uhrzeiten
und auch ein action detector - nur, falls die frage aufkommen sollte *g*

[Beta-User]

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

[the ratman]

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

[Beta-User]

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 .

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 .

[the ratman]

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]

[Beta-User]

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

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

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]

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

[the ratman]

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

[Beta-User]

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

[the ratman]

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*

[Beta-User]

Aus gegebenem Anlass nochmal eine Aktualisierung der "Komplettliste" aller derzeitigen Testversionen/hotfixes von hier:

...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) war wohl ein Folgeproblem, siehe auch https://forum.fhem.de/index.php/topic,122485.msg1170459.html#msg1170459);
- stateFormat (u.a. 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 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, 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)
- (eventuell "verlorene IO's" bei Verwendung von HMUARTLGW (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 (Vollversion: 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?)

und die gepatchte 00_HMLAN.pm nutzen:
https://forum.fhem.de/index.php/topic,120600.msg1153590.html#msg1153590

Da in

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).
(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

[the ratman]

sagts mal, hab ich was verpennt, oder muß man sich um martin sorgen machen?