event für attribut enable/disable

[herrmannj]

Hallo,

Anstoß war http://forum.fhem.de/index.php/topic,23655.0.html

Aufgabe: ein button im webfrontend um Automatismen zu de- oder aktivieren. Gelöst durch setzen des Attributes "disable" . Passt.

Problem: das setzen oder löschen des Attributes löst kein event aus, andere Clients (deren Webif) bekommen also davon nichts mit und zeigen die Änderung erst nach pagerefresh.

Ich würde mich sehr dafür aussprechen dem disable (und nur dem) ein eigenes Event zu spendieren. Generell alle Attribute so zu behandeln sehe ich nicht als notwendig an, vielleicht gibt es da andere Meinungen.

Einen patch kann ich gern erstellen.

vg
jörg

[rudolfkoenig]

Ich bin der Ansicht, dass wenn Attributaenderungen Events ausloesen, dann muss das fuer alle gelten.

Ich wuerde folgende Events ausloesen:

global ATTR devicename attrname attrval
global DELETEATTR devicename attrname attrval

Natuerlich nur, wenn diese Attribute ueber CommandAttr / CommandDeleteattr geaendert werden.
Einwaende? Kennt jemand Module, die Attribute haeufig aendern?

[herrmannj]

Ja das ist konsequent.

Nach einer Nacht drüber schlafen meine ich auch das für "at" und "notify" ein Reading mit Set und get für den user einfacher zu greifen wären. Vielleicht so: "Set at disabled on / 1". Da wären Events ja direkt inklusive

Das schließt die die Events auf Attribute nicht aus.

Ein Modul welches häufig Attribute ändert kenne ich nicht.

Vg
Jörg

[ntruchsess]

keine Einwände, wäre für GUIs ein sehr nützliches Feature. Die Events sollten auch beim hochfahren von FHEM ausgelöst werden, dann könnte ein GUI die aktuelle Konfiguration automatisch übermittelt bekommen.

[rudolfkoenig]

Code Auswählen Erweitern

Die Events sollten auch beim hochfahren von FHEM ausgelöst werden
Das wird natuerlich nicht gemacht, global DEFINE Events gibts ja waehrend des Hochfahrens auch nicht.

Code Auswählen Erweitern

dann könnte ein GUI die aktuelle Konfiguration automatisch übermittelt bekommen.
Da sehe technische Probleme (das war eine Untertreibung), da ein Frontend beim Hochfahren noch nicht mit FHEM verbunden ist. Und eine Event-Historie haben wir nicht. Oder ich habe was uebersehen.
Ein Frontend soll nach dem Verbinden mit FHEM die komplette Definition samt Attribute und Status abholen.

[betateilchen]

Ich bin der Ansicht, dass wenn Attributaenderungen Events ausloesen, dann muss das fuer alle gelten.

Ich bin der Ansicht, Attributänderungen sollten niemals einen event auslösen, sondern events sollten readings und triggern (wie INITIALIZED etc) vorbehalten bleiben.

[rudolfkoenig]

Begruendung?

Ich moechte ermoeglichen, dass Frontends, die auch Attributaenderungen (room/icon/etc) mitkriegen wollen, nicht pollen muessen.
Nachteile sehe ich wenige, da mWn Attribute nicht haeufig geaendert werden und die Events werden ueber global gesendet, d.h. viele Notifies kriegen es gar nicht mit.

[ntruchsess]

Code Auswählen Erweitern

Die Events sollten auch beim hochfahren von FHEM ausgelöst werden
Das wird natuerlich nicht gemacht, global DEFINE Events gibts ja waehrend des Hochfahrens auch nicht.

Wo wäre denn das prinzipielle Problem? Erst alle CommandDefs abarbeiten, anschließend alle CommandAttr. Dann kann ein Modul ohne weiteres alle Attribut-events schon beim Hochfahren einsammeln. Du hast natürlich recht - zwingend notwendig ist das nicht, man kann die Attributwerte ja auch nach dem Global initialized-event auslesen (auch wenn man damit nicht notwendigerweise zum gleichen Ergebnis kommt).

Code Auswählen Erweitern

dann könnte ein GUI die aktuelle Konfiguration automatisch übermittelt bekommen.
Da sehe technische Probleme (das war eine Untertreibung), da ein Frontend beim Hochfahren noch nicht mit FHEM verbunden ist. Und eine Event-Historie haben wir nicht. Oder ich habe was uebersehen.

Ein externes Frontend wird sich typischerweise nicht mit FHEM beenden, sondern weiterlaufen. Ich denke da z.B. an alles, was man über mqtt anbinden kann. Eine globale Event-historie braucht man nicht, das kann (und sollte) ein Modul, das zwischen FHEM-events und dem angebundenen GUI mediiert selber machen.

[betateilchen]

Begruendung?

Weil ich zum Beispiel der Meinung bin, dass bereits jetzt viel zu viele (vermeidbare, da überflüssige) events erzeugt werden. Und bei 300 devices alle noch mit den readingsFnAttr zu verwalten, ist schon eine Sysiphos-Arbeit. Wenn dann die gleiche Arbeit auch noch für die Attribute hinzukommt, wird das noch aufwändiger.

Ergänzungsvorschlag: Events für attribute global abschaltbar machen.

[rudolfkoenig]

@ntruchsess: dann bleiben wir beim Verhalten, was auch beim DEFINE ueblich ist. Bei einem Restart koennen auch neue Definitionen hinzukommen, das verbundene System muss also die komplette Struktur sowieso lesen. Ist auch effizienter als mehrere 100 Define bzw. Attribute-Events zu bekommen.

@betateilchen: Ich verstehe deine Argumentation nicht. Wer auch immer diese Events auswertet, muss sie selbst filtern, falls sie stoeren. Es sind nur 2 neue (global ATTR und DELETEATTR), die relativ selten auftreten, genau wie die anderen global DEFINED, DELETED, RENAMED usw. readingFnAttr hilft hier nicht, da es keine Reading-Updates sind. Abschaltbar zu haben stoert, da Entwickler sich dann nicht auf die Events verlassen koennen. Insb. wenn Module A es an, und Modul B es aus haben will.

[betateilchen]

Abschaltbar zu haben stoert, da Entwickler

Denkt eigentlich irgendwann auch mal jemand an die Anwender? Als Anwender will ich keine attributbezogenen events haben.

[justme1968]

ich schon.

und zwar auch als anwender.

[rudolfkoenig]

@betateilchen, ich rate mal:du protokollierst prinzipiell alle events in der DB und du willst diese Events da nicht sehen. Ich vermute, dass es nicht so viele sind, dass es wirklich stoert, weil niemand Attribute regelmaessig automatisch setzt (deswegen die Frage am Anfang). Weiterhin sind sie mit den anderen global Events (DEFINE, etc) doch in guter Gesellschaft. Und wenn es stoert, kann man das bestimmt in DbLog ausfiltern.

[betateilchen]

@betateilchen, ich rate mal:du protokollierst prinzipiell alle events in der DB

Falsch geraten. Ich logge in DbLog nur das, was ich auch wirklich haben möchte.

[rudolfkoenig]

Ich habe folgende globale Events eingefuehrt: ATTR, DELETEATTR, MODIFIED.