Bisher werden die Befehle in FHEM auch für Command Classes zur Verfügung gestellt, die laut NIF nur als controlled deklariert sind. Hatte ich zuletzt auch noch so befürwortet, um kaputte NIFs auszugleichen. Aufgrund einer Anfrage im Anfängerforum habe ich meine Meinung geändert:
- funktionslose Befehle für CCs, die nur controlled sind, verwirren; insbesondere bei zunehmender Anzahl von CCs
- die aktuellen Geräte haben meinem Eindruck nach kaum noch kaputte NIFs
- FHEM ergänzt fehlende CCs mitterweile anhand der XMLs
- parse verarbeitet auch Nachrichten, die ohne Eintrag in Attribut classes, vom Gerät kommen
Mit anhängendem Patch werden nur noch Befehle für CCs supported zur Auswahl angeboten (stehen im Attribut classes links vom MARK). Ganz zufrieden bin ich nicht, da der Patch mit der Vergangenheit bricht und die Reihenfolge in einem von User anpassbaren Attribut wichtig wird. Einflüsse auf SECURITY kann ich nicht überblicken. Warnung: Die Anpassung des Attribut classes durch die XMLs habe ich in Trockenübung gemacht.
Habs eingecheckt.
Es hat relativ schnell ein anderes Problem zutagegebracht, was eigentlich damit nichts zu tun hat:
- Mein Bewegungssensor meldet basicReport, was ich per eventMap auf on/off mappe.
- SetExtensions meint: wenn jemand (per eventMap) on/off sendet, der kann auch on/off empfangen, und bietet toggle/on-for-timer/etc an.
- Bisher wurde dadurch dem Sensor basicReport 255 versendet (ja, das ist auch Unsinn), jetzt gibt es die Fehlermeldung gleich in FHEM.
Wenn jemand eine Idee hat, wie ich sowas SetExtensions ohne Nebeneffekte austreibe, der moege sich melden.
Hi,
Security schaue ich mir morgen mal an, ich glaube aber das ich die Position des Mark berücksichtigt habe und es keine negativen Auswirkungen geben sollte.
Gruß, Andreas
Gesendet von meinem D5803 mit Tapatalk
Das Hinzufügen einer CC zum Attribut classes anhand der XMLs ist unnötig, wenn sie mit setasreport="true" markiert ist. FHEM wertet im Gegensatz zu ozw alle empfangenen Nachrichten aus. Der beigefügte Patch entfernt die Automatik.
@Andreas: Danke. Hatte auch nichts gefunden, bin aber sehr unsicher.
Hi Christian,
Zitat von: krikan am 27 Mai 2017, 18:40:30
@Andreas: Danke. Hatte auch nichts gefunden, bin aber sehr unsicher.
denke das sollte so in Ordnung sein. Ich schaue bei Security nach neuen Klassen die durch die Aktivierung der Security dazugekommen sind und sortiere die in classes ein, beachte dabei aber die Position des MARK, d.h. was vor dem MARK steht wird auch davor einsortiert, was danach steht wird auch danach einsortiert.
Dadurch sollte das auch weiterhin funktionieren.
Gruß,
Andreas.
Habe die Aenderungen aus dem CCSupportedNoCmdsPart2.patch eingecheckt.
Das https://forum.fhem.de/index.php/topic,72507.0.html passiert, wenn ich meine Meinung ändere.
Dem im Link genannten FGRM habe ich selbst zum Testen genutzt. Der Testaktor hatte SWITCH_MULTILEVEL links vom MARK; habe aber auch einen anderen, wo ich das Problem nachvollziehen kann: steht dort nur rechts vom MARK.
Zurückdrehen?
Hast du eine Idee, wie die anderen sowas handhaben?
Vermute das geht über die Pflichtklassen des jeweiligen Gerätetypen laut NIF (http://zwavepublic.com/sites/default/files/SDS10242-29%20-%20Z-Wave%20Device%20Class%20Specification.pdf) . ozw und Co. gehen immer davon aus, dass die Pflichtklassen des Gerätetypen vorhanden sind. Darum gibt es in den XMLs auch remove, was wir nicht benötigen.
Persönlich finde FHEM-Altlösung mit dem Risiko von funktionslosen Befehlen besser, als auf die (pflegeaufwändige?) Device Class Specification zu setzen.
Angesichts des Problems mit dem nicht seltenen FGRM sehe ich als einfachsten Weg nur ein Zurückdrehen des Patches.
Habe CCControlledNoCmds.patch zurueckgedreht.
Danke! Ab jetzt (fast) keine Meinungsänderungen von mir. :)