ReadingsUpdate & Co

[rudolfkoenig]

- Stichwort stateFormat: In dem Modul-Eigenen AttrList sollte man ab jetzt die
  globale Variable readingFnAttributes eintragen, bzw. genauso in Doku-Abteil
  auf readingFnAttributes verweisen, damit nicht bei jeder globaler Aenderung
  alle Module angepasst werden muessen.

- Das o.g. habe habe in allen Modulen, die readings*Update verwenden angepasst,
  konnte es aber nicht testen: bitte testen und ggf. fixen. Das waren die Module:
  *CUL_HM.pm *CUL_MAX.pm *Calendar.pm *ECMDDevice.pm *FB_CALLMONITOR.pm *FHT.pm
  *IPCAM.pm *MAX.pm *OWDevice.pm *TRX_ELSE.pm *TRX_LIGHT.pm
  *TRX_SECURITY.pm *TRX_WEATHER.pm *Twilight.pm *WS300.pm *Weather.pm
  *YAMAHA_AVR.pm *structure.pm
  Weiss jemand eine Methode, um Syntax der Module pruefen zu koennen? Sowas wie
  "perl -c FHEM/*.pm" waere nett.

- Modul HCS ist Ausnahme: hier wird event-on-* direkt referenziert, das muesste
  vom Autor angepasst werden

- Das doTrigger Parameter (bzw. bestimmen, ob ein Reading per trigger
  versendet wird oder nicht) gehoert mAn nicht ins readingsEndUpdate
  sondern ins readingsBulkUpdate.
  - Falls bisher doTrigger 0 war, hat EndUpdate zwar kein DoTrigger ausgeloest,
    aber dieser wurde von Dispatch trotzdem ausgefuehrt, weil CHANGED nocht nicht leer war.
  - Ich habe in 10_MAX.pm das readingsEndUpdate Parameter angepasst, bitte pruefen, da
    ich es nicht testen konnte. Ich meine sonst wird es "richtig" verwendet.
  - readingsBulkUpdate hat einen optionalen Parameter (changed), falls dieser 0 ist,
    dann wird diese Reading nicht als trigger versendet.

- DoSet ruft jetzt auch die readingsUpdate Funktionen auf. Damit es nicht doppelt getriggert wird, habe ich eine spezielle Behandlung eingefuehrt, hoffentlich ohnen Nebeneffekte.

- habe in der Doku ein paar offene <li> gefixed (in den Modulen, fuer die ich
  mich mehr oder weniger zustaendig fuehle), die Pruefung in commandref_join.pl
  auch etwas gefixed, und dabei den =()= Operator kennengelernt :)
  Waere nett, wenn der Rest vom jeweiligen Modulautor uebernommen wird.

- Attribute/Hash-Eintraege/Readings die mit . Anfangen werden ab sofort vom Endanwender
  "versteckt", es sei denn das globale Attribut showInternalValues ist gesetzt.
  Solche Readings erzeugen kein event (egal wie das Attribut gesetzt ist).

- Ich habe fast alle Dateien angefasst, nicht wundern beim update.

[Dr. Boris Neubert]

Hallo Rudi,

zunächst vielen Dank für diese Anpassungen!

- Das doTrigger Parameter (bzw. bestimmen, ob ein Reading per trigger
  versendet wird oder nicht) gehoert mAn nicht ins readingsEndUpdate
  sondern ins readingsBulkUpdate.
  - Falls bisher doTrigger 0 war, hat EndUpdate zwar kein DoTrigger ausgeloest,
    aber dieser wurde von Dispatch trotzdem ausgefuehrt, weil CHANGED nocht nicht leer war.

Ich verstehe nicht, was Du schreibst. Dispatch wertet CHANGED aus und löst die Trigger aus. Wenn das ReadingsUpdate aber von einem Timer aufgerufen wird, ist dies nicht der Fall, und der Trigger muß vom aufrufenden Modul ausgelöst werden. Und zwar nach dem Ende aller Updates.

- habe in der Doku ein paar offene <li> gefixed (in den Modulen, fuer die ich
  mich mehr oder weniger zustaendig fuehle), die Pruefung in commandref_join.pl
  auch etwas gefixed, und dabei den =()= Operator kennengelernt :)
  Waere nett, wenn der Rest vom jeweiligen Modulautor uebernommen wird.

Für meine Module erledigt.



Nun gleich zum nächsten Änderungsvorschlag. In einem nebenläufigen Thread schlug ich vor, benutzerdefinierte Readings einzuführen, z.B. in der Form

Code Auswählen Erweitern

attr meinDevice userReadings vordefiniertesReading eigenesReading code, ...

Wenn vordefiniertesReading gesetzt wird, wird automatisch eigenes Reading mittels code gefüllt. Dafür kann praktisch der gleiche Code verwendet werden wie für stateFormat.

Wozu ist das gut? Damit können die Anwender die generischen Readings der generischen Devices (ECMDDevice, OWDevice, ...) durch verständliche ersetzen, ohne über Dummys und Notifys zu gehen. Ich kaue im Moment noch an der Syntax, wie man das für mehrere userReadings hinbekommt, wenn der Trenner Komma auch in code vorkommen kann.

Habt Ihr Anmerkungen zu dem Vorschlag und eine Lösung für das Parser-Problem?

Grüße
Boris

[rudolfkoenig]

> Ich verstehe nicht, was Du schreibst.

Ich sehe die Situation auch noch nicht ganz klar, vielleicht deswegen meine unverstaendliche Formulierung :)

1. Es ist flexibler, wenn man pro reading aussuchen kann, ob man dafuer auch ein event generieren will, dafuer muss BulkUpdate eine Option haben (erledigt).

2. Ich habe ein Problem beim Dispatch (gehabt): dieser ruft ParseFn auf, hier wird EndUpdate aufgerufen, der zum ersten mal DoTrigger aufruft. Danach ruft Dispatch selber auch DoTrigger auf nachdem optionale Daten wie RSSI zum CHANGED hinzugefuegt hat
-> DoTrigger wurde zweimal aufgerufen, ein Aufruf muss weg
-> wg. der Optionalen Daten muss Dispatch DoTrigger aufrufen.

EndUpdate Aufruf mit dotrigger=0 ist damit zweideutig: will ich _jetzt_ kein DoTrigger (weil das von Dispatch uebernommen wird) oder will ich gar kein event/Trigger.

Mit der aktuellen Loesung ist der $dotrigger Parameter in EndUpdate fuer ParseFn's die aus Dispatch her aufgerufen werden wirkungslos. Fuer alle anderen hat sich nichts geaendert.

$dotrigger nur im BulkUpdate zu haben waere fuer die Programmierer eindeutiger, und EndUpdate koennte (falls nicht aus Dispatch kommt) immer ein DoTrigger aufrufen (der wiederum nichts tut, falls CHANGED leer ist).

> Habt Ihr Anmerkungen zu dem Vorschlag und eine Lösung für das Parser-Problem?

Keie Einwaende, gute Loesung auch nicht. Evtl. newline als Trenner, aber dann kann man es im FHEMWEB nicht sinnvoll editieren. Hat jemand dafuer eine Loesung?
Oder das Wort userReadings selbst als Trenner :) Technisch einfach aber Kurios.

[Dr. Boris Neubert]

- Stichwort stateFormat:

wikified here: http://www.fhemwiki.de/wiki/DevelopmentGuidelines#Status


Boris

[Dr. Boris Neubert]

- Stichwort stateFormat:

Habe in fhem.pl noch einen Fix angebracht, daß STATE nicht angefaßt wird, falls es weder state-Reading noch stateFormat gibt. Jetzt zeigen dummy und Calendar wieder was in FHEMWEB an.

Grüße
Boris

[Markus Bloch]

Hallo zusammen,

mir ist soeben im Zusammenhang mit den readingFnAttributes aufgefallen, dass event-on-update-reading und event-on-change-reading nur noch die Werte 0 oder 1 annehmen können,

dabei steht in der Commandref dazu:

event-on-update-reading
If not set, every update of any reading creates an event, which e.g. is handled by notify or FileLog. The attribute takes a comma-separated list of readings. You may use regular expressions in that list. If set, only updates of the listed readings create events.

event-on-change-reading
The attribute takes a comma-separated list of readings. You may use regular expressions in that list. If set, only changes of the listed readings create events. In other words, if a reading listed here is updated with the new value identical to the old value, no event is created.[/i]

Is das so gewollt, das diese Parameter jetzt nur noch 0 oder 1 sein können? Ich schliese daraus, dass das dann eben für alle Device Readings gilt, ist das richtig?

Viele Grüße

Markus

[rudolfkoenig]

Sorry, war mein Fehler, betraf aber nur das Setzen per dropdown aus FHEMWEB.
Habs gefixed und eingecheckt.

[Markus Bloch]

Vielen Dank

[sweetie-pie]

Ist das für Geräte von model "dummy" auch implementiert?

[Dr. Boris Neubert]

Ist das für Geräte von model "dummy" auch implementiert?

Doku kaputt?

Ja, ist es.

Grüße
Boris

[justme1968]

es ist mit stateFormat in der einfachen form (ohne perl code) nicht möglich attribute die ein '.' im namen haben zu ersetzen. das problem tritt hier auf Link] und auch bei den 1-wire switches. hier gibt es mehrere readings mit .A oder .B usw. im namen. laut perl code scheinen nur buchstaben und _ und - im reading namen erlaubt. spricht etwas dagegen hier auch den '.' zu erlauben ?

[rudolfkoenig]

Ja, es stimmt, in den einfachen Form wird ein Reading mit Punkt im Namen nicht ersetzt. Wenn ich es zulasse, dann funktionieren Konstrukte wie readingA.readingB nicht mehr. Da mir das egal ist, kann ich Punkt zulassen, es sei denn, jemand hat weitere Gegenargumente.

[rudolfkoenig]

Da kein Veto gekommen ist, habe die Aenderung eingecheckt.

[justme1968]

ich bin gerade dabei für die panStamp/SWAP devices neben den readings im internen sensor spezifischen format zusätzlich readings im 'menschenlesbaren' format in den jeweils gebräuchlichen einheiten zu implementieren. da die devices in ihrem jeweiligen xml file auch die nötigen umrechnungen haben ist das eigentlich auch recht einfach möglich.

ich wollte dafür den userReadings mechanismus verwenden weil er genau diese funktionalität abdeckt. dabei gibt es aber ein problem:

die panstamp devices senden ihre readings nicht in einer einzigen nachricht sondern in mehreren. z.b. temperatur und luftdruck gemeinsam in einer und die batteriespannung in einer zweiten. aus der kombinierten nachricht mache ich zwei readings um die temperatur und druck werte getrennt zu haben. aus diesen drei readings sollen dann im nächsten schritt die drei 'menschen lesbaren' readings werden. wenn jetzt die erste nachricht verarbeitet wird und nach dem readingsEndUpdate das erzeugen der user readigns angestossen d.h. alle drei user readings werden erzeugt. direkt nach der ersten nachricht kommt die zweite für die batterie spannung und das erzeugen der user readings wird ein zweites mal für alle drei angestossen.

Code Auswählen Erweitern

2013-05-07 21:39:35 SWAP temppress 0C.0-Temperature: 02DE
2013-05-07 21:39:35 SWAP temppress 0C.1-Pressure: 00018568
2013-05-07 21:39:35 SWAP temppress voltage: 1.6
2013-05-07 21:39:35 SWAP temppress preassure: 996.88
2013-05-07 21:39:35 SWAP temppress temperature: 23.4
2013-05-07 21:39:35 SWAP temppress 0B.0-Voltage: 0648
2013-05-07 21:39:35 SWAP temppress voltage: 1.608
2013-05-07 21:39:35 SWAP temppress preassure: 996.88
2013-05-07 21:39:35 SWAP temppress temperature: 23.4
pro device nachricht alle user readings. unabhängig ob die nachricht einen einfluss darauf hat oder nicht. und für einen sensor der zusätzlich noch luftfeuchtigkeut oder hellikeit oder beides liefert wären es dann 16 oder sogar 25 events mit jeweils 12 oder 20 doppelten readings und doppelten log einträgen.

ich habe keine kombination aus event-min-intervall, event-on-change-reading und event-on-update-reading gefunden die das problem zufriedenstellend löst. entweder gehen updates verloren, updates werden erst rüchwirkend bei der nächsten nachricht erzeugt, oder gleichbleibende werte erzeugen keine log einträge und damit einen abriss des plots.

weiter oben im thread (Link) gab es schon mal den vorschlag bei jedem user reading das triggernde reading mit anzugeben. ich denke das wäre genau die richtige lösung: für jedes user reading anzugeben bei welchem device reading es erzeugt werden soll. eine andere syntax ist aber vielleicht einfacher und rückwärtskompatibel. hinter dem namen jedes einzelnen user readings die liste der readings anzugeben für das sie erzeugt werden sollen:

Code Auswählen Erweitern

attr userReadings voltage:0B.0-Voltage {hex(ReadingsVal($name, "0B.0-Voltage","0"))*0.001 }, temperature:0C.0-Temperature {hex(ReadingsVal($name, "0C.0-Temperature","0"))*0.1-50 }, preassure:0C.1-Pressure {hex(ReadingsVal($name, "0C.1-Pressure","0"))*0.01 }
eigentlich hätte das problem mit den userReadings und der event vermehrung auch an anderer stelle schon auffallen sollten. ist es aber vielleicht nur deshalb nicht weil z.b. die 1-wire devices pollen und alle readigns auf einen schlag liefern.

[rudolfkoenig]

Ich habe nichts gegen die Erweiterung, und wenn Boris (userReadings stammt von ihm) keine Einwaende hat, dann wuerde ich es auch einchecken.

Was mit auffaellt:
- z.Zt. erlaubt userReadings nur Namen, die \w+ matchen (also kein Minus, Punkt, etc).
- userReadings ist ein Shortcut fuer EndUserReadings :), d.h. wenn man als Modulautor die Moeglichkeit hat die Aufgabe im Modul zu erledigen, dann sollte man es auch da tun.
- getestete Patches sind willkommen :)

[justme1968]

- das ist mir auch aufgefallen. ich habe aber kein problem damit (die readings mit den minus und punkt waren originale vom device). man könnte aber auch die gleichen zeichen erlauben wie in normalen readings.
- ja ich weiss. und ich bin ähnlicher meinung wie beim devStateIcon. wenn ich als modul autor dem anwender sinnvolle default werte zeigen kann und nicht funktionalität die es in fhem gibt duplizieren muss finde ich es schön etwas wieder zu verwenden.
- anbei ein patch wie ich es mir vorstellen würde. schon ein wenig getestet :)  edit: inzwischen schon mehr getestet. bei mir funktioniert es einwandfrei.

- ich würde gerne unabhängig von der trigger sache noch einen neuen modifier implementieren. 'increment' oder 'offset' um einen monoton wachsenden offset zu realisieren den man z.b. verwenden kann um das zurücksetzen eines (1-wire) zählers bei stromausfall abzufangen.

[Dr. Boris Neubert]

- das ist mir auch aufgefallen. ich habe aber kein problem damit (die readings mit den minus und punkt waren originale vom device). man könnte aber auch die gleichen zeichen erlauben wie in normalen readings.

Was immer mit den UserReadings an Erweiterungen passiert: es sollte abwärtskompatibel bleiben.

Da wir keinen Parser haben, wird das Attribut mit einem komplexen Regex rekursiv auseinandergenommen. Bei der Erweiterung des Zeichenumfangs für die Bezeichnung der Readings bitte vorher in Ruhe darüber nachdenken, ob das dann immer noch funktioniert und nachher gut testen.

- ja ich weiss. und ich bin ähnlicher meinung wie beim devStateIcon. wenn ich als modul autor dem anwender sinnvolle default
werte zeigen kann und nicht funktionalität die es in fhem gibt duplizieren muss finde ich es schön etwas wieder zu verwenden.

Ich weiß nicht, was Du damit meinst. M.E. gibt es bei userReadings nichts wiederzuverwenden. Ich sähe es lieber, wenn die Modulautoren die Readings selbst programmieren. Das reduziert die Abhängigkeiten und verhindert unerwünschte Nebeneffekte bei Änderungen. Keep it simple.

Ich kann mich aus Zeitgründen im Moment nicht mit fhem-Entwicklung befassen, bin aber nicht gegen gute Erweiterungen, die andere an den von mir eingebrachten Code machen.

Viele Grüße
Boris

[justme1968]

Was immer mit den UserReadings an Erweiterungen passiert: es sollte abwärtskompatibel bleiben.

Da wir keinen Parser haben, wird das Attribut mit einem komplexen Regex rekursiv auseinandergenommen. Bei der Erweiterung des Zeichenumfangs für die Bezeichnung der Readings bitte vorher in Ruhe darüber nachdenken, ob das dann immer noch funktioniert und nachher gut testen.

der aktuelle patch aendert noch nichts am zeichenumfang. er erlaubt nur nach dem namen des userereadings einen trigger mit doppelpunkt anzuhängen. ich denke es ist abwärts kompatibel gelöst. ich habe es bei mir so gut getestet wie es geht.

diesen trigger mechanismus einzubauen ist meiner meinung nach auf jeden fall richtig. ohne ihn werden die user readings mehrfach ausgewertet und das führt zu mehrfachen log und db einträgen sobald ein device mehr als ein event erzeugt. die idee dazu und ist ja auch weiter oben im thread wärend der ursprünglichen user readings idee schon aufgetaucht.

was die erweiterung des zeichenumfangs angeht: ich glaube wäre unkritischer zu implementieren als es scheint. die leerzeichen zwischen dein einzelnen schlüßelworten sind eindeutig genug um den ausdruck auch dann noch zu zerlegen.

Ich weiß nicht, was Du damit meinst. M.E. gibt es bei userReadings nichts wiederzuverwenden. Ich sähe es lieber, wenn die Modulautoren die Readings selbst programmieren. Das reduziert die Abhängigkeiten und verhindert unerwünschte Nebeneffekte bei Änderungen. Keep it simple.

ich weiss nicht warum es einfacher sein soll dinge doppelt zu implementieren wenn es einen mechanismus gibt der jetzt schon vorhanden ist und funktioniert. in diesem fall aus einem reading über eine konfigurierbare weg ein anderes zu erzeugen.

für die panstamps auf die user readings zurueck zu greifen ist im ersten schritt tatsächlich der einfachste weg weil ich damit aus den 'maschinen lesbaren' readings per konfigurierbarem weg ein 'menschen lesbares' machen kann und der anwender kann es auch noch anpassen.

ob es die entgültige lösung sein wird weiss ich nicht. selbst wenn ich im modul einen besseren weg finde damit umzugehen ist der vorgeschlagene trigger patch davon eigentlich unabhängig. sobald ein anwender die user readgins verwendet würde er auf der gleiche problem stoßen.

gruss
  andre

[rudolfkoenig]

> ich weiss nicht warum es einfacher sein soll dinge doppelt zu implementieren wenn es einen mechanismus gibt der jetzt schon vorhanden ist und funktioniert.

Damit der normale Benutzer nicht _gezwungen_ ist perl code zu sehen.

Um etwas zu uebertrieben, man koennte nach diesem Prinzip auch sagen: es ist alles in dem Modul hartkodiert, der Benutzer muss es nur nehmen und es nach seinem Beduerfnissen modifizieren. Wenn ich sehe, was die meisten Anfaenger mit perl veranstalten, dann will ich das soweit _sinnvoll moeglich_ einschraenken. Es bleibt eine Gratwanderung zwischen Flexibilitaet und Benutzer-Abschrecken: FHEM ist nur was fuer Bastler und Linux-Freaks.

Apropos Patch (der mAn fuer userReadings wirklich sinnvoll ist):
- Doku fehlt :)
- Wg. dem \S wird das hypothetische userReading 0B.0-Voltage jetzt in Name 0B und trigger .0-Voltage getrennt, ich finde das ist zu verwirrend, und man sollte : erwarten.
- warum werden Events ohne expliziten Wert (also on/off) ignoriert?
- ich haette die Pruefung als

Code Auswählen Erweitern

my @fnd = grep { $_ && $_ =~ m/^$trigger/ } @{$hash->{CHANGED}};
$triggered = @fnd;
geschrieben, ohne Test liege ich aber vlt. komplett daneben.

[justme1968]

ich schlage vor wir trennen die diskussion in einen teil mit dem trigger patch und den teil ob es vernünftig ist die userReadings per default zu füllen. beides ist ja unabhängig voneinander.

- die doku fehlt weil ich noch keine rückmeldung bekommen habe ob die syntax mit dem doppelpunkt ok ist und ich nicht zwei mal schreiben wollte :)
- wie oben schon kurz geschrieben habe ich den zeichenumfang für die userreadings nicht geändert. d.h. es ist immer noch nur \w+. das 0B.0-Voltage ist kein user reading sondern ein 'echtes' reading vom device. das zugehörige user reading ist temperature. also userreading:reading wäre temperature:0B.0-Voltage und das matched korrekt. das problem ist also eigentlich nicht das der name eines user readings fälschlicherweise zerhackt wird sondern das der doppelpunkt nicht eindeutig als trennzeichen dort steht. ich hatte auf die schnelle nicht gefunden welche zeichen wirklich für die normalen readings erlaubt sind. statt (\S) muss es also ein doppelpunkt gefolgt von den zeichen eines normalen readings sein. etwa eher so: (:\S*)?
- das ist in meiner version hier schon geändert. das war ein versehen.
- der eine grund für die schleife zum prüfen ist auch wieder das state reading. das event für das state reading hat keinen event namen und muss immer gesondert behandelt werden wenn man es möglich sein soll es auch als trigger zu verwenden. die sonderbehandlung war in dem ersten patch noch nicht drin. nur die vorbereitung das in der schleife noch mit zu machen. der zweite grund ist das ich mehr als einen trigger erlauben möchte. das geht nur wenn jeder einzelne verglichen wird.

[justme1968]

hier die aktuelle version des patches. inklusive doku :)

[rudolfkoenig]

Eingecheckt mit vielen abers:
- zum filtern habe ich meine vorherige Version genommen: ist kuerzer und flexibler (regexp statt Festwert)
- state funktionert mit deine Schleife auch nicht, mann kann an dieser Stelle state gar nicht mehr erkennen, weil das Wert des state Readings beliebigen Format aufnehmen kann (z.Bsp. T: 20.1 H: 30), und "state" als Name nicht mehr vorhanden ist.
- ich war geneigt das state Reading mit dem Namen zusaetzlich als event freizugeben, ich fuerchte aber um die Folgen. Immerhin wuerde es dieses Problem loesen, und auch die state Zeile wuerde dann in FHEMWEB-Detail-Ansicht bei longpoll aktualisieren. Ist mir aber noch zu wenig Vorteil fuer die doppelten Daten, bzw. die dadurch evtl. verursachten doppelten notify/FileLog Aufrufe.
- die deutsche Version der Doku war nicht sehr ueberzeugend (== war auf englisch), ich habe jetzt den kompletten Abschnitt uebersetzt.

[justme1968]

danke. mit nur einem aber und zwei anmerkungen:

- ich denke die regex beim grep sollte von zeilen anfang bis zum doppelpunkt gehen (m/^$trigger:/). sonst ist es zu unscharf und es würde z.b. der trigger 'counters' bei 'counters.A' und 'counters.B' triggern. und das soll er ja eben nicht.

- mit der filter und schleifen änderung ist es nicht mehr möglich mehr als einen trigger zu definieren. also ein userReading von mehr als einem echten reading abhängen zu lassen.
- mit dem state hat du leider recht.

[rudolfkoenig]

> ich denke die regex beim grep sollte von zeilen anfang bis zum doppelpunkt gehen (m/^$trigger:/).

Dann muesste der Benutzer aber den trigger immer mit .* abschliessen.
Wenn man darauf besteht, dann muss man jetzt selbst das ^$ hinschreiben.

> mit der filter und schleifen änderung ist es nicht mehr möglich mehr als einen trigger zu definieren

Ich meine das geht mit:
attr dev userReadings myReading:trigger1|trigger2|trigger3|... { perl code }

[justme1968]

> ich denke die regex beim grep sollte von zeilen anfang bis zum doppelpunkt gehen (m/^$trigger:/).

Dann muesste der Benutzer aber den trigger immer mit .* abschliessen.
Wenn man darauf besteht, dann muss man jetzt selbst das ^$ hinschreiben.

> mit der filter und schleifen änderung ist es nicht mehr möglich mehr als einen trigger zu definieren

Ich meine das geht mit:
attr dev userReadings myReading:trigger1|trigger2|trigger3|... { perl code }

ich war gedankklich noch bei meiner version mit den expliziten doppelpunkten und hatte deine geänderte doku nicht gelesen. da steht das der trigger als regexp verwendet wird. damit hast du natürlich recht.