Befehl von Node an Controller

Begonnen von A.Harrenberg, 12 Januar 2016, 22:09:39

Vorheriges Thema - Nächstes Thema

A.Harrenberg

Hallo Rudi,

habe gerade mal wieder was neues entdeckt was mir bisher noch nicht aufgefallen war...
Das DanaLock hat eine interne Uhr und unterstützt dafür die Klassen 0x8a_TIME und 0x8b_TIME_PARAMETERS. (Das wusste ich schon)
Kurz nach der Inklusion fragt das Danalock nach einem TIME-Report vom Controller. (Das ist neu und mir erst jetzt aufgefallen)

D.h. ich müsste den Befehl den ich als GET beim Controller definiert habe jetzt auch in PARSE mit einer entsprechenden Funktion entgegennehmen und den Report von der Node, den ich in Parse dekodiere, dann als "SET" kodiert auch an die Node verschicken können...

In Security passiert das eigentlich auch so auch bei den Nonce, die kann die Node ja auch vom Controller per Befehl anfragen. Ist das bei anderen Klassen bisher auch schon mal aufgetaucht?

Dieses Verhalten stimmt aber irgendwie nicht mit meinem Verständnis der "classes" überein. Die Node sendet ja die Klassen die sie unterstützt, dann "MARK" und dann die Klassen die sie auch steuern kann/will. Hier würde ich ja eigentlich erwarten das dann TIME auch hinter "MARK" auftaucht, tut es aber nicht...  (Das trifft übrigens auch auf SECURITY auf, das habe ich auch noch nie hinter "MARK" gesehen)

Interessanterweise fragt das DanaLock hier aber auch gar nicht die Uhrzeit ab, sondern den Offset zu UTC, den DST-Offset und das Datum wann DST anfängt und aufhört. Woher das Ding die Uhrzeit bekommt ist mir nicht klar... Aber vielleicht fragt es erst danach wenn es diese Info bekommen hat.

Meine Frage ist jetzt, woher könnte FHEM diese Info bekommen, damit diese automatisch gesendet werden könnten oder soll es dem User überlassen werden die Daten per "SET" zu setzen?

Ich tendiere ehrlich gesagt zu letzterem. Allgemeine Attribute für die Zeitzone etc. einzuführen macht für diesen seltenen Einsatzfall kaum Sinn, eine automatische Berechnung für DST Anfang/Ende ist auch nicht so einfach, selbst die Zeitzone zu bestimmen könnte schwierig werden...

Wie siehst Du das?

Gruß,
Andreas.
FB 7360, Homematic und ZWave
Support for ZWave-SECURITY

rudolfkoenig

Wenn ich jetzt den Entwickler in mir ausser acht lasse, dann meine ich, dass FHEM diese Anfragen eigentlich korrekt beantworten muesste. Nachdem der Entwickler sich aber nicht so ohne weiteres ignorieren laesst, schlage ich vor, die entsprechenden GET Anfragen auch als PARSE anzulegen, und dem Benutzer zu ueberlassen, per notify eine Antowrt zu schicken.

Gedankengang: zwave_class muesste umgebaut werden, so dass get/set auch in parse beruecksichtigt wird, damit man das nicht doppelt anlegen muss.

A.Harrenberg

Hi Rudi
Zitat von: rudolfkoenig am 13 Januar 2016, 14:26:53
Wenn ich jetzt den Entwickler in mir ausser acht lasse, dann meine ich, dass FHEM diese Anfragen eigentlich korrekt beantworten muesste. Nachdem der Entwickler sich aber nicht so ohne weiteres ignorieren laesst, schlage ich vor, die entsprechenden GET Anfragen auch als PARSE anzulegen, und dem Benutzer zu ueberlassen, per notify eine Antowrt zu schicken.

Gedankengang: zwave_class muesste umgebaut werden, so dass get/set auch in parse beruecksichtigt wird, damit man das nicht doppelt anlegen muss.
ich fände es auch "schöner" und "richtiger" das automatisch zu beantworten, in dem konkreten Fall hätte ich aber keine Ahnung woher diese Daten kommen sollen (Offset Zeitzone, Offset DST, Startdatum/zeit DST, Enddatum/zeit DST). Zeitzone und Offset DST liessen sich ja vielleicht noch mit PERL-Boardmitteln ermitteln (ich hätte aber keine Ahnung wie), spätestens bei dem Datum für die DST-Umstellung wird es aber schwierig bis unmöglich. Das ist ja nun mal nicht konstant und der User müsste das sogar jährlich neu setzen. Um das dann automatisch als Antwort senden zu können müsste das z.B. als globales Attribut verfügbar sein. Könntest Du Dir vorstellen das als Attribute im Dongle mitzuführen?

Dann könnte man dem User sagen das er diese Attribute zu füllen hat. Die Anfrage von der Node könnte man automatisch mit diesen Werten füllen und den REPORT verschicken. Die Daten könnte man auch nutzen um den ebenfalls vorhandenen SET Befehl in einer zweiten Variante mit diesen Daten anstatt mit Usereingabe anzubieten.

Den Umbau von zwave_class verstehe ich aber nicht, man muss da doch auf jeden Fall zwei verschiedene Funktionen angeben... In dem Fall muss ich ja einen REPORT generieren, das ist eine neue Funktion, die bereits vorhandene EMPFÄNGT ja diesen REPORT nur.

Also in PARSE muss eine Funktion rein die so einen REPORT empfängt (die normale Implementierung der Klasse). Zusätzlich muss jetzt in PARSE eine Funktion rein die auf den GET-Befehl reagiert und eine Funktion aufruft die so einen REPORT erstellt (gibt es bei der normalen Implementierung der Klasse nicht...) und verschickt.

Um per notify auf diese Anfrage zu reagieren müsste dieser Befehl dann als ein zusätzlicher SET Befehl hier z.B. als set timeOffsetReport implementiert werden.

(Ich werde am WE das Danalock noch mal an ZWay anlernen und "schauen" ob der diese Anfrage beantwortet oder nicht.)

Gruß,
Andreas.

Wenn Du mit zusätzlichen Attributen für die TIME
FB 7360, Homematic und ZWave
Support for ZWave-SECURITY

rudolfkoenig

ZitatZeitzone und Offset DST liessen sich ja vielleicht noch mit PERL-Boardmitteln ermitteln (ich hätte aber keine Ahnung wie

Siehe fhemTzOffset in fhem.pl. Mit eine Schleife kreigt man auch Datum raus.
Ich bin dafuer, dass wir das erstmal "haendisch" implementieren mit einem kleinen HOWTO in der Wiki, das reicht um Erfahrung zu sammeln. Wenn es danach oefters benoetigt wird, dann kann man es automatisieren.

A.Harrenberg

Hi Rudi,
Zitat von: rudolfkoenig am 14 Januar 2016, 08:58:18
Siehe fhemTzOffset in fhem.pl. Mit eine Schleife kreigt man auch Datum raus.
Ich bin dafuer, dass wir das erstmal "haendisch" implementieren mit einem kleinen HOWTO in der Wiki, das reicht um Erfahrung zu sammeln. Wenn es danach oefters benoetigt wird, dann kann man es automatisieren.
händisch geht aber nicht wirklich. Entweder man beantwortet den GET-Befehl sofort oder gar nicht, da läuft ja in der Node auch ein Timer ab.

In diesem speziellen Fall könnte man den Befehl entgegennehmen und ein "Please set TimeOffset for <device>" im Log oder Frontend anzeigen und das im Wiki beschreiben.

Das fhemTzOffset schaue ich mir trotzdem mal an, wenn das nicht zu kompliziert ist da das Datum rauszubekommen probiere ich das mal aus. Mich interessiert eigentlich auch ob dann evtl. weitere GET-Befehle (z.B. nach der aktuellen Uhrzeit) kommen. Das kann ich mir aber mal mit ZWay anschauen falls die Anfrage dort beantwortet wird.

Gruß,
Andreas.
FB 7360, Homematic und ZWave
Support for ZWave-SECURITY

rudolfkoenig

Mit händisch meinte ich natuerlich ein notify.

A.Harrenberg

Hi,

aber das Notfiy muss ja eine Funktion haben die den REPORT zusammenbaut, und das ist nicht die Funktion für SET timeOffset, die würde ja mit einer falschen BefehlsID senden und ich bin mir jetzt nicht ganz sicher, das Format der Nachricht könnte sich auch in ein paar Bits unterscheiden.

Es müsste also in jedem Fall eine Funktion geschrieben werden die diesen Report erzeugt. Falls die Info für den REPORT einfach aus der fhemTzOffset zu generieren sind kann man das alles automatisch machen, falls nicht muss der Funktion in dem Notify dann die benötigten Parameter mitgegeben werden.

An der "extra" Funktion komme ich aber nicht vorbei.

Gruß,
Andreas.
FB 7360, Homematic und ZWave
Support for ZWave-SECURITY

A.Harrenberg

Hi,

habe mal als Antwort einfach eine vordefinierte Nachricht zurückgeschickt. Jetzt fragt das Ding auch nach der aktuellen Uhrzeit und dem Datum... Das Fragespiel geht also weiter ,-)

Hier müssen ja REPORTS gesendet werden, das wären dann zwar SET-Befehle, aber die sind ja eigentlich nicht für den User gedacht, sondern nur als Antwort auf die Anfrage und sollten eher nicht "unsolicited" versendet werden. Für den Quick&Dirty Test nutze ich natürlich eine neue SET-Funktion, die steht dann aber dem (unbedarften) User zur Verfügung...

In diesem Fall (TIME_OFFSET_REPORT) ist das sogar laut spezifikation in Ordnung, das Danalock piept jedesmal ganz zufrieden wenn ich das ungefragt schicke, ob das allerdings für alle Report gilt und ob das für den Enduser so sinnvoll ist wage ich allerdings zu bezweifeln.

Blöde Frage, wie kann ich denn eine Nachricht verschicken ohne die per IOWrite direkt an allen Stacks vorbei zu senden und ohne das der User diesen Befehl im Menü zu sehen bekommt?

Gruß,
Andreas.
FB 7360, Homematic und ZWave
Support for ZWave-SECURITY

rudolfkoenig

ZitatBlöde Frage, wie kann ich denn eine Nachricht verschicken ohne die per IOWrite direkt an allen Stacks vorbei zu senden und ohne das der User diesen Befehl im Menü zu sehen bekommt?

Ich bin zwar der Ansicht, dass es doch bloede Fragen gibt, diese gehoert aber sicher nicht dazu :)
So eine Methode gibts meines Wissens nicht. Ich schlage vor, die Befehle mit "Used internally" oder "For developers only" dokumentieren.
Wenn das auf die Dauer sich als unschoen/unpraktikabel erweist, dann muessen wir was Neues ueberlegen.