Hallo Zusammen!
Ich betreibe seit geraumer Zeit eine Fhem Installation auf einem Raspberry und grundsätzlich funktioniert alles bestens. Mittlerweile bin ich jedoch auf eine kosmetische Unschönheit gestossen.
In einigen Devices befinden sich Readings die es eigentlich nicht gibt. z.B. wird bei einem FIBARO System FGR222 Roller Shutter Controller 2 ein Batterie Reading angezeigt. Bei einem anderen habe ich plötzlich Luftfeuchtigkeitswerte. Da das nicht wirklich passt wollte ich fragen wie ich die Devices neu initialisieren kann ohne meine bestehende Konfiguration zu verlieren. Meine Meinung war einfach die fhem.save zu bereinigen leider war das nicht von dauerhaftem Erfolg gekrönt.
Falls jemand eine Lösung dafür hat oder einen Link aus dem Forum (wo ich leider nichts gefunden habe) wäre ich recht dankbar.
lg
Cherrytree
deletereading <device> <reading>
Danke. Das hatte ich vergessen zu erwähnen, dass ich das bereits gemacht habe.
Das falsche Reading kam jedoch wieder...
Dann mal mehr Infos und am besten ein list von den betreffenden Devices hier in Codetags eintragen.
Ich erinnere mich dunkel, schon öfter gehört zu haben, dass ZWAVE Geräte manchmal seltsame readings erzeugen, kann aber den post nicht mehr finden. Vielleicht verschiebst du ins Zwave-Forum (Button ganz links unten), da ist vielleicht jemand unterwegs, der das Problem kennt.
Zitat von: KernSani am 11 Mai 2017, 15:18:37
Ich erinnere mich dunkel, schon öfter gehört zu haben, dass ZWAVE Geräte manchmal seltsame readings erzeugen, kann aber den post nicht mehr finden. Vielleicht verschiebst du ins Zwave-Forum (Button ganz links unten), da ist vielleicht jemand unterwegs, der das Problem kennt.
Ich kenne das Problem zur Genüge und habe hier schon öfter darüber berichtet.
Man kann nur die fehlerhaften Readings löschen, das kann man auch z.B. per at regelmäßig machen, und dann die unerwünschten Readings in das Attribut suppressReading als RegEx eintragen. Dann sollten die Readings nicht mehr kommen.
Gruß
Dan
Hi,
ich hatte solche Probleme weil ich in der 99_myUtils direkt sowas wie
$defs{<device>}{READINGS}{<reading>}{VAL}
...abgefragt hatte. Das kann auch mal das ein oder andere Reading "produzieren" und da hilft auch kein suppressReading.
Gruß,
Thorsten
Zitat von: DeeSPe am 11 Mai 2017, 15:21:34
Ich kenne das Problem zur Genüge und habe hier schon öfter darüber berichtet.
Hattest Du schon mal mit dem u.a. deshalb von Rudi für entsprechende ZWave-Devices eingeführten, experimentellen Attribut useCRC16 probiert? Keine Abhilfe?
Gruß, Christian
und wenn nichts anderes hilft gibt es das suppressReadings attribut.
gruss
andre
Zitat von: krikan am 11 Mai 2017, 15:35:51
Hattest Du schon mal mit dem u.a. deshalb von Rudi für entsprechende ZWave-Devices eingeführten, experimentellen Attribut useCRC16 probiert? Keine Abhilfe?
Gruß, Christian
Das habe ich bisher noch nicht probiert.
Danke aber für den Hinweis, werde mich damit mal auseinandersetzen.
Zitat von: justme1968 am 11 Mai 2017, 17:02:54
und wenn nichts anderes hilft gibt es das suppressReadings attribut.
Das hatte ich doch schon erwähnt... ;)
Gruß
Dan
Ich habe useCRC16 bei den Fibaro Motion Sensors gesetzt und wieder komische Readings erhalten die ich soeben bereinigt habe.
z.B.:
tankCapacity
direction
particulateMatter
dewpoint
generalPurpose
humidity
power
time
Gruß
Dan
Hi,
useCRC16 funktioniert nur bei den Abfragen an das Gerät (und wenn das Gerät auch CRC16 unterstützt)! D.h. wenn man irgendetwas aktiv beim Gerät abfragt wird das in CRC16 eingepackt und das Gerät MUSS dann auch mit CRC16 verpackt antworten. Die automatischen Statusnachrichten z.B. bei Erreichen von Schwellwerten oder einem Bewegungsalarm von einem Bewegungssensor werden von den Geräte jedoch weiterhin ohne CRC16 gesendet.
Es ist in der Spezifikation nicht vorgesehen das einstellen zu können. Hintergrund ist das die Geräte z.B. für Schaltvorgänge mit einem anderen Gerät assoziiert werden und dem Gerät nicht bekannt ist ob das "Empfangs-Gerät" überhaupt CRC16 verstehen würde, da zwischen den beiden Geräten kein NIF ausgetauscht wird. Man sagt lediglich einem Gerät das es etwas an ein Gerät mit der Nummer xxx schicken soll...
Gruß,
Andreas.
Hallo Andreas!
Hast Du eine Quellenangabe aus der sich ergibt, dass spontane Nachrichten an den Controller nicht CRC16 geschützt sein können?
Aus der Erinnerung enthielt mein ZWCul-Log vom HCL genaubsolche Nachrichten.
Gruß, Christian
Hallo Christian,
Zitat von: krikan am 19 Juni 2017, 21:36:27
Hast Du eine Quellenangabe aus der sich ergibt, dass spontane Nachrichten an den Controller nicht CRC16 geschützt sein können?
Aus der Erinnerung enthielt mein ZWCul-Log vom HCL genaubsolche Nachrichten.
ich habe das aus der Diskussion auf forum.z-wavepublic.com (http://forum.z-wavepublic.com/t/use-of-crc16-class-encoded-messages/115) so mitgenommen. Dort hatte ich das Thema mal eröffnet.
Ist eigentlich auch logisch das bei einer einfachen Assoziation nicht klar sein kann ob der Empfänger das verarbeiten kann.
Bei 100k Übertragung sollte das auch nicht passieren, da dann die Nachricht "intern" mit CRC16 gesichert ist. Nachrichten mit SECURITY sind da auch recht sicher da die "Authentication" dann nicht mehr stimmt
Gruß,
Andreas.