Readings komplett unterdrücken

[justme1968]

wäre es nicht besser wenn das attribut der gleichen syntax folgt wie die die event-.* attribute? d.h. komma separierte liste von regex?

die event-.* attribute sollten doch inzwischen eigentlich so funktionieren wie sie beschrieben sind und das problem eher sein das es eine weile braucht bis die beschreibung klar ist. u.a. weil die namen nicht intuitiv sind.

die einzige baustelle sehe ich in der interaktion mit dem event agregator. bzw. in der fehlenden beschreibung das sich beides ausschliesst.

[rudolfkoenig]

@DeeSPe: Regexp halt.
@justme1968: das mit der Liste verstehe ich nicht. Waere aufwendiger zu programmieren, und so viel verstaendlicher ist es auch nicht.

[DeeSPe]

wäre es nicht besser wenn das attribut der gleichen syntax folgt wie die die event-.* attribute? d.h. komma separierte liste von regex?

So war meine eigentliche Idee. Deswegen hatte ich es auch als suppressReadings vorgeschlagen.
Ich hätte keine Probleme damit einen Regex zu verwenden, aber der normale User würde sicher eine Liste erwarten so wie Andre schreibt (denke ich).

Gruß
Dan

[peterk_de]

die event-.* attribute sollten doch inzwischen eigentlich so funktionieren wie sie beschrieben sind

Zumindest event-on-change reading tut das nicht. Wenn dessen Regex nicht matcht, kommen bei Änderungen des Readings keine Events (so soll es auch sein). Wird ein Reading, für dass der Regex ebenfalls nicht matcht, jedoch neu angelegt (also per definition auch geändert) dann kommt ein event. Nervt seit ewig bei einigen Modulen, die Readings beim Update löschen und neu anlegen.

[justme1968]

bei den anderen attributen ist es eine liste von regex. da die reading namen aber meist so unterschiedlich ist wird praktisch fast immer entweder nur .* verwendet um alles zu erschlagen oder eine liste von readings mit komma getrennt. der code wäre drei zeilen länger aber konsistent.

@peterk_de: das ist aber doch genau das beschriebene verhalten. alle readings die matchen erzeugen bei change ein event, alle readings die nicht matchen erzeugen kein event mehr. ausser man hat zusätzlich event on update reading gesetzt und das reading matched hier.

das neue readings ein event erzeugen wenn es sie noch nicht gab und event-on-change nicht matched sollte eigentlich mit dem patch von hier: https://forum.fhem.de/index.php/topic,52483.msg443743.html#msg443743 behoben sein. wenn es matched wird das event erzeugt:

Code Auswählen Erweitern

define test dummy
attr test event-on-change-reading A
inform timer test
setreading test A 123
2016-09-21 22:47:32 dummy test A: 123
setreading test B 123ist das bei dir anders?

[herrmannj]

ach herrjeh... das kostet doch alles Rechenzeit in der event loop und schafft gute Quellen zur Fehlbedienung (a la event-on..).

Das müsste doch in den Module gefixt werden welche die readings erzeugen (dort unterdrücken) oder das modul was dahinter hängt (homebridge).

vg
joerg

[justme1968]

was hat denn homebridge damit zu tun?

[herrmannj]

Hintergrund ist der, dass für einige dieser falschen Readings beim Neustart vom HomeBridge automatisch entsprechende Charakteristics erzeugt werden und diese dann auch in HomeKit angezeigt werden, obwohl die Devices gar nicht über diese Readings verfügen. Es nervt einfach jedes Mal diese Readings wieder händisch zu löschen bzw. die falschen Characteristics wieder auszublenden. Wenn man Pech hat wurde das Reading kurz nach seinem Löschen wieder erzeugt und ist somit beim Neustart von HomeBridge wieder da.

[justme1968]

achso...

in homebridge kann mann natürlich nicht gewünschte characteristics weg konfigurieren. homebridge geht aber per default erst mal davon aus das readings die da sind auch richtig und gewünscht sind. und das ist auch sinnvoll so. falsche readings sind sehr viel seltener als als die anwender die sonst mühsam jedes reading hin konfigurieren müssten.

falsche readings müssen so früh wie möglich verhindert werden. wenn das durch mangelhafte checksummen nicht möglich ist bleibt nur beim erzeugen.

[DeeSPe]

achso...

in homebridge kann mann natürlich nicht gewünschte characteristics weg konfigurieren. homebridge geht aber per default erst mal davon aus das readings die da sind auch richtig und gewünscht sind. und das ist auch sinnvoll so. falsche readings sind sehr viel seltener als als die anwender die sonst mühsam jedes reading hin konfigurieren müssten.

falsche readings müssen so früh wie möglich verhindert werden. wenn das durch mangelhafte checksummen nicht möglich ist bleibt nur beim erzeugen.

Das sehe ich genau so.

Gruß
Dan

[DeeSPe]

Hab heute mal das neue Attribut getestet und leider funktioniert es, speziell bei den Fibaro Motion Sensoren, so nicht. Die Readings werden trotzdem angelegt. Würde tippen dass es an readingsBulkUpdate liegt und diese Readings vermutlich per readingsSingleUpdate angelegt/aktualisiert werden.

Gruß
Dan

EDIT: humidity wurde z.B. wieder angelegt.

[Benni]

Würde tippen dass es an readingsBulkUpdate liegt und diese Readings vermutlich per readingsSingleUpdate angelegt/aktualisiert werden.

Ich bin auch der Meinung, dass das Attribut auch bei readingsSingleUpdate greifen sollte. Sonst hat, v.a. der Anwender, dem Attribute ja eigentlich gehören , ein inkonsistentes Verhalten, dass er gar nicht nachvollziehen kann.


Tut es! (s. nachfolgener Post von Rudi)

[rudolfkoenig]

Erstens: readingsSingleUpdate ruft readingsBulkupdate auf.
Zweitens: die ueberwiegende Menge der Readings (insb. die, die Checksum-Gefaehrdet sind) wird in ZWave per readingBulkUpdate angelegt.
Drittens: es kommt mir sehr komisch vor, dass man _so viele_ ZWave CheckSum Fehler hat, ich konnte bei mir bisher keine beobachten. Kannst du bitte deswegen im ZWave Bereich eine Diskussion anlegen, und da ein log mit gesetzten Z"attr ZWDongle verbose 5" anhaengen?

[betateilchen]

Sonst hat, v.a. der Anwender, dem Attribute ja eigentlich gehören, ein inkonsistentes Verhalten,

warum soll es dem Anwender besser gehen wie mir als Entwickler? Ich musste vor einiger Zeit zwei meiner Module komplett von readingsBulkUpdate() auf readingsSingleUpdate() umbauen, nur damit wieder alle events so erzeugt werden, wie es sein soll.

[rudolfkoenig]

Kannst du bitte erklaeren, warum? readingsSingleUpdate ist weniger effizient, und ich will keinen Grund (ausser Bequemlichkeit) geben, es zu verwenden.