Versionen der CommandClasses

[A.Harrenberg]

Hallo Rudi,

je weiter ich mich in die ganzen CommandClasses einarbeite um so mehr stosse ich auf Befehle die erst aber bestimmten Version der CC verfügbar sind, oder die ab einer Version zusätzliche Parameter/Optionen beherschen, bzw. sich Änderungen an der Bedeutung der Parameter ergeben.

Aus Nutzersicht fände ich beides dumm, immer die Befehle der höchsten Version die implementiert ist zu sehen um dann festzustellen das der Befehl vom eigenen Gerät nicht verstanden wird, oder neuere aus Kompatibilitätsgründen nicht angezeigt zu bekommen.

Hast Du hier einen Ansatz wie das Problem zu lösen wäre? Besonders die Befehle bei denen Paramter dazugekommen sind oder bei denen sich die Bedeutung von Bitfeldern geändert hat machen mir etwas Kopfschmerzen.

Any ideas?

Gruß,
Andreas.

[rudolfkoenig]

Das Thema is in FHEM ein Probem, obwohl nach meiner Wahrnehmung nicht sehr dringend.
Falls das nicht stimmt, bitte melden.

Man koennte es so loesen, dass in %zwave_class neben set/get zusaetzlich setVersion/getVersion mit Versionsnummer existiert, was nur dann angeboten wird, falls vclasses existiert ("get versionClassAll" automatisch beim Includieren absetzen?), und die Version vertraeglich ist. Diese Befehle wuerden die unversionierten Befehle ueberschreiben, falls beide gleich lauten. Beispiel:

Code Auswählen Erweitern

SWITCH_MULTILEVEL        => { id => '26',
    set   => { off  => "0100", ... },
    setVersion => {
        4 => { swmBeginUp => "0420", ... } },
...


[krikan]

Besonders die Befehle bei denen Paramter dazugekommen sind oder bei denen sich die Bedeutung von Bitfeldern geändert hat machen mir etwas Kopfschmerzen.

Hinzukommen von Parametern ist mir klar, aber dass sich Bitfelder ändern dürfte doch die Ausnahme sein. Andreas, hast Du Beispiele zu geänderten Bitfeldern gefunden? Mir fallen auch nach längerem Überlegen keine Beispiele ein. Würde es daher bisher auch noch als nicht dringend einstufen.

Btw: Versuche zwar http://www.fhemwiki.de/wiki/Z-Wave_Command_Classes hinsichtlich der Versionen zu kontrollieren, aber bin nicht sicher ob mir das gelingt. Rudi alleine bei Doku zu folgen war/ist schon schwierig, aber da ihr jetzt zu Zweit (erfreulicherweise) an den Modulen arbeitet, wird es "eng". Andreas, hast Du das auch noch im Blick oder verlagern wir das komplett ins Modul/commandref?

[A.Harrenberg]

Hi Rudi,

Das Thema is in FHEM ein Probem, obwohl nach meiner Wahrnehmung nicht sehr dringend.
Falls das nicht stimmt, bitte melden.

Man koennte es so loesen, dass in %zwave_class neben set/get zusaetzlich setVersion/getVersion mit Versionsnummer existiert, was nur dann angeboten wird, falls vclasses existiert ("get versionClassAll" automatisch beim Includieren absetzen?), und die Version vertraeglich ist. Diese Befehle wuerden die unversionierten Befehle ueberschreiben, falls beide gleich lauten. Beispiel:

Code Auswählen Erweitern

SWITCH_MULTILEVEL        => { id => '26',
    set   => { off  => "0100", ... },
    setVersion => {
        4 => { swmBeginUp => "0420", ... } },
...


dringend ist es nicht, aber für ein paar Sachen halt unschön...
Den Ansatz schaue ich mir Ende der Woche noch mal in Ruhe an, scheint aber ein machbarer Weg zu sein.

Gruß,
Andreas.

[A.Harrenberg]

Hi Christian,

Hinzukommen von Parametern ist mir klar, aber dass sich Bitfelder ändern dürfte doch die Ausnahme sein. Andreas, hast Du Beispiele zu geänderten Bitfeldern gefunden? Mir fallen auch nach längerem Überlegen keine Beispiele ein. Würde es daher bisher auch noch als nicht dringend einstufen.

z.B. gerade bei der Diskussion um SWITCH_MULTILEVEL das erste Bit in dem START_LEVEL_CHANGE, da sind INC/DEC als Bitmaske hinzugekommen. Vorher waren die beiden Bits "reserved". Weitere Beispiele müsste ich jetzt raussuchen, aber bei den Thermostatklassen sind in den verschiedenen Versionen ja auch weitere Mögliche Geräte hinzugekommen.

Es sind gefühlt maximal 10% der Klassen davon betroffen, aber es dürfte für Verwirrung sorgen wenn angezeigte Befehle nicht funktionieren.

Ich wäre dafür die die Versionsabfrage der Klasse standardmäßig nach der Inklusion auszulösen.

Gruß,
Andreas.

[A.Harrenberg]

Hi,

uups, zu früh abgeschickt...

Btw: Versuche zwar http://www.fhemwiki.de/wiki/Z-Wave_Command_Classes hinsichtlich der Versionen zu kontrollieren, aber bin nicht sicher ob mir das gelingt. Rudi alleine bei Doku zu folgen war/ist schon schwierig, aber da ihr jetzt zu Zweit (erfreulicherweise) an den Modulen arbeitet, wird es "eng". Andreas, hast Du das auch noch im Blick oder verlagern wir das komplett ins Modul/commandref?

jein, manchmal denke ich daran wenigstens meine neuen Klassen nachzutragen, manchmal aber auch nicht ,-(
Aber eine gute Erinnerung, ich schau am WE mal wie der Status bei den letzten Klassen ist die wir eingepflegt haben.

Gruß,
Andreas.

[krikan]

Ich wäre dafür die die Versionsabfrage der Klasse standardmäßig nach der Inklusion auszulösen.

Ja, fände ich grundsätzlich auch nicht schlecht. Frage mich, was nach der Inklusion über "init"& Co noch abfragbar ist ohne sich Probleme einzuhandeln. Fände nämlich nach Inklusion "get <device> configAll" und "get <device> associationAll" auch sinnvoll, um direkt einen Überblick über die wichtigen Werte zu erhalten.

Rudis vorgeschlagene "Versionsvariante" sieht relativ einfach aus. Nach längerem Grübeln ist das mit Sicherheit nicht schlecht. Ich hadere immer mit den Versionen der CC ALARM/NOTIFIACTION. Evtl. könnte man es so schön lösen.

Der Wiki-Hinweis war keine Aufforderung zur Mitarbeit , sondern tatsächlich von mir eher der Gedanke die Pflege der Versionen dort einzustellen. In der commandref steht jetzt schon einiges zu den Versionen gelistet. Müsste nur ausgebaut werden. Wenn zudem Rudis obige "Versionsvariante" kommt, dann steht alles im Code und in commandref. Wir könnten uns dann mMn die Wiki-Versionspflege sparen. Ist doppelt und fehleranfällig.

[rudolfkoenig]

1. Stimmt, dass wenn ein Geraet Version X der Klasse unterstuetzt, dann auch alle Versionen 1..(X-1) unterstuetzen muss?
2. Habt ihr fuer mich ein/zwei nette Beispiele, womit ich ueben kann? Daran denken: es sollten von FHEM versendbare Kommandos sein.

[krikan]

1. Stimmt, dass wenn ein Geraet Version X der Klasse unterstuetzt, dann auch alle Versionen 1..(X-1) unterstuetzen muss?

So interpretiere ich das auch wegen Rückwärtskompatibilität. Schau mal ins SDS* S.4ff.

[krikan]

2. Habt ihr fuer mich ein/zwei nette Beispiele, womit ich ueben kann? Daran denken: es sollten von FHEM versendbare Kommandos sein.

Mir sind die Anforderungen hinsichtlich "nett" nicht klar.
Brauchst Du die kompletten Byte-Codes für verschiedene Class-Versionen eines Befehl?
Sollen sich die Byte-Codes nach Möglichkeit in der Länge unterscheiden?
...

[krikan]

Vorschlag:

Class MULTILEVEL_SWITCH
set-Kommando:
V1: 2601xx -> xx=Value
V2: 2601xxyy -> xx=Value yy=Dimming Duration

Class ALARM:
report-Kommando:
V1: 7105xxyy -> xx=Alarm Type yy=Alarm Level
V2: 7105xxyyzz... -> wirklich abwärtskompatibel?

edit: Ergänzungen nach PC(WIN)-Problemen

[krikan]

Class ALARM:
report-Kommando:

V2: 7105xxyyzz... -> wirklich abwärtskompatibel?

Natürlich abwärtskompatibel und Aufbau haben wir. report-Kommando V2 hat folgenden Aufbau:
7105 danach 8 Byte:
xx: Alarm Type
yy: Alarm Level
AA: Source Node ID ??
BB: Alarm Status
CC: Alarm Type
DD: Alarm Event
EE: Number Event Parameter ??
FF: Event Parameter

Ob es nett genug ist, musst Du bitte beurteilen. Beschwerde erlaubt.

[krikan]

Auch, wenn vielleicht das report-Kommando nicht hierunter "Daran denken: es sollten von FHEM versendbare Kommandos sein." fällt, noch folgende Ergänzung:
Bei der Suche nach Erläuterungen zu den Bedeutungen der Source Node Id im Report V3 habe ich http://dz.prosyst.com/pdoc/mBS_SH_SDK_8.0/modules/zwave/api/driver/com/prosyst/mbs/services/zwave/commandclasses/CCAlarm.AlarmReport.html gefunden. Seite erklärt Bedeutung und Versionsunterschiede mMn gut verständlich; insbesondere mit den anderen bekannten Infos ist das für mich hilfreich.