Implementation neuer Klassen -> extrem lange Readings nötig

[A.Harrenberg]

Hallo Rudi,

ich implementiere gerade ein paar weitere Klassen die im Zusammenhang mit dem Danalock stehen.

Das Ding unterstützt unter anderem die Klasse 0x53 NETWORK_SCHEDULE. Ich habe eine Definition der Befehle und der Reports die ich gerade implementiere, stehe aber ein wenig vor dem Problem das die Reports recht umfangreich sind und daher zu sehr langen Readings führen, zum anderen da sogar noch (nicht näher dokumentierte) Bitfelder drin sind, d.h. wenn die Bedeutung der Bits mal klar ist könnten die sogar noch länger werden wenn man die dekodiert ausgibt.

Akutell sieht z.B. das Reading für ein "SCHEDULE_SUPPORTED_REPORT" so aus: (das raw: ist noch für mich und würde ich dann später weglassen)

Code Auswählen Erweitern

raw:140f01630100 numSupported:20 startTimeSupport:001111 fallbackSupport:0 supportEnableDisable:0 numSupportedCC:1 supportedCC_1:99(USER_CODE) supportedCCmask_1:01 supportedOverrideTypes:0000000 overrideSupport:0

Das Bitfeld "startTimeSupport" könnten noch zu 6 Textmeldungen werden, ebenso "supportedOverride" zu 7. Die "supportedCC_x" und "supportedCCmask_x" Einträge sind in der Anzahl variabel ("numSupportedCC"), also auch hier könnte es noch mehr werden.

Die weiteren Reports der Klasse sehen auch nicht gerade kürzer aus, wobei es laut der Beschreibung zu COMMAND_SCHEDULE_REPORT sogar möglich zu sein scheint das dort mehrere Reports hintereinander ausgegeben werden, hier könnten also anscheinend sehr umfangreiche Ausgaben nötig sein.

Aktuell ist das Reading schon so lang das es in zwei Zeilen umgebrochen wird und dazu führt das ALLE Readings jetzt mit so hohen Zeilen ausgegeben werden, da anscheinend das Datumsfeld zweizeilig zusammengeschoben wurde.

Wie siehst Du das mit so langen Readings? Irgendwie müssen die Informationen ja in das Reading, und das mMn in einem "halbwegs" lesbarem Format. Ich würde die Namen der einzelnen Einträge auch nur ungerne in 2 oder 3 Buchstaben Abkürzungen "verschlüsseln"...

Ein anderes Problem sehe ich hier falls in Zukunft mal die Bitfelder dekodiert sind, dann würde sich ja das Reading ändern, was bei bestehenden Users evtl. zu Problemen führen könnte, je nachdem wie das Reading ausgewertet wurde. Wärest Du in so einem Fall für "Rückwärtskompatibilität" oder "alte Zöpfe abschneiden"?

Gruß,
Andreas.

[rudolfkoenig]

sehr langen Readings

Ich habe 10_ZWave.pm modifiziert, so dass die parse Eintraege eine Liste/Array zurueckliefern koennen, damit mehr als ein Reading auf einmal generiert werden kann. Z.Bsp kann die Funktion, die aus dem parse-Eintrag aufgerufen wird, folgendes zurueckliefern:

Code Auswählen Erweitern

  return ("Reading1:value1", "reading2:value2");

für "Rückwärtskompatibilität" oder "alte Zöpfe abschneiden"?

Bin fuer abschneiden, es sei denn die Aenderung betrifft sehr viele Benutzer, und die alte Version war jahrelang gueltig.

[A.Harrenberg]

Hi Rudi,

Ich habe 10_ZWave.pm modifiziert, so dass die parse Eintraege eine Liste/Array zurueckliefern koennen, damit mehr als ein Reading auf einmal generiert werden kann. Z.Bsp kann die Funktion, die aus dem parse-Eintrag aufgerufen wird, folgendes zurueckliefern:

Code Auswählen Erweitern

  return ("Reading1:value1", "reading2:value2");

ah, so eine Idee war mir auch schon gekommen z.B. für die "supportedCCs/supportedCCmask" eigene Readings anzulegen ,-)
Ich werde dann mal updaten und schauen wie es dann mit dieser Erweiterung funktioniert.

Bin fuer abschneiden, es sei denn die Aenderung betrifft sehr viele Benutzer, und die alte Version war jahrelang gueltig.

Da das ja jetzt SCHEDULE, TIME und TIMEPARAMETER bisher gar nicht implementiert waren und es bisher keine "Nachfrage" danach gab, werden es sicherlich auch nicht sooo viele Nutzer werden.

Gruß,
Andreas.

[A.Harrenberg]

Hi Rudi,

jetzt hätte ich aber doch mal ein paar Fragen...

Code Auswählen Erweitern

  return ("Reading1:value1", "reading2:value2");

a.) kann man da beliebig viele Readings angeben?
b.) wie löse ich das dann denn Programmtechnisch wenn die Anzahl der Readings die ich erzeugen will/muss nicht bekannt ist, sondern variabelö ist und  im Report vorgegeben ist?

Bei b.) stehe ich gerade ganz schön auf der Seife... Für die SCHEDULE Klasse werde ich mich wahrscheinlich zwar auch zwei Readings (eins für die normalen Reportdaten und eins für die darin enthaltenen CCs) beschränken, aber das ist ja ein grundsätzliches Problem.

Gruß,
Andreas.

[rudolfkoenig]

a.) "For all practical purposes": ja
b.) Aeh: Wie man ein Array fuellt (push/unshift/etc) will ich jetzt nicht in Detail erlaeutern, dazu gibt es Buecher. Und so'n Array kann man mit if/unless/etc auch konditional fuellen.

Nachrichten mit vielen Daten im Funkpaket wuerde ich mit mehreren Readings mit gleichem Praefix loesen, ist mAn besser lesbar. Vermutlich sind beide Extreme (ein Reading mit allen Parametern oder sehr viele Readings mit jeweils ein Parameter) nicht optimal. Obwohl ich im Zweifel eher fuers Letztere bin.

[A.Harrenberg]

Hi Rudi,

kann ich denn einfach ein Array zurückgeben und das wird dann zerlegt und abgearbeitet? Dann wäre es ja wirklich einfach ,-)

Gruß,
Andreas.

[rudolfkoenig]

Sicher. Hab mich wohl nicht sehr deutlich ausgedrueckt.

[A.Harrenberg]

Hi Rudi,

ok, mir war einfach nicht klar das ich ein Array übergeben kann und das dies gleichbedeutet ist mit durch Komma getrennten Strings.
Nach ein wenig nachdenken, ist das natürlich sonnenklar, die Parameter kommen ja immer als Array bei einer Funktion an.

Die Erklärung war schon deutlich genug, ich war nur vollkommen auf dem Holzweg ,-)

Danke,
Andreas.

[krikan]

Könntet ihr bitte hier http://forum.fhem.de/index.php/topic,45889.0.html rein schauen, ob es einen Zusammenhang gibt.
Danke, Christian

[A.Harrenberg]

Hi,

noch mal eine kleine "Strategiefrage"...

Wenn ich Reading habe das unter anderem zwei Parameter für Minuten und Sekunden hat, die aber auch jeweils "254 = not_supported" sein können, wie soll ich das am besten ausgeben/darstellen?

Einfach die 254 als Zahl ausgeben, oder als Text "not_supported"?

Falls so ein Reading mal jemand parsed ist es ja immer ärgerlich wenn man da Zahlen und Texte erwartet...

Ich würde in diesem Fall dazu neigen:
minutes:xx seconds:yy
auszugeben und dort ggf die 254 auszugeben.

Meinungen hierzu?

Gruß,
Andreas.

[rudolfkoenig]

Wenn du davon ausgehst, dass der Wert geplottet wird oder man via notify auf ein Schwellwert reagieren will, dann: Namen von Wert mit Leerzeichen trennen, und bei Sekunden belassen (nicht in minuten/sekunden umrechnen). Der FileLog/notify Regexp muesste zusaetzlich nach minute/sekunde/etc filtern um not_supported zu vermeiden.

Wenn die Nachricht nur fuer den Menschen als Info gedacht wird, dann kannst du gerne menschenfreundlich umrechnen.

254 in beiden Faellen als not_supported anzeigen.

[A.Harrenberg]

Wenn du davon ausgehst, dass der Wert geplottet wird oder man via notify auf ein Schwellwert reagieren will, dann: Namen von Wert mit Leerzeichen trennen, und bei Sekunden belassen (nicht in minuten/sekunden umrechnen). Der FileLog/notify Regexp muesste zusaetzlich nach minute/sekunde/etc filtern um not_supported zu vermeiden.

Wenn die Nachricht nur fuer den Menschen als Info gedacht wird, dann kannst du gerne menschenfreundlich umrechnen.

254 in beiden Faellen als not_supported anzeigen.

Hi,
wie sieht es denn mit Doppelpunkten hinter dem Namen aus? Für die Lesbarkeit finde ich das besser, gibt das Probleme beim Parsen?

Bei den Werten rechne ich das nicht in Minuten/Sekunden um, das kommt in der Nachricht als zwei getrennte Bytes an. Ich könnte das natürlich in Sekunden umrechnen, und bei dem entsprechenden  set auch als Sekunden entgegennehmen. In diesem Fall wird das eher nicht gesplittet werden, da es ja nur Einstellungen sind und keine Messwerte.

Ich bin mir auch nicht sicher ob ich dich bei dem not_supported richtig verstehe. Soll dann "not_supported" anstelle der Zahl ausgegeben werden oder nicht?

Gruß,
Andreas.

Gesendet von meinem LIFETAB_S785X mit Tapatalk

[rudolfkoenig]

wie sieht es denn mit Doppelpunkten hinter dem Namen aus?

Solange die Werte durch Leerzeichen getrennt sind, ist das egal. Es geht darum, dass bei notify du $EVTPARTn zur Verfuegung hast, und beim Plot/FileLog Spalte n, in beiden Faellen durch Leerzeichen getrennt.

Soll dann "not_supported" anstelle der Zahl ausgegeben werden

Ja.

[A.Harrenberg]

Hallo,

und noch mal ich... ,-)

Zahlen sollen dem Nutzer ja möglichst dezimal ausgegeben werden, das gleiche gilt dann ja umgekehrt auch für Eingaben bei set-Befehlen...

Ich habe jetzt aber hier ein Bitfeld in dem jedes Bit den Status für einen möglichen "DoorHandle" angibt. Soll das jetzt auch dezimal vom User angegeben werden oder wäre es nicht "schöner" das direkt als 0-1 Bitfeld eingeben zu können?

Irgendwie brauchen wir da mal eine "GUI-Guideline" ,-) um das in FHEM zu vereinheitlichen...

Gruß,
Andreas.

[rudolfkoenig]

Schoener ist eine Liste von lesbaren Werten, z.Bsp. Komma-getrennt. Ein Frontend-Widget gibt es auch schon dazu: uzsuSelect.

Das Problem einer perfekten Loesung ist, dass man haeufig gar nicht damit anfaengt, weil einem der Aufwand bewusst ist. Da sind mit nicht ganz so perfekte, aber vorhandene Loesungen lieber.

[A.Harrenberg]

Hi Rudi,

oje, UZSU sieht zwar schön aus, scheint aber auch etwas umfangreicher zu sein und hilft mir jetzt aber erst mal nicht weiter, das ganze muss ja auch z.B. auf der Kommandozeile laufen.
Irgendwie komme ich hier bei den einfachsten Sachen vom Hölzchen auf's Stöckchen...

Ich mach' das jetzt erst mal mit dezimalen Eingaben, wenn das dann erst mal läuft kann ich mir das UZSU immer noch anschauen...

Danke,
Andreas.

[rudolfkoenig]

Du hast angefangen

Btw. uzsu zu verwenden ist nicht kompliziert, man muss nur in zwave_cmdArgs

Code Auswählen Erweitern

deinBefehl => "uzsuSelect,option1,option2,option3"
eintragen.

[A.Harrenberg]

Hi Rudi,

Du hast angefangen

ich weiß, und ich bin noch nicht fertig...

Das Danalock unterstützt u.a. die Klasse APPLICATION_STATUS mit der eine Node eine Nachricht absetzen kann das der letzte Befehl "rejected" wurde. Das kann ich beim Schloss z.B. durch das Abrufen von User-ID außerhalb der gültigen Anzahl provozieren. Diese Nachricht wollte ich gerne im "state" ablegen, irgendwie fuktioniert das aber nicht...

Code Auswählen Erweitern

  APPLICATION_STATUS       => { id => '22',
    parse =>  { #"^032202(..)" => 'ZWave_applicationStatusParse($hash, $1)',
                "^03220200" => 'state:cmdRejected' }  },
Wenn ich die obere Zeile aktiviere wird die Funktion aufgerufen und sagt mir auch brav das da eine "00" angekommen ist. Wenn ich die zweite Zeile aktivieren wird kein Reading (egal ob ich jetzt "state" oder z.B. "applicationStatus:CmdRejected" angebe) angelegt oder aktualisiert, wobei die Funktion ja nichts anderes zurückgibt:

Code Auswählen Erweitern

return("state:CommandRejected") if ($arg eq "00");

Was mache ich jetzt schon wieder falsch?

Btw. uzsu zu verwenden ist nicht kompliziert, man muss nur in zwave_cmdArgs

Code Auswählen Erweitern

deinBefehl => "uzsuSelect,option1,option2,option3"
eintragen.

Ich habe mir das jetzt nur kurz angesehen, sieht hübsch aus, ich denke aber nicht das ich was davon nutzen kann/werde.

Gruß,
Andreas.

[rudolfkoenig]

Du verwendest eine 3 Tage alte 10_ZWave.pm, diesen Bug habe ich vorgestern gefixt.
Btw. ^ im Regexp ist ueberfluessig, da beim Pruefen ^ zusaetzlich hinzugefuegt wird.
Wundert mich, dass ^^nicht zu einem Fehler fuehrt.

[A.Harrenberg]

Hi Rudi,

Du verwendest eine 3 Tage alte 10_ZWave.pm, diesen Bug habe ich vorgestern gefixt.

ah, uraltes Model, wird schon gar nicht mehr hergestellt und Ersatzteile gibt es auch nicht mehr...

Ok, dann werde ich mal updaten und die "^" entfernen. Hab' schon gedacht das ich zu dumm bin vorhandene Zeilen zu kopieren und anzupassen.

Danke,
Andreas.