Hallo zusammen,
ich steige gerade von einem RazBerry, dessen Antenne ich geschrottet habe, auf den Aeotec Z-Stick GEN5 (der mit dem lustigen Lichtspiel) um.
Prinzipiell soll man ja in der Lage sein, den Stick vom Rechner abzuziehen, zum z-Wave-Element hinzugehen und dieses dann vorort zu in-/ex-kludieren.
Aber zum einen schweigt sich die Anleitung zum Z-Stick komplett darüber aus, wie man dabei vorgehen soll (also wie oft oder lange man den Taster auf dem Stick drücken muss) und zum anderen, wie mache ich das in Fhem?
Mache ich vor dem Abziehen des Sticks in Fhem ein ,,set AddNode on"?
Danach ist die Information der Node ja erst mal im Stick. Wie übernehme ich die Daten nach dem wieder Einstecken dann ins Fhem?
Kann ich, wenn die zu inkludiere Node in der Nähe ist, die Inklusion auch mit angestecktem Stick, so wie beim RazBerry vornehmen?
Gibt es irgendwo eine Übersicht, was das verschiedenfarbige Blinken des Sticks bedeutet?
Zur Info: es gibt noch eine weitere Windowssoftware, mit der man sich wohl die Qualität des z-Wave-Netzes anzeigen lassen kann.
Grundsätzlich scheint der Stick also Potential zu haben.
Was anderes: Es scheint gute Sitte zu sein, eine Node erstmal beim alten Controler zu exkludieren, bevor man sie beim Neuen wieder inkludiert. Da bei meinem RazBerry die Antenne abgerissen und damit das Exkludieren nicht mehr möglich ist, gibt es da eine andere Möglichkeit?
Manche z-Wave-Teile lassen sich auch resetten. Geht das auch? Also erst resetten und dann am Z-Stick inkludieren?
Gruß
Markus
Hi,
habe den Stick auch und das schon mal testweise gemacht.
Der große Vorteil ist mir schleierhaft, da zum Anlegen in fhem dann das Gerät wieder in "Wakeup" sein muss...
Ob das mit warten bis wakeup geht habe ich nicht getestet, daher bin ich wieder zurück auf den günstigeren Z1_usb oder wie der heißt (kann grad nicht nachschauen).
Laut Anleitung geht das so:
To initiate Inclusion-Mode, unplug the Z-Stick from the USB connector and then tap the button. (The LED will blink slowly.)
Note
While in Inclusion-Mode, the Z-Stick is in perpetual add/inclusion. There is no need to press the button on the Z-Stick again to include each new device.
To include a new Z-Wave device into the network, simply go to the device with the ZStick and press the button on the device you wish to include. (The LED on the Z-Stick will blink fast during a network neighbor discovery and stay solid for 3 seconds to indicate successful inclusion of the device into the network.)
The LED will then return to blinking slowly, indicating readiness for further device inclusions. Repeat step 2 for each device as you wish to include.
Tap the Z-Stick button to turn it off.
Dann Stick wieder einstecken (wo fhem läuft) und dann mauell anlegen.
Steht dann im fhem wiki:
http://www.fhemwiki.de/wiki/Z-Wave (http://www.fhemwiki.de/wiki/Z-Wave)
Erneutes Hinzufügen eines bereits registrierten Z-Wave Geräts
...
get ZWDongle_1 nodeList
...
set ZWDongle_1 createNode 2
...
Batteriebetriebene Geräte müssen bei Absetzen des createNode-Befehls wach sein...
Das geblinke habe ich auch ausgeschaltet.
Einfach einen bestimmten get Befehl (glaube ich war es) absetzen und gut is.
Habe ich hier im Forum mit der Suchfunktion gefunden...
Gruß, Joachim
Ich denke dass man die Geräte , die man an einem neuen Primary-Controller anmeldet erst resetten muss. Der neue hat eine neue Home ID und die alte wurde ja schon auf das device übertragen.
Nach meiner Anleitung müsste man mit dem Stick in die Nähe des zu inkludierenden Device gehen und bei beiden das inkludieren aktivieren. Über FHEM geht das ja mit set addnode on bzw. onNW. Beim Gerät durch 1 bzw. 3 mal drücken (Steht in der Anleitung)
Hi,
noch mal gelesen, nun etwas spezifischer:
Zitat
Prinzipiell soll man ja in der Lage sein, den Stick vom Rechner abzuziehen, zum z-Wave-Element hinzugehen und dieses dann vorort zu in-/ex-kludieren.
Aber zum einen schweigt sich die Anleitung zum Z-Stick komplett darüber aus, wie man dabei vorgehen soll (also wie oft oder lange man den Taster auf dem Stick drücken muss) und zum anderen, wie mache ich das in Fhem?
Mache ich vor dem Abziehen des Sticks in Fhem ein ,,set AddNode on"?
Danach ist die Information der Node ja erst mal im Stick. Wie übernehme ich die Daten nach dem wieder Einstecken dann ins Fhem?
Das Vorgehen habe ich beschrieben.
Und nein, vor dem Abziehen muss (darf) in fhem nichts gemacht werden.
Ein Includieren funktioniert auch mit angestecktem Stick.
Da genauso wie beim Razberry.
Also mittels ,,set AddNode on" bzw. ,,set AddNode onNW"...
Und bei dir dann wahrsch. wie docfred geschrieben hat entweder exludieren, wenn das mit dem Razberry noch gehen sollte oder halt nat. resetten...
...und wahrsch. auch in fhem löschen...
Aber wie geschrieben, dadurch, dass das batteriebetriebene Gerät dann zum Anlernen wieder geweckt werden muss ist der Vorteil von Abziehen, in der Nähe vom Gerät includieren und dann in fhem anlegen dahin...
Gruß, Joachim
Hallo zusammen,
ich habs gerade so mit meiner Wetterstation gemacht:
- Z-Stick abgezogen
- Z-Stick mit Station gekoppelt
- Z-Stick wieder mit FHEM verbunden
- Wetterstation wurde als unknown_8 erkannt
- 3x an der Wetterstation den Taster betätigt -> NIF versendet
- autocreate legt ZWave_SENSOR_MULTILEVEL_8 an
Fertig :)
Der Vorteil ist halt, dass man den Raspberry nicht abstöpseln, WLAN konfigurieren und aufs Carport-Dach bringen muss, um die Wetterstation zu inkludieren.
Gruß
Markus
Zitat von: MarkusAutomaticus am 03 Juli 2016, 17:52:44
- Z-Stick abgezogen
- Z-Stick mit Station gekoppelt
- Z-Stick wieder mit FHEM verbunden
- Wetterstation wurde als unknown_8 erkannt
- 3x an der Wetterstation den Taster betätigt -> NIF versendet
- autocreate legt ZWave_SENSOR_MULTILEVEL_8 an
Fertig :)
Das ist sicherlich eine mögliche Vorgehensweise.
ZitatDer Vorteil ist halt, dass man den Raspberry nicht abstöpseln, WLAN konfigurieren und aufs Carport-Dach bringen muss, um die Wetterstation zu inkludieren.
Den angegebenen Vorteil verstehe ich nur sehr eingeschränkt. Warum sollte man so etwas machen?
Bei einem Netz, das aus aktuellen Geräten (-> Explorer Frames-Unterstützung) besteht, ist es nicht notwendig Stick oder Endgerät in der örtlichen Position zu verändern. Man kann den Stick in den Modus für Network Wide Inclusion (addnode onNw) setzen und das zu inkludierende Endgerät dann per Network Wide Inclusion inkludieren, wobei automatisch das FHEM-Device angelegt wird. Die Routen im Stick sollten dann passen und aus meiner Sicht wichtiger: Wenn die Inklusion so nicht funktioniert, hat man direkt einen Hinweis, dass die Netzstabilität (Funkreichweite) unzureichend ist und kann handeln. Das stellt man mit dem An- und Abstöpseln erst später fest.
Sollten Geräte mit SDK 5 (ohne Explorer Frames) im Netz sein, kann die Network Wide Inklusion evtl. scheitern. Liegen auf der Route zwischen Stick und zu inkludierendem Gerät SDK 5-Geräte werden die Frames für Network Wide Inclusion nicht weitergereicht. Dann muss man für eine Inklusion eine örtliche Veränderung vornehmen. Jedoch hätte man dann das Problem, dass die Routen im Netz nicht korrekt sind, eine Selbstheilung mit SDK 5 eher schwierig ist und müsste neighborUpdate manuell durchführen.
So zumindest mein derzeitiges Verständnis. Aus den obigen Gründen rate ich im Wiki immer noch die Geräte an Ihren örtlichen Endpositionen bei der Inklusion zu belassen. Ist aus meiner Sicht risikoärmer. Zudem erkenne ich den Vorteil des An-/Abstöbseln mit mehr notwendigen Schritten bei aktuellen Geräten im Netz nicht.
Gegenargumente sind aber willkommen :).
Gruß, Christian
Hallo Christian,
ich habe keine Gegenargumente :-[
außer dass in den meisten Anleitungen steht, mann müsse das zu inkludierende Device zum Inkludieren nahe an den Controler bringen.
Angesichts meiner Probleme mit den Devices im Betrieb, dachte ich bisher, das sei die sicherste Methode.
Nichtsdestotrotz kann ich die Logik deiner Argumentation gut nachvollziehen.
Wie finde ich raus, ob meine Devices Network Wide Inclusion unterstützen?
Gibt es da irgendwo eine Übersicht?
Gruß
Markus
PS.: Aktuelle Probleme:
- Aeon Labs Plus Smart Switch 6: am Wochenende includiert, reagiert plötzlich nicht mehr
- EverspringBewegungsmelder-Z-Wave (EVR_SP103) am Wochenende includiert, schickt keine Events mehr
- Fibaro Relais Unterputzeinsatz 2 Schalter 1,5 kW, FIBEFGS-222: lässt sich weder resetten noch excludieren
Mal ehrlich: Wieviele Devices mit Stromnetzanschluss sind notwendig, damit ein z-Wave-Netz in einem durchschnittlichen 3 stöckigen Haus in Holzständerbauweise reibungslos funktioniert?
Ich habe derzeit: 1x Fibaro Zwischenstecker, 1x obigen Smartswitch, 1x Aeotec Sirene, 1x Fibaro Unterputzrelais, 1x Aeotec Z-Stick (bisher sind 2 Geschosse und der Carport involviert) ist das lächerlich wenig oder müsste das schon passen?
Nur mal so als Hausnummer, um ein Gefühl dafür zu kriegen.
Zitat von: MarkusAutomaticus am 04 Juli 2016, 09:29:17
Mal ehrlich: Wieviele Devices mit Stromnetzanschluss sind notwendig, damit ein z-Wave-Netz in einem durchschnittlichen 3 stöckigen Haus in Holzständerbauweise reibungslos funktioniert?
Das frage ich mich auch.
Hab einen Aeon Labs Stick und wollte mit einem NorthQ Energiemesser kommunizieren (Keller, ein Stockwerk). Das funktioniert mit HM, Jeelink und RFCTX ohne Probleme. Aber nicht mit dieser ZWAVE-Kombination. Dachte dann, dass es vielleicht am Batteriegerät liegt und habe einen Smartswitch 6 von Aeon Labs erstanden. Der Plan war, dass ich diesen als Repeater nutzen kann. Aber die Reichweite reichte auch hier nur innerhalb des Raumes. Schon im Nachbarraum war ein Kommunikation nicht mehr möglich. Habe jetzt einen ZME-Stick besorgt und werde heute Abend testen ob mit diesem Stick die Reichweite besser ist.
Habe jetzt in der Anleitung des Z-WAVE.ME Sticks gelesen (siehe Anhang), dass es für unterschiedliche Länder, geringfügig unterschiedgliche Frequenzen gibt. Das dies mit deutlichen Einbußen bei der Reichweite einher geht. Kann es sein, dass mein AEON LABS USB-Interface für ein anderes Land ist? Hab das aber über einen in Deutschland ansäßigen Versanghändler bezogen. Wie prüfe ich das? Gibt es von AEON LABs unterschiedliche Versionen.
Zitataußer dass in den meisten Anleitungen steht, mann müsse das zu inkludierende Device zum Inkludieren nahe an den Controler bringen.
Beruht meiner Meinung nach darauf, das dann Inklusion am Sichersten funktioniert (auch bei alten Geräten). Zudem ist das bei alten ohne Plus Controllern zwingend notwendig.
Ob meine Meinung 100% korrekt ist, kann ich nicht definitiv schreiben. Dazu fehlen noch zu viele Infos.
Zitat von: MarkusAutomaticus am 04 Juli 2016, 09:29:17
Wie finde ich raus, ob meine Devices Network Wide Inclusion unterstützen?
Gibt es da irgendwo eine Übersicht?
alle ZWave Plus - Geräte müssen nwi und ExplorerFrames unterstützen. (>=SDK 6.5)
alle anderen Explorer Frames-unterstützenden Geräte könnten grds. nwi (->SDK 4.5x und SDK 6.0x) -> zur Sicherheit technische Daten durchlesen.
SDK 5.x Geräte können grds. kein nwi.
-> Kurz: Am Sinnvollsten immer ZWavePlus Geräte nehmen, wenn man die Auswahl hat.
ZitatMal ehrlich: Wieviele Devices mit Stromnetzanschluss sind notwendig, damit ein z-Wave-Netz in einem durchschnittlichen 3 stöckigen Haus in Holzständerbauweise reibungslos funktioniert?
Keine Ahnung, mag da nicht pauschal etwas zu schreiben. Probieren. :)
Auffällig bei mir: die ohne Plus - Geräte haben eine deutlich geringere Reichweite als die ZwavePlus-Geräte.
ZitatAktuelle Probleme:
Hast Du Inklusion, Asssoziation und Konfiguration noch mal geprüft? Ansonsten halt separater Thead.
Zitat von: docfred am 04 Juli 2016, 12:06:13
Kann es sein, dass mein AEON LABS USB-Interface für ein anderes Land ist?
Eher unwahrscheinlich bis würde ich ausschließen. Du würdest vermutlich gar nichts empfangen.
Mir ist keine Funktion bekannt, wie man die vorgesehene Frequenz aus dem Stick auslesen kann.
ZitatNorthQ Energiemesser
Wenn es der mit dem steinalten SDK 5.x ist, dann möchte ich nicht wissen, was für ein Chip-Generation drinsteckt.
Hast Du bei Deinen Experimenten die Routen manuell aktualisiert? Bei SDK 5 geht so gut wie nichts automatisch (außer Du hast einen korrekt funktionierenden SUC)
ZitatHabe jetzt einen ZME-Stick besorgt und werde heute Abend testen ob mit diesem Stick die Reichweite besser ist.
Das wuerde mich bei der groesse bzw. Antenne sehr wundern. Bitte berichte.
Christian: kennst du in irgendeiner der API Funktionen eine RSSI Angabe? Domoticz zeigt angeblich was an, ist aber unklar, was. Laut anderen Quellen soll RSSI erst in den neuesten SDKs drin sein (was auch immer das heisst).
Das ist die Version des Aeon Labs Stick (1/2016 erworben)
Z-Wave 3.95 STATIC_CONTROLLER
Das ist die Version des Smartswitches: (6/2016 erworben)
Lib 3 Prot 4.5 App 1.0 HW 96 FWCounter 0
Kann zu diese Versionen jemand etwas sagen? Aktuell?
Wie gesagt, im gleichen Raum funktionieren diese (inkl. eines Danfoss-Thermostates). Der hat aber auch Probleme im anderen Raum.
Zitat von: docfred am 04 Juli 2016, 13:24:08
Das ist die Version des Aeon Labs Stick (1/2016 erworben)
Z-Wave 3.95 STATIC_CONTROLLER
-> ZWave Plus
SDK 6.51.02
ZitatDas ist die Version des Smartswitches: (6/2016 erworben)
Lib 3 Prot 4.5 App 1.0 HW 96 FWCounter 0
-> ZWave Plus
SDK 6.51.03
Wie man das ermittelt steht hier: http://www.fhemwiki.de/wiki/Z-Wave#Wie_kann_man_die_SDK-Version_eines_Ger.C3.A4tes_herausfinden.3F
Zitat von: rudolfkoenig am 04 Juli 2016, 13:16:08
kennst du in irgendeiner der API Funktionen eine RSSI Angabe? Domoticz zeigt angeblich was an, ist aber unklar, was.
Nein. Glaube auch nicht, dass es so etwas schon gibt.
AEOTEC Gen5-Stick hat zwar ein Reichweitentool, aber das soll (nicht selbst geprüft) auf Nachbarschaftsbeziehungen und CC Powerlevel aufsetzen.
Domoticz nutzt nach meinem Verständnis nur die Nachbarschaftbeziehungen (https://www.domoticz.com/wiki/Zwave#Network_and_group_info). Könnte ich mir bei Gelegenheit aber anschauen.
Gleiches macht vermutlich auch z-way, obwohl hier jemand bereits anderes geschrieben hatte ohne auf Nachfragen zu reagieren.
-> so eine bildliche Auswertung der Nachbarschaftsbeziehungen wäre schon interessant. Ich mache eine Kontrolle der Beziehungen derzeit manuell über eine readingsGroup.
Ist auf meinem TODO, vorher will ich aber ein "getNeighborListAll" (oder vergleichbares) implementieren.
Zitat von: krikan am 04 Juli 2016, 13:33:06
Wie man das ermittelt steht hier: http://www.fhemwiki.de/wiki/Z-Wave#Wie_kann_man_die_SDK-Version_eines_Ger.C3.A4tes_herausfinden.3F
Stick und Smartswith melden: ProtocolVers:SDK4.5x+6.0x
Zitat von: docfred am 04 Juli 2016, 14:09:37
Stick und Smartswith melden: ProtocolVers:SDK4.5x+6.0x
Das ist nur eine Grobermittlung über ZWdongle nodeInfo. Dort gibt es nur 3 bekannte Werte und Deine Geräte haben den "besten" Wert (bspw. Explorer-Frames Unterstützung). SDK4.5x+6.0x umfasst nach meiner derzeitigen Kenntnis und Tests auch 6.5x.
Was ich Dir geschrieben hatte ist die genauere Detailermittlung, die in der FAQ auch steht, aber eine externe Übersetzungsquelle braucht.
@Rudi
ZitatIst auf meinem TODO, vorher will ich aber ein "getNeighborListAll" (oder vergleichbares) implementieren.
Stimmt, wir hatten das Thema schon mal. Hatte ich vergessen. Läuft ja nicht weg :) .
Zitat von: rudolfkoenig am 04 Juli 2016, 13:16:08
kennst du in irgendeiner der API Funktionen eine RSSI Angabe? Domoticz zeigt angeblich was an, ist aber unklar, was. Laut anderen Quellen soll RSSI erst in den neuesten SDKs drin sein (was auch immer das heisst).
Hast Du eine genauere Info, wo Domoticz etwas anzeigen soll?
Ich habe mal ein Update auf die letzte Beta von Domoticz gemacht. Nach meinem Verständnis und Abgleich mit den Logs wird das hier https://www.domoticz.com/wiki/Zwave#Network_and_group_info gezeigte aus den Nachbarschaftsinformationen generiert. Ich fände es auch verwunderlich, wenn es anders wäre, da Domoticz ozw für Zwave nutzt und ozw kann auch keine RSSI ermitteln.
Sigma verweist bei Tests von 5er-Chip-Signalqualitäten für den Installateur auf das IMA Tool (das wir natürlich nicht bekommen). Wenn ich die wenig technische Beschreibung des Tools (stammt wohl aus der Marketingabteilung) richtig interpretiere, ermittelt das Telegrammlaufzeiten, Anzahl der Nachbarn,.. und gewichtet dies mit Faktor x um die Qualität einer Funkstrecke zu ermtteln. Dort steht nichts von RSSI und Co.
Zurück zum Topic AEOTEC Gen5: AEOTEC bietet für den Stick ein IMATool http://aeotec.com/downloads/IMAToolV1.zip an mit dem man Signalqualitäten messen kann und das Ergebnis mit Ampelfarben präsentiert wird. Das Log des Tools zeigt bei Tests mit meinem ZWavePlus-Controller keinen Hinweis auf RSSI, aber auf Laufzeitenmessung, Powerlevel-Änderungen, Nachbarzählung,...
-> Die Existenz einer RSSI-Ermittlung bei den aktuell verfügbaren Produkten halte ich für mehr als unwahrscheinlich. Einen neueren Chipsatz als 5er kenne ich nicht.
Vielen Dank fuer die Recherche.
Zeit bis zum Ack sammeln wir schon (timeToAck), Liste der Nachbarn kriegen wir auch.
Wir koennten schnelle Verbindungen durch Liniendicke kennzeichnen. Andere Ideen?
Zitat von: rudolfkoenig am 04 Juli 2016, 13:16:08
Das wuerde mich bei der groesse bzw. Antenne sehr wundern. Bitte berichte.
So, jetzt kann ich kurz berichten: Habe jetzt den Aeon Labs Stick durch einen ZME UZB1 Me Stick ersetzt. Alle Devices resettet und mit der Inclusion begonnen. Ging sofort. Den Smartswitch in den Keller verfrachtet. Kein Problem. Schaltet einwandfrei. Den Gasmeter mit AddNW im Keller includiert. Hat problemlos funktioniert. NeiborList vom Smartswitch: ZWDongle_0 ZWave_METER_3
Es ist definitiv so, dass trotz des schlichten kleinen Sticks die Reichweite um Klassen besser ist. Jetzt bin ich sogar motiviert die Danfoss Thermostate noch einmal einzubauen.
Gute Nacht
Das NorthQ sagt: ProtocolVers:SDK5.0x+4.2x sleeping routing maxBaud:40kbps SpecificDev RoutingSlave BeamCap OptFunc RoleType:N/A BasicDevClass:ROUTING_SLAVE GenericDevClass:METER SpecificDevClass:01
Das ist dann wohl nicht so gut.
Zitat von: docfred am 04 Juli 2016, 23:08:34
Das NorthQ sagt: ProtocolVers:SDK5.0x+4.2x sleeping routing maxBaud:40kbps SpecificDev RoutingSlave BeamCap OptFunc RoleType:N/A BasicDevClass:ROUTING_SLAVE GenericDevClass:METER SpecificDevClass:01
Das ist dann wohl nicht so gut.
Das zugrundeliegende SDK stammt laut Zwaveeurope aus 2007. Es hat Nachteile insbesondere hinsichtlich des automatischen Routenmanagements im Netz. Manuelles neigborUpdate ist quasi zwingend. Automatisches Routenupdate für den Node ist nahezu unmöglich (nur mit eingerichtetem und gepflegtem SUC). Auch das Gerät ist nutzbar, wenn man sich der Besonderheiten bewußt ist.
Dennoch würde ich bei Kaufentscheidungen und entsprechender Auswahlmöglichkeit immer den ZWavePlus zertifizierten Produkten den Vorzug geben. Die Produkte haben dann aktuelle ZWave-Technik mit u.a. besserem Routenmanagement, höheren Reichweiten,.. (siehe Infos zu ZWavePlus).
Eigentlich will ich nur das Problembewußtsein bei ZWave-Neueinsteigern schärfen: ZWave ist aktuell im Handel mit alten und neuen Chipsätzen/SDKs. Kauft aktuelle Gerät, um weniger Probleme zu bekommen oder seid euch zumindest der Unterschiede bewußt. Habe vorige Woche auch einmal angefangen im Wiki zur Geräteauswahl etwas festzuhalten.
Vielen Dank für die Info.
Das finde ich an diesem Forum toll, dass Ihr euer Wissen weitergebt (Auch wenn es manchmal vielleicht nervig ist, Dinge zu x-ten Mal zu sagen).
Allerdings finde ich Z-Wave bei allen Möglichkeiten, die dieser Standard bietet, wesentlich komplizierter (und zickiger) als z.B. HM. Was wäre eine gute Standardliteratur?
Ich habe noch das Problem, dass ich das Wakeupintervall beim Danfossthermostat und dem NorthQ Meter nicht verkürzt bekomme. Die Parameter sind doch z.B. 600 (für 10min) und 1 (weil das an den Conroller gemeldet werden soll)?
Zitat von: docfred am 05 Juli 2016, 10:09:33
Allerdings finde ich Z-Wave bei allen Möglichkeiten, die dieser Standard bietet, wesentlich komplizierter (und zickiger) als z.B. HM. Was wäre eine gute Standardliteratur?
Ja, Zwave ist auch mMn deutlich komplexer als HM. Liegt unter anderem daran, dass eben nicht radikal die alten SDKs/Chipsätze in den Geräten aus der Vermarktung verschwinden, sondern weiter vertrieben werden.
Einziges ausführliches, mir bekanntes Buch ist von Dr. Paetz (siehe http://www.fhemwiki.de/wiki/Z-Wave#Allgemein_2). Beim Lesen aber die Tätigkeit von Dr. Paetz bei ZWave-Europe und der Allianz beachten.
ZitatDie Parameter sind doch z.B. 600 (für 10min) und 1 (weil das an den Conroller gemeldet werden soll)?
Ja, wenn Controller NodeID 1 hat. Zudem müssen die End-Geräte die 10min unterstützen. Wenn die das nicht unterstützen, dann ist die Auswirkung des abgesetzten Befehls gerätespezifisch, weil früher im Standard nicht definiert. Bei Geräten mit CC WAKE_UP V2 kann man die Einstellmöglichkeiten mit "get <device> wakeupIntervalCapabilities" abrufen; ansonsten bleibt nur das Handbuch.
Zitat von: rudolfkoenig am 04 Juli 2016, 13:16:08
Laut anderen Quellen soll RSSI erst in den neuesten SDKs drin sein (was auch immer das heisst).
Demnach http://www.sigmadesigns.com/news/sigma-designs-launches-feature-rich-z-wave-sdk/ könnte so etwas im SDK 6.6 kommen. Fragt sich nur, wann das in Produkten im Handel auftaucht..
Besser als ein Spuerhund :)
Wir werden dann noch zusaetzlich das Problem haben, ohne Doku auskommen zu muessen :(
Ich hole mal das Thema wieder nach oben, da es für mich momentan aktuell ist. Ich versuche, den Stick mit Danalock V125 V2 zu verheiraten und in FHEM einzubinden. Der Stick wird in FHEM erkannt. Das Koppeln mit Danalock über FHEM geht leider nicht. Nachdem ich den Stick resettet habe, habe ich die Kopplung mit dem direkten Kontakt durchgeführt. In FHEM ist der Danalock nicht zu sehen.
Dann bin ich in Bezug auf Dokumentation bei https://aeotec.freshdesk.com/support/solutions/folders/6000146720 (https://aeotec.freshdesk.com/support/solutions/folders/6000146720) fündig geworden. Die ist m.E. recht ausführlich.
Vor allem aber habe ich Zensys Tool (Z-Wave PC Controller) gefunden:https://aeotec.freshdesk.com/support/solutions/articles/6000110204-zensys-tool (https://aeotec.freshdesk.com/support/solutions/articles/6000110204-zensys-tool). Das zeigt mir, dass Danalock auf dem Stick gelandet ist. Für die Spezialisten sind vielleicht die Bäume unten und rechts interessant. Ich hoffe, das sind genug Informationen.
Du solltest in FHEM das Device für das Danalock mit createNode erzeugen, wenn der Stick waehrend der Inklusion nicht am FHEM-Server eingesteckt war: https://wiki.fhem.de/wiki/Z-Wave#Erneutes_Hinzuf.C3.BCgen_eines_bereits_registrierten_Z-Wave_Ger.C3.A4ts
Zitat
Das Koppeln mit Danalock über FHEM geht leider nicht
Warum nicht? Was sagte das Log?
Ich habe den Grund gefunden. Z-Wave Stick ist zu weit von Danalock entfernt. Muss noch zwei Schalter dazwischen bauen.
PS:
Ich habe zwei Devolo MT-1646 in Richtung des Danalock inkludiert und den Danalock exkludiert. Wen ich jetzt in FHEM SET Addnote on setze, schaltet sich beim Drücken des SET-Buttons sofort aus, auch bei den anderen Möglichkeiten. Die Schalter lassen sich mit FHEM betätigen.
Ausschnitt aus der fhem.cfg
define ZWDongle_0 ZWDongle /dev/ttyACM0@115200
attr ZWDongle_0 room 1Parterre,ZWave
attr ZWDongle_0 verbose 5
define ZWave_SWITCH_BINARY_2 ZWave f7cd890b 2
attr ZWave_SWITCH_BINARY_2 IODev ZWDongle_0
attr ZWave_SWITCH_BINARY_2 classes ZWAVEPLUS_INFO VERSION MANUFACTURER_SPECIFIC SECURITY DEVICE_RESET_LOCALLY ASSOCIATION ASSOCIATION_GRP_INFO POWERLEVEL SWITCH_BINARY BASIC SWITCH_ALL METER CONFIGURATION ALARM PROTECTION FIRMWARE_UPDATE_MD
attr ZWave_SWITCH_BINARY_2 room 1Parterre,ZWave
attr ZWave_SWITCH_BINARY_2 vclasses ALARM:1 ASSOCIATION:2 ASSOCIATION_GRP_INFO:1 BASIC:1 CONFIGURATION:1 DEVICE_RESET_LOCALLY:1 FIRMWARE_UPDATE_MD:2 MANUFACTURER_SPECIFIC:2 METER:3 POWERLEVEL:1 PROTECTION:2 SECURITY:1 SWITCH_ALL:1 SWITCH_BINARY:1 VERSION:2 ZWAVEPLUS_INFO:2
define FileLog_ZWave_SWITCH_BINARY_2 FileLog ./log/ZWave_SWITCH_BINARY_2-%Y.log ZWave_SWITCH_BINARY_2
attr FileLog_ZWave_SWITCH_BINARY_2 logtype text
attr FileLog_ZWave_SWITCH_BINARY_2 room ZWave
define ZWave_SWITCH_BINARY_3 ZWave f7cd890b 3
attr ZWave_SWITCH_BINARY_3 IODev ZWDongle_0
attr ZWave_SWITCH_BINARY_3 classes ZWAVEPLUS_INFO VERSION MANUFACTURER_SPECIFIC SECURITY DEVICE_RESET_LOCALLY ASSOCIATION ASSOCIATION_GRP_INFO POWERLEVEL SWITCH_BINARY BASIC SWITCH_ALL METER CONFIGURATION ALARM PROTECTION FIRMWARE_UPDATE_MD
attr ZWave_SWITCH_BINARY_3 room 1Parterre,ZWave
attr ZWave_SWITCH_BINARY_3 vclasses ALARM:1 ASSOCIATION:2 ASSOCIATION_GRP_INFO:1 BASIC:1 CONFIGURATION:1 DEVICE_RESET_LOCALLY:1 FIRMWARE_UPDATE_MD:2 MANUFACTURER_SPECIFIC:2 METER:3 POWERLEVEL:1 PROTECTION:2 SECURITY:1 SWITCH_ALL:1 SWITCH_BINARY:1 VERSION:2 ZWAVEPLUS_INFO:2
define FileLog_ZWave_SWITCH_BINARY_3 FileLog ./log/ZWave_SWITCH_BINARY_3-%Y.log ZWave_SWITCH_BINARY_3
attr FileLog_ZWave_SWITCH_BINARY_3 logtype text
attr FileLog_ZWave_SWITCH_BINARY_3 room ZWave
Das Problem Erreichbarkeit des Danalock dürfte damt erledigt sein. Die Knoten sind jetzt 3 Meter (durch eine Ziegelwand) bzw. 5 m vom Danalock entfernt.
Anbei noch ein ausschnitt des Logfiles:
2017.02.02 21:26:44 5: ZWDongle_Write 001302032501002524 (f7cd890b)
2017.02.02 21:26:44 5: SW: 010a001302032501002524c2
2017.02.02 21:26:44 5: ACK received, WaitForAck=>2 for 010a001302032501002524c2
2017.02.02 21:26:44 4: ZWDongle_Read ZWDongle_0: rcvd 011301 (answer ZW_SEND_DATA), sending ACK
2017.02.02 21:26:44 5: SW: 06
2017.02.02 21:26:44 5: ZWDongle_0: dispatch 011301
2017.02.02 21:26:44 4: ZWDongle_Read ZWDongle_0: rcvd 001324000002 (request ZW_SEND_DATA), sending ACK
2017.02.02 21:26:44 5: SW: 06
2017.02.02 21:26:44 5: device ack reveived, removing 010a001302032501002524c2 from dongle sendstack
2017.02.02 21:26:44 5: ZWDongle_0: dispatch 001324000002
2017.02.02 21:26:44 4: CMD:ZW_SEND_DATA ID:00 ARG:0002 CB:24
2017.02.02 21:26:44 4: ZWDongle_0 transmit OK for CB 24, target ZWave_SWITCH_BINARY_2
2017.02.02 21:26:45 3: ZWave set ZWave_SWITCH_BINARY_3 off
2017.02.02 21:26:45 5: ZWDongle_Write 001303032501002525 (f7cd890b)
2017.02.02 21:26:45 5: SW: 010a001303032501002525c2
2017.02.02 21:26:45 5: ACK received, WaitForAck=>2 for 010a001303032501002525c2
2017.02.02 21:26:45 4: ZWDongle_Read ZWDongle_0: rcvd 011301 (answer ZW_SEND_DATA), sending ACK
2017.02.02 21:26:45 5: SW: 06
2017.02.02 21:26:45 5: ZWDongle_0: dispatch 011301
2017.02.02 21:26:45 4: ZWDongle_Read ZWDongle_0: rcvd 001325000002 (request ZW_SEND_DATA), sending ACK
2017.02.02 21:26:45 5: SW: 06
2017.02.02 21:26:45 5: device ack reveived, removing 010a001303032501002525c2 from dongle sendstack
2017.02.02 21:26:45 5: ZWDongle_0: dispatch 001325000002
2017.02.02 21:26:45 4: CMD:ZW_SEND_DATA ID:00 ARG:0002 CB:25
2017.02.02 21:26:45 4: ZWDongle_0 transmit OK for CB 25, target ZWave_SWITCH_BINARY_3
2017.02.02 21:26:47 4: ZWDongle_Read ZWDongle_0: rcvd 000410030e3202213400000000000000000000 (request APPLICATION_COMMAND_HANDLER), sending ACK
2017.02.02 21:26:47 5: SW: 06
2017.02.02 21:26:47 5: ZWDongle_0: dispatch 000410030e3202213400000000000000000000
2017.02.02 21:26:47 4: CMD:APPLICATION_COMMAND_HANDLER ID:03 ARG:0e3202213400000000000000000000 CB:10
2017.02.02 21:26:48 4: ZWDongle_Read ZWDongle_0: rcvd 0004100303250300 (request APPLICATION_COMMAND_HANDLER), sending ACK
2017.02.02 21:26:48 5: SW: 06
2017.02.02 21:26:48 5: ZWDongle_0: dispatch 0004100303250300
2017.02.02 21:26:48 4: CMD:APPLICATION_COMMAND_HANDLER ID:03 ARG:03250300 CB:10