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

[A.Harrenberg]

Hallo Rudi,

mal wieder eine Frage die mit den verschiedenen Versionen der Befehlsklassen zusammenhängt.

Die CC 0x71 wurde mit der V3 von ALARM in NOTIFICATION umbenannt, momentan ist in FHEM nur V1 implementiert (get alarm und das Parsen des ALARM-Reports 0x7105 implementiert).

Hintergrund:
Das DanaLock Schloss hat mit einem Firmwareupdate die Meldung der aktuellen Position geändert. Früher konnte man das umkonfigurieren, entweder als Report in der DOOR_LOCK Klasse oder in der ALARM Klasse, beides wurde dann ohne weitere Konfiguration gesendet. Jetzt muss man aber anscheinend in der NOTIFICATION Klasse konfigurieren WAS man gemeldet haben möchte, ohne diese Konfiguration meldet das Ding rein gar nichts. Hier ist also ein Update der Klasse in FHEM gefragt.

Ich habe die Defintion bis V4, könnte also zumindest die Befehle implementieren. Hier stellt sich dann aber die Frage nach der Namensgebung, zum einen der Name der Klasse, zum anderen der Name der einzelnen Befehle.

Beispiel für 0x7104
V1: ALARM_GET, ein Parameter "Alarm Type"
V2: ALARM_GET, zwei Parameter "Alarm Type" und "ZWave Alarm Type"
V3/V4: NOTIFICATION_GET, drei Parameter "Alarm Type" und "ZWave Alarm Type" und "Event"

Beispiel für 0x7106
V1: n.V.
V2: ALARM_SET, zwei Parameter "ZWave Alarm Type" und "ZWave Alarm Status"
V3/V4: NOTIFICATION_SET, zwei Parameter "ZWave Alarm Type" und "ZWave Alarm Status"

Falls man die Klasse einfach in NOTIFICATION umbenennt passt das mit den bestehenden Einträgen in "classes/vclasses/secure_classes" nicht mehr, außerdem werden Leute verwirrt deren Geräte V1/V2 ist und die Beschreibung dort ALARM benennt.

Falls man ALARM belässt gilt das natürlich andersherum für Leute mit neuen Geräte ab V3, die finden dann NOTIFICATION nicht.

Die neuen Befehle ab V3 (falls vorhanden, so genau habe ich noch nicht geschaut) sollten mMn aber auf jeden Falls als "Notification" benannt werden. Bei den Befehlen dies es bereits in der V2 gab wird es aber wieder schwierig. Bestehende Installation/Skripte etc. bauen auf den Namen auf, was für den Erhalt von ALARM_GET spricht, für einen Nutzer mit V3=Notification ist aber schwer zu verstehen warum er ALARM_GET nutzen soll.

Hier stellt sich mal wieder die prinzipielle Frage wie FHEM mit den verschiendenen Versionen der Klassen umgeht. Meist sind die Klassen ja völlig abwärtskompatibel, aber wenn mein Gerät nur V1 unterstützt, in FHEM aber bis V4 implementiert ist, dann habe ich eine Menge Befehle im Dropdown zur Verfügung die nicht unterstützt sind...

Gruß,
Andreas.

[rudolfkoenig]

Ich habe den Versions-Task von meinem TODO Stapel von unten nach oben geholt, es wird trotzdem noch etwas dauern, da es eine groessere Aenderung bedeutet.

[A.Harrenberg]

Hi Rudi,

wie hast Du Dir das denn vorgestellt?

Gruß,
Andreas.

[rudolfkoenig]

Ja eben noch gar nicht

[A.Harrenberg]

Ok...

Ich habe mir auch noch keine wirklichen Gedanken gemacht, die groben Ideen die ich hatte würden schon einen ziemlichen Umbau bedeuten und das Problem das mal eine Klasse umbenannt wird habe ich noch gar nicht näher betrachtet...

Gruß,
Andreas.

[rudolfkoenig]

Habe was implementiert, die Aenderung ist kleiner/ungefaehrlicher als gedacht. Details:
- neues hash %zwave_classVersion, enthaelt min/max Eintraege fuer Befehle.
- bisher einziger Eintrag ist "dimWithDuration => { min => 2 }", wenn jemand von weiteren weiss, bitte melden.
- Falls ein Befehl nicht aufgefuehrt ist, dann steht es wie bisher zur Verfuegung, sonst (falls vclasses Eintrag fuer die Klasse vorhanden ist) muss die Version der Klasse groesser gleich min und (falls max vorhanden) kleiner gleich max sein.
- dieser Filter betrifft nur get und set. Wenn jemand der Ansicht ist, dass das auch parse betreffen soll, sollte gute Argumente ueberlegen
- wir koennten einfach Befehle fuer Version == 0 entfernen (betrifft die Klassen, die nach MARK kommen), bin aber unsicher, und ich meine wir haben uns mal dagegen entschieden.

Sonst: get versionClassAll wird ab sofort bei der Inklusion ausgefuehrt, um vclasses zu fuellen.
Hier koennte noch einiges schiefgehen, bitte testen.

[krikan]

- bisher einziger Eintrag ist "dimWithDuration => { min => 2 }", wenn jemand von weiteren weiss, bitte melden.

Code Auswählen Erweitern

"wakeupIntervalCapabilities => { min => 2 }"
"meterReset => { min => 2 }"
"meterSupported => { min => 2 }"

[krikan]

Code Auswählen Erweitern

"wakeupIntervalCapabilities => { min => 2 }"
"meterReset => { min => 2 }"
"meterSupported => { min => 2 }"

Ich hatte blöderweise beim vorigen Beitrag mit "edit" gearbeitet, so dass Du wohl was verpasst hast....
Mehr fällt mir nicht ein/auf.

Die zusätzlichen Bytes/Parameter bei einem Befehl in neueren Klassen-Versionen müssen nach Deinem Konzept in der zugehörigen, befehlsaufrufenden Unterfunktion kontrolliert werden!?

[rudolfkoenig]

Ich hatte blöderweise beim vorigen Beitrag mit "edit" gearbeitet, so dass Du wohl was verpasst hast....

In der Tat

Die zusätzlichen Bytes/Parameter bei einem Befehl in neueren Klassen-Versionen müssen nach Deinem Konzept in der zugehörigen, befehlsaufrufenden Unterfunktion kontrolliert werden!?

Ja. Lieber waere es mir unterschiedliche Befehlsnamen zu waehlen, notfalls mit V2 am Ende. Dann weiss man wenigstens, was genau man verwendet, Doku ist auch einfacher.

Steht es irgendwo, dass Klassen rueckwaertskompatibel sein muessen? Waere einfacher, und man koennte auf das optionale max in zwave_classVersion auch verzichten.

[krikan]

Steht es irgendwo, dass Klassen rueckwaertskompatibel sein muessen?

Ja, zumindest lese ich SDS Page 3+4 (PDF-Seite 15 und 16) so. Wenige Ausnahmen lassen sich aber sicherlich auch finden (bspw. MultiInstance).

[rudolfkoenig]

Danke. Ausnahme ist doof.

[krikan]

- wir koennten einfach Befehle fuer Version == 0 entfernen (betrifft die Klassen, die nach MARK kommen), bin aber unsicher, und ich meine wir haben uns mal dagegen entschieden.

War damals dagegen. Begründung war: bei kaputten NIFs fehlt fälschlicherweise eine Klasse evtl. vor dem MARK und die Angabe der Klasse danach rettet uns/Befehle.
Jetzt denke ich, dass wir es einfach probieren sollten; nur die Info über die gemeldeten Klassen nach MARK sollte mMn (irgendwo) erhalten bleiben.

Hier koennte noch einiges schiefgehen, bitte testen.

Getestet (ohne SECURITY) und kein Problem festgestellt.

[krikan]

War damals dagegen. Begründung war: bei kaputten NIFs fehlt fälschlicherweise eine Klasse evtl. vor dem MARK und die Angabe der Klasse danach rettet uns/Befehle.
Jetzt denke ich, dass wir es einfach probieren sollten; nur die Info über die gemeldeten Klassen nach MARK sollte mMn (irgendwo) erhalten bleiben.

ABER: Was passiert dann, wenn bei kaputten NIF eine Klasse manuell im Attribut classes ergänzt wird. versionClass meldet doch dann :0 ?

[rudolfkoenig]

Jetzt denke ich, dass wir es einfach probieren sollten

Ok, habs gemacht, notfalls drehen wir es zurueck. Die Liste der Befehle fuer mein KFOB ist deutlich sinnvoller geworden..

ABER: Was passiert dann, wenn bei kaputten NIF eine Klasse manuell im Attribut classes ergänzt wird. versionClass meldet doch dann :0 ?

Dann muss man vclasses aendern. Waere die erste Begruendug, warum vclasses Attribut ist

[krikan]

Bei meinen Devices mit SWITCH_MULTILEVEL fehlen im FHEMWEB-Auswahlmenü aktuell alle Befehle der Klasse.

list für FGRM222 als Beispiel:

Code Auswählen Erweitern

Internals:
   DEF        e345c452 4
   IODev      ZWDongle_0
   NAME       ZWave_SWITCH_MULTILEVEL_4
   NR         218
   STATE      Blind 95 Slat 0
   TYPE       ZWave
   homeId     e345c452
   nodeIdHex  04
   Readings:
     2016-05-25 21:58:13   SEND_DATA       failed:00
     2016-05-21 14:44:08   UNPARSED        MANUFACTURER_PROPRIETARY 0891010f2603030000
     2016-05-25 22:10:57   configReportsType BlindPositionReportsSentToThe1
     2016-06-01 19:41:10   energy          0.11 kWh
     2016-05-25 12:46:15   model           FIBARO System FGRM222 Roller Shutter Controller 2
     2016-05-25 12:46:15   modelConfig     fibaro/fgrm222.xml
     2016-05-25 12:46:15   modelId         010f-0301-1001
     2016-06-01 07:27:37   position        Blind 95 Slat 0
     2016-06-01 19:27:36   power           0.0 W
     2016-06-01 07:26:40   state           TRANSMIT_NO_ACK
     2016-06-01 07:26:40   transmit        NO_ACK
     2016-05-25 22:07:45   version         Lib 3 Prot 3.52 App 22.22
Attributes:
   IODev      ZWDongle_0
   classes    MANUFACTURER_SPECIFIC VERSION CONFIGURATION ASSOCIATION SWITCH_BINARY POWERLEVEL METER SENSOR_MULTILEVEL FIRMWARE_UPDATE_MD SWITCH_BINARY MANUFACTURER_PROPRIETARY PROTECTION MARK METER SENSOR_MULTILEVEL MANUFACTURER_PROPRIETARY SCENE_ACTIVATION SWITCH_MULTILEVEL SWITCH_BINARY BASIC
   event-on-change-reading .*
   room       ZWave
   stateFormat position
   vclasses   ASSOCIATION:2 BASIC:1 CONFIGURATION:1 FIRMWARE_UPDATE_MD:1 MANUFACTURER_PROPRIETARY:1 MANUFACTURER_SPECIFIC:1 METER:2 POWERLEVEL:1 PROTECTION:2 SCENE_ACTIVATION:1 SENSOR_MULTILEVEL:2 SWITCH_BINARY:1 SWITCH_MULTILEVEL:3 VERSION:1

Gleiches Problem bei Aktor mit SWITCH_MULTILEVEL:2.

Könnte das bitte jemand gegentesten? Danke.