FHEMWiki - Benutzerbeiträge [de]

Trennung/Aufteilung von TCP/IP Netzen zur Erhöhung der Sicherheit

2019-04-10T06:01:20Z

Darkness: Überarbeitung und Ergänzung

{{Baustelle}}

In diesem Wiki-Artikel geht es um die Aufteilung/Einrichtung eines (W)LAN-Netztes mit 2 getrennten Adressbereichen sowie die Einrichtung von Subnetzen. Das hat Grundsätzlich nichts mit FHEM direkt zu tun, trägt aber zur Netzwekssicherheit bei.
Die Zielgruppe für diesen Artikel sind fortgeschrittene Anwedner, da umfangreiche Änderungen am Netzaufbau durchgeführt werden. Ebenso ist ein sicherer Umgang mit der CLI erforderlich.
Dies Beispiel bezieht sich auf eine Konkrete Ausgangslage mit einem Netzwerk, welches durch eine Fritzbox verwaltet wird. Sinngemäß sollte es sich aber auf andere Router (Speedport funktioniert nicht, da dort keine weitere Route für das lokale Netz eingetragen werden kann) übertragen lassen. FHEM läuft auf einen Raspberry Pi 3+ (zudem wird dieser auch als Pi-Hole verwendet).<br>
Ein ganz besonderer Dank geht an Wuppi68, der mir geduldig geholfen hat mein Netzwerk umzugestalten.
{{Hinweis|Dies ist keine Schritt-für-Schritt Anleitung. Der Artikel dient lediglich als Leitfaden. Die entsprechenden Einstellungen und Befehle sind auf die vorhandene Software anzupassen.
}}
== Ausgangslage ==
Das vorhandene Netzwerk besteht aus einer Fritzbox 7490 an der ein Klasse-C mit dem Adressbereich 192.168.178.0/24 angebunden ist. Die Geräte sind mittel WLAN und LAN angeschlossen.
== Ziel ==
Wie bereits eingangs erwähnt, wird es am Ende zwei Netzwerke geben.
Ein Gästenetzwerk mit der Adresse 192.168.178.0/24 sowie ein internes Netzwerk mit mehreren Subnetzen im Adressbereich 172.16.0.0/24.
Für das interne Routing wird zusätzliche Hardware benötigt. Ein Raspbarry Pi 3+ kann hardwarebeding schnell an die Grenzen kommen sollte dieser als Router eingesetzt werden.
Es wird empfohlen eine Sicherung Einstellungen des Routers und des Pis durchzuführen um jederzeit zur Ausgangslage zurück zu kehren!
== Motivation ==
In der heutigen Zeit kommunizieren eine Vielzahl von Geräten mittels (W)LAN. Wo anfangs nur ein Handy und ein Laptop waren sind heutzutage noch Sprachassistenten, Fernseher und besonders Geräte des IoTs dazu gekommen. Gerade in Hinblick auf Sicherheit sind dies Geräte besonders zu betrachten. Entweder werden diese Geräte mit fest eingestellten Nutzernamen/Passwörter ausgeliefert oder erkannte Sicherheitslücken werden nicht geschlossen. Dazu kommt noch eine Cloud-Verbindung bei der auch nicht überprüft werden kann, welche Daten übertragen werden.
Durch die Trennung der verschiedenen (Sub)Netze kann verhindert werden das u.a vertrauliche Daten ausgeleitet werden können oder aber der Zugriff auf das Internet komplett unterbunden wird
== DHCP anpassen ==
Bisher erfolgte die IP-Vergabe durch die Fritzbox. Zukünftig erfolgt die IP-Vergabe durch den Raspberry Pi (hier durch die Pi-Hole Software).
=== IP-Bereich ===
Im ersten Schritt wird der DHCP-Server so angepasst, dass zukünftig Adressen aus dem IP-Bereich 172.16.0.0/16 vergeben werden.
In diesem Fall aus dem Bereich 172.16.1.100 – 172.16.1.200.
Später erfolgt die weitere Unterteilung der 16er Netze in 24er Netze.
=== Aufteilung in Subnetze===
Über den DHCP-Server werden für bekannte Geräte statische Adressen vergeben. Dabei erfolgt eine weitere Aufteilung in Subnetze.
Später können diese 24er Netze durch Firewallregeln und VLAN-Tags entsprechende Zugrissrechte bekommen und voneinander abgegrenzt werden.
Als Beispiel für die Aufteilung
* 172.16.1.0 --> Default
* 172.16.2.0 --> Heimautomation
* 172.16.3.0 --> Media
* 172.16.4.0 --> Zocken
* ...
* 172.16.255.0 --> das letzte
Dadurch das als Subnetmaske die 255.255.0.0 (entspricht /16) gewählt wurde, sind die Geräte auch weiterhin noch untereinander erreichbar.
Die Fritzbox (der Router) bekommt die Adresse 172.16.1.1 mit der Netzmaske 255.255.0.0
Nach dieser Umstellung sollten alle Geräte wie gewohnt erreichbar sein.
=== FHEM-Anpassen===
Nach der IP-Umstellung empfiehlt es sich in FHEM alles Devices und Bedingungen anzupassen, welche auf alte IPs verweisen.
===Beobachten===
Sind alle Adressen umgestellt und FHEM entsprechend angepasst, sollte das Netzwerk jetzt ein wenig beobachtet werden. Läuft alles? Sind alle Geräte erreichbar? Gibt es ungewöhnliches Verhalten?
==Zwischenstand==
Wenn nach der Umstellung alles ohne Probleme läuft, hat das Netzt folgenden Zustand:
Router (FritzBox) 172.16.1.1
Raspberry PI (Pi-Hole,DNS) 172.16.1.2
Subnetze 172.16.1.0/16 – 172.16.255.0/16
Wenn alles läuft, kann mit dem Nächsten Schrift fortgefahren werden. Ansonsten ggf. noch Fehler korrigieren.
An dieser Stelle empfiehlt es sich ein Backup der Fritzbox und des Pis durchzuführen.
==Gastnetzt abtrennen==
Im nächsten Schritt erfolgt die Trennung zwischen dem internen Netz (172.16.0.0/16) und dem Gästenetz (192.168.178.0/24).
Ebenso bekommt der Pi eine Routingfunktion zwischen den beiden Netzen.
Sollzustand:
Fritzbox: 192.168.178.1
PiHole ETH0 172.16.1.1 und ETH0:0 192.168.178.2
=== Zusätzliche IP für Raspberry Pi ===
Da der Raspberry Pi das Routing zwischen dem internen- und Gästenetzt übernehmen soll, muss der Netzwerkkarte eine weitere IP zugewiesen werden (192.168.178.2)
=== DHCP anpassen ===
Der DHCP-Server des Pis soll zukünftig nur noch IPs aus dem Bereich 192.168.178.100 – 192.168.178.200 vergeben. Bekannte Geräte werden manuell in eine der internen Netze verschoben
=== Routing aktivieren ===
Damit der Raspberry Pi später auch Routing durchführen kann, muss dieses aktiviert werden. Bei ein Raspian Betriebssystem wird dies z.B. in /etc/sysctl.conf mittels net.ipv4.ip_forward = 1 aktiviert.
== Fritzbox und Pi anpassen ==
Im folgenden Schritt ist die Reihenfolge wichtig. Ggf. bietet es sich an, an den Pi Tastatur/Monitor anzuschließen. Alternativ kann die SD-Karte des Pis auch am PC gemountet werden, um Äderungen an den Konfigdateien anzupassen.
=== Routing an der Fritzbox ===
Auf der Fritzbox wird eine Route zum Raspberry Pi eingerichtet.
172.16.0.0/16 auf das Ziel 192.168.178.2
Damit wird das interne Netzt an den Pi weitergeroutet.
=== IP-Adresse Fritzbox anpassen ===
Die IP der Fritzbox wird auf 192.168.178.1 gesetzt. Nach dem Speichern ist die Fritzbox nicht mehr erreichbar, da noch keine Route aus dem 172.16.0.0/16 Netz zur Fritzbox besteht.
=== IP-Adresse des Pis anpassen ===
Im letzten Schritt wird die IP-Adresse der Netzwerkarte des Pis angepasst. Dazu erhält diese zwei IP-Adressen:
ETH0: 172.16.1.1
ETH0:0 192.168.178.2
Zusätzlich wird der Gateway für ETH0 auf die 192.168.178.1 gesetzt.
Nach einem anschließenden Reboot sollte das Netzt wieder wie gewohnt funktionieren.
Beim Problemen kann ggf. das Backup zurück gespielt werden.
=== Netze per IP-Tables trennen ===
Wenn der Reboot erfolgreich war und das Netz erreichbar ist, sollte jetzt folgender Zustand vorliegen:
Die Fritzbox arbeitet auf der IP 192.168.178.1 und Routet alles, was 172.16.0.0/24 ist an den Pi.
Der Pi hat die Adressen 172.16.1.1 und 192.168.178.2 und routet aus dem 172.16.0.0/24 zum Pi. Weitere Routingaufgaben sollten dem Pi nicht zugewiesen werden, da dieser sonst schnell an seine Leistungsgrenze kommt.
Alle unbekannten Geräte bekommen eine IP aus dem 192.168.178.0/24 Netz und müssen manuell in ein 172.16.0.0-Netz verschoben werden.
=== Trennen der Netze mittels Firewall ===
Um einen Zugriff des Gastnetzes auf das interne Netz zu verbieten, sind entsprechende Firewalleinträge zu erstellen.
==Zusammenfassung==
An dieser Stelle ist durch die Aufteilung in ein internes Netz und ein Gästenetz ein erster Schritt zur Absicherung erfolgt. Der Sicherheitsgewinn erfolgt aber erst, wenn diese beiden Netzt per Firewall auch voneinander getrennt sind.
Unbekannte Geräte werden mit einer IP aus dem Gästenetz versorg und erst nach einer manuellen Zuordnung ins interne Netz verschoben.

Trennung/Aufteilung von TCP/IP Netzen zur Erhöhung der Sicherheit

2019-04-01T12:05:43Z

Darkness:

Trennung/Aufteilung von TCP/IP Netzen zur Erhöhung der Sicherheit

2019-04-01T11:58:23Z

Darkness: Die Seite wurde neu angelegt: „{{Baustelle}} In diesem Wiki-Artikel geht es um die Aufteilung/Einrichtung eines (W)LAN-Netztes mit 2 getrennten Adressbereichen sowie die Einrichtung von Su…“

HomeConnect

2018-03-06T09:26:27Z

Darkness: Aufnahme des Thread über Stand der Freischaltungen

{{Infobox Modul
|ModPurpose=Anbindung von Hausgeräten mit Home Connect Schnittstelle
|ModType=d
|ModForumArea=Sonstige Systeme
|ModTechName=48_HomeConnectConnection.pm 48_HomeConnect.pm
|ModOwner=swhome
}}
==Übersicht==
Mit den beiden Modulen HomeConnectConnection und HomeConnect können in FHEM Devices für [http://www.home-connect.com/de/de/ Home Connect Hausgeräte] angelegt werden, die an einem Home Connect Account angemeldet sind. Mögliche Hausgeräte sind aktuell Backöfen, Spülmaschinen, Kühlschränke, Waschmaschinen, Wäschetrockner und Kaffeemaschinen der Marken Bosch, Siemens und Neff.

Wann verwendet man HomeConnectConnection, wann HomeConnect?

Das Modul HomeConnectConnection verwaltet die Verbindung zwischen FHEM und einem Home Connect Account. Es legt die HomeConnect Devices für die einzelnen Hausgeräte an.

==Aktueller Status des Moduls==
Die beiden Module befinden sich aktuell im Betatest. Jeder Tester muss sich bei Home Connect als Entwickler anmelden und freigeschaltet werden. Die Freischaltung kann entweder über eine persönliche Nachricht an swhome hier im Forum beantragt werden, oder man trägt sich in folgendes Thread ein: [https://forum.fhem.de/index.php/topic,81420.0.html/ Thread im Forum]

Was jeder auch ohne Freischaltung probieren kann ist der Hausgeräte-Simulator. Allerdings kann man damit in der Praxis nicht viel anfangen...

==Definition von FHEM Devices==
===Modul-Installation===
Zur Installation (oder zum Update) einfach diesen Befehl in der FHEM Kommandozeile eingeben:

<pre>
update all https://raw.githubusercontent.com/sw-home/FHEM-HomeConnect/master/controls_homeconnect.txt
</pre>

Danach FHEM neu starten.

Fehlermeldungen? Eventuell muss die Perl-Bibliothek libswitch-perl installiert werden.

Damit das Modul auch bei einem normale "update check" mit geprüft wird, muss folgendes ergänzt werden
<pre>
update add https://raw.githubusercontent.com/sw-home/FHEM-HomeConnect/master/controls_homeconnect.txt
</pre>

===Basisdefinition===
Um mit dem Simulator zu testen, braucht Ihr einen [https://developer.home-connect.com/ Entwickleraccount bei HomeConnect]

Man braucht zwingend einen Advanced Account um Geräte fernstarten zu dürfen. Das kostet nichts, es wird jedoch eine Namensverifikation durchgeführt.

Im Entwickleraccount muss eine Applikation generiert werden, als „Company Name“ im Home Connect Developer Portal bitte “FHEM Betatester“ angeben. Die wichtigste Einstellung der Applikation ist die Redirect URL. Diese URL muss den Host enthalten, den Ihr in Eurer Umgebung für den Zugriff auf FHEM verwendet, also localhost oder 192.168.x.y, und sie muss ein Kommando in dem definierten HomeConnectConnection Modul aufrufen. Die URL sieht dann z.B. so aus:

<pre>
http://localhost:8083/fhem?cmd.Test=set%20hcconn%20auth%20
</pre>

Die identische URL muss sowohl auf der Home Connect Seite in der Applikation angegeben werden, als auch bei der Definition in FHEM. Dazu kommt noch der generierte API Key:

<pre>
define hcconn HomeConnectConnection API-KEY REDIRECT-URL simulator
</pre>

Also zum Beispiel

<pre>
define hcconn HomeConnectConnection D239EBCABC99994D239EBCABC999B3D2393204
http://localhost:8083/fhem?cmd.Test=set%20hcconn%20auth%20 simulator
</pre>

Danach findet Ihr in dem neuen Device hcconn einen Link namens Home Connect Login. Diesen klicken und die Anmeldung wird durchgeführt. Danach im hcconn-Device noch scanDevices ausführen und Ihr solltet eine stattliche Anzahl Hausgeräte finden.

==Sicherheitsfunktion csrfToken in FHEM==
Neueste Versionen von FHEM verwenden eine [[csrfToken-HowTo|XSRF Schutzfunktion]]. Wer diese benutzen möchte, muss ein statisches Token definieren:
<pre>
attr WEB csrfToken myToken123
</pre>
und muss dann an seine redirectURL noch diesen Teil anhängen:
<pre>
&fwcsrf=myToken123
</pre>
Beispiel:
<pre>
define hcconn HomeConnectConnection D239EBCABC99994D239EBCABC999B3D2393204
http://localhost:8083/fhem?cmd.Test=set%20hcconn%20auth%20&fwcsrf=myToken123 simulator
</pre>
Wichtig wie immer: Die Redirect URL muss sowohl im Home Connect Developer Program als auch in der Definition des FHEM HomeConnectConnection devices geändert werden.

==Problembehandlung==
Frage: Wenn ich Zuhause bin, erreiche ich meinen FHEM-Server unter: https:// 192.168.x.x:8083/fhem.
Aus dem Internet erreiche ich FHEM über eine statische IP und Port-forwarding. Funktioniert das dann auch?

Antwort: Es muss kein Zugriff aus dem Internet auf den lokalen Server freigeschaltet werden, der Redirect passiert im eigenen Browser.
Aktuell ist nur eine redirect URL möglich, daher müsstest Du dich beim Home Connect Login für eine Variante entscheiden. Man muss sich ja nicht ständig neu einloggen. Ich habe aber gehört dass zukünftig mal eine Liste von URL's hinterlegt werden kann.

Frage: Ich bekomme '''vor''' dem Home Connect Login eine Fehlermeldung, sofort nach dem Klick auf "Home Connect Login"

Antwort: Entweder ist der API Key falsch oder die Redirect URL. Letztere muss den korrekten Hostnamen und Port enthalten, und auch den Namen des HomeConnectConnection device in der FHEM Installation. Diese URL muss identisch in der Home Connect App Definition und in der FHEM Definition eingetragen werden.

Frage: Ich bekomme '''nach''' dem Home Connect Login "Error" als Meldung in FHEM

Antwort: Dann hat Deine Redirect URL gestimmt und es ist was faul mit dem Api Key.

- Inspiziere mal genau die URL der Seite wo "Error" steht, vielleicht findest Du dort noch eine Fehlermeldung.

- Hast Du das Wort simulator in der Definition mit angegeben? Nur freigeschaltete Betatester können echte Hausgeräte steuern.

- Hast Du einen Advanced Account? Wenn nicht, können die Rechte von FHEM so eingeschränkt werden:
<pre>
attr hcconn accessScope IdentifyAppliance Monitor
</pre>

Frage: Die Geräte werden angelegt, aber das einzige, was ich angeboten bekomme ist: StartProgram RemoteProgramNotEnabled

Antwort: Du musst den Fernstart der Spülmaschine aktivieren, erst danach darf FHEM sie starten.

Frage: Nach dem Erlauben des Zugriffs bei HomeConnect erscheint nur ein weißer Bildschirm.

Antwort: Du musst das Attribut csrfToken deines FHEMWEB auf none setzen (oder wie oben beschrieben ein statisches Token installieren)
<pre>
attr WEB csrfToken none
</pre>

==Unterstützte Geräte==
Grundsätzlich funktionieren alle Home Connect Geräte, d.h. sie werden zumindest in FHEM angelegt und ihr Status wird sichtbar. Steuern kann man sie aktuell jedoch noch nicht alle.
===Backofen===
Steuerung aktuell nicht möglich, aber der Status wird angezeigt
===Geschirrspüler===
Steuerung möglich, Status wird angezeigt. Die Programmoption BSH.Common.Option.StartInRelative kann vor dem Programmstart auf eine Anzahl Sekunden gesetzt werden, um die der Start verzögert werden soll.

[[Kategorie:Other Components]]

HM-LC-Dim1T-Pl-3

2017-10-30T19:27:55Z

Darkness: Vorlage:Infobox Hardware eingefügt

{{Baustelle}}

{{Infobox Hardware
|Bild=PlatzHalter.png
|Bildbeschreibung=Vorderseite mit Beschriftungen
|HWProtocol=HomeMatic
|HWType=Dimmer
|HWCategory=HomeMatic
|HWComm=868,3/869,525 MHz
|HWChannels=1 (+2 virtuelle)
|HWVoltage=230 V
|HWPowerConsumption=1 W Standby
|HWPoweredBy=Netz
|HWSize=19x41x14mm
|HWDeviceFHEM=[[CUL_HM]]
|HWManufacturer=ELV / eQ-3
}}

'''HomeMatic HM-LC-Dim1L-Pl-3 Funk-Zwischenstecker-Dimmaktor 1fach Phasenabschnitt'''

HomeMatic Funk-Zwischenstecker-Dimmaktor 1fach, Phasenabschnitt

= Features =

Dimmen eines angeschlossenen Verbrauchers mittels CUL/CUN/HMLAN Konfigurator.

= Hinweise zum Betrieb mit FHEM =

Das [[Pairing (HomeMatic)|Pairing]] sollte wie in [[HomeMatic Devices pairen]] beschrieben durchgeführt werden.

== Mögliche Dimmoperationen ==

Der Dimmaktor versteht folgende Aktionen:
<pre>
set <name> on # schaltet den Aktor ein
set <name> off # schaltet den Aktor aus
set <name> toggle # schaltet den Aktor um
set <name> on-for-timer <sec> # schaltet den Aktor für <sec> ein
set <name> on-till <time> # schaltet den Aktor bis <time> ein (hh:mm:ss)
set <name> <value> [<on-time>] [<ramp-time>] # schaltet den Aktor auf <value> Prozent, <on-time> und <ramp-time> sind optional

# Beispiele
set <name> 50 0 60 # der Aktor dimmt in 60 Sekunden auf 50%
set <name> 75 300 180 # der Aktor dimmt in 180 Sekunden auf 75% und bleibt 5 Minuten an
set <name> 0 0 600 # der Aktor dimmt in 10 Minuten herunter (muss vorer eine Wert >0 haben) bis er aus ist
</pre>

== Peering und virtuelle Kanäle ==

Der Dimmer besitzt [[HomeMatic#virtuelle Kanäle|virtuelle Kanäle]] mittels denen auch komplexere Peeringschaltungen möglich sind.

== Peering mit HM-Sen-MDIR-WM55 ==

Ein Beispiel für die Verknüpfung aus dämmerungsgesteuerter Helligkeit und Bewegungsmelder wäre:

:<code>phyLevel = ((0% or Ch1) minus Ch2) </code>

*Ch1: Bewegungskanal (or)

::Der Bewegungsmelder schaltet den Kanal mit 100% ein

<pre>
<HM-Sen-MDIR-WM55>_Motion-shCtDlyOn ltLo
<HM-Sen-MDIR-WM55>_Motion-shCtOff ltLo
<HM-Sen-MDIR-WM55>_Motion-shCtOn ltLo
<HM-Sen-MDIR-WM55>_Motion-shCtRampOff ltLo
<HM-Sen-MDIR-WM55>_Motion-shCtRampOn ltLo
<HM-Sen-MDIR-WM55>_Motion-shCtValHi 100
<HM-Sen-MDIR-WM55>_Motion-shCtValLo 60
<HM-Sen-MDIR-WM55>_Motion-shDimElsActionType off
<HM-Sen-MDIR-WM55>_Motion-shDimElsJtDlyOff rampOff
<HM-Sen-MDIR-WM55>_Motion-shDimElsJtDlyOn rampOn
<HM-Sen-MDIR-WM55>_Motion-shDimElsJtOff dlyOn
<HM-Sen-MDIR-WM55>_Motion-shDimElsJtOn dlyOff
<HM-Sen-MDIR-WM55>_Motion-shDimElsJtRampOff off
<HM-Sen-MDIR-WM55>_Motion-shDimElsJtRampOn on
<HM-Sen-MDIR-WM55>_Motion-shDimElsOffTimeMd absolut
<HM-Sen-MDIR-WM55>_Motion-shDimElsOnTimeMd absolut
<HM-Sen-MDIR-WM55>_Motion-shDimJtDlyOff dlyOn
<HM-Sen-MDIR-WM55>_Motion-shDimJtDlyOn rampOn
<HM-Sen-MDIR-WM55>_Motion-shDimJtOff dlyOn
<HM-Sen-MDIR-WM55>_Motion-shDimJtOn on
<HM-Sen-MDIR-WM55>_Motion-shDimJtRampOff dlyOn
<HM-Sen-MDIR-WM55>_Motion-shDimJtRampOn on
<HM-Sen-MDIR-WM55>_Motion-shDimMaxLvl 100 %
<HM-Sen-MDIR-WM55>_Motion-shDimMinLvl 0 %
<HM-Sen-MDIR-WM55>_Motion-shDimStep 5 %
<HM-Sen-MDIR-WM55>_Motion-shMultiExec off
<HM-Sen-MDIR-WM55>_Motion-shOffDly 0 s
<HM-Sen-MDIR-WM55>_Motion-shOffDlyBlink on
<HM-Sen-MDIR-WM55>_Motion-shOffDlyNewTime 0.4 s
<HM-Sen-MDIR-WM55>_Motion-shOffDlyOldTime 0.4 s
<HM-Sen-MDIR-WM55>_Motion-shOffDlyStep 5 %
<HM-Sen-MDIR-WM55>_Motion-shOffLevel 0 %
<HM-Sen-MDIR-WM55>_Motion-shOffTime unused
<HM-Sen-MDIR-WM55>_Motion-shOffTimeMode absolut
<HM-Sen-MDIR-WM55>_Motion-shOnDly 0 s
<HM-Sen-MDIR-WM55>_Motion-shOnDlyMode setToOff
<HM-Sen-MDIR-WM55>_Motion-shOnLevel 100 %
<HM-Sen-MDIR-WM55>_Motion-shOnLvlPrio high
<HM-Sen-MDIR-WM55>_Motion-shOnMinLevel 10 %
<HM-Sen-MDIR-WM55>_Motion-shOnTime 600 s
<HM-Sen-MDIR-WM55>_Motion-shOnTimeMode absolut
<HM-Sen-MDIR-WM55>_Motion-shRampOffTime 0.5 s
<HM-Sen-MDIR-WM55>_Motion-shRampOnTime 0.5 s
<HM-Sen-MDIR-WM55>_Motion-shRampSstep 5 %
</pre>

*Ch2: Helligkeit (minus)

::Über FHEM wird dieser Kanal je nach Tageszeit gesetzt. Da dieser vom ersten Kanal abgezogen wird, bedeutet das Beispielsweise Tags 0% und Nachts 70%.
::Als Ergebnis wäre die Lampe Nachts auf 30% gedimmt

::Um diesen Kanal vom ersten zu subtrahieren muss Register logicCombination angepasst werden
::<code>set <HM-LC-Dim1L-Pl-3>_Dim_V_01 regSet logicCombination minus</code>

= Links =

Anleitung: [https://files.elv.com/Assets/Produkte/8/859/85973/Downloads/85973_HM_LC_Dim1T_Pl_KV1_um.pdf PDF]

[[Kategorie:HomeMatic Components]]
[[Kategorie:Dimmer]]

HM-LC-Dim1T-Pl-3

2017-10-30T19:19:52Z

Darkness: kleine Satzanpassung

{{Baustelle}}
'''HomeMatic HM-LC-Dim1L-Pl-3 Funk-Zwischenstecker-Dimmaktor 1fach Phasenabschnitt'''

HomeMatic Funk-Zwischenstecker-Dimmaktor 1fach, Phasenabschnitt

= Features =

Dimmen eines angeschlossenen Verbrauchers mittels CUL/CUN/HMLAN Konfigurator.

'''Technische Daten:'''
* Anschlussleistung: max. 300 VA
* Standby Verbrauch: 1 W
* Schutzart: IP20
* Maße(HxBxT): 63x125x41 mm

= Hinweise zum Betrieb mit FHEM =

Das [[Pairing (HomeMatic)|Pairing]] sollte wie in [[HomeMatic Devices pairen]] beschrieben durchgeführt werden.

== Mögliche Dimmoperationen ==

Der Dimmaktor versteht folgende Aktionen:
<pre>
set <name> on # schaltet den Aktor ein
set <name> off # schaltet den Aktor aus
set <name> toggle # schaltet den Aktor um
set <name> on-for-timer <sec> # schaltet den Aktor für <sec> ein
set <name> on-till <time> # schaltet den Aktor bis <time> ein (hh:mm:ss)
set <name> <value> [<on-time>] [<ramp-time>] # schaltet den Aktor auf <value> Prozent, <on-time> und <ramp-time> sind optional

# Beispiele
set <name> 50 0 60 # der Aktor dimmt in 60 Sekunden auf 50%
set <name> 75 300 180 # der Aktor dimmt in 180 Sekunden auf 75% und bleibt 5 Minuten an
set <name> 0 0 600 # der Aktor dimmt in 10 Minuten herunter (muss vorer eine Wert >0 haben) bis er aus ist
</pre>

== Peering und virtuelle Kanäle ==

Der Dimmer besitzt [[HomeMatic#virtuelle Kanäle|virtuelle Kanäle]] mittels denen auch komplexere Peeringschaltungen möglich sind.

== Peering mit HM-Sen-MDIR-WM55 ==

Ein Beispiel für die Verknüpfung aus dämmerungsgesteuerter Helligkeit und Bewegungsmelder wäre:

:<code>phyLevel = ((0% or Ch1) minus Ch2) </code>

*Ch1: Bewegungskanal (or)

::Der Bewegungsmelder schaltet den Kanal mit 100% ein

<pre>
<HM-Sen-MDIR-WM55>_Motion-shCtDlyOn ltLo
<HM-Sen-MDIR-WM55>_Motion-shCtOff ltLo
<HM-Sen-MDIR-WM55>_Motion-shCtOn ltLo
<HM-Sen-MDIR-WM55>_Motion-shCtRampOff ltLo
<HM-Sen-MDIR-WM55>_Motion-shCtRampOn ltLo
<HM-Sen-MDIR-WM55>_Motion-shCtValHi 100
<HM-Sen-MDIR-WM55>_Motion-shCtValLo 60
<HM-Sen-MDIR-WM55>_Motion-shDimElsActionType off
<HM-Sen-MDIR-WM55>_Motion-shDimElsJtDlyOff rampOff
<HM-Sen-MDIR-WM55>_Motion-shDimElsJtDlyOn rampOn
<HM-Sen-MDIR-WM55>_Motion-shDimElsJtOff dlyOn
<HM-Sen-MDIR-WM55>_Motion-shDimElsJtOn dlyOff
<HM-Sen-MDIR-WM55>_Motion-shDimElsJtRampOff off
<HM-Sen-MDIR-WM55>_Motion-shDimElsJtRampOn on
<HM-Sen-MDIR-WM55>_Motion-shDimElsOffTimeMd absolut
<HM-Sen-MDIR-WM55>_Motion-shDimElsOnTimeMd absolut
<HM-Sen-MDIR-WM55>_Motion-shDimJtDlyOff dlyOn
<HM-Sen-MDIR-WM55>_Motion-shDimJtDlyOn rampOn
<HM-Sen-MDIR-WM55>_Motion-shDimJtOff dlyOn
<HM-Sen-MDIR-WM55>_Motion-shDimJtOn on
<HM-Sen-MDIR-WM55>_Motion-shDimJtRampOff dlyOn
<HM-Sen-MDIR-WM55>_Motion-shDimJtRampOn on
<HM-Sen-MDIR-WM55>_Motion-shDimMaxLvl 100 %
<HM-Sen-MDIR-WM55>_Motion-shDimMinLvl 0 %
<HM-Sen-MDIR-WM55>_Motion-shDimStep 5 %
<HM-Sen-MDIR-WM55>_Motion-shMultiExec off
<HM-Sen-MDIR-WM55>_Motion-shOffDly 0 s
<HM-Sen-MDIR-WM55>_Motion-shOffDlyBlink on
<HM-Sen-MDIR-WM55>_Motion-shOffDlyNewTime 0.4 s
<HM-Sen-MDIR-WM55>_Motion-shOffDlyOldTime 0.4 s
<HM-Sen-MDIR-WM55>_Motion-shOffDlyStep 5 %
<HM-Sen-MDIR-WM55>_Motion-shOffLevel 0 %
<HM-Sen-MDIR-WM55>_Motion-shOffTime unused
<HM-Sen-MDIR-WM55>_Motion-shOffTimeMode absolut
<HM-Sen-MDIR-WM55>_Motion-shOnDly 0 s
<HM-Sen-MDIR-WM55>_Motion-shOnDlyMode setToOff
<HM-Sen-MDIR-WM55>_Motion-shOnLevel 100 %
<HM-Sen-MDIR-WM55>_Motion-shOnLvlPrio high
<HM-Sen-MDIR-WM55>_Motion-shOnMinLevel 10 %
<HM-Sen-MDIR-WM55>_Motion-shOnTime 600 s
<HM-Sen-MDIR-WM55>_Motion-shOnTimeMode absolut
<HM-Sen-MDIR-WM55>_Motion-shRampOffTime 0.5 s
<HM-Sen-MDIR-WM55>_Motion-shRampOnTime 0.5 s
<HM-Sen-MDIR-WM55>_Motion-shRampSstep 5 %
</pre>

*Ch2: Helligkeit (minus)

::Über FHEM wird dieser Kanal je nach Tageszeit gesetzt. Da dieser vom ersten Kanal abgezogen wird, bedeutet das Beispielsweise Tags 0% und Nachts 70%.
::Als Ergebnis wäre die Lampe Nachts auf 30% gedimmt

::Um diesen Kanal vom ersten zu subtrahieren muss Register logicCombination angepasst werden
::<code>set <HM-LC-Dim1L-Pl-3>_Dim_V_01 regSet logicCombination minus</code>

= Links =

Anleitung: [https://files.elv.com/Assets/Produkte/8/859/85973/Downloads/85973_HM_LC_Dim1T_Pl_KV1_um.pdf PDF]

[[Kategorie:HomeMatic Components]]
[[Kategorie:Dimmer]]

HM-LC-Dim1T-Pl-3

2017-10-30T19:14:22Z

Darkness: Die Seite wurde neu angelegt: „{{Baustelle}} '''HomeMatic HM-LC-Dim1L-Pl-3 Funk-Zwischenstecker-Dimmaktor 1fach Phasenabschnitt''' HomeMatic Funk-Zwischenstecker-Dimmaktor 1fach, Phasenabsc…“

{{Baustelle}}
'''HomeMatic HM-LC-Dim1L-Pl-3 Funk-Zwischenstecker-Dimmaktor 1fach Phasenabschnitt'''

HomeMatic Funk-Zwischenstecker-Dimmaktor 1fach, Phasenabschnitt

= Features =

Dimmen eines angeschlossenen Verbrauchers mittels CUL/CUN/HMLAN Konfigurator.

'''Technische Daten:'''
* Anschlussleistung: max. 300 VA
* Standby Verbrauch: 1 W
* Schutzart: IP20
* Maße(HxBxT): 63x125x41 mm

= Hinweise zum Betrieb mit FHEM =

Das [[Pairing (HomeMatic)|Pairing]] sollte wie in [[HomeMatic Devices pairen]] beschrieben durchgeführt werden.

== Mögliche Dimmoperationen ==

Der Dimmaktor versteht folgende Aktionen:
<pre>
set <name> on # schaltet den Aktor ein
set <name> off # schaltet den Aktor aus
set <name> toggle # schaltet den Aktor um
set <name> on-for-timer <sec> # schaltet den Aktor für <sec> ein
set <name> on-till <time> # schaltet den Aktor bis <time> ein (hh:mm:ss)
set <name> <value> [<on-time>] [<ramp-time>] # schaltet den Aktor auf <value> Prozent, <on-time> und <ramp-time> sind optional

# Beispiele
set <name> 50 0 60 # der Aktor dimmt in 60 Sekunden auf 50%
set <name> 75 300 180 # der Aktor dimmt in 180 Sekunden auf 75% und bleibt 5 Minuten an
set <name> 0 0 600 # der Aktor dimmt in 10 Minuten herunter (muss vorer eine Wert >0 haben) bis er aus ist
</pre>

== Peering und virtuelle Kanäle ==

Der Dimmer besitzt virtuelle Kanäle. Mittels dieser [[HomeMatic#virtuelle Kanäle|virtuelle Kanäle]] lassen sich auch komplexere Peeringmöglichkeiten erstellen.

== Peering mit HM-Sen-MDIR-WM55 ==

Ein Beispiel für die Verknüpfung aus dämmerungsgesteuerter Helligkeit und Bewegungsmelder wäre:

:<code>phyLevel = ((0% or Ch1) minus Ch2) </code>

*Ch1: Bewegungskanal (or)

::Der Bewegungsmelder schaltet den Kanal mit 100% ein

<pre>
<HM-Sen-MDIR-WM55>_Motion-shCtDlyOn ltLo
<HM-Sen-MDIR-WM55>_Motion-shCtOff ltLo
<HM-Sen-MDIR-WM55>_Motion-shCtOn ltLo
<HM-Sen-MDIR-WM55>_Motion-shCtRampOff ltLo
<HM-Sen-MDIR-WM55>_Motion-shCtRampOn ltLo
<HM-Sen-MDIR-WM55>_Motion-shCtValHi 100
<HM-Sen-MDIR-WM55>_Motion-shCtValLo 60
<HM-Sen-MDIR-WM55>_Motion-shDimElsActionType off
<HM-Sen-MDIR-WM55>_Motion-shDimElsJtDlyOff rampOff
<HM-Sen-MDIR-WM55>_Motion-shDimElsJtDlyOn rampOn
<HM-Sen-MDIR-WM55>_Motion-shDimElsJtOff dlyOn
<HM-Sen-MDIR-WM55>_Motion-shDimElsJtOn dlyOff
<HM-Sen-MDIR-WM55>_Motion-shDimElsJtRampOff off
<HM-Sen-MDIR-WM55>_Motion-shDimElsJtRampOn on
<HM-Sen-MDIR-WM55>_Motion-shDimElsOffTimeMd absolut
<HM-Sen-MDIR-WM55>_Motion-shDimElsOnTimeMd absolut
<HM-Sen-MDIR-WM55>_Motion-shDimJtDlyOff dlyOn
<HM-Sen-MDIR-WM55>_Motion-shDimJtDlyOn rampOn
<HM-Sen-MDIR-WM55>_Motion-shDimJtOff dlyOn
<HM-Sen-MDIR-WM55>_Motion-shDimJtOn on
<HM-Sen-MDIR-WM55>_Motion-shDimJtRampOff dlyOn
<HM-Sen-MDIR-WM55>_Motion-shDimJtRampOn on
<HM-Sen-MDIR-WM55>_Motion-shDimMaxLvl 100 %
<HM-Sen-MDIR-WM55>_Motion-shDimMinLvl 0 %
<HM-Sen-MDIR-WM55>_Motion-shDimStep 5 %
<HM-Sen-MDIR-WM55>_Motion-shMultiExec off
<HM-Sen-MDIR-WM55>_Motion-shOffDly 0 s
<HM-Sen-MDIR-WM55>_Motion-shOffDlyBlink on
<HM-Sen-MDIR-WM55>_Motion-shOffDlyNewTime 0.4 s
<HM-Sen-MDIR-WM55>_Motion-shOffDlyOldTime 0.4 s
<HM-Sen-MDIR-WM55>_Motion-shOffDlyStep 5 %
<HM-Sen-MDIR-WM55>_Motion-shOffLevel 0 %
<HM-Sen-MDIR-WM55>_Motion-shOffTime unused
<HM-Sen-MDIR-WM55>_Motion-shOffTimeMode absolut
<HM-Sen-MDIR-WM55>_Motion-shOnDly 0 s
<HM-Sen-MDIR-WM55>_Motion-shOnDlyMode setToOff
<HM-Sen-MDIR-WM55>_Motion-shOnLevel 100 %
<HM-Sen-MDIR-WM55>_Motion-shOnLvlPrio high
<HM-Sen-MDIR-WM55>_Motion-shOnMinLevel 10 %
<HM-Sen-MDIR-WM55>_Motion-shOnTime 600 s
<HM-Sen-MDIR-WM55>_Motion-shOnTimeMode absolut
<HM-Sen-MDIR-WM55>_Motion-shRampOffTime 0.5 s
<HM-Sen-MDIR-WM55>_Motion-shRampOnTime 0.5 s
<HM-Sen-MDIR-WM55>_Motion-shRampSstep 5 %
</pre>

*Ch2: Helligkeit (minus)

::Über FHEM wird dieser Kanal je nach Tageszeit gesetzt. Da dieser vom ersten Kanal abgezogen wird, bedeutet das Beispielsweise Tags 0% und Nachts 70%.
::Als Ergebnis wäre die Lampe Nachts auf 30% gedimmt

::Um diesen Kanal vom ersten zu subtrahieren muss Register logicCombination angepasst werden
::<code>set <HM-LC-Dim1L-Pl-3>_Dim_V_01 regSet logicCombination minus</code>

= Links =

Anleitung: [https://files.elv.com/Assets/Produkte/8/859/85973/Downloads/85973_HM_LC_Dim1T_Pl_KV1_um.pdf PDF]

[[Kategorie:HomeMatic Components]]
[[Kategorie:Dimmer]]

Jabber

2017-10-02T08:27:04Z

Darkness: Link auf Msg#Jabber gesetzt

{{Infobox Modul
|ModPurpose=Dieses Modul ermöglicht FHEM, sich mit dem Jabber-Netzwerk zu verbinden, um Nachrichten zu einem Jabber-Server zu senden oder von diesem zu empfangen.
|ModType=d
|ModCmdRef=
|ModForumArea=Unterstuetzende Dienste
|ModFTopic=18967
|ModTechName=70_Jabber.pm
|ModOwner=BioS ({{Link2FU|2021|Forum}})
}}
[[Jabber]] ist eine andere Beschreibung für "XMPP", ein Kommunikationsprotokoll für Nachrichtenorientierte "middleware", basierend auf XML.
Fester bestandteil des Protokolls ist die Verschlüsselung zwischen Client und Server.
Für den Benutzer ist es ähnlich anderer Chat-Plattformen wie zum Beispiel dem facebook Chat, ICQ oder Google Hangouts - jedoch frei Verfügbar, open Source und normalerweise Verschlüsselt (was Serverabhängig ist).

Seit Version 1.5 kann dieses Modul in Multi-User-Channel (sogenannte MUC) beitreten und Off-the-Record (OTR) Ende-zu-Ende Verschlüsselung benutzen.
OTR ist nochmal ein zusätzlicher Sicherheitsrelevater Punkt, da die Kommunikation wirklich von Endgerät zu FHEM verschlüsselt wird und man sich nicht auf die Jabber Server Transportverschlüsselung verlassen muss.



==Installation==
Auf aktuellen Systemen gibt es leider Probleme mit den verwendeten XMPP Perl Modulen.

Im speziellen benötigt man zwingend die folgende Perl-Modul Kombination, damit das Jabber Modul richtig funktionieren kann:
*XML::Stream 1.23
*Net::XMPP 1.02

Seine Modulversionen kann mit mit diesen Kommandos überprüfen, dabei auf den "Installed:" Eintrag achten:
<syntaxhighlight lang="bash">
cpan -D XML::Stream
cpan -D Net::XMPP
</syntaxhighlight>

Wenn man OTR benutzen möchte sollte zusätzlich noch das Perl Modul Crypt::OTR installiert sein.

Auf einem frisch installieren Ubuntu 16.04.02 LTS bedeutet das folgende Kommandos:
<syntaxhighlight lang="bash">
apt-get remove libnet-xmpp-perl
apt-get remove libxml-stream-perl
apt-get remove libotr5 libotr5-dev

apt-get install build-essential
apt-get install libnet-jabber-perl
wget http://ftp.de.debian.org/debian/pool/main/libn/libnet-xmpp-perl/libnet-xmpp-perl_1.02-3_all.deb
wget http://ftp.de.debian.org/debian/pool/main/libx/libxml-stream-perl/libxml-stream-perl_1.23-2_all.deb
dpkg -i libxml-stream-perl_1.23-2_all.deb
dpkg -i libnet-xmpp-perl_1.02-3_all.deb
</syntaxhighlight>

Für OTR ist noch folgendes notwendig (64bit Intel Platform):
<syntaxhighlight lang="bash">
apt-get install libgpg-error-dev
cpan install Digest::SHA1
wget http://ftp.de.debian.org/debian/pool/main/libo/libotr/libotr2_3.2.1-1+deb7u2_amd64.deb
wget http://ftp.de.debian.org/debian/pool/main/libo/libotr/libotr2-dev_3.2.1-1+deb7u2_amd64.deb
wget http://ftp.de.debian.org/debian/pool/main/libo/libotr/libotr2-bin_3.2.1-1+deb7u2_amd64.deb
wget http://ftp.de.debian.org/debian/pool/main/libg/libgcrypt11/libgcrypt11_1.5.0-5+deb7u4_amd64.deb
dpkg -i libgcrypt11_1.5.0-5+deb7u4_amd64.deb
dpkg -i libotr2_3.2.1-1+deb7u2_amd64.deb
dpkg -i libotr2-bin_3.2.1-1+deb7u2_amd64.deb
dpkg -i libotr2-dev_3.2.1-1+deb7u2_amd64.deb

cpan
cpan> notest install Crypt::OTR
</syntaxhighlight>

OTR bei 32 bit (Intel Platform):
<syntaxhighlight lang="bash">
apt-get install libgpg-error-dev
cpan install Digest::SHA1
wget http://ftp.de.debian.org/debian/pool/main/libo/libotr/libotr2_3.2.1-1+deb7u2_i386.deb
wget http://ftp.de.debian.org/debian/pool/main/libo/libotr/libotr2-dev_3.2.1-1+deb7u2_i386.deb
wget http://ftp.de.debian.org/debian/pool/main/libo/libotr/libotr2-bin_3.2.1-1+deb7u2_i386.deb
wget http://ftp.de.debian.org/debian/pool/main/libg/libgcrypt11/libgcrypt11_1.5.0-5+deb7u4_i386.deb
dpkg -i libgcrypt11_1.5.0-5+deb7u4_i386.deb
dpkg -i libotr2_3.2.1-1+deb7u2_i386.deb
dpkg -i libotr2-bin_3.2.1-1+deb7u2_i386.deb
dpkg -i libotr2-dev_3.2.1-1+deb7u2_i386.deb

cpan
cpan> notest install Crypt::OTR
</syntaxhighlight>

Wer keine Stunden auf die Keygenerierung warten will, kann noch das Programm "haveged" installieren, das kümmert sich um die entrophy generation, die OTR dringend braucht für seinen Privaten Schlüssel:
* haveged
<syntaxhighlight lang="bash">
apt-get install haveged
</syntaxhighlight>

==Beispiele==
Mit folgendem [[Notify]]-Beispiel kannst du auf eingehende Nachrichten reagieren, dieses Beispiel schickt das Reading "Temperatur" des Sensors "BU_Temperatur" bei jeder ankommenden Nachricht an den Sender zurück:

<syntaxhighlight lang="perl">
define Jabber_Notify notify JabberClient1:Message.* {
my $lastsender=ReadingsVal("JabberClient1","LastSenderJID","0");
my $lastmsg=ReadingsVal("JabberClient1","LastMessage","0");
my $temperature=ReadingsVal("BU_Temperatur","temperature","0");
fhem("set JabberClient1 msg ". $lastsender . " Temp: ".$temperature);
}
</syntaxhighlight>

Auf MUC Nachrichten lässt sich folgend reagieren, Augenmerk darauf legen dass der Nickname aus $lastsender in der msgmuc Funktion entfernt wird, damit die Nachricht an den Raum geht

<syntaxhighlight lang="perl">
define Jabber_Notify notify JabberClient1:MucMessage.* {
my $lastsender=ReadingsVal("JabberClient1","LastSenderJID","0");
my $lastmsg=ReadingsVal("JabberClient1","LastMessage","0");
my $temperature=ReadingsVal("BU_Temperatur","temperature","0");
fhem("set JabberClient1 msgmuc ". $lastsender . " Temp: ".$temperature);
}
</syntaxhighlight>

Auf OTR Nachrichten wird reagiert, wie auf normale private Nachrichten auch, jedoch wird mit der msgotr Funktion geantwortet:

<syntaxhighlight lang="perl">
define Jabber_Notify notify JabberClient1:OTRMessage.* {
my $lastsender=ReadingsVal("JabberClient1","LastSenderJID","0");
my $lastmsg=ReadingsVal("JabberClient1","LastMessage","0");
my $temperature=ReadingsVal("BU_Temperatur","temperature","0");
fhem("set JabberClient1 msgotr ". $lastsender . " Temp: ".$temperature);
}
</syntaxhighlight>

==Weitere Beispiele und HowTos im Wiki==
*[[FHEM_spricht_jabber]]
*[[Prosody|Installieren eines eigenen XMPP-Servers]]
*[[Msg#Jabber|Nachrichten über das msg-Modul senden]]

==Weblinks==
*[https://de.wikipedia.org/wiki/Extensible_Messaging_and_Presence_Protocol XMPP]
*[https://jabber.org jabber.org]
*[https://prosody.im/ Prosody Jabber Server]
*[https://pidgin.im/ pidgin Jabber Client]

Msg

2017-10-02T08:22:26Z

Darkness: Artikel um ein Jabberbeispiel ergänzt

{{SEITENTITEL:msg}}{{Infobox Modul
|ModPurpose=Versenden von Nachrichten der Typen Audio, Text, Mail, Push, Light, Screen
|ModType=cmd
|ModForumArea=Automatisierung
|ModFTopic=39983
|ModCmdRef=MSG
|ModTechName=75_MSG.pm
|ModOwner={{Link2FU|1363|Loredo}}
}}
Der FHEM-Befehl [[msg]] kann dazu benutzt werden, Benachrichtigungen auszugeben.

Der Befehl unterstützt die Nachrichtentypen
* text: Textnachrichten per Push- oder E-Mail-Dienst auf mobile Geräte verschicken
* audio: Sprachnachrichten und akustische Signale über Lautsprecher in der Wohnung ausgeben
* light: optische Signale durch Lampen in der Wohnung anzeigen
* screen: Nachrichten auf einem Bildschirm, etwa einem Fernsehgerät in der Wohnung, anzeigen
und kann an ein FHEM Gerät oder an eine eMail Adresse geschickt werden.

Weitere Details zu den Funktionen und zur Benutzung dieses Befehls finden sich im ersten Beitrag {{Link2Forum|Topic=39983|LinkText=dieser Diskussion}} im Forum.

Der Befehl '''msg''' ersetzt ausserdem das vormals verfügbare Modul '''MSG'''. Benutzer des alten Moduls müssen ihre Devices auf '''MSGFile''' und/oder '''MSGMail''' umstellen; bitte dafür das Forenthema {{Link2Forum|Topic=43447|LinkText="Benutzer von 75_MSG.pm: Aktion notwendig vor Update ab dem 04.11.2015"}} beachten!

===Vorteil===
Der Hauptvorteil ist, dass man hier an zentraler Stelle definiert, wie Nachrichten verteilt und zugestellt werden sollen und sich später auch jederzeit zentral anpassen lasst.
Dazu muss man dann nicht mehr jedes einzelne Notify, DOIF oder was auch immer anpassen (beispielsweise weil sich der Empfänger geändert hat oder man nun statt dem einen FHEM Modul ein anderes Modul für die Zustellung der Nachricht verwenden möchte).

Gesteuert wird das ganze über das setzen von Attributen. Zum einen am Device "globalMsg" für die Anpassung des Routing Verhaltens sowie einiger Attribute an einem beliebigen FHEM Device, welches die Adressierung des Bewohners oder der Bewohnergruppe ermöglicht. (Für die Profis: Alle globalen Attribute kann man auch per userattr an jedes beliebige Device hinzufügen; es erhält dort dann Vorrang).

Es können auch globale Empfänger konfiguriert werden, dann wird die Angabe eines Empfängers bei den neuen Kommandos optional und sollte einmal ein Empfänger angegeben werden, der keine Kontaktmöglichkeit für Text, Audio oder Visual hinterlegt hat, gibt es einen Fallback auf die globalen Einstellungen (also quasi eine Art Catch-All). Im Falle eines Fallbacks gibt es einen entsprechenden Logeintrag und eine Textnachricht wird entsprechend mit einem Hinweis ergänzt.

===Übertragungsmethoden===
====text====
Sendet eine Textnachricht per Push oder E-Mail. Je nach Priorität wird gepusht, gemailt oder beides. E-Mails werden mit der entsprechenden Priorität im Header markiert (dafür sind bei High und Low Prio HTML Mails zwingend erforderlich. Normale Mails werden als Nur-Text gesendet).

Die Befehle, wie gepusht oder gemailt werden soll, können über Attribute am Device "globalMsg" für die Prioritäts-Kategorien "High", "Normal" und "Low" angepasst werden. Standardmäßig wird für Push das Pushover Modul sowie für E-Mail system() per /usr/bin/mail verwendet.

Die Sub-Typen "mail" und "push" können auch explizit für sich aufgerufen werden.

====audio====
Gibt die Nachricht zunächst als Sprachnachricht weiter. Je nach Priorität wird die Nachricht auch per Text weitergeleitet. Auch kann optional die Anwesenheit des Bewohners berücksichtigt werden (follow me) und die Nachricht wird dann auch als Text weitergeleitet.
Außerdem kann über einen Dummy-Switcher gesteuert werden, ob Audio Nachrichten komplett wiedergegeben werden sollen, nur in einer gekürzten Fassung oder gerade überhaupt nicht (Emergency-Prio Nachrichten werden trotzdem immer wiedergegeben). Ich nutze das beispielsweise dafür, dass ich den Switcher auf "short" setze, wenn meine Wohnungstür offen steht, damit meine Nachbarn nicht meine gesamten Audio Benachrichtigungen zu hören kriegen ;)

Die Befehle zur Audio Wiedergabe können über Attribute am Device "globalMsg" für die Kategorien "Long", "Short with Priority" und "Short" angepasst werden. Der Nachrichtentitel wird hier als |Titel| mit übergeben.

Bei Verwendung von SONOSPLAYER gilt: Ist eine entsprechende Audio-Datei hinterlegt, wird diese dann vor der Nachricht mit eingebunden (Details siehe SONOS Doku). Ich nutze das, um meinen Audio-Nachrichten verschiedene Varianten von einem Gong voran zu stellen (z.B. wie im Flugzeug), damit sich die Bewohner bei einer plötzlichen Ansage nicht so erschrecken 8) Definiert man den Audio-Titel zentral über das Attribut msgTitleAudio, statt ihn in jedem msg-Kommando explizit anzugeben, kann man später auch zentral ändern, welche Sounddatei den Nachrichten vorangestellt werden soll und muss dann nicht überall Anpassungen vornehmen.
Weitere Audio-Dateien können natürlich wie in der SONOS Doku beschrieben in den Text über |Dateiname| aufgenommen werden.

====light====
Verwendet die Nachricht zunächst nur, um eine Leuchte anzusteuern (z.B. HUE). Je nach Priorität (hoch oder normal) kann die Leuchte anders geschaltet werden. Ist die Priorität hoch genug, wird die Nachricht zusätzlich auch per Audio wiedergegeben (dort greifen dann die Routing-Methoden für Audio). Auch hier kann optional die Anwesenheit des Bewohners berücksichtigt werden und die Nachricht alternativ als Text zugestellt werden, sofern die Priorität hoch genug ist.

Die Befehle zur visuellen Wiedergabe können über Attribute am Device "globaMsgl" für die Kategorien "High" und "Normal" angepasst werden. Standardmäßig wird ein einfaches Kommando für HUE Geräte verwendet (select und lselect zum kurzen bzw. längeren blinken).

====screen====
Ähnlich wie der Typ "light". Standardmäßig wird ein Text an eine ENIGMA2 Box geschickt.

===Verwendung===
'''Eine Liste der direkt unterstützten Module, ohne dass man diese händisch einbinden muss, kann man über den get-Befehl "routeCmd" beim Helfer-Device "globalMsg" (sofern es nicht umbenannt wurde) erhalten.'''
'''Dort kann man auch sehen, mit welcher Syntax ein bestimmtes Modul angesprochen wird und das ggf. als Vorlage für eine eigene Definition per msgCmd-Attribut nehmen.'''

Die Syntax ist sehr einfach gehalten:

:<code>msg [<type>] [<@device|e-mail address>] [<priority>] [|<title>|] <message></code>

Type kann auch weggelassen werden und ist dann automatisch auf "text" gesetzt.
Wenn kein Device und keine E-Mail Adresse angegeben wurden, dann wird automatisch an das globale msgConfig Device (globalMsg) verschickt (ansonsten gibt es eine Fehlermeldung, wenn dort kein passendes msgContact-Attribut gefunden wurde).

Auch können mehrere Typen oder Empfänger durch Komma getrennt angegeben werden (Und-Verknüpfung).
Eine Oder-Verknüpfung ist ebenso möglich und wird mit einer Pipe (|) zwischen Type und/oder Empfänger gemacht (Oder-Verknüpfung lässt sich auch mit Und-Verknüpfung kombinieren). Bei einer Oder-Verknüpfung wird nur zum nächsten Adressaten gesprungen, sofern für den vorigen keine der angegebenen Nachrichtentypen zugestellt werden konnte. Damit wird auch die automatische Eskalation zu einem anderen Nachrichten-Typ beeinflusst. Diese wird immer nur für den jeweils letzten Eintrag angewendet.

Grundsätzlich sind alle Syntax-Angaben, die oben in eckigen Klammern (also []) stehen, optional. Es wird dann auf entsprechende Standardwerte zurückgegriffen, die entweder über Attribute am Device oder global gesetzt wurden. Ist auch global nichts vorhanden, wird auf interne Standardwerte zurückgegriffen (gilt natürlich nicht für ein Device, denn irgendwo muss man ja immer einen Empfänger angeben ;) ).

Der Wertebereich für Priorität orientiert sich dabei an der Pushover API mit -2 bis 2. Es kann jedoch grundsätzlich jeder beliebige Wert verwendet werden. Es ist dann Sache des FHEM Moduls, ob der Wertebereich richtig ist oder ob er dort automatisch begrenzt wird (sofern ein FHEM Modul von der Priorität Gebrauch macht, ansonsten wird sie in erster Linie für das Routing innnerhalb des msg-Befehls benutzt).

Sowohl Und-Verknüpfung als auch Oder-Verknüpfung lassen sich ebenfalls in den Contact- und Recipient-Attributen anwenden. Somit bestehen eine Vielzahl von Möglichkeiten für die Adressierung von Empfängern und das Routing über bestimmte Nachrichtentypen.

===Konfiguration===

Sämtliche Einstellungen werden über Attribute vorgenommen. Dazu gibt es ein Konfigurationsdevice globalMsg in dem die Defaultwerte festgelegt werden. Alles andere passiert durch setzen von Attributen in den einzelnen Devices. Das Device globalMsg wird automatisch bei erster Verwendung von msg angelegt, sofern es nicht gefunden wurde.
Alternativ kann es mit
:<code>define globalMsg msgConfig </code>
angelegt werden

====Attribute für das Device "msgConfig"====
=====msgCmdAudio (Standard ohne Verwendung Attribut msgSwitcherDev)=====
Kommando für das "verschicken" von (langen) Audio Mitteilungen.
Entweder FHEM-Befehl oder in {} eingeschlossener Perl Befehl.

Verfügbare Variablen:
*%DEVICE%
*%RECIPIENT% (abhängig davon, ob das Modul optional oder verpflichtend eine gesonderte Adressierung des Empfängers vorsieht)
*%TITLE%
*%MSG%
*%PRIORITY%

=====msgCmdAudioShortPrio (nur in Verbindung mit msgSwitcherDev)=====
Kommando für das "verschicken" von Audio Mitteilungen mit Switcher Einstellung "short" und einer Prio höher/gleich msgFwPrioEmergencyAudio.
Entweder FHEM-Befehl oder in {} eingeschlossener Perl Befehl.

Verfügbare Variablen:
*%DEVICE%
*%RECIPIENT% (abhängig davon, ob das Modul optional oder verpflichtend eine gesonderte Adressierung des Empfängers vorsieht)
*%TITLE%
*%MSG%
*%PRIORITY%

=====msgCmdAudioShort (nur in Verbindung mit msgSwitcherDev)=====
Kommando für das "verschicken" von (gekürzten) Audio Mitteilungen mit Switcher Einstellung "short" unabhängig von der Priorität.
Entweder FHEM-Befehl oder in {} eingeschlossener Perl Befehl.

Verfügbare Variablen:
*%DEVICE%
*%RECIPIENT% (abhängig davon, ob das Modul optional oder verpflichtend eine gesonderte Adressierung des Empfängers vorsieht)
*%TITLE%
*%MSG%
*%PRIORITY%

=====msgCmd<TYPE><PrioCat>=====
Kommando für den jeweilige Nachrichten-Typen und der entsprechenden Nachrichten-Prioritätskategorie

=====msgFwPrioAbsent<TYPE>=====
Schwellenwert, ab dem Nachrichten diesen Typs bei kurzer Abwesenheit aller Bewohner per Text weitergeleitet werden sollen.
Voreinstellung: 0

=====msgFwPrioEmergency<TYPE>=====
Schwellenwert, ab dem Nachrichten diesen Typs als Emergency Prio behandelt werden.
Diese Nachrichten werden immer wiedergegeben, unabhängig der Abwesenheit oder der Einstellung long/short am aSwitcherDev Dummy.
Voreinstellung: 2

=====msgFwPrioGone<TYPE>=====
Schwellenwert, ab dem Nachrichten diesen Typs bei längerer Abwesenheit aller Bewohner per Text weitergeleitet werden sollen.
Voreinstellung: 1

=====msgPriority<TYPE>=====
Standard Priorität für Nachrichten diesen Typs, sofern nicht in der Nachricht angegeben.
Voreinstellung: 0

=====msgTitle<TYPE><PrioCat>=====
Standard Betreff für Nachrichten diesen Typs, sofern in der Nachricht keiner angegeben wurde.

=====msgResidentsDev=====
FHEM Gerätename, welcher für die Anwesenheit aller Bewohner verwendet wird. Auf dieses Device wird zurückgegriffen, sofern für das Empfänger-Device die entsprechenden Readings nicht vorhanden sind.
Bei Verwendung von ROOMMATE, GUEST oder RESIDENTS Devices als Empfänger wird dieses Attribut ignoriert.
Das in diesem Attribut angegebene Device muss die Readings "presence" und "state" haben. Es wird die Verwendung eines Devices vom FHEM Typ RESIDENTS empfohlen.
Über "presence" wird generell An/Abwesenheit bewertet. Hat "state" den Wert "gone", wird eine längere Abwesenheit angenommen.
Für das Weiterleiten von Nachrichten bei längerer Abwesenheit muss die Nachrichten Priorität höher sein, als wenn die Bewohner nur übergangsweise abwesend sind.
Siehe auch entsprechende Readings msgFwPrioGone<TYPE> msgFwPrioAbsent<TYPE>.

Readings Wertebereich:
presence: present|absent
state: gone|*

=====msgSwitcherDev=====
FHEM Gerätename, welcher für die Beeinflussung der Länge von Audio Nachrichten verwendet werden soll.
Bei "off" findet auch keine visuelle Benachrichtigung mehr statt. Screen Nachrichten sind nicht betroffen.
Hier bietet sich ein Dummy Device wie dieses hier an:

<pre>define HouseAnn dummy
attr HouseAnn alias Announcements
attr HouseAnn devStateIcon aktiv:general_an@90EE90 active:general_an@90EE90 lang:general_an@green:off aus:general_aus@red:long kurz:general_an@orange:long visuell:general_an@orange:long
attr HouseAnn event-on-change-reading state
attr HouseAnn eventMap active:aktiv long:lang short:kurz visual:visuell off:aus
attr HouseAnn group Automation
attr HouseAnn icon audio_volume_mid
attr HouseAnn room Apartment
attr HouseAnn setList state:lang,kurz,visuell,aus
attr HouseAnn webCmd state</pre>

====Attribute für alle FHEM Devices====
*Für die Verwendung der Fallback und Catchall-Zustellung von Nachrichten können diese Attribute im Device "global" gesetzt werden.
* Nahezu alle globalen Attribute können auch auf ein Device angewendet werden (Ausnahme: msgResidentsDev). Sie tauchen allerdings dort aus Gründen der Übersicht nicht standardmäßig auf. Man muss sie deshalb zuvor als userattr (entweder beim Device oder eben global) hinzufügen, damit man sie setzen kann.

=====msgContact<TYPE> (zwingend für Nachrichten diesen Typs)=====
FHEM Gerätename, welcher zur Übermittlung von Nachrichten diesen Typs angesprochen werden soll.
Muss bei Audio Nachrichten ohne eigene Definition von msgCmdAudio* ein Gerät vom Typ SONOSPLAYER sein.Muss bei Screen Nachrichten ohne eigene Definition von msgCmdScreen* ein Gerät vom Typ ENIGMA2 sein.Muss bei Light Nachrichten ohne eigene Definition von msgCmdLight* ein Gerät vom Typ HUEDevice sein.
Muss bei Push Nachrichten ohne eigene Definition von msgCmdPush* ein Gerät vom Typ Pushover sein.
Muss bei Mail Nachrichten eine oder mehrere gültige E-Mail Adressen enthalten.
Bei FHEM Gerätenamen, über die mehrere Empfänger adressiert werden können, kann der Empfänger mittels Doppelpunkt getrennt vom FHEM Gerätenamen angegeben werden. Je nach Modul ist das optional oder verbindlich.

=====msgRecipient<TYPE>=====
Leitet Nachrichten, die an dieses Gerät adressiert werden, auf ein anderes FHEM Device um.
Es wird dann der Wert von msgContact<TYPE> des anderen Gerätes für die Übermittlung der Nachricht verwendet.
Bei Nutzung des Attributs mit Typangabe werden nur Nachrichten des entsprechenden Typs umgeleitet.
Kombination von msgRecipient mit msgRecipient<TYPE> führt dazu, dass msgRecipient<TYPE> bevorzugt wird.

===Follow-Me Funktion===
Sobald ein Device, an welches man eine Nachricht schickt, ein Reading "location" beinhaltet, wird geprüft, ob es für diese Lokation eine speziell hinterlegte Kontaktmöglichkeit gibt (z.B. also eine genaue SONOS Soundbox in dem Raum, wo der Bewohner sich gerade befindet).

Gebraucht wird hierfür ein iBeacon zusammen mit dem GEOFANCY Modul. ich empfehle außerdem den Einsatz des ROOMMATE Moduls dazu, weil es die Handhabung der Location gleich mitbringt (Einrichtung siehe Wiki). Man kann aber auch jede andere Möglichkeit der Raumortung nutzen, es muss nur in einem Reading namens "location" enden.

Über das Attribut "msgLocationDevs" können Devices mit Komma getrennt angegeben werden, welche dann für je einen Raum stehen und welche dann dort die msgContact* Attribute hinterlegt haben (Delegationen mittels msgRecipient* funktionieren dort auch).
Am einfachsten ist es also pro Raum ein Dummy-Device anzulegen und dieses dann unter dem globalen Attribut "msgLocationDevs" mit aufzuführen.

Wichtig ist, dass dieses Dummy ein Attribut "msgLocationName" enthält, welches dann den exakt gleichen Wortlaut enthalten muss, wie auch im Reading "location" bei dem ROOMMATE Device (also genau der Lokationsname, den ihr z.B. in eurer Geofency.app angegeben habt). Zusätzlich dann eben noch die Type-Contacts. Hier ein Beispiel für Wohnzimmer und Schlafzimmer:

<pre>define msgRoom_Living dummy
attr msgRoom_Living msgContactAudio Sonos_Living_Room
attr msgRoom_Living msgContactLight LR_Ceilling,LR_FloorLamp,LR_SofaCorner,LR_DinnerCorner
attr msgRoom_Living msgLocationName Living
attr msgRoom_Living userattr msgLocationName

define msgRoom_Bedroom dummy
attr msgRoom_Bedroom msgContactAudio Sonos_Bedroom
attr msgRoom_Bedroom msgContactLight BR_FloorLamp
attr msgRoom_Bedroom msgLocationName Bedroom
attr msgRoom_Bedroom userattr msgLocationName</pre>

Beide Devices sind als globales Attribut verlinkt:

:<code>attr globalMsg msgLocationDevs msgRoom_Living,msgRoom_Bedroom</code>

Wenn ich nun einen msg-Audio Befehl absetze während ich im Schlafzimmer oder Wohnzimmer bin (Reading ist gleich "Living" oder "Bedroom"), wird die Nachricht auf demjenigen Gerät abgespielt, welches ich für den Raum hinterlegt habe (gleiches gilt für Light-Nachrichten). Wechsle ich den Raum und führe den Befehl nochmal aus, folgt mir auch die Wiedergabe der Nachricht

===Beispiele===
Bei der ersten Verwendung von msg wird das Konfigurationsdevice globalMsg angelegt. Es kann aber auch vorher manuell angelegt werden.

====Pushover====
Um mit msg Pushovernachrichten zu versenden ist vorher die Konfiguration eines [[Pushover|Pushoverdevices]] notwendig. Dieses wird dann mit
:<code>attr globalMsg msgContactPush <Pushoverdevice></code>
dem globalMsg als Standardpushoverdevice hinzugefügt.

anschließend kann der Befehl
:<code>msg test</code>
verwendet werden. Folgendes passiert:
Das msg-Modul erkennt dass eine Nachricht verschickt werden soll. Da kein Übertragungsweg angegeben ist, wird der Standardweg genommen, nämlich text. Bei text wird eine Mail und ein Push verschickt. Da Mail nicht näher definiert ist, wird nur der Push genommen. Da bei Push kein expliziter Empfänger angegeben ist, wird der Empfänger aus dem Attribut von msgContactPush genommen.

Alternativ kann auch direkt ein Push an einen definiertes Pushoverdevice gesendet werden:
:<code>msg push @<Pushoverdevice> 1 |FHEM| test</code>
hier wird eine Pushnachricht ein ein definiertes Pushoverdivce mit der Priorität 1, dem Titel FHEM und der Nachricht test gesendet

====Telegram====
Der Versand von Nachrichten über Telegram kann anlog zu Pushover verwendet werden. Zunächst muss auch hier ein [[TelegramBot|Telegram-Device]] angelegt werden.

Anschließend kann dieses in globalMsg als Standardevice festgelgt werden:
:<code>attr globalMsg msgContactPush <Telegramdevice></code>

anschließend kann der Befehl
:<code>msg test</code>
verwendet werden. Folgendes passiert:

Alternativ kann auch direkt ein Push an einen definiertes Telegramdevice gesendet werden:
:<code>msg push @<Telegramdevice> test</code>

Im vergleich zu Pushover werden Titel und Priorität ignoriert, da Telegram damit nicht umgehen kann.

==== msg in Verbindung mit ROOMMATES====
Werden ROOMMates verwendet dann können jedem ROOMMATE Kontaktdevices hinzugefügt werden.
Analog zu diesem Beispiel kann msg nicht nur bei ROOMMATES sondern bei jedem beliebigen FHEM-Device angewendet werden.
:<code>attr <ROOMMATEDEVICE> msgContactPush <Pushdevice(s)> </code>
oder konkret:
:<code>attr rr_Michael msgContactPush PushoverMichael</code>
bzw. für Telegram:
:<code>attr rr_Michael msgContactPush Telegram</code>
bzw. für beide:
:<code>attr rr_Michael msgContactPush Telegram,PushoverMichael</code>

Somit kann ich dann ganz einfach über
:<code> msg push @rr_Michael |FHEM| Dies ist eine Testnachricht für Michael!</code>
Michael eine Pushnachricht über das in dem Attribut für ihn definierte Device schicken.
Sollte sich der ROOMMATE nun dazu entschließen Pushover nicht mehr zu verwenden, so muss nicht an jeder Stelle im Code wo ein Push abgesetzt wird das Device geändert werden, sondern nur an einer Zentralen Stellen, nämlich beim ROOMMATE durch ändern des Attributes.

==== msg in Verbindung mit RESIDENTS====
Möchte man dynamisch Nachrichten an z.B. alle Personen schicken, die gerade zuhause sind, dann kann man sich das RESIDENTS-Modul und die darin vorhandenen Readings zu nutze machen. Alle Anwesenden Personen stehen in dem Reading residentsHomeDevs bzw. residentsTotalRoommatesPresentDevs wenn man zwischen ROOMMATES und GUESTs unterscheidet. Hier sollte man immer das Dev-Reading nutzen, da dort das ROOMMATE-Device angesprochen wird und nicht ggf. ein Alias.
Eine Nachricht an alle anwesenden Personen könnte als Beispielsweise so verschickt werden:
:<code>msg [msg-typ] @[r<resident-Device>:<Reading des Resident-Devices>] Du bist zuhause</code>
oder konkret
:<code>msg push @[rgr_Bewohner:residentsHomeDevs] Du bist zuhause</code>

Es gilt die normale Syntax von MSG. Typ ist beispielsweise Optional und ein Titel kann auch mitgegeben werden.
Das Routing des MSG-Moduls Teil dann das Reading in die einzelnen Empfänger auf und schickt in diesem Fall eine Push-Nachricht an die entsprechenden Personen

==== Lautstärkeanpassung bei Audionachrichten====
Um die Lautstärke einer Audioausgabe beim Absetzen des MSG-Befehls anzupassen (wenn diese von den Defaultwerten des msg-Schemas abweichen soll) kann am Ende der Nachricht ein JSON mit Variablen angehangen werden, welche vom Schema (siehe "get globalMsg routeCmd") unterstützt wird oder welche du selbst in einem msgCmd* Attribut verwendest. Für eine Sonos-Nachricht sieht das dann z.B. so aus:
:<code> msg audio @Sonos_Bedroom |Hint| Gute Nacht! O[{"VOLUME":"8"}] </code>

{{Hinweis| Standardmäßig wird bei angegebenem Betreff nach einer Audiodatei mit dem Namen des Betreffs (hier: Hint.mp3) in der Sonosfreigabe (bsp.: SonosSpeak) gesucht und diese vor der Nachricht abgespielt. Ist die Datei nicht vorhanden, dann kommt es zu 2 Fehlermeldungen vom Sonos-Modul im Log. Die anschließende Sprachnachricht wird aber trotzdem abgespielt.}}

====Jabber====
Der Versand der Nachrichten über Jabber ist ähnlich dem Versand über Telegram.
Natürlich muss auch hier zunächst das [[Jabber|Jabber-Device]] eingerichtet werden.

Im msgConfig ist folgendes Attribut zu ergänzen:
:<code>attr globalMsg msgContactPush jabberdevice:jabberkontact</code>

Um Nachrichten zu versenden, reicht nun
:<code>msg test</code>

{{Hinweis| Weitere Beispiele folgen.}}