FHEMWiki - Benutzerbeiträge [de]

Homebridge einrichten

2025-12-19T08:49:45Z

Motivierte linke Hände: Installationshinweise aktualisiert

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 Raspbian getestet). Der Wiki-Eintrag bezieht sich hauptsächlich auf eine {{Link2Forum|Topic=32652|LinkText=Diskussion im FHEM-Forum}}. Ein Riesendank gilt vor allem {{Link2FU|430|Andre (justme1968)}}.

Die Konfiguration der inzwischen aktuellen zweiten Version des Homekit-Plugins ist in einem neuen {{Link2Forum|Topic= 48558 |LinkText=Thread im FHEM-Forum}} beschrieben. Hinzugekommen ist vor allem die freie Konfigurierbarkeit der Zuordnung zwischen FHEM Device und Homekit Accessory/Service, zwischen FHEM Reading und Homekit Characteristic, das mapping vom FHEM Readingwerten zu Homekit Werten sowie das Mapping von Homekit Werten zu FHEM Set-Kommandos und Werten.

Eine Sammlung funktionsfähiger Homebridge FHEM Konfigurationen kann hier gefunden werden: [[Homebridge User Configs]]. Die Sammlung befindet sich noch im Aufbau.

= Aktuelle Systeme =
Für aktuelle Systeme ist die Installation recht simpel:

Für Debian-basierte Systeme (Debian, Ubuntu, Raspbian, etc.) fügt man das Homebridge-Repository dem eigenen System hinzu, installierte homebridge und loggt sich dann auf dem UI ein. Anschließend installiert man über das UI homebridge-fhem und richtet dann beides in Homekit ein. Die Details stehen unten.

Für andere Systeme gibt es Installationshinweise [https://github.com/homebridge/homebridge auf Github].

== Homebridge installieren (Debian-basierte Systeme) ==
Key hinzufügen:<syntaxhighlight lang="console">
curl -sSfL https://repo.homebridge.io/KEY.gpg | sudo gpg --dearmor | sudo tee /usr/share/keyrings/homebridge.gpg > /dev/null
</syntaxhighlight>Repository hinzufügen:<syntaxhighlight lang="console">
echo "deb [signed-by=/usr/share/keyrings/homebridge.gpg] https://repo.homebridge.io stable main" | sudo tee /etc/apt/sources.list.d/homebridge.list > /dev/null
</syntaxhighlight>Homebridge installieren:<syntaxhighlight lang="console">
sudo apt update && apt install homebridge
</syntaxhighlight>Anschließend sollte Homebridge laufen und ein Login auf dem Webinterface möglich sein:<syntaxhighlight lang="console">
http://<ip-des-Systems>:8581
</syntaxhighlight>

== Homebridge FHEM installieren ==
Im Hombridge-Webinterface auf der linken Seite "Plugins" auswählen. Unter den Plugins nach "FHEM" suchen, dann von dort Homebridge FHEM installieren.

Es empfiehlt sich außerdem, in FHEM ein siri Device anzulegen:<syntaxhighlight lang="console">
define siri siri
</syntaxhighlight>Sicherheitshalber Homebridge über das Webinterface an dieser Stelle neu starten.

== Homebridge und Homebridge FHEM in Homekit einrichten ==
Im Homebridge Webinterface gibt es auf der Status-Seite einen QR-Code. Dieser muss mit Homekit ("Gerät hinzufügen") gescannt werden, um Homebridge zu Homekit hinzuzufügen.

Außerdem gibt es in den "Bridge-Einstellungen" zu Homebridge FHEM (erreichbar über die senkrechten drei Punkte auf der Plugins-Seite) einen QR-Code für Homebridge FHEM. Auch dieser muss mit Homekit ("Gerät hinzufügen") gescannt werden.

In den "Einstellungen" (nicht "Bridge-Einstellungen") zu Homebridge FHEM (auch erreichbar über die senkrechten drei Punkte auf der Plugins-Seite) kann man einen "Filter" konfigurieren. Alle in FHEM konfigurierten Geräte, die auf diesen Filter passen, werden dann in Homekit sichtbar. Ich nutze dabei nach wie vor einen alten Filter, der alle dem Raum "Cfg_Homekit" zugeordneten Geräte für Homekit selektiert:<syntaxhighlight lang="console">
room=Cfg_Homekit
</syntaxhighlight>Jetzt sollte Homebridge laufen (auch automatisch starten) und die ausgewählten Geräte in Homekit erscheinen. Ab jetzt gilt es nur noch, diese einzeln zu konfigurieren und damit in Homekit auch nutzbar zu machen. [[Homebridge_User_Configs]] kann dabei sehr hilfreich sein.

= Für ältere Systeme oder manuellere Installationen =
Für ältere Systeme und manuellere Installationsmethoden nachfolgend die älteren Setup-Anweisungen aus diesem Wiki: Diese Vorgehensweise wurde auf einem Intel NUC mit Ubuntu Server 14.04 LTS und auf einem Raspberry Pi mit Raspbian getestet

= Vorbereitung der Umgebung =

== NodeJS installieren ==
''Die nachfolgenden Befehle sind alle mit "sudo" prefixed. Wenn du unter "root" arbeitest oder deine Distribution einen anderen Mechanismus verwendet, so kannst du dies natürlich weglassen.''

Zunächst wird das Betriebssystem (in diesem Falle Debian oder Ubuntu) auf den aktuellen Stand gebracht:
<syntaxhighlight lang="bash" style="width:50%;">
sudo apt-get update
sudo apt-get upgrade
sudo apt-get install build-essential libssl-dev</syntaxhighlight>

Nun muss NodeJS installiert werden. Leider ist die Version im Debian Repository deutlich zu alt, daher wird mit den folgenden Befehlen das Node Repository hinzugefügt und NodeJS (in der LTS Version) entsprechend installiert:

'''NodeJS V4'''
<syntaxhighlight lang="bash" style="width:50%;">
curl -sL https://deb.nodesource.com/setup_4.x | sudo -E bash -
sudo apt-get install -y nodejs
</syntaxhighlight>

{{Randnotiz|RNTyp=y|RNText=Bei Installation von NodeJS auf einem "alten" RasPi (B) bitte die besonderen Hinweise in {{Link2Forum|Topic=32652|Message=419325|LinkText=diesem Forenbeitrag}} beachten.}}
'''NodeJS V5'''
<syntaxhighlight lang="bash" style="width:50%">
curl -sL https://deb.nodesource.com/setup_5.x | sudo -E bash -
sudo apt-get install -y nodejs
</syntaxhighlight>

'''NodeJS V6'''
<syntaxhighlight lang="bash" style="width:50%">
curl -sL https://deb.nodesource.com/setup_6.x | sudo -E bash -
sudo apt-get install -y nodejs
</syntaxhighlight>

'''NodeJS V11'''
<syntaxhighlight lang="bash" style="width:50%">
curl -sL https://deb.nodesource.com/setup_11.x | sudo -E bash -
sudo apt-get install -y nodejs
</syntaxhighlight>

Bei Ubunutu ist es noch nötig apt-get wie folgt auszuführen.
<syntaxhighlight lang="bash" style="width:50%">
sudo apt-get install -y nodejs
</syntaxhighlight>

Damit ist NodeJS installiert.

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

Nun sind alle Voraussetzungen geschaffen.

= Installation von Homebridge & notwendiger Shims =
Im nachfolgenden Absatz wird die Installation von Homebridge sowie des notwendigen Plugins (Shim) für FHEM erläutert.
Eventuell muss vor die Befehle ein
<syntaxhighlight lang="bash" style="width:50%;">
sudo
</syntaxhighlight>
vorangestellt werden.
== Homebridge installieren ==
Die aktuelle Homebridge version wird mit
<syntaxhighlight lang="bash" style="width:50%;">
npm install -g --unsafe-perm homebridge
</syntaxhighlight>
installiert, was eine Weile dauert. Anschließend wird der FHEM platform shim mit:
<syntaxhighlight lang="bash" style="width:60%;">
npm install -g homebridge-fhem
</syntaxhighlight>
installiert.

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

Kommt eine DNS Fehlermeldung fehlt meistens der AVAHI-DAEMON, zu installieren via
<syntaxhighlight lang="bash" style="width=50%">
sudo apt-get install avahi-daemon
</syntaxhighlight>

Wenn npm beim Kompilieren von mdns mit der Meldung abbricht, dass "dns_sd.h" nicht gefunden wird, fehlt das Paket libavahi-compat-libdnssd-dev, zu installieren via
<syntaxhighlight lang="bash" style="width=50%">
sudo apt-get install libavahi-compat-libdnssd-dev
</syntaxhighlight>

== Homebridge aktualisieren ==
Prüfen, ob es Updates gibt:
<syntaxhighlight lang="bash" style="width:50%;">
npm -g outdated
</syntaxhighlight>
Die aktuelle Homebridge version wird mit
<syntaxhighlight lang="bash" style="width:50%;">
npm -g update homebridge
</syntaxhighlight>
installiert, was eine Weile dauert. Anschließend wird der FHEM platform shim mit:
<syntaxhighlight lang="bash" style="width:60%;">
npm -g update homebridge-fhem
</syntaxhighlight>
installiert.

Sollte dies nicht funktionieren, kann mit
<syntaxhighlight lang="bash" style="width:60%;">
npm -g install homebridge
</syntaxhighlight>
bzw.
<syntaxhighlight lang="bash" style="width:60%;">
npm -g install homebridge-fhem
</syntaxhighlight>
das Update installiert werden.

Um eine spezielle Version zu installieren, können die Installationsbefehle, von oben, wie folgt angepasst werden.
<syntaxhighlight lang="bash" style="width:60%;">
npm -g install homebridge-fhem@0.4.5
</syntaxhighlight>

= Homebridge konfigurieren =
''Wichtig: Für die weiteren Schritte sollte man nicht root verwenden, sondern beispielsweise einen dedizierten Nutzer für homebridge oder der Einfachheit halber den Nutzer, unter dem auch FHEM läuft (meist "fhem").''

== Einstellungen für homebridge ==
Zunächst wird das Verzeichnis für die Konfigurationsdatei erstellt und in dieses gewechselt:
<syntaxhighlight lang="bash" style="width:50%;">
mkdir -p ~/.homebridge
cd ~/.homebridge/
</syntaxhighlight>

Nun muss darin noch die config.json erstellt bzw. angepasst werden:
<syntaxhighlight lang="bash" style="width:50%;">
nano ~/.homebridge/config.json
</syntaxhighlight>

Hinweise zur Konfiguration:
* "''bridge''":
** "''username''": Sollte so belassen werden. Sollte später auf dem iOS Device keine Homebridge gefunden werden, so kann man hier beispielsweise den String auf 31 statt 30 enden lassen um so eine neue Homebridge vorzutäuschen.
** "''port''": Sollte so belassen werden
** "''pin''": Der PIN kann beliebig in dem Format xxx-xx-xxx angepasst werden. Dieser muss nur einmal bei der Einrichtung in iOS eingegeben werden.
* "''platforms''":
** "''platform''": Hier muss "FHEM" beibehalten werden.
** "''server''": Hier muss die IP des FHEM-Servers eingetragen werden. Dabei muss Homebridge nicht auf dem selben Server laufen wie FHEM, kann aber. Wenn es auf dem gleichen Rechner läuft, dann bietet es sich an, die IP 127.0.0.1 zu verwenden.
** "''port''": Hier muss der Port des gewählten FHEMWEBs eingetragen werden (muss nicht das "normale" sein, kann eine extra Instanz sein)
** "''auth''": Ist FHEM nicht mit Nutzername/Password abgesichert, so kann man diese Zeile einfach entfernen.
** "''filter''": Damit nicht alle Devices von Homebridge berücksichtigt werden, bietet es sich an, die Devices zu filtern. In diesem Beispiel wurden alle Devices, die über Siri steuerbar sein sollen, zusätzlich in den Raum Homekit konfiguriert.
<syntaxhighlight lang="json" 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": "127.0.0.1",
"port": "8083",
"auth": {"user": "FhemUser", "pass": "XXX"},
"filter": "room=Homekit"
}
],

"accessories": []
}
</syntaxhighlight>

Wenn für FHEMWEB kein user/password vergeben ist muss die "auth" Zeile weggelassen werden.
Wird FHEM mit SSL abgesichert, so muss zusätzlich in der Sektion "platforms" noch diese Zeile (nach "port") eingefügt werden:
<syntaxhighlight lang="javascript" style="width:50%;">
"ssl": true,
</syntaxhighlight>
Wenn man SSL ohne user/password benutzt, muss man "auth" Zeile einfugen, wobei die Werte weggelassen werden:
<syntaxhighlight lang="javascript" style="width:50%;">
"auth": {"user": "", "pass": ""},
</syntaxhighlight>

Natürlich kann man auch nach beliebigen anderen Kriterien filtern. z.b. nach Device TYPE, nach subtype Attribut, ... Es können mehrere FHEM platforms Abschnitte mit eigenem Filter im config file stehen (dabei das Komma zwischen den einzelnen Abschnitten nicht vergessen!) . Auch Geräte auf die mehr als ein Filterausdruck matched werden dabei nur einmal hinzugefügt.

= FHEM konfigurieren =
Es empfiehlt sich ein siri Gerät in FHEM anzulegen.
define siri siri

Die benötigten Attribute werden inzwischen beim ersten Start von homebridge-fhem automatisch auf FHEM Seite eingetragen.

Mehr zu den inzwischen verfügbaren Konfigurationsmöglichkeiten findet sich auf den github und npmjs Seiten des Plugins und im ersten Beitrag des zugehörigen Thread im {{Link2Forum|Topic= 48558 |LinkText=Diskussion im FHEM-Forum}}

= Start von Homebridge =

== Hinweis ==
Nach allen Änderungen die in FHEM gemacht werden, welche Homebridge betreffen, muss Homebridge neu gestartet werden. Wie der Neustart erfolgen muss, ist abhängig davon, wie man Homebridge gestartet hat. Bitte den entsprechenden Methoden entnehmen.

== Einmaliger Manueller Start ==
<syntaxhighlight lang="bash" style="width:50%;">
homebridge
</syntaxhighlight>

Homebridge sollte nun laufen. Hier kann man die Kommunikation nachverfolgen. Abbrechen kann das ganze mit CTRL+c (es sind dann auch keine Befehle mehr mit Siri möglich). Damit Siri auch Befehle ohne ständig offenes Terminal bearbeiten kann, bitte nächsten Punkt beachten.

=== Fehler während des Manuellen Starts ===
Kommt ein Fehler der ähnlich aussieht wie folgender, sollte zuerst die Nodesversion geprüft werden.
Die Nodes version kann durch ein System Update auf eine niedrigere Version wie benötigt gedowngraded werden
<syntaxhighlight lang="bash" style="width=50%">
Error: Module version mismatch. Expected 47, got 46.
at Error (native)
at Object.Module._extensions..node (module.js:450:18)
at Module.load (module.js:356:32)
at Function.Module._load (module.js:313:12)
at Module.require (module.js:366:17)
at require (module.js:385:17)
at Object.<anonymous> (/usr/lib/node_modules/homebridge/node_modules/mdns/lib/dns_sd.js:24:20)
at Module._compile (module.js:425:26)
at Object.Module._extensions..js (module.js:432:10)
at Module.load (module.js:356:32)
</syntaxhighlight>
Geprüft werden kann die Nodes Version mit:
<syntaxhighlight lang="bash" style="width=50%">node -v zeigt mir: v0.10.28, nodejs -v: v5.11.1</syntaxhighlight>
Hier ist die Version v0.10.28 wobei v0.12 Mindestvorraussetzung ist.
Die Installation der richtigen Nodes Version kann oben am Anhang des Wiki Artikels entnommen werden.

== Homebridge automatisch starten ==
Es gibt verschiedene Methoden, Homebridge automatisch zu starten.

=== Steuerung via FHEM ===
Auf Basis der unten stehenden ''Alternativen Methode'' wurde eine Version entwickelt, mit der man auch den Status einsehen und den Restart des Dienstes aus FHEM heraus erledigen kann. Diese Version ist auf der Seite [[Homebridge Start und Status in FHEM]] im Detail beschrieben.

=== Alternative Methode: Init-Skript ===
Dies startet homebridge als einen Service.

==== Service anlegen ====
<code>
sudo nano /etc/init.d/homebridge
</code>

Code einfügen (startet den Homebridge Server als Benutzer "pi" und nimmt an, dass sich .homebridge/config.json in seinem Homeverzeichnis unter /home/pi/ befindet):

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

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

=== Alternative Methode: systemd ===

Während das Init-Skript grundsätzlich auch mit systemd funktioniert, kann man natürlich für Homebridge auch ein systemd-Skript anlegen. Wie das geht, ist im [https://github.com/nfarina/homebridge/wiki/Running-HomeBridge-on-a-Raspberry-Pi#running-homebridge-on-bootup-systemd Wiki zu Homebridge] beschrieben.

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

Um HM-CC-RT-DN Thermostate steuern zu können, muss wie oben beschrieben folgendes attribute gesetzt werden (hier als Beispiel das Device "Heizung"):
# attr Heizung subtype thermostat
Für einen Dummy muss man den genericDeviceType setzen, also beispielsweise:
# attr Dummy genericDeviceType switch
# attr Dummy setList on off

Wie bereits vorher angemerkt: fügt man ein Device hinzu oder führt eine Änderung an einem Device durch, so sollte homebridge neu gestartet werden.

= HomeKit in iOS =

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

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

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

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

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

= Hinweise =

== Unterstützte Geräte ==
Das FHEM Plugin von {{Link2FU|430|Andre (justme1968)}} unterstützt automatisch mindestens die folgenden Geräte:

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

Über eine entsprechende Konfiguration lässt sich darüber hinaus jedes mit FHEM steuerbare Gerät auf die unterstützten Homekit-Typen abbilden.

Die aktuelle Liste und eine Beschreibung der Konfigurationsmöglichkeiten findet sich [https://www.npmjs.com/package/homebridge-fhem auf den npmjs seiten] bzw. [https://github.com/justme-1968/homebridge-fhem auf github].

Mehr zum homebridgeMapping findet sich hier: [[Alexa_und_Mappings#homebridgeMapping]]

Mehr zu den unterstützen Services und Characteristics findet sich hier: [https://github.com/homebridge/HAP-NodeJS/blob/master/src/lib/gen/HomeKit.ts]

Über eine '''history''' Characteristic lässt sich für bestimmte Service-Typen eine Eve-Kompatible history aktivieren:
... history:size=1024 ...

=== Beispiele ===

Gesammelte Beispiele funktionierender HomebridgeMappings sind hier zu finden: [[Homebridge_User_Configs]]

== Zusätzliche Plugins ==
Für manche der über FHEM steuerbaren Geräte wie z.b. MiLight, Harmony Hub, Philips Hue, Sonos,... gibt es eigene homekit plugins. Wenn immer möglich, empfiehlt es sich aber diese '''nicht''' zu verwenden, sondern die Steuerung über die FHEM-Integration zu realisieren, da
* diese in der Regel sehr viel mächtiger und frei konfigurierbar ist
* es FHEM erlaubt, als zentrale Instanz den Überblick über den aktuellen Gesamtzustand zu haben (wichtig bei Geräten, die gepollt werden)
* die Ressourcen auf den angesteuerten Geräten schont, da Werte optimal gecached werden und nur eine einzige Verbindung aufgebaut wird

== Hinweis für alte homebridge Versionen ==
UPDATE: Homebridge funktioniert mit einer kleinen Einschränkung nun auch mit node 4.0.0. Laut
[https://github.com/cflurin/homebridge-shims/wiki/Minimalist-Homebridge-on-a-Raspberry-Pi Homebridge on a Raspberry Pi] müssen die folgenden Abhängigkeiten (Dependencies) aus der '''package.json''' entfernt werden:
<pre>
"harmonyhubjs-client": "^1.1.4",
"harmonyhubjs-discover": "git+https://github.com/swissmanu/harmonyhubjs-discover.git"
</pre>

== Hinweis zur Geschwindigkeitsoptimierung auf einem Raspberry PI ==
Damit es auf einem Raspberry schneller läuft, wird darüber hinaus empfohlen, auch diverse Abhängigkeiten aus der '''package.json''' zu entfernen:
<pre>
"ad2usb": "git+https://github.com/alistairg/node-ad2usb.git#local",
"carwingsjs": "0.0.x",
"chokidar": "^1.0.5",
"eibd": "^0.3.1",
"elkington": "kevinohara80/elkington",
"harmonyhubjs-client": "^1.1.4",
"harmonyhubjs-discover": "git+https://github.com/swissmanu/harmonyhubjs-discover.git",
"lifx-api": "^1.0.1",
"lifx": "git+https://github.com/magicmonkey/lifxjs.git",
"node-hue-api": "^1.0.5",
"node-icontrol": "^0.1.4",
"node-milight-promise": "0.0.x",
"tough-cookie": "^2.0.0",
"sonos": "0.8.x",
"telldus-live": "0.2.x",
"teslams": "1.0.1",
"unofficial-nest-api": "git+https://github.com/hachidorii/unofficial_nodejs_nest.git#d8d48edc952b049ff6320ef99afa7b2f04cdee98",
"wemo": "0.2.x",
"wink-js": "0.0.5",
"komponist" : "0.1.0",
"yamaha-nodejs": "0.4.x",
</pre>

Daher zunächst ein Backup der Datei anlegen
<pre>sudo cp package.json package.json.bkp </pre>
Am einfachsten geht das Entfernen der Zeilen mit einem Editor, beispielsweise nano oder vi.
<pre>sudo nano package.json</pre>

Das config file sollte dann wie folgt aussehen: Achtung vor den letzten zwei "}" am Ende darf kein Komma sein.
<syntaxhighlight lang="json">
{
"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"
}
}
</syntaxhighlight>

== Links ==
* [https://github.com/nfarina/homebridge Github homebridge]
* [https://github.com/justme-1968/homebridge-fhem Github homebridge-fhem]
* [https://www.npmjs.com/package/homebridge NPM homebridge]
* [https://www.npmjs.com/package/homebridge-fhem NPM homebridge-fhem]

= Alternativen =
Will man nur "Hey Siri: Radio An" als Schaltbefehl senden und Homekit vermeiden, kann man auch Apple Shortcuts nutzen: [[Hey Siri Kurzbefehle, Apple Shortcuts]]

[[Kategorie:HOWTOS]]
[[Kategorie:Sprachsteuerung]]

Regulärer Ausdruck

2024-11-24T11:55:23Z

Motivierte linke Hände: Randnotiz zum veralteten Regex-Tester-Link nach Update der Links gelöscht.

Ein [[Regulärer Ausdruck]] (englisch ''regular expression'', daher auch häufig als '''''RegExp''''' oder '''''Regex''''' abgekürzt; siehe auch [https://de.wikipedia.org/wiki/Regul%C3%A4rer_Ausdruck Wikipedia]) wird im Kontext von FHEM häufig benutzt, um aus Zeichenketten oder aus dem Strom der Ereignisse anhand von Mustern und Regeln einzelne Teile bzw. Ereignisse zu extrahieren.

== Anwendung in FHEM ==
Die Notwendigkeit der Verwendung regulärer Ausdrücke ergibt sich beispielsweise bei der Definition eines [[FileLog]] (Filtern der Ereignisse) oder um aus einem mit [[HTTPMOD]] "gewonnenen" Datenstrom die relevanten Daten zu Weiterverarbeitung zu isolieren.

Einige Stellen, an denen reguläre Ausdrücke in FHEM vorkommen (wie z.B. [[FileLog]] und [[SVG]]), bieten eine Basisunterstützung bei der Definition und Verwaltung der zugehörigen Ausdrücke.

== Werkzeuge zur Erstellung Regulärer Ausdrücke ==
Insbesondere bei nur gelegentlicher Erstellung von Regulären Ausdrücken können diverse im Internet verfügbare "Tester" oder "Analyzer" wertvolle Hilfe leisten.

=== Regular Expression Tester ===
Exemplarisch wird hier auf [https://regex101.com regex101.com] und [https://regexr.com regexr.com] verwiesen, von denen insbesondere der erste auch eine "Explain" Funktion bietet, mit deren Einsatz die einzelnen Bestandteile des zu testenden regulären Ausdrucks erläutert werden. Wer einen deutschen Tester mit angegebenem Urheber sucht, findet zum Beispiel [https://regexe regexe] von Andreas Göbel. Es gibt viele andere Internetseiten, die sich mit der gleichen Thematik befassen.

==== "Execute" ====
Anhand des nebenstehenden Bildschirmfotos soll an einem einfachen Beispiel die generelle Funktionsweise derartiger Hilfsmittel erläutert werden:
;Input
:Datenstrom, der mit dem regulären Ausdruck verarbeitet werden soll; hier ein Teil (der Quelldaten) einer HTML-Seite.
;Expression
:Regulärer Ausdruck, mit dessen Hilfe aus dem Datenstrom der Wert des Feldes ''CM Status'', also in diesem Fall ''Operational'' extrahiert werden soll.
;Output
:Die einzelnen Teile des Testergebnisses. Der Ausdruck in Klammern {{Taste|([A-Za-z]+)}} stellt den Teil dar, der zur Weiterverarbeitung benutzt werden soll; der Rest dient zu Identifizierung der richtigen Stelle (hier ''Match at character 802'') innerhalb des Datenstroms.

==== "Explain" ====
[[Datei:RegExp_TestExplain.png|mini|400px|right|Regular Expression Tester, Explain]]
Der oben beschriebene ''Regular Expression Tester'' bietet über die Schaltfläche ''Explain'' auch eine Erläuterungsfunktion. Ebenfalls am obigen Beispiel wird im Bildschirmfoto wieder dargestellt, wie die einzelnen Bestandteile des regulären Ausdrucks sich auswirken.

 
=== Regex101.com ===
[[Datei:RegExp_regex101-com.png|mini|400px|left|regex101.com - Beispiel aus Spritpreismonitor]]
Auf der Seite [http://regex101.com/#p regexp101.com] werden die Bestandteile des regulären Ausdrucks zusätzlich zur Erläuterung auch noch farblich voneinander abgehoben. Das nebenstehende Beispiel zeigt einen kurzen Auszug aus dem [[Spritpreismonitor]].

 
== (Weitere) Beispiele ==
Es finden sich hier und im FHEM Forum viele, teilweise recht komplexe Beispiele für die Verwendung von regulären Ausdrücken, unter anderem
* auf der Seite [[Spritpreismonitor]]
* in der Beschreibung des Moduls [[HTTPMOD]]
* auf der Seite [[Wetter und Wettervorhersagen]]
* ...

== Links ==
* [https://de.wikipedia.org/wiki/Regul%C3%A4rer_Ausdruck Wikipedia]
* [https://wiki.selfhtml.org/wiki/Perl/Regul%C3%A4re_Ausdr%C3%BCcke selfhtml]
* [http://perldoc.perl.org/perlre.html perldoc]
* [http://chris.photobooks.com/regex/ Regular Expression Tester]
* [http://regex101.com/#p regexp101.com]

[[Kategorie:HOWTOS]]
[[Kategorie:Glossary]]

Regulärer Ausdruck

2024-11-24T11:54:26Z

Motivierte linke Hände: Links zu regex-Testern aktualisiert und den Text angepasst.

Ein [[Regulärer Ausdruck]] (englisch ''regular expression'', daher auch häufig als '''''RegExp''''' oder '''''Regex''''' abgekürzt; siehe auch [https://de.wikipedia.org/wiki/Regul%C3%A4rer_Ausdruck Wikipedia]) wird im Kontext von FHEM häufig benutzt, um aus Zeichenketten oder aus dem Strom der Ereignisse anhand von Mustern und Regeln einzelne Teile bzw. Ereignisse zu extrahieren.

== Anwendung in FHEM ==
Die Notwendigkeit der Verwendung regulärer Ausdrücke ergibt sich beispielsweise bei der Definition eines [[FileLog]] (Filtern der Ereignisse) oder um aus einem mit [[HTTPMOD]] "gewonnenen" Datenstrom die relevanten Daten zu Weiterverarbeitung zu isolieren.

Einige Stellen, an denen reguläre Ausdrücke in FHEM vorkommen (wie z.B. [[FileLog]] und [[SVG]]), bieten eine Basisunterstützung bei der Definition und Verwaltung der zugehörigen Ausdrücke.

== Werkzeuge zur Erstellung Regulärer Ausdrücke ==
Insbesondere bei nur gelegentlicher Erstellung von Regulären Ausdrücken können diverse im Internet verfügbare "Tester" oder "Analyzer" wertvolle Hilfe leisten.

=== Regular Expression Tester ===
{{Randnotiz|RNTyp=r|RNText=Die Seite von Chris Nielsen ist nicht mehr (oder derzeit nicht?) verfügbar, daher sollte gelegentlich dieses Beispiel auf eine andere Seite/Anwendung umgestellt werden.--[[Benutzer:Ph1959de|Peter]] ([[Benutzer Diskussion:Ph1959de|Diskussion]]) 13:47, 31. Aug. 2020 (CEST)}}
[[Datei:RegExp_TestExecute.png|mini|400px|right|Regular Expression Tester, Execute]]
Exemplarisch wird hier auf [https://regex101.com regex101.com] und [https://regexr.com regexr.com] verwiesen, von denen insbesondere der erste auch eine "Explain" Funktion bietet, mit deren Einsatz die einzelnen Bestandteile des zu testenden regulären Ausdrucks erläutert werden. Wer einen deutschen Tester mit angegebenem Urheber sucht, findet zum Beispiel [https://regexe regexe] von Andreas Göbel. Es gibt viele andere Internetseiten, die sich mit der gleichen Thematik befassen.

==== "Execute" ====
Anhand des nebenstehenden Bildschirmfotos soll an einem einfachen Beispiel die generelle Funktionsweise derartiger Hilfsmittel erläutert werden:
;Input
:Datenstrom, der mit dem regulären Ausdruck verarbeitet werden soll; hier ein Teil (der Quelldaten) einer HTML-Seite.
;Expression
:Regulärer Ausdruck, mit dessen Hilfe aus dem Datenstrom der Wert des Feldes ''CM Status'', also in diesem Fall ''Operational'' extrahiert werden soll.
;Output
:Die einzelnen Teile des Testergebnisses. Der Ausdruck in Klammern {{Taste|([A-Za-z]+)}} stellt den Teil dar, der zur Weiterverarbeitung benutzt werden soll; der Rest dient zu Identifizierung der richtigen Stelle (hier ''Match at character 802'') innerhalb des Datenstroms.

==== "Explain" ====
[[Datei:RegExp_TestExplain.png|mini|400px|right|Regular Expression Tester, Explain]]
Der oben beschriebene ''Regular Expression Tester'' bietet über die Schaltfläche ''Explain'' auch eine Erläuterungsfunktion. Ebenfalls am obigen Beispiel wird im Bildschirmfoto wieder dargestellt, wie die einzelnen Bestandteile des regulären Ausdrucks sich auswirken.

 
=== Regex101.com ===
[[Datei:RegExp_regex101-com.png|mini|400px|left|regex101.com - Beispiel aus Spritpreismonitor]]
Auf der Seite [http://regex101.com/#p regexp101.com] werden die Bestandteile des regulären Ausdrucks zusätzlich zur Erläuterung auch noch farblich voneinander abgehoben. Das nebenstehende Beispiel zeigt einen kurzen Auszug aus dem [[Spritpreismonitor]].

 
== (Weitere) Beispiele ==
Es finden sich hier und im FHEM Forum viele, teilweise recht komplexe Beispiele für die Verwendung von regulären Ausdrücken, unter anderem
* auf der Seite [[Spritpreismonitor]]
* in der Beschreibung des Moduls [[HTTPMOD]]
* auf der Seite [[Wetter und Wettervorhersagen]]
* ...

== Links ==
* [https://de.wikipedia.org/wiki/Regul%C3%A4rer_Ausdruck Wikipedia]
* [https://wiki.selfhtml.org/wiki/Perl/Regul%C3%A4re_Ausdr%C3%BCcke selfhtml]
* [http://perldoc.perl.org/perlre.html perldoc]
* [http://chris.photobooks.com/regex/ Regular Expression Tester]
* [http://regex101.com/#p regexp101.com]

[[Kategorie:HOWTOS]]
[[Kategorie:Glossary]]

IR-MQTT-Gateway

2021-01-15T15:26:52Z

Motivierte linke Hände:

{{Infobox Hardware|Bild=IR_WLAN_Gateway_Modul.jpg
|Bildbeschreibung=IR-WLAN-Gateway
|HWProtocol=MQTT
|HWType=Sender/Receiver
|HWCategory=Other
|HWComm=2,4 GHz
|HWChannels=1
|HWVoltage=5V
|HWPoweredBy=Kleinspannung
|HWPowerConsumption= ~0,2W(Standby)
|HWSize=55x20 mm (Durchm. x Höhe)
|HWDeviceFHEM=MQTT, MQTT_DEVICE und MQTT_BRIDGE
|HWManufacturer=HomeBrew}}

Hier wird die Einbindung des [[IR-WLAN-Gateway]] über MQTT beschrieben. Details zur Hardware und zu anderen Arten der Einbindung sind im Hauptartikel zum IR-WLAN-Gateway zu finden.
{{Hinweis|Dieser Artikel entstand vor Einführung der [[MQTT#Installation in FHEM|MQTT2-Module]]. Die Integration mit dem neueren Modul [[MQTT2_DEVICE]] ist ebenfalls möglich, einige Schritte dafür wurden bereits ergänzt. Neben der unten genannten kann insbesondere auch [[MQTT2-Module - Praxisbeispiele#Tasmota|Tasmota]] verwendet werden. Dazu existiert auch ein [[MQTT2-Module - Praxisbeispiele#attrTemplate|attrTemplate]], das für die Analyse der empfangenen IR-Codes hilfreich ist, die dann wieder für die Sendeseite benötigt werden.}}

MQTT2-Module_-_Praxisbeispiele#Tasmota

== Allgemeines ==
Hier soll die Einbindung der Hardware als transparentes Input- und Output-Device erfolgen, wobei das Hauptziel die Erstellung einer grafischen Fernbedienungsmöglichkeit darstellt. Diese wird mittels [[Remotecontrol]] umgesetzt.
<gallery>
datei:Remote IRMQTT.png|400px|thumb|Umsetzungsbeispiel
</gallery>

== Vorbereitung, firmware ==
Zunächst muß der ESP8266 mit einer MQTT-fähigen firmware versehen werden. Vorliegend wurde als ESP8266 ein ''Wemos D1 Mini'' verwendet.
Weiter wird ein vorhandener MQTT-Broker vorausgesetzt.

=== Flashen ===
Grundsätzlich sollte diese Anleitung mit jeder MQTT-fähigen firmware funktionieren, der Verfasser hat den Quellcode von [https://github.com/enc-X/mqtt-ir-transceiver hier] verwendet und wie folgt angepaßt:

* (Nur für Nutzung der Arduino IDE zum kompilieren, wird main.cpp zu src.ino umbenannt)
* in globals.h sind die Zeilen 27ff an die konkret verwendete Hardware anzupassen. Für den sog. IRBlaster also wie folgt:
// production device - (also Wemos...)
#define RECV_PIN D4 // D3 - GPIO0 - IR detector/demodulator
#define TRANS_PIN D1 // RX - GPIO3 - IR LED trasmitter
#define TRIGGER_PIN D7 // D4 - GPIO2 - trigger reset (press and hold after boot - 5 seconds)
#define LED_PIN D2 // D4 - GPIO2
#define BUTTON_ACTIVE_LEVEL LOW
#endif

Danach kann man die Firmware kompilieren und auf den Wemos flashen.

=== MQTT-Einstellungen vornehmen ===
Nach einem Reboot des Wemos kann man sich mit dessen Netzwerk verbinden und dann die Einstellungen für das eigene WLAN und den verwendeten MQTT-Broker vornehmen. Hier wurde ''ir_blaster'' als Basistopic verwendet.

Die Funktionalität des Gateways kann man dann z.B. mit mosquitto_sub prüfen:
mosquitto_sub -h <Server-IP> -d -t ir_blaster/receiver/#

Drückt man jetzt Tasten auf einer vorhandenen Infrarot-Fernbedienung, sollte die LED am Wemos blinken und entsprechende Ausgaben von mosquitto_sub erfolgen.

== MQTT_DEVICE ==

=== Empfangsseite ===
Um Informationen über empfangene Fernbedienungssignale in FHEM zu erhalten, wird zunächst das Gateway als [[MQTT_DEVICE]] angelegt:

define IR_Blaster MQTT_DEVICE

Je nach Art der Fernbediencodes kann dann mittels
attr IR_Blaster autoSubscribeReading ir_blaster/receiver/+/+
zunächst für verschiedene Fernbedienungstypen und -protokolle die automatisierte Anlage von passenden Subscriptions erfolgen. Hierzu werden dann einfach einzelne Tasten der jeweiligen Fernbedienung gedrückt. Manche Fernbedienungen benötigen einen weiteren Subtopic, hierfür ist das Attribut auf folgende Einstellung zu ändern:
attr IR_Blaster autoSubscribeReading ir_blaster/receiver/+/+/+

Die sich daraus ergebenden Attribute sehen z.B. so aus:

attr IR_Blaster subscribeReading_0 ir_blaster/receiver/NEC/0
attr IR_Blaster subscribeReading_1 ir_blaster/receiver/RC6/1
attr IR_Blaster subscribeReading_12 ir_blaster/receiver/RC5/12
attr IR_Blaster subscribeReading_13 ir_blaster/receiver/UNKNOWN/13
attr IR_Blaster subscribeReading_15 ir_blaster/receiver/RC6/15
attr IR_Blaster subscribeReading_16388 ir_blaster/receiver/PANASONIC/48/16388
attr IR_Blaster subscribeReading_20 ir_blaster/receiver/RC6/20
attr IR_Blaster subscribeReading_32 ir_blaster/receiver/NEC/32

=== Sendeseite ===
Da die firmware die zu sendenden Codes jeweils aus dem passenden Topic erwartet, ist das publishSet jeweils entsprechend anzupassen, z.B. auf
attr IR_Blaster publishSet ir_blaster/sender/NEC/32/

Dann sollten sich die Fernbediencodes bereits senden lassen.
set IR_Blaster 1587632295

Da es sehr umständlich ist, bei Wechsel zwischen verschiedenen Fernbedienungsprotokollen jeweils erst das ''publishSet'' zu ändern, nutzen wir die Möglichkeit, entsprechende <code>publishSet_<reading></code> anzulegen. Für jede der gewünschten Protokolle ist daher ein entsprechendes Attribut zu setzen. Für obiges Beispiel wäre dies z.B.
attr IR_Blaster publishSet_IRNEC32 ir_blaster/sender/NEC/32

Nunmehr sollte der obige Code auch über diesen Befehl erfolgreich an den Wemos übertragen werden können:
set IR_Blaster NEC32 1587632295

Wenn dies funktioniert, können die übrigen Attribute gesetzt werden:
attr IR_Blaster publishSet_IRPANA ir_blaster/sender/PANASONIC/48/16388
attr IR_Blaster publishSet_IRRC512 ir_blaster/sender/RC5/12
attr IR_Blaster publishSet_IRRC61 ir_blaster/sender/RC6/1
attr IR_Blaster publishSet_IRRC615 ir_blaster/sender/RC6/15
attr IR_Blaster publishSet_IRRC620 ir_blaster/sender/RC6/20
attr IR_Blaster publishSet_IRRaw ir_blaster/sender/sendStoredRaw
attr IR_Blaster publishSet_UNKNOWN13 ir_blaster/sender/UNKNOWN/13
attr IR_Blaster publishSet_rawMode ir_blaster/sender/rawMode
attr IR_Blaster publishSet_sendGC ir_blaster/sender/sendGC
attr IR_Blaster publishSet_sendRAW ir_blaster/sender/sendRAW

== MQTT2_DEVICE ==
Wenn man Mosquitto wie in [[MQTT2 DEVICE]] beschrieben mit einem Broker eingerichtet hat, sollte das IR-WLAN-Gateway automatisch gefunden und angelegt werden. Auf dieses neue Device muss dann noch das passende Template angewendet werden, z.B. bei einem auf Tasmota geflashten IR-Blaster:
set IR_Blaster attrTemplate tasmota_ir
Beim Anwenden des Templates wird man nach 4 Befehlen gefragt. Diese werden später mittels des setList-Attributs für die Befehle "power", "volumeup" und "11" verwendet (die "11" ist ein Beispiel dafür, zwei Tasten hintereinander zu senden). Das sind aber ohnehin nur Beispiele, die im setList-Attribut später geändert werden können. Für den Anfang reicht es, dort irgendwelche IR-Befehle einzutragen.

Zu verwendende IR-Befehle kann man der Tasmota-Konsole entnehmen: Wenn man die vorhandene Fernbedienung auf den IR-Blaster richtet und Tasten drückt, zeigt die Konsole den empfangenen Befehl an. Z.B. zeigt Tasmota:
<nowiki>13:23:52 MQT: tele/tasmota-ir/RESULT = {"IrReceived":{"Protocol":"NEC","Bits":32,"Data":"0x1D00B946","DataLSB":"0xB8009D62","Repeat":0}}</nowiki>
Der entsprechende IR-Befehl ist dann:
{"Protocol":"NEC","Bits":32,"Data":"0x1D00B946","DataLSB":"0xB8009D62","Repeat":0}
Ggf. ändert man "Repeat" auf eine andere Zahl als "0", um Sende- bzw. Empfangsproblemen zur ein mehrfaches Versenden des IR-Befehls vorzubeugen.
{"Protocol":"NEC","Bits":32,"Data":"0x1D00B946","DataLSB":"0xB8009D62","Repeat":2}
Über setList kann man dann definieren, dass IR-Befehle über den IR-Blaster gesendet werden. Z.B. kann man über
setList IR_Blaster power:noArg cmnd/tasmota-ir/IRsend {"Protocol":"NEC","Bits":32,"Data":"0x1D00B946","DataLSB":"0xB8009D62","Repeat":2}
erreichen, dass der IR-Befehl versendet wird, wenn man in FHEM
set IR_Blaster power
ausführt. So können in setList alle benötigten Befehle gespeichert werden.

Zusätzlich zu solchen spezifischen Befehlen wird in setList der generische Befehl
set IR_Blaster irsend
abgelegt. Dieser kann verwendet werden, um beliebige IR-Befehle über den IR-Blaster zu versenden. Z.B. versendet
set IR_Blaster irsend NEC 32 0x1D00B946
den oben als Beispiel verwendeten IR-Befehl.

== Grafische Darstellung in FHEM ==
Diese erfolgt über remotecontrol. Das Modul ist [[Remotecontrol|hier]] näher beschrieben, an dieser Stelle daher nur die sich ergebenden auszugsweisen Definitionen des notify und des remotecontrol-Devices:

=== remotecontrol ===
define Receiver remotecontrol
attr Receiver rc_iconpath icons/remotecontrol
attr Receiver rc_iconprefix black_btn_
attr Receiver row00 IRNEC32 2122415745:POWEROFF3,IRNEC32 2122448385:POWEROFF2,:blank,IRNEC32 1587632550:SPEAKER1,IRNEC32 1587665190:SPEAKER2
attr Receiver row01 :blank,:blank,:blank
attr Receiver row02 IRNEC32 1587632295:VOLUP2,IRNEC32 1587652950:SLEEP,IRNEC32 1587624135:MUTE,:blank,IRNEC32 1587664935:VOLDOWN2
...
=== notify ===
Zur Übertragung der Events aus remotecontrol wird ein notify benötigt:
define notify_Receiver notify Receiver set IR_Blaster $EVENT

== Nutzung als Input-Device ==
Auf eingehende Infrarotsignale kann mittels der üblichen Event-Handler (notify, DOIF, watchdog usw.) reagiert werden, am einfachsten nutzt man zur Erstellung den [[Event monitor|Event-Monitor]].

== Bekannte Probleme ==
Bei der Erkennung von Codes erfolgt uU. ein sehr schneller Wechsel zu Wiederholungscodes. Ggf. sollte man versuchen, die Fernbedienungstasten nur sehr kurz zu drücken, und erkannte Codes durch entsprechende Sendetests direkt zu verifizieren.

== Links ==
* Hardwarebeschreibung: [https://github.com/emc2cube/MySWeMosIRShield Platinenlayout, Bauteileliste]
* firmware: [https://github.com/enc-X/mqtt-ir-transceiver]
* {{Link2Forum|Topic=75466|Message=672652|LinkText=Darstellung mit Hilfe einer alternativen firmware}}
* Infos zur Hardware: {{Link2Forum|Topic=72950|LinkText=360 Grad IR WLAN Gateway}}

[[Kategorie:Other Components]]
[[Kategorie:IP Components]]
[[Kategorie:Infrarot]]
[[Kategorie:Code Snippets]]
[[Kategorie:MQTT]]

IR-MQTT-Gateway

2021-01-15T15:24:19Z

Motivierte linke Hände: Korrekturen/Anpassungen MQTT2

{{Infobox Hardware|Bild=IR_WLAN_Gateway_Modul.jpg
|Bildbeschreibung=IR-WLAN-Gateway
|HWProtocol=MQTT
|HWType=Sender/Receiver
|HWCategory=Other
|HWComm=2,4 GHz
|HWChannels=1
|HWVoltage=5V
|HWPoweredBy=Kleinspannung
|HWPowerConsumption= ~0,2W(Standby)
|HWSize=55x20 mm (Durchm. x Höhe)
|HWDeviceFHEM=MQTT, MQTT_DEVICE und MQTT_BRIDGE
|HWManufacturer=HomeBrew}}

Hier wird die Einbindung des [[IR-WLAN-Gateway]] über MQTT beschrieben. Details zur Hardware und zu anderen Arten der Einbindung sind im Hauptartikel zum IR-WLAN-Gateway zu finden.
{{Hinweis|Dieser Artikel entstand vor Einführung der [[MQTT#Installation in FHEM|MQTT2-Module]]. Die Integration mit dem neueren Modul [[MQTT2_DEVICE]] ist ebenfalls möglich, einige Schritte dafür wurden bereits ergänzt. Neben der unten genannten kann insbesondere auch [[MQTT2-Module - Praxisbeispiele#Tasmota|Tasmota]] verwendet werden. Dazu existiert auch ein [[MQTT2-Module - Praxisbeispiele#attrTemplate|attrTemplate]], das für die Analyse der empfangenen IR-Codes hilfreich ist, die dann wieder für die Sendeseite benötigt werden.}}

MQTT2-Module_-_Praxisbeispiele#Tasmota

== Allgemeines ==
Hier soll die Einbindung der Hardware als transparentes Input- und Output-Device erfolgen, wobei das Hauptziel die Erstellung einer grafischen Fernbedienungsmöglichkeit darstellt. Diese wird mittels [[Remotecontrol]] umgesetzt.
<gallery>
datei:Remote IRMQTT.png|400px|thumb|Umsetzungsbeispiel
</gallery>

== Vorbereitung, firmware ==
Zunächst muß der ESP8266 mit einer MQTT-fähigen firmware versehen werden. Vorliegend wurde als ESP8266 ein ''Wemos D1 Mini'' verwendet.
Weiter wird ein vorhandener MQTT-Broker vorausgesetzt.

=== Flashen ===
Grundsätzlich sollte diese Anleitung mit jeder MQTT-fähigen firmware funktionieren, der Verfasser hat den Quellcode von [https://github.com/enc-X/mqtt-ir-transceiver hier] verwendet und wie folgt angepaßt:

* (Nur für Nutzung der Arduino IDE zum kompilieren, wird main.cpp zu src.ino umbenannt)
* in globals.h sind die Zeilen 27ff an die konkret verwendete Hardware anzupassen. Für den sog. IRBlaster also wie folgt:
// production device - (also Wemos...)
#define RECV_PIN D4 // D3 - GPIO0 - IR detector/demodulator
#define TRANS_PIN D1 // RX - GPIO3 - IR LED trasmitter
#define TRIGGER_PIN D7 // D4 - GPIO2 - trigger reset (press and hold after boot - 5 seconds)
#define LED_PIN D2 // D4 - GPIO2
#define BUTTON_ACTIVE_LEVEL LOW
#endif

Danach kann man die Firmware kompilieren und auf den Wemos flashen.

=== MQTT-Einstellungen vornehmen ===
Nach einem Reboot des Wemos kann man sich mit dessen Netzwerk verbinden und dann die Einstellungen für das eigene WLAN und den verwendeten MQTT-Broker vornehmen. Hier wurde ''ir_blaster'' als Basistopic verwendet.

Die Funktionalität des Gateways kann man dann z.B. mit mosquitto_sub prüfen:
mosquitto_sub -h <Server-IP> -d -t ir_blaster/receiver/#

Drückt man jetzt Tasten auf einer vorhandenen Infrarot-Fernbedienung, sollte die LED am Wemos blinken und entsprechende Ausgaben von mosquitto_sub erfolgen.

== MQTT_DEVICE ==

=== Empfangsseite ===
Um Informationen über empfangene Fernbedienungssignale in FHEM zu erhalten, wird zunächst das Gateway als [[MQTT_DEVICE]] angelegt:

define IR_Blaster MQTT_DEVICE

Je nach Art der Fernbediencodes kann dann mittels
attr IR_Blaster autoSubscribeReading ir_blaster/receiver/+/+
zunächst für verschiedene Fernbedienungstypen und -protokolle die automatisierte Anlage von passenden Subscriptions erfolgen. Hierzu werden dann einfach einzelne Tasten der jeweiligen Fernbedienung gedrückt. Manche Fernbedienungen benötigen einen weiteren Subtopic, hierfür ist das Attribut auf folgende Einstellung zu ändern:
attr IR_Blaster autoSubscribeReading ir_blaster/receiver/+/+/+

Die sich daraus ergebenden Attribute sehen z.B. so aus:

attr IR_Blaster subscribeReading_0 ir_blaster/receiver/NEC/0
attr IR_Blaster subscribeReading_1 ir_blaster/receiver/RC6/1
attr IR_Blaster subscribeReading_12 ir_blaster/receiver/RC5/12
attr IR_Blaster subscribeReading_13 ir_blaster/receiver/UNKNOWN/13
attr IR_Blaster subscribeReading_15 ir_blaster/receiver/RC6/15
attr IR_Blaster subscribeReading_16388 ir_blaster/receiver/PANASONIC/48/16388
attr IR_Blaster subscribeReading_20 ir_blaster/receiver/RC6/20
attr IR_Blaster subscribeReading_32 ir_blaster/receiver/NEC/32

=== Sendeseite ===
Da die firmware die zu sendenden Codes jeweils aus dem passenden Topic erwartet, ist das publishSet jeweils entsprechend anzupassen, z.B. auf
attr IR_Blaster publishSet ir_blaster/sender/NEC/32/

Dann sollten sich die Fernbediencodes bereits senden lassen.
set IR_Blaster 1587632295

Da es sehr umständlich ist, bei Wechsel zwischen verschiedenen Fernbedienungsprotokollen jeweils erst das ''publishSet'' zu ändern, nutzen wir die Möglichkeit, entsprechende <code>publishSet_<reading></code> anzulegen. Für jede der gewünschten Protokolle ist daher ein entsprechendes Attribut zu setzen. Für obiges Beispiel wäre dies z.B.
attr IR_Blaster publishSet_IRNEC32 ir_blaster/sender/NEC/32

Nunmehr sollte der obige Code auch über diesen Befehl erfolgreich an den Wemos übertragen werden können:
set IR_Blaster NEC32 1587632295

Wenn dies funktioniert, können die übrigen Attribute gesetzt werden:
attr IR_Blaster publishSet_IRPANA ir_blaster/sender/PANASONIC/48/16388
attr IR_Blaster publishSet_IRRC512 ir_blaster/sender/RC5/12
attr IR_Blaster publishSet_IRRC61 ir_blaster/sender/RC6/1
attr IR_Blaster publishSet_IRRC615 ir_blaster/sender/RC6/15
attr IR_Blaster publishSet_IRRC620 ir_blaster/sender/RC6/20
attr IR_Blaster publishSet_IRRaw ir_blaster/sender/sendStoredRaw
attr IR_Blaster publishSet_UNKNOWN13 ir_blaster/sender/UNKNOWN/13
attr IR_Blaster publishSet_rawMode ir_blaster/sender/rawMode
attr IR_Blaster publishSet_sendGC ir_blaster/sender/sendGC
attr IR_Blaster publishSet_sendRAW ir_blaster/sender/sendRAW

== MQTT2_DEVICE ==
Wenn man Mosquitto wie in [[MQTT2 DEVICE]] beschrieben mit einem Broker eingerichtet hat, sollte das IR-WLAN-Gateway automatisch gefunden und angelegt werden. Auf dieses neue Device muss dann noch das passende Template angewendet werden, z.B. bei einem auf Tasmota geflashten IR-Blaster:
set IR_Blaster attrTemplate tasmota_ir
Beim Anwenden des Templates wird man nach 4 Befehlen gefragt. Diese werden später mittels des setList-Attributs für die Befehle "power", "volumeup" und "11" verwendet. Das sind aber ohnehin nur Beispiele, die im setList-Attribut später geändert werden können. Für den Anfang reicht es, dort irgendwelche IR-Befehle einzutragen.

Zu verwendende IR-Befehle kann man der Tasmota-Konsole entnehmen: Wenn man die vorhandene Fernbedienung auf den IR-Blaster richtet und Tasten drückt, zeigt die Konsole den empfangenen Befehl an. Z.B. zeigt Tasmota:
<nowiki>13:23:52 MQT: tele/tasmota-ir/RESULT = {"IrReceived":{"Protocol":"NEC","Bits":32,"Data":"0x1D00B946","DataLSB":"0xB8009D62","Repeat":0}}</nowiki>
Der entsprechende IR-Befehl ist dann:
{"Protocol":"NEC","Bits":32,"Data":"0x1D00B946","DataLSB":"0xB8009D62","Repeat":0}
Ggf. ändert man "Repeat" auf eine andere Zahl als "0", um Sende- bzw. Empfangsproblemen zur ein mehrfaches Versenden des IR-Befehls vorzubeugen.
{"Protocol":"NEC","Bits":32,"Data":"0x1D00B946","DataLSB":"0xB8009D62","Repeat":2}
Über setList kann man dann definieren, dass IR-Befehle über den IR-Blaster gesendet werden. Z.B. kann man über
setList IR_Blaster power:noArg cmnd/tasmota-ir/IRsend {"Protocol":"NEC","Bits":32,"Data":"0x1D00B946","DataLSB":"0xB8009D62","Repeat":2}
erreichen, dass der IR-Befehl versendet wird, wenn man in FHEM
set IR_Blaster power
ausführt. So können in setList alle benötigten Befehle gespeichert werden.

Zusätzlich zu solchen spezifischen Befehlen wird in setList der generische Befehl
set IR_Blaster irsend
abgelegt. Dieser kann verwendet werden, um beliebige IR-Befehle über den IR-Blaster zu versenden. Z.B. versendet
set IR_Blaster irsend NEC 32 0x1D00B946
den oben als Beispiel verwendeten IR-Befehl.

== Grafische Darstellung in FHEM ==
Diese erfolgt über remotecontrol. Das Modul ist [[Remotecontrol|hier]] näher beschrieben, an dieser Stelle daher nur die sich ergebenden auszugsweisen Definitionen des notify und des remotecontrol-Devices:

=== remotecontrol ===
define Receiver remotecontrol
attr Receiver rc_iconpath icons/remotecontrol
attr Receiver rc_iconprefix black_btn_
attr Receiver row00 IRNEC32 2122415745:POWEROFF3,IRNEC32 2122448385:POWEROFF2,:blank,IRNEC32 1587632550:SPEAKER1,IRNEC32 1587665190:SPEAKER2
attr Receiver row01 :blank,:blank,:blank
attr Receiver row02 IRNEC32 1587632295:VOLUP2,IRNEC32 1587652950:SLEEP,IRNEC32 1587624135:MUTE,:blank,IRNEC32 1587664935:VOLDOWN2
...
=== notify ===
Zur Übertragung der Events aus remotecontrol wird ein notify benötigt:
define notify_Receiver notify Receiver set IR_Blaster $EVENT

== Nutzung als Input-Device ==
Auf eingehende Infrarotsignale kann mittels der üblichen Event-Handler (notify, DOIF, watchdog usw.) reagiert werden, am einfachsten nutzt man zur Erstellung den [[Event monitor|Event-Monitor]].

== Bekannte Probleme ==
Bei der Erkennung von Codes erfolgt uU. ein sehr schneller Wechsel zu Wiederholungscodes. Ggf. sollte man versuchen, die Fernbedienungstasten nur sehr kurz zu drücken, und erkannte Codes durch entsprechende Sendetests direkt zu verifizieren.

== Links ==
* Hardwarebeschreibung: [https://github.com/emc2cube/MySWeMosIRShield Platinenlayout, Bauteileliste]
* firmware: [https://github.com/enc-X/mqtt-ir-transceiver]
* {{Link2Forum|Topic=75466|Message=672652|LinkText=Darstellung mit Hilfe einer alternativen firmware}}
* Infos zur Hardware: {{Link2Forum|Topic=72950|LinkText=360 Grad IR WLAN Gateway}}

[[Kategorie:Other Components]]
[[Kategorie:IP Components]]
[[Kategorie:Infrarot]]
[[Kategorie:Code Snippets]]
[[Kategorie:MQTT]]

IR-MQTT-Gateway

2021-01-15T14:36:38Z

Motivierte linke Hände: Anfänge für einen MQTT2-Teil ergänzt

{{Infobox Hardware|Bild=IR_WLAN_Gateway_Modul.jpg
|Bildbeschreibung=IR-WLAN-Gateway
|HWProtocol=MQTT
|HWType=Sender/Receiver
|HWCategory=Other
|HWComm=2,4 GHz
|HWChannels=1
|HWVoltage=5V
|HWPoweredBy=Kleinspannung
|HWPowerConsumption= ~0,2W(Standby)
|HWSize=55x20 mm (Durchm. x Höhe)
|HWDeviceFHEM=MQTT, MQTT_DEVICE und MQTT_BRIDGE
|HWManufacturer=HomeBrew}}

Hier wird die Einbindung des [[IR-WLAN-Gateway]] über MQTT beschrieben. Details zur Hardware und zu anderen Arten der Einbindung sind im Hauptartikel zum IR-WLAN-Gateway zu finden.
{{Hinweis|Dieser Artikel entstand vor Einführung der [[MQTT#Installation in FHEM|MQTT2-Module]]. Die Integration mit dem neueren Modul [[MQTT2_DEVICE]] ist ebenfalls möglich, einige Schritte dafür wurden bereits ergänzt. Neben der unten genannten kann insbesondere auch [[MQTT2-Module - Praxisbeispiele#Tasmota|Tasmota]] verwendet werden. Dazu existiert auch ein [[MQTT2-Module - Praxisbeispiele#attrTemplate|attrTemplate]], das für die Analyse der empfangenen IR-Codes hilfreich ist, die dann wieder für die Sendeseite benötigt werden.}}

MQTT2-Module_-_Praxisbeispiele#Tasmota

== Allgemeines ==
Hier soll die Einbindung der Hardware als transparentes Input- und Output-Device erfolgen, wobei das Hauptziel die Erstellung einer grafischen Fernbedienungsmöglichkeit darstellt. Diese wird mittels [[Remotecontrol]] umgesetzt.
<gallery>
datei:Remote IRMQTT.png|400px|thumb|Umsetzungsbeispiel
</gallery>

== Vorbereitung, firmware ==
Zunächst muß der ESP8266 mit einer MQTT-fähigen firmware versehen werden. Vorliegend wurde als ESP8266 ein ''Wemos D1 Mini'' verwendet.
Weiter wird ein vorhandener MQTT-Broker vorausgesetzt.

=== Flashen ===
Grundsätzlich sollte diese Anleitung mit jeder MQTT-fähigen firmware funktionieren, der Verfasser hat den Quellcode von [https://github.com/enc-X/mqtt-ir-transceiver hier] verwendet und wie folgt angepaßt:

* (Nur für Nutzung der Arduino IDE zum kompilieren, wird main.cpp zu src.ino umbenannt)
* in globals.h sind die Zeilen 27ff an die konkret verwendete Hardware anzupassen. Für den sog. IRBlaster also wie folgt:
// production device - (also Wemos...)
#define RECV_PIN D4 // D3 - GPIO0 - IR detector/demodulator
#define TRANS_PIN D1 // RX - GPIO3 - IR LED trasmitter
#define TRIGGER_PIN D7 // D4 - GPIO2 - trigger reset (press and hold after boot - 5 seconds)
#define LED_PIN D2 // D4 - GPIO2
#define BUTTON_ACTIVE_LEVEL LOW
#endif

Danach kann man die Firmware kompilieren und auf den Wemos flashen.

=== MQTT-Einstellungen vornehmen ===
Nach einem Reboot des Wemos kann man sich mit dessen Netzwerk verbinden und dann die Einstellungen für das eigene WLAN und den verwendeten MQTT-Broker vornehmen. Hier wurde ''ir_blaster'' als Basistopic verwendet.

Die Funktionalität des Gateways kann man dann z.B. mit mosquitto_sub prüfen:
mosquitto_sub -h <Server-IP> -d -t ir_blaster/receiver/#

Drückt man jetzt Tasten auf einer vorhandenen Infrarot-Fernbedienung, sollte die LED am Wemos blinken und entsprechende Ausgaben von mosquitto_sub erfolgen.

== MQTT_DEVICE ==

=== Empfangsseite ===
Um Informationen über empfangene Fernbedienungssignale in FHEM zu erhalten, wird zunächst das Gateway als [[MQTT_DEVICE]] angelegt:

define IR_Blaster MQTT_DEVICE

Je nach Art der Fernbediencodes kann dann mittels
attr IR_Blaster autoSubscribeReading ir_blaster/receiver/+/+
zunächst für verschiedene Fernbedienungstypen und -protokolle die automatisierte Anlage von passenden Subscriptions erfolgen. Hierzu werden dann einfach einzelne Tasten der jeweiligen Fernbedienung gedrückt. Manche Fernbedienungen benötigen einen weiteren Subtopic, hierfür ist das Attribut auf folgende Einstellung zu ändern:
attr IR_Blaster autoSubscribeReading ir_blaster/receiver/+/+/+

Die sich daraus ergebenden Attribute sehen z.B. so aus:

attr IR_Blaster subscribeReading_0 ir_blaster/receiver/NEC/0
attr IR_Blaster subscribeReading_1 ir_blaster/receiver/RC6/1
attr IR_Blaster subscribeReading_12 ir_blaster/receiver/RC5/12
attr IR_Blaster subscribeReading_13 ir_blaster/receiver/UNKNOWN/13
attr IR_Blaster subscribeReading_15 ir_blaster/receiver/RC6/15
attr IR_Blaster subscribeReading_16388 ir_blaster/receiver/PANASONIC/48/16388
attr IR_Blaster subscribeReading_20 ir_blaster/receiver/RC6/20
attr IR_Blaster subscribeReading_32 ir_blaster/receiver/NEC/32

=== Sendeseite ===
Da die firmware die zu sendenden Codes jeweils aus dem passenden Topic erwartet, ist das publishSet jeweils entsprechend anzupassen, z.B. auf
attr IR_Blaster publishSet ir_blaster/sender/NEC/32/

Dann sollten sich die Fernbediencodes bereits senden lassen.
set IR_Blaster 1587632295

Da es sehr umständlich ist, bei Wechsel zwischen verschiedenen Fernbedienungsprotokollen jeweils erst das ''publishSet'' zu ändern, nutzen wir die Möglichkeit, entsprechende <code>publishSet_<reading></code> anzulegen. Für jede der gewünschten Protokolle ist daher ein entsprechendes Attribut zu setzen. Für obiges Beispiel wäre dies z.B.
attr IR_Blaster publishSet_IRNEC32 ir_blaster/sender/NEC/32

Nunmehr sollte der obige Code auch über diesen Befehl erfolgreich an den Wemos übertragen werden können:
set IR_Blaster NEC32 1587632295

Wenn dies funktioniert, können die übrigen Attribute gesetzt werden:
attr IR_Blaster publishSet_IRPANA ir_blaster/sender/PANASONIC/48/16388
attr IR_Blaster publishSet_IRRC512 ir_blaster/sender/RC5/12
attr IR_Blaster publishSet_IRRC61 ir_blaster/sender/RC6/1
attr IR_Blaster publishSet_IRRC615 ir_blaster/sender/RC6/15
attr IR_Blaster publishSet_IRRC620 ir_blaster/sender/RC6/20
attr IR_Blaster publishSet_IRRaw ir_blaster/sender/sendStoredRaw
attr IR_Blaster publishSet_UNKNOWN13 ir_blaster/sender/UNKNOWN/13
attr IR_Blaster publishSet_rawMode ir_blaster/sender/rawMode
attr IR_Blaster publishSet_sendGC ir_blaster/sender/sendGC
attr IR_Blaster publishSet_sendRAW ir_blaster/sender/sendRAW

== MQTT2_DEVICE ==
Wenn man Mosquitto wie in [[MQTT2 DEVICE]] beschrieben mit einem Broker eingerichtet hat, sollte das IR-WLAN-Gateway automatisch gefunden und angelegt werden. Auf dieses neue Device muss dann noch das passende Template angewendet werden, z.B. bei einem auf Tasmota geflashten IR-Empfänger:
set IR_Blaster attrTemplate tasmota_ir
Beim Anwenden des Templates wird man nach 4 Befehlen gefragt. Diese werden später mittels des setList-Attributs für die Befehle "power", "volumeup" und "11" verwendet. Das sind aber ohnehin nur Beispiele, die im setList-Attribut später geändert werden können. Für den Anfang reicht es, dort irgendwelche IR-Befehle einzutragen. (Die Befehle kann man der Tasmota-Konsole entnehmen: Wenn man die vorhandene Fernbedienung auf den IR-Blaster richtet und Tasten drückt, zeigt die Konsole den empfangenen Befehl an. Z.B:
13:23:52 MQT: tele/tasmota-ir/RESULT = {"IrReceived":{"Protocol":"NEC","Bits":32,"Data":"0x1D00B946","DataLSB":"0xB8009D62","Repeat":0}}
Der entsprechende Befehl ist dann:
{"Protocol":"NEC","Bits":32,"Data":"0x1D00B946","DataLSB":"0xB8009D62","Repeat":0}
Ggf. ändert man "Repeat" noch auf eine andere Zahl als "0", um Sende- bzw. Empfangsproblemen vorzubeugen.
{"Protocol":"NEC","Bits":32,"Data":"0x1D00B946","DataLSB":"0xB8009D62","Repeat":2}

== Grafische Darstellung in FHEM ==
Diese erfolgt über remotecontrol. Das Modul ist [[Remotecontrol|hier]] näher beschrieben, an dieser Stelle daher nur die sich ergebenden auszugsweisen Definitionen des notify und des remotecontrol-Devices:

=== remotecontrol ===
define Receiver remotecontrol
attr Receiver rc_iconpath icons/remotecontrol
attr Receiver rc_iconprefix black_btn_
attr Receiver row00 IRNEC32 2122415745:POWEROFF3,IRNEC32 2122448385:POWEROFF2,:blank,IRNEC32 1587632550:SPEAKER1,IRNEC32 1587665190:SPEAKER2
attr Receiver row01 :blank,:blank,:blank
attr Receiver row02 IRNEC32 1587632295:VOLUP2,IRNEC32 1587652950:SLEEP,IRNEC32 1587624135:MUTE,:blank,IRNEC32 1587664935:VOLDOWN2
...
=== notify ===
Zur Übertragung der Events aus remotecontrol wird ein notify benötigt:
define notify_Receiver notify Receiver set IR_Blaster $EVENT

== Nutzung als Input-Device ==
Auf eingehende Infrarotsignale kann mittels der üblichen Event-Handler (notify, DOIF, watchdog usw.) reagiert werden, am einfachsten nutzt man zur Erstellung den [[Event monitor|Event-Monitor]].

== Bekannte Probleme ==
Bei der Erkennung von Codes erfolgt uU. ein sehr schneller Wechsel zu Wiederholungscodes. Ggf. sollte man versuchen, die Fernbedienungstasten nur sehr kurz zu drücken, und erkannte Codes durch entsprechende Sendetests direkt zu verifizieren.

== Links ==
* Hardwarebeschreibung: [https://github.com/emc2cube/MySWeMosIRShield Platinenlayout, Bauteileliste]
* firmware: [https://github.com/enc-X/mqtt-ir-transceiver]
* {{Link2Forum|Topic=75466|Message=672652|LinkText=Darstellung mit Hilfe einer alternativen firmware}}
* Infos zur Hardware: {{Link2Forum|Topic=72950|LinkText=360 Grad IR WLAN Gateway}}

[[Kategorie:Other Components]]
[[Kategorie:IP Components]]
[[Kategorie:Infrarot]]
[[Kategorie:Code Snippets]]
[[Kategorie:MQTT]]

IPCAM

2020-01-19T13:54:56Z

Motivierte linke Hände: Mobotix-Daten hinzugefügt

{{Infobox Modul
|ModPurpose=Einbindung von Netzwerkkameras
|ModType=d
|ModForumArea=Sonstiges
|ModTechName=49_IPCAM.pm
|ModOwner=mfr69bs ({{Link2FU|6|Martin Fischer}})}}

[[IPCAM]] ermöglicht die ereignis- oder zeitgesteuerte Erzeugung von Mitschnitten bei Netzwerkkameras. Außerdem ist es möglich, die Kamera im PTZ-Modus oder über eigene Befehle zu steuern.

== Voraussetzungen ==
Die Kamera(bilder) müssen über eine URL erreichbar sein.

== Definition ==
Das IPCAM Objekt wird angelegt mit
:<code><nowiki>define <name> IPCAM <ip[:port]> </nowiki></code>

Zusätzlich zum obigen Define muss zwingend noch das ''path'' Attribut gesetzt werden.

== Attribute ==
Die wichtigsten Attribute von ''IPCAM'' werden im Folgenden aufgeführt, die komplette Liste findet sich in der {{Link2CmdRef|Anker=IPCAMattr}}.

=== Authentifizierung ===
;basicauth
:Hinterlegung von Benutzernamen und Passwort

=== Eigene Befehle ===
;cmd01, cmd02, ... cmd15
:Festlegung von Befehlen, die nicht zu den vordefinierten gehören, z.B. <code>attr ipcam cmd01 led_mode=0</code>

=== Vordefinierte Befehle ===
;cmdPanLeft, cmdPanRight, cmdTiltUp, cmdTiltDown, cmdStep
:Diesen Befehlen können die Kameraspezifischen Werte zugeordnet werden, z.B. <code>attr ipcam cmdTiltUp command=0</code>

=== Pfade ===
;path
:...

== Unterstützte Netzwerkkameras ==
{{Randnotiz|RNText=Die Aufzählungen der unterstützten und der problematischen Netzwerkkameras sollten ergänzt werden, sobald neue Erkenntnisse vorliegen; beide Listen sind nicht vollständig.}}
Bei den folgenden Netzwerkkameras ist gesichert, dass sie durch das ''IPCAM'' Modul unterstützt sind:
* {{Link2Forum|Topic=33347|Message=257115|LinkText=Foscam 9805W}}
* Foscam FI9831P
* {{Link2Forum|Topic=13826|LinkText=Instar 2905}}
* {{Link2Forum|Topic=100493|LinkText=IN-8015 Full HD}}
* {{Link2Forum|Topic=36201|LinkText=IN-6001HD}}
* {{Link2Forum|Topic=11664|LinkText=Instar 6011, 6012, 2905}}
* {{Link2Forum|Topic=58676|LinkText=Instar IN-5905HD, IN-5907HD, IN-6014HD, IN-6012HD-PoE}}
* {{Link2Forum|Topic=15217|LinkText=WansView (Modell nicht näher spezifiziert)}}
* {{Link2Forum|Topic=11664|Message=158052|LinkText=Wansview 620, 625, 6012}}
* Axis 205
* D-Link DCS-933
* Mobotix (jedenfalls S26 und Q25)
* Xiaomi Dafang (nur mit alternativer Firmware)

Nicht gesichert, ob die Kamera unterstützt wird bzw. ob alle Funktionen nutzbar sind:
* {{Link2Forum|Topic=33347|LinkText=Foscam FI9831W}}

=== Pfad-Parameter für Axis 205 ===
<pre>
attr Cam1 path /jpg/image.jpg
</pre>

=== Pfad-Parameter für D-Link DCS-933 ===
<pre>attr Cam1 path image.jpg</pre>

=== Parameter für Hikvision DS-2CD2032-I ===
Mit folgenden Parameter wurde (lt. diesem {{Link2Forum|Topic=39932|Message=322269|LinkText=Forenbeitrag}}) die Hikvision DS-2CD2032-I erfolgreich betrieben:
<pre>
define Cam1 IPCAM 192.168.xxx.xxx
attr Cam1 basicauth <username>:<passwort>
attr Cam1 delay 0
attr Cam1 group Kamera
attr Cam1 icon it_camera
attr Cam1 path Streaming/channels/1/picture?snapShotImageType=JPEG
attr Cam1 snapshots 1
attr Cam1 storage /opt/fhem/www/snapshots/cam1
</pre>

=== Pfad-Parameter für Foscam FI9831P ===
Die Version ist ohne basicauth und hat Nutzer und Passwort direkt in der URL. Kann natürlich geändert werden.
Sämtliche Befehle für die Foscam HD Kameras findet man [https://www.manualslib.com/manual/728928/Foscam-Ip-Camera.html hier]
<pre>
define IPKamera IPCAM <ip>:<port>
attr IPKamera cmd01 cmd=ptzStopRun&usr=xxx&pwd=xxx
attr IPKamera cmdPanLeft cmd=ptzMoveLeft&usr=xxx&pwd=xxx
attr IPKamera cmdPanRight cmd=ptzMoveRight&usr=xxx&pwd=xxx
attr IPKamera cmdPos01 cmd=ptzGotoPresetPoint&name=<Nameposition>&usr=xxx&pwd=xxx
attr IPKamera cmdTiltDown cmd=ptzMoveDown&usr=xxx&pwd=xxx
attr IPKamera cmdTiltUp cmd=ptzMoveUp&usr=xxx&pwd=xxx
attr IPKamera path cgi-bin/CGIProxy.fcgi?usr=xxx&pwd=xxx&cmd=snapPicture2
attr IPKamera pathCmd cgi-bin/CGIProxy.fcgi
attr IPKamera pathPanTilt cgi-bin/CGIProxy.fcgi?usr=xxx&pwd=xxx
attr IPKamera storage ./www/images/webcam
</pre>

=== Pfad-Parameter für Mobotix ===
<pre>
attr IPKamera path /record/current.jpg
</pre>

=== Einstellungen für Foscam C2 und Foscam R2 ===
Eine ausführliche Beschreibung zur Benutzung der IP Kameras Foscam C2 und Foscam R2 findet sich in {{Link2Forum|Topic=84677|LinkText=diesem Forenthread}}.

=== Parameter für Xiaomi Dafang ===
Diese Parameter gelten bei installierter alternativer Firmware von [https://github.com/EliasKotlyar/Xiaomi-Dafang-Hacks hier]
<pre>

Attributes:
attr IPKamera cmdPanLeft cmd=motor_left
attr IPKamera cmdPanRight cmd=motor_right
attr IPKamera cmdTiltDown cmd=motor_down
attr IPKamera cmdTiltUp cmd=motor_up
attr IPKamera delay 10
attr IPKamera event-on-update-reading snapshots
attr IPKamera icon it_camera
attr IPKamera path cgi-bin/currentpic.cgi
attr IPKamera pathPanTilt cgi-bin/action.cgi?
attr IPKamera snapshots 5
attr IPKamera storage /opt/fhem/www/ipcamera/dafang_1/shot
</pre>

=== Parameter für INSTAR Full HD ===
Die vollständige Schnittstelle und weitere Beispiele können direkt im [https://wiki.instar.de/Erweitert/ INSTAR-Wiki] eingesehen werden. 
Zur Integration einer INSTAR Full HD CAM können zum Beispiel folgende Attribute verwendet werden:
<pre>
attr INSTAR_8015 basicauth {USERNAME}:{PASSWORD}
attr INSTAR_8015 cmd01 cmd=setinfrared&-infraredstat=auto
attr INSTAR_8015 cmd02 cmd=setinfrared&-infraredstat=close
attr INSTAR_8015 cmd03 cmd=setinfrared&-infraredstat=open
attr INSTAR_8015 cmd04 cmd=setmdalarm&-aname=ftprec&-switch=on
attr INSTAR_8015 cmd05 cmd=setmdalarm&-aname=ftprec&-switch=off
attr INSTAR_8015 cmd06 cmd=setplanrecattr&-planrec_enable=0
attr INSTAR_8015 cmd07 cmd=setplanrecattr&-planrec_enable=1
attr INSTAR_8015 cmd08 cmd=setplanrecattr&-planrec_chn=11
attr INSTAR_8015 cmd09 cmd=setplanrecattr&-planrec_chn=12
attr INSTAR_8015 cmd10 cmd=manualrec&-act=on
attr INSTAR_8015 cmd11 cmd=manualrec&-act=off
attr INSTAR_8015 cmd12 cmd=sdfrmt
attr INSTAR_8015 cmd13 cmd=preset&-act=goto&-number=0
attr INSTAR_8015 cmd14 cmd=preset&-act=goto&-number=1
attr INSTAR_8015 cmd15 cmd=preset&-act=goto&-number=2
attr INSTAR_8015 cmdPanLeft -act=left
attr INSTAR_8015 cmdPanRight -act=right
attr INSTAR_8015 cmdPos15 -act=stop
attr INSTAR_8015 cmdTiltDown -act=down
attr INSTAR_8015 cmdTiltUp -act=up
attr INSTAR_8015 credentials /<ipcam-conf-path>/ipcam.conf
attr INSTAR_8015 eventMap /pos 15:MOVE-STOP/pan left:MOVE-LEFT/pan right:MOVE-RIGHT/tilt up:MOVE-UP/tilt down:MOVE-DOWN/cmd 1:IR-LED-auto/cmd 2:IR-LED-off/cmd 3:IR-LED-on/cmd 4:FTP-rec-on/cmd 5:FTP-rec-off/cmd 6:REC-SD-DISABLE/cmd 7:REC-SD-ENABLE/cmd 8:REC-SD-QUAL-HIGH/cmd 9:REC-SD-QUAL-MID/cmd 10:MAN-REC-Start/cmd 11:MAN-REC-Stop/cmd 12:FORMAT-SD-CARD/cmd 13:POS-WZ/cmd 14:POS-Flur/cmd 15:POS-Park/
attr INSTAR_8015 icon it_camera
attr INSTAR_8015 path tmpfs/snap.jpg
attr INSTAR_8015 pathCmd param.cgi
attr INSTAR_8015 pathPanTilt ptzctrl.cgi?-step=
attr INSTAR_8015 scheme https
attr INSTAR_8015 storage /<ipcam-snapshot-path>/snapshots
attr INSTAR_8015 webCmd POS-WZ:POS-Flur:POS-Park
</pre>

== Nicht unterstützte Netzwerkkameras ==
{{Randnotiz|RNTyp=y|RNText=Die hier aufgeführten Netzwerkkameras sind definitiv nicht unterstützt oder es gibt gravierende, hier beschriebene Einschränkungen.}}
;TRENDnet TV-IP320PI
:Aufruf der Funktion <code>get ''myCam'' image</code> führt zur Fehlermeldung ''...invalid Format''; auf Kamerabild oder Stream kann jedoch über die URL camHostnameOrIP/Streaming/channels/1/Picture (Bild) bzw. camHostnameOrIP/Streaming/channels/1/httpPreview (Stream) zugegriffen werden.

== Generierte Ereignisse ==
Das Modul ''IPCAM'' generiert die Ereignisse
* <code><nowiki>last: <name_of_device>_snapshot.<image_extension></nowiki></code>
* <code><nowiki>snapshots: <total_number_of_taken_snapshots_at_end></nowiki></code>

== Bekannte Probleme ==
Derzeit (08/2015) ist das Logging aus dem Modul zumindest lückenhaft und verbesserungsfähig. So sollten z.B. einige weitere Meldungen zur Fehlereingrenzung bei der Einrichtung eines IPCAM Objekts eingefügt werden:
* Ausgabe des kompletten Pfads / der URL, die bei der Erzeugung eines Snapshots aus einzelnen Bestandteilen zusammengesetzt wird
* Die Zuordnung von Meldungen zu ''verbose''-Leveln sollte kontrolliert und ggf. umgestellt werden
* siehe auch diesen {{Link2Forum|Topic=39932|LinkText=Forenthread}}, der Beschreibung von Problemen, eine Hikvision IPCam in Betrieb zu nehmen

Außerdem müsste das Modul dringend auf die aktuelle Form des Logging, [[verbose|verbose/Log3]], umgestellt werden.

Eine mögliche Lösung für das Problem "Wrong or not supported image format: unknown" habe ich hier beschrieben: {{Link2Forum|Topic=10772|Message=425265|LinkText=Forenbeitrag}}

== Links ==
* Forenthread zur {{Link2Forum|Topic=10772|LinkText=Erweiterung des IPCAM Moduls}}
* Forenthread zum Thema {{Link2Forum|Topic=21005|LinkText=Bewegungserkennung}}
* Forenthread zum Thema {{Link2Forum|Topic=30723|LinkText=Bewegungsmelder der Kamera "anzapfen"}}
* Webseite des Modulautors zum Thema [http://www.fischer-net.de/hausautomation/videoueberwachung.html Videoüberwachung]

Global

2019-12-31T18:11:35Z

Motivierte linke Hände: Hinweis auf autosave = 0 bei Problemen beim Start ergänzt

{{SEITENTITEL:global}} 
{{Infobox Modul
|ModPurpose=Gerät zur Definition von globalen Attributen
|ModType=d
|ModCmdRef=global
|ModForumArea=Automatisierung
|ModTechName=fhem.pl ("Built-in")
|ModOwner=rudolfkoenig ({{Link2FU|8|Forum}} / [[Benutzer Diskussion:Rudolfkoenig|Wiki]])
}}

Das '''Device global''' dient dazu, diverse allgemein für das gesamte FHEM gültige Eigenschaften und Verhaltensvorgaben zu definieren. Diese werden in [[Attribut|Attributen]] des devices verwaltet, indem deren Werten gemäß der {{Link2CmdRef|Lang=de|Anker=global|Label=dokumentierten}} Bedeutung gesetzt werden.

Das Pseudogerät '''global''' wird automatisch erstellt, kann weder gelöscht noch [[rename|umbenannt]] werden und hat auch keine ''set'' oder ''get'' Parameter.
{{Todo|Ergänzen}}

== Definition ==
Nicht erforderlich; wird automatisch angelegt.
== Attribute ==
=== altitude ===
Höhe in Metern über dem Meeresspiegel, Voreinstellung ist 0.
=== latitude ===
Geographische Breite in Dezimalgrad, Voreinstellung ist 50.112, Frankfurt am Main.
=== longitude ===
Geographische Länge in Dezimalgrad, Voreinstellung ist 8.686, Frankfurt am Main.
=== archivedir, archivecmd, nrarchive ===
Diese Attribute können grundsätzlich in allen Devices gesetzt werden und beziehen sich dann auf deren Logging. Im Device global wirken sie ausschließlich auf das FHEM [[#logfile|logfile]].

Wenn eine neue FileLog-Datei geöffnet wird, wird der FileLog archiver aufgerufen. Das geschieht aber nur, wenn der Name der Datei sich geändert hat (abhängig von den zeitspezifischen Wildcards, die in FileLog (define) beschrieben werden) und gleichzeitig ein neuer Datensatz in diese Datei geschrieben werden muss.

Wenn das Attribut archivecmd benutzt wird, startet es als shell-Kommando (eine Einbettung in " ist nicht notwendig), und jedes % in diesem Befehl wird durch den Namen des alten Logfiles ersetzt.

Wenn dieses Attribut nicht gesetzt wird, aber dafür nrarchive, werden nrarchive viele Logfiles im aktuellen Verzeichnis gelassen, und ältere Dateien in das Archivverzeichnis (archivedir) verschoben (oder gelöscht, falls kein archivedir gesetzt wurde).

'''Achtung''': "ältere Dateien" sind die, die in der alphabetisch sortierten Liste oben sind.
=== archivesort ===
archivesort kann auf dem (voreingestellten) Wert ''alphanum'' oder auf ''timestamp'' gesetzt werden, und bestimmt die Methode für die Reihenfolgenberechnung der Dateien für nrarchive.
=== autoload_undefined_devices ===
Wenn dieses Attribut gesetzt ist, werden die zu einer neu empfangenen Nachricht zugehörigen Module automatisch geladen. Dies erfolgt vom autocreate Gerät, um so automatisch ein FHEM-Gerät bei erreichen einer entsprechenden Nachricht zu erstellen.
{{Todo|Ergänzen: gesetzt mit welchem Wert?}}
=== backupcmd ===
Wenn dieses Attribut gesetzt ist, startet es als ein SHELL-Befehl und erstellt eine durch Leerzeichen getrennte Liste von Dateien/Verzeichnissen als ein Argument zum Befehl, z.B.:
"/etc/fhem.cfg /var/log/fhem/fhem.save /usr/share/fhem/contrib /usr/share/fhem/FHEM /usr/share/fhem/foo /usr/share/fhem/foobar /usr/share/fhem/www"
'''Bemerkung''': Ihr Befehl/Skript muss die Zeichenkette "backup done" zurückgeben oder eine entsprechende Zeichenkette um Fehlermeldungen auszugeben, damit die Zusammenarbeit mit update funktioniert!

{{Todo|Ergänzen: Was denn nun: 'backup done' oder die oben beschriebene Zeichenkette?}}
Dieses Attribut wird vom backup Befehl benutzt.

'''Beispiel''':
attr global backupcmd /usr/local/bin/myBackupScript.sh
=== backupdir ===
Ein Verzeichnis, in dem die komprimierten Sicherheitsdateien zu speichern sind. Dieses Attribut wird vom backup Befehl benutzt.
'''Beispiel:'''
attr global backupdir /Volumes/BigHD

=== backupsymlink ===
Wird dieses Attribut auf etwas anderes als ''no'' gesetzt, dann unterstützt der Archivierungsbefehl "tar" symbolische Links in Ihrem Backup. Andererseits, anderenfalls (Wert ''no'') werden symbolische Links vom Befehl "tar" ignoriert. Dieses Attribut wird vom backup Befehl benutzt.

'''Beispiel:'''
attr global backupsymlink yes
=== blockingCallMax ===
Begrenzt die Anzahl der parallel laufenden Prozesse, die von der FHEM Hilfsroutine ''BlockingCall'' gestartet wurden. Sinnvoll auf weniger leistungsfähigeren Hardware.
=== configfile ===
Enthält den Namen der FHEM Konfigurationsdatei. Wenn save ohne Argumente aufgerufen wird dann wird die Ausgabedatei unter diesem Dateinamen gespeichert.
=== commandref ===
Falls der Wert ''full'' (die Voreinstellung) ist, wird nach jedem update ein komplettes commandref.html generiert. Falls der Wert ''modular'' ist, wird die Moduldokumentation erst nach Bedarf während der Laufzeit per JavaScript geladen.
=== dnsHostsFile ===
Falls dnsServer gesetzt ist, wird die angegebene Datei nach dem Hostnamen durchsucht. Um die vom System verwendete Datei zu benutzen, ist es unter Linux/Unix/OSX auf ''/etc/hosts'' und unter Windows auf ''C:\windows\system32\drivers\etc\hosts'' zu setzen. Achtung: es wird nur IPv4 unterstützt.
=== dnsServer ===
Enthält die IP Adresse des DNS Servers. Die von bestimmten Modulen (oder eigenen Code) aufgerufene HttpUtils_NonblockingGet wird auch bei der DNS Auflösung nicht mehr blockieren, falls dieses Attribut gesetzt ist, da es in diesem Fall FHEM eigene Routinen aufgerufen werden. Sonst werden die Betriebssystem eigenen, blockierenden Routinen inet_aton bzw gethostbyname aufgerufen.
=== featurelevel ===
Der Wert dieses Attributes de-/aktiviert einzelne Fähigkeiten (Features) bzw. Verhaltensweisen, die im Laufe der Versionsgeschichte dazugekommen sind, entfernt oder geändert wurden basierend auf der angegebenen FHEM Version.

Bei einer Neuinstallation oder einem Update wird der Featurelevel automatisch auf die aktuelle Version gesetzt. Ein manuelles
attr global featurelevel x.y
mit den Werten für x und y aus den gewünschten Haupt- und Unterversionsnummern setzt temporär oder - bei Speicherung in der fhem.cfg dauerhaft - eine gewünschte Version als Basis. Dieses Vorgehen kann z.B. bei Upgrades mit unerwarteten Nebenwirkungen eine erste Maßnahme und Workaround sein.
=== holiday2we ===
Ist dieses Attribut gesetzt, wird die Variable ''$we'' als "true" betrachtet, wenn der Wert der Variable ''holiday'' zu diesem Attribut nicht "none" ist.

Falls der Wert des Attributes eine Komma getrennte Liste ist, dann ist ''$we'' wahr, falls eine der referenzierten Instanzen nicht "none" ist.

'''Beispiel:'''
attr global holiday2we hessen
{{Todo|Verwirrung auflösen...}}
=== httpcompress ===
Einige Module von FHEM verwenden das Modul ''HttpUtils'' mit aktivierter Komprimierung (Voreinstellung). Falls man httpcompress auf 0 setzt, wird die Komprimierung deaktiviert.
{{Todo|Wozu sollte das gut sein?}}
=== keyFileName ===
FHEM Module speichern Passwörter und IDs in der Datei FHEM/FhemUtils/uniqueID. Um mehrere FHEM-Instanzen im gleichen Verzeichnis starten zu können, kann man dieses Attribut setzen, dessen Wert an FHEM/FhemUtils/ angehängt wird.
=== logdir ===
Falls gesetzt, wird %L in dem Attribut ''[[#logfile|logfile]]'' (oder in der Dateinamen Spezifikation des [[FileLog]] Moduls) durch den Wert des Attributes ersetzt.

'''Achtung''' Wird der Wert des Attributes geändert, bewirkt dies '''nicht''' das Verschieben bereits erstellter Dateien, und kann daher potentiell zu diversen Problemen führen.
=== logfile ===
Gibt das Logfile an, in welches gespeichert werden soll. Mit dem Wert ''"-"'' erfolgt die Ausgabe des Logs in das stdout-Gerät. In diesem Fall stellt sich der Server nicht selbst in den Hintergrund.

Der Name der Logdatei kann auch "wildcards" enthalten, um eine einfachere Abfolge für die Dateien zu erreichen. Weiteres zu den Dateinamen beim Modul [[FileLog]].

Die Attribute [[#archivedir, archivecmd, nrarchive|archivedir, archivecmd, nrarchive]] können ggf. passend gesetzt werden.

Sie können den Namen der Logdatei mit {$currlogfile} festlegen.
{{Todo|Der Gehalt des letzten Satzes erschließt sich nicht.}}
=== maxShutdownDelay ===
Einige Module benötigen Zeit zum Aufräumen beim shutdown, aber FHEM begrenzt diese Zeit auf 10 Sekunden. Mit diesem Attribut kann man sie anpassen.
=== modpath ===
Mit modpath geben Sie den Pfad zu dem Verzeichnis der FHEM Module an. Der Pfad enthält nicht das Verzeichnis FHEM. Das festgelegte Verzeichnis wird nach Dateinamen in der Form NN_<NAME>.pm durchsucht. Die gefundenen Dateien dienen als Quelle die Definition von Geräten unter dem Namen <NAME>. Wenn das erste Gerät des Typs <NAME> definiert wird, werden die entsprechenden Module geladen und in dem Modul die entsprechende Funktion mit dem Namen <NAME>_Initialize aufgerufen. Eine Ausnahme bilden Module die mit der Nummer 99 im Dateinamen beginnen. Diese enthalten PERL-Hilfsfunktionen und werden zur Startzeit geladen.
=== motd ===
''Message Of The Day'' (Nachricht des Tages). Der hier hinterlegte Text wird im Begrüßungsbildschirm von FHEM angezeigt, oder direkt beim Start einer "telnet" Sitzung, bevor der Prompt (''fhem>'')erscheint. Der SecurityCheck setzt motd wenn es bisher nicht gesetzt ist. Um das zu verhindern, können sie den Wert von motd auf ''none'' setzen. motd wird auch verwendet, um Fehlermeldungen während des FHEM-Starts zu sammeln und anzuzeigen.
=== mseclog ===
Wenn dieses Attribut (z. B. auf den Wert 1) gesetzt ist, enthalten Datums/Zeiteinträge (timestamp) in der Logdatei einen Millisekunden-Eintrag.

=== nofork ===
Wenn dieses Attribut oder das Attribut [[#logfile|logfile]] auf "''-''" gesetzt ist, wird FHEM nicht im Hintergrund abgearbeitet. Dieses Attribut ist bei einigen FHEM Installationen auf FRITZ!-Boxen notwendig, und wird fuer Windows automatisch gesetzt.
{{Todo|Ist das so formuliert tatsächlich korrekt?}}
=== pidfilename ===
In die angegebene Datei wird die Prozess-ID des FHEM(-Perl)-Prozesses geschrieben. Der Server läuft als Hintergrundprozess (daemon). Einige Distributionen wollen anhand der PID testen, ob der FHEM Prozess läuft. Die Datei wird bei Ausführung des "shutdown"-Kommandos gelöscht.
=== proxy ===
Der Wert wird in der Form ''IP:PORT'' gesetzt, wenn HttpUtils einen HTTP-Proxy verwenden soll.
=== proxyAuth ===
Base64 kodiertes Benutzername:Passwort für den HTTP-Proxy (vgl. [[#proxy|Attribut proxy]].
=== proxyExclude ===
Regulärer Ausdruck für die Namen aller Hosts, die '''nicht''' via Proxy anzusprechen sind.
=== restoreDirs ===
''Update'' sichert (kopiert) jede Datei, bevor sie durch die neue Version ersetzt wird. Zu diesen Zweck wird zuerst ein restoreDir/Update-Verzeichnis angelegt (vgl. Attribut [[#modpath|modpath]]) und danach ein Unterverzeichnis mit dem aktuellen Datum. In dieses Verzeichnis werden die alten Versionen der Dateien vor dem Überschreiben gerettet. Die Voreinstellung ist 3, d.h. die letzten 3 Datums-Verzeichnisse werden aufgehoben, und die älteren entfernt.

Auch fhem.cfg und fhem.state wird auf diese Weise vor dem Ausführen von save gesichert, diesmal in das restoreDir/save Verzeichnis. Zum Restaurieren der alten Dateien kann man das restore Befehl verwenden.

Falls man den Wert auf 0 setzt, ist dieses Feature deaktiviert.
=== sendStatistics ===
Der Wert dieses Attributes steuert das Verhalten des Moduls [[Fheminfo]]:

* ''onUpdate'': Übertragung von INFO-Daten bei jedem Update (empfohlene Einstellung).
* ''manually'': Manuelle Übertragung der INFO-Daten mit dem FHEM-Befehl [[fheminfo|fheminfo send]].
* ''never'': Die Übertragung von INFO-Daten wird komplett verhindert.

=== statefile ===
Der Wert dieses Attributes legt den Namen der Datei fest, in die Statusinformationen aller Geräte gespeichert werden, bevor der Server heruntergefahren wird. Falls diese Datei nicht angegeben wird, werden keinerlei Informationen gesichert.
=== title ===
Setzt im Browser den Fenstertitel der FHEM-Session. Ist der Wert in {} eingeschlossen, wird er als Perl-Ausdruck ausgewertet.
=== useInet6 ===
Die HttpUtils Routinen verwenden IPv6 für die Kommunikation, falls der Server eine IPv6 Adresse hat.

'''Achtung''': das Perl-Modul IO::Socket::INET6 wird benötigt.
{{Todo|Welcher Wert ist für das Attribut zu setzen?}}
=== userattr ===
Enthält eine durch Leerzeichen getrennte Liste, in der die Namen zusätzlicher Attribute aufgeführt sind, die in allen Devices verfügbar werden. Diese müssen zuerst in dieser Liste definiert werden, bevor sie (individuell bei allen Geräten) angewendet werden können.

''userattr'' kann auch als Attribut in einzelnen Gerätekonfigurationen spezifiziert werden, um weitere Attribute '''für diese Geräte''' zu definieren.

'''Achtung''': Bei der Festlegung global verfügbarer, zusätzlicher Attributnamen ist dringend darauf zu achten, dass keine Kollisionen mit Geräte spezifischen Attributen erzeugt werden.
=== dupTimeout ===
Definert die Wartezeit, nach der 2 identische Ereignisse zweier Empfänger als Duplikat angesehen werden. Voreingestellt sind 0,5 Sekunden.
=== showInternalValues ===
Attribute, Geräte, Readings die mit Punkt (.) anfangen werden nicht angezeigt, es sei denn das globale Attribut ''showInternalValues'' ist gesetzt. Diese Variable wird bei den Befehlen ''[[list]]'' und ''[[xmllist]]'' und bei der FHEMWEB Raumansicht geprüft.
{{Todo|... gesetzt auf welchen Wert?}}
=== sslVersion ===
Setzt die akzeptierten Crypto-Algorithmen im Hilfsmodul [[TcpServices]]. Die Voreinstellung ''TLSv12:!SSLv3'' wird als sicherer erachtet als die vorherige ''SSLv23:!SSLv3:!SSLv2'', aber sie kann Probleme mit nicht ausreichend aktualisierten Netzwerk-Diensten verursachen.
=== stacktrace ===
Falls auf ''1'' gesetzt, schreibt FHEM zusätzlich zu jedem "PERL WARNING" den stacktrace ins Log.
=== restartDelay ===
Setzt die Verzögerung beim Neustart mit ''shutdown restart'', die Voreinstellung ist 2 (Sekunden).
=== autosave ===
Erlaubt manchen Modulen, nach einer automatischen Änderung der Konfiguration ''save'' auszuführen, z. B. nachdem ein Gerät angelegt wurde. Die Voreinstellung ist ''1'' (wahr), man kann es ausschalten, indem man den Wert auf ''0'' setzt.

Auch wenn man autosave auf ''1'' setzt, wird es automatisch beim Starten wieder auf ''0'' gesetzt, falls beim Starten was schiefgegangen ist, damit ein automatisches Save (wie auch manche Module das ungefragt machen) nicht zum Verlust von Teilen der Konfiguration führt.
== weitere Informationen ==
Siehe {{Link2CmdRef|Lang=de|Label=commandref|Anker=global}}.

GDS

2018-02-09T07:25:18Z

Motivierte linke Hände: Fehlende Funktion des Kartendownloads dokumentiert

{{Infobox Modul
|ModPurpose=Herunterladen und Auswerten von Daten des Deutschen Wetterdienstes
|ModType=contrib
|ModForumArea=Unterstützende Dienste/Wettermodule
|ModFTopic=14106
|ModTechName=55_GDS.pm
|ModOwner=betateilchen
}}
[[GDS]] ist ein Modul, mit dessen Hilfe man sich die Daten des Deutschen Wetterdienstes herunterladen kann und dann Wetterlage, diverse Wetterkarten und/oder Unwettermeldungen anzeigen/auswerten kann.

== Voraussetzungen ==
=== Anmeldung beim DWD ===
Als erstes muss man sich beim Deutschen Wetterdienst zur [http://www.dwd.de/grundversorgung Grundversorgung] kostenlos [http://kunden.dwd.de/gdsRegistration/gdsRegistrationStart.do anmelden].

=== Installation der benötigten Perl-Module ===
GDS benötigt die Perl-Module Net::FTP, List::MoreUtils, XML::Simple, Text::CSV.

Für Ubuntu und Raspi sollte funktionieren:

<code>apt-get install libnet-lite-ftp-perl liblist-moreutils-perl libxml-simple-perl libtext-csv-perl</code>

Das ftp-Modul verursacht manchmal Probleme bei der Installation. Teilweise ist es wohl auch schon in der Grundinstallation vorhanden, ansonsten kann man versuchen:

<code>apt-get install libnet-ftp-perl</code>

oder

<code>apt-get install libwww-perl</code>

Abhängig von der Perl-Version muss ggf. auch noch Archive::Zip installiert werden.

== Anwendung ==
{{Randnotiz|RNTyp=Fehl|RNText=Dieser Modul ist '''NICHT''' in der {{Link2CmdRef}} dokumentiert!}}

=== Define ===
<code>define [gdsName] GDS [gdsUsername] [gdsPasswort]</code>

[gdsUsername] und [gdsPasswort] gibt es nach Anmeldung vom DWD.

=== Attribute ===
Die vollständige Liste der Attribute ist in der {{Link2CmdRef|Anker=GDS}}.

Hilfreich kann u.a. sein, wenn man hinter eine Firewall sitzt und der Datenabruf nicht funktioniert:

<code>attr [gdsName] gdsPassiveFtp 1</code>

== Anwendung ==
=== Liste der verfügbaren Zellen für Warnungen abrufen ===
<code>get [gdsName] list capstations</code>

=== Manuelle Aktualisierung der Daten ===

==== Aktuelle Daten vom Server abrufen ====
<code>get [gdsName] rereadcfg</code>

==== Readings aus abgerufenen Daten aktualisieren ====
<code>set [gdsName] update</code>

=== Station setzen für automatischen, periodischen Abruf ===
Station setzen, für die beim fhem-Start und dann alle 20 Minuten die Vorhersagedaten eingelesen werden sollen:

<code>set [gdsName] forecasts [Station]</code>

Automatisch abgerufen (alle 20 Minuten) werden nur die mit fc_ beginnenden Readings (forecast, d.h. die Vorhersage). Die a_ Readings (Warnungen, etc.) müssen manuell aktualisiert werden.

=== Unwetterwarnungen nach Region aus gelesenen Daten raussuchen ===
<code>set [gdsName] warnings [Region]</code>

z.B.: <code>set gds warn Nordrhein-Westfalen</code>

Die Region kann ausgeschrieben oder mit den [http://www.bmelv-statistik.de/de/daten-tabellen-suche/abkuerzungen-der-bundeslaender/ offiziellen Abkürzungen] bezeichnet werden.

=== Unwetterwarnungen granularer nach Kreis aus gelesenenen Daten raussuchen ===
<code>set [gdsName] alerts [Warncell-ID]</code>

Die passende Warncell-ID kann man sich über <code>get [gdsName] list capstations</code> heraussuchen.

Ob es passende Warnmeldungen gibt, kann dann über das Reading <code>a_valid</code> abgefragt werden. Wenn <code>a_valid</code> 1 ist, gibt <code>a_count</code> die Anzahl der vorhandenen Warnmeldungen an. Die Warnungen stehen dann in den Readings <code>a_X_...</code>, wobei X ab 0 hochzählt. D.h. wenn <code>a_count</code> 2 ist, gibt es a_0_... und a_1_... Ein praktisches Reading ist z.B. <code>a_X_headline</code>, das die Zusammenfassung der jeweiligen Warnung als kurze Textzusammenfassung enthält.

Alle eingelesenen Warnmeldungen kann man sich über die Funktion <code>gdsHeadlines()</code> ausgeben lassen. Z.B. einfach in der Befehlszeile von fhem eingeben:

<code>{gdsHeadlines([gdsName])}</code>

Wer möchte, kann auch das Trennzeichen bei mehreren Meldungen konfigurieren:

<code>{gdsHeadlines([gdsName],'[Trennzeichen]')}</code>

Z.B. also

<code>{gdsHeadlines(gds, '***')}</code>

Standard für das Trennzeichen ist der senkrechte Strich.

Jedenfalls nach <code>attr [gdsName] gdsLong 1</code> werden in a_X_description die Langmeldungen zu den Warnungen ausgegeben.

== Anwendungsbeispiele ==

Für GDS sollten die Daten regelmäßig aktualisiert werden. Dafür richtet man am besten '''zwei''' zeitlich '''nacheinander''' laufende ats ein:

Einen zum Holen aktualisierter Daten vom Server:

<pre>
define readGDS at +*00:10:00 get [gdsName] rereadcfg
attr readGDS alignTime 22:30:05
</pre>

Einen zweiten, der danach läuft, der aus den aktualisierten Serverdaten dann die Readings aktualisiert; z.B. für die Alerts:

<pre>
define checkGDS at +*00:10:00 get [gdsName] alerts [Region]
attr checkGDS alignTime 22:35:05
</pre>

Wichtig ist, dass beide at zeitlich auseinander liegen, im vorstehenden Beispiel durch die unterschiedlichen "alignTime" Attribute um 5 Minuten.

== Bekannte Probleme ==
Nach Änderungen im Angebot des DWD kann das GDS-Modul keine Karten mehr herunterladen. Die Karten können direkt vom DWD eingebunden werden. Hinweise dazu gibt es im [https://forum.fhem.de/index.php/topic,53157.0.html Supportthread im Forum].

Das GDS-Modul wurde mittlerweile auf "non-blocking" umgeschrieben, führt aber dennoch hin und wieder zu Meldungen einzelner Nutzer, dass FHEM "einfriert" (nichts macht), während auf die Rückmeldung von, z. B., einem FTP-Transfer ("get [gdsName] conditionsmap" etc.) gewartet wird. Das kann bei Timing-kritischen Bestandteilen zu Problemen führen, weil Events nicht mitbekommen werden, die Ansteuerung von Geräten nicht funktioniert, etc.

Einige dieser FHEM blockierenden Aktivitäten lassen sich mittels cron recht einfach auslagern (z. B. der ftp Transfer), für andere müsste das GDS-Modul umgeschrieben werden. Details dazu gibt es z. B. in {{Link2Forum|Topic=38106|LinkText=diesem schon etwas älteren Thread}} im Forum.

Nachfolgend noch eine Möglichkeit, das regelmäßige Laden der Karten vom Server in einen - dann FHEM nicht mehr blockierenden - cron-Job auszulagern:

Was Ihr wissen müsst:
*Wo legt das GDS-Modul die Karten ab? Z. B. im Temporär-Verzeichnis, /tmp. Wenn Ihr eine radarmap gespeichert habt, findet Ihr den Speicherort recht einfach, indem Ihr unter Linux <code>cd / && find . | grep gds_radarmap.jpg</code> ausführt.
*Wo liegen die Karten auf dem DWD-ftp-Server? Die Adresse des Servers ist [ftp://ftp-outgoing2.dwd.de ftp://ftp-outgoing2.dwd.de] und die Karten findet Ihr unterhalb von [ftp://ftp-outgoing2.dwd.de/gds/specials/ ftp://ftp-outgoing2.dwd.de/gds/specials/], z. B. die conditions maps unter [ftp://ftp-outgoing2.dwd.de/gds/specials/observations/maps/germany/ ftp://ftp-outgoing2.dwd.de/gds/specials/observations/maps/germany/], radarmaps unter [ftp://ftp-outgoing2.dwd.de/gds/specials/radar/ ftp://ftp-outgoing2.dwd.de/gds/specials/radar/] und dann dem passenden Unterverzeichnis für Eure Region, etc.
*Eure Login-Daten für den DWD ftp-server (habt Ihr vom DWD zugeschickt bekommen und in die Definition des GDS-Moduls eingetragen).

Anbei ein Beispielscript, das jeweils die neueste conditions- und Radarmap für Südwest-Deutschland holt und im /tmp-Verzeichnis ablegt:
<pre>
#!/bin/bash
if [ ! -d "/tmp/gds" ]; then
mkdir /tmp/gds
fi
# ftp-Server als Verzeichnis mounten:
curlftpfs ftp-outgoing2.dwd.de /tmp/gds -o user=user:pass
cd /tmp/gds/gds/specials/radar/southwest
NEUESTE_DATEI=$(ls -t | head -n 1)
echo Downloading ${NEUESTE_DATEI}...
cp "${NEUESTE_DATEI}" "/tmp/gds_radarmap.jpg"
echo ok.
chown fhem:dialout /tmp/gds_radarmap.jpg
cd /tmp/gds/gds/specials/observations/maps/germany
NEUESTE_DATEI=$(ls -t Suedwest* | head -n 1)
echo Downloading ${NEUESTE_DATEI}...
cp "${NEUESTE_DATEI}" "/tmp/gds_conditionsmap.jpg"
echo ok.
chown fhem:dialout /tmp/gds_conditionsmap.jpg
# unmount
fusermount -u /tmp/gds
</pre>

Hinweise:
*user:pass durch Eure Login-Daten für den Server ersetzen.
*/tmp ggf. anpassen, wenn bei Euch die GDS-Karten in einem anderen Verzeichnis liegen.
*"Suedwest" durch Eure Region ersetzen. Dateinamen können auf dem ftp-Server eingesehen werden.
*Die Angabe von user:pass im Klartext im Script ist unsicher. Sicherer wäre die Angabe einer versteckten und in den Rechten beschränkten Konfigurationsdatei.
*fhem:dialout sind die Rechte unter Debian. Mit einem <code>li -l</code> im Verzeichnis, in dem GDS die Karten ablegt, könnt Ihr Euch - vor dem Ausführen des Scripts - den Benutzer und die Rechte ansehen, wie das GDS-Modul bei Euch die Karten ablegt.
*Das Script braucht curlftpfs, das sich i.d.R. problemlos mittels <code>apt-get install curlftpfs</code> (Debian) o.ä. installieren lassen sollte.

Dann das Script noch regelmäßig über cron ausführen lassen, und schon blockiert Euer FHEM an einer Stelle weniger.

== Links ==
* [[Wetter und Wettervorhersagen]]

Homebridge einrichten

2017-12-29T08:53:10Z

Motivierte linke Hände: Link auf systemd-Skript im Homebridge-Wiki eingefügt.

Dieses HOWTO zeigt die Installation und Erstinbetriebnahme von Homebridge.

Damit kann Siri benutzt werden, um FHEM-Devices zu steuern. So können Devices angesprochen werden, die offiziell HomeKit nicht unterstützen (die Vorgehensweise wurde auf einem Intel NUC mit Ubuntu Server 14.04 LTS und auf einem Raspberry Pi mit Raspian getestet). Der WIKI-Eintrag bezieht sich hauptsächlich auf eine {{Link2Forum|Topic=32652|LinkText=Diskussion im FHEM-Forum}}. Ein Riesendank gilt vor allem {{Link2FU|430|Andre (justme1968)}}.

Die Konfiguration der inzwischen aktuellen zweiten Version des Homekit-Plugins ist in einem neuen {{Link2Forum|Topic= 48558 |LinkText=Thread im FHEM-Forum}} beschrieben. Hinzugekommen ist vor allem die freie Konfigurierbarkeit der Zuordnung zwischen FHEM Device und Homekit Accessory/Service, zwischen FHEM Reading und Homekit Characteristic, das mapping vom FHEM Readingwerten zu Homekit Werten sowie das Mapping von Homekit Werten zu FHEM Set-Kommandos und Werten.

Eine Sammlung funktionsfähiger Homebridge FHEM Konfiguration kann hier gefunden werden: [[Homebridge User Configs]]. Die Sammlung befindet sich noch im Aufbau.

= Vorbereitung der Umgebung =

== NodeJS installieren ==
''Die nachfolgenden Befehle sind alle mit "sudo" prefixed. Wenn du unter "root" arbeitest oder deine Distribution einen anderen Mechanismus verwendet, so kannst du dies natürlich weglassen.''

Zunächst wird das Betriebssystem (in diesem Falle Debian oder Ubuntu) auf den aktuellen Stand gebracht:
<syntaxhighlight lang="bash" style="width:50%;">
sudo apt-get update
sudo apt-get upgrade
sudo apt-get install build-essential libssl-dev</syntaxhighlight>

Nun muss NodeJS installiert werden. Leider ist die Version im Debian Repository deutlich zu alt, daher wird mit den folgenden Befehlen das Node Repository hinzugefügt und NodeJS (in der LTS Version) entsprechend installiert:

'''NodeJS V4'''
<syntaxhighlight lang="bash" style="width:50%;">
curl -sL https://deb.nodesource.com/setup_4.x | sudo -E bash -
sudo apt-get install -y nodejs
</syntaxhighlight>

{{Randnotiz|RNTyp=y|RNText=Bei Installation von NodeJS auf einem "alten" RasPi (B) bitte die besonderen Hinweise in {{Link2Forum|Topic=32652|Message=419325|LinkText=diesem Forenbeitrag}} beachten.}}
'''NodeJS V5'''
<syntaxhighlight lang="bash" style="width:50%">
curl -sL https://deb.nodesource.com/setup_5.x | sudo -E bash -
sudo apt-get install -y nodejs
</syntaxhighlight>

'''NodeJS V6'''
<syntaxhighlight lang="bash" style="width:50%">
curl -sL https://deb.nodesource.com/setup_6.x | sudo -E bash -
sudo apt-get install -y nodejs
</syntaxhighlight>

Damit ist NodeJS installiert.

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

Nun sind alle Voraussetzungen geschaffen.

= Installation von Homebridge & notwendiger Shims =
Im Nachfolgenden Absatz wird die Installation von Homebridge sowie des notwendigen Plugins (Shim) für FHEM erläutert.
Eventuell muss vor die Befehle ein
<syntaxhighlight lang="bash" style="width:50%;">
sudo
</syntaxhighlight>
vorangestellt werden.
== Homebridge installieren ==
Die aktuelle Homebridge version wird mit
<syntaxhighlight lang="bash" style="width:50%;">
npm install -g --unsafe-perm homebridge
</syntaxhighlight>
installiert, was eine Weile dauert. Anschließend wird der FHEM platform shim mit:
<syntaxhighlight lang="bash" style="width:60%;">
npm install -g homebridge-fhem
</syntaxhighlight>
installiert.

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

Kommt eine DNS Fehlermeldung fehlt meistens der AVAHI-DAEMON, zu installieren via
<syntaxhighlight lang="bash" style="width=50%">
sudo apt-get install avahi-daemon
</syntaxhighlight>

Wenn npm beim Kompilieren von mdns mit der Meldung abbricht, dass "dns_sd.h" nicht gefunden wird, fehlt das Paket libavahi-compat-libdnssd-dev, zu installieren via
<syntaxhighlight lang="bash" style="width=50%">
sudo apt-get install libavahi-compat-libdnssd-dev
</syntaxhighlight>

== Homebridge aktualisieren ==
Prüfen, ob es Updates gibt:
<syntaxhighlight lang="bash" style="width:50%;">
npm -g outdated
</syntaxhighlight>
Die aktuelle Homebridge version wird mit
<syntaxhighlight lang="bash" style="width:50%;">
npm -g update homebridge
</syntaxhighlight>
installiert, was eine Weile dauert. Anschließend wird der FHEM platform shim mit:
<syntaxhighlight lang="bash" style="width:60%;">
npm -g update homebridge-fhem
</syntaxhighlight>
installiert.

Sollte dies nicht funktionieren, kann mit
<syntaxhighlight lang="bash" style="width:60%;">
npm -g install homebridge
</syntaxhighlight>
bzw.
<syntaxhighlight lang="bash" style="width:60%;">
npm -g install homebridge-fhem
</syntaxhighlight>
das Update installiert werden.

= Homebridge konfigurieren =
''Wichtig: Für die weiteren Schritte sollte man nicht root verwenden, sondern beispielsweise einen dedizierten Nutzer für homebridge oder der Einfachheit halber den Nutzer, unter dem auch FHEM läuft (meist "fhem").''

== Einstellungen für homebridge ==
Zunächst wird das Verzeichnis für die Konfigurationsdatei erstellt und in dieses gewechselt:
<syntaxhighlight lang="bash" style="width:50%;">
mkdir -p ~/.homebridge
cd ~/.homebridge/
</syntaxhighlight>

Nun muss darin noch die config.json erstellt bzw. angepasst werden:
<syntaxhighlight lang="bash" style="width:50%;">
nano ~/.homebridge/config.json
</syntaxhighlight>

Hinweise zur Konfiguration:
* "''bridge''":
** "''username''": Sollte so belassen werden. Sollte später auf dem iOS Device keine Homebridge gefunden werden, so kann man hier beispielsweise den String auf 31 statt 30 enden lassen um so eine neue Homebridge vorzutäuschen.
** "''port''": Sollte so belassen werden
** "''pin''": Der PIN kann beliebig in dem Format xxx-xx-xxx angepasst werden. Dieser muss nur einmal bei der Einrichtung in iOS eingegeben werden.
* "''platforms''":
** "''platform''": Hier muss "FHEM" beibehalten werden.
** "''server''": Hier muss die IP des FHEM-Servers eingetragen werden. Dabei muss Homebridge nicht auf dem selben Server laufen wie FHEM, kann aber. Wenn es auf dem gleichen Rechner läuft, dann bietet es sich an, die IP 127.0.0.1 zu verwenden.
** "''port''": Hier muss der Port des gewählten FHEMWEBS eingetragen werden (muss nicht das "normale" sein, kann eine extra Instanz sein)
** "''auth''": Ist FHEM nicht mit Nutzername/Password abgesichert, so kann man diese Zeile einfach entfernen.
** "''filter''": Damit nicht alle Devices von Homebridge berücksichtigt werden, bietet es sich an, die Devices zu filtern. In diesem Beispiel wurden alle Devices, die über Siri steuerbar sein sollen, zusätzlich in den Raum Homekit konfiguriert.
<syntaxhighlight 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": "127.0.0.1",
"port": "8083",
"auth": {"user": "FhemUser", "pass": "XXX"},
"filter": "room=Homekit"
}
],

"accessories": []
}
</syntaxhighlight>

Wenn für FHEMWEB kein user/password vergeben ist muss die "auth" Zeile weg gelassen werden.
Wird FHEM mit SSL abgesichert, so muss zusätzlich in der Sektion "platforms" noch diese Zeile (nach "port") eingefügt werden:
<syntaxhighlight lang="javascript" style="width:50%;">
"ssl": true,
</syntaxhighlight>
Wenn man SSL ohne user/password benutzt, muss man "auth" Zeile einfugen, wobei die Werte weggelassen werden:
<syntaxhighlight lang="javascript" style="width:50%;">
"auth": {"user": "", "pass": ""},
</syntaxhighlight>

Natürlich kann man auch nach beliebigen anderen Kriterien filtern. z.b. nach Device TYPE, nach subtype Attribut, ... Es können mehrere FHEM platforms Abschnitte mit eigenem Filter im config file stehen (dabei das Komma zwischen den einzelnen abschnitten nicht vergessen!) . Auch Geräte auf die mehr als ein Filterausdruck matched werden dabei nur ein mal hinzugefügt.

= FHEM konfigurieren =
Es empfiehlt sich ein siri Gerät in FHEM anzulegen.
define siri siri

Die benötigten Attribute werden inzwischen beim ersten Start des von hombridge-fhem automatisch auf FHEM Seite eingetragen.

Mehr zu den inzwischen verfügbaren Konfigurationsmöglichkeiten findet sich auf den github und npmjs Seiten des Plugins und im ersten Beitrag des zugehörigen Thread im {{Link2Forum|Topic= 48558 |LinkText=Diskussion im FHEM-Forum}}

= Start von Homebridge =

== Hinweis ==
Nach allen Änderungen die in FHEM gemacht werden, welche Homebridge betreffen, muss Homebridge neu gestartet werden. Wie der Neustart erfolgen muss, ist abhängig davon, wie man Homebridge gestartet hat. Bitte den entsprechenden Methoden entnehmen.

== Einmaliger Manueller Start ==
<syntaxhighlight lang="bash" style="width:50%;">
homebridge
</syntaxhighlight>

Homebridge sollte nun laufen. Hier kann man die Kommunikation nachverfolgen. Abbrechen kann das ganze mit CTRL+c (es dann auch keine Befehle mehr mit Siri möglich). Damit Siri auch Befehle ohne ständig offenes Terminal bearbeiten kann, bitten nächsten Punkt beachten.

=== Fehler während des Manuellen Starts ===
Kommt ein Fehler der ähnlich aussieht wie folgender, sollte zu erst die Nodesversion geprüft werden.
Die Nodes version kann durch ein System Update auf eine niedrigere Version wie benötigt gedowngraded werden
<syntaxhighlight lang="bash" style="width=50%">
Error: Module version mismatch. Expected 47, got 46.
at Error (native)
at Object.Module._extensions..node (module.js:450:18)
at Module.load (module.js:356:32)
at Function.Module._load (module.js:313:12)
at Module.require (module.js:366:17)
at require (module.js:385:17)
at Object.<anonymous> (/usr/lib/node_modules/homebridge/node_modules/mdns/lib/dns_sd.js:24:20)
at Module._compile (module.js:425:26)
at Object.Module._extensions..js (module.js:432:10)
at Module.load (module.js:356:32)
</syntaxhighlight>
Geprüft werden kann die Nodes Version mit:
<syntaxhighlight lang="bash" style="width=50%">node -v zeigt mir: v0.10.28, nodejs -v: v5.11.1</syntaxhighlight>
Hier ist die Version v0.10.28 wobei v0.12 Mindestvorraussetzung ist.
Die installation der richtigen Nodes Version kann oben am Anhang des Wiki Artikels entnommen werden.

== Homebridge automatisch starten ==
Es gibt verschiedene Methoden, Homebridge automatisch zu starten.

=== Steuerung via FHEM ===
Auf Basis der unten stehenden ''Alternativen Methode'' wurde eine Version entwickelt, mit der man auch den Status einsehen und den Restart des Dienstes aus FHEM heraus erledigen kann. Diese Version ist auf der Seite [[Homebridge Start und Status in FHEM]] im Detail beschrieben.

=== Alternative Methode: Init-Skript ===
Dies startet homebridge als einen Service.

==== Service anlegen ====
<code>
sudo nano /etc/init.d/homebridge
</code>

Code einfügen (startet den Homebridge Server als Benutzer "pi" und nimmt an, dass sich .homebridge/config.json in seinem Homeverzeichnis unter /home/pi/ befindet):

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

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

=== Alternative Methode: systemd ===

Während das Init-Skript grundsätzlich auch mit systemd funktioniert, kann man natürlich für Homebridge auch ein systemd-Skript anlegen. Wie das geht, ist im [https://github.com/nfarina/homebridge/wiki/Running-HomeBridge-on-a-Raspberry-Pi#running-homebridge-on-bootup-systemd Wiki zu Homebridge] beschrieben.

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

Um HM-CC-RT-DN Thermostate steuern zu können, muss wie oben beschrieben folgendes attribute gesetzt werden (hier als Beispiel das Device "Heizung"):
# attr Heizung subtype thermostat
Für einen Dummy muss man den genericDeviceType setzen, also beispielsweise:
# attr Dummy genericDeviceType switch
# attr Dummy setList on off

Wie bereits vorher angemerkt: fügt man ein Device hinzu oder führt eine Änderung an einem Device durch, so sollte homebridge neu gestartet werden.

= HomeKit in iOS =

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

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

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

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

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

= Hinweise =

== Unterstützte Geräte ==
Das Fhem Plugin von {{Link2FU|430|Andre (justme1968)}} unterstützt automatisch mindestens die folgenden Geräte:

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

Über eine entsprechende Konfiguration lässt sich darüber hinaus jedes mit FHEM steuerbare Gerät auf die unterstützten Homekit typen abbilden.

Die aktuelle Liste und eine Beschreibung der Konfigurationsmöglichkeiten findet sich [https://www.npmjs.com/package/homebridge-fhem auf den npmjs seiten] bzw. [https://github.com/justme-1968/homebridge-fhem auf github].

== Zusätzliche Plugins ==
Für manche der über FHEM steuerbaren Geräte wie z.b. MiiLight, Harmony Hub, Phillips Hue, Sonos,... gibt es eigene homekit plugins. Wenn immer möglich, empfiehlt es sich aber diese '''nicht''' zu verwenden, sondern die Steuerung über die FHEM-Integration zu realisieren, da
* diese in der Regel sehr viel mächtiger und frei konfigurierbar ist
* es FHEM erlaubt, als zentrale Instanz den Überblick über den aktuellen Gesamtzustand zu haben (wichtig bei Geräten, die gepollt werden)
* die Ressourcen auf den angesteuerten Geräten schont, da Werte optimal gecached werden und nur eine einzige Verbindung aufgebaut wird

== Hinweis für alte homebridge Versionen ==
UPDATE: Homebridge funktioniert mit einer kleinen Einschränkung nun auch mit node 4.0.0. Laut
[https://github.com/cflurin/homebridge-shims/wiki/Minimalist-Homebridge-on-a-Raspberry-Pi Homebridge on a Raspberry Pi] müssen die folgenden Abhängigkeiten (Dependencies) aus der '''package.json''' entfernt werden:
<pre>
"harmonyhubjs-client": "^1.1.4",
"harmonyhubjs-discover": "git+https://github.com/swissmanu/harmonyhubjs-discover.git"
</pre>

== Hinweis zur Geschwindigkeitsoptimierung auf einem Raspberry PI ==

Damit es auf einem Raspberry schneller läuft, wird darüber hinaus empfohlen, auch diverse Abhängigkeiten aus der '''package.json''' zu entfernen:
<pre>
"ad2usb": "git+https://github.com/alistairg/node-ad2usb.git#local",
"carwingsjs": "0.0.x",
"chokidar": "^1.0.5",
"eibd": "^0.3.1",
"elkington": "kevinohara80/elkington",
"harmonyhubjs-client": "^1.1.4",
"harmonyhubjs-discover": "git+https://github.com/swissmanu/harmonyhubjs-discover.git",
"lifx-api": "^1.0.1",
"lifx": "git+https://github.com/magicmonkey/lifxjs.git",
"node-hue-api": "^1.0.5",
"node-icontrol": "^0.1.4",
"node-milight-promise": "0.0.x",
"tough-cookie": "^2.0.0",
"sonos": "0.8.x",
"telldus-live": "0.2.x",
"teslams": "1.0.1",
"unofficial-nest-api": "git+https://github.com/hachidorii/unofficial_nodejs_nest.git#d8d48edc952b049ff6320ef99afa7b2f04cdee98",
"wemo": "0.2.x",
"wink-js": "0.0.5",
"komponist" : "0.1.0",
"yamaha-nodejs": "0.4.x",
</pre>

Daher zunächst ein ein Backup der Datei anlegen
<pre>sudo cp package.json package.json.bkp </pre>
Am einfachsten geht das entfernen der Zeilen mit einem Editor, beispielsweise nano oder vi.
<pre>sudo nano package.json</pre>

Das config file sollte dann wie folgt aussehen: Achtung vor den letzten zwei "}" am Ende darf kein Komma sein.
<syntaxhighlight 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"
}
}
</syntaxhighlight>

== Links ==
* [https://github.com/nfarina/homebridge Github homebridge]
* [https://github.com/justme-1968/homebridge-fhem Github homebridge-fhem]
* [https://www.npmjs.com/package/homebridge NPM homebridge]
* [https://www.npmjs.com/package/homebridge-fhem NPM homebridge-fhem]

[[Kategorie:HOWTOS]]
[[Kategorie:Sprachsteuerung]]

Homebridge Start und Status in FHEM

2017-11-16T06:39:20Z

Motivierte linke Hände: Startskript angepasst, set $fhemdefine on/off für Status angepasst, damit der Status des Dummys stimmt, wenn start oder stop fehlgeschlagen ist. Spacing vereinheitlicht.

Um nicht bei jeder Änderung, welche die Homebridge betrifft, diese über die Console manuell neustarten zu müssen zeigt diese Lösung wie dies bequem aus FHEMWEB erfolgen kann. In den nachfolgenden Abschnitten sind die einzelnen Schritte dazu erläutert.

== Vorwort ==
Die im weitern genutzten Bezeichnungen von Dummys, Scriptdateinamen o.ä. können geändert werden. Die Änderungen müssen jedoch auch an allen entsprechenden Stellen vorgenommen werden.
Genannte IP Adressen, Benutzernamen und Passwörter sind auf die eigenen Gegebenheiten anzupassen. Die Berechtigungen des Benutzers müssen zur Ausführung der Scripte geprüft und ggf. angepasst werden. Entprechende Linux Kentnisse sollten vorhanden sein. Dieser Artikel berücksichtigt das FHEM und Homebridge nicht zwingend auf dem selben System laufen. Die hier gezeigte Lösung kann für beide Varianten genutzt werden, FHEM und Homebridge auf dem gleichen System oder auf getrennten Systemen.

== Umsetzung ==

=== Status- und Kontroll-Dummy ===
[[Datei:HomebridgeDummy.PNG|mini|550px|Status- bzw. Kontroll-Dummy]]

Es wird ein Dummy benötigt, welcher den Status des Homebridge-Dienstes anzeigt und über den dieser Dienst gesteuert werden kann. Das nötige Script um die Homebridge als Dienst zu starten wird weiter unten in diesem Artikel erstellt.

<syntaxhighlight lang="bash" style="width:100%;">
define SYS_Homebridge dummy
attr SYS_Homebridge devStateIcon .*on:general_an .*off:general_aus .*:audio_rec
attr SYS_Homebridge eventMap status:status start:start stop:stop restart:restart
attr SYS_Homebridge icon it_router
attr SYS_Homebridge room System
attr SYS_Homebridge userReadings OnStateChange:(start|stop|restart|status) { system ("sudo service homebridge ".ReadingsVal($NAME,"state","restart")." &" );; }
attr SYS_Homebridge webCmd status:start:stop:restart
</syntaxhighlight>

Der Dummy wird durch setzen von "start", "stop", "restart" oder "status" jeweils das userReading ausführen und somit letztendlich den homebridge Dienst steuert.

=== Start Script anlegen ===
Nun ist das Startscript für die Homebridge anzulegen. Mittels dem folgenden Befehl wird (wenn noch nicht vorhanden) das homebridge Script angelegt und im Editor geöffnet.

<syntaxhighlight lang="bash" style="width:100%;">
sudo nano /etc/init.d/homebridge
</syntaxhighlight>
Wenn die Homebridge nicht auf dem selben System läuft wie FHEM muss dieser Schritt auf dem Homebridge System ausgeführt werden.

Das nun folgende Script kann in die homebridge Datei, die im Nano Editor geöffnet, ist rein kopiert werden.

'''Achtung''': die Variabeln ''homeBridgeUser'', ''fhemHost'' und ''fhemHostTelnetPort'' sind ggf. auf die eigenen Gegebenheiten anzupassen.

<syntaxhighlight lang="bash" style="width:100%;">
#!/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`
homeBridgeUser="fhem"
fhemHost=127.0.0.1 #FHEM Server (Masterinstanz)
fhemHostTelnetPort=7072 #TelnetPort der FHEM Instanz
fhemDefine="SYS_Homebridge"

case "$1" in
start)
if ps -p $PID > /dev/null 2>&1; then
echo "Homebridge is already running"
perl /opt/fhem/fhem.pl $fhemHost:$fhemHostTelnetPort "setreading $fhemDefine info Homebridge is already running"
else
su - $homeBridgeUser -c "homebridge > /dev/null 2>&1 &"
echo "Homebridge starting"
perl /opt/fhem/fhem.pl $fhemHost:$fhemHostTelnetPort "setreading $fhemDefine info Homebridge starting"
perl /opt/fhem/fhem.pl $fhemHost:$fhemHostTelnetPort "set $fhemDefine on"
sleep 2
$0 status
fi
;;
stop)
if ! ps -p $PID > /dev/null 2>&1; then
echo "Homebridge is not running"
perl /opt/fhem/fhem.pl $fhemHost:$fhemHostTelnetPort "setreading $fhemDefine info Homebridge is not running"
else
kill $PID
echo "Homebridge stopping"
perl /opt/fhem/fhem.pl $fhemHost:$fhemHostTelnetPort "setreading $fhemDefine info Homebridge stopping"
perl /opt/fhem/fhem.pl $fhemHost:$fhemHostTelnetPort "set $fhemDefine off"
sleep 2
$0 status
fi
;;
restart)
if ! ps -p $PID > /dev/null 2>&1; then
$0 start
else
$0 stop
$0 start
fi
;;
status)
if ps -p $PID > /dev/null 2>&1; then
echo "Homebridge is running PID $PID"
perl /opt/fhem/fhem.pl $fhemHost:$fhemHostTelnetPort "setreading $fhemDefine info Homebridge running as PID $PID"
perl /opt/fhem/fhem.pl $fhemHost:$fhemHostTelnetPort "set $fhemDefine on"
else
echo "Homebridge is not running"
perl /opt/fhem/fhem.pl $fhemHost:$fhemHostTelnetPort "setreading $fhemDefine info Homebridge is not running"
perl /opt/fhem/fhem.pl $fhemHost:$fhemHostTelnetPort "set $fhemDefine off"
fi
;;
*)
echo "Usage: $0 {start|stop|status|restart}"
exit 1
;;
esac
exit 0

</syntaxhighlight>

Das Script setzt in dem bereits angelegten Dummy ein Reading ''info'' in dem der Ausführungsstatus des Scripts wieder gegeben wird. Das Reading ''state'' wir auf on oder off gesetzt. ''On'' bedeutet das Homebridge gestartet ist, ''off'' das die Homebridge nicht ausgeführt wird.

Damit die Homebridge auch mit Start des Systems gestartet wird sind die folgenden zwei Schritte notwendig

<syntaxhighlight lang="bash" style="width:100%;">
sudo chmod 755 /etc/init.d/homebridge
sudo update-rc.d homebridge defaults
</syntaxhighlight>

Zum testen kann der Dienst nun mit dem Befehl

<syntaxhighlight lang="bash" style="width:100%;">
sudo service homebridge start
</syntaxhighlight>
bzw.
<syntaxhighlight lang="bash" style="width:100%;">
sudo /etc/init.d/homebridge start
</syntaxhighlight>

gestartet werden. In dem angelegten Dummy werden zwei Readings erzeugt mit den entsprechenden Rückmeldungen aus dem Script. Die Readings werden erst angezeigt wenn die bereits geöffnete Detailseite des Dummys neu geladen wird.

=== Testlauf / Fertig ===
Nun können die einzelnen Aktionen über den Dummy ausführt werden. Dabei wird jeweils der eingerichtete Dienst angesteuert und eine (mit kurzer Verzögerung) Rückmeldung gegeben.

== Sonstiges ==

=== FHEM Benutzer Zugriff auf Script gewähren ===

Damit aus FHEM das Script ausgeführt werden kann benötigt dieser Benutzer entsprechende Berechtigungen. Dazu ist in der sudoers ein Eintrag zu ergänzen.
Dazu wird die sudoers Datei im Nano Editor geöffnet

<syntaxhighlight lang="bash" style="width:100%;">
sudo nano /etc/sudoers
</syntaxhighlight>

Dort sollte im Abschnitt ''# User privilege specification'' die folgende Zeile ergänzt werden

<syntaxhighlight lang="bash" style="width:100%;">
fhem ALL=(ALL) NOPASSWD:/etc/init.d/homebridge
</syntaxhighlight>

bzw. unter Raspbian Jessie (vgl.: [https://forum.fhem.de/index.php/topic,66841.msg581747.html#msg581747 Forenbeitrag]):

<syntaxhighlight lang="bash" style="width:100%;">
fhem ALL=(ALL) NOPASSWD:/usr/sbin/service
</syntaxhighlight>
'''Achtung!''' Sollte FHEM nicht unter dem Benuter ''fhem'' laufen ist dies an den entsprechenden Stellen anzupassen.

Beispielinhalt der sudoers:
<syntaxhighlight lang="bash" style="width:100%;">
#
# This file MUST be edited with the 'visudo' command as root.
#
# Please consider adding local content in /etc/sudoers.d/ instead of
# directly modifying this file.
#
# See the man page for details on how to write a sudoers file.
#
Defaults env_reset
Defaults mail_badpass
Defaults secure_path="/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin"

# Host alias specification

# User alias specification

# Cmnd alias specification

# User privilege specification
root ALL=(ALL:ALL) ALL
fhem ALL=(ALL) NOPASSWD:/etc/init.d/homebridge

# Members of the admin group may gain root privileges
%admin ALL = (ALL) NOPASSWD: ALL

# Allow members of group sudo to execute any command
%sudo ALL=(ALL:ALL) ALL

# See sudoers(5) for more information on "#include" directives:

#includedir /etc/sudoers.d
</syntaxhighlight>

[[Kategorie:HOWTOS]]

=== Anpassung wenn FHEM und Homebridge auf getrennten Systemen laufen ===
Unter dem Kapitel [[Umsetzung]] wurde bereits alles vorbereitet um mit wenigen Änderungen eine Homebridge zu starten die nicht auf dem selben System läuft wie FHEM. Es sind nur 2 Änderungen notwendig.
Die erste Änderung betrifft den eingerichteten Dummy. Hier ist das vorhandenen ''userReadings'' wie folgt abzuändern

<syntaxhighlight lang="bash" style="width:100%;">
attr SYS_Homebridge userReadings OnStateChange:(start|stop|restart|status) { system ("sudo /opt/fhem/FHEM/homebridgeserviceremote.sh ".ReadingsVal($NAME,"state","restart")." &" );; }
</syntaxhighlight>

Dadurch wird, durch die Aktionen des Dummys, ein weiteres Script angesprochen.

Nun wird dieses Script mit hilfe des Nano Editor angelegt

<syntaxhighlight lang="bash" style="width:100%;">
sudo nano /opt/fhem/FHEM/homebridgeserviceremote.sh
</syntaxhighlight>

und mit dem folgenden Inhalt befüllt.

'''Achtung''': die Variabeln ''remoteUser'', ''remotePasswort'' und ''remoteHost'' sind ggf. auf die eigenen Gegebenheiten der entfernt laufenden Homebridge anzupassen. Der hier genannte Benutzer muss natürlich berechtigt sein die Homebridge starten zu können. Es sollte auch nicht der root User verwendet werden, sondern ein eigens dafür angelegter und in den Berechtigungen eingeschränkter Benutzer verwendet werden.
Wer zur Fehleranalyse etwas mehr sehen möchte ändert den Wert von ''debug'' auf 1.

<syntaxhighlight lang="bash" style="width:100%;">
#!/bin/bash
debug=0
remoteUser="root"
remotePasswort="root"
remoteHost="192.168.1.111"
remoteService="homebridge"
fhemHostTelnetPort=7072 #TelnetPort der FHEM Instanz

# Vorraussetzungen prüfen
if [ $(dpkg-query -W -f='${Status}' sshpass 2>/dev/null | grep -c "ok installed") -eq 0 ];
then
if [ "$debug" = "1" ]; then
echo "sshpass wird benötigt. Installation beginnt";
perl /opt/fhem/fhem.pl $fhemHostTelnetPort "{Log 1, \"[homebridgeserviceremote.sh] sshpass wird benötigt. Installation beginnt\"}";
fi
apt-get install sshpass
if [ "$debug" = "1" ]; then
echo "sshpass wurde installiert";
perl /opt/fhem/fhem.pl $fhemHostTelnetPort "{Log 1, \"[homebridgeserviceremote.sh] sshpass wurde installiert\"}";
fi
fi
###################################

# Befehl ausführen
case "$1" in
start)
if [ "$debug" = "1" ]; then
echo "Ausführen von 'sudo service $remoteService start' auf '$remoteHost' als '$remoteUser'";
perl /opt/fhem/fhem.pl $fhemHostTelnetPort "{Log 1, \"[homebridgeserviceremote.sh] Ausführen von 'sudo service $remoteService start' auf '$remoteHost' als '$remoteUser'\"}";
fi
sshpass -p "$remotePasswort" ssh -o StrictHostKeyChecking=no $remoteUser@$remoteHost "sudo service $remoteService start"
if [ "$debug" = "1" ]; then
echo "Ausführung beendet";
perl /opt/fhem/fhem.pl $fhemHostTelnetPort "{Log 1, \"[homebridgeserviceremote.sh] Ausführung beendet\"}";
fi
;;
stop)
if [ "$debug" = "1" ]; then
echo "Ausführen von 'sudo service $remoteService stop' auf '$remoteHost' als '$remoteUser'";
perl /opt/fhem/fhem.pl $fhemHostTelnetPort "{Log 1, \"[homebridgeserviceremote.sh] Ausführen von 'sudo service $remoteService stop' auf '$remoteHost' als '$remoteUser'\"}";
fi
sshpass -p "$remotePasswort" ssh -o StrictHostKeyChecking=no $remoteUser@$remoteHost "sudo service $remoteService stop"
if [ "$debug" = "1" ]; then
echo "Ausführung beendet";
perl /opt/fhem/fhem.pl $fhemHostTelnetPort "{Log 1, \"[homebridgeserviceremote.sh] Ausführung beendet\"}";
fi
;;
restart)
if [ "$debug" = "1" ]; then
echo "Ausführen von 'sudo service $remoteService restart' auf '$remoteHost' als '$remoteUser'";
perl /opt/fhem/fhem.pl $fhemHostTelnetPort "{Log 1, \"[homebridgeserviceremote.sh] Ausführen von 'sudo service $remoteService restart' auf '$remoteHost' als '$remoteUser'\"}";
fi
sshpass -p "$remotePasswort" ssh -o StrictHostKeyChecking=no $remoteUser@$remoteHost "sudo service $remoteService restart"
if [ "$debug" = "1" ]; then
echo "Ausführung beendet";
perl /opt/fhem/fhem.pl $fhemHostTelnetPort "{Log 1, \"[homebridgeserviceremote.sh] Ausführung beendet\"}";
fi

;;
status)
if [ "$debug" = "1" ]; then
echo "Ausführen von 'sudo service $remoteService status' auf '$remoteHost' als '$remoteUser'";
perl /opt/fhem/fhem.pl $fhemHostTelnetPort "{Log 1, \"[homebridgeserviceremote.sh] Ausführen von 'sudo service $remoteService status' auf '$remoteHost' als '$remoteUser'\"}";
fi
sshpass -p "$remotePasswort" ssh -o StrictHostKeyChecking=no $remoteUser@$remoteHost "sudo service $remoteService status"
if [ "$debug" = "1" ]; then
echo "Ausführung beendet";
perl /opt/fhem/fhem.pl $fhemHostTelnetPort "{Log 1, \"[homebridgeserviceremote.sh] Ausführung beendet\"}";
fi
;;
*)
echo "Usage: $0 {start|stop|status|restart}"
exit 1
;;
esac
exit 0
###################################
</syntaxhighlight>

Das Script macht nicht sehr viel. Es verbindet sich über ssh mit dem entfernten System und startet (stopt, etc.) den Homebridge Dienst. Hinweis: es wird sshpass benötigt, welches das Script bei bedarf versucht zu installieren.

HINWEIS: Statt wie hier sshpass zu verwenden ist es besser ssh korrekt für zertifikatbasierten Zugriff zu konfigurieren.

== Dankeschön ==
Ein Dankeschön geht an die Entwicklergemeinde rund um Homebridge und dem FHEM Plugin für die Homebridge.

Ein besonderes Dankeschön an ''No Legend'' der die zugrunde liegende Idee und Lösung in diesem Artikel beschrieben hat.

Homebridge einrichten

2017-11-16T06:28:26Z

Motivierte linke Hände: verklickt... %-)

Dieses HOWTO zeigt die Installation und Erstinbetriebnahme von Homebridge.

Damit kann Siri benutzt werden, um FHEM-Devices zu steuern. So können Devices angesprochen werden, die offiziell HomeKit nicht unterstützen (die Vorgehensweise wurde auf einem Intel NUC mit Ubuntu Server 14.04 LTS und auf einem Raspberry Pi mit Raspian getestet). Der WIKI-Eintrag bezieht sich hauptsächlich auf eine {{Link2Forum|Topic=32652|LinkText=Diskussion im FHEM-Forum}}. Ein Riesendank gilt vor allem {{Link2FU|430|Andre (justme1968)}}.

Die Konfiguration der inzwischen aktuellen zweiten Version des Homekit-Plugins ist in einem neuen {{Link2Forum|Topic= 48558 |LinkText=Thread im FHEM-Forum}} beschrieben. Hinzugekommen ist vor allem die freie Konfigurierbarkeit der Zuordnung zwischen FHEM Device und Homekit Accessory/Service, zwischen FHEM Reading und Homekit Characteristic, das mapping vom FHEM Readingwerten zu Homekit Werten sowie das Mapping von Homekit Werten zu FHEM Set-Kommandos und Werten.

Eine Sammlung funktionsfähiger Homebridge FHEM Konfiguration kann hier gefunden werden: [[Homebridge User Configs]]. Die Sammlung befindet sich noch im Aufbau.

= Vorbereitung der Umgebung =

== NodeJS installieren ==
''Die nachfolgenden Befehle sind alle mit "sudo" prefixed. Wenn du unter "root" arbeitest oder deine Distribution einen anderen Mechanismus verwendet, so kannst du dies natürlich weglassen.''

Zunächst wird das Betriebssystem (in diesem Falle Debian oder Ubuntu) auf den aktuellen Stand gebracht:
<syntaxhighlight lang="bash" style="width:50%;">
sudo apt-get update
sudo apt-get upgrade
sudo apt-get install build-essential libssl-dev</syntaxhighlight>

Nun muss NodeJS installiert werden. Leider ist die Version im Debian Repository deutlich zu alt, daher wird mit den folgenden Befehlen das Node Repository hinzugefügt und NodeJS (in der LTS Version) entsprechend installiert:

'''NodeJS V4'''
<syntaxhighlight lang="bash" style="width:50%;">
curl -sL https://deb.nodesource.com/setup_4.x | sudo -E bash -
sudo apt-get install -y nodejs
</syntaxhighlight>

{{Randnotiz|RNTyp=y|RNText=Bei Installation von NodeJS auf einem "alten" RasPi (B) bitte die besonderen Hinweise in {{Link2Forum|Topic=32652|Message=419325|LinkText=diesem Forenbeitrag}} beachten.}}
'''NodeJS V5'''
<syntaxhighlight lang="bash" style="width:50%">
curl -sL https://deb.nodesource.com/setup_5.x | sudo -E bash -
sudo apt-get install -y nodejs
</syntaxhighlight>

'''NodeJS V6'''
<syntaxhighlight lang="bash" style="width:50%">
curl -sL https://deb.nodesource.com/setup_6.x | sudo -E bash -
sudo apt-get install -y nodejs
</syntaxhighlight>

Damit ist NodeJS installiert.

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

Nun sind alle Voraussetzungen geschaffen.

= Installation von Homebridge & notwendiger Shims =
Im Nachfolgenden Absatz wird die Installation von Homebridge sowie des notwendigen Plugins (Shim) für FHEM erläutert.
Eventuell muss vor die Befehle ein
<syntaxhighlight lang="bash" style="width:50%;">
sudo
</syntaxhighlight>
vorangestellt werden.
== Homebridge installieren ==
Die aktuelle Homebridge version wird mit
<syntaxhighlight lang="bash" style="width:50%;">
npm install -g --unsafe-perm homebridge
</syntaxhighlight>
installiert, was eine Weile dauert. Anschließend wird der FHEM platform shim mit:
<syntaxhighlight lang="bash" style="width:60%;">
npm install -g homebridge-fhem
</syntaxhighlight>
installiert.

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

Kommt eine DNS Fehlermeldung fehlt meistens der AVAHI-DAEMON, zu installieren via
<syntaxhighlight lang="bash" style="width=50%">
sudo apt-get install avahi-daemon
</syntaxhighlight>

Wenn npm beim Kompilieren von mdns mit der Meldung abbricht, dass "dns_sd.h" nicht gefunden wird, fehlt das Paket libavahi-compat-libdnssd-dev, zu installieren via
<syntaxhighlight lang="bash" style="width=50%">
sudo apt-get install libavahi-compat-libdnssd-dev
</syntaxhighlight>

== Homebridge aktualisieren ==
Prüfen, ob es Updates gibt:
<syntaxhighlight lang="bash" style="width:50%;">
npm -g outdated
</syntaxhighlight>
Die aktuelle Homebridge version wird mit
<syntaxhighlight lang="bash" style="width:50%;">
npm -g update homebridge
</syntaxhighlight>
installiert, was eine Weile dauert. Anschließend wird der FHEM platform shim mit:
<syntaxhighlight lang="bash" style="width:60%;">
npm -g update homebridge-fhem
</syntaxhighlight>
installiert.

Sollte dies nicht funktionieren, kann mit
<syntaxhighlight lang="bash" style="width:60%;">
npm -g install homebridge
</syntaxhighlight>
bzw.
<syntaxhighlight lang="bash" style="width:60%;">
npm -g install homebridge-fhem
</syntaxhighlight>
das Update installiert werden.

= Homebridge konfigurieren =
''Wichtig: Für die weiteren Schritte sollte man nicht root verwenden, sondern beispielsweise einen dedizierten Nutzer für homebridge oder der Einfachheit halber den Nutzer, unter dem auch FHEM läuft (meist "fhem").''

== Einstellungen für homebridge ==
Zunächst wird das Verzeichnis für die Konfigurationsdatei erstellt und in dieses gewechselt:
<syntaxhighlight lang="bash" style="width:50%;">
mkdir -p ~/.homebridge
cd ~/.homebridge/
</syntaxhighlight>

Nun muss darin noch die config.json erstellt bzw. angepasst werden:
<syntaxhighlight lang="bash" style="width:50%;">
nano ~/.homebridge/config.json
</syntaxhighlight>

Hinweise zur Konfiguration:
* "''bridge''":
** "''username''": Sollte so belassen werden. Sollte später auf dem iOS Device keine Homebridge gefunden werden, so kann man hier beispielsweise den String auf 31 statt 30 enden lassen um so eine neue Homebridge vorzutäuschen.
** "''port''": Sollte so belassen werden
** "''pin''": Der PIN kann beliebig in dem Format xxx-xx-xxx angepasst werden. Dieser muss nur einmal bei der Einrichtung in iOS eingegeben werden.
* "''platforms''":
** "''platform''": Hier muss "FHEM" beibehalten werden.
** "''server''": Hier muss die IP des FHEM-Servers eingetragen werden. Dabei muss Homebridge nicht auf dem selben Server laufen wie FHEM, kann aber. Wenn es auf dem gleichen Rechner läuft, dann bietet es sich an, die IP 127.0.0.1 zu verwenden.
** "''port''": Hier muss der Port des gewählten FHEMWEBS eingetragen werden (muss nicht das "normale" sein, kann eine extra Instanz sein)
** "''auth''": Ist FHEM nicht mit Nutzername/Password abgesichert, so kann man diese Zeile einfach entfernen.
** "''filter''": Damit nicht alle Devices von Homebridge berücksichtigt werden, bietet es sich an, die Devices zu filtern. In diesem Beispiel wurden alle Devices, die über Siri steuerbar sein sollen, zusätzlich in den Raum Homekit konfiguriert.
<syntaxhighlight 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": "127.0.0.1",
"port": "8083",
"auth": {"user": "FhemUser", "pass": "XXX"},
"filter": "room=Homekit"
}
],

"accessories": []
}
</syntaxhighlight>

Wenn für FHEMWEB kein user/password vergeben ist muss die "auth" Zeile weg gelassen werden.
Wird FHEM mit SSL abgesichert, so muss zusätzlich in der Sektion "platforms" noch diese Zeile (nach "port") eingefügt werden:
<syntaxhighlight lang="javascript" style="width:50%;">
"ssl": true,
</syntaxhighlight>
Wenn man SSL ohne user/password benutzt, muss man "auth" Zeile einfugen, wobei die Werte weggelassen werden:
<syntaxhighlight lang="javascript" style="width:50%;">
"auth": {"user": "", "pass": ""},
</syntaxhighlight>

Natürlich kann man auch nach beliebigen anderen Kriterien filtern. z.b. nach Device TYPE, nach subtype Attribut, ... Es können mehrere FHEM platforms Abschnitte mit eigenem Filter im config file stehen (dabei das Komma zwischen den einzelnen abschnitten nicht vergessen!) . Auch Geräte auf die mehr als ein Filterausdruck matched werden dabei nur ein mal hinzugefügt.

= FHEM konfigurieren =
Es empfiehlt sich ein siri Gerät in FHEM anzulegen.
define siri siri

Die benötigten Attribute werden inzwischen beim ersten Start des von hombridge-fhem automatisch auf FHEM Seite eingetragen.

Mehr zu den inzwischen verfügbaren Konfigurationsmöglichkeiten findet sich auf den github und npmjs Seiten des Plugins und im ersten Beitrag des zugehörigen Thread im {{Link2Forum|Topic= 48558 |LinkText=Diskussion im FHEM-Forum}}

= Start von Homebridge =

== Hinweis ==
Nach allen Änderungen die in FHEM gemacht werden, welche Homebridge betreffen, muss Homebridge neu gestartet werden. Wie der Neustart erfolgen muss, ist abhängig davon, wie man Homebridge gestartet hat. Bitte den entsprechenden Methoden entnehmen.

== Einmaliger Manueller Start ==
<syntaxhighlight lang="bash" style="width:50%;">
homebridge
</syntaxhighlight>

Homebridge sollte nun laufen. Hier kann man die Kommunikation nachverfolgen. Abbrechen kann das ganze mit CTRL+c (es dann auch keine Befehle mehr mit Siri möglich). Damit Siri auch Befehle ohne ständig offenes Terminal bearbeiten kann, bitten nächsten Punkt beachten.

=== Fehler während des Manuellen Starts ===
Kommt ein Fehler der ähnlich aussieht wie folgender, sollte zu erst die Nodesversion geprüft werden.
Die Nodes version kann durch ein System Update auf eine niedrigere Version wie benötigt gedowngraded werden
<syntaxhighlight lang="bash" style="width=50%">
Error: Module version mismatch. Expected 47, got 46.
at Error (native)
at Object.Module._extensions..node (module.js:450:18)
at Module.load (module.js:356:32)
at Function.Module._load (module.js:313:12)
at Module.require (module.js:366:17)
at require (module.js:385:17)
at Object.<anonymous> (/usr/lib/node_modules/homebridge/node_modules/mdns/lib/dns_sd.js:24:20)
at Module._compile (module.js:425:26)
at Object.Module._extensions..js (module.js:432:10)
at Module.load (module.js:356:32)
</syntaxhighlight>
Geprüft werden kann die Nodes Version mit:
<syntaxhighlight lang="bash" style="width=50%">node -v zeigt mir: v0.10.28, nodejs -v: v5.11.1</syntaxhighlight>
Hier ist die Version v0.10.28 wobei v0.12 Mindestvorraussetzung ist.
Die installation der richtigen Nodes Version kann oben am Anhang des Wiki Artikels entnommen werden.

== Homebridge automatisch starten ==
Es gibt verschiedene Methoden, Homebridge automatisch zu starten.

=== Steuerung via FHEM ===
Auf Basis der unten stehenden ''Alternativen Methode'' wurde eine Version entwickelt, mit der man auch den Status einsehen und den Restart des Dienstes aus FHEM heraus erledigen kann. Diese Version ist auf der Seite [[Homebridge Start und Status in FHEM]] im Detail beschrieben.

=== Alternative Methode ===
Dies startet homebridge als einen Service.

==== Service anlegen ====
<code>
sudo nano /etc/init.d/homebridge
</code>

Code einfügen (startet den Homebridge Server als Benutzer "pi" und nimmt an, dass sich .homebridge/config.json in seinem Homeverzeichnis unter /home/pi/ befindet):

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

==== Autostart aktivieren ====

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

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

Nun kann man mit

<code>
sudo service homebridge start
</code>

bzw.

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

den Dienst starten

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

Um HM-CC-RT-DN Thermostate steuern zu können, muss wie oben beschrieben folgendes attribute gesetzt werden (hier als Beispiel das Device "Heizung"):
# attr Heizung subtype thermostat
Für einen Dummy muss man den genericDeviceType setzen, also beispielsweise:
# attr Dummy genericDeviceType switch
# attr Dummy setList on off

Wie bereits vorher angemerkt: fügt man ein Device hinzu oder führt eine Änderung an einem Device durch, so sollte homebridge neu gestartet werden.

= HomeKit in iOS =

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

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

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

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

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

= Hinweise =

== Unterstützte Geräte ==
Das Fhem Plugin von {{Link2FU|430|Andre (justme1968)}} unterstützt automatisch mindestens die folgenden Geräte:

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

Über eine entsprechende Konfiguration lässt sich darüber hinaus jedes mit FHEM steuerbare Gerät auf die unterstützten Homekit typen abbilden.

Die aktuelle Liste und eine Beschreibung der Konfigurationsmöglichkeiten findet sich [https://www.npmjs.com/package/homebridge-fhem auf den npmjs seiten] bzw. [https://github.com/justme-1968/homebridge-fhem auf github].

== Zusätzliche Plugins ==
Für manche der über FHEM steuerbaren Geräte wie z.b. MiiLight, Harmony Hub, Phillips Hue, Sonos,... gibt es eigene homekit plugins. Wenn immer möglich, empfiehlt es sich aber diese '''nicht''' zu verwenden, sondern die Steuerung über die FHEM-Integration zu realisieren, da
* diese in der Regel sehr viel mächtiger und frei konfigurierbar ist
* es FHEM erlaubt, als zentrale Instanz den Überblick über den aktuellen Gesamtzustand zu haben (wichtig bei Geräten, die gepollt werden)
* die Ressourcen auf den angesteuerten Geräten schont, da Werte optimal gecached werden und nur eine einzige Verbindung aufgebaut wird

== Hinweis für alte homebridge Versionen ==
UPDATE: Homebridge funktioniert mit einer kleinen Einschränkung nun auch mit node 4.0.0. Laut
[https://github.com/cflurin/homebridge-shims/wiki/Minimalist-Homebridge-on-a-Raspberry-Pi Homebridge on a Raspberry Pi] müssen die folgenden Abhängigkeiten (Dependencies) aus der '''package.json''' entfernt werden:
<pre>
"harmonyhubjs-client": "^1.1.4",
"harmonyhubjs-discover": "git+https://github.com/swissmanu/harmonyhubjs-discover.git"
</pre>

== Hinweis zur Geschwindigkeitsoptimierung auf einem Raspberry PI ==

Damit es auf einem Raspberry schneller läuft, wird darüber hinaus empfohlen, auch diverse Abhängigkeiten aus der '''package.json''' zu entfernen:
<pre>
"ad2usb": "git+https://github.com/alistairg/node-ad2usb.git#local",
"carwingsjs": "0.0.x",
"chokidar": "^1.0.5",
"eibd": "^0.3.1",
"elkington": "kevinohara80/elkington",
"harmonyhubjs-client": "^1.1.4",
"harmonyhubjs-discover": "git+https://github.com/swissmanu/harmonyhubjs-discover.git",
"lifx-api": "^1.0.1",
"lifx": "git+https://github.com/magicmonkey/lifxjs.git",
"node-hue-api": "^1.0.5",
"node-icontrol": "^0.1.4",
"node-milight-promise": "0.0.x",
"tough-cookie": "^2.0.0",
"sonos": "0.8.x",
"telldus-live": "0.2.x",
"teslams": "1.0.1",
"unofficial-nest-api": "git+https://github.com/hachidorii/unofficial_nodejs_nest.git#d8d48edc952b049ff6320ef99afa7b2f04cdee98",
"wemo": "0.2.x",
"wink-js": "0.0.5",
"komponist" : "0.1.0",
"yamaha-nodejs": "0.4.x",
</pre>

Daher zunächst ein ein Backup der Datei anlegen
<pre>sudo cp package.json package.json.bkp </pre>
Am einfachsten geht das entfernen der Zeilen mit einem Editor, beispielsweise nano oder vi.
<pre>sudo nano package.json</pre>

Das config file sollte dann wie folgt aussehen: Achtung vor den letzten zwei "}" am Ende darf kein Komma sein.
<syntaxhighlight 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"
}
}
</syntaxhighlight>

== Links ==
* [https://github.com/nfarina/homebridge Github homebridge]
* [https://github.com/justme-1968/homebridge-fhem Github homebridge-fhem]
* [https://www.npmjs.com/package/homebridge NPM homebridge]
* [https://www.npmjs.com/package/homebridge-fhem NPM homebridge-fhem]

[[Kategorie:HOWTOS]]
[[Kategorie:Sprachsteuerung]]

Homebridge einrichten

2017-11-16T06:26:14Z

Motivierte linke Hände: define Kommando für siri eingefügt

Dieses HOWTO zeigt die Installation und Erstinbetriebnahme von Homebridge.

Damit kann Siri benutzt werden, um FHEM-Devices zu steuern. So können Devices angesprochen werden, die offiziell HomeKit nicht unterstützen (die Vorgehensweise wurde auf einem Intel NUC mit Ubuntu Server 14.04 LTS und auf einem Raspberry Pi mit Raspian getestet). Der WIKI-Eintrag bezieht sich hauptsächlich auf eine {{Link2Forum|Topic=32652|LinkText=Diskussion im FHEM-Forum}}. Ein Riesendank gilt vor allem {{Link2FU|430|Andre (justme1968)}}.

Die Konfiguration der inzwischen aktuellen zweiten Version des Homekit-Plugins ist in einem neuen {{Link2Forum|Topic= 48558 |LinkText=Thread im FHEM-Forum}} beschrieben. Hinzugekommen ist vor allem die freie Konfigurierbarkeit der Zuordnung zwischen FHEM Device und Homekit Accessory/Service, zwischen FHEM Reading und Homekit Characteristic, das mapping vom FHEM Readingwerten zu Homekit Werten sowie das Mapping von Homekit Werten zu FHEM Set-Kommandos und Werten.

Eine Sammlung funktionsfähiger Homebridge FHEM Konfiguration kann hier gefunden werden: [[Homebridge User Configs]]. Die Sammlung befindet sich noch im Aufbau.

= Vorbereitung der Umgebung =

== NodeJS installieren ==
''Die nachfolgenden Befehle sind alle mit "sudo" prefixed. Wenn du unter "root" arbeitest oder deine Distribution einen anderen Mechanismus verwendet, so kannst du dies natürlich weglassen.''

Zunächst wird das Betriebssystem (in diesem Falle Debian oder Ubuntu) auf den aktuellen Stand gebracht:
<syntaxhighlight lang="bash" style="width:50%;">
sudo apt-get update
sudo apt-get upgrade
sudo apt-get install build-essential libssl-dev</syntaxhighlight>

Nun muss NodeJS installiert werden. Leider ist die Version im Debian Repository deutlich zu alt, daher wird mit den folgenden Befehlen das Node Repository hinzugefügt und NodeJS (in der LTS Version) entsprechend installiert:

'''NodeJS V4'''
<syntaxhighlight lang="bash" style="width:50%;">
curl -sL https://deb.nodesource.com/setup_4.x | sudo -E bash -
sudo apt-get install -y nodejs
</syntaxhighlight>

{{Randnotiz|RNTyp=y|RNText=Bei Installation von NodeJS auf einem "alten" RasPi (B) bitte die besonderen Hinweise in {{Link2Forum|Topic=32652|Message=419325|LinkText=diesem Forenbeitrag}} beachten.}}
'''NodeJS V5'''
<syntaxhighlight lang="bash" style="width:50%">
curl -sL https://deb.nodesource.com/setup_5.x | sudo -E bash -
sudo apt-get install -y nodejs
</syntaxhighlight>

'''NodeJS V6'''
<syntaxhighlight lang="bash" style="width:50%">
curl -sL https://deb.nodesource.com/setup_6.x | sudo -E bash -
sudo apt-get install -y nodejs
</syntaxhighlight>

Damit ist NodeJS installiert.

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

Nun sind alle Voraussetzungen geschaffen.

= Installation von Homebridge & notwendiger Shims =
Im Nachfolgenden Absatz wird die Installation von Homebridge sowie des notwendigen Plugins (Shim) für FHEM erläutert.
Eventuell muss vor die Befehle ein
<syntaxhighlight lang="bash" style="width:50%;">
sudo
</syntaxhighlight>
vorangestellt werden.
== Homebridge installieren ==
Die aktuelle Homebridge version wird mit
<syntaxhighlight lang="bash" style="width:50%;">
npm install -g --unsafe-perm homebridge
</syntaxhighlight>
installiert, was eine Weile dauert. Anschließend wird der FHEM platform shim mit:
<syntaxhighlight lang="bash" style="width:60%;">
npm install -g homebridge-fhem
</syntaxhighlight>
installiert.

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

Kommt eine DNS Fehlermeldung fehlt meistens der AVAHI-DAEMON, zu installieren via
<syntaxhighlight lang="bash" style="width=50%">
sudo apt-get install avahi-daemon
</syntaxhighlight>

Wenn npm beim Kompilieren von mdns mit der Meldung abbricht, dass "dns_sd.h" nicht gefunden wird, fehlt das Paket libavahi-compat-libdnssd-dev, zu installieren via
<syntaxhighlight lang="bash" style="width=50%">
sudo apt-get install libavahi-compat-libdnssd-dev
</syntaxhighlight>

== Homebridge aktualisieren ==
Prüfen, ob es Updates gibt:
<syntaxhighlight lang="bash" style="width:50%;">
npm -g outdated
</syntaxhighlight>
Die aktuelle Homebridge version wird mit
<syntaxhighlight lang="bash" style="width:50%;">
npm -g update homebridge
</syntaxhighlight>
installiert, was eine Weile dauert. Anschließend wird der FHEM platform shim mit:
<syntaxhighlight lang="bash" style="width:60%;">
npm -g update homebridge-fhem
</syntaxhighlight>
installiert.

Sollte dies nicht funktionieren, kann mit
<syntaxhighlight lang="bash" style="width:60%;">
npm -g install homebridge
</syntaxhighlight>
bzw.
<syntaxhighlight lang="bash" style="width:60%;">
npm -g install homebridge-fhem
</syntaxhighlight>
das Update installiert werden.

= Homebridge konfigurieren =
''Wichtig: Für die weiteren Schritte sollte man nicht root verwenden, sondern beispielsweise einen dedizierten Nutzer für homebridge oder der Einfachheit halber den Nutzer, unter dem auch FHEM läuft (meist "fhem").''

== Einstellungen für homebridge ==
Zunächst wird das Verzeichnis für die Konfigurationsdatei erstellt und in dieses gewechselt:
<syntaxhighlight lang="bash" style="width:50%;">
mkdir -p ~/.homebridge
cd ~/.homebridge/
</syntaxhighlight>

Nun muss darin noch die config.json erstellt bzw. angepasst werden:
<syntaxhighlight lang="bash" style="width:50%;">
nano ~/.homebridge/config.json
</syntaxhighlight>

Hinweise zur Konfiguration:
* "''bridge''":
** "''username''": Sollte so belassen werden. Sollte später auf dem iOS Device keine Homebridge gefunden werden, so kann man hier beispielsweise den String auf 31 statt 30 enden lassen um so eine neue Homebridge vorzutäuschen.
** "''port''": Sollte so belassen werden
** "''pin''": Der PIN kann beliebig in dem Format xxx-xx-xxx angepasst werden. Dieser muss nur einmal bei der Einrichtung in iOS eingegeben werden.
* "''platforms''":
** "''platform''": Hier muss "FHEM" beibehalten werden.
** "''server''": Hier muss die IP des FHEM-Servers eingetragen werden. Dabei muss Homebridge nicht auf dem selben Server laufen wie FHEM, kann aber. Wenn es auf dem gleichen Rechner läuft, dann bietet es sich an, die IP 127.0.0.1 zu verwenden.
** "''port''": Hier muss der Port des gewählten FHEMWEBS eingetragen werden (muss nicht das "normale" sein, kann eine extra Instanz sein)
** "''auth''": Ist FHEM nicht mit Nutzername/Password abgesichert, so kann man diese Zeile einfach entfernen.
** "''filter''": Damit nicht alle Devices von Homebridge berücksichtigt werden, bietet es sich an, die Devices zu filtern. In diesem Beispiel wurden alle Devices, die über Siri steuerbar sein sollen, zusätzlich in den Raum Homekit konfiguriert.
<syntaxhighlight 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": "127.0.0.1",
"port": "8083",
"auth": {"user": "FhemUser", "pass": "XXX"},
"filter": "room=Homekit"
}
],

"accessories": []
}
</syntaxhighlight>

Wenn für FHEMWEB kein user/password vergeben ist muss die "auth" Zeile weg gelassen werden.
Wird FHEM mit SSL abgesichert, so muss zusätzlich in der Sektion "platforms" noch diese Zeile (nach "port") eingefügt werden:
<syntaxhighlight lang="javascript" style="width:50%;">
"ssl": true,
</syntaxhighlight>
Wenn man SSL ohne user/password benutzt, muss man "auth" Zeile einfugen, wobei die Werte weggelassen werden:
<syntaxhighlight lang="javascript" style="width:50%;">
"auth": {"user": "", "pass": ""},
</syntaxhighlight>

Natürlich kann man auch nach beliebigen anderen Kriterien filtern. z.b. nach Device TYPE, nach subtype Attribut, ... Es können mehrere FHEM platforms Abschnitte mit eigenem Filter im config file stehen (dabei das Komma zwischen den einzelnen abschnitten nicht vergessen!) . Auch Geräte auf die mehr als ein Filterausdruck matched werden dabei nur ein mal hinzugefügt.

= FHEM konfigurieren =
Es empfiehlt sich ein siri Gerät in FHEM anzulegen.
# define siri siri

Die benötigten Attribute werden inzwischen beim ersten Start des von hombridge-fhem automatisch auf FHEM Seite eingetragen.

Mehr zu den inzwischen verfügbaren Konfigurationsmöglichkeiten findet sich auf den github und npmjs Seiten des Plugins und im ersten Beitrag des zugehörigen Thread im {{Link2Forum|Topic= 48558 |LinkText=Diskussion im FHEM-Forum}}

= Start von Homebridge =

== Hinweis ==
Nach allen Änderungen die in FHEM gemacht werden, welche Homebridge betreffen, muss Homebridge neu gestartet werden. Wie der Neustart erfolgen muss, ist abhängig davon, wie man Homebridge gestartet hat. Bitte den entsprechenden Methoden entnehmen.

== Einmaliger Manueller Start ==
<syntaxhighlight lang="bash" style="width:50%;">
homebridge
</syntaxhighlight>

Homebridge sollte nun laufen. Hier kann man die Kommunikation nachverfolgen. Abbrechen kann das ganze mit CTRL+c (es dann auch keine Befehle mehr mit Siri möglich). Damit Siri auch Befehle ohne ständig offenes Terminal bearbeiten kann, bitten nächsten Punkt beachten.

=== Fehler während des Manuellen Starts ===
Kommt ein Fehler der ähnlich aussieht wie folgender, sollte zu erst die Nodesversion geprüft werden.
Die Nodes version kann durch ein System Update auf eine niedrigere Version wie benötigt gedowngraded werden
<syntaxhighlight lang="bash" style="width=50%">
Error: Module version mismatch. Expected 47, got 46.
at Error (native)
at Object.Module._extensions..node (module.js:450:18)
at Module.load (module.js:356:32)
at Function.Module._load (module.js:313:12)
at Module.require (module.js:366:17)
at require (module.js:385:17)
at Object.<anonymous> (/usr/lib/node_modules/homebridge/node_modules/mdns/lib/dns_sd.js:24:20)
at Module._compile (module.js:425:26)
at Object.Module._extensions..js (module.js:432:10)
at Module.load (module.js:356:32)
</syntaxhighlight>
Geprüft werden kann die Nodes Version mit:
<syntaxhighlight lang="bash" style="width=50%">node -v zeigt mir: v0.10.28, nodejs -v: v5.11.1</syntaxhighlight>
Hier ist die Version v0.10.28 wobei v0.12 Mindestvorraussetzung ist.
Die installation der richtigen Nodes Version kann oben am Anhang des Wiki Artikels entnommen werden.

== Homebridge automatisch starten ==
Es gibt verschiedene Methoden, Homebridge automatisch zu starten.

=== Steuerung via FHEM ===
Auf Basis der unten stehenden ''Alternativen Methode'' wurde eine Version entwickelt, mit der man auch den Status einsehen und den Restart des Dienstes aus FHEM heraus erledigen kann. Diese Version ist auf der Seite [[Homebridge Start und Status in FHEM]] im Detail beschrieben.

=== Alternative Methode ===
Dies startet homebridge als einen Service.

==== Service anlegen ====
<code>
sudo nano /etc/init.d/homebridge
</code>

Code einfügen (startet den Homebridge Server als Benutzer "pi" und nimmt an, dass sich .homebridge/config.json in seinem Homeverzeichnis unter /home/pi/ befindet):

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

==== Autostart aktivieren ====

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

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

Nun kann man mit

<code>
sudo service homebridge start
</code>

bzw.

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

den Dienst starten

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

Um HM-CC-RT-DN Thermostate steuern zu können, muss wie oben beschrieben folgendes attribute gesetzt werden (hier als Beispiel das Device "Heizung"):
# attr Heizung subtype thermostat
Für einen Dummy muss man den genericDeviceType setzen, also beispielsweise:
# attr Dummy genericDeviceType switch
# attr Dummy setList on off

Wie bereits vorher angemerkt: fügt man ein Device hinzu oder führt eine Änderung an einem Device durch, so sollte homebridge neu gestartet werden.

= HomeKit in iOS =

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

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

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

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

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

= Hinweise =

== Unterstützte Geräte ==
Das Fhem Plugin von {{Link2FU|430|Andre (justme1968)}} unterstützt automatisch mindestens die folgenden Geräte:

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

Über eine entsprechende Konfiguration lässt sich darüber hinaus jedes mit FHEM steuerbare Gerät auf die unterstützten Homekit typen abbilden.

Die aktuelle Liste und eine Beschreibung der Konfigurationsmöglichkeiten findet sich [https://www.npmjs.com/package/homebridge-fhem auf den npmjs seiten] bzw. [https://github.com/justme-1968/homebridge-fhem auf github].

== Zusätzliche Plugins ==
Für manche der über FHEM steuerbaren Geräte wie z.b. MiiLight, Harmony Hub, Phillips Hue, Sonos,... gibt es eigene homekit plugins. Wenn immer möglich, empfiehlt es sich aber diese '''nicht''' zu verwenden, sondern die Steuerung über die FHEM-Integration zu realisieren, da
* diese in der Regel sehr viel mächtiger und frei konfigurierbar ist
* es FHEM erlaubt, als zentrale Instanz den Überblick über den aktuellen Gesamtzustand zu haben (wichtig bei Geräten, die gepollt werden)
* die Ressourcen auf den angesteuerten Geräten schont, da Werte optimal gecached werden und nur eine einzige Verbindung aufgebaut wird

== Hinweis für alte homebridge Versionen ==
UPDATE: Homebridge funktioniert mit einer kleinen Einschränkung nun auch mit node 4.0.0. Laut
[https://github.com/cflurin/homebridge-shims/wiki/Minimalist-Homebridge-on-a-Raspberry-Pi Homebridge on a Raspberry Pi] müssen die folgenden Abhängigkeiten (Dependencies) aus der '''package.json''' entfernt werden:
<pre>
"harmonyhubjs-client": "^1.1.4",
"harmonyhubjs-discover": "git+https://github.com/swissmanu/harmonyhubjs-discover.git"
</pre>

== Hinweis zur Geschwindigkeitsoptimierung auf einem Raspberry PI ==

Damit es auf einem Raspberry schneller läuft, wird darüber hinaus empfohlen, auch diverse Abhängigkeiten aus der '''package.json''' zu entfernen:
<pre>
"ad2usb": "git+https://github.com/alistairg/node-ad2usb.git#local",
"carwingsjs": "0.0.x",
"chokidar": "^1.0.5",
"eibd": "^0.3.1",
"elkington": "kevinohara80/elkington",
"harmonyhubjs-client": "^1.1.4",
"harmonyhubjs-discover": "git+https://github.com/swissmanu/harmonyhubjs-discover.git",
"lifx-api": "^1.0.1",
"lifx": "git+https://github.com/magicmonkey/lifxjs.git",
"node-hue-api": "^1.0.5",
"node-icontrol": "^0.1.4",
"node-milight-promise": "0.0.x",
"tough-cookie": "^2.0.0",
"sonos": "0.8.x",
"telldus-live": "0.2.x",
"teslams": "1.0.1",
"unofficial-nest-api": "git+https://github.com/hachidorii/unofficial_nodejs_nest.git#d8d48edc952b049ff6320ef99afa7b2f04cdee98",
"wemo": "0.2.x",
"wink-js": "0.0.5",
"komponist" : "0.1.0",
"yamaha-nodejs": "0.4.x",
</pre>

Daher zunächst ein ein Backup der Datei anlegen
<pre>sudo cp package.json package.json.bkp </pre>
Am einfachsten geht das entfernen der Zeilen mit einem Editor, beispielsweise nano oder vi.
<pre>sudo nano package.json</pre>

Das config file sollte dann wie folgt aussehen: Achtung vor den letzten zwei "}" am Ende darf kein Komma sein.
<syntaxhighlight 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"
}
}
</syntaxhighlight>

== Links ==
* [https://github.com/nfarina/homebridge Github homebridge]
* [https://github.com/justme-1968/homebridge-fhem Github homebridge-fhem]
* [https://www.npmjs.com/package/homebridge NPM homebridge]
* [https://www.npmjs.com/package/homebridge-fhem NPM homebridge-fhem]

[[Kategorie:HOWTOS]]
[[Kategorie:Sprachsteuerung]]

SSCAM - Steuerung von Kameras in Synology Surveillance Station

2017-04-10T14:50:34Z

Motivierte linke Hände: Link auf surveillance vs. @surveillance - angepasst

{{Infobox Modul
|ModPurpose=Steuerung von Kameras in Synology Surveillance Station
|ModType=d
|ModCmdRef=SSCam
|ModForumArea=Sonstiges
|ModTechName=49_SSCam.pm
|ModOwner=nasseeder1 (Forum: DS_Starter)}}

== Zweckbeschreibung ==

Mit diesem Modul können Operationen von in der Synology Surveillance Station (SVS) definierten Kameras ausgeführt werden.
Es basiert auf der SVS API und unterstützt die SVS ab Version 7.
Zur Zeit werden folgende Funktionen unterstützt:

* Start einer Aufnahme
* Stop einer Aufnahme (per Befehl bzw. automatisch nach Ablauf der Aufnahmedauer)
* Aufnehmen eines Schnappschusses und Ablage in der Synology Surveillance Station
* Deaktivieren einer Kamera in Synology Surveillance Station
* Aktivieren einer Kamera in Synology Surveillance Station
* Steuerung der Belichtungsmodi Tag, Nacht bzw. Automatisch
* Umschaltung der Ereigniserkennung durch Kamera, durch SVS oder deaktiviert
* Abfrage von Kameraeigenschaften (auch mit Polling) sowie den Eigenschaften des installierten SVS-Paketes
* Bewegen an eine vordefinierte Preset-Position (bei PTZ-Kameras)
* Start einer vordefinierten Überwachungstour (bei PTZ-Kameras)
* Positionieren von PTZ-Kameras zu absoluten X/Y-Koordinaten
* kontinuierliche Bewegung von PTZ-Kameras
* auslösen externer Ereignisse 1-10 (Aktionsregel SVS)
* starten und beenden von Kamera-Livestreams
* Abruf und Ausgabe der Kamera Streamkeys sowie Stream-Urls (zur Nutzung von Kamera-Livestreams ohne Session Id)
* abspielen der letzten Aufnahme

Die Aufnahmen stehen in der Synology Surveillance Station (SVS) zur Verfügung und unterliegen, wie jede andere Aufnahme, den in der Synology Surveillance Station eingestellten Regeln.
So werden zum Beispiel die Aufnahmen entsprechend ihrer Archivierungsfrist gespeichert und dann gelöscht.

Wenn sie über dieses Modul diskutieren oder zur Verbesserung des Moduls beitragen möchten, ist im FHEM-Forum ein Sammelplatz unter: 
{{Link2Forum|Topic=45671.0 |LinkText=49_SSCam: Fragen, Hinweise, Neuigkeiten und mehr rund um dieses Modul}}

 

== Vorbereitung ==

Dieses Modul nutzt das Perl-Modul JSON. Bitte darauf achten dieses Paket zu installieren. (Debian: apt-get install libjson-perl).
SSCAM verwendet für HTTP-Calls die nichtblockierenden Funktionen von HttpUtils bzw. HttpUtils_NonblockingGet.
Im DSM bzw. der Synology Surveillance Station muß ein Nutzer für den Zugriff aus FHEM angelegt sein. Die Zugangsdaten für diesen Nutzer werden später über ein Set-Kommando dem angelegten Gerät zugewiesen. 
Nähere Informationen dazu unter [[#Credentials | Credentials]].

Überblick über die Perl-Module welche von SSCam genutzt werden: 

JSON
Data::Dumper
MIME::Base64
Time::HiRes
HttpUtils (FHEM-Modul)

 

== Define ==
<pre>
define <name> SSCam <Kameraname in SVS> <ServerAddr> [Port]
</pre>

Definiert eine neue Kamera für SSCam. Zunächst muß diese Kamera in der Synology Surveillance Station 7.0 oder höher eingebunden sein und entsprechend funktionieren.

Das Modul SSCam basiert auf Funktionen der Synology Surveillance Station API.
Weitere Informationen unter: [http://global.download.synology.com/download/Document/DeveloperGuide/Surveillance_Station_Web_API_v2.0.pdf Web API Guide].

Momentan wird nur das HTTP-Protokoll unterstützt um die Web-Services der Synology DS aufzurufen.

Die Parameter beschreiben im Einzelnen:

<pre>
name : der Name des neuen Gerätes in FHEM
Kameraname : Kameraname wie er in der Synology Surveillance Station angegeben ist. Leerzeichen im Namen sind nicht erlaubt !
ServerAddr : die IP-Addresse des Synology Surveillance Station Host.
Achtung: Es sollte kein Servername verwendet werden weil DNS-Aufrufe in FHEM blockierend sind
Port : optional - der Port des Synology Surveillance Station Host.
Wenn nicht angegeben, wird der Standardport 5000 gesetzt(nur HTTP)
</pre>

Beispiel:

define CamCP SSCAM Carport 192.168.2.20 [5000]

Wird eine neue Kamera definiert, wird diesem Device zunächst eine Standardaufnahmdauer von 15 zugewiesen.
Über das Attribut "rectime" kann die Aufnahmedauer für jede Kamera individuell angepasst werden. Der Wert "0" für "rectime" führt zu einer Endlosaufnahme die durch '''"set <name> off"''' gestoppt werden muß. Ein Logeintrag mit einem entsprechenden Hinweis auf diesen Umstand wird geschrieben.

Wird das Attribut "rectime" gelöscht, greift wieder der Default-Wert (15s) für die Aufnahmedauer.

Mit dem Befehl '''"set <name> on [rectime]"''' wird die Aufnahmedauer temporär festgelegt und überschreibt einmalig sowohl den Defaultwert als auch den Wert des gesetzten Attributs "rectime". Auch in diesem Fall führt "set <name> on 0" zu einer Daueraufnahme.

Eine eventuell in der SVS eingestellte Dauer der Voraufzeichnung wird weiterhin berücksichtigt.

=== Credentials ===

Nach dem Definieren des Gerätes müssen zuerst die Zugangsparameter gespeichert werden. Das geschieht mit dem Befehl:

set <name> credentials <username> <password>

Der Anwender kann in Abhängigkeit der beabsichtigten einzusetzenden Funktionen einen Nutzer im DSM bzw. in der Surveillance Station einrichten.
Ist der DSM-Nutzer der Gruppe Administratoren zugeordnet, hat er auf alle Funktionen Zugriff. Ohne diese Gruppenzugehörigkeit können nur Funktionen mit niedrigeren Rechtebedarf ausgeführt werden. Die benötigten Mindestrechte der Funktionen sind in der Tabelle weiter unten aufgeführt.
Alternativ zum DSM-Nutzer kann ein in der SVS angelegter Nutzer verwendet werden. Auch in diesem Fall hat ein Nutzer vom Typ Manager das Recht alle Funktionen auszuführen, wobei der Zugriff auf bestimmte Kameras/ im Privilegienprofil beschränkt werden kann (siehe Hilfefunktion in SVS).
Als Best Practice wird vorgeschlagen jeweils einen User im DSM und einen in der SVS anzulegen.

* DSM-User als Mitglied der Admin-Gruppe: uneingeschränkter Test aller Modulfunktionen -> session:DSM
* SVS-User als Manager oder Betrachter: angepasstes Privilegienprofil -> session: SurveillanceStation

Über das Attribut "session" kann ausgewählt werden, ob die Session mit dem DSM oder der SVS augebaut werden soll.
Erfolgt der Session-Aufbau mit dem DSM, stehen neben der SVS Web-API auch darüber hinaus gehende API Zugriffe zur Verfügung die unter Umständen zur Verarbeitung benötigt werden.

Nach der Gerätedefinition ist die Grundeinstellung "Login in das DSM", d.h. es können Credentials mit Admin-Berechtigungen genutzt werden um zunächst alle Funktionen der Kameras testen zu können. Danach können die Credentials z.B. in Abhängigkeit der benötigten Funktionen auf eine SVS-Session mit entsprechend beschränkten Privilegienprofil umgestellt werden.

Die nachfolgende Aufstellung zeigt die Mindestanforderungen der jeweiligen Modulfunktionen an die Nutzerrechte.
<pre>
* set ... on session: ServeillanceStation - Betrachter mit erweiterten Privileg "manuelle Aufnahme"
* set ... off session: ServeillanceStation - Betrachter mit erweiterten Privileg "manuelle Aufnahme"
* set ... snap session: ServeillanceStation - Betrachter
* set ... disable session: ServeillanceStation - Manager
* set ... enable session: ServeillanceStation - Manager
* set ... expmode session: ServeillanceStation - Manager
* set ... motdetsc session: ServeillanceStation - Manager
* set ... goPreset session: ServeillanceStation - Betrachter mit Privileg Objektivsteuerung der Kamera
* set ... runPatrol session: ServeillanceStation - Betrachter mit Privileg Objektivsteuerung der Kamera
* set ... goAbsPTZ session: ServeillanceStation - Betrachter mit Privileg Objektivsteuerung der Kamera
* set ... move session: ServeillanceStation - Betrachter mit Privileg Objektivsteuerung der Kamera
* set ... runView session: ServeillanceStation - Betrachter mit Privileg Liveansicht für Kamera
* set ... stopView -
* set ... credentials -
* set ... extevent session: DSM - Nutzer Mitglied von Admin-Gruppe
* get ... caminfoall session: ServeillanceStation - Betrachter
* get ... eventlist session: ServeillanceStation - Betrachter
* get ... svsinfo session: ServeillanceStation - Betrachter
* get ... svsinfo session: ServeillanceStation - Betrachter
* get ... stmUrlPath session: ServeillanceStation - Betrachter

</pre>

=== HTTP-Timeout setzen ===

Alle Funktionen dieses Moduls verwenden HTTP-Aufrufe gegenüber der SVS Web API. 
Der Standardwert für den HTTP-Timeout beträgt 4 Sekunden.
Durch Setzen des Attributes "httptimeout" > 0 kann dieser Wert bei Bedarf entsprechend den technischen Gegebenheiten angepasst werden.

 

== Set ==

Es gibt zur Zeit folgende Optionen für "set <name> ...".

<pre>
"on [rectime]": startet eine Aufnahme. Die Aufnahme wird automatisch nach Ablauf der Zeit [rectime]
gestoppt.
mit rectime = 0 wird eine Daueraufnahme gestartet die durch "set <name> off"
wieder gestoppt werden muß.
"off" : stoppt eine laufende Aufnahme manuell oder durch die Nutzung anderer Events
(z.B. über at, notify)
"snap": löst einen Schnappschuß der entsprechenden Kamera aus und speichert ihn in der SVS
"disable": deaktiviert eine Kamera in der Surveillance Station
"enable": aktiviert eine Kamera in der Surveillance Station
"credentials <username> <password>": speichert die Zugangsinformationen
"expmode [ day | night | auto ]": aktiviert den Belichtungsmodus Tag, Nacht oder Automatisch
"extevent [ 1-10 ]": löst das externe Ereignis 1-10 aus (Aktionsregeleditor in SVS)
"motdetsc [ by_camera | by_SVS | disable ]": schaltet die Bewegungserkennung in den gewünschten Modus
(durch Kamera, SVS, oder deaktiviert)
"goPreset <Presetname>": fährt eine PTZ-Kamera zu einer vordefinierten Preset-Position
"runPatrol <Patrolname>": startet eine vordefinierte Überwachungstour einer PTZ-Kamera
"goAbsPTZ [ X Y | up | down | left | right ]": positioniert eine PTZ-Kamera zu einer X/Y-Koordinate oder in Richtung up/down/left/right
"move [ up | down | left | right | dir_X ]": startet kontinuerliche Bewegung einer PTZ-Kamera in Richtung up/down/left/right bzw. dir_X
"runView [image | lastrec | lastrec_open |
link | link_open <room>]": startet einen Livestream bzw. die letzte Aufnahme als eingbettetes Image, als Link
oder öffnet diesen Medienstream sofort
"stopView": Gegenteil von "runView"
</pre>

=== set <name> [on [rectime] | off] ===

Der Befehl "set <name> on" startet eine Aufnahme. Die Standardaufnahmedauer beträgt 15 Sekunden. Sie kann mit dem Attribut "rectime" individuell festgelegt werden. Die im Attribut (bzw. im Standard) hinterlegte Aufnahmedauer kann einmalig mit "set <name> on [rectime]" überschrieben werden.
Die Aufnahme stoppt automatisch nach Ablauf der Zeit "rectime".

Ein Sonderfall ist der Start einer Daueraufnahme mit "set <name> on 0" bzw. dem Attributwert "rectime = 0". In diesem Fall wird eine Daueraufnahme gestartet die explizit wieder mit dem Befehl ""set <name> off" gestoppt werden muß.

Das Aufnahmeverhalten kann weiterhin mit dem Attribut "recextend" wie folgt beeinflusst werden.

'''Attribut "recextend = 0" bzw. nicht gesetzt (Standard):'''
* wird eine Aufnahme mit z.B. rectime=22 gestartet, wird kein weiterer Startbefehl für eine Aufnahme akzeptiert bis diese gestartete Aufnahme nach 22 Sekunden beendet ist. Ein Hinweis wird bei verbose=3 im Logfile protokolliert.

'''Attribut "recextend = 1" gesetzt:'''
* eine zuvor gestartete Aufnahme wird bei einem erneuten "set <name> on"-Befehl mit der Aufnahmezeit "rectime" neu parametrisiert. Das bedeutet, dass der Timer für den automatischen Stop auf den Wert "rectime" neu gesetzt wird. Dieser Vorgang wiederholt sich mit jedem Start-Befehl. Dadurch verlängert sich eine laufende Aufnahme bis kein Start-Inpuls mehr registriert wird.

* eine zuvor gestartete Endlos-Aufnahme wird mit einem erneuten "set <name> on"-Befehl nach der Aufnahmezeit "rectime" gestoppt (Timerneustart). Ist dies nicht gewünscht, ist darauf zu achten dass bei der Verwendung einer Endlos-Aufnahme das Attribut "recextend" nicht verwendet wird.

Beispiele für einfache Operationen:

<pre>
set <name> on [rectime] : startet die Aufnahme der Kamera <name>.
set <name> off : stoppt die Aufnahme der Kamera <name>
set <name> disable : deaktiviert die Kamera <name> in der Surveillance Station
set <name> enable : aktiviert die Kamera <name> in der Surveillance Station
</pre>

'''Hinweis:'''

In der SVS kann unter Aufnahmeeinstellungen der Kamera eine Vor-Aufnahmezeit eingestellt werden. Die Einstellung wird von der SVS bezüglich der Gesamtaufnahmezeit automatisch mit berücksichtigt.

Eine eingestellte Vor-Aufnahmezeit von z.B. 10s und eine rectime von 20s führt zu einer Gesamtaufnahmezeit von 30s (zzgl. Prozesszeit zur Befehlsabarbeitung).

=== set <name> snap ===

Ein Schnappschuß kann ausgelöst werden durch:

<pre>
set <name> snap
</pre>

Soll eine Reihe Schnappschüsse ausgelöst werden wenn eine Aufnahme startet, kann das durch folgendes notify geschehen.
Wird der Start der Kamera CamHE1 ausgelöst (vorher Attribut event-on-change-reading -> "Record" setzen), werden 3 Snapshots im Abstand von 2 Sekunden getriggert.

<pre>
define he1_snap_3 notify CamHE1:Record.*on define h3 at +*{3}00:00:02 set CamHE1 snap
</pre>

Triggern von 2 Schnappschüssen der Kamera "CamHE1" im Abstand von 6 Sekunden nachdem der Bewegungsmelder "MelderHE1" einen Event gesendet hat, kann z.B. mit folgendem notify geschehen:

<pre>
define he1_snap_2 notify MelderHE1:on.* define h2 at +*{2}00:00:06 set CamHE1 snap
</pre>

Es wird die ID des letzten Snapshots als Wert der Variable "LastSnapId" in den Readings der Kamera ausgegeben.

=== set <name> [enable] [disable] ===

Um eine Liste von Kameras oder alle Kameras (mit Regex) zum Beispiel um 21:46 zu deaktivieren / zu aktivieren zwei Beispiele mit at:

<pre>
define a13 at 21:46 set CamCP1,CamFL,CamHE1,CamTER disable (enable)
define a14 at 21:46 set Cam.* disable (enable)
</pre>

Etwas komfortabler gelingt das Schalten aller Kameras über einen Dummy.
Zunächst wird der Dummy angelegt:

<pre>
define allcams dummy
attr allcams eventMap on:enable off:disable
attr allcams room Cams
attr allcams webCmd enable:disable
</pre>

Durch Verknüpfung mit zwei angelegten notify, jeweils ein notify für "enable" und "disable", kann man durch Schalten des Dummys auf "enable" bzw. "disable" alle Kameras auf einmal aktivieren bzw. deaktivieren.

<pre>
define all_cams_disable notify allcams:.*off set CamCP1,CamFL,CamHE1,CamTER disable
attr all_cams_disable room Cams

define all_cams_enable notify allcams:on set CamCP1,CamFL,CamHE1,CamTER enable
attr all_cams_enable room Cams
</pre>

 
=== set <name> expmode [day] [night] [auto] ===

Mit diesem Befehl kann der Belichtungsmodus der Kameras gesetzt werden. Dadurch wird z.B. das Verhalten der Kamera-LED's entsprechend gesteuert. Die erfolgreiche Umschaltung wird durch das Reading CamExposureMode ("get ... caminfoall") reportet.

'''Hinweis:''' Die erfolgreiche Ausführung dieser Funktion ist davon abhängig ob die SVS diese Funktionalität der Kamera unterstützt. Ist in SVS -> IP-Kamera -> Optimierung -> Belichtungsmodus das Feld für den Tag/Nachtmodus grau hinterlegt, ist nicht von einer lauffähigen Unterstützung dieser Funktion auszugehen.

 
=== set <name> motdetsc [camera] [SVS] [disable] (geändert ab Rev 11284) ===

Der Befehl "motdetsc" (steht für "motion detection source") schaltet die Bewegungserkennung in den gewünschten Modus.
Wird die Bewegungserkennung durch die Kamera / SVS ohne weitere Optionen eingestellt, werden die momentan gültigen Bewegungserkennungsparameter der Kamera / SVS beibehalten.
Die erfolgreiche Ausführung der Operation lässt sich u.a. anhand des Status von SVS -> IP-Kamera -> Ereigniserkennung -> Bewegung nachvollziehen.

Für die Bewegungserkennung durch SVS bzw. durch Kamera können weitere Optionen angegeben werden. Die verfügbaren Optionen bezüglich der Bewegungserkennung durch SVS sind "Empfindlichkeit" und "Schwellwert".

<pre>
set <name> motdetsc SVS [Empfindlichkeit] [Schwellwert] # Befehlsmuster
set <name> motdetsc SVS 91 30 # setzt die Empfindlichkeit auf 91 und den Schwellwert auf 30
set <name> motdetsc SVS 0 40 # behält gesetzten Wert für Empfindlichkeit bei, setzt Schwellwert auf 40
set <name> motdetsc SVS 15 # setzt die Empfindlichkeit auf 15, Schwellwert bleibt unverändert
</pre>

Wird die Bewegungserkennung durch die Kamera genutzt, stehen die Optionen "Empfindlichkeit", "Objektgröße" und "Prozentsatz für Auslösung" zur Verfügung.

<pre>
set <name> motdetsc camera [Empfindlichkeit] [Schwellwert] [Prozentsatz] # Befehlsmuster
set <name> motdetsc camera 89 0 20 # setzt die Empfindlichkeit auf 89, Prozentsatz auf 20
set <name> motdetsc camera 90 40 10 # setzt Empfindlichkeit auf 90, Schwellwert auf 40,
Prozentsatz auf 10
set <name> motdetsc camera 30 # setzt die Empfindlichkeit auf 30, andere Werte bleiben
unverändert
</pre>

Es ist immer die Reihenfolge der Optionswerte zu beachten. Nicht gewünschte Optionen sind mit "0" zu besetzen sofern danach Optionen folgen deren Werte verändert werden sollen (siehe Beispiele oben). Der Zahlenwert der Optionen beträgt 1 - 99 (außer Sonderfall "0").

Die jeweils verfügbaren Optionen unterliegen der Funktion der Kamera und der Unterstützung durch die SVS. Es können jeweils nur die Optionen genutzt werden die in SVS -> Kamera bearbeiten -> Ereigniserkennung zur Verfügung stehen. Weitere Infos sind der Online-Hilfe zur SVS zu entnehmen.

Über den Befehl "get ... caminfoall" wird auch das Reading "CamMotDetSc" aktualisiert welches die gegenwärtige Einstellung der Bewegungserkennung dokumentiert. Es werden nur die Parameter und Parameterwerte angezeigt, welche die SVS aktiv unterstützt. Die Kamera selbst kann weiterführende Einstellmöglichkeiten besitzen.

Beispiel:

<pre>
CamMotDetSc SVS, sensitivity: 76, threshold: 55
</pre>

 

=== set <name> goPreset <Preset> ===

Mit diesem Kommando können PTZ-Kameras in eine vordefininierte Position bewegt werden. 
Die Preset-Positionen müssen dazu zunächst in der Synology Surveillance Station angelegt worden sein. Das geschieht in der PTZ-Steuerung im IP-Kamera Setup.
Die Presets werden über das Kommando "set <name> getinfo" eingelesen (geschieht bei restart von FHEM automatisch). Der Einlesevorgang kann durch ein Kamerapolling
regelmäßig wiederholt werden. Ein langes Pollingintervall ist in diesem Fall empfehlenswert da die Presetpositionen sich nur im Fall der Neuanlage bzw. Änderung verändern werden.
 

Hier ein Beispiel einer PTZ-Steuerung in Abhängigkeit eines IR-Melder Events:

<pre>
define CamFL.Preset.Wandschrank notify MelderTER:on.* set CamFL goPreset Wandschrank, ;; define CamFL.Preset.record
at +00:00:10 set CamFL on 5 ;;;; define s3 at +*{3}00:00:05 set CamFL snap ;; define CamFL.Preset.back at +00:00:30 set CamFL goPreset Home
</pre>

Funktionsweise: 
Der IR-Melder "MelderTER" registriert eine Bewegung. Daraufhin wird die Kamera CamFL in die Preset-Position "Wandschrank" gebracht. Eine Aufnahme mit Dauer von 5 Sekunden startet 10 Sekunden
später. Da die Voraufnahmezeit der Kamera 10s beträgt (vgl. Reading "CamPreRecTime"), startet die effektive Aufnahme wenn der Kameraschwenk beginnt. 
Mit dem Start der Aufnahme werden drei Schnappschüsse im Abstand von 5 Sekunden angefertigt. 
Nach einer Zeit von 30 Sekunden fährt die Kamera wieder zurück in die "Home"-Position. 

Ein Auszug aus dem Log verdeutlicht den Ablauf:

<pre>
2016.02.04 15:02:14 2: CamFL - Camera Flur_Vorderhaus has moved to position "Wandschrank"
2016.02.04 15:02:24 2: CamFL - Camera Flur_Vorderhaus Recording with Recordtime 5s started
2016.02.04 15:02:29 2: CamFL - Snapshot of Camera Flur_Vorderhaus has been done successfully
2016.02.04 15:02:30 2: CamFL - Camera Flur_Vorderhaus Recording stopped
2016.02.04 15:02:34 2: CamFL - Snapshot of Camera Flur_Vorderhaus has been done successfully
2016.02.04 15:02:39 2: CamFL - Snapshot of Camera Flur_Vorderhaus has been done successfully
2016.02.04 15:02:44 2: CamFL - Camera Flur_Vorderhaus has moved to position "Home"
</pre>

 
=== set <name> runPatrol <Patrolname> ===

Dieses Kommando startet die vordefinierterte Überwachungstour einer PTZ-Kamera. 
Die Überwachungstouren müssen dazu zunächst in der Synology Surveillance Station angelegt worden sein. Das geschieht in der PTZ-Steuerung im IP-Kamera Setup -> PTZ-Steuerung -> Überwachung.

Die Überwachungstouren (Patrols) werden über das Kommando "get <name> caminfoall" eingelesen, welches beim Restart von FHEM automatisch abgearbeitet wird. Der Einlesevorgang kann durch ein Kamerapolling regelmäßig wiederholt werden. Ein langes Pollingintervall ist in diesem Fall empfehlenswert, da sich die Überwachungstouren nur im Fall der Neuanlage bzw. Änderung verändern werden.

Nähere Informationen zur Anlage von Überwachungstouren sind in der Hilfe zur Surveillance Station enthalten.

 

=== set <name> goAbsPTZ [ X Y | up | down | left | right ] ===

Mit diesem Kommando wird eine PTZ-Kamera in Richtung einer wählbaren absoluten X/Y-Koordinate bewegt, oder zur maximalen Absolutposition in Richtung up/down/left/right.
Die Option ist nur für Kameras verfügbar die das Reading "CapPTZAbs=true" (die Fähigkeit für PTZAbs-Aktionen) besitzen. Die Eigenschaften der Kamera kann mit "get <name> caminfoall" abgefragt werden.
 

Beispiel für Ansteuerung absoluter X/Y-Koordinaten: 

<pre>
set <name> goAbsPTZ 120 450
</pre>

Dieses Beispiel bewegt die Kameralinse in die Position X=120 und Y=450. 
Der Wertebereich ist dabei:

<pre>
X = 0 - 640 (0 - 319 bewegt nach links, 321 - 640 bewegt nach rechts, 320 bewegt die Linse nicht)
Y = 0 - 480 (0 - 239 bewegt nach unten, 241 - 480 bewegt nach oben, 240 bewegt die Linse nicht)
</pre>

Die Linse kann damit in kleinsten bis sehr großen Schritten in die gewünschte Richtung bewegt werden. Dieser Vorgang muß ggf. mehrfach wiederholt werden um die Kameralinse in die gewünschte Position zu bringen. 

Soll die Bewegung mit der maximalen Schrittweite erfolgen, kann zur Vereinfachung der Befehl:

<pre>
set <name> goAbsPTZ up [down ] [left] [right]
</pre>

verwendet werden. Die Optik wird in diesem Fall mit der größt möglichen Schrittweite zur Absolutposition in der angegebenen Richtung bewegt. Auch in diesem Fall muß der Vorgang ggf. mehrfach wiederholt werden um die Kameralinse in die gewünschte Position zu bringen.

=== set <name> move [ up | down | left | right | dir_X ] [Sekunden] ===

Mit diesem Kommando wird eine kontinuierliche Bewegung der PTZ-Kamera gestartet. Neben den vier Grundrichtungen up/down/left/right stehen auch Zwischenwinkelmaße "dir_X" zur Verfügung. Die Feinheit dieser Graduierung ist von der Kamera abhängig und kann dem Reading "CapPTZDirections" entnommen werden.

Das Bogenmaß von 360 Grad teilt sich durch den Wert von "CapPTZDirections" und beschreibt die Bewegungsrichtungen beginnend mit "0=rechts" entgegen dem Uhrzeigersinn. D.h. bei einer Kamera mit "CapPTZDirections = 8" bedeutet dir_0 = rechts, dir_2 = oben, dir_4 = links, dir_6 = unten bzw. dir_1, dir_3, dir_5 und dir_7 die entsprechenden Zwischenrichtungen. Die möglichen Bewegungsrichtungen bei Kameras mit "CapPTZDirections = 32" sind dementsprechend kleinteliger.

Im Gegensatz zum "set <name> goAbsPTZ"-Befehl startet der Befehl "set <name> move" eine kontinuierliche Bewegung bis ein Stop-Kommando empfangen wird. Das Stop-Kommando wird nach Ablauf der optional anzugebenden Zeit [Sekunden] ausgelöst. Wird diese Laufzeit nicht angegeben, wird implizit Sekunde = 1 gesetzt.

Beispiele:

<pre>
set <name> move up 0.5 : bewegt die Linse 0,5 Sekunden (zzgl. Prozesszeit) nach oben (zzgl. Prozesszeit)
set <name> move dir_1 1.5 : bewegt die Linse 1,5 Sekunden (zzgl. Prozesszeit) nach rechts-oben
set <name> move dir_20 0.7 : bewegt die Linse 1,5 Sekunden (zzgl. Prozesszeit) nach links-unten bei "CapPTZDirections = 32"
</pre>

 
=== set <name> runView [ image | lastrec | lastrec_open | link | link_open <room>] ===

Mit "image, link, link_open" Es wird ein Livestream (mjpeg-Stream) der Kamera, entweder als eingebettetes Image oder als generierter Link, gestartet.
Der Zugriff auf die letzte Aufnahme einer Kamera kann über die Zusätze "lastrec" bzw. "lastrec_open" erfolgen.

'''Beispiele:'''

<pre>
attr <name> htmlattr target=_blank width="500" height="375"
attr <name> htmlattr target=_blank width=500,height=375
attr <name> htmlattr width=700,height=525,top=200,left=300
</pre>

Das Verhalten des Livestreams im FHEMWEB kann durch Angaben im Attribut "htmlattr" beeinflusst werden.
Mit diesen Attributwerten öffnet der Link als weiteres Fenster/Browsertab. Wird der Stream als Image gestartet, ändert sich die Größe entsprechend der Angaben von Width und Height.
Das Kommando "set <name> runView link_open" startet den Livestreamlink sofort in einem neuen Browsertab (longpoll=1 muß für WEB gesetzt sein).
Dabei wird für jede aktive FHEM-Session eine Fensteröffnung initiiert. Soll dieses Verhalten geändert werden, kann "set <name> runView link_open <room>"
verwendet werden um das Öffnen des Browserwindows in einem beliebigen, in einer FHEM-Session angezeigten Raum <room>, zu initiieren. 

Das gesetzte Attribut "livestreamprefix" überschreibt im Reading "LiveStreamUrl" die Angaben für Protokoll, Servername und Port. Damit kann z.B. die LiveStreamUrl für den Versand und externen Zugriff auf die SVS modifiziert werden.

'''Beispiel:'''

<pre>
attr <name> livestreamprefix https://<Servername>:<Port>
</pre>

Der Livestream wird über das Kommando "set <name> stopView" wieder beendet.

 

=== set <name> extevent [ 1-10 ] ===

Dieses Kommando triggert ein externes Ereignis (1-10) in der SVS. Die Aktionen, die dieses Ereignis auslöst, sind zuvor in dem Aktionsregeleditor der SVS einzustellen. Es stehen die Ereignisse 1-10 zur Verfügung. In der Banchrichtigungs-App der SVS können auch Email, SMS oder Mobil (DS-Cam) Nachrichten ausgegeben werden wenn ein externes Ereignis ausgelöst wurde. Nähere Informationen dazu sind in der Hilfe zum Aktionsregeleditor zu finden. Der verwendete User benötigt Admin-Rechte in einer DSM-Session.

 

== Get ==

Mit SSCam können die Eigenschaften der Kameras aus der Surveillance Station abgefragt werden. Dazu steht der Befehl zur Verfügung:

<pre>
get <name> caminfoall
get <name> eventlist
get <name> stmUrlPath
get <name> svsinfo
get <name> snapfileinfo
</pre>

Mit dem Befehl "get <name> caminfoall" werden abhängig von der Art der Kamera (z.B. Fix- oder PTZ-Kamera) die verfügbaren Eigenschaften ermittelt und als Readings zur Verfügung gestellt.
So wird zum Beispiel das Reading "Availability" auf "disconnected" gesetzt falls die Kamera von der Surveillance Station getrennt wird und kann für weitere Verarbeitungen genutzt werden.
Durch "get <name> eventlist" wird das Reading "CamEventNum" aktualisiert, welches die Gesamtanzahl der registrierten Kameraevents enthält.
Mit "get <name> snapfileinfo" wird der Filename des letzten Schnapschusses ermittelt. Der Befehl wird implizit mit "get <name> snap" ausgeführt.

Der Befehl "get <name> svsinfo" ist eigentlich nicht von der Kamera abhängig, sondern ermittelt vielmehr allgemeine Informationen zur installierten SVS-Version und andere Eigenschaften.
Die Funktionen "caminfoall" und "svsinfo" werden einmalig automatisch beim Start von FHEM ausgeführt um steuerungsrelevante Informationen zu sammeln.
Es ist darauf zu achten dass vorher die Credentials gespeichert wurden !

'''get <name> stmUrlPath'''

Mit diesem Kommando wird der aktuelle Streamkey der Kamera abgerufen und das Reading mit dem Key-Wert gefüllt. Dieser Streamkey kann verwendet werden um eigene Aufrufe eines Livestreams aufzubauen (siehe Beispiel). Wenn das Attribut "showStmInfoFull" gesetzt ist, werden zusaätzliche Stream-Informationen wie "StmKeyUnicst", "StmKeymjpegHttp" ausgegeben. Diese Readings enthalten die gültigen Stream-Pfade zu einem Livestream und können z.B. versendet und von einer entsprechenden Anwendung ohne session Id geöffnet werden. Wenn das Attribut "livestreamprefix" (Format: "http(s)://<hostname><port>) gesetzt ist, wird der Servername und Port überschrieben soweit es sinnvoll ist. Wird Polling der Kameraeigenschaften genutzt, wird die stmUrlPath-Funktion automatisch mit ausgeführt.

Beispiel für den Aufbau eines Http-Calls zu einem Livestream mit StmKey:

<pre>
http(s)://<hostname><port>/webapi/entry.cgi?api=SYNO.SurveillanceStation.VideoStreaming&version=1&method=Stream&format=mjpeg&cameraId=5StmKey="31fd87279976d89bb98409728cced890"
</pre>

cameraId (INTERNAL), StmKey müssen durch gültige Werte ersetzt werden.

'''Hinweis:'''

Falls der Stream-Aufruf versendet und von extern genutzt wird sowie hostname / port durch gültige Werte ersetzt und die Routerports entsprechend geöffnet werden, ist darauf zu achten dass diese sensiblen Daten nicht durch unauthorisierte Personen für den Zugriff genutzt werden können !

'''Polling der Kameraeigenschaften:''' 
Die Abfrage der Kameraeigenschaften erfolgt automatisch, wenn das Attribut "pollcaminfoall" (siehe Attribute) mit einem Wert > 10 gesetzt wird. Per Default ist das Attribut "pollcaminfoall" nicht gesetzt und das automatische Polling nicht aktiv. Der Wert dieses Attributes legt das Intervall der Abfrage in Sekunden fest. Ist das Attribut nicht gesetzt oder < 10 wird kein automatisches Polling gestartet bzw. gestoppt wenn vorher der Wert > 10 gesetzt war.

Das Attribut "pollcaminfoall" wird durch einen Watchdog-Timer überwacht. Änderungen des Attributwertes werden alle 90 Sekunden ausgewertet und entsprechend umgesetzt. Eine Änderung des Pollingstatus / Pollingintervalls wird im FHEM-Logfile protokolliert. Diese Protokollierung kann durch Setzen des Attributes "pollnologging" abgeschaltet werden. Dadurch kann ein unnötiges Anwachsen des Logs vermieden werden. Ab verbose=4 wird allerdings trotz gesetzten "pollnologging"-Attribut ein Log des Pollings zu Analysezwecken aktiviert.

Wird FHEM neu gestartet, wird bei aktivierten Polling der ersten Datenabruf innerhalb 60s nach dem Start ausgeführt.

Der Status des automatischen Pollings wird durch das Reading "PollState" signalisiert:

<pre>
PollState = Active - automatisches Polling wird mit Intervall entsprechend <pollcaminfoall> ausgeführt
PollState = Inactive - automatisches Polling wird nicht ausgeführt
</pre>

Die Bedeutung der Readingwerte ist unter Readings beschrieben.

'''Hinweise:'''

Wird Polling eingesetzt, sollte das Intervall nur so kurz wie benötigt eingestellt werden da die ermittelten Werte überwiegend statisch sind.
Das eingestellte Intervall sollte nicht kleiner sein als die Summe aller HTTP-Verarbeitungszeiten. Pro Pollingaufruf und Kamera werden ca. 10 - 20 Http-Calls gegen die Surveillance Station abgesetzt.

Bei einem eingestellten HTTP-Timeout (siehe Attribut) "httptimeout") von 4 Sekunden kann die theoretische Verarbeitungszeit nicht höher als 80 Sekunden betragen.
In dem Beispiel sollte man das Pollingintervall mit einem Sicherheitszuschlag auf nicht weniger 160 Sekunden setzen.
Ein praktikabler Richtwert könnte zwischen 600 - 1800 (s) liegen.

Sind mehrere Kameras in SSCam definiert, sollte "pollcaminfoall" nicht bei allen Kameras auf exakt den gleichen Wert gesetzt werden um Verarbeitungsengpässe und dadurch versursachte potentielle Fehlerquellen bei der Abfrage der Synology Surveillance Station zu vermeiden.
Ein geringfügiger Unterschied zwischen den Pollingintervallen der definierten Kameras von z.B. 1s kann bereits als ausreichend angesehen werden.

 

== Readings ==

Über den Pollingmechanismus bzw. durch Abfrage mit "Get" werden Readings bereitgestellt, deren Bedeutung in der nachfolgenden Tabelle dargestellt sind. Die übermittelten Readings können in Abhängigkeit des Kameratyps variieren.

<pre>
* Availability - Verfügbarkeit der Kamera (disabled, enabled, disconnected, other)
* CamEventNum - liefert die Gesamtanzahl der in SVS registrierten Events der Kamera
* CamExposureControl - zeigt den aktuell eingestellten Typ der Belichtungssteuerung
* CamExposureMode - aktueller Belichtungsmodus (Day, Night, Auto, Schedule, Unknown)
* CamIP - IP-Adresse der Kamera
* CamLiveMode - Quelle für Live-Ansicht (DS, Camera)
* CamModel - Kameramodell
* CamPort - IP-Port der Kamera
* CamPreRecTime - Dauer der der Voraufzeichnung in Sekunden (Einstellung in SVS)
* CamRecShare - gemeinsamer Ordner auf der DS für Aufnahmen
* CamRecVolume - Volume auf der DS für Aufnahmen
* CamVendor - Kamerahersteller Bezeichnung
* CamVideoFlip - Ist das Video gedreht </td></tr>
* CamVideoMirror - Ist das Video gespiegelt </td></tr>
* CapAudioOut - Fähigkeit der Kamera zur Audioausgabe über Surveillance Station (false/true)
* CapChangeSpeed - Fähigkeit der Kamera verschiedene Bewegungsgeschwindigkeiten auszuführen
* CapPTZAbs - Fähigkeit der Kamera für absolute PTZ-Aktionen
* CapPTZAutoFocus - Fähigkeit der Kamera für Autofokus Aktionen
* CapPTZDirections - die verfügbaren PTZ-Richtungen der Kamera
* CapPTZFocus - Art der Kameraunterstützung für Fokussierung
* CapPTZHome - Unterstützung der Kamera für Home-Position
* CapPTZIris - Unterstützung der Kamera für Iris-Aktion
* CapPTZPan - Unterstützung der Kamera für Pan-Aktion
* CapPTZTilt - Unterstützung der Kamera für Tilt-Aktion
* CapPTZZoom - Unterstützung der Kamera für Zoom-Aktion
* DeviceType - Kameratyp (Camera, Video_Server, PTZ, Fisheye)
* Error - Meldungstext des letzten Fehlers
* Errorcode - Fehlercode des letzten Fehlers
* LastSnapFilename - der Filename des letzten Schnapschusses
* LastSnapId - die ID des letzten Schnapschusses
* LastUpdateTime - Datum / Zeit der letzten Aktualisierung durch "caminfoall"
* LiveStreamUrl - die LiveStream-Url wenn der Stream gestartet ist. (Attribut "showStmInfoFull" muss gesetzt sein)
* Patrols - in Surveillance Station voreingestellte Überwachungstouren (bei PTZ-Kameras)
* PollState - zeigt den Status des automatischen Pollings an
* Presets - in Surveillance Station voreingestellte Positionen (bei PTZ-Kameras)
* Record - Aufnahme läuft = Start, keine Aufnahme = Stop
* StmKey - aktueller StreamKey. Kann zum öffnen eines Livestreams ohne Session Id genutzt werden.
* StmKeyUnicst - Uni-cast Stream Pfad der Kamera. ((Attribut "showStmInfoFull" muss gesetzt sein)
* StmKeymjpegHttp - Mjpeg Stream Pfad (über http) der Kamera. (Attribut "showStmInfoFull" muss gesetzt sein)
* SVScustomPortHttp - benutzerdefinierter Port der Surveillance Station (HTTP) im DSM-Anwendungsportal (get mit "svsinfo")
* SVScustomPortHttps - benutzerdefinierter Port der Surveillance Station (HTTPS) im DSM-Anwendungsportal (get mit "svsinfo")
* SVSlicenseNumber - die Anzahl der installierten Kameralizenzen (get mit "svsinfo")
* SVSuserPriv - die effektiven Rechte des verwendeten Users nach dem Login (get mit "svsinfo")
* SVSversion - die Paketversion der installierten Surveillance Station (get mit "svsinfo")
* UsedSpaceMB - durch Aufnahmen der Kamera belegter Plattenplatz auf dem Volume
</pre>

 

== Attribute ==

* '''debugactivetoken''' - wenn gesetzt wird der Status des Active-Tokens gelogged - nur für Debuggung, nicht im normalen Betrieb benutzen

* '''httptimeout''' - Timeout-Wert für HTTP-Aufrufe zur Synology Surveillance Station, Default: 4 Sekunden (wenn httptimeout = "0" oder nicht gesetzt)

* '''htmlattr''' - ergänzende Angaben zur Livestream-Url um das Verhalten wie Bildgröße zu beeinflussen

* '''livestreamprefix''' - überschreibt die Angaben zu Protokoll, Servernamen und Port zur Weiterverwendung der Livestreamadresse als z.B. externer Link. Die Angabe muss in der Form "http(s)://<servername>:<port>" erfolgen.

* '''noQuotesForSID''' - dieses Attribut kann in bestimmten Fällen die Fehlermeldung "402 - permission denied" vermeiden und ein login ermöglichen. (normalerweise nicht zu setzen)

* '''pollcaminfoall''' - Intervall der automatischen Eigenschaftsabfrage (Polling) einer Kamera (kleiner 10: kein Polling, größer 10: Polling mit Intervall)

* '''pollnologging''' - 0 bzw. nicht gesetzt = Logging Gerätepolling aktiv (default), 1 = Logging Gerätepolling inaktiv

* '''rectime''' - festgelegte Aufnahmezeit wenn eine Aufnahme gestartet wird. Mit rectime = 0 wird eine Endlosaufnahme gestartet. Ist "rectime" nicht gesetzt, wird der Defaultwert von 15s verwendet.

* '''session''' - Auswahl der Login-Session. Nicht gesetzt oder "DSM" -> session wird mit DSM aufgebaut (Standard). "SurveillanceStation" -> Session-Aufbau erfolgt mit SVS

* '''simu_SVSversion''' - simuliert eine andere SVS-Version. NUR FÜR DEBUGGING, nicht im normalen Betrieb zu nutzen !

* '''showStmInfoFull''' - zusaätzliche Streaminformationen wie LiveStreamUrl, StmKeyUnicst, StmKeymjpegHttp werden ausgegeben

* '''verbose'''
<pre>
Es werden verschiedene Verbose-Level unterstützt.
Dies sind im Einzelnen:

0 - Start/Stop-Ereignisse werden geloggt
1 - Fehlermeldungen werden geloggt
2 - Meldungen über wichtige Ereignisse oder Alarme
3 - gesendete Kommandos werden geloggt
4 - gesendete und empfangene Daten werden geloggt
5 - alle Ausgaben zur Fehleranalyse werden geloggt. ACHTUNG: unter Umständen werden sehr viele Daten in das Logfile geschrieben!
</pre>

weitere Attribute:

* [http://fhem.de/commandref_DE.html#readingFnAttributes readingFnAttributes]

 

== Das Modul bzw. eine Gerätedefinition deaktivieren ==

Mit dem Attribut "disable" kann das Modul bzw. eine Gerätedefinition deaktiviert werden. Im Gegensatz zum Befehl "set ... disable" wird nicht die Kamera an sich deaktiviert, sondern lediglich das Gerätemodul. In diesem Fall werden keine Funktionen mehr ausgeführt.
Wird das Modul deaktiviert, werden die folgenden Readings gesetzt:

<pre>
state: inactive
Availability: ???
PollState: Inactive
</pre>

Ist für eine Kamera Polling aktiviert, wird diese Aktivität abgeschaltet. Nach Reaktivierung des Gerätemoduls wird das Polling automatisch wieder fortgesetzt.

 

== Lösungsbeispiele und Ansätze für verschiedene Aufgabenstellungen ==

=== Eine Übersicht mit Hilfe von readingsGroup ===

Mit den umfangreichen Möglichkeiten des Moduls [[readingsGroup]] kann ein FHEM-Widget nach eigenen Vorstellungen erstellt werden. Hierbei ist es möglich sowohl einen Überblick über die Status der Kameras zu erhalten als auch Steuerungsaktivitäten vorzusehen. Das nachfolgende Beipiel soll als Anregung dafür dienen. Weitere Informationen unter der [http://fhem.de/commandref.html#readingsGroup commandref] zu readingsGroup.

'''Hinweis:'''
Die folgenden Beispiele enthalten keine Maskierungen oder Verdopplungen für ; und Zeilenende, sondern sind so angegeben, wie sie im Web Interface im Befehls-Eingabefeld, nach Klick auf DEF und im Attribut-Eingabefeld eingegeben werden. Mehrere Leerzeichen innerhalb von < > sind als <code><&nbsp;&nbsp;&nbsp;></code> zu kodieren.

{| class="wikitable"
! Definition !! Erläuterungen
|-
| colspan=2 | [[Bild:RgSSCam.jpg|thumb|500px|links|Kamerastatus und Steuerung]]
|-
| style="width:50%" |<code>define Cams_All_States readingsGroup <%it_camera>,<Verfügbar>,< >,<Status>,< >,<Erkennung>,< >,<letzte Aufnahme>,< >,<bel. Platz (MB)>,< >,<letzte Aktualisierung>,< >,<Modul Deaktivierung>,< >,<Image> TYPE=SSCam:Availability,
<&nbsp;&nbsp;&nbsp;>,state,<&nbsp;&nbsp;&nbsp;>,CamMotDetSc,<&nbsp;&nbsp;&nbsp;>,CamLastRecTime,<&nbsp;&nbsp;&nbsp;>,UsedSpaceMB,
<&nbsp;&nbsp;&nbsp;>,LastUpdateTime,<&nbsp;&nbsp;&nbsp;>,?!disable,<&nbsp;&nbsp;&nbsp;>,<%Start>,<%Stop></code>
| ReadingsGoup anlegen.
|-
| <code>attr Cams_All_States valueIcon {'Availability.enabled' => 'remotecontrol/black_btn_GREEN',
'Availability.disabled' => 'remotecontrol/black_btn_RED',
'state.inactive' => 'StandBy',
'state' => '%devStateIcon'}</code>
| In Abhängigkeit vom Wert der Kameraverfügbarkeit und des state-Readings entsprechende Icons anzeigen. Wird das Modul deaktiviert, wird ein Standby-Icon angezeigt unabhängig davon ob in der Kameradefinition ein devStateIcon hinterlegt wurde.
|-
| <code>attr Cams_All_States valueStyle {if($READING eq "Availability" && $VALUE eq "enabled"){ ' style="color:green" ' }
elsif( $READING eq "Availability" && $VALUE eq "disabled"){ ' style="color:red" ' }
elsif( $READING eq "CamMotDetSc" && $VALUE =~ /SVS.*/ ){ ' style="color:orange" ' }
elsif( $READING eq "CamMotDetSc" && $VALUE eq "disabled"){ ' style="color:LimeGreen" ' }
elsif( $READING eq "CamMotDetSc" && $VALUE =~ /Cam.*/ ){ ' style="color:SandyBrown" ' }}</code>
| Farbgestaltung der Texte in Anhängigkeit der Werte setzen.
|-
| <code>attr Cams_All_States valueFormat {($READING eq "CamMotDetSc" && $VALUE eq "disabled") ? "external" : $VALUE}</code>
| Wenn die Quelle der Bewegungserkennung auf "disabled" gestellt wurde, soll "external" in der Übersicht angezeigt werden weil die Bewegungserkennung in dem Fall durch IR-Melder durchgeführt wird.
|-
| <code>attr Cams_All_States valueColumns { 'Image' => 'colspan="2"'}</code>
| Die Überschrift "Image" soll sich über die letzten zwei Spalten strecken. Es gilt sowohl für "Start" und "Stop" .
|-
| <code>attr Cams_All_States nameStyle style="color:black;font-weight:bold"</code>
| Die Überschriften sollen schwarz und fett sein.
|-
| <code>attr Cams_All_States commands { 'Availability.enabled' => 'set $DEVICE disable',
'Availability.disabled' => 'set $DEVICE enable',
'Cams_All_States.Start' => 'set %DEVICE runView image',
'Cams_All_States.Stop' => 'set %DEVICE stopView',
disable => "disable:"}</code>
| Es sollen Kommandos bestimmten Readings / Werten unterlegt werden. Zum Beispiel kann die Kamera mit Klick auf das Availability-Icon disabled werden wenn der Readingswert "enabled" ist. Der Livestream kann mit "Start" in der letzten Spalte gestartet, oder das Modul über eine Auswahl in der Drop-Down-Liste unterhalb von "Modul Deaktivierung" deaktiviert/aktiviert werden.
|-
| <code>attr Cams_All_States cellStyle { "c:0" => 'style="text-align:left;color:green;font-weight:normal"',
"c:5" => 'style="text-align:center;color:green;font-weight:normal"',
"c:9" => 'style="text-align:center;font-weight:normal"'}</code>
| Formatierung bestimmter Spalten (0,5,9).
|-
| <code>attr Cams_All_States alias Status aller Kameras</code>
| Alias setzen.
|-
| <code>attr Cams_All_States group Kamerastatus</code>
| Gruppenzugehörigkeit setzen. Wird auch für die Anzeige im Dashboard benutzt.
|}

 

=== Mail mit Snapshot im Anhang und Aufnahmelink versenden (sendemail) ===

Nachfolgendes Beispiel zeigt eine Möglichkeit in Linux mit dem Tool [http://caspian.dotconf.net/menu/Software/SendEmail/ sendemail] eine Mail mit einem Link zu einer Kameraaufnahme und bis zu drei Anhängen zu versenden. Das Tool ist in vielen Repositories erhalten und kann unter Debian (z.B. Ubuntu) installiert werden mittels <code>apt-get install sendemail libio-socket-ssl-perl</code>.
Die Mail wird mit einem DOIF Kommando in Abhängigkeit von einer angefertigten Aufnahme angestoßen.

Zunächst die Mailfunktion in der 99_myUtils als Unterroutinen einfügen. Die Funktion ist nicht blockierend (mit Modul Blocking.pm) ausgeführt. Die "\" dienen nachfolgend nur
zur Kennzeichnung eines Zeilenumbruchs - den Code bitte auf eine Zeile schreiben.

<source lang=perl>
# Am Anfang von 99_myUtils hinzufügen
use Blocking;

##############################################################################
######## DebianMail Mail versenden nonblocking ############
##############################################################################

sub DebianMailnbl {

my $rcpt = shift;
my $subject = shift;
my $text = shift;
my $attach = shift;
my $attach1 = shift;
my $attach2 = shift;
my $hash->{NAME_MAIL} = "Debianmail";
my $name = $hash->{NAME_MAIL};

if ($attach2) {
$hash->{helper}{RUNNING_PID} = BlockingCall("DebianMailnbl_send", $name."|".$rcpt."|".$subject."|".$text."|".$attach." \
|".$attach1."|".$attach2, "", "", "", "");
} elsif ($attach1) {
$hash->{helper}{RUNNING_PID} = BlockingCall("DebianMailnbl_send", $name."|".$rcpt."|".$subject."|".$text."|".$attach."|" \
.$attach1, "", "", "", "");
} else {
$hash->{helper}{RUNNING_PID} = BlockingCall("DebianMailnbl_send", $name."|".$rcpt."|".$subject."|".$text."|".$attach,
"", "", "", "");
}

}

######################################################
######## Mailfunktion nonblocking
######################################################

sub DebianMailnbl_send {
my ($string) = @_;
my ($name, $rcpt, $subject, $text, $attach, $attach1, $attach2) = split("\\|", $string);
my $ret = "";
my $sender = "<Sendername>\@<Domäne>";
my $konto = "<Mailkonto";
my $passwrd = "<Mailkontopasswort>";
my $provider = "<Mailserver>";

if ($attach2) {
$ret .= qx(sendEmail -f '$sender' -t '$rcpt' -u '$subject' -m '$text' -a '$attach' -a '$attach1' -a '$attach2' -s '$provider' \
-xu '$konto' -xp '$passwrd' -o tls=no -o message -charset=utf-8 -o message-content-type=text/plain );
} elsif ($attach1) {
$ret .= qx(sendEmail -f '$sender' -t '$rcpt' -u '$subject' -m '$text' -a '$attach' -a '$attach1' -s '$provider' -xu '$konto' \
-xp '$passwrd' -o tls=no -o message-charset=utf-8 -o message-content-type=text/plain );
} else {
$ret .= qx(sendEmail -f '$sender' -t '$rcpt' -u '$subject' -m '$text' -a '$attach' -s '$provider' -xu '$konto' -xp '$passwrd' \
-o tls=no -o message-charset=utf-8 -o message-content-type=text/plain );
}

# remove CR from return-string
$ret =~ s,[\r\n]*,,g;

Log3 $name, 3, "$name - sendEmail returned: $ret";
}
</source>

Um die TLS Verschlüsselung (ehem. SSL) zu nutzen, dann tls=auto verwenden.

Falls der Body-Text in einem (Android-)Mailer auf dem Handy nicht gezeigt wird, kann evtl. der Parameter '''-o message-content-type=html''' helfen.

 
==== Versand triggern - Beispiel mit DOIF ====
Der Mailversand wird in dem Beispiel mit einem DOIF angetriggert:

<pre>
define CamHE1.email DOIF ([CamHE1:"CamLastRec"]) ({DebianMailnbl ('<Empfänger>@<Domäne>','Bewegungsalarm CamHE1','Eine Bewegung wurde an der Haustür registriert.
Aufnahmelink: [CamHE1:VideoFolder]/[CamHE1:CamLastRec]','/media/sf_surveillance/@Snapshot/[CamHE1:LastSnapFilename]')})
</pre>

Wird eine Aufnahme der Kamera CamHE1 beendet, wird integriert der Befehl "get .. eventlist" ausgeführt. Dadurch aktualisiert sich das Reading "CamLastRec".
Dieser Event wird genutzt um eine Mail mit einem Link zur Aufnahme und einem während der Aufnahme angelegten Schnappschuß zu versenden.
Will man einen weiteren Anhang versenden, sähe das DOIF folgendermaßen aus:

<pre>
define CamHE1.email DOIF ([CamHE1:"CamLastRec"]) ({DebianMailnbl ('<Empfänger>@<Domäne>','Bewegungsalarm CamHE1','Eine Bewegung wurde an der Haustür registriert.
Aufnahmelink: [CamHE1:VideoFolder]/[CamHE1:CamLastRec]','/media/sf_surveillance/@Snapshot/[CamHE1:LastSnapFilename]','<weiteres File>')})
</pre>

Dss Reading "VideoFolder" muß, wie in dem Beispiel zu sehen, dem "CamLastRec" vorangestellt werden um den kompletten Pfad zur Aufnahme zu erhalten. Der versendete Link würde somit etwa den folgenden Aufbau haben:

<pre>
/volume1/surveillance/Carport/20160407PM/Carport20160407-221541-1460060141.mp4
</pre>

Wenn in einer Mail nach extern versendet wird, ist ein solcher Link wahrscheinlich über eine Anwendung nicht zugreifbar.
Um den Link dynamisch anzupassen und so den Zugriff von extern über z.B. einen Webserver zu ermöglichen, kann das Attribut "videofolderMap" verwendet werden.

Wird dieses Attribut auf zum Beispiel ...<pre>"http://<Server>:8083/fhem/svs/Carport/"</pre> ...gesetzt, ergibt sich folgender Link der in der Mail versendet wird:

<pre>
http://<Server>:8083/fhem/svs/Carport/20160407PM/Carport20160407-221541-1460060141.mp4
</pre>

In dem obigen Beispiel wird ein FHEM-Webserver verwendet, der zuvor über HTTPSRV (siehe Commandref) angelegt wurde,
WIe der Webserver angelegt werden kann ist [[SSCAM_-_Steuerung_von_Kameras_in_Synology_Surveillance_Station#Einsatz_FHEM_Webserver_zum_Zugriff_auf_Aufnahmen | hier]] beschrieben.

'''Hinweis:'''

Nach dem Snapshot wird implizit die Funktion "get ... snapfileinfo" aufgerufen. Diese Funktion trägt den neuen/letzten Snapfilename in das Reading "LastSnapFilename" ein.
Es ist somit sicherzustellen dass dieses Funktion abgeschlossen ist bevor die Aufnahme per Mail versendet werden soll. Das kann zum Beispiel mit einem Notify auf den Event "<Device>:LastSnapFilename.*" geschehen.
Sollten das Problem auftreten dass alte Snapshots versendet werden, ist aller Wahrscheinlichkeit nach in dem beschriebenen Sachverhalt die Ursache zu finden.

 

==== Versand triggern - Beispiel mit Notify ====

Mit diesem Notify wird das Snapshotfile angehängt und auch ein Link zu dem Snapshot mit eingefügt.

<pre>
define CamHE1.email NOTIFY CamHE1:LastSnapFilename.* {DebianMailnbl ('<Empfänger>@<Domäne>','Bewegungsalarm CamHE1',
'Eine Bewegung wurde an der Haustür registriert. Aufnahmelink: http://<Server>:8083/fhem/snap/'.(ReadingsVal("CamHE1","LastSnapFilename","")),
'/media/sf_surveillance/@Snapshot/'.(ReadingsVal("CamHE1","LastSnapFilename","")))}
</pre>

Um den Link in dieser Form aufrufen zu können ist erst ein HTTPSRV anzulegen mit:

<pre>
define snapweb HTTPSRV snap /media/sf_surveillance/@Snapshot SVS-Snapshots
</pre>

Natürlich muß dabei der Pfad "/media/sf_surveillance/" so angepasst werden dass er dem (gemounteten) SVS-Aufnahmeverzeichnis entspricht.

 

=== Einsatz eines Webservers zum Zugriff auf Aufnahmen ===

==== Nutzung des FHEM-internen HTTPSRV Plug-In ====

Ziel der nachfolgenden Beschreibung ist es, eine Möglichkeit darzustellen, um den FHEM Webserver für den Zugriff auf die Aufnahmen der Synology Surveillance Station zu nutzen.

Folgende Ausgangslage wird für das Beispiel als gegeben angenommen:

* der gemeinsame Ordner der Surveillance Station (normalerweise "surveillance") in der Diskstation ist am FHEM-Server gemountet. Für das Beipiel ist das gemountete Verzeichnis: /media/sf_surveillance
* FHEMWEB ist im Einsatz
* für das Beispiel ist eine Kamera CamHE1 (SVS-Name: Hauseingang) definiert

HTTPSRV ist ein Plug-in für FHEMWEB und stellt den Webserver für den Zugriff zur Verfügung. Diese Möglichkeit ist sicherlich für jene Fälle interessant bei denen der Zugriff über einen Verzeichnisdienst nicht möglich oder nicht gewünscht ist (zum Bespiel von extern).
Es steht auch eine Modul-interne Zugriffsmöglichkeit auf die letzte Aufnahme mit dem Befehl "set CamHE1 runView lastrec (oder lastrec_open)" zur Verfügung.

Der Webserver wird definiert mit:

define svsweb HTTPSRV svs /media/sf_surveillance WebServer SVS-Aufnahmen

Der definierte Webserver sollte nun links im Seitenmenü unter dem Namen "WebServer SVS-Aufnahmen" erscheinen. Ein Klick auf diesen Link sollte nun die Meldung zeigen:

File not found: /media/sf_surveillance/index.html

Die Datei index.html existiert natürlich normalerweise nicht im surveillance-Verzeichnis. Der Inhalt des Verzeichnisses "/media/sf_surveillance", also des surveillance-Stammordners, wird nun mit der Basisadresse ... <pre>http://<FHEM-Server>:8083/fhem/svs/</pre> ...erreicht.

Alle Aufnahmen der Kameras werden in Unterordnern des surveillance-Stammerzeichnisses gespeichert, die den gleichen Namen wie die Kamera in der Surveillance Station haben. Um den Pfad zu dem Aufnahmefile zu spezifizieren, ist die Basisadresse des erstellten Webservers mit dem Unterordner der entsprechenden Kamera zu ergänzen. Mit diesem zusammengesetzten Gesamtpfad ist ebenfalls das Reading "VideoFolder", welches den physikalischen Pfad von Aufnahmen der entsprechenden Kamera beschreibt, zu überschreiben.

Die wird mit dem Attribut "videofolderMap" erreicht. In dem Beispiel wird es gesetzt auf:

<pre>
attr CamHE1 videofolderMap http://<FHEM-Server>:8083/fhem/svs/Hauseingang/
</pre>

Jede Aufnahme der Kamera "Hauseingang" bzw. "CamHE1" wird somit durch die Webadresse ...

<pre>
http://<FHEM-Server>:8083/fhem/svs/Hauseingang/<Inhalt Reading CamLastRec>
</pre>

... erreicht.

Wie eine Mail mit diesem Link versendet werden kann ist [[SSCAM_-_Steuerung_von_Kameras_in_Synology_Surveillance_Station#Mail_mit_Snapshot_im_Anhang_und_Aufnahmelink_versenden_.28sendmail.29 | hier]] beschrieben.

Der komplette in der Mail versendete Aufnahmelink sieht folgendermaßen aus:
<pre>
http://<FHEM-Server>:8083/fhem/svs/Hauseingang//20160408PM/Hauseingang20160408-215150-1460145110.mp4
</pre>

 

==== Nutzung der Webstation auf Synology DS zum Zugriff auf Recordings ====

Da die Benutzung des HTTPSRV für diesen Zweck FHEM belastet bzw. blockiert, hat Martin Fischer im Forum unter:
https://forum.fhem.de/index.php/topic,45671.msg482616.html#msg482616

zwei Möglichkeiten bschrieben wie man den internen Webserver des Synology DS statt dessen verwenden kann (DSM 6).

Darauf aufbauend ist hier folgend die Umsetzung im DSM 5.2 beschrieben.

'''1. schnelle Variante A'''

Die nachfolgende Beschreibung bezieht sich auf DSM 5.2. Es wird ein virtueller Host (test.myds.me) definiert, der auf Port HTTP 8081 hört. Das Dokument-Root soll in dem Beispiel der Ordner "/volume1/web/fhemsvs" sein.

* Nach dem Login als root wechselt man in das web-Verzeichnis mit "cd /volume1/web"
* anlegen des Root-Verzeichnisses für den virtuellen Host und setzen der Berechtigungen:
mkdir fhemsvs
chown http:http fhemsvs
chmod 775 fhemsvs

* Link im Root-Verzeichnis zum SVS-Stammverzeichnis setzen:
ln -s /volume1/surveillance/ /volume1/web/fhemsvs

(Hinweis: Wenn es zu Problemen beim Mailversand kommt - "leere" Bilder angehängt -, schaut mal, ob das Verzeichnis richtig ist. Einige (Beta-)Versionen von SVS benutzen @surveillance statt surveillance als Verzeichnis, so dass ein leicht anderer Link gesetzt werden muss: ln -s /volume1/\@surveillance/ /volume1/web/fhemsvs)

* einen virtuellen Host in Systemsteuerung -> Webdienste -> virtueller Host anlegen. Soll der Host von extern erreichbar sein, muß ebenfalls eine Registrierung des Hostnamens z.B. bei dem kostenfreien DNS-Dienst von Synology erfolgen sowie der verwendete Port im Router freigeschaltet werden.

[[Bild:vHost.PNG|left|thumb|300px|]] Der virtuelle Host ist durch die Angabe des Unterodners (fhemsvs), des Hostnamens (test.myds.me), des Protokolls und des Ports (8081) zu definieren. Die Angaben sind natürlichen den realen Werten anzupassen.

* die Recordings sind nun prinzipiell unter der Adresse erreichbar:
<pre>
http://test.myds.me:8081/surveillance/<Camname>/<Zeitordner>/<Dateiname>
</pre>

* in FHEM ist der Zugangspfad zu dem Aufnahmen zusammengesetzt aus den Readings "VideoFolder" (Original z.B. /volume1/surveillance/Carport) und "CamLastRec". Über das Attribut "videofolderMap" wird "/volume1/surveillance/Carport" nun ersetzt durch <pre>"http://test.myds.me:8081/surveillance/Carport/"</pre>

Der substituierte Aufnahmelink wird nun zu: (ReadingsVal("<camname>","VideoFolder","")).(ReadingsVal("<name>","CamLastRec",""))

* Der Versand des Aufnahmelinks per Mail kann durch ein Notify erfolgen:

define N.CamCP1.Rec.Email notify CamCP1:CamLastRec:.* {DebianMailnbl ('<Mailempfänger>','Bewegungsaufnahme Carport', 'Aufnahmelink: '.(ReadingsVal("CamCP1","VideoFolder","")).(ReadingsVal("CamCP1","CamLastRec",""))) }

Die Funktion DebianMailnbl für den Mailversand ist zuvor in 99_myUtils zu definieren. (siehe [[#Mail_mit_Snapshot_im_Anhang_und_Aufnahmelink_versenden_.28sendmail.29 | Mailversandroutine]] )

* Der Versand des Aufnahmelinks per TelegramBot kann durch folgendes Notify erfolgen:

define N.CamCP1.Rec.TeleBot notify CamCP1:CamLastRec:.* { my $var = (ReadingsVal("CamCP1","VideoFolder","")).(ReadingsVal("CamCP1","CamLastRec","")); fhem ("set teleBot message $var Bewegungsaufnahme beim Carport"); }

Natürlich ist TelegramBot vorab einzurichten. Der Versand erfolgt in dem Beispiel an den defaultPeer.

 

'''2. Variante B'''

(noch für DSM 5.2 zu beschreiben).

 

=== Workaround bei DSM 2-Stufen Verifizierung ===
1. Benutzer in der SVS einrichten, zum Manager machen 
2. Benutzer wird automatisch auch in FHEM eingerichtet, dort zum Admin machen 
3. 2-Stufen Verifizierung ausschalten 
4. Modul / Kamera zum Laufen bringen 
5. Session im Modul auf SVS stellen 
6. Benutzer in der DSM aus der Admin-Gruppe rausnehmen 
7. 2-Stufen Verifizierung einschalten (Option nur für Admins) 

== Hinweise zu Fehlern ==
=== "Execution failed" in Snap-Funktion nach SVS update auf 8.0.1 ===

Die Rechte auf das Verzeichnis /volume1/surveillance/@Snapshot wurden nicht auf den neuen Benutzer/Gruppe SurveillanceStation/SurveillanceStation umgesetzt.

Mit

chown -R SurveillanceStation:SurveillanceStation /volume1/surveillance/@Snapshot

konnte das Problem behoben werden.
Die Rechte des Verzeichnisses sind jetzt:

<pre>
drwxrwxrwx 8 root root 4096 Mar 4 16:03 .
drwxr-xr-x 49 root root 4096 Mar 4 15:06 ..
drwxrwxrwx 47 SurveillanceStation SurveillanceStation 4096 Mar 3 21:26 Carport
drwxrwxrwx+ 3 root root 4096 Mar 2 01:01 @eaDir
drwxr-xr-x 24 SurveillanceStation SurveillanceStation 4096 Mar 4 15:07 Hauseingang
drwxr-xr-x 4 SurveillanceStation SurveillanceStation 4096 Feb 26 19:59 Keller
drwxr-xr-x 3 SurveillanceStation SurveillanceStation 45056 Mar 4 15:39 @Snapshot
drwxr-xr-x 20 SurveillanceStation SurveillanceStation 4096 Mar 3 07:17 Terrasse
</pre>

Wochenende, Feiertage und Schulferien

2017-02-26T11:36:28Z

Motivierte linke Hände: schulferien.org durch Ferienwiki.de ersetzt, siehe https://forum.fhem.de/index.php?topic=65155.0

FHEM bietet mehrere Möglichkeiten, Komponenten in Abhängigkeit von Wochenenden, Feiertagen oder sogar Schulferien zu steuern.

Eine simple Rollladensteuerung um 7 Uhr morgens sieht beispielsweise wie folgt aus:

define RolloHoch at *07:00 set Rollo hoch

== Wochenendermittlung mit $we ==
Um am Wochenende (Samstag und Sonntag) länger schlafen zu können, kann diese Steuerung durch Nutzung der Variable ''$we'' erweitert werden.
Diese hat am Wochenende den Wert ''1'', an sonstigen Tagen den Wert ''0''. In if-Abfragen wird die 0 als ''false/falsch'' interpretiert, andere numerische Werte als ''true/wahr''. Man kann mittels ''if ($we)'' also ganz einfach prüfen, ob Wochenende ist und entsprechend steuern (oder auch nicht). Das o.a. Beispiel kann entsprechend ergänzt werden, so dass am Wochenende nicht um 7 Uhr das Rollo nach oben gefahren wird:

define RolloHoch at *07:00 { if (!($we)) { fhem("set Rollo hoch");; } }

Das ''!'' in der if-Abfrage negiert den dahinter folgenden Ausdruck in der Klammer, quasi ein "ist nicht Wochenende". Der Inhalt der äußeren geschweiften Klammern stellt echten Perl-Code dar (der hinter jeder Anweisung gerne ein Semikolon stehen hat, das in FHEM durch ein weiteres Semikolon [http://de.wikipedia.org/wiki/Maskierungszeichen maskiert/escaped] werden muss). Aus dem Perl-Code kann man mittels des Befehls ''fhem()'' wiederum FHEM-Code ausführen (hier der Befehl, um das Rollo nach oben zu fahren). Das (Doppel-)Semikolon ist in diesem Beispiel nicht zwingend notwendig, da es sich nur um eine einzige (und somit letzte) Anweisung handelt - man sollte sich jedoch aneignen, jede Anweisung im Perl-Code mit einem (Doppel-)Semikolon abzuschließen (eine schließende geschweifte Klammer stellt auch das Ende eine Anweisung bzw. eines Anweisungsblocks dar).

== Feiertage mittels holiday-Datei ==
Samstags und Sonntags bleibt das Rollo nun unten und man kann länger schlafen. Um diesen Komfort auch an Feiertagen zu haben, können in FHEM mittels ''holiday''-Dateien Feiertage definiert werden. Sinnvollerweise erstellt man sich für sein jeweiliges Bundesland eine eigene Datei, die Definitionen für feste Feiertage (z.B. Weihnachten oder der Tag der Deutschen Einheit) und solche in Abhängigkeit zu Ostern (z.B. Ostermontag oder Pfingsten, im Rheinland auch der Karneval) beinhaltet. Eine gutes Beispiel mit Erklärung findet sich in der [http://fhem.de/Heimautomatisierung-mit-fhem.pdf FHEM-Übersicht für Anfänger].
Nachdem beispielsweise die ''NRW_Feiertag.holiday''-Datei im FHEM-Ordner erstellt/abgelegt wurde, kann diese in die Konfiguration eingebunden werden. Mittels ''holiday2we'' können die darin definierten Feiertage mit der Variable ''$we'' "verheiratet" werden. ''if ($we)'' ist danach immer wahr, sobald Wochenende oder ein Feiertag ist:

attr global holiday2we NRW_Feiertag
define NRW_Feiertag holiday

== Feiertage mittels Internet-Kalender ==
Theoretisch kann man in o.a. Datei auch seine persönlichen Urlaube oder die Schulferien definieren. Hier eignet sich jedoch die ''Calendar''-Funktion wesentlich besser. V.a. die Schulferien der einzelnen Bundesländer sind im Internet (z.B. unter [http://www.ferienwiki.de ferienwiki.de]) als iCal-Datei verfügbar und können wie folgt in FHEM eingebunden werden:

define NRW_Ferien Calendar ical url https://www.ferienwiki.de/exports/ferien/2017/de/baden-wuerttemberg 86400

Das Intervall von 86400 Sekunden (entspricht 24 Stunden) für die Aktualisierung der Schulferien sollte im Normalbetrieb mehr als ausreichen. Wenn eigene Kalender (z.B. bei Google) für Urlaubstage genutzt werden, muss man individuell abwägen, wie oft dieser aktualisiert werden soll.

Um nun diesen Kalender nun nutzen zu können, benötigt FHEM einen ''dummy'', der entsprechend abgefragt werden kann:

define NRW_Ferientag dummy
define NRW_Ferien.notify notify NRW_Ferien { \
fhem "set BW_Ferientag " . (ReadingsVal("BW_Ferien", "modeStart", "") =~ "schulferien" ? 1: 0) }

Der ''BW_Ferientag'' ist in diesem Beispiel der angesprochene ''dummy'' und kann mittels ''Value("BW_Ferientag")'' abgefragt werden. Im ''notify'' wird der Wert gesetzt, sobald der Kalender aktualisiert wird: Eine ''1'' für einen Tag, an dem der Text "schulferien" in einem Ereignis vorkommt, das sich im ''modeStart''Modus (vgl. [http://www.fhem.de/commandref.html#Calendar CommandRef] - ''The start time has passed but the end time of the calendar event is not yet reached.'') befindet, ansonsten ''0''. Das Vorkommen des Textes ist in den Ereignissen der oben genutzten Quelle immer der Fall.

Um ein Rollo nun weder am Wochenende, an Feiertagen, noch zu Schulferien morgens hochfahren zu lassen, lautet das Beispiel:

define RolloHoch at *07:00 { if ( !($we) && !(Value("BW_Ferientag")) ) { fhem("set Rollo hoch");; } }

Ausgehend von diesem Artikel ist unter [[Google-Kalender zur Steuerung von Dummies]] eine Vorgehensweise zur
Steuerung von FHEM mit dem Google-Kalender veröffentlicht.

Diese Methode unterstützt jedoch nicht die Feiertagserkennung des [http://fhem.de/commandref_DE.html#DOIF DOIF]-Moduls, speziell im Abschnitt [http://fhem.de/commandref_DE.html#DOIF_Wochentagsteuerung Wochentagssteuerung]. Hier wird nur der Status der ''$we''-Variable abgefragt und die Methode mit dem eigenen Holiday-Kalender empfohlen.

[[Kategorie:Code Snippets]]

SSCAM - Steuerung von Kameras in Synology Surveillance Station

2016-12-04T12:52:51Z

Motivierte linke Hände: Ab SVS Version 8 anderes Verzeichnis für Snapshots

{{Infobox Modul
|ModPurpose=Steuerung von Kameras in Synology Surveillance Station
|ModType=d
|ModCmdRef=SSCam
|ModForumArea=Sonstiges
|ModTechName=49_SSCam.pm
|ModOwner=nasseeder1 (Forum: DS_Starter)}}

== Zweckbeschreibung ==

Mit diesem Modul können Operationen von in der Synology Surveillance Station (SVS) definierten Kameras ausgeführt werden.
Es basiert auf der SVS API und unterstützt die SVS ab Version 7.
Zur Zeit werden folgende Funktionen unterstützt:

* Start einer Aufnahme
* Stop einer Aufnahme (per Befehl bzw. automatisch nach Ablauf der Aufnahmedauer)
* Aufnehmen eines Schnappschusses und Ablage in der Synology Surveillance Station
* Deaktivieren einer Kamera in Synology Surveillance Station
* Aktivieren einer Kamera in Synology Surveillance Station
* Steuerung der Belichtungsmodi Tag, Nacht bzw. Automatisch
* Umschaltung der Ereigniserkennung durch Kamera, durch SVS oder deaktiviert
* Abfrage von Kameraeigenschaften (auch mit Polling) sowie den Eigenschaften des installierten SVS-Paketes
* Bewegen an eine vordefinierte Preset-Position (bei PTZ-Kameras)
* Start einer vordefinierten Überwachungstour (bei PTZ-Kameras)
* Positionieren von PTZ-Kameras zu absoluten X/Y-Koordinaten
* kontinuierliche Bewegung von PTZ-Kameras
* auslösen externer Ereignisse 1-10 (Aktionsregel SVS)
* starten und beenden von Kamera-Livestreams
* Abruf und Ausgabe der Kamera Streamkeys sowie Stream-Urls (zur Nutzung von Kamera-Livestreams ohne Session Id)
* abspielen der letzten Aufnahme

Die Aufnahmen stehen in der Synology Surveillance Station (SVS) zur Verfügung und unterliegen, wie jede andere Aufnahme, den in der Synology Surveillance Station eingestellten Regeln.
So werden zum Beispiel die Aufnahmen entsprechend ihrer Archivierungsfrist gespeichert und dann gelöscht.

Wenn sie über dieses Modul diskutieren oder zur Verbesserung des Moduls beitragen möchten, ist im FHEM-Forum ein Sammelplatz unter: 
{{Link2Forum|Topic=45671.0 |LinkText=49_SSCam: Fragen, Hinweise, Neuigkeiten und mehr rund um dieses Modul}}

 

== Vorbereitung ==

Dieses Modul nutzt das Perl-Modul JSON. Bitte darauf achten dieses Paket zu installieren. (Debian: apt-get install libjson-perl).
SSCAM verwendet für HTTP-Calls die nichtblockierenden Funktionen von HttpUtils bzw. HttpUtils_NonblockingGet.
Im DSM bzw. der Synology Surveillance Station muß ein Nutzer für den Zugriff aus FHEM angelegt sein. Die Zugangsdaten für diesen Nutzer werden später über ein Set-Kommando dem angelegten Gerät zugewiesen. 
Nähere Informationen dazu unter [[#Credentials | Credentials]].

Überblick über die Perl-Module welche von SSCam genutzt werden: 

JSON
Data::Dumper
MIME::Base64
Time::HiRes
HttpUtils (FHEM-Modul)

 

== Define ==
<pre>
define <name> SSCam <Kameraname in SVS> <ServerAddr> [Port]
</pre>

Definiert eine neue Kamera für SSCam. Zunächst muß diese Kamera in der Synology Surveillance Station 7.0 oder höher eingebunden sein und entsprechend funktionieren.

Das Modul SSCam basiert auf Funktionen der Synology Surveillance Station API.
Weitere Informationen unter: [http://global.download.synology.com/download/Document/DeveloperGuide/Surveillance_Station_Web_API_v2.0.pdf Web API Guide].

Momentan wird nur das HTTP-Protokoll unterstützt um die Web-Services der Synology DS aufzurufen.

Die Parameter beschreiben im Einzelnen:

<pre>
name : der Name des neuen Gerätes in FHEM
Kameraname : Kameraname wie er in der Synology Surveillance Station angegeben ist. Leerzeichen im Namen sind nicht erlaubt !
ServerAddr : die IP-Addresse des Synology Surveillance Station Host.
Achtung: Es sollte kein Servername verwendet werden weil DNS-Aufrufe in FHEM blockierend sind
Port : optional - der Port des Synology Surveillance Station Host.
Wenn nicht angegeben, wird der Standardport 5000 gesetzt(nur HTTP)
</pre>

Beispiel:

define CamCP SSCAM Carport 192.168.2.20 [5000]

Wird eine neue Kamera definiert, wird diesem Device zunächst eine Standardaufnahmdauer von 15 zugewiesen.
Über das Attribut "rectime" kann die Aufnahmedauer für jede Kamera individuell angepasst werden. Der Wert "0" für "rectime" führt zu einer Endlosaufnahme die durch '''"set <name> off"''' gestoppt werden muß. Ein Logeintrag mit einem entsprechenden Hinweis auf diesen Umstand wird geschrieben.

Wird das Attribut "rectime" gelöscht, greift wieder der Default-Wert (15s) für die Aufnahmedauer.

Mit dem Befehl '''"set <name> on [rectime]"''' wird die Aufnahmedauer temporär festgelegt und überschreibt einmalig sowohl den Defaultwert als auch den Wert des gesetzten Attributs "rectime". Auch in diesem Fall führt "set <name> on 0" zu einer Daueraufnahme.

Eine eventuell in der SVS eingestellte Dauer der Voraufzeichnung wird weiterhin berücksichtigt.

=== Credentials ===

Nach dem Definieren des Gerätes müssen zuerst die Zugangsparameter gespeichert werden. Das geschieht mit dem Befehl:

set <name> credentials <username> <password>

Der Anwender kann in Abhängigkeit der beabsichtigten einzusetzenden Funktionen einen Nutzer im DSM bzw. in der Surveillance Station einrichten.
Ist der DSM-Nutzer der Gruppe Administratoren zugeordnet, hat er auf alle Funktionen Zugriff. Ohne diese Gruppenzugehörigkeit können nur Funktionen mit niedrigeren Rechtebedarf ausgeführt werden. Die benötigten Mindestrechte der Funktionen sind in der Tabelle weiter unten aufgeführt.
Alternativ zum DSM-Nutzer kann ein in der SVS angelegter Nutzer verwendet werden. Auch in diesem Fall hat ein Nutzer vom Typ Manager das Recht alle Funktionen auszuführen, wobei der Zugriff auf bestimmte Kameras/ im Privilegienprofil beschränkt werden kann (siehe Hilfefunktion in SVS).
Als Best Practice wird vorgeschlagen jeweils einen User im DSM und einen in der SVS anzulegen.

* DSM-User als Mitglied der Admin-Gruppe: uneingeschränkter Test aller Modulfunktionen -> session:DSM
* SVS-User als Manager oder Betrachter: angepasstes Privilegienprofil -> session: SurveillanceStation

Über das Attribut "session" kann ausgewählt werden, ob die Session mit dem DSM oder der SVS augebaut werden soll.
Erfolgt der Session-Aufbau mit dem DSM, stehen neben der SVS Web-API auch darüber hinaus gehende API Zugriffe zur Verfügung die unter Umständen zur Verarbeitung benötigt werden.

Nach der Gerätedefinition ist die Grundeinstellung "Login in das DSM", d.h. es können Credentials mit Admin-Berechtigungen genutzt werden um zunächst alle Funktionen der Kameras testen zu können. Danach können die Credentials z.B. in Abhängigkeit der benötigten Funktionen auf eine SVS-Session mit entsprechend beschränkten Privilegienprofil umgestellt werden.

Die nachfolgende Aufstellung zeigt die Mindestanforderungen der jeweiligen Modulfunktionen an die Nutzerrechte.
<pre>
* set ... on session: ServeillanceStation - Betrachter mit erweiterten Privileg "manuelle Aufnahme"
* set ... off session: ServeillanceStation - Betrachter mit erweiterten Privileg "manuelle Aufnahme"
* set ... snap session: ServeillanceStation - Betrachter
* set ... disable session: ServeillanceStation - Manager
* set ... enable session: ServeillanceStation - Manager
* set ... expmode session: ServeillanceStation - Manager
* set ... motdetsc session: ServeillanceStation - Manager
* set ... goPreset session: ServeillanceStation - Betrachter mit Privileg Objektivsteuerung der Kamera
* set ... runPatrol session: ServeillanceStation - Betrachter mit Privileg Objektivsteuerung der Kamera
* set ... goAbsPTZ session: ServeillanceStation - Betrachter mit Privileg Objektivsteuerung der Kamera
* set ... move session: ServeillanceStation - Betrachter mit Privileg Objektivsteuerung der Kamera
* set ... runView session: ServeillanceStation - Betrachter mit Privileg Liveansicht für Kamera
* set ... stopView -
* set ... credentials -
* set ... extevent session: DSM - Nutzer Mitglied von Admin-Gruppe
* get ... caminfoall session: ServeillanceStation - Betrachter
* get ... eventlist session: ServeillanceStation - Betrachter
* get ... svsinfo session: ServeillanceStation - Betrachter
* get ... svsinfo session: ServeillanceStation - Betrachter
* get ... stmUrlPath session: ServeillanceStation - Betrachter

</pre>

=== HTTP-Timeout setzen ===

Alle Funktionen dieses Moduls verwenden HTTP-Aufrufe gegenüber der SVS Web API. 
Der Standardwert für den HTTP-Timeout beträgt 4 Sekunden.
Durch Setzen des Attributes "httptimeout" > 0 kann dieser Wert bei Bedarf entsprechend den technischen Gegebenheiten angepasst werden.

 

== Set ==

Es gibt zur Zeit folgende Optionen für "set <name> ...".

<pre>
"on [rectime]": startet eine Aufnahme. Die Aufnahme wird automatisch nach Ablauf der Zeit [rectime]
gestoppt.
mit rectime = 0 wird eine Daueraufnahme gestartet die durch "set <name> off"
wieder gestoppt werden muß.
"off" : stoppt eine laufende Aufnahme manuell oder durch die Nutzung anderer Events
(z.B. über at, notify)
"snap": löst einen Schnappschuß der entsprechenden Kamera aus und speichert ihn in der SVS
"disable": deaktiviert eine Kamera in der Surveillance Station
"enable": aktiviert eine Kamera in der Surveillance Station
"credentials <username> <password>": speichert die Zugangsinformationen
"expmode [ day | night | auto ]": aktiviert den Belichtungsmodus Tag, Nacht oder Automatisch
"extevent [ 1-10 ]": löst das externe Ereignis 1-10 aus (Aktionsregeleditor in SVS)
"motdetsc [ by_camera | by_SVS | disable ]": schaltet die Bewegungserkennung in den gewünschten Modus
(durch Kamera, SVS, oder deaktiviert)
"goPreset <Presetname>": fährt eine PTZ-Kamera zu einer vordefinierten Preset-Position
"runPatrol <Patrolname>": startet eine vordefinierte Überwachungstour einer PTZ-Kamera
"goAbsPTZ [ X Y | up | down | left | right ]": positioniert eine PTZ-Kamera zu einer X/Y-Koordinate oder in Richtung up/down/left/right
"move [ up | down | left | right | dir_X ]": startet kontinuerliche Bewegung einer PTZ-Kamera in Richtung up/down/left/right bzw. dir_X
"runView [image | lastrec | lastrec_open |
link | link_open <room>]": startet einen Livestream bzw. die letzte Aufnahme als eingbettetes Image, als Link
oder öffnet diesen Medienstream sofort
"stopView": Gegenteil von "runView"
</pre>

=== set <name> [on [rectime] | off] ===

Der Befehl "set <name> on" startet eine Aufnahme. Die Standardaufnahmedauer beträgt 15 Sekunden. Sie kann mit dem Attribut "rectime" individuell festgelegt werden. Die im Attribut (bzw. im Standard) hinterlegte Aufnahmedauer kann einmalig mit "set <name> on [rectime]" überschrieben werden.
Die Aufnahme stoppt automatisch nach Ablauf der Zeit "rectime".

Ein Sonderfall ist der Start einer Daueraufnahme mit "set <name> on 0" bzw. dem Attributwert "rectime = 0". In diesem Fall wird eine Daueraufnahme gestartet die explizit wieder mit dem Befehl ""set <name> off" gestoppt werden muß.

Das Aufnahmeverhalten kann weiterhin mit dem Attribut "recextend" wie folgt beeinflusst werden.

'''Attribut "recextend = 0" bzw. nicht gesetzt (Standard):'''
* wird eine Aufnahme mit z.B. rectime=22 gestartet, wird kein weiterer Startbefehl für eine Aufnahme akzeptiert bis diese gestartete Aufnahme nach 22 Sekunden beendet ist. Ein Hinweis wird bei verbose=3 im Logfile protokolliert.

'''Attribut "recextend = 1" gesetzt:'''
* eine zuvor gestartete Aufnahme wird bei einem erneuten "set <name> on"-Befehl mit der Aufnahmezeit "rectime" neu parametrisiert. Das bedeutet, dass der Timer für den automatischen Stop auf den Wert "rectime" neu gesetzt wird. Dieser Vorgang wiederholt sich mit jedem Start-Befehl. Dadurch verlängert sich eine laufende Aufnahme bis kein Start-Inpuls mehr registriert wird.

* eine zuvor gestartete Endlos-Aufnahme wird mit einem erneuten "set <name> on"-Befehl nach der Aufnahmezeit "rectime" gestoppt (Timerneustart). Ist dies nicht gewünscht, ist darauf zu achten dass bei der Verwendung einer Endlos-Aufnahme das Attribut "recextend" nicht verwendet wird.

Beispiele für einfache Operationen:

<pre>
set <name> on [rectime] : startet die Aufnahme der Kamera <name>.
set <name> off : stoppt die Aufnahme der Kamera <name>
set <name> disable : deaktiviert die Kamera <name> in der Surveillance Station
set <name> enable : aktiviert die Kamera <name> in der Surveillance Station
</pre>

'''Hinweis:'''

In der SVS kann unter Aufnahmeeinstellungen der Kamera eine Vor-Aufnahmezeit eingestellt werden. Die Einstellung wird von der SVS bezüglich der Gesamtaufnahmezeit automatisch mit berücksichtigt.

Eine eingestellte Vor-Aufnahmezeit von z.B. 10s und eine rectime von 20s führt zu einer Gesamtaufnahmezeit von 30s (zzgl. Prozesszeit zur Befehlsabarbeitung).

=== set <name> snap ===

Ein Schnappschuß kann ausgelöst werden durch:

<pre>
set <name> snap
</pre>

Soll eine Reihe Schnappschüsse ausgelöst werden wenn eine Aufnahme startet, kann das durch folgendes notify geschehen.
Wird der Start der Kamera CamHE1 ausgelöst (vorher Attribut event-on-change-reading -> "Record" setzen), werden 3 Snapshots im Abstand von 2 Sekunden getriggert.

<pre>
define he1_snap_3 notify CamHE1:Record.*on define h3 at +*{3}00:00:02 set CamHE1 snap
</pre>

Triggern von 2 Schnappschüssen der Kamera "CamHE1" im Abstand von 6 Sekunden nachdem der Bewegungsmelder "MelderHE1" einen Event gesendet hat, kann z.B. mit folgendem notify geschehen:

<pre>
define he1_snap_2 notify MelderHE1:on.* define h2 at +*{2}00:00:06 set CamHE1 snap
</pre>

Es wird die ID des letzten Snapshots als Wert der Variable "LastSnapId" in den Readings der Kamera ausgegeben.

=== set <name> [enable] [disable] ===

Um eine Liste von Kameras oder alle Kameras (mit Regex) zum Beispiel um 21:46 zu deaktivieren / zu aktivieren zwei Beispiele mit at:

<pre>
define a13 at 21:46 set CamCP1,CamFL,CamHE1,CamTER disable (enable)
define a14 at 21:46 set Cam.* disable (enable)
</pre>

Etwas komfortabler gelingt das Schalten aller Kameras über einen Dummy.
Zunächst wird der Dummy angelegt:

<pre>
define allcams dummy
attr allcams eventMap on:enable off:disable
attr allcams room Cams
attr allcams webCmd enable:disable
</pre>

Durch Verknüpfung mit zwei angelegten notify, jeweils ein notify für "enable" und "disable", kann man durch Schalten des Dummys auf "enable" bzw. "disable" alle Kameras auf einmal aktivieren bzw. deaktivieren.

<pre>
define all_cams_disable notify allcams:.*off set CamCP1,CamFL,CamHE1,CamTER disable
attr all_cams_disable room Cams

define all_cams_enable notify allcams:on set CamCP1,CamFL,CamHE1,CamTER enable
attr all_cams_enable room Cams
</pre>

 
=== set <name> expmode [day] [night] [auto] ===

Mit diesem Befehl kann der Belichtungsmodus der Kameras gesetzt werden. Dadurch wird z.B. das Verhalten der Kamera-LED's entsprechend gesteuert. Die erfolgreiche Umschaltung wird durch das Reading CamExposureMode ("get ... caminfoall") reportet.

'''Hinweis:''' Die erfolgreiche Ausführung dieser Funktion ist davon abhängig ob die SVS diese Funktionalität der Kamera unterstützt. Ist in SVS -> IP-Kamera -> Optimierung -> Belichtungsmodus das Feld für den Tag/Nachtmodus grau hinterlegt, ist nicht von einer lauffähigen Unterstützung dieser Funktion auszugehen.

 
=== set <name> motdetsc [camera] [SVS] [disable] (geändert ab Rev 11284) ===

Der Befehl "motdetsc" (steht für "motion detection source") schaltet die Bewegungserkennung in den gewünschten Modus.
Wird die Bewegungserkennung durch die Kamera / SVS ohne weitere Optionen eingestellt, werden die momentan gültigen Bewegungserkennungsparameter der Kamera / SVS beibehalten.
Die erfolgreiche Ausführung der Operation lässt sich u.a. anhand des Status von SVS -> IP-Kamera -> Ereigniserkennung -> Bewegung nachvollziehen.

Für die Bewegungserkennung durch SVS bzw. durch Kamera können weitere Optionen angegeben werden. Die verfügbaren Optionen bezüglich der Bewegungserkennung durch SVS sind "Empfindlichkeit" und "Schwellwert".

<pre>
set <name> motdetsc SVS [Empfindlichkeit] [Schwellwert] # Befehlsmuster
set <name> motdetsc SVS 91 30 # setzt die Empfindlichkeit auf 91 und den Schwellwert auf 30
set <name> motdetsc SVS 0 40 # behält gesetzten Wert für Empfindlichkeit bei, setzt Schwellwert auf 40
set <name> motdetsc SVS 15 # setzt die Empfindlichkeit auf 15, Schwellwert bleibt unverändert
</pre>

Wird die Bewegungserkennung durch die Kamera genutzt, stehen die Optionen "Empfindlichkeit", "Objektgröße" und "Prozentsatz für Auslösung" zur Verfügung.

<pre>
set <name> motdetsc camera [Empfindlichkeit] [Schwellwert] [Prozentsatz] # Befehlsmuster
set <name> motdetsc camera 89 0 20 # setzt die Empfindlichkeit auf 89, Prozentsatz auf 20
set <name> motdetsc camera 90 40 10 # setzt Empfindlichkeit auf 90, Schwellwert auf 40,
Prozentsatz auf 10
set <name> motdetsc camera 30 # setzt die Empfindlichkeit auf 30, andere Werte bleiben
unverändert
</pre>

Es ist immer die Reihenfolge der Optionswerte zu beachten. Nicht gewünschte Optionen sind mit "0" zu besetzen sofern danach Optionen folgen deren Werte verändert werden sollen (siehe Beispiele oben). Der Zahlenwert der Optionen beträgt 1 - 99 (außer Sonderfall "0").

Die jeweils verfügbaren Optionen unterliegen der Funktion der Kamera und der Unterstützung durch die SVS. Es können jeweils nur die Optionen genutzt werden die in SVS -> Kamera bearbeiten -> Ereigniserkennung zur Verfügung stehen. Weitere Infos sind der Online-Hilfe zur SVS zu entnehmen.

Über den Befehl "get ... caminfoall" wird auch das Reading "CamMotDetSc" aktualisiert welches die gegenwärtige Einstellung der Bewegungserkennung dokumentiert. Es werden nur die Parameter und Parameterwerte angezeigt, welche die SVS aktiv unterstützt. Die Kamera selbst kann weiterführende Einstellmöglichkeiten besitzen.

Beispiel:

<pre>
CamMotDetSc SVS, sensitivity: 76, threshold: 55
</pre>

 

=== set <name> goPreset <Preset> ===

Mit diesem Kommando können PTZ-Kameras in eine vordefininierte Position bewegt werden. 
Die Preset-Positionen müssen dazu zunächst in der Synology Surveillance Station angelegt worden sein. Das geschieht in der PTZ-Steuerung im IP-Kamera Setup.
Die Presets werden über das Kommando "set <name> getinfo" eingelesen (geschieht bei restart von FHEM automatisch). Der Einlesevorgang kann durch ein Kamerapolling
regelmäßig wiederholt werden. Ein langes Pollingintervall ist in diesem Fall empfehlenswert da die Presetpositionen sich nur im Fall der Neuanlage bzw. Änderung verändern werden.
 

Hier ein Beispiel einer PTZ-Steuerung in Abhängigkeit eines IR-Melder Events:

<pre>
define CamFL.Preset.Wandschrank notify MelderTER:on.* set CamFL goPreset Wandschrank, ;; define CamFL.Preset.record
at +00:00:10 set CamFL on 5 ;;;; define s3 at +*{3}00:00:05 set CamFL snap ;; define CamFL.Preset.back at +00:00:30 set CamFL goPreset Home
</pre>

Funktionsweise: 
Der IR-Melder "MelderTER" registriert eine Bewegung. Daraufhin wird die Kamera CamFL in die Preset-Position "Wandschrank" gebracht. Eine Aufnahme mit Dauer von 5 Sekunden startet 10 Sekunden
später. Da die Voraufnahmezeit der Kamera 10s beträgt (vgl. Reading "CamPreRecTime"), startet die effektive Aufnahme wenn der Kameraschwenk beginnt. 
Mit dem Start der Aufnahme werden drei Schnappschüsse im Abstand von 5 Sekunden angefertigt. 
Nach einer Zeit von 30 Sekunden fährt die Kamera wieder zurück in die "Home"-Position. 

Ein Auszug aus dem Log verdeutlicht den Ablauf:

<pre>
2016.02.04 15:02:14 2: CamFL - Camera Flur_Vorderhaus has moved to position "Wandschrank"
2016.02.04 15:02:24 2: CamFL - Camera Flur_Vorderhaus Recording with Recordtime 5s started
2016.02.04 15:02:29 2: CamFL - Snapshot of Camera Flur_Vorderhaus has been done successfully
2016.02.04 15:02:30 2: CamFL - Camera Flur_Vorderhaus Recording stopped
2016.02.04 15:02:34 2: CamFL - Snapshot of Camera Flur_Vorderhaus has been done successfully
2016.02.04 15:02:39 2: CamFL - Snapshot of Camera Flur_Vorderhaus has been done successfully
2016.02.04 15:02:44 2: CamFL - Camera Flur_Vorderhaus has moved to position "Home"
</pre>

 
=== set <name> runPatrol <Patrolname> ===

Dieses Kommando startet die vordefinierterte Überwachungstour einer PTZ-Kamera. 
Die Überwachungstouren müssen dazu zunächst in der Synology Surveillance Station angelegt worden sein. Das geschieht in der PTZ-Steuerung im IP-Kamera Setup -> PTZ-Steuerung -> Überwachung.

Die Überwachungstouren (Patrols) werden über das Kommando "get <name> caminfoall" eingelesen, welches beim Restart von FHEM automatisch abgearbeitet wird. Der Einlesevorgang kann durch ein Kamerapolling regelmäßig wiederholt werden. Ein langes Pollingintervall ist in diesem Fall empfehlenswert, da sich die Überwachungstouren nur im Fall der Neuanlage bzw. Änderung verändern werden.

Nähere Informationen zur Anlage von Überwachungstouren sind in der Hilfe zur Surveillance Station enthalten.

 

=== set <name> goAbsPTZ [ X Y | up | down | left | right ] ===

Mit diesem Kommando wird eine PTZ-Kamera in Richtung einer wählbaren absoluten X/Y-Koordinate bewegt, oder zur maximalen Absolutposition in Richtung up/down/left/right.
Die Option ist nur für Kameras verfügbar die das Reading "CapPTZAbs=true" (die Fähigkeit für PTZAbs-Aktionen) besitzen. Die Eigenschaften der Kamera kann mit "get <name> caminfoall" abgefragt werden.
 

Beispiel für Ansteuerung absoluter X/Y-Koordinaten: 

<pre>
set <name> goAbsPTZ 120 450
</pre>

Dieses Beispiel bewegt die Kameralinse in die Position X=120 und Y=450. 
Der Wertebereich ist dabei:

<pre>
X = 0 - 640 (0 - 319 bewegt nach links, 321 - 640 bewegt nach rechts, 320 bewegt die Linse nicht)
Y = 0 - 480 (0 - 239 bewegt nach unten, 241 - 480 bewegt nach oben, 240 bewegt die Linse nicht)
</pre>

Die Linse kann damit in kleinsten bis sehr großen Schritten in die gewünschte Richtung bewegt werden. Dieser Vorgang muß ggf. mehrfach wiederholt werden um die Kameralinse in die gewünschte Position zu bringen. 

Soll die Bewegung mit der maximalen Schrittweite erfolgen, kann zur Vereinfachung der Befehl:

<pre>
set <name> goAbsPTZ up [down ] [left] [right]
</pre>

verwendet werden. Die Optik wird in diesem Fall mit der größt möglichen Schrittweite zur Absolutposition in der angegebenen Richtung bewegt. Auch in diesem Fall muß der Vorgang ggf. mehrfach wiederholt werden um die Kameralinse in die gewünschte Position zu bringen.

=== set <name> move [ up | down | left | right | dir_X ] [Sekunden] ===

Mit diesem Kommando wird eine kontinuierliche Bewegung der PTZ-Kamera gestartet. Neben den vier Grundrichtungen up/down/left/right stehen auch Zwischenwinkelmaße "dir_X" zur Verfügung. Die Feinheit dieser Graduierung ist von der Kamera abhängig und kann dem Reading "CapPTZDirections" entnommen werden.

Das Bogenmaß von 360 Grad teilt sich durch den Wert von "CapPTZDirections" und beschreibt die Bewegungsrichtungen beginnend mit "0=rechts" entgegen dem Uhrzeigersinn. D.h. bei einer Kamera mit "CapPTZDirections = 8" bedeutet dir_0 = rechts, dir_2 = oben, dir_4 = links, dir_6 = unten bzw. dir_1, dir_3, dir_5 und dir_7 die entsprechenden Zwischenrichtungen. Die möglichen Bewegungsrichtungen bei Kameras mit "CapPTZDirections = 32" sind dementsprechend kleinteliger.

Im Gegensatz zum "set <name> goAbsPTZ"-Befehl startet der Befehl "set <name> move" eine kontinuierliche Bewegung bis ein Stop-Kommando empfangen wird. Das Stop-Kommando wird nach Ablauf der optional anzugebenden Zeit [Sekunden] ausgelöst. Wird diese Laufzeit nicht angegeben, wird implizit Sekunde = 1 gesetzt.

Beispiele:

<pre>
set <name> move up 0.5 : bewegt die Linse 0,5 Sekunden (zzgl. Prozesszeit) nach oben (zzgl. Prozesszeit)
set <name> move dir_1 1.5 : bewegt die Linse 1,5 Sekunden (zzgl. Prozesszeit) nach rechts-oben
set <name> move dir_20 0.7 : bewegt die Linse 1,5 Sekunden (zzgl. Prozesszeit) nach links-unten bei "CapPTZDirections = 32"
</pre>

 
=== set <name> runView [ image | lastrec | lastrec_open | link | link_open <room>] ===

Mit "image, link, link_open" Es wird ein Livestream (mjpeg-Stream) der Kamera, entweder als eingebettetes Image oder als generierter Link, gestartet.
Der Zugriff auf die letzte Aufnahme einer Kamera kann über die Zusätze "lastrec" bzw. "lastrec_open" erfolgen.

'''Beispiele:'''

<pre>
attr <name> htmlattr target=_blank width="500" height="375"
attr <name> htmlattr target=_blank width=500,height=375
attr <name> htmlattr width=700,height=525,top=200,left=300
</pre>

Das Verhalten des Livestreams im FHEMWEB kann durch Angaben im Attribut "htmlattr" beeinflusst werden.
Mit diesen Attributwerten öffnet der Link als weiteres Fenster/Browsertab. Wird der Stream als Image gestartet, ändert sich die Größe entsprechend der Angaben von Width und Height.
Das Kommando "set <name> runView link_open" startet den Livestreamlink sofort in einem neuen Browsertab (longpoll=1 muß für WEB gesetzt sein).
Dabei wird für jede aktive FHEM-Session eine Fensteröffnung initiiert. Soll dieses Verhalten geändert werden, kann "set <name> runView link_open <room>"
verwendet werden um das Öffnen des Browserwindows in einem beliebigen, in einer FHEM-Session angezeigten Raum <room>, zu initiieren. 

Das gesetzte Attribut "livestreamprefix" überschreibt im Reading "LiveStreamUrl" die Angaben für Protokoll, Servername und Port. Damit kann z.B. die LiveStreamUrl für den Versand und externen Zugriff auf die SVS modifiziert werden.

'''Beispiel:'''

<pre>
attr <name> livestreamprefix https://<Servername>:<Port>
</pre>

Der Livestream wird über das Kommando "set <name> stopView" wieder beendet.

 

=== set <name> extevent [ 1-10 ] ===

Dieses Kommando triggert ein externes Ereignis (1-10) in der SVS. Die Aktionen, die dieses Ereignis auslöst, sind zuvor in dem Aktionsregeleditor der SVS einzustellen. Es stehen die Ereignisse 1-10 zur Verfügung. In der Banchrichtigungs-App der SVS können auch Email, SMS oder Mobil (DS-Cam) Nachrichten ausgegeben werden wenn ein externes Ereignis ausgelöst wurde. Nähere Informationen dazu sind in der Hilfe zum Aktionsregeleditor zu finden. Der verwendete User benötigt Admin-Rechte in einer DSM-Session.

 

== Get ==

Mit SSCam können die Eigenschaften der Kameras aus der Surveillance Station abgefragt werden. Dazu steht der Befehl zur Verfügung:

<pre>
get <name> caminfoall
get <name> eventlist
get <name> stmUrlPath
get <name> svsinfo
get <name> snapfileinfo
</pre>

Mit dem Befehl "get <name> caminfoall" werden abhängig von der Art der Kamera (z.B. Fix- oder PTZ-Kamera) die verfügbaren Eigenschaften ermittelt und als Readings zur Verfügung gestellt.
So wird zum Beispiel das Reading "Availability" auf "disconnected" gesetzt falls die Kamera von der Surveillance Station getrennt wird und kann für weitere Verarbeitungen genutzt werden.
Durch "get <name> eventlist" wird das Reading "CamEventNum" aktualisiert, welches die Gesamtanzahl der registrierten Kameraevents enthält.
Mit "get <name> snapfileinfo" wird der Filename des letzten Schnapschusses ermittelt. Der Befehl wird implizit mit "get <name> snap" ausgeführt.

Der Befehl "get <name> svsinfo" ist eigentlich nicht von der Kamera abhängig, sondern ermittelt vielmehr allgemeine Informationen zur installierten SVS-Version und andere Eigenschaften.
Die Funktionen "caminfoall" und "svsinfo" werden einmalig automatisch beim Start von FHEM ausgeführt um steuerungsrelevante Informationen zu sammeln.
Es ist darauf zu achten dass vorher die Credentials gespeichert wurden !

'''get <name> stmUrlPath'''

Mit diesem Kommando wird der aktuelle Streamkey der Kamera abgerufen und das Reading mit dem Key-Wert gefüllt. Dieser Streamkey kann verwendet werden um eigene Aufrufe eines Livestreams aufzubauen (siehe Beispiel). Wenn das Attribut "showStmInfoFull" gesetzt ist, werden zusaätzliche Stream-Informationen wie "StmKeyUnicst", "StmKeymjpegHttp" ausgegeben. Diese Readings enthalten die gültigen Stream-Pfade zu einem Livestream und können z.B. versendet und von einer entsprechenden Anwendung ohne session Id geöffnet werden. Wenn das Attribut "livestreamprefix" (Format: "http(s)://<hostname><port>) gesetzt ist, wird der Servername und Port überschrieben soweit es sinnvoll ist. Wird Polling der Kameraeigenschaften genutzt, wird die stmUrlPath-Funktion automatisch mit ausgeführt.

Beispiel für den Aufbau eines Http-Calls zu einem Livestream mit StmKey:

<pre>
http(s)://<hostname><port>/webapi/entry.cgi?api=SYNO.SurveillanceStation.VideoStreaming&version=1&method=Stream&format=mjpeg&cameraId=5StmKey="31fd87279976d89bb98409728cced890"
</pre>

cameraId (INTERNAL), StmKey müssen durch gültige Werte ersetzt werden.

'''Hinweis:'''

Falls der Stream-Aufruf versendet und von extern genutzt wird sowie hostname / port durch gültige Werte ersetzt und die Routerports entsprechend geöffnet werden, ist darauf zu achten dass diese sensiblen Daten nicht durch unauthorisierte Personen für den Zugriff genutzt werden können !

'''Polling der Kameraeigenschaften:''' 
Die Abfrage der Kameraeigenschaften erfolgt automatisch, wenn das Attribut "pollcaminfoall" (siehe Attribute) mit einem Wert > 10 gesetzt wird. Per Default ist das Attribut "pollcaminfoall" nicht gesetzt und das automatische Polling nicht aktiv. Der Wert dieses Attributes legt das Intervall der Abfrage in Sekunden fest. Ist das Attribut nicht gesetzt oder < 10 wird kein automatisches Polling gestartet bzw. gestoppt wenn vorher der Wert > 10 gesetzt war.

Das Attribut "pollcaminfoall" wird durch einen Watchdog-Timer überwacht. Änderungen des Attributwertes werden alle 90 Sekunden ausgewertet und entsprechend umgesetzt. Eine Änderung des Pollingstatus / Pollingintervalls wird im FHEM-Logfile protokolliert. Diese Protokollierung kann durch Setzen des Attributes "pollnologging" abgeschaltet werden. Dadurch kann ein unnötiges Anwachsen des Logs vermieden werden. Ab verbose=4 wird allerdings trotz gesetzten "pollnologging"-Attribut ein Log des Pollings zu Analysezwecken aktiviert.

Wird FHEM neu gestartet, wird bei aktivierten Polling der ersten Datenabruf innerhalb 60s nach dem Start ausgeführt.

Der Status des automatischen Pollings wird durch das Reading "PollState" signalisiert:

<pre>
PollState = Active - automatisches Polling wird mit Intervall entsprechend <pollcaminfoall> ausgeführt
PollState = Inactive - automatisches Polling wird nicht ausgeführt
</pre>

Die Bedeutung der Readingwerte ist unter Readings beschrieben.

'''Hinweise:'''

Wird Polling eingesetzt, sollte das Intervall nur so kurz wie benötigt eingestellt werden da die ermittelten Werte überwiegend statisch sind.
Das eingestellte Intervall sollte nicht kleiner sein als die Summe aller HTTP-Verarbeitungszeiten. Pro Pollingaufruf und Kamera werden ca. 10 - 20 Http-Calls gegen die Surveillance Station abgesetzt.

Bei einem eingestellten HTTP-Timeout (siehe Attribut) "httptimeout") von 4 Sekunden kann die theoretische Verarbeitungszeit nicht höher als 80 Sekunden betragen.
In dem Beispiel sollte man das Pollingintervall mit einem Sicherheitszuschlag auf nicht weniger 160 Sekunden setzen.
Ein praktikabler Richtwert könnte zwischen 600 - 1800 (s) liegen.

Sind mehrere Kameras in SSCam definiert, sollte "pollcaminfoall" nicht bei allen Kameras auf exakt den gleichen Wert gesetzt werden um Verarbeitungsengpässe und dadurch versursachte potentielle Fehlerquellen bei der Abfrage der Synology Surveillance Station zu vermeiden.
Ein geringfügiger Unterschied zwischen den Pollingintervallen der definierten Kameras von z.B. 1s kann bereits als ausreichend angesehen werden.

 

== Readings ==

Über den Pollingmechanismus bzw. durch Abfrage mit "Get" werden Readings bereitgestellt, deren Bedeutung in der nachfolgenden Tabelle dargestellt sind. Die übermittelten Readings können in Abhängigkeit des Kameratyps variieren.

<pre>
* Availability - Verfügbarkeit der Kamera (disabled, enabled, disconnected, other)
* CamEventNum - liefert die Gesamtanzahl der in SVS registrierten Events der Kamera
* CamExposureControl - zeigt den aktuell eingestellten Typ der Belichtungssteuerung
* CamExposureMode - aktueller Belichtungsmodus (Day, Night, Auto, Schedule, Unknown)
* CamIP - IP-Adresse der Kamera
* CamLiveMode - Quelle für Live-Ansicht (DS, Camera)
* CamModel - Kameramodell
* CamPort - IP-Port der Kamera
* CamPreRecTime - Dauer der der Voraufzeichnung in Sekunden (Einstellung in SVS)
* CamRecShare - gemeinsamer Ordner auf der DS für Aufnahmen
* CamRecVolume - Volume auf der DS für Aufnahmen
* CamVendor - Kamerahersteller Bezeichnung
* CamVideoFlip - Ist das Video gedreht </td></tr>
* CamVideoMirror - Ist das Video gespiegelt </td></tr>
* CapAudioOut - Fähigkeit der Kamera zur Audioausgabe über Surveillance Station (false/true)
* CapChangeSpeed - Fähigkeit der Kamera verschiedene Bewegungsgeschwindigkeiten auszuführen
* CapPTZAbs - Fähigkeit der Kamera für absolute PTZ-Aktionen
* CapPTZAutoFocus - Fähigkeit der Kamera für Autofokus Aktionen
* CapPTZDirections - die verfügbaren PTZ-Richtungen der Kamera
* CapPTZFocus - Art der Kameraunterstützung für Fokussierung
* CapPTZHome - Unterstützung der Kamera für Home-Position
* CapPTZIris - Unterstützung der Kamera für Iris-Aktion
* CapPTZPan - Unterstützung der Kamera für Pan-Aktion
* CapPTZTilt - Unterstützung der Kamera für Tilt-Aktion
* CapPTZZoom - Unterstützung der Kamera für Zoom-Aktion
* DeviceType - Kameratyp (Camera, Video_Server, PTZ, Fisheye)
* Error - Meldungstext des letzten Fehlers
* Errorcode - Fehlercode des letzten Fehlers
* LastSnapFilename - der Filename des letzten Schnapschusses
* LastSnapId - die ID des letzten Schnapschusses
* LastUpdateTime - Datum / Zeit der letzten Aktualisierung durch "caminfoall"
* LiveStreamUrl - die LiveStream-Url wenn der Stream gestartet ist. (Attribut "showStmInfoFull" muss gesetzt sein)
* Patrols - in Surveillance Station voreingestellte Überwachungstouren (bei PTZ-Kameras)
* PollState - zeigt den Status des automatischen Pollings an
* Presets - in Surveillance Station voreingestellte Positionen (bei PTZ-Kameras)
* Record - Aufnahme läuft = Start, keine Aufnahme = Stop
* StmKey - aktueller StreamKey. Kann zum öffnen eines Livestreams ohne Session Id genutzt werden.
* StmKeyUnicst - Uni-cast Stream Pfad der Kamera. ((Attribut "showStmInfoFull" muss gesetzt sein)
* StmKeymjpegHttp - Mjpeg Stream Pfad (über http) der Kamera. (Attribut "showStmInfoFull" muss gesetzt sein)
* SVScustomPortHttp - benutzerdefinierter Port der Surveillance Station (HTTP) im DSM-Anwendungsportal (get mit "svsinfo")
* SVScustomPortHttps - benutzerdefinierter Port der Surveillance Station (HTTPS) im DSM-Anwendungsportal (get mit "svsinfo")
* SVSlicenseNumber - die Anzahl der installierten Kameralizenzen (get mit "svsinfo")
* SVSuserPriv - die effektiven Rechte des verwendeten Users nach dem Login (get mit "svsinfo")
* SVSversion - die Paketversion der installierten Surveillance Station (get mit "svsinfo")
* UsedSpaceMB - durch Aufnahmen der Kamera belegter Plattenplatz auf dem Volume
</pre>

 

== Attribute ==

* '''debugactivetoken''' - wenn gesetzt wird der Status des Active-Tokens gelogged - nur für Debuggung, nicht im normalen Betrieb benutzen

* '''httptimeout''' - Timeout-Wert für HTTP-Aufrufe zur Synology Surveillance Station, Default: 4 Sekunden (wenn httptimeout = "0" oder nicht gesetzt)

* '''htmlattr''' - ergänzende Angaben zur Livestream-Url um das Verhalten wie Bildgröße zu beeinflussen

* '''livestreamprefix''' - überschreibt die Angaben zu Protokoll, Servernamen und Port zur Weiterverwendung der Livestreamadresse als z.B. externer Link. Die Angabe muss in der Form "http(s)://<servername>:<port>" erfolgen.

* '''noQuotesForSID''' - dieses Attribut kann in bestimmten Fällen die Fehlermeldung "402 - permission denied" vermeiden und ein login ermöglichen. (normalerweise nicht zu setzen)

* '''pollcaminfoall''' - Intervall der automatischen Eigenschaftsabfrage (Polling) einer Kamera (kleiner 10: kein Polling, größer 10: Polling mit Intervall)

* '''pollnologging''' - 0 bzw. nicht gesetzt = Logging Gerätepolling aktiv (default), 1 = Logging Gerätepolling inaktiv

* '''rectime''' - festgelegte Aufnahmezeit wenn eine Aufnahme gestartet wird. Mit rectime = 0 wird eine Endlosaufnahme gestartet. Ist "rectime" nicht gesetzt, wird der Defaultwert von 15s verwendet.

* '''session''' - Auswahl der Login-Session. Nicht gesetzt oder "DSM" -> session wird mit DSM aufgebaut (Standard). "SurveillanceStation" -> Session-Aufbau erfolgt mit SVS

* '''simu_SVSversion''' - simuliert eine andere SVS-Version. NUR FÜR DEBUGGING, nicht im normalen Betrieb zu nutzen !

* '''showStmInfoFull''' - zusaätzliche Streaminformationen wie LiveStreamUrl, StmKeyUnicst, StmKeymjpegHttp werden ausgegeben

* '''verbose'''
<pre>
Es werden verschiedene Verbose-Level unterstützt.
Dies sind im Einzelnen:

0 - Start/Stop-Ereignisse werden geloggt
1 - Fehlermeldungen werden geloggt
2 - Meldungen über wichtige Ereignisse oder Alarme
3 - gesendete Kommandos werden geloggt
4 - gesendete und empfangene Daten werden geloggt
5 - alle Ausgaben zur Fehleranalyse werden geloggt. ACHTUNG: unter Umständen werden sehr viele Daten in das Logfile geschrieben!
</pre>

weitere Attribute:

* [http://fhem.de/commandref_DE.html#readingFnAttributes readingFnAttributes]

 

== Das Modul bzw. eine Gerätedefinition deaktivieren ==

Mit dem Attribut "disable" kann das Modul bzw. eine Gerätedefinition deaktiviert werden. Im Gegensatz zum Befehl "set ... disable" wird nicht die Kamera an sich deaktiviert, sondern lediglich das Gerätemodul. In diesem Fall werden keine Funktionen mehr ausgeführt.
Wird das Modul deaktiviert, werden die folgenden Readings gesetzt:

<pre>
state: inactive
Availability: ???
PollState: Inactive
</pre>

Ist für eine Kamera Polling aktiviert, wird diese Aktivität abgeschaltet. Nach Reaktivierung des Gerätemoduls wird das Polling automatisch wieder fortgesetzt.

 

== Lösungsbeispiele und Ansätze für verschiedene Aufgabenstellungen ==

=== Eine Übersicht mit Hilfe von readingsGroup ===

Mit den umfangreichen Möglichkeiten des Moduls [[readingsGroup]] kann ein FHEM-Widget nach eigenen Vorstellungen erstellt werden. Hierbei ist es möglich sowohl einen Überblick über die Status der Kameras zu erhalten als auch Steuerungsaktivitäten vorzusehen. Das nachfolgende Beipiel soll als Anregung dafür dienen. Weitere Informationen unter der [http://fhem.de/commandref.html#readingsGroup commandref] zu readingsGroup.

'''Hinweis:'''
Die folgenden Beispiele enthalten keine Maskierungen oder Verdopplungen für ; und Zeilenende, sondern sind so angegeben, wie sie im Web Interface im Befehls-Eingabefeld, nach Klick auf DEF und im Attribut-Eingabefeld eingegeben werden. Mehrere Leerzeichen innerhalb von < > sind als <code><&nbsp;&nbsp;&nbsp;></code> zu kodieren.

{| class="wikitable"
! Definition !! Erläuterungen
|-
| colspan=2 | [[Bild:RgSSCam.jpg|thumb|500px|links|Kamerastatus und Steuerung]]
|-
| style="width:50%" |<code>define Cams_All_States readingsGroup <%it_camera>,<Verfügbar>,< >,<Status>,< >,<Erkennung>,< >,<letzte Aufnahme>,< >,<bel. Platz (MB)>,< >,<letzte Aktualisierung>,< >,<Modul Deaktivierung>,< >,<Image> TYPE=SSCam:Availability,
<&nbsp;&nbsp;&nbsp;>,state,<&nbsp;&nbsp;&nbsp;>,CamMotDetSc,<&nbsp;&nbsp;&nbsp;>,CamLastRecTime,<&nbsp;&nbsp;&nbsp;>,UsedSpaceMB,
<&nbsp;&nbsp;&nbsp;>,LastUpdateTime,<&nbsp;&nbsp;&nbsp;>,?!disable,<&nbsp;&nbsp;&nbsp;>,<%Start>,<%Stop></code>
| ReadingsGoup anlegen.
|-
| <code>attr Cams_All_States valueIcon {'Availability.enabled' => 'remotecontrol/black_btn_GREEN',
'Availability.disabled' => 'remotecontrol/black_btn_RED',
'state.inactive' => 'StandBy',
'state' => '%devStateIcon'}</code>
| In Abhängigkeit vom Wert der Kameraverfügbarkeit und des state-Readings entsprechende Icons anzeigen. Wird das Modul deaktiviert, wird ein Standby-Icon angezeigt unabhängig davon ob in der Kameradefinition ein devStateIcon hinterlegt wurde.
|-
| <code>attr Cams_All_States valueStyle {if($READING eq "Availability" && $VALUE eq "enabled"){ ' style="color:green" ' }
elsif( $READING eq "Availability" && $VALUE eq "disabled"){ ' style="color:red" ' }
elsif( $READING eq "CamMotDetSc" && $VALUE =~ /SVS.*/ ){ ' style="color:orange" ' }
elsif( $READING eq "CamMotDetSc" && $VALUE eq "disabled"){ ' style="color:LimeGreen" ' }
elsif( $READING eq "CamMotDetSc" && $VALUE =~ /Cam.*/ ){ ' style="color:SandyBrown" ' }}</code>
| Farbgestaltung der Texte in Anhängigkeit der Werte setzen.
|-
| <code>attr Cams_All_States valueFormat {($READING eq "CamMotDetSc" && $VALUE eq "disabled") ? "external" : $VALUE}</code>
| Wenn die Quelle der Bewegungserkennung auf "disabled" gestellt wurde, soll "external" in der Übersicht angezeigt werden weil die Bewegungserkennung in dem Fall durch IR-Melder durchgeführt wird.
|-
| <code>attr Cams_All_States valueColumns { 'Image' => 'colspan="2"'}</code>
| Die Überschrift "Image" soll sich über die letzten zwei Spalten strecken. Es gilt sowohl für "Start" und "Stop" .
|-
| <code>attr Cams_All_States nameStyle style="color:black;font-weight:bold"</code>
| Die Überschriften sollen schwarz und fett sein.
|-
| <code>attr Cams_All_States commands { 'Availability.enabled' => 'set $DEVICE disable',
'Availability.disabled' => 'set $DEVICE enable',
'Cams_All_States.Start' => 'set %DEVICE runView image',
'Cams_All_States.Stop' => 'set %DEVICE stopView',
disable => "disable:"}</code>
| Es sollen Kommandos bestimmten Readings / Werten unterlegt werden. Zum Beispiel kann die Kamera mit Klick auf das Availability-Icon disabled werden wenn der Readingswert "enabled" ist. Der Livestream kann mit "Start" in der letzten Spalte gestartet, oder das Modul über eine Auswahl in der Drop-Down-Liste unterhalb von "Modul Deaktivierung" deaktiviert/aktiviert werden.
|-
| <code>attr Cams_All_States cellStyle { "c:0" => 'style="text-align:left;color:green;font-weight:normal"',
"c:5" => 'style="text-align:center;color:green;font-weight:normal"',
"c:9" => 'style="text-align:center;font-weight:normal"'}</code>
| Formatierung bestimmter Spalten (0,5,9).
|-
| <code>attr Cams_All_States alias Status aller Kameras</code>
| Alias setzen.
|-
| <code>attr Cams_All_States group Kamerastatus</code>
| Gruppenzugehörigkeit setzen. Wird auch für die Anzeige im Dashboard benutzt.
|}

 

=== Mail mit Snapshot im Anhang und Aufnahmelink versenden (sendemail) ===

Nachfolgendes Beispiel zeigt eine Möglichkeit in Linux mit dem Tool [http://caspian.dotconf.net/menu/Software/SendEmail/ sendemail] eine Mail mit einem Link zu einer Kameraaufnahme und bis zu drei Anhängen zu versenden. Das Tool ist in vielen Repositories erhalten und kann unter Debian (z.B. Ubuntu) installiert werden mittels <code>apt-get install sendemail libio-socket-ssl-perl</code>.
Die Mail wird mit einem DOIF Kommando in Abhängigkeit von einer angefertigten Aufnahme angestoßen.

Zunächst die Mailfunktion in der 99_myUtils als Unterroutinen einfügen. Die Funktion ist nicht blockierend (mit Modul Blocking.pm) ausgeführt. Die "\" dienen nachfolgend nur
zur Kennzeichnung eines Zeilenumbruchs - den Code bitte auf eine Zeile schreiben.

<source lang=perl>
# Am Anfang von 99_myUtils hinzufügen
use Blocking;

##############################################################################
######## DebianMail Mail versenden nonblocking ############
##############################################################################

sub DebianMailnbl {

my $rcpt = shift;
my $subject = shift;
my $text = shift;
my $attach = shift;
my $attach1 = shift;
my $attach2 = shift;
my $hash->{NAME_MAIL} = "Debianmail";
my $name = $hash->{NAME_MAIL};

if ($attach2) {
$hash->{helper}{RUNNING_PID} = BlockingCall("DebianMailnbl_send", $name."|".$rcpt."|".$subject."|".$text."|".$attach." \
|".$attach1."|".$attach2, "", "", "", "");
} elsif ($attach1) {
$hash->{helper}{RUNNING_PID} = BlockingCall("DebianMailnbl_send", $name."|".$rcpt."|".$subject."|".$text."|".$attach."|" \
.$attach1, "", "", "", "");
} else {
$hash->{helper}{RUNNING_PID} = BlockingCall("DebianMailnbl_send", $name."|".$rcpt."|".$subject."|".$text."|".$attach,
"", "", "", "");
}

}

######################################################
######## Mailfunktion nonblocking
######################################################

sub DebianMailnbl_send {
my ($string) = @_;
my ($name, $rcpt, $subject, $text, $attach, $attach1, $attach2) = split("\\|", $string);
my $ret = "";
my $sender = "<Sendername>\@<Domäne>";
my $konto = "<Mailkonto";
my $passwrd = "<Mailkontopasswort>";
my $provider = "<Mailserver>";

if ($attach2) {
$ret .= qx(sendEmail -f '$sender' -t '$rcpt' -u '$subject' -m '$text' -a '$attach' -a '$attach1' -a '$attach2' -s '$provider' \
-xu '$konto' -xp '$passwrd' -o tls=no -o message -charset=utf-8 -o message-content-type=text/plain );
} elsif ($attach1) {
$ret .= qx(sendEmail -f '$sender' -t '$rcpt' -u '$subject' -m '$text' -a '$attach' -a '$attach1' -s '$provider' -xu '$konto' \
-xp '$passwrd' -o tls=no -o message-charset=utf-8 -o message-content-type=text/plain );
} else {
$ret .= qx(sendEmail -f '$sender' -t '$rcpt' -u '$subject' -m '$text' -a '$attach' -s '$provider' -xu '$konto' -xp '$passwrd' \
-o tls=no -o message-charset=utf-8 -o message-content-type=text/plain );
}

# remove CR from return-string
$ret =~ s,[\r\n]*,,g;

Log3 $name, 3, "$name - sendEmail returned: $ret";
}
</source>

Um die TLS Verschlüsselung (ehem. SSL) zu nutzen, dann tls=auto verwenden.

Falls der Body-Text in einem (Android-)Mailer auf dem Handy nicht gezeigt wird, kann evtl. der Parameter '''-o message-content-type=html''' helfen.

 
==== Versand triggern - Beispiel mit DOIF ====
Der Mailversand wird in dem Beispiel mit einem DOIF angetriggert:

<pre>
define CamHE1.email DOIF ([CamHE1:"CamLastRec"]) ({DebianMailnbl ('<Empfänger>@<Domäne>','Bewegungsalarm CamHE1','Eine Bewegung wurde an der Haustür registriert.
Aufnahmelink: [CamHE1:VideoFolder]/[CamHE1:CamLastRec]','/media/sf_surveillance/@Snapshot/[CamHE1:LastSnapFilename]')})
</pre>

Wird eine Aufnahme der Kamera CamHE1 beendet, wird integriert der Befehl "get .. eventlist" ausgeführt. Dadurch aktualisiert sich das Reading "CamLastRec".
Dieser Event wird genutzt um eine Mail mit einem Link zur Aufnahme und einem während der Aufnahme angelegten Schnappschuß zu versenden.
Will man einen weiteren Anhang versenden, sähe das DOIF folgendermaßen aus:

<pre>
define CamHE1.email DOIF ([CamHE1:"CamLastRec"]) ({DebianMailnbl ('<Empfänger>@<Domäne>','Bewegungsalarm CamHE1','Eine Bewegung wurde an der Haustür registriert.
Aufnahmelink: [CamHE1:VideoFolder]/[CamHE1:CamLastRec]','/media/sf_surveillance/@Snapshot/[CamHE1:LastSnapFilename]','<weiteres File>')})
</pre>

Dss Reading "VideoFolder" muß, wie in dem Beispiel zu sehen, dem "CamLastRec" vorangestellt werden um den kompletten Pfad zur Aufnahme zu erhalten. Der versendete Link würde somit etwa den folgenden Aufbau haben:

<pre>
/volume1/surveillance/Carport/20160407PM/Carport20160407-221541-1460060141.mp4
</pre>

Wenn in einer Mail nach extern versendet wird, ist ein solcher Link wahrscheinlich über eine Anwendung nicht zugreifbar.
Um den Link dynamisch anzupassen und so den Zugriff von extern über z.B. einen Webserver zu ermöglichen, kann das Attribut "videofolderMap" verwendet werden.

Wird dieses Attribut auf zum Beispiel ...<pre>"http://<Server>:8083/fhem/svs/Carport/"</pre> ...gesetzt, ergibt sich folgender Link der in der Mail versendet wird:

<pre>
http://<Server>:8083/fhem/svs/Carport/20160407PM/Carport20160407-221541-1460060141.mp4
</pre>

In dem obigen Beispiel wird ein FHEM-Webserver verwendet, der zuvor über HTTPSRV (siehe Commandref) angelegt wurde,
WIe der Webserver angelegt werden kann ist [[SSCAM_-_Steuerung_von_Kameras_in_Synology_Surveillance_Station#Einsatz_FHEM_Webserver_zum_Zugriff_auf_Aufnahmen | hier]] beschrieben.

'''Hinweis:'''

Nach dem Snapshot wird implizit die Funktion "get ... snapfileinfo" aufgerufen. Diese Funktion trägt den neuen/letzten Snapfilename in das Reading "LastSnapFilename" ein.
Es ist somit sicherzustellen dass dieses Funktion abgeschlossen ist bevor die Aufnahme per Mail versendet werden soll. Das kann zum Beispiel mit einem Notify auf den Event "<Device>:LastSnapFilename.*" geschehen.
Sollten das Problem auftreten dass alte Snapshots versendet werden, ist aller Wahrscheinlichkeit nach in dem beschriebenen Sachverhalt die Ursache zu finden.

 

==== Versand triggern - Beispiel mit Notify ====

Mit diesem Notify wird das Snapshotfile angehängt und auch ein Link zu dem Snapshot mit eingefügt.

<pre>
define CamHE1.email NOTIFY CamHE1:LastSnapFilename.* {DebianMailnbl ('<Empfänger>@<Domäne>','Bewegungsalarm CamHE1',
'Eine Bewegung wurde an der Haustür registriert. Aufnahmelink: http://<Server>:8083/fhem/snap/'.(ReadingsVal("CamHE1","LastSnapFilename","")),
'/media/sf_surveillance/@Snapshot/'.(ReadingsVal("CamHE1","LastSnapFilename","")))}
</pre>

Um den Link in dieser Form aufrufen zu können ist erst ein HTTPSRV anzulegen mit:

<pre>
define snapweb HTTPSRV snap /media/sf_surveillance/@Snapshot SVS-Snapshots
</pre>

Natürlich muß dabei der Pfad "/media/sf_surveillance/" so angepasst werden dass er dem (gemounteten) SVS-Aufnahmeverzeichnis entspricht.

 

=== Einsatz eines Webservers zum Zugriff auf Aufnahmen ===

==== Nutzung des FHEM-internen HTTPSRV Plug-In ====

Ziel der nachfolgenden Beschreibung ist es, eine Möglichkeit darzustellen, um den FHEM Webserver für den Zugriff auf die Aufnahmen der Synology Surveillance Station zu nutzen.

Folgende Ausgangslage wird für das Beispiel als gegeben angenommen:

* der gemeinsame Ordner der Surveillance Station (normalerweise "surveillance") in der Diskstation ist am FHEM-Server gemountet. Für das Beipiel ist das gemountete Verzeichnis: /media/sf_surveillance
* FHEMWEB ist im Einsatz
* für das Beispiel ist eine Kamera CamHE1 (SVS-Name: Hauseingang) definiert

HTTPSRV ist ein Plug-in für FHEMWEB und stellt den Webserver für den Zugriff zur Verfügung. Diese Möglichkeit ist sicherlich für jene Fälle interessant bei denen der Zugriff über einen Verzeichnisdienst nicht möglich oder nicht gewünscht ist (zum Bespiel von extern).
Es steht auch eine Modul-interne Zugriffsmöglichkeit auf die letzte Aufnahme mit dem Befehl "set CamHE1 runView lastrec (oder lastrec_open)" zur Verfügung.

Der Webserver wird definiert mit:

define svsweb HTTPSRV svs /media/sf_surveillance WebServer SVS-Aufnahmen

Der definierte Webserver sollte nun links im Seitenmenü unter dem Namen "WebServer SVS-Aufnahmen" erscheinen. Ein Klick auf diesen Link sollte nun die Meldung zeigen:

File not found: /media/sf_surveillance/index.html

Die Datei index.html existiert natürlich normalerweise nicht im surveillance-Verzeichnis. Der Inhalt des Verzeichnisses "/media/sf_surveillance", also des surveillance-Stammordners, wird nun mit der Basisadresse ... <pre>http://<FHEM-Server>:8083/fhem/svs/</pre> ...erreicht.

Alle Aufnahmen der Kameras werden in Unterordnern des surveillance-Stammerzeichnisses gespeichert, die den gleichen Namen wie die Kamera in der Surveillance Station haben. Um den Pfad zu dem Aufnahmefile zu spezifizieren, ist die Basisadresse des erstellten Webservers mit dem Unterordner der entsprechenden Kamera zu ergänzen. Mit diesem zusammengesetzten Gesamtpfad ist ebenfalls das Reading "VideoFolder", welches den physikalischen Pfad von Aufnahmen der entsprechenden Kamera beschreibt, zu überschreiben.

Die wird mit dem Attribut "videofolderMap" erreicht. In dem Beispiel wird es gesetzt auf:

<pre>
attr CamHE1 videofolderMap http://<FHEM-Server>:8083/fhem/svs/Hauseingang/
</pre>

Jede Aufnahme der Kamera "Hauseingang" bzw. "CamHE1" wird somit durch die Webadresse ...

<pre>
http://<FHEM-Server>:8083/fhem/svs/Hauseingang/<Inhalt Reading CamLastRec>
</pre>

... erreicht.

Wie eine Mail mit diesem Link versendet werden kann ist [[SSCAM_-_Steuerung_von_Kameras_in_Synology_Surveillance_Station#Mail_mit_Snapshot_im_Anhang_und_Aufnahmelink_versenden_.28sendmail.29 | hier]] beschrieben.

Der komplette in der Mail versendete Aufnahmelink sieht folgendermaßen aus:
<pre>
http://<FHEM-Server>:8083/fhem/svs/Hauseingang//20160408PM/Hauseingang20160408-215150-1460145110.mp4
</pre>

 

==== Nutzung der Webstation auf Synology DS zum Zugriff auf Recordings ====

Da die Benutzung des HTTPSRV für diesen Zweck FHEM belastet bzw. blockiert, hat Martin Fischer im Forum unter:
https://forum.fhem.de/index.php/topic,45671.msg482616.html#msg482616

zwei Möglichkeiten bschrieben wie man den internen Webserver des Synology DS statt dessen verwenden kann (DSM 6).

Darauf aufbauend ist hier folgend die Umsetzung im DSM 5.2 beschrieben.

'''1. schnelle Variante A'''

Die nachfolgende Beschreibung bezieht sich auf DSM 5.2. Es wird ein virtueller Host (test.myds.me) definiert, der auf Port HTTP 8081 hört. Das Dokument-Root soll in dem Beispiel der Ordner "/volume1/web/fhemsvs" sein.

* Nach dem Login als root wechselt man in das web-Verzeichnis mit "cd /volume1/web"
* anlegen des Root-Verzeichnisses für den virtuellen Host und setzen der Berechtigungen:
mkdir fhemsvs
chown http:http fhemsvs
chmod 775 fhemsvs

* Für SVS-Versionen kleiner als 8: Link im Root-Verzeichnis zum SVS-Stammverzeichnis setzen:
ln -s /volume1/surveillance/ /volume1/web/fhemsvs

* Für SVS-Versionen ab 8: Link im Root-Verzeichnis zum SVS-Stammverzeichnis setzen:
ln -s /volume1/\@surveillance/ /volume1/web/fhemsvs

* einen virtuellen Host in Systemsteuerung -> Webdienste -> virtueller Host anlegen. Soll der Host von extern erreichbar sein, muß ebenfalls eine Registrierung des Hostnamens z.B. bei dem kostenfreien DNS-Dienst von Synology erfolgen sowie der verwendete Port im Router freigeschaltet werden.

[[Bild:vHost.PNG|left|thumb|300px|]] Der virtuelle Host ist durch die Angabe des Unterodners (fhemsvs), des Hostnamens (test.myds.me), des Protokolls und des Ports (8081) zu definieren. Die Angaben sind natürlichen den realen Werten anzupassen.

* die Recordings sind nun prinzipiell unter der Adresse erreichbar:
<pre>
http://test.myds.me:8081/surveillance/<Camname>/<Zeitordner>/<Dateiname>
</pre>

* in FHEM ist der Zugangspfad zu dem Aufnahmen zusammengesetzt aus den Readings "VideoFolder" (Original z.B. /volume1/surveillance/Carport) und "CamLastRec". Über das Attribut "videofolderMap" wird "/volume1/surveillance/Carport" nun ersetzt durch <pre>"http://test.myds.me:8081/surveillance/Carport/"</pre>

Der substituierte Aufnahmelink wird nun zu: (ReadingsVal("<camname>","VideoFolder","")).(ReadingsVal("<name>","CamLastRec",""))

* Der Versand des Aufnahmelinks per Mail kann durch ein Notify erfolgen:

define N.CamCP1.Rec.Email notify CamCP1:CamLastRec:.* {DebianMailnbl ('<Mailempfänger>','Bewegungsaufnahme Carport', 'Aufnahmelink: '.(ReadingsVal("CamCP1","VideoFolder","")).(ReadingsVal("CamCP1","CamLastRec",""))) }

Die Funktion DebianMailnbl für den Mailversand ist zuvor in 99_myUtils zu definieren. (siehe [[#Mail_mit_Snapshot_im_Anhang_und_Aufnahmelink_versenden_.28sendmail.29 | Mailversandroutine]] )

* Der Versand des Aufnahmelinks per TelegramBot kann durch folgendes Notify erfolgen:

define N.CamCP1.Rec.TeleBot notify CamCP1:CamLastRec:.* { my $var = (ReadingsVal("CamCP1","VideoFolder","")).(ReadingsVal("CamCP1","CamLastRec","")); fhem ("set teleBot message $var Bewegungsaufnahme beim Carport"); }

Natürlich ist TelegramBot vorab einzurichten. Der Versand erfolgt in dem Beispiel an den defaultPeer.

 

'''2. Variante B'''

(noch für DSM 5.2 zu beschreiben).

 

=== Workaround bei DSM 2-Stufen Verifizierung ===
1. Benutzer in der SVS einrichten, zum Manager machen 
2. Benutzer wird automatisch auch in FHEM eingerichtet, dort zum Admin machen 
3. 2-Stufen Verifizierung ausschalten 
4. Modul / Kamera zum Laufen bringen 
5. Session im Modul auf SVS stellen 
6. Benutzer in der DSM aus der Admin-Gruppe rausnehmen 
7. 2-Stufen Verifizierung einschalten (Option nur für Admins)

HP1000

2016-10-02T16:07:27Z

Motivierte linke Hände: Ein paar mögliche Userreadings ergänzt.

{{Infobox Modul
|ModPurpose=Einbindung einer HP1000 Wetterstation
|ModType=d
|ModForumArea=Heizungssteuerung/Raumklima
|ModFTopic=44022
|ModTechName=50_HP1000.pm
|ModOwner={{Link2FU|1363|Loredo}}
}}
== HP1000 ==
HP1000 ist ein Modul zum Auslesen von HP1000/WH2600 Wetterstationen von renkforce/Froggit, etc.

Funktionsweise des Moduls ist, dass in der Wetterstation eine FHEMWEB Instanz angegeben wird, an die die Wetterstation dann regelmäßig die Daten sendet.
== Konfiguration ==
Die Konfiguration des Moduls erfolgt in drei Schritten:
=== Definition einer Webinstanz für die Wetterstation ===
Zunächst muss auf einem eigenen Port eine neue FHEMWEB-Instanz angelegt werden, z.B. mit dem Namen WEBweather. Dieser muss zwingend der Name weatherstation zugewiesen werden. Dieser ist in der Firmware der Stationen fest codiert.
define WEBweather FHEMWEB 8089 global
attr WEBweather webname weatherstation
=== Definition der Wetterstation ===
Dann wird das Modul noch in Fhem definiert. Die Definition kann mit und ohne Benutzernamen und Passwort erfolgen. Wenn bei der Definition Benutzername und Passwort nicht angegeben werden, werden die von der Wetterstation gesendeten Benutzerdaten von Fhem nicht überprüft. Eine WH2600 Station erfordert im Webinterfache immer die Angabe von Benutzername und Passwort.
Definition mit Benutzername und Passwort:
define Wetterstation HP1000 Benutzer Passwort
Definition ohne Benutzername und Passwort:
define Wetterstation HP1000

=== Eingaben im Webinterface der Station ===
Dann muss der Station eingestellt werden, dass die Wetterinformationen an Fhem geschickt werden sollen. Bei einer WH2600 (Station ohne LCD Display) geschieht das im Webinterface, bei einer HP1000 direkt in den Einstellungen des LCD Displays.
Dazu unter "Weather Network" folgendes eintragen:
<pre>Remote Server => Customized
Server IP/Hostname => <Fhem-Domainname> bzw. <Fhem-IP> (siehe unten)
Server Port => Der Port der neuen Webinstanz in Fhem (im Beispiel oben 8089)
Station ID => selbst gewählter Benutzername
Password => selbst gewähltes Passwort</pre>
Zu '''Server IP/Hostname''': Hier muss entweder der Domainname angegeben werden, unter dem Fhem erreichbar ist (vollständige Domain nicht vergessen!), oder die IP. Wenn in Fhem keine Daten ankommen, ist das hier meist der Knackpunkt. Erfahrungen zeigen, dass teilweise der Domainname nicht vollständig angegeben wurde oder aber der Domainname nicht aufgelöst werden kann (vielleicht gibt es hier Probleme einzelner Stationen, bei der Konfiguration via DHCP den Nameserver-Eintrag richtig umzusetzen). Auch hat die Firmware oft einen Bug der verhindert, dass IP Adressen direkt verwendet werden können. Hier muss dann zwingend auf einen Domainnamen zurückgegriffen werden!
Einfach mal alle Möglichkeiten durchprobieren.

'''Station ID''' und '''Passwort''' müssen hier angegeben werden. Bei der Definition der Station in Fhem kann man diese angeben (dann wird geprüft, ob die berechtigte Station Daten schickt) oder weglassen (dann werden Benutzername und Passwort nicht von Fhem geprüft).

== Tipps, Tricks, Problemlösungen ==
=== FileLog ===
Das Modul definiert bei der Erstellung kein FileLog. Wenn man eines definiert, bietet sich aufgrund der Häufigkeit von Datenübertragungen und damit der Menge an übertragenen Informationen das Loggen nur des T:-Readings an:
define FileLog_WeatherStation FileLog ./log/WeatherStation-%Y.log WeatherStation:T:.*

Alternativ sei auch auf die Verwendung von DbLog verwiesen. Dort kann man mit Hilfe des DbLogInclude Attributs granularer einstellen wie oft ein Wert geloggt werden soll:
attr WeatherStation DbLogInclude windSpeed:300 windGust:300 windChill:300 temperature.*:300 humidity.*:300 luminosity:300 uv:300

Wichtig ist auch, dass für das Logging die richtigen Events ausgelöst werden. Wer die event-on-* Attribute benutzt kann diese in Kombination mit DbLogInclude z.B. so setzen:
attr event-on-update-reading temperature.*,humidity.*,windSpeed,windGust,windChill,luminosity,uv,dewpoint.*,rain.*

=== Falsch angezeigte/zu wenig Readings ===
Abhängig von der Firmwareversion und/oder dem Modell der Station kann es dazu kommen, dass teilweise nicht alle Readings oder die Readings mit den falschen Einheiten (z. B. Wingeschwindigkeit in mph, obwohl km/h konfiguriert wurde) angezeigt werden. In diesem Fall hilft es, im Webinterface der Wetterstation bei der Definition "Weather Network" den "Server Type" auf "JSP" zu stellen.

=== Keine Daten in Fhem ===
Wenn in Fhem keine Daten von der Wetterstation ankommen, liegt das häufig daran, dass FHEM nicht richtig als "Weather Network" konfiguriert wurde. Wenn die '''erforderlichen Eingaben im Webinterface''' (s. o.) der Station nicht helfen, kann man sich zum Testen per telnet mit der Wetterstation verbinden (Benutzername admin, Passwort admin). Mögliche Befehle:
<pre>help
quit
reboot
Usage: passwd
Old Password:
New Password:
Re-enter New Password:
Usage: username <user name>
Usage: ipconfig
Usage: setip <ip addr>
Usage: setmask <netmask>
Usage: setgateway <ip addr>
Usage: setdns <ip addr>
Usage: setmode <mode>
<mode>: 0: SERVER 1: CLIENT
Usage: setsrvport <port>
Usage: setdstport <port>
Usage: dhcpclient <status>
<status>: 0: disable 1: enable
Usage: connectype <protocol>
<protocol>: 0: TCP 1: UDP
Usage: transmitimer <time>
<time>: time in ms
Usage: saveconfig
Usage: accessip <index> <ip addr>
<index>: index of accessible IP
<ip addr>: accessible IP address
Usage: setaccip <mode>
<mode>: 0: disable 1: enable
Usage: setaw <cold start> <authentication fail> <ip changed> <password changed>
<cold start>: 0: Disable 1: Enable
<authentication fail>: 0: Disable 1: Enable
<ip changed>: 0: Disable 1: Enable
<password changed>: 0: Disable 1: Enable
Usage: setdsthn <Host name/IP>
Usage: tftpsrv <ip addr>
Usage: filename <file name>
Usage: dlfirmware
Usage: seteep <HEX RegStartAddr> <HEX Byte 0> <HEX Byte 1>...<HEX Byte N>
Usage: dbgmsg <mode>
<mode>: 0: Disable 1: Enable
Usage: connstatus
Usage: ping xxx.xxx.xxx.xxx
Usage: setRTC <HEX RegStartAddr> <HEX Byte 0> <HEX Byte 1>...<HEX Byte N></pre>
Am besten mit "ipconfig" sich die aktuelle Konfiguration anzeigen lassen. Mit ping kann man Verbindungen z. B. zu Fhem testen.

=== Userreading: Windrichtung als Himmelsrichtung ===
Wer als Reading lieber die Himmelsrichtung des Windes statt einer Gradangabe hätte, kann ein entsprechendes Userreading "windDirLit" erzeugen, das dann die Himmelsrichtung (N, NW, S, etc.) ausgibt. Dazu folgendes Userreading anlegen:

attr Wetterstation userReadings windDirLit:windDir.* { Windrichtung(ReadingsVal('Wetterstation', 'windDir', '0')); }

Und folgenden Code in die 99_myUtils.pm kopieren:

<pre>sub Windrichtung ($) {
my ($Grad) = @_;
my @Richtungen=('N', 'NNO', 'NO', 'ONO', 'O', 'OSO', 'SO', 'SSO', 'S', 'SSW', 'SW', 'WSW', 'W', 'WNW', 'NW', 'NNW', 'N');
return $Richtungen[sprintf('%.0f', $Grad / 22.5)];
}</pre>

=== Userreading: Windstärke in Beaufort ===
Wer gerne ein Reading hätte, um die Windstärke in Beaufort auszugeben, und wer sich die Windstärke normalerweise in km/h anzeigen lässt, kann sich dazu folgendes Userreading anlegen:

attr Wetterstation userReadings windBft:windSpeed.* { sprintf '%.0f', (ReadingsVal('Wetterstation', 'windSpeed', 0) / 3.0096) ** (2/3); }
=== Userreading: Windgeschwindigkeit in m/s ===
Wer sich die Windgeschwindigkeit in km/h anzeigen lässt, aber gerne ein zusätzliches Reading in m/s haben möchte (z. B., um die Windgeschwindigkeit an wetter.com übermitteln zu können mit dem weco-Modul für Fhem), kann sich auch dafür ein zusätzliches Reading "wind_mps" erzeugen:

attr Wetterstation userReadings wind_mps:windSpeed.* { sprintf '%0.2f', ReadingsVal('Wetterstation','windSpeed',0) / 3.6; }

HP1000

2016-10-02T07:09:38Z

Motivierte linke Hände: Nun stimmen auch die Überschriftenhierarchien... :-/

{{Infobox Modul
|ModPurpose=Einbindung einer HP1000 Wetterstation
|ModType=d
|ModForumArea=Heizungssteuerung/Raumklima
|ModFTopic=44022
|ModTechName=50_HP1000.pm
|ModOwner={{Link2FU|1363|Loredo}}
}}
== HP1000 ==
HP1000 ist ein Modul zum Auslesen von HP1000/WH2600 Wetterstationen von renkforce/Froggit, etc.

Funktionsweise des Moduls ist, dass in der Wetterstation eine FHEMWEB Instanz angegeben wird, an die die Wetterstation dann regelmäßig die Daten sendet.
== Konfiguration ==
Die Konfiguration des Moduls erfolgt in drei Schritten:
=== Definition einer Webinstanz für die Wetterstation ===
Zunächst muss auf einem eigenen Port eine neue FHEMWEB-Instanz angelegt werden, z.B. mit dem Namen WEBweather. Dieser muss zwingend der Name weatherstation zugewiesen werden. Dieser ist in der Firmware der Stationen fest codiert.
define WEBweather FHEMWEB 8089 global
attr WEBweather webname weatherstation
=== Definition der Wetterstation ===
Dann wird das Modul noch in Fhem definiert. Die Definition kann mit und ohne Benutzernamen und Passwort erfolgen. Wenn bei der Definition Benutzername und Passwort nicht angegeben werden, werden die von der Wetterstation gesendeten Daten von Fhem nicht überprüft. (Die Station erfordert im Webinterfache immer die Angabe von Benutzername und Passwort!)
Definition mit Benutzername und Passwort:
define Wetterstation HP1000 Benutzer Passwort
Definition ohne Benutzername und Passwort:
define Wetterstation HP1000
=== Eingaben im Webinterface der Station ===
Dann muss der Station in deren Webinterface noch gesagt werden, dass die Wetterinformationen an Fhem geschickt werden. Dazu im Webinterface unter "Weather Network" Folgendes eintragen:
<pre>Remote Server => Customzied
Server IP/Hostname => <Fhem-Domainname> bzw. <Fhem-IP> (s.u.)
Server Port => Der Port der neuen Webinstanz in Fhem (im Beispiel oben 8089)
Station ID => selbstgewählter Benutzername
Password => selbstgewähltes Passwort</pre>
Zu '''Server IP/Hostname''': Hier muss entweder der Domainname angegeben werden, unter dem Fhem erreichbar ist (vollständige Domain nicht vergessen!), oder die IP. Wenn in Fhem keine Daten ankommen, ist das hier meist der Knackpunkt. Erfahrungen zeigen, dass teilweise der Domainname nicht vollständig angegeben wurde oder aber der Domainname nicht aufgelöst werden kann (vielleicht gibt es hier Probleme einzelner Stationen, bei der Konfiguration via DHCP den Nameserver-Eintrag richtig umzusetzen). Einfach mal alle Möglichkeiten durchprobieren.

'''Station ID''' und '''Passwort''' müssen hier angegeben werden. Bei der Definition der Station in Fhem kann man diese angeben (dann wird geprüft, ob die berechtigte Station Daten schickt) oder weglassen (dann werden Benutzername und Passwort nicht von Fhem geprüft).
== Tipps, Tricks, Problemlösungen ==
=== FileLog ===
Das Modul definiert bei der Erstellung kein FileLog. Wenn man eines definiert, bietet sich aufgrund der Häufigkeit von Datenübertragungen und damit der Menge an übertragenen Informationen das Loggen nur des T:-Readings an:
define FileLog_Wetterstation FileLog ./log/Wetterstation-%Y.log Wetterstation:T:.*
=== Mehr Einträge im T:-Reading ===
Das Modul liefert standardmäßig nicht alle vom Außensender verfügbaren Daten auch in der T:-Zeile. Wenn man dort - z. B. zum Loggen - alle Daten haben möchte, kann man die übrigen Daten ergänzen. Dafür editiert man die Datei 50_HP1000.pm und ergänzt Zeilen.
Im Bereich von Zeile 347 suchen:
<pre> $result = "T: " . $webArgs->{outtemp} if ( defined( $webArgs->{outtemp} ) );
$result .= " H: " . $webArgs->{outhumi}
if ( defined( $webArgs->{outhumi} ) );
$result .= " Ti: " . $webArgs->{intemp}
if ( defined( $webArgs->{intemp} ) );
$result .= " Hi: " . $webArgs->{inhumi}
if ( defined( $webArgs->{inhumi} ) );
$result .= " W: " . $webArgs->{windspeed}
if ( defined( $webArgs->{windspeed} ) );
$result .= " R: " . $webArgs->{rainrate}
if ( defined( $webArgs->{rainrate} ) );
$result .= " WD: " . $webArgs->{winddir}
if ( defined( $webArgs->{winddir} ) );
$result .= " D: " . $webArgs->{dewpoint}
if ( defined( $webArgs->{dewpoint} ) );
$result .= " P: " . $webArgs->{relbaro}
if ( defined( $webArgs->{relbaro} ) );</pre>
und dahinter folgende neue Zeilen einfügen:
<pre> $result .= " U: " . $webArgs->{UV}
if ( defined( $webArgs->{UV} ) );
$result .= " L: " . $webArgs->{light}
if ( defined( $webArgs->{light} ) );
$result .= " WC: " . $webArgs->{windchill}
if (defined($webArgs->{windchill}));
$result .= " RD: " . $webArgs->{dailyrain}
if (defined($webArgs->{dailyrain}));
$result .= " RW: " . $webArgs->{weeklyrain}
if (defined($webArgs->{weeklyrain}));
$result .= " RM: ".$webArgs->{monthlyrain}
if (defined($webArgs->{monthlyrain}));
$result .= " RY: ".$webArgs->{yearlyrain}
if (defined($webArgs->{yearlyrain}));
$result .= " WG: ".$webArgs->{windgust}
if (defined($webArgs->{windgust}));</pre>
Um zu verhindern, dass die eigenen Ergänzungen bei einem Update des Moduls überschrieben werden, dann noch 50_HP1000.pm vom automatischen Update ausnehmen:
attr global exclude_from_update 50_HP1000.pm
=== Absturz von Fhem wegen Illegal division by zero ===
Wenn HP1000 Fhem abstürzen lässt mit der Fehlermeldung
<pre>2016.10.01 08:51:00 1: PERL WARNING: Use of uninitialized value in division (/) at ./FHEM/50_HP1000.pm line 383.
Illegal division by zero at ./FHEM/50_HP1000.pm line 383.</pre>
dann hilft es, die mit + markierten Zeilen (natürlich ohne die +-Zeichen selbst!) in 50_HP1000.pm im sub HP1000_GetSum (um Zeile 400) einzufügen:
<pre> if ($avg) {
+ if (@{ $hash->{helper}{history}{$t} } > 0) {
$return = sprintf( "%.1f",
sum( @{ $hash->{helper}{history}{$t} } ) /
@{ $hash->{helper}{history}{$t} } );

Log3 $name, 5, "HP1000 $name: Average for $t: $return";
+ }
}</pre>
=== Falsch angezeigte/zu wenig Readings ===
Abhängig von der Firmwareversion und/oder dem Modell der Station kann es dazu kommen, dass teilweise nicht alle Readings oder die Readings mit den falschen Einheiten (z. B. Wingeschwindigkeit in mph, obwohl km/h konfiguriert wurde) angezeigt werden. In diesem Fall hilft es, im Webinterface der Wetterstation bei der Definition "Weather Network" den "Server Type" auf "JSP" zu stellen.
=== Keine Daten in Fhem ===
Wenn in Fhem keine Daten von der Wetterstation ankommen, liegt das häufig daran, dass FHEM nicht richtig als "Weather Network" konfiguriert wurde. Wenn die '''erforderlichen Eingaben im Webinterface''' (s. o.) der Station nicht helfen, kann man sich zum Testen per telnet mit der Wetterstation verbinden (Benutzername admin, Passwort admin). Mögliche Befehle:
<pre>help
quit
reboot
Usage: passwd
Old Password:
New Password:
Re-enter New Password:
Usage: username <user name>
Usage: ipconfig
Usage: setip <ip addr>
Usage: setmask <netmask>
Usage: setgateway <ip addr>
Usage: setdns <ip addr>
Usage: setmode <mode>
<mode>: 0: SERVER 1: CLIENT
Usage: setsrvport <port>
Usage: setdstport <port>
Usage: dhcpclient <status>
<status>: 0: disable 1: enable
Usage: connectype <protocol>
<protocol>: 0: TCP 1: UDP
Usage: transmitimer <time>
<time>: time in ms
Usage: saveconfig
Usage: accessip <index> <ip addr>
<index>: index of accessible IP
<ip addr>: accessible IP address
Usage: setaccip <mode>
<mode>: 0: disable 1: enable
Usage: setaw <cold start> <authentication fail> <ip changed> <password changed>
<cold start>: 0: Disable 1: Enable
<authentication fail>: 0: Disable 1: Enable
<ip changed>: 0: Disable 1: Enable
<password changed>: 0: Disable 1: Enable
Usage: setdsthn <Host name/IP>
Usage: tftpsrv <ip addr>
Usage: filename <file name>
Usage: dlfirmware
Usage: seteep <HEX RegStartAddr> <HEX Byte 0> <HEX Byte 1>...<HEX Byte N>
Usage: dbgmsg <mode>
<mode>: 0: Disable 1: Enable
Usage: connstatus
Usage: ping xxx.xxx.xxx.xxx
Usage: setRTC <HEX RegStartAddr> <HEX Byte 0> <HEX Byte 1>...<HEX Byte N></pre>
Am besten mit "ipconfig" sich die aktuelle Konfiguration anzeigen lassen. Mit ping kann man Verbindungen z. B. zu Fhem testen.

HP1000

2016-10-02T07:08:20Z

Motivierte linke Hände: Erfahrungen und Informationen aus dem Support-Thread und der Commandref zusammengetragen.

{{Infobox Modul
|ModPurpose=Einbindung einer HP1000 Wetterstation
|ModType=d
|ModForumArea=Heizungssteuerung/Raumklima
|ModFTopic=44022
|ModTechName=50_HP1000.pm
|ModOwner={{Link2FU|1363|Loredo}}
}}
== HP1000 ==
HP1000 ist ein Modul zum Auslesen von HP1000/WH2600 Wetterstationen von renkforce/Froggit, etc.

Funktionsweise des Moduls ist, dass in der Wetterstation eine FHEMWEB Instanz angegeben wird, an die die Wetterstation dann regelmäßig die Daten sendet.
== Konfiguration ==
Die Konfiguration des Moduls erfolgt in drei Schritten:
=== Definition einer Webinstanz für die Wetterstation ===
Zunächst muss auf einem eigenen Port eine neue FHEMWEB-Instanz angelegt werden, z.B. mit dem Namen WEBweather. Dieser muss zwingend der Name weatherstation zugewiesen werden. Dieser ist in der Firmware der Stationen fest codiert.
define WEBweather FHEMWEB 8089 global
attr WEBweather webname weatherstation
=== Definition der Wetterstation ===
Dann wird das Modul noch in Fhem definiert. Die Definition kann mit und ohne Benutzernamen und Passwort erfolgen. Wenn bei der Definition Benutzername und Passwort nicht angegeben werden, werden die von der Wetterstation gesendeten Daten von Fhem nicht überprüft. (Die Station erfordert im Webinterfache immer die Angabe von Benutzername und Passwort!)
Definition mit Benutzername und Passwort:
define Wetterstation HP1000 Benutzer Passwort
Definition ohne Benutzername und Passwort:
define Wetterstation HP1000
=== Eingaben im Webinterface der Station ===
Dann muss der Station in deren Webinterface noch gesagt werden, dass die Wetterinformationen an Fhem geschickt werden. Dazu im Webinterface unter "Weather Network" Folgendes eintragen:
<pre>Remote Server => Customzied
Server IP/Hostname => <Fhem-Domainname> bzw. <Fhem-IP> (s.u.)
Server Port => Der Port der neuen Webinstanz in Fhem (im Beispiel oben 8089)
Station ID => selbstgewählter Benutzername
Password => selbstgewähltes Passwort</pre>
Zu '''Server IP/Hostname''': Hier muss entweder der Domainname angegeben werden, unter dem Fhem erreichbar ist (vollständige Domain nicht vergessen!), oder die IP. Wenn in Fhem keine Daten ankommen, ist das hier meist der Knackpunkt. Erfahrungen zeigen, dass teilweise der Domainname nicht vollständig angegeben wurde oder aber der Domainname nicht aufgelöst werden kann (vielleicht gibt es hier Probleme einzelner Stationen, bei der Konfiguration via DHCP den Nameserver-Eintrag richtig umzusetzen). Einfach mal alle Möglichkeiten durchprobieren.

'''Station ID''' und '''Passwort''' müssen hier angegeben werden. Bei der Definition der Station in Fhem kann man diese angeben (dann wird geprüft, ob die berechtigte Station Daten schickt) oder weglassen (dann werden Benutzername und Passwort nicht von Fhem geprüft).
== Tipps, Tricks, Problemlösungen ==
== FileLog ==
Das Modul definiert bei der Erstellung kein FileLog. Wenn man eines definiert, bietet sich aufgrund der Häufigkeit von Datenübertragungen und damit der Menge an übertragenen Informationen das Loggen nur des T:-Readings an:
define FileLog_Wetterstation FileLog ./log/Wetterstation-%Y.log Wetterstation:T:.*
== Mehr Einträge im T:-Reading ==
Das Modul liefert standardmäßig nicht alle vom Außensender verfügbaren Daten auch in der T:-Zeile. Wenn man dort - z. B. zum Loggen - alle Daten haben möchte, kann man die übrigen Daten ergänzen. Dafür editiert man die Datei 50_HP1000.pm und ergänzt Zeilen.
Im Bereich von Zeile 347 suchen:
<pre> $result = "T: " . $webArgs->{outtemp} if ( defined( $webArgs->{outtemp} ) );
$result .= " H: " . $webArgs->{outhumi}
if ( defined( $webArgs->{outhumi} ) );
$result .= " Ti: " . $webArgs->{intemp}
if ( defined( $webArgs->{intemp} ) );
$result .= " Hi: " . $webArgs->{inhumi}
if ( defined( $webArgs->{inhumi} ) );
$result .= " W: " . $webArgs->{windspeed}
if ( defined( $webArgs->{windspeed} ) );
$result .= " R: " . $webArgs->{rainrate}
if ( defined( $webArgs->{rainrate} ) );
$result .= " WD: " . $webArgs->{winddir}
if ( defined( $webArgs->{winddir} ) );
$result .= " D: " . $webArgs->{dewpoint}
if ( defined( $webArgs->{dewpoint} ) );
$result .= " P: " . $webArgs->{relbaro}
if ( defined( $webArgs->{relbaro} ) );</pre>
und dahinter folgende neue Zeilen einfügen:
<pre> $result .= " U: " . $webArgs->{UV}
if ( defined( $webArgs->{UV} ) );
$result .= " L: " . $webArgs->{light}
if ( defined( $webArgs->{light} ) );
$result .= " WC: " . $webArgs->{windchill}
if (defined($webArgs->{windchill}));
$result .= " RD: " . $webArgs->{dailyrain}
if (defined($webArgs->{dailyrain}));
$result .= " RW: " . $webArgs->{weeklyrain}
if (defined($webArgs->{weeklyrain}));
$result .= " RM: ".$webArgs->{monthlyrain}
if (defined($webArgs->{monthlyrain}));
$result .= " RY: ".$webArgs->{yearlyrain}
if (defined($webArgs->{yearlyrain}));
$result .= " WG: ".$webArgs->{windgust}
if (defined($webArgs->{windgust}));</pre>
Um zu verhindern, dass die eigenen Ergänzungen bei einem Update des Moduls überschrieben werden, dann noch 50_HP1000.pm vom automatischen Update ausnehmen:
attr global exclude_from_update 50_HP1000.pm
=== Absturz von Fhem wegen Illegal division by zero ===
Wenn HP1000 Fhem abstürzen lässt mit der Fehlermeldung
<pre>2016.10.01 08:51:00 1: PERL WARNING: Use of uninitialized value in division (/) at ./FHEM/50_HP1000.pm line 383.
Illegal division by zero at ./FHEM/50_HP1000.pm line 383.</pre>
dann hilft es, die mit + markierten Zeilen (natürlich ohne die +-Zeichen selbst!) in 50_HP1000.pm im sub HP1000_GetSum (um Zeile 400) einzufügen:
<pre> if ($avg) {
+ if (@{ $hash->{helper}{history}{$t} } > 0) {
$return = sprintf( "%.1f",
sum( @{ $hash->{helper}{history}{$t} } ) /
@{ $hash->{helper}{history}{$t} } );

Log3 $name, 5, "HP1000 $name: Average for $t: $return";
+ }
}</pre>
=== Falsch angezeigte/zu wenig Readings ===
Abhängig von der Firmwareversion und/oder dem Modell der Station kann es dazu kommen, dass teilweise nicht alle Readings oder die Readings mit den falschen Einheiten (z. B. Wingeschwindigkeit in mph, obwohl km/h konfiguriert wurde) angezeigt werden. In diesem Fall hilft es, im Webinterface der Wetterstation bei der Definition "Weather Network" den "Server Type" auf "JSP" zu stellen.
=== Keine Daten in Fhem ===
Wenn in Fhem keine Daten von der Wetterstation ankommen, liegt das häufig daran, dass FHEM nicht richtig als "Weather Network" konfiguriert wurde. Wenn die '''erforderlichen Eingaben im Webinterface''' (s. o.) der Station nicht helfen, kann man sich zum Testen per telnet mit der Wetterstation verbinden (Benutzername admin, Passwort admin). Mögliche Befehle:
<pre>help
quit
reboot
Usage: passwd
Old Password:
New Password:
Re-enter New Password:
Usage: username <user name>
Usage: ipconfig
Usage: setip <ip addr>
Usage: setmask <netmask>
Usage: setgateway <ip addr>
Usage: setdns <ip addr>
Usage: setmode <mode>
<mode>: 0: SERVER 1: CLIENT
Usage: setsrvport <port>
Usage: setdstport <port>
Usage: dhcpclient <status>
<status>: 0: disable 1: enable
Usage: connectype <protocol>
<protocol>: 0: TCP 1: UDP
Usage: transmitimer <time>
<time>: time in ms
Usage: saveconfig
Usage: accessip <index> <ip addr>
<index>: index of accessible IP
<ip addr>: accessible IP address
Usage: setaccip <mode>
<mode>: 0: disable 1: enable
Usage: setaw <cold start> <authentication fail> <ip changed> <password changed>
<cold start>: 0: Disable 1: Enable
<authentication fail>: 0: Disable 1: Enable
<ip changed>: 0: Disable 1: Enable
<password changed>: 0: Disable 1: Enable
Usage: setdsthn <Host name/IP>
Usage: tftpsrv <ip addr>
Usage: filename <file name>
Usage: dlfirmware
Usage: seteep <HEX RegStartAddr> <HEX Byte 0> <HEX Byte 1>...<HEX Byte N>
Usage: dbgmsg <mode>
<mode>: 0: Disable 1: Enable
Usage: connstatus
Usage: ping xxx.xxx.xxx.xxx
Usage: setRTC <HEX RegStartAddr> <HEX Byte 0> <HEX Byte 1>...<HEX Byte N></pre>
Am besten mit "ipconfig" sich die aktuelle Konfiguration anzeigen lassen. Mit ping kann man Verbindungen z. B. zu Fhem testen.

SSCAM - Steuerung von Kameras in Synology Surveillance Station

2016-09-17T07:02:39Z

Motivierte linke Hände: Hinweis, dass sendEmail, nicht sendmail für DebianMailnbl_send verwendet wird.

{{Infobox Modul
|ModPurpose=Steuerung von Kameras in Synology Surveillance Station
|ModType=d
|ModCmdRef=SSCam
|ModForumArea=Sonstiges
|ModTechName=49_SSCam.pm
|ModOwner=nasseeder1 (Forum: DS_Starter)}}

== Zweckbeschreibung ==

Mit diesem Modul können Operationen von in der Synology Surveillance Station (SVS) definierten Kameras ausgeführt werden.
Es basiert auf der SVS API und unterstützt die SVS ab Version 7.
Zur Zeit werden folgende Funktionen unterstützt:

* Start einer Aufnahme
* Stop einer Aufnahme (per Befehl bzw. automatisch nach Ablauf der Aufnahmedauer)
* Aufnehmen eines Schnappschusses und Ablage in der Synology Surveillance Station
* Deaktivieren einer Kamera in Synology Surveillance Station
* Aktivieren einer Kamera in Synology Surveillance Station
* Steuerung der Belichtungsmodi Tag, Nacht bzw. Automatisch
* Umschaltung der Ereigniserkennung durch Kamera, durch SVS oder deaktiviert
* Abfrage von Kameraeigenschaften (auch mit Polling) sowie den Eigenschaften des installierten SVS-Paketes
* Bewegen an eine vordefinierte Preset-Position (bei PTZ-Kameras)
* Start einer vordefinierten Überwachungstour (bei PTZ-Kameras)
* Positionieren von PTZ-Kameras zu absoluten X/Y-Koordinaten
* kontinuierliche Bewegung von PTZ-Kameras
* auslösen externer Ereignisse 1-10 (Aktionsregel SVS)
* starten und beenden von Kamera-Livestreams
* Abruf und Ausgabe der Kamera Streamkeys sowie Stream-Urls (zur Nutzung von Kamera-Livestreams ohne Session Id)
* abspielen der letzten Aufnahme

Die Aufnahmen stehen in der Synology Surveillance Station (SVS) zur Verfügung und unterliegen, wie jede andere Aufnahme, den in der Synology Surveillance Station eingestellten Regeln.
So werden zum Beispiel die Aufnahmen entsprechend ihrer Archivierungsfrist gespeichert und dann gelöscht.

Wenn sie über dieses Modul diskutieren oder zur Verbesserung des Moduls beitragen möchten, ist im FHEM-Forum ein Sammelplatz unter: 
{{Link2Forum|Topic=45671.0 |LinkText=49_SSCam: Fragen, Hinweise, Neuigkeiten und mehr rund um dieses Modul}}

 

== Vorbereitung ==

Dieses Modul nutzt das Perl-Modul JSON. Bitte darauf achten dieses Paket zu installieren. (Debian: apt-get install libjson-perl).
SSCAM verwendet für HTTP-Calls die nichtblockierenden Funktionen von HttpUtils bzw. HttpUtils_NonblockingGet.
Im DSM bzw. der Synology Surveillance Station muß ein Nutzer für den Zugriff aus FHEM angelegt sein. Die Zugangsdaten für diesen Nutzer werden später über ein Set-Kommando dem angelegten Gerät zugewiesen. 
Nähere Informationen dazu unter [[#Credentials | Credentials]].

Überblick über die Perl-Module welche von SSCam genutzt werden: 

JSON
Data::Dumper
MIME::Base64
Time::HiRes
HttpUtils (FHEM-Modul)

 

== Define ==
<pre>
define <name> SSCam <Kameraname in SVS> <ServerAddr> [Port]
</pre>

Definiert eine neue Kamera für SSCam. Zunächst muß diese Kamera in der Synology Surveillance Station 7.0 oder höher eingebunden sein und entsprechend funktionieren.

Das Modul SSCam basiert auf Funktionen der Synology Surveillance Station API.
Weitere Informationen unter: [http://global.download.synology.com/download/Document/DeveloperGuide/Surveillance_Station_Web_API_v2.0.pdf Web API Guide].

Momentan wird nur das HTTP-Protokoll unterstützt um die Web-Services der Synology DS aufzurufen.

Die Parameter beschreiben im Einzelnen:

<pre>
name : der Name des neuen Gerätes in FHEM
Kameraname : Kameraname wie er in der Synology Surveillance Station angegeben ist. Leerzeichen im Namen sind nicht erlaubt !
ServerAddr : die IP-Addresse des Synology Surveillance Station Host.
Achtung: Es sollte kein Servername verwendet werden weil DNS-Aufrufe in FHEM blockierend sind
Port : optional - der Port des Synology Surveillance Station Host.
Wenn nicht angegeben, wird der Standardport 5000 gesetzt(nur HTTP)
</pre>

Beispiel:

define CamCP SSCAM Carport 192.168.2.20 [5000]

Wird eine neue Kamera definiert, wird diesem Device zunächst eine Standardaufnahmdauer von 15 zugewiesen.
Über das Attribut "rectime" kann die Aufnahmedauer für jede Kamera individuell angepasst werden. Der Wert "0" für "rectime" führt zu einer Endlosaufnahme die durch '''"set <name> off"''' gestoppt werden muß. Ein Logeintrag mit einem entsprechenden Hinweis auf diesen Umstand wird geschrieben.

Wird das Attribut "rectime" gelöscht, greift wieder der Default-Wert (15s) für die Aufnahmedauer.

Mit dem Befehl '''"set <name> on [rectime]"''' wird die Aufnahmedauer temporär festgelegt und überschreibt einmalig sowohl den Defaultwert als auch den Wert des gesetzten Attributs "rectime". Auch in diesem Fall führt "set <name> on 0" zu einer Daueraufnahme.

Eine eventuell in der SVS eingestellte Dauer der Voraufzeichnung wird weiterhin berücksichtigt.

=== Credentials ===

Nach dem Definieren des Gerätes müssen zuerst die Zugangsparameter gespeichert werden. Das geschieht mit dem Befehl:

set <name> credentials <username> <password>

Der Anwender kann in Abhängigkeit der beabsichtigten einzusetzenden Funktionen einen Nutzer im DSM bzw. in der Surveillance Station einrichten.
Ist der DSM-Nutzer der Gruppe Administratoren zugeordnet, hat er auf alle Funktionen Zugriff. Ohne diese Gruppenzugehörigkeit können nur Funktionen mit niedrigeren Rechtebedarf ausgeführt werden. Die benötigten Mindestrechte der Funktionen sind in der Tabelle weiter unten aufgeführt.
Alternativ zum DSM-Nutzer kann ein in der SVS angelegter Nutzer verwendet werden. Auch in diesem Fall hat ein Nutzer vom Typ Manager das Recht alle Funktionen auszuführen, wobei der Zugriff auf bestimmte Kameras/ im Privilegienprofil beschränkt werden kann (siehe Hilfefunktion in SVS).
Als Best Practice wird vorgeschlagen jeweils einen User im DSM und einen in der SVS anzulegen.

* DSM-User als Mitglied der Admin-Gruppe: uneingeschränkter Test aller Modulfunktionen -> session:DSM
* SVS-User als Manager oder Betrachter: angepasstes Privilegienprofil -> session: SurveillanceStation

Über das Attribut "session" kann ausgewählt werden, ob die Session mit dem DSM oder der SVS augebaut werden soll.
Erfolgt der Session-Aufbau mit dem DSM, stehen neben der SVS Web-API auch darüber hinaus gehende API Zugriffe zur Verfügung die unter Umständen zur Verarbeitung benötigt werden.

Nach der Gerätedefinition ist die Grundeinstellung "Login in das DSM", d.h. es können Credentials mit Admin-Berechtigungen genutzt werden um zunächst alle Funktionen der Kameras testen zu können. Danach können die Credentials z.B. in Abhängigkeit der benötigten Funktionen auf eine SVS-Session mit entsprechend beschränkten Privilegienprofil umgestellt werden.

Die nachfolgende Aufstellung zeigt die Mindestanforderungen der jeweiligen Modulfunktionen an die Nutzerrechte.
<pre>
* set ... on session: ServeillanceStation - Betrachter mit erweiterten Privileg "manuelle Aufnahme"
* set ... off session: ServeillanceStation - Betrachter mit erweiterten Privileg "manuelle Aufnahme"
* set ... snap session: ServeillanceStation - Betrachter
* set ... disable session: ServeillanceStation - Manager
* set ... enable session: ServeillanceStation - Manager
* set ... expmode session: ServeillanceStation - Manager
* set ... motdetsc session: ServeillanceStation - Manager
* set ... goPreset session: ServeillanceStation - Betrachter mit Privileg Objektivsteuerung der Kamera
* set ... runPatrol session: ServeillanceStation - Betrachter mit Privileg Objektivsteuerung der Kamera
* set ... goAbsPTZ session: ServeillanceStation - Betrachter mit Privileg Objektivsteuerung der Kamera
* set ... move session: ServeillanceStation - Betrachter mit Privileg Objektivsteuerung der Kamera
* set ... runView session: ServeillanceStation - Betrachter mit Privileg Liveansicht für Kamera
* set ... stopView -
* set ... credentials -
* set ... extevent session: DSM - Nutzer Mitglied von Admin-Gruppe
* get ... caminfoall session: ServeillanceStation - Betrachter
* get ... eventlist session: ServeillanceStation - Betrachter
* get ... svsinfo session: ServeillanceStation - Betrachter
* get ... svsinfo session: ServeillanceStation - Betrachter
* get ... stmUrlPath session: ServeillanceStation - Betrachter

</pre>

=== HTTP-Timeout setzen ===

Alle Funktionen dieses Moduls verwenden HTTP-Aufrufe gegenüber der SVS Web API. 
Der Standardwert für den HTTP-Timeout beträgt 4 Sekunden.
Durch Setzen des Attributes "httptimeout" > 0 kann dieser Wert bei Bedarf entsprechend den technischen Gegebenheiten angepasst werden.

 

== Set ==

Es gibt zur Zeit folgende Optionen für "set <name> ...".

<pre>
"on [rectime]": startet eine Aufnahme. Die Aufnahme wird automatisch nach Ablauf der Zeit [rectime]
gestoppt.
mit rectime = 0 wird eine Daueraufnahme gestartet die durch "set <name> off"
wieder gestoppt werden muß.
"off" : stoppt eine laufende Aufnahme manuell oder durch die Nutzung anderer Events
(z.B. über at, notify)
"snap": löst einen Schnappschuß der entsprechenden Kamera aus und speichert ihn in der SVS
"disable": deaktiviert eine Kamera in der Surveillance Station
"enable": aktiviert eine Kamera in der Surveillance Station
"credentials <username> <password>": speichert die Zugangsinformationen
"expmode [ day | night | auto ]": aktiviert den Belichtungsmodus Tag, Nacht oder Automatisch
"extevent [ 1-10 ]": löst das externe Ereignis 1-10 aus (Aktionsregeleditor in SVS)
"motdetsc [ by_camera | by_SVS | disable ]": schaltet die Bewegungserkennung in den gewünschten Modus
(durch Kamera, SVS, oder deaktiviert)
"goPreset <Presetname>": fährt eine PTZ-Kamera zu einer vordefinierten Preset-Position
"runPatrol <Patrolname>": startet eine vordefinierte Überwachungstour einer PTZ-Kamera
"goAbsPTZ [ X Y | up | down | left | right ]": positioniert eine PTZ-Kamera zu einer X/Y-Koordinate oder in Richtung up/down/left/right
"move [ up | down | left | right | dir_X ]": startet kontinuerliche Bewegung einer PTZ-Kamera in Richtung up/down/left/right bzw. dir_X
"runView [image | lastrec | lastrec_open |
link | link_open <room>]": startet einen Livestream bzw. die letzte Aufnahme als eingbettetes Image, als Link
oder öffnet diesen Medienstream sofort
"stopView": Gegenteil von "runView"
</pre>

=== set <name> [on [rectime] | off] ===

Der Befehl "set <name> on" startet eine Aufnahme. Die Standardaufnahmedauer beträgt 15 Sekunden. Sie kann mit dem Attribut "rectime" individuell festgelegt werden. Die im Attribut (bzw. im Standard) hinterlegte Aufnahmedauer kann einmalig mit "set <name> on [rectime]" überschrieben werden.
Die Aufnahme stoppt automatisch nach Ablauf der Zeit "rectime".

Ein Sonderfall ist der Start einer Daueraufnahme mit "set <name> on 0" bzw. dem Attributwert "rectime = 0". In diesem Fall wird eine Daueraufnahme gestartet die explizit wieder mit dem Befehl ""set <name> off" gestoppt werden muß.

Das Aufnahmeverhalten kann weiterhin mit dem Attribut "recextend" wie folgt beeinflusst werden.

'''Attribut "recextend = 0" bzw. nicht gesetzt (Standard):'''
* wird eine Aufnahme mit z.B. rectime=22 gestartet, wird kein weiterer Startbefehl für eine Aufnahme akzeptiert bis diese gestartete Aufnahme nach 22 Sekunden beendet ist. Ein Hinweis wird bei verbose=3 im Logfile protokolliert.

'''Attribut "recextend = 1" gesetzt:'''
* eine zuvor gestartete Aufnahme wird bei einem erneuten "set <name> on"-Befehl mit der Aufnahmezeit "rectime" neu parametrisiert. Das bedeutet, dass der Timer für den automatischen Stop auf den Wert "rectime" neu gesetzt wird. Dieser Vorgang wiederholt sich mit jedem Start-Befehl. Dadurch verlängert sich eine laufende Aufnahme bis kein Start-Inpuls mehr registriert wird.

* eine zuvor gestartete Endlos-Aufnahme wird mit einem erneuten "set <name> on"-Befehl nach der Aufnahmezeit "rectime" gestoppt (Timerneustart). Ist dies nicht gewünscht, ist darauf zu achten dass bei der Verwendung einer Endlos-Aufnahme das Attribut "recextend" nicht verwendet wird.

Beispiele für einfache Operationen:

<pre>
set <name> on [rectime] : startet die Aufnahme der Kamera <name>.
set <name> off : stoppt die Aufnahme der Kamera <name>
set <name> disable : deaktiviert die Kamera <name> in der Surveillance Station
set <name> enable : aktiviert die Kamera <name> in der Surveillance Station
</pre>

'''Hinweis:'''

In der SVS kann unter Aufnahmeeinstellungen der Kamera eine Vor-Aufnahmezeit eingestellt werden. Die Einstellung wird von der SVS bezüglich der Gesamtaufnahmezeit automatisch mit berücksichtigt.

Eine eingestellte Vor-Aufnahmezeit von z.B. 10s und eine rectime von 20s führt zu einer Gesamtaufnahmezeit von 30s (zzgl. Prozesszeit zur Befehlsabarbeitung).

=== set <name> snap ===

Ein Schnappschuß kann ausgelöst werden durch:

<pre>
set <name> snap
</pre>

Soll eine Reihe Schnappschüsse ausgelöst werden wenn eine Aufnahme startet, kann das durch folgendes notify geschehen.
Wird der Start der Kamera CamHE1 ausgelöst (vorher Attribut event-on-change-reading -> "Record" setzen), werden 3 Snapshots im Abstand von 2 Sekunden getriggert.

<pre>
define he1_snap_3 notify CamHE1:Record.*on define h3 at +*{3}00:00:02 set CamHE1 snap
</pre>

Triggern von 2 Schnappschüssen der Kamera "CamHE1" im Abstand von 6 Sekunden nachdem der Bewegungsmelder "MelderHE1" einen Event gesendet hat, kann z.B. mit folgendem notify geschehen:

<pre>
define he1_snap_2 notify MelderHE1:on.* define h2 at +*{2}00:00:06 set CamHE1 snap
</pre>

Es wird die ID des letzten Snapshots als Wert der Variable "LastSnapId" in den Readings der Kamera ausgegeben.

=== set <name> [enable] [disable] ===

Um eine Liste von Kameras oder alle Kameras (mit Regex) zum Beispiel um 21:46 zu deaktivieren / zu aktivieren zwei Beispiele mit at:

<pre>
define a13 at 21:46 set CamCP1,CamFL,CamHE1,CamTER disable (enable)
define a14 at 21:46 set Cam.* disable (enable)
</pre>

Etwas komfortabler gelingt das Schalten aller Kameras über einen Dummy.
Zunächst wird der Dummy angelegt:

<pre>
define allcams dummy
attr allcams eventMap on:enable off:disable
attr allcams room Cams
attr allcams webCmd enable:disable
</pre>

Durch Verknüpfung mit zwei angelegten notify, jeweils ein notify für "enable" und "disable", kann man durch Schalten des Dummys auf "enable" bzw. "disable" alle Kameras auf einmal aktivieren bzw. deaktivieren.

<pre>
define all_cams_disable notify allcams:.*off set CamCP1,CamFL,CamHE1,CamTER disable
attr all_cams_disable room Cams

define all_cams_enable notify allcams:on set CamCP1,CamFL,CamHE1,CamTER enable
attr all_cams_enable room Cams
</pre>

 
=== set <name> expmode [day] [night] [auto] ===

Mit diesem Befehl kann der Belichtungsmodus der Kameras gesetzt werden. Dadurch wird z.B. das Verhalten der Kamera-LED's entsprechend gesteuert. Die erfolgreiche Umschaltung wird durch das Reading CamExposureMode ("get ... caminfoall") reportet.

'''Hinweis:''' Die erfolgreiche Ausführung dieser Funktion ist davon abhängig ob die SVS diese Funktionalität der Kamera unterstützt. Ist in SVS -> IP-Kamera -> Optimierung -> Belichtungsmodus das Feld für den Tag/Nachtmodus grau hinterlegt, ist nicht von einer lauffähigen Unterstützung dieser Funktion auszugehen.

 
=== set <name> motdetsc [camera] [SVS] [disable] (geändert ab Rev 11284) ===

Der Befehl "motdetsc" (steht für "motion detection source") schaltet die Bewegungserkennung in den gewünschten Modus.
Wird die Bewegungserkennung durch die Kamera / SVS ohne weitere Optionen eingestellt, werden die momentan gültigen Bewegungserkennungsparameter der Kamera / SVS beibehalten.
Die erfolgreiche Ausführung der Operation lässt sich u.a. anhand des Status von SVS -> IP-Kamera -> Ereigniserkennung -> Bewegung nachvollziehen.

Für die Bewegungserkennung durch SVS bzw. durch Kamera können weitere Optionen angegeben werden. Die verfügbaren Optionen bezüglich der Bewegungserkennung durch SVS sind "Empfindlichkeit" und "Schwellwert".

<pre>
set <name> motdetsc SVS [Empfindlichkeit] [Schwellwert] # Befehlsmuster
set <name> motdetsc SVS 91 30 # setzt die Empfindlichkeit auf 91 und den Schwellwert auf 30
set <name> motdetsc SVS 0 40 # behält gesetzten Wert für Empfindlichkeit bei, setzt Schwellwert auf 40
set <name> motdetsc SVS 15 # setzt die Empfindlichkeit auf 15, Schwellwert bleibt unverändert
</pre>

Wird die Bewegungserkennung durch die Kamera genutzt, stehen die Optionen "Empfindlichkeit", "Objektgröße" und "Prozentsatz für Auslösung" zur Verfügung.

<pre>
set <name> motdetsc camera [Empfindlichkeit] [Schwellwert] [Prozentsatz] # Befehlsmuster
set <name> motdetsc camera 89 0 20 # setzt die Empfindlichkeit auf 89, Prozentsatz auf 20
set <name> motdetsc camera 90 40 10 # setzt Empfindlichkeit auf 90, Schwellwert auf 40,
Prozentsatz auf 10
set <name> motdetsc camera 30 # setzt die Empfindlichkeit auf 30, andere Werte bleiben
unverändert
</pre>

Es ist immer die Reihenfolge der Optionswerte zu beachten. Nicht gewünschte Optionen sind mit "0" zu besetzen sofern danach Optionen folgen deren Werte verändert werden sollen (siehe Beispiele oben). Der Zahlenwert der Optionen beträgt 1 - 99 (außer Sonderfall "0").

Die jeweils verfügbaren Optionen unterliegen der Funktion der Kamera und der Unterstützung durch die SVS. Es können jeweils nur die Optionen genutzt werden die in SVS -> Kamera bearbeiten -> Ereigniserkennung zur Verfügung stehen. Weitere Infos sind der Online-Hilfe zur SVS zu entnehmen.

Über den Befehl "get ... caminfoall" wird auch das Reading "CamMotDetSc" aktualisiert welches die gegenwärtige Einstellung der Bewegungserkennung dokumentiert. Es werden nur die Parameter und Parameterwerte angezeigt, welche die SVS aktiv unterstützt. Die Kamera selbst kann weiterführende Einstellmöglichkeiten besitzen.

Beispiel:

<pre>
CamMotDetSc SVS, sensitivity: 76, threshold: 55
</pre>

 

=== set <name> goPreset <Preset> ===

Mit diesem Kommando können PTZ-Kameras in eine vordefininierte Position bewegt werden. 
Die Preset-Positionen müssen dazu zunächst in der Synology Surveillance Station angelegt worden sein. Das geschieht in der PTZ-Steuerung im IP-Kamera Setup.
Die Presets werden über das Kommando "set <name> getinfo" eingelesen (geschieht bei restart von FHEM automatisch). Der Einlesevorgang kann durch ein Kamerapolling
regelmäßig wiederholt werden. Ein langes Pollingintervall ist in diesem Fall empfehlenswert da die Presetpositionen sich nur im Fall der Neuanlage bzw. Änderung verändern werden.
 

Hier ein Beispiel einer PTZ-Steuerung in Abhängigkeit eines IR-Melder Events:

<pre>
define CamFL.Preset.Wandschrank notify MelderTER:on.* set CamFL goPreset Wandschrank, ;; define CamFL.Preset.record
at +00:00:10 set CamFL on 5 ;;;; define s3 at +*{3}00:00:05 set CamFL snap ;; define CamFL.Preset.back at +00:00:30 set CamFL goPreset Home
</pre>

Funktionsweise: 
Der IR-Melder "MelderTER" registriert eine Bewegung. Daraufhin wird die Kamera CamFL in die Preset-Position "Wandschrank" gebracht. Eine Aufnahme mit Dauer von 5 Sekunden startet 10 Sekunden
später. Da die Voraufnahmezeit der Kamera 10s beträgt (vgl. Reading "CamPreRecTime"), startet die effektive Aufnahme wenn der Kameraschwenk beginnt. 
Mit dem Start der Aufnahme werden drei Schnappschüsse im Abstand von 5 Sekunden angefertigt. 
Nach einer Zeit von 30 Sekunden fährt die Kamera wieder zurück in die "Home"-Position. 

Ein Auszug aus dem Log verdeutlicht den Ablauf:

<pre>
2016.02.04 15:02:14 2: CamFL - Camera Flur_Vorderhaus has moved to position "Wandschrank"
2016.02.04 15:02:24 2: CamFL - Camera Flur_Vorderhaus Recording with Recordtime 5s started
2016.02.04 15:02:29 2: CamFL - Snapshot of Camera Flur_Vorderhaus has been done successfully
2016.02.04 15:02:30 2: CamFL - Camera Flur_Vorderhaus Recording stopped
2016.02.04 15:02:34 2: CamFL - Snapshot of Camera Flur_Vorderhaus has been done successfully
2016.02.04 15:02:39 2: CamFL - Snapshot of Camera Flur_Vorderhaus has been done successfully
2016.02.04 15:02:44 2: CamFL - Camera Flur_Vorderhaus has moved to position "Home"
</pre>

 
=== set <name> runPatrol <Patrolname> ===

Dieses Kommando startet die vordefinierterte Überwachungstour einer PTZ-Kamera. 
Die Überwachungstouren müssen dazu zunächst in der Synology Surveillance Station angelegt worden sein. Das geschieht in der PTZ-Steuerung im IP-Kamera Setup -> PTZ-Steuerung -> Überwachung.

Die Überwachungstouren (Patrols) werden über das Kommando "get <name> caminfoall" eingelesen, welches beim Restart von FHEM automatisch abgearbeitet wird. Der Einlesevorgang kann durch ein Kamerapolling regelmäßig wiederholt werden. Ein langes Pollingintervall ist in diesem Fall empfehlenswert, da sich die Überwachungstouren nur im Fall der Neuanlage bzw. Änderung verändern werden.

Nähere Informationen zur Anlage von Überwachungstouren sind in der Hilfe zur Surveillance Station enthalten.

 

=== set <name> goAbsPTZ [ X Y | up | down | left | right ] ===

Mit diesem Kommando wird eine PTZ-Kamera in Richtung einer wählbaren absoluten X/Y-Koordinate bewegt, oder zur maximalen Absolutposition in Richtung up/down/left/right.
Die Option ist nur für Kameras verfügbar die das Reading "CapPTZAbs=true" (die Fähigkeit für PTZAbs-Aktionen) besitzen. Die Eigenschaften der Kamera kann mit "get <name> caminfoall" abgefragt werden.
 

Beispiel für Ansteuerung absoluter X/Y-Koordinaten: 

<pre>
set <name> goAbsPTZ 120 450
</pre>

Dieses Beispiel bewegt die Kameralinse in die Position X=120 und Y=450. 
Der Wertebereich ist dabei:

<pre>
X = 0 - 640 (0 - 319 bewegt nach links, 321 - 640 bewegt nach rechts, 320 bewegt die Linse nicht)
Y = 0 - 480 (0 - 239 bewegt nach unten, 241 - 480 bewegt nach oben, 240 bewegt die Linse nicht)
</pre>

Die Linse kann damit in kleinsten bis sehr großen Schritten in die gewünschte Richtung bewegt werden. Dieser Vorgang muß ggf. mehrfach wiederholt werden um die Kameralinse in die gewünschte Position zu bringen. 

Soll die Bewegung mit der maximalen Schrittweite erfolgen, kann zur Vereinfachung der Befehl:

<pre>
set <name> goAbsPTZ up [down ] [left] [right]
</pre>

verwendet werden. Die Optik wird in diesem Fall mit der größt möglichen Schrittweite zur Absolutposition in der angegebenen Richtung bewegt. Auch in diesem Fall muß der Vorgang ggf. mehrfach wiederholt werden um die Kameralinse in die gewünschte Position zu bringen.

=== set <name> move [ up | down | left | right | dir_X ] [Sekunden] ===

Mit diesem Kommando wird eine kontinuierliche Bewegung der PTZ-Kamera gestartet. Neben den vier Grundrichtungen up/down/left/right stehen auch Zwischenwinkelmaße "dir_X" zur Verfügung. Die Feinheit dieser Graduierung ist von der Kamera abhängig und kann dem Reading "CapPTZDirections" entnommen werden.

Das Bogenmaß von 360 Grad teilt sich durch den Wert von "CapPTZDirections" und beschreibt die Bewegungsrichtungen beginnend mit "0=rechts" entgegen dem Uhrzeigersinn. D.h. bei einer Kamera mit "CapPTZDirections = 8" bedeutet dir_0 = rechts, dir_2 = oben, dir_4 = links, dir_6 = unten bzw. dir_1, dir_3, dir_5 und dir_7 die entsprechenden Zwischenrichtungen. Die möglichen Bewegungsrichtungen bei Kameras mit "CapPTZDirections = 32" sind dementsprechend kleinteliger.

Im Gegensatz zum "set <name> goAbsPTZ"-Befehl startet der Befehl "set <name> move" eine kontinuierliche Bewegung bis ein Stop-Kommando empfangen wird. Das Stop-Kommando wird nach Ablauf der optional anzugebenden Zeit [Sekunden] ausgelöst. Wird diese Laufzeit nicht angegeben, wird implizit Sekunde = 1 gesetzt.

Beispiele:

<pre>
set <name> move up 0.5 : bewegt die Linse 0,5 Sekunden (zzgl. Prozesszeit) nach oben (zzgl. Prozesszeit)
set <name> move dir_1 1.5 : bewegt die Linse 1,5 Sekunden (zzgl. Prozesszeit) nach rechts-oben
set <name> move dir_20 0.7 : bewegt die Linse 1,5 Sekunden (zzgl. Prozesszeit) nach links-unten bei "CapPTZDirections = 32"
</pre>

 
=== set <name> runView [ image | lastrec | lastrec_open | link | link_open <room>] ===

Mit "image, link, link_open" Es wird ein Livestream (mjpeg-Stream) der Kamera, entweder als eingebettetes Image oder als generierter Link, gestartet.
Der Zugriff auf die letzte Aufnahme einer Kamera kann über die Zusätze "lastrec" bzw. "lastrec_open" erfolgen.

'''Beispiele:'''

<pre>
attr <name> htmlattr target=_blank width="500" height="375"
attr <name> htmlattr target=_blank width=500,height=375
attr <name> htmlattr width=700,height=525,top=200,left=300
</pre>

Das Verhalten des Livestreams im FHEMWEB kann durch Angaben im Attribut "htmlattr" beeinflusst werden.
Mit diesen Attributwerten öffnet der Link als weiteres Fenster/Browsertab. Wird der Stream als Image gestartet, ändert sich die Größe entsprechend der Angaben von Width und Height.
Das Kommando "set <name> runView link_open" startet den Livestreamlink sofort in einem neuen Browsertab (longpoll=1 muß für WEB gesetzt sein).
Dabei wird für jede aktive FHEM-Session eine Fensteröffnung initiiert. Soll dieses Verhalten geändert werden, kann "set <name> runView link_open <room>"
verwendet werden um das Öffnen des Browserwindows in einem beliebigen, in einer FHEM-Session angezeigten Raum <room>, zu initiieren. 

Das gesetzte Attribut "livestreamprefix" überschreibt im Reading "LiveStreamUrl" die Angaben für Protokoll, Servername und Port. Damit kann z.B. die LiveStreamUrl für den Versand und externen Zugriff auf die SVS modifiziert werden.

'''Beispiel:'''

<pre>
attr <name> livestreamprefix https://<Servername>:<Port>
</pre>

Der Livestream wird über das Kommando "set <name> stopView" wieder beendet.

 

=== set <name> extevent [ 1-10 ] ===

Dieses Kommando triggert ein externes Ereignis (1-10) in der SVS. Die Aktionen, die dieses Ereignis auslöst, sind zuvor in dem Aktionsregeleditor der SVS einzustellen. Es stehen die Ereignisse 1-10 zur Verfügung. In der Banchrichtigungs-App der SVS können auch Email, SMS oder Mobil (DS-Cam) Nachrichten ausgegeben werden wenn ein externes Ereignis ausgelöst wurde. Nähere Informationen dazu sind in der Hilfe zum Aktionsregeleditor zu finden. Der verwendete User benötigt Admin-Rechte in einer DSM-Session.

 

== Get ==

Mit SSCam können die Eigenschaften der Kameras aus der Surveillance Station abgefragt werden. Dazu steht der Befehl zur Verfügung:

<pre>
get <name> caminfoall
get <name> eventlist
get <name> stmUrlPath
get <name> svsinfo
get <name> snapfileinfo
</pre>

Mit dem Befehl "get <name> caminfoall" werden abhängig von der Art der Kamera (z.B. Fix- oder PTZ-Kamera) die verfügbaren Eigenschaften ermittelt und als Readings zur Verfügung gestellt.
So wird zum Beispiel das Reading "Availability" auf "disconnected" gesetzt falls die Kamera von der Surveillance Station getrennt wird und kann für weitere Verarbeitungen genutzt werden.
Durch "get <name> eventlist" wird das Reading "CamEventNum" aktualisiert, welches die Gesamtanzahl der registrierten Kameraevents enthält.
Mit "get <name> snapfileinfo" wird der Filename des letzten Schnapschusses ermittelt. Der Befehl wird implizit mit "get <name> snap" ausgeführt.

Der Befehl "get <name> svsinfo" ist eigentlich nicht von der Kamera abhängig, sondern ermittelt vielmehr allgemeine Informationen zur installierten SVS-Version und andere Eigenschaften.
Die Funktionen "caminfoall" und "svsinfo" werden einmalig automatisch beim Start von FHEM ausgeführt um steuerungsrelevante Informationen zu sammeln.
Es ist darauf zu achten dass vorher die Credentials gespeichert wurden !

'''get <name> stmUrlPath'''

Mit diesem Kommando wird der aktuelle Streamkey der Kamera abgerufen und das Reading mit dem Key-Wert gefüllt. Dieser Streamkey kann verwendet werden um eigene Aufrufe eines Livestreams aufzubauen (siehe Beispiel). Wenn das Attribut "showStmInfoFull" gesetzt ist, werden zusaätzliche Stream-Informationen wie "StmKeyUnicst", "StmKeymjpegHttp" ausgegeben. Diese Readings enthalten die gültigen Stream-Pfade zu einem Livestream und können z.B. versendet und von einer entsprechenden Anwendung ohne session Id geöffnet werden. Wenn das Attribut "livestreamprefix" (Format: "http(s)://<hostname><port>) gesetzt ist, wird der Servername und Port überschrieben soweit es sinnvoll ist. Wird Polling der Kameraeigenschaften genutzt, wird die stmUrlPath-Funktion automatisch mit ausgeführt.

Beispiel für den Aufbau eines Http-Calls zu einem Livestream mit StmKey:

<pre>
http(s)://<hostname><port>/webapi/entry.cgi?api=SYNO.SurveillanceStation.VideoStreaming&version=1&method=Stream&format=mjpeg&cameraId=5StmKey="31fd87279976d89bb98409728cced890"
</pre>

cameraId (INTERNAL), StmKey müssen durch gültige Werte ersetzt werden.

'''Hinweis:'''

Falls der Stream-Aufruf versendet und von extern genutzt wird sowie hostname / port durch gültige Werte ersetzt und die Routerports entsprechend geöffnet werden, ist darauf zu achten dass diese sensiblen Daten nicht durch unauthorisierte Personen für den Zugriff genutzt werden können !

'''Polling der Kameraeigenschaften:''' 
Die Abfrage der Kameraeigenschaften erfolgt automatisch, wenn das Attribut "pollcaminfoall" (siehe Attribute) mit einem Wert > 10 gesetzt wird. Per Default ist das Attribut "pollcaminfoall" nicht gesetzt und das automatische Polling nicht aktiv. Der Wert dieses Attributes legt das Intervall der Abfrage in Sekunden fest. Ist das Attribut nicht gesetzt oder < 10 wird kein automatisches Polling gestartet bzw. gestoppt wenn vorher der Wert > 10 gesetzt war.

Das Attribut "pollcaminfoall" wird durch einen Watchdog-Timer überwacht. Änderungen des Attributwertes werden alle 90 Sekunden ausgewertet und entsprechend umgesetzt. Eine Änderung des Pollingstatus / Pollingintervalls wird im FHEM-Logfile protokolliert. Diese Protokollierung kann durch Setzen des Attributes "pollnologging" abgeschaltet werden. Dadurch kann ein unnötiges Anwachsen des Logs vermieden werden. Ab verbose=4 wird allerdings trotz gesetzten "pollnologging"-Attribut ein Log des Pollings zu Analysezwecken aktiviert.

Wird FHEM neu gestartet, wird bei aktivierten Polling der ersten Datenabruf innerhalb 60s nach dem Start ausgeführt.

Der Status des automatischen Pollings wird durch das Reading "PollState" signalisiert:

<pre>
PollState = Active - automatisches Polling wird mit Intervall entsprechend <pollcaminfoall> ausgeführt
PollState = Inactive - automatisches Polling wird nicht ausgeführt
</pre>

Die Bedeutung der Readingwerte ist unter Readings beschrieben.

'''Hinweise:'''

Wird Polling eingesetzt, sollte das Intervall nur so kurz wie benötigt eingestellt werden da die ermittelten Werte überwiegend statisch sind.
Das eingestellte Intervall sollte nicht kleiner sein als die Summe aller HTTP-Verarbeitungszeiten. Pro Pollingaufruf und Kamera werden ca. 10 - 20 Http-Calls gegen die Surveillance Station abgesetzt.

Bei einem eingestellten HTTP-Timeout (siehe Attribut) "httptimeout") von 4 Sekunden kann die theoretische Verarbeitungszeit nicht höher als 80 Sekunden betragen.
In dem Beispiel sollte man das Pollingintervall mit einem Sicherheitszuschlag auf nicht weniger 160 Sekunden setzen.
Ein praktikabler Richtwert könnte zwischen 600 - 1800 (s) liegen.

Sind mehrere Kameras in SSCam definiert, sollte "pollcaminfoall" nicht bei allen Kameras auf exakt den gleichen Wert gesetzt werden um Verarbeitungsengpässe und dadurch versursachte potentielle Fehlerquellen bei der Abfrage der Synology Surveillance Station zu vermeiden.
Ein geringfügiger Unterschied zwischen den Pollingintervallen der definierten Kameras von z.B. 1s kann bereits als ausreichend angesehen werden.

 

== Readings ==

Über den Pollingmechanismus bzw. durch Abfrage mit "Get" werden Readings bereitgestellt, deren Bedeutung in der nachfolgenden Tabelle dargestellt sind. Die übermittelten Readings können in Abhängigkeit des Kameratyps variieren.

<pre>
* Availability - Verfügbarkeit der Kamera (disabled, enabled, disconnected, other)
* CamEventNum - liefert die Gesamtanzahl der in SVS registrierten Events der Kamera
* CamExposureControl - zeigt den aktuell eingestellten Typ der Belichtungssteuerung
* CamExposureMode - aktueller Belichtungsmodus (Day, Night, Auto, Schedule, Unknown)
* CamIP - IP-Adresse der Kamera
* CamLiveMode - Quelle für Live-Ansicht (DS, Camera)
* CamModel - Kameramodell
* CamPort - IP-Port der Kamera
* CamPreRecTime - Dauer der der Voraufzeichnung in Sekunden (Einstellung in SVS)
* CamRecShare - gemeinsamer Ordner auf der DS für Aufnahmen
* CamRecVolume - Volume auf der DS für Aufnahmen
* CamVendor - Kamerahersteller Bezeichnung
* CamVideoFlip - Ist das Video gedreht </td></tr>
* CamVideoMirror - Ist das Video gespiegelt </td></tr>
* CapAudioOut - Fähigkeit der Kamera zur Audioausgabe über Surveillance Station (false/true)
* CapChangeSpeed - Fähigkeit der Kamera verschiedene Bewegungsgeschwindigkeiten auszuführen
* CapPTZAbs - Fähigkeit der Kamera für absolute PTZ-Aktionen
* CapPTZAutoFocus - Fähigkeit der Kamera für Autofokus Aktionen
* CapPTZDirections - die verfügbaren PTZ-Richtungen der Kamera
* CapPTZFocus - Art der Kameraunterstützung für Fokussierung
* CapPTZHome - Unterstützung der Kamera für Home-Position
* CapPTZIris - Unterstützung der Kamera für Iris-Aktion
* CapPTZPan - Unterstützung der Kamera für Pan-Aktion
* CapPTZTilt - Unterstützung der Kamera für Tilt-Aktion
* CapPTZZoom - Unterstützung der Kamera für Zoom-Aktion
* DeviceType - Kameratyp (Camera, Video_Server, PTZ, Fisheye)
* Error - Meldungstext des letzten Fehlers
* Errorcode - Fehlercode des letzten Fehlers
* LastSnapFilename - der Filename des letzten Schnapschusses
* LastSnapId - die ID des letzten Schnapschusses
* LastUpdateTime - Datum / Zeit der letzten Aktualisierung durch "caminfoall"
* LiveStreamUrl - die LiveStream-Url wenn der Stream gestartet ist. (Attribut "showStmInfoFull" muss gesetzt sein)
* Patrols - in Surveillance Station voreingestellte Überwachungstouren (bei PTZ-Kameras)
* PollState - zeigt den Status des automatischen Pollings an
* Presets - in Surveillance Station voreingestellte Positionen (bei PTZ-Kameras)
* Record - Aufnahme läuft = Start, keine Aufnahme = Stop
* StmKey - aktueller StreamKey. Kann zum öffnen eines Livestreams ohne Session Id genutzt werden.
* StmKeyUnicst - Uni-cast Stream Pfad der Kamera. ((Attribut "showStmInfoFull" muss gesetzt sein)
* StmKeymjpegHttp - Mjpeg Stream Pfad (über http) der Kamera. (Attribut "showStmInfoFull" muss gesetzt sein)
* SVScustomPortHttp - benutzerdefinierter Port der Surveillance Station (HTTP) im DSM-Anwendungsportal (get mit "svsinfo")
* SVScustomPortHttps - benutzerdefinierter Port der Surveillance Station (HTTPS) im DSM-Anwendungsportal (get mit "svsinfo")
* SVSlicenseNumber - die Anzahl der installierten Kameralizenzen (get mit "svsinfo")
* SVSuserPriv - die effektiven Rechte des verwendeten Users nach dem Login (get mit "svsinfo")
* SVSversion - die Paketversion der installierten Surveillance Station (get mit "svsinfo")
* UsedSpaceMB - durch Aufnahmen der Kamera belegter Plattenplatz auf dem Volume
</pre>

 

== Attribute ==

* '''debugactivetoken''' - wenn gesetzt wird der Status des Active-Tokens gelogged - nur für Debuggung, nicht im normalen Betrieb benutzen

* '''httptimeout''' - Timeout-Wert für HTTP-Aufrufe zur Synology Surveillance Station, Default: 4 Sekunden (wenn httptimeout = "0" oder nicht gesetzt)

* '''htmlattr''' - ergänzende Angaben zur Livestream-Url um das Verhalten wie Bildgröße zu beeinflussen

* '''livestreamprefix''' - überschreibt die Angaben zu Protokoll, Servernamen und Port zur Weiterverwendung der Livestreamadresse als z.B. externer Link. Die Angabe muss in der Form "http(s)://<servername>:<port>" erfolgen.

* '''noQuotesForSID''' - dieses Attribut kann in bestimmten Fällen die Fehlermeldung "402 - permission denied" vermeiden und ein login ermöglichen. (normalerweise nicht zu setzen)

* '''pollcaminfoall''' - Intervall der automatischen Eigenschaftsabfrage (Polling) einer Kamera (kleiner 10: kein Polling, größer 10: Polling mit Intervall)

* '''pollnologging''' - 0 bzw. nicht gesetzt = Logging Gerätepolling aktiv (default), 1 = Logging Gerätepolling inaktiv

* '''rectime''' - festgelegte Aufnahmezeit wenn eine Aufnahme gestartet wird. Mit rectime = 0 wird eine Endlosaufnahme gestartet. Ist "rectime" nicht gesetzt, wird der Defaultwert von 15s verwendet.

* '''session''' - Auswahl der Login-Session. Nicht gesetzt oder "DSM" -> session wird mit DSM aufgebaut (Standard). "SurveillanceStation" -> Session-Aufbau erfolgt mit SVS

* '''simu_SVSversion''' - simuliert eine andere SVS-Version. NUR FÜR DEBUGGING, nicht im normalen Betrieb zu nutzen !

* '''showStmInfoFull''' - zusaätzliche Streaminformationen wie LiveStreamUrl, StmKeyUnicst, StmKeymjpegHttp werden ausgegeben

* '''verbose'''
<pre>
Es werden verschiedene Verbose-Level unterstützt.
Dies sind im Einzelnen:

0 - Start/Stop-Ereignisse werden geloggt
1 - Fehlermeldungen werden geloggt
2 - Meldungen über wichtige Ereignisse oder Alarme
3 - gesendete Kommandos werden geloggt
4 - gesendete und empfangene Daten werden geloggt
5 - alle Ausgaben zur Fehleranalyse werden geloggt. ACHTUNG: unter Umständen werden sehr viele Daten in das Logfile geschrieben!
</pre>

weitere Attribute:

* [http://fhem.de/commandref_DE.html#readingFnAttributes readingFnAttributes]

 

== Das Modul bzw. eine Gerätedefinition deaktivieren (ab Rev 11296) ==

Mit dem Attribut "disable" kann das Modul bzw. eine Gerätedefinition deaktiviert werden. Im Gegensatz zum Befehl "set ... disable" wird nicht die Kamera an sich deaktiviert, sondern lediglich das Gerätemodul. In diesem Fall werden keine Funktionen mehr ausgeführt.
Wird das Modul deaktiviert, werden die folgenden Readings gesetzt:

<pre>
state: inactive
Availability: ???
PollState: Inactive
</pre>

Ist für eine Kamera Polling aktiviert, wird diese Aktivität abgeschaltet. Nach Reaktivierung des Gerätemoduls wird das Polling automatisch wieder fortgesetzt.

 

== Lösungsbeispiele und Ansätze für verschiedene Aufgabenstellungen ==

=== Eine Übersicht mit Hilfe von readingsGroup ===

Mit den umfangreichen Möglichkeiten des Moduls [[readingsGroup]] kann ein FHEM-Widget nach eigenen Vorstellungen erstellt werden. Hierbei ist es möglich sowohl einen Überblick über die Status der Kameras zu erhalten als auch Steuerungsaktivitäten vorzusehen. Das nachfolgende Beipiel soll als Anregung dafür dienen. Weitere Informationen unter der [http://fhem.de/commandref.html#readingsGroup commandref] zu readingsGroup.

'''Hinweis:'''
Die folgenden Beispiele enthalten keine Maskierungen oder Verdopplungen für ; und Zeilenende, sondern sind so angegeben, wie sie im Web Interface im Befehls-Eingabefeld, nach Klick auf DEF und im Attribut-Eingabefeld eingegeben werden. Mehrere Leerzeichen innerhalb von < > sind als <code><&nbsp;&nbsp;&nbsp;></code> zu kodieren.

{| class="wikitable"
! Definition !! Erläuterungen
|-
| colspan=2 | [[Bild:RgSSCam.jpg|thumb|500px|links|Kamerastatus und Steuerung]]
|-
| style="width:50%" |<code>define Cams_All_States readingsGroup <%it_camera>,<Verfügbar>,< >,<Status>,< >,<Erkennung>,< >,<letzte Aufnahme>,< >,<bel. Platz (MB)>,< >,<letzte Aktualisierung>,< >,<Modul Deaktivierung>,< >,<Image> TYPE=SSCam:Availability,
<&nbsp;&nbsp;&nbsp;>,state,<&nbsp;&nbsp;&nbsp;>,CamMotDetSc,<&nbsp;&nbsp;&nbsp;>,CamLastRecTime,<&nbsp;&nbsp;&nbsp;>,UsedSpaceMB,
<&nbsp;&nbsp;&nbsp;>,LastUpdateTime,<&nbsp;&nbsp;&nbsp;>,?!disable,<&nbsp;&nbsp;&nbsp;>,<%Start>,<%Stop></code>
| ReadingsGoup anlegen.
|-
| <code>attr Cams_All_States valueIcon {'Availability.enabled' => 'remotecontrol/black_btn_GREEN',
'Availability.disabled' => 'remotecontrol/black_btn_RED',
'state.inactive' => 'StandBy',
'state' => '%devStateIcon'}</code>
| In Abhängigkeit vom Wert der Kameraverfügbarkeit und des state-Readings entsprechende Icons anzeigen. Wird das Modul deaktiviert, wird ein Standby-Icon angezeigt unabhängig davon ob in der Kameradefinition ein devStateIcon hinterlegt wurde.
|-
| <code>attr Cams_All_States valueStyle {if($READING eq "Availability" && $VALUE eq "enabled"){ ' style="color:green" ' }
elsif( $READING eq "Availability" && $VALUE eq "disabled"){ ' style="color:red" ' }
elsif( $READING eq "CamMotDetSc" && $VALUE =~ /SVS.*/ ){ ' style="color:orange" ' }
elsif( $READING eq "CamMotDetSc" && $VALUE eq "disabled"){ ' style="color:LimeGreen" ' }
elsif( $READING eq "CamMotDetSc" && $VALUE =~ /Cam.*/ ){ ' style="color:SandyBrown" ' }}</code>
| Farbgestaltung der Texte in Anhängigkeit der Werte setzen.
|-
| <code>attr Cams_All_States valueFormat {($READING eq "CamMotDetSc" && $VALUE eq "disabled") ? "external" : $VALUE}</code>
| Wenn die Quelle der Bewegungserkennung auf "disabled" gestellt wurde, soll "external" in der Übersicht angezeigt werden weil die Bewegungserkennung in dem Fall durch IR-Melder durchgeführt wird.
|-
| <code>attr Cams_All_States valueColumns { 'Image' => 'colspan="2"'}</code>
| Die Überschrift "Image" soll sich über die letzten zwei Spalten strecken. Es gilt sowohl für "Start" und "Stop" .
|-
| <code>attr Cams_All_States nameStyle style="color:black;font-weight:bold"</code>
| Die Überschriften sollen schwarz und fett sein.
|-
| <code>attr Cams_All_States commands { 'Availability.enabled' => 'set $DEVICE disable',
'Availability.disabled' => 'set $DEVICE enable',
'Cams_All_States.Start' => 'set %DEVICE runView image',
'Cams_All_States.Stop' => 'set %DEVICE stopView',
disable => "disable:"}</code>
| Es sollen Kommandos bestimmten Readings / Werten unterlegt werden. Zum Beispiel kann die Kamera mit Klick auf das Availability-Icon disabled werden wenn der Readingswert "enabled" ist. Der Livestream kann mit "Start" in der letzten Spalte gestartet, oder das Modul über eine Auswahl in der Drop-Down-Liste unterhalb von "Modul Deaktivierung" deaktiviert/aktiviert werden.
|-
| <code>attr Cams_All_States cellStyle { "c:0" => 'style="text-align:left;color:green;font-weight:normal"',
"c:5" => 'style="text-align:center;color:green;font-weight:normal"',
"c:9" => 'style="text-align:center;font-weight:normal"'}</code>
| Formatierung bestimmter Spalten (0,5,9).
|-
| <code>attr Cams_All_States alias Status aller Kameras</code>
| Alias setzen.
|-
| <code>attr Cams_All_States group Kamerastatus</code>
| Gruppenzugehörigkeit setzen. Wird auch für die Anzeige im Dashboard benutzt.
|}

 

=== Mail mit Snapshot im Anhang und Aufnahmelink versenden (sendemail) ===

Nachfolgendes Beispiel zeigt eine Möglichkeit in Linux mit dem Tool [http://caspian.dotconf.net/menu/Software/SendEmail/ sendemail] eine Mail mit einem Link zu einer Kameraaufnahme und bis zu drei Anhängen zu versenden. Das Tool ist in vielen Repositories erhalten und kann unter Debian (z.B. Ubuntu) installiert werden mittels <code>apt-get install sendemail libio-socket-ssl-perl</code>.
Die Mail wird mit einem DOIF Kommando in Abhängigkeit von einer angefertigten Aufnahme angestoßen.

Zunächst die Mailfunktion in der 99_myUtils als Unterroutinen einfügen. Die Funktion ist nicht blockierend (mit Modul Blocking.pm) ausgeführt. Die "\" dienen nachfolgend nur
zur Kennzeichnung eines Zeilenumbruchs - den Code bitte auf eine Zeile schreiben.

<source lang=perl>
# Am Anfang von 99_myUtils hinzufügen
use Blocking;

##############################################################################
######## DebianMail Mail versenden nonblocking ############
##############################################################################

sub DebianMailnbl {

my $rcpt = shift;
my $subject = shift;
my $text = shift;
my $attach = shift;
my $attach1 = shift;
my $attach2 = shift;
my $hash->{NAME_MAIL} = "Debianmail";
my $name = $hash->{NAME_MAIL};

if ($attach2) {
$hash->{helper}{RUNNING_PID} = BlockingCall("DebianMailnbl_send", $name."|".$rcpt."|".$subject."|".$text."|".$attach." \
|".$attach1."|".$attach2, "", "", "", "");
} elsif ($attach1) {
$hash->{helper}{RUNNING_PID} = BlockingCall("DebianMailnbl_send", $name."|".$rcpt."|".$subject."|".$text."|".$attach."|" \
.$attach1, "", "", "", "");
} else {
$hash->{helper}{RUNNING_PID} = BlockingCall("DebianMailnbl_send", $name."|".$rcpt."|".$subject."|".$text."|".$attach,
"", "", "", "");
}

}

######################################################
######## Mailfunktion nonblocking
######################################################

sub DebianMailnbl_send {
my ($string) = @_;
my ($name, $rcpt, $subject, $text, $attach, $attach1, $attach2) = split("\\|", $string);
my $ret = "";
my $sender = "<Sendername>\@<Domäne>";
my $konto = "<Mailkonto";
my $passwrd = "<Mailkontopasswort>";
my $provider = "<Mailserver>";

if ($attach2) {
$ret .= qx(sendEmail -f '$sender' -t '$rcpt' -u '$subject' -m '$text' -a '$attach' -a '$attach1' -a '$attach2' -s '$provider' \
-xu '$konto' -xp '$passwrd' -o tls=no -o message -charset=utf-8 -o message-content-type=text/plain );
} elsif ($attach1) {
$ret .= qx(sendEmail -f '$sender' -t '$rcpt' -u '$subject' -m '$text' -a '$attach' -a '$attach1' -s '$provider' -xu '$konto' \
-xp '$passwrd' -o tls=no -o message-charset=utf-8 -o message-content-type=text/plain );
} else {
$ret .= qx(sendEmail -f '$sender' -t '$rcpt' -u '$subject' -m '$text' -a '$attach' -s '$provider' -xu '$konto' -xp '$passwrd' \
-o tls=no -o message-charset=utf-8 -o message-content-type=text/plain );
}

# remove CR from return-string
$ret =~ s,[\r\n]*,,g;

Log3 $name, 3, "$name - sendEmail returned: $ret";
}
</source>

Um die TLS Verschlüsselung (ehem. SSL) zu nutzen, dann tls=auto verwenden.

Falls der Body-Text in einem (Android-)Mailer auf dem Handy nicht gezeigt wird, kann evtl. der Parameter '''-o message-content-type=html''' helfen.

 
==== Versand triggern - Beispiel mit DOIF ====
Der Mailversand wird in dem Beispiel mit einem DOIF angetriggert:

<pre>
define CamHE1.email DOIF ([CamHE1:"CamLastRec"]) ({DebianMailnbl ('<Empfänger>@<Domäne>','Bewegungsalarm CamHE1','Eine Bewegung wurde an der Haustür registriert.
Aufnahmelink: [CamHE1:VideoFolder]/[CamHE1:CamLastRec]','/media/sf_surveillance/@Snapshot/[CamHE1:LastSnapFilename]')})
</pre>

Wird eine Aufnahme der Kamera CamHE1 beendet, wird integriert der Befehl "get .. eventlist" ausgeführt. Dadurch aktualisiert sich das Reading "CamLastRec".
Dieser Event wird genutzt um eine Mail mit einem Link zur Aufnahme und einem während der Aufnahme angelegten Schnappschuß zu versenden.
Will man einen weiteren Anhang versenden, sähe das DOIF folgendermaßen aus:

<pre>
define CamHE1.email DOIF ([CamHE1:"CamLastRec"]) ({DebianMailnbl ('<Empfänger>@<Domäne>','Bewegungsalarm CamHE1','Eine Bewegung wurde an der Haustür registriert.
Aufnahmelink: [CamHE1:VideoFolder]/[CamHE1:CamLastRec]','/media/sf_surveillance/@Snapshot/[CamHE1:LastSnapFilename]','<weiteres File>')})
</pre>

Dss Reading "VideoFolder" muß, wie in dem Beispiel zu sehen, dem "CamLastRec" vorangestellt werden um den kompletten Pfad zur Aufnahme zu erhalten. Der versendete Link würde somit etwa den folgenden Aufbau haben:

<pre>
/volume1/surveillance/Carport/20160407PM/Carport20160407-221541-1460060141.mp4
</pre>

Wenn in einer Mail nach extern versendet wird, ist ein solcher Link wahrscheinlich über eine Anwendung nicht zugreifbar.
Um den Link dynamisch anzupassen und so den Zugriff von extern über z.B. einen Webserver zu ermöglichen, kann das Attribut "videofolderMap" verwendet werden.

Wird dieses Attribut auf zum Beispiel ...<pre>"http://<Server>:8083/fhem/svs/Carport/"</pre> ...gesetzt, ergibt sich folgender Link der in der Mail versendet wird:

<pre>
http://<Server>:8083/fhem/svs/Carport/20160407PM/Carport20160407-221541-1460060141.mp4
</pre>

In dem obigen Beispiel wird ein FHEM-Webserver verwendet, der zuvor über HTTPSRV (siehe Commandref) angelegt wurde,
WIe der Webserver angelegt werden kann ist [[SSCAM_-_Steuerung_von_Kameras_in_Synology_Surveillance_Station#Einsatz_FHEM_Webserver_zum_Zugriff_auf_Aufnahmen | hier]] beschrieben.

'''Hinweis:'''

Nach dem Snapshot wird implizit die Funktion "get ... snapfileinfo" aufgerufen. Diese Funktion trägt den neuen/letzten Snapfilename in das Reading "LastSnapFilename" ein.
Es ist somit sicherzustellen dass dieses Funktion abgeschlossen ist bevor die Aufnahme per Mail versendet werden soll. Das kann zum Beispiel mit einem Notify auf den Event "<Device>:LastSnapFilename.*" geschehen.
Sollten das Problem auftreten dass alte Snapshots versendet werden, ist aller Wahrscheinlichkeit nach in dem beschriebenen Sachverhalt die Ursache zu finden.

 

==== Versand triggern - Beispiel mit Notify ====

Mit diesem Notify wird das Snapshotfile angehängt und auch ein Link zu dem Snapshot mit eingefügt.

<pre>
define CamHE1.email NOTIFY CamHE1:LastSnapFilename.* {DebianMailnbl ('<Empfänger>@<Domäne>','Bewegungsalarm CamHE1',
'Eine Bewegung wurde an der Haustür registriert. Aufnahmelink: http://<Server>:8083/fhem/snap/'.(ReadingsVal("CamHE1","LastSnapFilename","")),
'/media/sf_surveillance/@Snapshot/'.(ReadingsVal("CamHE1","LastSnapFilename","")))}
</pre>

Um den Link in dieser Form aufrufen zu können ist erst ein HTTPSRV anzulegen mit:

<pre>
define snapweb HTTPSRV snap /media/sf_surveillance/@Snapshot SVS-Snapshots
</pre>

Natürlich muß dabei der Pfad "/media/sf_surveillance/" so angepasst werden dass er dem (gemounteten) SVS-Aufnahmeverzeichnis entspricht.

 

=== Einsatz eines Webservers zum Zugriff auf Aufnahmen ===

==== Nutzung des FHEM-internen HTTPSRV Plug-In ====

Ziel der nachfolgenden Beschreibung ist es, eine Möglichkeit darzustellen, um den FHEM Webserver für den Zugriff auf die Aufnahmen der Synology Surveillance Station zu nutzen.

Folgende Ausgangslage wird für das Beispiel als gegeben angenommen:

* der gemeinsame Ordner der Surveillance Station (normalerweise "surveillance") in der Diskstation ist am FHEM-Server gemountet. Für das Beipiel ist das gemountete Verzeichnis: /media/sf_surveillance
* FHEMWEB ist im Einsatz
* für das Beispiel ist eine Kamera CamHE1 (SVS-Name: Hauseingang) definiert

HTTPSRV ist ein Plug-in für FHEMWEB und stellt den Webserver für den Zugriff zur Verfügung. Diese Möglichkeit ist sicherlich für jene Fälle interessant bei denen der Zugriff über einen Verzeichnisdienst nicht möglich oder nicht gewünscht ist (zum Bespiel von extern).
Es steht auch eine Modul-interne Zugriffsmöglichkeit auf die letzte Aufnahme mit dem Befehl "set CamHE1 runView lastrec (oder lastrec_open)" zur Verfügung.

Der Webserver wird definiert mit:

define svsweb HTTPSRV svs /media/sf_surveillance WebServer SVS-Aufnahmen

Der definierte Webserver sollte nun links im Seitenmenü unter dem Namen "WebServer SVS-Aufnahmen" erscheinen. Ein Klick auf diesen Link sollte nun die Meldung zeigen:

File not found: /media/sf_surveillance/index.html

Die Datei index.html existiert natürlich normalerweise nicht im surveillance-Verzeichnis. Der Inhalt des Verzeichnisses "/media/sf_surveillance", also des surveillance-Stammordners, wird nun mit der Basisadresse ... <pre>http://<FHEM-Server>:8083/fhem/svs/</pre> ...erreicht.

Alle Aufnahmen der Kameras werden in Unterordnern des surveillance-Stammerzeichnisses gespeichert, die den gleichen Namen wie die Kamera in der Surveillance Station haben. Um den Pfad zu dem Aufnahmefile zu spezifizieren, ist die Basisadresse des erstellten Webservers mit dem Unterordner der entsprechenden Kamera zu ergänzen. Mit diesem zusammengesetzten Gesamtpfad ist ebenfalls das Reading "VideoFolder", welches den physikalischen Pfad von Aufnahmen der entsprechenden Kamera beschreibt, zu überschreiben.

Die wird mit dem Attribut "videofolderMap" erreicht. In dem Beispiel wird es gesetzt auf:

<pre>
attr CamHE1 videofolderMap http://<FHEM-Server>:8083/fhem/svs/Hauseingang/
</pre>

Jede Aufnahme der Kamera "Hauseingang" bzw. "CamHE1" wird somit durch die Webadresse ...

<pre>
http://<FHEM-Server>:8083/fhem/svs/Hauseingang/<Inhalt Reading CamLastRec>
</pre>

... erreicht.

Wie eine Mail mit diesem Link versendet werden kann ist [[SSCAM_-_Steuerung_von_Kameras_in_Synology_Surveillance_Station#Mail_mit_Snapshot_im_Anhang_und_Aufnahmelink_versenden_.28sendmail.29 | hier]] beschrieben.

Der komplette in der Mail versendete Aufnahmelink sieht folgendermaßen aus:
<pre>
http://<FHEM-Server>:8083/fhem/svs/Hauseingang//20160408PM/Hauseingang20160408-215150-1460145110.mp4
</pre>

 

==== Nutzung der Webstation auf Synology DS zum Zugriff auf Recordings ====

Da die Benutzung des HTTPSRV für diesen Zweck FHEM belastet bzw. blockiert, hat Martin Fischer im Forum unter:
https://forum.fhem.de/index.php/topic,45671.msg482616.html#msg482616

zwei Möglichkeiten bschrieben wie man den internen Webserver des Synology DS statt dessen verwenden kann (DSM 6).

Darauf aufbauend ist hier folgend die Umsetzung im DSM 5.2 beschrieben.

'''1. schnelle Variante A'''

Die nachfolgende Beschreibung bezieht sich auf DSM 5.2. Es wird ein virtueller Host (test.myds.me) definiert, der auf Port HTTP 8081 hört. Das Dokument-Root soll in dem Beispiel der Ordner "/volume1/web/fhemsvs" sein.

* Nach dem Login als root wechselt man in das web-Verzeichnis mit "cd /volume1/web"
* anlegen des Root-Verzeichnisses für den virtuellen Host und setzen der Berechtigungen:
mkdir fhemsvs
chown http:http fhemsvs
chmod 775 fhemsvs

* Link im Root-Verzeichnis zum SVS-Stammverzeichnis setzen:
ln -s /volume1/surveillance/ /volume1/web/fhemsvs

* einen virtuellen Host in Systemsteuerung -> Webdienste -> virtueller Host anlegen. Soll der Host von extern erreichbar sein, muß ebenfalls eine Registrierung des Hostnamens z.B. bei dem kostenfreien DNS-Dienst von Synology erfolgen sowie der verwendete Port im Router freigeschaltet werden.

[[Bild:vHost.PNG|left|thumb|300px|]] Der virtuelle Host ist durch die Angabe des Unterodners (fhemsvs), des Hostnamens (test.myds.me), des Protokolls und des Ports (8081) zu definieren. Die Angaben sind natürlichen den realen Werten anzupassen.

* die Recordings sind nun prinzipiell unter der Adresse erreichbar:
<pre>
http://test.myds.me:8081/surveillance/<Camname>/<Zeitordner>/<Dateiname>
</pre>

* in FHEM ist der Zugangspfad zu dem Aufnahmen zusammengesetzt aus den Readings "VideoFolder" (Original z.B. /volume1/surveillance/Carport) und "CamLastRec". Über das Attribut "videofolderMap" wird "/volume1/surveillance/Carport" nun ersetzt durch <pre>"http://test.myds.me:8081/surveillance/Carport/"</pre>

Der substituierte Aufnahmelink wird nun zu: (ReadingsVal("<camname>","VideoFolder","")).(ReadingsVal("<name>","CamLastRec",""))

* Der Versand des Aufnahmelinks per Mail kann durch ein Notify erfolgen:

define N.CamCP1.Rec.Email notify CamCP1:CamLastRec:.* {DebianMailnbl ('<Mailempfänger>','Bewegungsaufnahme Carport', 'Aufnahmelink: '.(ReadingsVal("CamCP1","VideoFolder","")).(ReadingsVal("CamCP1","CamLastRec",""))) }

Die Funktion DebianMailnbl für den Mailversand ist zuvor in 99_myUtils zu definieren. (siehe [[#Mail_mit_Snapshot_im_Anhang_und_Aufnahmelink_versenden_.28sendmail.29 | Mailversandroutine]] )

* Der Versand des Aufnahmelinks per TelegramBot kann durch folgendes Notify erfolgen:

define N.CamCP1.Rec.TeleBot notify CamCP1:CamLastRec:.* { my $var = (ReadingsVal("CamCP1","VideoFolder","")).(ReadingsVal("CamCP1","CamLastRec","")); fhem ("set teleBot message $var Bewegungsaufnahme beim Carport"); }

Natürlich ist TelegramBot vorab einzurichten. Der Versand erfolgt in dem Beispiel an den defaultPeer.

 

'''2. Variante B'''

(noch für DSM 5.2 zu beschreiben).

 

=== Workaround bei DSM 2-Stufen Verifizierung ===
1. Benutzer in der SVS einrichten, zum Manager machen 
2. Benutzer wird automatisch auch in FHEM eingerichtet, dort zum Admin machen 
3. 2-Stufen Verifizierung ausschalten 
4. Modul / Kamera zum Laufen bringen 
5. Session im Modul auf SVS stellen 
6. Benutzer in der DSM aus der Admin-Gruppe rausnehmen 
7. 2-Stufen Verifizierung einschalten (Option nur für Admins)

Pushbullet

2016-06-22T13:11:15Z

Motivierte linke Hände: Aufnahme Bildversand per Skript

'''Pushbullet''' ist ein Dienst, um Benachrichtigungen an unterschiedliche Endgeräte zu senden. Pushbullet stellt Apps für iPhone, Android, Windows (Beta), Mac OS X (bald erhältlich) sowie Plugins für Chrome und Firefox an. Eine genaue Liste kann [http://www.pushbullet.com/apps hier] eingesehen werden. Der Dienst sowie die Apps sind kostenlos.
{{Infobox Modul
|ModPurpose=Senden von Push-Nachrichten an unterschiedliche Endgeräte
|ModType=d
|ModForumArea=Unterstützende Dienste
|ModTechName=70_Pushbullet.pm
|ModOwner=fhainz
}}

==Installation==

Zur Benutzung von Pushbullet ist ein Google Account zwingend notwenig. Falls noch kein Google Account vorhanden ist kann man diesen [https://accounts.google.com/SignUp hier einrichten]. Anschließend kann man sich auf [http://pushbullet.com pushbullet.com] mit den Google Benutzerdaten einloggen. Den benötigten accessToken findet man in den Account Settings (rechts oben auf das Benutzer-Symbol klicken).
Auf dem gewünschten Endgerät muss nur noch der entsprechende Client installiert werden.

===Offizielle Clients===

'''Smartphones'''
*iOS: [https://www.pushbullet.com/apps Pushbullet App]
*Android: [https://www.pushbullet.com/apps Pushbullet App]

'''Browser-Erweiterungen'''
*Firefox: [https://www.pushbullet.com/apps Pushbullet Plugin]
*Chrome: [https://www.pushbullet.com/apps Pushbullet Plugin]
*Opera: [https://www.pushbullet.com/apps Pushbullet Plugin]
*Safari: [https://www.pushbullet.com/apps Pushbullet Plugin]

'''Betriebssystem-Erweiterungen'''
*Windows: [https://www.pushbullet.com/apps Pushbullet App]
*Mac OS X: [https://www.pushbullet.com/apps Pushbullet App]

===Clients durch die Community===
*Blackberry: [https://www.pushbullet.com/apps BlackBullet]
*Windows Phone: [https://www.pushbullet.com/apps PushPin]
*Ubuntu: [https://www.pushbullet.com/apps PB Indicator]

Übersicht aller Clients: [https://www.pushbullet.com/apps]

==Einbinden des Dienstes in Fhem==

Das Modul wird mit dem folgenden Befehl in fhem definiert:

define <name> Pushbullet <accessToken>

==Push Benachrichtigung senden==

===Nachricht===

Nachricht ohne Titel oder Gerät:
set <name> message Das ist eine Nachricht

Nachricht mit Titel ohne Gerät:
set <name> message Das ist eine Nachricht | Ein Titel

Nachricht mit Titel an Gerät iPhone:
set <name> message Das ist eine Nachricht | Ein Titel | iPhone

Nachricht mit Titel an Kontakt Max Mustermann
set <name> message Das ist eine Nachricht | Ein Titel | Max Mustermann

Wenn kein Titel angegeben wird tritt das Attribut defaultTitel in Kraft. Falls dies nicht gesetzt ist wird der Titel auf FHEM gesetzt.
Wenn kein Device angeben wird tritt das Attribut defaultDevice in Kraft. Falls dies nicht gesetzt ist geht der Push an alle '''deine''' Devices. Kontakte erhalten die Benachrichtigung '''nicht!'''

===Link===
Der Inhalt des Links wird in der App direkt angezeigt. Ein Webcam Foto kann somit mit einem Touch direkt am Endgerät angezeigt werden.

Link ohne Titel oder Gerät:
set <name> link http://google.com

Link mit Titel ohne Gerät:
set <name> link http://google.com | Google

Link mit Titel an Gerät iPhone
set <name> link http://google.com | Google | iPhone

Link mit Titel an Kontakt Max Mustermann
set <name> link http://google.com | Google | MaxMustermann

*Wenn kein Titel angegeben wird tritt das Attribut defaultTitel in Kraft. Falls dies nicht gesetzt ist wird der Titel auf FHEM gesetzt.
*Wenn kein Device angeben wird tritt das Attribut defaultDevice in Kraft. Falls dies nicht gesetzt ist geht der Push an alle '''deine''' Devices. Kontakte erhalten die Benachrichtigung '''nicht!'''

===Liste===

Liste ohne Titel oder Gerät:
set <name> list Milch, Brot, Zucker

Liste mit Titel ohne Gerät:
set <name> list Milch, Brot, Zucker | Einkaufsliste

Liste mit Titel an Gerät iPhone
set <name> list Milch, Brot, Zucker | Einkaufsliste | iPhone

Liste mit Titel an Kontakt Max Mustermann
set <name> list Milch, Brot, Zucker | Einkaufsliste | MaxMustermann

*Wenn kein Titel angegeben wird tritt das Attribut defaultTitel in Kraft. Falls dies nicht gesetzt ist wird der Titel auf FHEM gesetzt.
*Wenn kein Device angeben wird tritt das Attribut defaultDevice in Kraft. Falls dies nicht gesetzt ist geht der Push an alle '''deine''' Devices. Kontakte erhalten die Benachrichtigung '''nicht!'''

===Bilder versenden===
Das geht über ein (von User stkr002 erstelltes) externes Skript, das im Bedarfsfall aus FHEM aufgerufen werden muss:
<pre>#!/usr/bin/perl -w
use WWW::PushBullet;
$KEY = 'XXXXXXXXXXXXXXXXXXXXXXX';
$pb = WWW::PushBullet->new({apikey => $KEY});
$filename = '/opt/fhem/snapshot/ipcam_snapshot.jpg';
$pb->push_file({ file_name => $filename});</pre>

Aufrufen kann man das Skript z.B. über Perl-Code aus FHEM:

my $befehl = "/home/user/script";
my $ausgabe = `$befehl`;

Wenn man keinen festen Dateinamen und Key verwenden möchte, sondern unterschiedliche Dateien an unterschiedliche Empfänger schicken möchte, muss das oben gepostete Skript die Auswertung von Kommandozeilenparametern mit eingebaut werden:

my $argument = shift @ARGV;
my $noch_ein_argument = shift @ARGV;

etc.

==Kontakt hinzufügen==
Mit
set <name> contactAdd <Name> | <email>
wird eine neuer Kontakt hinzugefügt. Dieser bekommt erstmal eine E-Mail mit einer Einladung zur Pushbullet App. Fall die App nicht installiert wird, bekommt der Kontakt Push-Benachrichtigungen als E-Mail zugestellt.

==Gerät / Kontakt umbenennen==
Mit
set <name> deviceRename <alterName> | <neuerName>
wird ein Gerät oder Kontakt umbenannt.

==Gerät / Kontakt löschen==
Mit
set <name> deviceDelete <name>
wird ein Gerät oder Kontakt gelöscht.

==Geräte / Kontakte neu einlesen==
Mit
get <name> devices
kann man die Device Liste von pushbullet.com neu einlesen.

==Pushbullet Website==
Die Pushbullet Website bietet umfangreiche Möglichkeiten die gesendeten Push Nachrichten, Geräte und Kontakte zu verwalten. Weiters kann man auch Nachrichten versenden und löschen.

==Bekannte Probleme==
===Cannot load module Pushbullet===

Bei einigen Installationen kommt es beim Start zu folgender Fehlermeldung:

<pre>Error messages while initializing FHEM:
configfile: Cannot load module Pushbullet
Cannot load module Pushbullet</pre>

Abhilfe schafft in der Regel, JSON zu installieren. Zum Beispiel auf dem Raspberry:

<pre>sudo apt-get install libjson-perl</pre>

===Nachrichten von fhem werden nicht verschickt===

Nachrichten von http://www.pushbullet.com/ kommen jedoch auf dem Telephon an. Sicherstellen, daß das perl IO:Socket:SSL Modul installiert ist:

<pre>sudo apt-get install libio-socket-ssl-perl</pre>

==Links==
*Thread über das Modul im [http://forum.fhem.de/index.php/topic,29796.0.html FHEM-Forum]
*Pushbullet [https://www.pushbullet.com/apps Apps]
*Pushbullet [https://docs.pushbullet.com API]
*Homepage: [http://pushbullet.com pushbullet.com]

[[Kategorie: Code Snippets]]

GDS

2016-05-02T14:34:31Z

Motivierte linke Hände: Anpassungen an neue Version des GDS-Moduls

{{Infobox Modul
|ModPurpose=Herunterladen und Auswerten von Daten des Deutschen Wetterdienstes
|ModType=d
|ModForumArea=Unterstuetzende Dienste
|ModFTopic=14106
|ModTechName=55_GDS.pm
|ModOwner=betateilchen
}}
[[GDS]] ist ein Modul, mit dessen Hilfe man sich die Daten des Deutschen Wetterdienstes herunterladen kann und dann Wetterlage, diverse Wetterkarten und/oder Unwettermeldungen anzeigen/auswerten kann.

== Voraussetzungen ==
=== Anmeldung beim DWD ===
Als erstes muss man sich beim Deutschen Wetterdienst zur [http://www.dwd.de/grundversorgung Grundversorgung] kostenlos [http://kunden.dwd.de/gdsRegistration/gdsRegistrationStart.do anmelden].

=== Installation der benötigten Perl-Module ===
GDS benötigt die Perl-Module Net::FTP, List::MoreUtils, XML::Simple, Text::CSV.

Für Ubuntu und Raspi sollte funktionieren:

<code>apt-get install libnet-lite-ftp-perl liblist-moreutils-perl libxml-simple-perl libtext-csv-perl</code>

Das ftp-Modul verursacht manchmal Probleme bei der Installation. Teilweise ist es wohl auch schon in der Grundinstallation vorhanden, ansonsten kann man versuchen:

<code>apt-get install libnet-ftp-perl</code>

oder

<code>apt-get install libwww-perl</code>

Abhängig von der Perl-Version muss ggf. auch noch Archive::Zip installiert werden.

== Anwendung ==
=== Define ===
<code>define [gdsName] GDS [gdsUsername] [gdsPasswort]</code>

[gdsUsername] und [gdsPasswort] gibt es nach Anmeldung vom DWD.

=== Attribute ===
Die vollständige Liste der Attribute ist in der [http://fhem.de/commandref.html#GDS commandref].

Hilfreich kann u.a. sein, wenn man hinter eine Firewall sitzt und der Datenabruf nicht funktioniert:

<code>attr [gdsName] gdsPassiveFtp 1</code>

== Anwendung ==
=== Liste der verfügbaren Zellen für Warnungen abrufen ===
<code>get [gdsName] list capstations</code>

=== Manuelle Aktualisierung der Daten ===

==== Aktuelle Daten vom Server abrufen ====
<code>get [gdsName] rereadcfg</code>

==== Readings aus abgerufenen Daten aktualisieren ====
<code>set [gdsName] update</code>

=== Station setzen für automatischen, periodischen Abruf ===
Station setzen, für die beim fhem-Start und dann alle 20 Minuten die Vorhersagedaten eingelesen werden sollen:

<code>set [gdsName] forecasts [Station]</code>

Automatisch abgerufen (alle 20 Minuten) werden nur die mit fc_ beginnenden Readings (forecast, d.h. die Vorhersage). Die a_ Readings (Warnungen, etc.) müssen manuell aktualisiert werden.

=== Unwetterwarnungen nach Region aus gelesenen Daten raussuchen ===
<code>set [gdsName] warnings [Region]</code>

z.B.: <code>set gds warn Nordrhein-Westfalen</code>

Die Region kann ausgeschrieben oder mit den [http://www.bmelv-statistik.de/de/daten-tabellen-suche/abkuerzungen-der-bundeslaender/ offiziellen Abkürzungen] bezeichnet werden.

=== Unwetterwarnungen granularer nach Kreis aus gelesenenen Daten raussuchen ===
<code>set [gdsName] alerts [Warncell-ID]</code>

Die passende Warncell-ID kann man sich über <code>get [gdsName] list capstations</code> heraussuchen.

Ob es passende Warnmeldungen gibt, kann dann über das Reading <code>a_valid</code> abgefragt werden. Wenn <code>a_valid</code> 1 ist, gibt <code>a_count</code> die Anzahl der vorhandenen Warnmeldungen an. Die Warnungen stehen dann in den Readings <code>a_X_...</code>, wobei X ab 0 hochzählt. D.h. wenn <code>a_count</code> 2 ist, gibt es a_0_... und a_1_... Ein praktisches Reading ist z.B. <code>a_X_headline</code>, das die Zusammenfassung der jeweiligen Warnung als kurze Textzusammenfassung enthält.

Alle eingelesenen Warnmeldungen kann man sich über die Funktion <code>gdsHeadlines()</code> ausgeben lassen. Z.B. einfach in der Befehlszeile von fhem eingeben:

<code>{gdsHeadlines([gdsName])}</code>

Wer möchte, kann auch das Trennzeichen bei mehreren Meldungen konfigurieren:

<code>{gdsHeadlines([gdsName],'[Trennzeichen]')}</code>

Z.B. also

<code>{gdsHeadlines(gds, '***')}</code>

Standard für das Trennzeichen ist der senkrechte Strich.

Jedenfalls nach <code>attr [gdsName] gdsLong 1</code> werden in a_X_description die Langmeldungen zu den Warnungen ausgegeben.

=== Karten abrufen ===
Wetterlage: <code>get [gdsName] conditionsmap [Station] </code>

Vorhersage: <code>get [gdsName] forecastsmap [Station]</code>

Warnungen: <code>get [gdsName] warningsmap [Station]</code>

Radar: <code>get [gdsName] radarmap [Station]</code>

== Anwendungsbeispiele ==

Für GDS sollten die Daten regelmäßig aktualisiert werden. Dafür richtet man am besten '''zwei''' zeitlich '''nacheinander''' laufende ats ein:

Einen zum Holen aktualisierter Daten vom Server:

<pre>
define readGDS at +*00:10:00 get [gdsName] rereadcfg
attr readGDS alignTime 22:30:05
</pre>

Einen zweiten, der danach läuft, der aus den aktualisierten Serverdaten dann die Readings aktualisiert; z.B. für die Alerts:

<pre>
define checkGDS at +*00:10:00 get [gdsName] alerts [Region]
attr checkGDS alignTime 22:35:05
</pre>

Wichtig ist, dass beide at zeitlich auseinander liegen, im vorstehenden Beispiel durch die unterschiedlichen "alignTime" Attribute um 5 Minuten.

=== Karten regelmäßig vom Server neu laden ===

<code>define Karten at +*00:30:00 get [gdsName] radarmap Nordost; get [gdsName] conditionsmap Nordost; get [gdsName] warningsmap Berlin</code>

Hinweis: Die vorstehende Schreibweise ist die Schreibweise im Editiermodus der Weboberfläche von fhem. Wer die Zeile per copy & paste direkt in die Kommandozeile eintragen will, muss die Semikolons verdoppeln, sonst geht alles nach dem ersten Semikolon verloren.

Also:

<code>define Karten at +*00:30:00 get [gdsName] radarmap Nordost;; get [gdsName] conditionsmap Nordost;; get [gdsName] warningsmap Berlin</code>

== Bekannte Probleme ==
Das GDS-Modul wurde mittlerweile auf "non-blocking" umgeschrieben, führt aber dennoch hin und wieder zu Meldungen einzelner Nutzer, dass FHEM "einfriert" (nichts macht), während auf die Rückmeldung von, z. B., einem FTP-Transfer ("get [gdsName] conditionsmap" etc.) gewartet wird. Das kann bei Timing-kritischen Bestandteilen zu Problemen führen, weil Events nicht mitbekommen werden, die Ansteuerung von Geräten nicht funktioniert, etc.

Einige dieser FHEM blockierenden Aktivitäten lassen sich mittels cron recht einfach auslagern (z. B. der ftp Transfer), für andere müsste das GDS-Modul umgeschrieben werden. Details dazu gibt es z. B. in [http://forum.fhem.de/index.php/topic,38106.0.html diesem schon etwas älteren Thread] im Forum.

Nachfolgend noch eine Möglichkeit, das regelmäßige Laden der Karten vom Server in einen - dann FHEM nicht mehr blockierenden - cron-Job auszulagern:

Was Ihr wissen müsst:
*Wo legt das GDS-Modul die Karten ab? Z. B. im Temporär-Verzeichnis, /tmp. Wenn Ihr eine radarmap gespeichert habt, findet Ihr den Speicherort recht einfach, indem Ihr unter Linux <code>cd / && find . | grep gds_radarmap.jpg</code> ausführt.
*Wo liegen die Karten auf dem DWD-ftp-Server? Die Adresse des Servers ist [ftp://ftp-outgoing2.dwd.de ftp://ftp-outgoing2.dwd.de] und die Karten findet Ihr unterhalb von [ftp://ftp-outgoing2.dwd.de/gds/specials/ ftp://ftp-outgoing2.dwd.de/gds/specials/], z. B. die conditions maps unter [ftp://ftp-outgoing2.dwd.de/gds/specials/observations/maps/germany/ ftp://ftp-outgoing2.dwd.de/gds/specials/observations/maps/germany/], radarmaps unter [ftp://ftp-outgoing2.dwd.de/gds/specials/radar/ ftp://ftp-outgoing2.dwd.de/gds/specials/radar/] und dann dem passenden Unterverzeichnis für Eure Region, etc.
*Eure Login-Daten für den DWD ftp-server (habt Ihr vom DWD zugeschickt bekommen und in die Definition des GDS-Moduls eingetragen).

Anbei ein Beispielscript, das jeweils die neueste conditions- und Radarmap für Südwest-Deutschland holt und im /tmp-Verzeichnis ablegt:
<pre>
#!/bin/bash
if [ ! -d "/tmp/gds" ]; then
mkdir /tmp/gds
fi
# ftp-Server als Verzeichnis mounten:
curlftpfs ftp-outgoing2.dwd.de /tmp/gds -o user=user:pass
cd /tmp/gds/gds/specials/radar/southwest
NEUESTE_DATEI=$(ls -t | head -n 1)
echo Downloading ${NEUESTE_DATEI}...
cp "${NEUESTE_DATEI}" "/tmp/gds_radarmap.jpg"
echo ok.
chown fhem:dialout /tmp/gds_radarmap.jpg
cd /tmp/gds/gds/specials/observations/maps/germany
NEUESTE_DATEI=$(ls -t Suedwest* | head -n 1)
echo Downloading ${NEUESTE_DATEI}...
cp "${NEUESTE_DATEI}" "/tmp/gds_conditionsmap.jpg"
echo ok.
chown fhem:dialout /tmp/gds_conditionsmap.jpg
# unmount
fusermount -u /tmp/gds
</pre>

Hinweise:
*user:pass durch Eure Login-Daten für den Server ersetzen.
*/tmp ggf. anpassen, wenn bei Euch die GDS-Karten in einem anderen Verzeichnis liegen.
*"Suedwest" durch Eure Region ersetzen. Dateinamen können auf dem ftp-Server eingesehen werden.
*Die Angabe von user:pass im Klartext im Script ist unsicher. Sicherer wäre die Angabe einer versteckten und in den Rechten beschränkten Konfigurationsdatei.
*fhem:dialout sind die Rechte unter Debian. Mit einem <code>li -l</code> im Verzeichnis, in dem GDS die Karten ablegt, könnt Ihr Euch - vor dem Ausführen des Scripts - den Benutzer und die Rechte ansehen, wie das GDS-Modul bei Euch die Karten ablegt.
*Das Script braucht curlftpfs, das sich i.d.R. problemlos mittels <code>apt-get install curlftpfs</code> (Debian) o.ä. installieren lassen sollte.

Dann das Script noch regelmäßig über cron ausführen lassen, und schon blockiert Euer FHEM an einer Stelle weniger.

== Links ==
* [[Wetter und Wettervorhersagen]]

Calendar

2016-04-05T15:26:59Z

Motivierte linke Hände: Beta-Hinweis entfernt, Tipp zu ownCloud-Kalender aufgenommen

{{Infobox Modul
|ModPurpose=Anlegen eines Kalenderobjekts
|ModType=h
|ModForumArea=Unterstützende Dienste
|ModTechName=57_Calendar.pm
|ModOwner=borisneubert ({{Link2FU|10|Dr. Boris Neubert}})
}}

[[Calendar]] ist ein Hilfsmodul, das Kalenderereignisse aus einer Datei oder einem über die URL angegeben Kalender holt. Der Kalender muss im iCal-Format vorliegen.

Zur Anzeige der Kalenderereignisse kann das Modul [[CALVIEW]] verwendet werden.

== Voraussetzungen ==
Wenn die Kalender-URL mit ''https://'' beginnt, muss das Perl Modul IO::Socket::SSL installiert sein (z.B. mit <code>cpan -i IO::Socket::SSL</code> oder mit <code>apt-get install libio-socket-ssl-perl</code>).

== Anwendung ==
=== Define ===
Siehe commandref;
:<code>define <name> Calendar ical url <URL> [<interval>]</code>
:<code>define <name> Calendar ical file <FILENAME> [<interval>]</code>

Sofern für den Zugriff auf den Kalender Benutzername und Passwort erforderlich sind, können diese in der URL beispielsweise so mit angegeben werden:
:<code>define myCalendar ical url <nowiki>https://user:password@my.domain.com/.../yourcalendar.ics</nowiki></code>

=== Attribute ===
Siehe commandref;

== Anwendungsbeispiel(e) ==
* Einbindung von owncloud-Kalendern
Für ownCloud-Kalender muss bei der Definition als <URL> der Link zum Export des jeweiligen Kalenders angegeben werden. Der Link kann in der Weboberfläche von ownCloud gefunden werden. Für ownCloud 9.0 folgt dieser URL z.B. dem folgenden Muster:
:<code>http://<ownCloud-Benutzer>:<ownCloud-Passwort>@example.com/owncloud/remote.php/dav/calendars/<ownCloud-Benutzer>/<Kalendername>?export</code>
Der Standard für <Kalendername> ist <code>defaultcalendar</code>
* [[Google-Kalender zur Steuerung von Dummies]]
* [[Wochenende, Feiertage und Schulferien]]

== Links ==
* Modul, das alle Termine aus einer bestehenden Instanz von [[Calendar]] in Readings übernimmt: [[CALVIEW]]

Google-Kalender zur Steuerung von Dummies

2016-02-09T08:55:44Z

Motivierte linke Hände: Anpassung der Syntax an neue Version von Calendar

Mit dem Kalendermodul [http://fhem.de/commandref.html Calendar] ist es möglich, Ereignisse aus Kalendern im
ICal-Format abzufragen.
Dies und der Wiki-Eintrag [[Wochenende, Feiertage und Schulferien]] hat mich dazu veranlasst, dass ich durch
Kalendereinträge im Google-Kalender den Status meiner beiden [[dummy|Dummies]] "Urlaub" und "Besuch" steuere. Durch diese
beiden Dummies werden zum Beispiel die Rolläden im Schlafzimmer oder Gästezimmer bei Besuch oder Urlaub anders
gesteuert als ohne Besuch oder unter der Woche. Auch meine Zirkulationspumpe soll so bedarfsgerecht gesteuert werden.
Dass am Wochenende anders gesteuert wird, ist ja mit $we kein Problem.
Zuerst wird dafür der Kalender definiert:

define Kalender_Christian Calendar ical url <der richtige Kalenderlink> 14400

Den Kalenderlink [https://support.google.com/calendar/answer/37103?hl=de] findet man wie beschrieben heraus.
Dann habe ich meine Dummies definiert:

define Urlaub_dummy dummy
attr Urlaub_dummy room Kalender
attr Urlaub_dummy setList ja nein
attr Urlaub_dummy webCmd ja:nein
define Gast_dummy dummy
attr Gast_dummy room Kalender
attr Gast_dummy setList ja nein
attr Gast_dummy webCmd ja:nein

Und nun mussten die Notifys definiert werden, um bei entsprechenden Einträgen im Google-Kalender den Status der
Dummies zu setzen.

define Kalender_Christian_Start notify Kalender_Christian:modeStarted.*googlecom.* {\
Kalenderstart("$EVENT");;\
}
define Kalender_Christian_Ende notify Kalender_Christian:modeEnded.*googlecom.* {\
Kalenderende("$EVENT");;\
}

Um nicht für verschiedene Dummies immer einzelne Notifys zu bauen, wird hier bei mir je eine Funktion aus meiner [[99 myUtils anlegen|99_MyUtils.pm]] aufgerufen und das Event als Parameter übergeben. Die beiden zugehörigen
Funktionen für den Start und das Ende des Kalenderevents schauen so aus:
<source lang="perl">
sub
Kalenderstart ($)
{
my ($Ereignis) = @_;
my @Ereignisarray = split(/.*:\s/,$Ereignis);
my $Ereignisteil1 = $Ereignisarray[1];
my @uids = split(/;/,$Ereignisteil1);
foreach my $uid (@uids) {
my $Kalendertext = fhem("get Kalender_Christian summary uid=$uid 1");
if ($Kalendertext =~ /Urlaub/) {
fhem("set Urlaub_dummy ja");
}
if ($Kalendertext =~ /Besuch/) {
fhem("set Gast_dummy ja");
}
}
}
sub Kalenderende ($) {
my ($Ereignis) = @_;
my @Ereignisarray = split(/.*:\s/,$Ereignis);
my $Ereignisteil1 = $Ereignisarray[1];
my @uids = split(/;/,$Ereignisteil1);
foreach my $uid (@uids) {
my $Kalendertext = fhem("get Kalender_Christian summary uid=$uid 1");
if ($Kalendertext =~ /Urlaub/) {
fhem("set Urlaub_dummy nein");
}
if ($Kalendertext =~ /Besuch/) {
fhem("set Gast_dummy nein");
}
}
}
</source>

Zur Erläuterung: Als Ereignis wird z.B. "''modeStarted: 9aas2amo7td47th4sf7mlocl48googlecom''" oder bei 2 gleichzeitigen
Ereignissen: "''modeStarted: arqpe2a2snu6qn64dt0men7nd0googlecom;j0pjiupfb1sk3m5s64hbeo6880googlecom''"
übergeben. Da uns aber nur die eindeutige UID interessiert, wird das Ereignis beim Vorkommen der Zeichen ": Leerzeichen"
also nach modeStarted: geteilt (<code>split(/.*:\s/,$Ereignis)</code>). Die beiden Teile werden in ein Array (<code>@Ereignisarray</code>) gespeichert.
Und als 2. Element in dem Array ist nun die uns interessierende UID (<code>$Ereignisarray[1]</code>) vorhanden, mit welcher wir weiter
arbeiten. Da auch mit dem Fall mehrerer gleichzeitiger Ereignisse umgegangen werden können soll, müssen wir bei mehreren
UIDs diese wieder splitten. Diesmal beim Vorkommen des Semikolons als Trennzeichen (<code>split(/;/,$Ereignisteil1)</code>). Auch die
UIDs werden wieder in einem Array gespeichert und dann mittels der foreach-Schleife nacheinander abgearbeitet. Und
hierbei wird abhängig von der mittels UID abgerufenen Kalenderbeschreibung (<code>fhem("get Kalender_Christian summary
uid=$uid 1")</code>) ein Vergleich auf die Werte "Besuch" oder "Urlaub" durchgeführt (<code>if ($Kalendertext =~ /Urlaub/)</code>) und davon
abhängig der Dummy-Status gesetzt.
Abhängig von diesen Dummies reagiert dann meine Rollosteuerung.

[[Kategorie:Code Snippets]]

Apache Authentication Proxy

2016-01-08T14:15:34Z

Motivierte linke Hände: Tipps zur Beseitigung weiterer Hürden aufgenommen, Config ergänzt

== Konfiguration ==

Um den Zugriff auf FHEMWEB etwas sicherer zu machen, kann man den Webzugriff über einen Apachen laufen lassen. Dies ist ein kurzes Rezept, um Zugriffe auf FHEMWEB über einen Apachen authentifizieren zu lassen. Erstellt wurde es auf Debian Squeeze, sollte aber auch mit Ubuntu funktionieren.

<nowiki>apt-get install apache2 libapache2-mod-proxy-html</nowiki>

Step 1) FHEMWEB sollte nur noch auf dem Loopback lauschen, also kein 'global' Attribut in der Definition in fhem.cfg

<nowiki>define WEBS FHEMWEB 8084</nowiki>

Step 2) die folgenden Apache2 Module müssen aktiviert sein: mod_proxy + mod_proxy_http

<nowiki>a2enmod proxy
a2enmod proxy_http</nowiki>

Step 3) neue Datei /etc/apache2/conf.d/fhem:

Diese Konfiguration sorgt dafür, dass alle Anfragen unter /fhem weiter nach [http://localhost/fhem http://localhost/fhem] geleitet werden. Zusätzlich wird eine Basic-Authentifizierung eingeschaltet. Die Benutzerdatenbank ist dann in /etc/fhem-htpasswd zu finden.

<nowiki><Location /fhem>
# ProxyPass/ProxyPassReverse leitet HTTP requests auf eine andere URL um
ProxyPass http://localhost:8084/fhem
ProxyPassReverse http://localhost:8084/fhem
ProxyHTMLEnable On
# ProxyHTMLURLMap passt Links im HTML/JavaScript Source an
ProxyHTMLURLMap / /fhem/
ProxyHTMLURLMap /fhem/ /fhem/
AuthType Basic
AuthName "Password Required"
AuthUserFile /etc/fhem-htpasswd
Require valid-user
Order deny,allow
Allow from all
</Location></nowiki>

Step 4) Benutzer-Datenbank in /etc/fhem-htpasswd anlegen

<nowiki># -c -> create file
# -s SHA encryption
htpasswd -c -s /etc/fhem-htpasswd <username>
# add more users with
htpasswd -s /etc/fhem-htpasswd <username></nowiki>

Step 5) Apache neu starten

<nowiki>invoke-rc.d apache2 reload</nowiki>

bzw.

<nowiki>service apache2 reload</nowiki>

Fertig. FHEM ist jetzt über http://server/fhem erreichbar. Alle Zugriffe müssen aber erst mit Benutzername + Passwort freigeschaltet werden.

== Hinweis zu Apache 2.4 ==
Es muss zusätzlich das Modul '''proxy_html''' aktiviert werden (<code>a2enmod proxy_html</code>).
Und die zu erstellende Config-Datei muss jetzt nach ''/etc/apache2/conf-available/fhem.conf'' (statt /etc/apache2/conf.d/fhem).

== Mögliche Probleme ==

=== Invalid command 'ProxyHTMLURLMap' ===
Falls nach dem Neustart des Apache folgende Fehlermeldung kommt:

<nowiki>Invalid command 'ProxyHTMLURLMap', perhaps misspelled or defined by a module not included in the server configuration
Action 'configtest' failed.
The Apache error log may have more information.</nowiki>

fehlt das Paket libapache2-mod-proxy-html. Einfach mit

<nowiki>apt-get install libapache2-mod-proxy-html</nowiki>

nachinstallieren.

=== ProxyHTMLURLMap funktioniert nicht ===

Nicht bei allen Distributionen scheint die Konfigurationsdatei proxy_html.conf mitgeliefert zu werden. Allerdings ist seit einigen Versionen aus mod_proxy_ssl alle Information über zu ersetzende Links etc. entfernt worden. proxy_html.conf wird daher zwingend benötigt. Sie sollte in /etc/apache2/mods-available liegen und bei der Aktivierung des mods nach /etc/apache2/mods-enabled verlinkt werden. Wenn das nicht der Fall ist, kann man das nachholen.

Eine Beispielkonfiguration gibt es [http://apache.webthing.com/svn/apache/filters/proxy_html/proxy_html.conf hier beim ursprünglichen Autor des mods]. Abspeichern unter /etc/apache2/mods-available/proxy_html.conf und dann verlinken:

<pre>ln -s /etc/apache2/mods-available/proxy_html.conf /etc/apache2/mods-enabled/proxy_html.conf</pre>

Dann Apache neu starten/laden.

=== Content Encoding Fehler ===

Wenn Firefox und Chromium sich nach der Konfigurationsänderung über Content Encoding Fehler beschweren, könnte Folgendes helfen:

<pre>SetOutputFilter INFLATE;proxy-html;DEFLATE</pre>

[[Kategorie:HOWTOS]]

Harmony

2015-12-27T08:08:45Z

Motivierte linke Hände: Typos, freeze bei Nichterreichbarkeit des Hubs

{{SEITENTITEL:harmoony}}
{{Infobox Modul
|ModPurpose=Anbindung Logitech Harmony Hub basierter Fernbedienungen
|ModType=d
|ModCmdRef=harmony
|ModForumArea=Multimedia
|ModTechName=37_harmony.pm
|ModOwner=Andre ([http://forum.fhem.de/index.php?action=profile;u=430 Forum] / [[Benutzer Diskussion:justme|Wiki]])}}

Das Fhem-[[:Kategorie:Gerätemodul|Gerätemodul]] [[harmony]] bietet die Möglichkeit Logitech Harmony Hub basierte Fernbedienungen an Fhem anzubinden und so von Fhem aus Aktivitäten zu starten und zu stoppen, in Fhem auf das Starten und Stoppen von Aktivitäten über eine der mit dem Hub verbundenen Fernbedienungen zu reagieren oder auf Geräteebene jedes im Hub konfigurierte Gerät über IR, Bluetooth und/oder einen Smart Keyboard USB Dongle zu steuern.

Unterstützt werden zur Zeit die Modelle Ultimate Hub, Ultimate Smart Control, Ultimate, Smart Keyboard sowie alle darauf basierenden Kombinationen mit Smart Control und Smart Keyboard Add-On.

== Define ==
define <hub> harmony [<username> <password>] <ip>

Hier sind <code>username</code> und <code>password</code> die myharmony Zugangsdaten und <code>ip</code> ist die IP-Adresse des Hub im lokalen Netz.

Für die Firmware-Versionen 3.x ist die volle Funktionalität des Moduls auch ohne Angaben von <code>username</code> und <code>password</code> gegeben. Ab Firmware 4.x muss beides angegeben werden. Sonst ist keine Steuerung auf Geräteebene möglich.

==Allgemeines==
Aktivitäten und Geräte lassen sich an allen Stellen entweder als ID oder als Name angeben. Wenn der Name angegeben wird, müssen hierbei Leerzeichen durch einen Punkt ersetzt werden. Dies kann auch für eventuell andere im Namen vorhandene Sonderzeichen gelten.

== Aktivitäten ==
Das Reading <code>currentActivity</code> enthält die gerade laufende Aktivität. Beim Wechsel zwischen Aktivitäten erzeugt es Events, auf die in Fhem über ''notify'' reagiert werden kann. Das Reading <code>previousActivity</code> enthält die davor laufende Aktivität, sofern diese bekannt ist. Dieses Reading erzeugt keine Events.

In den Internals <code>currentActivityID</code> und <code>previousActivityID</code> stehen die dazu gehörenden IDs der Aktivitäten.

Innerhalb einer laufenden Aktivität kann mit
set <hub> command <command>
ein IR-Kommando an eines der beteiligten Geräte gesendet werden.

== Geräteebene ==
Innerhalb und außerhalb einer laufenden Aktivität kann mit
set <hub> command <id|name> <command>
ein IR-Kommando an eines der im Hub bekannten Geräte gesendet werden. Hierbei ist darauf zu achten, dass innerhalb einer Aktivität keine Kommandos verwendet werden sollten, die den Smart-State betreffen.

=== Fhem Devices auf Geräteebene ===
Es ist möglich, sich für einzelne oder alle im Hub konfigurierten Geräte ein zugehöriges FHEM-Device anlegen zu lassen:
set <hub> autocreate [<id|name>]

Beim Umschalten zwischen Aktivitäten wird in diesen FHEM-Devices im Reading power der in der Aktivität konfigurierten Einschaltzustand (on, off oder manual) angezeigt. Mit einem ''notify'' auf <code>power</code> Events lässt sich in Fhem auf einzelne Geräte reagieren.

'''Wichtig:''' Diese FHEM-Device spiegeln nicht den tatsächlichen Gerätezustand wieder, sondern den innerhalb einer Aktivität beabsichtigen Zustand. Der tatsächliche Zustand kann z.B. auf Grund von Empfangsproblemen abweichen.

Das get <code>commands</code> sowie die set <code>command</code>, <code>hidDevice</code>, <code>text</code>, <code>cursor</code> und <code>special</code> Kommandos auf Hub-Ebene stehen hier direkt und ohne Angabe von Device-ID oder Name zur Verfügung.

=== Kommandos an Fhem senden ===
Da es (zur Zeit) nicht möglich ist, Geräte-Kommandos oder einzelne Tasten direkt vom HUB zu empfangen, muss hierzu ein zusätzlicher Empfänger in Fhem eingebunden werden. Dies kann z.B. mit einem MCE-IR Empfänger oder per Bluetooth geschehen. Ein Fhem-Modul hierzu findet sich im in diesem {{Link2Forum|Topic=36257|LinkText=Forenthread}}.

== Smart Keyboard ==
Der Harmony Hub kann über Bluetooth oder die zum Smart Keyboard gehörenden USB-Dongle mit einem Rechner, Media PC oder sonstigem Gerät, das Tastatureingabe unterstützt, verbunden werden. Fhem kann diese Verbindung nutzen, um beliebige Tastendrücke an ein solches Gerät zu senden. Das können Texte sein, Cursorbewegungen oder die Power-, Multimedia oder sonstigen Funktionstasten, die das Gerät unterstützt.

Alle gesendeten Tastendrücke beziehen sich normalerweise auf das zur gerade laufenden Aktivität gehörende Tastatureingabegerät. Mit dem <code>hidDevice</code> Kommando lässt sich die Tastatureingabe auf jedes im Hub dafür konfigurierte Gerät umschalten.

'''Wichtig:''' Dieses Umschalten kann einige Sekunden dauern, da hierbei die bestehende Bluetooth-Verbindung getrennt und eine neue aufgebaut wird.

Es stehen die Kommandos <code>text</code>, <code>cursor</code> und <code>special</code> zur Verfügung.

Beispiele:

Gehe in PLEX auf die Library Musik und spiele das erste Item in der OnDeck Liste:
set <hub> text M
set <hub> cursor right
set <hub> text p

== Beispiele ==

=== Vorgeschaltete Funksteckdose ansteuern ===

'''Vorbereitung Harmony'''

Nachdem die Geräte mit Strom versorgt werden, benötigen sie einige Sekunden, bis sie ihre Einschaltsignale verarbeiten können. Diese Verzögerung wird durch ein Dummy Gerät in jeder Aktion erzeugt.

1) In MyHarmony einen Amazon Fire TV anlegen und ihm einen passenden Namen geben (z.B. Pause)

2) Unter "Geräte" dieses markieren und per "Ändern der Betriebseinstellungen" die Einstellungen aufrufen

3) Punkt "Ich möchte dieses Gerät eingeschaltet lassen, wenn Aktionen gewechselt werden und nur durch Drücken der Off-Taste ausschalten" auswählen

4) Einen harmlosen Befehl einfügen ("Search"), danach eine Verzögerung von 5000ms einbauen und dann noch einen Befehl ("Search"). Dies bewirkt eine Verzögerung von 5 Sekunden beim Ein- und Ausschalten

5) Unter Aktionen die Aktion auswählen und per "Einstellung ändern" das neue Gerät hinzufügen

6) Per "Diese Aktion anpassen" das neue Gerät an die erste Stelle schieben

7) Schritte 5-7 für alle Aktionen wiederholen

'''Konfiguration in FHEM'''

1) Der Harmony Hub muss existieren

#Harmony Hub Wohnzimmer definieren
define wz_harmonyhub harmony 192.168.123.123

2) Ihr benötigt eine fertig konfigurierte Funksteckdose (hier "wz_Multimedia")

3) Ihr baut eine Bedingung, die auf den Ein- und Ausschaltvorgang des Harmony Hub (hier wz_harmonyhub) reagiert und die Steckdose (hier wz_Multimedia) schaltet. Es wird eine '''zusätzliche''' Pause genutzt von 0 Sekunden bei der ersten Bedingung (wäre kontraproduktiv) und 10 Sekunden bei der zweiten Bedingung (DOELSEIF). Bei der Nutzung eines Beamers lässt sich hierüber die Abkühlzeit einstellen. Im Beispiel bleiben den Geräten somit 15 Sekunden zum Ausschalten und 5 Sekunden um die Empfangsbereitschaft herzustellen. Die erste Bedingung im DOIF ist eine Regex, da "currentActivity" bei mehrfachem Abschalten hintereinander immer wieder von "PowerOff" auf "Stopping PowerOff" wechselt.

#Auf den Schaltvorgang des Hubs reagieren
define wz_Multimedia_Automatik DOIF ([wz_harmonyhub:currentActivity] !~ /PowerOff/) (set wz_Multimedia on) DOELSEIF ([wz_harmonyhub:activity] eq "PowerOff") (set wz_Multimedia off)
attr wz_Multimedia_Automatik wait 0:10

== Bekannte Probleme ==
Wenn Fhem den Harmony Hub nicht erreichen kann, blockiert das Modul Fhem für den Timeout von 2 Sekunden im Abstand von nur wenigen Sekunden:

<pre>[...]
2015.12.26 18:25:45 1: Perfmon: possible freeze starting at 18:25:43, delay is 2.794
2015.12.26 18:25:58 1: Perfmon: possible freeze starting at 18:25:56, delay is 2.709
2015.12.26 18:26:11 1: Perfmon: possible freeze starting at 18:26:09, delay is 2.676
2015.12.26 18:26:24 1: Perfmon: possible freeze starting at 18:26:22, delay is 2.686
2015.12.26 18:26:37 1: Perfmon: possible freeze starting at 18:26:35, delay is 2.686
[...]
</pre>

Da dieses Blockieren die Funktionalität von Fhem beeinträchtigen kann, sollte man bei geplanten Auszeiten des Hubs diesen disablen:

set <hub> disable 1

== Weblinks ==
* [http://myharmony.com myHarmony] Logitech Harmony Hersteller
* [http://www.harmony-remote-forum.de/portal.php Harmony Remote Forum] deutsches Harmony Forum
* [http://forum.fhem.de/index.php/topic,14163.0.html Thread im FHEM Forum] Weitere Infos im FHEM Forum Thread

[[Kategorie:Unterhaltungselektronik]]
[[Kategorie:IP Components]]

HM-LC-Sw1PBU-FM Unterputz-Schaltaktor 1-fach

2015-12-17T21:06:03Z

Motivierte linke Hände: Typo

{{Infobox Hardware|Bild=platzHalter.png
|Bildbeschreibung=HM-LC-Sw1PBU-FM Unterputz-Schaltaktor 1-fach für Markenschalter
|HWProtocol=HomeMatic
|HWType=Aktor / Sender
|HWCategory=HomeMatic
|HWComm=868,3MHz
|HWChannels=1
|HWVoltage=230V
|HWPowerConsumption=0,5W (Standby)
|HWPoweredBy=Netz
|HWSize=71x71x37 mm
|HWDeviceFHEM=[http://fhem.de/commandref.html#CUL_HM CUL_HM]
|HWManufacturer=eQ-3}}

[[HM-LC-Sw1PBU-FM Unterputz-Schaltaktor 1-fach]] ist ein einkanaliger Funk-Schaltaktor "für Markenschalter", der mittels entsprechender Installationsadapter mit Tasterwippen diverser renommierter Hersteller versehen werden kann und sich dadurch nahtlos in bestehende Elektroinstallationen einfügt.

== Features ==
Das besondere an diesem Schalter ist, dass er den vorhandenen Unterputzeinsatz vollständig ersetzt. Dabei kann die Wippe des vorhandenen Schalters - je nach Hersteller - mit einer entsprechenden Adapterplatte weiterverwendet werden.

Es handelt sich hierbei nur um einen Aktor. Es ist nicht möglich die Taster mit anderen Homematic Geräten zu peeren. Man kann nur andere Taster mit dem Aktor peeren und diesen fernsteuern.

== Technische Daten ==

{|
| Art
| Unterputz
|-
| Typ
| 1fach
|-
| Stand-by-Verbrauch
| 0,5 W (lt. Bedienungsanleitung, S. 31, Stand 02/2012, 1 W)
|-
| Versorgungsspannung
| 230 V
|-
| Abmessungen (B x H x T)
| 71 x 71 x 37 mm
|-
| Farbe
| Grau
|-
| Max. Schaltleistung
| 1000 W
|-
| Relaistyp
| Wechsler
|-
| Funkfrequenz
| 868,3 MHz
|-
| Empfängerklasse
| SRD Class 2
|-
| Sicherung (intern)
| Rundsicherung 5 A, träge
|-
| Max. Sendeleistung
| 10 mW
|-
| IP-Schutzgrad
| IP 20
|-
| Umgebungstemperaturbereich
| 5–35 °C
|}

== Hinweise zur Hardware-Installation ==
Der vorhandene Schalter muss ersetzt werden. Dabei sind ein paar Dinge zu beachten:

* Der (neue) Schalter benötigt neben dem L-Leiter auch einen N-Leiter für die Stromversorgung.
* Die Befestigung ist nicht wie bei dem System z.B. von Merten durch spreizen von Klammern möglich. Der Schalter muss in die Löcher in der Dose geschraubt werden (Schrauben im Lieferumfang enthalten).
* Die "Frontplatte" bzw. der Befestigungsrahmen ist etwas dicker, als der Rahmen eines normalen Schalters. Dadurch kann es sein, dass der vorhandene Rahmen des Schalters nicht mehr ganz an der Wand anliegt.
* Um die bereits vorhandene Schalter-Wippe weiter nutzen zu können, muss ein passender Adapter verwendet werden.

== Hinweise zum Betrieb mit FHEM ==
Das Pairing sollte wie in [[HomeMatic Devices pairen]] beschrieben durchgeführt werden.

=== FHEM Config-Auszug ===
Ein exemplarischer Auszug aus der [[Konfiguration]]:

<pre>
define LichtWohnzimmer CUL_HM 197764
attr LichtWohnzimmer devInfo 010100
attr LichtWohnzimmer firmware 2.1
attr LichtWohnzimmer hmClass receiver
attr LichtWohnzimmer model unknown
attr LichtWohnzimmer room Wohnzimmer
attr LichtWohnzimmer serialNr JEQ0xxxxxx
attr LichtWohnzimmer subType switch
</pre>

=== Mögliche Schaltoperationen ===
Der Aktor versteht folgende Aktionen:

<pre>
set <name> on -> Schaltet den Aktor ein
set <name> off -> Schaltet den Aktor aus
set <name> toggle -> Ändert den Zustand des Aktors, d.h. ein eingeschalteter Aktor wird ausgeschaltet
</pre>

=== Log-Auszug ===
In FHEM ist nach dem Schalten des HM-LC-Sw1PBU-FM folgendes Log zu sehen:
<pre>
2012-06-05_00:09:22 LichtWohnzimmer deviceMsg: off
2012-06-05_00:09:22 LichtWohnzimmer off
2012-06-05_07:40:51 LichtWohnzimmer on
2012-06-05_07:40:51 LichtWohnzimmer deviceMsg: on
</pre>

Beim Einrichten des Schalters kommt folgender Auszug (Stand: 06.2012)
<pre>
2012.06.04 23:12:27 2: CUL_HM pair: CUL_HM_switch_197764 is a switch, model unknown serialNr JEQ0xxxxxx
</pre>

=== Funktion als Treppenlichtschalter ===
Um dafür zu sorgen, dass z.B. ein durch den HM-LC-Sw1PBU-FM eingeschaltetes Licht automatisch von FHEM nach 10 Minuten ausgeschaltet wird, kann folgende Definition verwendet werden:
:<code>define Beleuchtung_an notify Beleuchtung:on* define Beleuchtung_aus at +00:10:00 set Beleuchtung off </code>

=== Workaround um den Taster in FHEM zu nutzen ===
Man kann den Taster in der Originalfirmware nicht mit anderen Geräten peeren. Allerdings kann man mit folgendem Workaround den Taster in FHEM nutzen. Das hat jedoch eine Verzögerung zwischen drei und acht Sekunden. Dabei ist es trotzdem möglich, den Aktor per FHEM oder gepeertem Gerät weiter zu steuern. Der Taster beeinflusst den Aktor nicht mehr. Das ganze funktioniert, weil der HM-LC-Sw1PBU-FM bei jedem Tastendruck das reading für state aktualisiert, auch wenn sich der Wert nicht ändert.

Zuerst setzt man ein event auf event-on-change-reading:

attr HM-LC-Sw1PBU-FM event-on-change-reading state
attr HM-LC-Sw1PBU-FM event-on-update-reading state

Weiterhin wird der Schalter deaktiviert (hier nur für kurzen Tastendruck; mit lgSwJtXXX wird dieser Effekt auch für den langen Tastendruck erzielt):
set HM-LC-Sw1PBU-FM regSet intKeyVisib visib
set HM-LC-Sw1PBU-FM getConfig
set HM-LC-Sw1PBU-FM regSet prep shSwJtOff off self01
set HM-LC-Sw1PBU-FM regSet prep shSwJtOn on self01
set HM-LC-Sw1PBU-FM regSet prep shSwJtOff off self02
set HM-LC-Sw1PBU-FM regSet exec shSwJtOn on self02

Nun setzt man einen Notify auf das Reading:
:<code>define HM-LC-Sw1PBU-FM-TasterPressed notify HM-LC-Sw1PBU-FM {set YourOtherDevice toggle}</code>

=== Alternative Firmware ===
Um die beiden Taster als Remote und den Aktor getrennt zu nutzen gibt es alternative Firmware, deren Funktion und Benutzung auf der Seite [[HM-LC-Sw1PBU-FM Alternative Firmware]] im Detail beschrieben ist.

=== Schalter immer toggeln lassen ===
Im Werkszustand schaltet die Wippe bei Druck auf der einen Seite ein, auf der anderen Seite aus. Möchte man, dass bei jedem Tastendruck einfach der Zustand geändert wird, kann man das wie folgt erreichen (unten nur für den kurzen Tastendruck dargestellt):
set HM-LC-Sw1PBU-FM regSet intKeyVisib visib
set HM-LC-Sw1PBU-FM getConfig
set HM-LC-Sw1PBU-FM regSet shActionType jmpToTarget self01
set HM-LC-Sw1PBU-FM regSet shSwJtOn dlyOff self01
set HM-LC-Sw1PBU-FM regSet shSwJtOff dlyOn self01
set HM-LC-Sw1PBU-FM regSet shSwJtDlyOn on self01
set HM-LC-Sw1PBU-FM regSet shSwJtDlyOff off self01
set HM-LC-Sw1PBU-FM regSet shActionType jmpToTarget self02
set HM-LC-Sw1PBU-FM regSet shSwJtOn dlyOff self02
set HM-LC-Sw1PBU-FM regSet shSwJtOff dlyOn self02
set HM-LC-Sw1PBU-FM regSet shSwJtDlyOn on self02
set HM-LC-Sw1PBU-FM regSet shSwJtDlyOff off self02

=== on-for-timer Ersatz ===
Der HM-LC-Sw1PBU-FM kennt kein <code>set on-for-timer</code>. Um den HM-LC-Sw1PBU-FM trotzdem für einige Zeit anschalten zu können (z. B. wenn ein Fensteröffner dranhängt und das Fenster nur für eine gewisse Zeit geöffnet werden soll), muss ein Button der vccu mit dem HM-LC-Sw1PBU-FM gepeered werden:
set vccu_Btn4 peerChan 0 HM-LC-Sw1PBU-FM dual set

Danach wären (in diesem Fall mit vccu_Btn4) die virtuellen Buttons 4 und 5 mit dem HM-LC-Sw1PBU-FM gepeered. Das Fenster könnte dann über <code>set vccu_Btn4 press short</code> für die vorher über <code>set HM-LC-Sw1PBU-FM regSet shOnTime [Dauer] vccu_Btn4</code> die Öffnungszeit eingestellt werden kann.

== Links ==
* Anleitung (PDF {{DocLink|elv|/Assets/Produkte/10/1030/103029/Downloads/103029_FunkSchaltaktor_um.pdf}})
* Produktwebseite bei [http://www.elv.de/output/controller.aspx?cid=74&detail=10&detail2=37991 ELV]
* [[HM-LC-Sw1PBU-FM Alternative_Firmware|Alternative Firmware]]

[[Kategorie:HomeMatic Components]]
[[Kategorie:Schalter (Empfänger)]]

HM-LC-Sw1PBU-FM Unterputz-Schaltaktor 1-fach

2015-12-17T20:56:34Z

Motivierte linke Hände: vccu peering ergänzt

{{Infobox Hardware|Bild=platzHalter.png
|Bildbeschreibung=HM-LC-Sw1PBU-FM Unterputz-Schaltaktor 1-fach für Markenschalter
|HWProtocol=HomeMatic
|HWType=Aktor / Sender
|HWCategory=HomeMatic
|HWComm=868,3MHz
|HWChannels=1
|HWVoltage=230V
|HWPowerConsumption=0,5W (Standby)
|HWPoweredBy=Netz
|HWSize=71x71x37 mm
|HWDeviceFHEM=[http://fhem.de/commandref.html#CUL_HM CUL_HM]
|HWManufacturer=eQ-3}}

[[HM-LC-Sw1PBU-FM Unterputz-Schaltaktor 1-fach]] ist ein einkanaliger Funk-Schaltaktor "für Markenschalter", der mittels entsprechender Installationsadapter mit Tasterwippen diverser renommierter Hersteller versehen werden kann und sich dadurch nahtlos in bestehende Elektroinstallationen einfügt.

== Features ==
Das besondere an diesem Schalter ist, dass er den vorhandenen Unterputzeinsatz vollständig ersetzt. Dabei kann die Wippe des vorhandenen Schalters - je nach Hersteller - mit einer entsprechenden Adapterplatte weiterverwendet werden.

Es handelt sich hierbei nur um einen Aktor. Es ist nicht möglich die Taster mit anderen Homematic Geräten zu peeren. Man kann nur andere Taster mit dem Aktor peeren und diesen fernsteuern.

== Technische Daten ==

{|
| Art
| Unterputz
|-
| Typ
| 1fach
|-
| Stand-by-Verbrauch
| 0,5 W (lt. Bedienungsanleitung, S. 31, Stand 02/2012, 1 W)
|-
| Versorgungsspannung
| 230 V
|-
| Abmessungen (B x H x T)
| 71 x 71 x 37 mm
|-
| Farbe
| Grau
|-
| Max. Schaltleistung
| 1000 W
|-
| Relaistyp
| Wechsler
|-
| Funkfrequenz
| 868,3 MHz
|-
| Empfängerklasse
| SRD Class 2
|-
| Sicherung (intern)
| Rundsicherung 5 A, träge
|-
| Max. Sendeleistung
| 10 mW
|-
| IP-Schutzgrad
| IP 20
|-
| Umgebungstemperaturbereich
| 5–35 °C
|}

== Hinweise zur Hardware-Installation ==
Der vorhandene Schalter muss ersetzt werden. Dabei sind ein paar Dinge zu beachten:

* Der (neue) Schalter benötigt neben dem L-Leiter auch einen N-Leiter für die Stromversorgung.
* Die Befestigung ist nicht wie bei dem System z.B. von Merten durch spreizen von Klammern möglich. Der Schalter muss in die Löcher in der Dose geschraubt werden (Schrauben im Lieferumfang enthalten).
* Die "Frontplatte" bzw. der Befestigungsrahmen ist etwas dicker, als der Rahmen eines normalen Schalters. Dadurch kann es sein, dass der vorhandene Rahmen des Schalters nicht mehr ganz an der Wand anliegt.
* Um die bereits vorhandene Schalter-Wippe weiter nutzen zu können, muss ein passender Adapter verwendet werden.

== Hinweise zum Betrieb mit FHEM ==
Das Pairing sollte wie in [[HomeMatic Devices pairen]] beschrieben durchgeführt werden.

=== FHEM Config-Auszug ===
Ein exemplarischer Auszug aus der [[Konfiguration]]:

<pre>
define LichtWohnzimmer CUL_HM 197764
attr LichtWohnzimmer devInfo 010100
attr LichtWohnzimmer firmware 2.1
attr LichtWohnzimmer hmClass receiver
attr LichtWohnzimmer model unknown
attr LichtWohnzimmer room Wohnzimmer
attr LichtWohnzimmer serialNr JEQ0xxxxxx
attr LichtWohnzimmer subType switch
</pre>

=== Mögliche Schaltoperationen ===
Der Aktor versteht folgende Aktionen:

<pre>
set <name> on -> Schaltet den Aktor ein
set <name> off -> Schaltet den Aktor aus
set <name> toggle -> Ändert den Zustand des Aktors, d.h. ein eingeschalteter Aktor wird ausgeschaltet
</pre>

=== Log-Auszug ===
In FHEM ist nach dem Schalten des HM-LC-Sw1PBU-FM folgendes Log zu sehen:
<pre>
2012-06-05_00:09:22 LichtWohnzimmer deviceMsg: off
2012-06-05_00:09:22 LichtWohnzimmer off
2012-06-05_07:40:51 LichtWohnzimmer on
2012-06-05_07:40:51 LichtWohnzimmer deviceMsg: on
</pre>

Beim Einrichten des Schalters kommt folgender Auszug (Stand: 06.2012)
<pre>
2012.06.04 23:12:27 2: CUL_HM pair: CUL_HM_switch_197764 is a switch, model unknown serialNr JEQ0xxxxxx
</pre>

=== Funktion als Treppenlichtschalter ===
Um dafür zu sorgen, dass z.B. ein durch den HM-LC-Sw1PBU-FM eingeschaltetes Licht automatisch von FHEM nach 10 Minuten ausgeschaltet wird, kann folgende Definition verwendet werden:
:<code>define Beleuchtung_an notify Beleuchtung:on* define Beleuchtung_aus at +00:10:00 set Beleuchtung off </code>

=== Workaround um den Taster in FHEM zu nutzen ===
Man kann den Taster in der Originalfirmware nicht mit anderen Geräten peeren. Allerdings kann man mit folgendem Workaround den Taster in FHEM nutzen. Das hat jedoch eine Verzögerung zwischen drei und acht Sekunden. Dabei ist es trotzdem möglich, den Aktor per FHEM oder gepeertem Gerät weiter zu steuern. Der Taster beeinflusst den Aktor nicht mehr. Das ganze funktioniert, weil der HM-LC-Sw1PBU-FM bei jedem Tastendruck das reading für state aktualisiert, auch wenn sich der Wert nicht ändert.

Zuerst setzt man ein event auf event-on-change-reading:

attr HM-LC-Sw1PBU-FM event-on-change-reading state
attr HM-LC-Sw1PBU-FM event-on-update-reading state

Weiterhin wird der Schalter deaktiviert (hier nur für kurzen Tastendruck; mit lgSwJtXXX wird dieser Effekt auch für den langen Tastendruck erzielt):
set HM-LC-Sw1PBU-FM regSet intKeyVisib visib
set HM-LC-Sw1PBU-FM getConfig
set HM-LC-Sw1PBU-FM regSet prep shSwJtOff off self01
set HM-LC-Sw1PBU-FM regSet prep shSwJtOn on self01
set HM-LC-Sw1PBU-FM regSet prep shSwJtOff off self02
set HM-LC-Sw1PBU-FM regSet exec shSwJtOn on self02

Nun setzt man einen Notify auf das Reading:
:<code>define HM-LC-Sw1PBU-FM-TasterPressed notify HM-LC-Sw1PBU-FM {set YourOtherDevice toggle}</code>

=== Alternative Firmware ===
Um die beiden Taster als Remote und den Aktor getrennt zu nutzen gibt es alternative Firmware, deren Funktion und Benutzung auf der Seite [[HM-LC-Sw1PBU-FM Alternative Firmware]] im Detail beschrieben ist.

=== Schalter immer toggeln lassen ===
Im Werkszustand schaltet die Wippe bei Druck auf der einen Seite ein, auf der anderen Seite aus. Möchte man, dass bei jedem Tastendruck einfach der Zustand geändert wird, kann man das wie folgt erreichen (unten nur für den kurzen Tastendruck dargestellt):
set HM-LC-Sw1PBU-FM regSet intKeyVisib visib
set HM-LC-Sw1PBU-FM getConfig
set HM-LC-Sw1PBU-FM regSet shActionType jmpToTarget self01
set HM-LC-Sw1PBU-FM regSet shSwJtOn dlyOff self01
set HM-LC-Sw1PBU-FM regSet shSwJtOff dlyOn self01
set HM-LC-Sw1PBU-FM regSet shSwJtDlyOn on self01
set HM-LC-Sw1PBU-FM regSet shSwJtDlyOff off self01
set HM-LC-Sw1PBU-FM regSet shActionType jmpToTarget self02
set HM-LC-Sw1PBU-FM regSet shSwJtOn dlyOff self02
set HM-LC-Sw1PBU-FM regSet shSwJtOff dlyOn self02
set HM-LC-Sw1PBU-FM regSet shSwJtDlyOn on self02
set HM-LC-Sw1PBU-FM regSet shSwJtDlyOff off self02

=== on-for-timer Ersatz ===
Der HM-LC-Sw1PBU-FM kennt kein <code>set on-for-timer</code>. Um den HM-LC-Sw1PBU-FM trotzdem für einige Zeit anschalten zu können (z. B. wenn ein Fensteröffner dranhängt und das Fenster nur für eine gewisse Zeit geöffnet werden soll), muss ein Button der vccu mit dem HM-LC-Sw1PBU-FM gepeered werden:
set vccu_Btn4 peerChan 0 HM-LC-Sw1PBU-FM dual set

Danach wären (in diesem Fall mit vccu_Btn4) die virtuellen Buttons 4 und 5 mit dem HM-LC-Sw1PBU-FM gepeered. Das Fenster könnte dann über <code>set vccu_Btn4 press short</code> für die über <code>set HM-LC-Sw1PBU-FM regSet shOnTime vccu_Btn4 [Dauer]</code> die Öffnungszeit eingestellt werden kann.

== Links ==
* Anleitung (PDF {{DocLink|elv|/Assets/Produkte/10/1030/103029/Downloads/103029_FunkSchaltaktor_um.pdf}})
* Produktwebseite bei [http://www.elv.de/output/controller.aspx?cid=74&detail=10&detail2=37991 ELV]
* [[HM-LC-Sw1PBU-FM Alternative_Firmware|Alternative Firmware]]

[[Kategorie:HomeMatic Components]]
[[Kategorie:Schalter (Empfänger)]]

HM-LC-Sw1PBU-FM Unterputz-Schaltaktor 1-fach

2015-12-05T11:59:55Z

Motivierte linke Hände: Beispiel zum Togglen per Schalter hinzugefügt

{{Infobox Hardware|Bild=platzHalter.png
|Bildbeschreibung=HM-LC-Sw1PBU-FM Unterputz-Schaltaktor 1-fach für Markenschalter
|HWProtocol=HomeMatic
|HWType=Aktor / Sender
|HWCategory=HomeMatic
|HWComm=868,3MHz
|HWChannels=1
|HWVoltage=230V
|HWPowerConsumption=0,5W (Standby)
|HWPoweredBy=Netz
|HWSize=71x71x37 mm
|HWDeviceFHEM=[http://fhem.de/commandref.html#CUL_HM CUL_HM]
|HWManufacturer=eQ-3}}

[[HM-LC-Sw1PBU-FM Unterputz-Schaltaktor 1-fach]] ist ein einkanaliger Funk-Schaltaktor "für Markenschalter", der mittels entsprechender Installationsadapter mit Tasterwippen diverser renommierter Hersteller versehen werden kann und sich dadurch nahtlos in bestehende Elektroinstallationen einfügt.

== Features ==
Das besondere an diesem Schalter ist, dass er den vorhandenen Unterputzeinsatz vollständig ersetzt. Dabei kann die Wippe des vorhandenen Schalters - je nach Hersteller - mit einer entsprechenden Adapterplatte weiterverwendet werden.

Es handelt sich hierbei nur um einen Aktor. Es ist nicht möglich die Taster mit anderen Homematic Geräten zu peeren. Man kann nur andere Taster mit dem Aktor peeren und diesen fernsteuern.

== Technische Daten ==

{|
| Art
| Unterputz
|-
| Typ
| 1fach
|-
| Stand-by-Verbrauch
| 0,5 W (lt. Bedienungsanleitung, S. 31, Stand 02/2012, 1 W)
|-
| Versorgungsspannung
| 230 V
|-
| Abmessungen (B x H x T)
| 71 x 71 x 37 mm
|-
| Farbe
| Grau
|-
| Max. Schaltleistung
| 1000 W
|-
| Relaistyp
| Wechsler
|-
| Funkfrequenz
| 868,3 MHz
|-
| Empfängerklasse
| SRD Class 2
|-
| Sicherung (intern)
| Rundsicherung 5 A, träge
|-
| Max. Sendeleistung
| 10 mW
|-
| IP-Schutzgrad
| IP 20
|-
| Umgebungstemperaturbereich
| 5–35 °C
|}

== Hinweise zur Hardware-Installation ==
Der vorhandene Schalter muss ersetzt werden. Dabei sind ein paar Dinge zu beachten:

* Der (neue) Schalter benötigt neben dem L-Leiter auch einen N-Leiter für die Stromversorgung.
* Die Befestigung ist nicht wie bei dem System z.B. von Merten durch spreizen von Klammern möglich. Der Schalter muss in die Löcher in der Dose geschraubt werden (Schrauben im Lieferumfang enthalten).
* Die "Frontplatte" bzw. der Befestigungsrahmen ist etwas dicker, als der Rahmen eines normalen Schalters. Dadurch kann es sein, dass der vorhandene Rahmen des Schalters nicht mehr ganz an der Wand anliegt.
* Um die bereits vorhandene Schalter-Wippe weiter nutzen zu können, muss ein passender Adapter verwendet werden.

== Hinweise zum Betrieb mit FHEM ==
Das Pairing sollte wie in [[HomeMatic Devices pairen]] beschrieben durchgeführt werden.

=== FHEM Config-Auszug ===
Ein exemplarischer Auszug aus der [[Konfiguration]]:

<pre>
define LichtWohnzimmer CUL_HM 197764
attr LichtWohnzimmer devInfo 010100
attr LichtWohnzimmer firmware 2.1
attr LichtWohnzimmer hmClass receiver
attr LichtWohnzimmer model unknown
attr LichtWohnzimmer room Wohnzimmer
attr LichtWohnzimmer serialNr JEQ0xxxxxx
attr LichtWohnzimmer subType switch
</pre>

=== Mögliche Schaltoperationen ===
Der Aktor versteht folgende Aktionen:

<pre>
set <name> on -> Schaltet den Aktor ein
set <name> off -> Schaltet den Aktor aus
set <name> toggle -> Ändert den Zustand des Aktors, d.h. ein eingeschalteter Aktor wird ausgeschaltet
</pre>

=== Log-Auszug ===
In FHEM ist nach dem Schalten des HM-LC-Sw1PBU-FM folgendes Log zu sehen:
<pre>
2012-06-05_00:09:22 LichtWohnzimmer deviceMsg: off
2012-06-05_00:09:22 LichtWohnzimmer off
2012-06-05_07:40:51 LichtWohnzimmer on
2012-06-05_07:40:51 LichtWohnzimmer deviceMsg: on
</pre>

Beim Einrichten des Schalters kommt folgender Auszug (Stand: 06.2012)
<pre>
2012.06.04 23:12:27 2: CUL_HM pair: CUL_HM_switch_197764 is a switch, model unknown serialNr JEQ0xxxxxx
</pre>

=== Funktion als Treppenlichtschalter ===
Um dafür zu sorgen, dass z.B. ein durch den HM-LC-Sw1PBU-FM eingeschaltetes Licht automatisch von FHEM nach 10 Minuten ausgeschaltet wird, kann folgende Definition verwendet werden:
:<code>define Beleuchtung_an notify Beleuchtung:on* define Beleuchtung_aus at +00:10:00 set Beleuchtung off </code>

=== Workaround um den Taster in FHEM zu nutzen ===
Man kann den Taster in der Originalfirmware nicht mit anderen Geräten peeren. Allerdings kann man mit folgendem Workaround den Taster in FHEM nutzen. Das hat jedoch eine Verzögerung zwischen drei und acht Sekunden. Dabei ist es trotzdem möglich, den Aktor per FHEM oder gepeertem Gerät weiter zu steuern. Der Taster beeinflusst den Aktor nicht mehr. Das ganze funktioniert, weil der HM-LC-Sw1PBU-FM bei jedem Tastendruck das reading für state aktualisiert, auch wenn sich der Wert nicht ändert.

Zuerst setzt man ein event auf event-on-change-reading:

attr HM-LC-Sw1PBU-FM event-on-change-reading state
attr HM-LC-Sw1PBU-FM event-on-update-reading state

Weiterhin wird der Schalter deaktiviert (hier nur für kurzen Tastendruck; mit lgSwJtXXX wird dieser Effekt auch für den langen Tastendruck erzielt):
set HM-LC-Sw1PBU-FM regSet intKeyVisib visib
set HM-LC-Sw1PBU-FM getConfig
set HM-LC-Sw1PBU-FM regSet prep shSwJtOff off self01
set HM-LC-Sw1PBU-FM regSet prep shSwJtOn on self01
set HM-LC-Sw1PBU-FM regSet prep shSwJtOff off self02
set HM-LC-Sw1PBU-FM regSet exec shSwJtOn on self02

Nun setzt man einen Notify auf das Reading:
:<code>define HM-LC-Sw1PBU-FM-TasterPressed notify HM-LC-Sw1PBU-FM {set YourOtherDevice toggle}</code>

=== Alternative Firmware ===
Um die beiden Taster als Remote und den Aktor getrennt zu nutzen gibt es alternative Firmware, deren Funktion und Benutzung auf der Seite [[HM-LC-Sw1PBU-FM Alternative Firmware]] im Detail beschrieben ist.

=== Schalter immer toggeln lassen ===
Im Werkszustand schaltet die Wippe bei Druck auf der einen Seite ein, auf der anderen Seite aus. Möchte man, dass bei jedem Tastendruck einfach der Zustand geändert wird, kann man das wie folgt erreichen (unten nur für den kurzen Tastendruck dargestellt):
set HM-LC-Sw1PBU-FM regSet intKeyVisib visib
set HM-LC-Sw1PBU-FM getConfig
set HM-LC-Sw1PBU-FM regSet shActionType jmpToTarget self01
set HM-LC-Sw1PBU-FM regSet shSwJtOn dlyOff self01
set HM-LC-Sw1PBU-FM regSet shSwJtOff dlyOn self01
set HM-LC-Sw1PBU-FM regSet shSwJtDlyOn on self01
set HM-LC-Sw1PBU-FM regSet shSwJtDlyOff off self01
set HM-LC-Sw1PBU-FM regSet shActionType jmpToTarget self02
set HM-LC-Sw1PBU-FM regSet shSwJtOn dlyOff self02
set HM-LC-Sw1PBU-FM regSet shSwJtOff dlyOn self02
set HM-LC-Sw1PBU-FM regSet shSwJtDlyOn on self02
set HM-LC-Sw1PBU-FM regSet shSwJtDlyOff off self02

== Links ==
* Anleitung (PDF {{DocLink|elv|/Assets/Produkte/10/1030/103029/Downloads/103029_FunkSchaltaktor_um.pdf}})
* Produktwebseite bei [http://www.elv.de/output/controller.aspx?cid=74&detail=10&detail2=37991 ELV]
* [[HM-LC-Sw1PBU-FM Alternative_Firmware|Alternative Firmware]]

[[Kategorie:HomeMatic Components]]
[[Kategorie:Schalter (Empfänger)]]

GDS

2015-11-29T08:59:18Z

Motivierte linke Hände: /* Aktuelle Daten vom Server abrufen */

{{Infobox Modul
|ModPurpose=Herunterladen und Auswerten von Daten des Deutschen Wetterdienstes
|ModType=d
|ModForumArea=Unterstuetzende Dienste
|ModFTopic=14106
|ModTechName=55_GDS.pm
|ModOwner=betateilchen
}}
[[GDS]] ist ein Modul, mit dessen Hilfe man sich die Daten des Deutschen Wetterdienstes herunterladen kann und dann Wetterlage, diverse Wetterkarten und/oder Unwettermeldungen anzeigen/auswerten kann.

== Voraussetzungen ==
=== Anmeldung beim DWD ===
Als erstes muss man sich beim Deutschen Wetterdienst zur [http://www.dwd.de/grundversorgung Grundversorgung] kostenlos [http://kunden.dwd.de/gdsRegistration/gdsRegistrationStart.do anmelden].

=== Installation der benötigten Perl-Module ===
GDS benötigt die Perl-Module Net::FTP, List::MoreUtils, XML::Simple, Text::CSV.

Für Ubuntu und Raspi sollte funktionieren:

<code>apt-get install libnet-lite-ftp-perl liblist-moreutils-perl libxml-simple-perl libtext-csv-perl</code>

Das ftp-Modul verursacht manchmal Probleme bei der Installation. Teilweise ist es wohl auch schon in der Grundinstallation vorhanden, ansonsten kann man versuchen:

<code>apt-get install libnet-ftp-perl</code>

oder

<code>apt-get install libwww-perl</code>

== Anwendung ==
=== Define ===
<code>define [gdsName] GDS [gdsUsername] [gdsPasswort]</code>

[gdsUsername] und [gdsPasswort] gibt es nach Anmeldung vom DWD.

=== Attribute ===
Die vollständige Liste der Attribute ist in der [http://fhem.de/commandref.html#GDS commandref].

Station setzen, für die beim fhem-Start die Daten eingelesen werden sollen:

<code>attr [gdsName] gdsSetCond [Station]</code>

Hilfreich kann u.a. sein, wenn man hinter eine Firewall sitzt und der Datenabruf nicht funktioniert:

<code>attr [gdsName] gdsPassiveFtp 1</code>

== Anwendung ==
=== Liste der verfügbaren Wetterstationen abrufen ===
<code>get [gdsName] list stations</code>

=== Liste der verfügbaren Zellen für Warnungen abrufen ===
<code>get [gdsName] list capstations</code>

=== Manuelle Aktualisierung der Daten ===

==== Aktuelle Daten vom Server abrufen ====
<code>get [gdsName] rereadcfg</code>

==== Readings aus abgerufenen Daten aktualisieren ====
<code>set [gdsName] update</code>

=== Station setzen für automatischen, periodischen Abruf ===
<code>set [gdsName] conditions [Station]</code>

Automatisch abgerufen (alle 20 Minuten) werden nur die mit c_ beginnenden Readings. Die a_ Readings (Warnungen, etc.) müssen manuell aktualisiert werden.

=== Unwetterwarnungen nach Region aus gelesenen Daten raussuchen ===
<code>set [gdsName] warnings [Region]</code>

z.B.: <code> set gds warn Nordrhein-Westfalen</code>

Die Region kann ausgeschrieben oder mit den [http://www.bmelv-statistik.de/de/daten-tabellen-suche/abkuerzungen-der-bundeslaender/ offiziellen Abkürzungen] bezeichnet werden.

=== Unwetterwarnungen granularer nach Kreis aus gelesenenen Daten raussuchen ===
<code>set [gdsName] alerts [Warncell-ID]</code>

Die passende Warncell-ID kann man sich über <code>get [gdsName] list capstations</code> heraussuchen.

Ob es passende Warnmeldungen gibt, kann dann über das Reading <code>a_valid</code> abgefragt werden. Wenn <code>a_valid</code> 1 ist, gibt <code>a_count</code> die Anzahl der vorhandenen Warnmeldungen an. Die Warnungen stehen dann in den Readings <code>a_X_...</code>, wobei X ab 0 hochzählt. D.h. wenn <code>a_count</code> 2 ist, gibt es a_0_... und a_1_... Ein praktisches Reading ist z.B. <code>a_X_headline</code>, das die Zusammenfassung der jeweiligen Warnung als kurze Textzusammenfassung enthält.

Alle eingelesenen Warnmeldungen kann man sich über die Funktion <code>gdsHeadlines()</code> ausgeben lassen. Z.B. einfach in der Befehlszeile von fhem eingeben:

<code>{gdsHeadlines([gdsName])}</code>

Wer möchte, kann auch das Trennzeichen bei mehreren Meldungen konfigurieren:

<code>{gdsHeadlines([gdsName],'[Trennzeichen]')}</code>

Z.B. also

<code>{gdsHeadlines(gds, '***')}</code>

Standard für das Trennzeichen ist der senkrechte Strich.

Jedenfalls nach <code>attr [gdsName] gdsLong 1</code> werden in a_X_description die Langmeldungen zu den Warnungen ausgegeben.

=== Aktuelles Wetter abrufen ===
<code>get [gdsName] conditions [Station]</code>

=== Karten abrufen ===
Wetterlage: <code>get [gdsName] conditionsmap [Station] </code>

Vorhersage: <code>get [gdsName] forecastsmap [Station]</code>

Warnungen: <code>get [gdsName] warningsmap [Station]</code>

Radar: <code>get [gdsName] radarmap [Station]</code>

== Readings ==

<pre>
Höhe : m über NN
Luftd.: reduzierter Luftdruck auf Meereshöhe in hPa
TT : Lufttemperatur in Grad Celsius
Tn12 : Minimum der Lufttemperatur, 18 UTC Vortag bis 06 UTC heute, Grad Celsius
Tx12 : Maximum der Lufttemperatur, 18 UTC Vortag bis 06 UTC heute, Grad Celsius
Tg24 : Temperaturminimum 5cm über Erdboden 00 UTC bis 24 UTC, Grad Celsius
Tn24 : Minimum der Lufttemperatur, 00 UTC bis 24 UTC, Grad Celsius
Tm24 : Mittel der Lufttemperatur, 00 UTC bis 24 UTC, Grad Celsius
Tx24 : Maximum der Lufttemperatur, 00 UTC bis 24 UTC, Grad Celsius
Tmin : Minimum der Lufttemperatur, 06 UTC Vortag bis 06 UTC heute, Grad Celsius
Tmax : Maximum der Lufttemperatur, 06 UTC Vortag bis 06 UTC heute, Grad Celsius
RR1 : Niederschlagsmenge, einstündig, mm = l/qm
RR12 : Niederschlagsmenge, 12stündig, 18 UTC Vortag bis 06 UTC heute, mm = l/qm
RR24 : Niederschlagsmenge, 24stündig, 06 UTC Vortag bis 06 UTC heute, mm = l/qm
SSS : Gesamtschneehöhe in cm
SSS24 : Sonnenscheindauer in Stunden
SGLB24: Tagessumme Globalstrahlung in J/qcm
DD : Windrichtung
FF : Windgeschwindigkeit letztes 10-Minutenmittel in km/h
FX : höchste Windspitze im Bezugszeitraum in km/h
</pre>

== Anwendungsbeispiele ==

Für GDS sollten die Daten regelmäßig aktualisiert werden. Dafür richtet man am besten '''zwei''' zeitlich '''nacheinander''' laufende ats ein:

Einen zum Holen aktualisierter Daten vom Server:

<pre>
define readGDS at +*00:10:00 get [gdsName] rereadcfg
attr readGDS alignTime 22:30:05
</pre>

Einen zweiten, der danach läuft, der aus den aktualisierten Serverdaten dann die Readings aktualisiert; z.B. für die Alerts:

<pre>
define checkGDS at +*00:10:00 get [gdsName] alerts [Region]
attr checkGDS alignTime 22:35:05
</pre>

Wichtig ist, dass beide at zeitlich auseinander liegen, im vorstehenden Beispiel durch die unterschiedlichen "alignTime" Attribute um 5 Minuten.

=== Karten regelmäßig vom Server neu laden ===

<code>define Karten at +*00:30:00 get [gdsName] radarmap Nordost; get [gdsName] conditionsmap Nordost; get [gdsName] warningsmap Berlin</code>

Hinweis: Die vorstehende Schreibweise ist die Schreibweise im Editiermodus der Weboberfläche von fhem. Wer die Zeile per copy & paste direkt in die Kommandozeile eintragen will, muss die Semikolons verdoppeln, sonst geht alles nach dem ersten Semikolon verloren.

Also:

<code>define Karten at +*00:30:00 get [gdsName] radarmap Nordost;; get [gdsName] conditionsmap Nordost;; get [gdsName] warningsmap Berlin</code>

== Bekannte Probleme ==
Das eingecheckte GDS-Modul ist nicht auf "non-blocking" umgeschrieben. Das führt dazu, dass FHEM immer mal wieder "einfriert" (nichts macht), während auf die Rückmeldung von, z. B., einem FTP-Transfer ("get [gdsName] conditionsmap" etc.) gewartet wird. Das kann bei Timing-kritischen Bestandteilen zu Problemen führen, weil Events nicht mitbekommen werden, die Ansteuerung von Geräten nicht funktioniert, etc.

Einige dieser FHEM blockierenden Aktivitäten lassen sich mittels cron recht einfach auslagern (z. B. der ftp Transfer), für andere müsste das GDS-Modul umgeschrieben werden. Details dazu gibt es z. B. in [http://forum.fhem.de/index.php/topic,38106.0.html diesem Thread] im Forum.

Nachfolgend noch eine Möglichkeit, das regelmäßige Laden der Karten vom Server in einen - dann FHEM nicht mehr blockierenden - cron-Job auszulagern:

Was Ihr wissen müsst:
*Wo legt das GDS-Modul die Karten ab? Z. B. im Temporär-Verzeichnis, /tmp. Wenn Ihr eine radarmap gespeichert habt, findet Ihr den Speicherort recht einfach, indem Ihr unter Linux <code>cd / && find . | grep gds_radarmap.jpg</code> ausführt.
*Wo liegen die Karten auf dem DWD-ftp-Server? Die Adresse des Servers ist [ftp://ftp-outgoing2.dwd.de ftp://ftp-outgoing2.dwd.de] und die Karten findet Ihr unterhalb von [ftp://ftp-outgoing2.dwd.de/gds/specials/ ftp://ftp-outgoing2.dwd.de/gds/specials/], z. B. die conditions maps unter [ftp://ftp-outgoing2.dwd.de/gds/specials/observations/maps/germany/ ftp://ftp-outgoing2.dwd.de/gds/specials/observations/maps/germany/], radarmaps unter [ftp://ftp-outgoing2.dwd.de/gds/specials/radar/ ftp://ftp-outgoing2.dwd.de/gds/specials/radar/] und dann dem passenden Unterverzeichnis für Eure Region, etc.
*Eure Login-Daten für den DWD ftp-server (habt Ihr vom DWD zugeschickt bekommen und in die Definition des GDS-Moduls eingetragen).

Anbei ein Beispielscript, das jeweils die neueste conditions- und Radarmap für Südwest-Deutschland holt und im /tmp-Verzeichnis ablegt:
<pre>
#!/bin/bash
if [ ! -d "/tmp/gds" ]; then
mkdir /tmp/gds
fi
# ftp-Server als Verzeichnis mounten:
curlftpfs ftp-outgoing2.dwd.de /tmp/gds -o user=user:pass
cd /tmp/gds/gds/specials/radar/southwest
NEUESTE_DATEI=$(ls -t | head -n 1)
echo Downloading ${NEUESTE_DATEI}...
cp "${NEUESTE_DATEI}" "/tmp/gds_radarmap.jpg"
echo ok.
chown fhem:dialout /tmp/gds_radarmap.jpg
cd /tmp/gds/gds/specials/observations/maps/germany
NEUESTE_DATEI=$(ls -t Suedwest* | head -n 1)
echo Downloading ${NEUESTE_DATEI}...
cp "${NEUESTE_DATEI}" "/tmp/gds_conditionsmap.jpg"
echo ok.
chown fhem:dialout /tmp/gds_conditionsmap.jpg
# unmount
fusermount -u /tmp/gds
</pre>

Hinweise:
*user:pass durch Eure Login-Daten für den Server ersetzen.
*/tmp ggf. anpassen, wenn bei Euch die GDS-Karten in einem anderen Verzeichnis liegen.
*"Suedwest" durch Eure Region ersetzen. Dateinamen können auf dem ftp-Server eingesehen werden.
*Die Angabe von user:pass im Klartext im Script ist unsicher. Sicherer wäre die Angabe einer versteckten und in den Rechten beschränkten Konfigurationsdatei.
*fhem:dialout sind die Rechte unter Debian. Mit einem <code>li -l</code> im Verzeichnis, in dem GDS die Karten ablegt, könnt Ihr Euch - vor dem Ausführen des Scripts - den Benutzer und die Rechte ansehen, wie das GDS-Modul bei Euch die Karten ablegt.
*Das Script braucht curlftpfs, das sich i.d.R. problemlos mittels <code>apt-get install curlftpfs</code> (Debian) o.ä. installieren lassen sollte.

Dann das Script noch regelmäßig über cron ausführen lassen, und schon blockiert Euer FHEM an einer Stelle weniger.

== Links ==
* [[Wetter und Wettervorhersagen]]

GDS

2015-09-06T06:55:20Z

Motivierte linke Hände: Hinweise auf Blocking, Anleitung zum Holen aktueller Karten außerhalb von FHEM

{{Infobox Modul
|ModPurpose=Herunterladen und Auswerten von Daten des Deutschen Wetterdienstes
|ModType=d
|ModForumArea=Unterstuetzende Dienste
|ModFTopic=14106
|ModTechName=55_GDS.pm
|ModOwner=betateilchen
}}
[[GDS]] ist ein Modul, mit dessen Hilfe man sich die Daten des Deutschen Wetterdienstes herunterladen kann und dann Wetterlage, diverse Wetterkarten und/oder Unwettermeldungen anzeigen/auswerten kann.

== Voraussetzungen ==
=== Anmeldung beim DWD ===
Als erstes muss man sich beim Deutschen Wetterdienst zur [http://www.dwd.de/grundversorgung Grundversorgung] kostenlos [http://kunden.dwd.de/gdsRegistration/gdsRegistrationStart.do anmelden].

=== Installation der benötigten Perl-Module ===
GDS benötigt die Perl-Module Net::FTP, List::MoreUtils, XML::Simple, Text::CSV.

Für Ubuntu und Raspi sollte funktionieren:

<code>apt-get install libnet-lite-ftp-perl liblist-moreutils-perl libxml-simple-perl libtext-csv-perl</code>

Das ftp-Modul verursacht manchmal Probleme bei der Installation. Teilweise ist es wohl auch schon in der Grundinstallation vorhanden, ansonsten kann man versuchen:

<code>apt-get install libnet-ftp-perl</code>

oder

<code>apt-get install libwww-perl</code>

== Anwendung ==
=== Define ===
<code>define [gdsName] GDS [gdsUsername] [gdsPasswort]</code>

[gdsUsername] und [gdsPasswort] gibt es nach Anmeldung vom DWD.

=== Attribute ===
Die vollständige Liste der Attribute ist in der [http://fhem.de/commandref.html#GDS commandref].

Station setzen, für die beim fhem-Start die Daten eingelesen werden sollen:

<code>attr [gdsName] gdsSetCond [Station]</code>

Hilfreich kann u.a. sein, wenn man hinter eine Firewall sitzt und der Datenabruf nicht funktioniert:

<code>attr [gdsName] gdsPassiveFtp 1</code>

== Anwendung ==
=== Liste der verfügbaren Wetterstationen abrufen ===
<code>get [gdsName] list stations</code>

=== Liste der verfügbaren Zellen für Warnungen abrufen ===
<code>get [gdsName] list capstations</code>

=== Manuelle Aktualisierung der Daten ===

==== Aktuelle Daten vom Server abrufen ====
<code>set [gdsName] rereadcfg</code>

==== Readings aus abgerufenen Daten aktualisieren ====
<code>set [gdsName] update</code>

=== Station setzen für automatischen, periodischen Abruf ===
<code>set [gdsName] conditions [Station]</code>

Automatisch abgerufen (alle 20 Minuten) werden nur die mit c_ beginnenden Readings. Die a_ Readings (Warnungen, etc.) müssen manuell aktualisiert werden.

=== Unwetterwarnungen nach Region aus gelesenen Daten raussuchen ===
<code>set [gdsName] warnings [Region]</code>

z.B.: <code> set gds warn Nordrhein-Westfalen</code>

Die Region kann ausgeschrieben oder mit den [http://www.bmelv-statistik.de/de/daten-tabellen-suche/abkuerzungen-der-bundeslaender/ offiziellen Abkürzungen] bezeichnet werden.

=== Unwetterwarnungen granularer nach Kreis aus gelesenenen Daten raussuchen ===
<code>set [gdsName] alerts [Warncell-ID]</code>

Die passende Warncell-ID kann man sich über <code>get [gdsName] list capstations</code> heraussuchen.

Ob es passende Warnmeldungen gibt, kann dann über das Reading <code>a_valid</code> abgefragt werden. Wenn <code>a_valid</code> 1 ist, gibt <code>a_count</code> die Anzahl der vorhandenen Warnmeldungen an. Die Warnungen stehen dann in den Readings <code>a_X_...</code>, wobei X ab 0 hochzählt. D.h. wenn <code>a_count</code> 2 ist, gibt es a_0_... und a_1_... Ein praktisches Reading ist z.B. <code>a_X_headline</code>, das die Zusammenfassung der jeweiligen Warnung als kurze Textzusammenfassung enthält.

Alle eingelesenen Warnmeldungen kann man sich über die Funktion <code>gdsHeadlines()</code> ausgeben lassen. Z.B. einfach in der Befehlszeile von fhem eingeben:

<code>{gdsHeadlines([gdsName])}</code>

Wer möchte, kann auch das Trennzeichen bei mehreren Meldungen konfigurieren:

<code>{gdsHeadlines([gdsName],'[Trennzeichen]')}</code>

Z.B. also

<code>{gdsHeadlines(gds, '***')}</code>

Standard für das Trennzeichen ist der senkrechte Strich.

Jedenfalls nach <code>attr [gdsName] gdsLong 1</code> werden in a_X_description die Langmeldungen zu den Warnungen ausgegeben.

=== Aktuelles Wetter abrufen ===
<code>get [gdsName] conditions [Station]</code>

=== Karten abrufen ===
Wetterlage: <code>get [gdsName] conditionsmap [Station] </code>

Vorhersage: <code>get [gdsName] forecastsmap [Station]</code>

Warnungen: <code>get [gdsName] warningsmap [Station]</code>

Radar: <code>get [gdsName] radarmap [Station]</code>

== Readings ==

<pre>
Höhe : m über NN
Luftd.: reduzierter Luftdruck auf Meereshöhe in hPa
TT : Lufttemperatur in Grad Celsius
Tn12 : Minimum der Lufttemperatur, 18 UTC Vortag bis 06 UTC heute, Grad Celsius
Tx12 : Maximum der Lufttemperatur, 18 UTC Vortag bis 06 UTC heute, Grad Celsius
Tg24 : Temperaturminimum 5cm über Erdboden 00 UTC bis 24 UTC, Grad Celsius
Tn24 : Minimum der Lufttemperatur, 00 UTC bis 24 UTC, Grad Celsius
Tm24 : Mittel der Lufttemperatur, 00 UTC bis 24 UTC, Grad Celsius
Tx24 : Maximum der Lufttemperatur, 00 UTC bis 24 UTC, Grad Celsius
Tmin : Minimum der Lufttemperatur, 06 UTC Vortag bis 06 UTC heute, Grad Celsius
Tmax : Maximum der Lufttemperatur, 06 UTC Vortag bis 06 UTC heute, Grad Celsius
RR1 : Niederschlagsmenge, einstündig, mm = l/qm
RR12 : Niederschlagsmenge, 12stündig, 18 UTC Vortag bis 06 UTC heute, mm = l/qm
RR24 : Niederschlagsmenge, 24stündig, 06 UTC Vortag bis 06 UTC heute, mm = l/qm
SSS : Gesamtschneehöhe in cm
SSS24 : Sonnenscheindauer in Stunden
SGLB24: Tagessumme Globalstrahlung in J/qcm
DD : Windrichtung
FF : Windgeschwindigkeit letztes 10-Minutenmittel in km/h
FX : höchste Windspitze im Bezugszeitraum in km/h
</pre>

== Anwendungsbeispiele ==

Für GDS sollten die Daten regelmäßig aktualisiert werden. Dafür richtet man am besten '''zwei''' zeitlich '''nacheinander''' laufende ats ein:

Einen zum Holen aktualisierter Daten vom Server:

<pre>
define readGDS at +*00:10:00 get [gdsName] rereadcfg
attr readGDS alignTime 22:30:05
</pre>

Einen zweiten, der danach läuft, der aus den aktualisierten Serverdaten dann die Readings aktualisiert; z.B. für die Alerts:

<pre>
define checkGDS at +*00:10:00 get [gdsName] alerts [Region]
attr checkGDS alignTime 22:35:05
</pre>

Wichtig ist, dass beide at zeitlich auseinander liegen, im vorstehenden Beispiel durch die unterschiedlichen "alignTime" Attribute um 5 Minuten.

=== Karten regelmäßig vom Server neu laden ===

<code>define Karten at +*00:30:00 get [gdsName] radarmap Nordost; get [gdsName] conditionsmap Nordost; get [gdsName] warningsmap Berlin</code>

Hinweis: Die vorstehende Schreibweise ist die Schreibweise im Editiermodus der Weboberfläche von fhem. Wer die Zeile per copy & paste direkt in die Kommandozeile eintragen will, muss die Semikolons verdoppeln, sonst geht alles nach dem ersten Semikolon verloren.

Also:

<code>define Karten at +*00:30:00 get [gdsName] radarmap Nordost;; get [gdsName] conditionsmap Nordost;; get [gdsName] warningsmap Berlin</code>

== Bekannte Probleme ==
Das eingecheckte GDS-Modul ist nicht auf "non-blocking" umgeschrieben. Das führt dazu, dass FHEM immer mal wieder "einfriert" (nichts macht), während auf die Rückmeldung von, z. B., einem FTP-Transfer ("get [gdsName] conditionsmap" etc.) gewartet wird. Das kann bei Timing-kritischen Bestandteilen zu Problemen führen, weil Events nicht mitbekommen werden, die Ansteuerung von Geräten nicht funktioniert, etc.

Einige dieser FHEM blockierenden Aktivitäten lassen sich mittels cron recht einfach auslagern (z. B. der ftp Transfer), für andere müsste das GDS-Modul umgeschrieben werden. Details dazu gibt es z. B. in [http://forum.fhem.de/index.php/topic,38106.0.html diesem Thread] im Forum.

Nachfolgend noch eine Möglichkeit, das regelmäßige Laden der Karten vom Server in einen - dann FHEM nicht mehr blockierenden - cron-Job auszulagern:

Was Ihr wissen müsst:
*Wo legt das GDS-Modul die Karten ab? Z. B. im Temporär-Verzeichnis, /tmp. Wenn Ihr eine radarmap gespeichert habt, findet Ihr den Speicherort recht einfach, indem Ihr unter Linux <code>cd / && find . | grep gds_radarmap.jpg</code> ausführt.
*Wo liegen die Karten auf dem DWD-ftp-Server? Die Adresse des Servers ist [ftp://ftp-outgoing2.dwd.de ftp://ftp-outgoing2.dwd.de] und die Karten findet Ihr unterhalb von [ftp://ftp-outgoing2.dwd.de/gds/specials/ ftp://ftp-outgoing2.dwd.de/gds/specials/], z. B. die conditions maps unter [ftp://ftp-outgoing2.dwd.de/gds/specials/observations/maps/germany/ ftp://ftp-outgoing2.dwd.de/gds/specials/observations/maps/germany/], radarmaps unter [ftp://ftp-outgoing2.dwd.de/gds/specials/radar/ ftp://ftp-outgoing2.dwd.de/gds/specials/radar/] und dann dem passenden Unterverzeichnis für Eure Region, etc.
*Eure Login-Daten für den DWD ftp-server (habt Ihr vom DWD zugeschickt bekommen und in die Definition des GDS-Moduls eingetragen).

Anbei ein Beispielscript, das jeweils die neueste conditions- und Radarmap für Südwest-Deutschland holt und im /tmp-Verzeichnis ablegt:
<pre>
#!/bin/bash
if [ ! -d "/tmp/gds" ]; then
mkdir /tmp/gds
fi
# ftp-Server als Verzeichnis mounten:
curlftpfs ftp-outgoing2.dwd.de /tmp/gds -o user=user:pass
cd /tmp/gds/gds/specials/radar/southwest
NEUESTE_DATEI=$(ls -t | head -n 1)
echo Downloading ${NEUESTE_DATEI}...
cp "${NEUESTE_DATEI}" "/tmp/gds_radarmap.jpg"
echo ok.
chown fhem:dialout /tmp/gds_radarmap.jpg
cd /tmp/gds/gds/specials/observations/maps/germany
NEUESTE_DATEI=$(ls -t Suedwest* | head -n 1)
echo Downloading ${NEUESTE_DATEI}...
cp "${NEUESTE_DATEI}" "/tmp/gds_conditionsmap.jpg"
echo ok.
chown fhem:dialout /tmp/gds_conditionsmap.jpg
# unmount
fusermount -u /tmp/gds
</pre>

Hinweise:
*user:pass durch Eure Login-Daten für den Server ersetzen.
*/tmp ggf. anpassen, wenn bei Euch die GDS-Karten in einem anderen Verzeichnis liegen.
*"Suedwest" durch Eure Region ersetzen. Dateinamen können auf dem ftp-Server eingesehen werden.
*Die Angabe von user:pass im Klartext im Script ist unsicher. Sicherer wäre die Angabe einer versteckten und in den Rechten beschränkten Konfigurationsdatei.
*fhem:dialout sind die Rechte unter Debian. Mit einem <code>li -l</code> im Verzeichnis, in dem GDS die Karten ablegt, könnt Ihr Euch - vor dem Ausführen des Scripts - den Benutzer und die Rechte ansehen, wie das GDS-Modul bei Euch die Karten ablegt.
*Das Script braucht curlftpfs, das sich i.d.R. problemlos mittels <code>apt-get install curlftpfs</code> (Debian) o.ä. installieren lassen sollte.

Dann das Script noch regelmäßig über cron ausführen lassen, und schon blockiert Euer FHEM an einer Stelle weniger.

== Links ==
* [[Wetter und Wettervorhersagen]]

Hue

2015-09-04T09:55:32Z

Motivierte linke Hände: Hinweis auf httpUtils 1 (nonblocking) ergänzt.

<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 . 
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-icon zu setzen. Mit <code>attr HUEDevice1 color-icon 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 lib-Verzeichnis 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]]

FRITZBOX

2015-09-04T09:25:06Z

Motivierte linke Hände: Anwesenheitserkennung per Notify aufgenommen

{{Infobox Modul
|ModPurpose=Steuerung einer Fritz!Box über Fhem
|ModType=d
|ModForumArea=FRITZ!Box
|ModTechName=72_FRITZBOX.pm
|ModOwner=tupol/Topos ([http://forum.fhem.de/index.php?action=profile;u=5432 Forum] / [[Benutzer Diskussion:Topos|Wiki]])}}

Das Modul [[FRITZBOX]] ermöglicht die Steuerung einer [[AVM Fritz!Box]] und von AVM FRITZ!WLAN Repeatern durch Fhem. An Fritzboxen können sowohl Geräte abgefragt werden, auf denen FHEM selbst läuft (lokaler Modus), als auch um eine entfernte (externe) Geräte.

== Voraussetzungen ==
=== Remote-Zugang ===
Für den Remote-Zugang müssen die Module JSON:XS, LWP und SOAP::Lite installiert sein; auf einem [[Raspberry Pi]] oder unter Ubuntu z. B. mit dem Befehl
:::<code>sudo apt-get install libjson-perl libwww-perl libsoap-lite-perl libjson-xs-perl</code>

Teilweise ist derzeit zusätzlich die Installation der telnet Libraries erforderlich, auch wenn der Telnet-Zugang nicht genutzt werden soll. Siehe dazu den nachfolgenden Abschnitt.

=== Telnet ===
Das Modul basierte ursprünglich auf dem Zugriff auf die Fritzbox per Telnet. Ab FRITZ!OS 6.2x baut AVM den abgekündigten Telnet-Zugang sowie die webcm-Schnittstelle sukzessive zurück bzw. hat dies, je nach Firmware, schon ganz abgestellt (siehe {{Link2Forum|Topic=38586|LinkText=dieses Forenthema}}). Der zukunftssichere Zugriff auf die Fritzbox sollte also per TR-064 erfolgen. Der Vollständigkeit halber und für ältere Firmwareversionen:

# Wer den Zugang per Telnet (noch) nutzen (kann und) möchte, muss dies zuerst freischalten. Üblicherweise durch Eingabe von #96*7* an einem direkt an der entsprechenden FritzBox angeschlosssenen Telefon

# Auf dem System, auf dem Fhem läuft ([[Systemübersicht#Server|Server]]) muss Telnet installiert sein; auf einem [[Raspberry Pi]] und unter Ubuntu z. B. mit dem Befehl
:::<code>sudo apt-get install libnet-telnet-perl</code>

== Installation ==

=== Erste Schritte ===
Zur Erstinstallation reicht ein einfaches <code>define FritzBox FRITZBOX</code>, dieses Modul funktioniert lokal (FHEM auf Fritzbox) sowie per Fernzugriff (FHEM auf einem anderen Server im Netz, siehe nächsten Schritt).

==== TR-064: Modul FRITZBOX für Zugriff auf einem externen Server einrichten ====
Für den Fernzugriff über TR-064 auf eine oder mehrere Fritzboxen und/oder einen FRITZ!WLAN Repeater sind die folgenden Schritte nötig (für jedes Gerät):

Fritzbox definieren:
:<code>define FritzBox FRITZBOX</code>

Wenn das Login auf der Benutzeroberfläche der FritzBox mit User und Passwort (und nicht nur per Passwort) geschieht, den User konfigurieren:
:<code>attr FritzBox boxUser ''Benutzername'' </code>

Passwort konfigurieren:
:<code>set FritzBox password ''Passwort'' </code> - legt das zugehörige Passwort fest

Manuelle TR-064 Kommandos erlauben (die Abfrage per TR-064 funktioniert auch ohne dieses Attribut):
:<code>attr FritzBox allowTR064Command 1</code>

Wenn die Fritzbox nicht unter http://fritz.box erreichbar ist, IP setzen:
:<code>attr FritzBox fritzBoxIP 192.168.168.168</code>
192.168.168.168 dabei natürlich durch die passende IP ersetzen... Alternativ kann bei fritzBoxIP - trotz des Namens des Attributs - statt der IP auch der Hostname eingegeben werden, eine DNS-Auflösung findet statt.

Manchmal ist ein Neustart von FHEM erforderlich, damit die Fritzbox mit der veränderten IP gefunden wird.

==== Telnet: Modul FRITZBOX für Zugriff auf einem externen Server einrichten ====
[[Datei:Screenshot_FritzBox_TelnetUser.png|mini|300px|rechts|Anlegen des Attributs telnetUser]]
Bei Fernzugriff über Telnet sind weitere Schritte nötig:
# Telnet auf der Fritzbox freischalten (Tastenkombination #96*7* am angeschlossenen Telefon (auch FritzFon)
# TelnetUser definieren (wie im Screenshot gezeigt)
# Passwort zum Benutzer auf der Fritzbox definieren

[[Datei:Screenshot_FritzBox_Passwort.png|mini|300px|rechts|Passwort definieren]]

(bitte die Buttons {{Taste|set}} und {{Taste|attr}} bei der Definition der jeweiligen Einträge nicht vergessen)

Wer stattdessen lieber das [[Konfiguration|Befehl-Eingabefeld]] verwendet:

:<code>define FritzBox FRITZBOX</code>
:<code>attr FritzBox telnetUser ''Benutzername'' </code> - legt den Benutzer fest
:<code>set FritzBox password ''Passwort'' </code> - legt das zugehörige Passwort fest

Wer keinen User konfiguriert hat, kann das Feld "telnetUser" leer lassen.

Wer sicher gehen möchte, dass auch tatsächlich Telnet und nicht andere Zugriffe benutzt werden, sollte außerdem noch setzen:

:<code>attr FritzBox forceTelnetConnection 1</code>

=== mögliche Fehlermeldungen ===
Sollte schon bei <code>define FritzBox FRITZBOX</code> die Fehlermeldung kommen, dass dieses Modul nicht existiert, dann bitte prüfen, ob Fhem auf dem aktuellen Stand ist und ggf. [[Update|aktualisieren]].

Kommt jetzt bei der erneuten Definition die Fehlermeldung <code>Error: Perl modul Net::Telnet is missing on this system</code> bitte wie oben schon erwähnt den Befehl
:<code>sudo apt-get install libnet-telnet-perl</code>
direkt per Telnet/SSH auf dem FHEM-Server ausführen und neu starten.
Sollte alles geklappt haben, seht ihr nun eure Fritzbox und könnt diverse Einstellungen manuell vornehmen und/oder automatisch vornehmen lassen.

== Anwendung ==
=== Define ===
Siehe [http://fhem.de/commandref_DE.html#FRITZBOX commandref]

=== Attribute ===
Siehe commandref

=== TR-064 ===
Die offizielle Programmier-Schnittstelle der Fritz!Box läuft über das Protokoll TR-064.

mit dem Attribute 
<code>attr <device> allowTR064Command 1</code> 
kann man den Befehl 
<code>get <device> tr064Command <service> <control> <action> [[parameterName1 parameterValue1] ...]</code> 
freischalten und damit auf diese Schnittstelle zugreifen.

AVM hat die Schnittstellenbeschreibung unter [http://avm.de/service/schnittstellen/] veröffentlicht. Ein weitere Einstiegspunkt befindet sich auch auf der Box unter http://fritz.box:49000/tr64desc.xml

Folgende Service und Controls existieren (für den get-Befehl werden nur die fett formatierten Wörter benötigt)

{| class="wikitable"
|-
!serviceType!!controlURL!!XML!!Dokument bei AVM
|-
|<nowiki>urn:dslforum-org:service:</nowiki>'''DeviceInfo:1'''||/upnp/control/'''deviceinfo'''||[http://fritz.box:49000/deviceinfoSCPD.xml deviceinfoSCPD.xml]||[http://avm.de/fileadmin/user_upload/Global/Service/Schnittstellen/deviceinfoSCPD.pdf deviceinfoSCPD.pdf]
|-
|<nowiki>urn:dslforum-org:service:</nowiki>'''DeviceConfig:1'''||/upnp/control/'''deviceconfig'''||[http://fritz.box:49000/deviceconfigSCPD.xml deviceconfigSCPD.xml]||[http://avm.de/fileadmin/user_upload/Global/Service/Schnittstellen/deviceconfigSCPD.pdf deviceconfigSCPD.pdf]
|-
|<nowiki>urn:dslforum-org:service:</nowiki>'''Layer3Forwarding:1'''||/upnp/control/'''layer3forwarding'''||[http://fritz.box:49000//layer3forwardingSCPD.xml layer3forwardingSCPD.xml]||[http://avm.de/fileadmin/user_upload/Global/Service/Schnittstellen/layer3forwardingSCPD.pdf layer3forwardingSCPD.pdf]
|-
|<nowiki>urn:dslforum-org:service:</nowiki>'''LANConfigSecurity:1'''||/upnp/control/'''lanconfigsecurity'''||[http://fritz.box:49000//lanconfigsecuritySCPD.xml lanconfigsecuritySCPD.xml]||[http://avm.de/fileadmin/user_upload/Global/Service/Schnittstellen/lanconfigsecuritySCPD.pdf lanconfigsecuritySCPD.pdf]
|-
|<nowiki>urn:dslforum-org:service:</nowiki>'''ManagementServer:1'''||/upnp/control/'''mgmsrv'''||[http://fritz.box:49000//mgmsrvSCPD.xml mgmsrvSCPD.xml]||[http://avm.de/fileadmin/user_upload/Global/Service/Schnittstellen/mgmsrvSCPD.pdf mgmsrvSCPD.pdf]
|-
|<nowiki>urn:dslforum-org:service:</nowiki>'''Time:1'''||/upnp/control/'''time'''||[http://fritz.box:49000//timeSCPD.xml timeSCPD.xml]||[http://avm.de/fileadmin/user_upload/Global/Service/Schnittstellen/timeSCPD.pdf timeSCPD.pdf]
|-
|<nowiki>urn:dslforum-org:service:</nowiki>'''UserInterface:1'''||/upnp/control/'''userif'''||[http://fritz.box:49000//userifSCPD.xml userifSCPD.xml]||[http://avm.de/fileadmin/user_upload/Global/Service/Schnittstellen/userifSCPD.pdf userifSCPD.pdf]
|-
|<nowiki>urn:dslforum-org:service:</nowiki>'''X_VoIP:1'''||/upnp/control/'''x_voip'''||[http://fritz.box:49000//x_voipSCPD.xml x_voipSCPD.xml]||[http://avm.de/fileadmin/user_upload/Global/Service/Schnittstellen/x_voipSCPD.pdf x_voipSCPD.pdf]
|-
|<nowiki>urn:dslforum-org:service:</nowiki>'''X_AVM-DE_Storage:1'''||/upnp/control/'''x_storage'''||[http://fritz.box:49000//x_storageSCPD.xml x_storageSCPD.xml]||[http://avm.de/fileadmin/user_upload/Global/Service/Schnittstellen/x_storageSCPD.pdf x_storageSCPD.pdf]
|-
|<nowiki>urn:dslforum-org:service:</nowiki>'''X_AVM-DE_OnTel:1'''||/upnp/control/'''x_contact'''||[http://fritz.box:49000//x_contactSCPD.xml x_contactSCPD.xml]||[http://avm.de/fileadmin/user_upload/Global/Service/Schnittstellen/x_contactSCPD.pdf x_contactSCPD.pdf]
|-
|<nowiki>urn:dslforum-org:service:</nowiki>'''X_AVM-DE_WebDAVClient:1'''||/upnp/control/'''x_webdav'''||[http://fritz.box:49000//x_webdavSCPD.xml x_webdavSCPD.xml]||[http://avm.de/fileadmin/user_upload/Global/Service/Schnittstellen/x_webdavSCPD.pdf x_webdavSCPD.pdf]
|-
|<nowiki>urn:dslforum-org:service:</nowiki>'''X_AVM-DE_UPnP:1'''||/upnp/control/'''x_upnp'''||[http://fritz.box:49000//x_upnpSCPD.xml x_upnpSCPD.xml]||[http://avm.de/fileadmin/user_upload/Global/Service/Schnittstellen/x_upnp.pdf x_upnp.pdf]
|-
|<nowiki>urn:dslforum-org:service:</nowiki>'''X_AVM-DE_RemoteAccess:1'''||/upnp/control/'''x_remote'''||[http://fritz.box:49000/x_remoteSCPD.xml x_remoteSCPD.xml]||[http://avm.de/fileadmin/user_upload/Global/Service/Schnittstellen/x_remoteSCPD.pdf x_remoteSCPD.pdf]
|-
|<nowiki>urn:dslforum-org:service:</nowiki>'''X_AVM-DE_MyFritz:1'''||/upnp/control/'''x_myfritz'''||[http://fritz.box:49000/x_myfritzSCPD.xml x_myfritzSCPD.xml]||[http://avm.de/fileadmin/user_upload/Global/Service/Schnittstellen/x_myfritzSCPD.pdf x_myfritzSCPD.pdf]
|-
|<nowiki>urn:dslforum-org:service:</nowiki>'''X_AVM-DE_TAM:1'''||/upnp/control/'''x_tam'''||[http://fritz.box:49000/x_tamSCPD.xml x_tamSCPD.xml]||[http://avm.de/fileadmin/user_upload/Global/Service/Schnittstellen/x_tam.pdf x_tam.pdf]
|-
|<nowiki>urn:dslforum-org:service:</nowiki>'''X_AVM-DE_AppSetup:1'''||/upnp/control/'''x_appsetup'''||[http://fritz.box:49000/x_homeautoSCPD.xml x_homeautoSCPD.xml]||[http://avm.de/fileadmin/user_upload/Global/Service/Schnittstellen/x_appsetupSCPD.pdf x_appsetupSCPD.pdf]
|-
|<nowiki>urn:dslforum-org:service:</nowiki>'''X_AVM-DE_Homeauto:1'''||/upnp/control/'''x_homeauto'''||[http://fritz.box:49000/x_homeautoSCPD.xml x_homeautoSCPD.xml]||[http://avm.de/fileadmin/user_upload/Global/Service/Schnittstellen/x_homeautoSCPD.pdf x_homeautoSCPD.pdf]
|-
|<nowiki>urn:dslforum-org:service:</nowiki>'''WLANConfiguration:1'''||/upnp/control/'''wlanconfig1'''||[http://fritz.box:49000/wlanconfigSCPD.xml wlanconfigSCPD.xml]||[http://avm.de/fileadmin/user_upload/Global/Service/Schnittstellen/wlanconfigSCPD.pdf wlanconfigSCPD.pdf]
|-
|<nowiki>urn:dslforum-org:service:</nowiki>'''WLANConfiguration:2'''||/upnp/control/'''wlanconfig2'''||[http://fritz.box:49000/wlanconfigSCPD.xml wlanconfigSCPD.xml]||[http://avm.de/fileadmin/user_upload/Global/Service/Schnittstellen/wlanconfigSCPD.pdf wlanconfigSCPD.pdf]
|-
|<nowiki>urn:dslforum-org:service:</nowiki>'''WLANConfiguration:3'''||/upnp/control/'''wlanconfig3'''||[http://fritz.box:49000/wlanconfigSCPD.xml wlanconfigSCPD.xml]||[http://avm.de/fileadmin/user_upload/Global/Service/Schnittstellen/wlanconfigSCPD.pdf wlanconfigSCPD.pdf]
|-
|<nowiki>urn:dslforum-org:service:</nowiki>'''Hosts:1'''||/upnp/control/'''hosts'''||[http://fritz.box:49000/hostsSCPD.xml hostsSCPD.xml]||[http://avm.de/fileadmin/user_upload/Global/Service/Schnittstellen/hostsSCPD.pdf hostsSCPD.pdf]
|-
|<nowiki>urn:dslforum-org:service:</nowiki>'''LANEthernetInterfaceConfig:1'''||/upnp/control/'''lanethernetifcfg'''||[http://fritz.box:49000/lanifconfigSCPD.xml lanifconfigSCPD.xml]||[http://avm.de/fileadmin/user_upload/Global/Service/Schnittstellen/lanifconfigSCPD.pdf lanifconfigSCPD.pdf]
|-
|<nowiki>urn:dslforum-org:service:</nowiki>'''LANHostConfigManagement:1'''||/upnp/control/'''lanhostconfigmgm'''||[http://fritz.box:49000/lanhostconfigmgmSCPD.xml lanhostconfigmgmSCPD.xml]||[http://avm.de/fileadmin/user_upload/Global/Service/Schnittstellen/lanhostconfigmgmSCPD.pdf lanhostconfigmgmSCPD.pdf]
|-
|<nowiki>urn:dslforum-org:service:</nowiki>'''WANCommonInterfaceConfig:1'''||/upnp/control/'''wancommonifconfig1'''||[http://fritz.box:49000/wancommonifconfigSCPD.xml wancommonifconfigSCPD.xml]||[http://avm.de/fileadmin/user_upload/Global/Service/Schnittstellen/wancommonifconfigSCPD.pdf wancommonifconfigSCPD.pdf]
|-
|<nowiki>urn:dslforum-org:service:</nowiki>'''WANDSLInterfaceConfig:1'''||/upnp/control/'''wandslifconfig1'''||[http://fritz.box:49000/wandslifconfigSCPD.xml wandslifconfigSCPD.xml]||[http://avm.de/fileadmin/user_upload/Global/Service/Schnittstellen/wandslifconfigSCPD.pdf wandslifconfigSCPD.pdf]
|-
|<nowiki>urn:dslforum-org:service:</nowiki>'''WANDSLLinkConfig:1'''||/upnp/control/'''wandsllinkconfig1'''||[http://fritz.box:49000/wandsllinkconfigSCPD.xml wandsllinkconfigSCPD.xml]||[http://avm.de/fileadmin/user_upload/Global/Service/Schnittstellen/wandsllinkconfigSCPD.pdf wandsllinkconfigSCPD.pdf]
|-
|<nowiki>urn:dslforum-org:service:</nowiki>'''WANEthernetLinkConfig:1'''||/upnp/control/'''wanethlinkconfig1'''||[http://fritz.box:49000/wanethlinkconfigSCPD.xml wanethlinkconfigSCPD.xml]||[http://avm.de/fileadmin/user_upload/Global/Service/Schnittstellen/wanethlinkconfigSCPD.pdf wanethlinkconfigSCPD.pdf]
|-
|<nowiki>urn:dslforum-org:service:</nowiki>'''WANPPPConnection:1'''||/upnp/control/'''wanpppconn1'''||[http://fritz.box:49000/wanpppconnSCPD.xml wanpppconnSCPD.xml]||[http://avm.de/fileadmin/user_upload/Global/Service/Schnittstellen/wanpppconnSCPD.pdf wanpppconnSCPD.pdf]
|-
|<nowiki>urn:dslforum-org:service:</nowiki>'''WANIPConnection:1'''||/upnp/control/'''wanipconnection1'''||[http://fritz.box:49000/wanipconnSCPD.xml wanipconnSCPD.xml]||[http://avm.de/fileadmin/user_upload/Global/Service/Schnittstellen/wanipconnSCPD.pdf wanipconnSCPD.pdf]
|-
|}

=== Status-Symbol ===
<code>attr <device> devStateIcon .*on.*off:WLAN_on_gWLAN_off .*on.*on.*:WLAN_on_gWLAN_on WLAN..off.*:WLAN_off</code>

Im Verzeichnis www/images/default müssen die passenden Dateien "WLAN_on_gWLAN_off.png", "WLAN_on_gWLAN_on.png" und "WLAN_off.png" liegen. Wenn die PNGs fehlen, können sie hier [http://forum.fhem.de/index.php/topic,29725.msg318113.html#msg318113] heruntergeladen werden.

== Anwendungsbeispiele ==
[[Datei:Screenshot_FritzBox1.png|mini|300px|rechts|FRITZBOX Gerät auf der Fhem Oberfläche]]
Sollte alles geklappt haben, seht ihr nun unter "Unsortiert" den im nebenstehenden Screenshot gezeigten Eintrag für das "Gerät" (hier mit dem Icon "it_router").

=== TR-064 Bespiele ===

*Box Reboot: <code>get <device> tr064Command DeviceConfig:1 deviceconfig Reboot</code>

=== Klingel- und Sprachausgabe per TR-064 ===

Das geht derzeit nicht, da entsprechende Kommandos per TR-064 nicht verfügbar sind. Da Telnet sukzessive abgestellt wird, sollten sich Interessenten per Feature-Request an AVM wenden, wie hier [http://forum.fhem.de/index.php/topic,38586.0.html] beschrieben.

=== Anwesenheitserkennung per regelmäßiger Abfrage über das PRESENCE Modul ===

Fritzboxen und die FRITZ!WLAN Repeater speichern den Status angemeldeter Geräte. Dieser Status lässt sich mittels des FRITZBOX Moduls über Readings abfragen, die das Format mac_AA_AA_AA_AA_AA_AA haben und die MAC-Adressen der jeweils angemeldeten Geräte (AA:AA:AA:AA:AA:AA) enthalten. Das Reading existiert, wenn das Gerät angemeldet ist. Wenn das Gerät abgemeldet ist, existiert es ist. Es gibt auch noch den Zwischenstatus "inactive", der anscheinend gesetzt wird, bevor das Reading gelöscht wird.

Mit Hilfe des PRESENCE Moduls (vgl. [[Anwesenheitserkennung]]) kann man auf diese Weise den Anwesenheitsstatus abfragen. Anregungen dazu gibt es im zugehörigen {{Link2Forum|Topic=39433|LinkText=Forenthread}} zur Anwesenheitserkennung und in einem Blogpost: [http://heinz-otto.blogspot.de/2015/07/die-zeiten-andern-sich.html]. Auf dieser Basis könnte eine einfache Implementierung zum Beispiel so aussehen:

Funktion in 99_myUtils.pm:

<pre>sub checkFritzMACpresent($$) {
# Benötigt: Name der zu testenden Fritzbox ($Device),
# zu suchende MAC ($MAC),
# Rückgabe: 1 = Gerät gefunden
# 0 = Gerät nicht gefunden
my ($Device, $MAC) = @_;
my $Status = 0;
$MAC =~ tr/:/_/;
$MAC = "mac_".uc($MAC);
my $StatusFritz = ReadingsVal($Device, $MAC, "weg");
if ($StatusFritz eq "weg") {
Log 1, ("checkFritzMACpresent ($Device): $MAC nicht gefunden, abwesend.");
$Status = 0;
} elsif ($StatusFritz eq "inactive") {
Log 1, ("checkFritzMACpresent ($Device): $MAC ist >inactive<, also abwesend.");
$Status = 0;
} else {
# Reading existiert, Rückgabewert ist nicht "inactive", also ist das Gerät per WLAN angemeldet.
Log 1, ("checkFritzMACpresent ($Device): $MAC gefunden, Gerät heißt >$StatusFritz<.");
$Status = 1;
}
return $Status
}
</pre>

Nutzung dieser Funktion mit dem PRESENCE Modul definieren:

<code>define <Name> PRESENCE function {checkFritzMACpresent("Fritzbox","AA:BB:CC:DD:EE:FF")} 60 60</code>

wobei
*<Name> ein beliebig zu wählender Name für die PRESENCE-Funktion ist,
*Fritzbox der Name ist, mit dem ihr die abzufragende Fritzbox als FRITZBOX definiert habt,
*AA:BB:CC:DD:EE:FF die MAC-Adresse des gesuchten Geräts ist.
* "60 60" sagt, dass der Anwesenheitsstatus im 60-Sekunden-Takt abgefragt wird. Das macht natürlich nur Sinn, wenn ihr mit <code>attr Fritzbox INTERVAL 60</code> den Abfrageinterval bei der Fritzbox auch entsprechend hochgesetzt habt. Der Standard ist 300.
* "Log 1" führt immer zum Loggen. Das ist zum Einrichten praktisch, ohne dass man gleich für das ganze Modul oder ganz FHEM <code>attr <device> verbose 5</code> setzen muss. Wenn es läuft, können die "Log 1"-Zeilen gelöscht, auskommentiert (# an den Zeilenanfang) oder in "Log 5" geändert werden.

==== Mehrere Fritzboxen oder Repeater und Fritzbox (wird noch bearbeitet) ====
Existiert ein AVM Repeater im Netzwerk, kann der als eigenständiges Gerät mit FRITZBOX definiert werden. WLAN Geräte an der Fritzbox werden in der Instanz der Fritzbox gelistet und WLAN Geräte am Repeater in der Repeater Instanz. Um trotzdem die Anwesenheit im Netzwerk einfach zu erkennen muss die Subroutine in 99_myUtils abgewandelt werden.

<pre>my @fbs = devspec2array("TYPE=FRITZBOX"); (Nur als Hinweis)
</pre>

Existiert eine zweite Fritzbox im Accesspointmodus werden die WLAN Geräte im Netzwerk alle in der Hauptfritzbox an einem LAN Anschluss gelistet. D.h. man sieht an der Hauptfritzbox nicht, dass sie im WLAN sind. Eine zweite Instanz mit dem FRITZBOX Modul muss wegen der Anwesenheitserkennung nicht gemacht werden.

Weitere Hinweise zu komplexeren Abfragen mehrere Boxen auf einmal etc. findet ihr auch im {{Link2Forum|Topic=39433|LinkText=Forenthread}}.

=== Anwesenheitserkennung per Notify ===
Der von Fritzboxen und Fritz!WLAN Repeatern gespeicherte Status zum Status angemeldeter Geräte lässt sich (statt per PRESENCE, s.o.) auch per Notify anfragen:

<pre>define <Name> notify Fritzbox:mac_AA_BB_CC_DD_EE_FF:.* {
if (ReadingsVal("Fritzbox", "mac_AA_BB_CC_DD_EE_FF", "inactive") eq "inactive") {
fhem("set anwesend_smartphone absent");
} else
fhem("set anwesend_smartphone present");
}
}</pre>

Hinweise:
*[code]fhem("set anwesend_smartphone absent");[/code] ist nur ein Beispiel, das einen Dummy auf den Status "absent" bzw. "present" setzt. Man kann hier natürlich auch gleich entsprechende Aktionen durchführen. Wer das Beispiel übernehmen möchte, sollte den Dummy vorher definieren ([code]define anwesend_smartphone dummy[/code]).
*mac_AA_BB_CC_DD_EE_FF ist die MAC-Adresse des gesuchten Geräts.
*"Fritzbox" ist der Name, unter dem die Fritzbox als FRITZBOX-Modul definiert wurde.
*Das Notify funktioniert, weil Geräte, wenn sie sich abgemeldet haben, erst den Status "inactive" erhalten. Ist das Gerät ganz abgemeldet, verschwindet das mac_.*-Reading. Dabei löst das Notify nicht mehr aus. Da das mac-.*-Reading aber vorher auf "inactive" stand, wurde die Abwesend-Aktion schon ausgeführt.
*Damit der Notify nicht andauernd losgeht, sollte man mittels [code]attr Fritzbox event-on-change-reading mac_AA_BB_CC_DD_EE_FF[/code] Events nur auslösen, wenn sich der Status des Gerätes ändert. Will man mehrere Geräte abfragen, sollte man [code]attr Fritzbox event-on-change-reading mac_AA_BB_CC_DD_EE_FF,mac_GG_HH_II_JJ_KK_LL[/code] setzen, damit bei der Änderung jedes Readings ein Event ausgelöst wird.

=== Vergleich Anwesenheitserkennung PRESENCE/Notify ===
Die Anwesenheitserkennung per regelmäßiger PRESENCE-Abfrage hat den Vorteil, dass sie im Turnus der regelmäßigen Abfragen immer einen aktuellen Status produziert. Sie hat dafür den Nachteil, dass die PRESENCE-Funktionen regelmäßig abgearbeitet werden müssen, auch wenn sich gar nichts ändert. Außerdem aktualisiert sich der Status nicht sofort, sondern erst bei der nächsten regelmäßigen Abfrage. Durch häufiges Abfragen, kann dieser Nachteil verringert werden (bei entsprechend höherer Systemlast).

Die Anwesenheitserkennung per Notify hat den Vorteil, dass ein sich ändernder Status sofort abgebildet wird. Ändert sich kein Status, werden keine Routinen ausgeführt, was die Systemlast gering hält. Der Nachteil ist, dass - z.B. nach einem Systemstart - die entsprechende Aktion erst bei einer Änderung des Status ausgeführt wird. D.h. ist das zu testende Gerät anwesend, wird dann FHEM beendet, das Gerät entfernt und FHEM wieder gestartet, ist der Status in FHEM immer noch "anwesend". Da das Reading für das Gerät nicht existiert, wird darauf auch erst wieder ein Notify ausgeführt, wenn sich der Status des Geräts wieder ändert, d.h. es wieder ankommt. Bis dahin ist der Status im System falsch.
Der Nachteil des Notify kann verringert werden, wenn man statt [code]attr Fritzbox event-on-change-reading mac_AA_BB_CC_DD_EE_FF[/code] ein [code]attr Fritzbox event-on-update-reading mac_AA_BB_CC_DD_EE_FF[/code] setzt. Das erhöht allerdings die Systemlast und funktioniert auch nur für den Status "anwesend". Bei "abwesend" ist kein Reading vorhanden, so dass auch event-on-update-reading nicht ausgeführt wird.
Eine weitere Möglichkeit, den Nachteil der Notify-Methode auszugleichen, ist, die Statusabfrage beim Systemstart einmal manuell auszuführen, durch ein notify auf "GLOBAL:initialized":
<pre>
global:INITIALIZED {
Reset_Variables;
if (ReadingsVal("Fritzbox", "mac_AA_BB_CC_DD_EE_FF", "inactive") eq "inactive") {
fhem("set anwesend_smartphone absent");
} else
fhem("set anwesend_smartphone present");
}
}
</pre>
Das hilft allerdings nur beim Systemstart. Nicht, wenn FHEM aufgrund irgendwelcher Hänger eine Aktualisierung des Status' verpasst hat.

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

[[Kategorie:FritzBox]]

Notify

2015-09-04T08:26:34Z

Motivierte linke Hände:

{{SEITENTITEL:notify}}
{{Infobox Modul
|ModPurpose=Ausführung von Anweisung(en) als Reaktion auf Ereignisse
|ModType=h
|ModCmdRef=notify
|ModForumArea=Automatisierung
|ModTechName=91_notify.pm
|ModOwner=rudolfkoenig ({{Link2FU|8|Forum}} / [[Benutzer Diskussion:Rudolfkoenig|Wiki]])
}}
__TOC__
{{Todo|generelle Überarbeitung, Fehlerkontrolle, Formatierung}}
{{Randnotiz|RNTyp=[g|Info|RNText=Weitere grundlegende Informationen/Beispiele zu notify enthält [http://fhem.de/Heimautomatisierung-mit-fhem.pdf Heimautomatisierung mit Fhem]
"Um Ihren Perlcode zu testen, verwenden Sie das [http://fhem.de/commandref#trigger trigger-Kommando]. [...] Wenn Sie also z.B. ein <code>define Testcode notify Schalter1:on {Perlcode}</code> testen möchten, können Sie Ihren Code mit <code>trigger Schalter1 on</code> testen. trigger simuliert das Eintreten eines Ereignisses [...]" (Tipp von S. 38 der Version 4.0)}}
== Notify, das mächtige Tool ==
Die nachfolgenden Beispiele beziehen sich hauptsächlich auf [[EIB / KNX|KNX (EIB)]]. Sie sind aber auf alle anderen Systeme übertragbar.

Was ist notify?
Das Hilfsmodul notify dient dazu, Aktionen abhängig von einem anderen Ereignis/Event (siehe [[Event_monitor|Event monitor]]) auszulösen. Es ist damit möglich, Logikfunktionen im Fhem abzubilden.

Z.B.: das Licht in der Küche wird eingeschaltet ====> draus folgt, dass auch das Radio eingeschaltet wird.

=== Syntax von notify ===

define <name> notify <Suchmuster> <command>

Das Suchmuster (auch Regexp = regulärer Ausdruck) ist sehr wichtig. Es ist entweder der Name des auslösenden ("triggernden") Gerätes oder die Kombination aus Gerät und auslösendem Ereignis (Event) Gerätename:Event. Die Events kann man dem [[Event_monitor|Event-Monitor]] entnehmen. Wenn da z.B. Rollo1 steht, dann reagiert notify auf Rollo1 on und off und was es sonst noch alles gibt.

Wenn man mehrere Suchmuster möchte, kann man diese in Klammer schreiben (Rollo1|Rollo2|Steckdose5)
als Trenner wird dann Pipe (|) genutzt.

Man kann auch mit Platzhaltern arbeiten.

* Rollo. ==> das notify reagiert auf alles was mit Rollo und '''einem''' weiteren beliebigen Zeichen anfängt. Also auf Rollo1 wie auch auf RolloG, aber nicht auf Rollo_wischundweg
* Rollo.* ==> das notify reagiert auf alles das mit Rollo beginnt.
* .*isch ==>; Reagiere auf alles das mit isch aufhört (Tisch, Fisch)

Suchmuster/Regex kann man im Internet beispielsweise auf [http://regexpal.com/| http://regexpal.com/] testen.

=== Regexp wizard - FHEMWEB-unterstützte Anlage eines notify ===

Die Erstellung eines notify und insbesondere die korrekte Angabe des Suchmusters (Regex) führt gerade bei Einsteigern immer wieder zu Schwierigkeiten. Zur Fehlerminimierung empfiehlt es sich einmal die [[Konfiguration]] nicht direkt zu bearbeiten, sondern die "Befehl-Eingabezeile" und die "Objektdetails" zur Bearbeitung zu nutzen. Zudem enthält Fhem einen Regexp wizard mit dem Regex anhand der in Fhem vorhandenen Devices und deren Events aus einer Auswahlbox selektiert werden können. Voraussetzungen sind:
* Aktivierung des Hilfsmoduls [[eventTypes]] (bei allen Neuinstallationen Standard)
* das gesuchte Ereignis (Event) ist nach Aktivierung des Hilfsmoduls bereits mindestens einmal eingetreten

Schrittweise Darstellung der Nutzung des Regexp wizard zur Anlage eines "notify":

In das [[Konfiguration#Befehl-Eingabefeld|Befehls-Eingabefeld]] eingeben und mit {{Taste|Enter}} bestätigen:
define ntest notify a b
Als Beispiel wird ein notify mit <name> "ntest" angelegt. "a" und "b" sind beliebige Platzhalter für <Suchmuster> und <Command>, die bei der weiteren Bearbeitung mit dem endgültigen Werten ersetzt werden.
Der Regexp wizard öffnet sich:
[[Datei:Regexp wizard1.JPG|400px|thumb|center]]
Nun in der Auswahlbox das auslösende Event (Ereignis) auswählen; zunächst das Device und dann das gewünschte Regex. Hier soll das notify bei jeder Veränderung der Temperatur (temperature.*) des Device BTHR918N reagieren. Abschließend mit einem Mausklick auf {{Taste|set}} bestätigen. Wählt man mehrere Regex in dieser Weise aus, so wird das "notify" bei Eintritt jedes dieser Events ausgeführt:
[[Datei:Regexp wizard2.JPG|400px|thumb|center]]
Anschließend den Platzhalter "a" mit Klick auf den Link "removeRegexpPart" löschen:
[[Datei:Regexp wizard3.JPG|400px|thumb|center]]
Den Link "DEF" anklicken, damit sich der DEF-Editor öffnet:
[[Datei:Regexp wizard4.JPG|400px|thumb|center]]
Jetzt den auszuführenden Befehl im "DEF"-Bereich durch Überschreiben des Platzhalters "a" eintragen und mit Klick auf {{Taste|modify ntest}} abschließen:
[[Datei:Regexp wizard5.JPG|400px|thumb|center]]
Das fertige und sofort aktive "notify" sieht abschließend folgendermaßen aus:
[[Datei:Regexp wizard6.JPG|400px|thumb|center]]
Am Schluss das Speichern über {{Taste|Save config}} nicht vergessen.

=== Etwas schalten, wenn ein anderes Gerät geschaltet wird ===
Wenn man das obige mit KNX abbilden möchte, benötigt man auf der KNX Seite:

==== Vorbereitung ====
* Gruppenadresse (GA) für die Steckdose vom Radio (0/0/10)
* GA vom Licht (0/0/20)

Auf der Fhem Seite wird benötigt:

define RadioKueche EIB 0/0/10
define LichtKueche EIB 0/0/20

==== notify Befehl ====
define LichtamRadioan notify LichtKueche { fhem "set RadioKueche $EVENT" }
oder '''besser'''
define LichtamRadioan notify LichtKueche set RadioKueche $EVENT

==== Erklärung ====
* Der Begriff "LichtamRadioan" ist nur ein Platzhalter, damit das notify in Fhem verwaltet werden kann.
* "$EVENT" ist ein Platzhalter für den Zustand vom Pattern. $EVENT enthält ein "off" wenn das LichtKueche aus ist und ein "on" wenn das Licht eingeschaltet ist.
* "{ <perlcode> }" alles was zwischen {} steht ist Perl code. Perl kennt das Schlüsselwort Fhem. Das Schlüsselwort Fhem dient dazu, Fhem Befehle auszuführen. Es wird also der Fhem Befehl "set RadioKueche on/off" ausgeführt. on oder off ist abhängig vom Pattern. Der eigentliche Fhem Befehl muss in " " stehen.
* Warum ist die 2. Variante besser? In der 1. Variante wechselt man von Fhem-Ebene des notify mittels {} auf Perl-Ebene, wo man mit dem Schlüsselwort Fhem "" wieder einen Befehl auf Fhem-Ebene ausführt. In der 2. Variante werden diese unnötigen, resourcenverschwendenden Ebenen-Wechsel vermieden. Alles wird auf der Fhem-Ebene ausgeführt.

=== Einschalten von mehreren Geräten/Lampen, wenn das Licht eingeschaltet wird ===
==== Vorbereitung ====
KNX:
* 3 GAs für drei Geräten bzw Lampen (0/0/30 0/0/31 0/0/32)

Fhem:
define LichtWZ EIB 0/0/30
define Steckdose1 EIB 0/0/31
define Steckdose2 EIB 0/0/32

==== notify Befehl ====
define SteckdoseWZein notify LichtWZ { fhem "set Steckdose1 $EVENT;;set Steckdose2 $EVENT " }
oder '''besser'''
define SteckdoseWZein notify LichtWZ set Steckdose1,Steckdose2 $EVENT

==== Erklärung ====
Wenn das LichtWZ eingeschaltet wird, dann werden auch die Steckdosen (1 und 2) eingeschaltet.

=== Einfache ODER Funktion ===
Eine einfache ODER Funktion kann sehr einfach realisiert werden

==== Vorbereitung ====
KNX:
* 3x GAs der abzufragende Werte (0/0/40 0/0/41 0/0/42)

Fhem:
define Licht1 EIB 0/0/40
define Licht2 EIB 0/0/41
define Steckdose EIB 0/0/42

==== notify Befehl ====
define SteckdoseWZein notify (Licht1|Licht2) set Steckdose $EVENT
oder
define SteckdoseWZein notify (Licht.) set Steckdose $EVENT

==== Erklärung ====
Die Werte in der Klammer (wichtig ist das »|«) sind die Rückgabewerte. Alternativ kann in diesem Beispiel auch »Licht.« (zu beachten ist der Punkt) geschrieben werden. Der Punkt ist ein Platzhalter für (genau) ein beliebiges Zeichen.

Danach folgt der set Befehl.
Wenn also das Licht1 oder Licht2 den Wert "on" hat, dann hat auch die Steckdose den Wert "on"

Alternative: [[structure]]

=== Einfache UND Funktion ===
Ob man dieses Konstrukt noch als einfach bezeichnen kann, wage ich mal zu bezeifeln. In Fhem fehlen Loggingfunktionen, die man alle selber mit Perl Code erstellen kann (Danke an MAZ).
Dadurch ist Fhem zwar mächtig, wird aber für viele sehr kompliziert.

In diesem Beispiel soll - wenn drei Rollos geschlossen sind - am Taster eine LED eingeschaltet werden.

==== Vorbereitung ====
KNX:
* 3x GDs für die Rückgabewert Rollo geschlossen == 1 (0/0/50 0/0/51 0/0/52)
* GD LED am Lichtschalter (0/0/106)

Fhem:
define R1ZU EIB 0/0/50
attr R1ZU dummy 1
define R2ZU EIB 0/0/51
attr R1ZU dummy 1
define R3ZU EIB 0/0/52
attr R1ZU dummy 1
define LEDalleRolloZu EIB 0/0/106
Durch das Atribut dummy werden keine Schaltfunktion angeboten. Es kann nur Werte anzeigen.

==== notify Befehl ====
define nt.allerolloszu notify (R1ZU|R2ZU|R6ZU) {
my $r1 = Value("R1ZU");;
my $r2 = Value("R2ZU");;
my $r3 = Value("R6ZU");;
if ($r1 eq "on" && $r2 eq "on" && $r3 eq "on") {
fhem "set LEDalleRolloZu on"
} else {
fhem "set LEDalleRolloZu off"
}
}

==== Erklärung ====
Es werden die drei Rückgabewerte R1ZU, R2ZU und R3ZU ausgewertet. Danach folgt Perl Code, deswegen beginnt das ganze mit einer { und endet mit }

my $r1 => Variable $r1 definieren
= Value("R1ZU");; ==> weist den Rückgabewert (on oder off) von R1ZU der Variable $r1 zu

Der doppelte ;; ist ein Fhem Thema. Eigentlich würde für Perl ein ; reichen. Aber Fhem nutzt selbst das ; und daher wird ein ;; benötigt. Mit den ersten drei my Zeilen werden die Rückgabewerte den Variabeln zugewiesen.

Danach erfolgt ein normales "if then else" Konstrukt. Die Zeile »($r1 eq "on" && $r2 eq "on" && $r3 eq "on")« kann man so lesen: Wenn $r1 den Wert "on" und (&&) $r2 den Wert "on" und $r3 den Wert "on" dann schalte die LEDalleRolloZu ein {fhem("set LEDalleRolloZu on")}
ansonsten else schalte die LED aus. {fhem("set LEDalleRolloZu off")

Alternative: [[structure]]

=== Zeitverzögert schalten ===
{| class="wikitable"
| '''Aufgabe:''' || Zeitverzögert schalten
|-
| '''Beschreibung:''' || Mit einem Notify zeitverzögert eine Aktion auslösen.
|-
| '''Vorbereitung:''' || Gerät "Lampe" ist definiert und es gibt eine Situation, die ein Ereignis "Fernbedienung:.*" generiert.
|-
| '''Befehl:''' || <code>define ntfy1 notify Fernbedienung:.* sleep 7.5;; set Lampe $EVENT</code>
|-
| '''Erläuterungen:''' || Bei Eintreten eines Ereignisses "Fernbedienung*" wird nach einer Pause von siebeneinhalb Sekunden der Befehl <set Lampe ??> ausgeführt, wobei der eigentliche Befehl aus dem auslösenden Ereignis übernommen wird.
:''Quelle: [http://forum.fhem.de/index.php/topic,17161.0.html Fhem Forum]''
|}

=== Eine PV-Anlage (Solarstrom) zur Steuerung der Rollos nutzen (optional Zeit und Datums abhängig) ===
Hier ein kleines Beispiel, wie man mit Hilfe einer PV-Anlage die Sonneneinstrahlung auf der Südseite ermittelt und dies zur Rolladensteuerung nutzt.
Optional: Die Funktion soll allerdings nur zwischen 9:30 und 17:00 stattfinden. (zweites Beispiel)
Optional: Die Funktion soll nur zwischen dem 6. und 9. Monat funktioneren. (drittes Beispiel)

==== Vorbereitung ====
PV Anlage mit SolarView abfragen.
Per Hand ermitteln, ab wieviel erzeugtem Strom es sinnvoll ist die Rollos zu schließen.

==== notify Syntax ====
Fhem:

define sv SolarView solarview 15000 wr1 wr2 wr3 wr4 <----vier Wechselrichter
attr sv event-on-change-reading currentPower

define nt.sonnenlichtpersolar notify (sv:currentPower.*) {
if ($EVTPART1 < 3000 ) {
fhem('set Flur1 Auf');
}else {
if ($EVTPART1 > 5000 ) {
fhem('set Flur1 Ab');
}
}
}

Optional 1: Zeitabhängig

(sv:currentPower.*) {
my $hm = sprintf("%%02d:%%02d", $hour, $min);
if ( $hm gt "09:30" && $hm lt "17:00") {
if ($EVTPART1 < 5000 ) {
fhem('set Flur1 Auf');
}else {
if ($EVTPART1 > 8000 ) {
fhem('set Flur1 Ab');
}
}
}
}

Optional 2: Zeit und Datum

(sv:currentPower.*) {
my $hm = sprintf("%%02d:%%02d", $hour, $min);
if ($month >= 6 && $month <= 9) {
if ( $hm gt "09:30" && $hm lt "17:00") {
if ($EVTPART1 < 5000 ) {
fhem('set Flur1,RBUERO1,RBUERO2 Auf');
}else {
if ($EVTPART1 > 8000 ) {
fhem('set Flur1,Flur2,RBUERO1,RBUERO2 Ab');
}
}
}
}
}

==== Erklärung ====
* Das define wird in der Kommandozeile im Webbrowser eingegeben.
* Anschliessend wird im Webbrowser die DEF bearbeitet, das erspart uns Probleme mit Perl
* define sv SolarView ... <==== ist die Schnittstelle vom SolarView
* define nt.sonnenlichtpersolar notify (sv:currentPower.*) { <==== hier wird ein notify angelegt, der auf das "define sv" Wert "currentPower.*" (.* ist irgendwas) reagiert
if ($EVTPART1 < 3000 ) {
fhem('set Flur1 Auf');
}else {
if ($EVTPART1 > 5000 ) {
fhem('set Flur1 Ab');
}
}
}
Diese if-Funktion wertet den Rückgabewert von currentPower aus. Hierbei muss man wissen, dass $EVTPART1 das Splitergebnis vom Rückgabewert ist

Beispiel: Der Rückgabewert (wie im Beispiel) ist "currentPower: 6000".
Jetzt steht im "$EVTPART0 == currentPower:" und im "$EVTPART1 == 6000"
Das bedeutet, dass man sich nicht selbst den richtigen split (Perl Befehl) Aufruf ausdenken muss, dies übernimmt vielmehr Fhem.

Ergebnis:
Das Rollo wird abhängig von der erzeugten IST_Strommenge auf und zu gefahren.
Damit dies nicht dauernd hin und her pendelt, wurde der Auf Wert sehr klein und den Ab Wert sehr groß gewählt.

'''Optional 1:''' Der Block "my $hm = sprintf("%%02d:%%02d", $hour, $min);" erzeugt die String-Variable $hm mit dem Inhalt $hour:$min. %02d (wegen Fhem Besonderheit: %%02d) begrenzt die Ausgabe auf zwei Stellen.
Danach wird mit "if ( $hm gt "09:30" && $hm lt "17:00")" mit stringvergleichende Operatoren geprüft, ob die Uhrzeit zwischen 9:30 und 17:00 liegt (lt = kleiner als; gt = größer als). Es wäre auch ein le und ge möglich: le = kleiner/gleich als, ge = größer/gleich als.

'''Optional 2:'''if( $month >= 6 && $month <= 9) {

Hier wird die numerische Fhem-Standard-Variable $month (Monat) auf größer/gleich bzw kleiner/gleich mit den binären Operatoren überprüft.
Die Funktion arbeitet also nur zwischen dem 6. und dem 9. Monat und dann auch nur zwischen 9:31 und 16:59.

=== Hinweise ===
* Entsprechend zu $EVENT gibt es auch noch $NAME und $TYPE. $NAME und $TYPE enthalten den Namen bzw. Typ des Ereignis auslösenden Gerätes.
* Wird der Perl-Code in einem <code>notify</code> immer länger, lagere den Code wegen der Übersichtlichkeit in eine eigene Programmdatei aus, wie in [[99_myUtils anlegen]] beschrieben.
* Achtung! Wenn man das Skript für den notify-Befehl über mehrere Zeilen schreibt, muss man anscheinend darauf achten, dass keine abschliessende Leerzeile mitgespeichert wird. Sonst wird der notify-Befehl ignoriert.
* Dieser {{Link2Forum|Topic=38520|Message=307325}} enthält Vorschläge zur Vorgehensweise bei der Erstellung von komplexen ''notify'' Definitionen bzw. bei deren Fehlerbehebung.

== Weiterführende Links ==
* [[Escapen in Perlbefehlen]]
* [[Klammerebenen]]
* [[DOIF]] als Alternative vereinigt die Funktionalität des notify-, at-, watchdog-Befehls in Kombination mit logischen Abfragen unter einem Dach

[[Kategorie:HOWTOS]]
[[Kategorie:Hilfsmodul]]

FRITZBOX

2015-08-21T16:13:33Z

Motivierte linke Hände:

{{Infobox Modul
|ModPurpose=Steuerung einer Fritz!Box über Fhem
|ModType=d
|ModForumArea=FRITZ!Box
|ModTechName=72_FRITZBOX.pm
|ModOwner=tupol/Topos ([http://forum.fhem.de/index.php?action=profile;u=5432 Forum] / [[Benutzer Diskussion:Topos|Wiki]])}}

Das Modul [[FRITZBOX]] ermöglicht die Steuerung einer [[AVM Fritz!Box]] und von AVM FRITZ!WLAN Repeatern durch Fhem. An Fritzboxen können sowohl Geräte abgefragt werden, auf denen FHEM selbst läuft (lokaler Modus), als auch um eine entfernte (externe) Geräte.

== Voraussetzungen ==
=== Remote-Zugang ===
Für den Remote-Zugang müssen die Module JSON:XS, LWP und SOAP::Lite installiert sein; auf einem [[Raspberry Pi]] oder unter Ubuntu z. B. mit dem Befehl
:::<code>sudo apt-get install libjson-perl libwww-perl libsoap-lite-perl libjson-xs-perl</code>

Teilweise ist derzeit zusätzlich die Installation der telnet Libraries erforderlich, auch wenn der Telnet-Zugang nicht genutzt werden soll. Siehe dazu den nachfolgenden Abschnitt.

=== Telnet ===
Das Modul basierte ursprünglich auf dem Zugriff auf die Fritzbox per Telnet. Ab FRITZ!OS 6.2x baut AVM den abgekündigten Telnet-Zugang sowie die webcm-Schnittstelle sukzessive zurück bzw. hat dies, je nach Firmware, schon ganz abgestellt (siehe {{Link2Forum|Topic=38586|LinkText=dieses Forenthema}}). Der zukunftssichere Zugriff auf die Fritzbox sollte also per TR-064 erfolgen. Der Vollständigkeit halber und für ältere Firmwareversionen:

# Wer den Zugang per Telnet (noch) nutzen (kann und) möchte, muss dies zuerst freischalten. Üblicherweise durch Eingabe von #96*7* an einem direkt an der entsprechenden FritzBox angeschlosssenen Telefon

# Auf dem System, auf dem Fhem läuft ([[Systemübersicht#Server|Server]]) muss Telnet installiert sein; auf einem [[Raspberry Pi]] und unter Ubuntu z. B. mit dem Befehl
:::<code>sudo apt-get install libnet-telnet-perl</code>

== Installation ==

=== Erste Schritte ===
Zur Erstinstallation reicht ein einfaches <code>define FritzBox FRITZBOX</code>, dieses Modul funktioniert lokal (FHEM auf Fritzbox) sowie per Fernzugriff (FHEM auf einem anderen Server im Netz, siehe nächsten Schritt).

==== TR-064: Modul FRITZBOX für Zugriff auf einem externen Server einrichten ====
Für den Fernzugriff über TR-064 auf eine oder mehrere Fritzboxen und/oder einen FRITZ!WLAN Repeater sind die folgenden Schritte nötig (für jedes Gerät):

Fritzbox definieren:
:<code>define FritzBox FRITZBOX</code>

Wenn das Login auf der Benutzeroberfläche der FritzBox mit User und Passwort (und nicht nur per Passwort) geschieht, den User konfigurieren:
:<code>attr FritzBox boxUser ''Benutzername'' </code>

Passwort konfigurieren:
:<code>set FritzBox password ''Passwort'' </code> - legt das zugehörige Passwort fest

Manuelle TR-064 Kommandos erlauben (die Abfrage per TR-064 funktioniert auch ohne dieses Attribut):
:<code>attr FritzBox allowTR064Command 1</code>

Wenn die Fritzbox nicht unter http://fritz.box erreichbar ist, IP setzen:
:<code>attr FritzBox fritzBoxIP 192.168.168.168</code>
192.168.168.168 dabei natürlich durch die passende IP ersetzen... Alternativ kann bei fritzBoxIP - trotz des Namens des Attributs - statt der IP auch der Hostname eingegeben werden, eine DNS-Auflösung findet statt.

Manchmal ist ein Neustart von FHEM erforderlich, damit die Fritzbox mit der veränderten IP gefunden wird.

==== Telnet: Modul FRITZBOX für Zugriff auf einem externen Server einrichten ====
[[Datei:Screenshot_FritzBox_TelnetUser.png|mini|300px|rechts|Anlegen des Attributs telnetUser]]
Bei Fernzugriff über Telnet sind weitere Schritte nötig:
# Telnet auf der Fritzbox freischalten (Tastenkombination #96*7* am angeschlossenen Telefon (auch FritzFon)
# TelnetUser definieren (wie im Screenshot gezeigt)
# Passwort zum Benutzer auf der Fritzbox definieren

[[Datei:Screenshot_FritzBox_Passwort.png|mini|300px|rechts|Passwort definieren]]

(bitte die Buttons {{Taste|set}} und {{Taste|attr}} bei der Definition der jeweiligen Einträge nicht vergessen)

Wer stattdessen lieber das [[Konfiguration|Befehl-Eingabefeld]] verwendet:

:<code>define FritzBox FRITZBOX</code>
:<code>attr FritzBox telnetUser ''Benutzername'' </code> - legt den Benutzer fest
:<code>set FritzBox password ''Passwort'' </code> - legt das zugehörige Passwort fest

Wer keinen User konfiguriert hat, kann das Feld "telnetUser" leer lassen.

Wer sicher gehen möchte, dass auch tatsächlich Telnet und nicht andere Zugriffe benutzt werden, sollte außerdem noch setzen:

:<code>attr FritzBox forceTelnetConnection 1</code>

=== mögliche Fehlermeldungen ===
Sollte schon bei <code>define FritzBox FRITZBOX</code> die Fehlermeldung kommen, dass dieses Modul nicht existiert, dann bitte prüfen, ob Fhem auf dem aktuellen Stand ist und ggf. [[Update|aktualisieren]].

Kommt jetzt bei der erneuten Definition die Fehlermeldung <code>Error: Perl modul Net::Telnet is missing on this system</code> bitte wie oben schon erwähnt den Befehl
:<code>sudo apt-get install libnet-telnet-perl</code>
direkt per Telnet/SSH auf dem FHEM-Server ausführen und neu starten.
Sollte alles geklappt haben, seht ihr nun eure Fritzbox und könnt diverse Einstellungen manuell vornehmen und/oder automatisch vornehmen lassen.

== Anwendung ==
=== Define ===
Siehe [http://fhem.de/commandref_DE.html#FRITZBOX commandref]

=== Attribute ===
Siehe commandref

=== TR-064 ===
Die offizielle Programmier-Schnittstelle der Fritz!Box läuft über das Protokoll TR-064.

mit dem Attribute 
<code>attr <device> allowTR064Command 1</code> 
kann man den Befehl 
<code>get <device> tr064Command <service> <control> <action> [[parameterName1 parameterValue1] ...]</code> 
freischalten und damit auf diese Schnittstelle zugreifen.

AVM hat die Schnittstellenbeschreibung unter [http://avm.de/service/schnittstellen/] veröffentlicht. Ein weitere Einstiegspunkt befindet sich auch auf der Box unter http://fritz.box:49000/tr64desc.xml

Folgende Service und Controls existieren (für den get-Befehl werden nur die fett formatierten Wörter benötigt)

{| class="wikitable"
|-
!serviceType!!controlURL!!XML!!Dokument bei AVM
|-
|<nowiki>urn:dslforum-org:service:</nowiki>'''DeviceInfo:1'''||/upnp/control/'''deviceinfo'''||[http://fritz.box:49000/deviceinfoSCPD.xml deviceinfoSCPD.xml]||[http://avm.de/fileadmin/user_upload/Global/Service/Schnittstellen/deviceinfoSCPD.pdf deviceinfoSCPD.pdf]
|-
|<nowiki>urn:dslforum-org:service:</nowiki>'''DeviceConfig:1'''||/upnp/control/'''deviceconfig'''||[http://fritz.box:49000/deviceconfigSCPD.xml deviceconfigSCPD.xml]||[http://avm.de/fileadmin/user_upload/Global/Service/Schnittstellen/deviceconfigSCPD.pdf deviceconfigSCPD.pdf]
|-
|<nowiki>urn:dslforum-org:service:</nowiki>'''Layer3Forwarding:1'''||/upnp/control/'''layer3forwarding'''||[http://fritz.box:49000//layer3forwardingSCPD.xml layer3forwardingSCPD.xml]||[http://avm.de/fileadmin/user_upload/Global/Service/Schnittstellen/layer3forwardingSCPD.pdf layer3forwardingSCPD.pdf]
|-
|<nowiki>urn:dslforum-org:service:</nowiki>'''LANConfigSecurity:1'''||/upnp/control/'''lanconfigsecurity'''||[http://fritz.box:49000//lanconfigsecuritySCPD.xml lanconfigsecuritySCPD.xml]||[http://avm.de/fileadmin/user_upload/Global/Service/Schnittstellen/lanconfigsecuritySCPD.pdf lanconfigsecuritySCPD.pdf]
|-
|<nowiki>urn:dslforum-org:service:</nowiki>'''ManagementServer:1'''||/upnp/control/'''mgmsrv'''||[http://fritz.box:49000//mgmsrvSCPD.xml mgmsrvSCPD.xml]||[http://avm.de/fileadmin/user_upload/Global/Service/Schnittstellen/mgmsrvSCPD.pdf mgmsrvSCPD.pdf]
|-
|<nowiki>urn:dslforum-org:service:</nowiki>'''Time:1'''||/upnp/control/'''time'''||[http://fritz.box:49000//timeSCPD.xml timeSCPD.xml]||[http://avm.de/fileadmin/user_upload/Global/Service/Schnittstellen/timeSCPD.pdf timeSCPD.pdf]
|-
|<nowiki>urn:dslforum-org:service:</nowiki>'''UserInterface:1'''||/upnp/control/'''userif'''||[http://fritz.box:49000//userifSCPD.xml userifSCPD.xml]||[http://avm.de/fileadmin/user_upload/Global/Service/Schnittstellen/userifSCPD.pdf userifSCPD.pdf]
|-
|<nowiki>urn:dslforum-org:service:</nowiki>'''X_VoIP:1'''||/upnp/control/'''x_voip'''||[http://fritz.box:49000//x_voipSCPD.xml x_voipSCPD.xml]||[http://avm.de/fileadmin/user_upload/Global/Service/Schnittstellen/x_voipSCPD.pdf x_voipSCPD.pdf]
|-
|<nowiki>urn:dslforum-org:service:</nowiki>'''X_AVM-DE_Storage:1'''||/upnp/control/'''x_storage'''||[http://fritz.box:49000//x_storageSCPD.xml x_storageSCPD.xml]||[http://avm.de/fileadmin/user_upload/Global/Service/Schnittstellen/x_storageSCPD.pdf x_storageSCPD.pdf]
|-
|<nowiki>urn:dslforum-org:service:</nowiki>'''X_AVM-DE_OnTel:1'''||/upnp/control/'''x_contact'''||[http://fritz.box:49000//x_contactSCPD.xml x_contactSCPD.xml]||[http://avm.de/fileadmin/user_upload/Global/Service/Schnittstellen/x_contactSCPD.pdf x_contactSCPD.pdf]
|-
|<nowiki>urn:dslforum-org:service:</nowiki>'''X_AVM-DE_WebDAVClient:1'''||/upnp/control/'''x_webdav'''||[http://fritz.box:49000//x_webdavSCPD.xml x_webdavSCPD.xml]||[http://avm.de/fileadmin/user_upload/Global/Service/Schnittstellen/x_webdavSCPD.pdf x_webdavSCPD.pdf]
|-
|<nowiki>urn:dslforum-org:service:</nowiki>'''X_AVM-DE_UPnP:1'''||/upnp/control/'''x_upnp'''||[http://fritz.box:49000//x_upnpSCPD.xml x_upnpSCPD.xml]||[http://avm.de/fileadmin/user_upload/Global/Service/Schnittstellen/x_upnp.pdf x_upnp.pdf]
|-
|<nowiki>urn:dslforum-org:service:</nowiki>'''X_AVM-DE_RemoteAccess:1'''||/upnp/control/'''x_remote'''||[http://fritz.box:49000/x_remoteSCPD.xml x_remoteSCPD.xml]||[http://avm.de/fileadmin/user_upload/Global/Service/Schnittstellen/x_remoteSCPD.pdf x_remoteSCPD.pdf]
|-
|<nowiki>urn:dslforum-org:service:</nowiki>'''X_AVM-DE_MyFritz:1'''||/upnp/control/'''x_myfritz'''||[http://fritz.box:49000/x_myfritzSCPD.xml x_myfritzSCPD.xml]||[http://avm.de/fileadmin/user_upload/Global/Service/Schnittstellen/x_myfritzSCPD.pdf x_myfritzSCPD.pdf]
|-
|<nowiki>urn:dslforum-org:service:</nowiki>'''X_AVM-DE_TAM:1'''||/upnp/control/'''x_tam'''||[http://fritz.box:49000/x_tamSCPD.xml x_tamSCPD.xml]||[http://avm.de/fileadmin/user_upload/Global/Service/Schnittstellen/x_tam.pdf x_tam.pdf]
|-
|<nowiki>urn:dslforum-org:service:</nowiki>'''X_AVM-DE_AppSetup:1'''||/upnp/control/'''x_appsetup'''||[http://fritz.box:49000/x_homeautoSCPD.xml x_homeautoSCPD.xml]||[http://avm.de/fileadmin/user_upload/Global/Service/Schnittstellen/x_appsetupSCPD.pdf x_appsetupSCPD.pdf]
|-
|<nowiki>urn:dslforum-org:service:</nowiki>'''X_AVM-DE_Homeauto:1'''||/upnp/control/'''x_homeauto'''||[http://fritz.box:49000/x_homeautoSCPD.xml x_homeautoSCPD.xml]||[http://avm.de/fileadmin/user_upload/Global/Service/Schnittstellen/x_homeautoSCPD.pdf x_homeautoSCPD.pdf]
|-
|<nowiki>urn:dslforum-org:service:</nowiki>'''WLANConfiguration:1'''||/upnp/control/'''wlanconfig1'''||[http://fritz.box:49000/wlanconfigSCPD.xml wlanconfigSCPD.xml]||[http://avm.de/fileadmin/user_upload/Global/Service/Schnittstellen/wlanconfigSCPD.pdf wlanconfigSCPD.pdf]
|-
|<nowiki>urn:dslforum-org:service:</nowiki>'''WLANConfiguration:2'''||/upnp/control/'''wlanconfig2'''||[http://fritz.box:49000/wlanconfigSCPD.xml wlanconfigSCPD.xml]||[http://avm.de/fileadmin/user_upload/Global/Service/Schnittstellen/wlanconfigSCPD.pdf wlanconfigSCPD.pdf]
|-
|<nowiki>urn:dslforum-org:service:</nowiki>'''WLANConfiguration:3'''||/upnp/control/'''wlanconfig3'''||[http://fritz.box:49000/wlanconfigSCPD.xml wlanconfigSCPD.xml]||[http://avm.de/fileadmin/user_upload/Global/Service/Schnittstellen/wlanconfigSCPD.pdf wlanconfigSCPD.pdf]
|-
|<nowiki>urn:dslforum-org:service:</nowiki>'''Hosts:1'''||/upnp/control/'''hosts'''||[http://fritz.box:49000/hostsSCPD.xml hostsSCPD.xml]||[http://avm.de/fileadmin/user_upload/Global/Service/Schnittstellen/hostsSCPD.pdf hostsSCPD.pdf]
|-
|<nowiki>urn:dslforum-org:service:</nowiki>'''LANEthernetInterfaceConfig:1'''||/upnp/control/'''lanethernetifcfg'''||[http://fritz.box:49000/lanifconfigSCPD.xml lanifconfigSCPD.xml]||[http://avm.de/fileadmin/user_upload/Global/Service/Schnittstellen/lanifconfigSCPD.pdf lanifconfigSCPD.pdf]
|-
|<nowiki>urn:dslforum-org:service:</nowiki>'''LANHostConfigManagement:1'''||/upnp/control/'''lanhostconfigmgm'''||[http://fritz.box:49000/lanhostconfigmgmSCPD.xml lanhostconfigmgmSCPD.xml]||[http://avm.de/fileadmin/user_upload/Global/Service/Schnittstellen/lanhostconfigmgmSCPD.pdf lanhostconfigmgmSCPD.pdf]
|-
|<nowiki>urn:dslforum-org:service:</nowiki>'''WANCommonInterfaceConfig:1'''||/upnp/control/'''wancommonifconfig1'''||[http://fritz.box:49000/wancommonifconfigSCPD.xml wancommonifconfigSCPD.xml]||[http://avm.de/fileadmin/user_upload/Global/Service/Schnittstellen/wancommonifconfigSCPD.pdf wancommonifconfigSCPD.pdf]
|-
|<nowiki>urn:dslforum-org:service:</nowiki>'''WANDSLInterfaceConfig:1'''||/upnp/control/'''wandslifconfig1'''||[http://fritz.box:49000/wandslifconfigSCPD.xml wandslifconfigSCPD.xml]||[http://avm.de/fileadmin/user_upload/Global/Service/Schnittstellen/wandslifconfigSCPD.pdf wandslifconfigSCPD.pdf]
|-
|<nowiki>urn:dslforum-org:service:</nowiki>'''WANDSLLinkConfig:1'''||/upnp/control/'''wandsllinkconfig1'''||[http://fritz.box:49000/wandsllinkconfigSCPD.xml wandsllinkconfigSCPD.xml]||[http://avm.de/fileadmin/user_upload/Global/Service/Schnittstellen/wandsllinkconfigSCPD.pdf wandsllinkconfigSCPD.pdf]
|-
|<nowiki>urn:dslforum-org:service:</nowiki>'''WANEthernetLinkConfig:1'''||/upnp/control/'''wanethlinkconfig1'''||[http://fritz.box:49000/wanethlinkconfigSCPD.xml wanethlinkconfigSCPD.xml]||[http://avm.de/fileadmin/user_upload/Global/Service/Schnittstellen/wanethlinkconfigSCPD.pdf wanethlinkconfigSCPD.pdf]
|-
|<nowiki>urn:dslforum-org:service:</nowiki>'''WANPPPConnection:1'''||/upnp/control/'''wanpppconn1'''||[http://fritz.box:49000/wanpppconnSCPD.xml wanpppconnSCPD.xml]||[http://avm.de/fileadmin/user_upload/Global/Service/Schnittstellen/wanpppconnSCPD.pdf wanpppconnSCPD.pdf]
|-
|<nowiki>urn:dslforum-org:service:</nowiki>'''WANIPConnection:1'''||/upnp/control/'''wanipconnection1'''||[http://fritz.box:49000/wanipconnSCPD.xml wanipconnSCPD.xml]||[http://avm.de/fileadmin/user_upload/Global/Service/Schnittstellen/wanipconnSCPD.pdf wanipconnSCPD.pdf]
|-
|}

=== Status-Symbol ===
<code>attr <device> devStateIcon .*on.*off:WLAN_on_gWLAN_off .*on.*on.*:WLAN_on_gWLAN_on WLAN..off.*:WLAN_off</code>

Im Verzeichnis www/images/default müssen die passenden Dateien "WLAN_on_gWLAN_off.png", "WLAN_on_gWLAN_on.png" und "WLAN_off.png" liegen. Wenn die PNGs fehlen, können sie hier [http://forum.fhem.de/index.php/topic,29725.msg318113.html#msg318113] heruntergeladen werden.

== Anwendungsbeispiele ==
[[Datei:Screenshot_FritzBox1.png|mini|300px|rechts|FRITZBOX Gerät auf der Fhem Oberfläche]]
Sollte alles geklappt haben, seht ihr nun unter "Unsortiert" den im nebenstehenden Screenshot gezeigten Eintrag für das "Gerät" (hier mit dem Icon "it_router").

=== TR-064 Bespiele ===

*Box Reboot: <code>get <device> tr064Command DeviceConfig:1 deviceconfig Reboot</code>

=== Klingel- und Sprachausgabe per TR-064 ===

Das geht derzeit nicht, da entsprechende Kommandos per TR-064 nicht verfügbar sind. Da Telnet sukzessive abgestellt wird, sollten sich Interessenten per Feature-Request an AVM wenden, wie hier [http://forum.fhem.de/index.php/topic,38586.0.html] beschrieben.

=== Anwesenheitserkennung ===

Fritzboxen und die FRITZ!WLAN Repeater speichern den Status angemeldeter Geräte. Dieser Status lässt sich mittels des FRITZBOX Moduls über Readings abfragen, die das Format mac_AA_AA_AA_AA_AA_AA haben und die MAC-Adressen der jeweils angemeldeten Geräte (AA:AA:AA:AA:AA:AA) enthalten. Das Reading existiert, wenn das Gerät angemeldet ist. Wenn das Gerät abgemeldet ist, existiert es ist. Es gibt auch noch den Zwischenstatus "inactive", der anscheinend gesetzt wird, bevor das Reading gelöscht wird.

Mit Hilfe des PRESENCE Moduls (vgl. [[Anwesenheitserkennung]]) kann man auf diese Weise den Anwesenheitsstatus abfragen. Anregungen dazu gibt es im zugehörigen {{Link2Forum|Topic=39433|LinkText=Forenthread}} zur Anwesenheitserkennung und in einem Blogpost: [http://heinz-otto.blogspot.de/2015/07/die-zeiten-andern-sich.html]. Auf dieser Basis könnte eine einfache Implementierung zum Beispiel so aussehen:

Funktion in 99_myUtils.pm:

<pre>sub checkFritzMACpresent($$) {
# Benötigt: Name der zu testenden Fritzbox ($Device),
# zu suchende MAC ($MAC),
# Rückgabe: 1 = Gerät gefunden
# 0 = Gerät nicht gefunden
my ($Device, $MAC) = @_;
my $Status = 0;
$MAC =~ tr/:/_/;
$MAC = "mac_".uc($MAC);
my $StatusFritz = ReadingsVal($Device, $MAC, "weg");
if ($StatusFritz eq "weg") {
Log 1, ("checkFritzMACpresent ($Device): $MAC nicht gefunden, abwesend.");
$Status = 0;
} elsif ($StatusFritz eq "inactive") {
Log 1, ("checkFritzMACpresent ($Device): $MAC ist >inactive<, also abwesend.");
$Status = 0;
} else {
# Reading existiert, Rückgabewert ist nicht "inactive", also ist das Gerät per WLAN angemeldet.
Log 1, ("checkFritzMACpresent ($Device): $MAC gefunden, Gerät heißt >$StatusFritz<.");
$Status = 1;
}
return $Status
}
</pre>

Nutzung dieser Funktion mit dem PRESENCE Modul definieren:

<code>define <Name> PRESENCE function {checkFritzMACpresent("Fritzbox","AA:BB:CC:DD:EE:FF")} 60 60</code>

wobei
*<Name> ein beliebig zu wählender Name für die PRESENCE-Funktion ist,
*Fritzbox der Name ist, mit dem ihr die abzufragende Fritzbox als FRITZBOX definiert habt,
*AA:BB:CC:DD:EE:FF die MAC-Adresse des gesuchten Geräts ist.
* "60 60" sagt, dass der Anwesenheitsstatus im 60-Sekunden-Takt abgefragt wird. Das macht natürlich nur Sinn, wenn ihr mit <code>attr Fritzbox INTERVAL 60</code> den Abfrageinterval bei der Fritzbox auch entsprechend hochgesetzt habt. Der Standard ist 300.
* "Log 1" führt immer zum Loggen. Das ist zum Einrichten praktisch, ohne dass man gleich für das ganze Modul oder ganz FHEM <code>attr <device> verbose 5</code> setzen muss. Wenn es läuft, können die "Log 1"-Zeilen gelöscht, auskommentiert (# an den Zeilenanfang) oder in "Log 5" geändert werden.

Weitere Hinweise zu komplexeren Abfragen mehrere Boxen auf einmal etc. findet ihr auch im {{Link2Forum|Topic=39433|LinkText=Forenthread}}.

=== Mehrere Fritzboxen oder Repeater und Fritzbox (wird noch bearbeitet) ===
Existiert ein AVM Repeater im Netzwerk, kann der als eigenständiges Gerät mit FRITZBOX definiert werden. WLAN Geräte an der Fritzbox werden in der Instanz der Fritzbox gelistet und WLAN Geräte am Repeater in der Repeater Instanz. Um trotzdem die Anwesenheit im Netzwerk einfach zu erkennen muss die Subroutine in 99_myUtils abgewandelt werden.

<pre>my @fbs = devspec2array("TYPE=FRITZBOX"); (Nur als Hinweis)
</pre>

Existiert eine zweite Fritzbox im Accesspointmodus werden die WLAN Geräte im Netzwerk alle in der Hauptfritzbox an einem LAN Anschluss gelistet. D.h. man sieht an der Hauptfritzbox nicht, dass sie im WLAN sind. Eine zweite Instanz mit dem FRITZBOX Modul muss wegen der Anwesenheitserkennung nicht gemacht werden.

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

[[Kategorie:FritzBox]]

FRITZBOX

2015-08-21T07:45:16Z

Motivierte linke Hände: Anwesenheitserkennung aufgenommen

{{Infobox Modul
|ModPurpose=Steuerung einer Fritz!Box über Fhem
|ModType=d
|ModForumArea=FRITZ!Box
|ModTechName=72_FRITZBOX.pm
|ModOwner=tupol/Topos ([http://forum.fhem.de/index.php?action=profile;u=5432 Forum] / [[Benutzer Diskussion:Topos|Wiki]])}}

Das Modul [[FRITZBOX]] ermöglicht die Steuerung einer [[AVM Fritz!Box]] und von AVM FRITZ!WLAN Repeatern durch Fhem. An Fritzboxen können sowohl Geräte abgefragt werden, auf denen FHEM selbst läuft (lokaler Modus), als auch um eine entfernte (externe) Geräte.

== Voraussetzungen ==
=== Remote-Zugang ===
Für den Remote-Zugang müssen die Module JSON:XS, LWP und SOAP::Lite installiert sein; auf einem [[Raspberry Pi]] oder unter Ubuntu z. B. mit dem Befehl
:::<code>sudo apt-get install libjson-perl libwww-perl libsoap-lite-perl libjson-xs-perl</code>

Teilweise ist derzeit zusätzlich die Installation der telnet Libraries erforderlich, auch wenn der Telnet-Zugang nicht genutzt werden soll. Siehe dazu den nachfolgenden Abschnitt.

=== Telnet ===
Das Modul basierte ursprünglich auf dem Zugriff auf die Fritzbox per Telnet. Ab FRITZ!OS 6.2x baut AVM den abgekündigten Telnet-Zugang sowie die webcm-Schnittstelle sukzessive zurück bzw. hat dies, je nach Firmware, schon ganz abgestellt (siehe {{Link2Forum|Topic=38586|LinkText=dieses Forenthema}}). Der zukunftssichere Zugriff auf die Fritzbox sollte also per TR-064 erfolgen. Der Vollständigkeit halber und für ältere Firmwareversionen:

# Wer den Zugang per Telnet (noch) nutzen (kann und) möchte, muss dies zuerst freischalten. Üblicherweise durch Eingabe von #96*7* an einem direkt an der entsprechenden FritzBox angeschlosssenen Telefon

# Auf dem System, auf dem Fhem läuft ([[Systemübersicht#Server|Server]]) muss Telnet installiert sein; auf einem [[Raspberry Pi]] und unter Ubuntu z. B. mit dem Befehl
:::<code>sudo apt-get install libnet-telnet-perl</code>

== Installation ==

=== Erste Schritte ===
Zur Erstinstallation reicht ein einfaches <code>define FritzBox FRITZBOX</code>, dieses Modul funktioniert lokal (FHEM auf Fritzbox) sowie per Fernzugriff (FHEM auf einem anderen Server im Netz, siehe nächsten Schritt).

==== TR-064: Modul FRITZBOX für Zugriff auf einem externen Server einrichten ====
Für den Fernzugriff über TR-064 auf eine oder mehrere Fritzboxen und/oder einen FRITZ!WLAN Repeater sind die folgenden Schritte nötig (für jedes Gerät):

Fritzbox definieren:
:<code>define FritzBox FRITZBOX</code>

Wenn das Login auf der Benutzeroberfläche der FritzBox mit User und Passwort (und nicht nur per Passwort) geschieht, den User konfigurieren:
:<code>attr FritzBox boxUser ''Benutzername'' </code>

Passwort konfigurieren:
:<code>set FritzBox password ''Passwort'' </code> - legt das zugehörige Passwort fest

Manuelle TR-064 Kommandos erlauben (die Abfrage per TR-064 funktioniert auch ohne dieses Attribut):
:<code>attr FritzBox allowTR064Command 1</code>

Wenn die Fritzbox nicht unter http://fritz.box erreichbar ist, IP setzen:
:<code>attr FritzBox fritzBoxIP 192.168.168.168</code>
(192.168.168.168 natürlich durch die passende IP ersetzen...) Manchmal ist ein Neustart von FHEM erforderlich, damit die Fritzbox mit der veränderten IP gefunden wird.

==== Telnet: Modul FRITZBOX für Zugriff auf einem externen Server einrichten ====
[[Datei:Screenshot_FritzBox_TelnetUser.png|mini|300px|rechts|Anlegen des Attributs telnetUser]]
Bei Fernzugriff über Telnet sind weitere Schritte nötig:
# Telnet auf der Fritzbox freischalten (Tastenkombination #96*7* am angeschlossenen Telefon (auch FritzFon)
# TelnetUser definieren (wie im Screenshot gezeigt)
# Passwort zum Benutzer auf der Fritzbox definieren

[[Datei:Screenshot_FritzBox_Passwort.png|mini|300px|rechts|Passwort definieren]]

(bitte die Buttons {{Taste|set}} und {{Taste|attr}} bei der Definition der jeweiligen Einträge nicht vergessen)

Wer stattdessen lieber das [[Konfiguration|Befehl-Eingabefeld]] verwendet:

:<code>define FritzBox FRITZBOX</code>
:<code>attr FritzBox telnetUser ''Benutzername'' </code> - legt den Benutzer fest
:<code>set FritzBox password ''Passwort'' </code> - legt das zugehörige Passwort fest

Wer keinen User konfiguriert hat, kann das Feld "telnetUser" leer lassen.

Wer sicher gehen möchte, dass auch tatsächlich Telnet und nicht andere Zugriffe benutzt werden, sollte außerdem noch setzen:

:<code>attr FritzBox forceTelnetConnection 1</code>

=== mögliche Fehlermeldungen ===
Sollte schon bei <code>define FritzBox FRITZBOX</code> die Fehlermeldung kommen, dass dieses Modul nicht existiert, dann bitte prüfen, ob Fhem auf dem aktuellen Stand ist und ggf. [[Update|aktualisieren]].

Kommt jetzt bei der erneuten Definition die Fehlermeldung <code>Error: Perl modul Net::Telnet is missing on this system</code> bitte wie oben schon erwähnt den Befehl
:<code>sudo apt-get install libnet-telnet-perl</code>
direkt per Telnet/SSH auf dem FHEM-Server ausführen und neu starten.
Sollte alles geklappt haben, seht ihr nun eure Fritzbox und könnt diverse Einstellungen manuell vornehmen und/oder automatisch vornehmen lassen.

== Anwendung ==
=== Define ===
Siehe [http://fhem.de/commandref_DE.html#FRITZBOX commandref]

=== Attribute ===
Siehe commandref

=== TR-064 ===
Die offizielle Programmier-Schnittstelle der Fritz!Box läuft über das Protokoll TR-064.

mit dem Attribute 
<code>attr <device> allowTR064Command 1</code> 
kann man den Befehl 
<code>get <device> tr064Command <service> <control> <action> [[parameterName1 parameterValue1] ...]</code> 
freischalten und damit auf diese Schnittstelle zugreifen.

AVM hat die Schnittstellenbeschreibung unter [http://avm.de/service/schnittstellen/] veröffentlicht. Ein weitere Einstiegspunkt befindet sich auch auf der Box unter http://fritz.box:49000/tr64desc.xml

Folgende Service und Controls existieren (für den get-Befehl werden nur die fett formatierten Wörter benötigt)

{| class="wikitable"
|-
!serviceType!!controlURL!!XML!!Dokument bei AVM
|-
|<nowiki>urn:dslforum-org:service:</nowiki>'''DeviceInfo:1'''||/upnp/control/'''deviceinfo'''||[http://fritz.box:49000/deviceinfoSCPD.xml deviceinfoSCPD.xml]||[http://avm.de/fileadmin/user_upload/Global/Service/Schnittstellen/deviceinfoSCPD.pdf deviceinfoSCPD.pdf]
|-
|<nowiki>urn:dslforum-org:service:</nowiki>'''DeviceConfig:1'''||/upnp/control/'''deviceconfig'''||[http://fritz.box:49000/deviceconfigSCPD.xml deviceconfigSCPD.xml]||[http://avm.de/fileadmin/user_upload/Global/Service/Schnittstellen/deviceconfigSCPD.pdf deviceconfigSCPD.pdf]
|-
|<nowiki>urn:dslforum-org:service:</nowiki>'''Layer3Forwarding:1'''||/upnp/control/'''layer3forwarding'''||[http://fritz.box:49000//layer3forwardingSCPD.xml layer3forwardingSCPD.xml]||[http://avm.de/fileadmin/user_upload/Global/Service/Schnittstellen/layer3forwardingSCPD.pdf layer3forwardingSCPD.pdf]
|-
|<nowiki>urn:dslforum-org:service:</nowiki>'''LANConfigSecurity:1'''||/upnp/control/'''lanconfigsecurity'''||[http://fritz.box:49000//lanconfigsecuritySCPD.xml lanconfigsecuritySCPD.xml]||[http://avm.de/fileadmin/user_upload/Global/Service/Schnittstellen/lanconfigsecuritySCPD.pdf lanconfigsecuritySCPD.pdf]
|-
|<nowiki>urn:dslforum-org:service:</nowiki>'''ManagementServer:1'''||/upnp/control/'''mgmsrv'''||[http://fritz.box:49000//mgmsrvSCPD.xml mgmsrvSCPD.xml]||[http://avm.de/fileadmin/user_upload/Global/Service/Schnittstellen/mgmsrvSCPD.pdf mgmsrvSCPD.pdf]
|-
|<nowiki>urn:dslforum-org:service:</nowiki>'''Time:1'''||/upnp/control/'''time'''||[http://fritz.box:49000//timeSCPD.xml timeSCPD.xml]||[http://avm.de/fileadmin/user_upload/Global/Service/Schnittstellen/timeSCPD.pdf timeSCPD.pdf]
|-
|<nowiki>urn:dslforum-org:service:</nowiki>'''UserInterface:1'''||/upnp/control/'''userif'''||[http://fritz.box:49000//userifSCPD.xml userifSCPD.xml]||[http://avm.de/fileadmin/user_upload/Global/Service/Schnittstellen/userifSCPD.pdf userifSCPD.pdf]
|-
|<nowiki>urn:dslforum-org:service:</nowiki>'''X_VoIP:1'''||/upnp/control/'''x_voip'''||[http://fritz.box:49000//x_voipSCPD.xml x_voipSCPD.xml]||[http://avm.de/fileadmin/user_upload/Global/Service/Schnittstellen/x_voipSCPD.pdf x_voipSCPD.pdf]
|-
|<nowiki>urn:dslforum-org:service:</nowiki>'''X_AVM-DE_Storage:1'''||/upnp/control/'''x_storage'''||[http://fritz.box:49000//x_storageSCPD.xml x_storageSCPD.xml]||[http://avm.de/fileadmin/user_upload/Global/Service/Schnittstellen/x_storageSCPD.pdf x_storageSCPD.pdf]
|-
|<nowiki>urn:dslforum-org:service:</nowiki>'''X_AVM-DE_OnTel:1'''||/upnp/control/'''x_contact'''||[http://fritz.box:49000//x_contactSCPD.xml x_contactSCPD.xml]||[http://avm.de/fileadmin/user_upload/Global/Service/Schnittstellen/x_contactSCPD.pdf x_contactSCPD.pdf]
|-
|<nowiki>urn:dslforum-org:service:</nowiki>'''X_AVM-DE_WebDAVClient:1'''||/upnp/control/'''x_webdav'''||[http://fritz.box:49000//x_webdavSCPD.xml x_webdavSCPD.xml]||[http://avm.de/fileadmin/user_upload/Global/Service/Schnittstellen/x_webdavSCPD.pdf x_webdavSCPD.pdf]
|-
|<nowiki>urn:dslforum-org:service:</nowiki>'''X_AVM-DE_UPnP:1'''||/upnp/control/'''x_upnp'''||[http://fritz.box:49000//x_upnpSCPD.xml x_upnpSCPD.xml]||[http://avm.de/fileadmin/user_upload/Global/Service/Schnittstellen/x_upnp.pdf x_upnp.pdf]
|-
|<nowiki>urn:dslforum-org:service:</nowiki>'''X_AVM-DE_RemoteAccess:1'''||/upnp/control/'''x_remote'''||[http://fritz.box:49000/x_remoteSCPD.xml x_remoteSCPD.xml]||[http://avm.de/fileadmin/user_upload/Global/Service/Schnittstellen/x_remoteSCPD.pdf x_remoteSCPD.pdf]
|-
|<nowiki>urn:dslforum-org:service:</nowiki>'''X_AVM-DE_MyFritz:1'''||/upnp/control/'''x_myfritz'''||[http://fritz.box:49000/x_myfritzSCPD.xml x_myfritzSCPD.xml]||[http://avm.de/fileadmin/user_upload/Global/Service/Schnittstellen/x_myfritzSCPD.pdf x_myfritzSCPD.pdf]
|-
|<nowiki>urn:dslforum-org:service:</nowiki>'''X_AVM-DE_TAM:1'''||/upnp/control/'''x_tam'''||[http://fritz.box:49000/x_tamSCPD.xml x_tamSCPD.xml]||[http://avm.de/fileadmin/user_upload/Global/Service/Schnittstellen/x_tam.pdf x_tam.pdf]
|-
|<nowiki>urn:dslforum-org:service:</nowiki>'''X_AVM-DE_AppSetup:1'''||/upnp/control/'''x_appsetup'''||[http://fritz.box:49000/x_homeautoSCPD.xml x_homeautoSCPD.xml]||[http://avm.de/fileadmin/user_upload/Global/Service/Schnittstellen/x_appsetupSCPD.pdf x_appsetupSCPD.pdf]
|-
|<nowiki>urn:dslforum-org:service:</nowiki>'''X_AVM-DE_Homeauto:1'''||/upnp/control/'''x_homeauto'''||[http://fritz.box:49000/x_homeautoSCPD.xml x_homeautoSCPD.xml]||[http://avm.de/fileadmin/user_upload/Global/Service/Schnittstellen/x_homeautoSCPD.pdf x_homeautoSCPD.pdf]
|-
|<nowiki>urn:dslforum-org:service:</nowiki>'''WLANConfiguration:1'''||/upnp/control/'''wlanconfig1'''||[http://fritz.box:49000/wlanconfigSCPD.xml wlanconfigSCPD.xml]||[http://avm.de/fileadmin/user_upload/Global/Service/Schnittstellen/wlanconfigSCPD.pdf wlanconfigSCPD.pdf]
|-
|<nowiki>urn:dslforum-org:service:</nowiki>'''WLANConfiguration:2'''||/upnp/control/'''wlanconfig2'''||[http://fritz.box:49000/wlanconfigSCPD.xml wlanconfigSCPD.xml]||[http://avm.de/fileadmin/user_upload/Global/Service/Schnittstellen/wlanconfigSCPD.pdf wlanconfigSCPD.pdf]
|-
|<nowiki>urn:dslforum-org:service:</nowiki>'''WLANConfiguration:3'''||/upnp/control/'''wlanconfig3'''||[http://fritz.box:49000/wlanconfigSCPD.xml wlanconfigSCPD.xml]||[http://avm.de/fileadmin/user_upload/Global/Service/Schnittstellen/wlanconfigSCPD.pdf wlanconfigSCPD.pdf]
|-
|<nowiki>urn:dslforum-org:service:</nowiki>'''Hosts:1'''||/upnp/control/'''hosts'''||[http://fritz.box:49000/hostsSCPD.xml hostsSCPD.xml]||[http://avm.de/fileadmin/user_upload/Global/Service/Schnittstellen/hostsSCPD.pdf hostsSCPD.pdf]
|-
|<nowiki>urn:dslforum-org:service:</nowiki>'''LANEthernetInterfaceConfig:1'''||/upnp/control/'''lanethernetifcfg'''||[http://fritz.box:49000/lanifconfigSCPD.xml lanifconfigSCPD.xml]||[http://avm.de/fileadmin/user_upload/Global/Service/Schnittstellen/lanifconfigSCPD.pdf lanifconfigSCPD.pdf]
|-
|<nowiki>urn:dslforum-org:service:</nowiki>'''LANHostConfigManagement:1'''||/upnp/control/'''lanhostconfigmgm'''||[http://fritz.box:49000/lanhostconfigmgmSCPD.xml lanhostconfigmgmSCPD.xml]||[http://avm.de/fileadmin/user_upload/Global/Service/Schnittstellen/lanhostconfigmgmSCPD.pdf lanhostconfigmgmSCPD.pdf]
|-
|<nowiki>urn:dslforum-org:service:</nowiki>'''WANCommonInterfaceConfig:1'''||/upnp/control/'''wancommonifconfig1'''||[http://fritz.box:49000/wancommonifconfigSCPD.xml wancommonifconfigSCPD.xml]||[http://avm.de/fileadmin/user_upload/Global/Service/Schnittstellen/wancommonifconfigSCPD.pdf wancommonifconfigSCPD.pdf]
|-
|<nowiki>urn:dslforum-org:service:</nowiki>'''WANDSLInterfaceConfig:1'''||/upnp/control/'''wandslifconfig1'''||[http://fritz.box:49000/wandslifconfigSCPD.xml wandslifconfigSCPD.xml]||[http://avm.de/fileadmin/user_upload/Global/Service/Schnittstellen/wandslifconfigSCPD.pdf wandslifconfigSCPD.pdf]
|-
|<nowiki>urn:dslforum-org:service:</nowiki>'''WANDSLLinkConfig:1'''||/upnp/control/'''wandsllinkconfig1'''||[http://fritz.box:49000/wandsllinkconfigSCPD.xml wandsllinkconfigSCPD.xml]||[http://avm.de/fileadmin/user_upload/Global/Service/Schnittstellen/wandsllinkconfigSCPD.pdf wandsllinkconfigSCPD.pdf]
|-
|<nowiki>urn:dslforum-org:service:</nowiki>'''WANEthernetLinkConfig:1'''||/upnp/control/'''wanethlinkconfig1'''||[http://fritz.box:49000/wanethlinkconfigSCPD.xml wanethlinkconfigSCPD.xml]||[http://avm.de/fileadmin/user_upload/Global/Service/Schnittstellen/wanethlinkconfigSCPD.pdf wanethlinkconfigSCPD.pdf]
|-
|<nowiki>urn:dslforum-org:service:</nowiki>'''WANPPPConnection:1'''||/upnp/control/'''wanpppconn1'''||[http://fritz.box:49000/wanpppconnSCPD.xml wanpppconnSCPD.xml]||[http://avm.de/fileadmin/user_upload/Global/Service/Schnittstellen/wanpppconnSCPD.pdf wanpppconnSCPD.pdf]
|-
|<nowiki>urn:dslforum-org:service:</nowiki>'''WANIPConnection:1'''||/upnp/control/'''wanipconnection1'''||[http://fritz.box:49000/wanipconnSCPD.xml wanipconnSCPD.xml]||[http://avm.de/fileadmin/user_upload/Global/Service/Schnittstellen/wanipconnSCPD.pdf wanipconnSCPD.pdf]
|-
|}

=== Status-Symbol ===
<code>attr <device> devStateIcon .*on.*off:WLAN_on_gWLAN_off .*on.*on.*:WLAN_on_gWLAN_on WLAN..off.*:WLAN_off</code>

Im Verzeichnis www/images/default müssen die passenden Dateien "WLAN_on_gWLAN_off.png", "WLAN_on_gWLAN_on.png" und "WLAN_off.png" liegen. Wenn die PNGs fehlen, können sie hier [http://forum.fhem.de/index.php/topic,29725.msg318113.html#msg318113] heruntergeladen werden.

== Anwendungsbeispiele ==
[[Datei:Screenshot_FritzBox1.png|mini|300px|rechts|FRITZBOX Gerät auf der Fhem Oberfläche]]
Sollte alles geklappt haben, seht ihr nun unter "Unsortiert" den im nebenstehenden Screenshot gezeigten Eintrag für das "Gerät" (hier mit dem Icon "it_router").

=== TR-064 Bespiele ===

*Box Reboot: <code>get <device> tr064Command DeviceConfig:1 deviceconfig Reboot</code>

=== Klingel- und Sprachausgabe per TR-064 ===

Das geht derzeit nicht, da entsprechende Kommandos per TR-064 nicht verfügbar sind. Da Telnet sukzessive abgestellt wird, sollten sich Interessenten per Feature-Request an AVM wenden, wie hier [http://forum.fhem.de/index.php/topic,38586.0.html] beschrieben.

=== Anwesenheitserkennung ===

Fritzboxen und die FRITZ!WLAN Repeater speichern den Status angemeldeter Geräte. Dieser Status lässt sich mittels des FRITZBOX Moduls über Readings abfragen, die das Format mac_AA_AA_AA_AA_AA_AA haben und die MAC-Adressen der jeweils angemeldeten Geräte (AA:AA:AA:AA:AA:AA) enthalten. Das Reading existiert, wenn das Gerät angemeldet ist. Wenn das Gerät abgemeldet ist, existiert es ist. Es gibt auch noch den Zwischenstatus "inactive", der anscheinend gesetzt wird, bevor das Reading gelöscht wird.

Mit Hilfe des PRESENCE Moduls (vgl. [[Anwesenheitserkennung]]) kann man auf diese Weise den Anwesenheitsstatus abfragen. Anregungen dazu gibt es im zugehörigen {{Link2Forum|Topic=39422|LinkText=Forenthread}} zur Anwesenheitserkennung und in einem Blogpost: [http://heinz-otto.blogspot.de/2015/07/die-zeiten-andern-sich.html]. Auf dieser Basis könnte eine einfache Implementierung zum Beispiel so aussehen:

Funktion in 99_myUtils.pm:

<pre>sub checkFritzMACpresent($$) {
# Benötigt: Name der zu testenden Fritzbox ($Device),
# zu suchende MAC ($MAC),
# Rückgabe: 1 = Gerät gefunden
# 0 = Gerät nicht gefunden
my ($Device, $MAC) = @_;
my $Status = 0;
$MAC =~ tr/:/_/;
$MAC = "mac_".uc($MAC);
my $StatusFritz = ReadingsVal($Device, $MAC, "weg");
if ($StatusFritz eq "weg") {
Log 1, ("checkFritzMACpresent ($Device): $MAC nicht gefunden, abwesend.");
$Status = 0;
} elsif ($StatusFritz eq "inactive") {
Log 1, ("checkFritzMACpresent ($Device): $MAC ist >inactive<, also abwesend.");
$Status = 0;
} else {
# Reading existiert, Rückgabewert ist nicht "inactive", also ist das Gerät per WLAN angemeldet.
Log 1, ("checkFritzMACpresent ($Device): $MAC gefunden, Gerät heißt >$StatusFritz<.");
$Status = 1;
}
return $Status
}
</pre>

Nutzung dieser Funktion mit dem PRESENCE Modul definieren:

<code>define <Name> PRESENCE function {checkFritzMACpresent("Fritzbox","AA:BB:CC:DD:EE:FF")} 60 60</code>

wobei
*<Name> ein beliebig zu wählender Name für die PRESENCE-Funktion ist,
*Fritzbox der Name ist, mit dem ihr die abzufragende Fritzbox als FRITZBOX definiert habt,
*AA:BB:CC:DD:EE:FF die MAC-Adresse des gesuchten Geräts ist.
* "60 60" sagt, dass der Anwesenheitsstatus im 60-Sekunden-Takt abgefragt wird. Das macht natürlich nur Sinn, wenn ihr mit <code>attr Fritzbox INTERVAL 60</code> den Abfrageinterval bei der Fritzbox auch entsprechend hochgesetzt habt. Der Standard ist 300.

Weitere Hinweise zu komplexeren Abfragen mehrere Boxen auf einmal etc. findet ihr auch im {{Link2Forum|Topic=39422|LinkText=Forenthread}}.

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

[[Kategorie:FritzBox]]

FRITZBOX

2015-08-21T06:40:29Z

Motivierte linke Hände: Einheitliche Schreibweise Fritz*B*ox statt Fritz*b*ox im Code, kleinere Ergänzungen

Apptime

2015-08-20T12:26:20Z

Motivierte linke Hände: Erklärungen der Ausgabewerte ergänzt

{{SEITENTITEL:apptime}}
{{Infobox Modul
|ModPurpose=Ausführungszeit von Applikationen (Modulen) protokollieren
|ModType=cmd
|ModCmdRef=apptime
|ModForumArea=Sonstiges
|ModTechName=98_apptime.pm
|ModOwner=Martin/martinp876 ({{Link2FU|251|Forum}}/[[Benutzer Diskussion:Martinp876|Wiki]])
}}

Mit dem Befehl [[apptime]] wird das Protokollieren von Ausführungszeiten von Modulen und Funktionen gestartet. apptime hilft rauszufinden WER blockiert; [[perfmon]] ist der Indikator DASS ETWAS blockiert ({{Link2Forum|Topic=39253|Message=314155}}).

== Voraussetzungen ==
Keine.

== Anwendung ==
=== Aktivieren ===
Die Überwachung der Ausführungszeiten wird mit dem Befehl ''apptime'' (einzugeben in das [[Konfiguration|Befehlseingabefeld]]) gestartet.

=== Beenden ===
Um ''apptime'' zu beenden, muss Fhem neu gestartet werden.

Die aufgelaufenen protokollierten Werte können mit dem Befehl
:<code>apptime clear</code>
zurückgesetzt werden.

=== Auswertung ===
Die von ''apptime'' protokollierten Informationen können durch Eingabe des Befehls
:<code>apptime</code>
abgerufen werden. Ein (Beispiel!) Auszug aus der resultierenden Tabelle:
<pre>
name function max count total average maxDly
myJee JeeLink_Read 139 20 298 14.90 0 HASH(myJee)
myCUL CUL_Read 76 6 233 38.83 0 HASH(myCUL)
...
</pre>
Die Felder haben folgende Bedeutung:

<pre>
name: Entity, für die es ausgeführt wird
Wenn 'tmr-' vor dem Namen steht ist es durch einen Timer (InternalTimer) aufgerufen worden.
funktion: Name der Funktion, die ausgeführt wird
param max call: Input-Parameter an die Funktion beim längsten Aufruf
max: maximale Laufzeit in ms
count: Anzahl der Aufrufe
total: akkumulierte Laufzeit der Funktion in ms
average: durchschnittliche Laufzeit (total/count) in ms.
</pre>

{{Randnotiz|RNTyp=y|RNText=Bitte beachten: der Parameter für die Sortierung nach Spalte ''function'' lautet ''fun'''k'''tion''!}}
Durch Angabe eines Parameters
:<code>apptime [count|funktion|average|max|name|total]</code>
wird die Tabelle nach den Werten der entsprechenden Spalte sortiert.

Soll die komplette Tabelle ausgegeben werden, muss zusätzlich zum Spaltennamen noch der Parameter ''all'' angegeben werden (z.B.):
:<code>apptime count all</code>

== Anwendungsbeispiele ==

== Links ==
* Download von apptime.pm: [http://forum.fhem.de/index.php/topic,16103.msg111482.html#msg111482]

FRITZBOX

2015-08-20T10:25:12Z

Motivierte linke Hände: Weitere Anpassung Migration telnet -> TR-064

FRITZBOX

2015-08-20T08:24:22Z

Motivierte linke Hände: IP-Konfiguration bei nicht standardmäßiger Fritzbox-Konfiguration ergänzt

FRITZBOX

2015-08-20T07:42:22Z

Motivierte linke Hände: Installationshinweise Ubuntu ergänzt

FRITZBOX

2015-08-19T12:45:59Z

Motivierte linke Hände: Erste Anpassungen, um den Wiki-Artikel auf den aktuellen Stand zu bringen (Abschaltung Telnet auf Fritzboxen)...

1-Wire Busverlegung

2015-06-20T14:37:11Z

Motivierte linke Hände: Kabelbelegung ergänzt.

== Kabeltypen ==
Es kann eine Vielzahl von Kabeltypen verwendet werden.

Eine Abschirmung sollte möglichst immer vorhanden sein, ist aber nicht zwingend notwendig. Die Verwendung dieser Abschirmung als Nutzleitung ist eher ungünstig, sie sollte vielmehr einseitig (!) an Masse=GND angeschlossen sein.

Anforderungen an den Durchmesser der einzelnen Adern werden durch den Stromverbrauch der 1-Wire-Komponenten bestimmt. Hat man nur Temperatursensoren etc., reichen 0.6 mm vollständig aus, das Kabel könnte sogar noch dünner sein (z.B. um es unauffällig unter Tapeten zu verlegen). Wenn Aktoren, LEDs, oder sonstige echte Stromverbraucher auf dem Bus sitzen, sollten 0.8 mm Aderdurchmesser vorgesehen werden.

Die Frequenzen, die über diese Kabel transportiert werden müssen, liegen im niederfrequenten Bereich (Anstiegs- und Abfallzeit der Impulse bei ca. 20-30 Mikrosekunden). Abrupte Veränderungen des Kabeldurchmessers oder der Kabelart führen immer immer zu Sprüngen der Impedanz (Wellenwiderstand) und damit zur Reflexion, die sich in einer Verschlechterung der Impulsqualität bemerkbar macht. Es ist daher zu empfehlen, nicht zu viele solche Wechsel auf dem Weg zum Sensor/Aktor einzubauen.

*Für parasitär (d.h. aus der Datenleitung) versorgte Sensoren und Aktoren reichen 2 Adern = 1 Aderpaar vollständig aus (Datenleitung und Masse=GND)
*Für Sensoren und Aktoren mit echter Spannungsversorgung ist eine dritte Ader mit +5V vorzusehen. Wenn ein externes Netzteil verwendet wird, ist zu beachten, dass GND des Netzteils auch mit GND des Busmasters verbunden werden muss.
*Für größere Netze ist zu beachten, dass keine Sterntopologie entsteht: Zwei längere Kabel (d.h., länger als 3,5 m) an einem Busmaster erfordern dann, dass das eines der beiden Kabel als Hin- + Rückleitung ausgelegt wird, das erfordert dann also 4 Adern = 2 Aderpaare. Siehe hierzu den unten stehenden Abschnitt

=== Netzwerkkabel ===
Hierbei handelt es sich typischerweise um STP(Shielded Twisted Pair)-Kabel mit 8 Adern, 4x2x0.8mm bis zu 4x2x0.1mm für extra flache Kabel. Ein ''Twisted Pair'' weist über seine Länge eine einigermaßen homogene Impedanz auf, um diese nicht zu stören, sind zu kleine Biegeradien zu vermeiden
=== Brandmeldekabel ===
Dieses Kabel hat unterschiedliche Anzahl von Aderpaaren, z.B. 2x2x0.8mm, aber auch 2x3, 2x4 oder gar 2x5 Aderpaare; die äußere Farbe ist rot. Kosten ab 0,40 €/m.
=== EIB/KNX Buskabel ===
Dieses Kabel hat 4 Adern 2x2x0.8mm und ist mit einem Folienschirm geschirmt, die äußere Farbe ist meist grün. Kosten ab 0,40 €/m. Die 4. Ader kann entweder zur Datenrückleitung verwendet werden, oder eine weitere Spannung (z.B. 12 V) zu Aktoren (z.B. Relais) transportieren.
=== Geschirmtes Fernmeldekabel ===
Dieses Kabel hat 4 Adern 2x2x0.6mm und ist mit einem Folienschirm geschirmt, die äußere Farbe ist meist grau. Kosten ab 0,20 €/m. Die 4. Ader kann entweder zur Datenrückleitung verwendet werden, oder eine weitere Spannung (z.B. 12 V) zu Aktoren (z.B. Relais) transportieren.
=== Geschirmtes NF-Kabel ===
Auch als Mikrofonkabel verkauft, zwei Innenleiter in gemeinsamer Abschirmung. Diese wird dann als 3. Leiter verwendet. Das Kabel ist sehr flexibel und daher besonders für den mobilen Anschluss von Sensoren/Aktoren geeignet. Bewährt hat sich dies für kurze ''Stubs'' (max. 3.5 m), mit denen Sensoren/Aktoren an den Bus angeschlossen werden. Hierfür gibt es preisgünstige Kabelenden mit angegossenem 3.5 mm Klinkenstecker.

Auch kommerziell erhältliche Busmaster, wie der USB9097, haben solche Klinkenbuchsen. (Foto folgt)

=== Ungeschirmtes 3-adriges Kabel===
Prinzipiell auch geeignet, sorgt aber bei großen Leitungslängen für eine gewisse Störanfälligkeit. Bei Abzweigungen oder für kurze ''Stubs'' aber problemlos verwendbar.

Bei eBay sind preisgünstige 1-Wire Temperatursensoren in wasserdichtem Gehäuse erhältlich, die mit einem solchen Kabelende versehen sind.
===Belegung===
Es muss ausdrücklich betont werden, dass für die Belegung der Adern keine wie auch immer geartete Norm existiert. Die nachfolgenden Farbcodierungen sind lediglich Beispiele.
{| class="wikitable" style="text-align:center"
! Typ !! style="width:5em;"|GND Masse !! style="width:5em;"|VDD +5V !! style="width:5em;"|1-Wire Data !! style="width:5em;"|1-Wire Return !! Bemerkung / Vorgabe durch
|-
| Fernmeldekabel || style="color:white;background:#000000"|sw || style="color:white;background:red"|rt || style="background:yellow"|ge || style="background:white"|ws
|-
| Mikrofonkabel || style="background:white"|ws (schwarz) || style="color:white;background:#AAAAAA"|Schirm (rot) || style="color:white;background:red"|rt (gelb) || style="color:white;background:grey"| -- || Busmaster USB9097 (Sensoren mit Klinkenstecker)
|-
| Ungeschirmtes 3-adriges Kabel || style="color:white;background:green"|gn || style="color:white;background:red"|rt || style="background:yellow"|ge || style="color:white;background:grey"| -- || Kommerzielle Sensoren
|-
| Netzwerkkabel || style="background:white"|blau-weiß orange-weiß || style="color:black;background:#FAB514"|orange || style="color:white;background:blue"|blau || style="color:white;background:grey"| n. def. || LinkUSB(i)
|}

Anm. zum Mikrofonkabel: Die Werte in Klammern geben die Belegung bei (einigen) kommerziell erhältlichen Sensoren wieder (z.B. 1WAD_5V), bei denen der Anschluss an den 1-Wire-Bus über Klinkenstecker funktioniert.

== Verbindung verschiedener Kabeltypen ==
[[Datei:Connectionbox.jpg|mini|links|Connectionbox (geöffnet)]]
[[Datei:Connectionbox unten.jpg|mini|rechts|Connectionbox Platinenunterseite (paarweise Verbindung der Adern)]]
Gute Erfahrungen wurden gemacht mit ''CAT 5 Connection Boxes'' für Netzwerkkabel, die für ca. 1,50€ z.B. bei Reichelt erhältlich sind. Voraussetzung für die Verwendung ist allerdings der Besitz eines ''LSA-Anlegewerkzeuges'' (ca. 6 €). Da meist nur 4 Adern benötigt werden, können die insgesamt 8 Adern auf der Unterseite paarweise verbunden werden. Dafür sollte man möglichst den gleichen Aderdurchmesser verwenden, wie er in der Zu- und Ableitung auftritt.

 
==Topologie==
Maßgebliches Whitepaper für '''große Kabellängen''' ist das von Maxim herausgegebene Tutorial [http://pdfserv.maximintegrated.com/en/an/AN148.pdf Guidelines for Reliable Long 1-Wire Networks].

Die Kabellänge bis zum entferntesten Sensor kann bis zu 100 m betragen. Typischerweise werden die einzelnen 1-Wire-Komponenten an eine zentrale Busleitung über so genannte ''Stubs'' (kurze Kabelenden) angeschlossen, diese sollten nicht länger als 3.5 m sein. Die gleiche Beschränkung der Leitungslänge gilt, wenn alle 1-Wire Komponenten sternförmig zusammengeführt werden (Sterntopologie).

Bei Kabellängen von mehr als 3.5 m sollte immer eine lineare Topologie eingehalten werden (bis auf die ''Stubs''), gegebenenfalls ist die Datenleitung ('''nicht''' Masse und Stromversorgung) als Hin- und Rückleitung vorzusehen.
<gallery widths="250" caption="1-Wire Topologien" mode="packed">
1-wire_T1.png|Sterntopologie
1-wire_T2.png|Lineare Topologie
1-wire_T3.png|Lineare Topologie mit sternförmiger Anordnung einzelner Gruppen
</gallery>

==Pullup==
Maßgebliches Whitepaper für die Frage eines '''Pullup'''-Widerstandes, der bei gewissen Operationen den Datenbus mit mehr Strom versorgt, ist das von Maxim herausgegebene Tutorial [http://pdfserv.maximintegrated.com/en/an/AN4255.pdf How to Power the Extended Features of 1-Wire Devices].

== Links ==
* Informationen zum Aufbau des 1-Wire Bus [http://shop.wiregate.de/1-wire-bus]
* Weitere Informationen zum Aufbau des 1-Wire Bus [http://www.fuchs-shop.com/de/howto/linkfamily/]
[[Kategorie:1-Wire]]

FHEM2FHEM

2015-05-25T12:00:04Z

Motivierte linke Hände: Ergänzung watchdog-Überwachung von FHEM2FHEM Verbindung

{{SEITENTITEL:FHEM2FHEM}}
{{Infobox Modul
|ModPurpose=Hilfsmodul, um mehrere Fhem-Installationen zu verbinden
|ModType=h
|ModForumArea=Automatisierung
|ModTechName=93_FHEM2FHEM.pm
|ModOwner=rudolfkoenig ([http://forum.fhem.de/index.php?action=profile;u=8 Forum] / [[Benutzer Diskussion:Rudolfkoenig|Wiki]])
}}
[[FHEM2FHEM]] ist ein Hilfsmodul mit dem mehrere Fhem-Installationen -auch auf verschiedenen Rechnern- verbunden werden können

__TOC__

{{Todo|Fehlerkontrolle, Formatierung, Ergänzungen aus dem Forum, Bedeutung des Attributs dummy, Ergänzung ''Bekannte Probleme''}}

== Features / Funktionen ==
Dieses Modul bietet zwei grundsätzlich unterschiedliche Funktionsmöglichkeiten:
# Es kann alle Ereignisse (Events) von einem entfernten (remote) host abgreifen und an die lokale FHEM Instanz zur Weiterverarbeitung weiterreichen.
# Es kann die unaufbereitete Ereignisse (raw messages) von einem entfernten (remote) host und bestimmten Interfaces abgreifen und an die lokale FHEM Instanz weiterreichen.

Die Kommunikation ist unidirektional bzw. die Daten werden auf der lokalen Instanz von einer entfernten Instanz abgegriffen. Ein Element vom Type FHEM2FHEM wird auf der lokalen Instanz definiert.

== Anwendung ==

Beispiele für die Anwendung sind
* zur Verteilung der Interfaces auf mehrere FHEM Instanzen,
** Da an einer Hardwareinstanz ggf. zu wenig USB-Ports vorhanden sind, um stabil betrieben werden zu könne (z.B. RPi).
** Um eine zeitkritische und eine weniger zeitkritische Hardwareinstanz zu betreiben, da bestimmte Module die FHEM Instanz für eine gewisse Zeit verzögern können (Verzögerungen verursachen z.B. disconnects des HMLan beim keepalive).
** Um die Hauptinstanz von bestimmten Verarbeitungsschritten der Events zu entlasten, obwohl man hier zunächst untersuchen sollte, ob die Verarbeitung nicht eleganter und weniger Prozessorintensiv ausgeführt werden kann.
* Um längere örtliche Distanzen zu überbrücken,
** da z.B. die Funkreichweite bestimmter Signale für einen stabilen Betrieb zu gering ist.
** da ein Sensor nur lokal betrieben werden kann und die Distanz zur Hauptinstanz zu groß ist, z.B. bei direkt per USB an der Hardware Instanz angeschlossen Sensoren (CO2/VOC-Sensor)
* etc.

Lokale und remote FHEM-Instanz sind über ein Netzwerk verbunden.

=== Definition ===

Die Definition erfolgt über
<pre>
define <name> FHEM2FHEM <host>[:<portnr>][:SSL] [LOG:regexp|RAW:devicename] {portpassword}
</pre>

==== Parameter ====

Die Parameter der Definition beziehen sich auf die Verbindung zur entfernten FHEM-Instanz, zum Type der übernommenen Events und auf das Postpasswort, falls bei der entfernten FHEM-Instanz vergeben.

===== <host>[:<portnr>][:SSL] =====

Über <host> ist die IP-Adresse der entfernten FHEM-Instanz zu definieren. Die Portnummer bezieht dich auf die Nummer der Telnetschnittstelle, wie sie auf der entfernten Instanz vergeben ist. Falls nicht explizit verändert, ist diese Nummer standardmäßig 7072. Der letzte Zusatz :SSL muss angegeben werden, wenn die entfernte Instanz eine SSL-verschlüsselte Kommunikation voraussetzt. Ist dieses der Fall, muss auch auf dem lokalen Host das Perl-Modul IO::Socket::SSL installiert sein.

===== [LOG:regexp|RAW:devicename] =====
Der nächste Parameter spezifiziert den Verbindungs-Typ:
; LOG
Bei Verwendung dieses Verbindungstyps werden alle Ereignisse (Events) der entfernten FHEM-Instanz empfangen. Die Ereignisse sehen aus wie die, die nach dem <code>inform on</code> Befehl erzeugt werden. Sie können wie lokale Ereignisse durch FileLog oder notify genutzt werden und mit einem regulären Ausdruck gefiltert werden. Die Syntax dafür ist unter der notify-Definition beschrieben.

Einschränkungen: Geräte der entfernten FHEM-Instanz werden über autocreate lokal nicht automatisch angelegt und können weder mit list angezeigt noch lokal angesprochen werden.

Falls auf beiden FHEM-Installationen Geräte mit gleichem Namen angelegt wurden und die Geräte auch beide dasselbe Ereignis empfangen können (z.B. wenn an beiden Installationen CULs angeschlossen sind), werden logischer Weise alle FileLogs und notifys doppelt, einmal über das lokale Ereignis, einmal über das remote Ereignis ausgelöst.

; RAW
Bei diesem Verbindungstyp werden unaufbereitete Ereignisse (raw messages) des remote FHEM-Geräts devicename genau so empfangen, als wäre das Gerät lokal verbunden.

Einschränkungen: Nur Geräte, welche die "Dispatch-Funktion" unterstützen (CUL, FHZ, CM11, SISPM, RFXCOM, TCM, TRX, TUL), erzeugen raw messages. Für jedes entfernte Gerät, von dem raw messages abgegriffen werden sollen, muss ein eigenes FHEM2FHEM Objekt definiert werden. Dabei ist darauf zu achten, dass der angegebene Name für <code>devicename </code> gleichlautend ist, wie der Devicename auf der entfernten FHEM-Instanz.

Zusätzlich der Definition des FHEM2FHEM Elements, muss für das übernommene Geräte auf der lokalen Instanz ein Dummygerät gleichen Typs, d.h. als device-node "none" definiert werden. An dieses Dummygerät werden alle raw messages von FHME2FHEM weitergeleitet, weshalb auch alle notwendigen Attribute lokal für dieses Dummygerät gesetzt sein müssen (z.B. rfmode, wenn die remote CUL im HomeMatic-Modus läuft).
Die Verwendung bereits bestehender lokaler Geräte für die Weiterverarbeitung des raw messages ist zu vermeiden, weil sonst die Duplikatsfilterung nicht richtig funktioniert (siehe dupTimeout).

Komponenten, die über das Dummygerät erkannt werden, werden über autocreate automatisch angelegt.

===== {portpassword} =====

Falls ein Portpasswort auf der entfernten FHEM-Instanz gesetzt ist, übergibt dieser Parameter das entsprechende Passwort.

=== Attribute ===

==== dummy ====
???

==== disable ====

Deaktiviert die Verbindung.

==== disableForIntervals ====

Das Attribut ist eine leerzeichengetrennte Liste von Minuszeichen- getrennten HH:MM Paaren. Falls die aktuelle Uhrzeit zwischen diesen Werten fällt, dann wird die Ausführung, wie beim disable, ausgesetzt. Eine genaue Beschreibung findet sich in der commandref des Moduls <code>at</code>.

=== Set ===

==== reopen ====

Öffnet die Verbindung erneut.

== Voraussetzungen ==

* Zwei FHEM-Instanzen verbunden über ein Netzwerk mit der Möglichkeit, von der einen (lokal) auf den Telnetport der anderen (entfernte/remote) zuzugreifen zu können.
* Aktivierter Telnetport der entfernten FHEM-Instanz. Diese ist standardmäßig aktiviert.
* Fall das Perl-Modul für die SSL-Verschlüsselung nicht installiert sein, so kann dieses je nach Platform z.B. über folgenden Befehl nachinstalliert werden:
<pre>
sudo apt-get install libwww-perl
</pre>

== Anwendungsbeispiele ==
=== Type LOG ===

==== Verbindung von 2 Fritzboxen ====

Ich habe lange gesucht, wie ich FHEM2FHEM einsetzen kann. Das folgende habe ich mir (Danke an Rübezahl) von den entsprechenden Seiten zusammengeklaubt:

Code FritzBox 1 (entfernte Instanz):
<nowiki>define forwardRemote dummy</nowiki>

Code FritzBox 2 (lokale Instanz):
define Remoteserver FHEM2FHEM 192.168.178.1:7072 LOG:.*

define executeRemote notify forwardRemote {fhem "%"}

Gast-WLAN bei beiden Boxen ausschalten (siehe Beitrag "Fritzbox: WLAN ein/ausschalten", Dummys, notifys und 99_myUtils_irgendwas.pm müssen natürlich auf beiden Boxen vorhanden sein):

Aufruf FritzBox 1:
fhem("set D_G_WLAN off");;fhem("set forwardRemote set D_G_WLAN off");;

==== Weitergabe von Events ====

An eine Fritzbox (entfernte Instanz) ist ein RFXtrx433 angeschlossen. Die Events der erkannten Geräte, in diesem Falle ein Strommesser Revolt-5461 und ein Temperatur- und Feuchtigkeitssensor TFA 30.3150 sollen auf der Hauptinstanz (lokale Instanz) zur Verfügung stehen. Darüber hinaus wird auf der Fritzbox noch der Spritpreis abgerufen, dessen Events ebenfalls auf der Hauptinstanz zur Verfügung stehen sollen.

; Definition auf der entfernten Instanz
Auf der Fritzbox sind die Komponenten ganz normal definiert und loggen in mehrere Filelogs.
Der Telnetport ist standardmäßig auf 7072 definiert.
Es ist keine SSL Verschlüsselung aktiviert und kein Passwort vergeben.

; Definition auf der lokalen Instanz
Die Definition lautet wie folgt, wobei für die Regexp die Readings, die übernommen werden sollen, filtert.
<pre>
define FHEM_on_FB FHEM2FHEM 192.168.1.10:7072 LOG:.*(SuperE[0-9]|temperature|humidity|battery|voltage|energy_power|state).*
</pre>

Damit auf der lokalen Instanz die Geräte dargestellt werden können und nicht nur die Daten in der Datenbank landen, wurden entsprechende Dummies und dazu passende Notfies definiert.

Für den Revolt-5461
<pre>
define KU_Ofen_r dummy
attr KU_Ofen_r DbLogExclude .*

define KU_Ofen_notify notify KU_Ofen { $EVENT=~s/://;;;; fhem("setreading KU_Ofen_r $EVENT");;;; my $KU_Ofen_P= ReadingsVal("KU_Ofen_r","energy_power",0) ;;;; my $KU_Ofen_V= ReadingsVal("KU_Ofen_r","voltage",0) ;;;; fhem("setreading KU_Ofen_r state P: $KU_Ofen_P V: $KU_Ofen_V") }
attr KU_Ofen_notify DbLogExclude .*
</pre>

Für den Spritpreismonitor
<pre>
define Shell_r dummy
attr Shell DbLogExclude .*

define Shell_notify notify Shell { $EVENT=~s/://;;;; fhem("setreading Shell_r $EVENT") ;;;; my $Shell_SE10= ReadingsVal("Shell_r","SuperE10",0) ;;;; my $Shell_SE5= ReadingsVal("Shell_r","SuperE5",0) ;;;; fhem("setreading Shell_r state S_E10: $Shell_SE10 S_E5: $Shell_SE5")}
attr Shell_notify DbLogExclude .*
</pre>

Für den TFA 30.3150
<pre>
define Aussen_Temp_Hum_r dummy
attr Aussen_Temp_Hum DbLogExclude .*

define Aussen_Temp_Hum_notify notify Aussen_Temp_Hum { $EVENT=~s/://;;;; fhem("setreading Aussen_Temp_Hum_r $EVENT") ;;;; my $Aussen_Temp_Hum_T= ReadingsVal("Aussen_Temp_Hum_r","temperature",0) ;;;; my $Aussen_Temp_Hum_H= ReadingsVal("Aussen_Temp_Hum_r","humidity",0) ;;;; my $Aussen_Temp_Hum_D= ReadingsVal("Aussen_Temp_Hum_r","dewpoint",0) ;;;; fhem("setreading Aussen_Temp_Hum_r state T: $Aussen_Temp_Hum_T H: $Aussen_Temp_Hum_H D: $Aussen_Temp_Hum_D")}
attr Aussen_Temp_Hum_notify DbLogExclude .*
</pre>

Das Logging in die Datenbank funktioniert bereits direkt über die FHEM2FHEM Definition. Für das Logging in Filelogs müssten diese wie üblich definiert werden.
Damit die dummies und die notifies keine Extraeinträge in der Datenbank produzieren, wurde das Attribut DbLogExclude mit der Regexp <code>.*</code> gesetzt.
Die Notfies lösen jeweils 2 Aktionen aus
# Schreiben der Readings in das Dummy, wobei der zusätzliche Doppelpunkt übersprungen wird.
# Zusammensammeln der wichtigsten Werte und schreiben des Readings "state" des Dummy

=== Type RAW ===

==== Weitergabe eines Interfaces ====

An eine Fritzbox (entfernte Instanz) ist ein RFXtrx433 angeschlossen. Alle raw messages sollen auf einer weiteren Hauptinstanz zur Verfügung stehen. Vom RFTtrx433 werden messages von einem Strommesser Revolt-5461 und einem Temperatur- und Feuchtigkeitssensor TFA 30.3150 empfangen.

; Definition auf der entfernten Instanz
Auf der Fritzbox ist das Interface RFXtrx433 mit dem Namen RFXTRX_on_FB definiert.
Der Telnetport ist standardmäßig auf 7072 definiert.
Es ist keine SSL Verschlüsselung aktiviert und kein Passwort vergeben.

; Definition auf der lokalen Instanz
Die Definition lautet wie folgt, wobei hinter RAW: der Name des abgegriffenen Interfaces angegeben wird.
<pre>
define FHEM_on_FB FHEM2FHEM 192.168.1.10:7072 RAW:RFXTRX_on_FB
attr FHEM_on_FB DbLogExclude .*
</pre>

Zusätzlich wird ein Dummygerät benötigt, das wie ein lokales Interface agiert.
<pre>
define RFXTRX_on_FB TRX none 0000
attr RFXTRX_on_FB dummy 1
</pre>

In dieser Konfiguration werden die Komponenten an der Fritzbox auf der lokalen Instanz als neue Geräte erkannt mit dem IODev RFXTRX_on_FB.

== Bekannte Probleme ==
Bei auf Dummies gespiegelten Komponenten und einfachem notify/setreading (Type LOG),
* erhalten die Readings einen zusätzlichen Doppelpunkt (Abhilfe: siehe Beispiel bzw. Links)
* muss das Reading "state" explizit geschrieben werden. Sonst zeigt der Status des Dummy nur "???" (Abhilfe: siehe Beispiel)
* FHEM2FHEM stellt nicht immer neue Verbindung hier, wenn das entfernte FHEM stromlos gemacht wurde oder sich anderweitig "unfreundlich" verabschiedet hat. Lösung, Watchdog auf dem Hauptsystem, wie [http://forum.fhem.de/index.php/topic,20654.0 hier] beschrieben. Dabei kann inzwischen statt "modify" auch ein "set <name> reopen" verwendet werden.

== Troubleshooting ==
* Lässt sich der entfernte Host anpingen?
* Lässt sich vom lokalen Host auf der Kommandozeile auf die Telnet-Schnittstelle der entfernten FHEM-Instanz zugreifen?
* Welche Meldungen stehen im Logfile nach einem Restart und dem Versuch des Verbindungsaufbaus zur entfernten FHEM-Instanz?
* Mögliche Fehler beim Loggen
** Tauchen die Messages im Event Monitor der lokalen Instanz auf?
** etc.

== Links ==
Doppelpunkt hinter den Readings im Dummy [http://forum.fhem.de/index.php/topic,20766.msg143244.html#msg143244]

== sonstiges ==
[[Kategorie:Code Snippets]]

OWServer & OWDevice

2015-05-24T06:57:36Z

Motivierte linke Hände: Update zum Kompilieren der aktuellen owfs-Version mit USB-Unterstützung für den Raspi

==Einleitung==

Bei OWServer handelt es sich um eine 1-Wire Server Komponente und bei OWDevice um eine Geräte-Komponente, die die angeschlossenen Module definiert-
Die Module benötigen die Serverkomponente von [http://www.owfs.org OWFS].

'''Wichtig:'''

Die Module sind eine eigenständige Möglichkeit, den 1-Wire Bus anzusteuern und kommen ohne die Module aus, deren Namen aus Großbuchstaben bestehen (wie OWX, OWSWITCH, OWTHERM, etc.).
Umgekehrt können die Module OWSWITCH, OWTHERM, etc. auch mit dem Backendmodul OWServer zusammenarbeiten, siehe dazu die commandref der betreffenden Module.

==Vorbereitung==

Wie oben erwähnt, setzt OWServer/OWDevice auf OWFS auf. Dazu ist eine funktionierende OWFS Installation notwendig. Die Installation ist auf der selben Plattform (Debian-based) möglich oder auch Remote (zBsp Dockstar oder RPi). Eine gute [http://owfs.org/index.php?page=standard-devices Liste der Standard Devices]auf der Homepage von OWFS einzusehen. Nicht alle Standard Devices sind in OWDevice verfügbar (siehe unten).Wenn OWFS funktioniert kann's weiter gehen...

===owfs Pakete installieren===

1) entweder sind die Pakete bereits vorpaketiert und man muss nur das [http://owfs.davromaniak.eu/ Repository] noch in /etc/apt/sources.list eintragen

2) oder man muss selber kompilieren ([http://www.navitron.org.uk/forum/index.php?topic=12604.msg151750#msg151750 Quelle]). Version 3.1p0 von owfs lässt sich derzeit für den Raspberry Pi mit USB-Unterstützung nur kompilieren, wenn man einiges in den Make-Files patcht, wie [https://www.mail-archive.com/owfs-developers@lists.sourceforge.net/msg11484.html hier] beschrieben.

Eine ältere, kompilierte Version für den RaspberryPi kann hier heruntergeladen werden: [http://forum.fhem.de/index.php?action=dlattach;topic=12219.0;attach=2463 owfs_2.8p17-1_all.zip]

<nowiki>sudo apt-get install automake autoconf autotools-dev gcc g++ libtool libusb-dev fuse-utils libfuse-dev swig python-dev tcl-dev php5-dev
sudo apt-get install git git-buildpackage dh-make quilt php5-cli
git clone [git://git.debian.org/collab-maint/owfs.git git://git.debian.org/collab-maint/owfs.git] git
git-buildpackage -uc -us
cd ..
sudo dpkg -i ./owserver_2.8p7+cvs20110310-1_i386.deb ./libow-2.8-7_2.8p7+cvs20110310-1_i386.deb ./owfs-common_2.8p7+cvs20110310-1_all.deb
sudo dpkg -i ./owhttpd_2.8p7+cvs20110310-1_i386.deb</nowiki>
diese Pakete wurden alle gebaut:

<nowiki>libow-2.8-7_2.8p7+cvs20110310-1_i386.deb owfs-common_2.8p7+cvs20110310-1_all.deb
libowcapi-2.8-7_2.8p7+cvs20110310-1_i386.deb owfs-dbg_2.8p7+cvs20110310-1_i386.deb
libow-dev_2.8p7+cvs20110310-1_i386.deb owfs-doc_2.8p7+cvs20110310-1_all.deb
libownet-2.8-7_2.8p7+cvs20110310-1_i386.deb owfs-fuse_2.8p7+cvs20110310-1_i386.deb
libownet-dev_2.8p7+cvs20110310-1_i386.deb owftpd_2.8p7+cvs20110310-1_i386.deb
libownet-perl_2.8p7+cvs20110310-1_all.deb owhttpd_2.8p7+cvs20110310-1_i386.deb
libownet-php_2.8p7+cvs20110310-1_all.deb owserver_2.8p7+cvs20110310-1_i386.deb
libow-perl_2.8p7+cvs20110310-1_i386.deb ow-shell_2.8p7+cvs20110310-1_i386.deb
libow-php5_2.8p7+cvs20110310-1_i386.deb python-ow_2.8p7+cvs20110310-1_i386.deb
libow-tcl_2.8p7+cvs20110310-1_i386.deb python-ownet_2.8p7+cvs20110310-1_all.deb
owfs_2.8p7+cvs20110310-1_all.deb</nowiki>

3) In aktuellen Versionen von Raspbian sind die notwendigen Pakete für Version 2.8p15 schon in den konfigurierten Quellen vorhanden. Es reicht ein

<pre>sudo apt-get install owserver ow-shell owhttpd owftpd</pre>

===Unterstütze Geräte===
Eine aktuelle Liste der von OWDevice unterstützen Geräte findet man im [http://fhem.de/commandref.html#OWDevice FHEM-Commandref].

==Konfiguration von owserver==

Folgendes ist eine beispielhafte Konfiguration für OWFS mit einem am USB-Port angeschlossenen [http://denkovi.com/usb-to-one-wire-interface-adaptor-converter-thermometer Denkovi-Adapter] (Klon von DS9097U).

Es ist praktisch, dem Adapter ein festes Device zuzuordnen. Dazu legt man in /etc/udev/rules.d/ eine Datei 11-onewire.rules mit folgendem Inhalt an:

<nowiki>ATTRS{idVendor}=="0403", ATTRS{idProduct}=="6001", ATTRS{serial}=="DAE001nq", SUBSYSTEMS=="usb", ACTION=="add", MODE="0660", GROUP="plugdev", SYMLINK+="onewire"
</nowiki>

Nach dem Einstöpseln des USB-Kabels vom Adapter wird über die Seriennummer DAE001nq des USB-Wandlers auf dem Adapter das Gerät erkannt und der Symlink /dev/onewire auf das eigentliche USB-Gerät (z.B. /dev/ttyUSB1) erstellt.

Eine Minimalkonfiguration für /etc/owfs.conf ist

<pre>server: device = /dev/onewire
http: port = 2121
ftp: port = 2120
server: port = 4304
</pre>

Es ist sinnvoll, owhttpd installiert und laufen zu haben, um über die URL http://deinRaspberryPi:2121 zu sehen, dass owserver läuft und die Geräte am 1-wire-Bus erkennt.

==Konfiguration in FHEM==
Als erstes definiert man OWServer. Hiermit wird ein logischer OWServer definiert, auf welchem OWFS installiert ist

<nowiki>define <name> OWServer <protocol></nowiki>
<protocol> hat das Format <hostname>:<port>.

zBsp:

<nowiki>define myOWServer OWServer 192.168.14.100:4304</nowiki>
oder wenn sich OWFS auf dem gleichen Server befindet wie FHEM:

<nowiki>define myOWServer OWServer localhost:4304</nowiki>
Nach erfolgreichem "define" ist ein Klick auf den "Save" Button notwenig. Wenn nun der Status von myOWServer auf "Initialized" steht, ist der Server verbunden. Um sicher zu sein, dass der OWServer funktioniert, kann eine manuelle Abfrage der Device durchgeführt werden mit:

<nowiki>get myOWServer devices</nowiki>
Danach werden sämtliche angeschlossene Geräte angezeigt, inkl. Busmaster

===OWServer Set Befehle===
<nowiki>set <name> <value>
value:
timeout/directory
timeout/ftp
timeout/ha7
timeout/network
timeout/presence
timeout/serial
timeout/server
timeout/stable
timeout/uncached
timeout/usb
timeout/volatile
timeout/w1
units/pressure_scale
units/temperature_scale</nowiki>
Weitere Informationen zu den Set Befehlen sind im [http://owfs.org/uploads/owserver.1.html#sect41 OWServer Manual] zu entnehmen.

===OWServer Get Befehle===
<nowiki>get <name> <value>
value:
/settings/timeout/directory
/settings/timeout/ftp
/settings/timeout/ha7
/settings/timeout/network
/settings/timeout/presence
/settings/timeout/serial
/settings/timeout/server
/settings/timeout/stable
/settings/timeout/uncached
/settings/timeout/usb
/settings/timeout/volatile
/settings/timeout/w1
/settings/units/pressure_scale
/settings/units/temperature_scale</nowiki>
Zusätzlich stehen die FHEM-internen Befehle "errors" und "devices" zur Verfügung.
zBsp:

<nowiki>get <Devicename> errors #listet die Fehler des Device auf
get <Devicename> devices #scan den Server nach Device</nowiki>

===Angeschlossene Geräte auslesen===
Grundsätzlich werden die am Busmaster von OWFS angeschlossenen 1-Wire Geräte durch aktives autocreate nach einem Neustart (erfordert shutdown restart) selber in FHEM definiert.
Der Busmaster (zBsp ein DS9490r) selbst wird ebenfalls eingelesen und angezeigt.

===Definition von Geräten===
Es ist auch möglich, Geräte manuell anzulegen. Dies erfolgt in folgendem Format:

<nowiki>define <name> OWDevice <address> [<interval>]</nowiki>
zBsp:

<nowiki>define Vorlauftemp OWDevice 28.334F2B040000 60</nowiki>
Wobei der Wert 60 als Abfrageintervall in Sekunden zu verstehen ist.

===OWDevice State===
Bei Temperaturfühler wie DS18S20 wird das Reading "state" wie folgt ausgegeben:

<nowiki>temperature: 56.1875 alarm: 1</nowiki>
Um die Temperatur wie bei anderen Temperatur-Sensoren (zBsp. CUL_WS) anzuzeigen, hilft das Attribut "stateFormat". Dies kann wie folgt definiert werden:

<nowiki>attr <Devicename> stateFormat T: <wert></nowiki>
zBsp:

<nowiki>attr Boiler stateFormat T: temperature</nowiki>
alternativ

<nowiki>attr <Devicename> stateFormat {sprintf("%.1f",ReadingsVal("<Devicename>","temperature",0))."°C"}</nowiki>
Zusätzlich rundet das obenstehende Attribut mit "%.1f" die Temperatur auf eine Kommastelle.

==Tipps und Tricks==
1-wire-Geräte sind häufig generische Geräte, wie Zähler und Spannungsmesser (A/D-Wandler), an denen Sensorik hängt. Die rohen Werte vom 1-wire-Gerät (Zählimpulse, Spannungen) sind dann noch in menschenlesbare Werte zu verwandeln. Hier helfen userReadings, z.B.

<nowiki>attr myEnergyMeter userReadings energy { (ReadingsVal("myEnergyMeter","count.A",0)+AttrVal("myEnergyMeter","myBasis",0))/1250.0;; }</nowiki>

==Anwendungsbeispiele==
[[Stromzähler_und_1-Wire,_OWServer,_OWDevice|Hier]] findet man ein Beispiel einer Anbindung zweier Leistungsmesser (aka Stromzähler) mit S0 Ausgang über einen 1-wire-S0-Zähler an FHEM.

== Bekannte Probleme ==
=== Fhem hängt, wenn OWServer nicht erreichbar ist ===
Am Anfang gab es mit OWServer das Problem, dass Fhem immer komplett hing, wenn OWServer nicht erreichbar war (siehe z. B. [http://www.fischer-net.de/hausautomation/haustechnik/1-wire/60-1-wire-integration-in-fhem.html hier am Ende]). Das Problem wurde inzwischen dankenswerterweise für den laufenden Betrieb {{Link2Forum|Topic=16945|LinkText=behoben}} - <code>attr myOWServer nonblocking 1</code> muss dazu gesetzt werden -, aber zumindest beim Start hängt Fhem nach wie vor, wenn OWServer nicht erreichbar ist.

[[Kategorie:1-Wire]]

Pushbullet

2015-05-04T12:07:35Z

Motivierte linke Hände: Lösungshinweis zu "Cannot load module Pushbullet" ergänzt

'''Pushbullet''' ist ein Dienst, um Benachrichtigungen an unterschiedliche Endgeräte zu senden. Pushbullet stellt Apps für iPhone, Android, Windows (Beta), Mac OS X (bald erhältlich) sowie Plugins für Chrome und Firefox an. Eine genaue Liste kann [http://www.pushbullet.com/apps hier] eingesehen werden. Der Dienst sowie die Apps sind kostenlos.
{{Infobox Modul
|ModPurpose=Senden von Push-Nachrichten an unterschiedliche Endgeräte
|ModType=d
|ModForumArea=Unterstützende Dienste
|ModTechName=70_Pushbullet.pm
|ModOwner=fhainz
}}

==Installation==

Zur Benutzung von Pushbullet ist ein Google Account zwingend notwenig. Falls noch kein Google Account vorhanden ist kann man diesen [https://accounts.google.com/SignUp hier einrichten]. Anschließend kann man sich auf [http://pushbullet.com pushbullet.com] mit den Google Benutzerdaten einloggen. Den benötigten accessToken findet man in den Account Settings (rechts oben auf das Benutzer-Symbol klicken).
Auf dem gewünschten Endgerät muss nur noch der entsprechende Client installiert werden.

===Offizielle Clients===

'''Smartphones'''
*iOS: [https://www.pushbullet.com/apps Pushbullet App]
*Android: [https://www.pushbullet.com/apps Pushbullet App]

'''Browser-Erweiterungen'''
*Firefox: [https://www.pushbullet.com/apps Pushbullet Plugin]
*Chrome: [https://www.pushbullet.com/apps Pushbullet Plugin]
*Opera: [https://www.pushbullet.com/apps Pushbullet Plugin]
*Safari: [https://www.pushbullet.com/apps Pushbullet Plugin]

'''Betriebssystem-Erweiterungen'''
*Windows: [https://www.pushbullet.com/apps Pushbullet App]
*Mac OS X: [https://www.pushbullet.com/apps Pushbullet App]

===Clients durch die Community===
*Blackberry: [https://www.pushbullet.com/apps BlackBullet]
*Windows Phone: [https://www.pushbullet.com/apps PushPin]
*Ubuntu: [https://www.pushbullet.com/apps PB Indicator]

Übersicht aller Clients: [https://www.pushbullet.com/apps]

==Einbinden des Dienstes in Fhem==

Das Modul wird mit dem folgenden Befehl in fhem definiert:

define <name> Pushbullet <accessToken>

==Push Benachrichtigung senden==

===Nachricht===

Nachricht ohne Titel oder Gerät:
set <name> message Das ist eine Nachricht

Nachricht mit Titel ohne Gerät:
set <name> message Das ist eine Nachricht | Ein Titel

Nachricht mit Titel an Gerät iPhone:
set <name> message Das ist eine Nachricht | Ein Titel | iPhone

Nachricht mit Titel an Kontakt Max Mustermann
set <name> message Das ist eine Nachricht | Ein Titel | Max Mustermann

Wenn kein Titel angegeben wird tritt das Attribut defaultTitel in Kraft. Falls dies nicht gesetzt ist wird der Titel auf FHEM gesetzt.
Wenn kein Device angeben wird tritt das Attribut defaultDevice in Kraft. Falls dies nicht gesetzt ist geht der Push an alle '''deine''' Devices. Kontakte erhalten die Benachrichtigung '''nicht!'''

===Link===
Der Inhalt des Links wird in der App direkt angezeigt. Ein Webcam Foto kann somit mit einem Touch direkt am Endgerät angezeigt werden.

Link ohne Titel oder Gerät:
set <name> link http://google.com

Link mit Titel ohne Gerät:
set <name> link http://google.com | Google

Link mit Titel an Gerät iPhone
set <name> link http://google.com | Google | iPhone

Link mit Titel an Kontakt Max Mustermann
set <name> link http://google.com | Google | MaxMustermann

*Wenn kein Titel angegeben wird tritt das Attribut defaultTitel in Kraft. Falls dies nicht gesetzt ist wird der Titel auf FHEM gesetzt.
*Wenn kein Device angeben wird tritt das Attribut defaultDevice in Kraft. Falls dies nicht gesetzt ist geht der Push an alle '''deine''' Devices. Kontakte erhalten die Benachrichtigung '''nicht!'''

===Liste===

Liste ohne Titel oder Gerät:
set <name> list Milch, Brot, Zucker

Liste mit Titel ohne Gerät:
set <name> list Milch, Brot, Zucker | Einkaufsliste

Liste mit Titel an Gerät iPhone
set <name> list Milch, Brot, Zucker | Einkaufsliste | iPhone

Liste mit Titel an Kontakt Max Mustermann
set <name> list Milch, Brot, Zucker | Einkaufsliste | MaxMustermann

*Wenn kein Titel angegeben wird tritt das Attribut defaultTitel in Kraft. Falls dies nicht gesetzt ist wird der Titel auf FHEM gesetzt.
*Wenn kein Device angeben wird tritt das Attribut defaultDevice in Kraft. Falls dies nicht gesetzt ist geht der Push an alle '''deine''' Devices. Kontakte erhalten die Benachrichtigung '''nicht!'''

==Kontakt hinzufügen==
Mit
set <name> contactAdd <Name> | <email>
wird eine neuer Kontakt hinzugefügt. Dieser bekommt erstmal eine E-Mail mit einer Einladung zur Pushbullet App. Fall die App nicht installiert wird, bekommt der Kontakt Push-Benachrichtigungen als E-Mail zugestellt.

==Gerät / Kontakt umbenennen==
Mit
set <name> deviceRename <alterName> | <neuerName>
wird ein Gerät oder Kontakt umbenannt.

==Gerät / Kontakt löschen==
Mit
set <name> deviceDelete <name>
wird ein Gerät oder Kontakt gelöscht.

==Geräte / Kontakte neu einlesen==
Mit
get <name> devices
kann man die Device Liste von pushbullet.com neu einlesen.

==Pushbullet Website==
Die Pushbullet Website bietet umfangreiche Möglichkeiten die gesendeten Push Nachrichten, Geräte und Kontakte zu verwalten. Weiters kann man auch Nachrichten versenden und löschen.

==Bekannte Probleme==
===Cannot load module Pushbullet===

Bei einigen Installationen kommt es beim Start zu folgender Fehlermeldung:

<pre>Error messages while initializing FHEM:
configfile: Cannot load module Pushbullet
Cannot load module Pushbullet</pre>

Abhilfe schafft in der Regel, JSON zu installieren. Zum Beispiel auf dem Raspberry:

<pre>sudo apt-get install libjson-perl</pre>

==Links==
*Thread über das Modul im [http://forum.fhem.de/index.php/topic,29796.0.html FHEM-Forum]
*Pushbullet [https://www.pushbullet.com/apps Apps]
*Pushbullet [https://docs.pushbullet.com API]
*Homepage: [http://pushbullet.com pushbullet.com]

[[Kategorie: Code Snippets]]

OWServer & OWDevice

2015-05-04T08:34:20Z

Motivierte linke Hände: Ergänzung nonblocking

==Einleitung==

Bei OWServer handelt es sich um eine 1-Wire Server Komponente und bei OWDevice um eine Geräte-Komponente, die die angeschlossenen Module definiert-
Die Module benötigen die Serverkomponente von [http://www.owfs.org OWFS].

'''Wichtig:'''

Die Module sind eine eigenständige Möglichkeit, den 1-Wire Bus anzusteuern und kommen ohne die Module aus, deren Namen aus Großbuchstaben bestehen (wie OWX, OWSWITCH, OWTHERM, etc.).
Umgekehrt können die Module OWSWITCH, OWTHERM, etc. auch mit dem Backendmodul OWServer zusammenarbeiten, siehe dazu die commandref der betreffenden Module.

==Vorbereitung==

Wie oben erwähnt, setzt OWServer/OWDevice auf OWFS auf. Dazu ist eine funktionierende OWFS Installation notwendig. Die Installation ist auf der selben Plattform (Debian-based) möglich oder auch Remote (zBsp Dockstar oder RPi). Eine gute [http://owfs.org/index.php?page=standard-devices Liste der Standard Devices]auf der Homepage von OWFS einzusehen. Nicht alle Standard Devices sind in OWDevice verfügbar (siehe unten).Wenn OWFS funktioniert kann's weiter gehen...

===owfs Pakete installieren===

1) entweder sind die Pakete bereits vorpaketiert und man muss nur das [http://owfs.davromaniak.eu/ Repository] noch in /etc/apt/sources.list eintragen

2) oder man muss selber kompilieren ([http://www.navitron.org.uk/forum/index.php?topic=12604.msg151750#msg151750 Quelle]).
Für den RaspberryPi wurde dies schon durchgeführt: [http://forum.fhem.de/index.php?action=dlattach;topic=12219.0;attach=2463 owfs_2.8p17-1_all.zip]

<nowiki>sudo apt-get install automake autoconf autotools-dev gcc g++ libtool libusb-dev fuse-utils libfuse-dev swig python-dev tcl-dev php5-dev
sudo apt-get install git git-buildpackage dh-make quilt php5-cli
git clone [git://git.debian.org/collab-maint/owfs.git git://git.debian.org/collab-maint/owfs.git] git
git-buildpackage -uc -us
cd ..
sudo dpkg -i ./owserver_2.8p7+cvs20110310-1_i386.deb ./libow-2.8-7_2.8p7+cvs20110310-1_i386.deb ./owfs-common_2.8p7+cvs20110310-1_all.deb
sudo dpkg -i ./owhttpd_2.8p7+cvs20110310-1_i386.deb</nowiki>
diese Pakete werden alle gebaut:

<nowiki>libow-2.8-7_2.8p7+cvs20110310-1_i386.deb owfs-common_2.8p7+cvs20110310-1_all.deb
libowcapi-2.8-7_2.8p7+cvs20110310-1_i386.deb owfs-dbg_2.8p7+cvs20110310-1_i386.deb
libow-dev_2.8p7+cvs20110310-1_i386.deb owfs-doc_2.8p7+cvs20110310-1_all.deb
libownet-2.8-7_2.8p7+cvs20110310-1_i386.deb owfs-fuse_2.8p7+cvs20110310-1_i386.deb
libownet-dev_2.8p7+cvs20110310-1_i386.deb owftpd_2.8p7+cvs20110310-1_i386.deb
libownet-perl_2.8p7+cvs20110310-1_all.deb owhttpd_2.8p7+cvs20110310-1_i386.deb
libownet-php_2.8p7+cvs20110310-1_all.deb owserver_2.8p7+cvs20110310-1_i386.deb
libow-perl_2.8p7+cvs20110310-1_i386.deb ow-shell_2.8p7+cvs20110310-1_i386.deb
libow-php5_2.8p7+cvs20110310-1_i386.deb python-ow_2.8p7+cvs20110310-1_i386.deb
libow-tcl_2.8p7+cvs20110310-1_i386.deb python-ownet_2.8p7+cvs20110310-1_all.deb
owfs_2.8p7+cvs20110310-1_all.deb</nowiki>

3) In aktuellen Versionen von Raspbian sind die notwendigen Pakete schon in den konfigurierten Quellen vorhanden. Es reicht ein

<pre>sudo apt-get install owserver ow-shell owhttpd owftpd</pre>

===Unterstütze Geräte===
Eine aktuelle Liste der von OWDevice unterstützen Geräte findet man im [http://fhem.de/commandref.html#OWDevice FHEM-Commandref].

==Konfiguration in FHEM==
Als erstes definiert man OWServer. Hiermit wird ein logischer OWServer definiert, auf welchem OWFS installiert ist

<nowiki>define <name> OWServer <protocol></nowiki>
<protocol> hat das Format <hostname>:<port>.

zBsp:

<nowiki>define myOWServer OWServer 192.168.14.100:4304</nowiki>
oder wenn sich OWFS auf dem gleichen Server befindet wie FHEM:

<nowiki>define myOWServer OWServer localhost:4304</nowiki>
Nach erfolgreichem "define" ist ein Klick auf den "Save" Button notwenig. Wenn nun der Status von myOWServer auf "Initialized" steht, ist der Server verbunden. Um sicher zu sein, dass der OWServer funktioniert, kann eine manuelle Abfrage der Device durchgeführt werden mit:

<nowiki>get myOWServer devices</nowiki>
Danach werden sämtliche angeschlossene Geräte angezeigt, inkl. Busmaster

===OWServer Set Befehle===
<nowiki>set <name> <value>
value:
timeout/directory
timeout/ftp
timeout/ha7
timeout/network
timeout/presence
timeout/serial
timeout/server
timeout/stable
timeout/uncached
timeout/usb
timeout/volatile
timeout/w1
units/pressure_scale
units/temperature_scale</nowiki>
Weitere Informationen zu den Set Befehlen sind im [http://owfs.org/uploads/owserver.1.html#sect41 OWServer Manual] zu entnehmen.

===OWServer Get Befehle===
<nowiki>get <name> <value>
value:
/settings/timeout/directory
/settings/timeout/ftp
/settings/timeout/ha7
/settings/timeout/network
/settings/timeout/presence
/settings/timeout/serial
/settings/timeout/server
/settings/timeout/stable
/settings/timeout/uncached
/settings/timeout/usb
/settings/timeout/volatile
/settings/timeout/w1
/settings/units/pressure_scale
/settings/units/temperature_scale</nowiki>
Zusätzlich stehen die FHEM-internen Befehle "errors" und "devices" zur Verfügung.
zBsp:

<nowiki>get <Devicename> errors #listet die Fehler des Device auf
get <Devicename> devices #scan den Server nach Device</nowiki>

===Angeschlossene Geräte auslesen===
Grundsätzlich werden die am Busmaster von OWFS angeschlossenen 1-Wire Geräte durch aktives autocreate nach einem Neustart (erfordert shutdown restart) selber in FHEM definiert.
Der Busmaster (zBsp ein DS9490r) selbst wird ebenfalls eingelesen und angezeigt.

===Definition von Geräten===
Es ist auch möglich, Geräte manuell anzulegen. Dies erfolgt in folgendem Format:

<nowiki>define <name> OWDevice <address> [<interval>]</nowiki>
zBsp:

<nowiki>define Vorlauftemp OWDevice 28.334F2B040000 60</nowiki>
Wobei der Wert 60 als Abfrageintervall in Sekunden zu verstehen ist.

===OWDevice State===
Bei Temperaturfühler wie DS18S20 wird das Reading "state" wie folgt ausgegeben:

<nowiki>temperature: 56.1875 alarm: 1</nowiki>
Um die Temperatur wie bei anderen Temperatur-Sensoren (zBsp. CUL_WS) anzuzeigen, hilft das Attribut "stateFormat". Dies kann wie folgt definiert werden:

<nowiki>attr <Devicename> stateFormat T: <wert></nowiki>
zBsp:

<nowiki>attr Boiler stateFormat T: temperature</nowiki>
alternativ

<nowiki>attr <Devicename> stateFormat {sprintf("%.1f",ReadingsVal("<Devicename>","temperature",0))."°C"}</nowiki>
Zusätzlich rundet das obenstehende Attribut mit "%.1f" die Temperatur auf eine Kommastelle.

==Tipps und Tricks==
1-wire-Geräte sind häufig generische Geräte, wie Zähler und Spannungsmesser (A/D-Wandler), an denen Sensorik hängt. Die rohen Werte vom 1-wire-Gerät (Zählimpulse, Spannungen) sind dann noch in menschenlesbare Werte zu verwandeln. Hier helfen userReadings, z.B.

<nowiki>attr myEnergyMeter userReadings energy { (ReadingsVal("myEnergyMeter","count.A",0)+AttrVal("myEnergyMeter","myBasis",0))/1250.0;; }</nowiki>

==Anwendungsbeispiele==
[[Stromzähler_und_1-Wire,_OWServer,_OWDevice|Hier]] findet man ein Beispiel einer Anbindung zweier Leistungsmesser (aka Stromzähler) mit S0 Ausgang über einen 1-wire-S0-Zähler an FHEM.

== Bekannte Probleme ==
=== Fhem hängt, wenn OWServer nicht erreichbar ist ===
Am Anfang gab es mit OWServer das Problem, dass Fhem immer komplett hing, wenn OWServer nicht erreichbar war (siehe z. B. [http://www.fischer-net.de/hausautomation/haustechnik/1-wire/60-1-wire-integration-in-fhem.html hier am Ende]). Das Problem wurde inzwischen dankenswerterweise für den laufenden Betrieb {{Link2Forum|Topic=16945|LinkText=behoben}} - <code>attr myOWServer nonblocking 1</code> muss dazu gesetzt werden -, aber zumindest beim Start hängt Fhem nach wie vor, wenn OWServer nicht erreichbar ist.

[[Kategorie:1-Wire]]

OWServer & OWDevice

2015-05-03T08:06:52Z

Motivierte linke Hände: Hinweis auf FHEM Hänger, wenn owserver nicht erreichbar ist, aufgenommen.

==Einleitung==

Bei OWServer handelt es sich um eine 1-Wire Server Komponente und bei OWDevice um eine Geräte-Komponente, die die angeschlossenen Module definiert-
Die Module benötigen die Serverkomponente von [http://www.owfs.org OWFS].

'''Wichtig:'''

Die Module sind eine eigenständige Möglichkeit, den 1-Wire Bus anzusteuern und kommen ohne die Module aus, deren Namen aus Großbuchstaben bestehen (wie OWX, OWSWITCH, OWTHERM, etc.).
Umgekehrt können die Module OWSWITCH, OWTHERM, etc. auch mit dem Backendmodul OWServer zusammenarbeiten, siehe dazu die commandref der betreffenden Module.

==Vorbereitung==

Wie oben erwähnt, setzt OWServer/OWDevice auf OWFS auf. Dazu ist eine funktionierende OWFS Installation notwendig. Die Installation ist auf der selben Plattform (Debian-based) möglich oder auch Remote (zBsp Dockstar oder RPi). Eine gute [http://owfs.org/index.php?page=standard-devices Liste der Standard Devices]auf der Homepage von OWFS einzusehen. Nicht alle Standard Devices sind in OWDevice verfügbar (siehe unten).Wenn OWFS funktioniert kann's weiter gehen...

===owfs Pakete installieren===

1) entweder sind die Pakete bereits vorpaketiert und man muss nur das [http://owfs.davromaniak.eu/ Repository] noch in /etc/apt/sources.list eintragen

2) oder man muss selber kompilieren ([http://www.navitron.org.uk/forum/index.php?topic=12604.msg151750#msg151750 Quelle]).
Für den RaspberryPi wurde dies schon durchgeführt: [http://forum.fhem.de/index.php?action=dlattach;topic=12219.0;attach=2463 owfs_2.8p17-1_all.zip]

<nowiki>sudo apt-get install automake autoconf autotools-dev gcc g++ libtool libusb-dev fuse-utils libfuse-dev swig python-dev tcl-dev php5-dev
sudo apt-get install git git-buildpackage dh-make quilt php5-cli
git clone [git://git.debian.org/collab-maint/owfs.git git://git.debian.org/collab-maint/owfs.git] git
git-buildpackage -uc -us
cd ..
sudo dpkg -i ./owserver_2.8p7+cvs20110310-1_i386.deb ./libow-2.8-7_2.8p7+cvs20110310-1_i386.deb ./owfs-common_2.8p7+cvs20110310-1_all.deb
sudo dpkg -i ./owhttpd_2.8p7+cvs20110310-1_i386.deb</nowiki>
diese Pakete werden alle gebaut:

<nowiki>libow-2.8-7_2.8p7+cvs20110310-1_i386.deb owfs-common_2.8p7+cvs20110310-1_all.deb
libowcapi-2.8-7_2.8p7+cvs20110310-1_i386.deb owfs-dbg_2.8p7+cvs20110310-1_i386.deb
libow-dev_2.8p7+cvs20110310-1_i386.deb owfs-doc_2.8p7+cvs20110310-1_all.deb
libownet-2.8-7_2.8p7+cvs20110310-1_i386.deb owfs-fuse_2.8p7+cvs20110310-1_i386.deb
libownet-dev_2.8p7+cvs20110310-1_i386.deb owftpd_2.8p7+cvs20110310-1_i386.deb
libownet-perl_2.8p7+cvs20110310-1_all.deb owhttpd_2.8p7+cvs20110310-1_i386.deb
libownet-php_2.8p7+cvs20110310-1_all.deb owserver_2.8p7+cvs20110310-1_i386.deb
libow-perl_2.8p7+cvs20110310-1_i386.deb ow-shell_2.8p7+cvs20110310-1_i386.deb
libow-php5_2.8p7+cvs20110310-1_i386.deb python-ow_2.8p7+cvs20110310-1_i386.deb
libow-tcl_2.8p7+cvs20110310-1_i386.deb python-ownet_2.8p7+cvs20110310-1_all.deb
owfs_2.8p7+cvs20110310-1_all.deb</nowiki>

3) In aktuellen Versionen von Raspbian sind die notwendigen Pakete schon in den konfigurierten Quellen vorhanden. Es reicht ein

<pre>sudo apt-get install owserver ow-shell owhttpd owftpd</pre>

===Unterstütze Geräte===
Eine aktuelle Liste der von OWDevice unterstützen Geräte findet man im [http://fhem.de/commandref.html#OWDevice FHEM-Commandref].

==Konfiguration in FHEM==
Als erstes definiert man OWServer. Hiermit wird ein logischer OWServer definiert, auf welchem OWFS installiert ist

<nowiki>define <name> OWServer <protocol></nowiki>
<protocol> hat das Format <hostname>:<port>.

zBsp:

<nowiki>define myOWServer OWServer 192.168.14.100:4304</nowiki>
oder wenn sich OWFS auf dem gleichen Server befindet wie FHEM:

<nowiki>define myOWServer OWServer localhost:4304</nowiki>
Nach erfolgreichem "define" ist ein Klick auf den "Save" Button notwenig. Wenn nun der Status von myOWServer auf "Initialized" steht, ist der Server verbunden. Um sicher zu sein, dass der OWServer funktioniert, kann eine manuelle Abfrage der Device durchgeführt werden mit:

<nowiki>get myOWServer devices</nowiki>
Danach werden sämtliche angeschlossene Geräte angezeigt, inkl. Busmaster

===OWServer Set Befehle===
<nowiki>set <name> <value>
value:
timeout/directory
timeout/ftp
timeout/ha7
timeout/network
timeout/presence
timeout/serial
timeout/server
timeout/stable
timeout/uncached
timeout/usb
timeout/volatile
timeout/w1
units/pressure_scale
units/temperature_scale</nowiki>
Weitere Informationen zu den Set Befehlen sind im [http://owfs.org/uploads/owserver.1.html#sect41 OWServer Manual] zu entnehmen.

===OWServer Get Befehle===
<nowiki>get <name> <value>
value:
/settings/timeout/directory
/settings/timeout/ftp
/settings/timeout/ha7
/settings/timeout/network
/settings/timeout/presence
/settings/timeout/serial
/settings/timeout/server
/settings/timeout/stable
/settings/timeout/uncached
/settings/timeout/usb
/settings/timeout/volatile
/settings/timeout/w1
/settings/units/pressure_scale
/settings/units/temperature_scale</nowiki>
Zusätzlich stehen die FHEM-internen Befehle "errors" und "devices" zur Verfügung.
zBsp:

<nowiki>get <Devicename> errors #listet die Fehler des Device auf
get <Devicename> devices #scan den Server nach Device</nowiki>

===Angeschlossene Geräte auslesen===
Grundsätzlich werden die am Busmaster von OWFS angeschlossenen 1-Wire Geräte durch aktives autocreate nach einem Neustart (erfordert shutdown restart) selber in FHEM definiert.
Der Busmaster (zBsp ein DS9490r) selbst wird ebenfalls eingelesen und angezeigt.

===Definition von Geräten===
Es ist auch möglich, Geräte manuell anzulegen. Dies erfolgt in folgendem Format:

<nowiki>define <name> OWDevice <address> [<interval>]</nowiki>
zBsp:

<nowiki>define Vorlauftemp OWDevice 28.334F2B040000 60</nowiki>
Wobei der Wert 60 als Abfrageintervall in Sekunden zu verstehen ist.

===OWDevice State===
Bei Temperaturfühler wie DS18S20 wird das Reading "state" wie folgt ausgegeben:

<nowiki>temperature: 56.1875 alarm: 1</nowiki>
Um die Temperatur wie bei anderen Temperatur-Sensoren (zBsp. CUL_WS) anzuzeigen, hilft das Attribut "stateFormat". Dies kann wie folgt definiert werden:

<nowiki>attr <Devicename> stateFormat T: <wert></nowiki>
zBsp:

<nowiki>attr Boiler stateFormat T: temperature</nowiki>
alternativ

<nowiki>attr <Devicename> stateFormat {sprintf("%.1f",ReadingsVal("<Devicename>","temperature",0))."°C"}</nowiki>
Zusätzlich rundet das obenstehende Attribut mit "%.1f" die Temperatur auf eine Kommastelle.

==Tipps und Tricks==
1-wire-Geräte sind häufig generische Geräte, wie Zähler und Spannungsmesser (A/D-Wandler), an denen Sensorik hängt. Die rohen Werte vom 1-wire-Gerät (Zählimpulse, Spannungen) sind dann noch in menschenlesbare Werte zu verwandeln. Hier helfen userReadings, z.B.

<nowiki>attr myEnergyMeter userReadings energy { (ReadingsVal("myEnergyMeter","count.A",0)+AttrVal("myEnergyMeter","myBasis",0))/1250.0;; }</nowiki>

==Anwendungsbeispiele==
[[Stromzähler_und_1-Wire,_OWServer,_OWDevice|Hier]] findet man ein Beispiel einer Anbindung zweier Leistungsmesser (aka Stromzähler) mit S0 Ausgang über einen 1-wire-S0-Zähler an FHEM.

== Bekannte Probleme ==

=== fhem hängt, wenn owserver nicht erreichbar ist ===

Am Anfang gab es mit OWServer das Problem, dass FHEM immer komplett hing, wenn owserver nicht erreichbar war (siehe z. B. [http://www.fischer-net.de/hausautomation/haustechnik/1-wire/60-1-wire-integration-in-fhem.html hier am Ende]. Das Problem wurde inzwischen dankenswerterweise für den laufenden Betrieb [http://forum.fhem.de/index.php/topic,16945.0.html behoben], aber zumindest beim Start hängt FHEM nach wie vor, wenn owserver nicht erreichbar ist.

[[Kategorie:1-Wire]]

1-Wire Busverlegung

2015-05-02T20:24:50Z

Motivierte linke Hände: Ein paar Ergänzungen

== Kabeltypen ==
Es kann eine Vielzahl von Kabeltypen verwendet werden.

Eine Abschirmung sollte möglichst immer vorhanden sein, ist aber nicht zwingend notwendig. Die Verwendung dieser Abschirmung als Nutzleitung ist eher ungünstig, sie sollte vielmehr einseitig (!) an Masse=GND angeschlossen sein.

Anforderungen an den Durchmesser der einzelnen Adern werden durch den Stromverbrauch der 1-Wire-Komponenten bestimmt. Hat man nur Temperatursensoren etc., reichen 0.6 mm vollständig aus, das Kabel könnte sogar noch dünner sein (z.B. um es unauffällig unter Tapeten zu verlegen). Wenn Aktoren, LEDs, oder sonstige echte Stromverbraucher auf dem Bus sitzen, sollten 0.8 mm Aderdurchmesser vorgesehen werden.

Die Frequenzen, die über diese Kabel transportiert werden müssen, liegen im niederfrequenten Bereich (Anstiegs- und Abfallzeit der Impulse bei ca. 20-30 Mikrosekunden). Abrupte Veränderungen des Kabeldurchmessers oder der Kabelart führen immer immer zu Sprüngen der Impedanz (Wellenwiderstand) und damit zur Reflexion, die sich in einer Verschlechterung der Impulsqualität bemerkbar macht. Es ist daher zu empfehlen, nicht zu viele solche Wechsel auf dem Weg zum Sensor/Aktor einzubauen.

*Für parasitär (d.h. aus der Datenleitung) versorgte Sensoren und Aktoren reichen 2 Adern = 1 Aderpaar vollständig aus (Datenleitung und Masse=GND)
*Für Sensoren und Aktoren mit echter Spannungsversorgung ist eine dritte Ader mit +5V vorzusehen. Wenn ein externes Netzteil verwendet wird, ist zu beachten, dass GND des Netzteils auch mit GND des Busmasters verbunden werden muss.
*Für größere Netze ist zu beachten, dass keine Sterntopologie entsteht: Zwei längere Kabel (d.h., länger als 3,5 m) an einem Busmaster erfordern dann, dass das eines der beiden Kabel als Hin- + Rückleitung ausgelegt wird, das erfordert dann also 4 Adern = 2 Aderpaare. Siehe hierzu den unten stehenden Abschnitt

=== Netzwerkkabel ===
Hierbei handelt es sich typischerweise um STP(Shielded Twisted Pair)-Kabel mit 8 Adern, 4x2x0.8mm bis zu 4x2x0.1mm für extra flache Kabel. Ein ''Twisted Pair'' weist über seine Länge eine einigermaßen homogene Impedanz auf, um diese nicht zu stören, sind zu kleine Biegeradien zu vermeiden
=== Brandmeldekabel ===
Dieses Kabel hat unterschiedliche Anzahl von Aderpaaren, z.B. 2x2x0.8mm, aber auch 2x3, 2x4 oder gar 2x5 Aderpaare; die äußere Farbe ist rot. Kosten ab 0,40 €/m.
=== EIB/KNX Buskabel ===
Dieses Kabel hat 4 Adern 2x2x0.8mm und ist mit einem Folienschirm geschirmt, die äußere Farbe ist meist grün. Kosten ab 0,40 €/m. Die 4. Ader kann entweder zur Datenrückleitung verwendet werden, oder eine weitere Spannung (z.B. 12 V) zu Aktoren (z.B. Relais) transportieren.
=== Geschirmtes Fernmeldekabel ===
Dieses Kabel hat 4 Adern 2x2x0.6mm und ist mit einem Folienschirm geschirmt, die äußere Farbe ist meist grau. Kosten ab 0,20 €/m. Die 4. Ader kann entweder zur Datenrückleitung verwendet werden, oder eine weitere Spannung (z.B. 12 V) zu Aktoren (z.B. Relais) transportieren.
=== Geschirmtes NF-Kabel ===
Auch als Mikrofonkabel verkauft, zwei Innenleiter in gemeinsamer Abschirmung. Diese wird dann als 3. Leiter verwendet. Das Kabel ist sehr flexibel und daher besonders für den mobilen Anschluss von Sensoren/Aktoren geeignet. Bewährt hat sich dies für kurze ''Stubs'' (max. 3.5 m), mit denen Sensoren/Aktoren an den Bus angeschlossen werden. Hierfür gibt es preisgünstige Kabelenden mit angegossenem 3.5 mm Klinkenstecker.

Auch kommerziell erhältliche Busmaster, wie der USB9097, haben solche Klinkenbuchsen. (Foto folgt)

=== Ungeschirmtes 3-adriges Kabel===
Prinzipiell auch geeignet, sorgt aber bei großen Leitungslängen für eine gewisse Störanfälligkeit. Bei Abzweigungen oder für kurze ''Stubs'' aber problemlos verwendbar.

Bei eBay sind preisgünstige 1-Wire Temperatursensoren in wasserdichtem Gehäuse erhältlich, die mit einem solchen Kabelende versehen sind.
===Belegung===
Es muss ausdrücklich betont werden, dass für die Belegung der Adern keine wie auch immer geartete Norm existiert. Die nachfolgenden Farbcodierungen sind lediglich Beispiele.
{| class="wikitable" style="text-align:center"
! Typ !! style="width:5em;"|GND Masse !! style="width:5em;"|VDD +5V !! style="width:5em;"|1-Wire Data !! style="width:5em;"|1-Wire Return !! Bemerkung / Vorgabe durch
|-
| Fernmeldekabel || style="color:white;background:#000000"|sw || style="color:white;background:red"|rt || style="background:yellow"|ge || style="background:white"|ws
|-
| Mikrofonkabel || style="background:white"|ws || style="color:white;background:#AAAAAA"|Schirm || style="color:white;background:red"|rt || style="color:white;background:grey"| -- || Busmaster USB9097
|-
| Ungeschirmtes 3-adriges Kabel || style="color:white;background:green"|gn || style="color:white;background:red"|rt || style="background:yellow"|ge || style="color:white;background:grey"| -- || Kommerzielle Sensoren
|-
| Netzwerkkabel || style="background:white"|blau-weiß orange-weiß || style="color:black;background:#FAB514"|orange || style="color:white;background:blue"|blau || style="color:white;background:grey"| n. def. || LinkUSB(i)
|}

== Verbindung verschiedener Kabeltypen ==
[[Datei:Connectionbox.jpg|mini|links|Connectionbox (geöffnet)]]
[[Datei:Connectionbox unten.jpg|mini|rechts|Connectionbox Platinenunterseite (paarweise Verbindung der Adern)]]
Gute Erfahrungen wurden gemacht mit ''CAT 5 Connection Boxes'' für Netzwerkkabel, die für ca. 1,50€ z.B. bei Reichelt erhältlich sind. Voraussetzung für die Verwendung ist allerdings der Besitz eines ''LSA-Anlegewerkzeuges'' (ca. 6 €). Da meist nur 4 Adern benötigt werden, können die insgesamt 8 Adern auf der Unterseite paarweise verbunden werden. Dafür sollte man möglichst den gleichen Aderdurchmesser verwenden, wie er in der Zu- und Ableitung auftritt.

 
==Topologie==
Maßgebliches Whitepaper für '''große Kabellängen''' ist das von Maxim herausgegebene Tutorial [http://pdfserv.maximintegrated.com/en/an/AN148.pdf Guidelines for Reliable Long 1-Wire Networks].

Die Kabellänge bis zum entferntesten Sensor kann bis zu 100 m betragen. Typischerweise werden die einzelnen 1-Wire-Komponenten an eine zentrale Busleitung über so genannte ''Stubs'' (kurze Kabelenden) angeschlossen, diese sollten nicht länger als 3.5 m sein. Die gleiche Beschränkung der Leitungslänge gilt, wenn alle 1-Wire Komponenten sternförmig zusammengeführt werden (Sterntopologie).

Bei Kabellängen von mehr als 3.5 m sollte immer eine lineare Topologie eingehalten werden (bis auf die ''Stubs''), gegebenenfalls ist die Datenleitung ('''nicht''' Masse und Stromversorgung) als Hin- und Rückleitung vorzusehen.
<gallery widths="250" caption="1-Wire Topologien" mode="packed">
1-wire_T1.png|Sterntopologie
1-wire_T2.png|Lineare Topologie
1-wire_T3.png|Lineare Topologie mit sternförmiger Anordnung einzelner Gruppen
</gallery>

==Pullup==
Maßgebliches Whitepaper für die Frage eines '''Pullup'''-Widerstandes, der bei gewissen Operationen den Datenbus mit mehr Strom versorgt, ist das von Maxim herausgegebene Tutorial [http://pdfserv.maximintegrated.com/en/an/AN4255.pdf How to Power the Extended Features of 1-Wire Devices].

== Links ==
* Informationen zum Aufbau des 1-Wire Bus [http://shop.wiregate.de/1-wire-bus]
* Weitere Informationen zum Aufbau des 1-Wire Bus [http://www.fuchs-shop.com/de/howto/linkfamily/]
[[Kategorie:1-Wire]]

OWServer & OWDevice

2015-05-02T08:26:45Z

Motivierte linke Hände: Installation auf dem Raspberry vereinfacht

==Einleitung==

Bei OWServer handelt es sich um eine 1-Wire Server Komponente und bei OWDevice um eine Geräte-Komponente, die die angeschlossenen Module definiert-
Die Module benötigen die Serverkomponente von [http://www.owfs.org OWFS].

'''Wichtig:'''

Die Module sind eine eigenständige Möglichkeit, den 1-Wire Bus anzusteuern und kommen ohne die Module aus, deren Namen aus Großbuchstaben bestehen (wie OWX, OWSWITCH, OWTHERM, etc.).
Umgekehrt können die Module OWSWITCH, OWTHERM, etc. auch mit dem Backendmodul OWServer zusammenarbeiten, siehe dazu die commandref der betreffenden Module.

==Vorbereitung==

Wie oben erwähnt, setzt OWServer/OWDevice auf OWFS auf. Dazu ist eine funktionierende OWFS Installation notwendig. Die Installation ist auf der selben Plattform (Debian-based) möglich oder auch Remote (zBsp Dockstar oder RPi). Eine gute [http://owfs.org/index.php?page=standard-devices Liste der Standard Devices]auf der Homepage von OWFS einzusehen. Nicht alle Standard Devices sind in OWDevice verfügbar (siehe unten).Wenn OWFS funktioniert kann's weiter gehen...

===owfs Pakete installieren===

1) entweder sind die Pakete bereits vorpaketiert und man muss nur das [http://owfs.davromaniak.eu/ Repository] noch in /etc/apt/sources.list eintragen

2) oder man muss selber kompilieren ([http://www.navitron.org.uk/forum/index.php?topic=12604.msg151750#msg151750 Quelle]).
Für den RaspberryPi wurde dies schon durchgeführt: [http://forum.fhem.de/index.php?action=dlattach;topic=12219.0;attach=2463 owfs_2.8p17-1_all.zip]

<nowiki>sudo apt-get install automake autoconf autotools-dev gcc g++ libtool libusb-dev fuse-utils libfuse-dev swig python-dev tcl-dev php5-dev
sudo apt-get install git git-buildpackage dh-make quilt php5-cli
git clone [git://git.debian.org/collab-maint/owfs.git git://git.debian.org/collab-maint/owfs.git] git
git-buildpackage -uc -us
cd ..
sudo dpkg -i ./owserver_2.8p7+cvs20110310-1_i386.deb ./libow-2.8-7_2.8p7+cvs20110310-1_i386.deb ./owfs-common_2.8p7+cvs20110310-1_all.deb
sudo dpkg -i ./owhttpd_2.8p7+cvs20110310-1_i386.deb</nowiki>
diese Pakete werden alle gebaut:

<nowiki>libow-2.8-7_2.8p7+cvs20110310-1_i386.deb owfs-common_2.8p7+cvs20110310-1_all.deb
libowcapi-2.8-7_2.8p7+cvs20110310-1_i386.deb owfs-dbg_2.8p7+cvs20110310-1_i386.deb
libow-dev_2.8p7+cvs20110310-1_i386.deb owfs-doc_2.8p7+cvs20110310-1_all.deb
libownet-2.8-7_2.8p7+cvs20110310-1_i386.deb owfs-fuse_2.8p7+cvs20110310-1_i386.deb
libownet-dev_2.8p7+cvs20110310-1_i386.deb owftpd_2.8p7+cvs20110310-1_i386.deb
libownet-perl_2.8p7+cvs20110310-1_all.deb owhttpd_2.8p7+cvs20110310-1_i386.deb
libownet-php_2.8p7+cvs20110310-1_all.deb owserver_2.8p7+cvs20110310-1_i386.deb
libow-perl_2.8p7+cvs20110310-1_i386.deb ow-shell_2.8p7+cvs20110310-1_i386.deb
libow-php5_2.8p7+cvs20110310-1_i386.deb python-ow_2.8p7+cvs20110310-1_i386.deb
libow-tcl_2.8p7+cvs20110310-1_i386.deb python-ownet_2.8p7+cvs20110310-1_all.deb
owfs_2.8p7+cvs20110310-1_all.deb</nowiki>

3) In aktuellen Versionen von Raspbian sind die notwendigen Pakete schon in den konfigurierten Quellen vorhanden. Es reicht ein

<pre>sudo apt-get install owserver ow-shell owhttpd owftpd</pre>

===Unterstütze Geräte===
Eine aktuelle Liste der von OWDevice unterstützen Geräte findet man im [http://fhem.de/commandref.html#OWDevice FHEM-Commandref].

==Konfiguration in FHEM==
Als erstes definiert man OWServer. Hiermit wird ein logischer OWServer definiert, auf welchem OWFS installiert ist

<nowiki>define <name> OWServer <protocol></nowiki>
<protocol> hat das Format <hostname>:<port>.

zBsp:

<nowiki>define myOWServer OWServer 192.168.14.100:4304</nowiki>
oder wenn sich OWFS auf dem gleichen Server befindet wie FHEM:

<nowiki>define myOWServer OWServer localhost:4304</nowiki>
Nach erfolgreichem "define" ist ein Klick auf den "Save" Button notwenig. Wenn nun der Status von myOWServer auf "Initialized" steht, ist der Server verbunden. Um sicher zu sein, dass der OWServer funktioniert, kann eine manuelle Abfrage der Device durchgeführt werden mit:

<nowiki>get myOWServer devices</nowiki>
Danach werden sämtliche angeschlossene Geräte angezeigt, inkl. Busmaster

===OWServer Set Befehle===
<nowiki>set <name> <value>
value:
timeout/directory
timeout/ftp
timeout/ha7
timeout/network
timeout/presence
timeout/serial
timeout/server
timeout/stable
timeout/uncached
timeout/usb
timeout/volatile
timeout/w1
units/pressure_scale
units/temperature_scale</nowiki>
Weitere Informationen zu den Set Befehlen sind im [http://owfs.org/uploads/owserver.1.html#sect41 OWServer Manual] zu entnehmen.

===OWServer Get Befehle===
<nowiki>get <name> <value>
value:
/settings/timeout/directory
/settings/timeout/ftp
/settings/timeout/ha7
/settings/timeout/network
/settings/timeout/presence
/settings/timeout/serial
/settings/timeout/server
/settings/timeout/stable
/settings/timeout/uncached
/settings/timeout/usb
/settings/timeout/volatile
/settings/timeout/w1
/settings/units/pressure_scale
/settings/units/temperature_scale</nowiki>
Zusätzlich stehen die FHEM-internen Befehle "errors" und "devices" zur Verfügung.
zBsp:

<nowiki>get <Devicename> errors #listet die Fehler des Device auf
get <Devicename> devices #scan den Server nach Device</nowiki>

===Angeschlossene Geräte auslesen===
Grundsätzlich werden die am Busmaster von OWFS angeschlossenen 1-Wire Geräte durch aktives autocreate nach einem Neustart (erfordert shutdown restart) selber in FHEM definiert.
Der Busmaster (zBsp ein DS9490r) selbst wird ebenfalls eingelesen und angezeigt.

===Definition von Geräten===
Es ist auch möglich, Geräte manuell anzulegen. Dies erfolgt in folgendem Format:

<nowiki>define <name> OWDevice <address> [<interval>]</nowiki>
zBsp:

<nowiki>define Vorlauftemp OWDevice 28.334F2B040000 60</nowiki>
Wobei der Wert 60 als Abfrageintervall in Sekunden zu verstehen ist.

===OWDevice State===
Bei Temperaturfühler wie DS18S20 wird das Reading "state" wie folgt ausgegeben:

<nowiki>temperature: 56.1875 alarm: 1</nowiki>
Um die Temperatur wie bei anderen Temperatur-Sensoren (zBsp. CUL_WS) anzuzeigen, hilft das Attribut "stateFormat". Dies kann wie folgt definiert werden:

<nowiki>attr <Devicename> stateFormat T: <wert></nowiki>
zBsp:

<nowiki>attr Boiler stateFormat T: temperature</nowiki>
alternativ

<nowiki>attr <Devicename> stateFormat {sprintf("%.1f",ReadingsVal("<Devicename>","temperature",0))."°C"}</nowiki>
Zusätzlich rundet das obenstehende Attribut mit "%.1f" die Temperatur auf eine Kommastelle.

==Tipps und Tricks==
1-wire-Geräte sind häufig generische Geräte, wie Zähler und Spannungsmesser (A/D-Wandler), an denen Sensorik hängt. Die rohen Werte vom 1-wire-Gerät (Zählimpulse, Spannungen) sind dann noch in menschenlesbare Werte zu verwandeln. Hier helfen userReadings, z.B.

<nowiki>attr myEnergyMeter userReadings energy { (ReadingsVal("myEnergyMeter","count.A",0)+AttrVal("myEnergyMeter","myBasis",0))/1250.0;; }</nowiki>

==Anwendungsbeispiele==
[[Stromzähler_und_1-Wire,_OWServer,_OWDevice|Hier]] findet man ein Beispiel einer Anbindung zweier Leistungsmesser (aka Stromzähler) mit S0 Ausgang über einen 1-wire-S0-Zähler an FHEM.

[[Kategorie:1-Wire]]