FHEMWiki - Benutzerbeiträge [de]

Wallboxen Übersicht

2023-12-09T15:19:35Z

Sledge:

Diese Seite dient der übersichtlichen Darstellung verschiedener Wallboxen.

{| class="wikitable" style="margin:auto"
|-
!rowspan="2"|Hersteller!!rowspan="2"|Typ!!rowspan="2"|Preis in € ca.!!colspan="2"|Ladeleistung kW!!rowspan="2"|FI DC!!rowspan="2"|Zähler!!rowspan="2"|Kabel o. Dose!!rowspan="2"|Netzwerk!!rowspan="2"|Anbindung FHEM!!rowspan="2"|Betrieb!!rowspan="2"|Zugang Kontrolle!!rowspan="2"|Datum
|-
!1-phasig!!3-phasig
|-
|E.ON || Drive vBox smart 11|| 490,00 ||3,7 ||1,4-11||ja ||nein ||opt. Kabel 4,5m||WLAN und LAN, opt. RS485||Modbus TCP ||max 55°C||RFID ||Dez. 2023
|-
|Fronius || Wattpilot Home 11J || 770,00 ||3,68||11 ||ja ||nein ||Dose ||WLAN || ||max 40°C|| App||Dez. 2023
|-
|go-e || eCharger Gemini || 550,00 || ||11 ||ja ||ja ||Dose || WLAN ||REST, MQTT, Modbus TCP, Modul 46_GoECharger.pm ||max. 40°C||RFID,App||Dez. 2023
|-
|Hardy Barth||eCHARGE cPµ2 PRO || 750,00 || ||1,4-11||ja ||MID extern||Kabel 5m || || || || ||Dez. 2023
|-
|rowspan="2"|Elli = VW || ID.Charger Connect|| 800,00 ||rowspan="2"|7,4 ||rowspan="2"|11 ||rowspan="2"|ja ||nein ||rowspan="2"|Kabel ab 4,5m ||rowspan="2"|WLAN, LAN, LTE, opt. RS485 ||rowspan="2"|Software evcc bildet EEBUS auf MQTT ab. EEBUS-Interface für FHEM wäre wünschenswert ||rowspan="2"|max. 40°C||rowspan="2"|RFID,App||rowspan="2"|Dez. 2023
|-
|ID.Charger Pro || 1050,00 ||ja MID
|-
|KEBA ||KeContact P30 a-series|| 200,00 || ||1,4-11||ja ||nein ||Kabel 4m ||LAN ||Modbus TCP || || ||Dez. 2023
|-
|rowspan="2"|OpenWB ||OpenWB series2 Standard || 1100,00 ||rowspan="2"| 7,4|| rowspan="2" |11 oder 22||rowspan="2"|ja || ja|| rowspan="2" |Kabel ab 3m, optional mit Buchse (custom) || rowspan="2" |LAN ||rowspan="2"|REST, MQTT, Modbus via Adapter||rowspan="2"|max 45°C || RFID (opt)
PIN (opt, bei display)
| rowspan="2" |Dez. 2023
|-
|OpenWB PRO || 2100,00
|-
|Vestel || EVC04-E11-W-C || colspan="11" |Baugleich mit E.ON Drive vBox smart 11
|-
|Wallbox || Pulsar Plus || 700,00 || ||11 ||ja ||ja, nicht MID|| || WLAN, Bluetooth|| || ||RFID, App ||Dez.2023
|-
| || || || || || || || || || ||

|}

[[Kategorie:Wallboxen]]
[[Kategorie:FHEM]]

Wallboxen Übersicht

2023-12-09T15:08:40Z

Sledge: Ergänzung openWB

Diese Seite dient der übersichtlichen Darstellung verschiedener Wallboxen.

{| class="wikitable" style="margin:auto"
|-
!rowspan="2"|Hersteller!!rowspan="2"|Typ!!rowspan="2"|Preis in € ca.!!colspan="2"|Ladeleistung kW!!rowspan="2"|FI DC!!rowspan="2"|Zähler!!rowspan="2"|Kabel o. Dose!!rowspan="2"|Netzwerk!!rowspan="2"|Anbindung FHEM!!rowspan="2"|Betrieb!!rowspan="2"|Zugang Kontrolle!!rowspan="2"|Datum
|-
!1-phasig!!3-phasig
|-
|E.ON || Drive vBox smart 11|| 490,00 ||3,7 ||1,4-11||ja ||nein ||opt. Kabel 4,5m||WLAN und LAN, opt. RS485||Modbus TCP ||max 55°C||RFID ||Dez. 2023
|-
|Fronius || Wattpilot Home 11J || 770,00 ||3,68||11 ||ja ||nein ||Dose ||WLAN || ||max 40°C|| App||Dez. 2023
|-
|go-e || eCharger Gemini || 550,00 || ||11 ||ja ||ja ||Dose || WLAN ||REST, MQTT, Modbus TCP, Modul 46_GoECharger.pm ||max. 40°C||RFID,App||Dez. 2023
|-
|Hardy Barth||eCHARGE cPµ2 PRO || 750,00 || ||1,4-11||ja ||MID extern||Kabel 5m || || || || ||Dez. 2023
|-
|rowspan="2"|Elli = VW || ID.Charger Connect|| 800,00 ||rowspan="2"|7,4 ||rowspan="2"|11 ||rowspan="2"|ja ||nein ||rowspan="2"|Kabel ab 4,5m ||rowspan="2"|WLAN, LAN, LTE, opt. RS485 ||rowspan="2"|Software evcc bildet EEBUS auf MQTT ab. EEBUS-Interface für FHEM wäre wünschenswert ||rowspan="2"|max. 40°C||rowspan="2"|RFID,App||rowspan="2"|Dez. 2023
|-
|ID.Charger Pro || 1050,00 ||ja MID
|-
|KEBA ||KeContact P30 a-series|| 200,00 || ||1,4-11||ja ||nein ||Kabel 4m ||LAN ||Modbus TCP || || ||Dez. 2023
|-
|rowspan="2"|OpenWB ||OpenWB series2 Standard || 1100,00 ||rowspan="2"| 7,4|| rowspan="2" |11 oder 22||rowspan="2"|ja || ja|| rowspan="2" |Kabel ab 3m ||rowspan="2"|LAN ||rowspan="2"|REST, MQTT, Modbus via Adapter||rowspan="2"|max 45°C || RFID (opt)|| rowspan="2" |Dez. 2023
|-
|OpenWB PRO || 2100,00
|-
|Vestel || EVC04-E11-W-C || colspan="11" |Baugleich mit E.ON Drive vBox smart 11
|-
|Wallbox || Pulsar Plus || 700,00 || ||11 ||ja ||ja, nicht MID|| || WLAN, Bluetooth|| || ||RFID, App ||Dez.2023
|-
| || || || || || || || || || ||

|}

[[Kategorie:Wallboxen]]
[[Kategorie:FHEM]]

DevStateIcon

2019-10-17T18:32:58Z

Sledge:

{{SEITENTITEL:devStateIcon}} 


Das Attribut [[devStateIcon]] dient dazu, das anzuzeigende Icon eines Devices in Abhängigkeit vom Device-Status (STATE) in der Raumübersicht (room) festzulegen. Zudem kann man einstellen, was bei einem Klick auf das Icon geschieht.

== Syntax ==
Das ''devStateIcon'' Attribut kann in 2 verschiedenen Formen spezifiziert werden, die in der {{Link2CmdRef|Anker=devStateIcon}} sowie in [[DeviceOverview anpassen#devStateIcon|deviceOverview]] detaillierter beschrieben werden.

Seit FHEM Version 2019-02-20 gibt es die Möglichkeit mehr als ein Icon pro Device darzustellen: Sobald STATE mehrzeilig ist wird für jede Zeile ein Icon erzeugt und alle Icons nebeneinander
dargestellt. Mehrere Zeilen für STATE lassen sich über ein entsprechend gesetztes stateFormat Attribut erreichen. Ein Zeilenumbruch zwischen diesen Icons lässt sich mit erzeugen.

Ein Beispiel findet sich in {{Link2Forum|Topic=97586|LinkText=diesem Forenthread}} zur Entstehung des Features.

[[Datei:stateFormat-1.png|600px]]

== Einschränkungen ==
In ''devStateIcon'' dürfen keine Leerzeichen oder Klammern vorkommen (ausser zur Trennung der unterschiedlichen Zustände).

In den Zuständen können Leerzeichen und Klammern durch einen . (Punkt) ersetzt werden.

So müsste z.B. (siehe auch {{Link2Forum|Topic=42351|LinkText=dieses Forenthema}}
:<code>devStateIcon on-old-for-timer 60:weather_rain_heavy@red:off off:weather_sun@yellow:on-old-for-timer 60</code>
geändert werden auf
:<code>devStateIcon on-old-for-timer.60:weather_rain_heavy@red:off off:weather_sun@yellow:on-old-60</code>
wobei in diesem Beispiel zusätzlich der Befehlsteil des '''off''' mit der Attributdefinition
:<code>[[eventMap]] /on-old-for-timer 60:on-old-60/</code>
auf eine "leerzeichenlose" Version umdefiniert werden muss.

== Beispiele ==
* [[EnOcean-FSB61-Aktor-Beschattungselemente-Rollladen#Anzeige Rollladenstand im WebFrontend|Anzeige Rollladenstand im WebFrontend]]
* [[EnOcean-STM-250-Fenster-T%C3%BCrkontakt#Anzeige Türstatus im WebFrontend|Anzeige Türstatus im WebFrontend]]
* [[Color#Farbige_Lampen_Icons|Farbige Lampen Icons]]
* [[Icons]]

== Links ==
* Ausführliche Beschreibung (mit Beispielen) zu [[eventMap]], devStateIcon, [[setList]] und [[webCmd]] in {{Link2Forum|Topic=12080|LinkText=diesem Forenthread}} oder in [[DeviceOverview anpassen]]
* Beispiel für FS20 {{Link2Forum|Topic=26521|Message=197326}}

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

FHEM Connector für Amazon Alexa

2019-10-14T08:52:58Z

Sledge:

{{Baustelle}}
'''Alexa FHEMlazy''' war historisch ein Fork des Original [[Alexa-Fhem|alexa-fhem]], der im Januar 2019 mit dem Original zusammengeführt wurde und nun als '''FHEM Connector''' verfügbar ist.

Er ermöglicht innerhalb von Minuten die Verknüpfung von FHEM mit einem Amazon Echo Gerät. Auch Geräte anderer Hersteller mit verbauten Mikrofonen und Alexa-Sprachassistenten-Unterstützung sollten problemlos funktionieren. Für folgende Geräte ist dies bspw. der Fall (Falls Ihr andere/weitere Gerätemodelle bzw. Hersteller in Verwendung habt, bitte hier pflegen):

* SONOS Beam und SONOS One

Gegenüber dem klassischen Ansatz ergeben sich Einschränkungen, so läuft die Software normalerweise unter dem gleichen Benutzer wie FHEM auf dem gleichen Server, und es wird z.Zt. nur der Smarthome-Skill unterstützt (die Variante, bei der die Möglichkeiten der Interaktion von Amazon festgelegt wurden).
Dafür ist weder ein Developer-Account bei Amazon, eigene Lambda- und Skillfunktionen, noch das Öffnen eines eingehenden Ports aus dem Internet nötig.
* Die Software integriert einen Installer, der die Erstkonfiguration und Anmeldung übernimmt
* Die Kommunikation zur Software auf dem heimischen Rechner und dann zu FHEM verläuft über SSH und einen vom FHEM-Verein gehosteten Server
* Funktioniert mit IPv4, IPv6, echtem Dual Stack und DS-Lite
* Als Skill bei Amazon wird der Skill "FHEM Connector" verwendet.

Der Thread im Forum zur Software ist hier: {{Link2Forum|Topic=94817}}.

{{Infobox Modul
|ModPurpose=Einfache Anbindung von FHEM an Amazon Assistent Alexa
|ModType=h
|ModCmdRef=alexa
|ModTechName=39_alexa.pm / alexa-fhem
|ModForumArea=Frontends/Sprachsteuerung
|ModOwner=gvzdus, André/ justme1968 ({{Link2FU|430|Forum}} / [[Benutzer Diskussion:Justme|Wiki]])
}}

==Einführung==

===Arbeitsweise und Datenfluss===
Vorläufig ist alexa-fhem im "FHEM Connector-Modus" ein reiner [https://developer.amazon.com/de/docs/smarthome/understand-the-smart-home-skill-api.html SmartHome-Skill].
SmartHome-Skills erhalten weder die Sprachdaten selber noch das, was Amazon in Textform verstanden hat, sondern vielmehr extrahiert Amazon aus dem verstandenen Text Anweisungen und Abfragen für Geräte, die dann an den Skill übermittelt werden. Charmant ist dabei, dass unmittelbar gefragt werden kann "Alexa, wie ist die Temperatur im Wohnzimmer?", während andere Skills zunächst explizit angesprochen werden müssen ("Alexa, frage FHEM nach der Temperatur im Wohnzimmer"). Außerdem kann der Nutzer mehrere Smarthome-Skills installieren, und die Geräte werden zu einer Gesamtmenge zusammengefasst.

Gehen wir den Datenfluss bei der konkreten Frage "Wie ist die Temperatur im Wohnzimmer?" durch:
* Alexa hat bei der Skillinstallation gelernt, dass "FHEM Connector" bei Dir einen Thermostaten im Raum Wohnzimmer kennt. Dadurch wird bei der Sprachanalyse von "Alexa Voice Service" in der Cloud erkannt, dass eine Abfrage an "FHEM Connector" erfolgversprechend ist.
* Zunächst wird die zentrale "Lambda-Funktion" von "FHEM Connector" aufgerufen. Die Funktion leitet aber im Kern nur den Request unverändert an den vom Verein bereitgestellten Server weiter. Im Request enthalten ist ein Token, das sogenannte "Bearer-Token".
* Der "Vereinsserver" prüft anhand dieses Tokens, ob es überhaupt bekannt ist, und zu welchem Nutzer es gehört. Ist dieser Nutzer verbunden, wird der Request wiederum quasi unverändert an den Nutzer weitergeleitet.
* Diese Weiterleitung passiert über einen sogenannten SSH-Reverse-Tunnel, der von Deiner Seite und der Software auf dem FHEM-Tunnel automatisch aufgebaut wird.
* Auf Deiner Seite läuft die eigentliche Software, und zwar unter nodeJS. nodeJS ist ein Javascript ausführender Miniserver, der lokal auf Port 3000 auf Requests "lauscht". In der Original-Version [[Alexa-Fhem|Alexa FHEM]] kommen die Requests aus dem Internet (hoffentlich von der eigenen Lambda-Funktion), hier bei "FHEM Connector" kommen sie ausschließlich aus dem SSH-Tunnel von lokal.
* Die Software validiert nun diesen Request anhand des Bearer-Tokens. Konkret wird dabei das bei der Installation generierte Token, dass bei der Skill-Aktivierung an Amazon übertragen wurde, mit dem lokal gespeicherten Wert verglichen. Stimmt das Token, wird der Befehl verarbeitet, üblicherweise wird hierbei ein Aufruf an die Webschnittstelle von FHEM abgesetzt.
* FHEM führt den Befehl aus

Hört sich langsam und kompliziert an? Kompliziert: Okay. Langsam eher nicht, in etlichen Fällen liegt die Gesamtantwortszeit unter 200 ms.

Soweit ein erster Überblick über die Datenflüsse. Im Abschnitt Sicherheit ist das Konzept der Absicherung deutlich genauer und ausführlicher beschrieben.

==Installation==

Du wirst bei der Installation zuerst auf der Kommandozeile auf Deinem Raspberry (o.ä.) unterwegs sein, anschließend im Webfrontend von FHEM, und zum Schluss auf der Alexa-Konsole im Web.

===node.js installieren===

Bei Jessy liegt NodeJS bereits in einer ausreichend aktuellen Version vor. Mit

<syntaxhighlight lang="bash" style="width:50%;">
sudo apt-get install nodejs npm
</syntaxhighlight>

kannst Du es installieren. Mit
<syntaxhighlight lang="bash" style="width:50%;">
node --version
</syntaxhighlight>

erfährst Du die aktuelle Version - wenn hier etwas mit "8" vorneweg erscheint, ist alles gut.
Ansonsten suche Dir bitte eine Anleitung im Web, wie Du NodeJS auf Deinem System auf einen aktuellen Stand bringen kannst.

=== Alexa-FHEM installieren ===

Nun installieren wir Alexa-fhem aus dem offiziellen Repository:

<syntaxhighlight lang="bash" style="width:50%;">
sudo npm install -g alexa-fhem
</syntaxhighlight>

Der Vorgang benötigt etwas Zeit.

=== Alexa-FHEM aktivieren ===

Wechsele jetzt in FHEM-Web!

Wichtig ist, dass das Alexa-Modul in der Version ab 14. Januar 2019 vorliegt. Dafür bitte einmal FHEM aktualisieren:
Speichern der Config nicht vergessen, und

<syntaxhighlight lang="bash" style="width:50%;">
update
shutdown restart
</syntaxhighlight>

Alles, was jetzt noch nötig ist, ist das Anlegen eines Alexa-Devices. Gib dafür in der FHEM-Web-Kommandozeile

<syntaxhighlight lang="bash" style="width:50%;">
define alexa alexa
</syntaxhighlight>

an. Nun läuft, während Du bereits das neu angelegte Alexa-Devices siehst, ein komplexer Prozess im Hintergrund:

* Falls noch kein SSH-Key für den Benutzer, unter dem FHEM läuft, existiert, wird einer generiert
* Es wird ein Secret-Key im Prozess generiert, dass den Server nicht verlässt, und der Skillanmeldung dient.
* Du wirst auf dem Server "va-fhem.fhem.de" des FHEM-Vereins mit dem SSH-Key angemeldet, und der Hash-Wert Deines Secret-Key dort abgelegt.

Und wenn Du diese Sätze gelesen hast, sollte inzwischen sich das Alexa-Device in FHEM-Web aktualisiert haben, und
ungefähr so aussehen:

[[Datei:Alexa-Device-2.png|800px]]

Neben dem Status für alexa-fhem und der Proxyverbindung ist wichtig, dass diese beiden Zeilen beim Reload aufgetaucht sind:

<syntaxhighlight lang="bash" style="width:90%;">
alexaFHEM.bearerToken crypt:...
alexaFHEM.skillRegKey crypt:...
</syntaxhighlight>

Ja, und diesen Schlüssel benötigst Du wirklich! Also am besten schon einmal mit

<syntaxhighlight lang="bash" style="width:90%;">
get <alexa> proxyKey
</syntaxhighlight>

in Klartext anzeigen lassen und in ein Editor-Fenster dauerhaft wegsichern.

Jetzt solltest Du Dein Alexa-Device nicht mehr löschen, denn das im Reading angezeigte "bearerToken" zu löschen bedeutet, dass die Software die Zugriffe von nicht mehr überprüfen kann und keine Kommandos mehr funktionieren. In diesem Fall hilft nur die Neuinstallation des Skills.

==== Fehler bei der Aktivierung ====

Während kompliziertere Fehlerfälle im Abschnitt "Mögliche Probleme und Lösungen" behandelt werden, hier häufige Fälle, warum die kryptischen Zeilen nicht auftauchen:

* Zuerst bitte einfach einmal die Seite neu laden.

===== 401: Authorization Required =====

Wenn Du FHEM-Web mit einem User/Passwort-Schutz versehen hast, wirst du folgende Fehlermeldung sehen:

<syntaxhighlight lang="bash" style="width:90%;">
alexaFHEM stopped; failed to connect to fhem: 401: Authorization Required
</syntaxhighlight>

In der Regel musst du die Angaben User/Passwort noch einmal explizit setzen. Im Attribute-Abschnitt "alexaFHEM-auth" auswählen, User/Passwort mit ":" getrennt angeben und "attr" anklicken. alexa-fhem wird automatisch neu gestartet. Hier das Ganze in der Text-Variante:

<syntaxhighlight lang="bash" style="width:90%;">
attr alexa alexaFHEM-auth user:pass
</syntaxhighlight>

===== Permission denied =====

Wenn du folgende Fehlermeldungen im Alexa Logfile siehst, wurde das Verzeichnis "/opt/fhem/.ssh/" von dir bei der Arbeit mit "root" oder "sudo" mit den falschen Berechtigungen versehen:

<syntaxhighlight lang="bash" style="width:90%;">
[2019-7-25 11:59:12] sshautoconf: aborted with ssh-keygen returned error - key_save_private: Permission denied
[2019-7-25 11:59:12] *** SSH: proxy configuration failed: ssh-keygen returned error - key_save_private: Permission denied
</syntaxhighlight>

Prüfen kannst du die Berechtigungen mit folgendem Befehl auf der Shell-Konsole:

<syntaxhighlight lang="bash" style="width:90%;">
ls -l /opt/fhem/.ssh
</syntaxhighlight>

Du solltest dann folgende Ausgabe erhalten:

<syntaxhighlight lang="bash" style="width:90%;">
insgesamt 12
-rw------- 1 fhem dialout 1675 Jul 12 13:10 id_rsa
-rw-r--r-- 1 fhem dialout 391 Jul 12 13:10 id_rsa.pub
-rw-r--r-- 1 fhem dialout 884 Jul 12 13:10 known_hosts
</syntaxhighlight>

Steht in der Ausgabe nicht "fhem dialout" (dein fhem User), sondern bspw. "root root", dann bspw. mit folgendem Befehl an deinen fhem User anpassen:

<syntaxhighlight lang="bash" style="width:90%;">
chown fhem:dialout /opt/fhem/.ssh
</syntaxhighlight>

Mit dem ersten Befehl "ls -l ..." kannst du dann nochmal prüfen, ob die Berechtigungen korrekt übernommen wurden.

===== weitere Prüfungen =====

Hast Du noch die Shell-Konsole offen? Dann prüfe bitte noch einmal auf der Konsole, ob nun zwei Prozesse laufen:

<syntaxhighlight lang="bash" style="width:50%;">
ps -ef | egrep '(alexa|ssh)'
</syntaxhighlight>

sollte Dir idealerweise so etwas anzeigen:
<syntaxhighlight lang="bash" style="width:90%;">
fhem 31322 1 99 13:56 ? 00:00:03 alexa
fhem 31332 31322 8 13:56 ? 00:00:00 /usr/bin/ssh -R 1234:127.0.0.1:<zufälliger port> -oServerAliveInterval=90 -p 58824 fhem-va.fhem.de
</syntaxhighlight>

"alexa" ist dabei der Node-JS-Prozess, der ssh-Prozess ist die aufgebaute Verbindung zum Vereinsserver.

Wenn Du diese Prozesse '''nicht''' siehst oder das Alexa-Device keinen Registrierungskey anzeigt, dann ist leider der Start nicht glatt verlaufen.

Im Logfile (über den link <code>Logfile</code> in der Detail-Ansicht über <code>set</Code>, oder über den Namen bei ''currentlogfile'' in den Internals) findest Du idealerweise selber Hinweise, wo es hakt, oder kannst im Forum nachfragen.

=== Geräte im FHEM-Webfrontend zuweisen ===
Um das Aha-Erlebnis zu vergrößern, ist jetzt ein guter Zeitpunkt, 1 oder besser mind. 2 Geräte für den Alexa-Dienst zuzuweisen. Von Haus aus wird keines Deiner FHEM-Geräte automatisch Alexa zugewiesen!

Wähle die Geräte aus, rufe sie auf und setze das Attribut "alexaName". Hierbei in Kürze nur der Hinweis:
* Keine Angst vor Leerzeichen und Umlauten, funktioniert.
* Große Angst vor Rechtschreibfehlern (Terrasse, Rollladen) oder komplizierten Wörtern "handgebastelte Martinslaterne im Kinderzimmer Iphigenie-Chantal".
* Das Attribut "alexaRoom" ist NUR FÜR DEN CUSTOM SKILL relevant. Ausnahme: structure und LightScene Devices, siehe: [[FHEM_Connector_f%C3%BCr_Amazon_Alexa#Was_geht_alles_.3F]].

Lade die Geräte neu in die Software, indem Du <code>set <alexa> restart</code> ausführst!

== Finale: Skill verknüpfen ==
Suche im WebFrontend oder der Alexa-App den Skill "FHEM Connector". Für nicht-Mac/iOS Anwerder empfiehlt das WebFrontend (https://alexa.amazon.de) statt die App, damit Du den Anmeldeschlüssel auch bequem kopieren kannst.

Wenn du noch nicht bei Amazon angemeldet bist, erwartet Amazon zunächst, dass Du Dich normal bei Amazon anmeldest.

Sobald Du "FHEM Connector" aktivierst, öffnet sich ein Browser-Tab mit folgender Maske: 
[[Datei:FHEMlazy_login.png|240px]]

Hier kopierst Du Deinen Anmeldeschlüssel (im Klartext!) hinein und klickst auf Check. Als glücklicher Mensch ist auf der folgenden Statusseite alles grün: 
[[Datei:FHEMlazy_check.png|240px]]

Im Einzelnen wird hier geprüft, ob Du per SSH verbunden bist (und auch Deine IP zur Sicherheit angezeigt), ob der Reverse-Tunnel steht, ob nodeJS erreichbar ist und wie viele Geräte Alexa gleich finden sollte (in meinem Fall 22).

Sollte etwas nicht grün sein und Du eine Idee zum Fixen haben, kannst Du mit "Retry" neue Versuche auslösen.

Ist alles okay, klicke rechts den Button "Activate Skill". Du springst damit wieder zurück zu Amazon, die Dir hoffentlich zur erfolgreichen Verknüpfung gratulieren.

Amazon möchte nun unmittelbar die Gerätesuche starten, und unter SmartHome-Geräte sollten diese nun auftauchen.

== Was geht alles ? ==

* Geräte, die sich ein- und ausschalten lassen:
** Automatisch: Müssen <code>set on</code> und <code>set off</code> Kommandos haben
** dummys müssen <code>setList</code> mit on und off haben
** Über <code>genericDeviceType</code> switch bzw. light kann bestimmt werden ob es in alexa als Schalter oder Licht behandelt wird.
** Wenn die Set-Kommandos im FHEM Device anders benannt sind: hombridgeMapping On:cmdOn=<ein>,cmdOff=<aus> setzen
** Kommandos:
***Alexa, schalte <name> ein/aus
***Alexa, Licht an/aus
***Alexa, schalte <gruppe> ein/aus

* Geräte, die eine Temperatur messen
** Automatisch: Es muss ein Reading temperature geben
** Über <code>genericDeviceType</code> thermometer
** Sonst: hombridgeMapping CurrentTemperature:reading=<reading>

* Geräte, deren Helligkeit sich ändern lässt
** Automatisch: wenn <code>dim</code> oder <code>pct</code> Kommandos erkannt werden
** Über <code>genericDeviceType</code> light
** Über homebridgeMapping: Wenn <code>helligkeit</code> das Reading für die aktuelle Helligkeit enthält und die Helligkeit mit <code>set <device> prozent xxx</code> gesetzt wird, sieht das homebridgeMapping wie folgt aus:
*** homebridgeMapping Brightness=helligkeit::prozent,minValue=0,maxValue=<maximalwert>

**Kommandos:
***Alexa, mache <name> heller/dunkler
***Alexa, Licht heller/dunkler

* Geräte, deren Farbe sich ändern lässt
** ...

* Geräte, deren Farbtemperatur sich ändern lässt
** ...

* Geräte, bei denen sich eine Lautstärke einstellen lässt
** ...

* Geräte, bei denen sich ein prozentualer Wert einstellen lässt
** Automatisch: wenn <code>dim</code> oder <code>pct</code> Kommandos erkannt werden
** ...

* elektrische Türschlösser
** <code>genericDeviceType</code>: lock
** hombridgeMapping mit LockCurrentState und LockTargetState

* Thermostate
** Über <code>genericDeviceType</code> thermostate
** ...

* structure Devices aus FHEM (ab alexa-fhem version 0.5.7)
** können mit <code>genericDeviceType</code> scene als Szene eingebunden werden
** über <code>alexaRoom</code> kann der name um einen Ort ergänzt werden
** Szenen aus einer structure lassen sich ein- und ausschalten
** Wichtig:
*** Ein Skill darf nur 12 Szenen automatisch erkennen und einbinden.

* LightScene Devices aus FHEM (ab alexa-fhem version 0.5.8)
** können mit <code>genericDeviceType</code> scene als Szenen eingebunden werden
** über <code>alexaRoom</code> kann der name um einen Ort ergänzt werden
** Szenen aus einer LightScene lassen sich nur einschalten
** Wichtig:
*** Ein Skill darf nur 12 Szenen automatisch erkennen und einbinden.

* Geräte, deren Kanal sich umschalten lässt (ab alexa-fhem version 0.5.13)
** Über <code>genericDeviceType</code> media
** hombridgeMapping ChannelController:reading=<reading>,cmd=<cmd>
** Erlaubte Werte siehe hier: https://developer.amazon.com/de/docs/device-apis/alexa-channelcontroller.html#changechannel
** ...

* Geräte, deren Playback status sich schalten lässt (ab alexa-fhem version 0.5.13)
** Über <code>genericDeviceType</code> media
** hombridgeMapping PlaybackController:playback,values=Play;Pause;Stop;Previous;Next
** Erlaubte Werte siehe hier: https://developer.amazon.com/de/docs/device-apis/alexa-playbackcontroller.html#discovery
** ...

* Geräte, deren Eingang sich umschalten lässt (ab alexa-fhem version 0.5.13)
** Über <code>genericDeviceType</code> media
** hombridgeMapping InputController:reading=<reading>,cmd=<cmd>,values=HDMI+1;HDMI+2;XBOX
** Erlaubte Werte siehe hier: https://developer.amazon.com/de/docs/device-apis/alexa-property-schemas.html#input
** ...

* Kontaktsensoren (ab alexa-fhem version 0.5.15)
** Über <code>genericDeviceType</code> contact
** hombridgeMapping ContactSensorState:reading=<reading> oder CurrentDoorState:reading=<reading>
** Die Anzeige in der Alexa-App funktioniert sofort, die Abfrage per Sprache erst ab Version 0.5.27.

* Geräte, deren Lautstärke sich ändern lässt (ab alexa-fhem version 0.5.24)
** Über <code>genericDeviceType</code> speaker
** Automatisch: es muss ein Reading <code>volume</code> und/oder <code>mute</code> geben
** hombridgeMapping Volume:reading=<reading>,cmd=<cmd> Mute:reading=<reading>,cmd=<cmd>
** ...

* Geräte, die sich ein- (und optional) ausschalten lassen als Szene (ab alexa-fhem version 0.5.26)
** Über <code>genericDeviceType</code> scene
** Automatisch: Müssen <code>set on</code> und <code>set off</code> Kommandos haben
** hombridgeMapping On:reading=<reading>,cmdOn=<cmd>[,cmdOff=<cmd>]
** Hinweis: Fehlende Kommandos lassen sich mit cmdalias erzeugen
** Wichtig:
*** Ein Skill darf nur 12 Szenen automatisch erkennen und einbinden.

Es werden noch einige andere häufig verwendete Geräte (Homematic, hue,...) automatisch erkannt.

to be continued ...

In der [https://developer.amazon.com/docs/device-apis/list-of-interfaces.html List of Capability Interfaces] bei Amazon kann man sehen, welche Möglichkeiten das Smart Home Skill API aktuell in einzelnen Ländern bietet. Leider ohne die jeweiligen landessprachlichen Kommandos.

== Mögliche Probleme und Lösungen ==

Es kann vorkommen, dass Geräte zwar korrekt erkannt werden, aber das durch Alexa erkannte Kommando nicht richtig umgesetzt wird (Beispiel - mittlerweile behoben: {{Link2Forum|Topic=96766}}). Neben dem FHEM-Log gibt es noch das Logfile, welches von alexa-fhem angelegt wird.

=== Fehlersuche über die FHEM-Oberfläche ===

* alexa-fhem Logfile anschauen (Detail-Ansicht des <alexa>-Device aufrufen, klick auf '''Logfile''' oben)
* alexa-fhem im Debug-Modus aufrufen:
** -D zum alexaFHEM-params attribut hinzufügen
** Alexa-Befehl auslösen
** -D aus dem alexaFHEM-params attribut entfernen
* Die notwendigen Informationen finden sich in dem alexa-Logfile (siehe oben)

=== Fehlersuche über Kommandozeile (lies: Shell) + FHEM-Oberfläche ===

:* set <alexa> stop (FHEM-Oberfläche)
:* Auf der Kommandozeile <code>alexa-fhem -D -c /opt/fhem/alexa-fhem.cfg > debug.log</code> starten (dadurch wird die Datei debug.log erzeugt im aktuellen Verzeichnis)
:* Alexa-Befehl auslösen
:* alexa-fhem auf der Kommandozeile wieder stoppen (CTRL-C)
:* set <alexa> start (FHEM-Oberfläche)

Die Datei debug.log sollte Hinweise enthalten, wie das Problem zu lösen ist oder Dich zumindest in die richtige Richtung schieben.

Im Beispiel aus dem Forum fand sich in dem Logfile der Hinweis darauf, dass das Device mit falschen min/max-Werten unterwegs war.

=== Registrierungskey vergessen, Registrierung zurücksetzen ===

Auf der Kommandoshell:

<syntaxhighlight lang="bash" style="width:90%;">
pi@raspberrypi:~# sudo -u fhem ssh -p 58824 fhem-va.fhem.de status
Registered.
Registered on 2019-01-13T15:38:13Z.
</syntaxhighlight>

heisst, das der Vereinsserver eigentlich alles hat, was er will. Es wird kein neuer Schlüssel generiert.
Wenn Du die Situation zurücksetzen möchtest, wäre die hässliche Methode, Deinen SSH-Key zu löschen. Eleganter ist, die Registrierung auf Vereinsseite zu löschen:

<syntaxhighlight lang="bash" style="width:90%;">
pi@raspberrypi:~# sudo -u fhem ssh -p 58824 fhem-va.fhem.de unregister
Your registration has been removed
</syntaxhighlight>

löscht Deinen Schlüssel mitsamt allen dort gespeicherten Daten auf Vereinsseite. Bei Restart von alexa-fhem in FHEM-WEB wird jetzt ein neuer Registrierungskey angefordert.

== Sicherheitskonzept und Secrets ==

Um diesen Abschnitt zu verstehen, solltest Du den Abschnitt "Arbeitsweise" im Kopf haben. Einerseits ist Dir vermutlich einleuchtend, dass ein Server, der per SSH rückwärts nur ausgewählte Kommandos in den Tunnel, den Du aufgebaut hast, leitet, "irgendwie sicherer" ist. Andererseits möchte man nicht blind vertrauen.

=== SSH ===
==== SSH - macht das nichts Gefährliches? ====
SSH ist ein Veteran des Internet und entstand, um sich sicher (verschlüsselt) und schnell auf Servern einzuloggen. Schon früh wurde dabei der sogenannte "Reverse-Tunnel" implementiert: Also der vom Client (Deinem Rechner) geäußerte Wunsch: "Bitte leite mir Requests, die bei Dir, Server, auf Port xy eingehen, an meinen lokalen Port yz weiter.". Dieses Verfahren implementiert der Reverseproxy, wobei tatsächlich auf dem Server für Dich kein echter Port geöffnet wird.

Wie Dir ggf. sicher der Unix-Guru Deines Vertrauens bestätigen wird: Die Kombination
<syntaxhighlight lang="bash" style="width:50%;">
ssh -R 1234:localhost:<zufälliger port> zielserver
</syntaxhighlight>
erlaubt keine Ausführung von Shell-Kommandos auf Deinem Server, sondern einzig, dass vom SSH-Programm Verbindungen zu einem lokalen Port auf Deinem Server auf dem alexa-fhem lauscht aufgebaut werden. Du kannst also z.B. mit einem
<syntaxhighlight lang="bash" style="width:50%;">
sudo /usr/sbin/tcpdump -X -s 0 -i lo port <zufälliger port>
</syntaxhighlight>
vollständig überwachen (oder ggf. permanent aufzeichen), was auf Deinem Server von außen gesteuert passiert.

==== Wie wird bei SSH verschlüsselt? ====
Im Prinzip wie im Web auf SSL-Seiten, teils mit den gleichen Verschlüsselungsverfahren. Allerdings arbeitet SSH eher wie das im Web recht seltene Verfahren: Bei jeder Verbindung übermitteln sowohl Server wie auch Client den öffentlichen Teil ihres Schlüssels. Anders als im Web wird der Schlüssel aber nicht von einer öffentlichen Zertifizierungsstelle wie "LetsEncrypt" unterschrieben. Stattdessen entscheiden Server wie Client beim ersten Verbindungsaufbau typischerweise per manueller Frage: "Willst Du jetzt und künftig diesem Schlüssel vertrauen?" Bei der Installation wird diese Frage für Deine Seite bejaht, und fortan wird der öffentliche Schlüssel des FHEM-Servers auf Deinem Rechner gespeichert. Ab da bist Du z.B. davor sicher, dass jemand den DNS-Eintrag verbiegt oder sich in den Datenfluss Deines Providers einhängt: Ein geänderter Serverschlüssel würde bemerkt werden.
 
Soweit klar? Aus Deinem öffentlichen Schlüssel wiederum leitet der Server her: "Das ist definitiv wieder derjenige, der sich damals "registriert" hat". Und an dieser Stelle kann ich auch den ersten Teil des 3-teiligen Registrierungskeys erläutern: Die typischerweise 6-stellige Hex-Zahl am Anfang ist der Java-Hashcode Deines öffentlichen Schlüssel. Sie ist damit sozusagen Deine aus Deinem öffentlichen Schlüssel abgeleitete Benutzer-ID.

=== Die Rolle der Secrets ===
Wenn jetzt klar ist, dass die Verbindung zum Vereinsserver sicher und vertauschungsfrei funktioniert, bleiben noch 2 Probleme zu lösen:
1) Im Web bei der Skill-Aktivierung musst Du beweisen, dass Du der Mensch am Browser bist, dem der SSH-Tunnel von IP xy mit dem öffentlichen Schlüssel X gehört. Bei der automatischen Registrierung werden lokal auf Deinem Rechner zwei 64-Bit-Secrets generiert:
* Das Anmelde-Secret
* Das Bearer-Token
Beim Anmelden des SSH-Keys auf dem öffentlichen Server wird nun der Hashwert des ersten Secrets übertragen und dort in Verbindung mit Deinem öffentlichen Schlüssel gespeichert. Ein Hashwert bedeutet, dass (sofern das Verfahren, hier SHA256, funktioniert), niemand aus dem Hash das Secret zurückrechnen kann. Ein Datenbankklau auf dem Server gefährdet also nicht die Sicherheit Deines Passwortes.

Wenn Du nun beim Skill-Aktivieren den Registrierungskey eingibst, dann "sieht" der Server zum ersten Mal Dein ausgewürfeltes Secret, vergleicht es mit dem Hashwert und wird es anschließend wieder umgehend vergessen. Anhand des Hashwertes kann der Server aber entscheiden, dass Du der legitime Nutzer zum öffentlichen Schlüssel XY bist.

2) Das zweite Problem ist: Wie soll Amazon "beweisen", dass sie der legitime Aufrufer sind? Amazon erhält binnen wenigen Sekunden nach dem Klick auf "Activate Skill" den dritten Teil des Registrierungskeys als sogenanntes Bearer-Token. Zwar läuft er durch den Registrierungsserver, er wird dort, auf dem Registrierungs/Vereinsserver aber nicht gespeichert. Das Bearer-Token wird von Amazon bei allen Requests zu Deinem Server mitgesendet. Da es am Anfang zusätzlich Deine "User-ID" enthält, weiß der Vereinsserver, zu welchem SSH-Tunnel der Request zu senden ist. Aber lokal auf Deinem Rechner wird ausgewertet, ob das Token "stimmt".

== alexa-fhem Updaten ==
* alexa-fhem über FHEM anhalten:
:<syntaxhighlight lang="perl" style="width:50%;">set alexa stop</syntaxhighlight>

*Auf der Konsole wie anfangs bei der Installation:
:<syntaxhighlight lang="bash" style="width:50%;">sudo npm update -g alexa-fhem</syntaxhighlight>

:Manchmal hat npm Probleme mit einem Update. Dann einfach die aktuelle Version noch mal drüber Installieren:

:<syntaxhighlight lang="bash" style="width:50%;">sudo npm install -g alexa-fhem</syntaxhighlight>

*alexa-fhem über FHEM wieder starten:
:<syntaxhighlight lang="perl" style="width:50%;">set alexa start</syntaxhighlight>

== Bug- und Wunschliste ==
* Ist beim Start keine Internetverbindung vorhanden, erfolgt kein Retry -- alexa-fhem muss restartet werden (ssh_autoconfig wertet keine temporären Fehler aus)

==Weitergehende Informationen==
*[[Alexa und Mappings]]
*[[Alexa Tipps und Kniffe]]
*[[FHEM Connector for Amazon Alexa]]
[[Kategorie:HOWTOS]]
[[Kategorie:Sprachsteuerung]]

FHEM Connector für Amazon Alexa

2019-03-13T18:49:37Z

Sledge: homebridgeMapping bei dimmbaren Leuchten

{{Baustelle}}
'''Alexa FHEMlazy''' war historisch ein Fork des Original [[Alexa-Fhem|alexa-fhem]], der im Januar 2019 mit dem Original zusammengeführt wurde und nun als '''FHEM Connector''' verfügbar ist.

Er ermöglicht innerhalb von Minuten die Verknüpfung von FHEM mit einem Amazon Echo-Gerät.

Gegenüber dem klassischen Ansatz ergeben sich Einschränkungen, so läuft die Software normalerweise unter dem gleichen Benutzer wie FHEM auf dem gleichen Server, und es wird z.Zt. nur der Smarthome-Skill unterstützt (die Variante, bei der die Möglichkeiten der Interaktion von Amazon festgelegt wurden).
Dafür ist weder ein Developer-Account bei Amazon, eigene Lambda- und Skillfunktionen, noch das Öffnen eines eingehenden Ports aus dem Internet nötig.
* Die Software integriert einen Installer, der die Erstkonfiguration und Anmeldung übernimmt
* Die Kommunikation zur Software auf dem heimischen Rechner und dann zu FHEM verläuft über SSH und einen vom FHEM-Verein gehosteten Server
* Funktioniert mit IPv4, IPv6, echtem Dual Stack und DS-Lite
* Als Skill bei Amazon wird der Skill "FHEM Connector" verwendet.

Der Thread im Forum zur Software ist hier: {{Link2Forum|Topic=94817}}.

{{Infobox Modul
|ModPurpose=Einfache Anbindung von FHEM an Amazon Assistent Alexa
|ModType=h
|ModCmdRef=alexa
|ModTechName=39_alexa.pm / alexa-fhem
|ModForumArea=Frontends/Sprachsteuerung
|ModOwner=gvzdus, André/ justme1968 ({{Link2FU|430|Forum}} / [[Benutzer Diskussion:Justme|Wiki]])
}}

==Einführung==

===Arbeitsweise und Datenfluss===
Vorläufig ist alexa-fhem im "FHEM Connector-Modus" ein reiner [https://developer.amazon.com/de/docs/smarthome/understand-the-smart-home-skill-api.html SmartHome-Skill].
SmartHome-Skills erhalten weder die Sprachdaten selber noch das, was Amazon in Textform verstanden hat, sondern vielmehr extrahiert Amazon aus dem verstandenen Text Anweisungen und Abfragen für Geräte, die dann an den Skill übermittelt werden. Charmant ist dabei, dass unmittelbar gefragt werden kann "Alexa, wie ist die Temperatur im Wohnzimmer?", während andere Skills zunächst explizit angesprochen werden müssen ("Alexa, frage FHEM nach der Temperatur im Wohnzimmer"). Außerdem kann der Nutzer mehrere Smarthome-Skills installieren, und die Geräte werden zu einer Gesamtmenge zusammengefasst.

Gehen wir den Datenfluss bei der konkreten Frage "Wie ist die Temperatur im Wohnzimmer?" durch:
* Alexa hat bei der Skillinstallation gelernt, dass "FHEM Connector" bei Dir einen Thermostaten im Raum Wohnzimmer kennt. Dadurch wird bei der Sprachanalyse von "Alexa Voice Service" in der Cloud erkannt, dass eine Abfrage an "FHEM Connector" erfolgversprechend ist.
* Zunächst wird die zentrale "Lambda-Funktion" von "FHEM Connector" aufgerufen. Die Funktion leitet aber im Kern nur den Request unverändert an den vom Verein bereitgestellten Server weiter. Im Request enthalten ist ein Token, das sogenannte "Bearer-Token".
* Der "Vereinsserver" prüft anhand dieses Tokens, ob es überhaupt bekannt ist, und zu welchem Nutzer es gehört. Ist dieser Nutzer verbunden, wird der Request wiederum quasi unverändert an den Nutzer weitergeleitet.
* Diese Weiterleitung passiert über einen sogenannten SSH-Reverse-Tunnel, der von Deiner Seite und der Software auf dem FHEM-Tunnel automatisch aufgebaut wird.
* Auf Deiner Seite läuft die eigentliche Software, und zwar unter nodeJS. nodeJS ist ein Javascript ausführender Miniserver, der lokal auf Port 3000 auf Requests "lauscht". In der Original-Version [[Alexa-Fhem|Alexa FHEM]] kommen die Requests aus dem Internet (hoffentlich von der eigenen Lambda-Funktion), hier bei "FHEM Connector" kommen sie ausschließlich aus dem SSH-Tunnel von lokal.
* Die Software validiert nun diesen Request anhand des Bearer-Tokens. Konkret wird dabei das bei der Installation generierte Token, dass bei der Skill-Aktivierung an Amazon übertragen wurde, mit dem lokal gespeicherten Wert verglichen. Stimmt das Token, wird der Befehl verarbeitet, üblicherweise wird hierbei ein Aufruf an die Webschnittstelle von FHEM abgesetzt.
* FHEM führt den Befehl aus

Hört sich langsam und kompliziert an? Kompliziert: Okay. Langsam eher nicht, in etlichen Fällen liegt die Gesamtantwortszeit unter 200 ms.

Soweit ein erster Überblick über die Datenflüsse. Im Abschnitt Sicherheit ist das Konzept der Absicherung deutlich genauer und ausführlicher beschrieben.

==Installation==

Du wirst bei der Installation zuerst auf der Kommandozeile auf Deinem Raspberry (o.ä.) unterwegs sein, anschließend im Webfrontend von FHEM, und zum Schluss auf der Alexa-Konsole im Web.

===node.js installieren===

Bei Jessy liegt NodeJS bereits in einer ausreichend aktuellen Version vor. Mit

<syntaxhighlight lang="bash" style="width:50%;">
sudo apt-get install nodejs npm
</syntaxhighlight>

kannst Du es installieren. Mit
<syntaxhighlight lang="bash" style="width:50%;">
node --version
</syntaxhighlight>

erfährst Du die aktuelle Version - wenn hier etwas mit "8" vorneweg erscheint, ist alles gut.
Ansonsten suche Dir bitte eine Anleitung im Web, wie Du NodeJS auf Deinem System auf einen aktuellen Stand bringen kannst.

=== Alexa-FHEM installieren ===

Nun installieren wir Alexa-fhem aus dem offiziellen Repository:

<syntaxhighlight lang="bash" style="width:50%;">
sudo npm install -g alexa-fhem
</syntaxhighlight>

Der Vorgang benötigt etwas Zeit.

=== Alexa-FHEM aktivieren ===

Wechsele jetzt in FHEM-Web!

Wichtig ist, dass das Alexa-Modul in der Version ab 14. Januar 2019 vorliegt. Dafür bitte einmal FHEM aktualisieren:
Speichern der Config nicht vergessen, und

<syntaxhighlight lang="bash" style="width:50%;">
update
shutdown restart
</syntaxhighlight>

Alles, was jetzt noch nötig ist, ist das Anlegen eines Alexa-Devices. Gib dafür in der FHEM-Web-Kommandozeile

<syntaxhighlight lang="bash" style="width:50%;">
define alexa alexa
</syntaxhighlight>

an. Nun läuft, während Du bereits das neu angelegte Alexa-Devices siehst, ein komplexer Prozess im Hintergrund:

* Falls noch kein SSH-Key für den Benutzer, unter dem FHEM läuft, existiert, wird einer generiert
* Es wird ein Secret-Key im Prozess generiert, dass den Server nicht verlässt, und der Skillanmeldung dient.
* Du wirst auf dem Server "va-fhem.fhem.de" des FHEM-Vereins mit dem SSH-Key angemeldet, und der Hash-Wert Deines Secret-Key dort abgelegt.

Und wenn Du diese Sätze gelesen hast, sollte inzwischen sich das Alexa-Device in FHEM-Web aktualisiert haben, und
ungefähr so aussehen:

[[Datei:Alexa-Device-2.png|800px]]

Neben dem Status für alexa-fhem und der Proxyverbindung ist wichtig, dass diese beiden Zeilen beim Reload aufgetaucht sind:

<syntaxhighlight lang="bash" style="width:90%;">
alexaFHEM.bearerToken crypt:...
alexaFHEM.skillRegKey crypt:...
</syntaxhighlight>

Ja, und diesen Schlüssel benötigst Du wirklich! Also am besten schon einmal mit

<syntaxhighlight lang="bash" style="width:90%;">
get <alexa> proxyKey
</syntaxhighlight>

in Klartext anzeigen lassen und in ein Editor-Fenster dauerhaft wegsichern.

Während kompliziertere Fehlerfälle im Abschnitt "Mögliche Probleme und Lösungen" behandelt werden, hier häufige Fälle, warum die kryptischen Zeilen nicht auftauchen:

* Zuerst bitte einfach einmal die Seite neu laden.

* Wenn Du FHEM-Web mit einem User/Passwort-Schutz versehen hast, musst Du i.d.R. diese Angaben noch einmal explizit setzen: Im attribute-Abschnitt "alexaFHEM-auth" auswählen, User/Passwort mit ":" getrennt angeben und "attr" anklicken. alexa-fhem wird automatisch neu gestartet. Hier das Ganze in der Text-Variante:

<syntaxhighlight lang="bash" style="width:90%;">
attr alexa alexaFHEM-auth user:pass
</syntaxhighlight>

Hast Du noch die Shell-Konsole offen?

Dann prüfe bitte noch einmal auf der Konsole, ob nun zwei Prozesse laufen:
<syntaxhighlight lang="bash" style="width:50%;">
ps -ef | egrep '(alexa|ssh)'
</syntaxhighlight>

sollte Dir idealerweise so etwas anzeigen:
<syntaxhighlight lang="bash" style="width:90%;">
fhem 31322 1 99 13:56 ? 00:00:03 alexa
fhem 31332 31322 8 13:56 ? 00:00:00 /usr/bin/ssh -R 1234:127.0.0.1:<zufälliger port> -oServerAliveInterval=90 -p 58824 fhem-va.fhem.de
</syntaxhighlight>

"alexa" ist dabei der Node-JS-Prozess, der ssh-Prozess ist die aufgebaute Verbindung zum Vereinsserver.

Wenn Du diese Prozesse '''nicht''' siehst oder das Alexa-Device keinen Registrierungskey anzeigt, dann ist leider der Start nicht glatt verlaufen.

Im Logfile (über den link <code>Logfile</code> in der Detail-Ansicht über <code>set</Code>, oder über den Namen bei <it>currentlogfile</it> in den Internals) findest Du idealerweise selber Hinweise, wo es hakt, oder kannst im Forum nachfragen.

Jetzt solltest Du Dein Alexa-Device nicht mehr löschen, denn das im Reading angezeigte "bearerToken" zu löschen bedeutet, dass die Software die Zugriffe von nicht mehr überprüfen kann und keine Kommandos mehr funktionieren. In diesem Fall hilft nur die Neuinstallation des Skills.

=== Geräte im FHEM-Webfrontend zuweisen ===
Um das Aha-Erlebnis zu vergrößern, ist jetzt ein guter Zeitpunkt, 1 oder besser mind. 2 Geräte für den Alexa-Dienst zuzuweisen. Von Haus aus wird keines Deiner FHEM-Geräte automatisch Alexa zugewiesen!

Wähle die Geräte aus, rufe sie auf und setze das Attribut "alexaName". Hierbei in Kürze nur der Hinweis:
* Keine Angst vor Leerzeichen und Umlauten, funktioniert.
* Große Angst vor Rechtschreibfehlern (Terrasse, Rollladen) oder komplizierten Wörtern "handgebastelte Martinslaterne im Kinderzimmer Iphigenie-Chantal".

Lade die Geräte neu in die Software, indem Du <code>set <alexa> restart</code> ausführst!

== Finale: Skill verknüpfen ==
Suche im WebFrontend oder der Alexa-App den Skill "FHEM Connector". Für nicht-Mac/iOS Anwerder empfiehlt das WebFrontend (https://alexa.amazon.de) statt die App, damit Du den Anmeldeschlüssel auch bequem kopieren kannst.

Wenn du noch nicht bei Amazon angemeldet bist, erwartet Amazon zunächst, dass Du Dich normal bei Amazon anmeldest.

Sobald Du "FHEM Connector" aktivierst, öffnet sich ein Browser-Tab mit folgender Maske: 
[[Datei:FHEMlazy_login.png|240px]]

Hier kopierst Du Deinen Anmeldeschlüssel (im Klartext!) hinein und klickst auf Check. Als glücklicher Mensch ist auf der folgenden Statusseite alles grün: 
[[Datei:FHEMlazy_check.png|240px]]

Im Einzelnen wird hier geprüft, ob Du per SSH verbunden bist (und auch Deine IP zur Sicherheit angezeigt), ob der Reverse-Tunnel steht, ob nodeJS erreichbar ist und wie viele Geräte Alexa gleich finden sollte (in meinem Fall 22).

Sollte etwas nicht grün sein und Du eine Idee zum Fixen haben, kannst Du mit "Retry" neue Versuche auslösen.

Ist alles okay, klicke rechts den Button "Activate Skill". Du springst damit wieder zurück zu Amazon, die Dir hoffentlich zur erfolgreichen Verknüpfung gratulieren.

Amazon möchte nun unmittelbar die Gerätesuche starten, und unter SmartHome-Geräte sollten diese nun auftauchen.

== Was geht alles ? ==

* Geräte, die sich ein- und ausschalten lassen:
** Automatisch: Müssen <code>set on</code> und <code>set off</code> Kommandos haben
** dummys müssen <code>setList</code> mit on und off haben
** Über <code>genericDeviceType</code> switch bzw. light kann bestimmt werden ob es in alexa als Schalter oder Licht behandelt wird.
** Wenn die Set-Kommandos im FHEM Device anders benannt sind: hombridgeMapping On:cmdOn=<ein>,CmdOff=<aus> setzen
** Kommandos:
***Alexa, schalte <name> ein/aus
***Alexa, Licht an/aus
***Alexa, schalte <gruppe> ein/aus

* Geräte, die eine Temperatur messen
** Automatisch: Es muss ein Reading temperature geben
** Über <code>genericDeviceType</code> thermometer
** Sonst: hombridgeMapping CurrentTemperature:reading=<reading>

* Geräte, deren Helligkeit sich ändern lässt
** Automatisch: wenn <code>dim</code> oder <code>pct</code> Kommandos erkannt werden
** Über <code>genericDeviceType</code> light
** Über homebridgeMapping: Wenn <code>helligkeit</code> das Reading für die aktuelle Helligkeit enthält und die Helligkeit mit <code>set <device> prozent xxx</code> gesetzt wird, sieht das homebridgeMapping wie folgt aus:
*** homebridgeMapping Brightness=helligkeit::prozent,minValue=0,maxValue=<maximalwert>

**Kommandos:
***Alexa, mache <name> heller/dunkler
***Alexa, Licht heller/dunkler

* Geräte, deren Farbe sich ändern lässt
** ...

* Geräte, deren Farbtemperatur sich ändern lässt
** ...

* Geräte, bei denen sich eine Lautstärke einstellen lässt
** ...

* Geräte, bei denen sich ein prozentualer Wert einstellen lässt
** Automatisch: wenn <code>dim</code> oder <code>pct</code> Kommandos erkannt werden
** ...

* elektrische Türschlösser
** <code>genericDeviceType</code>: lock

* Thermostate
** Über <code>genericDeviceType</code> thermostate
** ...

* structure Devices aus FHEM (ab alexa-fhem version 0.5.7)
** werden mit <code>genericDeviceType</code> scene als Szene eingebunden
** über <code>alexaRoom</code> kann der name um einen Ort ergänzt werden
** Szenen aus einer structure lassen sich ein- und ausschalten
** Wichtig:
*** Ein Skill darf nur 12 Szenen automatisch erkennen und einbinden.
*** Ist der Typ "scene" nicht vorhanden, muss er manuell zum ''Global''-Device hinzugefügt werden: <code>attr global userattr genericDeviceType:switch,outlet,light,blind,scene,speaker,thermostat, ...</code>

* LightScene Devices aus FHEM (ab alexa-fhem version 0.5.8)
** werden mit <code>genericDeviceType</code> scene als Szenen eingebunden
** über <code>alexaRoom</code> kann der name um einen Ort ergänzt werden
** Szenen aus einer LightScene lassen sich nur einschalten
** Wichtig:
*** Ein Skill darf nur 12 Szenen automatisch erkennen und einbinden.
*** Ist der Typ "scene" nicht vorhanden, siehe ''structure''

* Geräte, deren Kanal sich umschalten lässt (ab alexa-fhem version 0.5.13)
** Über <code>genericDeviceType</code> media
** hombridgeMapping ChannelController:reading=<reading>,cmd=<cmd>
** Erlaubte Werte siehe hier: https://developer.amazon.com/de/docs/device-apis/alexa-channelcontroller.html#changechannel
** ...

* Geräte, deren Playback status sich schalten lässt (ab alexa-fhem version 0.5.13)
** Über <code>genericDeviceType</code> media
** hombridgeMapping PlaybackController:playback,values=Play;Pause;Stop;Previous;Next
** Erlaubte Werte siehe hier: https://developer.amazon.com/de/docs/device-apis/alexa-playbackcontroller.html#discovery
** ...

* Geräte, deren Eingang sich umschalten lässt (ab alexa-fhem version 0.5.13)
** Über <code>genericDeviceType</code> media
** hombridgeMapping InputController:reading=<reading>,cmd=<cmd>,values=HDMI+1;HDMI+2;XBOX
** Erlaubte Werte siehe hier: https://developer.amazon.com/de/docs/device-apis/alexa-property-schemas.html#input
** ...

* Kontaktsensoren (ab alexa-fhem version 0.5.15)
** Über <code>genericDeviceType</code> contact
** hombridgeMapping ContactSensorState:reading=<reading> oder CurrentDoorState:reading=<reading>
** Die Anzeige in der Alexa-App funktioniert schon, die Abfrage per Sprache noch nicht.

* Geräte, deren Lautstärke sich schalten lässt (ab alexa-fhem version 0.5.24)
** Über <code>genericDeviceType</code> speaker
** Automatisch: es muss ein Reading <code>volume</code> und/oder <code>mute</code> geben
** hombridgeMapping Volume:reading=<reading>,cmd=<cmd> Mute:reading=<reading>,cmd=<cmd>
** ...

Es werden noch einige andere häufig verwendete Geräte (Homematic, hue,...) automatisch erkannt.

to be continued ...

In der [https://developer.amazon.com/docs/device-apis/list-of-interfaces.html List of Capability Interfaces] bei Amazon kann man sehen, welche Möglichkeiten das Smart Home Skill API aktuell in einzelnen Ländern bietet. Leider ohne die jeweiligen landessprachlichen Kommandos.

== Mögliche Probleme und Lösungen ==

Es kann vorkommen, dass Geräte zwar korrekt erkannt werden, aber das durch Alexa erkannte Kommando nicht richtig umgesetzt wird (Beispiel - mittlerweile behoben: {{Link2Forum|Topic=96766}}). Neben dem FHEM-Log gibt es noch das Logfile, welches von alexa-fhem angelegt wird.

=== Fehlersuche über die FHEM-Oberfläche ===

* alexa-fhem Logfile anschauen (Detail-Ansicht des <alexa>-Device aufrufen, klick auf '''Logfile''' oben)
* alexa-fhem im Debug-Modus aufrufen:
** -D zum alexaFHEM-params attribut hinzufügen
** Alexa-Befehl auslösen
** -D aus dem alexaFHEM-params attribut entfernen
* Die notwendigen Informationen finden sich in dem alexa-Logfile (siehe oben)

=== Fehlersuche über Kommandozeile (lies: Shell) + FHEM-Oberfläche ===

:* set <alexa> stop (FHEM-Oberfläche)
:* Auf der Kommandozeile <code>alexa-fhem -D -c /opt/fhem/alexa-fhem.cfg > debug.log</code> starten (dadurch wird die Datei debug.log erzeugt im aktuellen Verzeichnis)
:* Alexa-Befehl auslösen
:* alexa-fhem auf der Kommandozeile wieder stoppen (CTRL-C)
:* set <alexa> start (FHEM-Oberfläche)

Die Datei debug.log sollte Hinweise enthalten, wie das Problem zu lösen ist oder Dich zumindest in die richtige Richtung schieben.

Im Beispiel aus dem Forum fand sich in dem Logfile der Hinweis darauf, dass das Device mit falschen min/max-Werten unterwegs war.

=== Registrierungskey vergessen, Registrierung zurücksetzen ===

Auf der Kommandoshell:

<syntaxhighlight lang="bash" style="width:90%;">
pi@raspberrypi:~# sudo -u fhem ssh -p 58824 fhem-va.fhem.de status
Registered.
Registered on 2019-01-13T15:38:13Z.
</syntaxhighlight>

heisst, das der Vereinsserver eigentlich alles hat, was er will. Es wird kein neuer Schlüssel generiert.
Wenn Du die Situation zurücksetzen möchtest, wäre die hässliche Methode, Deinen SSH-Key zu löschen. Eleganter ist, die Registrierung auf Vereinsseite zu löschen:

<syntaxhighlight lang="bash" style="width:90%;">
pi@raspberrypi:~# sudo -u fhem ssh -p 58824 fhem-va.fhem.de unregister
Your registration has been removed
</syntaxhighlight>

löscht Deinen Schlüssel mitsamt allen dort gespeicherten Daten auf Vereinsseite. Bei Restart von alexa-fhem in FHEM-WEB wird jetzt ein neuer Registrierungskey angefordert.

== Sicherheitskonzept und Secrets ==

Um diesen Abschnitt zu verstehen, solltest Du den Abschnitt "Arbeitsweise" im Kopf haben. Einerseits ist Dir vermutlich einleuchtend, dass ein Server, der per SSH rückwärts nur ausgewählte Kommandos in den Tunnel, den Du aufgebaut hast, leitet, "irgendwie sicherer" ist. Andererseits möchte man nicht blind vertrauen.

=== SSH ===
==== SSH - macht das nichts Gefährliches? ====
SSH ist ein Veteran des Internet und entstand, um sich sicher (verschlüsselt) und schnell auf Servern einzuloggen. Schon früh wurde dabei der sogenannte "Reverse-Tunnel" implementiert: Also der vom Client (Deinem Rechner) geäußerte Wunsch: "Bitte leite mir Requests, die bei Dir, Server, auf Port xy eingehen, an meinen lokalen Port yz weiter.". Dieses Verfahren implementiert der Reverseproxy, wobei tatsächlich auf dem Server für Dich kein echter Port geöffnet wird.

Wie Dir ggf. sicher der Unix-Guru Deines Vertrauens bestätigen wird: Die Kombination
<syntaxhighlight lang="bash" style="width:50%;">
ssh -R 1234:localhost:<zufälliger port> zielserver
</syntaxhighlight>
erlaubt keine Ausführung von Shell-Kommandos auf Deinem Server, sondern einzig, dass vom SSH-Programm Verbindungen zu einem lokalen Port auf Deinem Server auf dem alexa-fhem lauscht aufgebaut werden. Du kannst also z.B. mit einem
<syntaxhighlight lang="bash" style="width:50%;">
sudo /usr/sbin/tcpdump -X -s 0 -i lo port <zufälliger port>
</syntaxhighlight>
vollständig überwachen (oder ggf. permanent aufzeichen), was auf Deinem Server von außen gesteuert passiert.

==== Wie wird bei SSH verschlüsselt? ====
Im Prinzip wie im Web auf SSL-Seiten, teils mit den gleichen Verschlüsselungsverfahren. Allerdings arbeitet SSH eher wie das im Web recht seltene Verfahren: Bei jeder Verbindung übermitteln sowohl Server wie auch Client den öffentlichen Teil ihres Schlüssels. Anders als im Web wird der Schlüssel aber nicht von einer öffentlichen Zertifizierungsstelle wie "LetsEncrypt" unterschrieben. Stattdessen entscheiden Server wie Client beim ersten Verbindungsaufbau typischerweise per manueller Frage: "Willst Du jetzt und künftig diesem Schlüssel vertrauen?" Bei der Installation wird diese Frage für Deine Seite bejaht, und fortan wird der öffentliche Schlüssel des FHEM-Servers auf Deinem Rechner gespeichert. Ab da bist Du z.B. davor sicher, dass jemand den DNS-Eintrag verbiegt oder sich in den Datenfluss Deines Providers einhängt: Ein geänderter Serverschlüssel würde bemerkt werden.
 
Soweit klar? Aus Deinem öffentlichen Schlüssel wiederum leitet der Server her: "Das ist definitiv wieder derjenige, der sich damals "registriert" hat". Und an dieser Stelle kann ich auch den ersten Teil des 3-teiligen Registrierungskeys erläutern: Die typischerweise 6-stellige Hex-Zahl am Anfang ist der Java-Hashcode Deines öffentlichen Schlüssel. Sie ist damit sozusagen Deine aus Deinem öffentlichen Schlüssel abgeleitete Benutzer-ID.

=== Die Rolle der Secrets ===
Wenn jetzt klar ist, dass die Verbindung zum Vereinsserver sicher und vertauschungsfrei funktioniert, bleiben noch 2 Probleme zu lösen:
1) Im Web bei der Skill-Aktivierung musst Du beweisen, dass Du der Mensch am Browser bist, dem der SSH-Tunnel von IP xy mit dem öffentlichen Schlüssel X gehört. Bei der automatischen Registrierung werden lokal auf Deinem Rechner zwei 64-Bit-Secrets generiert:
* Das Anmelde-Secret
* Das Bearer-Token
Beim Anmelden des SSH-Keys auf dem öffentlichen Server wird nun der Hashwert des ersten Secrets übertragen und dort in Verbindung mit Deinem öffentlichen Schlüssel gespeichert. Ein Hashwert bedeutet, dass (sofern das Verfahren, hier SHA256, funktioniert), niemand aus dem Hash das Secret zurückrechnen kann. Ein Datenbankklau auf dem Server gefährdet also nicht die Sicherheit Deines Passwortes.

Wenn Du nun beim Skill-Aktivieren den Registrierungskey eingibst, dann "sieht" der Server zum ersten Mal Dein ausgewürfeltes Secret, vergleicht es mit dem Hashwert und wird es anschließend wieder umgehend vergessen. Anhand des Hashwertes kann der Server aber entscheiden, dass Du der legitime Nutzer zum öffentlichen Schlüssel XY bist.

2) Das zweite Problem ist: Wie soll Amazon "beweisen", dass sie der legitime Aufrufer sind? Amazon erhält binnen wenigen Sekunden nach dem Klick auf "Activate Skill" den dritten Teil des Registrierungskeys als sogenanntes Bearer-Token. Zwar läuft er durch den Registrierungsserver, er wird dort, auf dem Registrierungs/Vereinsserver aber nicht gespeichert. Das Bearer-Token wird von Amazon bei allen Requests zu Deinem Server mitgesendet. Da es am Anfang zusätzlich Deine "User-ID" enthält, weiß der Vereinsserver, zu welchem SSH-Tunnel der Request zu senden ist. Aber lokal auf Deinem Rechner wird ausgewertet, ob das Token "stimmt".

== alexa-fhem Updaten ==
* alexa-fhem über FHEM anhalten:
:<syntaxhighlight lang="perl" style="width:50%;">set alexa stop</syntaxhighlight>

*Auf der Konsole wie anfangs bei der Installation:
:<syntaxhighlight lang="bash" style="width:50%;">sudo npm update -g alexa-fhem</syntaxhighlight>

:Manchmal hat npm Probleme mit einem Update. Dann einfach die aktuelle Version noch mal drüber Installieren:

:<syntaxhighlight lang="bash" style="width:50%;">sudo npm install -g alexa-fhem</syntaxhighlight>

*alexa-fhem über FHEM wieder starten:
:<syntaxhighlight lang="perl" style="width:50%;">set alexa start</syntaxhighlight>

==Weitergehende Informationen==
*[[Alexa_und_Mappings]]
*[[Alexa_Tipps_und_Kniffe]]
[[Kategorie:HOWTOS]]
[[Kategorie:Sprachsteuerung]]

FHEM Connector für Amazon Alexa

2019-02-22T10:02:31Z

Sledge: Debugging etwas detaillierter beschrieben

{{Baustelle}}
'''Alexa FHEMlazy''' war historisch ein Fork des Original [[Alexa-Fhem|alexa-fhem]], der im Januar 2019 mit dem Original zusammengeführt wurde und nun als '''FHEM Connector''' verfügbar ist.

Er ermöglicht innerhalb von Minuten die Verknüpfung von FHEM mit einem Amazon Echo-Gerät.

Gegenüber dem klassischen Ansatz ergeben sich Einschränkungen, so läuft die Software normalerweise unter dem gleichen Benutzer wie FHEM auf dem gleichen Server, und es wird z.Zt. nur der Smarthome-Skill unterstützt (die Variante, bei der die Möglichkeiten der Interaktion von Amazon festgelegt wurden).
Dafür ist weder ein Developer-Account bei Amazon, eigene Lambda- und Skillfunktionen, noch das Öffnen eines eingehenden Ports aus dem Internet nötig.
* Die Software integriert einen Installer, der die Erstkonfiguration und Anmeldung übernimmt
* Die Kommunikation zur Software auf dem heimischen Rechner und dann zu FHEM verläuft über SSH und einen vom FHEM-Verein gehosteten Server
* Funktioniert mit IPv4, IPv6, echtem Dual Stack und DS-Lite
* Als Skill bei Amazon wird der Skill "FHEM Connector" verwendet.

Der Thread im Forum zur Software ist hier: {{Link2Forum|Topic=94817}}.

{{Infobox Modul
|ModPurpose=Einfache Anbindung von FHEM an Amazon Assistent Alexa
|ModType=h
|ModCmdRef=alexa
|ModTechName=39_alexa.pm / alexa-fhem
|ModForumArea=Frontends/Sprachsteuerung
|ModOwner=gvzdus, André/ justme1968 ({{Link2FU|430|Forum}} / [[Benutzer Diskussion:Justme|Wiki]])
}}

==Einführung==

===Arbeitsweise und Datenfluss===
Vorläufig ist alexa-fhem im "FHEM Connector-Modus" ein reiner [https://developer.amazon.com/de/docs/smarthome/understand-the-smart-home-skill-api.html SmartHome-Skill].
SmartHome-Skills erhalten weder die Sprachdaten selber noch das, was Amazon in Textform verstanden hat, sondern vielmehr extrahiert Amazon aus dem verstandenen Text Anweisungen und Abfragen für Geräte, die dann an den Skill übermittelt werden. Charmant ist dabei, dass unmittelbar gefragt werden kann "Alexa, wie ist die Temperatur im Wohnzimmer?", während andere Skills zunächst explizit angesprochen werden müssen ("Alexa, frage FHEM nach der Temperatur im Wohnzimmer"). Außerdem kann der Nutzer mehrere Smarthome-Skills installieren, und die Geräte werden zu einer Gesamtmenge zusammengefasst.

Gehen wir den Datenfluss bei der konkreten Frage "Wie ist die Temperatur im Wohnzimmer?" durch:
* Alexa hat bei der Skillinstallation gelernt, dass "FHEM Connector" bei Dir einen Thermostaten im Raum Wohnzimmer kennt. Dadurch wird bei der Sprachanalyse von "Alexa Voice Service" in der Cloud erkannt, dass eine Abfrage an "FHEM Connector" erfolgversprechend ist.
* Zunächst wird die zentrale "Lambda-Funktion" von "FHEM Connector" aufgerufen. Die Funktion leitet aber im Kern nur den Request unverändert an den vom Verein bereitgestellten Server weiter. Im Request enthalten ist ein Token, das sogenannte "Bearer-Token".
* Der "Vereinsserver" prüft anhand dieses Tokens, ob es überhaupt bekannt ist, und zu welchem Nutzer es gehört. Ist dieser Nutzer verbunden, wird der Request wiederum quasi unverändert an den Nutzer weitergeleitet.
* Diese Weiterleitung passiert über einen sogenannten SSH-Reverse-Tunnel, der von Deiner Seite und der Software auf dem FHEM-Tunnel automatisch aufgebaut wird.
* Auf Deiner Seite läuft die eigentliche Software, und zwar unter nodeJS. nodeJS ist ein Javascript ausführender Miniserver, der lokal auf Port 3000 auf Requests "lauscht". In der Original-Version [[Alexa-Fhem|Alexa FHEM]] kommen die Requests aus dem Internet (hoffentlich von der eigenen Lambda-Funktion), hier bei "FHEM Connector" kommen sie ausschließlich aus dem SSH-Tunnel von lokal.
* Die Software validiert nun diesen Request anhand des Bearer-Tokens. Konkret wird dabei das bei der Installation generierte Token, dass bei der Skill-Aktivierung an Amazon übertragen wurde, mit dem lokal gespeicherten Wert verglichen. Stimmt das Token, wird der Befehl verarbeitet, üblicherweise wird hierbei ein Aufruf an die Webschnittstelle von FHEM abgesetzt.
* FHEM führt den Befehl aus

Hört sich langsam und kompliziert an? Kompliziert: Okay. Langsam eher nicht, in etlichen Fällen liegt die Gesamtantwortszeit unter 200 ms.

Soweit ein erster Überblick über die Datenflüsse. Im Abschnitt Sicherheit ist das Konzept der Absicherung deutlich genauer und ausführlicher beschrieben.

==Installation==

Du wirst bei der Installation zuerst auf der Kommandozeile auf Deinem Raspberry (o.ä.) unterwegs sein, anschließend im Webfrontend von FHEM, und zum Schluss auf der Alexa-Konsole im Web.

===node.js installieren===

Bei Jessy liegt NodeJS bereits in einer ausreichend aktuellen Version vor. Mit

<syntaxhighlight lang="bash" style="width:50%;">
sudo apt-get install nodejs npm
</syntaxhighlight>

kannst Du es installieren. Mit
<syntaxhighlight lang="bash" style="width:50%;">
node --version
</syntaxhighlight>

erfährst Du die aktuelle Version - wenn hier etwas mit "8" vorneweg erscheint, ist alles gut.
Ansonsten suche Dir bitte eine Anleitung im Web, wie Du NodeJS auf Deinem System auf einen aktuellen Stand bringen kannst.

=== Alexa-FHEM installieren ===

Nun installieren wir Alexa-fhem aus dem offiziellen Repository:

<syntaxhighlight lang="bash" style="width:50%;">
sudo npm install -g alexa-fhem
</syntaxhighlight>

Der Vorgang benötigt etwas Zeit.

=== Alexa-FHEM aktivieren ===

Wechsele jetzt in FHEM-Web!

Wichtig ist, dass das Alexa-Modul in der Version ab 14. Januar 2019 vorliegt. Dafür bitte einmal FHEM aktualisieren:
Speichern der Config nicht vergessen, und

<syntaxhighlight lang="bash" style="width:50%;">
update
shutdown restart
</syntaxhighlight>

Alles, was jetzt noch nötig ist, ist das Anlegen eines Alexa-Devices. Gib dafür in der FHEM-Web-Kommandozeile

<syntaxhighlight lang="bash" style="width:50%;">
define alexa alexa
</syntaxhighlight>

an. Nun läuft, während Du bereits das neu angelegte Alexa-Devices siehst, ein komplexer Prozess im Hintergrund:

* Falls noch kein SSH-Key für den Benutzer, unter dem FHEM läuft, existiert, wird einer generiert
* Es wird ein Secret-Key im Prozess generiert, dass den Server nicht verlässt, und der Skillanmeldung dient.
* Du wirst auf dem Server "va-fhem.fhem.de" des FHEM-Vereins mit dem SSH-Key angemeldet, und der Hash-Wert Deines Secret-Key dort abgelegt.

Und wenn Du diese Sätze gelesen hast, sollte inzwischen sich das Alexa-Device in FHEM-Web aktualisiert haben, und
ungefähr so aussehen:

[[Datei:Alexa-Device-2.png|800px]]

Neben dem Status für alexa-fhem und der Proxyverbindung ist wichtig, dass diese beiden Zeilen beim Reload aufgetaucht sind:

<syntaxhighlight lang="bash" style="width:90%;">
alexaFHEM.bearerToken crypt:...
alexaFHEM.skillRegKey crypt:...
</syntaxhighlight>

Ja, und diesen Schlüssel benötigst Du wirklich! Also am besten schon einmal mit

<syntaxhighlight lang="bash" style="width:90%;">
get <alexa> proxyKey
</syntaxhighlight>

in Klartext anzeigen lassen und in ein Editor-Fenster dauerhaft wegsichern.

Während kompliziertere Fehlerfälle im Abschnitt "Mögliche Probleme und Lösungen" behandelt werden, hier häufige Fälle, warum die kryptischen Zeilen nicht auftauchen:

* Zuerst bitte einfach einmal die Seite neu laden.

* Wenn Du FHEM-Web mit einem User/Passwort-Schutz versehen hast, musst Du i.d.R. diese Angaben noch einmal explizit setzen: Im attribute-Abschnitt "alexaFHEM-auth" auswählen, User/Passwort mit ":" getrennt angeben und "attr" anklicken. alexa-fhem wird automatisch neu gestartet. Hier das Ganze in der Text-Variante:

<syntaxhighlight lang="bash" style="width:90%;">
attr alexa alexaFHEM-auth user:pass
</syntaxhighlight>

Hast Du noch die Shell-Konsole offen?

Dann prüfe bitte noch einmal auf der Konsole, ob nun zwei Prozesse laufen:
<syntaxhighlight lang="bash" style="width:50%;">
ps -ef | egrep '(alexa|ssh)'
</syntaxhighlight>

sollte Dir idealerweise so etwas anzeigen:
<syntaxhighlight lang="bash" style="width:90%;">
fhem 31322 1 99 13:56 ? 00:00:03 alexa
fhem 31332 31322 8 13:56 ? 00:00:00 /usr/bin/ssh -R 1234:127.0.0.1:<zufälliger port> -oServerAliveInterval=90 -p 58824 fhem-va.fhem.de
</syntaxhighlight>

"alexa" ist dabei der Node-JS-Prozess, der ssh-Prozess ist die aufgebaute Verbindung zum Vereinsserver.

Wenn Du diese Prozesse '''nicht''' siehst oder das Alexa-Device keinen Registrierungskey anzeigt, dann ist leider der Start nicht glatt verlaufen.

Im Logfile (über den link <code>Logfile</code> in der Detail-Ansicht über <code>set</Code>, oder über den Namen bei <it>currentlogfile</it> in den Internals) findest Du idealerweise selber Hinweise, wo es hakt, oder kannst im Forum nachfragen.

Jetzt solltest Du Dein Alexa-Device nicht mehr löschen, denn das im Reading angezeigte "bearerToken" zu löschen bedeutet, dass die Software die Zugriffe von nicht mehr überprüfen kann und keine Kommandos mehr funktionieren. In diesem Fall hilft nur die Neuinstallation des Skills.

=== Geräte im FHEM-Webfrontend zuweisen ===
Um das Aha-Erlebnis zu vergrößern, ist jetzt ein guter Zeitpunkt, 1 oder besser mind. 2 Geräte für den Alexa-Dienst zuzuweisen. Von Haus aus wird keines Deiner FHEM-Geräte automatisch Alexa zugewiesen!

Wähle die Geräte aus, rufe sie auf und setze das Attribut "alexaName". Hierbei in Kürze nur der Hinweis:
* Keine Angst vor Leerzeichen und Umlauten, funktioniert.
* Große Angst vor Rechtschreibfehlern (Terrasse, Rollladen) oder komplizierten Wörtern "handgebastelte Martinslaterne im Kinderzimmer Iphigenie-Chantal".

Lade die Geräte neu in die Software, indem Du <code>set <alexa> restart</code> ausführst!

== Finale: Skill verknüpfen ==
Suche im WebFrontend oder der Alexa-App den Skill "FHEM Connector". Für nicht-Mac/iOS Anwerder empfiehlt das WebFrontend (https://alexa.amazon.de) statt die App, damit Du den Anmeldeschlüssel auch bequem kopieren kannst.

Wenn du noch nicht bei Amazon angemeldet bist, erwartet Amazon zunächst, dass Du Dich normal bei Amazon anmeldest.

Sobald Du "FHEM Connector" aktivierst, öffnet sich ein Browser-Tab mit folgender Maske: 
[[Datei:FHEMlazy_login.png|240px]]

Hier kopierst Du Deinen Anmeldeschlüssel (im Klartext!) hinein und klickst auf Check. Als glücklicher Mensch ist auf der folgenden Statusseite alles grün: 
[[Datei:FHEMlazy_check.png|240px]]

Im Einzelnen wird hier geprüft, ob Du per SSH verbunden bist (und auch Deine IP zur Sicherheit angezeigt), ob der Reverse-Tunnel steht, ob nodeJS erreichbar ist und wie viele Geräte Alexa gleich finden sollte (in meinem Fall 22).

Sollte etwas nicht grün sein und Du eine Idee zum Fixen haben, kannst Du mit "Retry" neue Versuche auslösen.

Ist alles okay, klicke rechts den Button "Activate Skill". Du springst damit wieder zurück zu Amazon, die Dir hoffentlich zur erfolgreichen Verknüpfung gratulieren.

Amazon möchte nun unmittelbar die Gerätesuche starten, und unter SmartHome-Geräte sollten diese nun auftauchen.

== Was geht alles ? ==

* Geräte, die sich ein- und ausschalten lassen:
** Automatisch: Müssen <code>set on</code> und <code>set off</code> Kommandos haben
** dummys müssen <code>setList</code> mit on und off haben
** Über <code>genericDeviceType</code> switch bzw. light kann bestimmt werden ob es in alexa als Schalter oder Licht behandelt wird.
** Wenn die Set-Kommandos im FHEM Device anders benannt sind: hombridgeMapping On:cmdOn=<ein>,CmdOff=<aus> setzen
** Kommandos:
***Alexa, schalte <name> ein/aus
***Alexa, Licht an/aus
***Alexa, schalte <gruppe> ein/aus

* Geräte, die eine Temperatur messen
** Automatisch: Es muss ein Reading temperature geben
** Über <code>genericDeviceType</code> thermometer
** Sonst: hombridgeMapping CurrentTemperature:reading=<reading>

* Geräte, deren Helligkeit sich ändern lässt
** Automatisch: wenn <code>dim</code> oder <code>pct</code> Kommandos erkannt werden
** Über <code>genericDeviceType</code> light
** ...
**Kommandos:
***Alexa, mache <name> heller/dunkler
***Alexa, Licht heller/dunkler

* Geräte, deren Farbe sich ändern lässt
** ...

* Geräte, deren Farbtemperatur sich ändern lässt
** ...

* Geräte, bei denen sich eine Lautstärke einstellen lässt
** ...

* Geräte, bei denen sich ein prozentualer Wert einstellen lässt
** Automatisch: wenn <code>dim</code> oder <code>pct</code> Kommandos erkannt werden
** ...

* elektrische Türschlösser
** <code>genericDeviceType</code>: lock

* Thermostate
** Über <code>genericDeviceType</code> thermometer
** ...

* structure Devices aus FHEM (ab alexa-fhem version 0.5.7)
** werden mit <code>genericDeviceType</code> scene als Szene eingebunden
** über <code>alexaRoom</code> kann der name um einen Ort ergänzt werden
** Szenen aus einer structure lassen sich ein- und ausschalten
** Wichtig:
*** Ein Skill darf nur 12 Szenen automatisch erkennen und einbinden.
*** Ist der Typ "scene" nicht vorhanden, muss er manuell zum ''Global''-Device hinzugefügt werden: <code>attr global userattr genericDeviceType:switch,outlet,light,blind,scene,speaker,thermostat, ...</code>

* LightScene Devices aus FHEM (ab alexa-fhem version 0.5.8)
** werden mit <code>genericDeviceType</code> scene als Szenen eingebunden
** über <code>alexaRoom</code> kann der name um einen Ort ergänzt werden
** Szenen aus einer LightScene lassen sich nur einschalten
** Wichtig:
*** Ein Skill darf nur 12 Szenen automatisch erkennen und einbinden.
*** Ist der Typ "scene" nicht vorhanden, siehe ''structure''

* Geräte, deren Kanal sich umschalten lässt (ab alexa-fhem version 0.5.13)
** Über <code>genericDeviceType</code> media
** hombridgeMapping ChannelController:reading=<reading>,cmd=<cmd>
** Erlaubte Werte siehe hier: https://developer.amazon.com/de/docs/device-apis/alexa-channelcontroller.html#changechannel
** ...

* Geräte, deren Playback status sich schalten lässt (ab alexa-fhem version 0.5.13)
** Über <code>genericDeviceType</code> media
** hombridgeMapping PlaybackController:playback,values=Play;Pause;Stop;Previous;Next
** Erlaubte Werte siehe hier: https://developer.amazon.com/de/docs/device-apis/alexa-playbackcontroller.html#discovery
** ...

* Geräte, deren Eingang sich umschalten lässt (ab alexa-fhem version 0.5.13)
** Über <code>genericDeviceType</code> media
** hombridgeMapping InputController:reading=<reading>:cmd=<cmd>,values=HDMI+1;HDMI+2;XBOX
** Erlaubte Werte siehe hier: https://developer.amazon.com/de/docs/device-apis/alexa-property-schemas.html#input
** ...

* Kontaktsensoren (ab alexa-fhem version 0.5.15)
** Über <code>genericDeviceType</code> contact
** hombridgeMapping ContactSensorState:reading=<reading> oder CurrentDoorState:reading=<reading>
** Die Anzeige in der Alexa-App funktioniert schon, die Abfrage per Sprache noch nicht.

Es werden noch einige andere häufig verwendete Geräte (Homematic, hue,...) automatisch erkannt.

to be continued ...

In der [https://developer.amazon.com/docs/device-apis/list-of-interfaces.html List of Capability Interfaces] bei Amazon kann man sehen, welche Möglichkeiten das Smart Home Skill API aktuell in einzelnen Ländern bietet. Leider ohne die jeweiligen landessprachlichen Kommandos.

== Mögliche Probleme und Lösungen ==

Es kann vorkommen, dass Geräte zwar korrekt erkannt werden, aber das durch Alexa erkannte Kommando nicht richtig umgesetzt wird (Beispiel - mittlerweile behoben: {{Link2Forum|Topic=96766}}). Neben dem FHEM-Log gibt es noch das Logfile, welches von alexa-fhem angelegt wird.

=== Fehlersuche über die FHEM-Oberfläche ===

* alexa-fhem Logfile anschauen (Detail-Ansicht des <alexa>-Device aufrufen, klick auf '''Logfile''' oben)
* alexa-fhem im Debug-Modus aufrufen:
** -D zum alexaFHEM-params attribut hinzufügen
** Alexa-Befehl auslösen
** -D aus dem alexaFHEM-params attribut entfernen
* Die notwendigen Informationen finden sich in dem alexa-Logfile (siehe oben)

=== Fehlersuche über Kommandozeile (lies: Shell) + FHEM-Oberfläche ===

:* set <alexa> stop (FHEM-Oberfläche)
:* Auf der Kommandozeile <code>alexa-fhem -D -c /opt/fhem/alexa-fhem.cfg > debug.log</code> starten (dadurch wird die Datei debug.log erzeugt im aktuellen Verzeichnis)
:* Alexa-Befehl auslösen
:* alexa-fhem auf der Kommandozeile wieder stoppen (CTRL-C)
:* set <alexa> start (FHEM-Oberfläche)

Die Datei debug.log sollte Hinweise enthalten, wie das Problem zu lösen ist oder Dich zumindest in die richtige Richtung schieben.

Im Beispiel aus dem Forum fand sich in dem Logfile der Hinweis darauf, dass das Device mit falschen min/max-Werten unterwegs war.

=== Registrierungskey vergessen, Registrierung zurücksetzen ===

Auf der Kommandoshell:

<syntaxhighlight lang="bash" style="width:90%;">
pi@raspberrypi:~# sudo -u fhem ssh -p 58824 fhem-va.fhem.de status
Registered.
Registered on 2019-01-13T15:38:13Z.
</syntaxhighlight>

heisst, das der Vereinsserver eigentlich alles hat, was er will. Es wird kein neuer Schlüssel generiert.
Wenn Du die Situation zurücksetzen möchtest, wäre die hässliche Methode, Deinen SSH-Key zu löschen. Eleganter ist, die Registrierung auf Vereinsseite zu löschen:

<syntaxhighlight lang="bash" style="width:90%;">
pi@raspberrypi:~# sudo -u fhem ssh -p 58824 fhem-va.fhem.de unregister
Your registration has been removed
</syntaxhighlight>

löscht Deinen Schlüssel mitsamt allen dort gespeicherten Daten auf Vereinsseite. Bei Restart von alexa-fhem in FHEM-WEB wird jetzt ein neuer Registrierungskey angefordert.

== Sicherheitskonzept und Secrets ==

Um diesen Abschnitt zu verstehen, solltest Du den Abschnitt "Arbeitsweise" im Kopf haben. Einerseits ist Dir vermutlich einleuchtend, dass ein Server, der per SSH rückwärts nur ausgewählte Kommandos in den Tunnel, den Du aufgebaut hast, leitet, "irgendwie sicherer" ist. Andererseits möchte man nicht blind vertrauen.

=== SSH ===
==== SSH - macht das nichts Gefährliches? ====
SSH ist ein Veteran des Internet und entstand, um sich sicher (verschlüsselt) und schnell auf Servern einzuloggen. Schon früh wurde dabei der sogenannte "Reverse-Tunnel" implementiert: Also der vom Client (Deinem Rechner) geäußerte Wunsch: "Bitte leite mir Requests, die bei Dir, Server, auf Port xy eingehen, an meinen lokalen Port yz weiter.". Dieses Verfahren implementiert der Reverseproxy, wobei tatsächlich auf dem Server für Dich kein echter Port geöffnet wird.

Wie Dir ggf. sicher der Unix-Guru Deines Vertrauens bestätigen wird: Die Kombination
<syntaxhighlight lang="bash" style="width:50%;">
ssh -R 1234:localhost:<zufälliger port> zielserver
</syntaxhighlight>
erlaubt keine Ausführung von Shell-Kommandos auf Deinem Server, sondern einzig, dass vom SSH-Programm Verbindungen zu einem lokalen Port auf Deinem Server auf dem alexa-fhem lauscht aufgebaut werden. Du kannst also z.B. mit einem
<syntaxhighlight lang="bash" style="width:50%;">
sudo /usr/sbin/tcpdump -X -s 0 -i lo port <zufälliger port>
</syntaxhighlight>
vollständig überwachen (oder ggf. permanent aufzeichen), was auf Deinem Server von außen gesteuert passiert.

==== Wie wird bei SSH verschlüsselt? ====
Im Prinzip wie im Web auf SSL-Seiten, teils mit den gleichen Verschlüsselungsverfahren. Allerdings arbeitet SSH eher wie das im Web recht seltene Verfahren: Bei jeder Verbindung übermitteln sowohl Server wie auch Client den öffentlichen Teil ihres Schlüssels. Anders als im Web wird der Schlüssel aber nicht von einer öffentlichen Zertifizierungsstelle wie "LetsEncrypt" unterschrieben. Stattdessen entscheiden Server wie Client beim ersten Verbindungsaufbau typischerweise per manueller Frage: "Willst Du jetzt und künftig diesem Schlüssel vertrauen?" Bei der Installation wird diese Frage für Deine Seite bejaht, und fortan wird der öffentliche Schlüssel des FHEM-Servers auf Deinem Rechner gespeichert. Ab da bist Du z.B. davor sicher, dass jemand den DNS-Eintrag verbiegt oder sich in den Datenfluss Deines Providers einhängt: Ein geänderter Serverschlüssel würde bemerkt werden.
 
Soweit klar? Aus Deinem öffentlichen Schlüssel wiederum leitet der Server her: "Das ist definitiv wieder derjenige, der sich damals "registriert" hat". Und an dieser Stelle kann ich auch den ersten Teil des 3-teiligen Registrierungskeys erläutern: Die typischerweise 6-stellige Hex-Zahl am Anfang ist der Java-Hashcode Deines öffentlichen Schlüssel. Sie ist damit sozusagen Deine aus Deinem öffentlichen Schlüssel abgeleitete Benutzer-ID.

=== Die Rolle der Secrets ===
Wenn jetzt klar ist, dass die Verbindung zum Vereinsserver sicher und vertauschungsfrei funktioniert, bleiben noch 2 Probleme zu lösen:
1) Im Web bei der Skill-Aktivierung musst Du beweisen, dass Du der Mensch am Browser bist, dem der SSH-Tunnel von IP xy mit dem öffentlichen Schlüssel X gehört. Bei der automatischen Registrierung werden lokal auf Deinem Rechner zwei 64-Bit-Secrets generiert:
* Das Anmelde-Secret
* Das Bearer-Token
Beim Anmelden des SSH-Keys auf dem öffentlichen Server wird nun der Hashwert des ersten Secrets übertragen und dort in Verbindung mit Deinem öffentlichen Schlüssel gespeichert. Ein Hashwert bedeutet, dass (sofern das Verfahren, hier SHA256, funktioniert), niemand aus dem Hash das Secret zurückrechnen kann. Ein Datenbankklau auf dem Server gefährdet also nicht die Sicherheit Deines Passwortes.

Wenn Du nun beim Skill-Aktivieren den Registrierungskey eingibst, dann "sieht" der Server zum ersten Mal Dein ausgewürfeltes Secret, vergleicht es mit dem Hashwert und wird es anschließend wieder umgehend vergessen. Anhand des Hashwertes kann der Server aber entscheiden, dass Du der legitime Nutzer zum öffentlichen Schlüssel XY bist.

2) Das zweite Problem ist: Wie soll Amazon "beweisen", dass sie der legitime Aufrufer sind? Amazon erhält binnen wenigen Sekunden nach dem Klick auf "Activate Skill" den dritten Teil des Registrierungskeys als sogenanntes Bearer-Token. Zwar läuft er durch den Registrierungsserver, er wird dort, auf dem Registrierungs/Vereinsserver aber nicht gespeichert. Das Bearer-Token wird von Amazon bei allen Requests zu Deinem Server mitgesendet. Da es am Anfang zusätzlich Deine "User-ID" enthält, weiß der Vereinsserver, zu welchem SSH-Tunnel der Request zu senden ist. Aber lokal auf Deinem Rechner wird ausgewertet, ob das Token "stimmt".

== alexa-fhem Updaten ==
* alexa-fhem über FHEM anhalten:
:<syntaxhighlight lang="perl" style="width:50%;">set alexa stop</syntaxhighlight>

*Auf der Konsole wie anfangs bei der Installation:
:<syntaxhighlight lang="bash" style="width:50%;">sudo npm update -g alexa-fhem</syntaxhighlight>

:Manchmal hat npm Probleme mit einem Update. Dann einfach die aktuelle Version noch mal drüber Installieren:

:<syntaxhighlight lang="bash" style="width:50%;">sudo npm install -g alexa-fhem</syntaxhighlight>

*alexa-fhem über FHEM wieder starten:
:<syntaxhighlight lang="perl" style="width:50%;">set alexa start</syntaxhighlight>

==Weitergehende Informationen==
*[[Alexa_und_Mappings]]
*[[Alexa_Tipps_und_Kniffe]]
[[Kategorie:HOWTOS]]
[[Kategorie:Sprachsteuerung]]

FHEM Connector für Amazon Alexa

2019-01-31T20:10:12Z

Sledge: Kapitel über Fehlersuche befüllt

{{Baustelle}}
'''Alexa FHEMlazy''' war historisch ein Fork des Original [[Alexa-Fhem|alexa-fhem]], der im Januar 2019 mit dem Original zusammengeführt wurde und nun als '''FHEM Connector''' verfügbar ist.

Er ermöglicht innerhalb von Minuten die Verknüpfung von FHEM mit einem Amazon Echo-Gerät.

Gegenüber dem klassischen Ansatz ergeben sich Einschränkungen, so läuft die Software normalerweise unter dem gleichen Benutzer wie FHEM auf dem gleichen Server, und es wird z.Zt. nur der Smarthome-Skill unterstützt (die Variante, bei der die Möglichkeiten der Interaktion von Amazon festgelegt wurden).
Dafür ist weder ein Developer-Account bei Amazon, eigene Lambda- und Skillfunktionen, noch das Öffnen eines eingehenden Ports aus dem Internet nötig.
* Die Software integriert einen Installer, der die Erstkonfiguration und Anmeldung übernimmt
* Die Kommunikation zur Software auf dem heimischen Rechner und dann zu FHEM verläuft über SSH und einen vom FHEM-Verein gehosteten Server
* Funktioniert mit IPv4, IPv6, echtem Dual Stack und DS-Lite
* Als Skill bei Amazon wird der Skill "FHEM Connector" verwendet.

Der Thread im Forum zur Software ist hier: {{Link2Forum|Topic=94817}}.

{{Infobox Modul
|ModPurpose=Einfache Anbindung von FHEM an Amazon Assistent Alexa
|ModType=h
|ModCmdRef=alexa
|ModTechName=39_alexa.pm / alexa-fhem
|ModForumArea=Frontends/Sprachsteuerung
|ModOwner=gvzdus, André/ justme1968 ({{Link2FU|430|Forum}} / [[Benutzer Diskussion:Justme|Wiki]])
}}

==Einführung==

===Arbeitsweise und Datenfluss===
Vorläufig ist alexa-fhem im "FHEM Connector-Modus" ein reiner [https://developer.amazon.com/de/docs/smarthome/understand-the-smart-home-skill-api.html SmartHome-Skill].
SmartHome-Skills erhalten weder die Sprachdaten selber noch das, was Amazon in Textform verstanden hat, sondern vielmehr extrahiert Amazon aus dem verstandenen Text Anweisungen und Abfragen für Geräte, die dann an den Skill übermittelt werden. Charmant ist dabei, dass unmittelbar gefragt werden kann "Alexa, wie ist die Temperatur im Wohnzimmer?", während andere Skills zunächst explizit angesprochen werden müssen ("Alexa, frage FHEM nach der Temperatur im Wohnzimmer"). Außerdem kann der Nutzer mehrere Smarthome-Skills installieren, und die Geräte werden zu einer Gesamtmenge zusammengefasst.

Gehen wir den Datenfluss bei der konkreten Frage "Wie ist die Temperatur im Wohnzimmer?" durch:
* Alexa hat bei der Skillinstallation gelernt, dass "FHEM Connector" bei Dir einen Thermostaten im Raum Wohnzimmer kennt. Dadurch wird bei der Sprachanalyse von "Alexa Voice Service" in der Cloud erkannt, dass eine Abfrage an "FHEM Connector" erfolgversprechend ist.
* Zunächst wird die zentrale "Lambda-Funktion" von "FHEM Connector" aufgerufen. Die Funktion leitet aber im Kern nur den Request unverändert an den vom Verein bereitgestellten Server weiter. Im Request enthalten ist ein Token, das sogenannte "Bearer-Token".
* Der "Vereinsserver" prüft anhand dieses Tokens, ob es überhaupt bekannt ist, und zu welchem Nutzer es gehört. Ist dieser Nutzer verbunden, wird der Request wiederum quasi unverändert an den Nutzer weitergeleitet.
* Diese Weiterleitung passiert über einen sogenannten SSH-Reverse-Tunnel, der von Deiner Seite und der Software auf dem FHEM-Tunnel automatisch aufgebaut wird.
* Auf Deiner Seite läuft die eigentliche Software, und zwar unter nodeJS. nodeJS ist ein Javascript ausführender Miniserver, der lokal auf Port 3000 auf Requests "lauscht". In der Original-Version [[Alexa-Fhem|Alexa FHEM]] kommen die Requests aus dem Internet (hoffentlich von der eigenen Lambda-Funktion), hier bei "FHEM Connector" kommen sie ausschließlich aus dem SSH-Tunnel von lokal.
* Die Software validiert nun diesen Request anhand des Bearer-Tokens. Konkret wird dabei das bei der Installation generierte Token, dass bei der Skill-Aktivierung an Amazon übertragen wurde, mit dem lokal gespeicherten Wert verglichen. Stimmt das Token, wird der Befehl verarbeitet, üblicherweise wird hierbei ein Aufruf an die Webschnittstelle von FHEM abgesetzt.
* FHEM führt den Befehl aus

Hört sich langsam und kompliziert an? Kompliziert: Okay. Langsam eher nicht, in etlichen Fällen liegt die Gesamtantwortszeit unter 200 ms.

Soweit ein erster Überblick über die Datenflüsse. Im Abschnitt Sicherheit ist das Konzept der Absicherung deutlich genauer und ausführlicher beschrieben.

==Installation==

Du wirst bei der Installation zuerst auf der Kommandozeile auf Deinem Raspberry (o.ä.) unterwegs sein, anschließend im Webfrontend von FHEM, und zum Schluss auf der Alexa-Konsole im Web.

===node.js installieren===

Bei Jessy liegt NodeJS bereits in einer ausreichend aktuellen Version vor. Mit

<syntaxhighlight lang="bash" style="width:50%;">
sudo apt-get install nodejs npm
</syntaxhighlight>

kannst Du es installieren. Mit
<syntaxhighlight lang="bash" style="width:50%;">
node --version
</syntaxhighlight>

erfährst Du die aktuelle Version - wenn hier etwas mit "8" vorneweg erscheint, ist alles gut.
Ansonsten suche Dir bitte eine Anleitung im Web, wie Du NodeJS auf Deinem System auf einen aktuellen Stand bringen kannst.

=== Alexa-FHEM installieren ===

Nun installieren wir Alexa-fhem aus dem offiziellen Repository:

<syntaxhighlight lang="bash" style="width:50%;">
sudo npm install -g alexa-fhem
</syntaxhighlight>

Der Vorgang benötigt etwas Zeit.

=== Alexa-FHEM aktivieren ===

Wechsele jetzt in FHEM-Web!

Wichtig ist, dass das Alexa-Modul in der Version ab 14. Januar 2019 vorliegt. Dafür bitte einmal FHEM aktualisieren:
Speichern der Config nicht vergessen, und

<syntaxhighlight lang="bash" style="width:50%;">
update
shutdown restart
</syntaxhighlight>

Alles, was jetzt noch nötig ist, ist das Anlegen eines Alexa-Devices. Gib dafür in der FHEM-Web-Kommandozeile

<syntaxhighlight lang="bash" style="width:50%;">
define alexa alexa
</syntaxhighlight>

an. Nun läuft, während Du bereits das neu angelegte Alexa-Devices siehst, ein komplexer Prozess im Hintergrund:

* Falls noch kein SSH-Key für den Benutzer, unter dem FHEM läuft, existiert, wird einer generiert
* Es wird ein Secret-Key im Prozess generiert, dass den Server nicht verlässt, und der Skillanmeldung dient.
* Du wirst auf dem Server "va-fhem.fhem.de" des FHEM-Vereins mit dem SSH-Key angemeldet, und der Hash-Wert Deines Secret-Key dort abgelegt.

Und wenn Du diese Sätze gelesen hast, sollte inzwischen sich das Alexa-Device in FHEM-Web aktualisiert haben, und
ungefähr so aussehen:

[[Datei:Alexa-Device-2.png|800px]]

Neben dem Status für alexa-fhem und der Proxyverbindung ist wichtig, dass diese beiden Zeilen beim Reload aufgetaucht sind:

<syntaxhighlight lang="bash" style="width:90%;">
alexaFHEM.bearerToken crypt:...
alexaFHEM.skillRegKey crypt:...
</syntaxhighlight>

Ja, und diesen Schlüssel benötigst Du wirklich! Also am besten schon einmal mit

<syntaxhighlight lang="bash" style="width:90%;">
get <alexa> proxyKey
</syntaxhighlight>

in Klartext anzeigen lassen und in ein Editor-Fenster dauerhaft wegsichern.

Während kompliziertere Fehlerfälle im Abschnitt "Mögliche Probleme und Lösungen" behandelt werden, hier häufige Fälle, warum die kryptischen Zeilen nicht auftauchen:

* Zuerst bitte einfach einmal die Seite neu laden.

* Wenn Du FHEM-Web mit einem User/Passwort-Schutz versehen hast, musst Du i.d.R. diese Angaben noch einmal explizit setzen: Im attribute-Abschnitt "alexaFHEM-auth" auswählen, User/Passwort mit ":" getrennt angeben und "attr" anklicken. alexa-fhem wird automatisch neu gestartet. Hier das Ganze in der Text-Variante:

<syntaxhighlight lang="bash" style="width:90%;">
attr alexa alexaFHEM-auth user:pass
</syntaxhighlight>

Hast Du noch die Shell-Konsole offen?

Dann prüfe bitte noch einmal auf der Konsole, ob nun zwei Prozesse laufen:
<syntaxhighlight lang="bash" style="width:50%;">
ps -ef | egrep '(alexa|ssh)'
</syntaxhighlight>

sollte Dir idealerweise so etwas anzeigen:
<syntaxhighlight lang="bash" style="width:90%;">
fhem 31322 1 99 13:56 ? 00:00:03 alexa
fhem 31332 31322 8 13:56 ? 00:00:00 /usr/bin/ssh -R 1234:127.0.0.1:<zufälliger port> -oServerAliveInterval=90 -p 58824 fhem-va.fhem.de
</syntaxhighlight>

"alexa" ist dabei der Node-JS-Prozess, der ssh-Prozess ist die aufgebaute Verbindung zum Vereinsserver.

Wenn Du diese Prozesse '''nicht''' siehst oder das Alexa-Device keinen Registrierungskey anzeigt, dann ist leider der Start nicht glatt verlaufen.

Im Logfile (über den link <code>Logfile</code> in der Detail-Ansicht über <code>set</Code>, oder über den Namen bei <it>currentlogfile</it> in den Internals) findest Du idealerweise selber Hinweise, wo es hakt, oder kannst im Forum nachfragen.

Jetzt solltest Du Dein Alexa-Device nicht mehr löschen, denn das im Reading angezeigte "bearerToken" zu löschen bedeutet, dass die Software die Zugriffe von nicht mehr überprüfen kann und keine Kommandos mehr funktionieren. In diesem Fall hilft nur die Neuinstallation des Skills.

=== Geräte im FHEM-Webfrontend zuweisen ===
Um das Aha-Erlebnis zu vergrößern, ist jetzt ein guter Zeitpunkt, 1 oder besser mind. 2 Geräte für den Alexa-Dienst zuzuweisen. Von Haus aus wird keines Deiner FHEM-Geräte automatisch Alexa zugewiesen!

Wähle die Geräte aus, rufe sie auf und setze das Attribut "alexaName". Hierbei in Kürze nur der Hinweis:
* Keine Angst vor Leerzeichen und Umlauten, funktioniert.
* Große Angst vor Rechtschreibfehlern (Terrasse, Rollladen) oder komplizierten Wörtern "handgebastelte Martinslaterne im Kinderzimmer Iphigenie-Chantal".

Lade die Geräte neu in die Software, indem Du <code>set <alexa> restart</code> ausführst!

== Finale: Skill verknüpfen ==
Suche im WebFrontend oder der Alexa-App den Skill "FHEM Connector". Für nicht-Mac/iOS Anwerder empfiehlt das WebFrontend (https://alexa.amazon.de) statt die App, damit Du den Anmeldeschlüssel auch bequem kopieren kannst.

Wenn du noch nicht bei Amazon angemeldet bist, erwartet Amazon zunächst, dass Du Dich normal bei Amazon anmeldest.

Sobald Du "FHEM Connector" aktivierst, öffnet sich ein Browser-Tab mit folgender Maske: 
[[Datei:FHEMlazy_login.png|240px]]

Hier kopierst Du Deinen Anmeldeschlüssel (im Klartext!) hinein und klickst auf Check. Als glücklicher Mensch ist auf der folgenden Statusseite alles grün: 
[[Datei:FHEMlazy_check.png|240px]]

Im Einzelnen wird hier geprüft, ob Du per SSH verbunden bist (und auch Deine IP zur Sicherheit angezeigt), ob der Reverse-Tunnel steht, ob nodeJS erreichbar ist und wie viele Geräte Alexa gleich finden sollte (in meinem Fall 22).

Sollte etwas nicht grün sein und Du eine Idee zum Fixen haben, kannst Du mit "Retry" neue Versuche auslösen.

Ist alles okay, klicke rechts den Button "Activate Skill". Du springst damit wieder zurück zu Amazon, die Dir hoffentlich zur erfolgreichen Verknüpfung gratulieren.

Amazon möchte nun unmittelbar die Gerätesuche starten, und unter SmartHome-Geräte sollten diese nun auftauchen.

== Was geht alles ? ==

* Geräte, die sich ein- und ausschalten lassen:
** Automatisch: Müssen <code>set on</code> und <code>set off</code> Kommandos haben
** dummys müssen <code>setList</code> mit on und off haben
** Über <code>genericDeviceType</code> switch bzw. light kann bestimmt werden ob es in alexa als Schalter oder Licht behandelt wird.
** Wenn die Set-Kommandos im FHEM Device anders benannt sind: hombridgeMapping On:cmdOn=<ein>,CmdOff=<aus> setzen
** Kommandos:
***Alexa, schalte <name> ein/aus
***Alexa, Licht an/aus
***Alexa, schalte <gruppe> ein/aus

* Geräte, die eine Temperatur messen
** Automatisch: Es muss ein Reading temperature geben
** Über <code>genericDeviceType</code> thermometer
** Sonst: hombridgeMapping CurrentTemperature:reading=<reading>

* Geräte, deren Helligkeit sich ändern lässt
** Automatisch: wenn <code>dim</code> oder <code>pct</code> Kommandos erkannt werden
** Über <code>genericDeviceType</code> light
** ...
**Kommandos:
***Alexa, mache <name> heller/dunkler
***Alexa, Licht heller/dunkler

* Geräte, deren Farbe sich ändern lässt
** ...

* Geräte, deren Farbtemperatur sich ändern lässt
** ...

* Geräte, bei denen sich eine Lautstärke einstellen lässt
** ...

* Geräte, bei denen sich ein prozentualer Wert einstellen lässt
** Automatisch: wenn <code>dim</code> oder <code>pct</code> Kommandos erkannt werden
** ...

* elektrische Türschlösser
** <code>genericDeviceType</code>: lock

* Thermostate
** Über <code>genericDeviceType</code> thermometer
** ...

* structure Devices aus FHEM (ab alexa-fhem version 0.5.7)
** werden mit <code>genericDeviceType</code> scene als Szene eingebunden
** über <code>alexaRoom</code> kann der name um einen Ort ergänzt werden
** Szenen aus einer structure lassen sich ein- und ausschalten
** Wichtig: Ein Skill darf nur 12 Szenen automatisch erkennen und einbinden.

* LightScene Devices aus FHEM (ab alexa-fhem version 0.5.8)
** werden mit <code>genericDeviceType</code> scene als Szenen eingebunden
** über <code>alexaRoom</code> kann der name um einen Ort ergänzt werden
** Szenen aus einer LightScene lassen sich nur einschalten
** Wichtig: Ein Skill darf nur 12 Szenen automatisch erkennen und einbinden.

* Geräte, deren Kanal sich umschalten lässt (ab alexa-fhem version 0.5.13)
** Über <code>genericDeviceType</code> media
** hombridgeMapping ChannelController:reading=<reading>,cmd=<cmd>
** Erlaubte Werte siehe hier: https://developer.amazon.com/de/docs/device-apis/alexa-channelcontroller.html#changechannel
** ...

* Geräte, deren Playback status sich schalten lässt (ab alexa-fhem version 0.5.13)
** Über <code>genericDeviceType</code> media
** hombridgeMapping PlaybackController:playback,values=Play;Pause;Stop;Previous;Next
** Erlaubte Werte siehe hier: https://developer.amazon.com/de/docs/device-apis/alexa-playbackcontroller.html#discovery
** ...

* Geräte, deren Eingang sich umschalten lässt (ab alexa-fhem version 0.5.13)
** Über <code>genericDeviceType</code> media
** hombridgeMapping InputController:reading=<reading>:cmd=<cmd>,values=HDMI+1;HDMI+2;XBOX
** Erlaubte Werte siehe hier: https://developer.amazon.com/de/docs/device-apis/alexa-property-schemas.html#input
** ...

Es werden noch einige andere häufig verwendete Geräte (Homematic, hue,...) automatisch erkannt.

to be continued ...

In der [https://developer.amazon.com/docs/device-apis/list-of-interfaces.html List of Capability Interfaces] bei Amazon kann man sehen, welche Möglichkeiten das Smart Home Skill API aktuell in einzelnen Ländern bietet. Leider ohne die jeweiligen landessprachlichen Kommandos.

== Mögliche Probleme und Lösungen ==

Es kann vorkommen, dass Geräte zwar korrekt erkannt werden, aber das durch Alexa erkannte Kommando nicht richtig umgesetzt wird (Beispiel - mittlerweile behoben: {{Link2Forum|Topic=96766}}). Neben dem FHEM-Log gibt es noch das Logfile, welches von alexa-fhem angelegt wird.

Fehlersuche einfach:

* alexa-fhem Logfile anschauen (Speicherort findest Du in der Detail-Ansicht des <alexa> Devices bei "currentlogfile")
* alexa-fhem im Debug-Modus aufrufen
** set <alexa> stop
** Auf der Kommandozeile <code>alexa-fhem -D -c /opt/fhem/alexa-fhem.cfg > debug.log</code> starten
** Alexa-Befehl auslösen
** alexa-fhem auf der Console wieder stoppen
** set <alexa> start

Die Datei debug.log sollte Hinweise enthalten, wie das Problem zu lösen ist oder Dich zumindest in die richtige Richtung schieben.

Im Beispiel aus dem Forum der Hinweis darauf, dass das Device mit falschen min/max-Werten unterwegs war.

=== Registrierungskey vergessen, Registrierung zurücksetzen ===

Auf der Kommandoshell:

<syntaxhighlight lang="bash" style="width:90%;">
pi@raspberrypi:~# sudo -u fhem ssh -p 58824 fhem-va.fhem.de status
Registered.
Registered on 2019-01-13T15:38:13Z.
</syntaxhighlight>

heisst, das der Vereinsserver eigentlich alles hat, was er will. Es wird kein neuer Schlüssel generiert.
Wenn Du die Situation zurücksetzen möchtest, wäre die hässliche Methode, Deinen SSH-Key zu löschen. Eleganter ist, die Registrierung auf Vereinsseite zu löschen:

<syntaxhighlight lang="bash" style="width:90%;">
pi@raspberrypi:~# sudo -u fhem ssh -p 58824 fhem-va.fhem.de unregister
Your registration has been removed
</syntaxhighlight>

löscht Deinen Schlüssel mitsamt allen dort gespeicherten Daten auf Vereinsseite. Bei Restart von alexa-fhem in FHEM-WEB wird jetzt ein neuer Registrierungskey angefordert.

== Sicherheitskonzept und Secrets ==

Um diesen Abschnitt zu verstehen, solltest Du den Abschnitt "Arbeitsweise" im Kopf haben. Einerseits ist Dir vermutlich einleuchtend, dass ein Server, der per SSH rückwärts nur ausgewählte Kommandos in den Tunnel, den Du aufgebaut hast, leitet, "irgendwie sicherer" ist. Andererseits möchte man nicht blind vertrauen.

=== SSH ===
==== SSH - macht das nichts Gefährliches? ====
SSH ist ein Veteran des Internet und entstand, um sich sicher (verschlüsselt) und schnell auf Servern einzuloggen. Schon früh wurde dabei der sogenannte "Reverse-Tunnel" implementiert: Also der vom Client (Deinem Rechner) geäußerte Wunsch: "Bitte leite mir Requests, die bei Dir, Server, auf Port xy eingehen, an meinen lokalen Port yz weiter.". Dieses Verfahren implementiert der Reverseproxy, wobei tatsächlich auf dem Server für Dich kein echter Port geöffnet wird.

Wie Dir ggf. sicher der Unix-Guru Deines Vertrauens bestätigen wird: Die Kombination
<syntaxhighlight lang="bash" style="width:50%;">
ssh -R 1234:localhost:<zufälliger port> zielserver
</syntaxhighlight>
erlaubt keine Ausführung von Shell-Kommandos auf Deinem Server, sondern einzig, dass vom SSH-Programm Verbindungen zu einem lokalen Port auf Deinem Server auf dem alexa-fhem lauscht aufgebaut werden. Du kannst also z.B. mit einem
<syntaxhighlight lang="bash" style="width:50%;">
sudo /usr/sbin/tcpdump -X -s 0 -i lo port <zufälliger port>
</syntaxhighlight>
vollständig überwachen (oder ggf. permanent aufzeichen), was auf Deinem Server von außen gesteuert passiert.

==== Wie wird bei SSH verschlüsselt? ====
Im Prinzip wie im Web auf SSL-Seiten, teils mit den gleichen Verschlüsselungsverfahren. Allerdings arbeitet SSH eher wie das im Web recht seltene Verfahren: Bei jeder Verbindung übermitteln sowohl Server wie auch Client den öffentlichen Teil ihres Schlüssels. Anders als im Web wird der Schlüssel aber nicht von einer öffentlichen Zertifizierungsstelle wie "LetsEncrypt" unterschrieben. Stattdessen entscheiden Server wie Client beim ersten Verbindungsaufbau typischerweise per manueller Frage: "Willst Du jetzt und künftig diesem Schlüssel vertrauen?" Bei der Installation wird diese Frage für Deine Seite bejaht, und fortan wird der öffentliche Schlüssel des FHEM-Servers auf Deinem Rechner gespeichert. Ab da bist Du z.B. davor sicher, dass jemand den DNS-Eintrag verbiegt oder sich in den Datenfluss Deines Providers einhängt: Ein geänderter Serverschlüssel würde bemerkt werden.
 
Soweit klar? Aus Deinem öffentlichen Schlüssel wiederum leitet der Server her: "Das ist definitiv wieder derjenige, der sich damals "registriert" hat". Und an dieser Stelle kann ich auch den ersten Teil des 3-teiligen Registrierungskeys erläutern: Die typischerweise 6-stellige Hex-Zahl am Anfang ist der Java-Hashcode Deines öffentlichen Schlüssel. Sie ist damit sozusagen Deine aus Deinem öffentlichen Schlüssel abgeleitete Benutzer-ID.

=== Die Rolle der Secrets ===
Wenn jetzt klar ist, dass die Verbindung zum Vereinsserver sicher und vertauschungsfrei funktioniert, bleiben noch 2 Probleme zu lösen:
1) Im Web bei der Skill-Aktivierung musst Du beweisen, dass Du der Mensch am Browser bist, dem der SSH-Tunnel von IP xy mit dem öffentlichen Schlüssel X gehört. Bei der automatischen Registrierung werden lokal auf Deinem Rechner zwei 64-Bit-Secrets generiert:
* Das Anmelde-Secret
* Das Bearer-Token
Beim Anmelden des SSH-Keys auf dem öffentlichen Server wird nun der Hashwert des ersten Secrets übertragen und dort in Verbindung mit Deinem öffentlichen Schlüssel gespeichert. Ein Hashwert bedeutet, dass (sofern das Verfahren, hier SHA256, funktioniert), niemand aus dem Hash das Secret zurückrechnen kann. Ein Datenbankklau auf dem Server gefährdet also nicht die Sicherheit Deines Passwortes.

Wenn Du nun beim Skill-Aktivieren den Registrierungskey eingibst, dann "sieht" der Server zum ersten Mal Dein ausgewürfeltes Secret, vergleicht es mit dem Hashwert und wird es anschließend wieder umgehend vergessen. Anhand des Hashwertes kann der Server aber entscheiden, dass Du der legitime Nutzer zum öffentlichen Schlüssel XY bist.

2) Das zweite Problem ist: Wie soll Amazon "beweisen", dass sie der legitime Aufrufer sind? Amazon erhält binnen wenigen Sekunden nach dem Klick auf "Activate Skill" den dritten Teil des Registrierungskeys als sogenanntes Bearer-Token. Zwar läuft er durch den Registrierungsserver, er wird dort, auf dem Registrierungs/Vereinsserver aber nicht gespeichert. Das Bearer-Token wird von Amazon bei allen Requests zu Deinem Server mitgesendet. Da es am Anfang zusätzlich Deine "User-ID" enthält, weiß der Vereinsserver, zu welchem SSH-Tunnel der Request zu senden ist. Aber lokal auf Deinem Rechner wird ausgewertet, ob das Token "stimmt".

== alexa-fhem Updaten ==
* alexa-fhem über FHEM anhalten:
:<syntaxhighlight lang="perl" style="width:50%;">set alexa stop</syntaxhighlight>

*Auf der Konsole wie anfangs bei der Installation:
:<syntaxhighlight lang="bash" style="width:50%;">sudo npm update -g alexa-fhem</syntaxhighlight>

:Manchmal hat npm Probleme mit einem Update. Dann einfach die aktuelle Version noch mal drüber Installieren:

:<syntaxhighlight lang="bash" style="width:50%;">sudo npm install -g alexa-fhem</syntaxhighlight>

*alexa-fhem über FHEM wieder starten:
:<syntaxhighlight lang="perl" style="width:50%;">set alexa start</syntaxhighlight>

==Weitergehende Informationen==
*[[Alexa_und_Mappings]]
*[[Alexa_Tipps_und_Kniffe]]
[[Kategorie:HOWTOS]]
[[Kategorie:Sprachsteuerung]]

PRESENCE

2019-01-22T18:41:14Z

Sledge:

{{Infobox Modul
|ModPurpose=Anwesenheitserkennung
|ModType=h

|ModTechName=73_PRESENCE.pm
|ModOwner=markusbloch
}}

Das [[PRESENCE]] Modul bietet für die Anwesenheitserkennung mehrere Varianten an:

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

= Überwachen mittels Ping im WLAN/LAN =
{{Randnotiz|RNText=Um diese Methode auf einer FritzBox nutzen zu können, muss FHEM mit root-Rechten laufen. Dies ist standardmäßig nicht der Fall. Bitte dazu den Wiki Artikel [[FritzBox: fhem unter root starten]] beachten.}}
Um ein Gerät via Ping zu überwachen, muss folgende Definition durchgeführt werden:
:<code>define Handy PRESENCE lan-ping 192.168.0.30</code>

Dadurch wird die IP-Addresse 192.168.0.30 alle 30 Sekunden geprüft, ob sie erreichbar ist. Wenn sie erreichbar ist, ist der Status "present" (anwesend), ansonsten "absent" (abwesend).

Der Timeout kann verändert werden, indem ein Wert (in Sekunden) an das Define anhängt wird:
:<code>define Handy PRESENCE lan-ping 192.168.0.30 '''60'''</code>

Nun würde das Handy alle 60 Sekunden geprüft werden.

Nur wenn bei einem iPhone/iPad die Funktion "über WLAN synchronisieren" aktiviert ist, ist es auch im Standby zuverlässig pingbar. Standardmäßig deaktivieren Apple-Geräte ihr WLAN im Standby-Betrieb um die Akkulaufzeit zu verlängern.

Sollte die Fehlermeldung
:<code> PRESENCE (Handy) - ping command returned with output: ping: icmp open socket: Operation not permitted </code>
im Log auftauchen und lan-ping dadurch nicht funktionieren, liegt ein Berechtigungsproblem vor. Kein Grund den User fhem zu root zu machen!
Prüfe zu erst als User root ob die Capabilities gesetzt sind.
:<code>getcap /bin/ping</code>
Sollte folgendes Ergeben zu Tage fördern.
:<code>/bin/ping = cap_net_raw+ep</code>
Ist dem nicht so, setzen wir die benötigten Capabilities
:<code>setcap cap_net_raw+ep /bin/ping</code>
Mehr Informationen zum Thema Capabilities [https://manpages.debian.org/jessie/manpages-de/capabilities.7.de.html].

= FritzBox: direktes Abfragen der Aktivität via ctlmgr_ctl =
{{Randnotiz|RNText=Um diese Methode auf einer FritzBox nutzen zu können, muss FHEM mit root-Rechten laufen. Dies ist standardmäßig nicht der Fall. Bitte dazu den Wiki Artikel [[FritzBox: fhem unter root starten]] beachten.}}
Eine sehr häufige und auch zuverlässige Methode ist auf einer FritzBox die Abfrage mittels ctlmgr_ctl Befehl. Über diesen lassen sich alle Geräte abfragen ob sie aktiv sind. Ist ein Gerät aktiv, so gilt es als anwesend.

Dieser Modus kann allerdings nur in FHEM Installationen direkt auf einer FritzBox verwendet werden. Des weiteren muss FHEM unter dem User root laufen. Um ein Gerät zu überwachen, wird lediglich der Gerätename benötigt, so wie er unter dem Menüpunkt "Heimnetz" auftaucht.

Die erforderliche Definition:
:<code>define Handy PRESENCE fritzbox iPhone-4S</code>

= Überwachung mittels Perl-Code =
Es ist möglich zum Überwachen von Geräten eine eigene Perl-Funktion zu verwenden die dann vom PRESENCE Modul im Hintergrund aufgerufen wird.

define <name> PRESENCE function {...} [ <check-interval> [ <present-check-interval> ] ]

Sobald die Funktion den Rückgabewert 1 hat, ist das Gerät anwesend, bei 0 abwesend.

== Beispiel DHCP Überwachung auf Airport Basestation ==
Die hier vorgestellte Überwachung der DHCP Lease auf Airport Basestations per SNMP ist absolut robust gegenüber dem Ruhezustand von iOS und setzt keine weitere Konfiguration auf dem iPhone voraus. Das Abmelden beim Verlassen des Empfangsbereiches der Basestation geschieht mit etwa 5-10 Minuten Verzögerung und ist somit auch vor kurzzeitigen Empfangsproblemen sicher. Das nebenstehende Bild (???) verdeutlicht noch mal die Unterschiede zwischen einer IP-Basierten Ping-Überwachung und der Überwachung auf Ebene der Basestation oder FritzBox.

Bevor der folgende Code verwendet werden kann ist das Perl Modul Net:SNMP zu installieren (z. B. mit: <code>cpan install use Net::SNMP</code>).

Zuerst ist folgender Code in 99_myUtils.pm einzufügen, sollte diese noch nicht vorhanden sein muss diese aus dem Template welches unter Edit Files zu finden ist erzeugt werden.
'''Achtung, das ist nicht der komplette Inhalt der 99_myUtils!''' Das ist nur die einzelne Routine

<pre>
use Net::SNMP;
sub
snmpCheck($$)
{
my ($airport,$client)= @_;

my $community = "public";
my $host = $airport;
my $oid = ".1.3.6.1.2.1.3.1.1.2";
#my $oid = ".1.3.6.1.2.1.3.1.1.2.25.1.10.0.1";

my ( $session, $error ) = Net::SNMP->session(
-hostname => $host,
-community => $community,
-port => 161,
-version => 1
);

if( !defined($session) ) {
return 0;
return "Can't connect to host $host.";
}

my @snmpoids = ();

my $response = $session->get_next_request($oid);
my @nextid = keys %$response;
while ( @nextid && $nextid[0] && $nextid[0] =~ m/^$oid/ ) {
push( @snmpoids, $nextid[0] );

$response = $session->get_next_request( $nextid[0] );
@nextid = keys %$response;
}

if( !defined($response = $session->get_request( @snmpoids ) ) ) {
return 0;
}

foreach my $value (values %$response) {
return 1 if( $value eq $client )
}

return 0;
}
</pre>

Danach lässt sich das Mobilgerät so überwachen:
:<code>define iPhone PRESENCE function {snmpCheck("10.0.1.1","0x44d77429f35c")} 30 30</code>

wobei 10.0.1.1 durch die IP-Adresse der Basestation und 0x44d77429f35c durch die MAC Adresse des Geräts als HEX-Zahl ersetzt werden muss.

== Beispiel Anwesenheitserkennung mittels UniFi Controller ==

Die Anwesenheitserkennung bei Geräten in Verbindung mit UniFi-Produkten funktioniert selbst dann, wenn sich die Geräte im PowerSave-Modus befinden.

Beachte: Die Geräte werden erst ungefähr nach 5 Minuten, nachdem das Gerät das WLAN verlassen hat als disconnected angezeigt.

<code>define <NAME> PRESENCE function {ReadingsVal("<UniFi>","<NamedDevice>","") eq "connected" ? 1:0}</code>

= Überwachen mittels Events =
Der Vorteil gegenüber der Function-Variante ist, dass diese Variante ohne Blocking.pm-Overhead direkt ausgeführt werden kann und in "Echtzeit" abläuft (siehe {{Link2Forum|Topic=40287|Message=562823}}).

<code>define <NAME> PRESENCE event UniFi:NamedDevice:.disconnected UniFi:NamedDevice:.connected</code>

Dabei wird <UniFi> mit dem Namen des Unifi-Devices in FHEM ersetzt, <NamedDevice> mit dem Namen des zu überwachenden Devices im Unifi-Controller ersetzt.

= Überwachen mittels Bluetooth =
== Vorbereitung und Informationen ==
=== Getestete Hardware/Software ===
* '''Raspbian System''' - wheezy, Jessie (interner BT-Controller)
* '''BT-Dongle''' - CSL NET BT USB2.0 Stick, Bluetooth V4.0, Nano '''Achtung''': Es muss ein BT V4.0 oder höher verwendet werden. Nur dieser unterstützt ''LowEnergy''
* '''BT-TAG''' - Gtag von Gigaset, TrackR, UDOO Neo, PebbleBee, iTag von Unitec, X4-LIFE Multifunkti BL-Anhänger, iTag Wireless Anti, Trackr bravo, GhostyuBeacon iBc41

=== BT-Dongle am RaspberryPI installieren ===
Um den BT-Dongle ''(hier: CSL NET BT USB2.0)'' am RaspberryPI verwenden zu können, müssen die notwendigen Pakete über die Paketverwaltung von debian nachinstalliert werden.
Wer bereits ein BT-Dongle installiert hat, kann diesen Schritt überspringen.
<pre>
apt-get install bluetooth
</pre>
Nach erfolgreicher Installation der Pakete sollte der RaspberryPI neu gestartet werden.
<pre>
sudo reboot
</pre>

Nach dem erfolgten Reboot bitte das Log des RaspberryPI auf folgende Einträge prüfen:
<pre>
Feb 12 19:52:55 fhem kernel: [ 4.773600] Bluetooth: Core ver 2.20
Feb 12 19:52:55 fhem kernel: [ 4.773748] NET: Registered protocol family 31
Feb 12 19:52:55 fhem kernel: [ 4.773765] Bluetooth: HCI device and connection manager initialized
Feb 12 19:52:55 fhem kernel: [ 4.773797] Bluetooth: HCI socket layer initialized
Feb 12 19:52:55 fhem kernel: [ 4.773821] Bluetooth: L2CAP socket layer initialized
Feb 12 19:52:55 fhem kernel: [ 4.773890] Bluetooth: SCO socket layer initialized
Feb 12 19:52:55 fhem kernel: [ 4.797531] usbcore: registered new interface driver btusb
</pre>
Sobald der BT-Dongle erkannt wurde ''leuchtet'' (wenn vorhanden) auch die ''blaue/gelbe'' LED am Dongle auf.

=== BT-Tags aktivieren ===
Jetzt kann der BT-Tag aktiviert werden. Bei einigen BT-Tags muss dafür die '''Batteriesicherung''' gezogen werden.

Ein BT-Tag wird mit folgendem Befehl auf der Konsole gesucht:
<syntaxhighlight lang="bash">
sudo hcitool lescan

Ausgabe z.B.:
LE Scan ...
7C:2F:80:A1:XA:XD (unknown)
7C:2F:80:A1:XA:XD Gigaset G-tag
7C:2F:80:A1:X4:X1 (unknown)</syntaxhighlight>
Eine Übersicht über die möglichen Befehle von hcitool gibt es mit der Eingabe von:
<pre>
sudo hcitool

Ausgabe z.B.:
hcitool - HCI Tool ver 5.23
Usage:
hcitool [options] <command> [command parameters]
Options:
--help Display help
-i dev HCI device
Commands:
dev Display local devices
inq Inquire remote devices
scan Scan for remote devices
name Get name from remote device
info Get information from remote device
spinq Start periodic inquiry
epinq Exit periodic inquiry
cmd Submit arbitrary HCI commands
con Display active connections
cc Create connection to remote device
dc Disconnect from remote device
sr Switch master/slave role
cpt Change connection packet type
rssi Display connection RSSI
lq Display link quality
tpl Display transmit power level
afh Display AFH channel map
lp Set/display link policy settings
lst Set/display link supervision timeout
auth Request authentication
enc Set connection encryption
key Change connection link key
clkoff Read clock offset
clock Read local or remote clock
lescan Start LE scan
lewladd Add device to LE White List
lewlrm Remove device from LE White List
lewlsz Read size of LE White List
lewlclr Clear LE White list
lecc Create a LE Connection
ledc Disconnect a LE Connection
lecup LE Connection Update
</pre>

Falls beim SCAN kein BT-Tag gefunden wird, sollte das BT Interface neu gestartet werden. Dazu ist kein Reboot des RaspBerryPI notwendig.
<syntaxhighlight lang="bash">
sudo hciconfig hci0 down
sudo hciconfig hci0 up
sudo hcitool dev
</syntaxhighlight>

== Überwachung durch den FHEM Server direkt ==
[[Datei:Bluetooth-Adresse-iPhone.png|thumb|Bluetooth-Adresse eines iPhones]]
Jenach Aufstellungsort des FHEM Servers kann es sinnvoll sein, eine Bluetooth-Überwachung direkt durch den FHEM Server durchzuführen. Hierbei gilt allerdings zu beachten, dass Bluetooth nicht für große Reichweiten gedacht ist und in den meisten Fällen keine Wände überwinden kann. Das heisst, dass in den meisten Fällen damit nur ein Raum überwacht werden kann.

Je nach Einsatzzweck kann das auch so gewollt sein. Bluetooth USB Sticks, die bereits Bluetooth 4.0 unterstützen, können höhere Reichweiten über Zimmerwände hinaus erreichen. Vorausgesetzt, das Mobilgerät unterstützt Bluetooth 4.0.

Um eine Überwachung per Bluetooth durchführen zu können, benötigt man die Bluetooth-Adresse eines Gerätes. Diese ähnelt vom Aufbau einer MAC-Adresse. Generell wird die Adresse in den Telefon-Informationen bei Smartphones angezeigt.

Um eine Anwesenheitserkennung via Bluetooth durchzuführen, wird folgende Definition in der [[Konfiguration]] benötigt:
:<code>define Handy PRESENCE local-bluetooth XX:XX:XX:XX:XX:XX</code>

== Überwachung durch verteilte Agenten in der Wohnung (presenced/lepresenced/collectord) ==
[[Datei:Raspberry-Pi-mit-WLAN-und-Bluetooth-Stick.jpg|thumb|left|Raspberry Pi mit Bluetooth- und WLAN-USB-Stick]]
Um eine zuverlässige und flächendeckende Bluetooth-Anwesenheitserkennung durchzuführen, ist es unerlässlich, mehrere Bluetooth-Empfänger zu verwenden, die auf mehrere oder alle Räume verteilt sind.

Hierfür bietet sich zum Beispiel ein [[Raspberry Pi]] mit einem Mini-Bluetooth-USB-Stick und evtl. einem WLAN-USB-Stick an. Jeder Raum wird mit solch einem Raspberry ausgestattet und ist im WLAN Netz verfügbar.

Dieses Netz aus Raspberrys wird mit dem presenced / lepresenced Programm ausgestattet. Beide Programme sind Perl-Skripte, die als Daemon im Hintergrund laufen und auf Anfragen via Netzwerk warten. Es wird lediglich eine vollständige Perl-Grundinstallation mit Standardmodulen benötigt.

=== Unterschied presenced / lepresenced / collectord ===
presenced und lepresenced sind Programme, welche in regelmäßigen Abständen nach Bluetooth-Geräten suchen. Sobald ein Gerät, welches vorab definiert wurde, gefunden wird, wechselt der Status des Geräts in FHEM auf Anwesend. Der Unterschied zwischen presenced und lepresenced ist, dass lepresenced insbesondere für [https://de.wikipedia.org/wiki/Bluetooth_Low_Energy Bluetooth-LE-Devices] ist und presenced für "normale" Bluetooth-Geräte.

collectord wiederum ist ein Programm, welches mehrere Pis verbindet und auf allen den aktuellen Status von presenced/lepresenced abfragt. Ist das gesuchte Bluetooth-Gerät auf einem der Pi anwesend, so wird es auch in der definierten Hauptinstanz auf anwesend gesetzt. Zusätzlich wird der Pi auf dem das Gerät gefunden wurde als Reading angegeben. Sofern alle Räume einen Empfangspegel (RSSI) ermitteln können, wird bei mehreren anwesenden Räumen der Raum mit dem besten Empfangspegel selektiert (siehe {{Link2Forum|Topic=54482}}).

=== Installation von (le)presenced ===
Diese Anleitung ist sowohl für presenced, als auch für lepresenced gültig. Einfachheitshalber wird nur lepresenced erwähnt, sämtliche Schritte gehen jedoch auch mit presenced, wobei einfach die genannten Daten durch presenced ersetzt werden müssen.

Die Software lepresenced kann aktuell über drei Varianten installiert werden. Dabei ist die bevorzugte Variante (Variante 1) die Installation über das bereitgestellte .deb-Paket.
Die Variante 2 setzt voraus, dass im FHEM contrib Verzeichnis (/opt/fhem/contrib) die aktuelle Version des .deb-Pakets liegt. Die Variante 3 ist dafür gedacht, wenn man keine .deb-Pakete installieren kann/will oder es aus anderen Gründen nicht funktioniert. Es wird davon abgeraten die Variante 3 zu verwenden. Vollständigkeitshalber wird sie aber aufgeführt.

===== Installation per .deb-Paket =====

Die bevorzugte Variante ist die Installation von lepresenced durch die passenden .deb Pakete.
{{Randnotiz|RNText=Bei einem Upgrade einer älteren Version reicht es, das neue .deb Paket mit
:<code>sudo dpkg -i lepresenced-X.XX-X.deb</code>
zu aktualisieren}}

'''1.Variante:'''
Herunterladen der aktuellen lepresenced-0.83-3.deb (Stand August 2017) Datei über den Webbrowser
[https://svn.fhem.de/trac/export/HEAD/trunk/fhem/contrib/PRESENCE/deb/ SVN-Repository]. Im SVN die passende Datei auswählen und in der folgende Webseite den Link unter:
<pre>
Download in other formats:
Original Format
</pre>
anklicken und die Datei herunterladen.
Die Datei kann jetzt auf den RPi kopiert und mit folgenden Befehlen ausgeführt werden (ggf. Berechtigungen anpassen).

Alternativ per wget Befehl direkt auf den RPi (aktuelle Versionsnummer beachten)
https://svn.fhem.de/trac/export/HEAD/trunk/fhem/contrib/PRESENCE/deb/lepresenced-0.83-3.deb

'''2.Variante:''' (zu Verwenden, wenn es Probleme bei Variante 1 gibt)
Herunterladen aus dem fhem contrib Verzeichnis:
Hierzu muss das contrib auf dem aktuellen Stand sein. Dazu wird die Installation von subversion (normal bereits vorhanden) benötigt.

sudo apt-get install subversion

Danach kann per
sudo svn checkout https://svn.fhem.de/fhem/trunk/fhem/contrib svnrepo

Das aktuelle Repository auf den Pi heruntergeladen werden. Danach sollte im gewählten Verzeichnis die eingecheckten Dateien verfügbar sein.
/opt/fhem/svnrepo/PRESENCE/deb

''' Installation der Variante 1 oder 2 '''

Egal welche Variante gewählt wurde, nun kann mit folgenden Befehlen das Paket installiert werden. Bitte Pfade ggf. anpassen.

'''Wichtig''': Das '''Paket''' hat eine ca. Größe von '''6,5Kb'''. Ab und an gibt es wohl Probleme mit der Installation, wodurch die Datei 11,5kb groß wird.
Diese Datei lässt sich nicht Installieren. In diesem Fall das Paket bitte mit der Variante 1 und dem Bereich "Download in other formats" herunterladen.

sudo dpkg -i lepresenced-0.83-3.deb

sudo apt-get -f install

Die Ausgabe der Installation sollte am Ende ein [ ok ] Starting lepresenced (via systemctl): lepresenced.service. ausgeben.

<pre>
Paketlisten werden gelesen... Fertig
Abhängigkeitsbaum wird aufgebaut.
Statusinformationen werden eingelesen.... Fertig
Abhängigkeiten werden korrigiert ... Fertig
Die folgenden zusätzlichen Pakete werden installiert:
bluez-hcidump
Die folgenden NEUEN Pakete werden installiert:
bluez-hcidump
0 aktualisiert, 1 neu installiert, 0 zu entfernen und 0 nicht aktualisiert.
1 nicht vollständig installiert oder entfernt.
Es müssen 157 kB an Archiven heruntergeladen werden.
Nach dieser Operation werden 490 kB Plattenplatz zusätzlich benutzt.
Möchten Sie fortfahren? [J/n]
Holen: 1 http://archive.raspberrypi.org/debian/ jessie/main bluez-hcidump armhf 5.23-2+rpi2 [157 kB]
Es wurden 157 kB in 0 s geholt (921 kB/s).
Vormals nicht ausgewähltes Paket bluez-hcidump wird gewählt.
(Lese Datenbank ... 42033 Dateien und Verzeichnisse sind derzeit installiert.)
Vorbereitung zum Entpacken von .../bluez-hcidump_5.23-2+rpi2_armhf.deb ...
Entpacken von bluez-hcidump (5.23-2+rpi2) ...
Trigger für man-db (2.7.0.2-5) werden verarbeitet ...
bluez-hcidump (5.23-2+rpi2) wird eingerichtet ...
lepresenced (0.82-1) wird eingerichtet ...
[ ok ] Starting lepresenced (via systemctl): lepresenced.service.
</pre>

'''3.Variante:'''

Bei dieser Variante wird das aktuellste lepresenced Skript aus github heruntergeladen. Das bedeutet, dass jegliche Konfiguration wie automatischer Start, Berechtigungen etc.
manuell konfiguriert werden muss. Diese Variante eignet sich nur für diejenigen, die keine .deb-Pakete installieren wollen/können oder die genau Wissen, was sie tun!
<pre>
https://github.com/mhop/fhem-mirror/blob/master/fhem/contrib/PRESENCE/lepresenced
</pre>

Zur "Installation" des Skripts folgendermaßen vorgehen:
Unter /fhem manuell den Ordner „script“ anlegen:
<pre>
mkdir script
</pre>
Datei lepresenced reinkopieren und ausführbar machen:
<pre>
sudo chmod +x /opt/fhem/script/lepresenced
sudo chgrp -cR dialout lepresenced
</pre>
Skript erstmalig starten:
<pre>
sudo ./lepresenced --loglevel LOG_EMERG -d
</pre>
Kommt beim Starten des Skript eine Fehlermeldung, müssen die Abhängigkeiten aufgelöst werden.
<pre>
Can't locate Net/Server/Daemonize.pm in @INC (@INC contains: /etc/perl /usr/local/lib/perl/5.14.2 /usr/local/share/perl/5.14.2 /usr/lib/perl5 /usr/share/perl5 / usr/lib/perl/5.14 /usr/share/perl/5.14 /usr/local/lib/site_perl .) at /opt/fhem/lepresenced line 17.
BEGIN failed--compilation aborted at /opt/fhem/lepresenced line 17.
</pre>
Um die Abhängigkeiten aufzulösen muss folgendes nachinstalliert werden und anschließend ein Reboot durchgeführt werden.
<pre>
sudo apt-get install libnet-server-*
</pre>

===== Einrichtung eines Bluetooth-Geräts über FHEM =====

Nach dem letzten Schritt sind alle Bedingungen für eine abschließende Konfiguration eines BT-Geräts in FHEM abgeschlossen worden.
Jetzt kann der zum Beispiel ein G-Tag dem FHEM-Server bekannt gemacht werden:
<pre>
-- Name Modul Modus MAC vom Gtag IP vom PI Port Abfragezeit in Sekunden
define MeinGtAG PRESENCE lan-bluetooth xx:xx:xx:xx:xx:xx 127.0.0.1:5333 120
</pre>

'''Wichtig ist den angegeben Port zu unterscheiden. Für presenced muss der Port 5111 genommen werden, für lepresenced der Port 5333.'''
Den absent und present Mode kann man einfach testen, in dem man den Gtag mit Alufolie einwickelt.

Diese Variante sollte eingesetzt werden, wenn nur ein Pi nach Bluetooth-Geräten sucht. Möchte man mehr als ein Gerät nutzen um zum Beispiel eine größere Fläche abzudecken so muss mit collectored gearbeitet werden.

=== Alle Räume gemeinsam ansprechen mittels collectord ===
Um zwei presenced- oder lepresenced Installationen zu verbinden wird der collectord Daemon von Markus Bloch benötigt. Dieser kennt alle presenced-Installationen im Netzwerk und führt eine koordinierte Suche nach den gewünschten Geräten durch. Sobald ein Gerät in einem Raum erkannt wurde, meldet der collectord den Status einschließlich der Angabe des Raumes, in dem das Gerät erkannt wurde.

[[Datei:Presence_Collectord_Uebersicht.jpg|200px|thumb|left|Schematische Darstellung Presence und Collectord, Danke an dtavb]]
Auf Basis folgender Skizze wird die Einrichtung und der Betrieb der Anwesenheitserkennung und Überwachung 
mit dem PRESENCE-Modul sowie dem Skript (.deb-Paket) lepresenced beschrieben. Zusätzlich wird für die Verbindung 
mehrere lepresenced Instanzen der collectord verwendet.
Diese Skizze dient als Basis für alle genannten Konfigurationen innerhalb dieses Artikels.
{{NeuerTextBlock}}

==== Aufbau ====
; RPi1 (Hauptinstanz):
: FHEM Installation
: presence/lepresenced Installation
: collectord installation
: Sämtliche Bluetooth-Geräte in FHEM definiert
; RPi2 (Zweitsystem):
: FHEM installation
: presence/lepresenced Installation
: Sämtliche Bluetooth-Geräte in FHEM definiert

==== Installation per .deb-Paket ====
collectord wird heruntergeladen und installiert:
https://svn.fhem.de/trac/export/HEAD/trunk/fhem/contrib/PRESENCE/deb/collectord-1.8.deb (Stand Januar 2018)
<pre>
sudo dpkg -i collectord-1.8.deb
</pre>

Nach der Installation befindet sich im Verzeichnis: /etc/collectord.conf die Konfigurationsdatei für das collectord. Weitere Einstellungen können unter /etc/default/collectord vorgenommen werden.

==== Konfiguration auf Shellebene ====
<pre>
sudo vi /etc/collectord.conf
</pre>

Diese Datei muss jetzt nach folgender Vorlage angepasst werden.
<pre>
# room definition
#[room-name] # name of the room
#address=192.168.0.10 # ip-address or hostname
#port=5111 # tcp port which should be used (5111 is default)
#presence_timeout=120 # timeout in seconds for each check when devices are present
#absence_timeout=20 # timeout in secondsfor each check when devices are absent

[RPi1] # Name (wird als Reading room bei den BT-Tags angezeigt) der presence Instanze
address=127.0.0.1 # Lokale Adresse RPi1 , da hier das Collectord später laufen soll!
port=5333 # Port der Presence Installation
presence_timeout=60 # Selbstgewaelte Pruefintervalle
absence_timeout=60 # Selbstgewaelte Pruefintervalle

[RPi2] # Name (wird als Reading room bei den BT-Tags angezeigt) der presence Instanze
address=192.168.178.127 # IP-Adresse der Instanz, wo nur das Presence laueft, also RPi2
port=5333 # Port der Presence Installation
presence_timeout=60 # Selbstgewaelte Pruefintervalle
absence_timeout=60 # Selbstgewaelte Pruefintervalle
</pre>

Hinweis:
* Es dürfen keine [Namen] mit Leerzeichen verwendet werden
* Der angegebene Port richtet sich danach, ob auf dem Pi presenced (Port 5111) oder lepresenced (Port 5333) nach dem Bluetooth-Gerät sucht

==== Konfiguration in FHEM ====
;RPi1
define Gtag PRESENCE lan-bluetooth XX:XX:XX:XX:XX:XX 127.0.0.1:5222 60 ''Hinweis: (Der Port ist der, des collectord!! Standard 5222)''
;RPi2
define Gtag PRESENCE lan-bluetooth XX:XX:XX:XX:XX:XX 192.168.178.127:5222 60 ''Hinweis: (Der Port ist der, des collectord!! Standard 5222 - die IP-Adresse von die von RPi1)''

Nach der Konfiguration kann der Daemon gestartet werden.
Sobald das Bluetoothgerät irgendwo in der Wohnung erkannt wurde, meldet der Collectord dies sofort
an FHEM und teilt den Raum mit in dem es erkannt worden ist. Diese Information wird im Reading "rooms" des jeweiligen BT-Gerätes dargestellt.

Zum testen sollte collectord einmalig manuell gestartet werden. Dies hat den Vorteil, dass man nochmal den Port des collectord prüfen kann, dieser steht in der Zeile <pre>created socket on 0.0.0.0 with port 5222</pre> und man sehen kann, ob der collectord richtig startet, oder Fehler auswirft. Gestartet wird mit folgendem Kommando:
<pre>
sudo collectord -vv -c /etc/collectord.conf
</pre>
Die Ausgabe sieht wie folgt aus:
<pre>
2017-04-02 17:52:55 - =================================================
2017-04-02 17:52:55 - started with PID 15554
2017-04-02 17:52:55 - reading configuration file
2017-04-02 17:52:55 - no config errors found
2017-04-02 17:52:56 - created socket on 0.0.0.0 with port 5222
2017-04-02 17:53:20 - new connection from 127.0.0.1:48656
2017-04-02 17:53:20 - created thread 1 for processing device 7C:2F:80:E1:14:31 in room RPi2 for peer 127.0.0.1 (UUID: d0beb79dd4771532eb5e207c7bf31788)
2017-04-02 17:53:20 - created thread 2 for processing device 7C:2F:80:E1:14:31 in room RPi1 for peer 127.0.0.1 (UUID: d0beb79dd4771532eb5e207c7bf31788)
2017-04-02 17:53:20 - new connection from 127.0.0.1:48662
2017-04-02 17:53:20 - new connection from 127.0.0.1:48664
2017-04-02 17:53:20 - created thread 3 for processing device 7C:2F:80:ED:BC:F7 in room RPi2 for peer 127.0.0.1 (UUID: 7495a112063d5db45e6335d3fe305e36)
2017-04-02 17:53:20 - created thread 4 for processing device 7C:2F:80:ED:BC:F7 in room RPi1 for peer 127.0.0.1 (UUID: 7495a112063d5db45e6335d3fe305e36)
2017-04-02 17:53:20 - created thread 5 for processing device 7C:2F:80:E1:2A:4D in room RPi2 for peer 127.0.0.1 (UUID: c228f8d4d33b06787f995c7903c02760)
2017-04-02 17:53:20 - created thread 6 for processing device 7C:2F:80:E1:2A:4D in room RPi1 for peer 127.0.0.1 (UUID: c228f8d4d33b06787f995c7903c02760)
2017-04-02 17:53:22 - new connection from 192.168.xxx.xxx:51638
2017-04-02 17:53:22 - created thread 7 for processing device 7C:2F:80:E1:14:31 in room RPi2 for peer 192.168.xxx.xxx (UUID: 5db7012e709d6dc2fcd8159fc0344e40)
2017-04-02 17:53:22 - created thread 8 for processing device 7C:2F:80:E1:14:31 in room RPi1 for peer 192.168.xxx.xxx (UUID: 5db7012e709d6dc2fcd8159fc0344e40)
2017-04-02 17:53:22 - new connection from 192.168.xxx.xxx:51640
2017-04-02 17:53:22 - created thread 9 for processing device 7C:2F:80:ED:BC:F7 in room RPi2 for peer 192.168.xxx.xxx (UUID: c4b4d7c654132cf88e8c1fec3a956d3d)
2017-04-02 17:53:23 - created thread 10 for processing device 7C:2F:80:ED:BC:F7 in room RPi1 for peer 192.168.xxx.xxx (UUID: c4b4d7c654132cf88e8c1fec3a956d3d)
2017-04-02 17:53:29 - new connection from 192.168.xxx.xxx:51642
2017-04-02 17:53:29 - created thread 11 for processing device 7C:2F:80:E1:2A:4D in room RPi2 for peer 192.168.xxx.xxx (UUID: ecd7081e5ae3a0d8e735c8750cb116a1)
2017-04-02 17:53:29 - created thread 12 for processing device 7C:2F:80:E1:2A:4D in room RPi1 for peer 192.168.xxx.xxx (UUID: ecd7081e5ae3a0d8e735c8750cb116a1)
</pre>

Wenn das Log wie oben abgebildet aussieht wurde alles richtig gemacht und unter dem Device in FHEM erscheint ein neues Reading "rooms" mit dem Wert der erkannten PRESENCE-Installation.

'''Verhalten presence timeout im zusammenhang mit dem Attribut "absenceThreshold" der PRESENCE Konfiguration in FHEM'''
 
In der collectord.conf sind <code>presence_timeout</code> und <code>absence_timeout</code> für den jeweiligen Raum konfiguriert.
Das bedeutet, sobald irgendein Gerät in diesem jeweiligen Raum anwesend/abwesend ist, wird das jeweilige Timeout an den verbundenen presenced/lepresenced geschickt um damit das Check-Interval entsprechend zu ändern.

In der PRESENCE-Definition kann man ebenfalls ein <code>absence_timeout</code>/<code>presence_timeout</code> setzen. Sobald sich der Zustand ändert, wird auch das jeweilige Timeout an den collectord gesandt. Dies hat aber auf die Checks in den jeweiligen Räumen und damit der collectord.conf keinen Einfluss. Der collectord schickt ein Statusupdate an PRESENCE nur, wenn das vorgegebene Timeout (von PRESENCE) erreicht ist und keine Statusänderung stattfand. Sobald eine Änderung des Status erfolgt wird natürlich sofort der Status an PRESENCE geschickt.

Das Attribut absenceThreshold/presenceThreshold funktioniert nachwievor. Hier ist nur wichtig wie man die Timeouts sowohl in PRESENCE als auch collectord.conf setzt.

'''Das Reading "room" bei einer PRESENCE Definition und der Zusammenhang zu collectord'''
 
Wenn ein BT LE Empfänger in mehr als einem Raum detektiert wird, führt der collectord (ab Version 1.8) eine RSSI-Erkennung durch. Sofern alle Räume den Empfangspegel (RSSI) ermitteln können, wird der Raum mit dem besten Empfangspegel als Raum für das "room"-Reading ausgewählt. Der lepresenced in aktueller Version von PatrickR gibt immer den Empfangspegel aus.

==== Automatischer Start ====
Wenn der collectord per .deb Paket installiert wurde, startet er automatisch bei einem Reboot mit (via systemd/init-Skript).
 

Der Collectord wird standardmäßig mit dem Port 5222 gestartet. Um diese anzupassen sind zwei Schritte notwendig: 
'''1.)''' Anpassen der /usr/bin/collectord
Hier bitte den Parameter my $opt_p von 5222 auf 5XXX abändern.

Da der collectord mittlerweile per systemd beim reboot des RPi gestarte wird muss auch diese Konfiguration auf den neuen Port angepasst werden. 
'''2.)''' Anpassen der /etc/default/collectord
<pre>
# collectord startup defaults:
# The TCP port collectord will listen for incoming connections (default: 5222)
PORT=5111
# The location of the configuration file (default: /etc/collectord.conf
CFGFILE=/etc/collectord.conf
</pre>

Manuell starten als Daemon (Parameter <code>-d</code>) mit:
<pre>
sudo collectord -c /etc/collectord.conf -d -v -l /var/log/collectord.log
</pre>

== Batterieüberwachung ==

=== Batterieüberwachung mit dem Modul BleTagBattery ===
{{Infobox Modul
|ModPurpose=Anwesenheitserkennung
|ModType=h

|ModTechName=74_BleTagBattery
|ModOwner=mumpitzstuff
}}
Mit dem Modul BleTagBattery - können die Batteriestati aller BT-LE Devices gelesen werden.
Es wird das batteryLevel und battery angelegt welches als BT-LE Tags an einer PRESENCE-Installation registriert wurden.

Vorraussetzung und Installation:

Bluez und Gattool
sudo apt-get install bluez

Das Gattool ist in den Installationen von Bluez inbegriffen.

Hinzufügen des githup für das Modul
update add http://raw.githubusercontent.com/mumpitzstuff/fhem-BleTagBattery/master/controls_bletagbattery.txt
update all
restart fhem: shutdown restart
BT-LE tags muss an einer PRESENCE-Installation des type "lan-bluetooth" registriert sein.

Nach dem Neustart von FHEM kann das Modul definiert werden:
define a new device: define <name of device> BleTagBattery

Das Modul versucht in der Standardkonfiguration alle 6 Stunden die BT-LE Devices zu erreichen und das Reading batteryLevel und battery zu aktualisieren.
Das Update kann auch manuell mit dem folgenden Befehl erzwungen werden

set <name of device> statusRequest.

Weiter Informationen und Disskussionen können dem eigentlichen [https://forum.fhem.de/index.php?topic=68104.0 Forumsbeitrag] entnommen werden,

=== Batterieüberwachung (aktuell nur G-Tags) ===

Leider überträgt der G-Tag nach der Einrichtung als Device in FHEM kein Reading mit seinem aktuellen Batteriestatus.
Dem wurde mit Hilfe des Forum Abhilfe geschaffen.
Im Folgenden wird erläutert wie die Batterieüberwachung eingerichtet werden kann.

'''Voraussetzung:'''

bc - Basiscalculator [https://packages.debian.org/de/sid/bc Bc-Paket]
<pre> sudo apt-get install bc </pre>

Anlegen eines Shellskript auf dem Raspberry System.
Die Parameter <<MAC-Adresse>> und <<TagName>> müssen durch die Werte des auszulesenden G-Tags ersetzt werden.
<pre>
#!/bin/bash
stringZ=$(sudo gatttool -b 5C:2B:80:C1:14:41 --char-read --handle=0x001b)
stringZ=${stringZ:33:2}
stringZ=$(echo "$stringZ" | tr a-f A-F)
decimal=$(echo "ibase=16; $stringZ" | bc)
perl /opt/fhem/fhem.pl 7072 "setreading MeinGtag Batterie $decimal"
</pre>

Dem Device in FHEM (hier MeinGtag) ein userReading mit dem Namen '''Batterie''' hinzufügen.
Das Shellskript mit folgendem Befehl starten:
<pre>
./GtagBatterie.sh
</pre>
'''Wichtig ist hierbei,''' dass Skript mit "./" und nicht mit "sh" aufzurufen. Beim Aufruf mit "sh GtagBatterie.sh" produziert es einen Fehler
<pre>GtagBatterie.sh: 3: GtagBatterie.sh: Bad substitution </pre>

Das Reading wird auf den ausgelesenen Wert der Batterie gesetzt.

Hinweis: Es sollte für jeden G-Tag ein eigenes Skript abgelegt werden. Das Skript kann per crontab oder fhem Kommando (system) regelmäßig aufgerufen werden.

=== Batterieüberwachung (alle Devices vom Typ "MODE=lan-bluetooth") ===

Es gibt eine weitere Möglichkeit um den Batteriestatus von LE Devices abzurufen und in FHEM als Reading darzustellen.
Dabei wird der Batteriezustand für alle LE Devices, die bereits in FHEM konfiguriert sind und per lepresenced überwacht werden, automatisch in einem shell-Script ermittelt.
Näheres dazu im Forumartikel {{Link2Forum|Topic=56960|LinkText=Erweiterung: Anwesenheitserkennung/Batterieüberwachung}}.

Vorteile:
* Automatische Ermittlung aller in FHEM konfigurierten LE Devices
* Möglichkeit, diese Devices alternativ manuell im Script einzutragen
* Es werden nur Devices abgefragt, die im Status "present" sind, also mit ziemlicher Sicherheit auch verfügbar sind
* Ein eventuell auf dem FHEM telnet-Port gesetztes Passwort kann im Script hinterlegt werden

'''Voraussetzung:'''

'''Funktionierendes lepresenced''' - siehe [[Anwesenheitserkennung#Anleitung_f.C3.BCr_ein_LE_Device_.28z.B._Gtags.2CPebbles_etc..29|Anleitung für ein LE Device (z.B. Gtags,Pebbles etc.)]]

'''socat''' - TCP port forwarder
<pre>
sudo apt-get update && sudo apt-get install socat
</pre>

'''gawk''' - Zum extrahieren der Daten
<pre>
sudo apt-get update && sudo apt-get install gawk
</pre>

'''gatttool''' - Bestandteil von bluez

gatttool ist auf den meisten Distributionen im bluez-Paket, allerdings nicht bei Opensuse. Dort muss man das Sourcepaket von bluez installieren und selbst kompilieren.
gatttool sollte dann nach /usr/bin oder /usr/local/bin kopiert werden,

Zusätzlich zu den notwendigen Erweiterungen werden für die Ausführung von gatttool '''Root-Rechte benötigt'''!

Das Script selbst gibt es hier: [https://raw.githubusercontent.com/micky0867/lebattery/master/lebattery lebattery]

Am Besten unter /opt/fhem/script/lebattery speichern und ausführbar machen:
<syntaxhighlight lang="bash">
sudo su -
mkdir /opt/fhem/script
cd /opt/fhem/script
wget https://raw.githubusercontent.com/micky0867/lebattery/master/lebattery
chmod 755 lebattery
</syntaxhighlight>

Je nach Bedarf können im Script noch die folgenden 3 Parameter angepasst werden:
<syntaxhighlight lang="bash">
# If allowed_telnetPort is protected by a password, add the password here
TELNETPASSWORD=""
# Attribute for batterylevel in FHEM
ATTRIBUT="batterylevel"
# Use this, if you dont want the script to determine the tags on its own
LETAGS=""
</syntaxhighlight>

Das Skript wird dann unter root folgendermaßen gestartet:
<pre>
/opt/fhem/script/lebattery -v
</pre>

Ausgabe des Skripts, wenn es mit dem Verbose Parameter -v gestartet wird.

Beide Devices sind vom Typ NUT mini, das Device mit dem FHEM-Namen '''nut_Micky''' ist im Status '''absent'''. Das zweite Device ist im Status '''present'''.
<pre>
Determining address for nut_Micky ...
nut_Micky is in state absent, no further action required

Determining address for nut_Test ...
Fetching batterylevel for nut_Test (F3:44:04:81:54:89) ...
Setting batterylevel for nut_Test to 100%
</pre>

Mein crontab-Eintrag (User root) sieht so aus:
<pre>
3 3 * * * /opt/fhem/script/lebattery -v >/opt/fhem/script/lebattery.log 2>&1
</pre>
Damit wird jeden Morgen um 3 Minuten nach 3 Uhr der Zustand der Batterien aller Devices ermittelt und in FHEM abgespeichert. 
Bevor man das mit crontab macht, sollte man allerdings zunächst sicher stellen, dass es auch ohne crontab funktioniert....

Bei Problemen kann man auch erstmal schauen, ob das mit dem gattool überhaupt funktioniert:
<pre>
gatttool -t <Typ> -b <MAC-Adresse> --char-read --uuid 0x2a19

handle: 0x0017 value: 64
</pre>
In diesem Fall hat die Batterie noch 100% (hex 64). 
Der Typ ist abhängig vom Hersteller und kann public (G-Tags) bzw. random (Nut) sein. Im Zweifelsfall beides ausprobieren.

= Beispiele =
== Anwesenheitserkennung / Anwesenheitsbenachrichtigung mit G-Tags ==
Ein Skript zur Nutzung der Gigaset G-TAGs zur Alarmierung bei öffnen und schließen von Türen und zur Anwesenheitserkennung, um die Alarmierung zu aktivieren bzw. deaktivieren.
Es kann verwendet werden um die Anwesenheit von mehrern Personen im Haushalt zu erkennen. Dabei wird eingeschränkt, dass nur bestimmte Personen die Alarmierung aktivieren können ( Eltern/Kind -Beziehung ).
Des Weiteren werden im Beispiel die Eltern benachrichtigt wenn eins der Kinder das Haus verlässt und die Eltern nicht anwesend sind.

{{Randnotiz|RNText=Namen der G-Tags in den Skripten bitte anpassen!}}

Für die ''Notify'' und die ''RESIDENTS-Erweiterung'' wird ein Dummy benötigt.
<pre>
define Alarm dummy
attr Alarm devStateIcon aktiv:secur_locked@red inaktiv:secur_open@lightgreen
attr Alarm eventMap on:aktiv off:inaktiv
attr Alarm setList on off
attr Alarm webCmd aktiv:inaktiv
attr Alarm room Alarm
</pre>

=== Mit Notify ===
<pre>
gtag.*.presence:.* {Anwesenheit_check("$EVTPART1", "$NAME")}
</pre>

Code für die 99_myUtils.pm
<pre>
### GTAG ANWESENHEITS CHECK
sub Anwesenheit_check($$) {
my ($EVENT, $NAME) = @_;

# gtag_rot - Alias Marco
# gtag_schwarz - Alias Ulli
# gtag_gruen - Alias Frida
# gtag_orange - Alias Hannah

my $RESIDENT = "rr_"; # Alle GTAGs sind Standardmäßig Residents Roommate
# $RESIDENT = "rg_" if (($NAME eq "gtag_orange") xor ($NAME eq "gtag_weis")); # Hier nur Gäste (Roomguest) Auskommentiert, da ich es so nicht brauche
my $ROOMMATE = ("$RESIDENT" . "$NAME"); # Residentsname zusammenbauen
my $ALIASNAME = AttrVal($ROOMMATE,'alias',$ROOMMATE); # ALIAS des Roommates auslesen

my $GTAG1 = Value('gtag_rot'); # ELTERN
my $GTAG2 = Value('gtag_schwarz'); # ELTERN

my $STATUS = "wahrscheinlich gerade los";
$STATUS = "anwesend" if ($EVENT eq "present"); # Status: anwesend
$STATUS = "unterwegs" if ($EVENT eq "absent"); # Status: unterwegs

Log 1, "$ALIASNAME ist $STATUS."; # LOG Eintrag erzeugen

if (($EVENT eq "present" && Value("Alarm") eq "aktiv") && ($NAME eq "gtag_gruen" xor $NAME eq "gtag_orange")) {
fhem("set teleBot send ALARMIERUNG BLEIBT AKTIV: $ALIASNAME ist da..."); # Telegram
# fhem("set Infopush msg 'ALARMIERUNG BLEIBT AKTIV' '$ALIASNAME ist da...'"); # Pushover
}
elsif (($EVENT eq "present" && Value("Alarm") eq "aktiv") && ($NAME eq "gtag_rot" xor $NAME eq "gtag_schwarz")) {
fhem("set teleBot send ALARMIERUNG INAKTIV: $ALIASNAME ist da...; set Alarm inaktiv"); # Telegram
# fhem("set Infopush msg 'ALARMIERUNG INAKTIV' '$ALIASNAME ist da...'; set Alarm inaktiv"); # Pushover
}
elsif (($EVENT eq "absent" && Value("Alarm") eq "aktiv") && ($NAME eq "gtag_gruen" xor $NAME eq "gtag_orange")) {
fhem("set teleBot send ALARMIERUNG BLEIBT AKTIV: $ALIASNAME hat das Haus verlassen."); # Telegram
# fhem("set Infopush msg 'ALARMIERUNG BLEIBT AKTIV' '$ALIASNAME hat das Haus verlassen.'"); # Pushover
}
elsif (($EVENT eq "absent" && Value("Alarm") eq "inaktiv") && ($GTAG1 eq "absent" && $GTAG2 eq "absent")) {
fhem("set Alarm aktiv; set teleBot send ALARMIERUNG AKTIV: $ALIASNAME hat das Haus verlassen."); # Telegram
# fhem("set Alarm aktiv; set Infopush msg 'ALARMIERUNG AKTIV' '$ALIASNAME hat das Haus verlassen.' '' 0 ''"); # Pushover
}
}
</pre>

 

=== Mit Notify und Integration des RESIDENTS-MODUL ===

Der hier beschriebene Code erweitert die Funktionen unter dem Punkt 5.93.
Das Notify muss daher mit der folgenden Zeile erweitert werden.

<pre>
define Alarm_AnwesenheitCheck notify gtag.*.presence:.* { Anwesenheit_check("$EVTPART1", "$NAME"), Anwesenheit_check_resi("$NAME") }
</pre>

Zusätzlicher Code für die 99_myUtils.pm um die RESIDENTS Funktion nutzen zu können:
<pre>
### RESIDENTS
sub Anwesenheit_check_resi($) {
my ($NAME) = @_;
my $ALIASNAME = AttrVal($NAME,'alias',$NAME); # ALIASNAME des GTAGs auslesen

my $RESIDENT = "rr_"; # Als Standard sind alle GTAGs Roommates
$RESIDENT = "rg_" if (($NAME eq "gtag_orange") xor ($NAME eq "gtag_weis")); # Hier nur GTAG Namen der Gäste (Roomguest)
my $ROOMMATE = ("$RESIDENT" . "$ALIASNAME"); # Residentsname zusammenbauen

if (ReadingsVal($NAME,'presence',$NAME) eq "absent") {
fhem("set $ROOMMATE absent"); # Resisents Status von Roommates setzen
}
elsif(ReadingsVal($NAME,'presence',$NAME) eq "present") {
fhem("set $ROOMMATE home"); # Resisents Status von Roommates setzen
}
}
</pre>
 

=== Mit Notify und Fenster/Tür. -Kontakt Überwachung ===

Erweiterung für die Überwachung von Fenster/Tür. -Kontakten. Dazu sind zwei weitere Notifys notwendig die auf die Trigger der Kontakte regagieren
und so eine weitere Funktion in der 99_myUtils.pm ansprechen. Die Notifys triggern auf Kontakte die mit dem Namen Kontakt* beginnen.
Sollten die eigenen Fenster/Tür. -Kontakt anderen Namen besitzen, müssen die Skripte dementsprechend angepasst werden.
<pre>
define Alarm_Kontaktmeldung notify Kontakt.*:contact:.* {Kontakt_Meldung("$EVTPART1", "$NAME")}
</pre>
<pre>
define Alarm_Sabotagealarm notify Kontakt.*.sabotageError:.on {Kontakt_Sabotage("$EVTPART1", "$NAME")}
</pre>

Zusätzlicher Code für die 99_myUtils.pm um die TÜRKONTAKTE-Meldung nutzen zu können:
<pre>
### TÜRKONTAKTE-Meldung/Zustand
sub Kontakt_Meldung($$) {
my ($EVENT, $NAME) = @_;
my $ALIASNAME = AttrVal($NAME,'alias',$NAME);
Log 1, "$ALIASNAME wurde $EVENT";
if (ReadingsVal("Alarm", "state", "on") eq "on") {
fhem("set teleBot send $ALIASNAME wurde $EVENT"); # Nachricht über Telegram
# fhem("set Infopush msg '$ALIASNAME' '$ALIASNAME wurde $EVENT'"); # Nachricht über Pushover
}
}

### TÜRKONTAKTE-Sabotagealarm

sub Kontakt_Sabotage($$) {
my ($EVENT, $NAME) = @_;
my $ALIASNAME = AttrVal($NAME,'alias',$NAME);
Log 1, "$ALIASNAME meldet Sabotagealarm";
fhem("set teleBot send Alarm: $ALIASNAME meldet Sabotagealarm"); # Nachricht über Telegram
# fhem("set Infopush msg 'Alarmanlage' '$ALIASNAME meldet Sabotagealarm' '' 2 ' ' 60 600 "); # Nachricht über Pushover
}
</pre>
 

=== Hinweis zur Benutzung / Fehlerhandling ===

Der Alarm dummy hat den Zustand on:off. Die Bezeichnungen und Namen müssen 1:1 übernommen werden damit das Script funktioniert.
Andernfalls müssen die Bezeichnungen für z.B. absent:unterwegs und present:anwesend - angepasst werden.
Die Benachrichtigung kann aktuell per ''Telegram'' sowie ''Pushover'' ('''Achtung mit zweiterem sind Abokosten verbunden!''') realisiert werden.
Diskussion zum Thema im Forum unter: {{Link2Forum|Topic=64080}}
 

= Problemlösungen =
Falls es '''Probleme beim Starten des Skripts''' gibt bzw. man das Skript ohne Reboot des Systems neustarten möchte, kann man dies per kill Befehl erledigen.
<syntaxhighlight lang="bash">
ps -ef | grep lepresenced
sudo kill <pid>
</syntaxhighlight>

Debuglevel lepresenced setzen:
{{Randnotiz|RNText=Um Debug-Meldungen zu bekommen (Vorsicht bei SD-Karten-Systemen wie dem RPi) - Hierbei werden die Schreibzyklen auf die SD-Karte erhöht.}}

Der Log Level muss im lepresenced-Skript selbst verändert werden. Um den Log-Level auf INFO/WARNING/DEBUG zu setzen, das Skript lepresenced mit einem Editor öffnen und die Stellen, wo LOG_WARNING zu finden ist, durch den nötigen LOG-Eintrag ersetzen.

<pre>
lepresenced --loglevel LOG_DEBUG
</pre>
Nur das wichtigste Loggen:
<pre>
lepresenced --loglevel LOG_WARNING
</pre>
Keinerlei LOG-Einträge
<pre>
lepresenced --loglevel LOG_EMERG
</pre>

Bei '''Problemen mit der Batterieüberwachung''' der Tags kann die Pi Firmware mit folgenden Befehl auf eine ältere Version zurückgesetzt werden.
Fehlermeldung beim Aufruf des lebattery oder anderen Batterietestskripten:
<pre>connect: Connection refused (111)</pre>

Lösung (vorübergehend)
<pre>
sudo rpi-update 8521fd34c8f66b6d109acce943f6e25ec93ec005
</pre>

Mehr dazu unter: {{Link2Forum|Topic=56960|Message=589165}}

'''Das BT-Device ist ständig "absent"''' 
Eine Mögliche Lösung kann sein, das Paket bluez-hcidump zu installieren. Das Werkzeug hcidump erlaubt die Beobachtung von Bluetooth-Aktivitäten.
Dies ist nicht notwendig, wenn bereits bluez installiert ist, da dies Teil des bluez Paketes ist
<pre>
sudo apt-get install bluez-hcidump
</pre>

'''Fehler in Logdateien /var/log/syslog und /var/log/kernel'''
Jul 29 15:08:11 raspberrypi kernel: [ 4905.634211] bt_err_ratelimited: 1 callbacks suppressed
Jul 29 15:08:11 raspberrypi kernel: [ 4905.634231] Bluetooth: hci0 advertising data length corrected
Jul 29 15:08:12 raspberrypi kernel: [ 4906.647350] Bluetooth: hci0 advertising data length corrected
Jul 29 15:08:13 raspberrypi kernel: [ 4907.532081] Bluetooth: hci0 advertising data length corrected
Jul 29 15:08:13 raspberrypi kernel: [ 4907.655564] Bluetooth: hci0 advertising data length corrected

Die Ursache des Problems ist noch nicht ergründet, allerdings betrifft dies aktuell nur den RPi3. Die Fehlermeldungen werden in verschiedene Logs geschrieben. Darunter maßgeblich "syslog" und "kern.log".

Lösung (vorübergehend):
Unterbinden der Einträge durch Anlage eines blocklist Eintrag:

1. Unter "/etc/rsyslog.d" eine Datei erzeugen mit dem Namen "01-blocklist.conf"
2. Inhalt: (Die Ausdrücke in den "" sind diejenigen, die aus dem log verschwinden sollen. - bei mir waren es die untenstehenden")
:msg,contains,"Bluetooth: hci0 advertising data length corrected" stop
:msg,contains,"bt_err_ratelimited:" stop
3. Dienst neu starten "sudo service rsyslog restart"

Weiter Infos werden im offiziellen Thema {{Link2Forum|Topic=28753|Message=499184|LinkText=hier}} diskutiert.

Seit Version 0.82 kann es beim Start zu folgenden Meldungen im Log kommen.
Sep 06 16:13:45 raspberrypi systemd[1]: Started lepresenced.
Sep 06 16:13:45 raspberrypi lepresenced[16010]: [tid:1] main::bluetooth_scan_thread: Received 'Set scan parameters failed: Input/output error', ...tting...
Sep 06 16:13:46 raspberrypi lepresenced[16010]: [tid:1] main::bluetooth_scan_thread: hcitool exited, retrying...

Diese Meldungen können ignoriert werden. Abhilfe schafft sich lepresenced selbst, indem es sich resettet.

'''Moderne iPhones und Android Geräte wechseln in den Schlaf-Modus''', um Energie zu sparen. Somit sind die Geräte zur Anwesenheitserkennung nicht per Ping zu erreichen.
Durch das Programm hping3, lassen sich zyklisch Pakete an die Geräte senden, um sie wieder "aufzuwecken".

Mehr im Forum [https://forum.fhem.de/index.php/topic,76342.0.html]

= Versionsänderungen lepresenced =
<pre>
--Version 0.81 (BasisVersion)
--Version 0.82 (stable 08/2017)
-Neue Kommandozeilenoption "--debug": Startet lepresenced im Vordergrund und gibt ausführliche Debug-Informationen auf STDOUT aus.
-Sanity Check: lepresenced prüft beim Starten die Verfügbarkeit von hciconfig, hcitool und hcidump.
-Model: lepresenced übermittelt das Reading model nun als lan-lepresenced. Das erlaubt die Erkennung von lepresenced in der FHEM-Statistik (sofern aktiviert).
--Version 0.83 (stable 09/2017)
- Behebung von Systemstart Fehlern
- Weitere Debug-Möglichkeiten. U. a. wird nun mitgezählt, ob hcitool lescan ("legacy") und hcidump eine identische Zahl an Beacons empfangen
</pre>

= Ansprechpartner =
# {{Link2FU|117|markusbloch }} (Markus) für das PRESENCE-Modul und collectord
# {{Link2FU|5068|PatrikR}} (Patrick) für lepresenced
# [[Benutzer Diskussion:Devender|Devender]] ({{Link2FU|20043|Dirk}}) für Wiki und Doku

[[Kategorie:Anwesenheitserkennung]]

ROLLO

2019-01-21T15:19:12Z

Sledge:

{{SEITENTITEL:ROLLO}}
{{Infobox Modul
|ModPurpose=Rollo-Steuerung zur einfachen Anzeige/Programmierung
|ModType=h
|ModFTopic=95832


|ModForumArea=Unterstützende Dienste
|ModTechName=44_ROLLO.pm
|ModOwner=KernSani}}
Das Modul [[ROLLO]] bietet eine einfache Möglichkeit, mit ein bis zwei Relais den Hoch-/Runterlauf eines Rolladen zu steuern und punktgenau anzuhalten. Außerdem wird die aktuelle Position in fhem abgebildet.
Über welche Hardware/Module die Ausgänge angesprochen werden ist dabei egal.
__TOC__
Das Modul unterstützt beliebige Konfigurationen welche Befehle ausgeführt werden müssen um die Hardware des Rollos zu steuern.

* Die Rollo-Position wird in 10%-Schritten von 0% (offen) bis 100% (geschlossen) zwischengespeichert um auf der Oberfläche für jede Position ein Icon festlegen zu können.

[[Datei:Rolladen Eintrag.PNG|right|thumb|400px|Verschiedene Ansichten des Rollo:offen, fährt gerade herunter, position 50, fährt gerade hoch, geschlossen]]
Vorteil dieses Moduls:

Ist ein Rollo mit diesem Modul definiert kann man auf der Oberfläche per Klick das Rollo hoch/runter oder auf eine bestimmte Position fahren. Der aktuelle Status des Rollo (fährt hoch/runter,offen,geschlossen,etc.) wird angezeigt.
Die Oberflächenicons werden per devStateIcon gesteuert, Icons und Farben können für jeden Status individuell formatiert werden, die Standard Kommandos auf der Oberfläche (hier: offen, geschlossen, schlitz, Position) können ebenfalls per Attribut angepasst werden. Das Status-Icon ist anklickbar.
Beim Anlegen des Moduls werden die Attribute zur Darstellung in fhem mit Standardwerten angelegt, so dass man sich einiges an Tipparbeit sparen kann, aber trotzdem die Möglichkeit hat die Darstellung individuell anzupassen.

== Voraussetzungen ==
Das eigentliche ansteuern des Rollo muss mit FHEM Befehlen ausführbar sein, diese Modul ist "nur" eine Oberfläche/Bedienmodul, kein Hardwaremodul.

Wenn ROLLO installiert wurde, bevor es Bestandteil von FHEM wurde und lange kein Update gemacht wurde, wirst du die "position" readings und das entsprechende set Kommando vermissen. "position" wurde durch "pct" ersetzt, um Kompatibilität mit anderen Modulen [https://fhem.de/commandref_DE.html#AutoShuttersControl Automatic Shutter Control - ASC] sicher zu stellen. Bitte passe deine NOTIFYs/DOIFs entsprechend an.

== Installation ==

{{Hinweis|Dieses Modul ist in der offiziellen FHEM-Auslieferung enthalten.}}

== Anwendung ==
=== Define ===
define <name> ROLLO

=== Attribute ===
{|class="wikitable"
|-
! Name !! Datentyp/ Wertebereich !! Default-Wert !! Beschreibung
|-
|rl_type ||attr <Rollo-Device> rl_type [normal|HomeKit] ||||Typunterscheidung zur unterstützung verschiedener Hardware. Abhängig vom gewählten Typ wird die Richtung von der die pct gerechnet wird festgelegt:

normal = pct 0 ist offen, pct 100 ist geschlossen
HomeKit = pct 100 ist offen, pct 0 ist geschlossen
|-
|rl_secondsDown||attr <Rollo-Device> rl_secondsDown <number> ||||Sekunden zum hochfahren
|-
|rl_secondsUp ||attr <Rollo-Device> rl_secondsUp <number> ||||Sekunden zum herunterfahren
|-
|rl_excessTop ||attr <Rollo-Device> rl_excessTop <number> ||||Zeit die mein Rollo Fahren muss ohne das sich die Rollo-pct ändert (bei mir fährt der Rollo noch in die Wand, ohne das man es am Fenster sieht, die pct ist also schon bei 0%)
|-
|rl_excessBottom ||attr <Rollo-Device> rl_excessBottom <number> ||||(siehe excessTop)
|-
|rl_switchTime ||attr <Rollo-Device> rl_switchTime <number> ||||Zeit die zwischen 2 gegensätzlichen Laufbefehlen pausiert werden soll, also wenn der Rollo z.B. gerade runter fährt und ich den Befehl gebe hoch zu fahren, dann soll 1 sekunde gewartet werden bis der Motor wirklich zum stillstand kommt, bevor es wieder in die andere Richtung weiter geht. Dies ist die einzige Zeit die nichts mit der eigentlichen Laufzeit des Motors zu tun hat, sondern ein timer zwischen den Laufzeiten.
|-
|rl_resetTime ||attr <Rollo-Device> rl_resetTime <number> ||||Zeit die beim Anfahren von Endpositionen (offen,geschlossen) der Motor zusätzlich an bleiben soll um sicherzustellen das die Endposition wirklich angefahren wurde. Dadurch können Differenzen in der Positionsberechnung korrigiert werden.
|-
|rl_reactionTime ||attr <Rollo-Device> rl_reactionTime <number> ||||Zeit für den Motor zum reagieren
|-
|rl_autoStop ||attr <Rollo-Device> rl_autoStop [0|1] ||||Es muss kein Stop-Befehl ausgeführt werden, das Rollo stoppt von selbst.
|-
|rl_commandUp ||attr <Rollo-Device> rl_commandUp <string> ||||Es werden bis zu 3 beliebige Befehle zum hochfahren ausgeführt
|-
|rl_commandDown ||attr <Rollo-Device> rl_commandDown <string> ||||Es werden bis zu 3 beliebige Befehle zum runterfahren ausgeführt
|-
|rl_commandStop ||attr <Rollo-Device> rl_commandStop <string> ||||Befehl der zum Stoppen ausgeführt wird, sofern nicht commandStopDown bzw. commandStopUp definiert sind
|-
|rl_commandStopDown ||attr <Rollo-Device> rl_commandStopDown <string> ||||Befehl der zum stoppen ausgeführt wird, wenn der Rollo gerade herunterfährt. Wenn nicht definiert wird commandStop ausgeführt
|-
|rl_commandStopUp ||attr <Rollo-Device> rl_commandStopUp <string> ||||Befehl der zum Stoppen ausgeführt wird,wenn der Rollo gerade hochfährt. Wenn nicht definiert wird commandStop ausgeführt
|-
|rl_blockMode ||attr <Rollo-Device> rl_blockMode [blocked|force-open|force-closed|only-up|only-down|half-up|half-down|none] ||||wenn ich den Befehl blocked ausführe, dann wird aufgrund der blockMode-Art festgelegt wie mein Rollo reagieren soll:

blocked = Rollo lässt sich nicht mehr bewegen
force-open = bei einem beliebigen Fahrbefehl wird Rollo hochgefahren
force-closed = bei einem beliebigen Fahrbefehl wird Rollo runtergefahren
only-up = Befehle zum runterfahren werden ignoriert
only-down = Befehle zum hochfahren werden ignoriert
half-up = es werden nur die Positionen 50-100 angefahren, bei pct <50 wird pct 50% angefahren,
half-down = es werden nur die Positionen 0-50 angefahren, bei pct >50 wird pct 50 angefahren
none = block-Modus ist deaktiviert
|-
|automatic-enabled ||attr <Rollo-Device> automatic-enabled [on|off] ||||Wenn auf off gestellt, haben Befehle über Modul ROLLO_Automatic keine Auswirkungen auf diesen Rollo
|-
|automatic-delay ||attr <Rollo-Device> automatic-delay <number> ||||Dieses Attribut wird nur fuer die Modulerweiterung ROLLADEN_Automatic benoetigt.
Hiermit kann einge Zeitverzoegerund fuer den Rolladen eingestellt werden, werden die Rolladen per Automatic heruntergefahren, so wird dieser um die angegebenen minuten spaeter heruntergefahren.
|-
|rl_forceDrive ||attr <Rollo-Device> rl_forceDrive [0|1] ||||open/closed wird ausgeführt, auch wenn das ROLLO bereits in der Zielposition ist
|-
|rl_noSetPosBlocked ||attr <Rollo-Device> rl_noSetPosBlocked [0|1] ||||Wenn deaktiviert, können Positionsn (pct) auch gesetzt werden, wenn der ROLLO geblockt ist. Nach dem unblocken wird die entsprechende Position angefahren.
|-
|||disableattr <Rollo-Device> disable [0|1] ||||Wenn deaktiviert, können keine set oder get commandos für den ROLLO ausgeführt werden.
|-
|||||||
|-
|||||||
|-
|||||||
|}

=== Set ===

{|class="wikitable"
|-
!Name !!set Befehl !!Beschreibung
|-
|open ||set <Rollo-Device> open ||Faehrt das Rollo komplett auf (pct 0)
|-
|closed ||set <Rollo-Device> closed||Faehrt das Rollo komplett zu (pct 100)
|-
|up ||set <Rollo-Device> up ||Faehrt das Rollo um 10 auf (pct +10)
|-
|down ||set <Rollo-Device> down ||Faehrt das Rollo um 10 zu (pct -10)
|-
|half || set <Rollo-Device> half ||Faehrt das Rollo zur haelfte runter bzw. hoch (pct 50)
|-
|stop ||set <Rollo-Device> stop ||Stoppt das Rollo
|-
|drive ||set <Rollo-Device> drive up 5||Fährt das Rollo in die angegebene Richtung für die angegebene Zeit (in Sekunden)
|-
|blocked ||set <Rollo-Device> blocked ||wenn aktiviert, kann der ROLLO nur noch eingeschränkt gesteuert werden. Siehe Attribut block_mode für Details.
|-
|unblocked ||set <Rollo-Device> unblocked ||Aktiviert einen geblockten ROLLO wieder für die normale Benutzung
|-
|pct ||set <Rollo-Device> pct <value> ||Faehrt das Rollo auf eine beliebige pct zwischen 0 (offen) - 100 (geschlossen)
|-
|reset ||set <Rollo-Device> reset <value> ||Sagt dem Modul in welcher pct sich der Rollo befindet
|-
|extern ||set <Rollo-Device> extern <value> ||Der Software mitteilen dass gerade Befehl X bereits ausgeführt wurde und nun z.B,. das berechnen der aktuellen pct gestartet werden soll
|}

=== Get ===

{|class="wikitable"
|-
!Name !!set Befehl !!Beschreibung
|-
|version ||get <Rollo-Device> version ||Gibt die version des Modul Rollos aus
|}

=== Readings ===
{|class="wikitable"
|-
!Name !!Wert !!Beschreibung
|-
|command||open,stop,closed||
|-
|desired_pct||0-100||Zielposition die angefahren werden soll (nur sinnvoll während das Rollo fährt)
|-
|drive-type||modul,extern||bei dem Befehl "set rollo extern .." wird dieses attribut auf "extern" gestellt, sonst immer "modul"
|-
|last_drive||drive-up,drive-down||die zuletzt benutzte Fahrtrichtung
|-
|pct||0-100||exakte Position des Rollo
|-
|state||open,closed,position-[0-100]||die Position gerundet auf ganze 10% Schritte, identisch mit dem Internal STATE
|}

== Anwendungsbeispiele ==
===Set===
set RolladenWohnzimmer pct 50
set RolladenWohnzimmer geschlossen
set RolladenWohnzimmer offen
Drei Beispiele das Rollo-Modul anzuweisen verschiedene Positionen anzufahren.

set RolladenWohnzimmer extern stop
Das Rollo-Modul wird angewiesen den status auf "nicht fahren" zu setzen, die aktuelle Rollo-Position zu berechnen und als neue Position abzuspeichern. Der eigentliche Rollo-Stop-Befehl wird dabei aber nicht gesendet.

set RolladenWohnzimmer reset closed
In der Oberfläche von fhem wird für das Rollo die Position "geschlossen" gespeichert, ohne Berechnungen durchzuführen oder Hardware zu steuern. Wird evtl. benötigt wenn der Ist-Status von den Soll-Werten aus fhem abweicht.

===Zusammenspiel mit externem Taster===
In einem Anwendungszenario hat ein Nutzer zusätzliche Taster an seinem Rollo-Motor über die er ihn ebenfalls steuern kann.
Die Taster selber senden keine Events an fhem, nur der Rollo-Motor.
Hier ein Beispiel wie das ganze für aussehen könnte und diese Taster in das ROLLO-Modul integriert werden:

define rollo_manuell_auf DOIF ([meinRollo_Kanal1] eq "on" and [?meinRolloModul] ne "drive-up") (set meinRolloModul extern open) DOELSEIF ([meinRollo_Kanal1] eq "off" and [?meinRolloModul] eq "drive-up") (set meinRolloModul extern stop)
define rollo_manuell_ab DOIF ([meinRollo_Kanal2] eq "on" and [?meinRolloModul] ne "drive-down") (set meinRolloModul extern closed) DOELSEIF ([meinRollo_Kanal2] eq "off" and [?meinRolloModul] eq "drive-down") (set meinRolloModul extern stop)

meinRollo_Kanal1 und meinRollo_Kanal2 sind die Hardwarekanäle die in dem Rollo-Modul zum hochfahren/runterfahren benutzt werden.
Das erste DOIF prüft ob das Rollo hoch fährt, ohne das das Rollo-Modul davon etwas weis. Ist dem so wird dem Rollo Modul mithilfe des set <extern> mitgeteilt das das Rollo bereits gestartet wurde. Das Modul fängt an die Zeit zu zählen und aktualisiert den Status der Oberfläche auf "fahre hoch".
IM DOELSEIF wird abgefragt ob das Rollo steht, obwohl das Modul denkt das Rollo würde noch fahren. Ist dem so wird wieder mithilfe des set <extern> dem Modul mitgeteilt das das Rollo gestoppt wurde. Das Modul berechnet nun aufgrund der gefahrenen Zeit die aktuelle Position und aktualisiert den Status der Oberfläche auf die Position.

Das gleiche wird dann im zweiten DOIF nochmal für das herunterfahren gemacht.

Man kann nun das Rollo sowohl über die Oberfläche als auch per Taster bedienen und fhem und der reale Ist-Status sind synchron. Ach eine gleichzeitige Bedienung ist möglich, Das Rollo startet z.B. aufgrund einer Automatisierung morgens zum hochfahren und man klickt schnell auf den Taster neben dem Bett und stoppt das ganze wieder.

== Links ==

Thread im {{Link2Forum|Topic=95832|LinkText=Forum}} seit das Modul Bestandteil der offiziellen FHEM Auslieferung ist

Thread im {{Link2Forum|Topic=47202|LinkText=Forum}} bevor das Modul Bestandteil von FHEM war

STELLMOTOR

2019-01-05T10:48:06Z

Sledge: Korrektur 0,1 auf 1,1 für Rechtslauf / Wechsel in Tabelle

{{SEITENTITEL:STELLMOTOR}}
{{Infobox Modul
|ModPurpose=Stellmotor-Steuerung mit Zeitabweichungskorrektur
|ModType=x


|ModForumArea=Codeschnipsel
|ModTechName=39_STELLMOTOR.pm
|ModOwner=epsrw1,cwagner}}
Das Modul [[STELLMOTOR]] bietet eine einfache Möglichkeit, mit zwei Relais den Rechts-/Linkslauf eines Motors zu steuern und punktgenau anzuhalten.

== Features ==
Diese Wiki-Seite beschreibt die Version 3.0 des STELLMOTOR Moduls.

----

* Wiedereintrittsfähig nach einem Neustart
* Wiederholungsgenauigkeit durch Ausgleich von Rundungs- und Laufzeitabweichungen
* Vermeiden von Blockade des FHEM während der Laufzeit des Motors

Thread im {{Link2Forum|Topic=23933|LinkText=Forum}} mit der jeweils aktuellen Version des Moduls als Anhang im ersten Beitrag.

== Beschreibung ==
[[Datei:dok39_STELLMOTOR.jpg|mini|Funktionsweise]]

Vorrangig ist dieses Modul für zwei Relais an GPIO- oder an PIFace-Pins eines [[Raspberry Pi|Raspberrys]] gedacht. Andere Einplatinencomputer werden mit dem Device-Typ SysCmd unterstützt. Es bietet zusätzlich auch die Option, zwei Schaltaktoren per Funk (aus Timinggründen nicht empfohlen) oder 1-Wire anzusteuern.

Aus den Werten MaxTics (Default=100, für Prozentanzeige) und MaxDriveSeconds (Laufzeit des Motors von 0 bis 100%) wird die Zeit berechnet, die der Motor nach rechts oder links laufen muss, um die mit set gewünschte Motorstellung zu erreichen.

FHEM läuft dann weiter ohne einzufrieren, und prüft in einer Schleife nur noch ob, die Stoppzeit im Cache erreicht ist. Da der Stopp nie exakt zur geplanten Zeit ausgeführt wird, liegt im Cache ein weiterer Wert, der die Differenz zwischen geplanter und tatsächlicher Stoppzeit dem nächsten Kommando hinzurechnet. So werden sich addierende kleine Zeitdifferenzen vermieden.

Der Befehl "stop" hält den Motor sofort an und berechnet den aktuellen Stand neu.

Zum Kalibrieren (set calibrate) fährt der Motor einfach volle Zeit nach in eine Richtung (default=links, über attr auch rechts einstellbar). Hier wird der in Getriebemotoren meist eingebaute Endschalter genutzt, um den "Null-Punkt" sicher zu finden. Falls ein angeschlossener Motor solche Endschalter nicht hat, müssen diese für diese Schaltungsweise unbedingt vorgesehen werden. Übliche Montagepunkte sind ein Wellrad an der Ansgangswelle, an Endpunkten des zu bewegenden Objektes oder direkt am Motor gegen eine drehend gefedert gelagerte Motoraufhängung.

Anwendungsszenarien für das Modul sind unter Anderem:
* [[Mischersteuerung|3- oder 4-Wege Heizkreis-Mischer]]
* Solarspeicher|Warmwasser-Mischventil für Solarspeicher
* Eigenbau-Heizungsthermostate
* Eigenbau-Rolladensteuerung
* (Dach-)Fensteröffner
* Beamer-Leinwand
* Heliostaten
* ....

== Define ==
:<code>define <name> STELLMOTOR <PiFace|Gpio|FhemDev|SysCmd> </code>

Je nach Device Typ sind verschiedene Attribute erforderlich, damit STELLMOTOR weiß, wie die beiden Relais angeschlossen sind.
* '''PiFace''' und '''Gpio''' benötigen STMgpioPortRL und STMgpioPortSTART
* '''FhemDev''' benötigt STMfhemDevRL und STMfhemDevSTART
* '''SysCmd''' benötigt STMsysCmdRL und STMsysCmdSTART

Für den Schaltvorgang "baut" STELLMOTOR einen set-Befehl zusammen. Beispielsweise bei FhemDev
<code>
set <**..PortRL> 0 sowie set <**..PortSTART> 1 zum Einschalten links
set <**..PortRL> 1 sowie set <**..PortSTART> 0 zum Einschalten rechts (bei Type "einzel", sonst 1,1)
set <**..PortRL> 0 sowie set <**..PortSTART> 0 zum Ausschalten
</code>

* Die Schaltbefehle 0 und 1 können mit Attributen invertiert und/oder gemapped werden (z.B.: On/Off)

Um die Wirkung auszuprobieren, ohne jedes Mal zum Motor rennen zu müssen, bietet sich an, zwei '''Dummys''' zu verwenden:

<code>
define Stellmotor2rl dummy

define Stellmotor2start dummy
</code>

<code>
set <name> 45
</code>

stellt den Motor nun auf 45%. Angenommen, er stand bei 10%, wird er nun (45-10)*MaxDriveSeconds/MaxTics Sekunden lang nach rechts laufen und dann von STELLMOTOR gestoppt.

<code>
set <name> stop
</code>

stellt den Motor während einer laufenden Bewegung sofort ab und berechnet den Stand neu.

Diese beiden Bilder zeigen die elektrische Verdrahtung von zwei Relais, die von je einem Aktor gesteuert werden:
[[Datei:Relais-Schaltung FBH-Mischer attr einzel.jpg|mini|Schaltplan einzel]] [[Datei:Relais-Schaltung FBH-Mischer attribut Wechsel.jpg|mini|Schaltplan wechsel]]

Typische Getriebemotoren haben eingebaute Endschalter, die beim Erreichen der 0%- oder 100%-Position die Stromversorgung unterbrechen. Das Modul Stellmotor nutzt dies aus, um eine Kalibrierung zwischen rechnerischem und tatsächlichen Stand herzustellen.

== Attribute ==
Alle Attribute sind auch in FHEM durch das Kommando get attrHelp <varname> erklärt, für's "schnelle Nachschauen zwischendurch".

=== Global gültige Attribute ===
{| class="wikitable sortable"
|-
! Parameter !! Wertebereich !! Default !! Beschreibung
|-
| STMrlType|| String || einzel || je nach Schaltplan, Wechsel=start+RL-relais, einzel=R-Relais+L-Relais werden geschaltet
'''ACHTUNG:''' falsche Einstellung kann zu Kurzschluss am Motor führen, bitte Einstellung genau überdenken oder mit dummy testen

bei Einzel:
Rechtslauf: start=0 rl=1
Linkslauf: start=1 rl=0 Ruhe:
start=0 rl=0

bei Wechsel:
Rechtslauf start=1 rl=1
Linkslauf: L start=1 rl=0
Ruhe: start=0 rl=0

|-
|STMmaxDriveSeconds ||[0...n]||muss angepasst werden||gestoppte Zeit in Sekunden, die der Motor für die Fahrt von 0 bis 100 Prozent braucht
|-
|STMmaxTics ||[0...100]||100||Motorstellung - bei Prozentangaben 100, bei Winkelangaben anzupassen
|-
|STMpollInterval || Float ||0.1||Zeitintervall nach dem FHEM prüft, ob die interne Stoppzeit erreicht wurde. Hier sollte mit einem möglichst kleinen Wert gestartet werden, der vorsichtig erhöht werden kann, falls FHEM zu langsam läuft wegen des Stellmotors. Darf nicht größer STMlastDiffMax sein, sonst beginnt der Motor zu schwingen.
|-
| STMresetOtherDeviceAtCalibrate|| String || 0 || FHEM Device das am Ende des Kalibriervorganges zusätzlich resettet wird. (command:
set <STMresetOtherDeviceAtCalibrate> reset" wird abgesetzt), zB für eigenes Logging oder Rotary Encoder
|-
| STMinvertOut|| Zahl || 0 || setzen für Devices die 0 für Start und 1 für Stop erwarten
|-
| STMmapOffCmd|| String || 0 || string der im device-command anstelle '0' verwendet wird für stop
|-
| STMmapOnCmd|| String || 0 || string der im device-command anstelle '1' verwendet wird für start
|-
| STMcalibrateDirection|| String || L || auf R wird die Ralibrierung nach rechts gefahren, default= L (links)
|-
| STMlastDiffMax|| Zahl || 1|| ist die Stoppzeit weiter als dieser wert vom Soll entfernt, wird sofort ein neuer drive
gestartet. Wert muss immer größer als STMpollInterval sein, sonst beginnt der Motor zu schwingen
|-
| STMtimeTolerance|| Float || 0.001 || Stop-Time Differenzen kleiner als dieser Wert werden bei der Berechnung vollständig
ignoriert (Parameter wird voraussichtlich in der nächsten Modulversion entfallen)
|-
| STMdebugToLog3|| Zahl || 0/1 || Debug Informationen ins Log schreiben. Achtung, kann eine Menge Daten verursachen, falls
man vergisst, es wieder abzuschalten!
|-
| disable|| Zahl || 0/1 || Motor einfrieren. Neue Befehle werden in command_queue zwischengespeichert
|-
|-
|readingFnAttributes||||||readingFnAttributes
|}

=== Device Type abhängige Attribute ===

Je nach Device Type sind verschiedene Attribute vorgesehen, um STELLMOTOR mitzuteilen, wie die beiden Relais angesprochen
werden. Man kann so z. B. während der Aufbauphase der Installation neben den Gpio devices noch 2 dummy devices im Attr
vorhalten um zwischendurch zu testen. Hierzu muss dann nur noch die DEF des STELLMOTOR Devices vorübergehend auf FhemDev
geändert werden.

Alle Attributes sind auch in FHEM durch das kommando get attrHelp <varname> erklärt, für das "schnelle Nachschauen zwischendurch".

{| class="wikitable sortable"
|-
! Device Type !! Parameter !! Typ !! Default !! Beschreibung
|-
| PiFace / Gpio || STMgpioPortRL || Zahl || 5 || PiFace Digital port oder Gpio-Port für RL oder R Relais
|-
| PiFace / Gpio || STMgpioPortSTART || Zahl || 4 || PiFace Digital Port oder Gpio-Port für START (oder L Relais bei 'einzel')
|-
| FhemDev || STMfhemDevRL|| String || RelaisRL || FHEM-Device name für RL (oder R) Aktor (zB.: 'keller portB' oder 'dummyRLrelais')
|-
| FhemDev || STMfhemDevSTART|| String || RelaisSTART || FHEM-Device name für START (oder L) Aktor (zB.: 'keller portC' oder 'dummySTARTrelais')
|-
| SysCmd || STMsysCmdRL|| String || 0 || freies Command, das für RL an die Shell übergeben wird (zB: '/Usr/local/bin/gpio write 4', STELLMOTOR fügt 0 oder 1 arg. dazu)
|-
| SysCmd || STMsysCmdSTART|| String || 0 || freies Command, das für START an die Shell übergeben wird (zB: '/Usr/local/bin/gpio write 5', STELLMOTOR fügt 0 oder 1 arg. am Ende dazu)
|-
|}

----

== Settings ==

{| class="wikitable sortable"
|-
! SET !! Wertebereich !! Beschreibung
|-
|set <name> N||[1...100]||stellt den Mischer auf N % Öffnung. Dieser Wert muss ganzzahlig sein
|-
|set <name> stop || - || stoppt die laufende Bewegung sofort und berechnet den Positionswert neu
|-
|set <name> calibrate|| - ||stellt den Mischer auf Min. oder Max. (in FHEM 1% oder 100%); default: maximaler Linkslauf bis zur Endschalterpostion. Kann über Attr in Rechtslauf geändert werden.
|-
|set <name> reset|| - ||Setzt die Position und die Werte im Cache auf Null. Verwendung ist intern (am Ende von calibrate) oder nach mechanischem Neueinbau des Motors (da reicht aber auch ein Calibrate)
|}

----

== Readings ==

Alle Readings sind auch in FHEM durch das Kommando get readingsHelp <varname> erklärt, für das "schnelle nachschauen zwischendurch".

{| class="wikitable sortable"
|-
! readings !! Wertebereich !! Beschreibung
|-
|position||[1..100%]||der Wert wird gesetzt am Beginn einer Mischerbewegung (anderer Wertebereich, wenn MaxTics nicht 100)
|-
|state||active,error,position||Position wird beim Stopp der Motorbewegung gesetzt
|-
|lastStart|| Float ||Zeitstempel der letzten Motorbewegung
|-
|locked||[0 1]||Steht auf 1 während der Motor gerade läuft (Calibrate oder gewünsche Position per set).

Neue Kommandos werden während lock nur in eine Warteschleife (reading: command_queue) genommen.

Zeigt im im Frontend, dass der Motor gerade läuft.
|-
|queue_lastdiff||||Letzte Zeitdifferenz beim Stopp: abhängig von der Systemlast oder anderen blockierenden Kommandos wird das Stopp-Kommando nur nahe an der kalkulierten Stoppzeit ausgeführt, potentiell niemals exakt zum berechneten Zeitpunkt. STELLMOTOR merkt sich die Zeitdifferenz zwischen geplantem und tatsächlichem Stopp und addiert bei der nächsten Bewegung des Motors die Differenz, um möglichst präzise die gewünschte Motorstellung zu erreichen.
|-
|stopTime||||Null oder die errechnete Zeit zum Stopp der Motorbewegung
|-
|command_queue||||Position einer anstehenden neuen Motorposition, die angefordert wurde als die letzte Motorbewegung noch ausgeführt oder das Modul disabled war
|-
|OutType||||Bei der Defintion gewählte Arbeitsart: PiFace, Gpio, FhemDev, SysCmd
|-
|DoResetAtStop||||Zeitstempel des Ende der letzten Kalibrierfahrt
|}

----

== Weblinks ==
* {{Link2Forum|Topic=23933|LinkText=Thread im Forum}}, in dem dieses Modul vorgestellt wurde
* to be continued

[[Kategorie:Other Components]]
[[Kategorie:Heizungssteuerung]]
[[Kategorie:Raspberry Pi]]

Mischersteuerung

2019-01-05T10:46:38Z

Sledge: Fehler bei Beschreibung Rechtslauf / Wechsel korrigiert (1,1 anstelle 0,1 in der Tabelle)

{{Infobox Modul
|ModPurpose=Stellmotor Zeitsteuerung mit Zeitabweichungskorrektur
|ModType=x


|ModForumArea=Codeschnipsel
|ModTechName=39_STELLMOTOR.pm
|ModOwner=epsrw1,cwagner}}
Das FHEM-[[:Kategorie:Hilfsmodul|Hilfsmodul]] [[STELLMOTOR]] bietet eine einfache Möglichkeit, mit zwei Relais den Rechts-/Linkslauf eines (Mischer)motors zu steuern.

== Features ==

Diese Wiki-Seite beschreibt die Version 2.1 des STELLMOTOR Moduls.

----

* Wiedereintrittsfähig nach einem Neustart
* Wiederholungsgenauigkeit durch Ausgleich von Rundungs- und Laufzeitabweichungen
* Vermeiden von Blockade des FHEM während der Laufzeit des Motors

Thread im Forum:{{Link2Forum|Topic=23933}}

== Beschreibung ==

[[Datei:dok39_STELLMOTOR.jpg|mini|Funktionsweise]]
Typischerweise werden im Heizkreislauf Mischer eingesetzt, um einen Heizkreis mit unabhängig vom Kesselbrenner geregelten Vorlauf zu erreichen. Auch kann man so in einer Heizanlage, die mit für Fußbodenheizung zu hohen Vorläufen arbeiten muss, einen Kreis mit begrenztem Vorlauf abzuzweigen.

Mit Hilfe des hier beschriebenen Moduls VALVES [[Raumbedarfsabh%C3%A4ngige Heizungssteuerung]] kann ein geschlossener Regelkreislauf hergestellt werden, der sich am Bedarf der Wohnräume orientiert.

Vorrangig ist dieses Modul für zwei Relais an GPIO- oder an PIFace-Pins eines Rasberrys gedacht; es bietet aber auch die Option, zwei Schaltaktoren per Funk (aus Timinggründen nicht empfohlen) oder 1-Wire anzusteuern.

Die Set-Befehle für die Mischerstellung kommen idealerweise aus der Bewertung der Vorlauftemperatur durch ein Modul wie PID20 [[PID20 - Der PID-Regler]]. Dieser berücksichtigt auch den zeitlichen Verlauf der Temperaturänderungen im Vorlauf und ist vielfältig anpassbar.

Aus den Werten MaxTics (Default=100, für Prozentanzeige) und MaxDriveSeconds (Laufzeit des Motors von 0 bis 100%) wird die Zeit berechnet, die der Motor nach rechts oder links laufen muss, um die mit set gewünschte Ventilstellung zu erreichen.

FHEM läuft dann weiter ohne einzufrieren, und prüft im Loop nur noch ob, die Stoppzeit im Cache erreicht ist. Da der Stopp nie exakt zur geplanten Zeit ausgeführt wird, liegt im Cache ein weiterer Wert der die Differenz zwischen geplanter und tatsächlicher Stoppzeit dem nächsten Kommando hinzurechnet. So werden sich addierende kleine Zeitdifferenzen vermieden.

Zum Kalibrieren (set calibrate) fährt der Motor einfach volle Zeit nach links/null. Hier wird der in Mischermotoren wie dem Honeywell Centra VMK eingebauten Entschaltetr genutzt, um den "Null-Punkt" sicher zu finden. Falls ein angeschlossener Motor solche Endschalter nicht hat, müssen die für diese Schaltungsweise unbedingt vorgesehen werden.

== Define ==
<code>
define <name> STELLMOTOR <PiFace|Gpio|FhemDev|SysCmd>
</code>
Je nach Device Typ sind verschiedene Attribute zur erforderlich, damit STELLMOTOR weiß wie die beiden Relais angeschlossen sind.
* '''PiFace''' und '''Gpio''' benötigen STMgpioPortRL und STMgpioPortSTART
* '''FhemDev''' benötigt STMfhemDevRL und STMfhemDevSTART
* '''SysCmd''' benötigt STMsysCmdRL und STMsysCmdSTART

Für den Schaltvorgang "baut" STELLMOTOR einen set-Befehl zusammen. Beispielsweise bei FhemDev
<code>
set <**..PortRL> 0 sowie set <**..PortSTART> 1 zum Einschalten links
set <**..PortRL> 1 sowie set <**..PortSTART> 0 zum Einschalten rechts (bei Type "einzel", sonst 1,1)
set <**..PortRL> 0 sowie set <**..PortSTART> 0 zum Ausschalten
</code>

* Die Schaltbefehle 0 und 1 können mit Attributen invertiert und/oder gemapped werden (zB.: On/Off)

Um die Wirkung auszuprobieren, ohne jedes Mal zum Mischer rennen zu müssen, bietet sich an zwei '''Dummys''' zu verwenden:

<code>
define Stellmotor2rl dummy

define Stellmotor2start dummy
</code>

<code>
set <name> 45
</code>

stellt den Mischer nun auf 45%. Angenommen, stand er bei 10%, wird er nun (45-10)*MaxDriveSeconds/MaxTics Sekunden lang nach rechts laufen und dann von STELLMOTOR gestoppt.

Diese beiden Bilder zeigen die elektrische Verdrahtung von zwei Relais, die von je einem Aktor gesteuert werden:
[[Datei:Relais-Schaltung FBH-Mischer attr einzel.jpg|mini|Schaltplan einzel]] [[Datei:Relais-Schaltung FBH-Mischer attribut Wechsel.jpg|mini|Schaltplan wechsel]]

Typische Mischermotoren wie der Honeywell VMK haben eingebaute Endschalter, die beim Erreichen der 0%- oder 100%-Position die Stromversorgung unterbrechen. Das Modul Stellmotor nutzt dies aus, um eine Kalibrierung zwischen rechnerischem und tatsächlichen Mischerstand herzustellen.

----

== Attribute ==

Alle Attributes sind auch in FHEM durch das kommando get attrHelp <varname> erklärt, für's "schnelle Nachschauen zwischendurch".

=== Global gültige Attribute ===

{| class="wikitable sortable"
|-
! Parameter !! Wertebereich !! Default !! Beschreibung
|-
| STMrlType|| String || einzel || je nach Schaltplan, Wechsel=start+RL-relais, einzel=R-Relais+L-Relais werden geschaltet
'''ACHTUNG:''' falsche Einstellung kann zu Kurzschluß am Motor führen, bitte Einstellung genau überdenken oder mit dummy testen

bei einzel:
Rechtslauf: start=0 rl=1
Linkslauf: start=1 rl=0 Ruhe:
start=0 rl=0

bei wechsel:
Rechtslauf start=1 rl=1
Linkslauf: L start=1 rl=0
Ruhe: start=0 rl=0

|-
|STMmaxDriveSeconds ||[0...n]||muss angepasst werden||gestoppte Zeit in Sekunden, die der Motor für die Fahrt von 0 bis 100 Prozent braucht
|-
|STMmaxTics ||[0...100]||100||Mischerstellung - bei Prozentangaben (PID20) 100, bei Winkelangaben anzupassen
|-
|STMpollInterval || Float ||0.1||Zeitintervall nach dem FHEM prüft, ob die interne Stoppzeit erreicht wurde. Hier sollte mit einem möglichst kleinen Wert gestartet werden, der vorsichtig erhöht werden kann, falls FHEM zu langsam läuft wegen des Mischermotors. Darf nicht größer STMlastDiffMax sein, sonst beginnt der Motor zu Schwingen.
|-

| STMresetOtherDeviceAtCalibrate|| String || 0 || FHEM Device das am Ende des Kalibriervorganges zusätzlich resettet wird. (command: set <STMresetOtherDeviceAtCalibrate> reset" wird abgesetzt), zB für eigenes Logging oder Rotary Encoder
|-
| STMinvertOut|| Zahl || 0 || setzen für Devices die 0 für Start und 1 für Stop erwarten
|-
| STMmapOffCmd|| String || 0 || string der im device-command anstelle '0' verwendet wird für stop
|-
| STMmapOnCmd|| String || 0 || string der im device-command anstelle '1' verwendet wird für start
|-
| STMcalibrateDirection|| String || L || auf R wird die Ralibrierung nach rechts gefahren, default= L (links)
|-

| STMlastDiffMax|| Zahl || 1|| ist die Stoppzeit weiter als dieser wert vom Soll entfernt, wird sofort ein neuer drive gestartet. Wert muss immer größer als STMpollInterval sein, sonst beginnt der Motor zu Schwingen
|-
| STMtimeTolerance|| Float || 0.001 || Stop-Time Differenzen kleiner als dieser Wert werden bei der Berechnung vollständig ignoriert (wird eventuell in Zukunft entfallen)
|-

|-
|readingFnAttributes||||||readingFnAttributes
|}

=== Device Type abhängige Attribute ===

Je nach Device Type sind verschiedene Attribute vorgesehen, um STELLMOTOR mitzuteilen, wie die beiden Relais angesprochen werden. Man kann so zB während der Aufbauphase der Installation neben den Gpio devices noch 2 dummy devices im Attr vorhalten um zwischendurch zu testen. Hierzu muss dann nur noch die DEF des STELLMOTOR Devices vorübergehend auf FhemDev geändert werden.

Alle Attributes sind auch in FHEM durch das kommando get attrHelp <varname> erklärt, für's "schnelle Nachschauen zwischendurch".

{| class="wikitable sortable"
|-
! Device Type !! Parameter !! Typ !! Default !! Beschreibung
|-
| PiFace / Gpio || STMgpioPortRL || Zahl || 5 || PiFace Digital port oder Gpio-Port für RL oder R Relais
|-
| PiFace / Gpio || STMgpioPortSTART || Zahl || 4 || PiFace Digital Port oder Gpio-Port für START (oder L Relais bei 'einzel')
|-
| FhemDev || STMfhemDevRL|| String || RelaisRL || FHEM-Device name für RL (oder R) Aktor (zB.: 'keller portB' oder 'dummyRLrelais')
|-
| FhemDev || STMfhemDevSTART|| String || RelaisSTART || FHEM-Device name für START (oder L) Aktor (zB.: 'keller portC' oder 'dummySTARTrelais')
|-
| SysCmd || STMsysCmdRL|| String || 0 || freies Command das für RL an die Shell übergeben wird (zB: '/Usr/local/bin/gpio write 4', STELLMOTOR fügt 0 oder 1 arg. dazu)
|-
| SysCmd || STMsysCmdSTART|| String || 0 || freies Command das für START an die Shell übergeben wird (zB: '/Usr/local/bin/gpio write 5', STELLMOTOR fügt 0 oder 1 arg. am Ende dazu)
|-
|}

== Settings ==

{| class="wikitable sortable"
|-
! SET !! Wertebereich !! Beschreibung
|-
|set <name> N||[1...100]||stellt den Mischer auf N % Öffnung
|-
|set <name> stop|| - ||stoppt die laufende bewegung sofort und berechnet den aktuellen positionswert neu
|-
|set <name> calibrate|| - ||stellt den Mischer auf Min. oder Max (in FHEM 1% oder 100%); default: maximaler Linkslauf bis zur Endschalterpostion, kann über Attr in Rechtslauf geändert werden.
|-
|set <name> reset|| - ||Setzt die Position und die Werte im Cache auf Null. Verwendung ist intern (am Ende von calibrate) oder nach mechanischem Neueinbau des Motors (da reicht aber auch ein Calibrate)
|}

== Readings ==

Alle Readings sind auch in FHEM durch das kommando get readingsHelp <varname> erklärt, für's "schnelle nachschauen zwischendurch".

{| class="wikitable sortable"
|-
! readings !! Wertebereich !! Beschreibung
|-
|position||[1..100%]||der Wert wird gesetzt am Beginn einer Mischerbewegung (anderer Wertebereich, wenn MaxTics nicht 100)
|-
|state||active,error,position||Position wird beim Stopp der Motorbewegung gesetzt
|-
|lastStart|| Float ||Zeitstempel der letzten Motorbewegung
|-
|locked||[0 1]||Steht auf 1 während der Motor gerade läuft (Calibrate oder gewünsche Position per set).

Neue Kommandos werden während lock nur in eine Warteschleife (reading: command_queue) genommen.

Zeigt im im Frontend, dass der Motor gerade läuft.
|-
|queue_lastdiff||||abhängig von der FHEM-Last oder anderen blockierenden Kommandos wird das Stopp-Kommando nur nahe an der kalkulierten Stoppzeit ausgeführt, vermutlich nie exakt. STELLMOTOR merkt sich die Zeitdifferenz, zu der der Motor wirklich gestoppt wurde und addiert bei der nächsten Bewegung des Motors die Differenz, um möglichst präzise die wirkliche Motorstellung zu erreichen.
|-
|stopTime||||Null oder die errechnete Zeit zum Stopp der Motorbewegung
|-
|command_queue||||Position einer anstehenden neuen Motorposition, die angefordert wurde als die letzte Motorbewegung noch ausgeführt oder das Modul disabled war
|-
|OutType||||Bei der Defintion gewählte Arbeitsart: PiFace,Gpio,FhemDev,SysCmd
|-
|DoResetAtStop||||Zeitstempel des Ende der letzten Kalibrierfahrt
|}

== Weblinks ==
* [http://forum.fhem.de/index.php/topic,23933.msg174400.html#new Thread im Forum], in dem dieses Modul vorgestellt wurde
* to be continued

[[Kategorie:Regelungstechnik]]
[[Kategorie:Examples]]
[[Kategorie:Heizungssteuerung]]

Watchdog

2019-01-04T13:08:20Z

Sledge:

{{SEITENTITEL:watchdog}}

{{Infobox Modul
|ModPurpose=Zeitverzögerte Ausführung von Aktionen beim Ausbleiben von Ereignissen
|ModType=h

|ModCmdRef=watchdog
|ModTechName=91_watchdog.pm
|ModOwner=rudolfkoenig / [http://forum.fhem.de/index.php?action=profile;u=8 rudolfkoenig]
}}

[[watchdog]] ist ein Fhem-Erweiterungsmodul, mit dem z. B. zeitverzögert auf das Ausbleiben von Ereignissen reagiert werden kann. In Verbindung mit [[THRESHOLD]] kann auch auf das Über- oder Unterschreiten von Schwellenwerten reagiert werden.

== Voraussetzungen ==
Keine.

== Anwendung ==
{{Randnotiz|RNText=Die Reaktivierung des watchdog hat mit dem Befehl <code><nowiki>trigger <device> .</nowiki></code> (Achtung, den Punkt nicht vergessen!) oder durch Setzen des Attributs <code>autoRestart</code> zu erfolgen. Die in Blogs und Forumsbeiträgen häufiger zu findende Variante mit <code><nowiki>setstate</nowiki></code> entspricht nicht und entsprach nie der commandref. Sie funktioniert nur "aus Versehen". Es existiert dafür kein Bestandsschutz und unerwünschte Seiteneffekte sind nicht auszuschließen!}}
:<code>define <name> watchdog <regexp1> <timespec> <regexp2> <command> </code>
=== Define ===
Führe Befehl <command> aus, wenn nach Ereignis <regexp1> nicht innerhalb der Zeitspanne <timespec> das Ereignis <regexp2> auftritt.

=== Attribute ===

== Anwendungsbeispiele ==

=== Heizungsabschaltung bei geöffnetem Fenster ===
Wenn der Tür-/Fensterkontakt an der Balkontür (MAX_WZ_SK) länger als 15 Sekunden geöffnet ist, wird die Heizung im Wohnzimmer (MAX_WZ) ausgeschaltet:

<code>define wd_WZ_SK_opened watchdog MAX_WZ_SK:opened.* 00:00:15 MAX_WZ_SK:closed.* set MAX_WZ desiredTemperature off;; trigger wd_WZ_SK_opened .</code>

Der Befehl <code>trigger wd_WZ_SK_opened .</code> schaltet den watchdog nach einem Auslösen wieder in den Ursprungszustand. Ohne diesen Befehl würde der watchdog nur genau einmal auslösen. Statt über den angehängten Befehl <code>trigger wd_WZ_SK_opened .</code> könnte man auch durch Setzen des Attributes <code>autoRestart</code> für den watchdog (<code>attr wd_WZ_SK_opened autoRestart 1</code>) ein automatisches Rücksetzen in den Ursprungszustand (state = "defined") erreichen.

Quelle: {{Link2Forum|Topic=51387}}

=== Unterstützung der Statusermittlung für die Module RESIDENTS, ROOMMATE, GUEST ===
Ein watchdog kann bei der Statusermittlung eines Bewohners im Rahmen der Modulfamilie {{Link2CmdRef|Anker=RESIDENTS|Label=RESIDENTS}}, {{Link2CmdRef|Anker=ROOMMATE|Label=ROOMMATE}} und {{Link2CmdRef|Anker=GUEST|Label=GUEST}} genutzt werden. Mit folgender watchdog-Defintion wird der Status von Resident Ralf (rr_Ralf) automatisch 10 Minuten nach Umschalten auf den Status gotosleep auf asleep gesetzt, wenn keine andere Statusmeldung kommt:

<code>define wd_Ralf_gotosleep_asleep watchdog rr_Ralf:gotosleep.* 00:10:00 rr_Ralf:(home|absent|gone|none|asleep|awoken) set rr_Ralf asleep;; trigger wd_Ralf_gotosleep_asleep .</code>

Quelle: {{Link2Forum|Topic=51387}}

== Links ==
* Vorstellung einer Lösung im {{Link2Forum|Topic=23260}}, zeitverzögert auf das Ausbleiben von Temperaturwerten eines Sensors zu reagieren. (HINWEIS: Die Reaktivierung des watchdog im verlinkten Thema mit <code><nowiki>setstate <device> defined</nowiki></code> ist entsprechend commandref durch <code><nowiki>trigger <device> .</nowiki></code> oder Aktivierung des Attributs <code>autoRestart</code> zu ersetzen.)
* [[Watchdog kombiniert mit Threshold]]

Shelly-Aktoren

2018-11-27T19:13:53Z

Sledge:

{{
Infobox Modul
|ModPurpose=Das Modul 36_Shelly.pm stellt ein Interface zum Schalten der Shelly-Aktoren zur Verfügung
|ModType=d

|ModCmdRef=Shelly
|ModForumArea=Sonstige Systeme
|ModTechName=36_Shelly.pm
|ModOwner=Prof. Dr. Peter A. Henning
}}
Auf dieser Seite werden die Aktoren des bulgarischen Herstellers Shelly beschrieben sowie deren Ansteuerung mit FHEM und aufgetretene Probleme. Es handelt sich um IP-basierte Schaltaktoren, die angesteuert werden können
*über die Web-Oberfläche des eingebauten Mikro-Webservers
*über eine proprietäre App des Herstellers (Achtung, Cloud!)
*über das FHEM-Modul 36_Shelly.pm
*über MQTT
Ein Teil der Aktoren verfügt über eine eingebaute Leistungsmessung.
= Geräteübersicht =
{| class="wikitable mw-datatable"
!style="width:50px"|Modell
!style="width:50px"|Typ
!style="width:20px"|Aktor-Kanäle
!style="width:20px"|Mess-kanäle
!style="width:650px"|Bemerkungen
|-
|ShellyPlug
|Schalter
|1
|
|-
|Shelly1
|Schalter
|1
|
|-
|Shelly2
|Schalter/Rollladen
|2/1
|1
|-
|Shelly4Pro
|Schalter
|4
|4
|}
= Einbindung in FHEM =
== Out-of-the Box ==
*Schließen Sie den Aktor nach Vorschrift an
*Suchen Sie mit einem WLAN-fähigen Gerät (Laptop oder Smartphone) nach dem internen Access Point, der durch den Aktor erzeugt wird. Typischerweise hat dieser eine SSID ähnlich wie
shelly1-..., shellyswitch-..., shelly4pro-...,
*Verbinden Sie Ihr Gerät mit diesem Access Point. Typischerweise bekommt Ihr Gerät dabei die IP-Adresse 192.168.33.2 zugewiesen.
*Im Browser dieses Gerätes einfach die IP-Adresse 192.168.33.1 aufrufen - das ist der Shelly selbst, in dieser Web-Oberfläche kann man alles konfigurieren.
**Internen Access Point abschalten
**Shelly ins häusliche WLAN anmelden. Mit fester IP-Adresse <shelly-ip> natürlich...
**Testen: Ihr Gerät wieder mit dem häuslichen WLAN verbinden, und im Browser die Adresse <shelly-ip> aufrufen
*In FHEM definieren
define myShelly Shelly <shelly-ip>
*Auf der Detailseite des Devices muss unbedingt noch das Attribut <code>model</code> gesetzt werden:
attr myShelly model shellyplug|shelly1|shelly2|shelly4
Falls es sich um einen Shelly2 handelt, muss ferner das Attribut <code>mode</code> auf "roller" oder "relay" gesetzt werden.
*'''Für''' die Nutzung dieses Moduls mit den Shelly-Devices spricht, dass alle Daten übertragen und (prinzipiell) alle Konfigurationsänderungen durchgeführt werden können, außerdem ist es auf einfachste Weise zu installieren. Das Modul pollt im per Attribut <code>interval</code> einstellbaren Abstand zyklisch den Aktor auf Statusänderungen (Wert 0 => kein Polling).
*'''Gegen''' die Nutzung dieses Moduls mit den Shelly-Devices spricht, dass damit der Aktor nicht im Stande ist, irgendwelche Zustandsänderungen ''von sich aus'' an FHEM zu melden (Hinweis: Mit der aktuellen Version des Moduls unter Verwendung der Beta-Firmware von Shelly vom 13.11.2018 wird die Position auch nach manueller Betätigung gemeldet).
Zum Betrieb ist ferner noch zu bemerken, dass das Modul zwar meldet, ob ein Firmware-Update nötig ist - ausgelöst werden muss dieses aber über die Web-Oberfläche des Aktors selber.

== MQTT ==
MQTT (Message Queue Telemetry Transport) ist ein nachrichtenbasiertes Protokoll, bei dem Geräte (Devices) nicht direkt miteinander, sondern mit einem zentralen MQTT-Server (in alter Nomenklatur ''Broker'' genannt) kommunizieren. Eine kurze Einführung in MQTT findet man [[MQTT_Einführung|auf diesen Seiten]].
*'''Für''' die Nutzung von MQTT mit den Shelly-Devices spricht, dass ein Shelly-Aktor jede Zustandsänderung mit einer Nachricht an den zentralen MQTT-Server meldet - und zwar auch dann, wenn diese ''lokal'', d.h. über einen der Schalteingänge direkt am Shelly-Aktor ausgelöst worden ist. Darüber hinaus wird der Systemstatus außerdem zyklisch alle 30 Sekunden übermittelt.
*'''Gegen''' die Nutzung von MQTT mit den Shelly-Devices spricht, dass (mit dem aktuellen Firmware-Stand) weder alle Daten übermittelt werden, noch alle Konfigurationsänderungen durchgeführt werden können.
Zum Betrieb ist ferner noch zu bemerken, dass MQTT nicht meldet, ob ein Firmware-Update nötig ist.
=== Einrichtung ===
Zuerst muss ein zentraler MQTT-Server eingerichtet werden, siehe dazu die Hauptseite zu [[MQTT]]. Dann muss in der Web-Oberfläche des Shelly-Devices (erreichbar per Web-Browser unter der IP-Adresse des Shelly-Devices) MQTT eingerichtet und die IP-Adresse sowie der Port des MQTT-Servers eingetragen werden. '''Achtung:''' Das Einrichten von MQTT auf dem Shelly-Device sperrt den Cloud-Zugang, ibs. ist das Gerät dann nicht mehr durch die App von Shelly bedienbar.

= Probleme =
Im Spätsommer 2018 tauchten verschiedene Shelly-Aktoren mit Qualitätsmängeln auf
{| class="wikitable mw-datatable"
!style="width:50px"|Modell
!style="width:50px"|Revision
!style="width:20px"|Batch Id
!style="width:650px"|Problem/Abhilfe
|-
|Shelly1
|prod-2018-08
|2
|Keine Probleme bekannt.
|-
|Shelly2
|prod-2018-07c
|4
|Keine Probleme bekannt.
|-
|Shelly2
|prod-2018-10c
|5
|Verschmutzte Lötstellen bei den Schalteingängen, Gefahr eines Überschlages (siehe unten)
|-
|Shelly2
|prod-2018-10c
|5
|Keine Probleme bekannt, keine Auffälligkeiten an den Lötstellen (siehe oben)
|-
|Shelly4Pro
|unipos-0717
|1
|Verdrehte Eingangsklemme, funktioniert sonst ohne Probleme.
|}
Auch bei problemfreien Shelly2-Aktoren wird dennoch prophylaktisch empfohlen, die Anschlüsse SW1 und SW2 auf der Platine mit einem zusätzlichen Isolationsmaterial (z.B. Epoxidharz-2-Komponentenkleber) abzusichern, siehe [https://forum.fhem.de/index.php/topic,90950.msg853328.html#msg853328 Forum]

Shelly-Aktoren

2018-11-13T12:45:32Z

Sledge:

Shelly-Aktoren

2018-11-13T12:37:55Z

Sledge:

AutoShuttersControl

2018-11-12T17:45:46Z

Sledge: Anpassung der "Vorbereitung", da das Modul jetzt zum Standardumfang von FHEM gehört. Minor Proofreading

{{Baustelle}}
{{Infobox Modul
|ModPurpose=Steuerung von Rollläden
|ModCategory=Automatisierung
|ModType=x

|ModForumArea=Automatisierung
|ModTechName=73_AutoShuttersControl.pm
|ModOwner=CoolTux}}
Mit [[AutoShuttersControl]] oder kurz ASC können typische Aufgabenstellungen im Zusammenhang mit Rollläden u.ä. automatisiert werden, wie zum Beispiel das Öffnen bei Sonnenaufgang, Schließen bei Sonnenuntergang oder das Anfahren von Lüftungspositionen beim Öffnen des zugehörigen Fensters.

{{Hinweis|Das Modul befindet sich derzeit noch in der Entwicklung; der jeweils aktuelle Stand ist diesem {{Link2Forum|Topic=90751|LinkText="Thread im Forum"}} zu entnehmen.}}

== Basics ==
Zur Nutzung des Moduls sollten folgende andere FHEM-Devices vorhanden sein:
* Rollläden
* Fensterkontakte und
* Bewohnerstatus auf Basis von Residents/Roomates in englisch. Ersatzweise andere Devices, z.B. Dummys, welche als ''state'' ''home'', ''asleep'', ''gotosleep'' und ''awoken'' setzen sowie ein Reading ''lastState''.

Die Einrichtung des Moduls bzw. dessen Funktionalität erfolgt in mehreren Schritten:
* Definition des ASC-Devices
* Einstellung zentraler Vorgaben am ASC-Device
* Markieren der zukünftig zu steuernden Rollladen-Devices
* Einbinden der Rollladen-Devices in das ASC-Device
* Einstellen der individuellen Vorgaben je Rollladen (am Rollladen-Device)

== Einrichtung ==

=== Vorbereitung ===

{{Hinweis|Ihr benötigt ein aktuelles FHEM. Update ab dem 04.09.2018 Voraussetzung!}}

=== Define des ASC-Devices ===
Es genügt ein einfaches define ohne weitere Parameter.
<code>define <name> AutoShuttersControl</code>
Dies bewirkt neben der Anlage des Devices selbst auch, dass als weiteres globales Attribut ''ASC'' verfügbar wird.

=== Einstellung zentraler Vorgaben ===
Es stehen am ASC-Device einige Attribute zur Verfügung, über die sich das Verhalten des ASC-Devices insgesamt steuern lässt, z.B. zur Vermeidung von morgendlichen oder abendlichen Fahrten sowie bei Gefahr von Schäden an den Rollläden durch Frost oder zur Reaktion auf Fensterkontakte. Details sind der Commandref zu entnehmen.
Diese Attribute können auch nachträglich noch geändert werden.

=== Markieren zu steuernder Rollladen-Devices ===
Um einen oder mehrere Rollläden durch das ASC-Device zu steuern, wird für jeden Rollladen jeweils das neue globale Attribut ''ASC'' gesetzt. Der Wert ist mit 1 oder 2 festzulegen, wobei '''1''' bedeutet, dass
* die Offen-Position kleiner ist als die Geschlossen-Position, also typischerweise 0 ''offen'' bedeutet und 100 für ''geschlossen'' steht
* eine bestimmte Position mit '''position''' angefahren wird, also z.B. <code>set <name> position 70</code>.
Dies ist z.B. die passende Wahl für ROLLO-Devices

Die '''2''' steht für ein umgekehrtes Verhalten und den Befehlsteil ''pct'', also ''offen'' für <code>set <name> pct 100</code>. Typischer Vertreter dieses Typs sind HomeMatic (CUL_HM-) Geräte oder die Shelly2-Aktoren.

=== Einbinden in das ASC-Device ===
Nachdem man das obige Attribut bei einem oder mehreren Rollladen-Devices gesetzt hat, kann mit
<code>set <name> scanForShutters</code> ein Suchlauf gestartet werden, mit dem dann diese Rollläden durch das Modul gefunden und in die Steuerungslogik eingebunden werden.

=== Einstellen der individuellen Vorgaben ===
Nach der Einbindung sind an den Rollladen-Devices weitere Attribute verfügbar, mit denen die für den jeweiligen Rollladen geltenden Einstellungen vorgenommen werden können.
Die Beschreibung der Attribute ist in der commandref enthalten.

== Readings ==

===Readings im ASC-Device selbst.===

{|class="wikitable"
|-
! Name !! Datentyp/ Wertebereich !! Bedeutung
|-
|..._nextAstroTimeEvent || ||Uhrzeit des nächsten Astro Events, Sonnenauf- oder Sonnenuntergang oder feste Zeit pro Rollonamen
|-
|..._lastPosValue || ||letzter abgesetzter Fahrbefehl pro Rollonamen
|-
|..._lastDelayPosValue || ||letzter abgesetzter Fahrbefehl welcher beim nächsten zulässigen Event ausgeführt wird.
|-
|partyMode ||on, off || aktiviert den globalen Partymodus. Alle Rollläden, welche das Attribut AutoShuttersControl_Partymode bei sich auf on gestellt haben, werden nicht mehr gesteuert. Der letzte Schaltbefehl, welcher durch ein Fensterevent oder Bewohnerstatus an die Rollläden gesendet wurde, wird beim off setzen durch set ASC-Device partyMode off ausgeführt
|-
|lockOut || on, off ||für das Aktivieren des Aussperrschutzes gemäß des entsprechenden Attributs AutoShuttersControl_lock-out im jeweiligen Rolladen. (siehe Beschreibung bei den Attributen für die Rolladendevices)
|-
|room_... || ||Auflistung aller Rollläden welche in den jeweiligen Rämen gefunden wurde, Bsp.: room_Schlafzimmer,Terrasse
|-
|state || ||Status des Devices active, enabled, disabled
|-
|sunriseTimeWeHoliday|| on,off ||wird das Rolladen Device Attribut Attributes AutoShuttersControl_Time_Up_WE_Holiday beachtet oder nicht
|-
|userAttrList || rolled out ||Status der UserAttribute, welche an die Rollläden gesendet werden
|}

===Readings in den Rolllädendevices===

{|class="wikitable"
|-
! Name !! Bedeutung
|-
|ASC_Time_DriveUp ||Sonnenaufgangszeit für das Rollo
|-
|ASC_Time_DriveDown ||Sonnenuntergangszeit für das Rollo
|-
|ASC_ShuttersLastDrive ||Grund des letzten fahrens vom Rolladen
|}

== Settings ==

===Set Befehle für ASC-Device===

{|class="wikitable"
|-
! Name !! Datentyp/ Wertebereich !! Beschreibung
|-
|partyMode ||on, off ||aktiviert den globalen Partymodus. Siehe Reading partyMode
|-
|lockOut ||on, off ||aktiviert den globalen Aussperrschutz. Siehe Reading partyMode
|-
|renewSetSunriseSunsetTimer || || erneuert bei allen Rollläden die Zeiten für Sunset und Sunrise und setzt die internen Timer neu.
|-
|scanForShutters || ||sucht alle FHEM Devices mit dem Attribut "AutoShuttersControl" 1, 2
|-
|sunriseTimeWeHoliday || on,off ||aktiviert/deaktiviert die Beachtung des Attributes AutoShuttersControl_Time_Up_WE_Holiday für Rollladen-Devices
|-
|createNewNotifyDev || ||Legt die interne Struktur für NOTIFYDEV neu an
|-
|selfDefence ||on, off||aktiviert/deaktiviert den Selbstschutz, wenn das Residents Device absent meldet und selfDefence aktiv ist und ein Fenster im Haus steht noch offen, wird an diesem Fenster das Rollo runtergefahren
|-
|wiggle ||||Bewegt einen Rollladen oder alle Rollläden (für Abschreckungszwecke bei der Alarmierung) um 5%, und nach 1 Minute wieder zurück zur Ursprungsposition
|-
|||||
|}

== Get ==

{|class="wikitable"
|-
! Name !! Beschreibung
|-
| showShuttersInformations ||zeigt eine Übersicht der Autofahrzeiten
|-
| showNotifyDevsInformations ||zeigt eine Übersicht der abgelegten NOTIFYDEV Struktur. Dient zur Kontrolle
|}
== Attribute ==

===Attribute im AutoShuttersControl Device selbst.===

{|class="wikitable"
|-
! Name !! Datentyp/ Wertebereich !! Default-Wert !! Beschreibung
|-
|ASC_antifreezeTemp || || ||Temperatur ab welcher der Frostschutz greifen soll und das Rollo nicht mehr fährt. Der letzte Fahrbefehl wird gespeichert.
|-
|ASC_autoAstroModeEvening ||aktuell REAL, CIVIL, NAUTIC, ASTRONOMIC || || (in genau dieser Schreibweise)
|-
|ASC_autoAstroModeEveningHorizon || || || Höhe über Horizont, wenn beim Attribut AutoShuttersControl_autoAstroModeEvening HORIZON ausgewählt
|-
|ASC_autoAstroModeMorning ||aktuell REAL, CIVIL, NAUTIC, ASTRONOMIC || ||(in genau dieser Schreibweise)
|-
|ASC_autoAstroModeMorningHorizon || || ||Höhe über Horizont, wenn beim Attribut AutoShuttersControl_autoAstroModeMorning HORIZON ausgewählt
|-
|ASC_autoShuttersControlComfort ||on, off || ||schaltet die Komfortfunktion an. Bedeutet, dass ein Rollladen mit einem threestate Sensor am Fenster beim Öffnen in eine weit offen Position fährt. Die Offenposition wird beim Rollladen über das Attribut AutoShuttersControl_Pos_after_ComfortOpen eingestellt.
|-
|ASC_autoShuttersControlEvening ||on, off || ||ob Abends die Rollläden automatisch nach Zeit gesteuert werden sollen
|-
|ASC_autoShuttersControlMorning ||on, off || ||ob Morgens die Rollläden automatisch nach Zeit gesteuert werden sollen
|-
|ASC_temperatureReading || || ||Reading für die Außentemperatur
|-
|ASC_temperatureSensor || || ||Device für die Außentemperatur
|-
|ASC_timeUpHolidayDevice || || ||Device zur Urlaubserkennung oder Sonstiges / muss 0 oder 1 im Reading state beinhalten.
|-
|ASC_residentsDevice|| || ||Devicenamen des Residents-Device der obersten Ebene
|-
|ASC_residentsDeviceReading|| || ||Status Reading des Residents-Device der obersten Ebene
|-
|ASC_brightnessMinVal|| || ||minimaler Lichtwert, bei dem Schaltbedingungen noch geprüft werden sollen
|-
|ASC_brightnessMaxVal || || ||maximaler Lichtwert, bei dem Schaltbedingungen noch geprüft werden sollen
|-
|ASC_rainSensorDevice || || ||Device, welches bei Regen getriggert werden soll
|-
|ASC_rainSensorReading || || ||das ensprechende Reading zum Regendevice
|-
|ASC_rainSensorShuttersClosedPos || || ||Position in pct, welche der Rollladen bei Regen anfahren soll
|-
|ASC_shuttersDriveOffset || || ||maximale zufällige Verzögerung in Sekunden bei der Berechnung der Fahrzeiten, 0 bedeutet keine Verzögerung
|-
| || || ||
|-
| || || ||
|}

===Attribute in den Rolllädendevices===

{|class="wikitable"
|-
! Name !! Datentyp/ Wertebereich !! Default-Wert !! Beschreibung
|-
|ASC || 0, 1, 2|| ||1 = "Inverse oder Rollo Bsp.: Rollo Oben 0,Rollo Unten 100 und der Befehl zum Prozentualen fahren ist position",2 = "Homematic Style Bsp.: Rollo Oben 100,Rollo Unten 0 und der Befehl zum Prozentualen fahren ist pct
|-
|ASC_Antifreeze || on, off|| ||Frostschutz an oder aus
|-
|ASC_AutoAstroModeEvening ||REAL, CIVIL, NAUTIC, ASTRONOMIC|| ||aktuell REAL,CIVIL,NAUTIC,ASTRONOMIC
|-
|ASC_AutoAstroModeEveningHorizon || || ||Höhe über Horizont wenn beim Attribut ASC_autoAstroModeEvening HORIZON ausgewählt
|-
|ASC_AutoAstroModeMorning ||REAL, CIVIL, NAUTIC, ASTRONOMIC|| ||aktuell REAL,CIVIL,NAUTIC,ASTRONOMIC
|-
|ASC_AutoAstroModeMorningHorizon || || ||Höhe über Horizont wenn beim Attribut ASC_autoAstroModeMorning HORIZON ausgewählt
|-
|ASC_Closed_Pos || || ||in 10 Schritten von 0 bis 100,default Vorgabe ist abhängig vom Attribut ASC
|-
|ASC_Down || astro, time, brightness || ||bei Astro wird Sonnenuntergang berechnet, bei time wird der Wert aus ASC_Time_Down_Early als Fahrzeit verwendet und bei brightness muss ASC_Time_Down_Early und ASC_Time_Down_Late korrekt gesetzt werden. Der Timer läuft dann nach ASC_Time_Down_Late Zeit,es wird aber in der Zeit zwischen ASC_Time_Down_Early und ASC_Time_Down_Late geschaut ob die als Attribut im Moduldevice hinterlegte ASC_brightnessMinVal erreicht wurde, wenn ja wird der Rolladen runter gefahren
|-
|ASC_Mode_Down ||always, home, absent, off || ||wann darf die Automatik steuern. immer,niemals,bei abwesenheit des Roommate (ist kein Roommate und absent eingestellt wird gar nicht gesteuert)
|-
|ASC_Mode_Up ||always, home, absent, off || ||wann darf die Automatik steuern. immer,niemals,bei abwesenheit des Roommate (ist kein Roommate und absent eingestellt wird gar nicht gesteuert)
|-
|ASC_Drive_Offset || || ||maximale zufällige Verzögerung in Sekunden bei der Berechnung der Fahrzeiten, 0 bedeutet sofort, -1 bedeutet das das gleichwertige Attribut aus dem ASC-Device ausgewertet werden soll.
|-
|ASC_Open_Pos || || ||in 10 Schritten von 0 bis 100,default Vorgabe ist abhängig vom Attribut ASC
|-
|ASC_Partymode || on, off || ||schaltet den Partymodus an oder aus. Wird dann am ASC Device set ASC-DEVICE partyMode on geschalten, werden alle Fahrbefehle an den Rollläden, welche das Attribut auf on haben, zwischengespeichert und erst später ausgeführt
|-
|ASC_Pos_Reading || || ||Name des Readings, welches die Position des Rollladen in Prozent an gibt. Wird bei unbekannten Device -ypen auch als set Befehl zum Fahren verwendet
|-
|ASC_Pos_after_ComfortOpen || || ||in 10 Schritten von 0 bis 100, default Vorgabe ist abhängig vom Attribut ASC
|-
|ASC_Roommate_Reading || || ||das Reading zum Roommate-Device, welches den Status wieder gibt
|-
|ASC_Roommate_Device || || ||mit Komma getrennte Namen des/der Roommate-Device/s welche den/die Bewohner des Raumes vom Rollladen wieder gibt. Es macht nur Sinn in Schlaf- oder Kinderzimmern
|-
|ASC_Time_Down_Early || || ||Sunset frühste Zeit zum Runterfahren
|-
|ASC_Time_Down_Late || || ||Sunset späteste Zeit zum Runterfahren
|-
|ASC_Time_Up_Early || || ||Sunrise frühste Zeit zum Hochfahren
|-
|ASC_Time_Up_Late || || ||Sunrise späteste Zeit zum Hochfahren
|-
|ASC_Time_Up_WE_Holiday || || ||Sunrise frühste Zeit zum Hochfahren am Wochenende und/oder Urlaub (we2holiday wird beachtet). Achtung! Sollte nicht größer sein als ASC_Time_Up_Late, sonst wird ASC_Time_Up_Late verwendet
|-
|ASC_Up || astro, time, brightness || ||bei astro wird Sonnenaufgang berechnet, bei time wird der Wert aus ASC_Time_Up_Early als Fahrzeit verwendet und bei brightness müssen ASC_Time_Up_Early und ASC_Time_Up_Late korrekt gesetzt werden. Der Timer läuft dann nach ASC_Time_Up_Late Zeit, es wird aber in der Zeit zwischen ASC_Time_Up_Early und ASC_Time_Up_Late geschaut, ob die als Attribut im Moduldevice hinterlegte ASC_brightnessMinVal erreicht wurde. Wenn ja, wird der Rolladen runter gefahren
|-
|ASC_Ventilate_Pos || || ||in 10 Schritten von 0 bis 100, default Vorgabe ist abhängig vom Attribut ASC
|-
|ASC_Ventilate_Window_Open || || ||auf lüften, wenn das Fenster gekippt/geöffnet wird und aktuelle Position unterhalb der Lüften-Position ist
|-
|ASC_WindowRec || || ||Name des Fensterkontakts an welchen Fenster der Rollladen angebracht ist
|-
|ASC_WindowRec_subType || || ||Typ des verwendeten Fensterkontakts: twostate (optisch oder magnetisch) oder threestate (Drehgriffkontakt)
|-
|ASC_lock-out || soft, hard || ||stellt entsprechend den Aussperrschutz ein. Bei global aktiven Aussperrschutz (set ASC-Device lockOut soft) und einem Fensterkontakt open bleibt dann der Rolladen oben. Dies gilt nur bei Steuerbefehle über das ASC Modul. Stellt man global auf hard, wird bei entsprechender Möglichkeit versucht, den Rollladen hardwareseitig zu blockieren. Dann ist auch ein Fahren über die Taster nicht mehr möglich.
|-
|ASC_lock-outCmd || inhibit, blocked || ||set Befehl für das Rolladen-Device zum Hardware sperren. Der Befehl wird verwendet, wenn man "ASC_lock-out" auf hard setzt
|-
|ASC_Self_Defense_Exclude || on, off || ||bei on Wert wird dieser Rolladen bei aktiven Self Defense und offenen Fenster nicht runter gefahren, wenn Residents absent ist.
|-
|ASC_Shading_Brightness_Sensor || || ||Sensor-Device, welches für die Lichtwerte verwendet wird. ACHTUNG! Findet auch Verwendung bei ASC_Down - brightness
|-
|ASC_BrightnessMinVal || || ||minimaler Lichtwert, bei dem Schaltbedingungen noch geprüft werden sollen / wird der Wert von -1 nicht geändert, so wird automatisch der Wert aus dem Moduldevice genommen
|-
|ASC_BrightnessMaxVal || || ||maximaler Lichtwert, bei dem Schaltbedingungen noch geprüft werden sollen / wird der Wert von -1 nicht geändert, so wird automatisch der Wert aus dem Moduldevice genommen
|-
|ASC_ShuttersPlace || window, terrace || ||wenn dieses Attribut auf terrace gesetzt ist und das Residence Device in den Status "done" geht und SelfDefence aktiv ist wird das Rollo geschlossen
|-
| || || ||
|-
| || || ||
|-
| || || ||
|-
| || || ||
|-
| || || ||
|-
| || || ||
|-
| || || ||
|-
| || || ||
|}

== Hilfsmittel ==
tbd

readingsGroup, um die diversen Level einzustellen:

define rg_ASC_Rollaeden_Level readingsGroup <Gerät>,<Closed_Pos>,<Open_Pos>,<Shading_Pos>,<Ventilate_Pos> (Rolladen_.*|Jalousie_.*)..:?ASC_Closed_Pos,?ASC_Open_Pos,?ASC_Shading_Pos,?ASC_Ventilate_Pos
attr rg_ASC_Rollaeden_Level commands { ASC_Closed_Pos => 'ASC_Closed_Pos:0,10,20,30,35,40,45,50,55,60,65,70,75,80,85,90,95,100',\
ASC_Open_Pos => 'ASC_Open_Pos:0,10,20,30,35,40,45,50,55,60,65,70,75,80,85,90,95,100',\
ASC_Shading_Pos => 'ASC_Shading_Pos:0,10,20,30,35,40,45,50,55,60,65,70,75,80,85,90,95,100',\
ASC_Ventilate_Pos => 'ASC_Ventilate_Pos:0,10,20,30,35,40,45,50,55,60,65,70,75,80,85,90,95,100'}
[[Datei:ReadingsGroup ASC Level.png|600px|]]
readingsGroup, um die diversen Zeiten einzustellen:

define rg_ASC_Rollaeden_Times readingsGroup <Gerät>,<Stand>,<Time_Up_Early>,<Time_Up_WE>,<Time_Up_Late>,<Time_Down_Early>,Time_Down_Late>,<Mode_Down>,<Mode_Up> (Rolladen_.*|Jalousie_.*)..:level,?ASC_Time_Up_Early,?ASC_Time_Up_WE_Holiday,?ASC_Time_Up_Late,?ASC_Time_Down_Early,?ASC_Time_Down_Late,?ASC_Mode_Down,?ASC_Mode_Up
attr rg_ASC_Rollaeden_Times commands {level => 'pct:0,10,20,30,35,40,45,50,55,60,65,70,75,80,85,90,95,100', \
ASC_Mode_Down => 'ASC_Mode_Down:always,absent,off',\
ASC_Mode_Up => 'ASC_Mode_Up:always,absent,off',\
ASC_Time_Down_Early => 'ASC_Time_Down_Early:15:00,15:15,15:30,15:45,16:00,16:15,16:30,16:45,17:00,17:15,17:30,17:45,18:00,18:15,18:30,18:45,19:00,19:15,19:30,19:45,20:00,20:15,20:30,20:45,21:00,21:15,21:30,21:45,22:00', \
ASC_Time_Down_Late => 'ASC_Time_Down_Late:20:15,20:30,20:45,21:00,21:15,21:30,21:45,22:00,22:15,22:30,22:45,23:00,23:15,23:30',\
ASC_Time_Up_Early => 'ASC_Time_Up_Early:05:00,05:05,05:30,05:45,06:00,06:15,06:30,06:45,07:00,07:15,07:30,07:45,08:00,08:15,08:30,08:45,09:00,09:15,09:30,09:45,10:00', \
ASC_Time_Up_Late =>'ASC_Time_Up_Late:06:00,06:15,06:30,06:45,07:00,07:15,07:30,07:45,08:00,08:15,08:30,08:45,09:00,09:15,09:30,09:45,10:00',ASC_Time_Up_WE_Holiday => 'ASC_Time_Up_WE_Holiday:06:00,06:15,06:30,06:45,07:00,07:15,07:30,07:45,08:00,08:15,08:30,08:45,09:00,09:15,09:30,09:45,10:00'}
[[Datei:ReadingsGroup ASC Times.png|600px|]]

== Weblinks ==
* {{Link2Forum|Topic=92628|LinkText="Thread zum Modul im Forum"}}
* {{Link2Forum|Topic=90751|LinkText="Thread zur Entwicklung im Forum"}}
* {{Link2Forum|Topic=73964|LinkText="Thread zu den Scripten von user cluni"}}, die der Entwicklung des Moduls zugrunde liegen

[[Kategorie:Code Snippets]]
[[Kategorie:Rollladensteuerung]]

Diskussion:AutoShuttersControl

2018-11-12T17:29:08Z

Sledge: Erstellung einer Konfiguration in 6-7 einfachen Schritten erläutern

Hi, ich plane, meinen "so habe ich es bei mir eingerichtet"-Post aus dem Support-Thread hier im Wiki einzustellen und ggf etwas ausführlicher zu gestalten. Hinweise / Diksussion dann gerne hier dazu.

HM-SEC-KEY KeyMatic

2018-05-22T18:30:35Z

Sledge: Link Anleitung korrigiert

== Features ==
Das Gerät dient zum motorgesteuerten Betätigen von Zylinderschlössern in Türen.

== Hinweise zum Betrieb mit FHEM ==
Der HM-SEC-KEY Keymatic verwendet ausschließlich die AES authentifizierte Kommunikation und kann mit dem [[HMLAN Konfigurator]] bzw. [[CUL]] gesteuert werden.

Das Pairing sollte wie in [[HomeMatic Devices pairen]] beschrieben durchgeführt werden. An der KeyMatic muss dafür die Anlerntaste (Taste Schloss öffnen) betätigt werden.
{{Hinweis|Falls bereits ein Handsender als Masterfernbedienung 1 angelernt ist (was für autarken Betrieb sehr empfehlenswert ist), muss der Anlernvorgang zwingend durch Tastendruck auf eine Taste dieser Fernbedienung bestätigt werden.
Bestätigung im fhem.log '''3: CUL_HM pair: Haustuer keyMatic, model HM-SEC-KEY serialNr LEQ********'''
}}

Die KeyMatic-Unterstützung existiert derzeit in der aktuellen Entwicklerversion von FHEM

=== Sicherheitshinweis ===
Wenn die KeyMatic an einem aktiven HMLAN Konfigurator angelernt wurde, kann die entsprechende Tür per FHEM ver- / entriegelt bzw. geöffnet werden. Somit sollte das Netzwerk in dem FHEM läuft entsprechend gesichert sein. (Nicht nach Außen geöffnet, kein unsicheres WLAN usw.)

Die Verwendung eines eigenen [[AES Encryption#Aktivieren.2C_Einrichten.2C_Umgang_in_FHEM|AES Sicherheitsschlüssels]] ist dringend anzuraten, da ansonsten eine KeyMatic relativ einfach ferngesteuert werden kann.

=== FHEM Config-Auszug ===
Beispiel für die Konfiguration:

ssssss -> 6-Stellige hexadezimale Seriennummer. (Siehe Logfile: CUL_HM Unknown device CUL_HM_keyMatic_ssssss, please define it)
xxxxxxx -> Seriennummer (vom Aufkleber auf dem Gerät)

define keymatic CUL_HM ssssss
attr keymatic devInfo 010100
attr keymatic firmware 2.4
attr keymatic hmClass receiver
attr keymatic model HM-SEC-KEY-S
attr keymatic room Flur
attr keymatic serialNr JEQxxxxxxx
attr keymatic subType keyMatic
attr keymatic webCmd lock:unlock:open

== Mögliche Zustände ==
KeyMatic hat folgende Schaltzustände:

locked -> Der Riegel des Türschlosses ist an die vorher festgelegte Verschlussstellung gefahren (Tür verschlossen)
unlocked -> Der Riegel des Türschlosses ist "eingefahren" (Tür nicht verschlossen)
uncertain (locked / unlocked) -> Das Schloss wurde am Handrad gedreht. Die Schlossposition ist somit nicht mehr als "zuverlässig erkannt" gemeldet.
== Links ==
Anleitung [http://www.eq-3.de/Downloads/eq3/downloads_produktkatalog/homematic/bda/HM-Sec-Key_UM_GE_eQ-3_web.pdf] PDF

[[Kategorie:HomeMatic Components]]
[[Kategorie:Türschlosssteuerung]]

Virtueller Controller VCCU

2018-05-20T08:44:32Z

Sledge:

Eine '''Virtuelle CCU''', auch '''VCCU''' genannt, ist eine Zentrale für [[HomeMatic]]-Geräte. Die VCCU tritt beim [[Pairing (HomeMatic)|Pairing]] an die Stelle des ''I/O-Devices'' (auch "Schnittstelle" genannt, zum Beispiel [[CUL]] und [[HM-CFG-LAN]]).

HomeMatic-Geräte werden überlicherweise mit einer Zentrale gepaired, um sie zentral verwalten zu können. Der Pairing-Partner ist im einfachsten Fall das I/O-Device ([[CUL]], [[HM-CFG-LAN]], …) selbst. Nachteilig dabei ist, dass der Ausfall der Schnittstelle bewirkt, dass alle gepairten Geräte nicht mehr bedient werden können. Dies lässt sich im Gegensatz zu ungepairten Protokollen (z.b. FS20) auch nicht durch doppelte Definition mit abweichenden IO-Devices lösen, da das Pairing nur mit einer ''hmId'' erfolgen kann. Daher kann auch durch mehrere Schnittstellen / IOs keine Redundanz erreicht werden. Ähnliches gilt für eine Vergrösserung der Funkabdeckung durch mehrere Schnittstellen.

Dieses Problem kann durch eine VCCU gelöst werden. Die VCCU ist eine virtuelle Zentrale; sie tritt beim Pairing an die Stelle der Schnittstelle. Sie erhält eine eigene ''hmId'', mit der die HM Sensoren und Geräte gepaired werden. Die Funkschnittstelle(n) werden dann von der VCCU als reine "dumme" IOs verwaltet. Dieses bietet vielfältige Möglichkeiten, z.b. die Verwendung mehrerer IOs, aus denen die VCCU die "beste" nach diversen Kriterien (z.B. RSSI) auswählt. Dadurch kann sowohl die Redundanz als auch die Funkabdeckung erhöht werden.

Durch das Pairen der Geräte mit einer virtuellen CCU ergeben sich folgende Vorteile:

* Die Verwendung mehrerer I/O-Devices wird möglich. Das sorgt für Redundanz (Ausfallsicherheit) und/oder Reichweiten-Vergrößerung.
* Der Tausch eines I/O-Devices ist transparent für gepairte Geräte.
* Die VCCU stellt virtuelle Kanäle zur Verfügung, mit denen HomeMatic-Geräte [[Homematic Peering Beispiele|gepeert]] werden können.
* "Geordnete" Termination von Nachrichten. (Da die üblichen Funkschnittstellen (wie CUL im HM-Mode oder HM-LAN-Konfigurator) relativ "dumm" sind, führen viele Zustände zu den bekannten "Help me" Einträge im Log.)

Der einzige Nachteil einer VCCU gegenüber dem direkten Pairing mit dem I/O-Device ist ein Mehraufwand bei der initialen Konfiguration vom FHEM.

== Kurzbeschreibung ==

Ein virtueller Controller '''VCCU''' ist der Protokoll-Endpunkt der Zentrale und ersetzt dabei logisch (jedoch nicht physikalisch) z.b. den [[HM-CFG-LAN LAN Konfigurations-Adapter]] einer "klassichen" FHEM Konfiguration

Es können einer VCCU einzelne oder mehrere IO Devices zugeordnet werden. Man bündelt dadurch mehrere I/O Devices (z.B. CULs und HM-CFG-LANs) zu einem ''Pool''. Den HM-Devices in FHEM (Aktoren, Sensoren) kann dann als I/O Device die ''VCCU'' zugeordnet werden, dies geschieht durch das Attribut ''IOgrp.''

Durch diese Gruppierung der I/O Devices und dem Zuordnen der VCCU zu einem Device entstehen verschieden Vorteile, abhängig des Einsatzes der VCCU. So kann ein beliebiges I/O Device im Device Pool der VCCU ausfallen und das oder die verbliebenden I/O Devices übernehmen diese Funktion (abhängig von der Funkreichweite/Erreichbarkeit). Die VCCU wird das nächst verfügbare I/O Device zum Senden/Empfangen verwenden.

Ein weitere Vorteil ist, dass durch die VCCU auch das I/O Device genutzt werden kann, welches die beste Funkqualität aufweist. Dies kann z.B. bei beweglichen Sensoren/Aktoren (Fernbedienungen) sinnvoll sein, oder wenn die Funkqualität durch andere Faktoren beeinflusst wird (z.B. Tür/Tor oder andere "bewegliche" Störfaktoren)

== Mehrere VCCUs in einer Installation==

Theoretisch erlaubt FHEM die parallele Nutzung mehrer VCCUs, praktisch ergeben sich dadurch jedoch keine Vorteile gegenüber einer einzigen VCCU. Insbesondere kann bereits eine VCCU verschiedene I/O-Devices bedienen, zum Beispiel einen [[CUL]] ''und'' ein [[HM-CFG-LAN]].

Jede VCCUs muss eine eindeutige ''HomeMatic-ID'' haben, mit der HomeMatic-Geräte gepaired werden. Folglich kann jedes HomeMatic-Gerät nur mit ''einer'' VCCU gepaired werden.

Die VCCU überschreibt die hmid eines I/O Device mit seiner eignen, daher können nicht mehrere VCCUs das selbe I/O Device verwenden.

== Definition der VCCU==
=== hmId wählen ===
Eine VCCU benötigt wie alle HM Devices eine Adresse, mit der sie angesprochen wird. Bei Schnittstellen und Zentralen ist dies eine ''hmId''. Da die VCCU eine (virtuelle) Zentrale ist, muss sie auch mit einer ''hmId'' versehen werden. Dies geschieht per define analog zur Anlage einer physischen Schnittstelle (siehe weiter unten)

Eine VCCU gibt die ''hmId'' an die ihr zugewiesenen IOs (Funkschnittstellen) weiter. D.H. alle von einer VCCU genutzen I/Os haben nach der Zuweisung die selbe ''hmId''.

Definiert man eine VCCU nachdem I/Os (CUL oder HMLAN) für Homematic angelegt sind, sollte die ''hmId'' der bereits vorhandene Funkschnittstelle verwenden, hierdurch kann man sich das Neupairen der HM Devices ersparen. Hat man bereits mehre Funkschnittstellen im Einsatz, werde diese unterschiedliche ''hmId''s haben, zumindest eine Schnittstelle wird nach der Zuweisung zur VCCU seine ''hmId'' also ändern. Für mit dieser Schnittstelle schon gepairte Devices ist ein Neupairen unumgänglich.

Ausserdem muss in jedem Fall das attr IOgrp eines vor Anlage der VCCU gepairten Gerätes auf die VCCU angelegt/geändert werden., z.B. so
attr <device> IOgrp VCCU
(Siehe weiter unten ein Tipp, wie dies leicht nachträglich erledigt werden kann)

Mit der Anlage einer VCCU hat das eventuell angelegte attribut IODev eines HM_Devices keine Funktion mehr. Vielmehr setzt die VCCU das IODev automatisch je nach Verfügbarkeit und Funklage. Es ist jedoch nicht erforderlich angelegte IODev Attribute zu entfernen.

=== Einrichten ===
define VCCU CUL_HM <hmId>
attr VCCU model CCU-FHEM
attr VCCU IOList <io1>[,<io2>,...]

Das Attribut IOList dient dazu festzulegen, welche physikalischen Schnittstellen ("IO") von der VCCU genutzt werden, dies sind in der Regel alle HM-fähigen Schnittstellen einer Installtion.
IOList beinhaltet die Komma-getrennte Liste der IOs, so wie sie in FHEM angelegt sind.

Es seien z.b. in FHEM bereits die beiden Schnittstellen HMLAN und CULHM angelegt:

define HMLAN0 HMLAN 192.168.168.2:1000
attr HMLAN0 hmId 123456
attr HMLAN0 hmLanQlen 1_min
attr HMLAN0 icon hm_lan

define CUL0 CUL /dev/ttyACM0@9600 0000
attr CUL0 hmId 123456
attr CUL0 icon cul_cul
attr CUL0 rfmode HomeMatic

Dann kann zusätzlich die VCCU mit der selben hmId angelgt werden und die beiden physikalischen Schnittstellen ihr zugewiesen:

define VCCU CUL_HM 123456
attr VCCU IOList CUL0,HMLAN0
attr VCCU model CCU-FHEM
attr VCCU subType virtual
attr VCCU webCmd virtual:update

Wird die VCCU mit einer von vorhandene Schnittstellen abweichenden ''hmId'' angelegt, so wird die ''hmId'' der ihr zugewiesenen Schnittstelle(n) automatische angepasst. Dies hat in der Regel zur Folge, das HM Devices neu gepairt werden müssen.

Dies trifft auch zu, wenn bereits vorhandene Schnittstellen unterschiedliche hmIDs haben, dann wird sich die hmID mindestens einer Schnittstelle ändern. (Der Einfachheit halber war im obigen Beispiel angenommen, dass auch vorher die beiden Schnittstellen bereits die gleiche ID hatten.)

=== Auswirkungen auf IOs / Funkschnittstellen===
Sind IOs durch das Attribut IOList einer VCCU zugewiesen, werden die notwendigen Attribute im IO gesetzt, so wird die hmId durch die VCCU kontrolliert. Ein HMLAN/USB ist etwas enger verbunden als CUL IOs. Beim HMLAN kann die HMId nicht mehr geändert werden. Die kontrollierende VCCU wird in den Internals ''owner'' und ''owner_CCU'' des IO automatisch eingetragen. 

=== Was passiert beim Austausch/Wegfall von IOs ===
Häufig wird das Thema VCCU erst angefasst wenn das System schon eine Weile besteht und ein zweiter IO eingebaut, oder der alte IO ausgetauscht werden soll. Dabei ensteht folgende ungünstige Struktur in der fhem.cfg
...
define erster Io
...
define alle möglichen HM Geräte
...
define VCCU
define neuer IO
Beim Start von FHEM wird die cfg Zeilenweise abgearbeitet und für jedes HM gerät geprüft ob ein IO vorhanden ist, gegebenenfalls erfolgt ein Fehlereintrag im Log (unknown IODev specified). Wenn der neue IO erst am Ende der cfg definiert ist, ist er für alle davor liegenden HM Geräte nicht vorhanden. Das ist nur ein Schönheitsfehler beim Start von FHEM, im laufenden Betrieb spielt das keine Rolle.

Folgende Struktur wäre erstrebenswert
...
define Homematic IO 1
define Homematic IO 2
define VCCU
define HM Geräte
...
Solange kein Modul die Einträge in der fhem.cfg entsprechend einsortiert, muss dies Korrektur von Hand erfolgen. Dies ist einer der wenigen Fälle, wo die direktes Editieren der fhem.cfg z.B. dem eingebautem Editor unumgänglich ist. Soll der im Standard-WEBinterface von FHEM eingebaute Editor verwendet werden, muss zuerst das Attribut
attr WEB editConfig 1
in FHEM gesetzt werden.
Anschliessend die kompletten define Blöcke mit allem was dazu gehört entsprechend in die empfohlene Struktur bringen.
Datei sichern und rereadcfg eingeben.

=== Pairen von HM Devices===
HM Devices sollten vorzugsweise direkt mit der VCCU gepairt werden, hierzu werden die normalen Befehle
hmPairForSec
also z.b.
set VCCU hmPairForSec 600
oder
hmPairSerial
verwendet. Es ist im übrigen weiter möglich (aber nicht sinnvoll / empfehlenswert) auch nach Anlage einer VCCU HM Devices mit diesen Kommandos direkt an ein IO zu pairen, d.h. diese Kommandos haben auch nach Anlage einer VCCU noch eine Funktion an der physikalischen Schnittstelle (im Gegensatz z.b. zum attr IODev)

==== Autocreate ====
Sofern Autocreate eingeschaltet ist und das Pairing wie oben beschrieben an die VCCU erfolgt, werden unter anderem für das Device folgende Attribute angelegt:

attr <device> IODev <PhysischesIO>
attr <device> IOgrp VCCU:<PhysischesIO>

z.b.

attr Thermostat_Bad IODev HMLAN1
attr Thermostat_Bad IOgrp VCCU:HMLAN1

Das Physische IO hat keine weitere Wirkung, ebensowenig Änderungen, die Zeil kann im Grunde auch gelöscht werden. Der Eintrag zeigt aber an, welches physikalische IO zum Zeitpunkt des Autocreates verwendet wurde, vermutlich ist das das IO mit der besseren Funklage (wenn mehrere existieren). Das selbe IO wird mit
IOgrp VCCU:HMLAN1
auch als prefered eingetragen. D.H. die VCCU wird später zuerst prüfen ob HMLAN1 verfügbar ist (condition=ok) und es dann verwenden, andere IOs werden nur verwendet, wenn HMLAN1 nicht verfügbar ist.
Dieser Eintrag kann manuell geändert werden, Details im folgenden Abschnitt.

== Dynamisches IO ==
Ohne VCCU sendet sendet Befehle an ein HM Device in der Regel immer über das gleiche IO-Device. Fällt es aus, wird nicht mehr gesendet, selbst wenn ein zweites IO verfügbar wäre. Ausserdem gibt es ''bewegliche'' Fernbedienungen welche ihre Verbindung zu einem IO verlieren, aber über ein andere IO gut empfangen werden könnten.

Die VCCU adressiert beide Probleme:

Durch das Attibut IOgrp
attr <dev> IOgrp <vccu>:<preferredIO>
kann bestimmt werden, wie die VCCU die IO Devices genau nutzt. Insbesondere ist optional ein Preferd IO Device definierbar: bei stationären Devices - der häufigste Fall - sollte man das beste IO auswählen und als Default nutzen. Ein weiteres IO wird bei Ausfall des Ersten genutzt.

Das preferredIO ist jedoch optional und kann insbesondere bei beweglichen HM Devices (Fernbedienungen) weggelassen werden.

Es können auch mehrere preferredIO definiert werden, diese werden in der definierten Reihenfolge genutzt
attr <dev> IOgrp <vccu>:<prefIO1>,<prefIO2>,<prefIO3>

Beispiele:

Durch
attr <device> IOgrp VCCU:HMLAN1
wird die VCCU zuerst versuchen Befehle an <device> mit HMLAN1 zu senden, falls seine condition=ok.
Falls nicht wird (einer) der verbleibende(n) IOs verwendet, hier der mit dem besten RSSI.

Durch
attr <device> IOgrp VCCU
wird durch die VCCU der IO mit dem besten RSSI zum Device gewählt, falls seine condition=ok ist.

Da dies für jedes angelegte HM Device einzeln definiert werden kann/muss, kann so auch eine Verteilung des Funkverkehrs vorgenommen werden, z.b. um die 1%-Regel (HighLoad) zu berücksichtigen, dennoch bleibt die Redunanz bei Ausfall einer Schnittstelle erhalten.

=== Bemerkungen ===
Die besprochene Steuerung betrifft das '''Senden'''. Empfangen und verarbeitet werden Nachrichten immer von allen verfügbaren Quellen.

=== IOgrp bei nachträglicher Einrichtung einer VCCU ===
Wie erwähnt wird beim Verwenden von Autocreate das Attribut IOgrp mit angelegt.
Bei HM Devices die vor der Einrichtung einer VCCU angelegt wurden, fehlt das Attribut aber.
Es wird empfohlen, das Attribut IOgrp in solchen Devices zu nachträglich setzen. Kanäle senden nicht selbständig, haben daher kein Attribut IOgrp. 
Das Attribut '''IODev''' wird automatisch gesetzt, Usereinträge haben keine Funktion. Es zeigt jedoch indirekt das letzte genutzte output-device. 

==== Setzen der IOgrp auf (fast) allen Devices mit einem einzigen Befehl ====
Hat man eine bestehende FHEM-Installation mit mehreren/vielen Devices, kann das Setzen der ''IOgrp'' aufwändig sein.
Relativ einfach geht es bei allen HM Geräten durch Filtern der sechstelligen DEF (HMID):
:<code>attr TYPE=CUL_HM:FILTER=DEF=...... IOgrp VCCU</code>
Den obigen Befehl in der FHEM-Eingabezeile eingeben und mit <Return> bestätigen.
VCCU steht für den Namen der VCUU und ist entsprechend zu ersetzen.
Durch die 6 Punkte werden nur die Geräte erfasst, die Kanäle haben 8 stellige IDs und bleiben unberührt. Da üblicherweise auch die VCCU selbst sowie der ''ActionDetector'' sechsstellige IDs haben, muss normalerweise der Filter erweitert werden auf
:<code>attr TYPE=CUL_HM:FILTER=DEF=......''''':FILTER=subType!=virtual:FILTER=model!=ActionDetector''''' IOgrp VCCU</code>
Anschließend nicht vergessen, die Konfiguration mit save zu speichern.

== Virtuelle Kanäle der VCCU==
: ''→ Siehe auch: [[HomeMatic#IO_Entities]]''

Eine VCCU kann bis zu 50 virtuelle Kanäle, sogenannte '''IO-Entities''', bedienen. Diese können als Sender/Sensoren oder Empfänger genutzt werden. Man kann diese Kanäle mit einem realen Kanal peeren und Aktionen triggern.

Man peert beispielsweise einen Dimmer mit einer IO-Entity um "Tastendrücke" in der Zentrale auslösen zu können. Sowohl kurze (short) als auch lange (long) Tastendrücke können so an den Dimmer gesendet werden.
Auch mehrere Aktoren können mit einer IO-Entity gepeert werden, beispielsweise um alle Lichter der Gruppe mit einem "press" gleichzeitig zu schalten.

=== Anlegen ===
set VCCU virtual <AnzahlButton>
z.B.
set VCCU virtual 10
legt 10 Kanäle für die VCCU an, die Kanäle 1-10. Evtl. vorhandene Kanäle größer 10 werden gelöscht.

=== Kommandos ===
: ''→ Siehe auch: {{Link2CmdRef|Anker=CUL_HMvirtual}}''

Verfügbare Kommandos auflisten:

get vccu_Btn1 cmdList

Insbesondere gibt es:

set vccu_Btn1 press short
set vccu_Btn1 press long
set vccu_Btn1 postEvent <condition>

[[Kategorie:HomeMatic supportDevice]]
[[Kategorie:HOWTOS]]

HomeMatic Firmware Update

2018-05-12T06:50:13Z

Sledge: Hinweise auf Fehlersuche beim FW-Update unter FHEM; Verweis auf Forenartikel

Seit 2014 ist es möglich, bei einigen [[HomeMatic]] Komponenten selbst Firmware Updates durchzuführen. Vorher ging das nur per CCU oder durch Einsenden des Gerätes an ELV.
Dabei gibt es verschiedene Möglichkeiten das Firmware Update durchzuführen. Um in FHEM die aktuelle Firmware nach dem Update angezeigt zu bekommen, ist ein erneutes Pairen mit FHEM notwendig. Es muss aber nicht gelöscht oder zurückgesetzt werden.

== Varianten für Firmwareupdates ==
=== Firmware Update mit CUL/HM-CFG-USB/HMUARTLGW unter FHEM ===
FW Updates sind in FHEM möglich. Benötigt wird dafür ein [[CUL]] oder ein [[HM-CFG-USB USB Konfigurations-Adapter|HM-CFG-USB]] oder ein [[HMUARTLGW]]. Mit einem [[HMLAN]] ist ein Update nicht möglich.

Vor dem Update ist sicherzustellen, dass das korrekte IO für das Device genutzt wird (falls mehrere IOs im System zu Verfügung stehen). Siehe Attribut IODev und IOgrp bei der Verwendung einer [[Virtueller Controller VCCU|VCCU]]. Ein HMLAN kann mit dem Befehl: <code>set <HMLAN Name> close</code> temporär ausgeschlossen werden.

Um das Update durchführen zu können, wird die in dem entsprechenden Zip/tgz-File vorhandene .eq3-Datei benötigt. Bitte genau darauf achten, dass nicht versehentlich eine falsches Firmware-Datei verwendet wird. Der Vorgang selbst erfolgt mittels folgendem Befehl:
:<code>set <device> fwUpdate <filename> <nowiki>[<time>]</nowiki></code>
<filename> ist der Name der .eq3 Datei inklusive absolutem oder relativem Pfad zu fhem-Root.
Die Angabe von [<time>] ist optional. Es ist die Zeit in Sekunden, die FHEM wartet, bis das Device in den Bootloader-Modus versetzt wird. Bei den meisten Devices ist die Zeit nicht notwendig, da FHEM das Gerät selbst in den Bootloader-Mode versetzen kann.

Bei einigen älteren FW-Versionen wie z.B. bei den [[HM-CC-RT-DN]] v1.0 geht das allerdings nicht automatisch. Um den Flashvorgang zu starten, müssen hier noch die Batterien entfernt werden und beim wiedereinlegen die beiden äußeren Knöpfe gedrückt werden. Jene Zeit, die man für eben diese Aktion benötigt, wird hier eingegeben.

Wichtig: während des Updates können keine weiteren Nachrichten in FHEM von Homematic verarbeitet werden.

Da nach dem Update immer noch die alte FW-Version in FHEM steht, kann man entweder bei einigen Geräten die Version mit
:<code> set <device> getVersion </code>
auslesen oder wenn das Kommando wie z.B. bei den oben genannten Heizkörperventilen nicht zur Verfügung steht, genügt es, am Gerät selbst die Anlerntaste zu drücken (was am Beispiel der RTs bedeutet, dass die Boost-Taste für mindestens drei Sekunden gedrückt werden muss). Nach der Aktualisierung der Firmware-Information in FHEM, muss die [[Konfiguration]] noch gespeichert werden.

==== Fehlersuche / Probleme beim Update via FHEM ====
* Der Firmware-Update nimmt mehrere Minuten in Anspruch (bei einem HM-LC-Bl1PBU-FM bis zu 10 Minuten). Über <code>attr <device> verbose 5</code> kann man für das HM-Device im Log den Fortschritt detaillierter beobachten.
* Sollte es zu einem Abbruch kommen, kann es dazu kommen, dass weitere FW-Update-Versuche abgebrochen werden mit der Fehlermeldung "fail:notInBootLoader" und einem grünen Dauerblinken an der Anlerntaste [https://forum.fhem.de/index.php/topic,84200.msg764555.html#msg764555]. In diesem Fall kann die explizite Angabe des Parameters <code><nowiki>[<time>]</nowiki></code> helfen.

=== Firmware Update mit CUL/HM-CFG-USB unter Linux ===
Für Linux hat mgernoth ein Updatetool erstellt.

Zunächst muss sichergestellt werden, dass alle benötigten Pakete installiert sind. Um das Tool zu installieren und auszuführen, müssen die folgenden Pakete mit den gezeigten Befehlen installiert werden. Unter Debian:
<syntaxhighlight lang="bash">
sudo apt-get install libusb-1.0-0-dev git build-essential
</syntaxhighlight>
Unter OpenSuse 13.2 64 Bit:
<syntaxhighlight lang="bash">
sudo zypper install libusb-1.0-0-dev git
sudo zypper install --type pattern devel_basis
</syntaxhighlight>

Als nächstes wird der Sourcecode für das Tool heruntergeladen (vorher z.B. in den Pfad <code>/usr/src</code> wechseln):
<syntaxhighlight lang="bash">
git clone git://git.zerfleddert.de/hmcfgusb
</syntaxhighlight>
Und mit den Anweisungen
<syntaxhighlight lang="bash">
cd hmcfgusb
make
</syntaxhighlight>
wird daraus eine ausführbare Datei erstellt.

Weiterhin muss die nötige Firmware heruntergeladen und entpackt werden. Die offiziellen Updates gibt es unter [http://www.eq-3.de/downloads.html eq-3 Downloads]. Die Befehle, um beispielsweise die benötigte Datei für die Firmware Version 1.4 des HM-CC-RT-DN zu erhalten lauten:
<syntaxhighlight lang="bash">
wget http://www.eq-3.de/Downloads/Software/Firmware/hm_cc_rt_dn_update_V1_4_001_141020.tgz
tar xvzf hm_cc_rt_dn_update_V1_4_001_141020.tgz
</syntaxhighlight>
Zu guter Letzt muss noch das Tool mit einigen Parametern und der Seriennummer des HomeMatic Devices aufgerufen werden. Für ein Update mit einem CUL (<code>/dev/ttyACM0</code> ist in diesem Beispiel die Adresse des CULs) muss folgendes eingegeben werden:
<syntaxhighlight lang="bash">
sudo ./flash-ota -c /dev/ttyACM0 -f <FirmwareImageName>.eq3 -s <DeviceSerialNo>
</syntaxhighlight>
Für ein Update mit einem COC muss folgendes eingegeben werden (/dev/ttyAMA0):
<syntaxhighlight lang="bash">
sudo ./flash-ota -c /dev/ttyAMA0 -f <FirmwareImageName>.eq3 -s <DeviceSerialNo>
</syntaxhighlight>
Für ein Update mit HM-CFG-USB
<syntaxhighlight lang="bash">
sudo ./flash-ota -f <FirmwareImageName>.eq3 -s <DeviceSerialNo>
</syntaxhighlight>
Nun muss nur noch das HomeMatic Gerät in den Update-Modus versetzt werden. Wie das geht, steht in der jeweils mit der Firmwaredatei gelieferten "readme".

=== Firmware Update mit HM-CFG-USB unter Windows ===
Für ein Firmwareupdate unter Windows wird das "HomeMatic Firmware Update Tool" von eq-3 benötigt: [http://www.eq-3.de/downloads.html eQ-3 Downloads]. Zur Zeit ist das Update damit nur mit dem HM-CFG-USB-2 möglich, nicht aber mit dem HM-CFG-LAN oder dem HM-CFG-USB der ersten Generation.

Nach dem Start muss die Seriennummer des HomeMatic-Device eingegeben und die Firmware-Datei ausgewählt werden. Dann wird das Update-Tool durch einen Klick auf den entsprechenden Button in "Bereitschaft" gesetzt und anschließend muss das HomeMatic-Gerät in den Update-Modus versetzt werden. Bei Unterputz-Geräten ist das eventuell gar nicht so einfach, man kann in diesem Fall aber von FHEM aus dem Gerät ein Kommando schicken um es in den Bootloader Modus zu bringen. Dies geht mit dem Befehl
:<code>set <device> fwUpdate onlyEnterBootLoader</code>
Direkt danach sollte das Update Tool mit seiner Arbeit beginnen.

Falls das Update-Tool beim Auswählen der Firmware-Datei abstürzt ("Home Matic Firmware Update Tool funktioniert nicht mehr"), dann stimmt wahrscheinlich etwas mit der Firmware-Datei nicht. Die Datei darf nicht ausgepackt, sondern muss als ".tar.gz"-Datei, so wie sie heruntergeladen wurde, benutzt werden. Es kann Probleme geben, wenn die Datei mit dem Internet Explorer heruntergeladen wurde. Am einfachsten ist es, die Datei mit einem anderen Browser herunterzuladen.

== Mögliche Probleme ==
Lässt sich die Firmware nicht OTA auf das HomeMatic-Device flashen, kann dies folgende Ursachen haben:
* Die FHEM-Software ist nicht auf dem neuesten Stand. Bitte vorher ein ''update'' durchführen.
* '''Entfernung''' zwischen Sender und Empfänger '''zu klein'''. 1,5 bis 2 m Abstand sollten beide Geräte zueinander mindestens haben.
* '''Entfernung''' zwischen Sender und Empfänger '''zu groß'''. Überprüfen Sie die RSSI-Werte des zu flashenden Device. Schlechter als - 70 sollten sie nicht sein (also keine - 75 oder noch kleiner). Ansonsten muss der Abstand für die Dauer des Flashens verringert werden.
* Durch wiederholte Firmware-Updates oder Update-Versuche hat die [[1% Regel]] zugeschlagen. Der dort genannte Notbehelf (Funkschnittstelle kurz stromlos machen) schafft Abhilfe.

== Tool zur Firmware Versionsprüfung ==
[[Datei:HM-FWUpdate-eQ3.png|mini|400px|right|Beispiel einer Liste der relevanten Firmware Updates '''Legende:''' 1 - Link auf die eQ-3 Download-Seite 2 - Link auf die Details des HTTPMOD Device 3 - Link auf die Details des HomeMatic Device 4 - (Download) Link auf die Firmware Datei 5 - "reread": Aktualisierung dieser Liste auslösen]]
Im FHEM-Forum wurden unter dem Titel {{Link2Forum|Topic=47729|LinkText=...Firmware Versionsprüfung}} die erforderlichen Definitionen für ein [[HTTPMOD]]-Device vorgestellt, das
* für alle HomeMatic Devices der aktuellen FHEM-Umgebung
* die derzeit benutzte Firmware Version mit
* einem evtl. auf der eQ-3 Seite verfügbaren Update vergleicht und
* alle für die aktuelle Installation relevanten Updates in einer Übersicht (siehe Screenshot) darstellt und
* einmal täglich (alle 86400 Sekunden) automatisch ausgeführt wird; dieses Intervall sollte nicht verkürzt, sondern eher verlängert werden. Im Bedarfsfall kann durch anklicken von '''''reread''''' eine sofortige Aktualisierung ausgelöst werden.
 
{{Randnotiz|RNTyp=y|RNText=Sollte eine alte (vor dem 15.3.2016) Version dieser Definitionen bereits in Benutzung sein (zu erkennen am Vorhandensein von ''<nowiki>reading0[2|3|4|5]*</nowiki>''-Attributen), dann wird empfohlen, das Device mit <code>delete eq3</code> zunächst komplett zu löschen und anschließend neu anzulegen.}}
Die unten aufgeführten erforderlichen Anweisungen zur Erstellung dieser Übersicht sind
* im wesentlichen über das Webinterface eingebbar (können aber auch "en bloc" in die fhem.cfg eingetragen werden - auch wenn das eigentlich nicht empfohlen ist)
* der umfangreiche Perl-Code für das Attribut ''userReadings'' ist dargestellt für die Eingabe über das [[FHEMWEB|Webinterface]]
* für das Attribut ''stateFormat'' ist die mehrzeilige Eingabe (zumindest derzeit, März 2016) nicht unterstützt, daher wurde der Code in eine Subroutine ausgelagert
 {{Randnotiz|RNTyp=r|RNText='''Wichtige Änderungen:'''
22.05.2016 - ''reading01Regex'' und ''reading01Format'' angepasst (eQ-3)
}} 

=== Basis-Definitionen für Device eq3 ===
<syntaxhighlight lang="text">
define eq3 HTTPMOD http://www.eq-3.de/service/downloads.html 86400
attr eq3 userattr enableControlSet event-on-change-reading event-on-update-reading reading01AutoNumLen reading01Format reading01Name reading01RegOpt reading01RegOpt:s,i,g reading01Regex readingMaxAge readingMaxAgeReplacementMode readingMaxAgeReplacementMode:text,expression,delete requestData.* showError showMatched stateFormat userReadings webCmd
attr eq3 enableControlSet 1
attr eq3 event-on-change-reading .*
attr eq3 event-on-update-reading LAST_ERROR,MATCHED_READINGS
attr eq3 reading01AutoNumLen 2
attr eq3 reading01Format http://www.eq-3.de/%s
attr eq3 reading01Name fw_link
attr eq3 reading01RegOpt g
attr eq3 reading01Regex <a.href="(Downloads\/Software\/Firmware\/[^"]+)
attr eq3 readingMaxAge 10
attr eq3 readingMaxAgeReplacementMode delete
attr eq3 requestData.* suchtext=&suche_in=2&downloadart=11
attr eq3 room eq3
attr eq3 showError 1
attr eq3 showMatched 1
attr eq3 stateFormat {eq3StateFormat}
attr eq3 webCmd reread
</syntaxhighlight>

=== Definition/Code für Attribut userReadings ===
Der "Zugang" zur Eingabe des Attributs ''stateFormat'' erfolgt über die Details des Device '''eq3''' (URL: ...8083/fhem?detail=eq3).
[[Datei:HM-FWUpdate-eQ3-userReadings.png|mini|640px|left|"Der Weg" zur Eingabe von ''userReadings''; durch Klick in das Eingabefeld öffnet sich ein separates Fenster.]]
 Der Perl-Code, der für das Attribut ''userReadings'' eingegeben werden muss:
<syntaxhighlight lang="perl">
newFwForDevices:MATCHED_READINGS:.* {
my $ret = "";
my @data;
my @eq3FwList = map{@data = ReadingsVal("eq3","fw_link-".$_,"?") =~ m/Firmware\/(.*?)_update_V([\d_]+)_(\d\d)(\d\d)(\d\d)/;
$data[0] =~ s/_/-/g;
sprintf("%s:%s:%s.%s.%s:%s",$data[0],$data[1],$data[4],$data[3],"20".$data[2],$_);
} ReadingsVal("eq3","MATCHED_READINGS","?") =~ m/fw_link-(\d\d)/g;

foreach my $dev (devspec2array("TYPE=CUL_HM:FILTER=DEF=......:FILTER=subType!=(virtual|)")) {
my $md = AttrVal($dev,"model","?");
my $v = AttrVal($dev,"firmware","0.0");
my ($h,$l) = split('\.',$v);
foreach my $newFw (grep m/^${md}:/i,@eq3FwList) {
my ($nh,$nl,$no,$date,$idx) = $newFw =~ m/^[^:]+:(\d+)_(\d+)_?(\d*):([^:]+):(\d\d)$/;
if(($nh > $h) || (($nh == $h) && ($nl > $l))) {
$ret .= "," if($ret ne "");
$ret .= $dev." (".$md." | fw_".$v." => fw".$idx."_".$nh.".".$nl.($no?sprintf(".%d",$no):"")." | ".$date.")";
}
}
}
return ($ret eq "")?"no fw-updates needed!":$ret;
}
</syntaxhighlight>

=== Definition/Code für Attribut stateFormat ===
Da der Code für ''stateFormat'' recht umfangreich ist, wäre er als Einzeiler kaum sinnvoll zu verwalten, würde also ohnehin meistens über einen externen Editor bearbeitet werden. Daher wurde er als eigene (Sub-)Routine mit dem Namen ''eq3StateFormat'' in (z.B.) [[99_myUtils anlegen|99_myUtils]] ausgelagert:
<syntaxhighlight lang="perl">
sub eq3StateFormat() {
my $name = "eq3";

my $ret ="";
my $lastCheck = ReadingsTimestamp($name,"MATCHED_READINGS","???");
$ret .= '<div style="text-align:left">';
$ret .= 'last <a title="eq3-downloads" href="http://www.eq-3.de/downloads.html">homematic</a>-fw-check => '.$lastCheck;
$ret .= ' ';
$ret .= '<pre>';
$ret .= "| device | model | old_fw | new_fw | release |\n";
$ret .= "------------------------------------------------------------------------------------\n";
my $check = ReadingsVal($name,"newFwForDevices","???");
if($check eq "no fw-updates needed!") {
$ret .= '| '.$check.' |';
} else {
my @devices = split(',',$check);
foreach my $devStr (@devices) {
my ($dev,$md,$ofw,$idx,$nfw,$date) = $devStr =~ m/^([^\s]+)\s$([^\s]+)\s\|\sfw_(\d+\.\d+)\s=>\sfw(\d\d)_([\d\.]+)\s\|\s([^$]+)\)$/;
my $link = ReadingsVal($name,"fw_link-".$idx,"???");
$ret .= '| ';
$ret .= '<a href="/fhem?detail='.$dev.'">';
$ret .= sprintf("%-23s",$dev);
$ret .= '</a>';
$ret .= " | ";
$ret .= '<b'.(($md eq "?")?' title="missing attribute model => set device in teach mode to receive missing data" style="color:yellow"':' style="color:lightgray"').'>';
$ret .= sprintf("%-23s",$md);
$ret .= '';
$ret .= " | ";
$ret .= '<b'.(($ofw eq "0.0")?' title="missing attribute firmware => set device in teach mode to receive missing data" style="color:yellow"':' style="color:lightgray"').'>';
$ret .= sprintf("%6s",$ofw);
$ret .= '';
$ret .= " | ";
$ret .= '<a title="eq3-firmware.tgz" href="'.$link.'">';
$ret .= '';
$ret .= sprintf("%6s",$nfw);
$ret .= '';
$ret .= '</a>';
$ret .= " | ";
$ret .= sprintf("%-10s",$date);
$ret .= " |\n";
}
}
$ret .= '</pre>';
$ret .= '</div>';
return $ret;
}
</syntaxhighlight>

=== Sondersituationen ===
[[Datei:HM-FWUpdate-eQ3-check.png|mini|455px|right|Fehlerbedingung: Attribut ''firmware'' nicht gesetzt]]
Das Tool überprüft gleichzeitig auch bestimmte Rahmenbedingungen, so z.B., ob bei allen HomeMatic Devices die Attribute ''model'' und ''firmware'' gesetzt sind. Sollte das nicht der Fall sein, wird das Device in der Liste
* mit einem gelben "old_fw" Wert von 0.0 geführt; befindet sich der Mauszeiger über dem "0.0", wird der Hinweistext ''missing attribute firmware => set device in teach mode to receive missing data'' angezeigt (siehe Beispiel im Screenshot)
* mit einem gelben {{Taste|?}} in der Spalte "model" angezeigt; befindet sich der Mauszeiger über dem "?", wird der Hinweistext ''missing attribute model => set device in teach mode to receive missing data'' angezeigt
In diesem Fall sollte bei dem betreffenden Gerät versucht werden, mit ''getConfig'' die Daten zu aktualisieren bzw. vervollständigen.

Darüber hinaus ist zu beachten, dass die Firmware-Version in den HomeMatic Geräten zwei"teilig" (Version.Release) abgelegt ist, die Firmware Update-Dateien jedoch drei"teilige" Versionskennungen (Version_Release_???) haben. Für den Vergleich, ob neue Firmware verfügbar ist, kann natürlich nur die zweiteilige Kennung verwendet werden, eine Änderung im dritten Teil der Versionskennung kann daher nicht automatisch erkannt werden.

== Links ==
* [http://www.eq-3.de/downloads.html Firmware Download] Seite von eq-3
* Forenthread zur {{Link2Forum|Topic=47729|LinkText="Firmware Versionsprüfung"}}
* [http://git.zerfleddert.de/hmcfgusb/ Firmware Update Tool] von mgernoth

[[Kategorie:HomeMatic Components|1toolsAndWork]]
[[Kategorie:HOWTOS]]

Diskussion:Neues Charting Frontend

2016-08-07T08:08:57Z

Sledge: Hinweis auf Redundanz zu DbLog Artikel

Speziell im Abschnitt "dblog" hohe inhaltliche Redundanz zum Wiki-Artikel [http://www.fhemwiki.de/wiki/DbLog]. Wenn ok würde reduzieren auf das Erstellen der neuen Tabelle "frontend" und auf die Einrichtung von DbLog verweisen. --[[Benutzer:Sledge|Sledge]] ([[Benutzer Diskussion:Sledge|Diskussion]]) 10:08, 7. Aug. 2016 (CEST)

DbLog

2016-08-05T14:59:48Z

Sledge: Hinweis darauf, dass rereadcfg nach Erstellen und Definition von dblog genügt.

{{Infobox Modul
|ModPurpose=Protokolliert Ereignisse in einer Datenbank
|ModType=h
|ModForumArea=Automatisierung
|ModTechName=93_DbLog.pm
|ModOwner=tobiasfaust ({{Link2FU|118|Forum}}/[[Benutzer Diskussion:Tobias.faust|Wiki]])
}}

== Einleitung ==
Mit der Zeit entstehen im fhem recht umfangreiche Log-Daten für die verschiedensten konfigurierten Devices. Die übliche Einstiegs-[[Konfiguration]] sieht vor, dass die Logs als [http://fhem.de/commandref_DE.html#FileLog FileLog] gespeichert werden - je nach Einstellung in wenigen sehr großen oder vielen kleineren Dateien. Der Datei-basierte Zugriff ist allerdings nicht wirklick performant und kann schnell zum Flaschenhals werden (z.B. bei der Darstellung von Graphen über einen längeren Zeitraum).

Alternativ kann Fhem die Log-Daten mittels [http://fhem.de/commandref_DE.html#DbLog DbLog] in einer Datenbank speichern. Diese kann lokal als einfache SQLite- oder als zentrale Server-Datenbank (s.u.) gestaltet sein. Schon eine lokale einfache SQLite-Datenbank ist in der Regel deutlich performanter als File-basierte Logs.

Damit eine Datenbank-Nutzung möglich ist, müssen folgende Anpassungen gemacht werden:
# [[#Datenbank|Erstellen einer entsprechenden Datenbank]]
# [[#Datenbank-Anbindung mittels db.conf|Konfiguration der Datenbank-Anbindung in FHEM]]
# [[#Konfiguration als Device in fhem.cfg|Anpassen aller (oder einzelner) Konfigurationen von FileLog nach DbLog]]
# [[#Anpassen der gplot-Konfigurationen|Ggf. Anpassen der gplot-Konfigurationen]]

== Konfiguration ==
=== Datenbank-Anbindung mittels db.conf ===
DbLog wird durch 2 verschiedene Einträge aktiviert/definiert. In einer Datei namens '''db.conf''' werden die Parameter für eine Verbindung zur Datenbank (host, username, password, etc.) hinterlegt. Diese Datei kann in einem beliebigen Verzeichnis angelegt werden. Für eine MySQL-Datenbank sieht die db.conf folgendermaßen aus:

%dbconfig= (
connection => "mysql:database=fhem;host=db;port=3306",
user => "fhemuser",
password => "fhempassword",
);

Im Verzeichnis '''contrib/dblog''' der FHEM-Installation befindet sich eine Beispielkonfiguration mit der Syntax für jeden unterstützen Datenbanktyp.

=== Konfiguration als Device ===
Das DbLog Device wird dann definiert mit
:<code>define <name> DbLog <configfilename> <regexp> </code>
wobei ''<configfilename>'' dem Pfad zur zuvor angelegten db.conf entspricht.
Ein Beispiel hierfür wäre:
:<code>define logdb DbLog ./db.conf .*:.* </code>
Die Angabe von <code>.*:.*</code> bedeutet, dass sämtliche DeviceMessages (Messwerte, Batteriestatus, KeepAlives, etc.) in die Datenbank geschrieben werden. Dies führt u.U. dazu, dass die Datenbank auch mit vielen teils irrelevanten Werten gefüllt wird. Man kann daher die zu loggenden Werte einschränken, indem man genau angibt welche Werte übertragen werden sollen. Dies ist in [[#Finetuning des Loggings]] beschrieben.

=== Finetuning des Loggings ===
Bei der Konfiguration des Log-Devices werden die zu loggenden Daten definiert - in der einfachsten Form sieht das so aus: <code>define logdb DbLog ./db.conf .*:.* </code>. Die Angabe von <code>.*:.*</code> bedeutet, dass sämtliche DeviceMessages (Messwerte, Batteriestatus, KeepAlives, etc.) in die Datenbank geschrieben werden. Dies führt u.U. dazu, dass die Datenbank auch mit sehr vielen und teils nicht benötigten Werten gefüllt wird und schnell wächst. Die Datenbank ist zwar deutlich leistungsfähiger, was große Datenmengen angeht, Datensparsamkeit kann aber schnell sinnvoll werden...

Um das Log-Aufkommen einzugrenzen gibt es 2 Ansätze:
* Einschränkung über den <code>define</code>-Eintrag
* Einschränkung über DbLogExclude-Einträge der jeweiligen Devices
* Einschränkung über DbLogInclude-Einträge des jeweiligen Devices

==== Einschränkung über den zentralen <code>define</code>-Eintrag ====
Man kann die zu loggenden Werte einschränken, indem man genau angibt welche Werte übertragen werden sollen. Die erste Wildcard, also das erste <code>.*</code>, entspricht dem in FHEM verwendeten Device-Namen. Die zweite Wildcard entspricht dem vom Device ausgegebenen zu loggenden Wert. Separiert werden beiden Angaben durch einen Doppelpunkt.

Ein Beispiel, um zwar alle definierten Devices zu erfassen, aber nur die Werte Temperatur, Ventilposition und Luftfeuchte in die Datenbank zu schreiben wäre:
:<code>define myDbLog DbLog ./db.conf .*:(temperature|valveposition|humidity).* </code>

==== Einschränkung über die jeweiligen Devices ====
Man kann die zu loggenden Werte für einzelne Devices separat einschränken, ohne dies im zentralen define-Eintrag machen zu müssen. Dies kann interessant sein, wenn beispielsweise ein Device Fehlerwerte meldet, die uninteressant sind, oder es meldet unnötig häufig Werte - beides ist z.B. bei 1-wire-Temperatursensoren gerne der Fall.

Um das einzuschränken gibt es 2 Stellparameter, die als Attribute direkt zum jeweiligen Device konfiguriert werden:
* DbLogExclude - definiert Werte, die nicht geloggt werden sollen
* DbLogInclude - definiert Werte, die geloggt werden sollen ( siehe attr DbLogSelectionMode )
* event-min-interval, event-on-change-reading und event-on-update-reading beeinflussen, wie häufig Werte geloggt werden (vgl. [http://fhem.de/commandref_DE.html#event-on-update-reading commandref])

Eine konkrete Konfiguration für einen sehr gesprächigen 1-wire-Temperatursensor könnte wie folgt aussehen:
<pre>
define EG_Balkon GPIO4 BUSMASTER
attr EG_Balkon DbLogExclude failures,T,85 # logge keine "failures", "T"-Werte und "85"-Werte (default-Werte, wenn keine Temperatur gelesen werden kann)
attr EG_Balkon event-on-change-reading state # logge nur, wenn sich ein Wert ändert (wenn sich die Temperatur nicht ändert, logge das nicht)
attr EG_Balkon event-min-interval state:900 # logge spätestens alle 900sec = 15min
attr EG_Balkon event-on-update-reading .* # logge alle Werte, die aktualisiert werden

attr <1-Wire-Device vom Typ OWTHERM oder OWSWITCH> DbLogExclude data.* # verhindert das Logging der state-Eintragungen
</pre>

Eine in diesem {{Link2Forum|Topic=33697|Message=264127}} vorgestellte Strategie zur Vermeidung unnötigen Loggings ist, dass bei der Definition von Devices durch das nachfolgende <code>notify</code> automatisch ein DbLogExclude für alle Werte (.*) des Devices zugewiesen wird und dies nur bei Interesse an geloggten Werten gelöscht bzw. angepasst wird:
<code>define nDbLogExclude notify global:DEFINED.* attr $EVTPART1 DbLogExclude .*</code>

Ebenso ist es mittlerweile möglich, lediglich erwünschte Werte (Positiv-Liste) zu loggen und alle anderen zu verwerfen. Hierfür wird im LogDevice das attribut DbLogSelectionMode Include verwendet. Nun kann für jedes Device mit DbLogInclude <Reading1>,<Reading2>,... angegeben werden, welche Readings geloggt werden sollen.
Integriert ist ebenfalls ein "min-interval", siehe commandref.

== Datenbank ==
Unterstützte Datenbanksysteme (Auswahl):
* Sqlite
* MySQL
* PostGreSql

=== Tabellen ===
* current
* history

Die Tabelle current enthält für jedes zu loggende Device lediglich den letzten Wert. Falls noch kein Wert geloggt wurde, ist diese Tabelle leer.
Falls der Inhalt gelöscht wird, bauen sich die Daten automatisch wieder auf. Es gehen durch das löschen der Tabelle current keine Log-Informationen verloren.
Der Inhalt wird aber u.a. für die Dropdown-Felder beim Plot-Editor verwendet.

Die Tabelle history enthält alle bisher geloggten Daten. Löschen in dieser Tabelle bedeutet automatisch Datenverlust (gewollt oder nicht ... )
Der Inhalt dieser Tabelle wird verwendet, um die Plots zu zeichnen.

=== Tabellenlayout ===
DbLog ist auf eine feste Tabellenstruktur angewiesen. Man muss daher in seiner Datenbank eine Tabelle mit folgenden Spalten anlegen:
{| class="wikitable"
|-
! Spalte
! Beschreibung (en)
! Beschreibung (de)
! Beispiel
|-
| '''TIMESTAMP'''
| timestamp of event
| Zeitstempel
| 2007-12-30 21:45:22
|-
| '''DEVICE'''
| device name
| Device-Name
| Wetterstation
|-
| '''TYPE'''
| device type
| Device-Typ
| KS300
|-
| '''EVENT'''
| event specification as full string
| Eventspezifikation als Text
| humidity: 71 (%)
|-
| '''READING'''
| name of reading extracted from event
| Bezeichnung des Readings
| humidity
|-
| '''VALUE'''
| actual reading extracted from event
| Wert des Readings
| 71
|-
| '''UNIT'''
| unit extracted from event
| Einheit des Readings
| %
|-
|}

Die Vorlagen zur Anlage von Tabellen und Indizes sind für jeden unterstützten Datenbanktyp im Verzeichnis '''contrib/dblog''' der FHEM-Installation, oder hier zu finden: [http://sourceforge.net/p/fhem/code/HEAD/tree/trunk/fhem/contrib/dblog/ Link]. Das MySQL-Skript (db_create_mysql.sql) legt eine neue Datenbank, das PostGres-Skript (db_create_postgresql.sql) ein neues Schema mit Namen "fhem" an.

== Anpassen der gplot-Konfigurationen ==
Die meisten gplot-Konfigurationen sind bisher lediglich auf FileLog-Konfigurationen ausgelegt. Deshalb müssen sie für die Verwendung mit DbLog angepasst werden. Glücklicherweise beschränkt sich dies auf die reinen FileLog-Zeilen - es müssen die DbLog-Äquivalente hinzugefügt werden. Die FileLog-Einträge müssen zwar nicht gelöscht werden, wenn man aber FileLog und DbLog parallel betreibt, sollte man getrennte gplot-Dateien für beide Logging-Typen haben um Auswertungsprobleme erkennen zu können.

Für die fht.gplot Konfiguration sähe die Anpassung wie folgt aus (lediglich die vier DbLog-Zeilen wurden hinzugefügt):
<pre>
# Created by FHEM/98_SVG.pm, 2014-12-25 21:53:30
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 ytics nomirror
set y2tics
set grid y2tics
set ylabel "Actuator/Window (%)"
set y2label "Temperature in C"
set yrange 0:100
set y2range 5:25

#FileLog 4:.measured-temp\x3a:0:
#FileLog 4:.actuator\x3a:0:int
#FileLog 4:.desired-temp::
#FileLog 4:.window\x3a::

#DbLog <SPEC1>:.measured-temp:0:
#DbLog <SPEC1>:.actuator:0:int
#DbLog <SPEC1>:.desired-temp::
#DbLog <SPEC1>:.window::

plot "<IN>" using 1:2 axes x1y2 title 'Measured temperature' ls l0 lw 1 with lines,\
"<IN>" using 1:2 axes x1y1 title 'Actuator (%)' ls l1 lw 1 with lines,\
"<IN>" using 1:2 axes x1y2 title 'Desired Temperature' ls l2 lw 1 with steps,\
"<IN>" using 1:2 axes x1y1 title 'Window' ls l3 lw 1 with steps
</pre>

== Beispiel: Anlegen und Nutzung einer SQLite-Datenbank ==
Im folgenden wird eine lokale SQLite-Datenbank auf einen Ubuntu-System angelegt (nach Quelle: [http://www.tatsch-it.de/fhem-dblog/ http://www.tatsch-it.de/fhem-dblog/])
<ol>
<li>
''Installation von SQLite:''
<pre>sudo aptitude install sqlite3 libdbi-perl libdbd-sqlite3-perl</pre>
</li>
<li>
''Anlegen der SQLite-Datenbank fhem.db'' (öffnet auch direkt eine SQL-Kommandozeile):
<pre>sudo sqlite3 /opt/fhem/fhem.db</pre>
In der geöffneten SQL-Kommandozeile eingeben:
<pre>
CREATE TABLE 'history' (TIMESTAMP TIMESTAMP, DEVICE varchar(32), TYPE varchar(32), EVENT varchar(512), READING varchar(32), VALUE varchar(32), UNIT varchar(32));
CREATE TABLE 'current' (TIMESTAMP TIMESTAMP, DEVICE varchar(32), TYPE varchar(32), EVENT varchar(512), READING varchar(32), VALUE varchar(32), UNIT varchar(32));
</pre>
Die Kommandozeile verlässt man mit <code>.exit</code>.
</li>
<li>
''Anpassen des Besitzers und der Rechte der Datenbank-Datei:''
<pre>
sudo chown fhem /opt/fhem/fhem.db
sudo chmod 666 /opt/fhem/fhem.db
</pre>
</li>
<li>
''Datenbank-Anbindung des FHEM konfigurieren:''
<pre>sudo nano /opt/fhem/db.conf</pre>
Inhalt:
<pre>
%dbconfig= (
connection => "SQLite:dbname=/opt/fhem/fhem.db",
user => "",
password => ""
);
</pre>
</li>
<li>
''Logging des FHEM auf die Datenbank konfigurieren:'' (hier sind nur die Anpassungen aufgeführt)
<pre>sudo nano /opt/fhem/fhem.cfg</pre>
<pre>
...
attr global userattr DbLogExclude ... # erlaubt es einzelne Einträge nicht zu loggen
...
define logdb DbLog ./db.conf .*:.* # logt alle(!) auflaufenden Events aller Konfigurationen
...
</pre>
Da durch diese <code>define</code>-Definition alle auflaufenden Events gelogt werden, müssen keine weiteren Anpassungen in der Konfiguration gemacht werden. Die FileLog-Einträge können bedenkenlos bestehen bleiben - dann wird in Datenbank und FileLog gelogt und man verliert keine Daten, falls etwas nicht klappt. Wenn alles wie geplant läuft, können die FileLog-Definitionen gelöscht werden (ebenso die Log-Dateien). Ebenso können die zu loggenden Daten später eingegrenzt werden (s. [[#Finetuning des Loggings]]).
</li>
<li>
''FHEM neu starten:''
<pre>
sudo service fhem stop
sudo service fhem start
</pre>
</li>
<li>
''Kontrollieren, ob Logs in die Datenbank geschrieben werden:''
<pre>sudo sqlite3 /opt/fhem/fhem.db</pre>
In der geöffneten SQL-Kommandozeile eingeben:
<pre>
select * from history order by TIMESTAMP; # dies gibt alle(!) Logs chronologisch aus (kann nach längerem Betrieb recht lange dauern)
</pre>
Die Kommandozeile verlässt man mit <code>.exit</code>.
</li>
<li>
''Anpassung der glot-Dateien:'' siehe [[#Anpassen der gplot-Konfigurationen]]
</li>
</ol>

== Beispiel: Anlegen und Nutzung einer Mysql-Datenbank ==
Unter Ubuntu:
apt-get install mysql-server mysql-client
ob man die Pakete
apt-get install libdbd-mysql libdbi1 libdbd-mysql-perl
auch installieren muss, weiss ich nicht, bei mir sind sie drin

Bei der Installation sollte man aus Sicherheitsgründen ein Passwort für den mysql-root vergeben, wenn man nicht sogar ganz den Login verbietet.

nun zu mysql verbinden:
mysql -p -u root
Enter password:

Jetzt die Tabellenstruktur anlegen.
Hierfür kann nach Bedarf in der Datei /opt/fhem/contrib/dblog/db_create_mysql.sql das Passwort und der Benutzername geändert werden.
Dann wird die Datei eingelesen:

#mysql -u root -p < db_create_mysql.sql

Jetzt kann man den Zugang testen:

#mysql -p -u <fhemuser>
Enter password: <fhempassword>
mysql> show databases;

Nun müsste eine Datenbank "fhem" angezeigt werden, die die Tabellen current und history enthält.

Nun in der Datei db.conf den mysql-Block auskommentieren und ebenfalls Benutzername, Passwort UND HOST anpassen. Leider ist hier nicht standardmäßig localhost eingestellt.
vim /opt/fhem/contrib/dblog/db.conf

Jetzt kann ein DbLog-Device angelegt werden:
define logdb DbLog ./contrib/dblog/db.conf .*:.* # loggt ALLES!
Als State muss ein "connected" angezeigt werden.

Ein rereadcfg in Fhem stellt sicher, dass die neue Konfiguration übernommen wird - ein Neustart ist nicht erforderlich

Nun kann die Funktion noch einmal überprüft werden:
<source lang="sql">
#mysql -u <fhemuser> -p
Enter password: <fhempassword>
mysql> use fhem;
Database changed
mysql> show tables;
+----------------+
| Tables_in_fhem |
+----------------+
| current |
| history |
+----------------+
2 rows in set (0,00 sec)
mysql> select * from current; # Achtung, kann sehr groß werden .... #
</source>

== Integration von DBLog in eigene Module ==
=== Bereitstellung der UNITS ===
Mit der DbLog_SplitFn kann der Modulautor selbst festlegen, wie die Events des Moduls in die Bestandteile Reading/Value/Unit zerlegt werden um ein korrektes Logging per DbLog zu gewährleisten.
Weitere Informationen siehe hier: [[DevelopmentModuleIntro#X_DbLog_splitFn]]

== Bekannte Probleme ==
Beim Anlegen der Datenbank per script wird die Value-Spalte nur als Varchar(32) definiert. Dieses kann dazu führen, dass besonders lange Readings (z.b. vom Modul sysmon) abgeschnitten werden und nicht in der Datenbank landen. Dieses lässt sich leicht beheben, indem man die Spalte auf Varchar(64) ändert (siehe auch {{Link2Forum|Topic=25648|Message=252433|LinkText=diesen Forenbeitrag}}).

mysql> ALTER TABLE current MODIFY VALUE VARCHAR(64);
mysql> ALTER TABLE history MODIFY VALUE VARCHAR(64);

== Bearbeitung von Datenbank-Einträgen ==
{{Hinweis|Dieser Abschnitt soll lediglich eine kleine Einführung in die Datenbank-Bearbeitung liefern. Für vertiefende Informationen sollte man sich grundsätzlich mit SQL beschäftigen. Eine umfassende und gut verständliche Anleitung zu SQL bietet bspw. [http://www.w3schools.com/sql/default.asp w3schools].}}
Irgendwann wird der Fall eintreten, dass in der Datenbank Einträge drinstehen, die geändert oder gelöscht werden sollen (zB. fehlerhafte Sensor-Rückmeldungen, umbenannte Readings). In klassischen Log-Dateien würde man diese einfach bearbeiten und löschen/anpassen (wobei man aber tunlichst zuvor den fhem ausmacht um Datenfehler zu vermeiden). Eine Datenbank kann bearbeitet werden ohne den fhem abschalten zu müssen.

Datenbanken kann man ohne weiter Hilfsmittel direkt von der Kommandozeile/Shell aus bearbeiten. Alternativ gibt es auch verschiedenste Tools (webbasiert oder als Applikation), die einen dabei unterstützen (Bsp. findet man u.a. [https://wiki.ubuntuusers.de/SQLite/#Grafische-Benutzeroberflaechen hier]). Für einfache Arbeiten reicht allerdings idR. Shell.

=== SQLite-Datenbanken ===
'''Öffnen der DB unter Linux:'''

(Es werden Schreibrechte benötigt,ohne kann man die DB zwar öffnen, aber nichts machen)
sudo sqlite3 fhem.db
Dadurch öffnet sich ein SQL-Konsole, auf der alle weiteren Befehle ausgeführt werden.

'''Schliessen der DB:'''

sqlite> .exit

'''Hilfe anzeigen:'''

sqlite> .help

'''Alle Tabellen anzeigen:'''

sqlite> .tables

'''Das Schema der DB anzeigen:'''

(vgl. oben [[DbLog#Datenbanken]] und [[DbLog#Beispiel: Anlegen und Nutzung einer SQLite-Datenbank]])

sqlite> .schema

'''Alle Eintäge anzeigen:'''

Die Einträge liegen alle in der Tabelle "History".

'''Ganz wichtig''' ist immer das ";" am Ende Zeile (bei allen Kommandos, die nicht mit einem "." anfangen). Wenn es vergessen wurde zeigt die Konsole solange neue Zeilen bis ein ";" eingegeben wird. So kann ein Befehl auch bequem über mehrere Zeilen geschrieben werden.

sqlite> select * from HISTORY;

Dies kann sehr lange dauern und kann ggf. mit <code>STRG-C</code> abgebrochen werden.

'''Alle Einträge eines Geräts anzeigen:'''

In <code>where</code>-Statements werden Strings in einfache Anführungsstriche gesetzt, Zahlen nicht.

sqlite> select * from HISTORY where DEVICE='Pollenflug';

'''Alle Einträge eines Readings eines Geräts anzeigen:'''

sqlite> select * from HISTORY where DEVICE='Pollenflug' and READING='Graeser';

'''Alle Einträge eines bestimmten Wertes eines Readings eines Geräts anzeigen:'''

sqlite> select * from HISTORY where DEVICE='Pollenflug' and READING='Graeser' and VALUE>1;

'''LÖSCHEN aller Einträge eines bestimmten Wertes eines Readings eines Geräts anzeigen:'''

'''Achtung:''' Löschen kann nicht rückgängig gemacht werden!! Also IMMER erst die entsprechenden SELECT-Statements solange verfeinern bis wirklich nur die gewünschten Einträge angezeigt werden. Dann das <code>select *</code> durch <code>delete</code> ersetzen.

sqlite> delete from HISTORY where DEVICE='Pollenflug' and READING='Graeser' and VALUE>1;

== Datenbank reparieren ==
Es kann immer wieder mal vorkommen, dass Datenbanken Fehler enthalten. Das muss im Alltag garnicht auffallen und auch nicht immer schlimm enden. Wenn man auf der SQL-Konsole aber bspw. eine Meldung <code>Error: database disk image is malformed</code> erhält, sollte man ein Reparatur vornehmen.

=== SQLite-Datenbanken ===
Die folgenden Schritte beschreiben, wie man eine SQLite-DB reparieren kann (Quelle: [http://techblog.dorogin.com/2011/05/sqliteexception-database-disk-image-is.html]):

<ol>
<li>
DB öffnen:
<pre>sudo sqlite3 fhem.db</pre>
</li>
<li>
Integritäts-Check durchführen:
<pre>sqlite> pragma integrity_check;</pre>
Kommt hier ein "ok" ist die DB gesund. Ansonsten erscheint etwas wie
<pre>
*** in database main ***
On tree page 118786 cell 1: Rowid 75 out of order (previous was 816660)
On tree page 118786 cell 4: Rowid 815704 out of order (previous was 816727)
Corruption detected in cell 0 on page 118786
Multiple uses for byte 132 of page 118786
...
</pre>
</li>
<li>
Datenbank-Dump erstellen (Export gesamten DB in die Datei "dump_all_20160516_1043.sql") und DB verlassen:
<pre>
sqlite> .mode insert
sqlite> .output dump_all_20160516_1043.sql
sqlite> .dump
sqlite> .exit
</pre>
</li>
<li>
Neue Datenbank erstellen und den Dump einlesen, Integritäts-Check machen und verlassen:
<pre>sudo sqlite3 fhem-neu.db</pre>
<pre>
sqlite> .read dump_all_20160516_1043.sql
sqlite> pragma integrity_check;
ok
sqlite> .exit
</pre>
</li>
<li>
Spätestens jetzt fhem stoppen:
<pre>sudo service fhem stop</pre>
</li>
<li>
Alte DB sichern und neue aktivieren:
<pre>
sudo mv fhem.db fhem.db.sv_20160516
sudo mv fhem-neu.db fhem.db
</pre>
</li>
<li>
Kontrollieren, dass die neue DB die gleichen Rechte wie die alte DB hat (und ggf. korrigieren):
<pre>
~/fhem$ ls -lha
insgesamt 6,3G
drwxr-xr-x 12 fhem root 4,0K Mai 16 11:07 .
drwxr-xr-x 4 root root 4,0K Dez 25 17:50 ..
...
-rw-r--r-- 1 root root 1,4G Mai 16 11:04 fhem.db
-rw-r--r-- 1 fhem root 2,6G Mai 16 10:59 fhem.db.sv_20160516
...

~/fhem$ sudo chown fhem:root fhem.db

~/fhem$ ls -lha
insgesamt 6,3G
drwxr-xr-x 12 fhem root 4,0K Mai 16 11:07 .
drwxr-xr-x 4 root root 4,0K Dez 25 17:50 ..
...
-rw-r--r-- 1 fhem root 1,4G Mai 16 11:04 fhem.db
-rw-r--r-- 1 fhem root 2,6G Mai 16 10:59 fhem.db.sv_20160516
...
</pre>
</li>
<li>
fhem wieder starten (und natürlich kontrollieren):
<pre>sudo service fhem start</pre>
</li>
</ol>

== Links ==
* [[Heizleistung_und_Gasverbrauch|Beispiel das DbLog-Daten für SVG-Plots verwendet]]
* [[SVG-Plots von FileLog auf DbLog umstellen]]

HM-CFG-LAN LAN Konfigurations-Adapter

2016-08-05T10:39:20Z

Sledge: Info wg. häufiger Disconnects / Firmware aktualisiert

{{Infobox Hardware
|Bild=HM-CFG-LAN.jpg
|Bildbeschreibung=HM-CFG-LAN, Draufsicht und Seitenansicht
|HWProtocol=HomeMatic
|HWType=[[Interface]]
|HWCategory=
|HWComm=868,3 MHz
|HWChannels=n/a
|HWVoltage=7,5 VDC
|HWPowerConsumption=ca. 100 mA
|HWPoweredBy=Steckernetzteil
|HWSize=100x30mm (ø x H)
|HWDeviceFHEM=[http://fhem.de/commandref.html#HMLAN 00_HMLAN.pm]
|ModOwner={{Link2FU|251|Martin / martinp876}}
|HWManufacturer=ELV / eQ-3
}}

Der [[HM-CFG-LAN LAN Konfigurations-Adapter]] ([http://www.eq-3.de/produkt-detail-zentralen-und-gateways/items/hm-cfg-lan.html HM-CFG-LAN]), kurz HMLAN Konfigurator, ist ein [[Interface|Schnittstellengerät]] (IO) ohne wesentliche Intelligenz. Die Aufgabe ist, ein Interface von der Zentrale zu den Geräten bereitzustellen. Ein HMLAN Konfigurator selbst steuert keine Geräte, er überträgt nur Nachrichten in beide Richtungen.

== Alternativen ==
Alternativen zu einem HMLAN Konfigurator sind [[HM-CFG-USB USB Konfigurations-Adapter]], [[CUN]], [[CUNO]] und [[CUL]].

;HMUSB
:Ein HMUSB hat nahezu identische Eigenschaften wie ein HMLAN Konfigurator. Der wesentliche Unterschied ist die Anbindung über USB anstatt Ethernet. Es hat sich erwiesen, dass USB eine bessere Latenz hat als LAN - also eine kürzere Verzögerung. Damit hat ein HMUSB leichte Vorteile zu HMLAN Konfigurator, was aber in den bei Weitem meisten Fällen durch die interne Timing Kalkulation abgefangen wird. Zudem können über den HMUSB (ab Version 2) auch Firmware-Updates OTA (over-the-air, also per Funkverbindung) auf entsprechende HM-Geräte (z.B. den HM-CC-RT-DN) durchgeführt werden.
:Dafür bietet der HMLAN Konfigurator mit seinem Netzwerkanschluss Vorteile bei der Platzierung und bei der Ansteuerung (teilweise Timing-Probleme beim Anschluss von USB-Geräten an langsamere Raspberries und beim Durchschleifen von USB an fhem in einer virtuellen Maschine).

; CUL/CUN(O)
* Die Devices liefern keine eigenen Zeitstempel, wodurch eine Timingkorrektur durch FHEM nicht möglich ist. Je nach Systemgeschwindigkeit kann dies zu Problemen, Nachrichtenwiederholung und ggf. auch Nachrichtenverlust führen
* Da USB kurze Reaktionszeiten und geringe Timingschwankungen hat ist der Einsatz von [[CUL]] und [[CUNO]] mit HM möglich. Die Timingschwankungen der Ethernet-schnittstelle hingegen können in FHEM nicht ausgeglichen werden. Daher kann der Einsatz der [[CUNO]] über Ethernet '''nicht empfohlen''' werden.
* Der Übertragungsmodus ''lazyConfig'' wird nicht unterstützt

== Funktionen ==
=== AES ===
siehe [[AES Encryption]].

=== Übertragungsmodus ===
Es werden alle HM-Modi unterstützt. Diese sind Always, Burst, Wakeup und Config. Weiter gibt es lazyConfig und conditionalBurst. Siehe [[HomeMatic]] für Details.

=== KeepAlive ===
Der HMLAN Konfigurator baut eine Verbindung zur Zentrale über das LAN Interface auf. Der HMLAN Konfigurator erwartet alle 30 Sekunden eine keep-alive Nachricht von der Zentrale. Sollte diese ausbleiben, baut der HMLAN Konfigurator die LAN-Verbindung ab. Das führt zu einem Disconnect, der in State gemeldet wird. Die Verbindung wird automatisch wieder aufgebaut.
FHEM sendet den keep-alive alle 25 Sekunden, was einen 5 Sekunden Puffer einräumt. In Internals '''msgKeepAlive''' kann man sehen, wie hoch die maximale Verzögerung der Zentrale beim Senden war und wie viel Puffer (in Sekunden) noch verfügbar war.
Die Wiederholrate von 25 Sekunden des keep-alive kann mit dem Attribut '''wdTimer''' reduziert werden, was den Puffer erhöhen. Es wird jedoch dringend geraten, im Problemfall die Ursache der Verzögerung zu suchen und zu eliminieren.

=== Nachrichtenübertragung - Performance ===
* Mit Internal ''msgParseDly'' kann man ablesen, welche Verzögerung eine Nachricht vom Empfang im HMLAN Konfigurator bis zur Verarbeitung in der Zentrale hat.
* Der HMLAN Konfigurator hält sich an den Funkstandard, der einem Sender maximal 36 Sekunden Sendezeit je Stunde erlaubt. Wird dieser Wert überschritten, stellt der HMLAN Konfigurator das Senden ein. Empfangen wird weiter. Ist eine Nutzung des Zeitslots zu 90% erreicht, wird im Reading ''cond'' ''Warning-HighLoad'' gemeldet. Bei cond ''ERROR-Overload'' wird das Senden eingestellt.

=== Loggen/Mitschneiden ===
Es stehen die üblichen Funktionen des Attribute [[verbose]] zu Verfügung. Darüber hinaus gibt es die Attribute ''hmProtocolEvents'' und ''logIDs''. Siehe auch [[Homematic Nachrichten sniffen]].

== Vorbereitung ==
{{Randnotiz|RNText='''"Usersoftware"/Firmware'''
* V1.512 / 19.12.2013 / [http://files.elv.de/Assets/Produkte/8/851/85128/Downloads/hm_cfg_lan_software_v1_512.zip Download]
* V1.515 / 12.08.2014 / [http://files.elv.de/Assets/Produkte/8/851/85128/Downloads/hm_cfg_lan_software_v1_515.zip Download]
* V1.520 / 10.12.2015 / [http://www.eq-3.de/Downloads/Software/Konfigurationsadapter/Konfigurationsadapter_LAN/HM-CFG-LAN_Usersoftware_V1_520_eQ-3_151207.zip Download]
'''Firmware Update Tool / Firmware / Datum'''
* V1.2 / 0.965 / 11.02.2016 / [http://www.eq-3.de/Downloads/Software/Firmware%20Update%20Tool/HM-Firmware-Update-Tool_V1_2_eQ-3_160211.zip Download]

}}
[[Datei:HMLAN_CONFIG_IP_AES.png|300px|thumb|right|HomeMatic Lan-Interface Configurator]][[Datei:HMLAN_CONFIG_AES.png|300px|thumb|right|HomeMatic Konfigurator]]
Bevor man den HMLAN mit Fhem nutzen kann, müssen noch Einstellungen vorgenommen werden. Dazu braucht man Software die bei [http://www.eq-3.de/software.html HomeMatic] in der Version 1.512 (Stand 19. Dezember 2013) herunter zu laden ist und nach der Installation mit der Verknüpfung "HomeMatic-Lan-Interface konfigurieren" oder "HomeMatic-Komponenten konfigurieren" gestartet wird und unter Windows läuft. Für andere Betriebssystem (siehe Anhang im Beitrag {{Link2Forum|Topic=11506|Message=67417|LinkText=Anleitung für OS X}}) braucht man eine Windows-Emulation. Dem HMLAN liegen zwei Konfigurationsprogramme bei, bitte darauf achten, das richtige zu verwenden. Wenn das Konfigurationsprogramm den HMLAN-Konfigurator nicht findet, sollten alle nicht benutzten Netzwerkinterfaces vorübergehend deaktiviert werden, siehe {{Link2Forum|Topic=10933|Message=62960|LinkText=Beitrag im Fhem Forum}} und [[HM-CFG-LAN_LAN_Konfigurations-Adapter#Bekannte_Probleme|bekannte Probleme]].

=== Firmware ===
Die aktuelle Firmware Version des HMLAN Konfigurators ist 0.965 (Stand Februar 2016). Ein Update ist mit dem ''"Firmware Update Tool"'' möglich, die Firmware ist Bestandteil des Tools.

Um einen mit Fhem benutzten HM-LAN zu aktualisieren, reicht es,
# im HMLAN-Device mit <code>attr <myHMLAN> dummy 1</code> den Adapter vorübergehend zu deaktivieren,
# mit dem (Windows) Firmware Update Tool die Firmware auf den HM-LAN aufzuspielen
# nach dem Stoppen des Update Tools mit <code>deleteattr <myHMLAN> dummy</code> das Device in Fhem wieder zu aktivieren.
Version 1.2 des Firmware Update Tools läuft auch unter Windows 10.

=== IP Adresse ===
Der HMLAN Konfigurator ist ähnlich wie der CUN(O) ein Netzwerkgerät. Er beherrscht DHCP und bezieht bei einem im Netzwerk erreichbaren DHCP Servers von diesem eine IP-Adresse. Da Fhem zwecks Kommunikation die IP-Adresse wissen muss, ist es sinnvoll, dem HMLAN Konfigurator eine statische Adresse zuzuweisen.
* mit der auf der CD mitgelieferten ''"HomeMatic Lan-Interface Configurator"'' Software unter ''"Change IP Settings"'' oder
* im DHCP-Server eine feste IP-Adresse zuzuweisen (sofern dies vom gegeben DHCP Server als Konfigurationsoption unterstützt wird).

=== AES Encryptet LAN Communication ===
Wichtig ist, dass vor Verwendung die "AES Encryptet LAN Communication" abgeschaltet wird, da diese von FHEM nicht unterstützt wird. Dies ist unter ''"Change IP Settings"'' der ''"HomeMatic Lan-Interface Configurator"'' Software möglich. AES auf dem LAN ist zu unterscheiden von HMLAN auf der Funktschnittstelle. siehe [[AES Encryption]].

== Einbindung in FHEM ==
Der HMLAN-Konfigurator muss in FHEM [[Konfiguration|konfiguriert]] werden. Das erfolgt mit diesen Befehlen:
:<code>define HMLAN1 HMLAN <IP Adresse>:1000</code>
:<code>attr HMLAN1 hmId 123ABC</code>
Der Name (im obigen Beispiel ''HMLAN1'') kann frei vergeben werden. Standard IP-Port des HMLAN-Konfigurators ist 1000.

HMLAN kennt mehrere Attribute ([http://fhem.de/commandref.html#HMLAN commandref]).
Wichtig ist es, die '''hmId''' zu vergeben. Diese ist ein 3-Byte hexadezimal-Wert, somit eine 6-stellige Zeichenfolge in '''Großbuchstaben'''. 000000 und FFFFFF sind ungültig.
Wenn HM-Geräte mit der Zentrale [[Pairing (HomeMatic)|gepairt]] werden, wird ihnen diese hmId eingetragen. Wechselt man die hmId müssen '''alle''' damit gepairten Geräte neu gepairt werden.

Die Adresse wird in Grossbuchstaben eingegeben, siehe [[HMLAN_Konfigurator#Bekannte_Probleme|"Bekannte Probleme"]].

Ein '''gleichzeitiger''' Zugriff von Fhem und der HomeMatic-Software auf den HMLAN-Konfigurator ist nicht möglich, da letzterer nur eine Verbindung zulässt. Wollen Sie temporär z.B. mit der Windows-Software von HomeMatic zugreifen, ist Fhem zu deaktivieren.
Sinnvoll ist es, die hmId mit der der PC-Software gleichzusetzen. Dann kann man von beiden Zentralen alternativ zugreifen ohne pairen zu müssen.

=== Nutzung mehrere IOs ===
==== Empfangen ====
Man kann an einem FHEM mehrere IOs (HMLAN/USB, CUL/CUNO) betreiben. Generell empfangen alle IOs von allen Geräten in ihrem Empfangsbereich - unabhängig von der hmId.

==== Senden ====
An ein Gerät wird nur über das IO gesendet, das in Internals->IODev angezeigt wird. Nutzt man mehrere IOs sollte im HM Device das Attribut IODev auf das gewünschte IO setzen. Ansonsten sucht FHEM zufällig ein IO aus.

==== hmId bei mehreren IOs ====
Man kann allen IOs die gleiche HMId setzen. Das erlaubt die wahlfreie Umschaltung des Sende-IOs für das Device. Sollte man unterschiedliche hmIds wählen simuliert dies mehrere Zentralen. Das Device, an das man sendet, muss über ein IO angesprochen werden, mit einer hmId auf die das Device gepairt ist.

=== Virtueller Controller VCCU ===
Speziell wenn mehrere IOs verwendet werden sollen, empfiehlt sich die Verwendung einer [[Virtueller Controller VCCU|VCCU]], da ein redundante Nutzung mehrerer Schnittstellen dann wesentlich einfacher einzurichten ist. Das Einrichten einer VCCU lohnt sich aber schon bei der Benutzung nur eines HomeMatic I/O, also wenn man z.b. nur einen HMLAN Konfigurator einsetzen will. Zum Einen ist es wesentlich einfacher ggf. später weitere Schnittstellen dazu zu konfigurieren, zum Anderen adressiert die VCCU die auch bereits bei einer Schnittstelle auftauchende Probleme wie die "<code>Unknown code</code>" Meldungen im Log.

Die Einrichtung einer VCCU ist nicht sehr aufwändig und wird dringend empfohlen.

=== Attribute ===
* '''hmId''': Adresse, die das IO auf der Funkstrecke nutzt. Es ist ein 3-byte hexwert (6 Zeichen) in Großbuchstaben.
* '''hmkey, hmkey2..5''': bis zu 5 AES keys, die auf der Funkstrecke genutzt werden. Siehe [[AES Encryption]]
* '''hmLanQlen''' legt fest, wie viele Nachrichten parallel gesendet werden dürfen, also auf wie viele Antworten die Zentrale parallel warten darf. Ein Wert von 1 ist max defensiv, erzeugt aber eine höhere Verzögerung. Wählt man einen höheren Wert kann es zu Nachrichten-Wiederholunge kommen.
* '''hmProtocolEvents''': alle Nachrichten werden dekodiert ausgegeben. Diese Einstellung benötigt einige Performance insbesondere bei höheren Level. Man sollte es vorsichtig nutzen.
* '''logIDs''': zeichnet Rohmessages auf und bietet die genaueste Methode bei der Fehlersuche. Da Nachrichten undekodiert ausgegeben werden ist es im Wesentlichen für Spezialisten von Bedeutung. Man gibt eine Komma getrennte Liste von IDs an, die geloggt werden sollen. Mit '''all''' werden alle IDs aufgezeichnet. '''sys''' zeichnet zusätzlich Systemmessages auf. '''sys,all''' somit alles.
* '''respTime''': Antwortzeit des HMLAN auf ein keep-alive kann hier eingestellt werden. Normalerweise sollte das HMLAN in einer Sekunde der Zentrale antworten. Sollte dies nicht passieren, wird die Message wiederholt. Der Wert sollte nur in Ausnahmefällen verändert werden.

=== Readings ===
* '''Xmit-Events''': Anzahl der Ereignisse
* '''cond''': aktueller Zustand des IO.
** ok
** Warning-HighLoad: 90% der 1h sendekapazität sind erreicht
** ERROR-Overload: 100% der sendekapazität sind erreicht, '''das IO sendet nicht mehr'''
** timeout
** disconnected: die Verbindung FHEM /IO ist unterbrochen
** Overload-released: das IO ist aus ERROR-Overload zurück im Sendebetrieb
** init: Das IO wurde neu initialisiert.
* '''prot_ERROR-Overload''': Anzahl des Events, Zeitstempel des letzten Auftretens
* '''prot_Warning-HighLoad''': Anzahl des Events, Zeitstempel des letzten Auftretens
* '''prot_disconnected''': Anzahl des Events, Zeitstempel des letzten Auftretens
* '''prot_init''': Anzahl des Events, Zeitstempel des letzten Auftretens
* '''prot_ok''': Anzahl des Events, Zeitstempel des letzten Auftretens
* '''prot_timeout''': Anzahl des Events, Zeitstempel des letzten Auftretens

=== Internals ===
* '''XmitOpen''': 1 = HMLAN ist sende bereit
* '''assignedIDs''': HMIDs der HM Devices, die über dieses IO bedient werden
* '''assignedIDsCnt''': Anzahl der zugewiesenen HMIds von FHEM
* '''assignedIDsReport''': Anzahl der HMIds, die das HMLAN angibt zu bedienen. Die Zahl sollte identisch sein mit assignedIDsCnt
* '''msgKeepAlive''': dlyMax: maximale Verzögerung, die ein keep-alive hatte. bufferMin: der minimale Zeitpuffer, der übrig blieb, bis das keep-alive zu spät gekommen wäre. Der Puffer sollte 2 oder größer sein, sonst könnte man gelegentlich disconnects bekommen.
* '''msgLoadEst''': Funkbelastung des HMLAN. Der Wert wird über 1 Stunde akkumuliert. Sollten 100% erreicht sein, wird das HMLAN den Sendebetrieb einstellen. Der Wert ist eine Hochrechnung in FHEM. Es ist möglich, dass das HMLAN mehr belastet ist. Die 10 min werte zeigen die Belastung in den letzten 10min Perioden an.
* '''msgParseDly''': Verzögerung der Message Verarbeitung vom Empfang im IO bis zur Verarbeitung in FHEM. Eine Verzögerung kann durch Prozesse an LAN, durch FHEM Prozesse oder sonstige Prozesse/Applikationen der CPU hervorgerufen werden.

== Pairen von Geräten ==
Jedes HM Gerät muss vor Verwendung mit der HM-Zentrale [[Pairing (HomeMatic)|gepairt]] werden. Dabei wird die hmId des gewählten IOs in das Device programmiert. Ändert man die hmId des IO, mit man das Device anspricht, muss man das Device neu pairen.
Alle Geräte haben eine eigene Seriennummer, die nicht änderbar ist. Details zum Pairen auf der Seite [[HomeMatic Devices pairen]].

== Bekannte Probleme ==
=== Verbindung wird abgelehnt ===
Selten lehnt der HMLAN-Konfigurator ohne erkennbaren Grund nach monatelangem störungsfreiem Betrieb die Verbindung ab:
<pre style="width:400px;">
Opening HMLAN1 device 192.168.168.60:1000
192.168.168.60:1000 connection refused
</pre>
Der HMLAN-Konfigurator kann aber über die mitgelieferte Konfigurationssoftware problemlos erreicht werden. Der Zustand lässt sich auch durch einen Reboot des HMLAN-Konfigurators (oder Fhem) nicht beheben, wohl aber durch eine Aktualisierung der Firmware des HMLAN-Konfigurators, selbst wenn die installierte Version aktuell ist.

Wenn das Konfigurationsprogramm Probleme hat, den HM-CFG-LAN LAN Konfigurations-Adapter zu finden, sollten alle nicht benutzten Netzwerkinterfaces vorübergehend deaktiviert werden. Vereinzelt gibt es Hinweise darauf, dass es unter Windows 7 eventuell nicht reicht, die Netzwerkverbindungen im "Netzwerk- und Freigabecenter" zu deaktivieren, sondern ein Deaktivierung der Netzwerkadapter im Gerätemanager erforderlich ist.

=== Häufiger automatischer Neustart ("Reboot") ===
Der HMLAN Adapter startet ohne erkennbaren äußeren Anlass häufig neu. Das Problem ist auch im Forum unter der Überschrift {{Link2Forum|Topic=20776|LinkText=HMLAN Adapter wechselt permanent zwischen disconnected / connected}} beschrieben. Im FHEM Log erscheinen in diesem Fall folgende Meldungen:
<pre style="width:600px;">
... HMLAN_Parse: myHMLAN new condition timeout (je nach Timing, manchmal)
... HMLanHostname:1000 disconnected, waiting to reappear (myHMLAN)
... HMLAN_Parse: myHMLAN new condition disconnected
... HMLanHostname:1000 reappeared (myHMLAN)
... HMLAN_Parse: myHMLAN new condition init
... HMLAN_Parse: myHMLAN new condition ok
</pre>
Dieses Problem ist bei ELV [http://www.elv.de/topic/hm-lan-reboots.html bekannt] und soll mit der [http://www.eq-3.de/Downloads/Software/Konfigurationsadapter/Konfigurationsadapter_LAN/HM-CFG-LAN_Usersoftware_V1_520_eQ-3_151207.zip Konfigurationsadapter LAN Usersoftware V1.520 (10.12.2015)], bzw. der darin enthaltenen Firmware Version, behoben sein. Stand 05.08.2016 12:32 Auch mit der aktuellen Firmware (v0.965 - Link siehe oben) und der aktuellen Version von HMLAN (Rev 11645 vom 2016-06-11) tritt der Fehler noch auf.

== Verbesserung der Antennenleistung ==
Die Sende- und Empfangsleistung kann man verbessern. Details [[Trick_der_Woche#HM_LAN_Konfig-Adapter_Antenne_verbessern|hier]].

== Wechsel von CUL zu HMLAN ==
{{Randnotiz|RNTyp=y|RNText=Der hier beschriebene Wechsel sollte mittlerweile einfacher über die [[Virtueller Controller VCCU|VCCU]] realisierbar sein, indem erst ein weiteres IO-Device hinzugefügt und anschließend das zu ersetzende entfernt wird.}}
Sollten ein [[CUL]] als IO für Homematic-Geräte dienen und ein Wechsel auf den HMLAN Konfigurator geplant sein, kann die folgende Vorgehensweise gewählt werden:

* deaktivieren Sie das CUL in der ''fhem.cfg''.
* konfigurieren Sie den HMLAN Konfigurator '''von Hand'''
* Ändern sie das Attribut IODev aller HM-Devices vom Namen der CUL auf den Namen des HMLAN
* sollte sie das Attribut IODev nicht nutzen (nicht empfohlen) achten sie darauf, dass im fhem.cfg das IO vor allen HM-devices definiert wird. Eine automatischen Zuweisung des IO zu den Devices ist sonst nicht möglich.
** der HMLAN '''muss''' die gleiche ''hmId'' wie das bisherige CUL erhalten. Ansonsten müssen alle Geräte neu gepairt / angelernt werden.
** AES muss im HMLAN abgeschaltet werden.
* verbinden Sie den HMLAN Konfigurator mit ihrem Netzwerk und ziehen das CUL aus der USB-Buchse.
* geben Sie in der FHEM-Befehlszeile ''shutdown restart'' gefolgt von <Enter> (nicht "save") ein (evtl. reicht auch ein ''rereadcfg'').
* kontrollieren Sie im Event-Monitor und in den HM-Device-Logs von Fhem die Kommunikation.

Bitte beachten: Falls dem CUL keine explizite hmId per Attribut zugewiesen wurde, wird diese ID aus "F1<FHT-ID>" zusammengebaut. Die hmId muss auf dem HMLAN explizit gesetzt werden.

== Links ==
* [http://www.elv.de/homematic-lan-konfigurations-adapter.html Produktseite] bei ELV
* [http://www.eq-3.de/software.html Software] für den Konfigurationsadapter von der eQ-3 Site
* [[Trick_der_Woche#HM_LAN_Konfig-Adapter_Antenne_verbessern|HM LAN Konfig-Adapter Antenne verbessern]]

[[Kategorie:HomeMatic Components]]
[[Kategorie:Interfaces]]