Z-Wave: Unterschied zwischen den Versionen

Aus FHEMWiki
K (→‎Vorbereitung: -> Aktualisierung nach https://forum.fhem.de/index.php?topic=138013.0)
 
(138 dazwischenliegende Versionen von 10 Benutzern werden nicht angezeigt)
Zeile 19: Zeile 19:
</div>
</div>


[[Z-Wave]] ist ein drahtloser Kommunikations-Standard im 868 Mhz-Band (Europa), der von der Firma Sigma Designs und der Z-Wave Alliance, einen Zusammenschluss von mehreren Hundert Herstellern, für die Heimautomatisierung entwickelt wurde. Es existieren mehr als [http://products.z-wavealliance.org 1000 zertifizierte Produkte] verschiedenster Hersteller, die innerhalb eines gemeinsamen Z-Wave-Netzes einsetzbar sind. (Quelle: [http://de.wikipedia.org/wiki/Z-Wave Wikipedia])
[[Z-Wave]] ist ein drahtloser Kommunikations-Standard im 868 Mhz-Band (Europa), der von der Firma Sigma Designs und der Z-Wave Alliance, einen Zusammenschluss von mehreren Hundert Herstellern, für die Heimautomatisierung entwickelt wurde. Es existieren mehr als [http://products.z-wavealliance.org 1400 zertifizierte Produkte] verschiedenster Hersteller, die innerhalb eines gemeinsamen Z-Wave-Netzes einsetzbar sind. (Quelle: [http://de.wikipedia.org/wiki/Z-Wave Wikipedia])


Auf dieser Seite werden Grundlagen eines '''Z-Wave''' Systems und dessen Einrichtung in Fhem beschrieben.
Auf dieser Seite werden Grundlagen eines '''Z-Wave''' Systems und dessen Einrichtung in FHEM beschrieben.
== Z-Wave ==
== Z-Wave ==
=== Nodes - Controller und Slaves ===
=== Nodes - Controller und Slaves ===
Zeile 33: Zeile 33:
Die Home-ID ist im Controller (fest) hinterlegt und seine Node-ID ist typischerweise 1. Die Slaves haben zunächst keine Home-ID und Node-ID. Bei der '''Inklusion''' (Aufnahme) der Slaves in das Z-Wave-Netz überträgt der Controller seine Home-ID auf die Slaves und weist den Slaves eine eindeutige Node-ID im Netz zu, mit der Sie direkt angesprochen werden.  
Die Home-ID ist im Controller (fest) hinterlegt und seine Node-ID ist typischerweise 1. Die Slaves haben zunächst keine Home-ID und Node-ID. Bei der '''Inklusion''' (Aufnahme) der Slaves in das Z-Wave-Netz überträgt der Controller seine Home-ID auf die Slaves und weist den Slaves eine eindeutige Node-ID im Netz zu, mit der Sie direkt angesprochen werden.  


Besondere Node-ID ist die 255. Eine Nachricht an die Node-ID 255 kann von allen Z-Wave-Nodes ausgewertet werden (Broadcast)
Besondere Node-ID ist die 255. Eine Nachricht an die Node-ID 255 kann von allen Z-Wave-Nodes ausgewertet werden (Broadcast).


=== Primär- und Sekundärcontroller ===
=== Primär- und Sekundärcontroller ===
Der Controller, der durch Zuteilung seiner Home-ID auf die Slaves, das Netz aufbaut, ist der '''Primärcontroller'''. Grundsätzlich können in einem Netz mehrere Controller existieren, aber immer nur ein Primärcontroller. Weitere in das Netz eingebundene Controller werden zum '''Sekundärcontroller'''. Nur der Primärcontroller kann die Inklusion (Einbindung) der Nodes in das Netz durchführen. Hingegen können sowohl Primär- als auch Sekundärcontroller die '''Exklusion''' (Ausschluss) eines Nodes aus dem Netz vornehmen.
Der Controller, der durch Zuteilung seiner Home-ID auf die Slaves, das Netz aufbaut, ist der '''Primärcontroller'''. Grundsätzlich können in einem Netz mehrere Controller existieren, aber immer nur ein Primärcontroller. Weitere in das Netz eingebundene Controller werden zum '''Sekundärcontroller'''. Ohne besondere Maßnahmen kann nur der Primärcontroller die Inklusion (Einbindung) der Nodes in das Netz durchführen. Hingegen können sowohl Primär- als auch Sekundärcontroller die '''Exklusion''' (Ausschluss) eines Nodes aus dem Netz vornehmen.
 
Der Controller speichert intern diverse Informationen (Home-ID, Node-IDs,..) über das ZWave-Netz. Hierdurch kann unter anderem die Haussteuerungssoftware bei einem PC-Controller relativ unkompliziert gewechselt werden, da die wesentlichen ZWave-Netzinformationen vom Controller selbst verwaltet und gespeichert werden. Andererseits muß bei einem Controllerdefekt das gesamte Netz grundsätzlich neu aufgebaut werden, wenn kein Backup der internen Controllerdaten vorhanden ist.


=== Acknowledge ===
=== Acknowledge ===
Im Z-Wave-Netz werden Nachrichten vom Empänger-Node an den Sender-Node rückbestätigt (Acknowledge). Bei ausbleibendem Acknowledge wiederholt der Sender-Node die Nachricht bis zu 2 mal. Hierdurch wird eine höhere Betriebssicherheit des Z-Wave-Netzes erreicht. Bei Broadcast-Nachrichten an die Node-ID 255 findet keine Rückbestätigung statt.
Im Z-Wave-Netz werden Nachrichten vom Empänger-Node an den Sender-Node rückbestätigt (Acknowledge). Bei ausbleibendem Acknowledge wiederholt der Sender-Node die Nachricht automatisch auf Protokollebene bis zu 2 mal. Hierdurch wird eine höhere Betriebssicherheit des Z-Wave-Netzes erreicht. Bei Broadcast-Nachrichten an die Node-ID 255 findet keine Rückbestätigung statt.


=== Vermaschtes Netzwerk mit Routing ===
=== Vermaschtes Netzwerk mit Routing ===
Z-Wave nutzt als Netzwerktopologie ein '''mesh network''' (vermaschtes Netzwerk), d. h. jeder Node ist mit einem oder mehreren anderen Nodes verbunden. Das hat den Vorteil, dass eine Nachricht zwischen zwei Nodes übermittelt werden kann, selbst wenn diese nicht direkt miteinander kommunizieren können, z. B. weil sie zu weit voneinander entfernt sind. In diesem Fall wird die Funk-Nachricht über einen oder mehrere „Zwischen-Nodes“ übertragen; dieser Vorgang wird '''Routing''' genannt. Nur netzgespeiste Z-Wave-Geräte sind Router. Batteriebetriebe Z-Wave-Geräte sind grundsätzlich keine Router und dienen somit auch nicht zur Reichweitenerhöhung. (Quelle: [http://de.wikipedia.org/wiki/Z-Wave Wikipedia]) Einzelne Geräte, die alternativ per Batterie oder USB-Anschluss betrieben werden können, werden bei USB-Anschluss automatisch ({{Link2Forum|Topic=40393|Message=328080}}) oder durch Konfigurationsänderungen ({{Link2Forum|Topic=40393|Message=327331}}) zu Routern.
Z-Wave nutzt als Netzwerktopologie ein '''mesh network''' (vermaschtes Netzwerk), d. h. jeder Node ist mit einem oder mehreren anderen Nodes verbunden. Das hat den Vorteil, dass eine Nachricht zwischen zwei Nodes übermittelt werden kann, selbst wenn diese nicht direkt miteinander kommunizieren können, z. B. weil sie zu weit voneinander entfernt sind. In diesem Fall wird die Funk-Nachricht über einen oder mehrere „Zwischen-Nodes“ übertragen; dieser Vorgang wird '''Routing''' genannt. Nur netzgespeiste Z-Wave-Geräte sind Router. Batteriebetriebe Z-Wave-Geräte sind grundsätzlich keine Router und dienen somit auch nicht zur Reichweitenerhöhung. (Quelle: [http://de.wikipedia.org/wiki/Z-Wave Wikipedia]) Einzelne Geräte, die alternativ per Batterie oder USB-Anschluss betrieben werden können, werden bei USB-Anschluss automatisch ({{Link2Forum|Topic=40393|Message=328080}}) oder durch Konfigurationsänderungen ({{Link2Forum|Topic=40393|Message=327331}}) zu Routern.


Informationen über das optimale Routing werden bei der Inklusion der Nodes in einer Routing-Tabelle des Primärcontrollers gespeichert. Dies geschieht durch Abfrage des Nodes, welche weiteren Nodes er erreichen kann. Durch örtliche Änderung oder Defekte von Nodes können die in der Routing-Tabelle gespeicherten Informationen fehlerhaft bzw. suboptimal werden. Dies kann sich in Funkkommunikationsproblemen im Netzwerk äußern. Hier kann ein per Software manuell angeforderter Neuaufbau der Routing-Tabelle gegebenenfalls Abhilfe schaffen. Bei Geräten und Controllern mit aktuellen Firmware-Versionen (SDK 4.5x und SDK 6.xx oder größer, aber ''nicht'' SDK 5.x) und Unterstützung von Explorer Frames kann sich die Routing-Tabelle unter bestimmten Bedingungen auch automatisch aktualisieren ("Selbstheilung")[http://wiki.zwaveeurope.com/index.php?title=SDK_Versions_and_Explorer_Frames].
Informationen über das optimale Routing werden bei der Inklusion der Nodes in einer Routing-Tabelle des Primärcontrollers gespeichert. Dies geschieht durch Abfrage des Nodes, welche weiteren Nodes er erreichen kann. Durch örtliche Änderung oder Defekte von Nodes können die in der Routing-Tabelle gespeicherten Informationen fehlerhaft bzw. suboptimal werden. Dies kann sich in Funkkommunikationsproblemen im Netzwerk äußern. Hier kann ein per Software manuell angeforderter Neuaufbau der Routing-Tabelle gegebenenfalls Abhilfe schaffen. Bei Geräten und Controllern mit aktuellen Firmware-Versionen (SDK 4.5x und SDK 6.xx oder größer, aber ''nicht'' SDK 5.x) und Unterstützung von Explorer Frames kann sich die Routing-Tabelle unter bestimmten Bedingungen auch automatisch aktualisieren ("Selbstheilung")[https://web.archive.org/web/20160319202135/http://wiki.zwaveeurope.com/index.php?title=SDK_Versions_and_Explorer_Frames].


=== Command Classes ===
=== Command Classes ===
Die Steuerung und Kommunikation der Nodes erfolgt über '''[[Z-Wave_Command_Classes|Command Classes]]''' (Kommandoklassen). Die Command Classes sind nach Gerätefunktionen unterteilt.
Die Steuerung und Kommunikation der Nodes erfolgt über Befehle die funktionsbezogen in verschiedene '''Command Classes''' (Kommandoklassen) zusammengefasst sind.


Alle Z-Wave-Geräte haben als gemeinsame kleinste Übereinstimmung die '''Class Basic'''.  
Alle Z-Wave-Geräte haben als gemeinsame kleinste Übereinstimmung die '''Class Basic'''.  
Zeile 55: Zeile 57:
Durch eine Assoziation wird definiert, welche Geräte miteinander direkt -ohne Umweg über den Controller- kommunizieren können. Auch bei Ausfall des Controllers können diese Geräte ihre gemeinsame Funkton ausüben. Zudem dienen Assoziationen der Geschwindigkeitssteigerung und Funklastreduzierung innerhalb des Netzes. Angelegt werden Assoziationen über die '''Class Association'''.
Durch eine Assoziation wird definiert, welche Geräte miteinander direkt -ohne Umweg über den Controller- kommunizieren können. Auch bei Ausfall des Controllers können diese Geräte ihre gemeinsame Funkton ausüben. Zudem dienen Assoziationen der Geschwindigkeitssteigerung und Funklastreduzierung innerhalb des Netzes. Angelegt werden Assoziationen über die '''Class Association'''.


Dies sind nur die allerwichtigsten Command Classes. Weitere Command Classes sind den Handbüchern zu entnehmen.
Dies sind nur die allerwichtigsten Command Classes. Weitere Command Classes sind den Handbüchern zu entnehmen. Zudem enthält die Wiki-Seite [[Z-Wave Command Classes]] weitergehende Informationen.
 
=== Hinweise zur Z-Wave-Geräteauswahl ===
Aufgrund der vielen Z-Wave-Gerätehersteller mit jeweils eigenem Z-Wave-Gerätesortiment existiert eine große Produktauswahl. Jedoch gibt es auch große Unterschiede hinsichtlich Produkteigenschaften, Pflege der Produkte, Häufigkeit der Aktualisierung der Produktpalette und so weiter. Schwierigkeiten bereitet insbesondere, dass neben den aktuellesten Chipsätzen und SDKs auch die älteren Chipsätze und SDKs weiterhin in Produkten im Handel verfügbar sind. Neuere Chipsätze und aktuelle SDKs bieten gerade bei der Netzwerkstabilität (Explorer Frames, Reichweite usw.) Vorteile zu älteren Chipsätzen und SDKs. Beispielsweise beherrschen nur Geräte mit SDK 4.5x und 6.x oder neuer die für automatische Routenkorrekturen wichtigen Explorer Frames. Das ältere SDK 5.0, das verwirrenderweise auch noch eine höhere Versionsnummer als das neuere SDK 4.5 besitzt, beherrscht unter anderem keine Explorer Frames. Details hierzu enthält das [https://web.archive.org/web/20160319202135/http://wiki.zwaveeurope.com/index.php?title=SDK_Versions_and_Explorer_Frames wiki.zwaveeurope.com]. Aktuellstes SDK ist Stand 10/2017 das SDK 6.7x, das in ZWave Plus - zertifizierten Produkten zum Einsatz kommt.
 
Gerade Einsteiger beachten die Unterschiede bei den Chipsätze/SDKs aus Unkenntnis manchmal nicht und ärgern sich im Nachhinein über Probleme bei der Netzwerkstabilität und Reichweite. Darum nachfolgend allgemeine, aber sehr einfache Empfehlungen zur Geräteauswahl. Selbstverständlich wird hier nicht von anderen Produkten abgeraten, wenn man die Unterschiede kennt und Vorteile bei deren Produkteigenschaften sieht. Zudem kann man (leider) schlechtere Produkteigenschaften bei Geräten mit aktuelleren Chipsätzen/SDKs nie ausschließen.
 
Gateway
# [http://z-wavealliance.org/z-wave_plus_certification Z-Wave Plus-Zertifizierung]. Diese ist mittlerweile bei nahezu allen erhältlichen Gateways gegebenen.
 
Endgeräte
# Z-Wave Plus-Zertifizierung (aktuellste Technik, höhere theoretische Reichweite, SDK 6.5x oder höher) oder
# zumindest Explorer Frames-Unterstützung (SDK 4.5x und 6.0x) oder
# zuletzt -bei Kenntnis der Besonderheiten und Auswirkungen- Produkte ohne Explorer Frames (SDK 5.0x)
 
'''Kurz''': Produkte mit Z-Wave Plus-Zertifizierung einsetzen.


== Z-Wave in Fhem ==
Bitte unbedingt beachten, dass Z-Wave Plus-Vorteile bei einem Mischbetrieb mit älteren (ohne Plus) Geräten teilweise verloren gehen. Zum negativen Effekt des Einsatzes eines älteren, aber weiterhin erhältlichen Z-Wave-Repeaters mit aktuellen Z-Wave Plus-Geräten siehe beispielsweise den Hinweis in diesem {{Link2Forum|Topic=42591|Message=350066}}.
 
Bei Fragen zu bestimmten Geräten bitte -nach Durchsicht der Hinweise hier im Wiki- im Forum suchen oder anschließend nachfragen.
 
== Z-Wave in FHEM ==
=== Allgemein ===
=== Allgemein ===
Fhem wird fortwährend weiterentwickelt und verbessert. Daher ist es zwingend notwendig, dass Fhem auf dem aktuellsten Stand ist. Dazu nach der Fhem-Installation den Befehl <code>update</code> ausführen und anschließend <code>shutdown restart</code> durchführen. Genauso auch vor Anfragen im Forum die Aktualität von Fhem überprüfen.
FHEM wird fortwährend weiterentwickelt und verbessert. Daher ist es zwingend notwendig, dass FHEM auf dem aktuellsten Stand ist. Dazu nach der FHEM-Installation den Befehl <code>update</code> ausführen und anschließend <code>shutdown restart</code> durchführen. Genauso auch vor [[#Welche_Infos_sollten_Anfragen_im_ZWave-Forum_enthalten.3F|Anfragen im Forum]] die Aktualität von FHEM überprüfen.


Die Nutzung von Z-Wave in Fhem ist für den Anfänger nur mit der standardmäßig eingeschalteten [http://fhem.de/commandref.html#autocreate autocreate-Funktion] einfach umsetzbar. Die Kenntnis der Fhem-Grundlagen und Durcharbeitung der Anfänger-Lektüren wird im Folgenden vorausgesetzt. Insbesondere ist [http://fhem.de/Heimautomatisierung-mit-fhem.pdf Heimautomatisierung mit Fhem] Pflicht, auch wenn es nicht speziell Z-Wave behandelt, so werden doch wesentliche Punkte für ein Verständnis von Fhem vermittelt.
Die Einbindung von Z-Wave in FHEM ist (nicht nur für den Anfänger) ausschließlich mit der standardmäßig eingeschalteten [[autocreate|autocreate-Funktion]] einfach möglich. Die Kenntnis der FHEM-Grundlagen und Durcharbeitung der Anfänger-Lektüren wird im Folgenden vorausgesetzt. Insbesondere sind [[Erste_Schritte_in_FHEM|Erste Schritte in FHEM]] und [http://fhem.de/Heimautomatisierung-mit-fhem.pdf Heimautomatisierung mit FHEM] Pflicht, auch wenn sie nicht speziell Z-Wave behandeln, so werden doch wesentliche Punkte für ein Verständnis von FHEM vermittelt.


Im Folgendem und auf den [[:Kategorie:Z-Wave Components|Wiki-Seiten der Einzelgeräte]] werden immer wieder Auszüge aus der [[Konfiguration]] dargestellt. Diese dienen zur Erläuterung und Veranschaulichung. Die Bearbeitung der Konfiguration sollte -zur Verhinderung von Fehlern- nach Möglichkeit immer über das "[[Konfiguration#Befehl-Eingabefeld|Befehl-Eingabefeld]]" und die "[[Konfiguration#Objektdetails|Objektdetails]]" erfolgen.
Nachfolgend und auf den [[:Kategorie:Z-Wave Components|Wiki-Seiten der Einzelgeräte]] werden immer wieder Auszüge aus der [[Konfiguration]] dargestellt. Diese dienen zur Erläuterung und Veranschaulichung. Die Bearbeitung der Konfiguration sollte -zur Verhinderung von Fehlern- nach Möglichkeit immer über das "[[Konfiguration#Befehl-Eingabefeld|Befehl-Eingabefeld]]" und die "[[Konfiguration#Objektdetails|Objektdetails]]" erfolgen.


=== Vorbereitung ===
=== Vorbereitung ===
Die Bedienungsanleitungen (Handbücher) sind zwingende Voraussetzung zur korrekten Einbindung und Konfiguration von Z-Wave-Geräten in Fhem. Sie müssen daher vorliegen. Die Handbücher und technischen Informationen vieler Z-Wave-Geräte sind -trotz verschiedener Hersteller- zentral unter http://www.zwave.de/handbuecher/ in Deutsch abrufbar. Der Aufbau aller dort veröffentlichten Handbücher ist gleichartig, so dass man einen schnellen Einstieg in die Produkte und deren technischen Eigenschaften von verschiedenen Herstellern findet. Manche Hersteller (z.B. Fibaro) bieten zusätzlich auf Ihren Internetseiten noch separate, eigene Handbücher an. Bei ZWave-Plus-zertifizierten Geräten sind die Handbücher zudem unter http://products.z-wavealliance.org suf der gerätespezifischen Seite zu finden.
Die Bedienungsanleitungen (Handbücher) sind zwingende Voraussetzung zur korrekten Einbindung und Konfiguration von Z-Wave-Geräten in FHEM. Sie müssen daher vorliegen. Den ZWave-Geräten liegen teilweise nur gekürzte, gedruckte Fassungen der Handbücher bei. Man sollte bei allen Produkten auf folgenden Seiten nach eventuellen ausführlicheren Informationen suchen:
* Herstellerseite des ZWave-Gerätes
* https://products.z-wavealliance.org (englisch)
* https://devices.zwave-js.io/ oder https://github.com/zwave-js/node-zwave-js/tree/master/packages/config/config/devices (werden wohl im Wesentlichen aus den Daten von products.z-wavealliance.org erzeugt)
* https://opensmarthouse.org/zwavedatabase/
Insbesondere auf https://products.z-wavealliance.org, der Datenbank der ZWave-zertifizierten Produkte, sind regelmäßig ausführliche Informationen zu den Geräten zu finden.


== Definition des Gateways / Controllers ==
== Definition des Gateways / Controllers ==
{{Randnotiz|RNText='''Tester für ZWave@culfw gesucht!'''
Z-Wave-Controllerfunktionen werden derzeit in die Firmware [http://www.culfw.de culfw] für den [[CUL]] implementiert. Weitere Informationen im [[ZWCUL]] - Artikel.}}
=== Autocreate des Gateways ===
=== Autocreate des Gateways ===
Fhem kann mit einem Funkgateway Z-Wave-Funk empfangen und senden. Z-Wave-Gateways existieren von verschiedenen Herstellern.  
FHEM kann mit einem Funkgateway Z-Wave-Funk empfangen und senden. Z-Wave-Gateways (Controller) existieren von verschiedenen Herstellern.
 
Folgende Gateways wurden unter anderem bereits erfolgreich mit FHEM eingesetzt:
* AEON Labs Z-Stick S2 (SDK 5.x; [https://aeotec.freshdesk.com/support/solutions/articles/6000091809-z-stick-s2-v3-08-firmware-update Firmwareupdate auf 3.08 aus 2016])
* Aeotec Z-Stick Gen5 (Z-Wave Plus; SDK 6.5; [https://aeotec.freshdesk.com/support/solutions/articles/6000108806-z-stick-gen5-backup-software Backup-Software)] ({{Link2Forum|Topic=47000}})
* Goodway WD6001 (SDK 5.03 {{Link2Forum|Topic=40594|Message=332235}})
* Vision Z-Wave USB Stick ZU 1401 EU (SDK 6.0x)
* Vision Z-Wave USB Stick ZU 1401-5 EU (Z-Wave Plus; SDK 6.5x)
* Z-Wave.Me Z-StickC ({{Link2Forum|Topic=29930|Message=226530}})
* Z-Wave.Me USB Stick ZME_UZB1 (SDK 6.5x;  Z-Wave Plus; [http://razberry.z-wave.me/z-way-server/ Firmwareupdate und Backup über z-way])
* Z-Wave.Me Razberry in Verbindung mit Raspberry Pi (1. Generation: Z-Wave, 2. Generation: Gen5-Razberry mit Z-Wave Plus[http://forum.z-wave.me/viewtopic.php?f=3419&t=21327#p55404])
** Die seriellen Schnittstelle /dev/ttyAMA0 muss am Raspberry Pi freigeschaltet werden, damit das Razberry-Modul funktionsfähig ist: {{Link2Forum|Topic=78248|Message=702044}})
** Beim Raspberry Pi 3 muss der GPIO-Port auf den Hardware-UART0 umgestellt werden: [[Raspberry Pi 3: GPIO-Port Module und Bluetooth]]
 
Folgende Gateways sind '''nicht''' mit FHEM einsetzbar:
* Merten Funk-USB-Datenschnittstelle CONNECT
 
Sollte das eigene Gateway hier nicht aufgeführt sein, ist aufgrund der Standardisierung dennoch die Chance für eine erfolgreiche Einbindung des Gateways in FHEM vorhanden. Bitte dies hier oder im Forum entsprechend vermerken.
 
Das Z-Wave-Gateway wird unter Linux nach Anschluss an den FHEM-Rechner beim nächsten FHEM-Start oder ohne FHEM-Neustart durch Aufruf des Befehls <code>usb scan</code> zumeist automatisch erkannt und das zugehörige FHEM-Device nach dem Namensschema <code>ZWDongle_<[https://forum.fhem.de/index.php/topic,92885.msg854533.html#msg854533 Anhang]></code> angelegt. Ein manuelles Anlegen des ZWDongle-Moduls oder Eingriffe in die Konfiguration sind unter Linux normalerweise nicht notwendig.
 
Unter Windows ist ein manuelles Anlegen der Definition des ZWave-Gateways wegen fehlender Unterstützung des Befehls <code>usb scan</code> erforderlich (Beispiel für Z-Wave.Me USB Stick ZME_UZB1 unter Windows: <code>define ZWDongle_1 ZWDongle COM1@115200</code>).  


Das Z-Wave-Gateway wird unter Linux nach Anschluss an den Fhem-Rechner beim nächsten Fhem-Start oder ohne Fhem-Neustart durch Aufruf des Befehls <code>usb scan</code> zumeist automatisch erkannt und grundlegend durch entsprechende Einträge in der Konfiguration definiert. Ein manuelles Anlegen des ZWDongle-Moduls oder Eingriffe in die Konfiguration sind normalerweise nicht notwendig und auch nicht ratsam. Unter Windows ist ein manuelles Anlegen der Definition des ZWave-Gateways wegen fehlender Unterstützung des Befehls <code>usb scan</code> notwendig. Das Fhem-Gateway-Device ist nach der Definition in Fhem im Raum "Everything" zu finden.
Das FHEM-Gateway-Device ist nach der Definition in FHEM im Raum "Everything" zu finden.


Beispiele der automatisch erzeugten define-Zeile in der Konfiguration:
Beispiele der automatisch erzeugten define-Zeile in der Konfiguration:


Aeon Labs Z-Stick an der Fritzbox:  
Aeon Labs Z-Stick an der Fritzbox:  
  define ZWDongle_1 ZWDongle /dev/ttyUSB0@115200
  define ZWDongle_1 ZWDongle /dev/ttyUSB1@115200


Vision Z-Wave USB Stick ZU 1401 EU am Raspberry Pi:
Vision Z-Wave USB Stick ZU 1401 EU am Raspberry Pi (Raspbian):
  define ZWDongle_1 ZWDongle /dev/ttyACM0@115200
  define ZWDongle_1 ZWDongle /dev/ttyACM1@115200


Folgende Gateways wurden bereits erfolgreich mit Fhem eingesetzt:
Insbesondere wenn am FHEM-Server unter Linux mehrere USB-Gateways eingesetzt werden, empfiehlt es sich zur Erhöhung der Betriebsstabilität das Z-Wave-Gateway über [[Trick_der_Woche#CUL_.26_CO_.C3.BCber_Serial_ID-einbinden|Serial-by-Id]] oder [[LinuxDeviceNaming|uDev-Regeln]] anzusprechen.
* AEON Labs Z-Stick S2 (SDK 5.x; aktuellste Firmware 3.07 ist von 6/2010)
* Goodway WD6001 (SDK ??)
* Razberry in Verbindung mit Raspberry Pi (neue Gen5 Razberry: Z-Wave Plus[http://forum.z-wave.me/viewtopic.php?f=3419&t=21327#p55404]) (Notwendige Vorarbeiten: {{Link2Forum|Topic=11716|Message=190402}})
* Vision Z-Wave USB Stick ZU 1401 EU (VIS_ZU1401; SDK 6.x)
* Z-Wave.Me Z-StickC ({{Link2Forum|Topic=29930|Message=226530}})
* Z-Wave USB Stick (ZME_UZB1; Z-Wave Plus) ({{Link2Forum|Topic=30257}})


Folgende Gateways sind '''nicht''' mit Fhem einsetzbar:
Bei einem statischen Controller wird die Einrichtung als SUC -sofern der Controller als solcher nicht bei Auslieferung eingerichtet ist- vor der ersten Inklusion von Geräten empfohlen.
* Merten Funk-USB-Datenschnittstelle CONNECT
 
Sollte das eigene Gateway hier nicht aufgeführt sein, ist aufgrund der Standardisierung dennoch die Chance für eine erfolgreiche Einbindung des Gateways in Fhem vorhanden. Bitte dies hier oder im Forum entsprechend vermerken.
 
Bei der Auswahl des Gateways (und auch der Sensoren/Aktoren) empfiehlt es sich, auf das unterstützte SDK zu achten. Gateways mit Unterstützung von SDK 4.5x und 6.x oder neuer bieten mehr Funktionen, insbesondere auch hinsichtlich der Netzwerkstabilität (Explorer Frames), als Gateways mit ältere SDK-Versionen. Aber '''ACHTUNG:''' das SDK 5.x ist älter als SDK 4.5x. Details hierzu enthält das [http://wiki.zwaveeurope.com/index.php?title=SDK_Versions_and_Explorer_Frames wiki.zwaveeurope.com]. Einen Hinweis auf ein derzeit aktuelles SDK bietet auch die [http://z-wavealliance.org/z-wave_plus_certification Z-Wave Plus-Zertifizierung].


=== homeId und nodeList des Gateways ===
=== homeId und nodeList des Gateways ===
Zur manuellen Definition von Z-Wave Aktoren und Sensoren ist die <code>homeId</code> notwendig. Bei der hier bevorzugten Definition der Geräte durch autocreate ist die Kenntnis der <code>homeId</code> nicht zwingend. Jedoch kann durch Abfrage der <code>homeId</code> direkt nach Einbindung des Zwave-Gateways dessen Funktionsfähigkeit getestet werden.
Zur manuellen Definition von Z-Wave Aktoren und Sensoren ist die <code>homeId</code> notwendig. Bei der hier bevorzugten Definition der Geräte durch autocreate ist die Kenntnis der <code>homeId</code> nicht zwingend. Jedoch sollte durch Abfrage der <code>homeId</code> direkt nach Einbindung des Zwave-Gateways dessen Funktionsfähigkeit getestet werden.


Die <code>homeId</code> und <code>CtrlNodeId</code> des Gateways wird mit folgendem Befehl ausgelesen (ZWDongle_1 ist im folgenden durch den eigenen Gatewaynamen zu ersetzen):
Die <code>homeId</code> und <code>CtrlNodeId</code> des Gateways wird mit folgendem Befehl ausgelesen (<ZWDongle> ist im folgenden durch den Namen des FHEM-Devices des eigenen Gateways zu ersetzen):
  get ZWDongle_1 homeId
  get <ZWDongle> homeId
ergibt beispielsweise:
ergibt beispielsweise bei einem Gateway mit dem FHEM-Devicenamen ZWDongle_1:
  ZWDongle_1 homeId => HomeId:e345c456 CtrlNodeId:01  
  ZWDongle_1 homeId => HomeId:e345c456 CtrlNodeId:01  
In diesem Beispiel ist die Home-Id des Gateways ZWDongle_1 e345c456 und das Gateway hat die Node-Id 1.


Die aktuelle Liste der Z-Wave Nodes, die bereits am Gateway registriert/inkludiert sind, wird mit dem folgendem Befehl ausgelesen:
Die aktuelle Liste der Z-Wave Nodes, die bereits am Gateway registriert/inkludiert sind, wird mit dem folgendem Befehl ausgelesen:
  get ZWDongle_1 nodeList
  get <ZWDongle> nodeList
ergibt beispielsweise:
ergibt beispielsweise:
  ZWDongle_1 nodeList => 1,2,3,4,5
  ZWDongle_1 nodeList => ZWDongle_1 UNKNOWN_2
 


== Definition von Geräten / Slaves ==
== Definition von Geräten / Slaves ==
=== Hinzufügen eines neuen Z-Wave Geräts / Inklusion ===
=== Hinzufügen eines neuen Z-Wave Geräts / Inklusion ===
Zuerst wird das Z-Wave Gateway in den Standard-Modus zur Inklusion (zum Aufnehmen) neuer Geräte gesetzt:
Zur Verfolgung von Inklusionsablauf und Meldungen des Controllers während der Inklusion sollte der [[Event monitor]] in einem 2. Browserfenster vor Aktivierung des Inklusionsmodus geöffnet werden.
  set ZWDongle_1 addNode on
 
Das Z-Wave Gateway wird in den Standard-Modus zur Inklusion (zum Aufnehmen) neuer Geräte gesetzt:
  set <ZWDongle> addNode on
Bei der Standard-Inklusion muss direkter Funkkontakt zwischen Gateway und zu inkludierendem Z-Wave Gerät bestehen.
Bei der Standard-Inklusion muss direkter Funkkontakt zwischen Gateway und zu inkludierendem Z-Wave Gerät bestehen.


Sofern Z-Wave Gateway und Z-Wave Geräte Explorer Frames unterstützen, sollte statt dem obigen Befehl besser der Network-Wide-Modus für die Inklusion genutzt werden:
Sofern Z-Wave Gateway und Z-Wave Geräte Explorer Frames unterstützen, sollte statt des obigen Befehls besser der Network-Wide-Modus für die Inklusion genutzt werden:
  set ZWDongle_1 addNode nwOn
  set <ZWDongle> addNode onNw
Bei der Network-Wide-Inklusion muss kein direkter Funkkontakt zwischen Gateway und zu inkludierendem Z-Wave Gerät bestehen. Es reicht, wenn das zu inkludierende Gerät über andere bereits inkludierte, netzgespeiste Geräte mit Explorer Frames-Unterstützung erreicht werden kann. Die Network-Wide-Inklusion ist zu bevorzugen, da die Z-Wave-Geräte regelmäßig an Ihren örtlichen Endpositionen inkludiert werden können. Dadurch werden bei der Inklusion direkt die korrekten Routen gespeichert.  
Bei der Network-Wide-Inklusion muss kein direkter Funkkontakt zwischen Gateway und zu inkludierendem Z-Wave Gerät bestehen. Es reicht, wenn das zu inkludierende Gerät über andere bereits inkludierte, netzgespeiste Geräte mit Explorer Frames-Unterstützung erreicht werden kann. Die Network-Wide-Inklusion ist zu bevorzugen, da die Z-Wave-Geräte regelmäßig an Ihren örtlichen Endpositionen inkludiert werden können. Dadurch werden bei der Inklusion direkt die korrekten Routen gespeichert.  


Nachdem das Gateway in den Inklusionmodus geschaltet wurde, muss das Gerät in den Inklusionsmodus (Aufnahmemodus) versetzt werden. Wie dies zu erfolgen hat, ist im Handbuch des Geräte nachzulesen. Typisch sind ein- oder dreimaliges Drücken einer Taste am Gerät oder beim Anlegen der Versorgungsspannung. Durch die Inklusion werden Home-ID und Node-ID im Gerät gespeichert. Zudem teilt das Gerät über ein spezielle Funknachricht (NIF=Node Information Frame) dem Controller seinen Gerätetyp und seine Geräteeigenschaften mit. Hierbei werden dem Controller auch die vom Gerät unterstützten Command Classes mitgeteilt. Aus diesen Informationen erzeugt Fhem automatisch durch autocreate das Fhem-Geräte-Device. Die vom Geräte unterstützen Command Classes werden automatisch im Attribut <code>classes</code> des Fhem-Geräte-Device gespeichert. Das Gerät ist damit grundlegend in Fhem definiert.
Nachdem das Gateway in den Inklusionmodus geschaltet wurde, muss das Gerät in den Inklusionsmodus (Aufnahmemodus) versetzt werden. Wie dies zu erfolgen hat, ist im Handbuch des Geräte nachzulesen. Typisch sind ein- oder dreimaliges Drücken einer Taste am Gerät oder beim Anlegen der Versorgungsspannung. Durch die Inklusion werden Home-ID und Node-ID im Gerät gespeichert. Zudem teilt das Gerät über ein spezielle Funknachricht (NIF=Node Information Frame) dem Controller seinen Gerätetyp und seine Geräteeigenschaften mit. Hierbei werden dem Controller auch die vom Gerät unterstützten Command Classes mitgeteilt. Aus diesen Informationen erzeugt FHEM automatisch durch autocreate das FHEM-Geräte-Device nach dem Namensschema <code><nowiki>ZWave_<Geräteklasse laut NIF des Gerätes>_<NodeID></nowiki></code> (an eigene Wünsche anpassbar mit {{Link2CmdRef|Anker=rename|Label=rename}}). Die vom Geräte unterstützen Command Classes, die die in FHEM verfügbaren Befehle bestimmen, werden automatisch im Attribut <code>classes</code> des FHEM-Geräte-Device gespeichert. Das Gerät ist damit grundlegend in FHEM definiert und im Raum "ZWave" zu finden.  


Abschließend wird der Inklusionsmodus am Z-Wave Gateway wieder ausgeschaltet:
Nach der Inklusion schaltet FHEM den Inklusionsmodus des Z-Wave Gateway automatisch durch Absetzen des Befehls <code>set <ZWDongle> addNode off</code> aus und zeigt eine Dialogbox mit dem Ergebnis der Inklusion:
  set ZWDongle_1 addNode off
* <code><nowiki>created ZWave_<Geräteklasse laut NIF des Gerätes>_<NodeID></nowiki></code> = Inklusion war erfolgreich und es wurde das bezeichnete FHEM-Device durch autocreate angelegt.
* <code><nowiki>addNode failed</nowiki></code> = Inklusion ist fehlgeschlagen
   
Eine erfolgreiche Inklusion ist zudem am Event "ZW_ADD_NODE_TO_NETWORK protocolDone" im Event monitor und natürlich der Anlage des entsprechenden FHEM-Devices durch autocreate zu erkennen.  Das Scheitern einer Inklusion führt typischerweise zur Ausgabe des Events "ZW_ADD_NODE_TO_NETWORK failed". Häufigste Ursache sind Controllerprobleme, die sich oftmals durch kurzes Ein- und Ausstecken des Controllers, Neustart des Systems oder Ein- und Ausschalten des FHEM-Server-Computers beheben lassen.


HINWEISE:<br />
HINWEISE:<br />
* Nach Verständnis des Wikiseiten-Bearbeiters sollte die Network-Wide-Inklusion auch bei Gateways und Geräten ohne Explorer Frames Unterstützung genutzt werden können, da bei diesen Geräten automatisch auf die Standard-Inklusion umgestellt wird. Eine Prüfung ist mangels entsprechender Testgeräte bisher nicht möglich gewesen.
* Die Network-Wide-Inklusion kann nach derzeitiger Kenntnis auch bei Gateways und Geräten ohne Explorer Frames Unterstützung genutzt werden, da bei diesen Geräten grundsätzlich automatisch auf die Standard-Inklusion umgestellt wird.
* Bei der Standard-Inklusion ist unter Umständen nur ein geringer Abstand zwischen Gateway und Gerät möglich. Sollte die Inklusion daher nicht durchführbar sein, wenn Gateway und Gerät an ihren örtlichen Endpositionen sind (bevorzugte Variante), dann ist der Abstand zwischen diesen versuchsweise zu verringern. Anschließend bei örtlicher Veränderung die Routen mit <code>set <ZWDongle> neigbourUpdate <nodeID></code> neu ermitteln lassen. Unter Umständen kann der Abstand nur schrittweise erhöht werden. Dann ist bei jeder Abstandsänderung eine Neuermittlung der Routen notwendig.
* Bei der Standard-Inklusion ist unter Umständen nur ein geringer Abstand zwischen Gateway und Gerät möglich. Sollte die Inklusion daher nicht durchführbar sein, wenn Gateway und Gerät an ihren örtlichen Endpositionen sind (bevorzugte Variante), dann ist der Abstand zwischen diesen versuchsweise zu verringern. Anschließend bei örtlicher Veränderung die Routen mit <code><nowiki>set <ZWave-Devicename> neighborUpdate</nowiki></code> bzw. <code><nowiki>set TYPE=ZWave:FILTER=ZWaveSubDevice=no neighborUpdate</nowiki></code> neu ermitteln lassen. Unter Umständen kann der Abstand nur schrittweise erhöht werden. Dann ist bei jeder Abstandsänderung eine Neuermittlung der Routen notwendig.
* Der NIF enthält bei manchen Geräten nicht alle unterstützten Command Classes. Fhem identifiziert während der Inklusion das Gerät und ergänzt die fehlenden Command Classes aufgrund manuell gepflegter, gerätespezifischer [[#Welche_Funktion_haben_die_XML-Config-Dateien_in_Fhem.3F|XML-Config-Dateien]]. Weiterhin fehlende Command Classes können im Attribut <code>classes</code> manuell entsprechend ergänzt werden. Informationen liefern die unter [[#Links|Links]] aufgeführten Datenbanken. Häufig fehlt die Pflicht-Class BASIC.
* Der NIF enthält bei manchen Geräten fälschlicherweise nicht alle unterstützten Command Classes. FHEM identifiziert während der Inklusion das Gerät und ergänzt die fehlenden Command Classes aufgrund manuell gepflegter, gerätespezifischer [[#Welche_Funktion_haben_die_XML-Config-Dateien_in_FHEM.3F|XML-Config-Dateien]]. Weiterhin fehlende Command Classes können im Attribut <code>classes</code> manuell am Anfang der Liste entsprechend ergänzt werden. Informationen liefern die unter [[#Links|Links]] aufgeführten Datenbanken. Häufig fehlt die Pflicht-Class BASIC.
* Bei der hier beschriebenen Inklusion findet die Kommunikation zwischen Controller und Gerät anschließend dauerhaft unverschlüsselt statt. Manche Geräte bieten mit der Command Class SECURITY eine AES-verschlüsselte Kommunikation an. Da die Verschlüsselung zu einer höheren Funklast und Latenzen führt, sollte eine verschlüsselte Kommunikation nur mit Bedacht eingesetzt werden (bspw. bei Schlössern). Als Sonderfall ist das Vorgehen zur secure-Inklusion in der [[#Wie_kann_eine_verschl.C3.BCsselte_Kommunikation_unter_Nutzung_der_Command_Class_SECURITY_eingerichtet_werden.3F|FAQ]] beschrieben.


Nächster Schritt ist die [[#Assoziation|Assoziation]] des Gerätes mit dem Gateway.
Nächster Schritt ist die [[#Assoziation|Assoziation]] des Gerätes mit dem Gateway.


=== Assoziation ===
=== Assoziation ===
Geräte können über Assoziationen direkt mit anderen Geräten kommunizieren. Dies können zum einen Meldungen über den Status und Zustand der Geräte, als auch direkte Befehle sein. Zum Beispiel kann damit ein Bewegungsmelder eine entdeckte Bewegung an den Controller senden und/oder bei entdeckter Bewegung direkt eine Lampe ein- oder ausschalten.
{{Randnotiz|RNText=Bitte unbedingt die Besonderheiten bei [[#batteriebetriebene_Ger.C3.A4te|batteriebetriebenen Geräten]] beachten!}}
Z-Wave-Geräte können über Assoziationen direkt mit anderen Z-Wave-Geräten kommunizieren. Dies können zum einen Meldungen über den Status und Zustand der Geräte, als auch direkte Befehle sein. Zum Beispiel kann damit ein Bewegungsmelder eine entdeckte Bewegung an den Controller senden und/oder bei entdeckter Bewegung direkt eine Lampe ein- oder ausschalten.


Geräte können mehrere Assoziationsgruppen (Association Groups) haben, die für vom Hersteller vorgesehene unterschiedliche Aktionen definiert sind. Welche das sind, geht aus der jeweiligen Bedienungsanleitung hervor.
Die Assoziation zwischen zwei Geräten wird durch Aufnahme des zu steuernden Gerätes in eine oder mehrere Assoziationsgruppe(n) des steuernden Gerätes angelegt. Durch die Wahl der Assoziationsgruppe wird festgelegt, bei welchen Ereignissen welche Nachricht an das assoziierte Gerät verschickt wird. Angaben zu den Ereignissen und versandten Nachrichten an die Geräte in einer bestimmten Assoziationsgruppe stehen in der Bedienungsanleitung des jeweiligen Gerätes.


Damit Fhem Statusmeldungen von Sensoren/Aktoren anzeigen und auch darauf reagieren kann, '''muss''' der Controller (ZWDongle_1, <code>CtrlNodeId</code> = typischerweise 1) mit der/den passenden Assoziationsgruppe(n) des jeweiligen Gerätes <code><name></code> assoziiert werden:
Damit FHEM Statusmeldungen von Sensoren/Aktoren anzeigen und auch darauf reagieren kann, '''muss''' der Controller (<ZWDongle>-Device, <code>CtrlNodeId</code> = typischerweise 1) immer in der/den passenden Assoziationsgruppe(n) des jeweiligen Gerätes <code><name></code> aufgenommen werden:


  set <name> associationAdd <associationGroup> <CtrlNodeId>
  set <name> associationAdd <associationGroup> <CtrlNodeId>


Typischerweise ist die Assoziationsgruppe 1 der Geräte für die Statusmeldungen an den Controller vorgesehen (Ausnahme: [[#Fibaro|Fibaro]]). Daher legt Fhem die Assoziation von Controller mit der Assoziationsgruppe 1 des Gerätes bei der Inklusion immer automatisch an. Zudem identifiziert Fhem während der Inklusion das Gerät und setzt weitere Assoziationen mit dem Controller für von 1 abweichende Assoziationsgruppen aufgrund manuell gepflegter, gerätespezifischer [[#Welche_Funktion_haben_die_XML-Config-Dateien_in_Fhem.3F|XML-Config-Dateien]]. Ist keine XML-Config-Datei für das Gerät vorhanden, sind Assozationen des Controllers mit von 1 abweichenden Assoziationsgruppen oder weiteren Assoziationsgruppen mit dem zuvor genannten Befehl grundsätzlich manuell anzulegen.  
Typischerweise ist die Assoziationsgruppe 1 der Geräte für die Statusmeldungen an den Controller vorgesehen (Ausnahme: [[#Fibaro|Fibaro-Geräte ohne ZWave Plus - Zertifizierung]]). Daher nimmt FHEM die Assoziation von Controller mit der Assoziationsgruppe 1 des Gerätes bei der Inklusion immer automatisch vor. Zudem identifiziert FHEM während der Inklusion das Gerät und setzt weitere Assoziationen mit dem Controller für von 1 abweichende Assoziationsgruppen aufgrund manuell gepflegter, gerätespezifischer [[#Welche_Funktion_haben_die_XML-Config-Dateien_in_FHEM.3F|XML-Config-Dateien]]. Ist keine XML-Config-Datei für das Gerät vorhanden, sind Assoziationen des Controllers mit von 1 abweichenden Assoziationsgruppen oder weiteren Assoziationsgruppen mit dem zuvor genannten Befehl grundsätzlich manuell anzulegen.  


Die richtige Anlage der Assoziation(en) des Controllers mit dem Gerät immer prüfen, da dies eine Hauptfehlerquelle bei Funktionsproblemen mit Fhem ist:
Die richtige Anlage der Assoziation(en) des Controllers mit dem Gerät immer prüfen, da dies eine Hauptfehlerquelle bei Funktionsproblemen mit FHEM ist.


Abruf der assoziierten Geräte in einer bestimmten Assoziationsgruppe <associationGroup>:
  get <name> association <associationGroup>
  get <name> association <associationGroup>
Abruf der assozierten Geräte für alle Assoziationsgruppen eines Gerätes:
get <name> associationAll


Nahezu alle in Europa erhältlichen aktuellen Geräte unterstützen die Rückmeldung des Status via Association. Ausnahmen gibt es in Nordamerika, wo aufgrund von Patentansprüchen einige Hersteller auf die Statusrückmeldungen verzichten. Diese Geräte unterstützen in der Regel die Command Class ASSOCIATION nicht.
Nahezu alle in Europa erhältlichen aktuellen Geräte unterstützen die Rückmeldung des Status via Association. Ausnahmen gibt es in Nordamerika, wo aufgrund von Patentansprüchen einige Hersteller auf die Statusrückmeldungen verzichten. Diese Geräte unterstützen in der Regel die Command Class ASSOCIATION nicht.
Zeile 152: Zeile 203:


=== Konfiguration ===
=== Konfiguration ===
Die Standard-Konfiguration eines Gerätes entspricht oftmals nicht den eigenen Wünschen und Anforderungen (Einheiten usw.). Mit der Class CONFIGURATION lässt sich die Konfiguration ändern. Die Konfiguration beispielsweise bei Parametergröße 1 lässt sich mit diesem Befehl anpassen:
{{Randnotiz|RNText=Bitte unbedingt die Besonderheiten bei [[#batteriebetriebene_Ger.C3.A4te|batteriebetriebenen Geräten]] beachten!}}
Die Standard-Konfiguration eines Gerätes entspricht oftmals nicht den eigenen Wünschen und Anforderungen (Einheiten usw.). Mit den Befehlen der Class CONFIGURATION lässt sich die Konfiguration anpassen. Die zur Konfiguration eines Gerätes notwendigen Angaben zu den Parameternummern, -größen und -werten sind im jeweiligen Geräte-Handbuch bzw. entsprechenden Datenbanken (bspw. [http://devel.pepper1.net/zwavedb/ pepper1-ZWave-Datenbank] oder [http://products.zwavealliance.com/ products.zwavealliance.com]) enthalten.  
 
Die Konfiguration beispielsweise bei Parametergröße 1 lässt sich mit diesem Befehl anpassen:
  set <name> configByte <Parameternummer> <Parameterwert>
  set <name> configByte <Parameternummer> <Parameterwert>
Für weitere Parametergrößen gibt es die Befehle <code>configWord</code> und <code>configLong</code>


Die Angaben zu den Parameternummern, -größen und -werten sind im jeweiligen Geräte-Handbuch enthalten.
Die im Gerät hinterlegten Konfiguration kann pro Parameternummer mit folgendem Befehl abgerufen werden:
get <name> config <Parameternummer>


Zudem bietet Fhem basierend auf den XML-Config-Dateien die Möglichkeit die speziellen Parameternummern, -größen und -werten des Gerätes mit Hilfsinformationen einzubinden ({{Link2Forum|Topic=27455|Message=205414}}). Ein manuelles Suchen im Geräte-Handbuch ist dadurch in vielen Fällen unnötig. Für diese Funktion muss das Gerät von Fhem einmalig durch folgenden Befehl, der bei der Inklusion automatisch ausgeführt wird, identifiziert werden:   
Zudem bietet FHEM basierend auf den manuell gepflegten XML-Config-Dateien die Möglichkeit, die speziellen Parameternummern des Gerätes mit ihren Parametergrößen und -werte als eigenständige config-Befehle mit Hilfsinformationen einzubinden. Ein manuelles Suchen im Geräte-Handbuch und Nutzung der configByte-, configWord- und configLong-Befehle ist dadurch in vielen Fällen unnötig. Für diese Funktion muss das Gerät von FHEM einmalig durch folgenden Befehl, der bei der Inklusion automatisch ausgeführt wird, identifiziert werden:   
  get <name> model
  get <name> model
Die Readings <code>model</code>, <code>modelID</code> und <code>modelConfig</code> werden dadurch erzeugt. In <code>model</code> sollte der Klartextname des Gerätes stehen. Zudem sind dann spezielle set/get-Kommandos configXYZ für das Geräte im Auswahldialog der Detailansicht mit Hilfsinformationen verfügbar.
Die Readings <code>model</code>, <code>modelID</code> und <code>modelConfig</code> werden dadurch erzeugt. In <code>model</code> sollte der Klartextname des Gerätes stehen. Zudem sind dann -soweit eine XML-Config Datei für das Gerät existiert- die speziellen set/get-Kommandos configXYZ für das Geräte im Auswahldialog der Detailansicht mit Hilfsinformationen verfügbar:
[[Datei:Z-Wave_confighelp.PNG|900px|thumb|center|config-Befehl mit Hilfstext]]
 
Bei vorhandener XML-Config-Datei kann die komplette Konfiguration eines Gerätes abgerufen werden:
get <name> configAll
 
Außerdem wird durch den <code>get <name> model</code> -Befehl geprüft, ob das Gerät in der [http://devel.pepper1.net/zwavedb/ pepper1-ZWave-Datenbank] und/oder [http://products.zwavealliance.com/ products.zwavealliance.com] enthalten ist. Im Erfolgsfall wird ein Link "Details in pepper DB" und/oder "Details in alliance DB" zum entsprechenden Geräteeintrag in der jeweiligen Datenbank unten in der Detailansicht des FHEM-Geräte-Devices angelegt und ein Bild des Gerätes in die Detailansicht eingebunden.


Der Aufruf von <code>get <name> model</code> ist auch für die Nutzung der Class MANUFACTURER_PROPRIETARY zwingende Einsatzvoraussetzung.
Der Aufruf von <code>get <name> model</code> ist auch für die Nutzung der Class MANUFACTURER_PROPRIETARY zwingende Einsatzvoraussetzung.
Zeile 167: Zeile 229:


Zuerst wird der Z-Wave Gateway in den Standard-Modus zur Exklusion (Ausschluss) von Geräten gesetzt:
Zuerst wird der Z-Wave Gateway in den Standard-Modus zur Exklusion (Ausschluss) von Geräten gesetzt:
  set ZWDongle_1 removeNode on
  set <ZWDongle> removeNode on


Sofern Z-Wave Gateway und Z-Wave Geräte Explorer Frames unterstützen, sollte statt dem obigen Befehl besser der Network-Wide-Modus für die Exklusion genutzt werden (siehe auch Erläuterungen zu Standard- versus Network-Wide-Inklusion unter [[#Hinzufügen eines neuen Z-Wave Geräts / Inklusion|Inklusion]]):
Sofern Z-Wave Gateway und Z-Wave Geräte Explorer Frames unterstützen, sollte statt dem obigen Befehl besser der Network-Wide-Modus für die Exklusion genutzt werden (siehe auch Erläuterungen zu Standard- versus Network-Wide-Inklusion unter [[#Hinzufügen eines neuen Z-Wave Geräts / Inklusion|Inklusion]]):
  set ZWDongle_1 removeNode nwOn
  set <ZWDongle> removeNode onNw


Danach muss das Gerät in den Exklusionsmodus (Ausschlussmodus) versetzt werden. Wie dies zu erfolgen hat, ist im Handbuch des Geräte nachzulesen.  
Danach muss das Gerät in den Exklusionsmodus (Ausschlussmodus) versetzt werden. Wie dies zu erfolgen hat, ist im Handbuch des Geräte nachzulesen.  


Abschließend wird der Exklusionsmodus am Z-Wave Gateway wieder ausgeschaltet:
Abschließend wird der Exklusionsmodus am Z-Wave Gateway wieder ausgeschaltet:
  set ZWDongle_1 removeNode off
  set <ZWDongle> removeNode off


Das Fhem-Device muss nach der Exklusion manuell durch <code>delete <name></code> gelöscht werden.
Das FHEM-Device muss nach der Exklusion manuell durch <code>delete <name></code> gelöscht werden.
 
Die durch die Exklusion frei gewordene NodeID wird nicht bei der nächsten Inklusion wiederverwendet, sondern es wird die höchste noch nicht verwendete NodeID genutzt.


=== Erneutes Hinzufügen eines bereits registrierten Z-Wave Geräts ===
=== Erneutes Hinzufügen eines bereits registrierten Z-Wave Geräts ===
Die an einem Z-Wave-Gateway bereits registrierten/inkludierten Geräte sind im Gateway selbst abgespeichert und können durch Fhem jederzeit wieder abgerufen werden. Dies kann man in folgenden Fällen sinnvoll nutzen:
Die an einem Z-Wave-Gateway bereits registrierten/inkludierten Geräte sind im Gateway selbst abgespeichert und können durch FHEM jederzeit wieder abgerufen werden. Dies kann man in folgenden Fällen sinnvoll nutzen:
* Inklusion mit einem batteriegespeisten ZWave-Gateway (bspw. Aeon Labs Z-Stick) ohne Fhem-Server-Anschluss während der Inklusion
* Inklusion mit einem batteriegespeisten ZWave-Gateway (bspw. Aeon Labs Z-Stick) ohne FHEM-Server-Anschluss während der Inklusion
* Umstieg eines ZWave-Netzwerkes von Fremdsoftware auf Fhem  
* Umstieg eines ZWave-Netzwerkes von Fremdsoftware auf FHEM  
* Vollständiger oder teilweiser Verlust der Fhem-Konfiguration
* Vollständiger oder teilweiser Verlust der FHEM-Konfiguration


Eine Node-Liste aller inkludierten Geräte des Gateways wird abgerufen durch:
Eine Node-Liste aller inkludierten Geräte des Gateways wird abgerufen durch:
  get ZWDongle_1 nodeList
  get <ZWDongle> nodeList
Es werden die verschiedenen IDs der inkludierten Geräte zurückgeliefert, wobei 1 regelmäßig der Z-Wave Stick selbst ist.
Es wird eine Liste aller im Gateway inkludierten Gerät inklusive Gateway selbst zurückgeliefert. Sofern ein Gerät bereits als FHEM-Device angelegt wurde, wird der FHEM-Device-Name in der nodeList angezeigt. Dies ist für das Gateway selbst immer der Fall. Alle noch nicht in FHEM angelegten Geräte, werden als "UNKNOWN_x" ausgegeben, wobei x die ID des betreffenden Gerätes ist.


Mit dem folgenden Befehl wird beispielsweise das bereits im Gateway inkludierte Gerät mit der ID 2 in Fhem durch autocreate definiert:
Mit dem folgenden Befehl wird beispielsweise das bereits im Gateway inkludierte Gerät mit der ID 2 (in der nodeList angezeigt als "UNKNOWN_2") in FHEM durch autocreate definiert:
  set ZWDongle_1 createNode 2
  set <ZWDongle> createNode 2


Batteriebetriebene Geräte müssen bei Absetzen des <code>createNode</code>-Befehls wach sein, damit der Befehl verarbeitet werden kann. Dies erreicht man, indem man das Gerät auf "permanent wach" stellt. Falls das Gerät diese Funktion nicht anbietet, muss man es manuell aufwecken und max. 5-10 Sekunden später den <code>createNode</code>-Befehl absetzen. Alternativ kann das batteriebetriebene Gerät durch Versand des NIF vom Gerät aus automatisch in Fhem erzeugt werden: Hierzu am Gerät die Taste zum Versand des NIF drücken und <code>autocreate</code> legt das Fhem-Device an; der Aufruf von <code>createNode</code> entfällt dann.
Batteriebetriebene Geräte müssen bei Absetzen des <code>createNode</code>-Befehls wach sein, damit der Befehl verarbeitet werden kann. Dies erreicht man, indem man das Gerät auf "permanent wach" stellt. Falls das Gerät diese Funktion nicht anbietet, muss man es manuell aufwecken und max. 2 Sekunden später den <code>createNode</code>-Befehl absetzen. Alternativ kann das batteriebetriebene Gerät durch Versand des NIF vom Gerät aus automatisch in FHEM erzeugt werden: Hierzu am Gerät die Taste zum Versand des NIF drücken und <code>autocreate</code> legt das FHEM-Device an; der Aufruf von <code>createNode</code> entfällt dann.


== Geräte-Besonderheiten ==
== Geräte-Besonderheiten ==
=== batteriebetriebene Geräte ===
=== batteriebetriebene Geräte ===
Batteriebetriebenen Geräten können hinsichtlich ihrer Empfangsbereitschaft unterschieden werden in [http://docs.smartthings.com/en/latest/device-type-developers-guide/building-z-wave-device-types/z-wave-primer.html#listening-and-sleepy-devices]
Batteriebetriebenen Geräten können hinsichtlich ihrer Empfangsbereitschaft unterschieden werden in
 
* Wakeup-Geräte
* Wakeup-Geräte
* FLIRS-Geräte
* FLIRS-Geräte


==== Wakeup-Geräte ====
==== Wakeup-Geräte ====
Wakeup-Geräte, die die Command Class WAKE_UP unterstützen, sind momentan die häufigste Art von batteriebetriebenen Z-Wave Geräten.
Wakeup-Geräte sind momentan die häufigste Art von batteriebetriebenen Z-Wave Geräten. Sie sind erkennbar an der Unterstützung der Command Class WAKE_UP.
Zur Verlängerung der Batterielaufzeit legen sich batteriebetriebene Wakeup-Geräte „schlafen“ und wachen (Wakeup) nur in konfigurierbaren Intervallen auf, um Befehle zu verarbeiten. Das Aufwachen signalisieren die Geräte durch den Versand einer Nachricht "wakeup notification". Daraufhin senden Fhem und andere assozierte Geräte ihre bis dahin gesammelten Befehle, die dann verarbeitet bzw. beantwortet werden. Anschließend gehen die batteriebetriebenen Geräte wieder in den Schlafmodus.
Zur Verlängerung der Batterielaufzeit legen sich batteriebetriebene Wakeup-Geräte „schlafen“ und wachen (Wakeup) nur in konfigurierbaren Intervallen auf, um Befehle zu verarbeiten. Das Aufwachen signalisieren die Geräte durch den Versand einer Nachricht "wakeup notification". Daraufhin senden FHEM und andere Geräte ihre bis dahin gesammelten Befehle, die dann verarbeitet bzw. beantwortet werden. Anschließend gehen die batteriebetriebenen Geräte wieder in den Schlafmodus.


Fhem teilt bei set/get-Befehlen an batteriebetriebene Geräte über einen Hinweis der Form
FHEM teilt bei set/get-Befehlen an batteriebetriebene Geräte über einen Hinweis der Form
:<code>Scheduled for sending after WAKEUP</code>
:<code>Scheduled for sending after WAKEUP</code>
mit, dass der Befehl im Send-Stack abgespeichert und bei der nächsten "wakeup notification" an das Gerät versendet wird.
::oder
:<code>Scheduled get requests for sending after WAKEUP</code>
mit, dass der Befehl im Sendstack des FHEM-Geräte-Devices abgespeichert wurde und bei der nächsten "wakeup notification" an das Gerät versendet wird. Ein Versand der Befehle im Sendstack findet grundsätzlich ausschließlich nach Erhalt der "wakeup notification"-Nachricht statt, selbst wenn das Gerät zwischendurch andere Telegramme (bspw. Bewegungsmeldung, Temperatur) an den Controller verschickt. Nur nach Versand der "wakeup notification" ist das batteriebetriebene Gerät grundsätzlich in der Lage ("wach genug"), Telegramme korrekt zu empfangen und zu verarbeiten.


Das Wakeup-Interval wird wie folgt konfiguriert:
Wie viele Nachrichten im Sendstack auf einen Versand an das Gerät warten, ist im Internal <code>cmdsPending</code> des zugehörigen FHEM-Devices ersichtlich. Welche Nachrichten (Befehle) im Sendstack warten, ist in der Ausgabe des Befehls <code>[[list]] <device></code> erkennbar: Unter der Überschrift Sendstack sind alle wartenden Nachrichten als Rohnachrichten aufgeführt. Der Sendstack wird beim Beenden von FHEM nicht gespeichert. Durch Beenden von FHEM (beispielsweise durch <code>shutdown restart</code>) geht der Sendstack der Geräte daher verloren.
 
Das Wakeup-Interval und der Empfänger der "wakeup notification" wird wie folgt konfiguriert:
  <nowiki>set <name> wakeupInterval <time> <NodeId></nowiki>
  <nowiki>set <name> wakeupInterval <time> <NodeId></nowiki>
<time> ist die Zeit in Sekunden zwischen den Intervallen und <nodeID> der gewünschte Empfänger der "wakeup notification"; in der Regel ist dies der Controller <CtrlNodeId>. Viele Geräte kommen im Auslieferungszustand mit der NodeID 255. Die "wakeup notification" wird dann als Broadcast an alle erreichbaren Geräte gesendet. Hier sollte die Konfiguration auf die NodeID des Controllers geändert werden, da dies robuster ist und zusätzlich noch Batterielaufzeit spart.
<nowiki><time></nowiki> ist die Zeit in Sekunden zwischen den Intervallen und <nodeID> der gewünschte Empfänger der "wakeup notification"; in der Regel ist dies '''immer''' der Controller <CtrlNodeId>. Viele Geräte kommen im Auslieferungszustand mit der NodeID 255. Die "wakeup notification" wird dann als Broadcast ohne Nutzung von Routing an alle erreichbaren Geräte gesendet. Hier sollte die Konfiguration auf die NodeID des Controllers geändert werden, da dadurch die "wakeup notification" geroutet wird und größere Entfernungen zwischen Gerät und Controller möglich sind. Zudem ist dies robuster und spart zusätzlich noch Batterielaufzeit. Darum setzt FHEM bei der Inklusion von WakeUp-Geräten '''automatisch''' den Befehl <code><nowiki>set <name> wakeupInterval 86400 <ControllerNodeId></nowiki></code> ab. Bei abweichenden eigenen Vorstellungen ist dies gegebenenfalls anzupassen. Bei Geräten mit V2 der Command Class WAKE_UP kann das vom Hersteller vorgesehene Standard-wakeupInterval mit <code><nowiki>get <name> wakeupIntervalCapabilities</nowiki></code> vom Gerät abgerufen werden. Die Einstellungen von wakeupInterval nach Inklusion und nach jeder Änderung immer mit der Abfrage <code><nowiki>get <name> wakeupInterval</nowiki></code> überprüfen.
 
Ein Aufwachen und Versand der "wakeup notification" von batteriebetriebenen Geräten kann für die [[#Assoziation|Assoziation]] und [[#Konfiguration|Konfiguration]] manuell erzwungen werden. Hierzu bringt man das Gerät normalerweise in den Inklusionsmodus oder findet in der Bedienungsanleitung gegebenenfalls andere Informationen. Bitte beachten, dass dann je nach Gerät nur eine geringe Entfernung von Gateway und Gerät vorhanden sein darf (direkte Erreichbarkeit). Alternativ kann für die Dauer der Assoziation und Konfiguration das Wakeup-Interval verkürzt werden (beispielsweise auf 60 Sekunden), wodurch das Routing genutzt werden kann und größere Entfernungen zwischen Gateway und Gerät überbrückt werden können. Anschließend das Wakeup-Interval wieder auf eine batterieschonenende Dauer einzustellen.


Ein Aufwachen und Versand der "wakeup notification" von batteriebetriebenen Geräten kann für die [[#Assoziation|Assoziation]] und [[#Konfiguration|Konfiguration]] manuell erzwungen werden. Hierzu bringt man das Gerät normalerweise in den Inklusionsmodus oder findet in der Bedienungsanleitung gegebenenfalls andere Informationen. Alternativ kann für die Dauer der Assoziation und Konfiguration das Wakeup-Interval verkürzt werden (beispielsweise auf 60 Sekunden); um es anschließend wieder auf eine batterieschonenende Dauer einzustellen.
Einzelne batteriebetriebene Gerät lassen sich für längere Zeit auf "wach" bzw. permanent "wach" stellen. Dann aus dem Attribut <code>classes</code> <code>WAKE_UP</code> entfernen, damit Befehle in diesem Gerätemodus von FHEM direkt verschickt werden. Nach Ausschalten des "wach"-Modus <code>WAKE_UP</code> wieder im Attribut <code>classes</code> aufnehmen.


Bei Konfigurationsänderungen an batteriebetriebenen Geräten mit <code>set <name> config...</code> sollte die korrekte Verarbeitung der Befehle immer mit dem entsprechenden <code>get <name> config...</code> überprüft werden, um eventuelle Funk-Telegrammverluste sofort festzustellen.
Bei Konfigurationsänderungen an batteriebetriebenen Geräten mit <code>set <name> config...</code> sollte die korrekte Verarbeitung der Befehle immer mit dem entsprechenden <code>get <name> config...</code> oder -falls vorhanden- mit <code>get <name> configAll</code> überprüft werden, um eventuelle Funk-Telegrammverluste sofort festzustellen.


==== FLIRS-Geräte ====
==== FLIRS-Geräte ====
Besonderer Behandlung bedürfen batteriebetriebene FLIRS (frequently listening routing slave) Geräte. Diese warten alle 1-1,5 Sek auf einen "beam". Näher beschrieben unter anderem [http://library.ademconet.com/MWT/fs2/VAM/Introductory-Guide-to-Z-Wave-Technology.PDF hier]. Zu FLIRS-Geräten liegen derzeit keine bekannten Erfahrungen mit Fhem vor.
Ein batteriebetriebene FLIRS (frequently listening routing slave) Gerät wacht in sehr kurzen Zeitabständen (250ms oder 1000ms) auf und prüft, ob ein Funksignal vorliegt. Liegt kein Funksignal vor geht das Gerät wieder in Tiefschlaf. Zum Aufwecken eines FLIRS-Gerätes ist ein dauerhaftes Funksignal -der Wakeup-Beam-, notwendig, das etwas länger als die Aufweckzeitabstände sein muss. Näher beschrieben unter anderem [http://library.ademconet.com/MWT/fs2/VAM/Introductory-Guide-to-Z-Wave-Technology.PDF hier].  
 
FLIRS-Geräte haben nicht die Command Class WAKE_UP und arbeiten deshalb nicht mit "wakeup notification". Aus Sicht des FHEM-Nutzers sind die bekannten FLIRS-Geräte (Sirenen von Vision und Popp) nicht anders zu bedienen/einzurichten als netzgespeiste Geräte. Wakeup-Beam und andere Besonderheiten werden unsichtbar für den Nutzer automatisch abgewickelt.


=== Aeon Labs / Aeotec ===
=== Aeon Labs / Aeotec ===
Ausführliche Handbücher und technische Informationen auf https://aeotec.freshdesk.com/support/home
==== Multi Sensor 5 ====
==== Multi Sensor 5 ====
* aktuellste Firmware installieren
* aktuellste Firmware installieren
Zeile 225: Zeile 300:
* bei USB-Anschluss aus Attribut <code>classes</code> <code>WAKE_UP</code> entfernen
* bei USB-Anschluss aus Attribut <code>classes</code> <code>WAKE_UP</code> entfernen
* Parameter 101 auf 225 (oder 224 bei USB-Anschluss) setzen mit <code>set <name> configGroup1Reports 225</code> oder <code>set <name> configLong 101 225</code>, um Batteriezustand (nicht bei 224), Temperatur, Feuchte und Helligkeit regelmäßig zu erhalten. Das Sende-Intervall wird duch <code><nowiki>set <name> configGroup1Interval <time/s></nowiki></code> festgelegt (Standard 720 Sek).
* Parameter 101 auf 225 (oder 224 bei USB-Anschluss) setzen mit <code>set <name> configGroup1Reports 225</code> oder <code>set <name> configLong 101 225</code>, um Batteriezustand (nicht bei 224), Temperatur, Feuchte und Helligkeit regelmäßig zu erhalten. Das Sende-Intervall wird duch <code><nowiki>set <name> configGroup1Interval <time/s></nowiki></code> festgelegt (Standard 720 Sek).
* [http://www.pepper1.net/zwavedb/device/407 Paramterübersicht pepper-Datenbank]
* [http://devel.pepper1.net/zwavedb/device/407 Paramterübersicht pepper-Datenbank]
siehe {{Link2Forum|Topic=34505|Message=268913}}
siehe {{Link2Forum|Topic=34505|Message=268913}}


Zeile 231: Zeile 306:
siehe {{Link2Forum|Topic=40393}}
siehe {{Link2Forum|Topic=40393}}
* arbeitet bei USB-Anschluß als Router
* arbeitet bei USB-Anschluß als Router
* bei USB-Anschluss aus Attribut <code>classes</code> <code>WAKE_UP</code> entfernen
* die <code>configGroupxInterval</code> und <code>configxxxReportingThreshold</code> Einstellungen wirken nur bei USB-Anschluss, im reinen Batteriebetrieb werden die Sensordaten nur bei einem <code>wakeup</code> übertragen


==== Aeotec LED Bulb ZW098-C55 ====
==== Aeotec LED Bulb ZW098-C55 ====
Zeile 237: Zeile 314:
=== Danfoss ===
=== Danfoss ===
==== DAN_LC-13 Heizungsthermostat LC-13 (014G0013) ====
==== DAN_LC-13 Heizungsthermostat LC-13 (014G0013) ====
Das Danfoss Heizungsthermostat LC-13 muss derzeit zur korrekten Funktion mit Fhem regelmäßig mit folgendem <code>at</code> abgefragt werden ({{Link2Forum|Topic=32145|Message=260795}}):
Das Danfoss Heizungsthermostat LC-13 muss derzeit zur korrekten Funktion mit FHEM regelmäßig mit folgendem <code>at</code> abgefragt werden ({{Link2Forum|Topic=32145|Message=260795}}):
  define Atdanfoss at +*00:30 get <name> battery
  define Atdanfoss at +*00:30 get <name> battery
Auf dem Markt sind mehrere Varianten des Thermostates LC-13 erhältlich. Darum beim Kauf unbedingt auf die genaue Bezeichnung LC-13 (014G0013) achten ({{Link2Forum|Topic=38041|Message=303146}}).  
Auf dem Markt sind mehrere Varianten des Thermostates LC-13 erhältlich. Darum beim Kauf unbedingt auf die genaue Bezeichnung LC-13 (014G0013) achten ({{Link2Forum|Topic=38041|Message=303146}}).  
=== devolo ===
Ausführliche Handbücher auf http://products.z-wavealliance.org
==== MT02648 Tür-/Fenster Kontakt 3in1 ====
siehe {{Link2Forum|Topic=41337}}


=== DüWI ===
=== DüWI ===
Geräte von DÜWI liefern bei örtlicher Betätigung kein automatisches Funk-Signal über die Statusänderung. Das liese sich nur durch eine regelmäßige Statusabfrage durch Fhem (beispielsweise <code>define Status_Abfrage at +*00:03:00 get <name> swmStatus</code>) beheben.
Geräte von DÜWI liefern bei örtlicher Betätigung kein automatisches Funk-Signal über die Statusänderung. Das liese sich nur durch eine regelmäßige Statusabfrage durch FHEM (beispielsweise <code>define Status_Abfrage at +*00:03:00 get <name> swmStatus</code>) beheben.
Einige Produkte von [http://zwave.me Z-Wave.Me] basieren auf DÜWI-Geräten. Diese Z-Wave.Me Produkte haben jedoch eine erweiterte Firmware, welche die genannte und weitere Firmware-Schwächen der Original-Produkte von DÜWI behebt.
Einige Produkte von [http://zwave.me Z-Wave.Me] basieren auf DÜWI-Geräten. Diese Z-Wave.Me Produkte haben jedoch eine erweiterte Firmware, welche die genannte und weitere Firmware-Schwächen der Original-Produkte von DÜWI behebt.
=== Everspring ===
==== AN145 Sockelmodul E27 ====
Statusabfrage ohne permanente Abfrage: {{Link2Forum|Topic=48864|Message=405545|Beitrag}}


=== Fibaro ===
=== Fibaro ===
Bei vielen bisher erschienenen Devices wird die Association Group 3 für die Übermittlung von Sensor Werten verwendet.
Association Group für Übermittlung von Statusinformationen an den Controller:
set <name> associationAdd 3 <CtrlNodeId>
* "alte" ZWave-Geräte (kein ZWave-Plus): häufig Association Group 3
: <code><nowiki>set <name> associationAdd 3 <CtrlNodeId></nowiki></code>
: Bei diesen Geräten empfiehlt es sich zur Funklastreduzierung und Problemminimierung zu prüfen, ob die von FHEM automatisch vorgenommene Assoziation des Controllers mit der Association Group 1 gelöscht werden kann (<code><nowiki>set <name> associationDel 1 <CtrlNodeId></nowiki></code>). Nahezu immer werden in Association Group 1 die gleichen Infos, nur mit einer anderen Command Class, wie in der Association Group 3 an den Controller übermittelt.
* ZWave Plus-Geräte: Association Group 1 ("lifeline")


==== FGSS-001 Rauchmelder ====
==== FGSS-001 / FGSD-002 Rauchmelder ====
Dieser Rauchmelder scheint einen falschen Batterie-Level (0%) zu senden, wenn er außerhalb des wakeup intervals abgefragt wird.
* nicht untereinander vernetzbar
* keine Alarmauslösung/Sirenenfunktion durch ZWave-Zentralen


Workaround: Den Batterie-Level nicht direkt via <code>get</code> anfordern, sondern per <code>notify</code> auf den wakeup Report reagieren.
==== FGS-222 Relais Unterputzeinsatz ====
Bei der Inklusion werden von FHEM 3 Devices angelegt:
* Hauptdevice (Steuerung und automatischer Status für Kanal 1 und kanalübergreifende Funktionen)
* Device für Endpoint 1 (Steuerung Kanal 1)
* Device für Endpoint 2 (Steuerung und automatischer Status von Kanal 2)
Die Firmware des FGS-222 übermittelt den Status für Kanal 1 automatisch immer ausschließlich an das Hauptdevice. Die Steuerung von Kanal 1 kann hingegen sowohl über das Hauptdevice als auch über das Device für Endpoint 1 erfolgen. Das Device für Endpoint 1 ist somit nicht zwingend erforderlich und kann grundsätzlich gelöscht oder in den room hidden verschoben werden.


(Dieser Workaround sollte in aktuellen Fhem-Versionen durch eine Änderung in der Behandlung von Wakeup-Geräten nicht mehr notwendig sein. Mangels Rückmeldung von Besitzern des FGSS-001 ist dies aber noch nicht bestätigt.)
Details: {{Link2Forum|Topic=50176}}
 
Hinweis zum Reset: {{Link2Forum|Topic=55190|Message=469393}}


==== FGK-101 Tür/Fensterkontakt ====
==== FGK-101 Tür/Fensterkontakt ====
* Attribut <code>classes</code> um <code>BASIC</code> ergänzen (ab [[version|Modulversion]] 8824/25.6.2015 wird das automatisch bei der Inklusion durchgeführt)
* Der Tür/Fensterkontakt sendet Zustandsänderungen als Report der Class BASIC (ff oder 00). Anpassung auf open/closed ist mit dem Attribut <code>stateFormat</code> möglich.
* Der Status (open / closed) über die Class SENSOR_BINARY wird nur nach explizitem <code>get</code> gemeldet.
* Besonderheiten bei Anschluss eines Temperatursensors: {{Link2Forum|Topic=38012}}
* Besonderheiten bei Anschluss eines Temperatursensors: {{Link2Forum|Topic=38012}}


Zeile 267: Zeile 362:


=== Merten ===
=== Merten ===
Laut {{Link2Forum|Topic=38133}} müssen bei einigen Merten-Geräten, die mit Fremdsoftware inkludiert wurden, gegebenenfalls die Geräte wieder exkludiert und dann erneut mit Fhem inkludiert werden, damit Assoziationen mit Fhem gesetzt werden können.
Laut {{Link2Forum|Topic=38133}} müssen bei einigen Merten-Geräten, die mit Fremdsoftware inkludiert wurden, gegebenenfalls die Geräte wieder exkludiert und dann erneut mit FHEM inkludiert werden, damit Assoziationen mit FHEM gesetzt werden können.


=== Philio ===
=== Philio ===
Zeile 276: Zeile 371:
==== POPE004001 Z-Wave Rauchmelder mit Innensirene ====
==== POPE004001 Z-Wave Rauchmelder mit Innensirene ====
siehe {{Link2Forum|Topic=39856}}
siehe {{Link2Forum|Topic=39856}}
==== POPE005107 Z-Wave Außensirene ====
siehe {{Link2Forum|Topic=42736}}<br>
Alte Firmwareversionen haben einen Bug bei der Übermittlung von negativen Temperaturen. Eine Lösungsvariante über ein <code>userReadings</code> findet sich auch im verlinkten Thema.
==== POPE009006 Z-Wave Wall Plug Switch ====
siehe {{Link2Forum|Topic=40771}}
==== POPE009402 10Year Smoke Detector ====
Die erste Firmwareversion hat eine fehlerhafte modelID.  Diese Rauchmelder wird dadurch fälschlich als [[Z-Wave#POPE005107_Z-Wave_Au.C3.9Fensirene|Popp Aussensirene]] in FHEM angezeigt. Neuere Geräte werden laut Popp mit der korrekten modelID ausgeliefert.


=== Z-Wave.Me ===
=== Z-Wave.Me ===
Zeile 281: Zeile 383:
siehe {{Link2Forum|Topic=35513}}<BR>
siehe {{Link2Forum|Topic=35513}}<BR>
Das Forenthema enthält eine detaillierte Beschreibung der Nutzung der Class MULTI_CHANNEL_ASSOCIATION.
Das Forenthema enthält eine detaillierte Beschreibung der Nutzung der Class MULTI_CHANNEL_ASSOCIATION.
== Geräte-Vergleich ==
=== Doppel-Relais ===
{| class="wikitable"
|-
! Eigenschaft !! FIBARO Double Switch 2-FGS-223 !! Qubino Flush 2 relays  !! Philio-PAN04 1
|-
| Funktion || Doppel-Relais || Doppel-Relais || Doppel-Relais
|-
| Standby-Leistung || ca. 0.4W || ca. 0.4W || ca. 0.5W
|-
| Reaktion beim Schalten am Tastereingang || schnell, kaum merkliche Verzögerung ||  schnell, kaum merkliche Verzögerung || langsam, unangenehm langes drücken des Tasters nötig >1 Sekunde
|-
| Geräte in FHEM || 3 <br> x Hauptgerät <br> x.01 Relais 1 <br> x.02 Relais 2 || 3  <br> x Hauptgerät <br> x.01 Relais 1 <br> x.02 Relais 2 || 4  <br> x Hauptgerät <br> x.01 Relais 1 <br> x.02 Relais 2 <br> x.03 Summengerät (ähnlich Hauptgerät, überflüssig)
|-
| Zustand Hauptgerät || Oder-Verknüpfung der beiden Relais || Oder-Verknüpfung der beiden Relais || Oder-Verknüpfung der beiden Relais
|-
| Statuswechsel Report vom Gerät zum FHEM || ca. 1 Sekunde || ca. 3 Sekunden || ca. 3-4 Sekunden
|-
| Empfänger des Status Reports || Hauptgerät und Untergeräte || Hauptgerät und Untergeräte  || Nur Hauptgerät <br>Aktualisierung der Untergeräte nur bei aktiver Abfrage
|-
| Leistungsmessung || Separat für Untergeräte || Separat für Untergeräte || Nur Summe
|-
| Sicherung nötig / Strom || ja, 2x 6.5A, Summe max 10A || ja, max 2x 4A  || nein, 2x 6.5A
|}
Beim Qubino Flush 2 relays muss eine MULTI_CHANNEL_ASSOCIATION mit dem Controller (Endpoint root) statt einer "normalen" Assoziation gesetzt werden, damit die Status der Untergeräte einzeln signalisert werden:
set associationDel 1 <controllerNodeId>
set <device> mcaAdd 1 0 <controllerNodeId> 0
Bei einem FHEM-Updatestand ab 20.09.2019 erfolgt diese Einstellung automatisch.


== Links ==
== Links ==
* Grundlageninformation "Z-Wave-Haupt-Anleitung": [http://manuals.zwaveeurope.com/Generic_Z_de.pdf Wie errichte und betreibe ich ein Z-Wave basiertes Funknetz]
=== Allgemein ===
* herstellerübergreifende Datenbank mit Bedienungsanleitungen zu Z-Wave-Geräten: http://www.zwave.de/handbuecher/ oder http://manuals.zwaveeurope.com
* Grundlageninformation "Z-Wave-Haupt-Anleitung": [http://www.zwave.de/z-wave-funknetz-einrichten-und-betreiben/ Wie errichte und betreibe ich ein Z-Wave basiertes Funknetz]{{Randnotiz|Links teilweise nicht mehr aktuell|RNText=zwave.de existiert nicht mehr. Es erfolgt ein Forward auf zwave.eu/de. Die hier angegebenen Links darauf werden aber nicht abgebildet und liefern einen 404. Ich ([[Benutzer Diskussion:AlanBlack]]) suche noch nach den korrekten Seiten.|RNTyp=Fehl}}
* herstellerübergreifende Datenbank mit technischen Informationen zu Z-Wave-Geräten (Z-Wave Device Library): http://www.pepper1.net/zwavedb/
* [http://www.zwave.de/buch-z-wave-grundlagen/ Buch] "Z-Wave: Die Funktechnologie für das Smart Home" von Dr. Christian Paetz (Paetz "is the primary European representative for the Z-Wave Alliance" [http://z-wavealliance.org/global-contacts/])
* Z-Wave-Produktdatenbank mit Angabe zur Zertifizierung (Z-Wave oder [http://z-wavealliance.org/z-wave_plus_certification Z-Wave Plus]): http://products.z-wavealliance.org
* Z-Wave-Produktdatenbank mit Angabe zur Zertifizierung, Handbüchern und weiteren Detailinfos (Z-Wave oder [http://z-wavealliance.org/z-wave_plus_certification Z-Wave Plus]): http://products.z-wavealliance.org (englisch)
* herstellerübergreifende Datenbank mit Bedienungsanleitungen zu Z-Wave-Geräten: http://www.zwave.de/handbuecher/ oder http://manuals.zwaveeurope.com (mehrsprachig)
* herstellerübergreifende Datenbank mit technischen Informationen zu Z-Wave-Geräten (Z-Wave Device Library): http://devel.pepper1.net/zwavedb/ (englisch; wird derzeit nicht mehr aktualisiert)
* informative Webseiten zu Z-Wave:
* informative Webseiten zu Z-Wave:
** [http://www.z-wavealliance.org/ http://www.z-wavealliance.org/], englisch
** http://www.z-wavealliance.org/ (englisch)
** [http://www.zwaveeurope.com/ http://www.zwaveeurope.com/], englisch
** http://www.zwaveeurope.com/ (englisch)
** [http://www.zwave.de/ http://www.zwave.de/], deutsch
** http://www.zwave.de/ (deutsch)
** [http://library.ademconet.com/MWT/fs2/VAM/Introductory-Guide-to-Z-Wave-Technology.PDF Introductory Guide to Z-Wave-Technology von Honeywell], englisch
** [http://library.ademconet.com/MWT/fs2/VAM/Introductory-Guide-to-Z-Wave-Technology.PDF Introductory Guide to Z-Wave-Technology von Honeywell] (englisch; nicht auf aktuellem Stand)
* Hilfen zur Einbindung von Command Classes in Fhem
 
** [https://github.com/yepher/RaZBerry Infos zu Command Classes (ausführlich; insbesondere im Verzeichnis "docs"), RaZBerry und Z-Wave allgemein], englisch
=== Informationsquellen zur Einbindung von Command Classes ===
** [http://220.135.186.178/zwave/example/ Übersicht von Command Classes und deren Rückgabewerten mit Unterscheidung der Class-Versionen], englisch
Offizielle und ausführliche Informationen von Sigma Designs (veröffentlicht am 31.08.2016):
** Code von http://www.openzwave.org (https://github.com/OpenZWave/open-zwave) und http://www.openhab.org (Z-Wave binding: https://github.com/cdjackson/openhab)
* [http://z-wave.sigmadesigns.com/design-z-wave/z-wave-public-specification/ Z-Wave Public Specification]
 
Weitere Informationen (seit Veröffentlichung der Z-Wave Spezifikationen am 31.08.2016 geringe Relevanz)
* [https://github.com/yepher/RaZBerry Infos zu Command Classes (ausführlich; insbesondere im Verzeichnis "docs"), RaZBerry und Z-Wave allgemein], englisch
* [http://220.135.186.178/zwave/example/ Übersicht von Command Classes und deren Rückgabewerten mit Unterscheidung der Class-Versionen], englisch
* Code von http://www.openzwave.org (https://github.com/OpenZWave/open-zwave) und http://www.openhab.org (Z-Wave binding: https://github.com/cdjackson/openhab)
* eine Java-API-Beschreibung mit Hinweisen zu Unterschieden von Class-Versionen: http://dz.prosyst.com/pdoc/mBS_SH_SDK_8.1/modules/zwave/api/driver/index.html


== FAQ ==
== FAQ ==
=== Welche Schritte sind für die Einbindung von ZWave-Geräten in Fhem mindestens durchzuführen? ===
=== Welche Infos sollten Anfragen im ZWave-Forum enthalten? ===
* Anfragen bitte nur zur aktuellsten FHEM-Version: Befehl <code>update</code> ergibt Ausgabe "nothing to do..."
* detaillierte Beschreibung des Problems
* beteiligte Komponenten (genaue Bezeichnung und evtl. Link auf Hersteller-Dokumentation)
* list des jeweiligen FHEM-Devices (Ausgabe von <code>list <device></code>)
::Bitte vor Aufruf des list-Befehls -wenn vorhanden/möglich- folgende Befehle ausführen und Ergebnis abwarten:
::*<code>get <device> associationAll</code>
::*<code>get <device> configAll</code>
::*<code>get <device> versionClassAll</code>
::*<code>get <device> mcaAll</code>
::*<code>get <device> wakeupInterval</code> (nur bei batteriebetriebenen Geräten)
* passender Ausschnitt aus dem Logfile (siehe Link im FHEM-Menü links) generiert mit den gesetzten Attributen
::*<code>attr <ZWDongle> verbose 5</code> und
::*<code>attr global mseclog 1</code>
 
=== Welche Schritte sind für die Einbindung von ZWave-Geräten in FHEM mindestens durchzuführen? ===
Voraussetzung: ZWave-Gateway ist erfolgreich eingebunden!
Voraussetzung: ZWave-Gateway ist erfolgreich eingebunden!
# [[#Hinzufügen eines neuen Z-Wave Geräts / Inklusion|Inklusion]] des Gerätes
# [[#Hinzufügen eines neuen Z-Wave Geräts / Inklusion|Inklusion]] des Gerätes
# [[#Assoziation|Assoziation]] der Assoziationsgruppe(n) des Gerätes mit dem Gateway
# [[#Assoziation|Assoziation]] der Assoziationsgruppe(n) des Gerätes mit dem Gateway
# [[#Konfiguration|Konfiguration]] des Gerätes
# [[#Konfiguration|Konfiguration]] des Gerätes
=== Warum bleibt der Status (STATE) des neu inkludierten Gerätes dauerhaft auf "associationAdd <associationGroup> <CtrlNodeId>" stehen? ===
FHEM setzt das Reading "state", das den STATE bestimmt, nicht bei allen ZWave-Devices mit vordefinierten Standardwerten. Daher bleibt der bei der Inklusion automatisch abgesetzte "associationAdd"-Befehl unter Umständen im STATE stehen, bis der Anwender den STATE über die Vergabe des Attributes <code>{{Link2CmdRef|Anker=stateFormat|Label=stateFormat}}</code> manuell an seine Bedürfnisse angepasst hat.
(weitergehende Info zum state/STATE/stateFormat: [[DevelopmentState]])


=== Wie können bei mehrkanaligen Aktoren die zusätzlichen Kanäle (>1) angesprochen werden? ===
=== Wie können bei mehrkanaligen Aktoren die zusätzlichen Kanäle (>1) angesprochen werden? ===
* Bei der [[#Hinzufügen eines neuen Z-Wave Geräts / Inklusion|Inklusion]] des Gerätes wird nur der 1. Kanal angelegt
* Bei der [[#Hinzufügen eines neuen Z-Wave Geräts / Inklusion|Inklusion]] des Gerätes wird das Hauptdevice mit dem Namen <code><nowiki>ZWave_<Geräteklasse laut NIF des Gerätes>_<NodeID></nowiki></code> und die Devices für alle Kanäle (Endpoints) nach dem Namensschema <code><nowiki>ZWave_<Geräteklasse laut NIF des Gerätes>_<NodeID>.<EndpointNr></nowiki></code> automatisch angelegt. Jedes dieser FHEM-Devices spricht regelmäßig einen bestimmten Kanal des Gerätes an; einige Geräte sprechen mit dem Hauptdevice jedoch das gesamte Gerät mit allen Kanälen an (Bedienungsanleitung beachten).
* zusätzliche Kanäle (in Z-Wave Endpoints genannt) werden mit Hilfe der Befehle <code>get <device> mcEndpoints</code> und <code>get <device> mcCapability <chid></code> aus der Class MULTI_CHANNEL ermittelt/angelegt (Details und Beispiel siehe [http://fhem.de/commandref.html#ZWaveget commandref])
* Manuell werden Devices für zusätzliche Kanäle mit Hilfe der Befehle <code>get <device> mcEndpoints</code> und <code>get <device> mcCapability <chid></code> aus der Class MULTI_CHANNEL ermittelt bzw. einzeln über autocreate angelegt (Details und Beispiel siehe {{Link2CmdRef|Anker=ZWaveget}}). Mit dem Befehl <code>set <device> mcCreateAll</code> werden automatisch alle Kanäle des Gerätes durch autocreate als eigene Devices in FHEM angelegt.
 
=== Wie kann man die SDK-Version eines Gerätes herausfinden? ===
Mit FHEM alleine kann eine [[#Grobermittlung|Grobermittlung]] der SDK-Version vorgenommen werden, die aber für einige Zwecke bereits ausreichend ist. Soll eine [[#Detailermittlung|Detailermittlung]] der genauen SDK-Version erfolgen, dann müssen die mit FHEM ermittelten Werte anhand externer Quellen übersetzt werden.
==== Grobermittlung ====
Der Befehl <code><nowiki>get <ZWDongle> nodeInfo <dezimale nodeId></nowiki></code> liefert das Reading <code><nowiki>nodeInfo_<dezimale nodeId></nowiki></code> zurück.
Die Angabe im Reading hinter <code>ProtocolVers:</code> lässt grobe Rückschlüsse zu. Mögliche (bekannte) Werte:
* <code>2</code> -> bspw. keine Explorer Frames, keine SUC-Unterstützung (veraltet, keine bekannten Geräte mehr im Handel)
* <code>SDK5.0x+4.2x</code> -> bspw. keine Explorer Frames, teilweise SUC-Unterstützung
* <code>SDK4.5x+6.0x</code> -> bspw. Explorer Frames- und SUC-Unterstützung (Reading-Wert wird auch bei SDK 6.5x = Z-Wave Plus angezeigt)
==== Detailermittlung ====
Durch den Befehl <code><nowiki>get <name> version</nowiki></code> kann man die ZWave-Protokoll-Version von Geräten und Controller abfragen. Mit Unterstützung von Übersetzungstabellen
* http://wiki.micasaverde.com/index.php/ZWave_Protocol_Version
* Suche nach sdkids.xml in einer Suchmaschine
kann aus der Protokoll-Version das genutzte SDK festgestellt werden.
 
Beispielsweis entspricht das Reading eines Gerätes "Lib 6 '''Prot 2.64''' App 1.6" dem SDK 5.02 Patch 2 oder eines Controller "Z-Wave '''3.41''' STATIC_CONTROLLER" dem SDK 6.02.00.
HINWEIS: Bei der Vergabe der Protokoll-Version und zugehörigem SDK gibt es keine erkennbare Logik: Eine höhere Protokoll-Version steht nicht notwendig für eine höheres SDK.
 
=== Wie kann eine verschlüsselte Kommunikation unter Nutzung der Command Class SECURITY eingerichtet werden? ===
{{Randnotiz|RNText=FHEM unterstützt derzeit ausschließlich SECURITY 1 und nicht das mit dem SDK 6.7 neu eingeführte SECURITY 2 (S2). Soweit bekannt, sind S2-Geräte rückwärtskompatibel zu SECURITY 1.}}
Die verschlüsselte Kommunikation zwischen Controller und Endgerät setzt eine secure-Inklusion voraus. Bereits mit der Inklusion wird entschieden, ob die Kommunikation von Controller und Endgerät dauerhaft verschlüsselt oder unverschlüsselt erfolgt. Ist ein Gerät bereits normal inkludiert und entscheidet man sich nachträglich für eine verschlüsselte Kommunikation, so ist das nur möglich, indem das Gerät exkludiert und dann wieder secure inkludiert wird.
 
Ob die Verschlüsselung bei einem Gerät mit Unterstützung der Command Class SECURITY genutzt werden soll, sollte genau überlegt werden. Die Verschlüsselung führt zu einem deutlich größeren Funkverkehr zur Ausführung eines Befehls und teilweise auch zu spürbaren Latenzen.
 
Vorarbeiten:
* Das Perl-Modul Crypt-Rijndael muss installiert sein.
* Das Attribut <code>networkKey</code> muss mit einem 32-Zeichen langen Hexzahl beim ZWDongle angelegt werden. Dieser Schlüssel sollte nicht veröffentlicht werden und auch zusätzlich separat (bspw. auf Papier) festgehalten werden. Bei Verlust des Attributes und Schlüssels ist eine Kommunikation nur nach erneuter Inklusion möglich.
 
Ablauf der secure-Inklusion:
* Controller in den Modus zur secure-Inklusion schalten:
: <code>set <ZWDongle> addNode onSec</code> für die Standard-secure-Inklusion
: oder alternativ
: <code>set <ZWDongle> addNode onNwSec</code> für die Nework-Wide-secure-Inklusion
* Gerät gemäß Handbuch in den Modus zur secure-Inklusion bringen (teilweise ist jeweils für secure- und normale Inklusion ein anderes Vorgehen notwendig!)
* Das Gerät sollte jetzt automatisch erkannt und das FHEM-Device durch <code>autocreate</code> angelegt werden. Die secure-inkludierten Geräte haben ein zusätzliches Attribut <code>secure_classes</code> in dem die Command Classes deren Kommunikation verschlüsselt abläuft aufgelistet sind. Nicht in diesem Attribut, aber in <code>classes</code> aufgeführte Command Classes wickeln die Kommunikation weiterhin unverschlüsslt ab.
* Inklusionsmodus des Controllers ausschalten:
: <code>set <ZWDongle> addnode off</code>
* Das Vorgehen in FHEM unterscheidet sich von nun an nicht von normal (unverschlüsselt) inkludierten Geräten. Die Verschlüsselung läuft für den Anwender transparent ab. Darum anschließend [[#Assoziation|Assoziation]] und [[#Konfiguration|Konfiguration]] vornehmen.


=== Wie kann man ohne Exklusion Nodes des Controllers löschen? ===
=== Wie kann man ohne Exklusion Nodes des Controllers löschen? ===
HINWEIS: Geräte sollten grundsätzlich immer über eine Exklusion aus der Nodelist des Controllers gelöscht werden.  
HINWEIS: Geräte sollten grundsätzlich immer über eine Exklusion aus der Nodelist des Controllers gelöscht werden. Das nachfolgend geschilderte Vorgehen ist nur in Sonderfällen (bspw. Gerätedefekt, gebraucht gekauftes Gateway) anzuwenden.


In Sonderfällen (Gerätedefekt, gebrauchtes Gateway) können Nodes mit folgendem Vorgehen manuell gelöscht werden: {{Link2Forum|Topic=32823|Message=292626}}
Nicht mehr zu erreichende/reagierende Nodes (Geräte) können manuell mit dem Befehl <code>removeFailedNode</code> gelöscht werden. Dazu muss sich der betroffene Node auf der FailedNodeList des Controllers befinden. Auf die FailedNodeList kommen netzbetriebene Geräte automatisch, wenn sie vom Controller nicht mehr per Funk erreicht werden. Batteriebetriebene Geräte müssen manuell auf die FailedNodelist gesetzt werden, da der Controller nicht feststellen kann, ob sie nur langfristig "schlafen".


=== Welche Funktion haben die XML-Config-Dateien in Fhem? ===
Der Befehl <code>removeFailedNode</code> löscht nur Nodes auf der FailedNodeList, die erst vor Kurzem nicht erreicht werden konnten. Darum muss sowohl das manuelle Verschieben von batteriebetriebenen als auch das Nicht-Erreichen der netzbetriebenen Geräte erst Kurz vor Aufruf des <code>removeFailedNode</code>-Befehls erfolgt sein.
In den XML-Config-Dateien sind Informationen zu einzelnen ZWave-Geräten enthalten, die der Erleichterung der Gerätenutzung und -einbindung in Fhem dienen. Dies sind unter anderem Erläuterungen zu den Parameternummer/-werten, Assoziationsgruppen und Besonderheiten eines Gerätes. Ob eine zum Zwave-Gerät passende XML-Config Datei existiert, wird im Rahmen der Inklusion oder durch manuellen Aufruf des Befehls <code>get <name> model</code> ermittelt. Wird eine passende XML-Config-Datei gefunden, wird sie automatisch in Fhem eingebunden. Das Reading <code>modelConfig</code> enthält dann den zugehörigen XML-Config-Dateinamen. Stehen keine XML-Config-Informationen bereit, enthält das Reading <code>modelConfig</code> den Wert "unknown". Die Funktionsfähigkeit von Fhem mit ZWave-Geräten ist auch bei fehlender XML-Config-Datei gegeben. Es gibt dadurch keine funktionalen Einschränkungen in Fhem; es entfallen "nur" Erleichterungen und es sind unter Umständen mehr manuelle Schritte bei der Gerätenutzung/-einbindung notwendig.
 
Vorgehensweise für den Node <NodeId>:
# An den betroffenen Node eine Telegramm mit <code><nowiki>set <ZWDongle> sendNIF <NodeId></nowiki></code> verschicken, um ihn auf FailedNodeList zu verschieben bzw. Zeitstempel zu aktualisieren.
# Abfragen, ob der Node auf der FailedNodeList steht: <code><nowiki>get <ZWDongle> isFailedNode <NodeId></nowiki></code>. Wenn der Rückgabewert der Abfrage "yes" ist, steht der Node korrekt auf der FailedNodeList und kann mit <code>removeFailedNode</code> gelöscht werden.
# Befehl zum Löschen des Nodes absetzen: <code><nowiki>set <ZWDongle> removeFailedNode <NodeId></nowiki></code>. Der Befehl testet vor dem Löschen noch einmal, dass der Node nicht erreicht werden kann und entfernt erst dann den Node.
# Prüfen, der Ergebnisse des <code>removeFailedNode</code>-Befehls im Log oder [[Event monitor]]. Die verschiedenen Ergebnisse werden durch die in der {{Link2CmdRef}} dokumentierten Events signalisiert. Tritt das Ergebnis "failedNodeRemoveProcessBusy" mehrfach hintereinander auf, muss das ZWDongle kurz stromlos gemacht werden.
# Prüfen, ob der Node nicht mehr auf der Nodelist des Controllers ist: <code><nowiki>get <ZWDongle> nodeList</nowiki></code>
 
siehe auch {{Link2Forum|Topic=32823|Message=292626}}
 
=== Wie ist der einfachste Weg ein (defektes) Gerät durch ein gleiches Ersatzgerät auszutauschen? ===
Tauscht man ein defektes Gerät durch ein gleiches Ersatzgerät und inkludiert das Ersatzgerät per <code>addNode</code>, so erhält das Ersatzgerät eine neue NodeId. Soll das Ersatzgerät die gleiche NodeId wie das alte Gerät erhalten, so muss statt <code>addNode</code> der Befehl <code>replaceFailedNode</code> zur Inklusion des Ersatzgerätes (=gleiches Modell) verwendet werden.
 
Vorgehensweise für den Node <NodeId>:
# sofern das alte Gerät noch ansprechbar ist, die Konfiguration und Assoziationen abfragen, damit man die Werte im Ersatzgerät einfach wieder setzen kann:
## <code><nowiki>get <device> configAll</nowiki></code>
## <code><nowiki>get <device> associationAll</nowiki></code>
# defektes Gerät aus- und neues einbauen
# Befehl <code><nowiki>set <ZWDongle> sendNIF <NodeId></nowiki></code> absetzen, damit das Dongle die NodeId auf die FailedNodeList setzt.
# Abfragen, ob der Node auf der FailedNodeList steht: <code><nowiki>get <ZWDongle> isFailedNode <NodeId></nowiki></code>. Wenn der Rückgabewert der Abfrage "yes" ist, steht der Node korrekt auf der FailedNodeList und das Ersatzgerät kann mit <code>replaceFailedNode</code> inkludiert werden.
# <code><nowiki>set <zwdongle> replaceFailedNode <NodeId></nowiki></code> für die NodeId des defekten Gerätes aufrufen und das Ersatzgerät in den Inklusionsmodus bringen
# Korrekte Inklusion prüfen und beim alten Aktor ausgelesene Werte beim neuen Aktor wieder setzen.
 
=== Bei einer Inklusion wird eine durch Exklusion/removeFailedNode frei gewordenen NodeId nicht mehr vergeben. Ist das korrekt? ===
Ja, das ist richtig.
 
Bei der Inklusion über addNode vergibt der Controller die höchste bisher noch nie verwendete NodeID. Durch Exklusion oder removeFailedNode frei gewordene NodeIDs werden hierbei zunächst nicht erneut vergeben. Diese frei gewordenen NodeIds werden bei Inklusionen in aufsteigender Reihenfolge erst wieder vergeben, nachdem die höchste verfügbare NodeId (232?) inkludiert wurde. Sie sind somit grundsätzlich nicht verloren.
 
=== Welche Funktion haben die XML-Config-Dateien in FHEM? ===
In den XML-Config-Dateien sind Informationen zu einzelnen ZWave-Geräten enthalten, die der Erleichterung der Gerätenutzung und -einbindung in FHEM dienen. Dies sind unter anderem Erläuterungen zu den Parameternummer/-werten, Assoziationsgruppen und Besonderheiten eines Gerätes. Ob eine zum Zwave-Gerät passende XML-Config Datei existiert, wird im Rahmen der Inklusion oder durch manuellen Aufruf des Befehls <code>get <name> model</code> ermittelt. Wird eine passende XML-Config-Datei gefunden, wird sie automatisch in FHEM eingebunden. Das Reading <code>modelConfig</code> enthält dann den zugehörigen XML-Config-Dateinamen. Stehen keine XML-Config-Informationen bereit, enthält das Reading <code>modelConfig</code> den Wert "unknown". Die Funktionsfähigkeit von FHEM mit ZWave-Geräten ist auch bei fehlender XML-Config-Datei gegeben. Es gibt dadurch keine funktionalen Einschränkungen in FHEM; es entfallen "nur" Erleichterungen und es sind unter Umständen mehr manuelle Schritte bei der Gerätenutzung/-einbindung notwendig.


Erleichterungen bei vorhandener XML-Config für ein ZWave-Gerät:
Erleichterungen bei vorhandener XML-Config für ein ZWave-Gerät:
Zeile 321: Zeile 550:
** vom NIF nicht gemeldete, aber vom Gerät unterstützte Classes, werden im Attribut <code>classes</code> ergänzt
** vom NIF nicht gemeldete, aber vom Gerät unterstützte Classes, werden im Attribut <code>classes</code> ergänzt
* Bei der Konfiguration:
* Bei der Konfiguration:
** die Parameternummern stehen als configXY-Befehle zur Verfügung und werden mit Hilfetexten -auch zu den Parmaeterwerten- in der Detailansicht des Fhem-Device erläutert.
** die Parameternummern stehen als configXY-Befehle zur Verfügung und werden mit Hilfetexten -auch zu den Parameterwerten- in der Detailansicht des FHEM-Device erläutert.


HINWEIS: Bitte auch bei vorhandener XML-Config-Datei nach der Inklusion und bei der Konfiguration die Assoziationen und Parameter prüfen. Von den eigenen Vorstellungen abweichende Vorgaben oder gar Fehler in der Config-Datei können nie ausgeschlossen werden. Fehler bitte im Forum ({{Link2Forum|Area=ZWave}}) melden.
HINWEIS: Bitte auch bei vorhandener XML-Config-Datei nach der Inklusion und bei der Konfiguration die Assoziationen und Parameter prüfen. Von den eigenen Vorstellungen abweichende Vorgaben oder gar Fehler in der Config-Datei können nie ausgeschlossen werden. Fehler bitte im Forum ({{Link2Forum|Area=ZWave}}) melden.


=== Wie können fehlende XML-Config-Informationen für mein ZWave-Gerät in Fhem eingebunden werden? ===
=== Wie können fehlende XML-Config-Informationen für mein ZWave-Gerät in FHEM eingebunden werden? ===
Die XML-Config-Informationen von Fhem sind in folgenden 2 Dateien im Ordner fhem/FHEM/lib gespeichert:
Die XML-Config-Informationen von FHEM sind in folgenden Dateien im Ordner fhem/FHEM/lib gespeichert:
* openzwave_manufacturer_specific.xml
* openzwave_manufacturer_specific.xml
* openzwave_deviceconfig.xml.gz
* openzwave_deviceconfig.xml.gz
* fhem_zwave_deviceconfig.xml.gz
Die in den Dateien enthaltenen Informationen beruhen in großen Teilen auf Daten von openzwave und übernehmen daher das openzwave-Datenformat, das unter https://github.com/OpenZWave/open-zwave/wiki/Adding-Devices näher beschrieben wird.  
Die in den Dateien enthaltenen Informationen beruhen in großen Teilen auf Daten von openzwave und übernehmen daher das openzwave-Datenformat, das unter https://github.com/OpenZWave/open-zwave/wiki/Adding-Devices näher beschrieben wird.  


Die Datei "openzwave_manufacturer_specific.xml" enthält die eindeutige Kennung des ZWave-Gerätes, die in Fhem nach Aufruf des Befehls <code>get <name> model</code> im Reading <code>modelId</code> des Fhem-ZWave-Devices steht. Weiterhin wird der Klartextname dieses Gerätes, der im Reading <code>model</code> angezeigt werden soll, festgelegt. Zudem wird der Dateiname der eigentlichen XML-Config-Datei für das ZWave-Gerät angegeben, der später informativ im Reading <code>modelConfig</code> steht.
Die Datei "openzwave_manufacturer_specific.xml" enthält die eindeutige Kennung des ZWave-Gerätes, die in FHEM nach Aufruf des Befehls <code>get <name> model</code> im Reading <code>modelId</code> des FHEM-ZWave-Devices steht. Weiterhin wird der Klartextname dieses Gerätes, der im Reading <code>model</code> angezeigt werden soll, festgelegt. Zudem wird der Dateiname der eigentlichen XML-Config-Datei für das ZWave-Gerät angegeben, der später informativ im Reading <code>modelConfig</code> steht.
 
Die Dateien "openzwave_deviceconfig.xml.gz" und "fhem_zwave_deviceconfig.xml.gz" enthalten in komprimierter Form die eigentlichen XML-Config-Dateien für die ZWave-Geräte. FHEM durchsucht beide Dateien nach der passenden XML-Config-Datei. Ist in beiden Dateien eine XML-Config für ein Gerät vorhanden, so werden die XML-Daten aus der "fhem_zwave_deviceconfig.xml.gz" bevorzugt.
 
Falls ein ZWave-Gerät von FHEM nicht erkannt wird, bitte auf folgenden Seiten nachschauen, ob es schon XML-Config-Dateien gibt, die nur nicht in FHEM eingebunden sind:
# https://github.com/OpenZWave/open-zwave/tree/master/config in manufacturer_specific.xml und dem herstellerspezifischen Unterordner
# https://github.com/jeedom/plugin-openzwave/tree/beta/resources/openzwaved/config in manufacturer_specific.xml und dem herstellerspezifischen Unterordner
# http://www.cd-jackson.com/index.php/zwave/zwave-device-database
Sofern auf den genannten Seiten Daten vorhanden sind, postet eine Aktualisierungsbitte mit genauem Link zur entsprechenden Seite im Forum ({{Link2Forum|Area=ZWave}}).
 
Gibt es auf keiner der Seiten Infos zu dem Gerät, dann entsprechend https://github.com/OpenZWave/open-zwave/wiki/Adding-Devices die XML-Config-Datei für das Gerät erstellen und unkomprimiert zusammen mit der zu ergänzenden Info für die Datei "openzwave_manufacturer_specific.xml" im Forum ({{Link2Forum|Area=ZWave}}) zur Verfügung stellen.


Die Datei "openzwave_deviceconfig.xml.gz" enthält in komprimierter Form die eigentlichen XML-Config-Dateien für die ZWave-Geräte. Aufbau und Struktur einer einzelnen XML-Config-Datei ist der oben verlinkten Seite bei openzwave zu entnehmen.
=== Wie führt man eine Komplett-Sicherung der ZWave-Installation durch? ===
Zu einer Komplett-Sicherung der ZWave-Konfiguration gehören:


Prüfschritte und Vorgehensweise:
1. [[Backup]] der FHEM-Installation
* Gerät ist auf https://github.com/OpenZWave/open-zwave/tree/master/config in manufacturer_specific.xml und dem herstellerspezifischen Unterordner bereits vorhanden, aber steht in Fhem nicht zur Verfügung: Hinweis im Forum ({{Link2Forum|Area=ZWave}}), dass die XML-Config-Dateien in Fhem aktualisiert werden sollen.
::'''und'''
* Gerät ist auf https://github.com/OpenZWave/open-zwave/tree/master/config in manufacturer_specific.xml und dem herstellerspezifischen Unterordner auch nicht vorhanden: Entsprechend https://github.com/OpenZWave/open-zwave/wiki/Adding-Devices die XML-Config-Datei für das Gerät erstellen und unkomprimiert zusammen mit der zu ergänzenden Info für die Datei "openzwave_manufacturer_specific.xml" im Forum ({{Link2Forum|Area=ZWave}}) zur Verfügung stellen.
2. Backup des NVRAM des Controllers


=== Welche Infos sollten Anfragen im ZWave-Forum enthalten? ===
Es genügt nicht nur die FHEM-Installation/Konfiguration zu sichern, da der Controller im NVRAM Daten über HomeID, NodeIDs usw. speichert, die in der FHEM-Installation nicht enthalten sind und auch nicht durch FHEM rekonstruierbar sind.
* Anfragen bitte nur zur aktuellsten Fhem-Version: Befehl <code>update</code> ergibt Ausgabe "nothing to do..."
 
* detaillierte Beschreibung des Problems
 
* beteiligte Komponenten (genaue Bezeichnung und evtl. Link auf Hersteller-Dokumentation)
zu 2.) Backup des NVRAM des Controllers
* list des jeweiligen Fhem-Devices (<code>list <device></code>)
 
::Bitte vor Aufruf des list-Befehls -wenn vorhanden/möglich- folgende Befehle ausführen:
Einige Controllerhersteller bieten eine eigenständige Software zum Backup/Restore an (siehe Hinweise zu den Controllern unter [[#Autocreate_des_Gateways]]).
::*<code>set <device> associationRequestAll</code> und  
 
::*<code>set <device> configRequestAll</code>
FHEM kann mit den ZWDongle-Befehlen <code>backupCreate</code> das NVRAM der Controller sichern und mit <code>backupRestore</code> zurückschreiben. Da das Speicherlayout des NVRAM unter anderem von Controller-Hersteller, SDK und Firmwareversion abhängig sein kann, sollte man die Sicherung und Wiederherstellung des eigenen Controllers (auf eigenes Risiko) testen und sinnvollerweise einen gleichen Ersatzcontroller wie den Controller des Produktivsystem besitzen. Erfolgreiche Sicherung/Wiederherstellung wurde im Forum von den ZWavePlus-Controllern UZB1 (256k), Razberry (256k), Vision ZU 1401-5 EU (128k)und AEOTEC Z-Stick Gen5 (256k) berichtet.
* logs mit gesetzten Attribut verbose 5 beim '''Gateway/Dongle''' (<code>attr <ZWDongle> verbose 5</code>); bei zeitkritischen Problemen auch <code>attr global mseclog 1</code> für die logs setzen
(Weitergehende Infos - neben der {{Link2CmdRef}} - im Forum: {{Link2Forum|Topic=52364}}, {{Link2Forum|Topic=52914}}, {{Link2Forum|Topic=53023}})


=== Wie kann ich zur Fortentwicklung der ZWave-Module beitragen? ===
=== Wie kann ich zur Fortentwicklung der ZWave-Module beitragen? ===
Zeile 357: Zeile 598:


=== Wie wird ein fehlendes Kernelmodul (Fritzbox) eingebunden? ===
=== Wie wird ein fehlendes Kernelmodul (Fritzbox) eingebunden? ===
Auf der Fritzbox (und evtl. auch anderen Systemen) muss sichergestellt werden, dass das Kernelmodul für das Gateway geladen wird. Ansonsten scheitert die Einbindung des Gateways in Fhem.
Auf der Fritzbox (und evtl. auch anderen Systemen) muss sichergestellt werden, dass das Kernelmodul für das Gateway geladen wird. Ansonsten scheitert die Einbindung des Gateways in FHEM.


Für den Aeon Labs Z-Stick muss beispielsweise auf der Fritzbox das Kernelmodul <code>cp2101.ko</code> geladen werden.
Für den Aeon Labs Z-Stick muss beispielsweise auf der Fritzbox das Kernelmodul <code>cp2101.ko</code> geladen werden.
Diese Datei ist bei einer [[FHEM und FritzBox 7390]] Installation über das Image von [http://www.fhem.de fhem.de] bereits enthalten.
Diese Datei ist bei einer [[FHEM und FritzBox 7390]] Installation über das Image von [http://www.fhem.de fhem.de] bereits enthalten.
Um den Aeon Labs Z-Stick zu verwenden, muss dieses Kernelmodul vor oder beim Starten des Fhem-Servers geladen sein. Dies erreicht man durch einen Eintrag in der Datei <code>startfhem</code>.
Um den Aeon Labs Z-Stick zu verwenden, muss dieses Kernelmodul vor oder beim Starten des FHEM-Servers geladen sein. Dies erreicht man durch einen Eintrag in der Datei <code>startfhem</code>.


Die entsprechende Zeile kann direkt unterhalb der modprobe Anweisungen eingefügt werden.
Die entsprechende Zeile kann direkt unterhalb der modprobe Anweisungen eingefügt werden.
  insmod $home/lib/cp2101.ko
  insmod $home/lib/cp2101.ko


Nach einem Fhem-Neustart sollte das Gateway (der USB Stick) nun erkannt werden.
Nach einem FHEM-Neustart sollte das Gateway (der USB Stick) nun erkannt werden.
 
=== Wie ist der Aufbau der Z-Wave Messages bzw. wie finde ich bei einem Sendefehler die NodeId des Empfängers heraus? ===
 
Es könnte natürlich hin und wieder vorkommen, dass man im FHEM-Log folgende Fehler vorfindet:
 
<code><nowiki>ZWDongle_ProcessSendStack: no ACK, resending message 010a00130603320110259277</nowiki></code>
 
In diesem Fall gab es aus irgendeinem Grund einmalig das Problem, dass der Empfang einer Nachricht vom Empfänger nicht bestätigt wurde.
Will man dem auf die Spur kommen, so wäre es natürlich von Vorteil, die NodeId des Empfängers herauszufinden. Also muss man sich die Message näher anschauen:
 
<code><nowiki>010a00130603320110259277</nowiki></code>
* 01: data to controller
* 0a: length of msg
* 00: ?
* 13: ZW_SEND_DATA
* 06: NodeId
* 03: length of msg
* 32: Command Class 32 (METER, siehe %zwave_class in 10_ZWave.pm)
* 01: METER get scale command
* 10: scale parameter
* 25: send flags, explorer frames on
* 92: callbackId (um ACK zu identifizieren)
* 77: checkSum
 
In diesem Fall hat der Z-Wave-Controller 01 eine Nachricht an die NodeId 06 geschickt, welche vom Node nicht bestätigt wurde.


[[Kategorie:HOWTOS]]
[[Kategorie:HOWTOS]]
[[Kategorie:Z-Wave Components]]
[[Kategorie:Z-Wave Components|!]]
[[Kategorie:868MHz]]

Aktuelle Version vom 24. April 2024, 10:15 Uhr

ZWDongle
Zweck / Funktion
Einbindung Z-Wave-Gateways
Allgemein
Typ Gerätemodul
Details
Dokumentation EN / DE
Support (Forum) ZWave
Modulname 00_ZWDongle.pm
Ersteller Rudolf König (Forum)
Wichtig: sofern vorhanden, gilt im Zweifel immer die (englische) Beschreibung in der commandref!


ZWave
Zweck / Funktion
Ansteuerung Z-Wave-Geräte über ZWDongle
Allgemein
Typ Gerätemodul
Details
Dokumentation EN / DE
Support (Forum) ZWave
Modulname 10_ZWave.pm
Ersteller Rudolf König (Forum)
Wichtig: sofern vorhanden, gilt im Zweifel immer die (englische) Beschreibung in der commandref!

Z-Wave ist ein drahtloser Kommunikations-Standard im 868 Mhz-Band (Europa), der von der Firma Sigma Designs und der Z-Wave Alliance, einen Zusammenschluss von mehreren Hundert Herstellern, für die Heimautomatisierung entwickelt wurde. Es existieren mehr als 1400 zertifizierte Produkte verschiedenster Hersteller, die innerhalb eines gemeinsamen Z-Wave-Netzes einsetzbar sind. (Quelle: Wikipedia)

Auf dieser Seite werden Grundlagen eines Z-Wave Systems und dessen Einrichtung in FHEM beschrieben.

Z-Wave

Nodes - Controller und Slaves

Ein Z-Wave-Netz besteht aus mindestens 2 Geräten, den sogenannten Nodes (Knoten). Es setzt sich zusammen aus dem steuernden Controller (Zentrale) und min. 1 bis max. 231 gesteuerten Slaves (Geräten).

Home-Id und Node-ID

Innerhalb eines Z-Wave-Netzes gibt es zu 2 Identifikationsnummern zur Kennzeichnung der Netzstruktur:

  1. Home-ID: Gemeinsame Identifikationsnummer aller Nodes in einem Netz zur Abgrenzung gegenüber anderen Netzen. Nur Nodes mit der gleichen Home-ID können miteinander kommunizieren.
  2. Node-ID: Identifikationsnummer zur eindeutigen Kennzeichnung von jedem Node im Netz.

Die Home-ID ist im Controller (fest) hinterlegt und seine Node-ID ist typischerweise 1. Die Slaves haben zunächst keine Home-ID und Node-ID. Bei der Inklusion (Aufnahme) der Slaves in das Z-Wave-Netz überträgt der Controller seine Home-ID auf die Slaves und weist den Slaves eine eindeutige Node-ID im Netz zu, mit der Sie direkt angesprochen werden.

Besondere Node-ID ist die 255. Eine Nachricht an die Node-ID 255 kann von allen Z-Wave-Nodes ausgewertet werden (Broadcast).

Primär- und Sekundärcontroller

Der Controller, der durch Zuteilung seiner Home-ID auf die Slaves, das Netz aufbaut, ist der Primärcontroller. Grundsätzlich können in einem Netz mehrere Controller existieren, aber immer nur ein Primärcontroller. Weitere in das Netz eingebundene Controller werden zum Sekundärcontroller. Ohne besondere Maßnahmen kann nur der Primärcontroller die Inklusion (Einbindung) der Nodes in das Netz durchführen. Hingegen können sowohl Primär- als auch Sekundärcontroller die Exklusion (Ausschluss) eines Nodes aus dem Netz vornehmen.

Der Controller speichert intern diverse Informationen (Home-ID, Node-IDs,..) über das ZWave-Netz. Hierdurch kann unter anderem die Haussteuerungssoftware bei einem PC-Controller relativ unkompliziert gewechselt werden, da die wesentlichen ZWave-Netzinformationen vom Controller selbst verwaltet und gespeichert werden. Andererseits muß bei einem Controllerdefekt das gesamte Netz grundsätzlich neu aufgebaut werden, wenn kein Backup der internen Controllerdaten vorhanden ist.

Acknowledge

Im Z-Wave-Netz werden Nachrichten vom Empänger-Node an den Sender-Node rückbestätigt (Acknowledge). Bei ausbleibendem Acknowledge wiederholt der Sender-Node die Nachricht automatisch auf Protokollebene bis zu 2 mal. Hierdurch wird eine höhere Betriebssicherheit des Z-Wave-Netzes erreicht. Bei Broadcast-Nachrichten an die Node-ID 255 findet keine Rückbestätigung statt.

Vermaschtes Netzwerk mit Routing

Z-Wave nutzt als Netzwerktopologie ein mesh network (vermaschtes Netzwerk), d. h. jeder Node ist mit einem oder mehreren anderen Nodes verbunden. Das hat den Vorteil, dass eine Nachricht zwischen zwei Nodes übermittelt werden kann, selbst wenn diese nicht direkt miteinander kommunizieren können, z. B. weil sie zu weit voneinander entfernt sind. In diesem Fall wird die Funk-Nachricht über einen oder mehrere „Zwischen-Nodes“ übertragen; dieser Vorgang wird Routing genannt. Nur netzgespeiste Z-Wave-Geräte sind Router. Batteriebetriebe Z-Wave-Geräte sind grundsätzlich keine Router und dienen somit auch nicht zur Reichweitenerhöhung. (Quelle: Wikipedia) Einzelne Geräte, die alternativ per Batterie oder USB-Anschluss betrieben werden können, werden bei USB-Anschluss automatisch (Beitrag) oder durch Konfigurationsänderungen (Beitrag) zu Routern.

Informationen über das optimale Routing werden bei der Inklusion der Nodes in einer Routing-Tabelle des Primärcontrollers gespeichert. Dies geschieht durch Abfrage des Nodes, welche weiteren Nodes er erreichen kann. Durch örtliche Änderung oder Defekte von Nodes können die in der Routing-Tabelle gespeicherten Informationen fehlerhaft bzw. suboptimal werden. Dies kann sich in Funkkommunikationsproblemen im Netzwerk äußern. Hier kann ein per Software manuell angeforderter Neuaufbau der Routing-Tabelle gegebenenfalls Abhilfe schaffen. Bei Geräten und Controllern mit aktuellen Firmware-Versionen (SDK 4.5x und SDK 6.xx oder größer, aber nicht SDK 5.x) und Unterstützung von Explorer Frames kann sich die Routing-Tabelle unter bestimmten Bedingungen auch automatisch aktualisieren ("Selbstheilung")[1].

Command Classes

Die Steuerung und Kommunikation der Nodes erfolgt über Befehle die funktionsbezogen in verschiedene Command Classes (Kommandoklassen) zusammengefasst sind.

Alle Z-Wave-Geräte haben als gemeinsame kleinste Übereinstimmung die Class Basic.

Z-Wave-Geräte haben im Originalzustand eine bestimmte arbeitsfähige Grund-Konfiguration. Anpassbar an individuelle Bedürfnisse ist die Konfiguration über die Class Configuration.

Durch eine Assoziation wird definiert, welche Geräte miteinander direkt -ohne Umweg über den Controller- kommunizieren können. Auch bei Ausfall des Controllers können diese Geräte ihre gemeinsame Funkton ausüben. Zudem dienen Assoziationen der Geschwindigkeitssteigerung und Funklastreduzierung innerhalb des Netzes. Angelegt werden Assoziationen über die Class Association.

Dies sind nur die allerwichtigsten Command Classes. Weitere Command Classes sind den Handbüchern zu entnehmen. Zudem enthält die Wiki-Seite Z-Wave Command Classes weitergehende Informationen.

Hinweise zur Z-Wave-Geräteauswahl

Aufgrund der vielen Z-Wave-Gerätehersteller mit jeweils eigenem Z-Wave-Gerätesortiment existiert eine große Produktauswahl. Jedoch gibt es auch große Unterschiede hinsichtlich Produkteigenschaften, Pflege der Produkte, Häufigkeit der Aktualisierung der Produktpalette und so weiter. Schwierigkeiten bereitet insbesondere, dass neben den aktuellesten Chipsätzen und SDKs auch die älteren Chipsätze und SDKs weiterhin in Produkten im Handel verfügbar sind. Neuere Chipsätze und aktuelle SDKs bieten gerade bei der Netzwerkstabilität (Explorer Frames, Reichweite usw.) Vorteile zu älteren Chipsätzen und SDKs. Beispielsweise beherrschen nur Geräte mit SDK 4.5x und 6.x oder neuer die für automatische Routenkorrekturen wichtigen Explorer Frames. Das ältere SDK 5.0, das verwirrenderweise auch noch eine höhere Versionsnummer als das neuere SDK 4.5 besitzt, beherrscht unter anderem keine Explorer Frames. Details hierzu enthält das wiki.zwaveeurope.com. Aktuellstes SDK ist Stand 10/2017 das SDK 6.7x, das in ZWave Plus - zertifizierten Produkten zum Einsatz kommt.

Gerade Einsteiger beachten die Unterschiede bei den Chipsätze/SDKs aus Unkenntnis manchmal nicht und ärgern sich im Nachhinein über Probleme bei der Netzwerkstabilität und Reichweite. Darum nachfolgend allgemeine, aber sehr einfache Empfehlungen zur Geräteauswahl. Selbstverständlich wird hier nicht von anderen Produkten abgeraten, wenn man die Unterschiede kennt und Vorteile bei deren Produkteigenschaften sieht. Zudem kann man (leider) schlechtere Produkteigenschaften bei Geräten mit aktuelleren Chipsätzen/SDKs nie ausschließen.

Gateway

  1. Z-Wave Plus-Zertifizierung. Diese ist mittlerweile bei nahezu allen erhältlichen Gateways gegebenen.

Endgeräte

  1. Z-Wave Plus-Zertifizierung (aktuellste Technik, höhere theoretische Reichweite, SDK 6.5x oder höher) oder
  2. zumindest Explorer Frames-Unterstützung (SDK 4.5x und 6.0x) oder
  3. zuletzt -bei Kenntnis der Besonderheiten und Auswirkungen- Produkte ohne Explorer Frames (SDK 5.0x)

Kurz: Produkte mit Z-Wave Plus-Zertifizierung einsetzen.

Bitte unbedingt beachten, dass Z-Wave Plus-Vorteile bei einem Mischbetrieb mit älteren (ohne Plus) Geräten teilweise verloren gehen. Zum negativen Effekt des Einsatzes eines älteren, aber weiterhin erhältlichen Z-Wave-Repeaters mit aktuellen Z-Wave Plus-Geräten siehe beispielsweise den Hinweis in diesem Beitrag.

Bei Fragen zu bestimmten Geräten bitte -nach Durchsicht der Hinweise hier im Wiki- im Forum suchen oder anschließend nachfragen.

Z-Wave in FHEM

Allgemein

FHEM wird fortwährend weiterentwickelt und verbessert. Daher ist es zwingend notwendig, dass FHEM auf dem aktuellsten Stand ist. Dazu nach der FHEM-Installation den Befehl update ausführen und anschließend shutdown restart durchführen. Genauso auch vor Anfragen im Forum die Aktualität von FHEM überprüfen.

Die Einbindung von Z-Wave in FHEM ist (nicht nur für den Anfänger) ausschließlich mit der standardmäßig eingeschalteten autocreate-Funktion einfach möglich. Die Kenntnis der FHEM-Grundlagen und Durcharbeitung der Anfänger-Lektüren wird im Folgenden vorausgesetzt. Insbesondere sind Erste Schritte in FHEM und Heimautomatisierung mit FHEM Pflicht, auch wenn sie nicht speziell Z-Wave behandeln, so werden doch wesentliche Punkte für ein Verständnis von FHEM vermittelt.

Nachfolgend und auf den Wiki-Seiten der Einzelgeräte werden immer wieder Auszüge aus der Konfiguration dargestellt. Diese dienen zur Erläuterung und Veranschaulichung. Die Bearbeitung der Konfiguration sollte -zur Verhinderung von Fehlern- nach Möglichkeit immer über das "Befehl-Eingabefeld" und die "Objektdetails" erfolgen.

Vorbereitung

Die Bedienungsanleitungen (Handbücher) sind zwingende Voraussetzung zur korrekten Einbindung und Konfiguration von Z-Wave-Geräten in FHEM. Sie müssen daher vorliegen. Den ZWave-Geräten liegen teilweise nur gekürzte, gedruckte Fassungen der Handbücher bei. Man sollte bei allen Produkten auf folgenden Seiten nach eventuellen ausführlicheren Informationen suchen:

Insbesondere auf https://products.z-wavealliance.org, der Datenbank der ZWave-zertifizierten Produkte, sind regelmäßig ausführliche Informationen zu den Geräten zu finden.

Definition des Gateways / Controllers

Info green.pngTester für ZWave@culfw gesucht! Z-Wave-Controllerfunktionen werden derzeit in die Firmware culfw für den CUL implementiert. Weitere Informationen im ZWCUL - Artikel.

Autocreate des Gateways

FHEM kann mit einem Funkgateway Z-Wave-Funk empfangen und senden. Z-Wave-Gateways (Controller) existieren von verschiedenen Herstellern.

Folgende Gateways wurden unter anderem bereits erfolgreich mit FHEM eingesetzt:

Folgende Gateways sind nicht mit FHEM einsetzbar:

  • Merten Funk-USB-Datenschnittstelle CONNECT

Sollte das eigene Gateway hier nicht aufgeführt sein, ist aufgrund der Standardisierung dennoch die Chance für eine erfolgreiche Einbindung des Gateways in FHEM vorhanden. Bitte dies hier oder im Forum entsprechend vermerken.

Das Z-Wave-Gateway wird unter Linux nach Anschluss an den FHEM-Rechner beim nächsten FHEM-Start oder ohne FHEM-Neustart durch Aufruf des Befehls usb scan zumeist automatisch erkannt und das zugehörige FHEM-Device nach dem Namensschema ZWDongle_<Anhang> angelegt. Ein manuelles Anlegen des ZWDongle-Moduls oder Eingriffe in die Konfiguration sind unter Linux normalerweise nicht notwendig.

Unter Windows ist ein manuelles Anlegen der Definition des ZWave-Gateways wegen fehlender Unterstützung des Befehls usb scan erforderlich (Beispiel für Z-Wave.Me USB Stick ZME_UZB1 unter Windows: define ZWDongle_1 ZWDongle COM1@115200).

Das FHEM-Gateway-Device ist nach der Definition in FHEM im Raum "Everything" zu finden.

Beispiele der automatisch erzeugten define-Zeile in der Konfiguration:

Aeon Labs Z-Stick an der Fritzbox:

define ZWDongle_1 ZWDongle /dev/ttyUSB1@115200

Vision Z-Wave USB Stick ZU 1401 EU am Raspberry Pi (Raspbian):

define ZWDongle_1 ZWDongle /dev/ttyACM1@115200

Insbesondere wenn am FHEM-Server unter Linux mehrere USB-Gateways eingesetzt werden, empfiehlt es sich zur Erhöhung der Betriebsstabilität das Z-Wave-Gateway über Serial-by-Id oder uDev-Regeln anzusprechen.

Bei einem statischen Controller wird die Einrichtung als SUC -sofern der Controller als solcher nicht bei Auslieferung eingerichtet ist- vor der ersten Inklusion von Geräten empfohlen.

homeId und nodeList des Gateways

Zur manuellen Definition von Z-Wave Aktoren und Sensoren ist die homeId notwendig. Bei der hier bevorzugten Definition der Geräte durch autocreate ist die Kenntnis der homeId nicht zwingend. Jedoch sollte durch Abfrage der homeId direkt nach Einbindung des Zwave-Gateways dessen Funktionsfähigkeit getestet werden.

Die homeId und CtrlNodeId des Gateways wird mit folgendem Befehl ausgelesen (<ZWDongle> ist im folgenden durch den Namen des FHEM-Devices des eigenen Gateways zu ersetzen):

get <ZWDongle> homeId

ergibt beispielsweise bei einem Gateway mit dem FHEM-Devicenamen ZWDongle_1:

ZWDongle_1 homeId => HomeId:e345c456 CtrlNodeId:01 

In diesem Beispiel ist die Home-Id des Gateways ZWDongle_1 e345c456 und das Gateway hat die Node-Id 1.

Die aktuelle Liste der Z-Wave Nodes, die bereits am Gateway registriert/inkludiert sind, wird mit dem folgendem Befehl ausgelesen:

get <ZWDongle> nodeList

ergibt beispielsweise:

ZWDongle_1 nodeList => ZWDongle_1 UNKNOWN_2


Definition von Geräten / Slaves

Hinzufügen eines neuen Z-Wave Geräts / Inklusion

Zur Verfolgung von Inklusionsablauf und Meldungen des Controllers während der Inklusion sollte der Event monitor in einem 2. Browserfenster vor Aktivierung des Inklusionsmodus geöffnet werden.

Das Z-Wave Gateway wird in den Standard-Modus zur Inklusion (zum Aufnehmen) neuer Geräte gesetzt:

set <ZWDongle> addNode on

Bei der Standard-Inklusion muss direkter Funkkontakt zwischen Gateway und zu inkludierendem Z-Wave Gerät bestehen.

Sofern Z-Wave Gateway und Z-Wave Geräte Explorer Frames unterstützen, sollte statt des obigen Befehls besser der Network-Wide-Modus für die Inklusion genutzt werden:

set <ZWDongle> addNode onNw

Bei der Network-Wide-Inklusion muss kein direkter Funkkontakt zwischen Gateway und zu inkludierendem Z-Wave Gerät bestehen. Es reicht, wenn das zu inkludierende Gerät über andere bereits inkludierte, netzgespeiste Geräte mit Explorer Frames-Unterstützung erreicht werden kann. Die Network-Wide-Inklusion ist zu bevorzugen, da die Z-Wave-Geräte regelmäßig an Ihren örtlichen Endpositionen inkludiert werden können. Dadurch werden bei der Inklusion direkt die korrekten Routen gespeichert.

Nachdem das Gateway in den Inklusionmodus geschaltet wurde, muss das Gerät in den Inklusionsmodus (Aufnahmemodus) versetzt werden. Wie dies zu erfolgen hat, ist im Handbuch des Geräte nachzulesen. Typisch sind ein- oder dreimaliges Drücken einer Taste am Gerät oder beim Anlegen der Versorgungsspannung. Durch die Inklusion werden Home-ID und Node-ID im Gerät gespeichert. Zudem teilt das Gerät über ein spezielle Funknachricht (NIF=Node Information Frame) dem Controller seinen Gerätetyp und seine Geräteeigenschaften mit. Hierbei werden dem Controller auch die vom Gerät unterstützten Command Classes mitgeteilt. Aus diesen Informationen erzeugt FHEM automatisch durch autocreate das FHEM-Geräte-Device nach dem Namensschema ZWave_<Geräteklasse laut NIF des Gerätes>_<NodeID> (an eigene Wünsche anpassbar mit rename). Die vom Geräte unterstützen Command Classes, die die in FHEM verfügbaren Befehle bestimmen, werden automatisch im Attribut classes des FHEM-Geräte-Device gespeichert. Das Gerät ist damit grundlegend in FHEM definiert und im Raum "ZWave" zu finden.

Nach der Inklusion schaltet FHEM den Inklusionsmodus des Z-Wave Gateway automatisch durch Absetzen des Befehls set <ZWDongle> addNode off aus und zeigt eine Dialogbox mit dem Ergebnis der Inklusion:

  • created ZWave_<Geräteklasse laut NIF des Gerätes>_<NodeID> = Inklusion war erfolgreich und es wurde das bezeichnete FHEM-Device durch autocreate angelegt.
  • addNode failed = Inklusion ist fehlgeschlagen

Eine erfolgreiche Inklusion ist zudem am Event "ZW_ADD_NODE_TO_NETWORK protocolDone" im Event monitor und natürlich der Anlage des entsprechenden FHEM-Devices durch autocreate zu erkennen. Das Scheitern einer Inklusion führt typischerweise zur Ausgabe des Events "ZW_ADD_NODE_TO_NETWORK failed". Häufigste Ursache sind Controllerprobleme, die sich oftmals durch kurzes Ein- und Ausstecken des Controllers, Neustart des Systems oder Ein- und Ausschalten des FHEM-Server-Computers beheben lassen.

HINWEISE:

  • Die Network-Wide-Inklusion kann nach derzeitiger Kenntnis auch bei Gateways und Geräten ohne Explorer Frames Unterstützung genutzt werden, da bei diesen Geräten grundsätzlich automatisch auf die Standard-Inklusion umgestellt wird.
  • Bei der Standard-Inklusion ist unter Umständen nur ein geringer Abstand zwischen Gateway und Gerät möglich. Sollte die Inklusion daher nicht durchführbar sein, wenn Gateway und Gerät an ihren örtlichen Endpositionen sind (bevorzugte Variante), dann ist der Abstand zwischen diesen versuchsweise zu verringern. Anschließend bei örtlicher Veränderung die Routen mit set <ZWave-Devicename> neighborUpdate bzw. set TYPE=ZWave:FILTER=ZWaveSubDevice=no neighborUpdate neu ermitteln lassen. Unter Umständen kann der Abstand nur schrittweise erhöht werden. Dann ist bei jeder Abstandsänderung eine Neuermittlung der Routen notwendig.
  • Der NIF enthält bei manchen Geräten fälschlicherweise nicht alle unterstützten Command Classes. FHEM identifiziert während der Inklusion das Gerät und ergänzt die fehlenden Command Classes aufgrund manuell gepflegter, gerätespezifischer XML-Config-Dateien. Weiterhin fehlende Command Classes können im Attribut classes manuell am Anfang der Liste entsprechend ergänzt werden. Informationen liefern die unter Links aufgeführten Datenbanken. Häufig fehlt die Pflicht-Class BASIC.
  • Bei der hier beschriebenen Inklusion findet die Kommunikation zwischen Controller und Gerät anschließend dauerhaft unverschlüsselt statt. Manche Geräte bieten mit der Command Class SECURITY eine AES-verschlüsselte Kommunikation an. Da die Verschlüsselung zu einer höheren Funklast und Latenzen führt, sollte eine verschlüsselte Kommunikation nur mit Bedacht eingesetzt werden (bspw. bei Schlössern). Als Sonderfall ist das Vorgehen zur secure-Inklusion in der FAQ beschrieben.

Nächster Schritt ist die Assoziation des Gerätes mit dem Gateway.

Assoziation

Info green.pngBitte unbedingt die Besonderheiten bei batteriebetriebenen Geräten beachten!

Z-Wave-Geräte können über Assoziationen direkt mit anderen Z-Wave-Geräten kommunizieren. Dies können zum einen Meldungen über den Status und Zustand der Geräte, als auch direkte Befehle sein. Zum Beispiel kann damit ein Bewegungsmelder eine entdeckte Bewegung an den Controller senden und/oder bei entdeckter Bewegung direkt eine Lampe ein- oder ausschalten.

Die Assoziation zwischen zwei Geräten wird durch Aufnahme des zu steuernden Gerätes in eine oder mehrere Assoziationsgruppe(n) des steuernden Gerätes angelegt. Durch die Wahl der Assoziationsgruppe wird festgelegt, bei welchen Ereignissen welche Nachricht an das assoziierte Gerät verschickt wird. Angaben zu den Ereignissen und versandten Nachrichten an die Geräte in einer bestimmten Assoziationsgruppe stehen in der Bedienungsanleitung des jeweiligen Gerätes.

Damit FHEM Statusmeldungen von Sensoren/Aktoren anzeigen und auch darauf reagieren kann, muss der Controller (<ZWDongle>-Device, CtrlNodeId = typischerweise 1) immer in der/den passenden Assoziationsgruppe(n) des jeweiligen Gerätes <name> aufgenommen werden:

set <name> associationAdd <associationGroup> <CtrlNodeId>

Typischerweise ist die Assoziationsgruppe 1 der Geräte für die Statusmeldungen an den Controller vorgesehen (Ausnahme: Fibaro-Geräte ohne ZWave Plus - Zertifizierung). Daher nimmt FHEM die Assoziation von Controller mit der Assoziationsgruppe 1 des Gerätes bei der Inklusion immer automatisch vor. Zudem identifiziert FHEM während der Inklusion das Gerät und setzt weitere Assoziationen mit dem Controller für von 1 abweichende Assoziationsgruppen aufgrund manuell gepflegter, gerätespezifischer XML-Config-Dateien. Ist keine XML-Config-Datei für das Gerät vorhanden, sind Assoziationen des Controllers mit von 1 abweichenden Assoziationsgruppen oder weiteren Assoziationsgruppen mit dem zuvor genannten Befehl grundsätzlich manuell anzulegen.

Die richtige Anlage der Assoziation(en) des Controllers mit dem Gerät immer prüfen, da dies eine Hauptfehlerquelle bei Funktionsproblemen mit FHEM ist.

Abruf der assoziierten Geräte in einer bestimmten Assoziationsgruppe <associationGroup>:

get <name> association <associationGroup>

Abruf der assozierten Geräte für alle Assoziationsgruppen eines Gerätes:

get <name> associationAll

Nahezu alle in Europa erhältlichen aktuellen Geräte unterstützen die Rückmeldung des Status via Association. Ausnahmen gibt es in Nordamerika, wo aufgrund von Patentansprüchen einige Hersteller auf die Statusrückmeldungen verzichten. Diese Geräte unterstützen in der Regel die Command Class ASSOCIATION nicht.

Nächster Schritt ist die Konfiguration des Gerätes.

Konfiguration

Info green.pngBitte unbedingt die Besonderheiten bei batteriebetriebenen Geräten beachten!

Die Standard-Konfiguration eines Gerätes entspricht oftmals nicht den eigenen Wünschen und Anforderungen (Einheiten usw.). Mit den Befehlen der Class CONFIGURATION lässt sich die Konfiguration anpassen. Die zur Konfiguration eines Gerätes notwendigen Angaben zu den Parameternummern, -größen und -werten sind im jeweiligen Geräte-Handbuch bzw. entsprechenden Datenbanken (bspw. pepper1-ZWave-Datenbank oder products.zwavealliance.com) enthalten.

Die Konfiguration beispielsweise bei Parametergröße 1 lässt sich mit diesem Befehl anpassen:

set <name> configByte <Parameternummer> <Parameterwert>

Für weitere Parametergrößen gibt es die Befehle configWord und configLong

Die im Gerät hinterlegten Konfiguration kann pro Parameternummer mit folgendem Befehl abgerufen werden:

get <name> config <Parameternummer>

Zudem bietet FHEM basierend auf den manuell gepflegten XML-Config-Dateien die Möglichkeit, die speziellen Parameternummern des Gerätes mit ihren Parametergrößen und -werte als eigenständige config-Befehle mit Hilfsinformationen einzubinden. Ein manuelles Suchen im Geräte-Handbuch und Nutzung der configByte-, configWord- und configLong-Befehle ist dadurch in vielen Fällen unnötig. Für diese Funktion muss das Gerät von FHEM einmalig durch folgenden Befehl, der bei der Inklusion automatisch ausgeführt wird, identifiziert werden:

get <name> model

Die Readings model, modelID und modelConfig werden dadurch erzeugt. In model sollte der Klartextname des Gerätes stehen. Zudem sind dann -soweit eine XML-Config Datei für das Gerät existiert- die speziellen set/get-Kommandos configXYZ für das Geräte im Auswahldialog der Detailansicht mit Hilfsinformationen verfügbar:

config-Befehl mit Hilfstext

Bei vorhandener XML-Config-Datei kann die komplette Konfiguration eines Gerätes abgerufen werden:

get <name> configAll

Außerdem wird durch den get <name> model -Befehl geprüft, ob das Gerät in der pepper1-ZWave-Datenbank und/oder products.zwavealliance.com enthalten ist. Im Erfolgsfall wird ein Link "Details in pepper DB" und/oder "Details in alliance DB" zum entsprechenden Geräteeintrag in der jeweiligen Datenbank unten in der Detailansicht des FHEM-Geräte-Devices angelegt und ein Bild des Gerätes in die Detailansicht eingebunden.

Der Aufruf von get <name> model ist auch für die Nutzung der Class MANUFACTURER_PROPRIETARY zwingende Einsatzvoraussetzung.

Entfernen eines Z-Wave-Geräts / Exklusion

Durch die Exklusion wird die Home-ID und Node-ID aus dem Gerät und das Gerät selbst aus der Node-List des Controllers gelöscht. Erst nach einer Exklusion kann das Gerät in ein anderes Z-Wave-Netz aufgenommen werden.

Zuerst wird der Z-Wave Gateway in den Standard-Modus zur Exklusion (Ausschluss) von Geräten gesetzt:

set <ZWDongle> removeNode on

Sofern Z-Wave Gateway und Z-Wave Geräte Explorer Frames unterstützen, sollte statt dem obigen Befehl besser der Network-Wide-Modus für die Exklusion genutzt werden (siehe auch Erläuterungen zu Standard- versus Network-Wide-Inklusion unter Inklusion):

set <ZWDongle> removeNode onNw

Danach muss das Gerät in den Exklusionsmodus (Ausschlussmodus) versetzt werden. Wie dies zu erfolgen hat, ist im Handbuch des Geräte nachzulesen.

Abschließend wird der Exklusionsmodus am Z-Wave Gateway wieder ausgeschaltet:

set <ZWDongle> removeNode off

Das FHEM-Device muss nach der Exklusion manuell durch delete <name> gelöscht werden.

Die durch die Exklusion frei gewordene NodeID wird nicht bei der nächsten Inklusion wiederverwendet, sondern es wird die höchste noch nicht verwendete NodeID genutzt.

Erneutes Hinzufügen eines bereits registrierten Z-Wave Geräts

Die an einem Z-Wave-Gateway bereits registrierten/inkludierten Geräte sind im Gateway selbst abgespeichert und können durch FHEM jederzeit wieder abgerufen werden. Dies kann man in folgenden Fällen sinnvoll nutzen:

  • Inklusion mit einem batteriegespeisten ZWave-Gateway (bspw. Aeon Labs Z-Stick) ohne FHEM-Server-Anschluss während der Inklusion
  • Umstieg eines ZWave-Netzwerkes von Fremdsoftware auf FHEM
  • Vollständiger oder teilweiser Verlust der FHEM-Konfiguration

Eine Node-Liste aller inkludierten Geräte des Gateways wird abgerufen durch:

get <ZWDongle> nodeList

Es wird eine Liste aller im Gateway inkludierten Gerät inklusive Gateway selbst zurückgeliefert. Sofern ein Gerät bereits als FHEM-Device angelegt wurde, wird der FHEM-Device-Name in der nodeList angezeigt. Dies ist für das Gateway selbst immer der Fall. Alle noch nicht in FHEM angelegten Geräte, werden als "UNKNOWN_x" ausgegeben, wobei x die ID des betreffenden Gerätes ist.

Mit dem folgenden Befehl wird beispielsweise das bereits im Gateway inkludierte Gerät mit der ID 2 (in der nodeList angezeigt als "UNKNOWN_2") in FHEM durch autocreate definiert:

set <ZWDongle> createNode 2

Batteriebetriebene Geräte müssen bei Absetzen des createNode-Befehls wach sein, damit der Befehl verarbeitet werden kann. Dies erreicht man, indem man das Gerät auf "permanent wach" stellt. Falls das Gerät diese Funktion nicht anbietet, muss man es manuell aufwecken und max. 2 Sekunden später den createNode-Befehl absetzen. Alternativ kann das batteriebetriebene Gerät durch Versand des NIF vom Gerät aus automatisch in FHEM erzeugt werden: Hierzu am Gerät die Taste zum Versand des NIF drücken und autocreate legt das FHEM-Device an; der Aufruf von createNode entfällt dann.

Geräte-Besonderheiten

batteriebetriebene Geräte

Batteriebetriebenen Geräten können hinsichtlich ihrer Empfangsbereitschaft unterschieden werden in

  • Wakeup-Geräte
  • FLIRS-Geräte

Wakeup-Geräte

Wakeup-Geräte sind momentan die häufigste Art von batteriebetriebenen Z-Wave Geräten. Sie sind erkennbar an der Unterstützung der Command Class WAKE_UP. Zur Verlängerung der Batterielaufzeit legen sich batteriebetriebene Wakeup-Geräte „schlafen“ und wachen (Wakeup) nur in konfigurierbaren Intervallen auf, um Befehle zu verarbeiten. Das Aufwachen signalisieren die Geräte durch den Versand einer Nachricht "wakeup notification". Daraufhin senden FHEM und andere Geräte ihre bis dahin gesammelten Befehle, die dann verarbeitet bzw. beantwortet werden. Anschließend gehen die batteriebetriebenen Geräte wieder in den Schlafmodus.

FHEM teilt bei set/get-Befehlen an batteriebetriebene Geräte über einen Hinweis der Form

Scheduled for sending after WAKEUP
oder
Scheduled get requests for sending after WAKEUP

mit, dass der Befehl im Sendstack des FHEM-Geräte-Devices abgespeichert wurde und bei der nächsten "wakeup notification" an das Gerät versendet wird. Ein Versand der Befehle im Sendstack findet grundsätzlich ausschließlich nach Erhalt der "wakeup notification"-Nachricht statt, selbst wenn das Gerät zwischendurch andere Telegramme (bspw. Bewegungsmeldung, Temperatur) an den Controller verschickt. Nur nach Versand der "wakeup notification" ist das batteriebetriebene Gerät grundsätzlich in der Lage ("wach genug"), Telegramme korrekt zu empfangen und zu verarbeiten.

Wie viele Nachrichten im Sendstack auf einen Versand an das Gerät warten, ist im Internal cmdsPending des zugehörigen FHEM-Devices ersichtlich. Welche Nachrichten (Befehle) im Sendstack warten, ist in der Ausgabe des Befehls list <device> erkennbar: Unter der Überschrift Sendstack sind alle wartenden Nachrichten als Rohnachrichten aufgeführt. Der Sendstack wird beim Beenden von FHEM nicht gespeichert. Durch Beenden von FHEM (beispielsweise durch shutdown restart) geht der Sendstack der Geräte daher verloren.

Das Wakeup-Interval und der Empfänger der "wakeup notification" wird wie folgt konfiguriert:

set <name> wakeupInterval <time> <NodeId>

<time> ist die Zeit in Sekunden zwischen den Intervallen und <nodeID> der gewünschte Empfänger der "wakeup notification"; in der Regel ist dies immer der Controller <CtrlNodeId>. Viele Geräte kommen im Auslieferungszustand mit der NodeID 255. Die "wakeup notification" wird dann als Broadcast ohne Nutzung von Routing an alle erreichbaren Geräte gesendet. Hier sollte die Konfiguration auf die NodeID des Controllers geändert werden, da dadurch die "wakeup notification" geroutet wird und größere Entfernungen zwischen Gerät und Controller möglich sind. Zudem ist dies robuster und spart zusätzlich noch Batterielaufzeit. Darum setzt FHEM bei der Inklusion von WakeUp-Geräten automatisch den Befehl set <name> wakeupInterval 86400 <ControllerNodeId> ab. Bei abweichenden eigenen Vorstellungen ist dies gegebenenfalls anzupassen. Bei Geräten mit V2 der Command Class WAKE_UP kann das vom Hersteller vorgesehene Standard-wakeupInterval mit get <name> wakeupIntervalCapabilities vom Gerät abgerufen werden. Die Einstellungen von wakeupInterval nach Inklusion und nach jeder Änderung immer mit der Abfrage get <name> wakeupInterval überprüfen.

Ein Aufwachen und Versand der "wakeup notification" von batteriebetriebenen Geräten kann für die Assoziation und Konfiguration manuell erzwungen werden. Hierzu bringt man das Gerät normalerweise in den Inklusionsmodus oder findet in der Bedienungsanleitung gegebenenfalls andere Informationen. Bitte beachten, dass dann je nach Gerät nur eine geringe Entfernung von Gateway und Gerät vorhanden sein darf (direkte Erreichbarkeit). Alternativ kann für die Dauer der Assoziation und Konfiguration das Wakeup-Interval verkürzt werden (beispielsweise auf 60 Sekunden), wodurch das Routing genutzt werden kann und größere Entfernungen zwischen Gateway und Gerät überbrückt werden können. Anschließend das Wakeup-Interval wieder auf eine batterieschonenende Dauer einzustellen.

Einzelne batteriebetriebene Gerät lassen sich für längere Zeit auf "wach" bzw. permanent "wach" stellen. Dann aus dem Attribut classes WAKE_UP entfernen, damit Befehle in diesem Gerätemodus von FHEM direkt verschickt werden. Nach Ausschalten des "wach"-Modus WAKE_UP wieder im Attribut classes aufnehmen.

Bei Konfigurationsänderungen an batteriebetriebenen Geräten mit set <name> config... sollte die korrekte Verarbeitung der Befehle immer mit dem entsprechenden get <name> config... oder -falls vorhanden- mit get <name> configAll überprüft werden, um eventuelle Funk-Telegrammverluste sofort festzustellen.

FLIRS-Geräte

Ein batteriebetriebene FLIRS (frequently listening routing slave) Gerät wacht in sehr kurzen Zeitabständen (250ms oder 1000ms) auf und prüft, ob ein Funksignal vorliegt. Liegt kein Funksignal vor geht das Gerät wieder in Tiefschlaf. Zum Aufwecken eines FLIRS-Gerätes ist ein dauerhaftes Funksignal -der Wakeup-Beam-, notwendig, das etwas länger als die Aufweckzeitabstände sein muss. Näher beschrieben unter anderem hier.

FLIRS-Geräte haben nicht die Command Class WAKE_UP und arbeiten deshalb nicht mit "wakeup notification". Aus Sicht des FHEM-Nutzers sind die bekannten FLIRS-Geräte (Sirenen von Vision und Popp) nicht anders zu bedienen/einzurichten als netzgespeiste Geräte. Wakeup-Beam und andere Besonderheiten werden unsichtbar für den Nutzer automatisch abgewickelt.

Aeon Labs / Aeotec

Ausführliche Handbücher und technische Informationen auf https://aeotec.freshdesk.com/support/home

Multi Sensor 5

  • aktuellste Firmware installieren
  • Attribut classes um BASIC ergänzen (ab Modulversion 8824/25.6.2015 wird das automatisch bei der Inklusion durchgeführt)
  • bei USB-Anschluss aus Attribut classes WAKE_UP entfernen
  • Parameter 101 auf 225 (oder 224 bei USB-Anschluss) setzen mit set <name> configGroup1Reports 225 oder set <name> configLong 101 225, um Batteriezustand (nicht bei 224), Temperatur, Feuchte und Helligkeit regelmäßig zu erhalten. Das Sende-Intervall wird duch set <name> configGroup1Interval <time/s> festgelegt (Standard 720 Sek).
  • Paramterübersicht pepper-Datenbank

siehe Beitrag

Multisensor 6

siehe Thema

  • arbeitet bei USB-Anschluß als Router
  • bei USB-Anschluss aus Attribut classes WAKE_UP entfernen
  • die configGroupxInterval und configxxxReportingThreshold Einstellungen wirken nur bei USB-Anschluss, im reinen Batteriebetrieb werden die Sensordaten nur bei einem wakeup übertragen

Aeotec LED Bulb ZW098-C55

siehe Thema

Danfoss

DAN_LC-13 Heizungsthermostat LC-13 (014G0013)

Das Danfoss Heizungsthermostat LC-13 muss derzeit zur korrekten Funktion mit FHEM regelmäßig mit folgendem at abgefragt werden (Beitrag):

define Atdanfoss at +*00:30 get <name> battery

Auf dem Markt sind mehrere Varianten des Thermostates LC-13 erhältlich. Darum beim Kauf unbedingt auf die genaue Bezeichnung LC-13 (014G0013) achten (Beitrag).

devolo

Ausführliche Handbücher auf http://products.z-wavealliance.org

MT02648 Tür-/Fenster Kontakt 3in1

siehe Thema

DüWI

Geräte von DÜWI liefern bei örtlicher Betätigung kein automatisches Funk-Signal über die Statusänderung. Das liese sich nur durch eine regelmäßige Statusabfrage durch FHEM (beispielsweise define Status_Abfrage at +*00:03:00 get <name> swmStatus) beheben. Einige Produkte von Z-Wave.Me basieren auf DÜWI-Geräten. Diese Z-Wave.Me Produkte haben jedoch eine erweiterte Firmware, welche die genannte und weitere Firmware-Schwächen der Original-Produkte von DÜWI behebt.

Everspring

AN145 Sockelmodul E27

Statusabfrage ohne permanente Abfrage: Beitrag

Fibaro

Association Group für Übermittlung von Statusinformationen an den Controller:

  • "alte" ZWave-Geräte (kein ZWave-Plus): häufig Association Group 3
set <name> associationAdd 3 <CtrlNodeId>
Bei diesen Geräten empfiehlt es sich zur Funklastreduzierung und Problemminimierung zu prüfen, ob die von FHEM automatisch vorgenommene Assoziation des Controllers mit der Association Group 1 gelöscht werden kann (set <name> associationDel 1 <CtrlNodeId>). Nahezu immer werden in Association Group 1 die gleichen Infos, nur mit einer anderen Command Class, wie in der Association Group 3 an den Controller übermittelt.
  • ZWave Plus-Geräte: Association Group 1 ("lifeline")

FGSS-001 / FGSD-002 Rauchmelder

  • nicht untereinander vernetzbar
  • keine Alarmauslösung/Sirenenfunktion durch ZWave-Zentralen

FGS-222 Relais Unterputzeinsatz

Bei der Inklusion werden von FHEM 3 Devices angelegt:

  • Hauptdevice (Steuerung und automatischer Status für Kanal 1 und kanalübergreifende Funktionen)
  • Device für Endpoint 1 (Steuerung Kanal 1)
  • Device für Endpoint 2 (Steuerung und automatischer Status von Kanal 2)

Die Firmware des FGS-222 übermittelt den Status für Kanal 1 automatisch immer ausschließlich an das Hauptdevice. Die Steuerung von Kanal 1 kann hingegen sowohl über das Hauptdevice als auch über das Device für Endpoint 1 erfolgen. Das Device für Endpoint 1 ist somit nicht zwingend erforderlich und kann grundsätzlich gelöscht oder in den room hidden verschoben werden.

Details: Thema

Hinweis zum Reset: Beitrag

FGK-101 Tür/Fensterkontakt

  • Besonderheiten bei Anschluss eines Temperatursensors: Thema

GE

GE (Model t.b.d)

Dieser Schalter unterstützt keine Statusrückmeldungen.

Merten

Laut Thema müssen bei einigen Merten-Geräten, die mit Fremdsoftware inkludiert wurden, gegebenenfalls die Geräte wieder exkludiert und dann erneut mit FHEM inkludiert werden, damit Assoziationen mit FHEM gesetzt werden können.

Philio

PHI_PAN04 Relais Unterputzeinsatz 2 Schalter a 1.5kW mit Messfunktion

siehe Thema

Popp

POPE004001 Z-Wave Rauchmelder mit Innensirene

siehe Thema

POPE005107 Z-Wave Außensirene

siehe Thema
Alte Firmwareversionen haben einen Bug bei der Übermittlung von negativen Temperaturen. Eine Lösungsvariante über ein userReadings findet sich auch im verlinkten Thema.

POPE009006 Z-Wave Wall Plug Switch

siehe Thema

POPE009402 10Year Smoke Detector

Die erste Firmwareversion hat eine fehlerhafte modelID. Diese Rauchmelder wird dadurch fälschlich als Popp Aussensirene in FHEM angezeigt. Neuere Geräte werden laut Popp mit der korrekten modelID ausgeliefert.

Z-Wave.Me

ZME_RC2 Fernbedienung

siehe Thema
Das Forenthema enthält eine detaillierte Beschreibung der Nutzung der Class MULTI_CHANNEL_ASSOCIATION.


Geräte-Vergleich

Doppel-Relais

Eigenschaft FIBARO Double Switch 2-FGS-223 Qubino Flush 2 relays Philio-PAN04 1
Funktion Doppel-Relais Doppel-Relais Doppel-Relais
Standby-Leistung ca. 0.4W ca. 0.4W ca. 0.5W
Reaktion beim Schalten am Tastereingang schnell, kaum merkliche Verzögerung schnell, kaum merkliche Verzögerung langsam, unangenehm langes drücken des Tasters nötig >1 Sekunde
Geräte in FHEM 3
x Hauptgerät
x.01 Relais 1
x.02 Relais 2
3
x Hauptgerät
x.01 Relais 1
x.02 Relais 2
4
x Hauptgerät
x.01 Relais 1
x.02 Relais 2
x.03 Summengerät (ähnlich Hauptgerät, überflüssig)
Zustand Hauptgerät Oder-Verknüpfung der beiden Relais Oder-Verknüpfung der beiden Relais Oder-Verknüpfung der beiden Relais
Statuswechsel Report vom Gerät zum FHEM ca. 1 Sekunde ca. 3 Sekunden ca. 3-4 Sekunden
Empfänger des Status Reports Hauptgerät und Untergeräte Hauptgerät und Untergeräte Nur Hauptgerät
Aktualisierung der Untergeräte nur bei aktiver Abfrage
Leistungsmessung Separat für Untergeräte Separat für Untergeräte Nur Summe
Sicherung nötig / Strom ja, 2x 6.5A, Summe max 10A ja, max 2x 4A nein, 2x 6.5A

Beim Qubino Flush 2 relays muss eine MULTI_CHANNEL_ASSOCIATION mit dem Controller (Endpoint root) statt einer "normalen" Assoziation gesetzt werden, damit die Status der Untergeräte einzeln signalisert werden:

set associationDel 1 <controllerNodeId> 
set <device> mcaAdd 1 0 <controllerNodeId> 0 

Bei einem FHEM-Updatestand ab 20.09.2019 erfolgt diese Einstellung automatisch.

Links

Allgemein

Informationsquellen zur Einbindung von Command Classes

Offizielle und ausführliche Informationen von Sigma Designs (veröffentlicht am 31.08.2016):

Weitere Informationen (seit Veröffentlichung der Z-Wave Spezifikationen am 31.08.2016 geringe Relevanz)

FAQ

Welche Infos sollten Anfragen im ZWave-Forum enthalten?

  • Anfragen bitte nur zur aktuellsten FHEM-Version: Befehl update ergibt Ausgabe "nothing to do..."
  • detaillierte Beschreibung des Problems
  • beteiligte Komponenten (genaue Bezeichnung und evtl. Link auf Hersteller-Dokumentation)
  • list des jeweiligen FHEM-Devices (Ausgabe von list <device>)
Bitte vor Aufruf des list-Befehls -wenn vorhanden/möglich- folgende Befehle ausführen und Ergebnis abwarten:
  • get <device> associationAll
  • get <device> configAll
  • get <device> versionClassAll
  • get <device> mcaAll
  • get <device> wakeupInterval (nur bei batteriebetriebenen Geräten)
  • passender Ausschnitt aus dem Logfile (siehe Link im FHEM-Menü links) generiert mit den gesetzten Attributen
  • attr <ZWDongle> verbose 5 und
  • attr global mseclog 1

Welche Schritte sind für die Einbindung von ZWave-Geräten in FHEM mindestens durchzuführen?

Voraussetzung: ZWave-Gateway ist erfolgreich eingebunden!

  1. Inklusion des Gerätes
  2. Assoziation der Assoziationsgruppe(n) des Gerätes mit dem Gateway
  3. Konfiguration des Gerätes

Warum bleibt der Status (STATE) des neu inkludierten Gerätes dauerhaft auf "associationAdd <associationGroup> <CtrlNodeId>" stehen?

FHEM setzt das Reading "state", das den STATE bestimmt, nicht bei allen ZWave-Devices mit vordefinierten Standardwerten. Daher bleibt der bei der Inklusion automatisch abgesetzte "associationAdd"-Befehl unter Umständen im STATE stehen, bis der Anwender den STATE über die Vergabe des Attributes stateFormat manuell an seine Bedürfnisse angepasst hat. (weitergehende Info zum state/STATE/stateFormat: DevelopmentState)

Wie können bei mehrkanaligen Aktoren die zusätzlichen Kanäle (>1) angesprochen werden?

  • Bei der Inklusion des Gerätes wird das Hauptdevice mit dem Namen ZWave_<Geräteklasse laut NIF des Gerätes>_<NodeID> und die Devices für alle Kanäle (Endpoints) nach dem Namensschema ZWave_<Geräteklasse laut NIF des Gerätes>_<NodeID>.<EndpointNr> automatisch angelegt. Jedes dieser FHEM-Devices spricht regelmäßig einen bestimmten Kanal des Gerätes an; einige Geräte sprechen mit dem Hauptdevice jedoch das gesamte Gerät mit allen Kanälen an (Bedienungsanleitung beachten).
  • Manuell werden Devices für zusätzliche Kanäle mit Hilfe der Befehle get <device> mcEndpoints und get <device> mcCapability <chid> aus der Class MULTI_CHANNEL ermittelt bzw. einzeln über autocreate angelegt (Details und Beispiel siehe commandref/ZWaveget). Mit dem Befehl set <device> mcCreateAll werden automatisch alle Kanäle des Gerätes durch autocreate als eigene Devices in FHEM angelegt.

Wie kann man die SDK-Version eines Gerätes herausfinden?

Mit FHEM alleine kann eine Grobermittlung der SDK-Version vorgenommen werden, die aber für einige Zwecke bereits ausreichend ist. Soll eine Detailermittlung der genauen SDK-Version erfolgen, dann müssen die mit FHEM ermittelten Werte anhand externer Quellen übersetzt werden.

Grobermittlung

Der Befehl get <ZWDongle> nodeInfo <dezimale nodeId> liefert das Reading nodeInfo_<dezimale nodeId> zurück. Die Angabe im Reading hinter ProtocolVers: lässt grobe Rückschlüsse zu. Mögliche (bekannte) Werte:

  • 2 -> bspw. keine Explorer Frames, keine SUC-Unterstützung (veraltet, keine bekannten Geräte mehr im Handel)
  • SDK5.0x+4.2x -> bspw. keine Explorer Frames, teilweise SUC-Unterstützung
  • SDK4.5x+6.0x -> bspw. Explorer Frames- und SUC-Unterstützung (Reading-Wert wird auch bei SDK 6.5x = Z-Wave Plus angezeigt)

Detailermittlung

Durch den Befehl get <name> version kann man die ZWave-Protokoll-Version von Geräten und Controller abfragen. Mit Unterstützung von Übersetzungstabellen

kann aus der Protokoll-Version das genutzte SDK festgestellt werden.

Beispielsweis entspricht das Reading eines Gerätes "Lib 6 Prot 2.64 App 1.6" dem SDK 5.02 Patch 2 oder eines Controller "Z-Wave 3.41 STATIC_CONTROLLER" dem SDK 6.02.00.

HINWEIS: Bei der Vergabe der Protokoll-Version und zugehörigem SDK gibt es keine erkennbare Logik: Eine höhere Protokoll-Version steht nicht notwendig für eine höheres SDK.

Wie kann eine verschlüsselte Kommunikation unter Nutzung der Command Class SECURITY eingerichtet werden?

Info green.pngFHEM unterstützt derzeit ausschließlich SECURITY 1 und nicht das mit dem SDK 6.7 neu eingeführte SECURITY 2 (S2). Soweit bekannt, sind S2-Geräte rückwärtskompatibel zu SECURITY 1.

Die verschlüsselte Kommunikation zwischen Controller und Endgerät setzt eine secure-Inklusion voraus. Bereits mit der Inklusion wird entschieden, ob die Kommunikation von Controller und Endgerät dauerhaft verschlüsselt oder unverschlüsselt erfolgt. Ist ein Gerät bereits normal inkludiert und entscheidet man sich nachträglich für eine verschlüsselte Kommunikation, so ist das nur möglich, indem das Gerät exkludiert und dann wieder secure inkludiert wird.

Ob die Verschlüsselung bei einem Gerät mit Unterstützung der Command Class SECURITY genutzt werden soll, sollte genau überlegt werden. Die Verschlüsselung führt zu einem deutlich größeren Funkverkehr zur Ausführung eines Befehls und teilweise auch zu spürbaren Latenzen.

Vorarbeiten:

  • Das Perl-Modul Crypt-Rijndael muss installiert sein.
  • Das Attribut networkKey muss mit einem 32-Zeichen langen Hexzahl beim ZWDongle angelegt werden. Dieser Schlüssel sollte nicht veröffentlicht werden und auch zusätzlich separat (bspw. auf Papier) festgehalten werden. Bei Verlust des Attributes und Schlüssels ist eine Kommunikation nur nach erneuter Inklusion möglich.

Ablauf der secure-Inklusion:

  • Controller in den Modus zur secure-Inklusion schalten:
set <ZWDongle> addNode onSec für die Standard-secure-Inklusion
oder alternativ
set <ZWDongle> addNode onNwSec für die Nework-Wide-secure-Inklusion
  • Gerät gemäß Handbuch in den Modus zur secure-Inklusion bringen (teilweise ist jeweils für secure- und normale Inklusion ein anderes Vorgehen notwendig!)
  • Das Gerät sollte jetzt automatisch erkannt und das FHEM-Device durch autocreate angelegt werden. Die secure-inkludierten Geräte haben ein zusätzliches Attribut secure_classes in dem die Command Classes deren Kommunikation verschlüsselt abläuft aufgelistet sind. Nicht in diesem Attribut, aber in classes aufgeführte Command Classes wickeln die Kommunikation weiterhin unverschlüsslt ab.
  • Inklusionsmodus des Controllers ausschalten:
set <ZWDongle> addnode off
  • Das Vorgehen in FHEM unterscheidet sich von nun an nicht von normal (unverschlüsselt) inkludierten Geräten. Die Verschlüsselung läuft für den Anwender transparent ab. Darum anschließend Assoziation und Konfiguration vornehmen.

Wie kann man ohne Exklusion Nodes des Controllers löschen?

HINWEIS: Geräte sollten grundsätzlich immer über eine Exklusion aus der Nodelist des Controllers gelöscht werden. Das nachfolgend geschilderte Vorgehen ist nur in Sonderfällen (bspw. Gerätedefekt, gebraucht gekauftes Gateway) anzuwenden.

Nicht mehr zu erreichende/reagierende Nodes (Geräte) können manuell mit dem Befehl removeFailedNode gelöscht werden. Dazu muss sich der betroffene Node auf der FailedNodeList des Controllers befinden. Auf die FailedNodeList kommen netzbetriebene Geräte automatisch, wenn sie vom Controller nicht mehr per Funk erreicht werden. Batteriebetriebene Geräte müssen manuell auf die FailedNodelist gesetzt werden, da der Controller nicht feststellen kann, ob sie nur langfristig "schlafen".

Der Befehl removeFailedNode löscht nur Nodes auf der FailedNodeList, die erst vor Kurzem nicht erreicht werden konnten. Darum muss sowohl das manuelle Verschieben von batteriebetriebenen als auch das Nicht-Erreichen der netzbetriebenen Geräte erst Kurz vor Aufruf des removeFailedNode-Befehls erfolgt sein.

Vorgehensweise für den Node <NodeId>:

  1. An den betroffenen Node eine Telegramm mit set <ZWDongle> sendNIF <NodeId> verschicken, um ihn auf FailedNodeList zu verschieben bzw. Zeitstempel zu aktualisieren.
  2. Abfragen, ob der Node auf der FailedNodeList steht: get <ZWDongle> isFailedNode <NodeId>. Wenn der Rückgabewert der Abfrage "yes" ist, steht der Node korrekt auf der FailedNodeList und kann mit removeFailedNode gelöscht werden.
  3. Befehl zum Löschen des Nodes absetzen: set <ZWDongle> removeFailedNode <NodeId>. Der Befehl testet vor dem Löschen noch einmal, dass der Node nicht erreicht werden kann und entfernt erst dann den Node.
  4. Prüfen, der Ergebnisse des removeFailedNode-Befehls im Log oder Event monitor. Die verschiedenen Ergebnisse werden durch die in der commandref dokumentierten Events signalisiert. Tritt das Ergebnis "failedNodeRemoveProcessBusy" mehrfach hintereinander auf, muss das ZWDongle kurz stromlos gemacht werden.
  5. Prüfen, ob der Node nicht mehr auf der Nodelist des Controllers ist: get <ZWDongle> nodeList

siehe auch Beitrag

Wie ist der einfachste Weg ein (defektes) Gerät durch ein gleiches Ersatzgerät auszutauschen?

Tauscht man ein defektes Gerät durch ein gleiches Ersatzgerät und inkludiert das Ersatzgerät per addNode, so erhält das Ersatzgerät eine neue NodeId. Soll das Ersatzgerät die gleiche NodeId wie das alte Gerät erhalten, so muss statt addNode der Befehl replaceFailedNode zur Inklusion des Ersatzgerätes (=gleiches Modell) verwendet werden.

Vorgehensweise für den Node <NodeId>:

  1. sofern das alte Gerät noch ansprechbar ist, die Konfiguration und Assoziationen abfragen, damit man die Werte im Ersatzgerät einfach wieder setzen kann:
    1. get <device> configAll
    2. get <device> associationAll
  2. defektes Gerät aus- und neues einbauen
  3. Befehl set <ZWDongle> sendNIF <NodeId> absetzen, damit das Dongle die NodeId auf die FailedNodeList setzt.
  4. Abfragen, ob der Node auf der FailedNodeList steht: get <ZWDongle> isFailedNode <NodeId>. Wenn der Rückgabewert der Abfrage "yes" ist, steht der Node korrekt auf der FailedNodeList und das Ersatzgerät kann mit replaceFailedNode inkludiert werden.
  5. set <zwdongle> replaceFailedNode <NodeId> für die NodeId des defekten Gerätes aufrufen und das Ersatzgerät in den Inklusionsmodus bringen
  6. Korrekte Inklusion prüfen und beim alten Aktor ausgelesene Werte beim neuen Aktor wieder setzen.

Bei einer Inklusion wird eine durch Exklusion/removeFailedNode frei gewordenen NodeId nicht mehr vergeben. Ist das korrekt?

Ja, das ist richtig.

Bei der Inklusion über addNode vergibt der Controller die höchste bisher noch nie verwendete NodeID. Durch Exklusion oder removeFailedNode frei gewordene NodeIDs werden hierbei zunächst nicht erneut vergeben. Diese frei gewordenen NodeIds werden bei Inklusionen in aufsteigender Reihenfolge erst wieder vergeben, nachdem die höchste verfügbare NodeId (232?) inkludiert wurde. Sie sind somit grundsätzlich nicht verloren.

Welche Funktion haben die XML-Config-Dateien in FHEM?

In den XML-Config-Dateien sind Informationen zu einzelnen ZWave-Geräten enthalten, die der Erleichterung der Gerätenutzung und -einbindung in FHEM dienen. Dies sind unter anderem Erläuterungen zu den Parameternummer/-werten, Assoziationsgruppen und Besonderheiten eines Gerätes. Ob eine zum Zwave-Gerät passende XML-Config Datei existiert, wird im Rahmen der Inklusion oder durch manuellen Aufruf des Befehls get <name> model ermittelt. Wird eine passende XML-Config-Datei gefunden, wird sie automatisch in FHEM eingebunden. Das Reading modelConfig enthält dann den zugehörigen XML-Config-Dateinamen. Stehen keine XML-Config-Informationen bereit, enthält das Reading modelConfig den Wert "unknown". Die Funktionsfähigkeit von FHEM mit ZWave-Geräten ist auch bei fehlender XML-Config-Datei gegeben. Es gibt dadurch keine funktionalen Einschränkungen in FHEM; es entfallen "nur" Erleichterungen und es sind unter Umständen mehr manuelle Schritte bei der Gerätenutzung/-einbindung notwendig.

Erleichterungen bei vorhandener XML-Config für ein ZWave-Gerät:

  • Bei der Inklusion:
    • Assoziationen mit dem Controller bei von Gruppe 1 abweichenender Assoziationsgruppe werden automatisch gesetzt
    • vom NIF nicht gemeldete, aber vom Gerät unterstützte Classes, werden im Attribut classes ergänzt
  • Bei der Konfiguration:
    • die Parameternummern stehen als configXY-Befehle zur Verfügung und werden mit Hilfetexten -auch zu den Parameterwerten- in der Detailansicht des FHEM-Device erläutert.

HINWEIS: Bitte auch bei vorhandener XML-Config-Datei nach der Inklusion und bei der Konfiguration die Assoziationen und Parameter prüfen. Von den eigenen Vorstellungen abweichende Vorgaben oder gar Fehler in der Config-Datei können nie ausgeschlossen werden. Fehler bitte im Forum (ZWave) melden.

Wie können fehlende XML-Config-Informationen für mein ZWave-Gerät in FHEM eingebunden werden?

Die XML-Config-Informationen von FHEM sind in folgenden Dateien im Ordner fhem/FHEM/lib gespeichert:

  • openzwave_manufacturer_specific.xml
  • openzwave_deviceconfig.xml.gz
  • fhem_zwave_deviceconfig.xml.gz

Die in den Dateien enthaltenen Informationen beruhen in großen Teilen auf Daten von openzwave und übernehmen daher das openzwave-Datenformat, das unter https://github.com/OpenZWave/open-zwave/wiki/Adding-Devices näher beschrieben wird.

Die Datei "openzwave_manufacturer_specific.xml" enthält die eindeutige Kennung des ZWave-Gerätes, die in FHEM nach Aufruf des Befehls get <name> model im Reading modelId des FHEM-ZWave-Devices steht. Weiterhin wird der Klartextname dieses Gerätes, der im Reading model angezeigt werden soll, festgelegt. Zudem wird der Dateiname der eigentlichen XML-Config-Datei für das ZWave-Gerät angegeben, der später informativ im Reading modelConfig steht.

Die Dateien "openzwave_deviceconfig.xml.gz" und "fhem_zwave_deviceconfig.xml.gz" enthalten in komprimierter Form die eigentlichen XML-Config-Dateien für die ZWave-Geräte. FHEM durchsucht beide Dateien nach der passenden XML-Config-Datei. Ist in beiden Dateien eine XML-Config für ein Gerät vorhanden, so werden die XML-Daten aus der "fhem_zwave_deviceconfig.xml.gz" bevorzugt.

Falls ein ZWave-Gerät von FHEM nicht erkannt wird, bitte auf folgenden Seiten nachschauen, ob es schon XML-Config-Dateien gibt, die nur nicht in FHEM eingebunden sind:

  1. https://github.com/OpenZWave/open-zwave/tree/master/config in manufacturer_specific.xml und dem herstellerspezifischen Unterordner
  2. https://github.com/jeedom/plugin-openzwave/tree/beta/resources/openzwaved/config in manufacturer_specific.xml und dem herstellerspezifischen Unterordner
  3. http://www.cd-jackson.com/index.php/zwave/zwave-device-database

Sofern auf den genannten Seiten Daten vorhanden sind, postet eine Aktualisierungsbitte mit genauem Link zur entsprechenden Seite im Forum (ZWave).

Gibt es auf keiner der Seiten Infos zu dem Gerät, dann entsprechend https://github.com/OpenZWave/open-zwave/wiki/Adding-Devices die XML-Config-Datei für das Gerät erstellen und unkomprimiert zusammen mit der zu ergänzenden Info für die Datei "openzwave_manufacturer_specific.xml" im Forum (ZWave) zur Verfügung stellen.

Wie führt man eine Komplett-Sicherung der ZWave-Installation durch?

Zu einer Komplett-Sicherung der ZWave-Konfiguration gehören:

1. Backup der FHEM-Installation

und

2. Backup des NVRAM des Controllers

Es genügt nicht nur die FHEM-Installation/Konfiguration zu sichern, da der Controller im NVRAM Daten über HomeID, NodeIDs usw. speichert, die in der FHEM-Installation nicht enthalten sind und auch nicht durch FHEM rekonstruierbar sind.


zu 2.) Backup des NVRAM des Controllers

Einige Controllerhersteller bieten eine eigenständige Software zum Backup/Restore an (siehe Hinweise zu den Controllern unter #Autocreate_des_Gateways).

FHEM kann mit den ZWDongle-Befehlen backupCreate das NVRAM der Controller sichern und mit backupRestore zurückschreiben. Da das Speicherlayout des NVRAM unter anderem von Controller-Hersteller, SDK und Firmwareversion abhängig sein kann, sollte man die Sicherung und Wiederherstellung des eigenen Controllers (auf eigenes Risiko) testen und sinnvollerweise einen gleichen Ersatzcontroller wie den Controller des Produktivsystem besitzen. Erfolgreiche Sicherung/Wiederherstellung wurde im Forum von den ZWavePlus-Controllern UZB1 (256k), Razberry (256k), Vision ZU 1401-5 EU (128k)und AEOTEC Z-Stick Gen5 (256k) berichtet. (Weitergehende Infos - neben der commandref - im Forum: Thema, Thema, Thema)

Wie kann ich zur Fortentwicklung der ZWave-Module beitragen?

  • Erfolgreichen Einsatz von neuen/bisher nicht gemeldeten ZWave-Geräten im Forum mitteilen
  • Codeschnipsel und Ideen im Forum posten
  • Fehler und Probleme im Forum melden
  • Patches für 00_ZWDongle.pm und 10_ZWave.pm erstellen
  • Wiki: Ergänzungen und Korrekturen vornehmen; neue Geräte ins Wiki aufnehmen; Codeschnipsel und Beispiele einpflegen

Wie wird ein fehlendes Kernelmodul (Fritzbox) eingebunden?

Auf der Fritzbox (und evtl. auch anderen Systemen) muss sichergestellt werden, dass das Kernelmodul für das Gateway geladen wird. Ansonsten scheitert die Einbindung des Gateways in FHEM.

Für den Aeon Labs Z-Stick muss beispielsweise auf der Fritzbox das Kernelmodul cp2101.ko geladen werden. Diese Datei ist bei einer FHEM und FritzBox 7390 Installation über das Image von fhem.de bereits enthalten. Um den Aeon Labs Z-Stick zu verwenden, muss dieses Kernelmodul vor oder beim Starten des FHEM-Servers geladen sein. Dies erreicht man durch einen Eintrag in der Datei startfhem.

Die entsprechende Zeile kann direkt unterhalb der modprobe Anweisungen eingefügt werden.

insmod $home/lib/cp2101.ko

Nach einem FHEM-Neustart sollte das Gateway (der USB Stick) nun erkannt werden.

Wie ist der Aufbau der Z-Wave Messages bzw. wie finde ich bei einem Sendefehler die NodeId des Empfängers heraus?

Es könnte natürlich hin und wieder vorkommen, dass man im FHEM-Log folgende Fehler vorfindet:

ZWDongle_ProcessSendStack: no ACK, resending message 010a00130603320110259277

In diesem Fall gab es aus irgendeinem Grund einmalig das Problem, dass der Empfang einer Nachricht vom Empfänger nicht bestätigt wurde. Will man dem auf die Spur kommen, so wäre es natürlich von Vorteil, die NodeId des Empfängers herauszufinden. Also muss man sich die Message näher anschauen:

010a00130603320110259277

  • 01: data to controller
  • 0a: length of msg
  • 00: ?
  • 13: ZW_SEND_DATA
  • 06: NodeId
  • 03: length of msg
  • 32: Command Class 32 (METER, siehe %zwave_class in 10_ZWave.pm)
  • 01: METER get scale command
  • 10: scale parameter
  • 25: send flags, explorer frames on
  • 92: callbackId (um ACK zu identifizieren)
  • 77: checkSum

In diesem Fall hat der Z-Wave-Controller 01 eine Nachricht an die NodeId 06 geschickt, welche vom Node nicht bestätigt wurde.