Hallo Rudi,
in Thread "Popp Z-Wave+ Wall Plug Switch Schuko Inklusion Assoziation POPE009006" bin ich hier (http://forum.fhem.de/index.php/topic,40771.msg345617.html#msg345617) auf ein kleines Problem mit den command classes gestossen.
Das Gerät unterstützt unter SECURITY zusätzliche Klassen, die dazugehörigen Befehle werden natürlich nicht angezeigt, da die Befehlsliste ja auf den Einträgen im Attribut "classes" beruht.
Ich muss nun eigentlich nur die zusätzlichen Klassen in "classes" eintragen. Hier hätte ich aber mal ein Frage die sich mir auch früher schon mal gestellt hatte.
Die Klassen werden ja als Liste vom Gerät gesendet, es gibt da jedoch die Pseudoklasse "MARK". Die Einträge vor "MARK" sind die vom Gerät unterstützten Klassen, die Einträge nach "MARK" sind die Klassen welche das Gerät selbst steuern will.
Bei mir findet sich hinter MARK nur BASIC (was ja jedes Gerät eigentlich unterstützen soll), DEVICE_RESET_LOCALLY und HAIL. Es könnte aber mMn durchaus vorkommen das ein Gerät eine Klasse steuern will die es selbst nicht als Funktion anbietet. In diesem Fall würde FHEM trotzdem die Befehle anbieten, da die gesamte Liste betrachtet wird und nicht nur die Einträge vor "MARK".
Da dadurch evtl. Befehle angeboten werden die gar nicht unterstützt weden und die Klassen nach "MARK" mMn nur geparst werden müssen, bin ich der Meinung das man die Einträge hinter MARK entfernen sollte (also gar nicht erst anlegen sollte).
Das würde es mir auch einfacher machen die zusätzlichen Klassen nachzutragen. Momentan müsste ich nämlich bei beiden Einträgen feststellen ob MARK vorhanden ist und müsste dann korrekterweise die Einträge auch jeweils vor bzw. nach MARK anordnen.
Wie ist denn Deine Meinung dazu?
Gruß,
Andreas.
Auch, wenn ich nicht Rudi bin:
Das Problem, dass Anwender ueber angezeigte, aber nicht verfuegbare Befehle stolpern, ist hier mMn nie aufgetreten. Haeufiger jedoch, dass Classes nicht im Attribut classes vorhanden waren und die Anwender die Befehle vermissten und an der Einbindung scheiterten. Letzteres minimieren wir doch, indem wir alles nach MARK erhalten. Steht es nicht links (haeufig BASIC) rettet das die rechte Seite von MARK. Ja, das entspricht nicht der reinen Lehre.
Entscheidender aber ist mMn: Es gibt Geraete, bei denen ich auch die rechten Classes zwingend benoetige. Bspw. bei Fernbedienungen benoetigt man tlw. die steuernden Classes, um sie korrekt/vollstaendig mit Fhem nutzen zu können. Dazu muessrn auch die Classes rechts geparst werden.
Zudem haette ich gerne alle vom Geraet gelieferten Infos.
Wenn das alles durch eine Aufteilung auf 2 Attribute oder aehnliches sichergestellt werden kann, dann ist es Ok.
Hi Krikan,
Zitat von: krikan am 17 Oktober 2015, 16:24:14
Auch, wenn ich nicht Rudi bin:
Das Problem, dass Anwender ueber angezeigte, aber nicht verfuegbare Befehle stolpern, ist hier mMn nie aufgetreten. Haeufiger jedoch, dass Classes nicht im Attribut classes vorhanden waren und die Anwender die Befehle vermissten und an der Einbindung scheiterten. Letzteres minimieren wir doch, indem wir alles nach MARK erhalten. Steht es nicht links (haeufig BASIC) rettet das die rechte Seite von MARK. Ja, das entspricht nicht der reinen Lehre.
Entscheidender aber ist mMn: Es gibt Geraete, bei denen ich auch die rechten Classes zwingend benoetige. Bspw. bei Fernbedienungen benoetigt man tlw. die steuernden Classes, um sie korrekt/vollstaendig mit Fhem nutzen zu können. Dazu muessrn auch die Classes rechts geparst werden.
Um was für Klassen handelt es dich denn bei Dir? Bei mir taucht da neben BASIC nur HAIL und DEVICE_LOCALLY_RESET auf, beides Klassen für die anscheinend nur geparst wird und für die es keine Befehle gibt.
Welche Klassen tauchen den bei Dir nach MARK auf für die die Befehle der Klasse benötigst? Wenn das Gerät die Klasse nicht vor MARK als unterstützte Klasse meldet, aber trotzdem als Befehlsklasse unterstützt, ist das mMn ein Implementierungsfehler des Gerätes. (Und das Verhalten von FHEM wäre als workaround richtig)
Zitat von: krikan am 17 Oktober 2015, 16:24:14
Zudem haette ich gerne alle vom Geraet gelieferten Infos.
Wenn das alles durch eine Aufteilung auf 2 Attribute oder aehnliches sichergestellt werden kann, dann ist es Ok.
Hier habe ich meine Meinung mittlerweile auch geändert, zum einen stimme ich Dir zu das so viele Informationen wie möglich erhalten bleiben sollen, zum anderen würde es ein Kompatibilitätsproblem mit bereits bestehenden Einträgen verursachen.
Man könnte das Erstellen der Befehlsliste auf die Einträge vor MARK beschränken, wenn aber wie von Dir beschrieben auch Geräte im Umlauf gibt, die auch die Befehlsklasse für die Einträge nach MARK benötigen dann muss man es so lassen wie es jetzt ist.
Gruß,
Andreas.
Hallo Andreas,
es geht mir nicht im speziellen um meine Geraete. Geraete, die nicht alle Classes liefern, findest Du im Wiki. Meist wie geschrieben BASIC. Denke auch, dass die Geraete eine Macke haben. Letztlich bin ich aber nicht sicher, ob wir irgendeinen Teil der zwapi in dieser Hinsicht nicht kennen. Seit der Einbindung der Xml hat sich das Problem teilweise entschaerft.
Bei einigen Fernbedienungen braucht man aber zwingend die rechtem Classes, weil die Angaben links nicht auftauchen: basic, scene,.. Und das ist definitiv kein Fehler, da diese nur mit denn Classes steuern koennen und nicht gesteuert werden koennen. Das trifft tlw. auch auf andere Geraete zu.
Gruss, Christian
Hallo Krikan,
ich beginne zu begreifen wo der "Haken" ist...
Meiner Meinung nach benötigt man keine Befehlsklasse wenn das Gerät steuert, hier ist erst mal nur ein Parsen nötig, das geht auch ohne die Befehlsklasse. Aber das Gerät könnte nun z.B. einen Report/Antwort mittels eines Get-Befehls anfordern. Der EMPFANGENE Get kann geparst werdem. die Antwort würde dann aber per SET Befehl verschickt werden müssen, und das würde dann nicht gehen.
Ok, das kann ich erst mal so akezptieren. Das liegt dann an der Architektur.
Gruß,
Andreas.
Ok, und ich verstehe mehr von Deinem Anliegen ;). Ausblenden wuerde haeufig gehen, wenn alles auch set geparst wird. Jedoch befuerchte ich unnoetige Komplexitaet. Bisher hat sich auch niemand wirklich daran gestoert. Bleibt Rudis Entscheidung...
Hi Krikan,
wenn es so ist das über diese steuerndend Klassen z.B. Get-Befehle eintreffen die dann natürlich eine Antwort erfordern, dann MÜSSEN die Klassen natürlich drin bleiben. Um das "sauber" zu machen müsste man z.B. neben SET, GET und Parse noch sowas wie REPORT implementieren, also Befehle die von den Routinen in PARSE aufgerufen werden können um die Anworten zu senden. Diese würden dann nicht im Userinterface auftauchen und es würden auch keine SET- oder GET-Befehle angezeigt die evtl. gar nicht unterstützt werden.
Aber das ganze ich eher eine minimale Schönheitsfrage und mit den evtl. nötigen Antworten per SET ist es eigentlich keine Frage mehr, es sollte erst mal so bleiben wie es ist!
Gruß,
Andreas.
Danke fuer die Diskussion, und Argumente. Hat sich gelohnt abzuwarten, und nicht vorschnell zu reagieren. :)
Hi Rudi,
ja, hat sich für Dich gelohnt ,-)
Ich hatte übersehen das FHEM als "zu steuerndes Gerät" auch die SET-Befehle für evtl. Antworten benötigt. Also keine Änderungen.
Soll ich den Thread dann schliessen?
Gruß,
Andreas.
Zitat von: A.Harrenberg am 24 Oktober 2015, 09:35:25
Soll ich den Thread dann schliessen?
Persönlich finde ich es besser [gelöst] o.ä. im Betreff voranzustellen, als einen Thread zu schließen. Evtl. ergeben sich später noch neue Aspekte.
Gruß, Christian
Hi,
kurze Zusammenfassung des Ergebnisses:
Befehlsklassen nach der Pseudoklasse MARK werden weiterhin betrachtet. Diese Klassen werden vom Gerät gesteuert, hierzu kann es nötig sein das FHEM eine Antwort verschickt was nur mit einem SET-Befehl der entsprechenden Klasse möglich ist. Daher können diese Klassen nicht entfernt werden.
Gruß,
Andreas.