[PATCH] neue Befehlsklassen

[A.Harrenberg]

Hallo Rudi,

im angehängten Patchfile habe ich im Zudammenhang mit dem Danalock mal ein paar neue Command Classes angelegt:

0x53 NETWORK_SCHEDULE (SCHEDULE), V1
0x8a TIME, V2
0x8b TIME_PARAMETERS, V1
0x62 DOOR_LOCK, V2
0x22 APPLICATION_STATUS, V1

Außerdem habe ich bei 0x63 USER_CODE einen Befehl/Report ergänzt und bei 0x72 MANUFACTURER_SPECIFIC eine Variante beim Parsen angelegt, da das DanaLock hier 2 Byte mehr sendet (oder sollte man besser in %zwave_deviceSpecial ablegen?)

Bei 0x53 NETWORK_SCHEDULE ist zwar das Format der Befehle und der Reports "bekannt", Details zu einzelnen Parameter sind aber noch offen. Hier wird sich einiges nur über Ausprobieren rausfinden lassen, wobei das DanaLock die Klasse zwar aktuell unterstützt, man das aber in Ermangelung von geeigneter Zusatzhardware momentan noch gar nicht nutzen kann.

Wäre nett wenn Du Dir das mal ansehen könntest und dann eincheckst, Doku ist auch angepasst...

Gruß,
 Andreas.

[rudolfkoenig]

Holla. Das war aber gross.

Habs mit Aenderungen (s.u) eingecheckt.
- auf 80 Zeichen umformatiert
- Kommentare, die das Gleiche beschreiben, wie der Code, entfernt.
- die auskommentierten door Kommandos entfernt.
- falls der set falsche Parameter hat (Benutzerfehler / vertipper), dann muss das nicht mit verbose 1 gelogt werden.
- das Format muss man (meist) bei parse nicht pruefen, es reicht wenn man die korrekte Laenge (die ersten zwei Punkte im parse hash) angibt. Unbekannte Laengen werden dann genauso gemeldet, wie die anderen unbekannten Nachrichten dieser Klasse. Das habe ich aber nicht angepasst, war zu faul zum Zaehlen, und ich kanns nicht testen.
- bin etwas erstaunt, dass du dem Benutzer bei doorLockConfiguration bit-Operationen zutraust, insb. da die Parameter dezimal sind, und nicht auf Plausibilitaet geprueft werden.

[A.Harrenberg]

Hi Rudi,

Holla. Das war aber gross.

ja, da hatte sich was "angesammelt"... Einzelne Klassen waren ja auch schon früher "fertig", aber die Doku fehlte noch. Daher ist das erst jetzt alles auf einmal gekommen.

- bin etwas erstaunt, dass du dem Benutzer bei doorLockConfiguration bit-Operationen zutraust, insb. da die Parameter dezimal sind, und nicht auf Plausibilitaet geprueft werden.

Ja, ist sicherlich "grenzwertig", als Alternative würde mir aber nur einfallen das der User dort 8bits (oder 2x4 bit) eingibt. Und auf Plausibilität kann ich da nicht prüfen, da scheinen alle Kombinationen zulässig zu sein.

Gruß,
 Andreas.

[rudolfkoenig]

Und auf Plausibilität kann ich da nicht prüfen

Naja, z.Zt kann man auch "Brot" eingeben.
Und bei der Pruefung auf <1 wuerde Brot auch eine derbe Warnung im Log produzieren.

[A.Harrenberg]

Hi Rudi,

Naja, z.Zt kann man auch "Brot" eingeben.
Und bei der Pruefung auf <1 wuerde Brot auch eine derbe Warnung im Log produzieren.

na ja, das trifft aber doch wohl auf eigentlich fast alle set mit Parameter zu...
Was schlägst Du vor? Sollen die Parameter einzeln per Regexp geprüft werden? Dann müsste ich mir Regexp erst mal etwas genauer anschauen, bevor ich da was erweitere.

Gruß,
 Andreas.

[rudolfkoenig]

na ja, das trifft aber doch wohl auf eigentlich fast alle set mit Parameter zu...

Ich bin der Ansicht, auf fast keine:

fhem> set as6 basicSet brot
Error: brot is not a decimal number

%s wird nicht geprueft, das ist eine Aufgabe der aufgerufenen Funktion.
Du koenntest ZWave_DoorLockConfigSet($hash,%d,%d,%d) probieren, spart einiges am Code.

[A.Harrenberg]

Hi,

stimmt, da die meisten parameter ja über %d dezimal definiert sind wird das vorher abgefangen.
Schau ich mir noch mal an und werde es dann wohl so ändern.

Danke,
 Andreas.

[A.Harrenberg]

Hi,

jetzt habe ich doch noch ein paar grundsätzliche Fragen zum "User-Interface"...

Bei doorLockConfigurationSet gibt es zur Zeit drei Parameter: operationType handles timeoutSeconds

Zum einen hat Rudi angemerkt das für "handles" Bitoperationen des Users benötigt werden, zum anderen ist die Ausgabe des entsprechenden Reports

Code: [Auswählen]

doorLockConfiguration:  mode: constant outsideHandles: 0001 insideHandles: 0001 timeoutSeconds: not_supportedd.h. dort gibt es zwei getrennt 4-bit Blöcke für outside und inside.

Desweiteren wird der operationType als "constant" oder "timed" ausgegeben, die Eingabe beim set ist aber momentan dezimal 1 (=constant) oder 2 (=timed).

Aus User-Sicht ist das eher unschön, aus Programmsicht einfacher... Wie weit macht es Sinn das ganze aneinander anzupassen, d.h. in diesem Beispiel die Ausgabe operationType als [constant|timed] und beim Set ebenfalls [constant|timed] und bei den Handles ebenfalls zwei 4-bit Eingabeblöcke zu definieren.

Das ganze hat dann den Nachteil das man es etwas aufwändiger parsen muss und würde so ziemlich jede meiner Funktionen betreffen...

Meinungen?

Gruß,
 Andreas.

[rudolfkoenig]

Vorschlag: mach es erstmal soweit fertig, dass bei Benutzerunfug eine verstaendliche Meldung kommt, und der Rest ist in der Doku. Wenn sich rausstellt, dass viele User anfangen deinen Code zu verwenden, und Schwierigkeiten haben, dann koennen wir in einem zweiten Durchgang noch nachbessern. Dann haben wir auch Erfahrung, wo die Probleme liegen.

[A.Harrenberg]

Hi Rudi,

also zumindest für die doorLockConfigurationSet habe ich das jetzt mal "userfreundlch" angepasst.

Eingabe des Modus als Wort [timed|constant], eingabe des Bitfelds getrennt als 2x4 bit. Parsing der Eingabe sollte relativ Wasserdicht sein...
Hinweise des User auf Commandref falls Format nicht eingehalten wird und die Doku ist auch angepasst.

Die anderen Funktionen schaue ich mir bei Gelegenheit dann auch noch mal an.

Gruß,
 Andreas.
[EDIT: habe noch einen kleinen Fehler entfernt, da das File aber als noch nicht heruntergeladen markiert war habe ich nur den Anhang hier ausgetauscht]

[rudolfkoenig]

Habs eingecheckt.

[A.Harrenberg]

Hi,

und noch 'ne kleine Änderung für doorLockConfigurationSet...
Danach ist aber erst mal Ruhe. (Hoffe ich...)

Gruß,
 Andreas.

[rudolfkoenig]

Habs eingecheckt.