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 :)