ReadingsUpdate & Co

[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.