Implementation neuer Klassen -> extrem lange Readings nötig

Begonnen von A.Harrenberg, 16 Dezember 2015, 18:35:30

Vorheriges Thema - Nächstes Thema

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)
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.
FB 7360, Homematic und ZWave
Support for ZWave-SECURITY

rudolfkoenig

Zitatsehr 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:
  return ("Reading1:value1", "reading2:value2");

Zitat
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,
Zitat von: rudolfkoenig am 17 Dezember 2015, 17:08:41
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:
  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.

Zitat von: rudolfkoenig am 17 Dezember 2015, 17:08:41
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.

FB 7360, Homematic und ZWave
Support for ZWave-SECURITY

A.Harrenberg

Hi Rudi,

jetzt hätte ich aber doch mal ein paar Fragen...
Zitat von: rudolfkoenig am 17 Dezember 2015, 17:08:41
  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.
FB 7360, Homematic und ZWave
Support for ZWave-SECURITY

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.
FB 7360, Homematic und ZWave
Support for ZWave-SECURITY

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.
FB 7360, Homematic und ZWave
Support for ZWave-SECURITY

krikan


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.
FB 7360, Homematic und ZWave
Support for ZWave-SECURITY

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

Zitat von: rudolfkoenig am 19 Dezember 2015, 20:33:52
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

FB 7360, Homematic und ZWave
Support for ZWave-SECURITY

rudolfkoenig

Zitatwie 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.

ZitatSoll 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.
FB 7360, Homematic und ZWave
Support for ZWave-SECURITY

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.