[CUL_HM] patches Oktober 2021 - die Zweite

[MadMax-FHEM]

[OT!]

für den anfang: nur 2 dateien kopieren und über attribute aktivieren.
spart dann wahrscheinlich ganz automatisch immer wieder zeit ein, da vieles ganz offensichtlich wird.
mittelfristig hast du also mehr zeit für andere dinge. 

Ok, ok

1x die "offizielle" auf ein Testsystem und die Testversion auf das andere Testsystem...

0.1. hm.js in den ordner /opt/fhem/www/pgm2 kopieren und vorhandene version ggf sichern. rechte beachten, zb über linux console:

0.4 wichtig: damit keine neuen templates nach fhem restart verloren gehen, unbedingt die hinweise zur vorbereitung im wiki beachten (link beim fragezeichen).

Das hat aber gedauert, bis ich das Fragezeichen entdeckt hatte

Mal sehen...

Gruß, Joachim
[/OT sorry]

[Beta-User]

Betr. OT: Kein Problem, solange Themen diskutiert werden, die potentiell für alle CUL_HM-User interessant sind, die wissen wollen, wie das aktuell "am besten" geht...

Betr. Meldungen: Niemand muss sich entschuldigen, wenn er hier was schildert, das er "bemerkenswert" findet .
Mir hat das jedenfalls jetzt geholfen, sowas wie einen Vorschlag für einen "Masterplan" betr. das "autocreate"-Thema zu entwickeln. Wird aber etwas dauern, bis ich das in Ruhe für mich selbst durchgegangen bin.

[Beta-User]

Hier also der Versuch, das "autocreate"-Thema zu lösen...

Soll-Szenarien:
a) pairing nicht vom User angestoßen, keine VCCU, autocreate ist deaktiviert => es soll nichts passieren außer evtl. Einträgen im Log
b) pairing nicht vom User angestoßen, keine VCCU, autocreate ist aktiviert    => Device soll angelegt werden, FileLog wird entsprechend autocreate-Vorgabe erstellt
c) pairing nicht vom User angestoßen, VCCU, autocreate ist deaktiviert => es soll nichts passieren, das Device wird von der VCCU eingesammelt, keine "help-me"-Einträge
d) pairing nicht vom User angestoßen, VCCU, autocreate ist aktiviert    => Device soll angelegt werden, FileLog wird entsprechend autocreate-Vorgabe erstellt, kein VCCU-Eintrag
e) pairing vom User angestoßen, keine VCCU, autocreate ist deaktiviert => Device wird im "CUL_HM-Way" angelegt (=>kein FileLog)
f) pairing vom User angestoßen, keine VCCU, autocreate ist aktiviert    => Device soll angelegt werden, FileLog wird entsprechend autocreate-Vorgabe erstellt
g) pairing vom User angestoßen, VCCU, autocreate ist deaktiviert => Device wird im "CUL_HM-Way" angelegt (=>kein FileLog), IO-Attribute "VCCU-like"
h) pairing vom User angestoßen, VCCU, autocreate ist aktiviert => Device soll angelegt werden, FileLog wird entsprechend autocreate-Vorgabe erstellt, IO-Attribute "VCCU-like"

Mit etwas Glück sollte die angehängte Fassung diese Szenarien entsprechend abbilden. @MadMax-FHEM: Könntest du das bitte mal durchspielen, ob das paßt? (Bitte wieder mit einem Testsystem anfangen...)

EDIT:
Nach etwas Nachdenken soll autocreate nicht angestoßen werden, wenn das pairing nicht läuft => nur noch Schreiben eines entsprechenden Log-Eintrags.

[Beta-User]

...und hier noch eine leicht veränderte Variante für HMLAN:
Da wird dann bei einem normalen FHEM-Start HMLAN_DoInit() erst in der NotifyFn() aufgerufen, aber früher wie die CUL_HM NotifyFn(), so dass der HMLAN dann jeweils bereits mit der richtigen hmId gestartet sein sollte, bevor dann die Initialisierung von CUL_HM aus stattfindet.

Bin zwar mal wieder nicht sicher, ob das viel hilft, aber sauberer ist es mAn. jedenfalls...

[frank]

hast du auch an mehrere vccu gedacht?

[Beta-User]

hast du auch an mehrere vccu gedacht?

Zumindest kurz .

Genauer meine ich, dass es so zu lesen ist:
keine VCCU = für das IODev ist keine VCCU zuständig,
VCCU = das IODev steht unter der Kontrolle einer VCCU

Ob das für das "Abfangen" mit einer VCCU (weiter hinten) auch klappt, wenn das "falsche" IODev die Daten reinspielt, habe ich aber nicht intensiver beleuchtet, da kann es theoretisch Lücken geben, die aber nicht gravierend sein sollten...

[frank]

beim anlegen einer 2. vccu, wurde dieser zumindestens neulich ein io zugewiesen, das bereits der 1. vccu gehörte.

[Beta-User]

Danke für den Hinweis, da hatte die neu eingeführte Prüfung wohl den falschen Bezugspunkt . Jetzt sollte es passen (update im "autocreate"-Beitrag).

[Beta-User]

Bisher sind Rückmeldungen eher spärlich gekommen, obwohl es ein paar downloads gab...

Folgende Probleme sind bekannt:
- CUL_HM ist definitiv nicht rereadcfg-fest, und ich habe auf die Schnelle auch keine Idee, wie man es reparieren könnte (siehe https://forum.fhem.de/index.php/topic,123608.msg1182501.html#msg1182501)
- "A112" (wobei mir unklar ist, ob das ein neues oder altes Thema ist, und wer der eigentliche Verursacher)

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.

Ist die jeweils letzte Version von CUL_HM denn jetzt "vorschlagsfähig", was "autocreate" angeht? Was ist mit HMLAN? Dann wäre es Zeit, mal je einen patch draus zu machen und den ersten Beitrag upzudaten...

[MadMax-FHEM]

Bisher sind Rückmeldungen eher spärlich gekommen, obwohl es ein paar downloads gab...

Man kommt ja kaum mit dem Testen hinterher

Wobei ich noch nicht mal zu denen gehöre, die runtergeladen haben...
...aktuell leider unterwegs, da wird das mit Testen schwer

Aber ich werde das bzgl. autocreate mal durchschauen/-testen...

Gruß, Joachim

[frank]

Ist die jeweils letzte Version von CUL_HM denn jetzt "vorschlagsfähig", was "autocreate" angeht? Was ist mit HMLAN? Dann wäre es Zeit, mal je einen patch draus zu machen und den ersten Beitrag upzudaten...

sorry, aber nachdem ich im letzten update von martin keine änderungen der aktuellen probleme im diff gesehen habe, bin ich aus dem testen der versionen aus svn/oktober-patches wieder ausgestiegen.
es ist mir zu umständlich dauernd meine eigenen logmeldungen wieder einzubauen, um weitere probleme aufzuspüren.

verbesserungen baue ich bei mir natürlich auch ein.
allerdings habe ich autocreate nicht probiert, da ich an den einbau durch martin nicht wirklich glaube. 

keine meldungen sind gute meldungen. 
danke für deine bemühungen


ps: neulich gab es in 00_hmlan 2x "Clients". absicht?

[Udomatic]

Hallo,

seit dem letzten Update habe ich folgendes Problem und an den Attributen oder DOIF habe ich nichts geändert:

Ich habe an einen HM-LC-SW1PBU-FM einen HM-SEN-MDIR-WM55 gepeert, sodass der Bewegungsmelder das Licht steuert.

Seit dem Update schaltet der Bewegungsmelder das Licht nicht mehr an. Und wenn ich es am Schalter anschalte und der Bewegungsmelder eine Bewegung erkennt schaltet das Licht wieder aus!

Wie kann man das wieder heilen?

Gruß
Udo

[frank]

Ich habe an einen HM-LC-SW1PBU-FM einen HM-SEN-MDIR-WM55 gepairt, sodass der Bewegungsmelder das Licht steuert.

du meinst also gepeert.
dann ist aber fhem fein raus, und es liegt nicht am update.

da haben sich vermutlich die register im aktor geändert. eventuell ein reset gemacht?
ich denke du machst am besten einen eigenen thread auf und postest dort mal je ein list von beiden.

[Beta-User]

Stichwort levelInverse?

[frank]

Stichwort levelInverse?

gute idee.
dann also schalter richtig einbauen und register anpassen.

alternative für umweltsünder: die aktuellen patches plus "attr param levelInverse"