FHEMWiki - Benutzerbeiträge [de]

Homebridge einrichten

2015-11-12T09:31:18Z

Peterchen89: /* Homebridge installieren */ siehe http://stackoverflow.com/questions/17509669/how-to-install-nodejs-package-from-github-directly

Dieses HOWTO zeigt die Installation und Erstinbetriebnahme von Homebridge.

Damit kann Siri benutzt werden, um FHEM-Devices zu steuern. So können Devices angesprochen werden, die offiziell HomeKit nicht unterstützen (die Vorgehensweise wurde auf einem Intel NUC mit Ubuntu Server 14.04 LTS und auf einem Raspberry Pi mit Raspian getestet).

Um Homebridge erfolgreich zu installieren, müssen zunächst NPM, NodeJS, Python, g++, MDNS, sowie benötigte Hilfspakete installiert werden:

Der WIKI-Eintrag bezieht sich hauptsächlich auf diese {{Link2Forum|Topic=32652|LinkText=Diskussion im FHEM-Forum}}. Ein Riesendank gilt vor allem {{Link2FU|430|Andre (justme1968)}}.

Eine Sammlung funktionsfähiger Homebridge FHEM Konfiguration können hier gefunden werden http://www.fhemwiki.de/wiki/Hombridge_User_Configs
Die Sammlung befindet sich noch im Aufbau

== NodeJS installieren ==
In der Konsole folgende Befehle eingeben:
<source lang="bash" style="width:50%;">
sudo apt-get update
sudo apt-get upgrade
sudo apt-get install build-essential libssl-dev
</source>
UPDATE: Homebridge funktioniert mit einer kleinen Einschränkung nun auch mit node 4.0.0. Laut
[https://github.com/cflurin/homebridge-shims/wiki/Minimalist-Homebridge-on-a-Raspberry-Pi Homebridge on a Raspberry Pi] müssen die folgenden Abhängigkeiten (Dependencies) aus der '''package.json''' entfernt werden:
<pre>
"harmonyhubjs-client": "^1.1.4",
"harmonyhubjs-discover": "git+https://github.com/swissmanu/harmonyhubjs-discover.git"
</pre>

Damit es auf einem Raspberry schneller läuft wird darüber hinaus empfohlen auch diese Abhängigkeiten aus der '''package.json''' zu entfernen:

Vorher noch ein ein Backup der Datei anlegen
<pre>cp package.json package.json.bkp oder sudo cp package.json package.json.bkp </pre>
Am einfachsten geht das entfernen der Zeilen mit dem Editor vi.

<pre>vi package.json oder sudo vi package.json</pre>
Mit dem Cursor vor die entsprechende Zeile gehen und mit zwei mal Taste d (dd tippen) wird die Zeile gelöscht.

Eventuell muss vi mit sudo vi aufgerufen werden, je nach verwendeter Distribution.

Gespeichert wird dann mit folgendem Ablauf: ESC :wq! Enter
<pre>
"ad2usb": "git+https://github.com/alistairg/node-ad2usb.git#local",
"carwingsjs": "0.0.x",
"chokidar": "^1.0.5",
"eibd": "^0.3.1",
"elkington": "kevinohara80/elkington",
"harmonyhubjs-client": "^1.1.4",
"harmonyhubjs-discover": "git+https://github.com/swissmanu/harmonyhubjs-discover.git",
"lifx-api": "^1.0.1",
"lifx": "git+https://github.com/magicmonkey/lifxjs.git",
"node-hue-api": "^1.0.5",
"node-icontrol": "^0.1.4",
"node-milight-promise": "0.0.x",
"tough-cookie": "^2.0.0",
"sonos": "0.8.x",
"telldus-live": "0.2.x",
"teslams": "1.0.1",
"unofficial-nest-api": "git+https://github.com/hachidorii/unofficial_nodejs_nest.git#d8d48edc952b049ff6320ef99afa7b2f04cdee98",
"wemo": "0.2.x",
"wink-js": "0.0.5",
"komponist" : "0.1.0",
"yamaha-nodejs": "0.4.x",
</pre>

Das Konfig file sollte dann wie folgt aussehen: Achtung vor den letzten zwei } am Ende dar kein Komma sein.
<source lang="javascript">
{
"name": "homebridge",
"description": "HomeKit support for the impatient",
"version": "0.1.1",
"scripts": {
"start": "DEBUG=* node app.js || true"
},
"repository": {
"type": "git",
"url": "git://github.com/nfarina/homebridge.git"
},
"license": "ISC",
"dependencies": {
"async": "^1.4.2",
"color": "0.10.x",
"debug": "^2.2.0",
"hap-nodejs": "^0.0.2",
"isy-js": "",
"mdns": "^2.2.4",
"netatmo": "1.3.0",
"node-cache": "3.0.0",
"node-persist": "0.0.x",
"node-xmpp-client": "1.0.0-alpha23",
"q": "1.4.x",
"queue": "^3.1.0",
"request": "2.49.x",
"xml2js": "0.4.x",
"xmldoc": "0.1.x"
}
}
</source>

== Python, g++, MDNS installieren ==
<source lang="bash" style="width:50%;">
sudo apt-get install python
sudo apt-get install g++
sudo apt-get install libavahi-compat-libdnssd-dev
</source>

== Homebridge installieren ==
Die aktuelle Homebridge version wird mit
<source lang="bash" style="width:50%;">
npm install -g homebridge
</source>
installiert, der FHEM platform shim mit
<source lang="bash" style="width:60%;">
npm install -g git+https://github.com/justme-1968/homebridge-fhem.git
</source>

== ERR während der Installation ==
Bei folgendem Fehler ist das abrufen von Github nicht möglich.
<pre>npm ERR! git clone --template=/home/hs-server-admin/.npm/_git-remotes/_templates --mirror
git://github.com/KhaosT/ed25519.git /home/hs-server-admin/.npm/_git-remotes/git-github-com-KhaosT-ed25519-git-d8bdee1d:
github.com[0: 192.30.252.128]: errno=Die Wartezeit für die Verbindung ist abgelaufen</pre>
Fehlerursache konnte hier durch eine aktive Firewall verursacht werden.

== Homebridge konfigurieren ==
Im Verzeichnis ~/.homebridge/ muss nun noch die config.json erstellt bzw. angepasst werden:
<source lang="bash" style="width:50%;">
nano config.json
</source>

Homebridge muss nicht, kann aber auf dem selben Server laufen wie FHEM.

Unter "server" muss die IP des FHEM-Servers und unter "port" der benutzte Port des benutzten FHEMWEBS eingetragen werden.

Läuft der Homebridge Server auf dem gleichen Rechner wie FHEM, kann die IP 127.0.0.1 benutzt werden.

WICHTIG: Damit nicht alle Devices von Homebridge berücksichtig werden, bietet es sich an, die Devices zu filtern.

In diesem Beispiel wurden alle Devices, die über Siri steuerbar sein sollen zusätzlich in den ROOM Homekit per FHEM eingerichtet.

Der PIN kann beliebig in dem Format xxx-xx-xxx angepasst werden. Dieser muss nur einmal bei der Einrichtung in iOS eingegeben werden.

<source lang="javascript" style="width:50%;">
{
"bridge": {
"name": "Homebridge",
"username": "CC:22:3D:E3:CE:30",
"port": 51826,
"pin": "031-45-154"
},

"platforms": [
{
"platform": "FHEM",
"name": "FHEM",
"server": "192.168.xxx.xxx",
"port": "8083",
"filter": "room=Homekit",
"auth": {"user": "FhemUser", "pass": "XXX"}
}
],

"accessories": []
}
</source>

Achtung: Für ein FHEM Web Interface mit SSL Zertifikat muss die config wo folgt aussehen:
<source lang="javascript" style="width:50%;">
{
"bridge": {
"name": "Homebridge",
"username": "CC:22:3D:E3:CE:30",
"port": 51826,
"pin": "031-45-154"
},

"platforms": [
{
"platform": "FHEM",
"name": "FHEM",
"server": "192.168.xxx.xxx",
"port": "8083",
"filter": "room=Homekit",
"ssl": "true",
"auth": {"user": "FhemUser", "pass": "XXX"}
}
],

"accessories": []
}
</source>

== FHEM konfigurieren ==
Um die Device richtig mit FHEM und Homebridge vertraut zu machen, müssen wir noch unter global etwas ergänzen:
<source lang="perl" style="width:50%;">
attr global userattr genericDeviceType:ignore,switch,outlet,light,blind,speaker,thermostat,ignore,lock,window,contact
</source>

Einfach folgende Zeilen an die bestehenden Attribute anhängen:
<source lang="perl" style="width:50%;">
genericDeviceType:ignore,switch,outlet,light,blind,speaker,thermostat,ignore,lock,window,contact
</source>

Diese Einstellungen können auch bei den Einzelnen Devices gemacht werden.
Beispiel bei einem HM-CC-RT-DN, hier wird der subType thermostat gesetzt.
Einfach in das Device gehen hier das Attr subtype erstellen und thermostat auswählen.

== Homebridge starten ==
<source lang="bash" style="width:50%;">
homebridge
</source>

Hombridge sollte nun laufen.
Hier kann man die Kommunikation nachverfolgen.
Abbrechen kann das ganze mit ctrl +c.
Es sind keine Befehle mehr mit Siri möglich.

Damit Siri auch Befehle ohne ständig offenes Terminal bearbeiten kann, bitten nächsten Punkt beachten.

== Homebridge automatisch starten ==
Eine Anleitung um die Homebridge automatisch zu starten findet sich

* hier: [https://github.com/nfarina/homebridge/wiki/Running-HomeBridge-on-a-Raspberry-Pi] oder
* [http://www.meintechblog.de/2015/10/mit-siri-und-fhem-das-gesamte-smart-home-per-stimme-steuern/]

'''''Beide Links sind obsoloet da es die app.js nicht mehr gibt'''''

'''''Alternative Methode'''''

<code>
sudo nano /etc/init.d/homebridge
</code>

Code einfügen und ggf. den Pfad zu ".homebridge" anpassen

<source lang=bash>
#!/bin/sh
### BEGIN INIT INFO
# Provides: homebridge
# Required-Start: $network $remote_fs $syslog
# Required-Stop: $remote_fs $syslog
# Default-Start: 2 3 4 5
# Default-Stop: 0 1 6
# Short-Description: Start daemon at boot time for homebridge
# Description: Enable service provided by daemon.
### END INIT INFO
export PATH=$PATH:/usr/local/bin
export NODE_PATH=$NODE_PATH:/usr/local/lib/node_modules
PID=`pidof homebridge`
case "$1" in
start)
if ps -p $PID > /dev/null 2>&1; then
echo "Homebridge is already running"
else
homebridge -U /home/pi/.homebridge/ > /dev/null 2>&1 &
echo "Homebridge starting"
fi
;;
stop)
if ! ps -p $PID > /dev/null 2>&1; then
echo "Homebridge is not running"
else
kill $PID
echo "Homebridge closed"
fi
;;
restart)
if ! ps -p $PID > /dev/null 2>&1; then
homebridge -U /home/pi/.homebridge/ > /dev/null 2>&1 &
echo "Homebridge starting"
else
kill $PID
echo "Homebridge closed"
homebridge -U /home/pi/.homebridge/ > /dev/null 2>&1 &
echo "Homebridge starting"
fi
;;
status)
if ps -p $PID > /dev/null 2>&1; then
echo "Homebridge is running PID $PID"
else
echo "Homebridge is not running"
fi
;;
*)
echo "Usage: /etc/init.d/homebridge {start|stop|status|restart}"
exit 1
;;
esac
exit 0
</source>

'''Autostart aktivieren''':

<code>
sudo chmod 755 /etc/init.d/homebridge

sudo update-rc.d homebridge defaults
</code>

Nun kann man mit

<code>
sudo service homebridge start
</code>

bzw.

<code>
sudo /etc/init.d/homebridge start
</code>

den Dienst starten

== FHEM Device Einstellungen ==
Damit die zu schaltenden Geräte überhaupt in der Homebridge aufgenommen werden muss man sie im Raum Homekit hinzufügen.

Um HM-CC-RT-DN Thermostate steuern zu können, muss folgendes attribute gesetzt werden
# attr Heizung Subtype thermostat
Für einen Dummy muss man folgendes machen.
# attr Dummy genericDeviceType switch
# attr Dummy setList on off

== HomeKit in iOS einrichten ==
Um FHEM über Homebridge in iOS nutzen zu können, muss HomeKit eingerichtet werden.

Es gibt verschiedene Apps. Im folgenden wird die App EVE von Elgato empfohlen, die aus dem App-Store geladen werden muss.
In der App auf:
<pre style="width:50%;">
Gerät hinzufügen
</pre>
Es sollte ein Gerät mit der Bezeichnung "Homebridge" zur Auswahl erscheinen. Zur Ersteinrichtung auf PIN manuell eingeben gehen und (falls in der config.json nicht geändert):
<pre style="width:50%;">
031-45-154
</pre>
eingeben.

Im Anschluss können die Devices nach Belieben in verschiedene Räume zugeteilt werden, sowie Szenen und Bereiche erstellt werden.

== HomeBridge Allgemein ==
Nach allen Änderungen die in FHEM gemacht werden, welche Homebridge betreffen, muss Homebridge neu gestartet werden.

Der Neustart ist abhängig davon, wie man Homebridge gestartet hat.

Bitte den entsprechenden Methoden entnehmen.

== Steuerung von MiLight Allgemein ==
Wie hier im Forum http://forum.fhem.de/index.php/topic,32652.msg351706.html#msg351706 erwähnt, ist es möglich auch MiLight gGeräte per Siri anzusprechen.
Hierzu muss die config.jason angepasst werden.

1. Es muss die Bridge hinterlegt werden. Beispiel
<source lang="javascript" style="width:50%;">
{
"platform": "MiLight",
"name": "MiLight",
"ip_address": "192.168.001.033",
"port": 8899,
"type": "rgbw",
"delay": 30,
"repeat": 3,
"zones":["Wohnzimmer Lampen","Badezimmer Lampen","Büro Lampen","Keller Lampen"]
},
</source>

2. Es muss für jedes zu Steuernde Gerät ein Dummy angelegt werden. Beispiel:

<source lang="javascript" style="width:50%;">
{
"accessory": "Http",
"name": "Kitchen Lamp",
"on_url": "https://192.168.1.22:3030/devices/23222/on",
"off_url": "https://192.168.1.22:3030/devices/23222/off",
"brightness_url": "https://192.168.1.22:3030/devices/23222/brightness/%b",
"http_method": "POST"
},
</source>

== Schalten mit Siri ==
'''HolyMoly''' aus dem FHEM-Forum hat ein paar Beispiele gegeben, wie man Siri dazu bringt Devices zu schalten:
<pre style="width:50%;">
"Schalte alle Lampen im Obergeschoss ein."
"Schalte Chloes Licht aus."
"Dimme das Licht in der Küche."
"Dimme das Licht im Esszimmer auf 50 %."
"Stelle das Licht in der Küche am hellsten ein."
"Stelle die Temperatur im Tahoe-Haus auf 22 °C ein."
"Stelle das Thermostat im Erdgeschoss auf 21 °C ein.
"Schalte den Drucker im Büro ein."
"Siri, bereite alles für eine Party vor."
"Bereite das Ambiente fürs Abendessen vor."
"Aktiviere den Nachtruhemodus."
</pre>

Mittlerweile kann Siri auch noch die Lichtfarbe von LEDs ändern.

== Unterstütze Devices ==
Das Fhem Plugin von {{Link2FU|430|Andre (justme1968)}} unterstützt folgende Geräte

switches (devices with set on and set off commands)
lights (devices with set on and set off commands)
homematc and FS20 dimmers (devices with set on, set off and set dim or set pct commands)
HUE, WifiLight, SWAP_0000002200000003 (hue, sat, bri, rgb)
homematic, max and pid20 thermostats
homematic blinds
hommatic, MAX and FHTTK contact sensors (door, window)
HM-SEC-WIN, HM-SEC-KEY
presence, ROOMMATE
SONOS (power, volume)
harmony scenes
temperaturecw and humidity sensors
CO20 air quality sensor
probably some more ...

[[Kategorie:HOWTOS]]

Hue

2015-10-04T10:34:48Z

Peterchen89: /* HUE-Device */ color-icon ist falsch, color-icons ist korrekt.

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

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

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

== HUE-Bridge ==

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

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

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

WICHTIG: danach in Fhem ein mal die Konfiguration speichern damit der Pairing-Key gesichert wird. Sonst muss bei nächsten Fhem-Neustart das Paring erneut durchgefürt werden.

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

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

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

setzen.

== HUE-Device ==
Als Gerät können alle Hue und LightLink kompatiblen Modelle verwendet werden. Dies sind zur Zeit (Anfang 2014):
*HueBulbs (alle drei Modelle)
*Friends of Hue LightStrips und LivingColors Bloom
*LivingColors ab gen2
*LivingColors Bloom und Iris
*LivingWhites Energiesparlampen
*LivingWhites Leuchtenadapter
Diese sind jeweils über eine Bridge (HueDevice) aus steuerbar. Die LivingColors und LivingWhites Geräte sind vorher mit Hilfe einer LivingColors oder LivingWhites Fernbedienung an der Bridge anzulernen.
=== Grundlagen - Farbmodelle ===
Ein HueDevice kann per set-Befehl über unterschiedliche Farbmodelle gesteuert werden. In der folgenden Tabelle ist dargestellt, welche Werte-Kombinationen sinnvoll sind:
{| class="wikitable"
|-
! Farbmodell !! Bestandteile !! Beispiel
|-
| xyY || x- und y-Koordinate im Farbraum, Y ist die Helligkeit || <code> set bulb1 xy 0.4595,0.4105 : bri 220 </code>
|-
| hue,sat,bri || Farbwert, Sättigung und Helligkeit || <code> set bulb1 hue 14922 : sat 144 : bri 220 </code>
|-
| ct || Farbwert über Farbtemperatur || <code> set bulb1 color 2600 </code>
|-
| rgb || Farbbestandteile rot, grün und blau || <code> set bulb1 rgb FFC698 </code>
|}
'''Hinweis:''' Zur Regelung der Helligkeit sind die Befehle ''bri'' und ''pct'' gleichwertig. ''bri'' hat den Bereich 0..254, ''pct'' 0..100 .<br>
Das Modul lässt die Mischung von Angaben aus unterschiedlichen Farbmodellen technisch zu, jedoch sind diese nicht immer sinnvoll.

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

== RaspBee ==
Das HUEBridge Modul unterstützt in einer beta version auch das RaspBee ZigBee Modul über die zugehörige deCONZ Software und die Wireless Light Control WebApp mit dem REST plugin. Die hierzu erhältlichen Funk-Vorschaltgeräte sind noch nicht getestet sollten aber auch funktionieren.

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

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

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

Denon AV-Receiver

2015-02-14T13:53:41Z

Peterchen89: github url gefixt

{{SEITENTITEL:DENON_AVR}}
{{Infobox Modul
|ModPurpose=Anbindung Denon und Marantz AV-Receiver
|ModType=x
|ModFTopic=11338
|ModCmdRef=DENON_AVR
|ModForumArea=Multimedia
|ModTechName=71_DENON_AVR.pm
|ModOwner={{Link2FU|5244|xusader}}
}}
== Features / Funktionen ... ==

Für AV-Receiver des Herstellers D&M Holding (Marken Denon und Marantz) gibt es ein Fhem-Modul, welches allerdings aktuell noch nicht offiziell aufgenommen wurde. Es gibt entsprechend auch noch keinen Eintrag in der CommandRef. Dieser Wiki-Eintrag enthält daher das Wichtigste zum Einstieg in die Nutzung.

== Hinweise zum Betrieb mit Fhem ==

===Voraussetzungen AVR===

Der zu steuernde AVR sollte so eingestellt sein, dass er auch im Stand-by eine Netzwerkverbindung hat (s. jeweilige Anleitung). Außerdem muss die IP des AVR bekannt sein; hierzu dem AVR entweder direkt oder über den DHCP-Server eine feste IP zuordnen.

===Installation===

Das Modul von [https://github.com/xusader/fhem-denon/raw/master/FHEM/71_DENON_AVR.pm github] laden, im Modules-Verzeichnis speichern (Rechte beachten!) und durch

<code>reload 71_DENON_AVR.pm</code>

in Fhem laden.

===Einrichten===

<code>define <gewählter_Gerätename> DENON_AVR <IP_des_Gerätes></code>

Zum Beispiel also:

<code>define Marantz DENON_AVR 192.168.1.22</code>

===Readings===

Zur Nutzung in Fhem können die folgenden Readings (Beispiel) ausgewertet werden:

<pre style="width:500px;">
2015-02-06 13:15:05 input MPLAY
2015-02-06 13:15:05 mute off
2015-02-06 13:50:10 power =2
2015-02-06 13:16:08 sound STEREO
2015-02-06 13:15:04 state opened
2015-02-06 13:16:08 volume 40
2015-02-06 13:16:08 volumeStraight -40
</pre>

<code>volumeStraight</code> entspricht dabei der Lautstärkeangabe in dB.

Das Reading <code>power</code> scheint gerätespezifisch mehr als an oder aus auszugeben. Bei einem Maratz SR7008 z.B. ist "1" aus, "2" an. Davor steht teilweise "=", teilweise "r:", bisher ohne erkennbare Systematik.

===Ein-/Ausschalten===

<code>set <gewählter_Gerätename> [on|off]</code>

===Stumm an/aus===

<code>set <gewähler_Gerätename> mute [on|off]</code>

===Quellenwahl===

<code>set <gewählter_Gerätename> input <Quelle></code>

<Quelle> hängt dabei vom jeweiligen AVR ab. Eine Übersicht über mögliche Quellen sind z.B. in der am Ende dieses Artikels verlinkten Übersicht über Command-Codes für viele Geräte abrufbar.

Zum Beispiel für die Quelle "Media Player" bei Marantz:

<code>set Marantz input MPLAY</code>

== Bekannte Probleme ==

Beim Neustart von Fhem oder beim Einschalten des Stroms für den AVR ist der Status des Moduls "disconnected". Das lässt sich nur über die Neuinstallation des Moduls oder über ein

<code>modify <gewählter_Gerätename> <IP_des_Gerätes></code>

beheben. Läuft der AVR an einer von Fhem ansteuerbaren Steckdose, lässt sich das für das Einschalten des AVR auch automatisieren, z.B.:

<code>define Poweron notify FS20Schalter:on sleep 75;;modify <gewählter_Gerätename> <IP></code>

== Links ==

* {{Link2Forum|Topic=11338}} im Fhem-Forum
* [http://www.denon.de/ Herstellerseite zur Marke Denon]
* [http://www.marantz.de/ Herstellerseite zur Marke Marantz]
* [http://www.awe-europe.com/ir_232.html Seite, auf der die Command-Codes für viele Geräte abrufbar sind]

[[Kategorie:Unterhaltungselektronik]]

Modul Alarm

2015-02-05T11:39:31Z

Peterchen89: Verweise innerhalb der Seite zu internen Verweisen gemacht

Diese Seite beschreibt die Konfiguration und Verwendung des Moduls 95_Alarm.pm.

=Allgemeines=
Das Modul ''95_Alarm.pm'' stellt eine komfortable Oberfläche bereit, um per Webinterface bestimmte auslösende Elemente (nachfolgend 'Sensoren' genannt) mit bestimmten Aktionen (nachfolgend 'Aktoren' genannt) zu verknüpfen - und zwar nur innerhalb bestimmter Zeitfenster sowie an- und abschaltbar ("scharf/armed" bzw. "unscharf/disarmed"). Diese Verknüpfungen werden als "normale" FHEM-Definitionen gespeichert.
==Erste Schritte==
Damit FHEM-Devices als Aktoren oder Sensoren für die Alarmanlage genutzt werden können, müssen zwei neue globale Attribute eingeführt werden. Dazu muss in der Grundkonfiguration von FHEM die Zeile mit der Definition der nutzerspezifischen Attribute ''userattr'' angepasst werden:
attr global userattr '''alarmDevice alarmSettings''' devStateIcon devStateStyle ...''(hier folgen weitere Attribute)''
*Soll ein FHEM-Device als Sensor für die Alarmanlage genutzt werden, wird der Wert seines ''alarmDevice''-Attributes auf 'Sensor' gesetzt.
*Soll ein FHEM-Device als Aktor für die Alarmanlage genutzt werden, wird der Wert seines ''alarmDevice''-Attributes auf 'Actor' gesetzt
*Das Attribute ''alarmSettings'' wird beim Setzen der Alarme auf der Alarmkonfigurationsseite automatisch befüllt.
Ferner muss das Modul ''95_Alarm.pm'' im Modulpfad installiert werden, ebenso die JavaScript-Datei ''alarm.js'' in www/pgm2.
==Definition==
Die Alarmanlage - hier mit dem Namen ''AAA'' versehen - selbst wird über
define AAA Alarm
attr AAA room AlarmRoom
definiert. Zusätzlich soll sie im oberen Menü des Webinterfaces auftauchen, dazu benötigen wir noch (wird normalerweise automatisch mit angelegt):
define AAA_weblink weblink htmlCode {Alarm_Html("AAA")}
attr AAA_weblink room AlarmRoom
*Der Raum ''AlarmRoom'' ist ein versteckter Raum, der nicht im unteren Menü auftaucht.
*Es wird ein weiterer Raum benötigt, der in der gegenwärtigen Fassung des Moduls den Namen ''Alarm'' trägt

==Konfiguration==
Beim Anklicken des Begriffes ''Alarm'' im oberen Menü des Webinterfaces wird die Alarmkonfiguration angezeigt.
===Settings===
Im oberen Bereich sind drei Eingabefelder zu sehen:
*Arm Delay ist eine Verzögerungszeit, die zwischen dem Scharfschalten des Alarms und der tatsächlichen Wirksamkeit vergeht. Diese Zeit kann beispielsweise genutzt werden, um das Haus ohne Auslösung des Alarms zu verlassen.
*Arm Action ist ein FHEM-Befehl, der beim Scharfschalten ausgeführt wird. Im Beispielbild wird damit ein MP3-Funkgong ausgelöst, durch den eine Stimme sagen lässt ''Alarmanlage scharf geschaltet''.
*Disarm Action ist ein FHEM-Befehl, der beim Unscharfschalten ausgeführt wird. Im Beispielbild wird damit ein MP3-Funkgong ausgelöst, durch den eine Stimme sagen lässt ''Alarmanlage unscharf geschaltet''.
*Cancel Action ist ein FHEM-Befehl, der beim Widerrufen eines Alarms ausgeführt wird. Im Beispielbild wird damit ein MP3-Funkgong ausgelöst, durch den eine Stimme sagen lässt ''Alarm widerrufen''.
Als Default sind 8 Alarmlevel möglich, in der Tabelle 'Settings' können für jeden Level gesetzt werden:
*Startzeit und Endzeit des Alarmlevels
*Eine Nachricht zur Erläuterung des Alarms (Teil 2)
*Checkbox ''Armed'' = scharf
*Button ''Cancel'' zum Canceln = Aufheben des Alarms

[[Datei:alarm_settings.png]]

===Sensors===
Danach wird die Tabelle der Sensoren angezeigt. Für jeden Sensor kann gesetzt werden:
*Alarmlevel, die hierdurch ausgelöst werden
*Ein regulärer Ausdruck, bei dessen Erkennung die Auslösung erfolgt
*Eine Nachricht zur Erläuterung des Alarms (Teil 1)
*Ein Selektor, um festzulegen, ob dieser Sensor den Alarm
**auslöst (=Raise),
**widerruft (=Cancel),
**scharf schaltet (=Arm) oder
**unscharf schaltet (=Disarm).
'''Achtung: Es ist zwingend notwendig, dass für einen auszulösenden Alarmlevel auch ein Sensor für den Widerruf (=Cancel) des Alarms definiert wird, ansonsten ignoriert das Modul die Definition dieses Levels.'''

Die insgesamt in den ''STATE'' der Alarmanlage geschriebene Nachricht besteht dann aus
(Anzeige der Zustände) (Nachricht Teil 1)' '(Nachricht Teil 2).
Bitte weiter unten nachlesen, was mit der [[#Anzeige der Zustände|Anzeige der Zustände]] gemeint ist.
In diesen Nachrichten werden die folgenden Ersetzungen vorgenommen
* $NAME vird durch den Namen des auslösenden Devices ersetzt
* $EVENT wird durch den kompletten Event ersetzt
* $EVTPART1... wird durch den 1. Teilstring des Events gefüllt, etc.

[[Datei:alarm_sensors.png]]

===Actors===
Anschließend wird die Tabelle der Aktoren angezeigt. Für jeden Aktor kann gesetzt werden:
*Alarmlevel, die diesen Aktor starten
*Ein FHEM-Kommando zum Starten des Aktors
*Ein FHEM-Kommando zum Stoppen des Aktors
*Eine Zeitverzögerung - entweder als Angabe von Sekunden (<60) oder im Format mm:ss

[[Datei:alarm_actors.png]]

==Einrichten==
Durch Anklicken des Buttons ''Set Alarms'' werden die ''alarmSettings''-Attribute befüllt.
'''Achtung, Folgendes beachten'''
*Es ist zwingend notwendig, dass für einen auszulösenden Alarmlevel auch ein Sensor für den Widerruf (=Cancel) des Alarms definiert wird, ansonsten ignoriert das Modul die Definition dieses Levels.
*Der Button ''Set Alarms'' wird nur funktionieren, wenn keine [[#Sperrung|Sperrung]] vorliegt, siehe unten.
*Es empfiehlt sich, danach ein ''Save Config'' auszuführen, damit die Attribute und Notifier permanent sind.

===Anzeige der Zustände===
Auf Wunsch können die Zustände der Alarmanlage zusammen mit der konkreten Meldung im internal ''STATE'' (bzw. reading ''state'', beide sind in diesem Modul identisch) angezeigt werden.
Hierfür gibt es ein Attribut ''statedisplay'' mit den folgenden möglichen Werten, die nachfolgend am Beispiel für den Zustand "Alarm Level 1 ausgelöst" erläutert sind:
* ''none'' - keine Anzeige
* ''simple'' - OXOOOOOO
* ''color'' - <span style="color:green"> 0 <span style="width:1ex;color:red">1</span> 2 3 4 5 6 7</span>
* ''table'' - <table><tr style="height:1ex"><td style="width:1ex;background-color:green"/><td style="width:1ex;background-color:red"/><td style="width:1ex;background-color:green"/><td style="width:1ex;background-color:green"/><td style="width:1ex;background-color:green"/><td style="width:1ex;background-color:green"/><td style="width:1ex;background-color:green"/><td style="width:1ex;background-color:green"/></tr></table>

Das Problem ist, dass möglicherweise das internal ''STATE'' an anderer Stelle verwendet werden soll - z.B. beim Versenden von Mails als
Value('AAA')
Es macht natürlich keinen Sinn, eine HTML-Tabelle in eine Mail zu packen. Deshalb sollte für die Weiterverarbeitung statt des obigen Code verwendet werden
$defs{'AAA'}{READINGS}{"short"}{VAL}
Dies enthält nur die Meldung, nicht aber die Anzeige aller Zustände. Alternativ kann man auch die Zustandsanzeige durch Wahl des Attributwertes ''none'' komplett abstellen.
===Sperrung===
Das Attribut ''lockstate'' muss den Wert ''unlocked'' haben, damit durch Anklicken des Buttons ''Set Alarms'' die ''alarmSettings''-Attribute befüllt werden können. Das ist in der Regel beim ersten Laden des Moduls '''nicht''' der Fall, hierzu muss also das Attribut von Hand auf den richtigen Wert gesetzt werden !

=Sensoren=
==Rauchalarm==
'''Dieser Alarm ist mit Lebensgefahr verbunden und wird deshalb unabhängig von FHEM ausgelöst, und von FHEM nur registriert und mit weiteren Aktoren verbunden'''.

Im Beispiel werden vernetzte Rauchmelder des Typs [[HM-SEC-SD_Rauchmelder|HM-SEC-SD]] verwendet. Deren Teamleader erhalten das Attribut ''alarmDevice Sensor'', so dass sie in der Sensorenliste der Alarmanlage auftauchen. Sie lösen den Alarm mit dem höchsten Level aus. Die Realisierung lässt sich aber auch über beliebige andere in FHEM eingebundene Rauchmelder erreichen.

[[Datei:alarm_smoke.png]]

==Öffnung von Fenstern oder Türen ==
Dies dient der Überwachung von '''Zustandsänderungen''', ebenso wie zur '''Überprüfung eines statischen Zustands'''
===Szenarien===
====Kontrollrunde====
Dieses Alarmszenario (Alarmlevel 4) liegt vor, wenn die Hausbewohner anwesend sind, aber irgendwann zu Bett gehen wollen und vorher noch überprüfen, ob auch alle Türen und das Garagentor geschlossen sind. Sagen wir, beginnend um 22:00 bis 23:59. Man könnte diesen Alarmlevel aber auch durch einen externen Regensensor auslösen, der die Dachfenster auf ihren Öffnungszustand untersucht. Jedenfalls sollte dieser Alarmlevel immer scharf sein.

Durch einen externen Auslöser (sagen wir, beginnend um 22:00 Uhr) wird in periodischen Abständen eine Hilfsroutine gestartet, welche die Zustandsprüfung vornimmt und registriert. Nur wenn diese Registrierung eine Öffnung ergibt, wird der Alarm ausgelöst. Dieser Alarmlevel gehört also zur Kategorie ''Warnung'' und wird deshalb nur eine moderate Signalisierung benötigen - beispielsweise
*eine Nachricht mit gelbem Hintergrund erscheint auf einem [[Digitaler_Bilderrahmen_mit_lcd4linux|Digitalen Bilderrahmen]]
*eine Nachricht erscheint auf einem [[1-Wire_Textdisplay]]
*eine LED geht an auf dem [[1-Wire LED-Statusmonitor]]

====Zutritt====
Dieses Alarmszenario (Alarmlevel 5) liegt vor, wenn die Hausbewohner anwesend sind, aber vermutlich schlafen gegangen sind. Sagen wir, von 0:00 bis 5:00.

Wenn morgens um 4:00 die Haustür geöffnet wird, handelt es sich entweder um ein spätes Heimkommen eines Hausbewohners von einer Party - oder um einen Einbruchsversuch. Der Partygeher sollte also eine gewisse Warnungszeit bekommen, bevor ein moderater akustischer Aktor (sagen wir, ein Funkgong) losgeht. Dieser Aktor muss deshalb mit einer Verzögerung eingeschaltet werden, und der Partygeher erhält eine Warnung. Diese Warnung - sagen wir, eine bestimmte Lampe geht an - informiert ihn, dass er innerhalb von 30 Sekunden einen bestimmten Schalter betätigen muss. Etwa den für genau diese Lampe, um sie auszuschalten. Der Einbrecher kennt diesen Schalter nicht, der moderate Alarm wird also die schlafenden Hausbewohner wecken und ihn abschrecken.

Zusätzlich verfügt dieser Level auch noch über einen Partymodus: Mit diesem kann er für 24 Stunden abgestellt werden, so dass man auch um 3:00 in der Frühe die eigenen Partygäste aus dem Haus lassen kann, ohne ihn auszulösen.
====Einbruch====
Dieses Alarmszenario (Alarmlevel 6) liegt vor, wenn die Hausbewohner abwesend sind und diesen Level vorher scharf geschaltet haben - und idealerweise von 0:00 bis 23:59. Jeder Zutritt zu Haus löst diesen Alarm aus, und der akustische Aktor kann durchaus kräftig sein (etwa Einschalten der Rauchmelder für 1 Minute).

Da die Auslösung auch erfolgt, wenn der Hausbesitzer heimkommt, muss der akustische Aktor eine Verzögerung haben und innerhalb dieser einer Warnung gegeben werden, z.B. indem zunächst eine bestimmte Lampe angeht. Dies informiert ihn, dass er innerhalb von 30 Sekunden einen bestimmten Schalter betätigen muss. Etwa die Kombination, um diesen Alarmlevel unscharf zu schalten. Der Einbrecher kennt diese Kombination nicht, die Beleuchtung wird ihn also zunächst abschrecken und der nachfolgende laute akustische Aktor auch die Nachbarn wecken.
===Zustandsänderung===
Dazu werden alle überwachten Fenster- und Türkontakte mit dem Attribut ''alarmDevice Sensor'' versehen, so dass sie in der Sensorenliste der Alarmanlage auftauchen. In der Alarmkonfiguration sieht das dann so aus:

[[Datei:alarm_tf.png]]

===Zustandsprüfung===
Dies dient der Überprüfung eines '''statischen Zustands''', konkret ob und welche Fenster oder Türen offen sind - z.B. abends, oder bei Regenwetter. Dazu benötigen wir drei ''dummy'' Devices, von denen zwei als ''alarmDevice Sensor'' und einer als ''alarmDevice Actor'' attributiert werden und somit in der Sensoren- bzw. Aktorenliste der Alarmanlage auftauchen.

define TFOpen.warn dummy
attr TFOpen.warn alarmDevice Sensor
'''attr TFOpen.warn alarm4,|TFOpen.warn:.*[TF].*|$EVENT|on''' (Diese Zeile wird vom Modul 95_Alarm.pm automatisch erzeugt)
attr TFOpen.warn group windowDetector
attr TFOpen.warn room Alarm

define TFClose.warn dummy
attr TFClose.warn alarmDevice Sensor
'''attr TFClose.warn alarmSettings alarm4,|TFClose.warn:yes|Alle zu|off''' (Diese Zeile wird vom Modul 95_Alarm.pm automatisch erzeugt)
attr TFClose.warn group windowDetector
attr TFClose.warn room Alarm

define TFOpen.check dummy
attr TFOpen.check alarmDevice Actor
'''attr TFOpen.check alarmSettings alarm4,|{HouseOpen()}||10:00''' (Diese Zeile wird vom Modul 95_Alarm.pm automatisch erzeugt)
attr TFOpen.check group windowDetector
attr TFOpen.check room Alarm

[[Datei:TFAlarm.png|left|thumb|200px|]]Als nächstes muss eine Überwachungsroutine geschrieben werden. Das kann entweder als FHEM-Skript geschehen, oder in der Datei 99_myUtils.pm als perl-Code. Dieses Unterprogramm muss
*den obigen ''dummy'' TFOpen.warn setzen, und zwar auf den oder die Namen der geöffneten Fenster und Türen oder "none", wenn keine geöffnet sind.
*den obigen ''dummy'' TFClose.warn setzen, und zwar auf den Wert "no", wenn irgendeine geöffnet ist und "yes", wenn keine geöffnet sind.
Ein Beispiel für eine solche Überwachungsroutine ist weiter unten zu sehen.

Diese Doppelung ist nötig, weil jeder Sensor nur mit einem notify in den Alarmen auftauchen kann - das dient der Sicherheit gegen Fehlkonfiguration und ist beabsichtigt.

In dem nebenstehenden Flussdiagramm wird der Ablauf dargestellt, der sich mit diesem System ergibt. Dabei wird um 22:00 der erste Test auf ein ordnungsgemäß geschlossenes Haus gestartet - und bis Mitternacht alle 10 Minuten wiederholt. Alternativ könnte man das auch mit einem Regensensor als Erstauslöser koppeln.

Beispielcode für eine Überwachungsroutine:

sub HouseOpen()
{
my $kfo = 0;
my $kfs = "";
my $kto = 0;
my $kts = "";
my $str = "";
if( $main::value{'BK.F'} ne "Closed" ){
$kfo++;
$kfs = "BK/";
}
if( $main::value{'WK.F'} ne 'Closed' ){
$kfo++;
$kfs = $kfs."WK/";
}
if( $main::value{'VK.T'} ne "Closed" ){
$kto++;
$kts = "VK/";
}
if( $main::value{'WZ.T'} ne 'Closed' ){
$kto++;
$kts = $kts."WZ/";
}
if( ($kfo >= 1) && ($kto == 0) ){
$kfs = substr($kfs,0,-1);
fhem("define TFOpen.delay at +00:00:30 set TFOpen.warn $kfs Fenster");
fhem("define TFClose.delay at +00:00:30 set TFClose.warn no");
}elsif( ($kfo == 0) && ($kto >= 1) ){
$kts = substr($kts,0,-1);
fhem("define TFOpen.delay at +00:00:30 set TFOpen.warn $kts Tür");
fhem("define TFClose.delay at +00:00:30 set TFClose.warn no");
}elsif( ($kfo >= 1) && ($kto >= 1)){
$kts = substr($kts,0,-1);
$kfs = substr($kfs,0,-1);
$str = "$kts Tür + $kfs Fenster";
fhem("define TFOpen.delay at +00:00:30 set TFOpen.warn $kts T / $kfs F");
fhem("define TFClose.delay at +00:00:30 set TFClose.warn no");
}else{
fhem("set TFOpen.warn none");
fhem("set TFClose.warn yes");
}
return $str;
}

==Batterie schwach bei FHEM-Devices==
Dieser Sensor besteht aus einem ''notify'' und einem ''dummy'', der bei einer 'battery low'-Meldung eines beliebigen FHEM-Device auf dessen Namen gesetzt wird. Der ''dummy'' wird als ''alarmDevice Sensor'' attributiert, so dass er in der Sensorenliste der Alarmanlage auftaucht.

define LBatt.N notify .*:[Bb]attery.*[Ll]ow.* set LBatt.warn $NAME
attr LBatt.N room Alarm
attr LBatt.N group deviceDetector

define LBatt.warn dummy
attr LBatt.warn alarmDevice Sensor
attr LBatt.warn room Alarm
attr LBatt.warn group deviceDetector
Auf einen Test, ob gleichzeitig bei anderen FHEM-Devices die Batterie ebenfalls schwach ist, wird hier verzichtet. Für diesen Sensor wird ein eigener Alarmlevel (niedriger Priorität) erzeugt. Bei einem beliebigen 'battery low' Event wird somit der STATE der Alarmanlage gesetzt auf '''Batt. <devicename> schwach'''. Dieser Alarm muss manuell zurückgesetzt werden (schließlich sollten die Batterien ja erst gewechselt werden...)

[[Datei:alarm_lbatt.png]]

=Aktoren=
==Rauchmelder als Alarmsignal==
Für Alarme, bei denen es wirklich auf schnelle Reaktionen ankommt, kann man auch Rauchdetektoren verwenden, die über Funk aktivierbar sind. Im Beispiel werden vernetzte Rauchmelder des Typs [[HM-SEC-SD_Rauchmelder|HM-SEC-SD]] verwendet.

'''Achtung: Es ist sehr empfehlenswert, diesen Alarm auch wieder automatisch auszuschalten.'''

Dazu wird ein ''dummy'' erzeugt und mit ''alarmDevice Actor'' attributiert, so dass er in der Aktorenliste auftaucht:

define SD.alarm dummy
attr SD.alarm alarmDevice Actor
attr SD.alarm alarmSettings alarm7,|set TH.SD0 alarmOn|set TH.SD0 alarmOff|30
attr SD.alarm group alarmActor
attr SD.alarm room Alarm
In der Alarmkonfiguration sieht das dann so aus:

[[Datei:alarm_smokeactor.png]]

==Funk-Türgong / MP3-Türgong als Alarmsignal==
Hier wird ein FS20-Türgong als akustisches Alarmsignal verwendet.

define WZ.Gong FS20 <adresse>
attr WZ.Gong IODev CUL
attr WZ.Gong alarmDevice Actor
'''attr WZ.Gong alarmSettings alarm5,alarm6,|set WZ.Gong on||30''' (Vom Modul 95_Alarm.pm automatisch erzeugt)
attr WZ.Gong group alarmActor
attr WZ.Gong room Alarm,Erdgeschoss
In der Alarmkonfiguration sieht das dann so aus:

[[Datei:alarm_gongactor.png]]

Bei Verwendung eines MP3-Funkgongs (z.B. aus dem Homematic-Programm) kann man auf diesem eine ganze Menge verschiedene MP3-Dateien speichern, die z.B. Stimmenmeldungen "Alarmanlage scharf geschaltet" abgeben. Zur Erstellung dieser Meldungen hat es sich bewährt, einen kostenlosen Online-TTS (Text-to-Speech) Service zu nutzen, z.B. Ivona.
==Alarmierung per SMS==
Für Alarme, die man auch im Urlaub auf das Handy bekommen möchte, bedarf es natürlich eines Providers, der eine bestimmte Mailadresse als SMS weiterleitet. Ferner einer FHEM-Konfiguration, die Mails versenden kann. Dann wird ein ''dummy'' erzeugt und mit ''alarmDevice Actor'' attributiert, so dass er in der Aktorenliste auftaucht:
define Mail.alarm dummy
attr Mail.alarm alarmDevice Actor
'''attr Mail.alarm alarmSettings alarm6,alarm7,|{DebianMail(<mailadresse>,'Alarm',Value('AAA'))}||30''' (automatisch erzeugt)
attr Mail.alarm group alarmActor
attr Mail.alarm room Alarm
In der Alarmkonfiguration sieht das dann so aus:

[[Datei:alarm_mailactor.png]]

[[Kategorie:Examples]]

Diskussion:Modul Alarm

2015-02-05T11:33:01Z

Peterchen89: Neuer Abschnitt /* Message Part 1 bei Sensoren nötig? */

== Message Part 1 bei Sensoren nötig? ==

Im Screenshot sind Sensoren mit leerem Message Part 1 Feld abgebildet. In der Konstellation habe ich bei mir im Log den Fehler "[Alarm 6] not raised, alarmSensor ... has wrong settings" bekommen. Nach kurzem durchschauen des Codes habe ich dann noch eine Message ergänzt und konnte das Problem so lösen.

Wenn der Entwickler dem zu zustimmt würde ich gerne die Beschreibung im Text auf "muss" statt "kann" für das Namensfeld ändern und den Screenshot aktualisieren sodass bei allen Sensoren eine Message hinterlegt ist. Ich denke das würde es an der Stelle klarer machen. Einwände? --[[Benutzer:Peterchen89|Peterchen89]] ([[Benutzer Diskussion:Peterchen89|Diskussion]]) 11:33, 5. Feb. 2015 (UTC)

Modul Alarm

2015-02-05T11:26:52Z

Peterchen89: /* Definition */ weblink wird automatisch mit angelegt

Diese Seite beschreibt die Konfiguration und Verwendung des Moduls 95_Alarm.pm.

=Allgemeines=
Das Modul ''95_Alarm.pm'' stellt eine komfortable Oberfläche bereit, um per Webinterface bestimmte auslösende Elemente (nachfolgend 'Sensoren' genannt) mit bestimmten Aktionen (nachfolgend 'Aktoren' genannt) zu verknüpfen - und zwar nur innerhalb bestimmter Zeitfenster sowie an- und abschaltbar ("scharf/armed" bzw. "unscharf/disarmed"). Diese Verknüpfungen werden als "normale" FHEM-Definitionen gespeichert.
==Erste Schritte==
Damit FHEM-Devices als Aktoren oder Sensoren für die Alarmanlage genutzt werden können, müssen zwei neue globale Attribute eingeführt werden. Dazu muss in der Grundkonfiguration von FHEM die Zeile mit der Definition der nutzerspezifischen Attribute ''userattr'' angepasst werden:
attr global userattr '''alarmDevice alarmSettings''' devStateIcon devStateStyle ...''(hier folgen weitere Attribute)''
*Soll ein FHEM-Device als Sensor für die Alarmanlage genutzt werden, wird der Wert seines ''alarmDevice''-Attributes auf 'Sensor' gesetzt.
*Soll ein FHEM-Device als Aktor für die Alarmanlage genutzt werden, wird der Wert seines ''alarmDevice''-Attributes auf 'Actor' gesetzt
*Das Attribute ''alarmSettings'' wird beim Setzen der Alarme auf der Alarmkonfigurationsseite automatisch befüllt.
Ferner muss das Modul ''95_Alarm.pm'' im Modulpfad installiert werden, ebenso die JavaScript-Datei ''alarm.js'' in www/pgm2.
==Definition==
Die Alarmanlage - hier mit dem Namen ''AAA'' versehen - selbst wird über
define AAA Alarm
attr AAA room AlarmRoom
definiert. Zusätzlich soll sie im oberen Menü des Webinterfaces auftauchen, dazu benötigen wir noch (wird normalerweise automatisch mit angelegt):
define AAA_weblink weblink htmlCode {Alarm_Html("AAA")}
attr AAA_weblink room AlarmRoom
*Der Raum ''AlarmRoom'' ist ein versteckter Raum, der nicht im unteren Menü auftaucht.
*Es wird ein weiterer Raum benötigt, der in der gegenwärtigen Fassung des Moduls den Namen ''Alarm'' trägt

==Konfiguration==
Beim Anklicken des Begriffes ''Alarm'' im oberen Menü des Webinterfaces wird die Alarmkonfiguration angezeigt.
===Settings===
Im oberen Bereich sind drei Eingabefelder zu sehen:
*Arm Delay ist eine Verzögerungszeit, die zwischen dem Scharfschalten des Alarms und der tatsächlichen Wirksamkeit vergeht. Diese Zeit kann beispielsweise genutzt werden, um das Haus ohne Auslösung des Alarms zu verlassen.
*Arm Action ist ein FHEM-Befehl, der beim Scharfschalten ausgeführt wird. Im Beispielbild wird damit ein MP3-Funkgong ausgelöst, durch den eine Stimme sagen lässt ''Alarmanlage scharf geschaltet''.
*Disarm Action ist ein FHEM-Befehl, der beim Unscharfschalten ausgeführt wird. Im Beispielbild wird damit ein MP3-Funkgong ausgelöst, durch den eine Stimme sagen lässt ''Alarmanlage unscharf geschaltet''.
*Cancel Action ist ein FHEM-Befehl, der beim Widerrufen eines Alarms ausgeführt wird. Im Beispielbild wird damit ein MP3-Funkgong ausgelöst, durch den eine Stimme sagen lässt ''Alarm widerrufen''.
Als Default sind 8 Alarmlevel möglich, in der Tabelle 'Settings' können für jeden Level gesetzt werden:
*Startzeit und Endzeit des Alarmlevels
*Eine Nachricht zur Erläuterung des Alarms (Teil 2)
*Checkbox ''Armed'' = scharf
*Button ''Cancel'' zum Canceln = Aufheben des Alarms

[[Datei:alarm_settings.png]]

===Sensors===
Danach wird die Tabelle der Sensoren angezeigt. Für jeden Sensor kann gesetzt werden:
*Alarmlevel, die hierdurch ausgelöst werden
*Ein regulärer Ausdruck, bei dessen Erkennung die Auslösung erfolgt
*Eine Nachricht zur Erläuterung des Alarms (Teil 1)
*Ein Selektor, um festzulegen, ob dieser Sensor den Alarm
**auslöst (=Raise),
**widerruft (=Cancel),
**scharf schaltet (=Arm) oder
**unscharf schaltet (=Disarm).
'''Achtung: Es ist zwingend notwendig, dass für einen auszulösenden Alarmlevel auch ein Sensor für den Widerruf (=Cancel) des Alarms definiert wird, ansonsten ignoriert das Modul die Definition dieses Levels.'''

Die insgesamt in den ''STATE'' der Alarmanlage geschriebene Nachricht besteht dann aus
(Anzeige der Zustände) (Nachricht Teil 1)' '(Nachricht Teil 2).
Bitte weiter unten nachlesen, was mit der [http://www.fhemwiki.de/wiki/Modul_Alarmanlage#Anzeige_der_Zust.C3.A4nde Anzeige der Zustände] gemeint ist.
In diesen Nachrichten werden die folgenden Ersetzungen vorgenommen
* $NAME vird durch den Namen des auslösenden Devices ersetzt
* $EVENT wird durch den kompletten Event ersetzt
* $EVTPART1... wird durch den 1. Teilstring des Events gefüllt, etc.

[[Datei:alarm_sensors.png]]

===Actors===
Anschließend wird die Tabelle der Aktoren angezeigt. Für jeden Aktor kann gesetzt werden:
*Alarmlevel, die diesen Aktor starten
*Ein FHEM-Kommando zum Starten des Aktors
*Ein FHEM-Kommando zum Stoppen des Aktors
*Eine Zeitverzögerung - entweder als Angabe von Sekunden (<60) oder im Format mm:ss

[[Datei:alarm_actors.png]]

==Einrichten==
Durch Anklicken des Buttons ''Set Alarms'' werden die ''alarmSettings''-Attribute befüllt.
'''Achtung, Folgendes beachten'''
*Es ist zwingend notwendig, dass für einen auszulösenden Alarmlevel auch ein Sensor für den Widerruf (=Cancel) des Alarms definiert wird, ansonsten ignoriert das Modul die Definition dieses Levels.
*Der Button ''Set Alarms'' wird nur funktionieren, wenn keine [http://www.fhemwiki.de/wiki/Modul_Alarmanlage#Sperrung Sperrung] vorliegt, siehe unten.
*Es empfiehlt sich, danach ein ''Save Config'' auszuführen, damit die Attribute und Notifier permanent sind.

===Anzeige der Zustände===
Auf Wunsch können die Zustände der Alarmanlage zusammen mit der konkreten Meldung im internal ''STATE'' (bzw. reading ''state'', beide sind in diesem Modul identisch) angezeigt werden.
Hierfür gibt es ein Attribut ''statedisplay'' mit den folgenden möglichen Werten, die nachfolgend am Beispiel für den Zustand "Alarm Level 1 ausgelöst" erläutert sind:
* ''none'' - keine Anzeige
* ''simple'' - OXOOOOOO
* ''color'' - <span style="color:green"> 0 <span style="width:1ex;color:red">1</span> 2 3 4 5 6 7</span>
* ''table'' - <table><tr style="height:1ex"><td style="width:1ex;background-color:green"/><td style="width:1ex;background-color:red"/><td style="width:1ex;background-color:green"/><td style="width:1ex;background-color:green"/><td style="width:1ex;background-color:green"/><td style="width:1ex;background-color:green"/><td style="width:1ex;background-color:green"/><td style="width:1ex;background-color:green"/></tr></table>

Das Problem ist, dass möglicherweise das internal ''STATE'' an anderer Stelle verwendet werden soll - z.B. beim Versenden von Mails als
Value('AAA')
Es macht natürlich keinen Sinn, eine HTML-Tabelle in eine Mail zu packen. Deshalb sollte für die Weiterverarbeitung statt des obigen Code verwendet werden
$defs{'AAA'}{READINGS}{"short"}{VAL}
Dies enthält nur die Meldung, nicht aber die Anzeige aller Zustände. Alternativ kann man auch die Zustandsanzeige durch Wahl des Attributwertes ''none'' komplett abstellen.
===Sperrung===
Das Attribut ''lockstate'' muss den Wert ''unlocked'' haben, damit durch Anklicken des Buttons ''Set Alarms'' die ''alarmSettings''-Attribute befüllt werden können. Das ist in der Regel beim ersten Laden des Moduls '''nicht''' der Fall, hierzu muss also das Attribut von Hand auf den richtigen Wert gesetzt werden !

=Sensoren=
==Rauchalarm==
'''Dieser Alarm ist mit Lebensgefahr verbunden und wird deshalb unabhängig von FHEM ausgelöst, und von FHEM nur registriert und mit weiteren Aktoren verbunden'''.

Im Beispiel werden vernetzte Rauchmelder des Typs [[HM-SEC-SD_Rauchmelder|HM-SEC-SD]] verwendet. Deren Teamleader erhalten das Attribut ''alarmDevice Sensor'', so dass sie in der Sensorenliste der Alarmanlage auftauchen. Sie lösen den Alarm mit dem höchsten Level aus. Die Realisierung lässt sich aber auch über beliebige andere in FHEM eingebundene Rauchmelder erreichen.

[[Datei:alarm_smoke.png]]

==Öffnung von Fenstern oder Türen ==
Dies dient der Überwachung von '''Zustandsänderungen''', ebenso wie zur '''Überprüfung eines statischen Zustands'''
===Szenarien===
====Kontrollrunde====
Dieses Alarmszenario (Alarmlevel 4) liegt vor, wenn die Hausbewohner anwesend sind, aber irgendwann zu Bett gehen wollen und vorher noch überprüfen, ob auch alle Türen und das Garagentor geschlossen sind. Sagen wir, beginnend um 22:00 bis 23:59. Man könnte diesen Alarmlevel aber auch durch einen externen Regensensor auslösen, der die Dachfenster auf ihren Öffnungszustand untersucht. Jedenfalls sollte dieser Alarmlevel immer scharf sein.

Durch einen externen Auslöser (sagen wir, beginnend um 22:00 Uhr) wird in periodischen Abständen eine Hilfsroutine gestartet, welche die Zustandsprüfung vornimmt und registriert. Nur wenn diese Registrierung eine Öffnung ergibt, wird der Alarm ausgelöst. Dieser Alarmlevel gehört also zur Kategorie ''Warnung'' und wird deshalb nur eine moderate Signalisierung benötigen - beispielsweise
*eine Nachricht mit gelbem Hintergrund erscheint auf einem [[Digitaler_Bilderrahmen_mit_lcd4linux|Digitalen Bilderrahmen]]
*eine Nachricht erscheint auf einem [[1-Wire_Textdisplay]]
*eine LED geht an auf dem [[1-Wire LED-Statusmonitor]]

====Zutritt====
Dieses Alarmszenario (Alarmlevel 5) liegt vor, wenn die Hausbewohner anwesend sind, aber vermutlich schlafen gegangen sind. Sagen wir, von 0:00 bis 5:00.

Wenn morgens um 4:00 die Haustür geöffnet wird, handelt es sich entweder um ein spätes Heimkommen eines Hausbewohners von einer Party - oder um einen Einbruchsversuch. Der Partygeher sollte also eine gewisse Warnungszeit bekommen, bevor ein moderater akustischer Aktor (sagen wir, ein Funkgong) losgeht. Dieser Aktor muss deshalb mit einer Verzögerung eingeschaltet werden, und der Partygeher erhält eine Warnung. Diese Warnung - sagen wir, eine bestimmte Lampe geht an - informiert ihn, dass er innerhalb von 30 Sekunden einen bestimmten Schalter betätigen muss. Etwa den für genau diese Lampe, um sie auszuschalten. Der Einbrecher kennt diesen Schalter nicht, der moderate Alarm wird also die schlafenden Hausbewohner wecken und ihn abschrecken.

Zusätzlich verfügt dieser Level auch noch über einen Partymodus: Mit diesem kann er für 24 Stunden abgestellt werden, so dass man auch um 3:00 in der Frühe die eigenen Partygäste aus dem Haus lassen kann, ohne ihn auszulösen.
====Einbruch====
Dieses Alarmszenario (Alarmlevel 6) liegt vor, wenn die Hausbewohner abwesend sind und diesen Level vorher scharf geschaltet haben - und idealerweise von 0:00 bis 23:59. Jeder Zutritt zu Haus löst diesen Alarm aus, und der akustische Aktor kann durchaus kräftig sein (etwa Einschalten der Rauchmelder für 1 Minute).

Da die Auslösung auch erfolgt, wenn der Hausbesitzer heimkommt, muss der akustische Aktor eine Verzögerung haben und innerhalb dieser einer Warnung gegeben werden, z.B. indem zunächst eine bestimmte Lampe angeht. Dies informiert ihn, dass er innerhalb von 30 Sekunden einen bestimmten Schalter betätigen muss. Etwa die Kombination, um diesen Alarmlevel unscharf zu schalten. Der Einbrecher kennt diese Kombination nicht, die Beleuchtung wird ihn also zunächst abschrecken und der nachfolgende laute akustische Aktor auch die Nachbarn wecken.
===Zustandsänderung===
Dazu werden alle überwachten Fenster- und Türkontakte mit dem Attribut ''alarmDevice Sensor'' versehen, so dass sie in der Sensorenliste der Alarmanlage auftauchen. In der Alarmkonfiguration sieht das dann so aus:

[[Datei:alarm_tf.png]]

===Zustandsprüfung===
Dies dient der Überprüfung eines '''statischen Zustands''', konkret ob und welche Fenster oder Türen offen sind - z.B. abends, oder bei Regenwetter. Dazu benötigen wir drei ''dummy'' Devices, von denen zwei als ''alarmDevice Sensor'' und einer als ''alarmDevice Actor'' attributiert werden und somit in der Sensoren- bzw. Aktorenliste der Alarmanlage auftauchen.

define TFOpen.warn dummy
attr TFOpen.warn alarmDevice Sensor
'''attr TFOpen.warn alarm4,|TFOpen.warn:.*[TF].*|$EVENT|on''' (Diese Zeile wird vom Modul 95_Alarm.pm automatisch erzeugt)
attr TFOpen.warn group windowDetector
attr TFOpen.warn room Alarm

define TFClose.warn dummy
attr TFClose.warn alarmDevice Sensor
'''attr TFClose.warn alarmSettings alarm4,|TFClose.warn:yes|Alle zu|off''' (Diese Zeile wird vom Modul 95_Alarm.pm automatisch erzeugt)
attr TFClose.warn group windowDetector
attr TFClose.warn room Alarm

define TFOpen.check dummy
attr TFOpen.check alarmDevice Actor
'''attr TFOpen.check alarmSettings alarm4,|{HouseOpen()}||10:00''' (Diese Zeile wird vom Modul 95_Alarm.pm automatisch erzeugt)
attr TFOpen.check group windowDetector
attr TFOpen.check room Alarm

[[Datei:TFAlarm.png|left|thumb|200px|]]Als nächstes muss eine Überwachungsroutine geschrieben werden. Das kann entweder als FHEM-Skript geschehen, oder in der Datei 99_myUtils.pm als perl-Code. Dieses Unterprogramm muss
*den obigen ''dummy'' TFOpen.warn setzen, und zwar auf den oder die Namen der geöffneten Fenster und Türen oder "none", wenn keine geöffnet sind.
*den obigen ''dummy'' TFClose.warn setzen, und zwar auf den Wert "no", wenn irgendeine geöffnet ist und "yes", wenn keine geöffnet sind.
Ein Beispiel für eine solche Überwachungsroutine ist weiter unten zu sehen.

Diese Doppelung ist nötig, weil jeder Sensor nur mit einem notify in den Alarmen auftauchen kann - das dient der Sicherheit gegen Fehlkonfiguration und ist beabsichtigt.

In dem nebenstehenden Flussdiagramm wird der Ablauf dargestellt, der sich mit diesem System ergibt. Dabei wird um 22:00 der erste Test auf ein ordnungsgemäß geschlossenes Haus gestartet - und bis Mitternacht alle 10 Minuten wiederholt. Alternativ könnte man das auch mit einem Regensensor als Erstauslöser koppeln.

Beispielcode für eine Überwachungsroutine:

sub HouseOpen()
{
my $kfo = 0;
my $kfs = "";
my $kto = 0;
my $kts = "";
my $str = "";
if( $main::value{'BK.F'} ne "Closed" ){
$kfo++;
$kfs = "BK/";
}
if( $main::value{'WK.F'} ne 'Closed' ){
$kfo++;
$kfs = $kfs."WK/";
}
if( $main::value{'VK.T'} ne "Closed" ){
$kto++;
$kts = "VK/";
}
if( $main::value{'WZ.T'} ne 'Closed' ){
$kto++;
$kts = $kts."WZ/";
}
if( ($kfo >= 1) && ($kto == 0) ){
$kfs = substr($kfs,0,-1);
fhem("define TFOpen.delay at +00:00:30 set TFOpen.warn $kfs Fenster");
fhem("define TFClose.delay at +00:00:30 set TFClose.warn no");
}elsif( ($kfo == 0) && ($kto >= 1) ){
$kts = substr($kts,0,-1);
fhem("define TFOpen.delay at +00:00:30 set TFOpen.warn $kts Tür");
fhem("define TFClose.delay at +00:00:30 set TFClose.warn no");
}elsif( ($kfo >= 1) && ($kto >= 1)){
$kts = substr($kts,0,-1);
$kfs = substr($kfs,0,-1);
$str = "$kts Tür + $kfs Fenster";
fhem("define TFOpen.delay at +00:00:30 set TFOpen.warn $kts T / $kfs F");
fhem("define TFClose.delay at +00:00:30 set TFClose.warn no");
}else{
fhem("set TFOpen.warn none");
fhem("set TFClose.warn yes");
}
return $str;
}

==Batterie schwach bei FHEM-Devices==
Dieser Sensor besteht aus einem ''notify'' und einem ''dummy'', der bei einer 'battery low'-Meldung eines beliebigen FHEM-Device auf dessen Namen gesetzt wird. Der ''dummy'' wird als ''alarmDevice Sensor'' attributiert, so dass er in der Sensorenliste der Alarmanlage auftaucht.

define LBatt.N notify .*:[Bb]attery.*[Ll]ow.* set LBatt.warn $NAME
attr LBatt.N room Alarm
attr LBatt.N group deviceDetector

define LBatt.warn dummy
attr LBatt.warn alarmDevice Sensor
attr LBatt.warn room Alarm
attr LBatt.warn group deviceDetector
Auf einen Test, ob gleichzeitig bei anderen FHEM-Devices die Batterie ebenfalls schwach ist, wird hier verzichtet. Für diesen Sensor wird ein eigener Alarmlevel (niedriger Priorität) erzeugt. Bei einem beliebigen 'battery low' Event wird somit der STATE der Alarmanlage gesetzt auf '''Batt. <devicename> schwach'''. Dieser Alarm muss manuell zurückgesetzt werden (schließlich sollten die Batterien ja erst gewechselt werden...)

[[Datei:alarm_lbatt.png]]

=Aktoren=
==Rauchmelder als Alarmsignal==
Für Alarme, bei denen es wirklich auf schnelle Reaktionen ankommt, kann man auch Rauchdetektoren verwenden, die über Funk aktivierbar sind. Im Beispiel werden vernetzte Rauchmelder des Typs [[HM-SEC-SD_Rauchmelder|HM-SEC-SD]] verwendet.

'''Achtung: Es ist sehr empfehlenswert, diesen Alarm auch wieder automatisch auszuschalten.'''

Dazu wird ein ''dummy'' erzeugt und mit ''alarmDevice Actor'' attributiert, so dass er in der Aktorenliste auftaucht:

define SD.alarm dummy
attr SD.alarm alarmDevice Actor
attr SD.alarm alarmSettings alarm7,|set TH.SD0 alarmOn|set TH.SD0 alarmOff|30
attr SD.alarm group alarmActor
attr SD.alarm room Alarm
In der Alarmkonfiguration sieht das dann so aus:

[[Datei:alarm_smokeactor.png]]

==Funk-Türgong / MP3-Türgong als Alarmsignal==
Hier wird ein FS20-Türgong als akustisches Alarmsignal verwendet.

define WZ.Gong FS20 <adresse>
attr WZ.Gong IODev CUL
attr WZ.Gong alarmDevice Actor
'''attr WZ.Gong alarmSettings alarm5,alarm6,|set WZ.Gong on||30''' (Vom Modul 95_Alarm.pm automatisch erzeugt)
attr WZ.Gong group alarmActor
attr WZ.Gong room Alarm,Erdgeschoss
In der Alarmkonfiguration sieht das dann so aus:

[[Datei:alarm_gongactor.png]]

Bei Verwendung eines MP3-Funkgongs (z.B. aus dem Homematic-Programm) kann man auf diesem eine ganze Menge verschiedene MP3-Dateien speichern, die z.B. Stimmenmeldungen "Alarmanlage scharf geschaltet" abgeben. Zur Erstellung dieser Meldungen hat es sich bewährt, einen kostenlosen Online-TTS (Text-to-Speech) Service zu nutzen, z.B. Ivona.
==Alarmierung per SMS==
Für Alarme, die man auch im Urlaub auf das Handy bekommen möchte, bedarf es natürlich eines Providers, der eine bestimmte Mailadresse als SMS weiterleitet. Ferner einer FHEM-Konfiguration, die Mails versenden kann. Dann wird ein ''dummy'' erzeugt und mit ''alarmDevice Actor'' attributiert, so dass er in der Aktorenliste auftaucht:
define Mail.alarm dummy
attr Mail.alarm alarmDevice Actor
'''attr Mail.alarm alarmSettings alarm6,alarm7,|{DebianMail(<mailadresse>,'Alarm',Value('AAA'))}||30''' (automatisch erzeugt)
attr Mail.alarm group alarmActor
attr Mail.alarm room Alarm
In der Alarmkonfiguration sieht das dann so aus:

[[Datei:alarm_mailactor.png]]

[[Kategorie:Examples]]

Diskussion:HM-CC-RT-DN Funk-Heizkörperthermostat

2015-02-02T19:25:36Z

Peterchen89:

Hallo...

Fehlt da nicht in der Perl-Sub Urlaub($$$$$) ein ";" hinter

<code>
#Sendebefehl für ein HM-CC-RT-DN
{fhem ("set Kammer controlParty $temp $startDate $startTime $endDate $endTime")}
</code>
?

Kann es jetzt gerade nicht nachprüfen.

----
Stimmt das mit dem Channel 4 für burstRx noch? Zumindest ich bekomme das nur ausgelesen wenn ich direkt das Device abfrage. Habe fhem aus dem Trunk und Firmware 1.4 auf den Thermostaten. --[[Benutzer:Peterchen89|Peterchen89]] ([[Benutzer Diskussion:Peterchen89|Diskussion]]) 19:25, 2. Feb. 2015 (UTC)
<pre>
fhem> get kueche_heizung_Clima reg burstRx
Value not captured
fhem> get kueche_heizung reg burstRx
on
fhem>
</pre>

Icons

2014-10-02T05:08:26Z

Peterchen89: /* Geräten Icons zuweisen */ Beispiel für CMD ergänzt

Icons - alles rund um die Icons in Fhem
= Fhem mit Icons verschönern =
== Geräten Icons zuweisen ==
Im FHEMWEB auf Detail-Ansicht des Gerätes gehen, danach in der attr Zeile per dropdown
# Icon auswählen, um das Icon zu wählen, das standardmäßig links vom Gerät gezeigt wird; alternativ ganz unten auf '''Select Icon''' klicken, dann bekommt ihr alle Bilder angezeigt
# '''devStateIcon auswählen''', um unterschiedliche Schaltzustände mit unterschiedlichen Icons zu versehen; alternativ ganz unten auf '''Extend devStateIcon''' klicken, dann bekommt ihr alle Bilder angezeigt und könnt sie dem jeweiligen Schaltzustand zuordnen.

Dabei gilt folgendes:
* Icon-Dateiname OHNE Dateiendung eingeben
* wenn es sich bei dem Icon um eine svg-Datei handelt, kann mit @farbe die Farbe beeinflusst werden, z.B. <br /> <code>attr Geraet devStateIcon an:general_an@green aus:general_aus@red</code>, <br /> wobei hier die beiden Dateien general_an.svg und general_aus.svg heißen.
* statt des Standardfarbnamens, kann übrigens auch der 6-stellige Hex-Code übergeben werden (ohne # am Anfang). Den Code könnt ihr z.B. hier bei [http://www.colorpicker.com Colorpicker] generieren
* Möchte man dass bei Klick auf das Icon auch eine Aktion ausgelöst wird, kann man dies als dritten Parameter mit angeben. Beispiel für einen Wechsel zwischen "arround" und "away": <code>arround:status_available:away away:status_away_2:arround</code>.

Wenn ihr die Änderungen wie oben beschrieben durchführt, könnt ihr das Ergebnis gleich betrachten. Wenn alles passt, dann noch '''Save config''' drücken, dann wird alles fest abgespeichert.

== Größe der Icons verändern ==
Auch das kein Problem. Öffnet einfach die für Eurer Template (wie sieht fhem bei Euch aus: rechts unten -> Select Style -> das was ihr dort gewählt habt ist Euer Template) zuständige css-Datei. Diese findet ihr im fhem-Verzeichnis unter www/pgm2. Dort fügt ihr einfach folgende Zeile ein und ändert ggf. die Größenangaben.
<pre>svg { height:32px; width:32px; }</pre>

== Mehr Icons zur Auswahl ==
Grundsätzlich sind bei aktuellen fhem-Installationen die meisten Icons standardmäßig aktiviert. Navigiert doch einfach mal im fhem Verzeichnis in den www Ordner und dort in images. Die Ordner default, openautomation und fhemSVG sind standardmäßig aktiviert, d.h., Icons aus diesen Ordnern werden in fhem angezeigt. Wenn ihr zusätzlich die Icons auch aus den anderen Ordnern (z.B. icons_small) verwenden wollt, dann ergänzt einfach die entsprechende Zeile "WEB iconPath" in der fhem.cfg:
<pre>attr WEB iconPath fhemSVG:openautomation:default:icons_small</pre>

Das gleiche gilt, wenn ihr eine ältere fhem-Installation habt und noch nicht die Bilder z.B. aus fhemSVG angezeigt bekommt.

== Weitere Tipps ==
Weitere Tipps zu Icons finden sich auch auf der Seite [[Slider für HM-Rolladensteuerung anzeigen]].

= Eigene Icons erstellen =
Falls ihr eigene Icons basteln wollt - sehr gerne. Umso besser, wenn ihr diese dann mit uns teilt. Der passende [http://forum.fhem.de/index.php/topic,12605.0.html Thread im Forum].

== SVG-Icons ==
Hier einige Tipps zum Erstellen von SVG-Icons. SVGs bieten einige Vorteile:
* SVGs sind vektorbasiert und somit frei skalierbar
* SVGs sind, wenn man sie genauer betrachtet, gut lesbarer und veränderbarer Quellcode und können deswegen leicht über css manipuliert werden

Wie geht es nun:
* [http://inkscape.org/download/?lang=de Inkscape] besorgen (Open Source)
* Loszeichnen

Jetzt wird es wichtig - fhem ist etwas sensibel, was svgs anbelangt und will diese zudem farblich umgestalten. Daher folgendes unbedingt beachten:

* fhem ersetzt bei allen fill:#000000 und fill="#000000" die sechs Nullen mit einem Farbcode, wenn dieser mit übergeben wurde (sh. Fhem mit Icons verschönern weiter oben) - das solltet ihr beim zeichnen beachten
* daher arbeite ich immer so, dass ich beispielsweise Rechtecke/Kreise zeichne und diese dann mit "Kontur in Pfad umwandeln" umwandle -> dann ist das Rechteck transparent, die Linie schwarz (und wird von fhem erstetzt) und alles klappt
* alle Texte müssen in Pfade umgewandelt werden
* das gesamte Bild muss als "Normales SVG" gespeichert werden (Standardeinstellung bei Inkscape ist "Inkscape SVG")
* letzter wichtiger Tipp: Eine Zeile darf im SVG nicht fehlen, sonst zeigt fhem es nicht an. Wenn ihr Euer SVG in einem Texteditor öffnet (ich empfehle notepad++), schaut in in der <svg>-Definition, ob die Zeile mit viewBox dabei ist. Wenn nicht, dann nach unterem Format ergänzen.

<pre>
<?xml version="1.0" encoding="UTF-8" standalone="no"?>

<svg
version="1.0"
width="585"
height="585"
viewBox="0 0 585 585"
id="svg2421"
sodipodi:docname="usb-stick.svg">
</pre>

== SVG-Icons für das Modul remotecontrol: Schriftvorlage ==
Wer beispielsweise für das Modul remotecontrol noch andere Beschriftungen braucht, der kann sich diese ganz fix selbst machen. Im Ordner fhem\www\images\fhemSVG findet ihr die Datei rc_templatebutton.svg. Mit der macht ihr folgendes:
Ganz einfach inkscape runterladen (http://inkscape.org/download/?lang=de), Datei öffnen, auf Text klicken, dann oben in der Leiste auf Text -> Schrift und Text -> Reiter Text, Text ändern. Ggf. Größe/Position anpassen, dann Pfad -> Objekt in Pfad umwandeln, dann Datei -> Speichern unter -> euer name und "Normales SVG" => FERTIG

[[Kategorie:HOWTOS]]

Diskussion:CUL HM

2014-10-02T04:59:59Z

Peterchen89: Neuer Abschnitt /* HMID VCCU */

== HMID VCCU ==

In den Artikeln zu den Tastern ([[HM-PB-2-WM55_2fach-Funk-Wandtaster]] steht dass die hmId nicht existieren darf. Damit hat es aber bei mir nicht geklappt. Als ich die HMID auf die von mir verwendete gesetzt habe ging alles. War das Zufall, hat sich irgenwas geändert oder war die Information aus den Tasterartikeln einfach falsch?

Wenn der Abschnitt über virtuelle Aktoren hier so passt können wir die Abschnitte aus den Tasterartikeln rausnehmen und hierhin verlinken. --[[Benutzer:Peterchen89|Peterchen89]] ([[Benutzer Diskussion:Peterchen89|Diskussion]]) 04:59, 2. Okt. 2014 (UTC)

CUL HM

2014-10-02T04:57:18Z

Peterchen89: /* Anwendungsbeispiele */ virtuellen Aktor erstellen

{{Infobox Modul
|ModPurpose=HomeMatic Geräte (über CUL oder HMLAN)
|ModType=d
|ModCmdRef=CUL_HM
|ModForumArea=HomeMatic
|ModTechName=10_CUL_HM.pm
|ModOwner=martinp876 ([http://forum.fhem.de/index.php?action=profile;u=251 Forum] / [[Benutzer Diskussion:Martinp876|Wiki]])
}}

[[CUL_HM]] implementiert die Unterstützung für [[HomeMatic]]-Geräte, die über einen [[CUL]] oder
[[HM-CFG-LAN LAN Konfigurations-Adapter|HMLAN]] angebunden sind.

== Voraussetzungen ==
HomeMatic [[Interface]]: CUL im HomeMatic Modus oder HMLAN.

== Anwendung ==
=== Define ===
Details in der commandref.
:<code>define <name> CUL_HM <6-digit-hex-code|8-digit-hex-code> </code>

=== Attribute ===
Details in der commandref.

==== Virtuelle CCU (VCCU) ====
[[Datei:VirtualCCU.png|mini|400px|rechts|Standarddarstellung einer Virtual CCU im Webinterface]]
Die Definition von (z.B.)
:<code>define myVCCU CUL_HM 5C0C05</code>
:<code>attr myVCCU model CCU-FHEM</code>
führt zum Anlegen eines CUL_HM Device ''myVCCU'' als '''virtuelle CCU'''. Das Device bekommt (automatisch) ein Attribut <code>subType</code> mit dem Wert <code>virtual</code> und wird im [[PGM2|Webinterface]] wie in der Abbildung gezeigt dargestellt. Die einzelnen Elemente bedeuten:
;myVCCU
:Name des Device
;myHMLAN
:Name(n) des (der) zugeordneten IO Device(s) (mit dem angehängten aktuellen Status, hier <code>:ok</code>)
;Schieberegler
:???
;<code>update</code>
:Schaltfläche zum ...???

In den zugeordneten IO Devices wird automatisch(?) ein ''internal value'' mit Namen <code>owner_CCU</code> und dem Wert <code>myVCCU</code> angelegt.

Details zum Konzept, den Vorteilen und der Benutzung finden sich derzeit in {{Link2Forum|Topic=23008|LinkText=diesem Forenthread}} und auch {{Link2Forum|Topic=24048|Message=194876|LinkText=hier}}.

{{Todo|Das VCCU-Konzept scheint bedeutend (und komplex) genug, dass eine eigene Wiki-Seite gerechtfertigt wäre. Es muss sie nur noch jemand erstellen...}}

== Anwendungsbeispiele ==
=== Virtuellen Aktor erstellen ===
Ein virtueller Aktor ist nötig, damit Taster wie z.B. der [[HM-PB-6-WM55_6fach-Funk-Wandtaster|6fach-Wandtaster]] oder der [[HM-PB-2-WM55_2fach-Funk-Wandtaster|2fach-Wandtaster]] einen Tastendruck mit grünem Aufleuchten bestätigen. Diese Rückmeldung geben die Taster normalerweise wenn sie den Tastendruck an ihre Peers weitergeben haben. Hat man aber keine Homematic-Peers direkt gekoppelt (also nur die Zentrale gepairt), leuchten die Taster lediglich orange.

Mit einer virtuellen CCU kann man virtuelle Aktoren erstellen, mit denen man die Taster dann peeren kann. Zunächst muss dazu eine virtuelle CCU angelegt werden <code>define virtualCCU CUL_HM XXXXXX</code>, wobei XXXXXX der hmId des HMLAN-Interfaces entspricht (bzw. dessen was statt HMLAN verwendet wird). Mit <code>attr virtualCCU model CCU-FHEM</code> gibt man der CCU noch den korrekten Typ.
Virtuelle Aktoren kann man in der benötigten Anzahl (d.h. Anzahl aller Tasterbuttons) nun mit <code>set virtualCCU virtual X</code> anlegen, wobei X der benötigten Anzahl virtueller Aktoren entspricht. Danach existieren die virtuellen Aktoren als z.b. <code>virtualCCU_Btn1, virtualCCU_Btn2</code> usw. in FHEM.

Die Peerings zwischen Tastern und den Buttons stellt man dann folgendermaßen her (CUL_HM_HM_PB_2_WM55_1F1xxx_Btn_01 und CUL_HM_HM_PB_2_WM55_1F1xxx_Btn_02 sind jeweils die Buttons des Tasters CUL_HM_HM_PB_2_WM55_1F1xxx):
<pre>
set CUL_HM_HM_PB_2_WM55_1F1xxx_Btn_01 peerChan 0 virtualCCU_Btn1 single set
set CUL_HM_HM_PB_2_WM55_1F1xxx_Btn_02 peerChan 0 virtualCCU_Btn2 single set
</pre>

Danach führt man ein <code>set CUL_HM_HM_PB_2_WM55_1F1xxx getConfig</code> aus und drückt einmal kurz den Anlern-Button des Tasters. Danach sollte der Taster mehrmals kurz orange blinken.

Wenn alles geklappt hat wird nach dem betätigen der Taster in den States von CUL_HM_HM_PB_2_WM55_1F1xxx_Btn_01 bzw. CUL_HM_HM_PB_2_WM55_1F1xxx_Btn_02 ein "(to virtualCCU)" stehen.

Save Config nicht vergessen :-).

==== Tipps ====
* Es wäre auch möglich nur einen virtuellen Aktor anzulegen und alle Buttons damit zu peeren.

== Links ==
* [http://forum.fhem.de/index.php/topic,23008.msg163510.html Forenthread] zum Thema ''virtuelle CCU''.

[[Kategorie:HomeMatic Components]]

DbLog

2014-10-02T04:29:27Z

Peterchen89: /* Links */ + Ergänzung von Link auf Heizleistung_und_Gasverbrauch als Beispiel für SVG aus DbLog

{{Todo|Diese Seite muss noch vervollständigt werden. Informationen sind bisher verstreut, hauptsächlich über [[PGM3 dbLog]] und [[Neues Charting Frontend]].}}

{{Infobox Modul|
ModPurpose=Protokolliert Ereignisse in einer Datenbank
|ModType=h
|ModTechName=93_DbLog.pm
|ModOwner=Tobias
}}
[[DbLog]] protokolliert, im Unterschied zu [[FileLog]], Fhem-Ereignisse in einer Datenbank.

== Definition ==
DbLog wird durch 2 verschiedene Einträge aktiviert/definiert. In einer Datei namens db.conf werden in die Parameter für eine Verbindung zur Datenbank (host, username, password, etc.) hinterlegt. Diese Datei kann in einem beliebigen Verzeichnis angelegt werden.
Das DbLog Device wird dann in der fhem.cfg 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 .*:.* 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 unrelevanten Werten gefüllt wird. Man kann daher die zu loggenden Werte einschränken, indem man genau angibt welche Werte übertragen werden sollen. Die erste Wildcard, also das erste .* entspricht dem in FHEM verwendeten Device-Namen. Die weite Wildcard 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>

== Datenbank ==
Unterstützte Datenbanksysteme (Auswahl):
* Sqlite
* mySQL
*

=== Tabellen ===
* current
* history

=== Tabellenlayout ===
DbLog ist auf eine feste Tabellenstruktur angewiesen. Man muss daher in seiner Datenbank eine Tabelle mit folgenden Spalten anlegen:
* TIMESTAMP: timestamp of event, e.g. 2007-12-30 21:45:22
* DEVICE: device name, e.g. Wetterstation
* TYPE: device type, e.g. KS300
* EVENT: event specification as full string, e.g. humidity: 71 (%)
* READING: name of reading extracted from event, e.g. humidity
* VALUE: actual reading extracted from event, e.g. 71
* UNIT: unit extracted from event, e.g. %

== Links ==
* [[Heizleistung_und_Gasverbrauch|Beispiel das DbLog-Daten für SVG-Plots verwendet]]

DOIF

2014-10-02T04:23:05Z

Peterchen89: /* Waschmaschine Fertigmeldung */ pre statt code

{{Infobox Modul
|ModPurpose=Do ... if ...
|ModType=h
|ModForumArea=Automatisierung
|ModTechName=98_DOIF.pm
|ModOwner=Damian}}

[[DOIF]] ermöglicht, Aktionen ("do") unter bestimmten Bedingungen ("if") auszuführen. Bedingungen umfasst auch Konstrukte wie "wenn Zustand x ([[watchdog]]) für y Minuten... (Zeitsteuerung)".

Details zu diesem Modul finden sich derzeit nur in {{Link2Forum|Topic=23833|LinkText=diesem Forenthread}}.

== Voraussetzungen ==
Siehe Forum.

== Anwendung ==
=== Define ===
Siehe Forum.

=== Attribute ===
Siehe Forum.

== Anwendungsbeispiele ==
Siehe Forum.

=== Waschmaschine Fertigmeldung ===
Mit DOIF lässt sich sehr einfach eine Fertigmeldung für die Waschmaschine realisieren. Alles was dazu nötig ist, ist ein Dummy-Device das den aktuellen Betriebszustand der Waschmaschine enthält, ein notify der darauf reagiert und z.b. eine Nachricht via pushover sendet und ein DOIF das die Bedingungen für die Änderung des Betriebszustandes definiert. Im Beispiel unten ist im DOIF eine Schwelle von 5 Watt gesetzt ab der das Dummy-Device auf "on" gesetzt wird. Mittels wait wird für diese erste Bedingung eine Zeit von 60 Sekunden angegeben über die die 5 Watt genutzt werden müssen. Für den "fertig"-Fall wird ein Schwellenwert von 4 Watt angesetzt der für mindestens 300 Sekunden unterschritten werden muss.

<pre>
define waschmaschine_betrieb dummy
attr waschmaschine_betrieb event-on-change-reading state

define waschmaschine_DI DOIF ([waschmaschine_Pwr:power]>5) (set waschmaschine_betrieb on) DOELSEIF ([waschmaschine_Pwr:power]<4) (set waschmaschine_betrieb off)
attr waschmaschine_DI wait 60:300

define waschmaschine_fertig_pushover notify waschmaschine_betrieb:off set pushover msg 'Waschmaschine' 'Waschmaschine ist jetzt fertig!'
</pre>

Getestet wurde der Code mit einem [[HM-ES-PMSw1-Pl_Funk-Schaltaktor_1-fach_mit_Leistungsmessung]]. Dabei ist waschmaschine_Pwr das Device zu Channel 2.

=== On-for-timer simulieren ===
Die on-for-timer Funktion kann für Geräte, die das nicht von Haus aus unterstützen mit folgenden Definitionen simuliert werden:

<pre>
define schalter_d dummy

define di_Schalter DOIF ([Bewegungsmelder] eq "motion" ) (set schalter_d on, set schalter_d off)
attr di_Schalter do always

define di_Licht DOIF ([schalter_d] eq "on") (set Licht on) DOELSE (set Licht off)
attr di_Licht wait 0:300
</pre>

Details dazu finden sich in {{Link2Forum|Topic=23833|Message=193660|LinkText=diesem Forenbeitrag}}.

Alternativ kann man die on-for-timer Funktion durch Verwendung von [[ReadingsProxy|readingsProxy]] simulieren, da readingsProxy-Geräte alle Funktionen der [http://fhem.de/commandref.html#setExtensions setExtension] unterstützen.

== Links ==
* {{Link2Forum|Topic=23833|LinkText=Forenthread}} zur Entstehung dieses Moduls

DOIF

2014-10-02T04:22:33Z

Peterchen89: /* Anwendungsbeispiele */ Waschmaschine beschrieben

{{Infobox Modul
|ModPurpose=Do ... if ...
|ModType=h
|ModForumArea=Automatisierung
|ModTechName=98_DOIF.pm
|ModOwner=Damian}}

[[DOIF]] ermöglicht, Aktionen ("do") unter bestimmten Bedingungen ("if") auszuführen. Bedingungen umfasst auch Konstrukte wie "wenn Zustand x ([[watchdog]]) für y Minuten... (Zeitsteuerung)".

Details zu diesem Modul finden sich derzeit nur in {{Link2Forum|Topic=23833|LinkText=diesem Forenthread}}.

== Voraussetzungen ==
Siehe Forum.

== Anwendung ==
=== Define ===
Siehe Forum.

=== Attribute ===
Siehe Forum.

== Anwendungsbeispiele ==
Siehe Forum.

=== Waschmaschine Fertigmeldung ===
Mit DOIF lässt sich sehr einfach eine Fertigmeldung für die Waschmaschine realisieren. Alles was dazu nötig ist, ist ein Dummy-Device das den aktuellen Betriebszustand der Waschmaschine enthält, ein notify der darauf reagiert und z.b. eine Nachricht via pushover sendet und ein DOIF das die Bedingungen für die Änderung des Betriebszustandes definiert. Im Beispiel unten ist im DOIF eine Schwelle von 5 Watt gesetzt ab der das Dummy-Device auf "on" gesetzt wird. Mittels wait wird für diese erste Bedingung eine Zeit von 60 Sekunden angegeben über die die 5 Watt genutzt werden müssen. Für den "fertig"-Fall wird ein Schwellenwert von 4 Watt angesetzt der für mindestens 300 Sekunden unterschritten werden muss.

<code>
define waschmaschine_betrieb dummy
attr waschmaschine_betrieb event-on-change-reading state

define waschmaschine_DI DOIF ([waschmaschine_Pwr:power]>5) (set waschmaschine_betrieb on) DOELSEIF ([waschmaschine_Pwr:power]<4) (set waschmaschine_betrieb off)
attr waschmaschine_DI wait 60:300

define waschmaschine_fertig_pushover notify waschmaschine_betrieb:off set pushover msg 'Waschmaschine' 'Waschmaschine ist jetzt fertig!'
</code>

Getestet wurde der Code mit einem [[HM-ES-PMSw1-Pl_Funk-Schaltaktor_1-fach_mit_Leistungsmessung]]. Dabei ist waschmaschine_Pwr das Device zu Channel 2.

=== On-for-timer simulieren ===
Die on-for-timer Funktion kann für Geräte, die das nicht von Haus aus unterstützen mit folgenden Definitionen simuliert werden:

<pre>
define schalter_d dummy

define di_Schalter DOIF ([Bewegungsmelder] eq "motion" ) (set schalter_d on, set schalter_d off)
attr di_Schalter do always

define di_Licht DOIF ([schalter_d] eq "on") (set Licht on) DOELSE (set Licht off)
attr di_Licht wait 0:300
</pre>

Details dazu finden sich in {{Link2Forum|Topic=23833|Message=193660|LinkText=diesem Forenbeitrag}}.

Alternativ kann man die on-for-timer Funktion durch Verwendung von [[ReadingsProxy|readingsProxy]] simulieren, da readingsProxy-Geräte alle Funktionen der [http://fhem.de/commandref.html#setExtensions setExtension] unterstützen.

== Links ==
* {{Link2Forum|Topic=23833|LinkText=Forenthread}} zur Entstehung dieses Moduls

Anwesenheitserkennung

2014-10-02T04:10:18Z

Peterchen89: Anbindung an RESIDENTS beschrieben.

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

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

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

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

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

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

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

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

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

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

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

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

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

* '''lan-ping''' - Das überwachen via PING Checks, die durch den FHEM Server versandt werden.
* '''fritzbox''' - Das überwachen von Geräten auf einer FritzBox via ctlmgr_ctl (Nur auf einer FritzBox möglich)
* '''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äte, ü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ück gibt (0 oder 1)
* '''shell-script''' - Das überwachen mithilfe eines selbst geschriebenen Shell-Programms/Skript, das eine 0 oder 1 ausgibt, um den Anwesenheitsstatus mitzuteilen.

=== Ping-Überwachung von Geräten 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.

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

=== Bluetooth-Überwachung von Geräten durch den FHEM Server ===
[[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>

=== Bluetooth-Überwachung von Geräten durch verteilte Agenten in der Wohnung (presencd/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 (Download-Link ist in der [http://fhem.de/commandref_DE.html#PRESENCE Commandref] zum Modul enthalten) ausgestattet. Es stehen bereits entsprechende Pakete für den Raspberry zur Verfügung.

Beide Programme (presenced/collectord) 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. Nach Installation der *.deb Pakete sollten diese noch angewiesen werden, automatisch beim Rechner-Neustart gestartet zu werden:

<pre>
sudo update-rc.d presenced defaults
sudo update-rc.d collectord defaults
</pre>

Eine detaillierte Benutzung von presenced ist in der [http://fhem.de/commandref_DE.html#PRESENCE Commandref] Beschreibung zum PRESENCE Modul enthalten.

==== Jeden Raum einzeln ansprechen (presenced) ====
Nun kann zuallererst jeder Raum einzeln angesprochen werden. Dabei ist zu beachten, dass pro Definition in der Konfiguration nur ein Gerät in einem Raum spezifisch überwacht werden kann.

Eine Definition sieht dabei folgendermaßen aus:
:<code>define Handy_Wohnzimmer PRESENCE lan-bluetooth XX:XX:XX:XX:XX:XX 192.168.0.10:5111</code>

Damit wird nun das Gerät nur im Wohnzimmer (Raspberry mit IP 192.168.0.10) überwacht.

==== Alle Räume gemeinsam ansprechen (collectord) ====
Um jedoch alle Räume gemeinsam zu verwenden, gibt es den Collector-Daemon. 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.

Um alle Räume zu kennen, müssen diese mit einem Config-File dem collectord mitgeteilt werden. Dieses sieht folgendermaßen aus:

<pre>
[Schlafzimmer] # Name des Raumes (wird in FHEM als Reading angezeigt)
address=192.168.179.31 # IP-Adresse oder Hostname des presenced
port=5111 # TCP Port, der verwendet werden soll (standardmäßig Port 5111)
presence_timeout=120 # Prüfinterval, das verwendet werden soll, wenn ein Gerät anwesend ist
absence_timeout=20 # Prüfinterval, das verwendet werden soll, wenn ein Gerät abwesend ist

[Wohnzimmer]
address=192.168.179.34
port=5111
presence_timeout=180
absence_timeout=20
</pre>

Mit dieser Konfiguration kann der Collectord gestartet werden. Es empfiehlt sich diesen mit auf dem FHEM Server zu betreiben. Die erforderliche Definition in der Fhem-Konfiguration:
:<code>define Handy PRESENCE lan-bluetooth XX:XX:XX:XX:XX:XX 127.0.0.1:5222</code>

Sobald das Handy irgendwo in der Wohnung erkannt wurde, meldet der Collectord dies sofort an FHEM und teilt den Raum mit.

Eine detaillierte Benutzung von collectord findet man in der Commandref zum PRESENCE Modul.

=== Überwachung von Geräten mit 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.pl einzufügen:

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

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

=== Modul in FHEM einrichten ===
Das Modul ist mit einer einfachen Definition sofort betriebsbereit:
:<code>define geofancy GEOFANCY geo</code>

Damit nimmt FHEM unter http://192.168.178.1:8083/fhem/geo entsprechende Meldungen des iPhones entgegen. Damit das nicht nur über das lokale WLAN funktioniert, bedarf es allerdings noch einiger zusätzlicher Maßnahmen. FHEM muss vom Internet erreichbar gemacht werden, dabei sollte unbedingt an die Absicherung des Zugriffs gedacht werden.

Zunächst einmal habe ich bei mir eine eigene FHEMWEB Instanz dafür angelegt:
<pre>
define WEBhook FHEMWEB 8088 global
attr WEBhook hiddenroom input,detail,save,Unsorted,Everything,CUL_HM,FS20,Commandref,style,Edit files,Select style,Logfile,Floorplans,Remote doc,FileLogs,Apartment,Bathroom,Bedroom,Kitchen,Living,Residents,System,Weather,Event monitor,NEW
attr WEBhook room hidden
attr WEBhook webname webhook
</pre>

Damit ist unter der URL http://192.168.178.1:8088/webhook/geo das GEOFANCY Modul erreichbar. Ich verstecke in dieser Ansicht noch alle Räume, die ich so habe. Wer die Raumnamen allerdings kennt, kann sie trotzdem aufrufen. Auch wenn das Security-by-Obscurity ist - ich fühle mich wohler damit.

Mit dem neuen Attribut allowedCommands lässt sich diese FHEMWEB Instanz noch weiter absichern indem nur die tatsächlich benötigten Kommandos erlaubt werden (in diesem Fall keine) und damit alle anderen nicht erlaubten (attr,define,get,set,...) automatisch nicht mehr zur Verfügung stehen:
<code>attr WEBhook allowedCommands ,</code>

=== Webhook weiter absichern ===
Außerdem ist dringend zu empfehlen, den Zugriff über SSL und HTTP Basic-Authentication weiter abzusichern. Läuft FHEM auf einem RaspberryPi, dann empfehle ich dazu die Konfiguration eines ReverseProxy (z.B. nginx oder Apache), damit ist man am flexibelsten und kann auch alle FHEMWEB Instanzen direkt über einen einzigen Port (meist 443, der HTTPS/SSL Standard Port) zusammenfassen. Ich möchte hier allerdings beschreiben, wie weit man mit FHEM Bordmitteln kommt und nehme das Beispiel einer Installation auf einer Fritzbox.

Wie SSL aktiviert wird, steht in der [http://fhem.de/commandref.html#FHEMWEB Commandref für FHEMWEB]. Um die Kommandos auf der Fritzbox ausführen zu können, muss zuerst Telnet aktiviert werden (bitte Google benutzen). Anschließend wechselt man auf der Fritzbox ins Verzeichnis /var/media/ftp/fhem und kann dann den Hinweisen aus der [http://fhem.de/commandref.html#FHEMWEB Commandref] unter dem Punkt HTTPS folgen. Letztlich fehlt noch das entsprechende Attribut:

<pre>
attr WEBhook HTTPS
</pre>

Als nächstes aktivieren wir Benutzername+Passwort für den Zugriff. Die [http://fhem.de/commandref.html#FHEMWEB Commandref für FHEMWEB] gibt auch hier unter dem Punkt basicAuth entsprechende Hinweise. Wir fügen hier einfach mal einen Benutzer "webhook" mit dem Passwort "Geofancy" hinzu, das sieht dann so aus:

<pre>
attr WEBhook basicAuth { "$user:$password" eq "webhook:Geofancy" }
</pre>

Weitere Infos zur Absicherung gibt auch [[FritzBox Webzugriff absichern]].

Um zu testen, ob unsere Absicherung erfolgreich war, kann man die URL https://192.168.178.1:8088/webhook/geo aufrufen (wichtig ist, dass man jetzt https und nicht mehr http eingibt; ansonsten bekommt man keine Antwort). Eine Zertifikatswarnung kann getrost ignoriert werden, verschlüsselt wird trotzdem. Es sollte auch eine Passwort Abfrage kommen und die Eingabe der entsprechenden Daten sollte dann zu einer entsprechenden Meldung vom GEOFANCY Modul führen:

<pre>
NOK No data received, see API information on http://wiki.geofancy.com
</pre>

Das ist ok, schließlich sind wir keine App, sondern der Mensch, der nur mal eben prüfen will :-)

=== Zugriff vom Internet ermöglichen ===
Das ist je nach Fritzbox und Software Version unterschiedlich. Grundsätzlich gilt: Eine Weiterleitung des ports 8088 vom Internet auf das laufende FHEM auf Port 8088 intern ist von AVM so nicht vorgesehen.
Bei mir führte folgendes zum Erfolg:

* Einloggen per Telnet auf der Fritzbox (ich habe FritzOS 6 installiert)
* Konfiguration editieren mittels "nvi /var/flash/ar7.cfg"
* Suchen nach richtiger Zeile durch Eingabe von "/internet_forwardrules" und Enter
* Hinzufügen einer weiteren Zeile (Vorsicht, die bestehende Zeile endet mit ; und das muss in , umgeändert werden, so dass das ; schließlich am Ende der Zeile steht.

So sieht es bei mir vorher aus:
:<code>internet_forwardrules = "tcp 0.0.0.0:488 0.0.0.0:488 0";</code>
Hinterher:
:<code>internet_forwardrules = "tcp 0.0.0.0:488 0.0.0.0:488 0", "tcp 0.0.0.0:8088 0.0.0.0:8088 0";</code>

Danach mittels ":x" abspeichern und sofort per "reboot" die Box neu starten, um diese Änderungen zu aktivieren. Das ist wichtig; ansonsten zeigt die Erfahrung, dass die Änderung nicht dauerhaft erhalten bleibt und die gerade gemachten Änderungen verloren gehen.

Wer die Einstellungen zu "internet_forwardrules" bei sich nicht finden kann, hat womöglich eine andere Version als ich oder ein leicht anderes Gerät und bemüht am besten Google, was er tun kann, um das Gleiche zu erreichen. Möglicherweise tauchen die Einträge auch erst auf, wenn man mal über das Webinterface ein Forwarding eingerichtet hatte.

Hat man einen DynDNS Dienst oder myFritz auf der Fritzbox aktiviert, so kann man jetzt auch von draußen auf den Webhook zugreifen. Das kann man prüfen, indem man das iPhone aus dem WLAN ausbucht und einmal die externe Adresse eingibt, also z.B. https://meindyndns.org:8088/webhook/geo.

=== Einrichten in der Geof[e|a]ncy.app ===
Hat das alles soweit geklappt, können endlich in der Geofency.app bzw. Geofancy.app am iPhone die gewünschten Bereiche definiert werden. Am Besten zuvor in den Global Settings die folgenden Einstellungen hinterlegen:

* URL: https://meindyndns.org:8088/webhook/geo
* POST (oder GET, ist egal - das FHEM Modul kann beides)
* HTTP Basic Authentication: EIN (entsprechend Username und Password eintragen)

Anfänglich ist es empfehlenswert noch "Notification on success" und "Notification on Failure" einzuschalten. Ersteres kann man ausmachen wenn man weiß, dass es soweit funktioniert. Über "Send Test-Request" kann man einmal einen Test schicken und erhält das Ergebnis entsprechend dargestellt. Es sollte sowas kommen wie
:<code>POST Success: test OK</code>. In Geofancy.app gibt es keine Rückmeldung über den Erfolg des Testrequests. In FHEM sollten sich durch den Testrequest jedoch die Readings sofort aktualisieren (Ggf. ist ein Reload der FHEMWEB-Seite nötig da zusätzliche Tabellenzeilen nicht via Longpoll ergänzt werden).

Funktioniert das soweit, kann man eine neue Lokation als sein Zuhause anlegen. Es empfiehlt sich einen ID-Namen zu setzen; dieser ist dann in FHEM als Name für die Lokation sichtbar. Für die eigene Wohnung empfiehlt sich hier "home" (da dies auch direkt vom RESIDENTS Modul so verwendet werden kann). Man kann auch Trigger für andere Standorte anlegen. FHEM weiß dann sogar, wenn ihr im Büro seid und könnte sich dabei auch unterschiedlich verhalten, als wenn ihr "auf Achse" seid. Bei letzterem ist der Status im GEOFANCY Modul "underway", was so viel heißt wie "unbekannter Aufenthaltsort".

Hinweis: Zumindest für Geofancy.app liefert ein Testrequest wohl zufällige Locations zurück. Die eigenen Location-IDs werden also nicht übergeben, selbst wenn man sich in einem Geofence befindet. Um zu testen muss man sich wohl oder übel selbst bewegen ;-).

=== GEOFANCY Modul individualisieren ===
Die im GEOFANCY Modul dargestellten Readings sind nun in etwa so, wenn ihr euch bewegt:

<pre>
Readings:
2014-01-18 14:37:42 51F23894-AAAA-BBBB-CCCC-0123456789AB arrived home
2014-01-18 14:37:42 currLocLat_51F23894-AAAA-BBBB-CCCC-0123456789AB 48.9999
2014-01-18 14:37:42 currLocLong_51F23894-AAAA-BBBB-CCCC-0123456789AB 11.9999
2014-01-18 14:37:42 currLocTime_51F23894-AAAA-BBBB-CCCC-0123456789AB 2014-01-18 14:37:42
2014-01-18 14:37:42 currLoc_51F23894-AAAA-BBBB-CCCC-0123456789AB home
2014-01-17 19:18:23 lastArr 51F23894-AAAA-BBBB-CCCC-0123456789AB home
2014-01-17 18:41:46 lastDep 51F23894-AAAA-BBBB-CCCC-0123456789AB Office
2014-01-18 14:37:42 lastDevice 51F23894-AAAA-BBBB-CCCC-0123456789AB
2014-01-17 18:41:46 lastLocArr_51F23894-AAAA-BBBB-CCCC-0123456789AB 2014-01-17 08:58:37
2014-01-17 18:41:46 lastLocDep_51F23894-AAAA-BBBB-CCCC-0123456789AB 2014-01-17 18:41:46
2014-01-17 18:41:46 lastLocLat_51F23894-AAAA-BBBB-CCCC-0123456789AB 48.1111
2014-01-17 18:41:46 lastLocLong_51F23894-AAAA-BBBB-CCCC-0123456789AB 11.1111
2014-01-17 18:41:46 lastLoc_51F23894-AAAA-BBBB-CCCC-0123456789AB Office
2014-01-18 14:37:42 state dev:51F23894-AAAA-BBBB-CCCC-0123456789AB trig:test id:home lat:48.9999 long:11.9999
</pre>

Wer genauer hinschaut sieht: Mein iPhone heißt wohl 51F23894-AAAA-BBBB-CCCC-0123456789AB. Das ist sehr unübersichtlich. Wir setzen deshalb einen Alias-Namen für das Gerät. Sinnvoll erscheint mir der Vorname des Besitzers:
:<code>attr geofancy devAlias 51F23894-AAAA-BBBB-CCCC-0123456789AB:Julian</code>

Weitere Alias-Namen können mit Leerzeichen einfach angehängt werden.
Die alten Readings löschen wir mit
:<code>set geofancy clear readings</code>

Jetzt sehen die Readings schon viel freundlicher aus:
<pre>
Readings:
2014-01-18 14:37:42 Julian arrived home
2014-01-18 14:37:42 currLocLat_Julian 48.9999
2014-01-18 14:37:42 currLocLong_Julian 11.9999
2014-01-18 14:37:42 currLocTime_Julian 2014-01-18 14:37:42
2014-01-18 14:37:42 currLoc_Julian home
2014-01-17 19:18:23 lastArr Julian home
2014-01-17 18:41:46 lastDep Julian Office
2014-01-18 14:37:42 lastDevice Julian
2014-01-17 18:41:46 lastLocArr_Julian 2014-01-17 08:58:37
2014-01-17 18:41:46 lastLocDep_Julian 2014-01-17 18:41:46
2014-01-17 18:41:46 lastLocLat_Julian 48.1111
2014-01-17 18:41:46 lastLocLong_Julian 11.1111
2014-01-17 18:41:46 lastLoc_Julian Office
2014-01-18 14:37:42 state dev:Julian trig:test id:home lat:48.9999 long:11.9999
</pre>

Möchte man nun etwas bestimmtes tun, wenn man nach Hause kommt oder das Heim verlässt, kann man am Besten ein entsprechendes Notify auf das Reading currLog_Name setzen. Ich aktualisiere lediglich zwei Dummies, durch die dann alle weiteren Notifies ausgelöst werden:

<pre>
define n_Julian.Presence notify geofancy:currLoc_Julian:.home set Julian.homestatus home
attr n_Julian.Presence room Residents
define n_Julian.absence notify geofancy:currLoc_Julian:.underway {\
if (Value("Julian.homestatus") ne "gone" && Value("Julian.homestatus") ne "absent") {\
fhem("set Julian.homestatus absent");;\
}
define n_Julian.whereabout notify geofancy:currLoc_Julian:.* set Julian.whereabout $EVTPART1
</pre>

Wer es noch einfacher möchte (bzw. auch noch mehr Features) schaut sich einmal die neue Modulfamilie aus RESIDENTS[http://fhem.de/commandref_DE.html#RESIDENTS], ROOMMATE[http://fhem.de/commandref_DE.html#ROOMMATE] und GUEST[http://fhem.de/commandref_DE.html#GUEST] an. Diese sind direkt auf GEOFANCY abgestimmt.

Zur Anbindung von GEOFANCY zu RESIDENTS reicht in der Regel schon ein einfaches notify: <code>define n_rr_Julian.location notify geofancy:currLoc_Julian.* set rr_Julian location $EVTPART1</code>. Wobei "Julian" dabei als devAlias in GEOFANCY eingtragen wurde, rr_Julian der Name des ROOMMATE aus RESIDENTS ist. Außerdem sind die Location-IDs in der Geofency.app bzw. Geofancy.app so gewählt wurde, dass diese direkt einem ROOMMATE-Status entsprechen (also z.B. home, wayhome...).

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

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

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

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

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

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

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

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

Anwesenheitserkennung

2014-10-02T04:03:41Z

Peterchen89: Hinweise zu Geofancy.app ergänzt. "Ich" entfernt

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

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

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

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

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

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

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

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

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

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

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

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

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

* '''lan-ping''' - Das überwachen via PING Checks, die durch den FHEM Server versandt werden.
* '''fritzbox''' - Das überwachen von Geräten auf einer FritzBox via ctlmgr_ctl (Nur auf einer FritzBox möglich)
* '''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äte, ü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ück gibt (0 oder 1)
* '''shell-script''' - Das überwachen mithilfe eines selbst geschriebenen Shell-Programms/Skript, das eine 0 oder 1 ausgibt, um den Anwesenheitsstatus mitzuteilen.

=== Ping-Überwachung von Geräten 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.

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

=== Bluetooth-Überwachung von Geräten durch den FHEM Server ===
[[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>

=== Bluetooth-Überwachung von Geräten durch verteilte Agenten in der Wohnung (presencd/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 (Download-Link ist in der [http://fhem.de/commandref_DE.html#PRESENCE Commandref] zum Modul enthalten) ausgestattet. Es stehen bereits entsprechende Pakete für den Raspberry zur Verfügung.

Beide Programme (presenced/collectord) 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. Nach Installation der *.deb Pakete sollten diese noch angewiesen werden, automatisch beim Rechner-Neustart gestartet zu werden:

<pre>
sudo update-rc.d presenced defaults
sudo update-rc.d collectord defaults
</pre>

Eine detaillierte Benutzung von presenced ist in der [http://fhem.de/commandref_DE.html#PRESENCE Commandref] Beschreibung zum PRESENCE Modul enthalten.

==== Jeden Raum einzeln ansprechen (presenced) ====
Nun kann zuallererst jeder Raum einzeln angesprochen werden. Dabei ist zu beachten, dass pro Definition in der Konfiguration nur ein Gerät in einem Raum spezifisch überwacht werden kann.

Eine Definition sieht dabei folgendermaßen aus:
:<code>define Handy_Wohnzimmer PRESENCE lan-bluetooth XX:XX:XX:XX:XX:XX 192.168.0.10:5111</code>

Damit wird nun das Gerät nur im Wohnzimmer (Raspberry mit IP 192.168.0.10) überwacht.

==== Alle Räume gemeinsam ansprechen (collectord) ====
Um jedoch alle Räume gemeinsam zu verwenden, gibt es den Collector-Daemon. 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.

Um alle Räume zu kennen, müssen diese mit einem Config-File dem collectord mitgeteilt werden. Dieses sieht folgendermaßen aus:

<pre>
[Schlafzimmer] # Name des Raumes (wird in FHEM als Reading angezeigt)
address=192.168.179.31 # IP-Adresse oder Hostname des presenced
port=5111 # TCP Port, der verwendet werden soll (standardmäßig Port 5111)
presence_timeout=120 # Prüfinterval, das verwendet werden soll, wenn ein Gerät anwesend ist
absence_timeout=20 # Prüfinterval, das verwendet werden soll, wenn ein Gerät abwesend ist

[Wohnzimmer]
address=192.168.179.34
port=5111
presence_timeout=180
absence_timeout=20
</pre>

Mit dieser Konfiguration kann der Collectord gestartet werden. Es empfiehlt sich diesen mit auf dem FHEM Server zu betreiben. Die erforderliche Definition in der Fhem-Konfiguration:
:<code>define Handy PRESENCE lan-bluetooth XX:XX:XX:XX:XX:XX 127.0.0.1:5222</code>

Sobald das Handy irgendwo in der Wohnung erkannt wurde, meldet der Collectord dies sofort an FHEM und teilt den Raum mit.

Eine detaillierte Benutzung von collectord findet man in der Commandref zum PRESENCE Modul.

=== Überwachung von Geräten mit 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.pl einzufügen:

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

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

=== Modul in FHEM einrichten ===
Das Modul ist mit einer einfachen Definition sofort betriebsbereit:
:<code>define geofancy GEOFANCY geo</code>

Damit nimmt FHEM unter http://192.168.178.1:8083/fhem/geo entsprechende Meldungen des iPhones entgegen. Damit das nicht nur über das lokale WLAN funktioniert, bedarf es allerdings noch einiger zusätzlicher Maßnahmen. FHEM muss vom Internet erreichbar gemacht werden, dabei sollte unbedingt an die Absicherung des Zugriffs gedacht werden.

Zunächst einmal habe ich bei mir eine eigene FHEMWEB Instanz dafür angelegt:
<pre>
define WEBhook FHEMWEB 8088 global
attr WEBhook hiddenroom input,detail,save,Unsorted,Everything,CUL_HM,FS20,Commandref,style,Edit files,Select style,Logfile,Floorplans,Remote doc,FileLogs,Apartment,Bathroom,Bedroom,Kitchen,Living,Residents,System,Weather,Event monitor,NEW
attr WEBhook room hidden
attr WEBhook webname webhook
</pre>

Damit ist unter der URL http://192.168.178.1:8088/webhook/geo das GEOFANCY Modul erreichbar. Ich verstecke in dieser Ansicht noch alle Räume, die ich so habe. Wer die Raumnamen allerdings kennt, kann sie trotzdem aufrufen. Auch wenn das Security-by-Obscurity ist - ich fühle mich wohler damit.

Mit dem neuen Attribut allowedCommands lässt sich diese FHEMWEB Instanz noch weiter absichern indem nur die tatsächlich benötigten Kommandos erlaubt werden (in diesem Fall keine) und damit alle anderen nicht erlaubten (attr,define,get,set,...) automatisch nicht mehr zur Verfügung stehen:
<code>attr WEBhook allowedCommands ,</code>

=== Webhook weiter absichern ===
Außerdem ist dringend zu empfehlen, den Zugriff über SSL und HTTP Basic-Authentication weiter abzusichern. Läuft FHEM auf einem RaspberryPi, dann empfehle ich dazu die Konfiguration eines ReverseProxy (z.B. nginx oder Apache), damit ist man am flexibelsten und kann auch alle FHEMWEB Instanzen direkt über einen einzigen Port (meist 443, der HTTPS/SSL Standard Port) zusammenfassen. Ich möchte hier allerdings beschreiben, wie weit man mit FHEM Bordmitteln kommt und nehme das Beispiel einer Installation auf einer Fritzbox.

Wie SSL aktiviert wird, steht in der [http://fhem.de/commandref.html#FHEMWEB Commandref für FHEMWEB]. Um die Kommandos auf der Fritzbox ausführen zu können, muss zuerst Telnet aktiviert werden (bitte Google benutzen). Anschließend wechselt man auf der Fritzbox ins Verzeichnis /var/media/ftp/fhem und kann dann den Hinweisen aus der [http://fhem.de/commandref.html#FHEMWEB Commandref] unter dem Punkt HTTPS folgen. Letztlich fehlt noch das entsprechende Attribut:

<pre>
attr WEBhook HTTPS
</pre>

Als nächstes aktivieren wir Benutzername+Passwort für den Zugriff. Die [http://fhem.de/commandref.html#FHEMWEB Commandref für FHEMWEB] gibt auch hier unter dem Punkt basicAuth entsprechende Hinweise. Wir fügen hier einfach mal einen Benutzer "webhook" mit dem Passwort "Geofancy" hinzu, das sieht dann so aus:

<pre>
attr WEBhook basicAuth { "$user:$password" eq "webhook:Geofancy" }
</pre>

Weitere Infos zur Absicherung gibt auch [[FritzBox Webzugriff absichern]].

Um zu testen, ob unsere Absicherung erfolgreich war, kann man die URL https://192.168.178.1:8088/webhook/geo aufrufen (wichtig ist, dass man jetzt https und nicht mehr http eingibt; ansonsten bekommt man keine Antwort). Eine Zertifikatswarnung kann getrost ignoriert werden, verschlüsselt wird trotzdem. Es sollte auch eine Passwort Abfrage kommen und die Eingabe der entsprechenden Daten sollte dann zu einer entsprechenden Meldung vom GEOFANCY Modul führen:

<pre>
NOK No data received, see API information on http://wiki.geofancy.com
</pre>

Das ist ok, schließlich sind wir keine App, sondern der Mensch, der nur mal eben prüfen will :-)

=== Zugriff vom Internet ermöglichen ===
Das ist je nach Fritzbox und Software Version unterschiedlich. Grundsätzlich gilt: Eine Weiterleitung des ports 8088 vom Internet auf das laufende FHEM auf Port 8088 intern ist von AVM so nicht vorgesehen.
Bei mir führte folgendes zum Erfolg:

* Einloggen per Telnet auf der Fritzbox (ich habe FritzOS 6 installiert)
* Konfiguration editieren mittels "nvi /var/flash/ar7.cfg"
* Suchen nach richtiger Zeile durch Eingabe von "/internet_forwardrules" und Enter
* Hinzufügen einer weiteren Zeile (Vorsicht, die bestehende Zeile endet mit ; und das muss in , umgeändert werden, so dass das ; schließlich am Ende der Zeile steht.

So sieht es bei mir vorher aus:
:<code>internet_forwardrules = "tcp 0.0.0.0:488 0.0.0.0:488 0";</code>
Hinterher:
:<code>internet_forwardrules = "tcp 0.0.0.0:488 0.0.0.0:488 0", "tcp 0.0.0.0:8088 0.0.0.0:8088 0";</code>

Danach mittels ":x" abspeichern und sofort per "reboot" die Box neu starten, um diese Änderungen zu aktivieren. Das ist wichtig; ansonsten zeigt die Erfahrung, dass die Änderung nicht dauerhaft erhalten bleibt und die gerade gemachten Änderungen verloren gehen.

Wer die Einstellungen zu "internet_forwardrules" bei sich nicht finden kann, hat womöglich eine andere Version als ich oder ein leicht anderes Gerät und bemüht am besten Google, was er tun kann, um das Gleiche zu erreichen. Möglicherweise tauchen die Einträge auch erst auf, wenn man mal über das Webinterface ein Forwarding eingerichtet hatte.

Hat man einen DynDNS Dienst oder myFritz auf der Fritzbox aktiviert, so kann man jetzt auch von draußen auf den Webhook zugreifen. Das kann man prüfen, indem man das iPhone aus dem WLAN ausbucht und einmal die externe Adresse eingibt, also z.B. https://meindyndns.org:8088/webhook/geo.

=== Einrichten in der Geof[e|a]ncy.app ===
Hat das alles soweit geklappt, können endlich in der Geofency.app bzw. Geofancy.app am iPhone die gewünschten Bereiche definiert werden. Am Besten zuvor in den Global Settings die folgenden Einstellungen hinterlegen:

* URL: https://meindyndns.org:8088/webhook/geo
* POST (oder GET, ist egal - das FHEM Modul kann beides)
* HTTP Basic Authentication: EIN (entsprechend Username und Password eintragen)

Anfänglich ist es empfehlenswert noch "Notification on success" und "Notification on Failure" einzuschalten. Ersteres kann man ausmachen wenn man weiß, dass es soweit funktioniert. Über "Send Test-Request" kann man einmal einen Test schicken und erhält das Ergebnis entsprechend dargestellt. Es sollte sowas kommen wie
:<code>POST Success: test OK</code>. In Geofancy.app gibt es keine Rückmeldung über den Erfolg des Testrequests. In FHEM sollten sich durch den Testrequest jedoch die Readings sofort aktualisieren (Ggf. ist ein Reload der FHEMWEB-Seite nötig da zusätzliche Tabellenzeilen nicht via Longpoll ergänzt werden).

Funktioniert das soweit, kann man eine neue Lokation als sein Zuhause anlegen. Es empfiehlt sich einen ID-Namen zu setzen; dieser ist dann in FHEM als Name für die Lokation sichtbar. Für die eigene Wohnung empfiehlt sich hier "home" (da dies auch direkt vom RESIDENTS Modul so verwendet werden kann). Man kann auch Trigger für andere Standorte anlegen. FHEM weiß dann sogar, wenn ihr im Büro seid und könnte sich dabei auch unterschiedlich verhalten, als wenn ihr "auf Achse" seid. Bei letzterem ist der Status im GEOFANCY Modul "underway", was so viel heißt wie "unbekannter Aufenthaltsort".

Hinweis: Zumindest für Geofancy.app liefert ein Testrequest wohl zufällige Locations zurück. Die eigenen Location-IDs werden also nicht übergeben, selbst wenn man sich in einem Geofence befindet. Um zu testen muss man sich wohl oder übel selbst bewegen ;-).

=== GEOFANCY Modul individualisieren ===
Die im GEOFANCY Modul dargestellten Readings sind nun in etwa so, wenn ihr euch bewegt:

<pre>
Readings:
2014-01-18 14:37:42 51F23894-AAAA-BBBB-CCCC-0123456789AB arrived home
2014-01-18 14:37:42 currLocLat_51F23894-AAAA-BBBB-CCCC-0123456789AB 48.9999
2014-01-18 14:37:42 currLocLong_51F23894-AAAA-BBBB-CCCC-0123456789AB 11.9999
2014-01-18 14:37:42 currLocTime_51F23894-AAAA-BBBB-CCCC-0123456789AB 2014-01-18 14:37:42
2014-01-18 14:37:42 currLoc_51F23894-AAAA-BBBB-CCCC-0123456789AB home
2014-01-17 19:18:23 lastArr 51F23894-AAAA-BBBB-CCCC-0123456789AB home
2014-01-17 18:41:46 lastDep 51F23894-AAAA-BBBB-CCCC-0123456789AB Office
2014-01-18 14:37:42 lastDevice 51F23894-AAAA-BBBB-CCCC-0123456789AB
2014-01-17 18:41:46 lastLocArr_51F23894-AAAA-BBBB-CCCC-0123456789AB 2014-01-17 08:58:37
2014-01-17 18:41:46 lastLocDep_51F23894-AAAA-BBBB-CCCC-0123456789AB 2014-01-17 18:41:46
2014-01-17 18:41:46 lastLocLat_51F23894-AAAA-BBBB-CCCC-0123456789AB 48.1111
2014-01-17 18:41:46 lastLocLong_51F23894-AAAA-BBBB-CCCC-0123456789AB 11.1111
2014-01-17 18:41:46 lastLoc_51F23894-AAAA-BBBB-CCCC-0123456789AB Office
2014-01-18 14:37:42 state dev:51F23894-AAAA-BBBB-CCCC-0123456789AB trig:test id:home lat:48.9999 long:11.9999
</pre>

Wer genauer hinschaut sieht: Mein iPhone heißt wohl 51F23894-AAAA-BBBB-CCCC-0123456789AB. Das ist sehr unübersichtlich. Wir setzen deshalb einen Alias-Namen für das Gerät. Sinnvoll erscheint mir der Vorname des Besitzers:
:<code>attr geofancy devAlias 51F23894-AAAA-BBBB-CCCC-0123456789AB:Julian</code>

Weitere Alias-Namen können mit Leerzeichen einfach angehängt werden.
Die alten Readings löschen wir mit
:<code>set geofancy clear readings</code>

Jetzt sehen die Readings schon viel freundlicher aus:
<pre>
Readings:
2014-01-18 14:37:42 Julian arrived home
2014-01-18 14:37:42 currLocLat_Julian 48.9999
2014-01-18 14:37:42 currLocLong_Julian 11.9999
2014-01-18 14:37:42 currLocTime_Julian 2014-01-18 14:37:42
2014-01-18 14:37:42 currLoc_Julian home
2014-01-17 19:18:23 lastArr Julian home
2014-01-17 18:41:46 lastDep Julian Office
2014-01-18 14:37:42 lastDevice Julian
2014-01-17 18:41:46 lastLocArr_Julian 2014-01-17 08:58:37
2014-01-17 18:41:46 lastLocDep_Julian 2014-01-17 18:41:46
2014-01-17 18:41:46 lastLocLat_Julian 48.1111
2014-01-17 18:41:46 lastLocLong_Julian 11.1111
2014-01-17 18:41:46 lastLoc_Julian Office
2014-01-18 14:37:42 state dev:Julian trig:test id:home lat:48.9999 long:11.9999
</pre>

Möchte man nun etwas bestimmtes tun, wenn man nach Hause kommt oder das Heim verlässt, kann man am Besten ein entsprechendes Notify auf das Reading currLog_Name setzen. Ich aktualisiere lediglich zwei Dummies, durch die dann alle weiteren Notifies ausgelöst werden:

<pre>
define n_Julian.Presence notify geofancy:currLoc_Julian:.home set Julian.homestatus home
attr n_Julian.Presence room Residents
define n_Julian.absence notify geofancy:currLoc_Julian:.underway {\
if (Value("Julian.homestatus") ne "gone" && Value("Julian.homestatus") ne "absent") {\
fhem("set Julian.homestatus absent");;\
}
define n_Julian.whereabout notify geofancy:currLoc_Julian:.* set Julian.whereabout $EVTPART1
</pre>

Wer es noch einfacher möchte (bzw. auch noch mehr Features) schaut sich einmal die neue Modulfamilie aus RESIDENTS[http://fhem.de/commandref_DE.html#RESIDENTS], ROOMMATE[http://fhem.de/commandref_DE.html#ROOMMATE] und GUEST[http://fhem.de/commandref_DE.html#GUEST] an. Diese sind direkt auf GEOFANCY abgestimmt.

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

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

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

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

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

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

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

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

WakeOnLan

2014-07-03T08:33:55Z

Peterchen89: + FHEM läuft nicht als root-User.

Mittels Wake On Lan (WOL) können Computer, NAS usw. von einem anderen Netzwerk-Gerät eingeschaltet werden. Wake on LAN läuft auf der ISO/OSI-Schicht 2. Diese Pakete werden i.d.R. nicht geroutet. Ein Wake on Lan Paket kann entsprechend nur innerhalb eines Netzwerksegments versendet werden. Das zu weckende Gerät muss Wake on Lan unterstützen und es muss (bei PCs z.B. im BIOS oder im Treiber der Netzwerkkarte) eingeschaltet werden. Bei einigen Systemen steigt die Energieaufnahme im Standby bei aktiviertem WOL von unter 1 W auf mehrere W pro Stunde.

== Ermitteln der MAC-Adresse ==

Zunächst muss die MAC-Adresse des zu weckenden Gerätes ermittelt werden.
Auf dem Gerät selber:
* Auf einem Windows-PC in einer Shell den Befehl „ipconfig /all“ eingeben
* Auf einem Linux-PC in einer Shell den Befehl „ifconfig“ eingeben
Von einem anderen Gerät
* Auf einem Windows-PC in einer Shell den Befehl „arp -a“ eingeben
* Auf einem Linux-PC in einer Shell den Befehl „arp -a“ eingeben

== OpenWRT ==

Das Wake on Lan Paket kann mit dem Programm ''etherwake'' erzeugt werden.

<nowiki>opkg update
opkg install etherwake</nowiki>

Test: In der Shell folgenden Befehl eingeben (die MAC-Adresse muss natürlich angepasst werden das Interface (hier br-lan) eventuell auch):
<nowiki>etherwake -i br-lan 00:06:55:5a:53:f3</nowiki>
Das Gerät sollte jetzt einschalten.

Funktion in der Datei ''[[99_myUtils_anlegen|99-myUtils.pm]]'' erstellen.

<nowiki>######## WakeOnLan von OpenWRT ############
sub
WakeOnLan
{
my $mac = shift;
my $ret = "";
$ret .= qx(etherwake -i br-lan $mac);
$ret =~ s,[\r\n]*,,g; # remove CR from return-string
Log 1, "sendEmail to $mac: $ret";
}</nowiki>

Test: Im FHEM-Webinterface ''{ WakeOnLan('00:06:55:5a:53:f3');; }'' eingeben.

Um auf einen Tasterdruck reagieren zu können, muss die Datei fhem.cfg ergänzt werden:
<nowiki>define HM_Taster_01.ntfy notify HM_Taster_01.* {WakeOnLan('00:17:31:fa:9b:51')}</nowiki>

'''Achtung:''' Wenn FHEM nicht als root-Benutzer sondern als normaler Benutzer gestartet wird, wird etherwake nicht direkt funktionieren:
<nowiki>
fhem@XXX:/opt/fhem$ etherwake C8:CD:72:01:FF:FF
etherwake: This program must be run as root.</nowiki>

FHEM muss nun also etherwake irgendwie mit root-Rechten starten können. Sehr einfach kann man das erreichen, indem man das SETUID-Flag auf /usr/sbin/etherwake setzt. Das führt dazu, dass das Programm immer mit dem Benutzer ausgeführt wird dem es gehört. Da das Programm nach der Installation normalerweise root gehört, haben wir mit einem einfachen chmod +s /usr/sbin/etherwake also schon unser Ziel erreicht.
[[Kategorie:Code Snippets]]