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

[A.Harrenberg]

Hallo Rudi,

mal wieder eine Frage die mit den verschiedenen Versionen der Befehlsklassen zusammenhängt.

Die CC 0x71 wurde mit der V3 von ALARM in NOTIFICATION umbenannt, momentan ist in FHEM nur V1 implementiert (get alarm und das Parsen des ALARM-Reports 0x7105 implementiert).

Hintergrund:
Das DanaLock Schloss hat mit einem Firmwareupdate die Meldung der aktuellen Position geändert. Früher konnte man das umkonfigurieren, entweder als Report in der DOOR_LOCK Klasse oder in der ALARM Klasse, beides wurde dann ohne weitere Konfiguration gesendet. Jetzt muss man aber anscheinend in der NOTIFICATION Klasse konfigurieren WAS man gemeldet haben möchte, ohne diese Konfiguration meldet das Ding rein gar nichts. Hier ist also ein Update der Klasse in FHEM gefragt.

Ich habe die Defintion bis V4, könnte also zumindest die Befehle implementieren. Hier stellt sich dann aber die Frage nach der Namensgebung, zum einen der Name der Klasse, zum anderen der Name der einzelnen Befehle.

Beispiel für 0x7104
V1: ALARM_GET, ein Parameter "Alarm Type"
V2: ALARM_GET, zwei Parameter "Alarm Type" und "ZWave Alarm Type"
V3/V4: NOTIFICATION_GET, drei Parameter "Alarm Type" und "ZWave Alarm Type" und "Event"

Beispiel für 0x7106
V1: n.V.
V2: ALARM_SET, zwei Parameter "ZWave Alarm Type" und "ZWave Alarm Status"
V3/V4: NOTIFICATION_SET, zwei Parameter "ZWave Alarm Type" und "ZWave Alarm Status"

Falls man die Klasse einfach in NOTIFICATION umbenennt passt das mit den bestehenden Einträgen in "classes/vclasses/secure_classes" nicht mehr, außerdem werden Leute verwirrt deren Geräte V1/V2 ist und die Beschreibung dort ALARM benennt.

Falls man ALARM belässt gilt das natürlich andersherum für Leute mit neuen Geräte ab V3, die finden dann NOTIFICATION nicht.

Die neuen Befehle ab V3 (falls vorhanden, so genau habe ich noch nicht geschaut) sollten mMn aber auf jeden Falls als "Notification" benannt werden. Bei den Befehlen dies es bereits in der V2 gab wird es aber wieder schwierig. Bestehende Installation/Skripte etc. bauen auf den Namen auf, was für den Erhalt von ALARM_GET spricht, für einen Nutzer mit V3=Notification ist aber schwer zu verstehen warum er ALARM_GET nutzen soll.

Hier stellt sich mal wieder die prinzipielle Frage wie FHEM mit den verschiendenen Versionen der Klassen umgeht. Meist sind die Klassen ja völlig abwärtskompatibel, aber wenn mein Gerät nur V1 unterstützt, in FHEM aber bis V4 implementiert ist, dann habe ich eine Menge Befehle im Dropdown zur Verfügung die nicht unterstützt sind...

Gruß,
Andreas.

[rudolfkoenig]

Ich habe den Versions-Task von meinem TODO Stapel von unten nach oben geholt, es wird trotzdem noch etwas dauern, da es eine groessere Aenderung bedeutet.

[A.Harrenberg]

Hi Rudi,

wie hast Du Dir das denn vorgestellt?

Gruß,
Andreas.

[rudolfkoenig]

Ja eben noch gar nicht

[A.Harrenberg]

Ok...

Ich habe mir auch noch keine wirklichen Gedanken gemacht, die groben Ideen die ich hatte würden schon einen ziemlichen Umbau bedeuten und das Problem das mal eine Klasse umbenannt wird habe ich noch gar nicht näher betrachtet...

Gruß,
Andreas.

[rudolfkoenig]

Habe was implementiert, die Aenderung ist kleiner/ungefaehrlicher als gedacht. Details:
- neues hash %zwave_classVersion, enthaelt min/max Eintraege fuer Befehle.
- bisher einziger Eintrag ist "dimWithDuration => { min => 2 }", wenn jemand von weiteren weiss, bitte melden.
- Falls ein Befehl nicht aufgefuehrt ist, dann steht es wie bisher zur Verfuegung, sonst (falls vclasses Eintrag fuer die Klasse vorhanden ist) muss die Version der Klasse groesser gleich min und (falls max vorhanden) kleiner gleich max sein.
- dieser Filter betrifft nur get und set. Wenn jemand der Ansicht ist, dass das auch parse betreffen soll, sollte gute Argumente ueberlegen
- wir koennten einfach Befehle fuer Version == 0 entfernen (betrifft die Klassen, die nach MARK kommen), bin aber unsicher, und ich meine wir haben uns mal dagegen entschieden.

Sonst: get versionClassAll wird ab sofort bei der Inklusion ausgefuehrt, um vclasses zu fuellen.
Hier koennte noch einiges schiefgehen, bitte testen.

[krikan]

- bisher einziger Eintrag ist "dimWithDuration => { min => 2 }", wenn jemand von weiteren weiss, bitte melden.

Code Auswählen Erweitern

"wakeupIntervalCapabilities => { min => 2 }"
"meterReset => { min => 2 }"
"meterSupported => { min => 2 }"

[krikan]

Code Auswählen Erweitern

"wakeupIntervalCapabilities => { min => 2 }"
"meterReset => { min => 2 }"
"meterSupported => { min => 2 }"

Ich hatte blöderweise beim vorigen Beitrag mit "edit" gearbeitet, so dass Du wohl was verpasst hast....
Mehr fällt mir nicht ein/auf.

Die zusätzlichen Bytes/Parameter bei einem Befehl in neueren Klassen-Versionen müssen nach Deinem Konzept in der zugehörigen, befehlsaufrufenden Unterfunktion kontrolliert werden!?

[rudolfkoenig]

Ich hatte blöderweise beim vorigen Beitrag mit "edit" gearbeitet, so dass Du wohl was verpasst hast....

In der Tat

Die zusätzlichen Bytes/Parameter bei einem Befehl in neueren Klassen-Versionen müssen nach Deinem Konzept in der zugehörigen, befehlsaufrufenden Unterfunktion kontrolliert werden!?

Ja. Lieber waere es mir unterschiedliche Befehlsnamen zu waehlen, notfalls mit V2 am Ende. Dann weiss man wenigstens, was genau man verwendet, Doku ist auch einfacher.

Steht es irgendwo, dass Klassen rueckwaertskompatibel sein muessen? Waere einfacher, und man koennte auf das optionale max in zwave_classVersion auch verzichten.

[krikan]

Steht es irgendwo, dass Klassen rueckwaertskompatibel sein muessen?

Ja, zumindest lese ich SDS Page 3+4 (PDF-Seite 15 und 16) so. Wenige Ausnahmen lassen sich aber sicherlich auch finden (bspw. MultiInstance).

[rudolfkoenig]

Danke. Ausnahme ist doof.

[krikan]

- wir koennten einfach Befehle fuer Version == 0 entfernen (betrifft die Klassen, die nach MARK kommen), bin aber unsicher, und ich meine wir haben uns mal dagegen entschieden.

War damals dagegen. Begründung war: bei kaputten NIFs fehlt fälschlicherweise eine Klasse evtl. vor dem MARK und die Angabe der Klasse danach rettet uns/Befehle.
Jetzt denke ich, dass wir es einfach probieren sollten; nur die Info über die gemeldeten Klassen nach MARK sollte mMn (irgendwo) erhalten bleiben.

Hier koennte noch einiges schiefgehen, bitte testen.

Getestet (ohne SECURITY) und kein Problem festgestellt.

[krikan]

War damals dagegen. Begründung war: bei kaputten NIFs fehlt fälschlicherweise eine Klasse evtl. vor dem MARK und die Angabe der Klasse danach rettet uns/Befehle.
Jetzt denke ich, dass wir es einfach probieren sollten; nur die Info über die gemeldeten Klassen nach MARK sollte mMn (irgendwo) erhalten bleiben.

ABER: Was passiert dann, wenn bei kaputten NIF eine Klasse manuell im Attribut classes ergänzt wird. versionClass meldet doch dann :0 ?

[rudolfkoenig]

Jetzt denke ich, dass wir es einfach probieren sollten

Ok, habs gemacht, notfalls drehen wir es zurueck. Die Liste der Befehle fuer mein KFOB ist deutlich sinnvoller geworden..

ABER: Was passiert dann, wenn bei kaputten NIF eine Klasse manuell im Attribut classes ergänzt wird. versionClass meldet doch dann :0 ?

Dann muss man vclasses aendern. Waere die erste Begruendug, warum vclasses Attribut ist

[krikan]

Bei meinen Devices mit SWITCH_MULTILEVEL fehlen im FHEMWEB-Auswahlmenü aktuell alle Befehle der Klasse.

list für FGRM222 als Beispiel:

Code Auswählen Erweitern

Internals:
   DEF        e345c452 4
   IODev      ZWDongle_0
   NAME       ZWave_SWITCH_MULTILEVEL_4
   NR         218
   STATE      Blind 95 Slat 0
   TYPE       ZWave
   homeId     e345c452
   nodeIdHex  04
   Readings:
     2016-05-25 21:58:13   SEND_DATA       failed:00
     2016-05-21 14:44:08   UNPARSED        MANUFACTURER_PROPRIETARY 0891010f2603030000
     2016-05-25 22:10:57   configReportsType BlindPositionReportsSentToThe1
     2016-06-01 19:41:10   energy          0.11 kWh
     2016-05-25 12:46:15   model           FIBARO System FGRM222 Roller Shutter Controller 2
     2016-05-25 12:46:15   modelConfig     fibaro/fgrm222.xml
     2016-05-25 12:46:15   modelId         010f-0301-1001
     2016-06-01 07:27:37   position        Blind 95 Slat 0
     2016-06-01 19:27:36   power           0.0 W
     2016-06-01 07:26:40   state           TRANSMIT_NO_ACK
     2016-06-01 07:26:40   transmit        NO_ACK
     2016-05-25 22:07:45   version         Lib 3 Prot 3.52 App 22.22
Attributes:
   IODev      ZWDongle_0
   classes    MANUFACTURER_SPECIFIC VERSION CONFIGURATION ASSOCIATION SWITCH_BINARY POWERLEVEL METER SENSOR_MULTILEVEL FIRMWARE_UPDATE_MD SWITCH_BINARY MANUFACTURER_PROPRIETARY PROTECTION MARK METER SENSOR_MULTILEVEL MANUFACTURER_PROPRIETARY SCENE_ACTIVATION SWITCH_MULTILEVEL SWITCH_BINARY BASIC
   event-on-change-reading .*
   room       ZWave
   stateFormat position
   vclasses   ASSOCIATION:2 BASIC:1 CONFIGURATION:1 FIRMWARE_UPDATE_MD:1 MANUFACTURER_PROPRIETARY:1 MANUFACTURER_SPECIFIC:1 METER:2 POWERLEVEL:1 PROTECTION:2 SCENE_ACTIVATION:1 SENSOR_MULTILEVEL:2 SWITCH_BINARY:1 SWITCH_MULTILEVEL:3 VERSION:1

Gleiches Problem bei Aktor mit SWITCH_MULTILEVEL:2.

Könnte das bitte jemand gegentesten? Danke.

[krikan]

Ist auch logisch, da SWITCH_MULTILEVEL im Beispiel FGRM222 nur rechts von MARK steht. Für mich kein Problem, da ich mit "position" steuere. Aber wie geht das bei denjenigen, die dim genutzt haben?

Hier steht die Klasse aber links von MARK und alle Befehle fehlen.

Code Auswählen Erweitern

Internals:
   DEF        e345c452 19
   IODev      ZWDongle_0
   NAME       ZWave_LED
   NR         228
   STATE      neighborUpdate
   TYPE       ZWave
   homeId     e345c452
   nodeIdHex  13
   Readings:
     2016-05-25 21:50:30   SEND_DATA       failed:00
     2016-05-21 20:18:54   assocGroupName_01 Lifeline
     2016-05-21 20:18:18   assocGroup_1    Max 5 Nodes ZWDongle_0
     2016-05-21 20:18:18   assocGroup_2    Max 5 Nodes
     2016-05-21 20:18:18   assocGroups     2
     2016-06-01 19:18:57   basicReport     63
     2016-05-21 20:22:38   ccStatus_00     00
     2016-05-21 20:22:16   ccStatus_01     ff
     2016-05-21 20:22:21   ccStatus_02     00
     2016-05-21 20:22:25   ccStatus_03     00
     2016-05-21 20:22:30   ccStatus_04     00
     2016-05-21 19:51:25   configColorIndexConfigurationWhenThe38 2271560481
     2016-05-21 19:51:30   configColorfulModeConfiguration 3840
     2016-05-21 19:51:30   configLockUnlockConfiguration Unlock
     2016-05-21 19:51:35   configSendNotificationsToAssociated80 Basic
     2016-05-21 19:51:36   configSendOutAReportWhenTheColorIs32 Disable
     2016-05-21 19:51:36   configUseExternalSwitchToChangesThe35 Enable
     2016-05-21 19:51:36   configUseExternalSwitchToTurnOnOffThe34 Disable
     2016-05-21 19:51:20   model           Aeotec LED Bulb
     2016-05-21 19:51:20   modelConfig     aeotec/ledbulb.xml
     2016-05-21 19:51:20   modelId         0086-0003-0062
     2016-06-01 19:53:33   neighborList    ZWDongle_0 ZWave_SWITCH_MULTILEVEL_4 ZWave_SWITCH_BINARY_6 ZWave_SWITCH_MULTILEVEL_26 ZWave_SWITCH_MULTILEVEL_27 ZWave_SENSOR_BINARY_47 ZWave_SENSOR_NOTIFICATION_49 ZWave_SWITCH_BINARY_62 ZWave_RM_Flur_EG ZWave_RM_Jan ZWave_RM_Flur ZWave_RM_Eltern ZWave_SWITCH_BINARY_70
     2016-06-01 19:53:18   state           neighborUpdate
     2016-06-01 20:08:24   transmit        OK
     2016-05-21 20:18:10   zwavePlusInfo   version:01 role:AlwaysOnSlave node:Z-Wave+Node installerIcon:0600 userIcon:0600
Attributes:
   IODev      ZWDongle_0
   classes    ZWAVEPLUS_INFO SWITCH_MULTILEVEL COLOR_CONTROL SWITCH_ALL SCENE_ACTUATOR_CONF SCENE_ACTIVATION CONFIGURATION ASSOCIATION_GRP_INFO ASSOCIATION MANUFACTURER_SPECIFIC VERSION FIRMWARE_UPDATE_MD POWERLEVEL MARK DEVICE_RESET_LOCALLY HAIL
   room       ZWave
   vclasses   ASSOCIATION:2 ASSOCIATION_GRP_INFO:1 COLOR_CONTROL:1 CONFIGURATION:1 DEVICE_RESET_LOCALLY:1 FIRMWARE_UPDATE_MD:2 HAIL:1 MANUFACTURER_SPECIFIC:2 POWERLEVEL:1 SCENE_ACTIVATION:1 SCENE_ACTUATOR_CONF:1 SWITCH_ALL:1 SWITCH_MULTILEVEL:2 VERSION:2 ZWAVEPLUS_INFO:2
   webCmd     rgb

Bin verwirrt!?

[rudolfkoenig]

So reproduziert man den Bug richtig:
- als erstes die Detailseite eines Geraetes aufrufen, was Klassen in vclasses mit Version 0 fuehrt.
- danach fehlen (bis FHEM-Neustart) diese Befehle bei allen anderen Geraeten, auch wenn sie Version > 0 fuer diese Klasse, oder gar kein vclasses haben.

Habs gefixt und eingecheckt.
MARK hat z.Zt in FHEM keine Auswirkung auf die Befehle.

[krikan]

Danke fürs Suchen und Ausbessern.

MARK hat z.Zt in FHEM keine Auswirkung auf die Befehle.

Hatte ich auch irgendwann begriffen. Entscheidend ist nur, ob [class]:0 ist und nicht, ob die Klasse vor oder hinter MARK steht. War dann aber schon in den Tiefen der Device Class Specs, als Du das Problem schon gefunden hattest.

Meine (teilweise aufgefrischten) Erkenntnisse aus den Device Class Specs:

Laut Specs geben die DEVICE CLASSES des NIF die zwingend zu unterstützenden (supported) Command Classes vor (https://github.com/OpenZWave/open-zwave/blob/master/config/device_classes.xml). Auch die Pflicht-CC müssen laut Spec im NIF gemeldet werden.

FGRM222 hat kaputten NIF, da er als Generic Device = SWITCH_MULTILEVEL vorgibt, aber im NIF nicht die Pflicht-Command Class SWITCH_MULTILEVEL als supported (links von MARK) meldet.

Bei ozw fällt der kaputte NIF nicht auf und muss nicht über deren config-XML korrigiert werden, da ozw die Command Classes über die DEVICE CLASSES ermittelt und die Pflicht-CC SWITCH_MULTILEVEL als vorhanden voraussetzt. Die gemeldeten Command Classes werden in ozw nur berücksichtigt, wenn sie über die ohnehin vorhandenen Pflicht-CC laut DEVICE CLASS hinausgehen. "remove [cc]" in den config-XMLs von ozw entfernt eine Pflicht-CC als nicht vorhanden (nutzen wir bei uns richtigerweise nicht)

FHEM verlässt sich alleine auf die gemeldeten CC im NIF und berücksichtigt DEVICE CLASSES nicht. Laut Specs müsste das reichen; bis auf kaputte NIFs. FHEM fängt kaputte NIFs teilweise auf, indem auch CC rechts vom MARK als supported statt nur controlled berücksichtigt werden.

Ändern will ich am Vorgehen in FHEM nichts  . Text ist quasi ein Notizzettel..

[rudolfkoenig]

Die CCs nach MARK beschreiben, was ein Geraet von sich aus versenden kann, bei meiner KFOB ist das BASIC CENTRAL_SCENE SWITCH_MULTILEVEL SWITCH_ALL SCENE_ACTIVATION MULTI_CHANNEL. Gibt es einen "offiziellen" Weg (d.h. nicht config*) dem KFOB zu sagen, was er zum Dimmer schicken soll, also on, off oder dim75? Ich habe es bei mcaAdd vermutet, da sehe ich es aber nicht.

[krikan]

Gibt es einen "offiziellen" Weg (d.h. nicht config*) dem KFOB zu sagen, was er zum Dimmer schicken soll, also on, off oder dim75?

Kenne keinen, außer den nicht gewünschten config*.
Selbst die unterstützten Commands in den Assoziationsgruppen kann man erst bei ZWave+ über Class ASSOCIATION_GRP_INFO abrufen.

Evtl. kann man etwas mit den Szenenklassen erreichen, die Paetz als Vereinfachung von der beim KFOB nicht vorhandenen "Association Command Configuration Command Class" anführt und das mMn ermöglichen würde. Die Klassen habe ich mir aber noch nie näher angeschaut und sind vermutlich nur eine komplizierte Lösung für das einfache Problem.

[rudolfkoenig]

Laut Pepper gibt es 3 (4?) Geraete mit "Association Command Configuration", und ich habe eins von denen
Leider will/kann ich es nicht so recht zum experimentieren verwenden, ist naemlich verbaut

Ich frage mich, wieso nicht mehr Geraete diese Klasse implementieren.

[krikan]

Ich frage mich, wieso nicht mehr Geraete diese Klasse implementieren.

Paetz bietet in Abschnitt 4.3.3 die Begründung: Zu komplex im Namen, Implementierung und Nutzung. Als Ergebnis kaum Geräte mit der Klasse. 

@Andreas: Planst Du an der NOTIFICATION CLASS zu arbeiten?

[A.Harrenberg]

Hallo Christian,

@Andreas: Planst Du an der NOTIFICATION CLASS zu arbeiten?

mit Prio 2...

Ich habe eigentlich noch eine Baustelle bei SECURITY, da wollte ich noch einen Sicherheitstimer implementieren damit bei Problemen nicht immer die Nachrichten auf dem Stack liegenbleiben und dann alles "asynchron" abgearbeitet wird. Dabei ist mir aufgefallen das ich da an einer anderen Stelle einen Timer drin habe der bei Wake-Up Geräten versagt... Also zwei Baustellen.

Danach wollte ich dann aber die Notification Sachen implementieren. Falls Du da auch aktiv werden möchtest lasse ich Dir gerne den Vortritt, ich habe momentan so viel zu tun das ich zu nichts komme. Ich habe bisher nicht mal eure letzen Änderungen nachvollzogen und nächste Woche bin ich erst mal auf Dienstreise in China...

Gruß,
Andreas.

[krikan]

Hallo Andreas!
Wenn Du das irgendwann angehst, warte ich ab. Das hat keine Eile. Ich habe selbst noch genug andere, offene FHEM-Baustellen.
Gruß, Christian

[A.Harrenberg]

Hi Christian,

Wenn Du das irgendwann angehst, warte ich ab. Das hat keine Eile. Ich habe selbst noch genug andere, offene FHEM-Baustellen.

du bist in letzter zeit sowieso mit erstaunlich vielen Patches aktiv... ,-)

Da ich Ende Juni auch schon wieder in Urlaub fahre überlege ich mir momentan ob ich nicht Laptop. Dongle und zwei/drei Geräte mitnehme und im Urlaub abends ein wenig weitermache...
Im letzten Urlaub hatte ich mir ja die ganzen SECURITY Sachen rausgesucht und schon mal die Verschlüsselung offline programmiert.

Mal sehen,
Andreas.

[krikan]

du bist in letzter zeit sowieso mit erstaunlich vielen Patches aktiv

Das sind fast alles nur seit Monaten (eher Jahren) angekündigte Dinge (Controllerfunktionen, nodeInfo usw.), die ich teilweise bei mir schon mal eingebaut hatte und nur an den aktuellen Modulstand angepassen und erneut testen muss(te).

..und im Urlaub abends ein wenig weitermache...

Wenn es Spaß macht gerne, ansonsten ruhig an.


Benennungsschema bei Befehlen nach CC-Versionen:
Konsens ist jetzt, dass wir so benennen: dimWithDurationV2, dimWithDurationV3, dimWithDurationV4 usw. ?
Bin als Benutzer noch ein wenig irritiert, aber habe keinen besseren, einfacher handhabbaren Vorschlag.

[rudolfkoenig]

Konsens ist jetzt, dass wir so benennen: dimWithDurationV2, dimWithDurationV3, dimWithDurationV4 usw. ?

Ich sehe zwei Alternativen:
- gleicher Befehlsname, je nach Version mehr oder weniger optionale Parameter
- unterschiedliche Befehlsnamen.

Um Benutzer weniger zu verwirren, uns Supportaufwand zu sparen, und auch Frontend-Programmerern die Sache einfacher zu machen plaediere ich fuer unterschiedliche Befehlsnamen, es sei denn, jemand hat bessere Ideen. Also baw: dimWithDurationV2, dimWithDurationV3, dimWithDurationV4.

[A.Harrenberg]

Hallo,
so, ich melde mich auch mal wieder... Bin jetzt im Urlaub und habe mit der NOTIFICATION Klasse angefangen und schon gleich wieder ein paar Fragen/Anmerkungen.

Mit der Namensgebung für die verschiedenen Versionen kann ich mich anfreunden. Allerdings führt das Vorgehen dann nicht unbedingt zu kürzen Drop-Down-Befehlslisten, da man "alte" Versionen theoretisch auch noch anbieten muss um auch bei den Aufrufen Rückwärtskompatibel zu bleiben.

Mein AEOTEC Multisensor6 antwortet z.B. auf alarmGet bzw. NotificationGet in V1, V2 und V3 Syntax jeweils "passend" zu der Anfrage. Ob das im Einzelfall sinnvoll ist kann ich momentan nicht überblicken. Eigentlich würde ich dazu tendieren nur die höchste Verfügbare Version anzuzeigen, hierbei gäbe es allerdings ein "Update"-Problem...

Falls wir z.B. V1 und V2 implementieren und dann damit Geräte mit einer V3 betrieben werden, würde diese mit den V2-Befehlen in Makros etc. betrieben. Falls wir dann mal eine V3 implementieren, würde dem Gerät diese Befehle NICHT mehr zur Verfügung stehen, wodurch dann nichts mehr funktionieren würde...

Daher müssen wir wohl oder übel alle Versionen anzeigen, was dann den "max" Parameter in %zwave_classVersion überflüssig macht.

Schöner (aber auch aufwändiger) wäre es eigentlich das neue Konstrukt nur dafür zu nutzen Befehle auszublenden die von dem betreffenden Gerät nicht unterstützt werden und die Abwärts- oder auch Aufwärtskompatibilität durch aufwändiges Parsen in den Befehlen hinzubekommen. Das führt dann wie von Rudi schon gesagt auch zu einer relativ komplexen Befehlsbeschreibung mit "geschachtelt optionalen" Parametern etc...

Ich bin mir nicht mehr so ganz sicher, aber ich denke das ich das ansaztweise bei einigen der von mir implementierten Befehlen zwar bereits so gemacht habe, ich traue mich aber nicht zu sagen ob soetwas bei allen Versionen aller Klassen überhaupt funktionieren würde...

@Rudi: Wat' nu? V1,V2,V3 Befehle oder aufwändigeres Parsen und nur ein Befehl?

Grüße aus Frankreich,
Andreas.

[rudolfkoenig]

Nach Durchdenken deiner Argumente bin ich immer noch fuer die eindeutige  bzw. V1, V2, V3 (kurz V*) Variante, aber das erste V* wuerde ich weglassen, und wenn sinnvoll, das Befehl durch einen angepassten Namen kennzeichnen. Bei dim und dimWithDuration sind wir ja auch ohne V* ausgekommen. Wenn es anfaengt auszuarten (== Befehlsname zu lang) oder einem nichst Passendes einfaellt, dann haengen wir V* dran.

[A.Harrenberg]

Hallo Rudi,

ok, danke für die RM. Werde versuchen die Namensgebung so einzuhalten, wobei da konsequenterweise noch einige Befehlsklassen dementsprechend "nachgebessert" werden sollten...
Ich bin mir aber unschlüssig wie mit "bestehenden" Befehlen umgegangen werden soll. Ich gehe davon aus das die meisten eher V2 oder V3 implementieren. Wenn jetzt der "gleiche" Name ohne V* jetzt mit einem Mal nur noch V1-Stand hat wird das auch einiges kaputt machen...

Ein konkretes Beispiel dazu habe ich jetzt aber (noch) nicht greifbar.

Gruß,
Andreas.

[A.Harrenberg]

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]

@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]

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

[A.Harrenberg]

Hallo Christian,

Liste kam mEn daher: http://220.135.186.178/zwave/example/

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

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.

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]

Hi,

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]

Gibt 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]

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 Erweitern


     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 Erweitern

     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]

Hi Rudi,

Code Auswählen Erweitern

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]

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]

Hi Rudi,

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 Erweitern

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.

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]

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

[A.Harrenberg]

Hi Rudi,

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]

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 Erweitern

  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]

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 Erweitern

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]

@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

[krikan]

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

Nein.  War für Andreas nur die Info, dass Philio PST02 V4 und nicht V2 hat; und ich das auch mit V4 interpretiert bekomme.

[krikan]

Andreas, hattest Du gesehen, dass ozw aktuell auch bei der Einbindung von ALARM >= V2 ist? Ist aber noch im dev-branch: https://github.com/OpenZWave/open-zwave/tree/Dev/cpp/src/command_classes

Vielleicht kannst Du daraus noch Infos ziehen.

[A.Harrenberg]

Hallo Christian,

00: Length = 0x00 AND 0x1F = 00
      Sequence = 0x00 AND 0x80 = 00

gut wenn andere besser aufpassen als ich... Du hast Recht, in dem structByte ist auch ein Flag für Sequence, wenn man das so interpretiert das die Sequencenummer nur gesendet wird wenn das Bit auch gesetzt ist passt es!
Dann ist aber nach wie vor das V2-Beispiel aus dem alten Thread zu lang, das V4-Beispiel ist dann jetzt auch zu lang, Dein Philio passt, mein Multisensor ist zu lang und das DanaLock passt jetzt... Argl, wozu gibt es denn einen Standard wenn sich fast keiner dran hält.

Übrigens ist Dein Philio ein Beispiel für ein Gerät mit zwei AlarmTypen ,-)

ff: Status = 0xff AND 0xFF = on

Das ist aber nur der Status der Notification, nicht des Alarms! Bei on wird automatisch bei Eintreffen des Ereignisses gesendet, bei off nicht. (Manuelles Abfragen ergibt bei meinen Geräten aber keine brauchbaren Ergebnisse...)

Hast Du in ein paar Tagen mal Zeit für ein paar kleine Tests? Mich würde mal interessieren ob Deine Geräte beim Abfragen des Alarmstatus auch mal was vernünftiges melden, meine antworten immer mit dem gleichen Report der auch bei Eventauslösung kommt, egal ob das jetzt noch aktiv ist oder nicht ,-(

So kann ich z.B. bei dem DanaLock momentan nicht auslesen ob nun abgeschlossen ist oder nicht, da beide Abfragen gleich beantwortet werden. Entweder übersehe ich da auch noch wieder was oder das ist auch mal wieder nicht konsequent implementiert.

OZW dev-Branch hatte ich nicht gesehen, hatte nur in einen etwas älteren Code geschaut den ich hier noch lokal hatte und da nicht viel drin gefunden. Schaue ich mir auch noch mal an. (Hab' hier nur 'ne instabile 1MBit Leitung...)

Gruß,
Andreas.

[krikan]

Hallo Andreas!

Dann ist aber nach wie vor das V2-Beispiel aus dem alten Thread zu lang, das V4-Beispiel ist dann jetzt auch zu lang, Dein Philio passt, mein Multisensor ist zu lang und das DanaLock passt jetzt... Argl, wozu gibt es denn einen Standard wenn sich fast keiner dran hält.

Verstehe das mit dem "zu lang" nicht wirklich.
Der Vision V2 aus dem anderen Thread ergibt doch auch Sinn:

Code Auswählen Erweitern

07 ff 00 ff 07 03 00 00

07: AlarmTypeV1
ff: AlarmLevelV1
00: ZensorNetId
ff: Status = on
07: AlarmType = HomeSecurity/Burglar
03: Event
00: NumberEventParam
00: EventParam

Sind bei Deinen anderen "zu langen"-Beispielen die letzten, übrigen Bytes nicht nur 00 Werte, die man ignorieren könnte?

Übrigens ist Dein Philio ein Beispiel für ein Gerät mit zwei AlarmTypen ,-)

Ja und das finde ich lästig, da es derzeit mEn nur in einem Reading landet.

Das ist aber nur der Status der Notification, nicht des Alarms! Bei on wird automatisch bei Eintreffen des Ereignisses gesendet, bei off nicht. (Manuelles Abfragen ergibt bei meinen Geräten aber keine brauchbaren Ergebnisse...)

Das habe ich noch nicht wirklich "akzeptiert" und nicht begriffen und würde das gerne anhand Tests nachvollziehen, um es zu verstehen.

Hast Du in ein paar Tagen mal Zeit für ein paar kleine Tests?

Dafür habe ich immer Zeit. Wenn Du etwas brauchst, melde Dich.

Am meisten irritiert mich, dass Philio die AlarmTypeV1 und AlarmLevelV1 nicht setzt. Das widerspricht doch der Rückwärtskompatibilität!?

Gruß, Christian

[A.Harrenberg]

Hallo Rudi,

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

meiner Interpretation der XML nach dürfte in den ersten beiden Bytes nur Geräte nach V1 was ausgeben. In den Beispielen sendet aber sowohl ein V2 als auch ein V4 dort Typ und Level. Meine V3 Geräte und der V4 Philio von Christian sendet dort nur Nullen. Ab V2 gibt es die Type, Event und Eventparameter, was ja beim V4 Beispiel auch gut funktioniert. Theoretisch sollte das auch bei V2 so funktionieren können, aber sowohl bei meinen Geräten aus auch bei dem von Christian ist das irgendwie anders umgesetzt und man kann mit den Nachrichten eigentlich recht wenig anfangen...

Wenn ich Deinen Code richtig verstanden habe würde da ja momentan als Level IMMER "ff" ausgegeben werden falls die alarmnotification eingeschaltet ist. (was sie standardmäßig wahrscheinlich überall ist...). Da die Nachrichten ja bei fast allen Geräte anscheinend nur bei Auslösung kommt, "stimmt" "ff" als Level ja immerhin, der Level wird aber gar nicht explizit gesendet.

Wahrscheinlich muss man einfach schauen ob Event gesendet -> Level als "ff" annehmen. Bei Event "00" (event cleared?) müsste man schauen ob Eventparameter mitgeschickt wurden, wobei die "00" eigentlich "resevered" ist und nicht explizit als "event cleared" deklariert ist.

Ich schau mal wie ich das verbastelt bekomme ohne die bisherige Ausgabe zu ändern, wobei ich aber gerne noch weitere Informationen (z.B. NotificationStatus) anhängen möchte.

Gruß,
Andreas.

[A.Harrenberg]

Hallo Christian,

Hallo Andreas!Verstehe das mit dem "zu lang" nicht wirklich.
Der Vision V2 aus dem anderen Thread ergibt doch auch Sinn:

Code Auswählen Erweitern

07 ff 00 ff 07 03 00 00

07: AlarmTypeV1
ff: AlarmLevelV1
00: ZensorNetId
ff: Status = on
07: AlarmType = HomeSecurity/Burglar
03: Event
00: NumberEventParam
00: EventParam

also wenn man die Spec so liest das bei Länge EventParamter=0 keine Parameter gesendet werden und bei inaktivem Sequence-Flag auch keine Sequencenummer, dann ist die Antwort einfach ein 00-Byte zu lang!

Sind bei Deinen anderen "zu langen"-Beispielen die letzten, übrigen Bytes nicht nur 00 Werte, die man ignorieren könnte?

Jein, soetwas finde ich extrem unschön, wer sagt denn das da immer eine Null kommt? Und ist die Byte jetzt ein zu viel gesendeter EventParameter oder eine zu viel gesendete Sequencenummer? (Und wer sagt das unsere XML-Spec stimmt?)

Es wird darauf hinauslaufen das ich die Länge und das Flag beachte und überzählige Bytes ignoriere, wahrscheinlich aber mit ausgeben werde.

Ja und das finde ich lästig, da es derzeit mEn nur in einem Reading landet.

Stimmt, das landet in einem Reading und ist nur durch das vorangestellte "HomeSecurity" oder "AccessControl" zu unterscheiden, wobei die sich regelmäßig gegenseitig überschreiben.

@Rudi: Von getrennten Readings für jeden AlarmTyp bist Du wahrscheinlich nicht begeistert, oder?

Das habe ich noch nicht wirklich "akzeptiert" und nicht begriffen und würde das gerne anhand Tests nachvollziehen, um es zu verstehen.
Dafür habe ich immer Zeit. Wenn Du etwas brauchst, melde Dich.

Ich schick gleich mal den aktuellen Stand der 10_ZWave.pm, dann kannst Du das selbst ausprobieren. Mit dem 0x7106 Befehl kannst Du für eine AlarmTyp das automatische (unsolicited) senden des Status ein- und ausschalten. Der Zustand der Notification ist in dem 4. Byte der 0x7105 Antwort enthalten.
Das habe ich hier schon ausprobiert. Wenn man das ausgeschaltet hat kann man den Status natürlich nur noch manuell abfragen (0x7104), in der Antwort sieht man dann das an der Stelle "00" statt "ff" kommt.
Siehe auch SDS11060-12 ALARM_V2.

Am meisten irritiert mich, dass Philio die AlarmTypeV1 und AlarmLevelV1 nicht setzt. Das widerspricht doch der Rückwärtskompatibilität!?

An der Stelle bin ich mir unsicher, die V1 Klasse war anscheinend vollkommen applikationsspezifisch, ich interpretiere die das in diesem Fall eigentlich so das NUR V1 Geräte da was senden sollen/dürfen.

Gruß,
Andreas.

[A.Harrenberg]

Hallo Christian,

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

Mit get alarmTypeSupported und get alarmEventSupported bekommst Du erst einmal die unterstützten Funktionen angezeigt bzw. in die Readings.

Mit get alarmWithTypeEvent kannst Du den Alarm manuell abfragen. Drei Parameter, erster MUSS 0 sein (wegen der V1 Geschichte...), zweiter Parameter ist der Name des Alarmtyps (ignorecase) und dritter Paramter Eventnummer (kann aus dem reading entnommen werden)

Also z.B. get alarmWithTypeEvent 0 accesscontrol 16

Mit set alarmNotification <alamTyp> [on|off] schaltest Du dann das Senden der Nachrichten ein- oder aus. (Falls das Gerät das nicht "will" muss es das laut Spec explizit "rejecten")

Wenn Du also erst mal mit get alarmWithTypeEvent was ausliest, dann mal alamNotification ausschaltest und noch mal ausliest wirst Du in den Rohdaten sehen das das 4. Byte dann "00" ist und auch keine Nachrichten mehr automatisch geschickt werden.

Könntest Du dann bitte mal die Rohdaten schicken wenn Du z.B. 16 und 17 (Window/Door open/close) abfragst? Bei mir kommt da nichts an dem man erkennen könnte ob der entsprechende Alarm nun aktiv ist oder nicht...

Gruß,
Andreas.

[rudolfkoenig]

@Rudi: Von getrennten Readings für jeden AlarmTyp bist Du wahrscheinlich nicht begeistert, oder?

Ein Reading/Event zu ueberwachen ist halt einfacher als mehrere, und auch etwas uebersichtlicher bzw. weniger verwirrend in der Darstellung. Haengt aber auch davon ab, was genau/wann gemeldet wird, deswegen ueberlasse ich dir die Entscheidung.

[A.Harrenberg]

Hi Rudi,

Ein Reading/Event zu ueberwachen ist halt einfacher als mehrere, und auch etwas uebersichtlicher bzw. weniger verwirrend in der Darstellung. Haengt aber auch davon ab, was genau/wann gemeldet wird, deswegen ueberlasse ich dir die Entscheidung.

hmm, war vielleicht nicht wirklich zu Ende gedacht... Aus "Rückwärtskompatibilität" müsste man dann ja wohl das "alarm" Reading beibehalten wo alle alarmTypen reinschreiben und die meisten User hätten dann ein noch ein alarm_<Typ> Reading in dem genau das gleiche drin steht... Auch sehr unschön...

Würdest Du es für machbar halten zusätzliche alarm_<Typ> Readings einzuführen und das bisherige alarm-Reading dann mit 5.8 zu entfernen? Dann hätten normale User wieder nur ein Reading, Christian hätte dann zwei.

Die Frage wäre dann ob man aus dem Inhalt des Readings dann den vorangestellten alarmTyp rauslässt oder nicht. Drinlasse wäre ja irgendwie doppelt gemoppelt.

@Christian: Hättest Du denn gerne getrennte Readings?

Gruß,
Andreas.

[krikan]

@Christian: Hättest Du denn gerne getrennte Readings?

Bei derzeitigem Modulstand hätte ich das sehr gerne. Lass mich mal Deine Testversion ausprobieren, vielleicht ändert sich mit den neuen Abfragemöglichkeiten "get alarmTypeSupported" und "get alarmEventSupported" meine Meinung noch.

[A.Harrenberg]

Hallo Christian,

Bei derzeitigem Modulstand hätte ich das sehr gerne. Lass mich mal Deine Testversion ausprobieren, vielleicht ändert sich mit den neuen Abfragemöglichkeiten "get alarmTypeSupported" und "get alarmEventSupported" meine Meinung noch.

damit bekommst Du aber nur eine die unterstützten AlarmTypen und (jeweils) die Liste der unterstützten EventTypen.

Den Alarmstatus müsste man mit get alarmWithTypeEvent auslesen, da liefern meine Geräte allerdings keine verwertbaren Informationen über den Status/Level ,-(

Wenn Du heute abend oder morgen mal ein wenig mit rumspielst wirst Du ja recht schnell sehen ob bei Dir das sinnvollere Rückmeldungen kommen. Du solltest Dir allerdings die Rohtelegramme ansehen da die Parsefunktion ja noch die bisherige Version ist und nicht alle empfangenen Bytes darstellt.

Gruß,
Andreas.

[rudolfkoenig]

Würdest Du es für machbar halten zusätzliche alarm_<Typ> Readings einzuführen und das bisherige alarm-Reading dann mit 5.8 zu entfernen?

Eher ungern, und ich muesste vorher verstehen, warum das gut ist.

[A.Harrenberg]

Hallo Rudi,

Eher ungern, und ich muesste vorher verstehen, warum das gut ist.

ich vermute das hier der Bewegungsmelder (Homesecurity-Teil des Sensors) den "Status" der Tür/Fenster (AccessControl-Teil des Sensors) überschreibt da ja beide Nachrichten in das gleiche alarm-Reading geschrieben werden und man dann nicht mehr sehen kann ob die Tür/Fenster nun offen oder geschlossen ist. Dazu müsste man dann wohl eine Hilfslösung basteln und beim Eintreffen der Nachricht über Notify den Status in einem Hilfsdummy speichern.

Ich fände es auch unschön ein bestehendes Reading zu entfernen/zu ändern. Spezifische Readings würde hier ja helfen, da die meisten Geräte aber nur einen Typ haben wäre die Information dann doppelt.

Vielleicht hat Christian ja "Glück" und er kann den Status auslesen, dann ist es nicht mehr ganz so wichtig...

Gruß,
Andreas.

[rudolfkoenig]

der Bewegungsmelder (Homesecurity-Teil des Sensors) den "Status" der Tür/Fenster (AccessControl-Teil des Sensors) überschreibt

Das ist natuerlich was anderes, unterschiedliche Sensoren sollten auch unterschiedliche Events/Readings haben.
Eigentlich gehoert sowas mit 2 Endpoints geloest.

[A.Harrenberg]

Hallo Rudi,

tja, verschiedene Endpoints sind da wohl nicht vorgesehen... Ich hatte das auch eher als theoretische Möglichkeit in der Spec gesehen das es Sensoren geben könnte die mehrere Alarmtypen implementieren. Aber der Sensor von Christian ist direkt so ein Exemplar.

Problem ist das man das jetzt nicht "schön" lösen kann. Wenn einzelne Readings für jeden AlarmTyp angelegt werden UND wir das momentan angelegte alarm-Reading beibehalten wollen haben 98% der Nutzer das alarm-Reading und ein neues alarm_<alarmTyp> Reading mit eigentlich identischem Inhalt.

Mir würde da nur noch einfallen das per Attribut einstellbar zu machen ob alarm, alarm_<alarmType> (oder evtl. beide) ausgegeben werden.

Gruß,
Andreas.

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

[rudolfkoenig]

Hallo Andreas,

@Rudi: Wenn das so passt werde ich die Doku entsprechend anpassen und Dir dann demnächst mal ein Patch schicken.

Ich bitte dich:
- alarm_XX Readignamen aendern: es darf kein () vorkommen
- ZWave_CC_0x71_01_Get & co in ZWave_Alarm_01_Get usw. umzubennen
- auf TAB zu verzichten (da keiner mehr weiss, wie breit ein TAB ist, stiftet es nur Verwirrung).
- Zeilen auf 80 Zeichen zu beschraenken
- nicht benutzte Funktionen / auskommentierten Code entfernen

Sonst (bitte ignorieren, falls ich mich irre):
-  "for (my $i=0; $i<$numBitMasks; $i++)" klingt falsch, ich wuerde <= erwarten

[A.Harrenberg]

Hallo Rudi,

- alarm_XX Readignamen aendern: es darf kein () vorkommen

ok, war mir nicht bewusst.

- auf TAB zu verzichten (da keiner mehr weiss, wie breit ein TAB ist, stiftet es nur Verwirrung).

Hmm, dachte ich hätte meinen Editor so eingestellt das er TAB als zwei Spaces behandelt. Werde die TAB entfernen.

- Zeilen auf 80 Zeichen zu beschraenken
- nicht benutzte Funktionen / auskommentierten Code entfernen

Ja, aufhübschen werde ich das noch... ,-)

Sonst (bitte ignorieren, falls ich mich irre):
-  "for (my $i=0; $i<$numBitMasks; $i++)" klingt falsch, ich wuerde <= erwarten

Das sollte so passen, da die Schleife bei 0 anfängt und die Zählweise von "numBitMasks" bei 1 anfängt. Musste aber auch gerade überlegen warum ich das so gemacht hatte....

Gruß,
Andreas.

[krikan]

Hallo Andreas!
Nur eine kurze Zwischenmeldung: Teste derzeit zwischendurch immer wieder Deine oben angehängte Modulversion. Habe nicht wirklich etwas festgestellt; werde aber noch weiter probieren, da ich die Class noch nicht genau durchblicke. Das sollte aber ggfs. nicht an Änderungen/Einchecken hindern.
Gruß, Christian.

[A.Harrenberg]

Hallo Christian,

Nur eine kurze Zwischenmeldung: Teste derzeit zwischendurch immer wieder Deine oben angehängte Modulversion. Habe nicht wirklich etwas festgestellt; werde aber noch weiter probieren, da ich die Class noch nicht genau durchblicke. Das sollte aber ggfs. nicht an Änderungen/Einchecken hindern.

danke für die RM. Ich habe jetzt ja nur noch die "()" in den Readingnamen entfernt, ansonsten denke ich aber nur internas geändert und funktional nicht nicht mehr wirklich was geändert. Die Dokumentation habe ich auch schon mal soweit fertig, allerdings werde ich es heute und morgen wohl nicht schaffen das als Patch fertig zu machen. Ich peile mal Do. Abend an...

@Rudi: Ich habe ja die auch Texte der Events angepasst (Kommas entfernt), falls jetzt jemand auf den vollständigen String inklusive des Kommas geparst hat, wird das nach dem Update fehlschlagen. Hälst Du das für ein häufiges/wahrscheinliches Szenario? Sollte das dann evtl. angekündigt werden?

Gruß,
Andreas.

[rudolfkoenig]

Bin unentschlossen. Falls keine andere Meinungen kommen, dann wuerde ich es ankuendigen, zuletzt habe ich einen Rueffel wg. einem unangekuendigten Bugfix mit unerwarteten Nebeneffekten bekommen

[A.Harrenberg]

Hi Rudi,

Bin unentschlossen. Falls keine andere Meinungen kommen, dann wuerde ich es ankuendigen, zuletzt habe ich einen Rueffel wg. einem unangekuendigten Bugfix mit unerwarteten Nebeneffekten bekommen

den "Rüffel" habe ich gelesen, daher habe ich das hier vorgeschlagen ,-)
Ich denke eine Ankündigung schadet ja nicht, ich denke das Du damit aber noch warten solltest bis ich Dir den Patch schicken kann. Das Einpflegen des Patches kann man dann ja entsprechend einen Tag nach der Ankündigung machen.

Gruß,
Andreas.

[A.Harrenberg]

Hi Rudi, hallo Christian

angehängt der Patch für ALARM/NOTIFICATION.

@Christian: Ich habe auch eine aktuelle 10_ZWave.pm Version angehängt, wenn Du die vielleicht mal kurz antesten könntest...

@Rudi: Bitte schaue noch mal in den Patch rein und gib mir eine Rückmeldung wenn ich noch was anpassen soll. Im Doku-Teil war mir aufgefallen das dort teilweise "<name>" verwendet wurde, was dann ja als HTML-Tag ausgefiltert wird. Ich hoffe ich habe alle Stellen gefixt. Falls es so in Ordnung ist kannst Du es dann ja ankündigen und danach veröffentlichen.

Gruß,
Andreas.

[rudolfkoenig]

@Andreas: habe in der Doku ein paar Tippfehler verbessert, und nur den ersten Exemplar des "ALARM was renamend to NOTIFICATION" Paragraphs behalten. Sonst ohne Aenderung eingecheckt. Ich habe die Aenderung in CHANGED erwaehnt. Wer das da nicht liest, wird auch die Ankuendigungen nicht lesen.