Vision ZM1601 Battery Operated Siren

Begonnen von gamauf, 13 November 2015, 18:19:02

Vorheriges Thema - Nächstes Thema

krikan

Habe mir die Infos zu Eurer Sirene mal näher angeschaut:

Das ist die ZWave+-Version ZM1601EU-5 zu der man das korrekte Handbuch hier findet: http://products.zwavealliance.com/products/1009
Danach sind die beiden Parameter 1 und 2 und nicht mehr wie bei den Vorgängerversionen 0 und 1 ohne +. Das ist bisher nicht in den XMLs unterschieden worden und korrigiere ich.

Viel spannender finde ich aber, dass das scheinbar ein FLIRS-Geräte ist und nicht ein Standard-WakeUp-Device. Die class WAKE_UP fehlt auch im list von Andreas. Das Gerät sollte alle von FHEM versandten Befehle sofort verarbeiten. Man muss wohl nicht auf die nächste wakeUpNotification warten. Meines Wissens nach ist es das erste FLIRS-Gerät, das unter FHEM genutzt wird.

Funktioniert bei Euch -abgesehen von den Config-XML-Fehlern- das Gerät ohne Probleme? Gibt es keine Telegrammverluste (NO_ACK) oder andere Auffälligkeiten im Betrieb? Ich hatte die Infos im Internet immer so verstanden, dass für FLIRS-Geräte noch etwas in FHEM angepasst werden muss. Das wäre dann ggfs. nicht so.

Könnte einer von Euch das Ergebnis der Abfrage von "get <ZWDongle> nodeInfo" für den entsprechenden Geräte-Node posten; am liebsten mit dem zugehörigen Log (verbose 5)?

Danke und Gruß, Christian


gamauf

Hallo Christian!

Hier die Antwort aufs get nodeInfo:
ZWDongle_0 nodeInfo_15 => ROUTING_SLAVE SWITCH_BINARY sleeping frequentListening:64 beaming:16 routing 40kBaud Vers:4 Security:0
und der Log-Auszug:
2015.11.18 19:15:25 4: ZWDongle get ZWDongle_0 nodeInfo 15
2015.11.18 19:15:25 5: ZWDongle_Write 00 410f
2015.11.18 19:15:25 5: SW: 010400410fb5
2015.11.18 19:15:25 4: ZWDongle_ReadAnswer arg:nodeInfo regexp:^0141
2015.11.18 19:15:25 5: ACK received, removing 010400410fb5 from dongle sendstack
2015.11.18 19:15:25 4: ZWDongle_Read ZWDongle_0: sending ACK, processing 014153dc01041005
2015.11.18 19:15:25 5: SW: 06
2015.11.18 19:15:25 4: ZWDongle_ReadAnswer for nodeInfo: 014153dc01041005


Habe mich mit dem
set ZW_Sirene_1 blink 1 1
Befehl herumgespielt. der scheint kurz hintereinander ein
set ZW_Sirene_1 on
und
set ZW_Sirene_1 off
zu senden. Mir ist aufgefallen, daß anscheinend das Acknowledge auf das "off" nicht immer ankommt und daher FHEM die Sirene noch immer als "on" zeigt. hier das Log dazu:
2015.11.18 19:18:56 2: ZWave set ZW_Sirene_1 on
2015.11.18 19:18:56 5: ZWDongle_Write 00 130f032501FF250f
2015.11.18 19:18:56 5: SW: 010a00130f032501FF250f1b
2015.11.18 19:18:56 5: ACK received, WaitForAck=>2 for 010a00130f032501FF250f1b
2015.11.18 19:18:56 4: ZWDongle_Read ZWDongle_0: sending ACK, processing 011301
2015.11.18 19:18:56 5: SW: 06
2015.11.18 19:18:56 5: ZWDongle_0 dispatch 011301
2015.11.18 19:18:57 2: ZWave set ZW_Sirene_1 off
2015.11.18 19:18:57 4: ZWDongle_Read ZWDongle_0: sending ACK, processing 00130f000085
2015.11.18 19:18:57 5: SW: 06
2015.11.18 19:18:57 5: device ack reveived, removing 010a00130f032501FF250f1b from dongle sendstack
2015.11.18 19:18:57 5: ZWDongle_0 dispatch 00130f000085
2015.11.18 19:18:57 4: ZWDongle_0 CMD:ZW_SEND_DATA ID:00 ARG:0085
2015.11.18 19:18:57 4: ZWDongle_0 transmit OK for 0f
2015.11.18 19:18:57 5: ZWDongle_Write 00 130f03250100250f
2015.11.18 19:18:57 5: SW: 010a00130f03250100250fe4
2015.11.18 19:18:57 4: ZWDongle_Read ZWDongle_0: sending ACK, processing 0004000f032503ff
2015.11.18 19:18:57 5: SW: 06
2015.11.18 19:18:57 5: ZWDongle_0 dispatch 0004000f032503ff
2015.11.18 19:18:57 4: ZWDongle_0 CMD:APPLICATION_COMMAND_HANDLER ID:0f ARG:032503ff
2015.11.18 19:18:57 4: ZWDongle_Read ZWDongle_0: CAN received
2015.11.18 19:18:58 2: ZWDongle_ProcessSendStack: no ACK, resending message 010a00130f03250100250fe4
2015.11.18 19:18:58 5: SW: 010a00130f03250100250fe4
2015.11.18 19:18:58 5: ACK received, WaitForAck=>2 for 010a00130f03250100250fe4
2015.11.18 19:18:58 4: ZWDongle_Read ZWDongle_0: sending ACK, processing 011301
2015.11.18 19:18:58 5: SW: 06
2015.11.18 19:18:58 5: ZWDongle_0 dispatch 011301
2015.11.18 19:18:58 4: ZWDongle_Read ZWDongle_0: sending ACK, processing 00130f000003
2015.11.18 19:18:58 5: SW: 06
2015.11.18 19:18:58 5: device ack reveived, removing 010a00130f03250100250fe4 from dongle sendstack
2015.11.18 19:18:58 5: ZWDongle_0 dispatch 00130f000003
2015.11.18 19:18:58 4: ZWDongle_0 CMD:ZW_SEND_DATA ID:00 ARG:0003
2015.11.18 19:18:58 4: ZWDongle_0 transmit OK for 0f
2015.11.18 19:18:58 4: ZWDongle_Read ZWDongle_0: sending ACK, processing 0004000f03250300
2015.11.18 19:18:58 5: SW: 06
2015.11.18 19:18:58 5: ZWDongle_0 dispatch 0004000f03250300
2015.11.18 19:18:58 4: ZWDongle_0 CMD:APPLICATION_COMMAND_HANDLER ID:0f ARG:03250300

wobei diesmal das Acknowledge erkannt wurde.
Weiß nicht, ob das etwas mit dem FLIRS zu tun hat.

Grüße
Rainer

A.Harrenberg

Hallo Rainer,
Zitat von: gamauf am 18 November 2015, 13:44:48
Hallo Andreas Harrenberg!

Danke für Dein Feedback.
Nachdem nach Exclusion und erneuter Inclusion eine neue ID vergeben wird und ich danach die Konfiguration entsprechend nacharbeiten muß, brauche ich um die verschlüsselte Kommunikation zu testen etwas mehr Zeit am Stück, als ich jetzt gerade habe.
Werde das daher ein anderes Mal testen.

Keine Eile, ich habe ja noch die Baustelle mit dem Eintrag für Association, solange Du das händisch nachträgst ist ja erst mal alles in Ordnung. Es wird dann allerdings keine automatische Association eingetragen.

Gruß,
Andreas.
FB 7360, Homematic und ZWave
Support for ZWave-SECURITY

krikan

@Rainer: Vielen Dank für die Logs und Infos.

Zitat von: gamauf am 18 November 2015, 19:29:16
Weiß nicht, ob das etwas mit dem FLIRS zu tun hat.
Glaube nicht, dass das mit FLIRS zusammenhängt. Man müsste mal den Fehlerfall sehen. Vielleicht kann man mehr Schlüsse ziehen.

Nach nochmaliger Lektüre der (schmalen) Infos zu FLIRS: FLIRS-Geräte müssten vollständig durch FHEM unterstützt sein. Laut zwapi wird der wakeup-Beam automatisch an die FLIRS-Geräte verschickt, wenn eine Nachricht für das FLIRS-Gerät ansteht. Voraussetzung ist natürlich, dass die Nachbarn des FLIRS-Gerätes beaming (Versand von wakeup-Beams) unterstützten. Das sollten aber wohl alle aktuellen Geräte können.

Die korrigierten XMLs werden heute mit dem update verteilt. Ich hoffe, es läuft problemlos. Habe nämlich auch noch einige configs von jeedom-openzwave aufgenommen und das war ein bißchen hackelig.

scooty

Zitat von: krikan am 19 November 2015, 11:23:20
Die korrigierten XMLs werden heute mit dem update verteilt.

Sorry falls ich nerve, hatte heute ein FHEM-Update gemacht und in der heutigen openzwave_deviceconfig.xml.gz waren zumindest bei mir die Änderungen auf  "index="1"" und "index="2" leider nicht drin.

Andreas
Fhem auf Gigabyte Brix
CUL V3 HM / CUL V3 MAX / MaxCube aFW Homematic&MAX / ZWave.me ZME_UZB1 / SDuino 433 / Velux KLF200
Homematic / MAX / Logitech Hub / ZWave / Wifi LED / div. 433 Temperatursensoren / pywws WH10880 / IO Homecontrol

krikan

Hallo Andreas!
Hier nervt niemand.  :)
War von mir unzureichend erklärt. Du/Ihr müsstest bitte einmal "get <device> model" für die Sirene neu abrufen. Dann sollte die neue Config-XML "vision/zm1601eu_5.xml" mit den hoffentlich richtigen Werten genommen werden. Ansonsten bitte beschweren.
Gruß, Christian

gamauf

Hallo Christian!
Wenn Du schon dabei bist die XMLs zu aktualisieren, dürfte ich Dich bitten dieses Gerät auch gleich einzupflegen:
http://pepper1.net/zwavedb/device/842
http://forum.fhem.de/index.php/topic,42736.msg349698.html#msg349698
Ich glaub, daß es noch nicht drin ist.
Hab mir nämlich grad so ein Teil bestellt.

Steht in der pepper DB als Z-Wave.Me Gerät, wird aber von Popp vermarktet.

Danke!
Rainer

krikan

Hallo Rainer,
die Popp-Version (modelId 0064-0004-0002) ist seit gestern eingebunden. Kontrollieren darfst Du die XML noch, ob alles korrekt ist  ;).
Gruß, Christian

scooty

Zitat von: krikan am 19 November 2015, 12:49:58
Ansonsten bitte beschweren.
Hallo Christian,

kein Grund zur Beschwerde, funktioniert nach "get <device> model" wie gewünscht, vielen Dank.
:)

Sorry für Off-Topic und nur zu meinem Verständnis:
Wann genau oder was veranlasst ein ZWave-Device seine spezifische XML-Datei auszulesen?
Im Wiki steht
Zitatim Rahmen der Inklusion oder durch manuellen Aufruf des Befehls get <name> model
aber z.B. auch nach einem "shutdown restart" sind entsprechende Einträge im FHEM-Log bei mir zu finden.

Vielen Dank nochmals,
Andreas
Fhem auf Gigabyte Brix
CUL V3 HM / CUL V3 MAX / MaxCube aFW Homematic&MAX / ZWave.me ZME_UZB1 / SDuino 433 / Velux KLF200
Homematic / MAX / Logitech Hub / ZWave / Wifi LED / div. 433 Temperatursensoren / pywws WH10880 / IO Homecontrol

krikan

Zitat von: scooty am 19 November 2015, 13:11:35
Wann genau oder was veranlasst ein ZWave-Device seine spezifische XML-Datei auszulesen?
Eigentlich Rudis Thema, aber ich versuche mich:
Duch den Abruf von "get <device> model" wird aufgrund der ermittelten modelId das zugehörige config-XML festgelegt; ersichtlich im entsprechenden Reading. Das config-XML wird dann durch FHEM während der Programmlaufzeit u.a. beim Aufruf der Detailseite des Devices ausgelesen. Wenn ich den Dateinamen des config-XMLs -wie hier- ändere, muss eben neu abgefragt werden.

gamauf

Zitat von: krikan am 19 November 2015, 12:58:47
...die Popp-Version (modelId 0064-0004-0002) ist seit gestern eingebunden...
Super, danke!

illky

Hallo,

bei der ZM1602 sind auch die Parameter nicht richtig zugeordnet:

model Vision ZM1602 Main Operated Siren
modelConfig vision/zm1602eu.xml
modelId 0109-2009-0908

VG Stefan

krikan

Hallo Stefan!
Was meinst Du damit? Muss das auch 1 und 2 sein? Ist das auch eine ZWave+ Version?
Gruß, Christian

krikan

Hab es selbst gefunden. Ist auch ZWave+. Ich checke die Änderung gleich ein. Kommt morgen ab 8 per update.