CUL_HM Config handling update - beta tester

martinp876 · 17 Juli 2021, 09:59:36

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 · 17 Juli 2021, 14:10:02

Hallo Martin,

der Ansatz des besseren Attribut Handlings gefällt mir.

Erstes Feedback:
In Zeile 471

Code Auswählen

      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

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

EDIT: und das Aufräumen scheitert dann bei:

Code Auswählen

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 · 17 Juli 2021, 17:06:37

Hallo Martin,

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

Code Auswählen

          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 · 17 Juli 2021, 20:18:23

Hallo Martin,

hier ab Zeile 10754 in CUL_HM_assignIO

Code Auswählen

    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

    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 · 18 Juli 2021, 12:08:18

Hallo Martin,

in Zeile 1459 in CUL_HM_hmInitMsg($)

Code Auswählen

  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 · 18 Juli 2021, 15:23:55

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 · 18 Juli 2021, 16:09:09

Hallo Martin,

vermute ich richtig, dass Zeile 729

Code Auswählen

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

als

Code Auswählen

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

gedacht war?

EDIT:
Dann müsste wohl auch ab Zeile 1529

Code Auswählen

        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

        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 · 18 Juli 2021, 17:15:15

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

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

die Zentrale ohne Broadcastkennzeichnung steht.

Ein

Code Auswählen

    next if (!$btn);

nach Zeile 10630 würde das unterdrücken.

Gruß, Ansgar.

noansi · 18 Juli 2021, 19:24:53

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 · 18 Juli 2021, 20:24:48

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

frank · 19 Juli 2021, 12:56:57

moin.

ZitatBeispiel 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 · 19 Juli 2021, 19:56:43

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 · 19 Juli 2021, 21:59:09

Hallo Martin,

Zitatmir 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

    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 · 20 Juli 2021, 14:19:06

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

Code Auswählen

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 · 28 Juli 2021, 22:13:49

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

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.

martinp876 · 01 August 2021, 11:01:44

@frank: ja, das neuste fhem.pl ist notwendig. Rudi hat nachgebessert
@Ansgar: noDup muss ich noch untersuchen. Wird häufig benötigt... muss man grünlich prüfen.

Die neue Version hat Änderungen off-topic AttrStreamline
- handling von peers für devices welche die Peerlist um 1 Byte zu kurz angeben. Sowie den Shortcut "PeerDev" als substitut für "viele Channels"
-abschalten des commState in channels - siehe Attr commStInCh

Beschreibung kommt noch.
Ausserdem will ich die Beschreibung der Attribute sichtbarmachen. Das ist bei CUL_HM aktuell nicht der Fall - warum?

Going life ist dann nächste Woche - immerhin sind keine kritischen Anmerkungen gekommen. Danke fürs testen.

noansi · 01 August 2021, 21:17:08

Hallo Martin,

Zitat-abschalten des commState in channels - siehe Attr commStInCh

Default off, statt on, demnach also einschalten via commStInCh wäre willkommener.

Was hast Du mit attr tempListTmpl für die Clima Channels der RTs vor?

Code Auswählen

2021.08.01 20:42:12.057 1: CUL_HM attr tempListTmpl removed for TR_Dusche_Clima. Inadequate
2021.08.01 20:42:12.762 1: CUL_HM attr tempListTmpl removed for TR_Wohnen_Clima. Inadequate

habe ich noch.
Wenn das Attribut für die Clima Channels nicht erlaubt ist, dann funktioniert auch das set tempTmplSet nicht, es kann nur default, also entity name gesetzt werden.

Gruß, Ansgar.

Beta-User · 02 August 2021, 14:28:13

Zitat von: martinp876 am 01 August 2021, 11:01:44
Ausserdem will ich die Beschreibung der Attribute sichtbarmachen. Das ist bei CUL_HM aktuell nicht der Fall - warum?

Weiß nicht, ob die beigefügte Datei das komplett beseitigt. "Eigentlich" sollte neuerdings die "id"-Schreibweise verwendet werden (https://forum.fhem.de/index.php/topic,118915.msg1135123.html#msg1135123), dann müßte das passen. Ich vermute, dass bisher versucht wurde, aus der "alten name"-Syntax die passenden Zuordnungen abzuleiten, was halt mal besser und mal gar nicht geklappt hat (auch für das Finden von Ankern für href etc.).
Wie dem auch sei, ich hoffe, dass damit zumindest ein Anfang gemacht ist, auf dem du aufbauen kannst.

Geändert ist nur die commandref.
(Mehr Optionen und Details: https://forum.fhem.de/index.php/topic,120779.msg1166266.html#msg1166266 und der Link da zu MQTT_GENERIC_BRIDGE).

EDIT: bei einigen der Anker&id's war ich nicht so richtig sicher, wie die eigentlich sein sollten (betrifft z.B. CUL_HM-events und -internals und (im engl. Teil) getSerial)

Zitat
Going life ist dann nächste Woche - immerhin sind keine kritischen Anmerkungen gekommen. Danke fürs testen.

Aufgrund der aktuellen Probleme mit HMInfo (https://forum.fhem.de/index.php/topic,122313.0.html) wäre ggf. zu überlegen, ob das nicht vorgezogen werden sollte (auch wenn es dann ggf. andere Probleme gibt). Bekannte Komplettabstürze sollte man jedenfalls möglichst vermeiden...

betateilchen · 02 August 2021, 23:21:27

Hallo Martin,

wenn Du eine 98_HMinfo.pm eincheckst, die zwingend diese Entwicklungsversion von CUL_HM benötigt, solltest Du auch die passende CUL_HM dazu einchecken

ralf-ms · 03 August 2021, 07:58:32

Moinsen,

ich hab heute morgen ein "update all" gemacht, weil's mal wieder notwendig war.
fhem kam nicht mehr hoch, weil

Undefined subroutine &main::CUL_HM_AttrInit called at ./FHEM/98_HMinfo.pm line 1021, <$fh> line 562.

Als "Workaround" hab ich die Zeile auskommentieren müssen.
Hätte ich irgendwas beim update anders machen sollen?
Fehlt irgendwas in meiner config?
Evtl hängt das ja mit den hier diskutierten Änderungen zusammen (ich muss zugeben, ich hab's hier nur so grob überflogen...)

betateilchen · 03 August 2021, 09:31:04

Zitat von: ralf-ms am 03 August 2021, 07:58:32
Fehlt irgendwas in meiner config?

Ja, Dir fehlt eine passende Moduldatei 10_CUL_HM.pm

Darauf bezog sich schon mein gestriger Hinweis hier im Thread genau vor Deinem Beitrag.

--

ralf-ms · 03 August 2021, 10:26:50

Ah, jetzt hab ich's!
Der Kreis ist geschlossen, also auf das passende 10_CUL_HM Modul warten, das CUL_HM_AttrInit zur Verfügung stellt.
Ok, dann leg ich mich mal wieder hin...

the ratman · 03 August 2021, 12:47:28

ich hätte da https://forum.fhem.de/index.php/topic,122313.msg1168982.html#msg1168982 eventuell noch was zum spielen fürs neue cul_hm. (frank hat mich hierher verwiesen, weil ichs verpennt hatte)

martinp876 · 03 August 2021, 15:47:04

Hminfo war ein Fehler wegen der Verbindung. Werde ich klären und berichtigen- in hminfo.
Templateset wird natürlich korrigiert.
Das mit den Attributen werde ich studieren

martinp876 · 08 August 2021, 10:19:01

Die neue Version ist nun live.
Ich schliesse diesen Threat - alle Probleme werden nun wieder wie üblich behandelt. Ich habe noch nicht alle sonsitgen ausstehenden Probleme hier behandelt - es müssen also noch updates kommen.
Primär sind Attribute nun Entity spezifisch - und ich versuche diese so schmall wie möglich zu halten. Und so weit wie nötig.
Weiter werden (bestmöglich) Abhängigkeiten nachgezogen. Hat CUL_HM schon immer versucht. Bedeutet wenn ein Device umbenannt wird, wird es in allen bekannten Referenzen auch nachgezogen.
Wird ein Attribut gesetzt welches ein anderen Ausschliesst wird es entweder nicht zugelassen oder das andere entfernt.

Beta-Test-Abgeschlossen! Now live.