FHEMWiki - Benutzerbeiträge [de]

SYSMON

2023-01-12T09:54:03Z

Rspecht: Beispielkonfiguration SSH wurde hinzugefügt

{{Infobox Modul
|ModPurpose=Anzeige von Informationen und Statistiken zu dem System, auf dem FHEM ausgeführt wird.
|ModType=d

|ModForumArea=Unterstützende Dienste
|ModTechName=42_SYSMON.pm
|ModOwner=hexenmeister ([http://forum.fhem.de/index.php?action=profile;u=4065 Forum] / [[Benutzer:Hexenmeister|Wiki]])
}}

Das [[SYSMON]] Modul liefert diverse Informationen und Statistiken zu dem System, auf dem FHEM-Server ausgeführt wird. Seit Version 2.0 können auch Remote-Systeme abgefragt werden (Telnet).
Es werden nur Linux-basierte Systeme unterstützt. Manche Informationen sind hardwarespezifisch und sind daher nicht auf jeder Plattform verfügbar.
Bis jetzt wurde dieses Modul auf folgenden Systemen getestet: Raspberry Pi (Debian Wheezy), BeagleBone Black, FritzBox 7390, WR703N unter OpenWrt, CubieTruck und einige andere.

Für Informationen zu einer FritzBox beachten Sie bitte auch Module: [[FRITZBOX]] und [[FB_CALLMONITOR]].

Das Modul nutzt das Perlmodule 'Net::Telnet' für den Fernzugriff. Dieses muss ggf. nachinstalliert werden. Unter Ubuntu kann dafür das Paket libnet-telnet-perl verwendet werden.

==Definition==
:<code>define <name> SYSMON [MODE[:[USER@]HOST][:PORT]] [<M1>[ <M2>[ <M3>[ <M4>]]]]</code>

Diese Anweisung erstellt eine neue SYSMON-Instanz. Die Parameter M1 bis M4 legen die Aktualisierungsintervalle für verschiedenen Readings (Statistiken) fest. Die Parameter sind als Multiplikatoren für die Zeit, die durch INTERVAL_BASE definiert ist, zu verstehen. Da diese Zeit fest auf 60 Sekunden gesetzt ist, können die Mx-Parameters als Zeitintervalle in Minuten angesehen werden.
Wird einer (oder mehrere) Multiplikatoren auf Null gesetzt werden, wird das entsprechende Readings deaktiviert.

===Parameter===
Die Parameter sind für die Aktualisierung der Readings nach folgender Schema zuständig:

* '''M1''': (Default-Wert: 1)
:CPU-Daten: ''cpu_freq'', ''cpu_temp'', ''cpu_temp_avg'', ''loadavg'', ''stat_cpu'', ''stat_cpu_diff'', ''stat_cpu_percent'', ''stat_cpu_text'', power readings

* '''M2''': (Default-Wert: M1)
:Speicher: ''ram'', ''swap'' etc.

* '''M3''': (Default-Wert: M1)
:Netztwerkinformationen: ''eth0'', ''eth0_diff'', ''wlan0'', ''wlan0_diff'' etc.

* '''M4''': (Default-Wert: 10*M1)
:Filesystem-Informationen

folgende Readings werden immer anhand des Basisintervalls (unabhängig von den Mx-Parameters) aktualisiert:
''fhemuptime'', ''fhemuptime_text'', ''idletime'', ''idletime_text'', ''uptime'', ''uptime_text''

Für Abfrage eines entfernten Systems muss mindestens deren Adresse (HOST) angegeben werden, bei Bedarf ergänzt durch den Port und/oder den Benutzernamen. Das eventuell benötigte Passwort muss einmalig mit dem Befehl 'set password <pass>' definiert werden. Als MODE sind derzeit 'telnet' und 'local' erlaubt. 'local' erfordert keine weiteren Angaben und kann auch ganz weggelassen werden.

==readings==

* '''cpu_bogomips'''
:CPU Speed: BogoMIPS

* '''cpu_freq'''
:CPU-Frequenz

* '''cpu_temp'''
:CPU-Temperatur

* '''cpu_temp_avg'''
:Durchschnitt der CPU-Temperatur, gebildet über die letzten 4 Werte.

* '''fhemuptime'''
:Zeit (in Sekunden) seit dem Start des FHEM-Servers.

* '''fhemuptime_text'''
:Zeit seit dem Start des FHEM-Servers: Menschenlesbare Ausgabe (textuelle Darstellung).

* '''idletime'''
:Zeit (in Sekunden und in Prozent), die das System (nicht der FHEM-Server!) seit dem Start in dem Idle-Modus verbracht hat. Also die Zeit der Inaktivität.

* '''idletime_text'''
:Zeit der Inaktivität des Systems seit dem Systemstart in menschenlesbarer Form.

* '''loadavg'''
:Ausgabe der Werte für die Systemauslastung (load average): 1 Minute-, 5 Minuten- und 15 Minuten-Werte.

* '''ram'''
:Ausgabe der Speicherauslastung.

* '''swap'''
:Benutzung und Auslastung der SWAP-Datei (bzw. Partition).

* '''uptime'''
:Zeit (in Sekunden) seit dem Systemstart.

* '''uptime_text'''
:Zeit seit dem Systemstart in menschenlesbarer Form.

* '''Netzwerkinformationen'''
:Informationen zu den über die angegebene Netzwerkschnittstellen übertragene Datenmengen und der Differenz zu der vorherigen Messung.
:Beispiele:
::Menge der übertragenen Daten über die Schnittstelle eth0.
::eth0: RX: 940.58 MB, TX: 736.19 MB, Total: 1676.77 MB
::Änderung der übertragenen Datenmenge in Bezug auf den vorherigen Aufruf (für eth0).
::eth0_diff: RX: 0.66 MB, TX: 0.06 MB, Total: 0.72 MB

* '''Dateisysteminformationen'''
:Informationen zu der Größe und der Belegung der gewünschten Dateisystemen.
:Seit Version 1.1.0 können Dateisysteme auch benannt werden (s.u.).
:In diesem Fall werden für die diese Readings die angegebenen Namen verwendet.
:Dies soll die Übersicht verbessern und die Erstellung von Plots erleichtern.
:Beispiel:
::fs_root: Total: 7340 MB, Used: 3573 MB, 52 %, Available: 3425 MB at /

* '''CPU Auslastung'''
:Informationen zu der Auslastung der CPU(s).
:Beispiel:
::stat_cpu: 10145283 0 2187286 90586051 542691 69393 400342
::stat_cpu_diff: 2151 0 1239 2522 10 3 761
::stat_cpu_percent: 4.82 0.00 1.81 93.11 0.05 0.00 0.20
::stat_cpu_text: user: 32.17 %, nice: 0.00 %, sys: 18.53 %, idle: 37.72 %, io: 0.15 %, irq: 0.04 %, sirq: 11.38 %

* '''Benutzerdefinierte Einträge'''
::Diese Readings sind Ausgaben der Kommandos, die an das Betriebssystem übergeben werden. Die entsprechende Angaben werden im Attribut user-defined vorgenommen.

'''FritzBox-spezifische Readings'''
* '''wlan_state'''
:WLAN-Status: on/off

* '''wlan_guest_state'''
:Gast-WLAN-Status: on/off

* '''internet_ip'''
:aktuelle IP-Adresse

* '''internet_state'''
:Status der Internetverbindung: connected/disconnected

* '''night_time_ctrl'''
:Status der Klingelsperre on/off

* '''num_new_messages'''
:Anzahl der neuen Anrufbeantworter-Meldungen

* '''fw_version_info'''
:Angaben zu der installierten Firmware-Version:

 
'''Readings zur Stromversorgung'''
* '''power_ac_stat'''
:Statusinformation für die AC-Buchse: present (0|1), online (0|1), voltage, current
:Beispiel:
::power_ac_stat: 1 1 4.807 264

* '''power_ac_text'''
:Statusinformation für die AC-Buchse in menschenlesbarer Form
:Beispiel:
::power_ac_text ac: present / online, Voltage: 4.807 V, Current: 264 mA

* '''power_usb_stat'''
:Statusinformation für die USB-Buchse

* '''power_usb_text'''
Statusinformation für die USB-Buchse in menschenlesbarer Form

* '''power_battery_stat'''
:Statusinformation für die Batterie (wenn vorhanden): present (0|1), online (0|1), voltage, current, actual capacity
:Beispiel:
::power_battery_stat: 1 1 4.807 264 100

* '''power_battery_text'''
:Statusinformation für die Batterie (wenn vorhanden) in menschenlesbarer Form

* '''power_battery_info'''
:Menschenlesbare Zusatzinformationen für die Batterie (wenn vorhanden): Technologie, Kapazität, Status, Zustand, Gesamtkapazität
:Beispiel:
::power_battery_info: battery info: Li-Ion , capacity: 100 %, status: Full , health: Good , total capacity: 2100 mAh

===Ausgabe-Beispiel===

{| class="wikitable"
|-
|cpu_freq
|900
|2013-11-27 00:05:36
|-
|cpu_temp
|49.77
|2013-11-27 00:05:36
|-
|cpu_temp_avg
|49.7
|2013-11-27 00:05:36
|-
|eth0
|RX: 2954.22 MB, TX: 3469.21 MB, Total: 6423.43 MB
|2013-11-27 00:05:36
|-
|eth0_diff
|RX: 6.50 MB, TX: 0.23 MB, Total: 6.73 MB
|2013-11-27 00:05:36
|-
|fhemuptime
|11231
|2013-11-27 00:05:36
|-
|fhemuptime_text
|0 days, 03 hours, 07 minutes
|2013-11-27 00:05:36
|-
|idletime
|931024 88.35 %
|2013-11-27 00:05:36
|-
|idletime_text
|10 days, 18 hours, 37 minutes (88.35 %)
|2013-11-27 00:05:36
|-
|loadavg
|0.14 0.18 0.22
|2013-11-27 00:05:36
|-
|ram
|Total: 485 MB, Used: 140 MB, 28.87 %, Free: 345 MB
|2013-11-27 00:05:36
|-
|swap
|n/a
|2013-11-27 00:05:36
|-
|uptime
|1053739
|2013-11-27 00:05:36
|-
|uptime_text
|12 days, 04 hours, 42 minutes
|2013-11-27 00:05:36
|-
|wlan0
|RX: 0.00 MB, TX: 0.00 MB, Total: 0 MB
|2013-11-27 00:05:36
|-
|wlan0_diff
|RX: 0.00 MB, TX: 0.00 MB, Total: 0.00 MB
|2013-11-27 00:05:36
|-
|fs_root
|Total: 7404 MB, Used: 3533 MB, 50 %, Available: 3545 MB at /
|2013-11-27 00:05:36
|-
|fs_boot
|Total: 56 MB, Used: 19 MB, 33 %, Available: 38 MB at /boot
|2013-11-27 00:05:36
|-
|fs_usb1
|Total: 30942 MB, Used: 6191 MB, 21 %, Available: 24752 MB at /media/usb1
|2013-11-27 00:05:36
|-
|stat_cpu
|10145283 0 2187286 90586051 542691 69393 400342
|2013-11-27 00:05:36
|-
|stat_cpu_diff
|2151 0 1239 2522 10 3 761
|2013-11-27 00:05:36
|-
|stat_cpu_percent
|4.82 0.00 1.81 93.11 0.05 0.00 0.20
|2013-11-27 00:05:36
|-
|stat_cpu_text
|user: 32.17 %, nice: 0.00 %, sys: 18.53 %, idle: 37.72 %, io: 0.15 %, irq: 0.04 %, sirq: 11.38 %
|2013-11-27 00:05:36
|}

==Befehle==

===get===

*interval
:Listet die bei der Definition angegebene Polling-Intervalle auf.

*list
:Gibt alle Readings aus.

*update
:Aktualisiert alle Readings. Alle Werte werden neu abgefragt.

*version
:Zeigt die Version des SYSMON-Moduls.

===set===

*interval_multipliers
:Definiert Multipliers (wie bei der Definition des Gerätes).

*clean
:Löscht benutzerdefinierbare Readings. Nach einem Update (oder nach der automatischen Aktualisierung) werden neue Readings generiert.

*clear <reading name>
:Löscht den Reading-Eintrag mit dem gegebenen Namen. Nach einem Update (oder nach der automatischen Aktualisierung) wird dieser Eintrag ggf. neu erstellt (falls noch definiert). Dieses Mechanismus erlaubt das gezielte Löschen nicht mehr benötigter benutzerdefinierten Einträge.

==Attribute==

*filesystems <reading name>[:<mountpoint>[:<comment>]],...
:Gibt die zu überwachende Dateisysteme an. Es wird eine kommaseparierte Liste erwartet.
:Reading-Name wird bei der Anzeige und Logging verwendet, Mount-Point ist die Grundlage der Auswertung, Kommentar ist relevant für die HTML-Anzeige (s. SYSMON_ShowValuesHTML)
:Beispiel: /boot,/,/media/usb1
:oder: fs_boot:/boot,fs_root:/:Root,fs_usb1:/media/usb1:USB-Stick
:Im Sinne der besseren Übersicht sollten zumindest Name und MountPoint angegeben werden.

*network-interfaces <name>[:<interface>[:<comment>]],...
:Kommaseparierte Liste der Netzwerk-Interfaces, die überwacht werden sollen. Jeder Eintrag besteht aus dem Reading-Namen, dem Namen des Netzwerk-Adapters und einem Kommentar für die HTML-Anzeige (s. SYSMON_ShowValuesHTML). Wird kein Doppelpunkt verwendet, wird der Wert gleichzeitig als Reading-Name und Interface-Name verwendet.
:Beispiel ethernet:eth0:Ethernet,wlan:wlan0:WiFi

*user-defined <readingsName>:<Interval_Minutes>:<Comment>:<Cmd>,...
:Diese kommaseparierte Liste definiert Einträge mit jeweils folgenden Daten: Reading-Name, Aktualisierungsintervall in Minuten, Kommentar und Betriebssystem-Kommando.
:Die BS-Befehle werden entsprechend des angegebenen Intervalls ausgeführt und als Readings mit den angegebenen Namen vermerkt. Kommentare werden für die HTML-Ausgaben (s. SYSMON_ShowValuesHTML) benötigt.
:Alle Parameter sind nicht optional!
:Es ist wichtig, dass die angegebenen Befehle schnell ausgeführt werden, denn in dieser Zeit wird der gesamte FHEM-Server blockiert!
:Werden Ergebnisse der lang laufenden Operationen benötigt, sollten diese z.B als CRON-Job eingerichtet werden und in FHEM nur die davor gespeicherten Ausgaben visualisiert.

:Beispiel: Anzeige der vorliegenden Paket-Aktualisierungen für das Betriebssystem:
:In einem cron-Job wird folgendes täglich ausgeführt:
:apt-get upgrade --dry-run| perl -ne '/(\d*)\s[upgraded|aktualisiert]\D*(\d*)\D*install|^ \S+.*/ and print "$1 aktualisierte, $2 neue Pakete"' 2>/dev/null > /opt/fhem/data/updatestatus.txt
:Das Attribute uder-defined wird auf
:sys_updates:1440:System Aktualisierungen:cat /opt/fhem/data/updatestatus.txt
:gesetzt. Danach wird die Anzahl der verfügbaren Aktualisierungen täglich als Reading 'sys_updates' protokolliert.

*disable
:Mögliche Werte: 0,1. Bei 1 wird die Aktualisierung gestoppt.

==Plots==

Für dieses Modul sind bereits einige gplot-Dateien vordefiniert:

:FileLog-Versionen:
::SM_RAM.gplot
::SM_CPUTemp.gplot
::SM_FS_root.gplot
::SM_FS_usb1.gplot
::SM_Load.gplot
::SM_Network_eth0.gplot
::SM_Network_eth0t.gplot
::SM_Network_wlan0.gplot
::SM_CPUStat.gplot
::SM_CPUStatSum.gplot
::SM_CPUStatTotal.gplot
::SM_power_ac.gplot
::SM_power_usb.gplot
::SM_power_battery.gplot
:DbLog-Versionen:
::SM_DB_all.gplot
::SM_DB_CPUFreq.gplot
::SM_DB_CPUTemp.gplot
::SM_DB_Load.gplot
::SM_DB_Network_eth0.gplot
::SM_DB_RAM.gplot

==Methoden==

===HTML-Ausgabe===
HTML-Ausgabe-Methode (für ein Weblink): SYSMON_ShowValuesHTML(<SYSMON-Instanz>[,<Liste>])

Das Modul definiert eine Funktion, die ausgewählte Readings in HTML-Format ausgibt.
Als Parameter wird der Name des definierten SYSMON-Geräts erwartet.
Der zweite Parameter ist optional und gibt eine Liste der anzuzeigenden Readings im Format <ReadingName>[:<Comment>[:<Postfix>]] an.
Dabei gibt ReadingName den anzuzeigenden Reading an, der Wert aus Comment wird als der Anzeigename verwendet und Postfix wird nach dem einheitlichen Wert angezeigt (so können z.B. Einheiten wie MHz angezeigt werden).
Falls kein Comment angegeben ist, wird eine intern vordefinierte Beschreibung angegeben. Bei benutzerdefinierbaren Readings wird ggf. Comment aus der Definition verwendet.
Wird keine Liste angegeben, wird eine vordefinierte Auswahl verwendet (alle Werte).

<pre>define sysv1 weblink htmlCode {SYSMON_ShowValuesHTML('sysmon')}
define sysv2 weblink htmlCode {SYSMON_ShowValuesHTML('sysmon', ('date:Datum', 'cpu_temp:CPU Temperatur: °C', 'cpu_freq:CPU Frequenz: MHz'))}
</pre>

===Text-Ausgabe===

Text-Ausgabe-Methode: SYSMON_ShowValuesText(<SYSMON-Instance>[,<Liste>])

Analog SYSMON_ShowValuesHTML, jedoch formatiert als reines Text.

===Readings-Werte mit Perl lesen===
SYSMON_getValues([<Liste der gewünschten Schlüssel>])

Liefert ein Hash-Ref mit den gewünschten Werten. Wenn keine Liste (array) übergeben wird, werden alle Werte geliefert.

==Beispielkonfiguration==

# Modul-Definition
define sysmon SYSMON 1 1 1 10
#attr sysmon event-on-update-reading cpu_temp,cpu_temp_avg,cpu_freq,eth0_diff,loadavg,ram,^~ /.*usb.*,~ /$
attr sysmon event-on-update-reading cpu_temp,cpu_temp_avg,cpu_freq,eth0_diff,loadavg,ram,fs_.*,stat_cpu_percent
attr sysmon filesystems fs_boot:/boot,fs_root:/:Root,fs_usb1:/media/usb1:USB-Stick
attr sysmon network-interfaces eth0:eth0:Ethernet,wlan0:wlan0:WiFi
attr sysmon group RPi
attr sysmon room 9.03_Tech

# Log
define FileLog_sysmon FileLog ./log/sysmon-%Y-%m.log sysmon
attr FileLog_sysmon group RPi
attr FileLog_sysmon logtype SM_CPUTemp:Plot,text
attr FileLog_sysmon room 9.03_Tech

# Visualisierung: CPU-Temperatur
define wl_sysmon_temp SVG FileLog_sysmon:SM_CPUTemp:CURRENT
attr wl_sysmon_temp group RPi
attr wl_sysmon_temp label "CPU Temperatur: Min $data{min2}, Max $data{max2}, Last $data{currval2}"
attr wl_sysmon_temp room 9.03_Tech

# Visualisierung: Netzwerk-Datenübertragung für eth0
define wl_sysmon_eth0 SVG FileLog_sysmon:SM_Network_eth0:CURRENT
attr wl_sysmon_eth0 group RPi
attr wl_sysmon_eth0 label "Netzwerk-Traffic eth0: $data{min1}, Max: $data{max1}, Aktuell: $data{currval1}"
attr wl_sysmon_eth0 room 9.03_Tech

# Visualisierung: Netzwerk-Datenübertragung für wlan0
define wl_sysmon_wlan0 SVG FileLog_sysmon:SM_Network_wlan0:CURRENT
attr wl_sysmon_wlan0 group RPi
attr wl_sysmon_wlan0 label "Netzwerk-Traffic wlan0: $data{min1}, Max: $data{max1}, Aktuell: $data{currval1}"
attr wl_sysmon_wlan0 room 9.03_Tech

# Visualisierung: CPU-Auslastung (load average)
define wl_sysmon_load SVG FileLog_sysmon:SM_Load:CURRENT
attr wl_sysmon_load group RPi
attr wl_sysmon_load label "Load Min: $data{min1}, Max: $data{max1}, Aktuell: $data{currval1}"
attr wl_sysmon_load room 9.03_Tech

# Visualisierung: RAM-Nutzung
define wl_sysmon_ram SVG FileLog_sysmon:SM_RAM:CURRENT
attr wl_sysmon_ram group RPi
attr wl_sysmon_ram label "RAM-Nutzung Total: $data{max1}, Min: $data{min2}, Max: $data{max2}, Aktuell: $data{currval2}"
attr wl_sysmon_ram room 9.03_Tech

# Visualisierung: Dateisystem: Root-Partition
define wl_sysmon_fs_root SVG FileLog_sysmon:SM_FS_root:CURRENT
attr wl_sysmon_fs_root group RPi
attr wl_sysmon_fs_root label "Root Partition Total: $data{max1}, Min: $data{min2}, Max: $data{max2}, Aktuell: $data{currval2}"
attr wl_sysmon_fs_root room 9.03_Tech

# Visualisierung: Dateisystem: USB-Stick
define wl_sysmon_fs_usb1 SVG FileLog_sysmon:SM_FS_usb1:CURRENT
attr wl_sysmon_fs_usb1 group RPi
attr wl_sysmon_fs_usb1 label "USB1 Total: $data{max1}, Min: $data{min2}, Max: $data{max2}, Aktuell: $data{currval2}"
attr wl_sysmon_fs_usb1 room 9.03_Tech

# Anzeige der Readings zum Einbinden in ein 'Raum'.
define SysValues weblink htmlCode {SYSMON_ShowValuesHTML('sysmon')}
attr SysValues group RPi
attr SysValues room 9.03_Tech

# Anzeige CPU Auslasung
define wl_sysmon_cpustat SVG FileLog_sysmon:SM_CPUStat:CURRENT
attr wl_sysmon_cpustat label "CPU(min/max): user:$data{min1}/$data{max1} nice:$data{min2}/$data{max2} sys:$data{min3}/$data{max3} idle:$data{min4}/$data{max4} io:$data{min5}/$data{max5} irq:$data{min6}/$data{max6} sirq:$data{min7}/$data{max7}"
attr wl_sysmon_cpustat group RPi
attr wl_sysmon_cpustat room 9.99_Test
attr wl_sysmon_cpustat plotsize 840,420
define wl_sysmon_cpustat_s SVG FileLog_sysmon:SM_CPUStatSum:CURRENT
attr wl_sysmon_cpustat_s label "CPU(min/max): user:$data{min1}/$data{max1} nice:$data{min2}/$data{max2} sys:$data{min3}/$data{max3} idle:$data{min4}/$data{max4} io:$data{min5}/$data{max5} irq:$data{min6}/$data{max6} sirq:$data{min7}/$data{max7}"
attr wl_sysmon_cpustat_s group RPi
attr wl_sysmon_cpustat_s room 9.99_Test
attr wl_sysmon_cpustat_s plotsize 840,420
define wl_sysmon_cpustatT SVG FileLog_sysmon:SM_CPUStatTotal:CURRENT
attr wl_sysmon_cpustatT label "CPU-Auslastung"
attr wl_sysmon_cpustatT group RPi
attr wl_sysmon_cpustatT plotsize 840,420

# Anzeige Stromversorgung AC
define wl_sysmon_power_ac SVG FileLog_sysmon:SM_power_ac:CURRENT
attr wl_sysmon_power_ac label "Stromversorgung (ac) Spannung: $data{min1} - $data{max1} V, Strom: $data{min2} - $data{max2} mA"
attr wl_sysmon_power_ac room Technik
attr wl_sysmon_power_ac group system

# Anzeige Stromversorgung Battery
define wl_sysmon_power_bat SVG FileLog_sysmon:SM_power_battery:CURRENT
attr wl_sysmon_power_bat label "Stromversorgung (bat) Spannung: $data{min1} - $data{max1} V, Strom: $data{min2} - $data{max2} mA"
attr wl_sysmon_power_bat room Technik
attr wl_sysmon_power_bat group system

==Beispielkonfiguration Remote System per SSH==
Hier bedarf es etwas Vorarbeit damit man sich per SSH verbinden kann. Hier am Beispiel geht es um einen kleinen Orange Pi als Snapcast Audioreciver. Dazu muss man ein passwortlosen Login per authkey ermöglichen. Dieser wird auf dem FHEM Server als fhem User mit folgendem Befehl erzeugt:

ssh-keygen -t rsa

Auf dem zu überwachenden Gerät (Hier der OPi) wird ein User zum daten abfragen angelegt.

adduser fhemremote

Nun muss noch der Key vom FHEM Server zum OPi übertragen werden (auf dem FHEM Server als fhem User ausführen):

ssh-copy-id fhemremote@orangeaudio1

Jetzt noch einmal das Passwort des fhemremote User eingeben und die Vorbereitung ist geschafft.

Jetzt kann das Device angelegt werden. Ich überwache zusätzlich noch die Installierbaren Pakete einmal am Tag.

define systemSysmonOrangeAudio1 SYSMON ssh:fhemremote@orangeaudio1 1 10 10 10
attr systemSysmonOrangeAudio1 room Audio,Systemgeräte
attr systemSysmonOrangeAudio1 user-defined apt_upgradeable_pkg:1440:Upgradable Packages in Apt:apt-get -q -y --ignore-hold --allow-change-held-packages --allow-unauthenticated -s dist-upgrade | /bin/grep ^Inst | wc -l

MQTT

2020-06-11T12:27:40Z

Rspecht: /* OpenMQTTGateway */

MQTT ist ein Protokoll ("Message Queue Telemetry Transport"), mit dem Daten und Befehle zwischen verschiedenen Geräten ausgetauscht werden. Die Kommunikation erfolgt dabei über einen zentralen MQTT-Server, in alter Nomenklatur auch ''Broker'' genannt.

MQTT wurde entwickelt, um möglichst effizient, sicher und mit wenig Datenlast zu kommunizieren. MQTT ist nachrichtenorientiert, daher muss ein Client nicht beständig beim Server anfragen, ob neue Daten vorliegen. Heute findet sich MQTT vor allem im Bereich des ''Internet of Things'' (IoT). MQTT kann leicht mit FHEM verbunden werden, ohne dass dabei größerer CPU- oder Datenverbrauch entsteht.

== Eine sehr kurze Einführung in MQTT ==
Die folgende Einführung kann eine vollwertige Einleitung wie beispielsweise [https://github.com/mqtt/mqtt.github.io/wiki diese Wikieinträge] nicht ersetzen.

Bei MQTT findet die nachrichtenbasierte Kommunikation zwischen einzelnen Teilnehmern<ref>Teilnehmer in diesem Sinne kann ein Stück Hardware mit einer MQTT-fähigen firmware sein, ein auf einem Computer laufendes Script (einschließlich eines MQTT-Server-Dienstes wie ''mosquitto'' oder ''MQTT2_SERVER'', kurz: alles mögliche sein. Dadurch kann auch ein einzelner Computer unter mehreren ClientID's am MQTT-Datenaustausch beteiligt sein.</ref> in der Regel nicht direkt statt. Stattdessen werden alle Nachrichten von einem Teilnehmer an einen Serverdienst, den MQTT-Server (früher ''Broker'' genannt) übergeben, der dann dafür sorgt, dass die Nachricht an alle (berechtigten) anderen Teilnehmer verteilt wird, die sich für derartige Nachrichten "interessieren". Wenn also ein Teilnehmer ohne Server-Funktion (Client) Daten von einem bestimmten anderen Teilnehmer (anderer Client) empfangen will, muss es vorher dem MQTT-Server (Broker) mitteilen, dass er die Nachrichten dieses anderen Teilnehmers abonniert (deshalb wird dieser Vorgang als ''subscribe'' bezeichnet). Im IoT ist besonders interessant, dass Sender und Empfänger von Nachrichten durch den MQTT-Server vollständig entkoppelt werden können - jemand, der Daten bereit stellt, muss sich also nicht darum kümmern, wer diese Daten empfängt<ref>Aufgrund dieser Funktionsweise sollte allerdings darauf geachtet werden, die Möglichkeiten des jeweiligen Servers zur Sicherung der Daten gegen unberechtigten Zugriff zu nutzen, insbesondere wenn die Art der Daten oder die sich hierdurch ergebenden Möglichkeiten, z.B. Schaltvorgänge in der realen Welt auszulösen, dies notwendig macht!</ref>.

Eine Nachricht besteht im Wesentlichen aus den folgenden Elementen:
*ClientID - das ist die Kennung des Senders einer Nachricht<ref>Diese kann sich bei der Weitergabe der Nachricht ändern: Zunächst sendet ein Client eine Nachricht unter seiner ClientID, der MQTT-Server wird diese dann in der Regel durch seine Kennung ersetzten, wenn er die Nachricht an einen Abonnenten - der auch ein weiterer MQTT-Server sein kann - weitergibt.</ref>
*Topic - das ist die Adresse, an die eine Nachricht gesendet wird, bzw. von wo sie abgeholt werden kann (so ähnlich wie ein Postfach in der realen Welt). Topics sind einfache Strings, die mit Schrägstrichen getrennt werden (keine Leerzeichen und nur sehr wenige Sonderzeichen erlaubt). Ein Topic könnte beispielhaft so lauten: <code>zuHause/1OG/Kueche/Licht/state</code>. Diese Topics beinhalten also eine Hierarchie der Objekte - hier im Beispiel sind sie zuerst danach sortiert, ob sie sich zu Haus befinden, dann wird nach Stockwerken sortiert und im ersten Stock schaut man auf die Küche sowie das dort vorhandene Licht.
*Payload - das ist der Inhalt der Nachricht, oft handelt es sich um Befehle oder Daten.
*Quality of Service - soll geprüft werden, ob die Nachricht zugestellt wurde und wenn ja, mit welcher "Tiefe"?
*Retained Message.
Details bitte in der oben genannten Einführung nachlesen.

MQTT kommuniziert üblicherweise über Port 1883, es können aber unter derselben Netzwerkadresse an unterschiedlichen Ports auch mehrere Serverdienste bereitstehen.

== Installation in FHEM ==
Um MQTT in FHEM zu nutzen, benötigt man (mindestens) einen MQTT-Server. Es gibt zwei Möglichkeiten: Man kann FHEM-externe Server-Software (oder auch einen oder mehrere im Internet bereitstehende MQTT-Server) verwenden oder man kann die MQTT-Serverkomponente aktivieren, die mit {{Link2CmdRef|Anker=MQTT2_SERVER|Lang=en|Label=MQTT2_SERVER}} in FHEM direkt bereitsteht. Hier werden kurz beide Installationswege erläutert, zwingend ist nur einer, da eben mindestens ein MQTT-Serverdienst aktiv sein muß.

Die nachfolgenden Schaubilder zeigen schematisch die in FHEM zur Verfügung stehenden Wege der Einbindung von Hard- und/oder Softwarekomponenten, die über das MQTT-Protokoll Daten austauschen.
<gallery>
Datei:Mqtt2 server.png|Datenaustausch mit MQTT-Geräten, wenn MQTT2_SERVER als internem MQTT-Serverdienst verwendet wird
Datei:Mqtt2 client v extern server.png|Datenaustausch mit MQTT-Geräten, wenn MQTT2_CLIENT iVm. mosquitto als externem MQTT-Serverdienst verwendet wird
Datei:00 mqtt pm.png|Datenaustausch mit MQTT-Geräten, wenn das Modul ''MQTT'' (00_MQTT.pm) iVm. mosquitto als externem MQTT-Serverdienst verwendet wird
</gallery>
=== FHEM als MQTT-Server ===
Die mit dem Modul {{Link2CmdRef|Anker=MQTT2_SERVER|Lang=en|Label=MQTT2_SERVER}} bereitstehende Serverkomponente kann z.B. wie folgt aktiviert werden:
defmod myBroker MQTT2_SERVER 1883 global
Dieses [[Gerät]] übernimmt dann die Kommunikation mit den externen Clients (und wird von diesen behandelt, wie jeder andere MQTT-Server auch<ref>Bitte beachten Sie, dass (Stand: Juni 2019) MQTT2_SERVER nicht alle features des MQTT-Protokolls unterstützt.</ref>) und verteilt die eingehenden Nachrichten als IO-Device<ref>im Sinne des [[DevelopmentModuleIntro#Zweistufiges Modell für Module|2-stufigen Modulkonzepts]]</ref> für die Client-Module [[MQTT2_DEVICE]]<ref>Die Zahl 2 in den Modulnamen verweist nur darauf, dass es sich um eine neuere Modulfamilie handelt; die Kommunikation mit den externen Komponenten unterscheidet sich nicht zu den älteren Modulen, die vor dem Jahr 2018 genutzt werden konnten.</ref> und {{Link2CmdRef|Anker=MQTT_GENERIC_BRIDGE|Lang=de|Label=MQTT_GENERIC_BRIDGE}}.
Ein weiterer Vorteil dieser Lösung besteht darin, dass man ein MQTT2_SERVER-Device mit Hilfe von [[allowed]] absichern kann, was auch SSL-verschlüsselte Kommunikation ermöglicht. '''Hinweis:''' In diesem Fall muss User bzw. Passwort auch in den entsprechenden Geräten eingetragen werden.

{{Hinweis|Wenn Sie beabsichtigen, diese Variante zu verwenden, sollten Sie als nächstes die [[MQTT2-Module - Praxisbeispiele|Praxisbeispiele zu den MQTT2-Modulen]] lesen, und ggf. später wieder hierher zurückkehren. Dort findet sich auch ein Abschnitt zu dem auf den Grafiken zu den MQTT2-IO-Modulen enthaltenen [[MQTT2-Module_-_Praxisbeispiele#bridgeRegexp|bridgeRegexp]]-Attribut.}}

=== FHEM-externer Broker ===
==== Beispiel: mosquitto ====
Eine gern verwendete MQTT-Server-Software ist [http://mosquitto.org Mosquitto]. Sie kann ohne weiteres auf dem Raspberry Pi, der bereits eine FHEM-Installation besitzt, installiert werden und wird keine größere CPU- oder Netzwerklast verursachen.

Eine Anleitung zur Installation findet sich beispielsweise in diesem [http://blog.wenzlaff.de/?p=6487 Blogeintrag]. Im wesentlichen beschränkt sich die Installation eines MQTT Servers aber auf wenige Arbeitsschritte. Bei ''stretch'' ist ''Mosquitto'' bereits in der Distribution enthalten und kann - zusammen mit dem client Befehl ''mosquito_sub'', der weiter unten benötigt wird, wie folgt installiert und getestet werden<ref>Die für den Betrieb mit FHEM erforderlichen Perl-Module sind teilweise (noch) nicht in den Paketquellen verfügbar. Sie können dennoch statt mit cpan auch als Debian-Paket mit Hilfe von ''dh-make-perl'' installiert werden, wobei vorab das in den Paketquellen bereits vorhandene ''libmodule-pluggable-perl'' installiert werden sollte: 
<code>sudo apt-get install dh-make-perl 
dh-make-perl --install --cpan Net::MQTT::simple 
dh-make-perl --install --cpan Net::MQTT::Constants 
sudo dpkg -i libnet-mqtt-simple-perl*.deb 
sudo dpkg -i libnet-mqtt-perl*.deb</code></ref>:
{{Randnotiz|RNTyp=g|RNText=Für ältere Distributionen (hier am Beispiel von ''jessie'') muß ggf. aus einer zusätzlichen Paketquelle installiert werden:
wget http://repo.mosquitto.org/debian/mosquitto-repo.gpg.key
sudo apt-key add mosquitto-repo.gpg.key
cd /etc/apt/sources.list.d/
sudo wget http://repo.mosquitto.org/debian/mosquitto-jessie.list
sudo apt-get update
Danach kann die eigentliche Installation durchgeführt werden wie links für ''stretch'' beschrieben.}}<source lang="bash">
sudo apt-get install mosquitto mosquitto-clients

# MQTT Server Test
sudo service mosquitto status

# Start / Stop des Servers
sudo service mosquitto stop
sudo service mosquitto start
</source>
Danach ist der RPi mit <nowiki>shutdown restart</nowiki> neu zu starten.

==== IO-Module für externe MQTT-Server ====
Damit FHEM mit dem MQTT-Server kommuniziert, muss noch ein IO-Device angelegt werden. Dabei stehen zwei Varianten zur Wahl, das Modul [[MQTT (Modul)|MQTT]] oder seit Ende 2018 [[MQTT2_CLIENT]].

Beide Module können auch dazu genutzt werden, um Daten zwischen zwei FHEM-Installationen auszutauschen, insbesondere kann auch 00_MQTT.pm als Client für einen MQTT2_SERVER eingesetzt werden, der '''auf der anderen Installation''' als MQTT-Serverdienst eingerichtet ist. Darüber hinaus bestehen eine Vielzahl von Kombinationsmöglichkeiten der diversen IO-Module, wenn die Installation auf mehrere Server verteilt ist.
Auf einer FHEM-Installation wird jedoch in der Regel nur eines der IO-Module benötigt.

===== MQTT2_CLIENT =====
Ein MQTT2_CLIENT-IO-Device wird z.B. angelegt mit
define myBroker MQTT2_CLIENT 10.0.0.5:1883 ## bitte EIGENE IP-Adresse eintragen

{{Hinweis|Wenn Sie beabsichtigen, MQTT2_CLIENT zu verwenden, sollten Sie zuerst die [[MQTT2-Module - Praxisbeispiele|Praxisbeispiele zu den MQTT2-Modulen]] lesen, und dabei die Hinweise im Artikel [[MQTT2_CLIENT]] beachten.}}

Ein MQTT2_CLIENT-Device kann ebenfals mit Hilfe von [[allowed]] abgesichert werden, um z.B. SSL-verschlüsselte Kommunikation zu ermöglichem. Client-Module zu diesem IO-Typ sind wiederum [[MQTT2_DEVICE]] und {{Link2CmdRef|Anker=MQTT_GENERIC_BRIDGE|Lang=de|Label=MQTT_GENERIC_BRIDGE}}.

===== MQTT (Modul) =====
Vorab werden für diese Variante weitere Perl-Pakete benötigt:
<source lang="bash">
# Perl Version ausgeben
perl -v
# Perl MQTT Module nachinstallieren (läuft ein paar Minuten)
sudo cpan install Net::MQTT:Simple
sudo cpan install Net::MQTT:Constants
</source>

Ein IO-Device des Typs MQTT wird z.B. angelegt mit
{{Randnotiz|RNTyp=g|RNText=Sofern der Broker mit FHEM über localhost kommuniziert, kann als IP 127.0.0.1 verwendet werden.}}
define myBroker MQTT 10.0.0.5:1883 ## bitte EIGENE IP-Adresse eintragen
{{Randnotiz|RNTyp=g|RNText=Außerhalb der offiziellen Quellen sind auch einige ältere Varianten des Moduls MQTT_DEVICE verfügbar, die jeweils spezielle Anforderungen (z.B. für Zigbee2mqtt) separat abbilden. Diese werden hier nicht gesondert behandelt, da solche Sonderfälle heute generischer und einfacher durch den Einsatz von MQTT2_DEVICE abzubilden sind.}}Client-Device-Module zum Modul [[MQTT (Modul)|MQTT]] sind [[MQTT_DEVICE]], {{Link2CmdRef|Anker=MQTT_BRIDGE|Lang=de|Label=MQTT_BRIDGE}} (veraltet) und {{Link2CmdRef|Anker=MQTT_GENERIC_BRIDGE|Lang=de|Label=MQTT_GENERIC_BRIDGE}}. Da ''MQTT_DEVICE'' payload im JSON-Format (im Unterschied zu MQTT2_DEVICE) nicht selbst verarbeiten kann wird hier zusätzlich das Modul {{Link2CmdRef|Anker=expandJSON|Lang=de|Label=expandJSON}} benötigt, um den {{Link2Forum|Topic=66761|LinkText=JSON String auszuwerten}}.

=== Performancefragen... ===
...oder was sollte man als Lösung wählen, wenn man in die MQTT-Welt einsteigt<ref>vgl. hierzu diesen {{Link2Forum|Topic=94768|Message=875714|LinkText=Beitrag}} von Rudolf König</ref>?
Grundsätzlich sollte man davon ausgehen, dass innerhalb von FHEM die Verarbeitung derselben Daten näherungsweise denselben Aufwand bedeuten, unabhängig davon, welche der Implementierungen (''MQTT2_CLIENT'', ''MQTT'' oder ''MQTT2_SERVER'') man konkret wählt.
Ein externer Broker hat daher vor allem dann Vorteile, wenn die MQTT Daten überwiegend für was anderes (nicht FHEM) verwendet werden, oder MQTT zweckentfremdet wird (wie z.Bsp. für Musikübertragung). Nutzt man das MQTT-Protokoll dagegen vorwiegend innerhalb von FHEM, ist eher der Einsatz von MQTT2_SERVER in Betracht zu ziehen. Dieser soll Anfängern die Anbindung von MQTT Geräten in FHEM einfacher machen. Wer später merkt, dass er doch einen externen Broker benötigt, kann dann immer noch auf MQTT2_CLIENT in Verbindung mit einem anderen Broker wechseln.
Dagegen ist der Weg von MQTT_DEVICE zu MQTT2_DEVICE mit erheblich mehr Aufwand verbunden.

=== Kommunikation zu sonstigen FHEM-Geräten über MQTT ===

Möchte man Daten von einem [[Gerät]] (im FHEM-Sinn), das '''nicht''' vom Typ ''MQTT2_DEVICE'' oder ''MQTT_DEVICE'' (je nach IO-Modul) ist, per MQTT-Protokoll versenden (z.B. für eine andere Visualisierungslösung als FHEMWEB, oder als FHEM2FHEM-Ersatzlösung), oder diese sonstigen Geräte über MQTT-Anweisungen von außen steuern können, hat man mehrere Möglichkeiten:

==== MQTT_GENERIC_BRIDGE ====
Das Modul {{Link2CmdRef|Anker=MQTT_GENERIC_BRIDGE|Lang=en|Label=MQTT_GENERIC_BRIDGE}} ermöglicht es, sein jeweiliges IO-Modul-Gerät zu nutzen, um diesen Kommunikationsweg für beliebig viele andere FHEM-Geräte bereitzustellen. Dabei erfolgt am MQTT_GENERIC_BRIDGE-Gerät selbst nur eine Basiskonfiguration, im Übrigen durch Attribute an dem jeweiligen Gerät selbst. So kann z.B. ein Aktor des Typs [[CUL_HM]] an- oder ausgeschaltet werden oder auch einfach nur seinen aktuellen Schaltzustand per MQTT-Protokoll publizieren.

Dieses Modul kann seit November 2018 mit allen drei IO-Modul-Varianten zusammen eingesetzt werden, also sowohl mit ''MQTT2_SERVER'' bzw. ''MQTT2_CLIENT'' oder ''MQTT'' (00_MQTT.pm).

Dabei sollte man jedoch beachten, dass zur Verwendung mit den MQTT2-IO's unbedingt die autocreate-Funktion des betreffenden IOs ausgeschaltet wird und dies auch bleibt<ref>siehe dazu diesen {{Link2Forum|Topic=95341|LinkText=Thread}} zu den technischen Hintergründen</ref>! Weiter wird das Perl-Modul ''libmodule-pluggable-perl'' benötigt<ref>Dieses kann über <code>apt-get install libmodule-pluggable-perl</code> installiert werden</ref>, damit im Hintergrund auch das Modul [[MQTT (Modul)|MQTT]] geladen werden kann. Damit gelten auch für diesen Modul die Installationsvoraussetzungen für [[MQTT#MQTT_.28Modul.29|MQTT]]!

Anwendungsfälle und -beispiele für das Modul sind diesem {{Link2Forum|Topic=91642|LinkText=Thread}} zu entnehmen.

==== MQTT_BRIDGE ====
Dieses Modul kann nur zusammen mit einem IO-Gerät des Typs [[MQTT (Modul)|MQTT]] verwendet werden. Dabei wird pro weiterzuleitendem anderen FHEM-Gerät eine eigene Instanz dieses Moduls verwendet. Auf den Einsatz dieser Option sollte in neuen Installationen zugunsten von ''MQTT_GENERIC_BRIDGE'' verzichtet werden.

==== Per publish-Befehl am IO-Gerät ====
Alle drei IO-Module kennen direkte ''publish''-Anweisungen, mit deren Hilfe beliebige ''payloads'' an beliebige ''topics'' gesendet werden können. Dies kann man z.B. in einem [[notify]] oder [[at]] nutzen, um einzelne Events zu publishen oder Werteanfragen abzusetzen.

Hier eine regelmäßige Werteabfrage auf einen [[EBUS-MQTT2|ebus]]:
defmod get_ebus_updates at +*00:15:00 set ebusMQTT publish ebusd/430/Hc1HeatCurve/get;
set ebusMQTT publish ebusd/430/HwcTempDesired/get;
...

==== RAW-Events am IO-Gerät (MQTT2.*) ====
Bei beiden MQTT2-IO-Modulen (MQTT2_SERVER und MQTT2_CLIENT) kann per [[Regulärer Ausdruck|regulärem Ausdruck]] festgelegt werden, welche Nachrichten ein Event erzeugen sollen, auf das dann wieder z.B. mit einem [[notify]] reagiert werden kann, z.B. um beliebige Schaltaktionen auszulösen.

== MQTT-Clients (Beispiele) ==

===Arduino-library===
Zur Kommunikation mit dem Broker von Seiten eines [[Arduino|Arduinos]] mit selbst erstellten Sketches böte sich der PubSubClient an.

===PC-Software===
Um die Funktionalität des Brokers zu testen kann z.B. ein Analyse-Tool wie MQTT.fx verwendet werden, oder die im Paket ''mosquitto-clients'' enthaltenen Linux-Kommandozeilen-Programme ''mosquitto_sub'' und ''mosquitto_pub''. Letzterer könnte z.E. auch aus beliebigen ''shell-scripten'' heraus aufgerufen werden. Als Perl-Bibliothek steht alternativ z.B. [https://metacpan.org/pod/distribution/AnyEvent-MQTT/bin/anyevent-mqtt-pub anyevent-mqtt-pub] zur Verfügung.

=== Tasmota ===
Eine derzeit oft genutzte Möglichkeit für MQTT bilden die [[Sonoff]]-Geräte und weitere [[ESP8266]]-basierte Hardware, die unter vielen Handelsnamen erhältlich sind. Werden diese mit Tasmota ('''T'''heo '''A'''rends '''S'''onoff '''M'''QTT '''O'''ver '''T'''he '''A'''ir - einer offenen Firmware von [https://github.com/arendst arendst]) geflasht, so kommunizieren sie über MQTT. Um diese Geräte einzubinden, ist wie folgt vorzugehen. Zuerst ist ein Serverdienst (Broker) bereitzustellen, wie oben beschrieben.

Unter Sonoff sind einige Topics voreingestellt. arendst stellt insbesondere drei Topic-Präfixe bereit, die seiner Meinung jedes Topic einleiten sollen (in den Eingabemasken als "%prefix%" notiert). Das sind einmal Kommandos (abgekürzt als cmnd), die dazu dienen, Befehle auszuführen. Daten werden mit tele und stat übertragen. Ein Topic besteht dann zuerst aus diesem Präfix und danach dem eigentlichen Topic. Wer also beispielsweise einem Sonoff_Switch einen Befehl senden will, sollte als Topic cmnd/Sonoff_Switch wählen. Wenn der Switch ein- und ausgeschaltet werden kann, muss der Topic noch das Wort POWER enthalten (in MQTT werden viele Kennworte komplett groß geschrieben). Der Topic lautet damit vollständig "cmnd/Sonoff_Switch/POWER/set"

{{Randnotiz|RNTyp=g|RNText=Dabei ist darauf zu achten, dass für den Parameter ''topic = %topic% (sonoff)'' statt ''sonoff'' ein gerätespezifischer eigener Name eingetragen wird. Hierzu kann man z.B. auch die dynamisch aus der Chip-ID erzeugte Kennung ''DVES_%06X'' verwenden, indem man die unter ''client (DVES_8BABA9)'' zu findende Angabe kopiert. Die eigentliche Umbenennung zu einem "sprechenden Namen" kann dann innerhalb von FHEM - mittels ''rename'' oder ggf. mit einem ''alias'' - erfolgen.}}

Link zum Forum: {{Link2Forum|Topic=27532|LinkText=MQTT FHEM Einrichtung}} (hier als ''MQTT_DEVICE''!):

### FHEM Device mit MQTT verbinden ###
define Sonoff_Switch MQTT_DEVICE
attr Sonoff_Switch IODev myBroker
attr Sonoff_Switch devStateIcon ON:rc_GREEN:OFF OFF:rc_RED:ON
attr Sonoff_Switch icon hue_filled_br30
attr Sonoff_Switch publishSet ON OFF cmnd/TestSwitch/POWER
attr Sonoff_Switch room MQTT
attr Sonoff_Switch subscribeReading_Licht stat/Sonoff_Switch/POWER
attr Sonoff_Switch subscribeReading_Sensor tele/Sonoff_Switch/SENSOR
attr Sonoff_Switch subscribeReading_Status stat/Sonoff_Switch/STATUS
attr Sonoff_Switch webCmd ON:OFF

Der hier dargestellte Beispielcode realisiert die Kommunikation zwischen FHEM und dem sonoff Modul via MQTT Broker. Zu beachten ist hier, dass '''subscribeReading_Licht''' und '''subscribeReading_Status''' unterschiedliche Syntax des Topic Strings haben!

=== OpenMQTTGateway ===
Um verschiedene Systeme wie BLE usw. auf MQTT zu bringen bietet sich OpenMQTTGateway an.

Ich habe es für BLE kompiliert und auf einem ESP32 installiert. Hierzu braucht man nur das blanke Board ohne Zusatzhardware.

Weiter infos hier: [https://github.com/1technophile/OpenMQTTGateway]

In FHEM wird das ganze über den eigenen Broker oder einen extern Broker (z.B.: Mosquitto) eingebunden.

Zusätzlich legt ihr noch ein Device hierzu an.

<code>define MQTT2_OMG1 MQTT2_DEVICE</code>

Ich habe es noch in den Raum MQTT2 geschoben.

Mit <code>set MQTT2_OMG1 attrTemplate OpenMQTTGateway_MCU</code> wird das Template festgelegt.

Aus diesem Device raus könnt ihr euch nun auch ein Dummy für z.B. einen MiFlora anlegen lassen. Das geschieht dann über <code>set MQTT2_OMG1 attrTemplate OpenMQTTGateway_BT_mi_flora_sensor</code>

== Sicherheit ==
Prinzipiell ist MQTT ebenso sicher wie eine Postkarte. Solange man es nicht extra absichert, kann jeder der, im eigenen LAN ist (und die Adresse vom Broker kennt) alle Topics mitlesen.
:<code>meinHaus/Flur/Haustuer:open / close</code>
bietet unter diesen Umständen reichlich Raum für Verbesserungen!

Abhilfe:
=== Username / Passwort ===
Zunächst kann man erst mal einen Username / Passwort vergeben, was alle IO-Device-Module unterstützen. Da ist zwar auch noch lange nicht sicher, aber zumindest steigert es den Aufwand schon mal. Jetzt muss man zumindest schon mal Pakete sniffen und verstehen, um unbefugt zu lesen oder gar zu publishen.

=== TLS ===
Um wirklich sicher zu werden, führt kein Weg an TLS vorbei.

Der MQTT-Client in [[#Tasmota|Tasmota]] (für ESP8266) kann mit TLS betrieben werden, vgl. [https://github.com/arendst/Tasmota/wiki/TLS Beschreibung im Tasmota-Wiki].

Leider kann z.B. ein Arduino das schlicht nicht mehr, da die einfacheren Modelle nicht über ausreichend Speicher und die Rechenleistung verfügen.

'''(Hier fehlt eine Anleitung für allowed usw.)'''

== Probleme ==
=== Anweisung und Ergebnis weichen voneinander ab ===
In der Regel melden MQTT-fähige Geräte entweder den Erhalt einer Nachricht zurück oder den Status nach Durchführung der in der ''payload'' enthaltenen Anweisung. Dabei findet aber in der Regel beim Empfänger eine Verarbeitung der Nachricht statt, ggf. wird diese auch weitergesendet und nochmals verarbeitet, bevor dann ggf. eine Rückmeldung des neuen Status an den MQTT-Server erfolgt. Handelt es sich um einfache on/off-Befehle, bleibt Anweisung und Ergebnis in der Regel identisch. Bei anderen, namentlich bei Dimmer-Werten, kann es zu Rundungsdifferenzen bei nummerischen Werten kommen. So kann z.B. ein Dimm-Wert von 70% gesetzt werden, zürückgemeldet wird dann aber 72% (oder 67%).
Dies ist technisch bedingt, vermeiden kann das jedoch in aller Regel nur der Autor der jeweiligen software/firmware auf dem "rechnenden" Gerät.

=== Unbeabsichtigte Schleifen ===
Durch Fehler in der topic-Struktur können unbeabsichtigte Schleifen entstehen, die FHEM komplett blockieren können. Es ist unbedingt darauf zu achten, dass die jeweiligen Sende- und Empfangs-topics andere sind!

== Links ==
* [http://mqtt.org Offizielle Homepage von MQTT, englisch]
* [http://www.hivemq.com/blog/mqtt-essentials-part-1-introducing-mqtt Sehr gute Einführung, englisch, sind 5 lesenswerte Teile]
* [https://www.heise.de/developer/artikel/MQTT-Protokoll-fuer-das-Internet-der-Dinge-2168152.html Ein Exkurs von Heise mit Beispielen, deutsch, sehr lesenswert]
* [http://www.mqttfx.org/ MQTT FX - ein sehr praktisches Analysetool]
* {{Link2Forum|Topic=69230|LinkText=Diskussionsthread im Forum}}
* {{Link2Forum|Topic=92888|LinkText=Thread, zur Entstehungsgeschichte von MQTT2_CLIENT}}
* {{Link2Forum|Topic=93255|LinkText=Ankündigungsthread zur MQTT2-Erweiterung der MQTT_GENERIC_BRIDGE}}
* [[MQTT_Einf%C3%BChrung_Teil_2|Teil 2 der MQTT Einführung]]: Detailaspekte (vorrangig zur Modulfamilie MQTT/MQTT_DEVICE)
* [[MQTT Einführung Teil 3|Teil 3 der MQTT Einführung]]: Arduino-Client selbst programmieren

== Hinweise ==
<references />

[[Kategorie:Glossary]]
[[Kategorie:HOWTOS]]
[[Kategorie:MQTT|Einführung]]
[[Kategorie:MQTT| ]]

MQTT

2020-06-11T11:41:03Z

Rspecht: /* OpenMQTTGateway hinzugefügt */

MQTT ist ein Protokoll ("Message Queue Telemetry Transport"), mit dem Daten und Befehle zwischen verschiedenen Geräten ausgetauscht werden. Die Kommunikation erfolgt dabei über einen zentralen MQTT-Server, in alter Nomenklatur auch ''Broker'' genannt.

MQTT wurde entwickelt, um möglichst effizient, sicher und mit wenig Datenlast zu kommunizieren. MQTT ist nachrichtenorientiert, daher muss ein Client nicht beständig beim Server anfragen, ob neue Daten vorliegen. Heute findet sich MQTT vor allem im Bereich des ''Internet of Things'' (IoT). MQTT kann leicht mit FHEM verbunden werden, ohne dass dabei größerer CPU- oder Datenverbrauch entsteht.

== Eine sehr kurze Einführung in MQTT ==
Die folgende Einführung kann eine vollwertige Einleitung wie beispielsweise [https://github.com/mqtt/mqtt.github.io/wiki diese Wikieinträge] nicht ersetzen.

Bei MQTT findet die nachrichtenbasierte Kommunikation zwischen einzelnen Teilnehmern<ref>Teilnehmer in diesem Sinne kann ein Stück Hardware mit einer MQTT-fähigen firmware sein, ein auf einem Computer laufendes Script (einschließlich eines MQTT-Server-Dienstes wie ''mosquitto'' oder ''MQTT2_SERVER'', kurz: alles mögliche sein. Dadurch kann auch ein einzelner Computer unter mehreren ClientID's am MQTT-Datenaustausch beteiligt sein.</ref> in der Regel nicht direkt statt. Stattdessen werden alle Nachrichten von einem Teilnehmer an einen Serverdienst, den MQTT-Server (früher ''Broker'' genannt) übergeben, der dann dafür sorgt, dass die Nachricht an alle (berechtigten) anderen Teilnehmer verteilt wird, die sich für derartige Nachrichten "interessieren". Wenn also ein Teilnehmer ohne Server-Funktion (Client) Daten von einem bestimmten anderen Teilnehmer (anderer Client) empfangen will, muss es vorher dem MQTT-Server (Broker) mitteilen, dass er die Nachrichten dieses anderen Teilnehmers abonniert (deshalb wird dieser Vorgang als ''subscribe'' bezeichnet). Im IoT ist besonders interessant, dass Sender und Empfänger von Nachrichten durch den MQTT-Server vollständig entkoppelt werden können - jemand, der Daten bereit stellt, muss sich also nicht darum kümmern, wer diese Daten empfängt<ref>Aufgrund dieser Funktionsweise sollte allerdings darauf geachtet werden, die Möglichkeiten des jeweiligen Servers zur Sicherung der Daten gegen unberechtigten Zugriff zu nutzen, insbesondere wenn die Art der Daten oder die sich hierdurch ergebenden Möglichkeiten, z.B. Schaltvorgänge in der realen Welt auszulösen, dies notwendig macht!</ref>.

Eine Nachricht besteht im Wesentlichen aus den folgenden Elementen:
*ClientID - das ist die Kennung des Senders einer Nachricht<ref>Diese kann sich bei der Weitergabe der Nachricht ändern: Zunächst sendet ein Client eine Nachricht unter seiner ClientID, der MQTT-Server wird diese dann in der Regel durch seine Kennung ersetzten, wenn er die Nachricht an einen Abonnenten - der auch ein weiterer MQTT-Server sein kann - weitergibt.</ref>
*Topic - das ist die Adresse, an die eine Nachricht gesendet wird, bzw. von wo sie abgeholt werden kann (so ähnlich wie ein Postfach in der realen Welt). Topics sind einfache Strings, die mit Schrägstrichen getrennt werden (keine Leerzeichen und nur sehr wenige Sonderzeichen erlaubt). Ein Topic könnte beispielhaft so lauten: <code>zuHause/1OG/Kueche/Licht/state</code>. Diese Topics beinhalten also eine Hierarchie der Objekte - hier im Beispiel sind sie zuerst danach sortiert, ob sie sich zu Haus befinden, dann wird nach Stockwerken sortiert und im ersten Stock schaut man auf die Küche sowie das dort vorhandene Licht.
*Payload - das ist der Inhalt der Nachricht, oft handelt es sich um Befehle oder Daten.
*Quality of Service - soll geprüft werden, ob die Nachricht zugestellt wurde und wenn ja, mit welcher "Tiefe"?
*Retained Message.
Details bitte in der oben genannten Einführung nachlesen.

MQTT kommuniziert üblicherweise über Port 1883, es können aber unter derselben Netzwerkadresse an unterschiedlichen Ports auch mehrere Serverdienste bereitstehen.

== Installation in FHEM ==
Um MQTT in FHEM zu nutzen, benötigt man (mindestens) einen MQTT-Server. Es gibt zwei Möglichkeiten: Man kann FHEM-externe Server-Software (oder auch einen oder mehrere im Internet bereitstehende MQTT-Server) verwenden oder man kann die MQTT-Serverkomponente aktivieren, die mit {{Link2CmdRef|Anker=MQTT2_SERVER|Lang=en|Label=MQTT2_SERVER}} in FHEM direkt bereitsteht. Hier werden kurz beide Installationswege erläutert, zwingend ist nur einer, da eben mindestens ein MQTT-Serverdienst aktiv sein muß.

Die nachfolgenden Schaubilder zeigen schematisch die in FHEM zur Verfügung stehenden Wege der Einbindung von Hard- und/oder Softwarekomponenten, die über das MQTT-Protokoll Daten austauschen.
<gallery>
Datei:Mqtt2 server.png|Datenaustausch mit MQTT-Geräten, wenn MQTT2_SERVER als internem MQTT-Serverdienst verwendet wird
Datei:Mqtt2 client v extern server.png|Datenaustausch mit MQTT-Geräten, wenn MQTT2_CLIENT iVm. mosquitto als externem MQTT-Serverdienst verwendet wird
Datei:00 mqtt pm.png|Datenaustausch mit MQTT-Geräten, wenn das Modul ''MQTT'' (00_MQTT.pm) iVm. mosquitto als externem MQTT-Serverdienst verwendet wird
</gallery>
=== FHEM als MQTT-Server ===
Die mit dem Modul {{Link2CmdRef|Anker=MQTT2_SERVER|Lang=en|Label=MQTT2_SERVER}} bereitstehende Serverkomponente kann z.B. wie folgt aktiviert werden:
defmod myBroker MQTT2_SERVER 1883 global
Dieses [[Gerät]] übernimmt dann die Kommunikation mit den externen Clients (und wird von diesen behandelt, wie jeder andere MQTT-Server auch<ref>Bitte beachten Sie, dass (Stand: Juni 2019) MQTT2_SERVER nicht alle features des MQTT-Protokolls unterstützt.</ref>) und verteilt die eingehenden Nachrichten als IO-Device<ref>im Sinne des [[DevelopmentModuleIntro#Zweistufiges Modell für Module|2-stufigen Modulkonzepts]]</ref> für die Client-Module [[MQTT2_DEVICE]]<ref>Die Zahl 2 in den Modulnamen verweist nur darauf, dass es sich um eine neuere Modulfamilie handelt; die Kommunikation mit den externen Komponenten unterscheidet sich nicht zu den älteren Modulen, die vor dem Jahr 2018 genutzt werden konnten.</ref> und {{Link2CmdRef|Anker=MQTT_GENERIC_BRIDGE|Lang=de|Label=MQTT_GENERIC_BRIDGE}}.
Ein weiterer Vorteil dieser Lösung besteht darin, dass man ein MQTT2_SERVER-Device mit Hilfe von [[allowed]] absichern kann, was auch SSL-verschlüsselte Kommunikation ermöglicht. '''Hinweis:''' In diesem Fall muss User bzw. Passwort auch in den entsprechenden Geräten eingetragen werden.

{{Hinweis|Wenn Sie beabsichtigen, diese Variante zu verwenden, sollten Sie als nächstes die [[MQTT2-Module - Praxisbeispiele|Praxisbeispiele zu den MQTT2-Modulen]] lesen, und ggf. später wieder hierher zurückkehren. Dort findet sich auch ein Abschnitt zu dem auf den Grafiken zu den MQTT2-IO-Modulen enthaltenen [[MQTT2-Module_-_Praxisbeispiele#bridgeRegexp|bridgeRegexp]]-Attribut.}}

=== FHEM-externer Broker ===
==== Beispiel: mosquitto ====
Eine gern verwendete MQTT-Server-Software ist [http://mosquitto.org Mosquitto]. Sie kann ohne weiteres auf dem Raspberry Pi, der bereits eine FHEM-Installation besitzt, installiert werden und wird keine größere CPU- oder Netzwerklast verursachen.

Eine Anleitung zur Installation findet sich beispielsweise in diesem [http://blog.wenzlaff.de/?p=6487 Blogeintrag]. Im wesentlichen beschränkt sich die Installation eines MQTT Servers aber auf wenige Arbeitsschritte. Bei ''stretch'' ist ''Mosquitto'' bereits in der Distribution enthalten und kann - zusammen mit dem client Befehl ''mosquito_sub'', der weiter unten benötigt wird, wie folgt installiert und getestet werden<ref>Die für den Betrieb mit FHEM erforderlichen Perl-Module sind teilweise (noch) nicht in den Paketquellen verfügbar. Sie können dennoch statt mit cpan auch als Debian-Paket mit Hilfe von ''dh-make-perl'' installiert werden, wobei vorab das in den Paketquellen bereits vorhandene ''libmodule-pluggable-perl'' installiert werden sollte: 
<code>sudo apt-get install dh-make-perl 
dh-make-perl --install --cpan Net::MQTT::simple 
dh-make-perl --install --cpan Net::MQTT::Constants 
sudo dpkg -i libnet-mqtt-simple-perl*.deb 
sudo dpkg -i libnet-mqtt-perl*.deb</code></ref>:
{{Randnotiz|RNTyp=g|RNText=Für ältere Distributionen (hier am Beispiel von ''jessie'') muß ggf. aus einer zusätzlichen Paketquelle installiert werden:
wget http://repo.mosquitto.org/debian/mosquitto-repo.gpg.key
sudo apt-key add mosquitto-repo.gpg.key
cd /etc/apt/sources.list.d/
sudo wget http://repo.mosquitto.org/debian/mosquitto-jessie.list
sudo apt-get update
Danach kann die eigentliche Installation durchgeführt werden wie links für ''stretch'' beschrieben.}}<source lang="bash">
sudo apt-get install mosquitto mosquitto-clients

# MQTT Server Test
sudo service mosquitto status

# Start / Stop des Servers
sudo service mosquitto stop
sudo service mosquitto start
</source>
Danach ist der RPi mit <nowiki>shutdown restart</nowiki> neu zu starten.

==== IO-Module für externe MQTT-Server ====
Damit FHEM mit dem MQTT-Server kommuniziert, muss noch ein IO-Device angelegt werden. Dabei stehen zwei Varianten zur Wahl, das Modul [[MQTT (Modul)|MQTT]] oder seit Ende 2018 [[MQTT2_CLIENT]].

Beide Module können auch dazu genutzt werden, um Daten zwischen zwei FHEM-Installationen auszutauschen, insbesondere kann auch 00_MQTT.pm als Client für einen MQTT2_SERVER eingesetzt werden, der '''auf der anderen Installation''' als MQTT-Serverdienst eingerichtet ist. Darüber hinaus bestehen eine Vielzahl von Kombinationsmöglichkeiten der diversen IO-Module, wenn die Installation auf mehrere Server verteilt ist.
Auf einer FHEM-Installation wird jedoch in der Regel nur eines der IO-Module benötigt.

===== MQTT2_CLIENT =====
Ein MQTT2_CLIENT-IO-Device wird z.B. angelegt mit
define myBroker MQTT2_CLIENT 10.0.0.5:1883 ## bitte EIGENE IP-Adresse eintragen

{{Hinweis|Wenn Sie beabsichtigen, MQTT2_CLIENT zu verwenden, sollten Sie zuerst die [[MQTT2-Module - Praxisbeispiele|Praxisbeispiele zu den MQTT2-Modulen]] lesen, und dabei die Hinweise im Artikel [[MQTT2_CLIENT]] beachten.}}

Ein MQTT2_CLIENT-Device kann ebenfals mit Hilfe von [[allowed]] abgesichert werden, um z.B. SSL-verschlüsselte Kommunikation zu ermöglichem. Client-Module zu diesem IO-Typ sind wiederum [[MQTT2_DEVICE]] und {{Link2CmdRef|Anker=MQTT_GENERIC_BRIDGE|Lang=de|Label=MQTT_GENERIC_BRIDGE}}.

===== MQTT (Modul) =====
Vorab werden für diese Variante weitere Perl-Pakete benötigt:
<source lang="bash">
# Perl Version ausgeben
perl -v
# Perl MQTT Module nachinstallieren (läuft ein paar Minuten)
sudo cpan install Net::MQTT:Simple
sudo cpan install Net::MQTT:Constants
</source>

Ein IO-Device des Typs MQTT wird z.B. angelegt mit
{{Randnotiz|RNTyp=g|RNText=Sofern der Broker mit FHEM über localhost kommuniziert, kann als IP 127.0.0.1 verwendet werden.}}
define myBroker MQTT 10.0.0.5:1883 ## bitte EIGENE IP-Adresse eintragen
{{Randnotiz|RNTyp=g|RNText=Außerhalb der offiziellen Quellen sind auch einige ältere Varianten des Moduls MQTT_DEVICE verfügbar, die jeweils spezielle Anforderungen (z.B. für Zigbee2mqtt) separat abbilden. Diese werden hier nicht gesondert behandelt, da solche Sonderfälle heute generischer und einfacher durch den Einsatz von MQTT2_DEVICE abzubilden sind.}}Client-Device-Module zum Modul [[MQTT (Modul)|MQTT]] sind [[MQTT_DEVICE]], {{Link2CmdRef|Anker=MQTT_BRIDGE|Lang=de|Label=MQTT_BRIDGE}} (veraltet) und {{Link2CmdRef|Anker=MQTT_GENERIC_BRIDGE|Lang=de|Label=MQTT_GENERIC_BRIDGE}}. Da ''MQTT_DEVICE'' payload im JSON-Format (im Unterschied zu MQTT2_DEVICE) nicht selbst verarbeiten kann wird hier zusätzlich das Modul {{Link2CmdRef|Anker=expandJSON|Lang=de|Label=expandJSON}} benötigt, um den {{Link2Forum|Topic=66761|LinkText=JSON String auszuwerten}}.

=== Performancefragen... ===
...oder was sollte man als Lösung wählen, wenn man in die MQTT-Welt einsteigt<ref>vgl. hierzu diesen {{Link2Forum|Topic=94768|Message=875714|LinkText=Beitrag}} von Rudolf König</ref>?
Grundsätzlich sollte man davon ausgehen, dass innerhalb von FHEM die Verarbeitung derselben Daten näherungsweise denselben Aufwand bedeuten, unabhängig davon, welche der Implementierungen (''MQTT2_CLIENT'', ''MQTT'' oder ''MQTT2_SERVER'') man konkret wählt.
Ein externer Broker hat daher vor allem dann Vorteile, wenn die MQTT Daten überwiegend für was anderes (nicht FHEM) verwendet werden, oder MQTT zweckentfremdet wird (wie z.Bsp. für Musikübertragung). Nutzt man das MQTT-Protokoll dagegen vorwiegend innerhalb von FHEM, ist eher der Einsatz von MQTT2_SERVER in Betracht zu ziehen. Dieser soll Anfängern die Anbindung von MQTT Geräten in FHEM einfacher machen. Wer später merkt, dass er doch einen externen Broker benötigt, kann dann immer noch auf MQTT2_CLIENT in Verbindung mit einem anderen Broker wechseln.
Dagegen ist der Weg von MQTT_DEVICE zu MQTT2_DEVICE mit erheblich mehr Aufwand verbunden.

=== Kommunikation zu sonstigen FHEM-Geräten über MQTT ===

Möchte man Daten von einem [[Gerät]] (im FHEM-Sinn), das '''nicht''' vom Typ ''MQTT2_DEVICE'' oder ''MQTT_DEVICE'' (je nach IO-Modul) ist, per MQTT-Protokoll versenden (z.B. für eine andere Visualisierungslösung als FHEMWEB, oder als FHEM2FHEM-Ersatzlösung), oder diese sonstigen Geräte über MQTT-Anweisungen von außen steuern können, hat man mehrere Möglichkeiten:

==== MQTT_GENERIC_BRIDGE ====
Das Modul {{Link2CmdRef|Anker=MQTT_GENERIC_BRIDGE|Lang=en|Label=MQTT_GENERIC_BRIDGE}} ermöglicht es, sein jeweiliges IO-Modul-Gerät zu nutzen, um diesen Kommunikationsweg für beliebig viele andere FHEM-Geräte bereitzustellen. Dabei erfolgt am MQTT_GENERIC_BRIDGE-Gerät selbst nur eine Basiskonfiguration, im Übrigen durch Attribute an dem jeweiligen Gerät selbst. So kann z.B. ein Aktor des Typs [[CUL_HM]] an- oder ausgeschaltet werden oder auch einfach nur seinen aktuellen Schaltzustand per MQTT-Protokoll publizieren.

Dieses Modul kann seit November 2018 mit allen drei IO-Modul-Varianten zusammen eingesetzt werden, also sowohl mit ''MQTT2_SERVER'' bzw. ''MQTT2_CLIENT'' oder ''MQTT'' (00_MQTT.pm).

Dabei sollte man jedoch beachten, dass zur Verwendung mit den MQTT2-IO's unbedingt die autocreate-Funktion des betreffenden IOs ausgeschaltet wird und dies auch bleibt<ref>siehe dazu diesen {{Link2Forum|Topic=95341|LinkText=Thread}} zu den technischen Hintergründen</ref>! Weiter wird das Perl-Modul ''libmodule-pluggable-perl'' benötigt<ref>Dieses kann über <code>apt-get install libmodule-pluggable-perl</code> installiert werden</ref>, damit im Hintergrund auch das Modul [[MQTT (Modul)|MQTT]] geladen werden kann. Damit gelten auch für diesen Modul die Installationsvoraussetzungen für [[MQTT#MQTT_.28Modul.29|MQTT]]!

Anwendungsfälle und -beispiele für das Modul sind diesem {{Link2Forum|Topic=91642|LinkText=Thread}} zu entnehmen.

==== MQTT_BRIDGE ====
Dieses Modul kann nur zusammen mit einem IO-Gerät des Typs [[MQTT (Modul)|MQTT]] verwendet werden. Dabei wird pro weiterzuleitendem anderen FHEM-Gerät eine eigene Instanz dieses Moduls verwendet. Auf den Einsatz dieser Option sollte in neuen Installationen zugunsten von ''MQTT_GENERIC_BRIDGE'' verzichtet werden.

==== Per publish-Befehl am IO-Gerät ====
Alle drei IO-Module kennen direkte ''publish''-Anweisungen, mit deren Hilfe beliebige ''payloads'' an beliebige ''topics'' gesendet werden können. Dies kann man z.B. in einem [[notify]] oder [[at]] nutzen, um einzelne Events zu publishen oder Werteanfragen abzusetzen.

Hier eine regelmäßige Werteabfrage auf einen [[EBUS-MQTT2|ebus]]:
defmod get_ebus_updates at +*00:15:00 set ebusMQTT publish ebusd/430/Hc1HeatCurve/get;
set ebusMQTT publish ebusd/430/HwcTempDesired/get;
...

==== RAW-Events am IO-Gerät (MQTT2.*) ====
Bei beiden MQTT2-IO-Modulen (MQTT2_SERVER und MQTT2_CLIENT) kann per [[Regulärer Ausdruck|regulärem Ausdruck]] festgelegt werden, welche Nachrichten ein Event erzeugen sollen, auf das dann wieder z.B. mit einem [[notify]] reagiert werden kann, z.B. um beliebige Schaltaktionen auszulösen.

== MQTT-Clients (Beispiele) ==

===Arduino-library===
Zur Kommunikation mit dem Broker von Seiten eines [[Arduino|Arduinos]] mit selbst erstellten Sketches böte sich der PubSubClient an.

===PC-Software===
Um die Funktionalität des Brokers zu testen kann z.B. ein Analyse-Tool wie MQTT.fx verwendet werden, oder die im Paket ''mosquitto-clients'' enthaltenen Linux-Kommandozeilen-Programme ''mosquitto_sub'' und ''mosquitto_pub''. Letzterer könnte z.E. auch aus beliebigen ''shell-scripten'' heraus aufgerufen werden. Als Perl-Bibliothek steht alternativ z.B. [https://metacpan.org/pod/distribution/AnyEvent-MQTT/bin/anyevent-mqtt-pub anyevent-mqtt-pub] zur Verfügung.

=== Tasmota ===
Eine derzeit oft genutzte Möglichkeit für MQTT bilden die [[Sonoff]]-Geräte und weitere [[ESP8266]]-basierte Hardware, die unter vielen Handelsnamen erhältlich sind. Werden diese mit Tasmota ('''T'''heo '''A'''rends '''S'''onoff '''M'''QTT '''O'''ver '''T'''he '''A'''ir - einer offenen Firmware von [https://github.com/arendst arendst]) geflasht, so kommunizieren sie über MQTT. Um diese Geräte einzubinden, ist wie folgt vorzugehen. Zuerst ist ein Serverdienst (Broker) bereitzustellen, wie oben beschrieben.

Unter Sonoff sind einige Topics voreingestellt. arendst stellt insbesondere drei Topic-Präfixe bereit, die seiner Meinung jedes Topic einleiten sollen (in den Eingabemasken als "%prefix%" notiert). Das sind einmal Kommandos (abgekürzt als cmnd), die dazu dienen, Befehle auszuführen. Daten werden mit tele und stat übertragen. Ein Topic besteht dann zuerst aus diesem Präfix und danach dem eigentlichen Topic. Wer also beispielsweise einem Sonoff_Switch einen Befehl senden will, sollte als Topic cmnd/Sonoff_Switch wählen. Wenn der Switch ein- und ausgeschaltet werden kann, muss der Topic noch das Wort POWER enthalten (in MQTT werden viele Kennworte komplett groß geschrieben). Der Topic lautet damit vollständig "cmnd/Sonoff_Switch/POWER/set"

{{Randnotiz|RNTyp=g|RNText=Dabei ist darauf zu achten, dass für den Parameter ''topic = %topic% (sonoff)'' statt ''sonoff'' ein gerätespezifischer eigener Name eingetragen wird. Hierzu kann man z.B. auch die dynamisch aus der Chip-ID erzeugte Kennung ''DVES_%06X'' verwenden, indem man die unter ''client (DVES_8BABA9)'' zu findende Angabe kopiert. Die eigentliche Umbenennung zu einem "sprechenden Namen" kann dann innerhalb von FHEM - mittels ''rename'' oder ggf. mit einem ''alias'' - erfolgen.}}

Link zum Forum: {{Link2Forum|Topic=27532|LinkText=MQTT FHEM Einrichtung}} (hier als ''MQTT_DEVICE''!):

### FHEM Device mit MQTT verbinden ###
define Sonoff_Switch MQTT_DEVICE
attr Sonoff_Switch IODev myBroker
attr Sonoff_Switch devStateIcon ON:rc_GREEN:OFF OFF:rc_RED:ON
attr Sonoff_Switch icon hue_filled_br30
attr Sonoff_Switch publishSet ON OFF cmnd/TestSwitch/POWER
attr Sonoff_Switch room MQTT
attr Sonoff_Switch subscribeReading_Licht stat/Sonoff_Switch/POWER
attr Sonoff_Switch subscribeReading_Sensor tele/Sonoff_Switch/SENSOR
attr Sonoff_Switch subscribeReading_Status stat/Sonoff_Switch/STATUS
attr Sonoff_Switch webCmd ON:OFF

Der hier dargestellte Beispielcode realisiert die Kommunikation zwischen FHEM und dem sonoff Modul via MQTT Broker. Zu beachten ist hier, dass '''subscribeReading_Licht''' und '''subscribeReading_Status''' unterschiedliche Syntax des Topic Strings haben!

=== OpenMQTTGateway ===
Um verschiedene Systeme wie BLE usw. auf MQTT zu bringen bietet sich OpenMQTTGateway an.

Ich habe es für BLE kompiliert und auf einem ESP32 installiert. Hierzu braucht man nur das blanke Board ohne Zusatzhardware.

Weiter infos hier: [https://github.com/1technophile/OpenMQTTGateway]

In FHEM wird das ganze über den eigenen Broker oder einen extern Broker (z.B.: Mosquitto) eingebunden.

Zusätzlich legt ihr noch ein Device hierzu an.

<code>define MQTT2_OMG1 MQTT2_DEVICE</code>

Ich habe es noch in den Raum MQTT2 geschoben.

Mit <code>set MQTT2_OMG1 attrTemplate OpenMQTTGateway_MCU</code> wird das Template festgelegt.

== Sicherheit ==
Prinzipiell ist MQTT ebenso sicher wie eine Postkarte. Solange man es nicht extra absichert, kann jeder der, im eigenen LAN ist (und die Adresse vom Broker kennt) alle Topics mitlesen.
:<code>meinHaus/Flur/Haustuer:open / close</code>
bietet unter diesen Umständen reichlich Raum für Verbesserungen!

Abhilfe:
=== Username / Passwort ===
Zunächst kann man erst mal einen Username / Passwort vergeben, was alle IO-Device-Module unterstützen. Da ist zwar auch noch lange nicht sicher, aber zumindest steigert es den Aufwand schon mal. Jetzt muss man zumindest schon mal Pakete sniffen und verstehen, um unbefugt zu lesen oder gar zu publishen.

=== TLS ===
Um wirklich sicher zu werden, führt kein Weg an TLS vorbei.

Der MQTT-Client in [[#Tasmota|Tasmota]] (für ESP8266) kann mit TLS betrieben werden, vgl. [https://github.com/arendst/Tasmota/wiki/TLS Beschreibung im Tasmota-Wiki].

Leider kann z.B. ein Arduino das schlicht nicht mehr, da die einfacheren Modelle nicht über ausreichend Speicher und die Rechenleistung verfügen.

'''(Hier fehlt eine Anleitung für allowed usw.)'''

== Probleme ==
=== Anweisung und Ergebnis weichen voneinander ab ===
In der Regel melden MQTT-fähige Geräte entweder den Erhalt einer Nachricht zurück oder den Status nach Durchführung der in der ''payload'' enthaltenen Anweisung. Dabei findet aber in der Regel beim Empfänger eine Verarbeitung der Nachricht statt, ggf. wird diese auch weitergesendet und nochmals verarbeitet, bevor dann ggf. eine Rückmeldung des neuen Status an den MQTT-Server erfolgt. Handelt es sich um einfache on/off-Befehle, bleibt Anweisung und Ergebnis in der Regel identisch. Bei anderen, namentlich bei Dimmer-Werten, kann es zu Rundungsdifferenzen bei nummerischen Werten kommen. So kann z.B. ein Dimm-Wert von 70% gesetzt werden, zürückgemeldet wird dann aber 72% (oder 67%).
Dies ist technisch bedingt, vermeiden kann das jedoch in aller Regel nur der Autor der jeweiligen software/firmware auf dem "rechnenden" Gerät.

=== Unbeabsichtigte Schleifen ===
Durch Fehler in der topic-Struktur können unbeabsichtigte Schleifen entstehen, die FHEM komplett blockieren können. Es ist unbedingt darauf zu achten, dass die jeweiligen Sende- und Empfangs-topics andere sind!

== Links ==
* [http://mqtt.org Offizielle Homepage von MQTT, englisch]
* [http://www.hivemq.com/blog/mqtt-essentials-part-1-introducing-mqtt Sehr gute Einführung, englisch, sind 5 lesenswerte Teile]
* [https://www.heise.de/developer/artikel/MQTT-Protokoll-fuer-das-Internet-der-Dinge-2168152.html Ein Exkurs von Heise mit Beispielen, deutsch, sehr lesenswert]
* [http://www.mqttfx.org/ MQTT FX - ein sehr praktisches Analysetool]
* {{Link2Forum|Topic=69230|LinkText=Diskussionsthread im Forum}}
* {{Link2Forum|Topic=92888|LinkText=Thread, zur Entstehungsgeschichte von MQTT2_CLIENT}}
* {{Link2Forum|Topic=93255|LinkText=Ankündigungsthread zur MQTT2-Erweiterung der MQTT_GENERIC_BRIDGE}}
* [[MQTT_Einf%C3%BChrung_Teil_2|Teil 2 der MQTT Einführung]]: Detailaspekte (vorrangig zur Modulfamilie MQTT/MQTT_DEVICE)
* [[MQTT Einführung Teil 3|Teil 3 der MQTT Einführung]]: Arduino-Client selbst programmieren

== Hinweise ==
<references />

[[Kategorie:Glossary]]
[[Kategorie:HOWTOS]]
[[Kategorie:MQTT|Einführung]]
[[Kategorie:MQTT| ]]

MQTT

2020-06-11T11:35:07Z

Rspecht: /* Openmqttgateway angelegt */

MQTT ist ein Protokoll ("Message Queue Telemetry Transport"), mit dem Daten und Befehle zwischen verschiedenen Geräten ausgetauscht werden. Die Kommunikation erfolgt dabei über einen zentralen MQTT-Server, in alter Nomenklatur auch ''Broker'' genannt.

MQTT wurde entwickelt, um möglichst effizient, sicher und mit wenig Datenlast zu kommunizieren. MQTT ist nachrichtenorientiert, daher muss ein Client nicht beständig beim Server anfragen, ob neue Daten vorliegen. Heute findet sich MQTT vor allem im Bereich des ''Internet of Things'' (IoT). MQTT kann leicht mit FHEM verbunden werden, ohne dass dabei größerer CPU- oder Datenverbrauch entsteht.

== Eine sehr kurze Einführung in MQTT ==
Die folgende Einführung kann eine vollwertige Einleitung wie beispielsweise [https://github.com/mqtt/mqtt.github.io/wiki diese Wikieinträge] nicht ersetzen.

Bei MQTT findet die nachrichtenbasierte Kommunikation zwischen einzelnen Teilnehmern<ref>Teilnehmer in diesem Sinne kann ein Stück Hardware mit einer MQTT-fähigen firmware sein, ein auf einem Computer laufendes Script (einschließlich eines MQTT-Server-Dienstes wie ''mosquitto'' oder ''MQTT2_SERVER'', kurz: alles mögliche sein. Dadurch kann auch ein einzelner Computer unter mehreren ClientID's am MQTT-Datenaustausch beteiligt sein.</ref> in der Regel nicht direkt statt. Stattdessen werden alle Nachrichten von einem Teilnehmer an einen Serverdienst, den MQTT-Server (früher ''Broker'' genannt) übergeben, der dann dafür sorgt, dass die Nachricht an alle (berechtigten) anderen Teilnehmer verteilt wird, die sich für derartige Nachrichten "interessieren". Wenn also ein Teilnehmer ohne Server-Funktion (Client) Daten von einem bestimmten anderen Teilnehmer (anderer Client) empfangen will, muss es vorher dem MQTT-Server (Broker) mitteilen, dass er die Nachrichten dieses anderen Teilnehmers abonniert (deshalb wird dieser Vorgang als ''subscribe'' bezeichnet). Im IoT ist besonders interessant, dass Sender und Empfänger von Nachrichten durch den MQTT-Server vollständig entkoppelt werden können - jemand, der Daten bereit stellt, muss sich also nicht darum kümmern, wer diese Daten empfängt<ref>Aufgrund dieser Funktionsweise sollte allerdings darauf geachtet werden, die Möglichkeiten des jeweiligen Servers zur Sicherung der Daten gegen unberechtigten Zugriff zu nutzen, insbesondere wenn die Art der Daten oder die sich hierdurch ergebenden Möglichkeiten, z.B. Schaltvorgänge in der realen Welt auszulösen, dies notwendig macht!</ref>.

Eine Nachricht besteht im Wesentlichen aus den folgenden Elementen:
*ClientID - das ist die Kennung des Senders einer Nachricht<ref>Diese kann sich bei der Weitergabe der Nachricht ändern: Zunächst sendet ein Client eine Nachricht unter seiner ClientID, der MQTT-Server wird diese dann in der Regel durch seine Kennung ersetzten, wenn er die Nachricht an einen Abonnenten - der auch ein weiterer MQTT-Server sein kann - weitergibt.</ref>
*Topic - das ist die Adresse, an die eine Nachricht gesendet wird, bzw. von wo sie abgeholt werden kann (so ähnlich wie ein Postfach in der realen Welt). Topics sind einfache Strings, die mit Schrägstrichen getrennt werden (keine Leerzeichen und nur sehr wenige Sonderzeichen erlaubt). Ein Topic könnte beispielhaft so lauten: <code>zuHause/1OG/Kueche/Licht/state</code>. Diese Topics beinhalten also eine Hierarchie der Objekte - hier im Beispiel sind sie zuerst danach sortiert, ob sie sich zu Haus befinden, dann wird nach Stockwerken sortiert und im ersten Stock schaut man auf die Küche sowie das dort vorhandene Licht.
*Payload - das ist der Inhalt der Nachricht, oft handelt es sich um Befehle oder Daten.
*Quality of Service - soll geprüft werden, ob die Nachricht zugestellt wurde und wenn ja, mit welcher "Tiefe"?
*Retained Message.
Details bitte in der oben genannten Einführung nachlesen.

MQTT kommuniziert üblicherweise über Port 1883, es können aber unter derselben Netzwerkadresse an unterschiedlichen Ports auch mehrere Serverdienste bereitstehen.

== Installation in FHEM ==
Um MQTT in FHEM zu nutzen, benötigt man (mindestens) einen MQTT-Server. Es gibt zwei Möglichkeiten: Man kann FHEM-externe Server-Software (oder auch einen oder mehrere im Internet bereitstehende MQTT-Server) verwenden oder man kann die MQTT-Serverkomponente aktivieren, die mit {{Link2CmdRef|Anker=MQTT2_SERVER|Lang=en|Label=MQTT2_SERVER}} in FHEM direkt bereitsteht. Hier werden kurz beide Installationswege erläutert, zwingend ist nur einer, da eben mindestens ein MQTT-Serverdienst aktiv sein muß.

Die nachfolgenden Schaubilder zeigen schematisch die in FHEM zur Verfügung stehenden Wege der Einbindung von Hard- und/oder Softwarekomponenten, die über das MQTT-Protokoll Daten austauschen.
<gallery>
Datei:Mqtt2 server.png|Datenaustausch mit MQTT-Geräten, wenn MQTT2_SERVER als internem MQTT-Serverdienst verwendet wird
Datei:Mqtt2 client v extern server.png|Datenaustausch mit MQTT-Geräten, wenn MQTT2_CLIENT iVm. mosquitto als externem MQTT-Serverdienst verwendet wird
Datei:00 mqtt pm.png|Datenaustausch mit MQTT-Geräten, wenn das Modul ''MQTT'' (00_MQTT.pm) iVm. mosquitto als externem MQTT-Serverdienst verwendet wird
</gallery>
=== FHEM als MQTT-Server ===
Die mit dem Modul {{Link2CmdRef|Anker=MQTT2_SERVER|Lang=en|Label=MQTT2_SERVER}} bereitstehende Serverkomponente kann z.B. wie folgt aktiviert werden:
defmod myBroker MQTT2_SERVER 1883 global
Dieses [[Gerät]] übernimmt dann die Kommunikation mit den externen Clients (und wird von diesen behandelt, wie jeder andere MQTT-Server auch<ref>Bitte beachten Sie, dass (Stand: Juni 2019) MQTT2_SERVER nicht alle features des MQTT-Protokolls unterstützt.</ref>) und verteilt die eingehenden Nachrichten als IO-Device<ref>im Sinne des [[DevelopmentModuleIntro#Zweistufiges Modell für Module|2-stufigen Modulkonzepts]]</ref> für die Client-Module [[MQTT2_DEVICE]]<ref>Die Zahl 2 in den Modulnamen verweist nur darauf, dass es sich um eine neuere Modulfamilie handelt; die Kommunikation mit den externen Komponenten unterscheidet sich nicht zu den älteren Modulen, die vor dem Jahr 2018 genutzt werden konnten.</ref> und {{Link2CmdRef|Anker=MQTT_GENERIC_BRIDGE|Lang=de|Label=MQTT_GENERIC_BRIDGE}}.
Ein weiterer Vorteil dieser Lösung besteht darin, dass man ein MQTT2_SERVER-Device mit Hilfe von [[allowed]] absichern kann, was auch SSL-verschlüsselte Kommunikation ermöglicht. '''Hinweis:''' In diesem Fall muss User bzw. Passwort auch in den entsprechenden Geräten eingetragen werden.

{{Hinweis|Wenn Sie beabsichtigen, diese Variante zu verwenden, sollten Sie als nächstes die [[MQTT2-Module - Praxisbeispiele|Praxisbeispiele zu den MQTT2-Modulen]] lesen, und ggf. später wieder hierher zurückkehren. Dort findet sich auch ein Abschnitt zu dem auf den Grafiken zu den MQTT2-IO-Modulen enthaltenen [[MQTT2-Module_-_Praxisbeispiele#bridgeRegexp|bridgeRegexp]]-Attribut.}}

=== FHEM-externer Broker ===
==== Beispiel: mosquitto ====
Eine gern verwendete MQTT-Server-Software ist [http://mosquitto.org Mosquitto]. Sie kann ohne weiteres auf dem Raspberry Pi, der bereits eine FHEM-Installation besitzt, installiert werden und wird keine größere CPU- oder Netzwerklast verursachen.

Eine Anleitung zur Installation findet sich beispielsweise in diesem [http://blog.wenzlaff.de/?p=6487 Blogeintrag]. Im wesentlichen beschränkt sich die Installation eines MQTT Servers aber auf wenige Arbeitsschritte. Bei ''stretch'' ist ''Mosquitto'' bereits in der Distribution enthalten und kann - zusammen mit dem client Befehl ''mosquito_sub'', der weiter unten benötigt wird, wie folgt installiert und getestet werden<ref>Die für den Betrieb mit FHEM erforderlichen Perl-Module sind teilweise (noch) nicht in den Paketquellen verfügbar. Sie können dennoch statt mit cpan auch als Debian-Paket mit Hilfe von ''dh-make-perl'' installiert werden, wobei vorab das in den Paketquellen bereits vorhandene ''libmodule-pluggable-perl'' installiert werden sollte: 
<code>sudo apt-get install dh-make-perl 
dh-make-perl --install --cpan Net::MQTT::simple 
dh-make-perl --install --cpan Net::MQTT::Constants 
sudo dpkg -i libnet-mqtt-simple-perl*.deb 
sudo dpkg -i libnet-mqtt-perl*.deb</code></ref>:
{{Randnotiz|RNTyp=g|RNText=Für ältere Distributionen (hier am Beispiel von ''jessie'') muß ggf. aus einer zusätzlichen Paketquelle installiert werden:
wget http://repo.mosquitto.org/debian/mosquitto-repo.gpg.key
sudo apt-key add mosquitto-repo.gpg.key
cd /etc/apt/sources.list.d/
sudo wget http://repo.mosquitto.org/debian/mosquitto-jessie.list
sudo apt-get update
Danach kann die eigentliche Installation durchgeführt werden wie links für ''stretch'' beschrieben.}}<source lang="bash">
sudo apt-get install mosquitto mosquitto-clients

# MQTT Server Test
sudo service mosquitto status

# Start / Stop des Servers
sudo service mosquitto stop
sudo service mosquitto start
</source>
Danach ist der RPi mit <nowiki>shutdown restart</nowiki> neu zu starten.

==== IO-Module für externe MQTT-Server ====
Damit FHEM mit dem MQTT-Server kommuniziert, muss noch ein IO-Device angelegt werden. Dabei stehen zwei Varianten zur Wahl, das Modul [[MQTT (Modul)|MQTT]] oder seit Ende 2018 [[MQTT2_CLIENT]].

Beide Module können auch dazu genutzt werden, um Daten zwischen zwei FHEM-Installationen auszutauschen, insbesondere kann auch 00_MQTT.pm als Client für einen MQTT2_SERVER eingesetzt werden, der '''auf der anderen Installation''' als MQTT-Serverdienst eingerichtet ist. Darüber hinaus bestehen eine Vielzahl von Kombinationsmöglichkeiten der diversen IO-Module, wenn die Installation auf mehrere Server verteilt ist.
Auf einer FHEM-Installation wird jedoch in der Regel nur eines der IO-Module benötigt.

===== MQTT2_CLIENT =====
Ein MQTT2_CLIENT-IO-Device wird z.B. angelegt mit
define myBroker MQTT2_CLIENT 10.0.0.5:1883 ## bitte EIGENE IP-Adresse eintragen

{{Hinweis|Wenn Sie beabsichtigen, MQTT2_CLIENT zu verwenden, sollten Sie zuerst die [[MQTT2-Module - Praxisbeispiele|Praxisbeispiele zu den MQTT2-Modulen]] lesen, und dabei die Hinweise im Artikel [[MQTT2_CLIENT]] beachten.}}

Ein MQTT2_CLIENT-Device kann ebenfals mit Hilfe von [[allowed]] abgesichert werden, um z.B. SSL-verschlüsselte Kommunikation zu ermöglichem. Client-Module zu diesem IO-Typ sind wiederum [[MQTT2_DEVICE]] und {{Link2CmdRef|Anker=MQTT_GENERIC_BRIDGE|Lang=de|Label=MQTT_GENERIC_BRIDGE}}.

===== MQTT (Modul) =====
Vorab werden für diese Variante weitere Perl-Pakete benötigt:
<source lang="bash">
# Perl Version ausgeben
perl -v
# Perl MQTT Module nachinstallieren (läuft ein paar Minuten)
sudo cpan install Net::MQTT:Simple
sudo cpan install Net::MQTT:Constants
</source>

Ein IO-Device des Typs MQTT wird z.B. angelegt mit
{{Randnotiz|RNTyp=g|RNText=Sofern der Broker mit FHEM über localhost kommuniziert, kann als IP 127.0.0.1 verwendet werden.}}
define myBroker MQTT 10.0.0.5:1883 ## bitte EIGENE IP-Adresse eintragen
{{Randnotiz|RNTyp=g|RNText=Außerhalb der offiziellen Quellen sind auch einige ältere Varianten des Moduls MQTT_DEVICE verfügbar, die jeweils spezielle Anforderungen (z.B. für Zigbee2mqtt) separat abbilden. Diese werden hier nicht gesondert behandelt, da solche Sonderfälle heute generischer und einfacher durch den Einsatz von MQTT2_DEVICE abzubilden sind.}}Client-Device-Module zum Modul [[MQTT (Modul)|MQTT]] sind [[MQTT_DEVICE]], {{Link2CmdRef|Anker=MQTT_BRIDGE|Lang=de|Label=MQTT_BRIDGE}} (veraltet) und {{Link2CmdRef|Anker=MQTT_GENERIC_BRIDGE|Lang=de|Label=MQTT_GENERIC_BRIDGE}}. Da ''MQTT_DEVICE'' payload im JSON-Format (im Unterschied zu MQTT2_DEVICE) nicht selbst verarbeiten kann wird hier zusätzlich das Modul {{Link2CmdRef|Anker=expandJSON|Lang=de|Label=expandJSON}} benötigt, um den {{Link2Forum|Topic=66761|LinkText=JSON String auszuwerten}}.

=== Performancefragen... ===
...oder was sollte man als Lösung wählen, wenn man in die MQTT-Welt einsteigt<ref>vgl. hierzu diesen {{Link2Forum|Topic=94768|Message=875714|LinkText=Beitrag}} von Rudolf König</ref>?
Grundsätzlich sollte man davon ausgehen, dass innerhalb von FHEM die Verarbeitung derselben Daten näherungsweise denselben Aufwand bedeuten, unabhängig davon, welche der Implementierungen (''MQTT2_CLIENT'', ''MQTT'' oder ''MQTT2_SERVER'') man konkret wählt.
Ein externer Broker hat daher vor allem dann Vorteile, wenn die MQTT Daten überwiegend für was anderes (nicht FHEM) verwendet werden, oder MQTT zweckentfremdet wird (wie z.Bsp. für Musikübertragung). Nutzt man das MQTT-Protokoll dagegen vorwiegend innerhalb von FHEM, ist eher der Einsatz von MQTT2_SERVER in Betracht zu ziehen. Dieser soll Anfängern die Anbindung von MQTT Geräten in FHEM einfacher machen. Wer später merkt, dass er doch einen externen Broker benötigt, kann dann immer noch auf MQTT2_CLIENT in Verbindung mit einem anderen Broker wechseln.
Dagegen ist der Weg von MQTT_DEVICE zu MQTT2_DEVICE mit erheblich mehr Aufwand verbunden.

=== Kommunikation zu sonstigen FHEM-Geräten über MQTT ===

Möchte man Daten von einem [[Gerät]] (im FHEM-Sinn), das '''nicht''' vom Typ ''MQTT2_DEVICE'' oder ''MQTT_DEVICE'' (je nach IO-Modul) ist, per MQTT-Protokoll versenden (z.B. für eine andere Visualisierungslösung als FHEMWEB, oder als FHEM2FHEM-Ersatzlösung), oder diese sonstigen Geräte über MQTT-Anweisungen von außen steuern können, hat man mehrere Möglichkeiten:

==== MQTT_GENERIC_BRIDGE ====
Das Modul {{Link2CmdRef|Anker=MQTT_GENERIC_BRIDGE|Lang=en|Label=MQTT_GENERIC_BRIDGE}} ermöglicht es, sein jeweiliges IO-Modul-Gerät zu nutzen, um diesen Kommunikationsweg für beliebig viele andere FHEM-Geräte bereitzustellen. Dabei erfolgt am MQTT_GENERIC_BRIDGE-Gerät selbst nur eine Basiskonfiguration, im Übrigen durch Attribute an dem jeweiligen Gerät selbst. So kann z.B. ein Aktor des Typs [[CUL_HM]] an- oder ausgeschaltet werden oder auch einfach nur seinen aktuellen Schaltzustand per MQTT-Protokoll publizieren.

Dieses Modul kann seit November 2018 mit allen drei IO-Modul-Varianten zusammen eingesetzt werden, also sowohl mit ''MQTT2_SERVER'' bzw. ''MQTT2_CLIENT'' oder ''MQTT'' (00_MQTT.pm).

Dabei sollte man jedoch beachten, dass zur Verwendung mit den MQTT2-IO's unbedingt die autocreate-Funktion des betreffenden IOs ausgeschaltet wird und dies auch bleibt<ref>siehe dazu diesen {{Link2Forum|Topic=95341|LinkText=Thread}} zu den technischen Hintergründen</ref>! Weiter wird das Perl-Modul ''libmodule-pluggable-perl'' benötigt<ref>Dieses kann über <code>apt-get install libmodule-pluggable-perl</code> installiert werden</ref>, damit im Hintergrund auch das Modul [[MQTT (Modul)|MQTT]] geladen werden kann. Damit gelten auch für diesen Modul die Installationsvoraussetzungen für [[MQTT#MQTT_.28Modul.29|MQTT]]!

Anwendungsfälle und -beispiele für das Modul sind diesem {{Link2Forum|Topic=91642|LinkText=Thread}} zu entnehmen.

==== MQTT_BRIDGE ====
Dieses Modul kann nur zusammen mit einem IO-Gerät des Typs [[MQTT (Modul)|MQTT]] verwendet werden. Dabei wird pro weiterzuleitendem anderen FHEM-Gerät eine eigene Instanz dieses Moduls verwendet. Auf den Einsatz dieser Option sollte in neuen Installationen zugunsten von ''MQTT_GENERIC_BRIDGE'' verzichtet werden.

==== Per publish-Befehl am IO-Gerät ====
Alle drei IO-Module kennen direkte ''publish''-Anweisungen, mit deren Hilfe beliebige ''payloads'' an beliebige ''topics'' gesendet werden können. Dies kann man z.B. in einem [[notify]] oder [[at]] nutzen, um einzelne Events zu publishen oder Werteanfragen abzusetzen.

Hier eine regelmäßige Werteabfrage auf einen [[EBUS-MQTT2|ebus]]:
defmod get_ebus_updates at +*00:15:00 set ebusMQTT publish ebusd/430/Hc1HeatCurve/get;
set ebusMQTT publish ebusd/430/HwcTempDesired/get;
...

==== RAW-Events am IO-Gerät (MQTT2.*) ====
Bei beiden MQTT2-IO-Modulen (MQTT2_SERVER und MQTT2_CLIENT) kann per [[Regulärer Ausdruck|regulärem Ausdruck]] festgelegt werden, welche Nachrichten ein Event erzeugen sollen, auf das dann wieder z.B. mit einem [[notify]] reagiert werden kann, z.B. um beliebige Schaltaktionen auszulösen.

== MQTT-Clients (Beispiele) ==

===Arduino-library===
Zur Kommunikation mit dem Broker von Seiten eines [[Arduino|Arduinos]] mit selbst erstellten Sketches böte sich der PubSubClient an.

===PC-Software===
Um die Funktionalität des Brokers zu testen kann z.B. ein Analyse-Tool wie MQTT.fx verwendet werden, oder die im Paket ''mosquitto-clients'' enthaltenen Linux-Kommandozeilen-Programme ''mosquitto_sub'' und ''mosquitto_pub''. Letzterer könnte z.E. auch aus beliebigen ''shell-scripten'' heraus aufgerufen werden. Als Perl-Bibliothek steht alternativ z.B. [https://metacpan.org/pod/distribution/AnyEvent-MQTT/bin/anyevent-mqtt-pub anyevent-mqtt-pub] zur Verfügung.

=== Tasmota ===
Eine derzeit oft genutzte Möglichkeit für MQTT bilden die [[Sonoff]]-Geräte und weitere [[ESP8266]]-basierte Hardware, die unter vielen Handelsnamen erhältlich sind. Werden diese mit Tasmota ('''T'''heo '''A'''rends '''S'''onoff '''M'''QTT '''O'''ver '''T'''he '''A'''ir - einer offenen Firmware von [https://github.com/arendst arendst]) geflasht, so kommunizieren sie über MQTT. Um diese Geräte einzubinden, ist wie folgt vorzugehen. Zuerst ist ein Serverdienst (Broker) bereitzustellen, wie oben beschrieben.

Unter Sonoff sind einige Topics voreingestellt. arendst stellt insbesondere drei Topic-Präfixe bereit, die seiner Meinung jedes Topic einleiten sollen (in den Eingabemasken als "%prefix%" notiert). Das sind einmal Kommandos (abgekürzt als cmnd), die dazu dienen, Befehle auszuführen. Daten werden mit tele und stat übertragen. Ein Topic besteht dann zuerst aus diesem Präfix und danach dem eigentlichen Topic. Wer also beispielsweise einem Sonoff_Switch einen Befehl senden will, sollte als Topic cmnd/Sonoff_Switch wählen. Wenn der Switch ein- und ausgeschaltet werden kann, muss der Topic noch das Wort POWER enthalten (in MQTT werden viele Kennworte komplett groß geschrieben). Der Topic lautet damit vollständig "cmnd/Sonoff_Switch/POWER/set"

{{Randnotiz|RNTyp=g|RNText=Dabei ist darauf zu achten, dass für den Parameter ''topic = %topic% (sonoff)'' statt ''sonoff'' ein gerätespezifischer eigener Name eingetragen wird. Hierzu kann man z.B. auch die dynamisch aus der Chip-ID erzeugte Kennung ''DVES_%06X'' verwenden, indem man die unter ''client (DVES_8BABA9)'' zu findende Angabe kopiert. Die eigentliche Umbenennung zu einem "sprechenden Namen" kann dann innerhalb von FHEM - mittels ''rename'' oder ggf. mit einem ''alias'' - erfolgen.}}

Link zum Forum: {{Link2Forum|Topic=27532|LinkText=MQTT FHEM Einrichtung}} (hier als ''MQTT_DEVICE''!):

### FHEM Device mit MQTT verbinden ###
define Sonoff_Switch MQTT_DEVICE
attr Sonoff_Switch IODev myBroker
attr Sonoff_Switch devStateIcon ON:rc_GREEN:OFF OFF:rc_RED:ON
attr Sonoff_Switch icon hue_filled_br30
attr Sonoff_Switch publishSet ON OFF cmnd/TestSwitch/POWER
attr Sonoff_Switch room MQTT
attr Sonoff_Switch subscribeReading_Licht stat/Sonoff_Switch/POWER
attr Sonoff_Switch subscribeReading_Sensor tele/Sonoff_Switch/SENSOR
attr Sonoff_Switch subscribeReading_Status stat/Sonoff_Switch/STATUS
attr Sonoff_Switch webCmd ON:OFF

Der hier dargestellte Beispielcode realisiert die Kommunikation zwischen FHEM und dem sonoff Modul via MQTT Broker. Zu beachten ist hier, dass '''subscribeReading_Licht''' und '''subscribeReading_Status''' unterschiedliche Syntax des Topic Strings haben!

=== OpenMQTTGateway ===

== Sicherheit ==
Prinzipiell ist MQTT ebenso sicher wie eine Postkarte. Solange man es nicht extra absichert, kann jeder der, im eigenen LAN ist (und die Adresse vom Broker kennt) alle Topics mitlesen.
:<code>meinHaus/Flur/Haustuer:open / close</code>
bietet unter diesen Umständen reichlich Raum für Verbesserungen!

Abhilfe:
=== Username / Passwort ===
Zunächst kann man erst mal einen Username / Passwort vergeben, was alle IO-Device-Module unterstützen. Da ist zwar auch noch lange nicht sicher, aber zumindest steigert es den Aufwand schon mal. Jetzt muss man zumindest schon mal Pakete sniffen und verstehen, um unbefugt zu lesen oder gar zu publishen.

=== TLS ===
Um wirklich sicher zu werden, führt kein Weg an TLS vorbei.

Der MQTT-Client in [[#Tasmota|Tasmota]] (für ESP8266) kann mit TLS betrieben werden, vgl. [https://github.com/arendst/Tasmota/wiki/TLS Beschreibung im Tasmota-Wiki].

Leider kann z.B. ein Arduino das schlicht nicht mehr, da die einfacheren Modelle nicht über ausreichend Speicher und die Rechenleistung verfügen.

'''(Hier fehlt eine Anleitung für allowed usw.)'''

== Probleme ==
=== Anweisung und Ergebnis weichen voneinander ab ===
In der Regel melden MQTT-fähige Geräte entweder den Erhalt einer Nachricht zurück oder den Status nach Durchführung der in der ''payload'' enthaltenen Anweisung. Dabei findet aber in der Regel beim Empfänger eine Verarbeitung der Nachricht statt, ggf. wird diese auch weitergesendet und nochmals verarbeitet, bevor dann ggf. eine Rückmeldung des neuen Status an den MQTT-Server erfolgt. Handelt es sich um einfache on/off-Befehle, bleibt Anweisung und Ergebnis in der Regel identisch. Bei anderen, namentlich bei Dimmer-Werten, kann es zu Rundungsdifferenzen bei nummerischen Werten kommen. So kann z.B. ein Dimm-Wert von 70% gesetzt werden, zürückgemeldet wird dann aber 72% (oder 67%).
Dies ist technisch bedingt, vermeiden kann das jedoch in aller Regel nur der Autor der jeweiligen software/firmware auf dem "rechnenden" Gerät.

=== Unbeabsichtigte Schleifen ===
Durch Fehler in der topic-Struktur können unbeabsichtigte Schleifen entstehen, die FHEM komplett blockieren können. Es ist unbedingt darauf zu achten, dass die jeweiligen Sende- und Empfangs-topics andere sind!

== Links ==
* [http://mqtt.org Offizielle Homepage von MQTT, englisch]
* [http://www.hivemq.com/blog/mqtt-essentials-part-1-introducing-mqtt Sehr gute Einführung, englisch, sind 5 lesenswerte Teile]
* [https://www.heise.de/developer/artikel/MQTT-Protokoll-fuer-das-Internet-der-Dinge-2168152.html Ein Exkurs von Heise mit Beispielen, deutsch, sehr lesenswert]
* [http://www.mqttfx.org/ MQTT FX - ein sehr praktisches Analysetool]
* {{Link2Forum|Topic=69230|LinkText=Diskussionsthread im Forum}}
* {{Link2Forum|Topic=92888|LinkText=Thread, zur Entstehungsgeschichte von MQTT2_CLIENT}}
* {{Link2Forum|Topic=93255|LinkText=Ankündigungsthread zur MQTT2-Erweiterung der MQTT_GENERIC_BRIDGE}}
* [[MQTT_Einf%C3%BChrung_Teil_2|Teil 2 der MQTT Einführung]]: Detailaspekte (vorrangig zur Modulfamilie MQTT/MQTT_DEVICE)
* [[MQTT Einführung Teil 3|Teil 3 der MQTT Einführung]]: Arduino-Client selbst programmieren

== Hinweise ==
<references />

[[Kategorie:Glossary]]
[[Kategorie:HOWTOS]]
[[Kategorie:MQTT|Einführung]]
[[Kategorie:MQTT| ]]

DbLog

2017-11-03T15:33:39Z

Rspecht: /* Beispiel: Anlegen und Nutzung einer Mysql-Datenbank */

{{Infobox Modul
|ModPurpose=Protokolliert Ereignisse in einer Datenbank
|ModType=h
|ModForumArea=Automatisierung
|ModTechName=93_DbLog.pm
|ModOwner=tobiasfaust ({{Link2FU|118|Forum}}/[[Benutzer Diskussion:Tobias.faust|Wiki]])
}}

== Einleitung ==
Mit der Zeit entstehen im fhem recht umfangreiche Log-Daten für die verschiedensten konfigurierten Devices. Die übliche Einstiegs-[[Konfiguration]] sieht vor, dass die Logs als [http://fhem.de/commandref_DE.html#FileLog FileLog] gespeichert werden - je nach Einstellung in wenigen sehr großen oder vielen kleineren Dateien. Der Datei-basierte Zugriff ist allerdings nicht wirklick performant und kann schnell zum Flaschenhals werden (z.B. bei der Darstellung von Graphen über einen längeren Zeitraum).

Alternativ kann Fhem die Log-Daten mittels [http://fhem.de/commandref_DE.html#DbLog DbLog] in einer Datenbank speichern. Diese kann lokal als einfache SQLite- oder als zentrale Server-Datenbank (s.u.) gestaltet sein. Schon eine lokale einfache SQLite-Datenbank ist in der Regel deutlich performanter als File-basierte Logs.

Damit eine Datenbank-Nutzung möglich ist, müssen folgende Anpassungen gemacht werden:
# [[#Datenbank|Erstellen einer entsprechenden Datenbank]]
# [[#Datenbank-Anbindung mittels db.conf|Konfiguration der Datenbank-Anbindung in FHEM]]
# [[#Konfiguration als Device in fhem.cfg|Anpassen aller (oder einzelner) Konfigurationen von FileLog nach DbLog]]
# [[#Anpassen der gplot-Konfigurationen|Ggf. Anpassen der gplot-Konfigurationen]]

== Konfiguration ==
=== Datenbank-Anbindung mittels db.conf ===
DbLog wird durch 2 verschiedene Einträge aktiviert/definiert. In einer Datei namens '''db.conf''' werden die Parameter für eine Verbindung zur Datenbank (host, username, password, etc.) hinterlegt. Diese Datei kann in einem beliebigen Verzeichnis angelegt werden. Für eine MySQL-Datenbank sieht die db.conf folgendermaßen aus:

%dbconfig= (
connection => "mysql:database=fhem;host=db;port=3306",
user => "fhemuser",
password => "fhempassword",
);

Im Verzeichnis '''contrib/dblog''' der FHEM-Installation befindet sich eine Beispielkonfiguration mit der Syntax für jeden unterstützen Datenbanktyp.
Es wird empfohlen diese Datei zu kopieren und erst dann entsprechend zu bearbeiten. Am Besten kopiert man diese Datei in das FHEM Home Directory /opt/fhem/ und achtet auf die entsprechenden Rechte!
chown fhem:dialout /opt/fhem/db.conf

=== Konfiguration als Device ===
Das DbLog Device wird dann definiert mit
:<code>define <name> DbLog <configfilename> <regexp> </code>
wobei ''<configfilename>'' dem Pfad zur zuvor angelegten db.conf entspricht.
Ein Beispiel hierfür wäre:
:<code>define logdb DbLog ./db.conf .*:.* </code>
Die Angabe von <code>.*:.*</code> bedeutet, dass sämtliche DeviceMessages (Messwerte, Batteriestatus, KeepAlives, etc.) in die Datenbank geschrieben werden. Dies führt u.U. dazu, dass die Datenbank auch mit vielen teils irrelevanten Werten gefüllt wird. Man kann daher die zu loggenden Werte einschränken, indem man genau angibt welche Werte übertragen werden sollen. Dies ist in [[#Finetuning des Loggings]] beschrieben.

=== Finetuning des Loggings ===
Bei der Konfiguration des Log-Devices werden die zu loggenden Daten definiert - in der einfachsten Form sieht das so aus: <code>define logdb DbLog ./db.conf .*:.* </code>. Die Angabe von <code>.*:.*</code> bedeutet, dass sämtliche DeviceMessages (Messwerte, Batteriestatus, KeepAlives, etc.) in die Datenbank geschrieben werden. Dies führt u.U. dazu, dass die Datenbank auch mit sehr vielen und teils nicht benötigten Werten gefüllt wird und schnell wächst. Die Datenbank ist zwar deutlich leistungsfähiger, was große Datenmengen angeht, Datensparsamkeit kann aber schnell sinnvoll werden...

Um das Log-Aufkommen einzugrenzen gibt es 2 Ansätze:
* Einschränkung über den <code>define</code>-Eintrag
* Einschränkung über DbLogExclude-Einträge der jeweiligen Devices
* Einschränkung über DbLogInclude-Einträge des jeweiligen Devices

==== Einschränkung über den zentralen <code>define</code>-Eintrag ====
Man kann die zu loggenden Werte einschränken, indem man genau angibt welche Werte übertragen werden sollen. Die erste Wildcard, also das erste <code>.*</code>, entspricht dem in FHEM verwendeten Device-Namen. Die zweite Wildcard entspricht dem vom Device ausgegebenen zu loggenden Wert. Separiert werden beiden Angaben durch einen Doppelpunkt.

Ein Beispiel, um zwar alle definierten Devices zu erfassen, aber nur die Werte Temperatur, Ventilposition und Luftfeuchte in die Datenbank zu schreiben wäre:
:<code>define myDbLog DbLog ./db.conf .*:(temperature|valveposition|humidity).* </code>

==== Einschränkung über die jeweiligen Devices ====
Man kann die zu loggenden Werte für einzelne Devices separat einschränken, ohne dies im zentralen define-Eintrag machen zu müssen. Dies kann interessant sein, wenn beispielsweise ein Device Fehlerwerte meldet, die uninteressant sind, oder es meldet unnötig häufig Werte - beides ist z.B. bei 1-wire-Temperatursensoren gerne der Fall.

Um das einzuschränken gibt es 2 Stellparameter, die als Attribute direkt zum jeweiligen Device konfiguriert werden:
* DbLogExclude - definiert Werte, die nicht geloggt werden sollen
* DbLogInclude - definiert Werte, die geloggt werden sollen ( siehe attr DbLogSelectionMode )
* event-min-interval, event-on-change-reading und event-on-update-reading beeinflussen, wie häufig Werte geloggt werden (vgl. [http://fhem.de/commandref_DE.html#event-on-update-reading commandref])

Eine konkrete Konfiguration für einen sehr gesprächigen 1-wire-Temperatursensor könnte wie folgt aussehen:
<pre>
define EG_Balkon GPIO4 BUSMASTER
attr EG_Balkon DbLogExclude failures,T,85 # logge keine "failures", "T"-Werte und "85"-Werte (default-Werte, wenn keine Temperatur gelesen werden kann)
attr EG_Balkon event-on-change-reading state # logge nur, wenn sich ein Wert ändert (wenn sich die Temperatur nicht ändert, logge das nicht)
attr EG_Balkon event-min-interval state:900 # logge spätestens alle 900sec = 15min
attr EG_Balkon event-on-update-reading .* # logge alle Werte, die aktualisiert werden

attr <1-Wire-Device vom Typ OWTHERM oder OWSWITCH> DbLogExclude data.* # verhindert das Logging der state-Eintragungen
</pre>

Eine in diesem {{Link2Forum|Topic=33697|Message=264127}} vorgestellte Strategie zur Vermeidung unnötigen Loggings ist, dass bei der Definition von Devices durch das nachfolgende <code>notify</code> automatisch ein DbLogExclude für alle Werte (.*) des Devices zugewiesen wird und dies nur bei Interesse an geloggten Werten gelöscht bzw. angepasst wird:
<code>define nDbLogExclude notify global:DEFINED.* attr $EVTPART1 DbLogExclude .*</code>

Ebenso ist es mittlerweile möglich, lediglich erwünschte Werte (Positiv-Liste) zu loggen und alle anderen zu verwerfen. Hierfür wird im LogDevice das attribut DbLogSelectionMode Include verwendet. Nun kann für jedes Device mit DbLogInclude <Reading1>,<Reading2>,... angegeben werden, welche Readings geloggt werden sollen.
Integriert ist ebenfalls ein "min-interval", siehe commandref.

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

=== Tabellen ===
Die Datenbank ist relativ simpel gestaltet und besteht lediglich aus den folgenden beiden Tabellen:
* current
* history

DbLog ist auf eine feste Tabellenstruktur angewiesen. Man muss daher in seiner Datenbank eine Tabelle mit folgenden Spalten anlegen:
{| class="wikitable"
|-
! Spalte
! Beschreibung (en)
! Beschreibung (de)
! Beispiel
|-
| '''TIMESTAMP'''
| timestamp of event
| Zeitstempel
| 2007-12-30 21:45:22
|-
| '''DEVICE'''
| device name
| Device-Name
| Wetterstation
|-
| '''TYPE'''
| device type
| Device-Typ
| KS300
|-
| '''EVENT'''
| event specification as full string
| Eventspezifikation als Text
| humidity: 71 (%)
|-
| '''READING'''
| name of reading extracted from event
| Bezeichnung des Readings
| humidity
|-
| '''VALUE'''
| actual reading extracted from event
| Wert des Readings
| 71
|-
| '''UNIT'''
| unit extracted from event
| Einheit des Readings
| %
|-
|}

Die Vorlagen zur Anlage von Tabellen und Indizes sind für jeden unterstützten Datenbanktyp im Verzeichnis '''contrib/dblog''' der FHEM-Installation, oder hier zu finden: [https://svn.fhem.de/trac/browser/trunk/fhem/contrib/dblog/ Link]. Das MySQL-Skript (db_create_mysql.sql) legt eine neue Datenbank, das PostGres-Skript (db_create_postgresql.sql) ein neues Schema mit Namen "fhem" an.

==== current ====
Die Tabelle current enthält für jedes zu loggende Device lediglich den letzten Wert. Falls noch kein Wert geloggt wurde, ist diese Tabelle leer.
Falls der Inhalt gelöscht wird, bauen sich die Daten automatisch wieder auf. Es gehen durch das löschen der Tabelle current keine Log-Informationen verloren.
Der Inhalt wird aber u.a. für die Dropdown-Felder beim Plot-Editor verwendet.

Um doppelte Einträge in der Tabelle zu vermeiden, wurden die Möglichkeit geschaffen Primary Keys zu definieren. Da in der Spalte <code>READING</code> u.U. bei verschiedenen Geräten gleiche Namen vorkommen können, sollte der Primary Key um den Gerätenamen erweitert werden. Der Primary Key sollte also aus <code>DEVICE</code> und <code>READING</code> bestehen. Um in der Datenbank ''fhem'' diesen PK zu setzen, kann folgender SQL Code verwendet werden:

<syntaxhighlight lang="sql">
ALTER TABLE `fhem`.`current`
CHANGE COLUMN `DEVICE` `DEVICE` VARCHAR(64) CHARACTER SET 'utf8' COLLATE 'utf8_bin' NOT NULL ,
CHANGE COLUMN `READING` `READING` VARCHAR(64) CHARACTER SET 'utf8' COLLATE 'utf8_bin' NOT NULL ,
ADD PRIMARY KEY (`DEVICE`, `READING`);
</syntaxhighlight>

==== history ====
Die Tabelle history enthält alle bisher geloggten Daten. Löschen in dieser Tabelle bedeutet automatisch Datenverlust (gewollt oder nicht ... )
Der Inhalt dieser Tabelle wird verwendet, um die Plots zu zeichnen oder Auswertungen mit [https://wiki.fhem.de/wiki/DbRep_-_Reporting_und_Management_von_DbLog-Datenbankinhalten DbRep] anzufertigen

== Anpassen der gplot-Konfigurationen ==
Die meisten gplot-Konfigurationen sind bisher lediglich auf FileLog-Konfigurationen ausgelegt. Deshalb müssen sie für die Verwendung mit DbLog angepasst werden. Glücklicherweise beschränkt sich dies auf die reinen FileLog-Zeilen - es müssen die DbLog-Äquivalente hinzugefügt werden. Die FileLog-Einträge müssen zwar nicht gelöscht werden, wenn man aber FileLog und DbLog parallel betreibt, sollte man getrennte gplot-Dateien für beide Logging-Typen haben um Auswertungsprobleme erkennen zu können.

Für die fht.gplot Konfiguration sähe die Anpassung wie folgt aus (lediglich die vier DbLog-Zeilen wurden hinzugefügt):
<pre>
# Created by FHEM/98_SVG.pm, 2014-12-25 21:53:30
set terminal png transparent size <SIZE> crop
set output '<OUT>.png'
set xdata time
set timefmt "%Y-%m-%d_%H:%M:%S"
set xlabel " "
set title '<L1>'
set ytics nomirror
set y2tics
set grid y2tics
set ylabel "Actuator/Window (%)"
set y2label "Temperature in C"
set yrange 0:100
set y2range 5:25

#FileLog 4:.measured-temp\x3a:0:
#FileLog 4:.actuator\x3a:0:int
#FileLog 4:.desired-temp::
#FileLog 4:.window\x3a::

#DbLog <SPEC1>:.measured-temp:0:
#DbLog <SPEC1>:.actuator:0:int
#DbLog <SPEC1>:.desired-temp::
#DbLog <SPEC1>:.window::

plot "<IN>" using 1:2 axes x1y2 title 'Measured temperature' ls l0 lw 1 with lines,\
"<IN>" using 1:2 axes x1y1 title 'Actuator (%)' ls l1 lw 1 with lines,\
"<IN>" using 1:2 axes x1y2 title 'Desired Temperature' ls l2 lw 1 with steps,\
"<IN>" using 1:2 axes x1y1 title 'Window' ls l3 lw 1 with steps
</pre>

Des weiteren ist zu beachten:

On-Off-Plots

EG_Bad:window:::$val=~s/(on|off)(\d*).*/$1eq"on"?1:0/eg

unter Berücksichtigung von dim-Werten:

EG_WoZi_Licht:value:::$val=~s/(on|off)(\d*).*/$1eq"on"?1:($1eq"dim"?$2*0.01:0)/eg

== Beispiel: Anlegen und Nutzung einer SQLite-Datenbank ==
Im folgenden wird eine lokale SQLite-Datenbank auf einen Ubuntu-System angelegt (nach Quelle: [http://www.tatsch-it.de/fhem-dblog/ http://www.tatsch-it.de/fhem-dblog/])
<ol>
<li>
''Installation von SQLite:''
<pre>sudo aptitude install sqlite3 libdbi-perl libdbd-sqlite3-perl</pre>
</li>
<li>
''Anlegen der SQLite-Datenbank fhem.db'' (öffnet auch direkt eine SQL-Kommandozeile):
<pre>sudo sqlite3 /opt/fhem/fhem.db</pre>
In der geöffneten SQL-Kommandozeile eingeben:
<pre>
CREATE TABLE 'history' (TIMESTAMP TIMESTAMP, DEVICE varchar(64), TYPE varchar(64), EVENT varchar(512), READING varchar(64), VALUE varchar(128), UNIT varchar(32));
CREATE TABLE 'current' (TIMESTAMP TIMESTAMP, DEVICE varchar(64), TYPE varchar(64), EVENT varchar(512), READING varchar(64), VALUE varchar(128), UNIT varchar(32));
CREATE INDEX Search_Idx ON `history` (DEVICE, READING, TIMESTAMP);
</pre>
Die Kommandozeile verlässt man mit <code>.exit</code>.
</li>
<li>
''Anpassen des Besitzers und der Rechte der Datenbank-Datei:''
<pre>
sudo chown fhem /opt/fhem/fhem.db
sudo chmod 666 /opt/fhem/fhem.db
</pre>
</li>
<li>
''Datenbank-Anbindung des FHEM konfigurieren:''
<pre>sudo nano /opt/fhem/db.conf</pre>
Inhalt:
<pre>
%dbconfig= (
connection => "SQLite:dbname=/opt/fhem/fhem.db",
user => "",
password => ""
);
</pre>
</li>
<li>
''Logging des FHEM auf die Datenbank konfigurieren:'' (hier sind nur die Anpassungen aufgeführt)
<pre>sudo nano /opt/fhem/fhem.cfg</pre>
<pre>
...
attr global userattr DbLogExclude ... # erlaubt es einzelne Einträge nicht zu loggen
...
define logdb DbLog ./db.conf .*:.* # logt alle(!) auflaufenden Events aller Konfigurationen
...
</pre>
Da durch diese <code>define</code>-Definition alle auflaufenden Events gelogt werden, müssen keine weiteren Anpassungen in der Konfiguration gemacht werden. Die FileLog-Einträge können bedenkenlos bestehen bleiben - dann wird in Datenbank und FileLog gelogt und man verliert keine Daten, falls etwas nicht klappt. Wenn alles wie geplant läuft, können die FileLog-Definitionen gelöscht werden (ebenso die Log-Dateien). Ebenso können die zu loggenden Daten später eingegrenzt werden (s. [[#Finetuning des Loggings]]).
</li>
<li>
''FHEM neu starten:''
<pre>
sudo service fhem stop
sudo service fhem start
</pre>
</li>
<li>
''Kontrollieren, ob Logs in die Datenbank geschrieben werden:''
<pre>sudo sqlite3 /opt/fhem/fhem.db</pre>
In der geöffneten SQL-Kommandozeile eingeben:
<pre>
select * from history order by TIMESTAMP; # dies gibt alle(!) Logs chronologisch aus (kann nach längerem Betrieb recht lange dauern)
</pre>
Die Kommandozeile verlässt man mit <code>.exit</code>.
</li>
<li>
''Anpassung der glot-Dateien:'' siehe [[#Anpassen der gplot-Konfigurationen]]
</li>
</ol>

== Beispiel: Anlegen und Nutzung einer Mysql-Datenbank ==
Anstatt nano kann jeder andere kompatible Editor verwendet werden. Weiterhin bitte beachten, dass die hier genannten Befehle teilweise root-Rechte voraussetzen. Entweder komplett als root arbeiten, oder mittels sudo.

Unter Ubuntu/debian:
apt-get update && apt-get install mysql-server mysql-client libdbd-mysql libdbd-mysql-perl

Bei der Installation sollte man aus Sicherheitsgründen ein Passwort für den mysql-root vergeben, wenn man nicht sogar ganz den Login verbietet.

Hinweis: im Folgenden ist "#" der normale Prompt und "mysql>" der prompt innerhalb mysql, dieser kann mit exit verlassen werden.

Zum Test mal mit mysql verbinden:
# mysql -p -u root
Enter password:
mysql> exit

Jetzt die Tabellenstruktur anlegen.
Hierfür kann die Datei /opt/fhem/contrib/dblog/db_create_mysql.sql als Vorlage verwendet und das Passwort und der Benutzername geändert werden.
cd /opt/fhem/contrib/dblog/
nano db_create_mysql.sql
Dann wird die Datei eingelesen (root Passwort wird abgefragt):

# mysql -u root -p < db_create_mysql.sql

Jetzt kann man den Zugang testen:

# mysql -p -u <fhemuser>
Enter password: <fhempassword>
mysql> show databases;

Nun müsste eine Datenbank "fhem" angezeigt werden, die die Tabellen current und history enthält.

Nun in der Datei db.conf den mysql-Block auskommentieren und ebenfalls Benutzername, Passwort UND HOST anpassen. Leider ist hier nicht standardmäßig localhost eingestellt.
nano /opt/fhem/db.conf

Jetzt kann unter FHEM ein DbLog-Device angelegt werden (mit dem beispiel wird alles geloggt:
define logdb DbLog ./db.conf .*:.*
Als State muss ein "connected" angezeigt werden.

Ein rereadcfg in Fhem stellt sicher, dass die neue Konfiguration übernommen wird - ein Neustart ist nicht erforderlich

Nun kann die Funktion noch einmal überprüft werden:
<syntaxhighlight lang="sql">
# mysql -u <fhemuser> -p
Enter password: <fhempassword>
mysql> use fhem;
Database changed
mysql> show tables;
+----------------+
| Tables_in_fhem |
+----------------+
| current |
| history |
+----------------+
2 rows in set (0,00 sec)
mysql> select * from history; # Achtung, kann sehr groß werden .... #
</syntaxhighlight>

== Beispiel: Abfragescript PHP/MySQL ==
Um eine schnelle Übersicht zu bekommen habe ich mir dieses Script geschrieben:
<syntaxhighlight lang="php"><?php $pdo = new PDO('mysql:host=localhost;dbname=fhem', 'fhemuser', 'fhempasswort');
echo '<h2>Tabelle Current</h1> <table border="1">';
echo "<tr><th>Anzahl</th><th>Name</th><th>Readings</th></tr>";
$sql = "SELECT COUNT(*), DEVICE, GROUP_CONCAT(DISTINCT READING ORDER BY READING DESC SEPARATOR '</li><li>') FROM current GROUP BY DEVICE;"; foreach ($pdo->query($sql) as
$row) {
echo "<tr><td>" . $row[0] . "</td><td>" . $row[1] . "</td><td><ol><li>" . $row[2] . "</li></ol></td></tr>";
}
echo "</table>";

echo '<h2>Tabelle History</h1> <table border="1">';
echo "<tr><th>Anzahl</th><th>Name</th></tr>";
$sql = "SELECT COUNT(*), DEVICE FROM history GROUP BY DEVICE;"; foreach ($pdo->query($sql) as
$row) {
echo "<tr><td>" . $row[0] . "</td><td>" . $row[1] . "</td></tr>";
}
echo "</table>";
?>
</syntaxhighlight>

Bitte passt fhemuser und fhempasswort an. Das ganze kommt dann nach ''/var/www/html/fhemdb.php'' und ist mit ''<IP>/fhemdb.php'' aufrufbar. Wenn ihr den 2. Block für die history Tabelle ausklammert oder entfernt läuft das Script viel schneller ab - klar die history Tabelle ist meist randvoll.

== Integration von DBLog in eigene Module ==
=== Bereitstellung der UNITS ===
Mit der DbLog_splitFn kann der Modulautor selbst festlegen, wie die Events des Moduls in die Bestandteile Reading/Value/Unit zerlegt werden um ein korrektes Logging per DbLog zu gewährleisten.

Dazu muss der Modulautor in der [[DevelopmentModuleIntro#X_Initialize|Initialize-Funktion]] eine <code>DbLog_splitFn</code> bereitstellen:

<syntaxhighlight lang="perl">
sub X_Initialize($)
{
my ($hash) = @_;
...
$hash->{DbLog_splitFn} = "X_DbLog_splitFn";
}
</syntaxhighlight>

Die genaue Aufrufsyntax und Funktionweise einer DbLog_split-Funktion findet man [[DevelopmentModuleIntro#X_DbLog_split|hier]].

== Werte auslesen ==
Manchmal möchte man Daten aus den Logs abrufen ohne händisch in der Datenbank herumzuwühlen (s.u.). Dies ist insb. auch dann hilfreich, wenn man eigenen Funktionen, Notifys oder spezielle Plots entwirft, bei denen man auf Logdaten zugreifen möchte.

Grundsätzlich beschrieben ist dies in der [http://fhem.de/commandref_DE.html#DbLog commandref#DbLog] und unterscheidet sich minimal (aber entscheidend) von der Struktur bei [[FileLog#Werte_auslesen|FileLogs]].

Hier ein paar Beispiele, was man damit anstellen kann:

* <code>get meineDB - - 2016-10-01 2016-10-03 meinSensor</code> alle Einträge des meinSensor vom 01.10.-03.10.2016
* <code>get meineDB - - 2016-10-01_08:00:00 2016-10-01_16:00:00 meinSensor</code> alle Einträge des meinSensor von 8-16 Uhr am 01.10.2016
* <code>get meineDB - - 2016-10-01_08:00:00 2016-10-01_16:00:00 meinSensor:temperature</code> nur die temperature Werte
* <code>{ ReadingsTimestamp("meinSensor","state","0") }</code> Timestamp des aktuellen state des meinSensor
* <code>{ OldTimestamp("meinSensor") }</code> Timestamp des letzten state des FHT_3a32
* <code>{ time_str2num(OldTimestamp("meinSensor")) }</code> Timestamp in Sekunden des letzten state des meinSensor
* ...

== Bearbeitung von Datenbank-Einträgen ==
{{Hinweis|Dieser Abschnitt soll lediglich eine kleine Einführung in die Datenbank-Bearbeitung liefern. Für vertiefende Informationen sollte man sich grundsätzlich mit SQL beschäftigen. Eine umfassende und gut verständliche Anleitung zu SQL bietet bspw. [http://www.w3schools.com/sql/default.asp w3schools].}}
Irgendwann wird der Fall eintreten, dass in der Datenbank Einträge drinstehen, die geändert oder gelöscht werden sollen (zB. fehlerhafte Sensor-Rückmeldungen, umbenannte Readings). In klassischen Log-Dateien würde man diese einfach bearbeiten und löschen/anpassen (wobei man aber tunlichst zuvor den fhem ausmacht um Datenfehler zu vermeiden). Eine Datenbank kann bearbeitet werden ohne den fhem abschalten zu müssen.

Datenbanken kann man ohne weiter Hilfsmittel direkt von der Kommandozeile/Shell aus bearbeiten. Alternativ gibt es auch verschiedenste Tools (webbasiert oder als Applikation), die einen dabei unterstützen (Bsp. findet man u.a. [https://wiki.ubuntuusers.de/SQLite/#Grafische-Benutzeroberflaechen hier]). Für einfache Arbeiten reicht allerdings idR. Shell.

=== SQLite-Datenbanken ===
'''Öffnen der DB unter Linux:'''

(Es werden Schreibrechte benötigt,ohne kann man die DB zwar öffnen, aber nichts machen)
sudo sqlite3 fhem.db
Dadurch öffnet sich ein SQL-Konsole, auf der alle weiteren Befehle ausgeführt werden.

'''Schliessen der DB:'''

sqlite> .exit

'''Hilfe anzeigen:'''

sqlite> .help

'''Alle Tabellen anzeigen:'''

sqlite> .tables

'''Das Schema der DB anzeigen:'''

(vgl. oben [[DbLog#Datenbanken]] und [[DbLog#Beispiel: Anlegen und Nutzung einer SQLite-Datenbank]])

sqlite> .schema

'''Alle Eintäge anzeigen:'''

Die Einträge liegen alle in der Tabelle "History".

'''Ganz wichtig''' ist immer das ";" am Ende Zeile (bei allen Kommandos, die nicht mit einem "." anfangen). Wenn es vergessen wurde zeigt die Konsole solange neue Zeilen bis ein ";" eingegeben wird. So kann ein Befehl auch bequem über mehrere Zeilen geschrieben werden.

sqlite> select * from HISTORY;

Dies kann sehr lange dauern und kann ggf. mit <code>STRG-C</code> abgebrochen werden.

'''Alle Einträge eines Geräts anzeigen:'''

In <code>where</code>-Statements werden Strings in einfache Anführungsstriche gesetzt, Zahlen nicht.

sqlite> select * from HISTORY where DEVICE='Pollenflug';

'''Alle Einträge eines Readings eines Geräts anzeigen:'''

sqlite> select * from HISTORY where DEVICE='Pollenflug' and READING='Graeser';

'''Alle Einträge eines bestimmten Wertes eines Readings eines Geräts anzeigen:'''

sqlite> select * from HISTORY where DEVICE='Pollenflug' and READING='Graeser' and VALUE>1;

'''LÖSCHEN aller Einträge eines bestimmten Wertes eines Readings eines Geräts anzeigen:'''

'''Achtung:''' Löschen kann nicht rückgängig gemacht werden!! Also IMMER erst die entsprechenden SELECT-Statements solange verfeinern bis wirklich nur die gewünschten Einträge angezeigt werden. Dann das <code>select *</code> durch <code>delete</code> ersetzen.

sqlite> delete from HISTORY where DEVICE='Pollenflug' and READING='Graeser' and VALUE>1;

== Datenbank reparieren ==
Es kann immer wieder mal vorkommen, dass Datenbanken Fehler enthalten. Das muss im Alltag garnicht auffallen und auch nicht immer schlimm enden. Wenn man auf der SQL-Konsole aber bspw. eine Meldung <code>Error: database disk image is malformed</code> erhält, sollte man ein Reparatur vornehmen.

=== SQLite-Datenbanken ===
Die folgenden Schritte beschreiben, wie man eine SQLite-DB reparieren kann (Quelle: [http://techblog.dorogin.com/2011/05/sqliteexception-database-disk-image-is.html]):

<ol>
<li>
DB öffnen:
<pre>sudo sqlite3 fhem.db</pre>
</li>
<li>
Integritäts-Check durchführen:
<pre>sqlite> pragma integrity_check;</pre>
Kommt hier ein "ok" ist die DB gesund. Ansonsten erscheint etwas wie
<pre>
*** in database main ***
On tree page 118786 cell 1: Rowid 75 out of order (previous was 816660)
On tree page 118786 cell 4: Rowid 815704 out of order (previous was 816727)
Corruption detected in cell 0 on page 118786
Multiple uses for byte 132 of page 118786
...
</pre>
</li>
<li>
Datenbank-Dump erstellen (Export gesamten DB in die Datei "dump_all_20160516_1043.sql") und DB verlassen:
<pre>
sqlite> .mode insert
sqlite> .output dump_all_20160516_1043.sql
sqlite> .dump
sqlite> .exit
</pre>
</li>
<li>
Neue Datenbank erstellen und den Dump einlesen, Integritäts-Check machen und verlassen:
<pre>sudo sqlite3 fhem-neu.db</pre>
<pre>
sqlite> .read dump_all_20160516_1043.sql
sqlite> pragma integrity_check;
ok
sqlite> .exit
</pre>
</li>
<li>
Spätestens jetzt fhem stoppen:
<pre>sudo service fhem stop</pre>
</li>
<li>
Alte DB sichern und neue aktivieren:
<pre>
sudo mv fhem.db fhem.db.sv_20160516
sudo mv fhem-neu.db fhem.db
</pre>
</li>
<li>
Kontrollieren, dass die neue DB die gleichen Rechte wie die alte DB hat (und ggf. korrigieren):
<pre>
~/fhem$ ls -lha
insgesamt 6,3G
drwxr-xr-x 12 fhem root 4,0K Mai 16 11:07 .
drwxr-xr-x 4 root root 4,0K Dez 25 17:50 ..
...
-rw-r--r-- 1 root root 1,4G Mai 16 11:04 fhem.db
-rw-r--r-- 1 fhem root 2,6G Mai 16 10:59 fhem.db.sv_20160516
...

~/fhem$ sudo chown fhem:root fhem.db

~/fhem$ ls -lha
insgesamt 6,3G
drwxr-xr-x 12 fhem root 4,0K Mai 16 11:07 .
drwxr-xr-x 4 root root 4,0K Dez 25 17:50 ..
...
-rw-r--r-- 1 fhem root 1,4G Mai 16 11:04 fhem.db
-rw-r--r-- 1 fhem root 2,6G Mai 16 10:59 fhem.db.sv_20160516
...
</pre>
</li>
<li>
fhem wieder starten (und natürlich kontrollieren):
<pre>sudo service fhem start</pre>
</li>
</ol>

== Nützliche Codeschnipsel ==
Anbei ein paar nützliche Codeschnipsel rund um DbLog

=== Dateigrösse mitloggen ===
Da die Datenbank ins Unermessliche wachsen kann, empfiehlt es sich - je nach Speicherplatz - ab einer bestimmten Grösse tätig zu werden. Dazu muss diese Grösse allerdings ermittelt werden. Diese geschieht mittels des Userreadings, welches man vorteilshafterweise mit im DbLog-device anlegt:

<pre>attr myDbLog userReadings DbFileSize:reduceLogState.* { (split(' ',`du -m fhem.db`))[0] }</pre>

Mittels dieses Attributs wird die Grösse der .db-Datei immer nach dem Ausführen des ReduceLog in das Reading "DbFileSize" in ganzzahligen MByte abgelegt.

Basierend auf diesem Reading können dann weitere Aktionen, beispielsweise ein Plot, erstellt werden.

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

MySensors Starter Guide

2017-11-02T14:07:06Z

Rspecht: /* Debug über Konsole (z.B. Putty) */

{{Hinweis|Dieser Artikel ist im Aufbau und soll Einsteigern und Fortgeschrittenen als Referenzquelle für typische Fragen dienen. Alle sind eingeladen hier weitere Möglichkeiten einzubringen. Die beste Referenz für alle Fragen zu MySensors ist und bleibt aber die offizielle Hompage des Projekts!}}

== Einführung ==
[http://www.mysensors.org MySensors] ist ein open-Source-Projekt. Der Schwerpunkt liegt auf selbstgemachten Funk-Sensoren für die Hausautomatisierung und das "Internet der Dinge" in einer Art Baukastensystem. Die Bauanleitungen des Projekts für die einzelnen Musterbausteine sind in der Regel einfach nachzubauen, die Hard- und Softwarebauteile lassen sich dabei auch (fast beliebig) kombinieren.

=== Nodes und Children===
==== Nodes ====
Die Kombination von einem Microcontroller und einem Funkchip wird jeweils als "Node" bezeichnet.
Ein MySensors-Netzwerk besteht also (in der Regel) aus mindestens zwei Nodes, nämlich einer Gateway-Node und einer Sensor-Node. Jede Node ist durch eine sog. NodeID innerhalb des Netzwerks eindeutig identifizierbar, wobei die "0" jeweils für das Gateway reserviert ist.
Als Microcontroller werden in der Regel Arduinos (Nano oder Micro) verwendet, für das GW häufiger auch [[ESP8266]]. Als Funkchips lassen sich derzeit Module mit nRF24L01+ und RFM69 verwenden, die allerdings jeweils eine eigene Funktechnik verwendet und daher innerhalb eines Netzwerks nicht gemischt werden können. Es kann auch ein kabelgebundenes Netzwerk auf Basis von RS485-Modulen aufgebaut werden; hierfür werden 2 Adern als Datenleitung benötigt.
==== Children ====
Als Child wird alles bezeichnet, was jeweils innerhalb einer Node unterschieden werden soll. Beispiel: An einer Node wird ein BME280 angeschlossen. Dies ist ein I2C-Sensor, der drei Werte liefert, nämlich Temperatur, Luftfeuchtigkeit und Luftdruck. Jeder dieser Meßgrößen erhält üblicherweise eine eigene ChildID zugewiesen.

=== Softwarestand ===
{{Randnotiz|RNTyp=g|RNText=Der Verfasser hat in der Vergangenheit festgestellt, dass die bei MySensors beteiligten Entwickler eventuelle Verbesserungen und Fehlerkorrekturen nicht mehr in die "stable"-Version rückportieren. Bei Problemen empfiehlt es sich daher, die jeweilige beta-Version zu testen. Hierzu muß aber in der Regel auch das verwendete Gateway auf diese Version upgedated werden.}}
Bei Abfassung dieses Artikels war
*1.8.0 der Stand der verwendeten Arduino-IDE
*2.1.1 die stable-Version von MySensors.
*2.2.0-beta der aktuelle Development-Zweig von Mysensors

=== Vor- und Nachteile von MySensors ===
==== Vorteile ====
*Preisgünstig
*Modular, Elemente können (fast) beliebig kombiniert werden
*Es kann ein sog. ACK verlangt werden. Damit läßt sich sicherstellen, dass eine Node einen Befehl auch tatsächlich erhalten hat (Bidirektionalität).
*Auf den Microcontrollern kann eine eigene Funktionalität unabhängig von der zentralen FHEM-Instanz vorgesehen werden (z.B. LED-Licht direkt bei Bewegung schalten). Die Nodes können seit 2.0.1-beta dabei auch ohne Verbindung zum Gateway die loop() ausführen, wenn eine entsprechende Option aktiviert ist.
*MQTT kann unterstützt werden.
*Es kann auch eine kabelgebundene Infrastruktur aufgebaut werden (RS485, zwei Adern).

==== Nachteile ====
*Standardmäßig wird ein nicht verschüsselter Funkstandard verwendet, so dass von der Verwendung in sicherheitsrelevanten Funktionen (Türschließer usw.) abzuraten ist.

==== Zum Start ====
Für erste Tests sind sinnvoll:
{{Randnotiz|RNTyp=g|RNText=1. Für Sensbender-Boards sind spezielle [https://raw.githubusercontent.com/mysensors/ArduinoBoards/master/package_mysensors.org_index.json Board-Definitionen] für die IDE verfügbar. Nach den [https://github.com/mysensors/MySensors/releases Release Notes] sind diese ab der Version 2.0.0 zu empfehlen, die Installation erfolgt über File -> Preferencies -> Additional Boards Manager URLs
2. Manche neueren Boarddefinitionen aus der IDE führen u.U. zu häufigeren Reboots. Seit 1.6.18 scheint das Problem behoben zu sein, ansonsten ist ein Downgrade der Boarddefinitionen für AVR-Boards bis <=1.6.11 zu empfehlen.}}
*eine Arduino mit USB-Anschluß (Nano) oder ein ESP8266
*ein weiterer Arduino Nano
*zwei nRF24L01+ (alternativ: zwei RFM69)
*Die Arduino-IDE
*die gewünschte Sensorik, also z.B. einen DS18B20+Widerstand, ein Bewegungsmelder-Modul, ... siehe dazu die [https://www.mysensors.org/build Build-Anleitungen bei MySensors.org], wo auch Bezugsquellen zu finden sind.

== MySensors in FHEM ==
=== Allgemein ===
Die Nutzung von MySensors in FHEM ist (nicht nur für den Anfänger) mit der standardmäßig eingeschalteten [[autocreate|autocreate-Funktion]] einfach umsetzbar. Die Kenntnis der FHEM-Grundlagen und Durcharbeitung der Anfänger-Lektüren wird im Folgenden vorausgesetzt. Insbesondere sind [[Erste Schritte in FHEM]] und [http://fhem.de/Heimautomatisierung-mit-fhem.pdf Heimautomatisierung mit FHEM] Pflicht! Dort werden wesentliche Punkte für ein Verständnis von FHEM vermittelt, auch wenn manches nicht mehr ganz aktuell ist. So sollte man z.B. ein direktes Editieren der fhem.cfg unterlassen.

Im Folgenden werden immer wieder Auszüge aus der [[Konfiguration]] dargestellt. Diese dienen zur Erläuterung und Veranschaulichung. Die Bearbeitung der [[Konfiguration]] sollte - zur Verhinderung von Fehlern - nach Möglichkeit immer über das "[[Konfiguration#Befehl-Eingabefeld|Befehl-Eingabefeld]]" und die "[[Konfiguration#Objektdetails|Objektdetails]]" erfolgen.

=== Vorbereitung: Gateway ===
Zunächst ist das I/O-Device zu definieren, also das Gateway. Dies ist in [[MYSENSORS]] beschrieben.
{{Hinweis|Bei Verwendung eines seriellen Gateways ist zu empfehlen, einen Arduino mit orginalem FTDI-Chip zu verwenden und diesen mit der "by-id"-Methode ([[Trick_der_Woche#CUL_.26_CO_.C3.BCber_Serial_ID-einbinden]]) zuzuweisen. Beim Anschluß mehrer Arduinos mit einem CHG340/CHG341 an denselben Computer/Raspberry sind diese nur mit hohem {{Link2Forum|Topic=44926|Message=446809|LinkText=Aufwand}} eindeutig addressierbar.}}
{{Hinweis|Die Einbindung eines MySensors-Netzwerks kann auch über [http://fhem.de/commandref.html#MQTT MQTT] erfolgen. Dabei übernimmt ein MySensors-MQTT-Gateway die Kommunikation mit dem Broker. Der Autor hat hier jedoch keine eigene Erfahrung, bitte entsprechend nachtragen!}}

Serielles Gateway am Raspberry PI:
define MyGateway_0 MYSENSORS /dev/ttyUSB0@115200

Nach erfolgreicher Definition ist das Gateway im Raum "Everything" in der Gruppe "MYSENSORS" zu finden. Wenn unten "initialized" oder "opened" angezeigt wird, ist FHEM in der Lage, mit dem MySensors-Netz zu kommunizieren. Es sollte dann noch auf [[autocreate]] gestellt werden.

=== Das Gateway ist auch ein MySensors-Device ===
{{Hinweis|Sobald die ersten Meßwerte übertragen wurden, werden '''nach einem Browser-Refresh''' auch die aktuellen Meßwerte angezeigt, dies kann je nach Einstellung im Sketch aber einige Zeit dauern.}}
{{Randnotiz|RNTyp=g|RNText=Die Readings werden dem Modul MYSENSOR_DEVICE.pm entnommen. Sind diese dort nicht im Bereich "reads" bzw. "sends" enthalten, kann man fehlende Readings auch manuell anlegen. }}
Da am Gateway gleichzeitig auch bereits Sensoren angeschlossen sein können, legt FHEM direkt auch ein erstes [[MYSENSORS_DEVICE]] mit der NodeID "0" an. Sollten bereits ChildIDs im presentation()-Abschnitt des Gateway-Sketches enthalten gewesen sein, werden auch die zum Typ des präsentierten Sensor-Child-Typs passenden Readings automatisch angelegt.

=== Das erste Funk-MySensors-Device ===
In der Regel ist aber das erste "echte" MySensors-Device die 2. Node, die neben dem Gateway in Betrieb genommen wird. Hier gilt das Vorgesagte entsprechend: Nach dem ersten Start sind neu erkannte Devices ebenfalls im Raum "Everything" in der Gruppe "MYSENSORS" zu finden, die readings werden automatisch angelegt. Sobald Meßwerte übermittelt werden, werden die Readings damit gefüllt und entsprechend der per Sketch programmierten Vorgaben aktualisiert.

=== Details der Wechselwirkung zwischen FHEM und MySensors ===
==== Vergabe der NodeID ====
Die Vergabe der NodeID kann entweder im einzelnen Sketch erfolgen oder automatisiert. Dabei vergibt FHEM in der Regel fortlaufend Nummern ab 100. Die erste Node mit automatischer Nummernvergabe ist daher in der Regel das Device MYSENSORS_100.
{{Hinweis|Die NodeID wird - wie einige weitere Informationen - im sog. EEPROM des Arduinos abgespeichert. Ist sie einmal vergeben, ändert sie sich auch bei einem erneuten flashen der Node nicht mehr, es sei denn, man gibt per "define" im Sketch eine andere NodeID vor.}}

==== Fehlende Sensor-Typen und Readings ====
Für Anfänger ist zu empfehlen, nur Typen und Variablen zu nutzen, die in der 10_MYSENSORS_DEVICE.pm auch hinterlegt sind. Die Angaben dort zu "receives" und "sends" sind aus der Sicht der Node gemeint. Gibt es einzelne Sensor-Typen oder Readings (noch) nicht, gibt es folgende Möglichkeiten:
*Noch nicht vorhandene Typen kann man umgehen, indem man vergleichbare andere nimmt, also z.B. Wasser- statt Gaszähler (Stand: 11/2015)
*Fehlende Readings können auch
**in die 10_MYSENSORS_DEVICE.pm manuell eingepflegt werden, das automatische Anlegen geht dann aber ggf. bei einem Update wieder verloren
**manuell, z.B. <code>attr MYSENSOR_99 mapReading_ir_send3 3 ir_send</code>
Ist das Reading einmal angelegt, wird es auch automatisch befüllt, sobald die Node einen entsprechenden Wert sendet.

==== Austausch von Variablen oder Texten ====
Es ist möglich, Informationen auch bidirektional zwischen FHEM und den Nodes auszutauschen. Dies ermöglicht z.B. die Ansteuerung von Displays oder die Konfiguration von FHEM aus. Hierzu ist es am einfachsten, ein oder mehrere S_CUSTOM-Child zu präsentieren, die jeweils bis zu 5 Variablen ermöglichen. Die Zuordnung innerhalb der Node zu internen Variablen erfolgt dann über die Auswertung der Messages entsprechend der [https://forum.mysensors.org/topic/1817/weather-and-forecast-display-for-swedish-fhem-users/2 ChildID und der Variablennummer].

==== OTA ====
MySensors unterstützt für NRF-Chips zwar grundsätzlich OTA-updates, man muß dafür aber vorübergehend einen anderen Controller als FHEM einsetzen (Stand 11/2016).
Ein Howto ist in diesem {{Link2Forum|Topic=59388.0|LinkText=Forenbeitrag}} zu finden.
Der dort verwendete Bootloader erwartet OTA-Updates fest auf Channel 76.

== Links, Tricks, Kniffe und Erfahrungen ==

=== Interessante Links ===
==== Offizielles Debugging-Schema ====
*[https://forum.mysensors.org/topic/666/debug-faq-and-how-ask-for-help Debug / FAQ bei MySensors.org]
==== Debug über Konsole (z.B. Putty) ====
* Über Picocom könnt ihr einfach das Gateway debuggen. Dazu in FHEM entsprechend das Device abschalten und Picocom auf der Konsole aufrufen. Damit alles schön angezeigt wird hilft das imap wie unten gezeigt. Bitte passt das Device /dev/ttyUSB0 auf euer Gateway an.

<code>picocom /dev/ttyUSB0 -b115200 --imap lfcrlf</code>

==== Vorgehensweise zur Kombination von mehreren Sketchen/Sensoren an einer Node ====
Mehrere Sensoren (Children) kann man recht einfach an einen einzigen Arduino anschließen und ist dabei nur durch die Größe des Speichers begrenzt. Die Vorgehensweise erläutert dieses [https://forum.mysensors.org/topic/2597/combining-mysensors-examples/2 Beispiel] .
==== Verschlüsselung und Signierung ====
*{{Link2Forum|Topic=67248|LinkText=Forumsbeitrag zu MySensors Verschlüsselung und Signierung}}
*[https://www.mysensors.org/about/signing Darstellung bei MySensors.org]

=== EEPROM ===
Die Nodes speichern einen Teil ihrer Einstellungen im sog. EEPROM. Dazu gehören z.B. die NodeID, der letzte bekannte "nächste" Punkt im Netzwert (RepeaterID) oder der Zustand von Relais. In der Regel ist nur die NodeID problematisch und kann beim flashen per Sketch auf einen anderen als den bisherigen Wert gestellt werden. Wer dennoch das EEPROM löschen möchte, muß den '''MySensor-Lösch-Sketch''' nehmen, der nicht "0000..." ins EEPROM schreibt wie der Arduino-Standard-Lösch-Sketch, sondern "FFFF...".

=== Funk-Themen (NRF-Chips) ===
Viele berichtete Probleme bei der Einrichtung von MySensors-Netzwerken haben ihren Ursprung in einer unzureichenden Funkverbindung. {{Hinweis|Ob dies der Fall ist, läßt sich leicht testen, indem man die fragliche Node wieder in die Nähe des Gateways bringt. Funktioniert es dort wie erwartet, liegt eine schlechte Funkverbindung vor.}}

==== Abhilfemaßnahmen ====
*Einen bzw. mehrere [https://www.mysensors.org/build/connect_radio#connecting_a_decoupling-capacitor Kondensatoren] einlöten. Es sind auch fertige Module erhältlich, die diese Bauteile und einen Spannungsregler bereits enthalten, auf die der NRF mit einem Stecksockel aufgesteckt wird.
*Einen anderen Kanal wählen; die verwendeten Frequenzen liegen im b/g-WLAN-Bereich, so dass wechselseitige Störungen möglich sind. In Deutschland sind die Kanäle bis 84 erlaubt.
*NRF tauschen (Fake NRF-Chips sind zwar verwendbar, haben aber eine deutlich reduzierte Funkreichweite)
*Ein allgemeiner Guide zur Verwendung der nrf24l01+-Module ist [https://arduino-info.wikispaces.com/Nrf24L01-2.4GHz-HowTo hier] zu finden.
*Für das Gateway empfielt es sich, ein Modul mit externer Antenne zu verwenden (NRF24L01+PA+LNA Antenna version).
*Einstellen des richtigen PA_LEVEL_...s: Insbesondere der Standardsketch für das serielle Gateway definiert diesen als LOW, was korrekt ist, wenn der interne Spannungsregler des Arduino verwendet ist. Besser ist es, die benötigten 3,3V mittels eines seperaten Spannungsreglers zu erzeugen und dann den PA_LEVEL_MAX einzustellen.
*Funkstrecken lassen sich recht unkompliziert mit Repeatern überbrücken. Dieser muß nicht zwingend eine eigene Node sein. Jede (sinnvollerweise nicht Batterie-gespeiste) Node kann per <code> #define MY_REPEATER_FEATURE </code> zum Repeater gemacht werden.
*Sonstige Vorschläge ohne Erfolgsgarantie, aber mit Unterhaltungswert:
**[http://www.instructables.com/id/Enhanced-NRF24L01/ Eigenbau-Antennenverbesserung]
**[http://blog.blackoise.de/2016/02/fixing-your-cheap-nrf24l01-palna-module/ Schirmung]

==== Buffer-Management ====
Die NRF-Chips haben nur einen begrenzten Speicher, um Nachrichten zu puffern. Dieser kann überlaufen, wenn in kurzer Folge Informationen versendet werden, z.B. mehr als 5 Temperaturwerte von 1-Wire-Sensoren. Diese Problematik verschärft sich bei der Verwendung von Message-Signing, weil dort die volle payload-Bandbreite für einzelne Nachrichten genutzt wird. Für Abhilfe sorgen kurze Pausen zwischen den einzelnen Sendungen, z.B. <code>wait(30);</code>.

=== RS485 ===
Seit 2.0.1 ist es möglich, statt der Funkmodule auch ein kabelgebundenes Netzwerk auf Basis von RS485-Modulen aufzubauen; hierfür werden 2 Adern als Datenleitung benötigt, die Zahl der Nodes in einem solchen Netzwerk ist bei Verwendung der Standardmodule auf 32 beschränkt, bei Verwendung anderer Transceiver sind auch mehr Nodes möglich. Hierfür ist ein seperates Gateway erforderlich.

==== Bekannte Probleme bei RS485 ====
(Stand: 2.1.1)

*Die Vergabe der Node-ID's muß im Sketch selbst erfolgen, die automatische Zuweisung funktioniert nicht.
*Die für die Anbindung der Module definierten PINs (8+9) sind tief im Code verankert und sollten nicht geändert werden.
*Sollte der Speicher knapp werden, empfielt es sich, statt der softserial-Variante HW_SERIAL zu verwenden. Dies benötigt ca. 10% weniger Speicher (ATmega328).

=== Ablauf des Starts einer Node ===
Beim Start durchlaufen alle Nodes nacheinander bestimmte vordefinierte Programmroutinen in folgender Reihenfolge:

==== Vorversionen ====
*setup()
*presentation()
*loop()

==== seit MySensors 2.1.0 ====
*preHwInit()
*before()
*presentation()
*setup()
*loop()

==== Im Detail ====
Dieser Ablauf ermöglicht, die Arduino-Pins vorzukonfigurieren und angeschlossenes Equipment an der für den Programmablauf richtigen Stelle zu initialisieren. Dies ist u.U. wichtig, da
*eine Node im Normalfall nicht in loop() geht, solange die presentation() nicht erfolgreich war (also solange der Controller nicht verfügbar ist). Eine Failsafe-Initialisierung von Schnittstellen sollte demnach in preHwInit() oder before() erfolgen. Es kann zusätzlich seit 2.1.1 auch die Option MY_TRANSPORT_WAIT_READY_MS min. auf 1 gesetzt werden, dann startet die loop() auch ohne Verbindung zum Gateway.
*die Initialisierung anderer SPI-Hardware auf einem gemeinsamen Bus mit den NRF-Modulem vor der presentation() erfolgen muß.

=== Beispiel-Sketche ===
*[https://forum.mysensors.org/topic/938/multisensor-multiactuator-sketch-testboard-tested-with-fhem-controller Mehrfachsensor], allerdings noch für MySensors Vers. 1.5.4
*Bidirektionale {{Link2Forum|Topic=26807|msg=449776|LinkText="Infrarot-Fernbedienung"}} aus FHEM raus iVm. remotecontrol
*mehrere [https://github.com/rejoe2/MySensors-Dallas-Address-ChildID-Consistency Dallas-Temperatursensoren] auf einem Bus eindeutig erkennen
*[https://forum.mysensors.org/topic/1817/weather-and-forecast-display-for-swedish-fhem-users/2 Display] ansteuern

[[Kategorie:Arduino]]
[[Kategorie:IP Components]]
[[Kategorie:Other Components]]

MySensors Starter Guide

2017-11-02T14:05:39Z

Rspecht: /* Debug über Konsole (z.B. Putty) */

{{Hinweis|Dieser Artikel ist im Aufbau und soll Einsteigern und Fortgeschrittenen als Referenzquelle für typische Fragen dienen. Alle sind eingeladen hier weitere Möglichkeiten einzubringen. Die beste Referenz für alle Fragen zu MySensors ist und bleibt aber die offizielle Hompage des Projekts!}}

== Einführung ==
[http://www.mysensors.org MySensors] ist ein open-Source-Projekt. Der Schwerpunkt liegt auf selbstgemachten Funk-Sensoren für die Hausautomatisierung und das "Internet der Dinge" in einer Art Baukastensystem. Die Bauanleitungen des Projekts für die einzelnen Musterbausteine sind in der Regel einfach nachzubauen, die Hard- und Softwarebauteile lassen sich dabei auch (fast beliebig) kombinieren.

=== Nodes und Children===
==== Nodes ====
Die Kombination von einem Microcontroller und einem Funkchip wird jeweils als "Node" bezeichnet.
Ein MySensors-Netzwerk besteht also (in der Regel) aus mindestens zwei Nodes, nämlich einer Gateway-Node und einer Sensor-Node. Jede Node ist durch eine sog. NodeID innerhalb des Netzwerks eindeutig identifizierbar, wobei die "0" jeweils für das Gateway reserviert ist.
Als Microcontroller werden in der Regel Arduinos (Nano oder Micro) verwendet, für das GW häufiger auch [[ESP8266]]. Als Funkchips lassen sich derzeit Module mit nRF24L01+ und RFM69 verwenden, die allerdings jeweils eine eigene Funktechnik verwendet und daher innerhalb eines Netzwerks nicht gemischt werden können. Es kann auch ein kabelgebundenes Netzwerk auf Basis von RS485-Modulen aufgebaut werden; hierfür werden 2 Adern als Datenleitung benötigt.
==== Children ====
Als Child wird alles bezeichnet, was jeweils innerhalb einer Node unterschieden werden soll. Beispiel: An einer Node wird ein BME280 angeschlossen. Dies ist ein I2C-Sensor, der drei Werte liefert, nämlich Temperatur, Luftfeuchtigkeit und Luftdruck. Jeder dieser Meßgrößen erhält üblicherweise eine eigene ChildID zugewiesen.

=== Softwarestand ===
{{Randnotiz|RNTyp=g|RNText=Der Verfasser hat in der Vergangenheit festgestellt, dass die bei MySensors beteiligten Entwickler eventuelle Verbesserungen und Fehlerkorrekturen nicht mehr in die "stable"-Version rückportieren. Bei Problemen empfiehlt es sich daher, die jeweilige beta-Version zu testen. Hierzu muß aber in der Regel auch das verwendete Gateway auf diese Version upgedated werden.}}
Bei Abfassung dieses Artikels war
*1.8.0 der Stand der verwendeten Arduino-IDE
*2.1.1 die stable-Version von MySensors.
*2.2.0-beta der aktuelle Development-Zweig von Mysensors

=== Vor- und Nachteile von MySensors ===
==== Vorteile ====
*Preisgünstig
*Modular, Elemente können (fast) beliebig kombiniert werden
*Es kann ein sog. ACK verlangt werden. Damit läßt sich sicherstellen, dass eine Node einen Befehl auch tatsächlich erhalten hat (Bidirektionalität).
*Auf den Microcontrollern kann eine eigene Funktionalität unabhängig von der zentralen FHEM-Instanz vorgesehen werden (z.B. LED-Licht direkt bei Bewegung schalten). Die Nodes können seit 2.0.1-beta dabei auch ohne Verbindung zum Gateway die loop() ausführen, wenn eine entsprechende Option aktiviert ist.
*MQTT kann unterstützt werden.
*Es kann auch eine kabelgebundene Infrastruktur aufgebaut werden (RS485, zwei Adern).

==== Nachteile ====
*Standardmäßig wird ein nicht verschüsselter Funkstandard verwendet, so dass von der Verwendung in sicherheitsrelevanten Funktionen (Türschließer usw.) abzuraten ist.

==== Zum Start ====
Für erste Tests sind sinnvoll:
{{Randnotiz|RNTyp=g|RNText=1. Für Sensbender-Boards sind spezielle [https://raw.githubusercontent.com/mysensors/ArduinoBoards/master/package_mysensors.org_index.json Board-Definitionen] für die IDE verfügbar. Nach den [https://github.com/mysensors/MySensors/releases Release Notes] sind diese ab der Version 2.0.0 zu empfehlen, die Installation erfolgt über File -> Preferencies -> Additional Boards Manager URLs
2. Manche neueren Boarddefinitionen aus der IDE führen u.U. zu häufigeren Reboots. Seit 1.6.18 scheint das Problem behoben zu sein, ansonsten ist ein Downgrade der Boarddefinitionen für AVR-Boards bis <=1.6.11 zu empfehlen.}}
*eine Arduino mit USB-Anschluß (Nano) oder ein ESP8266
*ein weiterer Arduino Nano
*zwei nRF24L01+ (alternativ: zwei RFM69)
*Die Arduino-IDE
*die gewünschte Sensorik, also z.B. einen DS18B20+Widerstand, ein Bewegungsmelder-Modul, ... siehe dazu die [https://www.mysensors.org/build Build-Anleitungen bei MySensors.org], wo auch Bezugsquellen zu finden sind.

== MySensors in FHEM ==
=== Allgemein ===
Die Nutzung von MySensors in FHEM ist (nicht nur für den Anfänger) mit der standardmäßig eingeschalteten [[autocreate|autocreate-Funktion]] einfach umsetzbar. Die Kenntnis der FHEM-Grundlagen und Durcharbeitung der Anfänger-Lektüren wird im Folgenden vorausgesetzt. Insbesondere sind [[Erste Schritte in FHEM]] und [http://fhem.de/Heimautomatisierung-mit-fhem.pdf Heimautomatisierung mit FHEM] Pflicht! Dort werden wesentliche Punkte für ein Verständnis von FHEM vermittelt, auch wenn manches nicht mehr ganz aktuell ist. So sollte man z.B. ein direktes Editieren der fhem.cfg unterlassen.

Im Folgenden werden immer wieder Auszüge aus der [[Konfiguration]] dargestellt. Diese dienen zur Erläuterung und Veranschaulichung. Die Bearbeitung der [[Konfiguration]] sollte - zur Verhinderung von Fehlern - nach Möglichkeit immer über das "[[Konfiguration#Befehl-Eingabefeld|Befehl-Eingabefeld]]" und die "[[Konfiguration#Objektdetails|Objektdetails]]" erfolgen.

=== Vorbereitung: Gateway ===
Zunächst ist das I/O-Device zu definieren, also das Gateway. Dies ist in [[MYSENSORS]] beschrieben.
{{Hinweis|Bei Verwendung eines seriellen Gateways ist zu empfehlen, einen Arduino mit orginalem FTDI-Chip zu verwenden und diesen mit der "by-id"-Methode ([[Trick_der_Woche#CUL_.26_CO_.C3.BCber_Serial_ID-einbinden]]) zuzuweisen. Beim Anschluß mehrer Arduinos mit einem CHG340/CHG341 an denselben Computer/Raspberry sind diese nur mit hohem {{Link2Forum|Topic=44926|Message=446809|LinkText=Aufwand}} eindeutig addressierbar.}}
{{Hinweis|Die Einbindung eines MySensors-Netzwerks kann auch über [http://fhem.de/commandref.html#MQTT MQTT] erfolgen. Dabei übernimmt ein MySensors-MQTT-Gateway die Kommunikation mit dem Broker. Der Autor hat hier jedoch keine eigene Erfahrung, bitte entsprechend nachtragen!}}

Serielles Gateway am Raspberry PI:
define MyGateway_0 MYSENSORS /dev/ttyUSB0@115200

Nach erfolgreicher Definition ist das Gateway im Raum "Everything" in der Gruppe "MYSENSORS" zu finden. Wenn unten "initialized" oder "opened" angezeigt wird, ist FHEM in der Lage, mit dem MySensors-Netz zu kommunizieren. Es sollte dann noch auf [[autocreate]] gestellt werden.

=== Das Gateway ist auch ein MySensors-Device ===
{{Hinweis|Sobald die ersten Meßwerte übertragen wurden, werden '''nach einem Browser-Refresh''' auch die aktuellen Meßwerte angezeigt, dies kann je nach Einstellung im Sketch aber einige Zeit dauern.}}
{{Randnotiz|RNTyp=g|RNText=Die Readings werden dem Modul MYSENSOR_DEVICE.pm entnommen. Sind diese dort nicht im Bereich "reads" bzw. "sends" enthalten, kann man fehlende Readings auch manuell anlegen. }}
Da am Gateway gleichzeitig auch bereits Sensoren angeschlossen sein können, legt FHEM direkt auch ein erstes [[MYSENSORS_DEVICE]] mit der NodeID "0" an. Sollten bereits ChildIDs im presentation()-Abschnitt des Gateway-Sketches enthalten gewesen sein, werden auch die zum Typ des präsentierten Sensor-Child-Typs passenden Readings automatisch angelegt.

=== Das erste Funk-MySensors-Device ===
In der Regel ist aber das erste "echte" MySensors-Device die 2. Node, die neben dem Gateway in Betrieb genommen wird. Hier gilt das Vorgesagte entsprechend: Nach dem ersten Start sind neu erkannte Devices ebenfalls im Raum "Everything" in der Gruppe "MYSENSORS" zu finden, die readings werden automatisch angelegt. Sobald Meßwerte übermittelt werden, werden die Readings damit gefüllt und entsprechend der per Sketch programmierten Vorgaben aktualisiert.

=== Details der Wechselwirkung zwischen FHEM und MySensors ===
==== Vergabe der NodeID ====
Die Vergabe der NodeID kann entweder im einzelnen Sketch erfolgen oder automatisiert. Dabei vergibt FHEM in der Regel fortlaufend Nummern ab 100. Die erste Node mit automatischer Nummernvergabe ist daher in der Regel das Device MYSENSORS_100.
{{Hinweis|Die NodeID wird - wie einige weitere Informationen - im sog. EEPROM des Arduinos abgespeichert. Ist sie einmal vergeben, ändert sie sich auch bei einem erneuten flashen der Node nicht mehr, es sei denn, man gibt per "define" im Sketch eine andere NodeID vor.}}

==== Fehlende Sensor-Typen und Readings ====
Für Anfänger ist zu empfehlen, nur Typen und Variablen zu nutzen, die in der 10_MYSENSORS_DEVICE.pm auch hinterlegt sind. Die Angaben dort zu "receives" und "sends" sind aus der Sicht der Node gemeint. Gibt es einzelne Sensor-Typen oder Readings (noch) nicht, gibt es folgende Möglichkeiten:
*Noch nicht vorhandene Typen kann man umgehen, indem man vergleichbare andere nimmt, also z.B. Wasser- statt Gaszähler (Stand: 11/2015)
*Fehlende Readings können auch
**in die 10_MYSENSORS_DEVICE.pm manuell eingepflegt werden, das automatische Anlegen geht dann aber ggf. bei einem Update wieder verloren
**manuell, z.B. <code>attr MYSENSOR_99 mapReading_ir_send3 3 ir_send</code>
Ist das Reading einmal angelegt, wird es auch automatisch befüllt, sobald die Node einen entsprechenden Wert sendet.

==== Austausch von Variablen oder Texten ====
Es ist möglich, Informationen auch bidirektional zwischen FHEM und den Nodes auszutauschen. Dies ermöglicht z.B. die Ansteuerung von Displays oder die Konfiguration von FHEM aus. Hierzu ist es am einfachsten, ein oder mehrere S_CUSTOM-Child zu präsentieren, die jeweils bis zu 5 Variablen ermöglichen. Die Zuordnung innerhalb der Node zu internen Variablen erfolgt dann über die Auswertung der Messages entsprechend der [https://forum.mysensors.org/topic/1817/weather-and-forecast-display-for-swedish-fhem-users/2 ChildID und der Variablennummer].

==== OTA ====
MySensors unterstützt für NRF-Chips zwar grundsätzlich OTA-updates, man muß dafür aber vorübergehend einen anderen Controller als FHEM einsetzen (Stand 11/2016).
Ein Howto ist in diesem {{Link2Forum|Topic=59388.0|LinkText=Forenbeitrag}} zu finden.
Der dort verwendete Bootloader erwartet OTA-Updates fest auf Channel 76.

== Links, Tricks, Kniffe und Erfahrungen ==

=== Interessante Links ===
==== Offizielles Debugging-Schema ====
*[https://forum.mysensors.org/topic/666/debug-faq-and-how-ask-for-help Debug / FAQ bei MySensors.org]
==== Debug über Konsole (z.B. Putty) ====
* Über Picocom könnt ihr einfach das Gateway debuggen. Dazu in FHEM entsprechend das Device abschalten und Picocom wie folgt aufrufen. Dabei bitte /dev/ttyUSB0 entsprechend anpassen.

<code>picocom /dev/ttyUSB0 -b115200 --imap lfcrlf</code>

==== Vorgehensweise zur Kombination von mehreren Sketchen/Sensoren an einer Node ====
Mehrere Sensoren (Children) kann man recht einfach an einen einzigen Arduino anschließen und ist dabei nur durch die Größe des Speichers begrenzt. Die Vorgehensweise erläutert dieses [https://forum.mysensors.org/topic/2597/combining-mysensors-examples/2 Beispiel] .
==== Verschlüsselung und Signierung ====
*{{Link2Forum|Topic=67248|LinkText=Forumsbeitrag zu MySensors Verschlüsselung und Signierung}}
*[https://www.mysensors.org/about/signing Darstellung bei MySensors.org]

=== EEPROM ===
Die Nodes speichern einen Teil ihrer Einstellungen im sog. EEPROM. Dazu gehören z.B. die NodeID, der letzte bekannte "nächste" Punkt im Netzwert (RepeaterID) oder der Zustand von Relais. In der Regel ist nur die NodeID problematisch und kann beim flashen per Sketch auf einen anderen als den bisherigen Wert gestellt werden. Wer dennoch das EEPROM löschen möchte, muß den '''MySensor-Lösch-Sketch''' nehmen, der nicht "0000..." ins EEPROM schreibt wie der Arduino-Standard-Lösch-Sketch, sondern "FFFF...".

=== Funk-Themen (NRF-Chips) ===
Viele berichtete Probleme bei der Einrichtung von MySensors-Netzwerken haben ihren Ursprung in einer unzureichenden Funkverbindung. {{Hinweis|Ob dies der Fall ist, läßt sich leicht testen, indem man die fragliche Node wieder in die Nähe des Gateways bringt. Funktioniert es dort wie erwartet, liegt eine schlechte Funkverbindung vor.}}

==== Abhilfemaßnahmen ====
*Einen bzw. mehrere [https://www.mysensors.org/build/connect_radio#connecting_a_decoupling-capacitor Kondensatoren] einlöten. Es sind auch fertige Module erhältlich, die diese Bauteile und einen Spannungsregler bereits enthalten, auf die der NRF mit einem Stecksockel aufgesteckt wird.
*Einen anderen Kanal wählen; die verwendeten Frequenzen liegen im b/g-WLAN-Bereich, so dass wechselseitige Störungen möglich sind. In Deutschland sind die Kanäle bis 84 erlaubt.
*NRF tauschen (Fake NRF-Chips sind zwar verwendbar, haben aber eine deutlich reduzierte Funkreichweite)
*Ein allgemeiner Guide zur Verwendung der nrf24l01+-Module ist [https://arduino-info.wikispaces.com/Nrf24L01-2.4GHz-HowTo hier] zu finden.
*Für das Gateway empfielt es sich, ein Modul mit externer Antenne zu verwenden (NRF24L01+PA+LNA Antenna version).
*Einstellen des richtigen PA_LEVEL_...s: Insbesondere der Standardsketch für das serielle Gateway definiert diesen als LOW, was korrekt ist, wenn der interne Spannungsregler des Arduino verwendet ist. Besser ist es, die benötigten 3,3V mittels eines seperaten Spannungsreglers zu erzeugen und dann den PA_LEVEL_MAX einzustellen.
*Funkstrecken lassen sich recht unkompliziert mit Repeatern überbrücken. Dieser muß nicht zwingend eine eigene Node sein. Jede (sinnvollerweise nicht Batterie-gespeiste) Node kann per <code> #define MY_REPEATER_FEATURE </code> zum Repeater gemacht werden.
*Sonstige Vorschläge ohne Erfolgsgarantie, aber mit Unterhaltungswert:
**[http://www.instructables.com/id/Enhanced-NRF24L01/ Eigenbau-Antennenverbesserung]
**[http://blog.blackoise.de/2016/02/fixing-your-cheap-nrf24l01-palna-module/ Schirmung]

==== Buffer-Management ====
Die NRF-Chips haben nur einen begrenzten Speicher, um Nachrichten zu puffern. Dieser kann überlaufen, wenn in kurzer Folge Informationen versendet werden, z.B. mehr als 5 Temperaturwerte von 1-Wire-Sensoren. Diese Problematik verschärft sich bei der Verwendung von Message-Signing, weil dort die volle payload-Bandbreite für einzelne Nachrichten genutzt wird. Für Abhilfe sorgen kurze Pausen zwischen den einzelnen Sendungen, z.B. <code>wait(30);</code>.

=== RS485 ===
Seit 2.0.1 ist es möglich, statt der Funkmodule auch ein kabelgebundenes Netzwerk auf Basis von RS485-Modulen aufzubauen; hierfür werden 2 Adern als Datenleitung benötigt, die Zahl der Nodes in einem solchen Netzwerk ist bei Verwendung der Standardmodule auf 32 beschränkt, bei Verwendung anderer Transceiver sind auch mehr Nodes möglich. Hierfür ist ein seperates Gateway erforderlich.

==== Bekannte Probleme bei RS485 ====
(Stand: 2.1.1)

*Die Vergabe der Node-ID's muß im Sketch selbst erfolgen, die automatische Zuweisung funktioniert nicht.
*Die für die Anbindung der Module definierten PINs (8+9) sind tief im Code verankert und sollten nicht geändert werden.
*Sollte der Speicher knapp werden, empfielt es sich, statt der softserial-Variante HW_SERIAL zu verwenden. Dies benötigt ca. 10% weniger Speicher (ATmega328).

=== Ablauf des Starts einer Node ===
Beim Start durchlaufen alle Nodes nacheinander bestimmte vordefinierte Programmroutinen in folgender Reihenfolge:

==== Vorversionen ====
*setup()
*presentation()
*loop()

==== seit MySensors 2.1.0 ====
*preHwInit()
*before()
*presentation()
*setup()
*loop()

==== Im Detail ====
Dieser Ablauf ermöglicht, die Arduino-Pins vorzukonfigurieren und angeschlossenes Equipment an der für den Programmablauf richtigen Stelle zu initialisieren. Dies ist u.U. wichtig, da
*eine Node im Normalfall nicht in loop() geht, solange die presentation() nicht erfolgreich war (also solange der Controller nicht verfügbar ist). Eine Failsafe-Initialisierung von Schnittstellen sollte demnach in preHwInit() oder before() erfolgen. Es kann zusätzlich seit 2.1.1 auch die Option MY_TRANSPORT_WAIT_READY_MS min. auf 1 gesetzt werden, dann startet die loop() auch ohne Verbindung zum Gateway.
*die Initialisierung anderer SPI-Hardware auf einem gemeinsamen Bus mit den NRF-Modulem vor der presentation() erfolgen muß.

=== Beispiel-Sketche ===
*[https://forum.mysensors.org/topic/938/multisensor-multiactuator-sketch-testboard-tested-with-fhem-controller Mehrfachsensor], allerdings noch für MySensors Vers. 1.5.4
*Bidirektionale {{Link2Forum|Topic=26807|msg=449776|LinkText="Infrarot-Fernbedienung"}} aus FHEM raus iVm. remotecontrol
*mehrere [https://github.com/rejoe2/MySensors-Dallas-Address-ChildID-Consistency Dallas-Temperatursensoren] auf einem Bus eindeutig erkennen
*[https://forum.mysensors.org/topic/1817/weather-and-forecast-display-for-swedish-fhem-users/2 Display] ansteuern

[[Kategorie:Arduino]]
[[Kategorie:IP Components]]
[[Kategorie:Other Components]]

MySensors Starter Guide

2017-11-02T14:05:16Z

Rspecht: /* Debug über Konsole (z.B. Putty) */

{{Hinweis|Dieser Artikel ist im Aufbau und soll Einsteigern und Fortgeschrittenen als Referenzquelle für typische Fragen dienen. Alle sind eingeladen hier weitere Möglichkeiten einzubringen. Die beste Referenz für alle Fragen zu MySensors ist und bleibt aber die offizielle Hompage des Projekts!}}

== Einführung ==
[http://www.mysensors.org MySensors] ist ein open-Source-Projekt. Der Schwerpunkt liegt auf selbstgemachten Funk-Sensoren für die Hausautomatisierung und das "Internet der Dinge" in einer Art Baukastensystem. Die Bauanleitungen des Projekts für die einzelnen Musterbausteine sind in der Regel einfach nachzubauen, die Hard- und Softwarebauteile lassen sich dabei auch (fast beliebig) kombinieren.

=== Nodes und Children===
==== Nodes ====
Die Kombination von einem Microcontroller und einem Funkchip wird jeweils als "Node" bezeichnet.
Ein MySensors-Netzwerk besteht also (in der Regel) aus mindestens zwei Nodes, nämlich einer Gateway-Node und einer Sensor-Node. Jede Node ist durch eine sog. NodeID innerhalb des Netzwerks eindeutig identifizierbar, wobei die "0" jeweils für das Gateway reserviert ist.
Als Microcontroller werden in der Regel Arduinos (Nano oder Micro) verwendet, für das GW häufiger auch [[ESP8266]]. Als Funkchips lassen sich derzeit Module mit nRF24L01+ und RFM69 verwenden, die allerdings jeweils eine eigene Funktechnik verwendet und daher innerhalb eines Netzwerks nicht gemischt werden können. Es kann auch ein kabelgebundenes Netzwerk auf Basis von RS485-Modulen aufgebaut werden; hierfür werden 2 Adern als Datenleitung benötigt.
==== Children ====
Als Child wird alles bezeichnet, was jeweils innerhalb einer Node unterschieden werden soll. Beispiel: An einer Node wird ein BME280 angeschlossen. Dies ist ein I2C-Sensor, der drei Werte liefert, nämlich Temperatur, Luftfeuchtigkeit und Luftdruck. Jeder dieser Meßgrößen erhält üblicherweise eine eigene ChildID zugewiesen.

=== Softwarestand ===
{{Randnotiz|RNTyp=g|RNText=Der Verfasser hat in der Vergangenheit festgestellt, dass die bei MySensors beteiligten Entwickler eventuelle Verbesserungen und Fehlerkorrekturen nicht mehr in die "stable"-Version rückportieren. Bei Problemen empfiehlt es sich daher, die jeweilige beta-Version zu testen. Hierzu muß aber in der Regel auch das verwendete Gateway auf diese Version upgedated werden.}}
Bei Abfassung dieses Artikels war
*1.8.0 der Stand der verwendeten Arduino-IDE
*2.1.1 die stable-Version von MySensors.
*2.2.0-beta der aktuelle Development-Zweig von Mysensors

=== Vor- und Nachteile von MySensors ===
==== Vorteile ====
*Preisgünstig
*Modular, Elemente können (fast) beliebig kombiniert werden
*Es kann ein sog. ACK verlangt werden. Damit läßt sich sicherstellen, dass eine Node einen Befehl auch tatsächlich erhalten hat (Bidirektionalität).
*Auf den Microcontrollern kann eine eigene Funktionalität unabhängig von der zentralen FHEM-Instanz vorgesehen werden (z.B. LED-Licht direkt bei Bewegung schalten). Die Nodes können seit 2.0.1-beta dabei auch ohne Verbindung zum Gateway die loop() ausführen, wenn eine entsprechende Option aktiviert ist.
*MQTT kann unterstützt werden.
*Es kann auch eine kabelgebundene Infrastruktur aufgebaut werden (RS485, zwei Adern).

==== Nachteile ====
*Standardmäßig wird ein nicht verschüsselter Funkstandard verwendet, so dass von der Verwendung in sicherheitsrelevanten Funktionen (Türschließer usw.) abzuraten ist.

==== Zum Start ====
Für erste Tests sind sinnvoll:
{{Randnotiz|RNTyp=g|RNText=1. Für Sensbender-Boards sind spezielle [https://raw.githubusercontent.com/mysensors/ArduinoBoards/master/package_mysensors.org_index.json Board-Definitionen] für die IDE verfügbar. Nach den [https://github.com/mysensors/MySensors/releases Release Notes] sind diese ab der Version 2.0.0 zu empfehlen, die Installation erfolgt über File -> Preferencies -> Additional Boards Manager URLs
2. Manche neueren Boarddefinitionen aus der IDE führen u.U. zu häufigeren Reboots. Seit 1.6.18 scheint das Problem behoben zu sein, ansonsten ist ein Downgrade der Boarddefinitionen für AVR-Boards bis <=1.6.11 zu empfehlen.}}
*eine Arduino mit USB-Anschluß (Nano) oder ein ESP8266
*ein weiterer Arduino Nano
*zwei nRF24L01+ (alternativ: zwei RFM69)
*Die Arduino-IDE
*die gewünschte Sensorik, also z.B. einen DS18B20+Widerstand, ein Bewegungsmelder-Modul, ... siehe dazu die [https://www.mysensors.org/build Build-Anleitungen bei MySensors.org], wo auch Bezugsquellen zu finden sind.

== MySensors in FHEM ==
=== Allgemein ===
Die Nutzung von MySensors in FHEM ist (nicht nur für den Anfänger) mit der standardmäßig eingeschalteten [[autocreate|autocreate-Funktion]] einfach umsetzbar. Die Kenntnis der FHEM-Grundlagen und Durcharbeitung der Anfänger-Lektüren wird im Folgenden vorausgesetzt. Insbesondere sind [[Erste Schritte in FHEM]] und [http://fhem.de/Heimautomatisierung-mit-fhem.pdf Heimautomatisierung mit FHEM] Pflicht! Dort werden wesentliche Punkte für ein Verständnis von FHEM vermittelt, auch wenn manches nicht mehr ganz aktuell ist. So sollte man z.B. ein direktes Editieren der fhem.cfg unterlassen.

Im Folgenden werden immer wieder Auszüge aus der [[Konfiguration]] dargestellt. Diese dienen zur Erläuterung und Veranschaulichung. Die Bearbeitung der [[Konfiguration]] sollte - zur Verhinderung von Fehlern - nach Möglichkeit immer über das "[[Konfiguration#Befehl-Eingabefeld|Befehl-Eingabefeld]]" und die "[[Konfiguration#Objektdetails|Objektdetails]]" erfolgen.

=== Vorbereitung: Gateway ===
Zunächst ist das I/O-Device zu definieren, also das Gateway. Dies ist in [[MYSENSORS]] beschrieben.
{{Hinweis|Bei Verwendung eines seriellen Gateways ist zu empfehlen, einen Arduino mit orginalem FTDI-Chip zu verwenden und diesen mit der "by-id"-Methode ([[Trick_der_Woche#CUL_.26_CO_.C3.BCber_Serial_ID-einbinden]]) zuzuweisen. Beim Anschluß mehrer Arduinos mit einem CHG340/CHG341 an denselben Computer/Raspberry sind diese nur mit hohem {{Link2Forum|Topic=44926|Message=446809|LinkText=Aufwand}} eindeutig addressierbar.}}
{{Hinweis|Die Einbindung eines MySensors-Netzwerks kann auch über [http://fhem.de/commandref.html#MQTT MQTT] erfolgen. Dabei übernimmt ein MySensors-MQTT-Gateway die Kommunikation mit dem Broker. Der Autor hat hier jedoch keine eigene Erfahrung, bitte entsprechend nachtragen!}}

Serielles Gateway am Raspberry PI:
define MyGateway_0 MYSENSORS /dev/ttyUSB0@115200

Nach erfolgreicher Definition ist das Gateway im Raum "Everything" in der Gruppe "MYSENSORS" zu finden. Wenn unten "initialized" oder "opened" angezeigt wird, ist FHEM in der Lage, mit dem MySensors-Netz zu kommunizieren. Es sollte dann noch auf [[autocreate]] gestellt werden.

=== Das Gateway ist auch ein MySensors-Device ===
{{Hinweis|Sobald die ersten Meßwerte übertragen wurden, werden '''nach einem Browser-Refresh''' auch die aktuellen Meßwerte angezeigt, dies kann je nach Einstellung im Sketch aber einige Zeit dauern.}}
{{Randnotiz|RNTyp=g|RNText=Die Readings werden dem Modul MYSENSOR_DEVICE.pm entnommen. Sind diese dort nicht im Bereich "reads" bzw. "sends" enthalten, kann man fehlende Readings auch manuell anlegen. }}
Da am Gateway gleichzeitig auch bereits Sensoren angeschlossen sein können, legt FHEM direkt auch ein erstes [[MYSENSORS_DEVICE]] mit der NodeID "0" an. Sollten bereits ChildIDs im presentation()-Abschnitt des Gateway-Sketches enthalten gewesen sein, werden auch die zum Typ des präsentierten Sensor-Child-Typs passenden Readings automatisch angelegt.

=== Das erste Funk-MySensors-Device ===
In der Regel ist aber das erste "echte" MySensors-Device die 2. Node, die neben dem Gateway in Betrieb genommen wird. Hier gilt das Vorgesagte entsprechend: Nach dem ersten Start sind neu erkannte Devices ebenfalls im Raum "Everything" in der Gruppe "MYSENSORS" zu finden, die readings werden automatisch angelegt. Sobald Meßwerte übermittelt werden, werden die Readings damit gefüllt und entsprechend der per Sketch programmierten Vorgaben aktualisiert.

=== Details der Wechselwirkung zwischen FHEM und MySensors ===
==== Vergabe der NodeID ====
Die Vergabe der NodeID kann entweder im einzelnen Sketch erfolgen oder automatisiert. Dabei vergibt FHEM in der Regel fortlaufend Nummern ab 100. Die erste Node mit automatischer Nummernvergabe ist daher in der Regel das Device MYSENSORS_100.
{{Hinweis|Die NodeID wird - wie einige weitere Informationen - im sog. EEPROM des Arduinos abgespeichert. Ist sie einmal vergeben, ändert sie sich auch bei einem erneuten flashen der Node nicht mehr, es sei denn, man gibt per "define" im Sketch eine andere NodeID vor.}}

==== Fehlende Sensor-Typen und Readings ====
Für Anfänger ist zu empfehlen, nur Typen und Variablen zu nutzen, die in der 10_MYSENSORS_DEVICE.pm auch hinterlegt sind. Die Angaben dort zu "receives" und "sends" sind aus der Sicht der Node gemeint. Gibt es einzelne Sensor-Typen oder Readings (noch) nicht, gibt es folgende Möglichkeiten:
*Noch nicht vorhandene Typen kann man umgehen, indem man vergleichbare andere nimmt, also z.B. Wasser- statt Gaszähler (Stand: 11/2015)
*Fehlende Readings können auch
**in die 10_MYSENSORS_DEVICE.pm manuell eingepflegt werden, das automatische Anlegen geht dann aber ggf. bei einem Update wieder verloren
**manuell, z.B. <code>attr MYSENSOR_99 mapReading_ir_send3 3 ir_send</code>
Ist das Reading einmal angelegt, wird es auch automatisch befüllt, sobald die Node einen entsprechenden Wert sendet.

==== Austausch von Variablen oder Texten ====
Es ist möglich, Informationen auch bidirektional zwischen FHEM und den Nodes auszutauschen. Dies ermöglicht z.B. die Ansteuerung von Displays oder die Konfiguration von FHEM aus. Hierzu ist es am einfachsten, ein oder mehrere S_CUSTOM-Child zu präsentieren, die jeweils bis zu 5 Variablen ermöglichen. Die Zuordnung innerhalb der Node zu internen Variablen erfolgt dann über die Auswertung der Messages entsprechend der [https://forum.mysensors.org/topic/1817/weather-and-forecast-display-for-swedish-fhem-users/2 ChildID und der Variablennummer].

==== OTA ====
MySensors unterstützt für NRF-Chips zwar grundsätzlich OTA-updates, man muß dafür aber vorübergehend einen anderen Controller als FHEM einsetzen (Stand 11/2016).
Ein Howto ist in diesem {{Link2Forum|Topic=59388.0|LinkText=Forenbeitrag}} zu finden.
Der dort verwendete Bootloader erwartet OTA-Updates fest auf Channel 76.

== Links, Tricks, Kniffe und Erfahrungen ==

=== Interessante Links ===
==== Offizielles Debugging-Schema ====
*[https://forum.mysensors.org/topic/666/debug-faq-and-how-ask-for-help Debug / FAQ bei MySensors.org]
==== Debug über Konsole (z.B. Putty) ====
* Über Picocom könnt ihr einfach das Gateway debuggen. Dazu in FHEM entsprechend das Device abschalten und Picocom wie folgt aufrufen. Dabei bitte /dev/ttyUSB0 entsprechend anpassen.

<nowiki>picocom /dev/ttyUSB0 -b115200 --imap lfcrlf</nowiki>

==== Vorgehensweise zur Kombination von mehreren Sketchen/Sensoren an einer Node ====
Mehrere Sensoren (Children) kann man recht einfach an einen einzigen Arduino anschließen und ist dabei nur durch die Größe des Speichers begrenzt. Die Vorgehensweise erläutert dieses [https://forum.mysensors.org/topic/2597/combining-mysensors-examples/2 Beispiel] .
==== Verschlüsselung und Signierung ====
*{{Link2Forum|Topic=67248|LinkText=Forumsbeitrag zu MySensors Verschlüsselung und Signierung}}
*[https://www.mysensors.org/about/signing Darstellung bei MySensors.org]

=== EEPROM ===
Die Nodes speichern einen Teil ihrer Einstellungen im sog. EEPROM. Dazu gehören z.B. die NodeID, der letzte bekannte "nächste" Punkt im Netzwert (RepeaterID) oder der Zustand von Relais. In der Regel ist nur die NodeID problematisch und kann beim flashen per Sketch auf einen anderen als den bisherigen Wert gestellt werden. Wer dennoch das EEPROM löschen möchte, muß den '''MySensor-Lösch-Sketch''' nehmen, der nicht "0000..." ins EEPROM schreibt wie der Arduino-Standard-Lösch-Sketch, sondern "FFFF...".

=== Funk-Themen (NRF-Chips) ===
Viele berichtete Probleme bei der Einrichtung von MySensors-Netzwerken haben ihren Ursprung in einer unzureichenden Funkverbindung. {{Hinweis|Ob dies der Fall ist, läßt sich leicht testen, indem man die fragliche Node wieder in die Nähe des Gateways bringt. Funktioniert es dort wie erwartet, liegt eine schlechte Funkverbindung vor.}}

==== Abhilfemaßnahmen ====
*Einen bzw. mehrere [https://www.mysensors.org/build/connect_radio#connecting_a_decoupling-capacitor Kondensatoren] einlöten. Es sind auch fertige Module erhältlich, die diese Bauteile und einen Spannungsregler bereits enthalten, auf die der NRF mit einem Stecksockel aufgesteckt wird.
*Einen anderen Kanal wählen; die verwendeten Frequenzen liegen im b/g-WLAN-Bereich, so dass wechselseitige Störungen möglich sind. In Deutschland sind die Kanäle bis 84 erlaubt.
*NRF tauschen (Fake NRF-Chips sind zwar verwendbar, haben aber eine deutlich reduzierte Funkreichweite)
*Ein allgemeiner Guide zur Verwendung der nrf24l01+-Module ist [https://arduino-info.wikispaces.com/Nrf24L01-2.4GHz-HowTo hier] zu finden.
*Für das Gateway empfielt es sich, ein Modul mit externer Antenne zu verwenden (NRF24L01+PA+LNA Antenna version).
*Einstellen des richtigen PA_LEVEL_...s: Insbesondere der Standardsketch für das serielle Gateway definiert diesen als LOW, was korrekt ist, wenn der interne Spannungsregler des Arduino verwendet ist. Besser ist es, die benötigten 3,3V mittels eines seperaten Spannungsreglers zu erzeugen und dann den PA_LEVEL_MAX einzustellen.
*Funkstrecken lassen sich recht unkompliziert mit Repeatern überbrücken. Dieser muß nicht zwingend eine eigene Node sein. Jede (sinnvollerweise nicht Batterie-gespeiste) Node kann per <code> #define MY_REPEATER_FEATURE </code> zum Repeater gemacht werden.
*Sonstige Vorschläge ohne Erfolgsgarantie, aber mit Unterhaltungswert:
**[http://www.instructables.com/id/Enhanced-NRF24L01/ Eigenbau-Antennenverbesserung]
**[http://blog.blackoise.de/2016/02/fixing-your-cheap-nrf24l01-palna-module/ Schirmung]

==== Buffer-Management ====
Die NRF-Chips haben nur einen begrenzten Speicher, um Nachrichten zu puffern. Dieser kann überlaufen, wenn in kurzer Folge Informationen versendet werden, z.B. mehr als 5 Temperaturwerte von 1-Wire-Sensoren. Diese Problematik verschärft sich bei der Verwendung von Message-Signing, weil dort die volle payload-Bandbreite für einzelne Nachrichten genutzt wird. Für Abhilfe sorgen kurze Pausen zwischen den einzelnen Sendungen, z.B. <code>wait(30);</code>.

=== RS485 ===
Seit 2.0.1 ist es möglich, statt der Funkmodule auch ein kabelgebundenes Netzwerk auf Basis von RS485-Modulen aufzubauen; hierfür werden 2 Adern als Datenleitung benötigt, die Zahl der Nodes in einem solchen Netzwerk ist bei Verwendung der Standardmodule auf 32 beschränkt, bei Verwendung anderer Transceiver sind auch mehr Nodes möglich. Hierfür ist ein seperates Gateway erforderlich.

==== Bekannte Probleme bei RS485 ====
(Stand: 2.1.1)

*Die Vergabe der Node-ID's muß im Sketch selbst erfolgen, die automatische Zuweisung funktioniert nicht.
*Die für die Anbindung der Module definierten PINs (8+9) sind tief im Code verankert und sollten nicht geändert werden.
*Sollte der Speicher knapp werden, empfielt es sich, statt der softserial-Variante HW_SERIAL zu verwenden. Dies benötigt ca. 10% weniger Speicher (ATmega328).

=== Ablauf des Starts einer Node ===
Beim Start durchlaufen alle Nodes nacheinander bestimmte vordefinierte Programmroutinen in folgender Reihenfolge:

==== Vorversionen ====
*setup()
*presentation()
*loop()

==== seit MySensors 2.1.0 ====
*preHwInit()
*before()
*presentation()
*setup()
*loop()

==== Im Detail ====
Dieser Ablauf ermöglicht, die Arduino-Pins vorzukonfigurieren und angeschlossenes Equipment an der für den Programmablauf richtigen Stelle zu initialisieren. Dies ist u.U. wichtig, da
*eine Node im Normalfall nicht in loop() geht, solange die presentation() nicht erfolgreich war (also solange der Controller nicht verfügbar ist). Eine Failsafe-Initialisierung von Schnittstellen sollte demnach in preHwInit() oder before() erfolgen. Es kann zusätzlich seit 2.1.1 auch die Option MY_TRANSPORT_WAIT_READY_MS min. auf 1 gesetzt werden, dann startet die loop() auch ohne Verbindung zum Gateway.
*die Initialisierung anderer SPI-Hardware auf einem gemeinsamen Bus mit den NRF-Modulem vor der presentation() erfolgen muß.

=== Beispiel-Sketche ===
*[https://forum.mysensors.org/topic/938/multisensor-multiactuator-sketch-testboard-tested-with-fhem-controller Mehrfachsensor], allerdings noch für MySensors Vers. 1.5.4
*Bidirektionale {{Link2Forum|Topic=26807|msg=449776|LinkText="Infrarot-Fernbedienung"}} aus FHEM raus iVm. remotecontrol
*mehrere [https://github.com/rejoe2/MySensors-Dallas-Address-ChildID-Consistency Dallas-Temperatursensoren] auf einem Bus eindeutig erkennen
*[https://forum.mysensors.org/topic/1817/weather-and-forecast-display-for-swedish-fhem-users/2 Display] ansteuern

[[Kategorie:Arduino]]
[[Kategorie:IP Components]]
[[Kategorie:Other Components]]

MySensors Starter Guide

2017-11-02T14:04:41Z

Rspecht: /* Offizielles Debugging-Schema */

{{Hinweis|Dieser Artikel ist im Aufbau und soll Einsteigern und Fortgeschrittenen als Referenzquelle für typische Fragen dienen. Alle sind eingeladen hier weitere Möglichkeiten einzubringen. Die beste Referenz für alle Fragen zu MySensors ist und bleibt aber die offizielle Hompage des Projekts!}}

== Einführung ==
[http://www.mysensors.org MySensors] ist ein open-Source-Projekt. Der Schwerpunkt liegt auf selbstgemachten Funk-Sensoren für die Hausautomatisierung und das "Internet der Dinge" in einer Art Baukastensystem. Die Bauanleitungen des Projekts für die einzelnen Musterbausteine sind in der Regel einfach nachzubauen, die Hard- und Softwarebauteile lassen sich dabei auch (fast beliebig) kombinieren.

=== Nodes und Children===
==== Nodes ====
Die Kombination von einem Microcontroller und einem Funkchip wird jeweils als "Node" bezeichnet.
Ein MySensors-Netzwerk besteht also (in der Regel) aus mindestens zwei Nodes, nämlich einer Gateway-Node und einer Sensor-Node. Jede Node ist durch eine sog. NodeID innerhalb des Netzwerks eindeutig identifizierbar, wobei die "0" jeweils für das Gateway reserviert ist.
Als Microcontroller werden in der Regel Arduinos (Nano oder Micro) verwendet, für das GW häufiger auch [[ESP8266]]. Als Funkchips lassen sich derzeit Module mit nRF24L01+ und RFM69 verwenden, die allerdings jeweils eine eigene Funktechnik verwendet und daher innerhalb eines Netzwerks nicht gemischt werden können. Es kann auch ein kabelgebundenes Netzwerk auf Basis von RS485-Modulen aufgebaut werden; hierfür werden 2 Adern als Datenleitung benötigt.
==== Children ====
Als Child wird alles bezeichnet, was jeweils innerhalb einer Node unterschieden werden soll. Beispiel: An einer Node wird ein BME280 angeschlossen. Dies ist ein I2C-Sensor, der drei Werte liefert, nämlich Temperatur, Luftfeuchtigkeit und Luftdruck. Jeder dieser Meßgrößen erhält üblicherweise eine eigene ChildID zugewiesen.

=== Softwarestand ===
{{Randnotiz|RNTyp=g|RNText=Der Verfasser hat in der Vergangenheit festgestellt, dass die bei MySensors beteiligten Entwickler eventuelle Verbesserungen und Fehlerkorrekturen nicht mehr in die "stable"-Version rückportieren. Bei Problemen empfiehlt es sich daher, die jeweilige beta-Version zu testen. Hierzu muß aber in der Regel auch das verwendete Gateway auf diese Version upgedated werden.}}
Bei Abfassung dieses Artikels war
*1.8.0 der Stand der verwendeten Arduino-IDE
*2.1.1 die stable-Version von MySensors.
*2.2.0-beta der aktuelle Development-Zweig von Mysensors

=== Vor- und Nachteile von MySensors ===
==== Vorteile ====
*Preisgünstig
*Modular, Elemente können (fast) beliebig kombiniert werden
*Es kann ein sog. ACK verlangt werden. Damit läßt sich sicherstellen, dass eine Node einen Befehl auch tatsächlich erhalten hat (Bidirektionalität).
*Auf den Microcontrollern kann eine eigene Funktionalität unabhängig von der zentralen FHEM-Instanz vorgesehen werden (z.B. LED-Licht direkt bei Bewegung schalten). Die Nodes können seit 2.0.1-beta dabei auch ohne Verbindung zum Gateway die loop() ausführen, wenn eine entsprechende Option aktiviert ist.
*MQTT kann unterstützt werden.
*Es kann auch eine kabelgebundene Infrastruktur aufgebaut werden (RS485, zwei Adern).

==== Nachteile ====
*Standardmäßig wird ein nicht verschüsselter Funkstandard verwendet, so dass von der Verwendung in sicherheitsrelevanten Funktionen (Türschließer usw.) abzuraten ist.

==== Zum Start ====
Für erste Tests sind sinnvoll:
{{Randnotiz|RNTyp=g|RNText=1. Für Sensbender-Boards sind spezielle [https://raw.githubusercontent.com/mysensors/ArduinoBoards/master/package_mysensors.org_index.json Board-Definitionen] für die IDE verfügbar. Nach den [https://github.com/mysensors/MySensors/releases Release Notes] sind diese ab der Version 2.0.0 zu empfehlen, die Installation erfolgt über File -> Preferencies -> Additional Boards Manager URLs
2. Manche neueren Boarddefinitionen aus der IDE führen u.U. zu häufigeren Reboots. Seit 1.6.18 scheint das Problem behoben zu sein, ansonsten ist ein Downgrade der Boarddefinitionen für AVR-Boards bis <=1.6.11 zu empfehlen.}}
*eine Arduino mit USB-Anschluß (Nano) oder ein ESP8266
*ein weiterer Arduino Nano
*zwei nRF24L01+ (alternativ: zwei RFM69)
*Die Arduino-IDE
*die gewünschte Sensorik, also z.B. einen DS18B20+Widerstand, ein Bewegungsmelder-Modul, ... siehe dazu die [https://www.mysensors.org/build Build-Anleitungen bei MySensors.org], wo auch Bezugsquellen zu finden sind.

== MySensors in FHEM ==
=== Allgemein ===
Die Nutzung von MySensors in FHEM ist (nicht nur für den Anfänger) mit der standardmäßig eingeschalteten [[autocreate|autocreate-Funktion]] einfach umsetzbar. Die Kenntnis der FHEM-Grundlagen und Durcharbeitung der Anfänger-Lektüren wird im Folgenden vorausgesetzt. Insbesondere sind [[Erste Schritte in FHEM]] und [http://fhem.de/Heimautomatisierung-mit-fhem.pdf Heimautomatisierung mit FHEM] Pflicht! Dort werden wesentliche Punkte für ein Verständnis von FHEM vermittelt, auch wenn manches nicht mehr ganz aktuell ist. So sollte man z.B. ein direktes Editieren der fhem.cfg unterlassen.

Im Folgenden werden immer wieder Auszüge aus der [[Konfiguration]] dargestellt. Diese dienen zur Erläuterung und Veranschaulichung. Die Bearbeitung der [[Konfiguration]] sollte - zur Verhinderung von Fehlern - nach Möglichkeit immer über das "[[Konfiguration#Befehl-Eingabefeld|Befehl-Eingabefeld]]" und die "[[Konfiguration#Objektdetails|Objektdetails]]" erfolgen.

=== Vorbereitung: Gateway ===
Zunächst ist das I/O-Device zu definieren, also das Gateway. Dies ist in [[MYSENSORS]] beschrieben.
{{Hinweis|Bei Verwendung eines seriellen Gateways ist zu empfehlen, einen Arduino mit orginalem FTDI-Chip zu verwenden und diesen mit der "by-id"-Methode ([[Trick_der_Woche#CUL_.26_CO_.C3.BCber_Serial_ID-einbinden]]) zuzuweisen. Beim Anschluß mehrer Arduinos mit einem CHG340/CHG341 an denselben Computer/Raspberry sind diese nur mit hohem {{Link2Forum|Topic=44926|Message=446809|LinkText=Aufwand}} eindeutig addressierbar.}}
{{Hinweis|Die Einbindung eines MySensors-Netzwerks kann auch über [http://fhem.de/commandref.html#MQTT MQTT] erfolgen. Dabei übernimmt ein MySensors-MQTT-Gateway die Kommunikation mit dem Broker. Der Autor hat hier jedoch keine eigene Erfahrung, bitte entsprechend nachtragen!}}

Serielles Gateway am Raspberry PI:
define MyGateway_0 MYSENSORS /dev/ttyUSB0@115200

Nach erfolgreicher Definition ist das Gateway im Raum "Everything" in der Gruppe "MYSENSORS" zu finden. Wenn unten "initialized" oder "opened" angezeigt wird, ist FHEM in der Lage, mit dem MySensors-Netz zu kommunizieren. Es sollte dann noch auf [[autocreate]] gestellt werden.

=== Das Gateway ist auch ein MySensors-Device ===
{{Hinweis|Sobald die ersten Meßwerte übertragen wurden, werden '''nach einem Browser-Refresh''' auch die aktuellen Meßwerte angezeigt, dies kann je nach Einstellung im Sketch aber einige Zeit dauern.}}
{{Randnotiz|RNTyp=g|RNText=Die Readings werden dem Modul MYSENSOR_DEVICE.pm entnommen. Sind diese dort nicht im Bereich "reads" bzw. "sends" enthalten, kann man fehlende Readings auch manuell anlegen. }}
Da am Gateway gleichzeitig auch bereits Sensoren angeschlossen sein können, legt FHEM direkt auch ein erstes [[MYSENSORS_DEVICE]] mit der NodeID "0" an. Sollten bereits ChildIDs im presentation()-Abschnitt des Gateway-Sketches enthalten gewesen sein, werden auch die zum Typ des präsentierten Sensor-Child-Typs passenden Readings automatisch angelegt.

=== Das erste Funk-MySensors-Device ===
In der Regel ist aber das erste "echte" MySensors-Device die 2. Node, die neben dem Gateway in Betrieb genommen wird. Hier gilt das Vorgesagte entsprechend: Nach dem ersten Start sind neu erkannte Devices ebenfalls im Raum "Everything" in der Gruppe "MYSENSORS" zu finden, die readings werden automatisch angelegt. Sobald Meßwerte übermittelt werden, werden die Readings damit gefüllt und entsprechend der per Sketch programmierten Vorgaben aktualisiert.

=== Details der Wechselwirkung zwischen FHEM und MySensors ===
==== Vergabe der NodeID ====
Die Vergabe der NodeID kann entweder im einzelnen Sketch erfolgen oder automatisiert. Dabei vergibt FHEM in der Regel fortlaufend Nummern ab 100. Die erste Node mit automatischer Nummernvergabe ist daher in der Regel das Device MYSENSORS_100.
{{Hinweis|Die NodeID wird - wie einige weitere Informationen - im sog. EEPROM des Arduinos abgespeichert. Ist sie einmal vergeben, ändert sie sich auch bei einem erneuten flashen der Node nicht mehr, es sei denn, man gibt per "define" im Sketch eine andere NodeID vor.}}

==== Fehlende Sensor-Typen und Readings ====
Für Anfänger ist zu empfehlen, nur Typen und Variablen zu nutzen, die in der 10_MYSENSORS_DEVICE.pm auch hinterlegt sind. Die Angaben dort zu "receives" und "sends" sind aus der Sicht der Node gemeint. Gibt es einzelne Sensor-Typen oder Readings (noch) nicht, gibt es folgende Möglichkeiten:
*Noch nicht vorhandene Typen kann man umgehen, indem man vergleichbare andere nimmt, also z.B. Wasser- statt Gaszähler (Stand: 11/2015)
*Fehlende Readings können auch
**in die 10_MYSENSORS_DEVICE.pm manuell eingepflegt werden, das automatische Anlegen geht dann aber ggf. bei einem Update wieder verloren
**manuell, z.B. <code>attr MYSENSOR_99 mapReading_ir_send3 3 ir_send</code>
Ist das Reading einmal angelegt, wird es auch automatisch befüllt, sobald die Node einen entsprechenden Wert sendet.

==== Austausch von Variablen oder Texten ====
Es ist möglich, Informationen auch bidirektional zwischen FHEM und den Nodes auszutauschen. Dies ermöglicht z.B. die Ansteuerung von Displays oder die Konfiguration von FHEM aus. Hierzu ist es am einfachsten, ein oder mehrere S_CUSTOM-Child zu präsentieren, die jeweils bis zu 5 Variablen ermöglichen. Die Zuordnung innerhalb der Node zu internen Variablen erfolgt dann über die Auswertung der Messages entsprechend der [https://forum.mysensors.org/topic/1817/weather-and-forecast-display-for-swedish-fhem-users/2 ChildID und der Variablennummer].

==== OTA ====
MySensors unterstützt für NRF-Chips zwar grundsätzlich OTA-updates, man muß dafür aber vorübergehend einen anderen Controller als FHEM einsetzen (Stand 11/2016).
Ein Howto ist in diesem {{Link2Forum|Topic=59388.0|LinkText=Forenbeitrag}} zu finden.
Der dort verwendete Bootloader erwartet OTA-Updates fest auf Channel 76.

== Links, Tricks, Kniffe und Erfahrungen ==

=== Interessante Links ===
==== Offizielles Debugging-Schema ====
*[https://forum.mysensors.org/topic/666/debug-faq-and-how-ask-for-help Debug / FAQ bei MySensors.org]
==== Debug über Konsole (z.B. Putty) ====
* Über Picocom könnt ihr einfach das Gateway debuggen. Dazu in FHEM entsprechend das Device abschalten und Picocom wie folgt aufrufen: picocom /dev/ttyUSB0 -b115200 --imap lfcrlf
/dev/ttyUSB0 bitte entsprechend anpassen.

==== Vorgehensweise zur Kombination von mehreren Sketchen/Sensoren an einer Node ====
Mehrere Sensoren (Children) kann man recht einfach an einen einzigen Arduino anschließen und ist dabei nur durch die Größe des Speichers begrenzt. Die Vorgehensweise erläutert dieses [https://forum.mysensors.org/topic/2597/combining-mysensors-examples/2 Beispiel] .
==== Verschlüsselung und Signierung ====
*{{Link2Forum|Topic=67248|LinkText=Forumsbeitrag zu MySensors Verschlüsselung und Signierung}}
*[https://www.mysensors.org/about/signing Darstellung bei MySensors.org]

=== EEPROM ===
Die Nodes speichern einen Teil ihrer Einstellungen im sog. EEPROM. Dazu gehören z.B. die NodeID, der letzte bekannte "nächste" Punkt im Netzwert (RepeaterID) oder der Zustand von Relais. In der Regel ist nur die NodeID problematisch und kann beim flashen per Sketch auf einen anderen als den bisherigen Wert gestellt werden. Wer dennoch das EEPROM löschen möchte, muß den '''MySensor-Lösch-Sketch''' nehmen, der nicht "0000..." ins EEPROM schreibt wie der Arduino-Standard-Lösch-Sketch, sondern "FFFF...".

=== Funk-Themen (NRF-Chips) ===
Viele berichtete Probleme bei der Einrichtung von MySensors-Netzwerken haben ihren Ursprung in einer unzureichenden Funkverbindung. {{Hinweis|Ob dies der Fall ist, läßt sich leicht testen, indem man die fragliche Node wieder in die Nähe des Gateways bringt. Funktioniert es dort wie erwartet, liegt eine schlechte Funkverbindung vor.}}

==== Abhilfemaßnahmen ====
*Einen bzw. mehrere [https://www.mysensors.org/build/connect_radio#connecting_a_decoupling-capacitor Kondensatoren] einlöten. Es sind auch fertige Module erhältlich, die diese Bauteile und einen Spannungsregler bereits enthalten, auf die der NRF mit einem Stecksockel aufgesteckt wird.
*Einen anderen Kanal wählen; die verwendeten Frequenzen liegen im b/g-WLAN-Bereich, so dass wechselseitige Störungen möglich sind. In Deutschland sind die Kanäle bis 84 erlaubt.
*NRF tauschen (Fake NRF-Chips sind zwar verwendbar, haben aber eine deutlich reduzierte Funkreichweite)
*Ein allgemeiner Guide zur Verwendung der nrf24l01+-Module ist [https://arduino-info.wikispaces.com/Nrf24L01-2.4GHz-HowTo hier] zu finden.
*Für das Gateway empfielt es sich, ein Modul mit externer Antenne zu verwenden (NRF24L01+PA+LNA Antenna version).
*Einstellen des richtigen PA_LEVEL_...s: Insbesondere der Standardsketch für das serielle Gateway definiert diesen als LOW, was korrekt ist, wenn der interne Spannungsregler des Arduino verwendet ist. Besser ist es, die benötigten 3,3V mittels eines seperaten Spannungsreglers zu erzeugen und dann den PA_LEVEL_MAX einzustellen.
*Funkstrecken lassen sich recht unkompliziert mit Repeatern überbrücken. Dieser muß nicht zwingend eine eigene Node sein. Jede (sinnvollerweise nicht Batterie-gespeiste) Node kann per <code> #define MY_REPEATER_FEATURE </code> zum Repeater gemacht werden.
*Sonstige Vorschläge ohne Erfolgsgarantie, aber mit Unterhaltungswert:
**[http://www.instructables.com/id/Enhanced-NRF24L01/ Eigenbau-Antennenverbesserung]
**[http://blog.blackoise.de/2016/02/fixing-your-cheap-nrf24l01-palna-module/ Schirmung]

==== Buffer-Management ====
Die NRF-Chips haben nur einen begrenzten Speicher, um Nachrichten zu puffern. Dieser kann überlaufen, wenn in kurzer Folge Informationen versendet werden, z.B. mehr als 5 Temperaturwerte von 1-Wire-Sensoren. Diese Problematik verschärft sich bei der Verwendung von Message-Signing, weil dort die volle payload-Bandbreite für einzelne Nachrichten genutzt wird. Für Abhilfe sorgen kurze Pausen zwischen den einzelnen Sendungen, z.B. <code>wait(30);</code>.

=== RS485 ===
Seit 2.0.1 ist es möglich, statt der Funkmodule auch ein kabelgebundenes Netzwerk auf Basis von RS485-Modulen aufzubauen; hierfür werden 2 Adern als Datenleitung benötigt, die Zahl der Nodes in einem solchen Netzwerk ist bei Verwendung der Standardmodule auf 32 beschränkt, bei Verwendung anderer Transceiver sind auch mehr Nodes möglich. Hierfür ist ein seperates Gateway erforderlich.

==== Bekannte Probleme bei RS485 ====
(Stand: 2.1.1)

*Die Vergabe der Node-ID's muß im Sketch selbst erfolgen, die automatische Zuweisung funktioniert nicht.
*Die für die Anbindung der Module definierten PINs (8+9) sind tief im Code verankert und sollten nicht geändert werden.
*Sollte der Speicher knapp werden, empfielt es sich, statt der softserial-Variante HW_SERIAL zu verwenden. Dies benötigt ca. 10% weniger Speicher (ATmega328).

=== Ablauf des Starts einer Node ===
Beim Start durchlaufen alle Nodes nacheinander bestimmte vordefinierte Programmroutinen in folgender Reihenfolge:

==== Vorversionen ====
*setup()
*presentation()
*loop()

==== seit MySensors 2.1.0 ====
*preHwInit()
*before()
*presentation()
*setup()
*loop()

==== Im Detail ====
Dieser Ablauf ermöglicht, die Arduino-Pins vorzukonfigurieren und angeschlossenes Equipment an der für den Programmablauf richtigen Stelle zu initialisieren. Dies ist u.U. wichtig, da
*eine Node im Normalfall nicht in loop() geht, solange die presentation() nicht erfolgreich war (also solange der Controller nicht verfügbar ist). Eine Failsafe-Initialisierung von Schnittstellen sollte demnach in preHwInit() oder before() erfolgen. Es kann zusätzlich seit 2.1.1 auch die Option MY_TRANSPORT_WAIT_READY_MS min. auf 1 gesetzt werden, dann startet die loop() auch ohne Verbindung zum Gateway.
*die Initialisierung anderer SPI-Hardware auf einem gemeinsamen Bus mit den NRF-Modulem vor der presentation() erfolgen muß.

=== Beispiel-Sketche ===
*[https://forum.mysensors.org/topic/938/multisensor-multiactuator-sketch-testboard-tested-with-fhem-controller Mehrfachsensor], allerdings noch für MySensors Vers. 1.5.4
*Bidirektionale {{Link2Forum|Topic=26807|msg=449776|LinkText="Infrarot-Fernbedienung"}} aus FHEM raus iVm. remotecontrol
*mehrere [https://github.com/rejoe2/MySensors-Dallas-Address-ChildID-Consistency Dallas-Temperatursensoren] auf einem Bus eindeutig erkennen
*[https://forum.mysensors.org/topic/1817/weather-and-forecast-display-for-swedish-fhem-users/2 Display] ansteuern

[[Kategorie:Arduino]]
[[Kategorie:IP Components]]
[[Kategorie:Other Components]]

Einrichten knxd mit MDT SCN-IP000.02

2017-06-05T09:59:57Z

Rspecht:

== Vorwort ==
Im Rahmen einer Machbarkeitsstudie ging es um das Thema Zählererfassung im betrieblichen Umfeld. Dazu sollten diverse Techniken und Bus-Systeme mit einbezogen werden.
Als eine Art (halb privates) Nebenprojekt kam auch die Verknüpfung zwischen FHEM und einem KNX-Zählerbaustein zum Einsatz.
Es gibt hier im Wiki zwar schon die Beschreibung [[Einrichten_von_eibd_für_das_Weinzierl_IP_730_Interface]], aber diese beschäftigt sich mit anderer Hardware und dem eib-daemon.

== Voraussetzungen ==
===Hardware===
:* MDT IP-Interface SCN-IP000.02. Wird später als IP-Tunneling-Device verwendet. Adresse wird über DHCP bezogen. '''Sollte geändert werden'''
:* MDT 4fach Binäreingang BE-04000.01. Dient als Zählermodul
:* MDT Spannungsversorgung STV-0160.01. Achtung! Es kann keine Standard 24V Spannungsversorgung verwendet werden, da diese nicht die für KNX benötigte Drossel enthält
===Software===
:* FHEM 5.7 Installation auf Raspberry Pi 3, gemäß Anleitung (folgt!), '''Raspian Jessie'''
:* ETS 5.0 wird für die Konfiguration der KNX-Komponenten benötigt. Kostenfreie Demo-Lizenz. Beschränkt auf 5 Geräte. Download von [https://knx.org/knx-de/software/ets/herunterladen/index.php KNX.org]
:* Katalog-Datei für die ETS vom Binär-Eingang. Quelle: [http://www.mdt.de/Downloads_Produktdatenbanken.html MDT-Homepage]

==Installation von knxd==
KNX-Daemon für Linux installieren: [[Knxd#Installation]]

==Konfiguration von knxd==
:* ''/etc/knxd.conf'' anlegen. Relevant ist nur die letzte Zeile. Die originale Datei enthält eine für das System nicht funktionierende Konfiguration. Daher wird der gesamte Inhalt der Datei hier dokumentiert.
<pre>
# configuration for knxd.service
#KNXD_OPTS="-u /tmp/eib -b ip:"

# The default options are "-u /tmp/eib -b ip:"
# which tell knxd to route between all of
# /tmp/eib (legacy socket (-u))
# multicast client (-b ip:).
# The knxd.socket file also tells knxd to listen to
# /run/eib (socket activation via systemd)
# TCP port 6720 (socket activation via systemd)

# *** DO NOT use "-u" / "-u /run/knx" or "-i" / "-i 6720" here.
# Systemd already does that on behalf of knxd, via 'knx.socket'.

# If you have KNX hardware on a serial port or USB, add the appropriate
# "-b TYPE:…" option. In this case, you probably want to set up a multicast
# server, not a client (i.e. use "-D -T -R -S", not "-b ip:").
# DO NOT use both.
#
# If your KNX hardware is a KNX/IP gateway that doesn't do multicast,
# use "-b ipt:192.168.1.2" (or its DNS name) to talk to it.
#
# KNX MUST NOT have more than one path between any two devices. Thus,
# you need to make sure that the KNX/IP gateway does not route multicast
# before you use both "-S" and "-b ipt:".

# The default bus address of knxd is 0.0.1. If that's in use in your KNX
# network (or if you run more than one knxd on your network), set a
# different address (-e 15.0.99).

# Run `knxd --help` to get a complete list of available options and drivers.

## DO NOT use the following options:
## -i -- /lib/systemd/system/knxd.socket does this for us
## -u /run/knx -- likewise
## -d -- /lib/systemd/system/knxd.service expects knxd to run in the foreground

###############################################################################
# This file is ignored when NOT using systemd: edit /etc/default/knxd instead #
###############################################################################
KNXD_OPTS="-e 1.0.240 -b ipt:192.168.0.88"
</pre>

Die ''192.168.0.88'' ist exemplarisch für die IP-Adresse eures KNX-Gateways.

:* Der Daemon sollte auch einem Jessie-System mit dem System starten.
Der Status des KNX-Dienstes kann mit ''systemctl status knxd.service'' geprüft werden. Die Ausgabe sollte so ähnlich aussehen:
<pre>
root@rasspi-fhem99:~# systemctl status knxd.service
● knxd.service - KNX Daemon
Loaded: loaded (/lib/systemd/system/knxd.service; enabled)
Active: active (running) since Mo 2016-04-11 13:35:53 CEST; 14s ago
Main PID: 1258 (knxd)
CGroup: /system.slice/knxd.service
└─1258 /usr/bin/knxd -e 1.0.240 -b ipt:192.168.0.88
</pre>
Wichtig ist, dass die IP-Adresse des Gateways und die eib-Adresse (1.0.240) in der letzten Zeile stehen.

Der Dienst kann auch manuell gestartet und gestoppt werden:
Start:
<pre>
systemctl start knxd.service
</pre>
Beenden:
<pre>
systemctl stop knxd.service
systemctl stop knxd.socket
</pre>
Achtung! wird der Dienst beendet während FHEM in benutzt, '''hängt sich FHEM auf''' und muss neu gestartet werden.

* Definition des IP-Gateways in FHEM:
<pre>
define KNX TUL eibd:192.168.0.1 1.0.240
</pre>
''192.168.0.1'' Adresse des KNX-Daemons, i.d.R. localhost

''1.0.240'' EIB-Adresse für FHEM/KNXD

Nach dem FHEM-Neustart sollte das neue Device "KNX" den Status "Initialized" haben.

Falls ihr Probleme mit der systemd socket activation habt könnt ihr diese mit "systemctl disable knxd.socket" ausschalten. Dann müsst ihr aber wieder -u und -i einfügen!

== Installation/Konfiguration ETS==
Die ETS wird benötigt um KNX-Sensoren/Aktoren zu parametrieren und ihnen EIB-konforme Adressen zuzuweisen.
Ich empfehle an dieser Stelle das Dokument "Grundlagenwissen zum KNX Standard", welches von [https://www.google.de/url?sa=t&rct=j&q=&esrc=s&source=web&cd=1&ved=0ahUKEwi9w-O74ojMAhVBfxoKHeXKByAQFggkMAA&url=http%3A%2F%2Fwww.knx.org%2Ffileadmin%2Fdownloads%2F08%2520-%2520KNX%2520Flyers%2FGrundlagenwissen%2520zum%2520KNX%2520Standard%2FGrundlagenwissen_zum_KNX_Standard_German.pdf&usg=AFQjCNETdgrIp23RbSTx-E8Q0qFuNH1hBw&cad=rja KNX.org] heruntergeladen werden kann.

===Einrichtung des Binäreingangs BE-04000-01 in ETS===
* Bevor der Binär-Eingang benutzt werden kann, muss dieser in ETS konfiguriert werden.
Dazu wird in ETS zunächst ein Projekt angelegt. Als "Linientyp" wird TP (Twisted Pair) definiert.
Das IP-Gateway wird von der ETS selbstständig gefunden.
* Bevor das Gerät selbst in ETS angezeigt werden kann, muss eine Struktur für das Gerät erzeugt werden:
[[Datei:Ets struktur.png]]

1 Gebäudestruktur: Haus -> Keller -> Unterverteilung

2 Adressstruktur: "1 Haupt" -> "1/1 Mittel" -> "1/1/1 Schalter" 1.1.1 ist demnach die spätere Adresse für Schalteingang A des 4fach Geräts

3 Katalog-Import: Hier wird der Katalog für das Gerät importiert. Dieser wird dann per DragNDrop auf die erstellte Struktur "Unterverteilung" gezogen

* Jetzt kann das Gerät "Binäreingang 4-fach..." parametriert werden. Dazu im mittleren Fenster den Reiter "Parameter" wählen
[[Datei:Geraet parametrieren.png]]

Hier kann jetzt für jeden Eingang des Bausteins die entsprechende Funktion eingestellt werden, z.B. Schalter, Zähler, usw.
* Aus dem unteren Fenster werden nun per Drag N Drop die erstellten Gruppenadressen auf die jeweiligen Eingänge des Geräts gezogen. Damit wird auch die EIB-Adresse für jeden Eingang festgelegt.
* Jetzt muss das Gerät noch programmiert werden. Dazu Programmieren -> Physikalische Adresse und Applikationsprogramm

=== Installation/Konfiguration FHEM===
* In FHEM sollten jetzt die neu erzeugten EIB-Geräte angezeigt werden. Voraussetzung ist ein aktiviertes AutoCreate in ''fhem.cfg''
<pre>
define autocreate autocreate
</pre>
*[[Datei:Fhem eib.png]]

* Der Schalteingang wird als Glühbirne dargestellt
* Beim Zählereingang steht nur der Zählerstand als HEX-Zahl. In der ETS lässt sich für den Zähleingang festlegen, wie oft er Counter-Werte übertragen soll, z.B. alle 30 Impulse sollen übermittelt werden

[[Kategorie: Examples]]
[[Kategorie:EIB/KNX]]

SNOM

2016-04-01T12:58:24Z

Rspecht: /* Durchsage */

== Durchsage ==
Ausgangslage: Ein FHEM mit funktionierender Sprachausgabe (Text2Speech) über den angeschlossenen Lautsprecher.
Ziel: Die gleiche Durchsage auch auf allen SNOM 370 Telefonden abspielen.

Da die Snom-Geräte Audiomulticast unterstützen kommt dieses hier zum Einsatz.

Aktiviert wird es in den Einstellungen des Telefons. Hierzu muss am Telefon mit dem Knopf '''Settings''' das Einstellungsmenü aufgerufen werden. Hier kann man über den Eintrag '''Wartung''' und dann den Eintrag '''Administratormodus''' das Webfrontend freischalten.
Nun geht es vom PC aus mit dem Browser weiter. Dazu die IP des Telefons eingeben und unter '''Ewetiert''' den Reiter '''SIP/RTP''' anwählen.
Ganz unten gibt es nun eine Tabelle namens '''Multicast''' wo wir die '''Multicast Unterstützung''' auf '''An''' setzen. Darunter geben wir die Multicast IP Adresse sowie den dazugehörigen Port ein. Als Multicast IP kann man sich irgendwas im Range 224.0.0.0 - 239.255.255.255 aussuchen. Hier gibt es keine Abhängigkeit vom lokalen Subnetz - Wieso, Weshalb und Warum findet ihr in den RFC's [https://tools.ietf.org/html/rfc5771].

Dann geht es auf dem Raspberry Pi weiter - hier benötigt man FFMPEG. Ihr müsst es selbst kompilieren da in dem raspian Paket keine Filter eingebaut sind. Dazu findet ihr alles unter [http://www.jeffreythompson.org/blog/2014/11/13/installing-ffmpeg-for-raspberry-pi/].

Den ersten Test startet ihr mit folgendem Befehl: Bitte denkt daran die IP, den Port sowie die MP3 Datei (auf eine vorhandene) anzupassen.
ffmpeg -re -i "/opt/fhem/cache/d08c473c8d5f7f1b7ac252ce80d0b12a.mp3" -filter_complex 'aresample=8000,asetnsamples=n=160,volume=0.25' -acodec pcm_mulaw -ac 1 -vn -f rtp rtp://IP:PORT

Um es in FHEM aufrufen zu dürfen benötigt ihr einen SUDO Eintrag:
fhem ALL=NOPASSWD: /usr/local/bin/ffmpeg *

Unter FHEM ist es z.B. aus einem Notify wie folgt ansprechbar:
system('ffmpeg -re -i /opt/fhem/"' . $value . '" -filter_complex "aresample=8000,asetnsamples=n=160,volume=0.25" -acodec pcm_mulaw -ac 1 -vn -f rtp rtp://IP:PORT');

Damit das Text2Speech Modul ein passendes Notify abwirft müsst ihr an den Quellcode von dem Modul:
Dazu öffnet ihr die Datei 98_Text2Speech.pm und springt auf Zeile 619 - Dass ist das Ende der Routine ''sub Text2Speech_BuildMplayerCmdString($$) {'' und fügt vor dem '''return $cmd;''' folgende Zeile ein:
readingsSingleUpdate($hash, "file", $file, 1);
Nun wird bei jedem Zusammenbau des Mplayer Kommandos der Dateiname an FHEM übergeben und kann dort über ein Notify ausgewertet werden.

Nun noch das Notify anlegen:

MyTTS {
my $command = (substr($EVENT, 0, 4));;
my $value = (substr($EVENT, 6,(length($EVENT)-1)));;
Log 1, "$EVENT";;
if($command eq "file") {
Log 1, "$value";;
system('ffmpeg -re -i /opt/fhem/"' . $value . '" -filter_complex "aresample=8000,asetnsamples=n=160,volume=0.25" -acodec pcm_mulaw -ac 1 -vn -f rtp rtp://IP:PORT');
}
}

SNOM

2016-04-01T12:58:11Z

Rspecht: /* Durchsage */

SNOM

2016-04-01T11:12:45Z

Rspecht: /* Durchsage */

== Durchsage ==
FFMPEG bauen:
http://www.jeffreythompson.org/blog/2014/11/13/installing-ffmpeg-for-raspberry-pi/

Snom Freigabe auf seite ...?

erster test: ffmpeg -re -i "/opt/fhem/cache/d08c473c8d5f7f1b7ac252ce80d0b12a.mp3" -filter_complex 'aresample=8000,asetnsamples=n=160,volume=0.25' -acodec pcm_mulaw -ac 1 -vn -f rtp rtp://IP:PORT

Dann noch sudo freigeben:
fhem ALL=NOPASSWD: /usr/local/bin/ffmpeg *

Ein notify mit dateinamen erzeugen lassen:

readingsSingleUpdate($hash, "file", $file, 1); in 98_Text2Speech.pm einbauen

<nowiki> if(-e $file) { # Datei existiert jetzt
readingsSingleUpdate($hash, "file", $file, 1);
$cmd = Text2Speech_BuildMplayerCmdString($hash, $file);
Log3 $hash->{NAME}, 4, "Text2Speech: " .$cmd;
system($cmd);
}
</nowiki>

und das Notify anlegen:
<nowiki>
MyTTS {
my $command = (substr($EVENT, 0, 4));;
my $value = (substr($EVENT, 6,(length($EVENT)-1)));;
Log 1, "$EVENT";;
if($command eq "file") {
Log 1, "$value";;
system('ffmpeg -re -i /opt/fhem/"' . $value . '" -filter_complex "aresample=8000,asetnsamples=n=160,volume=0.25" -acodec pcm_mulaw -ac 1 -vn -f rtp rtp://IP:PORT');
}

}
</nowiki>

Bei mir ist die Podcast IP:PORT 238.255.255.252:5432 im 192.168er Netz...

SNOM

2016-04-01T07:40:17Z

Rspecht: Die Seite wurde neu angelegt: „== Durchsage == FFMPEG bauen: http://www.jeffreythompson.org/blog/2014/11/13/installing-ffmpeg-for-raspberry-pi/ Snom Freigabe auf seite ...? erster test: f…“

Yowsup

2015-10-28T21:37:14Z

Rspecht: /* Anwendungsbeispiele */

{{SEITENTITEL:yowsup}}
{{Infobox Modul
|ModPurpose=Schnittstelle, um WhatsApp-Nachrichten empfangen und senden zu können.
|ModType=d
|ModCmdRef=yowsup
|ModFTopic=27543
|ModForumArea=Unterstuetzende Dienste
|ModTechName=32_yowsup.pm
|ModOwner=André / justme1968 ({{Link2FU|430|Forum}} / [[Benutzer Diskussion:justme|Wiki]])
}}

Das Modul [[yowsup]] dient dazu, WhatsApp-Nachrichten zu empfangen und zu senden.

== Voraussetzungen ==
* Die Funktionalität ist vermutlich auf Linux/Unix Systeme beschränkt.
* Nach der Erstinstallation/-einrichtung '''muss''' zwingend das ''cmd'' Attribut korrekt gesetzt werden.

== Installation ==
Die ursprüngliche Einrichtung wurde hier {{Link2Forum|Topic=27543|Message=204426|LinkText=hier beschrieben}}, jedoch sind noch einige wichtige Dinge zu setzen.

=== Yowsup Installation ===
Bevor man loslegt sollte man wie immer sicherstellen, dass Debian auf dem aktuellen Stand ist:
<code>sudo apt-get update</code>
<code>sudo apt-get upgrade</code>
<code>sudo apt-get dist-upgrade</code>

Los gehts mit den Paketen:
<code>sudo apt-get install python-soappy python-dateutil python-pip python-dev build-essential</code>

Nun erstmal pip updaten:
<code>sudo pip install --upgrade pip</code>

Und dann axolotl installieren (das dauert ne Weile):
<code>sudo pip install python-axolotl</code>

Will man Bilder verarbeiten, so braucht man noch ein paar Pakete mehr:
* Paketinstallationen:
** Unter Debian Wheezy: <code>sudo apt-get install libtiff4-dev libjpeg8-dev zlib1g-dev libfreetype6-dev liblcms2-dev libwebp-dev tcl8.5-dev tk8.5-dev python-tk</code>
** Unter Debian Jessie: <code>sudo apt-get install libtiff5-dev libjpeg-dev zlib1g-dev libfreetype6-dev liblcms2-dev libwebp-dev tcl8.5-dev tk8.5-dev python-tk</code>
* PIP:<code>sudo pip install pillow</code>

Vor den weiteren Schritten sollte geprüft werden, ob dem User fhem eine Loginshell zugewiesen ist:
:<code>getent passwd fhem</code>
Wird hier am Ende /bin/false ausgegeben, so muss dies angepasst werden:
:<code>sudo chsh -s /bin/bash fhem</code>

Mittels ''getent passwd fhem'' kann auch bereits das Home-Verzeichnis ausgelesen werden, dies steht in der ausgegebenen Doppelpunkt-separierten Liste an vorletzter Stelle.

Nun loggt man sich unter dem User ein, unter dem fhem läuft (in den folgenden Beispielen werden die vom fhem-Setup-Script generierten Defaults verwendet: User=fhem , home=/opt/fhem Gruppe=dialout) und liest dort die $HOME-Variable aus und prüft das Home-Verzeichnis:
<pre>sudo su - fhem
echo $HOME
cd $HOME
logout</pre>
Diesen Wert braucht man später - gut merken. Sollte hier ein Fehler auftreten (z.B. das home nicht vorhanden), so muss dies zuerst korrigiert werden.

Desweiteren muss man nun yowsup installieren, was wie folgt vonstatten geht:
<pre>cd /opt
sudo mkdir yowsup-config
sudo wget https://github.com/tgalal/yowsup/archive/master.zip
sudo unzip master.zip
rm master.zip
cd yowsup-config
sudo nano yowsup.config</pre>

Wie bemerkt, ist man nun im Editor für die yowsup.config gelandet. Diese wird nun wie folgt gefüllt:
<pre>## Actual config starts below ##

#cc ist wichtig ansonsten funktioniert es nicht aus dem Script
cc=49
phone=498912345678
id=0000000000
password=</pre>
Ersetze die Nummer 498912345678 gegen eine Festnetz oder Handynummer welche derzeit nicht mit WhatsApp verwendet wird. Mittels STRG+o wird die Datei nun gespeichert und mittels STRG+x verlässt man den Editor.

Vor den weiteren Schritten sollte man nun erstmal die yowsup Verzeichnisse dem fhem-user zugängig machen:
<pre>sudo chown -R fhem:dialout /opt/yowsup-master /opt/yowsup-config</pre>

Für die folgenden Schritte würde ich auf den FHEM-Nutzer wechseln:
<pre>sudo su - fhem
cd /opt/yowsup-master</pre>

Nun erfolgt die Anmeldung am WhatsApp-Server. Dies kann man nun via <code>voice</code> oder <code>sms</code> machen. Bei einem Handy bietet sich SMS an, bei Festnetzanschlüssen sollte voice gewählt werden, wenn man sich nicht sicher ist, dass der Anschluss die Funktion 'SMS im Festnetz' unterstützt. Dann wird der Bestätigungscode zwar auf Englisch vorgelesen, dafür ist die Zuverlässigkeit des Registrierungsvorganges zuverlässiger. Bei Festnetznummern sollte man unbedingt etwas zum schreiben bereit halten!
<pre>python yowsup-cli registration -c /opt/yowsup-config/yowsup.config -r sms</pre>

Die Rückmeldung ist nun entscheidend. Wenn man diese zurückbekommt:
<pre>de sms
status: fail
retry_after: 3600
reason: no_routes</pre>
Dann ist die Nummer so nicht kompatibel. Was man dann noch probieren kann, ist die registration via voice - meistens ist das aber vergebene Liebesmüh'.

Wenn man folgende Rückmeldung bekommt:
<pre>Detected cc: 49
status: sent
retry_after: 1805
length: 6
method: sms</pre>

So ist alles gut gelaufen und man sollte kurz später eine SMS bekommen. Darin ist ein Text, der am Ende z.B. 123-456 lautet. Diesen fügt man ohne Bindestrich am Ende des folgenden Befehls ein:
<pre>python yowsup-cli registration -c /opt/yowsup-config/yowsup.config -R 123456</pre>

Dann kommt ein Text der etwa so aussehen sollte:
<pre>status: ok
kind: free
pw: bfGA9wPWWNeHcSBxxxxxxxxxxxxxxxxx
price: 0,89 €
price_expiration: 1432127524
currency: EUR
cost: 0.89
login: 498912345678
type: existing
expiration: 1460832553</pre>
Den Text hinter dem Zeilenanfang <code>pw: </code> benötigt man nun für die Konfigurationsdatei, wo dieser eingefügt werden muss:
<pre>nano /opt/yowsup-config/yowsup.config</pre>
Sodass die Datei beispielhaft dann so aussieht:
<pre>## Actual config starts below ##

#cc ist wichtig ansonsten funktioniert es nicht aus dem Script
cc=49
phone=498912345678
id=0000000000
password=bfGA9wPWWNeHcSBxxxxxxxxxxxxxxxxx</pre>

Wie man schon gesehen hat, ist der Account nur begrenzt gültig - die Gültigkeit kann man anhand der als <code>expiration: </code> bezeichneten Zeile ablesen, welche einen Unix-Timestamp beinhaltet. Diese kann man [http://elmar-eigner.de/tstamps.html?zeichen=1444570276&timeformat=2 HIER] umrechnen lassen.

Nun mal ein schneller test an die eigene Nummer (im Beispiel 491751234567):
<pre>python yowsup-cli demos -c /opt/yowsup-config/yowsup.config -s 491751234567 "Das ist ein Test"</pre>

Das sollte dir eine Nachricht einbringen. Wenn du darauf antwortest, kommt diese allerdings noch nicht an - der Client hat sich nach dem Befehl sofort beendet. Damit dieser dauerhaft im Hintergrund läuft legen wir nun in FHEM ein Gerät an, welches dies steuert.

=== FHEM Define ===
* Fhem Device anlegen: <code> define <name> yowsup</code>, also z.B. <code>define WhatsApp yowsup</code>
* Nun muss man den Pfad zu yowsup anpassen: <code>attr WhatsApp cmd /opt/yowsup-master/yowsup-cli demos -c /opt/yowsup-config/yowsup.config --yowsup</code>
* Und das Home directory mit dem Pfad zum Home des fhem users: <code>attr WhatsApp home PWD</code>
* Wenn alles gut geht, gibt es danach im Device ein internal PID und das Reading ''state''
* Im Whatsapp Client auf dem Handy sollte man sehen, dass Fhem online ist
* Zum Senden aus Fhem kann man das Kommando <code>set WhatsApp send <nummer> <text></code> verwenden

== Attribute ==
Bitte sehe immer in der [[http://fhem.de/commandref.html#yowsup Commandref]] nach - diese hier könnten veraltet sein.

* <code>cmd</code> komplettes Kommando, um den yowsup Client zu starten. z.B.: <code>attr WhatsApp cmd /opt/local/bin/yowsup-cli demos -c /root/config.yowsup --yowsup</code>. Wenn die ab yowsup-Version 2.4 standartmässig aktivierte Verschlüsselung abgeschaltet werden muss weil die entsprechenden Libs nicht installiert sind: <code>attr WhatsApp cmd /opt/local/bin/yowsup-cli demos -c /root/config.yowsup --yowsup -M</code>.
* <code>accept_from</code> kommagetrennte Liste von Kontakten (Nummern), von denen Nachrichten akzeptiert werden. Ist das Attribut nicht gesetzt, so werden die Nachrichten von jedem akzeptiert.
* <code>commandPrefix</code> nicht gesetzt -> es werden keine Befehle akzeptiert. 0 -> es werden keine Befehle akzeptiert. 1 -> erlaubt Befehle, jede Nachricht wird als Fhem-Befehl interpretiert. alles andere -> Wenn die Nachricht mit diesem Prefix startet, wird alles weitere als Befehle interpretiert.
{{Randnotiz|RNTyp=Warn|RNText='''allowedCommands''' should work as intended, but no guarantee can be given, that there is no way to circumvent it.}}
* <code>allowedCommands</code> Eine Komma-getrennte Liste von zulässigen Befehlen für diesen Kontakt. Wenn die Liste leer ist (z.B. nur ein Komma), dann werden keine Befehle akzeptiert.
* <code>home</code> Setzt das Home-directory welches für yowsup verwendet werden soll.

== Befehle ==
* image -> Über diesen Befehl können Bilder gesendet werden.

* raw -> Status ändern :
<code>set WhatsApp raw /profile setStatus 'mein Status' <--- die ' ' müssen bleiben</code>

Name der angezeigt werden soll, wenn eine Nachricht z.B. ans iPhone geschickt wird:

<code>set WhatsApp raw /presence name <DeinNick></code>

Anzeige online :

<code>set WhatsApp raw /presence available</code>

Profilbild ändern :

<code>set WhatsApp raw /profile setPicture '/opt/fhem/fhem_logo.png'</code>
<--- der gesamte Pfad zum Bild muss angegeben werden und Rechte müssen ggfs. bei fhem liegen

Falls es nicht funktioniert disconnect/connect probieren.

== Anwendungsbeispiele ==
=== Beispielnachricht ===
Beim Empfang einer Nachricht wird automatisch ein Fhem Device für diesen Kontakt angelegt. In diesem Device gibt es das Reading '''message''' für die empfangene Nachricht und ab der ersten Nachricht auch das Reading '''chatstate''', in dem zu sehen ist, ob gerade getippt wird.
Nachdem ein Device für einen Kontakt angelegt ist, lässt sich auch direkt dieses Device zum Senden verwenden:
:<code>set <device> send <text></code>,
d.h., man spart sich die Angabe der Nummer.

=== Gruppen ===
Gruppennachrichten werden von yowsup mit Sonderzeichen im Absender empfangen:
: 49yyyyyyyyyyyy/49xxxxxxxxxxx-1234567890
: absender/gründer-timestamp
Aufgrund der Sonderzeichen schlägt das automatische Anlegen einer yowsup Instanz fehl. Es kann aber zum Versenden direkt die JID der Gruppe genutzt werden, oder manuell die yowsup Instanz ohne Sonderzeichen gemacht werden.
: erst kommt die Nummer des Gruppenerstellers, dann die Uhrzeit im Unix Zeitformat.
: 49xxxxxxxxxxx-1234567890
: gründer-timestamp
:<code>define whatsapp.gruppe yowsup 49xxxxxxxxxxx-1234567890</code>
==== JID der Gruppe ermitteln ====
Am einfachsten ist es, eine Nachricht an die Gruppe zu senden und aus der Fehlermeldung von Fhem die JID herauszusuchen.
Etwas gezielter geht es mit der Auflistungsfunktion von yowsup direkt.
:<code>set WhatsApp raw /groups list</code>

Um die Ergebnisse eines raw Befehls im Log zu sehen, muss noch [[verbose]] 4 gesetzt werden:
:<code>attr WhatsApp verbose 4</code>
Dieses Attribut sollte, wenn nicht mehr benötigt, wieder gelöscht werden, um unnötige Logeinträge zu vermeiden.

=== Komponenten steuern ===
Um ein Notify anlegen zu können müssen wir zuerst eine Nachricht vom Handy an den FHEM senden. Dadurch wird ein Device mit der Nummer als Namen angelegt. Danach sollte das Device umbenannt werden da einige Befehle einen Namen ausschließlich aus Ziffern nicht akzeptieren. Dies geschieht wie folgt:

<code>rename 49123456789 HandySeppel</code>

Danach kann ein Notify angelegt werden:

<code>
define notifySeppelLicht notify (HandySeppel:message.*) {
if (ReadingsVal("HandySeppel","message",0) eq "Licht an") {
fhem "set HandySeppel send Licht ist nun an...";;
fhem "set FS20_a5d800 dim100%"
} else {
if (ReadingsVal("HandySeppel","message",0) eq "Licht aus") {
fhem "set HandySeppel send Licht ist nun aus...";;
fhem "set FS20_a5d800 dim0%"
} else {
fhem "set HandySeppel send Wie bitte?"
}}}</code>

Natürlich ist dieses Notify noch auf die eigenen Wünsche anzupassen.... :)

== Links ==
* {{Link2Forum|Topic=27543|LinkText=Forenthread}}, in dem die Whatsapp Anwendung beschrieben wird
* {{Link2Forum|Topic=27543|Message=299292|LinkText=Foreneintrag}}, ab dem das yowsup Modul beschrieben wird
* Die Python Whatsapp Library auf [https://github.com/tgalal/yowsup github]
* Imagehandling Bugfix [https://github.com/tgalal/yowsup/issues/901 github]

Yowsup

2015-10-28T18:42:29Z

Rspecht: /* Installation */

{{SEITENTITEL:yowsup}}
{{Infobox Modul
|ModPurpose=Schnittstelle, um WhatsApp-Nachrichten empfangen und senden zu können.
|ModType=d
|ModCmdRef=yowsup
|ModFTopic=27543
|ModForumArea=Unterstuetzende Dienste
|ModTechName=32_yowsup.pm
|ModOwner=André / justme1968 ({{Link2FU|430|Forum}} / [[Benutzer Diskussion:justme|Wiki]])
}}

Das Modul [[yowsup]] dient dazu, WhatsApp-Nachrichten zu empfangen und zu senden.

== Voraussetzungen ==
* Die Funktionalität ist vermutlich auf Linux/Unix Systeme beschränkt.
* Nach der Erstinstallation/-einrichtung '''muss''' zwingend das ''cmd'' Attribut korrekt gesetzt werden.

== Installation ==
Die ursprüngliche Einrichtung wurde hier {{Link2Forum|Topic=27543|Message=204426|LinkText=hier beschrieben}}, jedoch sind noch einige wichtige Dinge zu setzen.

=== Yowsup Installation ===
Bevor man loslegt sollte man wie immer sicherstellen, dass Debian auf dem aktuellen Stand ist:
<code>sudo apt-get update</code>
<code>sudo apt-get upgrade</code>
<code>sudo apt-get dist-upgrade</code>

Los gehts mit den Paketen:
<code>sudo apt-get install python-soappy python-dateutil python-pip python-dev build-essential</code>

Nun erstmal pip updaten:
<code>sudo pip install --upgrade pip</code>

Und dann axolotl installieren (das dauert ne Weile):
<code>sudo pip install python-axolotl</code>

Will man Bilder verarbeiten, so braucht man noch ein paar Pakete mehr:
* Paketinstallationen:
** Unter Debian Wheezy: <code>sudo apt-get install libtiff4-dev libjpeg8-dev zlib1g-dev libfreetype6-dev liblcms2-dev libwebp-dev tcl8.5-dev tk8.5-dev python-tk</code>
** Unter Debian Jessie: <code>sudo apt-get install libtiff5-dev libjpeg-dev zlib1g-dev libfreetype6-dev liblcms2-dev libwebp-dev tcl8.5-dev tk8.5-dev python-tk</code>
* PIP:<code>sudo pip install pillow</code>

Vor den weiteren Schritten sollte geprüft werden, ob dem User fhem eine Loginshell zugewiesen ist:
:<code>getent passwd fhem</code>
Wird hier am Ende /bin/false ausgegeben, so muss dies angepasst werden:
:<code>sudo chsh -s /bin/bash fhem</code>

Mittels ''getent passwd fhem'' kann auch bereits das Home-Verzeichnis ausgelesen werden, dies steht in der ausgegebenen Doppelpunkt-separierten Liste an vorletzter Stelle.

Nun loggt man sich unter dem User ein, unter dem fhem läuft (in den folgenden Beispielen werden die vom fhem-Setup-Script generierten Defaults verwendet: User=fhem , home=/opt/fhem Gruppe=dialout) und liest dort die $HOME-Variable aus und prüft das Home-Verzeichnis:
<pre>sudo su - fhem
echo $HOME
cd $HOME
logout</pre>
Diesen Wert braucht man später - gut merken. Sollte hier ein Fehler auftreten (z.B. das home nicht vorhanden), so muss dies zuerst korrigiert werden.

Desweiteren muss man nun yowsup installieren, was wie folgt vonstatten geht:
<pre>cd /opt
sudo mkdir yowsup-config
sudo wget https://github.com/tgalal/yowsup/archive/master.zip
sudo unzip master.zip
rm master.zip
cd yowsup-config
sudo nano yowsup.config</pre>

Wie bemerkt, ist man nun im Editor für die yowsup.config gelandet. Diese wird nun wie folgt gefüllt:
<pre>## Actual config starts below ##

#cc ist wichtig ansonsten funktioniert es nicht aus dem Script
cc=49
phone=498912345678
id=0000000000
password=</pre>
Ersetze die Nummer 498912345678 gegen eine Festnetz oder Handynummer welche derzeit nicht mit WhatsApp verwendet wird. Mittels STRG+o wird die Datei nun gespeichert und mittels STRG+x verlässt man den Editor.

Vor den weiteren Schritten sollte man nun erstmal die yowsup Verzeichnisse dem fhem-user zugängig machen:
<pre>sudo chown -R fhem:dialout /opt/yowsup-master /opt/yowsup-config</pre>

Für die folgenden Schritte würde ich auf den FHEM-Nutzer wechseln:
<pre>sudo su - fhem
cd /opt/yowsup-master</pre>

Nun erfolgt die Anmeldung am WhatsApp-Server. Dies kann man nun via <code>voice</code> oder <code>sms</code> machen. Bei einem Handy bietet sich SMS an, bei Festnetzanschlüssen sollte voice gewählt werden, wenn man sich nicht sicher ist, dass der Anschluss die Funktion 'SMS im Festnetz' unterstützt. Dann wird der Bestätigungscode zwar auf Englisch vorgelesen, dafür ist die Zuverlässigkeit des Registrierungsvorganges zuverlässiger. Bei Festnetznummern sollte man unbedingt etwas zum schreiben bereit halten!
<pre>python yowsup-cli registration -c /opt/yowsup-config/yowsup.config -r sms</pre>

Die Rückmeldung ist nun entscheidend. Wenn man diese zurückbekommt:
<pre>de sms
status: fail
retry_after: 3600
reason: no_routes</pre>
Dann ist die Nummer so nicht kompatibel. Was man dann noch probieren kann, ist die registration via voice - meistens ist das aber vergebene Liebesmüh'.

Wenn man folgende Rückmeldung bekommt:
<pre>Detected cc: 49
status: sent
retry_after: 1805
length: 6
method: sms</pre>

So ist alles gut gelaufen und man sollte kurz später eine SMS bekommen. Darin ist ein Text, der am Ende z.B. 123-456 lautet. Diesen fügt man ohne Bindestrich am Ende des folgenden Befehls ein:
<pre>python yowsup-cli registration -c /opt/yowsup-config/yowsup.config -R 123456</pre>

Dann kommt ein Text der etwa so aussehen sollte:
<pre>status: ok
kind: free
pw: bfGA9wPWWNeHcSBxxxxxxxxxxxxxxxxx
price: 0,89 €
price_expiration: 1432127524
currency: EUR
cost: 0.89
login: 498912345678
type: existing
expiration: 1460832553</pre>
Den Text hinter dem Zeilenanfang <code>pw: </code> benötigt man nun für die Konfigurationsdatei, wo dieser eingefügt werden muss:
<pre>nano /opt/yowsup-config/yowsup.config</pre>
Sodass die Datei beispielhaft dann so aussieht:
<pre>## Actual config starts below ##

#cc ist wichtig ansonsten funktioniert es nicht aus dem Script
cc=49
phone=498912345678
id=0000000000
password=bfGA9wPWWNeHcSBxxxxxxxxxxxxxxxxx</pre>

Wie man schon gesehen hat, ist der Account nur begrenzt gültig - die Gültigkeit kann man anhand der als <code>expiration: </code> bezeichneten Zeile ablesen, welche einen Unix-Timestamp beinhaltet. Diese kann man [http://elmar-eigner.de/tstamps.html?zeichen=1444570276&timeformat=2 HIER] umrechnen lassen.

Nun mal ein schneller test an die eigene Nummer (im Beispiel 491751234567):
<pre>python yowsup-cli demos -c /opt/yowsup-config/yowsup.config -s 491751234567 "Das ist ein Test"</pre>

Das sollte dir eine Nachricht einbringen. Wenn du darauf antwortest, kommt diese allerdings noch nicht an - der Client hat sich nach dem Befehl sofort beendet. Damit dieser dauerhaft im Hintergrund läuft legen wir nun in FHEM ein Gerät an, welches dies steuert.

=== FHEM Define ===
* Fhem Device anlegen: <code> define <name> yowsup</code>, also z.B. <code>define WhatsApp yowsup</code>
* Nun muss man den Pfad zu yowsup anpassen: <code>attr WhatsApp cmd /opt/yowsup-master/yowsup-cli demos -c /opt/yowsup-config/yowsup.config --yowsup</code>
* Und das Home directory mit dem Pfad zum Home des fhem users: <code>attr WhatsApp home PWD</code>
* Wenn alles gut geht, gibt es danach im Device ein internal PID und das Reading ''state''
* Im Whatsapp Client auf dem Handy sollte man sehen, dass Fhem online ist
* Zum Senden aus Fhem kann man das Kommando <code>set WhatsApp send <nummer> <text></code> verwenden

== Attribute ==
Bitte sehe immer in der [[http://fhem.de/commandref.html#yowsup Commandref]] nach - diese hier könnten veraltet sein.

* <code>cmd</code> komplettes Kommando, um den yowsup Client zu starten. z.B.: <code>attr WhatsApp cmd /opt/local/bin/yowsup-cli demos -c /root/config.yowsup --yowsup</code>. Wenn die ab yowsup-Version 2.4 standartmässig aktivierte Verschlüsselung abgeschaltet werden muss weil die entsprechenden Libs nicht installiert sind: <code>attr WhatsApp cmd /opt/local/bin/yowsup-cli demos -c /root/config.yowsup --yowsup -M</code>.
* <code>accept_from</code> kommagetrennte Liste von Kontakten (Nummern), von denen Nachrichten akzeptiert werden. Ist das Attribut nicht gesetzt, so werden die Nachrichten von jedem akzeptiert.
* <code>commandPrefix</code> nicht gesetzt -> es werden keine Befehle akzeptiert. 0 -> es werden keine Befehle akzeptiert. 1 -> erlaubt Befehle, jede Nachricht wird als Fhem-Befehl interpretiert. alles andere -> Wenn die Nachricht mit diesem Prefix startet, wird alles weitere als Befehle interpretiert.
{{Randnotiz|RNTyp=Warn|RNText='''allowedCommands''' should work as intended, but no guarantee can be given, that there is no way to circumvent it.}}
* <code>allowedCommands</code> Eine Komma-getrennte Liste von zulässigen Befehlen für diesen Kontakt. Wenn die Liste leer ist (z.B. nur ein Komma), dann werden keine Befehle akzeptiert.
* <code>home</code> Setzt das Home-directory welches für yowsup verwendet werden soll.

== Befehle ==
* image -> Über diesen Befehl können Bilder gesendet werden.

* raw -> Status ändern :
<code>set WhatsApp raw /profile setStatus 'mein Status' <--- die ' ' müssen bleiben</code>

Name der angezeigt werden soll, wenn eine Nachricht z.B. ans iPhone geschickt wird:

<code>set WhatsApp raw /presence name <DeinNick></code>

Anzeige online :

<code>set WhatsApp raw /presence available</code>

Profilbild ändern :

<code>set WhatsApp raw /profile setPicture '/opt/fhem/fhem_logo.png'</code>
<--- der gesamte Pfad zum Bild muss angegeben werden und Rechte müssen ggfs. bei fhem liegen

Falls es nicht funktioniert disconnect/connect probieren.

== Anwendungsbeispiele ==
=== Beispielnachricht ===
Beim Empfang einer Nachricht wird automatisch ein Fhem Device für diesen Kontakt angelegt. In diesem Device gibt es das Reading '''message''' für die empfangene Nachricht und ab der ersten Nachricht auch das Reading '''chatstate''', in dem zu sehen ist, ob gerade getippt wird.
Nachdem ein Device für einen Kontakt angelegt ist, lässt sich auch direkt dieses Device zum Senden verwenden:
:<code>set <device> send <text></code>,
d.h., man spart sich die Angabe der Nummer.

=== Gruppen ===
Gruppennachrichten werden von yowsup mit Sonderzeichen im Absender empfangen:
: 49yyyyyyyyyyyy/49xxxxxxxxxxx-1234567890
: absender/gründer-timestamp
Aufgrund der Sonderzeichen schlägt das automatische Anlegen einer yowsup Instanz fehl. Es kann aber zum Versenden direkt die JID der Gruppe genutzt werden, oder manuell die yowsup Instanz ohne Sonderzeichen gemacht werden.
: erst kommt die Nummer des Gruppenerstellers, dann die Uhrzeit im Unix Zeitformat.
: 49xxxxxxxxxxx-1234567890
: gründer-timestamp
:<code>define whatsapp.gruppe yowsup 49xxxxxxxxxxx-1234567890</code>
==== JID der Gruppe ermitteln ====
Am einfachsten ist es, eine Nachricht an die Gruppe zu senden und aus der Fehlermeldung von Fhem die JID herauszusuchen.
Etwas gezielter geht es mit der Auflistungsfunktion von yowsup direkt.
:<code>set WhatsApp raw /groups list</code>

Um die Ergebnisse eines raw Befehls im Log zu sehen, muss noch [[verbose]] 4 gesetzt werden:
:<code>attr WhatsApp verbose 4</code>
Dieses Attribut sollte, wenn nicht mehr benötigt, wieder gelöscht werden, um unnötige Logeinträge zu vermeiden.

== Links ==
* {{Link2Forum|Topic=27543|LinkText=Forenthread}}, in dem die Whatsapp Anwendung beschrieben wird
* {{Link2Forum|Topic=27543|Message=299292|LinkText=Foreneintrag}}, ab dem das yowsup Modul beschrieben wird
* Die Python Whatsapp Library auf [https://github.com/tgalal/yowsup github]
* Imagehandling Bugfix [https://github.com/tgalal/yowsup/issues/901 github]

ReadingsGroup

2015-10-27T12:23:18Z

Rspecht: /* Ausgabestil (hier rechtsbündig) */

{{SEITENTITEL:readingsGroup}}
{{Infobox Modul
|ModPurpose=Einfache zusammenfassende Darstellung von Informationen über mehrere Geräte und deren Steuerung
|ModType=h
|ModCmdRef=readingsGroup
|ModForumArea=Frontends
|ModTechName=33_readingsGroup.pm
|ModOwner=Andre ([http://forum.fhem.de/index.php?action=profile;u=430 Forum] / [[Benutzer Diskussion:justme|Wiki]])}}

Das Fhem-[[:Kategorie:Hilfsmodul|Hilfsmodul]] [[readingsGroup]] bietet eine einfache Möglichkeit, ''Readings'' (kein Präfix vor dem Reading-Namen), ''Internals'' (Präfix "+" vor dem Namen des internen Wertes) und ''Attributes'' (Präfix "?" vor dem Namen des Attributs) von einem oder mehreren ''Devices'' darzustellen und flexibel zu formatieren.

Die Aktualisierung im Browserfenster geschieht per longpoll und überträgt nur die jeweils geänderten Zellen. Wenn eine readingsGroup in keinem Browserfenster angezeigt wird findet keine longpoll aktualisierung statt.

== Definition ==
Siehe [http://fhem.de/commandref.html#readingsGroup commandref].

== Attribute ==
{{Randnotiz|RNText=In allen Mappings die einen Hash verwenden muss der Key (das was jeweils links von => Operator steht) in Anführungszeichen stehen. Die einzige Ausnahme hiervon sind Keys die aus einem String bestehen der mit einem Buchstaben beginnt und nur Buchstaben und Zahlen enthält.}}
Weitergehende Erläuterungen zu einzelnen Attributen.

Die komplette Liste der Attribute ist der commandref zu entnehmen.

=== noheading ===
[[Datei:ReadingsGroup_noheading.png|mini|rechts|400px|ReadingsGroup: rechts mit "noheading" Attribut, links der anklickbare Titel]]
Das Attribut <code>noheading</code> führt dazu, dass der Alias der ReadingsGroup nicht mehr als Titel angezeigt wird. Das kann wünschenswert sein, wenn die ReadingsGroup auf einer [[Dashboard]]-Seite angezeigt werden soll, hat allerdings den Nachteil, dass die Detail-Ansicht der ReadingsGroup nicht mehr über einen Klick auf den Titel aufgerufen werden kann. Der Einstellungsdialog der ReadingsGroup ist dann nur noch (z. B.) über
* <code>list TYPE=readingsGroup</code>
* einen "Probably associated with"-Link eines anderen Objekts oder über
* manuelle Modifikation der URL eines anderen Objekts (<code>http:.../fhem?detail=<objektname></code>)
erreichbar.

=== nolinks ===
Devicenamen und Titel der readingsGroup verlinken nicht mehr zur zugehörigen Detailansicht und sind nicht mehr anklickbar.

=== nostate ===
Das state-Reading wird bei regex match nicht berücksichtigt und nicht angezeigt.

=== notime ===
Es werden keine Timestamps für die Readings angezeigt. Nur für einspaltige readingsGroups sinnvoll.

== Beispiele ==
Bitte beachten: die folgenden Beispiele enthalten keine Maskierungen oder Verdoppelungen für ; und Zeilenende, sondern sind so angegeben, wie sie im [[PGM2|Web Interface]] im Befehls-Eingabefeld, nach Klick auf DEF und im Attribut-Eingabefeld eingegeben werden. Beim manuellen Einfügen in eine [[Konfiguration|Konfigurationsdatei]] sind diese Maskierungen oder Verdoppelungen natürlich vorzunehmen.

=== Einfache Auswahl über Reading-Namen ===
{| class="wikitable"
! Definition !! Erläuterungen !! Aussehen
|-
| style="width:40%" |<code>define battStatus readingsGroup .*:[Bb]attery</code>
| Alle readings mit Namen '''Battery''' oder '''battery''' von allen Devices.
| rowspan=3 | [[Datei:rgBattery.png|thumb]]
|-
| <code>attr battStatus alias FHT Batteriestatus </code>
| Der Alias wird als Zeilentitel verwendet
|-
| <code>attr battStatus mapping %ROOM </code>
| ''Mapping %ROOM'' führt dazu, dass der Raumname als Zeilentitel angezeigt wird.
|}

=== Übersicht HomeMatic Geräte ===

<nowiki>define HM_Components readingsGroup <Gerät>,<Name>,<Model>,<S/N> TYPE=CUL_HM:+NAME,?model,D-serialNr</nowiki>

=== Auswahl über Reading-Namen, Status als Symbol dargestellt ===
{| class="wikitable"
! Definition !! Erläuterungen !! Aussehen
|-
| style="width:40%" |<code>define rg_battery readingsGroup .*:battery</code>
| Alle readings mit Namen '''battery''' von allen Devices.
| rowspan=4 | [[Datei:rgBattery2.png|thumb]]
|-
| <code>attr rg_battery alias Batteriestatus </code>
| Der Alias wird als Überschrift verwendet
|-
| <code>attr rg_battery valueIcon {'battery.ok' => 'batterie', 'battery.low' => 'batterie@red'}</code>
| Statt der reading Werte "ok" und "low" soll ein Icon angezeigt werden.
|-
|<code>attr rg_battery commands { "battery.low" => "set %DEVICE replaceBatteryForSec 60" }</code>
| Für LaCrosse devices kann man beim Klick auf ein rotes "battery low icon" direkt replaceBatteryForSec setzen.
|}

=== Reading-Werte zuordnen (Icon / Text) ===
{| class="wikitable"
! Definition !! Erläuterungen !! Aussehen
|-
| style="width:40%" |<code>define rg readingsGroup Contact.Dachboden_gross:sensed.*</code>
| Alle sensedreadings des Contact.Dachboden_gross device.
| rowspan=4 | [[Datei:rgFenster.png|thumb]]
|-
| <code>attr rg mapping { 'sensed.A' => 'links', 'sensed.B' => 'rechts' }</code>
| Die Zuordnung rechts/links
|-
| <code>attr rg valueFormat {($VALUE eq '1')?"fts_window_roof":"fts_window_roof_open_2"}</code>
| Die Zuordnung von reading Wert zu Icon Namen.
|-
| <code>attr rg_battery valueIcon %VALUE </code>
| Statt des reading Werts soll ein Icon angezeigt werden.
|}

=== Formatvorgabe für Ausgabewerte ===
{| class="wikitable"
! Definition !! Erläuterungen !! Aussehen
|-
| style="width:40%" |<code>define TempHygro readingsGroup TYPE=CUL_WS:temperature,humidity,dewpoint</code>
| Alle readings mit Namen '''temperature''', '''humidity''', '''dewpoint''' von allen Devices des Typs '''CUL_WS'''
| rowspan=4 | [[Datei:rgTemperatur.png|thumb|[[S300TH]]-Werte in einer readingsGroup]]
|-
| <code>attr TempHygro alias Temperatur / rel. Feuchte / Taupunkt</code>
| Der Alias der readingsGroup wird als Überschrift verwendet
|-
| <code>attr TempHygro mapping %ALIAS</code>
| ''Mapping %ALIAS'' führt dazu, dass der Alias des Geräts als Zeilentitel angezeigt wird.
|-
| <code>attr TempHygro valueFormat { temperature => "%.1f&deg;C", humidity => "%.1f %%", dewpoint => "%.1f&deg;C"}</code>
| Formatierung der Ausgabewerte. '''Achtung:''' "%" die in der Ausgabe erscheinen sollen, müssen verdoppelt werden!
|}

=== Ausgabestil (hier rechtsbündig) ===
{| class="wikitable"
! Definition !! Erläuterungen !! Aussehen
|-
| style="width:40%" |<code>define Wetter readingsGroup WetterXXX:<%temp_temperature>,<Temperatur>,temperature WetterXXX:<%weather_humidity>,<Luftfeuchte>,humidity WetterXXX:<%weather_barometric_pressure>,<Luftdruck>,pressure
</code>
| Die readings mit Namen '''temperature''', '''humidity''' und '''pressure''' vom Device WetterXXX jeweils mit einem Icon und einem Label davor.
| rowspan=3 | [[Datei:rgWetter.png|thumb]]
|-
| <code>attr Wetter valueFormat { temperature => '%1.f &deg;C', humidity => '%1.f %%', pressure => '%i mbar' }</code>
| Die Formatierung der Readingswerte
|-
| <code>attr Wetter valueStyle style="text-align:right"</code>
| Die Readings sollen rechtsbündig dargestellt werden.
|}

=== Internal Value ausgeben ===
Diese Beispiel könnte entfallen (nächstes Beispiel ist sehr ähnlich; es wird lediglich ein weiterer Wert ausgegeben).
{| class="wikitable"
! Definition !! Erläuterungen !! Aussehen
|-
| style="width:40%" |<code>define culRSSI readingsGroup cul_RSSI=.*:+cul_RSSI</code>
| Den RSSI Wert aller Devices (am IODev ''cul'') die einen solchen haben anzeigen. '''Achtung''': "internal values" werden nicht per longpoll aktualisiert, sondern nur beim Seitenaufbau.
| rowspan=1 | [[Datei:rgculRSSI.png|thumb]]
|}

=== Internal Values ausgeben ===
{| class="wikitable"
! Definition !! Erläuterungen !! Aussehen
|-
| style="width:40%" |<code>define culRSSI readingsGroup cul_RSSI=.*:+cul_RSSI,+cul_TIME</code>
| Den RSSI Wert mit der zugehörigen Zeit aller Devices (am IODev ''cul'') die einen solchen haben anzeigen. '''Achtung''': "internal values" werden nicht per longpoll aktualisiert, sondern nur beim Seitenaufbau. "Internal Values" werden durch das vorangestellte '''+''' (Pluszeichen) identifiziert.
| rowspan=2 | [[Datei:rgculRSSI2.png|thumb]]
|-
|attr culRSSI valueStyle {return undef if($READING =~ m/TIME/); ($VALUE <= -85)?'style="color:red"':($VALUE <= -80)?'style="color:yellow"':undef}
|Schlechte RSSI Werte sollen abhängig von zwei Schwellwerten gelb oder rot eingefärbt werden (auf dem Screenshot nicht zu sehen).
|}

=== Alle Readings eines Gerätes, mit Ausnahme von... ===
{| class="wikitable"
! Definition !! Erläuterungen !! Aussehen
|-
| style="width:40%" |<code>define Systemstatus readingsGroup sysstat</code>
| Alle readings des sysstat Device
| rowspan=4 | [[Datei:rgSysstat.png|thumb]]
|-
| <code>attr Systemstatus nostate 1</code>
| Ohne state
|-
| <code>attr Systemstatus notime 1</code>
| Ohne readings timestamp
|-
| <code>attr Systemstatus mapping {'load' => 'Systemauslastung', 'temperature' => 'Systemtemperatur in &deg;C'}</code>
| Die Zuordnung der reading Namen zu den Zeilentiteln
|}

=== Anzeige auf einem Floorplan ===
{| class="wikitable"
! Definition !! Erläuterungen !! Aussehen
|-
| style="width:40%" |<code>define Heizung readingsGroup t(1|2|3):temperature</code>
| Die Temperatur readings der Devices t1, t2 und t3
| rowspan=6 | [[Datei:rgHeizung.png|thumb|220px]]
|-
| <code>attr Heizung mapping {'t1.temperature' => 'Vorlauf', 't2.temperature' => 'R&ücklauf', 't3.temperature' => 'Zirkulation'}</code>
| Die Zuordnung der reading Namen zu den Zeilentiteln
|-
| <code>attr Heizung nameStyle style="text-align:left"</code>
| Zeilentitel linksbündig wegen floorplan
|-
| <code>attr Heizung style style="font-size:20px;color:lightgray"</code>
| Großer Font und Farbe passend für den floorplan
|-
| <code>attr Heizung notime 1</code>
| Ohne readings timestamp
|-
| <code>attr Heizung valueFormat : %.1f &deg;C</code>
| Doppelpunkt zwischen Zeilentitel und Wert, eine Nachkommastelle plus Einheit
|}

=== LightScene DropDown-Menü für smallscreen Styles oder Floorplan ===

{| class="wikitable"
! Definition !! Erläuterungen !! Aussehen
|-
| style="width:40%" |<code>define lcDropDown meineLightScene:!state</code>
| Für die LightScene ''meineLightScene'' soll ein DropDown-Menü zur Auswahl der Szene erstellt werden.
| rowspan=6 |
|-
| <code>attr lcDropDown commands { state => 'scene:' }</code>
| Die Anzeige des state Readings wird auf das DropDown-Menü für das scene Kommando gemapped.
|-
| <code>attr lcDropDown nonames 1</code>
| Keine Readingnamen
|-
| <code>attr lcDropDown notime 1</code>
| Kein Timestamp
|}

=== Schriftgrößen, Farben, Icons ===
{| class="wikitable"
! Definition !! Erläuterungen
|-
| colspan=2 | [[Datei:rgVerbrauchPCA301.png|links|mini|400px|Schriftgröße, Farbe, Icons...]]
|-
| style="width:40%" |<code>define Verbrauch readingsGroup TYPE=PCA301:state,power,consumption</code>
| Die readings state, power und consumption aller [[PCA301 Funkschaltsteckdose mit Energieverbrauchsmessung|PCA301]] Devices mit einer Zeile pro Device.
|-
| <code>attr Verbrauch mapping %ROOM %ALIAS</code>
| Der Raumname und der Alias werden als Zeilentitel verwendet
|-
| <code>attr Verbrauch nameStyle style="font-weight:bold"</code>
| Der Zeilentitel soll fett sein
|-
| <code>attr Verbrauch style style="font-size:20px"</code>
| Alles in einem größeren Font
|-
| <code>attr Verbrauch valueFormat {power => "%.1f W", consumption => "%.2f kWh"}</code>
| Die Formatierung für die power und consumption readings: eine Nachkommastelle plus Einheit.
|-
|<code>attr Verbrauch valueIcon { state => '%devStateIcon' }</code>
| Für die Dosen, die schaltbar sind, soll das anklickbare device icon gezeigt werden.
|-
|<code>attr Verbrauch valueStyle {($READING eq "power" && $VALUE > 40)?'style="color:red"':'style="color:green"'}</code>
|Wenn das power reading >40 ist, soll es in rot angezeigt werden, alle anderen Werte und readings in grün
|}

=== Wertabhängige Farbgebung ===
{| class="wikitable"
! Definition !! Erläuterungen
|-
| colspan=2 | [[Datei:TemperaturenRG.png|600px|mini|links|Wertabhängige Farben]]
[[Datei:TemperaturenRG2.png|600px|mini|links|Andere Werte - andere Farben]]
|-
| style="width:40%" |<code>define wzTemperaturenRG readingsGroup Aussen:,<Temperatur>,temperature,<Luftfeuchte>,humidity Wohnzimmer:,<Temperatur>,temperature,<Luftfeuchte>,humidity Kasten_E_Geraete:,<Temperatur>,temperature,<Luftfeuchte>,humidity</code>
| Die readings temperatur und humidity der Devices Aussen, Wohnzimmer und Kasten_E_Geraete in einer Zeile pro Device.
|-
| <code>attr wzTemperaturenRG group 3. Temperaturen</code>
| Die readingsGroup kommt in eine Gruppe
|-
| <code>attr wzTemperaturenRG noheading 1</code>
| noheading
|-
| <code>attr wzTemperaturenRG nostate 1</code>
| nostate
|-
| <code>attr wzTemperaturenRG notime 1</code>
| notime
|-
| <code>attr wzTemperaturenRG valueFormat {temperature => "%.1f °C", humidity =>"%.1f %%" }</code>
| Die Formatierung für die temperatur und humidity readings: eine Nachkommastelle plus Einheit.
|-
|<code>attr wzTemperaturenRG valueStyle { if($DEVICE eq "Aussen" && $READING eq "temperature" && $VALUE > 30) { 'style="color:red"'}elsif($DEVICE eq "Aussen" && $READING eq "temperature" && $VALUE > 20) { 'style="color:orange"'}elsif($DEVICE eq "Aussen" && $READING eq "temperature" && $VALUE < 5) { 'style="color:blue"'}elsif($DEVICE eq "Wohnzimmer" && $READING eq "temperature" && $VALUE > 23) { 'style="color:red"'}elsif($DEVICE eq "Wohnzimmer" && $READING eq "temperature" && $VALUE > 21) { 'style="color:orange"'}elsif($DEVICE eq "Wohnzimmer" && $READING eq "temperature" && $VALUE < 20) { 'style="color:blue"'}elsif($DEVICE eq "Kasten_E_Geraete" && $READING eq "temperature" && $VALUE > 30) { 'style="color:red"'}elsif($DEVICE eq "Kasten_E_Geraete" && $READING eq "temperature" && $VALUE > 28) { 'style="color:orange"'}elsif($READING eq "humidity" && $VALUE > 65) { 'style="color:red"'}elsif($READING eq "humidity" && $VALUE > 60) { 'style="color:orange"'}else{'style="color:green"'} }</code>
| Diverse Farbkombinationen sind möglich
|}

=== Enigma Receiver ===
{| class="wikitable"
! Definition !! Erläuterungen
|-
| colspan=2 | [[Datei:ReceiverRG.jpg|600px|mini|links|Wertabhängige Farben]]
[[Datei:ReceiverRGmute.jpg|600px|mini|links|Wertabhängige Farben]]
|-
| style="width:40%" |<code>define wzReceiverRG readingsGroup wzReceiver:,<Aktuell>,eventtitle,<Rest>,eventremaining_hr,<Dauer>,eventduration_hr wzReceiver:<Beschreibung>,eventdescription wzReceiver:,<Nächste>,eventtitle_next,<Start>,eventstart_next_hr,<Dauer>,eventduration_next_hr wzReceiver:,<HDD Kapazität>,hdd1_capacity,<Frei>,wzReceiver:hdd1_free wzReceiver:,<Lautstärke>,volume,<HDD>,hdd1_capacity,<Frei>,hdd1_free</code>
| Mehrere readings des Device wzReceiver in mehreren Zeilen. Wenn der Receiver auf mute ist, wird anstatt der Lautstärke, mute angezeigt. Farbige Anzeige des freien Speicherplatzes
'''Benötigt:''' ENIGMA2 Receiver, 70_ENIGMA2.pm - Siehe: [[Enigma2 Receiver (Dreambox, VUplus etc.) steuern]]
|-
| <code>attr wzReceiverRG group Fernseher Receiver</code>
| Die readingsGroup kommt in eine Gruppe
|-
| <code>attr wzReceiverRG mapping &nbsp;</code>
| mapping wird auf &nbsp; (Leerzeichen) gesetzt, damit der Device Name nicht angezeigt wird
|-
| <code>attr wzReceiverRG noheading 1</code>
| noheading
|-
| <code>attr wzReceiverRG nostate 1</code>
| nostate
|-
| <code>attr wzReceiverRG notime 1</code>
| notime
|-
|-
| <code>attr wzReceiverRG valueColumns { eventdescription => 'colspan="4"' }</code>
| Die Beschreibung soll über 4 Spalten gehen
|-
| <code>attr wzReceiverRG valueFormat { wzReceiverRGvalueFormat($DEVICE,$READING,$VALUE);; }</code>
| Die Formatierung wird in die 99_myUtils.pm ausgelagert. Siehe: [[99 myUtils anlegen]]
|-
|<code>attr wzReceiverRG valueStyle { if($READING eq "hdd1_free" && $VALUE < 200){ 'style="color:red"' }elsif( $READING eq "hdd1_free" && $VALUE < 500 ){ 'style="color:orange"' }elsif( $READING eq "volume" && ReadingsVal($DEVICE, "mute", "") eq "on" ){ 'style="color:red"' }else{ 'style="color:green"' } }</code>
| Diverse Farbkombinationen sind möglich. Wenn der Receiver auf mute ist, wird anstatt der Lautstärke mute angezeigt.
|-
| <code>
sub wzReceiverRGvalueFormat($$$)
{
my ($DEVICE,$READING,$VALUE) = @_;

if($READING eq 'hdd1_capacity') {
return "%.2f MB";
} elsif( $READING eq 'hdd1_free') {
return "%.2f MB";
} elsif( $READING eq 'volume' ) {
if( ReadingsVal($DEVICE, "mute", "") eq "on") {
return "mute";
} else {
return "%i %%";
}
}
}</code>
| Dieser Teil kommt in die [[99_myUtils_anlegen|99_myUtils.pm]]
|}

=== Heizungswerte inklusive Batterie- und Fensterstatus ===
{| class="wikitable"
! Definition !! Erläuterungen
|-
| colspan=2 | [[Datei:rgHeizung3.png|thumb|links|500px|Heizungswerte inklusive Batterie- und Fensterstatus]]
|-
| style="width:40%" |<code>define Heizungswerte readingsGroup <%sani_heating>,< >,<Act>,<Soll>,<Ist> TYPE=FHT:actuator,desired-temp,measured-temp,<%18>,<%20>,<%22>,window,battery</code>
| Diverse readings aller Devices des Typs FHT.
|-
| <code>attr Heizungswerte commands { 'Heizungswerte.18' => 'set $DEVICE desired-temp 18', 'Heizungswerte.20' => 'set $DEVICE desired-temp 20', 'Heizungswerte.22' => 'set $DEVICE desired-temp 22' }</code>
| Die Links/Kommandos die hinter den 18, 20 und 22 liegen sollen.
|-
| <code>attr Heizungswerte nameStyle style="color:yellow;font-weight:bold"</code>
| Die Überschriften sollen gelb sein.
|-
| <code>attr Heizungswerte valueIcon {'battery.ok' => 'batterie@lightgreen', 'battery.low' => 'batterie@red', 'window.closed' => 'fts_window_1w@lightgreen', 'window.open' => 'fts_window_1w_open@red'}</code>
| Für den Batteriestand und den Zustand der Fenster sollen jeweils Icons angezeigt werden.
|}

=== Heizungswerte inklusive Ventilposition ===
{| class="wikitable"
! Definition !! Erläuterungen
|-
| colspan=2 | [[Datei:Rg_Heizung_Valveposition.png|thumb|links|500px|Heizungswerte inklusive Statusinformationen (MAX!)]]
|-
| style="width:40%" |<code>define Heizungswerte readingsGroup <%sani_heating>,<Ventil>,<Soll>,<Ist>,<MaxV>,<GID>,<Mode>,<Batterie> TYPE=CUL_HM:ValvePosition,desired-temp,measured-temp,R-valveMaxPos,groupid,mode,battery</code>
| Diverse readings aller Devices des Typs MAX.
|-
| <code>attr Heizungswerte mapping %ROOM</code>
| Die Raumnamen werden angezeigt.
|-
| <code>attr Heizungswerte nameStyle style="color:yellow;font-weight:bold"</code>
| Die Überschriften sollen gelb (fett) sein.
|-
| <code>attr Heizungswerte room Heizung</code>
| Die "readingsgroup" wird dem Raum "Heizung" zugeordnet.
|-
| <code>attr Heizungswerte valueFormat {'temperature' => "%.0f °C", 'desiredTemperature' => "%.0f °C", 'valveposition' =>"%.0f %%", 'maxValveSetting' =>"%.0f %%" }</code>
| Es wird noch die Einheit °C hinter den Temperaturwerten angezeigt.
|-
| <code>attr Heizungswerte valueIcon {'battery.ok' => 'batterie@lightgreen', 'battery.low' => 'batterie@red'}</code>
| Für den Batteriezustand werden Icons anstatt Klartextwerte genommen!
|-
| <code>attr Heizungswerte valueStyle { if($READING eq "temperature" && $VALUE > 20){ 'style="color:green;;font-weight:bold"' }elsif( $READING eq "temperature" && $VALUE <= 20 ){ 'style="color:blue"' }elsif( $READING eq "temperature" && $VALUE > 23 ){ 'style="color:red"' }else{ 'style="color:gray"' } }</code>
| Die Temperaturwerte werden abhängig vom Wert farbig dargestellt.
|-
| <code>attr Heizungswerte valueIcon {'battery.ok' => 'batterie@lightgreen', 'battery.low' => 'batterie@red', 'window.closed' => 'fts_window_1w@lightgreen', 'window.open' => 'fts_window_1w_open@red'}</code>
| Für den Batteriestand und den Zustand der Fenster sollen jeweils Icons angezeigt werden.
|}

=== Heizungswerte, Status und Regelmöglichkeit ===
{| class="wikitable"
! Definition !! Erläuterungen
|-
| colspan=2 | [[Datei:rgHeizung2.png|thumb|500px|links|Anzeige + Regelmöglichkeit]]
|-
| style="width:40%" |<code>define Heizungswerte2 readingsGroup <%sani_heating>,< >,<Act>,<Soll>,<Ist> TYPE=FHT:actuator,desired-temp,measured-temp,<{myUtils_HeizungUpDown($DEVICE,"up")}@desired-temp>,desired-new,<{myUtils_HeizungUpDown($DEVICE,"down")}@desired-temp>,window,battery</code>
| Diverse readings aller Devices des Typs FHT.
|-
| <code>attr Heizungswerte2 nameStyle style="color:yellow;font-weight:bold"</code>
| Die Überschriften sollen gelb sein.
|-
| <code>attr Heizungswerte2 valueIcon {'battery.ok' => 'batterie@lightgreen', 'battery.low' => 'batterie@red', 'window.closed' => 'fts_window_1w@lightgreen', 'window.open' => 'fts_window_1w_open@red'}</code>
| Für den Batteriestand und den Zustand der Fenster sollen jeweils Icons angezeigt werden.
|-
| <code>attr Heizungswerte2 valueStyle {($VALUE eq "00")?'style="visibility:hidden"':''}</code>
| Nach dem Einstellen den Wert wieder ausblenden.
|-
| <pre>#Heizung regeln in readingsGroup
sub
myUtils_HeizungUpDown($$)
{
my($DEVICE,$CMD) = @_;

my $icon = $CMD;
my $VALUE = ReadingsVal($DEVICE,"desired-new","20" );
$VALUE = ReadingsVal($DEVICE,"desired-temp","20" )
if( !$VALUE || $VALUE == 0 );
my $link;

if( $CMD eq "up" ) {
$icon = "control_arrow_upward";
$VALUE += 1;

if( $VALUE <= 24 ) {
$icon .= "\@red";
$link = "setreading $DEVICE desired-new $VALUE";
}
} elsif( $CMD eq "down" ) {
$icon = "control_arrow_downward";
$VALUE -= 1;

if( $VALUE >= 18 ) {
$icon .= "\@blue";
$link = "setreading $DEVICE desired-new $VALUE";
}
}

my $notify = "notifyHeizungUpDown";
if( !defined($defs{$notify}) ) {
CommandDefine(undef,
"$notify notify .*:desired-new.* "
."{ myUtils_HeizungUpDownNotify(\$NAME,\$EVTPART1); }" );
}

my $ret = "%$icon";
$ret .= "%$link" if( $link );

return $ret;
}
sub
myUtils_HeizungUpDownNotify($$)
{
my($DEVICE,$VALUE) = @_;

return if( $VALUE == 0 );

my $at = "triggerHeizungUpDown_$DEVICE";
CommandDelete(undef, $at) if( defined($defs{$at}) );
CommandDefine(undef,
"$at at +00:00:03 "
."{my \$v = ReadingsVal(\"$DEVICE\",\"desired-new\",undef);"
."fhem(\"set $DEVICE desired-temp \$v\") if( \$v );"
."fhem(\"setreading $DEVICE desired-new 00\");}" );

return undef;
}</pre>
| Dieser Teil kommt in die [[99_myUtils_anlegen|99_myUtils.pm]]: Hiermit werden die Icons zum Ändern der gewünschten Temperatur dargestellt und im Bereich >=18 und <= 24 Grad anklickbar gemacht. Zwischen den Pfeilen wird der gerade eingestellte Wert angezeigt. Wenn dieser drei Sekunden nicht mehr geändert wurde wird die desired-temp auf diesen Wert gesetzt und die Anzeige zwischen den Pfeilen ausgeblendet.
|}

=== Heizungswerte, Status, Steuerung und Wochenprofil ===
Dieses Beispiel funktioniert nur mit HomeMatic HM-CC-RT-DN, für andere Thermostate müssen an diversen Stellen Änderungen vorgenommen werden.
{{Todo|Überarbeiten}}
{| class="wikitable"
! Definition !! Erläuterungen
|-
| colspan=2 | [[Datei:RgThermostate.png|thumb|750px|links|Status, Steuerung und Wochenprofil]]
|-
| style="width:40%" |<pre>set d_label Heizung Heizung
set d_label Temperatur Temperatur
set d_label Status Status
set d_label Wochenplan Wochenplan
set d_label Werktag Werktag
set d_label Samstag Samstag
set d_label Sonntag Sonntag
set d_label Zeitraum1 Zeitraum 1
set d_label Zeitraum2 Zeitraum 2 </pre>
|Erzeugen der Readings im Device [[dummy#d_label|d_label]].
|-
| <code>
define rg_thermostate readingsGroup <>,Heizung@d_label,<|>,Temperatur@d_label,<|>,Status@d_label,<|>,Wochenplan@d_label,<|>,Werktag@d_label,<|>,Samstag@d_label,<|>,Sonntag@d_label,<|>,<> CUL_HM_HM_CC_RT_DN_......_Clima:<>,?alias,<|>,<Soll>,desired-temp,<Tag>,dayTemp@{rg($DEVICE."§clima")},impossible@{$DEVICE},<|>,controlMode,R-globalBtnLock@{rg($DEVICE."§device")},<|>,Zeitraum1@d_label,<|>,workday_period_1_start@{rg($DEVICE."§clima")},workday_period_1_stop@{rg($DEVICE."§clima")},<|>,saturday_period_1_start@{rg($DEVICE."§clima")},saturday_period_1_stop@{rg($DEVICE."§clima")},<|>,sunday_period_1_start@{rg($DEVICE."§clima")},sunday_period_1_stop@{rg($DEVICE."§clima")},<|>,impossible@{$DEVICE},<%system_fhem_update>,<nowiki> </nowiki>,state@{rg($DEVICE."§device")},<%getConfig>,<|>,<Ist>,measured-temp,<Nacht>,nightTemp@{rg($DEVICE."§clima")},<|>,<Ventil>,ValvePosition,<|>,Zeitraum2@d_label,<|>,workday_period_2_start@{rg($DEVICE."§clima")},workday_period_2_stop@{rg($DEVICE."§clima")},<|>,saturday_period_2_start@{rg($DEVICE."§clima")},saturday_period_2_stop@{rg($DEVICE."§clima")},<|>,sunday_period_2_start@{rg($DEVICE."§clima")},sunday_period_2_stop@{rg($DEVICE."§clima")},<|>,impossible@{$DEVICE},impossible@{rg($DEVICE."§device")},<%burstXmit> </code>
| Diverse readings aller Devices CUL_HM_HM_CC_RT_DN_......_Clima, entsprechender [[Makefine#d_climaControl|d_climaControl]] (müssen vorher angelegt werden) und [[dummy#d_label|d_label]].
|-
| <code>attr rg_thermostate commands { 'desired-temp' => 'desired-temp:', 'dayTemp' => 'dayTemp:', 'controlMode' => 'trigger ntfy_rg $DEVICE controlMode', 'R-globalBtnLock' => 'trigger ntfy_rg $DEVICE globalBtnLock', 'workday_period_1_start' => 'workday_period_1_start:', 'workday_period_1_stop' => 'workday_period_1_stop:', 'saturday_period_1_start' => 'saturday_period_1_start:', 'saturday_period_1_stop' => 'saturday_period_1_stop:', 'sunday_period_1_start' => 'sunday_period_1_start:', 'sunday_period_1_stop' => 'sunday_period_1_stop:', 'rg_thermostate.system_fhem_update' => 'trigger ntfy_rg $DEVICE setTimeTable', 'rg_thermostate.getConfig' => 'set $DEVICE getConfig', 'nightTemp' => 'nightTemp:', 'workday_period_2_start' => 'workday_period_2_start:', 'workday_period_2_stop' => 'workday_period_2_stop:', 'saturday_period_2_start' => 'saturday_period_2_start:', 'saturday_period_2_stop' => 'saturday_period_2_stop:', 'sunday_period_2_start' => 'sunday_period_2_start:', 'sunday_period_2_stop' => 'sunday_period_2_stop:', 'rg_thermostate.burstXmit' => 'set $DEVICE burstXmit'}</code>
| Temperaturen werden als DropDown Auswahl dargestellt, Icons triggern [[readingsGroup#sub_rg|ntfy_rg]]
|-
| <code>attr rg_thermostate mapping { 'desired-temp' => '', 'dayTemp' => '', 'workday_period_1_start' => '', 'workday_period_1_stop' => '', 'saturday_period_1_start' => '', 'saturday_period_1_stop' => '', 'sunday_period_1_start' => '', 'sunday_period_1_stop' => '', 'nightTemp' => '', 'workday_period_2_start' => '', 'workday_period_2_stop' => '', 'saturday_period_2_start' => '', 'saturday_period_2_stop' => '', 'sunday_period_2_start' => '', 'sunday_period_2_stop' => ''}</code>
| Ausblenden der Texte vor den DropDowns.
|-
| <code>
attr rg_thermostate nameStyle{($READING eq "Soll" ||$READING eq "Tag" ||$READING eq "%getConfig" ||$READING eq "Ist" ||$READING eq "Nacht" ||$READING eq "Ventil" )?'style="text-align:right"' :($READING eq "%burstXmit" )?'style="text-align:center"' :'style=""'}
</code>
| Ausrichten der Überschriften die keine readings sind.
|-
| <code>attr rg_thermostate nonames 1</code>
| Ausblenden der Device Namen.
|-
| <code>attr rg_thermostate valueColumns { 'Heizung' => 'colspan="2"', 'Temperatur' => 'colspan="4"', 'Status' => 'colspan="2"', 'Werktag' => 'colspan="2"', 'Samstag' => 'colspan="2"', 'Sonntag' => 'colspan="2"', 'alias' => 'colspan="2"'}</code>
| Diverse Readings sollen über mehrere Spalten dargestellt werden.
|-
| <code>attr rg_thermostate valueFormat { 'measured-temp' => "%0.1f °C", 'ValvePosition' => "%0.1f %%"}</code>
| Formatierung für measured-temp und ValvePosition.
|-
| <code>attr rg_thermostate valueIcon { 'controlMode.auto' => 'sani_heating_automatic@green', 'controlMode.set_auto' => 'sani_heating_automatic@orange', 'controlMode.manual' => 'sani_heating_manual@red', 'controlMode.set_manual' => 'sani_heating_manual@orange', 'R-globalBtnLock.on' => 'secur_locked@green', 'R-globalBtnLock.on ' => 'secur_locked@green', 'R-globalBtnLock.set_on ' => 'secur_locked@orange', 'R-globalBtnLock.off' => 'secur_open@red', 'R-globalBtnLock.off ' => 'secur_open@red', 'R-globalBtnLock.set_off ' => 'secur_open@orange'}</code>
| Zuweisung der Icons.
|-
| <code>
attr rg_thermostate valueStyle{($READING eq "Heizung" ||$READING eq "Temperatur" ||$READING eq "Status" ||$READING eq "Wochenplan" ||$READING eq "Werktag" ||$READING eq "Samstag" ||$READING eq "Sonntag" )?'style="font-size:20px;;color:RoyalBlue;;text-align:center"' :($READING eq "alias" )?'style="font-size:11px;;font-weight:bold;;text-align:left"' :($READING eq "ValvePosition" &&$VALUE > 40 )?'style="font-weight:bold;;color:Orange;;text-align:left"' :($READING eq "desired-temp" ||$READING eq "measured-temp" )?'style="text-align:center"' :($READING eq "state" ||$READING eq "ValvePosition" )?'style="text-align:left"' :'style="text-align:right"'}
</code>
| Ausrichten und Einfärben der Readings.
|}

=== Heizungsteuerung für HM Wand- und Heizkörperthermostate ===

Dieses Beispiel wurde für HM-TC-IT-WM-W-EU / HM-CC-RT-DN Geräte erstellt. Verwendung anderer Thermostate wird ggf. Anpassungen erforderlich machen. Die Geräte werden nicht automatisch ermittelt, sondern sind einzeln angegeben.
Es werden Soll- und Ist-Temperaturen angezeigt, Luftfeuchte und Ventilpositionen, Modus, Batterie und Global-Tastenlock.
Steuerungsmöglichkeiten: Solltemperatur, Modus (Manual/Automatik), (globale) Tastenlock.
Die Abweichung der Isttemperatur, die Ventilpositionen, Batteriestand etc. werden farblich hervorgehoben.

Die Gerätenamen (EG_WZ_WT01_Climate / EG_WZ_WT01, EG_WZ_TT01_Clima / EG_WZ_TT01 / EG_WZ_TT02, OG_BZ_WT01_Climate / OG_BZ_WT01, OG_BZ_TT01_Clima / OG_BZ_TT01, OG_SZ_WT01_Climate / OG_SZ_WT01, OG_SZ_TT01_Clima / OG_SZ_TT01, OG_DZ_WT01_Climate / OG_DZ_WT01, OG_DZ_TT01_Clima / OG_DZ_TT01) müssen natürlich entsprechend angepasst werden.

{| class="wikitable"
! Definition !! Erläuterungen
|-
| colspan=2 | [[Datei:RgHMTh.jpg|thumb|500px|links|Status, Steuerung und Wochenprofil]]
|-
| <code>define heatingInfo readingsGroup <%sani_heating>,<Soll>,<Soll neu>,<Ist>,<Ventil / RH>,<Modus>,<Lock>,<Bat>\ 
EG_WZ_WT01_Climate:desired-temp,<sollsetz>,measured-temp,humidity,controlMode,R-globalBtnLock@EG_WZ_WT01,batteryLevel@EG_WZ_WT01 \ 
EG_WZ_TT01_Clima:desired-temp,<>,measured-temp,ValvePosition,controlMode,R-globalBtnLock@EG_WZ_TT01,batteryLevel@EG_WZ_TT01 \ 
EG_WZ_TT02_Clima:desired-temp,<>,measured-temp,ValvePosition,controlMode,R-globalBtnLock@EG_WZ_TT02,batteryLevel@EG_WZ_TT02 \ 
<>,<>,<>,<>,<>,<>,<>,<> \ 
OG_BZ_WT01_Climate:desired-temp,<sollsetz>,measured-temp,humidity,controlMode,R-globalBtnLock@OG_BZ_WT01,batteryLevel@OG_BZ_WT01 \ 
OG_BZ_TT01_Clima:desired-temp,<>,measured-temp,ValvePosition,controlMode,R-globalBtnLock@OG_BZ_TT01,batteryLevel@OG_BZ_TT01 \ 
<>,<>,<>,<>,<>,<>,<>,<> \ 
OG_SZ_WT01_Climate:desired-temp,<sollsetz>,measured-temp,humidity,controlMode,R-globalBtnLock@OG_SZ_WT01,batteryLevel@OG_SZ_WT01 \ 
OG_SZ_TT01_Clima:desired-temp,<>,measured-temp,ValvePosition,controlMode,R-globalBtnLock@OG_SZ_TT01,batteryLevel@OG_SZ_TT01 \ 
<>,<>,<>,<>,<>,<>,<>,<> \ 
OG_DZ_WT01_Climate:desired-temp,<sollsetz>,measured-temp,humidity,controlMode,R-globalBtnLock@OG_DZ_WT01,batteryLevel@OG_DZ_WT01 \ 
OG_DZ_TT01_Clima:desired-temp,<>,measured-temp,ValvePosition,controlMode,R-globalBtnLock@OG_DZ_TT01,batteryLevel@OG_DZ_TT01</code>
| ReadingsGoup anlegen.
|-
| <code>attr heatingInfo cellStyle { "r:1"=>'style="font-weight:bold;;font-size:16px"', 
"r:2,c:0"=>'style="font-weight:bold"',"r:6,c:0" =>'style="font-weight:bold"', 
"r:9,c:0"=>'style="font-weight:bold"',"r:12,c:0"=>'style="font-weight:bold"'}</code>
| Schrift fett setzen etc.
|-
| <code>attr heatingInfo commands { 
'heatingInfo.sollsetz'=>'desired-temp:5.0,12.0,18.0,19.0,20.0,20.5,21.0,21.5,22.0,22.5,23.0,23.5,24.0', 
"controlMode.manual"=>"set %DEVICE controlMode auto","controlMode.auto"=>"set %DEVICE controlMode manual", 
"R-globalBtnLock.on"=>"set %DEVICE regSet globalBtnLock off", 
"R-globalBtnLock.off"=>"set %DEVICE regSet globalBtnLock on"}</code>
| Heizungssteuerung ermöglichen
|-
| <code>
attr heatingInfo mapping {OG_BZ_WT01_Climate=>"Bad", 
OG_BZ_TT01_Clima=>"&nbsp;;&nbsp;;&nbsp;;Regler",OG_SZ_WT01_Climate=>"Schlafzimmer", 
OG_SZ_TT01_Clima=>"&nbsp;;&nbsp;;&nbsp;;Regler",OG_DZ_WT01_Climate=>"Duschbad", 
OG_DZ_TT01_Clima=>"&nbsp;;&nbsp;;&nbsp;;Regler",EG_WZ_WT01_Climate=>"Wohnzimmer", 
EG_WZ_TT01_Clima=>"&nbsp;;&nbsp;;&nbsp;;Regler1",EG_WZ_TT02_Clima=>"&nbsp;;&nbsp;;&nbsp;;Regler2",'desired-temp' => ''} 
</code>
| Gewünschte Namen definieren.
|-
| <code>
attr heatingInfo valueFormat {if($READING eq "ValvePosition" && $VALUE ne "0"){$VALUE = int($VALUE/10)*10} 
elsif($READING eq "batteryLevel"){if($VALUE>=3){$VALUE=100} 
elsif($VALUE>=2.7){$VALUE=75}elsif($VALUE>=2.5){$VALUE=50}elsif($VALUE>=2.2){$VALUE=25} 
else{$VALUE=0}}}
</code>
| Werte vorformatieren (für die Icon-Zuordnung).
|-
| <code>
attr heatingInfo valueIcon {'controlMode.manual' => 'sani_heating_manual@795CFF', 
'controlMode.auto' => 'sani_heating_automatic@FFC13A', 'controlMode.boost' => 'sani_heating_boost@FB0C02', 
'humidity'=>'humidity@6FD9FB', 'R-globalBtnLock.on'=>'secur_locked@F7301D', 
'R-globalBtnLock.off'=>'secur_open@0CFB0C','ValvePosition.0' => 'sani_heating_level_0@002AE0', 
'ValvePosition.10' => 'sani_heating_level_10@F8D53D','ValvePosition.20' => 'sani_heating_level_20@FF9341', 
'ValvePosition.30' => 'sani_heating_level_30@F17F3F','ValvePosition.40' => 'sani_heating_level_40@E46C3C', 
'ValvePosition.50' => 'sani_heating_level_50@DE3B3A','ValvePosition.60' => 'sani_heating_level_60@A30D2D', 
'ValvePosition.70' => 'sani_heating_level_70@B40A23','ValvePosition.80' => 'sani_heating_level_80@C40619', 
'ValvePosition.90' => 'sani_heating_level_90@D4030F','ValvePosition.100' => 'sani_heating_level_100@E50005', 
'batteryLevel.100'=>'measure_battery_100@0CFB0C','batteryLevel.75'=>'measure_battery_75@42BC0A', 
'batteryLevel.50'=>'measure_battery_50@F5FF10','batteryLevel.25'=>'measure_battery_25@FB5909', 
'batteryLevel.0'=>'measure_battery_0@E50005','controlMode.set_boost' => 'hourglass', 
'controlMode.set_auto' => 'hourglass','controlMode.set_manual' => 'hourglass', 
'R-globalBtnLock.set_on' => 'hourglass','R-globalBtnLock.set_off' => 'hourglass'}
</code>
| Icons zuordnen.
|-
| <code>
attr heatingInfo valueStyle {if($READING eq "measured-temp") 
{my $t=$VALUE;;my $d=ReadingsVal($DEVICE,'desired-temp',0);; 
if($t-$d>=1){'style="color:rgb(251,63,11);;"'}elsif($t-$d<=-1){'style="color:rgb(79,58,251);;"'} 
else{'style="color:rgb(12,251,12);;"'}}}
</code>
| Farben (zu kalt: blau, zu warm: rot, ok: grün).
|-
| <code>
attr heatingInfo valueSuffix {"desired-temp"=>" °C", "measured-temp"=>" °C", 
"ValvePosition"=>" (".ReadingsVal($DEVICE,$READING,0)." %)", 
"humidity"=>" ".ReadingsVal($DEVICE,$READING,0)." % RH", 
"batteryLevel"=>" (".ReadingsVal($DEVICE,$READING,0)." V)"}
</code>
| Messeinheiten und Zahlenwerte.
|}

=== Readings aus zusätzlichen Devices ===
Im folgenden Beispiel wird gezeigt wie sich Readings zusätzlicher Devices zu einer Zeile mit mehreren Readings hinzufügen lassen. Diese zusätzlichen Devices können z.b. die unterschiedlichen Channel eines HomeMatic Gerätes sein. Im folgenden Beispiel wird der Name des zugehörigen Geräts dynamisch bestimmt.
{| class="wikitable"
! Definition !! Erläuterungen
|-
| colspan=2 | [[Datei:rgHeizung4.png|thumb|750px|links|Anzeige + Regelmöglichkeit]]
|-
| style="width:40%" |<code>define myTemp readingsGroup <Raum>,<Tist>,<Tsoll>,<Mode>,<Tnight>,<Tday>,<Hum>,<BatTC>,<Vist>,<Vsoll>,<Verr>,<BatVD> Thermostat.(WZ|OZ|AZ|Bad|Kueche|SZ|GZ|Bad.OG):measured-temp,desired-temp,controlMode,night-temp,day-temp,humidity,battery,ValvePosition@{valveOfDevice($DEVICE)},ValveDesired@{valveOfDevice($DEVICE)},R-valveErrorPos@{valveOfDevice($DEVICE)},battery@{valveOfDevice($DEVICE)} Broetje:ToutIst </code>
| Diverse Readings aller Thermostat Devices und des jeweils zugehörigen Ventilantriebs.
|-
| <code>attr myTemp mapping { 'Broetje' => 'Garten','Thermostat.AZ' => 'EG Arbeitszimmer','Thermostat.SZ' => 'OG Schlafzimmer','Thermostat.WZ'=>'EG Wohnzimmer','Thermostat.Kueche' => 'EG Küche','Thermostat.GZ' => 'OG Gästezimmer','Thermostat.Bad' => 'EG Bad','Thermostat.Bad.OG' => 'OG Bad','Thermostat.OZ' => 'EG Kaminzimmer','desired-temp' => <nowiki>''</nowiki> }</code>
| Die Benennung der Zeilentitel (Das ist je nach Konfiguration auch über $ALIAS und/oder $ROOM lösbar).
|-
| <code>attr myTemp commands { 'desired-temp' => 'desired-temp:' }</code>
| desired-temp soll per dropDown einstellbar sein.
|-
| <code>attr myTemp nameStyle style="color:yellow"</code>
| Die Überschriften sollen gelb sein.
|-
| <code>attr myTemp valueIcon {'battery.ok' => 'batterie@lightgreen', 'battery.low' => 'batterie@red'}</code>
| Für den Batteriestand sollen jeweils Icons angezeigt werden.
|-
| <code>attr myTemp valueFormat { 'measured-temp' => "%0.1f &deg;C",'ToutIst' => "%.1f &deg;C",'night-temp' => "%.1f &deg;C",'day-temp' => "%.1f &deg;C",'humidity' => "%.0f
%%",'ValvePosition' => "%.0f %%",'ValveDesired' => "%.0f %%",'R-valveErrorPos' => "%.0f %%" }</code>
| Die Formatierung der Werte.
|-
| <code>
#namen des ventil device aus thermostat device ableiten
sub valveOfDevice ($) {
my ($DEVICE) = @_;

if ($DEVICE =~ m/AZ/) {
return "Ventil.".substr($DEVICE,11).".Nord";
} else {
return "Ventil.".substr($DEVICE,11);
}
}</code>
| Dieser Teil kommt in die [[99_myUtils_anlegen|99_myUtils.pm]]: Hier wird aus dem Namen des Thermostaten der Name des zugehörigen Ventilantriebs abgeleitet.
|}
Da im {...} Teil des <reading>@<device> Arguments keine Leerzeichen oder Kommas vorkommen dürfen ist er in der Regel das Einfachste die Funktionalität wie in diesem Beispiel in eine eigene Routine auszulagern. Mit ein paar 'Tricks' lässt es sich aber manchmal auch ohne Leerzeichen oder Kommas lösen und dann direkt in die Definition schreiben:<code>...,ValvePosition@{$DEVICE=~s/Thermostat/Ventil/;$DEVICE;},...</code>

=== Dynamische Inhalte ===
[[Datei:rgDynamic-1.png|mini|450px|readingsGroup mit umschaltbarem Inhalt 1]]
[[Datei:rgDynamic-2.png|mini|450px|readingsGroup mit umschaltbarem Inhalt 2]]
Es ist möglich, den in einer readingsGroup dargestellten Inhalt dynamisch von zusätzlichen Bedingungen abhängig zu machen. Im folgenden Beispiel lässt sich
einstellen, dass nur die Devices angezeigt werden, die einen bestimmten Zustand (hier: on/off, open/tilted/closed) haben. Hier wird zum Umschalten ein dummy, der direkt über der readingsGroup dargestellt wird, verwendet. Über das links und/oder commands lässt sich auch eine Darstellung erzeugen, bei der das Umschalten direkt innerhalb der readingsGroup möglich ist.

<pre>
define LXrg dummy
attr LXrg group -
attr LXrg setList mode1:on,off mode2:open,closed,tilted
attr LXrg stateFormat 1=mode1 2=mode2
attr LXrg webCmd mode1:mode2

define rg readingsGroup Window.*:state Light.*:state
attr rg group -
attr rg valueFormat { return $VALUE if ( $VALUE eq ReadingsVal("LXrg","mode1","") || $VALUE eq ReadingsVal("LXrg","mode2","") );; return undef;;}

define Watch_LX notify LX.*:.* {my $value = ReadingsVal($NAME,'state','');;;;fhem("setreading $NAME $value")}
</pre>

=== Enable/Disable Button am Beispiel eines WeekdayTimer ===
Dieses Beispiel zeigt die Anwendung einer readingsGroup, um im Frontend einen Enable/Disable Button für ein Objekt darzustellen. Für den [[WeekdayTimer]] gibt es hier spezielle Erweiterungen (set Routinen, um das Attribut ''disable'' zu setzen). Es gibt aber auch eine allgemeinere Variante (siehe [http://forum.fhem.de/index.php/topic,23655.msg169141.html#msg169141 diesen Forumsbeitrag]) für alle Objekte, die das Fhem Attribut ''disable'' unterstützen.
{| class="wikitable"
! Definition !! Erläuterungen
|-
| colspan=2 | [[Datei:rg_scheduling.png|thumb|500px|links|Enable/Disable Button]]
|-
| style="width:40%" |<code>define rg_Timer_Wasser readingsGroup timer_Wasser_..:disabled,+DEF,<{rg_timer_Wasser_show_conditional($DEVICE,"nextUpdate")}@disabled>,<{rg_timer_Wasser_show_conditional($DEVICE,"nextValue")}@disabled></code>
| Definition der angezeigten Readings. Das Attribut ''disabled'' wird mit weiteren Einstellungen (''commands'') zum Button, +DEF zeigt die Definition, d.h. die Schaltzeiten, des Timers an. Die Readings nextUpdate und nextValue sollen nur angezeigt werden, falls der Timer aktiv ist. Hierfür sorgt eine Routine <code>rg_timer_Wasser_show_conditional</code>, die in der 99_myUtils.pm definiert wird. Das abschließende @disabled sorgt dafür, dass der LongPoll Mechanismus die Anzeige sofort ändert, wenn der Button betätigt wird.
|-
| <code>attr rg_Timer_Wasser valueFormat { if ( $READING =~ m/.*DEF/ ) { my @text = split(" ", $VALUE); shift @text; return join(" ", @text) }}</code>
| Der Name des Timers wird aus dem Internal "+DEF" vorne abgeschnitten. Damit werden nur die definierten Schaltpunkte angezeigt.
|-
| <code>attr rg_Timer_Wasser valueIcon { 'disabled.0' => 'Restart', 'disabled.1' => 'Shutdown' }</code>
| Die beiden Zustände für den Button werden durch zwei Standard-Icons angezeigt.
|-
| <code>attr rg_Timer_Wasser commands { 'disabled.0' => 'set $DEVICE disable', 'disabled.1' => 'set $DEVICE enable' }</code>
| Toggle-Funktion für den Button. Wenn der Timer aktiv ("disabled.0") sorgt ein Klick auf den Button, dass der Timer deaktiviert wird ("set $DEVICE disable").
|-
|<pre> sub rg_timer_Wasser_show_conditional($$)
{
my ($DEVICE,$READING) = @_;
return ( ReadingsVal($DEVICE, "disabled", "1") eq "0" )?
ReadingsVal($DEVICE, $READING, "reading_undef") : "disabled";
}</pre>
| Dieser Teil kommt in die [[99_myUtils_anlegen|99_myUtils.pm]]: Hiermit wird das übergebene Reading des Timers nur angezeigt, wenn der Timer aktiv ist. Andernfalls wird der String "disabled" angezeigt.
|}

=== Ändern von Attributen: Noch ein WeekdayTimer Beispiel ===
{{Randnotiz|RNTyp=y|RNText=Dieses Beispiel benutzt Funktionen, die erst ab [[version|Modulversion]] 8761/16.6.2015 verfügbar sind.}}
Inzwischen ist es auch möglich das commands Mapping auf Attribute anzuwenden. Die Syntax ist die gleiche wie für die set Kommandos. Um das Beispiel übersichtlich zu halten werden hier die Werte und Icons auch für deaktiviert WeekdayTimer angezeigt.

{| class="wikitable"
! Definition !! Erläuterungen
|-
| colspan=2 | [[Datei:rg_timer.png|thumb|500px|links|FhemWidget für das 'disable' Attribut]]
|-
| style="width:40%" |<code>define rgTimer readingsGroup <>,<Current>,<Update-Time>,<New>,<disable> TYPE=WeekdayTimer:state,nextUpdate,nextValue,?!disable</code>
| Definition der angezeigten Readings. Das Attribut ''disable'' wird mit weiteren Einstellungen (''commands'') zum Button. Durch das ! wird das Attribut auch dann angezeigt wenn es noch nicht gesetzt ist.
|-
| <code>attr rgTimer valueIcon { state => '%devStateIcon', nextValue => '{(split(":",Color::devStateIcon($DEVICE,"dimmer",undef,"nextValue")))[1]}' }</code>
| Für den aktuellen Zustand wird das devStateIcon angezeigt und für den nächsten Zustand das passende Lampen-Icon.
|-
| <code>attr rgTimer_Wasser valueFormat '{(split(" ", $VALUE))[1]}'</code>
| Vom nächsten Schaltpunkt wird nur die Zeit angezeigt.
|-
| <code>attr rgTimer commands { disable => 'disable:' }</code>
| Für das disable attribut wird das normale dropDown mit 0 und 1 angezeigt das auch in der Device Detail Ansicht verwendet wird.
|}

== Berechnungen ==
{{Randnotiz|RNTyp=y|RNText=Dieses Beispiel benutzt Funktionen, die erst ab [[version|Modulversion]] 8761/16.6.2015 verfügbar sind.}}
Das Rechnen funktioniert über das Flag "$", mit dem eine Funktion angegeben werden kann, die auf beliebige Kombinationen von Zeilen, Spalten und einzelnen Zellen angewendet wird. Ähnlich wie in einer Tabellenkalkulation.

Ein Beispiel:
:<code>define rg readingsGroup .*:temperature rg:$avg</code>
Damit wird eine readingsGroup über alle ''temperature'' Readings definiert. In einer zusätzlichen Zeile am Ende wird mit ''$avg'' der Durchschnittswert aller darüber liegenden Temperaturen angezeigt.

Das genaue Format: <code>$<operator>[(<zellen>)]</code> mit
*<code><operator></code>: sum, avg, min, max, scalar, count oder der Name einer beliebigen anderen Funktion, die ein Array mit allen Werten übergeben bekommt und ein Ergebnis zurückliefert.
*<code><zellen></code> ist eine durch Semikolon getrennte Liste aus <code><zeilen>:<spalten></code> Paaren.
*<code><zeilen></code> und <code><spalten></code> sind jeweils eine Perl Liste, d.h. hier können
** einzelne Werte,
** durch Komma getrennte Aufzählungen,
** mit .. angegebene Wertebereiche
** sowie <code>$ROW</code> und <code>$COLUMN</code> als Bezeichner für die aktuelle Zelle
:verwendet werden.

Alle Möglichkeiten sind kombinierbar. Die Zählung der Zeilen und Spalten beginnt bei 1. Eine nicht vorhandene Zeilenangabe wird durch den Bereich von Zeile 1 bis zur aktuellen Zeile ersetzt, eine nicht vorhandene Spalte durch die aktuelle Spalte.

Es ergeben sich somit unter anderem folgende Möglichkeiten:
*<code>$sum</code> equivalent zu <code>$sum(1..$ROW), $sum(:$COLUMN)</code> und <code>$sum(1..$ROW:$COLUMN)</code> die Summe der Werte in der Spalte über der aktuellen Zelle.
*<code>$max($ROW:1..$COLUMN-1)</code> Maximum aller Werte links von der aktuellen Zelle (in der aktuellen Zeile)
*<code>$avg(1..$ROW:1)</code> Durchschnitt aller Werte in Spalte 1 bis zur aktuellen Zeile
*<code>$scalar(:1)</code> Anzahl der Werte in Spalte 1
*<code>$min(1..5:1,2,4)</code> Minimum der Werte aus den Zeilen 1-5 in den Spalten 1, 2 und 4

Eigene Funktionen lassen sich über 99_myUtils anlegen und z.B. verwenden um Häufigkeiten zu zählen oder mit nichtnumerischen Readings umzugehen.

Die Ergebnisse werden im Weiteren wie normale Readings behandelt. Sie lassen sich von links oben nach rechts unten kaskadieren und lassen sich über valuePrefix, valueSuffix, valueFormat und valueStyle in der Darstellung beeinflussen. Also z.B. einfärben, als Balkendiagramm darstellen, ...

Mit Hilfe der Funktionalität zum auf- und zu-klappen von Teilen einer readingsGroup lassen sich z.B. im zusammengeklappten Zustand Summen, Extremwerte oder andere Ausreißer anzeigen und die Details nur beim Aufklappen zeigen.

Weitere Möglichkeiten:
* Attribut <code>firstCalcRow</code>: Hiermit kann der Default für die Nummer der ersten Zeile vorgegeben werden (sofern im Ausdruck nichts genaueres angegeben ist). firstCalcRow sollte z.B. auf 2 gesetzt werden, wenn in der readingsGroup Spaltenüberschriften verwendet werden.
* special <code><nowiki><hr></nowiki></code> um eine horizontale Linie über die volle Breite einzufügen
* Über ein angehängtes <code>@<alias></code> kann einem Rechenergebniss ein Alias-Name gegeben werden. Über diesen kann der Wert dann zur Formatierung mit den value-Attributen angesprochen werden.
* das <code>alwaysTrigger</code> Attribut kann jetzt auch den Wert 2 bekommen. Damit werden in der readingsGroup Readings für alle durch die Aggregation gebildeten Werte und entsprechende Events auch dann erzeugt wenn die readingsGroup nicht angezeigt wird. Wenn ein Alias-Name vergeben ist, wird dieser auch für den Reading-Namen verwendet.
* Über den operator <code>$count(<wert>)(<zellen>)</code> um das Vorkommen von <code><wert></code> in den angegebenen Zellen zu zählen. <code><wert></code> kann enweder direkt der zu zählende Wert sein (ohne Anführungzeichen) oder eine in / eingeschlossene regex. Mit <code>!<wert></code> kann das Nicht-Vorkommen von <code><wert></code> gezählt werden.

=== Ein interaktives Beispiel ===
[[Datei:rgCalc.png|mini|right|400px|Beispiel-readingsGroup mit Berechnungen]]
In drei [[dummy]] Objekten lässt sich jeweils ein Reading über einen Slider einstellen. In der darunter liegenden readingsGroup werden diese Readings und diverse daraus abgeleitete Werte dargestellt. Alle Readings und die daraus abgeleiteten Werte werden live per longpoll aktualisiert, wenn die slider bewegt werden.
 
<pre>
define t1 dummy
attr t1 room rg
attr t1 setList state:slider,-10,1,30
attr t1 webCmd state
define t2 dummy
attr t2 room rg
attr t2 setList state:slider,-10,1,30
attr t2 webCmd state
define t3 dummy
attr t3 room rg
attr t3 setList state:slider,-10,1,30
attr t3 webCmd state

define rg readingsGroup <>,<value>,<sum>,<min>,<max>,<avg>\
t\d:+NAME,state,$sum(1..$ROW:2),$min(1..$ROW:2),$max(1..$ROW:2),$avg(1..$ROW:2)\
<hr>\
rg:<>,$scalar,$sum(:2)@SUM,$min(:2)@MIN,$max(:2)@MAX,$avg(:2)@AVG\
<hr>\
t1:<t1,t2,t3>,state,state@t2,state@t3,$sum($ROW:2..4)@SUM,$count(/\d/)(2..$ROW-4:2)\

attr rg nonames 1
attr rg room rg
attr rg style style='text-align:center'
attr rg valueFormat { 'avg' => '%.2f', 'AVG' => '%.2f' }
attr rg valuePrefix { 'rg.scalar' => '#', 'rg.SUM' =>'Σ; ', 'rg.MIN' =>'Min: ', 'rg.MAX' =>'Max: ', 'rg.AVG' =>'∅; ', 'rg.count' => '#(X): ' }
attr rg valueSuffix { state => '°;C' }
</pre>

== Links und Trigger ==
=== readingsGroup mit Link ===
[[Datei:rgPCA-detail.png|mini|400px|readingsGroup mit Link]]
Das PCA301 Beispiel oben lässt sich mit einem ans Ende des define angehängten
:<code><{appendTrigger($DEVICE,"clear","Alle löschen")}></code>
und der folgenden appendTrigger Definition in 99_myUtils.pm um einen Link erweitern, der ein Event auslöst, an das z.B. ein notify gehängt werden kann, um die Verbrauchszähler der PCA301 Dosen zurückzusetzen.
:<code>define clearVerbrauch notify Verbrauch:clear set TYPE=PCA301 clear</code>

<pre>use vars qw($FW_ME);
use vars qw($FW_subdir);
sub
appendTrigger($$$)
{
my ($name,$trigger,$label) = @_;

my $ret .= "</table></td></tr>";

my $link = "cmd=trigger $name $trigger";
my $txt = "<a onClick=\"FW_cmd('$FW_ME$FW_subdir?XHR=1&$link')\">$label</a>";
$ret .= "<td colspan=\"99\"><div style=\"cursor:pointer;color:#888888;text-align:right\">$txt</div></td>";

return ($ret,0);
}</pre>

wenn hierdurch Änderungen an einer readingsGroup erfolgen, die ein Neuladen der Seite erforderlich machen, kann dies so erfolgen:
:<code>{myUtils_refresh("WEB")}</code>
mit folgendem code in 99_myUtils.pm:
<pre>sub
myUtils_refresh($)
{
my ($name) = @_;

FW_directNotify("#FHEMWEB:$name", "location.reload(true);","" );
}</pre>

Ein weiteres Beispiel für 'custom links und trigger' findet sich in {{Link2Forum|Topic=14425|Message=109383|LinkText=diesem Forenbeitrag}}: dort wird damit eine readingsGroup dynamisch umgeschaltet, um nur die eingeschalteten, nur die ausgeschalteten oder alle Lampen anzuzeigen.

=== sub rg ===
Damit beim klicken auf ein Icon oder einen Text in einer readingsGroup etwas passiert ist es möglich dies über das commands Attribut auf ein <code>'trigger ntfy_rg $DEVICE $READING'</code> oder Ähnliches zu mappen.
Anlegen des ntfy_rg notify
<pre>
define ntfy_rg notify ntfy_rg {rg($EVENT)}
</pre>
Folgender Code muss noch in de [[99_myUtils_anlegen|99_myUtils.pm]]
<pre>
sub rg($){
my @input = split(/[§\s]+/,shift);
my $device = $input[0];
my $function = $input[1];

if($function eq "clima"){
my $room = AttrVal($device, 'room', 'undef');
$room =~ s/\D//g;

return(("d_climaControl_".$room));
}
elsif($function eq "device"){
return InternalVal($device,"device","device error");
}
elsif($function eq "controlMode"){
my $controlMode = ReadingsVal($device,"controlMode","controlMode error");

if($controlMode ~~ /manual/)
{fhem("set $device controlMode auto")}
elsif($controlMode ~~ /auto/)
{fhem("set $device controlMode manual")};
}
elsif($function eq "globalBtnLock"){
my $globalBtnLock = ReadingsVal($device,"R-globalBtnLock","globalBtnLock error");

if($globalBtnLock ~~ /off/){
{fhem("set $device regSet globalBtnLock on")}
{fhem ("set $device getConfig")}
}
elsif($globalBtnLock ~~ /on/){
{fhem("set $device regSet globalBtnLock off")}
{fhem ("set $device getConfig")}
};
}
elsif($function eq "state"){
my $state = Value($device);

if($state ~~ /off/){
{fhem("set $device on")}
}
elsif($state ~~ /on/){
{fhem("set $device off")}
};
}
elsif($function eq "setTimeTable"){
my $room = AttrVal($device, 'room', 'undef');
$room =~ s/\D//g;
my $climaControl = ("d_climaControl_".$room);
my $dayTemp = ReadingsVal( $climaControl, "dayTemp" , 21.0 );
my $nightTemp = ReadingsVal( $climaControl, "nightTemp" , 17.0 );
my $workday_period_1_start = ReadingsVal( $climaControl, "workday_period_1_start" , "06:30" );
my $workday_period_1_stop = ReadingsVal( $climaControl, "workday_period_1_stop" , "18:00" );
my $workday_period_2_start = ReadingsVal( $climaControl, "workday_period_2_start" , "24:00" );
my $workday_period_2_stop = ReadingsVal( $climaControl, "workday_period_2_stop" , "24:00" );
my $saturday_period_1_start = ReadingsVal( $climaControl, "saturday_period_1_start" , "06:30" );
my $saturday_period_1_stop = ReadingsVal( $climaControl, "saturday_period_1_stop" , "12:00" );
my $saturday_period_2_start = ReadingsVal( $climaControl, "saturday_period_2_start" , "24:00" );
my $saturday_period_2_stop = ReadingsVal( $climaControl, "saturday_period_2_stop" , "24:00" );
my $sunday_period_1_start = ReadingsVal( $climaControl, "sunday_period_1_start" , "24:00" );
my $sunday_period_1_stop = ReadingsVal( $climaControl, "sunday_period_1_stop" , "24:00" );
my $sunday_period_2_start = ReadingsVal( $climaControl, "sunday_period_2_start" , "24:00" );
my $sunday_period_2_stop = ReadingsVal( $climaControl, "sunday_period_2_stop" , "24:00" );

{fhem("set $device tempListMon prep $workday_period_1_start $nightTemp $workday_period_1_stop $dayTemp $workday_period_2_start $nightTemp $workday_period_2_stop $dayTemp 24:00 $nightTemp")};
{fhem("set $device tempListTue prep $workday_period_1_start $nightTemp $workday_period_1_stop $dayTemp $workday_period_2_start $nightTemp $workday_period_2_stop $dayTemp 24:00 $nightTemp")};
{fhem("set $device tempListWed prep $workday_period_1_start $nightTemp $workday_period_1_stop $dayTemp $workday_period_2_start $nightTemp $workday_period_2_stop $dayTemp 24:00 $nightTemp")};
{fhem("set $device tempListThu prep $workday_period_1_start $nightTemp $workday_period_1_stop $dayTemp $workday_period_2_start $nightTemp $workday_period_2_stop $dayTemp 24:00 $nightTemp")};
{fhem("set $device tempListFri prep $workday_period_1_start $nightTemp $workday_period_1_stop $dayTemp $workday_period_2_start $nightTemp $workday_period_2_stop $dayTemp 24:00 $nightTemp")};
{fhem("set $device tempListSat prep $saturday_period_1_start $nightTemp $saturday_period_1_stop $dayTemp $saturday_period_2_start $nightTemp $saturday_period_2_stop $dayTemp 24:00 $nightTemp")};
{fhem("set $device tempListSun exec $sunday_period_1_start $nightTemp $sunday_period_1_stop $dayTemp $sunday_period_2_start $nightTemp $sunday_period_2_stop $dayTemp 24:00 $nightTemp")};
}
}
</pre>
Hier sind die benötigten CodeBlöcke für [[ReadingsGroup#Heizungswerte.2C_Status.2C_Steuerung_und_Wochenprofil|Heizungswerte, Status, Steuerung und Wochenprofil]] enthalten, aber auch um state zu triggern.

== Sonstiges ==
In der Regel werden die Parameter zu einem reading in den mappings unter <$DEVICE> und dann <$DEVICE>.<$READING> und dann unter <$READING>.<$VALUE> gesucht.

=== Lesbar machen ===
Für die meisten Attribute gilt:

* Wenn es komplexer wird ist es einfacher, den Code in eine eigene Routine in (beispielsweise) [[99 myUtils anlegen|99_myUtils]] auszulagern und diese aufzurufen:
:<code> attr <name> valueStyle {myValueToFormat($READING,$VALUE)}</code>
* code für unterschiedliche readings kann auch im mapping schon aufgeteilt werden:
:<code>attr <name> valueStyle { SuperE5 => '{perl code}', Diesel => '{perl code}' }</code>
* Ifs lassen sich verschachteln und sortieren. So kann die Anzahl der Klammern und Else-Zweige reduziert werden:
if( $READING eq ... ) {
return xxx if( $VALUE < 1 );
return yyy if( $VALUE < 1.5 );
return zzz;
} elsif( $READING eq ... ) {
...
}

Da alles lässt sich natürlich auch kombinieren und so viel lesbarer machen als ein einziger langer Bandwurm.

=== readingsGroup in einer Gruppe ===
Wenn der doppelte Rahmen um eine readingsGroup bei Darstellung in einer Gruppe stört, lässt er sich mit dem passenden style entfernen:
:<code>attr <rgName> style style="border:0px;background:none;box-shadow:none"</code>
Für die readingsGroup ''rgName'' wird der Darstellungsstil verändert.

=== Einfache Balkendiagramme ===
[[Datei:rgBars.png|mini|400px|readingsGroup mit Balken]]
Readings lassen sich mit einem valueStyle der folgenden Art mit einem "Füllstandsbalken" hinterlegen:
:<code>attr <rgName> valueStyle style="width:200px; text-align:center; border: 1px solid #ccc; background:-webkit-linear-gradient(left, red $VALUE%, rgba(0,0,0,0) $VALUE%)"</code>
Hier ist die gewünschte Breite der Spalte und je nach Wertebereich der Readings auch die Umrechnung des jeweiligen Readingwertes in prozentuale Werte anzupassen.

Die verwendeten Farben lassen sich natürlich auch anpassen, z.B. auch unter Verwendung der [[Color#Skalenfarbe_mit_Color::pahColor|Color::pahColor]] Routine.

Die Balken werden bei Änderungen der Readings automatisch per longpoll aktualisiert.

Je nach verwendetem Browser ist ''-webkit-linear-gradient'' durch ''-moz-linear-gradient'', ''-ms-linear-gradient'' oder ''linear-gradient'' zu ersetzen.

Die obige valueStyle Definition ist nur beispielhaft zu sehen und sollte mit den [[ReadingsGroup#Lesbar_machen|hier beschriebenen Methoden]] lesbarer gemacht werden.

Weitere Möglichkeiten zur Erzeugung von Balkendiagrammen sind in Forenbeiträgen {{Link2Forum|Topic=25313|LinkText=hier}} und {{Link2Forum|Topic=28318|LinkText=hier}} beschrieben.

=== readingsGroup Styling mit CSS ===
Jede readingsGroup lässt sich durch CSS individuell stylen.

==== Allgemeines ====
Damit der eigene CSS Code nach einem [[Update]] der FHEM-Style Dateien vorhanden bleibt, ist es notwenig eine eigene .css Datei (zB ios7ReadingsGroups.css) zu erstellen und ins Verzeichnis ''fhem/www/pgm2/'' zu kopieren. Anschließend muss in der [[FHEMWEB]] Instanz das Attribut ''CssFiles'' auf zB ''pgm2/ios7ReadingsGroups.css'' gesetzt werden.

==== Erweiterte Device Übersicht ====
Diese ReadingsGroup ist an der [[FHEMWEB]] Device-Übersicht angelehnt. Zusätzlich werden weitere Readings, hier Leistung, Betriebszeit Heute und Jahr, ein Link zu Detail-Seite der ReadingsGroup und Links zu den jeweiligen Device-Detail-Seite, dargestellt.

{| class="wikitable"
| [[Datei:RgStylingOhneCss.png|600px|mini|left|Device ReadingsGroup ohne CSS]] [[Datei:RgStylingMitCss.png|600px|mini|left|Device ReadingsGroup mit CSS]]
|}

===== Definition =====
<pre>
define rg_devices readingsGroup <{rgLink($DEVICE,"konfigurieren","Details")}>,<Device>,<Status>,<Leistung>,<Heute>,<Jahr>\
wzDeckenfluter:<%light_floor_lamp>,<{rgLink("wzDeckenfluter","detail","Deckenfluter")}>,state,<>,dauerHeute,dauerJahr\
wzMacMini:<%it_nas>,<{rgLink("wzMacMini","detail","MacMini")}>,state,power,consumption,consumptionYear\
attr rg_devices noheading 1
attr rg_devices nonames 1
attr rg_devices notime 1
attr rg_devices room ReadingsGroup Styling
attr rg_devices style class="block wide rgDevices"
attr rg_devices valueFormat { 'power' => "%.1f W ", consumption => "%.2f kWh", 'consumptionYear' => "%.2f kWh" }
attr rg_devices valueIcon { state => '%devStateIcon' }
</pre>

Damit sich der CSS auf die richtige readingsGroup bezieht, ist es nötigt
das Attribut ''style'' anzupassen.
{| class="wikitable"
! Definition !! Erläuterungen
|-
| style="width:40%" |<code>attr <rgName> style class="block wide rgDevices"</code>
| Die Klassen ''block'' und ''wide'' müssen eingetragen werden. Der Name der Nachfolgenden Klasse, hier ''rgDevices'', ist frei wählbar.
|}
===== Funktion rgLink() =====
Die Funktion rgLink($name,$action,$label) liefert einen Link mit dem Namen $label zurück. Der Code gehört in die [[99 myUtils anlegen|99_myUtils.pm]].
* $name - Name des Device das aufgerufen werden soll
* $action - Aktion die Ausgeführt werden soll.
**''konfigurieren'' erzeugt den kleinen ''Details'' Button links oben der einem zur Detail Seite der ReadingsGroup führt - nützlich wenn das ReadingsGroup-Attribut ''noheading'' gesetzt ist
** ''detail'' erzeugt einen Link zu Device-Detail Seite
* $label - Link-Name
<pre>
sub rgLink($$$){
my ($name,$action,$label) = @_;
my $link = "";
my $fhemLink = "";
my $txt = "";
my $ret = "";
my $divStyle = "";
my $aStyle = "";

# FHEM Variablen einbinden
use vars qw($FW_ME);
use vars qw($FW_subdir);
use vars qw($FW_ss);
use vars qw($FW_tp);

if( $action eq "konfigurieren" ){
$fhemLink = "detail=$name";
$divStyle = "cursor:pointer;font-size:11px;padding-bottom:2px;padding-left:3px;";
}
elsif( $action eq "detail" ){
$fhemLink = "detail=$name";
$divStyle = "cursor:pointer;display:inline;";
}

$link = '<a onclick="location.href=\'' . $FW_ME . $FW_subdir . '?' . $fhemLink . '\'" style="' . $aStyle . '">' . $label . '</a>';
$txt = '<div style="' . $divStyle . '">' . $link . '</div>';
$ret = "$txt";

return $ret;
}
</pre>

{{Randnotiz|RNText=Tipp
Verwende zum Bearbeiten der eigenen .css Dateien entweder den [http://fhem.de/commandref_DE.html#JavaScripts Codemirror Editor] oder einen eigenen Editor mit [http://de.wikipedia.org/wiki/Syntaxhervorhebung Syntax Highlighting] . Das hilft bei der Fehlersuche enorm. }}
===== Styling =====
Die eigene .css Datei erscheint in FHEM unter Edit-Files --> styles und kann direkt im FHEM-Editor oder mit eigenen Editor bearbeitet werden.

ios7ReadingsGroups.css:
<pre>
/* Readings Groups Devices */
table.rgDevices tr td{ text-align: center; }
table.rgDevices tr:first-child td:nth-child(2){ /* 1. Zeile 2. Spalte */ text-align: center; }
table.rgDevices tr td:first-child{ /* 1. Spalte */ width: 45px; text-align: center; }
table.rgDevices tr td:nth-child(2){ /* 2. Spalte */ width: 33%; text-align: left; }
table.rgDevices tr td:nth-child(3){ /* 3. Spalte */ width: 15%; }
table.rgDevices tr td:nth-child(4){ /* 4. Spalte */ width: 15%; }
table.rgDevices tr td:nth-child(5){ /* 5. Spalte */ width: 15%; }
</pre>

==== Auf Portrait / Landscape Modus des Smartphone unterscheiden ====
Dieses Beispiel ist an das obige Beispiel [[#Erweiterte_Device_.C3.9Cbersicht|Erweiterte Device Übersicht]] angelehnt.

{| class="wikitable"
| style="width:40%" |[[Datei:RgStylingSmallscreenPortrait.png|300px|mini|center|Device ReadingsGroup im Portrait Modus]]
|[[Datei:RgStylingSmallscreenLandscape.png|550px|mini|center|Device ReadingsGroup im Landscape Modus]]
|}

===== Allgemeines =====
Mit CSS ist man in der Lage auf die aktuelle Bildschirmlage zu reagieren. Alle Anweisungen die in diesen beiden Funktionen zwischen den beiden { } stehen, werden je nach Bildschirmlage aufgerufen
<pre>
/* Portrait Modus */
@media all and (orientation:portrait) { }

/* Landscape Modus */
@media all and (orientation:landscape) { }
</pre>

===== Styling =====
{{Randnotiz|RNText=Info
* ''width: xx%'' ändert die Breite der Spalte
* ''display: none'' blendet die Spalte aus}}
In der FHEMWEB_phone Instanz muss wie [[#Allgemeines|hier]] beschrieben eine neue eigene .css Datei eingetragen werden. In diesem Beispiel ios7smallscreenReadingsGroups.css

ios7smallscreenReadingsGroups.css
<pre>
/* landscape und portrait modus */
table.rgDevices tr td { /* Zuerst alles centern */ text-align: center; }
table.rgDevices tr:first-child td:nth-child(1){ /* 1. Zeile 1. Spalte */ text-align: center; }
table.rgDevices tr td:first-child { /* 1. Spalte */ width: 5%; }
table.rgDevices tr:first-child td:nth-child(2) { /* 1. Zeile 2. Spalte */ text-align: center; }
table.block table tr td table.rgDevices tr td { border-bottom: 1px solid #cbcbcb; }

/* Portrait Modus */
@media all and (orientation:portrait) {
table.rgDevices tr td:nth-child(2){ /* 2. Spalte */ width: 50%; text-align: left; }
table.rgDevices tr td:nth-child(3){ /* 3. Spalte */ width: auto; text-align: right; display: table-cell; }
table.rgDevices tr td:nth-child(4){ /* 4. Spalte */ width: 0; display: none; }
table.rgDevices tr td:nth-child(5){ /* 5. Spalte */ width: 0; display: none; }
table.rgDevices tr td:nth-child(6){ width: 0; display: none; }
table.rgDevices tr td div a svg{ margin-left: 90px; }
}

/* Landscape Modus */
@media all and (orientation:landscape) {
table.rgDevices tr td:nth-child(2){ /* 2. Spalte */ width: 35%; text-align: left; }
table.rgDevices tr td:nth-child(3){ /* 3. Spalte */ width: 15%; }
table.rgDevices tr td:nth-child(4){ /* 4. Spalte */ width: 15%; }
table.rgDevices tr td:nth-child(5){ /* 5. Spalte */ width: 15%; }
table.rgDevices tr td:nth-child(5){ /* 5. Spalte */ width: 15%; }
}
</pre>

==== Plots im Portrait Modus des Smartphones ausblenden ====
{| class="wikitable"
| style="width:40%" |[[Datei:RgStylingSmallscreenPortraitPlot.png|350px|mini|center|Device ReadingsGroup im Portrait Modus]]
|[[Datei:RgStylingSmallscreenLandscapePlot.PNG|550px|mini|center|Plot nur im Landscape]]
|}

Um die Plot und alle Steuerelemente im Portrait Modus auszublenden fügt man in seine eigene smallscreen.css wie [[#Allgemeines|hier beschrieben]] folgendes ein:
<pre>
@media all and (orientation:portrait) {
.SVGplot, .SVGlabel, .Zoom-in, .Zoom-out, .Prev { width: 0; display: none; }
}
</pre>

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

Buderus EMS

2015-10-25T13:11:46Z

Rspecht:

{{Baustelle}}
[[Buderus EMS]] ist das Bussystem zwischen den einzelnen Komponenten der Firma Buderus. In den meisten Fällen verbindet dieser Bus mindestens den Wandthermostat und die Heizung.

== Voraussetzungen ==
Man benötigt ein Inferfacemodul sowie eine Server-Software auf dem FHEM Server.

== Hardware ==
=== Variante 1: NetIO ===
Um den Bus im Netzwerk einzubinden benötigt man zusätzlich zu dem AVR Net-IO Board eine Adapterplatine. Diese Adapterplatine kann man recht einfach auf einer Lochrasterkarte aufbauen. Wie man das ganze Aufbaut ist im Link [http://ems-gateway.myds.me/dokuwiki/doku.php?id=wiki:ems:net_io EMS-Adapter/NetIO] sehr gut erklärt.

== Software ==
=== Variante 1: NetIO / EMSCollector ===
Wenn der oben beschriebene NetIO Hardware inkl. der zugehören Software läuft kann man sich um die Server-Software kümmern. Auch dieser Teil ist sehr gut in dem Link beschrieben. Abweichend hierzu kann man auf den MySQL Part verzichten da die Datenbank für FHEM nicht gebraucht wird. Maximal zum kompilieren des Collectors werden die Pakete benötigt, können danach jedoch wieder deinstalliert werden.

Nach erfolgreichem erstellen des Moduls kann es mit <code>chmod 700 collectord</code> ausführbar und mit <code>cp collectord /usr/bin/</code> ''installiert'' werden.

mit <code>collectord --db-path none -d all -C 7777 -D 7778 tcp:IP_NETIO:7950 -f</code> kann ein erster Test stattfinden.

Die Parameter bedeuten:
*<code>--db-path none</code> keine Datenbankanbindung
*<code>-d all</code> volle Debugstufe
*<code>-C 7777</code> Telnet Steuerport 7777
*<code>-C 7778</code> Telnet Steuerport 7778
*<code>tcp:IP_NETIO:7950</code> Schnittstelle zum Net-IO (IP Bitte anpassen)
*<code>-f</code> Vordergrund

Wenn nun eine Verbindung besteht und alle Tests durchlaufen sind kann man in <code>/etc/crontab</code> folgende Zeile am Ende einfügen <code>@reboot collectord_neu --db-path none -C 7777 -D 7778 tcp:192.168.0.248:7950</code> um den Dämon direkt beim Boot des FHEM-Servers zu starten.

== Konfiguration ==

tbd.

Benutzer:Rspecht

2015-10-25T13:10:40Z

Rspecht: Die Seite wurde neu angelegt: „== Kontakt zu FHEM == Im Oktober 2015 installiert und seither täglich am ''basteln''. Aktuell Realisiert: *FHEM auf BananaPi *MAX! intigriert *Buderus EMS in…“

== Kontakt zu FHEM ==
Im Oktober 2015 installiert und seither täglich am ''basteln''.

Aktuell Realisiert:
*FHEM auf BananaPi
*MAX! intigriert
*Buderus EMS intigriert

== zu Mir: ==
Elektroing. mit Hang zum selbst realisieren.
Sprich wenn ich ein Ziel sehe greife ich auch gerne zum Lötkolben und Programmieradapter um dieses zu ermöglichen.
Erfahrungen im Bereich:
* Atmel AVR Mikrocontroller
* Analogtechnik
* Funktechnik
* EMV Probleme

Buderus EMS

2015-10-25T13:05:35Z

Rspecht:

[[Buderus EMS]] ist das Bussystem zwischen den einzelnen Komponenten der Firma Buderus. In den meisten Fällen verbindet dieser Bus mindestens den Wandthermostat und die Heizung.

== Voraussetzungen ==
Man benötigt ein Inferfacemodul sowie eine Server-Software auf dem FHEM Server.

== Hardware ==
=== Variante 1: NetIO ===
Um den Bus im Netzwerk einzubinden benötigt man zusätzlich zu dem AVR Net-IO Board eine Adapterplatine. Diese Adapterplatine kann man recht einfach auf einer Lochrasterkarte aufbauen. Wie man das ganze Aufbaut ist im Link [http://ems-gateway.myds.me/dokuwiki/doku.php?id=wiki:ems:net_io EMS-Adapter/NetIO] sehr gut erklärt.

== Software ==
=== Variante 1: NetIO / EMSCollector ===
Wenn der oben beschriebene NetIO Hardware inkl. der zugehören Software läuft kann man sich um die Server-Software kümmern. Auch dieser Teil ist sehr gut in dem Link beschrieben. Abweichend hierzu kann man auf den MySQL Part verzichten da die Datenbank für FHEM nicht gebraucht wird. Maximal zum kompilieren des Collectors werden die Pakete benötigt, können danach jedoch wieder deinstalliert werden.

Nach erfolgreichem erstellen des Moduls kann es mit <code>chmod 700 collectord</code> ausführbar und mit <code>cp collectord /usr/bin/</code> ''installiert'' werden.

mit <code>collectord --db-path none -d all -C 7777 -D 7778 tcp:IP_NETIO:7950 -f</code> kann ein erster Test stattfinden.

Die Parameter bedeuten:
*<code>--db-path none</code> keine Datenbankanbindung
*<code>-d all</code> volle Debugstufe
*<code>-C 7777</code> Telnet Steuerport 7777
*<code>-C 7778</code> Telnet Steuerport 7778
*<code>tcp:IP_NETIO:7950</code> Schnittstelle zum Net-IO (IP Bitte anpassen)
*<code>-f</code> Vordergrund

Wenn nun eine Verbindung besteht und alle Tests durchlaufen sind kann man in <code>/etc/crontab</code> folgende Zeile am Ende einfügen <code>@reboot collectord_neu --db-path none -C 7777 -D 7778 tcp:192.168.0.248:7950</code> um den Dämon direkt beim Boot des FHEM-Servers zu starten.

== Konfiguration ==

tbd.

Dashboard

2015-10-25T12:59:39Z

Rspecht: /* Kleines Howto */

{{Todo|Weitere Überarbeitung und Anpassung an Modul-Version 3, siehe {{Link2Forum|Topic=16503|Message=309740|LinkText=Update-Hinweise}}) }}

{{Infobox Modul
|ModPurpose=Beliebiges Anordnen von Gruppen
|ModType=h
|ModForumArea=Frontends
|ModTechName=95_Dashboard.pm
|ModOwner=svenson08
}}

Das '''Dashboard''' ist ein [[:Kategorie:Hilfsmodul|Hilfsmodul]], das umfangreiche Gestaltungsmöglichkeiten für das [[PGM2]] Web-Frontend bietet. So z.B. die Anordnung von Gerätegruppen in mehreren Tabs und jeweils in mehreren Spalten mittels Drag'n Drop.

== Voraussetzungen ==
Keine speziellen Voraussetzungen erforderlich.

== Anwendung ==

=== Define ===
Die Syntax für die Definition eines Dashboards:
:<code>define <name> Dashboard</code>
Parameterbedeutung:
;name
:Eindeutiger Name des anzulegenden Dashboards.

=== Attribute ===
Das Dashboard unterstützt die folgenden Attribute:

;dashboard_activetab
:Bestimmt welches der Tabs beim Aufruf des Dashboards ausgewählt ist.
;dashboard_customcss
:Über dieses Attribut können CSS Definitionen eingegeben werden, um z.B. mit dem Wert ''body {background-image: none !important;}'' das Hintergrundbild im Dashboard zu deaktiviert werden.
;dashboard_tabcount (seit 05.07.2015 entfallen, siehe {{Link2Forum|Topic=16503|Message=309740|LinkText=Update-Hinweise}})
:Bestimmt die Anzahl der verfügbaren Tabs im Dashboard.
;dashboard_showtabs
:Bestimmt die Position der Tabs. Diese kann oben oder unten angezeigt oder komplett ausgeblendet werden. Letzteres führt dazu das dass Dashboard den Lockstate auf lock ändert.
;dashboard_showfullsize
:Zeigt das Dashboard ohne die Raumliste von FHEMWEB. Es wird dabei der gesamte linke Bereich (inkl. Raumliste und evtl. gesetzten Logo) und dem Header der Seite (inkl. Eingabezeile) ausgeblendet.
;dashboard_showtooglebuttons
:Wer die vergrößern/verkleinern nicht nutzen möchte kann dies mittels diesem Attribut deaktivieren.
;dashboard_width
:Bestimmt die Breite des Dashboards. Die Breite kann in Prozent (z.B. 80%) oder in Pixel (z.B. 1200) angegeben werden.
;dashboard_tab1groups (dashboard_tab2groups dashboard_tab3groups dashboard_tab4groups dashboard_tab5groups dashboard_tab6groups dashboard_tab7groups)
:Enthält die Auflistung der Gruppen, die im Dashboardtab angezeigt werden. Die Gruppen sind mit einem Komma zu trennen. Einer Gruppe kann ein Icons zugewiesen werden. Hierzu muss nach dem Gruppennamen '':<icon>@<farbe>'' eingefügt werden. z.B. <code>Light:Icon_Fisch@blue,AVIcon_Fisch@red,Single Lights:Icon_Fisch@yellow</code>
;dashboard_tab1name (dashboard_tab2name dashboard_tab3name dashboard_tab4name dashboard_tab5name dashboard_tab6name dashboard_tab7name)
:Bestimmt den Titel des Tabs.
;dashboard_tab1icon (dashboard_tab2icon dashboard_tab3icon dashboard_tab4icon dashboard_tab5icon dashboard_tab6icon dashboard_tab7icon)
:Anzuzeigendes Icon neben dem Titel des Tabs.
;dashboard_rowtopheight
:Festlegen der Höhe der oberen Reihe des Dashboards.
;dashboard_webfrontendfilter (seit 05.07.2015 entfallen, siehe {{Link2Forum|Topic=16503|Message=309740|LinkText=Update-Hinweise}})
:Dem Attribut ist der Name einer FHEMWEB Instanz zu hinterlegen(z.B. WEB), möchte man das Dashboard darauf beschränken. Es können mehrere Instanzen, durch Komma getrennt, angegeben werden.
;dashboard_rowbottomheight
:Festlegen der Höhe der unteren Reihe des Dashboards.
;dashboard_rowcenterheight
:Festlegen der Höhe der mittleren Reihe des Dashboards.
;dashboard_row
:Bestimmt welche Reihen im Dashboard angezeigt werden.
;dashboard_rowcentercolwidth
:Bestimmt die Breite der einzelnen Spalten der mittleren Dashboardreihe. Je Spalte kann ein separater Wert, durch Komma getrennt, hinterlegt werden. Jeder Wert bestimmt die Spaltenbreite in %.
;dashboard_colcount
:Legt die Anzahl der Spalten in der mittleren Reihe des Dashboards festgelegt.
;dashboard_tab1sorting (dashboard_tab2sorting dashboard_tab3sorting dashboard_tab4sorting dashboard_tab5sorting dashboard_tab6sorting dashboard_tab7sorting)
:Enthält die Positionierung der Gruppen im jeweiligen Tab. Es wird nicht empfohlen, dieses Attribut zu editieren.

== Anwendungsbeispiel(e) ==

== Allgemeine Hinweise ==

;Unterstützte Styles
Es werden die Styles Default, Dark und IOS7 unterstützt.

{| class="wikitable"
|Dashboard-Styles
|-
|[[Datei:dashboard_dark.png|thumb|500px|Dashboard im Style Dark]]
|-
|[[Datei:dashboard_default.png|thumb|500px|Dashboard im Default Style]]
|-
|[[Datei:dashboard_ios.png|thumb|500px|Dashboard im IOS7]]

|}

;Benötigte Dateien
Wenn vom Dashboard benötigte Dateien fehlen zeigt der STATUS des Dashboards den Hinweis ''Missing File, see LogFile for Details''. Weitere Einzelheiten zu diesem Fehler finden sich dann im Logfile. Es sollte klar sein, dass das Dashboard dann nicht (richtig) funktionieren kann.

== Erklärung / Internes ==
[[Datei:Dashboard_Menulink.png|mini|120px|Darstellung des Dashboard Menüs]]

Das Dashboard besteht in FHEM eigentlich aus zwei "Komponenten". Dem eigentlichen definierten Dashboard und einem Weblink. Es muss sich aber nicht um den Weblink für das Dashboard kümmern werden, da dieser bei Bedarf vom Dashboard eigenständig erstellt wird.

== Kleines Howto ==
;Schritt 1: Erstellen des Dashboards
:<code>define anyViews Dashboard</code>
FHEM neu starten.

;Schritt 2: Grundkonfiguration

:<code>attr anyViews dashboard_width 80%</code>
:<code>attr anyViews dashboard_tab1groups <GRUPPE1>,<GRUPPE2>,<GRUPPE3></code>

<GRUPPE1>, etc. sind durch richtige Gruppennamen zu ersetzen, z.B. Licht,Wetter oder ähnliches. Bitte denkt daran auch Komponenten den Gruppen zuzuweisen (über das jeweils zur Kompontente gehörende "groups"-Attribut) da ansonsten das Dasboard leer bleibt.

[[Datei:Dashboard-KeinGruppe.png|mini|250px|"Objekt" ohne Gruppe]]
[[Datei:Dashboard-Gruppe.png|mini|250px|"Objekt" in einer Gruppe]]

Danach sollen die beiden Gruppen im 1. Tab im Dashboard angezeigt werden. Zwar noch etwas chaotisch, aber das wird in den nächsten Schritten bearbeitet. 
[[#dashboard_tab1groups| Siehe dashboard_tab1groups]]

Das Dashboard zeigt neben den beiden Gruppen bereits einiges andere mit an. Hier werden erst einmal diese "Nebensächlichkeiten" erklärt. Für die weiteren Schritte dieser Anleitung sollten die nun genannten Einstellungen unverändert bleiben.

[[Datei:Dashboard_FirstGroup.png|mini|300px|Erste Gruppe im Dashboard]]
Am rechten Rand des Dashboards erscheinen einige Schalter ("Set", "Detail"). Der Schalter "Detail" springt in die Detailansicht des Dashboards um dort z.B. weiter Attribute hinzuzufügen. 
Der Schalter "Set" speichert die per Drag'n Drop vorgenommenen Änderungen '''temporär''' (diese sind dann noch nicht gespeichert!). "Set" wird in rot geschrieben wenn die Positionierung einer Gruppe geändert wurde, aber noch nicht mit dem "Set"-Schalter gesichert wurden! Ebenso wird mit dem Schalter "Set" das aktuell [[#dashboard_activetab|aktive Tab]] gesichert 
Die Schalterleiste kann über das Attribut ''dashboard_showtabs'' deaktiviert werden, oder wahlweise über oder unter dem Dashboard platziert werden. 
[[#dashboard_showtabs| Siehe dashboard_showtabs]]
 
Im Gruppentitel erscheint an deren rechten Rand ein Symbol (+/-). Mit diesem kann man die Gruppe minimieren oder die voreingestellte Größe wieder herstellen. 
[[#dashboard_showtooglebuttons| Siehe dashboard_showtooglebuttons]]
 
[[Datei:Dashboard_Helper.png|mini|300px|Dashboard Helper]]
Zum besseren Ausrichten der einzelnen Gruppen werden zur Unterstützung einige Hilfen angezeigt. Die Erste ist die Anzeige eines Rahmens um das Dashboard. Genauer gesagt um die einzelnen Reihen/Spalten des Dashboards. Eine weitere Hilfe ist der Hintergrund der Gruppen. Dieser kann über die Mindestgröße der Gruppe hinaus gezogen werden. Damit können beliebig große Abstände zwischen den einzelnen Gruppen eingestellt werden. 
[[#dashboard_showhelper| Siehe dashboard_showhelper]]

Da nun die ersten Gruppen im Dashboard angezeigt werden, geht es nun darum, diese an die gewünschten Stellen zu platzieren. Dazu werden erst noch die verschiedenen Reihen und Spalten eingerichtet. 

Das Dashboard verfügt über drei Reihen. Oben, Mitte und Unten. In der Standardeinstellung wird nur die mittlere Reihe angezeigt. Die mittlere Reihe sollte auch immer eingesetzt werden, da diese die Breite des Dashboard vorgibt. Für dieses kleine HowTo werden aber die obere und die mittlere Reihe eingeblendet, indem das Attribut '''dashboard_row''' auf '''top-center''' gestellt wird. Diese Einstellung gilt für das gesamte Dashboard und somit für alle verwendeten Tabs. Es ist nicht möglich, je Tab eine andere Einstellung zu wählen. 
[[#dashboard_row| Siehe dashboard_row]] 

Die Breite, die das Dashboard auf dem Bildschirm einnimmt, kann über das Attribut '''dashboard_width''' festgelegt werden. Standard ist die Breite von 100%. Es kann neben einem Prozentwert auch eine Breite in Pixel angegeben werden. 
[[#dashboard_width| Siehe dashboard_width]] 

Die Höhe der einzelnen Reihen kann über die Attribute dashboard_rowtopheight für die obere Reihe, dashboard_rowbottomheight für die untere Reihe und dashboard_rowcenterheight für die mittlere Reihe festgelegt werden. Damit können die Reihen nach den eigenen Bedürfnissen angepasst werden. Für dieses HowTo wird '''dashboard_rowtopheight''' auf '''300''' und '''dashboard_rowcenterheight''' auf '''400''' eingestellt. Diese Einstellung gilt für das gesamte Dashboard und somit für alle verwendeten Tabs. Es ist nicht möglich je Tab eine andere Einstellung zu wählen. 
[[#dashboard_rowtopheight| Siehe dashboard_rowtopheight]] 
[[#dashboard_rowbottomheight| Siehe dashboard_rowbottomheight]] 
[[#dashboard_rowcenterheight| Siehe dashboard_rowheight]] 

Die mittlere Reihe hat (historisch bedingt) eine Besonderheit. Diese kann in maximal 5 Spalten unterteilt werden. Für unser Beispiel setzten wird das Attribut '''dashboard_colcount''' auf '''2'''. Diese Einstellung gilt für das gesamte Dashboard und somit für alle verwendeten Tabs. Es ist nicht möglich je Tab eine andere Einstellung zu wählen. Weiter legen wir mit dem Attribut [[#dashboard_rowcentercolwidth|dashboard_rowcentercolwidth]] die Breite der ersten Spalte mit 30% und die der zweiten Spalte mit 70% fest in dem wir dem Attribut '''dashboard_rowcentercolwidth''' den Wert '''30,70''' zuteilen. 
[[#dashboard_colcount | Siehe dashboard_colcount ]] 

Sicherlich ist das positionieren einfach, und jeder wird das hin bekommen. Zwei, drei Worte möchte ich trotzdem darüber verlieren. 

:<ins>Verschieben</ins> 
:Gruppen können in andere Reihen oder Spalten des Dashboards verschoben werden. Dazu muss in die Gruppe angeklickt werden und die Maustaste gedrückt gehalten werden. Los lässt man diese wenn man an der richtige Stelle ist. Das war wohl schon jedem klar. 
:Ein möglicher Zielort wird mit einem abgerundeten Platzhalter markiert. Dieser verschiebt auch, falls notwendig, andere Gruppen. Manchen wundert es warum dieser Zielort manchmal recht spät angezeigt wird. Dies hängt von der Position des Mauszeigers ab. Aha?! Je weiter oben man eine Gruppe anpackt, desto höher muss man die Maus schieben. Oder anders formuliert, wenn sich ca. 50% der Gruppenfläche im Zielbereich befinden wird dieser Zielort erst markiert. Das verschieben eine Gruppe von einem Tab in das andere ist nicht möglich. Letztendlich bleibt jedem nur <ins>ausprobieren</ins>. 

:Gruppen können über, unter, neben und vor anderen Gruppen verschoben werden. Auch das erfolgt wie bereits oben aufgeführt. Dies ist für viele nicht neues. Zu beachten ist aber das sich eine Gruppe nur dann vor oder neben eine anderen positionieren lässt wenn diese von der Breite in das Dashboard passen. Wenn Ihr also Gruppen nebeneinander positionieren wollt dürfen diese in Summe nicht breiter als das Dashboard sein. 
:Dies gilt nicht für die Höhen der Gruppen. Diese können in Summe höher als das Dashboard und höher als eine Reihe sein. Hier findet keine Begrenzung statt wie bei der Breite. Um jedoch das ein oder andere optisch nicht so schöne Ergebnis zu bekommen sollte darauf geachtet werden das keine Gruppe über eine Reihe hinaus ragt. 

Für unser Beispiel verschieben wir zum Testen die Gruppen in beliebige Reihen bzw. Spalten der mittleren Reihe. Danach bitte den "Set" Schalter drücken, dieser hat sich durch die verschiebe Aktionen bereits rot markiert.

[[Datei:Dashboard_Positionieren.png|mini|200px|Ausrichtung von einzelnen Gruppen]]
Das Ausrichten ist gleichermaßen einfach wie das Positionieren und sollte auch nichts Neues sein. Aber auch hier möchte ich darüber zwei, drei Worte verlieren. 

:Das Positionieren ist nur möglich, wenn das Dashboard nicht gesperrt ist (Lock/Unlock). Dann wird ein abgeschrägte Ecke an der Gruppe angezeigt, mit der die Größe gezogen werden kann.
:Jede Gruppe kann in Höhe und Breite beliebig gezogen werden, wobei genau das wieder einen Hacken hat: Das Größerziehen ist nur bedingt möglich. Die Breite/Höhe ist auf die Breite/Höhe der Dashboard Reihe (oder Spalte) begrenzt. Damit kann man eine Gruppe nicht über den Rand des Dashboards hinaus vergrößern. 
:Das Kleinerziehen ist auch nur bis zu einer Mindestgröße möglich. Die Mindestgröße ist abhängig vom Inhalt der Gruppe, kann also von Gruppe zu Gruppe unterschiedlich sein. 
:Ein Sonderverhalten beim Vergrößern/Verkleinern gibt es auch: Ist ein Gruppe höher als die Reihe, lässt sich die Gruppe zwar dort positionieren. Beim Ausrichten springt dann der untere Rand nicht auf die Mindesthöhe der Gruppe, sondern auf die maximale Höhe der Reihe. In diesem Fall sollte die Höhe der Reihe geändert werden. Ähnliches kann auch in der Breite auftreten. 
:Ändert sich der Inhalt einer Gruppe (wird z.B. ein Dummy dazugepackt), ändert sich die Positionierung der Gruppe '''nicht''' automatisch. In diesem Fall ist man immer gezwungen auch die Größe der Gruppe im Dashboard an die neue Gegebenheit anzupassen.

Für unser Beispiel ziehen wir die Gruppen beliebig größer. Danach bitte den "Set"-Schalter drücken. Dieser hat sich durch die Verschiebeaktionen bereits rot markiert.

Wie bereits etwas weiter oben erklärt wird die Positionierung der Gruppen im Dashboard durch die Betätigung des Schalters "Set" temporär zwischengespeichert. Dadurch wird die Positionierung bereits für einen Seitenrefresh gespeichert. Solange bis das Browserfenster geschlossen wird. Danach wären diese Einstellungen verloren. 
Darum ist es notwendig die Positionierung permanent zu speichern, damit auch nach einem Neustart von Fhem die getroffenen Einstellungen und Positionierungen vorhanden sind. Dies geht über den in Fhem bekannten weg über ''Save config''. 
Wird der Schalter "Set" nicht betätigt, wird auch über ''Save config'' die Positionierung nicht gespeichert. Daher ist es wichtig, immer '''zuerst''' mit dem Schalter '''"Set"''' die Einstellung zwischenzuspeichern und '''danach mit ''Save config''''' den Zwischenspeicher permanent zu sichern. 

Durch den Schalter "Set" wird für jedes Tab die Einstellung in das für das jeweilige Tab zuständige Attribut geschrieben. Für Tab 1 ist das Attribut ''dashboard_tab1sorting'' zuständig, für Tab 2 das Attribut ''dashboard_tab2sorting'', usw. '''Diese Attribute sollten nicht editiert werden!'''

Es ist möglich jedem Tab einen eigenen individuellen Namen zu vergeben. Dazu ist für das jeweilige Tab das entsprechende Attribut zu befüllen. Z.B. für Tab 1 ist das Attribut ''dashboard_tab1name'' mit dem gewünschten Titel zu füllen. 
[[#dashboard_tab1name| Siehe dashboard_tab1name]]

== Letzte Änderungen / Dashboard-Historie ==

* (03.03.2014) Anzeigefehler bei readingGroups in einem Hiddenroom behoben
* (17.03.2014) Fehlerausgabe durch dashboard_webfrontendfilter behoben
* (26.03.2014) dashboard_showfullsize wird nicht im Raum "all" bzw. Everything angewendet
* (18.04.2014) Attribut dashboard_lock State entfernt. Kann nur noch in der Detailansicht verändert werden.
* (24.04.2014) Attribut dashboard_showhelper wird nicht mehr genutzt. Der Helper wird nur angezeigt wenn lockstate unlock ist.
* (24.04.2014) Schalter Detail und Set werden nun rechts angezeigt.
* (24.04.2014) Attribut dashboard_showtabs kann nicht mehr tabs-at-the-top-buttonbar-hidden oder tabs-on-the-bottom-buttonbar-hidden sein.
* (05.07.2015) {{Link2Forum|Topic=16503|Message=309740|LinkText=Änderungsübersicht und Update-Hinweise}}

== Links ==
* {{Link2Forum|Topic=16503}} über ''Dashboard''

[[Kategorie:FHEM Frontends]]
[[Kategorie:HOWTOS]]

Dashboard

2015-10-25T12:59:05Z

Rspecht: /* Kleines Howto */

{{Todo|Weitere Überarbeitung und Anpassung an Modul-Version 3, siehe {{Link2Forum|Topic=16503|Message=309740|LinkText=Update-Hinweise}}) }}

{{Infobox Modul
|ModPurpose=Beliebiges Anordnen von Gruppen
|ModType=h
|ModForumArea=Frontends
|ModTechName=95_Dashboard.pm
|ModOwner=svenson08
}}

Das '''Dashboard''' ist ein [[:Kategorie:Hilfsmodul|Hilfsmodul]], das umfangreiche Gestaltungsmöglichkeiten für das [[PGM2]] Web-Frontend bietet. So z.B. die Anordnung von Gerätegruppen in mehreren Tabs und jeweils in mehreren Spalten mittels Drag'n Drop.

== Voraussetzungen ==
Keine speziellen Voraussetzungen erforderlich.

== Anwendung ==

=== Define ===
Die Syntax für die Definition eines Dashboards:
:<code>define <name> Dashboard</code>
Parameterbedeutung:
;name
:Eindeutiger Name des anzulegenden Dashboards.

=== Attribute ===
Das Dashboard unterstützt die folgenden Attribute:

;dashboard_activetab
:Bestimmt welches der Tabs beim Aufruf des Dashboards ausgewählt ist.
;dashboard_customcss
:Über dieses Attribut können CSS Definitionen eingegeben werden, um z.B. mit dem Wert ''body {background-image: none !important;}'' das Hintergrundbild im Dashboard zu deaktiviert werden.
;dashboard_tabcount (seit 05.07.2015 entfallen, siehe {{Link2Forum|Topic=16503|Message=309740|LinkText=Update-Hinweise}})
:Bestimmt die Anzahl der verfügbaren Tabs im Dashboard.
;dashboard_showtabs
:Bestimmt die Position der Tabs. Diese kann oben oder unten angezeigt oder komplett ausgeblendet werden. Letzteres führt dazu das dass Dashboard den Lockstate auf lock ändert.
;dashboard_showfullsize
:Zeigt das Dashboard ohne die Raumliste von FHEMWEB. Es wird dabei der gesamte linke Bereich (inkl. Raumliste und evtl. gesetzten Logo) und dem Header der Seite (inkl. Eingabezeile) ausgeblendet.
;dashboard_showtooglebuttons
:Wer die vergrößern/verkleinern nicht nutzen möchte kann dies mittels diesem Attribut deaktivieren.
;dashboard_width
:Bestimmt die Breite des Dashboards. Die Breite kann in Prozent (z.B. 80%) oder in Pixel (z.B. 1200) angegeben werden.
;dashboard_tab1groups (dashboard_tab2groups dashboard_tab3groups dashboard_tab4groups dashboard_tab5groups dashboard_tab6groups dashboard_tab7groups)
:Enthält die Auflistung der Gruppen, die im Dashboardtab angezeigt werden. Die Gruppen sind mit einem Komma zu trennen. Einer Gruppe kann ein Icons zugewiesen werden. Hierzu muss nach dem Gruppennamen '':<icon>@<farbe>'' eingefügt werden. z.B. <code>Light:Icon_Fisch@blue,AVIcon_Fisch@red,Single Lights:Icon_Fisch@yellow</code>
;dashboard_tab1name (dashboard_tab2name dashboard_tab3name dashboard_tab4name dashboard_tab5name dashboard_tab6name dashboard_tab7name)
:Bestimmt den Titel des Tabs.
;dashboard_tab1icon (dashboard_tab2icon dashboard_tab3icon dashboard_tab4icon dashboard_tab5icon dashboard_tab6icon dashboard_tab7icon)
:Anzuzeigendes Icon neben dem Titel des Tabs.
;dashboard_rowtopheight
:Festlegen der Höhe der oberen Reihe des Dashboards.
;dashboard_webfrontendfilter (seit 05.07.2015 entfallen, siehe {{Link2Forum|Topic=16503|Message=309740|LinkText=Update-Hinweise}})
:Dem Attribut ist der Name einer FHEMWEB Instanz zu hinterlegen(z.B. WEB), möchte man das Dashboard darauf beschränken. Es können mehrere Instanzen, durch Komma getrennt, angegeben werden.
;dashboard_rowbottomheight
:Festlegen der Höhe der unteren Reihe des Dashboards.
;dashboard_rowcenterheight
:Festlegen der Höhe der mittleren Reihe des Dashboards.
;dashboard_row
:Bestimmt welche Reihen im Dashboard angezeigt werden.
;dashboard_rowcentercolwidth
:Bestimmt die Breite der einzelnen Spalten der mittleren Dashboardreihe. Je Spalte kann ein separater Wert, durch Komma getrennt, hinterlegt werden. Jeder Wert bestimmt die Spaltenbreite in %.
;dashboard_colcount
:Legt die Anzahl der Spalten in der mittleren Reihe des Dashboards festgelegt.
;dashboard_tab1sorting (dashboard_tab2sorting dashboard_tab3sorting dashboard_tab4sorting dashboard_tab5sorting dashboard_tab6sorting dashboard_tab7sorting)
:Enthält die Positionierung der Gruppen im jeweiligen Tab. Es wird nicht empfohlen, dieses Attribut zu editieren.

== Anwendungsbeispiel(e) ==

== Allgemeine Hinweise ==

;Unterstützte Styles
Es werden die Styles Default, Dark und IOS7 unterstützt.

{| class="wikitable"
|Dashboard-Styles
|-
|[[Datei:dashboard_dark.png|thumb|500px|Dashboard im Style Dark]]
|-
|[[Datei:dashboard_default.png|thumb|500px|Dashboard im Default Style]]
|-
|[[Datei:dashboard_ios.png|thumb|500px|Dashboard im IOS7]]

|}

;Benötigte Dateien
Wenn vom Dashboard benötigte Dateien fehlen zeigt der STATUS des Dashboards den Hinweis ''Missing File, see LogFile for Details''. Weitere Einzelheiten zu diesem Fehler finden sich dann im Logfile. Es sollte klar sein, dass das Dashboard dann nicht (richtig) funktionieren kann.

== Erklärung / Internes ==
[[Datei:Dashboard_Menulink.png|mini|120px|Darstellung des Dashboard Menüs]]

Das Dashboard besteht in FHEM eigentlich aus zwei "Komponenten". Dem eigentlichen definierten Dashboard und einem Weblink. Es muss sich aber nicht um den Weblink für das Dashboard kümmern werden, da dieser bei Bedarf vom Dashboard eigenständig erstellt wird.

== Kleines Howto ==
;Schritt 1: Erstellen des Dashboards
:<code>define anyViews Dashboard</code>
FHEM neu starten.

;Schritt 2: Grundkonfiguration

:<code>attr anyViews dashboard_width 80%</code>
:<code>attr anyViews dashboard_tab1groups <GRUPPE1>,<GRUPPE2>,<GRUPPE3></code>

<GRUPPE1>, etc. sind durch richtige Gruppennamen zu ersetzen, z.B. Licht,Wetter oder ähnliches. Bitte denkt daran auch Komponenten den Gruppen zuzuweisen (über das jeweilige groups Attribut) da ansonsten das Dasboard leer bleibt.

[[Datei:Dashboard-KeinGruppe.png|mini|250px|"Objekt" ohne Gruppe]]
[[Datei:Dashboard-Gruppe.png|mini|250px|"Objekt" in einer Gruppe]]

Danach sollen die beiden Gruppen im 1. Tab im Dashboard angezeigt werden. Zwar noch etwas chaotisch, aber das wird in den nächsten Schritten bearbeitet. 
[[#dashboard_tab1groups| Siehe dashboard_tab1groups]]

Das Dashboard zeigt neben den beiden Gruppen bereits einiges andere mit an. Hier werden erst einmal diese "Nebensächlichkeiten" erklärt. Für die weiteren Schritte dieser Anleitung sollten die nun genannten Einstellungen unverändert bleiben.

[[Datei:Dashboard_FirstGroup.png|mini|300px|Erste Gruppe im Dashboard]]
Am rechten Rand des Dashboards erscheinen einige Schalter ("Set", "Detail"). Der Schalter "Detail" springt in die Detailansicht des Dashboards um dort z.B. weiter Attribute hinzuzufügen. 
Der Schalter "Set" speichert die per Drag'n Drop vorgenommenen Änderungen '''temporär''' (diese sind dann noch nicht gespeichert!). "Set" wird in rot geschrieben wenn die Positionierung einer Gruppe geändert wurde, aber noch nicht mit dem "Set"-Schalter gesichert wurden! Ebenso wird mit dem Schalter "Set" das aktuell [[#dashboard_activetab|aktive Tab]] gesichert 
Die Schalterleiste kann über das Attribut ''dashboard_showtabs'' deaktiviert werden, oder wahlweise über oder unter dem Dashboard platziert werden. 
[[#dashboard_showtabs| Siehe dashboard_showtabs]]
 
Im Gruppentitel erscheint an deren rechten Rand ein Symbol (+/-). Mit diesem kann man die Gruppe minimieren oder die voreingestellte Größe wieder herstellen. 
[[#dashboard_showtooglebuttons| Siehe dashboard_showtooglebuttons]]
 
[[Datei:Dashboard_Helper.png|mini|300px|Dashboard Helper]]
Zum besseren Ausrichten der einzelnen Gruppen werden zur Unterstützung einige Hilfen angezeigt. Die Erste ist die Anzeige eines Rahmens um das Dashboard. Genauer gesagt um die einzelnen Reihen/Spalten des Dashboards. Eine weitere Hilfe ist der Hintergrund der Gruppen. Dieser kann über die Mindestgröße der Gruppe hinaus gezogen werden. Damit können beliebig große Abstände zwischen den einzelnen Gruppen eingestellt werden. 
[[#dashboard_showhelper| Siehe dashboard_showhelper]]

Da nun die ersten Gruppen im Dashboard angezeigt werden, geht es nun darum, diese an die gewünschten Stellen zu platzieren. Dazu werden erst noch die verschiedenen Reihen und Spalten eingerichtet. 

Das Dashboard verfügt über drei Reihen. Oben, Mitte und Unten. In der Standardeinstellung wird nur die mittlere Reihe angezeigt. Die mittlere Reihe sollte auch immer eingesetzt werden, da diese die Breite des Dashboard vorgibt. Für dieses kleine HowTo werden aber die obere und die mittlere Reihe eingeblendet, indem das Attribut '''dashboard_row''' auf '''top-center''' gestellt wird. Diese Einstellung gilt für das gesamte Dashboard und somit für alle verwendeten Tabs. Es ist nicht möglich, je Tab eine andere Einstellung zu wählen. 
[[#dashboard_row| Siehe dashboard_row]] 

Die Breite, die das Dashboard auf dem Bildschirm einnimmt, kann über das Attribut '''dashboard_width''' festgelegt werden. Standard ist die Breite von 100%. Es kann neben einem Prozentwert auch eine Breite in Pixel angegeben werden. 
[[#dashboard_width| Siehe dashboard_width]] 

Die Höhe der einzelnen Reihen kann über die Attribute dashboard_rowtopheight für die obere Reihe, dashboard_rowbottomheight für die untere Reihe und dashboard_rowcenterheight für die mittlere Reihe festgelegt werden. Damit können die Reihen nach den eigenen Bedürfnissen angepasst werden. Für dieses HowTo wird '''dashboard_rowtopheight''' auf '''300''' und '''dashboard_rowcenterheight''' auf '''400''' eingestellt. Diese Einstellung gilt für das gesamte Dashboard und somit für alle verwendeten Tabs. Es ist nicht möglich je Tab eine andere Einstellung zu wählen. 
[[#dashboard_rowtopheight| Siehe dashboard_rowtopheight]] 
[[#dashboard_rowbottomheight| Siehe dashboard_rowbottomheight]] 
[[#dashboard_rowcenterheight| Siehe dashboard_rowheight]] 

Die mittlere Reihe hat (historisch bedingt) eine Besonderheit. Diese kann in maximal 5 Spalten unterteilt werden. Für unser Beispiel setzten wird das Attribut '''dashboard_colcount''' auf '''2'''. Diese Einstellung gilt für das gesamte Dashboard und somit für alle verwendeten Tabs. Es ist nicht möglich je Tab eine andere Einstellung zu wählen. Weiter legen wir mit dem Attribut [[#dashboard_rowcentercolwidth|dashboard_rowcentercolwidth]] die Breite der ersten Spalte mit 30% und die der zweiten Spalte mit 70% fest in dem wir dem Attribut '''dashboard_rowcentercolwidth''' den Wert '''30,70''' zuteilen. 
[[#dashboard_colcount | Siehe dashboard_colcount ]] 

Sicherlich ist das positionieren einfach, und jeder wird das hin bekommen. Zwei, drei Worte möchte ich trotzdem darüber verlieren. 

:<ins>Verschieben</ins> 
:Gruppen können in andere Reihen oder Spalten des Dashboards verschoben werden. Dazu muss in die Gruppe angeklickt werden und die Maustaste gedrückt gehalten werden. Los lässt man diese wenn man an der richtige Stelle ist. Das war wohl schon jedem klar. 
:Ein möglicher Zielort wird mit einem abgerundeten Platzhalter markiert. Dieser verschiebt auch, falls notwendig, andere Gruppen. Manchen wundert es warum dieser Zielort manchmal recht spät angezeigt wird. Dies hängt von der Position des Mauszeigers ab. Aha?! Je weiter oben man eine Gruppe anpackt, desto höher muss man die Maus schieben. Oder anders formuliert, wenn sich ca. 50% der Gruppenfläche im Zielbereich befinden wird dieser Zielort erst markiert. Das verschieben eine Gruppe von einem Tab in das andere ist nicht möglich. Letztendlich bleibt jedem nur <ins>ausprobieren</ins>. 

:Gruppen können über, unter, neben und vor anderen Gruppen verschoben werden. Auch das erfolgt wie bereits oben aufgeführt. Dies ist für viele nicht neues. Zu beachten ist aber das sich eine Gruppe nur dann vor oder neben eine anderen positionieren lässt wenn diese von der Breite in das Dashboard passen. Wenn Ihr also Gruppen nebeneinander positionieren wollt dürfen diese in Summe nicht breiter als das Dashboard sein. 
:Dies gilt nicht für die Höhen der Gruppen. Diese können in Summe höher als das Dashboard und höher als eine Reihe sein. Hier findet keine Begrenzung statt wie bei der Breite. Um jedoch das ein oder andere optisch nicht so schöne Ergebnis zu bekommen sollte darauf geachtet werden das keine Gruppe über eine Reihe hinaus ragt. 

Für unser Beispiel verschieben wir zum Testen die Gruppen in beliebige Reihen bzw. Spalten der mittleren Reihe. Danach bitte den "Set" Schalter drücken, dieser hat sich durch die verschiebe Aktionen bereits rot markiert.

[[Datei:Dashboard_Positionieren.png|mini|200px|Ausrichtung von einzelnen Gruppen]]
Das Ausrichten ist gleichermaßen einfach wie das Positionieren und sollte auch nichts Neues sein. Aber auch hier möchte ich darüber zwei, drei Worte verlieren. 

:Das Positionieren ist nur möglich, wenn das Dashboard nicht gesperrt ist (Lock/Unlock). Dann wird ein abgeschrägte Ecke an der Gruppe angezeigt, mit der die Größe gezogen werden kann.
:Jede Gruppe kann in Höhe und Breite beliebig gezogen werden, wobei genau das wieder einen Hacken hat: Das Größerziehen ist nur bedingt möglich. Die Breite/Höhe ist auf die Breite/Höhe der Dashboard Reihe (oder Spalte) begrenzt. Damit kann man eine Gruppe nicht über den Rand des Dashboards hinaus vergrößern. 
:Das Kleinerziehen ist auch nur bis zu einer Mindestgröße möglich. Die Mindestgröße ist abhängig vom Inhalt der Gruppe, kann also von Gruppe zu Gruppe unterschiedlich sein. 
:Ein Sonderverhalten beim Vergrößern/Verkleinern gibt es auch: Ist ein Gruppe höher als die Reihe, lässt sich die Gruppe zwar dort positionieren. Beim Ausrichten springt dann der untere Rand nicht auf die Mindesthöhe der Gruppe, sondern auf die maximale Höhe der Reihe. In diesem Fall sollte die Höhe der Reihe geändert werden. Ähnliches kann auch in der Breite auftreten. 
:Ändert sich der Inhalt einer Gruppe (wird z.B. ein Dummy dazugepackt), ändert sich die Positionierung der Gruppe '''nicht''' automatisch. In diesem Fall ist man immer gezwungen auch die Größe der Gruppe im Dashboard an die neue Gegebenheit anzupassen.

Für unser Beispiel ziehen wir die Gruppen beliebig größer. Danach bitte den "Set"-Schalter drücken. Dieser hat sich durch die Verschiebeaktionen bereits rot markiert.

Wie bereits etwas weiter oben erklärt wird die Positionierung der Gruppen im Dashboard durch die Betätigung des Schalters "Set" temporär zwischengespeichert. Dadurch wird die Positionierung bereits für einen Seitenrefresh gespeichert. Solange bis das Browserfenster geschlossen wird. Danach wären diese Einstellungen verloren. 
Darum ist es notwendig die Positionierung permanent zu speichern, damit auch nach einem Neustart von Fhem die getroffenen Einstellungen und Positionierungen vorhanden sind. Dies geht über den in Fhem bekannten weg über ''Save config''. 
Wird der Schalter "Set" nicht betätigt, wird auch über ''Save config'' die Positionierung nicht gespeichert. Daher ist es wichtig, immer '''zuerst''' mit dem Schalter '''"Set"''' die Einstellung zwischenzuspeichern und '''danach mit ''Save config''''' den Zwischenspeicher permanent zu sichern. 

Durch den Schalter "Set" wird für jedes Tab die Einstellung in das für das jeweilige Tab zuständige Attribut geschrieben. Für Tab 1 ist das Attribut ''dashboard_tab1sorting'' zuständig, für Tab 2 das Attribut ''dashboard_tab2sorting'', usw. '''Diese Attribute sollten nicht editiert werden!'''

Es ist möglich jedem Tab einen eigenen individuellen Namen zu vergeben. Dazu ist für das jeweilige Tab das entsprechende Attribut zu befüllen. Z.B. für Tab 1 ist das Attribut ''dashboard_tab1name'' mit dem gewünschten Titel zu füllen. 
[[#dashboard_tab1name| Siehe dashboard_tab1name]]

== Letzte Änderungen / Dashboard-Historie ==

* (03.03.2014) Anzeigefehler bei readingGroups in einem Hiddenroom behoben
* (17.03.2014) Fehlerausgabe durch dashboard_webfrontendfilter behoben
* (26.03.2014) dashboard_showfullsize wird nicht im Raum "all" bzw. Everything angewendet
* (18.04.2014) Attribut dashboard_lock State entfernt. Kann nur noch in der Detailansicht verändert werden.
* (24.04.2014) Attribut dashboard_showhelper wird nicht mehr genutzt. Der Helper wird nur angezeigt wenn lockstate unlock ist.
* (24.04.2014) Schalter Detail und Set werden nun rechts angezeigt.
* (24.04.2014) Attribut dashboard_showtabs kann nicht mehr tabs-at-the-top-buttonbar-hidden oder tabs-on-the-bottom-buttonbar-hidden sein.
* (05.07.2015) {{Link2Forum|Topic=16503|Message=309740|LinkText=Änderungsübersicht und Update-Hinweise}}

== Links ==
* {{Link2Forum|Topic=16503}} über ''Dashboard''

[[Kategorie:FHEM Frontends]]
[[Kategorie:HOWTOS]]

Buderus EMS

2015-10-25T12:55:04Z

Rspecht: /* Software */

Buderus EMS

2015-10-25T12:51:16Z

Rspecht: /* Variante 1: NetIO / EMSCollector */

[[Buderus EMS]] ist das Bussystem zwischen den einzelnen Komponenten der Firma Buderus. In den meisten Fällen verbindet dieser Bus mindestens den Wandthermostat und die Heizung.

== Voraussetzungen ==
Man benötigt ein Inferfacemodul sowie eine Server-Software auf dem FHEM Server.

== Hardware ==
=== Variante 1: NetIO ===
Um den Bus im Netzwerk einzubinden benötigt man zusätzlich zu dem AVR Net-IO Board eine Adapterplatine. Diese Adapterplatine kann man recht einfach auf einer Lochrasterkarte aufbauen. Wie man das ganze Aufbaut ist im Link [http://ems-gateway.myds.me/dokuwiki/doku.php?id=wiki:ems:net_io EMS-Adapter/NetIO] sehr gut erklärt.

== Software ==
=== Variante 1: NetIO / EMSCollector ===
Wenn der oben beschriebene NetIO Hardware inkl. der zugehören Software läuft kann man sich um die Server-Software kümmern. Auch dieser Teil ist sehr gut in dem Link beschrieben. Abweichend hierzu kann man auf den MySQL Part verzichten da die Datenbank für FHEM nicht gebraucht wird. Maximal zum kompilieren des Collectors werden die Pakete benötigt, können danach jedoch wieder deinstalliert werden.

Nach erfolgreichem erstellen des Moduls kann es mit <code>chmod 700 collectord</code> ausführbar und mit <code>cp collectord /usr/bin/</code> ''installiert'' werden.

mit <code>collectord --db-path none -d all -C 7777 -D 7778 tcp:IP_NETIO:7950 -f</code> kann ein erster Test stattfinden. Die Parameter bedeuten:
*<code>--db-path none</code> keine Datenbankanbindung
*<code>-d all</code> volle Debugstufe
*<code>-C 7777</code> Telnet Steuerport 7777
*<code>-C 7778</code> Telnet Steuerport 7778
*<code>tcp:IP_NETIO:7950</code> Schnittstelle zum Net-IO
*<code>-f</code> Vordergrund

== Konfiguration ==

Buderus EMS

2015-10-25T12:47:25Z

Rspecht: /* Variante 1: NetIO / EMSCollector */

Buderus EMS

2015-10-25T12:44:24Z

Rspecht: /* Software */

Buderus EMS

2015-10-25T12:40:52Z

Rspecht: /* Variante 1: NetIO */

Buderus EMS

2015-10-25T12:40:06Z

Rspecht: /* Links */

Buderus EMS

2015-10-25T12:37:56Z

Rspecht: /* Links */

Buderus EMS

2015-10-25T12:37:15Z

Rspecht: /* Variante 1: NetIO */

Buderus EMS

2015-10-25T12:36:50Z

Rspecht: /* Variante 1: NetIO */

Buderus EMS

2015-10-25T12:35:36Z

Rspecht: /* Hardware */

Buderus EMS

2015-10-25T12:34:35Z

Rspecht: /* Konfiguration */

Buderus EMS

2015-10-25T12:29:19Z

Rspecht: /* Hardware */

Buderus EMS

2015-10-25T12:29:10Z

Rspecht: /* Voraussetzungen */

Buderus EMS

2015-10-25T12:28:18Z

Rspecht:

Buderus EMS

2015-10-25T12:27:11Z

Rspecht: Die Seite wurde neu angelegt: „Buderus EMS ist das Bussystem zwischen den einzelnen Komponenten der Firma Buderus. In den meisten Fällen verbindet dieser Bus mindestens den Wandthermost…“

[[Buderus EMS]] ist das Bussystem zwischen den einzelnen Komponenten der Firma Buderus. In den meisten Fällen verbindet dieser Bus mindestens den Wandthermostat und die Heizung.