Command Class umbenannt (ALARM -> NOTIFICATION), wie in FHEM anpassen?

[krikan]

Ist auch logisch, da SWITCH_MULTILEVEL im Beispiel FGRM222 nur rechts von MARK steht. Für mich kein Problem, da ich mit "position" steuere. Aber wie geht das bei denjenigen, die dim genutzt haben?

Hier steht die Klasse aber links von MARK und alle Befehle fehlen.

Code Auswählen Erweitern

Internals:
   DEF        e345c452 19
   IODev      ZWDongle_0
   NAME       ZWave_LED
   NR         228
   STATE      neighborUpdate
   TYPE       ZWave
   homeId     e345c452
   nodeIdHex  13
   Readings:
     2016-05-25 21:50:30   SEND_DATA       failed:00
     2016-05-21 20:18:54   assocGroupName_01 Lifeline
     2016-05-21 20:18:18   assocGroup_1    Max 5 Nodes ZWDongle_0
     2016-05-21 20:18:18   assocGroup_2    Max 5 Nodes
     2016-05-21 20:18:18   assocGroups     2
     2016-06-01 19:18:57   basicReport     63
     2016-05-21 20:22:38   ccStatus_00     00
     2016-05-21 20:22:16   ccStatus_01     ff
     2016-05-21 20:22:21   ccStatus_02     00
     2016-05-21 20:22:25   ccStatus_03     00
     2016-05-21 20:22:30   ccStatus_04     00
     2016-05-21 19:51:25   configColorIndexConfigurationWhenThe38 2271560481
     2016-05-21 19:51:30   configColorfulModeConfiguration 3840
     2016-05-21 19:51:30   configLockUnlockConfiguration Unlock
     2016-05-21 19:51:35   configSendNotificationsToAssociated80 Basic
     2016-05-21 19:51:36   configSendOutAReportWhenTheColorIs32 Disable
     2016-05-21 19:51:36   configUseExternalSwitchToChangesThe35 Enable
     2016-05-21 19:51:36   configUseExternalSwitchToTurnOnOffThe34 Disable
     2016-05-21 19:51:20   model           Aeotec LED Bulb
     2016-05-21 19:51:20   modelConfig     aeotec/ledbulb.xml
     2016-05-21 19:51:20   modelId         0086-0003-0062
     2016-06-01 19:53:33   neighborList    ZWDongle_0 ZWave_SWITCH_MULTILEVEL_4 ZWave_SWITCH_BINARY_6 ZWave_SWITCH_MULTILEVEL_26 ZWave_SWITCH_MULTILEVEL_27 ZWave_SENSOR_BINARY_47 ZWave_SENSOR_NOTIFICATION_49 ZWave_SWITCH_BINARY_62 ZWave_RM_Flur_EG ZWave_RM_Jan ZWave_RM_Flur ZWave_RM_Eltern ZWave_SWITCH_BINARY_70
     2016-06-01 19:53:18   state           neighborUpdate
     2016-06-01 20:08:24   transmit        OK
     2016-05-21 20:18:10   zwavePlusInfo   version:01 role:AlwaysOnSlave node:Z-Wave+Node installerIcon:0600 userIcon:0600
Attributes:
   IODev      ZWDongle_0
   classes    ZWAVEPLUS_INFO SWITCH_MULTILEVEL COLOR_CONTROL SWITCH_ALL SCENE_ACTUATOR_CONF SCENE_ACTIVATION CONFIGURATION ASSOCIATION_GRP_INFO ASSOCIATION MANUFACTURER_SPECIFIC VERSION FIRMWARE_UPDATE_MD POWERLEVEL MARK DEVICE_RESET_LOCALLY HAIL
   room       ZWave
   vclasses   ASSOCIATION:2 ASSOCIATION_GRP_INFO:1 COLOR_CONTROL:1 CONFIGURATION:1 DEVICE_RESET_LOCALLY:1 FIRMWARE_UPDATE_MD:2 HAIL:1 MANUFACTURER_SPECIFIC:2 POWERLEVEL:1 SCENE_ACTIVATION:1 SCENE_ACTUATOR_CONF:1 SWITCH_ALL:1 SWITCH_MULTILEVEL:2 VERSION:2 ZWAVEPLUS_INFO:2
   webCmd     rgb

Bin verwirrt!?

[rudolfkoenig]

So reproduziert man den Bug richtig:
- als erstes die Detailseite eines Geraetes aufrufen, was Klassen in vclasses mit Version 0 fuehrt.
- danach fehlen (bis FHEM-Neustart) diese Befehle bei allen anderen Geraeten, auch wenn sie Version > 0 fuer diese Klasse, oder gar kein vclasses haben.

Habs gefixt und eingecheckt.
MARK hat z.Zt in FHEM keine Auswirkung auf die Befehle.

[krikan]

Danke fürs Suchen und Ausbessern.

MARK hat z.Zt in FHEM keine Auswirkung auf die Befehle.

Hatte ich auch irgendwann begriffen. Entscheidend ist nur, ob [class]:0 ist und nicht, ob die Klasse vor oder hinter MARK steht. War dann aber schon in den Tiefen der Device Class Specs, als Du das Problem schon gefunden hattest.

Meine (teilweise aufgefrischten) Erkenntnisse aus den Device Class Specs:

Laut Specs geben die DEVICE CLASSES des NIF die zwingend zu unterstützenden (supported) Command Classes vor (https://github.com/OpenZWave/open-zwave/blob/master/config/device_classes.xml). Auch die Pflicht-CC müssen laut Spec im NIF gemeldet werden.

FGRM222 hat kaputten NIF, da er als Generic Device = SWITCH_MULTILEVEL vorgibt, aber im NIF nicht die Pflicht-Command Class SWITCH_MULTILEVEL als supported (links von MARK) meldet.

Bei ozw fällt der kaputte NIF nicht auf und muss nicht über deren config-XML korrigiert werden, da ozw die Command Classes über die DEVICE CLASSES ermittelt und die Pflicht-CC SWITCH_MULTILEVEL als vorhanden voraussetzt. Die gemeldeten Command Classes werden in ozw nur berücksichtigt, wenn sie über die ohnehin vorhandenen Pflicht-CC laut DEVICE CLASS hinausgehen. "remove [cc]" in den config-XMLs von ozw entfernt eine Pflicht-CC als nicht vorhanden (nutzen wir bei uns richtigerweise nicht)

FHEM verlässt sich alleine auf die gemeldeten CC im NIF und berücksichtigt DEVICE CLASSES nicht. Laut Specs müsste das reichen; bis auf kaputte NIFs. FHEM fängt kaputte NIFs teilweise auf, indem auch CC rechts vom MARK als supported statt nur controlled berücksichtigt werden.

Ändern will ich am Vorgehen in FHEM nichts  . Text ist quasi ein Notizzettel..

[rudolfkoenig]

Die CCs nach MARK beschreiben, was ein Geraet von sich aus versenden kann, bei meiner KFOB ist das BASIC CENTRAL_SCENE SWITCH_MULTILEVEL SWITCH_ALL SCENE_ACTIVATION MULTI_CHANNEL. Gibt es einen "offiziellen" Weg (d.h. nicht config*) dem KFOB zu sagen, was er zum Dimmer schicken soll, also on, off oder dim75? Ich habe es bei mcaAdd vermutet, da sehe ich es aber nicht.

[krikan]

Gibt es einen "offiziellen" Weg (d.h. nicht config*) dem KFOB zu sagen, was er zum Dimmer schicken soll, also on, off oder dim75?

Kenne keinen, außer den nicht gewünschten config*.
Selbst die unterstützten Commands in den Assoziationsgruppen kann man erst bei ZWave+ über Class ASSOCIATION_GRP_INFO abrufen.

Evtl. kann man etwas mit den Szenenklassen erreichen, die Paetz als Vereinfachung von der beim KFOB nicht vorhandenen "Association Command Configuration Command Class" anführt und das mMn ermöglichen würde. Die Klassen habe ich mir aber noch nie näher angeschaut und sind vermutlich nur eine komplizierte Lösung für das einfache Problem.

[rudolfkoenig]

Laut Pepper gibt es 3 (4?) Geraete mit "Association Command Configuration", und ich habe eins von denen
Leider will/kann ich es nicht so recht zum experimentieren verwenden, ist naemlich verbaut

Ich frage mich, wieso nicht mehr Geraete diese Klasse implementieren.

[krikan]

Ich frage mich, wieso nicht mehr Geraete diese Klasse implementieren.

Paetz bietet in Abschnitt 4.3.3 die Begründung: Zu komplex im Namen, Implementierung und Nutzung. Als Ergebnis kaum Geräte mit der Klasse. 

@Andreas: Planst Du an der NOTIFICATION CLASS zu arbeiten?

[A.Harrenberg]

Hallo Christian,

@Andreas: Planst Du an der NOTIFICATION CLASS zu arbeiten?

mit Prio 2...

Ich habe eigentlich noch eine Baustelle bei SECURITY, da wollte ich noch einen Sicherheitstimer implementieren damit bei Problemen nicht immer die Nachrichten auf dem Stack liegenbleiben und dann alles "asynchron" abgearbeitet wird. Dabei ist mir aufgefallen das ich da an einer anderen Stelle einen Timer drin habe der bei Wake-Up Geräten versagt... Also zwei Baustellen.

Danach wollte ich dann aber die Notification Sachen implementieren. Falls Du da auch aktiv werden möchtest lasse ich Dir gerne den Vortritt, ich habe momentan so viel zu tun das ich zu nichts komme. Ich habe bisher nicht mal eure letzen Änderungen nachvollzogen und nächste Woche bin ich erst mal auf Dienstreise in China...

Gruß,
Andreas.

[krikan]

Hallo Andreas!
Wenn Du das irgendwann angehst, warte ich ab. Das hat keine Eile. Ich habe selbst noch genug andere, offene FHEM-Baustellen.
Gruß, Christian

[A.Harrenberg]

Hi Christian,

Wenn Du das irgendwann angehst, warte ich ab. Das hat keine Eile. Ich habe selbst noch genug andere, offene FHEM-Baustellen.

du bist in letzter zeit sowieso mit erstaunlich vielen Patches aktiv... ,-)

Da ich Ende Juni auch schon wieder in Urlaub fahre überlege ich mir momentan ob ich nicht Laptop. Dongle und zwei/drei Geräte mitnehme und im Urlaub abends ein wenig weitermache...
Im letzten Urlaub hatte ich mir ja die ganzen SECURITY Sachen rausgesucht und schon mal die Verschlüsselung offline programmiert.

Mal sehen,
Andreas.

[krikan]

du bist in letzter zeit sowieso mit erstaunlich vielen Patches aktiv

Das sind fast alles nur seit Monaten (eher Jahren) angekündigte Dinge (Controllerfunktionen, nodeInfo usw.), die ich teilweise bei mir schon mal eingebaut hatte und nur an den aktuellen Modulstand angepassen und erneut testen muss(te).

..und im Urlaub abends ein wenig weitermache...

Wenn es Spaß macht gerne, ansonsten ruhig an.


Benennungsschema bei Befehlen nach CC-Versionen:
Konsens ist jetzt, dass wir so benennen: dimWithDurationV2, dimWithDurationV3, dimWithDurationV4 usw. ?
Bin als Benutzer noch ein wenig irritiert, aber habe keinen besseren, einfacher handhabbaren Vorschlag.

[rudolfkoenig]

Konsens ist jetzt, dass wir so benennen: dimWithDurationV2, dimWithDurationV3, dimWithDurationV4 usw. ?

Ich sehe zwei Alternativen:
- gleicher Befehlsname, je nach Version mehr oder weniger optionale Parameter
- unterschiedliche Befehlsnamen.

Um Benutzer weniger zu verwirren, uns Supportaufwand zu sparen, und auch Frontend-Programmerern die Sache einfacher zu machen plaediere ich fuer unterschiedliche Befehlsnamen, es sei denn, jemand hat bessere Ideen. Also baw: dimWithDurationV2, dimWithDurationV3, dimWithDurationV4.

[A.Harrenberg]

Hallo,
so, ich melde mich auch mal wieder... Bin jetzt im Urlaub und habe mit der NOTIFICATION Klasse angefangen und schon gleich wieder ein paar Fragen/Anmerkungen.

Mit der Namensgebung für die verschiedenen Versionen kann ich mich anfreunden. Allerdings führt das Vorgehen dann nicht unbedingt zu kürzen Drop-Down-Befehlslisten, da man "alte" Versionen theoretisch auch noch anbieten muss um auch bei den Aufrufen Rückwärtskompatibel zu bleiben.

Mein AEOTEC Multisensor6 antwortet z.B. auf alarmGet bzw. NotificationGet in V1, V2 und V3 Syntax jeweils "passend" zu der Anfrage. Ob das im Einzelfall sinnvoll ist kann ich momentan nicht überblicken. Eigentlich würde ich dazu tendieren nur die höchste Verfügbare Version anzuzeigen, hierbei gäbe es allerdings ein "Update"-Problem...

Falls wir z.B. V1 und V2 implementieren und dann damit Geräte mit einer V3 betrieben werden, würde diese mit den V2-Befehlen in Makros etc. betrieben. Falls wir dann mal eine V3 implementieren, würde dem Gerät diese Befehle NICHT mehr zur Verfügung stehen, wodurch dann nichts mehr funktionieren würde...

Daher müssen wir wohl oder übel alle Versionen anzeigen, was dann den "max" Parameter in %zwave_classVersion überflüssig macht.

Schöner (aber auch aufwändiger) wäre es eigentlich das neue Konstrukt nur dafür zu nutzen Befehle auszublenden die von dem betreffenden Gerät nicht unterstützt werden und die Abwärts- oder auch Aufwärtskompatibilität durch aufwändiges Parsen in den Befehlen hinzubekommen. Das führt dann wie von Rudi schon gesagt auch zu einer relativ komplexen Befehlsbeschreibung mit "geschachtelt optionalen" Parametern etc...

Ich bin mir nicht mehr so ganz sicher, aber ich denke das ich das ansaztweise bei einigen der von mir implementierten Befehlen zwar bereits so gemacht habe, ich traue mich aber nicht zu sagen ob soetwas bei allen Versionen aller Klassen überhaupt funktionieren würde...

@Rudi: Wat' nu? V1,V2,V3 Befehle oder aufwändigeres Parsen und nur ein Befehl?

Grüße aus Frankreich,
Andreas.

[rudolfkoenig]

Nach Durchdenken deiner Argumente bin ich immer noch fuer die eindeutige  bzw. V1, V2, V3 (kurz V*) Variante, aber das erste V* wuerde ich weglassen, und wenn sinnvoll, das Befehl durch einen angepassten Namen kennzeichnen. Bei dim und dimWithDuration sind wir ja auch ohne V* ausgekommen. Wenn es anfaengt auszuarten (== Befehlsname zu lang) oder einem nichst Passendes einfaellt, dann haengen wir V* dran.

[A.Harrenberg]

Hallo Rudi,

ok, danke für die RM. Werde versuchen die Namensgebung so einzuhalten, wobei da konsequenterweise noch einige Befehlsklassen dementsprechend "nachgebessert" werden sollten...
Ich bin mir aber unschlüssig wie mit "bestehenden" Befehlen umgegangen werden soll. Ich gehe davon aus das die meisten eher V2 oder V3 implementieren. Wenn jetzt der "gleiche" Name ohne V* jetzt mit einem Mal nur noch V1-Stand hat wird das auch einiges kaputt machen...

Ein konkretes Beispiel dazu habe ich jetzt aber (noch) nicht greifbar.

Gruß,
Andreas.