Popp Z-Wave+ Wall Plug Switch Schuko Inklusion Assoziation POPE009006

krikan · 22 November 2015, 17:27:18

Zitat von: krikan am 22 November 2015, 17:18:49
Das habe ich verbockt, habe aber keine Ahnung woran es liegt. Wahrscheinlich habe ich mich vertippt sehe es aber nicht .

@Rudi: Habe die config in fhem_deviceconfig.xml.gz eingebaut. Anscheinend wird aber immer aus der openzwave_deviceconfig.xml.gz gezogen. Was ist mein Gedankenfehler? Erkennst Du etwas?

Schon erkannt und wirklich dämlich: Ich sollte meine Brille aufsetzen. Die Datei muss fhem_zwave_deviceconfig.xml.gz heißen. Ändere ich ab.

Sorry, Christian

EDIT: fhem_zwave_deviceconfig.xml.gz habe ich angehängt. In Ordner fhem/FHEM/lib kopieren und dann funktioniert es hoffentlich.

A.Harrenberg · 22 November 2015, 17:36:47

Hi Torsten,

Zitat von: ToKa am 22 November 2015, 16:57:52
Nachdem ich die fehlenden classes wieder manuell ergänzt habe, fehlen die Configuration Parameter aus der XML Datei immer noch. Die SET Möglichkeiten sehen wie in der Anlage aus.

Kann man den von Euch erwähnten Timeout in der fhem Konfiguration anpassen?

das Gerät meldet die Klassen einfach nicht, und ich seh' nicht das fehlende Klassen dann über die XML Datei ergänzt werden. (Rudi, Krikan?)
Hast Du die Klasse Configuration denn auch zu der Liste hinzugefügt?

Der Timeout hat darauf auch gar keinen Einfluß, der sagt ja nur das innerhalb von drei Sekunden keine Antwort kam.

Zitat von: krikan am 22 November 2015, 17:18:49
Lahme ZWave-Geräte kann FHEM grds. nicht schneller machen. Aber wir könnten get rausschmeißen (Rudi versus Andreas).

Ich hab' nichts dagegen die momentane Implementierung für das Warten auf die Antwort von get-Anfragen rauszuwerfen, die Unterscheidung in SET- und GET-Befehle muss mMn aber drin bleiben um eine Ablaufsteuerung implementieren zu können.

Gruß,
Andreas.

krikan · 22 November 2015, 17:46:35

Zitat von: A.Harrenberg am 22 November 2015, 17:36:47
und ich seh' nicht das fehlende Klassen dann über die XML Datei ergänzt werden. (Rudi, Krikan?)

Die XML-Datei in der derzeitigen Form enthält keine hinzuzufügenden Classes. War nicht eingebaut und ich kannte sie noch nicht. Aber da ich Murks gebaut habe (siehe oben), hätte auch eine erweiterte XML nicht geholfen.

@Rudi: Brauche Hilfe beim SVN einchecken. Kann ich einfach die falsch benannte Datei im SVN löschen und mit neuem Namen einchecken oder führt das zu Problemen?

Zitat
Ich hab' nichts dagegen die momentane Implementierung für das Warten auf die Antwort von get-Anfragen rauszuwerfen, die Unterscheidung in SET- und GET-Befehle muss mMn aber drin bleiben um eine Ablaufsteuerung implementieren zu können.

Mir bekannt

rudolfkoenig · 22 November 2015, 17:56:55

Zitat@Rudi: Brauche Hilfe beim SVN einchecken. Kann ich einfach die falsch benannte Datei im SVN löschen und mit neuem Namen einchecken oder führt das zu Problemen?

Im SVN lieber umbennen, dann geht die Historie nicht verloren:

Code Auswählen

svn rename fhem_deviceconfig.xml.gz fhem_zwave_deviceconfig.xml.gz
Das habe ich jetzt selbst durchgefuehrt, und alles fuer update zur Verfuegung gestellt, d.h. ihr koennt es direkt testen.
Haken: alle, die in der letzten Woche ein update durchgefuehrt haben, behalten einen nutzlosen fhem_deviceconfig.xml.gz. Wir koennten die Datei zwar automatisch nach "unused" schieben, aber dann wird diese Schiebe-Operation bei jedem update ausgefuehrt.

Soll ich es schieben oder lieber nicht?

krikan · 22 November 2015, 18:04:15

Zitatlieber nicht

Bin dafür. Denke nicht, dass die Mehrheit der User so regelmäßig Updates durchführt. (Außerdem wissen wir ja, wer es verbockt hat und wer beschimpft werden kann.

)
Rudi, danke für Deine Hilfe/Zeit.

ToKa · 22 November 2015, 18:58:34

Hallo Andreas, hallo Christian,

super, nach dem Update von fhem und einem Neustart sind jetzt die Conf Parameter aus der XML Datei als SET Parameter vorhanden. CONFIGURATION musste ich hierzu in den classes nicht angeben.

Schalter ist jetzt wieder im Garten... mal schauen ob das mit dem zeitgesteuerten Ein- und Ausschalten jetzt klappt.

Gruß
Torsten

A.Harrenberg · 22 November 2015, 20:06:25

Hallo Torsten,

Zitat von: ToKa am 22 November 2015, 18:58:34
super, nach dem Update von fhem und einem Neustart sind jetzt die Conf Parameter aus der XML Datei als SET Parameter vorhanden. CONFIGURATION musste ich hierzu in den classes nicht angeben.

ok, dann erzeugt Rudi die Befehle inklusive der Klasse aus dem XML.

Hast Du evtl. mal einen Link auf die Anleitung von dem Ding? Ich finde nur welche ohne SECURITY und ich würde doch gerne mal die Anleitung sehen die dabei war... (Oder kannst Du Deine Anleitung vielleicht einscannen?)

Ist ja schon ein ziemliches Unding das der nicht alle Klassen meldet...

Gruß,
Andreas.

ToKa · 23 November 2015, 18:20:26

Hallo Andreas,

im Anhang findest Du die Anleitung. Auf der Seite 2 unter "Product Description" findest man den Hinweis, dass das Gerät sichere Kommunikation unterstützt.

Der Schalter funktioniert aktuell bei mir jetzt bedingt. Bekomme immer wieder Timeout / NoAck Meldungen. Bin nicht sicher, ob es an der Entfernung zwischen Controller und Switch liegt. Sind ca. 15m Luftlinie, was ja kein Problem sein sollte.

Was komisch ist, die Config Änderungen kommen aber im Switch an (z.B. Änderung der LED Farbe On/Off). Die Abfrage dieser Parameter ergibt auch eine Timeout Meldung, aber das Reading wird korrekt angezeigt. Nachfolgend LOG und Event Monitor:

Code Auswählen

2015.11.23 18:32:41.708 2: ZWave get OD.Switch.GardenLights configOffColor 
2015.11.23 18:32:41.709 5: ZWDongle_Write 00 1304037005152504
2015.11.23 18:32:41.710 5: SW: 010a001304037005152504a0
2015.11.23 18:32:41.712 4: ZWDongle_ReadAnswer arg:configOffColor regexp:^00040004..70
2015.11.23 18:32:41.712 5: ACK received, WaitForAck=>2 for 010a001304037005152504a0
2015.11.23 18:32:41.718 4: ZWDongle_Read ZWAVE1: sending ACK, processing 011301
2015.11.23 18:32:41.718 5: SW: 06
2015.11.23 18:32:41.720 5: ZWAVE1 dispatch 011301
2015.11.23 18:32:44.724 5: ZWDongle_ReadAnswer: select timeout
2015.11.23 18:32:44.726 4: no response from device, removing 010a001304037005152504a0 from dongle sendstack
2015.11.23 18:32:46.235 4: ZWDongle_Read ZWAVE1: sending ACK, processing 0013040101c5
2015.11.23 18:32:46.235 5: SW: 06
2015.11.23 18:32:46.237 5: ZWAVE1 dispatch 0013040101c5
2015.11.23 18:32:46.238 4: ZWAVE1 CMD:ZW_SEND_DATA ID:01 ARG:01c5
2015.11.23 18:32:46.238 2: ZWAVE1 transmit NO_ACK for 04
2015.11.23 18:32:51.718 2: ZWave: No ACK from OD.Switch.GardenLights after 10s for sent:1304037005152504
2015.11.23 18:33:23.281 2: ZWave get OD.Switch.GardenLights configOnColor 
2015.11.23 18:33:23.282 5: ZWDongle_Write 00 1304037005162504
2015.11.23 18:33:23.283 5: SW: 010a001304037005162504a3
2015.11.23 18:33:23.284 4: ZWDongle_ReadAnswer arg:configOnColor regexp:^00040004..70
2015.11.23 18:33:23.285 5: ACK received, WaitForAck=>2 for 010a001304037005162504a3
2015.11.23 18:33:23.291 4: ZWDongle_Read ZWAVE1: sending ACK, processing 011301
2015.11.23 18:33:23.291 5: SW: 06
2015.11.23 18:33:23.293 5: ZWAVE1 dispatch 011301
2015.11.23 18:33:26.297 5: ZWDongle_ReadAnswer: select timeout
2015.11.23 18:33:26.299 4: no response from device, removing 010a001304037005162504a3 from dongle sendstack
2015.11.23 18:33:27.512 4: ZWDongle_Read ZWAVE1: sending ACK, processing 00040004057006160103
2015.11.23 18:33:27.513 5: SW: 06
2015.11.23 18:33:27.515 5: ZWAVE1 dispatch 00040004057006160103
2015.11.23 18:33:27.515 4: ZWAVE1 CMD:APPLICATION_COMMAND_HANDLER ID:04 ARG:057006160103
2015.11.23 18:33:27.573 4: ZWDongle_Read ZWAVE1: sending ACK, processing 00040004057006160103
2015.11.23 18:33:27.574 5: SW: 06
2015.11.23 18:33:27.576 5: ZWAVE1 dispatch 00040004057006160103
2015.11.23 18:33:27.576 4: ZWAVE1 CMD:APPLICATION_COMMAND_HANDLER ID:04 ARG:057006160103
2015.11.23 18:33:27.867 4: ZWDongle_Read ZWAVE1: sending ACK, processing 0013040101ca
2015.11.23 18:33:27.867 5: SW: 06
2015.11.23 18:33:27.869 5: ZWAVE1 dispatch 0013040101ca
2015.11.23 18:33:27.870 4: ZWAVE1 CMD:ZW_SEND_DATA ID:01 ARG:01ca
2015.11.23 18:33:27.870 2: ZWAVE1 transmit NO_ACK for 04
2015.11.23 18:33:33.291 2: ZWave: No ACK from OD.Switch.GardenLights after 10s for sent:1304037005162504

Code Auswählen

2015-11-23 18:32:46.314 ZWave OD.Switch.GardenLights TRANSMIT_NO_ACK
2015-11-23 18:32:46.314 ZWave OD.Switch.GardenLights transmit: NO_ACK
2015-11-23 18:33:27.564 ZWave OD.Switch.GardenLights configOnColor: BlueDefault
2015-11-23 18:33:27.604 ZWave OD.Switch.GardenLights configOnColor: BlueDefault
2015-11-23 18:33:27.915 ZWave OD.Switch.GardenLights TRANSMIT_NO_ACK
2015-11-23 18:33:27.915 ZWave OD.Switch.GardenLights transmit: NO_ACK

Kann es sein, dass manche Parameter nur über eine sichere Kommunikation funktionieren? Sorry, wenn ich eine Newbie Frage stelle...

Gruß
Torsten

krikan · 23 November 2015, 18:24:33

Zitat von: ToKa am 23 November 2015, 18:20:26
Sind ca. 15m Luftlinie, was ja kein Problem sein sollte.

Das würde ich so nicht sehen. Kann sehr wohl schon das Problem sein. Welche Hindernisse, usw sind dazwischen?

ToKa · 23 November 2015, 18:39:07

Hallo Christian,

nur die Hauswand, Fenster und Terassentür, Höhenunterschied ca. 2m. Habe im vorangehenden Post noch Log und Eventmonitor eingefügt.

Gruß
Torsten

A.Harrenberg · 23 November 2015, 19:18:41

Hi Torsten,

Zitat von: ToKa am 23 November 2015, 18:20:26
im Anhang findest Du die Anleitung. Auf der Seite 2 unter "Product Description" findest man den Hinweis, dass das Gerät sichere Kommunikation unterstützt.

die Anleitung ist genauso schlecht wie das Gerät...
Im Text steht wie von Dir beschrieben das SECURITY unterstütz wird, die Klasse SECURITY taucht aber nicht in der Tabelle auf Seite 5/6 auf...

Laut Tabelle soll das Ding auch MULTI_CHANNEL haben, meldet es auch nicht...

Zitat von: ToKa am 23 November 2015, 18:20:26
Kann es sein, dass manche Parameter nur über eine sichere Kommunikation funktionieren? Sorry, wenn ich eine Newbie Frage stelle...

Also, ein "normales" Device sendet während der Inklusion seine Daten an den Controller, darin ist kodiert was für eine Art Gerät es ist und welche Befehlsklassen es unterstützt. Diese Rückmeldung wird von FHEM ausgwertet, in "classes" abgelegt und bestimmt welche Befehle Du über die Drop-Down Menüs bei SET bzw. GET auswählen kannst. Nicht unterstützte Befehle tauchen dadurch gar nicht erst in der Liste auf.

Wenn nun so ein Gerät wie dieser Schalter hier einige seiner Befehlsklassen nicht meldet, werden diese fehlenden Befehle natürlich auch nicht angeboten.

Wird nun ein Gerät mit SECURITY inkludiert geht der erste Teil ganz normal ab, d.h. das Gerät meldet die unterstützten Befehlsklassen die OHNE SECURITY unterstützt werden. Erst danach wird der SECURITY Modus ausgehandelt und das Passwort gesetzt. Im Anschluß daran werden die Befehlsklassen MIT SECURITY abgefragt, diese werden nicht automatisch gemeldet. Diese Befehlsklassen werden in "secure_classes" abgelegt.

Sollte da jetzt eine Klasse auftauchen die auch in classes vorhanden ist, so bedeutet das normalerweise das diese Klasse ab sofort nur noch verschlüsselt funktioniert, was aber für den Anwender transparent ist.

Es gibt aber auch den Fall das Funktionen NUR unter SECURITY angeboten werden, d.h. die Klasse in secure_classes vorhanden ist aber (vorerst noch) nicht in classes. Damit FHEM nun diese Befehle auch im Drop-Down anzeigen kann, werden diese "neuen" Klassen zu den bereits vorhandenen classes kopiert.

Also ja, es gibt Befehle / Befehlsklassen die nur über eine sichere Kommunikation funktionieren, dies sollte aber in der Beschreibung des Geräte eindeutig beschrieben sein.
In diesem Fall ist POPP ja nicht mal in der Lage die SECURITY Klasse selbst anzugeben...

Gruß,
Andreas.

ToKa · 23 November 2015, 20:37:39

Hallo Andreas,

danke für die genaue Erklärung. Als ich den Switch mit "SEC" inkludiert hatte, war auch die Klasse "MULTI_CHANNEL" dabei. Hatte mir ja von diesem Versuch alle Klassen gesichert und setze diese manuell.

Bin nun etwas ratlos, ob dich den Switch behalten soll? Hatte aber beim googlen auch keinen anderen für den Outdoorbereich gefunden.

Gruß
Torsten

krikan · 23 November 2015, 20:51:23

Zitat von: ToKa am 23 November 2015, 18:39:07
nur die Hauswand, Fenster und Terassentür, Höhenunterschied ca. 2m. Habe im vorangehenden Post noch Log und Eventmonitor eingefügt.

Das kann schon zu viel sein. Mein Fibaro-Rolladenaktor mit einer Entfernung von 5-6m zum Dongle (Wand und Decke dazwischen) bekommt nur stabile Verbindung mit einem Router dazwischen. Sonst fehlen die ACK vom Aktor häufig und get-Befehle werden unzuverlässig beantwortet; Befehle vom Dongle an Aktor kommen aber regelmäßig an. Ähnelt Deiner Situtation.

Timeout bedeutet nur, dass die Antwort nicht vor einer von FHEM bestimmten, eigentlich zu langen Zeit eingetroffen ist. Auch wenn die Antwort nach Timeout bei FHEM eintrifft wird sie verarbeitet.

Wie Andreas schon schreibt, gibt es einige Besonderheiten beim Aktor.
Mich würde die ZWave+ Zertifizierungsnummer interessieren. In products.zwavealliance.com taucht der Popp immer noch nicht auf. Der Zwave.me http://zwave.me/index.php?id=40, der äußerlich ähnlich aussieht, hat laut Homepage nur eine ZWave-Zertifizierung. Aber die pepper1 Einträge weisen auch ZWave+-Classes aus.

Gruß, Christian

A.Harrenberg · 23 November 2015, 21:01:14

Hi Torsten,

Zitat von: ToKa am 23 November 2015, 20:37:39
Bin nun etwas ratlos, ob dich den Switch behalten soll? Hatte aber beim googlen auch keinen anderen für den Outdoorbereich gefunden.

tja, die Entscheidung kann Dir keiner abnehmen...
Da Du ja Outdoor brauchst wirst Du kaum Alternativen haben. Das mit den Befehlsklassen kann man ja verkraften wenn man die manuell ergänzt, FHEM ist da ja recht flexibel.

Und wer weiß, vielleicht gibt es ja mal ein Firmwareupdate... OTA kann das Ding ja.

Das Reichweitenproblem wird wahrscheinlich auch bei anderen Produkten auftreten. Falls möglich kannst Du ja versuchen eine anderen Steckdosenschalter (indoor) besser zu platzieren und den dann als Router zu benutzen.

Solange es keine wirkliche Alternative gibt würde ich den wahrscheinlich behalten.

Gruß,
Andreas.

krikan · 30 November 2015, 18:45:42

Der Aktor wird mir nach Durchsicht dieses Forenthemas http://forum.z-wave.me/viewtopic.php?f=3419&t=22399 immer suspekter:

Laut den Angaben dort, hat der Aktor keinen "real meter". Die Verbräuche werden vielmehr durch Festlegen des Verbrauchs mit dem Parameter 20 und Multiplikation dieses Wertes mit der Anschaltzeit des Aktors ermittelt.

Unter http://products.z-wavealliance.org wird der immer noch nicht geführt.....