AttrFn und Hilfetext bei userattr

[fruemmel]

Hallo allerseits,

gibt es eine Möglichkeit das Setzen/Löschen/Verändern von selbst definierten Attributen (userattr) global in einer AttrFn abzufangen und z. B. syntaktisch zu prüfen?
Und als passende zweite Frage: gibt es eine Möglichkeit für entsprechende selbst definierte Attribute einen Hilfetext für die Eingabe bereitzustellen (Stichwort POD)?

Vielen Dank im voraus, Gruß Wolfgang

[Beta-User]

Was genau schwebt dir vor?

Es gibt diverse Module, die "ihre" Attribute allgemein verteilen, und (zumindest teilweise) auch eine Syntaxprüfung machen. Vielleicht schaust du dir unter dem Gesichtspunkt v.a. RHASSPY mal an. MQTT_GENERIC_BRIDGE und AutoShuttersControl wären weitere Kandidaten, aber da bin ich wegen der Syntaxprüfung nicht sicher, ob die das auch machen...

[fruemmel]

Ich habe bei mir ein userattr definiert, in dem ich hinterlegen kann, wie alt ein bestimmtes Reading bei einem konkreten Device (z. B. temperatur bei einem Sensor) sein darf. Je nach Konfiguration des Sensors kann dieses maximale Alter unterschiedlich sein. In einem Hilfsmodul verwalte ich die Devices, bei denen das userattr gesetzt ist und reagiere in der NotifyFn auf Aktualisierungen. In einer Timer-Routine stelle ich außerdem fest, wenn ein Reading zu lange nicht gesetzt wurde. Abhängig vom Alter des Readings (und des maximalen Alters im userattr) setze ich ein weiteres Reading im jeweiligen Device auf ok oder err. So kann ich z. B. veraltete Sensorwerte individuell erkennen und in FTUI markieren.

Ich kann aber z. B. nicht automatisch erkennen, wenn bei einem weiteren Sensor das userattr gefüllt wird, um es anschließend im Hilfsmodul zu überwachen. Auch eine Syntax-Prüfung ist an dieser Stelle nicht möglich. Außerdem kann ich beim Setzen des userattr im GUI derzeit keinen Hilfetext für die Syntax ausgeben.

[Beta-User]

Na ja, FHEMWEB verwaltet intern eine Liste, aus der sich ergibt, zu welchem Modul welches Attribut gehört. Funktionen dazu sind addToAttrList() und addToDevAttrList().

Vielleicht wird es klarer, wie das beim/nach FHEM-Start befüllt wird, wenn du dir die sub "initialize_prefix" im RHASSPY-Code anschaust und die commandref dazu (mit "wildcards", Stichwort "data-pattern").

"Eigentlich" müßte das auch mit myUtils-Code funktionieren.

[rudolfkoenig]

gibt es eine Möglichkeit das Setzen/Löschen/Verändern von selbst definierten Attributen (userattr) global in einer AttrFn abzufangen und z. B. syntaktisch zu prüfen?

Womoeglich funktioniert das mit einem cmdAlias:

Code Auswählen Erweitern

define myUserAttrChecker cmdalias attr .* AS { myUserAttrChecker($EVENT) }und der Funktion myUserAttrChecker in 99_myUtils.pm in etwa so:

Code Auswählen Erweitern

sub
myUserAttrChecker($)
{
  my @p = split(" ", @_[0], 3);
  if($p[1] eq "myRoom" && $p[2] eq "blue") {
    return "this is not allowed";
  }
  return CommandAttr(undef, join(" ", @p));
}Damit darf man ein myRoom Attribut nicht mehr auf blue setzen.
Egal ob myRoom als userattr oder sonstwie definiert wurde.

Und als passende zweite Frage: gibt es eine Möglichkeit für entsprechende selbst definierte Attribute einen Hilfetext für die Eingabe bereitzustellen (Stichwort POD)?

Mir ist nichts bekannt.
Wenn eine ueberwaeltigende Interesse danach besteht, kann ich aber was einbauen.

[JoWiemann]

Wenn eine ueberwaeltigende Interesse danach besteht, kann ich aber was einbauen.

Hallo Rudi,

würde mir gefallen. Manchmal nervt es schon, wenn die Hilfe separat nachgeschlagen werden muss.

Grüße Jörg

[Prof. Dr. Peter Henning]

Ich hielte es hingegen für überflüssig. "Selbst definierte Attribute" sollten sprechende Namen haben, so dass man auch noch nach 10 Jahren weiß, wofür sie gut sind.

LG

pah

[JoWiemann]

Hallo pah,

ich habe es so verstanden, dass es hier auch um Attribute geht, die von anderen Modul global in Devices zur Verfügung gestellt werden. Mich nervt es, wenn ich für die Attribute immer parallel in der commandRef nachschlagen muss. Aber vielleicht habe ich das ja auch falsch gelesen.

Grüße Jörg

[Beta-User]

Wenn eine ueberwaeltigende Interesse danach besteht, kann ich aber was einbauen.

Hmmm, ich glaube, dass das schon implementiert ist, was JoWiemann und fruemmel suchen. Siehe beigefügten screenshot - das ist ein CUL_HM-Device.

Was mir manchmal fehlt, ist eine Option, bestehenden Hilfetext in "fremden" Modulen zu ergänzen, z.B. wenn es um Funktionsaufrufe geht, die (für mich) ergänzend zu diesem Modul gehören (z.B. Valetudo-Gedöns zu MQTT2_DEVICE-readingList u.ä.). Das ist aber kein echter feature-request!

[betateilchen]

Wenn eine ueberwaeltigende Interesse danach besteht, kann ich aber was einbauen.

Von mir wenig bis kein Interesse.

[fruemmel]

Was genau schwebt dir vor?

Es gibt diverse Module, die "ihre" Attribute allgemein verteilen, und (zumindest teilweise) auch eine Syntaxprüfung machen. Vielleicht schaust du dir unter dem Gesichtspunkt v.a. RHASSPY mal an. MQTT_GENERIC_BRIDGE und AutoShuttersControl wären weitere Kandidaten, aber da bin ich wegen der Syntaxprüfung nicht sicher, ob die das auch machen...

Kannst Du mir auf die Sprünge helfen, wie in RHASSPY die Syntaxprüfung umgesetzt ist? Ich sehe in initialize_prefix, wie die Attribute über addToAttrList erstellt werden, aber wo kann bei der Nutzung eine inhaltliche Prüfung stattfinden, bzw. welche NotifyFn wird aufgerufen?

[fruemmel]

Ich hielte es hingegen für überflüssig. "Selbst definierte Attribute" sollten sprechende Namen haben, so dass man auch noch nach 10 Jahren weiß, wofür sie gut sind.

Die Namen kann man ja sprechend wählen, kein Thema. Aber mir geht es darum auch zu beschreiben, in welchem Format oder in welchem Wertebereich die Attribute bestückt werden sollen.

Womoeglich funktioniert das mit einem cmdAlias:

Code Auswählen Erweitern

define myUserAttrChecker cmdalias attr .* AS { myUserAttrChecker($EVENT) }und der Funktion myUserAttrChecker in 99_myUtils.pm in etwa so:

Code Auswählen Erweitern

sub
myUserAttrChecker($)
{
  my @p = split(" ", @_[0], 3);
  if($p[1] eq "myRoom" && $p[2] eq "blue") {
    return "this is not allowed";
  }
  return CommandAttr(undef, join(" ", @p));
}

Das funktioniert und hilft definitiv weiter. Mir war nicht bewusst, dass man mit cmdalias Standardbefehle überschreiben kann.

[Prof. Dr. Peter Henning]

Aber mir geht es darum auch zu beschreiben, in welchem Format oder in welchem Wertebereich die Attribute bestückt werden sollen.

Entweder sind diese Attribute nur für irgendein FHEM-Device (und nur für dieses) "selbst definiert" worden. Dann ist eine solche Beschreibung ganz sicher überflüssig.

Oder es sind globale User-Attribute, die von einem Modul verteilt werden. Beispiele dafür gibt es genug in meinen Modulen: 95_Babble ebenso wie 95_Alarm machen so etwas. Dann aber gehört die Beschreibung dieser Attribute zum verteilenden Modul, denn das wertet sie ja aus.

Also, gehupft wie gesprungen: Das wäre ein überflüssiges feature.

LG

pah

[fruemmel]

Oder es sind globale User-Attribute, die von einem Modul verteilt werden. Beispiele dafür gibt es genug in meinen Modulen: 95_Babble ebenso wie 95_Alarm machen so etwas. Dann aber gehört die Beschreibung dieser Attribute zum verteilenden Modul, denn das wertet sie ja aus.

Mein Fehler war es bisher, dass ich das userattr einfach in der global eingetragen habe, also nicht über ein Modul verteile. Somit kann ich Deine Sichtweise auch nachvollziehen.
Aber wenn schon ein Modul ein userattr verteilt, wäre es nicht auf wünschenswert, wenn dieses Modul den in irgendeinem Device erfassten Attribut-Wert prüfen könnte (Wertebereich, Syntax)? So wie ich es bisher verstanden habe, ist das aber im Modulcode nicht möglich.

[Beta-User]

Kannst Du mir auf die Sprünge helfen, wie in RHASSPY die Syntaxprüfung umgesetzt ist? Ich sehe in initialize_prefix, wie die Attribute über addToAttrList erstellt werden, aber wo kann bei der Nutzung eine inhaltliche Prüfung stattfinden, bzw. welche NotifyFn wird aufgerufen?

Sorry, es ist in der Tat so, dass mit dem Verteilen der Info, aus welchem Modul ein Attribut erzeugt wurde keine weitere Prüfung des gesetzten Inhalts verbunden ist.
RHASSPY reagiert auch "nur" per regulärer (in dem Fall von global getriggerten) NotifyFn() auf das Ändern von Attributen, was für eine Validierungsrückmeldung eh zu spät wäre.

Aber wenn schon ein Modul ein userattr verteilt, wäre es nicht auf wünschenswert, wenn dieses Modul den in irgendeinem Device erfassten Attribut-Wert prüfen könnte (Wertebereich, Syntax)?

Zumindest im Sinne der "logischen Vollständigkeit" ist die Frage berechtigt. Ob der Aufwand lohnt, diese Lücke zu schließen, muss Rudi entscheiden.

Meinem Bauchgefühl nach würden nicht viele Maintainer von so einer Option Gebrauch machen: schon jetzt ist die Validierung originär zu einem bestimmten Modul gehörenden Attribut-Inhalte eher die Ausnahme, und ähnliches gilt bereits für die Anzeige einer passenden Hilfe...
(Aber nur, weil das heute die Ausnahme ist, muß das ja nicht bedeuten, dass das so bleiben müßte.)

Für RHASSPY oder "RHASSPY-next" würde ich vermutlich auch keine direkte Validierung der an den "subordinated devices" gesetzen Attribute einbauen, selbst, wenn das ginge. Der User muss da mitdenken (falls er die Attribute überhaupt benötigt!) und die Auswertung am Ende selbst im list der zugehörigen RHASSPY-Instanz gegenchecken. Interessant wäre allenfalls, dass man (dafür) keine NotifyFn() benötigen würde, sich also evenutell bei allen Event-loops die Prüfung sparen könnte, ob diese aufzurufen ist. Macht in dem konkreten Fall allerdings keinen Unterschied sobald zusätzliche Optionen aktiviert sind, für die man Events an anderen Devices als global auswerten muss...

Man kann als Workaround für FHEMWEB zumindest widgets vorsehen, die z.B. bestimmte Wertebereiche vorsehen, so dass man sich zumindest in den "eindeutigen" Fällen helfen lassen kann, korrekte Attribut-Inhalte zu setzen.

PS: Vielleicht könnte dir für den konkreten Anwendungsfall "readingsWatcher" und/ oder "monitoring" weiterhelfen.