Hallo zusammen,
ich probiere gerade ein Z-Stick mit einem düwi Funk-Schalter Zwischenstecker ZW ZSA 3500 und einem düwi Funk-Dimmer Zwischenstecker ZW ZDAN 300 aus.
Den Funk Schalter konnte ich problemlos einbinden, aber den Funk-Dimmer kann ich nicht schalten.
Wenn ich ein "set ZWDongle_0 createNode 2" ausführe, wird der Dimmer ganz brav unter ZWAVE angelegt.
Leider kann ich den Dimmer aber dann weder schalten noch dimmen. Es fehlt oben das "set".
Wenn ich ein "set ZWave_SWITCH_MULTILEVEL_2 on" ausführe, bekomme ich "Unknown set argument on, choose one of" zurück.
Ist ein "SWITCH_MULTILEVEL" (ZWDongle_0 nodeInfo_2 => ROUTING_SLAVE SWITCH_MULTILEVEL listening routing 40kBaud Vers:3 Security:0)
einfach nur noch nicht implementiert, oder habe ich etwas falsch gemacht?
Gruß
Torsten
SWITCH_MULTILEVEL ist nicht implementiert, siehe auch 10_ZWave.pm: %zwave_class, was implementiert ist.
Details findet man im ZWave_CommandClassSpec.pdf (SDS11060), was auch auf dem Web zu finden ist.
Ich schlage folgendes vor:
SWITCH_MULTILEVEL => { id => '26' },
zu ersetzen mit
SWITCH_MULTILEVEL => { id => '26',
set => { off => "0100",
on => "01FF",
dim => "01%02x", },
get => { swmStatus => "02", },
parse => { "03.00.(.*)"=> '($1 == "00" ? "state:off" :
($1 == "ff" ? "state:on" :
"dim:".hex($1)))',}, },
Insb. beim parse bin ich unsicher, da ich es nicht testen kann.
Laut Doku gibt es auch noch weitere Kommandos, die man gerne implementieren kann.
Falls es funktioniert, bitte Bescheid geben, ich check das dann ein.
Hallo Rudolf,
funktioniert! Ich kann on/off schalten, oder direkt das Lampen Symbol für on/off drücken.
Dimmen kann ich über die Werte 0-99. Danach steht hinter dem Device der Wert z.B. "dim 50".
Das mit dem parse habe ich nicht so ganz verstanden. Kannst du mir das kurz erklären?
Wenn ich set on ausführe ist state auf on, oder bezieht sich das auf das Dimmen?
Vielen Dank für die schnelle Hilfe.
Gruß Torsten
Parse ist zum dekodieren der Antwort auf einem "get" notwendig.
Falls das nicht funktioniert, wuerde mir helfen debug-Ausgaben mit maximalen Loglevel zu sehen.
Dimmer
2013.01.13 12:00:51 5: Cmd: >get ZWave_SWITCH_MULTILEVEL_2 swmStatus<
2013.01.13 12:00:51 5: SW: 010800130202260205c5
2013.01.13 12:00:51 5: ZWDongle/RAW: /06
2013.01.13 12:00:51 5: ZWDongle/RAW: /0104011301e8
2013.01.13 12:00:51 5: SW: 06
2013.01.13 12:00:51 5: ZWDongle_Read ZWDongle_0: 011301
2013.01.13 12:00:51 5: ZWDongle_0 dispatch 011301
2013.01.13 12:00:51 5: ZWDongle/RAW: /01090004000203260363b5
2013.01.13 12:00:51 5: SW: 06
2013.01.13 12:00:51 5: ZWDongle_Read ZWDongle_0: 0004000203260363
2013.01.13 12:00:51 4: ZWDongle_0 APPLICATION_COMMAND_HANDLER 02 (03260363)
kommt nichts zurück
und zur Gegenprobe mit dem Schalter
2013.01.13 12:01:54 5: Cmd: >get ZWave_SWITCH_BINARY_3 swbStatus<
2013.01.13 12:01:54 5: SW: 010800130302250205c7
2013.01.13 12:01:54 5: ZWDongle/RAW: /06
2013.01.13 12:01:54 5: ZWDongle/RAW: /0104011301e8
2013.01.13 12:01:54 5: SW: 06
2013.01.13 12:01:54 5: ZWDongle_Read ZWDongle_0: 011301
2013.01.13 12:01:54 5: ZWDongle_0 dispatch 011301
2013.01.13 12:01:54 5: ZWDongle/RAW: /01090004000303250300d4
2013.01.13 12:01:54 5: SW: 06
2013.01.13 12:01:54 5: ZWDongle_Read ZWDongle_0: 0004000303250300
2013.01.13 12:01:54 4: ZWDongle_0 APPLICATION_COMMAND_HANDLER 03 (03250300)
2013.01.13 12:01:54 5: Triggering ZWave_SWITCH_BINARY_3 (1 changes)
2013.01.13 12:01:54 5: Notify loop for ZWave_SWITCH_BINARY_3 off
state:off
> 2013.01.13 12:00:51 4: ZWDongle_0 APPLICATION_COMMAND_HANDLER 02 (03260363)
> kommt nichts zurück
Klar, mein Regexp "03.00.(.*)" trifft den Wert (03260363) nicht.
Versuch es mal bitte mit "032603(.*)" als regexp, das sollte klappen.
Ich habe die Aenderungen dokumentiert und eingecheckt.
Was fehlt ist eine bessere bzz. automatische Unterstuetzung des dimmers per slider in FHEMWEB, das muss man z.Zt. noch manuell basteln. Siehe auch commandref.html Beispiele bei webCmd.
"032603(.*)" funktioniert!
Jetzt habe ich das auch mit dem "parse" verstanden.
Den Slider habe ich mir aus einem webCmd und einem dummy gebastelt. Meintest du das so, oder geht es noch eleganter?
Danke und Gruß
Torsten
Etwas "eleganteres" kenne ich im Moment auch nicht.
Eigentlich muesste das Modul selbst sowas zurueckliefern, damit Du das gar nichts machen musst, aber das fehlt noch in dem generischen Aufbau.
All,
dieser Thread kam wie gerufen. Ich stand gestern vor exakt der selben Aufgabenstellung :-)
Vielen Dank erstmal!
Jetzt fiel mir allerdings auf, dass FHEM nicht mitbekommt wenn ich manuell schalte/dimme. ich habe mir auch schon des angesprochene PDF durchgelesen, finde aber die Zahlenwerte für die entsprechenden Kommandos nicht um den entsprechenden Multilevel Switch Report zu implementieren (geschweige von meinen mangelhaften Perl Kenntnissen ;-) )
Könntet Ihr mit da bitte einen kleinen Tipp geben?
Danke!
Ich habe die o.g. Aenderungen (+reportOn/reportOff) jetzt eingecheckt, ist per update verfuegbar.
Manuelle Aenderungen sollten nach einem "reportOn" vom Geraet gemeldet werden und dank den Parse Eintrag in events umgewandelt werden. Das ist alles nur Theorie, da ich kein Geraet habe. Finde ich auch doof, dass die Konstanten in dem PDF nicht hinterlegt sind, ich habe sie aus AZW extrahiert (Vorgaenger von ZWave.me).
Wow! Vielen Dank für die schnelle Reaktion!
Ich habe den update ausgeführt, die Kommandos werden ausgeführt allerdings sehe ich kein Reporting...
Welche Infos kann ich liefern um das Problem zu debuggen?
Steht doch weiter oben: "debug-Ausgaben mit maximalen Loglevel". Also
attr global verbose 5, und dann schalten.
Falls nichts in der log steht, dann vermute ich, dass das Geraet das reportOn nicht mitbekommen hat, oder reporting fuer eine andere Zentrale konfiguriert ist (mWn kann nur ein Empfaenger fuer solche reports eingetragen sein). Das kann man wiederum mit dem association Kommandos und Bedienungsanleitung pruefen.
Ok folgender Output:
Eingabe von set <device> reportOn
2013.01.18 17:37:31 5: Cmd: >set zw1 reportOn<
2013.01.18 17:37:31 0: SW: 0109001303032603FF053a
2013.01.18 17:37:31 5: Triggering zw1 (1 changes)
2013.01.18 17:37:31 5: Notify loop for zw1 reportOn
2013.01.18 17:37:31 5: ZWDongle/RAW: /06
2013.01.18 17:37:31 5: ZWDongle/RAW: /0104011301e8
2013.01.18 17:37:31 0: SW: 06
2013.01.18 17:37:31 0: ZWDongle_Read zwif: 011301
2013.01.18 17:37:31 5: zwif dispatch 011301
Leider ein Eintrag im Logfile nach manuellem Schalten...
Sooorry Tippfehler :-(
Zitat von: thunder schrieb am Fr, 18 Januar 2013 21:59Ok folgender Output:
Eingabe von set <device> reportOn
2013.01.18 17:37:31 5: Cmd: >set zw1 reportOn<
2013.01.18 17:37:31 0: SW: 0109001303032603FF053a
2013.01.18 17:37:31 5: Triggering zw1 (1 changes)
2013.01.18 17:37:31 5: Notify loop for zw1 reportOn
2013.01.18 17:37:31 5: ZWDongle/RAW: /06
2013.01.18 17:37:31 5: ZWDongle/RAW: /0104011301e8
2013.01.18 17:37:31 0: SW: 06
2013.01.18 17:37:31 0: ZWDongle_Read zwif: 011301
2013.01.18 17:37:31 5: zwif dispatch 011301
Leider kein Eintrag im Logfile nach manuellem Schalten...
Damit ist der Abschnitt "Falls nichts..." meines Antwortes abzuarbeiten :)
Selbst ein Factory reset am Dimmer brachte keine Änderung...
In der Betriebsanleitung habe ich leider nichts gefunden. Wie löse ich die assoc Kommandos aus?
Viel mehr als im http://fhem.de/commandref.html#ZWaveget (//fhem.de/commandref.html#ZWaveget) dazu steht kann ich auch nicht sagen.
Habe noch versucht direkt den Status des Dimmers zu lesen:
2013.01.19 17:34:32 4: HTTP FHEMWEB:192.168.10.164:25485 GET /fhem?cmd=get+zw1+swmStatus
2013.01.19 17:34:32 5: Cmd: >get zw1 swmStatus<
2013.01.19 17:34:32 0: SW: 010800130302260205c4
2013.01.19 17:34:32 5: ZWDongle/RAW: /060104011301e8
2013.01.19 17:34:32 0: SW: 06
2013.01.19 17:34:32 0: ZWDongle_Read zwif: 011301
2013.01.19 17:34:32 5: zwif dispatch 011301
Beim cyberdwarf kam auf die gleiche Frage was ganz anderes zurueck. Die Antwort ist deswegen auch komisch, weil es keine Angaben zum Geraet (ID) enthaelt, insofern mit dem aktuellen Funktionen nicht verwendbar ist. Was fuer ein USB-Stick ist es?
Aeon Labs Z-Stick S2
gibt es sticks die besser laufen?
Ich kann nur sagen, dass mit dem von mir getesteten Goodway WD6001 die Daten von einem AN158 (switch-binary) so gemeldet werden, wie das auch beim cyberdwarf zu sehen war. Einen Dimmer habe ich nie gesehen.
Apropos Dimmer: der ZWave-Dimmer presentiert sich in FHEMWEB jetzt automatisch mit einem slider.
Hallo zusammen,
ich habe auch den Aeon Labs Z-Stick S2.
Bei mir meldet er nach einem "get ZWave_SWITCH_MULTILEVEL_2 swmStatus" den Wert zurück (z.B. dim45).
Was allerdings bei mir auch nicht geht, ist die automatische Rückmeldung, wenn der Taster am Dimmer betätigt wird. Ein reportOn habe ich auch abgesetzt.
Ich muss dann wieder ein "get ZWave_SWITCH_MULTILEVEL_2 swmStatus" ausführen.
Ich habe aber schon die nächste Baustelle und zwar einen Wandschalter Düwi 05443. Diesen habe ich über "include" in mein ZWave Netzwerk aufgenommen. Der Wandschalter wird unter FHEM als "ZWave_GENERIC_CONTROLLER_2" erkannt und angelegt.
Wenn ich die Auf oder Ab Taste 3x drücke steht im Log folgendes:
2013.01.21 23:37:59 5: ZWDongle/RAW: /0112004984020c0101018070758672858e7784a6
2013.01.21 23:37:59 5: SW: 06
2013.01.21 23:37:59 5: ZWDongle_Read ZWDongle_0: 004984020c0101018070758672858e7784
2013.01.21 23:37:59 5: ZWDongle_0 dispatch 004984020c0101018070758672858e7784
Mir gelingt es allerdings nicht, den Secondary Controller mit dem Dimmer zu binden. Wenn jemand dazu einen Tipp hat, wäre ich sehr dankbar.
@Rudolf
Danke für den Slider, bin auf das Update gespannt.
Gruß
Torsten
...bin am verzweifeln...
habe jetzt den Stick wie unter http://www.digiwave.dk/forum/viewtopic.php?f=2&t=115 (//www.digiwave.dk/forum/viewtopic.php?f=2&t=115) beschrieben zurückgesetzt und die Danvos SW kann unter Windows den Status lesen. Unter Linux ( 2.6.26-2-xen-amd64 #1 SMP Thu Nov 25 06:39:26 UTC 2010 x86_64 GNU/Linux) habe ich nach wie vor den timeout... :-(
@cyberdwarf: wie genau hast Du den Dimmer definiert? Könnte ich bitte den entsprechenden Auszug aus deiner .cfg bekommen?
Danke für Eure Hilfe...
nochmals kurz das aktuelle Log...
2013.01.31 14:28:29 5: Cmd: >get zw1 swmStatus<
2013.01.31 14:28:29 2: ZWave get zw1 swmStatus
2013.01.31 14:28:29 5: SW: 010800130202260205c5
2013.01.31 14:28:29 5: ZWDongle/RAW: /06
2013.01.31 14:28:29 5: ZWDongle/RAW: /0104011301e8
2013.01.31 14:28:29 5: SW: 06
2013.01.31 14:28:29 5: ZWDongle_Read zwif: 011301
2013.01.31 14:28:29 5: zwif dispatch 011301
Hallo thunder,
ich führe einget ZWDongle_0 nodeList
aus und erhalte eine Liste aller Geräte IDs
ZWDongle_0 nodeList => 1,2,3,4,5,6,7,8,9
Dann nehme ich mir die entsprechende ID und führe
set ZWDongle_0 createNode 3
aus.
Danach wird automatisch ein Eintrag in der .cfg erzeugt, der dann so aussieht.
define ZWave_SWITCH_MULTILEVEL_3 ZWave 0161d5d2 3
attr ZWave_SWITCH_MULTILEVEL_3 classes MANUFACTURER_SPECIFIC VERSION HAIL INDICATOR PROTECTION SWITCH_ALL SWITCH_MULTILEVEL
attr ZWave_SWITCH_MULTILEVEL_3 room ZWave
define FileLog_ZWave_SWITCH_MULTILEVEL_3 FileLog ./log/ZWave_SWITCH_MULTILEVEL_3-%Y.log ZWave_SWITCH_MULTILEVEL_3
attr FileLog_ZWave_SWITCH_MULTILEVEL_3 logtype text
attr FileLog_ZWave_SWITCH_MULTILEVEL_3 room ZWave
Gruß
Torsten
Zitat von: thunder schrieb am Fr, 18 Januar 2013 08:35All,
Jetzt fiel mir allerdings auf, dass FHEM nicht mitbekommt wenn ich manuell schalte/dimme.
Ähnliches Verhalten hier. Bei meinem SWITCH_BINARY wird bei Aktion über das Webfrontend state auf "on" oder "off" gesetzt. Schaltungen am Schalter landen jedoch in basicReport "00" oder "ff" (nach Aufnahme des USB Sticks in AssocGroup_01).
Ist das jetzt der noch recht frischen ZWave Implementierung geschuldet, oder meinen noch fast gar nicht vorhandenen FHEM Kenntnissen?
Zumindest als Workaround müsste ja ein entsprechendes update des state Readings bei Änderung des basicReport Wertes das gewünschte Ergebnis bringen.
Bin für jeden Tipp dankbar!
Irgendar läuft bei mir grundsätzlich schief... :-(
Ich habe jetzt nochmals die ganze ZWafe config entfernt und bin wie folgt vorgegangen:
usb scan
habe dann den entsprechenden define Befehl mit cut&paste in di eCommandozeile eingegeben und damit den Dongle definiert
define ZWDongle_0 ZWDongle /dev/ttyUSB0@115200
danach mit
get ZWDongle_0 nodeList
ZWDongle_0 nodeList => 1,2
die bekannten Nodes (1=Stick, 2=Dimmer) abgefragt
leider kam auf den
set ZWDongle_0 createNode 2
dann null Reaktion. Mit vollem verboselevel (5) bekam ich folgendes im Logfile:
2013.01.31 19:44:41 5: Cmd: >set ZWDongle_0 createNode 02<
2013.01.31 19:44:41 5: Triggering ZWDongle_0 (1 changes)
2013.01.31 19:44:41 5: Notify loop for ZWDongle_0 createNode 02
2013.01.31 19:44:41 5: ZWDongle/RAW: /06
2013.01.31 19:44:41 5: ZWDongle/RAW: /01040160019b
2013.01.31 19:44:41 5: ZWDongle_0 dispatch 016001
2013.01.31 19:44:41 4: HTTP FHEMWEB:192.168.10.164:37068 GET /fhem?detail=ZWDongle_0
2013.01.31 19:44:41 4: /fhem?detail=ZWDongle_0 / RL: 2015 / text/html; charset=UTF-8 / Content-Encoding: gzip
/
2013.01.31 19:44:41 4: HTTP FHEMWEB:192.168.10.164:37068 GET /fhem/css/style.css
2013.01.31 19:44:41 4: HTTP FHEMWEB:192.168.10.164:37063 GET /fhem/js/svg.js
2013.01.31 19:44:41 4: Connection accepted from FHEMWEB:192.168.10.164:37070
2013.01.31 19:44:41 4: HTTP FHEMWEB:192.168.10.164:37068 GET /fhem/js/fhemweb.js
2013.01.31 19:44:41 4: HTTP FHEMWEB:192.168.10.164:37068 GET /fhem/icons/icoEverything
2013.01.31 19:44:41 5: ZWDongle/RAW: /0106004981000031
2013.01.31 19:44:41 5: ZWDongle_0 dispatch 0049810000
2013.01.31 19:44:41 4: HTTP FHEMWEB:192.168.10.164:37068 GET /fhem?room=all&XHR=1&inform=1
2013.01.31 19:44:44 4: Connection closed for FHEMWEB:192.168.10.164:37068
Leider kann ich mit der PC-Software die Firmware Version des Sticks nicht auslesen....
um sicher zu gehen habe ich den Stick noch auf die letzte Firmware Release 3.07 gebracht. Bisher keine Veränderung...
... einen hab ich noch....
get ZWDongle_0 caps
des Aeon S2 Sticks liefert:
ZWDongle_0 caps => Vers:3 Rev:7 ManufID:0086 ProductType:0002 ProductID:0001
SERIAL_API_GET_INIT_DATA,SERIAL_API_APPL_NODE_INFORMATION,APPLICATION_COMMAND_HANDLER,
ZW_GET_CONTROLLER_CAPABILITIES,SERIAL_API_SET_TIMEOUTS,SERIAL_API_GET_CAPABILITIES,
ZW_SET_SLEEP_MODE,ZW_SEND_NODE_INFORMATION,ZW_SEND_DATA,ZW_SEND_DATA_MULTI,
ZW_GET_VERSION,ZW_SEND_DATA_ABORT,ZW_R_F_POWER_LEVEL_SET,MEMORY_GET_ID,MEMORY_GET_BYTE,
MEMORY_PUT_BYTE,MEMORY_GET_BUFFER,ZW_GET_NODE_PROTOCOL_INFO,ZW_REPLICATION_COMMAND_COMPLETE,
ZW_REPLICATION_SEND_DATA,ZW_ASSIGN_RETURN_ROUTE,ZW_DELETE_RETURN_ROUTE,
ZW_REQUEST_NODE_NEIGHBOR_UPDATE,ZW_APPLICATION_UPDATE,ZW_ADD_NODE_TO_NETWORK,
ZW_CREATE_NEW_PRIMARY,ZW_SET_LEARN_MODE,ZW_ASSIGN_SUC_RETURN_ROUTE,ZW_ENABLE_SUC,
ZW_REQUEST_NETWORK_UPDATE,ZW_SET_SUC_NODE_ID,ZW_DELETE_SUC_RETURN_ROUTE,ZW_GET_SUC_NODE_ID,
ZW_REDISCOVERY_NEEDED,ZW_REQUEST_NODE_INFO,ZW_REMOVE_FAILED_NODE_ID,ZW_IS_FAILED_NODE
Hilfe - mein Monitor ist nicht breit genug! (Könnte ein Mod so freundlich sein und den Code editieren?)
was gibt dir denn einget ZWDongle_0 nodeInfo 2
zurück?
Mir ist es manchmal auch nicht gelungen ein Gerät anzulegen.
Vereinzelt hat mehrfaches ausführen des createNode geholfen, oder einfach warten und später noch einmal ausprobieren.
Mal ein shutdown restart durchgeführt?
Ich habe auch noch nicht herausgefunden, woran das liegt.
Mittlerweile habe ich aber alle Geräte in der .cfg!
Gruß
Torsten
> 2013.01.31 19:44:41 5: ZWDongle_0 dispatch 016001
Das Problem ist, dass ZWDongle.pm mit diesem Antwort nichts anfangen kann, und ich auch nicht :)
Leider ist das Modul feige, und beschwert sich nicht laut, nicht so wie ich.
Falls jemand rausfindet, was man mir "016001" anfangen soll, der moege sich melden.
... ich schreibe einfach 'mal an Düwi...
...nur zur Sicherheit: "016001" ist eine drei Byte lange Message die über die emulierte, serielle Schnittstelle empfangen wurde. Richtig?
ich vermute, daß ich einen anderen Firmwarestand auf dem Dimmer habe als cyberdwarf
Zitat von: cyberdwarf schrieb am Do, 31 Januar 2013 21:07was gibt dir denn einget ZWDongle_0 nodeInfo 2
zurück?
ZWDongle_0 nodeInfo_2 => ROUTING_SLAVE SWITCH_MULTILEVEL listening routing 40kBaud Vers:3 Security:0
Zitat von: cyberdwarf schrieb am Do, 31 Januar 2013 21:07Vereinzelt hat mehrfaches ausführen des createNode geholfen, oder einfach warten und später noch einmal ausprobieren.
Mal ein shutdown restart durchgeführt?
Ja, ich habe es auch mehrmals (ca. 5 Mal) versucht (inclusive shutdown restart). Am Schluss funktionierte nur der manuelle Weg über define und attr (wobei ich beim define die nodeId "02" anstelle von "2" eingeben musste)
Viele Dank für Eure Unterstützung,
Uwe
> "016001" ist eine drei Byte lange Message die über die emulierte, serielle Schnittstelle empfangen wurde.
Nicht ganz korrekt:
Ueber die Schnittstelle wurde "01040160019b" empfangen, s.o.
Das erste Byte (01) ist sync, danach kommt Laenge (04) und zum Schluss CRC (9b).
Das was uebrig bleibt, sind Nutzdaten, und damit kann FHEM bzw. ich nichts anfangen.
Heisst noch lange nicht, dass es inkorrekt ist, vlt. ist das sowas wie Protokoll Version 1, oder Ausnahme X.
Btw. ich vermute dass hier weniger der Schalter als eher der Stick der Ausloeser ist.
"Schuld" ist vmtl. das FHEM Modul 10_ZWave.pm, da es noch nicht alle Varianten des Protokolls beherrscht.
...habe eben Antwort von REV (Egner der Marke Düwi) bekommen:
Zitat...wir bedauern, dass Sie Schwierigkeiten mit Produkten der insolventen Firma düwi haben.
Dieses Waren Sortiment führen wir nicht weiter, bitte wenden Sie sich direkt an http://www.zwave4u.de/ (//www.zwave4u.de/)