Command Class umbenannt (ALARM -> NOTIFICATION), wie in FHEM anpassen?

A.Harrenberg · 29 Juni 2016, 20:53:39

Hallo,

so, ich habe da auch noch zwei kleine Problemchen bei der Implementierung der NOTIFICATION Klasse...

Ab V3 gibt es da 0x01 EventSupporteGet und 0x02 EventSupportedReport. Damit habe ich momentan 2 kleine Problemchen.

1.) Die "Beschreibung" der NOTIFICATION Klasse aus der Update-XML Datei stimmt anscheinend nicht... ,-(

Bei dem Get spezifiziert man den Notification Type (mit den Schlüsseln aus %zwave_alarmType), soweit so gut. Im Report ist das erste Byte dann (wieder) der Notification Type, im zweiten Byte ist u.a. die Anzahl der folgenden Bitmasken-Bytes enthalten. Laut der XML-Datei soll in den folgenden Bitmasken dann bitweise nochmals der Notification Type enthalten sein, was natürlich keinen Sinn macht. Die Reports von meinem AEOTEC Multisensor6 und von dem DanaLock belegen das auch recht deutlich, ansonsten müsste mein Mulitisensor Events für CO2 und Powermanagement generieren...

Ich denke das hier bitweise nur die möglichen Events aufgelistet sind, d.h. gesetztes Bit = entsprechender Event wird unterstützt.
Teilweise ist das in der PDF-Doku für Alarm V2 rauszulesen, da dort einige Events erklärt sind, die V2 aber noch keinen Befehl hatte um die unterstützten Events abzufragen.

@All: Hat jemand bessere/andere Informationen zur Notification Klasse V3 und V4? Eine recht umfängliche Liste von Events ist ja bereits in FHEM in %zwave_alarmEvent hinterlegt, woher stammt diese Liste?

2.) Die Bedeutung der Event Types ist aktuell bereits in %zwave_alarmEvent hinterlegt, die Strings dort enthalten aber Leerzeichen und jede Menge Sonderzeichen. Für die Ausgabe eines einzelnen Events mag das in Ordnung sein, aber wie gebe ich eine Liste von unterstützten Events in ein Reading vernünftig aus? Die Texte dort enthalten Klammern, Punkte, Kommas, Ausrufezeichen, Schrägstriche und Minuszeichen...

Als Lösung fällt mir hier nur ein, für jeden Event Typ ein eigenes numeriertes Reading (notificationEventSupported_01, notificationEventSupported_02, ...) zu erzeugen, für das Danalock wären das allerdings schon 10 Stück!

Gibt es bessere Vorschläge solche Datenwüsten in Readings zu bekommen?

Gruß,
Andreas.

krikan · 29 Juni 2016, 21:01:33

Zitat von: A.Harrenberg am 29 Juni 2016, 20:53:39
@All: Eine recht umfängliche Liste von Events ist ja bereits in FHEM in %zwave_alarmEvent hinterlegt, woher stammt diese Liste?

Hallo Andreas!
Liste kam mEn daher: http://220.135.186.178/zwave/example/
Hier http://dz.prosyst.com/pdoc/mBS_SH_SDK_8.1/modules/zwave/api/driver/index.html findest Du evtl. noch weitere Infos.
Rest schaue ich mir auch noch mal an. Kann Dir auf die Schnelle nicht folgen. Vielleicht helfen Dir die Links aber schon mal.
Gruß, Christian

krikan · 29 Juni 2016, 21:10:55

Evtl. hat z-way bei Deinem Razberry die aktuellst Liste der Events...

A.Harrenberg · 29 Juni 2016, 21:29:04

Hallo Christian,

Zitat von: krikan am 29 Juni 2016, 21:01:33
Liste kam mEn daher: http://220.135.186.178/zwave/example/

ok, danke, ja das passt soweit zu den Daten in FHEM.

Zitat von: krikan am 29 Juni 2016, 21:01:33
Hier http://dz.prosyst.com/pdoc/mBS_SH_SDK_8.1/modules/zwave/api/driver/index.html findest Du evtl. noch weitere Infos.

Uff, nee, diese "Erklärungen" verstehe ich nicht, und das was ich davon glaube zu vertehen passt nicht zu dem was ich hier habe und als Antwort von den Geräten sehe.

Aber mit den aus der Liste bereits hinterlegten Events passt das ja zu meiner Vermutung.

Zitat von: krikan am 29 Juni 2016, 21:01:33
Rest schaue ich mir auch noch mal an. Kann Dir auf die Schnelle nicht folgen. Vielleicht helfen Dir die Links aber schon mal.

Geht ja im wesentlichen darum wie ich die 10 unterstützten EventTypes des Danalock in ein/mehrere Reading(s) bekomme. Einfach aneinanderhängen macht wenig Sinn und ist durch die bereits verwendenten Satz- und Sonderzeichen auch nicht so einfach.

Mein Lösungsansatz wäre wie gesagt getrennte Readings für jeden unterstützten Eventtyp.

Gruß,
Andreas.

A.Harrenberg · 29 Juni 2016, 21:31:35

Hi,

Zitat von: krikan am 29 Juni 2016, 21:10:55
Evtl. hat z-way bei Deinem Razberry die aktuellst Liste der Events...

mein Razberry habe ich gerade nicht zur Hand... Hab' ja schon recht viel mit in Urlaub geschleppt...

Außerdem war ich da von den unterstützten Befehlen SEHR enttäuscht. Die können z.B. das Danalock auf- und zu machen, sonst GAR NICHTS. Keine Schedule, keine User, nix...

Gruß,
Andreas.

rudolfkoenig · 30 Juni 2016, 10:46:40

ZitatGibt es bessere Vorschläge solche Datenwüsten in Readings zu bekommen?

Vorschlag: Alle Kommas aus den Texten entfernen, und die einzelnen Werte durch Komma trennen. Die anderen Sonderzeichen sollten nicht stoeren, wer per Regexp nach bestimmten sucht, wird er diese auch so finden. Wir sollten vlt. diese Texte in der Doku erwaehnen, damit man weiss, was kommen kann.
Was ich noch nicht verstanden habe: wieso meldet dein Tueroeffner mehrere Alarm Events?

A.Harrenberg · 30 Juni 2016, 21:04:57

Hi Rudi,

ich habe aktuell bereits eine Version erstellt bei der ich verschiedene Reading nutze, bei denen ich die Schlüssel aus %zwave_alarmEvent an den Readingnamen angehängt habe. Soweit ich das verstehe könnte es nämlich durchaus ein Device geben das mehrere AlarmTypen unterstützt, dann gäbe es für jeden Alarmtyp eine eigene Liste von Events, das wäre mit "normalem" Numerieren nicht mehr so einfach machbar. Die Liste der unterstützten Eventtypen muss man für jeden AlarmTyp einzeln abfragen.
Beim Danalock sieht das dann im List so aus:

Code Auswählen


     2016-06-30 09:03:46   notificationEventSupported_0601 AccessControl: Manual Lock Operation 
     2016-06-30 09:03:46   notificationEventSupported_0602 AccessControl: Manual Unlock Operation 
     2016-06-30 09:03:46   notificationEventSupported_0603 AccessControl: RF Lock Operation 
     2016-06-30 09:03:46   notificationEventSupported_0604 AccessControl: RF Unlock Operation 
     2016-06-30 09:03:46   notificationEventSupported_0605 AccessControl: Keypad Lock Operation 
     2016-06-30 09:03:46   notificationEventSupported_0606 AccessControl: Keypad Unlock Operation 
     2016-06-30 09:03:46   notificationEventSupported_0609 AccessControl: Auto Lock Locked Operation 
     2016-06-30 09:03:46   notificationEventSupported_060b AccessControl: Lock Jammed 
     2016-06-30 09:03:46   notificationEventSupported_0610 AccessControl: Keypad temporary disabled 
     2016-06-30 09:03:46   notificationEventSupported_0614 AccessControl: Unlock By RF with invalid user code

bzw. beim AEOTEC Multisensor6

Code Auswählen

     2016-06-29 22:07:27   notificationEventSupported_0703 HomeSecurity: Tampering, product covering removed 
     2016-06-29 22:07:27   notificationEventSupported_0708 HomeSecurity: Motion Detection, Unknown Location

Wenn alles in "ein" Reading soll müsste das Reading den Namen des Alarmtyps angehängt bekommen (falls es mehrere geben sollte). Komma entfernen ist bei "detected, Unknown Location" etwas unschön, evtl. könnte man das in "detected - Unknown Location", ändern, dann würde es gehen. Insgesamt gibt es auch nicht so viele Texte mit Kommas.

Jetzt kannst Du als "Chef" mal entscheiden, die numerierten Readings so belassen oder alles in ein Reading wie von Dir vorgeschlagen. (Das umzubauen dürfte nicht wirklich aufwändig sein, daran soll es also nicht scheitern)

Zu Deiner Frage:
Also das DanaLock hat nur einen AlarmTyp, in dem Fall "AccessControl", für dieses Typ kann es aber je nach Event die EventTypen
0601, 0602, 0603, 0604, 0605, 0606, 0609, 060b, 0610, 0614 melden. (siehe oben)
Zum Beispiel 0601 = "Manual Lock Operation" bzw. 0602 Unlock bei manueller Betätigung, 0603 = "RF Lock Operation" bzw. 0604 Unlock bei Betätigung über Bluetooth oder ZWave.
Pro Event kommt natürlich immer nur eine Meldung.

Gruß,
Andreas.

A.Harrenberg · 30 Juni 2016, 22:49:21

Hi Rudi,

Code Auswählen

2016-06-30 22:43:41   notificationEventSupported_AccessControl Manual Lock Operation, Manual Unlock Operation, RF Lock Operation, RF Unlock Operation, Keypad Lock Operation, Keypad Unlock Operation, Auto Lock Locked Operation, Lock Jammed, Keypad temporary disabled, Unlock By RF with invalid user code

so sieht das ganze in einer Zeile aus, die Kommas (in anderen Typen) habe ich dort durch "-" ersetzt.

Um meine eigenen Frage zu beantworten, ich würde das jetzt so lassen...

Gruß,
Andreas.

rudolfkoenig · 01 Juli 2016, 08:51:35

Und jetzt habe ich es auch verstanden: du willst die Liste der vom Geraet potentiell gemeldeten Alarm-Texte in FHEM speichern. Ich finde das sollte in einem Reading gespeichert werden, und nicht in mehreren.

Ich wuerde das Reading in "alarm_eventsSupported" umbenennen, damit wir mit dem Klassennamen ALARM konsistent bleiben. Diesen Namen in NOTIFICATION umzubenennen wuerde vmtl. zusaetzlichen Aufwand / Verwirrung bedeuten, die ich bAw vermeiden will.

A.Harrenberg · 01 Juli 2016, 11:00:22

Hi Rudi,

Zitat von: rudolfkoenig am 01 Juli 2016, 08:51:35
Und jetzt habe ich es auch verstanden: du willst die Liste der vom Geraet potentiell gemeldeten Alarm-Texte in FHEM speichern. Ich finde das sollte in einem Reading gespeichert werden, und nicht in mehreren.

Yep, momentan sieht das jetzt so aus,

Code Auswählen

2016-06-30 22:56:55   notificationEventSupported_AccessControl (1) Manual Lock Operation, (2) Manual Unlock Operation, (3) RF Lock Operation, (4) RF Unlock Operation, (5) Keypad Lock Operation, (6) Keypad Unlock Operation, (9) Auto Lock Locked Operation, (11) Lock Jammed, (16) Keypad temporary disabled, (20) Unlock By RF with invalid user code

ich habe den Texten noch die Eventnummer in Klammern vorangestellt, da man diese Nummer braucht um den jeweiligen Alarm per GET abzufragen. Ich fände das besser als die Liste mit den Nummern in der Doku nachschauen zu müssen.

Momentan liefern meine beiden Testgeräte bei der Abfrage allerdings nie aktive Events zurück, das verstehe ich noch nicht wirklich, schaue ich mir weiter an.

Zitat von: rudolfkoenig am 01 Juli 2016, 08:51:35
Ich wuerde das Reading in "alarm_eventsSupported" umbenennen, damit wir mit dem Klassennamen ALARM konsistent bleiben. Diesen Namen in NOTIFICATION umzubenennen wuerde vmtl. zusaetzlichen Aufwand / Verwirrung bedeuten, die ich bAw vermeiden will.

Ja, aber... Damit sind wir jetzt zurück zur eigentlichen Frage des Threads.

Ich verstehe Deinen Einwand, allerdings ist es ebenso verwirrend für jemanden der die Beschreibung seines Gerätes liest und da was von Notification steht und er das in FHEM nicht "wiederfindet". Ich sehe allerdings auch das sicherlich eine ganze Reihe Tür-/Fenstersensoren und Bewegungsmelder aktuell mit "ALARM" laufen, auch wenn etliche davon bereits V3=NOTIFICATION sind -> Chaos wäre vorprogrammiert...

Wenn wir hier konsequent bei ALARM bleiben, müssen wir das in der Doku aber auch SEHR deutlich beschreiben. Idealerweise könnte man ja beim Inkludieren / vclasses-Aufruf auch eine Art Info-Requester öffnen ("for class NOTIFICATION please refer to class ALARM, see documentation for details") sobald da V3 oder größer existiert? Einen Abschnitt für NOTIFICATION der auf ALARM veweist sollte dann auch in der Doku auftauchen.

Ich fürchte mich jetzt schon ein wenig vor der Dokumentation der Klasse, die wird umfangreich werden...

Noch mal zurück zum Readingnamen, soll da wirklich ein "_" hinter alarm? Das ist sonst bei den anderen Reading auch nicht der Fall, oder? Ich würde "alarmEventsSupported_<alarmtype>" vorschlagen. Der Anhang mit dem alarmtyp ist mMn nötig um Geräte mit mehreren Funktionen zu handhaben.

Gruß,
Andreas.

rudolfkoenig · 01 Juli 2016, 11:13:25

Ok, kein Unterstrich. An dem Info-Requester muss ich mich noch gewoehnen

A.Harrenberg · 01 Juli 2016, 11:50:05

Hi Rudi,

Zitat von: rudolfkoenig am 01 Juli 2016, 11:13:25
Ok, kein Unterstrich. An dem Info-Requester muss ich mich noch gewoehnen

vielleicht reicht ja auch die Doku... Wir werden ja sehen ob/wie viele Nachfragen kommen.

Gruß,
Andreas.

A.Harrenberg · 01 Juli 2016, 17:01:58

Hallo Rudi,

ich brauch noch mal ein klein wenig Unterstützung beim Parsen des AlarmReports. Im Code ist auf den entsprechendenThread verwiesen, Beispiel Nachrichten sind z.B. hier.

Wenn ich diese Beispiele und die Nachrichten von meinen beiden Geräte nehme und das mit der Beschreibung der Klasse vergleiche gibt es da so einige Ungereimtheiten...

Meiner Meinung nach ist die V2-Nachricht in dem Link zu lang! V2 definiert zwar 8 Bytes, das 7.te ist jedoch die Länge der Eventparameter, und wenn die Länge 0 ist sollte das 8 Byte nicht gesendet werden. Das V4-Beispiel in dem Link ist meiner Meinung nach i.O.

Die Nachrichten von Christians Philio einige Beiträge später scheint mir ein richtiges Beispiel für eine V2 zu sein. Falls das Ding allerdings V3/V4 sein sollte würde das auch nicht mehr passen.

Bei meinen beiden Geräte sendet der Multisensor mMn richtig, Länge Eventparameter 0 -> es folgt nur noch ein Byte -> Sequencenumber (V3). Das DanaLock sendet hier (V3) mMn zu kurz, da kommt als Länge eine 0, dafür dann aber auch keine Sequencenumber mehr...

Im Übrigen senden meine Geräte genauso wie der Philo von Christian "vorne" keinen AlarmType/Level sondern nur 0000.

In ZWave_alarmParse hast Du ja bereits versucht dieses Chaos irgendwie zu lösen, allerdings verstehe ich bereits die ersten Zeilen nicht und denke das hier was nicht richtig ist.

Geparst wird die Nachricht mit (..)(..)(.*) und dann wird alarmParse damit aufgerufen.

Code Auswählen

  my ($t,$l,$r) = @_;

  if($t=="00" && $r && $r =~ m/^..(..)(..)/) { # Forum #35178
    $l = $1; $t = $2;
  }

  if(!$r || $r !~ m/......(..)(.*)/ || !$zwave_alarmType{$t}) { # V1 or unknown
    return "alarm_type_$t:level $l";
  }

Im ersten Ansatz landet damit V1_AlarmType in $1 und V1_Level in $2, was dann auch ausgegeben wird wenn die zweite Abfrage zuschlägt. In der ersten IF Abfrage ist aber denke ich was nicht richtig.

Du prüfst ob neben den beiden V1-Parameter (mindestens?) drei weitere Parameter vorhanden sind und weist dann $l dem zweiten Byte (aus $r -> 4. Byte der Nachricht) und $t dem dritten Byte zu. Laut dem XML (und meinen Experimenten) ist das zweite (vierte) Byte aber nur der Status der Notification (ob der Wert unsolicited gesendet wird oder nicht) und nicht der Level des entsprechenden AlarmTyps.

Kannst Du vielleicht noch mal einen Blick in den Code werfen und versuchen Dich daran zu erinnern wieso Du das so gemacht hast? Ist das jetzt ein Fehler oder verstehe ich den Code mal wieder nicht?

Gruß,
Andreas.

krikan · 01 Juli 2016, 17:33:39

Zitat von: A.Harrenberg am 01 Juli 2016, 17:01:58
Die Nachrichten von Christians Philio einige Beiträge später scheint mir ein richtiges Beispiel für eine V2 zu sein. Falls das Ding allerdings V3/V4 sein sollte würde das auch nicht mehr passen.

Das ist beim Philio V4 und passt nach meiner Interpretation der Datentelegramme auch:

Code Auswählen

00 00 00 ff 07 08 00

00: AlarmTypeV1
00: AlarmLevelV1
00: ZensorNetSourceId
ff: Status = 0xff AND 0xFF = on
07: HomeSecurity/Burglar
08: Motion Detection, Unkown Location
00: Length = 0x00 AND 0x1F = 00
Sequence = 0x00 AND 0x80 = 00

rudolfkoenig · 01 Juli 2016, 18:31:28

@Andreas: klingt so, dass nicht nur wir, sondern auch die Hersteller verwirrt waeren. Ich habe fuer V2+ $l (AlarmLevelV1) von dieser Stelle genommen, weil es "passend" war, und ich damit "Event cleared:XX" fuer V2+ behalten konnte (habe/hatte ja kein Spec). Nach deiner Theorie bzw. Doku gibt es fuer V2+ kein "Event cleared", und man sollte $l ignorieren. Da ich den Spec nicht kenne, habe mit deiner Theorie kein Problem.

@Christian: soll ich aus deinen Zeilen ein TODO rauslesen, oder nicht? Bin unsicher