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
Abgesehen davon, dass ich das Ansinnen ziemlich schräg finde, frage ich mich, was das in der Wunschliste für CUL zu suchen hat.
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
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.
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
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.
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
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
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
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
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.
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
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.
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.
Das ging ja schnell!
Danke Rudi!
Sehe ich richtig dass das Attribut nur einen Wert aufnimmt und keine Liste?
Gruß
Dan
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.
@DeeSPe: Regexp halt.
@justme1968: das mit der Liste verstehe ich nicht. Waere aufwendiger zu programmieren, und so viel verstaendlicher ist es auch nicht.
Zitat von: justme1968 am 21 September 2016, 21:42:16
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
Zitat von: justme1968 am 21 September 2016, 21:42:16
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.
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 (https://forum.fhem.de/index.php/topic,52483.msg443743.html#msg443743) behoben sein. wenn es matched wird das event erzeugt: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?
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
was hat denn homebridge damit zu tun?
ZitatHintergrund 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.
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.
Zitat von: justme1968 am 21 September 2016, 23:15:24
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
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.
Zitat von: DeeSPe am 22 September 2016, 22:26:44
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)
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?
Zitat von: Benni am 23 September 2016, 06:07:58
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.
Kannst du bitte erklaeren, warum? readingsSingleUpdate ist weniger effizient, und ich will keinen Grund (ausser Bequemlichkeit) geben, es zu verwenden.
Zitat von: betateilchen am 23 September 2016, 15:30:58
warum soll es dem Anwender besser gehen wie mir als Entwickler?
Weil der Anwender eben nur Anwender ist und man von ihm nicht das tiefer gehende Hintergrundwissen eines Entwicklers verlangen kann.
Gruß
Dan
Und da ich nur Anwender bin, habe ich gleich eine Frage dazu ;D
Ich habe einen ZWave Sensor, der als Reading tankCapacity hat, was es aber nicht gibt.
Jetzt habe ich einfach attr suppressReading tankCapacity gemacht und jetzt?
Kann ich jetzt das reading löschen und es kommt auch nicht mehr?
Zitat von: Mitch am 23 September 2016, 16:30:13
Und da ich nur Anwender bin, habe ich gleich eine Frage dazu ;D
Ich habe einen ZWave Sensor, der als Reading tankCapacity hat, was es aber nicht gibt.
Jetzt habe ich einfach attr suppressReading tankCapacity gemacht und jetzt?
Kann ich jetzt das reading löschen und es kommt auch nicht mehr?
So ist es eigentlich gedacht, ja.
Leider klappt das, zumindest bei mir, so noch nicht mit allen Readings des Fibaro Motion Sensors.
Gruß
Dan
Zitat von: Mitch am 23 September 2016, 16:30:13
Jetzt habe ich einfach attr suppressReading tankCapacity gemacht und jetzt?
Nix und jetzt! Das funktioniert nicht, und sollte, zumindest wenn du's im FHEMWEB in der Eingabezeile zur Ausführung bringst auch eine sachdienliche Fehlermeldung erzeugen! Da fehlt zumindest mal das Device.
Ansonsten ja! Das Reading kann/muss(?) dann noch manuell gelöscht werden, es wird ja, wenn ich es richtig verstanden habe nur die Erzeugung verhindert.
Ist schon klar, habe das natürlich richtig mit Device gemacht
Hab heute auch mal wieder erfolglos ein Wenig mit dem Attribut herumprobiert.
Internals:
DEF 21
IODev JeeLink1
JeeLink1_MSGCNT 402
JeeLink1_RAWMSG OK 9 33 1 3 26 106
JeeLink1_TIME 2016-10-03 14:14:50
LASTInputDev JeeLink1
LaCrosse_lastRcv 2016-10-03 14:14:50
MSGCNT 402
NAME ku_Sensor_TK
NR 294
STATE T: -20.2
TYPE LaCrosse
addr 21
battery_new 0
corr1 0
corr2 0
previousH 106
previousT -20.5
sensorType 0=T(H)
Readings:
2016-09-16 18:34:50 H 0
2016-09-16 18:43:51 T 0
2016-10-03 14:14:50 battery ok
2016-10-03 13:35:11 humidity 0
2016-09-22 21:59:08 statBattery Hour: 0 Day: 0 Month: 0 Year: 0 (since: 2016-09-12 )
2016-09-22 20:59:55 statBatteryLast Hour: 0 Day: 0 Month: - Year: -
2016-09-22 21:59:08 statTemperatureDay Min: 26.3 Avg: 28.1 Max: 29.9
2016-09-21 23:59:55 statTemperatureDayLast Min: 27.4 Avg: 29.8 Max: 31.3
2016-09-22 21:59:08 statTemperatureMonth Min: 21.3 Avg: 29.8 Max: 35.9 (since: 2016-09-11_14:56:42 )
2016-09-22 21:59:08 statTemperatureYear Min: 21.3 Avg: 29.8 Max: 35.9 (since: 2016-09-11_14:56:42 )
2016-10-03 14:14:50 state T: -20.2
2016-10-03 14:14:50 temperature -20.2
Attributes:
IODev JeeLink1
alias Sensor Tiefkühler
doAverage 1
event-on-update-reading state,temperature
group Sensoren
icon temp_temperature
room Anwesenheit,Küche,LaCrosse
suppressReading humidity
Hier wurde humidity um 13:35:11 wieder erstellt.
Ebenso hier humidity um 13:54:13 + zugehörige stats Readings:
Internals:
DEF ee3970ea 21
IODev ZWaveBridge
LASTInputDev ZWaveBridge
MSGCNT 169
NAME bz_Sensor
NR 150
STATE closed
TYPE ZWave
ZWaveBridge_MSGCNT 169
ZWaveBridge_RAWMSG 00041015063105030a004d
ZWaveBridge_TIME 2016-10-03 14:04:39
ZWaveSubDevice no
homeId ee3970ea
isWakeUp 1
lastMsgSent 1475495348.32158
nodeIdHex 15
Readings:
2016-10-03 08:49:50 SEND_DATA failed:00
2016-09-30 09:34:46 UNKNOWN multilevel type 43 fl: 0a arg: 001b
2016-10-02 18:37:46 UNPARSED SENSOR_BINARY 063005012200d6
2016-10-02 12:54:02 alarm_type_00 level 255 node 21 seconds 0
2016-04-22 10:38:29 alarm_type_01 level 22
2016-03-30 23:12:25 alarm_type_03 level 0a
2016-03-26 19:32:45 assocGroup_1 Max 5 Nodes
2016-03-26 19:32:45 assocGroup_2 Max 5 Nodes
2016-03-26 19:32:45 assocGroup_3 Max 1 Nodes ZWaveBridge
2016-03-26 19:33:08 assocGroups 3
2016-04-29 11:04:52 basicReport 00
2016-03-26 19:30:40 basicSet ff
2016-10-03 13:19:13 battery 100 %
2016-09-02 08:50:38 cmdGet wakeupInterval
2016-08-29 08:19:07 cmdSet wakeupInterval
2016-05-29 13:09:45 configAmbientIlluminationLevelAbove83 1000
2016-05-29 13:54:38 configAmbientIlluminationLevelBelow82 100
2016-06-30 12:30:36 configBASICOFFCommandFrameValue 0
2016-06-30 12:30:36 configBASICONCommandFrameValue 255
2016-06-30 12:30:36 configBasicCommandClassFrames12 BASICONAndBASICOFFCommandFrames0
2016-06-30 12:30:36 configIlluminationReportThreshold 200
2016-06-30 12:30:36 configIlluminationReportsInterval 900
2016-06-30 12:30:37 configIntervalOfTemperatureMeasuring 900
2016-06-30 12:30:37 configLEDBrightness 0
2016-06-30 12:30:37 configLEDIndicatingTamperAlarm LEDIndicatesTamperAlarm
2016-06-30 12:30:37 configLEDSignalingMode LongBlinkThenShortBlinkLEDColour10
2016-06-30 12:30:37 configMaximumTemperatureResultingInRed87 28
2016-06-30 12:30:37 configMinimumTemperatureResultingIn86 18
2016-06-30 12:30:38 configMotionAlarmCancellationDelay 30
2016-06-30 12:30:38 configMotionSensorSBlindTime2 15
2016-06-30 12:30:38 configMotionSensorSSensitivity 15
2016-06-30 12:30:38 configNightDay 200
2016-06-30 12:30:38 configPIRSensorOperatingMode PIRSensorAlwaysActive
2016-06-30 12:30:39 configPIRSensorSPulseCounter 1Pulse
2016-06-30 12:30:39 configPIRSensorSWindowTime 12Seconds
2016-06-30 12:30:39 configTamperAlarmBroadcastMode TamperAlarmIsNotSentInBroadcast0
2016-06-30 12:30:39 configTamperAlarmCancellationDelay 30
2016-06-30 12:30:39 configTamperOperatingModes Tamper
2016-06-30 12:30:39 configTamperSensitivity 15
2016-06-30 12:30:40 configTemperatureOffset 0
2016-06-30 12:30:40 configTemperatureReportThreshold 10
2016-06-30 12:30:40 configTemperatureReportsInterval 900
2016-10-03 13:54:13 humidity 0
2016-10-03 14:04:39 luminance 77 Lux
2016-03-26 19:34:51 mcaSupportedGroupings 2
2016-04-11 19:35:17 model FIBARO System FGMS001 Motion Sensor
2016-04-11 19:35:17 modelConfig fibaro/fgms.xml
2016-04-11 19:35:17 modelId 010f-0800-1001
2016-06-06 00:31:52 neighborList ku_Licht3 ku_SD2 ku_SD3 ku_SD4 bz_SD1
2016-10-03 10:56:20 reportedState closed
2016-10-03 14:04:39 statBattery Hour: 0 Day: 0 Month: 0 Year: 0 (since: 2016-06-04 )
2016-10-03 13:59:55 statBatteryLast Hour: 0 Day: 0 Month: 0 Year: -
2016-10-03 14:04:39 statHumidityDay Min: 0 Avg: 0 Max: 0
2016-10-03 14:04:39 statHumidityMonth Min: 0 Avg: 0 Max: 0
2016-10-03 14:04:39 statHumidityYear Min: 0 Avg: 0 Max: 0 (since: )
2016-10-03 14:04:39 statLuminance Hour: 2.0000 Day: 77.0000 Month: 77.0000 Year: 77.0000 (since: )
2016-10-03 13:59:55 statLuminanceLast Hour: 10.0000 Day: 0.0000 Month: 0.0000 Year: -
2016-10-03 14:04:39 statTemperatureDay Min: 18.40000 Avg: 20.67323 Max: 21.10000
2016-10-02 23:59:55 statTemperatureDayLast Min: 21.10000 Avg: 21.49230 Max: 21.60000
2016-10-03 14:04:39 statTemperatureMonth Min: 18.40000 Avg: 21.47087 Max: 219.00000
2016-09-30 23:59:55 statTemperatureMonthLast Min: 0.00000 Avg: 23.44224 Max: 213.00000
2016-10-03 14:04:39 statTemperatureYear Min: 0.00000 Avg: 23.98063 Max: 760.00000 (since: 2016-06-03_11:33:11 )
2016-10-03 10:56:20 state closed
2016-10-03 14:04:19 temperature 20.5 C
2016-10-03 13:49:08 timeToAck 0.516
2016-10-03 13:49:08 transmit OK
2016-03-26 19:35:06 version Lib 3 Prot 3.67 App 2.7 HW 1 FWCounter 1 FW 2.7
2016-10-03 13:49:08 wakeup notification
2016-03-26 19:44:09 wakeupReport interval 900 target 1
SendStack:
sentackget:1315028002258d
Helper:
_98_statistics Statistiken
Attributes:
IODev ZWaveBridge
alias Badezimmersensor
classes SENSOR_BINARY WAKE_UP ASSOCIATION BATTERY MULTI_CMD CRC_16_ENCAP MANUFACTURER_SPECIFIC VERSION CONFIGURATION MULTI_CHANNEL_ASSOCIATION SENSOR_MULTILEVEL SENSOR_ALARM BASIC
devStateIcon closed:motion_detector
open:people_sensor@lightgreen
event-on-change-reading state
event-on-update-reading battery,luminance,temperature,wakeup
group Sensoren
homebridgeMapping MotionDetected=state,values=/^open/:1;/^closed/:0
CurrentRelativeHumidity=bz_Sensor_TH1:humidity
CurrentTemperature=temperature,minValue=5,subtype=Raumtemperatur
CurrentTemperature=bz_Sensor_TH1:dewpoint,minValue=-15,subtype=Taupunkt
icon message_presence
neighborListPos 825.9616381544679,336.11002986227317
room Badezimmer,HomeKit,ZWave
suppressReading (humidity|direction|generalPurpose|particulateMatter|position)
vclasses ASSOCIATION:2 BASIC:1 BATTERY:1 CONFIGURATION:1 CRC_16_ENCAP:1 MULTI_CHANNEL_ASSOCIATION:2 MULTI_CMD:1 SENSOR_ALARM:1 SENSOR_BINARY:1 SENSOR_MULTILEVEL:5 VERSION:2 WAKE_UP:1
Gruß
Dan
Bewirkt bei Dir "setReading ku_Sensor_TK humidity 12" eine Aenderung?
Nein, es bewirkt keine Änderung am Reading. Ebenso bei dem anderen Sensor.
Somit scheint suppressReading ja bei beiden zu funktionieren, nur wo kommt das Reading dann immer wieder her (EDIT: Wert ist auch immer 0)?
Gruß
Dan
Wuesste ich auch gerne: ZWave setzt Readings nur ueber die reading*Update Funktionen, und die pruefen suppressReading.
Kannst du bitte mit
{ $defs{ku_Sensor_TK}{READINGS}{humidity} }
pruefen, ob das Reading genau so geschrieben wird?
HASH(0x534fbc0)
ist das Ergebnis.
Dann bin ich erstmal ohne Ideen.
Was bedeutet das Ergebnis?
Das ist der Perl-Hash mit Value und Timestamp. Will sagen, es ist ein "richtiges" Reading, mit dem Namen "humidity" und nicht etwa "humidity " oder " humidity".
wo kommen denn die ganzen stat.* readings her?
verwendest du statistics oder etwas ähnliches? tauchen die 0 readings auch auf wenn du statistics weg lässt?
kann es sein das im statistics modul beim zugriff auf $hash->{READINGS} etwas schief geht?
Danke, die Schlussfolgerung war mir nicht klar.
Es bleibt also mysteriös...
Gruß
Dan
Zitat von: justme1968 am 03 Oktober 2016, 16:10:50
wo kommen denn die ganzen stat.* readings her?
verwendest du statistics oder etwas ähnliches? tauchen die 0 readings auch auf wenn du statistics weg lässt?
kann es sein das im statistics modul beim zugriff auf $hash->{READINGS} etwas schief geht?
Ja natürlich verwende ich das statistics Modul.
Für die eigentlich nicht vorhandenen Readings (z.B. humidity) werden dann eben auch die Stats erstellt.
Gruß
Dan
ein schritt vorher: werden die 0 readings auch erzeugt wenn du statistics nicht verwendest?
Zitat von: justme1968 am 03 Oktober 2016, 16:16:22
ein schritt vorher: werden die 0 readings auch erzeugt wenn du statistics nicht verwendest?
Prüfe ich jetzt.
Habe das statistics Device auf disable gesetzt und alle sinnlosen Readings gelöscht.
Gruß
Dan
humidity wurde gerade eben wieder erstellt:
Internals:
DEF ee3970ea 11
IODev ZWaveBridge
LASTInputDev ZWaveBridge
MSGCNT 303
NAME ku_Sensor
NR 61
STATE open
TYPE ZWave
ZWaveBridge_MSGCNT 303
ZWaveBridge_RAWMSG 0004000b033003ff
ZWaveBridge_TIME 2016-10-03 16:28:26
ZWaveSubDevice no
homeId ee3970ea
isWakeUp 1
lastMsgSent 1475504480.98183
nodeIdHex 0b
Readings:
2016-10-01 08:49:10 SEND_DATA failed:00
2016-08-09 16:19:36 UNKNOWN multilevel type 43 fl: 4a arg: 0044
2016-10-01 13:44:30 UNPARSED SENSOR_MULTILEVEL 063125030a0026
2016-09-26 07:18:15 alarm_type_00 level 255 node 11 seconds 0
2016-06-02 03:58:38 alarm_type_01 level 22
2016-02-25 07:37:51 alarm_type_02 level 0a
2016-06-10 05:04:25 alarm_type_03 level 0a
2016-04-25 22:15:53 assocGroup_1 Max 5 Nodes
2016-04-25 22:15:53 assocGroup_2 Max 5 Nodes
2016-04-25 22:15:53 assocGroup_3 Max 1 Nodes ZWaveBridge
2016-04-25 22:15:52 assocGroups 3
2016-05-27 09:46:30 basicReport ef
2016-03-26 20:20:52 basicSet 00
2016-10-03 16:21:19 battery 100 %
2016-08-02 21:23:45 cmdGet wakeupInterval
2016-05-29 13:54:12 configAmbientIlluminationLevelAbove83 1000
2016-05-29 13:54:12 configAmbientIlluminationLevelBelow82 100
2016-05-30 22:14:25 configBASICOFFCommandFrameValue 0
2016-05-30 22:14:26 configBASICONCommandFrameValue 255
2016-05-30 22:14:26 configBasicCommandClassFrames12 BASICONAndBASICOFFCommandFrames0
2016-05-30 22:14:26 configIlluminationReportThreshold 200
2016-05-30 22:14:26 configIlluminationReportsInterval 900
2016-05-29 13:54:13 configIntervalOfTemperatureMeasuring 900
2016-05-30 22:29:25 configLEDBrightness 0
2016-05-29 13:54:13 configLEDIndicatingTamperAlarm LEDIndicatesTamperAlarm
2016-05-30 22:29:28 configLEDSignalingMode LongBlinkThenShortBlinkLEDColour10
2016-05-30 22:44:16 configMaximumTemperatureResultingInRed87 28
2016-05-29 13:54:14 configMinimumTemperatureResultingIn86 18
2016-05-29 13:54:14 configMotionAlarmCancellationDelay 30
2016-05-29 13:54:14 configMotionSensorSBlindTime2 15
2016-05-30 22:59:13 configMotionSensorSSensitivity 15
2016-05-29 13:54:15 configNightDay 200
2016-05-29 13:54:15 configPIRSensorOperatingMode PIRSensorAlwaysActive
2016-05-29 13:54:15 configPIRSensorSPulseCounter 2Pulses
2016-05-29 13:54:15 configPIRSensorSWindowTime 16Seconds
2016-05-30 23:14:11 configTamperAlarmBroadcastMode TamperAlarmIsNotSentInBroadcast0
2016-05-30 23:29:04 configTamperAlarmCancellationDelay 30
2016-05-29 13:54:16 configTamperOperatingModes Tamper
2016-05-29 13:54:16 configTamperSensitivity 15
2016-05-29 13:54:16 configTemperatureOffset 0
2016-05-29 13:54:16 configTemperatureReportThreshold 10
2016-05-30 23:58:55 configTemperatureReportsInterval 900
2016-10-03 16:27:20 humidity 0
2016-10-03 16:17:52 luminance 107 Lux
2016-04-26 23:12:49 model FIBARO System FGMS001 Motion Sensor
2016-04-26 23:12:49 modelConfig fibaro/fgms.xml
2016-04-26 23:12:49 modelId 010f-0800-1001
2016-10-03 16:28:26 reportedState open
2016-10-03 16:17:52 statBattery Hour: 0 Day: 0 Month: 0 Year: 0 (since: 2016-06-04 )
2016-10-03 15:59:55 statBatteryLast Hour: 0 Day: 0 Month: 0 Year: -
2016-10-03 16:17:52 statLuminance Hour: 44.00 Day: 107.00 Month: 107.00 Year: 107.00 (since: 2016-06-04 )
2016-10-03 15:59:55 statLuminanceLast Hour: -40.00 Day: 0.00 Month: -3.00 Year: -
2016-10-03 16:17:52 statTemperatureDay Min: 20.0 Avg: 20.7 Max: 21.5
2016-10-02 23:59:55 statTemperatureDayLast Min: 21.5 Avg: 21.9 Max: 22.5
2016-10-03 16:17:52 statTemperatureMonth Min: 20.0 Avg: 21.7 Max: 22.5
2016-09-30 23:59:55 statTemperatureMonthLast Min: 0.0 Avg: 24.3 Max: 1670.7
2016-10-03 16:17:52 statTemperatureYear Min: -3264.8 Avg: 24.4 Max: 1670.7 (since: 2016-06-03_11:33:07 )
2016-10-03 16:28:26 state open
2016-10-03 16:21:35 temperature 21.1 C
2016-08-24 12:14:52 time 1662.9 seconds
2016-10-03 16:21:21 timeToAck 0.062
2016-10-03 16:21:21 transmit OK
2016-10-03 16:21:18 wakeup notification
2016-01-29 03:19:44 wakeupReport interval 900 target 1
Helper:
_98_statistics Statistiken
Bm:
Zwave_get:
cnt 8
dmx 0
max 4
tot 20
mAr:
HASH(0x2b35388)
ku_Sensor
battery
Zwave_set:
cnt 62
dmx 0
max 3
tot 81
mAr:
HASH(0x2b35388)
ku_Sensor
?
Attributes:
IODev ZWaveBridge
alias Küchensensor
classes SENSOR_BINARY WAKE_UP ASSOCIATION BATTERY MULTI_CMD CRC_16_ENCAP MANUFACTURER_SPECIFIC VERSION CONFIGURATION MULTI_CHANNEL_ASSOCIATION SENSOR_MULTILEVEL SENSOR_ALARM BASIC
devStateIcon closed:motion_detector
open:people_sensor@lightgreen
event-on-change-reading state
event-on-update-reading battery,luminance,temperature,wakeup
group Sensoren
homebridgeMapping CurrentTemperature=temperature,minValue=5,subtype=Raumtemperatur
CurrentTemperature=ku_Sensor_TH1:dewpoint,minValue=-15,subtype=Taupunkt
CurrentRelativeHumidity=ku_Sensor_TH1:humidity
CurrentAmbientLightLevel=luminance,minValue=0
MotionDetected=state,values=/^open/:1;/^closed/:0
icon message_presence
neighborListPos 825.7779767869511,108.7127725943412
room HomeKit,Küche,ZWave
suppressReading (humidity|direction|generalPurpose|particulateMatter|position)
Auch beim LaCrosse wieder humidity:
Internals:
DEF 21
IODev JeeLink1
JeeLink1_MSGCNT 661
JeeLink1_RAWMSG OK 9 33 1 3 51 106
JeeLink1_TIME 2016-10-03 16:34:51
LASTInputDev JeeLink1
LaCrosse_lastRcv 2016-10-03 16:34:51
MSGCNT 661
NAME ku_Sensor_TK
NR 294
STATE T: -17.9
TYPE LaCrosse
addr 21
battery_new 0
corr1 0
corr2 0
previousH 106
previousT -18
sensorType 0=T(H)
Readings:
2016-09-16 18:34:50 H 0
2016-09-16 18:43:51 T 0
2016-10-03 16:34:51 battery ok
2016-10-03 16:27:20 humidity 0
2016-09-22 21:59:08 statBattery Hour: 0 Day: 0 Month: 0 Year: 0 (since: 2016-09-12 )
2016-09-22 20:59:55 statBatteryLast Hour: 0 Day: 0 Month: - Year: -
2016-09-22 21:59:08 statTemperatureDay Min: 26.3 Avg: 28.1 Max: 29.9
2016-09-21 23:59:55 statTemperatureDayLast Min: 27.4 Avg: 29.8 Max: 31.3
2016-09-22 21:59:08 statTemperatureMonth Min: 21.3 Avg: 29.8 Max: 35.9 (since: 2016-09-11_14:56:42 )
2016-09-22 21:59:08 statTemperatureYear Min: 21.3 Avg: 29.8 Max: 35.9 (since: 2016-09-11_14:56:42 )
2016-10-03 16:34:31 state T: -17.9
2016-10-03 16:34:51 temperature -17.9
Helper:
Bm:
Lacrosse_set:
cnt 295
dmx 0
mAr
max 0
tot 0
Attributes:
IODev JeeLink1
alias Sensor Tiefkühler
doAverage 1
event-on-update-reading state,temperature
group Sensoren
icon temp_temperature
room Anwesenheit,Küche,LaCrosse
suppressReading humidity
Das statistics Modul (und avarage und andere vlt auch), sind relativ alt, und greifen auf die Readings direkt zu, ohne die ReadingsVal oder readings*Update Funktionen. Soweit ich in statistics sehe, koennen durch den direkten Zugriff aus $defs{X}{READINGS}{humidity}{VAL} auch noch andere Warnungen entstehen, ich tippe auch darauf, dass dieses Modul die Readings anlegt.
Wie gesagt, das statistics Modul ist seit gestern auf disable gesetzt und humidity wurde wieder erzeugt. Wenn statistics noch aktiv wäre hätten auch Stats Readings für humidity erzeugt werden müssen. Das wurden sie aber nicht.
Wenn es was bringt, dann lösche ich auch gerne mal testweise das statistics Device komplett und alle damit erzeugten stat.... Readings.
Gruß
Dan
Hab das statistics Device nun komplett gelöscht und ebenfalls die ungewünschten Readings bei dem LaCrosse Sensor:
deletereading ku_Sensor_TK humidity|H|T
Dieses Mal habe ich die Readings H und T ebenfalls gelöscht weil sie sowieso nur immer 0 angezeigt hatten.
Ebenso habe ich alle stats Readings gelöscht:
deletereading .* stat(T|B|H|L).*
Nach kurzer Zeit kamen H und humidity wieder. Und beide zur selben Zeit.
Internals:
DEF 21
IODev JeeLink1
JeeLink1_MSGCNT 375
JeeLink1_RAWMSG OK 9 33 1 3 27 106
JeeLink1_TIME 2016-10-04 12:51:34
LASTInputDev JeeLink1
LaCrosse_lastRcv 2016-10-04 12:51:34
MSGCNT 375
NAME ku_Sensor_TK
NR 292
STATE T: -20.5
TYPE LaCrosse
addr 21
battery_new 0
corr1 0
corr2 0
previousH 106
previousT -20.4
sensorType 0=T(H)
Readings:
2016-10-04 12:40:07 H 0
2016-10-04 12:51:34 battery ok
2016-10-04 12:40:07 humidity 0
2016-10-04 12:50:24 state T: -20.5
2016-10-04 12:51:34 temperature -20.5
T:
Attributes:
IODev JeeLink1
alias Sensor Tiefkühler
doAverage 1
event-on-update-reading state,temperature
group Sensoren
icon temp_temperature
room Anwesenheit,Küche,LaCrosse
suppressReading humidity
Auch bei den ZWave Sensoren ist humidity wieder da:
deletereading (ku|bz|sz|wz)_Sensor (humidity|dewpoint|direction|generalPurpose|particulateMatter|position)
Internals:
DEF ee3970ea 21
IODev ZWaveBridge
LASTInputDev ZWaveBridge
MSGCNT 152
NAME bz_Sensor
NR 148
STATE closed
TYPE ZWave
ZWaveBridge_MSGCNT 152
ZWaveBridge_RAWMSG 00041015063105030a0030
ZWaveBridge_TIME 2016-10-04 12:31:37
ZWaveSubDevice no
homeId ee3970ea
isWakeUp 1
lastMsgSent 1475577066.54054
nodeIdHex 15
Readings:
2016-10-04 08:46:33 SEND_DATA failed:00
2016-09-30 09:34:46 UNKNOWN multilevel type 43 fl: 0a arg: 001b
2016-10-02 18:37:46 UNPARSED SENSOR_BINARY 063005012200d6
2016-10-02 12:54:02 alarm_type_00 level 255 node 21 seconds 0
2016-04-22 10:38:29 alarm_type_01 level 22
2016-03-30 23:12:25 alarm_type_03 level 0a
2016-03-26 19:32:45 assocGroup_1 Max 5 Nodes
2016-03-26 19:32:45 assocGroup_2 Max 5 Nodes
2016-03-26 19:32:45 assocGroup_3 Max 1 Nodes ZWaveBridge
2016-03-26 19:33:08 assocGroups 3
2016-04-29 11:04:52 basicReport 00
2016-03-26 19:30:40 basicSet ff
2016-10-04 12:31:04 battery 100 %
2016-09-02 08:50:38 cmdGet wakeupInterval
2016-08-29 08:19:07 cmdSet wakeupInterval
2016-05-29 13:09:45 configAmbientIlluminationLevelAbove83 1000
2016-05-29 13:54:38 configAmbientIlluminationLevelBelow82 100
2016-06-30 12:30:36 configBASICOFFCommandFrameValue 0
2016-06-30 12:30:36 configBASICONCommandFrameValue 255
2016-06-30 12:30:36 configBasicCommandClassFrames12 BASICONAndBASICOFFCommandFrames0
2016-06-30 12:30:36 configIlluminationReportThreshold 200
2016-06-30 12:30:36 configIlluminationReportsInterval 900
2016-06-30 12:30:37 configIntervalOfTemperatureMeasuring 900
2016-06-30 12:30:37 configLEDBrightness 0
2016-06-30 12:30:37 configLEDIndicatingTamperAlarm LEDIndicatesTamperAlarm
2016-06-30 12:30:37 configLEDSignalingMode LongBlinkThenShortBlinkLEDColour10
2016-06-30 12:30:37 configMaximumTemperatureResultingInRed87 28
2016-06-30 12:30:37 configMinimumTemperatureResultingIn86 18
2016-06-30 12:30:38 configMotionAlarmCancellationDelay 30
2016-06-30 12:30:38 configMotionSensorSBlindTime2 15
2016-06-30 12:30:38 configMotionSensorSSensitivity 15
2016-06-30 12:30:38 configNightDay 200
2016-06-30 12:30:38 configPIRSensorOperatingMode PIRSensorAlwaysActive
2016-06-30 12:30:39 configPIRSensorSPulseCounter 1Pulse
2016-06-30 12:30:39 configPIRSensorSWindowTime 12Seconds
2016-06-30 12:30:39 configTamperAlarmBroadcastMode TamperAlarmIsNotSentInBroadcast0
2016-06-30 12:30:39 configTamperAlarmCancellationDelay 30
2016-06-30 12:30:39 configTamperOperatingModes Tamper
2016-06-30 12:30:39 configTamperSensitivity 15
2016-06-30 12:30:40 configTemperatureOffset 0
2016-06-30 12:30:40 configTemperatureReportThreshold 10
2016-06-30 12:30:40 configTemperatureReportsInterval 900
2016-10-04 12:36:02 humidity 0
2016-10-04 12:31:37 luminance 48 Lux
2016-03-26 19:34:51 mcaSupportedGroupings 2
2016-04-11 19:35:17 model FIBARO System FGMS001 Motion Sensor
2016-04-11 19:35:17 modelConfig fibaro/fgms.xml
2016-04-11 19:35:17 modelId 010f-0800-1001
2016-06-06 00:31:52 neighborList ku_Licht3 ku_SD2 ku_SD3 ku_SD4 bz_SD1
2016-10-04 12:06:21 reportedState closed
2016-10-04 12:06:21 state closed
2016-10-04 12:31:19 temperature 20.6 C
2016-10-04 12:31:06 timeToAck 0.077
2016-10-04 12:31:06 transmit OK
2016-03-26 19:35:06 version Lib 3 Prot 3.67 App 2.7 HW 1 FWCounter 1 FW 2.7
2016-10-04 12:31:04 wakeup notification
2016-03-26 19:44:09 wakeupReport interval 900 target 1
Attributes:
IODev ZWaveBridge
alias Badezimmersensor
classes SENSOR_BINARY WAKE_UP ASSOCIATION BATTERY MULTI_CMD CRC_16_ENCAP MANUFACTURER_SPECIFIC VERSION CONFIGURATION MULTI_CHANNEL_ASSOCIATION SENSOR_MULTILEVEL SENSOR_ALARM BASIC
devStateIcon closed:motion_detector
open:people_sensor@lightgreen
event-on-change-reading state
event-on-update-reading battery,luminance,temperature,wakeup
group Sensoren
homebridgeMapping MotionDetected=state,values=/^open/:1;/^closed/:0
CurrentRelativeHumidity=bz_Sensor_TH1:humidity
CurrentTemperature=temperature,minValue=5,subtype=Raumtemperatur
CurrentTemperature=bz_Sensor_TH1:dewpoint,minValue=-15,subtype=Taupunkt
icon message_presence
neighborListPos 825.9616381544679,336.11002986227317
room Badezimmer,HomeKit,ZWave
suppressReading (humidity|direction|generalPurpose|particulateMatter|position)
vclasses ASSOCIATION:2 BASIC:1 BATTERY:1 CONFIGURATION:1 CRC_16_ENCAP:1 MULTI_CHANNEL_ASSOCIATION:2 MULTI_CMD:1 SENSOR_ALARM:1 SENSOR_BINARY:1 SENSOR_MULTILEVEL:5 VERSION:2 WAKE_UP:1
Bei dem LaCrosse werde ich nun "attr ku_Sensor_TK suppressReading (humidity|H|T)" setzen und mal schauen ob dann die Readings wieder kommen. Ich werde berichten.
Bei den ZWave Sensoren fehlt mir allerdings eine weitere Möglichkeit etwas zu testen. Obwohl, ich könnte ja mal "suppressReading (humidit.*|direction|generalPurpose|particulateMatter|position)" testen.
Gruß
Dan
Der LaCrosse Sensor hat trotz "suppressReading (humidity|H|T)" auch wieder diese Readings erstellt.
Teste nun noch "suppressReading (humidit.*|H.*|T.*)".
Bei allen vier ZWave Sensoren sind die humidity Readings auch wieder gekommen.
Internals:
DEF ee3970ea 21
IODev ZWaveBridge
LASTInputDev ZWaveBridge
MSGCNT 215
NAME bz_Sensor
NR 148
STATE closed
TYPE ZWave
ZWaveBridge_MSGCNT 215
ZWaveBridge_RAWMSG 00041015063105030a0038
ZWaveBridge_TIME 2016-10-04 14:01:25
ZWaveSubDevice no
homeId ee3970ea
isWakeUp 1
lastMsgSent 1475582454.44177
nodeIdHex 15
Readings:
2016-10-04 08:46:33 SEND_DATA failed:00
2016-09-30 09:34:46 UNKNOWN multilevel type 43 fl: 0a arg: 001b
2016-10-02 18:37:46 UNPARSED SENSOR_BINARY 063005012200d6
2016-10-02 12:54:02 alarm_type_00 level 255 node 21 seconds 0
2016-04-22 10:38:29 alarm_type_01 level 22
2016-03-30 23:12:25 alarm_type_03 level 0a
2016-03-26 19:32:45 assocGroup_1 Max 5 Nodes
2016-03-26 19:32:45 assocGroup_2 Max 5 Nodes
2016-03-26 19:32:45 assocGroup_3 Max 1 Nodes ZWaveBridge
2016-03-26 19:33:08 assocGroups 3
2016-04-29 11:04:52 basicReport 00
2016-03-26 19:30:40 basicSet ff
2016-10-04 14:00:52 battery 100 %
2016-09-02 08:50:38 cmdGet wakeupInterval
2016-08-29 08:19:07 cmdSet wakeupInterval
2016-05-29 13:09:45 configAmbientIlluminationLevelAbove83 1000
2016-05-29 13:54:38 configAmbientIlluminationLevelBelow82 100
2016-06-30 12:30:36 configBASICOFFCommandFrameValue 0
2016-06-30 12:30:36 configBASICONCommandFrameValue 255
2016-06-30 12:30:36 configBasicCommandClassFrames12 BASICONAndBASICOFFCommandFrames0
2016-06-30 12:30:36 configIlluminationReportThreshold 200
2016-06-30 12:30:36 configIlluminationReportsInterval 900
2016-06-30 12:30:37 configIntervalOfTemperatureMeasuring 900
2016-06-30 12:30:37 configLEDBrightness 0
2016-06-30 12:30:37 configLEDIndicatingTamperAlarm LEDIndicatesTamperAlarm
2016-06-30 12:30:37 configLEDSignalingMode LongBlinkThenShortBlinkLEDColour10
2016-06-30 12:30:37 configMaximumTemperatureResultingInRed87 28
2016-06-30 12:30:37 configMinimumTemperatureResultingIn86 18
2016-06-30 12:30:38 configMotionAlarmCancellationDelay 30
2016-06-30 12:30:38 configMotionSensorSBlindTime2 15
2016-06-30 12:30:38 configMotionSensorSSensitivity 15
2016-06-30 12:30:38 configNightDay 200
2016-06-30 12:30:38 configPIRSensorOperatingMode PIRSensorAlwaysActive
2016-06-30 12:30:39 configPIRSensorSPulseCounter 1Pulse
2016-06-30 12:30:39 configPIRSensorSWindowTime 12Seconds
2016-06-30 12:30:39 configTamperAlarmBroadcastMode TamperAlarmIsNotSentInBroadcast0
2016-06-30 12:30:39 configTamperAlarmCancellationDelay 30
2016-06-30 12:30:39 configTamperOperatingModes Tamper
2016-06-30 12:30:39 configTamperSensitivity 15
2016-06-30 12:30:40 configTemperatureOffset 0
2016-06-30 12:30:40 configTemperatureReportThreshold 10
2016-06-30 12:30:40 configTemperatureReportsInterval 900
2016-10-04 14:03:29 humidity 0
2016-10-04 14:01:25 luminance 56 Lux
2016-03-26 19:34:51 mcaSupportedGroupings 2
2016-04-11 19:35:17 model FIBARO System FGMS001 Motion Sensor
2016-04-11 19:35:17 modelConfig fibaro/fgms.xml
2016-04-11 19:35:17 modelId 010f-0800-1001
2016-06-06 00:31:52 neighborList ku_Licht3 ku_SD2 ku_SD3 ku_SD4 bz_SD1
2016-10-04 12:06:21 reportedState closed
2016-10-04 12:06:21 state closed
2016-10-04 13:46:09 temperature 20.6 C
2016-10-04 14:00:54 timeToAck 0.060
2016-10-04 14:00:54 transmit OK
2016-03-26 19:35:06 version Lib 3 Prot 3.67 App 2.7 HW 1 FWCounter 1 FW 2.7
2016-10-04 14:00:52 wakeup notification
2016-03-26 19:44:09 wakeupReport interval 900 target 1
Attributes:
IODev ZWaveBridge
alias Badezimmersensor
classes SENSOR_BINARY WAKE_UP ASSOCIATION BATTERY MULTI_CMD CRC_16_ENCAP MANUFACTURER_SPECIFIC VERSION CONFIGURATION MULTI_CHANNEL_ASSOCIATION SENSOR_MULTILEVEL SENSOR_ALARM BASIC
devStateIcon closed:motion_detector
open:people_sensor@lightgreen
event-on-change-reading state
event-on-update-reading battery,luminance,temperature,wakeup
group Sensoren
homebridgeMapping MotionDetected=state,values=/^open/:1;/^closed/:0
CurrentRelativeHumidity=bz_Sensor_TH1:humidity
CurrentTemperature=temperature,minValue=5,subtype=Raumtemperatur
CurrentTemperature=bz_Sensor_TH1:dewpoint,minValue=-15,subtype=Taupunkt
icon message_presence
neighborListPos 825.9616381544679,336.11002986227317
room Badezimmer,HomeKit,ZWave
suppressReading (humidit.*|direction|generalPurpose|particulateMatter|position)
vclasses ASSOCIATION:2 BASIC:1 BATTERY:1 CONFIGURATION:1 CRC_16_ENCAP:1 MULTI_CHANNEL_ASSOCIATION:2 MULTI_CMD:1 SENSOR_ALARM:1 SENSOR_BINARY:1 SENSOR_MULTILEVEL:5 VERSION:2 WAKE_UP:1
Was mir aber dieses Mal auffällt, dass bei allen vier Sensoren der Timestamp vom Reading humidity der selbe ist.
Alle vier auf 2016-10-04 14:03:29.
Das kann doch kein Zufall sein! Schreibt hier eventuell ein anderes Device das humidity Reading in die Geräte?
Ich habe meine fhem.cfg und die 99_myUtils.pm nach möglichen Verdächtigen durchsucht, leider ohne Erfolg.
Gruß
Dan
Beim LaCrosse sind die Readings nun auch wieder da:
Internals:
DEF 21
IODev JeeLink1
JeeLink1_MSGCNT 568
JeeLink1_RAWMSG OK 9 33 1 3 42 106
JeeLink1_TIME 2016-10-04 14:30:24
LASTInputDev JeeLink1
LaCrosse_lastRcv 2016-10-04 14:30:24
MSGCNT 568
NAME ku_Sensor_TK
NR 292
STATE T: -18.9
TYPE LaCrosse
addr 21
battery_new 0
corr1 0
corr2 0
previousH 106
previousT -18.9
sensorType 0=T(H)
Readings:
2016-10-04 14:26:08 H 0
2016-10-04 14:28:09 T 0
2016-10-04 14:30:24 battery ok
2016-10-04 14:26:08 humidity 0
2016-10-04 14:29:39 state T: -18.9
2016-10-04 14:30:24 temperature -18.9
Attributes:
IODev JeeLink1
alias Sensor Tiefkühler
event-on-update-reading state,temperature
group Sensoren
icon temp_temperature
room Anwesenheit,Küche,LaCrosse
suppressReading (humidit.*|H.*|T.*)
Ich weiß echt nicht was ich noch probieren könnte.
Gruß
Dan
Könnte dewpoint verantwortlich sein?
define dewpointToAllDeviceReadings dewpoint dewpoint .* temperature humidity dewpoint
Hab das Device jetzt mal gelöscht und beobachte weiter.
Gruß
Dan
Offensichtlich war das dewpoint Device Schuld an den komischen humidity, H und T Readings beim LaCrosse.
Seit dem ich gestern das dewpoint Device gelöscht habe sind die Readings nicht wieder aufgetaucht.
Internals:
DEF 21
IODev JeeLink1
JeeLink1_MSGCNT 19
JeeLink1_RAWMSG OK 9 33 1 3 11 106
JeeLink1_TIME 2016-10-05 11:05:48
LASTInputDev JeeLink1
LaCrosse_lastRcv 2016-10-05 11:05:48
MSGCNT 19
NAME ku_Sensor_TK
NR 290
STATE T: -22.1
TYPE LaCrosse
addr 21
battery_new 0
corr1 0
corr2 0
previousH 106
previousT -22
sensorType 0=T(H)
Readings:
2016-10-05 11:05:48 battery ok
2016-10-05 10:57:48 state T: -22.1
2016-10-05 11:05:48 temperature -22.1
Attributes:
IODev JeeLink1
alias Sensor Tiefkühler
doAverage 1
group Sensoren
icon temp_temperature
room Anwesenheit,Küche,LaCrosse
Auch bei den ZWave Sensoren sind die humidity Readings bis jetzt nicht wiedergekommen.
Also scheint das Problem der falschen Readings wohl vom dewpoint Modul gekommen zu sein.
Meine Annahme war das dewpoint nur auf Devices wirkt welche die Readings temperature und humidity bereits aufweisen und nicht dass ein nicht vorhandenes humidity von dewpoint angelegt wird. Aber das ist wohl besser in einem neuen Thema zu dewpoint aufgehoben.
Habe jetzt bei den LaCrosse Sensoren "doDewpoint 1" gesetzt und ein neues dewpoint Device nur für den einen HM-WDS10-TH-O angelegt. Somit dürfte das nun "sauber" sein.
Bei allen LaCrosse und ZWave Sensoren habe ich das attr suppressReading wieder entfernt und werde beobachten welche merkwürdigen Readings irgendwann wieder auftauchen. Gestern fand ich bei einem der vier ZWave Sensoren noch ein Reading "barometricPressure" und bei zweien das Reading "time".
Gruß
Dan
Nach einigen Wochen des Testens kann ich nun Erfolg berichten.
Nach und nach habe ich die suppressReading Attribute befüllt mit den überflüssigen Readings. Hin und wider taucht mal wieder ein neues Reading auf welches ich noch nicht berücksichtigt hatte.
Die Readings die ich aber in suppressReading berücksichtigt habe sind bisher nicht wieder aufgetaucht!
Bin nun sehr zufrieden mit diesem Attribut.
Danke dafür!!! 8)
Gruß
Dan