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

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