[CUL_HM] patches Oktober 2021 - die Zweite

[Udomatic]

Stichwort levelInverse?

Ja und warum, hat doch die ganze Zeit ohne Level Inverse funktioniert?!

[Beta-User]

Ja und warum, hat doch die ganze Zeit ohne Level Inverse funktioniert?!

Show us!
Bitte in cfg vor dem update schauen.

[Udomatic]

Show us!
Bitte in cfg vor dem update schauen.

Ok, hier gehts weiter

https://forum.fhem.de/index.php/topic,123688.0.html

[frank]

Ist die jeweils letzte Version von CUL_HM denn jetzt "vorschlagsfähig", was "autocreate" angeht?

wahrscheinlich nein.

pairing nicht vom User angestoßen,...

was meinst du damit?
das kann doch eigentlich nur bedeuten, dass du den empfang einer anlernmessage meinst, was aber kein pairing ist.

also definiert jede anlernmessage vom nachbarn ein device in fhem. sicherlich ohne attr ignore=1, oder?
das wiederum bedeutet, dass hminfo configcheck ziehmlich umfangreich wird, oder übersehe ich gerade was 
dann wird wohl auch jedem device ein io assigned. bin nicht sicher, ob das dann beim nachbarn reinquatscht.

hast du mal ein list von so einem device? am besten vor und nach restart.
ständig rote fragezeichen? da wird es hier aber viele threads geben.

eine echte ccu speichert auch keine nachbar devices.

[Beta-User]

Details müssen wir uns nochmal ansehen.
Es ist kein direktes Nutzen von autocreate wie in der Intro dargestellt, eher ein Tricksen wie ZWave das macht, das ganze aber immer unter den "alten" Voraussetzungen, so dass zumindest keine neuen Probleme entstehen sollten.

Diff sind im ersten Post. Mehr Details ein anderes Mal.

[Timmäää]

Update des HMLAN läuft bei mir ohne Probleme.
Ergänzung: Ich setze eine vccu mit zwei IO, dem HMLAN und einem CUL, ein.

[Beta-User]

Update des HMLAN läuft bei mir ohne Probleme.

Danke für die Rückmeldung, dann werde ich Martin mal anpingen wg. FHEM 6.1 - CUL_HM+ ist damit die letzte Hürde.

Anbei dann eine Version, die wenigstens ins Log schreibt, dass CUL_HM nicht rereadcfg-fest ist... (sonst nichts neues)


Zu dem autocreate-Thema:

was meinst du damit?
das kann doch eigentlich nur bedeuten, dass du den empfang einer anlernmessage meinst, was aber kein pairing ist.

Nach wie vor tue ich mich schwer, den Funkverkehr und den Code ohne weiteres in Deckung zu bringen . Mein Ausgangspunkt ist die von Martin vercodete Fallunterscheidung (#1748)

Code Auswählen Erweitern

if(!$mh{devH} && $mh{mTp} eq "00") { # generate device ?Die aktuelle svn-Fassung führt in so einem Fall immer ein CommandDefine() aus, was m.E. nicht in jedem Fall erwünscht ist.

Ergo ist der Vorschlag, das nur zu machen, wenn entweder die "zuständige" VCCU oder das IODev im pairing-Modus sind, oder das allgemeine autocreate aktiv (über diesen letzten Punkt kann man m.E. diskutieren, über den Weg bis dahin eigentlich nicht, oder?).

Über Fernwirkungen habe ich bisher nicht weiter nachgedacht, da bis hierhin eigentlich eher alles "beim alten" sein sollte...

also definiert jede anlernmessage vom nachbarn ein device in fhem. sicherlich ohne attr ignore=1, oder?

Ob man bei nicht-laufendem pairing dann attr ignore setzen sollte, ist eine gute Frage (oder doch das autocreate ignorieren?). Im Moment ist es so gedacht, dass autocreate nur stattfindet, wenn keine VCCU zuständig ist, die das als "unknown_AB3456" einfangen würde.

das wiederum bedeutet, dass hminfo configcheck ziehmlich umfangreich wird, oder übersehe ich gerade was 

Vermutlich; aber eben nur, wenn keine VCCU vorhanden ist (=>selber schuld...?)

dann wird wohl auch jedem device ein io assigned. bin nicht sicher, ob das dann beim nachbarn reinquatscht.

Unschön. Bin für Vorschläge offen .

eine echte ccu speichert auch keine nachbar devices.

Das mag ja sein, aber ist der Vorschlag, "unknown_.*" in der VCCU abzuschaffen? Oder ist es nur eine Begründung, warum man den Zweig

Code Auswählen Erweitern

} elsif (!IsDisabled((devspec2array('TYPE=autocreate'))[0]) && !defined InternalVal($mh{ioName},'owner_CCU',undef)) {
nicht ausführen sollte? (bzw. stattdessen eine Zeile ins Log schreiben mit Hinweis auf "pairing nicht aktiv, bitte VCCU definieren oder pairing-Modus aktivieren"?).

EDIT: Nach etwas Nachdenken finde ich die "schreib was ins log"-Variante eigentlich die beste. Der User bekommt einen deutlichen Hinweis, wenn er ins log schaut, es werden keine unnötigen Devices angelegt, und wir haben auch noch eine Option, auf CCU-FHEM hinzuweisen...

EDIT2: HMLAN sollte jetzt auch beim define was ins log schreiben...

[Beta-User]

so mittlerweile mit neuerem  cul_hm gibt es probleme bei einem getconfig.

wenn der hmuart sendet, wird kein A112 gesendet, sodass der vd einschläft.
[...]
entweder ansgars optimierungen sind nie eingeflossen, oder sie sind wieder kaputt.
schade eigentlich.

Zu einem großen Teil waren die betreffenden Codevorschläge von noansi nicht im aktuellen CUL_HM drin. An einer Stelle scheint was eingeflossen zu sein, es gab aber vor meinem genau einen Download der kompletten CUL_HM, das wirst dann du gewesen sein.

Anbei der Versuch, das zu integrieren, an einer Stelle war m.E. keine Änderung notwendig, ansonsten _könnte_ das so passen, richtig Testen (und ein aktualisiertes diff liefern) kann ich aber auch erst wieder frühestens heute abend. (Status daher ausdrücklich: experimentell!).

Auch, wenn wir alle des Testens möglicherweise müde sind: Wie immer wäre es toll, wenn sich jemand finden würde, der das Risiko eingehen kann und mag...

Nachtrag noch zur Frage der "doppelten Clients" in HMLAN: Das ist m.E. kein Problem, da geht es einmal um den Code-Hash, und einmal um den Instanz-Hash. Jedenfalls in letzterem ist es erforderlich, wenn man es nicht in CU_HM fixen will, und anscheinend schadet es auch nicht, wenn es zusätzlich im Instanz-Hash steht.

[Beta-User]

scheinbar werden die io nicht unassigned, wenn man ein device auf ignore setzt, denn hmlan2 sendet weiterhin autonom die uhrzeit an 303AF8.
ein neuer bug.

Sorry, hatte ich irgendwie zu spät wieder auf dem Schirm, daher gleich noch ein update, das auch das noch beseitigen könnte. (Ist aber eher ein "fix auf Verdacht"...). die Idee dahinter ist, dem betreffenden Gerät kein IO zuzuweisen, ich bin nicht ganz sicher, ob da auf dem gewählten Weg auch klappt .

PS: Danke für die schnellen Downloads aus dem letzten Post!

[frank]

moin,

erst mal kurz zu a112:
ansgars version aus #47 ist meiner meinung nach der beste kompromiss gewesen. diese version habe ich dann sehr lange genutzt, bis zu einer svn version ende september mit attribut-check.
ich vermute, dass der grosse auskommentierte codeblock am ende von cul_hm_assignio anhaltspunkte geben könnte. nicht umsonst hat martin hier so viel alten code aufbewahrt. 

Auch, wenn wir alle des Testens möglicherweise müde sind

vor allem sinnloses, weil unnötiges, testen macht mich besonders müde. 

dieses problem ist ja super speziell und erfordert viele tests, da alle möglichen kombinationen von unterschiedlichen io in 2 verschiedenen devices eine rolle spielen. bei mir 3x3=9 kombinationen, die jeweils ziehmlich lange dauern und anschliessend aufwändig analysiert werden müssen.
da will ich eigentlich erstmal herausfinden, was ansgar wirklich gemacht hat, um auch später in martins versionen vorab sehen zu können, ob und vor allem was er wie übernommen hat.

ich finde deinen einsatz wirklich wunderbar, aber bitte keine schnellschüsse.
ansgars deutliche zurückhaltung seit nun schon längerer zeit lässt mich auch viel spekulieren.



ps: zu ignore

die Idee dahinter ist, dem betreffenden Gerät kein IO zuzuweisen

vor allem muss das gerät aus dem io entfernt werden (remove), wenn man das attribut ignore setzt.


edit: da war die reihenfolge der absätze durcheinandergeraten.

[Beta-User]

erst mal kurz zu a112:
ansgars version aus #47 ist meiner meinung nach der beste kompromiss gewesen. diese version habe ich dann sehr lange genutzt, bis zu einer svn version ende september mit attribut-check.

Hmm, der Teil war eigentlich schon länger in "meiner" Patch-Sammlung drin, wenn ich den Überblick nicht komplett verloren habe...
Ggf. müßten dann die Änderungen von heute morgen teiweise wieder raus? (Da hatte ich leider deinen heutigen Hinweis im anderen Thread offenbar falsch verstanden, dass das noch nicht gefixt sei.)

ich vermute, dass der grosse auskommentierte codeblock am ende von cul_hm_assignio anhaltspunkte geben könnte. nicht umsonst hat martin hier so viel alten code aufbewahrt. 

Anhaltspunkte vielleicht, aber ich bin auch etwas müde, was raten angeht...

ps: zu ignorevor allem muss das gerät aus dem io entfernt werden (remove), wenn man das attribut ignore setzt.

...auch wieder wahr... Es muss sowohl beim startup beachtet werden wie auch bei Änderung im laufenden Betrieb. Fix-Versuch anbei (direkter remove beim Setzen des Attributs, dto. für dummy). Eigentlich sollte das keine großen Tests erfordern, aber vermutlich übersehe ich wieder was...

ich finde deinen einsatz wirklich wunderbar, aber bitte keine schnellschüsse.
ansgars deutliche zurückhaltung seit nun schon längerer zeit lässt mich auch viel spekulieren.

Fühle mich auch deutlich unwohl in der jetzigen Rolle und würde mich gerne wieder zurückziehen. Andererseits will ich die User auch nicht komplett alleine lassen.

Anbei ist eine Version mit #47 + den sonstigen Stand von hier zurückgeschraubt (also entfernt, was zwischen #47 und heute morgen aus ansgars letzter Version eingeflossen war).

[frank]

Anbei ist eine Version mit #47 + den sonstigen Stand von hier zurückgeschraubt (also entfernt, was zwischen #47 und heute morgen aus ansgars letzter Version eingeflossen war).

den satz habe ich jetzt schon 6-7 mal gelesen, aber noch nicht wirklich durchschaut.   

trotzdem mal getestet + 00_hmlan.
-grob drübergeschaut: A112 verhalten beim vd sieht bei allen 3 io identisch wie gestern aus.
-die verschobene hmlan doinit zeigt jetzt auch alle cmds.
-sonst keine auffälligkeiten

[Beta-User]

den satz habe ich jetzt schon 6-7 mal gelesen, aber noch nicht wirklich durchschaut.   

, ja, verständlich schreiben ist nicht so einfach. Gemeint war: die Version von noansi aus Post #47 (im Thread zu dem A112-Thema) war schon länger in die hier zusammengeführten Patches integriert. Das hatte ich heute morgen erst auf den Stand von der letzten von noansi geposteten Fassung aus den nämlichen Thread gebracht, in der irrigen Annahme, dass die besser sei wie die aus #47. Also habe ich das wieder auf den Ausgangsstand (= Fassung aus #47) zurückgedreht, was diese Teile angeht.

Was

trotzdem mal getestet + 00_hmlan.
-grob drübergeschaut: A112 verhalten beim vd sieht bei allen 3 io identisch wie gestern aus.
-die verschobene hmlan doinit zeigt jetzt auch alle cmds.
-sonst keine auffälligkeiten

betrifft, habe ich nun wieder ein kleines Verständnisproblem: Ist das betr. A112 jetzt insgesamt (=alle IO-Typen?) ok, oder insgesamt buggy...? (vermutlich eher letzteres!)

Sonst scheint es soweit erkennbar erst mal ok zu sein, oder verstehe ich wieder was falsch?

(PS: HMLAN sollte eigentlich u.A. auch alle von dir benannten Patches enthalten).

[frank]

Gemeint war: die Version von noansi aus Post #47 (im Thread zu dem A112-Thema) war schon länger in die hier zusammengeführten Patches integriert. Das hatte ich heute morgen erst auf den Stand von der letzten von noansi geposteten Fassung aus den nämlichen Thread gebracht, in der irrigen Annahme, dass die besser sei wie die aus #47. Also habe ich das wieder auf den Ausgangsstand (= Fassung aus #47) zurückgedreht, was diese Teile angeht.

ok, verstanden.   

Sonst scheint es soweit erkennbar erst mal ok zu sein, oder verstehe ich wieder was falsch?

falsch verstanden. 
das gezeigte fehlverhalten im vd thread ist mit deiner version hier aus #70 identisch. keine verbesserung/verschlechterung. #70 habe ich dann sogar noch ein 2. mal runtergeladen und verglichen.
das "normale" betreiben der vd ist weiterhin gut, also erstmal nichts dringendes.

eine saubere, fehlerfreie io zuordnung finde ich derzeit wichtiger.
wünsch dir mal ein paar events zum reading IODev. rudi hat eine abstimmung gestartet.
https://forum.fhem.de/index.php/topic,123655.msg1182673.html#msg1182673

[frank]

Fix-Versuch anbei (direkter remove beim Setzen des Attributs, dto. für dummy). Eigentlich sollte das keine großen Tests erfordern, aber vermutlich übersehe ich wieder was...

konnte ich gerade nicht festellen.
das device ist zumindestens weiterhin unter "get assignIDs" beim hmlan zu finden. im log war auch nichts zusehen.