2-Kanal UP Aktor gesucht

[krikan]

Vielleicht habe ich auch bei der Konfiguration etwas falsch gemacht? Nochmal alles auf Anfang??

Leider keine wirkliche Ahnung, sonst würde ich es Dir schreiben. Vielleicht muss man etwas mit MULTI_CHANNEL_ASSOCIATION sowie den Endpoints spielen. Aber Beides sind Themen mit denen ich mich bisher kaum praktisch beschäftigt habe.

Was sind das eigentlich für unbekannte Klassen bei dem Node?

Sollte dem hier entsprechen:
http://forum.fhem.de/index.php/topic,39525.msg318007.html#msg318007
Kannst Du ignorieren, dürfte eigentlich keine negativen Effekte haben.

[krikan]

@nightstorm99: Dei UNKOWN_xy Classes kannst Du eigentlich auch direkt aus dem Attribut Classes löschen

@Rudi: Hältst Du es für sinnvoll die UNKOWN_xy aus dem Attribut classes aufgrund der fehlenden Prüfung der Version von MULTI_CHANNEL/MULTI_INSTANCE automatisch durch Fhem zu löschen oder soll ich das besser im Wiki als Besonderheit aufnehmen? (Problem hatte ich hier im Thread http://forum.fhem.de/index.php/topic,39525.msg318007.html#msg318007 detaillierter beschrieben)

[rudolfkoenig]

Bin unentschlossen, ob wir lieber Anfaenger verwirren oder Erfahreneren Hinweise wegnehmen sollten, ich tendiere zum Letzteren, da die Hinweise sehr mager sind.

Wg. dem Link: verstehe ich es richtig, dass wir vor mcCapability die Version abfragen muessten, um die Antwort richtig zu deuten?

[krikan]

Bin unentschlossen, ob wir lieber Anfaenger verwirren oder Erfahreneren Hinweise wegnehmen sollten, ich tendiere zum Letzteren, da die Hinweise sehr mager sind.

Persönlich hätte ich lieber die UNKNOWN_xy. Ich befürchte auch, dass automatisches Entfernen bei Version 3 oder neueren zu Problemen führt.

Wg. dem Link: verstehe ich es richtig, dass wir vor mcCapability die Version abfragen muessten, um die Antwort richtig zu deuten?

Ja. Anhand der Nachrichtenlänge, die häufig der Anhaltspunkt ist, ist das mMn nicht zu unterscheiden. Es bleibt als nur Version.

Das geht auch wieder in diese Richtung: http://forum.fhem.de/index.php/topic,39810.0.html.
Ich wünsche mir häufig, dass das Device-list automatisch eine komplette Übersicht der Class-Versionen, Assoziationen und Configs enthält, wenn hier im Forum um Hilfe gebeten wird. Das würde manches vereinfachen und auch zu (meiner) ZWave-Wissensentwicklung beitragen.

Dann sind wir aber fast bei dem Thema "Interview" des Gerätes, was alle anderen ZWave-Programme machen. Ich sehe Fhem aber momentan im Vorteil, weil kein langandauerndes und fehleranfälliges Interview gemacht wird (hatte schon mal andere Meinung).

[rudolfkoenig]

Ich wünsche mir häufig, dass das Device-list automatisch eine komplette Übersicht der Class-Versionen, Assoziationen und Configs enthält, wenn hier im Forum um Hilfe gebeten wird.

Habe den ersten Schritt dafuer gemacht: "set DEVICE versionClassRequest" setzt das Attribut vclasses, siehe im Anhang die Werte fuer mein KFOB.

Weiterhin wird ab sofort set/get mit allen Parametern geloggt.

Bedeutender ist die wakeupNoMoreInformation Aenderung: wenn das Modul meint sowas schicken zu wollen, dann wird in 0.1s Intervallen geprueft, ob lastMsgTimestamp laenger als eine Sekunde zurueckliegt, und erst dann die wakeupNoMoreInformation Nachricht geschickt.
Damit kann ich vom KFOB alle Versionen problemlos abholen.
lastMsgTimestamp ist von Sekundengenauigkeit auf gettimeofday umgestellt (0.01msec auf meinem Rechner)

[krikan]

@Rudi:
Danke

Bzgl. MULTI_CHANNEL/MULTI_INSTANCE war ich gerade dabei Dir zu schreiben, dass meine Analyse vermutlich fehlerhaft war. Also das Thema bitte noch mal ruhen lassen. Danke

[krikan]

@Rudi
Die Funktion 0a für get-mcCapability gibt es in MULTI_INSTANCE/MULTI_CHANNEL V1 nicht. Die wurde erst mit V2 eingeführt. Meine Aussagen von http://forum.fhem.de/index.php/topic,39525.msg318007.html#msg318007 bezüglich V1 und mangelender Unterscheidbarkeit der Versionen sind also falsch.

Folge:
Die Auswertung des Rückgabewertes in sub ZWave_mcCapability($$) in 10_ZWave.pm ist mMn nicht optimal, da der von mir im Link dargestellte Aufbau für V2 korrekt sein sollte. In der sub werden bei Aufruf für ein existierendes Endpoint-Device die Werte für Generic/Specific als UNKOWN_xy zurückgegeben (=2 UNKOWN). Existiert das Endpoint-Device nicht, dann wird über DoTrigger $caps weitergereicht und das Endpoint-Device mit den Werten für Endpoint und Generic/Specific als UNKOWN_xy (3 UNKOWN) angelegt wird. Die UNKOWN_xy sollten eigentlich nie angelegt werden.
Mit ZWave_mcCapability($$) habe ich aber Verständnisprobleme, so dass ich befürchte, etwas nicht zu erkennen:

Code Auswählen Erweitern

my $lcaps = substr($caps, 2);
wird mMn zwar angelegt, aber nie genutzt. Warum? Überbleibsel?
Bei der Auswertung durch sub wird zudem das dynamic/identical Bit im hex-Wert für Endpoint nicht berücksichtigt/eliminert. Im Fazit nicht notwendig, nur stimmt dann die Endpoint-Nummer nicht mit der Doku überein.

[rudolfkoenig]

Die Doku zu MULTI_CHANNEL Capability Report sagt, dass es EndPoint,GenericClass,SpecificClass,Class1,Class2,usw. beinhaltet. Generic scheint immer 10 zu sein, Specific 1, damit ist aber wohl kein CommandClass gemeint.

Habe mit "get mcCapability" solange rumgespielt, bis ich zufrieden war, die ersten 2 Bytes werden jetzt nicht mehr als Klasse interpretiert.

[krikan]

GenericClass,SpecificClass kann man aus https://github.com/OpenZWave/open-zwave/blob/master/config/device_classes.xml entnehmen:
GenericClass = 10 = Binary Switch
SpecificClass = 01 = Binary Power Switch
OZW schließt aus den Generic/Specific auf Command Classes, die die Geräte haben müssen; sieht man auch in der verlinkten Datei. Da man die CommandClasses aus dem NIF lesen kann, ist mir der Sinn dieses Vorgehens unklar. Probleme wegen fehlender Command Classes in Fhem im Vergleich zu OZW sind mir bisher nicht aufgefallen.

Ist es notwendig, dass bei wakeupNoMoreInformation die CallbackIds fehlen und bei transmitOptions immer 05 statt 25 bzw. Attribut noExplorerFrames genutzt wird und bei "set DEVICE versionClassRequest" die CallbackIds fehlen? War bei wakeupNoMoreInformation vermutlich vorher auch schon so, ist mir nur nicht aufgefallen/durchgegangen .

[rudolfkoenig]

Na notwendig nicht, ich habe halt beim Umbau nicht darauf geachtet, das gleich mit umzustellen. Habe es jetzt fuer wakeupNoMoreInformation und ZWave_clockAdjust nachgeholt.

[krikan]

Danke! Sorry, schlechte Wortwahl; EF war auch noch meine Nicht-Beachtung und hast Du ja noch was gefunden.