FHEMWiki - Benutzerbeiträge [de]

Wetter und Wettervorhersagen

2021-01-11T13:56:52Z

Mahowi: /* Eigene Wetterdaten hochladen */ Link zur API-Doku bei archive.org

Wetterdaten und Wettervorhersagen können auf verschiedene Weise in FHEM eingebunden werden.

== Yahoo-Wetter ==
Für die einfache Einbindung des Yahoo-Wetters gibt es das spezielle Modul [[Weather]].
Da die Yahoo Weather API zum 03.01.2019 abgeschaltet wurde, kann Weather keine Wetterdaten von Yahoo mehr beziehen!

== Unwetterzentrale ==
Informationen der Seite(n) Unwetterzentrale.de können mit Hilfe des Moduls [[UWZ]] eingebunden werden.

== Modul OPENWEATHER ==
Das Modul [[OPENWEATHER]] extrahiert Wetterdaten über die "openweather"-Schnittstelle (API) von www.wetter.com.
*Vorschau-Zeitraum: 3 Tage
*Vorschau-Interval: 6:00, 11:00, 17:00, 23:00
*Aktuelle Daten: keine

== Modul PROPLANTA ==
Das Modul [[PROPLANTA]] extrahiert Wetterdaten von der Website www.proplanta.de. (keine API)
*Vorschau-Zeitraum: 12 Tage
*Vorschau-Interval: 3 h
*Aktuelle Daten: jede volle Stunde

== Modul WWO ==
Das Modul extrahiert Wetterdaten über die (alte) API von worldweatheronline.com
*Vorschau-Zeitraum: ?? Tage<BR>
*Vorschau-Interval: ??<br>
*Aktuelle Daten: ??

== Deutscher Wetterdienst (DWD) ==

=== Modul DWD_OpenData ===
Das Modul [[DWD_OpenData]] stellt einen Teil der frei verfügbaren Daten des Deutschen Wetterdienstes (DWD) bereit, die über den [https://www.dwd.de/DE/leistungen/opendata/opendata.html Open Data Server] abgerufen werden können (diverse Datenformate, keine API).
*Vorschau-Zeitraum: 10 Tage
*Vorschau-Interval: datenabhängig, viele mit 3 h
*Vorschau-Orte: national und international
*Aktuelle Daten: nicht implementiert
*Wetterwarnungen: für Landkreise und Gemeinden in deutsch oder englisch

Es gibt zum Modul auch einen Weblink für [[FHEMWEB]], der 2 Icons pro Tag in horizontaler Form darstellt. Die Anzahl der insgesamt dargestellten Icons ist konfigurierbar. Liegen Wetterwarnungen vor, wird zusätzlich ein Warnsymbol angezeigt, über das man per Klick weitere Details zur Wetterwarnung abrufen kann.

[[DWD_OpenData|Weitere Details und Installationsbeschreibung]]

=== Wetterwarnungen als Karte ===
Der Deutsche Wetterdienst [http://www.dwd.de DWD] stellt neben diversen Wetterdaten auch Wetterwarnungen in Bildform bereit. Diese können sehr einfach via [http://fhem.de/commandref_DE.html#weblink weblink iframe] in FHEM eingebunden werden - das ist zwar nicht die schönste Form, aber die schnellste.

Dazu sucht man sich zuerst auf der [http://www.dwd.de/bvbw/appmanager/bvbw/dwdwwwDesktop?_nfpb=true&_pageLabel=_dwdwww_wetter_warnungen_warnungen&T92053gsbDocumentPath=BEA__Navigation%2FWetter__Warnungen%2FWarnungen.html%3F__nnn%3Dtrue&lastPageLabel=dwdwww_wetter_warnungen Warnungsseite des DWD] die eigene Region heraus (in der Karte durchklicken). Die gewünschte URL für Berlin Stadt ist z.B. <code>http://www.dwd.de/dyn/app/ws/html/reports/BXX_warning_de.html#WS_ANCHOR_0</code>. Das Anhängsel <code>#WS_ANCHOR_0</code> kann man in der Konfiguration auch weglassen.

Die Einbindung in FHEM sieht dann wie folgt aus:
<pre>
define dwd_warnmeldung weblink iframe http://www.dwd.de/dyn/app/ws/html/reports/BXX_warning_de.html
attr dwd_warnmeldung group Wetterwarnungen (DWD)
attr dwd_warnmeldung htmlattr width="100%" height="300" frameborder="0" marginheight="0" marginwidth="0"
attr dwd_warnmeldung room Wettervorhersage,Startseite
</pre>

== Vorhersage-Diagramm von YR ==
[http://www.yr.no YR] ist die Seite des norwegischen Wetterdiensts. Er ist zwar nur in Teilen auf Englisch (und gar nicht auf Deutsch) verfügbar, bietet aber sehr gute Wettervorhersagen - auch mit eigenen Vorhersagen für kleine Dörfer. Neben etlichen Detailinfos bietet YR eine sehr schicke 48h-Vorhersage-Grafik. Diese kann sehr einfach via [http://fhem.de/commandref_DE.html#weblink weblink iframe] in FHEM eingebunden werden.

Dazu geht man auf die [http://www.yr.no Startseite von YR] und gibt in das Suchfeld den Namen seines Dörfchens ein - die Ergebnissliste kann ziemlich lang werden, sodass man evtl. sehr genau schauen muss, welches das eigene Kaff ist - bei mir war es an 29. Stelle... ;-) Auf der gewünschten Seite gibt es einen Unterpunkt "Hour by hour", wo sich die besagte Grafik findet. Hier kopiert man sich einfach die URL der Grafik.

Die Einbindung in FHEM sieht dann bspw. wie folgt aus:
<pre>
define Wetter_yr_Vorhersage weblink iframe http://www.yr.no/place/Germany/Berlin/Berlin/meteogram.png
attr Wetter_yr_Vorhersage group Wettervorhersage (yr)
attr Wetter_yr_Vorhersage htmlattr width="100%" height="300" frameborder="0" marginheight="0" marginwidth="0"
attr Wetter_yr_Vorhersage room Wettervorhersage,Start
</pre>

== Wetter von Weather Underground ==
{{Randnotiz|RNTyp=r|RNText=Das ("offene") API von Weather Underground wird derzeit (März 2019) "retired" = abgestellt, ist also künftig nicht mehr nutzbar! Den benötigten API-Key bekommen "nur noch" Betreiber einer Wetterstation, die diese bei wundergound registrieren und ihre Daten hochladen.}}
'''Hinweis:''' Die hier beschriebene Vorgehensweise ist etwas anspruchsvoller und somit eher für erfahrene FHEM-User geeignet.

[http://www.wunderground.com/ Weather Underground] bietet eine sehr umfassende Sammlung aller möglichen offiziellen und privaten (aber teils sehr professionellen) Wetterstationen weltweit. Es besteht eine recht hohe Wahrscheinlichkeit, dass es in der eigenen Umgebung schon eine Wetterstation gibt. Anstatt nun selbst eine komplette Wetterstation aufzubauen, kann man alternativ auf die Daten der Nachbarstation zugreifen.

{{Randnotiz|RNTyp=y|RNText=Neben dem hier vorgestellten Abruf der Weather Underground-Daten mit [[HTTPMOD]] kann auf Weather Underground-Daten auch mit dem darauf spezialisierten Modul [http://fhem.de/commandref.html#Wunderground Wunderground] zugegriffen werden.}}

Dazu sind grundsätzlich die folgenden Schritte notwendig:
* Finden der geeigneten Station
* Auswerten der XML-Daten
* Erstellen passender gplot-Dateien

=== Finden der geeigneten Station ===
Als erstes geht man auf die [http://www.wunderground.com Startseite von Weather Underground] und gibt in das Suchfeld den Namen seines Dörfchens oder der nächsten Stadt ein - für Berlin landet man bspw. auf Seite für "Berlin Alexanderplatz". Es gibt aber manchmal sehr viele Wetterstationen in der direkten Umgebung. Diese findet man indem am auf "Change Station" klickt und sich eine passende Station aussucht. Nähere Infos (zB. zur verwendeten Hard- und Software) zu der gewählten Wetterstation erhält man, wenn man auf den Namen der Station klickt und dann auf "About this PWS".

Weather Underground stellt die Daten der Wetterstation auch über eine API als XML bereit, die wir auswerten können. Die entsprechende URL findet sich ebenfalls unter "About this PWS" unter "Download current conditions XML". Für Berlin Prenzlauer Berg wäre dies z.B.
<code>http://api.wunderground.com/weatherstation/WXDailyHistory.asp?ID=IBERLIN15&format=XML</code>.

Entscheidend für die jeweilige Station ist der Teil nach "?=ID", also in diesem Fall "IBERLIN15". Dieser Teil des Links lässt sich leicht durch die ID einer anderen Station ersetzen und die Suche nach dem entsprechenden Link auf der Seite der Station bleibt erspart.

=== Auswerten der XML-Daten ===
Die Auswertung der XML-Daten erfolgt via [[HTTPMOD]]. Da dies nicht ganz trivial ist, sind im Folgenden zuerst die wesentlichen Konfigurationsschritte exemplarisch beschrieben. Weiter unten findet sich dann die fertige vollständige Konfiguration.

Es erstes wird das Device HTTPMOD definiert (die 600 am Schluss ist der Aktualisierungszyklus in Sekunden, also alle 10 min):
:<code>define wetter_prenzelberg HTTPMOD http://api.wunderground.com/weatherstation/WXCurrentObXML.asp?ID=IBERLIN15 600 </code>

Dann werden Attribute für alle Readings definiert:
:<code>attr wetter_prenzelberg userattr readingsName_cloudiness readingsName_date ... </code>

Dann wird jedem Attribut ein Name zugewiesen (unter diesem Namen wird der Wert ins Log geschrieben):
:<code>attr wetter_prenzelberg readingsName_cloudiness cloudiness </code>

Zum Schluss wird das Reading selbst definiert:
:<code>attr wetter_prenzelberg readingsRegex_cloudiness cloudiness id="NN" percent="([\d\.]+) </code>

Die gesamte Konfiguration für alle von der API angebotenen Wetterwerte sieht dann wie folgt aus:
<pre>
define wetter_prenzelberg HTTPMOD http://api.wunderground.com/weatherstation/WXCurrentObXML.asp?ID=IBERLIN15 600
attr wetter_prenzelberg userattr readingsName_cloudiness readingsName_date readingsName_dewpointTemperature readingsName_fog readingsName_heatindex readingsName_humidity readingsName_pressure readingsName_solarRadiation readingsName_solarUV readingsName_temperature readingsName_time readingsName_windChill readingsName_windDegrees readingsName_windDirection readingsName_windGust readingsName_windSpeed readingsRegex_cloudiness readingsRegex_date readingsRegex_dewpointTemperature readingsRegex_fog readingsRegex_heatindex readingsRegex_humidity readingsRegex_pressure readingsRegex_solarRadiation readingsRegex_solarUV readingsRegex_temperature readingsRegex_time readingsRegex_windChill readingsRegex_windDegrees readingsRegex_windDirection readingsRegex_windGust readingsRegex_windSpeed
attr wetter_prenzelberg readingsName_cloudiness cloudiness
attr wetter_prenzelberg readingsName_date date
attr wetter_prenzelberg readingsName_dewpointTemperature dewpointTemperature
attr wetter_prenzelberg readingsName_fog fog
attr wetter_prenzelberg readingsName_heatindex heatindex
attr wetter_prenzelberg readingsName_humidity humidity
attr wetter_prenzelberg readingsName_pressure pressure
attr wetter_prenzelberg readingsName_solarRadiation solarRadiation
attr wetter_prenzelberg readingsName_solarUV solarUV
attr wetter_prenzelberg readingsName_temperature temperature
attr wetter_prenzelberg readingsName_time time
attr wetter_prenzelberg readingsName_windChill windChill
attr wetter_prenzelberg readingsName_windDegrees windDegrees
attr wetter_prenzelberg readingsName_windDirection windDirection
attr wetter_prenzelberg readingsName_windGust windGust
attr wetter_prenzelberg readingsName_windSpeed windSpeed
attr wetter_prenzelberg readingsRegex_cloudiness cloudiness id="NN" percent="([\d\.]+)
attr wetter_prenzelberg readingsRegex_date date date" content="([\d\.]+)
attr wetter_prenzelberg readingsRegex_dewpointTemperature <dewpoint_c>(\+|-?[\d\.]+)
attr wetter_prenzelberg readingsRegex_fog fog id="FOG" percent="([\d\.]+)
attr wetter_prenzelberg readingsRegex_heatindex <heat_index_c>(\+|-?[\d\.]+)
attr wetter_prenzelberg readingsRegex_humidity <relative_humidity>([\d\.]+)
attr wetter_prenzelberg readingsRegex_pressure <pressure_mb>([\d\.]+)
attr wetter_prenzelberg readingsRegex_solarRadiation <solar_radiation>([\d\.]+)
attr wetter_prenzelberg readingsRegex_solarUV <UV>([\d\.]+)
attr wetter_prenzelberg readingsRegex_temperature <temp_c>(\+|-?[\d\.]+)
attr wetter_prenzelberg readingsRegex_time time Zeit([\d\:]+)
attr wetter_prenzelberg readingsRegex_windChill <windchill_c>(\+|-?[\d\.]+)
attr wetter_prenzelberg readingsRegex_windDegrees <wind_degrees>([\d\.]+)
attr wetter_prenzelberg readingsRegex_windDirection <wind_dir>([\d\.]+)
attr wetter_prenzelberg readingsRegex_windGust <wind_gust_mph>([\d\.]+)
attr wetter_prenzelberg readingsRegex_windSpeed <wind_mph>([\d\.]+)
</pre>
Hinweis: Nicht immer werden alle Werte geliefert (wenn keine Sonne, dann kein UV-Wert...). Im System-Log kann das als Fehler auftauchen, ist aber kein Problem.

=== Erstellen passender gplot-Dateien ===
Um die ausgelesenen Werte als Graphen darstellen zu können müssen eigene gplot-Dateien erstellt werden. Eine grundsätzliche Anleitung dazu findet sich unter [[Creating Plots]]. Deshalb sollen hier nur Beispiele für die eigentlichen gplot-Dateien vorgestellt werden. Beispiele sollten sowohl für [[FileLog]] wie [[DbLog]] funktionieren.

Temperatur und Luftfeuchte:
<pre>
set terminal png transparent size <SIZE> crop
set output '<OUT>.png'
set xdata time
set timefmt "%Y-%m-%d_%H:%M:%S"
set xlabel " "
#set title '<L1>'
set title ''
set ytics
set y2tics
set grid ytics
set ylabel "Temperature in C"
set y2label "Humidity (%)"

#FileLog 4:temperature\x3a::
#FileLog 4:windChill\x3a::
#FileLog 4:humidity\x3a::

#DbLog <SPEC1>:temperature::
#DbLog <SPEC1>:windChill::
#DbLog <SPEC1>:humidity::

plot "<IN>" using 1:2 axes x1y1 title 'Temperatur (C)' ls l0 lw 1.5 with lines,\
"<IN>" using 1:2 axes x1y1 title 'Gefühlte Temperatur (C)' ls l1 lw 1.5 with lines,\
"<IN>" using 1:2 axes x1y2 title 'Luftfeuchtigkeit (%)' ls l2fill lw 0.2 with lines
</pre>

Wind und Windrichtung:
<pre>
set terminal png transparent size <SIZE> crop

set output '<OUT>.png'
set xdata time
set timefmt "%Y-%m-%d_%H:%M:%S"
set xlabel " "

set ytics
set y2tics ("Nord" 0, "Ost" 80, "Süd" 180, "West" 270, "Nord" 360)

#set title '<L1>'
set title ''

set grid xtics ytics

set yrange [0:20]
set y2range [0:360]

set ylabel "Wind (mph)"
set y2label "Richtung"

#FileLog 4:windSpeed:0:
#FileLog 4:windGust:0:
#FileLog 4:windDegrees:0:

#DbLog <SPEC1>:windSpeed::
#DbLog <SPEC1>:windGust::
#DbLog <SPEC1>:windDegrees::

plot "<IN>" using 1:2 axes x1y1 title 'Wind (mph)' ls l0 lw 1.5 with lines,\
"<IN>" using 1:2 axes x1y1 title 'Böen (mph)' ls l1 lw 1.5 with lines,\
"<IN>" using 1:2 axes x1y2 title 'Windrichtung (°)' ls l2fill lw 0.2 with points
</pre>

Sonnenintensität und UV-Werte:
<pre>
set terminal png transparent size <SIZE> crop

set output '<OUT>.png'
set xdata time
set timefmt "%Y-%m-%d_%H:%M:%S"
set xlabel " "

set ytics
set y2tics

#set title '<L1>'
set title ''

set grid xtics ytics

set ylabel "Sonnenstrahlung (W/qm)"
set y2label "UV"

#FileLog 4:solarRadiation:0:
#FileLog 4:solarUV:0:

#DbLog <SPEC1>:solarRadiation::
#DbLog <SPEC1>:solarUV::

plot "<IN>" using 1:2 axes x1y1 title 'Strahlung' ls l0 lw 1.5 with lines,\
"<IN>" using 1:2 axes x1y1 title 'UV' ls l1 lw 1.5 with lines
</pre>

'''Weitere TBD'''

=== Vergangene Daten abfragen ===
Ein konkretes vergangenes Datum der Wetterstation kann man übrigens auch abrufen - für den 28.11.2014 wäre dies bspw.
<code>http://www.wunderground.com/weatherstation/WXDailyHistory.asp?ID=IBERLIN15&day=28&month=11&year=2014&graphspan=day&format=1</code>.

=== Eigene Wetterdaten hochladen ===
{{Randnotiz|RNTyp=g|RNText=Unterstützung für das Modul gibt es im dazugehörigen {{Link2Forum|Topic=65587|LinkText=Forumsthread }}.}}

Wer eigene Wetterdaten hochladen will, kann hierzu das Modul [http://fhem.de/commandref.html#WUup WUup] verwenden. Dazu benötigt man die Zugangsdaten (stationID und Paßwort) für eine eigene Wetterstation. Mit dem Modul können die meisten vom [http://web.archive.org/web/20180815041359/http://wiki.wunderground.com/index.php/PWS_-_Upload_Protocol PWS Upload Protocol] unterstützten Daten hochgeladen werden:
* Winddir - [0-360 momentane Windrichtung]
* Windspeedmph - [mph momentane Windgeschwindigkeit]
* Windgustmph - [mph aktuellen Böe, mit Software-spezifischem Zeitraum]
* Windgustdir - [0-360 mit Software-spezifischer Zeit]
* Windspdmph_avg2m - [mph durchschnittliche Windgeschwindigkeit innerhalb 2 Minuten]
* Winddir_avg2m - [0-360 durchschnittliche Windrichtung innerhalb 2 Minuten]
* Windgustmph_10m - [mph Böen der vergangenen 10 Minuten]
* Windgustdir_10m - [0-360 Richtung der Böen der letzten 10 Minuten]
* Feuchtigkeit - [% Außenfeuchtigkeit 0-100%]
* Dewptf- [F Taupunkt im Freien]
* Tempf - [F Außentemperatur]
* Rainin - [in Regen in der vergangenen Stunde]
* Dailyrainin - [in Regenmenge bisher heute]
* Baromin - [inHg barometrischer Druck]
* Soiltempf - [F Bodentemperatur]
* Bodenfeuchtigkeit - [%]
* Solarradiation - [W/m²]
* UV - [Index]
* AqPM2.5 - Feinstaub PM2,5 [µg/m³]
* AqPM10 - Feinstaub PM10 [µg/m³]

Die Werte werden im Modul für Wunderground ins anglo-amerikanische System umgerechnet. Temperaturen werden also automatisch von °Celsius in Fahrenheit, Windgeschwindigkeiten von km/h in mph, mm in Inch und der barometrische Druck von hPa in inHg umgerechnet.

== Wetternetzwerk auf wetter.com ==
Ein vollständiges Beispiel zur Nutzung der Informationen über die Regenmenge (Station 1445, Weinheim) von wetter.com ist in {{Link2Forum|Topic=39600|Message=332837|LinkText=diesem Forenbeitrag}} beschrieben.

== Wetter von netatmo ==
Das FHEM-Modul [[netatmo]] ermöglicht den Datenimport von privaten und öffentlichen netatmo Wetterstationen sowie den Abruf der in der Netatmo App verfügbaren Wettervorhersage. Eine Übersicht über die verfügbaren öffentlichen Stationen findet sich auf der Seite [http://www.netatmo.com/de-DE/weathermap Weathermap]. Die meisten öffentlichen Stationen liefern Temperatur, Luftfeuchte und Luftdruck, einige auch Wind, Regen und Daten zur Luftqualität (CO<sub>2</sub>).

== Links ==
* {{Link2Forum|Topic=33610}} mit Sammlung und Beipielen von Internet-Links für die Anzeige von teilweise animierten Wetterbildern
* [http://bloglich.de/art/rpi/wetterdaten-auf-dem-raspberry-pi-in-fhem/ Beispiel in Blog(de)]
* [[HTTPMOD]] [[Kategorie:Code Snippets]] [[Kategorie:HOWTOS]] [[Kategorie:Wetterstationen]]

UConv

2020-02-17T08:32:05Z

Mahowi: Fehler in Infobox

{{Infobox Modul
|ModPurpose=Hilfsfunktionen zur modulübergreifenden Benutzung bei der Umrechnung von Einheiten.
|ModType=h
|ModForumArea=FHEM Development
|ModTechName=UConv.pm
|ModOwner=Loredo ([http://forum.fhem.de/index.php?action=profile;u=1363 Forum] / [[Benutzer Diskussion:loredo|Wiki]])}}

[[UConv]] soll modulübergreifend Funktionen bereitstellen, um verschiedene Einheiten umzurechnen. Es wird zur Zeit von dem [[HP1000|HP1000]] Modul verwendet.

== Benutzung ==
Um die im Folgenden beschriebenen Funktionen zu nutzen, muss die Datei UConv.pm eingebunden werden. Ein Modulautor kann das durch eine
:<code>use UConv;</code>
Anweisung in seinem Modul tun.

Ein Endanwender sollte diese Anweisung in [[99 myUtils anlegen|99_myUtils]] einfügen. Die Einbindung über ein [[Notify]] mittels <code>global:INITIALIZED</code> ist zu spät, da dieses Event erst nach dem Einlesen aller Konfigurationen kommt.

Es stehen verschiedene Funktionen zur Verfügung, die alle über <code>UConv::<nowiki><Funktionsname></nowiki></code> aufgerufen werden können.
Die Datei UConv beinhaltet entsprechende Kommentare dafür, welche Einheiten eine Funktion genau umrechnet.

[[Kategorie:Development]]

UConv

2020-02-04T10:28:26Z

Mahowi: "use Uconv" für Endanwender: Einbindung in 99_myUtils statt Notify (Forum #1020858)

{{Infobox Modul
|ModPurpose=Hilfsfunktionen zur modulübergreifenden Benutzung bei der Umrechnung von Einheiten.
|ModType=h
|ModCmdRef=intro 
|ModForumArea=FHEM Development
|ModTechName=UConv.pm
|ModOwner=Loredo ([http://forum.fhem.de/index.php?action=profile;u=1363 Forum] / [[Benutzer Diskussion:loredo|Wiki]])}}

[[UConv]] soll modulübergreifend Funktionen bereitstellen, um verschiedene Einheiten umzurechnen. Es wird zur Zeit von dem [[HP1000|HP1000]] Modul verwendet.

== Benutzung ==
Um die im Folgenden beschriebenen Funktionen zu nutzen, muss die Datei UConv.pm eingebunden werden. Ein Modulautor kann das durch eine
:<code>use UConv;</code>
Anweisung in seinem Modul tun.

Ein Endanwender sollte diese Anweisung in [[99 myUtils anlegen|99_myUtils]] einfügen. Die Einbindung über ein [[Notify]] mittels <code>global:INITIALIZED</code> ist zu spät, da dieses Event erst nach dem Einlesen aller Konfigurationen kommt.

Es stehen verschiedene Funktionen zur Verfügung, die alle über <code>UConv::<nowiki><Funktionsname></nowiki></code> aufgerufen werden können.
Die Datei UConv beinhaltet entsprechende Kommentare dafür, welche Einheiten eine Funktion genau umrechnet.

[[Kategorie:Development]]

Junkers Therme Stetigregelung

2019-09-02T12:12:14Z

Mahowi: /* Ziel dieses Projektes */ fixed typos

[[Kategorie:Examples]]

=Ansteuerung einer Junkerstherme mit einer Steuerspannung von 3-22V (0-32V möglich)=

Viele Heizungsthermen haben eine Regelung über einen Kontakt, an dem eine feste Spannung anliegt oder eben nicht anliegt. Also als Beispiel: 0V Heizung aus – 12V Heizung an, es gibt keine weiteren Zwischenstufen. Für diese Thermen ist diese Anleitung unzweckmäßig.
Bei einigen Junkersthermen ist dies jedoch anders 3V => 0% bis 22V => 100%. Es sind beliebige Zwischenwerte möglich. Ob man eine solche Heizung hat, kann man einfach feststellen in dem man die Steuerspannung bei angeschlossenem Regler misst. Junkers nennt diese Regler auch Raumtemperaturregler mit Stetigausgang.
Beobachtung (kein Wissen): Über diese Steuerspannung wird der Brenner in Abhängigkeit vom Rücklauf gesteuert. Umso niedriger die Steuerspannung desto später (tiefere Rücklauftemperatur) beginnt die Therme zu heizen. Bei der vorhandenen Junkertherme kann die Vorlauftemperatur nicht über die Steuerspannung eingestellt werden.

==Ziel dieses Projektes==

<ul>
<li>Keine Veränderung der Therme (Sicherheits-, Versicherungs-, Garantie-Gründe)</li>
<li>Sicher: Für den Fall eines Defekts der automatischen Steuerung soll der alte Regler erhalten bleiben</li>
<li>Erzeugen einer Spannung von 3-22 Volt (Simulation des bisherigen Raumtemperaturreglers)</li>
<li>Messung der Vorlauf- und Rücklauftemperatur</li>
<li>Günstig</li>
<li>Geringe Energieaufnahme</li>
<li>Ansteuerung mittels Netzwerk</li>
<li>Integration in FHEM</li>
</ul>

==Umsetzung==

<ul>
<li>Pollin AVR-NET-IO-Board</li>
<li>Software: Ethersex</li>
<li>kleine Zusatzplatine für die Spannungserzeugung (wird einfach parallel zu dem bestehenden Regler angeschlossen)</li>
<li>Messung der Vorlauf und Rücklauftemperatur mittels OneWire</li>
</ul>

==Vorbereitung 1==
[[File:Junkers_Therme_Stetigregelung_analoge_Anzeige.JPG|120px|right|thumb|Steuersignal]]
Da die Heizungsregelung eine sehr sensible Sache ist besonders bezüglich Frostschäden (beim Ausfall der automatischen Steuerung) und persönlicher Befindlichkeiten musste eine einfache und extrem ausfallsichere Kontrolleinheit her. Hierfür wird einfaches Drehspulmessinstrument verwendet. Anzeigewerte: 0V=Fehler, 3V=Heizung aus, 22V=Therme 100%.
Der alte Raumtemperaturregler ist weiterhin aktiv, momentan ist er auf 12°C Solltemperatur gestellt. Das bedeutet:
<ol>
<li>Wenn die automatische Reglung ausfällt, aktiviert der alte Raumtemperaturregler die Heizung bevor Frostschäden entstehen können.</li>
<li>Wenn die automatische Reglung ausfällt, kann die Therme einfach durch einstellen einer neuen Solltemperatur aktiviert werden.</li>
</ol>
Beide Fälle sind auf Grund von Ausfällen eines anderen FHEM-Systems im ersten Winter aufgetreten.

==Vorbereitung 2==
<p>
[[File:Junkers Therme Stetigregelung Signalverteiler.JPG|80px|right|thumb|Steuersignal]]
Die Leitung zu dem bisherigen Regler muss gesplittet werden. Hierfür die Heizung ausschalten (Sicherung auslösen) die Leitung auftrennen und einen Abzweig für die neue Regelung einfügen. Das Ganze kann mit einer Schmelzsicherung (für die 24V VCC Leitung) und einem 3poligem-Schalter (vollständiges Wegschalten der automatischen Regelung) versehen werden.
</p>

==Vorbereitung 3==
<p>
Netzwerk zu der Therme oder das Steuersignal zum Netzwerk ziehen. Das AVR-NET-IO-Board kann irgendwo in die Steuersignal-Leitung eingesetzt werden. Theoretisch kann auch die 24V Spannungsversorgung für den ursprünglichen Raumtemperaturregler verwendet werden. Hier muss einfach ein DC/DC-Wandler eingesetzt werden. (Bitte Leistungsabgabe der Heizung und Leistungsaufnahme des AVR-NET-IO-Board überprüfen)
</p>

==Digital-to-Analog-Converter==

Die Schaltung besteht aus einem DAC (LTC1257) und einem Operationsverstärker (LM358). Der LTC1257 wandelt (bei interner Referenzspannung) einen digital übermittelten Wert (über die Eingänge CLK, DIN und LOAD) in eine Spannung von 0-2,048V. Diese Spannung wird anschließend von dem LM358 erhöht. Die Elemente R1,R2, C1 und C2 gehören zur Grundbeschaltung des LTC1257. Mittels der Widerstände R3 und R4 wird der Verstärkungsfaktor der Operationsverstärkerschaltung eingestellt. Der OP ist als nicht invertierender Verstärker ausgeführt. Mit zwei Widerständen könnte aus dem LM358 eine doppelte invertierende Verstärkerschaltung (in Reihe geschaltete) aufgebaut werden. Das würde die Genauigkeit erhöhen. Die Schaltung funktioniert jedoch einwandfrei und eine höhere Genauigkeit wird vermutlich nur selten einen Vorteil bieten.
In diesem Fall ist hat VCC_Therme eine Spannung von 24V. Der LM358 kann bis 32V arbeiten, dann muss jedoch der Widerstandswert von R4 erhöht werden. An dem Steuersignal_Therme liegt je nach dem welchen Wert der LTC1257 gerade in einen anlogen Wert umsetzt, eine Spannung von 0-24V. Diese Schaltung kann eingesetzt werden, um Junkers-Thermen mit „Stetigeingang“ anzusteuern.

Die Beschaltung mit C1 und R1 scheint nicht in jedem Fall angemessen zu sein. Damit kann man sich einen Sägezahn als Referenzspannung einfangen, der im Kilohertzbereich die Referenz- (und damit auch die DAC-Ausgangspannung) von 100 % auf ca. 90 % fährt. Das gibt dann unerwünschte Effekte beim Messen der Spannung für die Stetigregelung. Ohne C1 und R1 ergibt sich eine konstante Referenzspannung.

[[File:Junkers_Therme_Stetigregelung_0MP.png|center|alt=Variante 1 - keine Messpunkte]]

Variant 2: Die Ausgangsspannung der Schaltung kann zwischen dem Widerstand R3 und R4 von einem ADC gemessen werden. Da an R4 über 90% der Spannung abfällt, kann die Messung problemlos mittels eines 5V ADCs erfolgen.

[[File:Junkers_Therme_Stetigregelung_1MP.jpg|center|alt=Variante 2 - ein Messpunkt]]

In der Varianten 3 ist eine Sicherheitsfunktion eingebaut, die durchaus sinnvoll ist. Die Diode D1 verhindert, dass diese Schaltung die Spannung unter einem Wert des alten externen Reglers zieht. Diese Schaltung ist so dimensioniert, dass bei Verwendung eines Junkers TRQ 21 Raumtemperaturreglers, die Therme von dieser Ansteuerung oder von dem TRQ 21 eingeschaltet werden kann. Wenn die Diode entfällt, kann diese Steuerung die Spannung von 0V ziehen und die Therme ausschalten. Im Fehlerfall und starkem Frost kann das unschön sein. Da an der Diode eine Spannung abfällt ist die Messung von Messpunkt 1 immer um diesen Wert geringer als an Messpunkt 2. Das ist aber kein Problem.

[[File:Junkers_Therme_Stetigregelung_2MP.png|center|alt=Variante 2 - ein Messpunkt]]

==Prototyp der Schaltung==

Der Aufbau des Prototypen erfolgte auf einer Punkt-Streifenrasterplatine (Immer drei Punkte einer Reihe sind miteinander verbunden (s. blaue Markierungen)). Um die Schaltung nachzubauen sind keine besonderen Lötkenntnisse erforderlich. Da nur wenige Brücken eingelötet werden müssen, lohnt sich eine fertige Platine nicht. Die Widerstände R4 und R6 sind jeweils als zwei Widerstände ausgeführt.

[[File:Junkers_Therme_Stetigregelung_Prototyp.jpg|center|alt=Variante 2 - ein Messpunkt]]

Variante 3 auf Punktraster in einer kompakten Version. Die Widerstände wurden stehend isoliert platziert, die Sicherung dient dem Schutz der Therme.
[[File:Junkers_Therme_Stetigregelung_V3.jpg|center|alt=Variante 3 - eine kompakte Aufbauvariante]]

==Pinzuordnung==

Die Verbindung zu dem AVR-NET-IO-Board erfolgt über die Pins der SUB-D Anschlussplatine (Kx):
<ul>
<li>CLK -> K12 -> PA2</li>
<li>DIN -> K11 -> PA1</li>
<li>LOAD -> K9 -> PC7</li>
<li>Messpunkt1 -> K10 -> PA0</li>
<li>Messpunkt2 -> K13 -> PA3</li>
<li>Onewire -> KK3 -> PC1</li>
</ul>

==Ethersex==

Die Firmware der AVR-NET-IO-Boards wird durch eine erweiterte Firmware ausgetauscht.

Der Vorgang ist hier beschrieben: [[AVR-NET-IO#Konfiguration_und_Flashen_von_ethersex]]

===Ethersex-Bauen===
Als Buildumgebung kann freetz-linux 1.1.1 verwendet werden. freetz-linux läuft sehr gut als Virtuelle Maschine in Virtual Box (unter Windows). Der AVR-ISP-Programmer lässt sich in die VM durchreichen. Eine Programmierung des ATMega kann so aus der VM erfolgen. Bei einem Test mit einer neueren freetz-linux Version schlug der Build-Vorgang fehl. In der Datei pinning/hardware/netio.m4 sind die PIN-Zuordnungen. Mittels „make menuconfig“ kann alles Mögliche eingestellt werden und mittels „make“ wird Ethersex für das AVR-NET-IO-Board erstellt.

Möglicherweise bricht "make" mit der Fehlermeldung "<nowiki>delay.h:230:28: error: __builtin_avr_delay_cycles expects an integer constant.</nowiki>" ab. Abhilfe schafft ein "<nowiki>#define __DELAY_BACKWARD_COMPATIBLE__ </nowiki>" in hardware/dac/ltc1257.c vor dem "<nowiki>#include <util/delay.h></nowiki>".

===Ethersex-Flashen===
Die Datei ethersex.hex aus dem tar Archive auf den Atmega 644 flashen. Hierfür eignet sich der AVRISP aus Hongkong von eBay (unter 4€ incl. Porto). Nicht vergessen die Fuses zu setzten.

==Teileliste==
Preise sind grob gerundet

<ul>
<li>eBay</li>
<ul>
<li>AVRISP-Programmer um Ethersex auf den AVR zu flashen 4€ (wenn nicht schon vorhanden)</li>
</ul>
<li>Pollin</li>
<ul>
<li>AVR-NET-IO - Fertigmodul 28€ (als Bausatz 8€ günstiger)</li>
<li>ATmega644-20PU 7€ (optional)</li>
<li>2x Temperatur-Sensor DS18S20 5€</li>
<li>5V-Netzteil EcoFriendly 5€ (ein einfaches USB-Ladegerät reicht)</li>
<li>Bausatz SUB-D Anschlussplatine 4€</li>
<li>Versandkosten 5€</li>
</ul>
<li>Reichelt</li>
<ul>
<li>LTC 1257 CN8 7€</li>
<li>Platine+Kleinteile < 10€</li>
<li>Versandkosten 6€</li>
</ul>
</ul>

Zusammen ca. 55-85€

==Erste Inbetriebnahme==
<ol>
<li>
Versuchen das AVR-NET-IO-Board per Ping zu erreichen. <br>(Die Datei aus dem tar-Archive sollte in dem Netz 192.168.178.0/24 sein)
</li>
<li>
Versuchen auf die Konsole des AVR-NET-IO-Board zuzugreifen Port: 2701 (Mit Putty, TerraTerm, netcat, ...)
</li>
<li>
Verfügbare Befehle ansehen:<br>
Befehl: help
</li>
<li>
OneWire Geräte auf Konsole scannen: 1w list<br>
Es sollten zwei Geräte (Vorlauftemperatur, Rücklauftemperatur) gefunden werden.<br>
Befehl: 1w list<br>
Ausgabe: 1069ad4d020800d8<br>
Ausgabe: 10884e5b0208002d<br>
Ausgabe: OK<br>
</li>
<li>
Temperatur einlesen:<br>
Befehl: 1w get 1069ad4d020800d8<br>
Ausgabe: 26.4<br>
</li>
<li>
Steuersignal der Heizung abfragen<br>
Befehl: adc get 0<br>
Ausgabe: 04D<br>
Befehl: adc get 3<br>
Ausgabe: 04F<br>
</li>
<li>
Steuersignal auf Maximum stellen<br>
Befehl: ltc1257_set 4095<br>
Ausgabe: OK<br>
</li>
<li>
Steuersignal der Heizung erneut abfragen<br>
Befehl: adc get 0<br>
Ausgabe: 0BF<br>
Befehl: adc get 3<br>
Ausgabe: 0C9<br>
</li>
</ol>

==Ermittlung der Betriebspunkte==

Wichtig sind vier Werte:
<ol>
<li>Messwert (ADC) für den Betriebspunkt Therme 0%</li>
<li>Messwert (ADC) für den Betriebspunkt Therme 100%</li>
<li>Stellwert (DAC) für den Betriebspunkt Therme 0%</li>
<li>Stellwert (DAC) für den Betriebspunkt Therme 100%</li>
</ol>

===Ermitteln der Messwerte===
Vorbereitung den Operationsverstärker (LM358) aus der Schaltung entfernen.
Minimalwert: Messwert wenn der Raumtemperaturregler die Therme ausschaltet. Hierfür den Raumtemperaturregler auf minimale Temperatur einstellen. Die Steuersignalspannung sollte ca. 3V betragen. Mittels „adc get“ den Wert ermitteln und ausschreiben.
Maximalwert: Messwert wenn der Raumtemperaturregler die Therme auf 100%. Hierfür den Raumtemperaturregler auf maximale Temperatur einstellen. Die Steuersignalspannung sollte ca. 18-22V betragen. Mittels „adc get“ den Wert ermitteln und ausschreiben.

===Ermitteln der Stellwerte===
Vorbereitung den Operationsverstärker (LM358) wieder in die Schaltung einsetzen. Und den Raumtemperaturregler auf minimale Raumtemperatur einstellen.
Jetzt werden die Stellwerte ermittelt. Der Sollwert des LTC1257 langsam erhöht und der aktuelle Wert mittels des ADC gemessen. Hierfür werden abwechselnd die Befehle: „ltc1257_set SOLLWERT“ und „adc get“ verwendet. Beide Werte auschreiben.

==Integration in FHEM==

In FHEM muss das Setzen der Sollwerte und die Erfassung der aktuellen Sollwerte/Istwerte integriert werden. Wenn der alt Raumtemperaturregler entfällt kann zweites auch entfallen.

===Setzen der Sollwerte===

Der LTC1257 bekommt den Sollwert mittels des Befehls ltc1257_set SOLLWERT (0 <= SOLLWERT >= 2048) zugewiesen. Hierfür wird eine classdef Datei erstellt, z.B.:

<nowiki>
# Umsetzung in ECMD Befehle
# Ein Uebergabeparameter -> Sollwert
set setDAC params dacValue
set setDAC cmd {"ltc1257_set %dacValue\n"}
set setDAC expect "OK\n"
# Keine Uebergabeparameter
set init cmd {"ltc1257_init\n"}
set init expect "OK\n"
#
</nowiki>

Danach kann der LTC1257 als ECMD Device in FHEM (fhem.cfg) angelegt werden. Hierfür wird eine möglicherweise bestehende „NETIO classdefs“ erweitert:

<nowiki>
attr NETIO_01 classdefs [Andere ECMD Geräte]:LTC1257=/opt/fhem/ltc1257.classdef
</nowiki>

Anschließend den DAC(/LTC1257) als ECMDDevice definieren

<nowiki>
define MEINDAC ECMDDevice LTC1257
attr MEINDAC room MEINRAUM
</nowiki>

Der Befehl zum Setzen eines neuen Spannungswertes lautet:

<nowiki>
my $dacValue = 1345;;\
fhem("set MEINDAC setDacValue ".$dacValue);;\
</nowiki>

===Ermitteln der Istwerte===

Der ADC ermittelt den aktuellen Sollwert über einen Spannungsteiler. Dieser Wert wird in einen Prozentwert (0-100) umgerechnet. Hierfür wird eine classdef Datei (adc.classdef)erstellt, z.B.:

<nowiki>
# Umsetzung in ECMD Befehle
# Ein Uebergabeparameter -> Sollwert
set setDacValue params dacValue
set setDacValue cmd {"ltc1257_set %dacValue"}
set setDacValue postproc {\
Log 3, "Setze Wert";;\
}
# Keine Uebergabeparameter
set init cmd {"ltc1257_init"}
</nowiki>

Danach kann der ADC als ECMD Device in FHEM (fhem.cfg) angelegt werden. Hierfür wird eine möglicherweise bestehende „NETIO classdefs“ erweitert:

<nowiki>
attr NETIO_01 classdefs [Andere ECMD Geräte]:LTC1257=/opt/fhem/adc.classdef
</nowiki>

Anschließend den ADC als ECMDDevice definieren

<nowiki>
define MEINADC ECMDDevice LTC1257
attr MEINADC room MEINRAUM
</nowiki>

==Möglichkeiten==

Ein Bild sagt mehr als tausend Worte
[[File:ScreenshotFHEMTherme.png|center|thumb|alt=Screenshot FHEM Therme]]

==Kritische Nachbetrachtung==
<ul>
<li>Anschluss der Zusatzplatine nicht über die SUB-D Anschlussplatine sondern über den 10poligen Pfostenstecker. Das würde viel sauberer/professioneller aussehen und ist bei dem verwendeten Platinentyp sehr einfach zu relaisieren.</li>
<li>Spannungsversorgung des AVR-NET-IO-Boards über die 24V Spannung der Therme (irgendwie cooler)</li>
<li>Eventuell ist es auch bei diesen Junkersthermen sinnvoller die Steuerspannung mittels eines Relais/Transistors zwischen 3-22V zu schalten. Unter Verwendung von 2 Relais/Transistoren wären auch 4 Schaltstufen möglich (0%, 25%, 50% und 100%). </li>
<li>Die Zusatzplatine trennt das AVR-NET-IO-Board/Netzwerk und die Heizung nicht. Wenn keine Messung der Steuersignalspannung gewünscht ist, würde ich den LTC1257 galvanisch trennen. Bislang gab es aber keine Probleme diesbezüglich. </li>
</ul>

Junkers Therme Stetigregelung

2019-09-02T12:11:02Z

Mahowi: /* Ansteuerung einer Junkerstherme mit einer Steuerspannung von 3-22V (0-32V möglich) */ fixed typos

[[Kategorie:Examples]]

=Ansteuerung einer Junkerstherme mit einer Steuerspannung von 3-22V (0-32V möglich)=

Viele Heizungsthermen haben eine Regelung über einen Kontakt, an dem eine feste Spannung anliegt oder eben nicht anliegt. Also als Beispiel: 0V Heizung aus – 12V Heizung an, es gibt keine weiteren Zwischenstufen. Für diese Thermen ist diese Anleitung unzweckmäßig.
Bei einigen Junkersthermen ist dies jedoch anders 3V => 0% bis 22V => 100%. Es sind beliebige Zwischenwerte möglich. Ob man eine solche Heizung hat, kann man einfach feststellen in dem man die Steuerspannung bei angeschlossenem Regler misst. Junkers nennt diese Regler auch Raumtemperaturregler mit Stetigausgang.
Beobachtung (kein Wissen): Über diese Steuerspannung wird der Brenner in Abhängigkeit vom Rücklauf gesteuert. Umso niedriger die Steuerspannung desto später (tiefere Rücklauftemperatur) beginnt die Therme zu heizen. Bei der vorhandenen Junkertherme kann die Vorlauftemperatur nicht über die Steuerspannung eingestellt werden.

==Ziel dieses Projektes==

<ul>
<li>Keine Veränderung der Therme (Sicherheits-, Versicherungs- ,Garantie-Gründe)</li>
<li>Sicher: Für den Fall eines Defekts der automatischen Steuerung soll der alte Regler soll erhalten</li>
<li>Erzeugen einer Spannung von 3-22Volt (Simulation des bisherigen Raumtemperaturreglers)</li>
<li>Messung der Vorlauf und Rücklauftemperatur</li>
<li>Günstig</li>
<li>Geringe Energieaufnahme</li>
<li>Ansteuerung mittels Netzwerk</li>
<li>Integration in FHEM</li>
</ul>

==Umsetzung==

<ul>
<li>Pollin AVR-NET-IO-Board</li>
<li>Software: Ethersex</li>
<li>kleine Zusatzplatine für die Spannungserzeugung (wird einfach parallel zu dem bestehenden Regler angeschlossen)</li>
<li>Messung der Vorlauf und Rücklauftemperatur mittels OneWire</li>
</ul>

==Vorbereitung 1==
[[File:Junkers_Therme_Stetigregelung_analoge_Anzeige.JPG|120px|right|thumb|Steuersignal]]
Da die Heizungsregelung eine sehr sensible Sache ist besonders bezüglich Frostschäden (beim Ausfall der automatischen Steuerung) und persönlicher Befindlichkeiten musste eine einfache und extrem ausfallsichere Kontrolleinheit her. Hierfür wird einfaches Drehspulmessinstrument verwendet. Anzeigewerte: 0V=Fehler, 3V=Heizung aus, 22V=Therme 100%.
Der alte Raumtemperaturregler ist weiterhin aktiv, momentan ist er auf 12°C Solltemperatur gestellt. Das bedeutet:
<ol>
<li>Wenn die automatische Reglung ausfällt, aktiviert der alte Raumtemperaturregler die Heizung bevor Frostschäden entstehen können.</li>
<li>Wenn die automatische Reglung ausfällt, kann die Therme einfach durch einstellen einer neuen Solltemperatur aktiviert werden.</li>
</ol>
Beide Fälle sind auf Grund von Ausfällen eines anderen FHEM-Systems im ersten Winter aufgetreten.

==Vorbereitung 2==
<p>
[[File:Junkers Therme Stetigregelung Signalverteiler.JPG|80px|right|thumb|Steuersignal]]
Die Leitung zu dem bisherigen Regler muss gesplittet werden. Hierfür die Heizung ausschalten (Sicherung auslösen) die Leitung auftrennen und einen Abzweig für die neue Regelung einfügen. Das Ganze kann mit einer Schmelzsicherung (für die 24V VCC Leitung) und einem 3poligem-Schalter (vollständiges Wegschalten der automatischen Regelung) versehen werden.
</p>

==Vorbereitung 3==
<p>
Netzwerk zu der Therme oder das Steuersignal zum Netzwerk ziehen. Das AVR-NET-IO-Board kann irgendwo in die Steuersignal-Leitung eingesetzt werden. Theoretisch kann auch die 24V Spannungsversorgung für den ursprünglichen Raumtemperaturregler verwendet werden. Hier muss einfach ein DC/DC-Wandler eingesetzt werden. (Bitte Leistungsabgabe der Heizung und Leistungsaufnahme des AVR-NET-IO-Board überprüfen)
</p>

==Digital-to-Analog-Converter==

Die Schaltung besteht aus einem DAC (LTC1257) und einem Operationsverstärker (LM358). Der LTC1257 wandelt (bei interner Referenzspannung) einen digital übermittelten Wert (über die Eingänge CLK, DIN und LOAD) in eine Spannung von 0-2,048V. Diese Spannung wird anschließend von dem LM358 erhöht. Die Elemente R1,R2, C1 und C2 gehören zur Grundbeschaltung des LTC1257. Mittels der Widerstände R3 und R4 wird der Verstärkungsfaktor der Operationsverstärkerschaltung eingestellt. Der OP ist als nicht invertierender Verstärker ausgeführt. Mit zwei Widerständen könnte aus dem LM358 eine doppelte invertierende Verstärkerschaltung (in Reihe geschaltete) aufgebaut werden. Das würde die Genauigkeit erhöhen. Die Schaltung funktioniert jedoch einwandfrei und eine höhere Genauigkeit wird vermutlich nur selten einen Vorteil bieten.
In diesem Fall ist hat VCC_Therme eine Spannung von 24V. Der LM358 kann bis 32V arbeiten, dann muss jedoch der Widerstandswert von R4 erhöht werden. An dem Steuersignal_Therme liegt je nach dem welchen Wert der LTC1257 gerade in einen anlogen Wert umsetzt, eine Spannung von 0-24V. Diese Schaltung kann eingesetzt werden, um Junkers-Thermen mit „Stetigeingang“ anzusteuern.

Die Beschaltung mit C1 und R1 scheint nicht in jedem Fall angemessen zu sein. Damit kann man sich einen Sägezahn als Referenzspannung einfangen, der im Kilohertzbereich die Referenz- (und damit auch die DAC-Ausgangspannung) von 100 % auf ca. 90 % fährt. Das gibt dann unerwünschte Effekte beim Messen der Spannung für die Stetigregelung. Ohne C1 und R1 ergibt sich eine konstante Referenzspannung.

[[File:Junkers_Therme_Stetigregelung_0MP.png|center|alt=Variante 1 - keine Messpunkte]]

Variant 2: Die Ausgangsspannung der Schaltung kann zwischen dem Widerstand R3 und R4 von einem ADC gemessen werden. Da an R4 über 90% der Spannung abfällt, kann die Messung problemlos mittels eines 5V ADCs erfolgen.

[[File:Junkers_Therme_Stetigregelung_1MP.jpg|center|alt=Variante 2 - ein Messpunkt]]

In der Varianten 3 ist eine Sicherheitsfunktion eingebaut, die durchaus sinnvoll ist. Die Diode D1 verhindert, dass diese Schaltung die Spannung unter einem Wert des alten externen Reglers zieht. Diese Schaltung ist so dimensioniert, dass bei Verwendung eines Junkers TRQ 21 Raumtemperaturreglers, die Therme von dieser Ansteuerung oder von dem TRQ 21 eingeschaltet werden kann. Wenn die Diode entfällt, kann diese Steuerung die Spannung von 0V ziehen und die Therme ausschalten. Im Fehlerfall und starkem Frost kann das unschön sein. Da an der Diode eine Spannung abfällt ist die Messung von Messpunkt 1 immer um diesen Wert geringer als an Messpunkt 2. Das ist aber kein Problem.

[[File:Junkers_Therme_Stetigregelung_2MP.png|center|alt=Variante 2 - ein Messpunkt]]

==Prototyp der Schaltung==

Der Aufbau des Prototypen erfolgte auf einer Punkt-Streifenrasterplatine (Immer drei Punkte einer Reihe sind miteinander verbunden (s. blaue Markierungen)). Um die Schaltung nachzubauen sind keine besonderen Lötkenntnisse erforderlich. Da nur wenige Brücken eingelötet werden müssen, lohnt sich eine fertige Platine nicht. Die Widerstände R4 und R6 sind jeweils als zwei Widerstände ausgeführt.

[[File:Junkers_Therme_Stetigregelung_Prototyp.jpg|center|alt=Variante 2 - ein Messpunkt]]

Variante 3 auf Punktraster in einer kompakten Version. Die Widerstände wurden stehend isoliert platziert, die Sicherung dient dem Schutz der Therme.
[[File:Junkers_Therme_Stetigregelung_V3.jpg|center|alt=Variante 3 - eine kompakte Aufbauvariante]]

==Pinzuordnung==

Die Verbindung zu dem AVR-NET-IO-Board erfolgt über die Pins der SUB-D Anschlussplatine (Kx):
<ul>
<li>CLK -> K12 -> PA2</li>
<li>DIN -> K11 -> PA1</li>
<li>LOAD -> K9 -> PC7</li>
<li>Messpunkt1 -> K10 -> PA0</li>
<li>Messpunkt2 -> K13 -> PA3</li>
<li>Onewire -> KK3 -> PC1</li>
</ul>

==Ethersex==

Die Firmware der AVR-NET-IO-Boards wird durch eine erweiterte Firmware ausgetauscht.

Der Vorgang ist hier beschrieben: [[AVR-NET-IO#Konfiguration_und_Flashen_von_ethersex]]

===Ethersex-Bauen===
Als Buildumgebung kann freetz-linux 1.1.1 verwendet werden. freetz-linux läuft sehr gut als Virtuelle Maschine in Virtual Box (unter Windows). Der AVR-ISP-Programmer lässt sich in die VM durchreichen. Eine Programmierung des ATMega kann so aus der VM erfolgen. Bei einem Test mit einer neueren freetz-linux Version schlug der Build-Vorgang fehl. In der Datei pinning/hardware/netio.m4 sind die PIN-Zuordnungen. Mittels „make menuconfig“ kann alles Mögliche eingestellt werden und mittels „make“ wird Ethersex für das AVR-NET-IO-Board erstellt.

Möglicherweise bricht "make" mit der Fehlermeldung "<nowiki>delay.h:230:28: error: __builtin_avr_delay_cycles expects an integer constant.</nowiki>" ab. Abhilfe schafft ein "<nowiki>#define __DELAY_BACKWARD_COMPATIBLE__ </nowiki>" in hardware/dac/ltc1257.c vor dem "<nowiki>#include <util/delay.h></nowiki>".

===Ethersex-Flashen===
Die Datei ethersex.hex aus dem tar Archive auf den Atmega 644 flashen. Hierfür eignet sich der AVRISP aus Hongkong von eBay (unter 4€ incl. Porto). Nicht vergessen die Fuses zu setzten.

==Teileliste==
Preise sind grob gerundet

<ul>
<li>eBay</li>
<ul>
<li>AVRISP-Programmer um Ethersex auf den AVR zu flashen 4€ (wenn nicht schon vorhanden)</li>
</ul>
<li>Pollin</li>
<ul>
<li>AVR-NET-IO - Fertigmodul 28€ (als Bausatz 8€ günstiger)</li>
<li>ATmega644-20PU 7€ (optional)</li>
<li>2x Temperatur-Sensor DS18S20 5€</li>
<li>5V-Netzteil EcoFriendly 5€ (ein einfaches USB-Ladegerät reicht)</li>
<li>Bausatz SUB-D Anschlussplatine 4€</li>
<li>Versandkosten 5€</li>
</ul>
<li>Reichelt</li>
<ul>
<li>LTC 1257 CN8 7€</li>
<li>Platine+Kleinteile < 10€</li>
<li>Versandkosten 6€</li>
</ul>
</ul>

Zusammen ca. 55-85€

==Erste Inbetriebnahme==
<ol>
<li>
Versuchen das AVR-NET-IO-Board per Ping zu erreichen. <br>(Die Datei aus dem tar-Archive sollte in dem Netz 192.168.178.0/24 sein)
</li>
<li>
Versuchen auf die Konsole des AVR-NET-IO-Board zuzugreifen Port: 2701 (Mit Putty, TerraTerm, netcat, ...)
</li>
<li>
Verfügbare Befehle ansehen:<br>
Befehl: help
</li>
<li>
OneWire Geräte auf Konsole scannen: 1w list<br>
Es sollten zwei Geräte (Vorlauftemperatur, Rücklauftemperatur) gefunden werden.<br>
Befehl: 1w list<br>
Ausgabe: 1069ad4d020800d8<br>
Ausgabe: 10884e5b0208002d<br>
Ausgabe: OK<br>
</li>
<li>
Temperatur einlesen:<br>
Befehl: 1w get 1069ad4d020800d8<br>
Ausgabe: 26.4<br>
</li>
<li>
Steuersignal der Heizung abfragen<br>
Befehl: adc get 0<br>
Ausgabe: 04D<br>
Befehl: adc get 3<br>
Ausgabe: 04F<br>
</li>
<li>
Steuersignal auf Maximum stellen<br>
Befehl: ltc1257_set 4095<br>
Ausgabe: OK<br>
</li>
<li>
Steuersignal der Heizung erneut abfragen<br>
Befehl: adc get 0<br>
Ausgabe: 0BF<br>
Befehl: adc get 3<br>
Ausgabe: 0C9<br>
</li>
</ol>

==Ermittlung der Betriebspunkte==

Wichtig sind vier Werte:
<ol>
<li>Messwert (ADC) für den Betriebspunkt Therme 0%</li>
<li>Messwert (ADC) für den Betriebspunkt Therme 100%</li>
<li>Stellwert (DAC) für den Betriebspunkt Therme 0%</li>
<li>Stellwert (DAC) für den Betriebspunkt Therme 100%</li>
</ol>

===Ermitteln der Messwerte===
Vorbereitung den Operationsverstärker (LM358) aus der Schaltung entfernen.
Minimalwert: Messwert wenn der Raumtemperaturregler die Therme ausschaltet. Hierfür den Raumtemperaturregler auf minimale Temperatur einstellen. Die Steuersignalspannung sollte ca. 3V betragen. Mittels „adc get“ den Wert ermitteln und ausschreiben.
Maximalwert: Messwert wenn der Raumtemperaturregler die Therme auf 100%. Hierfür den Raumtemperaturregler auf maximale Temperatur einstellen. Die Steuersignalspannung sollte ca. 18-22V betragen. Mittels „adc get“ den Wert ermitteln und ausschreiben.

===Ermitteln der Stellwerte===
Vorbereitung den Operationsverstärker (LM358) wieder in die Schaltung einsetzen. Und den Raumtemperaturregler auf minimale Raumtemperatur einstellen.
Jetzt werden die Stellwerte ermittelt. Der Sollwert des LTC1257 langsam erhöht und der aktuelle Wert mittels des ADC gemessen. Hierfür werden abwechselnd die Befehle: „ltc1257_set SOLLWERT“ und „adc get“ verwendet. Beide Werte auschreiben.

==Integration in FHEM==

In FHEM muss das Setzen der Sollwerte und die Erfassung der aktuellen Sollwerte/Istwerte integriert werden. Wenn der alt Raumtemperaturregler entfällt kann zweites auch entfallen.

===Setzen der Sollwerte===

Der LTC1257 bekommt den Sollwert mittels des Befehls ltc1257_set SOLLWERT (0 <= SOLLWERT >= 2048) zugewiesen. Hierfür wird eine classdef Datei erstellt, z.B.:

<nowiki>
# Umsetzung in ECMD Befehle
# Ein Uebergabeparameter -> Sollwert
set setDAC params dacValue
set setDAC cmd {"ltc1257_set %dacValue\n"}
set setDAC expect "OK\n"
# Keine Uebergabeparameter
set init cmd {"ltc1257_init\n"}
set init expect "OK\n"
#
</nowiki>

Danach kann der LTC1257 als ECMD Device in FHEM (fhem.cfg) angelegt werden. Hierfür wird eine möglicherweise bestehende „NETIO classdefs“ erweitert:

<nowiki>
attr NETIO_01 classdefs [Andere ECMD Geräte]:LTC1257=/opt/fhem/ltc1257.classdef
</nowiki>

Anschließend den DAC(/LTC1257) als ECMDDevice definieren

<nowiki>
define MEINDAC ECMDDevice LTC1257
attr MEINDAC room MEINRAUM
</nowiki>

Der Befehl zum Setzen eines neuen Spannungswertes lautet:

<nowiki>
my $dacValue = 1345;;\
fhem("set MEINDAC setDacValue ".$dacValue);;\
</nowiki>

===Ermitteln der Istwerte===

Der ADC ermittelt den aktuellen Sollwert über einen Spannungsteiler. Dieser Wert wird in einen Prozentwert (0-100) umgerechnet. Hierfür wird eine classdef Datei (adc.classdef)erstellt, z.B.:

<nowiki>
# Umsetzung in ECMD Befehle
# Ein Uebergabeparameter -> Sollwert
set setDacValue params dacValue
set setDacValue cmd {"ltc1257_set %dacValue"}
set setDacValue postproc {\
Log 3, "Setze Wert";;\
}
# Keine Uebergabeparameter
set init cmd {"ltc1257_init"}
</nowiki>

Danach kann der ADC als ECMD Device in FHEM (fhem.cfg) angelegt werden. Hierfür wird eine möglicherweise bestehende „NETIO classdefs“ erweitert:

<nowiki>
attr NETIO_01 classdefs [Andere ECMD Geräte]:LTC1257=/opt/fhem/adc.classdef
</nowiki>

Anschließend den ADC als ECMDDevice definieren

<nowiki>
define MEINADC ECMDDevice LTC1257
attr MEINADC room MEINRAUM
</nowiki>

==Möglichkeiten==

Ein Bild sagt mehr als tausend Worte
[[File:ScreenshotFHEMTherme.png|center|thumb|alt=Screenshot FHEM Therme]]

==Kritische Nachbetrachtung==
<ul>
<li>Anschluss der Zusatzplatine nicht über die SUB-D Anschlussplatine sondern über den 10poligen Pfostenstecker. Das würde viel sauberer/professioneller aussehen und ist bei dem verwendeten Platinentyp sehr einfach zu relaisieren.</li>
<li>Spannungsversorgung des AVR-NET-IO-Boards über die 24V Spannung der Therme (irgendwie cooler)</li>
<li>Eventuell ist es auch bei diesen Junkersthermen sinnvoller die Steuerspannung mittels eines Relais/Transistors zwischen 3-22V zu schalten. Unter Verwendung von 2 Relais/Transistoren wären auch 4 Schaltstufen möglich (0%, 25%, 50% und 100%). </li>
<li>Die Zusatzplatine trennt das AVR-NET-IO-Board/Netzwerk und die Heizung nicht. Wenn keine Messung der Steuersignalspannung gewünscht ist, würde ich den LTC1257 galvanisch trennen. Bislang gab es aber keine Probleme diesbezüglich. </li>
</ul>

SIGNALduino

2019-07-25T13:55:13Z

Mahowi: /* Unterstützte Geräte */Wetterstation CTW602 hinzugefügt

{{Infobox Modul
|ModPurpose=Empfang und Verarbeitung von digitalen Signalen
|ModType=d
|ModFTopic=38402
|ModCmdRef=SIGNALduino
|ModForumArea=Sonstige Systeme
|ModTechName=00_SIGNALduino.pm
|ModOwner=Sidey ({{Link2FU|8018|Forum}}/[[Benutzer Diskussion:Sidey|Wiki]])
}}

== Einleitung ==
=== Übersicht ===
Unter den Namen SIGNALduino versteht man sowohl den Low-Cost Empfänger für digitale Signale (vergleichbar dem [[CUL]]) als auch das gleichnamige Modul mit dem Dateinamen 00_SIGNALduino.pm. Mit dem SIGNALduino kann man entweder 433 oder 868 MHz-Geräte auslesen und ansprechen. Der SIGNALduino funktioniert auch mit anderen Medien wie Infrarot oder direkter Kabelverbindung.

Der SIGNALduino(-Stick) erkennt Signale anhand von Mustern und gibt sie (als maximal detaillierte Beschreibung einer Signalabfolge) dann schlicht sofort nur noch an FHEM zur Auswertung (Dekodierung) weiter. Auch nicht erkannte Signale werden an FHEM übergeben.
Aufgabe des SIGNALduino (Firmware/Stick) ist es also nur, Signal-Aktivitäten zu erfassen und maximal präzise (als kurzer Text-String) zu beschreiben.
Alles weitere (echte, finale Auswertung / Zuweisung dieser Signal-Daten) wird dann auf einer großen Box (Raspberry o.ä.) gemacht.

=== Vorteil gegenüber einem CUL/FHEMduino ===
Der SIGNALduino hat den Vorteil einer sehr schnellen Demodulation des Funksignals. Sollen weitere Protokolle dekodiert werden, so muss dazu nur ein passendes FHEM Modul entwickelt oder ein universelles Modul erweitert werden (also auf flexibel direkt updatebarer Rechner-Seite!!). Änderungen am Arduino-Firmware-Code sind normalerweise nicht notwendig (sofern die grundsätzliche Signal-Klassifizierung des Sticks korrekt funktioniert - leider nicht immer, z.B.: [https://github.com/RFD-FHEM/SIGNALDuino/issues/65 MU-Nachrichten werden z.T. als MC erkannt]).

Ein großer Vorteil des SIGNALduino besteht darin, dass auch Geräte mit leicht abweichende Frequenzen steuerbar sind; so empfangen die Somfy-Rolladenmotoren beispielsweise auf 433.42 und nicht, wie bei anderen Geräten sehr oft üblich, auf 433.92 MHz. Die Frequenzumstellung stellt für den SIGNALduino kein Problem dar.

Ebenso kann man den SIGNALduino direkt an den Sendeausgang eines Sensors anbinden und die digitalen Signale empfangen, dabei bitte aber auf die passenden Spannungen achten, denn ein Arduino Nano verträgt nur 5V.

=== Entwicklungsversion ===
Der SIGNALduino wird derzeit aktiv weiterentwickelt, siehe dazu https://github.com/RFD-FHEM. Die Version von Sidey wird [https://forum.fhem.de/index.php/topic,58396.0.html hier ]genauer beschrieben.

Es existiert eine weitere Entwicklungsversion, siehe dazu die [https://forum.fhem.de/index.php/topic,82379.msg744554.html#msg744554 Firmware] (hierzu gibt es auch eine private Version des [https://github.com/Ralf9/RFFHEM/issues/2 Moduls]).

== Hardware ==
=== Controller ===

Der SIGNALduino (Hardware) wird über den USB Port angeschlossen, er kann aber auch mit zusätzlichen ESP Modulen über ein WLAN angebunden werden.

Der SIGNALduino basiert auf einem [http://arduino.cc/de/Main/ArduinoBoardNano Arduino Nano], die Schaltung entspricht der des [[FHEMduino]] oder dem [[Selbstbau_CUL]]:
* Entweder wird ein Arduino mit einfachen Sende- und Empfangsmodulen verwendet, dann ist die Verkabelung identisch zum [[FHEMduino]]
* Oder es wird ein CC1101 Transceiver verwendet, dann ist die Verkabelung identisch zum [[Selbstbau_CUL]].
* Zuletzt gibt es ein fertig konfektioniertes Modul von In-Circuit mit Radino CC1101 Varianten, link zum [http://shop.in-circuit.de/index.php Hersteller].

Achten Sie beim Selbstbau auf die entsprechenden Sender-Empfänger. Der sehr preiswert angebotene XY-MK-5V hat sich als zu unzuverlässig erwiesen, während anscheinend beim CC1101 (insbesondere der "grünen Version") keine Probleme auftreten.

Es stehen auch für den [https://www.arduino.cc/en/Main/arduinoBoardUno UNO] und [https://www.arduino.cc/en/Main/ArduinoBoardProMini PRO Mini] Firmware-Dateien zur Verfügung. Die ausgelieferte Firmware läuft nur auf Mikrocontrollern mit 16 MHz; wer einen Mikrocontroller mit 8 MHz verwenden möchte, muss die Firmware selbst compilieren. Die SW ist auf [https://github.com/RFD-FHEM/SIGNALDuino github]. Vorgesehen ist nur die Übersetzung unter Windows mit Visual Studio und dem Visual Micro Zusatz. Es gibt aber auch eine Anleitung, wie man mit der [[Arduino]] IDE oder einem Makefile [[SIGNALduino Compilieren]] kann.

Es gibt auch eine Variante des SIGNALduino, die auf einem [[ESP8266]] nativ läuft, diese funktioniert seit Anfang 2018 annehmbar, allerdings befindet diese sich noch in einer Entwicklungsphase.

An den "SIGNALESP" kann auch ein CC1101 via SPI angebunden werden:

{||
!CC1101 Bezeichnung
!ESP Pin
|-
|CLK||GPIO14
|-
|MOSI||GPIO13
|-
|MISO||GPIO12
|-
|CSN||GPIO15
|-
|GDO0||GPIO4
|-
|GDO2||GPIO5
|}

Wird ein einfacher Empfänger / Sender Kombination verwendet, dann über die PINs:

{||
! Bezeichnung
! ESP Pin
|-
|Transmitter||GPIO4
|-
|Receiver||GPIO5
|}

=== Sendemodule ===
{{Randnotiz|RNTyp=r|RNText=Viele user berichten über Empfangsprobleme bei Nutzung des XY-MK-5V; es wird ausdrücklich empfohlen, ein anderes Empfangsmodul zu nutzen!}}
[[Datei:Fhemduino_schematic.png|200px|thumb|right|Beispielschaltplan SIGNAL(FHEM)duino]]

Mit einem Arduino-Nano und folgenden, billigen Sende- und Empfangsmodulen können Sie einen SIGNALduino bauen:
* FS1000A Dies ist das Sendemodul (TX) und wird oft im Set mit dem billigen XY-MK-5V-Empfänger angeboten (etwa 5€).
* RXB6 Das ist das empfohlene Empfangsmodul (RX), statt XY-MK-5V, etwa 5€ aus Deutschland.

Die Verkabelung erfolgt analog zum [[FHEMduino]] und das bedeutet (Arduino -> Modul):
* PIN D2 an DATA des RX-Moduls
* PIN D11 an DATA des TX-Moduls (PIN links mit Beschriftung ATAD)

Zusätzlich muss noch jeweils GND und 5V des Arduino mit dem GND bzw. VCC des Moduls verbunden werden.

Jetzt fehlen noch die Antennen. Dafür braucht man ein 17,2 cm langes Stück Kupferdraht, das wird beim Anschluss "ANT" jeweils am Modul angelötet (anfängergeeignet).

== Software ==

=== USB-ID ermitteln ===
Bevor der SIGNALduino mit dem FHEM Server (im Beispiel hier ein Raspberry PI) verbunden werden kann, muss die USB-Schnittstelle ermittelt werden. Hierzu bitte auf dem Terminal den Befehl
<pre> ls -l /dev/serial/by-id </pre>
ausführen. Beispielhaft sieht das Ergebnis etwa so aus:
''lrwxrwxrwx 1 root root 13 Jan 31 00:02 '''usb-FTDI_FT232R_USB_UART_A903N5T5-if00-port''' -> ../../ttyUSB0''
Damit ist der Anschluss des SIGNALduino bestimmt und das Gerät kann wie im nächsten Abschnitt beschrieben definiert werden. Zuvor muss noch das Modul geladen werden.

=== FHEM-Modul laden ===
Die SIGNALduino Module werden über das FHEM [[update]] verteilt, sobald die Änderungen einen "stabilen" und alltags tauglichen Zustand haben. Aktuell wird dort die Version 3.4.0 seit 20.07.2019 verteilt.

Die in der Entwicklung befindliche Version (3.4.x) kann mit folgenden Befehlen geladen werden:

* FHEM aktualisieren: <code>update</code>
* SIGNALduino Modul aktualisieren: <code>update all <nowiki>https://raw.githubusercontent.com/RFD-FHEM/RFFHEM/dev-r34/controls_signalduino.txt</nowiki></code> Durch das Update von FHEM wird sichergestellt, dass das Modul mit FHEM arbeitet.
*Danach kann das Gerät wie folgt definiert werden (die Spezifikation des USB-Anschlusses muss dabei an die aktuellen Gegebenheiten angepasst werden):
:<code>define <eigener-SIGNALduino-Name> SIGNALduino /dev/serial/by-id/usb-FTDI_FT232R_USB_UART_A903N5T5-if00-port0@57600</code>
* Solltet Ihr einen SIGNALESP via IP einbinden wollen ist die Syntax
:<code>define <eigener-SIGNALESP-Name> SIGNALduino <ip-adresse>:23</code>
Nach dem Einbinden wird der SIGNALduino, falls er erkannt wird, im Status "Opened" angezeigt.

Für neuere Entwicklungen kann in FHEM auch dauerhaft die developer Version aktualisiert werden:
<code>update add <nowiki>https://raw.githubusercontent.com/RFD-FHEM/RFFHEM/dev-r34/controls_signalduino.txt</nowiki></code>
Danach wird FHEM bei dem normalen Update-Befehl immer automatisch die aktuelle dev Version laden.

Die nachfolgenden Beispiel-Befehle verwenden "sduino" als <eigener-SIGNALduino-Name>.

==== Flashen des Arduino mit der SIGNALduino Firmware ====
Falls avrdude noch nicht vorhanden ist, kann es mit folgendem Befehl installiert werden:
:<code>sudo apt-get install avrdude</code>

In FHEM ist der SIGNALduino mit dem Status "Open" vorhanden. Jetzt müssen wir FHEM noch mitteilen, welche Hardware wir angeschlossen haben. Über das Attribut ''hardware'' lässt sich zwischen den mitgelieferten Firmware-Dateien wechseln. Solltet ihr einen Nano mit cc1101 Transceiver verwenden, so wählt bitte folgende Hardware
:<code>attr sduino hardware nanoCC1101</code>
sonst üblicherweise
:<code>attr sduino hardware nano328</code>

Dann muss mitgeteilt werden, welche Version man geladen haben will: stable oder testing. Derzeit ist nur testing verfügbar:
:<code>attr sduino updateChannelFW testing</code>
Nun wird die entsprechende Firmware heruntergeladen. Dies geschieht durch den Befehl
:<code>get sduino availableFirmware</code>
Anschließend kann der ''flash'' Befehl abgesetzt werden:
:<code>set sduino flash <und-dann-auswaehlen></code>
Dadurch wird der Arduino mit der gewählten Firmware geflasht. Das Ergebnis wird im Webinterface direkt angezeigt.

Alternativ kann auch der Flash-Befehl mit einem Dateinamen aufgerufen werden. Diese Möglichkeit sollte jedoch nur verwendet werden, wenn die SIGNALduino Firmware selbst compiliert wurde und eine andere Hardware verwendet wird. Der Flash-Befehl wird wie folgt aufgerufen:
:<code>set sduino flash FHEM/firmware/SIGNALduino_mega2560.hex</code>
(je nachdem wo und unter welchem Namen die .hex Datei abgelegt wurde)

==== Flashen einer Firmware über HTTP ====
Die Firmware wird in absehbarer Zeit nicht mehr über den Update Mechanismus verteilt werden.
Damit die passende Firmware auf den SIGNALduino geladen werden kann, wird diese dann über HTTP geladen.

==== Vorabversion einer Firmware ====
Die Firmware des SIGNALduino wird ebenso wie das FHEM Modul auch weiter entwickelt.
Die Entwickler sind auf Tests und Rückmeldungen der Nutzer angewiesen, da leider nicht alle Sensoren vorher getestet werden können.

Aktuell (November 2018) ist noch die Version 3.3.1 in Entwicklung. Diese steht aktuell in einer Release Candidate Version zur Verfügung.

Für die folgenden Microcontroller kann man die Firmware seit 21.02.2019 auch direkt downloaden und teilweise flashen.
Dazu muss das Attribut hardware auf einen gültigen Wert angepasst werden!
Über den GET Befehl availableFirmware werden dann für die hinterlegte Hardware die passenden Versionen gesucht. Über das Attribut updateChannelFW kann zwischen "stable" und "testing" definiert werden, welche Art von Firmware angeboten werden soll.

Nachdem die Firmwareversion erfragt wurde, bietet der set flash Befehl eine Auswahlliste an. Wird ein Flash Befehl mit einer der Versionen ausgewählt, wird diese Version zunächst heruntergeladen und bei den AVR Versionen auch versucht diese mittels avrdude zu flashen.
Die Firmware für den ESP8266 kann aktuell leider noch nicht über diesen Befehl aktualisiert werden.

Alternativ funktioniert aber auch die Option, dem Flash Befehl eine URL zu übergeben. Dann wird die Datei aus der URL heruntergeladen und auch versucht diese zu Flashen. z.B.
SIGNALDuino_nanocc1101.hex für einen Nano mit CC1101

<code>set sduino flash https://github.com/RFD-FHEM/SIGNALDuino/releases/download/3.3.1-RC10/SIGNALDuino_nanocc1101release.hex
</code>

oder
SIGNALESP_.hex (mit cc1101) für einen ESP8266 und 1 MB Flash
<code>set ipduino flash https://github.com/RFD-FHEM/SIGNALDuino/releases/download/nightly/SIGNALDuino_ESP8266cc1101nightly.hex
</code>

!Achtung, aktuell wird die Firmware für den ESP dadurch nur herunter geladen. Flashen müsst ihr leider immer noch über ein passendes Tool
z.B. [https://github.com/nodemcu/nodemcu-flasher ESP8266Flasher.exe] oder Esptool und einer seriellen Konsole.
Auch ist zu beachten, es handelt sich hierbei tatsächlich um ein Binary und nicht um ein Hex File.

Nach dem Booten des ESPs, spannt dieser ein eigenes WLAN auf. Habt ihr euch damit verbunden, könnt ihr den ESP mit eurem vorhandenen WLAN verbinden.

Die Haupt-Seite für Firmware-Releases findet sich unter https://github.com/RFD-FHEM/SIGNALDuino/releases/ .
Dort kann auch eine Änderungshistorie eingesehen werden.
==== Flashen eines radino Boards mit ATmega32U4 ====

Diese Funktion steht seit 21.02.2019 nun auch in der via FHEM aktualisierten version zur Verfügung:

Auch sind Berichte bekannt, dass der Radino beim Neustart von FHEM nicht korrekt initialisiert wird.
Weiterhin ist zu beachten, dass der Bootloader eine andere USB ID bekommt und diese im Attribut flashCommand hinterlegt werden muss.

==== Fehler beim Flashen ====
Sollte bei einem Flash Vorgang ein Fehler auftreten, solltet ihr zunächst im Logfile mit Verbose 5 nachsehen.

Findet ihr dort keine Fehlermeldung, gibt es noch ein separates Flashlog, welches ihr über einen Browser aufrufen könnt. Dazu müsst ihr nur den Folgenden Pfad an euren Servernamen anhängen:
<code>
/fhem/FileLog_logWrapper?dev=Logfile&type=text&file=SIGNALduino-Flash.log
</code>

=== Geräteerkennung ===
==== Unterstützte Geräte ====
Für die folgenden Geräte gibt es derzeit (2017) eine Unterstützung für den Betrieb mit FHEM. Die Geräte werden [[autocreate|automatisch erkannt]] und in der Konfiguration eingetragen, wenn der SIGNALduino läuft.
Bitte Geräte mit sehr präzisen Referenzen hier listen (Produktnummer, Protokoll-Variantenname etc.), damit eine globale Suche/Verifikation maximal erfolgreich ist. In der detaillierten Liste [[Geprüfte_Geräte]] lassen sich die Geräte näher identifizieren.
{|class="wikitable"
! style="text-align:left;"| Produkt
! (E)mpfangen<br />(S)enden
! Hinweise
! Verwendetes Modul
! Protokoll ID
|-
|Conrad Wetterstation KW9110||E S||Sensor: KW9010, neben Temperatur u. Luftfeuchte werden auch Trend, Batterie u. Kanal erfasst|| CUL_TCM97001 || 0.3
|-
|TCM Wetterstation (97001 und 21xxx Serie)||E|| || CUL_TCM97001 || 0
|-
|ABS Wetterstation (ABS 700)||E|| || CUL_TCM97001 || 0
|-
|Prologue Wetterstation ||E|| ||CUL_TCM97001 || 0
|-
|Rubicson Wetterstation ||E|| ||CUL_TCM97001 ||0
|-
|NC_WS Wetterstation ||E|| ||CUL_TCM97001 || 0
|-
|[http://www.gt-support.de/ GT-WT-02 Wetterstation]||E|| ||CUL_TCM97001 || 0
|-
|AURIOL Wetterstation ||E|| ||CUL_TCM97001 || 0
|-
|Mebus Wetterstation ||E|| ||CUL_TCM97001 || 0
|-
|Intertechno Funkschalter||E S|| ||IT || 3,4,5,17
|-
|<strike>Conrad RSL Funkschalter</strike>||E S|| Funktioniert aktuell nicht || SIGNALduino_RSL ||
|-
|[http://global.oregonscientific.com/product_view.php?id=5 Oregon Scientific Wettersensoren]||E || Protokoll V2 & V3 implementiert || OREGON || 10
|-
|Bresser Temp/Hydro Sensor||E || || Hideki || 12
|-
|[https://de.hama.com/00104985/hama-aussensensor-ts33c-fuer-wetterstation Hama TS33C]||E || || Hideki || 12
|-
|TFA Temp/Hydro Sensor||E || || Hideki || 12
|-
|Lacrosse TX2/TX3 Sensoren||E || || CUL_TX || 8
|-
|TFA 30320902||E || || SD_WS07 || 7
|-
|Eurochron eas800z||E || || SD_WS07 || 7
|-
|Technoline WS6750/TX70DTH||E || || SD_WS07 || 7
|-
|FreeTec Außenmodul NC-7344||E || || SD_WS07 || 7
|-
|CTW600||E || || SD_WS09 || 9
|-
|CTW602||E ||neuere Version des CTW600 mit 868.35 MHz || SD_WS09 || 9
|-
|WH1080||E || || SD_WS09 || 9
|-
|Visivon remote pt4450||E || || none || 24
|-
|Einhell HS 434/6||E || || none || 21
|-
|Flamingo FA20RF / FA21RF / FA22RF Rauchmelder||E || || FLAMINGO || 13,13.1,13.2
|-
|mumbi m-FS300||E || || none || 26,27
|-
|TFA 30.3200||E || || none || 33
|-
|Livolo||E|| || none || 20
|-
|Smartwares RM174RF/2 (RM174RF-001CPR) 4500177571 ||E [S?]|| IT EV1527; TODO herausfinden: Alarmierung (wie Alarmton getriggered werden kann); Batterieinfo? || IT || 3
|-
|Smartwares SH5-TSO-A||E S|| || IT || ?
|-
|X10 Security Devices||E|| || || 39
|-
|[[Somfy_via_SIGNALduino|Somfy RTS]]||E S|| || SOMFY || 43
|}
Bei einigen Intertechno-Funksteckdosen (Brennenstuhl) kann es zu Empfangsproblemen kommen. Hier muss die Taktrate, mit der gesendet wird, angepasst werden. Dazu muss für ''Funksteckdose'' (also sauber per-Client-Instanz-spezifisch, NICHT SIGNALduino-Transceiver-global) das Attribut
:<code>attr <Funksteckdose> ITclock 300</code>
gesetzt werden, der Standardwert ist 250.

==== Mein Gerät wird in FHEM nicht erkannt ====
1. Prüfen, ob vom Sensor die Signaldaten (verbose >=4) erkannt werden. Sobald ihr die empfangenen Signaldaten im Logfile zuordnen könnt, geht es weiter mit:

2. Eröffnet ein Thema unter [https://github.com/RFD-FHEM/RFFHEM/issues github] nach folgendem Muster:
:''Thema : Protokoll für <Das verwendete Gerät>
:Inhalt: Eure Hardware z.B. Arduino Nano mit XYZ Empfänger, oder Arduino Nano direkt an Gerät x

3. Auszug aus dem Logfile, welches zum Gerät gehört.
:''Alles was ihr sonst noch über das Gerät und die übertragenen Daten wisst.

Im Forum solltet ihr solche Fragen besser nicht posten, wenn das Gerät noch nicht unterstützt wird, dazu ist Github besser geeignet. Inzwischen wurde im Wiki eine eigene Seite eröffnet, die sich mit der Erkennung unbekannter Protokolle beschäftigt: [[Unbekannte_Funkprotokolle#Ansatz_1_-_Versuchen|Unbekannte_Funkprotokolle]].

==== Es wird ein Protokoll erkannt, Autocreate legt aber kein device an ====
Im SIGNALduino sind >30 Protokolle implementiert. Jedoch gibt es nur wenige Module, welche diese Protokolle verarbeiten.
Teilweise ist das auch nicht zwingend notwendig, um seine Anforderungen zu erfüllen. Insbesondere für Schalter bzw. Sensoren, die nur zwei Zustände kennen, geht es meist ohne Modul und automatisch angelegtem Gerät.

Nehmen wir an, wir haben einen Schalter. Dieser kann einen oder zwei Zustände senden.
Im FHEM Log (und, insbesondere, im FHEMWEB Event Monitor) tauchen Meldungen ähnlich dieser auf

<code>
2015.11.15 15:52:23 4: SIGNALduino_unknown incomming msg: u85#FF8081
</code>

Wir können mit Hilfe des Modules DOIF auf diese Nachricht eine Aktion ausführen:

Entweder, wenn wir den Inhalt der Nachricht nur zu Teilen wissen, da er sich ändert:

<code>
define mydoif DOIF ([sduino:&DMSG] =~ "u85#FF8081") (set Lamp on)
attr mydoif do always
</code>

Oder, wenn wir den Inhalt exakt kennen, dann auch als Vergleichsstring

<code>
define mydoif DOIF ([sduino:&DMSG] eq "u85#FF8081") (set relais on)
attr mydoif do always
</code>

Der Teil u85#FF8081 muss individuell angepasst werden, der Name eures SIGNALduino möglicherweise auch.

Als Alternative zu DOIF hier ein regex-verwendendes notify-Beispiel für einen Sender, der meint, zwei Codes alternierend senden zu müssen:

<code>
define n_sender_trigger notify sduino:UNKNOWNCODE.*u41#(13B72253|163873B3) { my_sender_trigger_indicate();; }
</code>

Selbstverfreilich muss in diesem Moment auch eine sub my_sender_trigger_indicate() definiert werden (z.B. in FHEM/99_myUtils.pm), die dort z.B. als Test eine Log-Ausgabe (Log3()) machen kann.

=== Das Logfile ===
Im Logfile ab [[Verbose]] 4 tauchen diverse Meldungen auf, deren Bedeutung kurz erläutert wird (verbose 3 unterdrückt diese Meldungen).

UPDATE: der folgende Bereich ist von einem weniger erfahrenen Zeitgenossen früher nach Kräften erweitert/geschrieben worden. Mittlerweile existiert aber ein neuer Inhalt [[Unbekannte_Funkprotokolle]] (siehe auch Erwähnung weiter oben), der als sehr gut beschrieben und unvergleichlich detailreicher bezeichnet werden muss ("endlich gibt es sowas!"). Der Bereich hier dürfte somit zwar für grundlegende Verdeutlichungen noch recht sinnvoll sein, der Inhalt sollte allerdings evt. in eine konsistente Dokumentation überarbeitet (verlagert/dedupliziert/reduziert) werden.

Die Protokolle (von der SIGNALDuino-Firmware gesendete Signal-Beschreibungs-Strings) können wie folgt unterschieden werden:

*MS - Nachricht mit Sync Puls: Hierzu ein Beispiel
:<code>MS;P0=-108;P1=395;P2=-1033;P3=-547;P4=-19932;P5=-8916;P6=1368;D=151313131312131313131313131313131312121212121313131313131312131212132;CP=1;SP=5;</code> P0-P6 sind die Signalpegel (Dauer und positiv/negativ). Hinter D= befindet sich die Abfolge der Signale. Die ersten beiden Ziffern 15 in D sind wie folgt zu lesen. Zuerst wurde ein Signal "1" also P1 mit 395 Mikrosekunden high (die Zeitdauer ergibt sich aufgrund der Mitteilung "P1=395") und anschließend ein Signal "5" also P5 mit 8916 Mikrosekunden low (die Zeitdauer ergibt sich aufgrund der Mitteilung "P5=-8916") gemessen. CP=1 ist die Referenz auf den Takt des Signales - der Basistakt ist in diesem Fall ~395 Mikrosekunden. SP=5 gibt die Referenz zum Syncpuls an, der das gesamte Signal einleitet. Welche Signalfolge nun eine binäre 1 bzw. 0 bedeutet, wird im SIGNALduino über die integrierte Protokoll Liste realisiert.

*MC - Nachricht vom Typ Manchester: Manchesterkodierte Signale können bereits sehr einfach im Arduino in eine Binärform umgewandelt werden. Es wird hier nach IEEE 802.3 umgewandelt. In Manchester Signalen gibt es lange und kurze Pulse. Deren Durchschnittswert wird mit LL (long low), LH (long high), SL (short low) und SH (short high) übermittelt. Zusätzlich, um das Protokoll schneller erkennen zu können, wird die Taktfrequenz mit übermittelt (C=429 Mikrosekunden). Die Daten befinden sich hinter D= und werden in HEX Form übergeben.
:<code>MC;LL=-1066;LH=904;SL=-562;SH=385;D=332B4B4D54D5554B552CD2D554B2B5354A;C=429;</code>

*MU - Message unsynced: Diese Art von Nachrichten sind nicht nach Manchester codiert und haben auch keinen erkennbaren Sync / Clock Signalpegel am Start der Nachricht. Bei diesen Nachrichtentypen ist es, im Vergleich zu den anderen, am wahrscheinlichsten, dass das übermittelte Signal unvollständig oder überhaupt kein Signal ist. Wie bei MS sind P0-P6 die Signalpegel und in D= wird die Abfolge der Signalpegel referenziert. CP=2 gibt auch hier die Referenz zum Takt an, allerdings muss dieser nicht korrekt erkannt worden sein.
:<code>MU;P0=1372;P1=-580;P2=362;P3=-1047;D=01212321212321212121212121212123212123212321232121212121212321;CP=2;</code>

Es erscheinen viele Meldungen dieser Art:

<pre>
Fingerprint for MU Protocol id xxxx -> yyy matches, trying to demodulate
sduino: Starting demodulation at Position 1
Fingerprint for MU Protocol id 28 -> IC Ledspot matches, trying to demodulate
sduino: Starting demodulation at Position 1
Fingerprint for MU Protocol id 29 -> HT12e remote matches, trying to demodulate
</pre>

Dies sind nun Bemühungen, anhand der von der SIGNALDuino-Firmware gelieferten rohen aber detaillierten Signal-Strings eine Vor-Analyse / Fingerprinting vorzunehmen.
Man könnte nun z.B. bei solchen Fingerprinting-Analysen erkennen:
* dass der Basis-Takt-Wert innerhalb eines charakteristischen Zeit-Bereichs liegt
* dass die Anzahl der Sync-Pulse eine präzise Zahl ist
* dass Längen erkannter Puls-Typen innerhalb eines Bereichs liegen

Mittels solcher Untersuchungen kann man also final hoffentlich hinreichend plausibel feststellen, "dass diese Aktivitäten offensichtlich(?) zu einer Funk-Komponente Rauchmelder von Hersteller XYZ gehören müssen, und man somit weiterleiten muss an ein (möglicherweise bereits existierendes) Userdaten-Dekodier-Modul für diese Herstellerkomponente".

Bei einer dann erfolgenden Demodulation des noch rohen SIGNALDuino-Strings könnte man z.B. (hoffentlich richtigerweise) annehmen, dass eine Signalpegel-Typ-Folge "13" eine binäre 1 bedeuten soll, während eine Folge "12" eine binäre 0 bedeuten soll. Man erhält aus dem Gesamt-Puls-String also nach vollständiger Demodulation eine Abfolge von vielen 0/1 Bits, die insgesamt ein Datenwort darstellen, mit einer gewissen Länge von NN bits (diese Längen-Angabe könnte übrigens - neben Namenssuche nach Hersteller oder Produkt etc. - ein wichtiges Such-Merkmal sein, ob andere Frameworks tatsächlich bereits wissen, wie Daten dieser Funk-Komponente zu dekodieren sind!). Dieses demodulierte Datenwort ist nun das finale Datenwort, welches einen Container für die Funk-Komponenten-Informationen darstellt (in diesem Container also beispielsweise enthalten: Temperatur, Feuchte, Akku-Status, ID, Alarm, ... - zumindest wenn nicht dummerweise der ganze Container erst einmal CRC- oder Crypto-verschlüsselt ist...).

Man muss an dieser Stelle unbedingt sagen, dass dieses Userdaten-Datenwort (einer bestimmten Hersteller-Funk-Komponente!) natürlich bei ''jeglichen'' Transceiver-Systemen ''immer'' gleich erkannt werden ''muss'' - an dieser Stelle ist also ganz klar, dass diese Daten an ''allgemeine'' FHEM-Module weitergeleitet (Dispatched) werden müssen, die nach Übernahme von Daten von ''jeglichen'' Transceiver-Systemen diese Daten immer auf die gleiche Weise ('''''generisch/zentral''''') für die jeweilige Hersteller-Funk-Komponente erledigen.

'''Die Abfolge ist also ganz klar:'''
Funk-Aktivität --> Transceiver-Gerät/Firmware (SIGNALDuino) --> maximal detailreich beschreibender Rx-Analyse-Output-String --> Fingerprinting-Grobzuordnung des (SIGNALDuino-Firmware-)Outputs (durch 00_SIGNALduino.pm) auf gerätespezifisches Verhalten --> ''generische/zentrale'' Dekodierung des gerätespezifischen Protokoll-Datenworts, in zentralen Grundsatz-Modulen wie z.B. <code>14_SD_WS.pm</code>).

Und wenn dann bei einer solchen Schritte-Abfolge irgendetwas noch fehlen/unpassend sein sollte, dann muss eben entsprechendes Development an gewissen Stellen erfolgen ;-)

====Minimieren (whitelist/blacklist) von unerwünschter Kommunikations-Aktivität/Einträgen====

"Unknown Code" bedeutet, dass der SIGNALduino Signaldaten empfangen und diese binär interpretiert hat. Diese Meldung soll uns nun aber mitteilen, dass es dann nicht weiter verarbeitet werden kann, da kein Modul existiert (oder kein Weiterleitungs-Dispatch zu einem bereits existierenden), welches diese Daten jetzt in ihre Bedeutung umwandeln kann.
:<code>sduino: Unknown code u1FFFFF0, help me!</code>

Außerdem kommt es gehäuft zu Logmeldungen und auch Events in ähnlicher Form:
:<code>SIGNALduino_unknown incomming msg: u85#FF8081</code>

Mittlerweile sind über 50 Protokolle für den SIGNALduino definiert. Dadurch kommt es vor, dass sich ein Signal mit mehr als einem Protokoll demodulieren lässt. Meist führt dies dann zu zusätzlichen "Unknown code"-Einträgen.

Derartige Einträge können mit dem Attribut WhitelistID minimiert werden. Dabei werden die Geräte, die nach Daten-Empfang tatsächlich verarbeitet werden sollen (also welche Protokolle vom FHEM Modul berücksichtigt werden), mit ihrer Protokollnummer in die WhitelistID aufgenommen.
Für Protokolle, die nicht berücksichtigt werden, gibt es weder Logeinträge noch Events. Diese werden im Programmablauf nicht berücksichtigt. Das spart zum einen Ressourcen und trägt auch zur Übersichtlichkeit bei.
Die Protokollnummer kann Tabelle [[#Unterst.C3.BCtzte_Ger.C3.A4te]] entnommen werden (hilfreich ist es auch, wenn in den verwendeten Geräten im Internal <gerätename>_DMSG nachgesehen wird). So bedeutet beispielsweise ein Eintrag der Form <code>W50#FF553335FFBC</code> dass dann das Protokoll #50 in die Whitelist aufzunehmen wäre (<code>attr sduino whitelist_IDs 50</code>).
{{Randnotiz|RNTyp=r|RNText=Achtung Schreibweise: Dokumentation oft als WhitelistID o.ä., aber Name ist whitelist_IDs!!
}}
Die Angabe erfolgt durch Komma getrennt: z.B.:
:<code>1,2,5,10</code>

=== Senden mit dem SIGNALduino ===
Der SIGNALduino kann etwas "raw senden", indem ihm das SIGNAL so übermittelt wird, wie er es moduliert. Hierzu muss der Befehl wie folgt eingegeben werden:

<code>
set sduino sendMsg P3#00111010#R4
</code>

Dieser Befehl moduliert die Bitfolge 00111010 mittels Protokoll #3 und wiederholt die Nachricht 4x.
Die Protokoll Nummer kann aus einer empfangenen Nachricht extrahiert werden. Ebenso die Bits.
<code>
sduino: extracted data 00111010 (bin)
sduino: Found Protocol id 3
</code>

Alternativ kann das Signal auch in einer "rohform" angegeben werden. Dies ist manchmal in speziellen Fällen notwendig:
<code>
set sduino raw SR;;R=3;;P0=4742;;P1=-1554;;P2=286;;P3=-786;;P4=649;;P5=-420;;D=0123234545234545452323232323454523234523454523232345454523232323452345234523452345;;
</code>

R=3 bedeutet, das Signal wird 3x gesendet.
Die Übertragung besteht aus den in D angegeben Pulsen, welche in P0-P5 definiert werden.
Die Daten kann man aus einer empfangenen MS oder MU Nachricht extrahieren.

Alternativ kann ab Version 3.2 auch eine vereinfachte Form eingegeben werden.

====Fehlersuche====

(Zielgerät reagiert nicht, etc.)

* Nachrichtenwiederholungsanzahl muss evt. für manche Geräte entsprechend groß eingestellt sein
* Sende-Takt-Wert (Clock) passt evt. nicht ganz, siehe z.B. Thread-Antwort [https://forum.fhem.de/index.php/topic,58397.msg775434.html#msg775434 Signalduino Version 3.3.1], wo für IT-Geräte ein Attribut anhand der CP= des Empfangsdaten-Logs modifiziert wird. ACHTUNG: dies kann entweder global das Internal-Attribut ITClock eines SIGNALduino-Transceiver-Devices sein, oder (viel besser da korrekt geräte-instanz-spezifische Konfiguration) das ITclock eines IT-Client-Devices.
{{Randnotiz|RNTyp=r|RNText=VORSICHT blöder Schreibweisen-Mismatch ITClock vs. ITclock!!
}}

== Fehlerbehandlung ==
Der SIGNALduino kann mit folgendem Befehl auf Werkseinstellungen zurückgesetzt werden:
:<code>get raw e</code>
als Antwort kommt dann "ccFactoryReset done". Ob ein solcher Reset nötig ist, erkennt man an der Antwort auf den Befehl "get config", auf den dann die Meldung "config: MS=1;MU=1;MC=1" folgen sollte.

In der Firmware sind die folgenden Befehle eingebaut

*:<code>get raw C<reg></code>
<reg> is a (two digit) hex number: return the value of the cc1101 register. <reg>=99 dumps the first 48 registers.
Example: C35 -> C35 = 0D
*:<code>get raw e</code>
EEPROM / factory reset. resets all eeprom values without reboot
*:<code>get raw r<AA></code>
Read eeprom (da das "R" beim SIGNALDuino bereits mit freeram belegt ist, habe ich das "r" verwendet)
*:<code>get raw r<AA>n</code>
Read 16 byte from eeprom (z.B. r00n)
*:<code>get raw W<AA><DD></code>
Write eeprom (schreibt einen Wert ins EEPROM und ins CC1101 Register. Die eeprom Adresse hat einen Offset von 2. z.B W041D schreibt 1D ins Register 2)

Die Sendeleistung lässt sich mit
:<code>get sduino ccreg 3E</code>

prüfen, wobei die Rückmeldung wie folgt zu lesen ist:
"-10_dBm" => '34',
"-5_dBm" => '68',
"0_dBm" => '60',
"5_dBm" => '84',
"7_dBm" => 'C8',
"10_dBm" => 'C0'
Dabei wird die Sendeleistung dauerhaft mit dem Befehl
:<code>set sduino cc1101_patable <value></code>
hochgeschaltet (<value> durch den Wert ersetzen).

Weitere Firmware-Befehle sind im Thread-Beitrag {{Link2Forum|Topic=58396|Message=497921}} zu finden.

== Foren Links ==
* {{Link2Forum|Topic=38402|LinkText=Forenthread - Ankündigung}}
* {{Link2Forum|Topic=58396|LinkText=SIGNALDuino Empfänger Firm- und Hardware}}
* {{Link2Forum|Topic=58397|LinkText=Signalduino Entwicklung Version 3.3.1 }}
* [http://www.rflink.nl/blog2/wiring Beschreibung zu diversen Empfängern und Verbesserung der Empfangsleistung]
* [[SIGNALduino in die Arduino Entwicklungsumgebung einbinden]]
* [[Somfy via SIGNALduino]]

[[Kategorie:Interfaces]]
[[Kategorie:Arduino]]
[[Kategorie:433MHz]]
[[Kategorie:868MHz]]

SIGNALduino

2019-07-23T09:14:32Z

Mahowi: /* Unterstützte Geräte */ Ergänzungen zu Flamingo

{{Infobox Modul
|ModPurpose=Empfang und Verarbeitung von digitalen Signalen
|ModType=d
|ModFTopic=38402
|ModCmdRef=SIGNALduino
|ModForumArea=Sonstige Systeme
|ModTechName=00_SIGNALduino.pm
|ModOwner=Sidey ({{Link2FU|8018|Forum}}/[[Benutzer Diskussion:Sidey|Wiki]])
}}

== Einleitung ==
=== Übersicht ===
Unter den Namen SIGNALduino versteht man sowohl den Low-Cost Empfänger für digitale Signale (vergleichbar dem [[CUL]]) als auch das gleichnamige Modul mit dem Dateinamen 00_SIGNALduino.pm. Mit dem SIGNALduino kann man entweder 433 oder 868 MHz-Geräte auslesen und ansprechen. Der SIGNALduino funktioniert auch mit anderen Medien wie Infrarot oder direkter Kabelverbindung.

Der SIGNALduino(-Stick) erkennt Signale anhand von Mustern und gibt sie (als maximal detaillierte Beschreibung einer Signalabfolge) dann schlicht sofort nur noch an FHEM zur Auswertung (Dekodierung) weiter. Auch nicht erkannte Signale werden an FHEM übergeben.
Aufgabe des SIGNALduino (Firmware/Stick) ist es also nur, Signal-Aktivitäten zu erfassen und maximal präzise (als kurzer Text-String) zu beschreiben.
Alles weitere (echte, finale Auswertung / Zuweisung dieser Signal-Daten) wird dann auf einer großen Box (Raspberry o.ä.) gemacht.

=== Vorteil gegenüber einem CUL/FHEMduino ===
Der SIGNALduino hat den Vorteil einer sehr schnellen Demodulation des Funksignals. Sollen weitere Protokolle dekodiert werden, so muss dazu nur ein passendes FHEM Modul entwickelt oder ein universelles Modul erweitert werden (also auf flexibel direkt updatebarer Rechner-Seite!!). Änderungen am Arduino-Firmware-Code sind normalerweise nicht notwendig (sofern die grundsätzliche Signal-Klassifizierung des Sticks korrekt funktioniert - leider nicht immer, z.B.: [https://github.com/RFD-FHEM/SIGNALDuino/issues/65 MU-Nachrichten werden z.T. als MC erkannt]).

Ein großer Vorteil des SIGNALduino besteht darin, dass auch Geräte mit leicht abweichende Frequenzen steuerbar sind; so empfangen die Somfy-Rolladenmotoren beispielsweise auf 433.42 und nicht, wie bei anderen Geräten sehr oft üblich, auf 433.92 MHz. Die Frequenzumstellung stellt für den SIGNALduino kein Problem dar.

Ebenso kann man den SIGNALduino direkt an den Sendeausgang eines Sensors anbinden und die digitalen Signale empfangen, dabei bitte aber auf die passenden Spannungen achten, denn ein Arduino Nano verträgt nur 5V.

=== Entwicklungsversion ===
Der SIGNALduino wird derzeit aktiv weiterentwickelt, siehe dazu https://github.com/RFD-FHEM. Die Version von Sidey wird [https://forum.fhem.de/index.php/topic,58396.0.html hier ]genauer beschrieben.

Es existiert eine weitere Entwicklungsversion, siehe dazu die [https://forum.fhem.de/index.php/topic,82379.msg744554.html#msg744554 Firmware] (hierzu gibt es auch eine private Version des [https://github.com/Ralf9/RFFHEM/issues/2 Moduls]).

== Hardware ==
=== Controller ===

Der SIGNALduino (Hardware) wird über den USB Port angeschlossen, er kann aber auch mit zusätzlichen ESP Modulen über ein WLAN angebunden werden.

Der SIGNALduino basiert auf einem [http://arduino.cc/de/Main/ArduinoBoardNano Arduino Nano], die Schaltung entspricht der des [[FHEMduino]] oder dem [[Selbstbau_CUL]]:
* Entweder wird ein Arduino mit einfachen Sende- und Empfangsmodulen verwendet, dann ist die Verkabelung identisch zum [[FHEMduino]]
* Oder es wird ein CC1101 Transceiver verwendet, dann ist die Verkabelung identisch zum [[Selbstbau_CUL]].
* Zuletzt gibt es ein fertig konfektioniertes Modul von In-Circuit mit Radino CC1101 Varianten, link zum [http://shop.in-circuit.de/index.php Hersteller].

Achten Sie beim Selbstbau auf die entsprechenden Sender-Empfänger. Der sehr preiswert angebotene XY-MK-5V hat sich als zu unzuverlässig erwiesen, während anscheinend beim CC1101 (insbesondere der "grünen Version") keine Probleme auftreten.

Es stehen auch für den [https://www.arduino.cc/en/Main/arduinoBoardUno UNO] und [https://www.arduino.cc/en/Main/ArduinoBoardProMini PRO Mini] Firmware-Dateien zur Verfügung. Die ausgelieferte Firmware läuft nur auf Mikrocontrollern mit 16 MHz; wer einen Mikrocontroller mit 8 MHz verwenden möchte, muss die Firmware selbst compilieren. Die SW ist auf [https://github.com/RFD-FHEM/SIGNALDuino github]. Vorgesehen ist nur die Übersetzung unter Windows mit Visual Studio und dem Visual Micro Zusatz. Es gibt aber auch eine Anleitung, wie man mit der [[Arduino]] IDE oder einem Makefile [[SIGNALduino Compilieren]] kann.

Es gibt auch eine Variante des SIGNALduino, die auf einem [[ESP8266]] nativ läuft, diese funktioniert seit Anfang 2018 annehmbar, allerdings befindet diese sich noch in einer Entwicklungsphase.

An den "SIGNALESP" kann auch ein CC1101 via SPI angebunden werden:

{||
!CC1101 Bezeichnung
!ESP Pin
|-
|CLK||GPIO14
|-
|MOSI||GPIO13
|-
|MISO||GPIO12
|-
|CSN||GPIO15
|-
|GDO0||GPIO4
|-
|GDO2||GPIO5
|}

Wird ein einfacher Empfänger / Sender Kombination verwendet, dann über die PINs:

{||
! Bezeichnung
! ESP Pin
|-
|Transmitter||GPIO4
|-
|Receiver||GPIO5
|}

=== Sendemodule ===
{{Randnotiz|RNTyp=r|RNText=Viele user berichten über Empfangsprobleme bei Nutzung des XY-MK-5V; es wird ausdrücklich empfohlen, ein anderes Empfangsmodul zu nutzen!}}
[[Datei:Fhemduino_schematic.png|200px|thumb|right|Beispielschaltplan SIGNAL(FHEM)duino]]

Mit einem Arduino-Nano und folgenden, billigen Sende- und Empfangsmodulen können Sie einen SIGNALduino bauen:
* FS1000A Dies ist das Sendemodul (TX) und wird oft im Set mit dem billigen XY-MK-5V-Empfänger angeboten (etwa 5€).
* RXB6 Das ist das empfohlene Empfangsmodul (RX), statt XY-MK-5V, etwa 5€ aus Deutschland.

Die Verkabelung erfolgt analog zum [[FHEMduino]] und das bedeutet (Arduino -> Modul):
* PIN D2 an DATA des RX-Moduls
* PIN D11 an DATA des TX-Moduls (PIN links mit Beschriftung ATAD)

Zusätzlich muss noch jeweils GND und 5V des Arduino mit dem GND bzw. VCC des Moduls verbunden werden.

Jetzt fehlen noch die Antennen. Dafür braucht man ein 17,2 cm langes Stück Kupferdraht, das wird beim Anschluss "ANT" jeweils am Modul angelötet (anfängergeeignet).

== Software ==

=== USB-ID ermitteln ===
Bevor der SIGNALduino mit dem FHEM Server (im Beispiel hier ein Raspberry PI) verbunden werden kann, muss die USB-Schnittstelle ermittelt werden. Hierzu bitte auf dem Terminal den Befehl
<pre> ls -l /dev/serial/by-id </pre>
ausführen. Beispielhaft sieht das Ergebnis etwa so aus:
''lrwxrwxrwx 1 root root 13 Jan 31 00:02 '''usb-FTDI_FT232R_USB_UART_A903N5T5-if00-port''' -> ../../ttyUSB0''
Damit ist der Anschluss des SIGNALduino bestimmt und das Gerät kann wie im nächsten Abschnitt beschrieben definiert werden. Zuvor muss noch das Modul geladen werden.

=== FHEM-Modul laden ===
Die SIGNALduino Module werden über das FHEM [[update]] verteilt, sobald die Änderungen einen "stabilen" und alltags tauglichen Zustand haben. Aktuell wird dort die Version 3.4.0 seit 20.07.2019 verteilt.

Die in der Entwicklung befindliche Version (3.4.x) kann mit folgenden Befehlen geladen werden:

* FHEM aktualisieren: <code>update</code>
* SIGNALduino Modul aktualisieren: <code>update all <nowiki>https://raw.githubusercontent.com/RFD-FHEM/RFFHEM/dev-r34/controls_signalduino.txt</nowiki></code> Durch das Update von FHEM wird sichergestellt, dass das Modul mit FHEM arbeitet.
*Danach kann das Gerät wie folgt definiert werden (die Spezifikation des USB-Anschlusses muss dabei an die aktuellen Gegebenheiten angepasst werden):
:<code>define <eigener-SIGNALduino-Name> SIGNALduino /dev/serial/by-id/usb-FTDI_FT232R_USB_UART_A903N5T5-if00-port0@57600</code>
* Solltet Ihr einen SIGNALESP via IP einbinden wollen ist die Syntax
:<code>define <eigener-SIGNALESP-Name> SIGNALduino <ip-adresse>:23</code>
Nach dem Einbinden wird der SIGNALduino, falls er erkannt wird, im Status "Opened" angezeigt.

Für neuere Entwicklungen kann in FHEM auch dauerhaft die developer Version aktualisiert werden:
<code>update add <nowiki>https://raw.githubusercontent.com/RFD-FHEM/RFFHEM/dev-r34/controls_signalduino.txt</nowiki></code>
Danach wird FHEM bei dem normalen Update-Befehl immer automatisch die aktuelle dev Version laden.

Die nachfolgenden Beispiel-Befehle verwenden "sduino" als <eigener-SIGNALduino-Name>.

==== Flashen des Arduino mit der SIGNALduino Firmware ====
Falls avrdude noch nicht vorhanden ist, kann es mit folgendem Befehl installiert werden:
:<code>sudo apt-get install avrdude</code>

In FHEM ist der SIGNALduino mit dem Status "Open" vorhanden. Jetzt müssen wir FHEM noch mitteilen, welche Hardware wir angeschlossen haben. Über das Attribut ''hardware'' lässt sich zwischen den mitgelieferten Firmware-Dateien wechseln. Solltet ihr einen Nano mit cc1101 Transceiver verwenden, so wählt bitte folgende Hardware
:<code>attr sduino hardware nanoCC1101</code>
sonst üblicherweise
:<code>attr sduino hardware nano328</code>

Dann muss mitgeteilt werden, welche Version man geladen haben will: stable oder testing. Derzeit ist nur testing verfügbar:
:<code>attr sduino updateChannelFW testing</code>
Nun wird die entsprechende Firmware heruntergeladen. Dies geschieht durch den Befehl
:<code>get sduino availableFirmware</code>
Anschließend kann der ''flash'' Befehl abgesetzt werden:
:<code>set sduino flash <und-dann-auswaehlen></code>
Dadurch wird der Arduino mit der gewählten Firmware geflasht. Das Ergebnis wird im Webinterface direkt angezeigt.

Alternativ kann auch der Flash-Befehl mit einem Dateinamen aufgerufen werden. Diese Möglichkeit sollte jedoch nur verwendet werden, wenn die SIGNALduino Firmware selbst compiliert wurde und eine andere Hardware verwendet wird. Der Flash-Befehl wird wie folgt aufgerufen:
:<code>set sduino flash FHEM/firmware/SIGNALduino_mega2560.hex</code>
(je nachdem wo und unter welchem Namen die .hex Datei abgelegt wurde)

==== Flashen einer Firmware über HTTP ====
Die Firmware wird in absehbarer Zeit nicht mehr über den Update Mechanismus verteilt werden.
Damit die passende Firmware auf den SIGNALduino geladen werden kann, wird diese dann über HTTP geladen.

==== Vorabversion einer Firmware ====
Die Firmware des SIGNALduino wird ebenso wie das FHEM Modul auch weiter entwickelt.
Die Entwickler sind auf Tests und Rückmeldungen der Nutzer angewiesen, da leider nicht alle Sensoren vorher getestet werden können.

Aktuell (November 2018) ist noch die Version 3.3.1 in Entwicklung. Diese steht aktuell in einer Release Candidate Version zur Verfügung.

Für die folgenden Microcontroller kann man die Firmware seit 21.02.2019 auch direkt downloaden und teilweise flashen.
Dazu muss das Attribut hardware auf einen gültigen Wert angepasst werden!
Über den GET Befehl availableFirmware werden dann für die hinterlegte Hardware die passenden Versionen gesucht. Über das Attribut updateChannelFW kann zwischen "stable" und "testing" definiert werden, welche Art von Firmware angeboten werden soll.

Nachdem die Firmwareversion erfragt wurde, bietet der set flash Befehl eine Auswahlliste an. Wird ein Flash Befehl mit einer der Versionen ausgewählt, wird diese Version zunächst heruntergeladen und bei den AVR Versionen auch versucht diese mittels avrdude zu flashen.
Die Firmware für den ESP8266 kann aktuell leider noch nicht über diesen Befehl aktualisiert werden.

Alternativ funktioniert aber auch die Option, dem Flash Befehl eine URL zu übergeben. Dann wird die Datei aus der URL heruntergeladen und auch versucht diese zu Flashen. z.B.
SIGNALDuino_nanocc1101.hex für einen Nano mit CC1101

<code>set sduino flash https://github.com/RFD-FHEM/SIGNALDuino/releases/download/3.3.1-RC10/SIGNALDuino_nanocc1101release.hex
</code>

oder
SIGNALESP_.hex (mit cc1101) für einen ESP8266 und 1 MB Flash
<code>set ipduino flash https://github.com/RFD-FHEM/SIGNALDuino/releases/download/nightly/SIGNALDuino_ESP8266cc1101nightly.hex
</code>

!Achtung, aktuell wird die Firmware für den ESP dadurch nur herunter geladen. Flashen müsst ihr leider immer noch über ein passendes Tool
z.B. [https://github.com/nodemcu/nodemcu-flasher ESP8266Flasher.exe] oder Esptool und einer seriellen Konsole.
Auch ist zu beachten, es handelt sich hierbei tatsächlich um ein Binary und nicht um ein Hex File.

Nach dem Booten des ESPs, spannt dieser ein eigenes WLAN auf. Habt ihr euch damit verbunden, könnt ihr den ESP mit eurem vorhandenen WLAN verbinden.

Die Haupt-Seite für Firmware-Releases findet sich unter https://github.com/RFD-FHEM/SIGNALDuino/releases/ .
Dort kann auch eine Änderungshistorie eingesehen werden.
==== Flashen eines radino Boards mit ATmega32U4 ====

Diese Funktion steht seit 21.02.2019 nun auch in der via FHEM aktualisierten version zur Verfügung:

Auch sind Berichte bekannt, dass der Radino beim Neustart von FHEM nicht korrekt initialisiert wird.
Weiterhin ist zu beachten, dass der Bootloader eine andere USB ID bekommt und diese im Attribut flashCommand hinterlegt werden muss.

==== Fehler beim Flashen ====
Sollte bei einem Flash Vorgang ein Fehler auftreten, solltet ihr zunächst im Logfile mit Verbose 5 nachsehen.

Findet ihr dort keine Fehlermeldung, gibt es noch ein separates Flashlog, welches ihr über einen Browser aufrufen könnt. Dazu müsst ihr nur den Folgenden Pfad an euren Servernamen anhängen:
<code>
/fhem/FileLog_logWrapper?dev=Logfile&type=text&file=SIGNALduino-Flash.log
</code>

=== Geräteerkennung ===
==== Unterstützte Geräte ====
Für die folgenden Geräte gibt es derzeit (2017) eine Unterstützung für den Betrieb mit FHEM. Die Geräte werden [[autocreate|automatisch erkannt]] und in der Konfiguration eingetragen, wenn der SIGNALduino läuft.
Bitte Geräte mit sehr präzisen Referenzen hier listen (Produktnummer, Protokoll-Variantenname etc.), damit eine globale Suche/Verifikation maximal erfolgreich ist. In der detaillierten Liste [[Geprüfte_Geräte]] lassen sich die Geräte näher identifizieren.
{|class="wikitable"
! style="text-align:left;"| Produkt
! (E)mpfangen<br />(S)enden
! Hinweise
! Verwendetes Modul
! Protokoll ID
|-
|Conrad Wetterstation KW9110||E S||Sensor: KW9010, neben Temperatur u. Luftfeuchte werden auch Trend, Batterie u. Kanal erfasst|| CUL_TCM97001 || 0.3
|-
|TCM Wetterstation (97001 und 21xxx Serie)||E|| || CUL_TCM97001 || 0
|-
|ABS Wetterstation (ABS 700)||E|| || CUL_TCM97001 || 0
|-
|Prologue Wetterstation ||E|| ||CUL_TCM97001 || 0
|-
|Rubicson Wetterstation ||E|| ||CUL_TCM97001 ||0
|-
|NC_WS Wetterstation ||E|| ||CUL_TCM97001 || 0
|-
|[http://www.gt-support.de/ GT-WT-02 Wetterstation]||E|| ||CUL_TCM97001 || 0
|-
|AURIOL Wetterstation ||E|| ||CUL_TCM97001 || 0
|-
|Mebus Wetterstation ||E|| ||CUL_TCM97001 || 0
|-
|Intertechno Funkschalter||E S|| ||IT || 3,4,5,17
|-
|<strike>Conrad RSL Funkschalter</strike>||E S|| Funktioniert aktuell nicht || SIGNALduino_RSL ||
|-
|[http://global.oregonscientific.com/product_view.php?id=5 Oregon Scientific Wettersensoren]||E || Protokoll V2 & V3 implementiert || OREGON || 10
|-
|Bresser Temp/Hydro Sensor||E || || Hideki || 12
|-
|[https://de.hama.com/00104985/hama-aussensensor-ts33c-fuer-wetterstation Hama TS33C]||E || || Hideki || 12
|-
|TFA Temp/Hydro Sensor||E || || Hideki || 12
|-
|Lacrosse TX2/TX3 Sensoren||E || || CUL_TX || 8
|-
|TFA 30320902||E || || SD_WS07 || 7
|-
|Eurochron eas800z||E || || SD_WS07 || 7
|-
|Technoline WS6750/TX70DTH||E || || SD_WS07 || 7
|-
|FreeTec Außenmodul NC-7344||E || || SD_WS07 || 7
|-
|CTW600||E || || SD_WS09 || 9
|-
|WH1080||E || || SD_WS09 || 9
|-
|Visivon remote pt4450||E || || none || 24
|-
|Einhell HS 434/6||E || || none || 21
|-
|Flamingo FA20RF / FA21RF / FA22RF Rauchmelder||E || || FLAMINGO || 13,13.1,13.2
|-
|mumbi m-FS300||E || || none || 26,27
|-
|TFA 30.3200||E || || none || 33
|-
|Livolo||E|| || none || 20
|-
|Smartwares RM174RF/2 (RM174RF-001CPR) 4500177571 ||E [S?]|| IT EV1527; TODO herausfinden: Alarmierung (wie Alarmton getriggered werden kann); Batterieinfo? || IT || 3
|-
|Smartwares SH5-TSO-A||E S|| || IT || ?
|-
|X10 Security Devices||E|| || || 39
|-
|[[Somfy_via_SIGNALduino|Somfy RTS]]||E S|| || SOMFY || 43
|}
Bei einigen Intertechno-Funksteckdosen (Brennenstuhl) kann es zu Empfangsproblemen kommen. Hier muss die Taktrate, mit der gesendet wird, angepasst werden. Dazu muss für ''Funksteckdose'' (also sauber per-Client-Instanz-spezifisch, NICHT SIGNALduino-Transceiver-global) das Attribut
:<code>attr <Funksteckdose> ITclock 300</code>
gesetzt werden, der Standardwert ist 250.

==== Mein Gerät wird in FHEM nicht erkannt ====
1. Prüfen, ob vom Sensor die Signaldaten (verbose >=4) erkannt werden. Sobald ihr die empfangenen Signaldaten im Logfile zuordnen könnt, geht es weiter mit:

2. Eröffnet ein Thema unter [https://github.com/RFD-FHEM/RFFHEM/issues github] nach folgendem Muster:
:''Thema : Protokoll für <Das verwendete Gerät>
:Inhalt: Eure Hardware z.B. Arduino Nano mit XYZ Empfänger, oder Arduino Nano direkt an Gerät x

3. Auszug aus dem Logfile, welches zum Gerät gehört.
:''Alles was ihr sonst noch über das Gerät und die übertragenen Daten wisst.

Im Forum solltet ihr solche Fragen besser nicht posten, wenn das Gerät noch nicht unterstützt wird, dazu ist Github besser geeignet. Inzwischen wurde im Wiki eine eigene Seite eröffnet, die sich mit der Erkennung unbekannter Protokolle beschäftigt: [[Unbekannte_Funkprotokolle#Ansatz_1_-_Versuchen|Unbekannte_Funkprotokolle]].

==== Es wird ein Protokoll erkannt, Autocreate legt aber kein device an ====
Im SIGNALduino sind >30 Protokolle implementiert. Jedoch gibt es nur wenige Module, welche diese Protokolle verarbeiten.
Teilweise ist das auch nicht zwingend notwendig, um seine Anforderungen zu erfüllen. Insbesondere für Schalter bzw. Sensoren, die nur zwei Zustände kennen, geht es meist ohne Modul und automatisch angelegtem Gerät.

Nehmen wir an, wir haben einen Schalter. Dieser kann einen oder zwei Zustände senden.
Im FHEM Log (und, insbesondere, im FHEMWEB Event Monitor) tauchen Meldungen ähnlich dieser auf

<code>
2015.11.15 15:52:23 4: SIGNALduino_unknown incomming msg: u85#FF8081
</code>

Wir können mit Hilfe des Modules DOIF auf diese Nachricht eine Aktion ausführen:

Entweder, wenn wir den Inhalt der Nachricht nur zu Teilen wissen, da er sich ändert:

<code>
define mydoif DOIF ([sduino:&DMSG] =~ "u85#FF8081") (set Lamp on)
attr mydoif do always
</code>

Oder, wenn wir den Inhalt exakt kennen, dann auch als Vergleichsstring

<code>
define mydoif DOIF ([sduino:&DMSG] eq "u85#FF8081") (set relais on)
attr mydoif do always
</code>

Der Teil u85#FF8081 muss individuell angepasst werden, der Name eures SIGNALduino möglicherweise auch.

Als Alternative zu DOIF hier ein regex-verwendendes notify-Beispiel für einen Sender, der meint, zwei Codes alternierend senden zu müssen:

<code>
define n_sender_trigger notify sduino:UNKNOWNCODE.*u41#(13B72253|163873B3) { my_sender_trigger_indicate();; }
</code>

Selbstverfreilich muss in diesem Moment auch eine sub my_sender_trigger_indicate() definiert werden (z.B. in FHEM/99_myUtils.pm), die dort z.B. als Test eine Log-Ausgabe (Log3()) machen kann.

=== Das Logfile ===
Im Logfile ab [[Verbose]] 4 tauchen diverse Meldungen auf, deren Bedeutung kurz erläutert wird (verbose 3 unterdrückt diese Meldungen).

UPDATE: der folgende Bereich ist von einem weniger erfahrenen Zeitgenossen früher nach Kräften erweitert/geschrieben worden. Mittlerweile existiert aber ein neuer Inhalt [[Unbekannte_Funkprotokolle]] (siehe auch Erwähnung weiter oben), der als sehr gut beschrieben und unvergleichlich detailreicher bezeichnet werden muss ("endlich gibt es sowas!"). Der Bereich hier dürfte somit zwar für grundlegende Verdeutlichungen noch recht sinnvoll sein, der Inhalt sollte allerdings evt. in eine konsistente Dokumentation überarbeitet (verlagert/dedupliziert/reduziert) werden.

Die Protokolle (von der SIGNALDuino-Firmware gesendete Signal-Beschreibungs-Strings) können wie folgt unterschieden werden:

*MS - Nachricht mit Sync Puls: Hierzu ein Beispiel
:<code>MS;P0=-108;P1=395;P2=-1033;P3=-547;P4=-19932;P5=-8916;P6=1368;D=151313131312131313131313131313131312121212121313131313131312131212132;CP=1;SP=5;</code> P0-P6 sind die Signalpegel (Dauer und positiv/negativ). Hinter D= befindet sich die Abfolge der Signale. Die ersten beiden Ziffern 15 in D sind wie folgt zu lesen. Zuerst wurde ein Signal "1" also P1 mit 395 Mikrosekunden high (die Zeitdauer ergibt sich aufgrund der Mitteilung "P1=395") und anschließend ein Signal "5" also P5 mit 8916 Mikrosekunden low (die Zeitdauer ergibt sich aufgrund der Mitteilung "P5=-8916") gemessen. CP=1 ist die Referenz auf den Takt des Signales - der Basistakt ist in diesem Fall ~395 Mikrosekunden. SP=5 gibt die Referenz zum Syncpuls an, der das gesamte Signal einleitet. Welche Signalfolge nun eine binäre 1 bzw. 0 bedeutet, wird im SIGNALduino über die integrierte Protokoll Liste realisiert.

*MC - Nachricht vom Typ Manchester: Manchesterkodierte Signale können bereits sehr einfach im Arduino in eine Binärform umgewandelt werden. Es wird hier nach IEEE 802.3 umgewandelt. In Manchester Signalen gibt es lange und kurze Pulse. Deren Durchschnittswert wird mit LL (long low), LH (long high), SL (short low) und SH (short high) übermittelt. Zusätzlich, um das Protokoll schneller erkennen zu können, wird die Taktfrequenz mit übermittelt (C=429 Mikrosekunden). Die Daten befinden sich hinter D= und werden in HEX Form übergeben.
:<code>MC;LL=-1066;LH=904;SL=-562;SH=385;D=332B4B4D54D5554B552CD2D554B2B5354A;C=429;</code>

*MU - Message unsynced: Diese Art von Nachrichten sind nicht nach Manchester codiert und haben auch keinen erkennbaren Sync / Clock Signalpegel am Start der Nachricht. Bei diesen Nachrichtentypen ist es, im Vergleich zu den anderen, am wahrscheinlichsten, dass das übermittelte Signal unvollständig oder überhaupt kein Signal ist. Wie bei MS sind P0-P6 die Signalpegel und in D= wird die Abfolge der Signalpegel referenziert. CP=2 gibt auch hier die Referenz zum Takt an, allerdings muss dieser nicht korrekt erkannt worden sein.
:<code>MU;P0=1372;P1=-580;P2=362;P3=-1047;D=01212321212321212121212121212123212123212321232121212121212321;CP=2;</code>

Es erscheinen viele Meldungen dieser Art:

<pre>
Fingerprint for MU Protocol id xxxx -> yyy matches, trying to demodulate
sduino: Starting demodulation at Position 1
Fingerprint for MU Protocol id 28 -> IC Ledspot matches, trying to demodulate
sduino: Starting demodulation at Position 1
Fingerprint for MU Protocol id 29 -> HT12e remote matches, trying to demodulate
</pre>

Dies sind nun Bemühungen, anhand der von der SIGNALDuino-Firmware gelieferten rohen aber detaillierten Signal-Strings eine Vor-Analyse / Fingerprinting vorzunehmen.
Man könnte nun z.B. bei solchen Fingerprinting-Analysen erkennen:
* dass der Basis-Takt-Wert innerhalb eines charakteristischen Zeit-Bereichs liegt
* dass die Anzahl der Sync-Pulse eine präzise Zahl ist
* dass Längen erkannter Puls-Typen innerhalb eines Bereichs liegen

Mittels solcher Untersuchungen kann man also final hoffentlich hinreichend plausibel feststellen, "dass diese Aktivitäten offensichtlich(?) zu einer Funk-Komponente Rauchmelder von Hersteller XYZ gehören müssen, und man somit weiterleiten muss an ein (möglicherweise bereits existierendes) Userdaten-Dekodier-Modul für diese Herstellerkomponente".

Bei einer dann erfolgenden Demodulation des noch rohen SIGNALDuino-Strings könnte man z.B. (hoffentlich richtigerweise) annehmen, dass eine Signalpegel-Typ-Folge "13" eine binäre 1 bedeuten soll, während eine Folge "12" eine binäre 0 bedeuten soll. Man erhält aus dem Gesamt-Puls-String also nach vollständiger Demodulation eine Abfolge von vielen 0/1 Bits, die insgesamt ein Datenwort darstellen, mit einer gewissen Länge von NN bits (diese Längen-Angabe könnte übrigens - neben Namenssuche nach Hersteller oder Produkt etc. - ein wichtiges Such-Merkmal sein, ob andere Frameworks tatsächlich bereits wissen, wie Daten dieser Funk-Komponente zu dekodieren sind!). Dieses demodulierte Datenwort ist nun das finale Datenwort, welches einen Container für die Funk-Komponenten-Informationen darstellt (in diesem Container also beispielsweise enthalten: Temperatur, Feuchte, Akku-Status, ID, Alarm, ... - zumindest wenn nicht dummerweise der ganze Container erst einmal CRC- oder Crypto-verschlüsselt ist...).

Man muss an dieser Stelle unbedingt sagen, dass dieses Userdaten-Datenwort (einer bestimmten Hersteller-Funk-Komponente!) natürlich bei ''jeglichen'' Transceiver-Systemen ''immer'' gleich erkannt werden ''muss'' - an dieser Stelle ist also ganz klar, dass diese Daten an ''allgemeine'' FHEM-Module weitergeleitet (Dispatched) werden müssen, die nach Übernahme von Daten von ''jeglichen'' Transceiver-Systemen diese Daten immer auf die gleiche Weise ('''''generisch/zentral''''') für die jeweilige Hersteller-Funk-Komponente erledigen.

'''Die Abfolge ist also ganz klar:'''
Funk-Aktivität --> Transceiver-Gerät/Firmware (SIGNALDuino) --> maximal detailreich beschreibender Rx-Analyse-Output-String --> Fingerprinting-Grobzuordnung des (SIGNALDuino-Firmware-)Outputs (durch 00_SIGNALduino.pm) auf gerätespezifisches Verhalten --> ''generische/zentrale'' Dekodierung des gerätespezifischen Protokoll-Datenworts, in zentralen Grundsatz-Modulen wie z.B. <code>14_SD_WS.pm</code>).

Und wenn dann bei einer solchen Schritte-Abfolge irgendetwas noch fehlen/unpassend sein sollte, dann muss eben entsprechendes Development an gewissen Stellen erfolgen ;-)

====Minimieren (whitelist/blacklist) von unerwünschter Kommunikations-Aktivität/Einträgen====

"Unknown Code" bedeutet, dass der SIGNALduino Signaldaten empfangen und diese binär interpretiert hat. Diese Meldung soll uns nun aber mitteilen, dass es dann nicht weiter verarbeitet werden kann, da kein Modul existiert (oder kein Weiterleitungs-Dispatch zu einem bereits existierenden), welches diese Daten jetzt in ihre Bedeutung umwandeln kann.
:<code>sduino: Unknown code u1FFFFF0, help me!</code>

Außerdem kommt es gehäuft zu Logmeldungen und auch Events in ähnlicher Form:
:<code>SIGNALduino_unknown incomming msg: u85#FF8081</code>

Mittlerweile sind über 50 Protokolle für den SIGNALduino definiert. Dadurch kommt es vor, dass sich ein Signal mit mehr als einem Protokoll demodulieren lässt. Meist führt dies dann zu zusätzlichen "Unknown code"-Einträgen.

Derartige Einträge können mit dem Attribut WhitelistID minimiert werden. Dabei werden die Geräte, die nach Daten-Empfang tatsächlich verarbeitet werden sollen (also welche Protokolle vom FHEM Modul berücksichtigt werden), mit ihrer Protokollnummer in die WhitelistID aufgenommen.
Für Protokolle, die nicht berücksichtigt werden, gibt es weder Logeinträge noch Events. Diese werden im Programmablauf nicht berücksichtigt. Das spart zum einen Ressourcen und trägt auch zur Übersichtlichkeit bei.
Die Protokollnummer kann Tabelle [[#Unterst.C3.BCtzte_Ger.C3.A4te]] entnommen werden (hilfreich ist es auch, wenn in den verwendeten Geräten im Internal <gerätename>_DMSG nachgesehen wird). So bedeutet beispielsweise ein Eintrag der Form <code>W50#FF553335FFBC</code> dass dann das Protokoll #50 in die Whitelist aufzunehmen wäre (<code>attr sduino whitelist_IDs 50</code>).
{{Randnotiz|RNTyp=r|RNText=Achtung Schreibweise: Dokumentation oft als WhitelistID o.ä., aber Name ist whitelist_IDs!!
}}
Die Angabe erfolgt durch Komma getrennt: z.B.:
:<code>1,2,5,10</code>

=== Senden mit dem SIGNALduino ===
Der SIGNALduino kann etwas "raw senden", indem ihm das SIGNAL so übermittelt wird, wie er es moduliert. Hierzu muss der Befehl wie folgt eingegeben werden:

<code>
set sduino sendMsg P3#00111010#R4
</code>

Dieser Befehl moduliert die Bitfolge 00111010 mittels Protokoll #3 und wiederholt die Nachricht 4x.
Die Protokoll Nummer kann aus einer empfangenen Nachricht extrahiert werden. Ebenso die Bits.
<code>
sduino: extracted data 00111010 (bin)
sduino: Found Protocol id 3
</code>

Alternativ kann das Signal auch in einer "rohform" angegeben werden. Dies ist manchmal in speziellen Fällen notwendig:
<code>
set sduino raw SR;;R=3;;P0=4742;;P1=-1554;;P2=286;;P3=-786;;P4=649;;P5=-420;;D=0123234545234545452323232323454523234523454523232345454523232323452345234523452345;;
</code>

R=3 bedeutet, das Signal wird 3x gesendet.
Die Übertragung besteht aus den in D angegeben Pulsen, welche in P0-P5 definiert werden.
Die Daten kann man aus einer empfangenen MS oder MU Nachricht extrahieren.

Alternativ kann ab Version 3.2 auch eine vereinfachte Form eingegeben werden.

====Fehlersuche====

(Zielgerät reagiert nicht, etc.)

* Nachrichtenwiederholungsanzahl muss evt. für manche Geräte entsprechend groß eingestellt sein
* Sende-Takt-Wert (Clock) passt evt. nicht ganz, siehe z.B. Thread-Antwort [https://forum.fhem.de/index.php/topic,58397.msg775434.html#msg775434 Signalduino Version 3.3.1], wo für IT-Geräte ein Attribut anhand der CP= des Empfangsdaten-Logs modifiziert wird. ACHTUNG: dies kann entweder global das Internal-Attribut ITClock eines SIGNALduino-Transceiver-Devices sein, oder (viel besser da korrekt geräte-instanz-spezifische Konfiguration) das ITclock eines IT-Client-Devices.
{{Randnotiz|RNTyp=r|RNText=VORSICHT blöder Schreibweisen-Mismatch ITClock vs. ITclock!!
}}

== Fehlerbehandlung ==
Der SIGNALduino kann mit folgendem Befehl auf Werkseinstellungen zurückgesetzt werden:
:<code>get raw e</code>
als Antwort kommt dann "ccFactoryReset done". Ob ein solcher Reset nötig ist, erkennt man an der Antwort auf den Befehl "get config", auf den dann die Meldung "config: MS=1;MU=1;MC=1" folgen sollte.

In der Firmware sind die folgenden Befehle eingebaut

*:<code>get raw C<reg></code>
<reg> is a (two digit) hex number: return the value of the cc1101 register. <reg>=99 dumps the first 48 registers.
Example: C35 -> C35 = 0D
*:<code>get raw e</code>
EEPROM / factory reset. resets all eeprom values without reboot
*:<code>get raw r<AA></code>
Read eeprom (da das "R" beim SIGNALDuino bereits mit freeram belegt ist, habe ich das "r" verwendet)
*:<code>get raw r<AA>n</code>
Read 16 byte from eeprom (z.B. r00n)
*:<code>get raw W<AA><DD></code>
Write eeprom (schreibt einen Wert ins EEPROM und ins CC1101 Register. Die eeprom Adresse hat einen Offset von 2. z.B W041D schreibt 1D ins Register 2)

Die Sendeleistung lässt sich mit
:<code>get sduino ccreg 3E</code>

prüfen, wobei die Rückmeldung wie folgt zu lesen ist:
"-10_dBm" => '34',
"-5_dBm" => '68',
"0_dBm" => '60',
"5_dBm" => '84',
"7_dBm" => 'C8',
"10_dBm" => 'C0'
Dabei wird die Sendeleistung dauerhaft mit dem Befehl
:<code>set sduino cc1101_patable <value></code>
hochgeschaltet (<value> durch den Wert ersetzen).

Weitere Firmware-Befehle sind im Thread-Beitrag {{Link2Forum|Topic=58396|Message=497921}} zu finden.

== Foren Links ==
* {{Link2Forum|Topic=38402|LinkText=Forenthread - Ankündigung}}
* {{Link2Forum|Topic=58396|LinkText=SIGNALDuino Empfänger Firm- und Hardware}}
* {{Link2Forum|Topic=58397|LinkText=Signalduino Entwicklung Version 3.3.1 }}
* [http://www.rflink.nl/blog2/wiring Beschreibung zu diversen Empfängern und Verbesserung der Empfangsleistung]
* [[SIGNALduino in die Arduino Entwicklungsumgebung einbinden]]
* [[Somfy via SIGNALduino]]

[[Kategorie:Interfaces]]
[[Kategorie:Arduino]]
[[Kategorie:433MHz]]
[[Kategorie:868MHz]]

Anwesenheitserkennung

2019-07-09T09:47:27Z

Mahowi: WIíki-Link zu "FHEM App" entfernt

Viele Benutzer führen bereits eine eigene '''Anwesenheitserkennung''' durch. Diese basiert in den meisten Fällen auf Ping Checks oder bei [[AVM Fritz!Box|FritzBoxen]] auf dem Befehl ''ctlmgr_ctl''. Diese Lösungen können aber je nach Aufbau und Funktion FHEM massiv beeinträchtigen. Aufgrund des Aufbaus vom FHEM kann dieses dadurch für mehrere Sekunden zum völligen Stillstand gebracht werden.

In FHEM gibt es mittlerweile mehrere Module, die eine zuverlässige Anwesenheitserkennung bieten, ohne dabei FHEM bei der Ausführung zu beeinträchtigen.

Eine erweiterte Funktion der Anwesenheitserkennung ist die Standortverfolgung, die sich nicht nur auf ein oder sehr wenige mit (eigenem) WLAN versorgte Gebiete beschränkt.

== Vorüberlegungen ==
Generell gibt es mehrere Ansätze um Anwesenheitserkennung mit Handys/Smartphones durchzuführen.

* via PING Checks im gesamten WLAN
* Aktivitätsprüfung auf einer FritzBox
* Bluetooth Checks in der gesamten Wohnung
* eigene Perl-Funktion
* aktive Benachrichtigung des Smartphones, ausgelöst z.B. über Geo-Lokation/Geofence

Dabei gilt bei der Auswahl der Art darauf zu achten wie sich das jeweilige Device verhält. Aufgrund der Vielfältigkeit kann man hier keine allgemeine Vorgehensweise empfehlen. Als einfacher Start (zumindest für Nicht-Apfel Telefone) eignet sich die Ping-Überprüfung und die FritzBox-Abfrage sehr gut.

=== Randbedingungen ===
Es gibt Geräte, die ihr WLAN/Bluetooth auch im Standby ständig aktiv haben und auf Anfragen antworten können (fast alle Android-Geräte). Gerade bei Tests über WLAN kann sich das aber signifikant auf die Akku Leistung auswirken.

Andere Geräte wiederum schalten WLAN im Standby Betrieb aus, um Akkukapazität zu sparen. Bluetooth hingegen bleibt weiterhin aktiviert und kann auf Anfragen reagieren. (iPhone)

Wenn man bei einem iPhone die Funktion "über WLAN synchronisieren" aktiviert hat, so ist dies auch im Standby jederzeit pingbar, wenn der Recher auf dem iTunes zum synchroniseren läuft auch an ist. Ansonsten ist bei iPhone Geräten nur die Aktivitätsprüfung mit einer FritzBox oder das überwachen der DHCP Lease auf einer Airport Basestation wirklich zuverlässig.

Auch wenn Bluetooth aktiviert ist, so bleiben einige Mobiltelefone erst dann empfangsbereit, wenn sie bereits zu irgend einem Bluetoothgerät gekoppelt wurden. Sind diese Geräte noch nie gekoppelt worden, deaktivieren diese ihren Bluetooth Empfänger beim verlassen des Bluetooth-Menüs im Gerät (iPhone).

Hier gilt es vor allem auszuprobieren, wie stark der Akku durch eine Anwesenheitserkennung belastet wird. Entscheidend ist hier, in welchem Abstand man eine Anwesenheitserkennung durchführt. Viele Abfragen wirken sich stärker auf den Akku aus als wenige. Wenige Abfragen bieten aber keine zuverlässige und zeitnahe Erkennung.

Als Alternative, unabhängig vom WLAN und der Erkennung, ob ein Gerät dort eingebucht ist oder nicht, bzw. unabhängig von Bluetooth kann zumindest bei einem iPhone die seit iOS 7 nochmals stark verbesserte Geo-Lokation (Geofencing) genutzt werden. Die iPhone Apps [http://geofency.com/ Geofency] oder [http://geofancy.com/ Geofancy] werden über das FHEM-Modul GEOFANCY angebunden und übertragen ihren Status immer dann, wenn ein definierter Standort betreten oder verlassen wird. Gekoppelt mit entsprechenden Notify und/oder Watchdog Kommandos ist so ebenfalls eine sehr zuverlässige Anwesenheitserkennung möglich (und das nicht nur für das eigene Zuhause).

== PRESENCE-Modul ==
Das [[PRESENCE]] Modul bietet für die Anwesenheitserkennung mehrere Varianten an. Diese sind aktuell folgende:

* '''lan-ping''' - Das Überwachen via PING Checks, die durch den FHEM Server versandt werden.
* '''fritzbox''' - Das Überwachen von Geräten auf einer FritzBox via ctlmgr_ctl (Nur auf einer FritzBox möglich)
* ''' Bluetooth'''
:- '''local-bluetooth''' - Das Überwachen via Bluetooth Checks, die vom FHEM Server direkt durchgeführt werden (angeschlossener Bluetooth-Stick und die Software bluez voraussgesetzt)
:- '''lan-bluetooth''' - Das Überwachen von Bluetoothgeräten, über Netzwerk. Auf einer oder mehreren Maschinen im Netzwerk (z.B. [[:Kategorie:Raspberry Pi|Raspberry Pi]]) läuft ein Presence-Daemon, der nach Bluetooth-Geräten sucht. Um mehrere Presence-Daemon mit FHEM zu verbinden, gibt es den Collector-Daemon, der sich zu allen Presence-Damons im Netzwerk verbindet und das Ergebnis von allen zusammenfasst.
* '''function''' - Das Überwachen mithilfe einer selbst geschrieben Perl-Funktion, die den Anwesenheitsstatus zurückgibt (0 oder 1)
* '''shell-script''' - Das Überwachen mithilfe eines selbst geschriebenen Shell-Programms/Skript, das eine 0 oder 1 ausgibt, um den Anwesenheitsstatus mitzuteilen.

Für eine bessere Übersicht befinden sich die '''Details''' zur '''Einrichtung''' und '''Benutzung''' von PRESENCE auf folgende '''Seite''' [[PRESENCE|PRESENCE]]

Im Forum [https://forum.fhem.de/index.php/topic,76342.0.html] findet man eine Lösung zum Problem des "deep standby" Modus von den neuen iPhones und Android Geräte. Mittels hping3 werden Packete an das Gerät geschickt, damit die "wach" bleiben. Dann werden die Mac-Adressen via 'arp' gelesen.

== GEOFANCY-Modul ==
Das Modul ermöglicht über einen sogenannten Webhook Mechanismus (umgangssprachlich oft auch als "Push" benannt) das aktive Melden des aktuellen Standortes. Die iPhone Apps [http://geofency.com/ Geofency] und [http://geofancy.com/ Geofancy] können dann aktiv und quasi in dem Moment, wo man den Wohnbereich betritt oder verlässt, benachrichtigen. Android Nutzern können [https://play.google.com/store/apps/details?id=de.egi.geofence.geozone&hl=de EgiGeoZone Geofence] nutzen. Das geht nochmals um einiges schneller, als die Erkennung im WLAN, bei der die Anwesenheit nur in (engen) Zyklen aktiv geprüft werden muss. Gleichzeitig werden Ressourcen in FHEM geschont. Die aktuelle Implementierung im iPhone 5S mit dediziert für das Tracking zuständigem Chip ist so gut, dass der Akku ebenfalls sehr geschont wird.

Für eine bessere Übersicht befinden sich die '''Details''' zur '''Einrichtung''' und '''Benutzung''' von GEOFANCY auf folgende '''Seite''' [[GEOFANCY|GEOFANCY]]

== livetracking-Modul ==
Das [[livetracking]] Modul baut auf der App Owntracking auf. Wird sie installiert, so kann man via MQTT oder HTTP an FHEM Angaben über den eigenen Standort, die Batteriestärke und die Entfernung zum Heimatort senden.

Livetracking ist unter Linux (RPi) wie folgt zu installieren. Zuerst sind zwei Perl-Module zu holen
sudo apt-get -y install libnet-oauth-perl
sudo apt-get -y install libmath-round-perl
Das Modul selbst wird ohne weitere Angaben durch
define <name> livetracking
in FHEM angelegt. Es erhält ein Attribut, das auf das owntracking-Gerät in FHEM verweist durch
attr owntracksDevice <hier-owntracking-device-angeben>
Das owntracking-device selbst ist ein MQTT-Gerät, das in der App entsprechend anzulegen ist. Eine beispielhafte Installation (hinter einem VPN) sieht hier so aus
defmod <hier-owntracking-device-angeben> MQTT_DEVICE
attr <hier-owntracking-device-angeben> IODev Mosquitto
attr <hier-owntracking-device-angeben> subscribeReading_OWNTRACKS owntracks/<nutzer-und-app-spezifische-angaben>

== Beispiele für die Nutzung der Anwesenheitserkennung ==
Hier sollen Beispiele für den Nutzen von Anwesenheitserkennung aufgezeigt werden.

=== Abschalten aller Verbraucher (Licht, Musikanlage) beim Verlassen der Wohnung ===
Typisches Szenario: Man geht ausser Haus, aber hat vergessen im Bad das Licht aus zu machen. Allerdings geht man heutzutage fast gar nicht mehr ohne Handy aus dem Haus.

Nun soll FHEM in der gesamten Wohnung das Licht, sowie sonstige Verbraucher ausschalten, wenn ich länger als 15 Minuten ausser Haus bin. Dazu benötigt man zuerst eine structure, die alle Verbraucher und sonstigen Devices, die das betrifft, zusammenfasst.

<pre>
define Gesamte_Wohnung structure Gesamtes_Licht Licht_Wohnzimmer Licht_Kueche LED_Kueche Licht_Bad Licht_Schlafzimmer AV_Receiver TV_Steckdose
attr Gesamte_Wohnung room Wohnung
</pre>

Nun kann man mittels eines watchdogs eine Überwachung für sein Handy anlegen:

<pre>
# Überwachen der gesamten Wohnung mittels collectord sowie presenced in jedem Raum
define Handy PRESENCE lan-bluetooth XX:XX:XX:XX:XX:XX 127.0.0.1:5222
attr Handy event-on-change-reading state # Ein Event soll nur bei der Änderung des Anwesenheitsstatus (Reading: status) erfolgen. Wichtig für den watchdog!!!

# Nach 15 Minuten Abwesenheit (Handy im Status "absent") soll die gesamte Wohnung ausgeschaltet werden.
define watchdog_Anwesenheit watchdog Handy:absent 00:15 Handy:present set Gesamte_Wohnung off ; trigger watchdog_Anwesenheit .
attr watchdog_Anwesenheit regexp1WontReactivate 1
</pre>

=== Benachrichtigung bei Batteriewechsel ===
Mit Hilfe des PRESENCE-Moduls kann man auch bei batteriebetriebenen Geräten eine Meldung ausgeben, sobald ein Batteriewechsel ansteht. Hier im Beispiel wird der Eve-Room-Sensor von Elgato eingebunden und anschließend mit einer DOIF-Nachricht ausgestattet.
Die Bluetooth-Adresse des Sensors kann mittels eines BLE-Scanners ermittelt werden.

<pre>
# PRESENCE-Modul für Elgato Eve Room Sensor mit Aktualisierung alle 6 Minuten
define Eve_Room_BLE lan-bluetooth <Bluetooth-Adresse> 127.0.0.1:5333 360
</pre>

Anschließend wird eine DOIF-Regel definiert, die eine Nachricht an die installierte FHEM App absendet:
<pre>
define Eve_Room_BLE_Battery_Msg DOIF ([Eve_Room_BLE] eq "absent") (set Msg_iPhone message 'Batteriewechsel beim Eve Room Sensor im Wohnzimmer.')
attr Eve_Room_BLE_Battery_Msg wait 600
</pre>

Die Aktualisierung des PRESENCE-Eintrages sollte nicht größer sein als das WAIT-Attribut der DOIF-Regel. Ansonsten könnte eine kurze Systemstörung zum Fehlalarm führen.
[[Kategorie:Code Snippets]]
[[Kategorie:Glossary]]
[[Kategorie:Anwesenheitserkennung]]

Wetter und Wettervorhersagen

2019-07-09T08:18:51Z

Mahowi: Link zur API Doku angepasst, AqPM2.5 und AgPM10 hinzugefügt

Wetterdaten und Wettervorhersagen können auf verschiedene Weise in FHEM eingebunden werden.

== Yahoo-Wetter ==
Für die einfache Einbindung des Yahoo-Wetters gibt es das spezielle Modul [[Weather]].

== Unwetterzentrale ==
Informationen der Seite(n) Unwetterzentrale.de können mit Hilfe des Moduls [[UWZ]] eingebunden werden.

== Modul OPENWEATHER ==
Das Modul [[OPENWEATHER]] extrahiert Wetterdaten über die "openweather"-Schnittstelle (API) von www.wetter.com.
*Vorschau-Zeitraum: 3 Tage
*Vorschau-Interval: 6:00, 11:00, 17:00, 23:00
*Aktuelle Daten: keine

== Modul PROPLANTA ==
Das Modul [[PROPLANTA]] extrahiert Wetterdaten von der Website www.proplanta.de. (keine API)
*Vorschau-Zeitraum: 12 Tage
*Vorschau-Interval: 3 h
*Aktuelle Daten: jede volle Stunde

== Modul WWO ==
Das Modul extrahiert Wetterdaten über die (alte) API von worldweatheronline.com
*Vorschau-Zeitraum: ?? Tage<BR>
*Vorschau-Interval: ??<br>
*Aktuelle Daten: ??

== Deutscher Wetterdienst (DWD) ==

=== Modul DWD_OpenData ===
Das Modul [[DWD_OpenData]] stellt einen Teil der frei verfügbaren Daten des Deutschen Wetterdienstes (DWD) bereit, die über den [https://www.dwd.de/DE/leistungen/opendata/opendata.html Open Data Server] abgerufen werden können (diverse Datenformate, keine API).
*Vorschau-Zeitraum: 10 Tage
*Vorschau-Interval: datenabhängig, viele mit 3 h
*Vorschau-Orte: national und international
*Aktuelle Daten: nicht implementiert
*Wetterwarnungen: für Landkreise und Gemeinden in deutsch oder englisch

Es gibt zum Modul auch einen Weblink für [[FHEMWEB]], der 2 Icons pro Tag in horizontaler Form darstellt. Die Anzahl der insgesamt dargestellten Icons ist konfigurierbar. Liegen Wetterwarnungen vor, wird zusätzlich ein Warnsymbol angezeigt, über das man per Klick weitere Details zur Wetterwarnung abrufen kann.

[[DWD_OpenData|Weitere Details und Installationsbeschreibung]]

=== Wetterwarnungen als Karte ===
Der Deutsche Wetterdienst [http://www.dwd.de DWD] stellt neben diversen Wetterdaten auch Wetterwarnungen in Bildform bereit. Diese können sehr einfach via [http://fhem.de/commandref_DE.html#weblink weblink iframe] in FHEM eingebunden werden - das ist zwar nicht die schönste Form, aber die schnellste.

Dazu sucht man sich zuerst auf der [http://www.dwd.de/bvbw/appmanager/bvbw/dwdwwwDesktop?_nfpb=true&_pageLabel=_dwdwww_wetter_warnungen_warnungen&T92053gsbDocumentPath=BEA__Navigation%2FWetter__Warnungen%2FWarnungen.html%3F__nnn%3Dtrue&lastPageLabel=dwdwww_wetter_warnungen Warnungsseite des DWD] die eigene Region heraus (in der Karte durchklicken). Die gewünschte URL für Berlin Stadt ist z.B. <code>http://www.dwd.de/dyn/app/ws/html/reports/BXX_warning_de.html#WS_ANCHOR_0</code>. Das Anhängsel <code>#WS_ANCHOR_0</code> kann man in der Konfiguration auch weglassen.

Die Einbindung in FHEM sieht dann wie folgt aus:
<pre>
define dwd_warnmeldung weblink iframe http://www.dwd.de/dyn/app/ws/html/reports/BXX_warning_de.html
attr dwd_warnmeldung group Wetterwarnungen (DWD)
attr dwd_warnmeldung htmlattr width="100%" height="300" frameborder="0" marginheight="0" marginwidth="0"
attr dwd_warnmeldung room Wettervorhersage,Startseite
</pre>

== Vorhersage-Diagramm von YR ==
[http://www.yr.no YR] ist die Seite des norwegischen Wetterdiensts. Er ist zwar nur in Teilen auf Englisch (und gar nicht auf Deutsch) verfügbar, bietet aber sehr gute Wettervorhersagen - auch mit eigenen Vorhersagen für kleine Dörfer. Neben etlichen Detailinfos bietet YR eine sehr schicke 48h-Vorhersage-Grafik. Diese kann sehr einfach via [http://fhem.de/commandref_DE.html#weblink weblink iframe] in FHEM eingebunden werden.

Dazu geht man auf die [http://www.yr.no Startseite von YR] und gibt in das Suchfeld den Namen seines Dörfchens ein - die Ergebnissliste kann ziemlich lang werden, sodass man evtl. sehr genau schauen muss, welches das eigene Kaff ist - bei mir war es an 29. Stelle... ;-) Auf der gewünschten Seite gibt es einen Unterpunkt "Hour by hour", wo sich die besagte Grafik findet. Hier kopiert man sich einfach die URL der Grafik.

Die Einbindung in FHEM sieht dann bspw. wie folgt aus:
<pre>
define Wetter_yr_Vorhersage weblink iframe http://www.yr.no/place/Germany/Berlin/Berlin/meteogram.png
attr Wetter_yr_Vorhersage group Wettervorhersage (yr)
attr Wetter_yr_Vorhersage htmlattr width="100%" height="300" frameborder="0" marginheight="0" marginwidth="0"
attr Wetter_yr_Vorhersage room Wettervorhersage,Start
</pre>

== Wetter von Weather Underground ==
{{Randnotiz|RNTyp=y|RNText=Neben dem hier vorgestellten Abruf der Weather Underground-Daten mit [[HTTPMOD]] kann auf Weather Underground-Daten auch mit dem darauf spezialisierten Modul [http://fhem.de/commandref.html#Wunderground Wunderground] zugegriffen werden.}}
'''ACHTUNG: Das API von Weather Underground wird derzeit (März 2019) "retired" = abgestellt.''' Ist also künftig nicht mehr nutzbar.
'''Hinweis:''' Dieses Vorgehen ist etwas anspruchsvoller und somit eher für erfahrene FHEM-User geeignet.

[http://www.wunderground.com/ Weather Underground] ist bietet eine sehr umfassende Sammlung aller möglichen offiziellen und privaten (aber teils sehr professionellen) Wetterstationen weltweit. Es besteht eine recht hohe Wahrscheinlichkeit, dass es in der eigenen Umgebung schon eine Wetterstation gibt. Anstatt nun selbst eine komplette Wetterstation aufzubauen, kann man alternativ auf die Daten der Nachbarstation zugreifen.

Dazu sind grundsätzlich die folgenden Schritte notwendig:
* Finden der geeigneten Station
* Auswerten der XML-Daten
* Erstellen passender gplot-Dateien

=== Finden der geeigneten Station ===
Als erstes geht man auf die [http://www.wunderground.com Startseite von Weather Underground] und gibt in das Suchfeld den Namen seines Dörfchens oder der nächsten Stadt ein - für Berlin landet man bspw. auf Seite für "Berlin Alexanderplatz". Es gibt aber manchmal sehr viele Wetterstationen in der direkten Umgebung. Diese findet man indem am auf "Change Station" klickt und sich eine passende Station aussucht. Nähere Infos (zB. zur verwendeten Hard- und Software) zu der gewählten Wetterstation erhält man, wenn man auf den Namen der Station klickt und dann auf "About this PWS".

Weather Underground stellt die Daten der Wetterstation auch über eine API als XML bereit, die wir auswerten können. Die entsprechende URL findet sich ebenfalls unter "About this PWS" unter "Download current conditions XML". Für Berlin Prenzlauer Berg wäre dies bspw.
<code>http://api.wunderground.com/weatherstation/WXDailyHistory.asp?ID=IBERLIN15&format=XML</code>.

Entscheidend für die jeweilige Station ist der Teil nach "?=ID", also in diesem Fall "IBERLIN15". Dieser Teil des Links lässt sich leicht durch die ID einer anderen Station ersetzen und die Suche nach dem entsprechenden Link auf der Seite der Station bleibt erspart.

=== Auswerten der XML-Daten ===
Die Auswertung der XML-Daten erfolgt via [[HTTPMOD]]. Da dies nicht ganz trivial ist, sind im Folgenden zuerst die wesentlichen Konfigurationsschritte exemplarisch beschrieben. Weiter unten findet sich dann die fertige vollständige Konfiguration.

Es erstes wird das Device HTTPMOD definiert (die 600 am Schluss ist der Aktualisierungszyklus in Sekunden, also alle 10 min):
:<code>define wetter_prenzelberg HTTPMOD http://api.wunderground.com/weatherstation/WXCurrentObXML.asp?ID=IBERLIN15 600 </code>

Dann werden Attribute für alle Readings definiert:
:<code>attr wetter_prenzelberg userattr readingsName_cloudiness readingsName_date ... </code>

Dann wird jedem Attribut ein Name zugewiesen (unter diesem Namen wird der Wert ins Log geschrieben):
:<code>attr wetter_prenzelberg readingsName_cloudiness cloudiness </code>

Zum Schluss wird das Reading selbst definiert:
:<code>attr wetter_prenzelberg readingsRegex_cloudiness cloudiness id="NN" percent="([\d\.]+) </code>

Die gesamte Konfiguration für alle von der API angebotenen Wetterwerte sieht dann wie folgt aus:
<pre>
define wetter_prenzelberg HTTPMOD http://api.wunderground.com/weatherstation/WXCurrentObXML.asp?ID=IBERLIN15 600
attr wetter_prenzelberg userattr readingsName_cloudiness readingsName_date readingsName_dewpointTemperature readingsName_fog readingsName_heatindex readingsName_humidity readingsName_pressure readingsName_solarRadiation readingsName_solarUV readingsName_temperature readingsName_time readingsName_windChill readingsName_windDegrees readingsName_windDirection readingsName_windGust readingsName_windSpeed readingsRegex_cloudiness readingsRegex_date readingsRegex_dewpointTemperature readingsRegex_fog readingsRegex_heatindex readingsRegex_humidity readingsRegex_pressure readingsRegex_solarRadiation readingsRegex_solarUV readingsRegex_temperature readingsRegex_time readingsRegex_windChill readingsRegex_windDegrees readingsRegex_windDirection readingsRegex_windGust readingsRegex_windSpeed
attr wetter_prenzelberg readingsName_cloudiness cloudiness
attr wetter_prenzelberg readingsName_date date
attr wetter_prenzelberg readingsName_dewpointTemperature dewpointTemperature
attr wetter_prenzelberg readingsName_fog fog
attr wetter_prenzelberg readingsName_heatindex heatindex
attr wetter_prenzelberg readingsName_humidity humidity
attr wetter_prenzelberg readingsName_pressure pressure
attr wetter_prenzelberg readingsName_solarRadiation solarRadiation
attr wetter_prenzelberg readingsName_solarUV solarUV
attr wetter_prenzelberg readingsName_temperature temperature
attr wetter_prenzelberg readingsName_time time
attr wetter_prenzelberg readingsName_windChill windChill
attr wetter_prenzelberg readingsName_windDegrees windDegrees
attr wetter_prenzelberg readingsName_windDirection windDirection
attr wetter_prenzelberg readingsName_windGust windGust
attr wetter_prenzelberg readingsName_windSpeed windSpeed
attr wetter_prenzelberg readingsRegex_cloudiness cloudiness id="NN" percent="([\d\.]+)
attr wetter_prenzelberg readingsRegex_date date date" content="([\d\.]+)
attr wetter_prenzelberg readingsRegex_dewpointTemperature <dewpoint_c>(\+|-?[\d\.]+)
attr wetter_prenzelberg readingsRegex_fog fog id="FOG" percent="([\d\.]+)
attr wetter_prenzelberg readingsRegex_heatindex <heat_index_c>(\+|-?[\d\.]+)
attr wetter_prenzelberg readingsRegex_humidity <relative_humidity>([\d\.]+)
attr wetter_prenzelberg readingsRegex_pressure <pressure_mb>([\d\.]+)
attr wetter_prenzelberg readingsRegex_solarRadiation <solar_radiation>([\d\.]+)
attr wetter_prenzelberg readingsRegex_solarUV <UV>([\d\.]+)
attr wetter_prenzelberg readingsRegex_temperature <temp_c>(\+|-?[\d\.]+)
attr wetter_prenzelberg readingsRegex_time time Zeit([\d\:]+)
attr wetter_prenzelberg readingsRegex_windChill <windchill_c>(\+|-?[\d\.]+)
attr wetter_prenzelberg readingsRegex_windDegrees <wind_degrees>([\d\.]+)
attr wetter_prenzelberg readingsRegex_windDirection <wind_dir>([\d\.]+)
attr wetter_prenzelberg readingsRegex_windGust <wind_gust_mph>([\d\.]+)
attr wetter_prenzelberg readingsRegex_windSpeed <wind_mph>([\d\.]+)
</pre>
Hinweis: Nicht immer werden alle Werte geliefert (wenn keine Sonne, dann kein UV-Wert...). Im System-Log kann das als Fehler auftauchen, ist aber kein Problem.

=== Erstellen passender gplot-Dateien ===
Um die ausgelesenen Werte als Graphen darstellen zu können müssen eigene gplot-Dateien erstellt werden. Eine grundsätzliche Anleitung dazu findet sich unter [[Creating Plots]]. Deshalb sollen hier nur Beispiele für die eigentlichen gplot-Dateien vorgestellt werden. Beispiele sollten sowohl für [[FileLog]] wie [[DbLog]] funktionieren.

Temperatur und Luftfeuchte:
<pre>
set terminal png transparent size <SIZE> crop
set output '<OUT>.png'
set xdata time
set timefmt "%Y-%m-%d_%H:%M:%S"
set xlabel " "
#set title '<L1>'
set title ''
set ytics
set y2tics
set grid ytics
set ylabel "Temperature in C"
set y2label "Humidity (%)"

#FileLog 4:temperature\x3a::
#FileLog 4:windChill\x3a::
#FileLog 4:humidity\x3a::

#DbLog <SPEC1>:temperature::
#DbLog <SPEC1>:windChill::
#DbLog <SPEC1>:humidity::

plot "<IN>" using 1:2 axes x1y1 title 'Temperatur (C)' ls l0 lw 1.5 with lines,\
"<IN>" using 1:2 axes x1y1 title 'Gefühlte Temperatur (C)' ls l1 lw 1.5 with lines,\
"<IN>" using 1:2 axes x1y2 title 'Luftfeuchtigkeit (%)' ls l2fill lw 0.2 with lines
</pre>

Wind und Windrichtung:
<pre>
set terminal png transparent size <SIZE> crop

set output '<OUT>.png'
set xdata time
set timefmt "%Y-%m-%d_%H:%M:%S"
set xlabel " "

set ytics
set y2tics ("Nord" 0, "Ost" 80, "Süd" 180, "West" 270, "Nord" 360)

#set title '<L1>'
set title ''

set grid xtics ytics

set yrange [0:20]
set y2range [0:360]

set ylabel "Wind (mph)"
set y2label "Richtung"

#FileLog 4:windSpeed:0:
#FileLog 4:windGust:0:
#FileLog 4:windDegrees:0:

#DbLog <SPEC1>:windSpeed::
#DbLog <SPEC1>:windGust::
#DbLog <SPEC1>:windDegrees::

plot "<IN>" using 1:2 axes x1y1 title 'Wind (mph)' ls l0 lw 1.5 with lines,\
"<IN>" using 1:2 axes x1y1 title 'Böen (mph)' ls l1 lw 1.5 with lines,\
"<IN>" using 1:2 axes x1y2 title 'Windrichtung (°)' ls l2fill lw 0.2 with points
</pre>

Sonnenintensität und UV-Werte:
<pre>
set terminal png transparent size <SIZE> crop

set output '<OUT>.png'
set xdata time
set timefmt "%Y-%m-%d_%H:%M:%S"
set xlabel " "

set ytics
set y2tics

#set title '<L1>'
set title ''

set grid xtics ytics

set ylabel "Sonnenstrahlung (W/qm)"
set y2label "UV"

#FileLog 4:solarRadiation:0:
#FileLog 4:solarUV:0:

#DbLog <SPEC1>:solarRadiation::
#DbLog <SPEC1>:solarUV::

plot "<IN>" using 1:2 axes x1y1 title 'Strahlung' ls l0 lw 1.5 with lines,\
"<IN>" using 1:2 axes x1y1 title 'UV' ls l1 lw 1.5 with lines
</pre>

'''Weitere TBD'''

=== Vergangene Daten abfragen ===
Ein konkretes vergangenes Datum der Wetterstation kann man übrigens auch abrufen - für den 28.11.2014 wäre dies bspw.
<code>http://www.wunderground.com/weatherstation/WXDailyHistory.asp?ID=IBERLIN15&day=28&month=11&year=2014&graphspan=day&format=1</code>.

=== Eigene Wetterdaten hochladen ===
{{Randnotiz|RNTyp=g|RNText=Unterstützung für das Modul gibt es im dazugehörigen {{Link2Forum|Topic=65587|LinkText=Forumsthread }}.}}

Wer eigene Wetterdaten hochladen will, kann hierzu das Modul [http://fhem.de/commandref.html#WUup WUup] verwenden. Dazu benötigt man die Zugangsdaten (stationID und Paßwort) für eine eigene Wetterstation. Mit dem Modul können die meisten vom [https://feedback.weather.com/customer/en/portal/articles/2924682-pws-upload-protocol?b_id=17298 PWS Upload Protocol] unterstützten Daten hochgeladen werden:
* Winddir - [0-360 momentane Windrichtung]
* Windspeedmph - [mph momentane Windgeschwindigkeit]
* Windgustmph - [mph aktuellen Böe, mit Software-spezifischem Zeitraum]
* Windgustdir - [0-360 mit Software-spezifischer Zeit]
* Windspdmph_avg2m - [mph durchschnittliche Windgeschwindigkeit innerhalb 2 Minuten]
* Winddir_avg2m - [0-360 durchschnittliche Windrichtung innerhalb 2 Minuten]
* Windgustmph_10m - [mph Böen der vergangenen 10 Minuten]
* Windgustdir_10m - [0-360 Richtung der Böen der letzten 10 Minuten]
* Feuchtigkeit - [% Außenfeuchtigkeit 0-100%]
* Dewptf- [F Taupunkt im Freien]
* Tempf - [F Außentemperatur]
* Rainin - [in Regen in der vergangenen Stunde]
* Dailyrainin - [in Regenmenge bisher heute]
* Baromin - [inHg barometrischer Druck]
* Soiltempf - [F Bodentemperatur]
* Bodenfeuchtigkeit - [%]
* Solarradiation - [W/m²]
* UV - [Index]
* AqPM2.5 - Feinstaub PM2,5 [µg/m³]
* AqPM10 - Feinstaub PM10 [µg/m³]

Die Werte werden im Modul für Wunderground ins anglo-amerikanische System umgerechnet. Temperaturen werden also automatisch von °Celsius in Fahrenheit, Windgeschwindigkeiten von km/h in mph, mm in Inch und der barometrische Druck von hPa in inHg umgerechnet.

== Wetternetzwerk auf wetter.com ==
Ein vollständiges Beispiel zur Nutzung der Informationen über die Regenmenge (Station 1445, Weinheim) von wetter.com ist in {{Link2Forum|Topic=39600|Message=332837|LinkText=diesem Forenbeitrag}} beschrieben.

== Wetter von netatmo ==
Das FHEM-Modul [[netatmo]] ermöglicht den Datenimport von privaten und öffentlichen netatmo Wetterstationen sowie den Abruf der in der Netatmo App verfügbaren Wettervorhersage. Eine Übersicht über die verfügbaren öffentlichen Stationen findet sich auf der Seite [http://www.netatmo.com/de-DE/weathermap Weathermap]. Die meisten öffentlichen Stationen liefern Temperatur, Luftfeuchte und Luftdruck, einige auch Wind, Regen und Daten zur Luftqualität (CO<sub>2</sub>).

== Links ==
* {{Link2Forum|Topic=33610}} mit Sammlung und Beipielen von Internet-Links für die Anzeige von teilweise animierten Wetterbildern
* [http://bloglich.de/art/rpi/wetterdaten-auf-dem-raspberry-pi-in-fhem/ Beispiel in Blog(de)]
* [[HTTPMOD]]

[[Kategorie:Code Snippets]]
[[Kategorie:HOWTOS]]
[[Kategorie:Wetterstationen]]

Anwesenheitserkennung - Remote Fritzbox

2017-11-13T07:39:37Z

Mahowi: /* Code (beide Varianten) */ Link2Forum gefixt

{{Randnotiz|RNTyp=y|RNText=Dieses Modul wird nicht mehr unterstützt oder weiterentwickelt, weil es:
# kein telnet mehr auf der FB gibt,
# die Weboberfläche sich mit jeder neuen FB-Version ändert,
# mit dem '''FRITZBOX Modul''' mittlerweile bessere Lösungen gibt.

Details (zur Umstellung) siehe:
* [[FRITZBOX]] Modulseite
* {{Link2Forum|Topic=39433|LinkText=dieses Forenthema}} und
* Otto's Technik Blog [http://heinz-otto.blogspot.de/2015/07/die-zeiten-andern-sich.html]
}}

In Erweiterung des Beitrages [[Anwesenheitserkennung|Anwesenheitserkennung]] wird eine Beispiel-Lösung für folgendes Szenario vorgestellt:

* Eine (nicht modifizierte) Fritzbox wird als WLAN Access Point und Router genutzt, jedoch läuft auf dieser Box kein FHEM oder Perl.
* Ein Linux Rechner (in diesem Beispiel ein RPI) wird als FHEM host verwendet.
* Device Erkennung mittels PRESENCE - ident mit PRESENCE fritzbox

Die Lösung basiert auf dem PRESENCE Modul und nutzt die Funktion '''PRESENCE function { }'''.

Auch bei einem Repeater-Einsatz im WLan (zweite Fritzbox) kann diese Lösung eingesetzt werden - es ist nur eine Installation auf der Haupt-Fritzbox notwendig, nicht auf dem Repeater.

== Background / Motivation ==
Ich hatte während der letzten 12 Monate ein modifiziertes PRESENCE Modul im Einsatz, das jedoch immer wieder ein Hängen oder Reboots der Fritzbox verursacht hatte (speziell bei 7270), daher hatte ich es nicht veröffentlicht. Die Vermutung liegt nahe, dass das ständige Telnet ein/aus-loggen die Hänger/Reboots verursacht hat.

'''update Version 1.3'''
Anpassung an die Änderungen im PRESENCE Modul, nun wahlweise die Angabe von Device-Namen oder MAC-Adresse möglich!

'''update Version 1.7'''
RemoteFritzBoxWeb speichert nun ebenfalls die Session-ID, damit weniger logins notwendig. Unterstützung für Repeater 1750E eingebaut, Abfragen werden serialisiert.

'''update Version 1.9'''
RemoteFritzBoxWeb: startup verbessert, verwendet telnetforBlocking zur Rückmeldung an fhem, OSX compatibility: keine Verwendung von pidof

== Konzept ==
=== Variante 1 ===
* Diese Lösung basiert (wie auch die '''PRESENCE fritzbox''' Funktion) auf dem Fritzbox Befehl ''ctlmgr_ctl'', der jedoch von der "Ferne" ausgelöst werden muss, da FHEM ja nicht auf der Fritzbox läuft. Weiters wurden Ideen/Konzepte des presenced/collectord verwendet.
* Die Lösung läuft bei mir seit Anfang Dez. 2013 stabil mit 12 abgefragten Devices / 120 Sekunden Intervall. (Env: FHEM auf RPI, Fritzbox 7390)
* Auf der Fritzbox wird ein '''shellscript''' installiert, dass von remote gestartet wird, Kommandos lokal ausführt und das Ergebniss zurückschickt.
* Am FHEM host läuft ein '''perl basierender daemon''' der Kommandos von FHEM empfängt, aufbereitet und das shellscript auf der Fritzbox (mit parameter) startet. Dieser Daemon hält auch die Telnet Verbindung zur Fritzbox permanent aufrecht. Gestartet wird dieser Daemon automatisch beim ersten Aufruf durch FHEM.
* ein Modul '''99_RFritzBox.pm''' ist die Schnittstelle zwischen FHEM und dem daemon.

=== Variante 2 ===
* Die WEB Oberfläche der Fritzbox wird über http abgefragt.
* Es ist kein code und kein Telnet auf der Fritzbox selbst notwendig, ein Nachteil könnte jedoch die Performance der Abfrage sein.
* Diese Variante ist vor allem für jene FB-Benutzer interessant, die kein Telnet auf der FB aktivieren können (oder wollen).
* Ab der Version 1.7 werden die Logindaten (Sid) zwischengespeichert (ca. 3 Minuten), das bringt wesentliche Performance-Vorteile.
* Zusätzlich werden die Webanfragen serialisiert, d.h. nur eine Abfrage gleichzeitig, damit sollten die select/timeout errors weg sein.
* '''Feature:''' Diese Version bietet die Möglichkeit, eine zweite Fritzbox (oder einen Repeater) per Web abzufragen.
* Derzeit getestet sind FB 7270,7390,7490 und der Repeater 1750E.

== Code (beide Varianten)==
Der Code ist als Zip-File im Thread {{Link2Forum|Topic=17957|LinkText=PRESENCE-RemoteFritzbox}} abgelegt. Bitte in diesem Thread auch Fragen/Feedback/Wünsche posten.

== Installation & Debug Variante 1 ==
=== Voraussetzungen ===
* Telnet auf der Fritzbox aktiviert
* perl NET::Telnet Modul auf dem Host wo FHEM läuft installiert. Beim Raspberry-PI geht das so:
<pre>sudo apt-get install libnet-telnet-perl</pre>
Folgende Reihenfolge ist empfehlenswert:

=== Kopieren von Rpresence.sh in die Fritzbox ===
z.B. mittels FTP in folgendes Verzeichnis:
<pre>
/var/media/ftp/FRITZ/bin # Der Verzeichnispfad muss angepasst werden! In diesem Beispiel ist das eine FB7390 im Internen Speicher.
chmod +x Rpresence.sh # shell script ausführbar machen.</pre>
Ein erster Test von der Telnet Konsole der Fritzbox:
<pre>./Rpresence.sh <FBdevicename/FB-MAC-Adress></pre> sollte folgendes Ergebnis liefern: <pre>RFritzBox: <FBdevicename/FB-MAC-Adress> y z</pre> wobei für <FBdevicename/FB-MAC-Adress> der Name <b>oder</b> die MAC-Adresse eines Gerätes, so wie in der Fritzbox Weboberfläche definert einzusetzen ist. y ist die Fritzbox interne Devicenummer dieses Gerätes (es sollte jedenfalls nicht 999 hier stehen, in diesem Fall hat die FB den Namen nicht gefunden. z ist der Status (0==abwesend/1==anwesend).
Falls bis hierher alles geklappt hat, ist die Einrichtung auf der Fritzbox fertig.

=== Installation & konfig & test Daemon am FHEM host ===
kopieren von RFritzBoxScan.pl ins FHEM Verzeichnis (dort wo alle Module 00_xxx.pm - 99_yyy.pm sind)
<pre>sudo chmod +x RFritzBoxScan.pl # ausführbar machen
sudo chown fhem:root RFritzBoxScan.pl #for user fhem </pre>
Erstellen eines config- files für den daemon:
im root FHEM-Verzeichnis ( dort wo üblicherweise auch die fhem.pl zu finden ist )
ein file: '''credentials.cfg''' mit folgendem Inhalt erstellen (Adressen/User/Passwort/pfad anpassen):
<pre>
# PRESENCE credentials (only required for function RemoteFritzBox)
$credentials{RemoteFritzBox}{ipadress} = '192.168.1.254'; # FB LAN Adress
$credentials{RemoteFritzBox}{username} = 'FritzBoxusername';
$credentials{RemoteFritzBox}{password} = 'FritzboxPasswort';
$credentials{RemoteFritzBox}{shellcmd} = '/var/media/ftp/FRITZ/bin/Rpresence.sh'; # pfad anpassen!
$credentials{RemoteFritzBox}{serverhost} = 'localhost'; # RFritzBoxScan.pl provides this service
$credentials{RemoteFritzBox}{serverport} = 7777;
$credentials{RemoteFritzBox}{serverbin} = 'RFritzBoxScan.pl'; # Fritzbox daemon
$credentials{RemoteFritzBox}{speedmatching} = "active"; # optional valid: <active|speed>
</pre>
Das Format dieser cfg-file entspricht dem im Modul Webcam.
Ein erster Test:
<pre>./RFritzBoxScan.pl <fullpath and name> # of credentials.cfg eg: /opt/fhem/credentials.cfg</pre>
Damit wir der Daemon von Hand gestartet und alle debug-Meldungen kommen auf diese Konsole.
Beim Start sollte der Output so aussehen:
<pre>
RFritzBoxScan: server waiting for client connection on port 7777
RFritzBoxScan: Fritzbox login ok
### die folgenden Zeilen kommen erst ab dem nächsten Schritt !
### und zwar jedesmal wenn ein request von FHEM an den daemon kommt...
RFritzBoxScan: connection from 127.0.0.1:57595
RFritzBoxScan: ..from FHEM received data: Nokia-N810
RFritzBoxScan: ..sending to Fritzbox: Nokia-N810 17
RFritzBoxScan: ..cmdresult: RFritzBox: Nokia-N810 17 1
RFritzBoxScan: ..result to fhem: 1
</pre>

=== Installation und Konfiguration FHEM-Module ===
kopieren von 99_RFritzBox.pm ins FHEM Verzeichnis
<pre>sudo chown fhem:root 99_RFritzBox.pm # for user fhem</pre>
Im FHEM command-feld: <pre>reload 99_RFritzBox.pm</pre> eintippen (oder FHEM neu starten)
Die FHEM-PRESENCE Definition:
<pre>define <myName> PRESENCE function {RemoteFritzBox("<FB-devicename/FB-MAC-Adress>")} 120 120
example by name:
define myEiFonStatus PRESENCE function {RemoteFritzBox("myEiFon")} 120 120
or with MAC adress:
define myEiFonStatus PRESENCE function {RemoteFritzBox("11:22:33:44:55:66")} 120 120
</pre>
damit wird in 120 sec Abständen der Status abgefragt.
im Telnet Fenster sollten jetzt die requests / response - Meldungen kommen.

Zum Abschluß:
<pre><Strg-C></pre> im telnet Fenster eingeben, der Daemon wird dadurch gestoppt. Auf den nächsten Aufruf durch FHEM warten, der Daemon wird automatisch (im Hintergrund) gestartet. Überprüfen durch Eingabe von <pre>ps -e | grep RFritzBoxScan</pre>

== Installation & Debug Variante 2 ==
=== Voraussetzungen ===
* fhem auf raspberry o.ä.

=== installation & konfig & test am FHEM host ===
Erstellen eines config- files im root FHEM-Verzeichnis ( dort wo üblicherweise auch die fhem.pl zu finden ist )
ein file: '''credentials.cfg''' mit folgendem Inhalt erstellen (Adressen/User/Passwort/Modell anpassen):
<pre>
# PRESENCE credentials (only required for function RemoteFritzBoxWeb)
$credentials{RemoteFritzBox}{ipadress} = '192.168.1.254'; # FB LAN Adress
$credentials{RemoteFritzBox}{username} = 'FritzBoxusername';
$credentials{RemoteFritzBox}{password} = 'FritzboxPasswort';
$credentials{RemoteFritzBox}{model} = 'FB'; # optional FB-model: FB, FBLAN, 1750E
# # model FB specifies the WLAN page, FBLAN the LAN page on Fritzbox-Web
# only required for a 2nd FB or repeater to be monitored by RemoteFritzBoxWeb - see below
$credentials{RemoteFritzBox1}{ipadress} = '192.168.1.253'; # 2nd FB LAN Adress
$credentials{RemoteFritzBox1}{username} = 'FritzBoxusername'; # optional, else 1st entry will be used
$credentials{RemoteFritzBox1}{password} = 'FritzboxPasswort'; # optional, else 1st entry will be used
$credentials{RemoteFritzBox1}{model} = '1750E'; # optional FB-model: FB, FBLAN, 1750E
</pre>
Das Format dieser cfg-file entspricht dem im Modul Webcam.
<br>Unterstützte Modelle:
FB holt und parsed die WLAN-Seite der Fritzbox, getested mit: 7270,7390,7490, DVBC-Repeater,... z.b: [http://fritz.box/wlan/wlan_settings.lua Fritzbox WLAN]
FBLAN holt und parsed die LAN-Seite der Fritzbox, getested mit: 7270,7390,7490,... z.b: [http://fritz.box/net/network_user_devices.lua Fritzbox LAN]
1750E holt und parsed die WLAN-Seite des 1750E Repeaters, z.b: [http://1750e.fritz.box/wlan/rep_settings.lua Repeater WLAN]

=== Installation und Konfiguration FHEM-Module ===
kopieren von 99_RFritzBox.pm ins FHEM Verzeichnis
<pre>sudo chown fhem:root 99_RFritzBox.pm # for user fhem</pre>
Im FHEM command-feld: <pre>reload 99_RFritzBox.pm</pre> eintippen (oder FHEM neu starten).

Die FHEM Definitionen:
<pre>define RemoteFritzBoxWeb dummy # muss RemoteFritzBoxWeb heissen, in diesem dummy wird
# das Web-login zwischengespeichert!
attr RemoteFritzBoxWeb event-on-update-reading none # verhindert unnötige notify's
attr RemoteFritzBoxWeb verbose (1-5) # optional: debugging on level 4-5</pre>

<pre>define <myName> PRESENCE function {RemoteFritzBoxWeb("<FBdevicename/FB.MAC-Adress>")} 120 120
example by name:
define myEiFonStatus PRESENCE function {RemoteFritzBoxWeb("myEiFon")} 120 120
or with MAC adress:
define myEiFonStatus PRESENCE function {RemoteFritzBoxWeb("11:22:33:44:55:66")} 120 120
</pre>
damit wird in 120 sec Abständen der Status abgefragt.

==== Optional: Zweite Fritzbox/Repeater definieren: ====
<pre>define <my2ndFritzbox> PRESENCE function{RemoteFritzBoxWeb("<FBdevicename/FB.MAC-Adress>", 1)} 120 120 </pre>
Die '''1''' im Funktionsaufruf ist wichtig!

== Debug Tip (beide Varianten)==
Log Meldungen vom Daemon bekommt man im FHEM Log durch Anlegen eines dummy devices mit dem Namen '''RemoteFritzBox''' :
<pre>
define RemoteFritzBox dummy # Variante 1
bzw:
define RemoteFritzBoxWeb dummy # Variante 2
attr RemoteFritzBoxWeb verbose 4 oder 5
</pre>
Den Daemon beenden, falls er im Hintergrund läuft (nur Variante 1):
<pre>sudo killall RFritzBoxScan.pl</pre>

have fun

[[Kategorie:Code Snippets]]
[[Kategorie:Glossary]]

FHEM startet nicht - Tipps zur Fehlersuche

2017-11-13T07:28:32Z

Mahowi: Link zu FHEMWEB gesetzt

'''Kein Zugriff auf FHEMWEB/FHEM startet nicht - Was kann ich tun???'''

Deine [[FHEMWEB]]-Seite ist nicht erreichbar? Ist FHEM tot, oder ist das Netzwerk kaputt? Was kann ich machen, um zu prüfen, woran es genau liegt?

In diesem Wiki-Artikel soll es darum gehen, wie Du für Dich prüfen kannst, ob ein Fehler bei FHEM, im Netzwerk oder ein anderes Problem vorliegt.
== Prüfen: Läuft überhaupt ein FHEM-Prozess? ==
Man kann sich unter einem Linuxsystem sämtliche laufende Prozesse auflisten lassen

<code>ps ax</code>

Der Befehl ''ps'' listet je nach Argument alle laufende Prozesse auf. Die Liste kann man nun noch nach einem bestimmten Prozess filtern. Aufruf und Ausgabe einer Prozessliste mit einem Filter nach perl sieht z. B. so aus:

<code>ps ax | grep perl</code>

<code>cooltux@fhem01-cluster:~> ps ax | grep perl</code>

<code>11320 pts/0 S+ 0:00 grep --color=auto perl</code>

Wie wir sehen, wird hier lediglich der gerade ausgeführte Befehl ''ps'' gefunden (weil das Wort ''perl'' in der Aufrufzeile stand. Es wird hier überhaupt kein Perl-Prozess gelistet. Aktuell läuft also definitiv kein FHEM, das ja ein Perl-Programm/Prozess ist.

Eine Prozessliste mit einem laufenden FHEM-Prozess könnte so aussehen:

<code>[11:31 root@fhem01-cluster cooltux] > ps ax | grep perl</code>

<code>15852 ? R 2119:09 /usr/bin/perl fhem.pl configDB</code>

<code>21447 pts/0 S+ 0:00 grep perl</code>

FHEM (''perl fhem.pl ...'') ist in diesem Fall also aktiv.
== Prüfen: Ist der laufende FHEM-Prozess überlastet? ==
Ich sollte mir anschauen, ob der FHEM-Prozess vielleicht zu sehr ausgelastet ist, der Prozess also 100 Prozent CPU Auslastung produziert?

Ein weiterer Linuxbefehl ''top'' wird uns hierbei behilflich sein:
<pre style="white-space: pre;">
[11:38 root@fhem01-cluster cooltux] > top
top - 11:38:18 up 11 days, 18:58, 1 user, load average: 1,07, 1,03, 1,00
Tasks: 125 total, 2 running, 123 sleeping, 0 stopped, 0 zombie
%Cpu(s): 24,9 us, 0,9 sy, 0,0 ni, 74,1 id, 0,0 wa, 0,0 hi, 0,1 si, 0,0 st
KiB Mem: 945524 total, 833532 used, 111992 free, 41552 buffers
KiB Swap: 102396 total, 46564 used, 55832 free. 496240 cached Mem
PID USER PR NI VIRT RES SHR S %CPU %MEM TIME+ COMMAND
15852 fhem 20 0 103652 82160 5068 R 100,0 8,7 2125:41 perl
21683 root 20 0 5740 2560 2092 R 1,0 0,3 0:00.37 top
19129 cooltux 20 0 86204 22348 3668 S 0,3 2,4 64:16.90 insync-portable
21350 cooltux 20 0 11436 2848 2248 S 0,3 0,3 0:00.10 sshd
1 root 20 0 23292 2368 1380 S 0,0 0,3 0:54.23 systemd
2 root 20 0 0 0 0 S 0,0 0,0 0:01.09 kthreadd
3 root 20 0 0 0 0 S 0,0 0,0 3:37.20 ksoftirqd/0
5 root 0 -20 0 0 0 S 0,0 0,0 0:00.00 kworker/0:0H
7 root 20 0 0 0 0 S 0,0 0,0 8:20.71 rcu_sched
8 root 20 0 0 0 0 S 0,0 0,0 0:00.00 rcu_bh
9 root rt 0 0 0 0 S 0,0 0,0 0:05.45 migration/0
</pre>
Hier können wir nun eindeutig erkennen, dass unser FHEM die CPU mit 100 Prozent auslastet. FHEM hat also ein Problem!

Zum Vergleich ein FHEM/Perl-Prozess ohne Probleme:
<pre style="white-space: pre;">
[11:50 root@fhem01-cluster cooltux] > top
top - 11:50:33 up 11 days, 19:10, 1 user, load average: 0,84, 1,03, 1,00
Tasks: 133 total, 1 running, 132 sleeping, 0 stopped, 0 zombie
%Cpu(s): 0,6 us, 0,8 sy, 0,0 ni, 98,6 id, 0,0 wa, 0,0 hi, 0,0 si, 0,0 st
KiB Mem: 945524 total, 818344 used, 127180 free, 43748 buffers
KiB Swap: 102396 total, 46820 used, 55576 free. 489652 cached Mem
PID USER PR NI VIRT RES SHR S %CPU %MEM TIME+ COMMAND
22074 fhem 20 0 86424 68516 7200 S 1,3 7,2 0:47.64 perl
22294 root 20 0 5740 2564 2092 R 1,3 0,3 0:00.19 top
22296 fhem 20 0 86424 63556 2240 S 1,3 6,7 0:00.04 perl
22297 fhem 20 0 2088 408 328 S 0,7 0,0 0:00.02 ping
7 root 20 0 0 0 0 S 0,3 0,0 8:21.23 rcu_sched
1366 mysql 20 0 620608 157132 5736 S 0,3 16,6 70:12.59 mysqld
19481 root 20 0 0 0 0 S 0,3 0,0 0:02.35 kworker/3:0
1 root 20 0 23292 2408 1420 S 0,0 0,3 0:54.27 systemd
2 root 20 0 0 0 0 S 0,0 0,0 0:01.09 kthreadd
3 root 20 0 0 0 0 S 0,0 0,0 3:37.42 ksoftirqd/0
5 root 0 -20 0 0 0 S 0,0 0,0 0:00.00 kworker/0:0H
</pre>
== Prüfen: Stimmen die Dateiberechtigungen? ==
Alle Dateien im Verzeichnis /opt/fhem/ und allen Unterverzeichnissen gehören nach der Installation dem Benutzer fhem und der Gruppe dialout. Man kann es leicht prüfen:
<code>ls -la /opt/fhem/</code>

Häufig wird der Eigentümer durch Manipulation der Dateien falsch gesetzt, mit diesem Befehl kann man alle Dateien auf den Eigentümer fhem und dessen primäre Gruppe setzen.

<code>sudo chown -R fhem: /opt/fhem/</code>

Die Setup Routine setzt den Besitz auf fhem:dialout
<code>sudo chown -R fhem:dialout /opt/fhem/</code>

== Und wenn sich gar nichts mehr tut? ==
=== Fehlernachrichten von FHEM bei dessen Start analysieren ===
In der Regel werden die Ausgaben von FHEM, auch die beim Start, gemeinsam mit vielen anderen Nachrichten in ein Logfile geschrieben. Dort kann natürlich nach Ursachen geforscht werden.

Eine einfachere Auswertung wird möglich, wenn man diese Meldungen zeitweilig in einem Terminalfenster (das Ding, um Kommandozeilenbefehle einzugeben) angezeigt bekommt. Das erreicht man z.B. auf folgendem Weg:

# Starte ein Terminalfenster bzw. einen Terminalemulator
# Wechsle in das FHEM-Installationsverzeichnis (meist: ''/opt/fhem'')
#: <code>cd /opt/fhem</code>
# Erstelle eine Kopie Deiner fhem.cfg, z.B. fhem.cfg.debug
#: <code>cp fhem.cfg fhem.cfg.debug</code>
# Bearbeite diese Kopie fhem.cfg.debug nun, um die Meldungen in das Terminalfenster zu leiten, in dem der FHEM-Start versucht wird:
#: <code>nano ./fhem.cfg.debug</code>
#:
#: In der Zeile mit "attr global logfile" ist der Dateiname durch ein - (Minuszeichen) zu ersetzen. Dadurch werden die FHEM-Ausgaben auf STDOUT (in das Terminalfenster) geschrieben, und FHEM geht nicht in den Hintergrund.

# Starte FHEM im Terminalfenster '''mit der angepassten Konfigurationsdatei''':
#: <code>perl fhem.pl fhem.cfg.debug</code>
#: Das Terminalfenster nun nicht schliessen, die Meldungen tauchen hier auf.
#: ... Die Fehlermeldungen sind nun zu interpretieren. Gegebenenfalls kann man sie kopieren und als wichtige Information bei einer Hilfeanfrage (z.B. im Forum) verwenden.
# Wenn man genug analysiert hat, FHEM mit Ctrl-C/Strg-C stoppen

'''Neue Möglichkeit des Debuggen'''

Seit dem 01.08.2017 gibt es die Möglichkeit beim manuellen Starten von FHEM im Terminal den Schalter -d zu verwenden ({{Link2Forum|Topic=74774|Message=666766}}). Dieser startet FHEM mit den beiden gesetzten Attributen <code>attr global logfile -</code> und <code>attr global verbose 5</code> und gibt somit alle Meldungen im Terminalfenster aus. Zuerst mit ins FHEM Verzeichnis wechseln. Root oder sudo ist nicht erforderlich!

<code>cd /opt/fhem</code>

fhem.cfg - Nutzer:
<code>perl fhem.pl -d fhem.cfg</code>

configDB - Nutzer:
<code>perl fhem.pl -d configDB</code>

[[Kategorie:HOWTOS]]

EBUS

2017-11-13T07:25:25Z

Mahowi: /* Mit ECMD in FHEM */ Link auf Artikel zu ECMD gesetzt

{{Randnotiz|RNTyp=r|RNText=Die Verwendung des EBUS zur ''Ansteuerung'' eines Heizungssystems kann dieses bei unsachgemäßer Anwendung beschädigen. Für unmittelbare oder mittelbare Folgen, die sich aus dem Nachbau des Interfaces oder der Verwendung der hier zur Verfügung gestellten Information ergeben, übernimmt der Autor keine Haftung.}}Dieser Artikel beschreibt die Ankopplung von Heizungssysteme mit eBus-Interface an FHEM.

Der eBus ist eine bei vielen Heizungssystemen vorhandene serielle Schnittstelle mit zwei Leitungen. Verwendet werden dabei 2400 Baud als Geschwindigkeit und die beiden Signalpegel
*logisch 1: 15–24 V
*logisch 0: 9–12 V

[[Datei:EBUS-Adapter-aufgebaut.png|thumb|left|alt=eBus Platine]]

Fertig aufgebaute eBus Platine, bereit für den Einsatz mit eBusd!
<div style="clear:both;"></div>

=Interface=
==Schaltung==
[[Datei:EBUS_Interface_Schaltung.png|thumb|left|alt=eBus-USB Interface]]
Eine direkte Ankopplung des eBus an FHEM via Pegelwandlung und serielle Schnittstelle ist nicht empfehlenswert, stattdessen wurde der Weg beschritten, einen separaten Raspberry Pi (Modell B) an den eBus zu koppeln und darauf die Software ''eBusd'' laufen zu lassen. Diese wird dann in einer beliebigen FHEM-Instanz als ECMD-Device definiert und somit per Telnet abgefragt.

Hierbei wird ein kommerziell für ca. 6,00 € erhältliches USB-Modul mit ein paar Zusatzbauteilen im Wert von ca. 5,00 € versehen. Das Interface hat die folgenden Eigenschaften:
*Verpolungssicherer eBus-Anschluss
*Galvanische Trennung zwischen eBus und USB
Die Bauteile sind unkritisch und können durch äquivalente Teile ersetzt werden. Allerdings sollte bei der Zenerdiode auf eine Belastbarkeit mit 1,3 W geachtet werden, und beim USB-Modul darauf, dass dieses einen FTDI-Chip enthält.

'''''Achtung:''' Der Autor übernimmt keine Haftung für die Anwendung dieser Schaltung. Zur Vermeidung von Schäden durch unsachgemäße Bedienung des Heizungssystems wird ausdrücklich empfohlen, nur die lesende Hälfte des Interfaces nachzubauen und sich auf ein passives Lauschen auf dem EBUS zu beschränken. Dazu einfach den Zweig mit Darlington-Transistor aus der Schaltung nicht einbauen.''

Die Schaltung des eBus von Prof. Dr. Peter A. Henning ist eine bewährte Schaltung die von zahlreichen Anwendern bereits nachgebaut wurde.
<div style="clear:both;"></div>
'''

==Eigenbau (Lochrasterplatine)==
[[Datei:EBUS_Adapter_Lochrasterplatine.png|thumb|left|alt=Platine]]

Hier ein Beispiel eines Aufbaues auf einer Lochrasterplatine.
<div style="clear:both;"></div>

==Platine==
Auf Basis der oben genannten Schaltung, wurde im {{Link2Forum|Topic=46098|LinkText=FHEM Forum}} ein Platinenlayout erstellt und produziert. Die dazu benötigten Gerberfiles können {{Link2Forum|Topic=45127|Message=370647|LinkText=hier}} heruntergeladen werden. Der Autor des Layouts hat dies mit der Freeware Version von EAGLE erstellt, d.h. die Files können bei allen Platinenherstellern eingereicht werden (keine Lizenz eines bestimmten Herstellers notwendig).
[[Datei:EBUS_Adapter_Platine.png|thumb|left|alt=Platine]]
Diese Beschreibung sollte hauptsächlich für Personen dienen, bei denen es nicht das tägliche Brot ist elektronische Schaltungen in Betrieb zu nehmen. Ich setze hier voraus, dass der Umgang mit einem Lötkolben klar ist. Wer noch nie gelötet hat, sollte besser einen Bekannten ersuchen der das schon gemacht hat.
Nachfolgend wird beschrieben, wie eine Platine mit den Bauteilen bestückt wird.
Am einfachsten ist es einen fertigen Adapter zu kaufen.
Siehe dazu auch den {{Link2Forum|Topic=46098|LinkText=Link aus dem Forum}}:
<div style="clear:both;"></div>

===Platine bestücken===
[[Datei:EBUS_Adapter_Bestueckung.png|thumb|left|alt=Platine bestücken]]
Bei der Bestückung sollte darauf geachtet werden mit den niedrigsten Bauteilen zuerst zu beginnen, sonst fallen sie beim verlöten ständig heraus. Wer die Farbcodes der Widerstände nicht auswendig kennt sollte diese vorher mit einem Meßgerät (Ohmmeter) messen. Nach den Dioden und Widerständen können die IC Sockel eingelötet werden, hier sollte lediglich auf die Einkerbung laut Bestückungsaufdruck geachtet werden. Zum Schluß noch die restlichen Bauteile. Nach einer genauen Sichtkontrolle (verbogene Beinchen des IC, Kurzschlüsse beim Löten, richtige Polung) können noch die ICS eingesetzt werden. Diese können auf einer flachen Unterlage etwas vorgebogen werden, damit sie leichter in den Sockel passen.
<div style="clear:both;"></div>
'''''Achtung''': der IC 4011 ist ein Cmos Schaltkreis und ist empfindlich gegen statische Aufladungen, daher die Beinchen nicht mit dem Finger berühren, bzw. ein Antistatikband am Arm verwenden.
<div style="clear:both;"></div>''

Bestückung der Widerstände bei Platine V1.6
R1 = 3k3
R2 = 1k0
R3 = 20k Poti
R4 = 10k (auf der Platine nicht beschriftet, links neben R2)
R5 = 470
R6 = 22k
R7 = 100k (auf der Platine nicht beschriftet, links unten liegt quer)

[https://secure.reichelt.de/index.html?&ACTION=20&AWKID=1170007&PROVID=2084 Warenkorb der benötigten Bauteile von Reichelt]
<div style="clear:both;"></div>''

===Platine Messpunkte===
[[Datei:EBUS_Adapter_Messpunkte.png|thumb|left|alt=Platine messen]]
Hier abgebildet der Schaltplan mit einigen wichtigen Spannungen für den Testbetrieb am Netzgerät. Bitte beachtet den Widerstand am Eingang des eBus und die Anschaltung der behelfsmäßigen Led zur Abstimmung. Spätestens dann, wenn die Schaltung Fehler zeigt, wird man über so einen Versuchsaufbau nicht herum kommen. Damit kann in Ruhe die Schaltung getestet und gemessen werden. Defekte Bauteile oder fehlerhafte Lötstellen sollten dann schnell gefunden werden.
<div style="clear:both;"></div>

Der Schaltplan zeigt einige wichtigen Spannungen für den Testbetrieb am Netzgerät.
Bei dem Versuchsaufbau ist insbesondere auf den Einsatz eines korrekten Vorwiderstands, am Eingang des eBus und die Anschaltung der behelfsmäßigen LED (zur Abstimmung), zu beachten (nur zur Abstimmhilfe).

===Poti abgleichen===
Zur ersten Justierung des Potis, wird der eBusd Dienst genutzt. Das Vorgehen sieht wie folgt aus:

1) '''eBus Dienst stoppen''' - Das kann mit der folgenden Kommandozeile bewerkstelligt werden:
service ebusd stop
2) '''eBus Dienst''', jedoch mit minimalen Parametern und ohne eBusd Konfigurationsdateien (CSV-Files), mit der folgenden Kommandozeile erneut starten:

'''''Hinweis:''' <DEVICE> Muss zuvor durch den entsprechenden USB-Port (siehe [[#USB Device und Port unter Linux ermitteln|USB Device und Port unter Linux ermitteln]]) z.B. /dev/ttyUSB0 ersetzt werden.''
ebusd -f -c /tmp --logareas bus --loglevel info -d <DEVICE>

3) Der eBusd Dienst läuft nun im '''Vordergrund'''.

4) '''Einem zweiten Terminal öffnen''' und den folgenden Befehl ausführen:
ebusctl raw

Mit dem Befehl erhält man im Terminalfenster die empfangenen Bytes als Hex, die wie folgt aussehen:
<syntaxhighlight lang="php">
2015-12-24 12:07:16.955 [bus notice] <aa
2015-12-24 12:07:17.001 [bus notice] <aa
2015-12-24 12:07:17.047 [bus notice] <aa
2015-12-24 12:07:17.093 [bus notice] <aa
2015-12-24 12:07:17.097 [bus notice] <10
2015-12-24 12:07:17.102 [bus notice] <50
2015-12-24 12:07:17.107 [bus notice] <b5
2015-12-24 12:07:17.111 [bus notice] <04
</syntaxhighlight>
Wenn gerade kein Gerät den Bus nutzt, dann sollten ca. 20 Zeilen pro Sekunde ausgegeben werden und zwar mit "<aa" (im Beispiel die oberen 4 Zeilen).

Sobald ein Gerät den eBus nutzt, tauchen neben "<aa" auch andere HEX Werte auf (im Beispiel die unteren 4 Zeilen). Diese Werte können ignoriert werden.

Wichtig bei der Poti Einstellung ist, dass vor allem die regulären "aa"s zu sehen sind. Tauchen die "aa"s auf, dann kann davon ausgegangen werden, dass der Poti korrekt eigestellt ist. Ist dies der Fall, dann kann der eBusd Dienst regulär gestartet werden.
Dabei muss der im Vordergrund laufende eBusd Prozess (siehe Punkt 2) mit der Tastenkombination STRG+C abgebrochen und der folgende Befehl in der Kommandozeile ausgeführt werden:
service ebusd start
Anschließend erscheint eine Meldung, die einen erfolgreichen Start des Dienstes signalisiert.
[ ok ] Starting ebusd: ebusd.

===Bekannte Fehler===
Das Logfile ist zur Inbetriebnahme unerlässlich und kann (z.B. mit [[#PSPad|PSPad]]) ausgelesen werden.
<syntaxhighlight lang="php">
2015-12-22 16:27:34.195 [bus notice] signal acquired
2015-12-22 16:28:12.029 [bus error] signal lost
2015-12-22 16:28:12.339 [bus notice] signal acquired
2015-12-22 16:28:14.006 [bus error] signal lost
2015-12-22 16:28:16.372 [bus notice] signal acquired
2015-12-22 16:28:18.023 [bus error] signal lost
2015-12-22 16:28:18.729 [bus notice] signal acquired
2015-12-22 16:28:20.458 [update notice] update myCustom Status01: 43.0;41.0;8.000;41.0;38.0;ok
2015-12-22 16:28:26.460 [update notice] update bc Mode QQ=10: standby
2015-12-22 16:28:30.436 [update notice] update myCustom Status01: 41.0;40.0;8.000;41.0;38.0;ok
2015-12-22 16:28:32.458 [update notice] update broadcast vdatetime QQ=10: 16:24:52;22.12.2015
2015-12-22 16:28:32.696 [update notice] update myCustom2 Pumpenstatus: ok
2015-12-22 16:28:36.452 [update notice] update bc Mode QQ=10: standby
2015-12-22 16:28:40.478 [update notice] update myCustom Status01: 40.0;39.0;7.750;41.0;38.0;ok
2015-12-22 16:28:42.482 [update notice] update myCustom1 Status11: nosignal;41;5;18;-;-;-;-;8.000
2015-12-22 16:28:42.753 [update notice] update myCustom Status02: auto;60;70.0;70;54.0
</syntaxhighlight>

Hier ein typisches Log wenn das Poti noch nicht oder '''falsch kalibriert''' wurde.
Ab dem Eintrag 16:28:20.458 war dann die richtige Stellung gefunden. Das Poti soll daher zunächst ganz nach links (Transistor der Platine ist dann rechts unten) gedreht werden und dann vorsichtig auf etwa 2:00 Uhr. Bei knapp 2:00 Uhr ist bei der Testplatine dann die ideale Stellung. Der Stellbereich ist sehr klein (etwa 1-2 mm), daher einen Schraubendreher verwenden der sehr exakt passt und gleichzeitig mit dem Laptop abfragen starten. Zur Kontrolle dann das Log (var/log/ebusd.log) abfragen.

<syntaxhighlight lang="php">
2015-11-29 06:26:55.271 [update notice] update myCustom1 Status11: nosignal;40;0;15;-;-;-;-;-0.188
2015-11-29 06:26:55.541 [update notice] update myCustom Status02: auto;60;70.0;70;54.0
2015-11-29 06:26:59.293 [update notice] update bc Mode QQ=10: standby
2015-11-29 06:27:03.323 [update notice] update myCustom Status01: 53.0;45.0;-0.438;47.0;46.0;error
2015-11-29 06:27:05.268 [update notice] update broadcast outsidetemp QQ=10: -3.188
2015-11-29 06:27:09.344 [update notice] update bc Mode QQ=10: standby
2015-11-29 06:27:11.934 [bus error] send to 08: ERR: read timeout, retry
2015-11-29 06:27:11.981 [bus error] send to 08: ERR: read timeout, retry
2015-11-29 06:27:12.025 [bus error] send to 08: ERR: read timeout, retry
2015-11-29 06:27:12.069 [bus error] send to 08: ERR: read timeout
</syntaxhighlight>

In diesem Fall liegt ein Fehler bei jedem Sendeversuch vor. Ein "bus error" mit timeout sollte nicht (zu oft) zu finden sein. Gut zu sehen sind schon die Broadcast Meldungen, die selbständig über den Bus laufen und vom Konverter schon richtig interpretiert werden. Sollten wie in diesem Fall, die Meldungen nicht mit Texten zu lesen sein fehlen noch die Konfigurationfiles (csv) im Verzeichnis /etc/ebusd. Welche Files hier verwendet werden sollen ist natürlich von der Therme und dem Zubehör abhängig.

'''''Achtung''': Der Autor übernimmt keine Haftung für die Anwendung dieser Schaltung. Zur Vermeidung von Schäden durch unsachgemäße Bedienung des Heizungssystems wird ausdrücklich empfohlen, nur lesend auf die Schnittstelle zugreifen.''

==Kommerzielles Interface==
Ein kommerzielles Interface für die Umsetzung eBus->USB ist hier erhältlich:
[https://www.eservice-online.de/produkte/ebus/ eBus Koppler USB]

=Software=
Als Software kommt auf dem Raspberry Pi der [https://github.com/john30/ebusd ebusd] = eBus-Dämon zum Einsatz (aktuell im Januar 2016 die Version 2.0).

Der ebusd wird auf dem System (z.B Raspberry Pi) nach der beiliegenden Anleitung übersetzt und installiert.

Wichtigsten Bestandteile (Komponenten) der Installation sind:
*''ebusd'' - das eigentliche Programm zur Kommunikation mit dem EBUS
*''ebusd-configuration - Dateien im CSV(Comma Separated Value)-Format, die beim Start des eBusd eingelesen und als Kommandos (Befehle) für das Heizungsystem verwendet werden.

Nachfolgend wird die Installation der zwei Komponenten beschrieben.

==eBusd Installation per Debian Package==

===Voraussetzungen===
wget (ist in der Regel auf vielen Distributionen bereits installiert). Die Installation kann mit der folgenden Kommandozeile nachträglich durchgeführt werden:
sudo apt-get install wget

===eBusd installieren===
Das entsprechende eBusd Debian Package kann [https://github.com/john30/ebusd/releases vom GitHub ebusd] bezogen werden.

Die Installation (''Stand Januar 2016 - Version 2.0'') wird wie folgt durchgeführt:

EBUSDPACKAGE=ebusd-2.0_armhf.deb # <--- Version kann bei Bedarf hier angepasst werden.
wget https://github.com/john30/ebusd/releases/download/v2.0/$EBUSDPACKAGE
sudo dpkg -i --force-overwrite $EBUSDPACKAGE

'''''Hinweis:''' Die eBusd wird dauernd aktualisiert. Aus diesem Grund sollte vor der Installation geprüft werden (siehe den o.g. Link), ob bereits eine neuere Version zur Verfügung steht. Der Name des Debian Packages muss, vor der Ausführung der o.g. Kommandozeilen, an der entsprechenden Stelle angepasst werden.''

===eBusd Konfigurationsdateien (CSV-Files)===
Das entsprechende eBusd Konfigurations Debian Package kann [https://github.com/john30/ebusd-configuration/releases vom GitHub ebusd-configuration] bezogen werden.

Die Installation (''Stand Januar 2016 - Version 2.0.5aa482c'') wird wie folgt durchgeführt:

EBUSDCFGPACKAGE=ebusd-configuration-2.0.5aa482c-de_all.deb # <--- Version kann bei Bedarf hier angepasst werden.
wget https://github.com/john30/ebusd-configuration/releases/download/v2.0.1/$EBUSDCFGPACKAGE
sudo dpkg -i --force-overwrite $EBUSDCFGPACKAGE

===eBusd starten===
Nach der erfolgreichen Installation des eBusd und der eBusd Konfigurationsdateien kann nun der Dienst gestartet werden.
Zuvor muss jedoch der USB-Port des eBus Adapters überprüft werden (siehe auch [[#USB Device und Port unter Linux ermitteln|USB Device und Port unter Linux ermitteln]]). Sollte der USB-Port von dem Standardwert "/dev/ttyUSB0" abweichen, dann muss die Konfiguration "/etc/default/ebusd" angepasst werden.
Andernfalls kann nun der Dienst mit der folgenden Kommandozeile gestartet werden:

service ebusd start
Anschließend erscheint eine Meldung:
[ ok ] Starting ebusd: ebusd.
die einen erfolgreichen Start des Dienstes signalisiert.

===eBusd und Konfigurationsdateien deinstallieren===
Nachfolgend wird die Deinstallation des eBusd und der eBusd Konfigurationsdateien beschrieben.

Zunächst muss der eBusd Dienst beendet werden, dies erfolgt mit der folgenden Kommandozeile:
service ebusd stop
Anschließend erscheint eine Meldung:
[ ok ] Stopping ebusd: ebusd.
die einen erfolgreichen Stop des Dienstes signalisiert.

Anschließend wird zunächst das Debian Konfigurations Package deinstalliert.

'''''Achtung:''' Bei der Deinstallation werden alle Konfigurationsdateien (CSV-Files) unwiderruflich gelöscht!''

Die Deinstallation erfolgt mit der folgenden Kommandozeile:
sudo dpkg -r --force-overwrite ebusd-configuration

Das eBusd Debian Package wird mit der folgenden Kommandozeile deinstalliert:
sudo dpkg -r --force-overwrite ebusd

'''Tipp:''' Mit der folgenden Kommandozeile:
dpkg -l | grep 'ebusd'
können die installierten eBusd Debian Packages überprüft werden.

Liefert der Befehl kein Ergebnis, dann kann davon ausgegangen werden, dass kein eBusd Debian Package mehr installiert ist.

==eBusd Installation Build Prozess==
Möchte man eine aktuelle Entwicklungsversion von eBusd nutzen, weil ein Fehler behoben wurde und für diese Version noch kein Debian Package vorhanden ist, dann kann der eBusd manuell kompiliert werden. Nachfolgend werden die dafür notwendigen Schritte beschrieben.

===Voraussetzungen===
Zunächst müssen die notwendigen Werkzeuge auf dem System installiert werden. Dies erfolgt mit der nachfolgenden Kommandozeile:
apt-get -y install git && apt-get -y install autoconf && apt-get -y install automake && apt-get -y install g++ && apt-get -y install make

Weiterführende Informationen findet man auch direkt im eBusd [https://github.com/john30/ebusd/wiki/1.-Build-and-install Wiki]!

===eBusd kompilieren ===

Nachdem alle Voraussetzungen erfüllt sind, kann der eBusd auf dem lokalen System kompiliert und installiert werden.
Dafür sind folgende Schritte notwendig:

'''eBusd auschecken'''

git clone https://github.com/john30/ebusd.git

'''Den Kompilierungsvorgang starten'''
<syntaxhighlight lang="bash">
cd ebusd
sudo ./autogen.sh --prefix=/usr
sudo make
sudo make install
sudo cp contrib/debian/default/ebusd /etc/default/ebusd # Konfigurationsdatei für eBusd Startoptionen.
</syntaxhighlight>

Dieser Vorgang kann je nach Geschwindigkeit des Systems ca. 20 Minuten dauern.

Wurde der Vorgang erfolgreich durchgeführt, dann kann mit der folgenden Kommandozeile die Version abgefragt werden:

ebusd -V

===Autostart von eBusd konfigurieren===

Damit die Austostartroutine auch nach einem Neustart des Systems funktioniert, muss das Dämonstartfile in das entsprechende Verzeichnis kopiert werden.
Die Konfiguration wird mit der folgenden Kommandozeile durchgeführt:

sudo cp contrib/debian/init.d/ebusd /etc/init.d/ebusd # (Dämonstartfile kopieren)

Der eBusd Dienst kann, wie [[#eBusd starten|hier]] beschrieben, gestartet werden.

===eBusd Logrotate===
Logrotate ist ein logischer Ablauf was mit dem Logfile geschehen soll. Man kann damit das File täglich komprimieren und das 7 Tage lang, dann erst wieder beginnen es zu überschreiben. Dies ist besonders wichtig, denn sonst würde irgendwann das Logilfe bis zu einer extremen Größe anwachsen.

<syntaxhighlight lang="bash">
/var/log/ebusd.log {
rotate 7
copytruncate
compress
missingok
notifempty
daily
}
</syntaxhighlight>

Das Logfile kann in '''/etc/logrotate.d/ebusd''' konfiguriert werden.
In diesem Beispiel wird alle 7 Tage rotiert und die Datei komprimiert, das aktuelle Tagesfile ist unkomprimiert und mit einem Editor lesbar.
Das Ergebnis aus der oben dargestellten Definition sieht wie folgt aus:
[[Datei:EBUS_Logfile_logrotate.png|thumb|left|alt=Logfile Ansicht]]
<div style="clear:both;"></div>

=Systemüberwachung=

Aufgrund unterschiedlicher Ursachen kann es vorkommen, dass der eBus Dämon seinen Dienst einstellt. Die hätte zufolge, dass der Lese- und Schreibzugriff nicht mehr möglich wäre. Nachfolgend werden zwei Möglichkeiten beschreiben wie eine Überwachung des Systems realisiert und im Störungsfall die Funktionalität wiederhergestellt, werden kann.

==Mithilfe von FHEM==

In FHEM kann man ein Notify einrichten, um bei einem Verbindungsabbruch mehrere Versuche zum Reconnect durchzuführen
<syntaxhighlight lang="php">
# fhem.cfg
define EBUS.N notify (EBUS.*DISCONNECTED.*)|(HK.Hz:A.Temp.*err) { EBUSrecover("notify EBUS.N",0)}
attr EBUS.N group deviceDetector
attr EBUS.N room Alarm
</syntaxhighlight>

Das dabei aufgerufene Perl-Programm besteht nur aus wenigen Zeilen und muss in die 99_myUtils.pm kopiert/erweitert werden:
<syntaxhighlight lang="perl">
# 99_myUtils.pm
sub EBUSrecover($$)
{
my ($evt,$num) = @_;
Log 1,"[EBUS] Recover triggered from $evt, attempt No. $num";
if(Value("EBUS") ne "opened"){
if( $num < 7){
$num++;
fhem("set EBUS reopen");
fhem("delete EBUSrecoverdly") if($defs{"EBUSrecoverdly"});
fhem("define EBUSrecoverdly at +00:00:05 {EBUSrecover('EBUSrecover',$num)}");
}else{
fhem("set Device.warn EBUS")
}
}
}
</syntaxhighlight>

==Mithilfe von Watchdog==

Es empfiehlt sich auch, den ebusd kontinuierlich zu überwachen und ggf. neu zu starten. Mit der nachfolgenden Beschreibung wird alle 5 Sekunden die Existenz des Programms abgefragt und dieses bei einem versagenden Test neu gestartet.

Dazu wird auf dem System nach überall erhältlichen Anleitungen der Watchdog Timer installiert und die Datei /etc/watchdog.conf mit den beiden Parametern
test-timeout = 10
interval = 5
besetzt. Ferner wird die Datei /etc/watchdog.d/ebusd angelegt mit dem Inhalt
<syntaxhighlight lang="bash">
#!/bin/sh
# description: watchdog helper file for ebusd
case "$1" in
'test')
#--- Test for ebusd
if [ -s /var/run/ebusd.pid ] ; then
RUN=`ps -ef | grep ebusd.*USB0 | grep -v grep`
if [ "$RUN" != "" ] ; then
#echo "ebusd is already running"
exit 0
else
echo "ebusd defunct at "`date`
exit 1
fi
else
echo "ebusd not running, return 1 at "`date`
exit 1
fi
;;
'repair')
#-- Restarting ebusd
echo "ebusd restarting at "`date`
/etc/init.d/ebusd start
RETVAL=$?
exit 0
;;
*)
exit 0
;;
esac
</syntaxhighlight>

=Visualisierung und Steuerung=

==Mit ECMD in FHEM==
Eine einfache aber sichere Anbindung des eBusd an FHEM kann mit [[ECMD]] durchgeführt werden. Es ist egal ob eBusd auf dem selben Raspberry wie FHEM läuft oder ein eigener Raspberry dafür verwendet wird. Die gezeigten Beispiele sind nur eine der Möglichkeiten die zum Ziel führen, sollen aber sicher und schnell zu den ersten Erfolgen führen.

===ECMD in FHEM aktivieren===
<syntaxhighlight lang="php">
# fhem.cfg
define EBUS ECMD telnet '''ip-raspi-ebusd''':8888 # IP Adresse ebusd einsetzen!!!
attr EBUS classdefs bai00.class=/opt/fhem/FHEM/bai00.cfg
attr EBUS icon usb
attr EBUS requestSeparator 000
attr EBUS room Vaillant

# Die Definition von ECMD, "ip-raspi-ebusd" muss durch die IP-Adresse ersetzt werden. Beispiel:
define EBUS ECMD telnet 192.168.0.10:8888
</syntaxhighlight>
Die Kommunikation erfolgt über Telnet und 8888 ist das Port über welches kommuniziert werden soll.

===ECMD Devices definieren===
<syntaxhighlight lang="php">
# fhem.cfg
define Vorlauf ECMDDevice bai00.class
attr Vorlauf IODev EBUS
attr Vorlauf group Vaillant
attr Vorlauf icon sani_supply_temp
attr Vorlauf room Vaillant

define Ruecklauf ECMDDevice bai00.class
attr Ruecklauf IODev EBUS
attr Ruecklauf group Vaillant
attr Ruecklauf icon sani_return_temp
attr Ruecklauf room Vaillant

define PumpeWatt ECMDDevice bai00.class
attr PumpeWatt IODev EBUS
attr PumpeWatt group Vaillant
attr PumpeWatt icon measure_power
attr PumpeWatt room Vaillant

define Fanspeed ECMDDevice bai00.class
attr Fanspeed IODev EBUS
attr Fanspeed group Vaillant
attr Fanspeed icon vent_ventilation_level_automatic
attr Fanspeed room Vaillant

define HKurve ECMDDevice bai00.class
attr HKurve IODev EBUS
attr HKurve group Vaillant
attr HKurve icon temp_control
attr HKurve room Vaillant
</syntaxhighlight>
Jeder Messwert der von eBusd abgefragt werden soll, muss dazu ein ECMDDevice erstellt werden. Hier ein paar Beispiele mit Vorlauf, Rücklauf, Leistung der Pumpe, Ventilatorgeschwindigkeit und der Heizkurve.

[[Datei:EBUS_Daten_Heizung.png|thumb|left|alt=EBUS-USB Interface]]
Zu jedem ECMDDevice muss es eine Classdefinition in der bai00.cfg geben. Der Name "bai00.cfg" ist frei gewählt und wird in diesen Beispielen verwendet.
<div style="clear:both;"></div>

===ECMD Classdefinition===

Um eine Klasse zu definieren muss der dazu benötigte Code in eine eigene Datei (hier bai00.cfg) geschrieben werden.

<syntaxhighlight lang="perl">
################## bai00.cfg ###############
#
#!/usr/bin/perl
# Aussentemperatur
get Aussentemp cmd {"r -f outsidetemp temp\n"}
get Aussentemp expect ".*\n*"
get Aussentemp postproc { $_ }
#
# vorlauftemperatur
get Vorlauf cmd {"r -m 10 status01 temp1.0\n"}
get Vorlauf expect "\d+\.\d+\n\n"
get Vorlauf postproc { sprintf("%5.1f",$_) }
#
# Ruecklauftemperatur
get Ruecklauf cmd {"r -m 10 status01 temp1.1\n"}
get Ruecklauf expect "\d+\.\d+\n\n"
get Ruecklauf postproc { sprintf("%5.1f",$_) }
#
# Pumpenleistung
get PumpeWatt cmd {"r -f PumpPower\n"}
get PumpeWatt expect "\d+\n\n"
get PumpeWatt postproc { sprintf("%5.0f",$_) }
#
# Fanspeed
get Fanspeed cmd {"r -f SDFanSpeed\n"}
get Fanspeed expect "\d+\n\n"
get Fanspeed postproc { sprintf("%5.0f",$_) }
#
# Heizkurve lesen
get HKurve cmd {"r -f Hc1HeatCurve\n"}
get HKurve expect "\d+\.\d+\n"
get HKurve postproc { sprintf("%3.1f",$_) }
#
# HeizkurveSchreiben
get HeizkurveSchreiben cmd {"write 430 Hc1HeatCurve ".Value("HeizkurveEinstellen")."\n"}
get HeizkurveSchreiben expect ".*\n\n"
get HeizkurveSchreiben postproc { $_ }
</syntaxhighlight>

Für jeden Device wird hier festgelegt wie die Befehls Syntax der Abfrage auszusehen hat (cmd) und wie die Ergebnisse zu filtern sind (expect), wie soll das Ausgabeformat sein (postproc). Diese Definitionen bitte in einer neuen Datei "bai00.cfg" speichern.

===ECMD Zyklische Abfrage===
<syntaxhighlight lang="php">
# Abfrage Timersteuerung, fhem.cfg
define EBUS.Timer at +*00:15:00 get Aussentemp Aussentemp;;get Vorlauf Vorlauf;;get Ruecklauf Ruecklauf;;get PumpeWatt PumpeWatt;get Fanspeed Fanspeed;;get PumpeWatt PumpeWatt;;get HKurve HKurve
attr EBUS.Timer group VaillantControl
attr EBUS.Timer icon time_timer
attr EBUS.Timer room Vaillant
attr EBUS.Timer verbose 0
</syntaxhighlight>

Um die Daten auch zyklisch vom eBus abholen zu können, wird ein Timer gesetzt. Hier wird alle 15 Minuten abgefragt.
Tipp: unwichtige Daten wie Druck oder irgendwelche Zähler definiert man in einem zweiten Timer, welcher dann zB. auf 1 Stunde getriggert wird. So wird die Häufigkeit des Zugriffs auf den eBus entlastet.

===ECMD Solar, Warmwasser und Heizkreis===

====ECMD Beispiel Solar====
Im nachfolgenden Beispiel wird der EBUS über das Modul ECMD angebunden und mit drei Klassen von Kommandos versehen. IP Adresse ist jene des Device wo der eBusd läuft.
<syntaxhighlight lang="php">
define EBUS ECMD telnet 192.168.0.192:8888
attr EBUS classdefs HK.SOL.class=/opt/fhem/FHEM/ebus_solar.cfg:HK.WW.class=/opt/fhem/FHEM/ebus_ww.cfg:HK.Hz.class=/opt/fhem/FHEM/ebus_hz.cfg
attr EBUS room System
#--
define HK.Hz ECMDDevice HK.Hz.class
attr HK.Hz IODev EBUS
attr HK.Hz group heating
attr HK.Hz room Verbrauch
#--
define HK.WW ECMDDevice HK.WW.class
attr HK.WW IODev EBUS
attr HK.WW group heating
attr HK.WW room Verbrauch
#--
define HK.SOL ECMDDevice HK.SOL.class
attr HK.SOL IODev EBUS
attr HK.SOL group solarGenerator
attr HK.SOL room Solaranlage
#--
# Diese drei Klassen werden als separate Files mit den in der EBUS-Definition stehenden Dateinamen ''ebus_hz.cfg'', ''ebus_ww.cfg'' sowie ''ebus_solar.cfg'' angelegt. Alle drei ECMD-Devices werden nun zyklisch (z.B. jede Minute) abgefragt mit
define EBUS.Timer at +*00:01:00 get HK.Hz A.Temp;;get HK.Hz state;;get HK.WW state;;get HK.SOL state
attr EBUS.Timer group heatingControl
attr EBUS.Timer room Verbrauch
attr EBUS.Timer verbose 0
</syntaxhighlight>

====ECMD Classdefinition Heizkreis====
Die erste Datei definiert die FHEM-Readings für die Abfrage von Außentemperatur und Heizkreis:
<syntaxhighlight lang="perl">
# Außentemperatur
get A.Temp cmd {"cyc broad temp\n"}
get A.Temp expect ".*"
get A.Temp postproc { my $rval;\
if(($_ eq "")||($_ eq "no data stored") ){\
$rval = "err";\
}else{\
$rval=sprintf("%5.2f °C",$_);\
}\
$rval; }
# Heizkeis HK1
get state cmd {"cyc mv HK1_temp\n"}
get state expect ".*"
get state postproc { my ($bval,$rval,$tval,$pval,$qval,$sval,$xval,$zval);\
my $hash = $defs{"%NAME"};\
if( ($_ eq "")||($_ eq "no data stored") ){\
$bval = "err";\
$rval = "err";\
$tval = "err";\
$pval = "err";\
$qval = "err";\
$sval = "err";\
$xval = "err";\
$zval = "err";\
}else{\
my @values=split(' ',$_);\
if( $values[0] < 15 ){\
$bval = "err";\
$rval = "err";\
$tval = "err";\
$pval = "err";\
$qval = "err";\
$sval = "err";\
$xval = "err";\
$zval = "err";\
} else { \
$bval = HzBedarf();\
$rval = sprintf("%5.2f °C",$values[0]);\
$tval = sprintf("%5.2f °C",$values[1]);\
if( $values[2] == 0 ){\
$pval = "OFF";\
$qval = "0 0";\
}elsif( $values[2] == 1 ){\
$pval = "ON (HK)";\
$qval = "80 0";\
}elsif( $values[2] == 2 ){\
$pval = "ON (WW)";\
$qval = "0 80";\
}else{\
$pval = "unknown";\
$qval = "err";\
}\
$sval = sprintf("%d",$values[2]);\
$xval = sprintf("%5.2f %5.2f %s %5.2f",\
$values[0],$values[1],$qval,$bval);\
$zval = sprintf("VL.T %5.2f °C, RL.T %5.2f °C, %s",\
$values[0],$values[1],$pval);\
}\
}\
readingsSingleUpdate($hash, "VL.T", $rval, 1);\
readingsSingleUpdate($hash, "RL.T", $tval, 1);\
readingsSingleUpdate($hash, "Pumpe", $pval, 1); \
readingsSingleUpdate($hash, "Pumpe.P", $qval, 1); \
readingsSingleUpdate($hash, "Bedarf", $bval, 1); \
readingsSingleUpdate($hash, "Status", $sval, 1);\
readingsSingleUpdate($hash, "reading", $xval, 1);\
$zval; }
</syntaxhighlight>

====ECMD Classdefinition Warmwasserkreis====
Die zweite Datei definiert die FHEM-Readings für den Warmwasserkreis:
<syntaxhighlight lang="perl">
# Warmwasserkreis
get state cmd {"cyc broad getstatus_WW\n"}
get state expect ".*"
get state postproc { my ($rval,$tval,$bval,$pval,$xval,$zval);\
my $hash = $defs{"%NAME"};\
if( ($_ eq "")||($_ eq "no data stored") ){\
$rval = "err";\
$tval = "err";\
$bval = "err";\
$pval = "err";\
$xval = "err";\
$zval = "err";\
}else{\
my @values=split(' ',$_);\
if( $values[1] < 15 ){\
$rval = "err";\
$tval = "err";\
$bval = "err";\
$pval = "err";\
$xval = "err";\
$zval = "err";\
}else {\
$rval = sprintf("%5.2f °C",$values[0]);\
$tval = sprintf("%5.2f °C",$values[1]);\
$bval = ($values[2] == 80) ? "ON (WW)" : "OFF";\
$pval = ($values[3] == 1) ? "ON" : "OFF";\
$xval = sprintf("%5.2f %5.2f %5.2f %d %d",\
$values[0],0.0,$values[1],$values[2],$values[3]);\
$zval = sprintf("SF1.T %5.2f °C, %s",\
$values[0],$pval);\
}\
}\
$zval; }
</syntaxhighlight>

====ECMD Classdefinition Solarkreis====
Die dritte Datei definiert die FHEM-Readings für den Solarkreis:
<syntaxhighlight lang="perl">
# Solarkreis
get state cmd {"cyc broad getstatus_SOL\n"}
get state expect ".*"
get state postproc { my ($rval,$pval,$qval,$lval,$yval,$xval,$zval);\
my $hash = $defs{"%NAME"};\
if( ($_ eq "")||($_ eq "no data stored") ){\
$rval = "err";\
$pval = "err";\
$qval = "err";\
$lval = "err";\
$yval = "err";\
$xval = "err";\
$zval = "err";\
}else{\
my @values=split(' ',$_);\
$rval = sprintf("%5.2f °C",$values[0]);\
$pval = ($values[1] == 1)?"ON":"OFF";\
$qval = ($values[1] == 1)?65:0;\
$lval = sprintf("%5.2f %%",$values[2]);\
$yval = sprintf("%d",$values[3]);\
$xval = sprintf("%5.2f %d %5.2f %d",\
$values[0],$qval,$values[2],$values[3]);\
$zval = sprintf("Coll.T %5.2f °C, %s",\
$values[0],$pval);\
}\
readingsSingleUpdate($hash, "Coll.T", $rval, 1);\
readingsSingleUpdate($hash, "Pumpe", $pval, 1);\
readingsSingleUpdate($hash, "Pumpe.P", $qval." W", 1);\
readingsSingleUpdate($hash, "Load", $lval, 1);\
readingsSingleUpdate($hash, "Yield", $yval, 1);\
readingsSingleUpdate($hash, "reading", $xval, 1);\
$zval; }
</syntaxhighlight>

===ECMD Classdefinition Heizkurve===

Diese Klassendefinition muss in der bai00.cfg gespeichert (angehängt) werden.
in diesem Beispiel wurde sie für die Vaillant Calormatic 430 definiert, bei einer Calormatic 470 muss der Text entsprechend geändert werden.

<syntaxhighlight lang="php">
# HeizkurveSchreiben Calormatic 430, bai00.cfg
get HeizkurveSchreiben cmd {"write -c 430 Hc1HeatCurve ".Value("HeizkurveEinstellen")."\n"}
get HeizkurveSchreiben expect ".*\n\n"
get HeizkurveSchreiben postproc { $_ }
</syntaxhighlight>

===Heizkurve schreiben===
<syntaxhighlight lang="php">
#fhem.cfg
define HeizkurveEinstellen dummy
attr HeizkurveEinstellen group Heizkurve_Einstellen
attr HeizkurveEinstellen icon temp_control
attr HeizkurveEinstellen room Vaillant,Heizung
attr HeizkurveEinstellen setList state:0.20,0.40,0.50,0.60,0.70,0.80,0.90,1.00,1.10,1.20,1.30,1.40,1.50,1.60,1.70
attr HeizkurveEinstellen webCmd state

define HeizkurveSchreiben_Click notify HeizkurveEinstellen {\
fhem("get HeizkurveSchreiben HeizkurveSchreiben");;\
}
attr HeizkurveSchreiben_Click group heatingControl
attr HeizkurveSchreiben_Click room Vaillant

define HeizkurveSchreiben ECMDDevice bai00.class
attr HeizkurveSchreiben IODev EBUS
attr HeizkurveSchreiben group Heizkurve_Einstellen
attr HeizkurveSchreiben room Vaillant
</syntaxhighlight>

Ein kleines Demo wie man via ECMD und eBus die Daten zurück in die Register der Therme (Calormatic) schreiben kann. Hier wird die Heizkurve verstellt.
Ein Dummy wird definiert und über eine setList werden die verschiedenen Kurven vorgegeben. Dank setList kann es zu keinen unerlaubten Eingaben kommen. Über den notify wird die Heizkurve dann schließlich gesetzt.

[[Datei:EBUS_Heizkurve_Einstellen.png|thumb|left|alt=EBUS-USB Interface]]
Vorsicht: überlegt euch bitte gut was ihr zurück schreiben wollt, es kann unter Umständen gefährlich für eure Hardware oder Gesundheit werden (zB: Warmwasser auf über 60 Grad). Alles was hier durchgeführt wird, führt ihr auf eigene Verantwortung durch.
<div style="clear:both;"></div>

===Wochenprogramme===
Ein gerne benutztes Feature ist die Änderung der Zeitprogramme des Heizgerätes in FHEM. Die Visualisierung ist etwas komplexer weil alles x 7 ist und hier Steuerzeichen beim Zusammensetzen des Sendestrings vorkommen die nicht direkt übergeben werden können. Einzelne Timer können damit nicht geschrieben werden, daher wird bei jeder Timereingabe der komplette String geschrieben. Der Einfachheit halber und wegen der Übersicht sind nur 2 Tagesprogramme (Timer) im Beispielcode vorgesehen (die Calormatic kann 3).
[[Datei:EBUS_Timerprogramme.png|thumb|left|alt=Wochentimer]]
<div style="clear:both;"></div>
<syntaxhighlight lang="perl">
#####################
# Timer-Programme #
#####################
get Mo cmd {"r -f hc1Timer.Monday\n"}
get Mo expect ".*\n\n"
get Mo postproc { Vaillant_Timer($_); }
get Di cmd {"r -f hc1Timer.Tuesday\n"}
get Di expect ".*\n\n"
get Di postproc { Vaillant_Timer($_); }
get Mi cmd {"r -f hc1Timer.Wednesday\n"}
get Mi expect ".*\n\n"
get Mi postproc { Vaillant_Timer($_); }
get Do cmd {"r -f hc1Timer.Thursday\n"}
get Do expect ".*\n\n"
get Do postproc { Vaillant_Timer($_); }
get Fr cmd {"r -f hc1Timer.Friday\n"}
get Fr expect ".*\n\n"
get Fr postproc { Vaillant_Timer($_); }
get Sa cmd {"r -f hc1Timer.Saturday\n"}
get Sa expect ".*\n\n"
get Sa postproc { Vaillant_Timer($_); }
get So cmd {"r -f hc1Timer.Sunday\n"}
get So expect ".*\n\n"
get So postproc { Vaillant_Timer($_); }
get ZeitfensterSchreibenMo cmd {"write -c 430 hc1Timer.Monday ".ReadingsVal("TimeMo","HHMM1",0) . chr(59) . ReadingsVal("TimeMo","HHMM2",0) . chr(59) . ReadingsVal("TimeMo","HHMM3",0) . chr(59) . ReadingsVal("TimeMo","HHMM4",0) . chr(59) . "24:00" . chr(59) . "24:00" . chr(59) . "selected\n"}
get ZeitfensterSchreibenMo expect ".*\n\n"
get ZeitfensterSchreibenMo postproc { $_ }
get ZeitfensterSchreibenDi cmd {"write -c 430 hc1Timer.Tuesday ".ReadingsVal("TimeDi","HHMM1",0) . chr(59) . ReadingsVal("TimeDi","HHMM2",0) . chr(59) . ReadingsVal("TimeDi","HHMM3",0) . chr(59) . ReadingsVal("TimeDi","HHMM4",0) . chr(59) . "24:00" . chr(59) . "24:00" . chr(59) . "selected\n"}
get ZeitfensterSchreibenDi expect ".*\n\n"
get ZeitfensterSchreibenDi postproc { $_ }
get ZeitfensterSchreibenMi cmd {"write -c 430 hc1Timer.Wednesday ".ReadingsVal("TimeMi","HHMM1",0) . chr(59) . ReadingsVal("TimeMi","HHMM2",0) . chr(59) . ReadingsVal("TimeMi","HHMM3",0) . chr(59) . ReadingsVal("TimeMi","HHMM4",0) . chr(59) . "24:00" . chr(59) . "24:00" . chr(59) . "selected\n"}
get ZeitfensterSchreibenMi expect ".*\n\n"
get ZeitfensterSchreibenMi postproc { $_ }
get ZeitfensterSchreibenDo cmd {"write -c 430 hc1Timer.Thursday ".ReadingsVal("TimeDo","HHMM1",0) . chr(59) . ReadingsVal("TimeDo","HHMM2",0) . chr(59) . ReadingsVal("TimeDo","HHMM3",0) . chr(59) . ReadingsVal("TimeDo","HHMM4",0) . chr(59) . "24:00" . chr(59) . "24:00" . chr(59) . "selected\n"}
get ZeitfensterSchreibenDo expect ".*\n\n"
get ZeitfensterSchreibenDo postproc { $_ }
get ZeitfensterSchreibenFr cmd {"write -c 430 hc1Timer.Friday ".ReadingsVal("TimeFr","HHMM1",0) . chr(59) . ReadingsVal("TimeFr","HHMM2",0) . chr(59) . ReadingsVal("TimeFr","HHMM3",0) . chr(59) . ReadingsVal("TimeFr","HHMM4",0) . chr(59) . "24:00" . chr(59) . "24:00" . chr(59) . "selected\n"}
get ZeitfensterSchreibenFr expect ".*\n\n"
get ZeitfensterSchreibenFr postproc { $_ }
get ZeitfensterSchreibenSa cmd {"write -c 430 hc1Timer.Saturday ".ReadingsVal("TimeSa","HHMM1",0) . chr(59) . ReadingsVal("TimeSa","HHMM2",0) . chr(59) . ReadingsVal("TimeSa","HHMM3",0) . chr(59) . ReadingsVal("TimeSa","HHMM4",0) . chr(59) . "24:00" . chr(59) . "24:00" . chr(59) . "selected\n"}
get ZeitfensterSchreibenSa expect ".*\n\n"
get ZeitfensterSchreibenSa postproc { $_ }
get ZeitfensterSchreibenSo cmd {"write -c 430 hc1Timer.Sunday ".ReadingsVal("TimeSo","HHMM1",0) . chr(59) . ReadingsVal("TimeSo","HHMM2",0) . chr(59) . ReadingsVal("TimeSo","HHMM3",0) . chr(59) . ReadingsVal("TimeSo","HHMM4",0) . chr(59) . "24:00" . chr(59) . "24:00" . chr(59) . "selected\n"}
get ZeitfensterSchreibenSo expect ".*\n\n"
get ZeitfensterSchreibenSo postproc { $_ }
</syntaxhighlight>

Dieses Beispiel ist für eine Vaillant Calormatic 430, bei einer Calormatic 470 müssen die entsprechenden Zeilen angepasst werden (write -c 430....) .

<syntaxhighlight lang="perl">
#########################################################
#
# Vaillant_Timer
# Datenstring = 03:30;19:30;20:00;20:00;20:00;20:00;Mo-Fr
#########################################################
# 99_myUtils.pm
sub Vaillant_Timer($)
{
my @values=split(/[; ]/,$_);
#-- suppress leading zero ?
for(my $i=0;$i<7;$i++){
$values[$i]=~s/^0//;
}
my $sval=sprintf("%s-%s",$values[0],$values[1]);
$sval .=sprintf(", %s-%s",$values[2],$values[3])
if($values[2] ne $values[3]);
$sval .=sprintf(", %s-%s",$values[4],$values[5])
if($values[4] ne $values[5]);
return $sval;
}
</syntaxhighlight>

Oben gezeigtes Beispiel benötigt den Vaillant_Timer (von Prof. Peter Henning). Dieser Code muss in die 99_myUtils.pm gespeichert werden. Unter diesem {{Link2Forum|Topic=41064|Message=336911|LinkText=Link}} gibt es weiterreichende Informationen zu diesem Thema.

==GAEBUS==

GAEBUS ist ein Perl Modul welches es in FHEM ermöglicht sämtliche Daten des eBus bequem zu konfigurieren.
Das Protokoll ist ebenso wie bei ECMD Telnet, aber die Einrichtung unterscheidet sich sehr stark und wird von den meisten Anwendern einfacher empfunden. Allerdings ist im derzeitigen Entwicklungsstand der GAEBUS noch nicht so flexibel wie ECMD. Das betrifft vor allem die Datenfilterung und Datenformatierung.

Eine genaue Installations- und Einrichtungsanleitung kann aus diesem {{Link2Forum|Topic=46098|Message=381580|LinkText=Forums-Thread}} entnommen werden.

Den Diskussionsthread des Autors findet man {{Link2Forum|Topic=41064|Message=332654|LinkText=hier}}.

==FHEM Tablet UI (FTUI)==

Die [http://forum.fhem.de/index.php/board,71.0.html Tablet-UI] ist ein ansprechendes HTML Frontend welches durch intensive Betreuung des Autors sehr gepflegt wird. Mit sogenannten Widgets kann hier auch für ungeübte schnell ein optisch ansprechendes Ergebnis erzielt werden. Die Tablet-UI stellt mit ihren Widgets direkt die Verbindung zu den Readings in FHEM her. Alle Messwerte die hier dargestellt werden sollen, müssen daher vorher in FHEM bereits definiert werden.

[[Datei:EBUSD_FTUI.png|thumb|left|alt=eBus Platine]]
<div style="clear:both;"></div>

Der komplette Demo-Code der abgebildeten Seite kann hier downgeloadet werden: {{Link2Forum|Topic=46098|Message=383071|LinkText=Tablet-UI}}

=Tipps & Tricks=

==eBusd Bedeutung der Telegramme==

Der ebusd wird entweder über ''ebusctl'' oder über ''telnet'' durch Klartextkommandos abgefragt, die lauten z.B. ''read -c broadcast outsidetemp''.
*In CSV-Dateien in /etc/ebusd wird festgelegt, in welche bzw. aus welcher binären Folge ein Kommando übersetzt wird. Konkret handelt es sich z.B. bei ''read -c broadcast outsidetemp'' um die Außentemperatur, die im Heizungssystem zyklisch als Broadcast gesendet wird und vom ebusd einfach mitgelesen wird.
*Für unterschiedliche Heizungssysteme werden unterschiedliche CSV-Dateien benötigt.
Für die Übersetzung der binären Daten in den Klartext ist es notwendig die entsprechenden Konfigurationsdateien(CSV-Files) zu installieren.
Den aktuellen Stand dieser Dateien findet ihr im [https://github.com/john30/ebusd-configuration/releases GIT von John].

Desweiteren kann der eBusd gestartet werden, und zwar mit den Optionen -f (läuft im Vordergrund) und --loglevel debug (alles wird geloggt). Diese Optionen produzieren Unmengen an Daten und damit werden auch alle empfangenen Telegramme protokolliert, z.B.
10feb5160301f00d44
Hierin bedeutet
{|
|Byte
|Bedeutung
|hier
|-
|0x10
|Adresse des Senders
|Zentrale
|-
|0xfe
|Adresse des Empfängers
|Alle Geräte
|-
|0xb5
|Herstellercode
|Vaillant
|-
|0x16
|Klasse des Kommandos
|Broadcast
|-
|0x03
|Anzahl Datenbytes
|3
|-
|0x01
|Bedeutung des Wertes
|outsidetemp = Außentemperatur
|-
|0xf0
|LSB des Wertes
|240
|-
|0x0d
|MSB des Wertes
|12
|-
|0x44
|CRC
|
|}
Damit ergibt sich in diesem Falle eine Außentemperatur von (12*256 + 240)/256 = 12,9375 Grad Celsius. In der zugehörigen CSV-Datei wird dem ebusd diese Übersetzung mitgeteilt durch eine Zeile der Form
u,broadcast,outsidetemp,Außentemperatur,,FE,B516,01,temp2,m,D2B,,°C,Temperatur
Diese CSV-Dateien können z.B. mit OpenOffice aus einem Spreadsheet generiert werden, indem dieses als CSV-Datei mit Separator "," gespeichert wird.
*Bei einem vollkommen unbekannten Heizungssystem sollte man den Hersteller fragen, welche Codes er verwendet
*Für Vaillant- und Wolf- Heizungssysteme liegen in dem oben genannten Verzeichnis ein paar Beispiele vor, die man als Ausgangspunkt nehmen kann.

==Serieller Konverter==

[[Datei:EBUS_RS232_Konverter.png|thumb|left|alt=eBus Platine]]
Es hat sich als nicht praktikabel erwiesen, den eBus mit einem Pegelwandler direkt an den seriellen GPIO-Port des Raspberry Pi anzuschließen. Die ständig einlaufenden Synchronisationssignale auf dem eBus, sowie die interne Verarbeitung der GPIO-Signale im Raspberry führen zu einer intolerablen Latenz, d.h., die eBus-Signale kommen verspätet bei der Software eBusd an (bis zu 90 Minuten wurden beobachtet). Stattdessen sollte grundsätzlich ein Seriell-USB-Konverter verwendet werden und der Raspberry Pi über einen USB-Port mit dem eBus verbunden werden.
<div style="clear:both;"></div>

==USB Device und Port unter Linux ermitteln==

Die einfachste Art den USB Device zu ermitteln erfolgt direkt am Raspberry Pi mit dem Befehl "lsusb".

pi@raspberry2 ~ $ lsusb
Bus 001 Device 002: ID 0424:9514 Standard Microsystems Corp.
Bus 001 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub
Bus 001 Device 003: ID 0424:ec00 Standard Microsystems Corp.
Bus 001 Device 004: ID 0403:6001 Future Technology Devices International, Ltd FT232 USB-Serial (UART) IC

in diesem Beispiel ist das der Device 004, dieser FT232 lauscht am eBus und ist mit dem eBus-Konverter verbunden.

Der USB Port kann mit der folgenden Kommandozeile ermittelt werden:
sudo dmesg | grep -i tty
Die Ausgabe sieht wie folgt aus:
[553999.530995] usb 1-1.3: FTDI USB Serial Device converter now attached to '''ttyUSB0'''

==eBusd==
===Prüfen der eBusd Konfigurationsdateien===
Mit dem Parameter "'''--checkconfig --scanconfig'''" kann die Installation der benutzten CSV Dateien am Raspberyy Pi überprüft werden. Vor allem wird hier angezeigt wieviele Messages übersetzt werden.

<syntaxhighlight lang="php">
pi@raspberry2 ~ $ ebusd --checkconfig --scanconfig
2016-01-22 17:14:12.619 [main notice] Performing configuration check...
2016-01-22 17:14:19.336 [main notice] found messages: 4440 (416 conditional on 89 conditions, 2 poll, 64 update)

pi@raspberry2 ~ $ ebusctl info
version: ebusd 2.0.0ea7efc
signal: acquired
symbol rate: 24
masters: 3
messages: 426
address 03: master #3
address 08: slave #3, scanned "MF=Vaillant;ID=BAI00;SW=0518;HW=7401", loaded "vaillant/08.bai.HW7401.csv"
address 10: master #6
address 15: slave #6, scanned "MF=Vaillant;ID=43000;SW=0215;HW=2002", loaded "vaillant/15.430.csv"
</syntaxhighlight>

Info hingegen zeigt genau welche CSV Dateien geladen worden sind und ihre Soft- und Hardewareversion.

===Bedeutung von "unknown MS" in der eBusd Logdatei===
Der Autor des eBus Dämons ist ständig bemüht die Geräte der unterschiedlichen Hersteller alle zu erfassen und so die Konfigurationsdateien zu ergänzen. Je nach Hard- und Softwarekonfiguration können Broadcast Meldungen vom eBus kommen die in der _broadcast.csv noch nicht übersetzt werden.

<syntaxhighlight lang="php">
2015-12-30 21:48:57.662 [update notice] unknown MS cmd: 1008b5110101 / 09404210004a620000ff
2015-12-30 21:48:59.670 [update notice] unknown BC cmd: 10feb516080001492130120315
2015-12-30 21:48:59.923 [update notice] unknown MS cmd: 1008b512020064 / 00
2015-12-30 21:49:01.711 [update notice] unknown MS cmd: 1008b5100900003c7affff00ff00 / 0101
</syntaxhighlight>

Diese Meldungen haben in der Regel für den weiteren Verlauf der Kommunikation über den eBus keinen Einfluß und ist keine Fehlfunktion der Schaltung oder Platine!

===Bedeutung von "signal lost"===

<syntaxhighlight lang="php">
pi@raspberrypi /etc/init.d $ sudo ebusd -f -c /tmp --logareas bus --loglevel info -d /dev/ttyUSB0
2016-01-18 22:38:56.348 [bus notice] signal acquired
2016-01-18 22:38:56.477 [bus notice] new master 10, master count 2
2016-01-18 22:38:56.481 [bus notice] new master 3f, master count 3
2016-01-18 22:39:02.051 [bus error] signal lost
</syntaxhighlight>

Bei dieser Meldung verliert der USB Konverter nach 20-Sekunden die Verbindung zum Raspberry Pi und produziert dann den Logeintrag.
{{Link2Forum|Topic=46098|Message=394313|LinkText=Lösungvorschlag}}

===ERR: unable to load===

2016-01-17 19:04:03.961 [main error] unable to load scan config 08: no file from /etc/ebusd/vaillant with prefix 08. matches ID "bai00", SW0604, HW5502

Ebusd wird gestartet, findet aber ein Konfigurations File (CSV) nicht.

Die eBusd Konfigurationsdateien könne nach [[#eBusd Konfigurationsdateien (CSV-Files)|diesem]] Vorgehen installiert werden.
Die Konfigurationsdateien aus dem Git neu laden und installieren.
{{Link2Forum|Topic=46098|Message=394270|LinkText=Lösungvorschlag}}

===ERR: duplicate Entry===

===ERR: End of input reached===

Die CSV Dateien wurden [http://forum.fhem.de/index.php/topic,46098.msg383450/topicseen.html#msg383450 fehlerhaft installiert] oder sind defekt!
Eine Neuinstallation dieser Dateien ist erforderlich!

Error reading "/etc/ebusd/vaillant/05.vd3.csv" line 1 field 1 value "05.vd4.csv": ERR: end of input reached
Erroneous item is here:
05.vd4.csv
^
Error reading "/etc/ebusd/vaillant/15.hep.csv" line 1 field 1 value "15.sdr_p.csv": ERR: end of input reached
Erroneous item is here:
15.sdr_p.csv
^

===BUS ERR send to 15===
<syntaxhighlight lang="php">
2016-01-16 19:20:28.575 [bus notice] new master 03, master count 4
2016-01-16 19:20:28.575 [update notice] unknown MS cmd: 1008b513020508 / 00
2016-01-16 19:20:29.413 [update notice] unknown MS cmd: 100ab504010d / 054201008037
2016-01-16 19:20:32.398 [bus error] send to 08: ERR: read timeout, retry
2016-01-16 19:20:33.005 [bus error] send to 08: ERR: read timeout, retry
2016-01-16 19:20:33.613 [bus error] send to 08: ERR: read timeout, retry
2016-01-16 19:20:34.859 [bus error] send to 08: ERR: read timeout
2016-01-16 19:20:34.859 [main error] scan config 08 message: ERR: read timeout
2016-01-16 19:20:37.017 [main notice] read common config file /etc/ebusd/vaillant/scan.csv
2016-01-16 19:20:37.019 [main notice] read common config file /etc/ebusd/vaillant/broadcast.csv
</syntaxhighlight>

Diese Fehlermeldung (read timeout) kann verschiedene Ursachen haben, meist liegt der Fehler in einer fehlerhaften Verkabelung.
{{Link2Forum|Topic=46098|Message=393547|LinkText=Lösungsvorschlag}}

=Systemarchitektur / Systemdesign=
Es muss sich jeder vorher überlegen, ob man für den eBus einen eigenen Rechner Raspberry Pi nimmt, oder auf der bestehenden FHEM Installation laufen lassen will. Eine Trennung bietet mehrere Vorteile die dann speziell im Testbetrieb den normalen Smart-Home Betrieb nicht beinflussen.
[[Datei:EBUS_Konfiguration.png|thumb|left|alt=eBus Konfiguration]]
Hier eine Konfiguration von FHEM und das Zusammenspiel mit eBusd via ECMD. Das soll aber jeder so handhaben wie es am Besten in das eigene Konzept passt.
<div style="clear:both;"></div>

=Werkzeuge / Tools=

==PSPad==
[http://www.pspad.com/de/ Pspad] ist ein besonders auf Programmierer zugeschnittener unicode-fähiger Editor für Microsoft Windows, welcher in der Lage ist auch per FTP die Dateien direkt zu editieren und zu schreiben ohne den Umweg sie vorher kopieren zu müssen! Besonders wichtig ist neben einem Syntaxhighlighter das er Linuxkonform ist und die Steuerzeichen am Zeilenende richtig interpretiert.

Hier zwei wichtige Infos zur Einrichtung des PSPad.

[[Datei:EBUS_PSPad_FTP.png|thumb|left|alt=eBus Platine]]

Im Tab "'''FTP'''" unten mit der rechten Maustaste auf die weiße Fläche klicken und in dem neu geöffneten Fenster "FTP verbinden" wählen.

[[Datei:EBUS_PSPad_FTP2.png|thumb|left|alt=eBus Platine]]
Es öffnet sich ein Fenster mit den Verbindungsdaten des FTP Servers. Nicht vergessen, das unten markierte Häckchen "'''Verbindung halten''' ..." zu markieren. Es wird dann alle 60 Sekunden ein NOOP Signal gesendet und die Verbindung wird nach einem Timeout nicht jedes Mal beendet.
<div style="clear:both;"></div>

==Filezilla==
Ebenso wie PSPad wird es für viele Arbeiten am Raspberry und eBusd eine Erleichterung sein manche Dateien direkt zu kopieren oder am PC zu sichern.
[https://filezilla-project.org/ Filezilla] beherrscht ebenfalls das '''FTP Protokoll''' und speichert die Verbindungsdaten in einem Profil.

[[Datei:EBUS_Filezilla_FTP.png|thumb|left|alt=eBus Platine]]
Links oben öffnet man den Servermanager und wählt (links unten) "neuer Server". Man gibt die Verbindungsdaten des Raspberry ein und drückt "speichern". Das Verbindungs Profil steht nun im Servermanager als "Raspberry" zur Verfügung und die Verbindung kann nun mit einem Doppelklick geöffnet werden. Dateien können nun durch einfaches Drag & Drop zwischen linken (lokales Laufwerk am PC) und rechten Dateifenster (in diesem Fall Raspberry) bequem kopiert werden.
<div style="clear:both;"></div>

==Putty==
[http://www.chiark.greenend.org.uk/~sgtatham/putty/download.html PuTTY] ist ein SSH Client welcher neben Secure Shell auch Telnet, Remote login und eine serielle Schnittstelle enthält. Als Tipp sei hier erwähnt, dass hier einige sehr nützliche Features zur Verfügung stehen:

* '''rechte Maustaste''' = Zwischenablage wird ins Terminalfenster kopiert
* '''Text mit Maus markieren''' = in Zwischenablage kopieren
* '''Pfeiltasten Auf/Ab''' = die letzten Befehle wiederholen, durch die Liste steppen

[[Datei:EBUS_Putty.png|thumb|left|alt=eBus Platine]]
Ebenso können mit Putty mehrere Terminalfenster parallel geöffnet werden. Diese Methode ist bei der Kalibrierung des Potis im Raw-Modus sehr von Vorteil.
<div style="clear:both;"></div>

=Weiterführende Links=
Diskussionsthread aus dem Forum:
*{{Link2Forum|Topic=46098|LinkText=eBus Schaltung in Betrieb nehmen!}}
*{{Link2Forum|Topic=29737|LinkText=Läuft: Heizung mit eBus-Schnittstelle}}

[[Kategorie:Other Components]]
[[Kategorie:Heizungssteuerung]]
[[Kategorie:Interfaces]]

Wetter und Wettervorhersagen

2017-08-17T17:39:31Z

Mahowi: Upload eigener Wetterdaten mit WUup

Wetterdaten und Wettervorhersagen können auf verschiedene Weise in FHEM eingebunden werden.

== Yahoo-Wetter ==
Für die einfache Einbindung des Yahoo-Wetters gibt es das spezielle Modul [[Weather]].

== Unwetterzentrale ==
Informationen der Seite(n) Unwetterzentrale.de können mit Hilfe des Moduls [[UWZ]] eingebunden werden.

== Modul OPENWEATHER ==
Das Modul [[OPENWEATHER]] extrahiert Wetterdaten über die "openweather"-Schnittstelle (API) von www.wetter.com.
*Vorschau-Zeitraum: 3 Tage
*Vorschau-Interval: 6:00, 11:00, 17:00, 23:00
*Aktuelle Daten: keine

== Modul PROPLANTA ==
Das Modul [[PROPLANTA]] extrahiert Wetterdaten von der Website www.proplanta.de. (keine API)
*Vorschau-Zeitraum: 12 Tage
*Vorschau-Interval: 3 h
*Aktuelle Daten: jede volle Stunde

== Modul WWO ==
Das Modul extrahiert Wetterdaten über die (alte) API von worldweatheronline.com
*Vorschau-Zeitraum: ?? Tage<BR>
*Vorschau-Interval: ??<br>
*Aktuelle Daten: ??

== Wetterwarnungen des DWD ==
{{Randnotiz|RNTyp=y|RNText=Die Nutzung der Vorhersagedaten wurde vom DWD verändert und ist momentan nicht wie hier beschrieben möglich. Eine Alternative bietet das Modul [[UWZ]]!}}
Der Deutsche Wetterdienst [http://www.dwd.de DWD] stellt neben diversen Wetterdaten auch Wetterwarnungen bereit. Diese können sehr einfach via [http://fhem.de/commandref_DE.html#weblink weblink iframe] in FHEM eingebunden werden - das ist zwar nicht die schönste Form, aber die schnellste.

Dazu sucht man sich zuerst auf der [http://www.dwd.de/bvbw/appmanager/bvbw/dwdwwwDesktop?_nfpb=true&_pageLabel=_dwdwww_wetter_warnungen_warnungen&T92053gsbDocumentPath=BEA__Navigation%2FWetter__Warnungen%2FWarnungen.html%3F__nnn%3Dtrue&lastPageLabel=dwdwww_wetter_warnungen Warnungsseite des DWD] die eigene Region heraus (in der Karte durchklicken). Die gewünschte URL für Berlin Stadt ist z.B. <code>http://www.dwd.de/dyn/app/ws/html/reports/BXX_warning_de.html#WS_ANCHOR_0</code>. Das Anhängsel <code>#WS_ANCHOR_0</code> kann man in der Konfiguration auch weglassen.

Die Einbindung in FHEM sieht dann wie folgt aus:
<pre>
define dwd_warnmeldung weblink iframe http://www.dwd.de/dyn/app/ws/html/reports/BXX_warning_de.html
attr dwd_warnmeldung group Wetterwarnungen (DWD)
attr dwd_warnmeldung htmlattr width="100%" height="300" frameborder="0" marginheight="0" marginwidth="0"
attr dwd_warnmeldung room Wettervorhersage,Startseite
</pre>

== Vorhersage-Diagramm von YR ==
[http://www.yr.no YR] ist die Seite des norwegischen Wetterdiensts. Er ist zwar nur in Teilen auf Englisch (und gar nicht auf Deutsch) verfügbar, bietet aber sehr gute Wettervorhersagen - auch mit eigenen Vorhersagen für kleine Dörfer. Neben etlichen Detailinfos bietet YR eine sehr schicke 48h-Vorhersage-Grafik. Diese kann sehr einfach via [http://fhem.de/commandref_DE.html#weblink weblink iframe] in FHEM eingebunden werden.

Dazu geht man auf die [http://www.yr.no Startseite von YR] und gibt in das Suchfeld den Namen seines Dörfchens ein - die Ergebnissliste kann ziemlich lang werden, sodass man evtl. sehr genau schauen muss, welches das eigene Kaff ist - bei mir war es an 29. Stelle... ;-) Auf der gewünschten Seite gibt es einen Unterpunkt "Hour by hour", wo sich die besagte Grafik findet. Hier kopiert man sich einfach die URL der Grafik.

Die Einbindung in FHEM sieht dann bspw. wie folgt aus:
<pre>
define Wetter_yr_Vorhersage weblink iframe http://www.yr.no/place/Germany/Berlin/Berlin/meteogram.png
attr Wetter_yr_Vorhersage group Wettervorhersage (yr)
attr Wetter_yr_Vorhersage htmlattr width="100%" height="300" frameborder="0" marginheight="0" marginwidth="0"
attr Wetter_yr_Vorhersage room Wettervorhersage,Start
</pre>

== Wetter von Weather Underground ==
{{Randnotiz|RNTyp=y|RNText=Neben dem hier vorgestellten Abruf der Weather Underground-Daten mit [[HTTPMOD]] kann auf Weather Underground-Daten auch mit dem darauf spezialisierten Modul [http://fhem.de/commandref.html#Wunderground Wunderground] zugegriffen werden.}}

'''Hinweis:''' Dieses Vorgehen ist etwas anspruchsvoller und somit eher für erfahrene FHEM-User geeignet.

[http://www.wunderground.com/ Weather Underground] ist bietet eine sehr umfassende Sammlung aller möglichen offiziellen und privaten (aber teils sehr professionellen) Wetterstationen weltweit. Es besteht eine recht hohe Wahrscheinlichkeit, dass es in der eigenen Umgebung schon eine Wetterstation gibt. Anstatt nun selbst eine komplette Wetterstation aufzubauen, kann man alternativ auf die Daten der Nachbarstation zugreifen.

Dazu sind grundsätzlich die folgenden Schritte notwendig:
* Finden der geeigneten Station
* Auswerten der XML-Daten
* Erstellen passender gplot-Dateien

=== Finden der geeigneten Station ===
Als erstes geht man auf die [http://www.wunderground.com Startseite von Weather Underground] und gibt in das Suchfeld den Namen seines Dörfchens oder der nächsten Stadt ein - für Berlin landet man bspw. auf Seite für "Berlin Alexanderplatz". Es gibt aber manchmal sehr viele Wetterstationen in der direkten Umgebung. Diese findet man indem am auf "Change Station" klickt und sich eine passende Station aussucht. Nähere Infos (zB. zur verwendeten Hard- und Software) zu der gewählten Wetterstation erhält man, wenn man auf den Namen der Station klickt und dann auf "About this PWS".

Weather Underground stellt die Daten der Wetterstation auch über eine API als XML bereit, die wir auswerten können. Die entsprechende URL findet sich ebenfalls unter "About this PWS" unter "Download current conditions XML". Für Berlin Prenzlauer Berg wäre dies bspw.
<code>http://api.wunderground.com/weatherstation/WXDailyHistory.asp?ID=IBERLIN15&format=XML</code>.

Entscheidend für die jeweilige Station ist der Teil nach "?=ID", also in diesem Fall "IBERLIN15". Dieser Teil des Links lässt sich leicht durch die ID einer anderen Station ersetzen und die Suche nach dem entsprechenden Link auf der Seite der Station bleibt erspart.

=== Auswerten der XML-Daten ===
Die Auswertung der XML-Daten erfolgt via [[HTTPMOD]]. Da dies nicht ganz trivial ist, sind im Folgenden zuerst die wesentlichen Konfigurationsschritte exemplarisch beschrieben. Weiter unten findet sich dann die fertige vollständige Konfiguration.

Es erstes wird das Device HTTPMOD definiert (die 600 am Schluss ist der Aktualisierungszyklus in Sekunden, also alle 10 min):
:<code>define wetter_prenzelberg HTTPMOD http://api.wunderground.com/weatherstation/WXCurrentObXML.asp?ID=IBERLIN15 600 </code>

Dann werden Attribute für alle Readings definiert:
:<code>attr wetter_prenzelberg userattr readingsName_cloudiness readingsName_date ... </code>

Dann wird jedem Attribut ein Name zugewiesen (unter diesem Namen wird der Wert ins Log geschrieben):
:<code>attr wetter_prenzelberg readingsName_cloudiness cloudiness </code>

Zum Schluss wird das Reading selbst definiert:
:<code>attr wetter_prenzelberg readingsRegex_cloudiness cloudiness id="NN" percent="([\d\.]+) </code>

Die gesamte Konfiguration für alle von der API angebotenen Wetterwerte sieht dann wie folgt aus:
<pre>
define wetter_prenzelberg HTTPMOD http://api.wunderground.com/weatherstation/WXCurrentObXML.asp?ID=IBERLIN15 600
attr wetter_prenzelberg userattr readingsName_cloudiness readingsName_date readingsName_dewpointTemperature readingsName_fog readingsName_heatindex readingsName_humidity readingsName_pressure readingsName_solarRadiation readingsName_solarUV readingsName_temperature readingsName_time readingsName_windChill readingsName_windDegrees readingsName_windDirection readingsName_windGust readingsName_windSpeed readingsRegex_cloudiness readingsRegex_date readingsRegex_dewpointTemperature readingsRegex_fog readingsRegex_heatindex readingsRegex_humidity readingsRegex_pressure readingsRegex_solarRadiation readingsRegex_solarUV readingsRegex_temperature readingsRegex_time readingsRegex_windChill readingsRegex_windDegrees readingsRegex_windDirection readingsRegex_windGust readingsRegex_windSpeed
attr wetter_prenzelberg readingsName_cloudiness cloudiness
attr wetter_prenzelberg readingsName_date date
attr wetter_prenzelberg readingsName_dewpointTemperature dewpointTemperature
attr wetter_prenzelberg readingsName_fog fog
attr wetter_prenzelberg readingsName_heatindex heatindex
attr wetter_prenzelberg readingsName_humidity humidity
attr wetter_prenzelberg readingsName_pressure pressure
attr wetter_prenzelberg readingsName_solarRadiation solarRadiation
attr wetter_prenzelberg readingsName_solarUV solarUV
attr wetter_prenzelberg readingsName_temperature temperature
attr wetter_prenzelberg readingsName_time time
attr wetter_prenzelberg readingsName_windChill windChill
attr wetter_prenzelberg readingsName_windDegrees windDegrees
attr wetter_prenzelberg readingsName_windDirection windDirection
attr wetter_prenzelberg readingsName_windGust windGust
attr wetter_prenzelberg readingsName_windSpeed windSpeed
attr wetter_prenzelberg readingsRegex_cloudiness cloudiness id="NN" percent="([\d\.]+)
attr wetter_prenzelberg readingsRegex_date date date" content="([\d\.]+)
attr wetter_prenzelberg readingsRegex_dewpointTemperature <dewpoint_c>(\+|-?[\d\.]+)
attr wetter_prenzelberg readingsRegex_fog fog id="FOG" percent="([\d\.]+)
attr wetter_prenzelberg readingsRegex_heatindex <heat_index_c>(\+|-?[\d\.]+)
attr wetter_prenzelberg readingsRegex_humidity <relative_humidity>([\d\.]+)
attr wetter_prenzelberg readingsRegex_pressure <pressure_mb>([\d\.]+)
attr wetter_prenzelberg readingsRegex_solarRadiation <solar_radiation>([\d\.]+)
attr wetter_prenzelberg readingsRegex_solarUV <UV>([\d\.]+)
attr wetter_prenzelberg readingsRegex_temperature <temp_c>(\+|-?[\d\.]+)
attr wetter_prenzelberg readingsRegex_time time Zeit([\d\:]+)
attr wetter_prenzelberg readingsRegex_windChill <windchill_c>(\+|-?[\d\.]+)
attr wetter_prenzelberg readingsRegex_windDegrees <wind_degrees>([\d\.]+)
attr wetter_prenzelberg readingsRegex_windDirection <wind_dir>([\d\.]+)
attr wetter_prenzelberg readingsRegex_windGust <wind_gust_mph>([\d\.]+)
attr wetter_prenzelberg readingsRegex_windSpeed <wind_mph>([\d\.]+)
</pre>
Hinweis: Nicht immer werden alle Werte geliefert (wenn keine Sonne, dann kein UV-Wert...). Im System-Log kann das als Fehler auftauchen, ist aber kein Problem.

=== Erstellen passender gplot-Dateien ===
Um die ausgelesenen Werte als Graphen darstellen zu können müssen eigene gplot-Dateien erstellt werden. Eine grundsätzliche Anleitung dazu findet sich unter [[Creating Plots]]. Deshalb sollen hier nur Beispiele für die eigentlichen gplot-Dateien vorgestellt werden. Beispiele sollten sowohl für [[FileLog]] wie [[DbLog]] funktionieren.

Temperatur und Luftfeuchte:
<pre>
set terminal png transparent size <SIZE> crop
set output '<OUT>.png'
set xdata time
set timefmt "%Y-%m-%d_%H:%M:%S"
set xlabel " "
#set title '<L1>'
set title ''
set ytics
set y2tics
set grid ytics
set ylabel "Temperature in C"
set y2label "Humidity (%)"

#FileLog 4:temperature\x3a::
#FileLog 4:windChill\x3a::
#FileLog 4:humidity\x3a::

#DbLog <SPEC1>:temperature::
#DbLog <SPEC1>:windChill::
#DbLog <SPEC1>:humidity::

plot "<IN>" using 1:2 axes x1y1 title 'Temperatur (C)' ls l0 lw 1.5 with lines,\
"<IN>" using 1:2 axes x1y1 title 'Gefühlte Temperatur (C)' ls l1 lw 1.5 with lines,\
"<IN>" using 1:2 axes x1y2 title 'Luftfeuchtigkeit (%)' ls l2fill lw 0.2 with lines
</pre>

Wind und Windrichtung:
<pre>
set terminal png transparent size <SIZE> crop

set output '<OUT>.png'
set xdata time
set timefmt "%Y-%m-%d_%H:%M:%S"
set xlabel " "

set ytics
set y2tics ("Nord" 0, "Ost" 80, "Süd" 180, "West" 270, "Nord" 360)

#set title '<L1>'
set title ''

set grid xtics ytics

set yrange [0:20]
set y2range [0:360]

set ylabel "Wind (mph)"
set y2label "Richtung"

#FileLog 4:windSpeed:0:
#FileLog 4:windGust:0:
#FileLog 4:windDegrees:0:

#DbLog <SPEC1>:windSpeed::
#DbLog <SPEC1>:windGust::
#DbLog <SPEC1>:windDegrees::

plot "<IN>" using 1:2 axes x1y1 title 'Wind (mph)' ls l0 lw 1.5 with lines,\
"<IN>" using 1:2 axes x1y1 title 'Böen (mph)' ls l1 lw 1.5 with lines,\
"<IN>" using 1:2 axes x1y2 title 'Windrichtung (°)' ls l2fill lw 0.2 with points
</pre>

Sonnenintensität und UV-Werte:
<pre>
set terminal png transparent size <SIZE> crop

set output '<OUT>.png'
set xdata time
set timefmt "%Y-%m-%d_%H:%M:%S"
set xlabel " "

set ytics
set y2tics

#set title '<L1>'
set title ''

set grid xtics ytics

set ylabel "Sonnenstrahlung (W/qm)"
set y2label "UV"

#FileLog 4:solarRadiation:0:
#FileLog 4:solarUV:0:

#DbLog <SPEC1>:solarRadiation::
#DbLog <SPEC1>:solarUV::

plot "<IN>" using 1:2 axes x1y1 title 'Strahlung' ls l0 lw 1.5 with lines,\
"<IN>" using 1:2 axes x1y1 title 'UV' ls l1 lw 1.5 with lines
</pre>

'''Weitere TBD'''

=== Vergangene Daten abfragen ===
Ein konkretes vergangenes Datum der Wetterstation kann man übrigens auch abrufen - für den 28.11.2014 wäre dies bspw.
<code>http://www.wunderground.com/weatherstation/WXDailyHistory.asp?ID=IBERLIN15&day=28&month=11&year=2014&graphspan=day&format=1</code>.

=== Eigene Wetterdaten hochladen ===
{{Randnotiz|RNTyp=g|RNText=Unterstützung für das Modul gibt es im dazugehörigen {{Link2Forum|Topic=65587|LinkText=Forumsthread }}.}}

Wer eigene Wetterdaten hochladen will, kann hierzu das Modul [http://fhem.de/commandref.html#WUup WUup] verwenden. Dazu benötigt man die Zugangsdaten (stationID und Paßwort) für eine eigene Wetterstation. Mit dem Modul können die meisten vom [http://wiki.wunderground.com/index.php/PWS_-_Upload_Protocol PWS Upload Protocol] unterstützten Daten hochgeladen werden:
* Winddir - [0-360 momentane Windrichtung]
* Windspeedmph - [mph momentane Windgeschwindigkeit]
* Windgustmph - [mph aktuellen Böe, mit Software-spezifischem Zeitraum]
* Windgustdir - [0-360 mit Software-spezifischer Zeit]
* Windspdmph_avg2m - [mph durchschnittliche Windgeschwindigkeit innerhalb 2 Minuten]
* Winddir_avg2m - [0-360 durchschnittliche Windrichtung innerhalb 2 Minuten]
* Windgustmph_10m - [mph Böen der vergangenen 10 Minuten]
* Windgustdir_10m - [0-360 Richtung der Böen der letzten 10 Minuten]
* Feuchtigkeit - [% Außenfeuchtigkeit 0-100%]
* Dewptf- [F Taupunkt im Freien]
* Tempf - [F Außentemperatur]
* Rainin - [in Regen in der vergangenen Stunde]
* Dailyrainin - [in Regenmenge bisher heute]
* Baromin - [inHg barometrischer Druck]
* Soiltempf - [F Bodentemperatur]
* Bodenfeuchtigkeit - [%]
* Solarradiation - [W/m²]
* UV - [Index]

Die Werte werden im Modul für Wunderground ins anglo-amerikanische System umgerechnet. Temperaturen werden also automatisch von °Celsius in Fahrenheit, Windgeschwindigkeiten von km/h in mph, mm in Inch und der barometrische Druck von hPa in inHg umgerechnet.

== Wetternetzwerk auf wetter.com ==
Ein vollständiges Beispiel zur Nutzung der Informationen über die Regenmenge (Station 1445, Weinheim) von wetter.com ist in {{Link2Forum|Topic=39600|Message=332837|LinkText=diesem Forenbeitrag}} beschrieben.

== Wetter von netatmo ==
Das FHEM-Modul [[netatmo]] ermöglicht den Datenimport von privaten und öffentlichen netatmo Wetterstationen. Eine Übersicht über die verfügbaren öffentlichen Stationen findet sich auf der Seite [http://www.netatmo.com/de-DE/weathermap Weathermap]. Die meisten öffentlichen Stationen liefern Temperatur, Luftfeuchte und Luftdruck, einige auch Wind, Regen und Daten zur Luftqualität (CO<sub>2</sub>).

== Links ==
* {{Link2Forum|Topic=33610}} mit Sammlung und Beipielen von Internet-Links für die Anzeige von teilweise animierten Wetterbildern
* [http://bloglich.de/art/rpi/wetterdaten-auf-dem-raspberry-pi-in-fhem/ Beispiel in Blog(de)]
* [[HTTPMOD]]
* [[GDS|Modul GDS]] zum Auslesen von DWD-Daten

[[Kategorie:Code Snippets]]
[[Kategorie:HOWTOS]]
[[Kategorie:Wetterstationen]]

Raspberry Pi & HTTPS

2017-04-18T06:43:26Z

Mahowi: Links auf "Raspberry Pi" und "FHEMWEB" gesetzt

Dieser Artikel beschreibt das Vorgehen unter '''Linux'''. Um unter '''Windows''' ein SSL Zertifikat zu erstellen hilft eine Bat Datei aus dem FHEM Users Forum: [https://groups.google.com/d/msg/fhem-users/uYNhSombpFw/UsRA9gmkKaEJ https://groups.google.com/d/msg/fhem-users/uYNhSombpFw/UsRA9gmkKaEJ]

Damit das Kennwort verschlüsselt übertragen wird, ist eine HTTPS Verbindung wichtig.

Die folgenden Schritte sind direkt auf dem [[Raspberry Pi|Raspberry]] oder über ein Terminal auszuführen.
Zunächst müssen folgende Pakete nachinstalliert werden:

<nowiki>sudo apt-get update
sudo apt-get install libio-socket-ssl-perl
sudo apt-get install libwww-perl</nowiki>

Anschließend muss noch im fhem-Verzeichnis (befindet sich in der Regel unter /opt) das Verzeichnis "certs" für die Zertifikate erstellt werden. Dies geht wie folgt:

<nowiki>cd /opt/fhem
sudo mkdir certs</nowiki>

In dieses Verzeichnis kommen zwei Dateien die mithilfe von OpenSSL erstellt werden: server-key.pem und server-cert.pem. Dazu wechselt man in das neu erstellte Verzeichnis. Auf der Konsole ist nun folgendes auszuführen:

<nowiki>cd /opt/fhem/certs
sudo openssl req -new -x509 -nodes -out server-cert.pem -days 3650 -keyout server-key.pem</nowiki>

Damit das SSL-Modul die erzeugten Dateien verwenden kann, muss das certs-Verzeichnis Ausführrechte haben (es ist auch kein Fehler, wenn die Dateien selbst nur die nötigsten Rechte haben). Die Berechtigungen werden wie folgt gesetzt

<nowiki>sudo chmod 644 /opt/fhem/certs/*.pem
sudo chmod 711 /opt/fhem/certs
</nowiki>

Das war auch schon alles, was man auf dem Raspberry Pi über die Konsole tun muss. Als nächstes öffnen wir FHEM im Browser. Hier müssen wir nun die Web Instanz suchen welche wir auf HTTPS umstellen möchten. In der Regel ist diese Instanz als WEB angelegt. Evtl. hab ihr mehrere Webinstanzen (z.B. WEBphone, WEBtablet) oder hab das Define anders benannt, dann müsst Ihr die folgenden Angaben entsprechend ändern.

Wechselt in [[FHEMWEB]] in die Detailansicht des Define WEB (die URL lautet z.B. http://fhem:8083/fhem?detail=WEB). Dort setzt Ihr nun das folgende Attribut

<nowiki>attr WEB HTTPS</nowiki>

Damit ist HTTPS aktiviert. Nicht vergessen, die Konfiguration zu speichern, denn erst nach einem Neustart erfolgt der Zugriff per HTTPS über [https://192.168.n.n:8083/fhem https://192.168.n.n:8083/fhem]. Es ist wichtig die Adresse mit https:// aufzurufen, da es keine automatische Weiterleitung von http auf https existiert.

[[Kategorie:HOWTOS]]

PDF Datei darstellen

2017-04-18T06:37:00Z

Mahowi: /* PDF Dateien unter FHEM darstellen */ Link auf "weblink" gesetzt, damit die Seite keine Sackgasse mehr ist

= PDF Dateien unter FHEM darstellen =

Mit den folgenden Zeilen kann man eine PDF Datei durch definieren eines [[weblink|Weblink]] direkt in seiner FHEM Webseite darstellen. Der PDF
Reader wird in dem entsprechenden Frame des Computers geöffnet.

'''Für fhem.cfg'''
<nowiki>### Aufruf der FHEM Anfänger Anleitung via https
define FhemDoc weblink iframe https://fhem:8083/fhem/docs/fhem-floorplan-installation-guide_de.pdf
attr FhemDoc room Anleitung
attr FhemDoc htmlattr width="600" height="900" frameborder="0" marginheight="0" marginwidth="0"
</nowiki>

Mittels des "htmlattr" kann man die Größe des PDF-Viewers innerhalb der Webseite bestimmen.

Hierbei wird bei Anwahl des Menüpunkt "Fhemdoc" innerhalb des gleichen Frames ein PDF Reader geöffnet und
dieser zeigt dann die entsprechende PDF Seite an.
== PC basierend ==
=== Linux ===
Das Darstellen oder Einbinden von Dokumentation ist auf linux PC ist generell einfach, da durch den Aufruf automatisch ein entsprechender Reader geladen wird. Unter Linux (kubuntu) wird automatisch okula geöffnet.
=== Windows/Mac ===
Auf einer Windows-Maschine oder Mac Maschine ist meist der Acrobat Reader installiert und sollte daher auch sofort arbeitet. Sollte die Darstellung nicht arbeiten, fehlt meistens das Acrobat Reader Plug-in des Internet Browsers.
== Android basierend ==
=== Standard Browser ===
Standardmäßig stellt der WEB Browser eines Android Handy's oder Tablet keine PDF Dateien dar. Die Datei wird automatisch gedownloaded und muss dann manuell mit einem PDF Reader geöffnet.
=== FireFox ===
Der Browser "FireFox" biete die Möglichkeit von Addons, die den Browser um weitere Funktionen erweitert.

Nachdem man im Google Play Store das Programm-Paket "Fire Fox" hinzugefügt hat und diesen nach seinen Wünschen konfiguiert hat, muss hier noch das Addon für "Fire Fox" namens "PDF Viewer" zu Firefox hinzugefügt werden.

;HInweis zum Browser FireFox
*Firefox scheint ein Problem mit dem "iFrame" Code zu haben, da ein entsprechender Code nicht auf der Webseite darstellt wird.
*Firefox ist generell nicht der schnellste Browser

; Nachteile der PDF Viewer Lösung
* Die Software wandelt die PDF Datei beim Öffnen der PDF-Datei diese in HTML5 um. Hierdurch ist die Darstellung der PDF Datei sehr langsam. Leider ist dies derzeit die einzige Lösung (Stand 12.2013), wie man in Webseiten eine PDF Datei unter Fire Fox darstellen kann.

=== Dolphin Browser ===
Infos fehlen noch
=== Boat Browser ===
Infos fehlen noch
=== Maxthon Browser ===
Infos fehlen noch
=== Opera Browser ===
Infos fehlen noch
=== UC Browser ===
Infos fehlen noch
=== Chrome Browser ===
Infos fehlen noch

[[Kategorie:HOWTOS]]

Bewegungsmelder: Status zurücksetzen

2017-04-18T06:27:41Z

Mahowi: Code: at wird über defmod definiert, daher keine Unterscheidung nötig, ob es schon definiert ist.

{{Randnotiz|RNText=Für HomeMatic ist dieser Codeschnipsel nicht mehr nötig. In der aktuellen Version des Moduls wird der Status automatisch aut ''noMotion'' zurückgesetzt.}}
Manche 'Bewegungsmelder (<strike>z.B. von [[HomeMatic Type motionDetector]]</strike>) haben den Nachteil, dass nach einer erkannten Bewegung zwar das Reading ''motion'' gesetzt, aber nicht mehr zurückgesetzt wird. Der folgende Codeschnipsel behebt das. Das Reading wird auf ''scanning'' zurückgesetzt und ein Event ausgelöst, auf das wiederum reagiert werden kann.

Folgender Code muss in die [[99_myUtils anlegen|99_myUtils.pm]] kopiert werden:
<source lang="perl">
sub BM_MotionHandling($$) {
my ( $device, $event ) = @_;
return if ( $attr{$device}{subType} ne "motionDetector" );

my $ResetAT = $device . "_Reset";
if ( $event eq "motion" ) {

# Bewegung erkannt, erstelle AT um Status wieder zurückzusetzen
fhem "defmod " . $ResetAT
. " at +00:05:00 {BM_MotionHandling(\"$device\", \"scanning\")}";
}
elsif ( $event eq "scanning" ) {

# Status des Devices wieder zurücksetzen
readingsSingleUpdate( $defs{$device}, "state", $event, 1 );
}
}</source>

Anschließend ist einmalig ein [[notify]] zu definieren. In diesem Beispiel wird davon ausgegangen, dass alle Bewegungsmelder mit "BM_" beginnen und bei Bewegung ein Reading mit dem Namen ''motion'' gesetzt wird. Anderenfalls muss die [[Regulärer Ausdruck|Regexp]] angepasst werden.
:<code>define NTFY_Reset_Motion notify (BM_.*:motion*) {BM_MotionHandling("$NAME", "motion")}</code>

[[Kategorie:Code Snippets]]

MapleCUX-Platinen

2017-04-03T13:11:40Z

Mahowi: Link für Bild korrigiert

{{Infobox Hardware|
|Bild=MapleCULx4.jpg
|Bildbeschreibung=MAPLE CUL (ohne LAN)
|HWProtocol=diverse
|HWType=Transceiver
|HWCategory=CUL
|HWComm=Funk 433MHz, 868MHz, optional 2,4GHz
|HWChannels=N/A
|HWVoltage=3,3V nach Spannungsregler
|HWPowerConsumption=
|HWPoweredBy=USB
|HWSize=
|HWDeviceFHEM=CUL
|HWManufacturer=Eigenbau
}}

== Einleitung ==

Der [https://wiki.fhem.de/wiki/MapleCUN MapleCUN ] ist neuartiges CUN oder CUL Interface zum Selbstbau, entwickelt von Telekatz.
Durch den STM32 Mikrocontroller ist die Basis sehr leistungsfähig. Der Controller ist deutlich schneller als ATMega und verfügt über mehr Flash und RAM sowie integriertes USB.
Es können 1-4 Transceiver verbaut werden. Durch fertige Platinen wird der Aufbaz erleichtert, sowie die Möglichkeiten erweitert.<br/>
<br/>

<gallery>
File:MapleCULx4.jpg|Prototypen-Aufbau mit Steck Tranceivern|alt=alt language
File:4-fach-1.3-1280.jpg|4-Fach CUL V1.3|alt=alt language
File:4-fach-1.3-LAN.jpg|4-Fach CUN mit LAN-Modul V1.3|alt=alt language
File:4-fach-produktiv.jpg|4-Fach CUL im offenen Gehäuse|alt=alt language
</gallery>

== Aufbau ==

Benötigt werden dazu folgende Teile:

* [https://de.aliexpress.com/item/leaflabs-Leaf-maple-mini-ARM-STM32-compatibility/32214664071.html Maple Mini Board]<br/>
* [https://de.aliexpress.com/item/CC1101-Wireless-Module-Long-Distance-Transmission-Antenna-868MHZ-M115/32635393463.html CC1101 Funkmodul]<br/>
* [https://de.aliexpress.com/item/Free-shipping-W5100-Ethernet-module-Ethernet-network-module-for-arduino/32341522510.html W5100] oder [https://de.aliexpress.com/item/Free-shipping-W5500-Ethernet-network-module-hardware-TCP-IP-51-STM32-microcontroller-program-over-W5100/32750316619.html W5500] Ethernet Modul (Optional)<br/>
Der Aufbau kann auf Lochraster erfolgen, fertige Platinen siehe Foto sparen jedoch Zeit, reduzieren Fehlerquellen und erhöhen die Zuverlässigkeit.

Die Module werden gemäß Schaltplan miteinander verbunden. Da alle Module mit 3,3V laufen sind keine Bauteile für eine Pegelanpassung notwendig.

== Bestückung der Module ==
Stand 01/2017: Es sind noch nicht alle Protokolle an den zusätzlichen Transceivern verfügbar.
SlowRF funktioniert nur an CC0 und CC1. Nach einem Reset der Konfiguration ist die Frequenz von CC0 auf 868MHz und CC1 auf 433MHz voreingestellt. Lässt sich dann aber auch umkonfigurieren.
KOPP und MBUS funktionieren nur an CC0.
Die restlichen Protokolle sind an allen Transceivern verfügbar.

== Zusätzliche Serielle Schnittstellen ==
Über USB werden zwei weitere Schnittstellen angelegt, der Netzwerkzugriff erfolgt über die Ports 2324 und 2325.<br/>

-Ein angeschlossener HM-MOD-UART kann in FHEM eingebunden werden. (5. Funkmodul)
-ein Arduino kann ein MySensors Gateway bilden
-ESP8266 ...
-RS485 ...
-1Wire

== Debugging ==

Output mit 4 Transceivern und LAN Modul:
-I- Getting new Started Project --
-I- MapleCUNx4
-I- Compiled: Mar 18 2017 15:46:32 --
-I- init Flash
-I- init Timer
-I- init EEprom
-I- init Ethernet
WIZCHIP Initialized success.
-I- Detected CC0: PN 0x00 VER 0x14
-I- Detected CC1: PN 0x00 VER 0x18
-I- Detected CC2: PN 0x00 VER 0x14
-I- Detected CC3: PN 0x00 VER 0x14
-I- Detected ethernet
-I- init USB
-I- init Complete

== Links ==
{{Link2Forum|Topic=https://forum.fhem.de/index.php/topic,60458.0.html |LinkText=Diskussion im Forum}}

[[Kategorie:Interfaces]]<br/>
[[Kategorie:CUL]]

ABFALL

2017-03-07T12:16:02Z

Mahowi: /* Voraussetzungen */

{{Infobox Modul
|ModPurpose=Filtern von (Abfall-)Terminen aus einem Calendar.
|ModType=x
|ModFTopic=48237
|ModForumArea=Codeschnipsel
|ModTechName=57_ABFALL.pm
|ModOwner=Constantin / {{Link2FU|14026|uniqueck}}
}}

[[ABFALL]] ist ein (inoffizielles, nicht Bestandteil der Distribution) Hilfsmodul, das bestimmte Termine aus einem bestehenden Kalender des Moduls [[Calendar]] in Readings übernimmt.

== Voraussetzungen ==
Es muss ein [[Calendar]]-Objekt definiert sein. Der dabei benutzte Name muss in der Definition des ABFALL-Objekts spezifiziert werden.
Es können auch mehrere Calendar Objekte übergeben werden.

Sonderzeichen aus dem Namen der Termine, werden entfernt um die Namen der generierten Readings FHEM tauglich zu machen, für die Werte der Readings bleiben diese allerdings erhalten.

== Anwendung ==
=== Installation ===
Mit folgendem Befehl kann das Modul direkt in den Standard FHEM Update Prozess eingeklinkt werden.
:<code>update add https://raw.githubusercontent.com/uniqueck/fhem-abfall/master/controls_fhemabfall.txt</code>
Um es nur zu installieren, kann auch einfach nur das Command
:<code>update all https://raw.githubusercontent.com/uniqueck/fhem-abfall/master/controls_fhemabfall.txt</code>
eingegeben werden.

=== Entwicklungsstrang ===
:<code>update add https://raw.githubusercontent.com/uniqueck/fhem-abfall/develop/controls_fhemabfall.txt</code>
bzw.
:<code>update all https://raw.githubusercontent.com/uniqueck/fhem-abfall/develop/controls_fhemabfall.txt</code>

=== Define ===
:<code>define <Name> ABFALL <calendarname>,<calendarname2>,...</code>

Erläuterung der Parameter im '''define''':
;<calendarname>
:Name des '''Calendar''' Kalenders

Beispiel:
:<code>define AbfallGoogleCalender Calendar ical url https://......</code>
:<code>define myABFALL ABFALL AbfallGoogleCalender</code>

=== Werte aktualisieren ===
Die Werte aktualisieren sich abhängig vom [[notify]] der entsprechenden Calendar Instanz, welche im define angegeben wurde(n).

=== Weitere Attribute ===

{| class="wikitable"
!Attribut
!Werteliste
!Beschreibung
!Default Wert
|-
!align="right" |calendarname_praefix
|0 und 1
|soll der Kalendername als praefix dem Reading vorangestellt werden, sollte bei nur einem Kalender auf 0 gesetzt werden
|1 - praefix wird vorangestellt
|-
!align="right" |abfall_clear_reading_regex
|
|regex zum Entfernen von Anteilen aus dem Termin, dieser wird vor dem Entfernen von Sonderzeichen aus den Namen der Termine angewandt.
|
|-
!align="right" |disable
|0 und 1
|deaktiviert das Modul
|0
|-
!align="right" |weekday_mapping
|
|Mapping, wie die Readings der Tage angezeigt werden sollen, zum Beispiel So Mo Di Mi Do Fr Sa
|Sonntag Montag Dienstag Mittwoch Donnerstag Freitag Samstag
|-
!align="right" |delimiter_text_reading
|
|Wenn zwei Abholungen an ein und demselben Tag existieren, wird dieses Trennzeichen genutzt, um die beiden (oder mehrere) Werte zu einem Text zu verbinden. Nur relevant für die Readings next_text und now_text
|und
|-
!align="right" |delimiter_reading
|
|wie attribute delimiter_text_reading, allerdings nur für die readings next und now
|
|-
!align="right" |filter
|
|regex zum Filtern der Namen der Termine aus den Kalendern, so dass nur solche genutzt werden, welche diesem Filter entsprechen
|
|-
|}

== Anwendungsbeispiel(e) ==
=== Einbindung ins Tablet UI ===
<pre><div data-device="myABFALL" data-type="symbol" class="bigger warn wider"
data-get="next" data-get-warn=".*(\d+).*"
data-get-on='["Restmuell_.*","Wertstoff_.*"]'
data-on-colors='["#000","#6EB54C"]'
data-icons='["fa-trash-o","fa-trash-o"]'></div></pre>

=== Einbindung ins Tablet UI, erweitert ===
Fallen die Leerungen zweier verschiedener Tonnen nicht auf den selben Tag, reicht es normalerweise, nur ein Symbol auf der Oberfläche zu platzieren und dieses dann dynamisch zu befüllen. In folgendem Beispiel werden folgende Anforderungen umgesetzt:
* Anzeige unterschiedlicher Symbole bzw. Farben für Papiertonne, Restmülltonne, Biotonne und gelbe Säcke
* Anzeige der verbleibenden Tage bis zur Leerung als "Warn"-Marker in Rot, aber nur, wenn die Leerung innerhalb der nächsten 2 Tage ist
* Blinken des Symbols, wenn die nächste Leerung morgen ansteht
* Rotation des Symbols, wenn die nächste Leerung noch am selben Tag ansteht. Nach einer bestimmten Uhrzeit (z.B. 9 Uhr morgens) soll dann auf die nächste Tonne geschaltet werden
* Anzeige des Datums bzw. von "heute" oder "morgen" unter dem Symbol als Label

Zur Datumsanzeige wird eine kleine Hilfsfunktion in die 99_myUtils eingebaut.
<source lang="perl">
sub datumHeuteMorgen($){
my $compareDate = shift;
my ($sec,$min,$hour,$mday,$mon,$year,$wday,$yday,$isdst) = localtime(time);
$year += 1900; $mon += 1;
my $heute = sprintf('%02d.%02d.%04d', $mday, $mon, $year);
($sec,$min,$hour,$mday,$mon,$year,$wday,$yday,$isdst)=localtime(time+86400);
$year += 1900; $mon += 1;
my $morgen = sprintf('%02d.%02d.%04d', $mday, $mon, $year);
return "heute" if $compareDate eq $heute;
return "morgen" if $compareDate eq $morgen;
return $compareDate;
}
</source>
Diese Funktion wird in den userReadings des Abfall-Moduls verwendet. Das Abfallmodul erzeugt eine Gruppe von Readings mit dem Namen now_*, wenn die Leerung am selben Tag ansteht, bzw. genau dann, wenn der Termin im zu Grunde liegenden Kalender gerade aktiv ist. In diesem Beispiel liegt dem Kalender-Modul ein Google-Kalender zu Grunde, bei dem die Termine immer von 0 Uhr bis 9 Uhr morgens eingetragen sind. Dadurch wird erreicht, dass die Anzeige nach 9 Uhr weiterspringt, weil dann die now-Readings verschwinden.

Folgende userReadings werden zum Abfallmodul hinzugefügt, welches in diesem Beispiel "abf.abfall" genannt ist:
<source lang="perl">
attr myABFALL userReadings ftui_datum {ReadingsVal("myABFALL","now_text","") eq "" ? datumHeuteMorgen(ReadingsVal("myABFALL","next_datum","")) : "heute";},ftui_next {ReadingsVal("myABFALL","now_text","") eq "" ? ReadingsVal("myABFALL","next","") : ReadingsVal("myABFALL","now","")."_0";}
</source>
Das Reading "ftui_next" bildet die Grundlage für das Symbol in TabletUI, das Reading "ftui_datum" wird für das Label genutzt.

Somit lässt sich ganze in FTUI wie folgt darstellen:
<source lang="html">
<div data-device="myABFALL"
data-type="symbol"
data-get="ftui_next"
data-get-on='["Biotonne_0$","Biotonne_1$","Biotonne_.*","GelberSack_0$","GelberSack_1$","GelberSack_.*","Papiertonne_0$","Papiertonne_1$","Papiertonne_.*","Restmuelltonne_0$","Restmuelltonne_1$","Restmuelltonne_.*"]'
data-get-warn=".*([0|1|2]).*"
data-on-colors='["#8B4513","#8B4513","#8B4513","#f4e946","#f4e946","#f4e946","#2d9e1c","#2d9e1c","#2d9e1c","#696969","#696969","#696969"]'
class="large warn"
data-icons='["fa-trash-o fa-spin","fa-trash-o blink","fa-trash-o","fs-bag fa-spin","fs-bag blink","fs-bag","fs-dustbin fa-spin","fs-dustbin blink","fs-dustbin","fa-trash fa-spin","fa-trash blink","fa-trash"]'
/>
<div data-device="myABFALL" data-get="ftui_datum" data-type="label"/>
</source>
Für Jede Tonne werden hier drei Zustände unterschieden und einzeln in "data-get-on", "data-on-colors" und "data-icons" zugeordnet. Daher haben diese Listen jeweils 12 Einträge.

=== Benachrichtigung ===
==== DOIF ====
====== TelegramBot Beispiel ======
<pre>[myABFALL:next_tage] == 1) ( set fhemBot message 'Morgen wird [myABFALL:next_text] abgeholt')
[myABFALL:now_text] ne "") ( set fhemBot message 'Heute wird [myABFALL:now_text] abgeholt')</pre>

====== Pushbullet Beispiel ======

Die morgigen Leerungen per Push um 19:30 mittels Pushbullet:

<code>define dAbfallmorgen doif ([19:30] and [myABFALL:next_tage] == 1) ( msg |Morgen wird [myABFALL:next_text] abgeholt)

attr dAbfallmorgen do always</code>

Die heutigen Leerungen per Push um 07:00 mittels Pushbullet:

<code>define dAbfallheute doif ([07:00] and [myABFALL:now_text] ne "") ( msg |Heute wird [myABFALL:now_text] abgeholt)

attr dAbfallheute do always</code>

=== Links ===
* Forenthema {{Link2Forum|Topic=50177|LinkText=Abfall Visualisierung mit Bilderrahmen}}

FHEMWiki:Interna

2017-02-15T14:56:05Z

Mahowi: /* Januar 2017 */

{{Randnotiz|RNTyp=info|RNText="Infobox Interna" zu FHEM Wiki
* [[Spezial:Version|Versionsinfo]]
* [[Spezial:Statistik|Statistisches]]
}}
[[FHEMWiki:Interna]] wie Informationen über geplante Wartungsarbeiten, Probleme, Erweiterungswünsche etc.

== Aktuell ==
== Januar 2017 ==
* MediaWiki wurde auf Version 1.28.0 aktualisiert

== Dezember 2016 ==
* Wiki wurde auf einen anderen Server und gleichzeitig auf die Domain wiki.fhem.de umgezogen
* MediaWiki wurde vorerst auf Version 1.24.1 belassen; Update auf aktuelle Version ist vorgesehen, sobald sich das Wiki in der neuen Umgebung eingespielt hat

== Umstellung vom 6.11.2015 ==
* Einige "Standarddateien" (aus wikimedia:common) scheinen verschwunden zu sein; dadurch fehlen aktuell einige Bilder, insbesondere in den Vorlagen "Hallo" und "Randnotiz". Arno wurde per Mail informiert.

== Umstellung vom 30.10.2015 ==
* [[Syntax Highlighting]] wurde auf mehrfachen Wunsch eingerichtet.

== Umstellung vom 10.2.2015 ==
Am 10.2.2015 wurde der Wiki-Server auf eine leistungsfähigere Plattform umgezogen.

Gleichzeitig wurde die MediaWiki Version auf 1.24.1 aktualisiert.

=== Offene Probleme ===
Probleme sind mittlerweile abgearbeitet, Wünsche bearbeitet (abgelehnt oder erfüllt)

=== Erledigte Probleme ===
* Kopfbereich aller Wiki-Seiten hat (noch) die falsche Hintergrundfarbe
** erledigt: [[Benutzer:Akw|Akw]] ([[Benutzer Diskussion:Akw|Diskussion]]) 17:27, 24. Feb. 2015 (CET)
* ''wikitable sortable'' funktioniert nicht (mehr)
** erledigt: --[[Benutzer:Akw|Akw]] ([[Benutzer Diskussion:Akw|Diskussion]]) 22:37, 19. Apr. 2015 (CEST)
* Bearbeitungs- und erweiterte Bearbeitungswerkzeugleiste sind trotz Auswahl in Benutzereinstellung nicht vorhanden (getestete Browser: Firefox, IE)
** erledigt: --[[Benutzer:Akw|Akw]] ([[Benutzer Diskussion:Akw|Diskussion]]) 22:37, 19. Apr. 2015 (CEST)
* Suchvorschlagsliste bei Eingabe des Suchwortes im Suchfeld nicht mehr vorhanden
** erledigt: --[[Benutzer:Krikan|Christian]] ([[Benutzer Diskussion:Krikan|Diskussion]]) 20:23, 22. Apr. 2015 (CEST)
* Darstellung ist "anders" (z.B.: Überschriften auf Level 2 (==) jetzt Serifenschrift)
* (Wunsch:) Wäre es möglich, die Extension [http://www.mediawiki.org/wiki/Extension:DynamicWikiSitemap DynamicWikiSitemap] zu installieren?
** Die funktioniert nicht gut mit dem nginx-webserver. Ich habe statische sitemaps für die Google Webmaster Tools erstellt: http://wiki.fhem.de/w/sitemap/sitemap-index-c1fhemwiki.xml [[Benutzer:Akw|Akw]] ([[Benutzer Diskussion:Akw|Diskussion]]) 17:27, 24. Feb. 2015 (CET)
* Benutzereinstellungen (Spezial:Einstellungen): die Seite bietet keine "Themes" (mehr?) an; es ist "nur noch" '''Benutzeroberfläche''' ''Vector'' installiert.
:: Das ist so gewollt. ([[Benutzer Diskussion:Akw|Diskussion]]) 17:27, 24. Feb. 2015 (CET)
* Bug? Wenn man direkt ein Kapitel einer Seite bearbeitet, bleibt die Schaltfläche "nur Kleinigkeiten wurden verändert" ohne Wirkung.

=== Diskussion ===
:: Es gibt aber allem Anschein nach noch ein offenes Problem mit diesem einzigen verbliebenen Skin: ich bekomme auf allen FHEM-Wiki Seiten (sichtbar "nur" in Firebug) die Fehlermeldung ''<nowiki>"NetworkError: 502 Bad Gateway - http://wiki.fhem.de/w/load.php?debug=false&lang=de&modules=startup&only=scripts&skin=vector&*"</nowiki>''. Nach einer Info, die ich an anderer Stelle gefunden habe, könnte auch die fehlende Werkzeugleiste damit zusammenhängen.
:: Falls die Frage erlaubt ist: was ist der Grund dafür, dass nur noch ein Skin "gewollt" ist? --[[Benutzer:Ph1959de|Peter]] ([[Benutzer Diskussion:Ph1959de|Diskussion]]) 10:56, 2. Apr. 2015 (CEST)
:: <hr />
:: Ich hab den Bug jetzt im Griff, denke ich. Es paar Puffergrößen mussten angepasst werden. --[[Benutzer:Akw|Akw]] ([[Benutzer Diskussion:Akw|Diskussion]]) 22:35, 19. Apr. 2015 (CEST)
:: @Peter: Wenn es zwingend gewünscht wird, lasse ich mich mit den Skins breitschlagen, aber Vector ist doch ganz hübsch oder? Und der Wartungsaufwand wird minimiert.
[[Kategorie:FHEM Wiki]]
::: Ich brauch jedenfalls keine Skins.[[Benutzer:Soulman|Soulman]] ([[Benutzer Diskussion:Soulman|Diskussion]]) 03:47, 26. Apr. 2015 (CEST)

MAX! Temperatur-Scanner

2017-01-30T13:05:01Z

Mahowi: /* Einrichten des Thermostat-internen Wochenprogrammes */ Typos

Der '''MAX! Temperatur-Scanner''' ist ein Perl-Skript, das die kontinuierliche Temperatur-Aufzeichnung
von MAX-Thermostaten ermöglicht.

== Features ==
* kontinuierliche Erfassung von Temperatur und Ventil-Position
* Berücksichtigung der System-Ressourcen (dutycycle, credits)
* [[MAX#CUL_MAX|CUL]] und [[MAX#MAXLAN|CUBE]] werden unterstützt
* gleichberechtigte zeitliche Bearbeitung der Thermostate (Round-Robin-Prinzip)
* Ermittlung der optimalen Scan-Rate über die Anzahl der eingebundenen Thermostate
* 2 Scan-Modi stehen zur Verfügung (DesiredChange + ModeChange)

== Zielsetzung des WIKI-Artikels ==
Hier werden Fragen und Erkenntnisse zum Thema dargestellt, da der Forums-Eintrag für viele Anwender nicht mehr überschaubar ist.

Der Artikel wird sukzessive erweitert.

== Voraussetzungen ==
==== Qualität der Funkverbindung ====
In der Log-Datei sollten möglichst wenig Einträge der nachfolgenden Form auftreten
<pre>2013.11.01 02:12:33 2: CUL_MAX_SendQueueHandler: Missing ack from 0905a5 for 0b0b0040123456xxxxxxxxx</pre>
Diese weisen auf eine schlechte Funkverbindung hin. In diesem Fall wird der CUL bis zu 3x den Befehl wiederholen und dabei jede Menge Credits verbrauchen. Damit wird der Scanner inaktiv bleiben, da häufig zu wenige Credits vorhanden sind.

==== Ausreichend Credits ====
Der Scanner kann nicht aktiv werden, wenn gehäuft Log-Einträge der nachfolgenden Form auftreten.
<pre>2013.11.01 14:12:50 2: CUL_MAX_SendQueueHandler: Not enough credit! credit10ms is 6, but we need 121. Waiting 115 seconds.</pre>
Die Ursache hierfür kann neben funktechnischen Problem auch sein, dass ein anderer Mechanismus ausserhalb des Scanners permanent sendet, ohne Rücksicht auf die Credits zu nehmen.

==== Einrichten des Thermostat-internen Wochenprogrammes ====

Die Readings des Wochenprogramms müssen erscheinen. Der Scanner greift ausgiebig auf diese Informationen zurück. Ein manuelles Verstellen des Sollwertes ist nur bis zu dem nächsten Schaltzeitpunkt des Wochenprogramms gültig. Danach wird je nach ScanMode das Thermostat selbst oder der Scanner den Sollwert gemäß den Einstellungen des Wochenprogramms ändern.

'''Bitte folgendes beachten:'''

Es gibt im Zusammenhang mit dem Wochenprogramm ein Problem mit dem letzten Schaltpunkt des Tages.
Der Workaround wurde [http://forum.fhem.de/index.php/topic,17231.msg112738.html#msg112738 hier]
beschrieben.

<big>Man muss dafür sorgen, dass man kurz vor Ende des Tages noch einen Schaltpunkt setzt.</big>

== Mechanismen ==
=== Das Problem ===
Der Hersteller der MAX-Thermostate hat diese so konzipiert, dass die gemessene Temperatur und Ventilstellung nur übertragen werden, wenn sich Folgendes ändert:
* die Ventilstellung
* die Betriebsart (mode: auto,manu,temporary,boost)
* der Sollwert

Es kann der Fall eintreten, dass über Stunden keine Temperatur an FHEM übertragen wird. Damit sind Aufzeichnungen für Temperatur und Ventilstellung wenig aussagekräftig.

=== Der Lösungsansatz ===
==== Triggerung per Mode-Umschaltung (ModeChange) ====
Dies ist der Default-Mode des Scanners.
Hier wird der Ansatz verfolgt, die Betriebsart des Thermostats regelmässig umzuschalten via
:AUTO ==> MANU
<Wartezeit mindestens 3 Minuten>
:MANU ==> AUTO

Dies veranlasst das Thermostat, regelmässig die gewünschten Werte an FHEM (den gepaarten Transceiver) zu senden.

==== Triggerung per Sollwert-Umschaltung (DesiredChange) ====
Durch Änderung des Sollwertes kann ebenso die Übertragung des Istwertes am Thermostat initiiert werden.

Der Scanner ändert den vorgegebenen Sollwert um 0.5 Grad. Er wird hierbei die Änderung immer in die Richtung einer sich vergroessernden Regelabweichung durchführen.

Dieser Modus wird durch die Definition des UserReadings "onlyAutoMode" festgelegt.
:<code>attr HT.JOHN userReadings onlyAutoMode { return "1";;}</code>

'''Beispiel:'''

Sollwert im Thermostat nach Wochenprofil: 18
Fall A:
----
* Istwert 17
* Sollwert A von Scanner gesetzt : 18.5
* Sollwert B von Scanner gesetzt : 18.0
* Der Scanner wechselt also von 18 auf 18.5 und zurück.

Fall B:
----
* Istwert 19
* Sollwert A von Scanner gesetzt : 17.5
* Sollwert B von Scanner gesetzt : 18.0
* Der Scanner wechselt also von 18 auf 17.5 und zurück.

=== Ergebnis ===
==== ohne Scanner ====
[[Datei:2013_12_MaxScanner_Vorher.png|ohne Scanner]]

==== mit Scanner (ScanMode=ModeChange) ====
[[Datei:13_12_01_Scanner_ModeChange.png|mit Scanner]]

==== mit Scanner (ScanMode=DesiredChange) ====
[[Datei:13_12_01_Scanner_DesiredChange.png|mit Scanner]]

=== Ressourcen ===
Die Sendezeit jedes Teilnehmers ist auf 1% begrenzt.

Konkret bedeutet dies, dass ein CUL ca. 33 Telegramme pro Stunde senden kann.
Der MAX-Scanner darf nicht alle Ressourcen für sich beanspruchen, sondern sieht seine Aufgabe als nachrangig.

Erst wenn mehr als 300 Credits (von max. 900 möglichen) zur Verfügung stehen, wird das Skript aktiv.

== Fragen und Antworten ==
=== Welchen ScanMode soll ich wählen? ===
Nachfolgende Punkte können als Entscheidungskriterium dienen:

'''ModeChange'''
* keine Änderung des Sollwertes nötig
* damit ist das Ventil "ruhiger", da sich die Regeldifferenz nicht durch den Scanner-Betrieb ändert.

'''DesiredChange'''
* der Auto-Modus wird niemals verlassen
* Falls FHEM ausfällt, wird das Thermostat das gespeicherte Wochenprogramm nutzen

=== Was passiert, wenn der Sollwert am Thermostat manuell verstellt wird? ===
Wenn der Sollwert manuell am Thermostat verändert wird, kann es bis zu 3 Minuten dauern, bis dieser an FHEM gemeldet wird.

Wenn der Scanner in dieser Wartezeit aktiv wird, wird er den soeben geänderten Sollwert überschreiben. In diesem Fall bliebe die manuelle Änderung wirkungslos.

Wird die manuelle Änderung des Sollwertes vom Scanner erkannt, so gilt dieser bis zum nächsten Schaltpunkt des internen Wochenprogrammes.

=== Mehrere Thermostate in einer Gruppe? ===
Wenn mehrere Thermostate in einer Gruppe vereinigt sind (Raumlösung nach ELV), dann darf nur ein einziges Thermostat vom Scanner bedient werden, da die anderen Thermostate von diesem synchronisiert werden. Also das Attribut "scanTemp" nur bei einem Repräsentanten der Gruppe aktivieren.

=== Was ist zu tun wenn, Thermostate zusammen mit einem Wandthermostat eingesetzt werden? ===
In diesem Fall ist der Scanner überflüssig, da das Wandthermostat ohnehin eine detaillierte Kurve des Istwertes liefert.

=== Sind Fensterkontakte sinnvoll? ===
Auf den ersten Blick scheinen sie das zu sein, da man meint Energie zu sparen. Hierzu gibt es jedoch auch eine andere Betrachtungsweise wie die Seite
[http://www.elv.de/topic/tuer-fensterkontakt-sinn-und-unsinn.html Sinn und Unsinn von Fensterkontakten] zeigt.

Das Thermostat ist auch ohne Fensterkontakt mit Hilfe der "Temperatur-Sturz-Erkennung" in der Lage festzustellen, dass ein Fenster offen ist. Der zuvor genannte Link präferiert diese Methode.

[[Datei:2013_11_02_Scanner_TSturz.png|Sturz-Temperatur-Erkennung]]

Aber auch die Temperatur-Sturz-Erkennung stellt hinterher wieder fix die 17 Grad ein. Ausserdem ist diese wie hier im Beispiel im Hochsommer angesprungen (Tür wurde zum Abkühlen geöffnet). Diese Problem kann vermutlich mit einer WindowOpenDuration von 0 behoben werden, ausserdem ist im Hochsommer die Heizung ohnehin ausgeschaltet.

Folgende Nachteile haben die Max-Fensterkontakte:
* Es gibt keine Verzögerungszeit, das Thermostat schliesst sofort, wenn das Fenster geöffnet wird. Das mag bei einem normalen Fenster noch akzeptabel sein, nicht aber bei Türen.
* Wenn das Thermostat im Auto-Modus ist und der Fensterkontakt geht von aktiv zu inaktiv (Fenster wieder geschlossen), dann stellt das Thermostat fix 17 Grad ein, also nicht den zuvor eingestellten Sollwert (dieses Verhalten betrachten viele als Design-Fehler).

=== Berücksichtigt der Scanner die Temperatur-Sturz-Erkennung? ===
Wenn desiredTemperature=WindowsOpenTemperature, dann stellt der Scanner seine Arbeit ein. Ansonsten würde er durch aktive Modeumschaltung die WindowsOpenTemperature dauerhaft setzen.

=== Kann der Scanner mit Fensterkontakten umgehen? ===
Der Scanner versucht, das Problem der fixen 17 Grad nach Schliessen des Fensters zu korrigieren. Hierzu braucht er jedoch die Information, welcher Fensterkontakt für das jeweilige Thermostat zuständig ist.

Ausserdem wäre es fatal, wenn der Scanner in der Phase des offenen Fensters den Sollwert überschreiben würde. Bei offenem Fenster ist der Scanner inaktiv, er schaltet also den Modus nicht mehr um.

=== Was passiert, wenn der Boost-Mode aktiviert wurde? ===
Sobald dies der Scanner erkennt, stellt er seine Aktivität ein, bis wieder der Modus Auto oder Manu erscheint.

=== Unterstützt der Scanner auch den MAX-ECO-Taster? ===
Nein.

=== Beeinflusst der Scanner den Regelmechanismus des Thermostats? ===
Im Prinzip nicht. Jedoch wird in der Betriebsart "DesiredChange" der Sollwert geringfügig um +/- 0.5 Grad im Sinne einer sich vergrößernden Regeldifferenz verändert.

== Die Modul-Variante ==

Die Modul-Variante ist seit dem 10.01.2016 Bestandteil von FHEM.

=== Voraussetzungen ===
* ggf. vorhandene Script-Variante sollte deaktiviert werden (99_UtilsMaxScan löschen/verschieben)

=== Inbetriebnahme ===
* Scanner Modul definieren
<pre>
define Scanner MaxScanner
attr Scanner verbose 1
</pre>

* die bestehende Max-Thermostate verfügen nun automatisch über neue Attribute, die den Scanner betreffen
* die meisten Scanner-spezfischen Attribute beginnen immer mit "scn"
* im folgende Beispiel wird das Thermostat HT.JOHN betrachtet:
<pre>
define HT.JOHN MAX HeatingThermostat 066666
</pre>
* das Thermostat wird für den Scanner freigegeben
<pre>attr HT.JOHN scanTemp 1</pre>
* wir wählen die Betriebsart Mode-Change
<pre>attr HT.JOHN scnProcessByDesiChange 0</pre>
* wir können 0..n ShutterContacts definieren, getrennt durch Komma
<pre>attr HT.JOHN scnShutterList SHUTTER.JOHN,SHUTTER.BRENNER</pre>
* verbose liefert ausführliche Infos im Logger
<pre>attr HT.JOHN verbose 4</pre>

=== Attribute Thermostat===
{| class="wikitable sortable"
|-
! Parameter !! Wertebereich !! Default !! Beschreibung
|-
|scanTemp||[0,1]||0||wenn 1, wird das Thermostat vom Scanner berücksichtigt
|-
|scnProcessByDesiChange||[0,1]||0||wenn 1, wird das Thermostat über die Änderung von desiredTemperature (DesiredChange) getriggert, ansonsten über die Änderung des Modes (ModeChange)
|-
|scnModeHandling||[NOCHANGE,AUTO,MANUAL]||AUTO|||wenn scnProcessByDesiChange aktiviert ist, kann man hier entscheiden, wie mit dem MODE verfahren werden soll. Wenn AUTO, wird der Scanner immer den Mode "auto" vorgeben, wenn MANUAL, den Mode "manual" sobald der Sollwert zum
Thermostat geschrieben wird. Ist hingegen NOCHANGE gewählt, so wird der aktuelle am Thermostat angewählte Mode belassen.
|-
|scnShutterList||||||Liste von assoziierten Max-Fensterkontakten (ShutterContacts), die durch ein Komma getrennt werden.
Der Scanner benötigt diese, um ein geöffnetes Fenster umgehend zu erkennen. Er erkennt ein offenes Fenster auch ohne Fensterkontakt, wenn gilt "aktueller Sollwert" = WindowOpenTemperature. Das Thermostat geht nach erkanntem Temperaturabfall auf diesen Wert.

|}
=== Attribute Scanner===
{| class="wikitable sortable"
|-
! Parameter !! Wertebereich !! Default !! Beschreibung
|-
|disable||[0,1]||0|| wenn 1, dann wird der Scanner gesperrt und ist somit inaktiv.
|-
|scnCreditThreshold||[150..600]||300|| die Mindestanzahl von verfügbaren Credits, ab der der Scanner mit dem Triggern der Thermostate beginnt
|-
|scnMinInterval||[3..60]||3|| die Mindestwartezeit in Minuten, nach der der Scanner ein Thermostate erneut triggert; diese wird nur berücksichtigt, wenn sie höher ist, als die berechnete Wartezeit, die sich aus der Anzahl der Thermostate ergibt.
|-
|}

=== Background ===

==== Hilfe zur Diagnose der Abläufe ====
Ein wichtiges Hilfsmittel ist der Event-Monitor. Mit der Filter-Einstellung "MAX.*" werden nur noch die MAX-relevanten Events dargestellt.

Interpretation der Ausgabe:<br/>
<pre>
2016-01-06 21:24:43 MAX HT.BAD desiredTemperature auto 20.0 <-- Triggern des Thermostats durch Scanner

2016-01-06 21:24:50 MAX HT.BAD mode: auto --> Rückmeldung vom Thermostat
2016-01-06 21:24:50 MAX HT.BAD RSSI: -54 --> Rückmeldung vom Thermostat
2016-01-06 21:24:56 MAX HT.BAD temperature: 20.2 --> Rückmeldung vom Thermostat
</pre>

Hier erscheinen also die zu Thermostat gesendeten Informationen ebenso, wie die empfangenen.
Empfangene Informationen sind meist mit einem ":" gekennzeichnet.

[[Kategorie:MAX]]

MAX! Temperatur-Scanner

2017-01-30T13:03:57Z

Mahowi: /* Features */ Links zur MAX-Hautpseite (CUBE, CUL)

Der '''MAX! Temperatur-Scanner''' ist ein Perl-Skript, das die kontinuierliche Temperatur-Aufzeichnung
von MAX-Thermostaten ermöglicht.

== Features ==
* kontinuierliche Erfassung von Temperatur und Ventil-Position
* Berücksichtigung der System-Ressourcen (dutycycle, credits)
* [[MAX#CUL_MAX|CUL]] und [[MAX#MAXLAN|CUBE]] werden unterstützt
* gleichberechtigte zeitliche Bearbeitung der Thermostate (Round-Robin-Prinzip)
* Ermittlung der optimalen Scan-Rate über die Anzahl der eingebundenen Thermostate
* 2 Scan-Modi stehen zur Verfügung (DesiredChange + ModeChange)

== Zielsetzung des WIKI-Artikels ==
Hier werden Fragen und Erkenntnisse zum Thema dargestellt, da der Forums-Eintrag für viele Anwender nicht mehr überschaubar ist.

Der Artikel wird sukzessive erweitert.

== Voraussetzungen ==
==== Qualität der Funkverbindung ====
In der Log-Datei sollten möglichst wenig Einträge der nachfolgenden Form auftreten
<pre>2013.11.01 02:12:33 2: CUL_MAX_SendQueueHandler: Missing ack from 0905a5 for 0b0b0040123456xxxxxxxxx</pre>
Diese weisen auf eine schlechte Funkverbindung hin. In diesem Fall wird der CUL bis zu 3x den Befehl wiederholen und dabei jede Menge Credits verbrauchen. Damit wird der Scanner inaktiv bleiben, da häufig zu wenige Credits vorhanden sind.

==== Ausreichend Credits ====
Der Scanner kann nicht aktiv werden, wenn gehäuft Log-Einträge der nachfolgenden Form auftreten.
<pre>2013.11.01 14:12:50 2: CUL_MAX_SendQueueHandler: Not enough credit! credit10ms is 6, but we need 121. Waiting 115 seconds.</pre>
Die Ursache hierfür kann neben funktechnischen Problem auch sein, dass ein anderer Mechanismus ausserhalb des Scanners permanent sendet, ohne Rücksicht auf die Credits zu nehmen.

==== Einrichten des Thermostat-internen Wochenprogrammes ====

Die Readings Wochenprogrammes müssen erscheinen. Der Scanner greift ausgiebig auf diese Informationen zurück. Ein manuelles verstellen des Sollwertes ist nur bis zu dem nächsten Schaltzeitpunkt des Wochenprogramms gültig. Danach wird je nach ScanMode das Thermostat selbst oder der Scanner den Sollwert gemäß den Einstellungen des Wochenprogramms ändern.

'''Bitte folgendes beachten:'''

Es gibt im Zusammenhang mit dem Wochenprogramm ein Problem mit dem letzten Schaltpunkt des Tages.
Der Workaround wurde [http://forum.fhem.de/index.php/topic,17231.msg112738.html#msg112738 hier]
beschrieben.

<big>Man muss dafür sorgen, dass man kurz vor Ende des Tages noch einen Schaltpunkt setzt.</big>

== Mechanismen ==
=== Das Problem ===
Der Hersteller der MAX-Thermostate hat diese so konzipiert, dass die gemessene Temperatur und Ventilstellung nur übertragen werden, wenn sich Folgendes ändert:
* die Ventilstellung
* die Betriebsart (mode: auto,manu,temporary,boost)
* der Sollwert

Es kann der Fall eintreten, dass über Stunden keine Temperatur an FHEM übertragen wird. Damit sind Aufzeichnungen für Temperatur und Ventilstellung wenig aussagekräftig.

=== Der Lösungsansatz ===
==== Triggerung per Mode-Umschaltung (ModeChange) ====
Dies ist der Default-Mode des Scanners.
Hier wird der Ansatz verfolgt, die Betriebsart des Thermostats regelmässig umzuschalten via
:AUTO ==> MANU
<Wartezeit mindestens 3 Minuten>
:MANU ==> AUTO

Dies veranlasst das Thermostat, regelmässig die gewünschten Werte an FHEM (den gepaarten Transceiver) zu senden.

==== Triggerung per Sollwert-Umschaltung (DesiredChange) ====
Durch Änderung des Sollwertes kann ebenso die Übertragung des Istwertes am Thermostat initiiert werden.

Der Scanner ändert den vorgegebenen Sollwert um 0.5 Grad. Er wird hierbei die Änderung immer in die Richtung einer sich vergroessernden Regelabweichung durchführen.

Dieser Modus wird durch die Definition des UserReadings "onlyAutoMode" festgelegt.
:<code>attr HT.JOHN userReadings onlyAutoMode { return "1";;}</code>

'''Beispiel:'''

Sollwert im Thermostat nach Wochenprofil: 18
Fall A:
----
* Istwert 17
* Sollwert A von Scanner gesetzt : 18.5
* Sollwert B von Scanner gesetzt : 18.0
* Der Scanner wechselt also von 18 auf 18.5 und zurück.

Fall B:
----
* Istwert 19
* Sollwert A von Scanner gesetzt : 17.5
* Sollwert B von Scanner gesetzt : 18.0
* Der Scanner wechselt also von 18 auf 17.5 und zurück.

=== Ergebnis ===
==== ohne Scanner ====
[[Datei:2013_12_MaxScanner_Vorher.png|ohne Scanner]]

==== mit Scanner (ScanMode=ModeChange) ====
[[Datei:13_12_01_Scanner_ModeChange.png|mit Scanner]]

==== mit Scanner (ScanMode=DesiredChange) ====
[[Datei:13_12_01_Scanner_DesiredChange.png|mit Scanner]]

=== Ressourcen ===
Die Sendezeit jedes Teilnehmers ist auf 1% begrenzt.

Konkret bedeutet dies, dass ein CUL ca. 33 Telegramme pro Stunde senden kann.
Der MAX-Scanner darf nicht alle Ressourcen für sich beanspruchen, sondern sieht seine Aufgabe als nachrangig.

Erst wenn mehr als 300 Credits (von max. 900 möglichen) zur Verfügung stehen, wird das Skript aktiv.

== Fragen und Antworten ==
=== Welchen ScanMode soll ich wählen? ===
Nachfolgende Punkte können als Entscheidungskriterium dienen:

'''ModeChange'''
* keine Änderung des Sollwertes nötig
* damit ist das Ventil "ruhiger", da sich die Regeldifferenz nicht durch den Scanner-Betrieb ändert.

'''DesiredChange'''
* der Auto-Modus wird niemals verlassen
* Falls FHEM ausfällt, wird das Thermostat das gespeicherte Wochenprogramm nutzen

=== Was passiert, wenn der Sollwert am Thermostat manuell verstellt wird? ===
Wenn der Sollwert manuell am Thermostat verändert wird, kann es bis zu 3 Minuten dauern, bis dieser an FHEM gemeldet wird.

Wenn der Scanner in dieser Wartezeit aktiv wird, wird er den soeben geänderten Sollwert überschreiben. In diesem Fall bliebe die manuelle Änderung wirkungslos.

Wird die manuelle Änderung des Sollwertes vom Scanner erkannt, so gilt dieser bis zum nächsten Schaltpunkt des internen Wochenprogrammes.

=== Mehrere Thermostate in einer Gruppe? ===
Wenn mehrere Thermostate in einer Gruppe vereinigt sind (Raumlösung nach ELV), dann darf nur ein einziges Thermostat vom Scanner bedient werden, da die anderen Thermostate von diesem synchronisiert werden. Also das Attribut "scanTemp" nur bei einem Repräsentanten der Gruppe aktivieren.

=== Was ist zu tun wenn, Thermostate zusammen mit einem Wandthermostat eingesetzt werden? ===
In diesem Fall ist der Scanner überflüssig, da das Wandthermostat ohnehin eine detaillierte Kurve des Istwertes liefert.

=== Sind Fensterkontakte sinnvoll? ===
Auf den ersten Blick scheinen sie das zu sein, da man meint Energie zu sparen. Hierzu gibt es jedoch auch eine andere Betrachtungsweise wie die Seite
[http://www.elv.de/topic/tuer-fensterkontakt-sinn-und-unsinn.html Sinn und Unsinn von Fensterkontakten] zeigt.

Das Thermostat ist auch ohne Fensterkontakt mit Hilfe der "Temperatur-Sturz-Erkennung" in der Lage festzustellen, dass ein Fenster offen ist. Der zuvor genannte Link präferiert diese Methode.

[[Datei:2013_11_02_Scanner_TSturz.png|Sturz-Temperatur-Erkennung]]

Aber auch die Temperatur-Sturz-Erkennung stellt hinterher wieder fix die 17 Grad ein. Ausserdem ist diese wie hier im Beispiel im Hochsommer angesprungen (Tür wurde zum Abkühlen geöffnet). Diese Problem kann vermutlich mit einer WindowOpenDuration von 0 behoben werden, ausserdem ist im Hochsommer die Heizung ohnehin ausgeschaltet.

Folgende Nachteile haben die Max-Fensterkontakte:
* Es gibt keine Verzögerungszeit, das Thermostat schliesst sofort, wenn das Fenster geöffnet wird. Das mag bei einem normalen Fenster noch akzeptabel sein, nicht aber bei Türen.
* Wenn das Thermostat im Auto-Modus ist und der Fensterkontakt geht von aktiv zu inaktiv (Fenster wieder geschlossen), dann stellt das Thermostat fix 17 Grad ein, also nicht den zuvor eingestellten Sollwert (dieses Verhalten betrachten viele als Design-Fehler).

=== Berücksichtigt der Scanner die Temperatur-Sturz-Erkennung? ===
Wenn desiredTemperature=WindowsOpenTemperature, dann stellt der Scanner seine Arbeit ein. Ansonsten würde er durch aktive Modeumschaltung die WindowsOpenTemperature dauerhaft setzen.

=== Kann der Scanner mit Fensterkontakten umgehen? ===
Der Scanner versucht, das Problem der fixen 17 Grad nach Schliessen des Fensters zu korrigieren. Hierzu braucht er jedoch die Information, welcher Fensterkontakt für das jeweilige Thermostat zuständig ist.

Ausserdem wäre es fatal, wenn der Scanner in der Phase des offenen Fensters den Sollwert überschreiben würde. Bei offenem Fenster ist der Scanner inaktiv, er schaltet also den Modus nicht mehr um.

=== Was passiert, wenn der Boost-Mode aktiviert wurde? ===
Sobald dies der Scanner erkennt, stellt er seine Aktivität ein, bis wieder der Modus Auto oder Manu erscheint.

=== Unterstützt der Scanner auch den MAX-ECO-Taster? ===
Nein.

=== Beeinflusst der Scanner den Regelmechanismus des Thermostats? ===
Im Prinzip nicht. Jedoch wird in der Betriebsart "DesiredChange" der Sollwert geringfügig um +/- 0.5 Grad im Sinne einer sich vergrößernden Regeldifferenz verändert.

== Die Modul-Variante ==

Die Modul-Variante ist seit dem 10.01.2016 Bestandteil von FHEM.

=== Voraussetzungen ===
* ggf. vorhandene Script-Variante sollte deaktiviert werden (99_UtilsMaxScan löschen/verschieben)

=== Inbetriebnahme ===
* Scanner Modul definieren
<pre>
define Scanner MaxScanner
attr Scanner verbose 1
</pre>

* die bestehende Max-Thermostate verfügen nun automatisch über neue Attribute, die den Scanner betreffen
* die meisten Scanner-spezfischen Attribute beginnen immer mit "scn"
* im folgende Beispiel wird das Thermostat HT.JOHN betrachtet:
<pre>
define HT.JOHN MAX HeatingThermostat 066666
</pre>
* das Thermostat wird für den Scanner freigegeben
<pre>attr HT.JOHN scanTemp 1</pre>
* wir wählen die Betriebsart Mode-Change
<pre>attr HT.JOHN scnProcessByDesiChange 0</pre>
* wir können 0..n ShutterContacts definieren, getrennt durch Komma
<pre>attr HT.JOHN scnShutterList SHUTTER.JOHN,SHUTTER.BRENNER</pre>
* verbose liefert ausführliche Infos im Logger
<pre>attr HT.JOHN verbose 4</pre>

=== Attribute Thermostat===
{| class="wikitable sortable"
|-
! Parameter !! Wertebereich !! Default !! Beschreibung
|-
|scanTemp||[0,1]||0||wenn 1, wird das Thermostat vom Scanner berücksichtigt
|-
|scnProcessByDesiChange||[0,1]||0||wenn 1, wird das Thermostat über die Änderung von desiredTemperature (DesiredChange) getriggert, ansonsten über die Änderung des Modes (ModeChange)
|-
|scnModeHandling||[NOCHANGE,AUTO,MANUAL]||AUTO|||wenn scnProcessByDesiChange aktiviert ist, kann man hier entscheiden, wie mit dem MODE verfahren werden soll. Wenn AUTO, wird der Scanner immer den Mode "auto" vorgeben, wenn MANUAL, den Mode "manual" sobald der Sollwert zum
Thermostat geschrieben wird. Ist hingegen NOCHANGE gewählt, so wird der aktuelle am Thermostat angewählte Mode belassen.
|-
|scnShutterList||||||Liste von assoziierten Max-Fensterkontakten (ShutterContacts), die durch ein Komma getrennt werden.
Der Scanner benötigt diese, um ein geöffnetes Fenster umgehend zu erkennen. Er erkennt ein offenes Fenster auch ohne Fensterkontakt, wenn gilt "aktueller Sollwert" = WindowOpenTemperature. Das Thermostat geht nach erkanntem Temperaturabfall auf diesen Wert.

|}
=== Attribute Scanner===
{| class="wikitable sortable"
|-
! Parameter !! Wertebereich !! Default !! Beschreibung
|-
|disable||[0,1]||0|| wenn 1, dann wird der Scanner gesperrt und ist somit inaktiv.
|-
|scnCreditThreshold||[150..600]||300|| die Mindestanzahl von verfügbaren Credits, ab der der Scanner mit dem Triggern der Thermostate beginnt
|-
|scnMinInterval||[3..60]||3|| die Mindestwartezeit in Minuten, nach der der Scanner ein Thermostate erneut triggert; diese wird nur berücksichtigt, wenn sie höher ist, als die berechnete Wartezeit, die sich aus der Anzahl der Thermostate ergibt.
|-
|}

=== Background ===

==== Hilfe zur Diagnose der Abläufe ====
Ein wichtiges Hilfsmittel ist der Event-Monitor. Mit der Filter-Einstellung "MAX.*" werden nur noch die MAX-relevanten Events dargestellt.

Interpretation der Ausgabe:<br/>
<pre>
2016-01-06 21:24:43 MAX HT.BAD desiredTemperature auto 20.0 <-- Triggern des Thermostats durch Scanner

2016-01-06 21:24:50 MAX HT.BAD mode: auto --> Rückmeldung vom Thermostat
2016-01-06 21:24:50 MAX HT.BAD RSSI: -54 --> Rückmeldung vom Thermostat
2016-01-06 21:24:56 MAX HT.BAD temperature: 20.2 --> Rückmeldung vom Thermostat
</pre>

Hier erscheinen also die zu Thermostat gesendeten Informationen ebenso, wie die empfangenen.
Empfangene Informationen sind meist mit einem ":" gekennzeichnet.

[[Kategorie:MAX]]

Raspberry Pi 3: GPIO-Port Module und Bluetooth

2017-01-27T15:18:50Z

Mahowi: RaspBee hinzugefügt

__NOTOC__
Der Raspberry Pi 3 nutzt für den GPIO-Port standardmäßig den UART1 (ttyS0), während die vorherigen Raspberry Pi-Modelle noch den UART0 dafür verwendeten. Der UART0 (ttyAMA0) wird beim Pi 3 durch das neu eingeführte Bluetooth-Modul softwaremäßig belegt. Der UART1 des Pi 3 mit Anhängigkeiten von CPU-Frequenz, CPU-Last, Temperatur und anderem ist für den Betrieb von Aufsteckmodulen jedoch häufig nicht stabil genug. Der Pi 3 muss daher zur Verwendung von einigen Aufsteckmodulen für den GPIO-Port, die über GPIO 14/15 kommunizieren so umkonfiguriert werden, dass der GPIO-Port wie bei den Vorgängermodellen wieder den UART0 einsetzt.

Unter anderem folgende Aufsteckmodule setzen für einen stabilen Betrieb die Nutzung des UART0 für den GPIO-Port voraus:
* EnOceanPi ([[:Kategorie:EnOcean Components|EnOcean]]-Gateway)
* Razberry ([[:Kategorie:Z-Wave Components|ZWave]]-Gateway)
* RaspBee ([[:Kategorie:ZigBee Components|ZigBee]]-Gateway)

Immer wieder angeführte und einfach umzusetzende Lösung ist Bluetooth zu deaktivieren und dann den UART0 (ttyAMA0) auf den GPIO-Port umzumappen (siehe beispielsweise {{Link2Forum|Topic=52161|Message=439757}}). Damit kann man aber das im Pi 3 eingebaute Bluetooth-Modul nicht mehr nutzen. Ein Vorteil des Pi 3 zu den Vorgängermodellen geht somit verloren.

{{Link2FU|14179|robert.heinze}} hat aufbauend auf seinen Erkenntnissen in diesem {{Link2Forum|Topic=51112}} nachfolgendes HowTo zur Verfügung gestellt,
nach dessen Abarbeitung eine parallele Verwendung von Aufsteckmodulen für den GPIO-Port und Bluetooth in FHEM mit dem Pi 3 möglich ist.

== HowTo ==
Standardmäßig belegt der Raspberry 3 den Software-UART-ttyAMA0 mit Bluetooth. Da wir diese Schnittstelle aber für serielle Module wie z.B. hier den EnOceanPi verwenden, legen wir den integrierten Bluetooth-Empfänger des Raspberry Pi 3 auf ttyS0 (UART1 - „mini UART“) um den Hardware-UART auf die TX/RX-Pins zu legen (UART0 - „full UART“). Hierfür sind einige Maßnahmen vorzunehmen, die nachfolgend schrittweise beschrieben werden.

=== Schritt 1: ===
Im ersten Schritt gilt es den Raspberry Pi 3 zu konfigurieren:

<source lang="bash">
sudo raspi-config
</source>

A7 Serial auf enabled setzen

=== Schritt 2: ===
Zur Bearbeitung von Textdateien wird hier und bei allen folgenden Schritten der Editor nano genutzt. Selbstverständlich kann auch auf einen anderen Editor zurückgegriffen werden.
<source lang="bash">
sudo nano /boot/cmdline.txt
</source>
Diese Zeile suchen:
dwc_otg.lpm_enable=0 console=tty1 root=/dev/mmcblk0p2 rootfstype=ext4 elevator=deadline fsck.repair=yes rootwait
und editieren. Der Eintrag <code>console=serial0,115200</code> sollte wie schon beim RPi2 entfernt werden, wenn es gesetzt ist, damit die UART-Schnittstelle von Zusatzmodulen wie EnOceanPi verwendet werden kann. Der genaue Inhalt der Zeile kann sich je nach System unterscheiden.

=== Schritt 3: ===
Raspberry auf aktuellen Stand bringen:
<source lang="bash">
sudo apt-get update
sudo apt-get upgrade
</source>

=== Schritt 4: ===
Firmware aktualisieren:
<source lang="bash">
sudo apt-get install rpi-update
sudo rpi-update
sudo reboot
</source>

=== Schritt 5: ===
In der Config-Datei /boot/config.txt wird das dementsprechende Overlay geladen, um Bluetooth auf mini UART zu legen:

dtoverlay=pi3-miniuart-bt

Die Taktfrequenz muss beim Starten auf eine konstante Frequenz eingestellt werden:

enable_uart=1

UART1 wird auf die Maximalfrequenz oder Minimalfrequenz gelegt, da der mini UART die Baudrate abhängig von der System Clock variiert:
force_turbo=1 oder core_freq=250, wir entscheiden uns für force_turbo=1 sofern ein dementsprechendes Netzteil (2,5A) verwendet wird.

<source lang="bash">
sudo nano /boot/config.txt
</source>
Am Ende der Datei einfach die folgenden Zeilen hinzufügen:

dtoverlay=pi3-miniuart-bt
enable_uart=1
force_turbo=1

=== Schritt 6: ===
Der Bluetooth UART-Service muss auf ttyS0 gelegt werden. Dies Sollte nach Mai 2016 nicht mehr notwendig sein! Inhalt der Datei hciuart.service genau vergleichen!

<source lang="bash">
sudo nano /lib/systemd/system/hciuart.service
</source>

In der Datei 2x ttyAMA0 gegen ttyS0 (oder alternativ /dev/serial1) tauschen, was in folgendem Code resultiert:

<pre>
[Unit]
Description=Configure Bluetooth Modems connected by UART
ConditionPathIsDirectory=/proc/device-tree/soc/gpio@7e200000/bt_pins
Before=bluetooth.service
After=dev-ttyS0.device

[Service]
Type=forking
ExecStart=/usr/bin/hciattach /dev/ttyS0 bcm43xx 921600 noflow -

[Install]
WantedBy=multi-user.target
</pre>

=== Schritt 7: ===
Auf Grund eines Timing-Problems in der Boot-Phase zwischen Bluetooth und dem FHEM Start muss der FHEM-Service 10 Sekunden verzögert werden.
<source lang="bash">
sudo nano /etc/init.d/fhem
</source>

In der ersten Zeile der Datei
sleep 10
einfügen.

Nun sollten nach einem Reboot das GPIO-Port-Aufsteckmodul (ttyAMA0) und Raspi 3-Bluetooth (ttyS0) parallel funktionieren.

=== Schritt 8 (optional) ===
Wenn Bluetooth noch nicht installiert wurde, muss es noch installiert werden.

<source lang="bash">
sudo apt-get install pi-bluetooth
</source>

[[Kategorie:HOWTOS]]
[[Kategorie:Raspberry Pi]]

Diskussion:MAX

2017-01-21T13:50:06Z

Mahowi: /* Associate zwischen WT und HT */

Hallo zusammen,

so wie es aussieht, funktioniert die gplot Datei nicht mehr (warum auch immer). Ich versuche mal, eine neue zu bauen und werde Sie hier einstellen.

Gruß PeMue

== MAX! Komponenten ==
Sollte dies nicht eigentlich der Grundlagenartikel sein und die einzelnen Hardwarekomponenten eigene Artikel haben ähnlich wie die Struktur im Homematik-Bereich des Wikis angelegt ist?

Ich besitze keine MAX!-Komponenten würde aber die Artikel anlegen und hier herausnehmen, wenn niemand dagegen spricht. Kommt erstmal auf meine ToDo-Liste, und ich frage vorher im Forum und/oder bei den Autoren nach... --[[Benutzer:Krokofant|Krokofant]] ([[Benutzer Diskussion:Krokofant|Diskussion]]) 13:11, 5. Dez. 2016 (CET)
<hr />
:Ich würde jetzt hier nicht unbedingt eine Aufteilung in Einzelartikel erzwingen. Wenn jemand ein einzelnes Gerät genauer beschreiben will (z.B. weil er es besitzt), kann das gern ein eigener Artikel werden. Derzeit sehe ich den Bedarf nicht - und MAX! ist auch bei weitem nicht so komplex wie HomeMatic. --[[Benutzer:Ph1959de|Peter]] ([[Benutzer Diskussion:Ph1959de|Diskussion]]) 16:36, 5. Dez. 2016 (CET)
:: Stimmt schon. Ich versuche immer in Wikis eine einheitliche Struktur zu finden und diese dann fortzuschreiben. Und beim Komponentenkauf hätte ich jetzt fast übersehen, dass es den MAX!-Eco-Taster (in fhem) überhaupt gibt, weil er hier nur im Sammelartikel vorkommt. Wie wäre es denn mit <nowiki>#REDIRECT</nowiki>-Artikeln zum entsprechenden Abschnitt im Sammelartikel? --[[Benutzer:Krokofant|Krokofant]] ([[Benutzer Diskussion:Krokofant|Diskussion]]) 19:53, 7. Dez. 2016 (CET)

== Codeschnipsel für HomeMatic-Fenster im MAX-Artikel ==
Hier [[MAX#Telegram-Benachrichtigung_bei_dauerge.C3.B6ffnetem_Fenster]] wurden Code-Anpassungen für HomeMatic-Fensterkontakt mit dem Hinweis aufgenommen, dass der HomeMatic-Fensterkontakt baugleich zum MAX-Fensterkontakt ist. Das ist meiner Meinung nach nicht so. Einen MAX-Fensterkontakt kann ich nicht mit HomeMatic-Protokoll ansprechen und umgekehrt. Daher ist die Ergänzung in diesem Artikel deplaziert und falsch. Zudem verwirrt dies. Plane daher das rückgängig zu machen und erbitte Kommentare.
Gruß, --[[Benutzer:Krikan|Christian]] ([[Benutzer Diskussion:Krikan|Diskussion]]) 12:29, 21. Jan. 2017 (CET)
<hr />
:Hallo Christian - ist mir mit genau den gleichen Gedanken aufgefallen. Sollte da keine Erklärung / Erläuterung kommen, bin ich auch für "revert". --[[Benutzer:Ph1959de|Peter]] ([[Benutzer Diskussion:Ph1959de|Diskussion]]) 12:43, 21. Jan. 2017 (CET)
::Ersteller der Änderung ist per PM informiert. --[[Benutzer:Krikan|Christian]] ([[Benutzer Diskussion:Krikan|Diskussion]]) 12:52, 21. Jan. 2017 (CET)
<hr />
: Hallo, ich habe die Änderung gemacht. Ist der Status bei wirklich "opened" oder auch "open"? In letzterem Fall - hier geht es ja nur um den Watchdog! - ist meine Ergänzung natürlich überflüssig. Der Watchdog funktioniert natürlich unabhängig ob es MAX oder Homematic ist. Zum Thema baugleich: Sollte der Status bei MAX "opened" sein, schlage ich vor, dass ich es in "optisch ähnlich" ändere, das wollte ich ausdrücken. 13:55, 21.01.2017

== Associate zwischen WT und HT ==

'''''Wer also via FHEM die desiredTemperature an den Wandthermostaten sendet, verändert damit weder direkt noch indirekt die Einstellung der assoziierten Heizkörper, sondern muss auch an diese Heizkörper senden.'''''

Das stimmt so nicht. Wenn ich in fhem die Temperatur am WT ändere wird das auch an die HTs weiter gegeben. Hat das mal irgendwann nicht funktioniert?
Wenn nichts dagegen spricht würde ich das sonst löschen.
--[[Benutzer:Mahowi|mahowi]] ([[Benutzer Diskussion:Mahowi|Diskussion]]) 14:26, 21. Jan. 2017 (CET)

Benutzer:Mahowi

2017-01-21T13:44:45Z

Mahowi: Die Seite wurde neu angelegt: „Mein Profil im Forum: {{Link2FU|11787|mahowi}}“

Mein Profil im Forum: {{Link2FU|11787|mahowi}}

Diskussion:MAX

2017-01-21T13:27:16Z

Mahowi:

Hallo zusammen,

so wie es aussieht, funktioniert die gplot Datei nicht mehr (warum auch immer). Ich versuche mal, eine neue zu bauen und werde Sie hier einstellen.

Gruß PeMue

== MAX! Komponenten ==
Sollte dies nicht eigentlich der Grundlagenartikel sein und die einzelnen Hardwarekomponenten eigene Artikel haben ähnlich wie die Struktur im Homematik-Bereich des Wikis angelegt ist?

Ich besitze keine MAX!-Komponenten würde aber die Artikel anlegen und hier herausnehmen, wenn niemand dagegen spricht. Kommt erstmal auf meine ToDo-Liste, und ich frage vorher im Forum und/oder bei den Autoren nach... --[[Benutzer:Krokofant|Krokofant]] ([[Benutzer Diskussion:Krokofant|Diskussion]]) 13:11, 5. Dez. 2016 (CET)
<hr />
:Ich würde jetzt hier nicht unbedingt eine Aufteilung in Einzelartikel erzwingen. Wenn jemand ein einzelnes Gerät genauer beschreiben will (z.B. weil er es besitzt), kann das gern ein eigener Artikel werden. Derzeit sehe ich den Bedarf nicht - und MAX! ist auch bei weitem nicht so komplex wie HomeMatic. --[[Benutzer:Ph1959de|Peter]] ([[Benutzer Diskussion:Ph1959de|Diskussion]]) 16:36, 5. Dez. 2016 (CET)
:: Stimmt schon. Ich versuche immer in Wikis eine einheitliche Struktur zu finden und diese dann fortzuschreiben. Und beim Komponentenkauf hätte ich jetzt fast übersehen, dass es den MAX!-Eco-Taster (in fhem) überhaupt gibt, weil er hier nur im Sammelartikel vorkommt. Wie wäre es denn mit <nowiki>#REDIRECT</nowiki>-Artikeln zum entsprechenden Abschnitt im Sammelartikel? --[[Benutzer:Krokofant|Krokofant]] ([[Benutzer Diskussion:Krokofant|Diskussion]]) 19:53, 7. Dez. 2016 (CET)

== Codeschnipsel für HomeMatic-Fenster im MAX-Artikel ==
Hier [[MAX#Telegram-Benachrichtigung_bei_dauerge.C3.B6ffnetem_Fenster]] wurden Code-Anpassungen für HomeMatic-Fensterkontakt mit dem Hinweis aufgenommen, dass der HomeMatic-Fensterkontakt baugleich zum MAX-Fensterkontakt ist. Das ist meiner Meinung nach nicht so. Einen MAX-Fensterkontakt kann ich nicht mit HomeMatic-Protokoll ansprechen und umgekehrt. Daher ist die Ergänzung in diesem Artikel deplaziert und falsch. Zudem verwirrt dies. Plane daher das rückgängig zu machen und erbitte Kommentare.
Gruß, --[[Benutzer:Krikan|Christian]] ([[Benutzer Diskussion:Krikan|Diskussion]]) 12:29, 21. Jan. 2017 (CET)
<hr />
:Hallo Christian - ist mir mit genau den gleichen Gedanken aufgefallen. Sollte da keine Erklärung / Erläuterung kommen, bin ich auch für "revert". --[[Benutzer:Ph1959de|Peter]] ([[Benutzer Diskussion:Ph1959de|Diskussion]]) 12:43, 21. Jan. 2017 (CET)
::Ersteller der Änderung ist per PM informiert. --[[Benutzer:Krikan|Christian]] ([[Benutzer Diskussion:Krikan|Diskussion]]) 12:52, 21. Jan. 2017 (CET)
<hr />
: Hallo, ich habe die Änderung gemacht. Ist der Status bei wirklich "opened" oder auch "open"? In letzterem Fall - hier geht es ja nur um den Watchdog! - ist meine Ergänzung natürlich überflüssig. Der Watchdog funktioniert natürlich unabhängig ob es MAX oder Homematic ist. Zum Thema baugleich: Sollte der Status bei MAX "opened" sein, schlage ich vor, dass ich es in "optisch ähnlich" ändere, das wollte ich ausdrücken. 13:55, 21.01.2017

== Associate zwischen WT und HT ==

"Wer also via FHEM die desiredTemperature an den Wandthermostaten sendet, verändert damit weder direkt noch indirekt die Einstellung der assoziierten Heizkörper, sondern muss auch an diese Heizkörper senden."

Das stimmt so nicht. Wenn ich in fhem die Temperatur am WT ändere wird das auch an die HTs weiter gegeben. Hat das mal irgendwann nicht funktioniert?
Wenn nichts dagegen spricht würde ich das sonst löschen.
--[[Benutzer:Mahowi|mahowi]] ([[Benutzer Diskussion:Mahowi|Diskussion]]) 14:26, 21. Jan. 2017 (CET)

Diskussion:MAX

2017-01-21T13:25:02Z

Mahowi: Neuer Abschnitt /* Associate zwischen WT und HT */

Hallo zusammen,

so wie es aussieht, funktioniert die gplot Datei nicht mehr (warum auch immer). Ich versuche mal, eine neue zu bauen und werde Sie hier einstellen.

Gruß PeMue

== MAX! Komponenten ==
Sollte dies nicht eigentlich der Grundlagenartikel sein und die einzelnen Hardwarekomponenten eigene Artikel haben ähnlich wie die Struktur im Homematik-Bereich des Wikis angelegt ist?

Ich besitze keine MAX!-Komponenten würde aber die Artikel anlegen und hier herausnehmen, wenn niemand dagegen spricht. Kommt erstmal auf meine ToDo-Liste, und ich frage vorher im Forum und/oder bei den Autoren nach... --[[Benutzer:Krokofant|Krokofant]] ([[Benutzer Diskussion:Krokofant|Diskussion]]) 13:11, 5. Dez. 2016 (CET)
<hr />
:Ich würde jetzt hier nicht unbedingt eine Aufteilung in Einzelartikel erzwingen. Wenn jemand ein einzelnes Gerät genauer beschreiben will (z.B. weil er es besitzt), kann das gern ein eigener Artikel werden. Derzeit sehe ich den Bedarf nicht - und MAX! ist auch bei weitem nicht so komplex wie HomeMatic. --[[Benutzer:Ph1959de|Peter]] ([[Benutzer Diskussion:Ph1959de|Diskussion]]) 16:36, 5. Dez. 2016 (CET)
:: Stimmt schon. Ich versuche immer in Wikis eine einheitliche Struktur zu finden und diese dann fortzuschreiben. Und beim Komponentenkauf hätte ich jetzt fast übersehen, dass es den MAX!-Eco-Taster (in fhem) überhaupt gibt, weil er hier nur im Sammelartikel vorkommt. Wie wäre es denn mit <nowiki>#REDIRECT</nowiki>-Artikeln zum entsprechenden Abschnitt im Sammelartikel? --[[Benutzer:Krokofant|Krokofant]] ([[Benutzer Diskussion:Krokofant|Diskussion]]) 19:53, 7. Dez. 2016 (CET)

== Codeschnipsel für HomeMatic-Fenster im MAX-Artikel ==
Hier [[MAX#Telegram-Benachrichtigung_bei_dauerge.C3.B6ffnetem_Fenster]] wurden Code-Anpassungen für HomeMatic-Fensterkontakt mit dem Hinweis aufgenommen, dass der HomeMatic-Fensterkontakt baugleich zum MAX-Fensterkontakt ist. Das ist meiner Meinung nach nicht so. Einen MAX-Fensterkontakt kann ich nicht mit HomeMatic-Protokoll ansprechen und umgekehrt. Daher ist die Ergänzung in diesem Artikel deplaziert und falsch. Zudem verwirrt dies. Plane daher das rückgängig zu machen und erbitte Kommentare.
Gruß, --[[Benutzer:Krikan|Christian]] ([[Benutzer Diskussion:Krikan|Diskussion]]) 12:29, 21. Jan. 2017 (CET)
<hr />
:Hallo Christian - ist mir mit genau den gleichen Gedanken aufgefallen. Sollte da keine Erklärung / Erläuterung kommen, bin ich auch für "revert". --[[Benutzer:Ph1959de|Peter]] ([[Benutzer Diskussion:Ph1959de|Diskussion]]) 12:43, 21. Jan. 2017 (CET)
::Ersteller der Änderung ist per PM informiert. --[[Benutzer:Krikan|Christian]] ([[Benutzer Diskussion:Krikan|Diskussion]]) 12:52, 21. Jan. 2017 (CET)
<hr />
: Hallo, ich habe die Änderung gemacht. Ist der Status bei wirklich "opened" oder auch "open"? In letzterem Fall - hier geht es ja nur um den Watchdog! - ist meine Ergänzung natürlich überflüssig. Der Watchdog funktioniert natürlich unabhängig ob es MAX oder Homematic ist. Zum Thema baugleich: Sollte der Status bei MAX "opened" sein, schlage ich vor, dass ich es in "optisch ähnlich" ändere, das wollte ich ausdrücken. 13:55, 21.01.2017

== Associate zwischen WT und HT ==

"Wer also via FHEM die desiredTemperature an den Wandthermostaten sendet, verändert damit weder direkt noch indirekt die Einstellung der assoziierten Heizkörper, sondern muss auch an diese Heizkörper senden."

Das stimmt so nicht. Wenn ich in fhem die Temperatur am WT ändere wird das auch an die HTs weiter gegeben. Hat das mal irgendwann nicht funktioniert?
Wenn nichts dagegen spricht würde ich das sonst löschen.

LaCrosse

2017-01-19T07:45:36Z

Mahowi: /* Voraussetzungen */ Link zur Firmware

{{Infobox Modul
|ModPurpose=Unterstützung von La Crosse Sensoren
|ModType=d
|ModCmdRef=LaCrosse
|ModForumArea=Sonstige Systeme
|ModTechName=36_LaCrosse.pm
|ModOwner=HCS ({{Link2FU|6609|Forum}}) }}
Das Modul [[LaCrosse]] unterstützt [https://www.lacrossetechnology.com/sensors.php La Crosse] Temperatur- und (Luft)Feuchtesensoren und Wetterstationen wie die WS 1600 (TX22 Sensoren).

== Voraussetzungen ==
Um ''LaCrosse''-Geräte nutzen zu können, wird ein [[JeeLink]] [[Interface]] oder ein [[LaCrosseGateway]] als IODevice benötigt, auf dem der LaCrosse Sketch ([https://svn.fhem.de/trac/export/HEAD/trunk/fhem/contrib/arduino/36_LaCrosse-LaCrosseITPlusReader.zip Download]) installiert ist.

== Anwendung ==
Neue Sensoren werden nur automatisch angelegt, wenn ''LaCrossePairForSec'' auf dem IODevice aktiviert ist.

=== Define ===
Die Syntax für das manuelle Anlegen eines Sensors ist der commandref zu entnehmen.

=== Attribute ===

== Anwendungsbeispiele ==
Unterstützte Geräte werden im Abschnitt "[[JeeLink#Unterst.C3.BCtzte_Sensoren_und_Aktoren_incl._Wetterstation_WS_1600|Unterstützte Sensoren und Aktoren]]" im Artikel zum JeeLink aufgeführt.

== Links ==
* ...

[[Kategorie:Temperatursensoren]]
[[Kategorie:Feuchtesensoren]]
[[Kategorie:Wetterstationen]]

LaCrosse

2017-01-19T07:31:26Z

Mahowi: /* Anwendungsbeispiele */ Verweis auf unterstützte Geräte im JeeLink-Artikel

{{Infobox Modul
|ModPurpose=Unterstützung von La Crosse Sensoren
|ModType=d
|ModCmdRef=LaCrosse
|ModForumArea=Sonstige Systeme
|ModTechName=36_LaCrosse.pm
|ModOwner=HCS ({{Link2FU|6609|Forum}}) }}
Das Modul [[LaCrosse]] unterstützt [https://www.lacrossetechnology.com/sensors.php La Crosse] Temperatur- und (Luft)Feuchtesensoren und Wetterstationen wie die WS 1600 (TX22 Sensoren).

== Voraussetzungen ==
Um ''LaCrosse''-Geräte nutzen zu können, wird ein [[JeeLink]] [[Interface]] oder ein [[LaCrosseGateway]] als IODevice benötigt, auf dem der LaCrosse Sketch installiert ist.

== Anwendung ==
Neue Sensoren werden nur automatisch angelegt, wenn ''LaCrossePairForSec'' auf dem IODevice aktiviert ist.

=== Define ===
Die Syntax für das manuelle Anlegen eines Sensors ist der commandref zu entnehmen.

=== Attribute ===

== Anwendungsbeispiele ==
Unterstützte Geräte werden im Abschnitt "[[JeeLink#Unterst.C3.BCtzte_Sensoren_und_Aktoren_incl._Wetterstation_WS_1600|Unterstützte Sensoren und Aktoren]]" im Artikel zum JeeLink aufgeführt.

== Links ==
* ...

[[Kategorie:Temperatursensoren]]
[[Kategorie:Feuchtesensoren]]
[[Kategorie:Wetterstationen]]

LaCrosseGateway V1.x

2017-01-18T18:51:29Z

Mahowi: /* Unterstützte Sensoren und Aktoren */ Verweis auf die Liste der vom JeeLink unterstützen Sensoren und Aktoren, so daß die Liste nicht doppelt geführt werden muß

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

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 />[https://forum.fhem.de/index.php/topic,45594.msg430183.html#msg430183 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)
*Steckbrett (inkl. Kabel/Widerstände)/Lochrasterplatine (Lötkolben, Lötzinn, Widerstände etc.)) / [[#Platine|PeMue Platine]]

==Schaltung==
===Variante: Devkit 1.0===
[[Datei:lgw_Schaltplan_Devkit.png|400px|thumb|left|Variante: Devkit 1.0]]
<div style="clear:both;"></div>
===Variante: ESP8266-12E===
[[Datei:lgw_Schaltplan_FTDI.png|400px|thumb|left|Variante: FTDI]]
<div style="clear:both;"></div>
===Variante: Platine (PeMue)===
[[Datei:lgw_Schaltplan_Platine.png|400px|thumb|left|Variante: Platine (PeMue)]]
<div style="clear:both;"></div>
===Addon Schaltung===
[[Datei:lgw_Addon-with-example.png|400px|thumb|left|Die Schaltung des kompletten AddOn mit allen aktuell möglichen Optionen]]
<div style="clear:both;"></div>
Siehe [[#Erweiterungsmöglichkeiten | Erweiterungsmöglichkeiten]].
===MCP2308===
I2C Adresse 0x27 -> A0,A1,A2 = 3.3V
<source 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
|----------------|</source>

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

'''''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:
<source 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</source>

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

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

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

'''LaCrosse:'''

Format:<source lang="php">LC <Address> T=<Temperature>,H=<Humidity></source>
Beispiel:
<source lang="php">LC 9F T=21.5,H=62</source>
<source lang="php">LC 9F T=21.5</source>
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||

|}

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)

==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:
<source lang="php">
esptool -vv -cp [Port] -cb 921600 -ca 0x00000 -cd nodemcu -cf [Pfad zur Firmware (bin-File)]</source>
'''[Port]''' und '''[Pfad zur Firmware (bin-File)]''' müssen angepasst werden.

''Beispiel (Mac/Linux):''

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

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

===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
<source lang="php">set myLaCrosseGateway flash</source> aktualisiert werden.
'''''myLaCrosseGateway''' muss bei Bedarf auf den Gerätenamen in FHEM angepasst werden.''

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

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

'''''Beispiel:'''''
<source 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</source>

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

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

Beispiel:
<source 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></source>

===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:
<source lang="php">http://<LGW-IP>/getLogData</source>

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

das Ergebnis sieht wie folgt aus:
<source 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</source>

'''''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:
<source lang="php">sudo apt-get install libwww-perl</source>
alternativ auch mit
<source lang="php">sudo cpan LWP::UserAgent</source>

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

==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:'''
<source lang="php">define myLaCrosseGateway LaCrosseGateway 192.168.22.33:81</source>
<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:
<source 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</source>
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:
<source 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;</source>

==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:
<source lang="php">attr myLaCrosseGateway timeout 120,30</source>
'''''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]

<source 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
</source>

==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: <source lang="php">8266e</source>
Er kann mit einem Terminalprogramm, von FHEM aus mit <source lang="php">set <myLaCrosseGateway> raw 8266e</source> 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.
<source lang="php">set myLaCrosseGateway LaCrossePairForSec 120 ignore_battery</source>

==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:
<source lang="php">set myLaCrosseGateway LaCrossePairForSec 120 ignore_battery</source>

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.
<source lang="php">define <name> LaCrosse 00</source>
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.''
<source lang="php">attr myLaCrosseGateway initCommands 220h</source>

'''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:'''
<source 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
</source>

==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:
<source lang="php">
#1 (Erste) => 17241
#2 (Zweite) => 9579
#3 (Dritte) => 8842
#4 (Vierte) => 20000
#5 (Fünfte) => 17241
</source>

'''''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
|-
| <source lang="php">attr myLaCrosseGateway initCommands 0#1r v</source>
| DataRate des ersten RFM setzen
|-
| <source lang="php">attr myLaCrosseGateway initCommands 8842#3r v </source>
| DataRate des dritten RFM setzen
|-
| <source lang="php">attr myLaCrosseGateway initCommands 868300#2f v</source>
| Frequenz des zweiten RFM setzten
|-
| <source lang="php">attr myLaCrosseGateway initCommands 868295#3f v</source>
| Frequenz des dritten RFM setzten
|-
| <source lang="php">attr myLaCrosseGateway initCommands 17241#1r 8842#2r v</source>
| Zwei RFM69CW mit DataRate 17241 und 8842
|-
| <source lang="php">attr myLaCrosseGateway initCommands 3#1m 20#1t 8842#2r v</source>
| Zwei RFM69CW mit 20 Sekunden DataRate 17241 toggle 9579 plus 8842 permanent
|-
| <source lang="php">attr myLaCrosseGateway initCommands 220h 868295#1f 868310#2f v</source>
| Zwei RFMs Frequenz 868295 und 868310 sowie Höhe über NN
|-
| <source lang="php">attr myLaCrosseGateway initCommands 868295#1f 3#1m 20#1t 2,868950,60i 8842#3r 220h 0a v</source>
| 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:'''
<source lang="php">attr myLaCrosseGateway initCommands 9#2m 20#2t v</source>

==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''
<source lang="php">OK VALUES LGPB 211 GP2=0,GP3=1,GP4=0,GP5=0,GP6=0,GP7=0</source>

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

==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.
Um auf dem 1.3" Display eine korrekte Darstellung zu erhalten, muss man die Checkbox 1.3" ankreuzen.

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

==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):
<source lang="php">define CULXYZ CUL <IP-Adresse>:85 0000</source>
'''''<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:

<source 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");;\
}\
\
} </source>
'''''<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''
<source lang="php">./esptool -vv -cp /dev/tty.SLAB_USBtoUART -cb 115200 -ca 0x00000 -cd nodemcu -ce</source>

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

=Weiterführende Links=
Diskussionsthread aus dem Forum:

[https://forum.fhem.de/index.php/topic,43672.0.html LaCrosseGateway - LaCrosse, PCA301 und EC3000 über wifi mit ESP8266 ohne Arduino]

[https://forum.fhem.de/index.php/topic,45594.0.html Platine für LaCrosseGateway: Platinenbestellung]

[https://forum.fhem.de/index.php/topic,51329.30.html Platine für nanoLGW (LaCrosse Gateway): Layout]

[https://forum.fhem.de/index.php/topic,52921.0.html Display für LaCrosseGateway]

[https://forum.fhem.de/index.php/topic,52895.0.html SC16IS750-Software-Clone]

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

JeeLink

2017-01-18T18:34:20Z

Mahowi: EMT7110 bereits in der Liste der vom LaCrosse-Sketch unterstützten Sensoren und Aktoren

'''JeeLink''' ist ein RF-Gerät im Formfaktor eines USB-Sticks mit externer Antenne.
{{Infobox Hardware
|Bild=JeeLink.jpg
|Bildbeschreibung=JeeLink mit Drahtantenne
|HWProtocol=PCA301, EC3000, RoomNode oder LaCrosse und EMT7110
|HWType=[[Interface]]
|HWCategory=
|HWComm=433/868/913 MHz
|HWChannels=?
|HWVoltage=5 V
|HWPowerConsumption=ca. 90 mA
|HWPoweredBy=USB
|HWSize=23*67*9mm
|HWDeviceFHEM=[http://fhem.de/commandref.html#JeeLink 36_JeeLink.pm]
|ModOwner={{Link2FU|430|Andre / justme1968}}
|HWManufacturer=JeeLabs
}}

== Beschreibung ==
Vergleichbar mit dem [[CUL]] von Busware, ist der JeeLink ein USB-Stick, mit dem Funk-Hausautomations-Komponenten angebunden werden können. CUL und JeeLink unterscheiden sich im Funkmodul (CUL -> CC1101; JeeLink -> RF12B), die nicht miteinander kompatibel sind. Daher kann man auch keinen CUL als JeeLink-Ersatz nutzen!

Den JeeLink gibt es in einer
* 433 MHz Version
* 868 MHz Version (Standard)
* 915 MHz Version (Betrieb in Europa nicht zugelassen)

== Vorbereitung JeeLink ==
Um mit dem JeeLink die jeweils gewünschten Signale empfangen zu können, ist er zunächst mit der passenden Firmware zu versorgen. Dies kann auf zwei Arten geschehen. Entweder durch das selber kompilieren der Software und das Flashen aus der Arduino IDE oder aus Fhem heraus mit einem aktuellen Firmwareimage das per update mit ausgeliefert wird.

=== Selber Kompilieren ===
[[Datei:JeeLink_flashen_1.jpg|mini|100px|rechts|Vorbereitung: Arduino einrichten]]
Um den JeeLink mit Fhem benutzen zu können, muss (mit der Arduino Software / Entwicklungsumgebung (IDE)) eine spezifische "Firmware" (ein Sketch) auf dem JeeLink installiert werden. Die generelle Vorbereitung für diese Aktion ist unabhängig vom benötigten Sketch und besteht aus den folgenden Schritten:
* Für Windows oder Mac OS X den passenden [http://www.ftdichip.com/Drivers/VCP.htm FTDI Treiber] installieren, unter Linux ist dieser meist schon vorhanden
* Installation der [http://arduino.cc/de/Guide/HomePage Arduino Software] für die benutzte Plattform (verfügbar sind Windows, Mac OS X und Linux)
* Je nach Sketch einbinden der [https://github.com/jcw/jeelib/archive/master.zip Jeelabs Library] in die Arduino IDE
* Herunterladen des benötigten Sketches (aus [https://svn.fhem.de/trac/browser/trunk/fhem/contrib/arduino FHEM/contrib])
* Anschließen des JeeLink an einen USB-Anschluss des Rechners mit der Arduino IDE
* Start der Arduino Software und JeeLink flashen

=== JeeLink aus Arduino flashen ===
[[Datei:JeeLink_flashen_2.jpg|mini|100px|rechts|JeeLink Flashen]]
* Anschließen des JeeLink an einen USB-Anschluss des Rechners mit der Arduino IDE
* Start der Arduino Software
* Seriellen Port des JeeLink auswählen
* Einstellungen: in den Tools als Board "Arduino Uno" auswählen
* Sketch mit "Datei öffnen" auswählen
* Upload klicken

=== JeeLink aus Fhem flashen ===
* Auf dem Fhem System muss <code>avrdude</code> installiert sein. Das kann z.B. über die "normale" Linux Paketverwaltung geschehen.
* mit <code>set <JeeLinkDevice> flash [firmware]</code> wird das Flashen angestossen<br><code>firmware</code> kann LaCrosse, PCA301 oder EC3000 sein. Wenn <code>firmware</code> nicht angegeben wird versucht FHEM den Namen der zu flashenden Firmware aus der zur Zeit installierten Firmware abzuleiten.
* im Fhem Log kann der Ausgang des Flashvorgangs kontrolliert werden
* über das <code>flashCommand</code> Attribut lässt sich das Kommando zum Flashen an besondere Anforderungen anpassen

'''Vorsicht bei Jeelink Clones!'''

Jeelink Clones basierend auf dem Arduino Nano haben normalerweise keinen Optibootloader drauf im Gegensatz zum Original JeeLink und JeeNode.

Konsequenz:

Beim "Nano Clone" und ähnliches muß man zum flashen in FHEM die Baudrate setzen mit "-b 57600"

Original JeeLink, original JeeNode, und alle Arduinos, die einen Optibootloader drauf haben flashen in FHEM ohne "-b 57600"

== Hinweise zum Betrieb mit Fhem ==
Um den JeeLink (erstmalig) mit Fhem benutzen zu können, muss dieser erfolgreich geflasht worden sein.
* JeeLink an den Fhem-Rechner anschließen
* Auf Linux Systemen kann es notwendig sein, mit <code>mknod /dev/ttyUSB0 c 188 0</code> das Device anzulegen (bitte erst überprüfen, ob der Stick nicht automatisch erkannt wird)

=== Definition in fhem.cfg ===
Erforderliche Definitionen in Fhem:
:<code>define myJeeLink JeeLink /dev/ttyUSBx@57600</code>
*'''USBx''' ist anzupassen an die aktuell benutzte Schnittstelle, 0 wenn sonst nichts am USB-Port hängt
*x=0,1,2, usw.

Die [http://fhem.de/commandref.html#autocreate autocreate-Funktion] sollte aktiv sein. Alle erkannten Devices (PCA301, LaCrosse Sensoren incl. IT+ Wetterstation WS1600, EMT7110, EC3000, und RoomNodes) werden dann automatisch angelegt, sobald die jeweiligen Daten empfangen werden.

Pro Geräte-Art/Protokoll muss ein eigener JeeLink mit dem passenden Sketch zum Empfang dieser Daten vorhanden sein (es kann jeweils nur ein Sketch im JeeLink aktiv sein und es gibt (zumindest derzeit (04/2014)) keinen Sketch, der mehr als eines der Protokolle abdeckt).

'''Anmerkung:''' Der LaCrosse Sketch deckt sowohl die LaCrosse Temperatursensoren, die IT+ Wetterstation WS1600 als auch den Energieverbrauchssensor EMT7110 ab.

=== PCA301 Sketch ===
Der Sketch für die Unterstützung der ''PCA301 Funkschaltsteckdose mit Energieverbrauchsmessung'' (PCA301-pcaSerial.zip) kann aus dem [https://svn.fhem.de/trac/browser/trunk/fhem/contrib/arduino/ FHEM-Repository] heruntergeladen werden. Details zur Benutzung finden sich im Artikel zur [[PCA301 Funkschaltsteckdose mit Energieverbrauchsmessung|PCA301]].

Unter Umständen werden die Signale der PCA301 nicht empfangen. Insbesondere mit selbst erstellten "JeeLinks" durch wahrscheinlich hohe Bauteiltoleranzen der RF12B Sendeeinheiten. Mit dem im Sketch voreingestellten rf12_center_freq = 0xA6FE (868,9500 MHz) bekommt man in diesem Fall keine Steckdose angelernt.

==== Frequenzanpassung über modifizierten Sketch ====
Durch Tests mittels ''set <myJeeLink> raw +'' bzw ''set <myJeeLink> raw -'' kann man dann ermitteln, ob die Funksignale z.B. ab A703 bis A715 empfangen werden. Das entspricht einem Frequenzbereich zwischen 868,9750 MHz und 869,0550 MHz.
Die Mitte ist die Lösung, die man dann im Sketch ändern muss:
:<code>static uint16_t rf12_center_freq = 0xA70C;</code>
Anschließend auf den JeeLink neu flashen.

==== Frequenzanpassung über Attribut initCommands ====
Über das <code>initCommands</code> lässt sich die gefundene Frequenz einstellen, ohne dass die Firmware verändert werden muss.
:<code>attr <JeeLinkDevice> initCommands <hhhh>h</code>

=== LaCrosse Sketch ===
Der Sketch für die Unterstützung der LaCrosse Temperatursensoren, der IT+ Wetterstation WS1600 und des Energieverbrauchssensors EMT7110 so wie auch TechnoLine Sensoren (Temperatur, Luftfeuchte,...).<br>

* Er kann aus dem [https://svn.fhem.de/trac/browser/trunk/fhem/contrib/arduino FHEM-Repository] heruntergeladen werden.
* Alternative ist den Sketch direkt über Fhem zu flashen <code>set <JeeLinkDevice> flash LaCrosse</code> z.B.: <code>set myJeeLink flash LaCrosse</code> zuvor sollte aber ein Fhem update mit <code>update</code> durchgeführt werden.
<br>

'''Sensoren anlernen:
Mit folgenden Befehl hat man die Möglichkeit 60 Sekunden ein Gerät anzulernen. Das Gerät erscheint dann unter der Rubrik LaCrosse. <code>set <JeeLinkDevice> LaCrossePairForSec 60</code> zum Beispiel: <code>set myJeeLink LaCrossePairForSec 60</code>.

'''In der neuesten Version unterstützt er auch den SuperJee''' (siehe auch diesen {{Link2Forum|Topic=14786|Message=316924|LinkText=Forenbeitrag}}) mit folgenden Optionen:

* Option 1 (Dual RFM):
:Es kann ein zweiter RFM12B oder RFM69CW angeschlossen werden. Somit können zwei data rates (z.B. 17241 für TX29DTH und 8842 für WS 1600) gleichzeitig empfangen werden. Das geht natürlich auch mit dem toggle mode, nur ist es bei der Wetterstation ärgerlich, wenn man 30 Sekunden lang nichts empfängt und dadurch die alles entscheidende Windböe verpasst.
* Option 2 (BMP180):
:Da der Luftdruck in den Basisstationen gemessen wird, steht er für FHEM nicht zur Verfügung.
Deshalb kann nun optional ein BMP180 oder BMP085 angeschlossen werden. Auch hier wird automatisch erkannt, ob er vorhanden ist.
:Der BMP180 wird mit 3,3V versorgt und SDA mit PC4 und SCL mit PC5 verbunden (siehe die in diesem {{Link2Forum|Topic=14786|Message=316924|LinkText=Forenbeitrag}} angehängte SuperJee-CL.png)

==== Übersicht Kommandos ====
<n>a set to 0 if the blue LED bothers
<n>f initial frequency in kHz (5 kHz steps, 860480 ... 879515) (for RFM #1)
<n>F initial frequency in kHz (5 kHz steps, 860480 ... 879515) (for RFM #2)
<n>h altituide above sea level
<n>m bits 1: 17.241 kbps, 2 : 9.579 kbps, 4 : 8.842 kbps (for RFM #1)
<n>M bits 1: 17.241 kbps, 2 : 9.579 kbps, 4 : 8.842 kbps (for RFM #2)
<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>t 0=no toggle, else interval in seconds (for RFM #1)
<n>T 0=no toggle, else interval in seconds (for RFM #2)
v show version
<n>y if 1 all received packets will be retransmitted (Relay mode)

==== Relay-Betrieb ====
Der LaCrosse Sketch ermöglicht auch den Relay-Betrieb zur Reichweitenverbesserung. Er funktioniert damit ähnlich wie z. B. ein WLAN Range Extender. Wenn der Sketch für den Relay-Betrieb konfiguriert ist, wird jedes empfangene IT+ Datenpaket, das eine gültige Prüfsumme hat, direkt nach dem Empfang wieder gesendet.

Das Prinzip ist generell recht einfach:
# JeeLink im Sketch als Relais konfigurieren und flashen.
# Auf "halber Strecke" (d.h. irgendwo zwischen dem primären Sender und dem entfernten Empfänger) auf ein USB-Steckernetzteil stecken. Der JeeLink arbeitet in diesem Modus "autonom", er benötigt also lediglich einen Spannungsversorgung.

Der JeeLink empfängt und decodiert alle Protokolle, die er auch für FHEM unterstützt. Wenn er ein Paket empfangen hat (egal von welchem Sensor) und CRC OK war, dann sendet er es wieder aus. Der JeeLink am FHEM merkt keinen Unterschied. Falls ein Paket es doch bis zum FHEM direkt geschafft hat, kommt es dort zweimal an. Diese Situation muss in Fhem behandelt werden.

Details zu diesem Betriebsmodus sind in diesen Forenbeiträgen ({{Link2Forum|Topic=14786|Message=165153|LinkText=LaCrosse}} bzw. {{Link2Forum|Topic=26494|Message=196648|LinkText=EMT7110}}) zu finden.

==== Frequenzanpassung ====
Ab Version LaCrosseITPlusReader.10.1e wurde der Sketch so erweitert, dass man von FHEM aus die Frequenz setzen kann. Dazu versteht der Sketch das neue Kommando "f":
:<code>set myJeeLink raw 868295f</code>
setzt die Frequenz auf 868295 kHz.

Die Frequenz kann im Bereich von 860480 kHz bis 879515 kHz in 5kHz -Schritten eingestellt werden.
Details dazu in diesem {{Link2Forum|Topic=14786|Message=222541}} im Forum. Die Frequenzanpassung ist insbesondere beim 30.3155.WD häufig erforderlich, weshalb er als kritisch einzustufen und nicht zu empfehlen ist (siehe {{Link2Forum|Topic=14786|Message=352550|LinkText=Forenbeitrag}}).

==== Toggle und Datenrate ====
Toggle
t: toggle time
20t = alle 20 Sekunden die Datenrate wechseln

Datenrate
m: toggle mode
bits: 1= 17.241 kbps, 2= 9.579 kbps, 4= 8.842 kbps
3m ist 17.241 kbps (TX29) und 9.579 kbps (TX35)

Beispiel initCommands
6m 30t v
Zwischen 8.842 kbps und 9.579 kbps wechseln (4+2=6), alle 30 Sekunden

==== Unterstützte Sensoren und Aktoren incl. Wetterstation WS 1600 ====
{{Randnotiz|RNTyp=y|RNText=Die Ausführungen in diesem Abschnitt gelten ab der Version 10.1q auch für die Wetterstation WS1080.

'''Wichtig WS1800''': die WS1080 gibt es (unter gleichem Namen) in einer "OOK"- und in einer "FSK"-Version.
* Der LaCrosse Sketch und das LaCrosseGateway können nur die FSK-Version empfangen, die OOK-Version wird nicht unterstützt.
* Die FSK-Version ist zu erkennen an einem runden grünen Aufkleber im Batteriefach der Station mit dem Aufdruck "PASS 7". Details dazu in {{Link2Forum|Topic=14786|Message=363766|LinkText=diesem Forenbeitrag}}
}}

Die in der folgenden Liste (Quelle: {{Link2Forum|Topic=14786|Message=164801|LinkText=Fhem Forum}}) aufgeführten Sensoren wurden bisher erfolgreich getestet:

{| class="wikitable"
!Bezeichnung !! Datenrate !! Link / Hinweise
|-
| TX21IT || 17.241 kbps ||
|-
| TX25-IT || 17.241 kbps ||
|-
| TX27-IT || 17.241 kbps ||
|-
| TX29-IT || 17.241 kbps ||
|-
| TX29DTH-IT || 17.241 kbps ||
|-
| TX37 || 17.241 kbps ||
|-
| TX35TH-IT || 9.579 kbps ||
|-
| TX35DTH-IT || 9.579 kbps ||
|-
| 30.3143.IT || 17.241 kbps ||
|-
| 30.3144.IT || 17.241 kbps || ({{Link2Forum|Topic=17662|LinkText=Forenthread}})
|-
| 30.3147.IT || 17.241 kbps ||
|-
| 30.3155WD || 9.579 kbps || kritisch; nicht zu empfehlen; siehe {{Link2Forum|Topic=14786|Message=352550|LinkText=Forenbeitrag}}
|-
| 30.3156WD || 9.579 kbps || Batterie-kritisch. Funktioniert schlecht mit Akkus!
|-
| 30.3187.IT || 17.241 kbps || haben alle die gleiche ID, daher nur einzeln verwendbar ({{Link2Forum|Topic=64636|LinkText=Forenthread}})
|-
| WT440XH || 17.241 kbps ||
|-
| WS 1600 (TX22) || 8.842 kbps || ({{Link2Forum|Topic=14786|Message=297293|LinkText=Forenbeitrag}})
|-
| WS 1080 || 17.241 kbps || Bitte Hinweise beachten! ({{Link2Forum|Topic=14786|Message=363766|LinkText=Forenbeitrag}})
|-
| [[EMT7110]] || 9.579 kbps || ({{Link2Forum|Topic=26494|LinkText=Forenthread}})
|-
| LevelSender || 17.241 kbps || ({{Link2Forum|Topic=23217|LinkText=Forenthread}})

|}

Werden Sensoren mit unterschiedlichen Datenraten gleichzeitig betrieben, ist der Toggle Modus einzustellen, z.B. mit dem Befehl
:<code>initCommands 6m 30t v </code>
wobei ''30t'' für "Toggle Modus, alle 30 Sekunden" steht.

=== Energy Count 3000 Sketch ===
Der Sketch für die Unterstützung der Energy Count 3000 Zwischenstecker kann aus dem [https://svn.fhem.de/trac/browser/trunk/fhem/contrib/arduino/ FHEM-Repository] heruntergeladen werden.

Das Fhem Modul dazu (36_EC3000.pm) ist genau wie die Module für JeeLink (36_JeeLink.pm) und PCA301 (36_PCA301.pm) mittlerweile im aktuellen Fhem enthalten.

=== JeeLabs RoomNode ===
Eine Beschreibung zum Empfang der JeeLabs RoomNodes ist in {{Link2Forum|Topic=11648|Message=92037|LinkText=diesem Forenbeitrag}} enthalten.

=== JeeLink LED deaktivieren ===
Ein "dauerhaftes" Deaktivieren der LED des JeeLink ist möglich mit
:<code>define not.global notify global:INITIALIZED set myJeeLink led off</code>
damit wird, sobald Fhem komplett gestartet ist, von Fhem der Befehl zum Ausschalten der LED gesendet. Alternativ kann mit
:<code>attr myJeeLink initCommands 0a v</code>
dem Sketch die Anweisung gegeben werden, bei der Initialisierung die LED zu deaktivieren.
''Quelle: dieser {{Link2Forum|Topic=27161|LinkText=Forenthread}}''

=== Weitergehende Informationen ===
Hinweise zum Betrieb eines JeeLink mit Fhem finden sich aktuell in größerer Anzahl in verschiedenen Diskussionen im Forum:
* {{Link2Forum|Topic=11648|LinkText=JeeLink / PCA301}} - Analyse des Funkprotokolls; Anfänge der Entstehung der PCA301 Unterstützung in Fhem.
* {{Link2Forum|Topic=14786|LinkText=JeeLink / LaCrosse}} - JeeLink Modul zur Einbindung von La Crosse
* {{Link2Forum|Topic=11648|Message=92019|LinkText=JeeLink / EC3000}} - Anfänge der Entstehung der EC3000 Unterstützung in Fhem.
* Hinweise zu {{Link2Forum|Topic=11648|Message=92037|LinkText=JeeLabs RoomNode}} und anderen JeeLab Nodes
* {{Link2Forum|Topic=25399|Message=183910|LinkText=JeeLink mit FHEM2FHEM nutzen}}

== Bekannte Probleme ==
* Beim Betrieb an einer [[AVM Fritz!Box|FritzBox]] wird der JeeLink unter Umständen als ''Für die Nutzung mit dem USB-Fernanschluss reserviert'' angezeigt. In diesem Fall muss die Reservierung deaktiviert/aufgehoben werden (Details dazu in diesem {{Link2Forum|Topic=16579|LinkText=Forenthread}}).
* Die Version ''v3c'' des JeeLink funktioniert (Stand 06/2015) nur mit dem LaCrosse Sketch. PCA301 und EC3000 Sketch sind auf den JeeLink Classic beschränkt (siehe unter anderem Diskussion im Forum, startend {{Link2Forum|Topic=11648|Message=308267|LinkText=hier}}).

== Weblinks ==
* [http://jeelabs.com/products/jeelink JeeLabs], JeeLink Hersteller
* [https://svn.fhem.de/trac/browser/trunk/fhem/contrib/arduino/ PCA301 Sketch] im SVN
* [https://svn.fhem.de/trac/browser/trunk/fhem/contrib/arduino/ LaCrosse Sketch] im SVN
* [https://svn.fhem.de/trac/browser/trunk/fhem/contrib/arduino/ EC3000 Sketch] im SVN
* [http://blog.moneybag.de/hausautomation-fhem-mit-funksteckdose-energiemessung-elv-pca-301/ Blog] zum Thema JeeLink zur Anbindung von PCA301 und von LaCrosse Temperatursensoren an Fhem
* {{Link2Forum|Topic=23217|LinkText=LevelSender}} Tankfüllstand mit JeeLink empfangen

[[Kategorie:Interfaces]]
[[Kategorie:Other Components]]
[[Kategorie:Temperatursensoren]]
[[Kategorie:Feuchtesensoren]]
[[Kategorie:Wetterstationen]]

JeeLink

2017-01-18T18:26:43Z

Mahowi: /* Getestete iT+ Sensoren incl. Wetterstation WS 1600 */

'''JeeLink''' ist ein RF-Gerät im Formfaktor eines USB-Sticks mit externer Antenne.
{{Infobox Hardware
|Bild=JeeLink.jpg
|Bildbeschreibung=JeeLink mit Drahtantenne
|HWProtocol=PCA301, EC3000, RoomNode oder LaCrosse und EMT7110
|HWType=[[Interface]]
|HWCategory=
|HWComm=433/868/913 MHz
|HWChannels=?
|HWVoltage=5 V
|HWPowerConsumption=ca. 90 mA
|HWPoweredBy=USB
|HWSize=23*67*9mm
|HWDeviceFHEM=[http://fhem.de/commandref.html#JeeLink 36_JeeLink.pm]
|ModOwner={{Link2FU|430|Andre / justme1968}}
|HWManufacturer=JeeLabs
}}

== Beschreibung ==
Vergleichbar mit dem [[CUL]] von Busware, ist der JeeLink ein USB-Stick, mit dem Funk-Hausautomations-Komponenten angebunden werden können. CUL und JeeLink unterscheiden sich im Funkmodul (CUL -> CC1101; JeeLink -> RF12B), die nicht miteinander kompatibel sind. Daher kann man auch keinen CUL als JeeLink-Ersatz nutzen!

Den JeeLink gibt es in einer
* 433 MHz Version
* 868 MHz Version (Standard)
* 915 MHz Version (Betrieb in Europa nicht zugelassen)

== Vorbereitung JeeLink ==
Um mit dem JeeLink die jeweils gewünschten Signale empfangen zu können, ist er zunächst mit der passenden Firmware zu versorgen. Dies kann auf zwei Arten geschehen. Entweder durch das selber kompilieren der Software und das Flashen aus der Arduino IDE oder aus Fhem heraus mit einem aktuellen Firmwareimage das per update mit ausgeliefert wird.

=== Selber Kompilieren ===
[[Datei:JeeLink_flashen_1.jpg|mini|100px|rechts|Vorbereitung: Arduino einrichten]]
Um den JeeLink mit Fhem benutzen zu können, muss (mit der Arduino Software / Entwicklungsumgebung (IDE)) eine spezifische "Firmware" (ein Sketch) auf dem JeeLink installiert werden. Die generelle Vorbereitung für diese Aktion ist unabhängig vom benötigten Sketch und besteht aus den folgenden Schritten:
* Für Windows oder Mac OS X den passenden [http://www.ftdichip.com/Drivers/VCP.htm FTDI Treiber] installieren, unter Linux ist dieser meist schon vorhanden
* Installation der [http://arduino.cc/de/Guide/HomePage Arduino Software] für die benutzte Plattform (verfügbar sind Windows, Mac OS X und Linux)
* Je nach Sketch einbinden der [https://github.com/jcw/jeelib/archive/master.zip Jeelabs Library] in die Arduino IDE
* Herunterladen des benötigten Sketches (aus [https://svn.fhem.de/trac/browser/trunk/fhem/contrib/arduino FHEM/contrib])
* Anschließen des JeeLink an einen USB-Anschluss des Rechners mit der Arduino IDE
* Start der Arduino Software und JeeLink flashen

=== JeeLink aus Arduino flashen ===
[[Datei:JeeLink_flashen_2.jpg|mini|100px|rechts|JeeLink Flashen]]
* Anschließen des JeeLink an einen USB-Anschluss des Rechners mit der Arduino IDE
* Start der Arduino Software
* Seriellen Port des JeeLink auswählen
* Einstellungen: in den Tools als Board "Arduino Uno" auswählen
* Sketch mit "Datei öffnen" auswählen
* Upload klicken

=== JeeLink aus Fhem flashen ===
* Auf dem Fhem System muss <code>avrdude</code> installiert sein. Das kann z.B. über die "normale" Linux Paketverwaltung geschehen.
* mit <code>set <JeeLinkDevice> flash [firmware]</code> wird das Flashen angestossen<br><code>firmware</code> kann LaCrosse, PCA301 oder EC3000 sein. Wenn <code>firmware</code> nicht angegeben wird versucht FHEM den Namen der zu flashenden Firmware aus der zur Zeit installierten Firmware abzuleiten.
* im Fhem Log kann der Ausgang des Flashvorgangs kontrolliert werden
* über das <code>flashCommand</code> Attribut lässt sich das Kommando zum Flashen an besondere Anforderungen anpassen

'''Vorsicht bei Jeelink Clones!'''

Jeelink Clones basierend auf dem Arduino Nano haben normalerweise keinen Optibootloader drauf im Gegensatz zum Original JeeLink und JeeNode.

Konsequenz:

Beim "Nano Clone" und ähnliches muß man zum flashen in FHEM die Baudrate setzen mit "-b 57600"

Original JeeLink, original JeeNode, und alle Arduinos, die einen Optibootloader drauf haben flashen in FHEM ohne "-b 57600"

== Hinweise zum Betrieb mit Fhem ==
Um den JeeLink (erstmalig) mit Fhem benutzen zu können, muss dieser erfolgreich geflasht worden sein.
* JeeLink an den Fhem-Rechner anschließen
* Auf Linux Systemen kann es notwendig sein, mit <code>mknod /dev/ttyUSB0 c 188 0</code> das Device anzulegen (bitte erst überprüfen, ob der Stick nicht automatisch erkannt wird)

=== Definition in fhem.cfg ===
Erforderliche Definitionen in Fhem:
:<code>define myJeeLink JeeLink /dev/ttyUSBx@57600</code>
*'''USBx''' ist anzupassen an die aktuell benutzte Schnittstelle, 0 wenn sonst nichts am USB-Port hängt
*x=0,1,2, usw.

Die [http://fhem.de/commandref.html#autocreate autocreate-Funktion] sollte aktiv sein. Alle erkannten Devices (PCA301, LaCrosse Sensoren incl. IT+ Wetterstation WS1600, EMT7110, EC3000, und RoomNodes) werden dann automatisch angelegt, sobald die jeweiligen Daten empfangen werden.

Pro Geräte-Art/Protokoll muss ein eigener JeeLink mit dem passenden Sketch zum Empfang dieser Daten vorhanden sein (es kann jeweils nur ein Sketch im JeeLink aktiv sein und es gibt (zumindest derzeit (04/2014)) keinen Sketch, der mehr als eines der Protokolle abdeckt).

'''Anmerkung:''' Der LaCrosse Sketch deckt sowohl die LaCrosse Temperatursensoren, die IT+ Wetterstation WS1600 als auch den Energieverbrauchssensor EMT7110 ab.

=== PCA301 Sketch ===
Der Sketch für die Unterstützung der ''PCA301 Funkschaltsteckdose mit Energieverbrauchsmessung'' (PCA301-pcaSerial.zip) kann aus dem [https://svn.fhem.de/trac/browser/trunk/fhem/contrib/arduino/ FHEM-Repository] heruntergeladen werden. Details zur Benutzung finden sich im Artikel zur [[PCA301 Funkschaltsteckdose mit Energieverbrauchsmessung|PCA301]].

Unter Umständen werden die Signale der PCA301 nicht empfangen. Insbesondere mit selbst erstellten "JeeLinks" durch wahrscheinlich hohe Bauteiltoleranzen der RF12B Sendeeinheiten. Mit dem im Sketch voreingestellten rf12_center_freq = 0xA6FE (868,9500 MHz) bekommt man in diesem Fall keine Steckdose angelernt.

==== Frequenzanpassung über modifizierten Sketch ====
Durch Tests mittels ''set <myJeeLink> raw +'' bzw ''set <myJeeLink> raw -'' kann man dann ermitteln, ob die Funksignale z.B. ab A703 bis A715 empfangen werden. Das entspricht einem Frequenzbereich zwischen 868,9750 MHz und 869,0550 MHz.
Die Mitte ist die Lösung, die man dann im Sketch ändern muss:
:<code>static uint16_t rf12_center_freq = 0xA70C;</code>
Anschließend auf den JeeLink neu flashen.

==== Frequenzanpassung über Attribut initCommands ====
Über das <code>initCommands</code> lässt sich die gefundene Frequenz einstellen, ohne dass die Firmware verändert werden muss.
:<code>attr <JeeLinkDevice> initCommands <hhhh>h</code>

=== LaCrosse Sketch ===
Der Sketch für die Unterstützung der LaCrosse Temperatursensoren, der IT+ Wetterstation WS1600 und des Energieverbrauchssensors EMT7110 so wie auch TechnoLine Sensoren (Temperatur, Luftfeuchte,...).<br>

* Er kann aus dem [https://svn.fhem.de/trac/browser/trunk/fhem/contrib/arduino FHEM-Repository] heruntergeladen werden.
* Alternative ist den Sketch direkt über Fhem zu flashen <code>set <JeeLinkDevice> flash LaCrosse</code> z.B.: <code>set myJeeLink flash LaCrosse</code> zuvor sollte aber ein Fhem update mit <code>update</code> durchgeführt werden.
<br>

'''Sensoren anlernen:
Mit folgenden Befehl hat man die Möglichkeit 60 Sekunden ein Gerät anzulernen. Das Gerät erscheint dann unter der Rubrik LaCrosse. <code>set <JeeLinkDevice> LaCrossePairForSec 60</code> zum Beispiel: <code>set myJeeLink LaCrossePairForSec 60</code>.

'''In der neuesten Version unterstützt er auch den SuperJee''' (siehe auch diesen {{Link2Forum|Topic=14786|Message=316924|LinkText=Forenbeitrag}}) mit folgenden Optionen:

* Option 1 (Dual RFM):
:Es kann ein zweiter RFM12B oder RFM69CW angeschlossen werden. Somit können zwei data rates (z.B. 17241 für TX29DTH und 8842 für WS 1600) gleichzeitig empfangen werden. Das geht natürlich auch mit dem toggle mode, nur ist es bei der Wetterstation ärgerlich, wenn man 30 Sekunden lang nichts empfängt und dadurch die alles entscheidende Windböe verpasst.
* Option 2 (BMP180):
:Da der Luftdruck in den Basisstationen gemessen wird, steht er für FHEM nicht zur Verfügung.
Deshalb kann nun optional ein BMP180 oder BMP085 angeschlossen werden. Auch hier wird automatisch erkannt, ob er vorhanden ist.
:Der BMP180 wird mit 3,3V versorgt und SDA mit PC4 und SCL mit PC5 verbunden (siehe die in diesem {{Link2Forum|Topic=14786|Message=316924|LinkText=Forenbeitrag}} angehängte SuperJee-CL.png)

==== Übersicht Kommandos ====
<n>a set to 0 if the blue LED bothers
<n>f initial frequency in kHz (5 kHz steps, 860480 ... 879515) (for RFM #1)
<n>F initial frequency in kHz (5 kHz steps, 860480 ... 879515) (for RFM #2)
<n>h altituide above sea level
<n>m bits 1: 17.241 kbps, 2 : 9.579 kbps, 4 : 8.842 kbps (for RFM #1)
<n>M bits 1: 17.241 kbps, 2 : 9.579 kbps, 4 : 8.842 kbps (for RFM #2)
<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>t 0=no toggle, else interval in seconds (for RFM #1)
<n>T 0=no toggle, else interval in seconds (for RFM #2)
v show version
<n>y if 1 all received packets will be retransmitted (Relay mode)

==== Relay-Betrieb ====
Der LaCrosse Sketch ermöglicht auch den Relay-Betrieb zur Reichweitenverbesserung. Er funktioniert damit ähnlich wie z. B. ein WLAN Range Extender. Wenn der Sketch für den Relay-Betrieb konfiguriert ist, wird jedes empfangene IT+ Datenpaket, das eine gültige Prüfsumme hat, direkt nach dem Empfang wieder gesendet.

Das Prinzip ist generell recht einfach:
# JeeLink im Sketch als Relais konfigurieren und flashen.
# Auf "halber Strecke" (d.h. irgendwo zwischen dem primären Sender und dem entfernten Empfänger) auf ein USB-Steckernetzteil stecken. Der JeeLink arbeitet in diesem Modus "autonom", er benötigt also lediglich einen Spannungsversorgung.

Der JeeLink empfängt und decodiert alle Protokolle, die er auch für FHEM unterstützt. Wenn er ein Paket empfangen hat (egal von welchem Sensor) und CRC OK war, dann sendet er es wieder aus. Der JeeLink am FHEM merkt keinen Unterschied. Falls ein Paket es doch bis zum FHEM direkt geschafft hat, kommt es dort zweimal an. Diese Situation muss in Fhem behandelt werden.

Details zu diesem Betriebsmodus sind in diesen Forenbeiträgen ({{Link2Forum|Topic=14786|Message=165153|LinkText=LaCrosse}} bzw. {{Link2Forum|Topic=26494|Message=196648|LinkText=EMT7110}}) zu finden.

==== Frequenzanpassung ====
Ab Version LaCrosseITPlusReader.10.1e wurde der Sketch so erweitert, dass man von FHEM aus die Frequenz setzen kann. Dazu versteht der Sketch das neue Kommando "f":
:<code>set myJeeLink raw 868295f</code>
setzt die Frequenz auf 868295 kHz.

Die Frequenz kann im Bereich von 860480 kHz bis 879515 kHz in 5kHz -Schritten eingestellt werden.
Details dazu in diesem {{Link2Forum|Topic=14786|Message=222541}} im Forum. Die Frequenzanpassung ist insbesondere beim 30.3155.WD häufig erforderlich, weshalb er als kritisch einzustufen und nicht zu empfehlen ist (siehe {{Link2Forum|Topic=14786|Message=352550|LinkText=Forenbeitrag}}).

==== Toggle und Datenrate ====
Toggle
t: toggle time
20t = alle 20 Sekunden die Datenrate wechseln

Datenrate
m: toggle mode
bits: 1= 17.241 kbps, 2= 9.579 kbps, 4= 8.842 kbps
3m ist 17.241 kbps (TX29) und 9.579 kbps (TX35)

Beispiel initCommands
6m 30t v
Zwischen 8.842 kbps und 9.579 kbps wechseln (4+2=6), alle 30 Sekunden

==== Unterstützte Sensoren und Aktoren incl. Wetterstation WS 1600 ====
{{Randnotiz|RNTyp=y|RNText=Die Ausführungen in diesem Abschnitt gelten ab der Version 10.1q auch für die Wetterstation WS1080.

'''Wichtig WS1800''': die WS1080 gibt es (unter gleichem Namen) in einer "OOK"- und in einer "FSK"-Version.
* Der LaCrosse Sketch und das LaCrosseGateway können nur die FSK-Version empfangen, die OOK-Version wird nicht unterstützt.
* Die FSK-Version ist zu erkennen an einem runden grünen Aufkleber im Batteriefach der Station mit dem Aufdruck "PASS 7". Details dazu in {{Link2Forum|Topic=14786|Message=363766|LinkText=diesem Forenbeitrag}}
}}

Die in der folgenden Liste (Quelle: {{Link2Forum|Topic=14786|Message=164801|LinkText=Fhem Forum}}) aufgeführten Sensoren wurden bisher erfolgreich getestet:

{| class="wikitable"
!Bezeichnung !! Datenrate !! Link / Hinweise
|-
| TX21IT || 17.241 kbps ||
|-
| TX25-IT || 17.241 kbps ||
|-
| TX27-IT || 17.241 kbps ||
|-
| TX29-IT || 17.241 kbps ||
|-
| TX29DTH-IT || 17.241 kbps ||
|-
| TX37 || 17.241 kbps ||
|-
| TX35TH-IT || 9.579 kbps ||
|-
| TX35DTH-IT || 9.579 kbps ||
|-
| 30.3143.IT || 17.241 kbps ||
|-
| 30.3144.IT || 17.241 kbps || ({{Link2Forum|Topic=17662|LinkText=Forenthread}})
|-
| 30.3147.IT || 17.241 kbps ||
|-
| 30.3155WD || 9.579 kbps || kritisch; nicht zu empfehlen; siehe {{Link2Forum|Topic=14786|Message=352550|LinkText=Forenbeitrag}}
|-
| 30.3156WD || 9.579 kbps || Batterie-kritisch. Funktioniert schlecht mit Akkus!
|-
| 30.3187.IT || 17.241 kbps || haben alle die gleiche ID, daher nur einzeln verwendbar ({{Link2Forum|Topic=64636|LinkText=Forenthread}})
|-
| WT440XH || 17.241 kbps ||
|-
| WS 1600 (TX22) || 8.842 kbps || ({{Link2Forum|Topic=14786|Message=297293|LinkText=Forenbeitrag}})
|-
| WS 1080 || 17.241 kbps || Bitte Hinweise beachten! ({{Link2Forum|Topic=14786|Message=363766|LinkText=Forenbeitrag}})
|-
| [[EMT7110]] || 9.579 kbps || ({{Link2Forum|Topic=26494|LinkText=Forenthread}})
|-
| LevelSender || 17.241 kbps || ({{Link2Forum|Topic=23217|LinkText=Forenthread}})

|}

==== EMT7110 ====
Der [[EMT7110]] läuft mit einer Datenrate von 9.579 kbps (Details dazu in diesem {{Link2Forum|Topic=26494|LinkText=Forenthread}}).

Werden Sensoren mit unterschiedlichen Datenraten gleichzeitig betrieben, ist der Toggle Modus einzustellen, z.B. mit dem Befehl
:<code>initCommands 30t v </code>
wobei ''30t'' für "Toggle Modus, alle 30 Sekunden" steht.

=== Energy Count 3000 Sketch ===
Der Sketch für die Unterstützung der Energy Count 3000 Zwischenstecker kann aus dem [https://svn.fhem.de/trac/browser/trunk/fhem/contrib/arduino/ FHEM-Repository] heruntergeladen werden.

Das Fhem Modul dazu (36_EC3000.pm) ist genau wie die Module für JeeLink (36_JeeLink.pm) und PCA301 (36_PCA301.pm) mittlerweile im aktuellen Fhem enthalten.

=== JeeLabs RoomNode ===
Eine Beschreibung zum Empfang der JeeLabs RoomNodes ist in {{Link2Forum|Topic=11648|Message=92037|LinkText=diesem Forenbeitrag}} enthalten.

=== JeeLink LED deaktivieren ===
Ein "dauerhaftes" Deaktivieren der LED des JeeLink ist möglich mit
:<code>define not.global notify global:INITIALIZED set myJeeLink led off</code>
damit wird, sobald Fhem komplett gestartet ist, von Fhem der Befehl zum Ausschalten der LED gesendet. Alternativ kann mit
:<code>attr myJeeLink initCommands 0a v</code>
dem Sketch die Anweisung gegeben werden, bei der Initialisierung die LED zu deaktivieren.
''Quelle: dieser {{Link2Forum|Topic=27161|LinkText=Forenthread}}''

=== Weitergehende Informationen ===
Hinweise zum Betrieb eines JeeLink mit Fhem finden sich aktuell in größerer Anzahl in verschiedenen Diskussionen im Forum:
* {{Link2Forum|Topic=11648|LinkText=JeeLink / PCA301}} - Analyse des Funkprotokolls; Anfänge der Entstehung der PCA301 Unterstützung in Fhem.
* {{Link2Forum|Topic=14786|LinkText=JeeLink / LaCrosse}} - JeeLink Modul zur Einbindung von La Crosse
* {{Link2Forum|Topic=11648|Message=92019|LinkText=JeeLink / EC3000}} - Anfänge der Entstehung der EC3000 Unterstützung in Fhem.
* Hinweise zu {{Link2Forum|Topic=11648|Message=92037|LinkText=JeeLabs RoomNode}} und anderen JeeLab Nodes
* {{Link2Forum|Topic=25399|Message=183910|LinkText=JeeLink mit FHEM2FHEM nutzen}}

== Bekannte Probleme ==
* Beim Betrieb an einer [[AVM Fritz!Box|FritzBox]] wird der JeeLink unter Umständen als ''Für die Nutzung mit dem USB-Fernanschluss reserviert'' angezeigt. In diesem Fall muss die Reservierung deaktiviert/aufgehoben werden (Details dazu in diesem {{Link2Forum|Topic=16579|LinkText=Forenthread}}).
* Die Version ''v3c'' des JeeLink funktioniert (Stand 06/2015) nur mit dem LaCrosse Sketch. PCA301 und EC3000 Sketch sind auf den JeeLink Classic beschränkt (siehe unter anderem Diskussion im Forum, startend {{Link2Forum|Topic=11648|Message=308267|LinkText=hier}}).

== Weblinks ==
* [http://jeelabs.com/products/jeelink JeeLabs], JeeLink Hersteller
* [https://svn.fhem.de/trac/browser/trunk/fhem/contrib/arduino/ PCA301 Sketch] im SVN
* [https://svn.fhem.de/trac/browser/trunk/fhem/contrib/arduino/ LaCrosse Sketch] im SVN
* [https://svn.fhem.de/trac/browser/trunk/fhem/contrib/arduino/ EC3000 Sketch] im SVN
* [http://blog.moneybag.de/hausautomation-fhem-mit-funksteckdose-energiemessung-elv-pca-301/ Blog] zum Thema JeeLink zur Anbindung von PCA301 und von LaCrosse Temperatursensoren an Fhem
* {{Link2Forum|Topic=23217|LinkText=LevelSender}} Tankfüllstand mit JeeLink empfangen

[[Kategorie:Interfaces]]
[[Kategorie:Other Components]]
[[Kategorie:Temperatursensoren]]
[[Kategorie:Feuchtesensoren]]
[[Kategorie:Wetterstationen]]

JeeLink

2017-01-18T18:24:44Z

Mahowi: /* Getestete iT+ Sensoren incl. Wetterstation WS 1600 */ Abgleich mit Einträgen in LaCrosseGateway

'''JeeLink''' ist ein RF-Gerät im Formfaktor eines USB-Sticks mit externer Antenne.
{{Infobox Hardware
|Bild=JeeLink.jpg
|Bildbeschreibung=JeeLink mit Drahtantenne
|HWProtocol=PCA301, EC3000, RoomNode oder LaCrosse und EMT7110
|HWType=[[Interface]]
|HWCategory=
|HWComm=433/868/913 MHz
|HWChannels=?
|HWVoltage=5 V
|HWPowerConsumption=ca. 90 mA
|HWPoweredBy=USB
|HWSize=23*67*9mm
|HWDeviceFHEM=[http://fhem.de/commandref.html#JeeLink 36_JeeLink.pm]
|ModOwner={{Link2FU|430|Andre / justme1968}}
|HWManufacturer=JeeLabs
}}

== Beschreibung ==
Vergleichbar mit dem [[CUL]] von Busware, ist der JeeLink ein USB-Stick, mit dem Funk-Hausautomations-Komponenten angebunden werden können. CUL und JeeLink unterscheiden sich im Funkmodul (CUL -> CC1101; JeeLink -> RF12B), die nicht miteinander kompatibel sind. Daher kann man auch keinen CUL als JeeLink-Ersatz nutzen!

Den JeeLink gibt es in einer
* 433 MHz Version
* 868 MHz Version (Standard)
* 915 MHz Version (Betrieb in Europa nicht zugelassen)

== Vorbereitung JeeLink ==
Um mit dem JeeLink die jeweils gewünschten Signale empfangen zu können, ist er zunächst mit der passenden Firmware zu versorgen. Dies kann auf zwei Arten geschehen. Entweder durch das selber kompilieren der Software und das Flashen aus der Arduino IDE oder aus Fhem heraus mit einem aktuellen Firmwareimage das per update mit ausgeliefert wird.

=== Selber Kompilieren ===
[[Datei:JeeLink_flashen_1.jpg|mini|100px|rechts|Vorbereitung: Arduino einrichten]]
Um den JeeLink mit Fhem benutzen zu können, muss (mit der Arduino Software / Entwicklungsumgebung (IDE)) eine spezifische "Firmware" (ein Sketch) auf dem JeeLink installiert werden. Die generelle Vorbereitung für diese Aktion ist unabhängig vom benötigten Sketch und besteht aus den folgenden Schritten:
* Für Windows oder Mac OS X den passenden [http://www.ftdichip.com/Drivers/VCP.htm FTDI Treiber] installieren, unter Linux ist dieser meist schon vorhanden
* Installation der [http://arduino.cc/de/Guide/HomePage Arduino Software] für die benutzte Plattform (verfügbar sind Windows, Mac OS X und Linux)
* Je nach Sketch einbinden der [https://github.com/jcw/jeelib/archive/master.zip Jeelabs Library] in die Arduino IDE
* Herunterladen des benötigten Sketches (aus [https://svn.fhem.de/trac/browser/trunk/fhem/contrib/arduino FHEM/contrib])
* Anschließen des JeeLink an einen USB-Anschluss des Rechners mit der Arduino IDE
* Start der Arduino Software und JeeLink flashen

=== JeeLink aus Arduino flashen ===
[[Datei:JeeLink_flashen_2.jpg|mini|100px|rechts|JeeLink Flashen]]
* Anschließen des JeeLink an einen USB-Anschluss des Rechners mit der Arduino IDE
* Start der Arduino Software
* Seriellen Port des JeeLink auswählen
* Einstellungen: in den Tools als Board "Arduino Uno" auswählen
* Sketch mit "Datei öffnen" auswählen
* Upload klicken

=== JeeLink aus Fhem flashen ===
* Auf dem Fhem System muss <code>avrdude</code> installiert sein. Das kann z.B. über die "normale" Linux Paketverwaltung geschehen.
* mit <code>set <JeeLinkDevice> flash [firmware]</code> wird das Flashen angestossen<br><code>firmware</code> kann LaCrosse, PCA301 oder EC3000 sein. Wenn <code>firmware</code> nicht angegeben wird versucht FHEM den Namen der zu flashenden Firmware aus der zur Zeit installierten Firmware abzuleiten.
* im Fhem Log kann der Ausgang des Flashvorgangs kontrolliert werden
* über das <code>flashCommand</code> Attribut lässt sich das Kommando zum Flashen an besondere Anforderungen anpassen

'''Vorsicht bei Jeelink Clones!'''

Jeelink Clones basierend auf dem Arduino Nano haben normalerweise keinen Optibootloader drauf im Gegensatz zum Original JeeLink und JeeNode.

Konsequenz:

Beim "Nano Clone" und ähnliches muß man zum flashen in FHEM die Baudrate setzen mit "-b 57600"

Original JeeLink, original JeeNode, und alle Arduinos, die einen Optibootloader drauf haben flashen in FHEM ohne "-b 57600"

== Hinweise zum Betrieb mit Fhem ==
Um den JeeLink (erstmalig) mit Fhem benutzen zu können, muss dieser erfolgreich geflasht worden sein.
* JeeLink an den Fhem-Rechner anschließen
* Auf Linux Systemen kann es notwendig sein, mit <code>mknod /dev/ttyUSB0 c 188 0</code> das Device anzulegen (bitte erst überprüfen, ob der Stick nicht automatisch erkannt wird)

=== Definition in fhem.cfg ===
Erforderliche Definitionen in Fhem:
:<code>define myJeeLink JeeLink /dev/ttyUSBx@57600</code>
*'''USBx''' ist anzupassen an die aktuell benutzte Schnittstelle, 0 wenn sonst nichts am USB-Port hängt
*x=0,1,2, usw.

Die [http://fhem.de/commandref.html#autocreate autocreate-Funktion] sollte aktiv sein. Alle erkannten Devices (PCA301, LaCrosse Sensoren incl. IT+ Wetterstation WS1600, EMT7110, EC3000, und RoomNodes) werden dann automatisch angelegt, sobald die jeweiligen Daten empfangen werden.

Pro Geräte-Art/Protokoll muss ein eigener JeeLink mit dem passenden Sketch zum Empfang dieser Daten vorhanden sein (es kann jeweils nur ein Sketch im JeeLink aktiv sein und es gibt (zumindest derzeit (04/2014)) keinen Sketch, der mehr als eines der Protokolle abdeckt).

'''Anmerkung:''' Der LaCrosse Sketch deckt sowohl die LaCrosse Temperatursensoren, die IT+ Wetterstation WS1600 als auch den Energieverbrauchssensor EMT7110 ab.

=== PCA301 Sketch ===
Der Sketch für die Unterstützung der ''PCA301 Funkschaltsteckdose mit Energieverbrauchsmessung'' (PCA301-pcaSerial.zip) kann aus dem [https://svn.fhem.de/trac/browser/trunk/fhem/contrib/arduino/ FHEM-Repository] heruntergeladen werden. Details zur Benutzung finden sich im Artikel zur [[PCA301 Funkschaltsteckdose mit Energieverbrauchsmessung|PCA301]].

Unter Umständen werden die Signale der PCA301 nicht empfangen. Insbesondere mit selbst erstellten "JeeLinks" durch wahrscheinlich hohe Bauteiltoleranzen der RF12B Sendeeinheiten. Mit dem im Sketch voreingestellten rf12_center_freq = 0xA6FE (868,9500 MHz) bekommt man in diesem Fall keine Steckdose angelernt.

==== Frequenzanpassung über modifizierten Sketch ====
Durch Tests mittels ''set <myJeeLink> raw +'' bzw ''set <myJeeLink> raw -'' kann man dann ermitteln, ob die Funksignale z.B. ab A703 bis A715 empfangen werden. Das entspricht einem Frequenzbereich zwischen 868,9750 MHz und 869,0550 MHz.
Die Mitte ist die Lösung, die man dann im Sketch ändern muss:
:<code>static uint16_t rf12_center_freq = 0xA70C;</code>
Anschließend auf den JeeLink neu flashen.

==== Frequenzanpassung über Attribut initCommands ====
Über das <code>initCommands</code> lässt sich die gefundene Frequenz einstellen, ohne dass die Firmware verändert werden muss.
:<code>attr <JeeLinkDevice> initCommands <hhhh>h</code>

=== LaCrosse Sketch ===
Der Sketch für die Unterstützung der LaCrosse Temperatursensoren, der IT+ Wetterstation WS1600 und des Energieverbrauchssensors EMT7110 so wie auch TechnoLine Sensoren (Temperatur, Luftfeuchte,...).<br>

* Er kann aus dem [https://svn.fhem.de/trac/browser/trunk/fhem/contrib/arduino FHEM-Repository] heruntergeladen werden.
* Alternative ist den Sketch direkt über Fhem zu flashen <code>set <JeeLinkDevice> flash LaCrosse</code> z.B.: <code>set myJeeLink flash LaCrosse</code> zuvor sollte aber ein Fhem update mit <code>update</code> durchgeführt werden.
<br>

'''Sensoren anlernen:
Mit folgenden Befehl hat man die Möglichkeit 60 Sekunden ein Gerät anzulernen. Das Gerät erscheint dann unter der Rubrik LaCrosse. <code>set <JeeLinkDevice> LaCrossePairForSec 60</code> zum Beispiel: <code>set myJeeLink LaCrossePairForSec 60</code>.

'''In der neuesten Version unterstützt er auch den SuperJee''' (siehe auch diesen {{Link2Forum|Topic=14786|Message=316924|LinkText=Forenbeitrag}}) mit folgenden Optionen:

* Option 1 (Dual RFM):
:Es kann ein zweiter RFM12B oder RFM69CW angeschlossen werden. Somit können zwei data rates (z.B. 17241 für TX29DTH und 8842 für WS 1600) gleichzeitig empfangen werden. Das geht natürlich auch mit dem toggle mode, nur ist es bei der Wetterstation ärgerlich, wenn man 30 Sekunden lang nichts empfängt und dadurch die alles entscheidende Windböe verpasst.
* Option 2 (BMP180):
:Da der Luftdruck in den Basisstationen gemessen wird, steht er für FHEM nicht zur Verfügung.
Deshalb kann nun optional ein BMP180 oder BMP085 angeschlossen werden. Auch hier wird automatisch erkannt, ob er vorhanden ist.
:Der BMP180 wird mit 3,3V versorgt und SDA mit PC4 und SCL mit PC5 verbunden (siehe die in diesem {{Link2Forum|Topic=14786|Message=316924|LinkText=Forenbeitrag}} angehängte SuperJee-CL.png)

==== Übersicht Kommandos ====
<n>a set to 0 if the blue LED bothers
<n>f initial frequency in kHz (5 kHz steps, 860480 ... 879515) (for RFM #1)
<n>F initial frequency in kHz (5 kHz steps, 860480 ... 879515) (for RFM #2)
<n>h altituide above sea level
<n>m bits 1: 17.241 kbps, 2 : 9.579 kbps, 4 : 8.842 kbps (for RFM #1)
<n>M bits 1: 17.241 kbps, 2 : 9.579 kbps, 4 : 8.842 kbps (for RFM #2)
<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>t 0=no toggle, else interval in seconds (for RFM #1)
<n>T 0=no toggle, else interval in seconds (for RFM #2)
v show version
<n>y if 1 all received packets will be retransmitted (Relay mode)

==== Relay-Betrieb ====
Der LaCrosse Sketch ermöglicht auch den Relay-Betrieb zur Reichweitenverbesserung. Er funktioniert damit ähnlich wie z. B. ein WLAN Range Extender. Wenn der Sketch für den Relay-Betrieb konfiguriert ist, wird jedes empfangene IT+ Datenpaket, das eine gültige Prüfsumme hat, direkt nach dem Empfang wieder gesendet.

Das Prinzip ist generell recht einfach:
# JeeLink im Sketch als Relais konfigurieren und flashen.
# Auf "halber Strecke" (d.h. irgendwo zwischen dem primären Sender und dem entfernten Empfänger) auf ein USB-Steckernetzteil stecken. Der JeeLink arbeitet in diesem Modus "autonom", er benötigt also lediglich einen Spannungsversorgung.

Der JeeLink empfängt und decodiert alle Protokolle, die er auch für FHEM unterstützt. Wenn er ein Paket empfangen hat (egal von welchem Sensor) und CRC OK war, dann sendet er es wieder aus. Der JeeLink am FHEM merkt keinen Unterschied. Falls ein Paket es doch bis zum FHEM direkt geschafft hat, kommt es dort zweimal an. Diese Situation muss in Fhem behandelt werden.

Details zu diesem Betriebsmodus sind in diesen Forenbeiträgen ({{Link2Forum|Topic=14786|Message=165153|LinkText=LaCrosse}} bzw. {{Link2Forum|Topic=26494|Message=196648|LinkText=EMT7110}}) zu finden.

==== Frequenzanpassung ====
Ab Version LaCrosseITPlusReader.10.1e wurde der Sketch so erweitert, dass man von FHEM aus die Frequenz setzen kann. Dazu versteht der Sketch das neue Kommando "f":
:<code>set myJeeLink raw 868295f</code>
setzt die Frequenz auf 868295 kHz.

Die Frequenz kann im Bereich von 860480 kHz bis 879515 kHz in 5kHz -Schritten eingestellt werden.
Details dazu in diesem {{Link2Forum|Topic=14786|Message=222541}} im Forum. Die Frequenzanpassung ist insbesondere beim 30.3155.WD häufig erforderlich, weshalb er als kritisch einzustufen und nicht zu empfehlen ist (siehe {{Link2Forum|Topic=14786|Message=352550|LinkText=Forenbeitrag}}).

==== Toggle und Datenrate ====
Toggle
t: toggle time
20t = alle 20 Sekunden die Datenrate wechseln

Datenrate
m: toggle mode
bits: 1= 17.241 kbps, 2= 9.579 kbps, 4= 8.842 kbps
3m ist 17.241 kbps (TX29) und 9.579 kbps (TX35)

Beispiel initCommands
6m 30t v
Zwischen 8.842 kbps und 9.579 kbps wechseln (4+2=6), alle 30 Sekunden

==== Getestete iT+ Sensoren incl. Wetterstation WS 1600 ====
{{Randnotiz|RNTyp=y|RNText=Die Ausführungen in diesem Abschnitt gelten ab der Version 10.1q auch für die Wetterstation WS1080.

'''Wichtig WS1800''': die WS1080 gibt es (unter gleichem Namen) in einer "OOK"- und in einer "FSK"-Version.
* Der LaCrosse Sketch und das LaCrosseGateway können nur die FSK-Version empfangen, die OOK-Version wird nicht unterstützt.
* Die FSK-Version ist zu erkennen an einem runden grünen Aufkleber im Batteriefach der Station mit dem Aufdruck "PASS 7". Details dazu in {{Link2Forum|Topic=14786|Message=363766|LinkText=diesem Forenbeitrag}}
}}

Die in der folgenden Liste (Quelle: {{Link2Forum|Topic=14786|Message=164801|LinkText=Fhem Forum}}) aufgeführten Sensoren wurden bisher erfolgreich getestet:

{| class="wikitable"
!Bezeichnung !! Datenrate !! Link / Hinweise
|-
| TX21IT || 17.241 kbps ||
|-
| TX25-IT || 17.241 kbps ||
|-
| TX27-IT || 17.241 kbps ||
|-
| TX29-IT || 17.241 kbps ||
|-
| TX29DTH-IT || 17.241 kbps ||
|-
| TX37 || 17.241 kbps ||
|-
| TX35TH-IT || 9.579 kbps ||
|-
| TX35DTH-IT || 9.579 kbps ||
|-
| 30.3143.IT || 17.241 kbps ||
|-
| 30.3144.IT || 17.241 kbps || ({{Link2Forum|Topic=17662|LinkText=Forenthread}})
|-
| 30.3147.IT || 17.241 kbps ||
|-
| 30.3155WD || 9.579 kbps || kritisch; nicht zu empfehlen; siehe {{Link2Forum|Topic=14786|Message=352550|LinkText=Forenbeitrag}}
|-
| 30.3156WD || 9.579 kbps || Batterie-kritisch. Funktioniert schlecht mit Akkus!
|-
| 30.3187.IT || 17.241 kbps || haben alle die gleiche ID, daher nur einzeln verwendbar ({{Link2Forum|Topic=64636|LinkText=Forenthread}})
|-
| WT440XH || 17.241 kbps ||
|-
| WS 1600 (TX22) || 8.842 kbps || ({{Link2Forum|Topic=14786|Message=297293|LinkText=Forenbeitrag}})
|-
| WS 1080 || 17.241 kbps || Bitte Hinweise beachten! ({{Link2Forum|Topic=14786|Message=363766|LinkText=Forenbeitrag}})
|-
| [[EMT7110]] || 9.579 kbps || ({{Link2Forum|Topic=26494|LinkText=Forenthread}})
|-
| LevelSender || 17.241 kbps || ({{Link2Forum|Topic=23217|LinkText=Forenthread}})

|}

==== EMT7110 ====
Der [[EMT7110]] läuft mit einer Datenrate von 9.579 kbps (Details dazu in diesem {{Link2Forum|Topic=26494|LinkText=Forenthread}}).

Werden Sensoren mit unterschiedlichen Datenraten gleichzeitig betrieben, ist der Toggle Modus einzustellen, z.B. mit dem Befehl
:<code>initCommands 30t v </code>
wobei ''30t'' für "Toggle Modus, alle 30 Sekunden" steht.

=== Energy Count 3000 Sketch ===
Der Sketch für die Unterstützung der Energy Count 3000 Zwischenstecker kann aus dem [https://svn.fhem.de/trac/browser/trunk/fhem/contrib/arduino/ FHEM-Repository] heruntergeladen werden.

Das Fhem Modul dazu (36_EC3000.pm) ist genau wie die Module für JeeLink (36_JeeLink.pm) und PCA301 (36_PCA301.pm) mittlerweile im aktuellen Fhem enthalten.

=== JeeLabs RoomNode ===
Eine Beschreibung zum Empfang der JeeLabs RoomNodes ist in {{Link2Forum|Topic=11648|Message=92037|LinkText=diesem Forenbeitrag}} enthalten.

=== JeeLink LED deaktivieren ===
Ein "dauerhaftes" Deaktivieren der LED des JeeLink ist möglich mit
:<code>define not.global notify global:INITIALIZED set myJeeLink led off</code>
damit wird, sobald Fhem komplett gestartet ist, von Fhem der Befehl zum Ausschalten der LED gesendet. Alternativ kann mit
:<code>attr myJeeLink initCommands 0a v</code>
dem Sketch die Anweisung gegeben werden, bei der Initialisierung die LED zu deaktivieren.
''Quelle: dieser {{Link2Forum|Topic=27161|LinkText=Forenthread}}''

=== Weitergehende Informationen ===
Hinweise zum Betrieb eines JeeLink mit Fhem finden sich aktuell in größerer Anzahl in verschiedenen Diskussionen im Forum:
* {{Link2Forum|Topic=11648|LinkText=JeeLink / PCA301}} - Analyse des Funkprotokolls; Anfänge der Entstehung der PCA301 Unterstützung in Fhem.
* {{Link2Forum|Topic=14786|LinkText=JeeLink / LaCrosse}} - JeeLink Modul zur Einbindung von La Crosse
* {{Link2Forum|Topic=11648|Message=92019|LinkText=JeeLink / EC3000}} - Anfänge der Entstehung der EC3000 Unterstützung in Fhem.
* Hinweise zu {{Link2Forum|Topic=11648|Message=92037|LinkText=JeeLabs RoomNode}} und anderen JeeLab Nodes
* {{Link2Forum|Topic=25399|Message=183910|LinkText=JeeLink mit FHEM2FHEM nutzen}}

== Bekannte Probleme ==
* Beim Betrieb an einer [[AVM Fritz!Box|FritzBox]] wird der JeeLink unter Umständen als ''Für die Nutzung mit dem USB-Fernanschluss reserviert'' angezeigt. In diesem Fall muss die Reservierung deaktiviert/aufgehoben werden (Details dazu in diesem {{Link2Forum|Topic=16579|LinkText=Forenthread}}).
* Die Version ''v3c'' des JeeLink funktioniert (Stand 06/2015) nur mit dem LaCrosse Sketch. PCA301 und EC3000 Sketch sind auf den JeeLink Classic beschränkt (siehe unter anderem Diskussion im Forum, startend {{Link2Forum|Topic=11648|Message=308267|LinkText=hier}}).

== Weblinks ==
* [http://jeelabs.com/products/jeelink JeeLabs], JeeLink Hersteller
* [https://svn.fhem.de/trac/browser/trunk/fhem/contrib/arduino/ PCA301 Sketch] im SVN
* [https://svn.fhem.de/trac/browser/trunk/fhem/contrib/arduino/ LaCrosse Sketch] im SVN
* [https://svn.fhem.de/trac/browser/trunk/fhem/contrib/arduino/ EC3000 Sketch] im SVN
* [http://blog.moneybag.de/hausautomation-fhem-mit-funksteckdose-energiemessung-elv-pca-301/ Blog] zum Thema JeeLink zur Anbindung von PCA301 und von LaCrosse Temperatursensoren an Fhem
* {{Link2Forum|Topic=23217|LinkText=LevelSender}} Tankfüllstand mit JeeLink empfangen

[[Kategorie:Interfaces]]
[[Kategorie:Other Components]]
[[Kategorie:Temperatursensoren]]
[[Kategorie:Feuchtesensoren]]
[[Kategorie:Wetterstationen]]

JeeLink

2017-01-18T17:50:34Z

Mahowi: /* Weblinks */ Kategorien analog zum LaCrosseGateway hinzugefügt

'''JeeLink''' ist ein RF-Gerät im Formfaktor eines USB-Sticks mit externer Antenne.
{{Infobox Hardware
|Bild=JeeLink.jpg
|Bildbeschreibung=JeeLink mit Drahtantenne
|HWProtocol=PCA301, EC3000, RoomNode oder LaCrosse und EMT7110
|HWType=[[Interface]]
|HWCategory=
|HWComm=433/868/913 MHz
|HWChannels=?
|HWVoltage=5 V
|HWPowerConsumption=ca. 90 mA
|HWPoweredBy=USB
|HWSize=23*67*9mm
|HWDeviceFHEM=[http://fhem.de/commandref.html#JeeLink 36_JeeLink.pm]
|ModOwner={{Link2FU|430|Andre / justme1968}}
|HWManufacturer=JeeLabs
}}

== Beschreibung ==
Vergleichbar mit dem [[CUL]] von Busware, ist der JeeLink ein USB-Stick, mit dem Funk-Hausautomations-Komponenten angebunden werden können. CUL und JeeLink unterscheiden sich im Funkmodul (CUL -> CC1101; JeeLink -> RF12B), die nicht miteinander kompatibel sind. Daher kann man auch keinen CUL als JeeLink-Ersatz nutzen!

Den JeeLink gibt es in einer
* 433 MHz Version
* 868 MHz Version (Standard)
* 915 MHz Version (Betrieb in Europa nicht zugelassen)

== Vorbereitung JeeLink ==
Um mit dem JeeLink die jeweils gewünschten Signale empfangen zu können, ist er zunächst mit der passenden Firmware zu versorgen. Dies kann auf zwei Arten geschehen. Entweder durch das selber kompilieren der Software und das Flashen aus der Arduino IDE oder aus Fhem heraus mit einem aktuellen Firmwareimage das per update mit ausgeliefert wird.

=== Selber Kompilieren ===
[[Datei:JeeLink_flashen_1.jpg|mini|100px|rechts|Vorbereitung: Arduino einrichten]]
Um den JeeLink mit Fhem benutzen zu können, muss (mit der Arduino Software / Entwicklungsumgebung (IDE)) eine spezifische "Firmware" (ein Sketch) auf dem JeeLink installiert werden. Die generelle Vorbereitung für diese Aktion ist unabhängig vom benötigten Sketch und besteht aus den folgenden Schritten:
* Für Windows oder Mac OS X den passenden [http://www.ftdichip.com/Drivers/VCP.htm FTDI Treiber] installieren, unter Linux ist dieser meist schon vorhanden
* Installation der [http://arduino.cc/de/Guide/HomePage Arduino Software] für die benutzte Plattform (verfügbar sind Windows, Mac OS X und Linux)
* Je nach Sketch einbinden der [https://github.com/jcw/jeelib/archive/master.zip Jeelabs Library] in die Arduino IDE
* Herunterladen des benötigten Sketches (aus [https://svn.fhem.de/trac/browser/trunk/fhem/contrib/arduino FHEM/contrib])
* Anschließen des JeeLink an einen USB-Anschluss des Rechners mit der Arduino IDE
* Start der Arduino Software und JeeLink flashen

=== JeeLink aus Arduino flashen ===
[[Datei:JeeLink_flashen_2.jpg|mini|100px|rechts|JeeLink Flashen]]
* Anschließen des JeeLink an einen USB-Anschluss des Rechners mit der Arduino IDE
* Start der Arduino Software
* Seriellen Port des JeeLink auswählen
* Einstellungen: in den Tools als Board "Arduino Uno" auswählen
* Sketch mit "Datei öffnen" auswählen
* Upload klicken

=== JeeLink aus Fhem flashen ===
* Auf dem Fhem System muss <code>avrdude</code> installiert sein. Das kann z.B. über die "normale" Linux Paketverwaltung geschehen.
* mit <code>set <JeeLinkDevice> flash [firmware]</code> wird das Flashen angestossen<br><code>firmware</code> kann LaCrosse, PCA301 oder EC3000 sein. Wenn <code>firmware</code> nicht angegeben wird versucht FHEM den Namen der zu flashenden Firmware aus der zur Zeit installierten Firmware abzuleiten.
* im Fhem Log kann der Ausgang des Flashvorgangs kontrolliert werden
* über das <code>flashCommand</code> Attribut lässt sich das Kommando zum Flashen an besondere Anforderungen anpassen

'''Vorsicht bei Jeelink Clones!'''

Jeelink Clones basierend auf dem Arduino Nano haben normalerweise keinen Optibootloader drauf im Gegensatz zum Original JeeLink und JeeNode.

Konsequenz:

Beim "Nano Clone" und ähnliches muß man zum flashen in FHEM die Baudrate setzen mit "-b 57600"

Original JeeLink, original JeeNode, und alle Arduinos, die einen Optibootloader drauf haben flashen in FHEM ohne "-b 57600"

== Hinweise zum Betrieb mit Fhem ==
Um den JeeLink (erstmalig) mit Fhem benutzen zu können, muss dieser erfolgreich geflasht worden sein.
* JeeLink an den Fhem-Rechner anschließen
* Auf Linux Systemen kann es notwendig sein, mit <code>mknod /dev/ttyUSB0 c 188 0</code> das Device anzulegen (bitte erst überprüfen, ob der Stick nicht automatisch erkannt wird)

=== Definition in fhem.cfg ===
Erforderliche Definitionen in Fhem:
:<code>define myJeeLink JeeLink /dev/ttyUSBx@57600</code>
*'''USBx''' ist anzupassen an die aktuell benutzte Schnittstelle, 0 wenn sonst nichts am USB-Port hängt
*x=0,1,2, usw.

Die [http://fhem.de/commandref.html#autocreate autocreate-Funktion] sollte aktiv sein. Alle erkannten Devices (PCA301, LaCrosse Sensoren incl. IT+ Wetterstation WS1600, EMT7110, EC3000, und RoomNodes) werden dann automatisch angelegt, sobald die jeweiligen Daten empfangen werden.

Pro Geräte-Art/Protokoll muss ein eigener JeeLink mit dem passenden Sketch zum Empfang dieser Daten vorhanden sein (es kann jeweils nur ein Sketch im JeeLink aktiv sein und es gibt (zumindest derzeit (04/2014)) keinen Sketch, der mehr als eines der Protokolle abdeckt).

'''Anmerkung:''' Der LaCrosse Sketch deckt sowohl die LaCrosse Temperatursensoren, die IT+ Wetterstation WS1600 als auch den Energieverbrauchssensor EMT7110 ab.

=== PCA301 Sketch ===
Der Sketch für die Unterstützung der ''PCA301 Funkschaltsteckdose mit Energieverbrauchsmessung'' (PCA301-pcaSerial.zip) kann aus dem [https://svn.fhem.de/trac/browser/trunk/fhem/contrib/arduino/ FHEM-Repository] heruntergeladen werden. Details zur Benutzung finden sich im Artikel zur [[PCA301 Funkschaltsteckdose mit Energieverbrauchsmessung|PCA301]].

Unter Umständen werden die Signale der PCA301 nicht empfangen. Insbesondere mit selbst erstellten "JeeLinks" durch wahrscheinlich hohe Bauteiltoleranzen der RF12B Sendeeinheiten. Mit dem im Sketch voreingestellten rf12_center_freq = 0xA6FE (868,9500 MHz) bekommt man in diesem Fall keine Steckdose angelernt.

==== Frequenzanpassung über modifizierten Sketch ====
Durch Tests mittels ''set <myJeeLink> raw +'' bzw ''set <myJeeLink> raw -'' kann man dann ermitteln, ob die Funksignale z.B. ab A703 bis A715 empfangen werden. Das entspricht einem Frequenzbereich zwischen 868,9750 MHz und 869,0550 MHz.
Die Mitte ist die Lösung, die man dann im Sketch ändern muss:
:<code>static uint16_t rf12_center_freq = 0xA70C;</code>
Anschließend auf den JeeLink neu flashen.

==== Frequenzanpassung über Attribut initCommands ====
Über das <code>initCommands</code> lässt sich die gefundene Frequenz einstellen, ohne dass die Firmware verändert werden muss.
:<code>attr <JeeLinkDevice> initCommands <hhhh>h</code>

=== LaCrosse Sketch ===
Der Sketch für die Unterstützung der LaCrosse Temperatursensoren, der IT+ Wetterstation WS1600 und des Energieverbrauchssensors EMT7110 so wie auch TechnoLine Sensoren (Temperatur, Luftfeuchte,...).<br>

* Er kann aus dem [https://svn.fhem.de/trac/browser/trunk/fhem/contrib/arduino FHEM-Repository] heruntergeladen werden.
* Alternative ist den Sketch direkt über Fhem zu flashen <code>set <JeeLinkDevice> flash LaCrosse</code> z.B.: <code>set myJeeLink flash LaCrosse</code> zuvor sollte aber ein Fhem update mit <code>update</code> durchgeführt werden.
<br>

'''Sensoren anlernen:
Mit folgenden Befehl hat man die Möglichkeit 60 Sekunden ein Gerät anzulernen. Das Gerät erscheint dann unter der Rubrik LaCrosse. <code>set <JeeLinkDevice> LaCrossePairForSec 60</code> zum Beispiel: <code>set myJeeLink LaCrossePairForSec 60</code>.

'''In der neuesten Version unterstützt er auch den SuperJee''' (siehe auch diesen {{Link2Forum|Topic=14786|Message=316924|LinkText=Forenbeitrag}}) mit folgenden Optionen:

* Option 1 (Dual RFM):
:Es kann ein zweiter RFM12B oder RFM69CW angeschlossen werden. Somit können zwei data rates (z.B. 17241 für TX29DTH und 8842 für WS 1600) gleichzeitig empfangen werden. Das geht natürlich auch mit dem toggle mode, nur ist es bei der Wetterstation ärgerlich, wenn man 30 Sekunden lang nichts empfängt und dadurch die alles entscheidende Windböe verpasst.
* Option 2 (BMP180):
:Da der Luftdruck in den Basisstationen gemessen wird, steht er für FHEM nicht zur Verfügung.
Deshalb kann nun optional ein BMP180 oder BMP085 angeschlossen werden. Auch hier wird automatisch erkannt, ob er vorhanden ist.
:Der BMP180 wird mit 3,3V versorgt und SDA mit PC4 und SCL mit PC5 verbunden (siehe die in diesem {{Link2Forum|Topic=14786|Message=316924|LinkText=Forenbeitrag}} angehängte SuperJee-CL.png)

==== Übersicht Kommandos ====
<n>a set to 0 if the blue LED bothers
<n>f initial frequency in kHz (5 kHz steps, 860480 ... 879515) (for RFM #1)
<n>F initial frequency in kHz (5 kHz steps, 860480 ... 879515) (for RFM #2)
<n>h altituide above sea level
<n>m bits 1: 17.241 kbps, 2 : 9.579 kbps, 4 : 8.842 kbps (for RFM #1)
<n>M bits 1: 17.241 kbps, 2 : 9.579 kbps, 4 : 8.842 kbps (for RFM #2)
<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>t 0=no toggle, else interval in seconds (for RFM #1)
<n>T 0=no toggle, else interval in seconds (for RFM #2)
v show version
<n>y if 1 all received packets will be retransmitted (Relay mode)

==== Relay-Betrieb ====
Der LaCrosse Sketch ermöglicht auch den Relay-Betrieb zur Reichweitenverbesserung. Er funktioniert damit ähnlich wie z. B. ein WLAN Range Extender. Wenn der Sketch für den Relay-Betrieb konfiguriert ist, wird jedes empfangene IT+ Datenpaket, das eine gültige Prüfsumme hat, direkt nach dem Empfang wieder gesendet.

Das Prinzip ist generell recht einfach:
# JeeLink im Sketch als Relais konfigurieren und flashen.
# Auf "halber Strecke" (d.h. irgendwo zwischen dem primären Sender und dem entfernten Empfänger) auf ein USB-Steckernetzteil stecken. Der JeeLink arbeitet in diesem Modus "autonom", er benötigt also lediglich einen Spannungsversorgung.

Der JeeLink empfängt und decodiert alle Protokolle, die er auch für FHEM unterstützt. Wenn er ein Paket empfangen hat (egal von welchem Sensor) und CRC OK war, dann sendet er es wieder aus. Der JeeLink am FHEM merkt keinen Unterschied. Falls ein Paket es doch bis zum FHEM direkt geschafft hat, kommt es dort zweimal an. Diese Situation muss in Fhem behandelt werden.

Details zu diesem Betriebsmodus sind in diesen Forenbeiträgen ({{Link2Forum|Topic=14786|Message=165153|LinkText=LaCrosse}} bzw. {{Link2Forum|Topic=26494|Message=196648|LinkText=EMT7110}}) zu finden.

==== Frequenzanpassung ====
Ab Version LaCrosseITPlusReader.10.1e wurde der Sketch so erweitert, dass man von FHEM aus die Frequenz setzen kann. Dazu versteht der Sketch das neue Kommando "f":
:<code>set myJeeLink raw 868295f</code>
setzt die Frequenz auf 868295 kHz.

Die Frequenz kann im Bereich von 860480 kHz bis 879515 kHz in 5kHz -Schritten eingestellt werden.
Details dazu in diesem {{Link2Forum|Topic=14786|Message=222541}} im Forum. Die Frequenzanpassung ist insbesondere beim 30.3155.WD häufig erforderlich, weshalb er als kritisch einzustufen und nicht zu empfehlen ist (siehe {{Link2Forum|Topic=14786|Message=352550|LinkText=Forenbeitrag}}).

==== Toggle und Datenrate ====
Toggle
t: toggle time
20t = alle 20 Sekunden die Datenrate wechseln

Datenrate
m: toggle mode
bits: 1= 17.241 kbps, 2= 9.579 kbps, 4= 8.842 kbps
3m ist 17.241 kbps (TX29) und 9.579 kbps (TX35)

Beispiel initCommands
6m 30t v
Zwischen 8.842 kbps und 9.579 kbps wechseln (4+2=6), alle 30 Sekunden

==== Getestete iT+ Sensoren incl. Wetterstation WS 1600 ====
{{Randnotiz|RNTyp=y|RNText=Die Ausführungen in diesem Abschnitt gelten ab der Version 10.1q auch für die Wetterstation WS1080.

'''Wichtig WS1800''': die WS1080 gibt es (unter gleichem Namen) in einer "OOK"- und in einer "FSK"-Version.
* Der LaCrosse Sketch und das LaCrosseGateway können nur die FSK-Version empfangen, die OOK-Version wird nicht unterstützt.
* Die FSK-Version ist zu erkennen an einem runden grünen Aufkleber im Batteriefach der Station mit dem Aufdruck "PASS 7". Details dazu in {{Link2Forum|Topic=14786|Message=363766|LinkText=diesem Forenbeitrag}}
<br/><br/>'''Wichtig: TFA 30.3187.IT'''<br>
Es wird von Anwendern berichtet, dass sie mehrere TFA 30.3187.IT gekauft haben, die alle die gleiche ID hatten. Dieser Sensor ist also nicht zu empfehlen, wenn man mehrere davon verwenden will.
}}

Die in der folgenden Liste (Quelle: {{Link2Forum|Topic=14786|Message=164801|LinkText=Fhem Forum}}) aufgeführten Sensoren wurden bisher erfolgreich getestet:

{| class="wikitable"
!Bezeichnung !! Datenrate !! Link
|-
| TX21IT || 17.241 kbps
|-
| TX25-IT || 17.241 kbps
|-
| TX27-IT || 17.241 kbps
|-
| TX29-IT || 17.241 kbps
|-
| TX29DTH-IT || 17.241 kbps
|-
| TX37 || 17.241 kbps
|-
| TX35TH-IT || 9.579 kbps
|-
| TX35DTH-IT || 9.579 kbps
|-
| 30.3143.IT || 17.241 kbps
|-
| 30.3144.IT || 17.241 kbps || ({{Link2Forum|Topic=17662|LinkText=Forenthread}})
|-
| 30.3147.IT || 17.241 kbps
|-
| 30.3155WD || 9.579 kbps || kritisch; nicht zu empfehlen; siehe {{Link2Forum|Topic=14786|Message=352550|LinkText=Forenbeitrag}}
|-
| 30.3156WD || 9.579 kbps || Batterie-kritisch. Funktioniert schlecht mit Akkus!
|-
| 30.3187.IT || 17.241 kbps || kritisch, siehe Randnotiz
|-
|| WS 1600 || 8.842 kbps || ({{Link2Forum|Topic=14786|Message=297293|LinkText=Forenbeitrag}})
|-
|| WS 1080 || 17.241 kbps || ({{Link2Forum|Topic=14786|Message=363766|LinkText=Forenbeitrag}})
|}

==== EMT7110 ====
Der [[EMT7110]] läuft mit einer Datenrate von 9.579 kbps (Details dazu in diesem {{Link2Forum|Topic=26494|LinkText=Forenthread}}).

Werden Sensoren mit unterschiedlichen Datenraten gleichzeitig betrieben, ist der Toggle Modus einzustellen, z.B. mit dem Befehl
:<code>initCommands 30t v </code>
wobei ''30t'' für "Toggle Modus, alle 30 Sekunden" steht.

=== Energy Count 3000 Sketch ===
Der Sketch für die Unterstützung der Energy Count 3000 Zwischenstecker kann aus dem [https://svn.fhem.de/trac/browser/trunk/fhem/contrib/arduino/ FHEM-Repository] heruntergeladen werden.

Das Fhem Modul dazu (36_EC3000.pm) ist genau wie die Module für JeeLink (36_JeeLink.pm) und PCA301 (36_PCA301.pm) mittlerweile im aktuellen Fhem enthalten.

=== JeeLabs RoomNode ===
Eine Beschreibung zum Empfang der JeeLabs RoomNodes ist in {{Link2Forum|Topic=11648|Message=92037|LinkText=diesem Forenbeitrag}} enthalten.

=== JeeLink LED deaktivieren ===
Ein "dauerhaftes" Deaktivieren der LED des JeeLink ist möglich mit
:<code>define not.global notify global:INITIALIZED set myJeeLink led off</code>
damit wird, sobald Fhem komplett gestartet ist, von Fhem der Befehl zum Ausschalten der LED gesendet. Alternativ kann mit
:<code>attr myJeeLink initCommands 0a v</code>
dem Sketch die Anweisung gegeben werden, bei der Initialisierung die LED zu deaktivieren.
''Quelle: dieser {{Link2Forum|Topic=27161|LinkText=Forenthread}}''

=== Weitergehende Informationen ===
Hinweise zum Betrieb eines JeeLink mit Fhem finden sich aktuell in größerer Anzahl in verschiedenen Diskussionen im Forum:
* {{Link2Forum|Topic=11648|LinkText=JeeLink / PCA301}} - Analyse des Funkprotokolls; Anfänge der Entstehung der PCA301 Unterstützung in Fhem.
* {{Link2Forum|Topic=14786|LinkText=JeeLink / LaCrosse}} - JeeLink Modul zur Einbindung von La Crosse
* {{Link2Forum|Topic=11648|Message=92019|LinkText=JeeLink / EC3000}} - Anfänge der Entstehung der EC3000 Unterstützung in Fhem.
* Hinweise zu {{Link2Forum|Topic=11648|Message=92037|LinkText=JeeLabs RoomNode}} und anderen JeeLab Nodes
* {{Link2Forum|Topic=25399|Message=183910|LinkText=JeeLink mit FHEM2FHEM nutzen}}

== Bekannte Probleme ==
* Beim Betrieb an einer [[AVM Fritz!Box|FritzBox]] wird der JeeLink unter Umständen als ''Für die Nutzung mit dem USB-Fernanschluss reserviert'' angezeigt. In diesem Fall muss die Reservierung deaktiviert/aufgehoben werden (Details dazu in diesem {{Link2Forum|Topic=16579|LinkText=Forenthread}}).
* Die Version ''v3c'' des JeeLink funktioniert (Stand 06/2015) nur mit dem LaCrosse Sketch. PCA301 und EC3000 Sketch sind auf den JeeLink Classic beschränkt (siehe unter anderem Diskussion im Forum, startend {{Link2Forum|Topic=11648|Message=308267|LinkText=hier}}).

== Weblinks ==
* [http://jeelabs.com/products/jeelink JeeLabs], JeeLink Hersteller
* [https://svn.fhem.de/trac/browser/trunk/fhem/contrib/arduino/ PCA301 Sketch] im SVN
* [https://svn.fhem.de/trac/browser/trunk/fhem/contrib/arduino/ LaCrosse Sketch] im SVN
* [https://svn.fhem.de/trac/browser/trunk/fhem/contrib/arduino/ EC3000 Sketch] im SVN
* [http://blog.moneybag.de/hausautomation-fhem-mit-funksteckdose-energiemessung-elv-pca-301/ Blog] zum Thema JeeLink zur Anbindung von PCA301 und von LaCrosse Temperatursensoren an Fhem
* {{Link2Forum|Topic=23217|LinkText=LevelSender}} Tankfüllstand mit JeeLink empfangen

[[Kategorie:Interfaces]]
[[Kategorie:Other Components]]
[[Kategorie:Temperatursensoren]]
[[Kategorie:Feuchtesensoren]]
[[Kategorie:Wetterstationen]]

LaCrosse

2017-01-18T17:47:18Z

Mahowi: /* Voraussetzungen */ Hinweis auf LaCrosseGateway als IODev

{{Infobox Modul
|ModPurpose=Unterstützung von La Crosse Sensoren
|ModType=d
|ModCmdRef=LaCrosse
|ModForumArea=Sonstige Systeme
|ModTechName=36_LaCrosse.pm
|ModOwner=HCS ({{Link2FU|6609|Forum}}) }}
Das Modul [[LaCrosse]] unterstützt [https://www.lacrossetechnology.com/sensors.php La Crosse] Temperatur- und (Luft)Feuchtesensoren und Wetterstationen wie die WS 1600 (TX22 Sensoren).

== Voraussetzungen ==
Um ''LaCrosse''-Geräte nutzen zu können, wird ein [[JeeLink]] [[Interface]] oder ein [[LaCrosseGateway]] als IODevice benötigt, auf dem der LaCrosse Sketch installiert ist.

== Anwendung ==
Neue Sensoren werden nur automatisch angelegt, wenn ''LaCrossePairForSec'' auf dem IODevice aktiviert ist.

=== Define ===
Die Syntax für das manuelle Anlegen eines Sensors ist der commandref zu entnehmen.

=== Attribute ===

== Anwendungsbeispiele ==

== Links ==
* ...

[[Kategorie:Temperatursensoren]]
[[Kategorie:Feuchtesensoren]]
[[Kategorie:Wetterstationen]]

LaCrosseGateway V1.x

2017-01-11T22:10:12Z

Mahowi: /* Unterstützte Sensoren und Aktoren */ Hinweis zu 30.3187.IT hinzugefügt

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

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 />[https://forum.fhem.de/index.php/topic,45594.msg430183.html#msg430183 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)
*Steckbrett (inkl. Kabel/Widerstände)/Lochrasterplatine (Lötkolben, Lötzinn, Widerstände etc.)) / [[#Platine|PeMue Platine]]

==Schaltung==
===Variante: Devkit 1.0===
[[Datei:lgw_Schaltplan_Devkit.png|400px|thumb|left|Variante: Devkit 1.0]]
<div style="clear:both;"></div>
===Variante: ESP8266-12E===
[[Datei:lgw_Schaltplan_FTDI.png|400px|thumb|left|Variante: FTDI]]
<div style="clear:both;"></div>
===Variante: Platine (PeMue)===
[[Datei:lgw_Schaltplan_Platine.png|400px|thumb|left|Variante: Platine (PeMue)]]
<div style="clear:both;"></div>
===Addon Schaltung===
[[Datei:lgw_Addon-with-example.png|400px|thumb|left|Die Schaltung des kompletten AddOn mit allen aktuell möglichen Optionen]]
<div style="clear:both;"></div>
Siehe [[#Erweiterungsmöglichkeiten | Erweiterungsmöglichkeiten]].
===MCP2308===
I2C Adresse 0x27 -> A0,A1,A2 = 3.3V
<source 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
|----------------|</source>

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

'''''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:
<source 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</source>

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

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

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

'''LaCrosse:'''

Format:<source lang="php">LC <Address> T=<Temperature>,H=<Humidity></source>
Beispiel:
<source lang="php">LC 9F T=21.5,H=62</source>
<source lang="php">LC 9F T=21.5</source>
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, die auch vom "LaCrosse Arduino" Sketch unterstützt werden, incl. WS 1600 und WS 1080 (Hinweis beachten)
siehe [[JeeLink#LaCrosse_Sketch |LaCrosse Sketch]]

{| class="wikitable"
!Bezeichnung !! Datenrate !! Sonstiges !!Funktion !!Link / Hinweise
|-
| TX21IT || 17.241 kbps ||extern||||
|-
| TX25-IT || 17.241 kbps ||extern||||
|-
| TX27-IT || 17.241 kbps ||extern||||
|-
| TX29-IT || 17.241 kbps ||extern||||
|-
| TX29DTH-IT || 17.241 kbps ||extern||||
|-
| TX37 || 17.241 kbps ||extern||||
|-
| TX35TH-IT || 9.579 kbps ||extern||||
|-
| TX35DTH-IT || 9.579 kbps ||extern||||
|-
| 30.3143.IT || 17.241 kbps ||extern||||
|-
| 30.3144.IT || 17.241 kbps ||extern|||| ({{Link2Forum|Topic=17662|LinkText=Forenthread}})
|-
| 30.3147.IT || 17.241 kbps ||extern||||
|-
| 30.3155WD || 9.579 kbps ||extern|||| kritisch; nicht zu empfehlen; siehe {{Link2Forum|Topic=14786|Message=352550|LinkText=Forenbeitrag}}
|-
| 30.3156WD || 9.579 kbps ||extern|||| Batterie-kritisch. Funktioniert schlecht mit Akkus!
|-
| 30.3187.IT || 17.241 kbps ||extern|||| haben alle die gleiche ID, daher nur einzeln verwendbar ({{Link2Forum|Topic=64636|LinkText=Forenthread}})
|-
| WT440XH || 17.241 kbps ||extern||||
|-
| WS 1600 (TX22) || 8.842 kbps || extern |||| ({{Link2Forum|Topic=14786|Message=297293|LinkText=Forenbeitrag}})
|-
| WS 1080 || 17.241 kbps || extern |||| Bitte Hinweise beachten! ({{Link2Forum|Topic=14786|Message=363766|LinkText=Forenbeitrag}})
|-
| [[EMT7110]] || 9.579 kbps || extern |||| ({{Link2Forum|Topic=26494|LinkText=Forenthread}})
|-
| LevelSender || 17.241 kbps || extern ||||
|-
| PCA301 ||868950 kHz (868,970 und 868,990 ) 6.631 kbps || extern || Energiemess-Steckdose (Unterstützung 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||

|}

Hinweis zur WS 1080: Die WS 1080 gibt es (unter gleichem Namen) in einer OOK- und in einer FSK-Version
Der LaCrosse Sketch und das LaCrosseGateway können nur die FSK-Version empfangen, die OOK-Version nicht.
Die FSK-Version erkennt man an dem grünen Aufkleber im Batteriefach der Station mit dem Aufdruck "PASS 7". Nur diese Version kann empfangen werden.
Die OOK-Version erkennt man an dem grünen Aufkleber im Batteriefach der Station mit dem Aufdruck "PASS A14C".

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)

==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:
<source lang="php">
esptool -vv -cp [Port] -cb 921600 -ca 0x00000 -cd nodemcu -cf [Pfad zur Firmware (bin-File)]</source>
'''[Port]''' und '''[Pfad zur Firmware (bin-File)]''' müssen angepasst werden.

''Beispiel (Mac/Linux):''

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

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

===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
<source lang="php">set myLaCrosseGateway flash</source> aktualisiert werden.
'''''myLaCrosseGateway''' muss bei Bedarf auf den Gerätenamen in FHEM angepasst werden.''

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

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

'''''Beispiel:'''''
<source 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</source>

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

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

Beispiel:
<source 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></source>

===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:
<source lang="php">http://<LGW-IP>/getLogData</source>

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

das Ergebnis sieht wie folgt aus:
<source 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</source>

'''''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:
<source lang="php">sudo apt-get install libwww-perl</source>
alternativ auch mit
<source lang="php">sudo cpan LWP::UserAgent</source>

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

==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:'''
<source lang="php">define myLaCrosseGateway LaCrosseGateway 192.168.22.33:81</source>
<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:
<source 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</source>
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:
<source 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;</source>

==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:
<source lang="php">attr myLaCrosseGateway timeout 120,30</source>
'''''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]

<source 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
</source>

==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: <source lang="php">8266e</source>
Er kann mit einem Terminalprogramm, von FHEM aus mit <source lang="php">set <myLaCrosseGateway> raw 8266e</source> 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.
<source lang="php">set myLaCrosseGateway LaCrossePairForSec 120 ignore_battery</source>

==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:
<source lang="php">set myLaCrosseGateway LaCrossePairForSec 120 ignore_battery</source>

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.
<source lang="php">define <name> LaCrosse 00</source>
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.''
<source lang="php">attr myLaCrosseGateway initCommands 220h</source>

'''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:'''
<source 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
</source>

==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:
<source lang="php">
#1 (Erste) => 17241
#2 (Zweite) => 9579
#3 (Dritte) => 8842
#4 (Vierte) => 20000
#5 (Fünfte) => 17241
</source>

'''''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
|-
| <source lang="php">attr myLaCrosseGateway initCommands 0#1r v</source>
| DataRate des ersten RFM setzen
|-
| <source lang="php">attr myLaCrosseGateway initCommands 8842#3r v </source>
| DataRate des dritten RFM setzen
|-
| <source lang="php">attr myLaCrosseGateway initCommands 868300#2f v</source>
| Frequenz des zweiten RFM setzten
|-
| <source lang="php">attr myLaCrosseGateway initCommands 868295#3f v</source>
| Frequenz des dritten RFM setzten
|-
| <source lang="php">attr myLaCrosseGateway initCommands 17241#1r 8842#2r v</source>
| Zwei RFM69CW mit DataRate 17241 und 8842
|-
| <source lang="php">attr myLaCrosseGateway initCommands 3#1m 20#1t 8842#2r v</source>
| Zwei RFM69CW mit 20 Sekunden DataRate 17241 toggle 9579 plus 8842 permanent
|-
| <source lang="php">attr myLaCrosseGateway initCommands 220h 868295#1f 868310#2f v</source>
| Zwei RFMs Frequenz 868295 und 868310 sowie Höhe über NN
|-
| <source lang="php">attr myLaCrosseGateway initCommands 868295#1f 3#1m 20#1t 2,868950,60i 8842#3r 220h 0a v</source>
| 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:'''
<source lang="php">attr myLaCrosseGateway initCommands 9#2m 20#2t v</source>

==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''
<source lang="php">OK VALUES LGPB 211 GP2=0,GP3=1,GP4=0,GP5=0,GP6=0,GP7=0</source>

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

==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.
Um auf dem 1.3" Display eine korrekte Darstellung zu erhalten, muss man die Checkbox 1.3" ankreuzen.

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

==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):
<source lang="php">define CULXYZ CUL <IP-Adresse>:85 0000</source>
'''''<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:

<source 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");;\
}\
\
} </source>
'''''<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''
<source lang="php">./esptool -vv -cp /dev/tty.SLAB_USBtoUART -cb 115200 -ca 0x00000 -cd nodemcu -ce</source>

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

=Weiterführende Links=
Diskussionsthread aus dem Forum:

[https://forum.fhem.de/index.php/topic,43672.0.html LaCrosseGateway - LaCrosse, PCA301 und EC3000 über wifi mit ESP8266 ohne Arduino]

[https://forum.fhem.de/index.php/topic,45594.0.html Platine für LaCrosseGateway: Platinenbestellung]

[https://forum.fhem.de/index.php/topic,51329.30.html Platine für nanoLGW (LaCrosse Gateway): Layout]

[https://forum.fhem.de/index.php/topic,52921.0.html Display für LaCrosseGateway]

[https://forum.fhem.de/index.php/topic,52895.0.html SC16IS750-Software-Clone]

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

OpenWRT

2016-12-06T18:26:50Z

Mahowi: Voraussetzungen für "make menuconfig" hinzugefügt

== Einleitung ==

Hier sind zwei alternative Installationswege beschrieben.

* Im ersten Kapitel wird beschrieben, wie Openwrt auf einem Gerät mit wenig(er) internem Speicher eingerichtet werden kann. Hier wird OpenWRT zuerst aus den Sourcen erstellt und ein Overlay für die PERL-Pakete eingerichtet.
* Das zweite Kapitel beschreibt, wie OpenWRT mit PERL im internen Speicher (6MB) installiert wird. Es werden keine Pakete selbst gebaut, sondern die Nightly-Snapshots verwendet. FHEM wird auf einem USB-Stick eingerichtet.

== Installation von FHEM incl. OpenWRT auf einem Router/Kleinstcomputer z.B. TP-LINK MR3020 ==
Wer nicht unbedingt eine Fritz!Box braucht sondern einfach nur FHEM ohne laufenden PC betreiben will, kann auch OpenWRT auf einem Router nutzen, z.B. dem sehr günstigen (25 Euro März 2012) und stromsparenden (ca. 1 Watt) TP-LINK MR3020.

Bitte beachten: Es kann keine Garantie übernommen werden, dass der Router bei Befolgung dieser Anleitung "kaputt" geht, z.B. dadurch, dass er bei Fehlkonfiguration im Netz nicht mehr erreichbar ist. Der Umbau erfolgt auf eigene Gefahr.

=== Vorraussetzungen ===
* Der Router (in diesem Howto ist der TP-LINK MR3020 verwendet worden, OpenWRT wird aber prinzipiell immer gleich aufgesetzt
* Ein USB Stick, da die Flash-Speicher der Router zu klein sind
* optional ein passiver USB-Hub (wenn der Router nur einen USB Port hat und ein CUL Stick betrieben werden soll)
* Ein Linux-PC zum Erstellen des Images. Dies kann auch eine virtuelle Maschine sein. Der Autor hat Ubuntu 10.11 verwendet.
=== Vorbereiten des USB-Sticks ===
Auf einem USB Stick müssen zwei Partitionen angelegt werden, eine als Auslagerungsspeicher für den RAM und eine für das Dateisystem auf dem später auch Perl und FHEM installiert werden. Das geht am besten mit dem Tool <code>fdisk</code> auf dem vorbereiteten Linux-PC. Dazu den Stick anstöpseln und per Aufruf von <code>fdisk -l</code> die Lister der gefundenen "Festplatten" anzeigen lassen. Eine davon ist der USB-Stick, z.B. an seiner Größe zu erkennen (500Mb reichen locker aus). In der Ausgabe z.B. nach einer Zeile suchen, die sinngemäß so aussieht: <code>Disk /dev/sdc: 484 MB, 484442112 bytes</code>. In diesem Fall ist der USB-Stick das Gerät "/dev/sdc".

Daraufhin kann fdisk für das Gerät aufgerufen werden. Detaillierte ANleitungen für fdisk finden sich im Internet. Vereinfacht ist folgender Vorgang auszuführen (alle Daten gehen auf dem Stick verloren!).

<source lang=bash>
fdisk /dev/sdc
o
n
p
1
1
+64M
n
p
2 (drei mal Enter drücken)
t
1
82
w
</source>

Danach ist der Stick partitioniert. Ein erneuter Aufruf von <code>fdisk -l</code> sollte ungefähr folgendes ERgebnis liefern:

Disk /dev/sdc: 484 MB, 484442112 bytes
2 heads, 63 sectors/track, 7509 cylinders
Units = cylinders of 126 * 512 = 64512 bytes
Disk identifier: 0x8c5e341e
Device Boot Start End Blocks Id System
/dev/sdc1 1 993 62527+ 82 Linux swap / Solaris
/dev/sdc2 994 7509 410508 83 Linux

Jetzt müssen die Partitionen noch formatiert werden. Vorsicht: Nur hier heisst der Stick /dev/sdc. Er kann auch anders heissen! Wenn ihr die falschen Namen verwendet, könntet ihr eure Festplatte löschen! /dev/sdc1 ist durch /dev/<euer-sdx>1 zu ersetzen

<source lang=bash>
mkswap /dev/sdc1
mkfs.ext4 /dev/sdc2
sync
</source>

Der Stick ist nun fertig vorbereitet und wird im Linux-PC nicht mehr benötigt. Er kann jetzt in den Router

=== Bauen des OpenWRT-Images ===
Um OpenWRT zu bauen, müssen die entsprechenden Werkzeuge auf dem Linux-PC installiert sein. Unter Ubuntu geht das so:
<source lang=bash>
sudo apt-get -y install build-essential libncurses5-dev zlib-dev libssl-dev git-core
</source>

OpenWRT kann am besten von GitHub ausgecheckt werden.
<source lang=bash>
git clone git://github.com/openwrt/openwrt.git
</source>

Das Auschecken dauert eine Weile, aber das ist noch gar nichts, das Bauen dauert noch viel länger. Sobald alles runtergeladen ist, wird in das Verzeichnis gewechselt und die Konfiguration vorgenommen
<source lang=bash>
cd openwrt
make menuconfig
</source>

Für die Konfiguration muss die Architektur des Routers bekannt sein. Diese kann auf der [http://www.openwrt.org OpenWRT-Seite] nachgeschlagen werden. der TP-LINK MR3020 hat eine <code>ar71xx</code>-Architektur.

Als erstes also die Architektur auswählen (Hier: <code>ar71xxx/ar91xxx</code>)
Zweitens kann beim Target-Profile meinst genau der Router ausgewählt werden (Notfalls auf der OpenWRT-Seite nachlesen)

Optional kann nun unter <code>Image-Configuration</code> bereits eine Netzwerkkonfiguration eingestellt werden, die der Router dann nach seinem Hochfahren hat. Wenn der Router in ein bestehendes Netz mit bestehenden DHCP-Server und Adressraum eingebunden wird, ist das sinnvoll. Wer das hat, weiss auch, was hier einzustellen ist. Standardmäßig ist die Adresse 192.168.1.1 vorgegeben. Die Konfiguration kann auch später jederzeit geändert werden.

Nun zu den Kernel-Modules. Hier sollte folgendes aktiviert werden (Einiges ist ggf. nicht nötig, aber so geht es). Die Einträge müssen mit "*" und nicht mit "M" selektiert sein, sonst kommen sie nicht ins Image.

* Block-Devices
** kmod-ide-core
** kmod-ide-generic
** kmod-loop (kann man immer mal brauchen)
** kmod-scsi-generic
* Filesystems
** kmod-fs-ext4 ''(davon wollen wir später vom USB-Stick booten)''
* USB-Support
** kmod-usb-acm ''(für CUL)''
** kmod-usb-hid
** kmod-usb-ohci
** kmod-usb-serial
** kmod-usb-serial-ftdi
** kmod-usb-storage-extras
** kmod-usb-uhci
** kmod-usb2

Unter Utilities noch folgendes aktivieren
* Filesystem
** e2fsprogs
* disc
** fdisk ''(für Analysezwecke sinnvoll)''
** swap-utils

Nun kann - in aller Ruhe - alles gebaut werden durch Eingabe von
<source lang=bash>
make
</source>

=== Vorbereiten des Routers ===
Das ganze kann bis zu mehrere Stunden laufen. Nun ist Zeit, den Router ins Netzwerk einzubinden. Wie genau, hängt von der persönlichen Konstellation ab. Der TP-Link MR3020 hat standardmäßig die IP-Adresse 192.168.0.254. Viele andere Router haben z.B. 192.168.0.1. Ich empfehle, das Update auf jeden Fall nicht über WLAN sondern ein Netzwerkkabel zu machen. Die meisten Router haben einen aktivierten DHCP-Server. Ein angestöpselter Windows-PC bekommt dann von ihm eine IP-Adresse zugewiesen. Beim MR3020 kann dann die Weboberfläche über [http://192.168.0.254 http://192.168.0.254] erreicht werden. (User/Passwort: admin/admin)

=== Installation von OpenWRT auf dem Router ===
In der Weboberfläche des Routers gibt es irgendwo einen Menüpunkt zum Firmware-Upgrade. Beim MR3020 erreichbar unter System Tools / Firmware Upgrade. Sobald das Bauen von OpenWRT fertig ist, liegt das Image im Unterordner <code>bin/<architektur>/</code>. Es sollte das Image genommen werden, was den Namen des Routers sowie "squashfs" sowie "factory" im Dateinamen enthält. Dieses muss jetzt im Webinterface wie beschrieben ausgewählt werden und hochgeladen werden. Alle Bestätigungsmeldungen und "Wollen-Sie-Das-auch-Wirklich"-Fragen natürlich bestätigen.

Nach einer Weile sollte dann der Router unter 192.168.1.1 anpingbar sein (von Linux aus: <code>ping 192.168.1.1</code>) bzw. unter der in der Image Configuration eingestellten IP. Wenn das nicht geht, kann man den Router auch ein 2. mal starten, da sollte man dann aber nach dem Flashen mal 10 Minuten Geduld haben (also Stecker raus/rein). Auf keinen Fall zu früh machen, dann könnte es sein, dass er gar nicht mehr hochfährt!

Zunächst muss man sich nun per telnet verbinden.
<source lang=bash>
telnet 192.168.1.1
</source>
Nun ist man schon im OpenWRT eingeloggt. Das erste und einzige, was in diesem Login nun gemacht wird, ist, per
<source lang=bash>
passwd
</source>
ein Passwort zu setzen. Danach kann man sich mit
<source lang=bash>
exit
</source>
ausloggen. Ab jetzt ist <code>telnet</code> zur Sicherheit deaktiviert und man kann per <code>ssh</code> eine Verbindung herstellen, da ja jetzt ein Passwort gesetzt ist
<source lang=bash>
ssh root@192.168.1.1
</source>
Für den weiteren Verlauf ist es notwendig, dass der Router Internetzugang hat. Dazu muss man ggf. von Hand in der Datei <code>/etc/config/network</code> die Netzwerkeinstellungen entsprechend anpassen.
<source lang=bash>
vi /etc/config/network
</source>
Zur Bedienung von vi z.B. [http://wiki.openwrt.org/doc/uci/network hier]

Wichtig ist die IP-Adresse, die Netzmaske, das Gateway und der DNS-Server. Bitte genau auf Tippfehler achten. Bei einer fehlenden Konfiguration ist der Router nicht mehr erreichbar. Nach abspeichern kann die neue Konfiguration aktiviert werden
<source lang=bash>
/etc/init.d/network restart
</source>
Falls sich auch die IP-Adresse geändert hat, mit ssh wie oben neu anmelden. Als nächstes soll der USB-Stick eingebunden werden, dazu sind einige Pakete zu installieren. OpenWRT hat einen eingebauten Paketmanager zur Nachinstallation von Software direkt aus dem Netz. Zunächst wird nur das installiert, was in den internen Speicher des Routers muss. Das Root-Dateisystem soll anschließend durch den USB-Stick erweitert werden, um dann dorthin die meiste Software zu installieren. Viele Details hierzu finden sich [http://wiki.openwrt.org/doc/howto/extroot hier]
<source lang=bash>
opkg update
opkg install block-mount
</source>
Bei einem Aufruf von
<source lang=bash>
fdisk -l
</source>
sollte der an dem Router angeschlossene Stick bereits zu sehen sein (analog zu oben). Hiermit lässt sich dann auch rausfinden, wie das Gerät auf dem Router heisst. In den meisten Fällen dürfte dies <code>/dev/sda</code> sein. In diesem Fall können wir nun das Dateisystem einbinden und dann die Dateien aus dem internen Speicher dorthin kopieren.
<source lang=bash>
mkdir /mnt/sda2
mount /dev/sda2 /mnt/sda2
tar -C /overlay -cvf - . | tar -C /mnt/sda2 -xf -
</source>
Nun kann auch schon die Konfiguration so umgestellt werden, dass beim nächsten Neustart der USB-Stick mit ins Root-Filesystem eingebunden wird. Dazu ist die Konfigurationsdatei <code>/etc/config/fstab</code> zu editieren.
<source lang=bash>
vi /etc/config/fstab
</source>
Diese sollte danach ungefähr so aussehen, wobei das von Router zu Router abweichen kann. Der automatische Block für "home" kann bearbeitet werden und der Spap-Block ebenfalls auf (hier) /dev/sda1 angepasst werden

config global automount
option from_fstab 1
option anon_mount 1
config global autoswap
option from_fstab 1
option anon_swap 1
config mount
option target /overlay
option device /dev/sda2
option fstype ext4
option options rw,sync
option enabled 1
option enabled_fsck 1
config swap
option device /dev/sda1
option enabled 1

Nun kann die Konfiguration aktiviert und die Box mit eingestecktem Stick neu gestartet werden
<source lang=bash>
/etc/init.d/fstab enable
reboot
</source>
Nun sollte überprüft werden, ob der Stick richtig eingebunden ist
<source lang=bash>
df -h
</source>
Die Ausgabe sollte sinngemäß folgende Zeilen enthalten

/dev/sda2 397.7M 19.8M 357.9M 5% /overlay
overlayfs:/overlay 397.7M 19.8M 357.9M 5%

Ist dies nicht der Fall, kann auf der OpenWRT Seite nach Troubleshooting-Möglichkeiten gesucht werden und dann hier fortgesetzt werden.
Nachdem nun der Stick erfolgreiche eingebunden werden, können die ganzen Pakete installiert werden, die zum Betrieb von FHEM notwendig sind. Da dies eine Vielzahl der perlbase-Pakete ist, sind hier schlichtweg alle verfügbaren perl-Pakete installiert worden. Ebenfalls einige andere nützliche Werkzeuge. Speichermäßig ist das auf dem USB-Stick nicht entscheidend.
<source lang=bash>
opkg update
opkg install usbutils luci ntpclient uhttpd perl perl-compress-bzip2 perl-dbi perl-html-parser perl-html-tagset perl-html-tree perl-lockfile-simple \
perl-net-telnet perl-uri perl-www perl-www-curl perl-www-mechanize perlbase-abbrev perlbase-anydbm-file perlbase-archive perlbase-assert perlbase-attribute \
perlbase-attributes perlbase-attrs perlbase-autoloader perlbase-autosplit perlbase-autouse perlbase-b perlbase-base perlbase-benchmark perlbase-bigfloat \
perlbase-bigint perlbase-bignum perlbase-bigrat perlbase-blib perlbase-bytes perlbase-cacheout perlbase-cgi perlbase-charnames perlbase-class \
perlbase-complete perlbase-compress perlbase-config perlbase-cpan perlbase-cpanplus perlbase-ctime perlbase-cwd perlbase-data perlbase-db \
perlbase-db-file perlbase-dbm-filter perlbase-devel perlbase-diagnostics perlbase-digest perlbase-dirhandle perlbase-dotsh perlbase-dumpvalue \
perlbase-dumpvar perlbase-dynaloader perlbase-encode perlbase-encoding perlbase-english perlbase-env perlbase-errno perlbase-essential perlbase-exceptions \
perlbase-extutils perlbase-fastcwd perlbase-fatal perlbase-fcntl perlbase-feature perlbase-fields perlbase-file perlbase-filecache perlbase-filehandle \
perlbase-filetest perlbase-filter perlbase-find perlbase-findbin perlbase-finddepth perlbase-flush perlbase-gdbm-file perlbase-getcwd perlbase-getopt \
perlbase-getoptpl perlbase-hash perlbase-hostname perlbase-i18n perlbase-if perlbase-importenv perlbase-integer perlbase-io perlbase-ipc perlbase-less \
perlbase-list perlbase-locale perlbase-log perlbase-look perlbase-math perlbase-memoize perlbase-mime perlbase-module perlbase-mro perlbase-net \
perlbase-next perlbase-o perlbase-object perlbase-opcode perlbase-open perlbase-ops perlbase-package perlbase-params perlbase-perl5db perlbase-perlio \
perlbase-pod perlbase-posix perlbase-pwd perlbase-re perlbase-safe perlbase-scalar perlbase-sdbm-file perlbase-search perlbase-selectsaver \
perlbase-selfloader perlbase-shell perlbase-shellwords perlbase-sigtrap perlbase-socket perlbase-sort perlbase-stat perlbase-storable perlbase-switch \
perlbase-symbol perlbase-sys perlbase-syslog perlbase-tainted perlbase-term perlbase-termcap perlbase-test perlbase-text perlbase-thread perlbase-threads \
perlbase-tie perlbase-time perlbase-unicode perlbase-unicore perlbase-user perlbase-xsloader
</source>
Das Webinterface "Luci" ist mitinstalliert worden und bietet komfortable Einstellmöglichkeiten für den Router allgemein. Nach einem
<source lang=bash>
/etc/init.d/uhttpd enable
/etc/init.d/uhttpd start
</source>
ist es unter <code>[http://192.168.1.1/ http://192.168.1.1/]</code> bzw. der entsprechenden Router-IP erreichbar. Wichtig ist es ggf. den DHCP-Server zu deaktivieren. Die meisten Router können auch als WLAN-Clients konfiguriert werden, sie brauchen also nicht zwangsweise ein Netzwerkkabel. All dies geht über die Weboberfläche.
Nun kann FHEM auf den Router/Stick kopiert werden. In diesem Beispiel benutzen wir das SVN-Repository
<source lang=bash>
opkg install subversion-client make libelf
mkdir /usr/src
cd /usr/src
svn co https://fhem.svn.sourceforge.net/svnroot/fhem/trunk/fhem
cd fhem
make install-pgm2
</source>
Die Bearbeitung der <code>/etc/fhem.cfg</code> ist nun so durchzuführen, wie bei jeder anderen FHEM-Installation auch.

==== CUL ====
Wenn ein [[CUL]] am Router verwendet werden soll, dann geht dies über den Umweg <code>ser2net</code>, da das CPAN Modul <code>Device::Serial</code> in OpenWRT nicht standardmäßig zur Verfügung steht.
<source lang=bash>
opkg install ser2net
vi /etc/ser2net.conf
</source>
In der Datei kann alles gelöscht werden und dann genau diese Zeile eingefügt werden:

27073:raw:300:/dev/ttyACM0:115200 NONE 1STOPBIT 7DATABITS

In der fhem.cfg ist die Definition des CUL-Sticks dann folgendermaßen:

define MyCUL CUL 127.0.0.1:27073 3333

Wenn man CUL doch per Device::Serial ansprechen oder andere FHEM Module verwenden will, die auf Device::Serial angewiesen sind, kann man das entsprechende OpenWRT Paket auch selber erstellen.
Hinweise dazu gibt es [http://tcb.udarknet.com/dokuwiki/doku.php/projects/securouter/openwrt hier].

Nun muss nur noch der Autostart von ser2net und fhem eingebaut werden und die integrierte, stromsparende FHEM-Kiste ist fertig.
<source lang=bash>
vi /etc/init.d/ser2net
</source>
mit folgendem Inhalt
<source lang=bash>
#!/bin/sh /etc/rc.common
# Ser2Net Init Script
START=10
STOP=15
start() {
ser2net
}
stop(){
killall ser2net
}
</source>
Danach Ser2Net aktivieren und starten:
<source lang=bash>
chmod +x /etc/init.d/ser2net
/etc/init.d/ser2net enable
/etc/init.d/ser2net start
</source>

==== FHEM beim Systemstart ====
Nun noch die Konfiguration für fhem selbst
<source lang=bash>
#!/bin/sh /etc/rc.common
# FHEM Init Script
START=11
STOP=15
start() {
/usr/bin/fhem.pl /etc/fhem.cfg
}
stop(){
echo "shutdown" | nc localhost 7072
}
</source>
Und auch hier aktivieren:
<source lang=bash>
chmod +x /etc/init.d/fhem
/etc/init.d/fhem enable
/etc/init.d/fhem start
</source>

==== Logfiles nicht auf USB-Stick ====
Da das ständige Schreiben 1. langsam und 2. den meisten USB-Sticks nicht gut tut, sollten die Logfiles ins RAM geschrieben werden, also ein Pfad unterhalb von <code>/tmp</code>. Der Speicher ist allerdings begrenzt. Je nach persönlichen Anforderungen muss dann regelmäßig das Log aus dem Speicher gelöscht oder archiviert werden. Z.b. wöchentlich auf den USB Stick oder auf Netzlaufwerke etc. Dies ist mit dem FileLog von alleine möglich (siehe [http://fhem.de/commandref.html#archivecmd]).

----

== Alternative Installation aus den Kompilierten Quellen bei einem Speicher größer 6MB ==
Zunächst wird OpenWRT auf den Router installiert. Auf die Installation des WEB-Interfaces „luci“ kann verzichtet werden.

=== Netzwerk einrichten ===

Der erste Login erfolgt mit <code>telnet</code> (nicht SSH) auf die IP 192.168.1.1 ohne Passwort.
Als erstes sollte mit dem Befehl <code>passwd</code> ein Passwort eingestellt werden.
Sobald das geschehen ist, wird der Telnet-Dienst abgestellt.
Ab jetzt sollte über den SSH-Dienst mit dem eben eingestellten Passwort gearbeitet werden.
Mittels <code>vi</code> kann die LAN-IP-Adresse in der Datei <code>/etc/config/network</code> angepasst werden.
<source lang=text>
config interface 'lan'
...
option ipaddr '192.168.178.4'
option netmask '255.255.255.0'
option gateway '192.168.178.1'
option dns '192.168.178.1'
...
</source>

Die Konfiguration wird mit dem Aufruf von <code>/etc/init.d/network restart</code> übernommen.

Zeitzone in der Datei <code>/etc/config/system</code> einstellen:
<source lang=text>
config system
...
option timezone 'CET-1CEST,M3.5.0,M10.5.0/3'
...
</source>

=== PERL installieren ===

Perl kann wie folgt eingerichtet werden. Je nach verwendetet FHEM-Module müssen weitere PERL-Pakete installiert werden. Für MAX_LAN, HM-CFG-LAN und ECMD reicht die folgende Auswahl:
<source lang=bash>
opkg update
opkg install perl perl-html-parser perl-html-tagset perl-uri perl-www perlbase-autoloader perlbase-config \
perlbase-ctime perlbase-digest perlbase-dynaloader perlbase-errno perlbase-essential perlbase-fcntl \
perlbase-file perlbase-integer perlbase-io perlbase-math perlbase-mime perlbase-posix perlbase-selectsaver \
perlbase-socket perlbase-symbol perlbase-tie perlbase-time perlbase-timelocal perlbase-xsloader
</source>

=== Einbinden der Partitionen per UUID ===

Für die Verwendung eines USB-Sticks müssen weitere Pakete installiert werden:
<source lang=bash>
opkg update
opkg install kmod-usb-storage block-mount kmod-fs-ext4
</source>

Der USB-Stick benötigt eine Datenpartition, optional kann eine zusätzliche SWAP-Partition eingerichtet werden.
Hierfür kann der Abschnitt "[[#Vorbereiten des USB-Sticks|Vorbereiten des USB-Sticks]]" aus dem vorherigen Kapitel verwendet werden.

Erstellen eines Verzeichnisses für den FHEM-Daten-Stick:
<source lang=bash>
mkdir /mnt/opt
</source>

Mittels des Befehls <code>block</code> kann eine brauchbare fstab-Konfiguration erstellt werden.
An dieser Stelle wird mit den eindeutigen UUIDs gearbeitet.
So ist es beim Betrieb von mehreren Datenspeichern unerheblich, in welcher Reihenfolge diese eingebunden werden.
Dies kann etwas Ärger ersparen.
<source lang=bash>
block detect > /etc/config/fstab
</source>

Die Konfigurationsdatei <code>/etc/config/fstab</code> muss angepasst werden.
Zunächst sind die Mount-Punkte nicht aktiviert und das Verzeichnis für die Datenpartition muss noch angepasst werden.
Die Option <code>uuid</code> muss unverändert bleiben.
<source lang=bash>
vi /etc/config/fstab
</source>
Darin
<source lang=text>
config 'global'
...
config 'mount'
option target '/mnt/opt'
option uuid '...'
option enabled '1'
config 'swap'
option uuid '...'
option enabled '1'
</source>

Über einen Neustart oder <code>/sbin/block mount</code> werden die Partitionen eingebunden.

=== Installation von FHEM ===
Die Installation von FHEM ist an vielen Stellen sehr gut beschrieben.
Hier nur die Quick&Dirty Variante.
Die [http://fhem.de/fhem.html#Download aktuellste, stabile Version] herunter laden.
Die Version ''X.Y'' in den folgenden Befehlen bitte entsprechend anpassen:
<source lang=bash>
cd /mnt/opt/
wget http://fhem.de/fhem-X.Y.tar.gz
opkg update
opkg install tar
tar xfz fhem-X.Y.tar.gz
mv fhem-X.Y fhem
</source>

=== Startskript anlegen ===

<source lang=bash>
touch /etc/init.d/fhem
chmod +x /etc/init.d/fhem
vi /etc/init.d/fhem
</source>
Darin
<source lang=bash>
#!/bin/sh /etc/rc.common
# FHEM Init Script

START=11
STOP=15

cd /mnt/opt/fhem/

start() {
if [ -f /mnt/opt/fhem-X.Y/log ]; then
mkdir -p /mnt/opt/fhem-X.Y/log
fi
/mnt/opt/fhem/fhem.pl /mnt/opt/fhem/fhem.cfg
}
stop(){
echo "stopping fhem"
/mnt/opt/fhem/fhem.pl 7072 "shutdown"
#kill -TERM $(cat /var/run/fhem.pid)
}
restart(){
echo "restarting"
mnt/opt/fhem/fhem.pl 7072 "shutdown"
#kill -TERM $(cat /var/run/fhem.pid)
/mnt/opt/fhem/fhem.pl /mnt/opt/fhem/fhem.cfg
}
</source>

Init.d-Script aktivieren:
<source lang=bash>
/etc/init.d/fhem start
/etc/init.d/fhem enable
</source>

Ab jetzt sollte FHEM bei jedem Bootvorgang automatisch gestartet werden.

=== Anmerkungen ===
* Es sollte sichergestellt werden, dass keine Dateien außerhalb von <code>/mnt/opt/</code> geschrieben werden.
* Die PERL-Version ist leider etwas älter (Version 5.10) an einigen Stellen muss der FHEM-Code angepasst werden. Besonders wenn mit dem „~~“ Operator gearbeitet wurde.

[[Kategorie:HOWTOS]]
[[Kategorie:Glossary]]
[[Kategorie:CUL]]

OpenWRT

2016-12-06T18:15:28Z

Mahowi: Die Quellen zu OpenWRT liegen jetzt auf GitHub

== Einleitung ==

Hier sind zwei alternative Installationswege beschrieben.

* Im ersten Kapitel wird beschrieben, wie Openwrt auf einem Gerät mit wenig(er) internem Speicher eingerichtet werden kann. Hier wird OpenWRT zuerst aus den Sourcen erstellt und ein Overlay für die PERL-Pakete eingerichtet.
* Das zweite Kapitel beschreibt, wie OpenWRT mit PERL im internen Speicher (6MB) installiert wird. Es werden keine Pakete selbst gebaut, sondern die Nightly-Snapshots verwendet. FHEM wird auf einem USB-Stick eingerichtet.

== Installation von FHEM incl. OpenWRT auf einem Router/Kleinstcomputer z.B. TP-LINK MR3020 ==
Wer nicht unbedingt eine Fritz!Box braucht sondern einfach nur FHEM ohne laufenden PC betreiben will, kann auch OpenWRT auf einem Router nutzen, z.B. dem sehr günstigen (25 Euro März 2012) und stromsparenden (ca. 1 Watt) TP-LINK MR3020.

Bitte beachten: Es kann keine Garantie übernommen werden, dass der Router bei Befolgung dieser Anleitung "kaputt" geht, z.B. dadurch, dass er bei Fehlkonfiguration im Netz nicht mehr erreichbar ist. Der Umbau erfolgt auf eigene Gefahr.

=== Vorraussetzungen ===
* Der Router (in diesem Howto ist der TP-LINK MR3020 verwendet worden, OpenWRT wird aber prinzipiell immer gleich aufgesetzt
* Ein USB Stick, da die Flash-Speicher der Router zu klein sind
* optional ein passiver USB-Hub (wenn der Router nur einen USB Port hat und ein CUL Stick betrieben werden soll)
* Ein Linux-PC zum Erstellen des Images. Dies kann auch eine virtuelle Maschine sein. Der Autor hat Ubuntu 10.11 verwendet.
=== Vorbereiten des USB-Sticks ===
Auf einem USB Stick müssen zwei Partitionen angelegt werden, eine als Auslagerungsspeicher für den RAM und eine für das Dateisystem auf dem später auch Perl und FHEM installiert werden. Das geht am besten mit dem Tool <code>fdisk</code> auf dem vorbereiteten Linux-PC. Dazu den Stick anstöpseln und per Aufruf von <code>fdisk -l</code> die Lister der gefundenen "Festplatten" anzeigen lassen. Eine davon ist der USB-Stick, z.B. an seiner Größe zu erkennen (500Mb reichen locker aus). In der Ausgabe z.B. nach einer Zeile suchen, die sinngemäß so aussieht: <code>Disk /dev/sdc: 484 MB, 484442112 bytes</code>. In diesem Fall ist der USB-Stick das Gerät "/dev/sdc".

Daraufhin kann fdisk für das Gerät aufgerufen werden. Detaillierte ANleitungen für fdisk finden sich im Internet. Vereinfacht ist folgender Vorgang auszuführen (alle Daten gehen auf dem Stick verloren!).

<source lang=bash>
fdisk /dev/sdc
o
n
p
1
1
+64M
n
p
2 (drei mal Enter drücken)
t
1
82
w
</source>

Danach ist der Stick partitioniert. Ein erneuter Aufruf von <code>fdisk -l</code> sollte ungefähr folgendes ERgebnis liefern:

Disk /dev/sdc: 484 MB, 484442112 bytes
2 heads, 63 sectors/track, 7509 cylinders
Units = cylinders of 126 * 512 = 64512 bytes
Disk identifier: 0x8c5e341e
Device Boot Start End Blocks Id System
/dev/sdc1 1 993 62527+ 82 Linux swap / Solaris
/dev/sdc2 994 7509 410508 83 Linux

Jetzt müssen die Partitionen noch formatiert werden. Vorsicht: Nur hier heisst der Stick /dev/sdc. Er kann auch anders heissen! Wenn ihr die falschen Namen verwendet, könntet ihr eure Festplatte löschen! /dev/sdc1 ist durch /dev/<euer-sdx>1 zu ersetzen

<source lang=bash>
mkswap /dev/sdc1
mkfs.ext4 /dev/sdc2
sync
</source>

Der Stick ist nun fertig vorbereitet und wird im Linux-PC nicht mehr benötigt. Er kann jetzt in den Router

=== Bauen des OpenWRT-Images ===
Um OpenWRT zu bauen, müssen die entsprechenden Werkzeuge auf dem Linux-PC installiert sein. Unter Ubuntu geht das so:
<source lang=bash>
sudo apt-get -y install subversion git-core
</source>

OpenWRT kann am besten von GitHub ausgecheckt werden.
<source lang=bash>
git clone git://github.com/openwrt/openwrt.git
</source>

Das Auschecken dauert eine Weile, aber das ist noch gar nichts, das Bauen dauert noch viel länger. Sobald alles runtergeladen ist, wird in das Verzeichnis gewechselt und die Konfiguration vorgenommen
<source lang=bash>
cd openwrt
make menuconfig
</source>

Für die Konfiguration muss die Architektur des Routers bekannt sein. Diese kann auf der [http://www.openwrt.org OpenWRT-Seite] nachgeschlagen werden. der TP-LINK MR3020 hat eine <code>ar71xx</code>-Architektur.

Als erstes also die Architektur auswählen (Hier: <code>ar71xxx/ar91xxx</code>)
Zweitens kann beim Target-Profile meinst genau der Router ausgewählt werden (Notfalls auf der OpenWRT-Seite nachlesen)

Optional kann nun unter <code>Image-Configuration</code> bereits eine Netzwerkkonfiguration eingestellt werden, die der Router dann nach seinem Hochfahren hat. Wenn der Router in ein bestehendes Netz mit bestehenden DHCP-Server und Adressraum eingebunden wird, ist das sinnvoll. Wer das hat, weiss auch, was hier einzustellen ist. Standardmäßig ist die Adresse 192.168.1.1 vorgegeben. Die Konfiguration kann auch später jederzeit geändert werden.

Nun zu den Kernel-Modules. Hier sollte folgendes aktiviert werden (Einiges ist ggf. nicht nötig, aber so geht es). Die Einträge müssen mit "*" und nicht mit "M" selektiert sein, sonst kommen sie nicht ins Image.

* Block-Devices
** kmod-ide-core
** kmod-ide-generic
** kmod-loop (kann man immer mal brauchen)
** kmod-scsi-generic
* Filesystems
** kmod-fs-ext4 ''(davon wollen wir später vom USB-Stick booten)''
* USB-Support
** kmod-usb-acm ''(für CUL)''
** kmod-usb-hid
** kmod-usb-ohci
** kmod-usb-serial
** kmod-usb-serial-ftdi
** kmod-usb-storage-extras
** kmod-usb-uhci
** kmod-usb2

Unter Utilities noch folgendes aktivieren
* Filesystem
** e2fsprogs
* disc
** fdisk ''(für Analysezwecke sinnvoll)''
** swap-utils

Nun kann - in aller Ruhe - alles gebaut werden durch Eingabe von
<source lang=bash>
make
</source>

=== Vorbereiten des Routers ===
Das ganze kann bis zu mehrere Stunden laufen. Nun ist Zeit, den Router ins Netzwerk einzubinden. Wie genau, hängt von der persönlichen Konstellation ab. Der TP-Link MR3020 hat standardmäßig die IP-Adresse 192.168.0.254. Viele andere Router haben z.B. 192.168.0.1. Ich empfehle, das Update auf jeden Fall nicht über WLAN sondern ein Netzwerkkabel zu machen. Die meisten Router haben einen aktivierten DHCP-Server. Ein angestöpselter Windows-PC bekommt dann von ihm eine IP-Adresse zugewiesen. Beim MR3020 kann dann die Weboberfläche über [http://192.168.0.254 http://192.168.0.254] erreicht werden. (User/Passwort: admin/admin)

=== Installation von OpenWRT auf dem Router ===
In der Weboberfläche des Routers gibt es irgendwo einen Menüpunkt zum Firmware-Upgrade. Beim MR3020 erreichbar unter System Tools / Firmware Upgrade. Sobald das Bauen von OpenWRT fertig ist, liegt das Image im Unterordner <code>bin/<architektur>/</code>. Es sollte das Image genommen werden, was den Namen des Routers sowie "squashfs" sowie "factory" im Dateinamen enthält. Dieses muss jetzt im Webinterface wie beschrieben ausgewählt werden und hochgeladen werden. Alle Bestätigungsmeldungen und "Wollen-Sie-Das-auch-Wirklich"-Fragen natürlich bestätigen.

Nach einer Weile sollte dann der Router unter 192.168.1.1 anpingbar sein (von Linux aus: <code>ping 192.168.1.1</code>) bzw. unter der in der Image Configuration eingestellten IP. Wenn das nicht geht, kann man den Router auch ein 2. mal starten, da sollte man dann aber nach dem Flashen mal 10 Minuten Geduld haben (also Stecker raus/rein). Auf keinen Fall zu früh machen, dann könnte es sein, dass er gar nicht mehr hochfährt!

Zunächst muss man sich nun per telnet verbinden.
<source lang=bash>
telnet 192.168.1.1
</source>
Nun ist man schon im OpenWRT eingeloggt. Das erste und einzige, was in diesem Login nun gemacht wird, ist, per
<source lang=bash>
passwd
</source>
ein Passwort zu setzen. Danach kann man sich mit
<source lang=bash>
exit
</source>
ausloggen. Ab jetzt ist <code>telnet</code> zur Sicherheit deaktiviert und man kann per <code>ssh</code> eine Verbindung herstellen, da ja jetzt ein Passwort gesetzt ist
<source lang=bash>
ssh root@192.168.1.1
</source>
Für den weiteren Verlauf ist es notwendig, dass der Router Internetzugang hat. Dazu muss man ggf. von Hand in der Datei <code>/etc/config/network</code> die Netzwerkeinstellungen entsprechend anpassen.
<source lang=bash>
vi /etc/config/network
</source>
Zur Bedienung von vi z.B. [http://wiki.openwrt.org/doc/uci/network hier]

Wichtig ist die IP-Adresse, die Netzmaske, das Gateway und der DNS-Server. Bitte genau auf Tippfehler achten. Bei einer fehlenden Konfiguration ist der Router nicht mehr erreichbar. Nach abspeichern kann die neue Konfiguration aktiviert werden
<source lang=bash>
/etc/init.d/network restart
</source>
Falls sich auch die IP-Adresse geändert hat, mit ssh wie oben neu anmelden. Als nächstes soll der USB-Stick eingebunden werden, dazu sind einige Pakete zu installieren. OpenWRT hat einen eingebauten Paketmanager zur Nachinstallation von Software direkt aus dem Netz. Zunächst wird nur das installiert, was in den internen Speicher des Routers muss. Das Root-Dateisystem soll anschließend durch den USB-Stick erweitert werden, um dann dorthin die meiste Software zu installieren. Viele Details hierzu finden sich [http://wiki.openwrt.org/doc/howto/extroot hier]
<source lang=bash>
opkg update
opkg install block-mount
</source>
Bei einem Aufruf von
<source lang=bash>
fdisk -l
</source>
sollte der an dem Router angeschlossene Stick bereits zu sehen sein (analog zu oben). Hiermit lässt sich dann auch rausfinden, wie das Gerät auf dem Router heisst. In den meisten Fällen dürfte dies <code>/dev/sda</code> sein. In diesem Fall können wir nun das Dateisystem einbinden und dann die Dateien aus dem internen Speicher dorthin kopieren.
<source lang=bash>
mkdir /mnt/sda2
mount /dev/sda2 /mnt/sda2
tar -C /overlay -cvf - . | tar -C /mnt/sda2 -xf -
</source>
Nun kann auch schon die Konfiguration so umgestellt werden, dass beim nächsten Neustart der USB-Stick mit ins Root-Filesystem eingebunden wird. Dazu ist die Konfigurationsdatei <code>/etc/config/fstab</code> zu editieren.
<source lang=bash>
vi /etc/config/fstab
</source>
Diese sollte danach ungefähr so aussehen, wobei das von Router zu Router abweichen kann. Der automatische Block für "home" kann bearbeitet werden und der Spap-Block ebenfalls auf (hier) /dev/sda1 angepasst werden

config global automount
option from_fstab 1
option anon_mount 1
config global autoswap
option from_fstab 1
option anon_swap 1
config mount
option target /overlay
option device /dev/sda2
option fstype ext4
option options rw,sync
option enabled 1
option enabled_fsck 1
config swap
option device /dev/sda1
option enabled 1

Nun kann die Konfiguration aktiviert und die Box mit eingestecktem Stick neu gestartet werden
<source lang=bash>
/etc/init.d/fstab enable
reboot
</source>
Nun sollte überprüft werden, ob der Stick richtig eingebunden ist
<source lang=bash>
df -h
</source>
Die Ausgabe sollte sinngemäß folgende Zeilen enthalten

/dev/sda2 397.7M 19.8M 357.9M 5% /overlay
overlayfs:/overlay 397.7M 19.8M 357.9M 5%

Ist dies nicht der Fall, kann auf der OpenWRT Seite nach Troubleshooting-Möglichkeiten gesucht werden und dann hier fortgesetzt werden.
Nachdem nun der Stick erfolgreiche eingebunden werden, können die ganzen Pakete installiert werden, die zum Betrieb von FHEM notwendig sind. Da dies eine Vielzahl der perlbase-Pakete ist, sind hier schlichtweg alle verfügbaren perl-Pakete installiert worden. Ebenfalls einige andere nützliche Werkzeuge. Speichermäßig ist das auf dem USB-Stick nicht entscheidend.
<source lang=bash>
opkg update
opkg install usbutils luci ntpclient uhttpd perl perl-compress-bzip2 perl-dbi perl-html-parser perl-html-tagset perl-html-tree perl-lockfile-simple \
perl-net-telnet perl-uri perl-www perl-www-curl perl-www-mechanize perlbase-abbrev perlbase-anydbm-file perlbase-archive perlbase-assert perlbase-attribute \
perlbase-attributes perlbase-attrs perlbase-autoloader perlbase-autosplit perlbase-autouse perlbase-b perlbase-base perlbase-benchmark perlbase-bigfloat \
perlbase-bigint perlbase-bignum perlbase-bigrat perlbase-blib perlbase-bytes perlbase-cacheout perlbase-cgi perlbase-charnames perlbase-class \
perlbase-complete perlbase-compress perlbase-config perlbase-cpan perlbase-cpanplus perlbase-ctime perlbase-cwd perlbase-data perlbase-db \
perlbase-db-file perlbase-dbm-filter perlbase-devel perlbase-diagnostics perlbase-digest perlbase-dirhandle perlbase-dotsh perlbase-dumpvalue \
perlbase-dumpvar perlbase-dynaloader perlbase-encode perlbase-encoding perlbase-english perlbase-env perlbase-errno perlbase-essential perlbase-exceptions \
perlbase-extutils perlbase-fastcwd perlbase-fatal perlbase-fcntl perlbase-feature perlbase-fields perlbase-file perlbase-filecache perlbase-filehandle \
perlbase-filetest perlbase-filter perlbase-find perlbase-findbin perlbase-finddepth perlbase-flush perlbase-gdbm-file perlbase-getcwd perlbase-getopt \
perlbase-getoptpl perlbase-hash perlbase-hostname perlbase-i18n perlbase-if perlbase-importenv perlbase-integer perlbase-io perlbase-ipc perlbase-less \
perlbase-list perlbase-locale perlbase-log perlbase-look perlbase-math perlbase-memoize perlbase-mime perlbase-module perlbase-mro perlbase-net \
perlbase-next perlbase-o perlbase-object perlbase-opcode perlbase-open perlbase-ops perlbase-package perlbase-params perlbase-perl5db perlbase-perlio \
perlbase-pod perlbase-posix perlbase-pwd perlbase-re perlbase-safe perlbase-scalar perlbase-sdbm-file perlbase-search perlbase-selectsaver \
perlbase-selfloader perlbase-shell perlbase-shellwords perlbase-sigtrap perlbase-socket perlbase-sort perlbase-stat perlbase-storable perlbase-switch \
perlbase-symbol perlbase-sys perlbase-syslog perlbase-tainted perlbase-term perlbase-termcap perlbase-test perlbase-text perlbase-thread perlbase-threads \
perlbase-tie perlbase-time perlbase-unicode perlbase-unicore perlbase-user perlbase-xsloader
</source>
Das Webinterface "Luci" ist mitinstalliert worden und bietet komfortable Einstellmöglichkeiten für den Router allgemein. Nach einem
<source lang=bash>
/etc/init.d/uhttpd enable
/etc/init.d/uhttpd start
</source>
ist es unter <code>[http://192.168.1.1/ http://192.168.1.1/]</code> bzw. der entsprechenden Router-IP erreichbar. Wichtig ist es ggf. den DHCP-Server zu deaktivieren. Die meisten Router können auch als WLAN-Clients konfiguriert werden, sie brauchen also nicht zwangsweise ein Netzwerkkabel. All dies geht über die Weboberfläche.
Nun kann FHEM auf den Router/Stick kopiert werden. In diesem Beispiel benutzen wir das SVN-Repository
<source lang=bash>
opkg install subversion-client make libelf
mkdir /usr/src
cd /usr/src
svn co https://fhem.svn.sourceforge.net/svnroot/fhem/trunk/fhem
cd fhem
make install-pgm2
</source>
Die Bearbeitung der <code>/etc/fhem.cfg</code> ist nun so durchzuführen, wie bei jeder anderen FHEM-Installation auch.

==== CUL ====
Wenn ein [[CUL]] am Router verwendet werden soll, dann geht dies über den Umweg <code>ser2net</code>, da das CPAN Modul <code>Device::Serial</code> in OpenWRT nicht standardmäßig zur Verfügung steht.
<source lang=bash>
opkg install ser2net
vi /etc/ser2net.conf
</source>
In der Datei kann alles gelöscht werden und dann genau diese Zeile eingefügt werden:

27073:raw:300:/dev/ttyACM0:115200 NONE 1STOPBIT 7DATABITS

In der fhem.cfg ist die Definition des CUL-Sticks dann folgendermaßen:

define MyCUL CUL 127.0.0.1:27073 3333

Wenn man CUL doch per Device::Serial ansprechen oder andere FHEM Module verwenden will, die auf Device::Serial angewiesen sind, kann man das entsprechende OpenWRT Paket auch selber erstellen.
Hinweise dazu gibt es [http://tcb.udarknet.com/dokuwiki/doku.php/projects/securouter/openwrt hier].

Nun muss nur noch der Autostart von ser2net und fhem eingebaut werden und die integrierte, stromsparende FHEM-Kiste ist fertig.
<source lang=bash>
vi /etc/init.d/ser2net
</source>
mit folgendem Inhalt
<source lang=bash>
#!/bin/sh /etc/rc.common
# Ser2Net Init Script
START=10
STOP=15
start() {
ser2net
}
stop(){
killall ser2net
}
</source>
Danach Ser2Net aktivieren und starten:
<source lang=bash>
chmod +x /etc/init.d/ser2net
/etc/init.d/ser2net enable
/etc/init.d/ser2net start
</source>

==== FHEM beim Systemstart ====
Nun noch die Konfiguration für fhem selbst
<source lang=bash>
#!/bin/sh /etc/rc.common
# FHEM Init Script
START=11
STOP=15
start() {
/usr/bin/fhem.pl /etc/fhem.cfg
}
stop(){
echo "shutdown" | nc localhost 7072
}
</source>
Und auch hier aktivieren:
<source lang=bash>
chmod +x /etc/init.d/fhem
/etc/init.d/fhem enable
/etc/init.d/fhem start
</source>

==== Logfiles nicht auf USB-Stick ====
Da das ständige Schreiben 1. langsam und 2. den meisten USB-Sticks nicht gut tut, sollten die Logfiles ins RAM geschrieben werden, also ein Pfad unterhalb von <code>/tmp</code>. Der Speicher ist allerdings begrenzt. Je nach persönlichen Anforderungen muss dann regelmäßig das Log aus dem Speicher gelöscht oder archiviert werden. Z.b. wöchentlich auf den USB Stick oder auf Netzlaufwerke etc. Dies ist mit dem FileLog von alleine möglich (siehe [http://fhem.de/commandref.html#archivecmd]).

----

== Alternative Installation aus den Kompilierten Quellen bei einem Speicher größer 6MB ==
Zunächst wird OpenWRT auf den Router installiert. Auf die Installation des WEB-Interfaces „luci“ kann verzichtet werden.

=== Netzwerk einrichten ===

Der erste Login erfolgt mit <code>telnet</code> (nicht SSH) auf die IP 192.168.1.1 ohne Passwort.
Als erstes sollte mit dem Befehl <code>passwd</code> ein Passwort eingestellt werden.
Sobald das geschehen ist, wird der Telnet-Dienst abgestellt.
Ab jetzt sollte über den SSH-Dienst mit dem eben eingestellten Passwort gearbeitet werden.
Mittels <code>vi</code> kann die LAN-IP-Adresse in der Datei <code>/etc/config/network</code> angepasst werden.
<source lang=text>
config interface 'lan'
...
option ipaddr '192.168.178.4'
option netmask '255.255.255.0'
option gateway '192.168.178.1'
option dns '192.168.178.1'
...
</source>

Die Konfiguration wird mit dem Aufruf von <code>/etc/init.d/network restart</code> übernommen.

Zeitzone in der Datei <code>/etc/config/system</code> einstellen:
<source lang=text>
config system
...
option timezone 'CET-1CEST,M3.5.0,M10.5.0/3'
...
</source>

=== PERL installieren ===

Perl kann wie folgt eingerichtet werden. Je nach verwendetet FHEM-Module müssen weitere PERL-Pakete installiert werden. Für MAX_LAN, HM-CFG-LAN und ECMD reicht die folgende Auswahl:
<source lang=bash>
opkg update
opkg install perl perl-html-parser perl-html-tagset perl-uri perl-www perlbase-autoloader perlbase-config \
perlbase-ctime perlbase-digest perlbase-dynaloader perlbase-errno perlbase-essential perlbase-fcntl \
perlbase-file perlbase-integer perlbase-io perlbase-math perlbase-mime perlbase-posix perlbase-selectsaver \
perlbase-socket perlbase-symbol perlbase-tie perlbase-time perlbase-timelocal perlbase-xsloader
</source>

=== Einbinden der Partitionen per UUID ===

Für die Verwendung eines USB-Sticks müssen weitere Pakete installiert werden:
<source lang=bash>
opkg update
opkg install kmod-usb-storage block-mount kmod-fs-ext4
</source>

Der USB-Stick benötigt eine Datenpartition, optional kann eine zusätzliche SWAP-Partition eingerichtet werden.
Hierfür kann der Abschnitt "[[#Vorbereiten des USB-Sticks|Vorbereiten des USB-Sticks]]" aus dem vorherigen Kapitel verwendet werden.

Erstellen eines Verzeichnisses für den FHEM-Daten-Stick:
<source lang=bash>
mkdir /mnt/opt
</source>

Mittels des Befehls <code>block</code> kann eine brauchbare fstab-Konfiguration erstellt werden.
An dieser Stelle wird mit den eindeutigen UUIDs gearbeitet.
So ist es beim Betrieb von mehreren Datenspeichern unerheblich, in welcher Reihenfolge diese eingebunden werden.
Dies kann etwas Ärger ersparen.
<source lang=bash>
block detect > /etc/config/fstab
</source>

Die Konfigurationsdatei <code>/etc/config/fstab</code> muss angepasst werden.
Zunächst sind die Mount-Punkte nicht aktiviert und das Verzeichnis für die Datenpartition muss noch angepasst werden.
Die Option <code>uuid</code> muss unverändert bleiben.
<source lang=bash>
vi /etc/config/fstab
</source>
Darin
<source lang=text>
config 'global'
...
config 'mount'
option target '/mnt/opt'
option uuid '...'
option enabled '1'
config 'swap'
option uuid '...'
option enabled '1'
</source>

Über einen Neustart oder <code>/sbin/block mount</code> werden die Partitionen eingebunden.

=== Installation von FHEM ===
Die Installation von FHEM ist an vielen Stellen sehr gut beschrieben.
Hier nur die Quick&Dirty Variante.
Die [http://fhem.de/fhem.html#Download aktuellste, stabile Version] herunter laden.
Die Version ''X.Y'' in den folgenden Befehlen bitte entsprechend anpassen:
<source lang=bash>
cd /mnt/opt/
wget http://fhem.de/fhem-X.Y.tar.gz
opkg update
opkg install tar
tar xfz fhem-X.Y.tar.gz
mv fhem-X.Y fhem
</source>

=== Startskript anlegen ===

<source lang=bash>
touch /etc/init.d/fhem
chmod +x /etc/init.d/fhem
vi /etc/init.d/fhem
</source>
Darin
<source lang=bash>
#!/bin/sh /etc/rc.common
# FHEM Init Script

START=11
STOP=15

cd /mnt/opt/fhem/

start() {
if [ -f /mnt/opt/fhem-X.Y/log ]; then
mkdir -p /mnt/opt/fhem-X.Y/log
fi
/mnt/opt/fhem/fhem.pl /mnt/opt/fhem/fhem.cfg
}
stop(){
echo "stopping fhem"
/mnt/opt/fhem/fhem.pl 7072 "shutdown"
#kill -TERM $(cat /var/run/fhem.pid)
}
restart(){
echo "restarting"
mnt/opt/fhem/fhem.pl 7072 "shutdown"
#kill -TERM $(cat /var/run/fhem.pid)
/mnt/opt/fhem/fhem.pl /mnt/opt/fhem/fhem.cfg
}
</source>

Init.d-Script aktivieren:
<source lang=bash>
/etc/init.d/fhem start
/etc/init.d/fhem enable
</source>

Ab jetzt sollte FHEM bei jedem Bootvorgang automatisch gestartet werden.

=== Anmerkungen ===
* Es sollte sichergestellt werden, dass keine Dateien außerhalb von <code>/mnt/opt/</code> geschrieben werden.
* Die PERL-Version ist leider etwas älter (Version 5.10) an einigen Stellen muss der FHEM-Code angepasst werden. Besonders wenn mit dem „~~“ Operator gearbeitet wurde.

[[Kategorie:HOWTOS]]
[[Kategorie:Glossary]]
[[Kategorie:CUL]]

Homebridge einrichten

2016-03-07T19:53:24Z

Mahowi: fehlendes Paket libavahi-compat-libdnssd-dev ergänzt

Dieses HOWTO zeigt die Installation und Erstinbetriebnahme von Homebridge.

Damit kann Siri benutzt werden, um FHEM-Devices zu steuern. So können Devices angesprochen werden, die offiziell HomeKit nicht unterstützen (die Vorgehensweise wurde auf einem Intel NUC mit Ubuntu Server 14.04 LTS und auf einem Raspberry Pi mit Raspian getestet). Der WIKI-Eintrag bezieht sich hauptsächlich auf eine {{Link2Forum|Topic=32652|LinkText=Diskussion im FHEM-Forum}}. Ein Riesendank gilt vor allem {{Link2FU|430|Andre (justme1968)}}.

Die Konfiguration der inzwischen aktuellen zweiten Version des Homekot-Plugins ist in einem neuen {{Link2Forum|Topic= 48558 |LinkText=Thread im FHEM-Forum}} beschrieben. Hinzugekommen ist vor allem die freie Konfigurierbarkeit der Zuordnung zwischen FHEM Device und Homekit Accessory/Service, zwischen FHEM Reading und Homekit Characteristic, das mapping vom FHEM Readingwerten zu Homekit Werten sowie das Mapping von Homekit Werten zu FHEM Set-Kommandos und Werten.

Eine Sammlung funktionsfähiger Homebridge FHEM Konfiguration kann hier gefunden werden: [[Homebridge User Configs]]. Die Sammlung befindet sich noch im Aufbau.

= Vorbereitung der Umgebung =

== NodeJS installieren ==
''Die nachfolgenden Befehle sind alle mit "sudo" prefixed. Wenn du unter "root" arbeitest oder deine Distribution einen anderen Mechanismus verwendet, so kannst du dies natürlich weglassen.''

Zunächst wird das Betriebssystem (in diesem Falle Debian oder Ubuntu) auf den aktuellen Stand gebracht:
<source lang="bash" style="width:50%;">
sudo apt-get update
sudo apt-get upgrade
sudo apt-get install build-essential libssl-dev</source>

Nun muss NodeJS installiert werden. Leider ist die Version im Debian Repository deutlich zu alt, daher wird mit den folgenden Befehlen das Node Repository hinzugefügt und NodeJS (in der LTS Version) entsprechend installiert:

'''NodeJS V4'''
<source lang="bash" style="width:50%;">
curl -sL https://deb.nodesource.com/setup_4.x | sudo -E bash -
sudo apt-get install -y nodejs
</source>

{{Randnotiz|RNTyp=y|RNText=Bei Installation von NodeJS auf einem "alten" RasPi (B) bitte die besonderen Hinweise in {{Link2Forum|Topic=32652|Message=419325|LinkText=diesem Forenbeitrag}} beachten.}}
'''NodeJS V5'''
<source lang="bash" style="width:50%">
curl -sL https://deb.nodesource.com/setup_5.x | sudo -E bash -
sudo apt-get install -y nodejs
</source>

Damit ist NodeJS installiert.

== Python, g++, MDNS installieren ==
<source lang="bash" style="width:50%;">
sudo apt-get install python g++ libavahi-compat-libdnssd-dev
</source>

Nun sind alle Voraussetzungen geschaffen.

= Installation von Homebridge & notwendiger Shims =
Im Nachfolgenden Absatz wird die Installation von Homebridge sowie des notwendigen Plugins (Shim) für FHEM erläutert.

== Homebridge installieren ==
Die aktuelle Homebridge version wird mit
<source lang="bash" style="width:50%;">
npm install -g homebridge
</source>
installiert, was eine Weile dauert. Anschließend wird der FHEM platform shim mit:
<source lang="bash" style="width:60%;">
npm install -g homebridge-fhem
</source>
installiert.

== Homebridge aktualisieren ==
Die aktuelle Homebridge version wird mit
<source lang="bash" style="width:50%;">
npm update -g homebridge
</source>
installiert, was eine Weile dauert. Anschließend wird der FHEM platform shim mit:
<source lang="bash" style="width:60%;">
npm update -g homebridge-fhem
</source>
installiert.

=== Fehler während der Installation ===
Bei folgendem Fehler ist das abrufen von Github nicht möglich.
<pre>npm ERR! git clone --template=/home/hs-server-admin/.npm/_git-remotes/_templates --mirror
git://github.com/KhaosT/ed25519.git /home/hs-server-admin/.npm/_git-remotes/git-github-com-KhaosT-ed25519-git-d8bdee1d:
github.com[0: 192.30.252.128]: errno=Die Wartezeit für die Verbindung ist abgelaufen</pre>
Fehlerursache konnte hier durch eine aktive Firewall verursacht werden.

Kommt eine DNS Fehlermeldung fehlt meistens der AVAHI-DAEMON, zu installieren via
<source lang="bash" style="width=50%">
sudo apt-get install avahi-daemon
</source>

Wenn npm beim Kompilieren von mdns mit der Meldung abbricht, daß "dns_sd.h" nicht gefunden wird, fehlt das Paket libavahi-compat-libdnssd-dev, zu installieren via
<source lang="bash" style="width=50%">
sudo apt-get install libavahi-compat-libdnssd-dev
</source>

= Homebridge konfigurieren =
''Wichtig: Für die weiteren Schritte sollte man nicht root verwenden, sondern beispielsweise einen dedizieren Nutzer für homebridge oder der Einfachheit halber den Nutzer unter dem auch FHEM läuft (meist "fhem").''

== Einstellungen für homebridge ==
Zunächst wird das Verzeichnis für die Konfigurationsdatei erstellt und in dieses gewechselt:
<source lang="bash" style="width:50%;">
mkdir -p ~/.homebridge
cd ~/.homebridge/
</source>

Nun muss darin noch die config.json erstellt bzw. angepasst werden:
<source lang="bash" style="width:50%;">
nano ~/.homebridge/config.json
</source>

Hinweise zur Konfiguration:
* "''bridge''":
** "''username''": Sollte so belassen werden. Sollte später auf dem iOS Device keine Homebridge gefunden werden, so kann man hier beispielsweise den String auf 31 statt 30 enden lassen um so eine neue Homebridge vorzutäuschen.
** "''port''": Sollte so belassen werden
** "''pin''": Der PIN kann beliebig in dem Format xxx-xx-xxx angepasst werden. Dieser muss nur einmal bei der Einrichtung in iOS eingegeben werden.
* "''platforms''":
** "''platform''": Hier muss "homebridge-fhem.fhem" beibehalten werden.
** "''server''": Hier muss die IP des FHEM-Servers eingetragen werden. Dabei muss Homebridge nicht auf dem selben Server laufen wie FHEM, kann aber. Wenn es auf dem gleichen Rechner läuft, dann bietet es sich an, die IP 127.0.0.1 zu verwenden.
** "''port''": Hier muss der Port des gewählten FHEMWEBS eingetragen werden (muss nicht das "normale" sein, kann eine extra Instanz sein)
** "''auth''": Ist FHEM nicht mit Nutzername/Password abgesichert, so kann man diese Zeile einfach entfernen.
** "''filter''": Damit nicht alle Devices von Homebridge berücksichtigt werden, bietet es sich an, die Devices zu filtern. In diesem Beispiel wurden alle Devices, die über Siri steuerbar sein sollen, zusätzlich in den Raum Homekit konfiguriert.
<source lang="javascript" style="width:50%;">
{
"bridge": {
"name": "Homebridge",
"username": "CC:22:3D:E3:CE:30",
"port": 51826,
"pin": "031-45-154"
},

"platforms": [
{
"platform": "homebridge-fhem.FHEM",
"name": "FHEM",
"server": "127.0.0.1",
"port": "8083",
"auth": {"user": "FhemUser", "pass": "XXX"},
"filter": "room=Homekit"
}
],

"accessories": []
}
</source>

Wird FHEM mit SSL abgesichert, so muss zusätzlich in der Sektion "platforms" noch diese Zeile (nach "port") eingefügt werden:
<source lang="javascript" style="width:50%;">
"ssl": true,
</source>

= FHEM konfigurieren =
Die benötigten Attribute werden inzwischen beim ersten Start des von hombridge-fhem automatisch auf FHEM seite eingetragen.

Mehr zu den inzwischen verfügbaren Konfigurationsmöglichkeiten findet sich auf den github und npmjs Seiten des Plugins und im ersten Beitrag des zugehörigen Thread im {{Link2Forum|Topic= 48558 |LinkText=Diskussion im FHEM-Forum}}

= Start von Homebridge =

== Hinweis ==
Nach allen Änderungen die in FHEM gemacht werden, welche Homebridge betreffen, muss Homebridge neu gestartet werden. Wie der Neustart erfolgen muss, ist abhängig davon, wie man Homebridge gestartet hat. Bitte den entsprechenden Methoden entnehmen.

== Einmaliger Manueller Start ==
<source lang="bash" style="width:50%;">
homebridge
</source>

Homebridge sollte nun laufen. Hier kann man die Kommunikation nachverfolgen. Abbrechen kann das ganze mit CTRL+c (es dann auch keine Befehle mehr mit Siri möglich). Damit Siri auch Befehle ohne ständig offenes Terminal bearbeiten kann, bitten nächsten Punkt beachten.

== Homebridge automatisch starten ==
Es gibt verschiedene Methoden, Homebridge automatisch zu starten.

=== Steuerung via FHEM ===
Auf Basis der unten stehenden ''Alternativen Methode'' wurde eine Version entwickelt, mit der man auch den Status einsehen und den Restart des Dienstes aus FHEM heraus erledigen kann. Diese Version ist auf der Seite [[Homebridge Start und Status in FHEM]] im Detail beschrieben.

=== Alternative Methode ===
Dies startet homebridge als einen Service.

==== Service anlegen ====
<code>
sudo nano /etc/init.d/homebridge
</code>

Code einfügen (startet den Homebridge Server als Benutzer "pi" und nimmt an, dass sich .homebridge/config.json in seinem Homeverzeichnis unter /home/pi/ befindet):

<source lang=bash>
#!/bin/sh
### BEGIN INIT INFO
# Provides: homebridge
# Required-Start: $network $remote_fs $syslog
# Required-Stop: $remote_fs $syslog
# Default-Start: 2 3 4 5
# Default-Stop: 0 1 6
# Short-Description: Start daemon at boot time for homebridge
# Description: Enable service provided by daemon.
### END INIT INFO
export PATH=$PATH:/usr/local/bin
export NODE_PATH=$NODE_PATH:/usr/local/lib/node_modules
PID=`pidof homebridge`
case "$1" in
start)
if ps -p $PID > /dev/null 2>&1; then
echo "Homebridge is already running"
else
su - pi -c "homebridge > /dev/null 2>&1 &"
echo "Homebridge starting"
$0 status
fi
;;
stop)
if ! ps -p $PID > /dev/null 2>&1; then
echo "Homebridge is not running"
else
kill $PID
echo "Homebridge closed"
fi
;;
restart)
if ! ps -p $PID > /dev/null 2>&1; then
$0 start
else
$0 stop
$0 start
fi
;;
status)
if ps -p $PID > /dev/null 2>&1; then
echo "Homebridge is running PID $PID"
else
echo "Homebridge is not running"
fi
;;
*)
echo "Usage: $0 {start|stop|status|restart}"
exit 1
;;
esac
exit 0
</source>

==== Autostart aktivieren ====

<code>
sudo chmod 755 /etc/init.d/homebridge

sudo update-rc.d homebridge defaults
</code>

Nun kann man mit

<code>
sudo service homebridge start
</code>

bzw.

<code>
sudo /etc/init.d/homebridge start
</code>

den Dienst starten

== FHEM Device Einstellungen ==
Damit die zu schaltenden Geräte überhaupt in der Homebridge aufgenommen werden muss man sie im Raum Homekit hinzufügen.

Um HM-CC-RT-DN Thermostate steuern zu können, muss wie oben beschrieben folgendes attribute gesetzt werden (hier als Beispiel das Device "Heizung"):
# attr Heizung subtype thermostat
Für einen Dummy muss man den genericDeviceType setzen, also beispielsweise:
# attr Dummy genericDeviceType switch
# attr Dummy setList on off

Wie bereits vorher angemerkt: Fügt man ein Device hinzu oder führt eine Änderung an einem Device durch, so sollte homebridge neu gestartet werden.

= HomeKit in iOS =

== Einrichtung ==
Um FHEM über Homebridge in iOS nutzen zu können, muss HomeKit eingerichtet werden.

Es gibt verschiedene Apps. Im folgenden wird die App EVE von Elgato empfohlen, die aus dem App-Store geladen werden muss.
In der App auf:
<pre style="width:50%;">
Gerät hinzufügen
</pre>
Es sollte ein Gerät mit der Bezeichnung "Homebridge" zur Auswahl erscheinen. Zur Ersteinrichtung auf PIN manuell eingeben gehen und (falls in der config.json nicht geändert):
<pre style="width:50%;">
031-45-154
</pre>
eingeben.

Im Anschluss können die Devices nach Belieben in verschiedene Räume zugeteilt werden, sowie Szenen und Bereiche erstellt werden.

== Schalten mit Siri ==
'''HolyMoly''' aus dem FHEM-Forum hat ein paar Beispiele gegeben, wie man Siri dazu bringt Devices zu schalten:
<pre style="width:50%;">
"Schalte alle Lampen im Obergeschoss ein."
"Schalte Chloes Licht aus."
"Dimme das Licht in der Küche."
"Dimme das Licht im Esszimmer auf 50 %."
"Stelle das Licht in der Küche am hellsten ein."
"Stelle die Temperatur im Tahoe-Haus auf 22 °C ein."
"Stelle das Thermostat im Erdgeschoss auf 21 °C ein.
"Schalte den Drucker im Büro ein."
"Siri, bereite alles für eine Party vor."
"Bereite das Ambiente fürs Abendessen vor."
"Aktiviere den Nachtruhemodus."
</pre>

Mittlerweile kann Siri auch noch die Lichtfarbe von LEDs ändern.

= Hinweise =

== Unterstützte Geräte ==
Das Fhem Plugin von {{Link2FU|430|Andre (justme1968)}} unterstützt automatisch mindestens die folgenden Geräte:

switches (devices with set on and set off commands)
lights (devices with set on and set off commands)
homematc and FS20 dimmers (devices with set on, set off and set dim or set pct commands)
HUE, WifiLight, MilightDevice, SWAP_0000002200000003 (hue, sat, bri, rgb)
homematic, max and pid20 thermostats
homematic, DUOFERN and FS20/IT(?) blinds
homematic, MAX and FHTTK contact sensors (door, window)
HM-SEC-WIN, HM-SEC-KEY
presence, ROOMMATE
SONOS (power, volume)
harmony scenes
temperaturecw and humidity sensors
CO20 air quality sensor
probably some more ...

Über eine entsprechende Konfiguration lässt sich darüber hinaus jedes mit FHEM steuerbare Gerät auf die unterstützten Homekit typen abbilden.

== Zusätzliche Plugins ==
Für manche der über FHEM steuerbaren Geräte wie z.b. MiiLight, Harmony Hub, Phillips Hue, Sonos,... gibt es eigene homekit plugins. Wenn immer möglich empfiehlt es sich aber diese NICHT zu verwenden sondern die Steuerung über die FHEM-Integration zu realisieren da
* diese ist in der Regel sehr viel mächtiger und frei konfigurierbar ist
* es FHEM erlaubt als zentrale Instanz den Überblick über den aktuellen Gesamtzustand zu haben (wichtig bei Geräten die gepollt werden)
* die Ressourcen auf den angesteuerten Geräten schont da Werte optimal gecached werden und nur eine einzige Verbindung aufgebaut wird

== Hinweis für alte homebridge Versionen ==
UPDATE: Homebridge funktioniert mit einer kleinen Einschränkung nun auch mit node 4.0.0. Laut
[https://github.com/cflurin/homebridge-shims/wiki/Minimalist-Homebridge-on-a-Raspberry-Pi Homebridge on a Raspberry Pi] müssen die folgenden Abhängigkeiten (Dependencies) aus der '''package.json''' entfernt werden:
<pre>
"harmonyhubjs-client": "^1.1.4",
"harmonyhubjs-discover": "git+https://github.com/swissmanu/harmonyhubjs-discover.git"
</pre>

== Hinweis zur Geschwindigkeitsoptimierung auf einem Raspberry PI ==

Damit es auf einem Raspberry schneller läuft, wird darüber hinaus empfohlen auch diverse Abhängigkeiten aus der '''package.json''' zu entfernen:
<pre>
"ad2usb": "git+https://github.com/alistairg/node-ad2usb.git#local",
"carwingsjs": "0.0.x",
"chokidar": "^1.0.5",
"eibd": "^0.3.1",
"elkington": "kevinohara80/elkington",
"harmonyhubjs-client": "^1.1.4",
"harmonyhubjs-discover": "git+https://github.com/swissmanu/harmonyhubjs-discover.git",
"lifx-api": "^1.0.1",
"lifx": "git+https://github.com/magicmonkey/lifxjs.git",
"node-hue-api": "^1.0.5",
"node-icontrol": "^0.1.4",
"node-milight-promise": "0.0.x",
"tough-cookie": "^2.0.0",
"sonos": "0.8.x",
"telldus-live": "0.2.x",
"teslams": "1.0.1",
"unofficial-nest-api": "git+https://github.com/hachidorii/unofficial_nodejs_nest.git#d8d48edc952b049ff6320ef99afa7b2f04cdee98",
"wemo": "0.2.x",
"wink-js": "0.0.5",
"komponist" : "0.1.0",
"yamaha-nodejs": "0.4.x",
</pre>

Daher zunächst ein ein Backup der Datei anlegen
<pre>sudo cp package.json package.json.bkp </pre>
Am einfachsten geht das entfernen der Zeilen einem Editor, beispielsweise nano oder vi.
<pre>sudo nano package.json</pre>

Das config file sollte dann wie folgt aussehen: Achtung vor den letzten zwei "}" am Ende darf kein Komma sein.
<source lang="javascript">
{
"name": "homebridge",
"description": "HomeKit support for the impatient",
"version": "0.1.1",
"scripts": {
"start": "DEBUG=* node app.js || true"
},
"repository": {
"type": "git",
"url": "git://github.com/nfarina/homebridge.git"
},
"license": "ISC",
"dependencies": {
"async": "^1.4.2",
"color": "0.10.x",
"debug": "^2.2.0",
"hap-nodejs": "^0.0.2",
"isy-js": "",
"mdns": "^2.2.4",
"netatmo": "1.3.0",
"node-cache": "3.0.0",
"node-persist": "0.0.x",
"node-xmpp-client": "1.0.0-alpha23",
"q": "1.4.x",
"queue": "^3.1.0",
"request": "2.49.x",
"xml2js": "0.4.x",
"xmldoc": "0.1.x"
}
}
</source>

[[Kategorie:HOWTOS]]

SIGNALDuino

2016-01-28T19:40:36Z

Mahowi: Weiterleitung nach SIGNALduino angelegt

#WEITERLEITUNG [[SIGNALduino]]

Konfiguration

2015-02-18T20:37:33Z

Mahowi: /* Konfiguration in einer SQL Datenbank */ DB-Erstellung etc. werden auf separate Seite ausgelagert.

Die '''Konfiguration''' eines Fhem [[Systemübersicht|Systems]] wird im Normalfall definiert durch Eintragungen in der Konfigurationsdatei <code>fhem.cfg</code>, die standardmäßig im Fhem-Installationsverzeichnis abgelegt ist.

Sofern nicht anderweitig erwähnt, beziehen sich alle weiteren Aussagen und Bildschirmfotos auf das [[PGM2|Standard Webinterface]] im Stil "dark".

== Grundstruktur ==
In einer Standardinstallation sind alle Definitionen in der Datei <code>fhem.cfg</code> abgelegt; diese Datei befindet sich im Installationsverzeichnis (z. B. <code>/opt/fhem</code>). Soll alternativ eine andere (Start-)Konfigurationsdatei verwendet werden, so ist deren Name beim Start von Fhem mitzugeben.

== Autocreate ==
Sofern die "Autocreate" Funktion aktiv ist (<code>define autocreate autocreate</code>), werden unter bestimmten Umständen Objekte automatisch angelegt. Diese Definitionen werden immer in der Start-Konfigurationsdatei abgelegt und abgespeichert. Nach der Erstinstallation von Fhem ist die "Autocreate" Funktion standardmäßig aktiv.

== Bearbeitung der Konfiguration ==
[[Bild:saveConfig.png|mini|120px|links|"Knopf" zum Speichern der Konfigurationsänderungen]]
[[Bild:saveConfigChangeList.png|mini|220px|rechts|Beispiel einer Liste der ungesicherten Anderungen der Konfiguration]]
Die Fhem-Konfiguration kann auf verschiedene Arten bearbeitet werden. Für Einsteiger empfiehlt sich grundsätzlich die Verwendung des "Befehl-Eingabefeld" und der "Objektdetails" mit eingeschalteter Syntaxhervorhebung. Die Methoden "Integrierter Editor" und insbesondere "Externer Editor" sollten als "Expertenmodus" angesehen und nur in begründeten (Ausnahme-)Fällen angewendet werden. Insbesondere beim Mischen der Arten können unerwünschte und/oder unerwartete Effekte auftreten, so beispielsweise, wenn ein benötigtes "Save config" nicht erfolgt ist, bevor ein "rereadcfg" oder Neustart von Fhem durchgeführt wird.

Seit Mitte Januar 2015 ist es, wie im Bild rechts gezeigt, möglich, sich eine Teilliste der ungesicherten Konfigurationsänderungen durch anklicken des roten {{Taste|?}} anzeigen zu lassen.

=== Befehl-Eingabefeld ===
[[Bild:ConfCommandField.png|thumb|300px|Right|Befehl-Eingabefeld]]
Eingaben in das Befehl-Eingabefeld (teilweise auch bezeichnet als "Kommando-Eingabefeld" oder kurz "Eingabefeld"), das sich oben auf jeder Seite des Standardinterfaces befindet, stellen einen schnellen und einfachen Weg dar, um z. B. neue Objekte zu definieren (im dargestellten Beispiel die Zuweisung eines (ggf. neuen) Raumes zu einem Objekt). Nach Bestätigung mit der <Enter>-Taste werden die Änderungen unmittelbar wirksam.

Die Änderung müssen manuell in der Konfigurationsdatei abspeichert werden, ansonsten gehen die Änderungen beim Neustart verloren: "Save config" (aus dem Menü in der linken Spalte) anklicken oder den Befehl "save" im Befehl-Eingabefeld eingeben.

=== Objektdetails ===
Durch Anklicken des Namensfeldes eines Objekts werden die Objektdetails aufgerufen. Je nach Objekttyp stehen auf dieser Seite verschiedene Optionen zur Manipulation von Objekteigenschaften zur Verfügung:
* [[Bild:ConfModifyDEF.png|300px|right]] <code>DEF</code> zur Anpassung der Definition
* [[Bild:ConfAttrDropdown.png|300px|right]] Attribute / Attributwerte aus Auswahllisten (nach Auswahl der Werte ist der <code>attr</code> Knopf anzuklicken)
* je nach Objekttyp stehen weitere / andere Aktionen zur
Nach einem Klick auf "Modify" werden die Änderungen an der Defintion unmittelbar wirksam.

Die Änderung müssen manuell in der Konfigurationsdatei abspeichert werden, ansonsten gehen die Änderungen beim Neustart verloren: "Save config" (aus dem Menü in der linken Spalte) anklicken oder den Befehl "save" im Befehl-Eingabefeld eingeben.

=== Integrierter Editor ===
[[Bild:ConfEditFiles.png|thumb|300px|links|Aufruf des integrierten Editors]]
[[Bild:ConfEditSyntaxHighlight.png|mini|300px|rechts|Editfenster (Ausschnitt) mit Syntaxhervorhebung]]
Sollte ein direktes Editieren der Konfigurationsdatei als nötig erachtet werden, wird der Editor über den entsprechenden Menüeintrag in der linken Spalte erreicht. Auf die Einhaltung der Syntax von Befehlen und Definitionen ist zu achten, teilweise sind besondere Maßnahmen zu ergreifen ("Escapen" von Sonderzeichen, verdoppeln von Semikolon). Mit dem Abspeichern der editierten Datei werden die Änderungen unmittelbar aktiv, korrekte Syntax und Semantik vorausgesetzt.

==== Syntaxhervorhebung ====
[[Bild:ConfEditDEFAutocomplete.png|mini|300px|rechts|Automatische Vervollständigung / Befehlsauswahlfenster ("se" getippt, dann Strg+Leertaste gedrückt)]]
Seit Anfang April 2014 ist der in Fhem integrierte Editor um Syntaxhervorhebungs-, Befehlsauswahl- und Befehlsvervollständigungsfunktionen erweitert.

Um die Funktionalität zu aktivieren müssen die folgenden zwei Attribute gesetzt werden:
:<code>attr WEB JavaScripts codemirror/fhem_codemirror.js</code>
:<code>attr WEB codemirrorParam { "theme":"blackboard", "lineNumbers":true }</code>

Die Syntaxhervorhebung / Befehlsvervollständigung, sofern aktiviert, ist wirksam für
* Bearbeitung der [[Konfiguration#Objektdetails|Objektdetails]]
* [[Konfiguration#Integrierter Editor|Integrierter Editor]]

Darüber hinaus wird (wie im Bildauschnitt dargestellt) über Strg+Leertaste eine Befehlsauswahl bzw. automatische Befehlsvervollständigung angeboten.

Der Forums-Thread unter der Überschrift [http://forum.fhem.de/index.php/topic,20444.0.html Javascript Editor einbinden] enthält die Diskussion zum Entwicklungsprozess.

=== Externer Editor ===
Unter bestimmten Umständen kann auch das Editieren der Konfiguration mit einem externen Editor wie z. B.
* Notepad++ (mit der nppFTP-Erweiterung)
* nano in einer Telnet Sitzung
* in wfftp integrierter / integrierbarer Editor
* ...
sinnvoll sein (duplizieren von Definitionen, globale Änderungen, umsortieren von Definitionen, etc.). In diesem Fall sollte der Benutzer sich mit der Bedienung des Editors in der gewählten Umgebung hinreichend gut auskennen.

Auf die Einhaltung der Syntax von Befehlen und Definitionen ist zu achten, teilweise sind besondere Maßnahmen zu ergreifen ("Escapen" von Sonderzeichen, verdoppeln von Semikolon). Nach dem Abspeichern der editierten Datei werden die Änderungen erst nach erneutem Einlesen der Konfiguration aktiv, korrekte Syntax und Semantik vorausgesetzt.

Notwendige Aktionen nach Durchführung der Änderung: "rereadcfg" oder Neustart von Fhem.

==== Syntaxhervorhebung ====
'''Syntax-Highlighting''' kann bei verschiedenen externen Editoren verwendet werden, näheres s. [[Syntax Highlighting bei externen Editoren]].

== Aufteilung der fhem.cfg in mehrere Konfigurationsdateien ==
Die fhem.cfg kann bei Bedarf mit Hilfe des Befehls [[include]] in mehrere Konfigurationsdateien aufgeteilt werden. Dies ist als '''"Expertenmodus"''' zu betrachten und sollte (wenn überhaupt) nur von erfahreneren Usern angewendet werden.

== Konfiguration in einer SQL Datenbank ==
Seit April 2014 (Fhem-Version 5079) können Definitionen alternativ zur Speicherung in einer einfachen Text-Konfigurationsdatei(en) in einer SQL Datenbank abgelegt werden. Hierzu dienen configDB (Hilfsmodul) und configdb (command), die in der [http://fhem.de/commandref.html#configDB commandref] dokumentiert sind.

Weitere Details zu dieser "Alternative":
* Fhem Forum - [http://forum.fhem.de/index.php/topic,20194.0.html Tester gesucht]
* Fhem Forum - [http://forum.fhem.de/index.php/topic,20117.0.html Vorüberlegungen]

[[Kategorie:FHEM]]

Diskussion:Konfiguration

2015-02-18T20:28:03Z

Mahowi: /* Auslagerung der Deatils "Konfiguration_in_einer_SQL_Datenbank" auf separate Wiki-Seite? */

== Umstrukturierung / Umsortierung der Abschnitte ==
Sollte "Auslagerung von Definitionen" nicht als "Expertenweg" bezeichnet werden? Eigentlich braucht man diese Auslagerung nicht, verwirrt eher und führt bei Einsteigern zu Problemen. (@Ph1959de zweifel daher, ob Verlinkung von EnOcean auf diese Wiki-Seite sinnvoll)--[[Benutzer:Krikan|Krikan]] ([[Benutzer Diskussion:Krikan|Diskussion]]) 13:10, 30. Jul. 2014 (UTC)
<hr />
:Bei der "Auslagerung ... = Expertenmodus" stimme ich Dir zu. Baust Du den Hinweis ein? Bei der Gelegenheit sollte der Abschnitt vielleicht auch gleich ganz an den Schluss der Seite verschoben werden.
:Die Verlinkung auf [[Konfiguration]] hätte ich persönlich gern auf jeder Seite die "fhem.cfg" erwähnt ... einfach um regelmäßig darauf hinzuweisen, dass das eigentlich nur eine spezielle Art ist, in Fhem Konfigurationsänderungen vorzunehmen.
:--[[Benutzer:Ph1959de|Peter]] ([[Benutzer Diskussion:Ph1959de|Diskussion]]) 13:38, 30. Jul. 2014 (UTC)
::Habe auf die Schnelle "Auslagerung.. = Expertenmodus" gekennzeichnet und diverse kleine Ergänzungen sowie mehrere Umgliederung'''en''' vorgenommen.
::Verlinkung auf [[Konfiguration]] ist in EnOcean im Wesentlichen umgesetzt.
::--[[Benutzer:Krikan|Krikan]] ([[Benutzer Diskussion:Krikan|Diskussion]]) 19:26, 30. Jul. 2014 (UTC)

::: Ich habe weiter unten unter [[Umbennung "Auslagerung von Definitionen" nach "Aufteilung komplexerer Konfigurationen" sinnvoll?]] einen Kommentar geschrieben, der hierzu passt. Grüße, [[Benutzer:Fabian|Fabian]] ([[Benutzer Diskussion:Fabian|Diskussion]]) 17:21, 15. Feb. 2015 (CET)

== Benennung Eingabefeld ==
Befehlseingabefenster versus (Command-)Eingabefeld: Das hier als "Befehlseingabefenster" bezeichnete Feld wird an anderer Stelle im Wiki "Eingabefeld" -genau wie in UliM´s Einsteiger-PDF- bezeichnet. Sollte man hier nicht eine Vereinheitlichung herbeiführen? Wenn ja, welche? --[[Benutzer:Krikan|Krikan]] ([[Benutzer Diskussion:Krikan|Diskussion]]) 05:54, 4. Aug. 2014 (UTC)
:Eingabefeld finde ich auch besser (als Eingabefenster) ... aber das mit dem "Befehls..." sollte doch irgendwie mit rein, weil es auch andere Eingabefelder gibt. --[[Benutzer:Ph1959de|Peter]] ([[Benutzer Diskussion:Ph1959de|Diskussion]]) 07:42, 4. Aug. 2014 (UTC)
:: UliM nutzt auch "Kommando-Eingabefeld". Wie wäre es damit? Denglisch "Command-Eingabefeld" finde ich nicht "schön". "Befehls-Engabefeld" ist wieder etwas neues. Würde es dann hier und in EnOcean ändern. --[[Benutzer:Krikan|Krikan]] ([[Benutzer Diskussion:Krikan|Diskussion]]) 08:00, 4. Aug. 2014 (UTC)
::<hr />
:::Nachdem das in der deutschen Version der commandref auch "Befehle" heißt (und nicht "Kommandos") finde ich Befehls-Eingabefeld nicht völlig abwegig ... letztlich denke ich, es sollte beides gehen. --[[Benutzer:Ph1959de|Peter]] ([[Benutzer Diskussion:Ph1959de|Diskussion]]) 08:29, 4. Aug. 2014 (UTC)
::::In der DE-commandref hatte ich nicht nachgesehen; danke für den Hinweis. Passe mich der an und übernehme daher "Befehls-Eingabefeld" Gruß, --[[Benutzer:Krikan|Krikan]] ([[Benutzer Diskussion:Krikan|Diskussion]]) 08:38, 4. Aug. 2014 (UTC)

== Umbennung "Auslagerung von Definitionen" nach "Aufteilung komplexerer Konfigurationen" sinnvoll? ==

Hallo Fabian!
Danke für Deine Arbeit im Wiki. Aber mit der obigen Umbennung bin ich ebenso wie mit den Erläuterungen nicht wirklich glücklichn. Wir versuchen seit einiger Zeit von der manuellen Editierei und Zersplitterung der fhem.cfg wegzukommen, damit die dadurch entstehenden unnötigen Probleme vermieden werden. Auf mich macht der Text und besonders die Umbennung den Eindruck, als müsste man komplexe (was ist das?) Konfigurationen aufteilen. Das ist aber definitiv nicht so und ich befürchte, das durch so eine Überschrift Einsteiger in die falsche Richtung gelenkt werden: Wenn ich mein Haus automatisiere, dann muss ich die fhem.cfg aufteilen. Neben der Rückgänigmachung der Überschrift, wäre mir am Liebsten Deinen Text in eine separate Seite auszulagern. -> Seite "Konfiguration" wird von den meisten neuen Modul/Hardwareseiten verlinkt und die nutzen gerade Einsteiger. Gruß,[[Benutzer:Krikan|Christian]] ([[Benutzer Diskussion:Krikan|Diskussion]]) 18:51, 14. Feb. 2015 (CET)
<hr>
: Hallo Christian!
: Ich hoffe ich bin hier nicht zu forsch eingestiegen - sorry, falls ich irgendwem auf die Füße gestiegen bin. Sollte ich für solche Änderungen zukünftig besser erstmal eine Diskussion anstoßen?
: Meine Ansatz ist folgender:
: * Bei umfangreicheren Konfigurationen (viele Devices etc) wird die fhem.cfg schnell sehr groß und dadurch unübersichtlich (mein Empfinden). Mir persönlich wird die Konfiguration von 6 FHTs, einem externen fhem-Raspi, versch. Wetterauswertungen, die Einbindung eines Müllkalenders und eine Internet-Überwachung einfach schon zu viel in einer Datei. ;-)
: * Perfekt wäre natürlich sowas wie eine IDE (mit Abschnittserkennung, Zuklappen, etc). Da das doch ein klein wenig aufwändig zu bauen wäre, trenne ich erstmal lieber die Dateien.
: * Den gesamten Abschnitt in eine eigene Seite auszulagern, finde ich sehr gut. Dann kann man das auch noch besser ausführen. Ausserdem kann in der Einleitung zum Abschnitt noch deutlicher rausgestellt werden, dass dies schon ein Expertenbereich ist.
: * Begriffsfrage: Ich finde den Begriff "Definitionen" unglücklich - ist der etabliert? Ich finde Konfigurationen treffender.
: Gruß, [[Benutzer:Fabian|Fabian]] ([[Benutzer Diskussion:Fabian|Diskussion]]) 17:16, 15. Feb. 2015 (CET)
<hr>
::Hallo Fabian, nein bist aus meiner Sicht nicht zu forsch. Mach ruhig weiter. Zur Sache:
:: * Nach meiner Meinung sollte die direkte Editierei der fhem.cfg eben gerade von Einsteigern vermieden werden, da dies häufig zu Problemen führt. Details werden gerade mal wieder im Forum im Anfängerbereich (sehr emotional) diskutiert. Rudi hat aktuell auch die Bearbeitung der fhem.cfg als readonly gesperrt. Die Auslagerungen der Konfiguration halte ich für noch eine Stufe komplizierter und sehe persönlich nicht die Notwendigkeit. Ich will und kann das aber niemanden vorschreiben; jeder so wie er mag. Nur hätte ich es halt nicht gerne als Standard in dieser (Einsteiger-)Seite, sondern eben eine Auslagerung auf eine separate Seite ("include" in der Kategorie "FhemBefehl", die sowieso noch fehlt) mit Verweis von hier.
:: * Zur Abgrenzung Definition/Konfiguration ist mir keine Etablierung bekannt. Mich stört "nur" das Wort "komplex".
:: Gruß, [[Benutzer:Krikan|Christian]] ([[Benutzer Diskussion:Krikan|Diskussion]]) 07:49, 16. Feb. 2015 (CET)
<hr>
::: Da bin ich völlig bei Dir. Ich kann den "komplexen" ;-) Teil ja mal in einen include-Artikel umziehen... Grüße, --[[Benutzer:Fabian|Fabian]] ([[Benutzer Diskussion:Fabian|Diskussion]]) 11:25, 16. Feb. 2015 (CET)

== Auslagerung der Deatils "Konfiguration_in_einer_SQL_Datenbank" auf separate Wiki-Seite? ==

Hallo Mahowi!
Danke für Deine Ergänzungen und Erläuterungen zu configDB. Ich fände es jedoch besser, wenn diese Details auf eine separaten Wiki-Seite zu configDB abgehandelt werden. Die Seite Konfiguration soll(te) eine Grundlagenseite sein, auf die von vielen Seiten innerhalb des Wikis verlinkt wird. Die Details zur Umstellung configDB und Anlage der Datenbanken sind Einmalgeschichten, die die Aufmerksamkeit auf die eigentlichen Themen nach meiner Meinung überlagern. Danke und Gruß,[[Benutzer:Krikan|Christian]] ([[Benutzer Diskussion:Krikan|Diskussion]]) 10:09, 15. Feb. 2015 (CET)
<hr>
: Hallo Christian!
: Sorry, ich war für ein paar Tage unterwegs.
: Ich nehme die Details erstmal hier raus. Sobald ich dazu komme, setze ich sie dann auf eine separate Seite. Im Forum gab es auch schon eine Debatte dazu.
: Gruß, [[Benutzer:Mahowi|Manny]] ([[Benutzer Diskussion:Mahowi|Diskussion]]) 21:27, 18. Feb. 2015 (CET)

Konfiguration

2015-02-13T14:52:13Z

Mahowi: /* Datenbankerstellung */

Die '''Konfiguration''' eines Fhem [[Systemübersicht|Systems]] wird im Normalfall definiert durch Eintragungen in der Konfigurationsdatei <code>fhem.cfg</code>, die standardmäßig im Fhem-Installationsverzeichnis abgelegt ist.

Sofern nicht anderweitig erwähnt, beziehen sich alle weiteren Aussagen und Bildschirmfotos auf das [[PGM2|Standard Webinterface]] im Stil "dark".

== Grundstruktur ==
In einer Standardinstallation sind alle Definitionen in der Datei <code>fhem.cfg</code> abgelegt; diese Datei befindet sich im Installationsverzeichnis (z. B. <code>/opt/fhem</code>). Soll alternativ eine andere (Start-)Konfigurationsdatei verwendet werden, so ist deren Name beim Start von Fhem mitzugeben.

== Autocreate ==
Sofern die "Autocreate" Funktion aktiv ist (<code>define autocreate autocreate</code>), werden unter bestimmten Umständen Objekte automatisch angelegt. Diese Definitionen werden immer in der Start-Konfigurationsdatei abgelegt und abgespeichert. Nach der Erstinstallation von Fhem ist die "Autocreate" Funktion standardmäßig aktiv.

== Bearbeitung der Konfiguration ==
[[Bild:saveConfig.png|mini|120px|links|"Knopf" zum Speichern der Konfigurationsänderungen]]
[[Bild:saveConfigChangeList.png|mini|220px|rechts|Beispiel einer Liste der ungesicherten Anderungen der Konfiguration]]
Die Fhem-Konfiguration kann auf verschiedene Arten bearbeitet werden. Für Einsteiger empfiehlt sich grundsätzlich die Verwendung des "Befehl-Eingabefeld" und der "Objektdetails" mit eingeschalteter Syntaxhervorhebung. Die Methoden "Integrierter Editor" und insbesondere "Externer Editor" sollten als "Expertenmodus" angesehen und nur in begründeten (Ausnahme-)Fällen angewendet werden. Insbesondere beim Mischen der Arten können unerwünschte und/oder unerwartete Effekte auftreten, so beispielsweise, wenn ein benötigtes "Save config" nicht erfolgt ist, bevor ein "rereadcfg" oder Neustart von Fhem durchgeführt wird.

Seit Mitte Januar 2015 ist es, wie im Bild rechts gezeigt, möglich, sich eine Teilliste der ungesicherten Konfigurationsänderungen durch anklicken des roten {{Taste|?}} anzeigen zu lassen.

=== Befehl-Eingabefeld ===
[[Bild:ConfCommandField.png|thumb|300px|Right|Befehl-Eingabefeld]]
Eingaben in das Befehl-Eingabefeld (teilweise auch bezeichnet als "Kommando-Eingabefeld" oder kurz "Eingabefeld"), das sich oben auf jeder Seite des Standardinterfaces befindet, stellen einen schnellen und einfachen Weg dar, um z. B. neue Objekte zu definieren (im dargestellten Beispiel die Zuweisung eines (ggf. neuen) Raumes zu einem Objekt). Nach Bestätigung mit der <Enter>-Taste werden die Änderungen unmittelbar wirksam.

Die Änderung müssen manuell in der Konfigurationsdatei abspeichert werden, ansonsten gehen die Änderungen beim Neustart verloren: "Save config" (aus dem Menü in der linken Spalte) anklicken oder den Befehl "save" im Befehl-Eingabefeld eingeben.

=== Objektdetails ===
Durch Anklicken des Namensfeldes eines Objekts werden die Objektdetails aufgerufen. Je nach Objekttyp stehen auf dieser Seite verschiedene Optionen zur Manipulation von Objekteigenschaften zur Verfügung:
* [[Bild:ConfModifyDEF.png|300px|right]] <code>DEF</code> zur Anpassung der Definition
* [[Bild:ConfAttrDropdown.png|300px|right]] Attribute / Attributwerte aus Auswahllisten (nach Auswahl der Werte ist der <code>attr</code> Knopf anzuklicken)
* je nach Objekttyp stehen weitere / andere Aktionen zur
Nach einem Klick auf "Modify" werden die Änderungen an der Defintion unmittelbar wirksam.

Die Änderung müssen manuell in der Konfigurationsdatei abspeichert werden, ansonsten gehen die Änderungen beim Neustart verloren: "Save config" (aus dem Menü in der linken Spalte) anklicken oder den Befehl "save" im Befehl-Eingabefeld eingeben.

=== Integrierter Editor ===
[[Bild:ConfEditFiles.png|thumb|300px|links|Aufruf des integrierten Editors]]
[[Bild:ConfEditSyntaxHighlight.png|mini|300px|rechts|Editfenster (Ausschnitt) mit Syntaxhervorhebung]]
Sollte ein direktes Editieren der Konfigurationsdatei als nötig erachtet werden, wird der Editor über den entsprechenden Menüeintrag in der linken Spalte erreicht. Auf die Einhaltung der Syntax von Befehlen und Definitionen ist zu achten, teilweise sind besondere Maßnahmen zu ergreifen ("Escapen" von Sonderzeichen, verdoppeln von Semikolon). Mit dem Abspeichern der editierten Datei werden die Änderungen unmittelbar aktiv, korrekte Syntax und Semantik vorausgesetzt.

=== Syntaxhervorhebung ===
[[Bild:ConfEditDEFAutocomplete.png|mini|300px|rechts|Automatische Vervollständigung / Befehlsauswahlfenster ("se" getippt, dann Strg+Leertaste gedrückt)]]
Seit Anfang April 2014 ist der in Fhem integrierte Editor um Syntaxhervorhebungs-, Befehlsauswahl- und Befehlsvervollständigungsfunktionen erweitert.

Um die Funktionalität zu aktivieren müssen die folgenden zwei Attribute gesetzt werden:
:<code>attr WEB JavaScripts codemirror/fhem_codemirror.js</code>
:<code>attr WEB codemirrorParam { "theme":"blackboard", "lineNumbers":true }</code>

Die Syntaxhervorhebung / Befehlsvervollständigung, sofern aktiviert, ist wirksam für
* Bearbeitung der [[Konfiguration#Objektdetails|Objektdetails]]
* [[Konfiguration#Integrierter Editor|Integrierter Editor]]

Darüber hinaus wird (wie im Bildauschnitt dargestellt) über Strg+Leertaste eine Befehlsauswahl bzw. automatische Befehlsvervollständigung angeboten.

Der Forums-Thread unter der Überschrift [http://forum.fhem.de/index.php/topic,20444.0.html Javascript Editor einbinden] enthält die Diskussion zum Entwicklungsprozess.

=== Externer Editor ===
Unter bestimmten Umständen kann auch das Editieren der Konfiguration mit einem externen Editor wie z. B.
* Notepad++ (mit der nppFTP-Erweiterung)
* nano in einer Telnet Sitzung
* in wfftp integrierter / integrierbarer Editor
* ...
sinnvoll sein (duplizieren von Definitionen, globale Änderungen, umsortieren von Definitionen, etc.). In diesem Fall sollte der Benutzer sich mit der Bedienung des Editors in der gewählten Umgebung hinreichend gut auskennen.

Auf die Einhaltung der Syntax von Befehlen und Definitionen ist zu achten, teilweise sind besondere Maßnahmen zu ergreifen ("Escapen" von Sonderzeichen, verdoppeln von Semikolon). Nach dem Abspeichern der editierten Datei werden die Änderungen erst nach erneutem Einlesen der Konfiguration aktiv, korrekte Syntax und Semantik vorausgesetzt.

Notwendige Aktionen nach Durchführung der Änderung: "rereadcfg" oder Neustart von Fhem.

== Auslagerung von Definitionen ==
Die Methode der Auslagerung von Definitionen gehört zum "Expertenmodus". Sie sollte nur bei detaillierter Kenntnis der Auswirkungen gewählt werden. Selbst einige Entwickler von Fhem wenden diese Methode nicht an. Sofern Definitionen aus der fhem.cfg ausgelagert werden sollen bzw. wurden, können die Dateien mit den ausgelagerten Anweisungen mithilfe von <code>include</code> eingebunden werden.
:<code>include Zimmer1.cfg</code> (Datei muss in <code>/opt/fhem/FHEM</code> liegen)
:<code>include /opt/fhem/eigene/Zimmer1.cfg</code> (Datei muss im angegebenen Verzeichnis liegen)

Sämtliche <code>attr global</code> Definitionen '''müssen''' in der fhem.cfg bleiben.

Nur Konfigurationsdateien, die im Verzeichnis <installationsverzeichnis>/FHEM liegen, werden unter "Edit files" zur Bearbeitung mit dem integrierten Editor aufgeführt.

== Konfiguration in einer SQL Datenbank ==
Seit April 2014 (Fhem-Version 5079) können Definitionen alternativ zur Speicherung in einer einfachen Text-Konfigurationsdatei(en) in einer SQL Datenbank abgelegt werden. Hierzu dienen configDB (Hilfsmodul) und configdb (command), die in der [http://fhem.de/commandref.html#configDB commandref] dokumentiert sind.

=== Voraussetzung ===
==== Datenbank ====
Unterstützt werden:
* [http://www.sqlite.org/ Sqlite]
* [http://www.mysql.de/ MySQL]
* [http://www.postgresql.org/ PostgreSQL]

==== Perl-Module ====
* Text::Diff (libtext-diff-perl)
* DBI (libdbi-perl)
* Je nach Datenbank:
** DBD::SQLite (libdbd-sqlite3-perl)
** DBD::mysql (libdbd-mysql-perl)
** DBD::Pg (libdbd-pg-perl)

=== configDB.conf ===
In einer Datei namens '''configDB.conf''' werden die Parameter für eine Verbindung zur Datenbank (host, username, password, etc.) hinterlegt. Diese muß im fhem Hauptverzeichnis liegen (z.B. /opt/fhem).
* Sqlite<br />
<pre>%dbconfig= (
connection => "SQLite:dbname=/opt/fhem/configDB.db",
user => "",
password => ""
);</pre>
* MySQL<br />
<pre>%dbconfig= (
connection => "mysql:database=configDB;host=localhost;port=3306",
user => "fhemuser",
password => "fhempassword",
);</pre>
* PostgreSQL:<br />
<pre>%dbconfig= (
connection => "Pg:database=configDB;host=localhost",
user => "fhemuser",
password => "fhempassword"
);</pre>

=== Datenbankerstellung ===
Es muß zuerst eine leere Datenbank erstellt werden. Die Tabellen werden automatisch erstellt.
* Sqlite<br />
<pre>pi@raspberrypi ~ $ sqlite3 configDB.db

SQLite version 3.7.13 2012-07-17 17:46:21
Enter ".help" for instructions
Enter SQL statements terminated with a ";"
sqlite> pragma auto_vacuum=2;
sqlite> .quit</pre>
* MySQL<br />
<pre>pi@raspberrypi ~ $ mysql -u root -p
Enter password:
Welcome to the MySQL monitor. Commands end with ; or \g.
Your MySQL connection id is 2937
Server version: 5.5.41-0+wheezy1 (Debian)

Copyright (c) 2000, 2014, Oracle and/or its affiliates. All rights reserved.

Oracle is a registered trademark of Oracle Corporation and/or its
affiliates. Other names may be trademarks of their respective
owners.

Type 'help;' or '\h' for help. Type '\c' to clear the current input statement.

mysql> CREATE DATABASE `configDB` DEFAULT CHARACTER SET utf8 COLLATE utf8_bin;
Query OK, 1 row affected (0.04 sec)

mysql> GRANT CREATE, SELECT, INSERT, DELETE, UPDATE ON `mahowi`.* TO 'fhemuser'@'%';
Query OK, 0 rows affected (0.04 sec)

mysql> \q
Bye</pre>
* PostgreSQL<br />'''''TBD'''''

=== Migration der Konfiguration auf configDB ===
* Im laufenden fhem <code>configdb migrate</code> eingeben. Das kann eine Weile dauern. Wenn die Migration beendet ist, werden die Datenbank-Statistiken angezeigt. Die Original fhem.cfg wird nicht verändert.
* fhem herunterfahren (<code>shutdown</code>)
* fhem neu starten mit <code>perl fhem.pl configDB</code>.
* Eventuell in ''/etc/init.d/fhem'' die Zeile <code>perl fhem.pl fhem.cfg</code> auskommentieren und das ''#'' vor der Zeile <code>perl fhem.pl configDB</code> löschen.

Das war's. Ab jetzt wird die gesamte Konfiguration in einer Datenbank gespeichert.

Weitere Details zu dieser "Alternative":
* Fhem Forum - [http://forum.fhem.de/index.php/topic,20194.0.html Tester gesucht]
* Fhem Forum - [http://forum.fhem.de/index.php/topic,20117.0.html Vorüberlegungen]

[[Kategorie:FHEM]]

Konfiguration

2015-02-13T14:52:00Z

Mahowi: /* configDB.conf */

Die '''Konfiguration''' eines Fhem [[Systemübersicht|Systems]] wird im Normalfall definiert durch Eintragungen in der Konfigurationsdatei <code>fhem.cfg</code>, die standardmäßig im Fhem-Installationsverzeichnis abgelegt ist.

Sofern nicht anderweitig erwähnt, beziehen sich alle weiteren Aussagen und Bildschirmfotos auf das [[PGM2|Standard Webinterface]] im Stil "dark".

== Grundstruktur ==
In einer Standardinstallation sind alle Definitionen in der Datei <code>fhem.cfg</code> abgelegt; diese Datei befindet sich im Installationsverzeichnis (z. B. <code>/opt/fhem</code>). Soll alternativ eine andere (Start-)Konfigurationsdatei verwendet werden, so ist deren Name beim Start von Fhem mitzugeben.

== Autocreate ==
Sofern die "Autocreate" Funktion aktiv ist (<code>define autocreate autocreate</code>), werden unter bestimmten Umständen Objekte automatisch angelegt. Diese Definitionen werden immer in der Start-Konfigurationsdatei abgelegt und abgespeichert. Nach der Erstinstallation von Fhem ist die "Autocreate" Funktion standardmäßig aktiv.

== Bearbeitung der Konfiguration ==
[[Bild:saveConfig.png|mini|120px|links|"Knopf" zum Speichern der Konfigurationsänderungen]]
[[Bild:saveConfigChangeList.png|mini|220px|rechts|Beispiel einer Liste der ungesicherten Anderungen der Konfiguration]]
Die Fhem-Konfiguration kann auf verschiedene Arten bearbeitet werden. Für Einsteiger empfiehlt sich grundsätzlich die Verwendung des "Befehl-Eingabefeld" und der "Objektdetails" mit eingeschalteter Syntaxhervorhebung. Die Methoden "Integrierter Editor" und insbesondere "Externer Editor" sollten als "Expertenmodus" angesehen und nur in begründeten (Ausnahme-)Fällen angewendet werden. Insbesondere beim Mischen der Arten können unerwünschte und/oder unerwartete Effekte auftreten, so beispielsweise, wenn ein benötigtes "Save config" nicht erfolgt ist, bevor ein "rereadcfg" oder Neustart von Fhem durchgeführt wird.

Seit Mitte Januar 2015 ist es, wie im Bild rechts gezeigt, möglich, sich eine Teilliste der ungesicherten Konfigurationsänderungen durch anklicken des roten {{Taste|?}} anzeigen zu lassen.

=== Befehl-Eingabefeld ===
[[Bild:ConfCommandField.png|thumb|300px|Right|Befehl-Eingabefeld]]
Eingaben in das Befehl-Eingabefeld (teilweise auch bezeichnet als "Kommando-Eingabefeld" oder kurz "Eingabefeld"), das sich oben auf jeder Seite des Standardinterfaces befindet, stellen einen schnellen und einfachen Weg dar, um z. B. neue Objekte zu definieren (im dargestellten Beispiel die Zuweisung eines (ggf. neuen) Raumes zu einem Objekt). Nach Bestätigung mit der <Enter>-Taste werden die Änderungen unmittelbar wirksam.

Die Änderung müssen manuell in der Konfigurationsdatei abspeichert werden, ansonsten gehen die Änderungen beim Neustart verloren: "Save config" (aus dem Menü in der linken Spalte) anklicken oder den Befehl "save" im Befehl-Eingabefeld eingeben.

=== Objektdetails ===
Durch Anklicken des Namensfeldes eines Objekts werden die Objektdetails aufgerufen. Je nach Objekttyp stehen auf dieser Seite verschiedene Optionen zur Manipulation von Objekteigenschaften zur Verfügung:
* [[Bild:ConfModifyDEF.png|300px|right]] <code>DEF</code> zur Anpassung der Definition
* [[Bild:ConfAttrDropdown.png|300px|right]] Attribute / Attributwerte aus Auswahllisten (nach Auswahl der Werte ist der <code>attr</code> Knopf anzuklicken)
* je nach Objekttyp stehen weitere / andere Aktionen zur
Nach einem Klick auf "Modify" werden die Änderungen an der Defintion unmittelbar wirksam.

Die Änderung müssen manuell in der Konfigurationsdatei abspeichert werden, ansonsten gehen die Änderungen beim Neustart verloren: "Save config" (aus dem Menü in der linken Spalte) anklicken oder den Befehl "save" im Befehl-Eingabefeld eingeben.

=== Integrierter Editor ===
[[Bild:ConfEditFiles.png|thumb|300px|links|Aufruf des integrierten Editors]]
[[Bild:ConfEditSyntaxHighlight.png|mini|300px|rechts|Editfenster (Ausschnitt) mit Syntaxhervorhebung]]
Sollte ein direktes Editieren der Konfigurationsdatei als nötig erachtet werden, wird der Editor über den entsprechenden Menüeintrag in der linken Spalte erreicht. Auf die Einhaltung der Syntax von Befehlen und Definitionen ist zu achten, teilweise sind besondere Maßnahmen zu ergreifen ("Escapen" von Sonderzeichen, verdoppeln von Semikolon). Mit dem Abspeichern der editierten Datei werden die Änderungen unmittelbar aktiv, korrekte Syntax und Semantik vorausgesetzt.

=== Syntaxhervorhebung ===
[[Bild:ConfEditDEFAutocomplete.png|mini|300px|rechts|Automatische Vervollständigung / Befehlsauswahlfenster ("se" getippt, dann Strg+Leertaste gedrückt)]]
Seit Anfang April 2014 ist der in Fhem integrierte Editor um Syntaxhervorhebungs-, Befehlsauswahl- und Befehlsvervollständigungsfunktionen erweitert.

Um die Funktionalität zu aktivieren müssen die folgenden zwei Attribute gesetzt werden:
:<code>attr WEB JavaScripts codemirror/fhem_codemirror.js</code>
:<code>attr WEB codemirrorParam { "theme":"blackboard", "lineNumbers":true }</code>

Die Syntaxhervorhebung / Befehlsvervollständigung, sofern aktiviert, ist wirksam für
* Bearbeitung der [[Konfiguration#Objektdetails|Objektdetails]]
* [[Konfiguration#Integrierter Editor|Integrierter Editor]]

Darüber hinaus wird (wie im Bildauschnitt dargestellt) über Strg+Leertaste eine Befehlsauswahl bzw. automatische Befehlsvervollständigung angeboten.

Der Forums-Thread unter der Überschrift [http://forum.fhem.de/index.php/topic,20444.0.html Javascript Editor einbinden] enthält die Diskussion zum Entwicklungsprozess.

=== Externer Editor ===
Unter bestimmten Umständen kann auch das Editieren der Konfiguration mit einem externen Editor wie z. B.
* Notepad++ (mit der nppFTP-Erweiterung)
* nano in einer Telnet Sitzung
* in wfftp integrierter / integrierbarer Editor
* ...
sinnvoll sein (duplizieren von Definitionen, globale Änderungen, umsortieren von Definitionen, etc.). In diesem Fall sollte der Benutzer sich mit der Bedienung des Editors in der gewählten Umgebung hinreichend gut auskennen.

Auf die Einhaltung der Syntax von Befehlen und Definitionen ist zu achten, teilweise sind besondere Maßnahmen zu ergreifen ("Escapen" von Sonderzeichen, verdoppeln von Semikolon). Nach dem Abspeichern der editierten Datei werden die Änderungen erst nach erneutem Einlesen der Konfiguration aktiv, korrekte Syntax und Semantik vorausgesetzt.

Notwendige Aktionen nach Durchführung der Änderung: "rereadcfg" oder Neustart von Fhem.

== Auslagerung von Definitionen ==
Die Methode der Auslagerung von Definitionen gehört zum "Expertenmodus". Sie sollte nur bei detaillierter Kenntnis der Auswirkungen gewählt werden. Selbst einige Entwickler von Fhem wenden diese Methode nicht an. Sofern Definitionen aus der fhem.cfg ausgelagert werden sollen bzw. wurden, können die Dateien mit den ausgelagerten Anweisungen mithilfe von <code>include</code> eingebunden werden.
:<code>include Zimmer1.cfg</code> (Datei muss in <code>/opt/fhem/FHEM</code> liegen)
:<code>include /opt/fhem/eigene/Zimmer1.cfg</code> (Datei muss im angegebenen Verzeichnis liegen)

Sämtliche <code>attr global</code> Definitionen '''müssen''' in der fhem.cfg bleiben.

Nur Konfigurationsdateien, die im Verzeichnis <installationsverzeichnis>/FHEM liegen, werden unter "Edit files" zur Bearbeitung mit dem integrierten Editor aufgeführt.

== Konfiguration in einer SQL Datenbank ==
Seit April 2014 (Fhem-Version 5079) können Definitionen alternativ zur Speicherung in einer einfachen Text-Konfigurationsdatei(en) in einer SQL Datenbank abgelegt werden. Hierzu dienen configDB (Hilfsmodul) und configdb (command), die in der [http://fhem.de/commandref.html#configDB commandref] dokumentiert sind.

=== Voraussetzung ===
==== Datenbank ====
Unterstützt werden:
* [http://www.sqlite.org/ Sqlite]
* [http://www.mysql.de/ MySQL]
* [http://www.postgresql.org/ PostgreSQL]

==== Perl-Module ====
* Text::Diff (libtext-diff-perl)
* DBI (libdbi-perl)
* Je nach Datenbank:
** DBD::SQLite (libdbd-sqlite3-perl)
** DBD::mysql (libdbd-mysql-perl)
** DBD::Pg (libdbd-pg-perl)

=== configDB.conf ===
In einer Datei namens '''configDB.conf''' werden die Parameter für eine Verbindung zur Datenbank (host, username, password, etc.) hinterlegt. Diese muß im fhem Hauptverzeichnis liegen (z.B. /opt/fhem).
* Sqlite<br />
<pre>%dbconfig= (
connection => "SQLite:dbname=/opt/fhem/configDB.db",
user => "",
password => ""
);</pre>
* MySQL<br />
<pre>%dbconfig= (
connection => "mysql:database=configDB;host=localhost;port=3306",
user => "fhemuser",
password => "fhempassword",
);</pre>
* PostgreSQL:<br />
<pre>%dbconfig= (
connection => "Pg:database=configDB;host=localhost",
user => "fhemuser",
password => "fhempassword"
);</pre>

==== Datenbankerstellung ====
Es muß zuerst eine leere Datenbank erstellt werden. Die Tabellen werden automatisch erstellt.
* Sqlite<br />
<pre>pi@raspberrypi ~ $ sqlite3 configDB.db

SQLite version 3.7.13 2012-07-17 17:46:21
Enter ".help" for instructions
Enter SQL statements terminated with a ";"
sqlite> pragma auto_vacuum=2;
sqlite> .quit</pre>
* MySQL<br />
<pre>pi@raspberrypi ~ $ mysql -u root -p
Enter password:
Welcome to the MySQL monitor. Commands end with ; or \g.
Your MySQL connection id is 2937
Server version: 5.5.41-0+wheezy1 (Debian)

Copyright (c) 2000, 2014, Oracle and/or its affiliates. All rights reserved.

Oracle is a registered trademark of Oracle Corporation and/or its
affiliates. Other names may be trademarks of their respective
owners.

Type 'help;' or '\h' for help. Type '\c' to clear the current input statement.

mysql> CREATE DATABASE `configDB` DEFAULT CHARACTER SET utf8 COLLATE utf8_bin;
Query OK, 1 row affected (0.04 sec)

mysql> GRANT CREATE, SELECT, INSERT, DELETE, UPDATE ON `mahowi`.* TO 'fhemuser'@'%';
Query OK, 0 rows affected (0.04 sec)

mysql> \q
Bye</pre>
* PostgreSQL<br />'''''TBD'''''

=== Migration der Konfiguration auf configDB ===
* Im laufenden fhem <code>configdb migrate</code> eingeben. Das kann eine Weile dauern. Wenn die Migration beendet ist, werden die Datenbank-Statistiken angezeigt. Die Original fhem.cfg wird nicht verändert.
* fhem herunterfahren (<code>shutdown</code>)
* fhem neu starten mit <code>perl fhem.pl configDB</code>.
* Eventuell in ''/etc/init.d/fhem'' die Zeile <code>perl fhem.pl fhem.cfg</code> auskommentieren und das ''#'' vor der Zeile <code>perl fhem.pl configDB</code> löschen.

Das war's. Ab jetzt wird die gesamte Konfiguration in einer Datenbank gespeichert.

Weitere Details zu dieser "Alternative":
* Fhem Forum - [http://forum.fhem.de/index.php/topic,20194.0.html Tester gesucht]
* Fhem Forum - [http://forum.fhem.de/index.php/topic,20117.0.html Vorüberlegungen]

[[Kategorie:FHEM]]

Konfiguration

2015-02-13T14:51:41Z

Mahowi: /* Migration der Konfiguration auf configDB */

Die '''Konfiguration''' eines Fhem [[Systemübersicht|Systems]] wird im Normalfall definiert durch Eintragungen in der Konfigurationsdatei <code>fhem.cfg</code>, die standardmäßig im Fhem-Installationsverzeichnis abgelegt ist.

Sofern nicht anderweitig erwähnt, beziehen sich alle weiteren Aussagen und Bildschirmfotos auf das [[PGM2|Standard Webinterface]] im Stil "dark".

== Grundstruktur ==
In einer Standardinstallation sind alle Definitionen in der Datei <code>fhem.cfg</code> abgelegt; diese Datei befindet sich im Installationsverzeichnis (z. B. <code>/opt/fhem</code>). Soll alternativ eine andere (Start-)Konfigurationsdatei verwendet werden, so ist deren Name beim Start von Fhem mitzugeben.

== Autocreate ==
Sofern die "Autocreate" Funktion aktiv ist (<code>define autocreate autocreate</code>), werden unter bestimmten Umständen Objekte automatisch angelegt. Diese Definitionen werden immer in der Start-Konfigurationsdatei abgelegt und abgespeichert. Nach der Erstinstallation von Fhem ist die "Autocreate" Funktion standardmäßig aktiv.

== Bearbeitung der Konfiguration ==
[[Bild:saveConfig.png|mini|120px|links|"Knopf" zum Speichern der Konfigurationsänderungen]]
[[Bild:saveConfigChangeList.png|mini|220px|rechts|Beispiel einer Liste der ungesicherten Anderungen der Konfiguration]]
Die Fhem-Konfiguration kann auf verschiedene Arten bearbeitet werden. Für Einsteiger empfiehlt sich grundsätzlich die Verwendung des "Befehl-Eingabefeld" und der "Objektdetails" mit eingeschalteter Syntaxhervorhebung. Die Methoden "Integrierter Editor" und insbesondere "Externer Editor" sollten als "Expertenmodus" angesehen und nur in begründeten (Ausnahme-)Fällen angewendet werden. Insbesondere beim Mischen der Arten können unerwünschte und/oder unerwartete Effekte auftreten, so beispielsweise, wenn ein benötigtes "Save config" nicht erfolgt ist, bevor ein "rereadcfg" oder Neustart von Fhem durchgeführt wird.

Seit Mitte Januar 2015 ist es, wie im Bild rechts gezeigt, möglich, sich eine Teilliste der ungesicherten Konfigurationsänderungen durch anklicken des roten {{Taste|?}} anzeigen zu lassen.

=== Befehl-Eingabefeld ===
[[Bild:ConfCommandField.png|thumb|300px|Right|Befehl-Eingabefeld]]
Eingaben in das Befehl-Eingabefeld (teilweise auch bezeichnet als "Kommando-Eingabefeld" oder kurz "Eingabefeld"), das sich oben auf jeder Seite des Standardinterfaces befindet, stellen einen schnellen und einfachen Weg dar, um z. B. neue Objekte zu definieren (im dargestellten Beispiel die Zuweisung eines (ggf. neuen) Raumes zu einem Objekt). Nach Bestätigung mit der <Enter>-Taste werden die Änderungen unmittelbar wirksam.

Die Änderung müssen manuell in der Konfigurationsdatei abspeichert werden, ansonsten gehen die Änderungen beim Neustart verloren: "Save config" (aus dem Menü in der linken Spalte) anklicken oder den Befehl "save" im Befehl-Eingabefeld eingeben.

=== Objektdetails ===
Durch Anklicken des Namensfeldes eines Objekts werden die Objektdetails aufgerufen. Je nach Objekttyp stehen auf dieser Seite verschiedene Optionen zur Manipulation von Objekteigenschaften zur Verfügung:
* [[Bild:ConfModifyDEF.png|300px|right]] <code>DEF</code> zur Anpassung der Definition
* [[Bild:ConfAttrDropdown.png|300px|right]] Attribute / Attributwerte aus Auswahllisten (nach Auswahl der Werte ist der <code>attr</code> Knopf anzuklicken)
* je nach Objekttyp stehen weitere / andere Aktionen zur
Nach einem Klick auf "Modify" werden die Änderungen an der Defintion unmittelbar wirksam.

Die Änderung müssen manuell in der Konfigurationsdatei abspeichert werden, ansonsten gehen die Änderungen beim Neustart verloren: "Save config" (aus dem Menü in der linken Spalte) anklicken oder den Befehl "save" im Befehl-Eingabefeld eingeben.

=== Integrierter Editor ===
[[Bild:ConfEditFiles.png|thumb|300px|links|Aufruf des integrierten Editors]]
[[Bild:ConfEditSyntaxHighlight.png|mini|300px|rechts|Editfenster (Ausschnitt) mit Syntaxhervorhebung]]
Sollte ein direktes Editieren der Konfigurationsdatei als nötig erachtet werden, wird der Editor über den entsprechenden Menüeintrag in der linken Spalte erreicht. Auf die Einhaltung der Syntax von Befehlen und Definitionen ist zu achten, teilweise sind besondere Maßnahmen zu ergreifen ("Escapen" von Sonderzeichen, verdoppeln von Semikolon). Mit dem Abspeichern der editierten Datei werden die Änderungen unmittelbar aktiv, korrekte Syntax und Semantik vorausgesetzt.

=== Syntaxhervorhebung ===
[[Bild:ConfEditDEFAutocomplete.png|mini|300px|rechts|Automatische Vervollständigung / Befehlsauswahlfenster ("se" getippt, dann Strg+Leertaste gedrückt)]]
Seit Anfang April 2014 ist der in Fhem integrierte Editor um Syntaxhervorhebungs-, Befehlsauswahl- und Befehlsvervollständigungsfunktionen erweitert.

Um die Funktionalität zu aktivieren müssen die folgenden zwei Attribute gesetzt werden:
:<code>attr WEB JavaScripts codemirror/fhem_codemirror.js</code>
:<code>attr WEB codemirrorParam { "theme":"blackboard", "lineNumbers":true }</code>

Die Syntaxhervorhebung / Befehlsvervollständigung, sofern aktiviert, ist wirksam für
* Bearbeitung der [[Konfiguration#Objektdetails|Objektdetails]]
* [[Konfiguration#Integrierter Editor|Integrierter Editor]]

Darüber hinaus wird (wie im Bildauschnitt dargestellt) über Strg+Leertaste eine Befehlsauswahl bzw. automatische Befehlsvervollständigung angeboten.

Der Forums-Thread unter der Überschrift [http://forum.fhem.de/index.php/topic,20444.0.html Javascript Editor einbinden] enthält die Diskussion zum Entwicklungsprozess.

=== Externer Editor ===
Unter bestimmten Umständen kann auch das Editieren der Konfiguration mit einem externen Editor wie z. B.
* Notepad++ (mit der nppFTP-Erweiterung)
* nano in einer Telnet Sitzung
* in wfftp integrierter / integrierbarer Editor
* ...
sinnvoll sein (duplizieren von Definitionen, globale Änderungen, umsortieren von Definitionen, etc.). In diesem Fall sollte der Benutzer sich mit der Bedienung des Editors in der gewählten Umgebung hinreichend gut auskennen.

Auf die Einhaltung der Syntax von Befehlen und Definitionen ist zu achten, teilweise sind besondere Maßnahmen zu ergreifen ("Escapen" von Sonderzeichen, verdoppeln von Semikolon). Nach dem Abspeichern der editierten Datei werden die Änderungen erst nach erneutem Einlesen der Konfiguration aktiv, korrekte Syntax und Semantik vorausgesetzt.

Notwendige Aktionen nach Durchführung der Änderung: "rereadcfg" oder Neustart von Fhem.

== Auslagerung von Definitionen ==
Die Methode der Auslagerung von Definitionen gehört zum "Expertenmodus". Sie sollte nur bei detaillierter Kenntnis der Auswirkungen gewählt werden. Selbst einige Entwickler von Fhem wenden diese Methode nicht an. Sofern Definitionen aus der fhem.cfg ausgelagert werden sollen bzw. wurden, können die Dateien mit den ausgelagerten Anweisungen mithilfe von <code>include</code> eingebunden werden.
:<code>include Zimmer1.cfg</code> (Datei muss in <code>/opt/fhem/FHEM</code> liegen)
:<code>include /opt/fhem/eigene/Zimmer1.cfg</code> (Datei muss im angegebenen Verzeichnis liegen)

Sämtliche <code>attr global</code> Definitionen '''müssen''' in der fhem.cfg bleiben.

Nur Konfigurationsdateien, die im Verzeichnis <installationsverzeichnis>/FHEM liegen, werden unter "Edit files" zur Bearbeitung mit dem integrierten Editor aufgeführt.

== Konfiguration in einer SQL Datenbank ==
Seit April 2014 (Fhem-Version 5079) können Definitionen alternativ zur Speicherung in einer einfachen Text-Konfigurationsdatei(en) in einer SQL Datenbank abgelegt werden. Hierzu dienen configDB (Hilfsmodul) und configdb (command), die in der [http://fhem.de/commandref.html#configDB commandref] dokumentiert sind.

=== Voraussetzung ===
==== Datenbank ====
Unterstützt werden:
* [http://www.sqlite.org/ Sqlite]
* [http://www.mysql.de/ MySQL]
* [http://www.postgresql.org/ PostgreSQL]

==== Perl-Module ====
* Text::Diff (libtext-diff-perl)
* DBI (libdbi-perl)
* Je nach Datenbank:
** DBD::SQLite (libdbd-sqlite3-perl)
** DBD::mysql (libdbd-mysql-perl)
** DBD::Pg (libdbd-pg-perl)

==== configDB.conf ====
In einer Datei namens '''configDB.conf''' werden die Parameter für eine Verbindung zur Datenbank (host, username, password, etc.) hinterlegt. Diese muß im fhem Hauptverzeichnis liegen (z.B. /opt/fhem).
* Sqlite<br />
<pre>%dbconfig= (
connection => "SQLite:dbname=/opt/fhem/configDB.db",
user => "",
password => ""
);</pre>
* MySQL<br />
<pre>%dbconfig= (
connection => "mysql:database=configDB;host=localhost;port=3306",
user => "fhemuser",
password => "fhempassword",
);</pre>
* PostgreSQL:<br />
<pre>%dbconfig= (
connection => "Pg:database=configDB;host=localhost",
user => "fhemuser",
password => "fhempassword"
);</pre>

==== Datenbankerstellung ====
Es muß zuerst eine leere Datenbank erstellt werden. Die Tabellen werden automatisch erstellt.
* Sqlite<br />
<pre>pi@raspberrypi ~ $ sqlite3 configDB.db

SQLite version 3.7.13 2012-07-17 17:46:21
Enter ".help" for instructions
Enter SQL statements terminated with a ";"
sqlite> pragma auto_vacuum=2;
sqlite> .quit</pre>
* MySQL<br />
<pre>pi@raspberrypi ~ $ mysql -u root -p
Enter password:
Welcome to the MySQL monitor. Commands end with ; or \g.
Your MySQL connection id is 2937
Server version: 5.5.41-0+wheezy1 (Debian)

Copyright (c) 2000, 2014, Oracle and/or its affiliates. All rights reserved.

Oracle is a registered trademark of Oracle Corporation and/or its
affiliates. Other names may be trademarks of their respective
owners.

Type 'help;' or '\h' for help. Type '\c' to clear the current input statement.

mysql> CREATE DATABASE `configDB` DEFAULT CHARACTER SET utf8 COLLATE utf8_bin;
Query OK, 1 row affected (0.04 sec)

mysql> GRANT CREATE, SELECT, INSERT, DELETE, UPDATE ON `mahowi`.* TO 'fhemuser'@'%';
Query OK, 0 rows affected (0.04 sec)

mysql> \q
Bye</pre>
* PostgreSQL<br />'''''TBD'''''

=== Migration der Konfiguration auf configDB ===
* Im laufenden fhem <code>configdb migrate</code> eingeben. Das kann eine Weile dauern. Wenn die Migration beendet ist, werden die Datenbank-Statistiken angezeigt. Die Original fhem.cfg wird nicht verändert.
* fhem herunterfahren (<code>shutdown</code>)
* fhem neu starten mit <code>perl fhem.pl configDB</code>.
* Eventuell in ''/etc/init.d/fhem'' die Zeile <code>perl fhem.pl fhem.cfg</code> auskommentieren und das ''#'' vor der Zeile <code>perl fhem.pl configDB</code> löschen.

Das war's. Ab jetzt wird die gesamte Konfiguration in einer Datenbank gespeichert.

Weitere Details zu dieser "Alternative":
* Fhem Forum - [http://forum.fhem.de/index.php/topic,20194.0.html Tester gesucht]
* Fhem Forum - [http://forum.fhem.de/index.php/topic,20117.0.html Vorüberlegungen]

[[Kategorie:FHEM]]

Konfiguration

2015-02-13T14:50:45Z

Mahowi: /* Konfiguration in einer SQL Datenbank */ Migration einer bestehenden fhem-Installation auf configDB beschrieben. DB-Erstellung mit PostgreSQL fehlt noch mangels Erfahrung.

Die '''Konfiguration''' eines Fhem [[Systemübersicht|Systems]] wird im Normalfall definiert durch Eintragungen in der Konfigurationsdatei <code>fhem.cfg</code>, die standardmäßig im Fhem-Installationsverzeichnis abgelegt ist.

Sofern nicht anderweitig erwähnt, beziehen sich alle weiteren Aussagen und Bildschirmfotos auf das [[PGM2|Standard Webinterface]] im Stil "dark".

== Grundstruktur ==
In einer Standardinstallation sind alle Definitionen in der Datei <code>fhem.cfg</code> abgelegt; diese Datei befindet sich im Installationsverzeichnis (z. B. <code>/opt/fhem</code>). Soll alternativ eine andere (Start-)Konfigurationsdatei verwendet werden, so ist deren Name beim Start von Fhem mitzugeben.

== Autocreate ==
Sofern die "Autocreate" Funktion aktiv ist (<code>define autocreate autocreate</code>), werden unter bestimmten Umständen Objekte automatisch angelegt. Diese Definitionen werden immer in der Start-Konfigurationsdatei abgelegt und abgespeichert. Nach der Erstinstallation von Fhem ist die "Autocreate" Funktion standardmäßig aktiv.

== Bearbeitung der Konfiguration ==
[[Bild:saveConfig.png|mini|120px|links|"Knopf" zum Speichern der Konfigurationsänderungen]]
[[Bild:saveConfigChangeList.png|mini|220px|rechts|Beispiel einer Liste der ungesicherten Anderungen der Konfiguration]]
Die Fhem-Konfiguration kann auf verschiedene Arten bearbeitet werden. Für Einsteiger empfiehlt sich grundsätzlich die Verwendung des "Befehl-Eingabefeld" und der "Objektdetails" mit eingeschalteter Syntaxhervorhebung. Die Methoden "Integrierter Editor" und insbesondere "Externer Editor" sollten als "Expertenmodus" angesehen und nur in begründeten (Ausnahme-)Fällen angewendet werden. Insbesondere beim Mischen der Arten können unerwünschte und/oder unerwartete Effekte auftreten, so beispielsweise, wenn ein benötigtes "Save config" nicht erfolgt ist, bevor ein "rereadcfg" oder Neustart von Fhem durchgeführt wird.

Seit Mitte Januar 2015 ist es, wie im Bild rechts gezeigt, möglich, sich eine Teilliste der ungesicherten Konfigurationsänderungen durch anklicken des roten {{Taste|?}} anzeigen zu lassen.

=== Befehl-Eingabefeld ===
[[Bild:ConfCommandField.png|thumb|300px|Right|Befehl-Eingabefeld]]
Eingaben in das Befehl-Eingabefeld (teilweise auch bezeichnet als "Kommando-Eingabefeld" oder kurz "Eingabefeld"), das sich oben auf jeder Seite des Standardinterfaces befindet, stellen einen schnellen und einfachen Weg dar, um z. B. neue Objekte zu definieren (im dargestellten Beispiel die Zuweisung eines (ggf. neuen) Raumes zu einem Objekt). Nach Bestätigung mit der <Enter>-Taste werden die Änderungen unmittelbar wirksam.

Die Änderung müssen manuell in der Konfigurationsdatei abspeichert werden, ansonsten gehen die Änderungen beim Neustart verloren: "Save config" (aus dem Menü in der linken Spalte) anklicken oder den Befehl "save" im Befehl-Eingabefeld eingeben.

=== Objektdetails ===
Durch Anklicken des Namensfeldes eines Objekts werden die Objektdetails aufgerufen. Je nach Objekttyp stehen auf dieser Seite verschiedene Optionen zur Manipulation von Objekteigenschaften zur Verfügung:
* [[Bild:ConfModifyDEF.png|300px|right]] <code>DEF</code> zur Anpassung der Definition
* [[Bild:ConfAttrDropdown.png|300px|right]] Attribute / Attributwerte aus Auswahllisten (nach Auswahl der Werte ist der <code>attr</code> Knopf anzuklicken)
* je nach Objekttyp stehen weitere / andere Aktionen zur
Nach einem Klick auf "Modify" werden die Änderungen an der Defintion unmittelbar wirksam.

Die Änderung müssen manuell in der Konfigurationsdatei abspeichert werden, ansonsten gehen die Änderungen beim Neustart verloren: "Save config" (aus dem Menü in der linken Spalte) anklicken oder den Befehl "save" im Befehl-Eingabefeld eingeben.

=== Integrierter Editor ===
[[Bild:ConfEditFiles.png|thumb|300px|links|Aufruf des integrierten Editors]]
[[Bild:ConfEditSyntaxHighlight.png|mini|300px|rechts|Editfenster (Ausschnitt) mit Syntaxhervorhebung]]
Sollte ein direktes Editieren der Konfigurationsdatei als nötig erachtet werden, wird der Editor über den entsprechenden Menüeintrag in der linken Spalte erreicht. Auf die Einhaltung der Syntax von Befehlen und Definitionen ist zu achten, teilweise sind besondere Maßnahmen zu ergreifen ("Escapen" von Sonderzeichen, verdoppeln von Semikolon). Mit dem Abspeichern der editierten Datei werden die Änderungen unmittelbar aktiv, korrekte Syntax und Semantik vorausgesetzt.

=== Syntaxhervorhebung ===
[[Bild:ConfEditDEFAutocomplete.png|mini|300px|rechts|Automatische Vervollständigung / Befehlsauswahlfenster ("se" getippt, dann Strg+Leertaste gedrückt)]]
Seit Anfang April 2014 ist der in Fhem integrierte Editor um Syntaxhervorhebungs-, Befehlsauswahl- und Befehlsvervollständigungsfunktionen erweitert.

Um die Funktionalität zu aktivieren müssen die folgenden zwei Attribute gesetzt werden:
:<code>attr WEB JavaScripts codemirror/fhem_codemirror.js</code>
:<code>attr WEB codemirrorParam { "theme":"blackboard", "lineNumbers":true }</code>

Die Syntaxhervorhebung / Befehlsvervollständigung, sofern aktiviert, ist wirksam für
* Bearbeitung der [[Konfiguration#Objektdetails|Objektdetails]]
* [[Konfiguration#Integrierter Editor|Integrierter Editor]]

Darüber hinaus wird (wie im Bildauschnitt dargestellt) über Strg+Leertaste eine Befehlsauswahl bzw. automatische Befehlsvervollständigung angeboten.

Der Forums-Thread unter der Überschrift [http://forum.fhem.de/index.php/topic,20444.0.html Javascript Editor einbinden] enthält die Diskussion zum Entwicklungsprozess.

=== Externer Editor ===
Unter bestimmten Umständen kann auch das Editieren der Konfiguration mit einem externen Editor wie z. B.
* Notepad++ (mit der nppFTP-Erweiterung)
* nano in einer Telnet Sitzung
* in wfftp integrierter / integrierbarer Editor
* ...
sinnvoll sein (duplizieren von Definitionen, globale Änderungen, umsortieren von Definitionen, etc.). In diesem Fall sollte der Benutzer sich mit der Bedienung des Editors in der gewählten Umgebung hinreichend gut auskennen.

Auf die Einhaltung der Syntax von Befehlen und Definitionen ist zu achten, teilweise sind besondere Maßnahmen zu ergreifen ("Escapen" von Sonderzeichen, verdoppeln von Semikolon). Nach dem Abspeichern der editierten Datei werden die Änderungen erst nach erneutem Einlesen der Konfiguration aktiv, korrekte Syntax und Semantik vorausgesetzt.

Notwendige Aktionen nach Durchführung der Änderung: "rereadcfg" oder Neustart von Fhem.

== Auslagerung von Definitionen ==
Die Methode der Auslagerung von Definitionen gehört zum "Expertenmodus". Sie sollte nur bei detaillierter Kenntnis der Auswirkungen gewählt werden. Selbst einige Entwickler von Fhem wenden diese Methode nicht an. Sofern Definitionen aus der fhem.cfg ausgelagert werden sollen bzw. wurden, können die Dateien mit den ausgelagerten Anweisungen mithilfe von <code>include</code> eingebunden werden.
:<code>include Zimmer1.cfg</code> (Datei muss in <code>/opt/fhem/FHEM</code> liegen)
:<code>include /opt/fhem/eigene/Zimmer1.cfg</code> (Datei muss im angegebenen Verzeichnis liegen)

Sämtliche <code>attr global</code> Definitionen '''müssen''' in der fhem.cfg bleiben.

Nur Konfigurationsdateien, die im Verzeichnis <installationsverzeichnis>/FHEM liegen, werden unter "Edit files" zur Bearbeitung mit dem integrierten Editor aufgeführt.

== Konfiguration in einer SQL Datenbank ==
Seit April 2014 (Fhem-Version 5079) können Definitionen alternativ zur Speicherung in einer einfachen Text-Konfigurationsdatei(en) in einer SQL Datenbank abgelegt werden. Hierzu dienen configDB (Hilfsmodul) und configdb (command), die in der [http://fhem.de/commandref.html#configDB commandref] dokumentiert sind.

=== Voraussetzung ===
==== Datenbank ====
Unterstützt werden:
* [http://www.sqlite.org/ Sqlite]
* [http://www.mysql.de/ MySQL]
* [http://www.postgresql.org/ PostgreSQL]

==== Perl-Module ====
* Text::Diff (libtext-diff-perl)
* DBI (libdbi-perl)
* Je nach Datenbank:
** DBD::SQLite (libdbd-sqlite3-perl)
** DBD::mysql (libdbd-mysql-perl)
** DBD::Pg (libdbd-pg-perl)

==== configDB.conf ====
In einer Datei namens '''configDB.conf''' werden die Parameter für eine Verbindung zur Datenbank (host, username, password, etc.) hinterlegt. Diese muß im fhem Hauptverzeichnis liegen (z.B. /opt/fhem).
* Sqlite<br />
<pre>%dbconfig= (
connection => "SQLite:dbname=/opt/fhem/configDB.db",
user => "",
password => ""
);</pre>
* MySQL<br />
<pre>%dbconfig= (
connection => "mysql:database=configDB;host=localhost;port=3306",
user => "fhemuser",
password => "fhempassword",
);</pre>
* PostgreSQL:<br />
<pre>%dbconfig= (
connection => "Pg:database=configDB;host=localhost",
user => "fhemuser",
password => "fhempassword"
);</pre>

==== Datenbankerstellung ====
Es muß zuerst eine leere Datenbank erstellt werden. Die Tabellen werden automatisch erstellt.
* Sqlite<br />
<pre>pi@raspberrypi ~ $ sqlite3 configDB.db

SQLite version 3.7.13 2012-07-17 17:46:21
Enter ".help" for instructions
Enter SQL statements terminated with a ";"
sqlite> pragma auto_vacuum=2;
sqlite> .quit</pre>
* MySQL<br />
<pre>pi@raspberrypi ~ $ mysql -u root -p
Enter password:
Welcome to the MySQL monitor. Commands end with ; or \g.
Your MySQL connection id is 2937
Server version: 5.5.41-0+wheezy1 (Debian)

Copyright (c) 2000, 2014, Oracle and/or its affiliates. All rights reserved.

Oracle is a registered trademark of Oracle Corporation and/or its
affiliates. Other names may be trademarks of their respective
owners.

Type 'help;' or '\h' for help. Type '\c' to clear the current input statement.

mysql> CREATE DATABASE `configDB` DEFAULT CHARACTER SET utf8 COLLATE utf8_bin;
Query OK, 1 row affected (0.04 sec)

mysql> GRANT CREATE, SELECT, INSERT, DELETE, UPDATE ON `mahowi`.* TO 'fhemuser'@'%';
Query OK, 0 rows affected (0.04 sec)

mysql> \q
Bye</pre>
* PostgreSQL<br />'''''TBD'''''

==== Migration der Konfiguration auf configDB ====
* Im laufenden fhem <code>configdb migrate</code> eingeben. Das kann eine Weile dauern. Wenn die Migration beendet ist, werden die Datenbank-Statistiken angezeigt. Die Original fhem.cfg wird nicht verändert.
* fhem herunterfahren (<code>shutdown</code>)
* fhem neu starten mit <code>perl fhem.pl configDB</code>.
* Eventuell in ''/etc/init.d/fhem'' die Zeile <code>perl fhem.pl fhem.cfg</code> auskommentieren und das ''#'' vor der Zeile <code>perl fhem.pl configDB</code> löschen.

Das war's. Ab jetzt wird die gesamte Konfiguration in einer Datenbank gespeichert.

Weitere Details zu dieser "Alternative":
* Fhem Forum - [http://forum.fhem.de/index.php/topic,20194.0.html Tester gesucht]
* Fhem Forum - [http://forum.fhem.de/index.php/topic,20117.0.html Vorüberlegungen]

[[Kategorie:FHEM]]

MAX

2015-02-11T17:55:40Z

Mahowi: /* IST-Temperaturwerte */ typos

'''MAX!''' ist eine Heizungssteuerung, die die Raumtemperatur durch funkvernetzte Heizkörperthermostate an den Heizkörpern regelt. MAX! stellt eine Alternative zur [[:Kategorie:FHT Components|FHT]] und [[HomeMatic]] Heizungsteuerung dar.

== Features ==
* Bidirektionale Kommuniktion (jeder Befehl wird mit ACK quittiert)
* Heizkörperthermostate übertragen auch die gemessene Temperatur

== FHEM Module ==
Die MAX Komponenten können über den MAX!Cube per Modul 00_MAXLAN oder über einen [[CUL]] oder [[CUNO]] per 14_CUL_MAX gesteuert werden. In beiden Fällen werden die einzelnen MAX! Geräte vom Modul 10_MAX
bereitgestellt.

Nachteil vom Cube ist, dass man ein Polling machen muss, um zu sehen ob sich der Status eines Gerätes geändert hat. Z.B. checkt man das alle 30 Sekunden. Dann sieht man aber auch Änderungen möglicherweise erst nach 30 Sekunden. Beim CUL sieht man die Funknachrichten direkt. Es wird aber auch ein Kombimodus unterstützt, in welchem man alles über den MAXLAN steuert, der CUL_MAX aber für zeitnahe Benachrichtigungen sorgt.

== Komponenten ==
=== Limit ===
* Auf 8 Thermostate pro Raum beschränkt
* Limit mit Cube liegt bei ca. 140 Geräten. Durch die [[1% Regel]] dürften es aber in der Praxis weniger sein

=== Heizkörperthermostate ===
Unterstützt wird das Einstellen von

* desiredTemperature = auto (Wochenprogramm), manuell (4.5 - 30.5), eco, comfort, boost, until
** (Besonderheit der Werte: 4.5 = Off und 30.5 = On)
* ecoTemperature, comfortTemperature, measurementOffset, maximumTemperature, minimumTemperature, windowOpenTemperature, windowOpenDuration

und das Auslesen

* der gemessenen Temperatur. (Hinweis: Wird bei Verwendung des MAX CUBE nicht regelmäßig aktualisiert)

=== Fensterkontakte ===
Der aktuelle Status (offen/geschlossen) wird (praktisch ohne Verzögerung) angezeigt.

Falls wir nicht mit Ack antworten, wird er mehrmals wiederholt.

Die Fensterkontakte können zusätzlich direkt an mehrere Heizkörperthermostate angelernt werden, und versetzen diese dann automatisch in windowOpenTemperature während sie geöffnet sind.

Wenn der Fensterkontakt an mindestens ein Heizkörperthermostat angelernt ist, dann sendet er zusätzlich stündlich seinen aktuellen Zustand.

'''Beispiel Autocreate'''
MAXLAN_Parse: Paired new device, type ShutterContact, addr 1a2b3c, serial JEQ0123456
autocreate: define MAX_1a2b3c MAX ShutterContact 1a2b3c
autocreate: define FileLog_MAX_1a2b3c FileLog /fhem/log/MAX_1a2b3c-%Y.log MAX_1a2b3c

'''Beispiel Definition'''
define MAX_1a2b3c MAX ShutterContact 1a2b3c

'''Beispiel Log'''
==> MAX_1a2b3c-2013.log <==
2013-10-20_18:52:08 MAX_1a2b3c battery: ok
2013-10-20_18:52:08 MAX_1a2b3c onoff: 0
2013-10-20_18:52:08 MAX_1a2b3c closed

=== Wandthermostate ===
Unterstützt wird das Einstellen von

* desiredTemperature (siehe Heizkörperthermostate), ecoTemperature, comfortTemperature

und das Auslesen

* der gemessenen Temperatur.

=== Eco-Taster ===
'''Achtung''': Zumindest über MAXLAN lässt sich der Zustand weder auslesen, noch wird man über Veränderungen informiert.

Per CUL_MAX funktioniert der Eco-Taster problemlos.

==== Beispielhafte Definition ====
:<code>define BUTTON.EG MAX PushButton 069d33</code>

==== Beispielhafte Event-Ausgabe ====

2013-07-02 21:06:14 MAX BUTTON.EG battery: ok
2013-07-02 21:06:14 MAX BUTTON.EG onoff: 0
2013-07-02 21:06:14 MAX BUTTON.EG closed

Wobei gilt
{| class="wikitable"
|-
! onoff !! Bedeutung
|-
| 0 || Eco
|-
| 1 || Auto
|}

== Anlernen per CUL ==
Das Anlernen funktioniert nur mit zurückgesetzen (Werksreset, also entweder alle 3 Tasten am Heizkörperthermostate betätigen, Batterien einlegen, Anzeige rES; oder in FHEM set factoryReset) Heizkörperthermostaten. Bereits an einen Cube angelernte Heizungsregler können '''nicht''' an ein CUL angemeldet werden, hier ist dann nur das "mitlesen" der Funkbotschaften möglich.

Info: Durch den Reset geht auch ein evtl. per Cube eingestelltes Automatikprogramm verloren.

== Konfiguration ==
Siehe [http://fhem.de/commandref.html#CUL_MAX commandref].

Die Module sind so konzipiert, dass man die offizielle Max! Software nicht benutzen muss. Man kann alles aus FHEM heraus machen. Nachdem das MAXLAN oder CUL_MAX Modul konfiguriert wurden (siehe unten), werden bereits gepairte Geräte automatisch erkannt.

=== MAXLAN ===
Minimale Konfiguration:
:<code>define ml MAXLAN 192.168.178.2</code>
wobei 192.168.178.2 die IP des MAX! Cube ist. Das MAXLAN-Modul findet selbstständig bereits gepairte Geräte und trägt diese in die Konfigurationsdatei fhem.cfg ein. Diese können dann im WEB-Interface mittels „alias“ einen eindeutigen Namen bekommen.

=== CUL_MAX ===
Minimale Konfiguration:

<nowiki>define CUL0 CUL /dev/ttyACM0@9600 0000
attr CUL0 rfmode MAX
define cm CUL_MAX 123456</nowiki>

=== Anlernen ===
Dazu muss der "pairmode" auf MAXLAN/CUL_MAX per
:<code>set ml/cm pairmode</code>
oder über das Web-Interface aktiviert werden. Falls kein Parameter angegeben wird, ist er standardmäßig für 60 Sekunden aktiviert. In dieser Zeit können MAX! Geräte nach deren Anleitung in den Anlernmodus versetzt werden, um sie mit FHEM zu pairen.

=== Geräte untereinander anlernen ===
Es gibt einen anderen Befehl, um Devices untereinander anzulernen (in neueren Versionen des MAX Moduls enthalten, heißt "associate").

Wenn man z.B.
:<code>set MAXFensterKontakt0 associate MaxHeizkörperthermostat3</code>
ausführt, dann sendet der MAXFensterKontakt0 jede Änderung zusätzlich (direkt über Funk, ohne Cube oder FHEM) an das MaxHeizkörperthermostat3.

Damit MaxHeizkörperthermostat3 auch auf die Nachrichten vom MAXFensterKontakt0 hört, muss noch ein
set MaxHeizkörperthermostat3 associate MAXFensterKontakt0 erfolgen.

Dann wechselt MaxHeizkörperthermostat3 immer dann auf die windowOpenTemperature, wenn der AXFensterKontakt0 offen ist. Dabei muss die groupId von beiden Geräte gar nicht gleich sein! (Die Semantik der groupId erschließt sich mir deshalb noch nicht ganz. Ich glaube, man kann damit Befehle (ala set desiredTemperature) an mehrere Thermostate gleichzeitig richten. Im Moment sendet FHEM einfach an jedes Thermostat einen Befehl.)

Wahrscheinlich funktioniert associate genauso zwischen Heizkörper/Wandthermostaten. Das müsste mal jemand ausprobieren und dann hier berichten.

=== Temperatursturzerkennung ===
Die Heizkörperthermostate verfügen über eine interne "Fenster-offen Erkennung" (Temperatursturzerkennung). Wird diese ausgelöst, regeln sie für die Zeit die unter "windowOpenDuration" festgelegt wurde auf die als "windowOpenTemperature" festgelegt Temperatur herunter und danach wieder auf die zuvor eingestellte Temperatur zurück.

Nachteil: Die Erkennung benötigt etwas Zeit und reagiert nicht sofort wie es beim Fensterkontakt oben der Fall ist

Vorteil: Es ist kein Fensterkontakt erforderlich

'''Wichtig:''' Setzt man die windowOpenTemperature auf "Off" (= 4.5 Grad), dann ist die Fenster-offen-Funktion abgeschaltet. Und auch wenn die desiredTemperature gerade auf "On" (= 30.5 Grad") steht, geht der Heizkörper nicht in die Fenster-offen-Funktion.

=== Externer Sensor für Fenster-offen-Erkennung ===
'''Achtung''': Wird nur von CUL_MAX unterstützt!

Ziel dieses Abschnittes ist es, einen externen Sensor (z.B. 1-Wire o.ä.) zu benutzen, um die MAX Heizkörperthermostate in und aus dem Fenster-offen Modus zu holen. Dazu sei bereits ein CUL, ein CUL_MAX und ein MAX Heizkörper definiert:

<nowiki>define CUL0 CUL /dev/ttyACM0@9600 0000
define cm CUL_MAX 123456
define Heizung MAX HeatingThermostat abcdef
attr Heizung IODev cm</nowiki>

Wir müssen einmalig den internen Fake-Fensterkontakt mit dem Heizkörper assozieren
:<code>set Heizung associate fakeShutterContact</code>
damit dieser die Nachrichten vom Fensterkontakt akzeptiert.

Nun können wir per
:<code>set cm fakeSC Heizung 1</code>
die Nachricht "Fenster offen" an die Heizung senden und per
:<code>set cm fakeSC Heizung 0</code>
die Nachricht "Fenster zu".

=== Externer Temperatursensor für Heizkörperregelung ===
'''Achtung''': Wird nur von CUL_MAX unterstützt!

Ziel dieses Abschnittes ist es, einen externen Sensor (z.B. 1-Wire o.ä.) zu benutzen, um die MAX Heizkörperthermostate zu regeln. Dazu sei bereits ein CUL, ein CUL_MAX und ein MAX Heizkörper definiert:

<nowiki>define CUL0 CUL /dev/ttyACM0@9600 0000
define cm CUL_MAX 123456
define Heizung MAX HeatingThermostat abcdef
attr Heizung IODev cm</nowiki>

Wir müssen einmalig das interne Fake-Wandthermostat mit dem Heizkörper assozieren:
:<code>set Heizung associate fakeWallThermostat</code>
damit dieser die Nachrichten vom Wandthermostat akzeptiert. Achtung: Dies schaltet im
Heizkörperthermostat die Regelung mit dem internen Temperaturfühler aus. Ohne die gleich kommenden "fakeWT" Nachrichten wird das Heizkörperthermostat nicht mehr regeln.

Nun können wir per
:<code>set cm fakeWT Heizung 14.5 12.1</code>
die desiredTemperature 14.5 und gemessene Temperatur 12.1 an die Heizung senden. Diese wird dann die Ventile öffnen, bis wir ein "fakeWT" absetzten, dessen gemessene Temperatur höher als die desiredTemperature ist.

Falls man zu lange Zeit (ca. 30 Minuten) kein neues "fakeWT" sendet, wird bei der Heizung das Attribut rferror gleich 1. Es ist nicht klar, ob das neben diesem Attribut auch Auswirkung auf die Funktionalität hat. Es wurde beobachtet, dass dann der interne Temperatursensor bis zum nächsten FakeWT aktiviert wird.

Beispiel eines automatischen Sendens einer externen Temperatur, der externe Temperatursensor heißt "WS300":

<nowiki>define SendExtTemp notify WS300:temperature.* {
MaxFakeWallThermostat("Heizung", %EVTPART1);
}</nowiki>

Dazu die Funktion, bitte in 99_MyUtils.pm eintragen:

sub MaxFakeWallThermostat($$)
{
my ($heizung, $aktTemp) = @_;
my $CULMAX = $defs{$heizung}{LASTInputDev};
my $desiredTemp = ReadingsVal($heizung, "desiredTemperature", undef);
my $windowOpenTemp = ReadingsVal($heizung, "windowOpenTemperature", undef);
my $lastTemp = ReadingsVal($heizung, "LastExtTemperature", 0);
my $lastSet = ReadingsTimestamp($heizung, "LastExtTemperature", 0);
if($desiredTemp && $windowOpenTemp &&
$desiredTemp != $windowOpenTemp &&
(time()-time_str2num($lastSet) >= 600 || abs($aktTemp-$lastTemp)>=0.2 )) {
Log 3, "set $CULMAX fakeWT $heizung $desiredTemp $aktTemp";
readingsSingleUpdate($defs{$heizung}, "LastExtTemperature", $aktTemp, 0);
fhem("set $CULMAX fakeWT $heizung $desiredTemp $aktTemp");
}
}

In diesem Beispiel heißt das zu steuernde Thermostat "Heizung". Die vom externen Sensor gemessene Temperatur wird nur unter den folgenden Voraussetzungen gesendet:
* das Thermostat befindet sich nicht im "Fenster-offen" Modus, und
* das letzte Senden liegt mindestens 10min zurück
* oder die gemessene Temperatur weicht um mindestens 0.2°C von der letzten gesendeten Temperatur ab

=== Wochenheizplan für Wandthermostat/Ventilantriebe erstellen ===
Ein Heizplan, den das Wandthermostat und auch der Ventilantrieb versteht und speichern kann, sieht folgendermaßen aus:
:<code>set WZ_Wandthermostat weekProfile Mon 17,17:30,20,23:00,17 Tue 17,17:30,20,23:00,17 Wed 17,17:30,20,23:00,17 Thu 17,17:30,20,23:00,17 Fri 17,15:00,20,23:00,17 Sat 17,11:00,20,23:00,17 Sun 17,11:00,20,23:00,17</code>
Genauer erläutert wird die Funktionsweise auch in der [http://fhem.de/commandref.html#MAX commandref].

Der gesamte Block kann kopiert und als FHEM Befehl abgesetzt werden. Unter Umständen benötigt das Speichern bzw. Übertragen wegen der Größe etwas Zeit, bevor die aktuellen, neu gesetzten Werte wieder ausgelesen werden können.

'''Bitte folgendes beachten:'''

Es gibt im Zusammenhang mit dem Wochenprogramm ein Problem mit dem letzten Schaltpunkt des Tages.
Der Workaround wurde [http://forum.fhem.de/index.php/topic,17231.msg112738.html#msg112738 hier]
beschrieben.
Man muss dafür sorgen, dass man kurz vor Ende des Tages noch einen Schaltpunkt setzt! Bei mir hat sich ein Schaltpunkt (ohne Änderung der Soll-Temperatur) um 23:55 bewährt:
:<code>set WZ_Wandthermostat weekProfile Mon 17,17:30,20,22:00,17,23:55,17</code>

=== Werte Plotten ===
[[File:Plot_MAX_Beispiel.png|thumb|right|Plot eines MAX Heizkörperthermostates]]
In den Log-Dateien wird regelmäßig der Batteriestatus, die Soll-Temperatur, die Ventilstellung und die Ist-Temperatur (Vorsicht: Wird nicht zuverlässig, möglicherweise nur bei einer Änderung der Ventilstellung übertragen.)

Inhalt der LOG-Datei eines Heizkörperthermostates:

<nowiki>2012-12-30_08:55:31 MAX_018d3f battery: ok
2012-12-30_08:55:31 MAX_018d3f desiredTemperature: 19.5
2012-12-30_08:55:31 MAX_018d3f valveposition: 83
2012-12-30_08:55:31 MAX_018d3f temperature: 16.4</nowiki>

Mit folgender Plot-Datei (max_temp.gplot) kann der Verlauf der Sensordaten gut angezeigt werden.

<nowiki>set terminal png transparent size <SIZE> crop
set output '<OUT>.png'
set xdata time
set timefmt "%Y-%m-%d_%H:%M:%S"
set xlabel " "
set y2tics
set title '<L1>'
set grid xtics y2tics
set y2label "Temperatur in Grad Celsius"
set ylabel "Signal in %"
#FileLog 4:desiredTemperature:0:
#FileLog 4:temperature:0:
#FileLog 4:valveposition:0:
plot \
"< egrep 'desiredTemperature' <IN>"\
using 1:4 axes x1y2 title 'Soll-Temperatur (C)' with lines lw 2 \
"< egrep 'temperature' <IN>"\
using 1:4 axes x1y2 title 'Ist-Temperatur(ungenau)(C)' with lines lw 2 \
"< egrep 'valveposition' <IN>"\
using 1:4 axes x1y1 title 'Ventil (%)' with lines lw 2</nowiki>
Einbinden eines Plots in der fhem.cgf

<nowiki>#Werte plotten
define MAX_017840_weblink weblink fileplot FileLog_MAX_017840:max_temp:CURRENT
attr MAX_017840_weblink label "Kueche Soll-Temperatur Min $data{min1}, Max $data{max1}, Last $data{currval1}"
attr MAX_017840_weblink room MAX</nowiki>

=== Nützliche kleine Erweiterungen ===
'''Einen Alias-Namen vergeben für eine bessere Lesbarkeit im Webinterface'''
:<code>attr MAX_018d3f alias Kueche</code>
'''Die Anzeigen für die einzelnen File-Logs füllen das Webinterface schnell und machen es unübersichtlich.''' Die File-Logs können einfach in einen separaten Raum verbannt werden.
:<code>attr FileLog_MAX_018d3f room LOG</code>
'''Einstellmöglichkeit für die Soll-Temperatur direkt in der „Raum-Seite“ schaffen.''' Die Temperatur wird dauerhaft auf einen bestimmten Wert gestellt. Das Wochenprogramm in dem Thermostat wird deaktiviert.
:<code>attr MAX_018d3f webCmd desiredTemperature</code>

'''Soll-Temperatur setzen, ohne das automatische Programm des Thermostates abzuschalten.'''
Es besteht die Möglichkeit eine Soll-Temperatur bis zum nächsten Schaltzeitpunkt zu setzen. Zum Beispiel kann das automatische Wochenprogramm in den Thermostaten dazu genutzt werden, nur abends die Soll-Temperatur zu senken. So läuft die Heizung nachts nicht voll durch. Wenn jedoch die Temperatur im Web-Interface von Fhem verändert wird, wird auch der Thermostat auf manuell gesetzt. So greift das Wochenprogramm nicht mehr. Abhilfe schafft der Befehl
:<code>set MAX_04711 desiredTemperature auto 20</code>
Damit die Eingabe komfortabel aus Fhem möglich ist, kann ein Dummy-Device erstellt werden:

<nowiki>#Dummy für die Schnell-Einstellung der Temperatur bis zum nächsten automatischen Schaltzeitpunkt
define HeizkoerperBad dummy
attr HeizkoerperBad room MAX,Heizungen
attr HeizkoerperBad setList state:eco,auto,14.0,16.0,17.0,18.0,19.0,20.0,21.0,22.0,23.0
attr HeizkoerperBad webCmd state
define HeizkoerperBad.ntfy notify HeizkoerperBad.* {\
my $valtemp = "%";;\
my $device = "MAX_04711";;\
my $cmd = 'set '.$device.' desiredTemperature auto '.$valtemp;;\
fhem($cmd);;\
}</nowiki>
Dieses Dummy-Device kann alternativ oder ergänzend zu <code>attr MAX_018d3f webCmd desiredTemperature</code> verwendet werden.

== Internals ==
=== IST-Temperaturwerte ===
[[File:Plot_MAX_Beispiel.png|thumb|right|Plot eines MAX Heizkörperthermostates]]
Diese Abbildung zeigt, dass die IST-Temperatur nicht regelmäßig dem MAX CUBE mitgeteilt wird. Im Automatikbetrieb wird bei einer Änderung der Ventilstellung die neue Ventilstellung zusammen mit der aktuellen IST-Temperatur gesendet. Bei der Abbildung war die Therme in der Nacht ausgeschaltet. Daraufhin sank die Temperatur soweit ab, dass das Heizungsthermostat das Ventil in Maximalstellung geöffnet hat. Gegen 08:50 wurde die Therme eingeschaltet und die Soll-Temperatur an diesem Heizungsthermostat erhöht. Während dieser ganzen Zeit erfolgt keine Aktualisierung der Ist-Temperatur. So kommt es auch gegen 10:30 zu einem sprunghaften Temperaturanstieg von 13,5°C auf 19°C (siehe Markierung *A).

Die IST-Temperatur wird anscheinend aktualisiert bei einer Änderung der:

* Ventilstellung
* Soll-Temperatur
* des Betriebsmodus (Auto/Manuell)

Wer eine detaillierte Kurve wünscht, sollte sich den [[MAX! Temperatur-Scanner]] ansehen.

=== MAXLAN ===
=== CUL_MAX ===
The Max devices use a CC1100 chip. For parameters see rf_moritz.c in culfw.
The thermostats use a Wake-On-Radio, thus one has to send packets at the right time.

CC1100 initialization sequence on one of the max devices (not Cube) (format: addr value, both in hex):

<nowiki>00 08
02 46
04 C6
05 26
0B 06
10 C8 //MDMCFG4 DRATE_E=8
11 93 //MDMCFG3 DRATE_M=147, data rate = (256+DRATE_M)*2^DRATE_E/2^28*f_xosc = (9992.599) 1kbit/s (at f_xosc=26 Mhz)
12 03
15 34
17 00
18 18
19 16
1B 43
21 56
25 00
26 11
0D 21
0E 65
0F 6A
07 4C //PKTCTRL1: ADR_CHK=0 APPEND_STATUS=1 CRC_AUTOFLUSH=1 PQT=2 (preamble must have 8 toggling bits before sync word detection)
16 1C //RXTIME=4
RX_TIME_QUAL=1 (when rx timeout expires, keep receiving if either sync word is found or PQI is set (see PQT))
RX_TIME_RSSI=1 (terminate RX if there is no carrier sense within the first 8 symbol periods)
20 78 //WORCTRL, WOR_RES=00 (1.8-1.9 sec), RC_CAL=1, EVENT1=7 (48 ticks), RC_PD=0
1E 87 //WOREVT1
1F 6B //WOREVT0, i.e. EVENT0 = 34667
29 59
2C 81
2D 35
3E C3</nowiki>
<nowiki>Not set, i.e. factory defaults:
13 MDMCFG1 NUM_PREAMBLE=2 (4 preamble bytes)</nowiki>
From the configuration, we see that the

<nowiki>RC Oscillator: f_xosc/750 = 34666.66 Hz
Event1 = Event1(=48 ticks)/RC Oscillator = 1.385 ms
t_Event0 = 750/26Mhz * EVENT0 * 2^(5*WOR_RES) = 1.00 second
C(RX_TIME, WOR_RES)= 0.2254
rx timeout = EVENT0·C(RX_TIME, WOR_RES) ·26/X(=26) = 34667*0.2254 us = 7.8139 ms</nowiki>

The ShutterContact seems to always sleep. Thus it is necessary to trigger it manually (by opening/closing the window) to make it receive messages. Pushing the button may work to. It is also awake just after
pairing, so one may send messages right then. One can use the WakeUp message to keep it from sleeping for some time. (This is also the reason why in the official MAX software, one must trigger the ShutterContact
after removing it from the house. The "factoryReset" packet is sent directly after the "ShutterContactState" packet has been acked.)

== Probleme und Lösungen ==
=== Der Wandthermostat oder Heizthermostat reagieren nicht auf Änderungen über FHEM ===
Das Autocreate von FHEM erkennt, wenn aktiviert, die Geräte initial und legt auch Einträge an. Es fehlt aber noch das Pairing, da sonst keine Steuerung möglich ist!
Wenn im Log also Meldungen wie

<nowiki>2013.03.20 15:12:30 5: CUL_MAX_SendQueueHandler: 1 items in queue
2013.03.20 15:12:30 5: CUL_MAX_SendQueueHandler: 1 items in queue
2013.03.20 15:12:30 2: CUL_MAX_SendQueueHandler: Missing ack from 01c9bb for 0b05008212345601c9bb0000</nowiki>
auftauchen (im Verbose Modus 5), dann wurde vermutlich kein oder ein inkorrektes Paring durchgeführt.
Nach dem Pairing sollten diese Meldungen verschwinden und stattdessen etwas wie
:<code>2013.03.20 15:21:43 5: Got matching ack</code>
auftauchen.

[[Kategorie:Kontaktsensor (magnetisch)]]
[[Kategorie:MAX]]
[[Kategorie:Heizungsventile]]

MAX

2015-02-11T17:54:11Z

Mahowi: /* Nützliche kleine Erweiterungen */ typo

'''MAX!''' ist eine Heizungssteuerung, die die Raumtemperatur durch funkvernetzte Heizkörperthermostate an den Heizkörpern regelt. MAX! stellt eine Alternative zur [[:Kategorie:FHT Components|FHT]] und [[HomeMatic]] Heizungsteuerung dar.

== Features ==
* Bidirektionale Kommuniktion (jeder Befehl wird mit ACK quittiert)
* Heizkörperthermostate übertragen auch die gemessene Temperatur

== FHEM Module ==
Die MAX Komponenten können über den MAX!Cube per Modul 00_MAXLAN oder über einen [[CUL]] oder [[CUNO]] per 14_CUL_MAX gesteuert werden. In beiden Fällen werden die einzelnen MAX! Geräte vom Modul 10_MAX
bereitgestellt.

Nachteil vom Cube ist, dass man ein Polling machen muss, um zu sehen ob sich der Status eines Gerätes geändert hat. Z.B. checkt man das alle 30 Sekunden. Dann sieht man aber auch Änderungen möglicherweise erst nach 30 Sekunden. Beim CUL sieht man die Funknachrichten direkt. Es wird aber auch ein Kombimodus unterstützt, in welchem man alles über den MAXLAN steuert, der CUL_MAX aber für zeitnahe Benachrichtigungen sorgt.

== Komponenten ==
=== Limit ===
* Auf 8 Thermostate pro Raum beschränkt
* Limit mit Cube liegt bei ca. 140 Geräten. Durch die [[1% Regel]] dürften es aber in der Praxis weniger sein

=== Heizkörperthermostate ===
Unterstützt wird das Einstellen von

* desiredTemperature = auto (Wochenprogramm), manuell (4.5 - 30.5), eco, comfort, boost, until
** (Besonderheit der Werte: 4.5 = Off und 30.5 = On)
* ecoTemperature, comfortTemperature, measurementOffset, maximumTemperature, minimumTemperature, windowOpenTemperature, windowOpenDuration

und das Auslesen

* der gemessenen Temperatur. (Hinweis: Wird bei Verwendung des MAX CUBE nicht regelmäßig aktualisiert)

=== Fensterkontakte ===
Der aktuelle Status (offen/geschlossen) wird (praktisch ohne Verzögerung) angezeigt.

Falls wir nicht mit Ack antworten, wird er mehrmals wiederholt.

Die Fensterkontakte können zusätzlich direkt an mehrere Heizkörperthermostate angelernt werden, und versetzen diese dann automatisch in windowOpenTemperature während sie geöffnet sind.

Wenn der Fensterkontakt an mindestens ein Heizkörperthermostat angelernt ist, dann sendet er zusätzlich stündlich seinen aktuellen Zustand.

'''Beispiel Autocreate'''
MAXLAN_Parse: Paired new device, type ShutterContact, addr 1a2b3c, serial JEQ0123456
autocreate: define MAX_1a2b3c MAX ShutterContact 1a2b3c
autocreate: define FileLog_MAX_1a2b3c FileLog /fhem/log/MAX_1a2b3c-%Y.log MAX_1a2b3c

'''Beispiel Definition'''
define MAX_1a2b3c MAX ShutterContact 1a2b3c

'''Beispiel Log'''
==> MAX_1a2b3c-2013.log <==
2013-10-20_18:52:08 MAX_1a2b3c battery: ok
2013-10-20_18:52:08 MAX_1a2b3c onoff: 0
2013-10-20_18:52:08 MAX_1a2b3c closed

=== Wandthermostate ===
Unterstützt wird das Einstellen von

* desiredTemperature (siehe Heizkörperthermostate), ecoTemperature, comfortTemperature

und das Auslesen

* der gemessenen Temperatur.

=== Eco-Taster ===
'''Achtung''': Zumindest über MAXLAN lässt sich der Zustand weder auslesen, noch wird man über Veränderungen informiert.

Per CUL_MAX funktioniert der Eco-Taster problemlos.

==== Beispielhafte Definition ====
:<code>define BUTTON.EG MAX PushButton 069d33</code>

==== Beispielhafte Event-Ausgabe ====

2013-07-02 21:06:14 MAX BUTTON.EG battery: ok
2013-07-02 21:06:14 MAX BUTTON.EG onoff: 0
2013-07-02 21:06:14 MAX BUTTON.EG closed

Wobei gilt
{| class="wikitable"
|-
! onoff !! Bedeutung
|-
| 0 || Eco
|-
| 1 || Auto
|}

== Anlernen per CUL ==
Das Anlernen funktioniert nur mit zurückgesetzen (Werksreset, also entweder alle 3 Tasten am Heizkörperthermostate betätigen, Batterien einlegen, Anzeige rES; oder in FHEM set factoryReset) Heizkörperthermostaten. Bereits an einen Cube angelernte Heizungsregler können '''nicht''' an ein CUL angemeldet werden, hier ist dann nur das "mitlesen" der Funkbotschaften möglich.

Info: Durch den Reset geht auch ein evtl. per Cube eingestelltes Automatikprogramm verloren.

== Konfiguration ==
Siehe [http://fhem.de/commandref.html#CUL_MAX commandref].

Die Module sind so konzipiert, dass man die offizielle Max! Software nicht benutzen muss. Man kann alles aus FHEM heraus machen. Nachdem das MAXLAN oder CUL_MAX Modul konfiguriert wurden (siehe unten), werden bereits gepairte Geräte automatisch erkannt.

=== MAXLAN ===
Minimale Konfiguration:
:<code>define ml MAXLAN 192.168.178.2</code>
wobei 192.168.178.2 die IP des MAX! Cube ist. Das MAXLAN-Modul findet selbstständig bereits gepairte Geräte und trägt diese in die Konfigurationsdatei fhem.cfg ein. Diese können dann im WEB-Interface mittels „alias“ einen eindeutigen Namen bekommen.

=== CUL_MAX ===
Minimale Konfiguration:

<nowiki>define CUL0 CUL /dev/ttyACM0@9600 0000
attr CUL0 rfmode MAX
define cm CUL_MAX 123456</nowiki>

=== Anlernen ===
Dazu muss der "pairmode" auf MAXLAN/CUL_MAX per
:<code>set ml/cm pairmode</code>
oder über das Web-Interface aktiviert werden. Falls kein Parameter angegeben wird, ist er standardmäßig für 60 Sekunden aktiviert. In dieser Zeit können MAX! Geräte nach deren Anleitung in den Anlernmodus versetzt werden, um sie mit FHEM zu pairen.

=== Geräte untereinander anlernen ===
Es gibt einen anderen Befehl, um Devices untereinander anzulernen (in neueren Versionen des MAX Moduls enthalten, heißt "associate").

Wenn man z.B.
:<code>set MAXFensterKontakt0 associate MaxHeizkörperthermostat3</code>
ausführt, dann sendet der MAXFensterKontakt0 jede Änderung zusätzlich (direkt über Funk, ohne Cube oder FHEM) an das MaxHeizkörperthermostat3.

Damit MaxHeizkörperthermostat3 auch auf die Nachrichten vom MAXFensterKontakt0 hört, muss noch ein
set MaxHeizkörperthermostat3 associate MAXFensterKontakt0 erfolgen.

Dann wechselt MaxHeizkörperthermostat3 immer dann auf die windowOpenTemperature, wenn der AXFensterKontakt0 offen ist. Dabei muss die groupId von beiden Geräte gar nicht gleich sein! (Die Semantik der groupId erschließt sich mir deshalb noch nicht ganz. Ich glaube, man kann damit Befehle (ala set desiredTemperature) an mehrere Thermostate gleichzeitig richten. Im Moment sendet FHEM einfach an jedes Thermostat einen Befehl.)

Wahrscheinlich funktioniert associate genauso zwischen Heizkörper/Wandthermostaten. Das müsste mal jemand ausprobieren und dann hier berichten.

=== Temperatursturzerkennung ===
Die Heizkörperthermostate verfügen über eine interne "Fenster-offen Erkennung" (Temperatursturzerkennung). Wird diese ausgelöst, regeln sie für die Zeit die unter "windowOpenDuration" festgelegt wurde auf die als "windowOpenTemperature" festgelegt Temperatur herunter und danach wieder auf die zuvor eingestellte Temperatur zurück.

Nachteil: Die Erkennung benötigt etwas Zeit und reagiert nicht sofort wie es beim Fensterkontakt oben der Fall ist

Vorteil: Es ist kein Fensterkontakt erforderlich

'''Wichtig:''' Setzt man die windowOpenTemperature auf "Off" (= 4.5 Grad), dann ist die Fenster-offen-Funktion abgeschaltet. Und auch wenn die desiredTemperature gerade auf "On" (= 30.5 Grad") steht, geht der Heizkörper nicht in die Fenster-offen-Funktion.

=== Externer Sensor für Fenster-offen-Erkennung ===
'''Achtung''': Wird nur von CUL_MAX unterstützt!

Ziel dieses Abschnittes ist es, einen externen Sensor (z.B. 1-Wire o.ä.) zu benutzen, um die MAX Heizkörperthermostate in und aus dem Fenster-offen Modus zu holen. Dazu sei bereits ein CUL, ein CUL_MAX und ein MAX Heizkörper definiert:

<nowiki>define CUL0 CUL /dev/ttyACM0@9600 0000
define cm CUL_MAX 123456
define Heizung MAX HeatingThermostat abcdef
attr Heizung IODev cm</nowiki>

Wir müssen einmalig den internen Fake-Fensterkontakt mit dem Heizkörper assozieren
:<code>set Heizung associate fakeShutterContact</code>
damit dieser die Nachrichten vom Fensterkontakt akzeptiert.

Nun können wir per
:<code>set cm fakeSC Heizung 1</code>
die Nachricht "Fenster offen" an die Heizung senden und per
:<code>set cm fakeSC Heizung 0</code>
die Nachricht "Fenster zu".

=== Externer Temperatursensor für Heizkörperregelung ===
'''Achtung''': Wird nur von CUL_MAX unterstützt!

Ziel dieses Abschnittes ist es, einen externen Sensor (z.B. 1-Wire o.ä.) zu benutzen, um die MAX Heizkörperthermostate zu regeln. Dazu sei bereits ein CUL, ein CUL_MAX und ein MAX Heizkörper definiert:

<nowiki>define CUL0 CUL /dev/ttyACM0@9600 0000
define cm CUL_MAX 123456
define Heizung MAX HeatingThermostat abcdef
attr Heizung IODev cm</nowiki>

Wir müssen einmalig das interne Fake-Wandthermostat mit dem Heizkörper assozieren:
:<code>set Heizung associate fakeWallThermostat</code>
damit dieser die Nachrichten vom Wandthermostat akzeptiert. Achtung: Dies schaltet im
Heizkörperthermostat die Regelung mit dem internen Temperaturfühler aus. Ohne die gleich kommenden "fakeWT" Nachrichten wird das Heizkörperthermostat nicht mehr regeln.

Nun können wir per
:<code>set cm fakeWT Heizung 14.5 12.1</code>
die desiredTemperature 14.5 und gemessene Temperatur 12.1 an die Heizung senden. Diese wird dann die Ventile öffnen, bis wir ein "fakeWT" absetzten, dessen gemessene Temperatur höher als die desiredTemperature ist.

Falls man zu lange Zeit (ca. 30 Minuten) kein neues "fakeWT" sendet, wird bei der Heizung das Attribut rferror gleich 1. Es ist nicht klar, ob das neben diesem Attribut auch Auswirkung auf die Funktionalität hat. Es wurde beobachtet, dass dann der interne Temperatursensor bis zum nächsten FakeWT aktiviert wird.

Beispiel eines automatischen Sendens einer externen Temperatur, der externe Temperatursensor heißt "WS300":

<nowiki>define SendExtTemp notify WS300:temperature.* {
MaxFakeWallThermostat("Heizung", %EVTPART1);
}</nowiki>

Dazu die Funktion, bitte in 99_MyUtils.pm eintragen:

sub MaxFakeWallThermostat($$)
{
my ($heizung, $aktTemp) = @_;
my $CULMAX = $defs{$heizung}{LASTInputDev};
my $desiredTemp = ReadingsVal($heizung, "desiredTemperature", undef);
my $windowOpenTemp = ReadingsVal($heizung, "windowOpenTemperature", undef);
my $lastTemp = ReadingsVal($heizung, "LastExtTemperature", 0);
my $lastSet = ReadingsTimestamp($heizung, "LastExtTemperature", 0);
if($desiredTemp && $windowOpenTemp &&
$desiredTemp != $windowOpenTemp &&
(time()-time_str2num($lastSet) >= 600 || abs($aktTemp-$lastTemp)>=0.2 )) {
Log 3, "set $CULMAX fakeWT $heizung $desiredTemp $aktTemp";
readingsSingleUpdate($defs{$heizung}, "LastExtTemperature", $aktTemp, 0);
fhem("set $CULMAX fakeWT $heizung $desiredTemp $aktTemp");
}
}

In diesem Beispiel heißt das zu steuernde Thermostat "Heizung". Die vom externen Sensor gemessene Temperatur wird nur unter den folgenden Voraussetzungen gesendet:
* das Thermostat befindet sich nicht im "Fenster-offen" Modus, und
* das letzte Senden liegt mindestens 10min zurück
* oder die gemessene Temperatur weicht um mindestens 0.2°C von der letzten gesendeten Temperatur ab

=== Wochenheizplan für Wandthermostat/Ventilantriebe erstellen ===
Ein Heizplan, den das Wandthermostat und auch der Ventilantrieb versteht und speichern kann, sieht folgendermaßen aus:
:<code>set WZ_Wandthermostat weekProfile Mon 17,17:30,20,23:00,17 Tue 17,17:30,20,23:00,17 Wed 17,17:30,20,23:00,17 Thu 17,17:30,20,23:00,17 Fri 17,15:00,20,23:00,17 Sat 17,11:00,20,23:00,17 Sun 17,11:00,20,23:00,17</code>
Genauer erläutert wird die Funktionsweise auch in der [http://fhem.de/commandref.html#MAX commandref].

Der gesamte Block kann kopiert und als FHEM Befehl abgesetzt werden. Unter Umständen benötigt das Speichern bzw. Übertragen wegen der Größe etwas Zeit, bevor die aktuellen, neu gesetzten Werte wieder ausgelesen werden können.

'''Bitte folgendes beachten:'''

Es gibt im Zusammenhang mit dem Wochenprogramm ein Problem mit dem letzten Schaltpunkt des Tages.
Der Workaround wurde [http://forum.fhem.de/index.php/topic,17231.msg112738.html#msg112738 hier]
beschrieben.
Man muss dafür sorgen, dass man kurz vor Ende des Tages noch einen Schaltpunkt setzt! Bei mir hat sich ein Schaltpunkt (ohne Änderung der Soll-Temperatur) um 23:55 bewährt:
:<code>set WZ_Wandthermostat weekProfile Mon 17,17:30,20,22:00,17,23:55,17</code>

=== Werte Plotten ===
[[File:Plot_MAX_Beispiel.png|thumb|right|Plot eines MAX Heizkörperthermostates]]
In den Log-Dateien wird regelmäßig der Batteriestatus, die Soll-Temperatur, die Ventilstellung und die Ist-Temperatur (Vorsicht: Wird nicht zuverlässig, möglicherweise nur bei einer Änderung der Ventilstellung übertragen.)

Inhalt der LOG-Datei eines Heizkörperthermostates:

<nowiki>2012-12-30_08:55:31 MAX_018d3f battery: ok
2012-12-30_08:55:31 MAX_018d3f desiredTemperature: 19.5
2012-12-30_08:55:31 MAX_018d3f valveposition: 83
2012-12-30_08:55:31 MAX_018d3f temperature: 16.4</nowiki>

Mit folgender Plot-Datei (max_temp.gplot) kann der Verlauf der Sensordaten gut angezeigt werden.

<nowiki>set terminal png transparent size <SIZE> crop
set output '<OUT>.png'
set xdata time
set timefmt "%Y-%m-%d_%H:%M:%S"
set xlabel " "
set y2tics
set title '<L1>'
set grid xtics y2tics
set y2label "Temperatur in Grad Celsius"
set ylabel "Signal in %"
#FileLog 4:desiredTemperature:0:
#FileLog 4:temperature:0:
#FileLog 4:valveposition:0:
plot \
"< egrep 'desiredTemperature' <IN>"\
using 1:4 axes x1y2 title 'Soll-Temperatur (C)' with lines lw 2 \
"< egrep 'temperature' <IN>"\
using 1:4 axes x1y2 title 'Ist-Temperatur(ungenau)(C)' with lines lw 2 \
"< egrep 'valveposition' <IN>"\
using 1:4 axes x1y1 title 'Ventil (%)' with lines lw 2</nowiki>
Einbinden eines Plots in der fhem.cgf

<nowiki>#Werte plotten
define MAX_017840_weblink weblink fileplot FileLog_MAX_017840:max_temp:CURRENT
attr MAX_017840_weblink label "Kueche Soll-Temperatur Min $data{min1}, Max $data{max1}, Last $data{currval1}"
attr MAX_017840_weblink room MAX</nowiki>

=== Nützliche kleine Erweiterungen ===
'''Einen Alias-Namen vergeben für eine bessere Lesbarkeit im Webinterface'''
:<code>attr MAX_018d3f alias Kueche</code>
'''Die Anzeigen für die einzelnen File-Logs füllen das Webinterface schnell und machen es unübersichtlich.''' Die File-Logs können einfach in einen separaten Raum verbannt werden.
:<code>attr FileLog_MAX_018d3f room LOG</code>
'''Einstellmöglichkeit für die Soll-Temperatur direkt in der „Raum-Seite“ schaffen.''' Die Temperatur wird dauerhaft auf einen bestimmten Wert gestellt. Das Wochenprogramm in dem Thermostat wird deaktiviert.
:<code>attr MAX_018d3f webCmd desiredTemperature</code>

'''Soll-Temperatur setzen, ohne das automatische Programm des Thermostates abzuschalten.'''
Es besteht die Möglichkeit eine Soll-Temperatur bis zum nächsten Schaltzeitpunkt zu setzen. Zum Beispiel kann das automatische Wochenprogramm in den Thermostaten dazu genutzt werden, nur abends die Soll-Temperatur zu senken. So läuft die Heizung nachts nicht voll durch. Wenn jedoch die Temperatur im Web-Interface von Fhem verändert wird, wird auch der Thermostat auf manuell gesetzt. So greift das Wochenprogramm nicht mehr. Abhilfe schafft der Befehl
:<code>set MAX_04711 desiredTemperature auto 20</code>
Damit die Eingabe komfortabel aus Fhem möglich ist, kann ein Dummy-Device erstellt werden:

<nowiki>#Dummy für die Schnell-Einstellung der Temperatur bis zum nächsten automatischen Schaltzeitpunkt
define HeizkoerperBad dummy
attr HeizkoerperBad room MAX,Heizungen
attr HeizkoerperBad setList state:eco,auto,14.0,16.0,17.0,18.0,19.0,20.0,21.0,22.0,23.0
attr HeizkoerperBad webCmd state
define HeizkoerperBad.ntfy notify HeizkoerperBad.* {\
my $valtemp = "%";;\
my $device = "MAX_04711";;\
my $cmd = 'set '.$device.' desiredTemperature auto '.$valtemp;;\
fhem($cmd);;\
}</nowiki>
Dieses Dummy-Device kann alternativ oder ergänzend zu <code>attr MAX_018d3f webCmd desiredTemperature</code> verwendet werden.

== Internals ==
=== IST-Temperaturwerte ===
[[File:Plot_MAX_Beispiel.png|thumb|right|Plot eines MAX Heizkörperthermostates]]
Diese Abbildung zeigt, dass die IST-Temperatur nicht regelmäßig dem MAX CUBE mitgeteilt wird. Im Automatikbetrieb wird beim einer Änderung der Ventilstellung die neue Ventilstellung zusammen mit der aktuellen IST-Temperatur gesendet. Bei der Abbildung war die Therme in der Nacht ausgeschaltet. Daraufhin sank die Temperatur soweit ab, dass das Heizungsthermostat das Ventil in Maximalstellung geöffnet hat. Gegen 08:50 wurde die Therme eingeschaltet und die Soll-Temperatur an diesem Heizungsthermostat erhöht. Während dieser ganzen Zeit erfolgt keine Aktualisierung der Ist-Temperatur. So kommt es auch gegen 10:30 zu einem sprunghaften Temperaturanstieg von 13,5°C auf 19°C (siehe Markierung *A).

Die IST-Temperatur wird anscheinend aktualisiert bei einer Änderung der:

* Ventilstellung
* Soll-Temperatur
* des Betriebsmodis (Auto/Manuell)

Wer eine detaillierte Kurven wünscht, sollte sich den [[MAX! Temperatur-Scanner]] ansehen.

=== MAXLAN ===
=== CUL_MAX ===
The Max devices use a CC1100 chip. For parameters see rf_moritz.c in culfw.
The thermostats use a Wake-On-Radio, thus one has to send packets at the right time.

CC1100 initialization sequence on one of the max devices (not Cube) (format: addr value, both in hex):

<nowiki>00 08
02 46
04 C6
05 26
0B 06
10 C8 //MDMCFG4 DRATE_E=8
11 93 //MDMCFG3 DRATE_M=147, data rate = (256+DRATE_M)*2^DRATE_E/2^28*f_xosc = (9992.599) 1kbit/s (at f_xosc=26 Mhz)
12 03
15 34
17 00
18 18
19 16
1B 43
21 56
25 00
26 11
0D 21
0E 65
0F 6A
07 4C //PKTCTRL1: ADR_CHK=0 APPEND_STATUS=1 CRC_AUTOFLUSH=1 PQT=2 (preamble must have 8 toggling bits before sync word detection)
16 1C //RXTIME=4
RX_TIME_QUAL=1 (when rx timeout expires, keep receiving if either sync word is found or PQI is set (see PQT))
RX_TIME_RSSI=1 (terminate RX if there is no carrier sense within the first 8 symbol periods)
20 78 //WORCTRL, WOR_RES=00 (1.8-1.9 sec), RC_CAL=1, EVENT1=7 (48 ticks), RC_PD=0
1E 87 //WOREVT1
1F 6B //WOREVT0, i.e. EVENT0 = 34667
29 59
2C 81
2D 35
3E C3</nowiki>
<nowiki>Not set, i.e. factory defaults:
13 MDMCFG1 NUM_PREAMBLE=2 (4 preamble bytes)</nowiki>
From the configuration, we see that the

<nowiki>RC Oscillator: f_xosc/750 = 34666.66 Hz
Event1 = Event1(=48 ticks)/RC Oscillator = 1.385 ms
t_Event0 = 750/26Mhz * EVENT0 * 2^(5*WOR_RES) = 1.00 second
C(RX_TIME, WOR_RES)= 0.2254
rx timeout = EVENT0·C(RX_TIME, WOR_RES) ·26/X(=26) = 34667*0.2254 us = 7.8139 ms</nowiki>

The ShutterContact seems to always sleep. Thus it is necessary to trigger it manually (by opening/closing the window) to make it receive messages. Pushing the button may work to. It is also awake just after
pairing, so one may send messages right then. One can use the WakeUp message to keep it from sleeping for some time. (This is also the reason why in the official MAX software, one must trigger the ShutterContact
after removing it from the house. The "factoryReset" packet is sent directly after the "ShutterContactState" packet has been acked.)

== Probleme und Lösungen ==
=== Der Wandthermostat oder Heizthermostat reagieren nicht auf Änderungen über FHEM ===
Das Autocreate von FHEM erkennt, wenn aktiviert, die Geräte initial und legt auch Einträge an. Es fehlt aber noch das Pairing, da sonst keine Steuerung möglich ist!
Wenn im Log also Meldungen wie

<nowiki>2013.03.20 15:12:30 5: CUL_MAX_SendQueueHandler: 1 items in queue
2013.03.20 15:12:30 5: CUL_MAX_SendQueueHandler: 1 items in queue
2013.03.20 15:12:30 2: CUL_MAX_SendQueueHandler: Missing ack from 01c9bb for 0b05008212345601c9bb0000</nowiki>
auftauchen (im Verbose Modus 5), dann wurde vermutlich kein oder ein inkorrektes Paring durchgeführt.
Nach dem Pairing sollten diese Meldungen verschwinden und stattdessen etwas wie
:<code>2013.03.20 15:21:43 5: Got matching ack</code>
auftauchen.

[[Kategorie:Kontaktsensor (magnetisch)]]
[[Kategorie:MAX]]
[[Kategorie:Heizungsventile]]

MAX

2015-02-11T17:50:40Z

Mahowi: /* Externer Temperatursensor für Heizkörperregelung */ wird nur von CUL_MAX unterstützt

'''MAX!''' ist eine Heizungssteuerung, die die Raumtemperatur durch funkvernetzte Heizkörperthermostate an den Heizkörpern regelt. MAX! stellt eine Alternative zur [[:Kategorie:FHT Components|FHT]] und [[HomeMatic]] Heizungsteuerung dar.

== Features ==
* Bidirektionale Kommuniktion (jeder Befehl wird mit ACK quittiert)
* Heizkörperthermostate übertragen auch die gemessene Temperatur

== FHEM Module ==
Die MAX Komponenten können über den MAX!Cube per Modul 00_MAXLAN oder über einen [[CUL]] oder [[CUNO]] per 14_CUL_MAX gesteuert werden. In beiden Fällen werden die einzelnen MAX! Geräte vom Modul 10_MAX
bereitgestellt.

Nachteil vom Cube ist, dass man ein Polling machen muss, um zu sehen ob sich der Status eines Gerätes geändert hat. Z.B. checkt man das alle 30 Sekunden. Dann sieht man aber auch Änderungen möglicherweise erst nach 30 Sekunden. Beim CUL sieht man die Funknachrichten direkt. Es wird aber auch ein Kombimodus unterstützt, in welchem man alles über den MAXLAN steuert, der CUL_MAX aber für zeitnahe Benachrichtigungen sorgt.

== Komponenten ==
=== Limit ===
* Auf 8 Thermostate pro Raum beschränkt
* Limit mit Cube liegt bei ca. 140 Geräten. Durch die [[1% Regel]] dürften es aber in der Praxis weniger sein

=== Heizkörperthermostate ===
Unterstützt wird das Einstellen von

* desiredTemperature = auto (Wochenprogramm), manuell (4.5 - 30.5), eco, comfort, boost, until
** (Besonderheit der Werte: 4.5 = Off und 30.5 = On)
* ecoTemperature, comfortTemperature, measurementOffset, maximumTemperature, minimumTemperature, windowOpenTemperature, windowOpenDuration

und das Auslesen

* der gemessenen Temperatur. (Hinweis: Wird bei Verwendung des MAX CUBE nicht regelmäßig aktualisiert)

=== Fensterkontakte ===
Der aktuelle Status (offen/geschlossen) wird (praktisch ohne Verzögerung) angezeigt.

Falls wir nicht mit Ack antworten, wird er mehrmals wiederholt.

Die Fensterkontakte können zusätzlich direkt an mehrere Heizkörperthermostate angelernt werden, und versetzen diese dann automatisch in windowOpenTemperature während sie geöffnet sind.

Wenn der Fensterkontakt an mindestens ein Heizkörperthermostat angelernt ist, dann sendet er zusätzlich stündlich seinen aktuellen Zustand.

'''Beispiel Autocreate'''
MAXLAN_Parse: Paired new device, type ShutterContact, addr 1a2b3c, serial JEQ0123456
autocreate: define MAX_1a2b3c MAX ShutterContact 1a2b3c
autocreate: define FileLog_MAX_1a2b3c FileLog /fhem/log/MAX_1a2b3c-%Y.log MAX_1a2b3c

'''Beispiel Definition'''
define MAX_1a2b3c MAX ShutterContact 1a2b3c

'''Beispiel Log'''
==> MAX_1a2b3c-2013.log <==
2013-10-20_18:52:08 MAX_1a2b3c battery: ok
2013-10-20_18:52:08 MAX_1a2b3c onoff: 0
2013-10-20_18:52:08 MAX_1a2b3c closed

=== Wandthermostate ===
Unterstützt wird das Einstellen von

* desiredTemperature (siehe Heizkörperthermostate), ecoTemperature, comfortTemperature

und das Auslesen

* der gemessenen Temperatur.

=== Eco-Taster ===
'''Achtung''': Zumindest über MAXLAN lässt sich der Zustand weder auslesen, noch wird man über Veränderungen informiert.

Per CUL_MAX funktioniert der Eco-Taster problemlos.

==== Beispielhafte Definition ====
:<code>define BUTTON.EG MAX PushButton 069d33</code>

==== Beispielhafte Event-Ausgabe ====

2013-07-02 21:06:14 MAX BUTTON.EG battery: ok
2013-07-02 21:06:14 MAX BUTTON.EG onoff: 0
2013-07-02 21:06:14 MAX BUTTON.EG closed

Wobei gilt
{| class="wikitable"
|-
! onoff !! Bedeutung
|-
| 0 || Eco
|-
| 1 || Auto
|}

== Anlernen per CUL ==
Das Anlernen funktioniert nur mit zurückgesetzen (Werksreset, also entweder alle 3 Tasten am Heizkörperthermostate betätigen, Batterien einlegen, Anzeige rES; oder in FHEM set factoryReset) Heizkörperthermostaten. Bereits an einen Cube angelernte Heizungsregler können '''nicht''' an ein CUL angemeldet werden, hier ist dann nur das "mitlesen" der Funkbotschaften möglich.

Info: Durch den Reset geht auch ein evtl. per Cube eingestelltes Automatikprogramm verloren.

== Konfiguration ==
Siehe [http://fhem.de/commandref.html#CUL_MAX commandref].

Die Module sind so konzipiert, dass man die offizielle Max! Software nicht benutzen muss. Man kann alles aus FHEM heraus machen. Nachdem das MAXLAN oder CUL_MAX Modul konfiguriert wurden (siehe unten), werden bereits gepairte Geräte automatisch erkannt.

=== MAXLAN ===
Minimale Konfiguration:
:<code>define ml MAXLAN 192.168.178.2</code>
wobei 192.168.178.2 die IP des MAX! Cube ist. Das MAXLAN-Modul findet selbstständig bereits gepairte Geräte und trägt diese in die Konfigurationsdatei fhem.cfg ein. Diese können dann im WEB-Interface mittels „alias“ einen eindeutigen Namen bekommen.

=== CUL_MAX ===
Minimale Konfiguration:

<nowiki>define CUL0 CUL /dev/ttyACM0@9600 0000
attr CUL0 rfmode MAX
define cm CUL_MAX 123456</nowiki>

=== Anlernen ===
Dazu muss der "pairmode" auf MAXLAN/CUL_MAX per
:<code>set ml/cm pairmode</code>
oder über das Web-Interface aktiviert werden. Falls kein Parameter angegeben wird, ist er standardmäßig für 60 Sekunden aktiviert. In dieser Zeit können MAX! Geräte nach deren Anleitung in den Anlernmodus versetzt werden, um sie mit FHEM zu pairen.

=== Geräte untereinander anlernen ===
Es gibt einen anderen Befehl, um Devices untereinander anzulernen (in neueren Versionen des MAX Moduls enthalten, heißt "associate").

Wenn man z.B.
:<code>set MAXFensterKontakt0 associate MaxHeizkörperthermostat3</code>
ausführt, dann sendet der MAXFensterKontakt0 jede Änderung zusätzlich (direkt über Funk, ohne Cube oder FHEM) an das MaxHeizkörperthermostat3.

Damit MaxHeizkörperthermostat3 auch auf die Nachrichten vom MAXFensterKontakt0 hört, muss noch ein
set MaxHeizkörperthermostat3 associate MAXFensterKontakt0 erfolgen.

Dann wechselt MaxHeizkörperthermostat3 immer dann auf die windowOpenTemperature, wenn der AXFensterKontakt0 offen ist. Dabei muss die groupId von beiden Geräte gar nicht gleich sein! (Die Semantik der groupId erschließt sich mir deshalb noch nicht ganz. Ich glaube, man kann damit Befehle (ala set desiredTemperature) an mehrere Thermostate gleichzeitig richten. Im Moment sendet FHEM einfach an jedes Thermostat einen Befehl.)

Wahrscheinlich funktioniert associate genauso zwischen Heizkörper/Wandthermostaten. Das müsste mal jemand ausprobieren und dann hier berichten.

=== Temperatursturzerkennung ===
Die Heizkörperthermostate verfügen über eine interne "Fenster-offen Erkennung" (Temperatursturzerkennung). Wird diese ausgelöst, regeln sie für die Zeit die unter "windowOpenDuration" festgelegt wurde auf die als "windowOpenTemperature" festgelegt Temperatur herunter und danach wieder auf die zuvor eingestellte Temperatur zurück.

Nachteil: Die Erkennung benötigt etwas Zeit und reagiert nicht sofort wie es beim Fensterkontakt oben der Fall ist

Vorteil: Es ist kein Fensterkontakt erforderlich

'''Wichtig:''' Setzt man die windowOpenTemperature auf "Off" (= 4.5 Grad), dann ist die Fenster-offen-Funktion abgeschaltet. Und auch wenn die desiredTemperature gerade auf "On" (= 30.5 Grad") steht, geht der Heizkörper nicht in die Fenster-offen-Funktion.

=== Externer Sensor für Fenster-offen-Erkennung ===
'''Achtung''': Wird nur von CUL_MAX unterstützt!

Ziel dieses Abschnittes ist es, einen externen Sensor (z.B. 1-Wire o.ä.) zu benutzen, um die MAX Heizkörperthermostate in und aus dem Fenster-offen Modus zu holen. Dazu sei bereits ein CUL, ein CUL_MAX und ein MAX Heizkörper definiert:

<nowiki>define CUL0 CUL /dev/ttyACM0@9600 0000
define cm CUL_MAX 123456
define Heizung MAX HeatingThermostat abcdef
attr Heizung IODev cm</nowiki>

Wir müssen einmalig den internen Fake-Fensterkontakt mit dem Heizkörper assozieren
:<code>set Heizung associate fakeShutterContact</code>
damit dieser die Nachrichten vom Fensterkontakt akzeptiert.

Nun können wir per
:<code>set cm fakeSC Heizung 1</code>
die Nachricht "Fenster offen" an die Heizung senden und per
:<code>set cm fakeSC Heizung 0</code>
die Nachricht "Fenster zu".

=== Externer Temperatursensor für Heizkörperregelung ===
'''Achtung''': Wird nur von CUL_MAX unterstützt!

Ziel dieses Abschnittes ist es, einen externen Sensor (z.B. 1-Wire o.ä.) zu benutzen, um die MAX Heizkörperthermostate zu regeln. Dazu sei bereits ein CUL, ein CUL_MAX und ein MAX Heizkörper definiert:

<nowiki>define CUL0 CUL /dev/ttyACM0@9600 0000
define cm CUL_MAX 123456
define Heizung MAX HeatingThermostat abcdef
attr Heizung IODev cm</nowiki>

Wir müssen einmalig das interne Fake-Wandthermostat mit dem Heizkörper assozieren:
:<code>set Heizung associate fakeWallThermostat</code>
damit dieser die Nachrichten vom Wandthermostat akzeptiert. Achtung: Dies schaltet im
Heizkörperthermostat die Regelung mit dem internen Temperaturfühler aus. Ohne die gleich kommenden "fakeWT" Nachrichten wird das Heizkörperthermostat nicht mehr regeln.

Nun können wir per
:<code>set cm fakeWT Heizung 14.5 12.1</code>
die desiredTemperature 14.5 und gemessene Temperatur 12.1 an die Heizung senden. Diese wird dann die Ventile öffnen, bis wir ein "fakeWT" absetzten, dessen gemessene Temperatur höher als die desiredTemperature ist.

Falls man zu lange Zeit (ca. 30 Minuten) kein neues "fakeWT" sendet, wird bei der Heizung das Attribut rferror gleich 1. Es ist nicht klar, ob das neben diesem Attribut auch Auswirkung auf die Funktionalität hat. Es wurde beobachtet, dass dann der interne Temperatursensor bis zum nächsten FakeWT aktiviert wird.

Beispiel eines automatischen Sendens einer externen Temperatur, der externe Temperatursensor heißt "WS300":

<nowiki>define SendExtTemp notify WS300:temperature.* {
MaxFakeWallThermostat("Heizung", %EVTPART1);
}</nowiki>

Dazu die Funktion, bitte in 99_MyUtils.pm eintragen:

sub MaxFakeWallThermostat($$)
{
my ($heizung, $aktTemp) = @_;
my $CULMAX = $defs{$heizung}{LASTInputDev};
my $desiredTemp = ReadingsVal($heizung, "desiredTemperature", undef);
my $windowOpenTemp = ReadingsVal($heizung, "windowOpenTemperature", undef);
my $lastTemp = ReadingsVal($heizung, "LastExtTemperature", 0);
my $lastSet = ReadingsTimestamp($heizung, "LastExtTemperature", 0);
if($desiredTemp && $windowOpenTemp &&
$desiredTemp != $windowOpenTemp &&
(time()-time_str2num($lastSet) >= 600 || abs($aktTemp-$lastTemp)>=0.2 )) {
Log 3, "set $CULMAX fakeWT $heizung $desiredTemp $aktTemp";
readingsSingleUpdate($defs{$heizung}, "LastExtTemperature", $aktTemp, 0);
fhem("set $CULMAX fakeWT $heizung $desiredTemp $aktTemp");
}
}

In diesem Beispiel heißt das zu steuernde Thermostat "Heizung". Die vom externen Sensor gemessene Temperatur wird nur unter den folgenden Voraussetzungen gesendet:
* das Thermostat befindet sich nicht im "Fenster-offen" Modus, und
* das letzte Senden liegt mindestens 10min zurück
* oder die gemessene Temperatur weicht um mindestens 0.2°C von der letzten gesendeten Temperatur ab

=== Wochenheizplan für Wandthermostat/Ventilantriebe erstellen ===
Ein Heizplan, den das Wandthermostat und auch der Ventilantrieb versteht und speichern kann, sieht folgendermaßen aus:
:<code>set WZ_Wandthermostat weekProfile Mon 17,17:30,20,23:00,17 Tue 17,17:30,20,23:00,17 Wed 17,17:30,20,23:00,17 Thu 17,17:30,20,23:00,17 Fri 17,15:00,20,23:00,17 Sat 17,11:00,20,23:00,17 Sun 17,11:00,20,23:00,17</code>
Genauer erläutert wird die Funktionsweise auch in der [http://fhem.de/commandref.html#MAX commandref].

Der gesamte Block kann kopiert und als FHEM Befehl abgesetzt werden. Unter Umständen benötigt das Speichern bzw. Übertragen wegen der Größe etwas Zeit, bevor die aktuellen, neu gesetzten Werte wieder ausgelesen werden können.

'''Bitte folgendes beachten:'''

Es gibt im Zusammenhang mit dem Wochenprogramm ein Problem mit dem letzten Schaltpunkt des Tages.
Der Workaround wurde [http://forum.fhem.de/index.php/topic,17231.msg112738.html#msg112738 hier]
beschrieben.
Man muss dafür sorgen, dass man kurz vor Ende des Tages noch einen Schaltpunkt setzt! Bei mir hat sich ein Schaltpunkt (ohne Änderung der Soll-Temperatur) um 23:55 bewährt:
:<code>set WZ_Wandthermostat weekProfile Mon 17,17:30,20,22:00,17,23:55,17</code>

=== Werte Plotten ===
[[File:Plot_MAX_Beispiel.png|thumb|right|Plot eines MAX Heizkörperthermostates]]
In den Log-Dateien wird regelmäßig der Batteriestatus, die Soll-Temperatur, die Ventilstellung und die Ist-Temperatur (Vorsicht: Wird nicht zuverlässig, möglicherweise nur bei einer Änderung der Ventilstellung übertragen.)

Inhalt der LOG-Datei eines Heizkörperthermostates:

<nowiki>2012-12-30_08:55:31 MAX_018d3f battery: ok
2012-12-30_08:55:31 MAX_018d3f desiredTemperature: 19.5
2012-12-30_08:55:31 MAX_018d3f valveposition: 83
2012-12-30_08:55:31 MAX_018d3f temperature: 16.4</nowiki>

Mit folgender Plot-Datei (max_temp.gplot) kann der Verlauf der Sensordaten gut angezeigt werden.

<nowiki>set terminal png transparent size <SIZE> crop
set output '<OUT>.png'
set xdata time
set timefmt "%Y-%m-%d_%H:%M:%S"
set xlabel " "
set y2tics
set title '<L1>'
set grid xtics y2tics
set y2label "Temperatur in Grad Celsius"
set ylabel "Signal in %"
#FileLog 4:desiredTemperature:0:
#FileLog 4:temperature:0:
#FileLog 4:valveposition:0:
plot \
"< egrep 'desiredTemperature' <IN>"\
using 1:4 axes x1y2 title 'Soll-Temperatur (C)' with lines lw 2 \
"< egrep 'temperature' <IN>"\
using 1:4 axes x1y2 title 'Ist-Temperatur(ungenau)(C)' with lines lw 2 \
"< egrep 'valveposition' <IN>"\
using 1:4 axes x1y1 title 'Ventil (%)' with lines lw 2</nowiki>
Einbinden eines Plots in der fhem.cgf

<nowiki>#Werte plotten
define MAX_017840_weblink weblink fileplot FileLog_MAX_017840:max_temp:CURRENT
attr MAX_017840_weblink label "Kueche Soll-Temperatur Min $data{min1}, Max $data{max1}, Last $data{currval1}"
attr MAX_017840_weblink room MAX</nowiki>

=== Nützliche kleine Erweiterungen ===
'''Einen Alias-Namen vergeben für eine bessere Lesbarkeit im Webinterface'''
:<code>attr MAX_018d3f alias Kueche</code>
'''Die Anzeigen für die einzelnen File-Logs füllen das Webinterface schnell und machen es unübersichtlich.''' Die File-Logs können einfach in einen separaten Raum verbannt werden.
:<code>attr FileLog_MAX_018d3f room LOG</code>
'''Einstellmöglichkeit für die Soll-Temperatur direkt in der „Raum-Seite“ schaffen.''' Die Temperatur wird dauerhaft auf einen bestimmten Wert gestellt. Das Wochenprogramm in dem Thermostat wird deaktiviert.
:<code>attr MAX_018d3f webCmd desiredTemperature</code>

'''Soll-Temperatur setzen, ohne das automatische Programm des Thermostates abzuschalten.'''
Es besteht die Möglichkeit eine Soll-Temperatur bis zum nächsten Schaltzeitpunkt zu setzen. Zum Beispiel kann das automatische Wochenprogramm in den Thermostaten dazu genutzt werden, nur abends die Soll-Temperatur zu senken. So läuft die Heizung nachts nicht voll durch. Wenn jedoch die Temperatur im Web-Interface von Fhem verändert wird, wird auch der Thermostat auf manuell gesetzt. So greift das Wochenprogramm nicht mehr. Abhilfe schafft der Befehl
:<code>set MAX_04711 desiredTemperature auto 20</code>
Damit die Eingabe komfortabel aus Fhem möglich ist, kann ein Dummy-Device erstellt werden:

<nowiki>#Dummy für die Schnell-Einstellung der Temperatur bis zum nächsten automatischen Schaltzeitpunkt
define HeizkoerperBad dummy
attr HeizkoerperBad room MAX,Heizungen
attr HeizkoerperBad setList state:eco,auto,14.0,16.0,17.0,18.0,19.0,20.0,21.0,22.0,23.0
attr HeizkoerperBad webCmd state
define HeizkoerperBad.ntfy notify HeizkoerperBad.* {\
my $valtemp = "%";;\
my $device = "MAX_04711";;\
my $cmd = 'set '.$device.' desiredTemperature auto '.$valtemp;;\
fhem($cmd);;\
}</nowiki>
Diese Dummy-Device kann alternativ oder ergänzend zu <code>attr MAX_018d3f webCmd desiredTemperature</code> verwendet werden.

== Internals ==
=== IST-Temperaturwerte ===
[[File:Plot_MAX_Beispiel.png|thumb|right|Plot eines MAX Heizkörperthermostates]]
Diese Abbildung zeigt, dass die IST-Temperatur nicht regelmäßig dem MAX CUBE mitgeteilt wird. Im Automatikbetrieb wird beim einer Änderung der Ventilstellung die neue Ventilstellung zusammen mit der aktuellen IST-Temperatur gesendet. Bei der Abbildung war die Therme in der Nacht ausgeschaltet. Daraufhin sank die Temperatur soweit ab, dass das Heizungsthermostat das Ventil in Maximalstellung geöffnet hat. Gegen 08:50 wurde die Therme eingeschaltet und die Soll-Temperatur an diesem Heizungsthermostat erhöht. Während dieser ganzen Zeit erfolgt keine Aktualisierung der Ist-Temperatur. So kommt es auch gegen 10:30 zu einem sprunghaften Temperaturanstieg von 13,5°C auf 19°C (siehe Markierung *A).

Die IST-Temperatur wird anscheinend aktualisiert bei einer Änderung der:

* Ventilstellung
* Soll-Temperatur
* des Betriebsmodis (Auto/Manuell)

Wer eine detaillierte Kurven wünscht, sollte sich den [[MAX! Temperatur-Scanner]] ansehen.

=== MAXLAN ===
=== CUL_MAX ===
The Max devices use a CC1100 chip. For parameters see rf_moritz.c in culfw.
The thermostats use a Wake-On-Radio, thus one has to send packets at the right time.

CC1100 initialization sequence on one of the max devices (not Cube) (format: addr value, both in hex):

<nowiki>00 08
02 46
04 C6
05 26
0B 06
10 C8 //MDMCFG4 DRATE_E=8
11 93 //MDMCFG3 DRATE_M=147, data rate = (256+DRATE_M)*2^DRATE_E/2^28*f_xosc = (9992.599) 1kbit/s (at f_xosc=26 Mhz)
12 03
15 34
17 00
18 18
19 16
1B 43
21 56
25 00
26 11
0D 21
0E 65
0F 6A
07 4C //PKTCTRL1: ADR_CHK=0 APPEND_STATUS=1 CRC_AUTOFLUSH=1 PQT=2 (preamble must have 8 toggling bits before sync word detection)
16 1C //RXTIME=4
RX_TIME_QUAL=1 (when rx timeout expires, keep receiving if either sync word is found or PQI is set (see PQT))
RX_TIME_RSSI=1 (terminate RX if there is no carrier sense within the first 8 symbol periods)
20 78 //WORCTRL, WOR_RES=00 (1.8-1.9 sec), RC_CAL=1, EVENT1=7 (48 ticks), RC_PD=0
1E 87 //WOREVT1
1F 6B //WOREVT0, i.e. EVENT0 = 34667
29 59
2C 81
2D 35
3E C3</nowiki>
<nowiki>Not set, i.e. factory defaults:
13 MDMCFG1 NUM_PREAMBLE=2 (4 preamble bytes)</nowiki>
From the configuration, we see that the

<nowiki>RC Oscillator: f_xosc/750 = 34666.66 Hz
Event1 = Event1(=48 ticks)/RC Oscillator = 1.385 ms
t_Event0 = 750/26Mhz * EVENT0 * 2^(5*WOR_RES) = 1.00 second
C(RX_TIME, WOR_RES)= 0.2254
rx timeout = EVENT0·C(RX_TIME, WOR_RES) ·26/X(=26) = 34667*0.2254 us = 7.8139 ms</nowiki>

The ShutterContact seems to always sleep. Thus it is necessary to trigger it manually (by opening/closing the window) to make it receive messages. Pushing the button may work to. It is also awake just after
pairing, so one may send messages right then. One can use the WakeUp message to keep it from sleeping for some time. (This is also the reason why in the official MAX software, one must trigger the ShutterContact
after removing it from the house. The "factoryReset" packet is sent directly after the "ShutterContactState" packet has been acked.)

== Probleme und Lösungen ==
=== Der Wandthermostat oder Heizthermostat reagieren nicht auf Änderungen über FHEM ===
Das Autocreate von FHEM erkennt, wenn aktiviert, die Geräte initial und legt auch Einträge an. Es fehlt aber noch das Pairing, da sonst keine Steuerung möglich ist!
Wenn im Log also Meldungen wie

<nowiki>2013.03.20 15:12:30 5: CUL_MAX_SendQueueHandler: 1 items in queue
2013.03.20 15:12:30 5: CUL_MAX_SendQueueHandler: 1 items in queue
2013.03.20 15:12:30 2: CUL_MAX_SendQueueHandler: Missing ack from 01c9bb for 0b05008212345601c9bb0000</nowiki>
auftauchen (im Verbose Modus 5), dann wurde vermutlich kein oder ein inkorrektes Paring durchgeführt.
Nach dem Pairing sollten diese Meldungen verschwinden und stattdessen etwas wie
:<code>2013.03.20 15:21:43 5: Got matching ack</code>
auftauchen.

[[Kategorie:Kontaktsensor (magnetisch)]]
[[Kategorie:MAX]]
[[Kategorie:Heizungsventile]]

MAX

2015-02-11T17:50:03Z

Mahowi: /* Externer Sensor für Fenster-offen-Erkennung */ geht nur mit CUL_MAX

'''MAX!''' ist eine Heizungssteuerung, die die Raumtemperatur durch funkvernetzte Heizkörperthermostate an den Heizkörpern regelt. MAX! stellt eine Alternative zur [[:Kategorie:FHT Components|FHT]] und [[HomeMatic]] Heizungsteuerung dar.

== Features ==
* Bidirektionale Kommuniktion (jeder Befehl wird mit ACK quittiert)
* Heizkörperthermostate übertragen auch die gemessene Temperatur

== FHEM Module ==
Die MAX Komponenten können über den MAX!Cube per Modul 00_MAXLAN oder über einen [[CUL]] oder [[CUNO]] per 14_CUL_MAX gesteuert werden. In beiden Fällen werden die einzelnen MAX! Geräte vom Modul 10_MAX
bereitgestellt.

Nachteil vom Cube ist, dass man ein Polling machen muss, um zu sehen ob sich der Status eines Gerätes geändert hat. Z.B. checkt man das alle 30 Sekunden. Dann sieht man aber auch Änderungen möglicherweise erst nach 30 Sekunden. Beim CUL sieht man die Funknachrichten direkt. Es wird aber auch ein Kombimodus unterstützt, in welchem man alles über den MAXLAN steuert, der CUL_MAX aber für zeitnahe Benachrichtigungen sorgt.

== Komponenten ==
=== Limit ===
* Auf 8 Thermostate pro Raum beschränkt
* Limit mit Cube liegt bei ca. 140 Geräten. Durch die [[1% Regel]] dürften es aber in der Praxis weniger sein

=== Heizkörperthermostate ===
Unterstützt wird das Einstellen von

* desiredTemperature = auto (Wochenprogramm), manuell (4.5 - 30.5), eco, comfort, boost, until
** (Besonderheit der Werte: 4.5 = Off und 30.5 = On)
* ecoTemperature, comfortTemperature, measurementOffset, maximumTemperature, minimumTemperature, windowOpenTemperature, windowOpenDuration

und das Auslesen

* der gemessenen Temperatur. (Hinweis: Wird bei Verwendung des MAX CUBE nicht regelmäßig aktualisiert)

=== Fensterkontakte ===
Der aktuelle Status (offen/geschlossen) wird (praktisch ohne Verzögerung) angezeigt.

Falls wir nicht mit Ack antworten, wird er mehrmals wiederholt.

Die Fensterkontakte können zusätzlich direkt an mehrere Heizkörperthermostate angelernt werden, und versetzen diese dann automatisch in windowOpenTemperature während sie geöffnet sind.

Wenn der Fensterkontakt an mindestens ein Heizkörperthermostat angelernt ist, dann sendet er zusätzlich stündlich seinen aktuellen Zustand.

'''Beispiel Autocreate'''
MAXLAN_Parse: Paired new device, type ShutterContact, addr 1a2b3c, serial JEQ0123456
autocreate: define MAX_1a2b3c MAX ShutterContact 1a2b3c
autocreate: define FileLog_MAX_1a2b3c FileLog /fhem/log/MAX_1a2b3c-%Y.log MAX_1a2b3c

'''Beispiel Definition'''
define MAX_1a2b3c MAX ShutterContact 1a2b3c

'''Beispiel Log'''
==> MAX_1a2b3c-2013.log <==
2013-10-20_18:52:08 MAX_1a2b3c battery: ok
2013-10-20_18:52:08 MAX_1a2b3c onoff: 0
2013-10-20_18:52:08 MAX_1a2b3c closed

=== Wandthermostate ===
Unterstützt wird das Einstellen von

* desiredTemperature (siehe Heizkörperthermostate), ecoTemperature, comfortTemperature

und das Auslesen

* der gemessenen Temperatur.

=== Eco-Taster ===
'''Achtung''': Zumindest über MAXLAN lässt sich der Zustand weder auslesen, noch wird man über Veränderungen informiert.

Per CUL_MAX funktioniert der Eco-Taster problemlos.

==== Beispielhafte Definition ====
:<code>define BUTTON.EG MAX PushButton 069d33</code>

==== Beispielhafte Event-Ausgabe ====

2013-07-02 21:06:14 MAX BUTTON.EG battery: ok
2013-07-02 21:06:14 MAX BUTTON.EG onoff: 0
2013-07-02 21:06:14 MAX BUTTON.EG closed

Wobei gilt
{| class="wikitable"
|-
! onoff !! Bedeutung
|-
| 0 || Eco
|-
| 1 || Auto
|}

== Anlernen per CUL ==
Das Anlernen funktioniert nur mit zurückgesetzen (Werksreset, also entweder alle 3 Tasten am Heizkörperthermostate betätigen, Batterien einlegen, Anzeige rES; oder in FHEM set factoryReset) Heizkörperthermostaten. Bereits an einen Cube angelernte Heizungsregler können '''nicht''' an ein CUL angemeldet werden, hier ist dann nur das "mitlesen" der Funkbotschaften möglich.

Info: Durch den Reset geht auch ein evtl. per Cube eingestelltes Automatikprogramm verloren.

== Konfiguration ==
Siehe [http://fhem.de/commandref.html#CUL_MAX commandref].

Die Module sind so konzipiert, dass man die offizielle Max! Software nicht benutzen muss. Man kann alles aus FHEM heraus machen. Nachdem das MAXLAN oder CUL_MAX Modul konfiguriert wurden (siehe unten), werden bereits gepairte Geräte automatisch erkannt.

=== MAXLAN ===
Minimale Konfiguration:
:<code>define ml MAXLAN 192.168.178.2</code>
wobei 192.168.178.2 die IP des MAX! Cube ist. Das MAXLAN-Modul findet selbstständig bereits gepairte Geräte und trägt diese in die Konfigurationsdatei fhem.cfg ein. Diese können dann im WEB-Interface mittels „alias“ einen eindeutigen Namen bekommen.

=== CUL_MAX ===
Minimale Konfiguration:

<nowiki>define CUL0 CUL /dev/ttyACM0@9600 0000
attr CUL0 rfmode MAX
define cm CUL_MAX 123456</nowiki>

=== Anlernen ===
Dazu muss der "pairmode" auf MAXLAN/CUL_MAX per
:<code>set ml/cm pairmode</code>
oder über das Web-Interface aktiviert werden. Falls kein Parameter angegeben wird, ist er standardmäßig für 60 Sekunden aktiviert. In dieser Zeit können MAX! Geräte nach deren Anleitung in den Anlernmodus versetzt werden, um sie mit FHEM zu pairen.

=== Geräte untereinander anlernen ===
Es gibt einen anderen Befehl, um Devices untereinander anzulernen (in neueren Versionen des MAX Moduls enthalten, heißt "associate").

Wenn man z.B.
:<code>set MAXFensterKontakt0 associate MaxHeizkörperthermostat3</code>
ausführt, dann sendet der MAXFensterKontakt0 jede Änderung zusätzlich (direkt über Funk, ohne Cube oder FHEM) an das MaxHeizkörperthermostat3.

Damit MaxHeizkörperthermostat3 auch auf die Nachrichten vom MAXFensterKontakt0 hört, muss noch ein
set MaxHeizkörperthermostat3 associate MAXFensterKontakt0 erfolgen.

Dann wechselt MaxHeizkörperthermostat3 immer dann auf die windowOpenTemperature, wenn der AXFensterKontakt0 offen ist. Dabei muss die groupId von beiden Geräte gar nicht gleich sein! (Die Semantik der groupId erschließt sich mir deshalb noch nicht ganz. Ich glaube, man kann damit Befehle (ala set desiredTemperature) an mehrere Thermostate gleichzeitig richten. Im Moment sendet FHEM einfach an jedes Thermostat einen Befehl.)

Wahrscheinlich funktioniert associate genauso zwischen Heizkörper/Wandthermostaten. Das müsste mal jemand ausprobieren und dann hier berichten.

=== Temperatursturzerkennung ===
Die Heizkörperthermostate verfügen über eine interne "Fenster-offen Erkennung" (Temperatursturzerkennung). Wird diese ausgelöst, regeln sie für die Zeit die unter "windowOpenDuration" festgelegt wurde auf die als "windowOpenTemperature" festgelegt Temperatur herunter und danach wieder auf die zuvor eingestellte Temperatur zurück.

Nachteil: Die Erkennung benötigt etwas Zeit und reagiert nicht sofort wie es beim Fensterkontakt oben der Fall ist

Vorteil: Es ist kein Fensterkontakt erforderlich

'''Wichtig:''' Setzt man die windowOpenTemperature auf "Off" (= 4.5 Grad), dann ist die Fenster-offen-Funktion abgeschaltet. Und auch wenn die desiredTemperature gerade auf "On" (= 30.5 Grad") steht, geht der Heizkörper nicht in die Fenster-offen-Funktion.

=== Externer Sensor für Fenster-offen-Erkennung ===
'''Achtung''': Wird nur von CUL_MAX unterstützt!

Ziel dieses Abschnittes ist es, einen externen Sensor (z.B. 1-Wire o.ä.) zu benutzen, um die MAX Heizkörperthermostate in und aus dem Fenster-offen Modus zu holen. Dazu sei bereits ein CUL, ein CUL_MAX und ein MAX Heizkörper definiert:

<nowiki>define CUL0 CUL /dev/ttyACM0@9600 0000
define cm CUL_MAX 123456
define Heizung MAX HeatingThermostat abcdef
attr Heizung IODev cm</nowiki>

Wir müssen einmalig den internen Fake-Fensterkontakt mit dem Heizkörper assozieren
:<code>set Heizung associate fakeShutterContact</code>
damit dieser die Nachrichten vom Fensterkontakt akzeptiert.

Nun können wir per
:<code>set cm fakeSC Heizung 1</code>
die Nachricht "Fenster offen" an die Heizung senden und per
:<code>set cm fakeSC Heizung 0</code>
die Nachricht "Fenster zu".

=== Externer Temperatursensor für Heizkörperregelung ===
Ziel dieses Abschnittes ist es, einen externen Sensor (z.B. 1-Wire o.ä.) zu benutzen, um die MAX Heizkörperthermostate zu regeln. Dazu sei bereits ein CUL, ein CUL_MAX und ein MAX Heizkörper definiert:

<nowiki>define CUL0 CUL /dev/ttyACM0@9600 0000
define cm CUL_MAX 123456
define Heizung MAX HeatingThermostat abcdef
attr Heizung IODev cm</nowiki>

Wir müssen einmalig das interne Fake-Wandthermostat mit dem Heizkörper assozieren:
:<code>set Heizung associate fakeWallThermostat</code>
damit dieser die Nachrichten vom Wandthermostat akzeptiert. Achtung: Dies schaltet im
Heizkörperthermostat die Regelung mit dem internen Temperaturfühler aus. Ohne die gleich kommenden "fakeWT" Nachrichten wird das Heizkörperthermostat nicht mehr regeln.

Nun können wir per
:<code>set cm fakeWT Heizung 14.5 12.1</code>
die desiredTemperature 14.5 und gemessene Temperatur 12.1 an die Heizung senden. Diese wird dann die Ventile öffnen, bis wir ein "fakeWT" absetzten, dessen gemessene Temperatur höher als die desiredTemperature ist.

Falls man zu lange Zeit (ca. 30 Minuten) kein neues "fakeWT" sendet, wird bei der Heizung das Attribut rferror gleich 1. Es ist nicht klar, ob das neben diesem Attribut auch Auswirkung auf die Funktionalität hat. Es wurde beobachtet, dass dann der interne Temperatursensor bis zum nächsten FakeWT aktiviert wird.

Beispiel eines automatischen Sendens einer externen Temperatur, der externe Temperatursensor heißt "WS300":

<nowiki>define SendExtTemp notify WS300:temperature.* {
MaxFakeWallThermostat("Heizung", %EVTPART1);
}</nowiki>

Dazu die Funktion, bitte in 99_MyUtils.pm eintragen:

sub MaxFakeWallThermostat($$)
{
my ($heizung, $aktTemp) = @_;
my $CULMAX = $defs{$heizung}{LASTInputDev};
my $desiredTemp = ReadingsVal($heizung, "desiredTemperature", undef);
my $windowOpenTemp = ReadingsVal($heizung, "windowOpenTemperature", undef);
my $lastTemp = ReadingsVal($heizung, "LastExtTemperature", 0);
my $lastSet = ReadingsTimestamp($heizung, "LastExtTemperature", 0);
if($desiredTemp && $windowOpenTemp &&
$desiredTemp != $windowOpenTemp &&
(time()-time_str2num($lastSet) >= 600 || abs($aktTemp-$lastTemp)>=0.2 )) {
Log 3, "set $CULMAX fakeWT $heizung $desiredTemp $aktTemp";
readingsSingleUpdate($defs{$heizung}, "LastExtTemperature", $aktTemp, 0);
fhem("set $CULMAX fakeWT $heizung $desiredTemp $aktTemp");
}
}

In diesem Beispiel heißt das zu steuernde Thermostat "Heizung". Die vom externen Sensor gemessene Temperatur wird nur unter den folgenden Voraussetzungen gesendet:
* das Thermostat befindet sich nicht im "Fenster-offen" Modus, und
* das letzte Senden liegt mindestens 10min zurück
* oder die gemessene Temperatur weicht um mindestens 0.2°C von der letzten gesendeten Temperatur ab

=== Wochenheizplan für Wandthermostat/Ventilantriebe erstellen ===
Ein Heizplan, den das Wandthermostat und auch der Ventilantrieb versteht und speichern kann, sieht folgendermaßen aus:
:<code>set WZ_Wandthermostat weekProfile Mon 17,17:30,20,23:00,17 Tue 17,17:30,20,23:00,17 Wed 17,17:30,20,23:00,17 Thu 17,17:30,20,23:00,17 Fri 17,15:00,20,23:00,17 Sat 17,11:00,20,23:00,17 Sun 17,11:00,20,23:00,17</code>
Genauer erläutert wird die Funktionsweise auch in der [http://fhem.de/commandref.html#MAX commandref].

Der gesamte Block kann kopiert und als FHEM Befehl abgesetzt werden. Unter Umständen benötigt das Speichern bzw. Übertragen wegen der Größe etwas Zeit, bevor die aktuellen, neu gesetzten Werte wieder ausgelesen werden können.

'''Bitte folgendes beachten:'''

Es gibt im Zusammenhang mit dem Wochenprogramm ein Problem mit dem letzten Schaltpunkt des Tages.
Der Workaround wurde [http://forum.fhem.de/index.php/topic,17231.msg112738.html#msg112738 hier]
beschrieben.
Man muss dafür sorgen, dass man kurz vor Ende des Tages noch einen Schaltpunkt setzt! Bei mir hat sich ein Schaltpunkt (ohne Änderung der Soll-Temperatur) um 23:55 bewährt:
:<code>set WZ_Wandthermostat weekProfile Mon 17,17:30,20,22:00,17,23:55,17</code>

=== Werte Plotten ===
[[File:Plot_MAX_Beispiel.png|thumb|right|Plot eines MAX Heizkörperthermostates]]
In den Log-Dateien wird regelmäßig der Batteriestatus, die Soll-Temperatur, die Ventilstellung und die Ist-Temperatur (Vorsicht: Wird nicht zuverlässig, möglicherweise nur bei einer Änderung der Ventilstellung übertragen.)

Inhalt der LOG-Datei eines Heizkörperthermostates:

<nowiki>2012-12-30_08:55:31 MAX_018d3f battery: ok
2012-12-30_08:55:31 MAX_018d3f desiredTemperature: 19.5
2012-12-30_08:55:31 MAX_018d3f valveposition: 83
2012-12-30_08:55:31 MAX_018d3f temperature: 16.4</nowiki>

Mit folgender Plot-Datei (max_temp.gplot) kann der Verlauf der Sensordaten gut angezeigt werden.

<nowiki>set terminal png transparent size <SIZE> crop
set output '<OUT>.png'
set xdata time
set timefmt "%Y-%m-%d_%H:%M:%S"
set xlabel " "
set y2tics
set title '<L1>'
set grid xtics y2tics
set y2label "Temperatur in Grad Celsius"
set ylabel "Signal in %"
#FileLog 4:desiredTemperature:0:
#FileLog 4:temperature:0:
#FileLog 4:valveposition:0:
plot \
"< egrep 'desiredTemperature' <IN>"\
using 1:4 axes x1y2 title 'Soll-Temperatur (C)' with lines lw 2 \
"< egrep 'temperature' <IN>"\
using 1:4 axes x1y2 title 'Ist-Temperatur(ungenau)(C)' with lines lw 2 \
"< egrep 'valveposition' <IN>"\
using 1:4 axes x1y1 title 'Ventil (%)' with lines lw 2</nowiki>
Einbinden eines Plots in der fhem.cgf

<nowiki>#Werte plotten
define MAX_017840_weblink weblink fileplot FileLog_MAX_017840:max_temp:CURRENT
attr MAX_017840_weblink label "Kueche Soll-Temperatur Min $data{min1}, Max $data{max1}, Last $data{currval1}"
attr MAX_017840_weblink room MAX</nowiki>

=== Nützliche kleine Erweiterungen ===
'''Einen Alias-Namen vergeben für eine bessere Lesbarkeit im Webinterface'''
:<code>attr MAX_018d3f alias Kueche</code>
'''Die Anzeigen für die einzelnen File-Logs füllen das Webinterface schnell und machen es unübersichtlich.''' Die File-Logs können einfach in einen separaten Raum verbannt werden.
:<code>attr FileLog_MAX_018d3f room LOG</code>
'''Einstellmöglichkeit für die Soll-Temperatur direkt in der „Raum-Seite“ schaffen.''' Die Temperatur wird dauerhaft auf einen bestimmten Wert gestellt. Das Wochenprogramm in dem Thermostat wird deaktiviert.
:<code>attr MAX_018d3f webCmd desiredTemperature</code>

'''Soll-Temperatur setzen, ohne das automatische Programm des Thermostates abzuschalten.'''
Es besteht die Möglichkeit eine Soll-Temperatur bis zum nächsten Schaltzeitpunkt zu setzen. Zum Beispiel kann das automatische Wochenprogramm in den Thermostaten dazu genutzt werden, nur abends die Soll-Temperatur zu senken. So läuft die Heizung nachts nicht voll durch. Wenn jedoch die Temperatur im Web-Interface von Fhem verändert wird, wird auch der Thermostat auf manuell gesetzt. So greift das Wochenprogramm nicht mehr. Abhilfe schafft der Befehl
:<code>set MAX_04711 desiredTemperature auto 20</code>
Damit die Eingabe komfortabel aus Fhem möglich ist, kann ein Dummy-Device erstellt werden:

<nowiki>#Dummy für die Schnell-Einstellung der Temperatur bis zum nächsten automatischen Schaltzeitpunkt
define HeizkoerperBad dummy
attr HeizkoerperBad room MAX,Heizungen
attr HeizkoerperBad setList state:eco,auto,14.0,16.0,17.0,18.0,19.0,20.0,21.0,22.0,23.0
attr HeizkoerperBad webCmd state
define HeizkoerperBad.ntfy notify HeizkoerperBad.* {\
my $valtemp = "%";;\
my $device = "MAX_04711";;\
my $cmd = 'set '.$device.' desiredTemperature auto '.$valtemp;;\
fhem($cmd);;\
}</nowiki>
Diese Dummy-Device kann alternativ oder ergänzend zu <code>attr MAX_018d3f webCmd desiredTemperature</code> verwendet werden.

== Internals ==
=== IST-Temperaturwerte ===
[[File:Plot_MAX_Beispiel.png|thumb|right|Plot eines MAX Heizkörperthermostates]]
Diese Abbildung zeigt, dass die IST-Temperatur nicht regelmäßig dem MAX CUBE mitgeteilt wird. Im Automatikbetrieb wird beim einer Änderung der Ventilstellung die neue Ventilstellung zusammen mit der aktuellen IST-Temperatur gesendet. Bei der Abbildung war die Therme in der Nacht ausgeschaltet. Daraufhin sank die Temperatur soweit ab, dass das Heizungsthermostat das Ventil in Maximalstellung geöffnet hat. Gegen 08:50 wurde die Therme eingeschaltet und die Soll-Temperatur an diesem Heizungsthermostat erhöht. Während dieser ganzen Zeit erfolgt keine Aktualisierung der Ist-Temperatur. So kommt es auch gegen 10:30 zu einem sprunghaften Temperaturanstieg von 13,5°C auf 19°C (siehe Markierung *A).

Die IST-Temperatur wird anscheinend aktualisiert bei einer Änderung der:

* Ventilstellung
* Soll-Temperatur
* des Betriebsmodis (Auto/Manuell)

Wer eine detaillierte Kurven wünscht, sollte sich den [[MAX! Temperatur-Scanner]] ansehen.

=== MAXLAN ===
=== CUL_MAX ===
The Max devices use a CC1100 chip. For parameters see rf_moritz.c in culfw.
The thermostats use a Wake-On-Radio, thus one has to send packets at the right time.

CC1100 initialization sequence on one of the max devices (not Cube) (format: addr value, both in hex):

<nowiki>00 08
02 46
04 C6
05 26
0B 06
10 C8 //MDMCFG4 DRATE_E=8
11 93 //MDMCFG3 DRATE_M=147, data rate = (256+DRATE_M)*2^DRATE_E/2^28*f_xosc = (9992.599) 1kbit/s (at f_xosc=26 Mhz)
12 03
15 34
17 00
18 18
19 16
1B 43
21 56
25 00
26 11
0D 21
0E 65
0F 6A
07 4C //PKTCTRL1: ADR_CHK=0 APPEND_STATUS=1 CRC_AUTOFLUSH=1 PQT=2 (preamble must have 8 toggling bits before sync word detection)
16 1C //RXTIME=4
RX_TIME_QUAL=1 (when rx timeout expires, keep receiving if either sync word is found or PQI is set (see PQT))
RX_TIME_RSSI=1 (terminate RX if there is no carrier sense within the first 8 symbol periods)
20 78 //WORCTRL, WOR_RES=00 (1.8-1.9 sec), RC_CAL=1, EVENT1=7 (48 ticks), RC_PD=0
1E 87 //WOREVT1
1F 6B //WOREVT0, i.e. EVENT0 = 34667
29 59
2C 81
2D 35
3E C3</nowiki>
<nowiki>Not set, i.e. factory defaults:
13 MDMCFG1 NUM_PREAMBLE=2 (4 preamble bytes)</nowiki>
From the configuration, we see that the

<nowiki>RC Oscillator: f_xosc/750 = 34666.66 Hz
Event1 = Event1(=48 ticks)/RC Oscillator = 1.385 ms
t_Event0 = 750/26Mhz * EVENT0 * 2^(5*WOR_RES) = 1.00 second
C(RX_TIME, WOR_RES)= 0.2254
rx timeout = EVENT0·C(RX_TIME, WOR_RES) ·26/X(=26) = 34667*0.2254 us = 7.8139 ms</nowiki>

The ShutterContact seems to always sleep. Thus it is necessary to trigger it manually (by opening/closing the window) to make it receive messages. Pushing the button may work to. It is also awake just after
pairing, so one may send messages right then. One can use the WakeUp message to keep it from sleeping for some time. (This is also the reason why in the official MAX software, one must trigger the ShutterContact
after removing it from the house. The "factoryReset" packet is sent directly after the "ShutterContactState" packet has been acked.)

== Probleme und Lösungen ==
=== Der Wandthermostat oder Heizthermostat reagieren nicht auf Änderungen über FHEM ===
Das Autocreate von FHEM erkennt, wenn aktiviert, die Geräte initial und legt auch Einträge an. Es fehlt aber noch das Pairing, da sonst keine Steuerung möglich ist!
Wenn im Log also Meldungen wie

<nowiki>2013.03.20 15:12:30 5: CUL_MAX_SendQueueHandler: 1 items in queue
2013.03.20 15:12:30 5: CUL_MAX_SendQueueHandler: 1 items in queue
2013.03.20 15:12:30 2: CUL_MAX_SendQueueHandler: Missing ack from 01c9bb for 0b05008212345601c9bb0000</nowiki>
auftauchen (im Verbose Modus 5), dann wurde vermutlich kein oder ein inkorrektes Paring durchgeführt.
Nach dem Pairing sollten diese Meldungen verschwinden und stattdessen etwas wie
:<code>2013.03.20 15:21:43 5: Got matching ack</code>
auftauchen.

[[Kategorie:Kontaktsensor (magnetisch)]]
[[Kategorie:MAX]]
[[Kategorie:Heizungsventile]]

MAX

2015-02-11T17:44:02Z

Mahowi: Status wird auch bei MAXLAN angezeigt.

'''MAX!''' ist eine Heizungssteuerung, die die Raumtemperatur durch funkvernetzte Heizkörperthermostate an den Heizkörpern regelt. MAX! stellt eine Alternative zur [[:Kategorie:FHT Components|FHT]] und [[HomeMatic]] Heizungsteuerung dar.

== Features ==
* Bidirektionale Kommuniktion (jeder Befehl wird mit ACK quittiert)
* Heizkörperthermostate übertragen auch die gemessene Temperatur

== FHEM Module ==
Die MAX Komponenten können über den MAX!Cube per Modul 00_MAXLAN oder über einen [[CUL]] oder [[CUNO]] per 14_CUL_MAX gesteuert werden. In beiden Fällen werden die einzelnen MAX! Geräte vom Modul 10_MAX
bereitgestellt.

Nachteil vom Cube ist, dass man ein Polling machen muss, um zu sehen ob sich der Status eines Gerätes geändert hat. Z.B. checkt man das alle 30 Sekunden. Dann sieht man aber auch Änderungen möglicherweise erst nach 30 Sekunden. Beim CUL sieht man die Funknachrichten direkt. Es wird aber auch ein Kombimodus unterstützt, in welchem man alles über den MAXLAN steuert, der CUL_MAX aber für zeitnahe Benachrichtigungen sorgt.

== Komponenten ==
=== Limit ===
* Auf 8 Thermostate pro Raum beschränkt
* Limit mit Cube liegt bei ca. 140 Geräten. Durch die [[1% Regel]] dürften es aber in der Praxis weniger sein

=== Heizkörperthermostate ===
Unterstützt wird das Einstellen von

* desiredTemperature = auto (Wochenprogramm), manuell (4.5 - 30.5), eco, comfort, boost, until
** (Besonderheit der Werte: 4.5 = Off und 30.5 = On)
* ecoTemperature, comfortTemperature, measurementOffset, maximumTemperature, minimumTemperature, windowOpenTemperature, windowOpenDuration

und das Auslesen

* der gemessenen Temperatur. (Hinweis: Wird bei Verwendung des MAX CUBE nicht regelmäßig aktualisiert)

=== Fensterkontakte ===
Der aktuelle Status (offen/geschlossen) wird (praktisch ohne Verzögerung) angezeigt.

Falls wir nicht mit Ack antworten, wird er mehrmals wiederholt.

Die Fensterkontakte können zusätzlich direkt an mehrere Heizkörperthermostate angelernt werden, und versetzen diese dann automatisch in windowOpenTemperature während sie geöffnet sind.

Wenn der Fensterkontakt an mindestens ein Heizkörperthermostat angelernt ist, dann sendet er zusätzlich stündlich seinen aktuellen Zustand.

'''Beispiel Autocreate'''
MAXLAN_Parse: Paired new device, type ShutterContact, addr 1a2b3c, serial JEQ0123456
autocreate: define MAX_1a2b3c MAX ShutterContact 1a2b3c
autocreate: define FileLog_MAX_1a2b3c FileLog /fhem/log/MAX_1a2b3c-%Y.log MAX_1a2b3c

'''Beispiel Definition'''
define MAX_1a2b3c MAX ShutterContact 1a2b3c

'''Beispiel Log'''
==> MAX_1a2b3c-2013.log <==
2013-10-20_18:52:08 MAX_1a2b3c battery: ok
2013-10-20_18:52:08 MAX_1a2b3c onoff: 0
2013-10-20_18:52:08 MAX_1a2b3c closed

=== Wandthermostate ===
Unterstützt wird das Einstellen von

* desiredTemperature (siehe Heizkörperthermostate), ecoTemperature, comfortTemperature

und das Auslesen

* der gemessenen Temperatur.

=== Eco-Taster ===
'''Achtung''': Zumindest über MAXLAN lässt sich der Zustand weder auslesen, noch wird man über Veränderungen informiert.

Per CUL_MAX funktioniert der Eco-Taster problemlos.

==== Beispielhafte Definition ====
:<code>define BUTTON.EG MAX PushButton 069d33</code>

==== Beispielhafte Event-Ausgabe ====

2013-07-02 21:06:14 MAX BUTTON.EG battery: ok
2013-07-02 21:06:14 MAX BUTTON.EG onoff: 0
2013-07-02 21:06:14 MAX BUTTON.EG closed

Wobei gilt
{| class="wikitable"
|-
! onoff !! Bedeutung
|-
| 0 || Eco
|-
| 1 || Auto
|}

== Anlernen per CUL ==
Das Anlernen funktioniert nur mit zurückgesetzen (Werksreset, also entweder alle 3 Tasten am Heizkörperthermostate betätigen, Batterien einlegen, Anzeige rES; oder in FHEM set factoryReset) Heizkörperthermostaten. Bereits an einen Cube angelernte Heizungsregler können '''nicht''' an ein CUL angemeldet werden, hier ist dann nur das "mitlesen" der Funkbotschaften möglich.

Info: Durch den Reset geht auch ein evtl. per Cube eingestelltes Automatikprogramm verloren.

== Konfiguration ==
Siehe [http://fhem.de/commandref.html#CUL_MAX commandref].

Die Module sind so konzipiert, dass man die offizielle Max! Software nicht benutzen muss. Man kann alles aus FHEM heraus machen. Nachdem das MAXLAN oder CUL_MAX Modul konfiguriert wurden (siehe unten), werden bereits gepairte Geräte automatisch erkannt.

=== MAXLAN ===
Minimale Konfiguration:
:<code>define ml MAXLAN 192.168.178.2</code>
wobei 192.168.178.2 die IP des MAX! Cube ist. Das MAXLAN-Modul findet selbstständig bereits gepairte Geräte und trägt diese in die Konfigurationsdatei fhem.cfg ein. Diese können dann im WEB-Interface mittels „alias“ einen eindeutigen Namen bekommen.

=== CUL_MAX ===
Minimale Konfiguration:

<nowiki>define CUL0 CUL /dev/ttyACM0@9600 0000
attr CUL0 rfmode MAX
define cm CUL_MAX 123456</nowiki>

=== Anlernen ===
Dazu muss der "pairmode" auf MAXLAN/CUL_MAX per
:<code>set ml/cm pairmode</code>
oder über das Web-Interface aktiviert werden. Falls kein Parameter angegeben wird, ist er standardmäßig für 60 Sekunden aktiviert. In dieser Zeit können MAX! Geräte nach deren Anleitung in den Anlernmodus versetzt werden, um sie mit FHEM zu pairen.

=== Geräte untereinander anlernen ===
Es gibt einen anderen Befehl, um Devices untereinander anzulernen (in neueren Versionen des MAX Moduls enthalten, heißt "associate").

Wenn man z.B.
:<code>set MAXFensterKontakt0 associate MaxHeizkörperthermostat3</code>
ausführt, dann sendet der MAXFensterKontakt0 jede Änderung zusätzlich (direkt über Funk, ohne Cube oder FHEM) an das MaxHeizkörperthermostat3.

Damit MaxHeizkörperthermostat3 auch auf die Nachrichten vom MAXFensterKontakt0 hört, muss noch ein
set MaxHeizkörperthermostat3 associate MAXFensterKontakt0 erfolgen.

Dann wechselt MaxHeizkörperthermostat3 immer dann auf die windowOpenTemperature, wenn der AXFensterKontakt0 offen ist. Dabei muss die groupId von beiden Geräte gar nicht gleich sein! (Die Semantik der groupId erschließt sich mir deshalb noch nicht ganz. Ich glaube, man kann damit Befehle (ala set desiredTemperature) an mehrere Thermostate gleichzeitig richten. Im Moment sendet FHEM einfach an jedes Thermostat einen Befehl.)

Wahrscheinlich funktioniert associate genauso zwischen Heizkörper/Wandthermostaten. Das müsste mal jemand ausprobieren und dann hier berichten.

=== Temperatursturzerkennung ===
Die Heizkörperthermostate verfügen über eine interne "Fenster-offen Erkennung" (Temperatursturzerkennung). Wird diese ausgelöst, regeln sie für die Zeit die unter "windowOpenDuration" festgelegt wurde auf die als "windowOpenTemperature" festgelegt Temperatur herunter und danach wieder auf die zuvor eingestellte Temperatur zurück.

Nachteil: Die Erkennung benötigt etwas Zeit und reagiert nicht sofort wie es beim Fensterkontakt oben der Fall ist

Vorteil: Es ist kein Fensterkontakt erforderlich

'''Wichtig:''' Setzt man die windowOpenTemperature auf "Off" (= 4.5 Grad), dann ist die Fenster-offen-Funktion abgeschaltet. Und auch wenn die desiredTemperature gerade auf "On" (= 30.5 Grad") steht, geht der Heizkörper nicht in die Fenster-offen-Funktion.

=== Externer Sensor für Fenster-offen-Erkennung ===
Ziel dieses Abschnittes ist es, einen externen Sensor (z.B. 1-Wire o.ä.) zu benutzen, um die MAX Heizkörperthermostate in und aus dem Fenster-offen Modus zu holen. Dazu sei bereits ein CUL, ein CUL_MAX und ein MAX Heizkörper definiert:

<nowiki>define CUL0 CUL /dev/ttyACM0@9600 0000
define cm CUL_MAX 123456
define Heizung MAX HeatingThermostat abcdef
attr Heizung IODev cm</nowiki>

Wir müssen einmalig den internen Fake-Fensterkontakt mit dem Heizkörper assozieren
:<code>set Heizung associate fakeShutterContact</code>
damit dieser die Nachrichten vom Fensterkontakt akzeptiert.

Nun können wir per
:<code>set cm fakeSC Heizung 1</code>
die Nachricht "Fenster offen" an die Heizung senden und per
:<code>set cm fakeSC Heizung 0</code>
die Nachricht "Fenster zu".

=== Externer Temperatursensor für Heizkörperregelung ===
Ziel dieses Abschnittes ist es, einen externen Sensor (z.B. 1-Wire o.ä.) zu benutzen, um die MAX Heizkörperthermostate zu regeln. Dazu sei bereits ein CUL, ein CUL_MAX und ein MAX Heizkörper definiert:

<nowiki>define CUL0 CUL /dev/ttyACM0@9600 0000
define cm CUL_MAX 123456
define Heizung MAX HeatingThermostat abcdef
attr Heizung IODev cm</nowiki>

Wir müssen einmalig das interne Fake-Wandthermostat mit dem Heizkörper assozieren:
:<code>set Heizung associate fakeWallThermostat</code>
damit dieser die Nachrichten vom Wandthermostat akzeptiert. Achtung: Dies schaltet im
Heizkörperthermostat die Regelung mit dem internen Temperaturfühler aus. Ohne die gleich kommenden "fakeWT" Nachrichten wird das Heizkörperthermostat nicht mehr regeln.

Nun können wir per
:<code>set cm fakeWT Heizung 14.5 12.1</code>
die desiredTemperature 14.5 und gemessene Temperatur 12.1 an die Heizung senden. Diese wird dann die Ventile öffnen, bis wir ein "fakeWT" absetzten, dessen gemessene Temperatur höher als die desiredTemperature ist.

Falls man zu lange Zeit (ca. 30 Minuten) kein neues "fakeWT" sendet, wird bei der Heizung das Attribut rferror gleich 1. Es ist nicht klar, ob das neben diesem Attribut auch Auswirkung auf die Funktionalität hat. Es wurde beobachtet, dass dann der interne Temperatursensor bis zum nächsten FakeWT aktiviert wird.

Beispiel eines automatischen Sendens einer externen Temperatur, der externe Temperatursensor heißt "WS300":

<nowiki>define SendExtTemp notify WS300:temperature.* {
MaxFakeWallThermostat("Heizung", %EVTPART1);
}</nowiki>

Dazu die Funktion, bitte in 99_MyUtils.pm eintragen:

sub MaxFakeWallThermostat($$)
{
my ($heizung, $aktTemp) = @_;
my $CULMAX = $defs{$heizung}{LASTInputDev};
my $desiredTemp = ReadingsVal($heizung, "desiredTemperature", undef);
my $windowOpenTemp = ReadingsVal($heizung, "windowOpenTemperature", undef);
my $lastTemp = ReadingsVal($heizung, "LastExtTemperature", 0);
my $lastSet = ReadingsTimestamp($heizung, "LastExtTemperature", 0);
if($desiredTemp && $windowOpenTemp &&
$desiredTemp != $windowOpenTemp &&
(time()-time_str2num($lastSet) >= 600 || abs($aktTemp-$lastTemp)>=0.2 )) {
Log 3, "set $CULMAX fakeWT $heizung $desiredTemp $aktTemp";
readingsSingleUpdate($defs{$heizung}, "LastExtTemperature", $aktTemp, 0);
fhem("set $CULMAX fakeWT $heizung $desiredTemp $aktTemp");
}
}

In diesem Beispiel heißt das zu steuernde Thermostat "Heizung". Die vom externen Sensor gemessene Temperatur wird nur unter den folgenden Voraussetzungen gesendet:
* das Thermostat befindet sich nicht im "Fenster-offen" Modus, und
* das letzte Senden liegt mindestens 10min zurück
* oder die gemessene Temperatur weicht um mindestens 0.2°C von der letzten gesendeten Temperatur ab

=== Wochenheizplan für Wandthermostat/Ventilantriebe erstellen ===
Ein Heizplan, den das Wandthermostat und auch der Ventilantrieb versteht und speichern kann, sieht folgendermaßen aus:
:<code>set WZ_Wandthermostat weekProfile Mon 17,17:30,20,23:00,17 Tue 17,17:30,20,23:00,17 Wed 17,17:30,20,23:00,17 Thu 17,17:30,20,23:00,17 Fri 17,15:00,20,23:00,17 Sat 17,11:00,20,23:00,17 Sun 17,11:00,20,23:00,17</code>
Genauer erläutert wird die Funktionsweise auch in der [http://fhem.de/commandref.html#MAX commandref].

Der gesamte Block kann kopiert und als FHEM Befehl abgesetzt werden. Unter Umständen benötigt das Speichern bzw. Übertragen wegen der Größe etwas Zeit, bevor die aktuellen, neu gesetzten Werte wieder ausgelesen werden können.

'''Bitte folgendes beachten:'''

Es gibt im Zusammenhang mit dem Wochenprogramm ein Problem mit dem letzten Schaltpunkt des Tages.
Der Workaround wurde [http://forum.fhem.de/index.php/topic,17231.msg112738.html#msg112738 hier]
beschrieben.
Man muss dafür sorgen, dass man kurz vor Ende des Tages noch einen Schaltpunkt setzt! Bei mir hat sich ein Schaltpunkt (ohne Änderung der Soll-Temperatur) um 23:55 bewährt:
:<code>set WZ_Wandthermostat weekProfile Mon 17,17:30,20,22:00,17,23:55,17</code>

=== Werte Plotten ===
[[File:Plot_MAX_Beispiel.png|thumb|right|Plot eines MAX Heizkörperthermostates]]
In den Log-Dateien wird regelmäßig der Batteriestatus, die Soll-Temperatur, die Ventilstellung und die Ist-Temperatur (Vorsicht: Wird nicht zuverlässig, möglicherweise nur bei einer Änderung der Ventilstellung übertragen.)

Inhalt der LOG-Datei eines Heizkörperthermostates:

<nowiki>2012-12-30_08:55:31 MAX_018d3f battery: ok
2012-12-30_08:55:31 MAX_018d3f desiredTemperature: 19.5
2012-12-30_08:55:31 MAX_018d3f valveposition: 83
2012-12-30_08:55:31 MAX_018d3f temperature: 16.4</nowiki>

Mit folgender Plot-Datei (max_temp.gplot) kann der Verlauf der Sensordaten gut angezeigt werden.

<nowiki>set terminal png transparent size <SIZE> crop
set output '<OUT>.png'
set xdata time
set timefmt "%Y-%m-%d_%H:%M:%S"
set xlabel " "
set y2tics
set title '<L1>'
set grid xtics y2tics
set y2label "Temperatur in Grad Celsius"
set ylabel "Signal in %"
#FileLog 4:desiredTemperature:0:
#FileLog 4:temperature:0:
#FileLog 4:valveposition:0:
plot \
"< egrep 'desiredTemperature' <IN>"\
using 1:4 axes x1y2 title 'Soll-Temperatur (C)' with lines lw 2 \
"< egrep 'temperature' <IN>"\
using 1:4 axes x1y2 title 'Ist-Temperatur(ungenau)(C)' with lines lw 2 \
"< egrep 'valveposition' <IN>"\
using 1:4 axes x1y1 title 'Ventil (%)' with lines lw 2</nowiki>
Einbinden eines Plots in der fhem.cgf

<nowiki>#Werte plotten
define MAX_017840_weblink weblink fileplot FileLog_MAX_017840:max_temp:CURRENT
attr MAX_017840_weblink label "Kueche Soll-Temperatur Min $data{min1}, Max $data{max1}, Last $data{currval1}"
attr MAX_017840_weblink room MAX</nowiki>

=== Nützliche kleine Erweiterungen ===
'''Einen Alias-Namen vergeben für eine bessere Lesbarkeit im Webinterface'''
:<code>attr MAX_018d3f alias Kueche</code>
'''Die Anzeigen für die einzelnen File-Logs füllen das Webinterface schnell und machen es unübersichtlich.''' Die File-Logs können einfach in einen separaten Raum verbannt werden.
:<code>attr FileLog_MAX_018d3f room LOG</code>
'''Einstellmöglichkeit für die Soll-Temperatur direkt in der „Raum-Seite“ schaffen.''' Die Temperatur wird dauerhaft auf einen bestimmten Wert gestellt. Das Wochenprogramm in dem Thermostat wird deaktiviert.
:<code>attr MAX_018d3f webCmd desiredTemperature</code>

'''Soll-Temperatur setzen, ohne das automatische Programm des Thermostates abzuschalten.'''
Es besteht die Möglichkeit eine Soll-Temperatur bis zum nächsten Schaltzeitpunkt zu setzen. Zum Beispiel kann das automatische Wochenprogramm in den Thermostaten dazu genutzt werden, nur abends die Soll-Temperatur zu senken. So läuft die Heizung nachts nicht voll durch. Wenn jedoch die Temperatur im Web-Interface von Fhem verändert wird, wird auch der Thermostat auf manuell gesetzt. So greift das Wochenprogramm nicht mehr. Abhilfe schafft der Befehl
:<code>set MAX_04711 desiredTemperature auto 20</code>
Damit die Eingabe komfortabel aus Fhem möglich ist, kann ein Dummy-Device erstellt werden:

<nowiki>#Dummy für die Schnell-Einstellung der Temperatur bis zum nächsten automatischen Schaltzeitpunkt
define HeizkoerperBad dummy
attr HeizkoerperBad room MAX,Heizungen
attr HeizkoerperBad setList state:eco,auto,14.0,16.0,17.0,18.0,19.0,20.0,21.0,22.0,23.0
attr HeizkoerperBad webCmd state
define HeizkoerperBad.ntfy notify HeizkoerperBad.* {\
my $valtemp = "%";;\
my $device = "MAX_04711";;\
my $cmd = 'set '.$device.' desiredTemperature auto '.$valtemp;;\
fhem($cmd);;\
}</nowiki>
Diese Dummy-Device kann alternativ oder ergänzend zu <code>attr MAX_018d3f webCmd desiredTemperature</code> verwendet werden.

== Internals ==
=== IST-Temperaturwerte ===
[[File:Plot_MAX_Beispiel.png|thumb|right|Plot eines MAX Heizkörperthermostates]]
Diese Abbildung zeigt, dass die IST-Temperatur nicht regelmäßig dem MAX CUBE mitgeteilt wird. Im Automatikbetrieb wird beim einer Änderung der Ventilstellung die neue Ventilstellung zusammen mit der aktuellen IST-Temperatur gesendet. Bei der Abbildung war die Therme in der Nacht ausgeschaltet. Daraufhin sank die Temperatur soweit ab, dass das Heizungsthermostat das Ventil in Maximalstellung geöffnet hat. Gegen 08:50 wurde die Therme eingeschaltet und die Soll-Temperatur an diesem Heizungsthermostat erhöht. Während dieser ganzen Zeit erfolgt keine Aktualisierung der Ist-Temperatur. So kommt es auch gegen 10:30 zu einem sprunghaften Temperaturanstieg von 13,5°C auf 19°C (siehe Markierung *A).

Die IST-Temperatur wird anscheinend aktualisiert bei einer Änderung der:

* Ventilstellung
* Soll-Temperatur
* des Betriebsmodis (Auto/Manuell)

Wer eine detaillierte Kurven wünscht, sollte sich den [[MAX! Temperatur-Scanner]] ansehen.

=== MAXLAN ===
=== CUL_MAX ===
The Max devices use a CC1100 chip. For parameters see rf_moritz.c in culfw.
The thermostats use a Wake-On-Radio, thus one has to send packets at the right time.

CC1100 initialization sequence on one of the max devices (not Cube) (format: addr value, both in hex):

<nowiki>00 08
02 46
04 C6
05 26
0B 06
10 C8 //MDMCFG4 DRATE_E=8
11 93 //MDMCFG3 DRATE_M=147, data rate = (256+DRATE_M)*2^DRATE_E/2^28*f_xosc = (9992.599) 1kbit/s (at f_xosc=26 Mhz)
12 03
15 34
17 00
18 18
19 16
1B 43
21 56
25 00
26 11
0D 21
0E 65
0F 6A
07 4C //PKTCTRL1: ADR_CHK=0 APPEND_STATUS=1 CRC_AUTOFLUSH=1 PQT=2 (preamble must have 8 toggling bits before sync word detection)
16 1C //RXTIME=4
RX_TIME_QUAL=1 (when rx timeout expires, keep receiving if either sync word is found or PQI is set (see PQT))
RX_TIME_RSSI=1 (terminate RX if there is no carrier sense within the first 8 symbol periods)
20 78 //WORCTRL, WOR_RES=00 (1.8-1.9 sec), RC_CAL=1, EVENT1=7 (48 ticks), RC_PD=0
1E 87 //WOREVT1
1F 6B //WOREVT0, i.e. EVENT0 = 34667
29 59
2C 81
2D 35
3E C3</nowiki>
<nowiki>Not set, i.e. factory defaults:
13 MDMCFG1 NUM_PREAMBLE=2 (4 preamble bytes)</nowiki>
From the configuration, we see that the

<nowiki>RC Oscillator: f_xosc/750 = 34666.66 Hz
Event1 = Event1(=48 ticks)/RC Oscillator = 1.385 ms
t_Event0 = 750/26Mhz * EVENT0 * 2^(5*WOR_RES) = 1.00 second
C(RX_TIME, WOR_RES)= 0.2254
rx timeout = EVENT0·C(RX_TIME, WOR_RES) ·26/X(=26) = 34667*0.2254 us = 7.8139 ms</nowiki>

The ShutterContact seems to always sleep. Thus it is necessary to trigger it manually (by opening/closing the window) to make it receive messages. Pushing the button may work to. It is also awake just after
pairing, so one may send messages right then. One can use the WakeUp message to keep it from sleeping for some time. (This is also the reason why in the official MAX software, one must trigger the ShutterContact
after removing it from the house. The "factoryReset" packet is sent directly after the "ShutterContactState" packet has been acked.)

== Probleme und Lösungen ==
=== Der Wandthermostat oder Heizthermostat reagieren nicht auf Änderungen über FHEM ===
Das Autocreate von FHEM erkennt, wenn aktiviert, die Geräte initial und legt auch Einträge an. Es fehlt aber noch das Pairing, da sonst keine Steuerung möglich ist!
Wenn im Log also Meldungen wie

<nowiki>2013.03.20 15:12:30 5: CUL_MAX_SendQueueHandler: 1 items in queue
2013.03.20 15:12:30 5: CUL_MAX_SendQueueHandler: 1 items in queue
2013.03.20 15:12:30 2: CUL_MAX_SendQueueHandler: Missing ack from 01c9bb for 0b05008212345601c9bb0000</nowiki>
auftauchen (im Verbose Modus 5), dann wurde vermutlich kein oder ein inkorrektes Paring durchgeführt.
Nach dem Pairing sollten diese Meldungen verschwinden und stattdessen etwas wie
:<code>2013.03.20 15:21:43 5: Got matching ack</code>
auftauchen.

[[Kategorie:Kontaktsensor (magnetisch)]]
[[Kategorie:MAX]]
[[Kategorie:Heizungsventile]]