CUL_HM Config handling update - beta tester

[martinp876]

Ich bereite den Update des Config-handling für CUL_HM vor. Hier gibt es die vorab Version für beta-tester.

Definition:
Config für FHEM sind primär die Attribute. Config der Devices (also register) sind nicht Thema hier

Ziel, Hintergrund:
fhem bietet seit einiger Zeit die Option, Attribute je entity zu definieren. Das reduziert die angebotenen Attribute auf die, welche wirklich zur Entity passen. Das betrifft Attribute wie auch deren möglicher Werte.
Attribute gibt es in den "Klassen":
Generell - wird von fhem-central verwaltet
CUL_HM: CUL_HM muss das Attribut bedienen und verwalten
User: User business. So lange der User dies definiert hat ist alles zulässig.

Konsequenz:
Attribute, welche unzulässig sind werden konsequent nicht zugelassen oder entfernt.
Der Anspruch, welcher beim Zuweisen des Attributs gilt wird über die Lebensdauer aufrecht erhalten.
Attribute werden auf Stand gehalten nach Bestem Vermögen.

Beispiel rename:
schon bisher war in CUL_HM implementiert, bei einem Rename alle Referenzen auf den alten Namen umzustellen auf den neuen. Das wird nun auch CUL_HM-externe entites ausgeweitet - was im Wesentlichen IOs betrifft.

Beispiel Obsolet
Die Attribute "IOgrp" und "IOdev" schliessen sich aus. Der User kann einstellen, das die vccu sich um das IO kümmert ODER er definiert sein eigenes ODER er überlässt alles dem fhem-kernel.
Wenn der User also IOgrp setzt wird IODev gelöscht. Das Attribut stehen zu lassen ist irreführend und schlicht falsch. Nichts schlechter als falsche Info.
Wird "attr dev IODev IO1" gesetzt und dann IO1 gelöscht wird auch das Attribut gelöscht.

Config vs admin
Define, rename,... sind konfigurationen.
Das Attribut "ignore" sehe ich als "admin". Ich kann es nutzen, ein IO ausser Betreib zu nehmen - und später wieder in Betrieb. Somit wird bei "ignore" das Attribut "IODev" nicht gelöscht. Allerdings wird dann auch nichts gesendet.

Würde ich "ignore" als Config betrachten wäre es für das User-device wie ein "delete" zu werten. Eine mögliche Implementierung

Der aktuelle Stand ist bei mir operationell. Ein Sichern des "cfg" kann vor dem Test nicht schaden.

Kommentare gerne.

[noansi]

Hallo Martin,

der Ansatz des besseren Attribut Handlings gefällt mir. 

Erstes Feedback:
In Zeile 471

Code Auswählen Erweitern

      delete $attr{$name}{$_} if (CUL_HM_AttrCheck($name,$_,$attr{$name}{$_})); 

ist mir aufgefallen, dass das Aufräumen nach dem Init wegen fehlendem 'set' noch nicht funktionieren kann.

Code Auswählen Erweitern

      delete $attr{$name}{$_} if (CUL_HM_AttrCheck($name, 'set', $_, $attr{$name}{$_})); 


EDIT: und das Aufräumen scheitert dann bei:

Code Auswählen Erweitern

2021.07.18 01:44:01.340 1: CUL_HM attr tempListTmpl removed for TR_Wohnen_Clima. Inadequate

für meine RTs.

Gruß, Ansgar.

[noansi]

Hallo Martin,

in CUL_HM_assignIO sowie für das Attribut selbst wird die Doku zum Attribut IOgrp

Code Auswählen Erweitern

          If none is detected in the prefIO list the mechanism is stopped and the IO as of IOdev is assigned

noch nicht berücksichtigt.

Andere Interpretation, die Doku ist noch nicht angepasst, da für die Nutzung des Attributs IODev nun IOgrp gelöscht werden soll, nach Attribut IODev Code.

Fällt mir auf, weil das Thema vor nicht allzu langer Zeit schon mal aufgekommen ist.

Gruß, Ansgar.

[noansi]

Hallo Martin,

hier ab Zeile 10754 in CUL_HM_assignIO

Code Auswählen Erweitern

    AssignIoPort($hash,$newIODevH->{NAME}); #  send preferred
    my $ID = CUL_HM_hash2Id($hash);
    IOWrite($hash, "", "remove:".$ID) if(defined($oldIODevH) && defined $oldIODevH->{NAME}); #IODev still old
    $hash->{IODev} = $newIODevH;

wird der remove beim neuen IO landen, statt beim alten, wenn das Attribut IODev nicht gesetzt ist, da dann AssignIoPort das Internal IODev setzt.

In geänderter Reihenfolge sollte auch das remove mit dem richtigen IO funktionieren:

Code Auswählen Erweitern

    my $ID = CUL_HM_hash2Id($hash);
    IOWrite($hash, "", "remove:".$ID) if(defined($oldIODevH) && defined $oldIODevH->{NAME}); #IODev still old
    AssignIoPort($hash,$newIODevH->{NAME}); #  send preferred
    $hash->{IODev} = $newIODevH;


Die letzte Zeile ist notwendig, um die Nutzung des neu gewählten IODev zu erzwingen, auch wenn AssignIoPort es ablehnt, es zu übernehmen, weil das Attribut IODev dem entgegen spricht (obwohl es nicht passieren sollte, wenn Attribut IOgrp ohne Attribut IODev genutzt wird, da das setzen von Attribut IOgrp das Attribut IODev löscht).

Alternativ wäre es natürlich dann auch möglich, das durch AssignIoPort gesetzte Internal in der Folge weiter zu nutzen, statt $newIODevH, was dem Sinn der Beschränkungen entspricht, die Rudolf bezüglich des Attributs IODev nun mal sieht und deutlich gemacht hat. Wenn der User dann Automatik will, dann muss er das Attribut IODev löschen.

Gruß, Ansgar.

[noansi]

Hallo Martin,

in Zeile 1459 in CUL_HM_hmInitMsg($)

Code Auswählen Erweitern

  my $wu = $hash->{helper}{io}{flgs} ? ($hash->{helper}{io}{flgs} & 0x02) : 0;
# CUL_HM_hmInitMsgUpdt($hash, $wu);

führt das Auskommentieren von  CUL_HM_hmInitMsgUpdt dazu das die IOs ihre Clients erst mitgeteilt bekommen, wenn das erste mal zu ihnen gesendet wird.
Da fehlt ein geeigneter Ersatz, wenn Du es da raus haben möchtest.

Das CUL_HM_assignIO($) in CUL_HM_updateConfig($) kann es beim FHEM Restart nicht dienstleisten, weil der CUL_HM_setupHMLAN Timer erst nach dem INITIALIZED notify ausgeführt wird und damit der init ans IO aus CUL_HM_assignIO noch keine Information zum Senden an das IO vorfindet.

Auch das CUL_HM_hmInitMsg in CUL_HM_updateConfig($) ist zu spät, um die Information zu setzen. Ein Vorziehen an dieser Stelle erfordert weitere Änderungen wegen Abhängigkeiten.

Gruß, Ansgar.

[noansi]

Hallo Martin,

mir ist noch aufgefallen, dass der peerCheck beim fhemstart fehlschlägt und somit die Channels diverser devices auf PeerIncom enden.

Das verschwindet, wenn ich den autoLoadArchive von HMinfo in HMinfo_init() verzögere, bis $modules{CUL_HM}{helper}{initDone} gesetzt ist.

Der damit verbundene Config Check kommt sonst zu früh.
Vermutlich wäre es aber besser, den Config Check, statt des autoLoadArchive zu verzögern, bis $modules{CUL_HM}{helper}{initDone} gesetzt ist, damit auch die peerListe intern richtig gesetzt ist.

Gruß, Ansgar.

[noansi]

Hallo Martin,

vermute ich richtig, dass Zeile 729

Code Auswählen Erweitern

  if($modules{CUL_HM}{helper}{primary} = $oldName){

als

Code Auswählen Erweitern

  if($modules{CUL_HM}{helper}{primary} eq $oldName){

gedacht war?

EDIT:
Dann müsste wohl auch ab Zeile 1529

Code Auswählen Erweitern

        CUL_HM_primaryDev() if ($ent eq $modules{CUL_HM}{helper}{primary});
        CUL_HM_Rename($new,$ent) if($evnt eq "RENAMED");

vertauscht werden:

Code Auswählen Erweitern

        CUL_HM_Rename($new,$ent) if($evnt eq "RENAMED");
        CUL_HM_primaryDev() if ($ent eq $modules{CUL_HM}{helper}{primary});

damit CUL_HM_Rename dem zufällig als erstes gefundenen neuen primary nicht mal die notifies abschaltet.

Gruß, Ansgar.

[noansi]

Hallo Martin,

das geänderte "# create missing CCU channels" in CUL_HM_UpdtCentral($) erzeugt bei mir einen VCCU Button 00.

Der Code macht das wohl, weil beim Repeater am Ende

Code Auswählen Erweitern

attr Repeater_HM peerIDs 00000000,2A133F00,2A133F01,56C58000,56C58001,F1103400

die Zentrale ohne Broadcastkennzeichnung steht.

Ein

Code Auswählen Erweitern

    next if (!$btn);

nach Zeile 10630 würde das unterdrücken.

Gruß, Ansgar.

[noansi]

Hallo Martin,

mir ist noch aufgefallen, dass CUL_HM_UpdtCentral das peerIds Atrribut für VCCU Buttons falsch zusammenbaut, so dass VCCU channel peers fehlen.

Gruß, Ansgar.

[martinp876]

Ein Update.
Ansgars Infos noch nicht enthalten. Weitere arbeiten sind notwendig... aber tests helfen.

[frank]

moin.

Beispiel Obsolet
Die Attribute "IOgrp" und "IOdev" schliessen sich aus. Der User kann einstellen, das die vccu sich um das IO kümmert ODER er definiert sein eigenes ODER er überlässt alles dem fhem-kernel.

dieses "gemischte" vorgehen hat in der vergangenheit nicht funktioniert. ich meine mit aes gab es probleme.
es galt: entweder alles über vccu, oder nichts.
siehe https://forum.fhem.de/index.php/topic,63284.msg560186/topicseen.html#msg560186

und attr dummy nicht vergessen
sowohl im device als auch im io.

wenn kein io assignt ist (zb dummy), wird das dann im internal IODev zukünftig registriert, zb mit "none"?

[martinp876]

So - updated - danke fürs prüfen.

Die Probleme mit IODev von Ansgar bestehen nicht, da das Attribut gelöscht und das Setzen verhindert wird, so lange IOgrp gesetzt ist.

Attr "Ignore" sehe ich nicht also Config sondern als maintenance. Das IO wird also nicht aus den Referenzen gelöscht - es wird aber auch nicht genutzt.
Dummy verhält sich gleich.
Will man ein IO aus der ccu Konfiguration nehmen löscht man es aus IOlist der vccu. Das sollte machbar sein. Löschen löscht es.

Ich denke das ist konsequent und somit nachvollziehbar.

Noch einmal der Unterschied:
Define/delete/rename ändert die Konfiguration und führt zu Anpassungen in den referenzierten/renden Entites.
Attr wie ignore/dummy sind maintenance aktionen und möglicherweise temporär. Da es nicht Config ist wird auch die Config nicht angepasst. Die Selektion des IO erfolgt zum operativen Zeitpunkt

Also Konsequenz muss FHEM nicht bei jeder Gelegenheit prüfen, ob eine Zugewiesene Entity noch existiert wenn sie genutzt werden soll.

[noansi]

Hallo Martin,

mir ist noch aufgefallen, dass CUL_HM_UpdtCentral das peerIds Attribut für VCCU Buttons falsch zusammenbaut, so dass VCCU channel peers fehlen.

Es fehlt ein vorbereitendes

Code Auswählen Erweitern

    CUL_HM_ID2PeerList($modules{CUL_HM}{defptr}{$ccuBId}{NAME},'peerUnread',1);

vor dem zufügen der peers, dann fehlen die peers nicht mehr.

Gruß, Ansgar.

[frank]

scheinbar braucht es für dieses experiment ein top aktuelles fhem, sonst gibt es chaos.

Code Auswählen Erweitern

2021.07.20 13:28:16.902 1: reload: Error:Modul 10_CUL_HM deactivated:
Too many arguments for main::notifyRegexpChanged at ./FHEM/10_CUL_HM.pm line 274, near "1)"
Too many arguments for main::notifyRegexpChanged at ./FHEM/10_CUL_HM.pm line 560, near "0)"
Too many arguments for main::notifyRegexpChanged at ./FHEM/10_CUL_HM.pm line 650, near "1)"
Too many arguments for main::notifyRegexpChanged at ./FHEM/10_CUL_HM.pm line 732, near "1)"
BEGIN not safe after errors--compilation aborted at ./FHEM/10_CUL_HM.pm line 3453, <$fh> line 379.

[noansi]

Hallo Martin,

CUL_HM_noDup(@) liefert bei Übergabe eines leeren arryas einen Leerstring zurück, statt eines leeren arrays.

Das macht bei der VCCU Peers Suche Probleme mit Warnings und Erstellen eines "irren" VCCU Buttons, wenn keine VCCU Buttons definiert sind/kein VCCU Peerings zu finden sind.

Leeres Array zurückliefern hilft dagegen:

Code Auswählen Erweitern

sub CUL_HM_noDup(@) {#return list with no duplicates
  return @_ if (!scalar(@_)); #noansi: return empty array instead of empty string
  my %all;
  $all{$_}=0 foreach (grep {defined $_ && $_ ne ''} @_); #remove also empties if present
  return (sort keys %all);
}


Ich sehe nicht, wofür der Leerstring als Rückgabe gut sein soll?

Gruß, Ansgar.