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

[rudolfkoenig]

Ich glaube in diesem Fall waere dein Attributvorschlag die beste Loesung.

[krikan]

anbei der Zwischenstand der 10_ZWave.pm, noch ohne jede Dokumentation...

Anhängend Log vom ersten Test mit einem Popp Rauchmelder mit ALARM V5.
list (bitte nicht von modelId irritieren lassen, ist laut Popp ein Firmwarebug):

Code Auswählen Erweitern

Internals:
   DEF        e345c452 68
   IODev      ZWDongle_0
   LASTInputDev ZWDongle_0
   MSGCNT     23
   NAME       ZWave_SENSOR_NOTIFICATION_68
   NR         297
   STATE      off
   TYPE       ZWave
   ZWDongle_0_MSGCNT 23
   ZWDongle_0_RAWMSG 000400440b7105000000ff0102000000
   ZWDongle_0_TIME 2016-07-02 16:24:39
   homeId     e345c452
   isWakeUp
   lastMsgSent 1467469477.09108
   nodeIdHex  44
   timeToAck  2.263
   Readings:
     2016-07-02 16:24:39   alarm           Smoke: detected - Unknown Location, arg 000000
     2016-07-02 15:54:39   alarmEventSupported_HomeSecurity (3) Tampering - product covering removed
     2016-07-02 15:54:02   alarmEventSupported_Smoke (2) detected - Unknown Location
     2016-07-02 15:55:31   alarmEventSupported_System (1) hardware failure
     2016-07-02 15:53:10   alarmTypeSupported Smoke HomeSecurity System
     2016-07-02 15:52:55   basicReport     00
     2016-07-02 07:23:46   battery         100 %
     2016-06-11 16:03:10   model           Popp Solar Powered Outdoor Siren
     2016-06-11 16:03:10   modelConfig     popp/solar-siren.xml
     2016-06-11 16:03:10   modelId         0154-0004-0002
     2016-07-02 16:24:33   reportedState   off
     2016-07-02 16:24:33   state           off
     2016-07-02 16:24:39   transmit        OK
Attributes:
   IODev      ZWDongle_0
   classes    ZWAVEPLUS_INFO BASIC SWITCH_BINARY SENSOR_BINARY ALARM CONFIGURATION ASSOCIATION BATTERY FIRMWARE_UPDATE_MD DEVICE_RESET_LOCALLY ASSOCIATION_GRP_INFO POWERLEVEL VERSION MANUFACTURER_SPECIFIC MARK BASIC
   room       ZWave
   vclasses   ALARM:5 ASSOCIATION:2 ASSOCIATION_GRP_INFO:1 BASIC:1 CONFIGURATION:1 DEVICE_RESET_LOCALLY:1 FIRMWARE_UPDATE_MD:3 MANUFACTURER_SPECIFIC:2 POWERLEVEL:1 SENSOR_BINARY:2 SWITCH_BINARY:1 VERSION:2 ZWAVEPLUS_INFO:2

Interessanterweise hat das Ein-/Ausschalten der Notifications-Events auch bei Smoke eine Auswirkung; zumindest sind die Rückgaben von get alarmWithTypeEvent andere. Bei manueller Sirenenauslösung erkenne ich keinen Unterschied in den Events. Smoke kann will ich nicht testen  .

Der Sensor hat 3 AlarmTypen. Und ich hätte gerne in der geänderten Fassung pro Alarm ein Reading. Aber das scheint ja schon beschlossen zu sein.

Philio PST02 - Tests kommen später.

[rudolfkoenig]

Statt alarmEventSupported_HomeSecurity bitte alarm_HomeSecurity, usw.

Und ich hätte gerne in der geänderten Fassung pro Alarm ein Reading. Aber das scheint ja schon beschlossen zu sein.

Ich bin noch bei "per Benutzer schaltbares Attribut"... Laut Zeitstempel ist das ja auch implementiert, sonst haette alarm den gleichen Zeitstempel, wie einer der alarmEvent*

[krikan]

Statt alarmEventSupported_HomeSecurity bitte alarm_HomeSecurity, usw.
Ich bin noch bei "per Benutzer schaltbares Attribut"... Laut Zeitstempel ist das ja auch implementiert, sonst haette alarm den gleichen Zeitstempel, wie einer der alarmEvent*

Das sind nicht die Alarme selbst (tauchen noch nicht auf), sondern die Angabe der unterstützten Alarmevents für einen bestimmten Alarmtyp.
Wird vielleicht beim Philio einleuchtender:
Alarmtyp "AccessControl" hat dort die möglichen Events:

Code Auswählen Erweitern

alarmEventSupported_AccessControl              (22) Window/Door is open, (23) Window/Door is closed

Ich grübel noch über ein super Argument für einen radikalen Schnitt. Die Zweigleisigkeit kriegt man doch nie mehr weg und ich befürchte Verwirrung. Oder soll das Attribut bei Neuanlagen von Devices per autocreate Standard werden?

[rudolfkoenig]

Das sind nicht die Alarme selbst (tauchen noch nicht auf), sondern die Angabe der unterstützten Alarmevents für einen bestimmten Alarmtyp.

Ach so. Seufz. Ich haette gerne eine Vereinfachung: wenn ich schon verwirrt werde, dann wird ein Anfaenger, der FHEM/Zwave/Geraet zum ersten mal sieht, bestimmt auch sein.

Was haltet ihr davon, diese Daten nicht zu speichern, also keine Readings dafuer anzubieten.
"get device alarmSupported" (oder so) darf alles erzaehlen, speichert aber nichts.

[krikan]

Hier das Log mit Experimenten mit dem Philio.

list:

Code Auswählen Erweitern

Internals:
   DEF        e345c452 74
   IODev      ZWDongle_0
   LASTInputDev ZWDongle_0
   MSGCNT     308
   NAME       ZWave_SENSOR_NOTIFICATION_74
   NR         304
   STATE      TRANSMIT_NO_ACK
   TYPE       ZWave
   ZWDongle_0_MSGCNT 308
   ZWDongle_0_RAWMSG 0004004a1e8f010403800364097105000000ff0708000531050301100631050122011d
   ZWDongle_0_TIME 2016-07-02 20:10:29
   homeId     e345c452
   isWakeUp   1
   lastMsgSent 1467482504.3098
   nodeIdHex  4a
   timeToAck  2.032
   Readings:
     2016-07-02 17:06:15   CMD             ZW_APPLICATION_UPDATE
     2016-07-02 20:10:29   alarm           HomeSecurity: Motion Detection - Unknown Location, arg 00
     2016-07-02 19:52:14   alarmEventSupported_AccessControl (22) Window/Door is open, (23) Window/Door is closed
     2016-07-02 19:52:14   alarmEventSupported_HomeSecurity (3) Tampering - product covering removed, (8) Motion Detection - Unknown Location
     2016-07-02 19:52:14   alarmTypeSupported AccessControl HomeSecurity
     2016-07-02 11:29:06   assocGroup_1    Max 8 Nodes ZWDongle_0
     2016-07-02 11:29:06   assocGroup_2    Max 8 Nodes
     2016-07-02 11:29:06   assocGroups     2
     2016-07-02 20:10:29   battery         100 %
     2016-07-02 20:10:29   luminance       16 %
     2016-07-02 11:27:12   model           Philio Technology Corporation PST02-A 4 in 1 Multi-Sensor
     2016-07-02 11:27:12   modelConfig     philio/pst02.xml
     2016-07-02 11:27:12   modelId         013c-0002-000c
     2016-07-02 11:29:14   state           TRANSMIT_NO_ACK
     2016-07-02 20:10:29   temperature     28.5 C
     2016-07-02 20:01:46   transmit        OK
     2016-07-02 20:01:44   wakeup          notification
Attributes:
   IODev      ZWDongle_0
   classes    ZWAVEPLUS_INFO BATTERY ALARM ASSOCIATION CONFIGURATION MANUFACTURER_SPECIFIC VERSION SENSOR_BINARY SENSOR_MULTILEVEL WAKE_UP ASSOCIATION_GRP_INFO POWERLEVEL DEVICE_RESET_LOCALLY MULTI_CMD SECURITY FIRMWARE_UPDATE_MD MARK BASIC
   room       ZWave
   vclasses   ALARM:4 ASSOCIATION:2 ASSOCIATION_GRP_INFO:1 BASIC:0 BATTERY:1 CONFIGURATION:1 DEVICE_RESET_LOCALLY:1 FIRMWARE_UPDATE_MD:2 MANUFACTURER_SPECIFIC:2 MULTI_CMD:1 POWERLEVEL:1 SECURITY:1 SENSOR_BINARY:2 SENSOR_MULTILEVEL:5 VERSION:2 WAKE_UP:2 ZWAVEPLUS_INFO:2

Ein-und Ausschalten der Alarmtypen funktioniert.
Hoffe, das Log hilft. Analysiert habe ich es selbst nicht. Wenn ich noch einmal mit bestimmten Befehlsreihenfolgen testen soll, bitte melden..

@Rudi:
Ob es weniger verwirrend ist, wenn get-Abfragen mal in Readings gespeichert werden und mal nicht, habe ich meine Zweifel.
Persönlich hätte ich das aber auch lieber in Readings. Ich kann mir sonst nicht merken, was ich bei einem bestimmten Gerät abfragen kann.
Bei WakeUp-Geräten müssten Vergessliche (ich) ohne Readings erst die supported-Abfrage stellen, wakeUpNotification abwarten, am Bildschirm nachschauen. Anschließend kann man erst die Abfrage machen..
Schon bei den ZWDongle-Befehlen (z.b. neigbhourUpdate) finde ich die fehlenden Ergebnis-Readings nicht ideal.
-> vielleicht sollten wir aber abwarten, was Andreas noch alles herausfindet.

[A.Harrenberg]

Hallo Christian,

zwei Punkte...

1.) der Event für Window/Door open/close 16/17 ist hex, Du müsstest das Dezimal eingeben -> 22/23, Du bekommst auf die Anfrage nach 16/17 immer 0xfe = unknown event als Antwort ,-)
Wenn Du also bitte noch mal get alarmWithTypeEvent 22 / 23 aufrufen könntest...

2.) Das Log von wimmelt von "unknown code" / "help me", soweit ich das erkennen kann ist das 0x8f MultiCMD. Hast Du eine Ahnung was da ist?

Gruß,
Andreas.

[krikan]

1.) der Event für Window/Door open/close 16/17 ist hex, Du müsstest das Dezimal eingeben -> 22/23, Du bekommst auf die Anfrage nach 16/17 immer 0xfe = unknown event als Antwort ,-)
Wenn Du also bitte noch mal get alarmWithTypeEvent 22 / 23 aufrufen könntest...

Hätte ich mal direkt gefragt!? Bei 22 und 23 kamen bei meinen Test immer "unknown notification type entered, see commandref" und der Befehl wird nicht abgesetzt. Darum dachte ich hex/dez-Konvertierungsproblem und habe 16/17 genommen. Damit ging es. Jetzt habe ich festgestellt: Ich kann genau einmal 22 und 23 abfragen und erst dann kommt "unknown notification type entered, see commandref". Nach dem nächsten "shutdown restart" habe ich wieder genau eine  Chance. Willst Du Dir das noch mal anschauen? Oder soll ich immer neu starten?

2.) Das Log von wimmelt von "unknown code" / "help me", soweit ich das erkennen kann ist das 0x8f MultiCMD. Hast Du eine Ahnung was da ist?

Nein. Die gibt es nur im geposteten Testzeitraum. Aktuell habe ich die auch nicht.

[krikan]

Neuer Tag:
FHEM ist seit dem Problem von gestern ohne Neustart durchgelaufen und heute morgen kann ich die Befehle problemlos absetzen.    Ergebnis hängt an. Bin aber angesichts des Problems von gestern etwas verunsichert.

[A.Harrenberg]

Hallo Christian,

Bei 22 und 23 kamen bei meinen Test immer "unknown notification type entered, see commandref" und der Befehl wird nicht abgesetzt. Darum dachte ich hex/dez-Konvertierungsproblem und habe 16/17 genommen. Damit ging es. Jetzt habe ich festgestellt: Ich kann genau einmal 22 und 23 abfragen und erst dann kommt "unknown notification type entered, see commandref".

die Meldung kommt aber von "alarmEventSupported"... Kann es sein das Du einfach die Parameter immer wieder in das Parameterfeld kopiert hast aber den falschen Befehl ausgewählt hast?

Falls nicht bin ich etwas ratlos was da jetzt schief geht...

Dann noch mal eine Frage an euch wegen der Syntax des V2-Get:alarmWithType und des V3-Get:alarmWithTypeEvent. Als erster Wert soll da der V1-Alarmtyp gesendet werden, bei nicht V1-Geräten soll da zwingend eine Null gesendet werden (meine Geräte scheinen aber auch andere Werte zu aktzeptieren bzw. zu ignorieren....)

Da es wahrscheinlich kaum noch V1 Geräte gibt wird wahrscheinlich niemand hier eine entsprechende V2/V3 Abfrage machen, zumal er dafür auch einfach den V1-Get Befehl "alarm" nehmen kann, die zusätzlichen Parameter würde das V1-Gerät ja sowieso ignorieren.

Soll ich den Parameter aus der Befehlszeile rausnehmen und einfach immer Null senden? Alternativ könnte ich auch prüfen ob der erste Parameter eine Zahl ist und die dann senden, d.h. der Befehl hätte einen optionalen ersten Parameter, das wäre beim Parsen etwas aufwändiger. Immer diese "sinnlose" Null voranzustellen ist irgendwie blöd...
Meinungen?

Gruß,
Andreas.

[krikan]

Kann es sein das Du einfach die Parameter immer wieder in das Parameterfeld kopiert hast aber den falschen Befehl ausgewählt hast?

Schließe ich eigentlich aus. Die "help me!" sind nun ja auch weg. Im Fazit: keine Ahnung und ich kann es nicht einmal auf Alkohol schieben  .

Reicht Dir das letzte Log? Oder brauchst Du mehr?

Soll ich den Parameter aus der Befehlszeile rausnehmen und einfach immer Null senden?

Würde ich persönlch ohne lange nachzudenken so machen.

[A.Harrenberg]

Hallo Christian,

Neuer Tag:
FHEM ist seit dem Problem von gestern ohne Neustart durchgelaufen und heute morgen kann ich die Befehle problemlos absetzen.    Ergebnis hängt an. Bin aber angesichts des Problems von gestern etwas verunsichert.

hmm, irgendwie wurde mir diese Nachricht heute mittag nicht angezeigt, wahrscheinlich ein Internetproblem, aber egal.

Tja, Deine Rückmeldungen für das Event Window/Door open bzw. close werden auch gleichlautend beantwortet. Damit scheint es nicht gewollt zu sein das man den aktuellen Status eines Alarms abfragt. Was angesicht der Tatsache das man das automatische Senden abschalten kann etwas merkwürdig erscheint.

Keine Ahnung wozu dann der Alarm-Get Befehl überhaupt gut sein soll, das einzige bisher sinnvolle in der Antwort ist der Notification Status.

Na ja, ZWave ist an einigen Stellen schon etwas merkwürdig designed...

Ich werde dann mal versuchen die Antwort so auszuwerten das sie mit der alten Ausgabe kompatibel ist und schau mal wie ich das mit dem Attribut eingebaut bekomme.
Die führende Null in der Abfrage werde ich dann auch weglassen und auch (erstmal) keinen optionale Parameter an der Stelle vorsehen.

Woher das merkwürdige Verhalten von Deinem System gestern gekommen ist würde mich ja schon interessieren, lässt sich aber wohl nicht mehr nachvollziehen.

Gruß,
Andreas.

[A.Harrenberg]

Hallo Rudi,

gäbe es eigentlich eine Methode ein Attribut nur in Abhängigkeit der Klasse anzulegen/anzuzeigen? Momentan wüsste ich jedenfalls nicht wie/wo ich das machen könnte,  d.h. das Attribut um einzelne alarm-Readings anzuzeigen würde dann bei allen Geräten auftauchen.

Falls das möglich wäre bin ich für einen Stupser in die richtige Richtung dankbar.

Gruß,
Andreas.

[rudolfkoenig]

Nicht das ich wuesste. Benutzer koennen sowas mit userattr, aber das von dem Modul zu verwenden ist nicht die feine Art. Ich bin dafuer, dass das Attribut immer sichtbar ist, und in der Doku beschrieben ist, in welchen Faellen es sinnvoll ist.

[A.Harrenberg]

Hallo Christian, hallo Rudi,

angehängt eine neue Version der 10_ZWave.pm.

Der erste Parameter (die "Null") bei dem Alarm-Get ist jetzt weg, der Alarmreport wird jetzt mit einer neuen Funktion geparst und kann unterschiedliche Readings anlegen. Hierzu gibt es das Attribut "extendedAlarmReadings"
0: wie bisher alles in "alarm"
1: einzelne Readings je Alarm_typ
2: beides...
Default ist die "0"

Das Format der Ausgabe bei "1" ist etwas anders, der Typ ist NICHT vorangestellt und es wird der Status der Notification angehängt.

@Christian: Bitte mal ausprobieren ob die Rückgaben noch "passen" oder ob ich das was durcheinander gebracht habe...

Gruß,
Andreas.

P.S.: Ich werde mich wegen Rückfahrt etc. dann jetzt wohl erst wieder nächste Woche melden können.

@Rudi: Wenn das so passt werde ich die Doku entsprechend anpassen und Dir dann demnächst mal ein Patch schicken. Das Problem mit der Reihenfolge und dem Exec-Init bei secure-Inklusion schaue ich mir danach an.