FHEMWiki - Benutzerbeiträge [de]

UserReadings

2023-03-19T19:25:26Z

Markus1407: /* Trigger */

{{SEITENTITEL:userReadings}} 

Über das Attribut [[userReadings]] können bei einem Device benutzerdefinierte [[reading|readings]] einschließlich der Anweisungen zum Befüllen derselben festgelegt werden. Das können zum Einen Formatänderungen ("sprintf"), oder aber auch durch die ''Modifier''
* difference
* differential
* integral
* offset
* monotonic
gesteuerte Berechnungen sein.

== Syntax ==
{{Randnotiz|RNTyp=y|RNText='''Geändertes Verhalten - bitte beachten'''
Im April 2016 hat sich die Verarbeitung des ''Triggers'' dahingehend geändert, dass die Trigger-Spezifikation jetzt als [[Regulärer Ausdruck]] interpretiert wird, damit also z.B. ein <code>avgTemp:temperature</code> geändert werden muss in <code>avgTemp:temperature.*</code>.

Technische Details dazu wurden in {{Link2Forum|Topic=52165|LinkText=diesem Forenthread}} diskutiert.}}
Siehe {{Link2CmdRef|Anker=readingFnAttributes}}.

* Bei Eingabe im Editor-Feld müssen mehrere Befehle mit einem ";" getrennt werden, bei Änderung in der Eingabezeile sind zwei ";" notwendig.
* Die Variable, dessen Wert man im Reading haben möchte, kann man einfach ans Ende stellen[https://perldoc.perl.org/functions/return.html]
* mehrere UserReadings werden durch Komma getrennt.

:<code>myreading {my $v = ReadingsVal($name,"actuation","error")+62; fhem("set PID desired $v"); $v},</code>
:<code>myreading2 {my $v = ReadingsVal($name,"actuation","error")+62; fhem("set PID2 desired $v"); $v}</code>

== Beispiele ==
{{Randnotiz|RNTyp=g|RNText=Die nachfolgenden Beispiele sind ohne Trigger notiert. In der Regel sollte jedoch geprüft werden, ob nicht ein solcher Trigger gesetzt werden kann. Dies ist insbesondere in den Fällen sinnvoll, in denen in einem Gerät sehr viele Readings vorhanden sind, die ggf. zu unterschiedlichen Zeitpunkten aktualisiert werden. Das erste Beispiel wäre daher besser so zu schreiben:<br><code>attr ElbePegelSchoena userReadings Pegel:value.* { ReadingsVal("ElbePegelSchoena","value",0) }</code> }}
==== Ein Reading soll einen anderen Namen bekommen ====
Das vorhandene Reading "value" des Devices "ElbePegelSchoena" soll künftig in "Pegel" umbenannt werden. Das geht nicht. Man kann aber ein neues Reading "Pegel" mit genau gleichem Wert erzeugen:
:<code>attr ElbePegelSchoena userReadings Pegel { ReadingsVal("ElbePegelSchoena","value",0) }</code>

==== Ausgabe eines Homematic 3-State Fenstersensor als Zahl für Visualisierung mit Icons ====
:<code><nowiki>attr HM_XXXXXX userReadings Statenum {if(ReadingsVal("HM_XXXXXX","state","") eq "closed") {return 0} elsif (ReadingsVal("HM_XXXXXX","state","") eq "tilted") {return 1} elsif (ReadingsVal("HM_XXXXXX","state","") eq "open") {return 2} else {return -1}}</nowiki></code>

==== Ausgabe als Moving Average und Formatierung mit sprintf ====
:<code>attr HZ_EINSTRAHLUNG_RAW userReadings Einstr_Mean.av {sprintf("%.1f",movingAverage("HZ_EINSTRAHLUNG_RAW","reading",1200))}</code>

==== Umrechnung der Temperatur (durch 10 geteilt) und Einheit [°C] angehängt ====
:<code>attr HZ_EINSTRAHLUNG_T userReadings SolarTemp {ReadingsVal("HZ_EINSTRAHLUNG_T","reading",0)/10 ." °C"}</code>

==== Batterieüberwachung durch Erweiterung mit notify und userReading ====
... ist im Detail auf der Seite [[Batterieüberwachung]] beschrieben.

==== Integralfunktion - integral ====
Die Verwendung der Integralfunktion bei ''userReadings'' ist ausführlich im Forenbeitrag {{Link2Forum|Topic=26300|Message=193084|LinkText=Integralfunktion bei UserReadings}} erklärt.

==== Trigger ====
Die Trigger-Regex muss ein Event matchen inklusive Wert. Hier soll ''countTotalSum'' um den Wert im Reading ''count'' erhöht werden, natürlich nur wenn ein Event für das Reading ''count'' eintrifft, damit der Wert nur einmal hinzu addiert wird. (Alle anderen Events werden ignoriert.) Hier ist auf das Wortende zu achten "'''\b'''" in der Regex, damit z.B. Events für ''count1'', ''count2'', ... keinen Trigger auslösen. (Hinweis: Beim bilden der Summe kann die Benutzung von event-on-change-reading zu falschen Ergebnissen führen.)
:<code>attr GasPulseCounter userReadings countTotalSum:count\b.* {my $val=ReadingsVal($name,"countTotalSum",0)+ReadingsVal($name,"count",0);;$val}</code>

Hier werden einfach die Anzahl der Events für ''count'' gezählt. Events für Readingnamen, welche ledichglich mit ''count'' beginnen werden ignoriert, wegen "\b".
:<code>attr GasPulseCounter userReadings inc:count\b.* {my $val=ReadingsVal($name,"inc",0)+1;;$val}</code>

Zusätzlich kann der Trigger auf einen bestimmten Value beschränkt werden. Hier wird jedes auftreten des Wertes "5" gezählt.
:<code>attr GasPulseCounter userReadings inc:count:.5 {my $val=ReadingsVal($name,"inc",0)+1;;$val}</code>

== Links ==
* {{Link2CmdRef|Lang=de|Anker=userReadings}} - userReadings

[[Kategorie:Attribut (allgemeingültig)]]

Save

2023-03-19T15:20:49Z

Markus1407:

{{Infobox Modul
|ModPurpose=Speichert Konfigurationsänderungen
|ModType=cmd
|ModCmdRef=save
|ModTechName=fhem.pl
|ModOwner=rudolfkoenig/Rudolfkoenig ({{Link2FU|8|Forum}}/[[Benutzer Diskussion:Rudolfkoenig|Wiki]])
}}

Der Befehl [[save]] gehört zu den FHEM-eigenen Befehlen. Mit ihm werden Änderungen der [[Konfiguration]] dauerhaft gespeichert.

Auch das Anklicken der Schaltfläche '''''Save config''''' (siehe [[Konfiguration#Bearbeitung der Konfiguration|Beispielabbildung]]) resultiert in der Ausführung dieses Befehls.

=== Config-file (Speichern der Konfiguration) ===
Im config-file wird die Konfiguration der Objekte gespeichert. Hierfür sollte folgendes Attribut angelegt sein:

:<code>attr global configfile fhem.cfg</code>

==== Protokollierung von Konfigurationsänderungen ====
Um Konfigurationsänderungen, die über das [[FHEMWEB|Webinterface]] gemacht wurden, zu protokollieren, kann mit (z.B.) dem folgenden Befehl eine spezielle [[FileLog|Logdatei]] angelegt werden:
:<code>define myConfigLog FileLog ./log/configChangeHistory.log global:(MODIFIED|DEFINED|ATTR|RENAMED|DELETED).*</code>
Wie bei Log Dateien üblich bestimmt der angegebene [[Regulärer Ausdruck|Reguläre Ausdruck]] den Umfang der Protokollierung, im gegebenen Beispiel würden also Neudefinitionen, Löschungen, Umbenennungen und Attributänderungen protokolliert.

Um einen Block von Änderungen in der Logdatei zu kommentieren, kann beispielsweise das [[Attribut]] "comment" des betreffenden Geräts angelegt bzw. geändert werden.

=== State-file (Speichern der Zustände) ===
https://fhem.de/commandref_DE.html#statefile

Die internen Zustände (Readings) werden im statefile gespeichert. Voraussetzung ist die Definition des Attributes
:<code>attr global statefile ./fhem.save</code>

==== Periodisches Speichern des Statefiles ====
Beispiel:
Statefile alle 15 Minuten speichern. (nicht die Konfiguration). Somit bleiben interne Zustände erhalten, wenn fhem nicht sauber beendet wird, z.B. beim Ausschalten des Systems (Raspberry Pi).

:<code>defmod saveStateFile at +*00:15:00 {WriteStatefile()}</code>

Siehe auch: https://forum.fhem.de/index.php?topic=71699.0

== Links ==
* Forenthema zur {{Link2Forum|Topic=112517|LinkText=Protokollierung von Konfigurationsänderungen}}

Save

2023-03-19T15:18:48Z

Markus1407:

{{Infobox Modul
|ModPurpose=Speichert Konfigurationsänderungen
|ModType=cmd
|ModCmdRef=save
|ModTechName=fhem.pl
|ModOwner=rudolfkoenig/Rudolfkoenig ({{Link2FU|8|Forum}}/[[Benutzer Diskussion:Rudolfkoenig|Wiki]])
}}

Der Befehl [[save]] gehört zu den FHEM-eigenen Befehlen. Mit ihm werden Änderungen der [[Konfiguration]] dauerhaft gespeichert.

Auch das Anklicken der Schaltfläche '''''Save config''''' (siehe [[Konfiguration#Bearbeitung der Konfiguration|Beispielabbildung]]) resultiert in der Ausführung dieses Befehls.

=== Config-file (Speichern der Konfiguration) ===
Im config-file wird die Konfiguration der Objekte gespeichert. Hierfür sollte folgendes Attribut angelegt sein:

:<code>attr global configfile fhem.cfg</code>

==== Protokollierung von Konfigurationsänderungen ====
Um Konfigurationsänderungen, die über das [[FHEMWEB|Webinterface]] gemacht wurden, zu protokollieren, kann mit (z.B.) dem folgenden Befehl eine spezielle [[FileLog|Logdatei]] angelegt werden:
:<code>define myConfigLog FileLog ./log/configChangeHistory.log global:(MODIFIED|DEFINED|ATTR|RENAMED|DELETED).*</code>
Wie bei Log Dateien üblich bestimmt der angegebene [[Regulärer Ausdruck|Reguläre Ausdruck]] den Umfang der Protokollierung, im gegebenen Beispiel würden also Neudefinitionen, Löschungen, Umbenennungen und Attributänderungen protokolliert.

Um einen Block von Änderungen in der Logdatei zu kommentieren, kann beispielsweise das [[Attribut]] "comment" des betreffenden Geräts angelegt bzw. geändert werden.

=== State-file (Speichern der Zustände) ===
https://fhem.de/commandref_DE.html#statefile

Die internen Zustände (Readings) werden im statefile gespeichert. Voraussetzung ist die Definition des Attributes
:<code>attr global statefile ./fhem.save</code>

==== Periodisches Speichern des Statefiles ====
Beispiel:
Statefile alle 15 Minuten speichern. (nicht die Konfiguration). Somit bleiben interne Zustände erhalten, wenn fhem nicht sauber beendet wird, z.B. beim Ausschalten des Systems (Raspberry Pi).

:<code>defmod saveStateFile at +*00:15:00 {WriteStatefile()}</code>

== Links ==
* Forenthema zur {{Link2Forum|Topic=112517|LinkText=Protokollierung von Konfigurationsänderungen}}

Save

2023-03-19T14:58:43Z

Markus1407: Statefile hinzugefügt

{{Infobox Modul
|ModPurpose=Speichert Konfigurationsänderungen
|ModType=cmd
|ModCmdRef=save
|ModTechName=fhem.pl
|ModOwner=rudolfkoenig/Rudolfkoenig ({{Link2FU|8|Forum}}/[[Benutzer Diskussion:Rudolfkoenig|Wiki]])
}}

Der Befehl [[save]] gehört zu den FHEM-eigenen Befehlen. Mit ihm werden Änderungen der [[Konfiguration]] dauerhaft gespeichert.

Auch das Anklicken der Schaltfläche '''''Save config''''' (siehe [[Konfiguration#Bearbeitung der Konfiguration|Beispielabbildung]]) resultiert in der Ausführung dieses Befehls.

== Protokollierung von Konfigurationsänderungen ==
Um Konfigurationsänderungen, die über das [[FHEMWEB|Webinterface]] gemacht wurden, zu protokollieren, kann mit (z.B.) dem folgenden Befehl eine spezielle [[FileLog|Logdatei]] angelegt werden:
:<code>define myConfigLog FileLog ./log/configChangeHistory.log global:(MODIFIED|DEFINED|ATTR|RENAMED|DELETED).*</code>
Wie bei Log Dateien üblich bestimmt der angegebene [[Regulärer Ausdruck|Reguläre Ausdruck]] den Umfang der Protokollierung, im gegebenen Beispiel würden also Neudefinitionen, Löschungen, Umbenennungen und Attributänderungen protokolliert.

Um einen Block von Änderungen in der Logdatei zu kommentieren, kann beispielsweise das [[Attribut]] "comment" des betreffenden Geräts angelegt bzw. geändert werden.

== Statefile (Speichern der Zustände) ==
https://fhem.de/commandref_DE.html#statefile

Die internen Zustände (Readings) werden im statefile gespeichert. Voraussetzung ist die Definition des Attributes
:<code>attr global statefile ./fhem.save</code>

== Periodisches Speichern des Statefiles ==
Beispiel: Statefile alle 15 Minuten speichern. (nicht die Konfiguration)
:<code>defmod saveStateFile at +*00:15:00 {WriteStatefile()}</code>

== Links ==
* Forenthema zur {{Link2Forum|Topic=112517|LinkText=Protokollierung von Konfigurationsänderungen}}

UserReadings

2023-03-17T12:54:01Z

Markus1407: /* Trigger */

{{SEITENTITEL:userReadings}} 

Über das Attribut [[userReadings]] können bei einem Device benutzerdefinierte [[reading|readings]] einschließlich der Anweisungen zum Befüllen derselben festgelegt werden. Das können zum Einen Formatänderungen ("sprintf"), oder aber auch durch die ''Modifier''
* difference
* differential
* integral
* offset
* monotonic
gesteuerte Berechnungen sein.

== Syntax ==
{{Randnotiz|RNTyp=y|RNText='''Geändertes Verhalten - bitte beachten'''
Im April 2016 hat sich die Verarbeitung des ''Triggers'' dahingehend geändert, dass die Trigger-Spezifikation jetzt als [[Regulärer Ausdruck]] interpretiert wird, damit also z.B. ein <code>avgTemp:temperature</code> geändert werden muss in <code>avgTemp:temperature.*</code>.

Technische Details dazu wurden in {{Link2Forum|Topic=52165|LinkText=diesem Forenthread}} diskutiert.}}
Siehe {{Link2CmdRef|Anker=readingFnAttributes}}.

* Bei Eingabe im Editor-Feld müssen mehrere Befehle mit einem ";" getrennt werden, bei Änderung in der Eingabezeile sind zwei ";" notwendig.
* Die Variable, dessen Wert man im Reading haben möchte, kann man einfach ans Ende stellen[https://perldoc.perl.org/functions/return.html]
* mehrere UserReadings werden durch Komma getrennt.

:<code>myreading {my $v = ReadingsVal($name,"actuation","error")+62; fhem("set PID desired $v"); $v},</code>
:<code>myreading2 {my $v = ReadingsVal($name,"actuation","error")+62; fhem("set PID2 desired $v"); $v}</code>

== Beispiele ==
{{Randnotiz|RNTyp=g|RNText=Die nachfolgenden Beispiele sind ohne Trigger notiert. In der Regel sollte jedoch geprüft werden, ob nicht ein solcher Trigger gesetzt werden kann. Dies ist insbesondere in den Fällen sinnvoll, in denen in einem Gerät sehr viele Readings vorhanden sind, die ggf. zu unterschiedlichen Zeitpunkten aktualisiert werden. Das erste Beispiel wäre daher besser so zu schreiben:<br><code>attr ElbePegelSchoena userReadings Pegel:value.* { ReadingsVal("ElbePegelSchoena","value",0) }</code> }}
==== Ein Reading soll einen anderen Namen bekommen ====
Das vorhandene Reading "value" des Devices "ElbePegelSchoena" soll künftig in "Pegel" umbenannt werden. Das geht nicht. Man kann aber ein neues Reading "Pegel" mit genau gleichem Wert erzeugen:
:<code>attr ElbePegelSchoena userReadings Pegel { ReadingsVal("ElbePegelSchoena","value",0) }</code>

==== Ausgabe eines Homematic 3-State Fenstersensor als Zahl für Visualisierung mit Icons ====
:<code><nowiki>attr HM_XXXXXX userReadings Statenum {if(ReadingsVal("HM_XXXXXX","state","") eq "closed") {return 0} elsif (ReadingsVal("HM_XXXXXX","state","") eq "tilted") {return 1} elsif (ReadingsVal("HM_XXXXXX","state","") eq "open") {return 2} else {return -1}}</nowiki></code>

==== Ausgabe als Moving Average und Formatierung mit sprintf ====
:<code>attr HZ_EINSTRAHLUNG_RAW userReadings Einstr_Mean.av {sprintf("%.1f",movingAverage("HZ_EINSTRAHLUNG_RAW","reading",1200))}</code>

==== Umrechnung der Temperatur (durch 10 geteilt) und Einheit [°C] angehängt ====
:<code>attr HZ_EINSTRAHLUNG_T userReadings SolarTemp {ReadingsVal("HZ_EINSTRAHLUNG_T","reading",0)/10 ." °C"}</code>

==== Batterieüberwachung durch Erweiterung mit notify und userReading ====
... ist im Detail auf der Seite [[Batterieüberwachung]] beschrieben.

==== Integralfunktion - integral ====
Die Verwendung der Integralfunktion bei ''userReadings'' ist ausführlich im Forenbeitrag {{Link2Forum|Topic=26300|Message=193084|LinkText=Integralfunktion bei UserReadings}} erklärt.

==== Trigger ====
Die Trigger-Regex muss ein Event matchen inklusive Wert. Hier soll ''countTotalSum'' um den Wert im Reading ''count'' erhöht werden, natürlich nur wenn ein Event für das Reading ''count'' eintrifft, damit der Wert nur einmal hinzu addiert wird. (Alle anderen Events werden ignoriert.) Hier ist auf das Wortende zu achten "'''\b'''" in der Regex, damit z.B. Events für ''count1'', ''count2'', ... keinen Trigger auslösen. (Hinweis: Beim bilden der Summe kann die Benutzung von event-on-change-reading zu falschen Ergebnissen führen.)
:<code>attr GasPulseCounter userReadings countTotalSum:count\b.* {my $val=ReadingsVal($name,"countTotalSum",0)+ReadingsVal($name,"count",0);;$val}</code>

Hier werden einfach die Anzahl der Events für ''count'' gezählt. Events für Readingnamen, welche ledichglich mit ''count'' beginnen werden ignoriert, wegen "\b".
:<code>attr GasPulseCounter userReadings inc:count\b.* {my $val=ReadingsVal($name,"inc",0)+1;;$val}</code>

== Links ==
* {{Link2CmdRef|Lang=de|Anker=userReadings}} - userReadings

[[Kategorie:Attribut (allgemeingültig)]]

UserReadings

2023-03-17T12:50:48Z

Markus1407: /* Trigger */

{{SEITENTITEL:userReadings}} 

Über das Attribut [[userReadings]] können bei einem Device benutzerdefinierte [[reading|readings]] einschließlich der Anweisungen zum Befüllen derselben festgelegt werden. Das können zum Einen Formatänderungen ("sprintf"), oder aber auch durch die ''Modifier''
* difference
* differential
* integral
* offset
* monotonic
gesteuerte Berechnungen sein.

== Syntax ==
{{Randnotiz|RNTyp=y|RNText='''Geändertes Verhalten - bitte beachten'''
Im April 2016 hat sich die Verarbeitung des ''Triggers'' dahingehend geändert, dass die Trigger-Spezifikation jetzt als [[Regulärer Ausdruck]] interpretiert wird, damit also z.B. ein <code>avgTemp:temperature</code> geändert werden muss in <code>avgTemp:temperature.*</code>.

Technische Details dazu wurden in {{Link2Forum|Topic=52165|LinkText=diesem Forenthread}} diskutiert.}}
Siehe {{Link2CmdRef|Anker=readingFnAttributes}}.

* Bei Eingabe im Editor-Feld müssen mehrere Befehle mit einem ";" getrennt werden, bei Änderung in der Eingabezeile sind zwei ";" notwendig.
* Die Variable, dessen Wert man im Reading haben möchte, kann man einfach ans Ende stellen[https://perldoc.perl.org/functions/return.html]
* mehrere UserReadings werden durch Komma getrennt.

:<code>myreading {my $v = ReadingsVal($name,"actuation","error")+62; fhem("set PID desired $v"); $v},</code>
:<code>myreading2 {my $v = ReadingsVal($name,"actuation","error")+62; fhem("set PID2 desired $v"); $v}</code>

== Beispiele ==
{{Randnotiz|RNTyp=g|RNText=Die nachfolgenden Beispiele sind ohne Trigger notiert. In der Regel sollte jedoch geprüft werden, ob nicht ein solcher Trigger gesetzt werden kann. Dies ist insbesondere in den Fällen sinnvoll, in denen in einem Gerät sehr viele Readings vorhanden sind, die ggf. zu unterschiedlichen Zeitpunkten aktualisiert werden. Das erste Beispiel wäre daher besser so zu schreiben:<br><code>attr ElbePegelSchoena userReadings Pegel:value.* { ReadingsVal("ElbePegelSchoena","value",0) }</code> }}
==== Ein Reading soll einen anderen Namen bekommen ====
Das vorhandene Reading "value" des Devices "ElbePegelSchoena" soll künftig in "Pegel" umbenannt werden. Das geht nicht. Man kann aber ein neues Reading "Pegel" mit genau gleichem Wert erzeugen:
:<code>attr ElbePegelSchoena userReadings Pegel { ReadingsVal("ElbePegelSchoena","value",0) }</code>

==== Ausgabe eines Homematic 3-State Fenstersensor als Zahl für Visualisierung mit Icons ====
:<code><nowiki>attr HM_XXXXXX userReadings Statenum {if(ReadingsVal("HM_XXXXXX","state","") eq "closed") {return 0} elsif (ReadingsVal("HM_XXXXXX","state","") eq "tilted") {return 1} elsif (ReadingsVal("HM_XXXXXX","state","") eq "open") {return 2} else {return -1}}</nowiki></code>

==== Ausgabe als Moving Average und Formatierung mit sprintf ====
:<code>attr HZ_EINSTRAHLUNG_RAW userReadings Einstr_Mean.av {sprintf("%.1f",movingAverage("HZ_EINSTRAHLUNG_RAW","reading",1200))}</code>

==== Umrechnung der Temperatur (durch 10 geteilt) und Einheit [°C] angehängt ====
:<code>attr HZ_EINSTRAHLUNG_T userReadings SolarTemp {ReadingsVal("HZ_EINSTRAHLUNG_T","reading",0)/10 ." °C"}</code>

==== Batterieüberwachung durch Erweiterung mit notify und userReading ====
... ist im Detail auf der Seite [[Batterieüberwachung]] beschrieben.

==== Integralfunktion - integral ====
Die Verwendung der Integralfunktion bei ''userReadings'' ist ausführlich im Forenbeitrag {{Link2Forum|Topic=26300|Message=193084|LinkText=Integralfunktion bei UserReadings}} erklärt.

==== Trigger ====
Die Trigger-Regex muss ein Event matchen inklusive Wert. Hier soll ''countTotalSum'' um den Wert im Reading ''count'' erhöht werden, natürlich nur wenn ein Event für das Reading ''count'' eintrifft, damit der Wert nur einmal hinzu addiert wird. (Alle anderen Events werden ignoriert.) Hier ist auf das Wortende zu achten "'''\b'''" in der Regex, damit z.B. Events für ''count1'', ''count2'', ... keinen Trigger auslösen.
:<code>attr GasPulseCounter userReadings countTotalSum:count\b.* {my $val=ReadingsVal($name,"countTotalSum",0)+ReadingsVal($name,"count",0);;$val}</code>

Hier werden einfach die Anzahl der Events für ''count'' gezählt. Events für Readingnamen, welche ledichglich mit ''count'' beginnen werden ignoriert, wegen "\b".
:<code>attr GasPulseCounter userReadings inc:count\b.* {my $val=ReadingsVal($name,"inc",0)+1;;$val}</code>

== Links ==
* {{Link2CmdRef|Lang=de|Anker=userReadings}} - userReadings

[[Kategorie:Attribut (allgemeingültig)]]

UserReadings

2023-03-17T12:48:53Z

Markus1407: /* Beispiele */

{{SEITENTITEL:userReadings}} 

Über das Attribut [[userReadings]] können bei einem Device benutzerdefinierte [[reading|readings]] einschließlich der Anweisungen zum Befüllen derselben festgelegt werden. Das können zum Einen Formatänderungen ("sprintf"), oder aber auch durch die ''Modifier''
* difference
* differential
* integral
* offset
* monotonic
gesteuerte Berechnungen sein.

== Syntax ==
{{Randnotiz|RNTyp=y|RNText='''Geändertes Verhalten - bitte beachten'''
Im April 2016 hat sich die Verarbeitung des ''Triggers'' dahingehend geändert, dass die Trigger-Spezifikation jetzt als [[Regulärer Ausdruck]] interpretiert wird, damit also z.B. ein <code>avgTemp:temperature</code> geändert werden muss in <code>avgTemp:temperature.*</code>.

Technische Details dazu wurden in {{Link2Forum|Topic=52165|LinkText=diesem Forenthread}} diskutiert.}}
Siehe {{Link2CmdRef|Anker=readingFnAttributes}}.

* Bei Eingabe im Editor-Feld müssen mehrere Befehle mit einem ";" getrennt werden, bei Änderung in der Eingabezeile sind zwei ";" notwendig.
* Die Variable, dessen Wert man im Reading haben möchte, kann man einfach ans Ende stellen[https://perldoc.perl.org/functions/return.html]
* mehrere UserReadings werden durch Komma getrennt.

:<code>myreading {my $v = ReadingsVal($name,"actuation","error")+62; fhem("set PID desired $v"); $v},</code>
:<code>myreading2 {my $v = ReadingsVal($name,"actuation","error")+62; fhem("set PID2 desired $v"); $v}</code>

== Beispiele ==
{{Randnotiz|RNTyp=g|RNText=Die nachfolgenden Beispiele sind ohne Trigger notiert. In der Regel sollte jedoch geprüft werden, ob nicht ein solcher Trigger gesetzt werden kann. Dies ist insbesondere in den Fällen sinnvoll, in denen in einem Gerät sehr viele Readings vorhanden sind, die ggf. zu unterschiedlichen Zeitpunkten aktualisiert werden. Das erste Beispiel wäre daher besser so zu schreiben:<br><code>attr ElbePegelSchoena userReadings Pegel:value.* { ReadingsVal("ElbePegelSchoena","value",0) }</code> }}
==== Ein Reading soll einen anderen Namen bekommen ====
Das vorhandene Reading "value" des Devices "ElbePegelSchoena" soll künftig in "Pegel" umbenannt werden. Das geht nicht. Man kann aber ein neues Reading "Pegel" mit genau gleichem Wert erzeugen:
:<code>attr ElbePegelSchoena userReadings Pegel { ReadingsVal("ElbePegelSchoena","value",0) }</code>

==== Ausgabe eines Homematic 3-State Fenstersensor als Zahl für Visualisierung mit Icons ====
:<code><nowiki>attr HM_XXXXXX userReadings Statenum {if(ReadingsVal("HM_XXXXXX","state","") eq "closed") {return 0} elsif (ReadingsVal("HM_XXXXXX","state","") eq "tilted") {return 1} elsif (ReadingsVal("HM_XXXXXX","state","") eq "open") {return 2} else {return -1}}</nowiki></code>

==== Ausgabe als Moving Average und Formatierung mit sprintf ====
:<code>attr HZ_EINSTRAHLUNG_RAW userReadings Einstr_Mean.av {sprintf("%.1f",movingAverage("HZ_EINSTRAHLUNG_RAW","reading",1200))}</code>

==== Umrechnung der Temperatur (durch 10 geteilt) und Einheit [°C] angehängt ====
:<code>attr HZ_EINSTRAHLUNG_T userReadings SolarTemp {ReadingsVal("HZ_EINSTRAHLUNG_T","reading",0)/10 ." °C"}</code>

==== Batterieüberwachung durch Erweiterung mit notify und userReading ====
... ist im Detail auf der Seite [[Batterieüberwachung]] beschrieben.

==== Integralfunktion - integral ====
Die Verwendung der Integralfunktion bei ''userReadings'' ist ausführlich im Forenbeitrag {{Link2Forum|Topic=26300|Message=193084|LinkText=Integralfunktion bei UserReadings}} erklärt.

==== Trigger ====
Die Trigger-Regex muss ein Event matchen inklusive Wert. Hier soll ''countTotalSum'' um den Wert im Reading ''count'' erhöht werden, natürlich nur wenn ein Event für das Reading ''count'' eintrifft, damit der Wert nur einmal hinzu addiert wird. (Alle anderen Events werden ignoriert.) Hier ist auf das Wortende zu achten "'''\b'''" in der Regex, damit z.B. Events für ''count1'', ''count2'', ... keinen Trigger auslösen.
<code>attr GasPulseCounter userReadings countTotalSum:count\b.* {my $val=ReadingsVal($name,"countTotalSum",0)+ReadingsVal($name,"count",0);;$val}</code>

Hier werden einfach die Anzahl der Events für ''count'' gezählt. Events für Readingnamen, welche ledichglich mit ''count'' beginnen werden ignoriert, wegen "\b".

<code>attr GasPulseCounter userReadings inc:count\b.* {my $val=ReadingsVal($name,"inc",0)+1;;$val}</code>

== Links ==
* {{Link2CmdRef|Lang=de|Anker=userReadings}} - userReadings

[[Kategorie:Attribut (allgemeingültig)]]

GardenaSmartBridge

2021-04-04T13:51:45Z

Markus1407:

{{Infobox Modul
|ModPurpose=GardenaSmartBridge
|ModType=d
|ModForumArea=
|ModFTopic=75098
|ModTechName=73_GardenaSmartBridge.pm
|ModOwner={{Link2FU|13684|CoolTux}}
}}

Das Modul GardenaSmartBridge stellt zusammen mit dem Device [[GardenaSmartDevice]] die Kommunikation zwischen der '''Gardena Cloud''' und FHEM her.
Es können damit Rasenmäher, Bewässerungscomputer und Sensoren überwacht und gesteuert werden, die Steuerung erfolgt durch das Modul [[GardenaSmartDevice]].
''Informationen zum [[GardenaSmartSystem]]''

== Voraussetzungen ==
* Perl-Modul "SSL Packet"
* Internetanbinung
* Netzwerk mit W-Lan oder LAN (RJ45)
* Smart Gateway von Gardena
* Account bei https://developer.husqvarnagroup.cloud/ (alt: [https://sg-api.dss.husqvarnagroup.net/ Gardena])
* Smart Produkte von Gardena [[GardenaSmartSystem]]

== Anwendung ==
=== Define ===
<code> define <NAME> GardenaSmartBridge </code>

==== Beispiel ====
<code> define myGardenaBridge GardenaSmartBridge </code>

Diese Anweisung erstellt ein neues GardenaSmartBridge Device Namens myGardenaBridge.
Im folgendem wird automatisch ein neuer Raum ''GardenaSmart'' erstellt und nach setzen des Attributes gardenaAccountEmail und einem <code>set myGardenaBridge gardenaAccountPassword</code> alle dem [https://sg-api.dss.husqvarnagroup.net/ Gardena] Account bekannten Geräte
angelegt.

=== Attribute ===
* debugJSON -
* disable - aktivieren & deaktivieren der Bridge (0= aktiviert, 1= deaktiviert)
* interval - Abfrageinterval in Minuten (5= default)
* gardenaAccountEmail - Email Adresse, die auch in der GardenaApp verwendet wurde

=== Readings ===

* address - bei Gardena verwendete Adresse
* city - bei Gardena hinterlegte Stadt
* devices - Anzahl der angelernten/verwendeten Geräte incl. des Gateways
* latitude - Längengrad
* longitude - Breitengrad
* name - Name des Gartens ''(Standard "MY GARDEN")''
* state - Status der Bridge (connect to cloud= Verbunden mit der Cloud)
* token - SessionID

== Anwendungsbeispiele ==

== Bekannte Probleme ==
* keine

== Links ==
* {{Link2Forum|Topic=75098|LinkText=Forenthread zu diesem Modul}}

[[Kategorie:Gerätemodul]]

GardenaSmartSystem

2021-04-04T13:50:39Z

Markus1407: update link

{{Randnotiz|RNText=Beispiel - [http://www.gardena.com/de/produkte/smart/smartsystem/ '''Smart Produkte von Gardena''']))
<hr />
* Kommunikation-1 (zu den Geräten): 868MHz
* Intelligenz-1: Smart Gateway<hr />
* Verdrahtung und Stromversorgung
}}
__TOC__

Das auf Cloud basierte Gardena Smart System kann zur intelligenten Bewässerung und Rasenpflege verwendet werden.
Derzeit verfügbare Produkte sind

* Smart Gateway - erlaubt die Steuerung der folgenden Geräte via APP oder FHEM
* Rasenmäher
* Sensoren
* Bewässerungscomputer
* Gartenpumpen

Der Smart Gateway kommuniziert via 868 MHz mit den angelernten Geräten. Er kann via W-Lan oder LAN (RJ45) mit dem
heimischen Netzwerk verbunden werden. Um die Geräte via APP oder FHEM bedienen zu können ist eine Internetanbindung und
ein Account bei https://developer.husqvarnagroup.cloud/ (alt: [https://sg-api.dss.husqvarnagroup.net/ Gardena]) zwingend erforderlich.

== Einbindung in FHEM ==
FHEM-seitig wird das Gardena Smart System durch die Module [[GardenaSmartBridge]], welches die Verbindung zur Cloud herstellt, und [[GardenaSmartDevice]] zum bedienen/steuern der jeweiligen Geräte.

== Ähnliche Systeme ==
* [https://forum.fhem.de/index.php/topic,52143.0.html - Bosch Indego]

== Links ==
* {{Link2Forum|Topic=75098|LinkText=Forenthread zu diesem Modul}}

[[Kategorie:Other_Components]]
[[Kategorie:868MHz]]

SiSi

2020-08-31T20:23:25Z

Markus1407:

{{Infobox Modul
|ModPurpose=Senden und Empfangen von Nachrichten (Text und Fotos) mit dem freien Messenger Signal
|ModType=x
|ModForumArea=Codeschnipsel
|ModFTopic=84996
|ModTechName=32_SiSi.pm
|ModOwner=Quantum ({{Link2FU|35410|Forum}})}}
Das Modul [[SiSi]] ermöglicht den Versand von Nachrichten über den Instant-Messaging-Dienst [https://signal.org Signal] aus FHEM heraus.

Um dies zu ermöglichen, sind mehrere Schritte notwendig:
#Installation des [https://github.com/AsamK/signal-cli Signal Messenger Command Line Interface (signal-cli)].
#Registrierung einer Rufnummer bei Signal
#Einrichtung der [https://de.wikipedia.org/wiki/D-Bus D-Bus]-Schnittstelle
#Inbetriebnahme des FHEM-Moduls

Diese Anleitung geht davon aus, dass
*als Betriebssystem Debian oder Raspbian verwendet wird
*FHEM im Verzeichnis ''/opt/fhem'' installiert wurde (ansonsten müssen die Pfade in der Anleitung angepasst werden)

Alle in dieser Anleitung vorkommenden Textstellen in spitzen Klammern (z.B. <ErsetzMich>) sind durch eigene Werte zu ersetzen, sofern es sich nicht um Auszüge aus Konfigurationsdateien handelt.

==Voraussetzungen==
Um sowohl das ''signal-cli'' als auch das Modul verwenden zu können, müssen bestimmmte Linux-Pakete installiert sein. Im Folgenden eine Liste der Pakete für Debian/Raspbian:
*'''''libunixsocket-java'''''
*'''''dbus'''''
*'''''libnet-dbus-perl'''''
*'''''haveged''''' (Dient dazu, genügend Entropie für den Zufallszahlengenerator zu erzeugen.)
*'''''openjdk-9-jre-headless''''' (Es sollte eine Version > 7 installiert werden. Welche genau, hängt von Betriebssystem und dem Installationszeitpunkt ab.)

Optional kann noch das Paket '''''shared-mime-info''''' installiert werden wenn ein gesendeter Anhang nicht direkt im Chatverlauf angezeigt werden soll, sondern erst durch einen Klick auf das Datei-Icon.

Installation der Pakete in einem Rutsch:
sudo apt-get update
sudo apt-get install libunixsocket-java dbus libnet-dbus-perl shared-mime-info haveged openjdk-9-jre-headless

==Installation des signal-cli==
[https://github.com/AsamK/signal-cli signal-cli] ist ein Kommandozeilen-Interface für [https://github.com/signalapp/libsignal-service-java libsignal-service-java]<ref>libsignal-service-java ist eine Java/Android Bibliothek zur Kommunikation mit dem Signal Messaging Service</ref>. Es unterstützt das Registrieren und Verifizieren einer Rufnummer sowie das Senden und Empfangen von Nachrichten.

Der erste Schritt zur Installation von ''signal-cli'' ist, die aktuellste Versionsnummer auf der GitHub-Seite des Projektes unter "[https://github.com/AsamK/signal-cli/releases Releases]" zu finden. Zum Zeitpunkt der Erstfassung dieser Anleitung war das die Version 0.6.0.

Anschließend wird die Release heruntergeladen und als Benutzer '''''fhem''''' in den Wurzelordner von FHEM (z.B. ''/opt/fhem'') entpackt.
<source lang="text">
export VERSION=0.6.0
wget https://github.com/AsamK/signal-cli/releases/download/v"${VERSION}"/signal-cli-"${VERSION}".tar.gz
sudo -u fhem tar xf signal-cli-"${VERSION}".tar.gz -C /opt/fhem
</source>

Zur einfacheren Handhabung kann der neu erstellte Ordner umbenannt und ein symbolischer Link in ''/usr/local/bin/'' erstellt werden.
<source lang="text">
sudo mv /opt/fhem/signal-cli-"${VERSION}" /opt/fhem/signal-cli
sudo ln -sf /opt/fhem/signal-cli/bin/signal-cli /usr/local/bin/
</source>

==Registrierung einer Rufnummer==
Um Signal nutzen zu können, ist eine Rufnummer zwingend erforderlich. Für diesen Fall empfiehlt es sich, eine Nummer zu verwenden, die nicht schon für die Kommunikation mit Signal verwendet wird. Zum Beispiel eine Festnetznummer.

Die Registrierung einer Nummer läuft wie folgt ab:
#Registrierung der Nummer mittels ''signal-cli''
#Erhalt einer Textnachricht mit dem Verifizierungscode an angegebene Nummer. Wenn an der Rufnummer keine Textnachrichten empfangen werden können, kann - wie in diesem Beispiel - mit dem Parameter ''--voice'' ein Sprachanruf erzwungen werden. In beiden Fällen kann es durchaus etwas länger dauern, bis man den Verifizierungscode erhält.
#Verifizierung der Nummer mittels ''signal-cli''

{{Hinweis|Alle der folgenden Befehle werden als Benutzer '''''fhem''''' ausgeführt, damit die Konfigurationsdateien im Home-Verzeichnis des Benutzers (z.B. ''~/.local/share/signal-cli'') landen.}}

Im ersten Schritt registriert man eine Nummer mittels ''signal-cli''.
<source lang="text">sudo -u fhem signal-cli -u <Telefonnummer> register --voice</source>
Wenn alles in Ordnung ist, erhält man keine Rückmeldung. Wenn es lange dauert, hat man nicht genug Entropie.
Kurz darauf erhält man einen Sprachanruf auf Englisch, mit dem einem der sechsstellige Verifizierungscode yyyyyy mitgeteilt wird.

Im zweiten Schritt wird diese Nummer mit Hilfe des erhaltenen Codes verifiziert.
<source lang="text">sudo -u fhem signal-cli -u <Telefonnummer> verify <VerificationCode></source>
Auch hier gibt es keine Rückmeldung, solange alles funktioniert hat.

War die Registrierung erfolgreich, können nun Nachrichten via ''signal-cli'' versendet werden:
<source lang="text">signal-cli -u <RegistrierteNummer> send -m "Greetings from FHEM!" <Empfängernummer></source>

== Einrichten der Kommunikation über D-Bus ==
Damit das FHEM-Modul über die D-Bus Schnittstelle mit ''signal-cli'' kommunizieren kann, ist die Einrichtung von D-Bus sowie die Erstellung eines [https://de.wikipedia.org/wiki/Systemd systemd]-Scripts notwendig.

{{Hinweis|Alle der folgenden drei Dateien müssen als Benutzer '''''root''''' angelegt und editiert werden.}}

;/etc/dbus-1/system.d/org.asamk.Signal.conf
Die Datei in einem Editor öffnen
sudo nano /etc/dbus-1/system.d/org.asamk.Signal.conf
und mit folgendem Inhalt befüllen
<source lang="xml">
<?xml version="1.0"?> 
<!DOCTYPE busconfig PUBLIC "-//freedesktop//DTD D-BUS Bus Configuration 1.0//EN"
"http://www.freedesktop.org/standards/dbus/1.0/busconfig.dtd">

<busconfig>
<policy user="fhem">
<allow own="org.asamk.Signal"/>
<allow send_destination="org.asamk.Signal"/>
<allow receive_sender="org.asamk.Signal"/>
</policy>

<policy context="default">
<allow send_destination="org.asamk.Signal"/>
<allow receive_sender="org.asamk.Signal"/>
</policy>
</busconfig>
</source>

;/usr/share/dbus-1/system-services/org.asamk.Signal.service
Die Datei in einem Editor öffnen
sudo nano /usr/share/dbus-1/system-services/org.asamk.Signal.service
und mit folgendem Inhalt befüllen
<source lang="ini">
[D-BUS Service]
Name=org.asamk.Signal
Exec=/bin/false
SystemdService=dbus-org.asamk.Signal.service
</source>

;/etc/systemd/system/signal.service
Die Datei in einem Editor öffnen
sudo nano /etc/systemd/system/signal.service
und mit folgendem Inhalt befüllen.

<source lang="ini">
[Unit]
Description=Send secure messages to Signal clients
Requires=dbus.socket
After=dbus.socket
Wants=network-online.target
After=network-online.target

[Service]
Type=dbus
Environment="SIGNAL_CLI_OPTS=-Xms2m"
ExecStart=/opt/fhem/signal-cli/bin/signal-cli -u +49xxxxxxxxxxx --config /opt/fhem/.local/share/signal-cli daemon --system
User=fhem
BusName=org.asamk.Signal

[Install]
Alias=dbus-org.asamk.Signal.service
</source>

'''Achtung!'''
* Die Rufnummer im Script muss durch die in den vorigen Schritten registrierte ersetzt werden.
* Außerdem muss unter Umständen der Pfad des FHEM-Wurzelverzeichnisses angepasst werden.
* Der Pfad zur Konfigurationsdatei ist je nach signal-cli Version anders:

;<0.6.1:
$HOME/.config/signal/data/
oder
$HOME/.config/textsecure/data/

;>=0.6.1
$HOME/.local/share/signal-cli/data/

Sind alle Dateien angelegt, können die Services mit diesen Befehlen aktiviert und gestartet werden.
<source lang="text">
sudo systemctl daemon-reload
sudo systemctl reload dbus.service
sudo systemctl enable signal.service
sudo systemctl start signal.service
</source>

Ob alles funktioniert, kann wie folgt getestet werden:
*D-Bus:
sudo -u fhem dbus-send --system --type=method_call --print-reply --dest="org.asamk.Signal" /org/asamk/Signal org.asamk.Signal.sendMessage string:<Nachricht> array:string: string:<EmpfängerNummer>
*signal-cli über D-Bus:
sudo -u fhem signal-cli --dbus-system send -m "<Nachricht>" <EmpfängerNummer>

== Einbindung des FHEM-Moduls ==
Solange das Modul '''32_SiSi.pm''' noch nicht via FHEM-Update verteilt wird, ist eine manuelle Installation notwendig. Das geschieht, in dem es von der [https://github.com/Quantum1337/32_SiSi.pm GitHub-Seite] des Modul-Autors heruntergeladen und in den FHEM-Ordner kopiert wird.

Der Befehl
wget https://raw.githubusercontent.com/Quantum1337/32_SiSi.pm/master/FHEM/32_SiSi.pm
speichert das Modul im aktuellen Verzeichnis.

Mit den folgenden Befehlen wird das Modul ins das FHEM-Verzeichnis verschoben und anschließend die Datei-Rechte angepasst.
sudo mv 32_SiSi.pm /opt/fhem/FHEM/
sudo chown fhem:dialout /opt/fhem/FHEM/32_SiSi.pm

Anschließend wird noch die lokale CommandRef aktualisiert:
cd /opt/fhem
sudo /usr/bin/perl contrib/commandref_join.pl

Zum Abschluss wird das Modul noch FHEM bekannt gemacht. Dazu in der FHEM-Kommandozeile folgenden Befehl eingeben:
reload 32_SiSi.pm

==Verwendung des FHEM-Moduls==
Die genaue Verwendung des Moduls 32_SiSi.pm ist in der CommandRef beschrieben. Hier deshalb nur ein kleines Beispiel.

SiSi-Device definieren:
define Signal SiSi

Dem Device mitteilen, dass es eine Verbindung zum signal-cli D-Bus Service herstellen soll:
attr Signal enable yes

Eine Standard-Empfängernummer definieren, falls im Befehlsaufruf keine angegeben ist:
attr Signal defaultPeer +49170zzzzzzzz

Anschließend kann aus FHEM heraus eine Nachricht gesendet werden:
set Signal msg Hurra, es funktioniert!

===Zusammenspiel mit den Modulen Msg und Roommate===
Um mithilfe des Moduls [[Msg]] Signal-Nachrichten versenden zu können, ist im Device ''globalMsg'' das Attribut '''msgCmdPush''' zu setzen.
attr globalMsg msgCmdPush set %DEVICE% msg @%RECIPIENT% %MSG%

Optional kann ein Standard-Empfänger gesetzt werden der die Nachricht erhält, wenn beim Aufruf von ''Msg'' kein Empfänger angegeben wurde:
attr globalMsg msgContactPush <Signal-Device>:<Empfängernummer>
Danach kann mit <code>msg Testnachricht</code> eine Signal-Nachricht versendet werden.

Werden {{Link2CmdRef|Anker=ROOMMATE|Lang=de|Label=ROOMMATE-Devices}} verwendet, kann jedem eine Kontaktadresse hinterlegt werden, damit beim Aufruf von ''Msg'' einfach der Device-Name anstatt der Nummer angegeben werden kann. (Funktioniert natürlich bei jedem anderen Device auch. Aber ein ROOMMATE-Device macht das ganze anschaulicher.)
<source lang="text">
attr <ROOMMATE-Device> msgContactPush <Signal-Device>:<Empfängernummer>

z.B.:
attr rr_Max msgContactPush Signal:+49...
</source>
Anschließend kann mit <code>msg @rr_Max Testnachricht</code> eine Nachricht an Max gesendet werden.

==Hinweise==
Derzeit ist es aufgrund von Einschränkungen in der D-Bus-API noch nicht möglich, mit dem SiSi-Modul neue Fingerprints von Kontakten hinzuzufügen oder aus Gruppen auszutreten. Daher muss beides noch manuell auf der Linux-Kommandozeile erfolgen.

;Neuer Fingerprint
:Mit folgendem Befehl wird dieser Nummer wieder vertraut und ''signal-cli'' fügt den geänderten Fingerprint dann automatisch zu seiner Liste hinzu.
:<source lang="text">sudo -u fhem signal-cli -u <FHEM-NUMMER> trust -a <Nummer mit geänderten Fingerprint></source>

;Aus einer Gruppe austreten
:Soll die "FHEM-Signal-Rufnummer" aus einer bestehende Gruppe entfernt werden, kann dieser Aufruf von ''signal-cli'' verwendet werden.
:<source lang="text">sudo -u fhem signal-cli -u <FHEM-NUMMER> quitGroup -g <GroupID></source>

==Querverweise==
<references />
[[Kategorie:Signal]]

Z-Wave

2019-03-10T12:30:55Z

Markus1407: /* Doppel-Relais */

<div style="float:right">{{Infobox Modul
|Name=ZWDongle
|ModPurpose=Einbindung Z-Wave-Gateways
|ModType=d
|ModCmdRef=ZWDongle
|ModForumArea=ZWave
|ModTechName=00_ZWDongle.pm
|ModOwner=Rudolf König ([http://forum.fhem.de/index.php?action=profile;u=8 Forum])
}}
{{Infobox Modul
|Name=ZWave
|ModPurpose=Ansteuerung Z-Wave-Geräte über ZWDongle
|ModType=d
|ModCmdRef=ZWave
|ModForumArea=ZWave
|ModTechName=10_ZWave.pm
|ModOwner=Rudolf König ([http://forum.fhem.de/index.php?action=profile;u=8 Forum])
}}
</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 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.
== 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:
# '''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.
# '''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: [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")[https://web.archive.org/web/20160319202135/http://wiki.zwaveeurope.com/index.php?title=SDK_Versions_and_Explorer_Frames].

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

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

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 ===
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 (beispielsweise Devolo, AEOTEC). Man sollte bei allen Produkten auf folgenden Seiten nach eventuellen ausführlicheren Handbüchern suchen:
* Herstellerseite des ZWave-Gerätes
* http://www.zwave.de/handbuecher/ (deutsch)
* http://products.z-wavealliance.org (englisch)
Insbesondere auf http://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 ==
{{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 ===
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 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 [[Trick_der_Woche#CUL_.26_CO_.C3.BCber_Serial_ID-einbinden|Serial-by-Id]] oder [[LinuxDeviceNaming|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 <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> 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 <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.

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:
* <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 />
* 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><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 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.

=== Assoziation ===
{{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.

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

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.

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|Konfiguration]] des Gerätes.

=== Konfiguration ===
{{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>
Für weitere Parametergrößen gibt es die Befehle <code>configWord</code> und <code>configLong</code>

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

=== 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 [[#Hinzufügen eines neuen Z-Wave Geräts / Inklusion|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 <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 ===
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 <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 ==
=== 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
:<code>Scheduled for sending after WAKEUP</code>
::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.

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

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> oder -falls vorhanden- mit <code>get <name> configAll</code> ü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 [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 ===
Ausführliche Handbücher und technische Informationen auf https://aeotec.freshdesk.com/support/home

==== Multi Sensor 5 ====
* aktuellste Firmware installieren
* 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)
* 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).
* [http://devel.pepper1.net/zwavedb/device/407 Paramterübersicht pepper-Datenbank]
siehe {{Link2Forum|Topic=34505|Message=268913}}

==== Multisensor 6 ====
siehe {{Link2Forum|Topic=40393}}
* 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 ====
siehe {{Link2Forum|Topic=40504}}

=== Danfoss ===
==== 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}}):
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}}).

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

==== MT02648 Tür-/Fenster Kontakt 3in1 ====
siehe {{Link2Forum|Topic=41337}}

=== 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.
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 ===
Association Group für Übermittlung von Statusinformationen an den Controller:
* "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 / 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: {{Link2Forum|Topic=50176}}

Hinweis zum Reset: {{Link2Forum|Topic=55190|Message=469393}}

==== FGK-101 Tür/Fensterkontakt ====
* Besonderheiten bei Anschluss eines Temperatursensors: {{Link2Forum|Topic=38012}}

=== GE ===
==== GE (Model t.b.d) ====
Dieser Schalter unterstützt keine Statusrückmeldungen.

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

=== Philio ===
==== PHI_PAN04 Relais Unterputzeinsatz 2 Schalter a 1.5kW mit Messfunktion ====
siehe {{Link2Forum|Topic=28046}}

=== Popp ===
==== POPE004001 Z-Wave Rauchmelder mit Innensirene ====
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 ===
==== ZME_RC2 Fernbedienung ====
siehe {{Link2Forum|Topic=35513}}<BR>
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 || Nur Hauptgerät <br> Aktualisierung der Untergeräte nur bei aktiver Abfrage || Nur Hauptgerät <br>Aktualisierung der Untergeräte nur bei aktiver Abfrage
|-
| Leistungsmessung || Separat für Untergeräte || Nur Summe || Nur Summe
|-
| Sicherung nötig / Strom || ja, 2x 6.5A, Summe max 10A || ja, max 2x 4A || nein, 2x 6.5A
|}

== Links ==
=== Allgemein ===
* 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]
* [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, 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:
** [http://www.z-wavealliance.org/ http://www.z-wavealliance.org/] (englisch)
** [http://www.zwaveeurope.com/ http://www.zwaveeurope.com/] (englisch)
** [http://www.zwave.de/ 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; nicht auf aktuellem Stand)

=== Informationsquellen zur Einbindung von Command Classes ===
Offizielle und ausführliche Informationen von Sigma Designs (veröffentlicht am 31.08.2016):
* [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 ==
=== 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!
# [[#Hinzufügen eines neuen Z-Wave Geräts / Inklusion|Inklusion]] des Gerätes
# [[#Assoziation|Assoziation]] der Assoziationsgruppe(n) des Gerätes mit dem Gateway
# [[#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? ===
* 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).
* 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? ===
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 <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".

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.

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 nicht erneut vergeben. Nur bei einem Controller-Reset, der mit einem unwiederbringlichen Verlust sämtlicher Informationen des ZWave-Netzes und Neuvergabe der HomeID verbunden ist, beginnt die Zählung wieder von vorne.

=== 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:
* 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 <code>classes</code> 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 ({{Link2Forum|Area=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 <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/master/ressources/openzwave/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.

=== 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 <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.
(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? ===
* 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
* [[How_to_write_a_patch|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 <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.
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.
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:

<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:Z-Wave Components|!]]
[[Kategorie:868MHz]]

Z-Wave

2019-03-10T12:30:16Z

Markus1407: /* Doppel-Relais */

<div style="float:right">{{Infobox Modul
|Name=ZWDongle
|ModPurpose=Einbindung Z-Wave-Gateways
|ModType=d
|ModCmdRef=ZWDongle
|ModForumArea=ZWave
|ModTechName=00_ZWDongle.pm
|ModOwner=Rudolf König ([http://forum.fhem.de/index.php?action=profile;u=8 Forum])
}}
{{Infobox Modul
|Name=ZWave
|ModPurpose=Ansteuerung Z-Wave-Geräte über ZWDongle
|ModType=d
|ModCmdRef=ZWave
|ModForumArea=ZWave
|ModTechName=10_ZWave.pm
|ModOwner=Rudolf König ([http://forum.fhem.de/index.php?action=profile;u=8 Forum])
}}
</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 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.
== 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:
# '''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.
# '''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: [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")[https://web.archive.org/web/20160319202135/http://wiki.zwaveeurope.com/index.php?title=SDK_Versions_and_Explorer_Frames].

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

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

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 ===
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 (beispielsweise Devolo, AEOTEC). Man sollte bei allen Produkten auf folgenden Seiten nach eventuellen ausführlicheren Handbüchern suchen:
* Herstellerseite des ZWave-Gerätes
* http://www.zwave.de/handbuecher/ (deutsch)
* http://products.z-wavealliance.org (englisch)
Insbesondere auf http://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 ==
{{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 ===
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 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 [[Trick_der_Woche#CUL_.26_CO_.C3.BCber_Serial_ID-einbinden|Serial-by-Id]] oder [[LinuxDeviceNaming|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 <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> 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 <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.

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:
* <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 />
* 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><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 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.

=== Assoziation ===
{{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.

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

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.

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|Konfiguration]] des Gerätes.

=== Konfiguration ===
{{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>
Für weitere Parametergrößen gibt es die Befehle <code>configWord</code> und <code>configLong</code>

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

=== 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 [[#Hinzufügen eines neuen Z-Wave Geräts / Inklusion|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 <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 ===
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 <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 ==
=== 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
:<code>Scheduled for sending after WAKEUP</code>
::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.

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

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> oder -falls vorhanden- mit <code>get <name> configAll</code> ü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 [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 ===
Ausführliche Handbücher und technische Informationen auf https://aeotec.freshdesk.com/support/home

==== Multi Sensor 5 ====
* aktuellste Firmware installieren
* 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)
* 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).
* [http://devel.pepper1.net/zwavedb/device/407 Paramterübersicht pepper-Datenbank]
siehe {{Link2Forum|Topic=34505|Message=268913}}

==== Multisensor 6 ====
siehe {{Link2Forum|Topic=40393}}
* 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 ====
siehe {{Link2Forum|Topic=40504}}

=== Danfoss ===
==== 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}}):
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}}).

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

==== MT02648 Tür-/Fenster Kontakt 3in1 ====
siehe {{Link2Forum|Topic=41337}}

=== 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.
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 ===
Association Group für Übermittlung von Statusinformationen an den Controller:
* "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 / 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: {{Link2Forum|Topic=50176}}

Hinweis zum Reset: {{Link2Forum|Topic=55190|Message=469393}}

==== FGK-101 Tür/Fensterkontakt ====
* Besonderheiten bei Anschluss eines Temperatursensors: {{Link2Forum|Topic=38012}}

=== GE ===
==== GE (Model t.b.d) ====
Dieser Schalter unterstützt keine Statusrückmeldungen.

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

=== Philio ===
==== PHI_PAN04 Relais Unterputzeinsatz 2 Schalter a 1.5kW mit Messfunktion ====
siehe {{Link2Forum|Topic=28046}}

=== Popp ===
==== POPE004001 Z-Wave Rauchmelder mit Innensirene ====
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 ===
==== ZME_RC2 Fernbedienung ====
siehe {{Link2Forum|Topic=35513}}<BR>
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 || Nur Hauptgerät <br> Aktualisierung der Untergeräte nur bei aktiver Abfrage || Nur Hauptgerät <br>Aktualisierung der Untergeräte nur bei aktiver Abfrage
|-
| Leistungsmessung || Separat für Untergeräte || Nur Summe || Nur Summe
|-
| Leitungssicherung nötig || ja, 2x 6.5A, Summe max 10A || ja, max 2x 4A || nein, 2x 6.5A
|}

== Links ==
=== Allgemein ===
* 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]
* [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, 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:
** [http://www.z-wavealliance.org/ http://www.z-wavealliance.org/] (englisch)
** [http://www.zwaveeurope.com/ http://www.zwaveeurope.com/] (englisch)
** [http://www.zwave.de/ 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; nicht auf aktuellem Stand)

=== Informationsquellen zur Einbindung von Command Classes ===
Offizielle und ausführliche Informationen von Sigma Designs (veröffentlicht am 31.08.2016):
* [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 ==
=== 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!
# [[#Hinzufügen eines neuen Z-Wave Geräts / Inklusion|Inklusion]] des Gerätes
# [[#Assoziation|Assoziation]] der Assoziationsgruppe(n) des Gerätes mit dem Gateway
# [[#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? ===
* 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).
* 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? ===
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 <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".

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.

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 nicht erneut vergeben. Nur bei einem Controller-Reset, der mit einem unwiederbringlichen Verlust sämtlicher Informationen des ZWave-Netzes und Neuvergabe der HomeID verbunden ist, beginnt die Zählung wieder von vorne.

=== 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:
* 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 <code>classes</code> 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 ({{Link2Forum|Area=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 <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/master/ressources/openzwave/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.

=== 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 <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.
(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? ===
* 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
* [[How_to_write_a_patch|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 <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.
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.
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:

<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:Z-Wave Components|!]]
[[Kategorie:868MHz]]

Z-Wave

2019-03-10T12:28:31Z

Markus1407: /* Doppel-Relais */

<div style="float:right">{{Infobox Modul
|Name=ZWDongle
|ModPurpose=Einbindung Z-Wave-Gateways
|ModType=d
|ModCmdRef=ZWDongle
|ModForumArea=ZWave
|ModTechName=00_ZWDongle.pm
|ModOwner=Rudolf König ([http://forum.fhem.de/index.php?action=profile;u=8 Forum])
}}
{{Infobox Modul
|Name=ZWave
|ModPurpose=Ansteuerung Z-Wave-Geräte über ZWDongle
|ModType=d
|ModCmdRef=ZWave
|ModForumArea=ZWave
|ModTechName=10_ZWave.pm
|ModOwner=Rudolf König ([http://forum.fhem.de/index.php?action=profile;u=8 Forum])
}}
</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 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.
== 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:
# '''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.
# '''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: [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")[https://web.archive.org/web/20160319202135/http://wiki.zwaveeurope.com/index.php?title=SDK_Versions_and_Explorer_Frames].

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

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

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 ===
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 (beispielsweise Devolo, AEOTEC). Man sollte bei allen Produkten auf folgenden Seiten nach eventuellen ausführlicheren Handbüchern suchen:
* Herstellerseite des ZWave-Gerätes
* http://www.zwave.de/handbuecher/ (deutsch)
* http://products.z-wavealliance.org (englisch)
Insbesondere auf http://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 ==
{{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 ===
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 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 [[Trick_der_Woche#CUL_.26_CO_.C3.BCber_Serial_ID-einbinden|Serial-by-Id]] oder [[LinuxDeviceNaming|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 <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> 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 <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.

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:
* <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 />
* 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><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 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.

=== Assoziation ===
{{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.

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

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.

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|Konfiguration]] des Gerätes.

=== Konfiguration ===
{{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>
Für weitere Parametergrößen gibt es die Befehle <code>configWord</code> und <code>configLong</code>

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

=== 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 [[#Hinzufügen eines neuen Z-Wave Geräts / Inklusion|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 <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 ===
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 <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 ==
=== 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
:<code>Scheduled for sending after WAKEUP</code>
::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.

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

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> oder -falls vorhanden- mit <code>get <name> configAll</code> ü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 [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 ===
Ausführliche Handbücher und technische Informationen auf https://aeotec.freshdesk.com/support/home

==== Multi Sensor 5 ====
* aktuellste Firmware installieren
* 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)
* 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).
* [http://devel.pepper1.net/zwavedb/device/407 Paramterübersicht pepper-Datenbank]
siehe {{Link2Forum|Topic=34505|Message=268913}}

==== Multisensor 6 ====
siehe {{Link2Forum|Topic=40393}}
* 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 ====
siehe {{Link2Forum|Topic=40504}}

=== Danfoss ===
==== 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}}):
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}}).

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

==== MT02648 Tür-/Fenster Kontakt 3in1 ====
siehe {{Link2Forum|Topic=41337}}

=== 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.
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 ===
Association Group für Übermittlung von Statusinformationen an den Controller:
* "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 / 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: {{Link2Forum|Topic=50176}}

Hinweis zum Reset: {{Link2Forum|Topic=55190|Message=469393}}

==== FGK-101 Tür/Fensterkontakt ====
* Besonderheiten bei Anschluss eines Temperatursensors: {{Link2Forum|Topic=38012}}

=== GE ===
==== GE (Model t.b.d) ====
Dieser Schalter unterstützt keine Statusrückmeldungen.

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

=== Philio ===
==== PHI_PAN04 Relais Unterputzeinsatz 2 Schalter a 1.5kW mit Messfunktion ====
siehe {{Link2Forum|Topic=28046}}

=== Popp ===
==== POPE004001 Z-Wave Rauchmelder mit Innensirene ====
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 ===
==== ZME_RC2 Fernbedienung ====
siehe {{Link2Forum|Topic=35513}}<BR>
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
|-
| 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 || Nur Hauptgerät <br> Aktualisierung der Untergeräte nur bei aktiver Abfrage || Nur Hauptgerät <br>Aktualisierung der Untergeräte nur bei aktiver Abfrage
|-
| Leistungsmessung || Separat für Untergeräte || Nur Summe || Nur Summe
|-
| Leitungssicherung nötig || ja, 2x 6.5A, Summe max 10A || ja, max 2x 4A || nein, 2x 6.5A
|}

== Links ==
=== Allgemein ===
* 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]
* [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, 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:
** [http://www.z-wavealliance.org/ http://www.z-wavealliance.org/] (englisch)
** [http://www.zwaveeurope.com/ http://www.zwaveeurope.com/] (englisch)
** [http://www.zwave.de/ 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; nicht auf aktuellem Stand)

=== Informationsquellen zur Einbindung von Command Classes ===
Offizielle und ausführliche Informationen von Sigma Designs (veröffentlicht am 31.08.2016):
* [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 ==
=== 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!
# [[#Hinzufügen eines neuen Z-Wave Geräts / Inklusion|Inklusion]] des Gerätes
# [[#Assoziation|Assoziation]] der Assoziationsgruppe(n) des Gerätes mit dem Gateway
# [[#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? ===
* 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).
* 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? ===
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 <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".

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.

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 nicht erneut vergeben. Nur bei einem Controller-Reset, der mit einem unwiederbringlichen Verlust sämtlicher Informationen des ZWave-Netzes und Neuvergabe der HomeID verbunden ist, beginnt die Zählung wieder von vorne.

=== 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:
* 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 <code>classes</code> 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 ({{Link2Forum|Area=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 <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/master/ressources/openzwave/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.

=== 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 <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.
(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? ===
* 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
* [[How_to_write_a_patch|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 <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.
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.
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:

<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:Z-Wave Components|!]]
[[Kategorie:868MHz]]

Z-Wave

2019-03-10T11:52:36Z

Markus1407: /* Doppel-Relais */

<div style="float:right">{{Infobox Modul
|Name=ZWDongle
|ModPurpose=Einbindung Z-Wave-Gateways
|ModType=d
|ModCmdRef=ZWDongle
|ModForumArea=ZWave
|ModTechName=00_ZWDongle.pm
|ModOwner=Rudolf König ([http://forum.fhem.de/index.php?action=profile;u=8 Forum])
}}
{{Infobox Modul
|Name=ZWave
|ModPurpose=Ansteuerung Z-Wave-Geräte über ZWDongle
|ModType=d
|ModCmdRef=ZWave
|ModForumArea=ZWave
|ModTechName=10_ZWave.pm
|ModOwner=Rudolf König ([http://forum.fhem.de/index.php?action=profile;u=8 Forum])
}}
</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 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.
== 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:
# '''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.
# '''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: [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")[https://web.archive.org/web/20160319202135/http://wiki.zwaveeurope.com/index.php?title=SDK_Versions_and_Explorer_Frames].

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

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

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 ===
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 (beispielsweise Devolo, AEOTEC). Man sollte bei allen Produkten auf folgenden Seiten nach eventuellen ausführlicheren Handbüchern suchen:
* Herstellerseite des ZWave-Gerätes
* http://www.zwave.de/handbuecher/ (deutsch)
* http://products.z-wavealliance.org (englisch)
Insbesondere auf http://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 ==
{{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 ===
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 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 [[Trick_der_Woche#CUL_.26_CO_.C3.BCber_Serial_ID-einbinden|Serial-by-Id]] oder [[LinuxDeviceNaming|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 <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> 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 <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.

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:
* <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 />
* 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><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 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.

=== Assoziation ===
{{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.

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

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.

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|Konfiguration]] des Gerätes.

=== Konfiguration ===
{{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>
Für weitere Parametergrößen gibt es die Befehle <code>configWord</code> und <code>configLong</code>

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

=== 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 [[#Hinzufügen eines neuen Z-Wave Geräts / Inklusion|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 <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 ===
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 <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 ==
=== 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
:<code>Scheduled for sending after WAKEUP</code>
::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.

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

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> oder -falls vorhanden- mit <code>get <name> configAll</code> ü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 [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 ===
Ausführliche Handbücher und technische Informationen auf https://aeotec.freshdesk.com/support/home

==== Multi Sensor 5 ====
* aktuellste Firmware installieren
* 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)
* 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).
* [http://devel.pepper1.net/zwavedb/device/407 Paramterübersicht pepper-Datenbank]
siehe {{Link2Forum|Topic=34505|Message=268913}}

==== Multisensor 6 ====
siehe {{Link2Forum|Topic=40393}}
* 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 ====
siehe {{Link2Forum|Topic=40504}}

=== Danfoss ===
==== 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}}):
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}}).

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

==== MT02648 Tür-/Fenster Kontakt 3in1 ====
siehe {{Link2Forum|Topic=41337}}

=== 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.
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 ===
Association Group für Übermittlung von Statusinformationen an den Controller:
* "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 / 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: {{Link2Forum|Topic=50176}}

Hinweis zum Reset: {{Link2Forum|Topic=55190|Message=469393}}

==== FGK-101 Tür/Fensterkontakt ====
* Besonderheiten bei Anschluss eines Temperatursensors: {{Link2Forum|Topic=38012}}

=== GE ===
==== GE (Model t.b.d) ====
Dieser Schalter unterstützt keine Statusrückmeldungen.

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

=== Philio ===
==== PHI_PAN04 Relais Unterputzeinsatz 2 Schalter a 1.5kW mit Messfunktion ====
siehe {{Link2Forum|Topic=28046}}

=== Popp ===
==== POPE004001 Z-Wave Rauchmelder mit Innensirene ====
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 ===
==== ZME_RC2 Fernbedienung ====
siehe {{Link2Forum|Topic=35513}}<BR>
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
|-
| 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 || Nur Hauptgerät <br> Aktualisierung der Untergeräte nur bei aktiver Abfrage || Nur Hauptgerät <br>Aktualisierung der Untergeräte nur bei aktiver Abfrage
|-
| Leistungsmessung || Separat für Untergeräte || Nur Summe || Nur Summe
|-
| Leitungssicherung nötig || ja, 2x 6.5A, Summe max 10A || ja, max 2x 4A || nein
|}

== Links ==
=== Allgemein ===
* 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]
* [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, 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:
** [http://www.z-wavealliance.org/ http://www.z-wavealliance.org/] (englisch)
** [http://www.zwaveeurope.com/ http://www.zwaveeurope.com/] (englisch)
** [http://www.zwave.de/ 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; nicht auf aktuellem Stand)

=== Informationsquellen zur Einbindung von Command Classes ===
Offizielle und ausführliche Informationen von Sigma Designs (veröffentlicht am 31.08.2016):
* [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 ==
=== 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!
# [[#Hinzufügen eines neuen Z-Wave Geräts / Inklusion|Inklusion]] des Gerätes
# [[#Assoziation|Assoziation]] der Assoziationsgruppe(n) des Gerätes mit dem Gateway
# [[#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? ===
* 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).
* 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? ===
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 <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".

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.

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 nicht erneut vergeben. Nur bei einem Controller-Reset, der mit einem unwiederbringlichen Verlust sämtlicher Informationen des ZWave-Netzes und Neuvergabe der HomeID verbunden ist, beginnt die Zählung wieder von vorne.

=== 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:
* 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 <code>classes</code> 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 ({{Link2Forum|Area=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 <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/master/ressources/openzwave/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.

=== 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 <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.
(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? ===
* 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
* [[How_to_write_a_patch|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 <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.
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.
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:

<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:Z-Wave Components|!]]
[[Kategorie:868MHz]]

Z-Wave

2019-03-10T11:44:44Z

Markus1407: /* Links */

<div style="float:right">{{Infobox Modul
|Name=ZWDongle
|ModPurpose=Einbindung Z-Wave-Gateways
|ModType=d
|ModCmdRef=ZWDongle
|ModForumArea=ZWave
|ModTechName=00_ZWDongle.pm
|ModOwner=Rudolf König ([http://forum.fhem.de/index.php?action=profile;u=8 Forum])
}}
{{Infobox Modul
|Name=ZWave
|ModPurpose=Ansteuerung Z-Wave-Geräte über ZWDongle
|ModType=d
|ModCmdRef=ZWave
|ModForumArea=ZWave
|ModTechName=10_ZWave.pm
|ModOwner=Rudolf König ([http://forum.fhem.de/index.php?action=profile;u=8 Forum])
}}
</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 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.
== 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:
# '''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.
# '''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: [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")[https://web.archive.org/web/20160319202135/http://wiki.zwaveeurope.com/index.php?title=SDK_Versions_and_Explorer_Frames].

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

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

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 ===
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 (beispielsweise Devolo, AEOTEC). Man sollte bei allen Produkten auf folgenden Seiten nach eventuellen ausführlicheren Handbüchern suchen:
* Herstellerseite des ZWave-Gerätes
* http://www.zwave.de/handbuecher/ (deutsch)
* http://products.z-wavealliance.org (englisch)
Insbesondere auf http://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 ==
{{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 ===
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 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 [[Trick_der_Woche#CUL_.26_CO_.C3.BCber_Serial_ID-einbinden|Serial-by-Id]] oder [[LinuxDeviceNaming|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 <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> 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 <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.

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:
* <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 />
* 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><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 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.

=== Assoziation ===
{{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.

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

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.

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|Konfiguration]] des Gerätes.

=== Konfiguration ===
{{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>
Für weitere Parametergrößen gibt es die Befehle <code>configWord</code> und <code>configLong</code>

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

=== 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 [[#Hinzufügen eines neuen Z-Wave Geräts / Inklusion|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 <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 ===
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 <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 ==
=== 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
:<code>Scheduled for sending after WAKEUP</code>
::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.

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

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> oder -falls vorhanden- mit <code>get <name> configAll</code> ü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 [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 ===
Ausführliche Handbücher und technische Informationen auf https://aeotec.freshdesk.com/support/home

==== Multi Sensor 5 ====
* aktuellste Firmware installieren
* 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)
* 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).
* [http://devel.pepper1.net/zwavedb/device/407 Paramterübersicht pepper-Datenbank]
siehe {{Link2Forum|Topic=34505|Message=268913}}

==== Multisensor 6 ====
siehe {{Link2Forum|Topic=40393}}
* 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 ====
siehe {{Link2Forum|Topic=40504}}

=== Danfoss ===
==== 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}}):
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}}).

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

==== MT02648 Tür-/Fenster Kontakt 3in1 ====
siehe {{Link2Forum|Topic=41337}}

=== 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.
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 ===
Association Group für Übermittlung von Statusinformationen an den Controller:
* "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 / 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: {{Link2Forum|Topic=50176}}

Hinweis zum Reset: {{Link2Forum|Topic=55190|Message=469393}}

==== FGK-101 Tür/Fensterkontakt ====
* Besonderheiten bei Anschluss eines Temperatursensors: {{Link2Forum|Topic=38012}}

=== GE ===
==== GE (Model t.b.d) ====
Dieser Schalter unterstützt keine Statusrückmeldungen.

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

=== Philio ===
==== PHI_PAN04 Relais Unterputzeinsatz 2 Schalter a 1.5kW mit Messfunktion ====
siehe {{Link2Forum|Topic=28046}}

=== Popp ===
==== POPE004001 Z-Wave Rauchmelder mit Innensirene ====
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 ===
==== ZME_RC2 Fernbedienung ====
siehe {{Link2Forum|Topic=35513}}<BR>
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
|-
| 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 || Nur Hauptgerät <br> Aktualisierung der Untergeräte nur bei aktiver Abfrage || Nur Hauptgerät <br>Aktualisierung der Untergeräte nur bei aktiver Abfrage
|-
| Leistungsmessung || Separat für Untergeräte || Nur Summe || Nur Summe
|}

== Links ==
=== Allgemein ===
* 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]
* [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, 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:
** [http://www.z-wavealliance.org/ http://www.z-wavealliance.org/] (englisch)
** [http://www.zwaveeurope.com/ http://www.zwaveeurope.com/] (englisch)
** [http://www.zwave.de/ 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; nicht auf aktuellem Stand)

=== Informationsquellen zur Einbindung von Command Classes ===
Offizielle und ausführliche Informationen von Sigma Designs (veröffentlicht am 31.08.2016):
* [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 ==
=== 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!
# [[#Hinzufügen eines neuen Z-Wave Geräts / Inklusion|Inklusion]] des Gerätes
# [[#Assoziation|Assoziation]] der Assoziationsgruppe(n) des Gerätes mit dem Gateway
# [[#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? ===
* 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).
* 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? ===
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 <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".

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.

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 nicht erneut vergeben. Nur bei einem Controller-Reset, der mit einem unwiederbringlichen Verlust sämtlicher Informationen des ZWave-Netzes und Neuvergabe der HomeID verbunden ist, beginnt die Zählung wieder von vorne.

=== 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:
* 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 <code>classes</code> 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 ({{Link2Forum|Area=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 <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/master/ressources/openzwave/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.

=== 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 <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.
(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? ===
* 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
* [[How_to_write_a_patch|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 <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.
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.
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:

<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:Z-Wave Components|!]]
[[Kategorie:868MHz]]

Hue

2019-01-14T09:55:10Z

Markus1407: /* HUE-Bridge */

<div style="float:right">{{Infobox Modul
|Name=HUEBridge
|ModPurpose=Anbindung Bridge des Philips Hue Lighting System
|ModType=d

|ModCmdRef=HUEBridge
|ModForumArea=Beleuchtung
|ModTechName=30_HUEBridge.pm
|ModOwner=Andre ([http://forum.fhem.de/index.php?action=profile;u=430 Forum] / [[Benutzer Diskussion:justme|Wiki]])
}}
{{Infobox Modul
|Name=HUEDevice
|ModPurpose=Ansteuerung Geräte des Philips Hue Lighting System über HUEBridge
|ModType=d

|ModCmdRef=HUEDevice
|ModForumArea=Beleuchtung
|ModTechName=31_HUEDevice.pm
|ModOwner=Andre ([http://forum.fhem.de/index.php?action=profile;u=430 Forum] / [[Benutzer Diskussion:justme|Wiki]])
}}
</div>

== HUE-Bridge ==

=== Einrichtung in fhem ===
Die Einrichtung ist wirklich einfach. Mit

<code>define Wiesollesheißen HUEBridge eu.re.ip.1</code>

wird die Bridge eingebunden. Dann einfach auf den runden Knopf in der Mitte der Bridge drücken und sie wird von FHEM erkannt. Die drei Lampen des Starterkits werden automatisch erkannt und sind ansteuerbar -> fertig!

WICHTIG: danach in FHEM einmal die Konfiguration speichern damit der Pairing-Key gesichert wird. Sonst muss beim nächsten FHEM-Neustart das Pairing erneut durchgeführt werden.

Eine ausführliche Anleitung mit Bildern zudem unter: http://www.meintechblog.de/2014/11/philips-hue-so-klappt-die-integration-in-fhem/

Falls die Hue Bridge resetet wurde bleibt der Status auf "paired" und geht nicht mehr auf connected. Um das paring erneut durchzuführen muss das Attribut "key" gelöscht werden.

=== Nonblocking ===
Wenn man möchte, dass die Versuche, die HUEBridge zu kontaktieren, FHEM nicht blockieren, sollte man

<pre>attr <HUEBridge_Name> httpUtils 1</pre>

setzen.

== HUE-Device ==
Als Gerät können alle Hue und LightLink kompatiblen Modelle verwendet werden. Dies sind unter anderem:
*HueBulbs (E27, GU10, Lux, White, ...)
*Hue Beyond und Phoenix
*Friends of Hue LightStrips und LivingColors Bloom
*LivingColors ab gen2
*LivingColors Bloom, Iris und Aura
*LivingWhites Energiesparlampen
*LivingWhites Leuchtenadapter
*LivingWhites Bulbs
*[[HUE_Dimmer_Switch|Hue Tap und Hue Dimmer]] (mit Einschränkungen)
*dresden elektronik Vorschaltgeräte
*OSRAM LIGHTIFY Lampen (an der Hue Bridge angelernt)

Diese sind jeweils über eine Bridge (HueDevice) steuerbar. Die LivingColors und LivingWhites Geräte sind vorher mit Hilfe einer LivingColors oder LivingWhites Fernbedienung an der Bridge anzulernen.

Es werden auch alle HUE Sensoren unterstützt. Diese werden aber nicht per autocreate angelegt sondern müssen manuell definiert werden. Hier ist auf ein passendes polling Intervall zu achten. Siehe: [[HUE_Dimmer_Switch|HUE Dimmer Switch]]. Das [[Hue#RaspBee|RaspBee]] Gateway unterstützt auch ein PushAPI über das Sensoren ohne polling eingebunden werden können.

=== Grundlagen - Farbmodelle ===
Ein HueDevice kann per set-Befehl über unterschiedliche Farbmodelle gesteuert werden. In der folgenden Tabelle ist dargestellt, welche Werte-Kombinationen sinnvoll sind:
{| class="wikitable"
|-
! Farbmodell !! Bestandteile !! Beispiel
|-
| xyY || x- und y-Koordinate im Farbraum, Y ist die Helligkeit || <code> set bulb1 xy 0.4595,0.4105 : bri 220 </code>
|-
| hue,sat,bri || Farbwert, Sättigung und Helligkeit || <code> set bulb1 hue 14922 : sat 144 : bri 220 </code>
|-
| ct || Farbwert über Farbtemperatur || <code> set bulb1 color 2600 </code>
|-
| rgb || Farbbestandteile rot, grün und blau || <code> set bulb1 rgb FFC698 </code>
|}
'''Hinweis:''' Zur Regelung der Helligkeit sind die Befehle ''bri'' und ''pct'' gleichwertig. ''bri'' hat den Bereich 0..254, ''pct'' 0..100 .<br>
Das Modul lässt die Mischung von Angaben aus unterschiedlichen Farbmodellen technisch zu, jedoch sind diese nicht immer sinnvoll.

=== Darstellung im Webfrontend ===
Wenn man die SVG Icons verwendet ist es sinnvoll, das Attribut color-icons zu setzen. Mit <code>attr HUEDevice1 color-icons 2</code> werden z.B. die Farben und der Dimmzustand der Lampe als Icon dargestellt.
Damit das ganze funktioniert, müsst ihr auch noch das <code>attr WEB iconPath fhemSVG:openautomation:default</code> setzen.

== RaspBee & ConBee ==
Das HUEBridge Modul unterstützt auch die ZigBee Gateway Module RaspBee und ConBee von Dresden Elektronik über die zugehörige deCONZ Software und die Wireless Light Control WebApp und die Phoscon WebApp (kommt zusammen mit deConz). Die hierzu erhältlichen Funk-Vorschaltgeräte sind noch nicht getestet sollten aber auch funktionieren.

Im {{Link2Forum|Topic=80985|LinkText=Forum}} gibt es eine Betaversion der HUE Module, die das deCONZ PushAPI über Websockets unterstützen. Sensoren müssen hier nicht mehr gepollt werden.

Mittlerweile funktioniert die Einbindung der RaspBee und ConBee Module auf einem sehr einfachen Weg. Dieser ist in {{Link2Forum|Topic=95288|LinkText=Forum}} zusammengefasst. Zusätzliche Plugins sind nicht mehr nötig.

== HUE auf der Fritzbox ==
Da auf der FB standardmäßig kein JSON installiert ist, muss dies nachinstalliert werden: Man lädt das JSON-Paket http://search.cpan.org/CPAN/authors/id/M/MA/MAKAMAKA/JSON-2.53.tar.gz, packt es aus und kopiert den Inhalt vom <b>lib-Verzeichnis</b> nach \fhem\lib\perl5\site_perl\5.12.2

== HUE auf der Synology Diskstation ==
Da auf der DS standardmäßig kein JSON installiert ist, muss dies nachinstalliert werden, die Anleitung dazu {{Link2Forum|Topic=19093|Message=224641|LinkText=hier}}

[[Kategorie:ZigBee Components]]
[[Kategorie:ZigBee]]
[[Kategorie:Lichteffektgeräte]]
[[Kategorie:IP Components]]

LaCrosseGateway V1.x

2018-08-20T21:16:05Z

Markus1407: z

Diese Wiki-Seite beschreibt ausschließlich das LaCrosseGateway V1.x, das auf dem ESP8266 basiert.<br/>
Für das LaCrosseGateway32 [https://forum.fhem.de/index.php?topic=70338.0] das auf dem ESP32 basiert, wird es eine eigene Seite geben.{{Randnotiz|RNText=Dokumentationsstand Version 1.27}}

Das LaCrosseGateway (hier und im Forum auch mit LGW abgekürzt) erfüllt den gleichen Zweck wie ein [[JeeLink|JeeLink USB-Stick]] und zwar das Empfangen, Abfragen und Steuern von funkbasierten LaCrosse Sensoren und Aktoren, die im 868 MHz FSK Sendeverfahren arbeiten (OOK-Sendeverfahren (433 Mhz) wird nicht unterstützt). Die Verarbeitung der Daten und Steuerung der Aktoren erfolgt mithilfe von FHEM, das als zentrale Steuereinheit dient.
Der signifikante Unterschied zu einem JeeLink USB-Stick ist der Betrieb über Wireless LAN ([https://de.wikipedia.org/wiki/Wi-Fi WiFi]).
Das Herzstück des LaCrosse-Gateways besteht aus einem ESP8266-12E/F. Das LaCrosseGateway ist aufgrund des hohen Stromverbrauchs nicht für den Akkubetrieb geeignet.

Der Einsatz eines WiFi-LaCrosse-Gateways bietet folgende Vorteile:
*Kann an eine Stelle platziert werden, an der alle Sensoren optimal empfangen werden, dafür ist nur Strom (5V/1A USB Netzteil) und [https://de.wikipedia.org/wiki/Wi-Fi WiFi] Access Point erforderlich
*Im Minimalausbau nur zwei Bauteile NodeMCU DEVKIT 1.0 + RFM69 (siehe Bauteile) nötig
*Alternativ am USB-Port wie ein JeeLink verwendbar
*Einsatz von on board Sensoren / Aktoren (siehe [[#Unterstützte Sensoren und Aktoren | Unterstützte Sensoren und Aktoren]]) möglich

Hinweis: Die Anbindung in FHEM kann zwar noch mit dem JeeLink-Modul erfolgen, aber es ist sinnvoll, auf das LaCrosseGateway-Modul (36_LaCrosseGateway.pm) umzustellen, da dieses eine bessere Unterstützung für die Funktionen des LGW bietet.

=Hardware=
==Bauteile==
Für das WiFi-LaCrosse-Gateway werden folgende Bauteile verwendet:
*[Option 1] [http://www.esp8266.com/wiki/doku.php?id=esp8266-module-family#esp-12-e_q ESP8266 ESP-12E Modul].<br />Diese Variante eignet sich für Projekte für die eine kleine Bauform benötigt wird.<br />Für die Inbetriebnahme, insbesondere für das Aufbringen der Firmware, muss das Modul an ein [[Medium:Lgw USB2Serial Adapter.jpg|USB2Serial-Adapter]], angeschlossen werden. Für diese Variante sind Lötkenntnisse erforderlich.
*[Option 2] [https://raw.githubusercontent.com/nodemcu/nodemcu-devkit-v1.0/master/Documents/NodeMCU_DEVKIT_1.0.jpg NodeMCU DEVKIT 1.0 (oder 2.0)]ist die Inbetriebnahme einfacher, da alles für das Aufbringen der Firmware bereits vorhanden ist und kein Löten nötig ist.<br />{{Link2Forum|Topic=45594|Message=430183|LinkText=Hinweis:}} Folgende Devkits werden nicht "offiziel" unterstützt, da ungetestet, können aber durchaus in bestimmten Fällen verwendet werden:
** V0.9 (da ungetestet, bekommt man aber kaum noch zu kaufen)
** V3.0 - passt nicht auf die Platine von PeMue, ist größer als das 2.0. Auf der Rückseite steht "Lolin".
** Devkits mit einem CH340 USB converter (da ungetestet und teils falsche Bauform und von der USB-Anbindung her teils problematisch)
*[Option 3] Alternativ zu einem Devkit 1.0 kann auch ein [http://www.wemos.cc/Products/d1_mini.html "WeMOS D1 mini"] eingesetzt werden. Vorteil bei diesem Kit ist die kleine Bauform bei gleichem Funktionsumfang wie das DEVKIT 1.0.
*[Option 4] ESP8266-07 auf einem DEVKIT 1.0. für den Betrieb mit einer externen Wifi Antenne.
**''Hinweis:'' Der ESP-07 hat einen 25Q80 1M flash Chip. Dieser ist für den Betrieb mit der LaCrosseGateway Firmware geeignet, für ein OTA-Update ist es jedoch zu wenig. Aus diesem Grund muss/kann dieser auf 4M flash umgebaut werden. Weitere Informationen und Details zum Umbau sind im {{Link2Forum|Topic=45594|Message=448307|LinkText=Forenthread (Gehäuse-Variante)}} beschrieben.
*[Optional] RFM69CW - Für das Senden und Emfangen funkbasierte LaCrosse Aktoren und Sensoren
*[Optional] On board Sensoren (siehe [[#Unterstützte Sensoren und Aktoren | Unterstützte Sensoren und Aktoren]])
*[Optional] SC16IS750 Zur Bereitstellung der seriellen Schnittstelle, da die GPIOs (GPIO1 / GPIO3) DEVKIT's V1.0 von FTDI verwendet werden und damit nicht genutzt werden können.
*[Optional] OLED-Display SSD1306 I2C zur Darstellung von Daten (Bootvorgang, on board Sensoren, Inhalte aus FHEM)
*[Optional] [[#MCP23008|MCP23008]] zur Bereitstellung (Konfigurierbar) von digitalen 8 Ein- Ausgängen oder Sonderfunktion (OLED)
*[Optional] Nextion Touch Display zur Darstellung von verschiedenen Informationen oder zum Schalten von Aktoren.
*Steckbrett (inkl. Kabel/Widerstände)/Lochrasterplatine (Lötkolben, Lötzinn, Widerstände etc.)) / [[#Platine|PeMue Platine]]

==Schaltung==
===Variante: Devkit 1.0 Minimum===
[[Datei:lgw_Schaltplan_Devkit_minimum.png|400px|thumb|left|Variante: Devkit 1.0]]
<div style="clear:both;"></div>
===Variante: Devkit 1.0 Maximalausbau===
[[Datei:lgw_Schaltplan_Devkit_full.png|400px|thumb|left|Variante: FTDI]]
<div style="clear:both;"></div>
===Variante: Platine (PeMue)===
siehe hier: {{Link2Forum|Topic=45594|LinkText=Thread}}
<div style="clear:both;"></div>
Siehe [[#Erweiterungsmöglichkeiten | Erweiterungsmöglichkeiten]].

===MCP23008===
I2C Adresse 0x27 -> A0,A1,A2 = 3.3V
<syntaxhighlight lang="php">
|-------\/-------|
LGW D1 |1 SCL VDD 18| LGW 3.3V
LGW D2 |2 SDA GP7 17| PB7 --/ --- GND or Output
LGW 3.3V |3 A2 GP6 16| PB6 --/ --- GND or Output
LGW 3.3V |4 A1 GP5 15| PB5 --/ --- GND or Output
LGW 3.3V |5 A0 GP4 14| PB4 --/ --- GND or Output
LGW 3.3V |6 RES GP3 13| PB3 --/ --- GND or Output
|7 NC GP2 12| PB2 --/ --- GND or Output
|8 INT GP1 11| PB1 --/ --- GND or Output
LGW GND |9 VSS GP0 10| PB0 --/ --- GND or Output
|----------------|</syntaxhighlight>

===Nextion Display===
Angeschlossen wird das Display wie folgt:
GPIO0: TXD -> Nextion RXD
GPIO2: RXD -> Nextion TXD

Das Display benötigt eine 5V Spannungsversorgung, diese kann vom VIN des DevKit's abgegriffen werden. Vom Betrieb mit 3.3V wird abgeraten.
Ein level shifter für RXD/TXD ist nicht nötig.

==Aufbau auf einem Steckbrett==
[[Datei:lgw_Steckbrett.png|600px|thumb|left|LaCrosseGateway Aufbau auf einem Steckbrett]]
<div style="clear:both;"></div>
'''''Hinweis:''' Der Sender und Empfänger RFM12, der auf dem Steckbrett zu sehen ist, wird nicht mehr unterstützt.''

==Platine==
PeMue (vielen Dank) hat {{Link2Forum|Topic=45594|LinkText=hier}} eine Platine (7,1cm x 5,0cm) für das LaCrosseGateway entworfen (Stand 05.2016).

===Oberseite===
[[Datei:lgw_Platine_Oberseite.jpg|400px|thumb|left|LaCrosseGateway Platine Oberseite]]
<div style="clear:both;"></div>

===Unterseite===
[[Datei:lgw_Platine_Unterseite.jpg|400px|thumb|left|LaCrosseGateway Platine Unterseite]]
<div style="clear:both;"></div>

===Devkit 1.0 bestückt Oberseite===
[[Datei:Lgw_Platine_Devkit_oberseite.png|400px|thumb|left|LaCrosseGateway Platine Oberseite]]
<div style="clear:both;"></div>

===Devkit 1.0 bestückt Unterseite===
[[Datei:lgw_Platine_Devkit_unterseite.png|400px|thumb|left|LaCrosseGateway Platine Unterseite]]
<div style="clear:both;"></div>

===ESP8266-12E bestückt Oberseite===
{| class="galleryTable noFloat"
|-
| [[Datei:lgw_Platine_ESP-12E_oberseite.png|400px|thumb|left|(1) LaCrosseGateway Platine Oberseite mit 2 x RFM69CW, BME280 und DHT22]]
| [[Datei:lgw_Platine_ESP-12E_oberseite_2.jpg|490px|thumb|left|(2) LaCrosseGateway Platine Oberseite mit 2 x RFM69CW, BME280]]
| [[Datei:lgw_Platine_ESP-12E_oberseite_2_inkl_GE.jpg.jpg|325px|thumb|left|(2) LaCrosseGateway Platine Oberseite mit 2 x RFM69CW, BME280 inkl. Gehäuse]]
|}
'''''Hinweis:''' Die Platine (Bild (1)) ist mit einem LM75 Sensor bestückt. Diese Bestückung macht zusammen mit einem BME280 keinen Sinn, es handelt sich hierbei um eine Entwicklungsplatine.''

===ESP8266-12E bestückt Unterseite===
{| class="galleryTable noFloat"
|-
| [[Datei:lgw_Platine_ESP-12E_unterseite.png|400px|thumb|left|(1) LaCrosseGateway Platine Unterseite]]
| [[Datei:lgw_Platine_ESP-12E_unterseite_2.jpg|415px|thumb|left|(2) LaCrosseGateway Platine Unterseite mit 2 x RFM69CW, BME280]]
|}

===Platine bestücken (Hinweise und Tipps)===
*Auf der Platine (Version 1.0) ist für das RFM69CW-Modul eine Markierung (zwei Quadrate) aufgedruckt, die den Chip und den Quarz symbolisieren. Wenn man den RFM69CW so drauflötet, wie abgebildet, ist er falsch rum drauf.<br />Es muss darauf geachtet werden, wo auf dem RFM69CW die "Ant" Beschriftung steht, dieser Lötpunkt muss auf die Platine an den Punkt "1" ausgerichtet werden. Zur Sicherheit bitte den [[#Variante: Platine (PeMue)|Schaltplan]] konsultieren und die genaue Position ermitteln.<br>'''Für die Platine V1.1 wurde das korrigiert.'''
*Die Antennenlänge für das RFM69CW beträgt 82 mm. Dafür möglichst eindrähtigen Leiter (aus Kupfer) verwenden.

==Erweiterungsmöglichkeiten==
Das LaCrosseGateway kann optional mit verschiedenen Komponenten erweitert werden.

Folgende Erweiterungen sind möglich:
*es kann ein eigener Prozessor (mit eigener Firmware) angeschlossen werden, der Daten empfängt und diese dem LGW übergibt.
*es kann z.B. ein NanoCUL angeschlossen werden, dessen serielle Schnittstelle transparent auf einem Port im Web bereitgestellt wird.
*es kann ein vierter und fünfter RFM69CW angeschlossen werden, diese können alles, was die bisherigen drei auch können.
*es kann ein aktiver Piezo Summer (Piezo Buzzer) angeschlossen (an GPIO7 des SC16IS750) werden, um von FHEM aus das LaCrosseGateway einen Alarm ausgeben zu lassen. Hinweis: Falls der Strom von 10mA, den die Ausgänge liefern, nicht reicht, ist noch eine Transistor-Schaltstufe vorzusehen.

Alle diese Daten stellt das LaCrosseGateway per WiFi an FHEM zu, dort wird es von den entsprechenden Modulen (LaCrosseGateway, LaCrosse, PCA301, ...) weiterverarbeitet.

Alle Komponenten werden automatisch erkannt, sofern angeschlossen.
Für die Realisierung der o.g Möglichkeiten wird ein [http://www.aliexpress.com/item/1x-Breakout-Board-for-SC16IS750-I2C-SPI-to-UART-IC/1327351219.html?spm=2114.30010308.3.38.HxdznQ&ws_ab_test=searchweb201556_9,searchweb201602_2_10034_507_10020_10001_10002_10017_10010_10005_10011_10006_10021_10003_10004_10022_10009_10008_10018_10019,searchweb201603_6&btsid=97b30f2b-e937-426b-8202-de585dd7ee97 SC16IS750] verwendet.

Der SC16IS750 wird per I2C an das LaCrosseGateway angeschlossen und bietet eine serielle Schnittstelle und 8 Digital I/Os

'''Auf dieser Basis sind momentan folgende Erweiterungen möglich:'''

===SubProzessor===
Der SubProzessor dient dazu, dass mit einem eigenen Sketch Daten erfasst werden können, ohne sich um die ganze Nummer, die das LGW macht (WiFi, Kommunikation mit FHEM, Frontend, OTA, ...), kümmern zu müssen.
Ferner ermöglicht es die Implementierung von eigenen Projekten, dabei werden die zeitkritischen Abläufe des LGWs nicht beeinträchtig.

An die serielle Schnittstelle des SC16IS750 kann optional ein Arduino angeschlossen werden (z.B. ein Pro Mini)
Entweder ein 3.3V / 8MHz oder ein 5V / 16MHz, der aber dann auch mit 3.3V betrieben wird.

'''''Wichtig:''' Alle LaCrosseGateway Komponenten laufen ausschließlich mit '''3.3V''', aus diesem Grund dürfen keine '''5V''' Komponenten angeschlossen werden.''

'''Firmware flashen'''

Die Firmware kann über das LGW auf den SubProzessor (Voraussetzung: Arduino hat einen bootloader) geflasht werden.

Dazu wird sie auf das LGW hochgeladen (<nowiki>http://<LGW-IP>/ota/addon.hex</nowiki>).

Das LGW nimmt den Upload entgegen, wandelt das Intel-Hex in binary um und schickt es per STK500-Protokoll an den Arduino.

Falls ein OLED angeschlossen ist, wird sogar ein progress angezeigt.

'''Vorgehen Firmware flashen'''

Die Firmware kann z.B. mithilfe von "curl" mit dem nachfolgendem Befehl hochgeladen werden:
<syntaxhighlight lang="php">curl --http1.0 -H "Content_Type:multipart/form-data" -F "file=@/myFolder/LGW-Addon.ino.hex; filename=addon.hex" http://192.168.31.211/ota/addon.hex</syntaxhighlight>

'''''Hinweis:''' fielname=addon.hex im Beispiel darf nicht verändert werden, nur /myFolder/LGW-Addon.ino.hex und die IP-Adresse wird entsprechend angepasst.''

Der Upload dauert etwas, danach sollte bei Erfolg vom LGW ein Protokoll zurückgeschickt bekommen, der wie folgt aussieht:
<syntaxhighlight lang="php">Start receiving 'addon.hex'
File: /addon.hex Size: 21417
Starting flash
Sending sync
Enter program mode
Binary size is:7608
Leave Program Mode
Flash finished</syntaxhighlight>

Mit dem SubProzessor können die entsprechenden Daten auf zwei mögliche Arten am LGW übermittelt werden:

'''KeyValueProtokoll (KVP):'''
Format:<syntaxhighlight lang="php">KV <Type> <Address> <Key>=<Value>,<Key>=<Value>,<Key>=<Value>, ...</syntaxhighlight>
Beispiel:<syntaxhighlight lang="php">KV DHT 01 Temperature=21.5,Humidity=62</syntaxhighlight>

Das LGW übermittelt die Daten als KVP an FHEM und dort entsteht ein KVP Device, das die Daten darstellt.

'''LaCrosse:'''

Format:<syntaxhighlight lang="php">LC <Address> T=<Temperature>,H=<Humidity></syntaxhighlight>
Beispiel:
<syntaxhighlight lang="php">LC 9F T=21.5,H=62</syntaxhighlight>
<syntaxhighlight lang="php">LC 9F T=21.5</syntaxhighlight>
Das LGW setzt die Werte in das LaCrosse Protokoll um (wie z.B. ein TX29DTH) und schickt sie an FHEM.
In FHEM entsteht ein LaCrosse Device (autocreate, LaCrossePairForSec ...), als ob es ein LaCrosse Sensor wäre.

Das [https://forum.fhem.de/index.php?action=dlattach;topic=43672.0;attach=48914 LGW-Addon.ino] ist ein einfaches Beispiel, das diese Technik veranschaulicht.
Es bindet den geliebten DHT22 an und sendet ihn als LaCrosse-Sensor (über das LGW) an FHEM und es misst die Spannung und sendet sie zusammen mit der UpTime des SubProzessors als KVP

Der umrandete Bereich [[#Addon Schaltung |Schaltung - "Example"]] "Example" ist das zu [https://forum.fhem.de/index.php?action=dlattach;topic=43672.0;attach=48914 LGW-Addon.ino] passende Beispiel.

==Unterstützte Sensoren und Aktoren==
Alle Sensoren und Aktoren, die auch vom "LaCrosse Arduino" Sketch unterstützt werden.<br />
(siehe [[JeeLink#Unterst.C3.BCtzte_Sensoren_und_Aktoren_incl._Wetterstation_WS_1600JeeLink|vom JeeLink unterstützte LaCrosse Sensoren und Aktoren]])

Zusätzlich zu LaCrosse werden auch die folgenden Geräte unterstützt:
{| class="wikitable"
!Bezeichnung !! Datenrate !! Sonstiges !! Funktion !! Hinweise
|-
| PCA301 ||868950 kHz (868,970 und 868,990 ) 6.631 kbps || extern || Energiemess-Steckdose (Unterstützt werden bis zu 50 Dosen) ||
|-
| EC3000 ||868.300 kHz mit 20.000 kbps|| extern || Energiemess-Steckdose ||
|-
| RFM69CW || || on board || Zum Empfangen und Senden von Sensor/Aktor Daten.|| Hinweise DHT22 beachten.
|-
| BME280 || || on board || Temperatur, Feuchte und Druck || Falls das verwendete Breakout bereits PullUp-Widerstände für SDA und SCL enthält, sind diese nicht mehr zusätzlich nötig.
|-
| BMP180 || || on board || Temperatur und Druck || Falls das verwendete Breakout bereits PullUp-Widerstände für SDA und SCL enthält, sind diese nicht mehr zusätzlich nötig.
|-
| LM75 || || on board|| Temperatur ||
|-
| DHT22 || ||on board|| Temperatur und Feuchte. || Kann anstatt RFM69 Radio#3 eingesetzt werden.
|-
| SC16IS750 || I2C Adresse: 0x90 ||on board|| OI Erweiterung ||
|-
| OLED SSD1306|| I2C Adresse: 0x3C || on board || OLED Display||
|-
| MCP23008|| I2C Adresse: 0x27 || on board || Input/Output Port Expander||
|-
| Piezo Summer |||| on board ||Piezo Buzzer||
|-
| Nextion Display ||(Max.) 57600 baud || on board ||Touch Display||

|}

Alle direkt am LGW anschließbare Sensoren werden automatisch erkannt, wenn sie vorhanden sind.

<u>Sie werden in folgender Reihenfolge verwendet:</u>

Wenn ein BME280 vorhanden ist, wird dieser verwendet und sonst nichts, da man dann bereits Temperatur, Feuchte und Druck hat.

Ist kein BME280 vorhanden, wird geschaut, ob ein BMP180 vorhanden ist. Falls ja, haben wir Druck und Temperatur.

Dann wird geschaut, ob ein DHT22 vorhanden ist. Wenn ja, wird er zusätzlich verwendet, aber vom BMP180 dann nur noch der Druck.

Temperatur und Feuchte vom DHT22, dass dieses Wertepaar von einem Sensor stammt.

Wenn kein BMP180 und kein BME180 da ist, sondern nur ein DHT22, dann hat man Temperatur und Feuchte.

Wenn nichts vorhanden ist (also keiner der bisher genannten Sensoren), wird, falls vorhanden, der LM75 verwendet.

=Software=

== Release Notes ==
*[https://forum.fhem.de/index.php/topic,43672.0.html LaCrosseGateway Release Notes im Forum]

==Funktionsumfang==
*Access Point für die Konfiguration
*Konfiguration über WEB-Frontend (Erreichbar per ''<nowiki>http://IP-Adresse oder Hostname/setup</nowiki>'' auf Port 80 )
**SSID und Password (Die Konfiguration wird im EEPROM gespeichert und bei zukünftigen Neustarts verwendet.)
**Statische IP-Adresse anstatt DHCP
**Hostname
*Vom LaCrosseGateway FHEM-Modul über IP-Adresse:Port oder Hostname:Port ansprechbar. Der Port ist konfigurierbar.
*Unterstützt bis zu 5 x RFM69CW (Keine Unterstützung für RFM12)
*On board und externe Sensoren und Aktoren ([[#Unterstützte Sensoren und Aktoren |Unterstützte Sensoren und Aktoren]])
*Betrieb nur per USB möglich, als ob es ein JeeLink wäre
*FHEM Anbindung
*Log im Web-Frontend
*Firmware OTA-Update (Firmware-Over-the-Air-Update per FHEM)
*Erweiterungsmöglichkeiten per SC16IS750 (Für Buzzer und für weitere zwei RFM69)
*SubProzessor (An die serielle Schnittstelle des SC16IS750 kann optional ein Arduino angeschlossen werden (z.B. ein Pro Mini))
*Serial bridge (Optional kann die serielle Schnittstelle des SC16IS750 transparent auf einem TCP Port bereitgestellt werden)
*Software Serial Bridge - Stellt die Soft Serial Schnittstelle transparent auf einem TCP Port.

==Sourcecode==
Der Quellcode des LaCrosse Gateways befindet sich [https://svn.fhem.de/trac/export/HEAD/trunk/fhem/contrib/arduino/36_LaCrosseGateway.zip im FHEM SVN Repository (contrib)].

==Firmware Download==
Die [https://svn.fhem.de/trac/export/HEAD/trunk/fhem/FHEM/firmware/JeeLink_LaCrosseGateway.bin Firmware] befindet sich im [https://svn.fhem.de/trac/browser/trunk/fhem FHEM SVN Repository] und wird per FHEM Update verteilt. Neue Version der [https://svn.fhem.de/trac/export/HEAD/trunk/fhem/FHEM/firmware/JeeLink_LaCrosseGateway.bin Firmware] wird im {{Link2Forum|Topic=43672|LinkText=FHEM Forum "LaCrosse Gateway"}} angekündigt und der Funktionsumfang bzw. die Änderungen beschrieben.

Nach einem FEHM-Update alternativ auch: ''<FHEM-Installations-Verzeichnis>/FHEM/firmware/JeeLink_LaCrosseGateway.bin''

==Firmware aufspielen==
Wie bei einem JeeLink muss auch für das LaCrosseGateway die Firmware aufgespielt werden.

Das [https://raw.githubusercontent.com/nodemcu/nodemcu-devkit-v1.0/master/Documents/NodeMCU_DEVKIT_1.0.jpg NodeMCU DEVKIT 1.0] hat eine CP2102 UART Bridge implementiert, dafür muss ein CP2102 Treiber installiert sein.

Bei einem ESP8266-12E Modul kann die Firmware mithilfe eines Seriell-USB-Konverters aufgespielt werden.

===Windows/Mac/Linux per "esptool"===
Verifiziert und getestet wurde dieses Vorgehen auf Windows (Windows 10), Mac (El Capitan):

1) Das [https://github.com/igrr/esptool-ck/releases esptool 0.4.6] für die entsprechende Plattform herunterladen.

2) Zum Aufspielen der Firmware, muss ein Befehl nach der folgenden Syntax ausgeführt werden:
<syntaxhighlight lang="php">
esptool -vv -cp [Port] -cb 921600 -ca 0x00000 -cd nodemcu -cf [Pfad zur Firmware (bin-File)]</syntaxhighlight>
'''[Port]''' und '''[Pfad zur Firmware (bin-File)]''' müssen angepasst werden.

''Beispiel (Mac/Linux):''

<syntaxhighlight lang="php">esptool -vv -cp /dev/tty.SLAB_USBtoUART -cb 921600 -ca 0x00000 -cd nodemcu -cf JeeLink_LaCrosseGateway.bin</syntaxhighlight>

'''''Hinweis:''' Das esptool ist nicht sonderlich stabil. Es kommt vor, dass es manchmal den upload nicht startet oder nicht durchbekommt. In diesem Fall hilft es den Vorgang, auch mehrmals, zu wiederholen.''

=== Linux/Debian/Ubuntu "esptool v2.1"===

Installieren:
<syntaxhighlight lang="bash">
sudo apt-get esptool
</syntaxhighlight>

''Beispiel mit neuer Syntax bei esptool v2.1:''
<syntaxhighlight lang="bash"> sudo esptool --port /dev/ttyUSB0 write_flash 0x00000 JeeLink_LaCrosseGateway.bin</syntaxhighlight>

===Windows per "nodemcu-flasher"===

1) [https://github.com/nodemcu/nodemcu-flasher/raw/master/Win32/Release/ESP8266Flasher.exe Espressif Flashtool] downloaden und entpacken:

2) [https://svn.fhem.de/trac/export/HEAD/trunk/fhem/FHEM/firmware/JeeLink_LaCrosseGateway.bin Firmware] downloaden

3) FlashTool starten und wie folgt einstellen:

{| class="galleryTable noFloat"
|-
| [[Datei:nodemcu-flasher_1.png|450px|thumb|left|Firmware auswählen]]
| [[Datei:nodemcu-flasher_2.png|450px|thumb|left|Flash Parameter (Advanced Tab) wie abgebildet einstellen]]
|}

4) COM-Port auswählen und den Flashvorgang starten (Button: '''Flash(F)''') ...
[[Datei:nodemcu-flasher_3.png|450px|thumb|left|COM Port auswählen und das "Flashen" initiieren]]
<div style="clear:both;"></div>

Nach dem Flashen sollte über die serielle Ausgabe des ESP der Start und das Öffen des AccessPoints zu sehen sein.

'''''Hinweis:''' Die Geschwindigkeit von 921600 baud ist nicht auf jedem Rechner (besonders auf virtualisierten Systemen) machbar. In diesem Fall die Baudrate auf 57600 reduzieren.''

==Funktionsweise==
Während des Startvorgangs versucht sich das LaCrosseGateway in einem WLAN anzumelden. Dazu muss es eine SSID und das entsprechende Passwort kennen.

Beim ersten Start (nach dem initialen Aufspielen der Firmware) sind diese Informationen noch unbekannt. Aus diesem Grund wird folgende Strategie verfolgt:

Wenn es sich in keinem WLAN anmelden kann, dann öffnet es einen Access Point mit der SSID "LaCrosseGateway_'''xxxxxx'''", wobei '''xxxxxx''' die eindeutige Chip-ID des ESP8266 ist.

Der Access Point wird aus Sicherheitsgründen nach 15 Minuten wieder geschlossen.
Innerhalb dieser 15 Minuten kann man sich mit dem Access Point verbinden. Der Access Point vergibt (per DHCP) IP-Adressen aus dem Netzwerk 192.168.222.0. Anschließend kann über die LaCrosseGateway Konfigurationsseite [http://192.168.222.1/setup http://192.168.222.1/setup] die initiale Konfiguration vorgenommen werden.
Die Konfiguration wird im EEPROM gespeichert und bei zukünftigen Neustarts verwendet.
Die Konfigurationsseite ist auch im "Normalbetrieb" (ohne Access Point) über die Adresse http://''seine aktuelle IP-Adresse''/setup erreichbar.

Wenn sich das LaCrosseGateway an dem konfigurierten WLAN anmelden konnte (es wartet max. 30 Sekunden auf einen connect) und von diesem per DHCP eine IP-Adresse erhalten hat, dann stellt es auf dieser Adresse den Port 81 zur Verfügung, über den in FHEM das LaCrosseGateway Modul senden und empfangen kann.

'''Optische Darstellung der Initialisierung'''

Beim Start und der Initialisierung wird mit der Board-eigenen LED signalisieren, was gerade passiert:
*5 schnelle blinks direkt nach dem Start, als Zeichen, dass ein Reset stattgefunden hat
*Blinken im Sekundentakt, während versucht wird, sich mit einem WLAN zu verbinden.
*LED aus, wenn der Connect zu einem WLAN geklappt hat und dann vereinzeltes Blinken, wenn Daten an FHEM übermittelt werden

== LaCrosseGateway einrichten ==
Für die Ersteinrichtung des LaCrosseGateways werden die SSID und das Passwort des WLAN-Routers benötigt. Ferner wird empfohlen auf dem WLAN-Router bzw. dem DHCP-Server eine IP-Adresse für das LaCrosseGateway zu reservieren. Für die Reservierung wird die MAC-Adresse des LaCrosseGateways benötigt, diese kann über die "Home"-Page des LaCrosseGateways ermittelt, alternativ von dem [[#Windows per "nodemcu-flasher" |NODEMCU Firmware Programmer]] (''Reiter "Operation -> "STA MAC"'') entnommen werden.

Sofern diese Vorbereitungen getroffen wurden und alle Informationen vorliegen, kann das LaCrosseGateway eingerichtet werden.

'''''<u>Für die Konfiguration sind folgende Schritte nötig:</u>'''''
*Mit dem LaCrosseGateway Access Point "LaCrosseGateway_xxxxxx" verbinden (siehe [[#Funktionsweise |Beschreibung Funktionsweise]])
*Mithilfe eines Browsers die [http://192.168.222.1/setup LaCrosseGateway "Setup"-Page] öffnen
*SSID und das Password eintragen. Man kann zwei SSID/Passwort-Kombinationen mit jeweils einem Timeout konfigurieren. 120 bedeutet z.B. dass das LGW 120 Sekunden lang versucht, die SSID zu erreichen. Falls die erste SSID nach "Timeout" Sekunden nicht erreicht wurde, wird Timeout Sekunden lang versucht, die zweite SSID zu connecten.
*''[Empfohlen]'' Das Frontend Passwort festlegen
*''[Optional]'' Falls kein DHCP-Server zur Verfügung steht bzw. keine Reservierung erwünscht ist, dann muss die IP-Adresse / Netmask (Optional auch Gateway) eingetragen werden
*''[Empfohlen]'' Hostnamen festlegen bzw. anpassen
*Alle Angaben mit dem Button "save and restart" bestätigen. Dabei werden die vorgenommen Einstellungen im EEPROM gespeichert und ein Neustart des LaCrosseGateways initiiert.

Nach dem Neustart verbindet sich das LaCrosseGateway mit dem WLAN-Router.

Anschließend kann mit der [[#Hinweise zum Betrieb mit FHEM |Inbetriebnahme in FHEM]] fortgefahren werden.

==Firmware aktualisieren==

Nachfolgend werden, neben der unter dem Punkt [[#Firmware aufspielen |Firmware aufspielen]] beschriebenen Möglichkeiten, weitere Möglichkeiten zur Aktualisierung der LaCrosseGateway [[LaCrosseGateway#Firmware Download|Firmware]] aufgezeigt.

Hinweis: Die Einstellungen des LaCrosseGateway werden dabei nicht gelöscht.

=== Per FHEM (OTA-Update)===
Voraussetzungen:

*Das LGW muss auf der IP-Adresse, die im LaCrosseGateway Modul definiert ist, erreichbar sein
*Es wird kein avrdude benötigt
*Das Attribut "flashCommand" spielt keine Rolle

Die LaCrosseGateway Firmware kann von LaCrosseGateway Device (LaCrosseGateway Modul) aus mit
<syntaxhighlight lang="php">set myLaCrosseGateway flash</syntaxhighlight> aktualisiert werden.
'''''myLaCrosseGateway''' muss bei Bedarf auf den Gerätenamen in FHEM angepasst werden.''

'''''Hinweis:''' Das Update dauert ca. 30 Sekunden.''

=== Per FHEM (USB)===
Voraussetzungen:
Auf dem FHEM-Server muss Python und pyserial installiert sein. Die Installation kann z.B. so erfolgen:
*apt-get install python
*wget https://bootstrap.pypa.io/get-pip.py
*python get-pip.py
*pip install pyserial

Das Attribut "mode" muss auf USB gesetzt sein: attr myLaCrosseGateway mode USB

Der flash-Vorgang wird gestartet mit: set myLaCrosseGateway flash

=== Per CURL ===
Voraussetzungen:
*[https://curl.haxx.se/download.html curl-Tool] installiert

'''''Beispiel:'''''
<syntaxhighlight lang="php">curl --http1.0 -# -o ~output.txt -H "Content_Type:multipart/form-data" -F "file=@.\JeeLink_LaCrosseGateway.bin; filename=firmware.bin" http://192.168.31.211/ota/firmware.bin</syntaxhighlight>

'''Firmwaredateiname (file=)''' und die '''IP-Adresse''' muss entsprechend angepasst werden.

=== Per WEB OTA-Update (deprecated)===

'''''deprecated'''''

==LaCrosseGateway Web-Frontend==
===Staus-Wert RSSI===
Die WiFi Signalstärke (dBm) (-36 ist besser als -60)

===Staus-Wert FramesPerMinute===
Dieser gibt an, wie viele frames von Sensoren in der letzten Minute erfolgreich empfangen, dekodiert und verarbeitet wurden.
Es eignet sich zur Überwachung, wenn weniger als ein Grenzwert empfangen wurde, dann kann ein Alarm (Benachrichtigung, Restart etc.) ausgelöst werden.

===Staus-Wert ReceivedFrames===
Dieser Wert gibt an, wie viele seit dem Start des LGW empfangen wurden.

===WiFi "Startup-delay"===

Mit diesen Konfigurationsprameter kann eine Verzögerung (in Sekunden) definiert werden, bis das LGW nach einen Neustart einen ersten Verbindungsversuch zum WiFi Access Point (Router: Fritzbox etc.) startet.

Eine Anpassung kann für den folgenden Fall sinnvoll sein:

Nach einem Stromausfall benötigt ein WiFi Access Point (Router: Fritzbox etc.) in den meisten Fällen länger zum Starten als das LGW. In der default Einstellung führt das dazu, dass der LGW nach dem Starten versucht 30 Sekunden lang eine Verbindung zum AP herzustellen. Wenn keine Verbindung innerhalb dieser Zeit zustande kommt, dann gibt das LGW auf und macht seinen eigenen AP auf. Mit einer entsprechenden Verzögerung (Dauer bis der Router gestartet ist und der WiFi-AP zur Verfügung steht) kann sichergestellt werden, dass der AP gestartet ist und sich das LGW mit dem AP verbinden kann.

===Internal Sensors "Sensor-ID"===
Bei Einsatz von mehr als einem LaCrosseGateway, muss die LaCrosse-ID, mit der die internen Sensoren des Gateways übermittelt werden, angepasst werden.
Hierbei ist darauf zu achten, dass die LaCrosse-ID nur einmal auf einer FHEM Instanz vorkommen darf. Die ID kann entweder Dezimal (211) oder Hex (0xD3) angegeben werden.

'''''Detailinformationen:''''' Wenn ein LGW interne Sensoren hat (BME280, BMP180, DHT22, ...) dann sendet es die Daten des Sensors so, als ob es eine Wetterstation wäre (WS 1600 Format) an das LGW. Bisher hat es dafür die Sensor-ID 0 verwendet. Wenn man mehrere LGWs an ein FHEM angebunden hat, dann mischen sich deren Sensor-Daten auf dem LaCrosse device mit der ID 0. Um das zu vermeiden, kann man nun konfigurieren, mit welcher Sensor-ID die internen Sensoren gesendet werden sollen und die beiden LGWs unterschiedliche konfigurieren.

Die Anpassung der LaCrosse-ID hat keinerlei Einfluss auf die Daten, die von den Radios empfangen werden.

===Internal Sensors "Altitude"===
Mit diesen Parameter kann die Höhe über NN konfiguriert werden.

===Internal Sensors "Temperature-/Humidity-correction"===
Für Temperatur und Feuchte kann ein Korrekturwert angegeben werden.

Der Wert kann entweder ein Offset oder prozentual sein.

'''Beispiele:'''

{| class="wikitable" style="margin-left: auto; margin-left: 0px;"
! Korrekturwert !! Gemessen !! Ergebnis
|-
| -5
| 20°C
| 15°C
|-
| +3
| 20°C
| 23°C
|-
| -10%
| 20°C
| 18°C
|-
| +20%
| 20°C
| 24°C
|}

===SC16IS750-Clone===
Wenn aktiviert, wird die I2C clock auf 100 kHz runtergenommen und
es wird an einigen Stellen etwas auf die Bremse getreten, dass ein SC16IS70-Clone, der langsamer
als echte Hardware ist, mitkommt.
Sollte man ohne zwingenden Grund nicht aktivieren.

===Use MDNS===
Legt fest, ob das LGW seine IP-Adresse per MDNS bekannt gibt. Dies ist nötig, wenn man einen Mac hat oder bei Windows einen Bonjour-Service laufen hat.
Dies ist beim Entwickeln sinnvoll, kann üblicherweise ausgeschaltet bleiben.

===MCP23008===
Konfigurationsmöglichkeit für die 8 IO Pins (siehe auch [[#Inbetriebnahme_von_MCP23008|Inbetriebnahme von MCP23008]]).

===Serial bridge port und bridge baud===
Das LGW kann nun optional die serielle Schnittstelle des SC16IS750 transparent auf einem TCP Port bereitstellen.
Dazu gibt es die "Serial bridge port" und "Serial bridge baud" auf der "config"-Page des LGWs.
Das LGW überträgt transparent die Daten der seriellen Schnittstelle an FHEM und umgekehrt.

===Soft Serial Bridge===
Das LGW kann optional eine Soft serial bridge (Zuverlässig nur mit bis zu 57600 baud) transparent auf einem TCP Port bereitstellen.
Folgende Parameter können auf der LGW Setup-Page angepasst/konfiguriert werden:

{| class="wikitable" style="margin-left: auto; margin-left: 0px;"
! Parameter !! Beschreibung
|-
| Port
| Der Port, auf dem es angesprochen werden kann
|-
| Baud
| Die Baudrate für die Kommunikation
|-
| Nextion display
| Für den Betrieb eines Nextion Display muss diese Option aktiviert sein.
|-
| Add units
| Fügt an die Werte (Temp,Hum,Pres), die das LGW an das Display schickt, Einheiten an.
|}

Mithilfe des Soft serial bridge können verschiedene Geräte (nanoCUL, Nextion Display, etc.), welche per seriellen Schnitstelle kommunizieren können, in Betrieb genommen werden.

===Statuswerte abrufen===
Mit http://<IP-des-LGW>/state können die Statuswerte, die das LGW-Frontend anzeigt, als XML zur Weiterverarbeitung abgerufen werden.

Beispiel:
<syntaxhighlight lang="php"><LGW>
<Info Key="UpTimeSeconds" Value="107086"/>
<Info Key="UpTimeText" Value="1Tg. 5Std. 44Min. 46Sek. "/>
<Info Key="WIFI" Value="NeverTellThem"/>
<Info Key="MacAddress" Value="18:FE:34:9A:6D:48"/>
<Info Key="ChipID" Value="10120520"/>
<Info Key="ReceivedFrames" Value="93593"/>
<Info Key="FramesPerMinute" Value="52"/>
</LGW></syntaxhighlight>

===Funktionsweise Log===
Das Log ist als Hilfsmittel bei der Fehlersuche gedacht z.B. um bei PCA301 zu verfolgen, wann wer was wie frägt und antwortet oder um zu schauen, ob irgend welche Sensoren überhaupt empfangen werden und die Daten an FHEM geliefert werden.

[[Datei:lgw_LogPage.png|600px|thumb|left|LaCrosseGateway Log ebfrontend]]
<div style="clear:both;"></div>
Mit "Command" kann man Befehle an das LGW senden. Sie entsprechen dem, was man mit "set myLaCrosseGateway raw ..." aus FHEM schicken kann.
Die obere Liste enthält die Daten, die an FHEM übermittelt werden (bzw. würden, wenn sich ein FHEM auf das LGW verbunden hat)
Die untere Liste enthält debug-Informationen u.a. wird hier der letzte Systemstart aufgezeichnet.
Die verwendete SDK-Version und der letzte Reset-Grund werden ebenfalls ausgegeben

Das Log kann per HTTP abgerufen werden:
<syntaxhighlight lang="php">http://<LGW-IP>/getLogData</syntaxhighlight>

'''''Beispiel:'''''
<syntaxhighlight lang="php">http://192.168.31.211/getLogData</syntaxhighlight>

das Ergebnis sieht wie folgt aus:
<syntaxhighlight lang="php">DATA:OK 22 117 196 0 58 226 102 0 58 191 86 0 0 40 172 0 105 1 101 3 0 [75 C4 E2 66 00 00 BF 56 00 00 00 02 3B FC DC 00 69 01 65 4A A4 C4 F9 F2 4F 11 A4 F6 7C 03 A0 00 00 00 00 03 A0 38 09 21 27]
DATA:OK 9 11 130 4 173 125 [92 D5 97 7D 75]
DATA:OK EMT7110 84 81 8 207 0 36 0 1 1 199 1 [25 6A 54 51 40 02 00 24 C3 41 C7 9B]
SYS: AddOn: KV ADDON 01 Voltage=3.33,UpTime=4921
DATA:OK VALUES ADDON 01 Voltage=3.33,UpTime=4921
DATA:OK 9 38 1 4 67 65 [99 84 91 41 07]
DATA:OK 22 126 67 0 65 236 34 0 65 231 116 0 0 32 103 0 48 0 134 1 0 [7E 43 EC 22 00 00 E7 74 00 00 00 01 C7 AC D7 00 30 00 86 00 57 E4 69 1E 46 8E D4 68 C7 04 10 00 00 00 00 04 10 18 0A DC F7]
DATA:OK 9 36 1 4 128 61 [99 05 52 3D 96]
DATA:OK WS 0 4 4 185 255 255 255 255 255 255 255 255 255 0 3 252</syntaxhighlight>

'''''DATA:''''' für die obere Liste

'''''SYS: ''''' für die untere Liste

Bei jedem Aufruf werden die seit dem letzten Abruf neu aufgelaufenen Logeinträge geliefert.
Intern werden maximal 40 Einträge gepuffert (aber kein Ringpuffer, weil die ersten 40 mit dem Bootlog erhalten bleiben müssen)

'''''Hinweis:''''' Aus Performance- und Stabilitätsgründen sollten die Daten nicht zu häufig und nicht von zwei Instanzen gleichzeitig abgerufen werden.

=Hinweise zum Betrieb mit FHEM=

==Voraussetzungen==
Es wird ein [[#LaCrosseGateway einrichten |vorkonfiguriertes]] LaCrosseGateway vorausgesetzt.

Perl Modul: ''LWP::UserAgent'' - Dieses wird für das Firmware Update per FHEM LaCrosseGateway Modul benötigt.
Auf einem Raspberry Pi kann die Installation wie folgt durchgeführt werden:
<syntaxhighlight lang="php">sudo apt-get install libwww-perl</syntaxhighlight>
alternativ auch mit
<syntaxhighlight lang="php">sudo cpan LWP::UserAgent</syntaxhighlight>

'''FHEM Module'''

'''Hinweis:''' Ursprünglich wurde für das LaCrosseGateway das FHEM-Modul 36_JeeLink.pm verwendet. Da es aber inzwischen erhebliche Unterschiede zwischen dem JeeLink-LaCrosse-Sketch und dem LaCrosseGateway gibt, existiert seit Mitte November 2016 ein für das LaCrosseGateway spezialisiertes und optimiertes FHEM-Modul, das 36_LaCrosseGateway.pm.<br>
Dieses sollte anstatt dem 36_JeeLink.pm vorzugsweise verwendet werden.

''36_LaCrosseGeateway.pm'' (wird per FHEM Update verteilt)

''36_KeyValueProtocol.pm'' (wird per FHEM Update verteilt)

''36_LaCrosse.pm'' (wird per FHEM Update verteilt)

''36_PCA301.pm'' (wird per FHEM Update verteilt)

''36_EC3000.pm'' (wird per FHEM Update verteilt)

''36_EMT7110.pm'' (wird per FHEM Update verteilt)

''36_Level.pm'' (wird per FHEM Update verteilt)

''42_Nextion.pm'' (wird per FHEM Update verteilt)

==Device Definition==
===WLAN===
Die Definition sieht dann wie folgt aus:

<code>define <myLaCrosseGateway> LaCrosseGateway <IP-Adresse>:81</code>

''<myLaCrosseGateway>'' kann bei Bedarf angepasst werden.

''<IP-Adresse>'' muss entsprechend angepasst werden. Anstatt der IP-Adresse kann auch der Hostname vom LaCrosseGateway verwendet werden.

'''Beispiel:'''
<syntaxhighlight lang="php">define myLaCrosseGateway LaCrosseGateway 192.168.22.33:81</syntaxhighlight>
<u>IP-Adresse ermitteln:</u> Das LaCrosseGateway heist per default Einstellung "''LaCrosseGateway''", per ping auf den Hostnamen ''LaCrosseGateway'' kann die <IP-Adresse> ermittelt werden.

===USB===
Wenn man das LGW über USB betreiben will, dann möchte man üblicherweise kein WiFi.
Um das WiFi zu deaktivieren gibt es zwei Möglichkeiten:<br>
1.) Man kann mit einen 10k pullup auf 3.3V an MOSI == GPIO13 == D7 "jumpern", dass man kein wifi will. Wenn voranden, wird WiFi sofort beim Start deaktiviert.<br>
2.) Man kann WiFi auf der Setup-Page des LGW deaktivieren.<br>

Für den Betrieb via USB sieht die Definition wie folgt aus:

<code>define <myLaCrosseGateway> LaCrosseGateway <USB-Port>@57600</code>

''<myLaCrosseGateway>'' kann bei Bedarf angepasst werden.

''<USB-Port>'' muss entsprechend angepasst werden.

Beispiel: <code>define myLaCrosseGateway LaCrosseGateway /dev/ttyUSB0@57600</code>
''/dev/ttyUSB0'' Falls bereits mehrere USB Geräte angeschlossen sind muss der USB Port angepasst werden.

'''Hinweis:''' Sind mehrere USB Devices am FHEM Server (z.B. RPI, Cubietruck etc.) in Betrieb, dann ist die Zuordnung über den USB-Port nicht zuverlässig. Die Ports werden u.a. in der Reihenfolge vergeben, in der die Geräte angeschlossen werden. Zuverlässiger und eindeutiger ist die Zuordnung über die Serial-ID.

Dieser Befehl zeigt die Serial-ID der angeschlossenen USB-Devices an:
<code>ls -l /dev/serial/by-id</code>

Beispiel für die Ausgabe:
<syntaxhighlight lang="text">lrwxrwxrwx 1 root root 13 Mai 14 10:37 usb-Prolific_Technology_Inc._USB-Serial_Controller-if00-port0 -> ../../ttyUSB1
lrwxrwxrwx 1 root root 13 Mai 30 11:27 usb-Silicon_Labs_CP2102_USB_to_UART_Bridge_Controller_0001-if00-port0 -> ../../ttyUSB2
lrwxrwxrwx 1 root root 13 Apr 16 14:52 usb-Silicon_Labs_ELV_USB-Modul_UM2102_EVFSRFF8COEXIKOT-if00-port0 -> ../../ttyUSB0</syntaxhighlight>
In diesem Fall ist u.a. ein DEVKIT 1.0 mit der Serial-ID ''usb-Silicon_Labs_CP2102_USB_to_UART_Bridge_Controller_0001-if00-port0 -> ../../ttyUSB2'' angeschlossen.

Auf Basis dieser Informationen lässt sich folgende Definition erstellen:

<code>define myLaCrosseGateway LaCrosseGateway /dev/serial/by-id/usb-Silicon_Labs_CP2102_USB_to_UART_Bridge_Controller_0001-if00-port0@57600</code><br>
Wichtig ist es, die Übertragungsrate von 57600 bit/s anzugeben.<br><br>

Wenn man das LGW ohne WiFi betreibt, dann muss man natürlich auf die Annehmlichkeiten des Web-Frontends verzichten.<br>
In diesem Fall kann man die Konfiguration, die man über das Web-Frontend machen würde, über die serielle Schnittstelle machen.<br>

<code>set myLaCrosseGateway raw "SETUP ..."</code><br>
Das ... sind die gewünschten Einstellungen. Es müssen nicht alle Einstellungen gesendet werden sondern nur die, die man setzen will.<br>
Es werden nur die Einstellungen gesetzt und im EEPROM gespeichert, es wird aber kein Reboot ausgelöst<br>
Einen Reboot kann man mit "set myLaCrosseGateway raw 8377e" auslösen.<br>
Mehrere Einstellungen können durch Semikolon getrennt angegeben werden.<br>
Beispiel:
<code>set myJeeLink213 raw "SETUP UseWiFi false; IO0 OLED mode=thp; IO1 OLED Off; CorrT -2.5; ISID 213"</code>

Man kann auf der seriellen Schnittstelle die aktuellen Einstellungen abrufen.
Das command ist 1g<br>
<code>set myLaCrosseGateway raw 1g</code><br>
Man bekommt dann so etwas zurück:
<syntaxhighlight lang="text">SETUP ctSSID esesidee; ctPASS PasstWort; staticIP 192.168.31.211; staticMask 255.255.255.0; staticGW 192.168.31.1;
HostName LGW211; StartupDelay 1; ISID 0xD3; Altitude 220; CorrT 0; CorrH 0; DataPort1 81; DataPort2 82; SerialBridgePort 85;
SerialBridgeBaud 38400; UseMDNS true; IO0 OLED mode=s; IO1 OLED mode=thp; IO2 OLED On; IO3 OLED Off; oledStart 120; KVInterval 10;
KVIdentity 211; PCA301Plugs 036180=3,03A094=1,035FF1=6;</syntaxhighlight>

==Reconnect==
Falls das LaCrosseGateway nicht erreichbar ist (Kein Strom/Stromausfall, WLAN Verbingung unterbrochen etc.), bricht das LaCrosseGateway Device die Kommunikation ab. Über das entsprechende ''timeout'' Attribut kann das LaCrosseGateway device so konfigurert werden, dass es in regelmässigen Abständen erneut versucht eine Verbindung mit dem LaCrosseGateway herzustellen.

Konfigurationsempfehlung für ''timeout'' = 120 Sekunden und ''checkInterval'' = 30 Sekunden:

Der Wert kann in FHEM wie folgt gesetzt werden:
<syntaxhighlight lang="php">attr myLaCrosseGateway timeout 120,30</syntaxhighlight>
'''''myLaCrosseGateway''' muss auf den Gerätenamen in FHEM angepasst werden.''

Während das LaCrosseGateway eine WiFi-Verbindung aufbaut, benötigt das LaCrosseGateway-Modul je nach Konfiguration einige Zeit bis es einen neuen Connect auf den Datenport des LaCrosseGateway versucht. Das Finden der optimalen Werte erfordert etwas Geduld, es kann auch schon mal ein, zwei Minuten Dauern, bis die ersten Daten in FHEM übertragen werden.

'''''Erklärung der Timeout Werte:'''''
120,30 prüft alle 30 Sekunden, ob seit mindestens 120 Sekunden keine Daten mehr übermittelt wurden und falls dem so ist, macht es einen Reset auf der Schnittstelle, was die Verbindung zum LaCrosseGateway neu aufbaut. Das bedeutet, in so einem Fall ist die Verbindung nach spätestens 150 Sekunden wieder hergestellt.

'''''Hinweis:''' Mit diesem Attribut wird lediglich eine neue Verbindung aufgebaut, dabei wird das LaCrosseGateway nicht resetet.''

==Liste aller initCommands==
Eine aktuelle Liste der initCommands, die man von FHEM, Terminalprogramm oder Web-Frontend aus senden kann, sind auf dem Web-Frontend "Help"-Page" des LaCrosseGateways (ab V1.17) aufgeführt.

[http://IP-Adresse/setup http://IP-Adresse oder Hostname/help]

<syntaxhighlight lang="php">
<n>a set to 0 if the blue LED bothers
<n>c use one of the possible data rates (for transmit on RFM #1)
<n>d set to 1 to see debug messages
<8266>e Clear EEPROM
<n>f initial frequency in kHz (5 kHz steps, 860480 ... 879515)
<n>g get information (1g: get current settings)
<n>h Altitude
<n,f,i>i Init PCA for Radio #<n> to <m>MHz and <i>s Interval
<n>m bits 1: 17.241 kbps, 2 : 9.579 kbps, 4 : 8.842 kbps, 8 : 20.000 kbps (for RFM #1)
<n>M bits 1: 17.241 kbps, 2 : 9.579 kbps, 4 : 8.842 kbps, 8 : 20.000 kbps (for RFM #2)
<n>#<x>m bits 1: 17.241 kbps, 2 : 9.579 kbps, 4 : 8.842 kbps, 8 : 20.000 kbps (for RFM #x)
<n>o set HF-parameter e.g. 1,4o for RFM69
<n>p payload on the serial port (1: all, 2: only undecoded data)
<n>r use one of the possible data rates (for RFM #1)
<n>R use one of the possible data rates (for RFM #2)
<n>#<x>r use one of the possible data rates (for RFM #x)
<x,x,...>s Send to PCA301 (must be 10 byte)
<x,x,...>S Send to CustomSensor
<n>t 0=no toggle, else interval in seconds (for RFM #1)
<n>T 0=no toggle, else interval in seconds (for RFM #2)
<n>#<x>t 0=no toggle, else interval in seconds (for RFM #x)
v show version
<n>w 0=no wifi
<n>z set to 1 to display analyzed frame data instead of the normal data
</syntaxhighlight>

==LaCrosseGateway zurücksetzen==
Das LaCrosseGateway kann auf die "Werkseinstellungen" zurückgesetzt werden.<br>
Dadurch werden alle auf der Setup-Page gemachten und im EEPROM gespeicherten Einstellungen verworfen.
Der Befehl dazu lautet: <syntaxhighlight lang="php">8266e</syntaxhighlight>
Er kann mit einem Terminalprogramm, von FHEM aus mit <syntaxhighlight lang="php">set <myLaCrosseGateway> raw 8266e</syntaxhighlight> oder von der Log-Page des LGW gesendet werden.

Danach startet das LGW wieder als Access Point [[#LaCrosseGateway einrichten|initiale Konfiguration]] und die Konfiguration kann über die "Setup-Page" neu vorgenommen werden kann.

==Sensoren/Aktoren anlegen==

Voraussetzung: FHEM autocreat ist aktiv.
Die [http://fhem.de/commandref.html#autocreate FHEM autocreate Funktion] ist aktiv.

Die erkannnten Sensoren und Aktoren werden automatisch erkannt und in FHEM angelegt, sobald Daten empfangen werden.

Empfangene Sensoren werden nur hinzugefügt werden, wenn LaCrossePairForSec auf 120 Sekunden gesetzt wird.
<syntaxhighlight lang="php">set myLaCrosseGateway LaCrossePairForSec 120 ignore_battery</syntaxhighlight>

==Inbetriebnahme von BMP180 / BME280==
Damit die Daten der o.g. Sensoren in FHEM zur Verfügung stehen, muss zunächst das FHEM-Device angelegt werden.

Das Anlegen kann automatisch erfolgen, dafür muss der folgende FHEM Befehl ausgeführt werden:
<syntaxhighlight lang="php">set myLaCrosseGateway LaCrossePairForSec 120 ignore_battery</syntaxhighlight>

Dann sollte von [http://fhem.de/commandref.html#autocreate FHEM autocreate Funktion] ein LaCrosse Device mit der [[#Sensor-ID | Sensor-ID]] (Default Wert: 0) angelegt werden.

Alternativ kann das FHEM Device manuell angelegt werden:
Die '''''ID''''', mit der das LGW die internen Sensoren sendet, entspricht der konfugurierten [[#Sensor-ID | Sensor-ID]] (Default Wert: 0)
Es verhält sich so, als ob es eine Wetterstation (wie z.B. WS 1600) wäre.
<syntaxhighlight lang="php">define <name> LaCrosse 00</syntaxhighlight>
Anchließend muss eine Höhenkorrektur (Grund: der Luftdruck wird immer bezogen auf NN angegeben, der Sensor liefert aber den Absolutdruck) mit dem command '''''h''''' in den initCommands vorgenommen werden, dies erfolgt mit dem FHEM Befehl:

Beispiel: 220h legt 220m über NN fest.''
<syntaxhighlight lang="php">attr myLaCrosseGateway initCommands 220h</syntaxhighlight>

'''Besser:''' Alternativ kann die Höhe über NN auch auf der Setup-Page des LGW gesetzt werden.<br>
Das hat den Vorteil, dass sofort vom Start an der normalisierte Luftdruck an FHEM gesendet wird und nicht erst, wenn die initCommands von FHEM geschickt wurden.

==Inbetriebnahme Piezo Summer==

Der Piezo Summer wird in FHEM über das LaCrosseGateway Modul angesteuert.

'''Beispiele:'''
<syntaxhighlight lang="php">
set myLaCrosseGateway raw 1,60b -> beep ... beep ... beep 60 Sekunden lang
set myLaCrosseGateway raw 2,300b -> beep beep ... beep beep ... beep beep 300 Sekunden lang
set myLaCrosseGateway raw 3,120b -> beep beep beep ... beep beep beep ... 120 Sekunden lang
set myLaCrosseGateway raw 0b -> beep stoppen
</syntaxhighlight>

==Inbetriebnahme von RFM69CW==
Mit dem LaCrosseGateway ist es möglich mehrere RFM69CW einzusetzten. Nachfolgend wird die Konfiguration des Senders/Empfängers erläutert.

Die "Default Werte" (wenn keine Angaben definiert werden) für die data rate sind wie folgt definiert:
<syntaxhighlight lang="php">
#1 (Erste) => 17241
#2 (Zweite) => 9579
#3 (Dritte) => 8842
#4 (Vierte) => 20000
#5 (Fünfte) => 17241
</syntaxhighlight>

'''''Hinweis:''' Detailinformationen sind auch auf der LaCrosseGateway "Help"-Page zu finden.''

{| class="wikitable" style="margin-left: auto; margin-left: 0px;"
|-
|colspan="2" style="text-align:center"|'''<Datenrate>#<Radio-Nummer><command>'''
|-
| <code>m t:</code> || ''Toggle-Steuerung''
|-
| <code>r:</code> || ''Datarate''
|-
| <code>f:</code> || ''Frequenz''
|}

'''''Beispiele:'''''

''
{| class="wikitable" style="margin-left: auto; margin-left: 0px;"
!Definition !! Erläuterungen
|-
| <syntaxhighlight lang="php">attr myLaCrosseGateway initCommands 0#1r v</syntaxhighlight>
| DataRate des ersten RFM setzen
|-
| <syntaxhighlight lang="php">attr myLaCrosseGateway initCommands 8842#3r v </syntaxhighlight>
| DataRate des dritten RFM setzen
|-
| <syntaxhighlight lang="php">attr myLaCrosseGateway initCommands 868300#2f v</syntaxhighlight>
| Frequenz des zweiten RFM setzten
|-
| <syntaxhighlight lang="php">attr myLaCrosseGateway initCommands 868295#3f v</syntaxhighlight>
| Frequenz des dritten RFM setzten
|-
| <syntaxhighlight lang="php">attr myLaCrosseGateway initCommands 17241#1r 8842#2r v</syntaxhighlight>
| Zwei RFM69CW mit DataRate 17241 und 8842
|-
| <syntaxhighlight lang="php">attr myLaCrosseGateway initCommands 3#1m 20#1t 8842#2r v</syntaxhighlight>
| Zwei RFM69CW mit 20 Sekunden DataRate 17241 toggle 9579 plus 8842 permanent
|-
| <syntaxhighlight lang="php">attr myLaCrosseGateway initCommands 220h 868295#1f 868310#2f v</syntaxhighlight>
| Zwei RFMs Frequenz 868295 und 868310 sowie Höhe über NN
|-
| <syntaxhighlight lang="php">attr myLaCrosseGateway initCommands 868295#1f 3#1m 20#1t 2,868950,60i 8842#3r 220h 0a v</syntaxhighlight>
| Drei RFMs Frequenz 868295 / PCA301 / WS1600 sowie Höhe über NN <br>Radio 1 auf 868295 MHz und Toggle 9K/17K mit 20 Sekunden<br>Radio 2 für PCA301 initialisiert<br>Radio 3 macht 8842 kbps für die WS 1600<br>Höhe 220m über NN<br>Activity LED aus<br>v am Ende ruft die neu gesetzen Daten vom LaCrosseGateway ab, damit sie in FHEM LaCrosseGateway Modul aktualisiert werden.
|}

'''''Hinweis:''' Es ist wichtig ein "v" an das Ende eines initCommands anzuhängen. Damit wird veranlasst, dass das LaCrosseGateway seine neuen Einstellungen an FHEM zurückmeldet.
==Inbetriebnahme von PCA301==
PCA301 im LGW funtioniert ähnlich dem PCA301 Sketch, allerding mit einigen systembedingten Abweichungen.

Per default ist PCA301 nicht aktiviert, es muss in den initCommands aktiviert werden. Dazu gibt es das command "'''''i'''''".

'''<RadioNr>,<Frequenz>,<Poll-Intervall>i'''

Die Initialisierung kann auch erneut geschickt werden, um z.B. das Poll-Intervall zu ändern.

'''''Wichtig:''''' Es darf nur '''"ein"''' Radio für PCA301 initialisiert sein, nicht mehrere. Das PCA301 initialisierte Radio ist dediziert für PCA301 zuständig, es kann nicht zwischen anderen Protokollen (z.B. LaCrosse) toggeln.''

Das ''Poll-Interval'' sollte nicht extrem heruntergesetzt (nicht unter eine Minute) werden, da PCA301 sonst LaCrosse verdrängt. PCA301 hat hörere Priorität, da es bei der Kommunikation
mit den Dosen keine Antworten überhören darf.

Unter Umständen muss die Frequenz etwas angepasst werden, wenn das Radio und/oder die Dosen nicht genau auf 868950 liegen.
Das ist daran zu erkennen, dass entweder gar keine Antwort von den Dosen oder verzögerte Antwort ankommt.
Werte von 868960 oder 960970 haben in manchen Fällen Abhilfe gebracht.

'''''Beispiele:'''''

{| class="wikitable" style="margin-left: auto; margin-left: 0px;"
! Definition !! Erläuterungen
|-
| style="width:40%" | <code>attr myLaCrosseGateway initCommands 2,868950,120i v</code>
| Initialisiert den zweiten RFM auf 868950 MHz und setzt das Poll-Intervall auf 120 Sekunden
|-
| <code>attr myLaCrosseGateway initCommands 1,868950,120i 3#2m 20#2t 220h 0a v</code>
| Initialisierung eines LaCrosseGateways mit zwei Radios für TX29, TX35, PCA301 und BMP180/BME280.<br>Das erste Radio macht PCA301 und das zweite toggelt 17241/9579 im 20 Sekunden Takt um TX29 und TX35 zu empfangen<br>der BMP180/BME280 liefert den Druck für 220m Meereshöhe<br>die LED ist deaktiviert
|}

'''Ablauf:'''

Nachdem PCA301 initialisiert ist, lauscht das LaCrosseGateway auf der entsprechenden Frequenz.
Sobald eine Dose empfangen wurde, wird sie in der Konfiguration (EEPROM) dauerhaft registriert und ab sofort gepollt.

Das ''Polling'' funtioniert so, dass für jede Dose geschaut wird, wann sie zuletzt empfangen wurde und wenn das länger als das konfigurierte Interval zurück liegt,
dann wird sie abgefragt. Wenn sonst etwas (Basisstation, anderes FHEM) die Dose abgefragt hat und das LaCrosseGateway die Antwort gehört hat, dann gilt das auch als
empfangen und es wird kein eigener Poll für die Dose ausgelöst. ''Das Zusammenspiel mit einer echten Basisstation konnte bisher nur grob simuliert werden.''

Das ''Pairing'' (also die Vergabe eines Kanals) funktioniert wie im PCA301-Sketch, button an der Dose ''"3 Sekunden"'' drücken, dann vergibt das LaCrosseGateway den nächsten freien Kanal.
Dosen, die bereits einen Kanal haben, können durch ein Schalten vor Ort, an das LaCrosseGateway angelernt werden. Das LaCrosseGateway erkennt sie und nimmt sie in die
Konfiguration auf. Falls die Dose bereits mit einem anderen Kanal bekannt war, wird der Kanal im LaCrosseGateway aktualisisert.

Auf der Setup-Page im Web-Frontend (http://IP-Adresse oder Hostname/setup) des LaCrosseGateway kann die Liste der bekannten Dosen (ID=Kanal) eingesehen werden. Hinweis: Es sollten keine Änderungen in diesem Bereich vorgenommen werden.

Wenn ein Kommando (Schalten, Daten abfragen, ...) an eine Dose gesendet wurde und keine Antwort kam, wird bereits im Sketch drei mal versucht, eine Antwort zu bekommen.

Das PCA301 Modul in FHEM funktioniert komplett wie bisher.

Weiterführende Themen zum PCA301 sind im Wiki [[PCA301 Funkschaltsteckdose mit Energieverbrauchsmessung]] und PCA301 FHEM Thread {{Link2Forum|Topic=11648|LinkText=JeeLink / PCA301 Thread}} beschrieben.

Die Befehle, die der PCA301-Sketch kennt, gibt es im LaCrosseGateway nur teilweise:
{| class="wikitable" style="margin-left: auto; margin-left: 0px;"
! Befehl (Beschreibung)!! Erläuterungen
|-
| <code>a "turn activity LED on or off</code>
| wie bisher
|-
| <code>l "list known devices"</code>
| entfallen, kann man nun im Web-Frontend sehen
|-
| <code>q "turn quiet mode on or off"</code>
| wie bisher
|-
| <code>r "list recordings"</code>
| entfallen
|-
| <code>s "send to plug"</code>
| wie bisher
|-
| <code>v "report version and configuration parameters"</code>
| wie bisher
|-
| <code>d, e, p "poll / turn a device on / off"</code>
| entfallen
|-
| <code>h, +, -, # "modify and display RF12 Frequency register"</code>
| entfallen, ersetzt durch das "i" command bzw. das bereits vorhandene "f" command
|}

==Inbetriebnahme von Energy Count 3000 (EC3000)==
Die EC3000 sendet auf 868.300 kHz mit 20.000 kbps. Dafür wurde eine neue data rate hinzugefügt.
Sie kann mit 3r oder 20000r gesetzt werden. Wenn diese data rate gesetzt wird, wird auch automatisch der RFM69 auf den Empfang von EC3000 uminitialisiert.

EC3000 kann auch in einen data rate toggle mit einbezogen werden. Dazu gibt es nun das bit mit dem Wert 8 für 20.000 kbps

Um EC3000 dediziert mit einem der drei RFMs zu empfangen muss man einfach die data rate des gewünschten RFM setzen. Beispiel initCommand:
20000#2r

Um EC3000 in einen data rate toggle mit einzubeziehen muss im m command das 8-wertige bit gesetzt werden.
Wenn man z.B. mit dem zweiten Radio 17k Sensoren (TX29...) und EC3000 empfangen soll (20 Sekunden toggle), wäre das initCommand:

'''Beispiel:'''
<syntaxhighlight lang="php">attr myLaCrosseGateway initCommands 9#2m 20#2t v</syntaxhighlight>

==Inbetriebnahme von MCP23008==
Auf der LaCrosseGateway "config"-page kann für jeden der 8 IO Pins konfiguriert werden, ob es ein Input oder Output Pin ist.

'''Input''': Eingang, wird per KVP an FHEM übermittelt. Einsatzzweck: z.B. Anschluß von Pushbuttons.

'''Output''': Kann von FHEM aus gesetzt werden. Einsatzzweck: z.B. Anschluß von LEDs.

Beispiel: ''Input => Eingang, wird per KVP an FHEM übermittelt''
<syntaxhighlight lang="php">OK VALUES LGPB 211 GP2=0,GP3=1,GP4=0,GP5=0,GP6=0,GP7=0</syntaxhighlight>

Beispiel: ''Output => Kann von FHEM aus gesetzt werden.''
<syntaxhighlight lang="php">set myLaCrosseGateway raw "MCP GP0=1,GP1=0"</syntaxhighlight>

==Inbetriebnahme Analogport==
Der Analogport A0 des ESP8266 wird als Reading im LaCrosseGatewayModul aufgeführt.
Um das zu aktivieren, muss man auf der Setup-Page des LGW die Option "Send analog values" ankreuzen.
Der Eingangsspannungsbereich von A0 ist 0V ... 1.0V, was zu einem Reading von 0 ... 1023 führt.

==Inbetriebnahme von OLED-Display==
Es wird das 128x64 pixel 0.96" I2C Display mit dem SSD1306 controller und das 128x64 pixel 1.3" mit dem SH1106 controller unterstützt.

Für die korrekte Darstellung auf dem 1.3" Display, muss die Checkbox 1.3" auf der Setup-Page aktiviert werden

Hinweis: das 0.96" Display bekommt man auch in einer Varianten, die SPI unterstützt. Diese Variante kann nur nach einem Umbau verwendet werden.

Der nachfolgende Funktionsumfang ist implementiert:

*OLED ein- und ausschalten sowie das Senden von individuellen Texten über FHEM mithilfe des LaCrosseGateway-Moduls
*OLED Startverhalten konfigurierbar
*Übermittlung des Display Status im KVP
*Anzeige von Statusinformationen in der obersten Zeile mithilfe von Symbolen (siehe Abbildung - von links nach rechts)
**WiFI connect erfolgreich
**Ein FHEM hat sich auf einen DataPort connected
**Ein FHEM hat sich auf den Prozessor an der [[#Serial_transparent_bridge|uart bridge]] connected
**WiFi Signalstärke (dBm). Hinweis: -36 ist besser als -60
[[Datei:lgw_oled_statuszeile.png|400px|thumb|left|OLED Anzeige von Statusinformationen]]
<div style="clear:both;"></div>
*Darstellung von bis zu drei Texten und optional ein Symbol.
*Definition des Zeitintvervalls für das Umschalten zur nächsten Seite
*Zuweisung der Modes an die Ports des MCP23008 (Die Konfiguration erfolgt auf der "Setup"-Page)
*Fortschrittsanzeige beim Flashen eines an die serielle Schnittstelle des SC16IS750 angeschlossenen Arduinos (siehe SubProzessor und Serial transparent bridge)

===OLED Start Modus===
Einstellungsmöglichkeit über die "Config"-Page wie sich das OLED nach einem Start verhalten soll.
Mögliche Optionen: on / off / Anzahl Sekunden, nach denen es ausgeht.
Zusätzlich kann der initiale Mode festgelegt werden (z.B. thp)

===Modes===
{| class="wikitable" style="margin-left: auto; margin-left: 0px;"
! Prefix !! Parameter !! Erläuterung
|-
| OLED mode=
| t
| Temperatur des internen Sensors
|-
| OLED mode=
| h
| Feuchte des internen Sensors
|-
| OLED mode=
| p
| Druck des internen Sensors
|-
| OLED mode=
| s
| Statuswerte des LGW
|-
| OLED mode=
| f
| von FHEM gesetzter Text
|}

===Mögliche Symbole===
{| class="wikitable" style="margin-left: auto; margin-left: 0px;"
! Parameter !! Erläuterung !! OLED Darstellung
|-
| t
| Temperature
| [[Datei:lgw_sym_t.jpg|150px|thumb|left|]]
<div style="clear:both;"></div>
|-
| h
| Humidity
|[[Datei:lgw_sym_h.jpg|150px|thumb|left|]]
<div style="clear:both;"></div>
|-
| p
| Pressure
|[[Datei:lgw_sym_p.jpg|150px|thumb|left|]]
<div style="clear:both;"></div>
|-
| s
| System
|[[Datei:lgw_sym_s.jpg|150px|thumb|left|]]
<div style="clear:both;"></div>
|-
| i
| Info
|[[Datei:lgw_sym_i.jpg|150px|thumb|left|]]
<div style="clear:both;"></div>
|-
| w
| Warning
|[[Datei:lgw_sym_w.jpg|150px|thumb|left|]]
<div style="clear:both;"></div>
|-
| e
| Error
|[[Datei:lgw_sym_e.jpg|150px|thumb|left|]]
<div style="clear:both;"></div>
|}

===Beispiele===

{| class="wikitable" style="margin-left: auto; margin-left: 0px;"
! Definition !! Erläuterung
|-
| style="width:30%" | <syntaxhighlight lang="php">set myLaCrosseGateway raw "OLED On"</syntaxhighlight>
| Schaltet ein angeschlossenes Display ein
|-
| <syntaxhighlight lang="php">set myLaCrosseGateway raw "OLED Off"</syntaxhighlight>
| Schaltet ein angeschlossenes Display aus
|-
| <syntaxhighlight lang="php">set myLaCrosseGateway raw "OLED interval=20"</syntaxhighlight>
| Legt fest, dass (je nach mode) alle 20 Sekunden die nächste Seite angezeigt wird.
|-
| <syntaxhighlight lang="php">set myLaCrosseGateway raw "OLED mode=ths"</syntaxhighlight>
| Zeigt nacheinander Temperatur, Feuchte und Systemdaten an
|-
| <syntaxhighlight lang="php">set myLaCrosseGateway raw "OLED mode=thp"</syntaxhighlight>
| Zeigt nacheinander Temperatur, Feuchte und Luftdruck an
|-
| <syntaxhighlight lang="php">set myLaCrosseGateway raw "OLED mode=thps"</syntaxhighlight>
| Zeigt nacheinander Temperatur, Feuchte, Luftdruck und Systemdaten an
|-
| <syntaxhighlight lang="php">set myLaCrosseGateway raw "OLED mode=f"</syntaxhighlight>
| Zeigt ausschließlich den von FHEM festgeleget Text an
|-
| <syntaxhighlight lang="php">set myLaCrosseGateway raw "OLED mode=s"</syntaxhighlight>
| Zeigt ausschließlich die Systemdaten an
|-
| <syntaxhighlight lang="php">set myLaCrosseGateway raw "OLED show=Soll: 20.5,Ist: 19.2,,t"</syntaxhighlight>
| Zeigt die übergebenen Texte an und links das Symbol für Temperatur
|-
| <syntaxhighlight lang="php">set myLaCrosseGateway raw "OLED show=55%,,,h"</syntaxhighlight>
| Zeigt nur den Text "55%" und das Symbol für Feuchte an. Da es nur ein Text ist, wird er größer dargestellt
|-
| <syntaxhighlight lang="php">set myLaCrosseGateway raw "OLED show=Line 1,Line 2,Line 3"</syntaxhighlight>
| Zeigt drei Texte aber kein Symbol an.
|-
| <syntaxhighlight lang="php">attr myLaCrosseGateway initCommands "OLED mode=thps"</syntaxhighlight>
| Zeigt nacheinander Temperatur, Feuchte, Luftdruck und Systemdaten an. Der Mode wird immer geschickt, wenn FHEM sich neu auf das LGW connected.
|}

==Inbetriebnahme eines Nextion Displays==

Mithilfe der Seriellen Schnittstelle [[#Soft_serial_bridge|(Soft serial bridge]]), kann ein Nextion Display in Betrieb genommen werden. Das Besondere dabei ist, dass das LGW zusätzlich seine Status Informationen (AP-Verbindungsstatus, RSSI ,IP ,Version ,FHEM Verbindungsstatus, etc.) an das Display schickt.
Die Anbindung an FHEM erfolgt Mithilfe des Nextion Moduls (42_Nextion.pm), welches per FHEM Update verteilt wird.

Ein Diskussionsthread zum Thema „LaCrosseGateway mit Nextion Display“ findet man {{Link2Forum|Topic=63443|LinkText=hier}}.

===Voraussetzungen===
Vor der Inbetriebnahme in FHEM, müssen folgende Voraussetzungen erfüllt sein:
*Das Display ist wie [[#Nextion_Display|hier]] beschrieben an das LGW angeschlossen.
*Die [[#Soft_serial_bridge|Soft serial bridge]] auf der LGW Setup-page ist konfiguriert.
*Das LaCrosse Gateway Device ist wie [[#Device_Definition|hier]] beschrieben angelegt.

===Funktionsumfang===

Der nachfolgende Funktionsumfang ist implementiert:

*OTA Firmware (.tft File) übertragung an das Display
*Automatische Anpassung der Baudrate auf dem Nextion
*Das LGW schickt (periodisch) Werte an folgende Controls:
{| class="wikitable" style="margin-left: auto; margin-left: 0px;"
! Control!! Beschreibung/Anmerkung
|-
| LGW#temp.txt
| Nur wenn ein entsprechender on board sensor vorhanden ist.
|-
| LGW#hum.txt
| Nur wenn ein entsprechender on board sensor vorhanden ist.
|-
| LGW#pres.txt
| Nur wenn ein entsprechender on board sensor vorhanden ist.
|-
| LGW#rssi.txt
| WLAN RSSI Signalstärke
|-
| LGW#ip.txt
| IP-Adresse des LGW's
|-
| LGW#fpm.txt
| Frames Per Minute
|-
| LGW#heap.txt
| Free Heap
|-
| LGW#up.txt
| Uptime
|-
| LGW#ver.txt
| Version
|-
| LGW#wifi (vis)
| Setzt die visibility
|-
| LGW#fhem
| Setzt die visibility
|-
| LGW#cpu1
| Setzt die visibility
|-
| LGW#cpu2
| Setzt die visibility
|-
| LGW#main
| Sendet, nachdem es sich initialisiert hat, ein "page LGW#main" an das Nextion.
|-
| LGW#info
| Sendet die Info an die LGW#prog page
|-
| LGW#ptext
| Sendet die Info an die LGW#prog page
|-
| LGW#pbar
| Sendet die Info an die LGW#prog page
|}

*Fortschrittsanzeige beim flashen der Nextion Firmware

===Device Definition Nextion Modul===

Die Definition für die Nextion Bridge sieht dann wie folgt aus:

<code>define <nextion> Nextion <IP-Adresse>:<Port></code>

''<nextion>'' kann bei Bedarf angepasst werden.

''<IP-Adresse>'' muss entsprechend angepasst werden. Anstatt der IP-Adresse kann auch der Hostname vom LaCrosseGateway verwendet werden.

''<Port>'' Ist der auf der Setup-page definierte Port

'''Beispiel:'''
<syntaxhighlight lang="php">define nextion Nextion 192.168.22.33:86</syntaxhighlight> IP-Adresse ermitteln: Das LaCrosseGateway heist per default Einstellung "LaCrosseGateway", per ping auf den Hostnamen LaCrosseGateway kann die <IP-Adresse> ermittelt werden.

===Firmware erstellen und flashen ===
Ein UI für das Nextion Display wird mit dem Nextion Editor erstellt. Mithilfe des Editors kann die entsprechende Firmware (tft Datei – siehe „File -> Open build folder“) kompiliert (Button: Compile) werden.

Das LGW kann die Firmware (.tft Datei) zum Display übertragen. Dazu gibt es zwei Varianten:

'''curl'''

Syntax lautet:

<code>curl --http1.0 -# -o ~output.txt -H "Content_Type:multipart/form-data" -F "file=@<tftFileName>; filename=nextion.tft" http://<LGW-IP>/ota/nextion</code>

Beispiel:

<code>curl --http1.0 -# -o ~output.txt -H "Content_Type:multipart/form-data" -F "file=@D:\MyNextionFiles\lgw.tft; filename=nextion.tft" http://192.168.31.213/ota/nextion</code>

'''Das LaCrosseGateway Modul in FHEM'''

Syntax lautet:

<syntaxhighlight lang="php">set <myLaCrosseGateway> nextionUpload</syntaxhighlight>

Wenn das Attribut "tftFile" gesetzt ist, wird die darin angegebene Datei hochgeladen, ansonsten wird versucht, das File „FHEM/firmware/nextion.tft“ hochzuladen.

===Anwendungsbeispiel===
In {{Link2Forum|Topic=63443|LinkText=diesem FHEM Forum Thread}} wurde ein LGW Nextion UI erarbeitet (Stand 01.08.2017 {{Link2Forum|Topic=63443|Message=582453|LinkText=Version 0.7}}), um die Funktionsweise zu demonstrieren.
Das Nextion UI besteht aus folgenden Pages:
{| class="wikitable"
!ID !! Name !! Page !! Beispiel !! Hinweise/Funktion/Bechreibung !! Nextion Debug commands
|-
| 0 ||Boot || Boot || [[Datei:lgw_nextion_boot.png|200px|thumb|left|]]<div style="clear:both;"></div> || Das ist die Startseite nach Einschalten des Nextion Displays. ||
|-
| 1 ||Progress||LGW#prog ||[[Datei:lgw_nextion_prog.png|200px|thumb|left|]]<div style="clear:both;"></div>|| Auf dieser Seite wird der WiFi Verbindungsfortschritt angezeit. Alles Werte werden vom LGW befüllt. ||page LGW#prog
vis LGW#pbar,1

vis LGW#ptext,1

LGW#pbar.val=50

LGW#ptext.txt="Connect WiFi (1)"
|-
| 2 ||Main|| LGW#main || [[Datei:lgw_nextion_main.png|200px|thumb|left|]]<div style="clear:both;"></div> ||Dies ist die Haupseite, welche vom LGW aufgerufen wird, sobald der Bootvorgang abgeschlossen ist.<br>Hinweise zur Funktionsweise findet man {{Link2Forum|Topic=63443|Message=546896|LinkText=hier}}|| page LGW#main
vis LGW#wifi,1

vis LGW#fhem,1

vis LGW#cpu1,1

vis LGW#cpu2,1

LGW#rssi.txt="-68"

tTime.txt="23:45"

tDate.txt="01.08.2017"

vis iTemp,1

LGW#temp.txt="25.7"

vis iHum,1

LGW#hum.txt="68%"

vis iPres,1

LGW#pres.txt="1024hPa"

vis iWind,1

tout_ws.txt="23km/h"

vis iOutT,1

tout_t.txt="28°C"
|-
| 3 ||Info Page|| Info || [[Datei:lgw_nextion_info.png|200px|thumb|left|]]<div style="clear:both;"></div> || Alle Informationen auf dieser Seite werden von LGW automatisch befüllt. || page Info
vis LGW#ip,1

LGW#ip.txt="192.168.222.1"

vis LGW#fpm,1

LGW#fpm.txt="5"

vis LGW#heap,1

LGW#heap.txt="16280"

vis LGW#ver,1

LGW#ver.txt="1.30"

vis LGW#up,1

LGW#up.txt="1Tg.4Std.34Min."
|-
| 4 || Info Page 2 || Info2 || [[Datei:lgw_nextion_info2.png|200px|thumb|left|]]<div style="clear:both;"></div> || tInfo50 und tInf51 sind für Nextion UI Version reserviert. tInfo60 bis tInfo91 sind nicht belegt und können verwendet werden, um z.B. die FHEM Verison anzuzeigen. || page Info2
tInfo60.txt="tInfo60:"

tInfo61.txt="tInfo61"

tInfo70.txt="tInfo70:"

tInfo71.txt="tInfo71"

tInfo80.txt="tInfo80:"

tInfo81.txt="tInfo81"

tInfo90.txt="tInfo90:"

tInfo91.txt="tInfo91"
|-
| 5 || Settings || Settings || [[Datei:Lgw_nextion_Settings.png|200px|thumb|left|]]<div style="clear:both;"></div> || Einstellungsmöglichkeit von Helligkeit (Wertebereich von 10% bis 100%) des Displays und des PowerOff Timeouts (Wertebereich: off und 1-120 Sek.)||page Settings
h1.val=25

h0.val=60
|-
| 6 || Control Center||CoCe||[[Datei:lgw_nextion_CoCe.png|200px|thumb|left|]]<div style="clear:both;"></div> ||Zum Schalten von Aktoren und Status anzeige.<br>Weiteren Hinweise zur Funktionsweise sind {{Link2Forum|Topic=63443|Message=576902|LinkText=hier}} zu finden. || page CoCe
lblT1.txt="lbT1"

lblS1.txt="aus"

lblT2.txt="lbT2"

lblS2.txt="an"

lblT3.txt="lbT4"

lblS3.txt="zu"

lblT4.txt="lbT3"

lblS4.txt="auf"

lblT5.txt="lbT5"

lblS5.txt="n.a."
|-
| 7 || Weather ||Weather||[[Datei:lgw_nextion_Weather.png|200px|thumb|left|]]<div style="clear:both;"></div>||Zur Anzeige einer Wettervorhersage. Diese Seite wird durch ein touch auf den "Temp-Wert" in der Main#Page aufgerufen. <br>Implementierungshinweise sind {{Link2Forum|Topic=63443|Message=582453|LinkText=hier}} zu finden. ||page Weather
p0.pic=12

t0.txt="Mo 01 Aug 2017\rmin:15 max:18"

p1.pic=16

t1.txt="Di 02 Aug 2017\rmin:15 max:18"

p2.pic=17

t2.txt="Mi 03 Aug 2017\rmin:15 max:18"

p3.pic=12

t3.txt="Do 04 Aug 2017\rmin:25 max:28"

p4.pic=15

t4.txt="Fr 05 Aug 2017\rmin:28 max:32"
|}

Hinweis: Alle Contorls die mit dem Namen "LGW#" beginnen sind für das LGW reserviert und werden entsprechend vom Gateway befüllt.

===Nextion Tipps & Tricks===
====Nextion Commandreferenz====
Sehr hilfreich ist die Nextion instruction Page, welche hier: https://www.itead.cc/wiki/Nextion_Instruction_Set zu finden ist.

==Serial Transparent Bridge==
Das LGW kann optional die serielle Schnittstelle des SC16IS750 transparent auf einem TCP Port bereitstellen.
Dazu gibt es die settings ''"Serial bridge port"'' und ''"Serial bridge baud"'' auf der "Setup"-Page" (Web-Frontend) des LaCrosseGateways.
Das LaCrosseGateway überträgt transparent die Daten der seriellen Schnittstelle an FHEM und umgekehrt.
Damit kann z.B. ein NanoCUL an das LaCrosseGateway angeschlossen werden und in FHEM verwenden werden.

'''''Vorgehensweise:'''''
*Einen NanoCUL bauen, z.B. auf Basis eines Arduino Pro Mini, flashen und testweise in Betrieb nehmen.
*Den NanoCUL an die serielle Schnittstelle des SC16IS70 anschließen
*Port und baud rate auf der "Setup"-Page des LaCrosseGateways festlegen, z.B. Port 85 und 38400 baud
*CUL in FHEM definieren (Beispiel):
<syntaxhighlight lang="php">define CULXYZ CUL <IP-Adresse>:85 0000</syntaxhighlight>
'''''<CULXYZ>''''' Muss nach eigenen Bedürfnissen angepasst werden.

'''''<IP-Adresse>''''' Muss entsprechend angepasst werden.

Sollte das CUL-Device nicht erreichbar sein (Restart, Austausch im Falle eines Deffekts etc.), empfiehlt sich einen reconnect Mechnismus in FHEM zu implementieren.

Dieser kann wie folgt aussehen:

<syntaxhighlight lang="php">define CULXYZ-Reconnector at +*00:00:30 {\
my $deviceName = "<CULXYZ>";;\
my $version = CommandGet("", $deviceName . " version");;\
my $gotAnswer = index($version, 'No answer') == -1;;\
\
if(!$gotAnswer) {\
fhem("set " . $deviceName . " reopen");;\
}\
\
} </syntaxhighlight>
'''''<CULXYZ>''''' Muss nach eigenen Bedürfnissen angepasst werden.

'''''Vorgehen Firmware flashen mit LGW'''''

Ein bereits in Betrieb genomene NanoCUL kann nach dem gleichen Vorgehen (siehe [[#SubProzessor|"SubProzessor - Vorgehen Firmware flashen"]]) wie ein SubProzessor geflasht werden.

==Zugriff mit mehreren FHEM Instanzen==

Bis zu drei FHEM Instanzen können auf das LaCrosseGateway gleichzeitig zugreifen.
Auf der "Setup"-Page des LaCrosseGateways können bis zu drei Ports (Data ports), pro Port eine FHEM Instanz, definiert werden (Reboot erforderlich).
Aus Performancegründen empfiehlt sich nur die benötigten Ports zu definieren.

'''''Hinweise:''''' Die Portnummer 8266 wird für OTA Update verwendet, und 80 für die "Config"-page. Aus diesem Grund ist die Verwendung dieser ports nicht erlaubt.

Wenn sich mehrere FHEM Instanzen ein LaCrosseGateway teilen, dann ist darauf zu achten, dass die eine gemeinsame/gleiche initCommand Konfiguration haben. Sollten die FHEM Instanzen unterschiedliche initCommands senden, gewinnt das (zufällig) letzte und legt es für alle anderen fest.

=Nano LaCrosse Gateway=
Das nano LaCrosse Gateway verwendet die gleiche [https://svn.fhem.de/trac/export/HEAD/trunk/fhem/FHEM/firmware/JeeLink_LaCrosseGateway.bin Firmware] wie das WiFi LaCrosse Gateway, der signifikante Unterschied ist die kompakte (portable) Bauform. Aufgrund der Bauform können jeodch nicht alle Bauteile verwendet werden.
Das Gateway eignet sich sehr gut als Entwicklungstick (dies ist der Entstehungsgrund) oder zum Empfangen und Steuern von LaCrosse basierten Sensoren/Aktoren an einem FHEM Server (RPI,Cubietruck, etc.).

Der Betieb über WiFi, entsprechende Stromversorgung (per USB) vorausgesetzt, ist ebenfalls möglich.

Weiterführende Informationen zum nano LaCrosse Gateway und Ideensammlung für eine Platine sind im {{Link2Forum|Topic=51329|LinkText=FHEM Forum}} zu finden.

==Bauteile==
Folgende Bauteile werden benötigt:
*Gehäuse [http://www.elv.de/output/controller.aspx?cid=74&detail=10&detail2=36507 schwarz] oder [http://www.voelkner.de/products/164819/USB-Gehaeuse-USB-1kl-Transparent.html transparent]
*ESP-12E
*Auto-Flash-Reset-Schaltung
*[http://www.aliexpress.com/item/6Pin-USB-2-0-to-TTL-UART-Module-Serial-Converter-CP2102-STC-Replace-Ft232/32364013343.html?spm=2114.13010208.99999999.261.mWmpl5 CP2102 FTDI]
*RFM69CW
*Status-LED

==Schaltung==
[[Datei:lgw_nano_Schaltplan.png|600px|thumb|left|Schaltplan NanoLGW]]
<div style="clear:both;"></div>

==Selbstbau==
{| class="galleryTable noFloat"
|-
| [[Datei:lgw_nano_Selbstbau1.png|320px|thumb|left|Selbstbau nano LaCrosse Gateway 1]]
| [[Datei:lgw_nano_Selbstbau2.png|300px|thumb|left|Selbstbau nano LaCrosse Gateway 2]]
| [[Datei:lgw_nano_Selbstbau3.png|475px|thumb|left|Selbstbau nano LaCrosse Gateway 3]]
|}
==Platine==
===nano LaCrosse Gateway===
{| class="galleryTable noFloat"
|-
|[[Datei:Nanolgw_bestueckt_oberseite.jpg|400px|thumb|left|nano LaCrosse Gateway Platine Oberseite]]
|[[Datei:Nanolgw_bestueckt_unterseite.jpg|400px|thumb|left|nano LaCrosse Gateway Platine Unterseite]]
|}
===USB2TTL===
{| class="galleryTable noFloat"
|-
|[[Datei:Nanolgw_USB2TTL_1.jpg|400px|thumb|left|USB2TTL Platine Oberseite]]
|[[Datei:Nanolgw_USB2TTL_2.jpg|400px|thumb|left|USB2TTL Platine Unterseite]]
|}
===nano LaCrosse Gateway inkl. USB2TTL===
{| class="galleryTable noFloat"
|-
|[[Datei:Nanolgw_oberseite_USB2TTL_1.jpg|400px|thumb|left|nano LaCrosse Gateway inkl. USB2TTL Oberseite]]
|[[Datei:Nanolgw_oberseite_USB2TTL_2.jpg|400px|thumb|left|nano LaCrosse Gateway inkl. USB2TTL Oberseite]]
|}
{| class="galleryTable noFloat"
|-
|[[Datei:Nanolgw_unterseite_USB2TTL.jpg|400px|thumb|left|nano LaCrosse Gateway inkl. USB2TTL Unterseite]]
|[[Datei:Nanolgw_seitenansicht_USB2TTL.jpg|400px|thumb|left|nano LaCrosse Gateway inkl. USB2TTL Seitenansicht]]
|}
===nano LaCrosse Gateway fertig bestückt inkl. Gehäuse===
{| class="galleryTable noFloat"
|-
|[[Datei:Nanolgw_USB2TTL_fertig_oberseite.jpg|400px|thumb|left|nano LGW fertig bestückt inkl. Gehäuse Oberseite]]
|[[Datei:nanolgw_USB2TTL_fertig_unterseite.jpg|400px|thumb|left|nano LGW fertig bestückt inkl. Gehäuse Unterseite]]
|}
===Platine bestücken (Hinweise und Tipps)===
*Die Beschriftung SJ4 und SJ3 ist auf dem USB2TTL Wandler vertauscht, dies beeinträchtigt aber die Funktion nicht.
*Beim nanoLGW hängt C1 etwas über dem FTDI232RL vom USB2TTL Wandler, daher braucht diese Platine noch eine "Schönheitskorrektur".

= Tipps & Tricks =

==Löschen des kompletten Flash des ESP8266 mit dem esptool==
Aufgrund eines aktuell im espressif SDK vorhandenen Bugs, kann es passieren, dass das LaCrosseGateway nach dem Aufspielen der Firmware, mit einer Exception den Bootvorgang (nach "Start WIFI_STA") abbricht und nicht mehr ordnungsgemäß starten kann. In diesem Fall hilft nur noch das Löschen des kompletten Speichers des ESP8266 und das erneute Aufspielen der Firmware.

Mit dem nachfolgenden Befehl kann der Speicher des ESP8266 komplett gelöscht werden.

'''''Achtung:''' Dabei werden alle Einstellungen unwiderruflich gelöscht''
<syntaxhighlight lang="php">./esptool -vv -cp /dev/tty.SLAB_USBtoUART -cb 115200 -ca 0x00000 -cd nodemcu -ce</syntaxhighlight>

'''''</dev/tty.SLAB_USBtoUART>''' Muss entsprechend angepasst werden.''

=Weiterführende Links=
Diskussionsthread aus dem Forum:

{{Link2Forum|Topic=43672|LinkText=LaCrosseGateway - LaCrosse, PCA301 und EC3000 über wifi mit ESP8266 ohne Arduino}}

{{Link2Forum|Topic=45594|LinkText=Platine für LaCrosseGateway: Platinenbestellung}}

{{Link2Forum|Topic=51329|LinkText=Platine für nanoLGW (LaCrosse Gateway): Layout}}

{{Link2Forum|Topic=52921|LinkText=Display für LaCrosseGateway}}

{{Link2Forum|Topic=63443|LinkText=LaCrosseGateway mit Nextion Display}}

[[Kategorie:Interfaces]]
[[Kategorie:IP Components]]
[[Kategorie:Other Components]]
[[Kategorie:Temperatursensoren]]
[[Kategorie:Feuchtesensoren]]
[[Kategorie:Wetterstationen]]
[[Kategorie:868MHz]]

LaCrosseGateway V1.x

2018-08-04T13:53:35Z

Markus1407:

Diese Wiki-Seite beschreibt ausschließlich das LaCrosseGateway V1.x, das auf dem ESP8266 basiert.<br/>
Für das LaCrosseGateway32 das auf dem ESP32 basiert, wird es eine eigene Seite geben.{{Randnotiz|RNText=Dokumentationsstand Version 1.27}}

Das LaCrosseGateway (hier und im Forum auch mit LGW abgekürzt) erfüllt den gleichen Zweck wie ein [[JeeLink|JeeLink USB-Stick]] und zwar das Empfangen, Abfragen und Steuern von funkbasierten LaCrosse Sensoren und Aktoren, die im 868 MHz FSK Sendeverfahren arbeiten (OOK-Sendeverfahren (433 Mhz) wird nicht unterstützt). Die Verarbeitung der Daten und Steuerung der Aktoren erfolgt mithilfe von FHEM, das als zentrale Steuereinheit dient.
Der signifikante Unterschied zu einem JeeLink USB-Stick ist der Betrieb über Wireless LAN ([https://de.wikipedia.org/wiki/Wi-Fi WiFi]).
Das Herzstück des LaCrosse-Gateways besteht aus einem ESP8266-12E/F. Das LaCrosseGateway ist aufgrund des hohen Stromverbrauchs nicht für den Akkubetrieb geeignet.

Der Einsatz eines WiFi-LaCrosse-Gateways bietet folgende Vorteile:
*Kann an eine Stelle platziert werden, an der alle Sensoren optimal empfangen werden, dafür ist nur Strom (5V/1A USB Netzteil) und [https://de.wikipedia.org/wiki/Wi-Fi WiFi] Access Point erforderlich
*Im Minimalausbau nur zwei Bauteile NodeMCU DEVKIT 1.0 + RFM69 (siehe Bauteile) nötig
*Alternativ am USB-Port wie ein JeeLink verwendbar
*Einsatz von on board Sensoren / Aktoren (siehe [[#Unterstützte Sensoren und Aktoren | Unterstützte Sensoren und Aktoren]]) möglich

Hinweis: Die Anbindung in FHEM kann zwar noch mit dem JeeLink-Modul erfolgen, aber es ist sinnvoll, auf das LaCrosseGateway-Modul (36_LaCrosseGateway.pm) umzustellen, da dieses eine bessere Unterstützung für die Funktionen des LGW bietet.

=Hardware=
==Bauteile==
Für das WiFi-LaCrosse-Gateway werden folgende Bauteile verwendet:
*[Option 1] [http://www.esp8266.com/wiki/doku.php?id=esp8266-module-family#esp-12-e_q ESP8266 ESP-12E Modul].<br />Diese Variante eignet sich für Projekte für die eine kleine Bauform benötigt wird.<br />Für die Inbetriebnahme, insbesondere für das Aufbringen der Firmware, muss das Modul an ein [[Medium:Lgw USB2Serial Adapter.jpg|USB2Serial-Adapter]], angeschlossen werden. Für diese Variante sind Lötkenntnisse erforderlich.
*[Option 2] [https://raw.githubusercontent.com/nodemcu/nodemcu-devkit-v1.0/master/Documents/NodeMCU_DEVKIT_1.0.jpg NodeMCU DEVKIT 1.0 (oder 2.0)]ist die Inbetriebnahme einfacher, da alles für das Aufbringen der Firmware bereits vorhanden ist und kein Löten nötig ist.<br />{{Link2Forum|Topic=45594|Message=430183|LinkText=Hinweis:}} Folgende Devkits werden nicht "offiziel" unterstützt, da ungetestet, können aber durchaus in bestimmten Fällen verwendet werden:
** V0.9 (da ungetestet, bekommt man aber kaum noch zu kaufen)
** V3.0 - passt nicht auf die Platine von PeMue, ist größer als das 2.0. Auf der Rückseite steht "Lolin".
** Devkits mit einem CH340 USB converter (da ungetestet und teils falsche Bauform und von der USB-Anbindung her teils problematisch)
*[Option 3] Alternativ zu einem Devkit 1.0 kann auch ein [http://www.wemos.cc/Products/d1_mini.html "WeMOS D1 mini"] eingesetzt werden. Vorteil bei diesem Kit ist die kleine Bauform bei gleichem Funktionsumfang wie das DEVKIT 1.0.
*[Option 4] ESP8266-07 auf einem DEVKIT 1.0. für den Betrieb mit einer externen Wifi Antenne.
**''Hinweis:'' Der ESP-07 hat einen 25Q80 1M flash Chip. Dieser ist für den Betrieb mit der LaCrosseGateway Firmware geeignet, für ein OTA-Update ist es jedoch zu wenig. Aus diesem Grund muss/kann dieser auf 4M flash umgebaut werden. Weitere Informationen und Details zum Umbau sind im {{Link2Forum|Topic=45594|Message=448307|LinkText=Forenthread (Gehäuse-Variante)}} beschrieben.
*[Optional] RFM69CW - Für das Senden und Emfangen funkbasierte LaCrosse Aktoren und Sensoren
*[Optional] On board Sensoren (siehe [[#Unterstützte Sensoren und Aktoren | Unterstützte Sensoren und Aktoren]])
*[Optional] SC16IS750 Zur Bereitstellung der seriellen Schnittstelle, da die GPIOs (GPIO1 / GPIO3) DEVKIT's V1.0 von FTDI verwendet werden und damit nicht genutzt werden können.
*[Optional] OLED-Display SSD1306 I2C zur Darstellung von Daten (Bootvorgang, on board Sensoren, Inhalte aus FHEM)
*[Optional] [[#MCP23008|MCP23008]] zur Bereitstellung (Konfigurierbar) von digitalen 8 Ein- Ausgängen oder Sonderfunktion (OLED)
*[Optional] Nextion Touch Display zur Darstellung von verschiedenen Informationen oder zum Schalten von Aktoren.
*Steckbrett (inkl. Kabel/Widerstände)/Lochrasterplatine (Lötkolben, Lötzinn, Widerstände etc.)) / [[#Platine|PeMue Platine]]

==Schaltung==
===Variante: Devkit 1.0 Minimum===
[[Datei:lgw_Schaltplan_Devkit_minimum.png|400px|thumb|left|Variante: Devkit 1.0]]
<div style="clear:both;"></div>
===Variante: Devkit 1.0 Maximalausbau===
[[Datei:lgw_Schaltplan_Devkit_full.png|400px|thumb|left|Variante: FTDI]]
<div style="clear:both;"></div>
===Variante: Platine (PeMue)===
siehe hier: {{Link2Forum|Topic=45594|LinkText=Thread}}
<div style="clear:both;"></div>
Siehe [[#Erweiterungsmöglichkeiten | Erweiterungsmöglichkeiten]].

===MCP23008===
I2C Adresse 0x27 -> A0,A1,A2 = 3.3V
<syntaxhighlight lang="php">
|-------\/-------|
LGW D1 |1 SCL VDD 18| LGW 3.3V
LGW D2 |2 SDA GP7 17| PB7 --/ --- GND or Output
LGW 3.3V |3 A2 GP6 16| PB6 --/ --- GND or Output
LGW 3.3V |4 A1 GP5 15| PB5 --/ --- GND or Output
LGW 3.3V |5 A0 GP4 14| PB4 --/ --- GND or Output
LGW 3.3V |6 RES GP3 13| PB3 --/ --- GND or Output
|7 NC GP2 12| PB2 --/ --- GND or Output
|8 INT GP1 11| PB1 --/ --- GND or Output
LGW GND |9 VSS GP0 10| PB0 --/ --- GND or Output
|----------------|</syntaxhighlight>

===Nextion Display===
Angeschlossen wird das Display wie folgt:
GPIO0: TXD -> Nextion RXD
GPIO2: RXD -> Nextion TXD

Das Display benötigt eine 5V Spannungsversorgung, diese kann vom VIN des DevKit's abgegriffen werden. Vom Betrieb mit 3.3V wird abgeraten.
Ein level shifter für RXD/TXD ist nicht nötig.

==Aufbau auf einem Steckbrett==
[[Datei:lgw_Steckbrett.png|600px|thumb|left|LaCrosseGateway Aufbau auf einem Steckbrett]]
<div style="clear:both;"></div>
'''''Hinweis:''' Der Sender und Empfänger RFM12, der auf dem Steckbrett zu sehen ist, wird nicht mehr unterstützt.''

==Platine==
PeMue (vielen Dank) hat {{Link2Forum|Topic=45594|LinkText=hier}} eine Platine (7,1cm x 5,0cm) für das LaCrosseGateway entworfen (Stand 05.2016).

===Oberseite===
[[Datei:lgw_Platine_Oberseite.jpg|400px|thumb|left|LaCrosseGateway Platine Oberseite]]
<div style="clear:both;"></div>

===Unterseite===
[[Datei:lgw_Platine_Unterseite.jpg|400px|thumb|left|LaCrosseGateway Platine Unterseite]]
<div style="clear:both;"></div>

===Devkit 1.0 bestückt Oberseite===
[[Datei:Lgw_Platine_Devkit_oberseite.png|400px|thumb|left|LaCrosseGateway Platine Oberseite]]
<div style="clear:both;"></div>

===Devkit 1.0 bestückt Unterseite===
[[Datei:lgw_Platine_Devkit_unterseite.png|400px|thumb|left|LaCrosseGateway Platine Unterseite]]
<div style="clear:both;"></div>

===ESP8266-12E bestückt Oberseite===
{| class="galleryTable noFloat"
|-
| [[Datei:lgw_Platine_ESP-12E_oberseite.png|400px|thumb|left|(1) LaCrosseGateway Platine Oberseite mit 2 x RFM69CW, BME280 und DHT22]]
| [[Datei:lgw_Platine_ESP-12E_oberseite_2.jpg|490px|thumb|left|(2) LaCrosseGateway Platine Oberseite mit 2 x RFM69CW, BME280]]
| [[Datei:lgw_Platine_ESP-12E_oberseite_2_inkl_GE.jpg.jpg|325px|thumb|left|(2) LaCrosseGateway Platine Oberseite mit 2 x RFM69CW, BME280 inkl. Gehäuse]]
|}
'''''Hinweis:''' Die Platine (Bild (1)) ist mit einem LM75 Sensor bestückt. Diese Bestückung macht zusammen mit einem BME280 keinen Sinn, es handelt sich hierbei um eine Entwicklungsplatine.''

===ESP8266-12E bestückt Unterseite===
{| class="galleryTable noFloat"
|-
| [[Datei:lgw_Platine_ESP-12E_unterseite.png|400px|thumb|left|(1) LaCrosseGateway Platine Unterseite]]
| [[Datei:lgw_Platine_ESP-12E_unterseite_2.jpg|415px|thumb|left|(2) LaCrosseGateway Platine Unterseite mit 2 x RFM69CW, BME280]]
|}

===Platine bestücken (Hinweise und Tipps)===
*Auf der Platine (Version 1.0) ist für das RFM69CW-Modul eine Markierung (zwei Quadrate) aufgedruckt, die den Chip und den Quarz symbolisieren. Wenn man den RFM69CW so drauflötet, wie abgebildet, ist er falsch rum drauf.<br />Es muss darauf geachtet werden, wo auf dem RFM69CW die "Ant" Beschriftung steht, dieser Lötpunkt muss auf die Platine an den Punkt "1" ausgerichtet werden. Zur Sicherheit bitte den [[#Variante: Platine (PeMue)|Schaltplan]] konsultieren und die genaue Position ermitteln.<br>'''Für die Platine V1.1 wurde das korrigiert.'''
*Die Antennenlänge für das RFM69CW beträgt 82 mm. Dafür möglichst eindrähtigen Leiter (aus Kupfer) verwenden.

==Erweiterungsmöglichkeiten==
Das LaCrosseGateway kann optional mit verschiedenen Komponenten erweitert werden.

Folgende Erweiterungen sind möglich:
*es kann ein eigener Prozessor (mit eigener Firmware) angeschlossen werden, der Daten empfängt und diese dem LGW übergibt.
*es kann z.B. ein NanoCUL angeschlossen werden, dessen serielle Schnittstelle transparent auf einem Port im Web bereitgestellt wird.
*es kann ein vierter und fünfter RFM69CW angeschlossen werden, diese können alles, was die bisherigen drei auch können.
*es kann ein aktiver Piezo Summer (Piezo Buzzer) angeschlossen (an GPIO7 des SC16IS750) werden, um von FHEM aus das LaCrosseGateway einen Alarm ausgeben zu lassen. Hinweis: Falls der Strom von 10mA, den die Ausgänge liefern, nicht reicht, ist noch eine Transistor-Schaltstufe vorzusehen.

Alle diese Daten stellt das LaCrosseGateway per WiFi an FHEM zu, dort wird es von den entsprechenden Modulen (LaCrosseGateway, LaCrosse, PCA301, ...) weiterverarbeitet.

Alle Komponenten werden automatisch erkannt, sofern angeschlossen.
Für die Realisierung der o.g Möglichkeiten wird ein [http://www.aliexpress.com/item/1x-Breakout-Board-for-SC16IS750-I2C-SPI-to-UART-IC/1327351219.html?spm=2114.30010308.3.38.HxdznQ&ws_ab_test=searchweb201556_9,searchweb201602_2_10034_507_10020_10001_10002_10017_10010_10005_10011_10006_10021_10003_10004_10022_10009_10008_10018_10019,searchweb201603_6&btsid=97b30f2b-e937-426b-8202-de585dd7ee97 SC16IS750] verwendet.

Der SC16IS750 wird per I2C an das LaCrosseGateway angeschlossen und bietet eine serielle Schnittstelle und 8 Digital I/Os

'''Auf dieser Basis sind momentan folgende Erweiterungen möglich:'''

===SubProzessor===
Der SubProzessor dient dazu, dass mit einem eigenen Sketch Daten erfasst werden können, ohne sich um die ganze Nummer, die das LGW macht (WiFi, Kommunikation mit FHEM, Frontend, OTA, ...), kümmern zu müssen.
Ferner ermöglicht es die Implementierung von eigenen Projekten, dabei werden die zeitkritischen Abläufe des LGWs nicht beeinträchtig.

An die serielle Schnittstelle des SC16IS750 kann optional ein Arduino angeschlossen werden (z.B. ein Pro Mini)
Entweder ein 3.3V / 8MHz oder ein 5V / 16MHz, der aber dann auch mit 3.3V betrieben wird.

'''''Wichtig:''' Alle LaCrosseGateway Komponenten laufen ausschließlich mit '''3.3V''', aus diesem Grund dürfen keine '''5V''' Komponenten angeschlossen werden.''

'''Firmware flashen'''

Die Firmware kann über das LGW auf den SubProzessor (Voraussetzung: Arduino hat einen bootloader) geflasht werden.

Dazu wird sie auf das LGW hochgeladen (<nowiki>http://<LGW-IP>/ota/addon.hex</nowiki>).

Das LGW nimmt den Upload entgegen, wandelt das Intel-Hex in binary um und schickt es per STK500-Protokoll an den Arduino.

Falls ein OLED angeschlossen ist, wird sogar ein progress angezeigt.

'''Vorgehen Firmware flashen'''

Die Firmware kann z.B. mithilfe von "curl" mit dem nachfolgendem Befehl hochgeladen werden:
<syntaxhighlight lang="php">curl --http1.0 -H "Content_Type:multipart/form-data" -F "file=@/myFolder/LGW-Addon.ino.hex; filename=addon.hex" http://192.168.31.211/ota/addon.hex</syntaxhighlight>

'''''Hinweis:''' fielname=addon.hex im Beispiel darf nicht verändert werden, nur /myFolder/LGW-Addon.ino.hex und die IP-Adresse wird entsprechend angepasst.''

Der Upload dauert etwas, danach sollte bei Erfolg vom LGW ein Protokoll zurückgeschickt bekommen, der wie folgt aussieht:
<syntaxhighlight lang="php">Start receiving 'addon.hex'
File: /addon.hex Size: 21417
Starting flash
Sending sync
Enter program mode
Binary size is:7608
Leave Program Mode
Flash finished</syntaxhighlight>

Mit dem SubProzessor können die entsprechenden Daten auf zwei mögliche Arten am LGW übermittelt werden:

'''KeyValueProtokoll (KVP):'''
Format:<syntaxhighlight lang="php">KV <Type> <Address> <Key>=<Value>,<Key>=<Value>,<Key>=<Value>, ...</syntaxhighlight>
Beispiel:<syntaxhighlight lang="php">KV DHT 01 Temperature=21.5,Humidity=62</syntaxhighlight>

Das LGW übermittelt die Daten als KVP an FHEM und dort entsteht ein KVP Device, das die Daten darstellt.

'''LaCrosse:'''

Format:<syntaxhighlight lang="php">LC <Address> T=<Temperature>,H=<Humidity></syntaxhighlight>
Beispiel:
<syntaxhighlight lang="php">LC 9F T=21.5,H=62</syntaxhighlight>
<syntaxhighlight lang="php">LC 9F T=21.5</syntaxhighlight>
Das LGW setzt die Werte in das LaCrosse Protokoll um (wie z.B. ein TX29DTH) und schickt sie an FHEM.
In FHEM entsteht ein LaCrosse Device (autocreate, LaCrossePairForSec ...), als ob es ein LaCrosse Sensor wäre.

Das [https://forum.fhem.de/index.php?action=dlattach;topic=43672.0;attach=48914 LGW-Addon.ino] ist ein einfaches Beispiel, das diese Technik veranschaulicht.
Es bindet den geliebten DHT22 an und sendet ihn als LaCrosse-Sensor (über das LGW) an FHEM und es misst die Spannung und sendet sie zusammen mit der UpTime des SubProzessors als KVP

Der umrandete Bereich [[#Addon Schaltung |Schaltung - "Example"]] "Example" ist das zu [https://forum.fhem.de/index.php?action=dlattach;topic=43672.0;attach=48914 LGW-Addon.ino] passende Beispiel.

==Unterstützte Sensoren und Aktoren==
Alle Sensoren und Aktoren, die auch vom "LaCrosse Arduino" Sketch unterstützt werden.<br />
(siehe [[JeeLink#Unterst.C3.BCtzte_Sensoren_und_Aktoren_incl._Wetterstation_WS_1600JeeLink|vom JeeLink unterstützte LaCrosse Sensoren und Aktoren]])

Zusätzlich zu LaCrosse werden auch die folgenden Geräte unterstützt:
{| class="wikitable"
!Bezeichnung !! Datenrate !! Sonstiges !! Funktion !! Hinweise
|-
| PCA301 ||868950 kHz (868,970 und 868,990 ) 6.631 kbps || extern || Energiemess-Steckdose (Unterstützt werden bis zu 50 Dosen) ||
|-
| EC3000 ||868.300 kHz mit 20.000 kbps|| extern || Energiemess-Steckdose ||
|-
| RFM69CW || || on board || Zum Empfangen und Senden von Sensor/Aktor Daten.|| Hinweise DHT22 beachten.
|-
| BME280 || || on board || Temperatur, Feuchte und Druck || Falls das verwendete Breakout bereits PullUp-Widerstände für SDA und SCL enthält, sind diese nicht mehr zusätzlich nötig.
|-
| BMP180 || || on board || Temperatur und Druck || Falls das verwendete Breakout bereits PullUp-Widerstände für SDA und SCL enthält, sind diese nicht mehr zusätzlich nötig.
|-
| LM75 || || on board|| Temperatur ||
|-
| DHT22 || ||on board|| Temperatur und Feuchte. || Kann anstatt RFM69 Radio#3 eingesetzt werden.
|-
| SC16IS750 || I2C Adresse: 0x90 ||on board|| OI Erweiterung ||
|-
| OLED SSD1306|| I2C Adresse: 0x3C || on board || OLED Display||
|-
| MCP23008|| I2C Adresse: 0x27 || on board || Input/Output Port Expander||
|-
| Piezo Summer |||| on board ||Piezo Buzzer||
|-
| Nextion Display ||(Max.) 57600 baud || on board ||Touch Display||

|}

Alle direkt am LGW anschließbare Sensoren werden automatisch erkannt, wenn sie vorhanden sind.

<u>Sie werden in folgender Reihenfolge verwendet:</u>

Wenn ein BME280 vorhanden ist, wird dieser verwendet und sonst nichts, da man dann bereits Temperatur, Feuchte und Druck hat.

Ist kein BME280 vorhanden, wird geschaut, ob ein BMP180 vorhanden ist. Falls ja, haben wir Druck und Temperatur.

Dann wird geschaut, ob ein DHT22 vorhanden ist. Wenn ja, wird er zusätzlich verwendet, aber vom BMP180 dann nur noch der Druck.

Temperatur und Feuchte vom DHT22, dass dieses Wertepaar von einem Sensor stammt.

Wenn kein BMP180 und kein BME180 da ist, sondern nur ein DHT22, dann hat man Temperatur und Feuchte.

Wenn nichts vorhanden ist (also keiner der bisher genannten Sensoren), wird, falls vorhanden, der LM75 verwendet.

=Software=

== Release Notes ==
*[https://forum.fhem.de/index.php/topic,43672.0.html LaCrosseGateway Release Notes im Forum]

==Funktionsumfang==
*Access Point für die Konfiguration
*Konfiguration über WEB-Frontend (Erreichbar per ''<nowiki>http://IP-Adresse oder Hostname/setup</nowiki>'' auf Port 80 )
**SSID und Password (Die Konfiguration wird im EEPROM gespeichert und bei zukünftigen Neustarts verwendet.)
**Statische IP-Adresse anstatt DHCP
**Hostname
*Vom LaCrosseGateway FHEM-Modul über IP-Adresse:Port oder Hostname:Port ansprechbar. Der Port ist konfigurierbar.
*Unterstützt bis zu 5 x RFM69CW (Keine Unterstützung für RFM12)
*On board und externe Sensoren und Aktoren ([[#Unterstützte Sensoren und Aktoren |Unterstützte Sensoren und Aktoren]])
*Betrieb nur per USB möglich, als ob es ein JeeLink wäre
*FHEM Anbindung
*Log im Web-Frontend
*Firmware OTA-Update (Firmware-Over-the-Air-Update per FHEM)
*Erweiterungsmöglichkeiten per SC16IS750 (Für Buzzer und für weitere zwei RFM69)
*SubProzessor (An die serielle Schnittstelle des SC16IS750 kann optional ein Arduino angeschlossen werden (z.B. ein Pro Mini))
*Serial bridge (Optional kann die serielle Schnittstelle des SC16IS750 transparent auf einem TCP Port bereitgestellt werden)
*Software Serial Bridge - Stellt die Soft Serial Schnittstelle transparent auf einem TCP Port.

==Sourcecode==
Der Quellcode des LaCrosse Gateways befindet sich [https://svn.fhem.de/trac/export/HEAD/trunk/fhem/contrib/arduino/36_LaCrosseGateway.zip im FHEM SVN Repository (contrib)].

==Firmware Download==
Die [https://svn.fhem.de/trac/export/HEAD/trunk/fhem/FHEM/firmware/JeeLink_LaCrosseGateway.bin Firmware] befindet sich im [https://svn.fhem.de/trac/browser/trunk/fhem FHEM SVN Repository] und wird per FHEM Update verteilt. Neue Version der [https://svn.fhem.de/trac/export/HEAD/trunk/fhem/FHEM/firmware/JeeLink_LaCrosseGateway.bin Firmware] wird im {{Link2Forum|Topic=43672|LinkText=FHEM Forum "LaCrosse Gateway"}} angekündigt und der Funktionsumfang bzw. die Änderungen beschrieben.

Nach einem FEHM-Update alternativ auch: ''<FHEM-Installations-Verzeichnis>/FHEM/firmware/JeeLink_LaCrosseGateway.bin''

==Firmware aufspielen==
Wie bei einem JeeLink muss auch für das LaCrosseGateway die Firmware aufgespielt werden.

Das [https://raw.githubusercontent.com/nodemcu/nodemcu-devkit-v1.0/master/Documents/NodeMCU_DEVKIT_1.0.jpg NodeMCU DEVKIT 1.0] hat eine CP2102 UART Bridge implementiert, dafür muss ein CP2102 Treiber installiert sein.

Bei einem ESP8266-12E Modul kann die Firmware mithilfe eines Seriell-USB-Konverters aufgespielt werden.

===Windows/Mac/Linux per "esptool"===
Verifiziert und getestet wurde dieses Vorgehen auf Windows (Windows 10), Mac (El Capitan):

1) Das [https://github.com/igrr/esptool-ck/releases esptool 0.4.6] für die entsprechende Plattform herunterladen.

2) Zum Aufspielen der Firmware, muss ein Befehl nach der folgenden Syntax ausgeführt werden:
<syntaxhighlight lang="php">
esptool -vv -cp [Port] -cb 921600 -ca 0x00000 -cd nodemcu -cf [Pfad zur Firmware (bin-File)]</syntaxhighlight>
'''[Port]''' und '''[Pfad zur Firmware (bin-File)]''' müssen angepasst werden.

''Beispiel (Mac/Linux):''

<syntaxhighlight lang="php">esptool -vv -cp /dev/tty.SLAB_USBtoUART -cb 921600 -ca 0x00000 -cd nodemcu -cf JeeLink_LaCrosseGateway.bin</syntaxhighlight>

'''''Hinweis:''' Das esptool ist nicht sonderlich stabil. Es kommt vor, dass es manchmal den upload nicht startet oder nicht durchbekommt. In diesem Fall hilft es den Vorgang, auch mehrmals, zu wiederholen.''

=== Linux/Debian/Ubuntu "esptool v2.1"===

Installieren:
<syntaxhighlight lang="bash">
sudo apt-get esptool
</syntaxhighlight>

''Beispiel mit neuer Syntax bei esptool v2.1:''
<syntaxhighlight lang="bash"> sudo esptool --port /dev/ttyUSB0 write_flash 0x00000 JeeLink_LaCrosseGateway.bin</syntaxhighlight>

===Windows per "nodemcu-flasher"===

1) [https://github.com/nodemcu/nodemcu-flasher/raw/master/Win32/Release/ESP8266Flasher.exe Espressif Flashtool] downloaden und entpacken:

2) [https://svn.fhem.de/trac/export/HEAD/trunk/fhem/FHEM/firmware/JeeLink_LaCrosseGateway.bin Firmware] downloaden

3) FlashTool starten und wie folgt einstellen:

{| class="galleryTable noFloat"
|-
| [[Datei:nodemcu-flasher_1.png|450px|thumb|left|Firmware auswählen]]
| [[Datei:nodemcu-flasher_2.png|450px|thumb|left|Flash Parameter (Advanced Tab) wie abgebildet einstellen]]
|}

4) COM-Port auswählen und den Flashvorgang starten (Button: '''Flash(F)''') ...
[[Datei:nodemcu-flasher_3.png|450px|thumb|left|COM Port auswählen und das "Flashen" initiieren]]
<div style="clear:both;"></div>

Nach dem Flashen sollte über die serielle Ausgabe des ESP der Start und das Öffen des AccessPoints zu sehen sein.

'''''Hinweis:''' Die Geschwindigkeit von 921600 baud ist nicht auf jedem Rechner (besonders auf virtualisierten Systemen) machbar. In diesem Fall die Baudrate auf 57600 reduzieren.''

==Funktionsweise==
Während des Startvorgangs versucht sich das LaCrosseGateway in einem WLAN anzumelden. Dazu muss es eine SSID und das entsprechende Passwort kennen.

Beim ersten Start (nach dem initialen Aufspielen der Firmware) sind diese Informationen noch unbekannt. Aus diesem Grund wird folgende Strategie verfolgt:

Wenn es sich in keinem WLAN anmelden kann, dann öffnet es einen Access Point mit der SSID "LaCrosseGateway_'''xxxxxx'''", wobei '''xxxxxx''' die eindeutige Chip-ID des ESP8266 ist.

Der Access Point wird aus Sicherheitsgründen nach 15 Minuten wieder geschlossen.
Innerhalb dieser 15 Minuten kann man sich mit dem Access Point verbinden. Der Access Point vergibt (per DHCP) IP-Adressen aus dem Netzwerk 192.168.222.0. Anschließend kann über die LaCrosseGateway Konfigurationsseite [http://192.168.222.1/setup http://192.168.222.1/setup] die initiale Konfiguration vorgenommen werden.
Die Konfiguration wird im EEPROM gespeichert und bei zukünftigen Neustarts verwendet.
Die Konfigurationsseite ist auch im "Normalbetrieb" (ohne Access Point) über die Adresse http://''seine aktuelle IP-Adresse''/setup erreichbar.

Wenn sich das LaCrosseGateway an dem konfigurierten WLAN anmelden konnte (es wartet max. 30 Sekunden auf einen connect) und von diesem per DHCP eine IP-Adresse erhalten hat, dann stellt es auf dieser Adresse den Port 81 zur Verfügung, über den in FHEM das LaCrosseGateway Modul senden und empfangen kann.

'''Optische Darstellung der Initialisierung'''

Beim Start und der Initialisierung wird mit der Board-eigenen LED signalisieren, was gerade passiert:
*5 schnelle blinks direkt nach dem Start, als Zeichen, dass ein Reset stattgefunden hat
*Blinken im Sekundentakt, während versucht wird, sich mit einem WLAN zu verbinden.
*LED aus, wenn der Connect zu einem WLAN geklappt hat und dann vereinzeltes Blinken, wenn Daten an FHEM übermittelt werden

== LaCrosseGateway einrichten ==
Für die Ersteinrichtung des LaCrosseGateways werden die SSID und das Passwort des WLAN-Routers benötigt. Ferner wird empfohlen auf dem WLAN-Router bzw. dem DHCP-Server eine IP-Adresse für das LaCrosseGateway zu reservieren. Für die Reservierung wird die MAC-Adresse des LaCrosseGateways benötigt, diese kann über die "Home"-Page des LaCrosseGateways ermittelt, alternativ von dem [[#Windows per "nodemcu-flasher" |NODEMCU Firmware Programmer]] (''Reiter "Operation -> "STA MAC"'') entnommen werden.

Sofern diese Vorbereitungen getroffen wurden und alle Informationen vorliegen, kann das LaCrosseGateway eingerichtet werden.

'''''<u>Für die Konfiguration sind folgende Schritte nötig:</u>'''''
*Mit dem LaCrosseGateway Access Point "LaCrosseGateway_xxxxxx" verbinden (siehe [[#Funktionsweise |Beschreibung Funktionsweise]])
*Mithilfe eines Browsers die [http://192.168.222.1/setup LaCrosseGateway "Setup"-Page] öffnen
*SSID und das Password eintragen. Man kann zwei SSID/Passwort-Kombinationen mit jeweils einem Timeout konfigurieren. 120 bedeutet z.B. dass das LGW 120 Sekunden lang versucht, die SSID zu erreichen. Falls die erste SSID nach "Timeout" Sekunden nicht erreicht wurde, wird Timeout Sekunden lang versucht, die zweite SSID zu connecten.
*''[Empfohlen]'' Das Frontend Passwort festlegen
*''[Optional]'' Falls kein DHCP-Server zur Verfügung steht bzw. keine Reservierung erwünscht ist, dann muss die IP-Adresse / Netmask (Optional auch Gateway) eingetragen werden
*''[Empfohlen]'' Hostnamen festlegen bzw. anpassen
*Alle Angaben mit dem Button "save and restart" bestätigen. Dabei werden die vorgenommen Einstellungen im EEPROM gespeichert und ein Neustart des LaCrosseGateways initiiert.

Nach dem Neustart verbindet sich das LaCrosseGateway mit dem WLAN-Router.

Anschließend kann mit der [[#Hinweise zum Betrieb mit FHEM |Inbetriebnahme in FHEM]] fortgefahren werden.

==Firmware aktualisieren==

Nachfolgend werden, neben der unter dem Punkt [[#Firmware aufspielen |Firmware aufspielen]] beschriebenen Möglichkeiten, weitere Möglichkeiten zur Aktualisierung der LaCrosseGateway [[LaCrosseGateway#Firmware Download|Firmware]] aufgezeigt.

Hinweis: Die Einstellungen des LaCrosseGateway werden dabei nicht gelöscht.

=== Per FHEM (OTA-Update)===
Voraussetzungen:

*Das LGW muss auf der IP-Adresse, die im LaCrosseGateway Modul definiert ist, erreichbar sein
*Es wird kein avrdude benötigt
*Das Attribut "flashCommand" spielt keine Rolle

Die LaCrosseGateway Firmware kann von LaCrosseGateway Device (LaCrosseGateway Modul) aus mit
<syntaxhighlight lang="php">set myLaCrosseGateway flash</syntaxhighlight> aktualisiert werden.
'''''myLaCrosseGateway''' muss bei Bedarf auf den Gerätenamen in FHEM angepasst werden.''

'''''Hinweis:''' Das Update dauert ca. 30 Sekunden.''

=== Per FHEM (USB)===
Voraussetzungen:
Auf dem FHEM-Server muss Python und pyserial installiert sein. Die Installation kann z.B. so erfolgen:
*apt-get install python
*wget https://bootstrap.pypa.io/get-pip.py
*python get-pip.py
*pip install pyserial

Das Attribut "mode" muss auf USB gesetzt sein: attr myLaCrosseGateway mode USB

Der flash-Vorgang wird gestartet mit: set myLaCrosseGateway flash

=== Per CURL ===
Voraussetzungen:
*[https://curl.haxx.se/download.html curl-Tool] installiert

'''''Beispiel:'''''
<syntaxhighlight lang="php">curl --http1.0 -# -o ~output.txt -H "Content_Type:multipart/form-data" -F "file=@.\JeeLink_LaCrosseGateway.bin; filename=firmware.bin" http://192.168.31.211/ota/firmware.bin</syntaxhighlight>

'''Firmwaredateiname (file=)''' und die '''IP-Adresse''' muss entsprechend angepasst werden.

=== Per WEB OTA-Update (deprecated)===

'''''deprecated'''''

==LaCrosseGateway Web-Frontend==
===Staus-Wert RSSI===
Die WiFi Signalstärke (dBm) (-36 ist besser als -60)

===Staus-Wert FramesPerMinute===
Dieser gibt an, wie viele frames von Sensoren in der letzten Minute erfolgreich empfangen, dekodiert und verarbeitet wurden.
Es eignet sich zur Überwachung, wenn weniger als ein Grenzwert empfangen wurde, dann kann ein Alarm (Benachrichtigung, Restart etc.) ausgelöst werden.

===Staus-Wert ReceivedFrames===
Dieser Wert gibt an, wie viele seit dem Start des LGW empfangen wurden.

===WiFi "Startup-delay"===

Mit diesen Konfigurationsprameter kann eine Verzögerung (in Sekunden) definiert werden, bis das LGW nach einen Neustart einen ersten Verbindungsversuch zum WiFi Access Point (Router: Fritzbox etc.) startet.

Eine Anpassung kann für den folgenden Fall sinnvoll sein:

Nach einem Stromausfall benötigt ein WiFi Access Point (Router: Fritzbox etc.) in den meisten Fällen länger zum Starten als das LGW. In der default Einstellung führt das dazu, dass der LGW nach dem Starten versucht 30 Sekunden lang eine Verbindung zum AP herzustellen. Wenn keine Verbindung innerhalb dieser Zeit zustande kommt, dann gibt das LGW auf und macht seinen eigenen AP auf. Mit einer entsprechenden Verzögerung (Dauer bis der Router gestartet ist und der WiFi-AP zur Verfügung steht) kann sichergestellt werden, dass der AP gestartet ist und sich das LGW mit dem AP verbinden kann.

===Internal Sensors "Sensor-ID"===
Bei Einsatz von mehr als einem LaCrosseGateway, muss die LaCrosse-ID, mit der die internen Sensoren des Gateways übermittelt werden, angepasst werden.
Hierbei ist darauf zu achten, dass die LaCrosse-ID nur einmal auf einer FHEM Instanz vorkommen darf. Die ID kann entweder Dezimal (211) oder Hex (0xD3) angegeben werden.

'''''Detailinformationen:''''' Wenn ein LGW interne Sensoren hat (BME280, BMP180, DHT22, ...) dann sendet es die Daten des Sensors so, als ob es eine Wetterstation wäre (WS 1600 Format) an das LGW. Bisher hat es dafür die Sensor-ID 0 verwendet. Wenn man mehrere LGWs an ein FHEM angebunden hat, dann mischen sich deren Sensor-Daten auf dem LaCrosse device mit der ID 0. Um das zu vermeiden, kann man nun konfigurieren, mit welcher Sensor-ID die internen Sensoren gesendet werden sollen und die beiden LGWs unterschiedliche konfigurieren.

Die Anpassung der LaCrosse-ID hat keinerlei Einfluss auf die Daten, die von den Radios empfangen werden.

===Internal Sensors "Altitude"===
Mit diesen Parameter kann die Höhe über NN konfiguriert werden.

===Internal Sensors "Temperature-/Humidity-correction"===
Für Temperatur und Feuchte kann ein Korrekturwert angegeben werden.

Der Wert kann entweder ein Offset oder prozentual sein.

'''Beispiele:'''

{| class="wikitable" style="margin-left: auto; margin-left: 0px;"
! Korrekturwert !! Gemessen !! Ergebnis
|-
| -5
| 20°C
| 15°C
|-
| +3
| 20°C
| 23°C
|-
| -10%
| 20°C
| 18°C
|-
| +20%
| 20°C
| 24°C
|}

===SC16IS750-Clone===
Wenn aktiviert, wird die I2C clock auf 100 kHz runtergenommen und
es wird an einigen Stellen etwas auf die Bremse getreten, dass ein SC16IS70-Clone, der langsamer
als echte Hardware ist, mitkommt.
Sollte man ohne zwingenden Grund nicht aktivieren.

===Use MDNS===
Legt fest, ob das LGW seine IP-Adresse per MDNS bekannt gibt. Dies ist nötig, wenn man einen Mac hat oder bei Windows einen Bonjour-Service laufen hat.
Dies ist beim Entwickeln sinnvoll, kann üblicherweise ausgeschaltet bleiben.

===MCP23008===
Konfigurationsmöglichkeit für die 8 IO Pins (siehe auch [[#Inbetriebnahme_von_MCP23008|Inbetriebnahme von MCP23008]]).

===Serial bridge port und bridge baud===
Das LGW kann nun optional die serielle Schnittstelle des SC16IS750 transparent auf einem TCP Port bereitstellen.
Dazu gibt es die "Serial bridge port" und "Serial bridge baud" auf der "config"-Page des LGWs.
Das LGW überträgt transparent die Daten der seriellen Schnittstelle an FHEM und umgekehrt.

===Soft Serial Bridge===
Das LGW kann optional eine Soft serial bridge (Zuverlässig nur mit bis zu 57600 baud) transparent auf einem TCP Port bereitstellen.
Folgende Parameter können auf der LGW Setup-Page angepasst/konfiguriert werden:

{| class="wikitable" style="margin-left: auto; margin-left: 0px;"
! Parameter !! Beschreibung
|-
| Port
| Der Port, auf dem es angesprochen werden kann
|-
| Baud
| Die Baudrate für die Kommunikation
|-
| Nextion display
| Für den Betrieb eines Nextion Display muss diese Option aktiviert sein.
|-
| Add units
| Fügt an die Werte (Temp,Hum,Pres), die das LGW an das Display schickt, Einheiten an.
|}

Mithilfe des Soft serial bridge können verschiedene Geräte (nanoCUL, Nextion Display, etc.), welche per seriellen Schnitstelle kommunizieren können, in Betrieb genommen werden.

===Statuswerte abrufen===
Mit http://<IP-des-LGW>/state können die Statuswerte, die das LGW-Frontend anzeigt, als XML zur Weiterverarbeitung abgerufen werden.

Beispiel:
<syntaxhighlight lang="php"><LGW>
<Info Key="UpTimeSeconds" Value="107086"/>
<Info Key="UpTimeText" Value="1Tg. 5Std. 44Min. 46Sek. "/>
<Info Key="WIFI" Value="NeverTellThem"/>
<Info Key="MacAddress" Value="18:FE:34:9A:6D:48"/>
<Info Key="ChipID" Value="10120520"/>
<Info Key="ReceivedFrames" Value="93593"/>
<Info Key="FramesPerMinute" Value="52"/>
</LGW></syntaxhighlight>

===Funktionsweise Log===
Das Log ist als Hilfsmittel bei der Fehlersuche gedacht z.B. um bei PCA301 zu verfolgen, wann wer was wie frägt und antwortet oder um zu schauen, ob irgend welche Sensoren überhaupt empfangen werden und die Daten an FHEM geliefert werden.

[[Datei:lgw_LogPage.png|600px|thumb|left|LaCrosseGateway Log ebfrontend]]
<div style="clear:both;"></div>
Mit "Command" kann man Befehle an das LGW senden. Sie entsprechen dem, was man mit "set myLaCrosseGateway raw ..." aus FHEM schicken kann.
Die obere Liste enthält die Daten, die an FHEM übermittelt werden (bzw. würden, wenn sich ein FHEM auf das LGW verbunden hat)
Die untere Liste enthält debug-Informationen u.a. wird hier der letzte Systemstart aufgezeichnet.
Die verwendete SDK-Version und der letzte Reset-Grund werden ebenfalls ausgegeben

Das Log kann per HTTP abgerufen werden:
<syntaxhighlight lang="php">http://<LGW-IP>/getLogData</syntaxhighlight>

'''''Beispiel:'''''
<syntaxhighlight lang="php">http://192.168.31.211/getLogData</syntaxhighlight>

das Ergebnis sieht wie folgt aus:
<syntaxhighlight lang="php">DATA:OK 22 117 196 0 58 226 102 0 58 191 86 0 0 40 172 0 105 1 101 3 0 [75 C4 E2 66 00 00 BF 56 00 00 00 02 3B FC DC 00 69 01 65 4A A4 C4 F9 F2 4F 11 A4 F6 7C 03 A0 00 00 00 00 03 A0 38 09 21 27]
DATA:OK 9 11 130 4 173 125 [92 D5 97 7D 75]
DATA:OK EMT7110 84 81 8 207 0 36 0 1 1 199 1 [25 6A 54 51 40 02 00 24 C3 41 C7 9B]
SYS: AddOn: KV ADDON 01 Voltage=3.33,UpTime=4921
DATA:OK VALUES ADDON 01 Voltage=3.33,UpTime=4921
DATA:OK 9 38 1 4 67 65 [99 84 91 41 07]
DATA:OK 22 126 67 0 65 236 34 0 65 231 116 0 0 32 103 0 48 0 134 1 0 [7E 43 EC 22 00 00 E7 74 00 00 00 01 C7 AC D7 00 30 00 86 00 57 E4 69 1E 46 8E D4 68 C7 04 10 00 00 00 00 04 10 18 0A DC F7]
DATA:OK 9 36 1 4 128 61 [99 05 52 3D 96]
DATA:OK WS 0 4 4 185 255 255 255 255 255 255 255 255 255 0 3 252</syntaxhighlight>

'''''DATA:''''' für die obere Liste

'''''SYS: ''''' für die untere Liste

Bei jedem Aufruf werden die seit dem letzten Abruf neu aufgelaufenen Logeinträge geliefert.
Intern werden maximal 40 Einträge gepuffert (aber kein Ringpuffer, weil die ersten 40 mit dem Bootlog erhalten bleiben müssen)

'''''Hinweis:''''' Aus Performance- und Stabilitätsgründen sollten die Daten nicht zu häufig und nicht von zwei Instanzen gleichzeitig abgerufen werden.

=Hinweise zum Betrieb mit FHEM=

==Voraussetzungen==
Es wird ein [[#LaCrosseGateway einrichten |vorkonfiguriertes]] LaCrosseGateway vorausgesetzt.

Perl Modul: ''LWP::UserAgent'' - Dieses wird für das Firmware Update per FHEM LaCrosseGateway Modul benötigt.
Auf einem Raspberry Pi kann die Installation wie folgt durchgeführt werden:
<syntaxhighlight lang="php">sudo apt-get install libwww-perl</syntaxhighlight>
alternativ auch mit
<syntaxhighlight lang="php">sudo cpan LWP::UserAgent</syntaxhighlight>

'''FHEM Module'''

'''Hinweis:''' Ursprünglich wurde für das LaCrosseGateway das FHEM-Modul 36_JeeLink.pm verwendet. Da es aber inzwischen erhebliche Unterschiede zwischen dem JeeLink-LaCrosse-Sketch und dem LaCrosseGateway gibt, existiert seit Mitte November 2016 ein für das LaCrosseGateway spezialisiertes und optimiertes FHEM-Modul, das 36_LaCrosseGateway.pm.<br>
Dieses sollte anstatt dem 36_JeeLink.pm vorzugsweise verwendet werden.

''36_LaCrosseGeateway.pm'' (wird per FHEM Update verteilt)

''36_KeyValueProtocol.pm'' (wird per FHEM Update verteilt)

''36_LaCrosse.pm'' (wird per FHEM Update verteilt)

''36_PCA301.pm'' (wird per FHEM Update verteilt)

''36_EC3000.pm'' (wird per FHEM Update verteilt)

''36_EMT7110.pm'' (wird per FHEM Update verteilt)

''36_Level.pm'' (wird per FHEM Update verteilt)

''42_Nextion.pm'' (wird per FHEM Update verteilt)

==Device Definition==
===WLAN===
Die Definition sieht dann wie folgt aus:

<code>define <myLaCrosseGateway> LaCrosseGateway <IP-Adresse>:81</code>

''<myLaCrosseGateway>'' kann bei Bedarf angepasst werden.

''<IP-Adresse>'' muss entsprechend angepasst werden. Anstatt der IP-Adresse kann auch der Hostname vom LaCrosseGateway verwendet werden.

'''Beispiel:'''
<syntaxhighlight lang="php">define myLaCrosseGateway LaCrosseGateway 192.168.22.33:81</syntaxhighlight>
<u>IP-Adresse ermitteln:</u> Das LaCrosseGateway heist per default Einstellung "''LaCrosseGateway''", per ping auf den Hostnamen ''LaCrosseGateway'' kann die <IP-Adresse> ermittelt werden.

===USB===
Wenn man das LGW über USB betreiben will, dann möchte man üblicherweise kein WiFi.
Um das WiFi zu deaktivieren gibt es zwei Möglichkeiten:<br>
1.) Man kann mit einen 10k pullup auf 3.3V an MOSI == GPIO13 == D7 "jumpern", dass man kein wifi will. Wenn voranden, wird WiFi sofort beim Start deaktiviert.<br>
2.) Man kann WiFi auf der Setup-Page des LGW deaktivieren.<br>

Für den Betrieb via USB sieht die Definition wie folgt aus:

<code>define <myLaCrosseGateway> LaCrosseGateway <USB-Port>@57600</code>

''<myLaCrosseGateway>'' kann bei Bedarf angepasst werden.

''<USB-Port>'' muss entsprechend angepasst werden.

Beispiel: <code>define myLaCrosseGateway LaCrosseGateway /dev/ttyUSB0@57600</code>
''/dev/ttyUSB0'' Falls bereits mehrere USB Geräte angeschlossen sind muss der USB Port angepasst werden.

'''Hinweis:''' Sind mehrere USB Devices am FHEM Server (z.B. RPI, Cubietruck etc.) in Betrieb, dann ist die Zuordnung über den USB-Port nicht zuverlässig. Die Ports werden u.a. in der Reihenfolge vergeben, in der die Geräte angeschlossen werden. Zuverlässiger und eindeutiger ist die Zuordnung über die Serial-ID.

Dieser Befehl zeigt die Serial-ID der angeschlossenen USB-Devices an:
<code>ls -l /dev/serial/by-id</code>

Beispiel für die Ausgabe:
<syntaxhighlight lang="text">lrwxrwxrwx 1 root root 13 Mai 14 10:37 usb-Prolific_Technology_Inc._USB-Serial_Controller-if00-port0 -> ../../ttyUSB1
lrwxrwxrwx 1 root root 13 Mai 30 11:27 usb-Silicon_Labs_CP2102_USB_to_UART_Bridge_Controller_0001-if00-port0 -> ../../ttyUSB2
lrwxrwxrwx 1 root root 13 Apr 16 14:52 usb-Silicon_Labs_ELV_USB-Modul_UM2102_EVFSRFF8COEXIKOT-if00-port0 -> ../../ttyUSB0</syntaxhighlight>
In diesem Fall ist u.a. ein DEVKIT 1.0 mit der Serial-ID ''usb-Silicon_Labs_CP2102_USB_to_UART_Bridge_Controller_0001-if00-port0 -> ../../ttyUSB2'' angeschlossen.

Auf Basis dieser Informationen lässt sich folgende Definition erstellen:

<code>define myLaCrosseGateway LaCrosseGateway /dev/serial/by-id/usb-Silicon_Labs_CP2102_USB_to_UART_Bridge_Controller_0001-if00-port0@57600</code><br>
Wichtig ist es, die Übertragungsrate von 57600 bit/s anzugeben.<br><br>

Wenn man das LGW ohne WiFi betreibt, dann muss man natürlich auf die Annehmlichkeiten des Web-Frontends verzichten.<br>
In diesem Fall kann man die Konfiguration, die man über das Web-Frontend machen würde, über die serielle Schnittstelle machen.<br>

<code>set myLaCrosseGateway raw "SETUP ..."</code><br>
Das ... sind die gewünschten Einstellungen. Es müssen nicht alle Einstellungen gesendet werden sondern nur die, die man setzen will.<br>
Es werden nur die Einstellungen gesetzt und im EEPROM gespeichert, es wird aber kein Reboot ausgelöst<br>
Einen Reboot kann man mit "set myLaCrosseGateway raw 8377e" auslösen.<br>
Mehrere Einstellungen können durch Semikolon getrennt angegeben werden.<br>
Beispiel:
<code>set myJeeLink213 raw "SETUP UseWiFi false; IO0 OLED mode=thp; IO1 OLED Off; CorrT -2.5; ISID 213"</code>

Man kann auf der seriellen Schnittstelle die aktuellen Einstellungen abrufen.
Das command ist 1g<br>
<code>set myLaCrosseGateway raw 1g</code><br>
Man bekommt dann so etwas zurück:
<syntaxhighlight lang="text">SETUP ctSSID esesidee; ctPASS PasstWort; staticIP 192.168.31.211; staticMask 255.255.255.0; staticGW 192.168.31.1;
HostName LGW211; StartupDelay 1; ISID 0xD3; Altitude 220; CorrT 0; CorrH 0; DataPort1 81; DataPort2 82; SerialBridgePort 85;
SerialBridgeBaud 38400; UseMDNS true; IO0 OLED mode=s; IO1 OLED mode=thp; IO2 OLED On; IO3 OLED Off; oledStart 120; KVInterval 10;
KVIdentity 211; PCA301Plugs 036180=3,03A094=1,035FF1=6;</syntaxhighlight>

==Reconnect==
Falls das LaCrosseGateway nicht erreichbar ist (Kein Strom/Stromausfall, WLAN Verbingung unterbrochen etc.), bricht das LaCrosseGateway Device die Kommunikation ab. Über das entsprechende ''timeout'' Attribut kann das LaCrosseGateway device so konfigurert werden, dass es in regelmässigen Abständen erneut versucht eine Verbindung mit dem LaCrosseGateway herzustellen.

Konfigurationsempfehlung für ''timeout'' = 120 Sekunden und ''checkInterval'' = 30 Sekunden:

Der Wert kann in FHEM wie folgt gesetzt werden:
<syntaxhighlight lang="php">attr myLaCrosseGateway timeout 120,30</syntaxhighlight>
'''''myLaCrosseGateway''' muss auf den Gerätenamen in FHEM angepasst werden.''

Während das LaCrosseGateway eine WiFi-Verbindung aufbaut, benötigt das LaCrosseGateway-Modul je nach Konfiguration einige Zeit bis es einen neuen Connect auf den Datenport des LaCrosseGateway versucht. Das Finden der optimalen Werte erfordert etwas Geduld, es kann auch schon mal ein, zwei Minuten Dauern, bis die ersten Daten in FHEM übertragen werden.

'''''Erklärung der Timeout Werte:'''''
120,30 prüft alle 30 Sekunden, ob seit mindestens 120 Sekunden keine Daten mehr übermittelt wurden und falls dem so ist, macht es einen Reset auf der Schnittstelle, was die Verbindung zum LaCrosseGateway neu aufbaut. Das bedeutet, in so einem Fall ist die Verbindung nach spätestens 150 Sekunden wieder hergestellt.

'''''Hinweis:''' Mit diesem Attribut wird lediglich eine neue Verbindung aufgebaut, dabei wird das LaCrosseGateway nicht resetet.''

==Liste aller initCommands==
Eine aktuelle Liste der initCommands, die man von FHEM, Terminalprogramm oder Web-Frontend aus senden kann, sind auf dem Web-Frontend "Help"-Page" des LaCrosseGateways (ab V1.17) aufgeführt.

[http://IP-Adresse/setup http://IP-Adresse oder Hostname/help]

<syntaxhighlight lang="php">
<n>a set to 0 if the blue LED bothers
<n>c use one of the possible data rates (for transmit on RFM #1)
<n>d set to 1 to see debug messages
<8266>e Clear EEPROM
<n>f initial frequency in kHz (5 kHz steps, 860480 ... 879515)
<n>g get information (1g: get current settings)
<n>h Altitude
<n,f,i>i Init PCA for Radio #<n> to <m>MHz and <i>s Interval
<n>m bits 1: 17.241 kbps, 2 : 9.579 kbps, 4 : 8.842 kbps, 8 : 20.000 kbps (for RFM #1)
<n>M bits 1: 17.241 kbps, 2 : 9.579 kbps, 4 : 8.842 kbps, 8 : 20.000 kbps (for RFM #2)
<n>#<x>m bits 1: 17.241 kbps, 2 : 9.579 kbps, 4 : 8.842 kbps, 8 : 20.000 kbps (for RFM #x)
<n>o set HF-parameter e.g. 1,4o for RFM69
<n>p payload on the serial port (1: all, 2: only undecoded data)
<n>r use one of the possible data rates (for RFM #1)
<n>R use one of the possible data rates (for RFM #2)
<n>#<x>r use one of the possible data rates (for RFM #x)
<x,x,...>s Send to PCA301 (must be 10 byte)
<x,x,...>S Send to CustomSensor
<n>t 0=no toggle, else interval in seconds (for RFM #1)
<n>T 0=no toggle, else interval in seconds (for RFM #2)
<n>#<x>t 0=no toggle, else interval in seconds (for RFM #x)
v show version
<n>w 0=no wifi
<n>z set to 1 to display analyzed frame data instead of the normal data
</syntaxhighlight>

==LaCrosseGateway zurücksetzen==
Das LaCrosseGateway kann auf die "Werkseinstellungen" zurückgesetzt werden.<br>
Dadurch werden alle auf der Setup-Page gemachten und im EEPROM gespeicherten Einstellungen verworfen.
Der Befehl dazu lautet: <syntaxhighlight lang="php">8266e</syntaxhighlight>
Er kann mit einem Terminalprogramm, von FHEM aus mit <syntaxhighlight lang="php">set <myLaCrosseGateway> raw 8266e</syntaxhighlight> oder von der Log-Page des LGW gesendet werden.

Danach startet das LGW wieder als Access Point [[#LaCrosseGateway einrichten|initiale Konfiguration]] und die Konfiguration kann über die "Setup-Page" neu vorgenommen werden kann.

==Sensoren/Aktoren anlegen==

Voraussetzung: FHEM autocreat ist aktiv.
Die [http://fhem.de/commandref.html#autocreate FHEM autocreate Funktion] ist aktiv.

Die erkannnten Sensoren und Aktoren werden automatisch erkannt und in FHEM angelegt, sobald Daten empfangen werden.

Empfangene Sensoren werden nur hinzugefügt werden, wenn LaCrossePairForSec auf 120 Sekunden gesetzt wird.
<syntaxhighlight lang="php">set myLaCrosseGateway LaCrossePairForSec 120 ignore_battery</syntaxhighlight>

==Inbetriebnahme von BMP180 / BME280==
Damit die Daten der o.g. Sensoren in FHEM zur Verfügung stehen, muss zunächst das FHEM-Device angelegt werden.

Das Anlegen kann automatisch erfolgen, dafür muss der folgende FHEM Befehl ausgeführt werden:
<syntaxhighlight lang="php">set myLaCrosseGateway LaCrossePairForSec 120 ignore_battery</syntaxhighlight>

Dann sollte von [http://fhem.de/commandref.html#autocreate FHEM autocreate Funktion] ein LaCrosse Device mit der [[#Sensor-ID | Sensor-ID]] (Default Wert: 0) angelegt werden.

Alternativ kann das FHEM Device manuell angelegt werden:
Die '''''ID''''', mit der das LGW die internen Sensoren sendet, entspricht der konfugurierten [[#Sensor-ID | Sensor-ID]] (Default Wert: 0)
Es verhält sich so, als ob es eine Wetterstation (wie z.B. WS 1600) wäre.
<syntaxhighlight lang="php">define <name> LaCrosse 00</syntaxhighlight>
Anchließend muss eine Höhenkorrektur (Grund: der Luftdruck wird immer bezogen auf NN angegeben, der Sensor liefert aber den Absolutdruck) mit dem command '''''h''''' in den initCommands vorgenommen werden, dies erfolgt mit dem FHEM Befehl:

Beispiel: 220h legt 220m über NN fest.''
<syntaxhighlight lang="php">attr myLaCrosseGateway initCommands 220h</syntaxhighlight>

'''Besser:''' Alternativ kann die Höhe über NN auch auf der Setup-Page des LGW gesetzt werden.<br>
Das hat den Vorteil, dass sofort vom Start an der normalisierte Luftdruck an FHEM gesendet wird und nicht erst, wenn die initCommands von FHEM geschickt wurden.

==Inbetriebnahme Piezo Summer==

Der Piezo Summer wird in FHEM über das LaCrosseGateway Modul angesteuert.

'''Beispiele:'''
<syntaxhighlight lang="php">
set myLaCrosseGateway raw 1,60b -> beep ... beep ... beep 60 Sekunden lang
set myLaCrosseGateway raw 2,300b -> beep beep ... beep beep ... beep beep 300 Sekunden lang
set myLaCrosseGateway raw 3,120b -> beep beep beep ... beep beep beep ... 120 Sekunden lang
set myLaCrosseGateway raw 0b -> beep stoppen
</syntaxhighlight>

==Inbetriebnahme von RFM69CW==
Mit dem LaCrosseGateway ist es möglich mehrere RFM69CW einzusetzten. Nachfolgend wird die Konfiguration des Senders/Empfängers erläutert.

Die "Default Werte" (wenn keine Angaben definiert werden) für die data rate sind wie folgt definiert:
<syntaxhighlight lang="php">
#1 (Erste) => 17241
#2 (Zweite) => 9579
#3 (Dritte) => 8842
#4 (Vierte) => 20000
#5 (Fünfte) => 17241
</syntaxhighlight>

'''''Hinweis:''' Detailinformationen sind auch auf der LaCrosseGateway "Help"-Page zu finden.''

{| class="wikitable" style="margin-left: auto; margin-left: 0px;"
|-
|colspan="2" style="text-align:center"|'''<Datenrate>#<Radio-Nummer><command>'''
|-
| <code>m t:</code> || ''Toggle-Steuerung''
|-
| <code>r:</code> || ''Datarate''
|-
| <code>f:</code> || ''Frequenz''
|}

'''''Beispiele:'''''

''
{| class="wikitable" style="margin-left: auto; margin-left: 0px;"
!Definition !! Erläuterungen
|-
| <syntaxhighlight lang="php">attr myLaCrosseGateway initCommands 0#1r v</syntaxhighlight>
| DataRate des ersten RFM setzen
|-
| <syntaxhighlight lang="php">attr myLaCrosseGateway initCommands 8842#3r v </syntaxhighlight>
| DataRate des dritten RFM setzen
|-
| <syntaxhighlight lang="php">attr myLaCrosseGateway initCommands 868300#2f v</syntaxhighlight>
| Frequenz des zweiten RFM setzten
|-
| <syntaxhighlight lang="php">attr myLaCrosseGateway initCommands 868295#3f v</syntaxhighlight>
| Frequenz des dritten RFM setzten
|-
| <syntaxhighlight lang="php">attr myLaCrosseGateway initCommands 17241#1r 8842#2r v</syntaxhighlight>
| Zwei RFM69CW mit DataRate 17241 und 8842
|-
| <syntaxhighlight lang="php">attr myLaCrosseGateway initCommands 3#1m 20#1t 8842#2r v</syntaxhighlight>
| Zwei RFM69CW mit 20 Sekunden DataRate 17241 toggle 9579 plus 8842 permanent
|-
| <syntaxhighlight lang="php">attr myLaCrosseGateway initCommands 220h 868295#1f 868310#2f v</syntaxhighlight>
| Zwei RFMs Frequenz 868295 und 868310 sowie Höhe über NN
|-
| <syntaxhighlight lang="php">attr myLaCrosseGateway initCommands 868295#1f 3#1m 20#1t 2,868950,60i 8842#3r 220h 0a v</syntaxhighlight>
| Drei RFMs Frequenz 868295 / PCA301 / WS1600 sowie Höhe über NN <br>Radio 1 auf 868295 MHz und Toggle 9K/17K mit 20 Sekunden<br>Radio 2 für PCA301 initialisiert<br>Radio 3 macht 8842 kbps für die WS 1600<br>Höhe 220m über NN<br>Activity LED aus<br>v am Ende ruft die neu gesetzen Daten vom LaCrosseGateway ab, damit sie in FHEM LaCrosseGateway Modul aktualisiert werden.
|}

'''''Hinweis:''' Es ist wichtig ein "v" an das Ende eines initCommands anzuhängen. Damit wird veranlasst, dass das LaCrosseGateway seine neuen Einstellungen an FHEM zurückmeldet.
==Inbetriebnahme von PCA301==
PCA301 im LGW funtioniert ähnlich dem PCA301 Sketch, allerding mit einigen systembedingten Abweichungen.

Per default ist PCA301 nicht aktiviert, es muss in den initCommands aktiviert werden. Dazu gibt es das command "'''''i'''''".

'''<RadioNr>,<Frequenz>,<Poll-Intervall>i'''

Die Initialisierung kann auch erneut geschickt werden, um z.B. das Poll-Intervall zu ändern.

'''''Wichtig:''''' Es darf nur '''"ein"''' Radio für PCA301 initialisiert sein, nicht mehrere. Das PCA301 initialisierte Radio ist dediziert für PCA301 zuständig, es kann nicht zwischen anderen Protokollen (z.B. LaCrosse) toggeln.''

Das ''Poll-Interval'' sollte nicht extrem heruntergesetzt (nicht unter eine Minute) werden, da PCA301 sonst LaCrosse verdrängt. PCA301 hat hörere Priorität, da es bei der Kommunikation
mit den Dosen keine Antworten überhören darf.

Unter Umständen muss die Frequenz etwas angepasst werden, wenn das Radio und/oder die Dosen nicht genau auf 868950 liegen.
Das ist daran zu erkennen, dass entweder gar keine Antwort von den Dosen oder verzögerte Antwort ankommt.
Werte von 868960 oder 960970 haben in manchen Fällen Abhilfe gebracht.

'''''Beispiele:'''''

{| class="wikitable" style="margin-left: auto; margin-left: 0px;"
! Definition !! Erläuterungen
|-
| style="width:40%" | <code>attr myLaCrosseGateway initCommands 2,868950,120i v</code>
| Initialisiert den zweiten RFM auf 868950 MHz und setzt das Poll-Intervall auf 120 Sekunden
|-
| <code>attr myLaCrosseGateway initCommands 1,868950,120i 3#2m 20#2t 220h 0a v</code>
| Initialisierung eines LaCrosseGateways mit zwei Radios für TX29, TX35, PCA301 und BMP180/BME280.<br>Das erste Radio macht PCA301 und das zweite toggelt 17241/9579 im 20 Sekunden Takt um TX29 und TX35 zu empfangen<br>der BMP180/BME280 liefert den Druck für 220m Meereshöhe<br>die LED ist deaktiviert
|}

'''Ablauf:'''

Nachdem PCA301 initialisiert ist, lauscht das LaCrosseGateway auf der entsprechenden Frequenz.
Sobald eine Dose empfangen wurde, wird sie in der Konfiguration (EEPROM) dauerhaft registriert und ab sofort gepollt.

Das ''Polling'' funtioniert so, dass für jede Dose geschaut wird, wann sie zuletzt empfangen wurde und wenn das länger als das konfigurierte Interval zurück liegt,
dann wird sie abgefragt. Wenn sonst etwas (Basisstation, anderes FHEM) die Dose abgefragt hat und das LaCrosseGateway die Antwort gehört hat, dann gilt das auch als
empfangen und es wird kein eigener Poll für die Dose ausgelöst. ''Das Zusammenspiel mit einer echten Basisstation konnte bisher nur grob simuliert werden.''

Das ''Pairing'' (also die Vergabe eines Kanals) funktioniert wie im PCA301-Sketch, button an der Dose ''"3 Sekunden"'' drücken, dann vergibt das LaCrosseGateway den nächsten freien Kanal.
Dosen, die bereits einen Kanal haben, können durch ein Schalten vor Ort, an das LaCrosseGateway angelernt werden. Das LaCrosseGateway erkennt sie und nimmt sie in die
Konfiguration auf. Falls die Dose bereits mit einem anderen Kanal bekannt war, wird der Kanal im LaCrosseGateway aktualisisert.

Auf der Setup-Page im Web-Frontend (http://IP-Adresse oder Hostname/setup) des LaCrosseGateway kann die Liste der bekannten Dosen (ID=Kanal) eingesehen werden. Hinweis: Es sollten keine Änderungen in diesem Bereich vorgenommen werden.

Wenn ein Kommando (Schalten, Daten abfragen, ...) an eine Dose gesendet wurde und keine Antwort kam, wird bereits im Sketch drei mal versucht, eine Antwort zu bekommen.

Das PCA301 Modul in FHEM funktioniert komplett wie bisher.

Weiterführende Themen zum PCA301 sind im Wiki [[PCA301 Funkschaltsteckdose mit Energieverbrauchsmessung]] und PCA301 FHEM Thread {{Link2Forum|Topic=11648|LinkText=JeeLink / PCA301 Thread}} beschrieben.

Die Befehle, die der PCA301-Sketch kennt, gibt es im LaCrosseGateway nur teilweise:
{| class="wikitable" style="margin-left: auto; margin-left: 0px;"
! Befehl (Beschreibung)!! Erläuterungen
|-
| <code>a "turn activity LED on or off</code>
| wie bisher
|-
| <code>l "list known devices"</code>
| entfallen, kann man nun im Web-Frontend sehen
|-
| <code>q "turn quiet mode on or off"</code>
| wie bisher
|-
| <code>r "list recordings"</code>
| entfallen
|-
| <code>s "send to plug"</code>
| wie bisher
|-
| <code>v "report version and configuration parameters"</code>
| wie bisher
|-
| <code>d, e, p "poll / turn a device on / off"</code>
| entfallen
|-
| <code>h, +, -, # "modify and display RF12 Frequency register"</code>
| entfallen, ersetzt durch das "i" command bzw. das bereits vorhandene "f" command
|}

==Inbetriebnahme von Energy Count 3000 (EC3000)==
Die EC3000 sendet auf 868.300 kHz mit 20.000 kbps. Dafür wurde eine neue data rate hinzugefügt.
Sie kann mit 3r oder 20000r gesetzt werden. Wenn diese data rate gesetzt wird, wird auch automatisch der RFM69 auf den Empfang von EC3000 uminitialisiert.

EC3000 kann auch in einen data rate toggle mit einbezogen werden. Dazu gibt es nun das bit mit dem Wert 8 für 20.000 kbps

Um EC3000 dediziert mit einem der drei RFMs zu empfangen muss man einfach die data rate des gewünschten RFM setzen. Beispiel initCommand:
20000#2r

Um EC3000 in einen data rate toggle mit einzubeziehen muss im m command das 8-wertige bit gesetzt werden.
Wenn man z.B. mit dem zweiten Radio 17k Sensoren (TX29...) und EC3000 empfangen soll (20 Sekunden toggle), wäre das initCommand:

'''Beispiel:'''
<syntaxhighlight lang="php">attr myLaCrosseGateway initCommands 9#2m 20#2t v</syntaxhighlight>

==Inbetriebnahme von MCP23008==
Auf der LaCrosseGateway "config"-page kann für jeden der 8 IO Pins konfiguriert werden, ob es ein Input oder Output Pin ist.

'''Input''': Eingang, wird per KVP an FHEM übermittelt. Einsatzzweck: z.B. Anschluß von Pushbuttons.

'''Output''': Kann von FHEM aus gesetzt werden. Einsatzzweck: z.B. Anschluß von LEDs.

Beispiel: ''Input => Eingang, wird per KVP an FHEM übermittelt''
<syntaxhighlight lang="php">OK VALUES LGPB 211 GP2=0,GP3=1,GP4=0,GP5=0,GP6=0,GP7=0</syntaxhighlight>

Beispiel: ''Output => Kann von FHEM aus gesetzt werden.''
<syntaxhighlight lang="php">set myLaCrosseGateway raw "MCP GP0=1,GP1=0"</syntaxhighlight>

==Inbetriebnahme Analogport==
Der Analogport A0 des ESP8266 wird als Reading im LaCrosseGatewayModul aufgeführt.
Um das zu aktivieren, muss man auf der Setup-Page des LGW die Option "Send analog values" ankreuzen.
Der Eingangsspannungsbereich von A0 ist 0V ... 1.0V, was zu einem Reading von 0 ... 1023 führt.

==Inbetriebnahme von OLED-Display==
Es wird das 128x64 pixel 0.96" I2C Display mit dem SSD1306 controller und das 128x64 pixel 1.3" mit dem SH1106 controller unterstützt.

Für die korrekte Darstellung auf dem 1.3" Display, muss die Checkbox 1.3" auf der Setup-Page aktiviert werden

Hinweis: das 0.96" Display bekommt man auch in einer Varianten, die SPI unterstützt. Diese Variante kann nur nach einem Umbau verwendet werden.

Der nachfolgende Funktionsumfang ist implementiert:

*OLED ein- und ausschalten sowie das Senden von individuellen Texten über FHEM mithilfe des LaCrosseGateway-Moduls
*OLED Startverhalten konfigurierbar
*Übermittlung des Display Status im KVP
*Anzeige von Statusinformationen in der obersten Zeile mithilfe von Symbolen (siehe Abbildung - von links nach rechts)
**WiFI connect erfolgreich
**Ein FHEM hat sich auf einen DataPort connected
**Ein FHEM hat sich auf den Prozessor an der [[#Serial_transparent_bridge|uart bridge]] connected
**WiFi Signalstärke (dBm). Hinweis: -36 ist besser als -60
[[Datei:lgw_oled_statuszeile.png|400px|thumb|left|OLED Anzeige von Statusinformationen]]
<div style="clear:both;"></div>
*Darstellung von bis zu drei Texten und optional ein Symbol.
*Definition des Zeitintvervalls für das Umschalten zur nächsten Seite
*Zuweisung der Modes an die Ports des MCP23008 (Die Konfiguration erfolgt auf der "Setup"-Page)
*Fortschrittsanzeige beim Flashen eines an die serielle Schnittstelle des SC16IS750 angeschlossenen Arduinos (siehe SubProzessor und Serial transparent bridge)

===OLED Start Modus===
Einstellungsmöglichkeit über die "Config"-Page wie sich das OLED nach einem Start verhalten soll.
Mögliche Optionen: on / off / Anzahl Sekunden, nach denen es ausgeht.
Zusätzlich kann der initiale Mode festgelegt werden (z.B. thp)

===Modes===
{| class="wikitable" style="margin-left: auto; margin-left: 0px;"
! Prefix !! Parameter !! Erläuterung
|-
| OLED mode=
| t
| Temperatur des internen Sensors
|-
| OLED mode=
| h
| Feuchte des internen Sensors
|-
| OLED mode=
| p
| Druck des internen Sensors
|-
| OLED mode=
| s
| Statuswerte des LGW
|-
| OLED mode=
| f
| von FHEM gesetzter Text
|}

===Mögliche Symbole===
{| class="wikitable" style="margin-left: auto; margin-left: 0px;"
! Parameter !! Erläuterung !! OLED Darstellung
|-
| t
| Temperature
| [[Datei:lgw_sym_t.jpg|150px|thumb|left|]]
<div style="clear:both;"></div>
|-
| h
| Humidity
|[[Datei:lgw_sym_h.jpg|150px|thumb|left|]]
<div style="clear:both;"></div>
|-
| p
| Pressure
|[[Datei:lgw_sym_p.jpg|150px|thumb|left|]]
<div style="clear:both;"></div>
|-
| s
| System
|[[Datei:lgw_sym_s.jpg|150px|thumb|left|]]
<div style="clear:both;"></div>
|-
| i
| Info
|[[Datei:lgw_sym_i.jpg|150px|thumb|left|]]
<div style="clear:both;"></div>
|-
| w
| Warning
|[[Datei:lgw_sym_w.jpg|150px|thumb|left|]]
<div style="clear:both;"></div>
|-
| e
| Error
|[[Datei:lgw_sym_e.jpg|150px|thumb|left|]]
<div style="clear:both;"></div>
|}

===Beispiele===

{| class="wikitable" style="margin-left: auto; margin-left: 0px;"
! Definition !! Erläuterung
|-
| style="width:30%" | <syntaxhighlight lang="php">set myLaCrosseGateway raw "OLED On"</syntaxhighlight>
| Schaltet ein angeschlossenes Display ein
|-
| <syntaxhighlight lang="php">set myLaCrosseGateway raw "OLED Off"</syntaxhighlight>
| Schaltet ein angeschlossenes Display aus
|-
| <syntaxhighlight lang="php">set myLaCrosseGateway raw "OLED interval=20"</syntaxhighlight>
| Legt fest, dass (je nach mode) alle 20 Sekunden die nächste Seite angezeigt wird.
|-
| <syntaxhighlight lang="php">set myLaCrosseGateway raw "OLED mode=ths"</syntaxhighlight>
| Zeigt nacheinander Temperatur, Feuchte und Systemdaten an
|-
| <syntaxhighlight lang="php">set myLaCrosseGateway raw "OLED mode=thp"</syntaxhighlight>
| Zeigt nacheinander Temperatur, Feuchte und Luftdruck an
|-
| <syntaxhighlight lang="php">set myLaCrosseGateway raw "OLED mode=thps"</syntaxhighlight>
| Zeigt nacheinander Temperatur, Feuchte, Luftdruck und Systemdaten an
|-
| <syntaxhighlight lang="php">set myLaCrosseGateway raw "OLED mode=f"</syntaxhighlight>
| Zeigt ausschließlich den von FHEM festgeleget Text an
|-
| <syntaxhighlight lang="php">set myLaCrosseGateway raw "OLED mode=s"</syntaxhighlight>
| Zeigt ausschließlich die Systemdaten an
|-
| <syntaxhighlight lang="php">set myLaCrosseGateway raw "OLED show=Soll: 20.5,Ist: 19.2,,t"</syntaxhighlight>
| Zeigt die übergebenen Texte an und links das Symbol für Temperatur
|-
| <syntaxhighlight lang="php">set myLaCrosseGateway raw "OLED show=55%,,,h"</syntaxhighlight>
| Zeigt nur den Text "55%" und das Symbol für Feuchte an. Da es nur ein Text ist, wird er größer dargestellt
|-
| <syntaxhighlight lang="php">set myLaCrosseGateway raw "OLED show=Line 1,Line 2,Line 3"</syntaxhighlight>
| Zeigt drei Texte aber kein Symbol an.
|-
| <syntaxhighlight lang="php">attr myLaCrosseGateway initCommands "OLED mode=thps"</syntaxhighlight>
| Zeigt nacheinander Temperatur, Feuchte, Luftdruck und Systemdaten an. Der Mode wird immer geschickt, wenn FHEM sich neu auf das LGW connected.
|}

==Inbetriebnahme eines Nextion Displays==

Mithilfe der Seriellen Schnittstelle [[#Soft_serial_bridge|(Soft serial bridge]]), kann ein Nextion Display in Betrieb genommen werden. Das Besondere dabei ist, dass das LGW zusätzlich seine Status Informationen (AP-Verbindungsstatus, RSSI ,IP ,Version ,FHEM Verbindungsstatus, etc.) an das Display schickt.
Die Anbindung an FHEM erfolgt Mithilfe des Nextion Moduls (42_Nextion.pm), welches per FHEM Update verteilt wird.

Ein Diskussionsthread zum Thema „LaCrosseGateway mit Nextion Display“ findet man {{Link2Forum|Topic=63443|LinkText=hier}}.

===Voraussetzungen===
Vor der Inbetriebnahme in FHEM, müssen folgende Voraussetzungen erfüllt sein:
*Das Display ist wie [[#Nextion_Display|hier]] beschrieben an das LGW angeschlossen.
*Die [[#Soft_serial_bridge|Soft serial bridge]] auf der LGW Setup-page ist konfiguriert.
*Das LaCrosse Gateway Device ist wie [[#Device_Definition|hier]] beschrieben angelegt.

===Funktionsumfang===

Der nachfolgende Funktionsumfang ist implementiert:

*OTA Firmware (.tft File) übertragung an das Display
*Automatische Anpassung der Baudrate auf dem Nextion
*Das LGW schickt (periodisch) Werte an folgende Controls:
{| class="wikitable" style="margin-left: auto; margin-left: 0px;"
! Control!! Beschreibung/Anmerkung
|-
| LGW#temp.txt
| Nur wenn ein entsprechender on board sensor vorhanden ist.
|-
| LGW#hum.txt
| Nur wenn ein entsprechender on board sensor vorhanden ist.
|-
| LGW#pres.txt
| Nur wenn ein entsprechender on board sensor vorhanden ist.
|-
| LGW#rssi.txt
| WLAN RSSI Signalstärke
|-
| LGW#ip.txt
| IP-Adresse des LGW's
|-
| LGW#fpm.txt
| Frames Per Minute
|-
| LGW#heap.txt
| Free Heap
|-
| LGW#up.txt
| Uptime
|-
| LGW#ver.txt
| Version
|-
| LGW#wifi (vis)
| Setzt die visibility
|-
| LGW#fhem
| Setzt die visibility
|-
| LGW#cpu1
| Setzt die visibility
|-
| LGW#cpu2
| Setzt die visibility
|-
| LGW#main
| Sendet, nachdem es sich initialisiert hat, ein "page LGW#main" an das Nextion.
|-
| LGW#info
| Sendet die Info an die LGW#prog page
|-
| LGW#ptext
| Sendet die Info an die LGW#prog page
|-
| LGW#pbar
| Sendet die Info an die LGW#prog page
|}

*Fortschrittsanzeige beim flashen der Nextion Firmware

===Device Definition Nextion Modul===

Die Definition für die Nextion Bridge sieht dann wie folgt aus:

<code>define <nextion> Nextion <IP-Adresse>:<Port></code>

''<nextion>'' kann bei Bedarf angepasst werden.

''<IP-Adresse>'' muss entsprechend angepasst werden. Anstatt der IP-Adresse kann auch der Hostname vom LaCrosseGateway verwendet werden.

''<Port>'' Ist der auf der Setup-page definierte Port

'''Beispiel:'''
<syntaxhighlight lang="php">define nextion Nextion 192.168.22.33:86</syntaxhighlight> IP-Adresse ermitteln: Das LaCrosseGateway heist per default Einstellung "LaCrosseGateway", per ping auf den Hostnamen LaCrosseGateway kann die <IP-Adresse> ermittelt werden.

===Firmware erstellen und flashen ===
Ein UI für das Nextion Display wird mit dem Nextion Editor erstellt. Mithilfe des Editors kann die entsprechende Firmware (tft Datei – siehe „File -> Open build folder“) kompiliert (Button: Compile) werden.

Das LGW kann die Firmware (.tft Datei) zum Display übertragen. Dazu gibt es zwei Varianten:

'''curl'''

Syntax lautet:

<code>curl --http1.0 -# -o ~output.txt -H "Content_Type:multipart/form-data" -F "file=@<tftFileName>; filename=nextion.tft" http://<LGW-IP>/ota/nextion</code>

Beispiel:

<code>curl --http1.0 -# -o ~output.txt -H "Content_Type:multipart/form-data" -F "file=@D:\MyNextionFiles\lgw.tft; filename=nextion.tft" http://192.168.31.213/ota/nextion</code>

'''Das LaCrosseGateway Modul in FHEM'''

Syntax lautet:

<syntaxhighlight lang="php">set <myLaCrosseGateway> nextionUpload</syntaxhighlight>

Wenn das Attribut "tftFile" gesetzt ist, wird die darin angegebene Datei hochgeladen, ansonsten wird versucht, das File „FHEM/firmware/nextion.tft“ hochzuladen.

===Anwendungsbeispiel===
In {{Link2Forum|Topic=63443|LinkText=diesem FHEM Forum Thread}} wurde ein LGW Nextion UI erarbeitet (Stand 01.08.2017 {{Link2Forum|Topic=63443|Message=582453|LinkText=Version 0.7}}), um die Funktionsweise zu demonstrieren.
Das Nextion UI besteht aus folgenden Pages:
{| class="wikitable"
!ID !! Name !! Page !! Beispiel !! Hinweise/Funktion/Bechreibung !! Nextion Debug commands
|-
| 0 ||Boot || Boot || [[Datei:lgw_nextion_boot.png|200px|thumb|left|]]<div style="clear:both;"></div> || Das ist die Startseite nach Einschalten des Nextion Displays. ||
|-
| 1 ||Progress||LGW#prog ||[[Datei:lgw_nextion_prog.png|200px|thumb|left|]]<div style="clear:both;"></div>|| Auf dieser Seite wird der WiFi Verbindungsfortschritt angezeit. Alles Werte werden vom LGW befüllt. ||page LGW#prog
vis LGW#pbar,1

vis LGW#ptext,1

LGW#pbar.val=50

LGW#ptext.txt="Connect WiFi (1)"
|-
| 2 ||Main|| LGW#main || [[Datei:lgw_nextion_main.png|200px|thumb|left|]]<div style="clear:both;"></div> ||Dies ist die Haupseite, welche vom LGW aufgerufen wird, sobald der Bootvorgang abgeschlossen ist.<br>Hinweise zur Funktionsweise findet man {{Link2Forum|Topic=63443|Message=546896|LinkText=hier}}|| page LGW#main
vis LGW#wifi,1

vis LGW#fhem,1

vis LGW#cpu1,1

vis LGW#cpu2,1

LGW#rssi.txt="-68"

tTime.txt="23:45"

tDate.txt="01.08.2017"

vis iTemp,1

LGW#temp.txt="25.7"

vis iHum,1

LGW#hum.txt="68%"

vis iPres,1

LGW#pres.txt="1024hPa"

vis iWind,1

tout_ws.txt="23km/h"

vis iOutT,1

tout_t.txt="28°C"
|-
| 3 ||Info Page|| Info || [[Datei:lgw_nextion_info.png|200px|thumb|left|]]<div style="clear:both;"></div> || Alle Informationen auf dieser Seite werden von LGW automatisch befüllt. || page Info
vis LGW#ip,1

LGW#ip.txt="192.168.222.1"

vis LGW#fpm,1

LGW#fpm.txt="5"

vis LGW#heap,1

LGW#heap.txt="16280"

vis LGW#ver,1

LGW#ver.txt="1.30"

vis LGW#up,1

LGW#up.txt="1Tg.4Std.34Min."
|-
| 4 || Info Page 2 || Info2 || [[Datei:lgw_nextion_info2.png|200px|thumb|left|]]<div style="clear:both;"></div> || tInfo50 und tInf51 sind für Nextion UI Version reserviert. tInfo60 bis tInfo91 sind nicht belegt und können verwendet werden, um z.B. die FHEM Verison anzuzeigen. || page Info2
tInfo60.txt="tInfo60:"

tInfo61.txt="tInfo61"

tInfo70.txt="tInfo70:"

tInfo71.txt="tInfo71"

tInfo80.txt="tInfo80:"

tInfo81.txt="tInfo81"

tInfo90.txt="tInfo90:"

tInfo91.txt="tInfo91"
|-
| 5 || Settings || Settings || [[Datei:Lgw_nextion_Settings.png|200px|thumb|left|]]<div style="clear:both;"></div> || Einstellungsmöglichkeit von Helligkeit (Wertebereich von 10% bis 100%) des Displays und des PowerOff Timeouts (Wertebereich: off und 1-120 Sek.)||page Settings
h1.val=25

h0.val=60
|-
| 6 || Control Center||CoCe||[[Datei:lgw_nextion_CoCe.png|200px|thumb|left|]]<div style="clear:both;"></div> ||Zum Schalten von Aktoren und Status anzeige.<br>Weiteren Hinweise zur Funktionsweise sind {{Link2Forum|Topic=63443|Message=576902|LinkText=hier}} zu finden. || page CoCe
lblT1.txt="lbT1"

lblS1.txt="aus"

lblT2.txt="lbT2"

lblS2.txt="an"

lblT3.txt="lbT4"

lblS3.txt="zu"

lblT4.txt="lbT3"

lblS4.txt="auf"

lblT5.txt="lbT5"

lblS5.txt="n.a."
|-
| 7 || Weather ||Weather||[[Datei:lgw_nextion_Weather.png|200px|thumb|left|]]<div style="clear:both;"></div>||Zur Anzeige einer Wettervorhersage. Diese Seite wird durch ein touch auf den "Temp-Wert" in der Main#Page aufgerufen. <br>Implementierungshinweise sind {{Link2Forum|Topic=63443|Message=582453|LinkText=hier}} zu finden. ||page Weather
p0.pic=12

t0.txt="Mo 01 Aug 2017\rmin:15 max:18"

p1.pic=16

t1.txt="Di 02 Aug 2017\rmin:15 max:18"

p2.pic=17

t2.txt="Mi 03 Aug 2017\rmin:15 max:18"

p3.pic=12

t3.txt="Do 04 Aug 2017\rmin:25 max:28"

p4.pic=15

t4.txt="Fr 05 Aug 2017\rmin:28 max:32"
|}

Hinweis: Alle Contorls die mit dem Namen "LGW#" beginnen sind für das LGW reserviert und werden entsprechend vom Gateway befüllt.

===Nextion Tipps & Tricks===
====Nextion Commandreferenz====
Sehr hilfreich ist die Nextion instruction Page, welche hier: https://www.itead.cc/wiki/Nextion_Instruction_Set zu finden ist.

==Serial Transparent Bridge==
Das LGW kann optional die serielle Schnittstelle des SC16IS750 transparent auf einem TCP Port bereitstellen.
Dazu gibt es die settings ''"Serial bridge port"'' und ''"Serial bridge baud"'' auf der "Setup"-Page" (Web-Frontend) des LaCrosseGateways.
Das LaCrosseGateway überträgt transparent die Daten der seriellen Schnittstelle an FHEM und umgekehrt.
Damit kann z.B. ein NanoCUL an das LaCrosseGateway angeschlossen werden und in FHEM verwenden werden.

'''''Vorgehensweise:'''''
*Einen NanoCUL bauen, z.B. auf Basis eines Arduino Pro Mini, flashen und testweise in Betrieb nehmen.
*Den NanoCUL an die serielle Schnittstelle des SC16IS70 anschließen
*Port und baud rate auf der "Setup"-Page des LaCrosseGateways festlegen, z.B. Port 85 und 38400 baud
*CUL in FHEM definieren (Beispiel):
<syntaxhighlight lang="php">define CULXYZ CUL <IP-Adresse>:85 0000</syntaxhighlight>
'''''<CULXYZ>''''' Muss nach eigenen Bedürfnissen angepasst werden.

'''''<IP-Adresse>''''' Muss entsprechend angepasst werden.

Sollte das CUL-Device nicht erreichbar sein (Restart, Austausch im Falle eines Deffekts etc.), empfiehlt sich einen reconnect Mechnismus in FHEM zu implementieren.

Dieser kann wie folgt aussehen:

<syntaxhighlight lang="php">define CULXYZ-Reconnector at +*00:00:30 {\
my $deviceName = "<CULXYZ>";;\
my $version = CommandGet("", $deviceName . " version");;\
my $gotAnswer = index($version, 'No answer') == -1;;\
\
if(!$gotAnswer) {\
fhem("set " . $deviceName . " reopen");;\
}\
\
} </syntaxhighlight>
'''''<CULXYZ>''''' Muss nach eigenen Bedürfnissen angepasst werden.

'''''Vorgehen Firmware flashen mit LGW'''''

Ein bereits in Betrieb genomene NanoCUL kann nach dem gleichen Vorgehen (siehe [[#SubProzessor|"SubProzessor - Vorgehen Firmware flashen"]]) wie ein SubProzessor geflasht werden.

==Zugriff mit mehreren FHEM Instanzen==

Bis zu drei FHEM Instanzen können auf das LaCrosseGateway gleichzeitig zugreifen.
Auf der "Setup"-Page des LaCrosseGateways können bis zu drei Ports (Data ports), pro Port eine FHEM Instanz, definiert werden (Reboot erforderlich).
Aus Performancegründen empfiehlt sich nur die benötigten Ports zu definieren.

'''''Hinweise:''''' Die Portnummer 8266 wird für OTA Update verwendet, und 80 für die "Config"-page. Aus diesem Grund ist die Verwendung dieser ports nicht erlaubt.

Wenn sich mehrere FHEM Instanzen ein LaCrosseGateway teilen, dann ist darauf zu achten, dass die eine gemeinsame/gleiche initCommand Konfiguration haben. Sollten die FHEM Instanzen unterschiedliche initCommands senden, gewinnt das (zufällig) letzte und legt es für alle anderen fest.

=Nano LaCrosse Gateway=
Das nano LaCrosse Gateway verwendet die gleiche [https://svn.fhem.de/trac/export/HEAD/trunk/fhem/FHEM/firmware/JeeLink_LaCrosseGateway.bin Firmware] wie das WiFi LaCrosse Gateway, der signifikante Unterschied ist die kompakte (portable) Bauform. Aufgrund der Bauform können jeodch nicht alle Bauteile verwendet werden.
Das Gateway eignet sich sehr gut als Entwicklungstick (dies ist der Entstehungsgrund) oder zum Empfangen und Steuern von LaCrosse basierten Sensoren/Aktoren an einem FHEM Server (RPI,Cubietruck, etc.).

Der Betieb über WiFi, entsprechende Stromversorgung (per USB) vorausgesetzt, ist ebenfalls möglich.

Weiterführende Informationen zum nano LaCrosse Gateway und Ideensammlung für eine Platine sind im {{Link2Forum|Topic=51329|LinkText=FHEM Forum}} zu finden.

==Bauteile==
Folgende Bauteile werden benötigt:
*Gehäuse [http://www.elv.de/output/controller.aspx?cid=74&detail=10&detail2=36507 schwarz] oder [http://www.voelkner.de/products/164819/USB-Gehaeuse-USB-1kl-Transparent.html transparent]
*ESP-12E
*Auto-Flash-Reset-Schaltung
*[http://www.aliexpress.com/item/6Pin-USB-2-0-to-TTL-UART-Module-Serial-Converter-CP2102-STC-Replace-Ft232/32364013343.html?spm=2114.13010208.99999999.261.mWmpl5 CP2102 FTDI]
*RFM69CW
*Status-LED

==Schaltung==
[[Datei:lgw_nano_Schaltplan.png|600px|thumb|left|Schaltplan NanoLGW]]
<div style="clear:both;"></div>

==Selbstbau==
{| class="galleryTable noFloat"
|-
| [[Datei:lgw_nano_Selbstbau1.png|320px|thumb|left|Selbstbau nano LaCrosse Gateway 1]]
| [[Datei:lgw_nano_Selbstbau2.png|300px|thumb|left|Selbstbau nano LaCrosse Gateway 2]]
| [[Datei:lgw_nano_Selbstbau3.png|475px|thumb|left|Selbstbau nano LaCrosse Gateway 3]]
|}
==Platine==
===nano LaCrosse Gateway===
{| class="galleryTable noFloat"
|-
|[[Datei:Nanolgw_bestueckt_oberseite.jpg|400px|thumb|left|nano LaCrosse Gateway Platine Oberseite]]
|[[Datei:Nanolgw_bestueckt_unterseite.jpg|400px|thumb|left|nano LaCrosse Gateway Platine Unterseite]]
|}
===USB2TTL===
{| class="galleryTable noFloat"
|-
|[[Datei:Nanolgw_USB2TTL_1.jpg|400px|thumb|left|USB2TTL Platine Oberseite]]
|[[Datei:Nanolgw_USB2TTL_2.jpg|400px|thumb|left|USB2TTL Platine Unterseite]]
|}
===nano LaCrosse Gateway inkl. USB2TTL===
{| class="galleryTable noFloat"
|-
|[[Datei:Nanolgw_oberseite_USB2TTL_1.jpg|400px|thumb|left|nano LaCrosse Gateway inkl. USB2TTL Oberseite]]
|[[Datei:Nanolgw_oberseite_USB2TTL_2.jpg|400px|thumb|left|nano LaCrosse Gateway inkl. USB2TTL Oberseite]]
|}
{| class="galleryTable noFloat"
|-
|[[Datei:Nanolgw_unterseite_USB2TTL.jpg|400px|thumb|left|nano LaCrosse Gateway inkl. USB2TTL Unterseite]]
|[[Datei:Nanolgw_seitenansicht_USB2TTL.jpg|400px|thumb|left|nano LaCrosse Gateway inkl. USB2TTL Seitenansicht]]
|}
===nano LaCrosse Gateway fertig bestückt inkl. Gehäuse===
{| class="galleryTable noFloat"
|-
|[[Datei:Nanolgw_USB2TTL_fertig_oberseite.jpg|400px|thumb|left|nano LGW fertig bestückt inkl. Gehäuse Oberseite]]
|[[Datei:nanolgw_USB2TTL_fertig_unterseite.jpg|400px|thumb|left|nano LGW fertig bestückt inkl. Gehäuse Unterseite]]
|}
===Platine bestücken (Hinweise und Tipps)===
*Die Beschriftung SJ4 und SJ3 ist auf dem USB2TTL Wandler vertauscht, dies beeinträchtigt aber die Funktion nicht.
*Beim nanoLGW hängt C1 etwas über dem FTDI232RL vom USB2TTL Wandler, daher braucht diese Platine noch eine "Schönheitskorrektur".

= Tipps & Tricks =

==Löschen des kompletten Flash des ESP8266 mit dem esptool==
Aufgrund eines aktuell im espressif SDK vorhandenen Bugs, kann es passieren, dass das LaCrosseGateway nach dem Aufspielen der Firmware, mit einer Exception den Bootvorgang (nach "Start WIFI_STA") abbricht und nicht mehr ordnungsgemäß starten kann. In diesem Fall hilft nur noch das Löschen des kompletten Speichers des ESP8266 und das erneute Aufspielen der Firmware.

Mit dem nachfolgenden Befehl kann der Speicher des ESP8266 komplett gelöscht werden.

'''''Achtung:''' Dabei werden alle Einstellungen unwiderruflich gelöscht''
<syntaxhighlight lang="php">./esptool -vv -cp /dev/tty.SLAB_USBtoUART -cb 115200 -ca 0x00000 -cd nodemcu -ce</syntaxhighlight>

'''''</dev/tty.SLAB_USBtoUART>''' Muss entsprechend angepasst werden.''

=Weiterführende Links=
Diskussionsthread aus dem Forum:

{{Link2Forum|Topic=43672|LinkText=LaCrosseGateway - LaCrosse, PCA301 und EC3000 über wifi mit ESP8266 ohne Arduino}}

{{Link2Forum|Topic=45594|LinkText=Platine für LaCrosseGateway: Platinenbestellung}}

{{Link2Forum|Topic=51329|LinkText=Platine für nanoLGW (LaCrosse Gateway): Layout}}

{{Link2Forum|Topic=52921|LinkText=Display für LaCrosseGateway}}

{{Link2Forum|Topic=63443|LinkText=LaCrosseGateway mit Nextion Display}}

[[Kategorie:Interfaces]]
[[Kategorie:IP Components]]
[[Kategorie:Other Components]]
[[Kategorie:Temperatursensoren]]
[[Kategorie:Feuchtesensoren]]
[[Kategorie:Wetterstationen]]
[[Kategorie:868MHz]]

LaCrosseGateway V1.x

2018-06-19T20:22:20Z

Markus1407:

Diese Wiki-Seite beschreibt ausschließlich das LaCrosseGateway V1.x, das auf dem ESP8266 basiert.<br/>
Für das LaCrosseGateway32 das auf dem ESP32 basiert, wird es eine eigene Seite geben.{{Randnotiz|RNText=Dokumentationsstand Version 1.27}}

Das LaCrosseGateway (hier und im Forum auch mit LGW abgekürzt) erfüllt den gleichen Zweck wie ein [[JeeLink|JeeLink USB-Stick]] und zwar das Empfangen, Abfragen und Steuern von funkbasierten LaCrosse Sensoren und Aktoren, die im 868 MHz FSK Sendeverfahren arbeiten (OOK-Sendeverfahren (433 Mhz) wird nicht unterstützt). Die Verarbeitung der Daten und Steuerung der Aktoren erfolgt mithilfe von FHEM, das als zentrale Steuereinheit dient.
Der signifikante Unterschied zu einem JeeLink USB-Stick ist der Betrieb über Wireless LAN ([https://de.wikipedia.org/wiki/Wi-Fi WiFi]).
Das Herzstück des LaCrosse-Gateways besteht aus einem ESP8266-12E/F. Das LaCrosseGateway ist aufgrund des hohen Stromverbrauchs nicht für den Akkubetrieb geeignet.

Der Einsatz eines WiFi-LaCrosse-Gateways bietet folgende Vorteile:
*Kann an eine Stelle platziert werden, an der alle Sensoren optimal empfangen werden, dafür ist nur Strom (5V/1A USB Netzteil) und [https://de.wikipedia.org/wiki/Wi-Fi WiFi] Access Point erforderlich
*Im Minimalausbau nur zwei Bauteile NodeMCU DEVKIT 1.0 + RFM69 (siehe Bauteile) nötig
*Alternativ am USB-Port wie ein JeeLink verwendbar
*Einsatz von on board Sensoren / Aktoren (siehe [[#Unterstützte Sensoren und Aktoren | Unterstützte Sensoren und Aktoren]]) möglich

Hinweis: Die Anbindung in FHEM kann zwar noch mit dem JeeLink-Modul erfolgen, aber es ist sinnvoll, auf das LaCrosseGateway-Modul (36_LaCrosseGateway.pm) umzustellen, da dieses eine bessere Unterstützung für die Funktionen des LGW bietet.

=Hardware=
==Bauteile==
Für das WiFi-LaCrosse-Gateway werden folgende Bauteile verwendet:
*[Option 1] [http://www.esp8266.com/wiki/doku.php?id=esp8266-module-family#esp-12-e_q ESP8266 ESP-12E Modul].<br />Diese Variante eignet sich für Projekte für die eine kleine Bauform benötigt wird.<br />Für die Inbetriebnahme, insbesondere für das Aufbringen der Firmware, muss das Modul an ein [[Medium:Lgw USB2Serial Adapter.jpg|USB2Serial-Adapter]], angeschlossen werden. Für diese Variante sind Lötkenntnisse erforderlich.
*[Option 2] [https://raw.githubusercontent.com/nodemcu/nodemcu-devkit-v1.0/master/Documents/NodeMCU_DEVKIT_1.0.jpg NodeMCU DEVKIT 1.0 (oder 2.0)]ist die Inbetriebnahme einfacher, da alles für das Aufbringen der Firmware bereits vorhanden ist und kein Löten nötig ist.<br />{{Link2Forum|Topic=45594|Message=430183|LinkText=Hinweis:}} Folgende Devkits werden nicht "offiziel" unterstützt, da ungetestet, können aber durchaus in bestimmten Fällen verwendet werden:
** V0.9 (da ungetestet, bekommt man aber kaum noch zu kaufen)
** V3.0 - passt nicht auf die Platine von PeMue, ist größer als das 2.0. Auf der Rückseite steht "Lolin".
** Devkits mit einem CH340 USB converter (da ungetestet und teils falsche Bauform und von der USB-Anbindung her teils problematisch)
*[Option 3] Alternativ zu einem Devkit 1.0 kann auch ein [http://www.wemos.cc/Products/d1_mini.html "WeMOS D1 mini"] eingesetzt werden. Vorteil bei diesem Kit ist die kleine Bauform bei gleichem Funktionsumfang wie das DEVKIT 1.0.
*[Option 4] ESP8266-07 auf einem DEVKIT 1.0. für den Betrieb mit einer externen Wifi Antenne.
**''Hinweis:'' Der ESP-07 hat einen 25Q80 1M flash Chip. Dieser ist für den Betrieb mit der LaCrosseGateway Firmware geeignet, für ein OTA-Update ist es jedoch zu wenig. Aus diesem Grund muss/kann dieser auf 4M flash umgebaut werden. Weitere Informationen und Details zum Umbau sind im {{Link2Forum|Topic=45594|Message=448307|LinkText=Forenthread (Gehäuse-Variante)}} beschrieben.
*[Optional] RFM69CW - Für das Senden und Emfangen funkbasierte LaCrosse Aktoren und Sensoren
*[Optional] On board Sensoren (siehe [[#Unterstützte Sensoren und Aktoren | Unterstützte Sensoren und Aktoren]])
*[Optional] SC16IS750 Zur Bereitstellung der seriellen Schnittstelle, da die GPIOs (GPIO1 / GPIO3) DEVKIT's V1.0 von FTDI verwendet werden und damit nicht genutzt werden können.
*[Optional] OLED-Display SSD1306 I2C zur Darstellung von Daten (Bootvorgang, on board Sensoren, Inhalte aus FHEM)
*[Optional] [[#MCP23008|MCP23008]] zur Bereitstellung (Konfigurierbar) von digitalen 8 Ein- Ausgängen oder Sonderfunktion (OLED)
*[Optional] Nextion Touch Display zur Darstellung von verschiedenen Informationen oder zum Schalten von Aktoren.
*Steckbrett (inkl. Kabel/Widerstände)/Lochrasterplatine (Lötkolben, Lötzinn, Widerstände etc.)) / [[#Platine|PeMue Platine]]

==Schaltung==
===Variante: Devkit 1.0 Minimum===
[[Datei:lgw_Schaltplan_Devkit_minimum.png|400px|thumb|left|Variante: Devkit 1.0]]
<div style="clear:both;"></div>
===Variante: Devkit 1.0 Maximalausbau===
[[Datei:lgw_Schaltplan_Devkit_full.png|400px|thumb|left|Variante: FTDI]]
<div style="clear:both;"></div>
===Variante: Platine (PeMue)===
siehe hier: {{Link2Forum|Topic=45594|LinkText=Thread}}
<div style="clear:both;"></div>
Siehe [[#Erweiterungsmöglichkeiten | Erweiterungsmöglichkeiten]].

===MCP23008===
I2C Adresse 0x27 -> A0,A1,A2 = 3.3V
<syntaxhighlight lang="php">
|-------\/-------|
LGW D1 |1 SCL VDD 18| LGW 3.3V
LGW D2 |2 SDA GP7 17| PB7 --/ --- GND or Output
LGW 3.3V |3 A2 GP6 16| PB6 --/ --- GND or Output
LGW 3.3V |4 A1 GP5 15| PB5 --/ --- GND or Output
LGW 3.3V |5 A0 GP4 14| PB4 --/ --- GND or Output
LGW 3.3V |6 RES GP3 13| PB3 --/ --- GND or Output
|7 NC GP2 12| PB2 --/ --- GND or Output
|8 INT GP1 11| PB1 --/ --- GND or Output
LGW GND |9 VSS GP0 10| PB0 --/ --- GND or Output
|----------------|</syntaxhighlight>

===Nextion Display===
Angeschlossen wird das Display wie folgt:
GPIO0: TXD -> Nextion RXD
GPIO2: RXD -> Nextion TXD

Das Display benötigt eine 5V Spannungsversorgung, diese kann vom VIN des DevKit's abgegriffen werden. Vom Betrieb mit 3.3V wird abgeraten.
Ein level shifter für RXD/TXD ist nicht nötig.

==Aufbau auf einem Steckbrett==
[[Datei:lgw_Steckbrett.png|600px|thumb|left|LaCrosseGateway Aufbau auf einem Steckbrett]]
<div style="clear:both;"></div>
'''''Hinweis:''' Der Sender und Empfänger RFM12, der auf dem Steckbrett zu sehen ist, wird nicht mehr unterstützt.''

==Platine==
PeMue (vielen Dank) hat {{Link2Forum|Topic=45594|LinkText=hier}} eine Platine (7,1cm x 5,0cm) für das LaCrosseGateway entworfen (Stand 05.2016).

===Oberseite===
[[Datei:lgw_Platine_Oberseite.jpg|400px|thumb|left|LaCrosseGateway Platine Oberseite]]
<div style="clear:both;"></div>

===Unterseite===
[[Datei:lgw_Platine_Unterseite.jpg|400px|thumb|left|LaCrosseGateway Platine Unterseite]]
<div style="clear:both;"></div>

===Devkit 1.0 bestückt Oberseite===
[[Datei:Lgw_Platine_Devkit_oberseite.png|400px|thumb|left|LaCrosseGateway Platine Oberseite]]
<div style="clear:both;"></div>

===Devkit 1.0 bestückt Unterseite===
[[Datei:lgw_Platine_Devkit_unterseite.png|400px|thumb|left|LaCrosseGateway Platine Unterseite]]
<div style="clear:both;"></div>

===ESP8266-12E bestückt Oberseite===
{| class="galleryTable noFloat"
|-
| [[Datei:lgw_Platine_ESP-12E_oberseite.png|400px|thumb|left|(1) LaCrosseGateway Platine Oberseite mit 2 x RFM69CW, BME280 und DHT22]]
| [[Datei:lgw_Platine_ESP-12E_oberseite_2.jpg|490px|thumb|left|(2) LaCrosseGateway Platine Oberseite mit 2 x RFM69CW, BME280]]
| [[Datei:lgw_Platine_ESP-12E_oberseite_2_inkl_GE.jpg.jpg|325px|thumb|left|(2) LaCrosseGateway Platine Oberseite mit 2 x RFM69CW, BME280 inkl. Gehäuse]]
|}
'''''Hinweis:''' Die Platine (Bild (1)) ist mit einem LM75 Sensor bestückt. Diese Bestückung macht zusammen mit einem BME280 keinen Sinn, es handelt sich hierbei um eine Entwicklungsplatine.''

===ESP8266-12E bestückt Unterseite===
{| class="galleryTable noFloat"
|-
| [[Datei:lgw_Platine_ESP-12E_unterseite.png|400px|thumb|left|(1) LaCrosseGateway Platine Unterseite]]
| [[Datei:lgw_Platine_ESP-12E_unterseite_2.jpg|415px|thumb|left|(2) LaCrosseGateway Platine Unterseite mit 2 x RFM69CW, BME280]]
|}

===Platine bestücken (Hinweise und Tipps)===
*Auf der Platine (Version 1.0) ist für das RFM69CW-Modul eine Markierung (zwei Quadrate) aufgedruckt, die den Chip und den Quarz symbolisieren. Wenn man den RFM69CW so drauflötet, wie abgebildet, ist er falsch rum drauf.<br />Es muss darauf geachtet werden, wo auf dem RFM69CW die "Ant" Beschriftung steht, dieser Lötpunkt muss auf die Platine an den Punkt "1" ausgerichtet werden. Zur Sicherheit bitte den [[#Variante: Platine (PeMue)|Schaltplan]] konsultieren und die genaue Position ermitteln.<br>'''Für die Platine V1.1 wurde das korrigiert.'''
*Die Antennenlänge für das RFM69CW beträgt 82 mm. Dafür möglichst eindrähtigen Leiter (aus Kupfer) verwenden.

==Erweiterungsmöglichkeiten==
Das LaCrosseGateway kann optional mit verschiedenen Komponenten erweitert werden.

Folgende Erweiterungen sind möglich:
*es kann ein eigener Prozessor (mit eigener Firmware) angeschlossen werden, der Daten empfängt und diese dem LGW übergibt.
*es kann z.B. ein NanoCUL angeschlossen werden, dessen serielle Schnittstelle transparent auf einem Port im Web bereitgestellt wird.
*es kann ein vierter und fünfter RFM69CW angeschlossen werden, diese können alles, was die bisherigen drei auch können.
*es kann ein aktiver Piezo Summer (Piezo Buzzer) angeschlossen (an GPIO7 des SC16IS750) werden, um von FHEM aus das LaCrosseGateway einen Alarm ausgeben zu lassen. Hinweis: Falls der Strom von 10mA, den die Ausgänge liefern, nicht reicht, ist noch eine Transistor-Schaltstufe vorzusehen.

Alle diese Daten stellt das LaCrosseGateway per WiFi an FHEM zu, dort wird es von den entsprechenden Modulen (LaCrosseGateway, LaCrosse, PCA301, ...) weiterverarbeitet.

Alle Komponenten werden automatisch erkannt, sofern angeschlossen.
Für die Realisierung der o.g Möglichkeiten wird ein [http://www.aliexpress.com/item/1x-Breakout-Board-for-SC16IS750-I2C-SPI-to-UART-IC/1327351219.html?spm=2114.30010308.3.38.HxdznQ&ws_ab_test=searchweb201556_9,searchweb201602_2_10034_507_10020_10001_10002_10017_10010_10005_10011_10006_10021_10003_10004_10022_10009_10008_10018_10019,searchweb201603_6&btsid=97b30f2b-e937-426b-8202-de585dd7ee97 SC16IS750] verwendet.

Der SC16IS750 wird per I2C an das LaCrosseGateway angeschlossen und bietet eine serielle Schnittstelle und 8 Digital I/Os

'''Auf dieser Basis sind momentan folgende Erweiterungen möglich:'''

===SubProzessor===
Der SubProzessor dient dazu, dass mit einem eigenen Sketch Daten erfasst werden können, ohne sich um die ganze Nummer, die das LGW macht (WiFi, Kommunikation mit FHEM, Frontend, OTA, ...), kümmern zu müssen.
Ferner ermöglicht es die Implementierung von eigenen Projekten, dabei werden die zeitkritischen Abläufe des LGWs nicht beeinträchtig.

An die serielle Schnittstelle des SC16IS750 kann optional ein Arduino angeschlossen werden (z.B. ein Pro Mini)
Entweder ein 3.3V / 8MHz oder ein 5V / 16MHz, der aber dann auch mit 3.3V betrieben wird.

'''''Wichtig:''' Alle LaCrosseGateway Komponenten laufen ausschließlich mit '''3.3V''', aus diesem Grund dürfen keine '''5V''' Komponenten angeschlossen werden.''

'''Firmware flashen'''

Die Firmware kann über das LGW auf den SubProzessor (Voraussetzung: Arduino hat einen bootloader) geflasht werden.

Dazu wird sie auf das LGW hochgeladen (<nowiki>http://<LGW-IP>/ota/addon.hex</nowiki>).

Das LGW nimmt den Upload entgegen, wandelt das Intel-Hex in binary um und schickt es per STK500-Protokoll an den Arduino.

Falls ein OLED angeschlossen ist, wird sogar ein progress angezeigt.

'''Vorgehen Firmware flashen'''

Die Firmware kann z.B. mithilfe von "curl" mit dem nachfolgendem Befehl hochgeladen werden:
<syntaxhighlight lang="php">curl --http1.0 -H "Content_Type:multipart/form-data" -F "file=@/myFolder/LGW-Addon.ino.hex; filename=addon.hex" http://192.168.31.211/ota/addon.hex</syntaxhighlight>

'''''Hinweis:''' fielname=addon.hex im Beispiel darf nicht verändert werden, nur /myFolder/LGW-Addon.ino.hex und die IP-Adresse wird entsprechend angepasst.''

Der Upload dauert etwas, danach sollte bei Erfolg vom LGW ein Protokoll zurückgeschickt bekommen, der wie folgt aussieht:
<syntaxhighlight lang="php">Start receiving 'addon.hex'
File: /addon.hex Size: 21417
Starting flash
Sending sync
Enter program mode
Binary size is:7608
Leave Program Mode
Flash finished</syntaxhighlight>

Mit dem SubProzessor können die entsprechenden Daten auf zwei mögliche Arten am LGW übermittelt werden:

'''KeyValueProtokoll (KVP):'''
Format:<syntaxhighlight lang="php">KV <Type> <Address> <Key>=<Value>,<Key>=<Value>,<Key>=<Value>, ...</syntaxhighlight>
Beispiel:<syntaxhighlight lang="php">KV DHT 01 Temperature=21.5,Humidity=62</syntaxhighlight>

Das LGW übermittelt die Daten als KVP an FHEM und dort entsteht ein KVP Device, das die Daten darstellt.

'''LaCrosse:'''

Format:<syntaxhighlight lang="php">LC <Address> T=<Temperature>,H=<Humidity></syntaxhighlight>
Beispiel:
<syntaxhighlight lang="php">LC 9F T=21.5,H=62</syntaxhighlight>
<syntaxhighlight lang="php">LC 9F T=21.5</syntaxhighlight>
Das LGW setzt die Werte in das LaCrosse Protokoll um (wie z.B. ein TX29DTH) und schickt sie an FHEM.
In FHEM entsteht ein LaCrosse Device (autocreate, LaCrossePairForSec ...), als ob es ein LaCrosse Sensor wäre.

Das [https://forum.fhem.de/index.php?action=dlattach;topic=43672.0;attach=48914 LGW-Addon.ino] ist ein einfaches Beispiel, das diese Technik veranschaulicht.
Es bindet den geliebten DHT22 an und sendet ihn als LaCrosse-Sensor (über das LGW) an FHEM und es misst die Spannung und sendet sie zusammen mit der UpTime des SubProzessors als KVP

Der umrandete Bereich [[#Addon Schaltung |Schaltung - "Example"]] "Example" ist das zu [https://forum.fhem.de/index.php?action=dlattach;topic=43672.0;attach=48914 LGW-Addon.ino] passende Beispiel.

==Unterstützte Sensoren und Aktoren==
Alle Sensoren und Aktoren, die auch vom "LaCrosse Arduino" Sketch unterstützt werden.<br />
(siehe [[JeeLink#Unterst.C3.BCtzte_Sensoren_und_Aktoren_incl._Wetterstation_WS_1600JeeLink|vom JeeLink unterstützte LaCrosse Sensoren und Aktoren]])

Zusätzlich zu LaCrosse werden auch die folgenden Geräte unterstützt:
{| class="wikitable"
!Bezeichnung !! Datenrate !! Sonstiges !! Funktion !! Hinweise
|-
| PCA301 ||868950 kHz (868,970 und 868,990 ) 6.631 kbps || extern || Energiemess-Steckdose (Unterstützt werden bis zu 50 Dosen) ||
|-
| EC3000 ||868.300 kHz mit 20.000 kbps|| extern || Energiemess-Steckdose (funktioniert nur mit RFM69, nicht mit RFM12) ||
|-
| RFM69CW || || on board || Zum Empfangen und Senden von Sensor/Aktor Daten.|| Hinweise DHT22 beachten.
|-
| BME280 || || on board || Temperatur, Feuchte und Druck || Falls das verwendete Breakout bereits PullUp-Widerstände für SDA und SCL enthält, sind diese nicht mehr zusätzlich nötig.
|-
| BMP180 || || on board || Temperatur und Druck || Falls das verwendete Breakout bereits PullUp-Widerstände für SDA und SCL enthält, sind diese nicht mehr zusätzlich nötig.
|-
| LM75 || || on board|| Temperatur ||
|-
| DHT22 || ||on board|| Temperatur und Feuchte. || Kann anstatt RFM69 Radio#3 eingesetzt werden.
|-
| SC16IS750 || I2C Adresse: 0x90 ||on board|| OI Erweiterung ||
|-
| OLED SSD1306|| I2C Adresse: 0x3C || on board || OLED Display||
|-
| MCP23008|| I2C Adresse: 0x27 || on board || Input/Output Port Expander||
|-
| Piezo Summer |||| on board ||Piezo Buzzer||
|-
| Nextion Display ||(Max.) 57600 baud || on board ||Touch Display||

|}

Alle direkt am LGW anschließbare Sensoren werden automatisch erkannt, wenn sie vorhanden sind.

<u>Sie werden in folgender Reihenfolge verwendet:</u>

Wenn ein BME280 vorhanden ist, wird dieser verwendet und sonst nichts, da man dann bereits Temperatur, Feuchte und Druck hat.

Ist kein BME280 vorhanden, wird geschaut, ob ein BMP180 vorhanden ist. Falls ja, haben wir Druck und Temperatur.

Dann wird geschaut, ob ein DHT22 vorhanden ist. Wenn ja, wird er zusätzlich verwendet, aber vom BMP180 dann nur noch der Druck.

Temperatur und Feuchte vom DHT22, dass dieses Wertepaar von einem Sensor stammt.

Wenn kein BMP180 und kein BME180 da ist, sondern nur ein DHT22, dann hat man Temperatur und Feuchte.

Wenn nichts vorhanden ist (also keiner der bisher genannten Sensoren), wird, falls vorhanden, der LM75 verwendet.

=Software=
==Funktionsumfang==
*Access Point für die Konfiguration
*Konfiguration über WEB-Frontend (Erreichbar per ''<nowiki>http://IP-Adresse oder Hostname/setup</nowiki>'' auf Port 80 )
**SSID und Password (Die Konfiguration wird im EEPROM gespeichert und bei zukünftigen Neustarts verwendet.)
**Statische IP-Adresse anstatt DHCP
**Hostname
*Vom LaCrosseGateway FHEM-Modul über IP-Adresse:Port oder Hostname:Port ansprechbar. Der Port ist konfigurierbar.
*Unterstützt bis zu 5 x RFM69CW (Keine Unterstützung für RFM12)
*On board und externe Sensoren und Aktoren ([[#Unterstützte Sensoren und Aktoren |Unterstützte Sensoren und Aktoren]])
*Betrieb nur per USB möglich, als ob es ein JeeLink wäre
*FHEM Anbindung
*Log im Web-Frontend
*Firmware OTA-Update (Firmware-Over-the-Air-Update per FHEM)
*Erweiterungsmöglichkeiten per SC16IS750 (Für Buzzer und für weitere zwei RFM69)
*SubProzessor (An die serielle Schnittstelle des SC16IS750 kann optional ein Arduino angeschlossen werden (z.B. ein Pro Mini))
*Serial bridge (Optional kann die serielle Schnittstelle des SC16IS750 transparent auf einem TCP Port bereitgestellt werden)
*Software Serial Bridge - Stellt die Soft Serial Schnittstelle transparent auf einem TCP Port.

==Sourcecode==
Der Quellcode des LaCrosse Gateways befindet sich [https://svn.fhem.de/trac/export/HEAD/trunk/fhem/contrib/arduino/36_LaCrosseGateway.zip im FHEM SVN Repository (contrib)].

==Firmware Download==
Die [https://svn.fhem.de/trac/export/HEAD/trunk/fhem/FHEM/firmware/JeeLink_LaCrosseGateway.bin Firmware] befindet sich im [https://svn.fhem.de/trac/browser/trunk/fhem FHEM SVN Repository] und wird per FHEM Update verteilt. Neue Version der [https://svn.fhem.de/trac/export/HEAD/trunk/fhem/FHEM/firmware/JeeLink_LaCrosseGateway.bin Firmware] wird im {{Link2Forum|Topic=43672|LinkText=FHEM Forum "LaCrosse Gateway"}} angekündigt und der Funktionsumfang bzw. die Änderungen beschrieben.

Nach einem FEHM-Update alternativ auch: ''<FHEM-Installations-Verzeichnis>/FHEM/firmware/JeeLink_LaCrosseGateway.bin''

==Firmware aufspielen==
Wie bei einem JeeLink muss auch für das LaCrosseGateway die Firmware aufgespielt werden.

Das [https://raw.githubusercontent.com/nodemcu/nodemcu-devkit-v1.0/master/Documents/NodeMCU_DEVKIT_1.0.jpg NodeMCU DEVKIT 1.0] hat eine CP2102 UART Bridge implementiert, dafür muss ein CP2102 Treiber installiert sein.

Bei einem ESP8266-12E Modul kann die Firmware mithilfe eines Seriell-USB-Konverters aufgespielt werden.

===Windows/Mac/Linux per "esptool"===
Verifiziert und getestet wurde dieses Vorgehen auf Windows (Windows 10), Mac (El Capitan):

1) Das [https://github.com/igrr/esptool-ck/releases esptool 0.4.6] für die entsprechende Plattform herunterladen.

2) Zum Aufspielen der Firmware, muss ein Befehl nach der folgenden Syntax ausgeführt werden:
<syntaxhighlight lang="php">
esptool -vv -cp [Port] -cb 921600 -ca 0x00000 -cd nodemcu -cf [Pfad zur Firmware (bin-File)]</syntaxhighlight>
'''[Port]''' und '''[Pfad zur Firmware (bin-File)]''' müssen angepasst werden.

''Beispiel (Mac/Linux):''

<syntaxhighlight lang="php">esptool -vv -cp /dev/tty.SLAB_USBtoUART -cb 921600 -ca 0x00000 -cd nodemcu -cf JeeLink_LaCrosseGateway.bin</syntaxhighlight>

'''''Hinweis:''' Das esptool ist nicht sonderlich stabil. Es kommt vor, dass es manchmal den upload nicht startet oder nicht durchbekommt. In diesem Fall hilft es den Vorgang, auch mehrmals, zu wiederholen.''

=== Linux/Debian/Ubuntu "esptool v2.1"===

Installieren:
<syntaxhighlight lang="bash">
sudo apt-get esptool
</syntaxhighlight>

''Beispiel mit neuer Syntax bei esptool v2.1:''
<syntaxhighlight lang="bash"> sudo esptool --port /dev/ttyUSB0 write_flash 0x00000 JeeLink_LaCrosseGateway.bin</syntaxhighlight>

===Windows per "nodemcu-flasher"===

1) [https://github.com/nodemcu/nodemcu-flasher/raw/master/Win32/Release/ESP8266Flasher.exe Espressif Flashtool] downloaden und entpacken:

2) [https://svn.fhem.de/trac/export/HEAD/trunk/fhem/FHEM/firmware/JeeLink_LaCrosseGateway.bin Firmware] downloaden

3) FlashTool starten und wie folgt einstellen:

{| class="galleryTable noFloat"
|-
| [[Datei:nodemcu-flasher_1.png|450px|thumb|left|Firmware auswählen]]
| [[Datei:nodemcu-flasher_2.png|450px|thumb|left|Flash Parameter (Advanced Tab) wie abgebildet einstellen]]
|}

4) COM-Port auswählen und den Flashvorgang starten (Button: '''Flash(F)''') ...
[[Datei:nodemcu-flasher_3.png|450px|thumb|left|COM Port auswählen und das "Flashen" initiieren]]
<div style="clear:both;"></div>

Nach dem Flashen sollte über die serielle Ausgabe des ESP der Start und das Öffen des AccessPoints zu sehen sein.

'''''Hinweis:''' Die Geschwindigkeit von 921600 baud ist nicht auf jedem Rechner (besonders auf virtualisierten Systemen) machbar. In diesem Fall die Baudrate auf 57600 reduzieren.''

==Funktionsweise==
Während des Startvorgangs versucht sich das LaCrosseGateway in einem WLAN anzumelden. Dazu muss es eine SSID und das entsprechende Passwort kennen.

Beim ersten Start (nach dem initialen Aufspielen der Firmware) sind diese Informationen noch unbekannt. Aus diesem Grund wird folgende Strategie verfolgt:

Wenn es sich in keinem WLAN anmelden kann, dann öffnet es einen Access Point mit der SSID "LaCrosseGateway_'''xxxxxx'''", wobei '''xxxxxx''' die eindeutige Chip-ID des ESP8266 ist.

Der Access Point wird aus Sicherheitsgründen nach 15 Minuten wieder geschlossen.
Innerhalb dieser 15 Minuten kann man sich mit dem Access Point verbinden. Der Access Point vergibt (per DHCP) IP-Adressen aus dem Netzwerk 192.168.222.0. Anschließend kann über die LaCrosseGateway Konfigurationsseite [http://192.168.222.1/setup http://192.168.222.1/setup] die initiale Konfiguration vorgenommen werden.
Die Konfiguration wird im EEPROM gespeichert und bei zukünftigen Neustarts verwendet.
Die Konfigurationsseite ist auch im "Normalbetrieb" (ohne Access Point) über die Adresse http://''seine aktuelle IP-Adresse''/setup erreichbar.

Wenn sich das LaCrosseGateway an dem konfigurierten WLAN anmelden konnte (es wartet max. 30 Sekunden auf einen connect) und von diesem per DHCP eine IP-Adresse erhalten hat, dann stellt es auf dieser Adresse den Port 81 zur Verfügung, über den in FHEM das LaCrosseGateway Modul senden und empfangen kann.

'''Optische Darstellung der Initialisierung'''

Beim Start und der Initialisierung wird mit der Board-eigenen LED signalisieren, was gerade passiert:
*5 schnelle blinks direkt nach dem Start, als Zeichen, dass ein Reset stattgefunden hat
*Blinken im Sekundentakt, während versucht wird, sich mit einem WLAN zu verbinden.
*LED aus, wenn der Connect zu einem WLAN geklappt hat und dann vereinzeltes Blinken, wenn Daten an FHEM übermittelt werden

== LaCrosseGateway einrichten ==
Für die Ersteinrichtung des LaCrosseGateways werden die SSID und das Passwort des WLAN-Routers benötigt. Ferner wird empfohlen auf dem WLAN-Router bzw. dem DHCP-Server eine IP-Adresse für das LaCrosseGateway zu reservieren. Für die Reservierung wird die MAC-Adresse des LaCrosseGateways benötigt, diese kann über die "Home"-Page des LaCrosseGateways ermittelt, alternativ von dem [[#Windows per "nodemcu-flasher" |NODEMCU Firmware Programmer]] (''Reiter "Operation -> "STA MAC"'') entnommen werden.

Sofern diese Vorbereitungen getroffen wurden und alle Informationen vorliegen, kann das LaCrosseGateway eingerichtet werden.

'''''<u>Für die Konfiguration sind folgende Schritte nötig:</u>'''''
*Mit dem LaCrosseGateway Access Point "LaCrosseGateway_xxxxxx" verbinden (siehe [[#Funktionsweise |Beschreibung Funktionsweise]])
*Mithilfe eines Browsers die [http://192.168.222.1/setup LaCrosseGateway "Setup"-Page] öffnen
*SSID und das Password eintragen. Man kann zwei SSID/Passwort-Kombinationen mit jeweils einem Timeout konfigurieren. 120 bedeutet z.B. dass das LGW 120 Sekunden lang versucht, die SSID zu erreichen. Falls die erste SSID nach "Timeout" Sekunden nicht erreicht wurde, wird Timeout Sekunden lang versucht, die zweite SSID zu connecten.
*''[Empfohlen]'' Das Frontend Passwort festlegen
*''[Optional]'' Falls kein DHCP-Server zur Verfügung steht bzw. keine Reservierung erwünscht ist, dann muss die IP-Adresse / Netmask (Optional auch Gateway) eingetragen werden
*''[Empfohlen]'' Hostnamen festlegen bzw. anpassen
*Alle Angaben mit dem Button "save and restart" bestätigen. Dabei werden die vorgenommen Einstellungen im EEPROM gespeichert und ein Neustart des LaCrosseGateways initiiert.

Nach dem Neustart verbindet sich das LaCrosseGateway mit dem WLAN-Router.

Anschließend kann mit der [[#Hinweise zum Betrieb mit FHEM |Inbetriebnahme in FHEM]] fortgefahren werden.

==Firmware aktualisieren==

Nachfolgend werden, neben der unter dem Punkt [[#Firmware aufspielen |Firmware aufspielen]] beschriebenen Möglichkeiten, weitere Möglichkeiten zur Aktualisierung der LaCrosseGateway [[LaCrosseGateway#Firmware Download|Firmware]] aufgezeigt.

Hinweis: Die Einstellungen des LaCrosseGateway werden dabei nicht gelöscht.

=== Per FHEM (OTA-Update)===
Voraussetzungen:

*Das LGW muss auf der IP-Adresse, die im LaCrosseGateway Modul definiert ist, erreichbar sein
*Es wird kein avrdude benötigt
*Das Attribut "flashCommand" spielt keine Rolle

Die LaCrosseGateway Firmware kann von LaCrosseGateway Device (LaCrosseGateway Modul) aus mit
<syntaxhighlight lang="php">set myLaCrosseGateway flash</syntaxhighlight> aktualisiert werden.
'''''myLaCrosseGateway''' muss bei Bedarf auf den Gerätenamen in FHEM angepasst werden.''

'''''Hinweis:''' Das Update dauert ca. 30 Sekunden.''

=== Per FHEM (USB)===
Voraussetzungen:
Auf dem FHEM-Server muss Python und pyserial installiert sein. Die Installation kann z.B. so erfolgen:
*apt-get install python
*wget https://bootstrap.pypa.io/get-pip.py
*python get-pip.py
*pip install pyserial

Das Attribut "mode" muss auf USB gesetzt sein: attr myLaCrosseGateway mode USB

Der flash-Vorgang wird gestartet mit: set myLaCrosseGateway flash

=== Per CURL ===
Voraussetzungen:
*[https://curl.haxx.se/download.html curl-Tool] installiert

'''''Beispiel:'''''
<syntaxhighlight lang="php">curl --http1.0 -# -o ~output.txt -H "Content_Type:multipart/form-data" -F "file=@.\JeeLink_LaCrosseGateway.bin; filename=firmware.bin" http://192.168.31.211/ota/firmware.bin</syntaxhighlight>

'''Firmwaredateiname (file=)''' und die '''IP-Adresse''' muss entsprechend angepasst werden.

=== Per WEB OTA-Update (deprecated)===

'''''deprecated'''''

==LaCrosseGateway Web-Frontend==
===Staus-Wert RSSI===
Die WiFi Signalstärke (dBm) (-36 ist besser als -60)

===Staus-Wert FramesPerMinute===
Dieser gibt an, wie viele frames von Sensoren in der letzten Minute erfolgreich empfangen, dekodiert und verarbeitet wurden.
Es eignet sich zur Überwachung, wenn weniger als ein Grenzwert empfangen wurde, dann kann ein Alarm (Benachrichtigung, Restart etc.) ausgelöst werden.

===Staus-Wert ReceivedFrames===
Dieser Wert gibt an, wie viele seit dem Start des LGW empfangen wurden.

===WiFi "Startup-delay"===

Mit diesen Konfigurationsprameter kann eine Verzögerung (in Sekunden) definiert werden, bis das LGW nach einen Neustart einen ersten Verbindungsversuch zum WiFi Access Point (Router: Fritzbox etc.) startet.

Eine Anpassung kann für den folgenden Fall sinnvoll sein:

Nach einem Stromausfall benötigt ein WiFi Access Point (Router: Fritzbox etc.) in den meisten Fällen länger zum Starten als das LGW. In der default Einstellung führt das dazu, dass der LGW nach dem Starten versucht 30 Sekunden lang eine Verbindung zum AP herzustellen. Wenn keine Verbindung innerhalb dieser Zeit zustande kommt, dann gibt das LGW auf und macht seinen eigenen AP auf. Mit einer entsprechenden Verzögerung (Dauer bis der Router gestartet ist und der WiFi-AP zur Verfügung steht) kann sichergestellt werden, dass der AP gestartet ist und sich das LGW mit dem AP verbinden kann.

===Internal Sensors "Sensor-ID"===
Bei Einsatz von mehr als einem LaCrosseGateway, muss die LaCrosse-ID, mit der die internen Sensoren des Gateways übermittelt werden, angepasst werden.
Hierbei ist darauf zu achten, dass die LaCrosse-ID nur einmal auf einer FHEM Instanz vorkommen darf. Die ID kann entweder Dezimal (211) oder Hex (0xD3) angegeben werden.

'''''Detailinformationen:''''' Wenn ein LGW interne Sensoren hat (BME280, BMP180, DHT22, ...) dann sendet es die Daten des Sensors so, als ob es eine Wetterstation wäre (WS 1600 Format) an das LGW. Bisher hat es dafür die Sensor-ID 0 verwendet. Wenn man mehrere LGWs an ein FHEM angebunden hat, dann mischen sich deren Sensor-Daten auf dem LaCrosse device mit der ID 0. Um das zu vermeiden, kann man nun konfigurieren, mit welcher Sensor-ID die internen Sensoren gesendet werden sollen und die beiden LGWs unterschiedliche konfigurieren.

Die Anpassung der LaCrosse-ID hat keinerlei Einfluss auf die Daten, die von den Radios empfangen werden.

===Internal Sensors "Altitude"===
Mit diesen Parameter kann die Höhe über NN konfiguriert werden.

===Internal Sensors "Temperature-/Humidity-correction"===
Für Temperatur und Feuchte kann ein Korrekturwert angegeben werden.

Der Wert kann entweder ein Offset oder prozentual sein.

'''Beispiele:'''

{| class="wikitable" style="margin-left: auto; margin-left: 0px;"
! Korrekturwert !! Gemessen !! Ergebnis
|-
| -5
| 20°C
| 15°C
|-
| +3
| 20°C
| 23°C
|-
| -10%
| 20°C
| 18°C
|-
| +20%
| 20°C
| 24°C
|}

===SC16IS750-Clone===
Wenn aktiviert, wird die I2C clock auf 100 kHz runtergenommen und
es wird an einigen Stellen etwas auf die Bremse getreten, dass ein SC16IS70-Clone, der langsamer
als echte Hardware ist, mitkommt.
Sollte man ohne zwingenden Grund nicht aktivieren.

===Use MDNS===
Legt fest, ob das LGW seine IP-Adresse per MDNS bekannt gibt. Dies ist nötig, wenn man einen Mac hat oder bei Windows einen Bonjour-Service laufen hat.
Dies ist beim Entwickeln sinnvoll, kann üblicherweise ausgeschaltet bleiben.

===MCP23008===
Konfigurationsmöglichkeit für die 8 IO Pins (siehe auch [[#Inbetriebnahme_von_MCP23008|Inbetriebnahme von MCP23008]]).

===Serial bridge port und bridge baud===
Das LGW kann nun optional die serielle Schnittstelle des SC16IS750 transparent auf einem TCP Port bereitstellen.
Dazu gibt es die "Serial bridge port" und "Serial bridge baud" auf der "config"-Page des LGWs.
Das LGW überträgt transparent die Daten der seriellen Schnittstelle an FHEM und umgekehrt.

===Soft Serial Bridge===
Das LGW kann optional eine Soft serial bridge (Zuverlässig nur mit bis zu 57600 baud) transparent auf einem TCP Port bereitstellen.
Folgende Parameter können auf der LGW Setup-Page angepasst/konfiguriert werden:

{| class="wikitable" style="margin-left: auto; margin-left: 0px;"
! Parameter !! Beschreibung
|-
| Port
| Der Port, auf dem es angesprochen werden kann
|-
| Baud
| Die Baudrate für die Kommunikation
|-
| Nextion display
| Für den Betrieb eines Nextion Display muss diese Option aktiviert sein.
|-
| Add units
| Fügt an die Werte (Temp,Hum,Pres), die das LGW an das Display schickt, Einheiten an.
|}

Mithilfe des Soft serial bridge können verschiedene Geräte (nanoCUL, Nextion Display, etc.), welche per seriellen Schnitstelle kommunizieren können, in Betrieb genommen werden.

===Statuswerte abrufen===
Mit http://<IP-des-LGW>/state können die Statuswerte, die das LGW-Frontend anzeigt, als XML zur Weiterverarbeitung abgerufen werden.

Beispiel:
<syntaxhighlight lang="php"><LGW>
<Info Key="UpTimeSeconds" Value="107086"/>
<Info Key="UpTimeText" Value="1Tg. 5Std. 44Min. 46Sek. "/>
<Info Key="WIFI" Value="NeverTellThem"/>
<Info Key="MacAddress" Value="18:FE:34:9A:6D:48"/>
<Info Key="ChipID" Value="10120520"/>
<Info Key="ReceivedFrames" Value="93593"/>
<Info Key="FramesPerMinute" Value="52"/>
</LGW></syntaxhighlight>

===Funktionsweise Log===
Das Log ist als Hilfsmittel bei der Fehlersuche gedacht z.B. um bei PCA301 zu verfolgen, wann wer was wie frägt und antwortet oder um zu schauen, ob irgend welche Sensoren überhaupt empfangen werden und die Daten an FHEM geliefert werden.

[[Datei:lgw_LogPage.png|600px|thumb|left|LaCrosseGateway Log ebfrontend]]
<div style="clear:both;"></div>
Mit "Command" kann man Befehle an das LGW senden. Sie entsprechen dem, was man mit "set myLaCrosseGateway raw ..." aus FHEM schicken kann.
Die obere Liste enthält die Daten, die an FHEM übermittelt werden (bzw. würden, wenn sich ein FHEM auf das LGW verbunden hat)
Die untere Liste enthält debug-Informationen u.a. wird hier der letzte Systemstart aufgezeichnet.
Die verwendete SDK-Version und der letzte Reset-Grund werden ebenfalls ausgegeben

Das Log kann per HTTP abgerufen werden:
<syntaxhighlight lang="php">http://<LGW-IP>/getLogData</syntaxhighlight>

'''''Beispiel:'''''
<syntaxhighlight lang="php">http://192.168.31.211/getLogData</syntaxhighlight>

das Ergebnis sieht wie folgt aus:
<syntaxhighlight lang="php">DATA:OK 22 117 196 0 58 226 102 0 58 191 86 0 0 40 172 0 105 1 101 3 0 [75 C4 E2 66 00 00 BF 56 00 00 00 02 3B FC DC 00 69 01 65 4A A4 C4 F9 F2 4F 11 A4 F6 7C 03 A0 00 00 00 00 03 A0 38 09 21 27]
DATA:OK 9 11 130 4 173 125 [92 D5 97 7D 75]
DATA:OK EMT7110 84 81 8 207 0 36 0 1 1 199 1 [25 6A 54 51 40 02 00 24 C3 41 C7 9B]
SYS: AddOn: KV ADDON 01 Voltage=3.33,UpTime=4921
DATA:OK VALUES ADDON 01 Voltage=3.33,UpTime=4921
DATA:OK 9 38 1 4 67 65 [99 84 91 41 07]
DATA:OK 22 126 67 0 65 236 34 0 65 231 116 0 0 32 103 0 48 0 134 1 0 [7E 43 EC 22 00 00 E7 74 00 00 00 01 C7 AC D7 00 30 00 86 00 57 E4 69 1E 46 8E D4 68 C7 04 10 00 00 00 00 04 10 18 0A DC F7]
DATA:OK 9 36 1 4 128 61 [99 05 52 3D 96]
DATA:OK WS 0 4 4 185 255 255 255 255 255 255 255 255 255 0 3 252</syntaxhighlight>

'''''DATA:''''' für die obere Liste

'''''SYS: ''''' für die untere Liste

Bei jedem Aufruf werden die seit dem letzten Abruf neu aufgelaufenen Logeinträge geliefert.
Intern werden maximal 40 Einträge gepuffert (aber kein Ringpuffer, weil die ersten 40 mit dem Bootlog erhalten bleiben müssen)

'''''Hinweis:''''' Aus Performance- und Stabilitätsgründen sollten die Daten nicht zu häufig und nicht von zwei Instanzen gleichzeitig abgerufen werden.

=Hinweise zum Betrieb mit FHEM=

==Voraussetzungen==
Es wird ein [[#LaCrosseGateway einrichten |vorkonfiguriertes]] LaCrosseGateway vorausgesetzt.

Perl Modul: ''LWP::UserAgent'' - Dieses wird für das Firmware Update per FHEM LaCrosseGateway Modul benötigt.
Auf einem Raspberry Pi kann die Installation wie folgt durchgeführt werden:
<syntaxhighlight lang="php">sudo apt-get install libwww-perl</syntaxhighlight>
alternativ auch mit
<syntaxhighlight lang="php">sudo cpan LWP::UserAgent</syntaxhighlight>

'''FHEM Module'''

'''Hinweis:''' Ursprünglich wurde für das LaCrosseGateway das FHEM-Modul 36_JeeLink.pm verwendet. Da es aber inzwischen erhebliche Unterschiede zwischen dem JeeLink-LaCrosse-Sketch und dem LaCrosseGateway gibt, existiert seit Mitte November 2016 ein für das LaCrosseGateway spezialisiertes und optimiertes FHEM-Modul, das 36_LaCrosseGateway.pm.<br>
Dieses sollte anstatt dem 36_JeeLink.pm vorzugsweise verwendet werden.

''36_LaCrosseGeateway.pm'' (wird per FHEM Update verteilt)

''36_KeyValueProtocol.pm'' (wird per FHEM Update verteilt)

''36_LaCrosse.pm'' (wird per FHEM Update verteilt)

''36_PCA301.pm'' (wird per FHEM Update verteilt)

''36_EC3000.pm'' (wird per FHEM Update verteilt)

''36_EMT7110.pm'' (wird per FHEM Update verteilt)

''36_Level.pm'' (wird per FHEM Update verteilt)

''42_Nextion.pm'' (wird per FHEM Update verteilt)

==Device Definition==
===WLAN===
Die Definition sieht dann wie folgt aus:

<code>define <myLaCrosseGateway> LaCrosseGateway <IP-Adresse>:81</code>

''<myLaCrosseGateway>'' kann bei Bedarf angepasst werden.

''<IP-Adresse>'' muss entsprechend angepasst werden. Anstatt der IP-Adresse kann auch der Hostname vom LaCrosseGateway verwendet werden.

'''Beispiel:'''
<syntaxhighlight lang="php">define myLaCrosseGateway LaCrosseGateway 192.168.22.33:81</syntaxhighlight>
<u>IP-Adresse ermitteln:</u> Das LaCrosseGateway heist per default Einstellung "''LaCrosseGateway''", per ping auf den Hostnamen ''LaCrosseGateway'' kann die <IP-Adresse> ermittelt werden.

===USB===
Wenn man das LGW über USB betreiben will, dann möchte man üblicherweise kein WiFi.
Um das WiFi zu deaktivieren gibt es zwei Möglichkeiten:<br>
1.) Man kann mit einen 10k pullup auf 3.3V an MOSI == GPIO13 == D7 "jumpern", dass man kein wifi will. Wenn voranden, wird WiFi sofort beim Start deaktiviert.<br>
2.) Man kann WiFi auf der Setup-Page des LGW deaktivieren.<br>

Für den Betrieb via USB sieht die Definition wie folgt aus:

<code>define <myLaCrosseGateway> LaCrosseGateway <USB-Port>@57600</code>

''<myLaCrosseGateway>'' kann bei Bedarf angepasst werden.

''<USB-Port>'' muss entsprechend angepasst werden.

Beispiel: <code>define myLaCrosseGateway LaCrosseGateway /dev/ttyUSB0@57600</code>
''/dev/ttyUSB0'' Falls bereits mehrere USB Geräte angeschlossen sind muss der USB Port angepasst werden.

'''Hinweis:''' Sind mehrere USB Devices am FHEM Server (z.B. RPI, Cubietruck etc.) in Betrieb, dann ist die Zuordnung über den USB-Port nicht zuverlässig. Die Ports werden u.a. in der Reihenfolge vergeben, in der die Geräte angeschlossen werden. Zuverlässiger und eindeutiger ist die Zuordnung über die Serial-ID.

Dieser Befehl zeigt die Serial-ID der angeschlossenen USB-Devices an:
<code>ls -l /dev/serial/by-id</code>

Beispiel für die Ausgabe:
<syntaxhighlight lang="text">lrwxrwxrwx 1 root root 13 Mai 14 10:37 usb-Prolific_Technology_Inc._USB-Serial_Controller-if00-port0 -> ../../ttyUSB1
lrwxrwxrwx 1 root root 13 Mai 30 11:27 usb-Silicon_Labs_CP2102_USB_to_UART_Bridge_Controller_0001-if00-port0 -> ../../ttyUSB2
lrwxrwxrwx 1 root root 13 Apr 16 14:52 usb-Silicon_Labs_ELV_USB-Modul_UM2102_EVFSRFF8COEXIKOT-if00-port0 -> ../../ttyUSB0</syntaxhighlight>
In diesem Fall ist u.a. ein DEVKIT 1.0 mit der Serial-ID ''usb-Silicon_Labs_CP2102_USB_to_UART_Bridge_Controller_0001-if00-port0 -> ../../ttyUSB2'' angeschlossen.

Auf Basis dieser Informationen lässt sich folgende Definition erstellen:

<code>define myLaCrosseGateway LaCrosseGateway /dev/serial/by-id/usb-Silicon_Labs_CP2102_USB_to_UART_Bridge_Controller_0001-if00-port0@57600</code><br>
Wichtig ist es, die Übertragungsrate von 57600 bit/s anzugeben.<br><br>

Wenn man das LGW ohne WiFi betreibt, dann muss man natürlich auf die Annehmlichkeiten des Web-Frontends verzichten.<br>
In diesem Fall kann man die Konfiguration, die man über das Web-Frontend machen würde, über die serielle Schnittstelle machen.<br>

<code>set myLaCrosseGateway raw "SETUP ..."</code><br>
Das ... sind die gewünschten Einstellungen. Es müssen nicht alle Einstellungen gesendet werden sondern nur die, die man setzen will.<br>
Es werden nur die Einstellungen gesetzt und im EEPROM gespeichert, es wird aber kein Reboot ausgelöst<br>
Einen Reboot kann man mit "set myLaCrosseGateway raw 8377e" auslösen.<br>
Mehrere Einstellungen können durch Semikolon getrennt angegeben werden.<br>
Beispiel:
<code>set myJeeLink213 raw "SETUP UseWiFi false; IO0 OLED mode=thp; IO1 OLED Off; CorrT -2.5; ISID 213"</code>

Man kann auf der seriellen Schnittstelle die aktuellen Einstellungen abrufen.
Das command ist 1g<br>
<code>set myLaCrosseGateway raw 1g</code><br>
Man bekommt dann so etwas zurück:
<syntaxhighlight lang="text">SETUP ctSSID esesidee; ctPASS PasstWort; staticIP 192.168.31.211; staticMask 255.255.255.0; staticGW 192.168.31.1;
HostName LGW211; StartupDelay 1; ISID 0xD3; Altitude 220; CorrT 0; CorrH 0; DataPort1 81; DataPort2 82; SerialBridgePort 85;
SerialBridgeBaud 38400; UseMDNS true; IO0 OLED mode=s; IO1 OLED mode=thp; IO2 OLED On; IO3 OLED Off; oledStart 120; KVInterval 10;
KVIdentity 211; PCA301Plugs 036180=3,03A094=1,035FF1=6;</syntaxhighlight>

==Reconnect==
Falls das LaCrosseGateway nicht erreichbar ist (Kein Strom/Stromausfall, WLAN Verbingung unterbrochen etc.), bricht das LaCrosseGateway Device die Kommunikation ab. Über das entsprechende ''timeout'' Attribut kann das LaCrosseGateway device so konfigurert werden, dass es in regelmässigen Abständen erneut versucht eine Verbindung mit dem LaCrosseGateway herzustellen.

Konfigurationsempfehlung für ''timeout'' = 120 Sekunden und ''checkInterval'' = 30 Sekunden:

Der Wert kann in FHEM wie folgt gesetzt werden:
<syntaxhighlight lang="php">attr myLaCrosseGateway timeout 120,30</syntaxhighlight>
'''''myLaCrosseGateway''' muss auf den Gerätenamen in FHEM angepasst werden.''

Während das LaCrosseGateway eine WiFi-Verbindung aufbaut, benötigt das LaCrosseGateway-Modul je nach Konfiguration einige Zeit bis es einen neuen Connect auf den Datenport des LaCrosseGateway versucht. Das Finden der optimalen Werte erfordert etwas Geduld, es kann auch schon mal ein, zwei Minuten Dauern, bis die ersten Daten in FHEM übertragen werden.

'''''Erklärung der Timeout Werte:'''''
120,30 prüft alle 30 Sekunden, ob seit mindestens 120 Sekunden keine Daten mehr übermittelt wurden und falls dem so ist, macht es einen Reset auf der Schnittstelle, was die Verbindung zum LaCrosseGateway neu aufbaut. Das bedeutet, in so einem Fall ist die Verbindung nach spätestens 150 Sekunden wieder hergestellt.

'''''Hinweis:''' Mit diesem Attribut wird lediglich eine neue Verbindung aufgebaut, dabei wird das LaCrosseGateway nicht resetet.''

==Liste aller initCommands==
Eine aktuelle Liste der initCommands, die man von FHEM, Terminalprogramm oder Web-Frontend aus senden kann, sind auf dem Web-Frontend "Help"-Page" des LaCrosseGateways (ab V1.17) aufgeführt.

[http://IP-Adresse/setup http://IP-Adresse oder Hostname/help]

<syntaxhighlight lang="php">
<n>a set to 0 if the blue LED bothers
<n>c use one of the possible data rates (for transmit on RFM #1)
<n>d set to 1 to see debug messages
<8266>e Clear EEPROM
<n>f initial frequency in kHz (5 kHz steps, 860480 ... 879515)
<n>g get information (1g: get current settings)
<n>h Altitude
<n,f,i>i Init PCA for Radio #<n> to <m>MHz and <i>s Interval
<n>m bits 1: 17.241 kbps, 2 : 9.579 kbps, 4 : 8.842 kbps, 8 : 20.000 kbps (for RFM #1)
<n>M bits 1: 17.241 kbps, 2 : 9.579 kbps, 4 : 8.842 kbps, 8 : 20.000 kbps (for RFM #2)
<n>#<x>m bits 1: 17.241 kbps, 2 : 9.579 kbps, 4 : 8.842 kbps, 8 : 20.000 kbps (for RFM #x)
<n>o set HF-parameter e.g. 50305o for RFM12 or 1,4o for RFM69
<n>p payload on the serial port (1: all, 2: only undecoded data)
<n>r use one of the possible data rates (for RFM #1)
<n>R use one of the possible data rates (for RFM #2)
<n>#<x>r use one of the possible data rates (for RFM #x)
<x,x,...>s Send to PCA301 (must be 10 byte)
<x,x,...>S Send to CustomSensor
<n>t 0=no toggle, else interval in seconds (for RFM #1)
<n>T 0=no toggle, else interval in seconds (for RFM #2)
<n>#<x>t 0=no toggle, else interval in seconds (for RFM #x)
v show version
<n>w 0=no wifi
<n>z set to 1 to display analyzed frame data instead of the normal data
</syntaxhighlight>

==LaCrosseGateway zurücksetzen==
Das LaCrosseGateway kann auf die "Werkseinstellungen" zurückgesetzt werden.<br>
Dadurch werden alle auf der Setup-Page gemachten und im EEPROM gespeicherten Einstellungen verworfen.
Der Befehl dazu lautet: <syntaxhighlight lang="php">8266e</syntaxhighlight>
Er kann mit einem Terminalprogramm, von FHEM aus mit <syntaxhighlight lang="php">set <myLaCrosseGateway> raw 8266e</syntaxhighlight> oder von der Log-Page des LGW gesendet werden.

Danach startet das LGW wieder als Access Point [[#LaCrosseGateway einrichten|initiale Konfiguration]] und die Konfiguration kann über die "Setup-Page" neu vorgenommen werden kann.

==Sensoren/Aktoren anlegen==

Voraussetzung: FHEM autocreat ist aktiv.
Die [http://fhem.de/commandref.html#autocreate FHEM autocreate Funktion] ist aktiv.

Die erkannnten Sensoren und Aktoren werden automatisch erkannt und in FHEM angelegt, sobald Daten empfangen werden.

Empfangene Sensoren werden nur hinzugefügt werden, wenn LaCrossePairForSec auf 120 Sekunden gesetzt wird.
<syntaxhighlight lang="php">set myLaCrosseGateway LaCrossePairForSec 120 ignore_battery</syntaxhighlight>

==Inbetriebnahme von BMP180 / BME280==
Damit die Daten der o.g. Sensoren in FHEM zur Verfügung stehen, muss zunächst das FHEM-Device angelegt werden.

Das Anlegen kann automatisch erfolgen, dafür muss der folgende FHEM Befehl ausgeführt werden:
<syntaxhighlight lang="php">set myLaCrosseGateway LaCrossePairForSec 120 ignore_battery</syntaxhighlight>

Dann sollte von [http://fhem.de/commandref.html#autocreate FHEM autocreate Funktion] ein LaCrosse Device mit der [[#Sensor-ID | Sensor-ID]] (Default Wert: 0) angelegt werden.

Alternativ kann das FHEM Device manuell angelegt werden:
Die '''''ID''''', mit der das LGW die internen Sensoren sendet, entspricht der konfugurierten [[#Sensor-ID | Sensor-ID]] (Default Wert: 0)
Es verhält sich so, als ob es eine Wetterstation (wie z.B. WS 1600) wäre.
<syntaxhighlight lang="php">define <name> LaCrosse 00</syntaxhighlight>
Anchließend muss eine Höhenkorrektur (Grund: der Luftdruck wird immer bezogen auf NN angegeben, der Sensor liefert aber den Absolutdruck) mit dem command '''''h''''' in den initCommands vorgenommen werden, dies erfolgt mit dem FHEM Befehl:

Beispiel: 220h legt 220m über NN fest.''
<syntaxhighlight lang="php">attr myLaCrosseGateway initCommands 220h</syntaxhighlight>

'''Besser:''' Alternativ kann die Höhe über NN auch auf der Setup-Page des LGW gesetzt werden.<br>
Das hat den Vorteil, dass sofort vom Start an der normalisierte Luftdruck an FHEM gesendet wird und nicht erst, wenn die initCommands von FHEM geschickt wurden.

==Inbetriebnahme Piezo Summer==

Der Piezo Summer wird in FHEM über das LaCrosseGateway Modul angesteuert.

'''Beispiele:'''
<syntaxhighlight lang="php">
set myLaCrosseGateway raw 1,60b -> beep ... beep ... beep 60 Sekunden lang
set myLaCrosseGateway raw 2,300b -> beep beep ... beep beep ... beep beep 300 Sekunden lang
set myLaCrosseGateway raw 3,120b -> beep beep beep ... beep beep beep ... 120 Sekunden lang
set myLaCrosseGateway raw 0b -> beep stoppen
</syntaxhighlight>

==Inbetriebnahme von RFM69CW==
Mit dem LaCrosseGateway ist es möglich mehrere RFM69CW einzusetzten. Nachfolgend wird die Konfiguration des Senders/Empfängers erläutert.

Die "Default Werte" (wenn keine Angaben definiert werden) für die data rate sind wie folgt definiert:
<syntaxhighlight lang="php">
#1 (Erste) => 17241
#2 (Zweite) => 9579
#3 (Dritte) => 8842
#4 (Vierte) => 20000
#5 (Fünfte) => 17241
</syntaxhighlight>

'''''Hinweis:''' Detailinformationen sind auch auf der LaCrosseGateway "Help"-Page zu finden.''

{| class="wikitable" style="margin-left: auto; margin-left: 0px;"
|-
|colspan="2" style="text-align:center"|'''<Datenrate>#<Radio-Nummer><command>'''
|-
| <code>m t:</code> || ''Toggle-Steuerung''
|-
| <code>r:</code> || ''Datarate''
|-
| <code>f:</code> || ''Frequenz''
|}

'''''Beispiele:'''''

''
{| class="wikitable" style="margin-left: auto; margin-left: 0px;"
!Definition !! Erläuterungen
|-
| <syntaxhighlight lang="php">attr myLaCrosseGateway initCommands 0#1r v</syntaxhighlight>
| DataRate des ersten RFM setzen
|-
| <syntaxhighlight lang="php">attr myLaCrosseGateway initCommands 8842#3r v </syntaxhighlight>
| DataRate des dritten RFM setzen
|-
| <syntaxhighlight lang="php">attr myLaCrosseGateway initCommands 868300#2f v</syntaxhighlight>
| Frequenz des zweiten RFM setzten
|-
| <syntaxhighlight lang="php">attr myLaCrosseGateway initCommands 868295#3f v</syntaxhighlight>
| Frequenz des dritten RFM setzten
|-
| <syntaxhighlight lang="php">attr myLaCrosseGateway initCommands 17241#1r 8842#2r v</syntaxhighlight>
| Zwei RFM69CW mit DataRate 17241 und 8842
|-
| <syntaxhighlight lang="php">attr myLaCrosseGateway initCommands 3#1m 20#1t 8842#2r v</syntaxhighlight>
| Zwei RFM69CW mit 20 Sekunden DataRate 17241 toggle 9579 plus 8842 permanent
|-
| <syntaxhighlight lang="php">attr myLaCrosseGateway initCommands 220h 868295#1f 868310#2f v</syntaxhighlight>
| Zwei RFMs Frequenz 868295 und 868310 sowie Höhe über NN
|-
| <syntaxhighlight lang="php">attr myLaCrosseGateway initCommands 868295#1f 3#1m 20#1t 2,868950,60i 8842#3r 220h 0a v</syntaxhighlight>
| Drei RFMs Frequenz 868295 / PCA301 / WS1600 sowie Höhe über NN <br>Radio 1 auf 868295 MHz und Toggle 9K/17K mit 20 Sekunden<br>Radio 2 für PCA301 initialisiert<br>Radio 3 macht 8842 kbps für die WS 1600<br>Höhe 220m über NN<br>Activity LED aus<br>v am Ende ruft die neu gesetzen Daten vom LaCrosseGateway ab, damit sie in FHEM LaCrosseGateway Modul aktualisiert werden.
|}

'''''Hinweis:''' Es ist wichtig ein "v" an das Ende eines initCommands anzuhängen. Damit wird veranlasst, dass das LaCrosseGateway seine neuen Einstellungen an FHEM zurückmeldet.
==Inbetriebnahme von PCA301==
PCA301 im LGW funtioniert ähnlich dem PCA301 Sketch, allerding mit einigen systembedingten Abweichungen.

Per default ist PCA301 nicht aktiviert, es muss in den initCommands aktiviert werden. Dazu gibt es das command "'''''i'''''".

'''<RadioNr>,<Frequenz>,<Poll-Intervall>i'''

Die Initialisierung kann auch erneut geschickt werden, um z.B. das Poll-Intervall zu ändern.

'''''Wichtig:''''' Es darf nur '''"ein"''' Radio für PCA301 initialisiert sein, nicht mehrere. Das PCA301 initialisierte Radio ist dediziert für PCA301 zuständig, es kann nicht zwischen anderen Protokollen (z.B. LaCrosse) toggeln.''

Das ''Poll-Interval'' sollte nicht extrem heruntergesetzt (nicht unter eine Minute) werden, da PCA301 sonst LaCrosse verdrängt. PCA301 hat hörere Priorität, da es bei der Kommunikation
mit den Dosen keine Antworten überhören darf.

Unter Umständen muss die Frequenz etwas angepasst werden, wenn das Radio und/oder die Dosen nicht genau auf 868950 liegen.
Das ist daran zu erkennen, dass entweder gar keine Antwort von den Dosen oder verzögerte Antwort ankommt.
Werte von 868960 oder 960970 haben in manchen Fällen Abhilfe gebracht.

'''''Beispiele:'''''

{| class="wikitable" style="margin-left: auto; margin-left: 0px;"
! Definition !! Erläuterungen
|-
| style="width:40%" | <code>attr myLaCrosseGateway initCommands 2,868950,120i v</code>
| Initialisiert den zweiten RFM auf 868950 MHz und setzt das Poll-Intervall auf 120 Sekunden
|-
| <code>attr myLaCrosseGateway initCommands 1,868950,120i 3#2m 20#2t 220h 0a v</code>
| Initialisierung eines LaCrosseGateways mit zwei Radios für TX29, TX35, PCA301 und BMP180/BME280.<br>Das erste Radio macht PCA301 und das zweite toggelt 17241/9579 im 20 Sekunden Takt um TX29 und TX35 zu empfangen<br>der BMP180/BME280 liefert den Druck für 220m Meereshöhe<br>die LED ist deaktiviert
|}

'''Ablauf:'''

Nachdem PCA301 initialisiert ist, lauscht das LaCrosseGateway auf der entsprechenden Frequenz.
Sobald eine Dose empfangen wurde, wird sie in der Konfiguration (EEPROM) dauerhaft registriert und ab sofort gepollt.

Das ''Polling'' funtioniert so, dass für jede Dose geschaut wird, wann sie zuletzt empfangen wurde und wenn das länger als das konfigurierte Interval zurück liegt,
dann wird sie abgefragt. Wenn sonst etwas (Basisstation, anderes FHEM) die Dose abgefragt hat und das LaCrosseGateway die Antwort gehört hat, dann gilt das auch als
empfangen und es wird kein eigener Poll für die Dose ausgelöst. ''Das Zusammenspiel mit einer echten Basisstation konnte bisher nur grob simuliert werden.''

Das ''Pairing'' (also die Vergabe eines Kanals) funktioniert wie im PCA301-Sketch, button an der Dose ''"3 Sekunden"'' drücken, dann vergibt das LaCrosseGateway den nächsten freien Kanal.
Dosen, die bereits einen Kanal haben, können durch ein Schalten vor Ort, an das LaCrosseGateway angelernt werden. Das LaCrosseGateway erkennt sie und nimmt sie in die
Konfiguration auf. Falls die Dose bereits mit einem anderen Kanal bekannt war, wird der Kanal im LaCrosseGateway aktualisisert.

Auf der Setup-Page im Web-Frontend (http://IP-Adresse oder Hostname/setup) des LaCrosseGateway kann die Liste der bekannten Dosen (ID=Kanal) eingesehen werden. Hinweis: Es sollten keine Änderungen in diesem Bereich vorgenommen werden.

Wenn ein Kommando (Schalten, Daten abfragen, ...) an eine Dose gesendet wurde und keine Antwort kam, wird bereits im Sketch drei mal versucht, eine Antwort zu bekommen.

Das PCA301 Modul in FHEM funktioniert komplett wie bisher.

Weiterführende Themen zum PCA301 sind im Wiki [[PCA301 Funkschaltsteckdose mit Energieverbrauchsmessung]] und PCA301 FHEM Thread {{Link2Forum|Topic=11648|LinkText=JeeLink / PCA301 Thread}} beschrieben.

Die Befehle, die der PCA301-Sketch kennt, gibt es im LaCrosseGateway nur teilweise:
{| class="wikitable" style="margin-left: auto; margin-left: 0px;"
! Befehl (Beschreibung)!! Erläuterungen
|-
| <code>a "turn activity LED on or off</code>
| wie bisher
|-
| <code>l "list known devices"</code>
| entfallen, kann man nun im Web-Frontend sehen
|-
| <code>q "turn quiet mode on or off"</code>
| wie bisher
|-
| <code>r "list recordings"</code>
| entfallen
|-
| <code>s "send to plug"</code>
| wie bisher
|-
| <code>v "report version and configuration parameters"</code>
| wie bisher
|-
| <code>d, e, p "poll / turn a device on / off"</code>
| entfallen
|-
| <code>h, +, -, # "modify and display RF12 Frequency register"</code>
| entfallen, ersetzt durch das "i" command bzw. das bereits vorhandene "f" command
|}

==Inbetriebnahme von Energy Count 3000 (EC3000)==
Die EC3000 sendet auf 868.300 kHz mit 20.000 kbps. Dafür wurde eine neue data rate hinzugefügt.
Sie kann mit 3r oder 20000r gesetzt werden. Wenn diese data rate gesetzt wird, wird auch automatisch der RFM69 auf den Empfang von EC3000 uminitialisiert.

EC3000 kann auch in einen data rate toggle mit einbezogen werden. Dazu gibt es nun das bit mit dem Wert 8 für 20.000 kbps

Um EC3000 dediziert mit einem der drei RFMs zu empfangen muss man einfach die data rate des gewünschten RFM setzen. Beispiel initCommand:
20000#2r

Um EC3000 in einen data rate toggle mit einzubeziehen muss im m command das 8-wertige bit gesetzt werden.
Wenn man z.B. mit dem zweiten Radio 17k Sensoren (TX29...) und EC3000 empfangen soll (20 Sekunden toggle), wäre das initCommand:

'''Beispiel:'''
<syntaxhighlight lang="php">attr myLaCrosseGateway initCommands 9#2m 20#2t v</syntaxhighlight>

==Inbetriebnahme von MCP23008==
Auf der LaCrosseGateway "config"-page kann für jeden der 8 IO Pins konfiguriert werden, ob es ein Input oder Output Pin ist.

'''Input''': Eingang, wird per KVP an FHEM übermittelt. Einsatzzweck: z.B. Anschluß von Pushbuttons.

'''Output''': Kann von FHEM aus gesetzt werden. Einsatzzweck: z.B. Anschluß von LEDs.

Beispiel: ''Input => Eingang, wird per KVP an FHEM übermittelt''
<syntaxhighlight lang="php">OK VALUES LGPB 211 GP2=0,GP3=1,GP4=0,GP5=0,GP6=0,GP7=0</syntaxhighlight>

Beispiel: ''Output => Kann von FHEM aus gesetzt werden.''
<syntaxhighlight lang="php">set myLaCrosseGateway raw "MCP GP0=1,GP1=0"</syntaxhighlight>

==Inbetriebnahme Analogport==
Der Analogport A0 des ESP8266 wird als Reading im LaCrosseGatewayModul aufgeführt.
Um das zu aktivieren, muss man auf der Setup-Page des LGW die Option "Send analog values" ankreuzen.
Der Eingangsspannungsbereich von A0 ist 0V ... 1.0V, was zu einem Reading von 0 ... 1023 führt.

==Inbetriebnahme von OLED-Display==
Es wird das 128x64 pixel 0.96" I2C Display mit dem SSD1306 controller und das 128x64 pixel 1.3" mit dem SH1106 controller unterstützt.

Für die korrekte Darstellung auf dem 1.3" Display, muss die Checkbox 1.3" auf der Setup-Page aktiviert werden

Hinweis: das 0.96" Display bekommt man auch in einer Varianten, die SPI unterstützt. Diese Variante kann nur nach einem Umbau verwendet werden.

Der nachfolgende Funktionsumfang ist implementiert:

*OLED ein- und ausschalten sowie das Senden von individuellen Texten über FHEM mithilfe des LaCrosseGateway-Moduls
*OLED Startverhalten konfigurierbar
*Übermittlung des Display Status im KVP
*Anzeige von Statusinformationen in der obersten Zeile mithilfe von Symbolen (siehe Abbildung - von links nach rechts)
**WiFI connect erfolgreich
**Ein FHEM hat sich auf einen DataPort connected
**Ein FHEM hat sich auf den Prozessor an der [[#Serial_transparent_bridge|uart bridge]] connected
**WiFi Signalstärke (dBm). Hinweis: -36 ist besser als -60
[[Datei:lgw_oled_statuszeile.png|400px|thumb|left|OLED Anzeige von Statusinformationen]]
<div style="clear:both;"></div>
*Darstellung von bis zu drei Texten und optional ein Symbol.
*Definition des Zeitintvervalls für das Umschalten zur nächsten Seite
*Zuweisung der Modes an die Ports des MCP23008 (Die Konfiguration erfolgt auf der "Setup"-Page)
*Fortschrittsanzeige beim Flashen eines an die serielle Schnittstelle des SC16IS750 angeschlossenen Arduinos (siehe SubProzessor und Serial transparent bridge)

===OLED Start Modus===
Einstellungsmöglichkeit über die "Config"-Page wie sich das OLED nach einem Start verhalten soll.
Mögliche Optionen: on / off / Anzahl Sekunden, nach denen es ausgeht.
Zusätzlich kann der initiale Mode festgelegt werden (z.B. thp)

===Modes===
{| class="wikitable" style="margin-left: auto; margin-left: 0px;"
! Prefix !! Parameter !! Erläuterung
|-
| OLED mode=
| t
| Temperatur des internen Sensors
|-
| OLED mode=
| h
| Feuchte des internen Sensors
|-
| OLED mode=
| p
| Druck des internen Sensors
|-
| OLED mode=
| s
| Statuswerte des LGW
|-
| OLED mode=
| f
| von FHEM gesetzter Text
|}

===Mögliche Symbole===
{| class="wikitable" style="margin-left: auto; margin-left: 0px;"
! Parameter !! Erläuterung !! OLED Darstellung
|-
| t
| Temperature
| [[Datei:lgw_sym_t.jpg|150px|thumb|left|]]
<div style="clear:both;"></div>
|-
| h
| Humidity
|[[Datei:lgw_sym_h.jpg|150px|thumb|left|]]
<div style="clear:both;"></div>
|-
| p
| Pressure
|[[Datei:lgw_sym_p.jpg|150px|thumb|left|]]
<div style="clear:both;"></div>
|-
| s
| System
|[[Datei:lgw_sym_s.jpg|150px|thumb|left|]]
<div style="clear:both;"></div>
|-
| i
| Info
|[[Datei:lgw_sym_i.jpg|150px|thumb|left|]]
<div style="clear:both;"></div>
|-
| w
| Warning
|[[Datei:lgw_sym_w.jpg|150px|thumb|left|]]
<div style="clear:both;"></div>
|-
| e
| Error
|[[Datei:lgw_sym_e.jpg|150px|thumb|left|]]
<div style="clear:both;"></div>
|}

===Beispiele===

{| class="wikitable" style="margin-left: auto; margin-left: 0px;"
! Definition !! Erläuterung
|-
| style="width:30%" | <syntaxhighlight lang="php">set myLaCrosseGateway raw "OLED On"</syntaxhighlight>
| Schaltet ein angeschlossenes Display ein
|-
| <syntaxhighlight lang="php">set myLaCrosseGateway raw "OLED Off"</syntaxhighlight>
| Schaltet ein angeschlossenes Display aus
|-
| <syntaxhighlight lang="php">set myLaCrosseGateway raw "OLED interval=20"</syntaxhighlight>
| Legt fest, dass (je nach mode) alle 20 Sekunden die nächste Seite angezeigt wird.
|-
| <syntaxhighlight lang="php">set myLaCrosseGateway raw "OLED mode=ths"</syntaxhighlight>
| Zeigt nacheinander Temperatur, Feuchte und Systemdaten an
|-
| <syntaxhighlight lang="php">set myLaCrosseGateway raw "OLED mode=thp"</syntaxhighlight>
| Zeigt nacheinander Temperatur, Feuchte und Luftdruck an
|-
| <syntaxhighlight lang="php">set myLaCrosseGateway raw "OLED mode=thps"</syntaxhighlight>
| Zeigt nacheinander Temperatur, Feuchte, Luftdruck und Systemdaten an
|-
| <syntaxhighlight lang="php">set myLaCrosseGateway raw "OLED mode=f"</syntaxhighlight>
| Zeigt ausschließlich den von FHEM festgeleget Text an
|-
| <syntaxhighlight lang="php">set myLaCrosseGateway raw "OLED mode=s"</syntaxhighlight>
| Zeigt ausschließlich die Systemdaten an
|-
| <syntaxhighlight lang="php">set myLaCrosseGateway raw "OLED show=Soll: 20.5,Ist: 19.2,,t"</syntaxhighlight>
| Zeigt die übergebenen Texte an und links das Symbol für Temperatur
|-
| <syntaxhighlight lang="php">set myLaCrosseGateway raw "OLED show=55%,,,h"</syntaxhighlight>
| Zeigt nur den Text "55%" und das Symbol für Feuchte an. Da es nur ein Text ist, wird er größer dargestellt
|-
| <syntaxhighlight lang="php">set myLaCrosseGateway raw "OLED show=Line 1,Line 2,Line 3"</syntaxhighlight>
| Zeigt drei Texte aber kein Symbol an.
|-
| <syntaxhighlight lang="php">attr myLaCrosseGateway initCommands "OLED mode=thps"</syntaxhighlight>
| Zeigt nacheinander Temperatur, Feuchte, Luftdruck und Systemdaten an. Der Mode wird immer geschickt, wenn FHEM sich neu auf das LGW connected.
|}

==Inbetriebnahme eines Nextion Displays==

Mithilfe der Seriellen Schnittstelle [[#Soft_serial_bridge|(Soft serial bridge]]), kann ein Nextion Display in Betrieb genommen werden. Das Besondere dabei ist, dass das LGW zusätzlich seine Status Informationen (AP-Verbindungsstatus, RSSI ,IP ,Version ,FHEM Verbindungsstatus, etc.) an das Display schickt.
Die Anbindung an FHEM erfolgt Mithilfe des Nextion Moduls (42_Nextion.pm), welches per FHEM Update verteilt wird.

Ein Diskussionsthread zum Thema „LaCrosseGateway mit Nextion Display“ findet man {{Link2Forum|Topic=63443|LinkText=hier}}.

===Voraussetzungen===
Vor der Inbetriebnahme in FHEM, müssen folgende Voraussetzungen erfüllt sein:
*Das Display ist wie [[#Nextion_Display|hier]] beschrieben an das LGW angeschlossen.
*Die [[#Soft_serial_bridge|Soft serial bridge]] auf der LGW Setup-page ist konfiguriert.
*Das LaCrosse Gateway Device ist wie [[#Device_Definition|hier]] beschrieben angelegt.

===Funktionsumfang===

Der nachfolgende Funktionsumfang ist implementiert:

*OTA Firmware (.tft File) übertragung an das Display
*Automatische Anpassung der Baudrate auf dem Nextion
*Das LGW schickt (periodisch) Werte an folgende Controls:
{| class="wikitable" style="margin-left: auto; margin-left: 0px;"
! Control!! Beschreibung/Anmerkung
|-
| LGW#temp.txt
| Nur wenn ein entsprechender on board sensor vorhanden ist.
|-
| LGW#hum.txt
| Nur wenn ein entsprechender on board sensor vorhanden ist.
|-
| LGW#pres.txt
| Nur wenn ein entsprechender on board sensor vorhanden ist.
|-
| LGW#rssi.txt
| WLAN RSSI Signalstärke
|-
| LGW#ip.txt
| IP-Adresse des LGW's
|-
| LGW#fpm.txt
| Frames Per Minute
|-
| LGW#heap.txt
| Free Heap
|-
| LGW#up.txt
| Uptime
|-
| LGW#ver.txt
| Version
|-
| LGW#wifi (vis)
| Setzt die visibility
|-
| LGW#fhem
| Setzt die visibility
|-
| LGW#cpu1
| Setzt die visibility
|-
| LGW#cpu2
| Setzt die visibility
|-
| LGW#main
| Sendet, nachdem es sich initialisiert hat, ein "page LGW#main" an das Nextion.
|-
| LGW#info
| Sendet die Info an die LGW#prog page
|-
| LGW#ptext
| Sendet die Info an die LGW#prog page
|-
| LGW#pbar
| Sendet die Info an die LGW#prog page
|}

*Fortschrittsanzeige beim flashen der Nextion Firmware

===Device Definition Nextion Modul===

Die Definition für die Nextion Bridge sieht dann wie folgt aus:

<code>define <nextion> Nextion <IP-Adresse>:<Port></code>

''<nextion>'' kann bei Bedarf angepasst werden.

''<IP-Adresse>'' muss entsprechend angepasst werden. Anstatt der IP-Adresse kann auch der Hostname vom LaCrosseGateway verwendet werden.

''<Port>'' Ist der auf der Setup-page definierte Port

'''Beispiel:'''
<syntaxhighlight lang="php">define nextion Nextion 192.168.22.33:86</syntaxhighlight> IP-Adresse ermitteln: Das LaCrosseGateway heist per default Einstellung "LaCrosseGateway", per ping auf den Hostnamen LaCrosseGateway kann die <IP-Adresse> ermittelt werden.

===Firmware erstellen und flashen ===
Ein UI für das Nextion Display wird mit dem Nextion Editor erstellt. Mithilfe des Editors kann die entsprechende Firmware (tft Datei – siehe „File -> Open build folder“) kompiliert (Button: Compile) werden.

Das LGW kann die Firmware (.tft Datei) zum Display übertragen. Dazu gibt es zwei Varianten:

'''curl'''

Syntax lautet:

<code>curl --http1.0 -# -o ~output.txt -H "Content_Type:multipart/form-data" -F "file=@<tftFileName>; filename=nextion.tft" http://<LGW-IP>/ota/nextion</code>

Beispiel:

<code>curl --http1.0 -# -o ~output.txt -H "Content_Type:multipart/form-data" -F "file=@D:\MyNextionFiles\lgw.tft; filename=nextion.tft" http://192.168.31.213/ota/nextion</code>

'''Das LaCrosseGateway Modul in FHEM'''

Syntax lautet:

<syntaxhighlight lang="php">set <myLaCrosseGateway> nextionUpload</syntaxhighlight>

Wenn das Attribut "tftFile" gesetzt ist, wird die darin angegebene Datei hochgeladen, ansonsten wird versucht, das File „FHEM/firmware/nextion.tft“ hochzuladen.

===Anwendungsbeispiel===
In {{Link2Forum|Topic=63443|LinkText=diesem FHEM Forum Thread}} wurde ein LGW Nextion UI erarbeitet (Stand 01.08.2017 {{Link2Forum|Topic=63443|Message=582453|LinkText=Version 0.7}}), um die Funktionsweise zu demonstrieren.
Das Nextion UI besteht aus folgenden Pages:
{| class="wikitable"
!ID !! Name !! Page !! Beispiel !! Hinweise/Funktion/Bechreibung !! Nextion Debug commands
|-
| 0 ||Boot || Boot || [[Datei:lgw_nextion_boot.png|200px|thumb|left|]]<div style="clear:both;"></div> || Das ist die Startseite nach Einschalten des Nextion Displays. ||
|-
| 1 ||Progress||LGW#prog ||[[Datei:lgw_nextion_prog.png|200px|thumb|left|]]<div style="clear:both;"></div>|| Auf dieser Seite wird der WiFi Verbindungsfortschritt angezeit. Alles Werte werden vom LGW befüllt. ||page LGW#prog
vis LGW#pbar,1

vis LGW#ptext,1

LGW#pbar.val=50

LGW#ptext.txt="Connect WiFi (1)"
|-
| 2 ||Main|| LGW#main || [[Datei:lgw_nextion_main.png|200px|thumb|left|]]<div style="clear:both;"></div> ||Dies ist die Haupseite, welche vom LGW aufgerufen wird, sobald der Bootvorgang abgeschlossen ist.<br>Hinweise zur Funktionsweise findet man {{Link2Forum|Topic=63443|Message=546896|LinkText=hier}}|| page LGW#main
vis LGW#wifi,1

vis LGW#fhem,1

vis LGW#cpu1,1

vis LGW#cpu2,1

LGW#rssi.txt="-68"

tTime.txt="23:45"

tDate.txt="01.08.2017"

vis iTemp,1

LGW#temp.txt="25.7"

vis iHum,1

LGW#hum.txt="68%"

vis iPres,1

LGW#pres.txt="1024hPa"

vis iWind,1

tout_ws.txt="23km/h"

vis iOutT,1

tout_t.txt="28°C"
|-
| 3 ||Info Page|| Info || [[Datei:lgw_nextion_info.png|200px|thumb|left|]]<div style="clear:both;"></div> || Alle Informationen auf dieser Seite werden von LGW automatisch befüllt. || page Info
vis LGW#ip,1

LGW#ip.txt="192.168.222.1"

vis LGW#fpm,1

LGW#fpm.txt="5"

vis LGW#heap,1

LGW#heap.txt="16280"

vis LGW#ver,1

LGW#ver.txt="1.30"

vis LGW#up,1

LGW#up.txt="1Tg.4Std.34Min."
|-
| 4 || Info Page 2 || Info2 || [[Datei:lgw_nextion_info2.png|200px|thumb|left|]]<div style="clear:both;"></div> || tInfo50 und tInf51 sind für Nextion UI Version reserviert. tInfo60 bis tInfo91 sind nicht belegt und können verwendet werden, um z.B. die FHEM Verison anzuzeigen. || page Info2
tInfo60.txt="tInfo60:"

tInfo61.txt="tInfo61"

tInfo70.txt="tInfo70:"

tInfo71.txt="tInfo71"

tInfo80.txt="tInfo80:"

tInfo81.txt="tInfo81"

tInfo90.txt="tInfo90:"

tInfo91.txt="tInfo91"
|-
| 5 || Settings || Settings || [[Datei:Lgw_nextion_Settings.png|200px|thumb|left|]]<div style="clear:both;"></div> || Einstellungsmöglichkeit von Helligkeit (Wertebereich von 10% bis 100%) des Displays und des PowerOff Timeouts (Wertebereich: off und 1-120 Sek.)||page Settings
h1.val=25

h0.val=60
|-
| 6 || Control Center||CoCe||[[Datei:lgw_nextion_CoCe.png|200px|thumb|left|]]<div style="clear:both;"></div> ||Zum Schalten von Aktoren und Status anzeige.<br>Weiteren Hinweise zur Funktionsweise sind {{Link2Forum|Topic=63443|Message=576902|LinkText=hier}} zu finden. || page CoCe
lblT1.txt="lbT1"

lblS1.txt="aus"

lblT2.txt="lbT2"

lblS2.txt="an"

lblT3.txt="lbT4"

lblS3.txt="zu"

lblT4.txt="lbT3"

lblS4.txt="auf"

lblT5.txt="lbT5"

lblS5.txt="n.a."
|-
| 7 || Weather ||Weather||[[Datei:lgw_nextion_Weather.png|200px|thumb|left|]]<div style="clear:both;"></div>||Zur Anzeige einer Wettervorhersage. Diese Seite wird durch ein touch auf den "Temp-Wert" in der Main#Page aufgerufen. <br>Implementierungshinweise sind {{Link2Forum|Topic=63443|Message=582453|LinkText=hier}} zu finden. ||page Weather
p0.pic=12

t0.txt="Mo 01 Aug 2017\rmin:15 max:18"

p1.pic=16

t1.txt="Di 02 Aug 2017\rmin:15 max:18"

p2.pic=17

t2.txt="Mi 03 Aug 2017\rmin:15 max:18"

p3.pic=12

t3.txt="Do 04 Aug 2017\rmin:25 max:28"

p4.pic=15

t4.txt="Fr 05 Aug 2017\rmin:28 max:32"
|}

Hinweis: Alle Contorls die mit dem Namen "LGW#" beginnen sind für das LGW reserviert und werden entsprechend vom Gateway befüllt.

===Nextion Tipps & Tricks===
====Nextion Commandreferenz====
Sehr hilfreich ist die Nextion instruction Page, welche hier: https://www.itead.cc/wiki/Nextion_Instruction_Set zu finden ist.

==Serial Transparent Bridge==
Das LGW kann optional die serielle Schnittstelle des SC16IS750 transparent auf einem TCP Port bereitstellen.
Dazu gibt es die settings ''"Serial bridge port"'' und ''"Serial bridge baud"'' auf der "Setup"-Page" (Web-Frontend) des LaCrosseGateways.
Das LaCrosseGateway überträgt transparent die Daten der seriellen Schnittstelle an FHEM und umgekehrt.
Damit kann z.B. ein NanoCUL an das LaCrosseGateway angeschlossen werden und in FHEM verwenden werden.

'''''Vorgehensweise:'''''
*Einen NanoCUL bauen, z.B. auf Basis eines Arduino Pro Mini, flashen und testweise in Betrieb nehmen.
*Den NanoCUL an die serielle Schnittstelle des SC16IS70 anschließen
*Port und baud rate auf der "Setup"-Page des LaCrosseGateways festlegen, z.B. Port 85 und 38400 baud
*CUL in FHEM definieren (Beispiel):
<syntaxhighlight lang="php">define CULXYZ CUL <IP-Adresse>:85 0000</syntaxhighlight>
'''''<CULXYZ>''''' Muss nach eigenen Bedürfnissen angepasst werden.

'''''<IP-Adresse>''''' Muss entsprechend angepasst werden.

Sollte das CUL-Device nicht erreichbar sein (Restart, Austausch im Falle eines Deffekts etc.), empfiehlt sich einen reconnect Mechnismus in FHEM zu implementieren.

Dieser kann wie folgt aussehen:

<syntaxhighlight lang="php">define CULXYZ-Reconnector at +*00:00:30 {\
my $deviceName = "<CULXYZ>";;\
my $version = CommandGet("", $deviceName . " version");;\
my $gotAnswer = index($version, 'No answer') == -1;;\
\
if(!$gotAnswer) {\
fhem("set " . $deviceName . " reopen");;\
}\
\
} </syntaxhighlight>
'''''<CULXYZ>''''' Muss nach eigenen Bedürfnissen angepasst werden.

'''''Vorgehen Firmware flashen mit LGW'''''

Ein bereits in Betrieb genomene NanoCUL kann nach dem gleichen Vorgehen (siehe [[#SubProzessor|"SubProzessor - Vorgehen Firmware flashen"]]) wie ein SubProzessor geflasht werden.

==Zugriff mit mehreren FHEM Instanzen==

Bis zu drei FHEM Instanzen können auf das LaCrosseGateway gleichzeitig zugreifen.
Auf der "Setup"-Page des LaCrosseGateways können bis zu drei Ports (Data ports), pro Port eine FHEM Instanz, definiert werden (Reboot erforderlich).
Aus Performancegründen empfiehlt sich nur die benötigten Ports zu definieren.

'''''Hinweise:''''' Die Portnummer 8266 wird für OTA Update verwendet, und 80 für die "Config"-page. Aus diesem Grund ist die Verwendung dieser ports nicht erlaubt.

Wenn sich mehrere FHEM Instanzen ein LaCrosseGateway teilen, dann ist darauf zu achten, dass die eine gemeinsame/gleiche initCommand Konfiguration haben. Sollten die FHEM Instanzen unterschiedliche initCommands senden, gewinnt das (zufällig) letzte und legt es für alle anderen fest.

=Nano LaCrosse Gateway=
Das nano LaCrosse Gateway verwendet die gleiche [https://svn.fhem.de/trac/export/HEAD/trunk/fhem/FHEM/firmware/JeeLink_LaCrosseGateway.bin Firmware] wie das WiFi LaCrosse Gateway, der signifikante Unterschied ist die kompakte (portable) Bauform. Aufgrund der Bauform können jeodch nicht alle Bauteile verwendet werden.
Das Gateway eignet sich sehr gut als Entwicklungstick (dies ist der Entstehungsgrund) oder zum Empfangen und Steuern von LaCrosse basierten Sensoren/Aktoren an einem FHEM Server (RPI,Cubietruck, etc.).

Der Betieb über WiFi, entsprechende Stromversorgung (per USB) vorausgesetzt, ist ebenfalls möglich.

Weiterführende Informationen zum nano LaCrosse Gateway und Ideensammlung für eine Platine sind im {{Link2Forum|Topic=51329|LinkText=FHEM Forum}} zu finden.

==Bauteile==
Folgende Bauteile werden benötigt:
*Gehäuse [http://www.elv.de/output/controller.aspx?cid=74&detail=10&detail2=36507 schwarz] oder [http://www.voelkner.de/products/164819/USB-Gehaeuse-USB-1kl-Transparent.html transparent]
*ESP-12E
*Auto-Flash-Reset-Schaltung
*[http://www.aliexpress.com/item/6Pin-USB-2-0-to-TTL-UART-Module-Serial-Converter-CP2102-STC-Replace-Ft232/32364013343.html?spm=2114.13010208.99999999.261.mWmpl5 CP2102 FTDI]
*RFM69CW
*Status-LED

==Schaltung==
[[Datei:lgw_nano_Schaltplan.png|600px|thumb|left|Schaltplan NanoLGW]]
<div style="clear:both;"></div>

==Selbstbau==
{| class="galleryTable noFloat"
|-
| [[Datei:lgw_nano_Selbstbau1.png|320px|thumb|left|Selbstbau nano LaCrosse Gateway 1]]
| [[Datei:lgw_nano_Selbstbau2.png|300px|thumb|left|Selbstbau nano LaCrosse Gateway 2]]
| [[Datei:lgw_nano_Selbstbau3.png|475px|thumb|left|Selbstbau nano LaCrosse Gateway 3]]
|}
==Platine==
===nano LaCrosse Gateway===
{| class="galleryTable noFloat"
|-
|[[Datei:Nanolgw_bestueckt_oberseite.jpg|400px|thumb|left|nano LaCrosse Gateway Platine Oberseite]]
|[[Datei:Nanolgw_bestueckt_unterseite.jpg|400px|thumb|left|nano LaCrosse Gateway Platine Unterseite]]
|}
===USB2TTL===
{| class="galleryTable noFloat"
|-
|[[Datei:Nanolgw_USB2TTL_1.jpg|400px|thumb|left|USB2TTL Platine Oberseite]]
|[[Datei:Nanolgw_USB2TTL_2.jpg|400px|thumb|left|USB2TTL Platine Unterseite]]
|}
===nano LaCrosse Gateway inkl. USB2TTL===
{| class="galleryTable noFloat"
|-
|[[Datei:Nanolgw_oberseite_USB2TTL_1.jpg|400px|thumb|left|nano LaCrosse Gateway inkl. USB2TTL Oberseite]]
|[[Datei:Nanolgw_oberseite_USB2TTL_2.jpg|400px|thumb|left|nano LaCrosse Gateway inkl. USB2TTL Oberseite]]
|}
{| class="galleryTable noFloat"
|-
|[[Datei:Nanolgw_unterseite_USB2TTL.jpg|400px|thumb|left|nano LaCrosse Gateway inkl. USB2TTL Unterseite]]
|[[Datei:Nanolgw_seitenansicht_USB2TTL.jpg|400px|thumb|left|nano LaCrosse Gateway inkl. USB2TTL Seitenansicht]]
|}
===nano LaCrosse Gateway fertig bestückt inkl. Gehäuse===
{| class="galleryTable noFloat"
|-
|[[Datei:Nanolgw_USB2TTL_fertig_oberseite.jpg|400px|thumb|left|nano LGW fertig bestückt inkl. Gehäuse Oberseite]]
|[[Datei:nanolgw_USB2TTL_fertig_unterseite.jpg|400px|thumb|left|nano LGW fertig bestückt inkl. Gehäuse Unterseite]]
|}
===Platine bestücken (Hinweise und Tipps)===
*Die Beschriftung SJ4 und SJ3 ist auf dem USB2TTL Wandler vertauscht, dies beeinträchtigt aber die Funktion nicht.
*Beim nanoLGW hängt C1 etwas über dem FTDI232RL vom USB2TTL Wandler, daher braucht diese Platine noch eine "Schönheitskorrektur".

= Tipps & Tricks =

==Löschen des kompletten Flash des ESP8266 mit dem esptool==
Aufgrund eines aktuell im espressif SDK vorhandenen Bugs, kann es passieren, dass das LaCrosseGateway nach dem Aufspielen der Firmware, mit einer Exception den Bootvorgang (nach "Start WIFI_STA") abbricht und nicht mehr ordnungsgemäß starten kann. In diesem Fall hilft nur noch das Löschen des kompletten Speichers des ESP8266 und das erneute Aufspielen der Firmware.

Mit dem nachfolgenden Befehl kann der Speicher des ESP8266 komplett gelöscht werden.

'''''Achtung:''' Dabei werden alle Einstellungen unwiderruflich gelöscht''
<syntaxhighlight lang="php">./esptool -vv -cp /dev/tty.SLAB_USBtoUART -cb 115200 -ca 0x00000 -cd nodemcu -ce</syntaxhighlight>

'''''</dev/tty.SLAB_USBtoUART>''' Muss entsprechend angepasst werden.''

=Weiterführende Links=
Diskussionsthread aus dem Forum:

{{Link2Forum|Topic=43672|LinkText=LaCrosseGateway - LaCrosse, PCA301 und EC3000 über wifi mit ESP8266 ohne Arduino}}

{{Link2Forum|Topic=45594|LinkText=Platine für LaCrosseGateway: Platinenbestellung}}

{{Link2Forum|Topic=51329|LinkText=Platine für nanoLGW (LaCrosse Gateway): Layout}}

{{Link2Forum|Topic=52921|LinkText=Display für LaCrosseGateway}}

{{Link2Forum|Topic=63443|LinkText=LaCrosseGateway mit Nextion Display}}

[[Kategorie:Interfaces]]
[[Kategorie:IP Components]]
[[Kategorie:Other Components]]
[[Kategorie:Temperatursensoren]]
[[Kategorie:Feuchtesensoren]]
[[Kategorie:Wetterstationen]]
[[Kategorie:868MHz]]

Event-min-interval

2017-12-07T10:36:33Z

Markus1407: /* Wechselwirkungen */

{{SEITENTITEL:event-min-interval}} 

== Syntax ==

Mit dem Attribut [[event-min-interval]] kann für Readings eines Gerätes festgelegt werden, dass nach einer bestimmten Zeit ein Event, auch ohne Wertänderung ausgelöst wird.

Das ''event-min-interval'' Attribut wird in der folgenden Weise spezifiziert:

:<code><nowiki>attr <device> event-min-interval reading1:minInterval1[,reading2:minInterval2,...]</nowiki></code>

* Reading Name oder reguläre Ausdrücke
* minIntervall in Sekunden.

== Wechselwirkungen ==

Dieses Attribut steht in Wechselwirkung mit den Attributen [[event-on-change-reading]] und [[event-on-update-reading]], bitte also unbedingt auch deren Beschreibung berücksichtigen!

{| class="wikitable"
|+ Wechselwirkiungen
|-
|'''event-on-update-reading'''
|'''event-on-change-reading'''
|'''event-min-interval'''
|'''Wirkung'''
|-
|nicht gesetzt
|.*<br>
<br>
Bei event-on-change-reading kann zusätzlich noch ein Threshold gesetzt werden um die Anzahl der Events zu redizieren. Z.B. bei Temperaturwerten sinnvoll:<br>
event-on-change-reading Temp.*:0.5 ,.*<br>
<br>
Alle Readings, die mit Temp beginnen erzeugen nur ein event wenn die Änderung >0.5 Grad ist. Alle anderen Readings erzeugen bei jeder Änderung ein Event.<br>
|.*:3600
|Durch die Regex ".*" gilt für alle Readings:
Ein Event wird '''sofort''' ausgelöst wenn sich der Reading Wert ändert,<br>
ODER wenn mindestens 3600 Sekunden (1h) seit dem letzten Event vergangen ist<br>
UND das Reading '''aktuaisiert''' wird.<br><br>
Wird ein Reading nicht aktualisiert (mit dem gleichen Wert) gibt es nach Ablauf der Zeit auch kein Event.<br><br>
Beispiel:<br>
Ein Raspberry Pi GPIO besitzt ein Attribut poll_interval, dieses wird z.B. auf 10 Minuten gesetzt.<br>
Dann werden die Readings alle 10 Minuten aktualisiert. Bei konstantem Wert wird nach 1 Stunde und maximal 10 Minuten ein Event gesendet.<br>
|-
|.*
|nicht gesetzt
|.*:3600
|TODO
|-
|nicht gesetzt
|nicht gesetzt
|.*:3600
|Durch die Regex ".*" gilt für alle Readings:
Ein Event wird sofort ausgelöst wenn mindestens 3600 Sekunden (1h) seit dem letzten Event vergangen ist
EGAL ob das Reading aktualisiert wird oder gleich bleibt.

Beispiel:
Temperatursensor sendet Temperatur-Werte, es wird ein Event erzeugt wenn mindestens 3600 Sekunden (1h) seit dem letzten Event vergangen ist
EGAL ob die Temperatur sich verändert hat oder nicht.
|}

== Beispiele ==
Um alle Readings eines Gerätes bei Aktualisierungen zu protokollieren, sollte das Attribut folgendermaßen gesetzt werden:
:<code><nowiki>attr <device> event-min-interval .*:3600</nowiki></code>

== Siehe auch ==
*[[event-on-update-reading]]
*[[event-on-change-reading]]
*[[event-min-interval]]

== Links ==
*

[[Kategorie:Attribut (allgemeingültig)]]

Event-min-interval

2017-12-07T10:34:31Z

Markus1407: /* Wechselwirkungen */

{{SEITENTITEL:event-min-interval}} 

== Syntax ==

Mit dem Attribut [[event-min-interval]] kann für Readings eines Gerätes festgelegt werden, dass nach einer bestimmten Zeit ein Event, auch ohne Wertänderung ausgelöst wird.

Das ''event-min-interval'' Attribut wird in der folgenden Weise spezifiziert:

:<code><nowiki>attr <device> event-min-interval reading1:minInterval1[,reading2:minInterval2,...]</nowiki></code>

* Reading Name oder reguläre Ausdrücke
* minIntervall in Sekunden.

== Wechselwirkungen ==

Dieses Attribut steht in Wechselwirkung mit den Attributen [[event-on-change-reading]] und [[event-on-update-reading]], bitte also unbedingt auch deren Beschreibung berücksichtigen!

{| class="wikitable"
|+ Wechselwirkiungen
|-
|'''event-on-update-reading'''
|'''event-on-change-reading'''
|'''event-min-interval'''
|'''Wirkung'''
|-
|nicht gesetzt
|.*
|.*:3600
|Durch die Regex ".*" gilt für alle Readings:
Ein Event wird '''sofort''' ausgelöst wenn sich der Reading Wert ändert,<br>
ODER wenn mindestens 3600 Sekunden (1h) seit dem letzten Event vergangen ist<br>
UND das Reading '''aktuaisiert''' wird.<br><br>
Wird ein Reading nicht aktualisiert (mit dem gleichen Wert) gibt es nach Ablauf der Zeit auch kein Event.<br><br>
Beispiel:<br>
Ein Raspberry Pi GPIO besitzt ein Attribut poll_interval, dieses wird z.B. auf 10 Minuten gesetzt.<br>
Dann werden die Readings alle 10 Minuten aktualisiert. Bei konstantem Wert wird nach 1 Stunde und maximal 10 Minuten ein Event gesendet.<br>
<br>
Bei event-on-change-reading kann zusätzlich noch ein Threshold gesetzt werden um die Anzahl der Events zu redizieren. Z.B. bei Temperaturwerten sinnvoll:<br>
event-on-change-reading Temp.*:0.5 ,.*<br>
<br>
Alle Readings, die mit Temp beginnen erzeugen nur ein event wenn die Änderung >0.5 Grad ist. Alle anderen Readings erzeugen bei jeder Änderung ein Event.<br>
|-
|.*
|nicht gesetzt
|.*:3600
|TODO
|-
|nicht gesetzt
|nicht gesetzt
|.*:3600
|Durch die Regex ".*" gilt für alle Readings:
Ein Event wird sofort ausgelöst wenn mindestens 3600 Sekunden (1h) seit dem letzten Event vergangen ist
EGAL ob das Reading aktualisiert wird oder gleich bleibt.

Beispiel:
Temperatursensor sendet Temperatur-Werte, es wird ein Event erzeugt wenn mindestens 3600 Sekunden (1h) seit dem letzten Event vergangen ist
EGAL ob die Temperatur sich verändert hat oder nicht.
|}

== Beispiele ==
Um alle Readings eines Gerätes bei Aktualisierungen zu protokollieren, sollte das Attribut folgendermaßen gesetzt werden:
:<code><nowiki>attr <device> event-min-interval .*:3600</nowiki></code>

== Siehe auch ==
*[[event-on-update-reading]]
*[[event-on-change-reading]]
*[[event-min-interval]]

== Links ==
*

[[Kategorie:Attribut (allgemeingültig)]]

Event-min-interval

2017-11-04T17:54:17Z

Markus1407: /* Wechselwirkungen */

{{SEITENTITEL:event-min-interval}} 

== Syntax ==

Mit dem Attribut [[event-min-interval]] kann für Readings eines Gerätes festgelegt werden, dass nach einer bestimmten Zeit ein Event, auch ohne Wertänderung ausgelöst wird.

Das ''event-min-interval'' Attribut wird in der folgenden Weise spezifiziert:

:<code><nowiki>attr <device> event-min-interval reading1:minInterval1[,reading2:minInterval2,...]</nowiki></code>

* Reading Name oder reguläre Ausdrücke
* minIntervall in Sekunden.

== Wechselwirkungen ==

Dieses Attribut steht in Wechselwirkung mit den Attributen [[event-on-change-reading]] und [[event-on-update-reading]], bitte also unbedingt auch deren Beschreibung berücksichtigen!

{| class="wikitable"
|+ Wechselwirkiungen
|-
|'''event-on-update-reading'''
|'''event-on-change-reading'''
|'''event-min-interval'''
|'''Wirkung'''
|-
|nicht gesetzt
|.*
|.*:3600
|Durch die Regex ".*" gilt für alle Readings:
Ein Event wird '''sofort''' ausgelöst wenn sich der Reading Wert ändert,<br>
ODER wenn mindestens 3600 Sekunden (1h) seit dem letzten Event vergangen ist<br>
UND das Reading '''aktuaisiert''' wird.<br><br>
Wird ein Reading nicht aktualisiert (mit dem gleichen Wert) gibt es nach Ablauf der Zeit auch kein Event.<br><br>
Beispiel:<br>
Ein Raspberry Pi GPIO besitzt ein Attribut poll_interval, dieses wird z.B. auf 10 Minuten gesetzt.<br>
Dann werden die Readings alle 10 Minuten aktualisiert. Bei konstantem Wert wird nach 1 Stunde und maximal 10 Minuten ein Event gesendet.
|-
|.*
|nicht gesetzt
|.*:3600
|TODO
|-
|nicht gesetzt
|nicht gesetzt
|.*:3600
|TODO
|}

== Beispiele ==
Um alle Readings eines Gerätes bei Aktualisierungen zu protokollieren, sollte das Attribut folgendermaßen gesetzt werden:
:<code><nowiki>attr <device> event-min-interval .*:3600</nowiki></code>

== Siehe auch ==
*[[event-on-update-reading]]
*[[event-on-change-reading]]
*[[event-min-interval]]

== Links ==
*

[[Kategorie:Attribut (allgemeingültig)]]

2017-10-20T13:28:35Z

Markus1407: Die Seite wurde neu angelegt: „{{Infobox Modul |ModPurpose=I2C_LCD dient zum ansteuern von LCD Displays am I2C Bus. |ModType=h |ModCmdRef=I2C_LCD |ModForumArea= |ModTechName=52_I2C_LCD.pm |M…“

{{Infobox Modul
|ModPurpose=I2C_LCD dient zum ansteuern von LCD Displays am I2C Bus.
|ModType=h
|ModCmdRef=I2C_LCD
|ModForumArea=
|ModTechName=52_I2C_LCD.pm
|ModOwner=ntruchsess}}

Das [[I2C_LCD]]-Modul bietet die Möglichkeit LCD Displays am I2C-Bus anzusteuern.

== Hinweise zur Benutzung ==

Standardmässig wird der Text rechtsbündig ausgegeben.
Soll der Text linksbündig ausgegeben werden muss der optionale Parameter [,l] angegeben werden. (Achtung kleines "L", keine "Eins".)

set <name> writeXY x-pos,y-pos,len'''[,l]''' <text to be displayed>

== Beispiel ==

[[Kategorie:Other Components]]

DLCD

2017-10-20T13:10:02Z

Markus1407:

{{Infobox Modul
|ModPurpose=Daten sammeln und formatiert auf LCD ausgeben
|ModType=x
|ModCmdRef= ---- noch nicht Teil von FHEM ----
|ModForumArea=Codeschnipsel
|ModTechName=39_DLCD.pm
|ModOwner=epsrw1 ([http://forum.fhem.de/index.php?action=profile;u=6340 Forum] / [[Benutzer Diskussion:Epsrw1|Wiki]])}}

Das [[DLCD]]-Modul bietet eine einfache Möglichkeit, Daten zu sammeln und für die Anzeige auf einem seriellen LCD aufzubereiten.

== Features ==
'''''Diese Wiki-Seite beschreibt den Versionsstand 2.0 des DLCD-Moduls.'''''

Thread im {{Link2Forum|Topic=24519|LinkText=Fhem-Forum}} mit der jeweils aktuellen Version des Moduls als Anhang im ersten Beitrag.

== Beschreibung ==
[[Datei:dok39_DLCD.jpg|mini|Funktionsweise]]

DLCD bietet als kleines Helferlein die Möglichkeit, Textzeilen eines LCD Displays als Readings vorzubereiten und mit Daten frei konfigurierbarer Readings zu befüllen.
DLCD baut z.B. auf einer Instanz des Moduls [[I2C_LCD]] auf.

Jede Zeile wird als Attr vordefiniert, und mit Platzhaltern (z.B.: %1%) für die einzutragenden Werte versehen.

Die Liste aller einzulesenden Devices:Readings wird in einem attr eingestellt. Das Modul prüft dann regelmäßig (attr: poll interval) die Daten der Fhem-Devices
und aktualisiert dann die Anzeige sobald sich einer der Werte geändert hat.

Zusätzlich können Zahlen einfach über attr formatiert werden (Kommastellen, Rundung, Anzeige von + und - Zeichen).

Eine Reihe von Platzhaltern ermöglicht das Einsetzen von Datum und Zeit-Werten in die Ausgabezeilen (zB Minute einzeln, Wochentag, Datum, ....)

Die über attr einschaltbare Rollierfunktion verschiebt die Zeilen bei jedem Update um eine Ziffer nach oben. So läßt sich zB eine wechselanzeige auf einem einzeiligen Display realisieren.

Die eigentliche Ausgabe auf das LCD erfolgt jeweils immer dann wenn eine Änderung der Daten festgestellt wird, auf beliebiges konfigurierbares Device. Zum beispiel I2C LCD über FHEM, oder auch über shell-command für nicht von FHEM unterstützte displays.

Manche Displays können Leerzeichen oder Umlaute nicht richtig wiedergeben. Daher kann DLCD über attr eingestellte Ersetzungen vornehmen, bevor die Daten an das LCD-device übergeben werden.

Um die Einrichtung zu erleichtern, kann man mit dem attr dlcdDebugOutput die jeweils an das Device abgesetzten Befehle als ''reading'' ausgeben lassen.

Mit stateFormat state<br>Line1<br>Line2<br>Line3<br>Line4 kann man sich ein Abbild des Displayinhaltes im Web-frontend anzeigen lassen.

[[Datei:dlcd_stateformat.png|mini|Frontend-Beispiel]]

== Define ==
:<code>define <name> DLCD </code>

''In der Basisversion wurde Number::Format von cpan benötigt. Dies ist ab v. 1.1. nicht mehr der Fall.''

== Attribute ==
Alle Attribute sind auch in fhem durch das Kommando get attrHelp <varname> erklärt, für's "schnelle Nachschauen zwischendurch".

* dlcdRows -> Anzahl Datenzeilen (kann mehr als am Display sein mit eingeschaltetem Scrolling)
* dlcdCols -> Anzahl Spalten des LC-Displays
* dlcdPollInterval -> Zeitintervall, nach dem FHEM versucht, die Daten zu aktualisieren
* dlcdLine1 -> Formatvorlage für LCD-Zeile z.B.: text: %1% text: %2%
* dlcdLine2 -> Formatvorlage für LCD-Zeile z.B.: text: %3% text: %4%
* dlcdLine3 -> Formatvorlage für LCD-Zeile z.B.: text: %5% text: %6%
* dlcdLine4 -> Formatvorlage für LCD-Zeile Text: %7% text: %8%
* dlcdLine5 -> Formatvorlage für LCD-Zeile Text: %11% text: %12%
* dlcdVal1 -> Quelle für den Wert %1% im Format: FhemDev:reading
* dlcdVal2 -> Quelle für den Wert %2% im Format: FhemDev:reading
* dlcdVal3 -> Quelle für den Wert %3% im Format: FhemDev:reading
* ...
* dlcdVal20 -> Quelle für den Wert %12% im Format: FhemDev:reading

* dlcdTriggerCmd -> Fhem-Befehl zum Schreiben einer LCD-Zeile, z.B.: <code>set lcd_wand writeXY 0,%L%,20,1 %T%</code>
* dlcdVal1formatnum -> Zahlenformatierung für Wert %1%, muss none sein bei Nicht-Zahl
* dlcdVal2formatnum -> Zahlenformatierung für Wert %1%, muss none sein bei Nicht-Zahl
* dlcdVal3formatnum -> Zahlenformatierung für Wert %1%, muss none sein bei Nicht-Zahl
* ...
* dlcdVal20formatnum -> Zahlenformatierung für Wert %1%, muss none sein bei Nicht-Zahl

-----

dlcdVal .. formatnum setzen die Anzahl Dezimalstellen fest, sowie ob ein + bzw. - Zeichen vorangestellt wird. Es funktioniert wie folgt:

erste Ziffer: Gesamtzahl Ziffern in der Ausgabe.
zweite Ziffer: Anzahl fester Dezimalstellen
optional: +- an dritter Stelle

Beispiele:
2+1 -> 1.1 9.0 0.4
4+2+- -> -12.34 +10.50
4+0+- -> -0012 +0010

Die möglichen Optionen sind in einer Liste fest vorgegeben, um Fehleinstellungen zu vermeiden. Über manuellen Eintrag in der fhem-config können Eigenkreationen eingestellt werden, die nicht in der Liste enthalten sind (zB. 10+2+-).

-----

* dlcdVal1formatstring -> benutzerdefinierter sprintf format pattern, setzt formatnum außer kraft. zB: %03f
* dlcdVal2formatstring -> benutzerdefinierter sprintf format pattern, setzt formatnum außer kraft. zB: %03f
* dlcdVal3formatstring -> benutzerdefinierter sprintf format pattern, setzt formatnum außer kraft. zB: %03f
* ...
* dlcdVal20formatstring -> benutzerdefinierter sprintf format pattern, setzt formatnum außer kraft. zB: %03f

* dlcdBlankspaceReplace -> Leerzeichen wird im dlcdTriggerCmd durch diesen attr-Wert ersetzt. z.B.: \\x20 oder \\x{10}
* dlcdReplaceRegex -> beliebige ersetzung von zeichen, kommagetrennte paare mit = zeichen, zB.: ä=\\xE1,ö=\\xEF,ü=\\xF5,Ä=\\xE1,Ö=\\xEF,Ü=\\xF5,ß=\\xE2,°=\\x{DF}, Unicode-Beispiel: \N{U+code}, zB \N{U+0041}und \N{U+41} werden zu A und A
* dlcdPhysicalRows -> Anzahl physikalisch vorhandener Zeilen am Ausgabedisplay
* dlcdScrolling -> Zeilen automatisch scrollen, 1=an 0=aus
* dlcdDebugOutput -> zusätzliche readings für aktuelle Display-ausgabe zum testen der Scroll-Funktion
* dlcdClearLineCmd -> optional: command um lcd-zeile zu leeren (%L%=line 0-n), zB. Set lcd42 clear %L%
* dlcdClearAllCmd -> optional: command um lcd komplett zu leeren (nur bei scrolling)
* dlcdLineAddrMap -> alternative Zeilenadressierung. Default ist 0,1,2,3,4,5,6,7,8,9. Beispiel: 1,2,3 verwendet nur 2. bis 4. LCD-zeile und überspringt die erste.
* disable -> keine neuen schreibvorgänge

== Settings ==
reset ->alle Readings zurücksetzen

== Readings ==
Line1 -> Aktuelle Anzeige der Zeile 1

Line2 -> Aktuelle Anzeige der Zeile 2

Line3 -> Aktuelle Anzeige der Zeile 3

Line4 -> Aktuelle Anzeige der Zeile 4

Line5 -> Aktuelle Anzeige der Zeile 5

== Spezielle Anzeigefunktionen ==

Datum und Uhrzeit basieren aktuell auf der Systemzeit des FHEM-Servers. Eine Möglichkeit, als Zeitbasis den Timestamp eines FHEM-Readings zu verwenden, ist denkbar; wer das nutzen möchte, bitte im Forum melden.

=== Datum ===
* %date_Y% --> Jaheszahl 4-stellig
* %date_y% --> Jahreszahl 2-stellig
* %date_M% --> Monat als Zahl, 2-stellig
* %date_M_eng% --> Monat, Abkürzung englisch
* %date_M_ger% --> Monat, Abkürzung deutsch
* %date_D% --> Tag des Monats 2-stellig
* %date_WD% --> Wochentag 1-stellig im Format 0(So) ... 6(Sa)
* %date_WD_eng% --> Wochentag, Abkürzung englisch
* %date_WD_ger% --> Wochentag, Abkürzung deutsch
* %date_dmy% --> Datum im Format 25.08.2014

=== Zeit ===
* %time_hms% --> HH:MM:SS Uhrzeit
* %time_h% --> Stunde
* %time_m% --> Minute
* %time_s% --> Sekunde

=== LCD-Abbild im Web-frontend ===
attr <name> stateFormat state<br>Line1<br>Line2<br>Line3<br>Line4<br>Line5

=== Mathematische Werteberechnung ===
* Noch in Arbeit - Ideen sind willkommen ;) --> Forum
* To be continued

== Weblinks ==
* {{Link2Forum|Topic=24519|LinkText=Thread}} im Forum, in dem dieses Modul vorgestellt wurde
* [https://waschto.eu/statusdisplay-mit-esp-easy-dlcd-und-fhem/ Projekt: Statusdisplay mit ESP Easy und DLCD]
* ...

[[Kategorie:Other Components]]

DLCD

2017-10-20T13:08:59Z

Markus1407: /* Beschreibung */

{{Infobox Modul
|ModPurpose=Daten sammeln und formatiert auf LCD ausgeben
|ModType=x
|ModCmdRef= ---- noch nicht Teil von FHEM ----
|ModForumArea=Codeschnipsel
|ModTechName=39_DLCD.pm
|ModOwner=epsrw1 ([http://forum.fhem.de/index.php?action=profile;u=6340 Forum] / [[Benutzer Diskussion:Epsrw1|Wiki]])}}

Das [[DLCD]]-Modul bietet eine einfache Möglichkeit, Daten zu sammeln und für die Anzeige auf einem seriellen LCD aufzubereiten.

== Features ==
'''''Diese Wiki-Seite beschreibt den Versionsstand 2.0 des DLCD-Moduls.'''''

Thread im {{Link2Forum|Topic=24519|LinkText=Fhem-Forum}} mit der jeweils aktuellen Version des Moduls als Anhang im ersten Beitrag.

== Beschreibung ==
[[Datei:dok39_DLCD.jpg|mini|Funktionsweise]]

DLCD bietet als kleines Helferlein die Möglichkeit, Textzeilen eines LCD Displays als Readings vorzubereiten und mit Daten frei konfigurierbarer Readings zu befüllen.
DLCD baut z.B. auf einer Instanz des Moduls I2C_LCD auf.

Jede Zeile wird als Attr vordefiniert, und mit Platzhaltern (z.B.: %1%) für die einzutragenden Werte versehen.

Die Liste aller einzulesenden Devices:Readings wird in einem attr eingestellt. Das Modul prüft dann regelmäßig (attr: poll interval) die Daten der Fhem-Devices
und aktualisiert dann die Anzeige sobald sich einer der Werte geändert hat.

Zusätzlich können Zahlen einfach über attr formatiert werden (Kommastellen, Rundung, Anzeige von + und - Zeichen).

Eine Reihe von Platzhaltern ermöglicht das Einsetzen von Datum und Zeit-Werten in die Ausgabezeilen (zB Minute einzeln, Wochentag, Datum, ....)

Die über attr einschaltbare Rollierfunktion verschiebt die Zeilen bei jedem Update um eine Ziffer nach oben. So läßt sich zB eine wechselanzeige auf einem einzeiligen Display realisieren.

Die eigentliche Ausgabe auf das LCD erfolgt jeweils immer dann wenn eine Änderung der Daten festgestellt wird, auf beliebiges konfigurierbares Device. Zum beispiel I2C LCD über FHEM, oder auch über shell-command für nicht von FHEM unterstützte displays.

Manche Displays können Leerzeichen oder Umlaute nicht richtig wiedergeben. Daher kann DLCD über attr eingestellte Ersetzungen vornehmen, bevor die Daten an das LCD-device übergeben werden.

Um die Einrichtung zu erleichtern, kann man mit dem attr dlcdDebugOutput die jeweils an das Device abgesetzten Befehle als ''reading'' ausgeben lassen.

Mit stateFormat state<br>Line1<br>Line2<br>Line3<br>Line4 kann man sich ein Abbild des Displayinhaltes im Web-frontend anzeigen lassen.

[[Datei:dlcd_stateformat.png|mini|Frontend-Beispiel]]

== Define ==
:<code>define <name> DLCD </code>

''In der Basisversion wurde Number::Format von cpan benötigt. Dies ist ab v. 1.1. nicht mehr der Fall.''

== Attribute ==
Alle Attribute sind auch in fhem durch das Kommando get attrHelp <varname> erklärt, für's "schnelle Nachschauen zwischendurch".

* dlcdRows -> Anzahl Datenzeilen (kann mehr als am Display sein mit eingeschaltetem Scrolling)
* dlcdCols -> Anzahl Spalten des LC-Displays
* dlcdPollInterval -> Zeitintervall, nach dem FHEM versucht, die Daten zu aktualisieren
* dlcdLine1 -> Formatvorlage für LCD-Zeile z.B.: text: %1% text: %2%
* dlcdLine2 -> Formatvorlage für LCD-Zeile z.B.: text: %3% text: %4%
* dlcdLine3 -> Formatvorlage für LCD-Zeile z.B.: text: %5% text: %6%
* dlcdLine4 -> Formatvorlage für LCD-Zeile Text: %7% text: %8%
* dlcdLine5 -> Formatvorlage für LCD-Zeile Text: %11% text: %12%
* dlcdVal1 -> Quelle für den Wert %1% im Format: FhemDev:reading
* dlcdVal2 -> Quelle für den Wert %2% im Format: FhemDev:reading
* dlcdVal3 -> Quelle für den Wert %3% im Format: FhemDev:reading
* ...
* dlcdVal20 -> Quelle für den Wert %12% im Format: FhemDev:reading

* dlcdTriggerCmd -> Fhem-Befehl zum Schreiben einer LCD-Zeile, z.B.: <code>set lcd_wand writeXY 0,%L%,20,1 %T%</code>
* dlcdVal1formatnum -> Zahlenformatierung für Wert %1%, muss none sein bei Nicht-Zahl
* dlcdVal2formatnum -> Zahlenformatierung für Wert %1%, muss none sein bei Nicht-Zahl
* dlcdVal3formatnum -> Zahlenformatierung für Wert %1%, muss none sein bei Nicht-Zahl
* ...
* dlcdVal20formatnum -> Zahlenformatierung für Wert %1%, muss none sein bei Nicht-Zahl

-----

dlcdVal .. formatnum setzen die Anzahl Dezimalstellen fest, sowie ob ein + bzw. - Zeichen vorangestellt wird. Es funktioniert wie folgt:

erste Ziffer: Gesamtzahl Ziffern in der Ausgabe.
zweite Ziffer: Anzahl fester Dezimalstellen
optional: +- an dritter Stelle

Beispiele:
2+1 -> 1.1 9.0 0.4
4+2+- -> -12.34 +10.50
4+0+- -> -0012 +0010

Die möglichen Optionen sind in einer Liste fest vorgegeben, um Fehleinstellungen zu vermeiden. Über manuellen Eintrag in der fhem-config können Eigenkreationen eingestellt werden, die nicht in der Liste enthalten sind (zB. 10+2+-).

-----

* dlcdVal1formatstring -> benutzerdefinierter sprintf format pattern, setzt formatnum außer kraft. zB: %03f
* dlcdVal2formatstring -> benutzerdefinierter sprintf format pattern, setzt formatnum außer kraft. zB: %03f
* dlcdVal3formatstring -> benutzerdefinierter sprintf format pattern, setzt formatnum außer kraft. zB: %03f
* ...
* dlcdVal20formatstring -> benutzerdefinierter sprintf format pattern, setzt formatnum außer kraft. zB: %03f

* dlcdBlankspaceReplace -> Leerzeichen wird im dlcdTriggerCmd durch diesen attr-Wert ersetzt. z.B.: \\x20 oder \\x{10}
* dlcdReplaceRegex -> beliebige ersetzung von zeichen, kommagetrennte paare mit = zeichen, zB.: ä=\\xE1,ö=\\xEF,ü=\\xF5,Ä=\\xE1,Ö=\\xEF,Ü=\\xF5,ß=\\xE2,°=\\x{DF}, Unicode-Beispiel: \N{U+code}, zB \N{U+0041}und \N{U+41} werden zu A und A
* dlcdPhysicalRows -> Anzahl physikalisch vorhandener Zeilen am Ausgabedisplay
* dlcdScrolling -> Zeilen automatisch scrollen, 1=an 0=aus
* dlcdDebugOutput -> zusätzliche readings für aktuelle Display-ausgabe zum testen der Scroll-Funktion
* dlcdClearLineCmd -> optional: command um lcd-zeile zu leeren (%L%=line 0-n), zB. Set lcd42 clear %L%
* dlcdClearAllCmd -> optional: command um lcd komplett zu leeren (nur bei scrolling)
* dlcdLineAddrMap -> alternative Zeilenadressierung. Default ist 0,1,2,3,4,5,6,7,8,9. Beispiel: 1,2,3 verwendet nur 2. bis 4. LCD-zeile und überspringt die erste.
* disable -> keine neuen schreibvorgänge

== Settings ==
reset ->alle Readings zurücksetzen

== Readings ==
Line1 -> Aktuelle Anzeige der Zeile 1

Line2 -> Aktuelle Anzeige der Zeile 2

Line3 -> Aktuelle Anzeige der Zeile 3

Line4 -> Aktuelle Anzeige der Zeile 4

Line5 -> Aktuelle Anzeige der Zeile 5

== Spezielle Anzeigefunktionen ==

Datum und Uhrzeit basieren aktuell auf der Systemzeit des FHEM-Servers. Eine Möglichkeit, als Zeitbasis den Timestamp eines FHEM-Readings zu verwenden, ist denkbar; wer das nutzen möchte, bitte im Forum melden.

=== Datum ===
* %date_Y% --> Jaheszahl 4-stellig
* %date_y% --> Jahreszahl 2-stellig
* %date_M% --> Monat als Zahl, 2-stellig
* %date_M_eng% --> Monat, Abkürzung englisch
* %date_M_ger% --> Monat, Abkürzung deutsch
* %date_D% --> Tag des Monats 2-stellig
* %date_WD% --> Wochentag 1-stellig im Format 0(So) ... 6(Sa)
* %date_WD_eng% --> Wochentag, Abkürzung englisch
* %date_WD_ger% --> Wochentag, Abkürzung deutsch
* %date_dmy% --> Datum im Format 25.08.2014

=== Zeit ===
* %time_hms% --> HH:MM:SS Uhrzeit
* %time_h% --> Stunde
* %time_m% --> Minute
* %time_s% --> Sekunde

=== LCD-Abbild im Web-frontend ===
attr <name> stateFormat state<br>Line1<br>Line2<br>Line3<br>Line4<br>Line5

=== Mathematische Werteberechnung ===
* Noch in Arbeit - Ideen sind willkommen ;) --> Forum
* To be continued

== Weblinks ==
* {{Link2Forum|Topic=24519|LinkText=Thread}} im Forum, in dem dieses Modul vorgestellt wurde
* [https://waschto.eu/statusdisplay-mit-esp-easy-dlcd-und-fhem/ Projekt: Statusdisplay mit ESP Easy und DLCD]
* ...

[[Kategorie:Other Components]]