Readings komplett unterdrücken

Begonnen von DeeSPe, 18 September 2016, 22:34:37

Vorheriges Thema - Nächstes Thema

DeeSPe

Hallo,

ich habe einige Devices, hauptsächlich ZWave, die des Öfteren Readings erzeugen, die sie eigentlich gar nicht besitzen.
Bezüglich der falschen Readings gab es schon einige Anfragen.

Mal als Beispiele, erzeugen folgende Devices die Readings die überhaupt keinen Sinn ergeben:
FIBARO System FGWPE Wall Plug:
direction
luminance
temperature
velocity

FIBARO System FGMS001 Motion Sensor:
direction
generalPurpose
humidity
particulateMatter
position

Des Weiteren habe ich noch einen LaCrosse Sensor der immer ein Reading humidity (mit Wert 0) erzeugt obwohl er gar keinen Sensor dafür hat. Es ist ein reiner Temperatursensor.

Nun habe ich schon mit notify(s) probiert diese Readings automatisch löschen zu lassen, aber das klappt nicht wie gewünscht. Habe auch mit event-on-*-reading erfolglos herum probiert.

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.

Auf Grund dessen hätte ich einen Wunsch für ein neues globales Attribut, z.B. supressReadings
In diesem Attribut könnte man dann für jedes Device die Readings angeben, die bei deren Erstellung unterdrückt werden sollen, also gar nicht erst als Reading erscheinen. Speziell bei humidity und temperature werden nämlich, bedingt durch das statistics Modul, auch weitere historische Readings angelegt.

Eventuell gibt es was Ähnliches schon und ich habe es nur nicht gefunden?

Vielen Dank.

Gruß
Dan
MAINTAINER: 22_HOMEMODE, 98_Hyperion, 98_FileLogConvert, 98_serviced

Als kleine Unterstützung für meine Programmierungen könnt ihr mir gerne einen Kaffee spendieren: https://buymeacoff.ee/DeeSPe

betateilchen

Abgesehen davon, dass ich das Ansinnen ziemlich schräg finde, frage ich mich, was das in der Wunschliste für CUL zu suchen hat.
-----------------------
Formuliere die Aufgabe möglichst einfach und
setze die Lösung richtig um - dann wird es auch funktionieren.
-----------------------
Lesen gefährdet die Unwissenheit!

DeeSPe

Ich könnte Deine Aussage sicherlich besser verstehen wenn Du sie auch untermauern würdest.

Was genau ist an dem Ansinnen schräg?
Offensichtlich (zumindest so wie ich es bisher im Forum gelesen habe) ist es nicht möglich diese unkontrollierte Erstellung der Readings bei (jetzt speziell) ZWave in den Griff zu bekommen.
Auch meinen LaCrosse Sensor werde ich nicht beibringen können das Erstellen des humidity Readings einzustellen.
Da du das so schräg findest, gib mir doch einen Hinweis wie ich es selbst in den Griff bekommen könnte!  ;)

Sorry, ist mir bisher gar nicht aufgefallen dass ich das unter "CUL - Entwicklung" gepostet hatte.
Bin wohl beim Erstellen des Themas versehentlich ein Kästchen zu tief gerutscht.
Das sollte logischer Weise unter "FHEM - Entwicklung -> Wunschliste", kann man passieren...
Ich werde mal schauen ob ich berechtigt bin das Thema an die richtige Stelle zu schieben.

Gruß
Dan
MAINTAINER: 22_HOMEMODE, 98_Hyperion, 98_FileLogConvert, 98_serviced

Als kleine Unterstützung für meine Programmierungen könnt ihr mir gerne einen Kaffee spendieren: https://buymeacoff.ee/DeeSPe

betateilchen

Zitat von: DeeSPe am 21 September 2016, 15:13:28
Ich könnte Deine Aussage sicherlich besser verstehen wenn Du sie auch untermauern würdest.

Was genau ist an dem Ansinnen schräg?
Offensichtlich (zumindest so wie ich es bisher im Forum gelesen habe) ist es nicht möglich diese unkontrollierte Erstellung der Readings bei (jetzt speziell) ZWave in den Griff zu bekommen.

Die Erstellung von readings zu einem bestimmten device ist m.E. alleinige Aufgabe des Moduls, das die devices anlegt und nicht Aufgabe eines (globalen) Attributes. Die Verantwortung liegt in diesem Punkt für mich eindeutig und ausschliesslich beim Entwickler und nicht beim Anwender. (Soweit zur Frage, was ich an Deinem Ansinnen schräg finde)

Dass diese Aufgabe durchaus lösbar ist, kann man doch beispielsweise gut im Homematic Bereich sehen, wo es keine "falschen" readings gibt, weil pro devicetyp (model) eindeutig feststeht, welche readings das Gerät überhaupt erzeugt.
-----------------------
Formuliere die Aufgabe möglichst einfach und
setze die Lösung richtig um - dann wird es auch funktionieren.
-----------------------
Lesen gefährdet die Unwissenheit!

DeeSPe

Deine Ansicht verstehe ich und teile ich.

So wie ich es aber mitbekommen habe besteht entweder keine Möglichkeit oder kein wirkliches Interesse daran das entsprechend im Modul anzupassen.

Was soll ich nun Deiner Meinung nach als Anwender tun?
Mich damit abfinden oder eine Lösung versuchen herbeizuführen?
Ich sehe das hier als einen möglichen Lösungsansatz, der - zugegeben - das eigentliche Problem nicht löst, aber zumindest dessen Folgen.

Gruß
Dan
MAINTAINER: 22_HOMEMODE, 98_Hyperion, 98_FileLogConvert, 98_serviced

Als kleine Unterstützung für meine Programmierungen könnt ihr mir gerne einen Kaffee spendieren: https://buymeacoff.ee/DeeSPe

betateilchen

Ein globales Attribut, das die Erzeugung von readings reguliert, waere ein tiefgreifender Eingriff in die gesamte Logik der readings innerhalb  von fhem. Ausserdem waere auch dann nicht sichergestellt, dass das Attribut in allen Faellen greifen wuerde, da innerhalb der unterschiedlichen Module unterschiedliche Varianten zur Erzeugung von readings im Einsatz sind.

Dein "Problem" verstehe ich schon irgendwie, aber ich bleibe bei meiner Ansicht, dass es nicht Aufgabe des Anwenders sein kann, falsch angelegte readings in seiner Installation zu beseitigen. Wenn ein Modul falsche readings erzeugt, dann ist das ein Bug im Modul. Und diesen Bug hat der Entwickler zu beseitigen.
-----------------------
Formuliere die Aufgabe möglichst einfach und
setze die Lösung richtig um - dann wird es auch funktionieren.
-----------------------
Lesen gefährdet die Unwissenheit!

DeeSPe

Zitat von: betateilchen am 21 September 2016, 17:38:12Dein "Problem" verstehe ich schon irgendwie, aber ich bleibe bei meiner Ansicht, dass es nicht Aufgabe des Anwenders sein kann, falsch angelegte readings in seiner Installation zu beseitigen. Wenn ein Modul falsche readings erzeugt, dann ist das ein Bug im Modul. Und diesen Bug hat der Entwickler zu beseitigen.

Soll heißen?
Im ZWave- und LaCrosse-Bereich wieder ein "Fass" aufmachen und mich dort rund machen lassen? :o

Gruß
Dan
MAINTAINER: 22_HOMEMODE, 98_Hyperion, 98_FileLogConvert, 98_serviced

Als kleine Unterstützung für meine Programmierungen könnt ihr mir gerne einen Kaffee spendieren: https://buymeacoff.ee/DeeSPe

Ralf W.

Zitat von: DeeSPe am 21 September 2016, 17:44:21
Im ZWave- und LaCrosse-Bereich wieder ein "Fass" aufmachen und mich dort rund machen lassen? :o
Ja bitte. Ich lese dann mit  :D

Scherz beiseite. Du bist sicherlich nicht allein mit dem Problem. Ich habe hier vier Sensoren (LaCrosse und LCGW), die rain und wind.* anzeigen.

MfG
http://twitter.com/RWausD
Schon gewusst, dass Haarausfall zu einer Glatze führen kann?

FHEM: NUC7PJYH2, Ubuntu Server 22.04.2 LTS, HMCCU - RaspberryMatic, DE ConBee II, diverse Sensoren und Aktoren.

betateilchen

Wieso Fass aufmachen? Der Prozess zum Bugfixing ist doch ganz einfach und funktioniert hier im Forum eigentlich problemlos.


  • Den Entwickler darauf hinweisen, dass sein Modul Dinge tut, die nicht korrekt sind
  • Das Fehlverhalten anhand von reproduzierbaren Beispielen belegen
  • Um Abhilfe/Fehlerbeseitigung bitten
  • Etwas Geduld haben

-----------------------
Formuliere die Aufgabe möglichst einfach und
setze die Lösung richtig um - dann wird es auch funktionieren.
-----------------------
Lesen gefährdet die Unwissenheit!

FlorianZ

Mich stören die falschen readings bei Zwave auch schon länger.
So wie ich das verstanden habe, kommen diese durch eine schwache Checksumme bei Zwave zustande.Also eher kein Bug im Modul.

Gruß Florian

rudolfkoenig

Der Entwickler kann nicht immer was tun:
- Mein Stand ist, dass das ZWave Problem von falschen Daten kommt, die CheckSumme ist im Normalfall 8 Bit. Oder von einem verrueckten Firmware, passiert bei Fibaro immer wieder.
- Jeder Modulentwickler muesste eine Liste der Modelle mit allen moeglchen Readings fuehren, um sinnlose zu ignorieren. Das mag klappen fuer Systeme mit wenig Geraeten wie HM, bei anderen wie ZWave, wo viele Hersteller taeglich neue Geraete auf dem Markt werfen, ist das ein Problem.
- Diverse einfache Geraete haben das gleiche Firmware, wie der grosse Bruder, aber nicht alle Sensoren, und liefern 0-Werte. Hier ist ein automatisches Filtern nicht moeglich.
- der KM271 unterstuetzt 2 Heizkreise, ich habe aber nur eins. Trotzdem kriege ich ca 40 zusaetzliche Readings fuer Heizkreis2, muss also immer aufpassen, nicht die sinnlosen Werte abzulesen.

Alle diese Probleme koennen irgendwie vom Modulautor auch gefixt werden, aber wenn der Benutzer das einfach selbst machen kann, wieso nicht.

Ich werde bei Gelegenheit das Attribut fuer readingsBulkUpdate implementieren, d.h. die meisten neueren Module sollten davon profitieren.

DeeSPe

Zitat von: FlorianZ am 21 September 2016, 18:23:14
Mich stören die falschen readings bei Zwave auch schon länger.
So wie ich das verstanden habe, kommen diese durch eine schwache Checksumme bei Zwave zustande.Also eher kein Bug im Modul.

Gruß Florian

Ja, genau das hatte ich auch gelesen.
Es kann immer Bugs in Firmwares geben!
Ist dann die Frage ob man das dem Modulentwickler aufbürden kann etwas gegen die Bugs in das Modul einzubauen!?
Ich für meinen Teil hatte in mein Modul auch etwas eingebaut um einen vorhanden Bug möglichst zu umgehen.

Gruß
Dan

P.S. Danke Rudi für diese Fachaussage. Etwas in dieser Richtung hatte ich mir gewünscht.  :o
MAINTAINER: 22_HOMEMODE, 98_Hyperion, 98_FileLogConvert, 98_serviced

Als kleine Unterstützung für meine Programmierungen könnt ihr mir gerne einen Kaffee spendieren: https://buymeacoff.ee/DeeSPe

betateilchen

Zitat von: rudolfkoenig am 21 September 2016, 18:37:37
Ich werde bei Gelegenheit das Attribut fuer readingsBulkUpdate implementieren, d.h. die meisten neueren Module sollten davon profitieren.

Au weia...

Der readingsBulk-Mechanismus funktioniert doch schon jetzt aufgrund diverser Sonderbehandlungen und -abfragen nicht mehr zuverlaessig (siehe meinen hierzu vor einiger Zeit eroeffneten Thread). Wenn da nun noch mehr Fallunterscheidungen eingebaut werden, steht zu befuerchten, dass das Ganze irgendwann gar nicht mehr zu gebrauchen ist.

-----------------------
Formuliere die Aufgabe möglichst einfach und
setze die Lösung richtig um - dann wird es auch funktionieren.
-----------------------
Lesen gefährdet die Unwissenheit!

rudolfkoenig

Zitatsteht zu befuerchten, dass das Ganze irgendwann gar nicht mehr zu gebrauchen ist.
Ich hoffe nicht, jedenfalls nicht fuer dieses Attribut. Die Aenderung sind nur zwei Zeilen am Anfang von readingsBulkUpdate gewesen:
Zitat+  my $sp = AttrVal($name, "suppressReading", undef);
+  return if($sp && $reading =~ m/^$sp$/);
Mit Doku usw. natuerlich etwas mehr. Habs eingecheckt.

Was mir immer noch Bauchschmerzen bereitet, das sind die event-* Attribute, insb. wenn man sie miteinander kombiniert.

DeeSPe

Das ging ja schnell!
Danke Rudi!

Sehe ich richtig dass das Attribut nur einen Wert aufnimmt und keine Liste?

Gruß
Dan
MAINTAINER: 22_HOMEMODE, 98_Hyperion, 98_FileLogConvert, 98_serviced

Als kleine Unterstützung für meine Programmierungen könnt ihr mir gerne einen Kaffee spendieren: https://buymeacoff.ee/DeeSPe