Korrektes Handling des Aeotec Z-Stick GEN5

Begonnen von MarkusAutomaticus, 01 Juli 2016, 10:43:25

Vorheriges Thema - Nächstes Thema

krikan

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  :) .

krikan

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.

rudolfkoenig

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?

docfred

#19
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

docfred

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.

krikan

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.

docfred

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)?

krikan

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.

krikan

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..

rudolfkoenig

Besser als ein Spuerhund :)

Wir werden dann noch zusaetzlich das Problem haben, ohne Doku auskommen zu muessen :(

fermoll

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 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. 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.
FHEM auf Synology Ds 1621+ in Docker, . 2x Max!Cube, Debmatic auf RPI 3  mit HM-MOD-RPI-PCB , CUNO mit 35cm Antene, 2x HM-LC-Bl1PBU-FM, HC-LC-Bl1-FM
22 HT u. HT+, Fensterkontakte, S300TH, EM 100-GZ(S).
Diverse Wemos mit ESPEasy. 2. RPI3+, 1 RPI 4 8GB

krikan

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?

fermoll

#28
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

FHEM auf Synology Ds 1621+ in Docker, . 2x Max!Cube, Debmatic auf RPI 3  mit HM-MOD-RPI-PCB , CUNO mit 35cm Antene, 2x HM-LC-Bl1PBU-FM, HC-LC-Bl1-FM
22 HT u. HT+, Fensterkontakte, S300TH, EM 100-GZ(S).
Diverse Wemos mit ESPEasy. 2. RPI3+, 1 RPI 4 8GB