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

[Beta-User]

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.

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

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

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?

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

[Beta-User]

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

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.

[frank]

setze 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?

[Beta-User]

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.

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

[Beta-User]

...und weil's grade so nett ist, hier noch eine Ergänzung betr. das deviceRename...

[frank]

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.

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

das halte ich auch für falsch.

[Beta-User]

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.

[Beta-User]

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

[Beta-User]

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

EDIT: Kleinigkeiten nachträglich geändert, aber nichts substantielles => geht immer noch nicht...

[Beta-User]

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 .

[Beta-User]

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!