Info: devolo Tür-/Fenster Kontakt 3in1 in fhem

[Buwe]

Keine Frage, sondern ich wollte einfach diesem hilfreichen Forum auch mal was zurück geben:

Ich hatte das Ding einfach mal im vorbeigehen mitgenommen. U.a. weil es in der Anleitung mal konkrete Aussagen zum Abstand (max. 2cm) Magnet<> Sensor gab.
Auch interessant zu wissen: Der Sensor hat auf beiden Seiten einen Reed-Kontakt so dass man den Sensor nicht je nach Öffnungs-Richtung des Fensterflügels "auf dem Kopf" anbringen muss.

Grundsätzlich noch: devolo sagt auf der Verpackung zwar, man benötige eine "Z-Wave Steuereinheit, wie z.B. die devolo Home Control Zentrale", allerdings verschweigt die mitgelieferte Anleitung sämtliche Parameter oder auch Inclusion, etc. Es wird immer auf die Online-Hilfe der devolo-Zentrale verwiesen. Auch auf der devolo-Webseite findet sich nichts. Das gilt im Übrigen auch für den devolo Zwischenstecker den ich habe.
Bei Pepper, Openzwave, etc. ist Devolo auch noch nicht (richtig) angekommen, dementsprechend hilft "model"/"configrequestall" in FHEM nicht wirklich weiter. Ich hatte aber schon vorher die Vermutung, dass devolo sich bei Philio bedient. Der Sensor dürfte ein PST02-C sein, zumindest haben die Parameter gepasst.

Bevor man das Ding ans Fenster "nagelt", sollte man es erst mal am Tisch einrichten. Also in der Reihenfolge FHEM in den Inklusionsmodus schalten (nwOn) und dann den Streifen an der Batterie rausziehen. Inklusion war problemlos (ist dann zunächst ein "Garage"-Sensor).
Vorteil: Durch Anheben des Sensors wird immer der "tamper-" Taster ausgelöst, so dass man die Konfigurationsparameter ohne langes Warten ändern kann. Funktioniert zwar auch wenn man den Deckel abnimmt, aber der lässt ziemlich schlecht öffnen (lt. der Philio-Anleitung liefern die im Gegensatz zu devolo ein Werkzeug dafür mit). Solange der tamper-Taster noch nicht gedrückt ist, gibt eine LED beim Wakeup und Anbringen/Positionieren des Kontakts/Magnets ein optisches Feedback.

Einige Besonderheiten (zumindest für einen Newbie):

• Wakup notification ist per default alle 24 Stunden und geht als Broadcast raus (255). Bei der Notification werden keine Werte (z.B. Temperatur) übertragen.
• Alle 6 Stunden werden als Default-Report: Batterie, Temperatur, Helligkeit und Zu(00)/Auf(ff) gesendet. Diese Zeit kann an zwei Stellen beinflusst werden: Config-No. 20 (Default:30) beeinflusst alle zusammen,  Config-No. 13  (default:12) als Beispiel beinflusst nur die Temparatur. Für die Nicht-Mathematiker: 12 Minuten * 30 Minuten = 360 Minuten/6Stunden 
• Die Dauer zwischen zwei Reports wird jeweils um einige Sekunden kürzer (siehe log unten). Wenn er nicht irgendwann irgendwas tut, müsste die Dauer irgendwann man 0 Minuten sein?
• Cofig-No. 5 auf 8 setzen: ändert die Temperaturwerte auf Celsius statt Fahrenheit (Dank ans fhemwiki)
• Ändert sich die Temperatur um mehr als 0,56 C, erfolgt eine Meldung an FHEM. Für die Helligkeit ist eine Meldung per Default deaktiviert, wobei die Philio-Anleitung bei Aktivierung auf die reduzierte Batterie-Lebensdauer hinweist.
• tamper-Reading, wird beim Auslösen auf "ff" gesetzt und nicht zurückgesetzt. Man kann erneutes Auslösen nur an der Uhrzeit erkennen. (Per setreading manuell auf "00" gesetzt).
• state oder STATE werden beim Auslösen des Fensterkontakts nicht gesetzt (Über "stateformat" gelöst)

Der Vollständigkeit halber ein list <device>...

Code Auswählen Erweitern


Internals:
   DEF        d45feXXX 5
   IODev      zw.dongle
   LASTInputDev zw.dongle
   MSGCNT     19
   NAME       eg.wz.window_open
   NR         70
   STATE      Status: Zu
   TYPE       ZWave
   homeId     d45fXXX
   id         05
   lastMsgSent 1442887809.01576
   zw.dongle_MSGCNT 19
   zw.dongle_RAWMSG 00040005108f0102053105030101063105012200dc
   zw.dongle_TIME 2015-09-22 08:53:55
   Readings:
     2015-09-20 21:03:30   CMD             ZW_APPLICATION_UPDATE
     2015-09-22 05:24:34   battery         100 %
     2015-09-21 13:16:07   config_12       2
     2015-09-21 13:16:07   config_13       2
     2015-09-21 12:16:42   config_20       30
     2015-09-20 17:29:05   config_5        8
     2015-09-22 05:24:34   doorWindow      00
     2015-09-22 08:53:55   luminance       1 %
     2015-09-20 16:55:53   model           0x0175 0x0002 0x000e
     2015-09-20 16:55:53   modelId         0175-0002-000e
     2015-09-20 16:55:49   state           associationAdd 1 01
     2015-09-21 19:42:59   tamper          00
     2015-09-22 08:53:55   temperature     22.0 C
     2015-09-22 04:10:11   transmit        OK
     2015-09-22 04:10:09   wakeup          notification
     2015-09-21 16:15:02   wakeupReport    interval 21600 target 1
Attributes:
   IODev      zw.dongle
   alias      Terassentür
   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
   devStateIcon .*Zu:fts_door_right@green .*Auf:fts_door_right_open@red
   eventMap   00:Zu ff:Auf
   icon       control_building_eg
   room       Wohnzimmer
   stateFormat Status: doorWindow


... und ein log. (Report: für Temperatur und Helligkeit auf 1 Stunde gesetzt, Batterie und Zustand Kontakt auf 6 Stunden gelassen)

Code Auswählen Erweitern


2015-09-22_03:54:51 eg.wz.window_open luminance: 1 %
2015-09-22_03:54:51 eg.wz.window_open temperature: 22.0 C

2015-09-22_04:10:09 eg.wz.window_open wakeup: notification

2015-09-22_04:54:40 eg.wz.window_open luminance: 1 %
2015-09-22_04:54:40 eg.wz.window_open temperature: 22.0 C

2015-09-22_05:24:34 eg.wz.window_open battery: 100 %
2015-09-22_05:24:34 eg.wz.window_open doorWindow: Zu

2015-09-22_05:54:28 eg.wz.window_open luminance: 1 %
2015-09-22_05:54:28 eg.wz.window_open temperature: 22.0 C

2015-09-22_06:54:17 eg.wz.window_open luminance: 28 %
2015-09-22_06:54:17 eg.wz.window_open temperature: 22.0 C


Der Sensor könnte zwar Security genauso wie mein Dongle, aber das scheint in fhem noch eine "Baustelle" zu sein(?).
Falls da irgendwelche Tests gewünscht werden...

[krikan]

Der Sensor dürfte ein PST02-C sein, zumindest haben die Parameter gepasst.

Davon ist auszugehen. Detaillierte Handbücher mit Config-Angaben zum Devolo-Sensor findet man unter http://products.z-wavealliance.org/products/1130. Bei den Z-Wave+ Geräten sind dort immer vernünftige Handbücher zu finden, selbst wenn beim Hersteller/OEM nur unvollständige Angaben zur Verfügung stehen.

Der Sensor könnte zwar Security genauso wie mein Dongle, aber das scheint in fhem noch eine "Baustelle" zu sein(?). 

Es fehlen einfach Tester. Du kannst sehr gerne probieren und im entsprechenden Thread berichten. A.Harrenberg, der Entwickler ist aber zur Zeit nicht anwesend (Details siehe Thread).
Mit einem Philio PST02-1A hatte ich die Testversion von SECURITY probiert. Das funktionierte problemlos. Nach Übernahme in das svn hatte ich anfangs noch Probleme, bin aber noch nicht weiter zum Testen gekommen.

[Buwe]

Danke für den Link.
Da war ich schon mal im Zusammenhang mit dem Zwischenstecker, der dort (immer) noch nicht auftaucht.

In Bezug auf einen Test. Müsste mal schauen das ich meine Konfiguration wegsichere = Schon mal Übung für den Ernstfall.
Ich habe Wiki, Forum und Commandref überflogen, auf die Schnelle:
Crypt::Rijndael war bereits installiert
Attribut: networkKey (jetzt) gesetzt

node_info für den Dongle sagt immer noch Security:0
shutdown restart hat nicht geholfen

Vermutlich muss man erst den Dongle in fhem löschen/neu anlegen?
Sensor erst exkludieren/dann inkludieren mit addnode + sec? (=autocreate ausschalten)

Und ich müsste vermutlich erst mal schauen wie man Module aus dem SVN einbindet?
Macht vermutlich auch nur Sinn wenn das Device per "get model erkannt" wird?

Sorry für die Fragen, aber die Threads für Security und auch ConfigRequestAll sind mittlerweile doch recht lang. 

[krikan]

node_info für den Dongle sagt immer noch Security:0
shutdown restart hat nicht geholfen

Vermutlich muss man erst den Dongle in fhem löschen/neu anlegen?

Nein, am Dongle musst Du nichts ändern und auch nur ein aktuelles Fhem (update -> nothing to do..) haben (nichts manuell aus svn ziehen).
"Nur" den Sensor exkludieren.
Dann autocreate einschalten, verbose 5 bei ZWDongle und mscelog 1 bei global
Dann inkludieren mit "set <ZWdongle> addNode on sec".
Wenn alles korrekt läuft, sollte der Sensor dann secure-inkludiert sein. Du bekommst ein neues Fhem-Device mit dem Attribut secure_classes und alles "sollte" (Wunsch) so laufen wie vorher nur eben gesichert.

Und ich müsste vermutlich erst mal schauen wie man Module aus dem SVN einbindet?

Nein, siehe oben: nur aktuelles Fhem

Macht vermutlich auch nur Sinn wenn das Device per "get model erkannt" wird?

Nein, unwichtig

Sorry für die Fragen, aber die Threads für Security und auch ConfigRequestAll sind mittlerweile doch recht lang.

Du darfst/sollst fragen, dafür ist das Forum da. Bitte teste das aber nur, wenn Du Zeit und Spass daran hast. Mißerfolg ist nicht auszuschließen. Denke auch daran, dass bei einer späteren non-secure Inklusion in Dein Produktivsystem der Sensor eine neue NodeId erhält.

[krikan]

Da war ich schon mal im Zusammenhang mit dem Zwischenstecker, der dort (immer) noch nicht auftaucht.

Suchst Du den: http://products.z-wavealliance.org/products/1129 ?

[Buwe]

Gehe auf deinen ersten Link, scrolle nach unten und klicke auf: 
This Brand: See other products of this brand 

Bei mir kommen da nur zwei Sensoren und ein Schalter...

Den Security Test muss ich leider auf die Schnelle schuldig bleiben.
Ich weiß jetzt a) warum Philio dieses Werkzeug zum Öffnen mitliefert und b) das das mitgelieferte Tape saugut hält
Ich bekomme ihn selbst mit gebogener Büroklammer o.ä. nicht mal eben zerstörungsfrei geöffnet.

Ich probiere es noch mal am Wochenende...

[krikan]

Gehe auf deinen ersten Link, scrolle nach unten und klicke auf: 
This Brand: See other products of this brand 

Bei mir kommen da nur zwei Sensoren und ein Schalter...

Das Geheimnis ist eben: die Seite führt den Hersteller "devolo" 2 Mal. Warum wissen wohl nur Eingeweihte.

Den Security Test muss ich leider auf die Schnelle schuldig bleiben.
Ich weiß jetzt a) warum Philio dieses Werkzeug zum Öffnen mitliefert und b) das das mitgelieferte Tape saugut hält
Ich bekomme ihn selbst mit gebogener Büroklammer o.ä. nicht mal eben zerstörungsfrei geöffnet.

Ich probiere es noch mal am Wochenende...

Bist nichts schuldig. Wie geschrieben: mache es nur, wenn Du magst.

[feeeem]

Halo Buwe,

habe auch den devolo Tür/Fensterkontakt und es klappt ganz gut damit. Aber zwei Dinge kriege ich nicht hin (bin noch relativ neu bei ZWave/FHEM):

1. Wie bekommt man die Parameter z.B. vom PST02-C hinterlegt?
2. Bei Dir steht als Device STATE  "Status: Zu"
Das ist bei mir nicht so - oder ist das so definiert, wenn man die Parameter benutzt?

Vielen Dank
Norbert

[Buwe]

Antwort in nicht "schön" vom IPad:

Zu 1:
Gehe auf die Detailansicht deines Sensors
Hinter SET aus der Dropdown ConfigByte auswählen
Als Beispiel ändern von Fahrenheit auf Celsius: In das Feld hinter ConfigByte 5 8 eingeben (Wichtig ist das Leerzeichen zwischen 5 und 8!)
Dann erst auf Set klicken.
Am besten auf gleichem Wege ein Get Config 5 hinterherschicken, dann kannst du später unter Readings sehen ob er es gefressen hat
Entweder wartest du max. 24 Stunden (default) bis zum nächsten Wakeup oder löst durch Abnehmen des Deckels ein "Tamper" aus.

Zu 2:
Schau dir mein List Devise oben an: Stichwort  stateformat und eventmap

[feeeem]

Hallo Buwe,

Zur Frage nach den Parametern, habe ich mich wahrscheinlich unklar ausgedrückt.
Da seitens devolo erstmal keine genaueren Informationen mitgeliefert wurden, habe ich auch auf die Suche begeben, und ein englischsprachiges Dokument (http://products.z-wavealliance.org/MarketCertification/File?folder=&filename=MarketCertificationFiles/1130/Devolo%20home%20Control%20Door-Window.pdf) gefunden, welches das Gerät detailliert mit allen Parametern beschreibt. So konnte ich dann z.B. die Temperatur auf Celsius umstellen.

Was ich eigentlich gerne hätte, ist die gerätespezifische Parameterdefinition, die von FHEM z.B. dazu benutzt wird, bei set und get direkt die Parameter mit sinnvollen Namen (configXXXX) anzuzeigen und einen Hilfetext dazu, siehe Screenshot unten von einem anderen Gerät, zu dem es offenbar eine Beschreibung gibt.
Wenn ich das richtig verstanden habe, kommen diese Informationen aus dem openzwave_deviceconfig.xml.
Deshalb dachte ich Du hättest eine Möglichkeit gefunden, die Information von baugleichen Philio Gerät dort "einzubauen".

Zum zweiten Punkt:
Wieder was gelernt! Dank für den Hinweis auf stateformat und eventmap, diese Funktion hab ich genau gesucht.
Hatte wohl nicht genau genug in Dein Listing geschaut oder nicht weit genug nach unten gecrollt

[krikan]

Was ich eigentlich gerne hätte, ist die gerätespezifische Parameterdefinition, die von FHEM z.B. dazu benutzt wird, bei set und get direkt die Parameter mit sinnvollen Namen (configXXXX) anzuzeigen und einen Hilfetext dazu, siehe Screenshot unten von einem anderen Gerät, zu dem es offenbar eine Beschreibung gibt.
Wenn ich das richtig verstanden habe, kommen diese Informationen aus dem openzwave_deviceconfig.xml.
Deshalb dachte ich Du hättest eine Möglichkeit gefunden, die Information von baugleichen Philio Gerät dort "einzubauen".

Wenn PST02-1C (https://github.com/OpenZWave/open-zwave/blob/master/config/philio/pst02-1c.xml) und der Devolo komplett baugleich sind, dann packe ich das ins svn und es würde danach über update verteilt. Hierzu hätte ich aber gerne eine definitive Aussage.
Details zu den XML-Configs:
http://www.fhemwiki.de/wiki/Z-Wave#Welche_Funktion_haben_die_XML-Config-Dateien_in_Fhem.3F
http://www.fhemwiki.de/wiki/Z-Wave#Wie_k.C3.B6nnen_fehlende_XML-Config-Informationen_f.C3.BCr_mein_ZWave-Ger.C3.A4t_in_Fhem_eingebunden_werden.3F
Man kann das auch bei seiner eigenen Installation testen, indem die openzwave_manufacturer_specific.xml in der eigenen Installation anpasst und neu startet.

[feeeem]

Die Manufacturer Provided Product Manuals auf products.z-wavealliance.org für die nachfolgenden drei Geräte sehen nahezu identisch aus. Die Dokumente haben ganz offensichtlich den gleichen Ursprung, sind nur unterschiedlich "gebranded" und das Philio Dokument beschreibt 3 Varianten, die anderen beiden nur zwei.

Tür/Fensterkontakt Philio PST02-1C: http://products.z-wavealliance.org/products/1092
Tür/Fensterkontakt devolo MT02648: http://products.z-wavealliance.org/products/1130
Tür/Fensterkontakt D-Link DCH-Z110: Version http://products.z-wavealliance.org/products/1151

Der hier im Fokus stehende Tür/Fensterkontakt ist in allen Dokumenten gleich beschrieben, lediglich die Zuordnung der Variantenkennung A-B-C ist unterschiedlich: Bei Philio ist dr Tür/Fensterkontakt die "C" Variante, bei devolo "B" und bei D-Link "A".

Insofern kann man aus meiner Sicht die pst02-1c.xml für devolo verwenden.

Folgendes ist mir allerdings aufgefallen: Die Maxwerte für die Parameter 21 & 22 in der pst02-1c.xml stimmen nicht mit den Dokus überein. In allen drei o.g. Dokus stehen übereinstimmend andere Werte.

Hoffe das hilft.

[feeeem]

Noch was:

Bei openhab gibt es ein XML für den devolo Tür/Fensterkontakt: https://github.com/openhab/openhab/blob/master/bundles/binding/org.openhab.binding.zwave/database/devolo/mt02648.xml

Dort sind übrigens die Maximalwerte für Parameter 21 & 22 korrekt.

[Buwe]

Ist zwar prinziell schon beschrieben:
Philio PST02-A/B/C, alle drei Modelle liefern zunächst Temperatur und Helligkeit. Alle drei werden im gleichen PDF abgehandelt und eine Tabelle schlüsselt die Unterschiede auf:
A zusätzlich Tür/Fensterkontakt und Bewegungsmelder
B nur Bewegungsmelder
C nur Tür/Fensterkontakt

Laut Devolo Homepage gibt es bei denen als Modell nur Tür/Fensterkontakt oder Bewegungsmelder. Wenn der Bewegungsmelder auch den Kontakt hätte, würde ja vermutlich auch der Magnet in der Beschreibung/Fotos genannt?

Die openhab XML entspricht meines Erachtens dem All-in-One Modell von Philio (A).
Die Treffer bei der Suche nach MT02648 sind doch sehr überschaubar.
Der Thread unter https://github.com/openhab/openhab/pull/2996 erweckt bei mir den Eindruck, dass dahinter keine tiefergehende Diagnose steckt sondern jemand die Config an Hand des (nicht vollständig gelesenen) PDFs o.ä. erstellt hat.

Das mit den unterschiedlichen Werten in der pst02-1c.xml lässt eventuell dadurch erklären das Philio einen ganzen "Zoo" dieser optisch identischen Sensoren liefert. Die hier beschriebenen sind ja Z-Wave Plus. Möglicherweise wurde diese xml von den älteren Modellen mit leicht unterschiedlichen Parametern einfach kopiert.

Ich stecke (noch) nicht so tief in Z-Wave drin, daher weiß ich nicht was falsche gesetzte Parameter im schlimmsten Fall bewirken. Möglicherweise ist das ja unschädlich.

[krikan]

Binde am Wochenende (wenn nichts dazwischen kommt) die PST02-1c.xml für den (Euren) devolo Sensor mit modelId  0175-0002-000e in Fhem ein. Gebe Bescheid, wenn ich fertig bin.

Fehler in den XMLs kann man nicht ausschließen, die XMLs sind im Fazit immer manuell aus den Handbüchern zusammengestellt. Ein Testen aller Parameter und Werte ist quasi unmöglich; dazu gibt es bei den Geräten zu viele Möglichkeiten. Zudem wird bei openzwave noch nicht zwischen verschiedenen Firmwareversionen unterschieden; hier gibt es schon einmal Änderungen.

Die XMLs von openhab haben ein anderes Format, das uns nicht hilft. Wir nutzen das openzwave-XML-Format.