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

[A.Harrenberg]

Hi Uwe,

Der Sensor ist baugleich und reicht für gedachten den Zweck. Die anderen beiden werden zus. den Bewegungssensor benötigen.

ah, ok. D.h. der Sensor lässt sich mit Security einbinden, die Frage ist jetzt warum Zwave.me den "blacklisted"...

"Was willst du denn hiermit sagen":
Der Sensor blinkt während der Inklusion und zeigt den Erfolg durch längeres leuchten an.
Will man danach was an den Sensor senden muss man ja ein Wakeup provozieren. Bei diesem Sensor über den Tamper-Schalter.
Die Überlegung aus den vorherigen Versuchen war: Falls fhem doch noch nicht mit dem Interview fertig war, vermeidet mehrmaliges Wakeup hintereinander vielleicht irgendwelche Timeouts.
Also beispielsweise was du unter Assocation-Befehl und einschlafen beschrieben hast.

Soweit ich da gerade reingeschaut habe glaubt FHEM anscheinend nur das Gerät würde schlafen... Da stimmt was im Ablauf nicht, könnte sein das ich mich mit den Security-Funktionen da an eine falsche Stelle reingeklemmt habe. Allerdings ist mir sowas bisher bei keinem Gerät aufgefallen. Vielleicht hat Rudi 'ne schnelle Idee, ansonsten werde ich mal eine Version mit mehr Debug-Output erstellen müssen um rauszubekommen wo der da falsch abbiegt...

Gruß,
Andreas.

[rudolfkoenig]

@Andreas: ich habe jetzt drueber gebruetet. Leider habe ich nichts konretes, aber immerhin einen Verdacht.

Meine Theorie ist, dass das Geraet zunaechst keine Ahnung davon hat, dass es WAKE_UP ist, erst, nachdem secSupported aufgerufen wird. Haken: ich sehe nicht, wann die sec_classes zu den classes hinzugefuegt werden.
Das waere mAn auch deswegen notwendig, damit man Befehle (set/get), die nur in gesicherten Klassen vorkommen, absetzen kann.
Wenn meine Theorie stimmt, dann muesste ZWave_secSupported $hash->{lastMsgSent} auf jetzt setzen.

P.S.: "readingsSingleUpdate($hash, "send_nonce", undef, 0);" ist mAn sehr aufwendig und wirkungslos.
Ich wuerde stattdessen "delete $hash->{READINGS}{send_nonce};" verwenden.

[rudolfkoenig]

Das waere mAn auch deswegen notwendig, damit man Befehle (set/get), die nur in gesicherten Klassen vorkommen, absetzen kann.

Bitte streichen, habe gerade den Aufruf von ZWave_isSecureClass in ZWave_Cmd gefunden....

[A.Harrenberg]

Hallo Rudi,
SecClasses werden aktuell noch nicht zu den normalen classes hinzugefügt. Das muss ich noch einbauen. Dazu wollte ich erst mal die Sache mit MARK klären. Ich denke aber nicht das dies etwas hiermit zu tun hat. An irgendeiner Stelle wird hier der Zeitstempel nicht aktualisiert odet der ganze Ablauf gestört. Warum sollte das WakeUp ansprechen wenn wenige Sekunden vorher noch gesendet wurde. Ich habe aber gerade wenig Zeit, ich kann mich wahrscheinlich erst in 2 Wochen intensiver darum kümmern. Gruß, Andreas.

[Buwe]

Da noch Geld in der Haushaltskasse war 
Ich hatte mir noch einen Philio (-A 4in1 Version) wg. Bewegungsmelder bestellt.

Der ließ sich auch mit Security einbinden.
"Besonderheiten:"

• Die beiden Devolos musste als erstes die Assocation mit dem Controller nachgeholt werden. Der Philio hat das selber gemacht. Ohne Assocation gehen alle Get/Set Config-Befehle anscheinend ins Nirwana.
• Es ist anscheinend nicht möglich in einem Wakeup mehere Get/Set Config Befehle zu senden. Ich hatte bei allen dreien Probleme damit (hatte ich ja schon mal geschrieben).
  Also einen Set/Get Befehl senden, Wakeup provozieren (solange noch nicht montiert), dann erst nächsten Befehl. usw.

Weitere Besonderheit der Geräte die mit Security inkludiert wurden: Jegliche Aktivität die ein Device Funktelegramm erzeugt "müllt" mir das fhem.log mit folgender Nachricht(en) zu:

Code Auswählen Erweitern


2015.10.22 09:07:57 2: ZWave set eg.kue.window_open sendNonce
2015.10.22 09:09:10 2: ZWave set eg.kue.window_open sendNonce
2015.10.22 09:09:27 2: ZWave set eg.fl.window_open sendNonce
2015.10.22 09:09:32 2: ZWave set eg.fl.window_open sendNonce
2015.10.22 09:19:04 2: ZWave set eg.fl.window_open sendNonce


[rudolfkoenig]

Associations werden beim/nach dem Anlernen eigentlich gesetzt, auch beim secure inclusion.
Koenntet du bitte das secure inclusion nochmal mit "attr ZWDongle verbose 5" protokollieren, und das Ergebnis hier posten?

Das Problem mit "sendNonce" habe ich hoffentlich gefixt, konnte es aber nicht testen.
Workaround: beim Geraet verbose auf 1 setzen.

[Buwe]

Associations werden beim/nach dem Anlernen eigentlich gesetzt, auch beim secure inclusion.
Koenntet du bitte das secure inclusion nochmal mit "attr ZWDongle verbose 5" protokollieren, und das Ergebnis hier posten?

Wo das nicht funktioniert hatte, habe ich schon logs geschickt?
http://forum.fhem.de/index.php/topic,41337.msg344440.html#msg344440

[A.Harrenberg]

Hi Buwe,

die alten Logs nutzen gar nichts, ich hatte Dir ja auch schon dazu geschrieben das die Logs noch mit einer älteren Version von FHEM gemacht wurden in der einige kleine aber wichtige Änderungen noch nicht drin sind.

Das "Problem" mit mehreren GET-/SET Befehlen bei WakeUp-Geräten habe ich in den diversen Thread zum Thema Security ja schon geschildert. Die Befehle werden ja "gesammelt" und nach einer WakeUp-Notification rausgeschickt. Da hier dann aus jedem einzelnen Befehle durch die Verschlüsselung eine Frage-Antwort-Kommunikation mit bis zu 8 zusammengehörenden Nachrichten wird, FHEM aber nach der ersten Nachricht gleich mit dem zweiten Befehl weitermacht kommt es hier zu einer Störung der Kommunikation.

Hier sind Rudi und ich noch in Abstimmung wie wir hier einen gesteuerten Ablauf der Kommunikation sicherstellen können damit das verhindert wird. Allerdings habe ich leider frühestens in einer Woche Zeit mich da drum zu kümmern.

Bzgl. Deines ersten Problems kann ich mir nicht vorstellen wieso die Get/Set Befehle von der Association abhängen sollen. Auch hier sind Logfiles vor dem Setzen und nach dem Setzen der Association hilfreich.

Gruß,
Andreas.

[feeeem]

Hallo krikan,

ich beziehe mich auf unsere Diskussion zu den verschiedenen baugleichen Tür/Fensterkontakten (Beiträge #9 - #14 dieses Threads). Du hattest daraufhin dankenswerterweise die XML Beschreibung vom Philio PST02-1C für den Devolo MT02648 eingebunden:

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.

Aufgrund eines günstigen Angebots habe ich mittlerweile auch ein paar Exemplare vom D-Link DCH-Z110 gekauft. Dieses Gerät hat die modelId 0108-0002-000e.

Könntest Du dafür ebenfalls die PST02-1c.xml hinterlegen?

Vielen Dank vorab!

[krikan]

Dieses Gerät hat die modelId 0108-0002-000e.

Wird in der nächsten großen Aktualisierung drin sein, die ich (hoffentlich) dieses Wochenende fertig bekomme und einchecke.

Gruß, Christian

[tmak]

Wird in der nächsten großen Aktualisierung drin sein, die ich (hoffentlich) dieses Wochenende fertig bekomme und einchecke.

Gruß, Christian

Hallo Christian,

ich bin auch gerade dabei meine ersten ZWAVE Schritte mit FHEM und dem D-Link DCH-Z110 zu machen. Sollte ich noch bis zu dem Update warten oder wird der Sensor auch jetzt schon funktionieren?

Kommt das Update dann via FHEM Update oder muss ich noch was manuell machen?

Danke und Viele Grüße
Torben

[krikan]

Hallo Torben!
Der Sensor wird auch jetzt schon funktionieren. Die XMLs erleichtern nur einiges. Details findest Du im fhemwiki im ZWave-Artikel, den Du Dir anschauen solltest.
Sind nachdem ich es eingecheckt habe im naechsten Update (fruehestens Montag)
Gruss,Christian

[krikan]

Neue XMLs sind eingecheckt. Die Philio, Devolo und D-Link - Tür-/Fensterkontakte sind enthalten. Parameter 21 und 22 habe ich nicht geändert; angegebenen Bereiche sind demnach laut Doku zu groß (s. oben im Thread).

Heute bei sourceforge http://sourceforge.net/p/fhem/code/HEAD/tree/ und morgen ab ca. 8 Uhr per automatischer Verteilung durch "update".

[feeeem]

Neue XMLs sind eingecheckt. Die Philio, Devolo und D-Link - Tür-/Fensterkontakte sind enthalten.

Danke!

[tmak]

Neue XMLs sind eingecheckt.

Super, danke für die Information! Dann werde ich meinen D-Link heute abend einmal neu einbinden!