FHEMWiki - Benutzerbeiträge [de]

FTUI3 Chart

2026-04-03T12:33:48Z

TomLee: unit Attribut ergänzt

{{Baustelle}}

Mit dem Chart-Widget können in FTUI3 komplexe Diagramme erstellt werden. Die Spezifikation erfolgt analog zur Spezifikation in FHEM. In einem Diagramm - definiert durch das Element <ftui-chart> - können beliebig viele Datensätze dargestellt werden. Für jeden Datensatz muss dabei ein Element <ftui-chart-data> angegeben werden. Beispiel:

<ftui-chart y-label="Energie W" y-unit="kWh" >
<ftui-chart-data label="PV1" color="red" log="EnergieD" spec="12:nt5000.reading" point-radius="0" border-width="3"></ftui-chart-data>
<ftui-chart-data label="PV2" color="pink" log="EnergieD" spec="5:PowerFlow.energy_summary_in" point-radius="0" border-width="3"></ftui-chart-data>
<ftui-chart-data label="Speicher" color="green" log="EnergieD" spec="4:PowerFlow.energy_summary_out" point-radius="0" border-width="3"></ftui-chart-data>
<ftui-chart-data color="green" log="EnergieD" spec="4:PowerFlow.battery_SOC::$fld[3]*10.24/100" point-radius="0"></ftui-chart-data>

<ftui-chart-data label="Haus" color="white" log="EnergieD" spec="6:PowerFlow.energy_summary_out" point-radius="0" border-width="3"></ftui-chart-data>
<ftui-chart-data label="Wallbox" color="yellow" log="EnergieD" spec="5:PowerFlow.energy_summary_out" point-radius="0" border-width="3"></ftui-chart-data>
<ftui-chart-data label="Grid" color="blue" log="EnergieD" spec="6:PowerFlow.energy_summary_in" point-radius="0" border-width="3"></ftui-chart-data>
<ftui-chart-data label="Upload" color="gray" log="EnergieD" spec="7:PowerFlow.energy_summary_in" point-radius="0" border-width="3"></ftui-chart-data>
</ftui-chart>
[[File:Ftui3-chart-1.png |800px]]

==Attribute von ftui-chart==
*y-label: Achsenbeschriftung für die erste vertikale Achse
*y-unit: Einheiten für die erste vertikale Achse
*y1-label: Achsenbeschriftung für die 2. vertikale Achse
*y1-unit: Einheiten für die 2. vertikale Achse
*unit: Zeitachse des Charts (Werte: hour, day, week, month, year, 24h, 30d)

==Attribute von ftui-chart-data==
*label: Bezeichnung der Daten in der Legende. Fehlt dieses Attribut, erfolgt kein Eintrag in die Legende.
*color: Farbe der Daten. Achtung, hier können nur die benannten Farben von FTUI3 verwendet werden.
*point-radius: Radius der Punkte für die Daten. Ist dieser Wert 0, werden keine Punkte gezeichnet.
*border-width: Breite der Linien für die Daten. Default-Wert ist 1

*log: Name des FHEM-Device für das Logging der Daten
*spec: Datenspezifikation wie im *.gplot-file von FHEM, also <Spalte>:<Regulärer Ausdruck>:<Default>:<Funktion>
[[Kategorie:FHEM Tablet UI V3]]

MQTT2-Module - Praxisbeispiele

2026-03-27T13:08:12Z

TomLee: /* Einfache Payload */ Ersatzwert für unbekannte Werte ergänzt

== Einführung: MQTT bzw. MQTT2 in FHEM ==
{{Randnotiz|RNTyp=y|RNText=Sollten Sie MQTT2_CLIENT verwenden, beachten Sie bitte, dass der MQTT2_CLIENT die ursprüngliche Herkunft der über MQTT verteilten Informationen nicht kennt. Daher ergeben sich in der Anwendung kleinere Unterschiede, zu deren Verständnis die diesbezüglichen [[MQTT2_CLIENT#Anwendung|Hinweise zu MQTT2_CLIENT]] bekannt sein sollten.}}Zur Einbindung von Geräten, welche zur Nutzung des MQTT-Protokols konfiguriert werden können und darüber mit einem MQTT-Server (früher: Broker) kommunizieren, stehen unter FHEM verschiedene Optionen zur Verfügung, wobei nicht alle Module beliebig miteinander verwendet werden können. Details hierzu sind dieser [[MQTT|Übersicht]] zu entnehmen.

Im Rahmen dieses Artikels wird für die eigentlichen Geräte [[MQTT2 DEVICE|MQTT2_DEVICE]] verwendet, damit wird als IO-Device entweder {{Link2CmdRef|Anker=MQTT2_SERVER|Lang=en|Label=MQTT2_SERVER}} oder [[MQTT2 CLIENT|MQTT2_CLIENT]] benötigt, mit einem IO-Device des Typs [[MQTT (Modul)|MQTT]] funktioniert die nachfolgende Darstellung dagegen nicht<ref>Allerdings können die Konfigurationen in der Regel recht einfach auf die bisherige MQTT-Implementierung übertragen werden</ref>. MQTT2_DEVICE unterstützt u.a. auch die ''setExtensions'' direkt, also z.B. ''on-for-timer<ref>Beachten Sie bei mehrkanaligen Geräten, dass jeweils nur ein Hauptkanal mittels setExtensions verwaltet werden kann! U.a. aus diesen Grund ist es meist sinnvoller, die ''split''-Varianten der attrTemplate-Einrichtung zu verwenden.</ref>'' sowie ''[[MQTT2-Module - Praxisbeispiele#attrTemplate_2|attrTemplate]]''<ref>Auch MQTT_DEVICE unterstützt SetExtensions, allerdings muss dies dort per Attribut eingeschaltet werden</ref>.

=== Allgemeine Einstellungen und Hinweise ===
{{Randnotiz|RNTyp=r|RNText=Beachten Sie, dass für [[autocreate]] in Verbindung mit MQTT2_SERVER '''zwingend''' jeder über MQTT kommunizierende Client eine ClientID angeben muss. Passen Sie daher ggf. die Einstellungen Ihres Geräts an. Manche Geräte verwenden auch "Wegwerf"-ClientID's. Für diese empfiehlt es sich, ggf. dann die durch autocreate erstellten Geräte nachzubearbeiten und die ClientID-Angabe v.a. aus den Inhalten des readingList-Attributs zu entfernen.}}Die nachfolgenden Beispiele gelingen am einfachsten mit '''MQTT2_SERVER als Server ("Broker")''', für diesen sollte dabei ''autocreate'' '''nicht deaktiviert''' sein, damit die erforderlichen MQTT2_DEVICES soweit möglich automatisiert erstellt werden<ref>Dabei wird vorausgesetzt, dass ein allgemeines {{Link2CmdRef|Anker=autocreate|Lang=en|Label=autocreate}}-Device (''TYPE=autocreate'') ebenfalls aktiv ist.</ref> .

Beispiel<ref>MQTT2_SERVER verwendet als default-Einstellung für ''autocreate'' ''simple'', ohne dass ein entsprechendes Attribut gesetzt werden müsste. Die Einstellung ''complex'' empfiehlt sich in der Regel nicht; diese ist jedoch dann zu empfehlen, wenn das Device entweder verschachtelte JSON-Array-Strukturen liefert oder bestimmte Readings nicht gefüllt werden sollen.</ref>:
define MQTT2_FHEM_Server MQTT2_SERVER 1883 global

Falls der MQTT Broker mit Hilfe von [[allowed]] abgesichert wurde, muss in den Geräten ebenfalls User bzw. Passwort eingetragen werden, damit eine MQTT Kommunikation möglich ist.

{{Hinweis|Die Code-Darstellung in diesem Beitrag entspricht jeweils dem RAW-Format zum [[Import von Code Snippets]]. Wer die Attribute direkt und einzeln bearbeitet, muss ggf. die "\" entfernen!}}

=== MQTT-Einstellungen in den Geräten ===
Die Beispiele gehen davon aus, dass die einzubindenden Geräte '''''mit den default-Einstellungen''''' für MQTT betrieben werden, wenn man von den Angaben zum Server und ggf. der Gerätekennung absieht. Es sollten also insbesondere '''keine Veränderungen der topic-Pfade''' vorgenommen werden.

{{Hinweis|Einige der hier beschriebenen Einstellungen haben Änderungen der sich durch die jeweiligen Automatismen eigentlich jeweils ergebenden Standard-Werte zur Folge, insbesondere, was Reading-Namen und von den Geräten gesendete Werte angeht. Sie sollten daher zunächst die Konfiguration des jeweiligen MQTT2-DEVICE-Geräts abschließen, und erst anschließend die weitere Integration mit Event-Handlern, logging usw. vornehmen. }}

=== auto-Konfigurations-features ===
Viele firmwares und Dienste bieten Möglichkeiten an, einer Controller-Software (insbesondere homeassistant) Hilfsdaten zur automatisierten Konfiguration bereitzustellen. Da FHEM diese Daten nicht zu ihrem ursprünglichen Zweck verwenden kann, werden hierdurch lediglich zusätzliche Readings erzeugt, mit denen man als User in der Regel wenig anfangen kann. Es wird daher empfohlen, derartige features '''abzuschalten'''. Wo dies nicht möglich ist, sollte man eine passende [[MQTT2_CLIENT#ignoreRegexp|ignoreRegexp]] setzen bzw. diese passend erweitern!

=== Schritt für Schritt ===
Hier werden in der Regel fertige Konfigurationen für häufige Anwendungsfälle (beispielhaft) dargestellt. In [[MQTT2_DEVICE - Schritt für Schritt]] ist etwas mehr über die Vorgehensweise bei der Zusammenstellung der verschiedenen Attribute und deren Zusammenwirken zu erfahren.

== zigbee2mqtt ==
[[Bild:MQTT2_zigbee2mqtt_Bulbs.png|400px|thumb|Darstellung in FHEMWEB]]
[https://www.zigbee2mqtt.io zigbee2mqtt] ist ein open-source Projekt, mit dem zigbee-Geräte über MQTT direkt angesprochen werden können, ohne dass hierfür eine Bridge eines Herstellers benötigt wird.

Einzelheiten zur Vorgehensweise sind auf der Detailseite [[Zigbee2mqtt|zigbee2mqtt]] zu finden.

== Tasmota ==
{{Randnotiz|RNTyp=r|RNText=Bitte beachten Sie, dass versicherungsrechtliche Probleme entstehen können, wenn die herstellereigene Firmware ersetzt wird!}}[https://github.com/arendst/Sonoff-Tasmota Tasmota] ('''T'''heo '''A'''rends '''S'''onoff '''M'''QTT '''O'''ver '''T'''he '''A'''ir - einer offenen Firmware von [https://github.com/arendst arendst]) ist eine open-source Software für ESP8266-Geräte, die z.B. statt der originalen Firmware für Sonoff-Geräte und andere ESP8266-basierte WLAN-Steckdosen usw. verwendet werden kann.
{{Hinweis|[[Datei:Tasmota mqtt config.png|120px|thumb|right]]Vor allem, aber nicht nur bei Verwendung des MQTT2_CLIENT als IO, ist es empfehlenswert, in der MQTT-Konfiguration der tasmota-Geräte für den Parameter ''<nowiki>topic = %topic% (tasmota)</nowiki>'' ebenfalls die dynamisch aus der Chip-ID erzeugte Kennung ''DVES_%06X'' zu verwenden. (Kopieren Sie einfach diese Zeichenkette aus dem Eingabefeld für ''"client ..."'', siehe nebenstehende Abbildung). Die eigentliche Umbenennung zu einem "sprechenden Namen" kann dann innerhalb von FHEM - mittels ''rename'' oder ggf. mit einem ''alias'' - erfolgen.}}
=== MQTT2_DEVICE ===
Dieses sollte bei aktiviertem ''autocreate'' am MQTT2_SERVER-Device automatisch angelegt werden, sobald das betreffende Gerät eingesteckt oder neu gestartet oder an einem evtl. vorhandenen Taster geschalten wird. Bislang wurden Tasmota version(en) ab 6.1.1 bis min. 8.1.0 getestet, dies auf verschiedener Hardware, zunächst mit Sonoff Touch und S20, zwischenzeitlich mit einer Vielzahl von Geräten, die per USB-Adapter oder mit der Methode aus dem [https://www.heise.de/ct/artikel/Tuya-Convert-IoT-Geraete-ohne-Loeten-vom-Cloud-Zwang-befreien-4283623.html Tuya-Convert]-Projekt des heise-Verlags auf Tasmota umgeflasht wurden.

=== Manuelle Anpassungen - Schalter ===
Die RAW-Definition kann dann beispielsweise wie folgt ergänzt werden:
<syntaxhighlight lang="perl">
defmod MQTT2_DVES_9B01BD MQTT2_DEVICE DVES_9B01BD
attr MQTT2_DVES_9B01BD IODev m2server
attr MQTT2_DVES_9B01BD devStateIcon on:FS20.on:off off:FS20.off:on
attr MQTT2_DVES_9B01BD readingList DVES_9B01BD:tele/DVES_9B01BD/STATE:.* { json2nameValue($EVENT) }\
DVES_9B01BD:tele/DVES_9B01BD/LWT:.* LWT\
DVES_9B01BD:tele/DVES_9B01BD/UPTIME:.* { json2nameValue($EVENT) }\
DVES_9B01BD:tele/DVES_9B01BD/SENSOR:.* { json2nameValue($EVENT) }\
DVES_9B01BD:tele/DVES_9B01BD/INFO1:.* { json2nameValue($EVENT) }\
DVES_9B01BD:tele/DVES_9B01BD/INFO2:.* { json2nameValue($EVENT) }\
DVES_9B01BD:tele/DVES_9B01BD/INFO3:.* { json2nameValue($EVENT) }\
DVES_9B01BD:stat/DVES_9B01BD/RESULT:.* { json2nameValue($EVENT) }\
DVES_9B01BD:stat/DVES_9B01BD/STATE:.* { json2nameValue($EVENT) }
attr MQTT2_DVES_9B01BD room MQTT2_DEVICE
attr MQTT2_DVES_9B01BD setList on cmnd/DVES_9B01BD/POWER on\
off cmnd/DVES_9B01BD/POWER off\
reboot cmnd/DVES_9B01BD/Restart 1
attr MQTT2_DVES_9B01BD webCmd on:off:reboot
</syntaxhighlight>

=== Manuelle Anpassungen - Dimmer ===
{{Randnotiz|RNTyp=r|RNText=Dieses Beispiel ist nur bedingt zur Nachahmung zu empfehlen: Prinzipiell kann man Readings und setter in MQTT2_DEVICE fast nach Belieben benennen. Wählt man allerdings <i>FHEM-typische</i> Namen, kann dies sehr zur Vereinfachung beitragen. Z.B. wird eine Sprachssteuerung bei einem Dimmer üblicherweise automatisch korrekt eingestellt werden, wenn der für die Helligkeit zuständige setter z.B. <i>pct</i> (oder <i>brightness</i>) heißt, oder eine abzufragende Temperatur <i>temperature</i>. Entsprechendes gilt im Rahmen von <i>devspec-Abfragen</i>.}}Bei einem Dimmer sind einige zusätzliche Anpassungen vorzunehmen. Ein Dimmer wird über '''POWER''' geschaltet und über '''Dimmer''' gedimmt. Damit das funktioniert, müssen ein stateFormat und devStateIcon zusammenarbeiten:
<syntaxhighlight lang="perl">
attr MQTT2_DVES_2DF34D devStateIcon 10\d.*:dim100%@orange:off 1\d.*:dim12%@orange:off 2\d.*:dim18%@orange:off 3\d.*:dim31%@orange:off 4\d.*:dim43%@orange:off 5\d.*:dim50%@orange:off 6\d.*:dim62%@orange:off 7\d.*:dim68%@orange:off 8\d.*:dim81%@orange:off 9\d.*:dim93%@orange:off 0:FS20.off:on .*:FS20.off@orange:off
attr MQTT2_DVES_2DF34D stateFormat {if(ReadingsVal($name,"POWER",0)eq"off"){0}else{ReadingsVal($name,"Dimmer",0)}}
</syntaxhighlight>
Nun kann man über das Icon ein- und ausschalten und der Zustand des Dimmers wird korrekt angezeigt.

Es fehlt noch ein Slider, um auch dimmen zu können. Zusätzlich muss setList noch um Dimmer erweitert werden:
<syntaxhighlight lang="text">
attr MQTT2_DVES_2DF34D setList on cmnd/dimmer/POWER on\
off cmnd/dimmer/POWER off\
Dimmer cmnd/dimmer/Dimmer
attr MQTT2_DVES_2DF34D webCmd Dimmer
attr MQTT2_DVES_2DF34D widgetOverride Dimmer:slider,0,1,100
</syntaxhighlight>

=== attrTemplate ===
===== Allgemeines =====
Für gängige Tasmota-Geräte stehen ''templates'' bereit, mit denen sich diese schnell konfigurieren lassen.
Beachten Sie dazu den Abschnitt ''attrTemplate'' in [[MQTT2 DEVICE#attrTemplate|MQTT2_DEVICE]]. Bei Anwendung eines template mit "split" im Namen werden dabei weitere Geräte angelegt und konfiguriert.{{Hinweis|Bitte attrTemplates nicht verwechseln mit templates, die auf den Tasmota- bzw. Blackadder-Seiten angeboten werden, welche zur Konfiguration der firmware genutzt werden können! Es sollte zunächst die firmware korrekt eingerichtet werden, so dass das Gerät selbst direkt auf dessen Web-Interface korrekt bedient werden kann.}}

===== Kein passendes attrTemplate vorhanden? =====
Exisitert (noch) kein passendes attrTemplate, ist zu empfehlen, zunächst das "''tasmota_basic''" anzuwenden. Dieses führt einige Basiskonfigurationen durch, die für FHEM hilfreich sind, z.B. wird die firmware so eingestellt, dass Schaltzustände in Kleinschreibung übermittelt werden, statt der defaults "ON" bzw. "OFF".

Allerdings stellt dieses das ''autocreate'' an dem MQTT2_DEVICE auf 0, was dann nicht optimal ist, wenn man weitere Readings aus dem Gerät erwartet, etwa, weil zusätzliche Sensoren vorhanden sind. In diesem Fall empfiehlt es sich, das ''autocreate''-Attribut an dem MQTT2_DEVICE zu löschen, damit alle weiteren Informationen verarbeitet werden und ggf. im ''jsonMap''-Attribut nur die Angabe "''POWER1:state''" zu belassen.

=== on-for-timer ===
Um z.B. ein Relais nur für einen Zeitraum anzuschalten, kann man bei Tasmota-Geräten zwischen mehrere Varianten wählen. Ohne speziellen ''setter'' in der ''setList'' werden die '''SetExtensions''' verwendet. Timer laufen damit innerhalb FHEM. Da diese intern als temporäres [[at]] ausgeführt werden, sind diese auch noch nach einem FHEM-Neustart vorhanden, sofern FHEM ordnungsgemäß beendet und neu gestartet wird.

Die Tasmota-firmware bietet ergänzend dazu zwei Möglichkeiten an, bei denen der Timer direkt auf dem ESP-Microcontroller verwaltet wird:

==== delay ====
Zeile zur Erweiterung der ''setList'' (Attributeingabe via FHEMWEB!):
on-for-timer {my $duration = $EVTPART1*10; 'cmnd/DVES_575127/Backlog POWER1 1; delay '.$duration.'; POWER1 0'}

Ohne Auswirkungen auf alles, was danach kommt, hat aber den Nachteil, dass die möglichen Zeitspannen auf 3600 1/10 Sekunden begrenzt sind (siehe [https://tasmota.github.io/docs/Commands/#delay Commands - Tasmota Delay]), also 6 Minuten.

====pulseTime ====
Zeile zur Erweiterung der ''setList'' (s.o.):
on-for-timer {my $duration = $EVTPART1 < 11.2 ? $EVTPART1*10 : $EVTPART1+100; 'CMNDTOPIC/Backlog pulseTime1 '.$duration.'; POWER1 1'}
Auch hier sind die möglichen längsten Einschaltdauern begrenzt, allerdings ist diese mit 18h deutlich länger als mit ''delay''. Diese Implementierung hat den Nachteil, dass der ESP-Microcontroller die jeweils letzte pulseTime auch für alle weiteren "normalen" Einschaltvorgänge berücksichtigt, das Relais also ebenfalls nach Ablauf der übermittelten pulseTime abgeschaltet wird; dies gilt allerdings ohne explizites ''save'' nur bis zum nächsten reboot des Microcontrollers.

Da nach dem ersten pulseTime setzten, diese immer benutzt wird, kann man mit einem kleine Workaround das Device normal arbeiten lassen. Dafür wird bei jedem anderem Befehl, aus der PulseTime, der Timer deaktiviert.
Hierfür machen wir uns zu nutzen, dass man mehrere Befehle gleichzeitig an Tasmota senden kann (backlog). Ob diese Lösung auch mit anderen MQTT Firmwares funktioniert, kann ich nicht sagen. Es wurde lediglich mit Tasmota getestet.
Wir senden also, bevor wir den eigentlich Tasmota Befehl zum Ein- oder Ausschalten schicken, einen Befehl zum deaktivieren des Timers: "pulseTime 0"
Hier ein Beispiel: (das entsprechende device "DEV_611F3E" muss gegen das eigene ersetzt werden)
off:noArg cmnd/DVES_611F3E/backlog pulseTime 0; POWER1 0
on:noArg cmnd/DVES_611F3E/backlog pulseTime 0; POWER1 1
toggle:noArg cmnd/DVES_611F3E/backlog pulseTime 0; POWER1 2

=== zigbee2tasmota ===
[https://tasmota.github.io/docs/Zigbee/ zigbee2tasmota] ist eine Erweiterung der Tasmota-firmware für Microcontroller, insbesondere dem ESP8266 (und ESP32)(link), über die einige ZigBee-Chipsätze (insbesondere TI CC2530) als [[ZigBee#Koordinator_.28ZigBee_coordinator.2C_ZC.29|Coordinator]] eingebunden werden können, um ein ZigBee-Netzwerk aufzubauen.
{{Hinweis|Stand 08/2020 war die Einbindung anderer Chipsätze erst in einem Alpha-Stadium; die Zahl der über einen CC2530 einbindbaren ZigBee-Geräte ist daher derzeit relativ begrenzt (ca. 16)!}}
Auch für diese Lösung stehen einige ''attrTemplate'' zur Verfügung. Nähere Informationen hierzu sind dem Artikel [[Zigbee2Tasmota-MQTT]] zu entnehmen.

== ESPurna ==
ESPurna ist eine weitere alternative firmware für ESP8266-basierte Geräte, Details sind der [https://github.com/xoseperez/espurna/wiki Projektseite] zu entnehmen.

Das Format, in dem ESPurna Daten sendet, unterscheidet sich v.a. darin, dass bool'sche Werte als 0 oder 1 gesendet werden, und nicht wie sonst üblich als "on" oder "off" oä.. Es stehen einige Mustertemplates zur Verfügung, um diese Art der Payload in FHEM-konforme Werte zu überführen.

== Shelly ==
=== Vorbemerkung ===
Auch für Shelly-Geräte steht eine Auswahl an [[MQTT2-Module - Praxisbeispiele#attrTemplate_2|templates]] bereit.
Beachten Sie auch hier, dass uU. bei Anwendung eines template mit "split" im Namen weitere Geräte angelegt und konfiguriert werden.

Standardmäßig senden die Shelly-Geräte ihren kompletten Status alle 30 Sekunden. Dies kann man über den Parameter ''mqtt_update_period'' in den ''settings'' ändern, allerdings ist dieser nur über die HTTP-Schnittstelle des Shelly verfügbar. Um diese Statusupdates abzustellen, kann über den Browser folgender Befehl verwendet werden:
http://<ip-des-shelly>/settings?mqtt_update_period=0,
Soweit bekannt, werden dann nur statische updates ausgeschaltet, z.B. für das Relay bzw. angeschlossene Taster oder Schalter; insbesondere Verbrauchswerte werden dennoch aktualisiert.

=== Shelly1 ===

=== Shellybulb ===
Zunächst muss man einen Statusupdate des Shellybulb erzwingen (Aus- und Einschalten, physikalisch oder per Web-UI), damit das Gerät bei eingeschaltetem autocreate angelegt wird. Dies sieht zunächst so aus:
Internals:
CFGFN
CID shellybulb_3CC533
DEF shellybulb_3CC533
DEVICETOPIC MQTT2_shellybulb_3CC533
IODev MQTT2_FHEM_Server
NAME MQTT2_shellybulb_3CC533
NR 246
STATE ???
TYPE MQTT2_DEVICE
READINGS:
2018-12-12 19:28:08 status_blue 0
2018-12-12 19:28:08 status_brightness 61
2018-12-12 19:28:08 status_effect 0
2018-12-12 19:28:08 status_gain 26
2018-12-12 19:28:08 status_green 0
2018-12-12 19:28:08 status_ison true
2018-12-12 19:28:08 status_mode color
2018-12-12 19:28:08 status_red 255
2018-12-12 19:28:08 status_temp 3250
2018-12-12 19:28:08 status_white 0
Attributes:
IODev MQTT2_FHEM_Server
readingList shellybulb_3CC533:shellies/shellybulb-3CC533/color/0/status:.* { json2nameValue($EVENT, 'status_') }
room MQTT2_DEVICE
[[Bild:MQTT2 Shellybulb.png|400px|thumb|Darstellung in FHEMWEB nach Anwendung des template]]Dann bei den set-Anweisungen das attrTemplate "shellybulb" auswählen und setzen. Es erscheint eine Abfrage, ob die vorhandenen Readings gelöscht werden sollen. Diese bitte bestätigen und die Seite neu laden. Danach einmal An- und Ausschalten, damit die Readings auch durch einen neuen Status initialisiert werden und die Seite im Browser neu laden.

=== Shelly Plug S ===
Über die Leistungsmessung des Shelly Plug S lässt sich sehr einfach auch eine Erkennung des Betriebszustandes des angeschlossenen Gerätes realisieren. Dazu stellt man zuerst fest, wieviel Leistung das Gerät in jedem Betriebszustand verbraucht und kann dann z.B. für einen angeschlossenen Fernseher, der im Standby 1 Watt und im Betrieb > 100 Watt verbraucht, den Zustand erkennen und als on/off Status anzeigen. Dazu wird das state Reading wie folgt definiert:
attr readingList shellies/shellyplug-s-123456/relay/0/power:.* { { state => $EVTPART0<100?"off":"on" } }
Der Status des MQTT2 Devices zeigt dann bei <100W "off" und sonst "on" an.

=== HTTP-Commands ===
In diesem {{Link2Forum|Topic=102369|LinkText=Forumsbeitrag}} wird eine Lösung vorgestellt, um über [[99 myUtils anlegen|myUtils-Code]] weitere Kommandos bereitzustellen, die sonst nur direkt über das Web-Interface zu erreichen sind.

== Shelly Gen2 ==
=== Vorbereitung ===
Shelly mit dem WLAN verbinden, entweder über die Shelly APP oder per Laptop auf den Offenen AP des Shelly verbinden und dann übers WebUI des Shelly mit dem Heimischen WLAN verbinden. Über die APP geht dies meist etwas einfach und schneller, besonders wenn man mehrere Shelly Geräte hinzufügen möchte. Durch die BT Unterstützung der Gen2 Geräte, klappt dies meist auch deutlich schneller und zuverlässiger als noch bei Gen 1 Geräten.
Nachdem der Shelly mit dem WLAN verbunden ist, sollte die Firmware überprüft und gegebenenfalls aktualisiert werden (Stand Anfang 2022 scheint die firmware noch nicht voll ausgereift gewesen zu sein, da dass insbesondere die MQTT-Schnittstelle immer wieder überarbeitet wurde). Bitte KEINE BETA Versionen installieren, wenn nicht dazu aufgefordert wurde.
Nach dem, durch das Update ausgelösten, Neustart kurz Prüfen ob die Uhrzeit passt, wenn trotz richtiger Zeitzone die Uhrzeit nicht stimmt hilft ein weiterer Neustart.
Nun auf Networks| Internet (leider in APP und WebUI unterschiedlich), hier auf MQTT und die Einstellungen für den verwendeten MQTT Server treffen. Diese Einstellungen werden auch wieder durch Neustart übernommen.
=== Shelly Plus 1 ===
Zunächst muss man einen Statusupdate des Shelly erzwingen (Aus- und Einschalten, physikalisch oder per Web-UI), damit das Gerät bei eingeschaltetem autocreate angelegt wird. Dies sieht zunächst so aus:
<syntaxhighlight lang="text">
defmod MQTT2_shellyplus1_441793a34044 MQTT2_DEVICE shellyplus1_441793a34044
attr MQTT2_shellyplus1_441793a34044 readingList shellyplus1_441793a34044:shellyplus1-441793a34044/online:.* online\
shellyplus1_441793a34044:shellyplus1-441793a34044/status/mqtt:.* { json2nameValue($EVENT) }\
shellyplus1_441793a34044:shellyplus1-441793a34044/events/rpc:.* { json2nameValue($EVENT) }\
shellyplus1_441793a34044:shellyplus1-441793a34044/status/sys:.* { json2nameValue($EVENT) }\
shellyplus1_441793a34044:shellyplus1-441793a34044/status/switch_0:.* { json2nameValue($EVENT) }
attr MQTT2_shellyplus1_441793a34044 room MQTT2_DEVICE

setstate MQTT2_shellyplus1_441793a34044 2022-03-05 11:08:24 IODev m2s
setstate MQTT2_shellyplus1_441793a34044 2022-03-05 11:08:31 available_updates_beta_version 0.10.0-beta6
setstate MQTT2_shellyplus1_441793a34044 2022-03-05 11:08:31 cfg_rev 7
setstate MQTT2_shellyplus1_441793a34044 2022-03-05 11:08:24 connected true
setstate MQTT2_shellyplus1_441793a34044 2022-03-05 11:09:12 dst shellyplus1-441793a34044/events
setstate MQTT2_shellyplus1_441793a34044 2022-03-05 11:08:31 fs_free 237568
setstate MQTT2_shellyplus1_441793a34044 2022-03-05 11:08:31 fs_size 458752
setstate MQTT2_shellyplus1_441793a34044 2022-03-05 11:09:12 id 0
setstate MQTT2_shellyplus1_441793a34044 2022-03-05 11:08:31 mac 441793A34044
setstate MQTT2_shellyplus1_441793a34044 2022-03-05 11:09:12 method NotifyStatus
setstate MQTT2_shellyplus1_441793a34044 2022-03-05 11:08:24 online true
setstate MQTT2_shellyplus1_441793a34044 2022-03-05 11:09:12 output false
setstate MQTT2_shellyplus1_441793a34044 2022-03-05 11:08:24 params_mqtt_connected true
setstate MQTT2_shellyplus1_441793a34044 2022-03-05 11:09:12 params_switch_0_id 0
setstate MQTT2_shellyplus1_441793a34044 2022-03-05 11:09:12 params_switch_0_output false
setstate MQTT2_shellyplus1_441793a34044 2022-03-05 11:09:12 params_switch_0_source WS_in
setstate MQTT2_shellyplus1_441793a34044 2022-03-05 11:08:24 params_switch_0_temperature_tC 39.88
setstate MQTT2_shellyplus1_441793a34044 2022-03-05 11:08:24 params_switch_0_temperature_tF 103.78
setstate MQTT2_shellyplus1_441793a34044 2022-03-05 11:08:31 params_sys_available_updates_beta_version 0.10.0-beta6
setstate MQTT2_shellyplus1_441793a34044 2022-03-05 11:09:12 params_ts 1646474952.66
setstate MQTT2_shellyplus1_441793a34044 2022-03-05 11:08:24 params_wifi_rssi -57
setstate MQTT2_shellyplus1_441793a34044 2022-03-05 11:08:24 params_wifi_ssid WLAN-Alex
setstate MQTT2_shellyplus1_441793a34044 2022-03-05 11:08:24 params_wifi_sta_ip 192.168.177.167
setstate MQTT2_shellyplus1_441793a34044 2022-03-05 11:08:24 params_wifi_status got ip
setstate MQTT2_shellyplus1_441793a34044 2022-03-05 11:08:31 ram_free 179764
setstate MQTT2_shellyplus1_441793a34044 2022-03-05 11:08:31 ram_size 249456
setstate MQTT2_shellyplus1_441793a34044 2022-03-05 11:08:31 restart_required false
setstate MQTT2_shellyplus1_441793a34044 2022-03-05 11:09:12 source WS_in
setstate MQTT2_shellyplus1_441793a34044 2022-03-05 11:09:12 src shellyplus1-441793a34044
setstate MQTT2_shellyplus1_441793a34044 2022-03-05 11:09:12 temperature_tC 39.9
setstate MQTT2_shellyplus1_441793a34044 2022-03-05 11:09:12 temperature_tF 103.9
setstate MQTT2_shellyplus1_441793a34044 2022-03-05 11:08:31 time 11:08
setstate MQTT2_shellyplus1_441793a34044 2022-03-05 11:08:31 unixtime 1646474911
setstate MQTT2_shellyplus1_441793a34044 2022-03-05 11:08:31 uptime 7
</syntaxhighlight>

Über die set Anweisung unterhalb der Device Übersicht können wir ein attrTemplate wählen; shellyPlus_1
Es erscheint eine kurze Übersicht was im Template enthalten ist, dieses befindet sich noch im Aufbau und wird aktuell von der Community aufgebaut und weiterentwickelt. Mit einem Klick auf „set“ laden wir das Template und übernehmen die Einstellungen für den Shelly Plus 1.
Damit ist der Shelly bereit, im Status wird neben dem Namen auch der Onlinestatus des Shellys (grüner | roter Punkt) so wie eine Lampe mit Toggle (on | off) Funktion und die Temperatur des Shellys angezeigt. Darüber hinaus verschwindet die Lampe und wird durch einen klickbaren Hinweis ersetzt, wenn ein Neustart des Shellys nötig ist.

=== Tipps ===
{{Randnotiz|RNTyp=g|RNText=So nimmt man bei Verwendung eines normalen Schalters (eine Stellung EIN eine AUS) gerne den „Flip“ Mode – damit wird der Shelly IMMER umgeschaltet, egal in welche Stellung der Schalter sich bewegt („Kreuzschaltung“). Diese Einstellungen trifft man grundlegend im WebUI des Shelly (oder APP) unter „Channel settings“.
Für den „Flip“ müssen wir die Grundeinstellung des „Power on default“ auch ändern (gleiche Seite) - persönlich wähle ich „Restore last“, also: nach Stromausfall wird der letzte Zustand wieder hergestellt; grundsätzlich gehen alle Modi außer „Match input“.
}}
Das aktuelle Template wurde um die Funktion erweitert, den Button Mode umzuschalten. In den meisten Fällen legt man sich auf eine Schaltmethode fest, welche zum Hardware Setup passt.

Manchmal will man aber vielleicht den Hardware Schalter deaktivieren, nennen wir es „Kindersicherung“. Bei Shelly heißt das „detached“.
Diese Funktion wurde ins Template als „in_mode“ Übernommen. Mögliche set Befehle sind „flip“, „detached“ „toggle“. Bedingung zur Verwendung ist: „relay power on default“ darf NICHT „Match input“ sein. Sollte Follow statt Flip bevorzugt werden, müsste entsprechende Zeile in der setList von „flip“ auf „follow“ angepasst werden.

Der Befehlt lässt sich mit dem webCmd in_mode auch schnell zugänglich in die Übersicht vom Shelly setzen, so erhält man neben dem Status ein Dropdown mit flip detached und toggle zum schnellen umschalten. Mit webCmdLabel kann man noch einen Namen für das Dropdown setzen.

== OpenMQTTGateway ==
Um verschiedene Systeme wie BLE usw. auf MQTT zu bringen bietet sich [https://github.com/1technophile/OpenMQTTGateway OpenMQTTGateway] an, z.B. wird für das Auslesen vieler BLE-Seonsoren lediglich ein ESP32-Board ohne Zusatzhardware (ab ca. 5,- Euro in Fernost erhältlich) benötigt, auf das dann eine vorkompilierte firmware geflasht wird (hierfür wird ein USB-seriell-Wandler benötigt).

Nähere Details sind im Artikel [[OpenMQTTGateway]] zu finden.

== 8-Port-Ethernet Board ==
<gallery>
datei:8-relais-ethernetboard closed.jpg|mit Gehäuse
datei:8-Port-MQTT-Relais-Board.jpg|ohne Gehäuse
</gallery>
In diesem {{Link2Forum|Topic=107536|Message=1016379|LinkText=Forenbeitrag}} bzw. dem betreffenden Thread wurde ein Relais-Board vorgestellt, mit dem 8 Relais über Ethernetkabel verbunden werden, die Kommunikation erfolgt dann über MQTT. Über die verwendete Software ist wenig bekannt, es könnte jedoch sein, dass diese Art der Einbindung auch bei weiteren Boards funktioniert, die einen bestimmten Ethernet-Chipset von TI (DP83848) und eine Cortex M3 MCU verwenden.

== Milight-Bridge ==
=== Vorbemerkung ===
Der [https://github.com/sidoh/esp8266_milight_hub esp8266_milight_hub] ist ein open source- Projekt, mit dem auf Basis von ''openmili'' eine Vielzahl von MiLight-Geräten gesteuert werden können. Der MiLight-Hub erstetzt dabei eine beliebige Zahl von Milight-Bridges und ist auch zu verschiedenen Versionen des MiLight-Protokols kompatibel. Allerdings lassen sich manche MiLight-Geräte nicht an die Bridge anlernen, und es werden auch nicht alle Fernbedienungs-Typen voll unterstützt.
Neben MQTT kann dieser auch mit HTTPMOD oder Wifilight (bzw. den MiLight-Modulen) gesteuert werden. Die Hardware entspricht dabei im Wesentlichen einem MySensors-Wifi-Gateway<ref>Es wird lediglich ein anderer CS-PIN genutzt. Dies kann einfach in der Web-Oberfläche der Firmware umgestellt werden.</ref>.
Hier wird vorausgesetzt, dass eine funktionierende Bridge vorhanden ist und die zu steuernden Leuchtmittel mit dem Hub bereits verbunden (gepairt) sind bzw. entsprechende Fernbedienungs-Signale empfangen werden können (bei vorhandenem pairing eines Leuchtmittels an die Fernbedienung).
Der Vorteil der MQTT-Lösung liegt darin, dass man bei kompatiblen Fernbedienungen auch direkt Informationen über Schaltvorgänge erhält, die mit der Fernbedienung ausgelöst werden.

=== Einstellungen am MiLight-Hub ===
Die zum FHEM-Server bzw. dem MQTT2_SERVER passenden Vorgaben sind im Web-Interface des Hub einzustellen. Gegebenenfalls passen Sie die vom Hub zurückzugebenden Elemente im Web-Interface des Hub an.
Die Einstellungen für ''MQTT topic pattern'' usw. können auf den default-Werten<ref>Diese sind: <br>''milight/:device_id/:device_type/:group_id'' für "topic pattern"<br>''milight/updates/:hex_device_id/:device_type/:group_id'' für "update topic pattern"<br>''milight/states/:hex_device_id/:device_type/:group_id'' für "state topic pattern". Der Autor hat derzeit folgende Infotypen zum Senden markiert: "status, brightness, hue, color, mode, color_temp, bulb_mode, computed_color, hex_color" (enthält eventuell zu viele Angaben. Bei einem Eventhandler muss man uU. darauf achten, dass kurz hintereinander zweimal dasselbe Event kommen kann (für ON/OFF)).</ref> belassen werden, für die seit Mitte 2019 vorhandene Option, eine LWT-Message zu senden (''MQTT Client Status Topic''), tragen Sie ''milight/LWT'' ein und aktivieren ''Detailed''.

=== FHEM-Devices ===
[[Bild:MQTT2 MiLight.png|400px|thumb|Milight: Darstellung in FHEMWEB]]
==== Bridge ====
Wird nun über den Hub oder eine von diesem erkannte Fernbedienung ein vorhandenes Leuchtmittel geschaltet, wird bei eingeschaltetem autocreate ein erstes Device erstellt, die zunächst erstellte Definition sieht typischerweise etwa so aus:
defmod MQTT2_milight_hub_1370325 MQTT2_DEVICE milight_hub_1370325
attr MQTT2_milight_hub_1370325 IODev MQTT2_FHEM_Server
attr MQTT2_milight_hub_1370325 readingList milight_hub_1370325:milight/updates/0xBE59/rgbw/1:.* { json2nameValue($EVENT, '1_', $JSONMAP) }
attr MQTT2_milight_hub_1370325 room MQTT2_DEVICE

Auf dieses Device wird nun das ''template'' '''esp_milight_hub_bridge''' angewandt.

==== Einzelne Leuchtmittel ====

Wird nun nochmals das oben verwendete Leuchtmittel geschaltet, erstellt autocreate ein weiteres Device:
defmod MQTT2_milight_0xBE59_1 MQTT2_DEVICE milight_0xBE59_1
attr MQTT2_milight_0xBE59_1 IODev MQTT2_FHEM_Server
attr MQTT2_milight_0xBE59_1 readingList milight/states/0xBE59/rgbw/1:.* { json2nameValue($EVENT, '1_', $JSONMAP) }
attr MQTT2_milight_0xBE59_1 room MQTT2_DEVICE

Auf dieses wird nun eines der Bulb-templates angewendet. Wählt man das template X_01_esp_milight_hub_rgbw_bulb, wird eine einfache Variante erstellt, die neben einem toggelnden Icon nur Regler für Helligkeit, die Farbe und zwei Schaltflächen für den Weiß- und Nachtmodus enthält. Wer mehr oder andere Steuerelemente erhalten möchte, verwendet ein anderes template. Nicht benötigte Elemente kann man dabei einfach aus der Definition löschen.

Alle weiteren Devices werden genauso erstellt.

Um ein Device zu erhalten, mit dem sich alle Kanäle gleichzeitig steuern lassen, kann das template ''X_01a_esp_milight_hub_make_rgbw_group'' verwendet werden. Dieses verändert nicht das aktuelle Device, sondern erstellt '''eine Kopie''', die dann modifiziert wird. Diese Kopie ist unter dem Namen ''milight_<RemoteID>_0'' im selben Raum zu finden wie das Ausgangsgerät und kann ebenfalls an die eigenen Wünsche angepasst werden.

Weitere Beispiele:
Beispiel für ein RGB-CCT-Device:
defmod Licht_Wz_all MQTT2_DEVICE
attr Licht_Wz_all IODev MQTT2_Broker
attr Licht_Wz_all eventMap /set_white:Weiss/night_mode:Nacht/white_mode:white/on:on/off:off/ON:on/OFF:off/next_mode:Mode/mode_speed_up:Up/mode_speed_down:Down/
attr Licht_Wz_all group Licht
attr Licht_Wz_all icon light_control
attr Licht_Wz_all readingList milight/0x5D02/rgb_cct/0:.* { json2nameValue($EVENT) }\
milight/updates/0x5D02/rgb_cct/0:.* { json2nameValue($EVENT) }\
milight/states/0x5D02/rgb_cct/0:.* { json2nameValue($EVENT) }\

attr Licht_Wz_all room Wohnzimmer
attr Licht_Wz_all setList on milight/0x5D02/rgb_cct/0 {"status":"ON"}\
off milight/0x5D02/rgb_cct/0 {"status":"OFF"}\
level milight/0x5D02/rgb_cct/0 {"$EVTPART0":"$EVTPART1"}\
hue:colorpicker,HUE,0,1,359 milight/0x5D02/rgb_cct/0 {"$EVTPART0":"$EVTPART1"}\
command:uzsuSelectRadio,Weiss,Nacht,Mode,Up,Down milight/0x5D02/rgb_cct/0 {"$EVTPART0":"$EVTPART1"}\
brightness:colorpicker,BRI,0,1,255 milight/0x5D02/rgb_cct/0 {"$EVTPART0":"$EVTPART1"}\
next_mode milight/0x5D02/rgb_cct/0 {"$EVTPART0":"$EVTPART1"}\
mode_speed_up milight/0x5D02/rgb_cct/0 {"$EVTPART0":"$EVTPART1"}\
mode_speed_down milight/0x5D02/rgb_cct/0 {"$EVTPART0":"$EVTPART1"}\
saturation:colorpicker,BRI,0,1,100 milight/0x5D02/rgb_cct/0 {"$EVTPART0":"$EVTPART1"}\
color_temp:colorpicker,CT,153,1,370 milight/0x5D02/rgb_cct/0 {"$EVTPART0":"$EVTPART1"}\
device_id milight/0x5D02/rgb_cct/0 {"$EVTPART0":"$EVTPART1"}\
effect milight/0x5D02/rgb_cct/0 {"$EVTPART0":"$EVTPART1"}\
mode milight/0x5D02/rgb_cct/0 {"$EVTPART0":"$EVTPART1"}\
commands milight/0x5D02/rgb_cct/0 {"$EVTPART0":"$EVTPART1"}
attr Licht_Wz_all sortby 1
attr Licht_Wz_all webCmd command:brightness:saturation:color_temp:hue
attr Licht_Wz_all webCmdLabel command\
:brightness:saturation\
:color_temp:hue
==== Ein Leuchtmittel, mehrere Fernbedienungen ====
Pairt man mehrere Fernbedienungen mit einem Leuchtmittel, sollten auch alle entsprechenden Fernbedienungscodes in das readingList-Attribut übernommen werden. Dazu übernimmt man am einfachsten die Einträge aus den zusätzlichen MQTT2_DEVICEs. Benötigt man das zusätzliche Device nicht separat, um z.B. eine getrennte Gruppenschaltung zu realisieren, kann man dieses löschen. Beispiel-readingList für ein Device, das auf zwei Fernbedienungscodes und zwei Gruppen "hört":

attr Licht_Wz_all readingList milight/states/0x1234/rgbw/2:.* {json2nameValue($EVENT) }\
milight/updates/0x1234/rgbw/2:.* { json2nameValue($EVENT) }\
milight/states/0x1234/rgbw/0:.* { json2nameValue($EVENT) }\
milight/updates/0x1234/rgbw/0:.* { json2nameValue($EVENT) }\
milight/states/0xABCD/rgbw/0:.* { json2nameValue($EVENT) }\
milight/updates/0xABCD/rgbw/0:.* { json2nameValue($EVENT) }\
milight/states/0xABCD/rgbw/4:.* { json2nameValue($EVENT) }\
milight/updates/0xABCD/rgbw/4:.* { json2nameValue($EVENT) }

==== Fernbedienung als Input-Device nutzen ====
In diesem {{Link2Forum|Topic=103493|LinkText=Thread}} ist dargestellt, wie man eine Fernbedingung des Typs FUT089 dazu verwenden kann, einen [[MPD]] oder Rollladenaktoren zu steuern, oder diese Fernbedienung für [[Hue#HUE-Device|HUEDevice]]-Leuchtmittel zu nutzen.
Um hier nur Differenz-Meldungen direkt an die betreffende myUtils-Funktion zu übergeben und doppelte Events zu verhindern, sollte hier die readingList so angepasst werden, dass nur Messages aus dem "updates"-Zweig ausgewertet werden:
defmod MiLight_RC1_0 MQTT2_DEVICE milight_0xABCD_0
attr MiLight_RC1_0 readingList milight/states/0xABCD/fut089/[0-8]:.* {}
milight/updates/0xABCD/fut089/0:.* { FHEM::attrT_MiLight_Utils::MPDcontrol('myMPD',$EVENT, 'Yamaha_Main') }\
milight/updates/0x5D47/fut089/1:.* { FHEM::attrT_MiLight_Utils::FUT_to_RGBW('Licht_Stehlampe_links',$EVENT) }\
milight/updates/0x5D47/fut089/2:.* { FHEM::attrT_MiLight_Utils::FUT_to_RGBW('Licht_Stehlampe_rechts',$EVENT) }\
milight/updates/0x5D47/fut089/3:.* { FHEM::attrT_MiLight_Utils::four_Lights_matrix($EVENT, 'Licht_WoZi_Vorn_Aussen', 'Licht_WoZi_Vorn_Mitte', 'Licht_WoZi_Hinten_Aussen', 'Licht_WoZi_Hinten_Mitte') }\
milight/updates/0x5D47/fut089/4:.* { FHEM::attrT_MiLight_Utils::shuttercontrol('Jalousie_WZ',$EVENT) }\
milight/updates/0x5D47/fut089/5:.* { FHEM::attrT_MiLight_Utils::shuttercontrol('Rollladen_WZ_SSO',$EVENT) }\
milight/updates/0x5D47/fut089/6:.* { FHEM::attrT_MiLight_Utils::shuttercontrol('Rollladen_WZ_SSW',$EVENT) }\
milight/updates/0x5D47/fut089/7:.* {}\
milight/updates/0x5D47/fut089/8:.* {}
attr MiLight_RC_WZ stateFormat CommandSet

== eBus ==
An dieser Stelle sollen lediglich die Grundzüge erläutert werden, eine ausführliche Anleitung über die Konfiguration des [[EBUS-MQTT2|eBus mit MQTT2 gibt es hier]].

=== Vorbereitung und Definition am eBus ===
Vorausgesetzt wird ein laufender eBus-Dämon. Dessen Einrichtung wird im Artikel [[EBUS#Software|EBUS]] beschrieben.
In der Konfiguration des Dämons ( /etc/default/ebusd ) ist die Kommunikation über MQTT zu aktivieren und die Topic-Struktur festzulegen, z.B. ''ebusd/%circuit/%name''.
--accesslevel=* --mqttport=1883 --mqttjson --mqtthost=IpAdresseMQTTSERVER --mqtttopic=ebusd/%circuit/%name
{{Hinweis|Nachfolgend wird davon ausgegangen, dass als Vorgabe für mqtttopic ''ebusd'' verwendet wurde. Dies kann geändert werden, es wird aber dringend empfohlen, das mqtttopic in jedem Fall mit ''ebus...'' zu beginnen!}}

=== Vorbereitung und Definition in FHEM ===
Unabhängig von dem konkret genutzten IO-Modul (MQTT2_SERVER oder MQTT2_CLIENT) sollte an diesem '''''vor''''' den nachfolgenden Schritten zunächst das autocreate ausgeschaltet werden. Weiter sollte geprüft werden, ob es bereits MQTT2_DEVICE-Geräte gibt, die Einträge in der ''readingList'' enthalten, die vom ebus stammen. Da wir die ''readingList'' anschließend mit erweiterten JSON-Optionen erstellen wollen, müssen zumindest sämtliche ''readingList''-Attribute entsprechend bereinigt oder gelöscht werden; in der Regel ist es einfacher, diese Geräte nach dem Deaktivieren des autocreate am IO zu löschen.
{{Randnotiz|RNTyp=y|RNText=Sollten Sie MQTT2_CLIENT als IO nutzen, sollte für das weitere Vorgehen eine Kopie des MQTT2-"Sammeldevices" genutzt werden, und dessen ''CID'' auf ''ebusd'' geändert werden. Nach Anwendung des ebusd-splitter-templates müssen dann alle den ebus betreffenden Einträge aus der ''readingList'' des "Sammeldevices" gelöscht werden oder diese ganz gelöscht.}}Ist der ebus-Dämon lauffähig und für MQTT konfiguriert, sendet dieser regelmäßige Messages.

Sind die Vorbereitungen abgeschlossen, aktivieren wir ''autocreate'' wieder, allerdings wählen wir als autocreate-Methode ''complex'' aus, da der eBus-Dämon teilweise<ref>Dies betrifft vorrangig die Statusmeldungen</ref> eine weiter verschachtelte JSON-Struktur zum Versenden der Informationen verwendet als üblich. Danach wird wie bei den anderen o.g. Geräten automatisch ein neues MQTT2_DEVICE angelegt<ref>Bei Verwendung des MQTT2_CLIENT wird dann die ''readingList'' am bereits definierten MQTT2_DEVICE aus der Kopie des "Sammeldevice" automatisch wieder erstellt bzw. gefüllt.</ref>

==== "ebus-Bridge" ====
Auf das von ''autocreate'' erstellte MQTT2_DEVICE wird nunmehr das template ''eBus_daemon_splitter'' angewendet. Nach einiger Zeit sollte sowohl die readingList an diesem Device erweitert worden sein, wie auch ein oder mehrere neue MQTT2_DEVICE-Geräte angelegt.
Dieses Device liefert zukünftig Readings zum Dämon selbst, wie dessen ''uptime'', alle weiteren am eBus angeschlossenen Teilnehmer werden dagegen zweckmäßigerweise durch ein oder mehrere weitere MQTT2_DEVICE-Geräte dargestellt.

Das ''attrTemplate'' läd eine weitere ''attrTemplate''-file und [[99 myUtils anlegen|99_myUtils-Code]] vom FHEM-Server nach. Beides steht dann auch unmittelbar zur Nutzung zur Verfügung.
==== "ebusd_bai" und weitere Geräte ====
{{Hinweis|Der eBus-Dämon sendet nicht alle Informationen zu allen am eBus angeschlossenen Geräte automatisch. Diese müssen teilweise erst aktiv angefragt werden. Wie das im einzelnen erfolgen kann, ist dem o.g. Detailartikel zu entnehmen.}}
Funktioniert die Kommunikation zwischen dem eBus-Dämon und FHEM, sollte nach einigen Minuten zumindest ein weiteres Gerät namens ''MQTT2_ebus_bai'' angelegt worden sein.

== Sonos2Mqtt ==
Aus einem Versuch heraus ist ein {{Link2Forum|Topic=111711|LinkText=kleines Projekt}} geworden: Die Sonos Umgebung mit Hilfe von sonos2mqtt als generisches MQTT2_DEVICE komfortabel in FHEM einzubinden.

Mit Hilfe von ein paar Templates ist die grundlegende Einbindung in FHEM nach einer kleinen Installation auf Systemebene schnell erledigt. Es läuft derzeit noch zahlreiche Entwicklung und Ideenfindung, die Fortschritte sind live im Thread oder [[Sonos2mqtt|konsolidiert im Wiki]] zu finden.

=== Setup im System ===
Für dies Funktion wird der nodejs Server [https://github.com/svrooij/sonos2mqtt sonos2mqtt] benötigt. Entweder installiert man den lokal, irgendwo im Netzwerk oder nutzt den [[MQTT2-Module - Praxisbeispiele#Verwendung des Docker Containers|Docker Container.]]

Der nodejs Server sonos2mqtt kann aus Sicht von FHEM irgendwo im Netzwerk stehen - aber er muss im gleichen Netzwerk wie die Sonosplayer stehen. Das UPNP Sonosnetzwerk funktioniert nicht über Netzwerksegmente hinweg.

Eine Beschreibung aller Startparameter für sonos2mqtt findet man [https://svrooij.github.io/sonos2mqtt in der offiziellen Doku].

Erreicht der nodejs Server sonos2mqtt den MQTT Server nicht über - default: localhost, Port 1883, keine Anmeldung" - muss der Parameter --mqtt gesetzt werden!

Beispiele:
:<code>--mqtt mqtt://myuser:the_secret_password@192.168.0.3:1800</code> # alles gesetzt
:<code>--mqtt mqtt://192.168.0.3:1800</code> # IP Adresse und Port gesetzt, keine Anmeldung am MQTT Server
:<code>--mqtt mqtt://192.168.0.3</code> # IP Adresse gesetzt, Port ist Standard 1883

Erfolgt der Start mit pm2, werden die Parameter mit einem ''zusätzlichen'' doppelten Bindestrich (--) hinter dem nodejs Modul übergeben.

Beispiel:
<syntaxhighlight lang="perl">
pm2 start sonos2mqtt -- --mqtt mqtt://myuser:the_secret_password@192.168.0.3:1800
</syntaxhighlight>

'''Lokales Setup'''

Voraussetzung: nodejs und pm2 ist installiert und für alle Benutzer verfügbar. <syntaxhighlight lang="bash">
sudo npm install -g sonos2mqtt
</syntaxhighlight>
Je nach Entwicklungsstand sind auch Betaversionen verfügbar. Für aktuelle Betaversionen wird dieser Zusatz beim Setup verwendet. -> sonosmqtt@3.1.0-beta.1

Wird der sonos2mqtt Server auf einer anderen Maschine eingerichtet, ist der Start entsprechend diesem Absatz [[MQTT2-Module - Praxisbeispiele#Autostart von sonos2mqtt im System mit pm2 .28Alternative.29|Autostart von Sonos2mqtt im System mit pm2]] einzurichten.

=== Setup in FHEM ===
Man definiert lediglich ein Bridge Device, der Rest wird automatisch erledigt.

Voraussetzung:
* autocreate im System ist aktiv.
* Der verwendete MQTT2_SERVER steht auf '''autocreate simple''' (default/Standard).
* Templates aktuell - FHEM uptodate oder bei Bedarf in der FHEM Kommandozeile aktualisieren:
<pre>
{ Svn_GetFile("FHEM/lib/AttrTemplate/mqtt2.template", "FHEM/lib/AttrTemplate/mqtt2.template", sub(){ AttrTemplate_Initialize() }) }
</pre>
Bei der Anwendung des Templates für die Bridge wird das Attribut devicetopic ausgelesen oder auf default sonos gesetzt!

Wird ein anderer Devicetopic verwendet, muss der bei der Anlage der Bridge gesetzt werden!

Diese Zeilen einzeln in der FHEM Kommandozeile oder als Block in der Raw Definition. <syntaxhighlight lang="perl">
define SonosBridge MQTT2_DEVICE
attr SonosBridge room MQTT2_DEVICE
set SonosBridge attrTemplate sonos2mqtt_bridge_comfort
</syntaxhighlight>
Das Template sonos2mqtt_bridge_comfort:
* setzt das Template sonos2mqtt_bridge auf das Device,
* lädt die Datei 99_sonos2mqttUtils.pm aus dem contrib Ordner nach,
* definiert ein notify, dies erledigt im weiteren Betrieb die automatische Konfiguration der automatisch erzeugten MQTT2_DEVICEs.
** mit dem Template sonos2mqtt_speaker (das Template kann auch manuell auf vorhandene Player angewendet werden, die automatische Erzeugung der Player wird aber empfohlen)
** Ermittelt Detailinformation des jeweiligen Players (vor allem IP Adresse und Modelnumber)
** Lädt die Sonosgeräte Icons von den UPNP Devices herunter
** erweitert das setList input Kommando um den TV Eingang (HDMI, spdif) bzw. Line_IN Eingang falls vorhanden (Modelnumber)
* Die Player werden automatisch einzeln erzeugt wenn sie mqtt Nachrichten senden (Play/Stop) oder (alle sofort) wenn der sonos2mqtt Server gestartet wird.

==== Wozu dient die Bridge? ====
Sie stellt ein paar wesentliche Funktionen zu Verfügung
# Auffangen von nicht benötigten MQTT Nachrichten.
# Erzeugung/Weiterleitung von Nachrichten für die einzelnen Player - damit auch die Erzeugung von separaten Playern nach dem Schema MQTT2_RINCON12345678901234567.
# Statusanzeige sonos2mqtt als Reading connected (0 offline, 1 connected, 2 Player connected).
Sie kann zusätzlich als zentrales Device verwendet werden, um die Sonos Umgebung abzubilden, z.B. Readings für Favoriten u.ä.

==== Start sonos2mqtt lokal ====
Der Start / Stop des sonos2mqtt Servers innerhalb von FHEM ist nur lokal simpel möglich. Ist der Server irgendwo im Netzwerk oder im Docker Container, muss man andere Möglichkeiten finden. Der Neustart aus FHEM ist zwar praktisch, aber nicht erforderlich.

Wird eine existierenden Sonos Landschaft inhaltlich verändert (Player dazu/weg), muss der Server neu gestartet werden. Werden Player temporär abgeschaltet, merkt das der Server nach einer Zeit selbst, oder man forciert dies mit einem CheckSubscription an der Bridge.

Soll das Modul sonos2mqtt mit seinen default Einstellungen gestartet werden, genügt dieser kurze Befehl (in der FHEM Kommandozeile):
<syntaxhighlight lang="bash">
"pm2 start sonos2mqtt"
</syntaxhighlight>
Tipp: Verwendet man anstatt "Befehl" den Syntax {qx(Befehl)} in der FHEM Kommandozeile, wirkt der Befehl zwar blockierend aber die Ausgabe erfolgt im Browser und nicht im Logfile. Mit dem Parameter -s erfolgt keine Ausgabe.

==== Autostart von sonos2mqtt mit FHEM ====
Der Code startet sowohl das sonos2mqtt Modul sofort und implementiert ein notify für den zukünftigen automatischen Start beim Start von FHEM.
<syntaxhighlight lang="perl">
define n_pm2_sonos notify global:INITIALIZED|n_pm2_sonos:start "pm2 -s start sonos2mqtt"
trigger n_pm2_sonos start
</syntaxhighlight>

=== Autostart von sonos2mqtt im System mit pm2 (Alternative) ===
Der obige Code startet das sonos2mqtt nodejs Modul mit pm2 beim Start von FHEM. Sollte das nicht funktionieren oder nicht ins gesamte Konzept passen (weil z.B. mehrere nodejs Module geladen werden) kann der automatische Start direkt im System erfolgen. Zunächst dafür das oben eventuell schon definierte notify löschen!<syntaxhighlight lang="perl">
delete n_pm2_sonos
</syntaxhighlight>Der Start des Modul muss nicht mit erhöhten Rechten geschehen! Im Terminal folgendes eingeben (unter dem angemeldeten Benutzer wird sonos2mqtt später immer gestartet):<syntaxhighlight lang="bash">
pm2 start sonos2mqtt
pm2 startup
</syntaxhighlight>
Der letzte Befehl "redet", d.h. es gibt eine Ausgabe in der Art:
<syntaxhighlight lang="bash">
[PM2] To setup the Startup Script, copy/paste the following command:
sudo env PATH=$PATH:/usr/bin /usr/lib/node_modules/pm2/bin/pm2 startup systemd -u pi --hp /home/pi
</syntaxhighlight>
Man tut einfach genau das, was dasteht: die letzte Zeile kopieren und wieder einfügen und ausführen. Danach muss man die Konfiguration von pm2 noch sichern:
<syntaxhighlight lang="bash">
pm2 save
</syntaxhighlight>

=== Verwendung des Docker Containers ===
Ergänzend zur [https://svrooij.io/sonos2mqtt/getting-started.html#run-sonos2mqtt-in-docker Original Doku:]

Beim Container findet die Konfiguration der Verbindung zum FHEM in den Environment Variablen statt:
<syntaxhighlight lang="perl">
environment:
- SONOS2MQTT_DEVICE=192.168.56.207 # hier muss einer der Sonos Lautsprecher stehen
- SONOS2MQTT_MQTT=mqtt://192.168.56.121:1883 # mqtt2_server FHEM, erweiterter Syntax siehe oben
- SONOS_LISTENER_HOST=192.168.56.121 # Docker host IP
</syntaxhighlight>

=== Sonos2mqtt mit mehr Komfort ===
Im Wiki Artikel [[Sonos2mqtt]] geht es weiter.

== Owntracks GPS Tracking in FHEM über MQTT - Cloud ==
Das hier gezeiget Beispiel verwendet eine MQTT Instanz im Internet, die mit einem MQTT2_CLIENT angebunden wird. Da wenig Traffic benötigt wird, genügt z.B. eine kostenfreie Instanz z.B. bei myqtthub (Stand. Dezember 2020)

Alternativ kann man einen MQTT2_SERVER auch direkt verfügbar machen, wenn man sich sicher ist was man da tut! Siehe {{Link2Forum|Topic=99666|Message=1028576|LinkText=diesen Forenbeitrag}}. Das Bridge Device wird dabei genau so benötigt, nur der IODev ist dann der MQTT2_SERVER.

=== owntracks auf dem Smartphone konfigurieren ===
Menü / Einstellung / Verbindung

Dort sind insgesamt 4 Registerkarten mit Werten zu füllen (Beispiel):
* Modus -> MQTT
* Hostname ->
** Hostnamen: host.cloud.com
** Port: 8883
** ClientID: ID vom Provider
** WebSockets (nicht nutzen)
* Identifikation ->
** Benutzername: user-name
** Passwort: user-password
** GeräteID: mi6 (erscheint in FHEM im Device Namen verwendet)
** TrackerID: hk (nur zweistellig, erscheint als ID in der owntracks Karte)
* Sicherheit ->
** TLS aktivieren
=== Definition in FHEM ===
Der MQTT2_CLIENT wird so eingerichtet, man braucht eine andere ClientID als auf dem Smartphone! Stimmt alles sollte das Gerät sofort open anzeigen.<syntaxhighlight lang="perl">
MQTT2_CLIENT einrichten, autocreate simpel
define mqtt2Cloud MQTT2_CLIENT host.cloud.com:8883
attr mqtt2Cloud SSL 1
attr mqtt2Cloud autocreate simple
attr mqtt2Cloud clientId fhem1
attr mqtt2Cloud room MQTT2_IO
attr mqtt2Cloud username user-name
set mqtt2Cloud password user-password
</syntaxhighlight>Für die automatische Erzeugung der Trackergeräte in FHEM richtig man zuerst ein Bridge Device ein:<syntaxhighlight lang="perl">
define MQTT2_Cloud_bridge MQTT2_DEVICE
attr MQTT2_Cloud_bridge IODev mqtt2Cloud
attr MQTT2_Cloud_bridge autocreate 1
attr MQTT2_Cloud_bridge room MQTT2_DEVICE
</syntaxhighlight>Dies wird entweder mit dem Template allgemein konfiguriert<syntaxhighlight lang="perl">
set MQTT2_Cloud_bridge attrTemplate MQTT2_CLIENT_general_bridge
</syntaxhighlight>oder manuell nur für owntracks eingerichtet<syntaxhighlight lang="perl">
attr MQTT2_Cloud_bridge bridgeRegexp owntracks/[^/]+/([^/:]+).* "owntracks_$1"
</syntaxhighlight>MQTT2 Geräte für owntracks werden jetzt automatisch mit dem Namen MQTT2_owntracks_<GeräteID> erzeugt. Diese werden einfach mit dem Template owntracks_device fertig konfiguriert. Bei einem IOS Gerät kann man danach noch das Template owntracks_device_IOS als Erweiterung anwenden.

==== Anwesenheitserkennung ====
Die Anwesenheit kann im owntracks Device direkt für die selbst definierten Plätze abgelesen werden: entweder steht im reading place der jeweilige Ort oder away. Um hier noch eine gewisse Einheitlichkeit in der Verwendung zu bekommen kann man ein PRESENCE Device verwenden: <syntaxhighlight lang="perl">
define OT_Mi6 PRESENCE event MQTT2_owntracks_mi6:place:.away MQTT2_owntracks_mi6:place:.<Home>
</syntaxhighlight>Im Move Modus erfolgt die Erkennung sehr schnell und damit einige Sekunden eher als eine BT Erkennung im Haus - der Akkuverbrauch steigt enorm. Im Significant Modus kann es schon mal ein paar Minuten dauern - ein relevanter Akku Verbrauch ist nicht erkennbar.

== Owntracks GPS Tracking in FHEM direkt an den eigenen Fhem-Server ==
Dieses Beispiel beschreibt den direkten MQTT2 Zugang wobei das IODev dann der MQTT2_SERVER ist. Hierzu bitte {{Link2Forum|Topic=99666|Message=1028576|LinkText=diesen Forenbeitrag}} lesen.

=== SSL - Zertifikate fuer fhem erstellen. ===
Zunächst erstellen wir fuer den MQTT - Server CA zertifizierte SSL Zertifikate. Diese sind identisch mit den SSL - Zertifikaten, welche man evtl. schon fuer den SSL - Zugang seines FHEMWEB - Device erstellt hat.

Hat man den FHEMWEB schon mit eiem SSL Zertifikat (http'''<u>s</u>'''://) abgesichert, muss man daraus nur noch den .p12 - Container erstellen.

Hat man den FHEMWEB noch nicht abgesichert (http://), dann wir es höchste Zeit!

Für die Erstellung dieser SSL Zertifikate folgt dem Wiki-Beitrag [[FHEM mit HTTPS SSL-Zertifikat und eine eigene Zertifizierungsstelle]].

Die darin beschriebenen Dateien, das cacert.pem sowie den server.p12 - Container müsst ihr nun an euer Mobiltelefon senden.

=== Definition in FHEM ===
Der MQTT2_Server wird wie folgt eingerichtet.<syntaxhighlight lang="perl">
define myMQTT2Server_extern MQTT2_SERVER IPV6:1884 global
attr MQTTBroker_extern SSL 1
attr MQTTBroker_extern autocreate complex
attr MQTTBroker_extern event-on-change-reading .*
attr MQTTBroker_extern group MQTT2
attr MQTTBroker_extern icon mqtt_broker
attr MQTTBroker_extern room MQTT2
</syntaxhighlight>

Der MQTT2_Server wird zusätzlich über "allowed" abgesichert:<syntaxhighlight lang="perl">
define allowed_MQTT2Server_extern allowed
attr allowed_MQTT2Server_extern DbLogExclude .*
attr allowed_MQTT2Server_extern group MQTT2
attr allowed_MQTT2Server_extern room MQTT2
attr allowed_MQTT2Server_extern validFor myMQTT2Server_extern
</syntaxhighlight>Jetzt vergeben wir noch einen Usernamen und ein Passwort für dieses "allowed" - Device<syntaxhighlight lang="perl">
set allowed_MQTT2Server_extern basicAuth MyMQTT2Username MyMQTT2Password

</syntaxhighlight>Denkt bitte daran einen eigenen Usernamen und ein eigenes langes, kompliziertes Passwort zu verwenden. Vorsicht bei Sonderzeichen!

=== Port-Freigaben im Router ===
An dieser Stelle müssen wir den Port 1884 in den Internet - Freigaben eures Routers freigeben.

Bei der Fritz!Box wird dies beispielsweise unter Internet -> Freigaben -> Port-Freigaben gemacht. Die Details hierzu entnehmt bitte der Bedienungsanleitung eures Routers.

Wichtig ist dabei, das ihr das Protokol "TCP" verwendet und der Port 1884 extern nach Port 1884 intern an die IP - Adresse des jeweiligen fhem-Servers übermittelt wird.

=== owntracks auf dem Smartphone konfigurieren ===
Menü / Einstellung / Verbindung

Dort sind insgesamt 4 Registerkarten mit Werten zu füllen (Beispiel):
* Modus -> MQTT
* Hostname ->
** Hostnamen: subdomain.dyndns.com
** Port: 1884
** ClientID: Vorname_Nachname
** WebSockets (nicht nutzen)
* Identifikation ->
** Benutzername: MyMQTT2Username
** Passwort: MyMQTT2Password
** GeräteID: mi6 (erscheint in FHEM im Device Namen verwendet)
** TrackerID: hk (nur zweistellig, erscheint als ID in der owntracks Karte. Empfehlung: Die Initialien verwenden.)
* Sicherheit ->
** TLS aktivieren
** CA-Zertifikat: cacert.pem
** Client-Zertifikat: server.p12
** Passwort fuer Client-Zertifikat: Passwort für den server.p12 - Container

Wenn alles richtig gemacht wurde, dann erstellt das myMQTT2Server_extern - Device automatisch ein neues Device für jede owntracks-App, die sich an dem myMQTT2Server_extern - Device meldet.

Übrigens: Will man seine gesamte Familie ebenfalls über owntracks tracken, so muss man in den jeweiligen APPs nur die Werte für ClientID, GeräteID und TrackerID individuell gestalten.

An den fhem- Einstellungen müssen keine weiteren Änderungen vorgenommen werden.
== Allgemeine Hinweise ==
=== MQTT2_SERVER und MQTT2_CLIENT für Debugging nutzen ===
Nutzt man das rawEvents-Attribut am MQTT2-IO<ref>z.B. <code>attr MQTT2_FHEM_Server rawEvents .*</code>, der regex-Filter kann wie üblich angepasst werden</ref>, kann man den Datenverkehr des Servers am Event-Monitor mitschneiden. Dies ist insbesondere für unbekannte Geräte nützlich, deren Topic- und Payload-Struktur noch nicht bekannt ist.
Um den kompletten MQTT Datenaustausch mitzuschneiden, kann man mit <code>attr mqtt2_server verbose 5</code> auch alles ins FHEM-Log schreiben lassen.

=== autocreate funktioniert anscheinend nicht? ===
In der Regel wird bei neu eingehenden MQTT-Messages über ''autocreate'' ein neues Device erstellt, wenn Nachrichten von einem bisher unbekannten Gerät kommen. Geschieht dies nicht, sollten folgende Punkte geprüft werden:
# (nur bei MQTT2_SERVER:) Der Client muss eine ClientID angeben, diese darf nicht den defaults von ''mosquito_sub'' entsprechen.
# Ein allgemeines {{Link2CmdRef|Anker=autocreate|Lang=en|Label=autocreate}}-Device (''TYPE=autocreate'') muss vorhanden und aktiv sein.
# ''autocreate'' am IO muss eingeschaltet sein, was für MQTT2_SERVER bedeutet, dass es nicht auf "0" stehen darf (hier ist dann ''simple'' die aktive Voreinstellung), für MQTT2_CLIENT sollte ebenfalls ''simple'' verwendet werden; dies muss hier allerdings explizit gesetzt werden.

Wird dann immer noch kein Device erstellt, gibt es in aller Regel ein Device, das bereits einen entsprechenden Eintrag in der readingList enthält, oder es sind keine Nachrichten eingegangen. Überprüfen Sie daher dann ggf. die Einstellungen am Client-Gerät (z.B. im Web-Interface des Shelly oder Tasmota-geflashten ESP8266).

Das ''autocreate'' am Device schließlich bestimmt, ob die ''readingsList'' erweitert werden darf, wenn Informationen über bisher nicht über die readingList abgedeckte Topics empfangen werden und vom MQTT2-IO als zu diesem Device/ClientID gehörend identifiziert wurden.

=== attrTemplate ===
{{Randnotiz|RNTyp=Info|RNText=Die per attrTemplate jeweils erzeugten Konfigurationen sind Einrichtungsbeispiele, die v.a. eine in sich konsistenze Zusammenstellung der verschiedenen Attribute enthalten. Es steht jedem User frei, diese Ausgangsbasis dann nach seinem Belieben zu ändern. Spätere Änderungen des verwendeten attrTemplate wirken sich nicht automatisch auf die durch frühere Versionen oder den User nachkonfigurierte Geräte aus! Da es vorkommen kann, dass sich die per MQTT übermittelten Daten und Topics ändern, wenn z.B. eine firmware aktualisiert wurden, kann dies Anpassungen am jeweiligen Template erforderlich machen. Grundsätzlich sollen die per attrTemplate für MQTT2_DEVICE verfügbaren attrTemplate jeweils für die aktuellste verfügbare stabile firmware-Version passen.}}
Zur Konfiguration von MQTT2_DEVICE-Geräten kann die Funktion ''[[AttrTemplate|attrTemplate]]'' genutzt werden.
Die Anwendung für MQTT2_DEVICE ist [[MQTT2 DEVICE#attrTemplate|hier]] beschrieben.

{{Hinweis|In einigen Fällen kann es vorkommen, dass die template-Bezeichnung zwischenzeitlich geändert wurde. Seit 21.09.2019 erfolgt die Sortierung der auswählbaren templates nicht mehr nur nach den Namen, so dass die entsprechenden Namensbestandteile entfallen sind, die einer besseren Sortierung dienten.}}

=== attrTemplate: Es werden nicht alle templates angezeigt ===
Siehe Beitrag [[AttrTemplate#Warum finde ich das Template xyz nicht.3F|AttrTemplate: Warum finde ich das Template xyz nicht.]]

=== attrTemplate und Sprachsteuerung ===
Konfiguriert man MQTT2_DEVICE-Geräte mit attrTemplate, werden in der Regel auch direkt die für die Sprachsteuerung der Geräte erforderlichen Attribute mit gesetzt. Weiterführende Hinweise sind auch zu diesem Teilaspekt von ''[[AttrTemplate|attrTemplate]]'' dem betreffenden Hauptartikel zu entnehmen.

=== bridgeRegexp ===
[[Datei:Mqtt2 server.png|300px|thumb|left|Logische Verortung der bridgeRegexp-Angaben]]{{Randnotiz|RNTyp=y|RNText=Beachten Sie, dass aufgrund des geschilderten Prinzips eine Änderung einer bridgeRegexp bei einem Gerät auch dazu führt, dass alle Readings eines Geräts und alle readingList-Einträge gelöscht werden.}}Üblicherweise werden alle Informationen, die aus einer Quelle stammen auch '''''einem''''' ''MQTT2_DEVICE'' zugeordnet, wobei im Falle des dort nicht aktivierten autocreate-Attributs entsprechende readingList-Einträge erzeugt werden. In dem nebenstehenden Schaubild wären dies die Geräte ''A'' bis ''D''. Das '''Attribut''' ''bridgeRegexp'' kann dazu genutzt werden, um neue, bisher unbekannte Topic-Strukturen im Rahmen des autocreate-Vorgangs anders zu strukturieren. Diese werden dabei im Ergebnis einem '''anderen Device''' (das ggf. erst erstellt wird) zugeschlagen, sollte eine zu der topic-Struktur passende regex in diesem Attribut gesetzt sein. Für dessen CID und die Bildung des Names wird die im 2. Teil jedes Eintrags als ''newClientId'' hinterlegte Angabe verwendet. In nebenstehendem Schaubild ist dies exemplarisch für die Gerätegruppe ''D'' mit dem ''bridge''-Device ''D'' und dessen ''Satelliten'' ''D1'' bis ''D4'' dargestellt.
Dementsprechend sind in den hier aufgeführten Beispielen ''bridgeRegexp''-Attribute immer dort zu finden, wo ein Gerät oder Dienst dazu dient, mit weiteren, ggf. auf andere Weise kommunizierende Geräte oder Baugruppen zu kommunizieren, wie z.B. für über hier dargestellten ''zigbee2mqtt'' oder ''zigbee2tasmota''. Ein Sonderfall hierbei ist das template ''MQTT2_CLIENT_general_bridge'' zur Verwendung mit dem [[MQTT2_CLIENT#Anwendung|MQTT2_CLIENT]], denn aus dessen Sicht stammen alle Informationen aus derselben Quelle, nämlich z.B. dem ''mosquitto''-Server und würden sonst alle ein und demselben MQTT2_DEVICE zugewiesen.

=== Ständig neue Devices? ===
MQTT2_SERVER kann zwischen verschiedenen Geräten auch anhand der ClientID unterscheiden. Für jedes neu erkannte Gerät wird auch ein eigenes MQTT2_DEVICE angelegt. Abhilfemaßnahmen:
==== Vergabe einer ClientID ====
Die meisten MQTT-fähigen Geräte enthalten Optionen zur Vergabe einer eindeutigen ClientID (siehe das Beispiel des zigbee2mqtt-Dienstes oben).
Wird keine ClientID vergeben, verwenden manche Clients für jede Verbindung wieder neue ID's. Es wird empfohlen, möglichst von diesen Einstelloptionen Gebrauch zu machen.

==== Löschen der ClientID aus der readingList usw. ====
Ist dies nicht möglich oder erwünscht, kann man auch die ClientID aus den readingList-, setList- und getList-Attributen entfernen. Dies ist jedenfalls solange unschädlich als nicht mehrere Geräte identische Topic-Pfade verwenden (daher die Empfehlung, insbesondere bei Tasmota-Geräten den ''default'' "sonoff" zu ändern).
Beispielsweise wäre <code>attr Milight_Bridge readingList milight_hub_1370325:milight/LWT:.* {json2nameValue($EVENT) }</code> zu ändern in <code>attr Milight_Bridge readingList milight/LWT:.* {json2nameValue($EVENT) }</code>
Die über ''attrTemplate'' verfügbaren Konfigurationen verwenden in der Regel keine ClientID's bzw. entfernen diese.

=== Wildcards in readingList und setList ===
Auch in readingList und in setList sollten sich sog. wildcards verwenden lassen. Die Vorgehensweise ist jedoch unterschiedlich:

In ''readingList'' werden normale regex-Ausdrücke verwendet. Ein Punkt steht daher z.B. für ein beliebiges Zeichen, alles zwischen zwei Topic-Tree-Elementen (getrennt typischerweise durch einen "/") kann man so schreiben: "[^/]+" (entspricht: "Mindestens ein Zeichen, das kein Schrägstrich ist"). Ergänzender Hinweis: Will man z.B. Informationen aus einem beliebigen Teil des Topic-trees extrahieren und als Reading-Namen verwenden, kann dies im Rahmen eines Perl-Aufrufs geschehen. Beispiele aus der mqtt2.template-file: OpenMQTTGateway_BT_scanner und OpenMQTTGateway_BT_gtag (letzteres überführt die Information, über welches Gateway bestimmte Informationen eingegangen ist jeweils in eigene Readings pro Gateway).

In ''setList'' gelten dagegen die wildcard-Konventionen aus der MQTT-Welt. Dort steht "+" für einen austauschbaren Teil des Topic-Trees (zwischen zwei Schrägstrichen). Anmerkung: Bitte vorher prüfen, ob es wirklich sinnvoll ist, derart unspezifische Publishes vorzunehmen. Meist gibt es "Gruppen-Topics", auf die mehrere Geräte eines bestimmten Typs hören bzw. man kann dies dort (in der firmware bzw. auf den Konfigurationsseiten der Geräte) einstellen.

=== Die JSON-Daten sollen ausnahmsweise nicht ausgepackt werden ===
In manchen Fällen ist das automatische Auspacken der JSON-Payload nicht erwünscht. In diesen Fällen kann man einfach den gewünschten Reading-Namen in die readingList eintragen, statt der Anweisung, den JSON an json2NameValue() zu übergeben. Aus
<pre>
attr MQTT_OwnTracks readingList owntracks/clouduser/mi6:.* { json2nameValue($EVENT) }\
owntracks/clouduser/mi6/waypoints:.* { json2nameValue($EVENT) }\
owntracks/clouduser/mi6/event:.* { json2nameValue($EVENT) }
</pre>
wird dann:
<pre>
attr MQTT_OwnTracks readingList owntracks/clouduser/mi6:.* json_mi6\
owntracks/clouduser/mi6/waypoints:.* json_waypoints\
owntracks/clouduser/mi6/event:.* json_event
</pre>
Erforderlichenfalls kann man die Einträge auch doppelt erstellen, um sowohl den JSON wie auch die ausgepackten Readings zu erhalten.

=== Die JSON-Daten vor dem auspacken manipulieren ===
Aus diversen Gründen kann es zweckmäßig sein, einen bestimmten Wert der JSON-Payload zu ignorieren.
Z.B. sendet ein Client statt eines Messwertes die Info "bad". Dieser Fehlerwert soll aus der JSON-Payload "ausgefiltert" werden:
<pre>
attr DEVICE readingList <your topic>:.* { my $rets = json2nameValue($EVENT,'',$JSONMAP);; my %cleaned = map { $_,$rets->{$_} } grep { 'bad' ne $rets->{$_} } keys %{$rets};; return \%cleaned }
</pre>
Numerische Werte zuvor runden :
<pre>
attr DEVICE readingList <your topic>:.* { my $h=json2nameValue($EVENT,'XXX');; map { $h->{$_}=round($h->{$_}) if(looks_like_number($h->{$_})) } keys %{$h};; $h }
</pre>

==== Einfache Payload ====
Einen Wert mappen:
<pre>
attr DEVICE readingList <your topic>:.* {my %map=(0=>'SofortLaden',1=>'MinPV',2=>'NurPV',3=>'Stop',4=>'Standby');; return {ChargeMode=>$h{$EVENT}||$EVENT}}
</pre>

=== Unnötige Konfigurationsinformationen verwerfen ===
Siehe Einleitung und den [[MQTT2_CLIENT#ignoreRegexp|ignoreRegexp-Abschnitt zu MQTT2_CLIENT]].

=== Weiterführende Themen ===
==== Verbinden mehrerer FHEM-Instanzen über MQTT ====
Wie im Hauptartikel zu [[MQTT#Kommunikation zu sonstigen FHEM-Geräten über MQTT|MQTT]] erläutert, gibt es mehrere Varianten, wie man mit Hilfe von FHEM aus Events an beliebigen Geräten MQTT-Messages erzeugen kann. So kann man z.B. Messdaten eines Systems über ein ''notify'' iVm. einer einfachen ''publish''-Anweisung an ein zweites FHEM schicken, das diese Daten dann z.B. mit Hilfe der MQTT2-Module auswerten kann.
Damit dabei Nachrichten unterschiedlicher Quellen auch als getrennte Readings bzw. ggf. auch gesonderten MQTT2_DEVICE-Instanzen zugeordnet werden, sollte man entsprechende Topic-Strukturen wählen, die dann auch mit Hilfe einer geeigneten ''bridgeRegexp'' automatisiert ausgewertet werden kann, siehe z.B. dieser {{Link2Forum|Topic=107145|LinkText=Forumsthread}}:
attr MQTT2_myMqttServer bridgeRegexp \
SmartHome/MqttGenericBridge2/([A-Za-z0-9]*)/.*:.* "mgb2_$1"
Dabei werden die betreffenden Informationen der entfernten FHEM-Instanz alle nach dem Schema ''SmartHome/MqttGenericBridge2/<Device-Name>/<Reading-Name>'' versendet.

==== Umstellung von MQTT_DEVICE (und Derivaten wie XiaomiMQTTDevice) zu MQTT2_DEVICE ====
Wer beabsichtigt, von der Implementierung MQTT+MQTT_DEVICE zu MQTT2-IO und MQTT2_DEVICE zu wechseln, sollte einige Punkte beachten. Viele diesbezügliche Fragen sind vor allem in {{Link2Forum|Topic=103762|LinkText=diesem Foren-Thread}}

näher erläutert.

== Links ==
* {{Link2Forum|Topic=91394|LinkText=Thread, aus dem diese Anleitung ursprünglich entstanden ist}}
* {{Link2Forum|Topic=91807|LinkText=Thread zum Tasmota-Device}}
* {{Link2Forum|Topic=97989|LinkText=Thread, aus dem diese Anleitung für den eBus ursprünglich entstanden ist}}
* {{Link2Forum|Topic=94495|LinkText=Neue templates einreichen}}
* {{Link2Forum|Topic=94494|LinkText=Fragen, Wünsche und Kritik zu mqtt2.template}}
* {{Link2Forum|Topic=116162|LinkText=Der MQTT-Workshop für MQTT2-Module}}

== Hinweise ==
<references />
[[Kategorie:HOWTOS]]
[[Kategorie:MQTT]]
[[Kategorie:IP Components|IP Komponenten]]
[[Kategorie:Other Components]]
[[Kategorie:Interfaces]]

Trick der Woche

2025-08-18T11:13:03Z

TomLee: /* FTUI(3) Dateien direkt in FHEMWEB bearbeiten */

Diese Seite enthält Tipps und Tricks, die zu unbedeutend sind, einen eigenen Artikel zu rechtfertigen, alternative Schreibweisen/Lösungen für eine Problem darstellen, Ungenauigkeiten oder unklare Formulierungen in den offiziellen Dokumenten ergänzen und ähnliches. Jeder Eintrag ist typischerweise sehr kurz (wenige Zeilen lang) und beleuchtet vielleicht nur einen Aspekt von FHEM, er kann allgemeiner Natur sein, oder sich auf ein spezielles Gerät oder einen speziellen Anwendungsfall beziehen.

== August 2025==
=== FTUI(3) Dateien direkt in FHEMWEB bearbeiten ===
Im Attribut editFileList der [https://fhem.de/commandref_modular.html#FHEMWEB FHEMWEB]-Definition '''zusätzlich zu den Default-Werten''' eintragen:
FTUI (www/tablet):$FW_dir.'/tablet':^.*html$
FTUI3 (www/ftui)<code>:$FW_dir.'/tablet':^.*\.(html|htm|js|css)$</code>

== August 2022==
=== Update ===
Wenn der Befehl "Update" nicht funktioniert und insbesondere die Fehlermeldung ''Bad hostname 'fhem.de:80''' zurück gibt, kann es sinnvoll sein, den Parameter -noSSL zu versuchen. Details dazu im Artikel [[Update]]

== Januar 2022==
=== günstiger Luftfeuchtesensor ===
Der [[HM-CC-TC Funk-Wandthermostat]] ist schon lange abgekündigt. Er wird derzeit oft recht günstig im Netz angeboten und eignet sich daher als billiger "StandAlone" Temperatur- und Luftfeuchtesensor, auch wenn er keinen Ventielantrieb steuern soll.

== Dezember 2020 ==
=== Performance von Notifys ===
Im Tipp vom Dezember 2013 [[Trick der Woche#notify durch mehrere Ereignisse auslösen lassen|notify durch mehrere Ereignisse auslösen lassen]] heisst es:
:''[…] Wenn man aber möchte, dass z.B. "on" und "off" auslöst (um etwa Dim-Befehle auszuschliessen), kann dies wie folgt erreicht werden:''
::<code>define irgendwas notify MeinSchalter:(on|off) …</code>
Performanter ist allerdings:
:<code>define irgendwas notify MeinSchalter:o[nf]+ …</code>
wobei '''o[nf]+''' eine "Regexp" für beliebige Zeichenketten ist, die mit '''o''' anfangen und '''n''' und/oder '''f''' enthalten, also (auch) on und off.

Alternativ kann auch:
:<code>define irgendwas notify MeinSchalter:on|MeinSchalter:off … </code>
verwendet werden.
Die letzten beiden Varianten sparen Ausführungszeit. Ganz allgemein ist es besser, im notify das Suchmuster mit einem [[Regulärer Ausdruck|regulären Ausdruck]] (Regexp) eng zu definieren.

:<code>define irgendwas notify MeinSchalter:on ... </code>
ist performanter als
:<code>define irgendwas notify MeinSchalter { if ($EVENT eq "on" ... </code>
auch wenn das Ergebnis gleich ist.

Allerdings ist
:<code>define irgendwas notify MeinSchalter:on ... </code>
:<code>define irgendwas1 notify MeinSchalter:off ... </code>
langsamer als
:<code>define irgendwas notify MeinSchaltero[nf]+ { if ($EVENT eq "on" ) { fhem( ) } else { fhem("... </code>

Die oben erwähnten "if" sind "perl if"s. Die Verwendung des FHEM Modul DOIF ist deutlich langsamer. Die Betrachtung betrifft sowieso nur langsame Host-Systeme mit gleichzeitig vielen defines. Bei Verwendung z.b. einen Raspberry Pi 4 oder schnellerem Host dürften die Unterschiede vernachlässigbar sein.

== Oktober 2020 ==
=== Entprellen ===
Will man ein notify innerhalb eines bestimmten Zeitraumes nur einmal auslösen lassen, auch wenn er in diesem Zeitraum mehrfach getriggered werden sollte, so bietet sich das [[Attribut]] '''disabledAfterTrigger''' an:
:<code>attr <notify_device> disabledAfterTrigger <Anzahl Sekunden></code>.

== Oktober 2019 ==
=== Funkstörungen durch leere Batterien ===
Unerklärliche Funkstörungen besonders im SlowRF Bereich (z.b. FS20) mit stark verminderter Reichweite von CULs, gestörter [[RFR CUL]] Kommunikation etc. gestörtem Empfang von Funktelegrammen aller Art können ihre Ursache darin haben, dass einige Geräte mit (fast) leeren Batterien unkontrolliert senden und dadurch den Kanal mit Störsignalen verschmutzen. Anfällig sind insbesondere ältere FHT Fenstersensoren wie der [[FHT80TF]], die mit fast leeren Batterien eine Art Rauschen aussenden und damit die '''komplette''' FS20 Kommunikation lahmlegen können, Störungen beeinflussen auch andere Funkprotokolle im selben Frequenzbereich, wie z.b. HM.
Also im Falle unerklärlicher und weitreicher Funkstörungen die Batterien aller Geräte überprüfen.

== Februar 2019 ==
=== Unterräume anlegen ===
[[Datei:Unterraeume.png|350px|thumb|right|Beispiel für einen gegliederten Raum "Steuerung"]]
In [[FHEMWEB]] besteht neben der Möglichkeit, Geräte dadurch übersichtlich anzuordnen, indem diese Gruppen und einfachen Räumen zugeordnet werden, auch die Möglichkeit, Räume weiter zu gliedern und Unterräume zu verwenden. Dazu wird nach der Angabe des Hauptraums der Unterraum, getrennt durch ein "->" angegeben. Beispiele:
attr <DEVICENAME> room Steuerung->Logik
attr <DEVICENAME> room Steuerung->Heizung
'''Hinweis''': Legt man zusätzlich einen Raum ''Steuerung'' an, erscheint dieser als zusätzlicher Eintrag in der Raumliste.

== Januar 2019 ==
=== HomeMatic IP ===
Das [[HomeMatic IP]]-Protokoll unterscheidet sich deutlich vom bisherigen HomeMatic Protokoll, im Grunde ist es ein anderes System, das nur dem Namen nach dem älteren HomeMatic gleicht. HM-IP Geräte können aktuell (Anfang 2019) nur über eine systemeigene Zentrale CCU2 (als physisch vorhandenes Interface) und die HomeMatic-Module in FHEM integriert werden, sind in FHEM jedoch '''nicht''' unmittelbar als Homematic-Geräte ansprechbar.

== Dezember 2018 ==
===HomeMatic Heizungsregler Uhrzeit einstellen===
HomeMatic Thermostate / Heizungsregler wie der HM-CC-TC der der HM-TC-IT-WM-W-EU etc. synchronisieren ihre Uhrzeit täglich etwa gegen Mitternacht mit der Zentrale. Man kann dieses Update aber jederzeit erzingen durch den Befehl
set <DEVICENAME> sysTime

== November 2018 ==
===HomeMatic Heizunggeräte gebraucht gekauft===
HomeMatic Heizunggeräte gebraucht gekauft und jetzt lassen sie sich nicht richtig peeren oder pairen?
Das Problem ist meistens, dass die Geräte noch mit der Zentrale des Verkäufers gepairt oder mit anderen Geräten gepeert sind.
Mit Thermostaten wie der [[HM-CC-TC Funk-Wandthermostat]] oder der Nachfolger [[HM-TC-IT-WM-W-EU Funk-Wandthermostat AP]] können mit Ventilantrieben wie dem [[HM-CC-VD Funk-Stellantrieb]] nur gepeert werden, wenn
* die Thermostaten nicht selbst schon mit einer Zentrale (im FHEM Umfeld also z.b. einer [[Virtueller Controller VCCU]] oder [[HM-[[HM-CFG-LAN LAN Konfigurations-Adapter]] oder ähnliches) gepairt wurden
* die Ventilantriebe nicht selbst mit einer Zentrale gepairt oder mit einem Thermostaten gepeert wurden.

Es ist daher sinnvoll zuerst alle Geräte zurückzusetzen, da viele Verkäufer dies vergessen. Wie das geht steht in der Anleitung.
Beispiele:
* HM-CC-TC -> MENU lange drücken, dann Sonderfunktion "RES" anwählen, mit OK-Taste bestätigen
* HM-CC-VD -> Anlernknopf 10 Sekunden lang drücken. Der Antrieb geht in Zustand A2, nachdem er das Ventil 1x auf- und zugefahren hat geht er in A3, Knopf nochmals drücken.
* HM-TC-IT-WM-W-EU -> Batterien entfernen, alle 3 Tasten gedrückt halten, Batterien einlegen, warten bis "rES" im Display erscheint, Tasten loslassen

== Januar 2018 ==
=== at absolutem Datum ===
Vielen ist nicht klar, dass man mit dem "define … at" auch einfach ein absolutes Datum definieren kann (obwohl es in der Commandref steht). Anstatt umfangreicher DOIF Konstrukte oder "define … at" die täglich ablaufen und testen ob der gewünschte Tag schon erreicht ist, geht auch ein einfaches:

define Licht_Neujahr_2019 at 2019-01-03T06:01:01 set Licht1 on

Allgemein:
define <name> at [<datespec>] <command>
wobei <datespec> = (YYYY-MM-DDTHH:MM:SS) (also in ISO8601 Schreibweise).
Wichtig ist die Angabe mit Sekunden, die nicht weggelassen werden können.

== Dezember 2017 ==
=== perl Version ===
Gelegentlich taucht die Frage auf, welche perl Version zum Betrieb von FHEM minimal erforderlich ist. Bedauerlicherweise lässt sich das aber aktuell nicht definitiv bestimmen.
Rudolf König testet zur Zeit (Ende 2017) mit v5.16 (5 Jahre alt) und v5.24 (ca. 1 Jahr alt).
Sollte sich herausstellen, dass eines seiner Module (vor allem fhem.pl selbst) nicht mit der jeweils ''aktuellen'' perl Version funktioniert, so wird das Modul entsprechend kompatibel gemacht.
Andererseits verwendet Rudolf König nach eigener Aussage (bewusst) keine Features, die eine höhere Version als perl 5.8.3 (immerhin älter als 13 Jahre) voraussetzen. Tatsächlich zeigen aktuelle Installation auf relativ alten BuffaloLinkstation Systemen, dass FEHM mit perl 5.8.3 prinzipiell lauffähig ist.

Rudolf König prüft als Maintainer von fhem.pl aber nicht, welche Mindestversionen andere Entwickler in Ihren Modulen benötigen. Es ist daher möglich oder sogar wahrscheinlich, das einzelne Module höhere Versionen als 5.8.3 benötigen.

Es gibt aktuell keinen Weg, die Mindestanforderungen z.b. automatisiert zu ermitteln.

== November 2017 ==
=== Grundlastmodul ===
Mit einem Grundlastmodul ist es möglich, LED Leuchtmittel an einem Schaltaktor / Dimmer zu betreiben. Dies ist bei manchen nicht möglich, da einige LEDs nachglimmen oder flackern. Das Grundlastmodul, welches parallel zum Verbraucher angeschlossen wird, kann diesen Effekt aufheben, da ein Verbraucher mit ohmscher Last simuliert wird.
Das Modul ermöglicht eventuell auch den Betrieb eines [[RSL 2-Draht Einbauschalter]]s, der bei LED Leuchtmitteln ansonsten nicht eingesetzt werden kann, da zum Betrieb eine Restspannung über den Verbraucher benötigt wird, der bei LED Lampen mit Vorschaltgerät nicht vorhanden ist.

In Frage kommt z.b. ein Eltako ELTA Grundlastelement GLE / PTC, das ca. 5-8 Euro kostet.
Technisch handelt sich dabei um einen PTC, also einen Widerstand mit positivem Temperaturkoeffizient, d.h. der Widerstand sinkt deutlich, wenn das Element kälter wird.

Das genannte Grundlastelement hat folgende Daten:
Kaltwiderstand: 3500 Ω
Einschaltstrom bei 230 V: 65 mA (ca. 15 W)
Verlustleistung nach 60 Sekunden: 0,65 W

Im kalten Zustand lässt der PTC bei 230 Volt einen Strom von ca. 0,065 Ampere zu.
Das reicht, um von Schaltaktoren, Freischaltern, Dimmern etc. als die erforderliche Grundlast erkannt zu werden.
Wird der Stromkreis eingeschaltet, fliesst auch tatsächlich Strom durch den PTC, der sich dadurch schnell erwärmt (das Element wird tatsächlich sogar relativ heiss). Dadurch steigt steigt der Widerstand auf ca 50000-60000 Ohm an und die Verlustleistung sinkt auf unter 1 Watt. Der PTC regelt sich jetzt selber auf eine bestimmte Temperatur und Widerstand ein.

Wird ausgeschaltet, so fliest über den PTC immer noch ein kleiner Reststrom von ca 0,005 Ampere, der als Grundlast reicht, um z.b. Spannungen abzubauen, die LEDs nachflackern lassen, dieser steigt mit Erkalten rasch an, dadurch werden auch Schalter wie die [[RSL 2-Draht Einbauschalter]] mit genug Strom versorgt.

Theoretisch kann also auch ein PTC mit diesen Werten und einer Leistung von ca. 20 Watt selbst gebaut werden, der Preis der Einzelteile liegt bei unter 2 Euro. Das Eltako Element ist bereits mit Isolierung und Anschlussleitungen versehen, mit eigner Arbeitszeit ist der Preisvorteil beim Selberbau also gering.

== Februar 2017 ==
=== at Zeiten ===
at 03:00 -> 1x um 3 Uhr (wann immer das nächste mal 3 Uhr ist, ggf. erst morgen)
at *03:00 -> jeden Tag um 3 Uhr
at +03:00 -> in 3 Stunden
at +*03:00 -> in 3 Stunden und dann alle 3 Stunden erneut
at +*{4}03:00 -> in 3 Stunden und dann alle 3 Stunden erneut, aber nur 4x ausführen.

== Oktober 2016 ==
=== Grundlagen der Heizungssteuerung ===
Der Artikel [[Grundlagen der Heizungssteuerung]] soll einen zentralen Einstiegspunkt und eine Übersicht der Möglichkeiten insb. für Neulinge in FHEM bieten.

=== Batterieüberwachung für Geräte ohne Batteriestatus ===
Es gibt Möglichkeiten um auch bei Geräten ohne Batteriestatus-Reading eine schwache Batterie erkennen zu können: [[Batterie%C3%BCberwachung#Ger.C3.A4te_ohne_Batteriestatus|Geräte ohne Batteriestatus]].

== Mai 2016 ==
=== DbLog reparieren ===
Sollte ein fhem mit DbLog Probleme machen, oder auf der SQL-Konsole Fehler werfen, so ist eine Reparatur der DB fällig. Das ist auf der Kommandozeile verhältnismäßig einfach möglich und wird im Kapitel [[DbLog#Datenbank reparieren]] beschrieben.

=== DbLog bearbeiten ===
Unerwünschte Einträge in den Loggings treten immer wieder mal auf. Wie man dies in einer Datenbank korrigiert, dazu gibt das Kapitel [[DbLog#Bearbeitung von Datenbank-Einträgen]] eine erste Einführung.

=== Pollenflug ===
In dieser schönen Jahreszeit werden manche durch Heuschnupfen geplagt. Auf der Seite [[Pollenflug]] wird beschrieben, wie man eine Pollenvorhersage in fhem einbinden kann - hilft zwar nicht gegen das Niesen, ist aber trotzdem ganz informativ... ;-)

== April 2016 ==
=== HomeMatic und VCCU ===
HomeMatic Nutzer sollten unbedingt eine [[Virtueller Controller VCCU|VCCU]] einrichten und nutzen.
Die Einrichtung ist unaufwändig und schafft jede Menge Vorteile, auch beim Einsetzen nur einer Schnittstelle wie z.B. einem [[HM-CFG-LAN LAN Konfigurations-Adapter]]. Auch die nachträglich Einrichtung ist problemlos, sofern vorher nur ein I/O Gerät ("Funkschnittstelle") verwendet wurde.

== Dezember 2015 ==
===defmod===
In vielen Fällen will man mit einer Aktion gleichzeitig eine andere Aktion bereits für später festlegen, z.b. nach Einschalten einer Heizung durch einen Bewegungsmelder diese eine Stunde später wieder ausschalten.

Dies kann z.B. durch ein Konstrukt dieser Art erledigt werden:
:<code>define Heizung_an notify Bewegung set HZG_WZ desired-temp 22 ;; define reset_Heizung at +01:00:00 set HZG_WZ desired-temp 16</code>

Nachteilig ist, dass bei einer weiteren Auslösung des Bewegungsmelders die Heizzeit nicht verlängert wird, da eine Neudefinition von '''reset_Heizung''' mit der Fehlermeldung '''reset_Heizung already exists, delete it first''' quittiert wird. Die Lösung bisher war, das alte '''reset_Heizung''' zunächst zu löschen und dann erneut mit neuem Zeitstempel anzulegen:
:<code>define Heizung_an notify Bewegung set HZG_WZ desired-temp 22 ;; delete reset_Heizung ;; define reset_Heizung at +01:00:00 set HZG_WZ desired-temp 16</code>
Aber auch dieses umständliche Konstrukt hat noch einen Nachteil: Es erzeugt bei einer ersten Auslösung eine Fehlermeldung, weil '''reset_Heizung''' noch nicht exisitert und daher nicht gelöscht werden kann. Dies liesse sich abfangen, was die Konstruktion weiter verkomplizieren würde.

Daher hat Rudolf König mit FHEM 5.6 den neuen Befehel "defmod" eingeführt, der ein noch nicht existieredendes define neu anlegt (wie "define"), eine bereits vorhandenes aber direkt ändert (wie "delete" und danach "define")

Dadurch lässt sich verkürzt schreiben:
:<code>define Heizung_an notify Bewegung set HZG_WZ desired-temp 22 ;; defmod reset_Heizung at +01:00:00 set HZG_WZ desired-temp 16</code>

== April 2015 ==
===FS20 Timer===
FS20 Aktoren beherrschen zwei verschiedene Timer-Methoden.

Angenommen ein FS20 Device heisse "Lampe" und sei z.B. ein [[FS20_SU_Unterputz-Funk-Schalter|FS20 SU]] (Unterputzschalter), dann kann man mit FHEM sowohl
:<code> set Lampe on-for-timer 30</code>
verwenden um die Lampe 30 Sekunden einzuschalten, aber auch zunächst in den FS20 SU die maximale Einschaltdauer einprogrammieren:
:<code> set Lampe timer 30</code>
Dannach wird jedes normale
:<code> set Lampe on</code>
die Lampe für nur 30 Sekunden einschalten.

Als Timerwerte kommen in beiden Fällen die bekannten [[Trick_der_Woche#FS20_Timerzeiten|128 Sekundenwerte]] von 0,25 Sekunden bis Etwa 4,5 Stunden in Frage.

Es ist offenbar nicht bei allen Aktoren möglich einen einmal eingestellten Timer zu löschen, neue Werte eingeben aber sehr wohl.

Mehr hier: [[FS20_Allgemein#Gerätetimer setzen / löschen|FS20 timer]].

== Februar 2015 ==
=== 1-wire am GPIO4-Port des RaspberryPi funktioniert nicht mehr nach Systemupdate ===
Es kann passieren, dass nach einem Systemupdate (apt-get update oder apt-get dist-upgrade) die 1-wire-Geräte am GPIO4-Port plötzlich nicht mehr funktionieren. Eine Problemlösung dazu ist im Artikel "[[Raspberry Pi und 1-Wire#1-wire am GPIO4-Port funktioniert nicht mehr nach Systemupdate]]" beschrieben.

=== Backup der Konfiguration (fhem.cfg und fhem.state) bei jedem "save" ===
Der nachfolgende Codeschnipsel erstellt bei jedem "save" eine Kopie der aktuellen [[Konfiguration]] (fhem.cfg und fhem.state) in ein Verzeichnis "backup_cfg-state" welches unter /opt/fhem/ zu finden ist. Somit kann bei einem Fehler jederzeit auf den letzten Stand zurückgegangen werden.
Zuerst ins FHEM Befehlsfeld den folgenden Befehl eingeben:
:<code>{ `mkdir backup_cfg-state` } </code>

Danach folgendes [[notify]] anlegen:
define backupCfg notify global:SAVE {\
my $now = TimeNow();; $now =~ s/ /_/g;; \
`cp $attr{global}{configfile} ./backup_cfg-state/fhem.cfg.$now`;;\
`cp $attr{global}{statefile} ./backup_cfg-state/fhem.state.$now`;;\
}

Quelle: {{Link2Forum|Topic=30873|Message=234412|LinkText=FHEM-Forum}}

== Januar 2015 ==
=== CUL & CO über Serial ID-einbinden ===
Bei mehreren USB-Geräten kann es vorkommen, dass sie vertauscht werden z.B. ''/dev/ttyUSB0'' zu'' /dev/ttyUSB1'' oder ''/dev/ttyACM0'' zu ''/dev/ttyACM1''.

Um dies zu umgehen, kann man sie über ihre Serial-ID in FHEM einbinden.

Dieser Befehl zeigt die Serial-ID:

:<code>ls -l /dev/serial/by-id</code>

Hier die Beispielausgabe eines CUL868, JeeLink, RFXtrx und eines CUL433

user@xxxx:~# ls -l /dev/serial/by-id
lrwxrwxrwx 1 root root 13 Jan 9 23:34 usb-busware.de_CUL868-if00 -> ../../ttyACM0
lrwxrwxrwx 1 root root 13 Jan 9 13:26 usb-FTDI_FT232R_USB_UART_A901RQ9F-if00-port0-> ../../ttyUSB0
lrwxrwxrwx 1 root root 13 Jan 9 13:26 usb-RFXCOM_RFXtrx433_A1WZWL5Y-if00-port0-> ../../ttyUSB1
lrwxrwxrwx 1 root root 13 Jan 9 21:29 usb-busware.de_CUL433-if00 -> ../../ttyACM1

Damit lässt sich folgende Definition erstellen:

z.B. für einen CUL868

:<code>define CUL868 CUL /dev/serial/by-id/usb-busware.de_CUL868-if00@9600 1134</code>

oder einen JeeLink

:<code>define Jeelink JeeLink /dev/serial/by-id/usb-FTDI_FT232R_USB_UART_A901RQ9F-if00-port0@57600</code>

'''Einschränkung:''' Bei CULs von Busware lassen sich nur CUL433 und CUL868 unterscheiden. Zwei CUL868 haben z.B. immer die gleiche Serial-ID.

=== HM LAN Konfig-Adapter Antenne verbessern===
Die Antenne des [[HM-CFG-LAN LAN Konfigurations-Adapter]] kann man mit etwas Bastelgeschick verlängern um den Empfang zu verbessern.

Sinnvoll ist die Verlängerung auf 1/2 Lambda (868MHz = 17,27 cm) oder gar 1 Lambda.
1 Lambda Antennen haben starke Richtwirkung in Form eines gedachten Zylinders, dessen Mittelachse die Antenne ist.
D.h., Alles was sich in Richtung des Anfangs und des Endes des Antennedrahtes befindet, hat schlechteren Empfang als mit einer kurzen Antenne. Daher muss man die Antenne ggf. genauer ausrichten.

Anleitungen dazu werden an verschiedenen Stellen veröffentlicht, z.B. in
[http://www.ip-symcon.de/forum/threads/18411-Umbau-HM-LAN-Adapter-auf-Lambda-1-2-Dipol-Antenne diesem Beitrag] im IP-Symcon Forum (anders als der Namen der Anleitung vermuten lässt, liegt hier kein Dipol vor, sondern eine "normale" 1 Lambda Antenne.)

Prinzipiell so dünnen Draht wie möglich verwenden.

Wer noch mehr rausholen will, kann auch zusätzlichen Aufwand betreiben und die Antenne etwas von der Elektronik entfernen, die nämlich Störstrahlung in die Antenne einkoppelt. Oder eine Groundplane bauen.
Ein Anleitung für die CCU (analog auch für den HM LAN Konfig-Adapter einsetzbar) gibt es [http://www.techwriter.de/beispiel/funkeige.htm hier].

== Dezember 2014 ==
=== FHT80TF als "Prüfsender" einsetzen ===
Da der [[FHT80TF-2]] günstig ist und seinen Zustand ca. alle zwei Minuten sendet, kann er gut zum Ermitteln der Funklage von [[SlowRF]] Komponenten genutzt werden, auch wenn diese nicht senden. Den RSSI einer FS20 Schaltsteckdose kann man z.B. nicht wissen, da die Dose nur ein Empfänger ist. Wenn eine Dose nicht gut funktioniert und man den Verdacht hat, dass sie funktechnisch ungünstig liegt, kann man einen [[FHT80TF-2]] neben die Steckdose legen und man bekommt nach zwei Minuten einen Wert, der (trotz umgekehrter Funkrichtung) gut genug ist, um einem Hinweise zu geben.

== November 2014 ==
=== FS20 Adressschema und die Rolle des Hauscodes ===
[[FS20_Allgemein#FS20_Adressierungsschema_.28Vorschlag.29]]

== Oktober 2014 ==
=== Aktor für Wanddosen ohne Nulleiter ===
Es gibt viele Aktoren die man in Einbaudosen hinter Schaltern einbauen kann. Oft scheitert deren Nutzung aber daran, dass in vielen Elektroinstalltionen in der Einbaudose eines (Licht)schalters kein Neutralleiter (Nulleiter) verlegt ist, den die meisten Aktoren zur eigenen Stromversorgung brauchen. Hier kann der [[RSL 2-Draht Einbauschalter]] helfen, der auch ohne Neutraleiter funktioniert und kompatibel zu InterTechno ist. Er lässt sich z.B. mit einem CUL(433) schalten. Problematisch ist damit allerdings das Schalten von LED Lampen.

== August 2014 ==
=== Perl-Skripte Online testen ===
Im Internet existieren Webseiten auf denen man Perl-Code online testen kann. Beispielsweise auf [http://www.tutorialspoint.com/execute_perl_online.php codingground] kann man Code zum Testen eingeben und die Auswirkungen betrachten. Dies eignet sich zur schnellen Fehleranalyse oder um Perl zu lernen. Natürlich lassen sich keine FHEM-Besonderheiten nutzen.

== Juli 2014 ==
=== Funklast reduzieren===
Bewegungsmelder erzeugen in der Regel eine recht hohe Funklast, wenn sie oft ausgelöst werden, also z.B. Licht in einem Zimmer schalten sollen.

Konstruktionen der Art:
:<code>define FlurLicht notify Bewegungsmelder_Flur:motion:.* set Licht_Flur on-for-timer 256</code>
haben daher den Nachteil bei viel Bewegung im Flur und je nach Einstellung des Sendeabstandes des Bewegungsmelders mindestens alle 120 Sekunde oder öfter ein
:<code>on-for-timer 256</code>
zu senden. Das erzeugt eine hohe Funklast, speziell wenn der Aktor ein SlowRF Gerät ist (z.B. FS20 Unterputzschalter).
In solchen Fällen kann es helfen, nur dann einen Befehl zu senden, wenn das Licht nicht schon an ist:
:<code>define FlurLicht notify Bewegungsmelder_Flur:motion:.* { if (Value("Licht_Flur") eq "off") { fhem ("set Licht_Flur1 on-for-timer 256") } }</code>
Nachteilig ist aber, dass eine Auslösung innerhalb 256 Sekunden die Einschaltzeit nicht verlängert. Dies kann man umgehen, indem man nicht on-for-timer verwendet, sondern den Aktor selber verzögert auschaltet und bei weiteren Auslösungen nur die Verzögerung erneut anlegt:
:<code>define FlurLicht notify Bewegungsmelder_Flur:motion:.* { if (Value("Licht_Flur1") eq "off") { fhem ("set Licht_Flur on ;; define FlurLicht_aus at +00:04:16 set Licht_Flur off") } else { fhem ("delete FlurLicht_aus ;; define FlurLicht_aus at +00:04:16 set Licht_Flur off") }}</code>
Durch den relativ neuen Befehl "defmod" kann ausserdem das Löschen und neu Anlegen zusammengefasst werden, sieh Tipp Dezember 2015

== Juni 2014 ==
=== Batteriestatus bei HomeMatic Devices aktivieren===
Zumindest einige (wenn nicht alle) batteriegespeisten HM-Geräte können Batteriemeldungen senden, tun dies in der normalen Konfiguration aber nicht.
Dazu muss das Register cyclicInfoMsg auf on gesetzt werden.

Wie man das macht steht z.B. hier
[[HM-SEC-SC_Tür-Fensterkontakt#Batteriestatus_aktivieren]]
und hier
[[HomeMatic_Type_ThreeState]]

== Mai 2014 ==
=== Dummywert mit aktueller Uhrzeit versehen in anderen Dummy kopieren===
Der Inhalt von Dummy1 soll erweitert um Uhrzeit und Datum in Dummy2 kopiert werden (z.B. um die Urzeit der letzten Auslösung einer Alarmanlage anzuzeigen)
:<code>{ fhem("set dummy2 " . (Value("Dummy1")." ".TimeNow()) ) } </code>

=== Zwei Dummywerte in einen anderen Dummy kopieren ===
Der String in Dummy1 soll um den String in Dummy2 erweitert und nach Dummy3 kopiert werden:
:<code>{ fhem("set Dummy3 ".(Value("Dummy1")+Value("Dummy2"))) } </code>
(Achtung: "+" ist Zahlen addieren, "." ist String konkatenieren / verketten)

== April 2014==
=== Code sparen ===
Wer Definitionen wie die aus dem März zum [[Trick der Woche#Zuverlässigkeit von FS20 Schaltungen erhöhen|Abfangen von Fehlbedienungen]] verwendet, kann durch eine ELSE Erweiterung auch gleich das Auschalten erledigen.
:<code>define act_on_TV_on notify TV { if ("$EVENT" eq "on" || "$EVENT" eq "dimup") { fhem("set TV on") } else { fhem("set TV off") } }</code>

Hierdurch schaltet ON oder versehentlich zu langes Drücken (also DIMUP) den Fernseher ein, jeder ''andere'' Tastendruck (also insbesondere die OFF Taste oder zu langes Drücken der OFF Taste -> DIMDOWN) den Fernseher aus.

Voraussetzung ist, dass die Fernbedienung standardkonfiguriert ist, siehe auch nächster Tip.

=== Konfiguration eines FS20 Senders prüfen ===
Gelegentlich reagieren bestimmte notifys nicht, die von Sendern (Fernbedienungen, Sensoren oder Schaltern) ausgelöst werden sollen. Speziell bei FS20 aber auch bei HomeMatic kann das daran liegen, dass der Sender nicht sendet was man denkt. So gut wie alle FS20 Sender kennen nämlich nicht nur ON und OFF, sondern über ein Dutzend Schaltzustände. Dimmen ist einem noch hinreichend bewusst, es gibt aber auch exotische Dinge wie Ein-für-Zeitdauer, Ein-auf-alte-Helligkeit, Aus-für-Zeitdauer (nur FS20), Ein-für-Zeitdauer-dannach-alter-Zustand und vieles mehr.

Was also ein Infrarot-Bewegungsmelder bei Auslösung sendet und auch was eine Fernbedienungstaste sendet ist einstellbar. Wenn jetzt zum Beispiel an einer Fernbedienung auf Tastendruck nicht ON sondern Ein-für-Zeitdauer (ON-FOR-TIMER) gesendet wird, wird
:<code>define act_on_TV_on notify TVFB:on set TV on</code>
seltsamerweise nicht auslösen, obwohl die richtige Taste (und diese auch nicht zu lang) gedrückt wurde.

Auch wenn man sich sicher ist, das Richtige in die Fernbedienung/Sensoren einprogramiert zu haben, ist ein einfacher Test immer, dies mit
:<code>define act_on_TV notify TVFB set TV on</code>
zu prüfen. Dieses notify löst immer aus, wenn "TVFB" ''irgendetwas'' sendet, egal was. (Beachte: Man kann dann den Fernseher aber nicht mehr ausschalten, da auch die Austaste das notify auslöst und zum TV-Aktor nur "on" sendet).

Geht die Schaltung jetzt (kann man den Fernseher also jetzt EINschalten), liegt der Verdacht nahe, dass die Konfiguration des Senders / Sensors anders ist, als man denkt. Das Logfile, der EventMonitor oder ein Beobachtung von FHEM per Telnet mittels "inform" gibt Aufschluss, welcher Befehl tatsächlich empfangen wurde.

== März 2014==
=== Zuverlässigkeit von FS20 Schaltungen erhöhen ===
FS20 Fernbedienungen senden bei Tastendrücken von mehr als 0,4 Sekunden anstatt ON bzw. OFF DIMUP bzw DIMDOWN.(Auch einige FBs anderer Systeme verhalten sich ähnlich)

Das führt gelegentlich zu allgemein schlechter Bedienbarkeit (und schlechtem WAF), da 0,4 Sekunden relativ kurz ist und gerne aus versehen länger gedrückt wird. Das ist vor allem problematisch, wenn etwas geschaltet werden soll, was keinen Dimmer hat oder Dimmen nicht unterstützt.

Eine Konfiguration wie
:<code>define act_on_TV_on notify TVFB:on set TV on</code>
hat also dann den Nachteil, dass bei versehentlich zu langem Tastendruck auf die Fernbedienung das TV nicht angeht. Da die meisten Nutzer unbewusst dazu neigen, bei Misserfolg die selbe Taste erneut aber länger zu drücken (was erneut keinen Erfolg zeigt) ist Frustration zu erwarten.

Es kann daher speziell bei nicht dimmbaren Aktoren von Vorteil sein, auch dimmen abzufangen, z.B. durch eine zweite zusätzliche Definition:

:<code>define act_on_TV_dimup notify TVFB:dimup set TV on</code>

Es ist in der Regel einfacher, einige dieser zusätzlichen Definitionen einzufügen, als allen Bedienern des Systems zu erklären, dass man keinesfalls länger als 0,4 Sekunden drücken darf.

Alternativ kann man auch beide Befehle in einer Definition durch Perlbefehle {} abfangen:

:<code>define act_on_TV_on notify TVFB { if ("$EVENT" eq "on" || "$EVENT" eq "dimup") { fhem("set TV on") }}</code>

Allerdings hat dies den Nachteil, dass jedes Event dieses define durchläuft und erst später geprüft wird, ob das Event überhaupt irgendetwas auslöst.
Z.B. wird
:<code>define act_on_TV_on notify TVFB ...</code>
auch durch TVFB off ausgelöst (oder unter bestimmten Bedungen sogar duch alle Events), nur um dann nach dem Perl Test festzustellen, dass doch nichts getan werden soll.

Ressourcenschonender ist daher:
:<code>define act_on_TV_on notify TVFB:on|TVFB:dimup set TV on </code>

Andere Möglichkeiten vergleiche: [[Trick der Woche#notify durch mehrere Ereignisse auslösen lassen|Notify durch mehrere Ereignisse auslösen lassen]] und [[Trick der Woche#Performance_von_Notifys|Performance von Notifys]]

== Februar 2014==
=== Sequence nutzen ===
Man kann Aktionen statt mit einem Tastedruck auch mit einer Sequenz von Tastendücken auslösen. Das Format des Befehle ist:

:<code>define <name> sequence <re1> <timeout1> <re2> [<timeout2> <re3> ...] </code>

wobei <re1> ...<re_n> die Aktionen sind und <timeout_n> der maximale Abstand der Tastendrücke in Sekunden.

Angenommen, man wolle z.B. eine Lampe dann anschalten, wenn man zuerst Taste1 EIN, dann Taste2 AUS und dann wieder Taste1 EIN einer Fernbedienung drückt, könnte das konkret so aussehen:

:<code>define MeineLampenSequenz1 sequence Btn1:on 0.5 Btn2:off 0.5 Btn1:on</code>

Zwischen jedem der Tastendrücke darf eine halbe Sekunde Abstand sein. Diese Definition selbst löst die Lampe nicht aus, sondern definiert nur wie die Sequenz aussehen soll. Um die Lampe bei erfolgreicher Betätigung der Sequenz auch einzuschalten, bedarf es zusätzlich etwas wie:

:<code>define MeineLampe notify MeineLampenSequenz1:trigger set Lampe on</code>

Sequence kann man gut nutzen, um mit einer Fernbedienung mehr Funktionen zu schalten als Tasten zur Verfügung stehen. Ebenso könnte man damit simple Codeschlösser für Alarmanlagen bauen, z.B. um eine Anlage auszuschalten, wenn eine bestimmte Abfolge von Tasten gedrückt wird.

Je nach Funksystem nimmt die Zuverlässigkeit aber rasch ab. Angenommen im Bereich FS20 (das System ist etwas unzuverlässiger ist als z.B. HomeMatic) seien 95% aller Funktsignale ungestört übertragbar, dann würden in der Praxis von 100 Tastendrücken an einer Fernbedienung 95x Erfolg zeigen und 5x fehlschlagen; das ist sicher tolerabel.

Bei einer Sequenzlänge von nur 4 Tasten würde die kombinierte Erfolgsquote der Sequenz jedoch nur noch ca. 80% sein, zum Ausschalten einer Alarmanlage vermutlich bereits unpraktisch.

== Januar 2014==
===isday===
Bekanntlich kann man mit "isday" leicht testen ob es draussen hell ist oder nicht. isday ist eine Funktion des (automatisch geladenen) Moduls [[SUNRISE_EL]], das auch sunset und sunrise enthält.

Problematisch bei isday ist die fehlende Möglichkeit, Sonnenaufgang und Untergang einzustellen (zumindest wenn man nicht 99_SUNRISE_EL.pm verändern will): isday ist wahr, wenn die Sonne im gegebenen Breitengrad theoretisch sichtbar ist. Wenn örtliche Gegebenheiten (Bebauung, Bäume, Tal etc.) eine Anpassung erfordern, kann man sich auch ein eigenes isday basteln, in dem man sunrise und sunset verwendet und dieses mit getrennten offsets versieht.

Zuerst definiert man sich eine Variable ("dummy") der anstelle isday eingesetzt werden soll, z.B.:

:<code>define Tageslicht dummy </code>

Dann wird diese mit sunset und sunrise befüllt:

define SetDummy1 at *{sunset(-3600)} set Tageslicht hell
define SetDummy2 at *{sunrise(+1800)} set Tageslicht dunkel

Jetzt kann für jeden Wechsel ein eigener Offset gewählt werden, im Beispiel 3600 Sekunden vor Sonnenuntergang und 1800 Sekunden nach Sonnenaufgang. Anstatt das Dummy "Tageslicht" mit den Werten "hell/dunkel" zu befüllen, kann natürlich auch 1/0 oder "Tag/Nacht" etc. verwendet werden, je nachdem was bei der Anwendung besser passt.

Für höhere Ansprüche könnte hingegen das [[Twilight]]-Modul verwendet werden, das Dämmerungsstufen kennt.

===Struktur von "else if" Verzweigungen===
define ... notify ... {\
if ... {\
fhem ("... ;; ...")\
}\
elsif ... {\
fhem ("... ;; ...")\
}\
elsif ... {\
fhem ("... ;; ...")\
}\
else {\
if ... {\
fhem ("... ;; ...")\
}\
}

Achtung: es muss tatsächlich "elsif" heissen und nicht "elseif" oder "else if".

Gilt für Perl Aufrufe.
Wer aktuell in FHEM neu einsteigt, kann auch den seit 2014 zur Verfügung stehenden FHEM Befehl [[DOIF]] verwenden, der komfortabler ist und zusätzliche Features aufweist.

== Dezember 2013==
===notify durch mehrere Ereignisse auslösen lassen===
Bekanntermassen löst

:<code>define irgendwas notify MeinSchalter …</code>

aus, wenn irgendein Ereignis vom Sender "MeinSchalter" eintrifft.

Mit

:<code>define irgendwas notify MeinSchalter:on …</code>

wird das notify jedoch nur ausgelöst, wenn dieses Ereignis eine "on" ist.
Wenn man aber möchte, das z.B. "on" und "off" auslöst (um etwa Dim-Befehle auszuschliessen) kann dies wie folgt erreicht werden:

:<code>define irgendwas notify MeinSchalter:(on|off) …</code>

Die Klammern sind wichtig, vergleiche eine Lösung, bei der zwei Sender alternativ das notify auslösen können:

:<code>define irgendwas notify MeinSchalter:on|MeinAndererSchalter:on …</code>

Selbstverständlich geht z.B. auch folgendes:

:<code>define irgendwas notify MeinSchalter:on|MeinAndererSchalter …</code>

Hier wird ausgelöst wenn "MeinSchalter" das Ereignis "on" liefert oder "MeinAndererSchalter" irgendein Ereignis. Beachte hierzu jedoch den Tipp vom Dezember 2020 "Performance von Notifys"

=== Aktoren über mehrere Funkschnittstellen ansprechen ===
Falls man mehrere Funkschnittstellen zur Reichweitenverlängerung hat (CUL / CUNO etc), und ein Aktor von beiden Funkschnittstellen in etwa gleich (schlecht) erreichbar ist, mag der Wunsch aufkommen, einen Funkbefehl über beide Schnittstellen auszusenden. Dies ist bei Funkprotokollen möglich, die kein echtes Pairing der Aktoren an die Funkschnittstelle erfordern, also z.B. FS20 oder Intertechno, nicht jedoch ohne weiteres bei HomeMatic.

Problematisch ist aber, dass die Funkschnittstelle über IODev eindeutige je Aktor festgelegt werden muss, eine Zuordnung mehrerer IODevs ist nicht vorgesehen.
(wenn man IODev nicht setzt, wird per default die LETZTE definiert passende Schnittstelle verwendet)

Dieses Problem kann mit einem Trick aber umgangen werden. Und zwar legt man den Aktor 2x mit gleicher Adresse aber abweichenden Namen und IOdevs an, z.B. so:

define brenner_CUL1 FS20 11114244 11
attr brenner_CUL1 IODev CUL1
attr brenner_CUL1 room Keller

define brenner_CUL2 FS20 11114244 11
attr brenner_CUL2 IODev CUL2
attr brenner_CUL2 room Keller

Ein Befehl der Art:

set brenner_CUL1,brenner_CUL2 on

sendet den ON Befehl für den FS20 Aktor 11114244 11 jetzt tatsächlich über beide CULs aus!

Achtung: Wenn die Schnittstellen gleichschnell angebunden sind, sollte vermutlich der [[Sendpool]] verwendet werden, da die Aussendungen sonst tatsächlich gleichzeitig erfolgen könnten und sich dann gegenseitig stören würden. Dieser Trick funktioniert ausserdem nur bei Befehlen, bei denen es im Zweifel egal ist, wenn sie beim Aktor 2x eintreffen.

Bei HomeMatic lässt sich ein ähnlicher Effekt durch einrichten einer [[Virtueller Controller VCCU|virtuellen CCU]] erreichen.

=== Retrycount bei FHTs ist überflüssig===
Das von der Funktion ''autocreate'' älterer FHEM Versionen beim Anlegen von FHT80 Heizungsreglern voreingetragene attribute "retrycount" hat in den allermeisten Fällen keine Wirkung, da es NUR greift, wenn man als Funkschnittstelle eine FHZ1X00PC verwendet und dann den Softbuffer einschaltet. Selbst wenn man diese Konfiguration nutzt, will gut überlegt werden, ob die Wirkung postiv ist: Bei ungenügender Empfangslage vergrössert es Kommunikationsprobleme eventuell sogar.

Es kann also in der Regel entfernt oder auf den Wert "1" gesetzt werden.

define Heizung_Bad FHT 060d
attr Heizung_Bad retrycount 3 <=== Diese Zeile entfernen

Siehe auch:[[Kommunikationsprobleme mit FHT]]

== November 2013 ==
=== FS20 Funksteckdose sicherer schalten===
Seltsamerweise kommt es vor, das FS20 Aktoren - insbesondere die FS20 Funksteckdose - an der Grenze der Funkreichweite bestimmte Befehle eines Typs empfängt, andere aber nicht. Z.B. lässt sich die FS20 Steckdose zwar immer einschalten, aber oft nicht mehr aus (oder umgekehrt).

Gelegentlich kann man die Zuverlässigkeit erhöhen, indem man statt dem nicht funktionierenden Befehl das Gegenteil mit "for-timer 1" verwendet.

Im Fall, dass eine FS20 Steckdose sich also einwandfrei EINschalten lässt:
:<code>set SteckdoseA on</code>
aber oft ein AUSschalten mittels
:<code>set SteckdoseA off</code>
nicht funktioniert, kann man versuchen die Dose anstelle mit "off" mit dem Befehl
:<code>set SteckdoseA on-for-timer 1</code>
auszuschalten.

Analog kann man mit off-for-timer arbeiten, wenn sich Aktoren nicht einschalten lassen, ausschalten aber geht.

Achtung: Dieser Trick funtioniert ausdrücklich nur, wenn der "on/off-for-timer" Befehl im Aktor selber abgebildet wird. Daher ist der Trick vermutlich nicht auf andere Funksysteme übertragbar. z.B. unterstützt HM nur on-for-timer und Intertechno kennt keinen Timer.

=== Mehrere Geräte zugleich schalten===
Ein Ereignis soll mehrere Geräte schalten:

:<code>define act_on_Bewegungsmelder notify Bewegungsmelder set Lampe1 on;;set Lampe2 on;;set FunksteckdoseA on</code>

Aus Übersichtlichkeitsgründen können vor und nach den Semikolons auch Leerzeichen eingefügt werden (obwohl in einigen Dokumentation behauptet wird, dies dürfe man nicht machen):

:<code>define act_on_Bewegungsmelder notify Bewegungsmelder set Lampe1 on ;; set Lampe2 on ;; set FunksteckdoseA on</code>

Wenn der Schaltbefehl bei allen Geräten gleich ist, kann man wie folgt zusammenfassen:

:<code>define act_on_Bewegungsmelder notify Bewegungsmelder set Lampe1,Lampe2,FunksteckdoseA on</code>

Das Komma wird nicht [[Escapen in Perlbefehlen|escaped]] (verdoppelt), hier darf tatsächlich KEIN Leerzeichen vor oder nach dem Komma eingefügt werden.

=== Logfileinträge unterdrücken===
Das Attribute "verbose 0" verhindert, dass das Gerät Logfileinträge erzeugt.

Beispiel:

define Funksteckdose FS20 22224222 01
attr Funksteckdose verbose 0

===FHT Lazy Mode benutzen===
Es gibt wenig Gründe, den FHT "Lazy Mode" nicht zu verwenden
define Heizung_Bad FHT 060d
attr Heizung_Bad lazy

Dieser sorgt dafür, dass Temperaturänderungen (genau genommen alle Änderungen, auch z.B. date) nur übertragen werden, wenn sie nicht sowieso schon am FHT eingestellt sind und veringern die Funklast dadurch deutlich.

Siehe auch: [[Kommunikationsprobleme mit FHT]]

== Oktober 2013 ==
=== Zuverlässigkeit von Wiedereinschalten erhöhen ===
Speziell bei FS20 Aktoren ist wegen des fehlenden Rückkanals nicht leicht erkennbar, ob ein Einschaltbefehl Wirkung gezeigt hat. Das bringt einen ganz schlechten WAF, wenn man z.B. mit einem FS20 Aktor eine Heizung ausschaltet und das Wiedereinschalten nach z.B. einer Stunde nicht klappt.

Hier empfiehlt es sich, das Ausschalten mittels
:<code>set Heizungs_schalter off-for-timer 3584</code> (= fast eine Stunde)
zu erledigen. Da bei FS20 der off-for-timer Befehl im Aktor abgewickelt wird (und nicht durch FHEM), schaltet sich der Aktor auch dann garantiert wieder ein, wenn FHEM abstürzt, eine Funkstörung vorliegt oder ähnliches. Bei Bedarf kann der Befehl off-for-timer zur Verlängerung der Ausschaltzeit wiederholt werden. Dies kann z.B. nötig sein, wenn die Ausschaltung länger als 4,5 Stunden (15360 Sekunden, der Maximalwert des Timers) dauern soll.

Achtung: dieser Trick funktioniert nur, wenn der Aktor "off-for-timer" selbst beherrscht. FS20 Geräte können das, HomeMatic können aber nur "on-for-timer". Man kann off-for-timer mit HomeMatic trotzdem verwenden, aber in diesem Fall sendet FHEM den Einschaltbefehl nach der Timerzeit. InterTechno, RSL etc, können gar keinen Timer, hier sendet FHEM immer 2 Befehle im passenden Abstand.

=== FS20 Timerzeiten ===
FS20 Timer werden in Sekunden angegeben. Es sind jedoch nicht alle Werte einstellbar. Da der Timer Wert in 7 Bit übertragen werden muss, sind nur 128 Werte möglich. Um mit diesen Werten im unteren Bereich möglichst fein aufzulösen, andererseits aber auch lange Zeiten zu ermöglichen, ist die Verteilung nicht linear. Einstellbar sind folgende Zeiten in Sekunden;

0,25 0,5 0,75 1 1,25 1,5 1,75 2 2,25 2,5 2,75 3 3,25 3,5 3,75
4 4,5 5 5,5 6 6,5 7 7,5 8 9 10 11 12 13 14 15 16 18 20 22
24 26 28 30 32 36 40 44 48 52 56 60 64 72 80 88 96 104 112
120 128 144 160 176 192 208 224 240 256 288 320 352 384 416
448 480 512 576 640 704 768 832 896 960 1024 1152 1280 1408
1536 1664 1792 1920 2048 2304 2560 2816 3072 3328 3584 3840 4096
4608 5120 5632 6144 6656 7168 7680 8192 9216 10240 11264 12288
13312 14336 15360
(etwas übersichtlicher formatiert auch [[FS20 Allgemein#ON/OFF Befehle mit Time Parameter|hier]]).

Andere Zeiten werden von FHEM gerundet. Ein neues Setzen des Timer für FS20 löscht den alten Wert.

Auch HomeMatic Aktoren beherrschen Time Parameter, im Gegensatz zu FS20 allerdings kein "off-for-timer". Details dazu im Artikel [[HomeMatic Timerwerte]]

[[Kategorie:HOWTOS]]

Trick der Woche

2025-08-18T10:14:36Z

TomLee:

Diese Seite enthält Tipps und Tricks, die zu unbedeutend sind, einen eigenen Artikel zu rechtfertigen, alternative Schreibweisen/Lösungen für eine Problem darstellen, Ungenauigkeiten oder unklare Formulierungen in den offiziellen Dokumenten ergänzen und ähnliches. Jeder Eintrag ist typischerweise sehr kurz (wenige Zeilen lang) und beleuchtet vielleicht nur einen Aspekt von FHEM, er kann allgemeiner Natur sein, oder sich auf ein spezielles Gerät oder einen speziellen Anwendungsfall beziehen.

== August 2025==
=== FTUI(3) Dateien direkt in FHEMWEB bearbeiten ===
Im Attribut editFileList der [https://fhem.de/commandref_modular.html#FHEMWEB FHEMWEB]-Definition '''zusätzlich zu den Default-Werten''' eintragen:
FTUI (www/tablet):$FW_dir.'/tablet':^.*html$
FTUI3 (www/ftui):$FW_dir.'/ftui':^.*html$

== August 2022==
=== Update ===
Wenn der Befehl "Update" nicht funktioniert und insbesondere die Fehlermeldung ''Bad hostname 'fhem.de:80''' zurück gibt, kann es sinnvoll sein, den Parameter -noSSL zu versuchen. Details dazu im Artikel [[Update]]

== Januar 2022==
=== günstiger Luftfeuchtesensor ===
Der [[HM-CC-TC Funk-Wandthermostat]] ist schon lange abgekündigt. Er wird derzeit oft recht günstig im Netz angeboten und eignet sich daher als billiger "StandAlone" Temperatur- und Luftfeuchtesensor, auch wenn er keinen Ventielantrieb steuern soll.

== Dezember 2020 ==
=== Performance von Notifys ===
Im Tipp vom Dezember 2013 [[Trick der Woche#notify durch mehrere Ereignisse auslösen lassen|notify durch mehrere Ereignisse auslösen lassen]] heisst es:
:''[…] Wenn man aber möchte, dass z.B. "on" und "off" auslöst (um etwa Dim-Befehle auszuschliessen), kann dies wie folgt erreicht werden:''
::<code>define irgendwas notify MeinSchalter:(on|off) …</code>
Performanter ist allerdings:
:<code>define irgendwas notify MeinSchalter:o[nf]+ …</code>
wobei '''o[nf]+''' eine "Regexp" für beliebige Zeichenketten ist, die mit '''o''' anfangen und '''n''' und/oder '''f''' enthalten, also (auch) on und off.

Alternativ kann auch:
:<code>define irgendwas notify MeinSchalter:on|MeinSchalter:off … </code>
verwendet werden.
Die letzten beiden Varianten sparen Ausführungszeit. Ganz allgemein ist es besser, im notify das Suchmuster mit einem [[Regulärer Ausdruck|regulären Ausdruck]] (Regexp) eng zu definieren.

:<code>define irgendwas notify MeinSchalter:on ... </code>
ist performanter als
:<code>define irgendwas notify MeinSchalter { if ($EVENT eq "on" ... </code>
auch wenn das Ergebnis gleich ist.

Allerdings ist
:<code>define irgendwas notify MeinSchalter:on ... </code>
:<code>define irgendwas1 notify MeinSchalter:off ... </code>
langsamer als
:<code>define irgendwas notify MeinSchaltero[nf]+ { if ($EVENT eq "on" ) { fhem( ) } else { fhem("... </code>

Die oben erwähnten "if" sind "perl if"s. Die Verwendung des FHEM Modul DOIF ist deutlich langsamer. Die Betrachtung betrifft sowieso nur langsame Host-Systeme mit gleichzeitig vielen defines. Bei Verwendung z.b. einen Raspberry Pi 4 oder schnellerem Host dürften die Unterschiede vernachlässigbar sein.

== Oktober 2020 ==
=== Entprellen ===
Will man ein notify innerhalb eines bestimmten Zeitraumes nur einmal auslösen lassen, auch wenn er in diesem Zeitraum mehrfach getriggered werden sollte, so bietet sich das [[Attribut]] '''disabledAfterTrigger''' an:
:<code>attr <notify_device> disabledAfterTrigger <Anzahl Sekunden></code>.

== Oktober 2019 ==
=== Funkstörungen durch leere Batterien ===
Unerklärliche Funkstörungen besonders im SlowRF Bereich (z.b. FS20) mit stark verminderter Reichweite von CULs, gestörter [[RFR CUL]] Kommunikation etc. gestörtem Empfang von Funktelegrammen aller Art können ihre Ursache darin haben, dass einige Geräte mit (fast) leeren Batterien unkontrolliert senden und dadurch den Kanal mit Störsignalen verschmutzen. Anfällig sind insbesondere ältere FHT Fenstersensoren wie der [[FHT80TF]], die mit fast leeren Batterien eine Art Rauschen aussenden und damit die '''komplette''' FS20 Kommunikation lahmlegen können, Störungen beeinflussen auch andere Funkprotokolle im selben Frequenzbereich, wie z.b. HM.
Also im Falle unerklärlicher und weitreicher Funkstörungen die Batterien aller Geräte überprüfen.

== Februar 2019 ==
=== Unterräume anlegen ===
[[Datei:Unterraeume.png|350px|thumb|right|Beispiel für einen gegliederten Raum "Steuerung"]]
In [[FHEMWEB]] besteht neben der Möglichkeit, Geräte dadurch übersichtlich anzuordnen, indem diese Gruppen und einfachen Räumen zugeordnet werden, auch die Möglichkeit, Räume weiter zu gliedern und Unterräume zu verwenden. Dazu wird nach der Angabe des Hauptraums der Unterraum, getrennt durch ein "->" angegeben. Beispiele:
attr <DEVICENAME> room Steuerung->Logik
attr <DEVICENAME> room Steuerung->Heizung
'''Hinweis''': Legt man zusätzlich einen Raum ''Steuerung'' an, erscheint dieser als zusätzlicher Eintrag in der Raumliste.

== Januar 2019 ==
=== HomeMatic IP ===
Das [[HomeMatic IP]]-Protokoll unterscheidet sich deutlich vom bisherigen HomeMatic Protokoll, im Grunde ist es ein anderes System, das nur dem Namen nach dem älteren HomeMatic gleicht. HM-IP Geräte können aktuell (Anfang 2019) nur über eine systemeigene Zentrale CCU2 (als physisch vorhandenes Interface) und die HomeMatic-Module in FHEM integriert werden, sind in FHEM jedoch '''nicht''' unmittelbar als Homematic-Geräte ansprechbar.

== Dezember 2018 ==
===HomeMatic Heizungsregler Uhrzeit einstellen===
HomeMatic Thermostate / Heizungsregler wie der HM-CC-TC der der HM-TC-IT-WM-W-EU etc. synchronisieren ihre Uhrzeit täglich etwa gegen Mitternacht mit der Zentrale. Man kann dieses Update aber jederzeit erzingen durch den Befehl
set <DEVICENAME> sysTime

== November 2018 ==
===HomeMatic Heizunggeräte gebraucht gekauft===
HomeMatic Heizunggeräte gebraucht gekauft und jetzt lassen sie sich nicht richtig peeren oder pairen?
Das Problem ist meistens, dass die Geräte noch mit der Zentrale des Verkäufers gepairt oder mit anderen Geräten gepeert sind.
Mit Thermostaten wie der [[HM-CC-TC Funk-Wandthermostat]] oder der Nachfolger [[HM-TC-IT-WM-W-EU Funk-Wandthermostat AP]] können mit Ventilantrieben wie dem [[HM-CC-VD Funk-Stellantrieb]] nur gepeert werden, wenn
* die Thermostaten nicht selbst schon mit einer Zentrale (im FHEM Umfeld also z.b. einer [[Virtueller Controller VCCU]] oder [[HM-[[HM-CFG-LAN LAN Konfigurations-Adapter]] oder ähnliches) gepairt wurden
* die Ventilantriebe nicht selbst mit einer Zentrale gepairt oder mit einem Thermostaten gepeert wurden.

Es ist daher sinnvoll zuerst alle Geräte zurückzusetzen, da viele Verkäufer dies vergessen. Wie das geht steht in der Anleitung.
Beispiele:
* HM-CC-TC -> MENU lange drücken, dann Sonderfunktion "RES" anwählen, mit OK-Taste bestätigen
* HM-CC-VD -> Anlernknopf 10 Sekunden lang drücken. Der Antrieb geht in Zustand A2, nachdem er das Ventil 1x auf- und zugefahren hat geht er in A3, Knopf nochmals drücken.
* HM-TC-IT-WM-W-EU -> Batterien entfernen, alle 3 Tasten gedrückt halten, Batterien einlegen, warten bis "rES" im Display erscheint, Tasten loslassen

== Januar 2018 ==
=== at absolutem Datum ===
Vielen ist nicht klar, dass man mit dem "define … at" auch einfach ein absolutes Datum definieren kann (obwohl es in der Commandref steht). Anstatt umfangreicher DOIF Konstrukte oder "define … at" die täglich ablaufen und testen ob der gewünschte Tag schon erreicht ist, geht auch ein einfaches:

define Licht_Neujahr_2019 at 2019-01-03T06:01:01 set Licht1 on

Allgemein:
define <name> at [<datespec>] <command>
wobei <datespec> = (YYYY-MM-DDTHH:MM:SS) (also in ISO8601 Schreibweise).
Wichtig ist die Angabe mit Sekunden, die nicht weggelassen werden können.

== Dezember 2017 ==
=== perl Version ===
Gelegentlich taucht die Frage auf, welche perl Version zum Betrieb von FHEM minimal erforderlich ist. Bedauerlicherweise lässt sich das aber aktuell nicht definitiv bestimmen.
Rudolf König testet zur Zeit (Ende 2017) mit v5.16 (5 Jahre alt) und v5.24 (ca. 1 Jahr alt).
Sollte sich herausstellen, dass eines seiner Module (vor allem fhem.pl selbst) nicht mit der jeweils ''aktuellen'' perl Version funktioniert, so wird das Modul entsprechend kompatibel gemacht.
Andererseits verwendet Rudolf König nach eigener Aussage (bewusst) keine Features, die eine höhere Version als perl 5.8.3 (immerhin älter als 13 Jahre) voraussetzen. Tatsächlich zeigen aktuelle Installation auf relativ alten BuffaloLinkstation Systemen, dass FEHM mit perl 5.8.3 prinzipiell lauffähig ist.

Rudolf König prüft als Maintainer von fhem.pl aber nicht, welche Mindestversionen andere Entwickler in Ihren Modulen benötigen. Es ist daher möglich oder sogar wahrscheinlich, das einzelne Module höhere Versionen als 5.8.3 benötigen.

Es gibt aktuell keinen Weg, die Mindestanforderungen z.b. automatisiert zu ermitteln.

== November 2017 ==
=== Grundlastmodul ===
Mit einem Grundlastmodul ist es möglich, LED Leuchtmittel an einem Schaltaktor / Dimmer zu betreiben. Dies ist bei manchen nicht möglich, da einige LEDs nachglimmen oder flackern. Das Grundlastmodul, welches parallel zum Verbraucher angeschlossen wird, kann diesen Effekt aufheben, da ein Verbraucher mit ohmscher Last simuliert wird.
Das Modul ermöglicht eventuell auch den Betrieb eines [[RSL 2-Draht Einbauschalter]]s, der bei LED Leuchtmitteln ansonsten nicht eingesetzt werden kann, da zum Betrieb eine Restspannung über den Verbraucher benötigt wird, der bei LED Lampen mit Vorschaltgerät nicht vorhanden ist.

In Frage kommt z.b. ein Eltako ELTA Grundlastelement GLE / PTC, das ca. 5-8 Euro kostet.
Technisch handelt sich dabei um einen PTC, also einen Widerstand mit positivem Temperaturkoeffizient, d.h. der Widerstand sinkt deutlich, wenn das Element kälter wird.

Das genannte Grundlastelement hat folgende Daten:
Kaltwiderstand: 3500 Ω
Einschaltstrom bei 230 V: 65 mA (ca. 15 W)
Verlustleistung nach 60 Sekunden: 0,65 W

Im kalten Zustand lässt der PTC bei 230 Volt einen Strom von ca. 0,065 Ampere zu.
Das reicht, um von Schaltaktoren, Freischaltern, Dimmern etc. als die erforderliche Grundlast erkannt zu werden.
Wird der Stromkreis eingeschaltet, fliesst auch tatsächlich Strom durch den PTC, der sich dadurch schnell erwärmt (das Element wird tatsächlich sogar relativ heiss). Dadurch steigt steigt der Widerstand auf ca 50000-60000 Ohm an und die Verlustleistung sinkt auf unter 1 Watt. Der PTC regelt sich jetzt selber auf eine bestimmte Temperatur und Widerstand ein.

Wird ausgeschaltet, so fliest über den PTC immer noch ein kleiner Reststrom von ca 0,005 Ampere, der als Grundlast reicht, um z.b. Spannungen abzubauen, die LEDs nachflackern lassen, dieser steigt mit Erkalten rasch an, dadurch werden auch Schalter wie die [[RSL 2-Draht Einbauschalter]] mit genug Strom versorgt.

Theoretisch kann also auch ein PTC mit diesen Werten und einer Leistung von ca. 20 Watt selbst gebaut werden, der Preis der Einzelteile liegt bei unter 2 Euro. Das Eltako Element ist bereits mit Isolierung und Anschlussleitungen versehen, mit eigner Arbeitszeit ist der Preisvorteil beim Selberbau also gering.

== Februar 2017 ==
=== at Zeiten ===
at 03:00 -> 1x um 3 Uhr (wann immer das nächste mal 3 Uhr ist, ggf. erst morgen)
at *03:00 -> jeden Tag um 3 Uhr
at +03:00 -> in 3 Stunden
at +*03:00 -> in 3 Stunden und dann alle 3 Stunden erneut
at +*{4}03:00 -> in 3 Stunden und dann alle 3 Stunden erneut, aber nur 4x ausführen.

== Oktober 2016 ==
=== Grundlagen der Heizungssteuerung ===
Der Artikel [[Grundlagen der Heizungssteuerung]] soll einen zentralen Einstiegspunkt und eine Übersicht der Möglichkeiten insb. für Neulinge in FHEM bieten.

=== Batterieüberwachung für Geräte ohne Batteriestatus ===
Es gibt Möglichkeiten um auch bei Geräten ohne Batteriestatus-Reading eine schwache Batterie erkennen zu können: [[Batterie%C3%BCberwachung#Ger.C3.A4te_ohne_Batteriestatus|Geräte ohne Batteriestatus]].

== Mai 2016 ==
=== DbLog reparieren ===
Sollte ein fhem mit DbLog Probleme machen, oder auf der SQL-Konsole Fehler werfen, so ist eine Reparatur der DB fällig. Das ist auf der Kommandozeile verhältnismäßig einfach möglich und wird im Kapitel [[DbLog#Datenbank reparieren]] beschrieben.

=== DbLog bearbeiten ===
Unerwünschte Einträge in den Loggings treten immer wieder mal auf. Wie man dies in einer Datenbank korrigiert, dazu gibt das Kapitel [[DbLog#Bearbeitung von Datenbank-Einträgen]] eine erste Einführung.

=== Pollenflug ===
In dieser schönen Jahreszeit werden manche durch Heuschnupfen geplagt. Auf der Seite [[Pollenflug]] wird beschrieben, wie man eine Pollenvorhersage in fhem einbinden kann - hilft zwar nicht gegen das Niesen, ist aber trotzdem ganz informativ... ;-)

== April 2016 ==
=== HomeMatic und VCCU ===
HomeMatic Nutzer sollten unbedingt eine [[Virtueller Controller VCCU|VCCU]] einrichten und nutzen.
Die Einrichtung ist unaufwändig und schafft jede Menge Vorteile, auch beim Einsetzen nur einer Schnittstelle wie z.B. einem [[HM-CFG-LAN LAN Konfigurations-Adapter]]. Auch die nachträglich Einrichtung ist problemlos, sofern vorher nur ein I/O Gerät ("Funkschnittstelle") verwendet wurde.

== Dezember 2015 ==
===defmod===
In vielen Fällen will man mit einer Aktion gleichzeitig eine andere Aktion bereits für später festlegen, z.b. nach Einschalten einer Heizung durch einen Bewegungsmelder diese eine Stunde später wieder ausschalten.

Dies kann z.B. durch ein Konstrukt dieser Art erledigt werden:
:<code>define Heizung_an notify Bewegung set HZG_WZ desired-temp 22 ;; define reset_Heizung at +01:00:00 set HZG_WZ desired-temp 16</code>

Nachteilig ist, dass bei einer weiteren Auslösung des Bewegungsmelders die Heizzeit nicht verlängert wird, da eine Neudefinition von '''reset_Heizung''' mit der Fehlermeldung '''reset_Heizung already exists, delete it first''' quittiert wird. Die Lösung bisher war, das alte '''reset_Heizung''' zunächst zu löschen und dann erneut mit neuem Zeitstempel anzulegen:
:<code>define Heizung_an notify Bewegung set HZG_WZ desired-temp 22 ;; delete reset_Heizung ;; define reset_Heizung at +01:00:00 set HZG_WZ desired-temp 16</code>
Aber auch dieses umständliche Konstrukt hat noch einen Nachteil: Es erzeugt bei einer ersten Auslösung eine Fehlermeldung, weil '''reset_Heizung''' noch nicht exisitert und daher nicht gelöscht werden kann. Dies liesse sich abfangen, was die Konstruktion weiter verkomplizieren würde.

Daher hat Rudolf König mit FHEM 5.6 den neuen Befehel "defmod" eingeführt, der ein noch nicht existieredendes define neu anlegt (wie "define"), eine bereits vorhandenes aber direkt ändert (wie "delete" und danach "define")

Dadurch lässt sich verkürzt schreiben:
:<code>define Heizung_an notify Bewegung set HZG_WZ desired-temp 22 ;; defmod reset_Heizung at +01:00:00 set HZG_WZ desired-temp 16</code>

== April 2015 ==
===FS20 Timer===
FS20 Aktoren beherrschen zwei verschiedene Timer-Methoden.

Angenommen ein FS20 Device heisse "Lampe" und sei z.B. ein [[FS20_SU_Unterputz-Funk-Schalter|FS20 SU]] (Unterputzschalter), dann kann man mit FHEM sowohl
:<code> set Lampe on-for-timer 30</code>
verwenden um die Lampe 30 Sekunden einzuschalten, aber auch zunächst in den FS20 SU die maximale Einschaltdauer einprogrammieren:
:<code> set Lampe timer 30</code>
Dannach wird jedes normale
:<code> set Lampe on</code>
die Lampe für nur 30 Sekunden einschalten.

Als Timerwerte kommen in beiden Fällen die bekannten [[Trick_der_Woche#FS20_Timerzeiten|128 Sekundenwerte]] von 0,25 Sekunden bis Etwa 4,5 Stunden in Frage.

Es ist offenbar nicht bei allen Aktoren möglich einen einmal eingestellten Timer zu löschen, neue Werte eingeben aber sehr wohl.

Mehr hier: [[FS20_Allgemein#Gerätetimer setzen / löschen|FS20 timer]].

== Februar 2015 ==
=== 1-wire am GPIO4-Port des RaspberryPi funktioniert nicht mehr nach Systemupdate ===
Es kann passieren, dass nach einem Systemupdate (apt-get update oder apt-get dist-upgrade) die 1-wire-Geräte am GPIO4-Port plötzlich nicht mehr funktionieren. Eine Problemlösung dazu ist im Artikel "[[Raspberry Pi und 1-Wire#1-wire am GPIO4-Port funktioniert nicht mehr nach Systemupdate]]" beschrieben.

=== Backup der Konfiguration (fhem.cfg und fhem.state) bei jedem "save" ===
Der nachfolgende Codeschnipsel erstellt bei jedem "save" eine Kopie der aktuellen [[Konfiguration]] (fhem.cfg und fhem.state) in ein Verzeichnis "backup_cfg-state" welches unter /opt/fhem/ zu finden ist. Somit kann bei einem Fehler jederzeit auf den letzten Stand zurückgegangen werden.
Zuerst ins FHEM Befehlsfeld den folgenden Befehl eingeben:
:<code>{ `mkdir backup_cfg-state` } </code>

Danach folgendes [[notify]] anlegen:
define backupCfg notify global:SAVE {\
my $now = TimeNow();; $now =~ s/ /_/g;; \
`cp $attr{global}{configfile} ./backup_cfg-state/fhem.cfg.$now`;;\
`cp $attr{global}{statefile} ./backup_cfg-state/fhem.state.$now`;;\
}

Quelle: {{Link2Forum|Topic=30873|Message=234412|LinkText=FHEM-Forum}}

== Januar 2015 ==
=== CUL & CO über Serial ID-einbinden ===
Bei mehreren USB-Geräten kann es vorkommen, dass sie vertauscht werden z.B. ''/dev/ttyUSB0'' zu'' /dev/ttyUSB1'' oder ''/dev/ttyACM0'' zu ''/dev/ttyACM1''.

Um dies zu umgehen, kann man sie über ihre Serial-ID in FHEM einbinden.

Dieser Befehl zeigt die Serial-ID:

:<code>ls -l /dev/serial/by-id</code>

Hier die Beispielausgabe eines CUL868, JeeLink, RFXtrx und eines CUL433

user@xxxx:~# ls -l /dev/serial/by-id
lrwxrwxrwx 1 root root 13 Jan 9 23:34 usb-busware.de_CUL868-if00 -> ../../ttyACM0
lrwxrwxrwx 1 root root 13 Jan 9 13:26 usb-FTDI_FT232R_USB_UART_A901RQ9F-if00-port0-> ../../ttyUSB0
lrwxrwxrwx 1 root root 13 Jan 9 13:26 usb-RFXCOM_RFXtrx433_A1WZWL5Y-if00-port0-> ../../ttyUSB1
lrwxrwxrwx 1 root root 13 Jan 9 21:29 usb-busware.de_CUL433-if00 -> ../../ttyACM1

Damit lässt sich folgende Definition erstellen:

z.B. für einen CUL868

:<code>define CUL868 CUL /dev/serial/by-id/usb-busware.de_CUL868-if00@9600 1134</code>

oder einen JeeLink

:<code>define Jeelink JeeLink /dev/serial/by-id/usb-FTDI_FT232R_USB_UART_A901RQ9F-if00-port0@57600</code>

'''Einschränkung:''' Bei CULs von Busware lassen sich nur CUL433 und CUL868 unterscheiden. Zwei CUL868 haben z.B. immer die gleiche Serial-ID.

=== HM LAN Konfig-Adapter Antenne verbessern===
Die Antenne des [[HM-CFG-LAN LAN Konfigurations-Adapter]] kann man mit etwas Bastelgeschick verlängern um den Empfang zu verbessern.

Sinnvoll ist die Verlängerung auf 1/2 Lambda (868MHz = 17,27 cm) oder gar 1 Lambda.
1 Lambda Antennen haben starke Richtwirkung in Form eines gedachten Zylinders, dessen Mittelachse die Antenne ist.
D.h., Alles was sich in Richtung des Anfangs und des Endes des Antennedrahtes befindet, hat schlechteren Empfang als mit einer kurzen Antenne. Daher muss man die Antenne ggf. genauer ausrichten.

Anleitungen dazu werden an verschiedenen Stellen veröffentlicht, z.B. in
[http://www.ip-symcon.de/forum/threads/18411-Umbau-HM-LAN-Adapter-auf-Lambda-1-2-Dipol-Antenne diesem Beitrag] im IP-Symcon Forum (anders als der Namen der Anleitung vermuten lässt, liegt hier kein Dipol vor, sondern eine "normale" 1 Lambda Antenne.)

Prinzipiell so dünnen Draht wie möglich verwenden.

Wer noch mehr rausholen will, kann auch zusätzlichen Aufwand betreiben und die Antenne etwas von der Elektronik entfernen, die nämlich Störstrahlung in die Antenne einkoppelt. Oder eine Groundplane bauen.
Ein Anleitung für die CCU (analog auch für den HM LAN Konfig-Adapter einsetzbar) gibt es [http://www.techwriter.de/beispiel/funkeige.htm hier].

== Dezember 2014 ==
=== FHT80TF als "Prüfsender" einsetzen ===
Da der [[FHT80TF-2]] günstig ist und seinen Zustand ca. alle zwei Minuten sendet, kann er gut zum Ermitteln der Funklage von [[SlowRF]] Komponenten genutzt werden, auch wenn diese nicht senden. Den RSSI einer FS20 Schaltsteckdose kann man z.B. nicht wissen, da die Dose nur ein Empfänger ist. Wenn eine Dose nicht gut funktioniert und man den Verdacht hat, dass sie funktechnisch ungünstig liegt, kann man einen [[FHT80TF-2]] neben die Steckdose legen und man bekommt nach zwei Minuten einen Wert, der (trotz umgekehrter Funkrichtung) gut genug ist, um einem Hinweise zu geben.

== November 2014 ==
=== FS20 Adressschema und die Rolle des Hauscodes ===
[[FS20_Allgemein#FS20_Adressierungsschema_.28Vorschlag.29]]

== Oktober 2014 ==
=== Aktor für Wanddosen ohne Nulleiter ===
Es gibt viele Aktoren die man in Einbaudosen hinter Schaltern einbauen kann. Oft scheitert deren Nutzung aber daran, dass in vielen Elektroinstalltionen in der Einbaudose eines (Licht)schalters kein Neutralleiter (Nulleiter) verlegt ist, den die meisten Aktoren zur eigenen Stromversorgung brauchen. Hier kann der [[RSL 2-Draht Einbauschalter]] helfen, der auch ohne Neutraleiter funktioniert und kompatibel zu InterTechno ist. Er lässt sich z.B. mit einem CUL(433) schalten. Problematisch ist damit allerdings das Schalten von LED Lampen.

== August 2014 ==
=== Perl-Skripte Online testen ===
Im Internet existieren Webseiten auf denen man Perl-Code online testen kann. Beispielsweise auf [http://www.tutorialspoint.com/execute_perl_online.php codingground] kann man Code zum Testen eingeben und die Auswirkungen betrachten. Dies eignet sich zur schnellen Fehleranalyse oder um Perl zu lernen. Natürlich lassen sich keine FHEM-Besonderheiten nutzen.

== Juli 2014 ==
=== Funklast reduzieren===
Bewegungsmelder erzeugen in der Regel eine recht hohe Funklast, wenn sie oft ausgelöst werden, also z.B. Licht in einem Zimmer schalten sollen.

Konstruktionen der Art:
:<code>define FlurLicht notify Bewegungsmelder_Flur:motion:.* set Licht_Flur on-for-timer 256</code>
haben daher den Nachteil bei viel Bewegung im Flur und je nach Einstellung des Sendeabstandes des Bewegungsmelders mindestens alle 120 Sekunde oder öfter ein
:<code>on-for-timer 256</code>
zu senden. Das erzeugt eine hohe Funklast, speziell wenn der Aktor ein SlowRF Gerät ist (z.B. FS20 Unterputzschalter).
In solchen Fällen kann es helfen, nur dann einen Befehl zu senden, wenn das Licht nicht schon an ist:
:<code>define FlurLicht notify Bewegungsmelder_Flur:motion:.* { if (Value("Licht_Flur") eq "off") { fhem ("set Licht_Flur1 on-for-timer 256") } }</code>
Nachteilig ist aber, dass eine Auslösung innerhalb 256 Sekunden die Einschaltzeit nicht verlängert. Dies kann man umgehen, indem man nicht on-for-timer verwendet, sondern den Aktor selber verzögert auschaltet und bei weiteren Auslösungen nur die Verzögerung erneut anlegt:
:<code>define FlurLicht notify Bewegungsmelder_Flur:motion:.* { if (Value("Licht_Flur1") eq "off") { fhem ("set Licht_Flur on ;; define FlurLicht_aus at +00:04:16 set Licht_Flur off") } else { fhem ("delete FlurLicht_aus ;; define FlurLicht_aus at +00:04:16 set Licht_Flur off") }}</code>
Durch den relativ neuen Befehl "defmod" kann ausserdem das Löschen und neu Anlegen zusammengefasst werden, sieh Tipp Dezember 2015

== Juni 2014 ==
=== Batteriestatus bei HomeMatic Devices aktivieren===
Zumindest einige (wenn nicht alle) batteriegespeisten HM-Geräte können Batteriemeldungen senden, tun dies in der normalen Konfiguration aber nicht.
Dazu muss das Register cyclicInfoMsg auf on gesetzt werden.

Wie man das macht steht z.B. hier
[[HM-SEC-SC_Tür-Fensterkontakt#Batteriestatus_aktivieren]]
und hier
[[HomeMatic_Type_ThreeState]]

== Mai 2014 ==
=== Dummywert mit aktueller Uhrzeit versehen in anderen Dummy kopieren===
Der Inhalt von Dummy1 soll erweitert um Uhrzeit und Datum in Dummy2 kopiert werden (z.B. um die Urzeit der letzten Auslösung einer Alarmanlage anzuzeigen)
:<code>{ fhem("set dummy2 " . (Value("Dummy1")." ".TimeNow()) ) } </code>

=== Zwei Dummywerte in einen anderen Dummy kopieren ===
Der String in Dummy1 soll um den String in Dummy2 erweitert und nach Dummy3 kopiert werden:
:<code>{ fhem("set Dummy3 ".(Value("Dummy1")+Value("Dummy2"))) } </code>
(Achtung: "+" ist Zahlen addieren, "." ist String konkatenieren / verketten)

== April 2014==
=== Code sparen ===
Wer Definitionen wie die aus dem März zum [[Trick der Woche#Zuverlässigkeit von FS20 Schaltungen erhöhen|Abfangen von Fehlbedienungen]] verwendet, kann durch eine ELSE Erweiterung auch gleich das Auschalten erledigen.
:<code>define act_on_TV_on notify TV { if ("$EVENT" eq "on" || "$EVENT" eq "dimup") { fhem("set TV on") } else { fhem("set TV off") } }</code>

Hierdurch schaltet ON oder versehentlich zu langes Drücken (also DIMUP) den Fernseher ein, jeder ''andere'' Tastendruck (also insbesondere die OFF Taste oder zu langes Drücken der OFF Taste -> DIMDOWN) den Fernseher aus.

Voraussetzung ist, dass die Fernbedienung standardkonfiguriert ist, siehe auch nächster Tip.

=== Konfiguration eines FS20 Senders prüfen ===
Gelegentlich reagieren bestimmte notifys nicht, die von Sendern (Fernbedienungen, Sensoren oder Schaltern) ausgelöst werden sollen. Speziell bei FS20 aber auch bei HomeMatic kann das daran liegen, dass der Sender nicht sendet was man denkt. So gut wie alle FS20 Sender kennen nämlich nicht nur ON und OFF, sondern über ein Dutzend Schaltzustände. Dimmen ist einem noch hinreichend bewusst, es gibt aber auch exotische Dinge wie Ein-für-Zeitdauer, Ein-auf-alte-Helligkeit, Aus-für-Zeitdauer (nur FS20), Ein-für-Zeitdauer-dannach-alter-Zustand und vieles mehr.

Was also ein Infrarot-Bewegungsmelder bei Auslösung sendet und auch was eine Fernbedienungstaste sendet ist einstellbar. Wenn jetzt zum Beispiel an einer Fernbedienung auf Tastendruck nicht ON sondern Ein-für-Zeitdauer (ON-FOR-TIMER) gesendet wird, wird
:<code>define act_on_TV_on notify TVFB:on set TV on</code>
seltsamerweise nicht auslösen, obwohl die richtige Taste (und diese auch nicht zu lang) gedrückt wurde.

Auch wenn man sich sicher ist, das Richtige in die Fernbedienung/Sensoren einprogramiert zu haben, ist ein einfacher Test immer, dies mit
:<code>define act_on_TV notify TVFB set TV on</code>
zu prüfen. Dieses notify löst immer aus, wenn "TVFB" ''irgendetwas'' sendet, egal was. (Beachte: Man kann dann den Fernseher aber nicht mehr ausschalten, da auch die Austaste das notify auslöst und zum TV-Aktor nur "on" sendet).

Geht die Schaltung jetzt (kann man den Fernseher also jetzt EINschalten), liegt der Verdacht nahe, dass die Konfiguration des Senders / Sensors anders ist, als man denkt. Das Logfile, der EventMonitor oder ein Beobachtung von FHEM per Telnet mittels "inform" gibt Aufschluss, welcher Befehl tatsächlich empfangen wurde.

== März 2014==
=== Zuverlässigkeit von FS20 Schaltungen erhöhen ===
FS20 Fernbedienungen senden bei Tastendrücken von mehr als 0,4 Sekunden anstatt ON bzw. OFF DIMUP bzw DIMDOWN.(Auch einige FBs anderer Systeme verhalten sich ähnlich)

Das führt gelegentlich zu allgemein schlechter Bedienbarkeit (und schlechtem WAF), da 0,4 Sekunden relativ kurz ist und gerne aus versehen länger gedrückt wird. Das ist vor allem problematisch, wenn etwas geschaltet werden soll, was keinen Dimmer hat oder Dimmen nicht unterstützt.

Eine Konfiguration wie
:<code>define act_on_TV_on notify TVFB:on set TV on</code>
hat also dann den Nachteil, dass bei versehentlich zu langem Tastendruck auf die Fernbedienung das TV nicht angeht. Da die meisten Nutzer unbewusst dazu neigen, bei Misserfolg die selbe Taste erneut aber länger zu drücken (was erneut keinen Erfolg zeigt) ist Frustration zu erwarten.

Es kann daher speziell bei nicht dimmbaren Aktoren von Vorteil sein, auch dimmen abzufangen, z.B. durch eine zweite zusätzliche Definition:

:<code>define act_on_TV_dimup notify TVFB:dimup set TV on</code>

Es ist in der Regel einfacher, einige dieser zusätzlichen Definitionen einzufügen, als allen Bedienern des Systems zu erklären, dass man keinesfalls länger als 0,4 Sekunden drücken darf.

Alternativ kann man auch beide Befehle in einer Definition durch Perlbefehle {} abfangen:

:<code>define act_on_TV_on notify TVFB { if ("$EVENT" eq "on" || "$EVENT" eq "dimup") { fhem("set TV on") }}</code>

Allerdings hat dies den Nachteil, dass jedes Event dieses define durchläuft und erst später geprüft wird, ob das Event überhaupt irgendetwas auslöst.
Z.B. wird
:<code>define act_on_TV_on notify TVFB ...</code>
auch durch TVFB off ausgelöst (oder unter bestimmten Bedungen sogar duch alle Events), nur um dann nach dem Perl Test festzustellen, dass doch nichts getan werden soll.

Ressourcenschonender ist daher:
:<code>define act_on_TV_on notify TVFB:on|TVFB:dimup set TV on </code>

Andere Möglichkeiten vergleiche: [[Trick der Woche#notify durch mehrere Ereignisse auslösen lassen|Notify durch mehrere Ereignisse auslösen lassen]] und [[Trick der Woche#Performance_von_Notifys|Performance von Notifys]]

== Februar 2014==
=== Sequence nutzen ===
Man kann Aktionen statt mit einem Tastedruck auch mit einer Sequenz von Tastendücken auslösen. Das Format des Befehle ist:

:<code>define <name> sequence <re1> <timeout1> <re2> [<timeout2> <re3> ...] </code>

wobei <re1> ...<re_n> die Aktionen sind und <timeout_n> der maximale Abstand der Tastendrücke in Sekunden.

Angenommen, man wolle z.B. eine Lampe dann anschalten, wenn man zuerst Taste1 EIN, dann Taste2 AUS und dann wieder Taste1 EIN einer Fernbedienung drückt, könnte das konkret so aussehen:

:<code>define MeineLampenSequenz1 sequence Btn1:on 0.5 Btn2:off 0.5 Btn1:on</code>

Zwischen jedem der Tastendrücke darf eine halbe Sekunde Abstand sein. Diese Definition selbst löst die Lampe nicht aus, sondern definiert nur wie die Sequenz aussehen soll. Um die Lampe bei erfolgreicher Betätigung der Sequenz auch einzuschalten, bedarf es zusätzlich etwas wie:

:<code>define MeineLampe notify MeineLampenSequenz1:trigger set Lampe on</code>

Sequence kann man gut nutzen, um mit einer Fernbedienung mehr Funktionen zu schalten als Tasten zur Verfügung stehen. Ebenso könnte man damit simple Codeschlösser für Alarmanlagen bauen, z.B. um eine Anlage auszuschalten, wenn eine bestimmte Abfolge von Tasten gedrückt wird.

Je nach Funksystem nimmt die Zuverlässigkeit aber rasch ab. Angenommen im Bereich FS20 (das System ist etwas unzuverlässiger ist als z.B. HomeMatic) seien 95% aller Funktsignale ungestört übertragbar, dann würden in der Praxis von 100 Tastendrücken an einer Fernbedienung 95x Erfolg zeigen und 5x fehlschlagen; das ist sicher tolerabel.

Bei einer Sequenzlänge von nur 4 Tasten würde die kombinierte Erfolgsquote der Sequenz jedoch nur noch ca. 80% sein, zum Ausschalten einer Alarmanlage vermutlich bereits unpraktisch.

== Januar 2014==
===isday===
Bekanntlich kann man mit "isday" leicht testen ob es draussen hell ist oder nicht. isday ist eine Funktion des (automatisch geladenen) Moduls [[SUNRISE_EL]], das auch sunset und sunrise enthält.

Problematisch bei isday ist die fehlende Möglichkeit, Sonnenaufgang und Untergang einzustellen (zumindest wenn man nicht 99_SUNRISE_EL.pm verändern will): isday ist wahr, wenn die Sonne im gegebenen Breitengrad theoretisch sichtbar ist. Wenn örtliche Gegebenheiten (Bebauung, Bäume, Tal etc.) eine Anpassung erfordern, kann man sich auch ein eigenes isday basteln, in dem man sunrise und sunset verwendet und dieses mit getrennten offsets versieht.

Zuerst definiert man sich eine Variable ("dummy") der anstelle isday eingesetzt werden soll, z.B.:

:<code>define Tageslicht dummy </code>

Dann wird diese mit sunset und sunrise befüllt:

define SetDummy1 at *{sunset(-3600)} set Tageslicht hell
define SetDummy2 at *{sunrise(+1800)} set Tageslicht dunkel

Jetzt kann für jeden Wechsel ein eigener Offset gewählt werden, im Beispiel 3600 Sekunden vor Sonnenuntergang und 1800 Sekunden nach Sonnenaufgang. Anstatt das Dummy "Tageslicht" mit den Werten "hell/dunkel" zu befüllen, kann natürlich auch 1/0 oder "Tag/Nacht" etc. verwendet werden, je nachdem was bei der Anwendung besser passt.

Für höhere Ansprüche könnte hingegen das [[Twilight]]-Modul verwendet werden, das Dämmerungsstufen kennt.

===Struktur von "else if" Verzweigungen===
define ... notify ... {\
if ... {\
fhem ("... ;; ...")\
}\
elsif ... {\
fhem ("... ;; ...")\
}\
elsif ... {\
fhem ("... ;; ...")\
}\
else {\
if ... {\
fhem ("... ;; ...")\
}\
}

Achtung: es muss tatsächlich "elsif" heissen und nicht "elseif" oder "else if".

Gilt für Perl Aufrufe.
Wer aktuell in FHEM neu einsteigt, kann auch den seit 2014 zur Verfügung stehenden FHEM Befehl [[DOIF]] verwenden, der komfortabler ist und zusätzliche Features aufweist.

== Dezember 2013==
===notify durch mehrere Ereignisse auslösen lassen===
Bekanntermassen löst

:<code>define irgendwas notify MeinSchalter …</code>

aus, wenn irgendein Ereignis vom Sender "MeinSchalter" eintrifft.

Mit

:<code>define irgendwas notify MeinSchalter:on …</code>

wird das notify jedoch nur ausgelöst, wenn dieses Ereignis eine "on" ist.
Wenn man aber möchte, das z.B. "on" und "off" auslöst (um etwa Dim-Befehle auszuschliessen) kann dies wie folgt erreicht werden:

:<code>define irgendwas notify MeinSchalter:(on|off) …</code>

Die Klammern sind wichtig, vergleiche eine Lösung, bei der zwei Sender alternativ das notify auslösen können:

:<code>define irgendwas notify MeinSchalter:on|MeinAndererSchalter:on …</code>

Selbstverständlich geht z.B. auch folgendes:

:<code>define irgendwas notify MeinSchalter:on|MeinAndererSchalter …</code>

Hier wird ausgelöst wenn "MeinSchalter" das Ereignis "on" liefert oder "MeinAndererSchalter" irgendein Ereignis. Beachte hierzu jedoch den Tipp vom Dezember 2020 "Performance von Notifys"

=== Aktoren über mehrere Funkschnittstellen ansprechen ===
Falls man mehrere Funkschnittstellen zur Reichweitenverlängerung hat (CUL / CUNO etc), und ein Aktor von beiden Funkschnittstellen in etwa gleich (schlecht) erreichbar ist, mag der Wunsch aufkommen, einen Funkbefehl über beide Schnittstellen auszusenden. Dies ist bei Funkprotokollen möglich, die kein echtes Pairing der Aktoren an die Funkschnittstelle erfordern, also z.B. FS20 oder Intertechno, nicht jedoch ohne weiteres bei HomeMatic.

Problematisch ist aber, dass die Funkschnittstelle über IODev eindeutige je Aktor festgelegt werden muss, eine Zuordnung mehrerer IODevs ist nicht vorgesehen.
(wenn man IODev nicht setzt, wird per default die LETZTE definiert passende Schnittstelle verwendet)

Dieses Problem kann mit einem Trick aber umgangen werden. Und zwar legt man den Aktor 2x mit gleicher Adresse aber abweichenden Namen und IOdevs an, z.B. so:

define brenner_CUL1 FS20 11114244 11
attr brenner_CUL1 IODev CUL1
attr brenner_CUL1 room Keller

define brenner_CUL2 FS20 11114244 11
attr brenner_CUL2 IODev CUL2
attr brenner_CUL2 room Keller

Ein Befehl der Art:

set brenner_CUL1,brenner_CUL2 on

sendet den ON Befehl für den FS20 Aktor 11114244 11 jetzt tatsächlich über beide CULs aus!

Achtung: Wenn die Schnittstellen gleichschnell angebunden sind, sollte vermutlich der [[Sendpool]] verwendet werden, da die Aussendungen sonst tatsächlich gleichzeitig erfolgen könnten und sich dann gegenseitig stören würden. Dieser Trick funktioniert ausserdem nur bei Befehlen, bei denen es im Zweifel egal ist, wenn sie beim Aktor 2x eintreffen.

Bei HomeMatic lässt sich ein ähnlicher Effekt durch einrichten einer [[Virtueller Controller VCCU|virtuellen CCU]] erreichen.

=== Retrycount bei FHTs ist überflüssig===
Das von der Funktion ''autocreate'' älterer FHEM Versionen beim Anlegen von FHT80 Heizungsreglern voreingetragene attribute "retrycount" hat in den allermeisten Fällen keine Wirkung, da es NUR greift, wenn man als Funkschnittstelle eine FHZ1X00PC verwendet und dann den Softbuffer einschaltet. Selbst wenn man diese Konfiguration nutzt, will gut überlegt werden, ob die Wirkung postiv ist: Bei ungenügender Empfangslage vergrössert es Kommunikationsprobleme eventuell sogar.

Es kann also in der Regel entfernt oder auf den Wert "1" gesetzt werden.

define Heizung_Bad FHT 060d
attr Heizung_Bad retrycount 3 <=== Diese Zeile entfernen

Siehe auch:[[Kommunikationsprobleme mit FHT]]

== November 2013 ==
=== FS20 Funksteckdose sicherer schalten===
Seltsamerweise kommt es vor, das FS20 Aktoren - insbesondere die FS20 Funksteckdose - an der Grenze der Funkreichweite bestimmte Befehle eines Typs empfängt, andere aber nicht. Z.B. lässt sich die FS20 Steckdose zwar immer einschalten, aber oft nicht mehr aus (oder umgekehrt).

Gelegentlich kann man die Zuverlässigkeit erhöhen, indem man statt dem nicht funktionierenden Befehl das Gegenteil mit "for-timer 1" verwendet.

Im Fall, dass eine FS20 Steckdose sich also einwandfrei EINschalten lässt:
:<code>set SteckdoseA on</code>
aber oft ein AUSschalten mittels
:<code>set SteckdoseA off</code>
nicht funktioniert, kann man versuchen die Dose anstelle mit "off" mit dem Befehl
:<code>set SteckdoseA on-for-timer 1</code>
auszuschalten.

Analog kann man mit off-for-timer arbeiten, wenn sich Aktoren nicht einschalten lassen, ausschalten aber geht.

Achtung: Dieser Trick funtioniert ausdrücklich nur, wenn der "on/off-for-timer" Befehl im Aktor selber abgebildet wird. Daher ist der Trick vermutlich nicht auf andere Funksysteme übertragbar. z.B. unterstützt HM nur on-for-timer und Intertechno kennt keinen Timer.

=== Mehrere Geräte zugleich schalten===
Ein Ereignis soll mehrere Geräte schalten:

:<code>define act_on_Bewegungsmelder notify Bewegungsmelder set Lampe1 on;;set Lampe2 on;;set FunksteckdoseA on</code>

Aus Übersichtlichkeitsgründen können vor und nach den Semikolons auch Leerzeichen eingefügt werden (obwohl in einigen Dokumentation behauptet wird, dies dürfe man nicht machen):

:<code>define act_on_Bewegungsmelder notify Bewegungsmelder set Lampe1 on ;; set Lampe2 on ;; set FunksteckdoseA on</code>

Wenn der Schaltbefehl bei allen Geräten gleich ist, kann man wie folgt zusammenfassen:

:<code>define act_on_Bewegungsmelder notify Bewegungsmelder set Lampe1,Lampe2,FunksteckdoseA on</code>

Das Komma wird nicht [[Escapen in Perlbefehlen|escaped]] (verdoppelt), hier darf tatsächlich KEIN Leerzeichen vor oder nach dem Komma eingefügt werden.

=== Logfileinträge unterdrücken===
Das Attribute "verbose 0" verhindert, dass das Gerät Logfileinträge erzeugt.

Beispiel:

define Funksteckdose FS20 22224222 01
attr Funksteckdose verbose 0

===FHT Lazy Mode benutzen===
Es gibt wenig Gründe, den FHT "Lazy Mode" nicht zu verwenden
define Heizung_Bad FHT 060d
attr Heizung_Bad lazy

Dieser sorgt dafür, dass Temperaturänderungen (genau genommen alle Änderungen, auch z.B. date) nur übertragen werden, wenn sie nicht sowieso schon am FHT eingestellt sind und veringern die Funklast dadurch deutlich.

Siehe auch: [[Kommunikationsprobleme mit FHT]]

== Oktober 2013 ==
=== Zuverlässigkeit von Wiedereinschalten erhöhen ===
Speziell bei FS20 Aktoren ist wegen des fehlenden Rückkanals nicht leicht erkennbar, ob ein Einschaltbefehl Wirkung gezeigt hat. Das bringt einen ganz schlechten WAF, wenn man z.B. mit einem FS20 Aktor eine Heizung ausschaltet und das Wiedereinschalten nach z.B. einer Stunde nicht klappt.

Hier empfiehlt es sich, das Ausschalten mittels
:<code>set Heizungs_schalter off-for-timer 3584</code> (= fast eine Stunde)
zu erledigen. Da bei FS20 der off-for-timer Befehl im Aktor abgewickelt wird (und nicht durch FHEM), schaltet sich der Aktor auch dann garantiert wieder ein, wenn FHEM abstürzt, eine Funkstörung vorliegt oder ähnliches. Bei Bedarf kann der Befehl off-for-timer zur Verlängerung der Ausschaltzeit wiederholt werden. Dies kann z.B. nötig sein, wenn die Ausschaltung länger als 4,5 Stunden (15360 Sekunden, der Maximalwert des Timers) dauern soll.

Achtung: dieser Trick funktioniert nur, wenn der Aktor "off-for-timer" selbst beherrscht. FS20 Geräte können das, HomeMatic können aber nur "on-for-timer". Man kann off-for-timer mit HomeMatic trotzdem verwenden, aber in diesem Fall sendet FHEM den Einschaltbefehl nach der Timerzeit. InterTechno, RSL etc, können gar keinen Timer, hier sendet FHEM immer 2 Befehle im passenden Abstand.

=== FS20 Timerzeiten ===
FS20 Timer werden in Sekunden angegeben. Es sind jedoch nicht alle Werte einstellbar. Da der Timer Wert in 7 Bit übertragen werden muss, sind nur 128 Werte möglich. Um mit diesen Werten im unteren Bereich möglichst fein aufzulösen, andererseits aber auch lange Zeiten zu ermöglichen, ist die Verteilung nicht linear. Einstellbar sind folgende Zeiten in Sekunden;

0,25 0,5 0,75 1 1,25 1,5 1,75 2 2,25 2,5 2,75 3 3,25 3,5 3,75
4 4,5 5 5,5 6 6,5 7 7,5 8 9 10 11 12 13 14 15 16 18 20 22
24 26 28 30 32 36 40 44 48 52 56 60 64 72 80 88 96 104 112
120 128 144 160 176 192 208 224 240 256 288 320 352 384 416
448 480 512 576 640 704 768 832 896 960 1024 1152 1280 1408
1536 1664 1792 1920 2048 2304 2560 2816 3072 3328 3584 3840 4096
4608 5120 5632 6144 6656 7168 7680 8192 9216 10240 11264 12288
13312 14336 15360
(etwas übersichtlicher formatiert auch [[FS20 Allgemein#ON/OFF Befehle mit Time Parameter|hier]]).

Andere Zeiten werden von FHEM gerundet. Ein neues Setzen des Timer für FS20 löscht den alten Wert.

Auch HomeMatic Aktoren beherrschen Time Parameter, im Gegensatz zu FS20 allerdings kein "off-for-timer". Details dazu im Artikel [[HomeMatic Timerwerte]]

[[Kategorie:HOWTOS]]

Trick der Woche

2025-08-18T10:08:53Z

TomLee: fhem-Dateien editieren

Diese Seite enthält Tipps und Tricks, die zu unbedeutend sind, einen eigenen Artikel zu rechtfertigen, alternative Schreibweisen/Lösungen für eine Problem darstellen, Ungenauigkeiten oder unklare Formulierungen in den offiziellen Dokumenten ergänzen und ähnliches. Jeder Eintrag ist typischerweise sehr kurz (wenige Zeilen lang) und beleuchtet vielleicht nur einen Aspekt von FHEM, er kann allgemeiner Natur sein, oder sich auf ein spezielles Gerät oder einen speziellen Anwendungsfall beziehen.

== August 2025==
=== FTUI(3) Dateien direkt in FHEMWEB bearbeiten ===
Im Attribut editFileList der [https://fhem.de/commandref_modular.html#FHEMWEB FHEMWEB]-Definition '''zusätzlich zu den Default-Werten''' eintragen:
FTUI (www/tablet):$FW_dir.'/tablet':^.*html$
FTUI3 (www/ftui):$FW_dir.'/ftui':^.*html$

== August 2022==
=== Update ===
Wenn der Befehl "Update" nicht funktioniert und insbesondere die Fehlermeldung ''Bad hostname 'fhem.de:80''' zurück gibt, kann es sinnvoll sein, den Parameter -noSSL zu versuchen. Details dazu im Artikel [[Update]]

== Januar 2022==
=== günstiger Luftfeuchtesensor ===
Der [[HM-CC-TC Funk-Wandthermostat]] ist schon lange abgekündigt. Er wird derzeit oft recht günstig im Netz angeboten und eignet sich daher als billiger "StandAlone" Temperatur- und Luftfeuchtesensor, auch wenn er keinen Ventielantrieb steuern soll.

== Dezember 2020 ==
=== Performance von Notifys ===
Im Tipp vom Dezember 2013 [[Trick der Woche#notify durch mehrere Ereignisse auslösen lassen|notify durch mehrere Ereignisse auslösen lassen]] heisst es:
:''[…] Wenn man aber möchte, dass z.B. "on" und "off" auslöst (um etwa Dim-Befehle auszuschliessen), kann dies wie folgt erreicht werden:''
::<code>define irgendwas notify MeinSchalter:(on|off) …</code>
Performanter ist allerdings:
:<code>define irgendwas notify MeinSchalter:o[nf]+ …</code>
wobei '''o[nf]+''' eine "Regexp" für beliebige Zeichenketten ist, die mit '''o''' anfangen und '''n''' und/oder '''f''' enthalten, also (auch) on und off.

Alternativ kann auch:
:<code>define irgendwas notify MeinSchalter:on|MeinSchalter:off … </code>
verwendet werden.
Die letzten beiden Varianten sparen Ausführungszeit. Ganz allgemein ist es besser, im notify das Suchmuster mit einem [[Regulärer Ausdruck|regulären Ausdruck]] (Regexp) eng zu definieren.

:<code>define irgendwas notify MeinSchalter:on ... </code>
ist performanter als
:<code>define irgendwas notify MeinSchalter { if ($EVENT eq "on" ... </code>
auch wenn das Ergebnis gleich ist.

Allerdings ist
:<code>define irgendwas notify MeinSchalter:on ... </code>
:<code>define irgendwas1 notify MeinSchalter:off ... </code>
langsamer als
:<code>define irgendwas notify MeinSchaltero[nf]+ { if ($EVENT eq "on" ) { fhem( ) } else { fhem("... </code>

Die oben erwähnten "if" sind "perl if"s. Die Verwendung des FHEM Modul DOIF ist deutlich langsamer. Die Betrachtung betrifft sowieso nur langsame Host-Systeme mit gleichzeitig vielen defines. Bei Verwendung z.b. einen Raspberry Pi 4 oder schnellerem Host dürften die Unterschiede vernachlässigbar sein.

== Oktober 2020 ==
=== Entprellen ===
Will man ein notify innerhalb eines bestimmten Zeitraumes nur einmal auslösen lassen, auch wenn er in diesem Zeitraum mehrfach getriggered werden sollte, so bietet sich das [[Attribut]] '''disabledAfterTrigger''' an:
:<code>attr <notify_device> disabledAfterTrigger <Anzahl Sekunden></code>.

== Oktober 2019 ==
=== Funkstörungen durch leere Batterien ===
Unerklärliche Funkstörungen besonders im SlowRF Bereich (z.b. FS20) mit stark verminderter Reichweite von CULs, gestörter [[RFR CUL]] Kommunikation etc. gestörtem Empfang von Funktelegrammen aller Art können ihre Ursache darin haben, dass einige Geräte mit (fast) leeren Batterien unkontrolliert senden und dadurch den Kanal mit Störsignalen verschmutzen. Anfällig sind insbesondere ältere FHT Fenstersensoren wie der [[FHT80TF]], die mit fast leeren Batterien eine Art Rauschen aussenden und damit die '''komplette''' FS20 Kommunikation lahmlegen können, Störungen beeinflussen auch andere Funkprotokolle im selben Frequenzbereich, wie z.b. HM.
Also im Falle unerklärlicher und weitreicher Funkstörungen die Batterien aller Geräte überprüfen.

== Februar 2019 ==
=== Unterräume anlegen ===
[[Datei:Unterraeume.png|350px|thumb|right|Beispiel für einen gegliederten Raum "Steuerung"]]
In [[FHEMWEB]] besteht neben der Möglichkeit, Geräte dadurch übersichtlich anzuordnen, indem diese Gruppen und einfachen Räumen zugeordnet werden, auch die Möglichkeit, Räume weiter zu gliedern und Unterräume zu verwenden. Dazu wird nach der Angabe des Hauptraums der Unterraum, getrennt durch ein "->" angegeben. Beispiele:
attr <DEVICENAME> room Steuerung->Logik
attr <DEVICENAME> room Steuerung->Heizung
'''Hinweis''': Legt man zusätzlich einen Raum ''Steuerung'' an, erscheint dieser als zusätzlicher Eintrag in der Raumliste.

== Januar 2019 ==
=== HomeMatic IP ===
Das [[HomeMatic IP]]-Protokoll unterscheidet sich deutlich vom bisherigen HomeMatic Protokoll, im Grunde ist es ein anderes System, das nur dem Namen nach dem älteren HomeMatic gleicht. HM-IP Geräte können aktuell (Anfang 2019) nur über eine systemeigene Zentrale CCU2 (als physisch vorhandenes Interface) und die HomeMatic-Module in FHEM integriert werden, sind in FHEM jedoch '''nicht''' unmittelbar als Homematic-Geräte ansprechbar.

== Dezember 2018 ==
===HomeMatic Heizungsregler Uhrzeit einstellen===
HomeMatic Thermostate / Heizungsregler wie der HM-CC-TC der der HM-TC-IT-WM-W-EU etc. synchronisieren ihre Uhrzeit täglich etwa gegen Mitternacht mit der Zentrale. Man kann dieses Update aber jederzeit erzingen durch den Befehl
set <DEVICENAME> sysTime

== November 2018 ==
===HomeMatic Heizunggeräte gebraucht gekauft===
HomeMatic Heizunggeräte gebraucht gekauft und jetzt lassen sie sich nicht richtig peeren oder pairen?
Das Problem ist meistens, dass die Geräte noch mit der Zentrale des Verkäufers gepairt oder mit anderen Geräten gepeert sind.
Mit Thermostaten wie der [[HM-CC-TC Funk-Wandthermostat]] oder der Nachfolger [[HM-TC-IT-WM-W-EU Funk-Wandthermostat AP]] können mit Ventilantrieben wie dem [[HM-CC-VD Funk-Stellantrieb]] nur gepeert werden, wenn
* die Thermostaten nicht selbst schon mit einer Zentrale (im FHEM Umfeld also z.b. einer [[Virtueller Controller VCCU]] oder [[HM-[[HM-CFG-LAN LAN Konfigurations-Adapter]] oder ähnliches) gepairt wurden
* die Ventilantriebe nicht selbst mit einer Zentrale gepairt oder mit einem Thermostaten gepeert wurden.

Es ist daher sinnvoll zuerst alle Geräte zurückzusetzen, da viele Verkäufer dies vergessen. Wie das geht steht in der Anleitung.
Beispiele:
* HM-CC-TC -> MENU lange drücken, dann Sonderfunktion "RES" anwählen, mit OK-Taste bestätigen
* HM-CC-VD -> Anlernknopf 10 Sekunden lang drücken. Der Antrieb geht in Zustand A2, nachdem er das Ventil 1x auf- und zugefahren hat geht er in A3, Knopf nochmals drücken.
* HM-TC-IT-WM-W-EU -> Batterien entfernen, alle 3 Tasten gedrückt halten, Batterien einlegen, warten bis "rES" im Display erscheint, Tasten loslassen

== Januar 2018 ==
=== at absolutem Datum ===
Vielen ist nicht klar, dass man mit dem "define … at" auch einfach ein absolutes Datum definieren kann (obwohl es in der Commandref steht). Anstatt umfangreicher DOIF Konstrukte oder "define … at" die täglich ablaufen und testen ob der gewünschte Tag schon erreicht ist, geht auch ein einfaches:

define Licht_Neujahr_2019 at 2019-01-03T06:01:01 set Licht1 on

Allgemein:
define <name> at [<datespec>] <command>
wobei <datespec> = (YYYY-MM-DDTHH:MM:SS) (also in ISO8601 Schreibweise).
Wichtig ist die Angabe mit Sekunden, die nicht weggelassen werden können.

== Dezember 2017 ==
=== perl Version ===
Gelegentlich taucht die Frage auf, welche perl Version zum Betrieb von FHEM minimal erforderlich ist. Bedauerlicherweise lässt sich das aber aktuell nicht definitiv bestimmen.
Rudolf König testet zur Zeit (Ende 2017) mit v5.16 (5 Jahre alt) und v5.24 (ca. 1 Jahr alt).
Sollte sich herausstellen, dass eines seiner Module (vor allem fhem.pl selbst) nicht mit der jeweils ''aktuellen'' perl Version funktioniert, so wird das Modul entsprechend kompatibel gemacht.
Andererseits verwendet Rudolf König nach eigener Aussage (bewusst) keine Features, die eine höhere Version als perl 5.8.3 (immerhin älter als 13 Jahre) voraussetzen. Tatsächlich zeigen aktuelle Installation auf relativ alten BuffaloLinkstation Systemen, dass FEHM mit perl 5.8.3 prinzipiell lauffähig ist.

Rudolf König prüft als Maintainer von fhem.pl aber nicht, welche Mindestversionen andere Entwickler in Ihren Modulen benötigen. Es ist daher möglich oder sogar wahrscheinlich, das einzelne Module höhere Versionen als 5.8.3 benötigen.

Es gibt aktuell keinen Weg, die Mindestanforderungen z.b. automatisiert zu ermitteln.

== November 2017 ==
=== Grundlastmodul ===
Mit einem Grundlastmodul ist es möglich, LED Leuchtmittel an einem Schaltaktor / Dimmer zu betreiben. Dies ist bei manchen nicht möglich, da einige LEDs nachglimmen oder flackern. Das Grundlastmodul, welches parallel zum Verbraucher angeschlossen wird, kann diesen Effekt aufheben, da ein Verbraucher mit ohmscher Last simuliert wird.
Das Modul ermöglicht eventuell auch den Betrieb eines [[RSL 2-Draht Einbauschalter]]s, der bei LED Leuchtmitteln ansonsten nicht eingesetzt werden kann, da zum Betrieb eine Restspannung über den Verbraucher benötigt wird, der bei LED Lampen mit Vorschaltgerät nicht vorhanden ist.

In Frage kommt z.b. ein Eltako ELTA Grundlastelement GLE / PTC, das ca. 5-8 Euro kostet.
Technisch handelt sich dabei um einen PTC, also einen Widerstand mit positivem Temperaturkoeffizient, d.h. der Widerstand sinkt deutlich, wenn das Element kälter wird.

Das genannte Grundlastelement hat folgende Daten:
Kaltwiderstand: 3500 Ω
Einschaltstrom bei 230 V: 65 mA (ca. 15 W)
Verlustleistung nach 60 Sekunden: 0,65 W

Im kalten Zustand lässt der PTC bei 230 Volt einen Strom von ca. 0,065 Ampere zu.
Das reicht, um von Schaltaktoren, Freischaltern, Dimmern etc. als die erforderliche Grundlast erkannt zu werden.
Wird der Stromkreis eingeschaltet, fliesst auch tatsächlich Strom durch den PTC, der sich dadurch schnell erwärmt (das Element wird tatsächlich sogar relativ heiss). Dadurch steigt steigt der Widerstand auf ca 50000-60000 Ohm an und die Verlustleistung sinkt auf unter 1 Watt. Der PTC regelt sich jetzt selber auf eine bestimmte Temperatur und Widerstand ein.

Wird ausgeschaltet, so fliest über den PTC immer noch ein kleiner Reststrom von ca 0,005 Ampere, der als Grundlast reicht, um z.b. Spannungen abzubauen, die LEDs nachflackern lassen, dieser steigt mit Erkalten rasch an, dadurch werden auch Schalter wie die [[RSL 2-Draht Einbauschalter]] mit genug Strom versorgt.

Theoretisch kann also auch ein PTC mit diesen Werten und einer Leistung von ca. 20 Watt selbst gebaut werden, der Preis der Einzelteile liegt bei unter 2 Euro. Das Eltako Element ist bereits mit Isolierung und Anschlussleitungen versehen, mit eigner Arbeitszeit ist der Preisvorteil beim Selberbau also gering.

== Februar 2017 ==
=== at Zeiten ===
at 03:00 -> 1x um 3 Uhr (wann immer das nächste mal 3 Uhr ist, ggf. erst morgen)
at *03:00 -> jeden Tag um 3 Uhr
at +03:00 -> in 3 Stunden
at +*03:00 -> in 3 Stunden und dann alle 3 Stunden erneut
at +*{4}03:00 -> in 3 Stunden und dann alle 3 Stunden erneut, aber nur 4x ausführen.

== Oktober 2016 ==
=== Grundlagen der Heizungssteuerung ===
Der Artikel [[Grundlagen der Heizungssteuerung]] soll einen zentralen Einstiegspunkt und eine Übersicht der Möglichkeiten insb. für Neulinge in FHEM bieten.

=== Batterieüberwachung für Geräte ohne Batteriestatus ===
Es gibt Möglichkeiten um auch bei Geräten ohne Batteriestatus-Reading eine schwache Batterie erkennen zu können: [[Batterie%C3%BCberwachung#Ger.C3.A4te_ohne_Batteriestatus|Geräte ohne Batteriestatus]].

== Mai 2016 ==
=== DbLog reparieren ===
Sollte ein fhem mit DbLog Probleme machen, oder auf der SQL-Konsole Fehler werfen, so ist eine Reparatur der DB fällig. Das ist auf der Kommandozeile verhältnismäßig einfach möglich und wird im Kapitel [[DbLog#Datenbank reparieren]] beschrieben.

=== DbLog bearbeiten ===
Unerwünschte Einträge in den Loggings treten immer wieder mal auf. Wie man dies in einer Datenbank korrigiert, dazu gibt das Kapitel [[DbLog#Bearbeitung von Datenbank-Einträgen]] eine erste Einführung.

=== Pollenflug ===
In dieser schönen Jahreszeit werden manche durch Heuschnupfen geplagt. Auf der Seite [[Pollenflug]] wird beschrieben, wie man eine Pollenvorhersage in fhem einbinden kann - hilft zwar nicht gegen das Niesen, ist aber trotzdem ganz informativ... ;-)

== April 2016 ==
=== HomeMatic und VCCU ===
HomeMatic Nutzer sollten unbedingt eine [[Virtueller Controller VCCU|VCCU]] einrichten und nutzen.
Die Einrichtung ist unaufwändig und schafft jede Menge Vorteile, auch beim Einsetzen nur einer Schnittstelle wie z.B. einem [[HM-CFG-LAN LAN Konfigurations-Adapter]]. Auch die nachträglich Einrichtung ist problemlos, sofern vorher nur ein I/O Gerät ("Funkschnittstelle") verwendet wurde.

== Dezember 2015 ==
===defmod===
In vielen Fällen will man mit einer Aktion gleichzeitig eine andere Aktion bereits für später festlegen, z.b. nach Einschalten einer Heizung durch einen Bewegungsmelder diese eine Stunde später wieder ausschalten.

Dies kann z.B. durch ein Konstrukt dieser Art erledigt werden:
:<code>define Heizung_an notify Bewegung set HZG_WZ desired-temp 22 ;; define reset_Heizung at +01:00:00 set HZG_WZ desired-temp 16</code>

Nachteilig ist, dass bei einer weiteren Auslösung des Bewegungsmelders die Heizzeit nicht verlängert wird, da eine Neudefinition von '''reset_Heizung''' mit der Fehlermeldung '''reset_Heizung already exists, delete it first''' quittiert wird. Die Lösung bisher war, das alte '''reset_Heizung''' zunächst zu löschen und dann erneut mit neuem Zeitstempel anzulegen:
:<code>define Heizung_an notify Bewegung set HZG_WZ desired-temp 22 ;; delete reset_Heizung ;; define reset_Heizung at +01:00:00 set HZG_WZ desired-temp 16</code>
Aber auch dieses umständliche Konstrukt hat noch einen Nachteil: Es erzeugt bei einer ersten Auslösung eine Fehlermeldung, weil '''reset_Heizung''' noch nicht exisitert und daher nicht gelöscht werden kann. Dies liesse sich abfangen, was die Konstruktion weiter verkomplizieren würde.

Daher hat Rudolf König mit FHEM 5.6 den neuen Befehel "defmod" eingeführt, der ein noch nicht existieredendes define neu anlegt (wie "define"), eine bereits vorhandenes aber direkt ändert (wie "delete" und danach "define")

Dadurch lässt sich verkürzt schreiben:
:<code>define Heizung_an notify Bewegung set HZG_WZ desired-temp 22 ;; defmod reset_Heizung at +01:00:00 set HZG_WZ desired-temp 16</code>

== April 2015 ==
===FS20 Timer===
FS20 Aktoren beherrschen zwei verschiedene Timer-Methoden.

Angenommen ein FS20 Device heisse "Lampe" und sei z.B. ein [[FS20_SU_Unterputz-Funk-Schalter|FS20 SU]] (Unterputzschalter), dann kann man mit FHEM sowohl
:<code> set Lampe on-for-timer 30</code>
verwenden um die Lampe 30 Sekunden einzuschalten, aber auch zunächst in den FS20 SU die maximale Einschaltdauer einprogrammieren:
:<code> set Lampe timer 30</code>
Dannach wird jedes normale
:<code> set Lampe on</code>
die Lampe für nur 30 Sekunden einschalten.

Als Timerwerte kommen in beiden Fällen die bekannten [[Trick_der_Woche#FS20_Timerzeiten|128 Sekundenwerte]] von 0,25 Sekunden bis Etwa 4,5 Stunden in Frage.

Es ist offenbar nicht bei allen Aktoren möglich einen einmal eingestellten Timer zu löschen, neue Werte eingeben aber sehr wohl.

Mehr hier: [[FS20_Allgemein#Gerätetimer setzen / löschen|FS20 timer]].

== Februar 2015 ==
=== 1-wire am GPIO4-Port des RaspberryPi funktioniert nicht mehr nach Systemupdate ===
Es kann passieren, dass nach einem Systemupdate (apt-get update oder apt-get dist-upgrade) die 1-wire-Geräte am GPIO4-Port plötzlich nicht mehr funktionieren. Eine Problemlösung dazu ist im Artikel "[[Raspberry Pi und 1-Wire#1-wire am GPIO4-Port funktioniert nicht mehr nach Systemupdate]]" beschrieben.

=== Backup der Konfiguration (fhem.cfg und fhem.state) bei jedem "save" ===
Der nachfolgende Codeschnipsel erstellt bei jedem "save" eine Kopie der aktuellen [[Konfiguration]] (fhem.cfg und fhem.state) in ein Verzeichnis "backup_cfg-state" welches unter /opt/fhem/ zu finden ist. Somit kann bei einem Fehler jederzeit auf den letzten Stand zurückgegangen werden.
Zuerst ins FHEM Befehlsfeld den folgenden Befehl eingeben:
:<code>{ `mkdir backup_cfg-state` } </code>

Danach folgendes [[notify]] anlegen:
define backupCfg notify global:SAVE {\
my $now = TimeNow();; $now =~ s/ /_/g;; \
`cp $attr{global}{configfile} ./backup_cfg-state/fhem.cfg.$now`;;\
`cp $attr{global}{statefile} ./backup_cfg-state/fhem.state.$now`;;\
}

Quelle: {{Link2Forum|Topic=30873|Message=234412|LinkText=FHEM-Forum}}

== Januar 2015 ==
=== CUL & CO über Serial ID-einbinden ===
Bei mehreren USB-Geräten kann es vorkommen, dass sie vertauscht werden z.B. ''/dev/ttyUSB0'' zu'' /dev/ttyUSB1'' oder ''/dev/ttyACM0'' zu ''/dev/ttyACM1''.

Um dies zu umgehen, kann man sie über ihre Serial-ID in FHEM einbinden.

Dieser Befehl zeigt die Serial-ID:

:<code>ls -l /dev/serial/by-id</code>

Hier die Beispielausgabe eines CUL868, JeeLink, RFXtrx und eines CUL433

user@xxxx:~# ls -l /dev/serial/by-id
lrwxrwxrwx 1 root root 13 Jan 9 23:34 usb-busware.de_CUL868-if00 -> ../../ttyACM0
lrwxrwxrwx 1 root root 13 Jan 9 13:26 usb-FTDI_FT232R_USB_UART_A901RQ9F-if00-port0-> ../../ttyUSB0
lrwxrwxrwx 1 root root 13 Jan 9 13:26 usb-RFXCOM_RFXtrx433_A1WZWL5Y-if00-port0-> ../../ttyUSB1
lrwxrwxrwx 1 root root 13 Jan 9 21:29 usb-busware.de_CUL433-if00 -> ../../ttyACM1

Damit lässt sich folgende Definition erstellen:

z.B. für einen CUL868

:<code>define CUL868 CUL /dev/serial/by-id/usb-busware.de_CUL868-if00@9600 1134</code>

oder einen JeeLink

:<code>define Jeelink JeeLink /dev/serial/by-id/usb-FTDI_FT232R_USB_UART_A901RQ9F-if00-port0@57600</code>

'''Einschränkung:''' Bei CULs von Busware lassen sich nur CUL433 und CUL868 unterscheiden. Zwei CUL868 haben z.B. immer die gleiche Serial-ID.

=== HM LAN Konfig-Adapter Antenne verbessern===
Die Antenne des [[HM-CFG-LAN LAN Konfigurations-Adapter]] kann man mit etwas Bastelgeschick verlängern um den Empfang zu verbessern.

Sinnvoll ist die Verlängerung auf 1/2 Lambda (868MHz = 17,27 cm) oder gar 1 Lambda.
1 Lambda Antennen haben starke Richtwirkung in Form eines gedachten Zylinders, dessen Mittelachse die Antenne ist.
D.h., Alles was sich in Richtung des Anfangs und des Endes des Antennedrahtes befindet, hat schlechteren Empfang als mit einer kurzen Antenne. Daher muss man die Antenne ggf. genauer ausrichten.

Anleitungen dazu werden an verschiedenen Stellen veröffentlicht, z.B. in
[http://www.ip-symcon.de/forum/threads/18411-Umbau-HM-LAN-Adapter-auf-Lambda-1-2-Dipol-Antenne diesem Beitrag] im IP-Symcon Forum (anders als der Namen der Anleitung vermuten lässt, liegt hier kein Dipol vor, sondern eine "normale" 1 Lambda Antenne.)

Prinzipiell so dünnen Draht wie möglich verwenden.

Wer noch mehr rausholen will, kann auch zusätzlichen Aufwand betreiben und die Antenne etwas von der Elektronik entfernen, die nämlich Störstrahlung in die Antenne einkoppelt. Oder eine Groundplane bauen.
Ein Anleitung für die CCU (analog auch für den HM LAN Konfig-Adapter einsetzbar) gibt es [http://www.techwriter.de/beispiel/funkeige.htm hier].

== Dezember 2014 ==
=== FHT80TF als "Prüfsender" einsetzen ===
Da der [[FHT80TF-2]] günstig ist und seinen Zustand ca. alle zwei Minuten sendet, kann er gut zum Ermitteln der Funklage von [[SlowRF]] Komponenten genutzt werden, auch wenn diese nicht senden. Den RSSI einer FS20 Schaltsteckdose kann man z.B. nicht wissen, da die Dose nur ein Empfänger ist. Wenn eine Dose nicht gut funktioniert und man den Verdacht hat, dass sie funktechnisch ungünstig liegt, kann man einen [[FHT80TF-2]] neben die Steckdose legen und man bekommt nach zwei Minuten einen Wert, der (trotz umgekehrter Funkrichtung) gut genug ist, um einem Hinweise zu geben.

== November 2014 ==
=== FS20 Adressschema und die Rolle des Hauscodes ===
[[FS20_Allgemein#FS20_Adressierungsschema_.28Vorschlag.29]]

== Oktober 2014 ==
=== Aktor für Wanddosen ohne Nulleiter ===
Es gibt viele Aktoren die man in Einbaudosen hinter Schaltern einbauen kann. Oft scheitert deren Nutzung aber daran, dass in vielen Elektroinstalltionen in der Einbaudose eines (Licht)schalters kein Neutralleiter (Nulleiter) verlegt ist, den die meisten Aktoren zur eigenen Stromversorgung brauchen. Hier kann der [[RSL 2-Draht Einbauschalter]] helfen, der auch ohne Neutraleiter funktioniert und kompatibel zu InterTechno ist. Er lässt sich z.B. mit einem CUL(433) schalten. Problematisch ist damit allerdings das Schalten von LED Lampen.

== August 2014 ==
=== Perl-Skripte Online testen ===
Im Internet existieren Webseiten auf denen man Perl-Code online testen kann. Beispielsweise auf [http://www.tutorialspoint.com/execute_perl_online.php codingground] kann man Code zum Testen eingeben und die Auswirkungen betrachten. Dies eignet sich zur schnellen Fehleranalyse oder um Perl zu lernen. Natürlich lassen sich keine FHEM-Besonderheiten nutzen.

== Juli 2014 ==
=== Funklast reduzieren===
Bewegungsmelder erzeugen in der Regel eine recht hohe Funklast, wenn sie oft ausgelöst werden, also z.B. Licht in einem Zimmer schalten sollen.

Konstruktionen der Art:
:<code>define FlurLicht notify Bewegungsmelder_Flur:motion:.* set Licht_Flur on-for-timer 256</code>
haben daher den Nachteil bei viel Bewegung im Flur und je nach Einstellung des Sendeabstandes des Bewegungsmelders mindestens alle 120 Sekunde oder öfter ein
:<code>on-for-timer 256</code>
zu senden. Das erzeugt eine hohe Funklast, speziell wenn der Aktor ein SlowRF Gerät ist (z.B. FS20 Unterputzschalter).
In solchen Fällen kann es helfen, nur dann einen Befehl zu senden, wenn das Licht nicht schon an ist:
:<code>define FlurLicht notify Bewegungsmelder_Flur:motion:.* { if (Value("Licht_Flur") eq "off") { fhem ("set Licht_Flur1 on-for-timer 256") } }</code>
Nachteilig ist aber, dass eine Auslösung innerhalb 256 Sekunden die Einschaltzeit nicht verlängert. Dies kann man umgehen, indem man nicht on-for-timer verwendet, sondern den Aktor selber verzögert auschaltet und bei weiteren Auslösungen nur die Verzögerung erneut anlegt:
:<code>define FlurLicht notify Bewegungsmelder_Flur:motion:.* { if (Value("Licht_Flur1") eq "off") { fhem ("set Licht_Flur on ;; define FlurLicht_aus at +00:04:16 set Licht_Flur off") } else { fhem ("delete FlurLicht_aus ;; define FlurLicht_aus at +00:04:16 set Licht_Flur off") }}</code>
Durch den relativ neuen Befehl "defmod" kann ausserdem das Löschen und neu Anlegen zusammengefasst werden, sieh Tipp Dezember 2015

== Juni 2014 ==
=== Batteriestatus bei HomeMatic Devices aktivieren===
Zumindest einige (wenn nicht alle) batteriegespeisten HM-Geräte können Batteriemeldungen senden, tun dies in der normalen Konfiguration aber nicht.
Dazu muss das Register cyclicInfoMsg auf on gesetzt werden.

Wie man das macht steht z.B. hier
[[HM-SEC-SC_Tür-Fensterkontakt#Batteriestatus_aktivieren]]
und hier
[[HomeMatic_Type_ThreeState]]

== Mai 2014 ==
=== Dummywert mit aktueller Uhrzeit versehen in anderen Dummy kopieren===
Der Inhalt von Dummy1 soll erweitert um Uhrzeit und Datum in Dummy2 kopiert werden (z.B. um die Urzeit der letzten Auslösung einer Alarmanlage anzuzeigen)
:<code>{ fhem("set dummy2 " . (Value("Dummy1")." ".TimeNow()) ) } </code>

=== Zwei Dummywerte in einen anderen Dummy kopieren ===
Der String in Dummy1 soll um den String in Dummy2 erweitert und nach Dummy3 kopiert werden:
:<code>{ fhem("set Dummy3 ".(Value("Dummy1")+Value("Dummy2"))) } </code>
(Achtung: "+" ist Zahlen addieren, "." ist String konkatenieren / verketten)

== April 2014==
=== Code sparen ===
Wer Definitionen wie die aus dem März zum [[Trick der Woche#Zuverlässigkeit von FS20 Schaltungen erhöhen|Abfangen von Fehlbedienungen]] verwendet, kann durch eine ELSE Erweiterung auch gleich das Auschalten erledigen.
:<code>define act_on_TV_on notify TV { if ("$EVENT" eq "on" || "$EVENT" eq "dimup") { fhem("set TV on") } else { fhem("set TV off") } }</code>

Hierdurch schaltet ON oder versehentlich zu langes Drücken (also DIMUP) den Fernseher ein, jeder ''andere'' Tastendruck (also insbesondere die OFF Taste oder zu langes Drücken der OFF Taste -> DIMDOWN) den Fernseher aus.

Voraussetzung ist, dass die Fernbedienung standardkonfiguriert ist, siehe auch nächster Tip.

=== Konfiguration eines FS20 Senders prüfen ===
Gelegentlich reagieren bestimmte notifys nicht, die von Sendern (Fernbedienungen, Sensoren oder Schaltern) ausgelöst werden sollen. Speziell bei FS20 aber auch bei HomeMatic kann das daran liegen, dass der Sender nicht sendet was man denkt. So gut wie alle FS20 Sender kennen nämlich nicht nur ON und OFF, sondern über ein Dutzend Schaltzustände. Dimmen ist einem noch hinreichend bewusst, es gibt aber auch exotische Dinge wie Ein-für-Zeitdauer, Ein-auf-alte-Helligkeit, Aus-für-Zeitdauer (nur FS20), Ein-für-Zeitdauer-dannach-alter-Zustand und vieles mehr.

Was also ein Infrarot-Bewegungsmelder bei Auslösung sendet und auch was eine Fernbedienungstaste sendet ist einstellbar. Wenn jetzt zum Beispiel an einer Fernbedienung auf Tastendruck nicht ON sondern Ein-für-Zeitdauer (ON-FOR-TIMER) gesendet wird, wird
:<code>define act_on_TV_on notify TVFB:on set TV on</code>
seltsamerweise nicht auslösen, obwohl die richtige Taste (und diese auch nicht zu lang) gedrückt wurde.

Auch wenn man sich sicher ist, das Richtige in die Fernbedienung/Sensoren einprogramiert zu haben, ist ein einfacher Test immer, dies mit
:<code>define act_on_TV notify TVFB set TV on</code>
zu prüfen. Dieses notify löst immer aus, wenn "TVFB" ''irgendetwas'' sendet, egal was. (Beachte: Man kann dann den Fernseher aber nicht mehr ausschalten, da auch die Austaste das notify auslöst und zum TV-Aktor nur "on" sendet).

Geht die Schaltung jetzt (kann man den Fernseher also jetzt EINschalten), liegt der Verdacht nahe, dass die Konfiguration des Senders / Sensors anders ist, als man denkt. Das Logfile, der EventMonitor oder ein Beobachtung von FHEM per Telnet mittels "inform" gibt Aufschluss, welcher Befehl tatsächlich empfangen wurde.

== März 2014==
=== Zuverlässigkeit von FS20 Schaltungen erhöhen ===
FS20 Fernbedienungen senden bei Tastendrücken von mehr als 0,4 Sekunden anstatt ON bzw. OFF DIMUP bzw DIMDOWN.(Auch einige FBs anderer Systeme verhalten sich ähnlich)

Das führt gelegentlich zu allgemein schlechter Bedienbarkeit (und schlechtem WAF), da 0,4 Sekunden relativ kurz ist und gerne aus versehen länger gedrückt wird. Das ist vor allem problematisch, wenn etwas geschaltet werden soll, was keinen Dimmer hat oder Dimmen nicht unterstützt.

Eine Konfiguration wie
:<code>define act_on_TV_on notify TVFB:on set TV on</code>
hat also dann den Nachteil, dass bei versehentlich zu langem Tastendruck auf die Fernbedienung das TV nicht angeht. Da die meisten Nutzer unbewusst dazu neigen, bei Misserfolg die selbe Taste erneut aber länger zu drücken (was erneut keinen Erfolg zeigt) ist Frustration zu erwarten.

Es kann daher speziell bei nicht dimmbaren Aktoren von Vorteil sein, auch dimmen abzufangen, z.B. durch eine zweite zusätzliche Definition:

:<code>define act_on_TV_dimup notify TVFB:dimup set TV on</code>

Es ist in der Regel einfacher, einige dieser zusätzlichen Definitionen einzufügen, als allen Bedienern des Systems zu erklären, dass man keinesfalls länger als 0,4 Sekunden drücken darf.

Alternativ kann man auch beide Befehle in einer Definition durch Perlbefehle {} abfangen:

:<code>define act_on_TV_on notify TVFB { if ("$EVENT" eq "on" || "$EVENT" eq "dimup") { fhem("set TV on") }}</code>

Allerdings hat dies den Nachteil, dass jedes Event dieses define durchläuft und erst später geprüft wird, ob das Event überhaupt irgendetwas auslöst.
Z.B. wird
:<code>define act_on_TV_on notify TVFB ...</code>
auch durch TVFB off ausgelöst (oder unter bestimmten Bedungen sogar duch alle Events), nur um dann nach dem Perl Test festzustellen, dass doch nichts getan werden soll.

Ressourcenschonender ist daher:
:<code>define act_on_TV_on notify TVFB:on|TVFB:dimup set TV on </code>

Andere Möglichkeiten vergleiche: [[Trick der Woche#notify durch mehrere Ereignisse auslösen lassen|Notify durch mehrere Ereignisse auslösen lassen]] und [[Trick der Woche#Performance_von_Notifys|Performance von Notifys]]

== Februar 2014==
=== Sequence nutzen ===
Man kann Aktionen statt mit einem Tastedruck auch mit einer Sequenz von Tastendücken auslösen. Das Format des Befehle ist:

:<code>define <name> sequence <re1> <timeout1> <re2> [<timeout2> <re3> ...] </code>

wobei <re1> ...<re_n> die Aktionen sind und <timeout_n> der maximale Abstand der Tastendrücke in Sekunden.

Angenommen, man wolle z.B. eine Lampe dann anschalten, wenn man zuerst Taste1 EIN, dann Taste2 AUS und dann wieder Taste1 EIN einer Fernbedienung drückt, könnte das konkret so aussehen:

:<code>define MeineLampenSequenz1 sequence Btn1:on 0.5 Btn2:off 0.5 Btn1:on</code>

Zwischen jedem der Tastendrücke darf eine halbe Sekunde Abstand sein. Diese Definition selbst löst die Lampe nicht aus, sondern definiert nur wie die Sequenz aussehen soll. Um die Lampe bei erfolgreicher Betätigung der Sequenz auch einzuschalten, bedarf es zusätzlich etwas wie:

:<code>define MeineLampe notify MeineLampenSequenz1:trigger set Lampe on</code>

Sequence kann man gut nutzen, um mit einer Fernbedienung mehr Funktionen zu schalten als Tasten zur Verfügung stehen. Ebenso könnte man damit simple Codeschlösser für Alarmanlagen bauen, z.B. um eine Anlage auszuschalten, wenn eine bestimmte Abfolge von Tasten gedrückt wird.

Je nach Funksystem nimmt die Zuverlässigkeit aber rasch ab. Angenommen im Bereich FS20 (das System ist etwas unzuverlässiger ist als z.B. HomeMatic) seien 95% aller Funktsignale ungestört übertragbar, dann würden in der Praxis von 100 Tastendrücken an einer Fernbedienung 95x Erfolg zeigen und 5x fehlschlagen; das ist sicher tolerabel.

Bei einer Sequenzlänge von nur 4 Tasten würde die kombinierte Erfolgsquote der Sequenz jedoch nur noch ca. 80% sein, zum Ausschalten einer Alarmanlage vermutlich bereits unpraktisch.

== Januar 2014==
===isday===
Bekanntlich kann man mit "isday" leicht testen ob es draussen hell ist oder nicht. isday ist eine Funktion des (automatisch geladenen) Moduls [[SUNRISE_EL]], das auch sunset und sunrise enthält.

Problematisch bei isday ist die fehlende Möglichkeit, Sonnenaufgang und Untergang einzustellen (zumindest wenn man nicht 99_SUNRISE_EL.pm verändern will): isday ist wahr, wenn die Sonne im gegebenen Breitengrad theoretisch sichtbar ist. Wenn örtliche Gegebenheiten (Bebauung, Bäume, Tal etc.) eine Anpassung erfordern, kann man sich auch ein eigenes isday basteln, in dem man sunrise und sunset verwendet und dieses mit getrennten offsets versieht.

Zuerst definiert man sich eine Variable ("dummy") der anstelle isday eingesetzt werden soll, z.B.:

:<code>define Tageslicht dummy </code>

Dann wird diese mit sunset und sunrise befüllt:

define SetDummy1 at *{sunset(-3600)} set Tageslicht hell
define SetDummy2 at *{sunrise(+1800)} set Tageslicht dunkel

Jetzt kann für jeden Wechsel ein eigener Offset gewählt werden, im Beispiel 3600 Sekunden vor Sonnenuntergang und 1800 Sekunden nach Sonnenaufgang. Anstatt das Dummy "Tageslicht" mit den Werten "hell/dunkel" zu befüllen, kann natürlich auch 1/0 oder "Tag/Nacht" etc. verwendet werden, je nachdem was bei der Anwendung besser passt.

Für höhere Ansprüche könnte hingegen das [[Twilight]]-Modul verwendet werden, das Dämmerungsstufen kennt.

===Struktur von "else if" Verzweigungen===
define ... notify ... {\
if ... {\
fhem ("... ;; ...")\
}\
elsif ... {\
fhem ("... ;; ...")\
}\
elsif ... {\
fhem ("... ;; ...")\
}\
else {\
if ... {\
fhem ("... ;; ...")\
}\
}

Achtung: es muss tatsächlich "elsif" heissen und nicht "elseif" oder "else if".

Gilt für Perl Aufrufe.
Wer aktuell in FHEM neu einsteigt, kann auch den seit 2014 zur Verfügung stehenden FHEM Befehl [[DOIF]] verwenden, der komfortabler ist und zusätzliche Features aufweist.

== Dezember 2013==
===notify durch mehrere Ereignisse auslösen lassen===
Bekanntermassen löst

:<code>define irgendwas notify MeinSchalter …</code>

aus, wenn irgendein Ereignis vom Sender "MeinSchalter" eintrifft.

Mit

:<code>define irgendwas notify MeinSchalter:on …</code>

wird das notify jedoch nur ausgelöst, wenn dieses Ereignis eine "on" ist.
Wenn man aber möchte, das z.B. "on" und "off" auslöst (um etwa Dim-Befehle auszuschliessen) kann dies wie folgt erreicht werden:

:<code>define irgendwas notify MeinSchalter:(on|off) …</code>

Die Klammern sind wichtig, vergleiche eine Lösung, bei der zwei Sender alternativ das notify auslösen können:

:<code>define irgendwas notify MeinSchalter:on|MeinAndererSchalter:on …</code>

Selbstverständlich geht z.B. auch folgendes:

:<code>define irgendwas notify MeinSchalter:on|MeinAndererSchalter …</code>

Hier wird ausgelöst wenn "MeinSchalter" das Ereignis "on" liefert oder "MeinAndererSchalter" irgendein Ereignis. Beachte hierzu jedoch den Tipp vom Dezember 2020 "Performance von Notifys"

=== Aktoren über mehrere Funkschnittstellen ansprechen ===
Falls man mehrere Funkschnittstellen zur Reichweitenverlängerung hat (CUL / CUNO etc), und ein Aktor von beiden Funkschnittstellen in etwa gleich (schlecht) erreichbar ist, mag der Wunsch aufkommen, einen Funkbefehl über beide Schnittstellen auszusenden. Dies ist bei Funkprotokollen möglich, die kein echtes Pairing der Aktoren an die Funkschnittstelle erfordern, also z.B. FS20 oder Intertechno, nicht jedoch ohne weiteres bei HomeMatic.

Problematisch ist aber, dass die Funkschnittstelle über IODev eindeutige je Aktor festgelegt werden muss, eine Zuordnung mehrerer IODevs ist nicht vorgesehen.
(wenn man IODev nicht setzt, wird per default die LETZTE definiert passende Schnittstelle verwendet)

Dieses Problem kann mit einem Trick aber umgangen werden. Und zwar legt man den Aktor 2x mit gleicher Adresse aber abweichenden Namen und IOdevs an, z.B. so:

define brenner_CUL1 FS20 11114244 11
attr brenner_CUL1 IODev CUL1
attr brenner_CUL1 room Keller

define brenner_CUL2 FS20 11114244 11
attr brenner_CUL2 IODev CUL2
attr brenner_CUL2 room Keller

Ein Befehl der Art:

set brenner_CUL1,brenner_CUL2 on

sendet den ON Befehl für den FS20 Aktor 11114244 11 jetzt tatsächlich über beide CULs aus!

Achtung: Wenn die Schnittstellen gleichschnell angebunden sind, sollte vermutlich der [[Sendpool]] verwendet werden, da die Aussendungen sonst tatsächlich gleichzeitig erfolgen könnten und sich dann gegenseitig stören würden. Dieser Trick funktioniert ausserdem nur bei Befehlen, bei denen es im Zweifel egal ist, wenn sie beim Aktor 2x eintreffen.

Bei HomeMatic lässt sich ein ähnlicher Effekt durch einrichten einer [[Virtueller Controller VCCU|virtuellen CCU]] erreichen.

=== Retrycount bei FHTs ist überflüssig===
Das von der Funktion ''autocreate'' älterer FHEM Versionen beim Anlegen von FHT80 Heizungsreglern voreingetragene attribute "retrycount" hat in den allermeisten Fällen keine Wirkung, da es NUR greift, wenn man als Funkschnittstelle eine FHZ1X00PC verwendet und dann den Softbuffer einschaltet. Selbst wenn man diese Konfiguration nutzt, will gut überlegt werden, ob die Wirkung postiv ist: Bei ungenügender Empfangslage vergrössert es Kommunikationsprobleme eventuell sogar.

Es kann also in der Regel entfernt oder auf den Wert "1" gesetzt werden.

define Heizung_Bad FHT 060d
attr Heizung_Bad retrycount 3 <=== Diese Zeile entfernen

Siehe auch:[[Kommunikationsprobleme mit FHT]]

== November 2013 ==
=== FS20 Funksteckdose sicherer schalten===
Seltsamerweise kommt es vor, das FS20 Aktoren - insbesondere die FS20 Funksteckdose - an der Grenze der Funkreichweite bestimmte Befehle eines Typs empfängt, andere aber nicht. Z.B. lässt sich die FS20 Steckdose zwar immer einschalten, aber oft nicht mehr aus (oder umgekehrt).

Gelegentlich kann man die Zuverlässigkeit erhöhen, indem man statt dem nicht funktionierenden Befehl das Gegenteil mit "for-timer 1" verwendet.

Im Fall, dass eine FS20 Steckdose sich also einwandfrei EINschalten lässt:
:<code>set SteckdoseA on</code>
aber oft ein AUSschalten mittels
:<code>set SteckdoseA off</code>
nicht funktioniert, kann man versuchen die Dose anstelle mit "off" mit dem Befehl
:<code>set SteckdoseA on-for-timer 1</code>
auszuschalten.

Analog kann man mit off-for-timer arbeiten, wenn sich Aktoren nicht einschalten lassen, ausschalten aber geht.

Achtung: Dieser Trick funtioniert ausdrücklich nur, wenn der "on/off-for-timer" Befehl im Aktor selber abgebildet wird. Daher ist der Trick vermutlich nicht auf andere Funksysteme übertragbar. z.B. unterstützt HM nur on-for-timer und Intertechno kennt keinen Timer.

=== Mehrere Geräte zugleich schalten===
Ein Ereignis soll mehrere Geräte schalten:

:<code>define act_on_Bewegungsmelder notify Bewegungsmelder set Lampe1 on;;set Lampe2 on;;set FunksteckdoseA on</code>

Aus Übersichtlichkeitsgründen können vor und nach den Semikolons auch Leerzeichen eingefügt werden (obwohl in einigen Dokumentation behauptet wird, dies dürfe man nicht machen):

:<code>define act_on_Bewegungsmelder notify Bewegungsmelder set Lampe1 on ;; set Lampe2 on ;; set FunksteckdoseA on</code>

Wenn der Schaltbefehl bei allen Geräten gleich ist, kann man wie folgt zusammenfassen:

:<code>define act_on_Bewegungsmelder notify Bewegungsmelder set Lampe1,Lampe2,FunksteckdoseA on</code>

Das Komma wird nicht [[Escapen in Perlbefehlen|escaped]] (verdoppelt), hier darf tatsächlich KEIN Leerzeichen vor oder nach dem Komma eingefügt werden.

=== Logfileinträge unterdrücken===
Das Attribute "verbose 0" verhindert, dass das Gerät Logfileinträge erzeugt.

Beispiel:

define Funksteckdose FS20 22224222 01
attr Funksteckdose verbose 0

===FHT Lazy Mode benutzen===
Es gibt wenig Gründe, den FHT "Lazy Mode" nicht zu verwenden
define Heizung_Bad FHT 060d
attr Heizung_Bad lazy

Dieser sorgt dafür, dass Temperaturänderungen (genau genommen alle Änderungen, auch z.B. date) nur übertragen werden, wenn sie nicht sowieso schon am FHT eingestellt sind und veringern die Funklast dadurch deutlich.

Siehe auch: [[Kommunikationsprobleme mit FHT]]

== Oktober 2013 ==
=== Zuverlässigkeit von Wiedereinschalten erhöhen ===
Speziell bei FS20 Aktoren ist wegen des fehlenden Rückkanals nicht leicht erkennbar, ob ein Einschaltbefehl Wirkung gezeigt hat. Das bringt einen ganz schlechten WAF, wenn man z.B. mit einem FS20 Aktor eine Heizung ausschaltet und das Wiedereinschalten nach z.B. einer Stunde nicht klappt.

Hier empfiehlt es sich, das Ausschalten mittels
:<code>set Heizungs_schalter off-for-timer 3584</code> (= fast eine Stunde)
zu erledigen. Da bei FS20 der off-for-timer Befehl im Aktor abgewickelt wird (und nicht durch FHEM), schaltet sich der Aktor auch dann garantiert wieder ein, wenn FHEM abstürzt, eine Funkstörung vorliegt oder ähnliches. Bei Bedarf kann der Befehl off-for-timer zur Verlängerung der Ausschaltzeit wiederholt werden. Dies kann z.B. nötig sein, wenn die Ausschaltung länger als 4,5 Stunden (15360 Sekunden, der Maximalwert des Timers) dauern soll.

Achtung: dieser Trick funktioniert nur, wenn der Aktor "off-for-timer" selbst beherrscht. FS20 Geräte können das, HomeMatic können aber nur "on-for-timer". Man kann off-for-timer mit HomeMatic trotzdem verwenden, aber in diesem Fall sendet FHEM den Einschaltbefehl nach der Timerzeit. InterTechno, RSL etc, können gar keinen Timer, hier sendet FHEM immer 2 Befehle im passenden Abstand.

=== FS20 Timerzeiten ===
FS20 Timer werden in Sekunden angegeben. Es sind jedoch nicht alle Werte einstellbar. Da der Timer Wert in 7 Bit übertragen werden muss, sind nur 128 Werte möglich. Um mit diesen Werten im unteren Bereich möglichst fein aufzulösen, andererseits aber auch lange Zeiten zu ermöglichen, ist die Verteilung nicht linear. Einstellbar sind folgende Zeiten in Sekunden;

0,25 0,5 0,75 1 1,25 1,5 1,75 2 2,25 2,5 2,75 3 3,25 3,5 3,75
4 4,5 5 5,5 6 6,5 7 7,5 8 9 10 11 12 13 14 15 16 18 20 22
24 26 28 30 32 36 40 44 48 52 56 60 64 72 80 88 96 104 112
120 128 144 160 176 192 208 224 240 256 288 320 352 384 416
448 480 512 576 640 704 768 832 896 960 1024 1152 1280 1408
1536 1664 1792 1920 2048 2304 2560 2816 3072 3328 3584 3840 4096
4608 5120 5632 6144 6656 7168 7680 8192 9216 10240 11264 12288
13312 14336 15360
(etwas übersichtlicher formatiert auch [[FS20 Allgemein#ON/OFF Befehle mit Time Parameter|hier]]).

Andere Zeiten werden von FHEM gerundet. Ein neues Setzen des Timer für FS20 löscht den alten Wert.

Auch HomeMatic Aktoren beherrschen Time Parameter, im Gegensatz zu FS20 allerdings kein "off-for-timer". Details dazu im Artikel [[HomeMatic Timerwerte]]

[[Kategorie:HOWTOS]]

FileLog

2025-04-15T18:25:51Z

TomLee:

{{Infobox Modul
|ModPurpose=Protokollierung von Fhem-Ereignissen
|ModType=h
|ModForumArea=Automatisierung
|ModTechName=92_FileLog.pm
|ModOwner=rudolfkoenig ({{Link2FU|8|Forum}} / [[Benutzer Diskussion:Rudolfkoenig|Wiki]])
}}
Das Modul [[FileLog]] dient zur Protokollierung von Ereignissen in FHEM. Die Einträge werden in eine einfache Textdatei geschrieben. Zur Protokollierung in eine Datenbank kann alternativ oder auch parallel das Modul [[DbLog]] verwendet werden.

Logdateien sind die Basis für die Erstellung von Diagrammen ([[SVG]]).

== Definition ==
Ein FileLog wird (Details in der {{Link2CmdRef|Anker=FileLogdefine}}) mittels
:<code>define <name> FileLog <filename> <regexp> [readonly]</code>
angelegt. Dabei bezeichnet
;<name>
: - wie üblich - der Devicename der Definition
;<filename>
: legt den Namen der Datei auf Dateisystemebene fest
[[Datei:FileLogRegExpHelper.png|200px|thumb|right|Hilfe für addRegexpPart]]
;<regexp>
: bestimmt, welche Daten in die Datei geschrieben werden. Für die Bearbeitung der [[Regulärer Ausdruck|regexp]] stellt [[FHEMWEB]] die gezeigte Hilfsfunktion zur Verfügung (siehe hierzu auch dieses {{Link2Forum|Topic=12557|LinkText=Forenthema}} sowie den Abschnitt [[#Sonderfälle|Sonderfälle]])
;[readonly]
: ist optional und wird in [[#Sonderfälle|Sonderfällen]] benötigt. Dieser Parameter ist seit März 2015 ([https://svn.fhem.de/trac/changeset/8264 Changeset 8264]) verfügbar.

== Attribute ==
Über {{Link2CmdRef|Anker=FileLogattr|Label=Attribute}} lässt sich unter anderem auch festlegen, wie die Archivierung von Logdateien durchgeführt werden soll (Archivierungsbefehl, -pfad sowie Anzahl von Archivgenerationen).

Wenn bestimmte Zeilen '''nicht''' in die Logdatei geschrieben werden sollen, ist das Attribut ''ignoreRegexp'' hilfreich. Wenn beispielsweise alle Zeilen, die die Zeichenfolge "AbCd" oder "CdEf" enthalten '''nicht''' geloggt werden sollen, dann wäre
:<code>attr <log-name> ignoreRegexp .*AbCd.*|.*CdEf.*</code>
eine Attributdefinition, die das ermöglicht.

Dies bezieht sich aber nur auf normale FileLog-Instanzen. Falls Events aus dem globalen FHEM-Logfile ausgeschlossen werden sollen, muss man das Attribut in '''global''' angeben. (Zusammenhang siehe [[#Globale Logdatei]])
:<code>attr global ignoreRegexp .*AbCd.*|.*CdEf.*</code>

== Funktionen ==
''FileLog'' bietet Funktionen wie ''reopen'', ''absorb'' und ''get''. Details dazu sind in der {{Link2CmdRef|Anker=FileLogset}} zu finden.

Sofern eine Instanz vom Objekt [[eventTypes]] angelegt ist, bietet die Detailansicht eines FileLog eine komfortable Möglichkeit, die regulären Ausdrücke für den/die Filter zu bearbeiten.

== Sonderfälle ==
Üblicherweise sind FileLog Devices dafür zuständig, aufgrund von Events die gewünschten Daten in die Logdatei zu schreiben, in Sonderfällen kann FileLog aber auch dafür verwendet werden, "bestehende" Dateien (in die aus anderen Quellen / von anderen Programme geschrieben wird) zu behandeln.

=== Globale Logdatei ===
{{Randnotiz|RNTyp=y|RNText=Bis August 2021 war die Spezifikation von '''fakelog''' erforderlich bzw. möglich, um die Sonderbehandlung für diese Logdatei zu unterstützen. Mittlerweile ist das nicht mehr nötig und es wird (auch in der Beispielkonfiguration) der Wert '''Logfile''' empfohlen.}}
Die globale Logdatei für FHEM (üblicherweise als fhem.log bezeichnet) wird mit dem Attribut
:<code>attr global logfile <filename></code>
für das ''global''-Objekt definiert, wobei für ''<filename>'' normalerweise <code>./log/fhem-%Y-%m.log</code> verwendet wird.

Um das ''fhem.log'' über das [[FHEMWEB|Web Interface]] anzeigen zu können, ist ein weiterer Eintrag in der [[Konfiguration]] erforderlich, nämlich:
:<code>define Logfile FileLog <filename> <strike>fakelog</strike> Logfile</code>
Das ''<filename>'' muss '''zwingend''' durch den gleichen Wert ersetzt werden, der in der Definition des globalen ''logfile'' Attributs verwendet wurde, weil anderenfalls unterschiedliche Dateien verwendet werden - mit dem Effekt, dass die über das Web Interface angezeigte Datei nicht die erwarteten Einträge enthält (Details dazu auch in diesem {{Link2Forum|Topic=40041|Message=323315|LinkText=Forenbeitrag}}).

=== Logdaten aus anderen Quellen ===
Soll ein FileLog Device Daten aus anderen Quellen anzeigen, empfiehlt es sich, den Parameter '''''readonly''''' anzugeben. Damit wird vermieden, dass FHEM ebenfalls versucht, in die angegebene Datei (<filename>) zu schreiben.

=== Unterdrückung der addRegexpPart Hilfsfunktion ===
Wird bei einem FileLog Device die Anzeige der addRegxepPart Hilfsfunktion nicht gewünscht, muss als <regexp>-Parameter der gleiche Wert angegeben werden, der auch für den <name>-Parameter spezifiziert wurde (bisher (Nov. 2021) konnte dafür auch der Wert ''fakelog'' als <regexp>-Parameter verwendet werden; das wird in späteren Versionen nicht mehr unterstützt werden).

== Anwendungsbeispiele ==
=== Werte auslesen ===
Manchmal möchte man Daten aus den Logs abrufen, ohne händisch in den Logfiles herumzuwühlen. Dies ist insbesondere auch dann hilfreich, wenn man eigene Funktionen, Notifys oder spezielle Plots entwirft, bei denen man auf Logdaten zugreifen möchte.

Grundsätzlich beschrieben ist dies in der {{Link2CmdRef|Lang=de|Anker=FileLog}} und unterscheidet sich minimal (aber entscheidend) von der Struktur bei [[DbLog#Werte_auslesen|DbLogs]].

Hier ein paar Beispiele, was man damit anstellen kann:
* <code>get FileLog_FHT_3a32 - - 2016-10-01 2016-10-03</code>
: alle Einträge des FileLog_FHT_3a32 vom 01.10.-03.10.2016
* <code>get FileLog_FHT_3a32 - - 2016-10-01_08:00:00 2016-10-01_16:00:00</code>
: alle Einträge des FileLog_FHT_3a32 von 8-16 Uhr am 01.10.2016
* <code>get FileLog_FHT_3a32 - - 2016-10-01_08:00:00 2016-10-01_16:00:00 4:measured:0:</code>
: nur die Temperatur-Werte
* <code>{ ReadingsTimestamp("FHT_3a32","state","0") }</code>
: Timestamp des aktuellen state des FHT_3a32
* <code>{ OldTimestamp("FHT_3a32") }</code>
: Timestamp des letzten state des FHT_3a32
* <code>{ time_str2num(OldTimestamp("FHT_3a32")) }</code>
: Timestamp in Sekunden des letzten state des FHT_3a32
* ...
Weitere Beispiele kann man sich gut aus den SVG-Dateien ziehen.

=== Mehrere Werte und Dummy in einer Zeile formatiert in Logdatei schreiben ===
Manchmal möchte man die einzelnen Werte nicht untereinander in der Logdatei haben, sondern wie bei einer CSV-Datei in einer Zeile.

Hierzu kann man wie im Beispiel die einzelnen Readings Kesseltemperatur, Vorlauftemperatur und Rücklauftemperatur aus One-Wire-Sensoren DS18B20 und die Außentemperatur als vierten Wert aus einem Dummy über sprintf formatieren. Wer das durcht Komma oder Semikolon getrennt haben möchte, ersetzt die Leerzeichen zwischen den einzelnen Werten durch sein Wunschtrennzeichen.<syntaxhighlight lang="Text">
attr HEIZUNG userReadings HeizDataLog {sprintf("K: %3.1f VL: %3.1f RL: %3.1f Pr: %4.1f", ReadingsVal("OWX_28_4C966XXXXXXX","temperature", 0),ReadingsVal("OWX_28_4F9XXXXXXXXX","temperature", 0),ReadingsVal("OWX_28_FFAXXXXXXXXX","temperature", 0), (Value("Heiz_Temp_Outside")))}</syntaxhighlight>
Für die einzelnen Userreadings lassen sich auch unterschiedliche Intervalle angeben.<syntaxhighlight lang="Text">attr HEIZUNG event-min-interval HeizDataLog:300, HeizKesselTemp:20</syntaxhighlight>
Da im Beispiel nur Userreading HeizDataLog geschreiben werden soll, muss es bei <regexp> dementsprechend angegeben werden.
<syntaxhighlight lang="Text">
# logging
define FileLog_Heizung FileLog ./log/Heizung/Heizung_%Y_%m.log HEIZUNG:HeizDataLog.*
attr FileLog_Heizung logtype text
attr FileLog_Heizung room LogFiles,Heizung
attr FileLog_Heizung group Heizung
</syntaxhighlight>
Das ergibt folgendes Ergebnis:
<syntaxhighlight lang="Text">
2020-09-27_19:36:57 HEIZUNG HeizDataLog: K: 66.8 VL: 60.8 RL: 35.7 Out: 18.4
2020-09-27_19:41:58 HEIZUNG HeizDataLog: K: 60.0 VL: 56.9 RL: 34.3 Out: 18.3
2020-09-27_19:46:58 HEIZUNG HeizDataLog: K: 50.2 VL: 47.9 RL: 34.4 Out: 18.2
</syntaxhighlight>

== Links ==
* {{Link2Forum|Topic=40041|Message=323315|LinkText=Forenbeitrag}} zum Thema fhem.log / fakelog
* Forenthema zum {{Link2Forum|Topic=124167|LinkText="Deprecate" von ''fakelog''}}

[[Kategorie:Logging]]

Dimplex Wärmepumpenmanager

2025-03-30T17:01:16Z

TomLee:

Mit der NWPM-Erweiterung ist es möglich, den Dimplex Wärmepumpenmanager in ein Hausnetzwerk einzubinden. Durch die Einbindung der NWPM-Erweiterung ist es ebenfalls möglich, die zur Verfügung gestellten Werte vom Wärmepumpenmanager mittels ModbusTCP in FHEM zu übernehmen, anzuzeigen und grafisch darzustellen.

== Voraussetzung ==
Die Anbindung des Dimplex Wärmepumpenmanager an FHEM erfolgt mittels NWPM-Erweiterung und der aktuellen FHEM Installation. Weiterhin werden die zur Verfügung stehenden Module:

* 36_ModbusTCPServer.pm
* 37_ModbusCoil.pm
* 37_ModbusRegister.pm

genutzt. Getestet wurde der Zugriff auf einem BeagleBone Black mit der [[BeagleBone Black|hier beschriebenen]] Debian Installation.

== Installation ==
Die oben aufgeführten Module sind notwendig und müssen nachinstalliert werden. Zum Zeitpunkt der Erstellung dieser Dokumentation (31.1.2015) sind diese noch nicht offiziell in FHEM enthalten und werden auch nicht mittels Update verteilt. Die Module werden mit dem Befehl:
<pre>
update all https://raw.githubusercontent.com/ChrisD70/FHEM-Modules/master/autoupdate/mb/controls_modbus.txt
</pre>
über die FHEM Befehlszeile installiert und anschließend
<pre>
reload 36_ModbusTCPServer.pm
reload 37_ModbusCoil.pm
reload 37_ModbusRegister.pm
</pre>
mit einem Reload geladen.
== Benutzung ==
=== Anlegen der ModbusTCPServer Verbindung ===
Wie im nachfolgenden angegeben muss zunächst eine ModbusTCPServer Verbindung hergestellt werden. Die angegebene IP-Adresse muss durch die IP-Adresse der Wärmepumpe ersetzt werden.
<pre>
define HeatPumpServer ModbusTCPServer 192.168.1.150
attr HeatPumpServer verbose 2
</pre>
Ein erfolgreicher Verbindungsaufbau wird mit einem „ok“ im State gekennzeichnet.

=== Modbus-Register/Coil Adressen definieren ===
Im nachfolgendem Beispiel wird anhand der Außentemperatur die Adressdefinition erklärt.
<pre>
define dim_outdoor_temperature ModbusRegister 0 1
attr dim_outdoor_temperature IODev HeatPumpServer
attr dim_outdoor_temperature conversion 0.1:0
attr dim_outdoor_temperature event-min-interval .*:900
attr dim_outdoor_temperature event-on-change-reading .*
attr dim_outdoor_temperature plcDataType INT
attr dim_outdoor_temperature registerType Holding
attr dim_outdoor_temperature room Dimplex
attr dim_outdoor_temperature stateAlias temperature
attr dim_outdoor_temperature stateFormat {sprintf("%0.1f", ReadingsVal($name,"state",0))}
attr dim_outdoor_temperature updateInterval 00:10:00
</pre>
Erklärung:
{| class="wikitable"
|+ Erläuterungen zur Adressdefinition
|-
! Attribut !! Erläuterungen
|-
| ModbusRegister 0 1 || 0 Device Adresse, in der Regel bei ModbusTCP immer 0
|-
| ModbusRegister 0 1 || 1 Register Adresse, wird unter www.dimplex.de/wiki → ModbusTCP → Spalten IP zur Verfügung gestellt
|-
| IODev || Verwendeter und zuvor angelegter ModbusTCPServer
|-
| conversion || eine gegebenenfalls notwendige Konvertierung des übermittelten Values
|-
| PlcDataType || Ermögliche automatische Interpretation der ankommenden Daten
|-
| stateAlias || es wird ein zusätzliches Reading erzeugt, um zum Beispiel das Statistic-Modul nutzen zu können, stateAlias ist eine echte Kopie von "state"
|-
| updateInterval || Intervall des Abfragezyklus (z.B. 00:10:00 Minuten)
|-
|}

=== Betriebsdaten ===
Vorschlag der Namensvergabe für die Betriebsdaten. Eine sinnvolle Namensvergabe erleichtert später das Anlegen weiterer Definitionen von zum Beispiel Logfiles, Statistiken oder auch [[readingsGroup]].
{| class="wikitable"
|-
| dim_outdoor_temperature || Außentemperatur
|-
| dim_flow_temperature || Vorlauftemperatur
|-
| dim_return_temperature || Rücklauftemperatur
|-
| dim_returnset_temperature || Rücklaufsolltemperatur
|-
| dim_room_temperature || Raumtemperatur
|-
| dim_dhw_temperature || Warmwassertemperatur
|-
| dim_dhwset_temperature || Warmwassersolltemperatur
|-
| dim_brine_temperature || Soletemperatur
|-
| dim_high_pressure || Hochdruck
|-
| dim_low_pressure || Niederdruck
|}
Register Warmwassertemperatur definieren:<pre>
define dim_dhw_temperature ModbusRegister 0 3
attr dim_dhw_temperature IODev HeatPumpServer
attr dim_dhw_temperature conversion 0.1:0
attr dim_dhw_temperature event-min-interval .*:900
attr dim_dhw_temperature event-on-change-reading .*
attr dim_dhw_temperature plcDataType INT
attr dim_dhw_temperature registerType Holding
attr dim_dhw_temperature room Dimplex
attr dim_dhw_temperature stateAlias temperature
attr dim_dhw_temperature stateFormat {sprintf("%0.1f", ReadingsVal($name,"state",0))}
attr dim_dhw_temperature updateInterval 00:01:00
</pre>Register Vorlauftemperatur definieren:<pre>
define dim_flow_temperature ModbusRegister 0 5
attr dim_flow_temperature IODev HeatPumpServer
attr dim_flow_temperature conversion 0.1:0
attr dim_flow_temperature event-min-interval .*:900
attr dim_flow_temperature event-on-change-reading .*
attr dim_flow_temperature plcDataType INT
attr dim_flow_temperature registerType Holding
attr dim_flow_temperature room Dimplex
attr dim_flow_temperature stateAlias temperature
attr dim_flow_temperature stateFormat {sprintf("%0.1f", ReadingsVal($name,"state",0))}
attr dim_flow_temperature updateInterval 00:01:00
</pre>Register Rücklauftemperatur definieren:<pre>
define dim_return_temperature ModbusRegister 0 2
attr dim_return_temperature IODev HeatPumpServer
attr dim_return_temperature conversion 0.1:0
attr dim_return_temperature event-min-interval .*:900
attr dim_return_temperature event-on-change-reading .*
attr dim_return_temperature plcDataType INT
attr dim_return_temperature registerType Holding
attr dim_return_temperature room Dimplex
attr dim_return_temperature stateAlias temperature
attr dim_return_temperature stateFormat {sprintf("%0.1f", ReadingsVal($name,"state",0))}
attr dim_return_temperature updateInterval 00:01:00
</pre>Register Rücklaufsolltemperatur definieren:<pre>
define dim_returnset_temperature ModbusRegister 0 53
attr dim_returnset_temperature IODev HeatPumpServer
attr dim_returnset_temperature conversion 0.1:0
attr dim_returnset_temperature event-min-interval .*:900
attr dim_returnset_temperature event-on-change-reading .*
attr dim_returnset_temperature plcDataType INT
attr dim_returnset_temperature registerType Holding
attr dim_returnset_temperature room Dimplex
attr dim_returnset_temperature stateAlias temperature
attr dim_returnset_temperature stateFormat {sprintf("%0.1f", ReadingsVal($name,"state",0))}
attr dim_returnset_temperature updateInterval 00:05:00
</pre>

==== Logfile Betriebsdaten ====
Anlegen eines täglichen Logfile der Betriebsdaten.
<pre>
define filelog_dim_temperature FileLog ./log/filelog_dim_temperature-%W-%d.log dim_.*._temperature:temperature:.*|dim_.*._pressure:pressure:.*
attr filelog_dim_temperature room Dimplex
</pre>

==== Statistiken ====
Folgender Code legt die Statistiken der Betriebsdaten an
<pre>
define dim_statistics statistics dim_.*._temperature|dim_.*._pressure
attr dim_statistics dayChangeTime 1
attr dim_statistics deltaReadings temperature,pressure
attr dim_statistics minAvgMaxReadings temperature,pressure
attr dim_statistics room Dimplex
attr dim_statistics tendencyReadings temperature,pressure
</pre>

=== Zustände ===
Vorschlag der Namensvergabe für die Zustände. Eine sinnvolle Namensvergabe erleichtert später das Anlegen weiterer Definitionen von zum Beispiel Logfiles, Statistiken oder auch [[readingsGroup]].
{| class="wikitable"
|-
| dim_compressor_output || Verdichter
|-
| dim_ventilator_output || Ventilator
|-
| dim_brinepump_ output || Solepumpe
|-
| dim_circulationpump_output || Heizungsumwälzpumpe M13
|-
| dim_2heatgenerator_output || 2.Wärmeerzeuger
|-
| dim_dhwpump_output || Warmwasserpumpe M18
|-
| dim_auxiliarypump_output || Zusatzpumpe M16
|-
| dim_flangeheater_output || Flanschheizung
|}
Coil Verdichter und passenden HourCounter für Verdichter definieren:<pre>
define dim_compressor_output ModbusCoil 0 41
attr dim_compressor_output IODev HeatPumpServer
attr dim_compressor_output disableRegisterMapping 1
attr dim_compressor_output event-min-interval .*:900
attr dim_compressor_output event-on-change-reading .*
attr dim_compressor_output room Dimplex
attr dim_compressor_output source Coil
attr dim_compressor_output updateInterval 00:01:00

define hourcounter_compressor_output HourCounter dim_compressor_output:on dim_compressor_output:off
attr hourcounter_compressor_output event-min-interval tick.*:0,.*:3600
attr hourcounter_compressor_output event-on-change-reading .*
</pre>Coil Ventilator definieren und passenden HourCounter für Ventilator definieren:<pre>
define dim_ventilator_output ModbusCoil 0 43
attr dim_ventilator_output IODev HeatPumpServer
attr dim_ventilator_output disableRegisterMapping 1
attr dim_ventilator_output event-min-interval .*:900
attr dim_ventilator_output event-on-change-reading .*
attr dim_ventilator_output room Dimplex
attr dim_ventilator_output source Coil
attr dim_ventilator_output updateInterval 00:01:00

define hourcounter_ventilator_output HourCounter dim_ventilator_output:on dim_ventilator_output:off
attr hourcounter_ventilator_output event-min-interval tick.*:0,.*:3600
attr hourcounter_ventilator_output event-on-change-reading .*
</pre>Coil 2.Wärmeerzeuger definieren und passenden HourCounter für 2.Wärmeerzeuger definieren:<pre>
define dim_2heatgenerator_output ModbusCoil 0 44
attr dim_2heatgenerator_output IODev HeatPumpServer
attr dim_2heatgenerator_output disableRegisterMapping 1
attr dim_2heatgenerator_output event-min-interval .*:900
attr dim_2heatgenerator_output event-on-change-reading .*
attr dim_2heatgenerator_output room Dimplex
attr dim_2heatgenerator_output source Coil
attr dim_2heatgenerator_output updateInterval 00:01:00

define hourcounter_2heatgenerator_output HourCounter dim_2heatgenerator_output:on dim_2heatgenerator_output:off
attr hourcounter_2heatgenerator_output event-min-interval tick.*:0,.*:3600
attr hourcounter_2heatgenerator_output event-on-change-reading .*
</pre>Coil Heizungsumwälzpumpe M13 definieren und passenden HourCounter für Heizungsumwälzpumpe M13 definieren:<pre>
define dim_circulationpump_output ModbusCoil 0 45
attr dim_circulationpump_output IODev HeatPumpServer
attr dim_circulationpump_output disableRegisterMapping 1
attr dim_circulationpump_output event-min-interval .*:900
attr dim_circulationpump_output event-on-change-reading .*
attr dim_circulationpump_output room Dimplex
attr dim_circulationpump_output source Coil
attr dim_circulationpump_output updateInterval 00:01:00

define hourcounter_circulationpump_output HourCounter dim_circulationpump_output:on dim_circulationpump_output:off
attr hourcounter_circulationpump_output event-min-interval tick.*:0,.*:3600
attr hourcounter_circulationpump_output event-on-change-reading .*
</pre>Coil Warmwasserpumpe M18 definieren und passenden HourCounter für Warmwasserpumpe M18 definieren:<pre>
define dim_dhwpump_output ModbusCoil 0 46
attr dim_dhwpump_output IODev HeatPumpServer
attr dim_dhwpump_output disableRegisterMapping 1
attr dim_dhwpump_output event-min-interval .*:900
attr dim_dhwpump_output event-on-change-reading .*
attr dim_dhwpump_output room Dimplex
attr dim_dhwpump_output source Coil
attr dim_dhwpump_output updateInterval 00:01:00

define hourcounter_dhwpump_output HourCounter dim_dhwpump_output:on dim_dhwpump_output:off
attr hourcounter_dhwpump_output event-min-interval tick.*:0,.*:3600
attr hourcounter_dhwpump_output event-on-change-reading .*
</pre>Coil Zusatzpumpe M16 definieren und Passenden HourCounter für Zusatzpumpe M16 definieren:<pre>
define dim_auxiliarypump_output ModbusCoil 0 49
attr dim_auxiliarypump_output IODev HeatPumpServer
attr dim_auxiliarypump_output disableRegisterMapping 1
attr dim_auxiliarypump_output event-min-interval .*:900
attr dim_auxiliarypump_output event-on-change-reading .*
attr dim_auxiliarypump_output room Dimplex
attr dim_auxiliarypump_output source Coil
attr dim_auxiliarypump_output updateInterval 00:01:00

define hourcounter_auxiliarypump_output HourCounter dim_auxiliarypump_output:on dim_auxiliarypump_output:off
attr hourcounter_auxiliarypump_output event-min-interval tick.*:0,.*:3600
attr hourcounter_auxiliarypump_output event-on-change-reading .*
</pre>Coil Flanschheizung definieren und passenden HourCounter für Flanschheizung M16 definieren:<pre>
define dim_flangeheater_output ModbusCoil 0 50
attr dim_flangeheater_output IODev HeatPumpServer
attr dim_flangeheater_output disableRegisterMapping 1
attr dim_flangeheater_output event-min-interval .*:900
attr dim_flangeheater_output event-on-change-reading .*
attr dim_flangeheater_output room Dimplex
attr dim_flangeheater_output source Coil
attr dim_flangeheater_output updateInterval 00:01:00

define hourcounter_flangeheater_output HourCounter dim_flangeheater_output:on dim_flangeheater_output:off
attr hourcounter_flangeheater_output event-min-interval tick.*:0,.*:3600
attr hourcounter_flangeheater_output event-on-change-reading .*
</pre>

==== Logfile Zustände ====
Anlegen eines wöchentlichen Logfile der Zustände:
<pre>
define filelog_dim_output_week FileLog ./log/filelog_dim_output_week-%W.log dim_.*._output.*
attr filelog_dim_output_week room Dimplex
</pre>

=== Historie ===
Vorschlag der Namensvergabe für die Historie. Eine sinnvolle Namensvergabe erleichtert später das Anlegen weiterer Definitionen von zum Beispiel Logfiles, Statistiken oder auch [[readingsGroup]].
{| class="wikitable"
|-
| dim_compressor_history || Verdichter
|-
| dim_ventilator_history || Ventilator
|-
| dim_brinepump_history || Solepumpe
|-
| dim_circulationpump_history || Heizungsumwälzpumpe M13
|-
| dim_2heatgenerator_history || 2.Wärmeerzeuger
|-
| dim_dhwpump_history || Warmwasserpumpe M18
|-
| dim_auxiliarypump_history || Zusatzpumpe M16
|-
| dim_flangeheater_history || Flanschheizung
|}
Register Historie Verdichter definieren:<pre>
define dim_compressor_history ModbusRegister 0 72
attr dim_compressor_history IODev HeatPumpServer
attr dim_compressor_history alignUpdateInterval 00:01:00
attr dim_compressor_history event-on-change-reading .*
attr dim_compressor_history plcDataType INT
attr dim_compressor_history registerType Holding
attr dim_compressor_history room Dimplex
attr dim_compressor_history updateInterval 01:00:00
</pre>Register Historie Ventilator definieren:<pre>
define dim_ventilator_history ModbusRegister 0 74
attr dim_ventilator_history IODev HeatPumpServer
attr dim_ventilator_history alignUpdateInterval 00:01:00
attr dim_ventilator_history event-on-change-reading .*
attr dim_ventilator_history plcDataType INT
attr dim_ventilator_history registerType Holding
attr dim_ventilator_history room Dimplex
attr dim_ventilator_history updateInterval 01:00:00
</pre>Register Historie 2.Wärmeerzeuger definieren:<pre>
define dim_2heatgenerator_history ModbusRegister 0 75
attr dim_2heatgenerator_history IODev HeatPumpServer
attr dim_2heatgenerator_history alignUpdateInterval 00:01:00
attr dim_2heatgenerator_history event-on-change-reading .*
attr dim_2heatgenerator_history plcDataType INT
attr dim_2heatgenerator_history registerType Holding
attr dim_2heatgenerator_history room Dimplex
attr dim_2heatgenerator_history updateInterval 01:00:00
</pre>Register Historie Heizungsumwälzpumpe M13 definieren:<pre>
define dim_circulationpump_history ModbusRegister 0 76
attr dim_circulationpump_history IODev HeatPumpServer
attr dim_circulationpump_history alignUpdateInterval 00:01:00
attr dim_circulationpump_history event-on-change-reading .*
attr dim_circulationpump_history plcDataType INT
attr dim_circulationpump_history registerType Holding
attr dim_circulationpump_history room Dimplex
attr dim_circulationpump_history updateInterval 01:00:00
</pre>Register Historie Warmwasserpumpe M18 definieren:<pre>
define dim_dhwpump_history ModbusRegister 0 77
attr dim_dhwpump_history IODev HeatPumpServer
attr dim_dhwpump_history alignUpdateInterval 00:01:00
attr dim_dhwpump_history event-on-change-reading .*
attr dim_dhwpump_history plcDataType INT
attr dim_dhwpump_history registerType Holding
attr dim_dhwpump_history room Dimplex
attr dim_dhwpump_history updateInterval 01:00:00
</pre>Register Historie Flanschheizung definieren:<pre>
define dim_flangeheater_history ModbusRegister 0 78
attr dim_flangeheater_history IODev HeatPumpServer
attr dim_flangeheater_history alignUpdateInterval 00:01:00
attr dim_flangeheater_history event-on-change-reading .*
attr dim_flangeheater_history plcDataType INT
attr dim_flangeheater_history registerType Holding
attr dim_flangeheater_history room Dimplex
attr dim_flangeheater_history updateInterval 01:00:00
</pre>
==== Logfile Historie ====
Anlegen eines monatlichen Logfile für die Historischen Daten:
<pre>
define filelog_dim_history_month FileLog ./log/filelog_dim_history_month-%m.log dim_.*._history.*
attr filelog_dim_history_month room Dimplex
</pre>

==== Wärmemengen ====
Laut Definition aus dem [http://www.dimplex.de/wiki Dimplex-Wiki] werden die Wärmemengen für Heizen, Warmwasser und Schwimmbad aus 3 Register-Adressen zusammengesetzt. Im Nachfolgenden Code-Beispiel wird dies entsprechend dargestellt. Dabei wird jeweils im ersten Register ein neues userReading mit der Darstellung der Gesamtwärmemenge angelegt.

Wärmemenge Heizen definieren:
<pre>
define dim_heating1_thermalenergy ModbusRegister 0 5096
attr dim_heating1_thermalenergy IODev HeatPumpServer
attr dim_heating1_thermalenergy event-on-change-reading .*
attr dim_heating1_thermalenergy plcDataType INT
attr dim_heating1_thermalenergy registerType Holding
attr dim_heating1_thermalenergy room Dimplex
attr dim_heating1_thermalenergy updateInterval 00:15:00
attr dim_heating1_thermalenergy userReadings heatingthermalenergy {\
((ReadingsVal("dim_heating3_thermalenergy","state",0)*100000000)+\
(ReadingsVal("dim_heating2_thermalenergy","state",0)*10000)+\
(ReadingsVal("dim_heating1_thermalenergy","state",0)))}

define dim_heating2_thermalenergy ModbusRegister 0 5097
attr dim_heating2_thermalenergy IODev HeatPumpServer
attr dim_heating2_thermalenergy event-on-change-reading .*
attr dim_heating2_thermalenergy plcDataType INT
attr dim_heating2_thermalenergy registerType Holding
attr dim_heating2_thermalenergy room Dimplex
attr dim_heating2_thermalenergy updateInterval 00:15:00

define dim_heating3_thermalenergy ModbusRegister 0 5098
attr dim_heating3_thermalenergy IODev HeatPumpServer
attr dim_heating3_thermalenergy event-on-change-reading .*
attr dim_heating3_thermalenergy plcDataType INT
attr dim_heating3_thermalenergy registerType Holding
attr dim_heating3_thermalenergy room Dimplex
attr dim_heating3_thermalenergy updateInterval 00:15:00
</pre>Wärmemenge Warmwasser definieren:<pre>
define dim_dhw1_thermalenergy ModbusRegister 0 5099
attr dim_dhw1_thermalenergy IODev HeatPumpServer
attr dim_dhw1_thermalenergy event-on-change-reading .*
attr dim_dhw1_thermalenergy plcDataType INT
attr dim_dhw1_thermalenergy registerType Holding
attr dim_dhw1_thermalenergy room Dimplex
attr dim_dhw1_thermalenergy updateInterval 00:15:00
attr dim_dhw1_thermalenergy userReadings dhwthermalenergy {\ ((ReadingsVal("dim_dhw3_thermalenergy","state",0)*100000000)+\
(ReadingsVal("dim_dhw2_thermalenergy","state",0)*10000)+\
(ReadingsVal("dim_dhw1_thermalenergy","state",0)))}

define dim_dhw2_thermalenergy ModbusRegister 0 5100
attr dim_dhw2_thermalenergy IODev HeatPumpServer
attr dim_dhw2_thermalenergy event-on-change-reading .*
attr dim_dhw2_thermalenergy plcDataType INT
attr dim_dhw2_thermalenergy registerType Holding
attr dim_dhw2_thermalenergy room Dimplex
attr dim_dhw2_thermalenergy updateInterval 00:15:00

define dim_dhw3_thermalenergy ModbusRegister 0 5101
attr dim_dhw3_thermalenergy IODev HeatPumpServer
attr dim_dhw3_thermalenergy event-on-change-reading .*
attr dim_dhw3_thermalenergy plcDataType INT
attr dim_dhw3_thermalenergy registerType Holding
attr dim_dhw3_thermalenergy room Dimplex
attr dim_dhw3_thermalenergy updateInterval 00:15:00
</pre>
==== Umweltenergie ====
Als Umweltenergie wird die zugeführte Kälteenergie aus der Umwelt (Luft/Erdreich) bezeichnet. Das Auslesen dieser Werte über die Schnittstelle ist erst ab einem neueren Softwarestand möglich. Die Differenz der gesamten Wärmemenge und der Umweltenergie entspricht in etwa der Energie des Verdichters.

Umweltenergie/entzogene Kälteenergie definieren:
<pre>
define dim_environment1_energy ModbusRegister 0 5127
attr dim_environment1_energy IODev HeatPumpServer
attr dim_environment1_energy event-on-change-reading .*
attr dim_environment1_energy plcDataType INT
attr dim_environment1_energy registerType Holding
attr dim_environment1_energy room Dimplex
attr dim_environment1_energy updateInterval 00:15:00
attr dim_environment1_energy userReadings environmentenergy {\
((ReadingsVal("dim_environment3_energy","state",0)*100000000)+\
(ReadingsVal("dim_environment2_energy","state",0)*10000)+\
(ReadingsVal("dim_environment1_energy","state",0)))}

define dim_environment2_energy ModbusRegister 0 5128
attr dim_environment2_energy IODev HeatPumpServer
attr dim_environment2_energy event-on-change-reading .*
attr dim_environment2_energy plcDataType INT
attr dim_environment2_energy registerType Holding
attr dim_environment2_energy room Dimplex
attr dim_environment2_energy updateInterval 00:15:00

define dim_environment3_energy ModbusRegister 0 5129
attr dim_environment3_energy IODev HeatPumpServer
attr dim_environment3_energy event-on-change-reading .*
attr dim_environment3_energy plcDataType INT
attr dim_environment3_energy registerType Holding
attr dim_environment3_energy room Dimplex
attr dim_environment3_energy updateInterval 00:15:00
</pre>

==== Logfile Wärmemengen ====
Anlegen eines jährlichen Logfile der Wärmemengen.
<pre>
define filelog_dim_thermalenergy_year FileLog ./log/filelog_dim_thermalenergy_year-%y.log dim_heating1_thermalenergy:heatingthermalenergy:.*|dim_heating1_thermalenergy:heatingthermalenergy:.*
attr filelog_dim_thermalenergy_year room Dimplex
</pre>

=== Meldungen ===
[[Bild:dimplex_rh_status_heatpump.jpg|thumb|right|Beispiel Meldungen]]
Eine sinnvolle Anzeige sind die Meldungen (Status, Sperre, Störung) der Wärmepumpe. Im nachfolgenden Beispiel werden die Meldungen mit dem Hilfsmodul [[readingsHistory]] dargestellt. Die Definitionen der Meldungen beziehen sich auf die im [http://www.dimplex.de/wiki Dimplex-Wiki] beschriebene L-Software. Bei abweichenden Softwareständen müssen die Register sowie die Texte angepasst werden.

Register Statusmeldung definieren:

<pre>
define dim_status_heatpump ModbusRegister 0 103
attr dim_status_heatpump IODev HeatPumpServer
attr dim_status_heatpump event-on-change-reading .*
attr dim_status_heatpump plcDataType INT
attr dim_status_heatpump registerType Holding
attr dim_status_heatpump room Dimplex
attr dim_status_heatpump updateInterval 00:00:10
attr dim_status_heatpump userReadings Status {\
((ReadingsVal($name,"state","") == 1) ? "Aus":\
(ReadingsVal($name,"state","") == 4) ? "Warmwasser":\
(ReadingsVal($name,"state","") == 10) ? "Abtauen":\
(ReadingsVal($name,"state","") == 11) ? "Durchflussüberwachnung":"")}

</pre>Register Sperrmeldunge definieren:<pre>
define dim_block_heatpump ModbusRegister 0 104
attr dim_block_heatpump IODev HeatPumpServer
attr dim_block_heatpump event-on-change-reading .*
attr dim_block_heatpump plcDataType INT
attr dim_block_heatpump registerType Holding
attr dim_block_heatpump room Dimplex
attr dim_block_heatpump updateInterval 00:00:10
attr dim_block_heatpump userReadings Sperre {\
((ReadingsVal($name,"state","") == 0) ? "":\
(ReadingsVal($name,"state","") == 7) ? "Systemkontrolle":\
(ReadingsVal($name,"state","") == 9) ? "Pumpenvorlauf":\
(ReadingsVal($name,"state","") == 10) ? "Mindeststandzeit":\
(ReadingsVal($name,"state","") == 11) ? "Netzbelastung":\
(ReadingsVal($name,"state","") == 12) ? "Schaltspielsperre":\
(ReadingsVal($name,"state","") == 15) ? "EVU":"")}
</pre>Register Störmeldungen definieren:<pre>
define dim_fault_heatpump ModbusRegister 0 105
attr dim_fault_heatpump IODev HeatPumpServer
attr dim_fault_heatpump event-on-change-reading .*
attr dim_fault_heatpump plcDataType INT
attr dim_fault_heatpump registerType Holding
attr dim_fault_heatpump room Dimplex
attr dim_fault_heatpump updateInterval 00:01:00
attr dim_fault_heatpump userReadings Störung {\
((ReadingsVal($name,"state","") == 0) ? "":\
(ReadingsVal($name,"state","") == 6) ? "Elektronisches Ex.Ventil":\
(ReadingsVal($name,"state","") == 15) ? "Sensorik":\
(ReadingsVal($name,"state","") == 19) ? "!Primärkreis":\
(ReadingsVal($name,"state","") == 22) ? "!Warmwasser":\
(ReadingsVal($name,"state","") == 23) ? "!Last Verdichter":\
(ReadingsVal($name,"state","") == 24) ? "!Codierung":\
(ReadingsVal($name,"state","") == 25) ? "!Niederdruck":\
(ReadingsVal($name,"state","") == 26) ? "!Frostschutz":\
(ReadingsVal($name,"state","") == 29) ? "!Temperatur Differenz":\
(ReadingsVal($name,"state","") == 31) ? "!Durchfluss":"")}
</pre>
==== Anzeige der Meldungen ====
readingsHistory definieren:<pre>
define rh_dim_status_heatpump readingsHistory dim_status_heatpump:Status dim_block_heatpump:Sperre dim_fault_heatpump:Störung
attr rh_dim_status_heatpump alias Status
attr rh_dim_status_heatpump mapping {'dim_status_heatpump' => '', 'dim_block_heatpump' => '', 'dim_fault_heatpump' => ''}
attr rh_dim_status_heatpump nohtml 1
attr rh_dim_status_heatpump room Dimplex
attr rh_dim_status_heatpump rows 20
attr rh_dim_status_heatpump timestampFormat %b %a %R
</pre>

== Plotbeispiel ==
=== Temperaturen ===
<pre>
# Created by FHEM/98_SVG.pm, 2015-05-11 21:40:00
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 ytics y2tics
set ylabel ""
set y2label "Temperatur (°C)"

#filelog_dim_temperature_week 4:dim_outdoor_temperature.*::
#filelog_dim_temperature_week 4:dim_room_temperature.*::
#filelog_dim_temperature_week 4:dim_return_temperature.*::
#filelog_dim_temperature_week 4:dim_returnset_temperature.*::
#filelog_dim_temperature_week 4:dim_dhw_temperature.*::
#filelog_dim_temperature_week 4:dim_flow_temperature.*::
#filelog_dim_temperature_week 4:dim_brine_temperature.*::

plot "<IN>" using 1:2 axes x1y2 title 'AT' ls l7 lw 1 with lines,\
"<IN>" using 1:2 axes x1y2 title 'RT' ls l1 lw 1 with lines,\
"<IN>" using 1:2 axes x1y2 title 'RL' ls l2 lw 1 with lines,\
"<IN>" using 1:2 axes x1y2 title 'RLS' ls l3 lw 1 with lines,\
"<IN>" using 1:2 axes x1y2 title 'WWT' ls l4 lw 1 with lines,\
"<IN>" using 1:2 axes x1y2 title 'VLT' ls l0 lw 1 with lines,\
"<IN>" using 1:2 axes x1y2 title 'SOL' ls l6 lw 1 with lines
</pre>

=== Ausgänge ===
<pre>
# Created by FHEM/98_SVG.pm, 2015-05-11 21:45:00
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 ''
set ytics ("An" -1, "Aus" -2, "An" -5, "Aus" -6, "An" -9, "Aus" -10, "An" -13, "Aus" -14)
set y2tics ("An" 1, "Aus" 0, "An" -3, "Aus" -4, "An" -7, "Aus" -8, "An" -11, "Aus" -12)
set grid
set ylabel ""
set y2label "Digital"
set yrange [-16:2]
set y2range [-16:2]

#FileLog 3:dim_compressor_output.*::$fld[2]=~"on"?1:0
#FileLog 3:dim_ventilator_output.*::$fld[2]=~"on"?-1:-2
#FileLog 3:dim_2heatgenerator_output.*::$fld[2]=~"on"?-3:-4
#FileLog 3:dim_circulationpump_output.*::$fld[2]=~"on"?-5:-6
#FileLog 3:dim_dhwpump_output.*::$fld[2]=~"on"?-7:-8
#FileLog 3:dim_auxiliarypump_output.*::$fld[2]=~"on"?-9:-10
#FileLog 3:dim_solarpump_output.*::$fld[2]=~"on"?-11:-12
#FileLog 3:dim_flangeheater_output.*::$fld[2]=~"on"?-13:-14

plot "<IN>" using 1:2 axes x1y2 title 'Vd' ls l7 lw 1.5 with steps,\
"<IN>" using 1:2 axes x1y2 title 'Ve' ls l6 lw 1.5 with steps,\
"<IN>" using 1:2 axes x1y2 title '2.We' ls l5 lw 1.5 with steps,\
"<IN>" using 1:2 axes x1y2 title 'Hub' ls l4 lw 1.5 with steps,\
"<IN>" using 1:2 axes x1y2 title 'Wup' ls l3 lw 1 with steps,\
"<IN>" using 1:2 axes x1y2 title 'Zup' ls l0 lw 1.5 with steps,\
"<IN>" using 1:2 axes x1y2 title 'Sol' ls l2 lw 1.5 with steps,\
"<IN>" using 1:2 axes x1y2 title 'Flh' ls l7 lw 1.5 with steps
</pre>

[[Bild:dimplex_hp_graph.jpg|thumb|right|Plotbeispiel]]
Im nebenstehenden Plotbeispiel werde die Temperaturen (Analogwerte) sowie die Ausgänge (Digitalwerte) dargestellt. Im einzelnen sind die Kurven für die

* Aussen- (AT)
* Raum- (RT)
* Rücklauf- (RL)
* Rücklaufsoll- (RLS)
* Warmwasser- (WWT) und
* Vorlauftemperatur (VLT)

sowie die Ausgänge für

* Verdichter 1 (Vd)
* Ventilator (Ve)
* 2.Wärmeerzeuger (2We)
* Heizungsumwälzpumpe (Hup)
* Warmwasserumwälzpumpe (Wup) und
* Zusatzumwälzpumpe (Zup)

enthalten.

= Kontakt =
Weitere Fragen, Wünsche und Anregungen bitte im entsprechenden {{Link2Forum|Topic=33086|LinkText=Forenthread zum Wiki-Artikel "Dimplex Wärmepumpenmanager"}} zur Diskussion stellen.

Offene Punkte:
- Darstellung der Werte in einer readingsGroup
- Zugriff auf Zeitfunktionen mit Lesen und Schreiben

[[Kategorie:HOWTOS]]
[[Kategorie:Heizungssteuerung]]
[[Kategorie:Other Components]]

Dimplex Wärmepumpenmanager

2025-03-30T16:55:14Z

TomLee:

Mit der NWPM-Erweiterung ist es möglich, den Dimplex Wärmepumpenmanager in ein Hausnetzwerk einzubinden. Durch die Einbindung der NWPM-Erweiterung ist es ebenfalls möglich, die zur Verfügung gestellten Werte vom Wärmepumpenmanager mittels ModbusTCP in FHEM zu übernehmen, anzuzeigen und grafisch darzustellen.

== Voraussetzung ==
Die Anbindung des Dimplex Wärmepumpenmanager an FHEM erfolgt mittels NWPM-Erweiterung und der aktuellen FHEM Installation. Weiterhin werden die zur Verfügung stehenden Module:

* 36_ModbusTCPServer.pm
* 37_ModbusCoil.pm
* 37_ModbusRegister.pm

genutzt. Getestet wurde der Zugriff auf einem BeagleBone Black mit der [[BeagleBone Black|hier beschriebenen]] Debian Installation.

== Installation ==
Die oben aufgeführten Module sind notwendig und müssen nachinstalliert werden. Zum Zeitpunkt der Erstellung dieser Dokumentation (31.1.2015) sind diese noch nicht offiziell in FHEM enthalten und werden auch nicht mittels Update verteilt. Die Module werden mit dem Befehl:
<pre>
update all https://raw.githubusercontent.com/ChrisD70/FHEM-Modules/master/autoupdate/mb/controls_modbus.txt
</pre>
über die FHEM Befehlszeile installiert und anschließend
<pre>
reload 36_ModbusTCPServer.pm
reload 37_ModbusCoil.pm
reload 37_ModbusRegister.pm
</pre>
mit einem Reload geladen.
== Benutzung ==
=== Anlegen der ModbusTCPServer Verbindung ===
Wie im nachfolgenden angegeben muss zunächst eine ModbusTCPServer Verbindung hergestellt werden. Die angegebene IP-Adresse muss durch die IP-Adresse der Wärmepumpe ersetzt werden.
<pre>
########################################################
## ModbusTCPServer definieren
########################################################
define HeatPumpServer ModbusTCPServer 192.168.1.150
attr HeatPumpServer verbose 2
</pre>
Ein erfolgreicher Verbindungsaufbau wird mit einem „ok“ im State gekennzeichnet.

=== Modbus-Register/Coil Adressen definieren ===
Im nachfolgendem Beispiel wird anhand der Außentemperatur die Adressdefinition erklärt.
<pre>
define dim_outdoor_temperature ModbusRegister 0 1
attr dim_outdoor_temperature IODev HeatPumpServer
attr dim_outdoor_temperature conversion 0.1:0
attr dim_outdoor_temperature event-min-interval .*:900
attr dim_outdoor_temperature event-on-change-reading .*
attr dim_outdoor_temperature plcDataType INT
attr dim_outdoor_temperature registerType Holding
attr dim_outdoor_temperature room Dimplex
attr dim_outdoor_temperature stateAlias temperature
attr dim_outdoor_temperature stateFormat {sprintf("%0.1f", ReadingsVal($name,"state",0))}
attr dim_outdoor_temperature updateInterval 00:10:00
</pre>
Erklärung:
{| class="wikitable"
|+ Erläuterungen zur Adressdefinition
|-
! Attribut !! Erläuterungen
|-
| ModbusRegister 0 1 || 0 Device Adresse, in der Regel bei ModbusTCP immer 0
|-
| ModbusRegister 0 1 || 1 Register Adresse, wird unter www.dimplex.de/wiki → ModbusTCP → Spalten IP zur Verfügung gestellt
|-
| IODev || Verwendeter und zuvor angelegter ModbusTCPServer
|-
| conversion || eine gegebenenfalls notwendige Konvertierung des übermittelten Values
|-
| PlcDataType || Ermögliche automatische Interpretation der ankommenden Daten
|-
| stateAlias || es wird ein zusätzliches Reading erzeugt, um zum Beispiel das Statistic-Modul nutzen zu können, stateAlias ist eine echte Kopie von "state"
|-
| updateInterval || Intervall des Abfragezyklus (z.B. 00:10:00 Minuten)
|-
|}

=== Betriebsdaten ===
Vorschlag der Namensvergabe für die Betriebsdaten. Eine sinnvolle Namensvergabe erleichtert später das Anlegen weiterer Definitionen von zum Beispiel Logfiles, Statistiken oder auch [[readingsGroup]].
{| class="wikitable"
|-
| dim_outdoor_temperature || Außentemperatur
|-
| dim_flow_temperature || Vorlauftemperatur
|-
| dim_return_temperature || Rücklauftemperatur
|-
| dim_returnset_temperature || Rücklaufsolltemperatur
|-
| dim_room_temperature || Raumtemperatur
|-
| dim_dhw_temperature || Warmwassertemperatur
|-
| dim_dhwset_temperature || Warmwassersolltemperatur
|-
| dim_brine_temperature || Soletemperatur
|-
| dim_high_pressure || Hochdruck
|-
| dim_low_pressure || Niederdruck
|}
Register Warmwassertemperatur definieren:<pre>
define dim_dhw_temperature ModbusRegister 0 3
attr dim_dhw_temperature IODev HeatPumpServer
attr dim_dhw_temperature conversion 0.1:0
attr dim_dhw_temperature event-min-interval .*:900
attr dim_dhw_temperature event-on-change-reading .*
attr dim_dhw_temperature plcDataType INT
attr dim_dhw_temperature registerType Holding
attr dim_dhw_temperature room Dimplex
attr dim_dhw_temperature stateAlias temperature
attr dim_dhw_temperature stateFormat {sprintf("%0.1f", ReadingsVal($name,"state",0))}
attr dim_dhw_temperature updateInterval 00:01:00
</pre>Register Vorlauftemperatur definieren:<pre>
define dim_flow_temperature ModbusRegister 0 5
attr dim_flow_temperature IODev HeatPumpServer
attr dim_flow_temperature conversion 0.1:0
attr dim_flow_temperature event-min-interval .*:900
attr dim_flow_temperature event-on-change-reading .*
attr dim_flow_temperature plcDataType INT
attr dim_flow_temperature registerType Holding
attr dim_flow_temperature room Dimplex
attr dim_flow_temperature stateAlias temperature
attr dim_flow_temperature stateFormat {sprintf("%0.1f", ReadingsVal($name,"state",0))}
attr dim_flow_temperature updateInterval 00:01:00
</pre>Register Rücklauftemperatur definieren:<pre>
define dim_return_temperature ModbusRegister 0 2
attr dim_return_temperature IODev HeatPumpServer
attr dim_return_temperature conversion 0.1:0
attr dim_return_temperature event-min-interval .*:900
attr dim_return_temperature event-on-change-reading .*
attr dim_return_temperature plcDataType INT
attr dim_return_temperature registerType Holding
attr dim_return_temperature room Dimplex
attr dim_return_temperature stateAlias temperature
attr dim_return_temperature stateFormat {sprintf("%0.1f", ReadingsVal($name,"state",0))}
attr dim_return_temperature updateInterval 00:01:00
</pre>Register Rücklaufsolltemperatur definieren:<pre>
define dim_returnset_temperature ModbusRegister 0 53
attr dim_returnset_temperature IODev HeatPumpServer
attr dim_returnset_temperature conversion 0.1:0
attr dim_returnset_temperature event-min-interval .*:900
attr dim_returnset_temperature event-on-change-reading .*
attr dim_returnset_temperature plcDataType INT
attr dim_returnset_temperature registerType Holding
attr dim_returnset_temperature room Dimplex
attr dim_returnset_temperature stateAlias temperature
attr dim_returnset_temperature stateFormat {sprintf("%0.1f", ReadingsVal($name,"state",0))}
attr dim_returnset_temperature updateInterval 00:05:00
</pre>

==== Logfile Betriebsdaten ====
Anlegen eines täglichen Logfile der Betriebsdaten.
<pre>
define filelog_dim_temperature FileLog ./log/filelog_dim_temperature-%W-%d.log dim_.*._temperature:temperature:.*|dim_.*._pressure:pressure:.*
attr filelog_dim_temperature room Dimplex
</pre>

==== Statistiken ====
Folgender Code legt die Statistiken der Betriebsdaten an
<pre>
define dim_statistics statistics dim_.*._temperature|dim_.*._pressure
attr dim_statistics dayChangeTime 1
attr dim_statistics deltaReadings temperature,pressure
attr dim_statistics minAvgMaxReadings temperature,pressure
attr dim_statistics room Dimplex
attr dim_statistics tendencyReadings temperature,pressure
</pre>

=== Zustände ===
Vorschlag der Namensvergabe für die Zustände. Eine sinnvolle Namensvergabe erleichtert später das Anlegen weiterer Definitionen von zum Beispiel Logfiles, Statistiken oder auch [[readingsGroup]].
{| class="wikitable"
|-
| dim_compressor_output || Verdichter
|-
| dim_ventilator_output || Ventilator
|-
| dim_brinepump_ output || Solepumpe
|-
| dim_circulationpump_output || Heizungsumwälzpumpe M13
|-
| dim_2heatgenerator_output || 2.Wärmeerzeuger
|-
| dim_dhwpump_output || Warmwasserpumpe M18
|-
| dim_auxiliarypump_output || Zusatzpumpe M16
|-
| dim_flangeheater_output || Flanschheizung
|}
Coil Verdichter und passenden HourCounter für Verdichter definieren:<pre>
define dim_compressor_output ModbusCoil 0 41
attr dim_compressor_output IODev HeatPumpServer
attr dim_compressor_output disableRegisterMapping 1
attr dim_compressor_output event-min-interval .*:900
attr dim_compressor_output event-on-change-reading .*
attr dim_compressor_output room Dimplex
attr dim_compressor_output source Coil
attr dim_compressor_output updateInterval 00:01:00

define hourcounter_compressor_output HourCounter dim_compressor_output:on dim_compressor_output:off
attr hourcounter_compressor_output event-min-interval tick.*:0,.*:3600
attr hourcounter_compressor_output event-on-change-reading .*
</pre>Coil Ventilator definieren und passenden HourCounter für Ventilator definieren:<pre>
define dim_ventilator_output ModbusCoil 0 43
attr dim_ventilator_output IODev HeatPumpServer
attr dim_ventilator_output disableRegisterMapping 1
attr dim_ventilator_output event-min-interval .*:900
attr dim_ventilator_output event-on-change-reading .*
attr dim_ventilator_output room Dimplex
attr dim_ventilator_output source Coil
attr dim_ventilator_output updateInterval 00:01:00

define hourcounter_ventilator_output HourCounter dim_ventilator_output:on dim_ventilator_output:off
attr hourcounter_ventilator_output event-min-interval tick.*:0,.*:3600
attr hourcounter_ventilator_output event-on-change-reading .*
</pre>Coil 2.Wärmeerzeuger definieren und passenden HourCounter für 2.Wärmeerzeuger definieren:<pre>
define dim_2heatgenerator_output ModbusCoil 0 44
attr dim_2heatgenerator_output IODev HeatPumpServer
attr dim_2heatgenerator_output disableRegisterMapping 1
attr dim_2heatgenerator_output event-min-interval .*:900
attr dim_2heatgenerator_output event-on-change-reading .*
attr dim_2heatgenerator_output room Dimplex
attr dim_2heatgenerator_output source Coil
attr dim_2heatgenerator_output updateInterval 00:01:00

define hourcounter_2heatgenerator_output HourCounter dim_2heatgenerator_output:on dim_2heatgenerator_output:off
attr hourcounter_2heatgenerator_output event-min-interval tick.*:0,.*:3600
attr hourcounter_2heatgenerator_output event-on-change-reading .*
</pre>Coil Heizungsumwälzpumpe M13 definieren und passenden HourCounter für Heizungsumwälzpumpe M13 definieren:<pre>
define dim_circulationpump_output ModbusCoil 0 45
attr dim_circulationpump_output IODev HeatPumpServer
attr dim_circulationpump_output disableRegisterMapping 1
attr dim_circulationpump_output event-min-interval .*:900
attr dim_circulationpump_output event-on-change-reading .*
attr dim_circulationpump_output room Dimplex
attr dim_circulationpump_output source Coil
attr dim_circulationpump_output updateInterval 00:01:00

define hourcounter_circulationpump_output HourCounter dim_circulationpump_output:on dim_circulationpump_output:off
attr hourcounter_circulationpump_output event-min-interval tick.*:0,.*:3600
attr hourcounter_circulationpump_output event-on-change-reading .*
</pre>Coil Warmwasserpumpe M18 definieren und passenden HourCounter für Warmwasserpumpe M18 definieren:<pre>
define dim_dhwpump_output ModbusCoil 0 46
attr dim_dhwpump_output IODev HeatPumpServer
attr dim_dhwpump_output disableRegisterMapping 1
attr dim_dhwpump_output event-min-interval .*:900
attr dim_dhwpump_output event-on-change-reading .*
attr dim_dhwpump_output room Dimplex
attr dim_dhwpump_output source Coil
attr dim_dhwpump_output updateInterval 00:01:00

define hourcounter_dhwpump_output HourCounter dim_dhwpump_output:on dim_dhwpump_output:off
attr hourcounter_dhwpump_output event-min-interval tick.*:0,.*:3600
attr hourcounter_dhwpump_output event-on-change-reading .*
</pre>Coil Zusatzpumpe M16 definieren und Passenden HourCounter für Zusatzpumpe M16 definieren:<pre>
define dim_auxiliarypump_output ModbusCoil 0 49
attr dim_auxiliarypump_output IODev HeatPumpServer
attr dim_auxiliarypump_output disableRegisterMapping 1
attr dim_auxiliarypump_output event-min-interval .*:900
attr dim_auxiliarypump_output event-on-change-reading .*
attr dim_auxiliarypump_output room Dimplex
attr dim_auxiliarypump_output source Coil
attr dim_auxiliarypump_output updateInterval 00:01:00

define hourcounter_auxiliarypump_output HourCounter dim_auxiliarypump_output:on dim_auxiliarypump_output:off
attr hourcounter_auxiliarypump_output event-min-interval tick.*:0,.*:3600
attr hourcounter_auxiliarypump_output event-on-change-reading .*
</pre>Coil Flanschheizung definieren und passenden HourCounter für Flanschheizung M16 definieren:<pre>
define dim_flangeheater_output ModbusCoil 0 50
attr dim_flangeheater_output IODev HeatPumpServer
attr dim_flangeheater_output disableRegisterMapping 1
attr dim_flangeheater_output event-min-interval .*:900
attr dim_flangeheater_output event-on-change-reading .*
attr dim_flangeheater_output room Dimplex
attr dim_flangeheater_output source Coil
attr dim_flangeheater_output updateInterval 00:01:00

define hourcounter_flangeheater_output HourCounter dim_flangeheater_output:on dim_flangeheater_output:off
attr hourcounter_flangeheater_output event-min-interval tick.*:0,.*:3600
attr hourcounter_flangeheater_output event-on-change-reading .*
</pre>

==== Logfile Zustände ====
Anlegen eines wöchentlichen Logfile der Zustände:
<pre>
define filelog_dim_output_week FileLog ./log/filelog_dim_output_week-%W.log dim_.*._output.*
attr filelog_dim_output_week room Dimplex
</pre>

=== Historie ===
Vorschlag der Namensvergabe für die Historie. Eine sinnvolle Namensvergabe erleichtert später das Anlegen weiterer Definitionen von zum Beispiel Logfiles, Statistiken oder auch [[readingsGroup]].
{| class="wikitable"
|-
| dim_compressor_history || Verdichter
|-
| dim_ventilator_history || Ventilator
|-
| dim_brinepump_history || Solepumpe
|-
| dim_circulationpump_history || Heizungsumwälzpumpe M13
|-
| dim_2heatgenerator_history || 2.Wärmeerzeuger
|-
| dim_dhwpump_history || Warmwasserpumpe M18
|-
| dim_auxiliarypump_history || Zusatzpumpe M16
|-
| dim_flangeheater_history || Flanschheizung
|}
Register Historie Verdichter definieren:<pre>
define dim_compressor_history ModbusRegister 0 72
attr dim_compressor_history IODev HeatPumpServer
attr dim_compressor_history alignUpdateInterval 00:01:00
attr dim_compressor_history event-on-change-reading .*
attr dim_compressor_history plcDataType INT
attr dim_compressor_history registerType Holding
attr dim_compressor_history room Dimplex
attr dim_compressor_history updateInterval 01:00:00
</pre>Register Historie Ventilator definieren:<pre>
define dim_ventilator_history ModbusRegister 0 74
attr dim_ventilator_history IODev HeatPumpServer
attr dim_ventilator_history alignUpdateInterval 00:01:00
attr dim_ventilator_history event-on-change-reading .*
attr dim_ventilator_history plcDataType INT
attr dim_ventilator_history registerType Holding
attr dim_ventilator_history room Dimplex
attr dim_ventilator_history updateInterval 01:00:00
</pre>Register Historie 2.Wärmeerzeuger definieren:<pre>
define dim_2heatgenerator_history ModbusRegister 0 75
attr dim_2heatgenerator_history IODev HeatPumpServer
attr dim_2heatgenerator_history alignUpdateInterval 00:01:00
attr dim_2heatgenerator_history event-on-change-reading .*
attr dim_2heatgenerator_history plcDataType INT
attr dim_2heatgenerator_history registerType Holding
attr dim_2heatgenerator_history room Dimplex
attr dim_2heatgenerator_history updateInterval 01:00:00
</pre>Register Historie Heizungsumwälzpumpe M13 definieren:<pre>
define dim_circulationpump_history ModbusRegister 0 76
attr dim_circulationpump_history IODev HeatPumpServer
attr dim_circulationpump_history alignUpdateInterval 00:01:00
attr dim_circulationpump_history event-on-change-reading .*
attr dim_circulationpump_history plcDataType INT
attr dim_circulationpump_history registerType Holding
attr dim_circulationpump_history room Dimplex
attr dim_circulationpump_history updateInterval 01:00:00
</pre>Register Historie Warmwasserpumpe M18 definieren:<pre>
define dim_dhwpump_history ModbusRegister 0 77
attr dim_dhwpump_history IODev HeatPumpServer
attr dim_dhwpump_history alignUpdateInterval 00:01:00
attr dim_dhwpump_history event-on-change-reading .*
attr dim_dhwpump_history plcDataType INT
attr dim_dhwpump_history registerType Holding
attr dim_dhwpump_history room Dimplex
attr dim_dhwpump_history updateInterval 01:00:00
</pre>Register Historie Flanschheizung definieren:<pre>
define dim_flangeheater_history ModbusRegister 0 78
attr dim_flangeheater_history IODev HeatPumpServer
attr dim_flangeheater_history alignUpdateInterval 00:01:00
attr dim_flangeheater_history event-on-change-reading .*
attr dim_flangeheater_history plcDataType INT
attr dim_flangeheater_history registerType Holding
attr dim_flangeheater_history room Dimplex
attr dim_flangeheater_history updateInterval 01:00:00
</pre>
==== Logfile Historie ====
Anlegen eines monatlichen Logfile für die Historischen Daten:
<pre>
define filelog_dim_history_month FileLog ./log/filelog_dim_history_month-%m.log dim_.*._history.*
attr filelog_dim_history_month room Dimplex
</pre>

==== Wärmemengen ====
Laut Definition aus dem [http://www.dimplex.de/wiki Dimplex-Wiki] werden die Wärmemengen für Heizen, Warmwasser und Schwimmbad aus 3 Register-Adressen zusammengesetzt. Im Nachfolgenden Code-Beispiel wird dies entsprechend dargestellt. Dabei wird jeweils im ersten Register ein neues userReading mit der Darstellung der Gesamtwärmemenge angelegt.

Wärmemenge Heizen definieren:
<pre>
define dim_heating1_thermalenergy ModbusRegister 0 5096
attr dim_heating1_thermalenergy IODev HeatPumpServer
attr dim_heating1_thermalenergy event-on-change-reading .*
attr dim_heating1_thermalenergy plcDataType INT
attr dim_heating1_thermalenergy registerType Holding
attr dim_heating1_thermalenergy room Dimplex
attr dim_heating1_thermalenergy updateInterval 00:15:00
attr dim_heating1_thermalenergy userReadings heatingthermalenergy {\
((ReadingsVal("dim_heating3_thermalenergy","state",0)*100000000)+\
(ReadingsVal("dim_heating2_thermalenergy","state",0)*10000)+\
(ReadingsVal("dim_heating1_thermalenergy","state",0)))}

define dim_heating2_thermalenergy ModbusRegister 0 5097
attr dim_heating2_thermalenergy IODev HeatPumpServer
attr dim_heating2_thermalenergy event-on-change-reading .*
attr dim_heating2_thermalenergy plcDataType INT
attr dim_heating2_thermalenergy registerType Holding
attr dim_heating2_thermalenergy room Dimplex
attr dim_heating2_thermalenergy updateInterval 00:15:00

define dim_heating3_thermalenergy ModbusRegister 0 5098
attr dim_heating3_thermalenergy IODev HeatPumpServer
attr dim_heating3_thermalenergy event-on-change-reading .*
attr dim_heating3_thermalenergy plcDataType INT
attr dim_heating3_thermalenergy registerType Holding
attr dim_heating3_thermalenergy room Dimplex
attr dim_heating3_thermalenergy updateInterval 00:15:00
</pre>Wärmemenge Warmwasser definieren:<pre>
define dim_dhw1_thermalenergy ModbusRegister 0 5099
attr dim_dhw1_thermalenergy IODev HeatPumpServer
attr dim_dhw1_thermalenergy event-on-change-reading .*
attr dim_dhw1_thermalenergy plcDataType INT
attr dim_dhw1_thermalenergy registerType Holding
attr dim_dhw1_thermalenergy room Dimplex
attr dim_dhw1_thermalenergy updateInterval 00:15:00
attr dim_dhw1_thermalenergy userReadings dhwthermalenergy {\ ((ReadingsVal("dim_dhw3_thermalenergy","state",0)*100000000)+\
(ReadingsVal("dim_dhw2_thermalenergy","state",0)*10000)+\
(ReadingsVal("dim_dhw1_thermalenergy","state",0)))}

define dim_dhw2_thermalenergy ModbusRegister 0 5100
attr dim_dhw2_thermalenergy IODev HeatPumpServer
attr dim_dhw2_thermalenergy event-on-change-reading .*
attr dim_dhw2_thermalenergy plcDataType INT
attr dim_dhw2_thermalenergy registerType Holding
attr dim_dhw2_thermalenergy room Dimplex
attr dim_dhw2_thermalenergy updateInterval 00:15:00

define dim_dhw3_thermalenergy ModbusRegister 0 5101
attr dim_dhw3_thermalenergy IODev HeatPumpServer
attr dim_dhw3_thermalenergy event-on-change-reading .*
attr dim_dhw3_thermalenergy plcDataType INT
attr dim_dhw3_thermalenergy registerType Holding
attr dim_dhw3_thermalenergy room Dimplex
attr dim_dhw3_thermalenergy updateInterval 00:15:00
</pre>
==== Umweltenergie ====
Als Umweltenergie wird die zugeführte Kälteenergie aus der Umwelt (Luft/Erdreich) bezeichnet. Das Auslesen dieser Werte über die Schnittstelle ist erst ab einem neueren Softwarestand möglich. Die Differenz der gesamten Wärmemenge und der Umweltenergie entspricht in etwa der Energie des Verdichters.

Umweltenergie/entzogene Kälteenergie definieren:
<pre>
define dim_environment1_energy ModbusRegister 0 5127
attr dim_environment1_energy IODev HeatPumpServer
attr dim_environment1_energy event-on-change-reading .*
attr dim_environment1_energy plcDataType INT
attr dim_environment1_energy registerType Holding
attr dim_environment1_energy room Dimplex
attr dim_environment1_energy updateInterval 00:15:00
attr dim_environment1_energy userReadings environmentenergy {\
((ReadingsVal("dim_environment3_energy","state",0)*100000000)+\
(ReadingsVal("dim_environment2_energy","state",0)*10000)+\
(ReadingsVal("dim_environment1_energy","state",0)))}

define dim_environment2_energy ModbusRegister 0 5128
attr dim_environment2_energy IODev HeatPumpServer
attr dim_environment2_energy event-on-change-reading .*
attr dim_environment2_energy plcDataType INT
attr dim_environment2_energy registerType Holding
attr dim_environment2_energy room Dimplex
attr dim_environment2_energy updateInterval 00:15:00

define dim_environment3_energy ModbusRegister 0 5129
attr dim_environment3_energy IODev HeatPumpServer
attr dim_environment3_energy event-on-change-reading .*
attr dim_environment3_energy plcDataType INT
attr dim_environment3_energy registerType Holding
attr dim_environment3_energy room Dimplex
attr dim_environment3_energy updateInterval 00:15:00
</pre>

==== Logfile Wärmemengen ====
Anlegen eines jährlichen Logfile der Wärmemengen.
<pre>
define filelog_dim_thermalenergy_year FileLog ./log/filelog_dim_thermalenergy_year-%y.log dim_heating1_thermalenergy:heatingthermalenergy:.*|dim_heating1_thermalenergy:heatingthermalenergy:.*
attr filelog_dim_thermalenergy_year room Dimplex
</pre>

=== Meldungen ===
[[Bild:dimplex_rh_status_heatpump.jpg|thumb|right|Beispiel Meldungen]]
Eine sinnvolle Anzeige sind die Meldungen (Status, Sperre, Störung) der Wärmepumpe. Im nachfolgenden Beispiel werden die Meldungen mit dem Hilfsmodul [[readingsHistory]] dargestellt. Die Definitionen der Meldungen beziehen sich auf die im [http://www.dimplex.de/wiki Dimplex-Wiki] beschriebene L-Software. Bei abweichenden Softwareständen müssen die Register sowie die Texte angepasst werden.

Register Statusmeldung definieren:

<pre>
define dim_status_heatpump ModbusRegister 0 103
attr dim_status_heatpump IODev HeatPumpServer
attr dim_status_heatpump event-on-change-reading .*
attr dim_status_heatpump plcDataType INT
attr dim_status_heatpump registerType Holding
attr dim_status_heatpump room Dimplex
attr dim_status_heatpump updateInterval 00:00:10
attr dim_status_heatpump userReadings Status {\
((ReadingsVal($name,"state","") == 1) ? "Aus":\
(ReadingsVal($name,"state","") == 4) ? "Warmwasser":\
(ReadingsVal($name,"state","") == 10) ? "Abtauen":\
(ReadingsVal($name,"state","") == 11) ? "Durchflussüberwachnung":"")}

</pre>Register Sperrmeldunge definieren:<pre>
define dim_block_heatpump ModbusRegister 0 104
attr dim_block_heatpump IODev HeatPumpServer
attr dim_block_heatpump event-on-change-reading .*
attr dim_block_heatpump plcDataType INT
attr dim_block_heatpump registerType Holding
attr dim_block_heatpump room Dimplex
attr dim_block_heatpump updateInterval 00:00:10
attr dim_block_heatpump userReadings Sperre {\
((ReadingsVal($name,"state","") == 0) ? "":\
(ReadingsVal($name,"state","") == 7) ? "Systemkontrolle":\
(ReadingsVal($name,"state","") == 9) ? "Pumpenvorlauf":\
(ReadingsVal($name,"state","") == 10) ? "Mindeststandzeit":\
(ReadingsVal($name,"state","") == 11) ? "Netzbelastung":\
(ReadingsVal($name,"state","") == 12) ? "Schaltspielsperre":\
(ReadingsVal($name,"state","") == 15) ? "EVU":"")}
</pre>Register Störmeldungen definieren:<pre>
define dim_fault_heatpump ModbusRegister 0 105
attr dim_fault_heatpump IODev HeatPumpServer
attr dim_fault_heatpump event-on-change-reading .*
attr dim_fault_heatpump plcDataType INT
attr dim_fault_heatpump registerType Holding
attr dim_fault_heatpump room Dimplex
attr dim_fault_heatpump updateInterval 00:01:00
attr dim_fault_heatpump userReadings Störung {\
((ReadingsVal($name,"state","") == 0) ? "":\
(ReadingsVal($name,"state","") == 6) ? "Elektronisches Ex.Ventil":\
(ReadingsVal($name,"state","") == 15) ? "Sensorik":\
(ReadingsVal($name,"state","") == 19) ? "!Primärkreis":\
(ReadingsVal($name,"state","") == 22) ? "!Warmwasser":\
(ReadingsVal($name,"state","") == 23) ? "!Last Verdichter":\
(ReadingsVal($name,"state","") == 24) ? "!Codierung":\
(ReadingsVal($name,"state","") == 25) ? "!Niederdruck":\
(ReadingsVal($name,"state","") == 26) ? "!Frostschutz":\
(ReadingsVal($name,"state","") == 29) ? "!Temperatur Differenz":\
(ReadingsVal($name,"state","") == 31) ? "!Durchfluss":"")}
</pre>
==== Anzeige der Meldungen ====
readingsHistory definieren:<pre>
define rh_dim_status_heatpump readingsHistory dim_status_heatpump:Status dim_block_heatpump:Sperre dim_fault_heatpump:Störung
attr rh_dim_status_heatpump alias Status
attr rh_dim_status_heatpump mapping {'dim_status_heatpump' => '', 'dim_block_heatpump' => '', 'dim_fault_heatpump' => ''}
attr rh_dim_status_heatpump nohtml 1
attr rh_dim_status_heatpump room Dimplex
attr rh_dim_status_heatpump rows 20
attr rh_dim_status_heatpump timestampFormat %b %a %R
</pre>

== Plotbeispiel ==
=== Temperaturen ===
<pre>
# Created by FHEM/98_SVG.pm, 2015-05-11 21:40:00
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 ytics y2tics
set ylabel ""
set y2label "Temperatur (°C)"

#filelog_dim_temperature_week 4:dim_outdoor_temperature.*::
#filelog_dim_temperature_week 4:dim_room_temperature.*::
#filelog_dim_temperature_week 4:dim_return_temperature.*::
#filelog_dim_temperature_week 4:dim_returnset_temperature.*::
#filelog_dim_temperature_week 4:dim_dhw_temperature.*::
#filelog_dim_temperature_week 4:dim_flow_temperature.*::
#filelog_dim_temperature_week 4:dim_brine_temperature.*::

plot "<IN>" using 1:2 axes x1y2 title 'AT' ls l7 lw 1 with lines,\
"<IN>" using 1:2 axes x1y2 title 'RT' ls l1 lw 1 with lines,\
"<IN>" using 1:2 axes x1y2 title 'RL' ls l2 lw 1 with lines,\
"<IN>" using 1:2 axes x1y2 title 'RLS' ls l3 lw 1 with lines,\
"<IN>" using 1:2 axes x1y2 title 'WWT' ls l4 lw 1 with lines,\
"<IN>" using 1:2 axes x1y2 title 'VLT' ls l0 lw 1 with lines,\
"<IN>" using 1:2 axes x1y2 title 'SOL' ls l6 lw 1 with lines
</pre>

=== Ausgänge ===
<pre>
# Created by FHEM/98_SVG.pm, 2015-05-11 21:45:00
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 ''
set ytics ("An" -1, "Aus" -2, "An" -5, "Aus" -6, "An" -9, "Aus" -10, "An" -13, "Aus" -14)
set y2tics ("An" 1, "Aus" 0, "An" -3, "Aus" -4, "An" -7, "Aus" -8, "An" -11, "Aus" -12)
set grid
set ylabel ""
set y2label "Digital"
set yrange [-16:2]
set y2range [-16:2]

#FileLog 3:dim_compressor_output.*::$fld[2]=~"on"?1:0
#FileLog 3:dim_ventilator_output.*::$fld[2]=~"on"?-1:-2
#FileLog 3:dim_2heatgenerator_output.*::$fld[2]=~"on"?-3:-4
#FileLog 3:dim_circulationpump_output.*::$fld[2]=~"on"?-5:-6
#FileLog 3:dim_dhwpump_output.*::$fld[2]=~"on"?-7:-8
#FileLog 3:dim_auxiliarypump_output.*::$fld[2]=~"on"?-9:-10
#FileLog 3:dim_solarpump_output.*::$fld[2]=~"on"?-11:-12
#FileLog 3:dim_flangeheater_output.*::$fld[2]=~"on"?-13:-14

plot "<IN>" using 1:2 axes x1y2 title 'Vd' ls l7 lw 1.5 with steps,\
"<IN>" using 1:2 axes x1y2 title 'Ve' ls l6 lw 1.5 with steps,\
"<IN>" using 1:2 axes x1y2 title '2.We' ls l5 lw 1.5 with steps,\
"<IN>" using 1:2 axes x1y2 title 'Hub' ls l4 lw 1.5 with steps,\
"<IN>" using 1:2 axes x1y2 title 'Wup' ls l3 lw 1 with steps,\
"<IN>" using 1:2 axes x1y2 title 'Zup' ls l0 lw 1.5 with steps,\
"<IN>" using 1:2 axes x1y2 title 'Sol' ls l2 lw 1.5 with steps,\
"<IN>" using 1:2 axes x1y2 title 'Flh' ls l7 lw 1.5 with steps
</pre>

[[Bild:dimplex_hp_graph.jpg|thumb|right|Plotbeispiel]]
Im nebenstehenden Plotbeispiel werde die Temperaturen (Analogwerte) sowie die Ausgänge (Digitalwerte) dargestellt. Im einzelnen sind die Kurven für die

* Aussen- (AT)
* Raum- (RT)
* Rücklauf- (RL)
* Rücklaufsoll- (RLS)
* Warmwasser- (WWT) und
* Vorlauftemperatur (VLT)

sowie die Ausgänge für

* Verdichter 1 (Vd)
* Ventilator (Ve)
* 2.Wärmeerzeuger (2We)
* Heizungsumwälzpumpe (Hup)
* Warmwasserumwälzpumpe (Wup) und
* Zusatzumwälzpumpe (Zup)

enthalten.

= Kontakt =
Weitere Fragen, Wünsche und Anregungen bitte im entsprechenden {{Link2Forum|Topic=33086|LinkText=Forenthread zum Wiki-Artikel "Dimplex Wärmepumpenmanager"}} zur Diskussion stellen.

Offene Punkte:
- Darstellung der Werte in einer readingsGroup
- Zugriff auf Zeitfunktionen mit Lesen und Schreiben

[[Kategorie:HOWTOS]]
[[Kategorie:Heizungssteuerung]]
[[Kategorie:Other Components]]

Dimplex Wärmepumpenmanager

2025-03-30T16:32:30Z

TomLee:

Mit der NWPM-Erweiterung ist es möglich, den Dimplex Wärmepumpenmanager in ein Hausnetzwerk einzubinden. Durch die Einbindung der NWPM-Erweiterung ist es ebenfalls möglich, die zur Verfügung gestellten Werte vom Wärmepumpenmanager mittels ModbusTCP in FHEM zu übernehmen, anzuzeigen und grafisch darzustellen.

== Voraussetzung ==
Die Anbindung des Dimplex Wärmepumpenmanager an FHEM erfolgt mittels NWPM-Erweiterung und der aktuellen FHEM Installation. Weiterhin werden die zur Verfügung stehenden Module:

* 36_ModbusTCPServer.pm
* 37_ModbusCoil.pm
* 37_ModbusRegister.pm

genutzt. Getestet wurde der Zugriff auf einem BeagleBone Black mit der [[BeagleBone Black|hier beschriebenen]] Debian Installation.

== Installation ==
Die oben aufgeführten Module sind notwendig und müssen nachinstalliert werden. Zum Zeitpunkt der Erstellung dieser Dokumentation (31.1.2015) sind diese noch nicht offiziell in FHEM enthalten und werden auch nicht mittels Update verteilt. Die Module werden mit dem Befehl:
<pre>
update all https://raw.githubusercontent.com/ChrisD70/FHEM-Modules/master/autoupdate/mb/controls_modbus.txt
</pre>
über die FHEM Befehlszeile installiert und anschließend
<pre>
reload 36_ModbusTCPServer.pm
reload 37_ModbusCoil.pm
reload 37_ModbusRegister.pm
</pre>
mit einem Reload geladen.
== Benutzung ==
=== Anlegen der ModbusTCPServer Verbindung ===
Wie im nachfolgenden angegeben muss zunächst eine ModbusTCPServer Verbindung hergestellt werden. Die angegebene IP-Adresse muss durch die IP-Adresse der Wärmepumpe ersetzt werden.
<pre>
########################################################
## ModbusTCPServer definieren
########################################################
define HeatPumpServer ModbusTCPServer 192.168.1.150
attr HeatPumpServer verbose 2
</pre>
Ein erfolgreicher Verbindungsaufbau wird mit einem „ok“ im State gekennzeichnet.

=== Modbus-Register/Coil Adressen definieren ===
Im nachfolgendem Beispiel wird anhand der Außentemperatur die Adressdefinition erklärt.
<pre>
define dim_outdoor_temperature ModbusRegister 0 1
attr dim_outdoor_temperature IODev HeatPumpServer
attr dim_outdoor_temperature conversion 0.1:0
attr dim_outdoor_temperature event-min-interval .*:900
attr dim_outdoor_temperature event-on-change-reading .*
attr dim_outdoor_temperature plcDataType INT
attr dim_outdoor_temperature registerType Holding
attr dim_outdoor_temperature room Dimplex
attr dim_outdoor_temperature stateAlias temperature
attr dim_outdoor_temperature stateFormat {sprintf("%0.1f", ReadingsVal($name,"state",0))}
attr dim_outdoor_temperature updateInterval 00:10:00
</pre>
Erklärung:
{| class="wikitable"
|+ Erläuterungen zur Adressdefinition
|-
! Attribut !! Erläuterungen
|-
| ModbusRegister 0 1 || 0 Device Adresse, in der Regel bei ModbusTCP immer 0
|-
| ModbusRegister 0 1 || 1 Register Adresse, wird unter www.dimplex.de/wiki → ModbusTCP → Spalten IP zur Verfügung gestellt
|-
| IODev || Verwendeter und zuvor angelegter ModbusTCPServer
|-
| conversion || eine gegebenenfalls notwendige Konvertierung des übermittelten Values
|-
| PlcDataType || Ermögliche automatische Interpretation der ankommenden Daten
|-
| stateAlias || es wird ein zusätzliches Reading erzeugt, um zum Beispiel das Statistic-Modul nutzen zu können, stateAlias ist eine echte Kopie von "state"
|-
| updateInterval || Intervall des Abfragezyklus (z.B. 00:10:00 Minuten)
|-
|}

=== Betriebsdaten ===
Vorschlag der Namensvergabe für die Betriebsdaten. Eine sinnvolle Namensvergabe erleichtert später das Anlegen weiterer Definitionen von zum Beispiel Logfiles, Statistiken oder auch [[readingsGroup]].
{| class="wikitable"
|-
| dim_outdoor_temperature || Außentemperatur
|-
| dim_flow_temperature || Vorlauftemperatur
|-
| dim_return_temperature || Rücklauftemperatur
|-
| dim_returnset_temperature || Rücklaufsolltemperatur
|-
| dim_room_temperature || Raumtemperatur
|-
| dim_dhw_temperature || Warmwassertemperatur
|-
| dim_dhwset_temperature || Warmwassersolltemperatur
|-
| dim_brine_temperature || Soletemperatur
|-
| dim_high_pressure || Hochdruck
|-
| dim_low_pressure || Niederdruck
|}
Register Warmwassertemperatur definieren:<pre>
define dim_dhw_temperature ModbusRegister 0 3
attr dim_dhw_temperature IODev HeatPumpServer
attr dim_dhw_temperature conversion 0.1:0
attr dim_dhw_temperature event-min-interval .*:900
attr dim_dhw_temperature event-on-change-reading .*
attr dim_dhw_temperature plcDataType INT
attr dim_dhw_temperature registerType Holding
attr dim_dhw_temperature room Dimplex
attr dim_dhw_temperature stateAlias temperature
attr dim_dhw_temperature stateFormat {sprintf("%0.1f", ReadingsVal($name,"state",0))}
attr dim_dhw_temperature updateInterval 00:01:00
</pre>Register Vorlauftemperatur definieren:<pre>
define dim_flow_temperature ModbusRegister 0 5
attr dim_flow_temperature IODev HeatPumpServer
attr dim_flow_temperature conversion 0.1:0
attr dim_flow_temperature event-min-interval .*:900
attr dim_flow_temperature event-on-change-reading .*
attr dim_flow_temperature plcDataType INT
attr dim_flow_temperature registerType Holding
attr dim_flow_temperature room Dimplex
attr dim_flow_temperature stateAlias temperature
attr dim_flow_temperature stateFormat {sprintf("%0.1f", ReadingsVal($name,"state",0))}
attr dim_flow_temperature updateInterval 00:01:00
</pre>Register Rücklauftemperatur definieren:<pre>
define dim_return_temperature ModbusRegister 0 2
attr dim_return_temperature IODev HeatPumpServer
attr dim_return_temperature conversion 0.1:0
attr dim_return_temperature event-min-interval .*:900
attr dim_return_temperature event-on-change-reading .*
attr dim_return_temperature plcDataType INT
attr dim_return_temperature registerType Holding
attr dim_return_temperature room Dimplex
attr dim_return_temperature stateAlias temperature
attr dim_return_temperature stateFormat {sprintf("%0.1f", ReadingsVal($name,"state",0))}
attr dim_return_temperature updateInterval 00:01:00
</pre>Register Rücklaufsolltemperatur definieren:<pre>
define dim_returnset_temperature ModbusRegister 0 53
attr dim_returnset_temperature IODev HeatPumpServer
attr dim_returnset_temperature conversion 0.1:0
attr dim_returnset_temperature event-min-interval .*:900
attr dim_returnset_temperature event-on-change-reading .*
attr dim_returnset_temperature plcDataType INT
attr dim_returnset_temperature registerType Holding
attr dim_returnset_temperature room Dimplex
attr dim_returnset_temperature stateAlias temperature
attr dim_returnset_temperature stateFormat {sprintf("%0.1f", ReadingsVal($name,"state",0))}
attr dim_returnset_temperature updateInterval 00:05:00
</pre>

==== Logfile Betriebsdaten ====
Anlegen eines täglichen Logfile der Betriebsdaten.
<pre>
define filelog_dim_temperature FileLog ./log/filelog_dim_temperature-%W-%d.log dim_.*._temperature:temperature:.*|dim_.*._pressure:pressure:.*
attr filelog_dim_temperature room Dimplex
</pre>

==== Statistiken ====
Folgender Code legt die Statistiken der Betriebsdaten an
<pre>
define dim_statistics statistics dim_.*._temperature|dim_.*._pressure
attr dim_statistics dayChangeTime 1
attr dim_statistics deltaReadings temperature,pressure
attr dim_statistics minAvgMaxReadings temperature,pressure
attr dim_statistics room Dimplex
attr dim_statistics tendencyReadings temperature,pressure
</pre>

=== Zustände ===
Vorschlag der Namensvergabe für die Zustände. Eine sinnvolle Namensvergabe erleichtert später das Anlegen weiterer Definitionen von zum Beispiel Logfiles, Statistiken oder auch [[readingsGroup]].
{| class="wikitable"
|-
| dim_compressor_output || Verdichter
|-
| dim_ventilator_output || Ventilator
|-
| dim_brinepump_ output || Solepumpe
|-
| dim_circulationpump_output || Heizungsumwälzpumpe M13
|-
| dim_2heatgenerator_output || 2.Wärmeerzeuger
|-
| dim_dhwpump_output || Warmwasserpumpe M18
|-
| dim_auxiliarypump_output || Zusatzpumpe M16
|-
| dim_flangeheater_output || Flanschheizung
|}
Coil Verdichter und passenden HourCounter für Verdichter definieren:<pre>
define dim_compressor_output ModbusCoil 0 41
attr dim_compressor_output IODev HeatPumpServer
attr dim_compressor_output disableRegisterMapping 1
attr dim_compressor_output event-min-interval .*:900
attr dim_compressor_output event-on-change-reading .*
attr dim_compressor_output room Dimplex
attr dim_compressor_output source Coil
attr dim_compressor_output updateInterval 00:01:00

define hourcounter_compressor_output HourCounter dim_compressor_output:on dim_compressor_output:off
attr hourcounter_compressor_output event-min-interval tick.*:0,.*:3600
attr hourcounter_compressor_output event-on-change-reading .*
</pre>Coil Ventilator definieren und passenden HourCounter für Ventilator definieren:<pre>
define dim_ventilator_output ModbusCoil 0 43
attr dim_ventilator_output IODev HeatPumpServer
attr dim_ventilator_output disableRegisterMapping 1
attr dim_ventilator_output event-min-interval .*:900
attr dim_ventilator_output event-on-change-reading .*
attr dim_ventilator_output room Dimplex
attr dim_ventilator_output source Coil
attr dim_ventilator_output updateInterval 00:01:00

define hourcounter_ventilator_output HourCounter dim_ventilator_output:on dim_ventilator_output:off
attr hourcounter_ventilator_output event-min-interval tick.*:0,.*:3600
attr hourcounter_ventilator_output event-on-change-reading .*
</pre>Coil 2.Wärmeerzeuger definieren und passenden HourCounter für 2.Wärmeerzeuger definieren:<pre>
define dim_2heatgenerator_output ModbusCoil 0 44
attr dim_2heatgenerator_output IODev HeatPumpServer
attr dim_2heatgenerator_output disableRegisterMapping 1
attr dim_2heatgenerator_output event-min-interval .*:900
attr dim_2heatgenerator_output event-on-change-reading .*
attr dim_2heatgenerator_output room Dimplex
attr dim_2heatgenerator_output source Coil
attr dim_2heatgenerator_output updateInterval 00:01:00

define hourcounter_2heatgenerator_output HourCounter dim_2heatgenerator_output:on dim_2heatgenerator_output:off
attr hourcounter_2heatgenerator_output event-min-interval tick.*:0,.*:3600
attr hourcounter_2heatgenerator_output event-on-change-reading .*
</pre>Coil Heizungsumwälzpumpe M13 definieren und passenden HourCounter für Heizungsumwälzpumpe M13 definieren:<pre>
define dim_circulationpump_output ModbusCoil 0 45
attr dim_circulationpump_output IODev HeatPumpServer
attr dim_circulationpump_output disableRegisterMapping 1
attr dim_circulationpump_output event-min-interval .*:900
attr dim_circulationpump_output event-on-change-reading .*
attr dim_circulationpump_output room Dimplex
attr dim_circulationpump_output source Coil
attr dim_circulationpump_output updateInterval 00:01:00

define hourcounter_circulationpump_output HourCounter dim_circulationpump_output:on dim_circulationpump_output:off
attr hourcounter_circulationpump_output event-min-interval tick.*:0,.*:3600
attr hourcounter_circulationpump_output event-on-change-reading .*
</pre>Coil Warmwasserpumpe M18 definieren und passenden HourCounter für Warmwasserpumpe M18 definieren:<pre>
define dim_dhwpump_output ModbusCoil 0 46
attr dim_dhwpump_output IODev HeatPumpServer
attr dim_dhwpump_output disableRegisterMapping 1
attr dim_dhwpump_output event-min-interval .*:900
attr dim_dhwpump_output event-on-change-reading .*
attr dim_dhwpump_output room Dimplex
attr dim_dhwpump_output source Coil
attr dim_dhwpump_output updateInterval 00:01:00

define hourcounter_dhwpump_output HourCounter dim_dhwpump_output:on dim_dhwpump_output:off
attr hourcounter_dhwpump_output event-min-interval tick.*:0,.*:3600
attr hourcounter_dhwpump_output event-on-change-reading .*
</pre>Coil Zusatzpumpe M16 definieren und Passenden HourCounter für Zusatzpumpe M16 definieren:<pre>
define dim_auxiliarypump_output ModbusCoil 0 49
attr dim_auxiliarypump_output IODev HeatPumpServer
attr dim_auxiliarypump_output disableRegisterMapping 1
attr dim_auxiliarypump_output event-min-interval .*:900
attr dim_auxiliarypump_output event-on-change-reading .*
attr dim_auxiliarypump_output room Dimplex
attr dim_auxiliarypump_output source Coil
attr dim_auxiliarypump_output updateInterval 00:01:00

define hourcounter_auxiliarypump_output HourCounter dim_auxiliarypump_output:on dim_auxiliarypump_output:off
attr hourcounter_auxiliarypump_output event-min-interval tick.*:0,.*:3600
attr hourcounter_auxiliarypump_output event-on-change-reading .*
</pre>Coil Flanschheizung definieren und passenden HourCounter für Flanschheizung M16 definieren:<pre>
define dim_flangeheater_output ModbusCoil 0 50
attr dim_flangeheater_output IODev HeatPumpServer
attr dim_flangeheater_output disableRegisterMapping 1
attr dim_flangeheater_output event-min-interval .*:900
attr dim_flangeheater_output event-on-change-reading .*
attr dim_flangeheater_output room Dimplex
attr dim_flangeheater_output source Coil
attr dim_flangeheater_output updateInterval 00:01:00

define hourcounter_flangeheater_output HourCounter dim_flangeheater_output:on dim_flangeheater_output:off
attr hourcounter_flangeheater_output event-min-interval tick.*:0,.*:3600
attr hourcounter_flangeheater_output event-on-change-reading .*
</pre>

==== Logfile Zustände ====
Anlegen eines wöchentlichen Logfile der Zustände:
<pre>
define filelog_dim_output_week FileLog ./log/filelog_dim_output_week-%W.log dim_.*._output.*
attr filelog_dim_output_week room Dimplex
</pre>

=== Historie ===
Vorschlag der Namensvergabe für die Historie. Eine sinnvolle Namensvergabe erleichtert später das Anlegen weiterer Definitionen von zum Beispiel Logfiles, Statistiken oder auch [[readingsGroup]].
{| class="wikitable"
|-
| dim_compressor_history || Verdichter
|-
| dim_ventilator_history || Ventilator
|-
| dim_brinepump_history || Solepumpe
|-
| dim_circulationpump_history || Heizungsumwälzpumpe M13
|-
| dim_2heatgenerator_history || 2.Wärmeerzeuger
|-
| dim_dhwpump_history || Warmwasserpumpe M18
|-
| dim_auxiliarypump_history || Zusatzpumpe M16
|-
| dim_flangeheater_history || Flanschheizung
|}
Register Historie Verdichter definieren:<pre>
define dim_compressor_history ModbusRegister 0 72
attr dim_compressor_history IODev HeatPumpServer
attr dim_compressor_history alignUpdateInterval 00:01:00
attr dim_compressor_history event-on-change-reading .*
attr dim_compressor_history plcDataType INT
attr dim_compressor_history registerType Holding
attr dim_compressor_history room Dimplex
attr dim_compressor_history updateInterval 01:00:00
</pre>Register Historie Ventilator definieren:<pre>
define dim_ventilator_history ModbusRegister 0 74
attr dim_ventilator_history IODev HeatPumpServer
attr dim_ventilator_history alignUpdateInterval 00:01:00
attr dim_ventilator_history event-on-change-reading .*
attr dim_ventilator_history plcDataType INT
attr dim_ventilator_history registerType Holding
attr dim_ventilator_history room Dimplex
attr dim_ventilator_history updateInterval 01:00:00
</pre>Register Historie 2.Wärmeerzeuger definieren:<pre>
define dim_2heatgenerator_history ModbusRegister 0 75
attr dim_2heatgenerator_history IODev HeatPumpServer
attr dim_2heatgenerator_history alignUpdateInterval 00:01:00
attr dim_2heatgenerator_history event-on-change-reading .*
attr dim_2heatgenerator_history plcDataType INT
attr dim_2heatgenerator_history registerType Holding
attr dim_2heatgenerator_history room Dimplex
attr dim_2heatgenerator_history updateInterval 01:00:00
</pre>Register Historie Heizungsumwälzpumpe M13 definieren:<pre>
define dim_circulationpump_history ModbusRegister 0 76
attr dim_circulationpump_history IODev HeatPumpServer
attr dim_circulationpump_history alignUpdateInterval 00:01:00
attr dim_circulationpump_history event-on-change-reading .*
attr dim_circulationpump_history plcDataType INT
attr dim_circulationpump_history registerType Holding
attr dim_circulationpump_history room Dimplex
attr dim_circulationpump_history updateInterval 01:00:00
</pre>Register Historie Warmwasserpumpe M18 definieren:<pre>
define dim_dhwpump_history ModbusRegister 0 77
attr dim_dhwpump_history IODev HeatPumpServer
attr dim_dhwpump_history alignUpdateInterval 00:01:00
attr dim_dhwpump_history event-on-change-reading .*
attr dim_dhwpump_history plcDataType INT
attr dim_dhwpump_history registerType Holding
attr dim_dhwpump_history room Dimplex
attr dim_dhwpump_history updateInterval 01:00:00
</pre>Register Historie Flanschheizung definieren:<pre>
define dim_flangeheater_history ModbusRegister 0 78
attr dim_flangeheater_history IODev HeatPumpServer
attr dim_flangeheater_history alignUpdateInterval 00:01:00
attr dim_flangeheater_history event-on-change-reading .*
attr dim_flangeheater_history plcDataType INT
attr dim_flangeheater_history registerType Holding
attr dim_flangeheater_history room Dimplex
attr dim_flangeheater_history updateInterval 01:00:00
</pre>
==== Logfile Historie ====
Anlegen eines monatlichen Logfile für die Historischen Daten:
<pre>
define filelog_dim_history_month FileLog ./log/filelog_dim_history_month-%m.log dim_.*._history.*
attr filelog_dim_history_month room Dimplex
</pre>

==== Wärmemengen ====
Laut Definition aus dem [http://www.dimplex.de/wiki Dimplex-Wiki] werden die Wärmemengen für Heizen, Warmwasser und Schwimmbad aus 3 Register-Adressen zusammengesetzt. Im Nachfolgenden Code-Beispiel wird dies entsprechend dargestellt. Dabei wird jeweils im ersten Register ein neues userReading mit der Darstellung der Gesamtwärmemenge angelegt.

Wärmemenge Heizen definieren:
<pre>
define dim_heating1_thermalenergy ModbusRegister 0 5096
attr dim_heating1_thermalenergy IODev HeatPumpServer
attr dim_heating1_thermalenergy event-on-change-reading .*
attr dim_heating1_thermalenergy plcDataType INT
attr dim_heating1_thermalenergy registerType Holding
attr dim_heating1_thermalenergy room Dimplex
attr dim_heating1_thermalenergy updateInterval 00:15:00
attr dim_heating1_thermalenergy userReadings heatingthermalenergy {\
((ReadingsVal("dim_heating3_thermalenergy","state",0)*100000000)+\
(ReadingsVal("dim_heating2_thermalenergy","state",0)*10000)+\
(ReadingsVal("dim_heating1_thermalenergy","state",0)))}

define dim_heating2_thermalenergy ModbusRegister 0 5097
attr dim_heating2_thermalenergy IODev HeatPumpServer
attr dim_heating2_thermalenergy event-on-change-reading .*
attr dim_heating2_thermalenergy plcDataType INT
attr dim_heating2_thermalenergy registerType Holding
attr dim_heating2_thermalenergy room Dimplex
attr dim_heating2_thermalenergy updateInterval 00:15:00

define dim_heating3_thermalenergy ModbusRegister 0 5098
attr dim_heating3_thermalenergy IODev HeatPumpServer
attr dim_heating3_thermalenergy event-on-change-reading .*
attr dim_heating3_thermalenergy plcDataType INT
attr dim_heating3_thermalenergy registerType Holding
attr dim_heating3_thermalenergy room Dimplex
attr dim_heating3_thermalenergy updateInterval 00:15:00
</pre>Wärmemenge Warmwasser definieren:<pre>
define dim_dhw1_thermalenergy ModbusRegister 0 5099
attr dim_dhw1_thermalenergy IODev HeatPumpServer
attr dim_dhw1_thermalenergy event-on-change-reading .*
attr dim_dhw1_thermalenergy plcDataType INT
attr dim_dhw1_thermalenergy registerType Holding
attr dim_dhw1_thermalenergy room Dimplex
attr dim_dhw1_thermalenergy updateInterval 00:15:00
attr dim_dhw1_thermalenergy userReadings dhwthermalenergy {\
((ReadingsVal("dim_dhw3_thermalenergy","state",0)*100000000)+\
(ReadingsVal("dim_dhw2_thermalenergy","state",0)*10000)+\
(ReadingsVal("dim_dhw1_thermalenergy","state",0)))}

define dim_dhw2_thermalenergy ModbusRegister 0 5100
attr dim_dhw2_thermalenergy IODev HeatPumpServer
attr dim_dhw2_thermalenergy event-on-change-reading .*
attr dim_dhw2_thermalenergy plcDataType INT
attr dim_dhw2_thermalenergy registerType Holding
attr dim_dhw2_thermalenergy room Dimplex
attr dim_dhw2_thermalenergy updateInterval 00:15:00

define dim_dhw3_thermalenergy ModbusRegister 0 5101
attr dim_dhw3_thermalenergy IODev HeatPumpServer
attr dim_dhw3_thermalenergy event-on-change-reading .*
attr dim_dhw3_thermalenergy plcDataType INT
attr dim_dhw3_thermalenergy registerType Holding
attr dim_dhw3_thermalenergy room Dimplex
attr dim_dhw3_thermalenergy updateInterval 00:15:00
</pre>
==== Umweltenergie ====
Als Umweltenergie wird die zugeführte Kälteenergie aus der Umwelt (Luft/Erdreich) bezeichnet. Das Auslesen dieser Werte über die Schnittstelle ist erst ab einem neueren Softwarestand möglich. Die Differenz der gesamten Wärmemenge und der Umweltenergie entspricht in etwa der Energie des Verdichters.

Umweltenergie/entzogene Kälteenergie definieren:
<pre>
define dim_environment1_energy ModbusRegister 0 5127
attr dim_environment1_energy IODev HeatPumpServer
attr dim_environment1_energy event-on-change-reading .*
attr dim_environment1_energy plcDataType INT
attr dim_environment1_energy registerType Holding
attr dim_environment1_energy room Dimplex
attr dim_environment1_energy updateInterval 00:15:00
attr dim_environment1_energy userReadings environmentenergy {\
((ReadingsVal("dim_environment3_energy","state",0)*100000000)+\
(ReadingsVal("dim_environment2_energy","state",0)*10000)+\
(ReadingsVal("dim_environment1_energy","state",0)))}

define dim_environment2_energy ModbusRegister 0 5128
attr dim_environment2_energy IODev HeatPumpServer
attr dim_environment2_energy event-on-change-reading .*
attr dim_environment2_energy plcDataType INT
attr dim_environment2_energy registerType Holding
attr dim_environment2_energy room Dimplex
attr dim_environment2_energy updateInterval 00:15:00

define dim_environment3_energy ModbusRegister 0 5129
attr dim_environment3_energy IODev HeatPumpServer
attr dim_environment3_energy event-on-change-reading .*
attr dim_environment3_energy plcDataType INT
attr dim_environment3_energy registerType Holding
attr dim_environment3_energy room Dimplex
attr dim_environment3_energy updateInterval 00:15:00
</pre>

==== Logfile Wärmemengen ====
Anlegen eines jährlichen Logfile der Wärmemengen.
<pre>
define filelog_dim_thermalenergy_year FileLog ./log/filelog_dim_thermalenergy_year-%y.log dim_heating1_thermalenergy:heatingthermalenergy:.*|dim_heating1_thermalenergy:heatingthermalenergy:.*
attr filelog_dim_thermalenergy_year room Dimplex
</pre>

=== Meldungen ===
[[Bild:dimplex_rh_status_heatpump.jpg|thumb|right|Beispiel Meldungen]]
Eine sinnvolle Anzeige sind die Meldungen (Status, Sperre, Störung) der Wärmepumpe. Im nachfolgenden Beispiel werden die Meldungen mit dem Hilfsmodul [[readingsHistory]] dargestellt. Die Definitionen der Meldungen beziehen sich auf die im [http://www.dimplex.de/wiki Dimplex-Wiki] beschriebene L-Software. Bei abweichenden Softwareständen müssen die Register sowie die Texte angepasst werden.

Register Statusmeldung definieren:

<pre>
define dim_status_heatpump ModbusRegister 0 103
attr dim_status_heatpump IODev HeatPumpServer
attr dim_status_heatpump event-on-change-reading .*
attr dim_status_heatpump plcDataType INT
attr dim_status_heatpump registerType Holding
attr dim_status_heatpump room Dimplex
attr dim_status_heatpump updateInterval 00:00:10
attr dim_status_heatpump userReadings Status {\
((ReadingsVal($name,"state","") == 1) ? "Aus":\
(ReadingsVal($name,"state","") == 4) ? "Warmwasser":\
(ReadingsVal($name,"state","") == 10) ? "Abtauen":\
(ReadingsVal($name,"state","") == 11) ? "Durchflussüberwachnung":"")}

</pre>Register Sperrmeldunge definieren:<pre>
define dim_block_heatpump ModbusRegister 0 104
attr dim_block_heatpump IODev HeatPumpServer
attr dim_block_heatpump event-on-change-reading .*
attr dim_block_heatpump plcDataType INT
attr dim_block_heatpump registerType Holding
attr dim_block_heatpump room Dimplex
attr dim_block_heatpump updateInterval 00:00:10
attr dim_block_heatpump userReadings Sperre {\
((ReadingsVal($name,"state","") == 0) ? "":\
(ReadingsVal($name,"state","") == 7) ? "Systemkontrolle":\
(ReadingsVal($name,"state","") == 9) ? "Pumpenvorlauf":\
(ReadingsVal($name,"state","") == 10) ? "Mindeststandzeit":\
(ReadingsVal($name,"state","") == 11) ? "Netzbelastung":\
(ReadingsVal($name,"state","") == 12) ? "Schaltspielsperre":\
(ReadingsVal($name,"state","") == 15) ? "EVU":"")}
</pre>Register Störmeldungen definieren:<pre>
define dim_fault_heatpump ModbusRegister 0 105
attr dim_fault_heatpump IODev HeatPumpServer
attr dim_fault_heatpump event-on-change-reading .*
attr dim_fault_heatpump plcDataType INT
attr dim_fault_heatpump registerType Holding
attr dim_fault_heatpump room Dimplex
attr dim_fault_heatpump updateInterval 00:01:00
attr dim_fault_heatpump userReadings Störung {\
((ReadingsVal($name,"state","") == 0) ? "":\
(ReadingsVal($name,"state","") == 6) ? "Elektronisches Ex.Ventil":\
(ReadingsVal($name,"state","") == 15) ? "Sensorik":\
(ReadingsVal($name,"state","") == 19) ? "!Primärkreis":\
(ReadingsVal($name,"state","") == 22) ? "!Warmwasser":\
(ReadingsVal($name,"state","") == 23) ? "!Last Verdichter":\
(ReadingsVal($name,"state","") == 24) ? "!Codierung":\
(ReadingsVal($name,"state","") == 25) ? "!Niederdruck":\
(ReadingsVal($name,"state","") == 26) ? "!Frostschutz":\
(ReadingsVal($name,"state","") == 29) ? "!Temperatur Differenz":\
(ReadingsVal($name,"state","") == 31) ? "!Durchfluss":"")}
</pre>
==== Anzeige der Meldungen ====
readingsHistory definieren:<pre>
define rh_dim_status_heatpump readingsHistory dim_status_heatpump:Status dim_block_heatpump:Sperre dim_fault_heatpump:Störung
attr rh_dim_status_heatpump alias Status
attr rh_dim_status_heatpump mapping {'dim_status_heatpump' => '', 'dim_block_heatpump' => '', 'dim_fault_heatpump' => ''}
attr rh_dim_status_heatpump nohtml 1
attr rh_dim_status_heatpump room Dimplex
attr rh_dim_status_heatpump rows 20
attr rh_dim_status_heatpump timestampFormat %b %a %R
</pre>

== Plotbeispiel ==
=== Temperaturen ===
<pre>
# Created by FHEM/98_SVG.pm, 2015-05-11 21:40:00
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 ytics y2tics
set ylabel ""
set y2label "Temperatur (°C)"

#filelog_dim_temperature_week 4:dim_outdoor_temperature.*::
#filelog_dim_temperature_week 4:dim_room_temperature.*::
#filelog_dim_temperature_week 4:dim_return_temperature.*::
#filelog_dim_temperature_week 4:dim_returnset_temperature.*::
#filelog_dim_temperature_week 4:dim_dhw_temperature.*::
#filelog_dim_temperature_week 4:dim_flow_temperature.*::
#filelog_dim_temperature_week 4:dim_brine_temperature.*::

plot "<IN>" using 1:2 axes x1y2 title 'AT' ls l7 lw 1 with lines,\
"<IN>" using 1:2 axes x1y2 title 'RT' ls l1 lw 1 with lines,\
"<IN>" using 1:2 axes x1y2 title 'RL' ls l2 lw 1 with lines,\
"<IN>" using 1:2 axes x1y2 title 'RLS' ls l3 lw 1 with lines,\
"<IN>" using 1:2 axes x1y2 title 'WWT' ls l4 lw 1 with lines,\
"<IN>" using 1:2 axes x1y2 title 'VLT' ls l0 lw 1 with lines,\
"<IN>" using 1:2 axes x1y2 title 'SOL' ls l6 lw 1 with lines
</pre>

=== Ausgänge ===
<pre>
# Created by FHEM/98_SVG.pm, 2015-05-11 21:45:00
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 ''
set ytics ("An" -1, "Aus" -2, "An" -5, "Aus" -6, "An" -9, "Aus" -10, "An" -13, "Aus" -14)
set y2tics ("An" 1, "Aus" 0, "An" -3, "Aus" -4, "An" -7, "Aus" -8, "An" -11, "Aus" -12)
set grid
set ylabel ""
set y2label "Digital"
set yrange [-16:2]
set y2range [-16:2]

#FileLog 3:dim_compressor_output.*::$fld[2]=~"on"?1:0
#FileLog 3:dim_ventilator_output.*::$fld[2]=~"on"?-1:-2
#FileLog 3:dim_2heatgenerator_output.*::$fld[2]=~"on"?-3:-4
#FileLog 3:dim_circulationpump_output.*::$fld[2]=~"on"?-5:-6
#FileLog 3:dim_dhwpump_output.*::$fld[2]=~"on"?-7:-8
#FileLog 3:dim_auxiliarypump_output.*::$fld[2]=~"on"?-9:-10
#FileLog 3:dim_solarpump_output.*::$fld[2]=~"on"?-11:-12
#FileLog 3:dim_flangeheater_output.*::$fld[2]=~"on"?-13:-14

plot "<IN>" using 1:2 axes x1y2 title 'Vd' ls l7 lw 1.5 with steps,\
"<IN>" using 1:2 axes x1y2 title 'Ve' ls l6 lw 1.5 with steps,\
"<IN>" using 1:2 axes x1y2 title '2.We' ls l5 lw 1.5 with steps,\
"<IN>" using 1:2 axes x1y2 title 'Hub' ls l4 lw 1.5 with steps,\
"<IN>" using 1:2 axes x1y2 title 'Wup' ls l3 lw 1 with steps,\
"<IN>" using 1:2 axes x1y2 title 'Zup' ls l0 lw 1.5 with steps,\
"<IN>" using 1:2 axes x1y2 title 'Sol' ls l2 lw 1.5 with steps,\
"<IN>" using 1:2 axes x1y2 title 'Flh' ls l7 lw 1.5 with steps
</pre>

[[Bild:dimplex_hp_graph.jpg|thumb|right|Plotbeispiel]]
Im nebenstehenden Plotbeispiel werde die Temperaturen (Analogwerte) sowie die Ausgänge (Digitalwerte) dargestellt. Im einzelnen sind die Kurven für die

* Aussen- (AT)
* Raum- (RT)
* Rücklauf- (RL)
* Rücklaufsoll- (RLS)
* Warmwasser- (WWT) und
* Vorlauftemperatur (VLT)

sowie die Ausgänge für

* Verdichter 1 (Vd)
* Ventilator (Ve)
* 2.Wärmeerzeuger (2We)
* Heizungsumwälzpumpe (Hup)
* Warmwasserumwälzpumpe (Wup) und
* Zusatzumwälzpumpe (Zup)

enthalten.

= Kontakt =
Weitere Fragen, Wünsche und Anregungen bitte im entsprechenden {{Link2Forum|Topic=33086|LinkText=Forenthread zum Wiki-Artikel "Dimplex Wärmepumpenmanager"}} zur Diskussion stellen.

Offene Punkte:
- Darstellung der Werte in einer readingsGroup
- Zugriff auf Zeitfunktionen mit Lesen und Schreiben

[[Kategorie:HOWTOS]]
[[Kategorie:Heizungssteuerung]]
[[Kategorie:Other Components]]

Dimplex Wärmepumpenmanager

2025-03-30T16:23:47Z

TomLee: ?

Mit der NWPM-Erweiterung ist es möglich, den Dimplex Wärmepumpenmanager in ein Hausnetzwerk einzubinden. Durch die Einbindung der NWPM-Erweiterung ist es ebenfalls möglich, die zur Verfügung gestellten Werte vom Wärmepumpenmanager mittels ModbusTCP in FHEM zu übernehmen, anzuzeigen und grafisch darzustellen.

== Voraussetzung ==
Die Anbindung des Dimplex Wärmepumpenmanager an FHEM erfolgt mittels NWPM-Erweiterung und der aktuellen FHEM Installation. Weiterhin werden die zur Verfügung stehenden Module:

* 36_ModbusTCPServer.pm
* 37_ModbusCoil.pm
* 37_ModbusRegister.pm

genutzt. Getestet wurde der Zugriff auf einem BeagleBone Black mit der [[BeagleBone Black|hier beschriebenen]] Debian Installation.

== Installation ==
Die oben aufgeführten Module sind notwendig und müssen nachinstalliert werden. Zum Zeitpunkt der Erstellung dieser Dokumentation (31.1.2015) sind diese noch nicht offiziell in FHEM enthalten und werden auch nicht mittels Update verteilt. Die Module werden mit dem Befehl:
<pre>
update all https://raw.githubusercontent.com/ChrisD70/FHEM-Modules/master/autoupdate/mb/controls_modbus.txt
</pre>
über die FHEM Befehlszeile installiert und anschließend
<pre>
reload 36_ModbusTCPServer.pm
reload 37_ModbusCoil.pm
reload 37_ModbusRegister.pm
</pre>
mit einem Reload geladen.
== Benutzung ==
=== Anlegen der ModbusTCPServer Verbindung ===
Wie im nachfolgenden angegeben muss zunächst eine ModbusTCPServer Verbindung hergestellt werden. Die angegebene IP-Adresse muss durch die IP-Adresse der Wärmepumpe ersetzt werden.
<pre>
########################################################
## ModbusTCPServer definieren
########################################################
define HeatPumpServer ModbusTCPServer 192.168.1.150
attr HeatPumpServer verbose 2
</pre>
Ein erfolgreicher Verbindungsaufbau wird mit einem „ok“ im State gekennzeichnet.

=== Modbus-Register/Coil Adressen definieren ===
Im nachfolgendem Beispiel wird anhand der Außentemperatur die Adressdefinition erklärt.
<pre>
define dim_outdoor_temperature ModbusRegister 0 1
attr dim_outdoor_temperature IODev HeatPumpServer
attr dim_outdoor_temperature conversion 0.1:0
attr dim_outdoor_temperature event-min-interval .*:900
attr dim_outdoor_temperature event-on-change-reading .*
attr dim_outdoor_temperature plcDataType INT
attr dim_outdoor_temperature registerType Holding
attr dim_outdoor_temperature room Dimplex
attr dim_outdoor_temperature stateAlias temperature
attr dim_outdoor_temperature stateFormat {sprintf("%0.1f", ReadingsVal($name,"state",0))}
attr dim_outdoor_temperature updateInterval 00:10:00
</pre>
Erklärung:
{| class="wikitable"
|+ Erläuterungen zur Adressdefinition
|-
! Attribut !! Erläuterungen
|-
| ModbusRegister 0 1 || 0 Device Adresse, in der Regel bei ModbusTCP immer 0
|-
| ModbusRegister 0 1 || 1 Register Adresse, wird unter www.dimplex.de/wiki → ModbusTCP → Spalten IP zur Verfügung gestellt
|-
| IODev || Verwendeter und zuvor angelegter ModbusTCPServer
|-
| conversion || eine gegebenenfalls notwendige Konvertierung des übermittelten Values
|-
| PlcDataType || Ermögliche automatische Interpretation der ankommenden Daten
|-
| stateAlias || es wird ein zusätzliches Reading erzeugt, um zum Beispiel das Statistic-Modul nutzen zu können, stateAlias ist eine echte Kopie von "state"
|-
| updateInterval || Intervall des Abfragezyklus (z.B. 00:10:00 Minuten)
|-
|}

=== Betriebsdaten ===
Vorschlag der Namensvergabe für die Betriebsdaten. Eine sinnvolle Namensvergabe erleichtert später das Anlegen weiterer Definitionen von zum Beispiel Logfiles, Statistiken oder auch [[readingsGroup]].
{| class="wikitable"
|-
| dim_outdoor_temperature || Außentemperatur
|-
| dim_flow_temperature || Vorlauftemperatur
|-
| dim_return_temperature || Rücklauftemperatur
|-
| dim_returnset_temperature || Rücklaufsolltemperatur
|-
| dim_room_temperature || Raumtemperatur
|-
| dim_dhw_temperature || Warmwassertemperatur
|-
| dim_dhwset_temperature || Warmwassersolltemperatur
|-
| dim_brine_temperature || Soletemperatur
|-
| dim_high_pressure || Hochdruck
|-
| dim_low_pressure || Niederdruck
|}
Register Warmwassertemperatur definieren:<pre>
define dim_dhw_temperature ModbusRegister 0 3
attr dim_dhw_temperature IODev HeatPumpServer
attr dim_dhw_temperature conversion 0.1:0
attr dim_dhw_temperature event-min-interval .*:900
attr dim_dhw_temperature event-on-change-reading .*
attr dim_dhw_temperature plcDataType INT
attr dim_dhw_temperature registerType Holding
attr dim_dhw_temperature room Dimplex
attr dim_dhw_temperature stateAlias temperature
attr dim_dhw_temperature stateFormat {sprintf("%0.1f", ReadingsVal($name,"state",0))}
attr dim_dhw_temperature updateInterval 00:01:00
</pre>Register Vorlauftemperatur definieren:<pre>
define dim_flow_temperature ModbusRegister 0 5
attr dim_flow_temperature IODev HeatPumpServer
attr dim_flow_temperature conversion 0.1:0
attr dim_flow_temperature event-min-interval .*:900
attr dim_flow_temperature event-on-change-reading .*
attr dim_flow_temperature plcDataType INT
attr dim_flow_temperature registerType Holding
attr dim_flow_temperature room Dimplex
attr dim_flow_temperature stateAlias temperature
attr dim_flow_temperature stateFormat {sprintf("%0.1f", ReadingsVal($name,"state",0))}
attr dim_flow_temperature updateInterval 00:01:00
</pre>Register Rücklauftemperatur definieren:<pre>
define dim_return_temperature ModbusRegister 0 2
attr dim_return_temperature IODev HeatPumpServer
attr dim_return_temperature conversion 0.1:0
attr dim_return_temperature event-min-interval .*:900
attr dim_return_temperature event-on-change-reading .*
attr dim_return_temperature plcDataType INT
attr dim_return_temperature registerType Holding
attr dim_return_temperature room Dimplex
attr dim_return_temperature stateAlias temperature
attr dim_return_temperature stateFormat {sprintf("%0.1f", ReadingsVal($name,"state",0))}
attr dim_return_temperature updateInterval 00:01:00
</pre>Register Rücklaufsolltemperatur definieren:<pre>
define dim_returnset_temperature ModbusRegister 0 53
attr dim_returnset_temperature IODev HeatPumpServer
attr dim_returnset_temperature conversion 0.1:0
attr dim_returnset_temperature event-min-interval .*:900
attr dim_returnset_temperature event-on-change-reading .*
attr dim_returnset_temperature plcDataType INT
attr dim_returnset_temperature registerType Holding
attr dim_returnset_temperature room Dimplex
attr dim_returnset_temperature stateAlias temperature
attr dim_returnset_temperature stateFormat {sprintf("%0.1f", ReadingsVal($name,"state",0))}
attr dim_returnset_temperature updateInterval 00:05:00
</pre>

==== Logfile Betriebsdaten ====
Anlegen eines täglichen Logfile der Betriebsdaten.
<pre>
define filelog_dim_temperature FileLog ./log/filelog_dim_temperature-%W-%d.log dim_.*._temperature:temperature:.*|dim_.*._pressure:pressure:.*
attr filelog_dim_temperature room Dimplex
</pre>

==== Statistiken ====
Folgender Code legt die Statistiken der Betriebsdaten an
<pre>
define dim_statistics statistics dim_.*._temperature|dim_.*._pressure
attr dim_statistics dayChangeTime 1
attr dim_statistics deltaReadings temperature,pressure
attr dim_statistics minAvgMaxReadings temperature,pressure
attr dim_statistics room Dimplex
attr dim_statistics tendencyReadings temperature,pressure
</pre>

=== Zustände ===
Vorschlag der Namensvergabe für die Zustände. Eine sinnvolle Namensvergabe erleichtert später das Anlegen weiterer Definitionen von zum Beispiel Logfiles, Statistiken oder auch [[readingsGroup]].
{| class="wikitable"
|-
| dim_compressor_output || Verdichter
|-
| dim_ventilator_output || Ventilator
|-
| dim_brinepump_ output || Solepumpe
|-
| dim_circulationpump_output || Heizungsumwälzpumpe M13
|-
| dim_2heatgenerator_output || 2.Wärmeerzeuger
|-
| dim_dhwpump_output || Warmwasserpumpe M18
|-
| dim_auxiliarypump_output || Zusatzpumpe M16
|-
| dim_flangeheater_output || Flanschheizung
|}
Coil Verdichter und passenden HourCounter für Verdichter definieren:<pre>
define dim_compressor_output ModbusCoil 0 41
attr dim_compressor_output IODev HeatPumpServer
attr dim_compressor_output disableRegisterMapping 1
attr dim_compressor_output event-min-interval .*:900
attr dim_compressor_output event-on-change-reading .*
attr dim_compressor_output room Dimplex
attr dim_compressor_output source Coil
attr dim_compressor_output updateInterval 00:01:00

define hourcounter_compressor_output HourCounter dim_compressor_output:on dim_compressor_output:off
attr hourcounter_compressor_output event-min-interval tick.*:0,.*:3600
attr hourcounter_compressor_output event-on-change-reading .*
</pre>Coil Ventilator definieren und passenden HourCounter für Ventilator definieren:<pre>
define dim_ventilator_output ModbusCoil 0 43
attr dim_ventilator_output IODev HeatPumpServer
attr dim_ventilator_output disableRegisterMapping 1
attr dim_ventilator_output event-min-interval .*:900
attr dim_ventilator_output event-on-change-reading .*
attr dim_ventilator_output room Dimplex
attr dim_ventilator_output source Coil
attr dim_ventilator_output updateInterval 00:01:00

define hourcounter_ventilator_output HourCounter dim_ventilator_output:on dim_ventilator_output:off
attr hourcounter_ventilator_output event-min-interval tick.*:0,.*:3600
attr hourcounter_ventilator_output event-on-change-reading .*
</pre>Coil 2.Wärmeerzeuger definieren und passenden HourCounter für 2.Wärmeerzeuger definieren:<pre>
define dim_2heatgenerator_output ModbusCoil 0 44
attr dim_2heatgenerator_output IODev HeatPumpServer
attr dim_2heatgenerator_output disableRegisterMapping 1
attr dim_2heatgenerator_output event-min-interval .*:900
attr dim_2heatgenerator_output event-on-change-reading .*
attr dim_2heatgenerator_output room Dimplex
attr dim_2heatgenerator_output source Coil
attr dim_2heatgenerator_output updateInterval 00:01:00

define hourcounter_2heatgenerator_output HourCounter dim_2heatgenerator_output:on dim_2heatgenerator_output:off
attr hourcounter_2heatgenerator_output event-min-interval tick.*:0,.*:3600
attr hourcounter_2heatgenerator_output event-on-change-reading .*
</pre>Coil Heizungsumwälzpumpe M13 definieren und passenden HourCounter für Heizungsumwälzpumpe M13 definieren:<pre>
define dim_circulationpump_output ModbusCoil 0 45
attr dim_circulationpump_output IODev HeatPumpServer
attr dim_circulationpump_output disableRegisterMapping 1
attr dim_circulationpump_output event-min-interval .*:900
attr dim_circulationpump_output event-on-change-reading .*
attr dim_circulationpump_output room Dimplex
attr dim_circulationpump_output source Coil
attr dim_circulationpump_output updateInterval 00:01:00

define hourcounter_circulationpump_output HourCounter dim_circulationpump_output:on dim_circulationpump_output:off
attr hourcounter_circulationpump_output event-min-interval tick.*:0,.*:3600
attr hourcounter_circulationpump_output event-on-change-reading .*
</pre>Coil Warmwasserpumpe M18 definieren und passenden HourCounter für Warmwasserpumpe M18 definieren:<pre>
define dim_dhwpump_output ModbusCoil 0 46
attr dim_dhwpump_output IODev HeatPumpServer
attr dim_dhwpump_output disableRegisterMapping 1
attr dim_dhwpump_output event-min-interval .*:900
attr dim_dhwpump_output event-on-change-reading .*
attr dim_dhwpump_output room Dimplex
attr dim_dhwpump_output source Coil
attr dim_dhwpump_output updateInterval 00:01:00

define hourcounter_dhwpump_output HourCounter dim_dhwpump_output:on dim_dhwpump_output:off
attr hourcounter_dhwpump_output event-min-interval tick.*:0,.*:3600
attr hourcounter_dhwpump_output event-on-change-reading .*
</pre>Coil Zusatzpumpe M16 definieren und Passenden HourCounter für Zusatzpumpe M16 definieren:<pre>
define dim_auxiliarypump_output ModbusCoil 0 49
attr dim_auxiliarypump_output IODev HeatPumpServer
attr dim_auxiliarypump_output disableRegisterMapping 1
attr dim_auxiliarypump_output event-min-interval .*:900
attr dim_auxiliarypump_output event-on-change-reading .*
attr dim_auxiliarypump_output room Dimplex
attr dim_auxiliarypump_output source Coil
attr dim_auxiliarypump_output updateInterval 00:01:00

define hourcounter_auxiliarypump_output HourCounter dim_auxiliarypump_output:on dim_auxiliarypump_output:off
attr hourcounter_auxiliarypump_output event-min-interval tick.*:0,.*:3600
attr hourcounter_auxiliarypump_output event-on-change-reading .*
</pre>Coil Flanschheizung definieren und passenden HourCounter für Flanschheizung M16 definieren:<pre>
define dim_flangeheater_output ModbusCoil 0 50
attr dim_flangeheater_output IODev HeatPumpServer
attr dim_flangeheater_output disableRegisterMapping 1
attr dim_flangeheater_output event-min-interval .*:900
attr dim_flangeheater_output event-on-change-reading .*
attr dim_flangeheater_output room Dimplex
attr dim_flangeheater_output source Coil
attr dim_flangeheater_output updateInterval 00:01:00

define hourcounter_flangeheater_output HourCounter dim_flangeheater_output:on dim_flangeheater_output:off
attr hourcounter_flangeheater_output event-min-interval tick.*:0,.*:3600
attr hourcounter_flangeheater_output event-on-change-reading .*
</pre>

==== Logfile Zustände ====
Anlegen eines wöchentlichen Logfile der Zustände:
<pre>
define filelog_dim_output_week FileLog ./log/filelog_dim_output_week-%W.log dim_.*._output.*
attr filelog_dim_output_week room Dimplex
</pre>

=== Historie ===
Vorschlag der Namensvergabe für die Historie. Eine sinnvolle Namensvergabe erleichtert später das Anlegen weiterer Definitionen von zum Beispiel Logfiles, Statistiken oder auch [[readingsGroup]].
{| class="wikitable"
|-
| dim_compressor_history || Verdichter
|-
| dim_ventilator_history || Ventilator
|-
| dim_brinepump_history || Solepumpe
|-
| dim_circulationpump_history || Heizungsumwälzpumpe M13
|-
| dim_2heatgenerator_history || 2.Wärmeerzeuger
|-
| dim_dhwpump_history || Warmwasserpumpe M18
|-
| dim_auxiliarypump_history || Zusatzpumpe M16
|-
| dim_flangeheater_history || Flanschheizung
|}
Register Historie Verdichter definieren:<pre>
define dim_compressor_history ModbusRegister 0 72
attr dim_compressor_history IODev HeatPumpServer
attr dim_compressor_history alignUpdateInterval 00:01:00
attr dim_compressor_history event-on-change-reading .*
attr dim_compressor_history plcDataType INT
attr dim_compressor_history registerType Holding
attr dim_compressor_history room Dimplex
attr dim_compressor_history updateInterval 01:00:00
</pre>Register Historie Ventilator definieren:<pre>
define dim_ventilator_history ModbusRegister 0 74
attr dim_ventilator_history IODev HeatPumpServer
attr dim_ventilator_history alignUpdateInterval 00:01:00
attr dim_ventilator_history event-on-change-reading .*
attr dim_ventilator_history plcDataType INT
attr dim_ventilator_history registerType Holding
attr dim_ventilator_history room Dimplex
attr dim_ventilator_history updateInterval 01:00:00
</pre>Register Historie 2.Wärmeerzeuger definieren:<pre>
define dim_2heatgenerator_history ModbusRegister 0 75
attr dim_2heatgenerator_history IODev HeatPumpServer
attr dim_2heatgenerator_history alignUpdateInterval 00:01:00
attr dim_2heatgenerator_history event-on-change-reading .*
attr dim_2heatgenerator_history plcDataType INT
attr dim_2heatgenerator_history registerType Holding
attr dim_2heatgenerator_history room Dimplex
attr dim_2heatgenerator_history updateInterval 01:00:00
</pre>Register Historie Heizungsumwälzpumpe M13 definieren:<pre>
define dim_circulationpump_history ModbusRegister 0 76
attr dim_circulationpump_history IODev HeatPumpServer
attr dim_circulationpump_history alignUpdateInterval 00:01:00
attr dim_circulationpump_history event-on-change-reading .*
attr dim_circulationpump_history plcDataType INT
attr dim_circulationpump_history registerType Holding
attr dim_circulationpump_history room Dimplex
attr dim_circulationpump_history updateInterval 01:00:00
</pre>Register Historie Warmwasserpumpe M18 definieren:<pre>
define dim_dhwpump_history ModbusRegister 0 77
attr dim_dhwpump_history IODev HeatPumpServer
attr dim_dhwpump_history alignUpdateInterval 00:01:00
attr dim_dhwpump_history event-on-change-reading .*
attr dim_dhwpump_history plcDataType INT
attr dim_dhwpump_history registerType Holding
attr dim_dhwpump_history room Dimplex
attr dim_dhwpump_history updateInterval 01:00:00
</pre>Register Historie Flanschheizung definieren:<pre>
define dim_flangeheater_history ModbusRegister 0 78
attr dim_flangeheater_history IODev HeatPumpServer
attr dim_flangeheater_history alignUpdateInterval 00:01:00
attr dim_flangeheater_history event-on-change-reading .*
attr dim_flangeheater_history plcDataType INT
attr dim_flangeheater_history registerType Holding
attr dim_flangeheater_history room Dimplex
attr dim_flangeheater_history updateInterval 01:00:00
</pre>
==== Logfile Historie ====
Anlegen eines monatlichen Logfile für die Historischen Daten:
<pre>
define filelog_dim_history_month FileLog ./log/filelog_dim_history_month-%m.log dim_.*._history.*
attr filelog_dim_history_month room Dimplex
</pre>

==== Wärmemengen ====
Laut Definition aus dem [http://www.dimplex.de/wiki Dimplex-Wiki] werden die Wärmemengen für Heizen, Warmwasser und Schwimmbad aus 3 Register-Adressen zusammengesetzt. Im Nachfolgenden Code-Beispiel wird dies entsprechend dargestellt. Dabei wird jeweils im ersten Register ein neues userReading mit der Darstellung der Gesamtwärmemenge angelegt.

Wärmemenge Heizen definieren:
<pre>
define dim_heating1_thermalenergy ModbusRegister 0 5096
attr dim_heating1_thermalenergy IODev HeatPumpServer
attr dim_heating1_thermalenergy event-on-change-reading .*
attr dim_heating1_thermalenergy plcDataType INT
attr dim_heating1_thermalenergy registerType Holding
attr dim_heating1_thermalenergy room Dimplex
attr dim_heating1_thermalenergy updateInterval 00:15:00
attr dim_heating1_thermalenergy userReadings heatingthermalenergy {\
((ReadingsVal("dim_heating3_thermalenergy","state",0)*100000000)+\
(ReadingsVal("dim_heating2_thermalenergy","state",0)*10000)+\
(ReadingsVal("dim_heating1_thermalenergy","state",0)))}

define dim_heating2_thermalenergy ModbusRegister 0 5097
attr dim_heating2_thermalenergy IODev HeatPumpServer
attr dim_heating2_thermalenergy event-on-change-reading .*
attr dim_heating2_thermalenergy plcDataType INT
attr dim_heating2_thermalenergy registerType Holding
attr dim_heating2_thermalenergy room Dimplex
attr dim_heating2_thermalenergy updateInterval 00:15:00

define dim_heating3_thermalenergy ModbusRegister 0 5098
attr dim_heating3_thermalenergy IODev HeatPumpServer
attr dim_heating3_thermalenergy event-on-change-reading .*
attr dim_heating3_thermalenergy plcDataType INT
attr dim_heating3_thermalenergy registerType Holding
attr dim_heating3_thermalenergy room Dimplex
attr dim_heating3_thermalenergy updateInterval 00:15:00
</pre>Wärmemenge Warmwasser definieren:<pre>
define dim_dhw1_thermalenergy ModbusRegister 0 5099
attr dim_dhw1_thermalenergy IODev HeatPumpServer
attr dim_dhw1_thermalenergy event-on-change-reading .*
attr dim_dhw1_thermalenergy plcDataType INT
attr dim_dhw1_thermalenergy registerType Holding
attr dim_dhw1_thermalenergy room Dimplex
attr dim_dhw1_thermalenergy updateInterval 00:15:00
attr dim_dhw1_thermalenergy userReadings dhwthermalenergy {\
((ReadingsVal("dim_dhw3_thermalenergy","state",0)*100000000)+\
(ReadingsVal("dim_dhw2_thermalenergy","state",0)*10000)+\
(ReadingsVal("dim_dhw1_thermalenergy","state",0)))}

define dim_dhw2_thermalenergy ModbusRegister 0 5100
attr dim_dhw2_thermalenergy IODev HeatPumpServer
attr dim_dhw2_thermalenergy event-on-change-reading .*
attr dim_dhw2_thermalenergy plcDataType INT
attr dim_dhw2_thermalenergy registerType Holding
attr dim_dhw2_thermalenergy room Dimplex
attr dim_dhw2_thermalenergy updateInterval 00:15:00

define dim_dhw3_thermalenergy ModbusRegister 0 5101
attr dim_dhw3_thermalenergy IODev HeatPumpServer
attr dim_dhw3_thermalenergy event-on-change-reading .*
attr dim_dhw3_thermalenergy plcDataType INT
attr dim_dhw3_thermalenergy registerType Holding
attr dim_dhw3_thermalenergy room Dimplex
attr dim_dhw3_thermalenergy updateInterval 00:15:00
</pre>
==== Umweltenergie ====
Als Umweltenergie wird die zugeführte Kälteenergie aus der Umwelt (Luft/Erdreich) bezeichnet. Das Auslesen dieser Werte über die Schnittstelle ist erst ab einem neueren Softwarestand möglich. Die Differenz der gesamten Wärmemenge und der Umweltenergie entspricht in etwa der Energie des Verdichters.

Umweltenergie/entzogene Kälteenergie definieren:
<pre>
define dim_environment1_energy ModbusRegister 0 5127
attr dim_environment1_energy IODev HeatPumpServer
attr dim_environment1_energy event-on-change-reading .*
attr dim_environment1_energy plcDataType INT
attr dim_environment1_energy registerType Holding
attr dim_environment1_energy room Dimplex
attr dim_environment1_energy updateInterval 00:15:00
attr dim_environment1_energy userReadings environmentenergy {\
((ReadingsVal("dim_environment3_energy","state",0)*100000000)+\
(ReadingsVal("dim_environment2_energy","state",0)*10000)+\
(ReadingsVal("dim_environment1_energy","state",0)))}

define dim_environment2_energy ModbusRegister 0 5128
attr dim_environment2_energy IODev HeatPumpServer
attr dim_environment2_energy event-on-change-reading .*
attr dim_environment2_energy plcDataType INT
attr dim_environment2_energy registerType Holding
attr dim_environment2_energy room Dimplex
attr dim_environment2_energy updateInterval 00:15:00

define dim_environment3_energy ModbusRegister 0 5129
attr dim_environment3_energy IODev HeatPumpServer
attr dim_environment3_energy event-on-change-reading .*
attr dim_environment3_energy plcDataType INT
attr dim_environment3_energy registerType Holding
attr dim_environment3_energy room Dimplex
attr dim_environment3_energy updateInterval 00:15:00
</pre>

==== Logfile Wärmemengen ====
Anlegen eines jährlichen Logfile der Wärmemengen.
<pre>
define filelog_dim_thermalenergy_year FileLog ./log/filelog_dim_thermalenergy_year-%y.log dim_heating1_thermalenergy:heatingthermalenergy:.*|dim_heating1_thermalenergy:heatingthermalenergy:.*
attr filelog_dim_thermalenergy_year room Dimplex
</pre>

=== Meldungen ===
[[Bild:dimplex_rh_status_heatpump.jpg|thumb|right|Beispiel Meldungen]]
Eine sinnvolle Anzeige sind die Meldungen (Status, Sperre, Störung) der Wärmepumpe. Im nachfolgenden Beispiel werden die Meldungen mit dem Hilfsmodul [[readingsHistory]] dargestellt. Die Definitionen der Meldungen beziehen sich auf die im [http://www.dimplex.de/wiki Dimplex-Wiki] beschriebene L-Software. Bei abweichenden Softwareständen müssen die Register sowie die Texte angepasst werden.

Register Statusmeldung definieren:

<pre>
define dim_status_heatpump ModbusRegister 0 103
attr dim_status_heatpump IODev HeatPumpServer
attr dim_status_heatpump event-on-change-reading .*
attr dim_status_heatpump plcDataType INT
attr dim_status_heatpump registerType Holding
attr dim_status_heatpump room Dimplex
attr dim_status_heatpump updateInterval 00:00:10
attr dim_status_heatpump userReadings Status {\
((ReadingsVal($name,"state","") == 1) ? "Aus":\
(ReadingsVal($name,"state","") == 4) ? "Warmwasser":\
(ReadingsVal($name,"state","") == 10) ? "Abtauen":\
(ReadingsVal($name,"state","") == 11) ? "Durchflussüberwachnung":"")}

</pre>Register Sperrmeldunge definieren:<pre>
define dim_block_heatpump ModbusRegister 0 104
attr dim_block_heatpump IODev HeatPumpServer
attr dim_block_heatpump event-on-change-reading .*
attr dim_block_heatpump plcDataType INT
attr dim_block_heatpump registerType Holding
attr dim_block_heatpump room Dimplex
attr dim_block_heatpump updateInterval 00:00:10
attr dim_block_heatpump userReadings Sperre {\
((ReadingsVal($name,"state","") == 0) ? "":\
(ReadingsVal($name,"state","") == 7) ? "Systemkontrolle":\
(ReadingsVal($name,"state","") == 9) ? "Pumpenvorlauf":\
(ReadingsVal($name,"state","") == 10) ? "Mindeststandzeit":\
(ReadingsVal($name,"state","") == 11) ? "Netzbelastung":\
(ReadingsVal($name,"state","") == 12) ? "Schaltspielsperre":\
(ReadingsVal($name,"state","") == 15) ? "EVU":"")}
</pre>Register Störmeldungen definieren:<pre>
define dim_fault_heatpump ModbusRegister 0 105
attr dim_fault_heatpump IODev HeatPumpServer
attr dim_fault_heatpump event-on-change-reading .*
attr dim_fault_heatpump plcDataType INT
attr dim_fault_heatpump registerType Holding
attr dim_fault_heatpump room Dimplex
attr dim_fault_heatpump updateInterval 00:01:00
attr dim_fault_heatpump userReadings Störung {\
((ReadingsVal($name,"state","") == 0) ? "":\
(ReadingsVal($name,"state","") == 6) ? "Elektronisches Ex.Ventil":\
(ReadingsVal($name,"state","") == 15) ? "Sensorik":\
(ReadingsVal($name,"state","") == 19) ? "!Primärkreis":\
(ReadingsVal($name,"state","") == 22) ? "!Warmwasser":\
(ReadingsVal($name,"state","") == 23) ? "!Last Verdichter":\
(ReadingsVal($name,"state","") == 24) ? "!Codierung":\
(ReadingsVal($name,"state","") == 25) ? "!Niederdruck":\
(ReadingsVal($name,"state","") == 26) ? "!Frostschutz":\
(ReadingsVal($name,"state","") == 29) ? "!Temperatur Differenz":\
(ReadingsVal($name,"state","") == 31) ? "!Durchfluss":"")}
</pre>
==== Anzeige der Meldungen ====
readingsHistory definieren:<pre>
define rh_dim_status_heatpump readingsHistory dim_status_heatpump:Status dim_block_heatpump:Sperre dim_fault_heatpump:Störung
attr rh_dim_status_heatpump alias Status
attr rh_dim_status_heatpump mapping {'dim_status_heatpump' => '', 'dim_block_heatpump' => '', 'dim_fault_heatpump' => ''}
attr rh_dim_status_heatpump nohtml 1
attr rh_dim_status_heatpump room Dimplex
attr rh_dim_status_heatpump rows 20
attr rh_dim_status_heatpump timestampFormat %b %a %R
</pre>

== Plotbeispiel ==
=== Temperaturen ===
<pre>
# Created by FHEM/98_SVG.pm, 2015-05-11 21:40:00
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 ytics y2tics
set ylabel ""
set y2label "Temperatur (°C)"

#filelog_dim_temperature_week 4:dim_outdoor_temperature.*::
#filelog_dim_temperature_week 4:dim_room_temperature.*::
#filelog_dim_temperature_week 4:dim_return_temperature.*::
#filelog_dim_temperature_week 4:dim_returnset_temperature.*::
#filelog_dim_temperature_week 4:dim_dhw_temperature.*::
#filelog_dim_temperature_week 4:dim_flow_temperature.*::
#filelog_dim_temperature_week 4:dim_brine_temperature.*::

plot "<IN>" using 1:2 axes x1y2 title 'AT' ls l7 lw 1 with lines,\
"<IN>" using 1:2 axes x1y2 title 'RT' ls l1 lw 1 with lines,\
"<IN>" using 1:2 axes x1y2 title 'RL' ls l2 lw 1 with lines,\
"<IN>" using 1:2 axes x1y2 title 'RLS' ls l3 lw 1 with lines,\
"<IN>" using 1:2 axes x1y2 title 'WWT' ls l4 lw 1 with lines,\
"<IN>" using 1:2 axes x1y2 title 'VLT' ls l0 lw 1 with lines,\
"<IN>" using 1:2 axes x1y2 title 'SOL' ls l6 lw 1 with lines
</pre>

=== Ausgänge ===
<pre>
# Created by FHEM/98_SVG.pm, 2015-05-11 21:45:00
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 ''
set ytics ("An" -1, "Aus" -2, "An" -5, "Aus" -6, "An" -9, "Aus" -10, "An" -13, "Aus" -14)
set y2tics ("An" 1, "Aus" 0, "An" -3, "Aus" -4, "An" -7, "Aus" -8, "An" -11, "Aus" -12)
set grid
set ylabel ""
set y2label "Digital"
set yrange [-16:2]
set y2range [-16:2]

#FileLog 3:dim_compressor_output.*::$fld[2]=~"on"?1:0
#FileLog 3:dim_ventilator_output.*::$fld[2]=~"on"?-1:-2
#FileLog 3:dim_2heatgenerator_output.*::$fld[2]=~"on"?-3:-4
#FileLog 3:dim_circulationpump_output.*::$fld[2]=~"on"?-5:-6
#FileLog 3:dim_dhwpump_output.*::$fld[2]=~"on"?-7:-8
#FileLog 3:dim_auxiliarypump_output.*::$fld[2]=~"on"?-9:-10
#FileLog 3:dim_solarpump_output.*::$fld[2]=~"on"?-11:-12
#FileLog 3:dim_flangeheater_output.*::$fld[2]=~"on"?-13:-14

plot "<IN>" using 1:2 axes x1y2 title 'Vd' ls l7 lw 1.5 with steps,\
"<IN>" using 1:2 axes x1y2 title 'Ve' ls l6 lw 1.5 with steps,\
"<IN>" using 1:2 axes x1y2 title '2.We' ls l5 lw 1.5 with steps,\
"<IN>" using 1:2 axes x1y2 title 'Hub' ls l4 lw 1.5 with steps,\
"<IN>" using 1:2 axes x1y2 title 'Wup' ls l3 lw 1 with steps,\
"<IN>" using 1:2 axes x1y2 title 'Zup' ls l0 lw 1.5 with steps,\
"<IN>" using 1:2 axes x1y2 title 'Sol' ls l2 lw 1.5 with steps,\
"<IN>" using 1:2 axes x1y2 title 'Flh' ls l7 lw 1.5 with steps
</pre>

[[Bild:dimplex_hp_graph.jpg|thumb|right|Plotbeispiel]]
Im nebenstehenden Plotbeispiel werde die Temperaturen (Analogwerte) sowie die Ausgänge (Digitalwerte) dargestellt. Im einzelnen sind die Kurven für die

* Aussen- (AT)
* Raum- (RT)
* Rücklauf- (RL)
* Rücklaufsoll- (RLS)
* Warmwasser- (WWT) und
* Vorlauftemperatur (VLT)

sowie die Ausgänge für

* Verdichter 1 (Vd)
* Ventilator (Ve)
* 2.Wärmeerzeuger (2We)
* Heizungsumwälzpumpe (Hup)
* Warmwasserumwälzpumpe (Wup) und
* Zusatzumwälzpumpe (Zup)

enthalten.

= Kontakt =
Weitere Fragen, Wünsche und Anregungen bitte im entsprechenden {{Link2Forum|Topic=33086|LinkText=Forenthread zum Wiki-Artikel "Dimplex Wärmepumpenmanager"}} zur Diskussion stellen.

Offene Punkte:
- Darstellung der Werte in einer readingsGroup
- Zugriff auf Zeitfunktionen mit Lesen und Schreiben

[[Kategorie:HOWTOS]]
[[Kategorie:Heizungssteuerung]]
[[Kategorie:Other Components]]

Dimplex Wärmepumpenmanager

2025-03-30T16:16:04Z

TomLee: Spurensuche weshalb der Abstand entsteht

Mit der NWPM-Erweiterung ist es möglich, den Dimplex Wärmepumpenmanager in ein Hausnetzwerk einzubinden. Durch die Einbindung der NWPM-Erweiterung ist es ebenfalls möglich, die zur Verfügung gestellten Werte vom Wärmepumpenmanager mittels ModbusTCP in FHEM zu übernehmen, anzuzeigen und grafisch darzustellen.

== Voraussetzung ==
Die Anbindung des Dimplex Wärmepumpenmanager an FHEM erfolgt mittels NWPM-Erweiterung und der aktuellen FHEM Installation. Weiterhin werden die zur Verfügung stehenden Module:

* 36_ModbusTCPServer.pm
* 37_ModbusCoil.pm
* 37_ModbusRegister.pm

genutzt. Getestet wurde der Zugriff auf einem BeagleBone Black mit der [[BeagleBone Black|hier beschriebenen]] Debian Installation.

== Installation ==
Die oben aufgeführten Module sind notwendig und müssen nachinstalliert werden. Zum Zeitpunkt der Erstellung dieser Dokumentation (31.1.2015) sind diese noch nicht offiziell in FHEM enthalten und werden auch nicht mittels Update verteilt. Die Module werden mit dem Befehl:
<pre>
update all https://raw.githubusercontent.com/ChrisD70/FHEM-Modules/master/autoupdate/mb/controls_modbus.txt
</pre>
über die FHEM Befehlszeile installiert und anschließend
<pre>
reload 36_ModbusTCPServer.pm
reload 37_ModbusCoil.pm
reload 37_ModbusRegister.pm
</pre>
mit einem Reload geladen.
== Benutzung ==
=== Anlegen der ModbusTCPServer Verbindung ===
Wie im nachfolgenden angegeben muss zunächst eine ModbusTCPServer Verbindung hergestellt werden. Die angegebene IP-Adresse muss durch die IP-Adresse der Wärmepumpe ersetzt werden.
<pre>
########################################################
## ModbusTCPServer definieren
########################################################
define HeatPumpServer ModbusTCPServer 192.168.1.150
attr HeatPumpServer verbose 2
</pre>
Ein erfolgreicher Verbindungsaufbau wird mit einem „ok“ im State gekennzeichnet.

=== Modbus-Register/Coil Adressen definieren ===
Im nachfolgendem Beispiel wird anhand der Außentemperatur die Adressdefinition erklärt.
<pre>
define dim_outdoor_temperature ModbusRegister 0 1
attr dim_outdoor_temperature IODev HeatPumpServer
attr dim_outdoor_temperature conversion 0.1:0
attr dim_outdoor_temperature event-min-interval .*:900
attr dim_outdoor_temperature event-on-change-reading .*
attr dim_outdoor_temperature plcDataType INT
attr dim_outdoor_temperature registerType Holding
attr dim_outdoor_temperature room Dimplex
attr dim_outdoor_temperature stateAlias temperature
attr dim_outdoor_temperature stateFormat {sprintf("%0.1f", ReadingsVal($name,"state",0))}
attr dim_outdoor_temperature updateInterval 00:10:00
</pre>
Erklärung:
{| class="wikitable"
|+ Erläuterungen zur Adressdefinition
|-
! Attribut !! Erläuterungen
|-
| ModbusRegister 0 1 || 0 Device Adresse, in der Regel bei ModbusTCP immer 0
|-
| ModbusRegister 0 1 || 1 Register Adresse, wird unter www.dimplex.de/wiki → ModbusTCP → Spalten IP zur Verfügung gestellt
|-
| IODev || Verwendeter und zuvor angelegter ModbusTCPServer
|-
| conversion || eine gegebenenfalls notwendige Konvertierung des übermittelten Values
|-
| PlcDataType || Ermögliche automatische Interpretation der ankommenden Daten
|-
| stateAlias || es wird ein zusätzliches Reading erzeugt, um zum Beispiel das Statistic-Modul nutzen zu können, stateAlias ist eine echte Kopie von "state"
|-
| updateInterval || Intervall des Abfragezyklus (z.B. 00:10:00 Minuten)
|-
|}

=== Betriebsdaten ===
Vorschlag der Namensvergabe für die Betriebsdaten. Eine sinnvolle Namensvergabe erleichtert später das Anlegen weiterer Definitionen von zum Beispiel Logfiles, Statistiken oder auch [[readingsGroup]].
{| class="wikitable"
|-
| dim_outdoor_temperature || Außentemperatur
|-
| dim_flow_temperature || Vorlauftemperatur
|-
| dim_return_temperature || Rücklauftemperatur
|-
| dim_returnset_temperature || Rücklaufsolltemperatur
|-
| dim_room_temperature || Raumtemperatur
|-
| dim_dhw_temperature || Warmwassertemperatur
|-
| dim_dhwset_temperature || Warmwassersolltemperatur
|-
| dim_brine_temperature || Soletemperatur
|-
| dim_high_pressure || Hochdruck
|-
| dim_low_pressure || Niederdruck
|}
Register Warmwassertemperatur definieren:<pre>
define dim_dhw_temperature ModbusRegister 0 3
attr dim_dhw_temperature IODev HeatPumpServer
attr dim_dhw_temperature conversion 0.1:0
attr dim_dhw_temperature event-min-interval .*:900
attr dim_dhw_temperature event-on-change-reading .*
attr dim_dhw_temperature plcDataType INT
attr dim_dhw_temperature registerType Holding
attr dim_dhw_temperature room Dimplex
attr dim_dhw_temperature stateAlias temperature
attr dim_dhw_temperature stateFormat {sprintf("%0.1f", ReadingsVal($name,"state",0))}
attr dim_dhw_temperature updateInterval 00:01:00
</pre>Register Vorlauftemperatur definieren:<pre>
define dim_flow_temperature ModbusRegister 0 5
attr dim_flow_temperature IODev HeatPumpServer
attr dim_flow_temperature conversion 0.1:0
attr dim_flow_temperature event-min-interval .*:900
attr dim_flow_temperature event-on-change-reading .*
attr dim_flow_temperature plcDataType INT
attr dim_flow_temperature registerType Holding
attr dim_flow_temperature room Dimplex
attr dim_flow_temperature stateAlias temperature
attr dim_flow_temperature stateFormat {sprintf("%0.1f", ReadingsVal($name,"state",0))}
attr dim_flow_temperature updateInterval 00:01:00
</pre>Register Rücklauftemperatur definieren:<pre>
define dim_return_temperature ModbusRegister 0 2
attr dim_return_temperature IODev HeatPumpServer
attr dim_return_temperature conversion 0.1:0
attr dim_return_temperature event-min-interval .*:900
attr dim_return_temperature event-on-change-reading .*
attr dim_return_temperature plcDataType INT
attr dim_return_temperature registerType Holding
attr dim_return_temperature room Dimplex
attr dim_return_temperature stateAlias temperature
attr dim_return_temperature stateFormat {sprintf("%0.1f", ReadingsVal($name,"state",0))}
attr dim_return_temperature updateInterval 00:01:00
</pre>Register Rücklaufsolltemperatur definieren:<pre>
define dim_returnset_temperature ModbusRegister 0 53
attr dim_returnset_temperature IODev HeatPumpServer
attr dim_returnset_temperature conversion 0.1:0
attr dim_returnset_temperature event-min-interval .*:900
attr dim_returnset_temperature event-on-change-reading .*
attr dim_returnset_temperature plcDataType INT
attr dim_returnset_temperature registerType Holding
attr dim_returnset_temperature room Dimplex
attr dim_returnset_temperature stateAlias temperature
attr dim_returnset_temperature stateFormat {sprintf("%0.1f", ReadingsVal($name,"state",0))}
attr dim_returnset_temperature updateInterval 00:05:00
</pre>

==== Logfile Betriebsdaten ====
Anlegen eines täglichen Logfile der Betriebsdaten.
<pre>
define filelog_dim_temperature FileLog ./log/filelog_dim_temperature-%W-%d.log
dim_.*._temperature:temperature:.*|dim_.*._pressure:pressure:.*
attr filelog_dim_temperature room Dimplex
</pre>

==== Statistiken ====
Folgender Code legt die Statistiken der Betriebsdaten an
<pre>
define dim_statistics statistics dim_.*._temperature|dim_.*._pressure
attr dim_statistics dayChangeTime 1
attr dim_statistics deltaReadings temperature,pressure
attr dim_statistics minAvgMaxReadings temperature,pressure
attr dim_statistics room Dimplex
attr dim_statistics tendencyReadings temperature,pressure
</pre>

=== Zustände ===
Vorschlag der Namensvergabe für die Zustände. Eine sinnvolle Namensvergabe erleichtert später das Anlegen weiterer Definitionen von zum Beispiel Logfiles, Statistiken oder auch [[readingsGroup]].
{| class="wikitable"
|-
| dim_compressor_output || Verdichter
|-
| dim_ventilator_output || Ventilator
|-
| dim_brinepump_ output || Solepumpe
|-
| dim_circulationpump_output || Heizungsumwälzpumpe M13
|-
| dim_2heatgenerator_output || 2.Wärmeerzeuger
|-
| dim_dhwpump_output || Warmwasserpumpe M18
|-
| dim_auxiliarypump_output || Zusatzpumpe M16
|-
| dim_flangeheater_output || Flanschheizung
|}
Coil Verdichter und passenden HourCounter für Verdichter definieren:<pre>
define dim_compressor_output ModbusCoil 0 41
attr dim_compressor_output IODev HeatPumpServer
attr dim_compressor_output disableRegisterMapping 1
attr dim_compressor_output event-min-interval .*:900
attr dim_compressor_output event-on-change-reading .*
attr dim_compressor_output room Dimplex
attr dim_compressor_output source Coil
attr dim_compressor_output updateInterval 00:01:00

define hourcounter_compressor_output HourCounter dim_compressor_output:on dim_compressor_output:off
attr hourcounter_compressor_output event-min-interval tick.*:0,.*:3600
attr hourcounter_compressor_output event-on-change-reading .*
</pre>Coil Ventilator definieren und passenden HourCounter für Ventilator definieren:<pre>
define dim_ventilator_output ModbusCoil 0 43
attr dim_ventilator_output IODev HeatPumpServer
attr dim_ventilator_output disableRegisterMapping 1
attr dim_ventilator_output event-min-interval .*:900
attr dim_ventilator_output event-on-change-reading .*
attr dim_ventilator_output room Dimplex
attr dim_ventilator_output source Coil
attr dim_ventilator_output updateInterval 00:01:00

define hourcounter_ventilator_output HourCounter dim_ventilator_output:on dim_ventilator_output:off
attr hourcounter_ventilator_output event-min-interval tick.*:0,.*:3600
attr hourcounter_ventilator_output event-on-change-reading .*
</pre>Coil 2.Wärmeerzeuger definieren und passenden HourCounter für 2.Wärmeerzeuger definieren:<pre>
define dim_2heatgenerator_output ModbusCoil 0 44
attr dim_2heatgenerator_output IODev HeatPumpServer
attr dim_2heatgenerator_output disableRegisterMapping 1
attr dim_2heatgenerator_output event-min-interval .*:900
attr dim_2heatgenerator_output event-on-change-reading .*
attr dim_2heatgenerator_output room Dimplex
attr dim_2heatgenerator_output source Coil
attr dim_2heatgenerator_output updateInterval 00:01:00

define hourcounter_2heatgenerator_output HourCounter dim_2heatgenerator_output:on dim_2heatgenerator_output:off
attr hourcounter_2heatgenerator_output event-min-interval tick.*:0,.*:3600
attr hourcounter_2heatgenerator_output event-on-change-reading .*
</pre>Coil Heizungsumwälzpumpe M13 definieren und passenden HourCounter für Heizungsumwälzpumpe M13 definieren:<pre>
define dim_circulationpump_output ModbusCoil 0 45
attr dim_circulationpump_output IODev HeatPumpServer
attr dim_circulationpump_output disableRegisterMapping 1
attr dim_circulationpump_output event-min-interval .*:900
attr dim_circulationpump_output event-on-change-reading .*
attr dim_circulationpump_output room Dimplex
attr dim_circulationpump_output source Coil
attr dim_circulationpump_output updateInterval 00:01:00

define hourcounter_circulationpump_output HourCounter dim_circulationpump_output:on dim_circulationpump_output:off
attr hourcounter_circulationpump_output event-min-interval tick.*:0,.*:3600
attr hourcounter_circulationpump_output event-on-change-reading .*
</pre>Coil Warmwasserpumpe M18 definieren und passenden HourCounter für Warmwasserpumpe M18 definieren:<pre>
define dim_dhwpump_output ModbusCoil 0 46
attr dim_dhwpump_output IODev HeatPumpServer
attr dim_dhwpump_output disableRegisterMapping 1
attr dim_dhwpump_output event-min-interval .*:900
attr dim_dhwpump_output event-on-change-reading .*
attr dim_dhwpump_output room Dimplex
attr dim_dhwpump_output source Coil
attr dim_dhwpump_output updateInterval 00:01:00

define hourcounter_dhwpump_output HourCounter dim_dhwpump_output:on dim_dhwpump_output:off
attr hourcounter_dhwpump_output event-min-interval tick.*:0,.*:3600
attr hourcounter_dhwpump_output event-on-change-reading .*
</pre>Coil Zusatzpumpe M16 definieren und Passenden HourCounter für Zusatzpumpe M16 definieren:<pre>
define dim_auxiliarypump_output ModbusCoil 0 49
attr dim_auxiliarypump_output IODev HeatPumpServer
attr dim_auxiliarypump_output disableRegisterMapping 1
attr dim_auxiliarypump_output event-min-interval .*:900
attr dim_auxiliarypump_output event-on-change-reading .*
attr dim_auxiliarypump_output room Dimplex
attr dim_auxiliarypump_output source Coil
attr dim_auxiliarypump_output updateInterval 00:01:00

define hourcounter_auxiliarypump_output HourCounter dim_auxiliarypump_output:on dim_auxiliarypump_output:off
attr hourcounter_auxiliarypump_output event-min-interval tick.*:0,.*:3600
attr hourcounter_auxiliarypump_output event-on-change-reading .*
</pre>Coil Flanschheizung definieren und passenden HourCounter für Flanschheizung M16 definieren:<pre>
define dim_flangeheater_output ModbusCoil 0 50
attr dim_flangeheater_output IODev HeatPumpServer
attr dim_flangeheater_output disableRegisterMapping 1
attr dim_flangeheater_output event-min-interval .*:900
attr dim_flangeheater_output event-on-change-reading .*
attr dim_flangeheater_output room Dimplex
attr dim_flangeheater_output source Coil
attr dim_flangeheater_output updateInterval 00:01:00

define hourcounter_flangeheater_output HourCounter dim_flangeheater_output:on dim_flangeheater_output:off
attr hourcounter_flangeheater_output event-min-interval tick.*:0,.*:3600
attr hourcounter_flangeheater_output event-on-change-reading .*
</pre>

==== Logfile Zustände ====
Anlegen eines wöchentlichen Logfile der Zustände:
<pre>
define filelog_dim_output_week FileLog ./log/filelog_dim_output_week-%W.log dim_.*._output.*
attr filelog_dim_output_week room Dimplex
</pre>

=== Historie ===
Vorschlag der Namensvergabe für die Historie. Eine sinnvolle Namensvergabe erleichtert später das Anlegen weiterer Definitionen von zum Beispiel Logfiles, Statistiken oder auch [[readingsGroup]].
{| class="wikitable"
|-
| dim_compressor_history || Verdichter
|-
| dim_ventilator_history || Ventilator
|-
| dim_brinepump_history || Solepumpe
|-
| dim_circulationpump_history || Heizungsumwälzpumpe M13
|-
| dim_2heatgenerator_history || 2.Wärmeerzeuger
|-
| dim_dhwpump_history || Warmwasserpumpe M18
|-
| dim_auxiliarypump_history || Zusatzpumpe M16
|-
| dim_flangeheater_history || Flanschheizung
|}
Register Historie Verdichter definieren:<pre>
define dim_compressor_history ModbusRegister 0 72
attr dim_compressor_history IODev HeatPumpServer
attr dim_compressor_history alignUpdateInterval 00:01:00
attr dim_compressor_history event-on-change-reading .*
attr dim_compressor_history plcDataType INT
attr dim_compressor_history registerType Holding
attr dim_compressor_history room Dimplex
attr dim_compressor_history updateInterval 01:00:00
</pre>Register Historie Ventilator definieren:<pre>
define dim_ventilator_history ModbusRegister 0 74
attr dim_ventilator_history IODev HeatPumpServer
attr dim_ventilator_history alignUpdateInterval 00:01:00
attr dim_ventilator_history event-on-change-reading .*
attr dim_ventilator_history plcDataType INT
attr dim_ventilator_history registerType Holding
attr dim_ventilator_history room Dimplex
attr dim_ventilator_history updateInterval 01:00:00
</pre>Register Historie 2.Wärmeerzeuger definieren:<pre>
define dim_2heatgenerator_history ModbusRegister 0 75
attr dim_2heatgenerator_history IODev HeatPumpServer
attr dim_2heatgenerator_history alignUpdateInterval 00:01:00
attr dim_2heatgenerator_history event-on-change-reading .*
attr dim_2heatgenerator_history plcDataType INT
attr dim_2heatgenerator_history registerType Holding
attr dim_2heatgenerator_history room Dimplex
attr dim_2heatgenerator_history updateInterval 01:00:00
</pre>Register Historie Heizungsumwälzpumpe M13 definieren:<pre>
define dim_circulationpump_history ModbusRegister 0 76
attr dim_circulationpump_history IODev HeatPumpServer
attr dim_circulationpump_history alignUpdateInterval 00:01:00
attr dim_circulationpump_history event-on-change-reading .*
attr dim_circulationpump_history plcDataType INT
attr dim_circulationpump_history registerType Holding
attr dim_circulationpump_history room Dimplex
attr dim_circulationpump_history updateInterval 01:00:00
</pre>Register Historie Warmwasserpumpe M18 definieren:<pre>
define dim_dhwpump_history ModbusRegister 0 77
attr dim_dhwpump_history IODev HeatPumpServer
attr dim_dhwpump_history alignUpdateInterval 00:01:00
attr dim_dhwpump_history event-on-change-reading .*
attr dim_dhwpump_history plcDataType INT
attr dim_dhwpump_history registerType Holding
attr dim_dhwpump_history room Dimplex
attr dim_dhwpump_history updateInterval 01:00:00
</pre>Register Historie Flanschheizung definieren:<pre>
define dim_flangeheater_history ModbusRegister 0 78
attr dim_flangeheater_history IODev HeatPumpServer
attr dim_flangeheater_history alignUpdateInterval 00:01:00
attr dim_flangeheater_history event-on-change-reading .*
attr dim_flangeheater_history plcDataType INT
attr dim_flangeheater_history registerType Holding
attr dim_flangeheater_history room Dimplex
attr dim_flangeheater_history updateInterval 01:00:00
</pre>
==== Logfile Historie ====
Anlegen eines monatlichen Logfile für die Historischen Daten:
<pre>
define filelog_dim_history_month FileLog ./log/filelog_dim_history_month-%m.log dim_.*._history.*
attr filelog_dim_history_month room Dimplex
</pre>

==== Wärmemengen ====
Laut Definition aus dem [http://www.dimplex.de/wiki Dimplex-Wiki] werden die Wärmemengen für Heizen, Warmwasser und Schwimmbad aus 3 Register-Adressen zusammengesetzt. Im Nachfolgenden Code-Beispiel wird dies entsprechend dargestellt. Dabei wird jeweils im ersten Register ein neues userReading mit der Darstellung der Gesamtwärmemenge angelegt.

Wärmemenge Heizen definieren:
<pre>
define dim_heating1_thermalenergy ModbusRegister 0 5096
attr dim_heating1_thermalenergy IODev HeatPumpServer
attr dim_heating1_thermalenergy event-on-change-reading .*
attr dim_heating1_thermalenergy plcDataType INT
attr dim_heating1_thermalenergy registerType Holding
attr dim_heating1_thermalenergy room Dimplex
attr dim_heating1_thermalenergy updateInterval 00:15:00
attr dim_heating1_thermalenergy userReadings heatingthermalenergy {\
((ReadingsVal("dim_heating3_thermalenergy","state",0)*100000000)+\
(ReadingsVal("dim_heating2_thermalenergy","state",0)*10000)+\
(ReadingsVal("dim_heating1_thermalenergy","state",0)))}

define dim_heating2_thermalenergy ModbusRegister 0 5097
attr dim_heating2_thermalenergy IODev HeatPumpServer
attr dim_heating2_thermalenergy event-on-change-reading .*
attr dim_heating2_thermalenergy plcDataType INT
attr dim_heating2_thermalenergy registerType Holding
attr dim_heating2_thermalenergy room Dimplex
attr dim_heating2_thermalenergy updateInterval 00:15:00

define dim_heating3_thermalenergy ModbusRegister 0 5098
attr dim_heating3_thermalenergy IODev HeatPumpServer
attr dim_heating3_thermalenergy event-on-change-reading .*
attr dim_heating3_thermalenergy plcDataType INT
attr dim_heating3_thermalenergy registerType Holding
attr dim_heating3_thermalenergy room Dimplex
attr dim_heating3_thermalenergy updateInterval 00:15:00
</pre>Wärmemenge Warmwasser definieren:<pre>
define dim_dhw1_thermalenergy ModbusRegister 0 5099
attr dim_dhw1_thermalenergy IODev HeatPumpServer
attr dim_dhw1_thermalenergy event-on-change-reading .*
attr dim_dhw1_thermalenergy plcDataType INT
attr dim_dhw1_thermalenergy registerType Holding
attr dim_dhw1_thermalenergy room Dimplex
attr dim_dhw1_thermalenergy updateInterval 00:15:00
attr dim_dhw1_thermalenergy userReadings dhwthermalenergy {\
((ReadingsVal("dim_dhw3_thermalenergy","state",0)*100000000)+\
(ReadingsVal("dim_dhw2_thermalenergy","state",0)*10000)+\
(ReadingsVal("dim_dhw1_thermalenergy","state",0)))}

define dim_dhw2_thermalenergy ModbusRegister 0 5100
attr dim_dhw2_thermalenergy IODev HeatPumpServer
attr dim_dhw2_thermalenergy event-on-change-reading .*
attr dim_dhw2_thermalenergy plcDataType INT
attr dim_dhw2_thermalenergy registerType Holding
attr dim_dhw2_thermalenergy room Dimplex
attr dim_dhw2_thermalenergy updateInterval 00:15:00

define dim_dhw3_thermalenergy ModbusRegister 0 5101
attr dim_dhw3_thermalenergy IODev HeatPumpServer
attr dim_dhw3_thermalenergy event-on-change-reading .*
attr dim_dhw3_thermalenergy plcDataType INT
attr dim_dhw3_thermalenergy registerType Holding
attr dim_dhw3_thermalenergy room Dimplex
attr dim_dhw3_thermalenergy updateInterval 00:15:00
</pre>
==== Umweltenergie ====
Als Umweltenergie wird die zugeführte Kälteenergie aus der Umwelt (Luft/Erdreich) bezeichnet. Das Auslesen dieser Werte über die Schnittstelle ist erst ab einem neueren Softwarestand möglich. Die Differenz der gesamten Wärmemenge und der Umweltenergie entspricht in etwa der Energie des Verdichters.

Umweltenergie/entzogene Kälteenergie definieren:
<pre>
define dim_environment1_energy ModbusRegister 0 5127
attr dim_environment1_energy IODev HeatPumpServer
attr dim_environment1_energy event-on-change-reading .*
attr dim_environment1_energy plcDataType INT
attr dim_environment1_energy registerType Holding
attr dim_environment1_energy room Dimplex
attr dim_environment1_energy updateInterval 00:15:00
attr dim_environment1_energy userReadings environmentenergy {\
((ReadingsVal("dim_environment3_energy","state",0)*100000000)+\
(ReadingsVal("dim_environment2_energy","state",0)*10000)+\
(ReadingsVal("dim_environment1_energy","state",0)))}

define dim_environment2_energy ModbusRegister 0 5128
attr dim_environment2_energy IODev HeatPumpServer
attr dim_environment2_energy event-on-change-reading .*
attr dim_environment2_energy plcDataType INT
attr dim_environment2_energy registerType Holding
attr dim_environment2_energy room Dimplex
attr dim_environment2_energy updateInterval 00:15:00

define dim_environment3_energy ModbusRegister 0 5129
attr dim_environment3_energy IODev HeatPumpServer
attr dim_environment3_energy event-on-change-reading .*
attr dim_environment3_energy plcDataType INT
attr dim_environment3_energy registerType Holding
attr dim_environment3_energy room Dimplex
attr dim_environment3_energy updateInterval 00:15:00
</pre>

==== Logfile Wärmemengen ====
Anlegen eines jährlichen Logfile der Wärmemengen.
<pre>
define filelog_dim_thermalenergy_year FileLog ./log/filelog_dim_thermalenergy_year-%y.log dim_heating1_thermalenergy:heatingthermalenergy:.*|dim_heating1_thermalenergy:heatingthermalenergy:.*
attr filelog_dim_thermalenergy_year room Dimplex
</pre>

=== Meldungen ===
[[Bild:dimplex_rh_status_heatpump.jpg|thumb|right|Beispiel Meldungen]]
Eine sinnvolle Anzeige sind die Meldungen (Status, Sperre, Störung) der Wärmepumpe. Im nachfolgenden Beispiel werden die Meldungen mit dem Hilfsmodul [[readingsHistory]] dargestellt. Die Definitionen der Meldungen beziehen sich auf die im [http://www.dimplex.de/wiki Dimplex-Wiki] beschriebene L-Software. Bei abweichenden Softwareständen müssen die Register sowie die Texte angepasst werden.

Register Statusmeldung definieren:

<pre>
define dim_status_heatpump ModbusRegister 0 103
attr dim_status_heatpump IODev HeatPumpServer
attr dim_status_heatpump event-on-change-reading .*
attr dim_status_heatpump plcDataType INT
attr dim_status_heatpump registerType Holding
attr dim_status_heatpump room Dimplex
attr dim_status_heatpump updateInterval 00:00:10
attr dim_status_heatpump userReadings Status {\
((ReadingsVal($name,"state","") == 1) ? "Aus":\
(ReadingsVal($name,"state","") == 4) ? "Warmwasser":\
(ReadingsVal($name,"state","") == 10) ? "Abtauen":\
(ReadingsVal($name,"state","") == 11) ? "Durchflussüberwachnung":"")}

</pre>Register Sperrmeldunge definieren:<pre>
define dim_block_heatpump ModbusRegister 0 104
attr dim_block_heatpump IODev HeatPumpServer
attr dim_block_heatpump event-on-change-reading .*
attr dim_block_heatpump plcDataType INT
attr dim_block_heatpump registerType Holding
attr dim_block_heatpump room Dimplex
attr dim_block_heatpump updateInterval 00:00:10
attr dim_block_heatpump userReadings Sperre {\
((ReadingsVal($name,"state","") == 0) ? "":\
(ReadingsVal($name,"state","") == 7) ? "Systemkontrolle":\
(ReadingsVal($name,"state","") == 9) ? "Pumpenvorlauf":\
(ReadingsVal($name,"state","") == 10) ? "Mindeststandzeit":\
(ReadingsVal($name,"state","") == 11) ? "Netzbelastung":\
(ReadingsVal($name,"state","") == 12) ? "Schaltspielsperre":\
(ReadingsVal($name,"state","") == 15) ? "EVU":"")}
</pre>Register Störmeldungen definieren:<pre>
define dim_fault_heatpump ModbusRegister 0 105
attr dim_fault_heatpump IODev HeatPumpServer
attr dim_fault_heatpump event-on-change-reading .*
attr dim_fault_heatpump plcDataType INT
attr dim_fault_heatpump registerType Holding
attr dim_fault_heatpump room Dimplex
attr dim_fault_heatpump updateInterval 00:01:00
attr dim_fault_heatpump userReadings Störung {\
((ReadingsVal($name,"state","") == 0) ? "":\
(ReadingsVal($name,"state","") == 6) ? "Elektronisches Ex.Ventil":\
(ReadingsVal($name,"state","") == 15) ? "Sensorik":\
(ReadingsVal($name,"state","") == 19) ? "!Primärkreis":\
(ReadingsVal($name,"state","") == 22) ? "!Warmwasser":\
(ReadingsVal($name,"state","") == 23) ? "!Last Verdichter":\
(ReadingsVal($name,"state","") == 24) ? "!Codierung":\
(ReadingsVal($name,"state","") == 25) ? "!Niederdruck":\
(ReadingsVal($name,"state","") == 26) ? "!Frostschutz":\
(ReadingsVal($name,"state","") == 29) ? "!Temperatur Differenz":\
(ReadingsVal($name,"state","") == 31) ? "!Durchfluss":"")}
</pre>
==== Anzeige der Meldungen ====
readingsHistory definieren:<pre>
define rh_dim_status_heatpump readingsHistory dim_status_heatpump:Status dim_block_heatpump:Sperre dim_fault_heatpump:Störung
attr rh_dim_status_heatpump alias Status
attr rh_dim_status_heatpump mapping {'dim_status_heatpump' => '', 'dim_block_heatpump' => '', 'dim_fault_heatpump' => ''}
attr rh_dim_status_heatpump nohtml 1
attr rh_dim_status_heatpump room Dimplex
attr rh_dim_status_heatpump rows 20
attr rh_dim_status_heatpump timestampFormat %b %a %R
</pre>

== Plotbeispiel ==
=== Temperaturen ===
<pre>
# Created by FHEM/98_SVG.pm, 2015-05-11 21:40:00
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 ytics y2tics
set ylabel ""
set y2label "Temperatur (°C)"

#filelog_dim_temperature_week 4:dim_outdoor_temperature.*::
#filelog_dim_temperature_week 4:dim_room_temperature.*::
#filelog_dim_temperature_week 4:dim_return_temperature.*::
#filelog_dim_temperature_week 4:dim_returnset_temperature.*::
#filelog_dim_temperature_week 4:dim_dhw_temperature.*::
#filelog_dim_temperature_week 4:dim_flow_temperature.*::
#filelog_dim_temperature_week 4:dim_brine_temperature.*::

plot "<IN>" using 1:2 axes x1y2 title 'AT' ls l7 lw 1 with lines,\
"<IN>" using 1:2 axes x1y2 title 'RT' ls l1 lw 1 with lines,\
"<IN>" using 1:2 axes x1y2 title 'RL' ls l2 lw 1 with lines,\
"<IN>" using 1:2 axes x1y2 title 'RLS' ls l3 lw 1 with lines,\
"<IN>" using 1:2 axes x1y2 title 'WWT' ls l4 lw 1 with lines,\
"<IN>" using 1:2 axes x1y2 title 'VLT' ls l0 lw 1 with lines,\
"<IN>" using 1:2 axes x1y2 title 'SOL' ls l6 lw 1 with lines
</pre>

=== Ausgänge ===
<pre>
# Created by FHEM/98_SVG.pm, 2015-05-11 21:45:00
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 ''
set ytics ("An" -1, "Aus" -2, "An" -5, "Aus" -6, "An" -9, "Aus" -10, "An" -13, "Aus" -14)
set y2tics ("An" 1, "Aus" 0, "An" -3, "Aus" -4, "An" -7, "Aus" -8, "An" -11, "Aus" -12)
set grid
set ylabel ""
set y2label "Digital"
set yrange [-16:2]
set y2range [-16:2]

#FileLog 3:dim_compressor_output.*::$fld[2]=~"on"?1:0
#FileLog 3:dim_ventilator_output.*::$fld[2]=~"on"?-1:-2
#FileLog 3:dim_2heatgenerator_output.*::$fld[2]=~"on"?-3:-4
#FileLog 3:dim_circulationpump_output.*::$fld[2]=~"on"?-5:-6
#FileLog 3:dim_dhwpump_output.*::$fld[2]=~"on"?-7:-8
#FileLog 3:dim_auxiliarypump_output.*::$fld[2]=~"on"?-9:-10
#FileLog 3:dim_solarpump_output.*::$fld[2]=~"on"?-11:-12
#FileLog 3:dim_flangeheater_output.*::$fld[2]=~"on"?-13:-14

plot "<IN>" using 1:2 axes x1y2 title 'Vd' ls l7 lw 1.5 with steps,\
"<IN>" using 1:2 axes x1y2 title 'Ve' ls l6 lw 1.5 with steps,\
"<IN>" using 1:2 axes x1y2 title '2.We' ls l5 lw 1.5 with steps,\
"<IN>" using 1:2 axes x1y2 title 'Hub' ls l4 lw 1.5 with steps,\
"<IN>" using 1:2 axes x1y2 title 'Wup' ls l3 lw 1 with steps,\
"<IN>" using 1:2 axes x1y2 title 'Zup' ls l0 lw 1.5 with steps,\
"<IN>" using 1:2 axes x1y2 title 'Sol' ls l2 lw 1.5 with steps,\
"<IN>" using 1:2 axes x1y2 title 'Flh' ls l7 lw 1.5 with steps
</pre>

[[Bild:dimplex_hp_graph.jpg|thumb|right|Plotbeispiel]]
Im nebenstehenden Plotbeispiel werde die Temperaturen (Analogwerte) sowie die Ausgänge (Digitalwerte) dargestellt. Im einzelnen sind die Kurven für die

* Aussen- (AT)
* Raum- (RT)
* Rücklauf- (RL)
* Rücklaufsoll- (RLS)
* Warmwasser- (WWT) und
* Vorlauftemperatur (VLT)

sowie die Ausgänge für

* Verdichter 1 (Vd)
* Ventilator (Ve)
* 2.Wärmeerzeuger (2We)
* Heizungsumwälzpumpe (Hup)
* Warmwasserumwälzpumpe (Wup) und
* Zusatzumwälzpumpe (Zup)

enthalten.

= Kontakt =
Weitere Fragen, Wünsche und Anregungen bitte im entsprechenden {{Link2Forum|Topic=33086|LinkText=Forenthread zum Wiki-Artikel "Dimplex Wärmepumpenmanager"}} zur Diskussion stellen.

Offene Punkte:
- Darstellung der Werte in einer readingsGroup
- Zugriff auf Zeitfunktionen mit Lesen und Schreiben

[[Kategorie:HOWTOS]]
[[Kategorie:Heizungssteuerung]]
[[Kategorie:Other Components]]

Dimplex Wärmepumpenmanager

2025-03-30T16:07:35Z

TomLee: Raw-Code-Anpassungen

Mit der NWPM-Erweiterung ist es möglich, den Dimplex Wärmepumpenmanager in ein Hausnetzwerk einzubinden. Durch die Einbindung der NWPM-Erweiterung ist es ebenfalls möglich, die zur Verfügung gestellten Werte vom Wärmepumpenmanager mittels ModbusTCP in FHEM zu übernehmen, anzuzeigen und grafisch darzustellen.

== Voraussetzung ==
Die Anbindung des Dimplex Wärmepumpenmanager an FHEM erfolgt mittels NWPM-Erweiterung und der aktuellen FHEM Installation. Weiterhin werden die zur Verfügung stehenden Module:

* 36_ModbusTCPServer.pm
* 37_ModbusCoil.pm
* 37_ModbusRegister.pm

genutzt. Getestet wurde der Zugriff auf einem BeagleBone Black mit der [[BeagleBone Black|hier beschriebenen]] Debian Installation.

== Installation ==
Die oben aufgeführten Module sind notwendig und müssen nachinstalliert werden. Zum Zeitpunkt der Erstellung dieser Dokumentation (31.1.2015) sind diese noch nicht offiziell in FHEM enthalten und werden auch nicht mittels Update verteilt. Die Module werden mit dem Befehl:
<pre>
update all https://raw.githubusercontent.com/ChrisD70/FHEM-Modules/master/autoupdate/mb/controls_modbus.txt
</pre>
über die FHEM Befehlszeile installiert und anschließend
<pre>
reload 36_ModbusTCPServer.pm
reload 37_ModbusCoil.pm
reload 37_ModbusRegister.pm
</pre>
mit einem Reload geladen.
== Benutzung ==
=== Anlegen der ModbusTCPServer Verbindung ===
Wie im nachfolgenden angegeben muss zunächst eine ModbusTCPServer Verbindung hergestellt werden. Die angegebene IP-Adresse muss durch die IP-Adresse der Wärmepumpe ersetzt werden.
<pre>
########################################################
## ModbusTCPServer definieren
########################################################
define HeatPumpServer ModbusTCPServer 192.168.1.150
attr HeatPumpServer verbose 2
</pre>
Ein erfolgreicher Verbindungsaufbau wird mit einem „ok“ im State gekennzeichnet.

=== Modbus-Register/Coil Adressen definieren ===
Im nachfolgendem Beispiel wird anhand der Außentemperatur die Adressdefinition erklärt.
<pre>
define dim_outdoor_temperature ModbusRegister 0 1
attr dim_outdoor_temperature IODev HeatPumpServer
attr dim_outdoor_temperature conversion 0.1:0
attr dim_outdoor_temperature event-min-interval .*:900
attr dim_outdoor_temperature event-on-change-reading .*
attr dim_outdoor_temperature plcDataType INT
attr dim_outdoor_temperature registerType Holding
attr dim_outdoor_temperature room Dimplex
attr dim_outdoor_temperature stateAlias temperature
attr dim_outdoor_temperature stateFormat {sprintf("%0.1f", ReadingsVal($name,"state",0))}
attr dim_outdoor_temperature updateInterval 00:10:00
</pre>
Erklärung:
{| class="wikitable"
|+ Erläuterungen zur Adressdefinition
|-
! Attribut !! Erläuterungen
|-
| ModbusRegister 0 1 || 0 Device Adresse, in der Regel bei ModbusTCP immer 0
|-
| ModbusRegister 0 1 || 1 Register Adresse, wird unter www.dimplex.de/wiki → ModbusTCP → Spalten IP zur Verfügung gestellt
|-
| IODev || Verwendeter und zuvor angelegter ModbusTCPServer
|-
| conversion || eine gegebenenfalls notwendige Konvertierung des übermittelten Values
|-
| PlcDataType || Ermögliche automatische Interpretation der ankommenden Daten
|-
| stateAlias || es wird ein zusätzliches Reading erzeugt, um zum Beispiel das Statistic-Modul nutzen zu können, stateAlias ist eine echte Kopie von "state"
|-
| updateInterval || Intervall des Abfragezyklus (z.B. 00:10:00 Minuten)
|-
|}

=== Betriebsdaten ===
Vorschlag der Namensvergabe für die Betriebsdaten. Eine sinnvolle Namensvergabe erleichtert später das Anlegen weiterer Definitionen von zum Beispiel Logfiles, Statistiken oder auch [[readingsGroup]].
{| class="wikitable"
|-
| dim_outdoor_temperature || Außentemperatur
|-
| dim_flow_temperature || Vorlauftemperatur
|-
| dim_return_temperature || Rücklauftemperatur
|-
| dim_returnset_temperature || Rücklaufsolltemperatur
|-
| dim_room_temperature || Raumtemperatur
|-
| dim_dhw_temperature || Warmwassertemperatur
|-
| dim_dhwset_temperature || Warmwassersolltemperatur
|-
| dim_brine_temperature || Soletemperatur
|-
| dim_high_pressure || Hochdruck
|-
| dim_low_pressure || Niederdruck
|}
Register Warmwassertemperatur definieren:<pre>
define dim_dhw_temperature ModbusRegister 0 3
attr dim_dhw_temperature IODev HeatPumpServer
attr dim_dhw_temperature conversion 0.1:0
attr dim_dhw_temperature event-min-interval .*:900
attr dim_dhw_temperature event-on-change-reading .*
attr dim_dhw_temperature plcDataType INT
attr dim_dhw_temperature registerType Holding
attr dim_dhw_temperature room Dimplex
attr dim_dhw_temperature stateAlias temperature
attr dim_dhw_temperature stateFormat {sprintf("%0.1f", ReadingsVal($name,"state",0))}
attr dim_dhw_temperature updateInterval 00:01:00
</pre>Register Vorlauftemperatur definieren:<pre>
define dim_flow_temperature ModbusRegister 0 5
attr dim_flow_temperature IODev HeatPumpServer
attr dim_flow_temperature conversion 0.1:0
attr dim_flow_temperature event-min-interval .*:900
attr dim_flow_temperature event-on-change-reading .*
attr dim_flow_temperature plcDataType INT
attr dim_flow_temperature registerType Holding
attr dim_flow_temperature room Dimplex
attr dim_flow_temperature stateAlias temperature
attr dim_flow_temperature stateFormat {sprintf("%0.1f", ReadingsVal($name,"state",0))}
attr dim_flow_temperature updateInterval 00:01:00
</pre>Register Rücklauftemperatur definieren:<pre>
define dim_return_temperature ModbusRegister 0 2
attr dim_return_temperature IODev HeatPumpServer
attr dim_return_temperature conversion 0.1:0
attr dim_return_temperature event-min-interval .*:900
attr dim_return_temperature event-on-change-reading .*
attr dim_return_temperature plcDataType INT
attr dim_return_temperature registerType Holding
attr dim_return_temperature room Dimplex
attr dim_return_temperature stateAlias temperature
attr dim_return_temperature stateFormat {sprintf("%0.1f", ReadingsVal($name,"state",0))}
attr dim_return_temperature updateInterval 00:01:00
</pre>Register Rücklaufsolltemperatur definieren:<pre>
define dim_returnset_temperature ModbusRegister 0 53
attr dim_returnset_temperature IODev HeatPumpServer
attr dim_returnset_temperature conversion 0.1:0
attr dim_returnset_temperature event-min-interval .*:900
attr dim_returnset_temperature event-on-change-reading .*
attr dim_returnset_temperature plcDataType INT
attr dim_returnset_temperature registerType Holding
attr dim_returnset_temperature room Dimplex
attr dim_returnset_temperature stateAlias temperature
attr dim_returnset_temperature stateFormat {sprintf("%0.1f", ReadingsVal($name,"state",0))}
attr dim_returnset_temperature updateInterval 00:05:00
</pre>

==== Logfile Betriebsdaten ====
Anlegen eines täglichen Logfile der Betriebsdaten.
<pre>
define filelog_dim_temperature FileLog ./log/filelog_dim_temperature-%W-%d.log
dim_.*._temperature:temperature:.*|dim_.*._pressure:pressure:.*
attr filelog_dim_temperature room Dimplex
</pre>

==== Statistiken ====
Folgender Code legt die Statistiken der Betriebsdaten an
<pre>
define dim_statistics statistics dim_.*._temperature|dim_.*._pressure
attr dim_statistics dayChangeTime 1
attr dim_statistics deltaReadings temperature,pressure
attr dim_statistics minAvgMaxReadings temperature,pressure
attr dim_statistics room Dimplex
attr dim_statistics tendencyReadings temperature,pressure
</pre>

=== Zustände ===
Vorschlag der Namensvergabe für die Zustände. Eine sinnvolle Namensvergabe erleichtert später das Anlegen weiterer Definitionen von zum Beispiel Logfiles, Statistiken oder auch [[readingsGroup]].
{| class="wikitable"
|-
| dim_compressor_output || Verdichter
|-
| dim_ventilator_output || Ventilator
|-
| dim_brinepump_ output || Solepumpe
|-
| dim_circulationpump_output || Heizungsumwälzpumpe M13
|-
| dim_2heatgenerator_output || 2.Wärmeerzeuger
|-
| dim_dhwpump_output || Warmwasserpumpe M18
|-
| dim_auxiliarypump_output || Zusatzpumpe M16
|-
| dim_flangeheater_output || Flanschheizung
|}
Coil Verdichter und passenden HourCounter für Verdichter definieren:<pre>
define dim_compressor_output ModbusCoil 0 41
attr dim_compressor_output IODev HeatPumpServer
attr dim_compressor_output disableRegisterMapping 1
attr dim_compressor_output event-min-interval .*:900
attr dim_compressor_output event-on-change-reading .*
attr dim_compressor_output room Dimplex
attr dim_compressor_output source Coil
attr dim_compressor_output updateInterval 00:01:00

define hourcounter_compressor_output HourCounter dim_compressor_output:on dim_compressor_output:off
attr hourcounter_compressor_output event-min-interval tick.*:0,.*:3600
attr hourcounter_compressor_output event-on-change-reading .*
</pre>Coil Ventilator definieren und passenden HourCounter für Ventilator definieren:<pre>
define dim_ventilator_output ModbusCoil 0 43
attr dim_ventilator_output IODev HeatPumpServer
attr dim_ventilator_output disableRegisterMapping 1
attr dim_ventilator_output event-min-interval .*:900
attr dim_ventilator_output event-on-change-reading .*
attr dim_ventilator_output room Dimplex
attr dim_ventilator_output source Coil
attr dim_ventilator_output updateInterval 00:01:00

define hourcounter_ventilator_output HourCounter dim_ventilator_output:on dim_ventilator_output:off
attr hourcounter_ventilator_output event-min-interval tick.*:0,.*:3600
attr hourcounter_ventilator_output event-on-change-reading .*
</pre>Coil 2.Wärmeerzeuger definieren und passenden HourCounter für 2.Wärmeerzeuger definieren:<pre>
define dim_2heatgenerator_output ModbusCoil 0 44
attr dim_2heatgenerator_output IODev HeatPumpServer
attr dim_2heatgenerator_output disableRegisterMapping 1
attr dim_2heatgenerator_output event-min-interval .*:900
attr dim_2heatgenerator_output event-on-change-reading .*
attr dim_2heatgenerator_output room Dimplex
attr dim_2heatgenerator_output source Coil
attr dim_2heatgenerator_output updateInterval 00:01:00

define hourcounter_2heatgenerator_output HourCounter dim_2heatgenerator_output:on dim_2heatgenerator_output:off
attr hourcounter_2heatgenerator_output event-min-interval tick.*:0,.*:3600
attr hourcounter_2heatgenerator_output event-on-change-reading .*
</pre>Coil Heizungsumwälzpumpe M13 definieren und passenden HourCounter für Heizungsumwälzpumpe M13 definieren:<pre>
define dim_circulationpump_output ModbusCoil 0 45
attr dim_circulationpump_output IODev HeatPumpServer
attr dim_circulationpump_output disableRegisterMapping 1
attr dim_circulationpump_output event-min-interval .*:900
attr dim_circulationpump_output event-on-change-reading .*
attr dim_circulationpump_output room Dimplex
attr dim_circulationpump_output source Coil
attr dim_circulationpump_output updateInterval 00:01:00

define hourcounter_circulationpump_output HourCounter dim_circulationpump_output:on dim_circulationpump_output:off
attr hourcounter_circulationpump_output event-min-interval tick.*:0,.*:3600
attr hourcounter_circulationpump_output event-on-change-reading .*
</pre>Coil Warmwasserpumpe M18 definieren und passenden HourCounter für Warmwasserpumpe M18 definieren:<pre>
define dim_dhwpump_output ModbusCoil 0 46
attr dim_dhwpump_output IODev HeatPumpServer
attr dim_dhwpump_output disableRegisterMapping 1
attr dim_dhwpump_output event-min-interval .*:900
attr dim_dhwpump_output event-on-change-reading .*
attr dim_dhwpump_output room Dimplex
attr dim_dhwpump_output source Coil
attr dim_dhwpump_output updateInterval 00:01:00

define hourcounter_dhwpump_output HourCounter dim_dhwpump_output:on dim_dhwpump_output:off
attr hourcounter_dhwpump_output event-min-interval tick.*:0,.*:3600
attr hourcounter_dhwpump_output event-on-change-reading .*
</pre>Coil Zusatzpumpe M16 definieren und Passenden HourCounter für Zusatzpumpe M16 definieren:<pre>
define dim_auxiliarypump_output ModbusCoil 0 49
attr dim_auxiliarypump_output IODev HeatPumpServer
attr dim_auxiliarypump_output disableRegisterMapping 1
attr dim_auxiliarypump_output event-min-interval .*:900
attr dim_auxiliarypump_output event-on-change-reading .*
attr dim_auxiliarypump_output room Dimplex
attr dim_auxiliarypump_output source Coil
attr dim_auxiliarypump_output updateInterval 00:01:00

define hourcounter_auxiliarypump_output HourCounter dim_auxiliarypump_output:on dim_auxiliarypump_output:off
attr hourcounter_auxiliarypump_output event-min-interval tick.*:0,.*:3600
attr hourcounter_auxiliarypump_output event-on-change-reading .*
</pre>Coil Flanschheizung definieren und passenden HourCounter für Flanschheizung M16 definieren:<pre>
define dim_flangeheater_output ModbusCoil 0 50
attr dim_flangeheater_output IODev HeatPumpServer
attr dim_flangeheater_output disableRegisterMapping 1
attr dim_flangeheater_output event-min-interval .*:900
attr dim_flangeheater_output event-on-change-reading .*
attr dim_flangeheater_output room Dimplex
attr dim_flangeheater_output source Coil
attr dim_flangeheater_output updateInterval 00:01:00

define hourcounter_flangeheater_output HourCounter dim_flangeheater_output:on dim_flangeheater_output:off
attr hourcounter_flangeheater_output event-min-interval tick.*:0,.*:3600
attr hourcounter_flangeheater_output event-on-change-reading .*
</pre>

==== Logfile Zustände ====
Anlegen eines wöchentlichen Logfile der Zustände:
<pre>
define filelog_dim_output_week FileLog ./log/filelog_dim_output_week-%W.log dim_.*._output.*
attr filelog_dim_output_week room Dimplex
</pre>

=== Historie ===
Vorschlag der Namensvergabe für die Historie. Eine sinnvolle Namensvergabe erleichtert später das Anlegen weiterer Definitionen von zum Beispiel Logfiles, Statistiken oder auch [[readingsGroup]].
{| class="wikitable"
|-
| dim_compressor_history || Verdichter
|-
| dim_ventilator_history || Ventilator
|-
| dim_brinepump_history || Solepumpe
|-
| dim_circulationpump_history || Heizungsumwälzpumpe M13
|-
| dim_2heatgenerator_history || 2.Wärmeerzeuger
|-
| dim_dhwpump_history || Warmwasserpumpe M18
|-
| dim_auxiliarypump_history || Zusatzpumpe M16
|-
| dim_flangeheater_history || Flanschheizung
|}
Register Historie Verdichter definieren:<pre>
define dim_compressor_history ModbusRegister 0 72
attr dim_compressor_history IODev HeatPumpServer
attr dim_compressor_history alignUpdateInterval 00:01:00
attr dim_compressor_history event-on-change-reading .*
attr dim_compressor_history plcDataType INT
attr dim_compressor_history registerType Holding
attr dim_compressor_history room Dimplex
attr dim_compressor_history updateInterval 01:00:00
</pre>Register Historie Ventilator definieren:<pre>
define dim_ventilator_history ModbusRegister 0 74
attr dim_ventilator_history IODev HeatPumpServer
attr dim_ventilator_history alignUpdateInterval 00:01:00
attr dim_ventilator_history event-on-change-reading .*
attr dim_ventilator_history plcDataType INT
attr dim_ventilator_history registerType Holding
attr dim_ventilator_history room Dimplex
attr dim_ventilator_history updateInterval 01:00:00
</pre>Register Historie 2.Wärmeerzeuger definieren:<pre>
define dim_2heatgenerator_history ModbusRegister 0 75
attr dim_2heatgenerator_history IODev HeatPumpServer
attr dim_2heatgenerator_history alignUpdateInterval 00:01:00
attr dim_2heatgenerator_history event-on-change-reading .*
attr dim_2heatgenerator_history plcDataType INT
attr dim_2heatgenerator_history registerType Holding
attr dim_2heatgenerator_history room Dimplex
attr dim_2heatgenerator_history updateInterval 01:00:00
</pre>Register Historie Heizungsumwälzpumpe M13 definieren:<pre>
define dim_circulationpump_history ModbusRegister 0 76
attr dim_circulationpump_history IODev HeatPumpServer
attr dim_circulationpump_history alignUpdateInterval 00:01:00
attr dim_circulationpump_history event-on-change-reading .*
attr dim_circulationpump_history plcDataType INT
attr dim_circulationpump_history registerType Holding
attr dim_circulationpump_history room Dimplex
attr dim_circulationpump_history updateInterval 01:00:00
</pre>Register Historie Warmwasserpumpe M18 definieren:<pre>
define dim_dhwpump_history ModbusRegister 0 77
attr dim_dhwpump_history IODev HeatPumpServer
attr dim_dhwpump_history alignUpdateInterval 00:01:00
attr dim_dhwpump_history event-on-change-reading .*
attr dim_dhwpump_history plcDataType INT
attr dim_dhwpump_history registerType Holding
attr dim_dhwpump_history room Dimplex
attr dim_dhwpump_history updateInterval 01:00:00
</pre>Register Historie Flanschheizung definieren:<pre>
define dim_flangeheater_history ModbusRegister 0 78
attr dim_flangeheater_history IODev HeatPumpServer
attr dim_flangeheater_history alignUpdateInterval 00:01:00
attr dim_flangeheater_history event-on-change-reading .*
attr dim_flangeheater_history plcDataType INT
attr dim_flangeheater_history registerType Holding
attr dim_flangeheater_history room Dimplex
attr dim_flangeheater_history updateInterval 01:00:00
</pre>
==== Logfile Historie ====
Anlegen eines monatlichen Logfile für die Historischen Daten:
<pre>
define filelog_dim_history_month FileLog ./log/filelog_dim_history_month-%m.log dim_.*._history.*
attr filelog_dim_history_month room Dimplex
</pre>

==== Wärmemengen ====
Laut Definition aus dem [http://www.dimplex.de/wiki Dimplex-Wiki] werden die Wärmemengen für Heizen, Warmwasser und Schwimmbad aus 3 Register-Adressen zusammengesetzt. Im Nachfolgenden Code-Beispiel wird dies entsprechend dargestellt. Dabei wird jeweils im ersten Register ein neues userReading mit der Darstellung der Gesamtwärmemenge angelegt.

Wärmemenge Heizen definieren:
<pre>
define dim_heating1_thermalenergy ModbusRegister 0 5096
attr dim_heating1_thermalenergy IODev HeatPumpServer
attr dim_heating1_thermalenergy event-on-change-reading .*
attr dim_heating1_thermalenergy plcDataType INT
attr dim_heating1_thermalenergy registerType Holding
attr dim_heating1_thermalenergy room Dimplex
attr dim_heating1_thermalenergy updateInterval 00:15:00
attr dim_heating1_thermalenergy userReadings heatingthermalenergy {\
((ReadingsVal("dim_heating3_thermalenergy","state",0)*100000000)+\
(ReadingsVal("dim_heating2_thermalenergy","state",0)*10000)+\
(ReadingsVal("dim_heating1_thermalenergy","state",0)))}

define dim_heating2_thermalenergy ModbusRegister 0 5097
attr dim_heating2_thermalenergy IODev HeatPumpServer
attr dim_heating2_thermalenergy event-on-change-reading .*
attr dim_heating2_thermalenergy plcDataType INT
attr dim_heating2_thermalenergy registerType Holding
attr dim_heating2_thermalenergy room Dimplex
attr dim_heating2_thermalenergy updateInterval 00:15:00

define dim_heating3_thermalenergy ModbusRegister 0 5098
attr dim_heating3_thermalenergy IODev HeatPumpServer
attr dim_heating3_thermalenergy event-on-change-reading .*
attr dim_heating3_thermalenergy plcDataType INT
attr dim_heating3_thermalenergy registerType Holding
attr dim_heating3_thermalenergy room Dimplex
attr dim_heating3_thermalenergy updateInterval 00:15:00
</pre>Wärmemenge Warmwasser definieren:<pre>
define dim_dhw1_thermalenergy ModbusRegister 0 5099
attr dim_dhw1_thermalenergy IODev HeatPumpServer
attr dim_dhw1_thermalenergy event-on-change-reading .*
attr dim_dhw1_thermalenergy plcDataType INT
attr dim_dhw1_thermalenergy registerType Holding
attr dim_dhw1_thermalenergy room Dimplex
attr dim_dhw1_thermalenergy updateInterval 00:15:00
attr dim_dhw1_thermalenergy userReadings dhwthermalenergy {\
((ReadingsVal("dim_dhw3_thermalenergy","state",0)*100000000)+\
(ReadingsVal("dim_dhw2_thermalenergy","state",0)*10000)+\
(ReadingsVal("dim_dhw1_thermalenergy","state",0)))}

define dim_dhw2_thermalenergy ModbusRegister 0 5100
attr dim_dhw2_thermalenergy IODev HeatPumpServer
attr dim_dhw2_thermalenergy event-on-change-reading .*
attr dim_dhw2_thermalenergy plcDataType INT
attr dim_dhw2_thermalenergy registerType Holding
attr dim_dhw2_thermalenergy room Dimplex
attr dim_dhw2_thermalenergy updateInterval 00:15:00

define dim_dhw3_thermalenergy ModbusRegister 0 5101
attr dim_dhw3_thermalenergy IODev HeatPumpServer
attr dim_dhw3_thermalenergy event-on-change-reading .*
attr dim_dhw3_thermalenergy plcDataType INT
attr dim_dhw3_thermalenergy registerType Holding
attr dim_dhw3_thermalenergy room Dimplex
attr dim_dhw3_thermalenergy updateInterval 00:15:00
</pre>
==== Umweltenergie ====
Als Umweltenergie wird die zugeführte Kälteenergie aus der Umwelt (Luft/Erdreich) bezeichnet. Das Auslesen dieser Werte über die Schnittstelle ist erst ab einem neueren Softwarestand möglich. Die Differenz der gesamten Wärmemenge und der Umweltenergie entspricht in etwa der Energie des Verdichters.

Umweltenergie/entzogene Kälteenergie definieren:
<pre>
define dim_environment1_energy ModbusRegister 0 5127
attr dim_environment1_energy IODev HeatPumpServer
attr dim_environment1_energy event-on-change-reading .*
attr dim_environment1_energy plcDataType INT
attr dim_environment1_energy registerType Holding
attr dim_environment1_energy room Dimplex
attr dim_environment1_energy updateInterval 00:15:00
attr dim_environment1_energy userReadings environmentenergy {\
((ReadingsVal("dim_environment3_energy","state",0)*100000000)+\
(ReadingsVal("dim_environment2_energy","state",0)*10000)+\
(ReadingsVal("dim_environment1_energy","state",0)))}

define dim_environment2_energy ModbusRegister 0 5128
attr dim_environment2_energy IODev HeatPumpServer
attr dim_environment2_energy event-on-change-reading .*
attr dim_environment2_energy plcDataType INT
attr dim_environment2_energy registerType Holding
attr dim_environment2_energy room Dimplex
attr dim_environment2_energy updateInterval 00:15:00

define dim_environment3_energy ModbusRegister 0 5129
attr dim_environment3_energy IODev HeatPumpServer
attr dim_environment3_energy event-on-change-reading .*
attr dim_environment3_energy plcDataType INT
attr dim_environment3_energy registerType Holding
attr dim_environment3_energy room Dimplex
attr dim_environment3_energy updateInterval 00:15:00
</pre>

==== Logfile Wärmemengen ====
Anlegen eines jährlichen Logfile der Wärmemengen.
<pre>
define filelog_dim_thermalenergy_year FileLog ./log/filelog_dim_thermalenergy_year-%y.log dim_heating1_thermalenergy:heatingthermalenergy:.*|dim_heating1_thermalenergy:heatingthermalenergy:.*
attr filelog_dim_thermalenergy_year room Dimplex
</pre>

=== Meldungen ===
[[Bild:dimplex_rh_status_heatpump.jpg|thumb|right|Beispiel Meldungen]]
Eine sinnvolle Anzeige sind die Meldungen (Status, Sperre, Störung) der Wärmepumpe. Im nachfolgenden Beispiel werden die Meldungen mit dem Hilfsmodul [[readingsHistory]] dargestellt. Die Definitionen der Meldungen beziehen sich auf die im [http://www.dimplex.de/wiki Dimplex-Wiki] beschriebene L-Software. Bei abweichenden Softwareständen müssen die Register sowie die Texte angepasst werden.

Register Statusmeldung definieren:

<pre>
define dim_status_heatpump ModbusRegister 0 103
attr dim_status_heatpump IODev HeatPumpServer
attr dim_status_heatpump event-on-change-reading .*
attr dim_status_heatpump plcDataType INT
attr dim_status_heatpump registerType Holding
attr dim_status_heatpump room Dimplex
attr dim_status_heatpump updateInterval 00:00:10
attr dim_status_heatpump userReadings Status {\
((ReadingsVal($name,"state","") == 1) ? "Aus":\
(ReadingsVal($name,"state","") == 4) ? "Warmwasser":\
(ReadingsVal($name,"state","") == 10) ? "Abtauen":\
(ReadingsVal($name,"state","") == 11) ? "Durchflussüberwachnung":"")}

</pre>Register Sperrmeldunge definieren:<pre>
define dim_block_heatpump ModbusRegister 0 104
attr dim_block_heatpump IODev HeatPumpServer
attr dim_block_heatpump event-on-change-reading .*
attr dim_block_heatpump plcDataType INT
attr dim_block_heatpump registerType Holding
attr dim_block_heatpump room Dimplex
attr dim_block_heatpump updateInterval 00:00:10
attr dim_block_heatpump userReadings Sperre {\
((ReadingsVal($name,"state","") == 0) ? "":\
(ReadingsVal($name,"state","") == 7) ? "Systemkontrolle":\
(ReadingsVal($name,"state","") == 9) ? "Pumpenvorlauf":\
(ReadingsVal($name,"state","") == 10) ? "Mindeststandzeit":\
(ReadingsVal($name,"state","") == 11) ? "Netzbelastung":\
(ReadingsVal($name,"state","") == 12) ? "Schaltspielsperre":\
(ReadingsVal($name,"state","") == 15) ? "EVU":"")}
</pre>Register Störmeldungen definieren:<pre>
define dim_fault_heatpump ModbusRegister 0 105
attr dim_fault_heatpump IODev HeatPumpServer
attr dim_fault_heatpump event-on-change-reading .*
attr dim_fault_heatpump plcDataType INT
attr dim_fault_heatpump registerType Holding
attr dim_fault_heatpump room Dimplex
attr dim_fault_heatpump updateInterval 00:01:00
attr dim_fault_heatpump userReadings Störung {\
((ReadingsVal($name,"state","") == 0) ? "":\
(ReadingsVal($name,"state","") == 6) ? "Elektronisches Ex.Ventil":\
(ReadingsVal($name,"state","") == 15) ? "Sensorik":\
(ReadingsVal($name,"state","") == 19) ? "!Primärkreis":\
(ReadingsVal($name,"state","") == 22) ? "!Warmwasser":\
(ReadingsVal($name,"state","") == 23) ? "!Last Verdichter":\
(ReadingsVal($name,"state","") == 24) ? "!Codierung":\
(ReadingsVal($name,"state","") == 25) ? "!Niederdruck":\
(ReadingsVal($name,"state","") == 26) ? "!Frostschutz":\
(ReadingsVal($name,"state","") == 29) ? "!Temperatur Differenz":\
(ReadingsVal($name,"state","") == 31) ? "!Durchfluss":"")}
</pre>
==== Anzeige der Meldungen ====
readingsHistory definieren:<pre>
define rh_dim_status_heatpump readingsHistory dim_status_heatpump:Status dim_block_heatpump:Sperre dim_fault_heatpump:Störung
attr rh_dim_status_heatpump alias Status
attr rh_dim_status_heatpump mapping {'dim_status_heatpump' => '', 'dim_block_heatpump' => '', 'dim_fault_heatpump' => ''}
attr rh_dim_status_heatpump nohtml 1
attr rh_dim_status_heatpump room Dimplex
attr rh_dim_status_heatpump rows 20
attr rh_dim_status_heatpump timestampFormat %b %a %R
</pre>

== Plotbeispiel ==
=== Temperaturen ===
<pre>
# Created by FHEM/98_SVG.pm, 2015-05-11 21:40:00
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 ytics y2tics
set ylabel ""
set y2label "Temperatur (°C)"

#filelog_dim_temperature_week 4:dim_outdoor_temperature.*::
#filelog_dim_temperature_week 4:dim_room_temperature.*::
#filelog_dim_temperature_week 4:dim_return_temperature.*::
#filelog_dim_temperature_week 4:dim_returnset_temperature.*::
#filelog_dim_temperature_week 4:dim_dhw_temperature.*::
#filelog_dim_temperature_week 4:dim_flow_temperature.*::
#filelog_dim_temperature_week 4:dim_brine_temperature.*::

plot "<IN>" using 1:2 axes x1y2 title 'AT' ls l7 lw 1 with lines,\
"<IN>" using 1:2 axes x1y2 title 'RT' ls l1 lw 1 with lines,\
"<IN>" using 1:2 axes x1y2 title 'RL' ls l2 lw 1 with lines,\
"<IN>" using 1:2 axes x1y2 title 'RLS' ls l3 lw 1 with lines,\
"<IN>" using 1:2 axes x1y2 title 'WWT' ls l4 lw 1 with lines,\
"<IN>" using 1:2 axes x1y2 title 'VLT' ls l0 lw 1 with lines,\
"<IN>" using 1:2 axes x1y2 title 'SOL' ls l6 lw 1 with lines
</pre>

=== Ausgänge ===
<pre>
# Created by FHEM/98_SVG.pm, 2015-05-11 21:45:00
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 ''
set ytics ("An" -1, "Aus" -2, "An" -5, "Aus" -6, "An" -9, "Aus" -10, "An" -13, "Aus" -14)
set y2tics ("An" 1, "Aus" 0, "An" -3, "Aus" -4, "An" -7, "Aus" -8, "An" -11, "Aus" -12)
set grid
set ylabel ""
set y2label "Digital"
set yrange [-16:2]
set y2range [-16:2]

#FileLog 3:dim_compressor_output.*::$fld[2]=~"on"?1:0
#FileLog 3:dim_ventilator_output.*::$fld[2]=~"on"?-1:-2
#FileLog 3:dim_2heatgenerator_output.*::$fld[2]=~"on"?-3:-4
#FileLog 3:dim_circulationpump_output.*::$fld[2]=~"on"?-5:-6
#FileLog 3:dim_dhwpump_output.*::$fld[2]=~"on"?-7:-8
#FileLog 3:dim_auxiliarypump_output.*::$fld[2]=~"on"?-9:-10
#FileLog 3:dim_solarpump_output.*::$fld[2]=~"on"?-11:-12
#FileLog 3:dim_flangeheater_output.*::$fld[2]=~"on"?-13:-14

plot "<IN>" using 1:2 axes x1y2 title 'Vd' ls l7 lw 1.5 with steps,\
"<IN>" using 1:2 axes x1y2 title 'Ve' ls l6 lw 1.5 with steps,\
"<IN>" using 1:2 axes x1y2 title '2.We' ls l5 lw 1.5 with steps,\
"<IN>" using 1:2 axes x1y2 title 'Hub' ls l4 lw 1.5 with steps,\
"<IN>" using 1:2 axes x1y2 title 'Wup' ls l3 lw 1 with steps,\
"<IN>" using 1:2 axes x1y2 title 'Zup' ls l0 lw 1.5 with steps,\
"<IN>" using 1:2 axes x1y2 title 'Sol' ls l2 lw 1.5 with steps,\
"<IN>" using 1:2 axes x1y2 title 'Flh' ls l7 lw 1.5 with steps
</pre>

[[Bild:dimplex_hp_graph.jpg|thumb|right|Plotbeispiel]]
Im nebenstehenden Plotbeispiel werde die Temperaturen (Analogwerte) sowie die Ausgänge (Digitalwerte) dargestellt. Im einzelnen sind die Kurven für die

* Aussen- (AT)
* Raum- (RT)
* Rücklauf- (RL)
* Rücklaufsoll- (RLS)
* Warmwasser- (WWT) und
* Vorlauftemperatur (VLT)

sowie die Ausgänge für

* Verdichter 1 (Vd)
* Ventilator (Ve)
* 2.Wärmeerzeuger (2We)
* Heizungsumwälzpumpe (Hup)
* Warmwasserumwälzpumpe (Wup) und
* Zusatzumwälzpumpe (Zup)

enthalten.

= Kontakt =
Weitere Fragen, Wünsche und Anregungen bitte im entsprechenden {{Link2Forum|Topic=33086|LinkText=Forenthread zum Wiki-Artikel "Dimplex Wärmepumpenmanager"}} zur Diskussion stellen.

Offene Punkte:
- Darstellung der Werte in einer readingsGroup
- Zugriff auf Zeitfunktionen mit Lesen und Schreiben

[[Kategorie:HOWTOS]]
[[Kategorie:Heizungssteuerung]]
[[Kategorie:Other Components]]

Dimplex Wärmepumpenmanager

2025-03-30T13:55:16Z

TomLee: Kommentare aus den Codebeispielen entfernt. Raw-Code Anpassungen.

Mit der NWPM-Erweiterung ist es möglich, den Dimplex Wärmepumpenmanager in ein Hausnetzwerk einzubinden. Durch die Einbindung der NWPM-Erweiterung ist es ebenfalls möglich, die zur Verfügung gestellten Werte vom Wärmepumpenmanager mittels ModbusTCP in FHEM zu übernehmen, anzuzeigen und grafisch darzustellen.

== Voraussetzung ==
Die Anbindung des Dimplex Wärmepumpenmanager an FHEM erfolgt mittels NWPM-Erweiterung und der aktuellen FHEM Installation. Weiterhin werden die zur Verfügung stehenden Module:

* 36_ModbusTCPServer.pm
* 37_ModbusCoil.pm
* 37_ModbusRegister.pm

genutzt. Getestet wurde der Zugriff auf einem BeagleBone Black mit der [[BeagleBone Black|hier beschriebenen]] Debian Installation.

== Installation ==
Die oben aufgeführten Module sind notwendig und müssen nachinstalliert werden. Zum Zeitpunkt der Erstellung dieser Dokumentation (31.1.2015) sind diese noch nicht offiziell in FHEM enthalten und werden auch nicht mittels Update verteilt. Die Module werden mit dem Befehl:
<pre>
update all https://raw.githubusercontent.com/ChrisD70/FHEM-Modules/master/autoupdate/mb/controls_modbus.txt
</pre>
über die FHEM Befehlszeile installiert und anschließend
<pre>
reload 36_ModbusTCPServer.pm
reload 37_ModbusCoil.pm
reload 37_ModbusRegister.pm
</pre>
mit einem Reload geladen.
== Benutzung ==
=== Anlegen der ModbusTCPServer Verbindung ===
Wie im nachfolgenden angegeben muss zunächst eine ModbusTCPServer Verbindung hergestellt werden. Die angegebene IP-Adresse muss durch die IP-Adresse der Wärmepumpe ersetzt werden.
<pre>
########################################################
## ModbusTCPServer definieren
########################################################
define HeatPumpServer ModbusTCPServer 192.168.1.150
attr HeatPumpServer verbose 2
</pre>
Ein erfolgreicher Verbindungsaufbau wird mit einem „ok“ im State gekennzeichnet.

=== Modbus-Register/Coil Adressen definieren ===
Im nachfolgendem Beispiel wird anhand der Außentemperatur die Adressdefinition erklärt.
<pre>
define dim_outdoor_temperature ModbusRegister 0 1
attr dim_outdoor_temperature IODev HeatPumpServer
attr dim_outdoor_temperature conversion 0.1:0
attr dim_outdoor_temperature event-min-interval .*:900
attr dim_outdoor_temperature event-on-change-reading .*
attr dim_outdoor_temperature plcDataType INT
attr dim_outdoor_temperature registerType Holding
attr dim_outdoor_temperature room Dimplex
attr dim_outdoor_temperature stateAlias temperature
attr dim_outdoor_temperature stateFormat {sprintf("%0.1f", ReadingsVal($name,"state",0))}
attr dim_outdoor_temperature updateInterval 00:10:00
</pre>
Erklärung:
{| class="wikitable"
|+ Erläuterungen zur Adressdefinition
|-
! Attribut !! Erläuterungen
|-
| ModbusRegister 0 1 || 0 Device Adresse, in der Regel bei ModbusTCP immer 0
|-
| ModbusRegister 0 1 || 1 Register Adresse, wird unter www.dimplex.de/wiki → ModbusTCP → Spalten IP zur Verfügung gestellt
|-
| IODev || Verwendeter und zuvor angelegter ModbusTCPServer
|-
| conversion || eine gegebenenfalls notwendige Konvertierung des übermittelten Values
|-
| PlcDataType || Ermögliche automatische Interpretation der ankommenden Daten
|-
| stateAlias || es wird ein zusätzliches Reading erzeugt, um zum Beispiel das Statistic-Modul nutzen zu können, stateAlias ist eine echte Kopie von "state"
|-
| updateInterval || Intervall des Abfragezyklus (z.B. 00:10:00 Minuten)
|-
|}

=== Betriebsdaten ===
Vorschlag der Namensvergabe für die Betriebsdaten. Eine sinnvolle Namensvergabe erleichtert später das Anlegen weiterer Definitionen von zum Beispiel Logfiles, Statistiken oder auch [[readingsGroup]].
{| class="wikitable"
|-
| dim_outdoor_temperature || Außentemperatur
|-
| dim_flow_temperature || Vorlauftemperatur
|-
| dim_return_temperature || Rücklauftemperatur
|-
| dim_returnset_temperature || Rücklaufsolltemperatur
|-
| dim_room_temperature || Raumtemperatur
|-
| dim_dhw_temperature || Warmwassertemperatur
|-
| dim_dhwset_temperature || Warmwassersolltemperatur
|-
| dim_brine_temperature || Soletemperatur
|-
| dim_high_pressure || Hochdruck
|-
| dim_low_pressure || Niederdruck
|}
Register Warmwassertemperatur definieren:<pre>
define dim_dhw_temperature ModbusRegister 0 3
attr dim_dhw_temperature IODev HeatPumpServer
attr dim_dhw_temperature conversion 0.1:0
attr dim_dhw_temperature event-min-interval .*:900
attr dim_dhw_temperature event-on-change-reading .*
attr dim_dhw_temperature plcDataType INT
attr dim_dhw_temperature registerType Holding
attr dim_dhw_temperature room Dimplex
attr dim_dhw_temperature stateAlias temperature
attr dim_dhw_temperature stateFormat {sprintf("%0.1f", ReadingsVal($name,"state",0))}
attr dim_dhw_temperature updateInterval 00:01:00
</pre>Register Vorlauftemperatur definieren:<pre>
define dim_flow_temperature ModbusRegister 0 5
attr dim_flow_temperature IODev HeatPumpServer
attr dim_flow_temperature conversion 0.1:0
attr dim_flow_temperature event-min-interval .*:900
attr dim_flow_temperature event-on-change-reading .*
attr dim_flow_temperature plcDataType INT
attr dim_flow_temperature registerType Holding
attr dim_flow_temperature room Dimplex
attr dim_flow_temperature stateAlias temperature
attr dim_flow_temperature stateFormat {sprintf("%0.1f", ReadingsVal($name,"state",0))}
attr dim_flow_temperature updateInterval 00:01:00
</pre>Register Rücklauftemperatur definieren:<pre>
define dim_return_temperature ModbusRegister 0 2
attr dim_return_temperature IODev HeatPumpServer
attr dim_return_temperature conversion 0.1:0
attr dim_return_temperature event-min-interval .*:900
attr dim_return_temperature event-on-change-reading .*
attr dim_return_temperature plcDataType INT
attr dim_return_temperature registerType Holding
attr dim_return_temperature room Dimplex
attr dim_return_temperature stateAlias temperature
attr dim_return_temperature stateFormat {sprintf("%0.1f", ReadingsVal($name,"state",0))}
attr dim_return_temperature updateInterval 00:01:00
</pre>Register Rücklaufsolltemperatur definieren:<pre>
define dim_returnset_temperature ModbusRegister 0 53
attr dim_returnset_temperature IODev HeatPumpServer
attr dim_returnset_temperature conversion 0.1:0
attr dim_returnset_temperature event-min-interval .*:900
attr dim_returnset_temperature event-on-change-reading .*
attr dim_returnset_temperature plcDataType INT
attr dim_returnset_temperature registerType Holding
attr dim_returnset_temperature room Dimplex
attr dim_returnset_temperature stateAlias temperature
attr dim_returnset_temperature stateFormat {sprintf("%0.1f", ReadingsVal($name,"state",0))}
attr dim_returnset_temperature updateInterval 00:05:00
</pre>

==== Logfile Betriebsdaten ====
Anlegen eines täglichen Logfile der Betriebsdaten.
<pre>
define filelog_dim_temperature FileLog ./log/filelog_dim_temperature-%W-%d.log
dim_.*._temperature:temperature:.*|dim_.*._pressure:pressure:.*
attr filelog_dim_temperature room Dimplex
</pre>

==== Statistiken ====
Folgender Code legt die Statistiken der Betriebsdaten an
<pre>
define dim_statistics statistics dim_.*._temperature|dim_.*._pressure
attr dim_statistics dayChangeTime 1
attr dim_statistics deltaReadings temperature,pressure
attr dim_statistics minAvgMaxReadings temperature,pressure
attr dim_statistics room Dimplex
attr dim_statistics tendencyReadings temperature,pressure
</pre>

=== Zustände ===
Vorschlag der Namensvergabe für die Zustände. Eine sinnvolle Namensvergabe erleichtert später das Anlegen weiterer Definitionen von zum Beispiel Logfiles, Statistiken oder auch [[readingsGroup]].
{| class="wikitable"
|-
| dim_compressor_output || Verdichter
|-
| dim_ventilator_output || Ventilator
|-
| dim_brinepump_ output || Solepumpe
|-
| dim_circulationpump_output || Heizungsumwälzpumpe M13
|-
| dim_2heatgenerator_output || 2.Wärmeerzeuger
|-
| dim_dhwpump_output || Warmwasserpumpe M18
|-
| dim_auxiliarypump_output || Zusatzpumpe M16
|-
| dim_flangeheater_output || Flanschheizung
|}
Coil Verdichter und passenden HourCounter für Verdichter definieren:<pre>
define dim_compressor_output ModbusCoil 0 41
attr dim_compressor_output IODev HeatPumpServer
attr dim_compressor_output disableRegisterMapping 1
attr dim_compressor_output event-min-interval .*:900
attr dim_compressor_output event-on-change-reading .*
attr dim_compressor_output room Dimplex
attr dim_compressor_output source Coil
attr dim_compressor_output updateInterval 00:01:00

define hourcounter_compressor_output HourCounter dim_compressor_output:on dim_compressor_output:off
attr hourcounter_compressor_output event-min-interval tick.*:0,.*:3600
attr hourcounter_compressor_output event-on-change-reading .*
</pre>Coil Ventilator definieren und passenden HourCounter für Ventilator definieren:<pre>
define dim_ventilator_output ModbusCoil 0 43
attr dim_ventilator_output IODev HeatPumpServer
attr dim_ventilator_output disableRegisterMapping 1
attr dim_ventilator_output event-min-interval .*:900
attr dim_ventilator_output event-on-change-reading .*
attr dim_ventilator_output room Dimplex
attr dim_ventilator_output source Coil
attr dim_ventilator_output updateInterval 00:01:00

define hourcounter_ventilator_output HourCounter dim_ventilator_output:on dim_ventilator_output:off
attr hourcounter_ventilator_output event-min-interval tick.*:0,.*:3600
attr hourcounter_ventilator_output event-on-change-reading .*
</pre>Coil 2.Wärmeerzeuger definieren und passenden HourCounter für 2.Wärmeerzeuger definieren:<pre>
define dim_2heatgenerator_output ModbusCoil 0 44
attr dim_2heatgenerator_output IODev HeatPumpServer
attr dim_2heatgenerator_output disableRegisterMapping 1
attr dim_2heatgenerator_output event-min-interval .*:900
attr dim_2heatgenerator_output event-on-change-reading .*
attr dim_2heatgenerator_output room Dimplex
attr dim_2heatgenerator_output source Coil
attr dim_2heatgenerator_output updateInterval 00:01:00

define hourcounter_2heatgenerator_output HourCounter dim_2heatgenerator_output:on dim_2heatgenerator_output:off
attr hourcounter_2heatgenerator_output event-min-interval tick.*:0,.*:3600
attr hourcounter_2heatgenerator_output event-on-change-reading .*
</pre>Coil Heizungsumwälzpumpe M13 definieren und passenden HourCounter für Heizungsumwälzpumpe M13 definieren:<pre>
define dim_circulationpump_output ModbusCoil 0 45
attr dim_circulationpump_output IODev HeatPumpServer
attr dim_circulationpump_output disableRegisterMapping 1
attr dim_circulationpump_output event-min-interval .*:900
attr dim_circulationpump_output event-on-change-reading .*
attr dim_circulationpump_output room Dimplex
attr dim_circulationpump_output source Coil
attr dim_circulationpump_output updateInterval 00:01:00

define hourcounter_circulationpump_output HourCounter dim_circulationpump_output:on dim_circulationpump_output:off
attr hourcounter_circulationpump_output event-min-interval tick.*:0,.*:3600
attr hourcounter_circulationpump_output event-on-change-reading .*
</pre>Coil Warmwasserpumpe M18 definieren und passenden HourCounter für Warmwasserpumpe M18 definieren:<pre>
define dim_dhwpump_output ModbusCoil 0 46
attr dim_dhwpump_output IODev HeatPumpServer
attr dim_dhwpump_output disableRegisterMapping 1
attr dim_dhwpump_output event-min-interval .*:900
attr dim_dhwpump_output event-on-change-reading .*
attr dim_dhwpump_output room Dimplex
attr dim_dhwpump_output source Coil
attr dim_dhwpump_output updateInterval 00:01:00

define hourcounter_dhwpump_output HourCounter dim_dhwpump_output:on dim_dhwpump_output:off
attr hourcounter_dhwpump_output event-min-interval tick.*:0,.*:3600
attr hourcounter_dhwpump_output event-on-change-reading .*
</pre>Coil Zusatzpumpe M16 definieren und Passenden HourCounter für Zusatzpumpe M16 definieren:<pre>
define dim_auxiliarypump_output ModbusCoil 0 49
attr dim_auxiliarypump_output IODev HeatPumpServer
attr dim_auxiliarypump_output disableRegisterMapping 1
attr dim_auxiliarypump_output event-min-interval .*:900
attr dim_auxiliarypump_output event-on-change-reading .*
attr dim_auxiliarypump_output room Dimplex
attr dim_auxiliarypump_output source Coil
attr dim_auxiliarypump_output updateInterval 00:01:00

define hourcounter_auxiliarypump_output HourCounter dim_auxiliarypump_output:on dim_auxiliarypump_output:off
attr hourcounter_auxiliarypump_output event-min-interval tick.*:0,.*:3600
attr hourcounter_auxiliarypump_output event-on-change-reading .*
</pre>Coil Flanschheizung definieren und passenden HourCounter für Flanschheizung M16 definieren:<pre>
define dim_flangeheater_output ModbusCoil 0 50
attr dim_flangeheater_output IODev HeatPumpServer
attr dim_flangeheater_output disableRegisterMapping 1
attr dim_flangeheater_output event-min-interval .*:900
attr dim_flangeheater_output event-on-change-reading .*
attr dim_flangeheater_output room Dimplex
attr dim_flangeheater_output source Coil
attr dim_flangeheater_output updateInterval 00:01:00

define hourcounter_flangeheater_output HourCounter dim_flangeheater_output:on dim_flangeheater_output:off
attr hourcounter_flangeheater_output event-min-interval tick.*:0,.*:3600
attr hourcounter_flangeheater_output event-on-change-reading .*
</pre>

==== Logfile Zustände ====
Anlegen eines wöchentlichen Logfile der Zustände:
<pre>
define filelog_dim_output_week FileLog ./log/filelog_dim_output_week-%W.log dim_.*._output.*
attr filelog_dim_output_week room Dimplex
</pre>

=== Historie ===
Vorschlag der Namensvergabe für die Historie. Eine sinnvolle Namensvergabe erleichtert später das Anlegen weiterer Definitionen von zum Beispiel Logfiles, Statistiken oder auch [[readingsGroup]].
{| class="wikitable"
|-
| dim_compressor_history || Verdichter
|-
| dim_ventilator_history || Ventilator
|-
| dim_brinepump_history || Solepumpe
|-
| dim_circulationpump_history || Heizungsumwälzpumpe M13
|-
| dim_2heatgenerator_history || 2.Wärmeerzeuger
|-
| dim_dhwpump_history || Warmwasserpumpe M18
|-
| dim_auxiliarypump_history || Zusatzpumpe M16
|-
| dim_flangeheater_history || Flanschheizung
|}
Register Historie Verdichter definieren:<pre>
define dim_compressor_history ModbusRegister 0 72
attr dim_compressor_history IODev HeatPumpServer
attr dim_compressor_history alignUpdateInterval 00:01:00
attr dim_compressor_history event-on-change-reading .*
attr dim_compressor_history plcDataType INT
attr dim_compressor_history registerType Holding
attr dim_compressor_history room Dimplex
attr dim_compressor_history updateInterval 01:00:00
</pre>Register Historie Ventilator definieren:<pre>
define dim_ventilator_history ModbusRegister 0 74
attr dim_ventilator_history IODev HeatPumpServer
attr dim_ventilator_history alignUpdateInterval 00:01:00
attr dim_ventilator_history event-on-change-reading .*
attr dim_ventilator_history plcDataType INT
attr dim_ventilator_history registerType Holding
attr dim_ventilator_history room Dimplex
attr dim_ventilator_history updateInterval 01:00:00
</pre>Register Historie 2.Wärmeerzeuger definieren:<pre>
define dim_2heatgenerator_history ModbusRegister 0 75
attr dim_2heatgenerator_history IODev HeatPumpServer
attr dim_2heatgenerator_history alignUpdateInterval 00:01:00
attr dim_2heatgenerator_history event-on-change-reading .*
attr dim_2heatgenerator_history plcDataType INT
attr dim_2heatgenerator_history registerType Holding
attr dim_2heatgenerator_history room Dimplex
attr dim_2heatgenerator_history updateInterval 01:00:00
</pre>Register Historie Heizungsumwälzpumpe M13 definieren:<pre>
define dim_circulationpump_history ModbusRegister 0 76
attr dim_circulationpump_history IODev HeatPumpServer
attr dim_circulationpump_history alignUpdateInterval 00:01:00
attr dim_circulationpump_history event-on-change-reading .*
attr dim_circulationpump_history plcDataType INT
attr dim_circulationpump_history registerType Holding
attr dim_circulationpump_history room Dimplex
attr dim_circulationpump_history updateInterval 01:00:00
</pre>Register Historie Warmwasserpumpe M18 definieren:<pre>
define dim_dhwpump_history ModbusRegister 0 77
attr dim_dhwpump_history IODev HeatPumpServer
attr dim_dhwpump_history alignUpdateInterval 00:01:00
attr dim_dhwpump_history event-on-change-reading .*
attr dim_dhwpump_history plcDataType INT
attr dim_dhwpump_history registerType Holding
attr dim_dhwpump_history room Dimplex
attr dim_dhwpump_history updateInterval 01:00:00
</pre>Register Historie Flanschheizung definieren:<pre>
define dim_flangeheater_history ModbusRegister 0 78
attr dim_flangeheater_history IODev HeatPumpServer
attr dim_flangeheater_history alignUpdateInterval 00:01:00
attr dim_flangeheater_history event-on-change-reading .*
attr dim_flangeheater_history plcDataType INT
attr dim_flangeheater_history registerType Holding
attr dim_flangeheater_history room Dimplex
attr dim_flangeheater_history updateInterval 01:00:00
</pre>
==== Logfile Historie ====
Anlegen eines monatlichen Logfile für die Historischen Daten:
<pre>
define filelog_dim_history_month FileLog ./log/filelog_dim_history_month-%m.log dim_.*._history.*
attr filelog_dim_history_month room Dimplex
</pre>

==== Wärmemengen ====
Laut Definition aus dem [http://www.dimplex.de/wiki Dimplex-Wiki] werden die Wärmemengen für Heizen, Warmwasser und Schwimmbad aus 3 Register-Adressen zusammengesetzt. Im Nachfolgenden Code-Beispiel wird dies entsprechend dargestellt. Dabei wird jeweils im ersten Register ein neues userReading mit der Darstellung der Gesamtwärmemenge angelegt.

Wärmemenge Heizen definieren:
<pre>
define dim_heating1_thermalenergy ModbusRegister 0 5096
attr dim_heating1_thermalenergy IODev HeatPumpServer
attr dim_heating1_thermalenergy event-on-change-reading .*
attr dim_heating1_thermalenergy plcDataType INT
attr dim_heating1_thermalenergy registerType Holding
attr dim_heating1_thermalenergy room Dimplex
attr dim_heating1_thermalenergy updateInterval 00:15:00
attr dim_heating1_thermalenergy userReadings heatingthermalenergy {\
((ReadingsVal("dim_heating3_thermalenergy","state",0)*100000000)+\
(ReadingsVal("dim_heating2_thermalenergy","state",0)*10000)+\
(ReadingsVal("dim_heating1_thermalenergy","state",0)))}

define dim_heating2_thermalenergy ModbusRegister 0 5097
attr dim_heating2_thermalenergy IODev HeatPumpServer
attr dim_heating2_thermalenergy event-on-change-reading .*
attr dim_heating2_thermalenergy plcDataType INT
attr dim_heating2_thermalenergy registerType Holding
attr dim_heating2_thermalenergy room Dimplex
attr dim_heating2_thermalenergy updateInterval 00:15:00

define dim_heating3_thermalenergy ModbusRegister 0 5098
attr dim_heating3_thermalenergy IODev HeatPumpServer
attr dim_heating3_thermalenergy event-on-change-reading .*
attr dim_heating3_thermalenergy plcDataType INT
attr dim_heating3_thermalenergy registerType Holding
attr dim_heating3_thermalenergy room Dimplex
attr dim_heating3_thermalenergy updateInterval 00:15:00
</pre>Wärmemenge Warmwasser definieren:<pre>
define dim_dhw1_thermalenergy ModbusRegister 0 5099
attr dim_dhw1_thermalenergy IODev HeatPumpServer
attr dim_dhw1_thermalenergy event-on-change-reading .*
attr dim_dhw1_thermalenergy plcDataType INT
attr dim_dhw1_thermalenergy registerType Holding
attr dim_dhw1_thermalenergy room Dimplex
attr dim_dhw1_thermalenergy updateInterval 00:15:00
attr dim_dhw1_thermalenergy userReadings dhwthermalenergy {\
((ReadingsVal("dim_dhw3_thermalenergy","state",0)*100000000)+\
(ReadingsVal("dim_dhw2_thermalenergy","state",0)*10000)+\
(ReadingsVal("dim_dhw1_thermalenergy","state",0)))}

define dim_dhw2_thermalenergy ModbusRegister 0 5100
attr dim_dhw2_thermalenergy IODev HeatPumpServer
attr dim_dhw2_thermalenergy event-on-change-reading .*
attr dim_dhw2_thermalenergy plcDataType INT
attr dim_dhw2_thermalenergy registerType Holding
attr dim_dhw2_thermalenergy room Dimplex
attr dim_dhw2_thermalenergy updateInterval 00:15:00

define dim_dhw3_thermalenergy ModbusRegister 0 5101
attr dim_dhw3_thermalenergy IODev HeatPumpServer
attr dim_dhw3_thermalenergy event-on-change-reading .*
attr dim_dhw3_thermalenergy plcDataType INT
attr dim_dhw3_thermalenergy registerType Holding
attr dim_dhw3_thermalenergy room Dimplex
attr dim_dhw3_thermalenergy updateInterval 00:15:00
</pre>
==== Umweltenergie ====
Als Umweltenergie wird die zugeführte Kälteenergie aus der Umwelt (Luft/Erdreich) bezeichnet. Das Auslesen dieser Werte über die Schnittstelle ist erst ab einem neueren Softwarestand möglich. Die Differenz der gesamten Wärmemenge und der Umweltenergie entspricht in etwa der Energie des Verdichters.

Umweltenergie/entzogene Kälteenergie definieren:
<pre>
define dim_environment1_energy ModbusRegister 0 5127
attr dim_environment1_energy IODev HeatPumpServer
attr dim_environment1_energy event-on-change-reading .*
attr dim_environment1_energy plcDataType INT
attr dim_environment1_energy registerType Holding
attr dim_environment1_energy room Dimplex
attr dim_environment1_energy updateInterval 00:15:00
attr dim_environment1_energy userReadings environmentenergy {\
((ReadingsVal("dim_environment3_energy","state",0)*100000000)+\
(ReadingsVal("dim_environment2_energy","state",0)*10000)+\
(ReadingsVal("dim_environment1_energy","state",0)))}

define dim_environment2_energy ModbusRegister 0 5128
attr dim_environment2_energy IODev HeatPumpServer
attr dim_environment2_energy event-on-change-reading .*
attr dim_environment2_energy plcDataType INT
attr dim_environment2_energy registerType Holding
attr dim_environment2_energy room Dimplex
attr dim_environment2_energy updateInterval 00:15:00

define dim_environment3_energy ModbusRegister 0 5129
attr dim_environment3_energy IODev HeatPumpServer
attr dim_environment3_energy event-on-change-reading .*
attr dim_environment3_energy plcDataType INT
attr dim_environment3_energy registerType Holding
attr dim_environment3_energy room Dimplex
attr dim_environment3_energy updateInterval 00:15:00
</pre>

==== Logfile Wärmemengen ====
Anlegen eines jährlichen Logfile der Wärmemengen.
<pre>
define filelog_dim_thermalenergy_year FileLog ./log/filelog_dim_thermalenergy_year-%y.log
dim_heating1_thermalenergy:heatingthermalenergy:.*|
dim_dhw1_thermalenergy:dhwthermalenergy:.*|
dim_heating1_thermalenergy:heatingthermalenergy:.*
attr filelog_dim_thermalenergy_year room Dimplex
</pre>

=== Meldungen ===
[[Bild:dimplex_rh_status_heatpump.jpg|thumb|right|Beispiel Meldungen]]
Eine sinnvolle Anzeige sind die Meldungen (Status, Sperre, Störung) der Wärmepumpe. Im nachfolgenden Beispiel werden die Meldungen mit dem Hilfsmodul [[readingsHistory]] dargestellt. Die Definitionen der Meldungen beziehen sich auf die im [http://www.dimplex.de/wiki Dimplex-Wiki] beschriebene L-Software. Bei abweichenden Softwareständen müssen die Register sowie die Texte angepasst werden.

Register Statusmeldung definieren:

<pre>
define dim_status_heatpump ModbusRegister 0 103
attr dim_status_heatpump IODev HeatPumpServer
attr dim_status_heatpump event-on-change-reading .*
attr dim_status_heatpump plcDataType INT
attr dim_status_heatpump registerType Holding
attr dim_status_heatpump room Dimplex
attr dim_status_heatpump updateInterval 00:00:10
attr dim_status_heatpump userReadings Status {\
((ReadingsVal($name,"state","") == 1) ? "Aus":\
(ReadingsVal($name,"state","") == 4) ? "Warmwasser":\
(ReadingsVal($name,"state","") == 10) ? "Abtauen":\
(ReadingsVal($name,"state","") == 11) ? "Durchflussüberwachnung":"")}

</pre>Register Sperrmeldunge definieren:<pre>
define dim_block_heatpump ModbusRegister 0 104
attr dim_block_heatpump IODev HeatPumpServer
attr dim_block_heatpump event-on-change-reading .*
attr dim_block_heatpump plcDataType INT
attr dim_block_heatpump registerType Holding
attr dim_block_heatpump room Dimplex
attr dim_block_heatpump updateInterval 00:00:10
attr dim_block_heatpump userReadings Sperre {\
((ReadingsVal($name,"state","") == 0) ? "":\
(ReadingsVal($name,"state","") == 7) ? "Systemkontrolle":\
(ReadingsVal($name,"state","") == 9) ? "Pumpenvorlauf":\
(ReadingsVal($name,"state","") == 10) ? "Mindeststandzeit":\
(ReadingsVal($name,"state","") == 11) ? "Netzbelastung":\
(ReadingsVal($name,"state","") == 12) ? "Schaltspielsperre":\
(ReadingsVal($name,"state","") == 15) ? "EVU":"")}
</pre>Register Störmeldungen definieren:<pre>
define dim_fault_heatpump ModbusRegister 0 105
attr dim_fault_heatpump IODev HeatPumpServer
attr dim_fault_heatpump event-on-change-reading .*
attr dim_fault_heatpump plcDataType INT
attr dim_fault_heatpump registerType Holding
attr dim_fault_heatpump room Dimplex
attr dim_fault_heatpump updateInterval 00:01:00
attr dim_fault_heatpump userReadings Störung {\
((ReadingsVal($name,"state","") == 0) ? "":\
(ReadingsVal($name,"state","") == 6) ? "Elektronisches Ex.Ventil":\
(ReadingsVal($name,"state","") == 15) ? "Sensorik":\
(ReadingsVal($name,"state","") == 19) ? "!Primärkreis":\
(ReadingsVal($name,"state","") == 22) ? "!Warmwasser":\
(ReadingsVal($name,"state","") == 23) ? "!Last Verdichter":\
(ReadingsVal($name,"state","") == 24) ? "!Codierung":\
(ReadingsVal($name,"state","") == 25) ? "!Niederdruck":\
(ReadingsVal($name,"state","") == 26) ? "!Frostschutz":\
(ReadingsVal($name,"state","") == 29) ? "!Temperatur Differenz":\
(ReadingsVal($name,"state","") == 31) ? "!Durchfluss":"")}
</pre>
==== Anzeige der Meldungen ====
readingsHistory definieren:<pre>
define rh_dim_status_heatpump readingsHistory dim_status_heatpump:Status dim_block_heatpump:Sperre dim_fault_heatpump:Störung
attr rh_dim_status_heatpump alias Status
attr rh_dim_status_heatpump mapping {'dim_status_heatpump' => '', 'dim_block_heatpump' => '', 'dim_fault_heatpump' => ''}
attr rh_dim_status_heatpump nohtml 1
attr rh_dim_status_heatpump room Dimplex
attr rh_dim_status_heatpump rows 20
attr rh_dim_status_heatpump timestampFormat %b %a %R
</pre>

== Plotbeispiel ==
=== Temperaturen ===
<pre>
# Created by FHEM/98_SVG.pm, 2015-05-11 21:40:00
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 ytics y2tics
set ylabel ""
set y2label "Temperatur (°C)"

#filelog_dim_temperature_week 4:dim_outdoor_temperature.*::
#filelog_dim_temperature_week 4:dim_room_temperature.*::
#filelog_dim_temperature_week 4:dim_return_temperature.*::
#filelog_dim_temperature_week 4:dim_returnset_temperature.*::
#filelog_dim_temperature_week 4:dim_dhw_temperature.*::
#filelog_dim_temperature_week 4:dim_flow_temperature.*::
#filelog_dim_temperature_week 4:dim_brine_temperature.*::

plot "<IN>" using 1:2 axes x1y2 title 'AT' ls l7 lw 1 with lines,\
"<IN>" using 1:2 axes x1y2 title 'RT' ls l1 lw 1 with lines,\
"<IN>" using 1:2 axes x1y2 title 'RL' ls l2 lw 1 with lines,\
"<IN>" using 1:2 axes x1y2 title 'RLS' ls l3 lw 1 with lines,\
"<IN>" using 1:2 axes x1y2 title 'WWT' ls l4 lw 1 with lines,\
"<IN>" using 1:2 axes x1y2 title 'VLT' ls l0 lw 1 with lines,\
"<IN>" using 1:2 axes x1y2 title 'SOL' ls l6 lw 1 with lines
</pre>

=== Ausgänge ===
<pre>
# Created by FHEM/98_SVG.pm, 2015-05-11 21:45:00
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 ''
set ytics ("An" -1, "Aus" -2, "An" -5, "Aus" -6, "An" -9, "Aus" -10, "An" -13, "Aus" -14)
set y2tics ("An" 1, "Aus" 0, "An" -3, "Aus" -4, "An" -7, "Aus" -8, "An" -11, "Aus" -12)
set grid
set ylabel ""
set y2label "Digital"
set yrange [-16:2]
set y2range [-16:2]

#FileLog 3:dim_compressor_output.*::$fld[2]=~"on"?1:0
#FileLog 3:dim_ventilator_output.*::$fld[2]=~"on"?-1:-2
#FileLog 3:dim_2heatgenerator_output.*::$fld[2]=~"on"?-3:-4
#FileLog 3:dim_circulationpump_output.*::$fld[2]=~"on"?-5:-6
#FileLog 3:dim_dhwpump_output.*::$fld[2]=~"on"?-7:-8
#FileLog 3:dim_auxiliarypump_output.*::$fld[2]=~"on"?-9:-10
#FileLog 3:dim_solarpump_output.*::$fld[2]=~"on"?-11:-12
#FileLog 3:dim_flangeheater_output.*::$fld[2]=~"on"?-13:-14

plot "<IN>" using 1:2 axes x1y2 title 'Vd' ls l7 lw 1.5 with steps,\
"<IN>" using 1:2 axes x1y2 title 'Ve' ls l6 lw 1.5 with steps,\
"<IN>" using 1:2 axes x1y2 title '2.We' ls l5 lw 1.5 with steps,\
"<IN>" using 1:2 axes x1y2 title 'Hub' ls l4 lw 1.5 with steps,\
"<IN>" using 1:2 axes x1y2 title 'Wup' ls l3 lw 1 with steps,\
"<IN>" using 1:2 axes x1y2 title 'Zup' ls l0 lw 1.5 with steps,\
"<IN>" using 1:2 axes x1y2 title 'Sol' ls l2 lw 1.5 with steps,\
"<IN>" using 1:2 axes x1y2 title 'Flh' ls l7 lw 1.5 with steps
</pre>

[[Bild:dimplex_hp_graph.jpg|thumb|right|Plotbeispiel]]
Im nebenstehenden Plotbeispiel werde die Temperaturen (Analogwerte) sowie die Ausgänge (Digitalwerte) dargestellt. Im einzelnen sind die Kurven für die

* Aussen- (AT)
* Raum- (RT)
* Rücklauf- (RL)
* Rücklaufsoll- (RLS)
* Warmwasser- (WWT) und
* Vorlauftemperatur (VLT)

sowie die Ausgänge für

* Verdichter 1 (Vd)
* Ventilator (Ve)
* 2.Wärmeerzeuger (2We)
* Heizungsumwälzpumpe (Hup)
* Warmwasserumwälzpumpe (Wup) und
* Zusatzumwälzpumpe (Zup)

enthalten.

= Kontakt =
Weitere Fragen, Wünsche und Anregungen bitte im entsprechenden {{Link2Forum|Topic=33086|LinkText=Forenthread zum Wiki-Artikel "Dimplex Wärmepumpenmanager"}} zur Diskussion stellen.

Offene Punkte:
- Darstellung der Werte in einer readingsGroup
- Zugriff auf Zeitfunktionen mit Lesen und Schreiben

[[Kategorie:HOWTOS]]
[[Kategorie:Heizungssteuerung]]
[[Kategorie:Other Components]]

Ble2mqtt

2025-02-28T18:20:58Z

TomLee: /* Einbindung in FHEM */

{{SEITENTITEL:ble2mqtt}}
{{Infobox Modul
|ModPurpose=Anwesenheitserkennung von Bluetooth-Geräten
|ModType=contrib
|ModFTopic=127173
|ModForumArea=Unterstützende Dienste
|ModTechName=ble2mqtt
|ModOwner={{Link2FU|5068|PatrickR}}
}}
[[ble2mqtt]] ist ein Script, das den Anwesenheitsstatus eines oder mehrerer Bluetooth Low Energy Geräte überprüfen und das Ergebnis an einen MQTT Broker schicken kann.

Es verwendet dazu die Linux Tools ''bluetoothctl'' und ''gatttool''.

ble2mqtt ist in Perl geschrieben und wurde von {{Link2FU|5068|PatrickR}} erstellt. Weitere Informationen finden sich in diesem {{Link2Forum|Topic=127173|LinkText=Forums-Thema}}. Fragen dazu bitte in den Bereich {{Link2Forum|Area=Unterstützende Dienste}}.

==Voraussetzungen==
* Debian od. Raspberry Pi OS
* Bluetooth Empfänger

==Parameter==
Beim Start von ble2mqtt können folgende Parameter angegeben werden:

{| class="wikitable"
!Parameter!!Beschreibung!!Standardwert!!Beispiel!!Optional
|-
| --mqttserver
|Die Adresse des MQTT Brokers inklusive Port
|
| --mqttserver mqtt.example.org:1883
|nein
|-
| --mqttfingerprint
|Der Fingerprint des für die TLS-verschlüsselte Kommunikation mit dem MQTT Broker verwendeten Zertifikates
|
| --mqttfingerprint bfe5d244a821194230f1479fe2f8f7bbcd2a8cb8
|ja
|-
| --mqtttopic
| An welches MQTT-Topic das Tool die Informationen schicken soll.
|ble2mqtt
| --mqtttopic ble2mqtt/Wohnzimmer
|ja
|-
| --mqttuser
|Der Benutzernamen, unter dem die Verbindung zum Broker hergestellt werden soll
|
| --mqttuser ble2mqtt
|ja bzw. abhängig vom Broker
|-
| --mqttpass
|Das zum Benutzernamen gehörende Passwort
|
| --mqttpass verysecret3
|ja bzw. abhängig vom Broker
|-
| --retain
|Versendet die Nachrichten present und lastseen als retained.
|0
| --retain
|ja
|-
| --daemonize
|Wenn ble2mqtt im Hintergrund (als Daemon) ausgeführt werden soll
|0
| --daemonize
|ja
|-
| --loglevel
|Wie und was genau protokolliert werden soll. Mögliche Loglevel sind LOG_CRIT, LOG_ERR, LOG_WARNING, LOG_NOTICE, LOG_INFO, LOG_DEBUG.
|LOG_INFO
| --loglevel LOG_ERR
|ja
|-
| --logtarget
|Wohin gelogged werden soll. Mögliche Optionen sind ''syslog'' und ''stdout''.
|syslog
| --logtarget stdout
|ja
|-
| --absentinterval
|Anzahl an Sekunden, nach denen das Gerät als abwesend bezeichnet werden soll. Mindestwert ist 30.
|60
| --absentinterval 120
|ja
|-
| --rssithreshold
|Ab welcher Abweichung des RSSI Wertes ein Update getriggert werden soll. Mindestwert ist 5.
|10
| --rssithreshold 8
|ja
|-
| --watchdogthreshold
|Ab welchem Zeitraum in Sekunden nach Empfangen des letzten BT-Signals ble2mqtt neu gestartet werden soll. Mindestwert ist 30. Der Wert 0 bedeutet deaktiviert, also nie.
|0
| --watchdogthreshold 30
|ja
|-
| --debug
|Kann nur gemeinsam mit --daemonize verwendet werden, um Logeinträge auf stdout auszugeben. Je höher die Nummer, desto mehr Output.
|0
| --daemonize --debug 4
|ja
|-
| --mac
|Filtert mittels Regex nach MAC-Adressen der von ble2mqtt zu beachtenden BLE-Geräte. Alle anderen Geräte werden ignoriert.
|
| --mac '(11:22:33:44:55:66|77:88:99:00:AA:BB)'
|ja
|-
| --batterymaxage
|Zeit in Stunden, nach denen ein Batterie-Wert als veraltet angesehen und aktualisiert wird. Der Wert 0 deaktiviert den Batterie-Check.
|48
| --batterymaxage 6
|ja
|-
| --forcebattery
|Nur in Kombination mit --mac. Erzwingt einen Batterie-Check, auch wenn das battery-service am Gerät nicht erkannt wird.
|0
| --forcebattery
|ja
|}
===Beispiele===
* Broker verlangt Username/Passwort; es sollen keine Batterie-Werte ausgelesen werden
ble2mqtt --mqttserver mqtt.example.org:1883 --mqttuser ble2mqtt --mqttpass verysecret3 --batterymaxage 0

* Broker verlangt keine Authentifizierung; es soll nach zwei G-Tags gesucht werden; definiertes MQTT-Topic; Batteriewerte benötigt
ble2mqtt --mqttserver mqtt.example.org:1883 --mqtttopic ble2mqtt/Wohnzimmer --mac '(11:22:33:44:55:66|77:88:99:00:AA:BB)'

* Broker verlangt keine Authentifizierung; Geräte sollen nach 45s ohne Kontakt als abwesend angezeigt werden; MQTT Nachrichten sollen gespeichert bleiben
ble2mqtt --mqttserver mqtt.example.org:1883 --absentinterval 45 --retain

==Installation==
Zur Installation muss das ble2mqtt-Script auf den Server kopiert werden und es müssen diverse Linux- und Perl-Pakete installiert werden. Das Script findet ihr im [https://svn.fhem.de/trac/browser/trunk/fhem/contrib/ble2mqttd Contrib-Verzeichnis] von FHEM.

Zuerst das Script nach /usr/local/bin kopieren, um beim Aufruf in der Bash nicht immer den ganzen Pfad voranstellen zu müssen.
:<code>sudo cp -a ble2mqttd /usr/local/bin/</code>
Danach das Script noch als ausführbar markieren
:<code>sudo chmod +x /usr/local/bin/ble2mqttd</code>

===Benötigte Linux Pakete===
Die benötigten Pakete können ganz einfach mit ''apt'' installiert werden. Dabei werden auch mögliche Abhängigkeiten automatisch installiert.
<syntaxhighlight lang="bash">
sudo apt install -y libssl-dev libio-socket-ssl-perl libreadonly-perl libtest-expect-perl libnet-ssleay-perl libnet-server-perl
</syntaxhighlight>

===Benötigte Perl-Module===
Es wird das Modul ''Net::MQTT::Simple'' (''libnet-mqtt-simple-perl'') benötigt. Das ist - Stand 08.11.2023 - noch nicht in den Stable-Repositories von Debian verfügbar und muss daher mittels ''cpan'' installiert werden. Voraussetzung dafür ist das Modul ''CPAN::DistnameInfo'', welches zuerst installiert werden muss.
<syntaxhighlight lang="Bash">
sudo cpan CPAN::DistnameInfo
sudo cpan Net::MQTT::Simple
</syntaxhighlight>
Sobald ''libnet-mqtt-simple-perl'' verfügbar ist, kann dieses statt der Perl-Module wie ein normales Linux-Paket installiert werden.

===Erster Test===
Mit einem einfachen Aufruf von '''ble2mqtt''' kann getestet werden, ob alle benötigten Module und Pakete vorhanden sind.
<syntaxhighlight lang="Bash">
sudo /usr/local/bin/ble2mqttd
</syntaxhighlight>

===Erstellen einens Systemd-Daemons===
Damit '''ble2mqtt''' bei jedem Systemstart automatisch gestartet wird, muss ein Systemd-Daemon erstellt werden. Das wird gemacht, in dem eine neue Textdatei mit folgendem Inhalt angelegt und der Daemon dann aktiviert wird.

{{Hinweis|'''Wichtig:''' Das Kommando, mit welchen Parametern ble2mqtt gestartet wird, muss natürlich individuell angepasst werden!}}
<syntaxhighlight lang="bash">
sudo nano /etc/systemd/system/ble2mqttd.service
</syntaxhighlight>

<syntaxhighlight lang="ini">
[Unit]
Description=ble2mqttd
After=bluetooth.target

[Service]
Type=simple
Restart=always
ExecStart=/usr/local/bin/ble2mqttd --mqttserver mqtt.example.com:1883 --mqtttopic ble2mqtt/wohnzimmer --mac '(11:22:33:44:55:66|77:88:99:00:AA:BB)' --absentinterval 30 --mqttuser <username> --mqttpass <password>

[Install]
WantedBy=multi-user.target
</syntaxhighlight>

sudo systemctl daemon-reload
sudo systemctl enable ble2mqttd.service
sudo systemctl start ble2mqttd.service

==Einbindung in FHEM==
Da ble2mqtt alle Informationen an einen [[MQTT]]-Broker sendet, können diese Informationen ganz einfach als [[MQTT2_DEVICE]] in FHEM eingebunden werden. Wie dabei vorgegangen werden kann, unterscheidet sich je nach Anwendungsbereich und den eigenen Vorlieben.

Als Beispiel sie hier die Anwesenheitserkennung mittels BT-Tags angeführt.

===Anwesenheitserkennung mittels BT-Tags===
[[File:ble2mqtt.png|thumb|Readings eines Devices, dass mit diesem Code erstellt wurde]]
Der folgende Code geht davon aus, dass es mehrere ble2mqtt-Instanzen gibt und ein BT-Tag mit der MAC-Adresse AA:BB:CC:DD:EE:FF erkannt werden soll.

Die verschiedenen ble2mqtt-Instanzen schicken ihre Nachrichten in unterschiedliche Topics.
Für jede Instanz ein eigenes Topic:
*ble2mqtt/wohnzimmer
*ble2mqtt/schlafzimmer
*ble2mqtt/kueche
Im Attribut ''devicetopic'' werden diese Topics dann gemeinsam ausgewertet. Das funktioniert, in dem der Name des Subtopics einfach durch den Regex-Ausdruck ''.*'' ersetzt wird.

Bedeutet aber auch, dass die Informationen - wenn gewünscht - wieder in unterschiedliche Readings zerlegt werden müssen. Um z.B. schnell zu erkennen, in welchem Raum der BT-Tag gerade liegt. Das passiert hier z.B. bei den Nachrichten für ''rssi'' und ''presence''. Daraus resultieren dann eigene Readings für jedes MQTT-Subtopic.

Das "raumübergreifende" Reading ''presence'' wird anhand der des Alters in Sekunden der letzten lastseen-Nachricht gesteuert. Die lastseen-Nachricht wird immer gesendet, wenn der Scanvorgang von ble2mqtt das gewünschte Gerät findet.

<syntaxhighlight lang="perl">
defmod ble2mqttGTag MQTT2_DEVICE FHEM
attr ble2mqttGTag devicetopic ble2mqtt/.*/AA_BB_CC_DD_EE_FF
attr ble2mqttGTag event-on-change-reading .*
attr ble2mqttGTag readingList ble2mqtt/.*/heartbeat:.* heartbeat\
$DEVICETOPIC/rssi:.* {my $room=(split m{[/]}x,$TOPIC)[1];; my $roomMax=$room;; my $rssiMax=$EVENT;; my @readings = grep { $_ =~ m{\Arssi_(?!$room).*}x } keys %{$defs{"$NAME"}->{READINGS}};; for (@readings) {my $rssiTmp=ReadingsVal($NAME,$_,'-100');; my $roomTmp=(split m{[_]}x,$_)[1];; if(($rssiMax gt $rssiTmp)&&(ReadingsVal($NAME,"presence_".$roomTmp,'absent') eq 'present')) {$rssiMax=$rssiTmp;; $roomMax=$roomTmp}};; {rssi=>$rssiMax,room=>$roomMax,"rssi_$room"=>$EVENT}}\
$DEVICETOPIC/lastseen:.* {lastseen=>strftime "%Y-%m-%d %H:%M:%S", localtime($EVENT)}\
$DEVICETOPIC/present:.* {my $roomAct=(split m{[/]}x,$TOPIC)[1];; my $rssi=ReadingsVal($NAME,"rssi_".$roomAct,'-100');; my $presenceAct=$EVENT?'present':'absent';; my $room=$EVENT ? $roomAct:'';; my @readings = grep { $_ =~ m{\Apresence_(?!$roomAct).*}x } keys %{$defs{$NAME}->{READINGS}};; for (@readings) {if(ReadingsVal($NAME,$_,'absent') eq 'present') {my $roomTmp=(split m{[_]}x,$_)[1];; my $rssiTmp=ReadingsVal($NAME,"rssi_".$roomTmp,'-100');; if($rssi gt $rssiTmp){$room=$roomTmp;; $rssi=$rssiTmp}}};; {"presence_$roomAct"=>$presenceAct, room=>$room}}\
ble2mqtt/.*/state:.* state\
$DEVICETOPIC/battery:.* batteryLevel
attr ble2mqttGTag userReadings presence {if (ReadingsAge($NAME,"lastseen",0)>60) {return "absent";;}else{return "present";;}}
</syntaxhighlight>
[[Import_von_Code_Snippets|↑Raw Code]]

Das Ergebnis ist unter anderem ein Reading ''presence'' mit den Zuständen ''absent'' und ''present''. Es kann somit ganz einfach als "presenceDevice" in einem [[ROOMMATE]]-Device verwendet werden:
attr rr_Franz rr_presenceDevices ble2mqttGTag

[[Category:MQTT]][[Category:Anwesenheitserkennung]][[Category:FHEM Utilities]]

Sonos2mqtt

2024-12-21T14:02:14Z

TomLee: kleine Rechtschreibkorrekturen

== Grundeinrichtung ==
Die Grundeinrichtung ist bereits im Artikel [[MQTT2-Module - Praxisbeispiele#Sonos2Mqtt|MQTT2-Module - Praxisbeispiele]] beschrieben. Hier soll es um die praktische Verwendung und Erweiterung gehen.

Für alle Erweiterungen wird versucht vorhandene Devices in FHEM zu verwenden.

Viele Dinge werden derzeit noch entwickelt und können frei gestaltet werden - der Vorteil von generischen FHEM Devices.

== Tipps zur Verwendung ==
Die automatische Konfiguration setzt den alias entsprechend dem im Sonos vergeben Namen . Die langen MQTT2_RINCON_ Namen sind unhandlich und schlecht lesbar. Man kann Player mit einem devspec ansprechen, das simpelste ist:
:<code>set alias=Büro play</code>
Oder alle Player
:<code>set model=sonos2mqtt_speaker leaveGroup</code>

== Konfiguration der Player ==
Mit dem Template sonos_bridge_comfort wird aus dem contrib Ordner eine Datei 99_sonos2mqttUtils.pm nachgeladen und aktiviert. Darin befindet sich der wesentliche Code, die sonos2mqtt Geräte selbst enthalten nur rudimentäre Aufrufe.

Selbstverständlich kann man diese Datei jederzeit selbst gestalten (FHEM Menu:Edit Files) aber man sollte beachten, dass eine erneute Anwendung des Templates die Datei überschreibt.

Man kann auch jederzeit diese Datei aus dem SVN neu laden:
<syntaxhighlight lang="perl">
{ Svn_GetFile("contrib/AttrTemplate/99_sonos2mqttUtils.pm", "FHEM/99_sonos2mqttUtils.pm", sub(){ CommandReload(undef, "99_sonos2mqttUtils") }) }
</syntaxhighlight>Hauptroutine ist sonos2mqtt die mit zwei Parametern aufgerufen wird. <code>{sonos2mqtt($NAME,$EVENT)}</code>

Die Optik des Players wird mit der Routine <code>sonos2mqtt_devStateIcon</code> bestimmt.

Man kann die Player mittels <code>attr a:model=sonos2mqtt_speaker webCmd volume</code> mit einem Slider in der Übersicht ausstatten.

Ändert man die Sonoslandschaft, kann man auch alles einreißen und neu erzeugen lassen. Zunächst alles löschen (für die FHEM Kommandozeile):<syntaxhighlight lang="perl">
{fhem("delete a:model=sonos2mqtt_speaker;;delete FileLog_MQTT2_RINCON.*");;qx(rm ./log/MQTT2_RINCON_*);;return ""}
</syntaxhighlight>Danach muss man sonos2mqtt einfach neu starten: pm2 start ... bzw den docker container neu starten.

== Befehle nachrüsten ==
Um Befehle in der setList / getList / readingList nachzurüsten gibt es die Routine <code>sonos2mqtt_mod_list(devspec,attrName,line)</code>

Vorhandene Zeilen werden ersetzt. Identifiziert wird nur der erste Teil bis zum ":". Beispiel für die Kommandozeile:

<code>{sonos2mqtt_mod_list('a:model=sonos2mqtt_bridge','readingList','sonos/RINCON_([0-9A-Z]+)/Reply:.* Reply')}</code>

== Sprachausgabe ==
Man hat zwei Möglichkeiten, dies umzusetzen:
# Text2Speech FHEM intern
# Mit dem sonos text to speech Server https://svrooij.io/sonos2mqtt/

=== Text2Speech Variante einrichten ===
Zwei zusätzliche Geräte sind notwendig:
* [[Text2Speech]] im Servermodus, erzeugt mp3 Dateien im cache Verzeichnis und legt einen Link im Reading httpName ab.
* Ein HTTP Server stellt die Dateien im gleichen Verzeichnis bereit
'''Hinweis''': Für die vollständige Funktion und Installation von Text2Speech ist die Commandref zu beachten! Für das unten im Beispiel verwendete Feature UseMP3Wrap muss das Tool mp3wrap installiert werden (z.B. <code>apt install mp3wrap</code>). Dies ist bei längeren Texten und bei der Verwendung von eingebetteten festen Sounds existenziell!

Für die Funktion ist wichtig, dass das Sonos System den Host im Link zur Datei richtig auflösen kann. Deshalb wird der Hostname und Port des Servers im Reading host des TTS Device als Name oder IP Adresse abgelegt! Dies kann entweder mit dem hier gezeigten Befehl oder vollständig manuell erfolgen. Für FHEM innerhalb Docker muss man die Adresse des Docker Host angeben.
<syntaxhighlight lang="perl">
defmod SonosTTS Text2Speech none
attr SonosTTS TTS_UseMP3Wrap 1
attr SonosTTS TTS_Language Deutsch
attr SonosTTS userReadings httpName:lastFilename.* {'http://'.ReadingsVal($name,'host','set host:port first').'/fhem/'.ReadingsVal($name,'lastFilename','')}
attr SonosTTS TTS_CacheFileDir cache
setreading SonosTTS host {(qx(hostname -s|tr -d '\n').':'.InternalVal('WEB','PORT','8083'))}
#setreading SonosTTS host {((split(' ', qx(hostname -I)))[0].':'.InternalVal('WEB','PORT','8083'))}
#setreading SonosTTS host <hostname>:<port>

defmod SonosSpeakWeb HTTPSRV cache cache SonosSpeakWeb
</syntaxhighlight>
Der Sprachausgabe Befehl im Player Device läuft in 3 Schritten:
# mit dem TTS Gerät wird die mp3 Datei erzeugt,
# mit dem sleep wird auf die Fertigstellung gewartet,
# die Datei wird mit <code>set Player notify volume uri</code> abgespielt.
Durch den "sonos2mqtt notify" Befehl wird die laufende Umgebung wiederhergestellt.
* Wird der Sprachbefehl an den Gruppenmaster gesendet wird die mp3 Datei in der gesamten Gruppe gespielt.
* Wird der Sprachbefehl an ein Mitglied einer Gruppe gesendet (nicht den Master) wird die Gruppe aufgetrennt und später wieder hergestellt.
Es sind zwei Befehle zur Sprachausgabe eingebaut:

=== sayText Befehl ===
Dieser Befehl orientiert sich an den FHEM [[DevelopmentGuidelinesAV|DevelopmentGuidelines]] und sammelt "gleichzeitig" eintreffende Sprachnachrichten, damit nichts verloren geht. Informationen im Forum dazu in {{Link2Forum|Topic=111711|Message=1100112|LinkText=diesem Beitrag}}.

Die Lautstärke wird separat in SonosTTS gesetzt: <code>setreading SonosTTS vol 15</code>, ebenso die Sprache (einmalig bei der Einrichtung oder bei Bedarf zwischendurch) <code>attr SonosTTS TTS_Language Deutsch</code>

''Hinweis: Der Befehl <code>set SonosTTS volume xx</code> hat im Servermodus des Devices keine Wirkung!''
=== Speak Befehl ===
Dieser Befehl ist ähnlich wie der in der FHEM-Sonos Umgebung:
:<code>set Player speak <volume> text</code>

Verwendet man diesen Syntax (mit Sprache und Stimme am Anfang), wird automatisch der speak Befehl an die sonos-tts abgesetzt. Die sonos-tts muss man separat installieren/integrieren!

<code>set EG.KU.Sonos speak de-DE Vicki 25 Test</code>

Will man keine laufenden Sendung unterbrechen sondern einfach eine Ansage machen und danach etwas starten, kann man so vorgehen:
<syntaxhighlight lang="perl">
set SonosTTS tts Hier steht die Ansage;sleep SonosTTS:playing:.0 ; set alias=PlayerAlias playUri [SonosTTS:httpName]
</syntaxhighlight>

=== Volume Befehl ===
Der Befehl akzeptiert einen zweiten Wert als Startwert d.h. set volume 25 10 setzt sofort auf 10 und startet dann fading auf 25. Ein zweiter Wert -1 erzeugt ein fading vom aktuellen Wert auf den angegebenen.

==== Spiele feste Sounds ====
Generell kann man feste mp3 Dateien (Klingeltöne, Klänge usw.) auch im cache Verzeichnis ablegen und direkt mit dem Link starten.

Es gibt zahlreiche Soundquellen im Internet, ist der gewünschte Sound dabei, kann man ihn innerhalb FHEM herunterladen und an Ort und Stelle platzieren. (Beispiel ohne und mit Umbennung)
<syntaxhighlight lang="perl">
"wget -qP ./cache https://cdn.smartersoft-group.com/various/pull-bell-short.mp3"
"wget -qO ./cache/KlingelTon.mp3 https://cdn.smartersoft-group.com/various/pull-bell-short.mp3"
</syntaxhighlight>
Vergewissern ob der gewünschte Sound auch da ist: {qx(ls -lha ./cache)}

Mit set magic kann man dabei einfach Teile aus anderen Readings holen.
<syntaxhighlight lang="perl">
set alias=Büro notify 25 {('http://[SonosTTS:host]/fhem/cache/KlingelTon.mp3')}
</syntaxhighlight>
Man kann auch den setter im Gerät erweitern <code>{sonos2mqtt_mod_list('a:model=sonos2mqtt_speaker','setList',q(playSound:textField ....))}</code> :
<syntaxhighlight lang="perl">
playSound:textField {my $tts="SonosTTS";my ($cmd,$vol,$file)=split(' ', $EVENT,3);$file=($file=~m/.*\.mp3$/)?"$file":"$file.mp3";fhem("set $NAME notify $vol http://[$tts:host]/fhem/[a:$tts:TTS_CacheFileDir]/$file")}
</syntaxhighlight>
Damit sind dann dieser Syntax möglich:
<syntaxhighlight lang="perl">
set alias=Büro playSound 40 KlingelTon.mp3
</syntaxhighlight>
oder ohne Dateiendung (wird auf .mp3 gesetzt)
<syntaxhighlight lang="perl">
set alias=Büro playSound 40 KlingelTon
</syntaxhighlight>

=== SonosBridge ===
Die SonsoBridge enthält bereits ein paar zentrale Funktionen und Readings, z.B. wird beim Laden der Favoritenliste ein Reading favlist und grouplist erzeugt, welches zur Erweiterung der Player mit Auswahllisten dienen kann.

=== Player mit Favoritenliste und Gruppenliste ausstatten ===
Wenn nicht schon geschehen muss man jetzt die Favoriten zum ersten Mal einlesen: <syntaxhighlight lang="perl">
get SonosBridge Favorites
</syntaxhighlight>Nachdem die SonosBridge "aufgerüstet" ist, kann man allen Playern die Favoritenliste zum Auswählen eintragen. Beide Zeile sind für die FHEM Kommandozeile und verwenden die Routine aus der 99_sonos2mqttUtils.
<syntaxhighlight lang="perl">
{sonos2mqtt_mod_list('a:model=sonos2mqtt_speaker','setList','joinGroup:'.ReadingsVal((devspec2array('a:model=sonos2mqtt_bridge'))[0],'grouplist','').q( {sonos2mqtt($NAME,$EVENT)}))}
{sonos2mqtt_mod_list('a:model=sonos2mqtt_speaker','setList','playFav:'.ReadingsVal((devspec2array('a:model=sonos2mqtt_bridge'))[0],'favlist','').q( {sonos2mqtt($NAME,$EVENT)}))}
</syntaxhighlight>
Man kann den playFav Befehl auch im set Befehl mit einem Teil des Favoriten Namen verwenden. Enthält die Favoritenliste z.B. Radio Leipzig würde der auch mit diesem Befehl angesteuert werden:<syntaxhighlight lang="perl">
set alias=Bad playFav leipzig
</syntaxhighlight>

=== Listen der Favoriten Radios und Playlist erstellen ===
Im Sonos System kann man an (mindestens) drei Stellen Favoriten hinterlegen: Sonos-Favoriten, Sonos-Playlisten, TuneIn: Meine Radiosender

Diese drei Listen kann man einlesen und für die einfache Suche und Auswahl verwenden. Der play Befehl akzeptiert dazu zwei weitere Parameter und sucht in den entsprechenden Listen.

Diese play Befehle starten nicht sofort, sondern erst nach einem folgenden set ... play. Damit kann man etwas vorbereiten und gezielt starten.

<code>set alias=Büro play Favorite Deutschlandfunk</code>

<code>set alias=Büro play Radio HitRadio</code>

<code>set alias=Büro play Playlist Meine Hits</code>

Die Sonos-Favoriten-, TuneIn: Meine Radiosender- und Sonos-Playlisten dazu vom Sonos System einmalig (bzw. bei Veränderungen) einlesen:
<pre>
get SonosBridge Reply Playlists;sleep SonosBridge:Reply.*;setreading SonosBridge Playlists [SonosBridge:Reply]
get SonosBridge Reply Favorites;sleep SonosBridge:Reply.*;setreading SonosBridge Favorites [SonosBridge:Reply]
get SonosBridge Reply Radios;sleep SonosBridge:Reply.*;setreading SonosBridge Radios [SonosBridge:Reply]
</pre>

Beispiel für ein Guten Morgen Radio:
<pre>
set alias=BadWanne,alias=Kueche joinGroup Bad;
set alias=BadWanne,alias=Bad volume 13 6;
set alias=Bad play Favorite Deutschlandfunk.Kultur.RP;
set alias=Kueche volume 18 8;
sleep 0.2;set alias=Bad play
</pre>

=== Radioliste durchtasten ===
Will man eine Liste von bestimmten Radiostationen mit einem Taster "durchtasten" kann man das wie folgt tun:

Das oben erwähnte <code>99_sonos2mqttUtils.pm</code> (ab 6.1.2023) schreibt die Radios aus dem Reading <code>Favoriten</code> in das userReading <code>favlist</code> im SonosBridge Device und aktualisiert das auch.

==== Der Befehl zum weiterschalten ====
Jedes Mal wenn dieser Befehl ausgeführt wird, wird der nächste "Radio-Favorit" (aus dem userReading <code>favlist</code> des SonosBridge Devices) gestartet.

Erfolgt die Ausgabe eines Radiosender, wird bei einem <code>set ''sonos2mqtt_speaker'' next</code> auf den nächsten Sender in dieser Liste geschaltet und der <code>transportState</code> beibehalten.

==== Name der Radiostation vor dem Umschalten ansagen ====
Will man vor dem Radiostart noch die Ansage des Senders haben, geht das zwar auch mit dem <code>speak</code> Befehl, die direkte Ausgabe ohne Restore der Umgebung (sonos2mqtt notify) ist aber effektiver.

Damit das funktioniert müssen wir die Events einschränken:
<syntaxhighlight lang="perl">
attr model=sonos2mqtt_speaker event-on-change-reading .*
{my $dev = (devspec2array('model=sonos2mqtt_bridge'))[0];;my $r=Each($dev,ReadingsVal($dev,'favlist',''));;my $play = (devspec2array('alias=Büro'))[0];;my $tts="SonosTTS";;fhem("set $tts tts Es folgt $r;;sleep $tts:playing:.0;;set $play playUri [$tts:httpName];;sleep $play:play;;sleep $play:PLAYING;;sleep $play:STOPPED;;set $play playFav $r")}
</syntaxhighlight>
Kurze Erklärung zum Code
* ermittelt den nächsten Radiosender in der Liste: <code>my $dev = (devspec2array('model=sonos2mqtt_bridge'))[0];;my $r=Each($dev,ReadingsVal($dev,'favlist',<nowiki>''</nowiki>))</code>
* ermitteln des Namens des <code>''sonos2mqtt_speaker''</code> Devices anhand des <code>alias</code> Attributes: <code>my $play = (devspec2array('alias=Büro'))[0]</code>
* erzeugt die Ansage "Es folgt SenderXY": <code>my $tts="SonosTTS";;fhem("set $tts tts Es folgt $r</code>
* wenn die mp3 Datei fertig erzeugt ist: <code>sleep $tts:playing:.0</code>, wird sie mit dem Befehl playUri an den oben ermittelten <code>''sonos2mqtt_speaker''</code> gesendet: <code>set $play playUri [$tts:httpName]</code>
* es wird eine Eventfolge abgewartet -> play / PLAYING / STOPPED: <code>sleep $play:play;;sleep $play:PLAYING;;sleep $play:STOPPED</code>
* danach wird der Radiosender gestartet: <code>set $play playFav $r</code>
Der Code ist so einfach und relativ "steif" für die Kommandozeile. Man kann das auch in einen Setter packen (<code>set ''sonos2mqtt_speaker'' toggleRadio</code>). Dazu den Text unten in das Attribut <code>setList</code> des <code>''sonos2mqtt_speaker''</code> Devices hinzufügen:
<syntaxhighlight lang="perl">
toggleRadio:noArg {my $dev = (devspec2array('model=sonos2mqtt_bridge'))[0];my $r=Each($dev,ReadingsVal($dev,'favlist',''));my $tts="SonosTTS";fhem("set $tts tts Es folgt $r;sleep $tts:playing:.0;set $NAME playUri [$tts:httpName];sleep $NAME:play;sleep $NAME:PLAYING;sleep $NAME:STOPPED;set $NAME playFav $r")}
</syntaxhighlight>

== Dokumentationen und weitere Entwicklungen ==
ToDo

Erweiterung um Alarmhandling siehe [https://forum.fhem.de/index.php/topic,111711.msg1162031.html#msg1162031 Forum]

[[Kategorie:MQTT]]

MQTT2-Module - Praxisbeispiele

2024-11-15T14:15:30Z

TomLee: Beispiel ergänzt: numerische Werte runden

== Einführung: MQTT bzw. MQTT2 in FHEM ==
{{Randnotiz|RNTyp=y|RNText=Sollten Sie MQTT2_CLIENT verwenden, beachten Sie bitte, dass der MQTT2_CLIENT die ursprüngliche Herkunft der über MQTT verteilten Informationen nicht kennt. Daher ergeben sich in der Anwendung kleinere Unterschiede, zu deren Verständnis die diesbezüglichen [[MQTT2_CLIENT#Anwendung|Hinweise zu MQTT2_CLIENT]] bekannt sein sollten.}}Zur Einbindung von Geräten, welche zur Nutzung des MQTT-Protokols konfiguriert werden können und darüber mit einem MQTT-Server (früher: Broker) kommunizieren, stehen unter FHEM verschiedene Optionen zur Verfügung, wobei nicht alle Module beliebig miteinander verwendet werden können. Details hierzu sind dieser [[MQTT|Übersicht]] zu entnehmen.

Im Rahmen dieses Artikels wird für die eigentlichen Geräte [[MQTT2 DEVICE|MQTT2_DEVICE]] verwendet, damit wird als IO-Device entweder {{Link2CmdRef|Anker=MQTT2_SERVER|Lang=en|Label=MQTT2_SERVER}} oder [[MQTT2 CLIENT|MQTT2_CLIENT]] benötigt, mit einem IO-Device des Typs [[MQTT (Modul)|MQTT]] funktioniert die nachfolgende Darstellung dagegen nicht<ref>Allerdings können die Konfigurationen in der Regel recht einfach auf die bisherige MQTT-Implementierung übertragen werden</ref>. MQTT2_DEVICE unterstützt u.a. auch die ''setExtensions'' direkt, also z.B. ''on-for-timer<ref>Beachten Sie bei mehrkanaligen Geräten, dass jeweils nur ein Hauptkanal mittels setExtensions verwaltet werden kann! U.a. aus diesen Grund ist es meist sinnvoller, die ''split''-Varianten der attrTemplate-Einrichtung zu verwenden.</ref>'' sowie ''[[MQTT2-Module - Praxisbeispiele#attrTemplate_2|attrTemplate]]''<ref>Auch MQTT_DEVICE unterstützt SetExtensions, allerdings muss dies dort per Attribut eingeschaltet werden</ref>.

=== Allgemeine Einstellungen und Hinweise ===
{{Randnotiz|RNTyp=r|RNText=Beachten Sie, dass für [[autocreate]] in Verbindung mit MQTT2_SERVER '''zwingend''' jeder über MQTT kommunizierende Client eine ClientID angeben muss. Passen Sie daher ggf. die Einstellungen Ihres Geräts an. Manche Geräte verwenden auch "Wegwerf"-ClientID's. Für diese empfiehlt es sich, ggf. dann die durch autocreate erstellten Geräte nachzubearbeiten und die ClientID-Angabe v.a. aus den Inhalten des readingList-Attributs zu entfernen.}}Die nachfolgenden Beispiele gelingen am einfachsten mit '''MQTT2_SERVER als Server ("Broker")''', für diesen sollte dabei ''autocreate'' '''nicht deaktiviert''' sein, damit die erforderlichen MQTT2_DEVICES soweit möglich automatisiert erstellt werden<ref>Dabei wird vorausgesetzt, dass ein allgemeines {{Link2CmdRef|Anker=autocreate|Lang=en|Label=autocreate}}-Device (''TYPE=autocreate'') ebenfalls aktiv ist.</ref> .

Beispiel<ref>MQTT2_SERVER verwendet als default-Einstellung für ''autocreate'' ''simple'', ohne dass ein entsprechendes Attribut gesetzt werden müsste. Die Einstellung ''complex'' empfiehlt sich in der Regel nicht; diese ist jedoch dann zu empfehlen, wenn das Device entweder verschachtelte JSON-Array-Strukturen liefert oder bestimmte Readings nicht gefüllt werden sollen.</ref>:
define MQTT2_FHEM_Server MQTT2_SERVER 1883 global

Falls der MQTT Broker mit Hilfe von [[allowed]] abgesichert wurde, muss in den Geräten ebenfalls User bzw. Passwort eingetragen werden, damit eine MQTT Kommunikation möglich ist.

{{Hinweis|Die Code-Darstellung in diesem Beitrag entspricht jeweils dem RAW-Format zum [[Import von Code Snippets]]. Wer die Attribute direkt und einzeln bearbeitet, muss ggf. die "\" entfernen!}}

=== MQTT-Einstellungen in den Geräten ===
Die Beispiele gehen davon aus, dass die einzubindenden Geräte '''''mit den default-Einstellungen''''' für MQTT betrieben werden, wenn man von den Angaben zum Server und ggf. der Gerätekennung absieht. Es sollten also insbesondere '''keine Veränderungen der topic-Pfade''' vorgenommen werden.

{{Hinweis|Einige der hier beschriebenen Einstellungen haben Änderungen der sich durch die jeweiligen Automatismen eigentlich jeweils ergebenden Standard-Werte zur Folge, insbesondere, was Reading-Namen und von den Geräten gesendete Werte angeht. Sie sollten daher zunächst die Konfiguration des jeweiligen MQTT2-DEVICE-Geräts abschließen, und erst anschließend die weitere Integration mit Event-Handlern, logging usw. vornehmen. }}

=== auto-Konfigurations-features ===
Viele firmwares und Dienste bieten Möglichkeiten an, einer Controller-Software (insbesondere homeassistant) Hilfsdaten zur automatisierten Konfiguration bereitzustellen. Da FHEM diese Daten nicht zu ihrem ursprünglichen Zweck verwenden kann, werden hierdurch lediglich zusätzliche Readings erzeugt, mit denen man als User in der Regel wenig anfangen kann. Es wird daher empfohlen, derartige features '''abzuschalten'''. Wo dies nicht möglich ist, sollte man eine passende [[MQTT2_CLIENT#ignoreRegexp|ignoreRegexp]] setzen bzw. diese passend erweitern!

=== Schritt für Schritt ===
Hier werden in der Regel fertige Konfigurationen für häufige Anwendungsfälle (beispielhaft) dargestellt. In [[MQTT2_DEVICE - Schritt für Schritt]] ist etwas mehr über die Vorgehensweise bei der Zusammenstellung der verschiedenen Attribute und deren Zusammenwirken zu erfahren.

== zigbee2mqtt ==
[[Bild:MQTT2_zigbee2mqtt_Bulbs.png|400px|thumb|Darstellung in FHEMWEB]]
[https://www.zigbee2mqtt.io zigbee2mqtt] ist ein open-source Projekt, mit dem zigbee-Geräte über MQTT direkt angesprochen werden können, ohne dass hierfür eine Bridge eines Herstellers benötigt wird.

Einzelheiten zur Vorgehensweise sind auf der Detailseite [[Zigbee2mqtt|zigbee2mqtt]] zu finden.

== Tasmota ==
{{Randnotiz|RNTyp=r|RNText=Bitte beachten Sie, dass versicherungsrechtliche Probleme entstehen können, wenn die herstellereigene Firmware ersetzt wird!}}[https://github.com/arendst/Sonoff-Tasmota Tasmota] ('''T'''heo '''A'''rends '''S'''onoff '''M'''QTT '''O'''ver '''T'''he '''A'''ir - einer offenen Firmware von [https://github.com/arendst arendst]) ist eine open-source Software für ESP8266-Geräte, die z.B. statt der originalen Firmware für Sonoff-Geräte und andere ESP8266-basierte WLAN-Steckdosen usw. verwendet werden kann.
{{Hinweis|[[Datei:Tasmota mqtt config.png|120px|thumb|right]]Vor allem, aber nicht nur bei Verwendung des MQTT2_CLIENT als IO, ist es empfehlenswert, in der MQTT-Konfiguration der tasmota-Geräte für den Parameter ''<nowiki>topic = %topic% (tasmota)</nowiki>'' ebenfalls die dynamisch aus der Chip-ID erzeugte Kennung ''DVES_%06X'' zu verwenden. (Kopieren Sie einfach diese Zeichenkette aus dem Eingabefeld für ''"client ..."'', siehe nebenstehende Abbildung). Die eigentliche Umbenennung zu einem "sprechenden Namen" kann dann innerhalb von FHEM - mittels ''rename'' oder ggf. mit einem ''alias'' - erfolgen.}}
=== MQTT2_DEVICE ===
Dieses sollte bei aktiviertem ''autocreate'' am MQTT2_SERVER-Device automatisch angelegt werden, sobald das betreffende Gerät eingesteckt oder neu gestartet oder an einem evtl. vorhandenen Taster geschalten wird. Bislang wurden Tasmota version(en) ab 6.1.1 bis min. 8.1.0 getestet, dies auf verschiedener Hardware, zunächst mit Sonoff Touch und S20, zwischenzeitlich mit einer Vielzahl von Geräten, die per USB-Adapter oder mit der Methode aus dem [https://www.heise.de/ct/artikel/Tuya-Convert-IoT-Geraete-ohne-Loeten-vom-Cloud-Zwang-befreien-4283623.html Tuya-Convert]-Projekt des heise-Verlags auf Tasmota umgeflasht wurden.

=== Manuelle Anpassungen - Schalter ===
Die RAW-Definition kann dann beispielsweise wie folgt ergänzt werden:
<syntaxhighlight lang="perl">
defmod MQTT2_DVES_9B01BD MQTT2_DEVICE DVES_9B01BD
attr MQTT2_DVES_9B01BD IODev m2server
attr MQTT2_DVES_9B01BD devStateIcon on:FS20.on:off off:FS20.off:on
attr MQTT2_DVES_9B01BD readingList DVES_9B01BD:tele/DVES_9B01BD/STATE:.* { json2nameValue($EVENT) }\
DVES_9B01BD:tele/DVES_9B01BD/LWT:.* LWT\
DVES_9B01BD:tele/DVES_9B01BD/UPTIME:.* { json2nameValue($EVENT) }\
DVES_9B01BD:tele/DVES_9B01BD/SENSOR:.* { json2nameValue($EVENT) }\
DVES_9B01BD:tele/DVES_9B01BD/INFO1:.* { json2nameValue($EVENT) }\
DVES_9B01BD:tele/DVES_9B01BD/INFO2:.* { json2nameValue($EVENT) }\
DVES_9B01BD:tele/DVES_9B01BD/INFO3:.* { json2nameValue($EVENT) }\
DVES_9B01BD:stat/DVES_9B01BD/RESULT:.* { json2nameValue($EVENT) }\
DVES_9B01BD:stat/DVES_9B01BD/STATE:.* { json2nameValue($EVENT) }
attr MQTT2_DVES_9B01BD room MQTT2_DEVICE
attr MQTT2_DVES_9B01BD setList on cmnd/DVES_9B01BD/POWER on\
off cmnd/DVES_9B01BD/POWER off\
reboot cmnd/DVES_9B01BD/Restart 1
attr MQTT2_DVES_9B01BD webCmd on:off:reboot
</syntaxhighlight>

=== Manuelle Anpassungen - Dimmer ===
{{Randnotiz|RNTyp=r|RNText=Dieses Beispiel ist nur bedingt zur Nachahmung zu empfehlen: Prinzipiell kann man Readings und setter in MQTT2_DEVICE fast nach Belieben benennen. Wählt man allerdings <i>FHEM-typische</i> Namen, kann dies sehr zur Vereinfachung beitragen. Z.B. wird eine Sprachssteuerung bei einem Dimmer üblicherweise automatisch korrekt eingestellt werden, wenn der für die Helligkeit zuständige setter z.B. <i>pct</i> (oder <i>brightness</i>) heißt, oder eine abzufragende Temperatur <i>temperature</i>. Entsprechendes gilt im Rahmen von <i>devspec-Abfragen</i>.}}Bei einem Dimmer sind einige zusätzliche Anpassungen vorzunehmen. Ein Dimmer wird über '''POWER''' geschaltet und über '''Dimmer''' gedimmt. Damit das funktioniert, müssen ein stateFormat und devStateIcon zusammenarbeiten:
<syntaxhighlight lang="perl">
attr MQTT2_DVES_2DF34D devStateIcon 10\d.*:dim100%@orange:off 1\d.*:dim12%@orange:off 2\d.*:dim18%@orange:off 3\d.*:dim31%@orange:off 4\d.*:dim43%@orange:off 5\d.*:dim50%@orange:off 6\d.*:dim62%@orange:off 7\d.*:dim68%@orange:off 8\d.*:dim81%@orange:off 9\d.*:dim93%@orange:off 0:FS20.off:on .*:FS20.off@orange:off
attr MQTT2_DVES_2DF34D stateFormat {if(ReadingsVal($name,"POWER",0)eq"off"){0}else{ReadingsVal($name,"Dimmer",0)}}
</syntaxhighlight>
Nun kann man über das Icon ein- und ausschalten und der Zustand des Dimmers wird korrekt angezeigt.

Es fehlt noch ein Slider, um auch dimmen zu können. Zusätzlich muss setList noch um Dimmer erweitert werden:
<syntaxhighlight lang="text">
attr MQTT2_DVES_2DF34D setList on cmnd/dimmer/POWER on\
off cmnd/dimmer/POWER off\
Dimmer cmnd/dimmer/Dimmer
attr MQTT2_DVES_2DF34D webCmd Dimmer
attr MQTT2_DVES_2DF34D widgetOverride Dimmer:slider,0,1,100
</syntaxhighlight>

=== attrTemplate ===
===== Allgemeines =====
Für gängige Tasmota-Geräte stehen ''templates'' bereit, mit denen sich diese schnell konfigurieren lassen.
Beachten Sie dazu den Abschnitt ''attrTemplate'' in [[MQTT2 DEVICE#attrTemplate|MQTT2_DEVICE]]. Bei Anwendung eines template mit "split" im Namen werden dabei weitere Geräte angelegt und konfiguriert.{{Hinweis|Bitte attrTemplates nicht verwechseln mit templates, die auf den Tasmota- bzw. Blackadder-Seiten angeboten werden, welche zur Konfiguration der firmware genutzt werden können! Es sollte zunächst die firmware korrekt eingerichtet werden, so dass das Gerät selbst direkt auf dessen Web-Interface korrekt bedient werden kann.}}

===== Kein passendes attrTemplate vorhanden? =====
Exisitert (noch) kein passendes attrTemplate, ist zu empfehlen, zunächst das "''tasmota_basic''" anzuwenden. Dieses führt einige Basiskonfigurationen durch, die für FHEM hilfreich sind, z.B. wird die firmware so eingestellt, dass Schaltzustände in Kleinschreibung übermittelt werden, statt der defaults "ON" bzw. "OFF".

Allerdings stellt dieses das ''autocreate'' an dem MQTT2_DEVICE auf 0, was dann nicht optimal ist, wenn man weitere Readings aus dem Gerät erwartet, etwa, weil zusätzliche Sensoren vorhanden sind. In diesem Fall empfiehlt es sich, das ''autocreate''-Attribut an dem MQTT2_DEVICE zu löschen, damit alle weiteren Informationen verarbeitet werden und ggf. im ''jsonMap''-Attribut nur die Angabe "''POWER1:state''" zu belassen.

=== on-for-timer ===
Um z.B. ein Relais nur für einen Zeitraum anzuschalten, kann man bei Tasmota-Geräten zwischen mehrere Varianten wählen. Ohne speziellen ''setter'' in der ''setList'' werden die '''SetExtensions''' verwendet. Timer laufen damit innerhalb FHEM. Da diese intern als temporäres [[at]] ausgeführt werden, sind diese auch noch nach einem FHEM-Neustart vorhanden, sofern FHEM ordnungsgemäß beendet und neu gestartet wird.

Die Tasmota-firmware bietet ergänzend dazu zwei Möglichkeiten an, bei denen der Timer direkt auf dem ESP-Microcontroller verwaltet wird:

==== delay ====
Zeile zur Erweiterung der ''setList'' (Attributeingabe via FHEMWEB!):
on-for-timer {my $duration = $EVTPART1*10; 'cmnd/DVES_575127/Backlog POWER1 1; delay '.$duration.'; POWER1 0'}

Ohne Auswirkungen auf alles, was danach kommt, hat aber den Nachteil, dass die möglichen Zeitspannen auf 3600 1/10 Sekunden begrenzt sind (siehe [https://tasmota.github.io/docs/Commands/#delay Commands - Tasmota Delay]), also 6 Minuten.

====pulseTime ====
Zeile zur Erweiterung der ''setList'' (s.o.):
on-for-timer {my $duration = $EVTPART1 < 11.2 ? $EVTPART1*10 : $EVTPART1+100; 'CMNDTOPIC/Backlog pulseTime1 '.$duration.'; POWER1 1'}
Auch hier sind die möglichen längsten Einschaltdauern begrenzt, allerdings ist diese mit 18h deutlich länger als mit ''delay''. Diese Implementierung hat den Nachteil, dass der ESP-Microcontroller die jeweils letzte pulseTime auch für alle weiteren "normalen" Einschaltvorgänge berücksichtigt, das Relais also ebenfalls nach Ablauf der übermittelten pulseTime abgeschaltet wird; dies gilt allerdings ohne explizites ''save'' nur bis zum nächsten reboot des Microcontrollers.

Da nach dem ersten pulseTime setzten, diese immer benutzt wird, kann man mit einem kleine Workaround das Device normal arbeiten lassen. Dafür wird bei jedem anderem Befehl, aus der PulseTime, der Timer deaktiviert.
Hierfür machen wir uns zu nutzen, dass man mehrere Befehle gleichzeitig an Tasmota senden kann (backlog). Ob diese Lösung auch mit anderen MQTT Firmwares funktioniert, kann ich nicht sagen. Es wurde lediglich mit Tasmota getestet.
Wir senden also, bevor wir den eigentlich Tasmota Befehl zum Ein- oder Ausschalten schicken, einen Befehl zum deaktivieren des Timers: "pulseTime 0"
Hier ein Beispiel: (das entsprechende device "DEV_611F3E" muss gegen das eigene ersetzt werden)
off:noArg cmnd/DVES_611F3E/backlog pulseTime 0; POWER1 0
on:noArg cmnd/DVES_611F3E/backlog pulseTime 0; POWER1 1
toggle:noArg cmnd/DVES_611F3E/backlog pulseTime 0; POWER1 2

=== zigbee2tasmota ===
[https://tasmota.github.io/docs/Zigbee/ zigbee2tasmota] ist eine Erweiterung der Tasmota-firmware für Microcontroller, insbesondere dem ESP8266 (und ESP32)(link), über die einige ZigBee-Chipsätze (insbesondere TI CC2530) als [[ZigBee#Koordinator_.28ZigBee_coordinator.2C_ZC.29|Coordinator]] eingebunden werden können, um ein ZigBee-Netzwerk aufzubauen.
{{Hinweis|Stand 08/2020 war die Einbindung anderer Chipsätze erst in einem Alpha-Stadium; die Zahl der über einen CC2530 einbindbaren ZigBee-Geräte ist daher derzeit relativ begrenzt (ca. 16)!}}
Auch für diese Lösung stehen einige ''attrTemplate'' zur Verfügung. Nähere Informationen hierzu sind dem Artikel [[Zigbee2Tasmota-MQTT]] zu entnehmen.

== ESPurna ==
ESPurna ist eine weitere alternative firmware für ESP8266-basierte Geräte, Details sind der [https://github.com/xoseperez/espurna/wiki Projektseite] zu entnehmen.

Das Format, in dem ESPurna Daten sendet, unterscheidet sich v.a. darin, dass bool'sche Werte als 0 oder 1 gesendet werden, und nicht wie sonst üblich als "on" oder "off" oä.. Es stehen einige Mustertemplates zur Verfügung, um diese Art der Payload in FHEM-konforme Werte zu überführen.

== Shelly ==
=== Vorbemerkung ===
Auch für Shelly-Geräte steht eine Auswahl an [[MQTT2-Module - Praxisbeispiele#attrTemplate_2|templates]] bereit.
Beachten Sie auch hier, dass uU. bei Anwendung eines template mit "split" im Namen weitere Geräte angelegt und konfiguriert werden.

Standardmäßig senden die Shelly-Geräte ihren kompletten Status alle 30 Sekunden. Dies kann man über den Parameter ''mqtt_update_period'' in den ''settings'' ändern, allerdings ist dieser nur über die HTTP-Schnittstelle des Shelly verfügbar. Um diese Statusupdates abzustellen, kann über den Browser folgender Befehl verwendet werden:
http://<ip-des-shelly>/settings?mqtt_update_period=0,
Soweit bekannt, werden dann nur statische updates ausgeschaltet, z.B. für das Relay bzw. angeschlossene Taster oder Schalter; insbesondere Verbrauchswerte werden dennoch aktualisiert.

=== Shelly1 ===

=== Shellybulb ===
Zunächst muss man einen Statusupdate des Shellybulb erzwingen (Aus- und Einschalten, physikalisch oder per Web-UI), damit das Gerät bei eingeschaltetem autocreate angelegt wird. Dies sieht zunächst so aus:
Internals:
CFGFN
CID shellybulb_3CC533
DEF shellybulb_3CC533
DEVICETOPIC MQTT2_shellybulb_3CC533
IODev MQTT2_FHEM_Server
NAME MQTT2_shellybulb_3CC533
NR 246
STATE ???
TYPE MQTT2_DEVICE
READINGS:
2018-12-12 19:28:08 status_blue 0
2018-12-12 19:28:08 status_brightness 61
2018-12-12 19:28:08 status_effect 0
2018-12-12 19:28:08 status_gain 26
2018-12-12 19:28:08 status_green 0
2018-12-12 19:28:08 status_ison true
2018-12-12 19:28:08 status_mode color
2018-12-12 19:28:08 status_red 255
2018-12-12 19:28:08 status_temp 3250
2018-12-12 19:28:08 status_white 0
Attributes:
IODev MQTT2_FHEM_Server
readingList shellybulb_3CC533:shellies/shellybulb-3CC533/color/0/status:.* { json2nameValue($EVENT, 'status_') }
room MQTT2_DEVICE
[[Bild:MQTT2 Shellybulb.png|400px|thumb|Darstellung in FHEMWEB nach Anwendung des template]]Dann bei den set-Anweisungen das attrTemplate "shellybulb" auswählen und setzen. Es erscheint eine Abfrage, ob die vorhandenen Readings gelöscht werden sollen. Diese bitte bestätigen und die Seite neu laden. Danach einmal An- und Ausschalten, damit die Readings auch durch einen neuen Status initialisiert werden und die Seite im Browser neu laden.

=== Shelly Plug S ===
Über die Leistungsmessung des Shelly Plug S lässt sich sehr einfach auch eine Erkennung des Betriebszustandes des angeschlossenen Gerätes realisieren. Dazu stellt man zuerst fest, wieviel Leistung das Gerät in jedem Betriebszustand verbraucht und kann dann z.B. für einen angeschlossenen Fernseher, der im Standby 1 Watt und im Betrieb > 100 Watt verbraucht, den Zustand erkennen und als on/off Status anzeigen. Dazu wird das state Reading wie folgt definiert:
attr readingList shellies/shellyplug-s-123456/relay/0/power:.* { { state => $EVTPART0<100?"off":"on" } }
Der Status des MQTT2 Devices zeigt dann bei <100W "off" und sonst "on" an.

=== HTTP-Commands ===
In diesem {{Link2Forum|Topic=102369|LinkText=Forumsbeitrag}} wird eine Lösung vorgestellt, um über [[99 myUtils anlegen|myUtils-Code]] weitere Kommandos bereitzustellen, die sonst nur direkt über das Web-Interface zu erreichen sind.

== Shelly Gen2 ==
=== Vorbereitung ===
Shelly mit dem WLAN verbinden, entweder über die Shelly APP oder per Laptop auf den Offenen AP des Shelly verbinden und dann übers WebUI des Shelly mit dem Heimischen WLAN verbinden. Über die APP geht dies meist etwas einfach und schneller, besonders wenn man mehrere Shelly Geräte hinzufügen möchte. Durch die BT Unterstützung der Gen2 Geräte, klappt dies meist auch deutlich schneller und zuverlässiger als noch bei Gen 1 Geräten.
Nachdem der Shelly mit dem WLAN verbunden ist, sollte die Firmware überprüft und gegebenenfalls aktualisiert werden (Stand Anfang 2022 scheint die firmware noch nicht voll ausgereift gewesen zu sein, da dass insbesondere die MQTT-Schnittstelle immer wieder überarbeitet wurde). Bitte KEINE BETA Versionen installieren, wenn nicht dazu aufgefordert wurde.
Nach dem, durch das Update ausgelösten, Neustart kurz Prüfen ob die Uhrzeit passt, wenn trotz richtiger Zeitzone die Uhrzeit nicht stimmt hilft ein weiterer Neustart.
Nun auf Networks| Internet (leider in APP und WebUI unterschiedlich), hier auf MQTT und die Einstellungen für den verwendeten MQTT Server treffen. Diese Einstellungen werden auch wieder durch Neustart übernommen.
=== Shelly Plus 1 ===
Zunächst muss man einen Statusupdate des Shelly erzwingen (Aus- und Einschalten, physikalisch oder per Web-UI), damit das Gerät bei eingeschaltetem autocreate angelegt wird. Dies sieht zunächst so aus:
<syntaxhighlight lang="text">
defmod MQTT2_shellyplus1_441793a34044 MQTT2_DEVICE shellyplus1_441793a34044
attr MQTT2_shellyplus1_441793a34044 readingList shellyplus1_441793a34044:shellyplus1-441793a34044/online:.* online\
shellyplus1_441793a34044:shellyplus1-441793a34044/status/mqtt:.* { json2nameValue($EVENT) }\
shellyplus1_441793a34044:shellyplus1-441793a34044/events/rpc:.* { json2nameValue($EVENT) }\
shellyplus1_441793a34044:shellyplus1-441793a34044/status/sys:.* { json2nameValue($EVENT) }\
shellyplus1_441793a34044:shellyplus1-441793a34044/status/switch_0:.* { json2nameValue($EVENT) }
attr MQTT2_shellyplus1_441793a34044 room MQTT2_DEVICE

setstate MQTT2_shellyplus1_441793a34044 2022-03-05 11:08:24 IODev m2s
setstate MQTT2_shellyplus1_441793a34044 2022-03-05 11:08:31 available_updates_beta_version 0.10.0-beta6
setstate MQTT2_shellyplus1_441793a34044 2022-03-05 11:08:31 cfg_rev 7
setstate MQTT2_shellyplus1_441793a34044 2022-03-05 11:08:24 connected true
setstate MQTT2_shellyplus1_441793a34044 2022-03-05 11:09:12 dst shellyplus1-441793a34044/events
setstate MQTT2_shellyplus1_441793a34044 2022-03-05 11:08:31 fs_free 237568
setstate MQTT2_shellyplus1_441793a34044 2022-03-05 11:08:31 fs_size 458752
setstate MQTT2_shellyplus1_441793a34044 2022-03-05 11:09:12 id 0
setstate MQTT2_shellyplus1_441793a34044 2022-03-05 11:08:31 mac 441793A34044
setstate MQTT2_shellyplus1_441793a34044 2022-03-05 11:09:12 method NotifyStatus
setstate MQTT2_shellyplus1_441793a34044 2022-03-05 11:08:24 online true
setstate MQTT2_shellyplus1_441793a34044 2022-03-05 11:09:12 output false
setstate MQTT2_shellyplus1_441793a34044 2022-03-05 11:08:24 params_mqtt_connected true
setstate MQTT2_shellyplus1_441793a34044 2022-03-05 11:09:12 params_switch_0_id 0
setstate MQTT2_shellyplus1_441793a34044 2022-03-05 11:09:12 params_switch_0_output false
setstate MQTT2_shellyplus1_441793a34044 2022-03-05 11:09:12 params_switch_0_source WS_in
setstate MQTT2_shellyplus1_441793a34044 2022-03-05 11:08:24 params_switch_0_temperature_tC 39.88
setstate MQTT2_shellyplus1_441793a34044 2022-03-05 11:08:24 params_switch_0_temperature_tF 103.78
setstate MQTT2_shellyplus1_441793a34044 2022-03-05 11:08:31 params_sys_available_updates_beta_version 0.10.0-beta6
setstate MQTT2_shellyplus1_441793a34044 2022-03-05 11:09:12 params_ts 1646474952.66
setstate MQTT2_shellyplus1_441793a34044 2022-03-05 11:08:24 params_wifi_rssi -57
setstate MQTT2_shellyplus1_441793a34044 2022-03-05 11:08:24 params_wifi_ssid WLAN-Alex
setstate MQTT2_shellyplus1_441793a34044 2022-03-05 11:08:24 params_wifi_sta_ip 192.168.177.167
setstate MQTT2_shellyplus1_441793a34044 2022-03-05 11:08:24 params_wifi_status got ip
setstate MQTT2_shellyplus1_441793a34044 2022-03-05 11:08:31 ram_free 179764
setstate MQTT2_shellyplus1_441793a34044 2022-03-05 11:08:31 ram_size 249456
setstate MQTT2_shellyplus1_441793a34044 2022-03-05 11:08:31 restart_required false
setstate MQTT2_shellyplus1_441793a34044 2022-03-05 11:09:12 source WS_in
setstate MQTT2_shellyplus1_441793a34044 2022-03-05 11:09:12 src shellyplus1-441793a34044
setstate MQTT2_shellyplus1_441793a34044 2022-03-05 11:09:12 temperature_tC 39.9
setstate MQTT2_shellyplus1_441793a34044 2022-03-05 11:09:12 temperature_tF 103.9
setstate MQTT2_shellyplus1_441793a34044 2022-03-05 11:08:31 time 11:08
setstate MQTT2_shellyplus1_441793a34044 2022-03-05 11:08:31 unixtime 1646474911
setstate MQTT2_shellyplus1_441793a34044 2022-03-05 11:08:31 uptime 7
</syntaxhighlight>

Über die set Anweisung unterhalb der Device Übersicht können wir ein attrTemplate wählen; shellyPlus_1
Es erscheint eine kurze Übersicht was im Template enthalten ist, dieses befindet sich noch im Aufbau und wird aktuell von der Community aufgebaut und weiterentwickelt. Mit einem Klick auf „set“ laden wir das Template und übernehmen die Einstellungen für den Shelly Plus 1.
Damit ist der Shelly bereit, im Status wird neben dem Namen auch der Onlinestatus des Shellys (grüner | roter Punkt) so wie eine Lampe mit Toggle (on | off) Funktion und die Temperatur des Shellys angezeigt. Darüber hinaus verschwindet die Lampe und wird durch einen klickbaren Hinweis ersetzt, wenn ein Neustart des Shellys nötig ist.

=== Tipps ===
{{Randnotiz|RNTyp=g|RNText=So nimmt man bei Verwendung eines normalen Schalters (eine Stellung EIN eine AUS) gerne den „Flip“ Mode – damit wird der Shelly IMMER umgeschaltet, egal in welche Stellung der Schalter sich bewegt („Kreuzschaltung“). Diese Einstellungen trifft man grundlegend im WebUI des Shelly (oder APP) unter „Channel settings“.
Für den „Flip“ müssen wir die Grundeinstellung des „Power on default“ auch ändern (gleiche Seite) - persönlich wähle ich „Restore last“, also: nach Stromausfall wird der letzte Zustand wieder hergestellt; grundsätzlich gehen alle Modi außer „Match input“.
}}
Das aktuelle Template wurde um die Funktion erweitert, den Button Mode umzuschalten. In den meisten Fällen legt man sich auf eine Schaltmethode fest, welche zum Hardware Setup passt.

Manchmal will man aber vielleicht den Hardware Schalter deaktivieren, nennen wir es „Kindersicherung“. Bei Shelly heißt das „detached“.
Diese Funktion wurde ins Template als „in_mode“ Übernommen. Mögliche set Befehle sind „flip“, „detached“ „toggle“. Bedingung zur Verwendung ist: „relay power on default“ darf NICHT „Match input“ sein. Sollte Follow statt Flip bevorzugt werden, müsste entsprechende Zeile in der setList von „flip“ auf „follow“ angepasst werden.

Der Befehlt lässt sich mit dem webCmd in_mode auch schnell zugänglich in die Übersicht vom Shelly setzen, so erhält man neben dem Status ein Dropdown mit flip detached und toggle zum schnellen umschalten. Mit webCmdLabel kann man noch einen Namen für das Dropdown setzen.

== OpenMQTTGateway ==
Um verschiedene Systeme wie BLE usw. auf MQTT zu bringen bietet sich [https://github.com/1technophile/OpenMQTTGateway OpenMQTTGateway] an, z.B. wird für das Auslesen vieler BLE-Seonsoren lediglich ein ESP32-Board ohne Zusatzhardware (ab ca. 5,- Euro in Fernost erhältlich) benötigt, auf das dann eine vorkompilierte firmware geflasht wird (hierfür wird ein USB-seriell-Wandler benötigt).

Nähere Details sind im Artikel [[OpenMQTTGateway]] zu finden.

== 8-Port-Ethernet Board ==
<gallery>
datei:8-relais-ethernetboard closed.jpg|mit Gehäuse
datei:8-Port-MQTT-Relais-Board.jpg|ohne Gehäuse
</gallery>
In diesem {{Link2Forum|Topic=107536|Message=1016379|LinkText=Forenbeitrag}} bzw. dem betreffenden Thread wurde ein Relais-Board vorgestellt, mit dem 8 Relais über Ethernetkabel verbunden werden, die Kommunikation erfolgt dann über MQTT. Über die verwendete Software ist wenig bekannt, es könnte jedoch sein, dass diese Art der Einbindung auch bei weiteren Boards funktioniert, die einen bestimmten Ethernet-Chipset von TI (DP83848) und eine Cortex M3 MCU verwenden.

== Milight-Bridge ==
=== Vorbemerkung ===
Der [https://github.com/sidoh/esp8266_milight_hub esp8266_milight_hub] ist ein open source- Projekt, mit dem auf Basis von ''openmili'' eine Vielzahl von MiLight-Geräten gesteuert werden können. Der MiLight-Hub erstetzt dabei eine beliebige Zahl von Milight-Bridges und ist auch zu verschiedenen Versionen des MiLight-Protokols kompatibel. Allerdings lassen sich manche MiLight-Geräte nicht an die Bridge anlernen, und es werden auch nicht alle Fernbedienungs-Typen voll unterstützt.
Neben MQTT kann dieser auch mit HTTPMOD oder Wifilight (bzw. den MiLight-Modulen) gesteuert werden. Die Hardware entspricht dabei im Wesentlichen einem MySensors-Wifi-Gateway<ref>Es wird lediglich ein anderer CS-PIN genutzt. Dies kann einfach in der Web-Oberfläche der Firmware umgestellt werden.</ref>.
Hier wird vorausgesetzt, dass eine funktionierende Bridge vorhanden ist und die zu steuernden Leuchtmittel mit dem Hub bereits verbunden (gepairt) sind bzw. entsprechende Fernbedienungs-Signale empfangen werden können (bei vorhandenem pairing eines Leuchtmittels an die Fernbedienung).
Der Vorteil der MQTT-Lösung liegt darin, dass man bei kompatiblen Fernbedienungen auch direkt Informationen über Schaltvorgänge erhält, die mit der Fernbedienung ausgelöst werden.

=== Einstellungen am MiLight-Hub ===
Die zum FHEM-Server bzw. dem MQTT2_SERVER passenden Vorgaben sind im Web-Interface des Hub einzustellen. Gegebenenfalls passen Sie die vom Hub zurückzugebenden Elemente im Web-Interface des Hub an.
Die Einstellungen für ''MQTT topic pattern'' usw. können auf den default-Werten<ref>Diese sind: <br>''milight/:device_id/:device_type/:group_id'' für "topic pattern"<br>''milight/updates/:hex_device_id/:device_type/:group_id'' für "update topic pattern"<br>''milight/states/:hex_device_id/:device_type/:group_id'' für "state topic pattern". Der Autor hat derzeit folgende Infotypen zum Senden markiert: "status, brightness, hue, color, mode, color_temp, bulb_mode, computed_color, hex_color" (enthält eventuell zu viele Angaben. Bei einem Eventhandler muss man uU. darauf achten, dass kurz hintereinander zweimal dasselbe Event kommen kann (für ON/OFF)).</ref> belassen werden, für die seit Mitte 2019 vorhandene Option, eine LWT-Message zu senden (''MQTT Client Status Topic''), tragen Sie ''milight/LWT'' ein und aktivieren ''Detailed''.

=== FHEM-Devices ===
[[Bild:MQTT2 MiLight.png|400px|thumb|Milight: Darstellung in FHEMWEB]]
==== Bridge ====
Wird nun über den Hub oder eine von diesem erkannte Fernbedienung ein vorhandenes Leuchtmittel geschaltet, wird bei eingeschaltetem autocreate ein erstes Device erstellt, die zunächst erstellte Definition sieht typischerweise etwa so aus:
defmod MQTT2_milight_hub_1370325 MQTT2_DEVICE milight_hub_1370325
attr MQTT2_milight_hub_1370325 IODev MQTT2_FHEM_Server
attr MQTT2_milight_hub_1370325 readingList milight_hub_1370325:milight/updates/0xBE59/rgbw/1:.* { json2nameValue($EVENT, '1_', $JSONMAP) }
attr MQTT2_milight_hub_1370325 room MQTT2_DEVICE

Auf dieses Device wird nun das ''template'' '''esp_milight_hub_bridge''' angewandt.

==== Einzelne Leuchtmittel ====

Wird nun nochmals das oben verwendete Leuchtmittel geschaltet, erstellt autocreate ein weiteres Device:
defmod MQTT2_milight_0xBE59_1 MQTT2_DEVICE milight_0xBE59_1
attr MQTT2_milight_0xBE59_1 IODev MQTT2_FHEM_Server
attr MQTT2_milight_0xBE59_1 readingList milight/states/0xBE59/rgbw/1:.* { json2nameValue($EVENT, '1_', $JSONMAP) }
attr MQTT2_milight_0xBE59_1 room MQTT2_DEVICE

Auf dieses wird nun eines der Bulb-templates angewendet. Wählt man das template X_01_esp_milight_hub_rgbw_bulb, wird eine einfache Variante erstellt, die neben einem toggelnden Icon nur Regler für Helligkeit, die Farbe und zwei Schaltflächen für den Weiß- und Nachtmodus enthält. Wer mehr oder andere Steuerelemente erhalten möchte, verwendet ein anderes template. Nicht benötigte Elemente kann man dabei einfach aus der Definition löschen.

Alle weiteren Devices werden genauso erstellt.

Um ein Device zu erhalten, mit dem sich alle Kanäle gleichzeitig steuern lassen, kann das template ''X_01a_esp_milight_hub_make_rgbw_group'' verwendet werden. Dieses verändert nicht das aktuelle Device, sondern erstellt '''eine Kopie''', die dann modifiziert wird. Diese Kopie ist unter dem Namen ''milight_<RemoteID>_0'' im selben Raum zu finden wie das Ausgangsgerät und kann ebenfalls an die eigenen Wünsche angepasst werden.

Weitere Beispiele:
Beispiel für ein RGB-CCT-Device:
defmod Licht_Wz_all MQTT2_DEVICE
attr Licht_Wz_all IODev MQTT2_Broker
attr Licht_Wz_all eventMap /set_white:Weiss/night_mode:Nacht/white_mode:white/on:on/off:off/ON:on/OFF:off/next_mode:Mode/mode_speed_up:Up/mode_speed_down:Down/
attr Licht_Wz_all group Licht
attr Licht_Wz_all icon light_control
attr Licht_Wz_all readingList milight/0x5D02/rgb_cct/0:.* { json2nameValue($EVENT) }\
milight/updates/0x5D02/rgb_cct/0:.* { json2nameValue($EVENT) }\
milight/states/0x5D02/rgb_cct/0:.* { json2nameValue($EVENT) }\

attr Licht_Wz_all room Wohnzimmer
attr Licht_Wz_all setList on milight/0x5D02/rgb_cct/0 {"status":"ON"}\
off milight/0x5D02/rgb_cct/0 {"status":"OFF"}\
level milight/0x5D02/rgb_cct/0 {"$EVTPART0":"$EVTPART1"}\
hue:colorpicker,HUE,0,1,359 milight/0x5D02/rgb_cct/0 {"$EVTPART0":"$EVTPART1"}\
command:uzsuSelectRadio,Weiss,Nacht,Mode,Up,Down milight/0x5D02/rgb_cct/0 {"$EVTPART0":"$EVTPART1"}\
brightness:colorpicker,BRI,0,1,255 milight/0x5D02/rgb_cct/0 {"$EVTPART0":"$EVTPART1"}\
next_mode milight/0x5D02/rgb_cct/0 {"$EVTPART0":"$EVTPART1"}\
mode_speed_up milight/0x5D02/rgb_cct/0 {"$EVTPART0":"$EVTPART1"}\
mode_speed_down milight/0x5D02/rgb_cct/0 {"$EVTPART0":"$EVTPART1"}\
saturation:colorpicker,BRI,0,1,100 milight/0x5D02/rgb_cct/0 {"$EVTPART0":"$EVTPART1"}\
color_temp:colorpicker,CT,153,1,370 milight/0x5D02/rgb_cct/0 {"$EVTPART0":"$EVTPART1"}\
device_id milight/0x5D02/rgb_cct/0 {"$EVTPART0":"$EVTPART1"}\
effect milight/0x5D02/rgb_cct/0 {"$EVTPART0":"$EVTPART1"}\
mode milight/0x5D02/rgb_cct/0 {"$EVTPART0":"$EVTPART1"}\
commands milight/0x5D02/rgb_cct/0 {"$EVTPART0":"$EVTPART1"}
attr Licht_Wz_all sortby 1
attr Licht_Wz_all webCmd command:brightness:saturation:color_temp:hue
attr Licht_Wz_all webCmdLabel command\
:brightness:saturation\
:color_temp:hue
==== Ein Leuchtmittel, mehrere Fernbedienungen ====
Pairt man mehrere Fernbedienungen mit einem Leuchtmittel, sollten auch alle entsprechenden Fernbedienungscodes in das readingList-Attribut übernommen werden. Dazu übernimmt man am einfachsten die Einträge aus den zusätzlichen MQTT2_DEVICEs. Benötigt man das zusätzliche Device nicht separat, um z.B. eine getrennte Gruppenschaltung zu realisieren, kann man dieses löschen. Beispiel-readingList für ein Device, das auf zwei Fernbedienungscodes und zwei Gruppen "hört":

attr Licht_Wz_all readingList milight/states/0x1234/rgbw/2:.* {json2nameValue($EVENT) }\
milight/updates/0x1234/rgbw/2:.* { json2nameValue($EVENT) }\
milight/states/0x1234/rgbw/0:.* { json2nameValue($EVENT) }\
milight/updates/0x1234/rgbw/0:.* { json2nameValue($EVENT) }\
milight/states/0xABCD/rgbw/0:.* { json2nameValue($EVENT) }\
milight/updates/0xABCD/rgbw/0:.* { json2nameValue($EVENT) }\
milight/states/0xABCD/rgbw/4:.* { json2nameValue($EVENT) }\
milight/updates/0xABCD/rgbw/4:.* { json2nameValue($EVENT) }

==== Fernbedienung als Input-Device nutzen ====
In diesem {{Link2Forum|Topic=103493|LinkText=Thread}} ist dargestellt, wie man eine Fernbedingung des Typs FUT089 dazu verwenden kann, einen [[MPD]] oder Rollladenaktoren zu steuern, oder diese Fernbedienung für [[Hue#HUE-Device|HUEDevice]]-Leuchtmittel zu nutzen.
Um hier nur Differenz-Meldungen direkt an die betreffende myUtils-Funktion zu übergeben und doppelte Events zu verhindern, sollte hier die readingList so angepasst werden, dass nur Messages aus dem "updates"-Zweig ausgewertet werden:
defmod MiLight_RC1_0 MQTT2_DEVICE milight_0xABCD_0
attr MiLight_RC1_0 readingList milight/states/0xABCD/fut089/[0-8]:.* {}
milight/updates/0xABCD/fut089/0:.* { FHEM::attrT_MiLight_Utils::MPDcontrol('myMPD',$EVENT, 'Yamaha_Main') }\
milight/updates/0x5D47/fut089/1:.* { FHEM::attrT_MiLight_Utils::FUT_to_RGBW('Licht_Stehlampe_links',$EVENT) }\
milight/updates/0x5D47/fut089/2:.* { FHEM::attrT_MiLight_Utils::FUT_to_RGBW('Licht_Stehlampe_rechts',$EVENT) }\
milight/updates/0x5D47/fut089/3:.* { FHEM::attrT_MiLight_Utils::four_Lights_matrix($EVENT, 'Licht_WoZi_Vorn_Aussen', 'Licht_WoZi_Vorn_Mitte', 'Licht_WoZi_Hinten_Aussen', 'Licht_WoZi_Hinten_Mitte') }\
milight/updates/0x5D47/fut089/4:.* { FHEM::attrT_MiLight_Utils::shuttercontrol('Jalousie_WZ',$EVENT) }\
milight/updates/0x5D47/fut089/5:.* { FHEM::attrT_MiLight_Utils::shuttercontrol('Rollladen_WZ_SSO',$EVENT) }\
milight/updates/0x5D47/fut089/6:.* { FHEM::attrT_MiLight_Utils::shuttercontrol('Rollladen_WZ_SSW',$EVENT) }\
milight/updates/0x5D47/fut089/7:.* {}\
milight/updates/0x5D47/fut089/8:.* {}
attr MiLight_RC_WZ stateFormat CommandSet

== eBus ==
An dieser Stelle sollen lediglich die Grundzüge erläutert werden, eine ausführliche Anleitung über die Konfiguration des [[EBUS-MQTT2|eBus mit MQTT2 gibt es hier]].

=== Vorbereitung und Definition am eBus ===
Vorausgesetzt wird ein laufender eBus-Dämon. Dessen Einrichtung wird im Artikel [[EBUS#Software|EBUS]] beschrieben.
In der Konfiguration des Dämons ( /etc/default/ebusd ) ist die Kommunikation über MQTT zu aktivieren und die Topic-Struktur festzulegen, z.B. ''ebusd/%circuit/%name''.
--accesslevel=* --mqttport=1883 --mqttjson --mqtthost=IpAdresseMQTTSERVER --mqtttopic=ebusd/%circuit/%name
{{Hinweis|Nachfolgend wird davon ausgegangen, dass als Vorgabe für mqtttopic ''ebusd'' verwendet wurde. Dies kann geändert werden, es wird aber dringend empfohlen, das mqtttopic in jedem Fall mit ''ebus...'' zu beginnen!}}

=== Vorbereitung und Definition in FHEM ===
Unabhängig von dem konkret genutzten IO-Modul (MQTT2_SERVER oder MQTT2_CLIENT) sollte an diesem '''''vor''''' den nachfolgenden Schritten zunächst das autocreate ausgeschaltet werden. Weiter sollte geprüft werden, ob es bereits MQTT2_DEVICE-Geräte gibt, die Einträge in der ''readingList'' enthalten, die vom ebus stammen. Da wir die ''readingList'' anschließend mit erweiterten JSON-Optionen erstellen wollen, müssen zumindest sämtliche ''readingList''-Attribute entsprechend bereinigt oder gelöscht werden; in der Regel ist es einfacher, diese Geräte nach dem Deaktivieren des autocreate am IO zu löschen.
{{Randnotiz|RNTyp=y|RNText=Sollten Sie MQTT2_CLIENT als IO nutzen, sollte für das weitere Vorgehen eine Kopie des MQTT2-"Sammeldevices" genutzt werden, und dessen ''CID'' auf ''ebusd'' geändert werden. Nach Anwendung des ebusd-splitter-templates müssen dann alle den ebus betreffenden Einträge aus der ''readingList'' des "Sammeldevices" gelöscht werden oder diese ganz gelöscht.}}Ist der ebus-Dämon lauffähig und für MQTT konfiguriert, sendet dieser regelmäßige Messages.

Sind die Vorbereitungen abgeschlossen, aktivieren wir ''autocreate'' wieder, allerdings wählen wir als autocreate-Methode ''complex'' aus, da der eBus-Dämon teilweise<ref>Dies betrifft vorrangig die Statusmeldungen</ref> eine weiter verschachtelte JSON-Struktur zum Versenden der Informationen verwendet als üblich. Danach wird wie bei den anderen o.g. Geräten automatisch ein neues MQTT2_DEVICE angelegt<ref>Bei Verwendung des MQTT2_CLIENT wird dann die ''readingList'' am bereits definierten MQTT2_DEVICE aus der Kopie des "Sammeldevice" automatisch wieder erstellt bzw. gefüllt.</ref>

==== "ebus-Bridge" ====
Auf das von ''autocreate'' erstellte MQTT2_DEVICE wird nunmehr das template ''eBus_daemon_splitter'' angewendet. Nach einiger Zeit sollte sowohl die readingList an diesem Device erweitert worden sein, wie auch ein oder mehrere neue MQTT2_DEVICE-Geräte angelegt.
Dieses Device liefert zukünftig Readings zum Dämon selbst, wie dessen ''uptime'', alle weiteren am eBus angeschlossenen Teilnehmer werden dagegen zweckmäßigerweise durch ein oder mehrere weitere MQTT2_DEVICE-Geräte dargestellt.

Das ''attrTemplate'' läd eine weitere ''attrTemplate''-file und [[99 myUtils anlegen|99_myUtils-Code]] vom FHEM-Server nach. Beides steht dann auch unmittelbar zur Nutzung zur Verfügung.
==== "ebusd_bai" und weitere Geräte ====
{{Hinweis|Der eBus-Dämon sendet nicht alle Informationen zu allen am eBus angeschlossenen Geräte automatisch. Diese müssen teilweise erst aktiv angefragt werden. Wie das im einzelnen erfolgen kann, ist dem o.g. Detailartikel zu entnehmen.}}
Funktioniert die Kommunikation zwischen dem eBus-Dämon und FHEM, sollte nach einigen Minuten zumindest ein weiteres Gerät namens ''MQTT2_ebus_bai'' angelegt worden sein.

== Sonos2Mqtt ==
Aus einem Versuch heraus ist ein {{Link2Forum|Topic=111711|LinkText=kleines Projekt}} geworden: Die Sonos Umgebung mit Hilfe von sonos2mqtt als generisches MQTT2_DEVICE komfortabel in FHEM einzubinden.

Mit Hilfe von ein paar Templates ist die grundlegende Einbindung in FHEM nach einer kleinen Installation auf Systemebene schnell erledigt. Es läuft derzeit noch zahlreiche Entwicklung und Ideenfindung, die Fortschritte sind live im Thread oder [[Sonos2mqtt|konsolidiert im Wiki]] zu finden.

=== Setup im System ===
Für dies Funktion wird der nodejs Server [https://github.com/svrooij/sonos2mqtt sonos2mqtt] benötigt. Entweder installiert man den lokal, irgendwo im Netzwerk oder nutzt den [[MQTT2-Module - Praxisbeispiele#Verwendung des Docker Containers|Docker Container.]]

Der nodejs Server sonos2mqtt kann aus Sicht von FHEM irgendwo im Netzwerk stehen - aber er muss im gleichen Netzwerk wie die Sonosplayer stehen. Das UPNP Sonosnetzwerk funktioniert nicht über Netzwerksegmente hinweg.

Eine Beschreibung aller Startparameter für sonos2mqtt findet man [https://svrooij.github.io/sonos2mqtt in der offiziellen Doku].

Erreicht der nodejs Server sonos2mqtt den MQTT Server nicht über - default: localhost, Port 1883, keine Anmeldung" - muss der Parameter --mqtt gesetzt werden!

Beispiele:
:<code>--mqtt mqtt://myuser:the_secret_password@192.168.0.3:1800</code> # alles gesetzt
:<code>--mqtt mqtt://192.168.0.3:1800</code> # IP Adresse und Port gesetzt, keine Anmeldung am MQTT Server
:<code>--mqtt mqtt://192.168.0.3</code> # IP Adresse gesetzt, Port ist Standard 1883

Erfolgt der Start mit pm2, werden die Parameter mit einem ''zusätzlichen'' doppelten Bindestrich (--) hinter dem nodejs Modul übergeben.

Beispiel:
<syntaxhighlight lang="perl">
pm2 start sonos2mqtt -- --mqtt mqtt://myuser:the_secret_password@192.168.0.3:1800
</syntaxhighlight>

'''Lokales Setup'''

Voraussetzung: nodejs und pm2 ist installiert und für alle Benutzer verfügbar. <syntaxhighlight lang="bash">
sudo npm install -g sonos2mqtt
</syntaxhighlight>
Je nach Entwicklungsstand sind auch Betaversionen verfügbar. Für aktuelle Betaversionen wird dieser Zusatz beim Setup verwendet. -> sonosmqtt@3.1.0-beta.1

Wird der sonos2mqtt Server auf einer anderen Maschine eingerichtet, ist der Start entsprechend diesem Absatz [[MQTT2-Module - Praxisbeispiele#Autostart von sonos2mqtt im System mit pm2 .28Alternative.29|Autostart von Sonos2mqtt im System mit pm2]] einzurichten.

=== Setup in FHEM ===
Man definiert lediglich ein Bridge Device, der Rest wird automatisch erledigt.

Voraussetzung:
* autocreate im System ist aktiv.
* Der verwendete MQTT2_SERVER steht auf '''autocreate simple''' (default/Standard).
* Templates aktuell - FHEM uptodate oder bei Bedarf in der FHEM Kommandozeile aktualisieren:
<pre>
{ Svn_GetFile("FHEM/lib/AttrTemplate/mqtt2.template", "FHEM/lib/AttrTemplate/mqtt2.template", sub(){ AttrTemplate_Initialize() }) }
</pre>
Bei der Anwendung des Templates für die Bridge wird das Attribut devicetopic ausgelesen oder auf default sonos gesetzt!

Wird ein anderer Devicetopic verwendet, muss der bei der Anlage der Bridge gesetzt werden!

Diese Zeilen einzeln in der FHEM Kommandozeile oder als Block in der Raw Definition. <syntaxhighlight lang="perl">
define SonosBridge MQTT2_DEVICE
attr SonosBridge room MQTT2_DEVICE
set SonosBridge attrTemplate sonos2mqtt_bridge_comfort
</syntaxhighlight>
Das Template sonos2mqtt_bridge_comfort:
* setzt das Template sonos2mqtt_bridge auf das Device,
* lädt die Datei 99_sonos2mqttUtils.pm aus dem contrib Ordner nach,
* definiert ein notify, dies erledigt im weiteren Betrieb die automatische Konfiguration der automatisch erzeugten MQTT2_DEVICEs.
** mit dem Template sonos2mqtt_speaker (das Template kann auch manuell auf vorhandene Player angewendet werden, die automatische Erzeugung der Player wird aber empfohlen)
** Ermittelt Detailinformation des jeweiligen Players (vor allem IP Adresse und Modelnumber)
** Lädt die Sonosgeräte Icons von den UPNP Devices herunter
** erweitert das setList input Kommando um den TV Eingang (HDMI, spdif) bzw. Line_IN Eingang falls vorhanden (Modelnumber)
* Die Player werden automatisch einzeln erzeugt wenn sie mqtt Nachrichten senden (Play/Stop) oder (alle sofort) wenn der sonos2mqtt Server gestartet wird.

==== Wozu dient die Bridge? ====
Sie stellt ein paar wesentliche Funktionen zu Verfügung
# Auffangen von nicht benötigten MQTT Nachrichten.
# Erzeugung/Weiterleitung von Nachrichten für die einzelnen Player - damit auch die Erzeugung von separaten Playern nach dem Schema MQTT2_RINCON12345678901234567.
# Statusanzeige sonos2mqtt als Reading connected (0 offline, 1 connected, 2 Player connected).
Sie kann zusätzlich als zentrales Device verwendet werden, um die Sonos Umgebung abzubilden, z.B. Readings für Favoriten u.ä.

==== Start sonos2mqtt lokal ====
Der Start / Stop des sonos2mqtt Servers innerhalb von FHEM ist nur lokal simpel möglich. Ist der Server irgendwo im Netzwerk oder im Docker Container, muss man andere Möglichkeiten finden. Der Neustart aus FHEM ist zwar praktisch, aber nicht erforderlich.

Wird eine existierenden Sonos Landschaft inhaltlich verändert (Player dazu/weg), muss der Server neu gestartet werden. Werden Player temporär abgeschaltet, merkt das der Server nach einer Zeit selbst, oder man forciert dies mit einem CheckSubscription an der Bridge.

Soll das Modul sonos2mqtt mit seinen default Einstellungen gestartet werden, genügt dieser kurze Befehl (in der FHEM Kommandozeile):
<syntaxhighlight lang="bash">
"pm2 start sonos2mqtt"
</syntaxhighlight>
Tipp: Verwendet man anstatt "Befehl" den Syntax {qx(Befehl)} in der FHEM Kommandozeile, wirkt der Befehl zwar blockierend aber die Ausgabe erfolgt im Browser und nicht im Logfile. Mit dem Parameter -s erfolgt keine Ausgabe.

==== Autostart von sonos2mqtt mit FHEM ====
Der Code startet sowohl das sonso2mqtt Modul sofort und implementiert ein notify für den zukünftigen automatischen Start beim Start von FHEM.
<syntaxhighlight lang="perl">
define n_pm2_sonos notify global:INITIALIZED|n_pm2_sonos:start "pm2 -s start sonos2mqtt"
trigger n_pm2_sonos start
</syntaxhighlight>

=== Autostart von sonos2mqtt im System mit pm2 (Alternative) ===
Der obige Code startet das sonos2mqtt nodejs Modul mit pm2 beim Start von FHEM. Sollte das nicht funktionieren oder nicht ins gesamte Konzept passen (weil z.B. mehrere nodejs Module geladen werden) kann der automatische Start direkt im System erfolgen. Zunächst dafür das oben eventuell schon definierte notify löschen!<syntaxhighlight lang="perl">
delete n_pm2_sonos
</syntaxhighlight>Der Start des Modul muss nicht mit erhöhten Rechten geschehen! Im Terminal folgendes eingeben (unter dem angemeldeten Benutzer wird sonos2mqtt später immer gestartet):<syntaxhighlight lang="bash">
pm2 start sonos2mqtt
pm2 startup
</syntaxhighlight>
Der letzte Befehl "redet", d.h. es gibt eine Ausgabe in der Art:
<syntaxhighlight lang="bash">
[PM2] To setup the Startup Script, copy/paste the following command:
sudo env PATH=$PATH:/usr/bin /usr/lib/node_modules/pm2/bin/pm2 startup systemd -u pi --hp /home/pi
</syntaxhighlight>
Man tut einfach genau das, was dasteht: die letzte Zeile kopieren und wieder einfügen und ausführen. Danach muss man die Konfiguration von pm2 noch sichern:
<syntaxhighlight lang="bash">
pm2 save
</syntaxhighlight>

=== Verwendung des Docker Containers ===
Ergänzend zur [https://svrooij.io/sonos2mqtt/getting-started.html#run-sonos2mqtt-in-docker Original Doku:]

Beim Container findet die Konfiguration der Verbindung zum FHEM in den Environment Variablen statt:
<syntaxhighlight lang="perl">
environment:
- SONOS2MQTT_DEVICE=192.168.56.207 # hier muss einer der Sonos Lautsprecher stehen
- SONOS2MQTT_MQTT=mqtt://192.168.56.121:1883 # mqtt2_server FHEM, erweiterter Syntax siehe oben
- SONOS_LISTENER_HOST=192.168.56.121 # Docker host IP
</syntaxhighlight>

=== Sonos2mqtt mit mehr Komfort ===
Im Wiki Artikel [[Sonos2mqtt]] geht es weiter.

== Owntracks GPS Tracking in FHEM über MQTT - Cloud ==
Das hier gezeiget Beispiel verwendet eine MQTT Instanz im Internet, die mit einem MQTT2_CLIENT angebunden wird. Da wenig Traffic benötigt wird, genügt z.B. eine kostenfreie Instanz z.B. bei myqtthub (Stand. Dezember 2020)

Alternativ kann man einen MQTT2_SERVER auch direkt verfügbar machen, wenn man sich sicher ist was man da tut! Siehe {{Link2Forum|Topic=99666|Message=1028576|LinkText=diesen Forenbeitrag}}. Das Bridge Device wird dabei genau so benötigt, nur der IODev ist dann der MQTT2_SERVER.

=== owntracks auf dem Smartphone konfigurieren ===
Menü / Einstellung / Verbindung

Dort sind insgesamt 4 Registerkarten mit Werten zu füllen (Beispiel):
* Modus -> MQTT
* Hostname ->
** Hostnamen: host.cloud.com
** Port: 8883
** ClientID: ID vom Provider
** WebSockets (nicht nutzen)
* Identifikation ->
** Benutzername: user-name
** Passwort: user-password
** GeräteID: mi6 (erscheint in FHEM im Device Namen verwendet)
** TrackerID: hk (nur zweistellig, erscheint als ID in der owntracks Karte)
* Sicherheit ->
** TLS aktivieren
=== Definition in FHEM ===
Der MQTT2_CLIENT wird so eingerichtet, man braucht eine andere ClientID als auf dem Smartphone! Stimmt alles sollte das Gerät sofort open anzeigen.<syntaxhighlight lang="perl">
MQTT2_CLIENT einrichten, autocreate simpel
define mqtt2Cloud MQTT2_CLIENT host.cloud.com:8883
attr mqtt2Cloud SSL 1
attr mqtt2Cloud autocreate simple
attr mqtt2Cloud clientId fhem1
attr mqtt2Cloud room MQTT2_IO
attr mqtt2Cloud username user-name
set mqtt2Cloud password user-password
</syntaxhighlight>Für die automatische Erzeugung der Trackergeräte in FHEM richtig man zuerst ein Bridge Device ein:<syntaxhighlight lang="perl">
define MQTT2_Cloud_bridge MQTT2_DEVICE
attr MQTT2_Cloud_bridge IODev mqtt2Cloud
attr MQTT2_Cloud_bridge autocreate 1
attr MQTT2_Cloud_bridge room MQTT2_DEVICE
</syntaxhighlight>Dies wird entweder mit dem Template allgemein konfiguriert<syntaxhighlight lang="perl">
set MQTT2_Cloud_bridge attrTemplate MQTT2_CLIENT_general_bridge
</syntaxhighlight>oder manuell nur für owntracks eingerichtet<syntaxhighlight lang="perl">
attr MQTT2_Cloud_bridge bridgeRegexp owntracks/[^/]+/([^/:]+).* "owntracks_$1"
</syntaxhighlight>MQTT2 Geräte für owntracks werden jetzt automatisch mit dem Namen MQTT2_owntracks_<GeräteID> erzeugt. Diese werden einfach mit dem Template owntracks_device fertig konfiguriert. Bei einem IOS Gerät kann man danach noch das Template owntracks_device_IOS als Erweiterung anwenden.

==== Anwesenheitserkennung ====
Die Anwesenheit kann im owntracks Device direkt für die selbst definierten Plätze abgelesen werden: entweder steht im reading place der jeweilige Ort oder away. Um hier noch eine gewisse Einheitlichkeit in der Verwendung zu bekommen kann man ein PRESENCE Device verwenden: <syntaxhighlight lang="perl">
define OT_Mi6 PRESENCE event MQTT2_owntracks_mi6:place:.away MQTT2_owntracks_mi6:place:.<Home>
</syntaxhighlight>Im Move Modus erfolgt die Erkennung sehr schnell und damit einige Sekunden eher als eine BT Erkennung im Haus - der Akkuverbrauch steigt enorm. Im Significant Modus kann es schon mal ein paar Minuten dauern - ein relevanter Akku Verbrauch ist nicht erkennbar.

== Owntracks GPS Tracking in FHEM direkt an den eigenen Fhem-Server ==
Dieses Beispiel beschreibt den direkten MQTT2 Zugang wobei das IODev dann der MQTT2_SERVER ist. Hierzu bitte {{Link2Forum|Topic=99666|Message=1028576|LinkText=diesen Forenbeitrag}} lesen.

=== SSL - Zertifikate fuer fhem erstellen. ===
Zunächst erstellen wir fuer den MQTT - Server CA zertifizierte SSL Zertifikate. Diese sind identisch mit den SSL - Zertifikaten, welche man evtl. schon fuer den SSL - Zugang seines FHEMWEB - Device erstellt hat.

Hat man den FHEMWEB schon mit eiem SSL Zertifikat (http'''<u>s</u>'''://) abgesichert, muss man daraus nur noch den .p12 - Container erstellen.

Hat man den FHEMWEB noch nicht abgesichert (http://), dann wir es höchste Zeit!

Für die Erstellung dieser SSL Zertifikate folgt dem Wiki-Beitrag [[FHEM mit HTTPS SSL-Zertifikat und eine eigene Zertifizierungsstelle]].

Die darin beschriebenen Dateien, das cacert.pem sowie den server.p12 - Container müsst ihr nun an euer Mobiltelefon senden.

=== Definition in FHEM ===
Der MQTT2_Server wird wie folgt eingerichtet.<syntaxhighlight lang="perl">
define myMQTT2Server_extern MQTT2_SERVER IPV6:1884 global
attr MQTTBroker_extern SSL 1
attr MQTTBroker_extern autocreate complex
attr MQTTBroker_extern event-on-change-reading .*
attr MQTTBroker_extern group MQTT2
attr MQTTBroker_extern icon mqtt_broker
attr MQTTBroker_extern room MQTT2
</syntaxhighlight>

Der MQTT2_Server wird zusätzlich über "allowed" abgesichert:<syntaxhighlight lang="perl">
define allowed_MQTT2Server_extern allowed
attr allowed_MQTT2Server_extern DbLogExclude .*
attr allowed_MQTT2Server_extern group MQTT2
attr allowed_MQTT2Server_extern room MQTT2
attr allowed_MQTT2Server_extern validFor myMQTT2Server_extern
</syntaxhighlight>Jetzt vergeben wir noch einen Usernamen und ein Passwort für dieses "allowed" - Device<syntaxhighlight lang="perl">
set allowed_MQTT2Server_extern basicAuth MyMQTT2Username MyMQTT2Password

</syntaxhighlight>Denkt bitte daran einen eigenen Usernamen und ein eigenes langes, kompliziertes Passwort zu verwenden. Vorsicht bei Sonderzeichen!

=== Port-Freigaben im Router ===
An dieser Stelle müssen wir den Port 1884 in den Internet - Freigaben eures Routers freigeben.

Bei der Fritz!Box wird dies beispielsweise unter Internet -> Freigaben -> Port-Freigaben gemacht. Die Details hierzu entnehmt bitte der Bedienungsanleitung eures Routers.

Wichtig ist dabei, das ihr das Protokol "TCP" verwendet und der Port 1884 extern nach Port 1884 intern an die IP - Adresse des jeweiligen fhem-Servers übermittelt wird.

=== owntracks auf dem Smartphone konfigurieren ===
Menü / Einstellung / Verbindung

Dort sind insgesamt 4 Registerkarten mit Werten zu füllen (Beispiel):
* Modus -> MQTT
* Hostname ->
** Hostnamen: subdomain.dyndns.com
** Port: 1884
** ClientID: Vorname_Nachname
** WebSockets (nicht nutzen)
* Identifikation ->
** Benutzername: MyMQTT2Username
** Passwort: MyMQTT2Password
** GeräteID: mi6 (erscheint in FHEM im Device Namen verwendet)
** TrackerID: hk (nur zweistellig, erscheint als ID in der owntracks Karte. Empfehlung: Die Initialien verwenden.)
* Sicherheit ->
** TLS aktivieren
** CA-Zertifikat: cacert.pem
** Client-Zertifikat: server.p12
** Passwort fuer Client-Zertifikat: Passwort für den server.p12 - Container

Wenn alles richtig gemacht wurde, dann erstellt das myMQTT2Server_extern - Device automatisch ein neues Device für jede owntracks-App, die sich an dem myMQTT2Server_extern - Device meldet.

Übrigens: Will man seine gesamte Familie ebenfalls über owntracks tracken, so muss man in den jeweiligen APPs nur die Werte für ClientID, GeräteID und TrackerID individuell gestalten.

An den fhem- Einstellungen müssen keine weiteren Änderungen vorgenommen werden.
== Allgemeine Hinweise ==
=== MQTT2_SERVER und MQTT2_CLIENT für Debugging nutzen ===
Nutzt man das rawEvents-Attribut am MQTT2-IO<ref>z.B. <code>attr MQTT2_FHEM_Server rawEvents .*</code>, der regex-Filter kann wie üblich angepasst werden</ref>, kann man den Datenverkehr des Servers am Event-Monitor mitschneiden. Dies ist insbesondere für unbekannte Geräte nützlich, deren Topic- und Payload-Struktur noch nicht bekannt ist.
Um den kompletten MQTT Datenaustausch mitzuschneiden, kann man mit <code>attr mqtt2_server verbose 5</code> auch alles ins FHEM-Log schreiben lassen.

=== autocreate funktioniert anscheinend nicht? ===
In der Regel wird bei neu eingehenden MQTT-Messages über ''autocreate'' ein neues Device erstellt, wenn Nachrichten von einem bisher unbekannten Gerät kommen. Geschieht dies nicht, sollten folgende Punkte geprüft werden:
# (nur bei MQTT2_SERVER:) Der Client muss eine ClientID angeben, diese darf nicht den defaults von ''mosquito_sub'' entsprechen.
# Ein allgemeines {{Link2CmdRef|Anker=autocreate|Lang=en|Label=autocreate}}-Device (''TYPE=autocreate'') muss vorhanden und aktiv sein.
# ''autocreate'' am IO muss eingeschaltet sein, was für MQTT2_SERVER bedeutet, dass es nicht auf "0" stehen darf (hier ist dann ''simple'' die aktive Voreinstellung), für MQTT2_CLIENT sollte ebenfalls ''simple'' verwendet werden; dies muss hier allerdings explizit gesetzt werden.

Wird dann immer noch kein Device erstellt, gibt es in aller Regel ein Device, das bereits einen entsprechenden Eintrag in der readingList enthält, oder es sind keine Nachrichten eingegangen. Überprüfen Sie daher dann ggf. die Einstellungen am Client-Gerät (z.B. im Web-Interface des Shelly oder Tasmota-geflashten ESP8266).

Das ''autocreate'' am Device schließlich bestimmt, ob die ''readingsList'' erweitert werden darf, wenn Informationen über bisher nicht über die readingList abgedeckte Topics empfangen werden und vom MQTT2-IO als zu diesem Device/ClientID gehörend identifiziert wurden.

=== attrTemplate ===
{{Randnotiz|RNTyp=Info|RNText=Die per attrTemplate jeweils erzeugten Konfigurationen sind Einrichtungsbeispiele, die v.a. eine in sich konsistenze Zusammenstellung der verschiedenen Attribute enthalten. Es steht jedem User frei, diese Ausgangsbasis dann nach seinem Belieben zu ändern. Spätere Änderungen des verwendeten attrTemplate wirken sich nicht automatisch auf die durch frühere Versionen oder den User nachkonfigurierte Geräte aus! Da es vorkommen kann, dass sich die per MQTT übermittelten Daten und Topics ändern, wenn z.B. eine firmware aktualisiert wurden, kann dies Anpassungen am jeweiligen Template erforderlich machen. Grundsätzlich sollen die per attrTemplate für MQTT2_DEVICE verfügbaren attrTemplate jeweils für die aktuellste verfügbare stabile firmware-Version passen.}}
Zur Konfiguration von MQTT2_DEVICE-Geräten kann die Funktion ''[[AttrTemplate|attrTemplate]]'' genutzt werden.
Die Anwendung für MQTT2_DEVICE ist [[MQTT2 DEVICE#attrTemplate|hier]] beschrieben.

{{Hinweis|In einigen Fällen kann es vorkommen, dass die template-Bezeichnung zwischenzeitlich geändert wurde. Seit 21.09.2019 erfolgt die Sortierung der auswählbaren templates nicht mehr nur nach den Namen, so dass die entsprechenden Namensbestandteile entfallen sind, die einer besseren Sortierung dienten.}}

=== attrTemplate: Es werden nicht alle templates angezeigt ===
Siehe Beitrag [[AttrTemplate#Warum finde ich das Template xyz nicht.3F|AttrTemplate: Warum finde ich das Template xyz nicht.]]

=== attrTemplate und Sprachsteuerung ===
Konfiguriert man MQTT2_DEVICE-Geräte mit attrTemplate, werden in der Regel auch direkt die für die Sprachsteuerung der Geräte erforderlichen Attribute mit gesetzt. Weiterführende Hinweise sind auch zu diesem Teilaspekt von ''[[AttrTemplate|attrTemplate]]'' dem betreffenden Hauptartikel zu entnehmen.

=== bridgeRegexp ===
[[Datei:Mqtt2 server.png|300px|thumb|left|Logische Verortung der bridgeRegexp-Angaben]]{{Randnotiz|RNTyp=y|RNText=Beachten Sie, dass aufgrund des geschilderten Prinzips eine Änderung einer bridgeRegexp bei einem Gerät auch dazu führt, dass alle Readings eines Geräts und alle readingList-Einträge gelöscht werden.}}Üblicherweise werden alle Informationen, die aus einer Quelle stammen auch '''''einem''''' ''MQTT2_DEVICE'' zugeordnet, wobei im Falle des dort nicht aktivierten autocreate-Attributs entsprechende readingList-Einträge erzeugt werden. In dem nebenstehenden Schaubild wären dies die Geräte ''A'' bis ''D''. Das '''Attribut''' ''bridgeRegexp'' kann dazu genutzt werden, um neue, bisher unbekannte Topic-Strukturen im Rahmen des autocreate-Vorgangs anders zu strukturieren. Diese werden dabei im Ergebnis einem '''anderen Device''' (das ggf. erst erstellt wird) zugeschlagen, sollte eine zu der topic-Struktur passende regex in diesem Attribut gesetzt sein. Für dessen CID und die Bildung des Names wird die im 2. Teil jedes Eintrags als ''newClientId'' hinterlegte Angabe verwendet. In nebenstehendem Schaubild ist dies exemplarisch für die Gerätegruppe ''D'' mit dem ''bridge''-Device ''D'' und dessen ''Satelliten'' ''D1'' bis ''D4'' dargestellt.
Dementsprechend sind in den hier aufgeführten Beispielen ''bridgeRegexp''-Attribute immer dort zu finden, wo ein Gerät oder Dienst dazu dient, mit weiteren, ggf. auf andere Weise kommunizierende Geräte oder Baugruppen zu kommunizieren, wie z.B. für über hier dargestellten ''zigbee2mqtt'' oder ''zigbee2tasmota''. Ein Sonderfall hierbei ist das template ''MQTT2_CLIENT_general_bridge'' zur Verwendung mit dem [[MQTT2_CLIENT#Anwendung|MQTT2_CLIENT]], denn aus dessen Sicht stammen alle Informationen aus derselben Quelle, nämlich z.B. dem ''mosquitto''-Server und würden sonst alle ein und demselben MQTT2_DEVICE zugewiesen.

=== Ständig neue Devices? ===
MQTT2_SERVER kann zwischen verschiedenen Geräten auch anhand der ClientID unterscheiden. Für jedes neu erkannte Gerät wird auch ein eigenes MQTT2_DEVICE angelegt. Abhilfemaßnahmen:
==== Vergabe einer ClientID ====
Die meisten MQTT-fähigen Geräte enthalten Optionen zur Vergabe einer eindeutigen ClientID (siehe das Beispiel des zigbee2mqtt-Dienstes oben).
Wird keine ClientID vergeben, verwenden manche Clients für jede Verbindung wieder neue ID's. Es wird empfohlen, möglichst von diesen Einstelloptionen Gebrauch zu machen.

==== Löschen der ClientID aus der readingList usw. ====
Ist dies nicht möglich oder erwünscht, kann man auch die ClientID aus den readingList-, setList- und getList-Attributen entfernen. Dies ist jedenfalls solange unschädlich als nicht mehrere Geräte identische Topic-Pfade verwenden (daher die Empfehlung, insbesondere bei Tasmota-Geräten den ''default'' "sonoff" zu ändern).
Beispielsweise wäre <code>attr Milight_Bridge readingList milight_hub_1370325:milight/LWT:.* {json2nameValue($EVENT) }</code> zu ändern in <code>attr Milight_Bridge readingList milight/LWT:.* {json2nameValue($EVENT) }</code>
Die über ''attrTemplate'' verfügbaren Konfigurationen verwenden in der Regel keine ClientID's bzw. entfernen diese.

=== Wildcards in readingList und setList ===
Auch in readingList und in setList sollten sich sog. wildcards verwenden lassen. Die Vorgehensweise ist jedoch unterschiedlich:

In ''readingList'' werden normale regex-Ausdrücke verwendet. Ein Punkt steht daher z.B. für ein beliebiges Zeichen, alles zwischen zwei Topic-Tree-Elementen (getrennt typischerweise durch einen "/") kann man so schreiben: "[^/]+" (entspricht: "Mindestens ein Zeichen, das kein Schrägstrich ist"). Ergänzender Hinweis: Will man z.B. Informationen aus einem beliebigen Teil des Topic-trees extrahieren und als Reading-Namen verwenden, kann dies im Rahmen eines Perl-Aufrufs geschehen. Beispiele aus der mqtt2.template-file: OpenMQTTGateway_BT_scanner und OpenMQTTGateway_BT_gtag (letzteres überführt die Information, über welches Gateway bestimmte Informationen eingegangen ist jeweils in eigene Readings pro Gateway).

In ''setList'' gelten dagegen die wildcard-Konventionen aus der MQTT-Welt. Dort steht "+" für einen austauschbaren Teil des Topic-Trees (zwischen zwei Schrägstrichen). Anmerkung: Bitte vorher prüfen, ob es wirklich sinnvoll ist, derart unspezifische Publishes vorzunehmen. Meist gibt es "Gruppen-Topics", auf die mehrere Geräte eines bestimmten Typs hören bzw. man kann dies dort (in der firmware bzw. auf den Konfigurationsseiten der Geräte) einstellen.

=== Die JSON-Daten sollen ausnahmsweise nicht ausgepackt werden ===
In manchen Fällen ist das automatische Auspacken der JSON-Payload nicht erwünscht. In diesen Fällen kann man einfach den gewünschten Reading-Namen in die readingList eintragen, statt der Anweisung, den JSON an json2NameValue() zu übergeben. Aus
<pre>
attr MQTT_OwnTracks readingList owntracks/clouduser/mi6:.* { json2nameValue($EVENT) }\
owntracks/clouduser/mi6/waypoints:.* { json2nameValue($EVENT) }\
owntracks/clouduser/mi6/event:.* { json2nameValue($EVENT) }
</pre>
wird dann:
<pre>
attr MQTT_OwnTracks readingList owntracks/clouduser/mi6:.* json_mi6\
owntracks/clouduser/mi6/waypoints:.* json_waypoints\
owntracks/clouduser/mi6/event:.* json_event
</pre>
Erforderlichenfalls kann man die Einträge auch doppelt erstellen, um sowohl den JSON wie auch die ausgepackten Readings zu erhalten.

=== Die JSON-Daten vor dem auspacken manipulieren ===
Aus diversen Gründen kann es zweckmäßig sein, einen bestimmten Wert der JSON-Payload zu ignorieren.
Z.B. sendet ein Client statt eines Messwertes die Info "bad". Dieser Fehlerwert soll aus der JSON-Payload "ausgefiltert" werden:
<pre>
attr DEVICE readingList <your topic>:.* { my $rets = json2nameValue($EVENT,'',$JSONMAP);; my %cleaned = map { $_,$rets->{$_} } grep { 'bad' ne $rets->{$_} } keys %{$rets};; return \%cleaned }
</pre>
Numerische Werte zuvor runden :
<pre>
attr DEVICE readingList <your topic>:.* { my $h=json2nameValue($EVENT,'XXX');; map { $h->{$_}=round($h->{$_}) if(looks_like_number($h->{$_})) } keys %{$h};; $h }
</pre>

==== Einfache Payload ====
Einen Wert mappen:
<pre>
attr DEVICE readingList <your topic>:.* {my %h=(0=>'SofortLaden',1=>'MinPV',2=>'NurPV',3=>'Stop',4=>'Standby');; return {ChargeMode=>$h{$EVENT}}}
</pre>

=== Unnötige Konfigurationsinformationen verwerfen ===
Siehe Einleitung und den [[MQTT2_CLIENT#ignoreRegexp|ignoreRegexp-Abschnitt zu MQTT2_CLIENT]].

=== Weiterführende Themen ===
==== Verbinden mehrerer FHEM-Instanzen über MQTT ====
Wie im Hauptartikel zu [[MQTT#Kommunikation zu sonstigen FHEM-Geräten über MQTT|MQTT]] erläutert, gibt es mehrere Varianten, wie man mit Hilfe von FHEM aus Events an beliebigen Geräten MQTT-Messages erzeugen kann. So kann man z.B. Messdaten eines Systems über ein ''notify'' iVm. einer einfachen ''publish''-Anweisung an ein zweites FHEM schicken, das diese Daten dann z.B. mit Hilfe der MQTT2-Module auswerten kann.
Damit dabei Nachrichten unterschiedlicher Quellen auch als getrennte Readings bzw. ggf. auch gesonderten MQTT2_DEVICE-Instanzen zugeordnet werden, sollte man entsprechende Topic-Strukturen wählen, die dann auch mit Hilfe einer geeigneten ''bridgeRegexp'' automatisiert ausgewertet werden kann, siehe z.B. dieser {{Link2Forum|Topic=107145|LinkText=Forumsthread}}:
attr MQTT2_myMqttServer bridgeRegexp \
SmartHome/MqttGenericBridge2/([A-Za-z0-9]*)/.*:.* "mgb2_$1"
Dabei werden die betreffenden Informationen der entfernten FHEM-Instanz alle nach dem Schema ''SmartHome/MqttGenericBridge2/<Device-Name>/<Reading-Name>'' versendet.

==== Umstellung von MQTT_DEVICE (und Derivaten wie XiaomiMQTTDevice) zu MQTT2_DEVICE ====
Wer beabsichtigt, von der Implementierung MQTT+MQTT_DEVICE zu MQTT2-IO und MQTT2_DEVICE zu wechseln, sollte einige Punkte beachten. Viele diesbezügliche Fragen sind vor allem in {{Link2Forum|Topic=103762|LinkText=diesem Foren-Thread}}

näher erläutert.

== Links ==
* {{Link2Forum|Topic=91394|LinkText=Thread, aus dem diese Anleitung ursprünglich entstanden ist}}
* {{Link2Forum|Topic=91807|LinkText=Thread zum Tasmota-Device}}
* {{Link2Forum|Topic=97989|LinkText=Thread, aus dem diese Anleitung für den eBus ursprünglich entstanden ist}}
* {{Link2Forum|Topic=94495|LinkText=Neue templates einreichen}}
* {{Link2Forum|Topic=94494|LinkText=Fragen, Wünsche und Kritik zu mqtt2.template}}
* {{Link2Forum|Topic=116162|LinkText=Der MQTT-Workshop für MQTT2-Module}}

== Hinweise ==
<references />
[[Kategorie:HOWTOS]]
[[Kategorie:MQTT]]
[[Kategorie:IP Components|IP Komponenten]]
[[Kategorie:Other Components]]
[[Kategorie:Interfaces]]

Notify

2023-04-29T15:04:49Z

TomLee: /* Syntax */

{{SEITENTITEL:notify}}
{{Infobox Modul
|ModPurpose=Ausführung von Anweisung(en) als Reaktion auf Ereignisse
|ModType=h
|ModCmdRef=notify
|ModForumArea=Automatisierung
|ModTechName=91_notify.pm
|ModOwner=rudolfkoenig ({{Link2FU|8|Forum}} / [[Benutzer Diskussion:Rudolfkoenig|Wiki]])
}}

== Einführung ==
{{Hinweis|Weitere grundlegende Informationen/Beispiele zu notify enthält [http://fhem.de/Heimautomatisierung-mit-fhem.pdf Heimautomatisierung mit FHEM]}}
Das Hilfsmodul notify dient dazu [[Ereignis|Ereignisse]] über ein Suchmuster zu erkennen und bei einem Treffer eine Aktion auszulösen. Mit ''notify'' und anderen [[Eventhandler|Eventhandlern]] <ref>hierzu gehören u.a. auch [[DOIF]], [[THRESHOLD]] und [[watchdog]]</ref> ist es möglich, Logikfunktionen im FHEM abzubilden.

'''Beispiele:'''
* Wird das Licht in der Küche eingeschaltet, soll FHEM dort auch das Radio einschalten.
* Bei Druck auf einen Taster soll die Umwälzpumpe für das Warmwasser eingeschaltet werden.
* Erweiterte Möglichkeiten: Aber nur, wenn das Radio aus ist bzw. die Temperatur im Rücklauf des Warmwassers unterhalb einer bestimmten Schwelle liegt<ref>vgl. hierzu z.B. {{Link2CmdRef|Anker=devspec|Label=FILTER}} und [[if-condition]]</ref>.

== Syntax ==

define <name> notify <Suchmuster> <command>

Das ''[[Regulärer Ausdruck|Suchmuster]]'' (häufig als Regexp = regular expression = regulärer Ausdruck bezeichnet) ist sehr wichtig: Es ist entweder der Name des auslösenden ("triggernden") Gerätes oder die Kombination aus Gerät und auslösendem Ereignis (Event) <code>Gerätename:Event</code>. Die Events kann man dem [[Event_monitor|Event-Monitor]] entnehmen. Wenn dort z.B. <code>Rollo1</code> steht, dann reagiert ''notify'' auf <code>Rollo1 on</code> und <code>Rollo1 off</code> usw.

Wenn man mehrere Suchmuster kombinieren möchte, kann man diese in Klammer schreiben, als Trenner wird dann Pipe (|) genutzt: <code>(Rollo1|Rollo2|Steckdose5)</code>.

'''Auch die Verwendung von Platzhaltern ist möglich''':
* <code>Rollo.</code> → das notify reagiert auf alles was mit Rollo und '''einem''' weiteren beliebigen Zeichen anfängt. Also auf Rollo1 wie auch auf RolloG, aber nicht auf Rollo_wischundweg
* <code>Rollo.*</code> → notify reagiert auf alles das mit Rollo beginnt
* <code>.*isch</code> → auf alles das mit isch aufhört (Tisch, Fisch)
* <code>Schalter(1|2|3)</code> → hört auf Schalter1, Schalter2 und Schalter3
* <code>dimmer:pct:.(100|7[6-9]|[89][0-9])</code> → reagiert, wenn pct einen Wert über 75 annimmt.

Suchmuster/Regex kann man im Internet beispielsweise auf [http://regexpal.com/| http://regexpal.com/] testen.

Es gibt seit Juli 2020 eine Perlfunktion notifyRegexpCheck zum Testen, wie FHEM über das Suchmuster "denkt" - siehe {{Link2Forum|Topic=111938|Message=1074202|LinkText=diesen Beitrag}} im Forum.

{{Hinweis|Das '''Suchmuster''' wird notify-intern um das Zeichen ^ (beginnt mit) und das Zeichen $ (endet mit) ergänzt<ref>Der Eventhandler [[DOIF]] verwendet die in Perl übliche Syntax für reguläre Ausdrücke als DOIF-Suchmuster.</ref>.

Deshalb darf das Suchmuster nicht mit einem üblichen [[Regulärer Ausdruck|'''Regulären Ausdruck''']], wie er in Perl<ref>https://perldoc.perl.org/perlre.html</ref> verwendet wird, gleichgesetzt werden, da die Ergänzung zu einem grundsätzlich unterschiedlichen Verhalten führt, siehe nachstehendes Beispiel.}}

'''Beispiel für das unterschiedliche Verhalten von ''Suchmuster'' und ''regulären Ausdruck'''''

Für einen '''regulären Audruck''' gilt: Wenn der reguläre Ausdruck ''lampe'' ist und das [[Ereignis]] ''tischlampe'' dann passen ''tischlampe'' und ''lampe'' zueinander.

Für das '''Suchmuster''' gilt: Wenn das Suchmuster ''lampe'' ist und das [[Ereignis]] ''tischlampe'' dann passen ''tischlampe'' und ''lampe'' '''nicht''' zueinander, weil das Suchmuster zu ^lampe$ ergänzt wird und damit exakt nur auf ''lampe'' matcht (passt).

'''Variablen Zuordnung zum Event'''

'''Beispiel 1'''

2020-01-21 22:40:39 HUEDevice VibrationTest1 battery: 88
{| class="wikitable"
|-
! !!$NAME !! colspan="2" |$EVENT
|-
| ||||$EVTPART0 ||$EVTPART1
|-
|2020-01-21 22:40:39 HUEDevice|| VibrationTest1|| battery:|| 88
|}

'''Beispiel 2'''
2021-05-09 19:11:43 FB_CALLMONITOR cm_example external_name: Graf Herzog von und zu ...
{| class="wikitable"
|-
! !!$NAME !! colspan="7" |$EVENT
|-
| ||||$EVTPART0 ||$EVTPART1 || $EVTPART2|| $EVTPART3 || $EVTPART4|| $EVTPART5|| ...
|-
|2021-05-09 19:11:43 FB_CALLMONITOR|| cm_example|| external_name:|| Graf|| Herzog|| von|| und|| zu|| ...
|}

'''Beispiel 3'''

2023-04-29 16:53:04 dummy Demo closed
{| class="wikitable"
|-
! !!$NAME !! colspan="1" |$EVENT
|-
| ||||$EVTPART0
|-
|2023-04-29 16:53:04 dummy|| Demo|| closed
|}

== FHEMWEB-unterstütztes Anlegen eines notify ==
{{Hinweis|Die Erstellung eines notify und insbesondere die korrekte Angabe des Suchmusters (Regex) führt gerade bei Einsteigern immer wieder zu Schwierigkeiten. Zur Fehlerminimierung empfiehlt es sich zum einen, die [[Konfiguration]] nicht direkt zu bearbeiten, sondern die "Befehl-Eingabezeile", die "Objektdetails" oder den [[Import von Code Snippets|Import von RAW-Definitionen]] zur Bearbeitung zu nutzen.}}

=== Event Monitor ===
Die komfortabelste Möglichkeit, die häufigsten Event-Handler zu erstellen, bietet der [[Event monitor|Event-Monitor]]. Die Vorgehensweis ist in dem zugehörigen Artikel dargestellt.

=== Regexp wizard ===
Zudem enthält FHEM einen Regexp wizard mit dem Regex anhand der in FHEM vorhandenen Devices und deren Events aus einer Auswahlbox selektiert werden können. Voraussetzungen sind:
* Aktivierung des Hilfsmoduls [[eventTypes]] (bei allen Neuinstallationen Standard)
* das gesuchte Ereignis (Event) ist nach Aktivierung des Hilfsmoduls bereits mindestens einmal eingetreten

Schrittweise Darstellung der Nutzung des Regexp wizard zur Anlage eines "notify":

In das [[Konfiguration#Befehl-Eingabefeld|Befehls-Eingabefeld]] eingeben und mit {{Taste|Enter}} bestätigen:
define ntest notify a b
Als Beispiel wird ein notify mit <name> "ntest" angelegt. "a" und "b" sind beliebige Platzhalter für <Suchmuster> und <Command>, die bei der weiteren Bearbeitung mit dem endgültigen Werten ersetzt werden.
Der Regexp wizard öffnet sich:
[[Datei:Regexp wizard1.JPG|400px|thumb|center]]
Nun in der Auswahlbox das auslösende Event (Ereignis) auswählen; zunächst das Device und dann das gewünschte Regex. Hier soll das notify bei jeder Veränderung der Temperatur (temperature.*) des Device BTHR918N reagieren. Abschließend mit einem Mausklick auf {{Taste|set}} bestätigen. Wählt man mehrere Regex in dieser Weise aus, so wird das "notify" bei Eintritt jedes dieser Events ausgeführt:
[[Datei:Regexp wizard2.JPG|400px|thumb|center]]
Anschließend den Platzhalter "a" mit Klick auf den Link "removeRegexpPart" löschen:
[[Datei:Regexp wizard3.JPG|400px|thumb|center]]
Den Link "DEF" anklicken, damit sich der DEF-Editor öffnet:
[[Datei:Regexp wizard4.JPG|400px|thumb|center]]
Jetzt den auszuführenden Befehl im "DEF"-Bereich durch Überschreiben des Platzhalters "b" eintragen und mit Klick auf {{Taste|modify ntest}} abschließen:
[[Datei:Regexp wizard5.JPG|400px|thumb|center]]
Das fertige und sofort aktive "notify" sieht abschließend folgendermaßen aus:
[[Datei:Regexp wizard6.JPG|400px|thumb|center]]
Am Schluss das Speichern über {{Taste|Save config}} nicht vergessen.

== Mein notify geht nicht - wie kann ich mir selbst helfen: Debugging ==
Funktioniert ein notify nicht wie gewünscht, kann es nur zwei Hauptursachen haben:
* Entweder das Suchmuster paßt nicht zum gewünschten Auslöser (FHEM Device), und/oder
* die Anweisung enthält einen Fehler.
Sollte kein Fehler im Logfile auftauchen aber das notify ausgelöst werden, stimmt meist der Übertragungsweg zum Zieldevice nicht.
Der STATE des notify zeigt normalerweise mit Datum/Uhrzeit die letzte Auslösung an.

Beim Debuggen sollte man daher beide Elemente getrennt untersuchen. Hier ein Beispiel welches nicht wie gewünscht funktioniert:
<syntaxhighlight lang="perl"> define n_test notify n_test:muster Ausführungsteil</syntaxhighlight>
Zum debuggen benötigen wir
* den [[Event monitor]]
* das [https://fhem.de/commandref.html#trigger trigger-Kommando] - kann man jederzeit verwenden um das Suchmuster als Event unabhängig vom Auslöser zu erzeugen.
* die FHEM Kommandozeile
* den [[DEF-Editor]]
* eventuell einen Texteditor um Codeblöcke zwischen zu lagern und Notizen zu machen.

Das Suchmuster im Beispiel notify triggert auf sich selbst, es soll auf jeden Event mit dem Inhalt '''muster''' ausgelöst werden, Beispiel:
2018-07-14 14:31:03 notify n_test muster bild

=== Suchmuster ===
Sollte das notify nicht funktionieren:
* keine Reaktion wie gewünscht
* keine Fehlermeldung in der Weboberfläche beim Anlegen, keine Fehlermeldung im Logfile
* STATE ist unverändert auf active oder einem altem Datum/Uhrzeit
liegt der Fehler mit Sicherheit im Suchmuster. Man hat die Chance das Suchmuster mit dem trigger Befehl zu erzeugen und zu schauen ob die Anweisung ausgeführt wird. Dabei ist zu beachten: Der erste ":" im Suchmuster ist zusätzlich zwischen Gerät und Event als Trennung. Jeder weiter : ist, wenn vorhanden, Bestandteil des Events! Siehe dazu den Abschnitt [https://fhem.de/commandref_DE.html#notify Hinweise in der commandref]
*Im Beispiel: Event: n_test muster -> Suchmuster n_test:muster
Um aus dem [[Event]] ein passendes Suchmuster zu erzeugen kann der [[Event monitor|Event-Monitor]] direkt verwendet werden. Man kann ein neues notify erzeugen oder ein Bestehendes modifizieren lassen.

Unser Regex im Beispiel ist zu spezifisch, es triggert nur exakt auf '''muster'''. Dieser Trigger erzeugt den folgenden Eintrag im Eventmonitor, entspricht exakt dem Suchmuster und löst das notify aus:
trigger n_test muster
2018-07-13 11:52:08 notify n_test muster
Das Suchmuster für unsere Anforderung muss in <code>n_test:muster.*</code> geändert werden, damit jeder Event der mit muster beginnt das notify auslöst.
Der . im Regex steht für jedes beliebige Zeichen und der * für eine beliebige Anzahl des Zeichens davor: also beliebig viele beliebige Zeichen nach muster.

Das Suchmuster wird häufig in ein komplizierteres Regex umgewandelt um im notify mehrere Aktionen zu starten. Das eigene Regex kann z.B. mit http://regexpal.com/ oder https://regex101.com/ getestet werden.

Funktioniert der Auslöser, das notify tut aber noch nicht was es soll, müssen wir die Anweisung untersuchen. In unserem korrigierten Beispiel
<syntaxhighlight lang="perl"> defmod n_test notify n_test:muster.* Ausführungsteil</syntaxhighlight>
folgt beim Kommando <code>trigger n_test muster bild</code> ein Eintrag im Log:
2018.07.13 11:47:57 3: n_test return value: Unknown command Ausführungsteil, try help.
Das notify wurde zwar getriggert aber die Anweisung war nicht ausführbar.

Ein richtiges Suchmuster und eine fehlerhafte Anweisung wird also normalerweise einen Fehlereintrag im Logfile erzeugen!

=== Spezialfall: notify löst zwar aus - aber zu oft ===
In dem Fall ist das Suchmuster (regExp) zu unscharf oder das triggernde Gerät löst das Event zu oft aus. Das regExp sollte so genau wie möglich konstruiert werden, device:.* ist eine einfache aber oft keine gute Wahl!

Im Device, welches den Event auslöst, kann mit den Attributen event-on-.* die Häufigkeit gesteuert werden. Insbesondere ist hier das regExp .* eine Art Standardwahl um aufeinanderfolgende gleichartige Events zu verhindern.
:<code>attr device event-on-change-reading .*</code>
'''Achtung''': durch falsche Angaben kann man Events ganz leicht völlig verhindern!

Siehe auch [[event-on-change-reading]]

=== Anweisung ===
Wird das notify getriggert oder will man ganz schnell mal ein notify testen, kann man die Anweisung durch folgenden Code ersetzen, man öffnet also einfach nur die DEF, kopiert den ursprünglichen Inhalt an einen sicheren Ort und ersetzt die Anweisung durch eine der beiden Zeilen. Die erste Zeile kann man auch einfach mal in der Kommandozeile testen:
<syntaxhighlight lang="perl">{Log 1, "Das Notify n_test hat ausgeloest."}
{Log 1, "Das Device $NAME hat ausgeloest, der Event sah so aus: $EVENT"}</syntaxhighlight>
Wird das notify ausgelöst, muss anschließend im Logfile ein Eintrag zu finden sein:
2018.07.13 10:28:57 1: Das Notify n_test hat ausgeloest, der Event sah so aus: muster
Unsere Anweisung <code>Ausführungsteil</code> liefert in der Kommandozeile selbst einen Fehler:
<code>Unknown command Ausführungsteil, try help.</code>
Ein Versuch mit geschweiften Klammern <code>{Ausführungsteil}</code> liefert wieder einen Fehler:
<code>Unrecognized character \xC3; marked by <-- HERE after {Ausf<-- HERE near column 6 at (eval 5977) line 1.</code>
Diese Variante <code>{"Ausführungsteil"}</code> liefert den String Ausführungsteil ohne Fehler: Das notify arbeitet fehler- aber sinnfrei.
Der fertige Code:
defmod n_test notify n_test:muster.* {"Ausführungsteil"}

Man kann die Anweisung, normalerweise so wie sie ist, in der FHEM Kommandozeile testen. Sind im Perl Code (in geschweiften Klammern) im DEF Editor Semikolon enthalten muss man diese für den Test in der Kommandozeile (oder Raw Def) verdoppeln.
Laufzeitabhängige Variablen sind in der Kommandozeile meist nicht verfügbar, diese sollte man für den Test einfach durch passende Inhalte austauschen. So kann man die komfortable Variante (loggt den Namen und das komplette Event) nicht in der Kommandozeile ausführen.

Funktioniert ein FHEM Befehl in der Kommandozeile nicht (z.B. Lampe geht nicht an) kann es im notify auch nicht funktionieren, dann muss die Fehlersuche an anderer Stelle fortgeführt werden.

Komplexeren Code im Ausführungsteil sollte man beim Testen in Teilabschnitte aufteilen, von der Laufzeit abhängige Variable ($NAME, $EVENT, $EVTPART) durch Strings ("TestWort") ersetzen, die Teilabschnitte separat testen und anschließend schrittweise wieder komplettieren.

== Beispiele ==
{{Hinweis|Für die nachfolgenden Beispiele wurden einige unterschiedliche Technologien verwendet. Sie können aber recht einfach auf alle anderen Systeme übertragen werden, dabei sollte ggf. darauf geachtet werden, dass sich Schaltbefehle und Events teilweise je nach konkret eingesetzter Technologie unterscheiden können. Dann ist ggf. eine Erweiterung, z.B. durch eine [[if-condition|if-Abfrage]] erforderlich.}}

=== Schalter entprellen ===
Will man ein notify innerhalb eines bestimmten Zeitraumes nur einmal auslösen lassen, auch wenn er in diesem Zeitraum mehrfach getriggered werden sollte, so bietet sich das Attribut disabledAfterTrigger an,
attr <notify_device> disabledAfterTrigger <Anzahl Sekunden>
In dem Zeitraum wird dann nur einmal (beim ersten Mal) der Befehl ausgelöst, auch wenn mehrfach getriggered wurde. Der Zeitraum kann Bruchteile von Sekunden umfassen.

=== Etwas schalten, wenn ein anderes Gerät geschaltet wird ===

==== Vorbedingungen ====
Dieses Beispiel verwendet eine einfache InterTechno-kompatible Funksteckdose für das Radio und einen HM-Aktor für das Licht:

define RadioKueche IT 000000FFFF 0F F0
define LichtKueche CUL_HM 3A37D6
Beachte: beide kennen als Event bzw. Schaltbefehle ''on'' und ''off''.

==== notify Befehl ====
define LichtamRadioan notify LichtKueche set RadioKueche $EVENT
oder alternativ:
define LichtamRadioan notify LichtKueche { fhem "set RadioKueche $EVENT" }

==== Erklärung ====
* Der Name des ''notify'' "LichtamRadioan" kann frei gewählt werden, er dient nur dazu, das notify in FHEM eindeutig zu identifizieren.
* "$EVENT" ist ein Platzhalter für den Zustand vom Pattern. $EVENT enthält ein "off" wenn das LichtKueche aus- und ein "on" wenn das Licht eingeschaltet wird.
* "{ <perlcode> }" alles was zwischen {} steht ist Perl code. Perl kennt das Schlüsselwort fhem. Das Schlüsselwort FHEM dient dazu, FHEM Befehle auszuführen. Es wird also der FHEM Befehl "set RadioKueche on/off" ausgeführt. on oder off ist abhängig vom Pattern. Der eigentliche FHEM Befehl muss in " " stehen.
* Wann ist ein Wechsel auf die Perl-Ebene erforderlich?
** einfache FHEM-Befehle sollten in der Regel direkt verwendet werden, dies ist ressourcenschonender.
** Immer dann, wenn dies nicht möglich ist, weil z.B. komplexerer Code ausgeführt werden soll, (blockierende) Prozesse ausgelagert werden sollten oder Systembefehle ausgeführt werden, ist es günstiger, auf die Perl-Ebene zu wechseln <ref>In diesem {{Link2Forum|Topic=88398|Message=808685|LinkText=Forenbeitrag}} wird z.B. erläutert, wie man nichtblockierend externe Scripte aufrufen kann, die dann ihre Ergebnisse wieder an FHEM übergeben.</ref>.

=== Einschalten von mehreren Geräten/Lampen, wenn das Licht eingeschaltet wird ===
Dieses Beispiel verwendet einen HM-Aktor für das Licht sowie zwei Milight-Birnen, die einzeln geschaltet werden sollen<ref>Dies ist ausdrücklich keine Empfehlung für diese Technologie und der Module</ref> in den Stehlampen:

==== Vorbedingungen ====
FHEM:
define LichtWZ CUL_HM 3A37D8
define Stehlampe1 MilightDevice RGBW Milight_Wohnzimmer 5
define Stehlampe2 MilightDevice RGBW Milight_Wohnzimmer 6

==== notify Befehl ====
define SteckdoseWZein notify LichtWZ set Stehlampe1,Stehlampe2 $EVENT
oder ''in Perl''
define SteckdoseWZein notify LichtWZ { fhem "set Stehlampe1 $EVENT;;set Stehlampe2 $EVENT " }
==== Erklärung ====
Wenn das LichtWZ eingeschaltet wird, dann werden auch die Stehlampen (1 und 2) eingeschaltet.

=== Einfache ODER Funktion ===
Eine einfache ODER Funktion kann sehr einfach realisiert werden

==== Vorbereitung ====
KNX:
* 3x GAs der abzufragende Werte (0/0/40 0/0/41 0/0/42)

FHEM:
define Licht1 CUL_HM 3A37D8
define Licht2 CUL_HM 1B7EC3
define Stehlampe MilightDevice RGBW Milight_Wohnzimmer 7

==== notify Befehl ====
define SteckdoseWZein notify (Licht1|Licht2) set Stehlampe $EVENT
oder
define SteckdoseWZein notify (Licht.) set Stehlampe $EVENT

==== Erklärung ====
Die Werte in der Klammer (wichtig ist das »|«) sind die Rückgabewerte. Alternativ kann in diesem Beispiel auch »Licht.« (zu beachten ist der Punkt) geschrieben werden. Der Punkt ist ein Platzhalter für (genau) ein beliebiges Zeichen.

Danach folgt der set Befehl.
Wenn also das Licht1 oder Licht2 den Wert "on" hat, dann hat auch die Steckdose den Wert "on"

Alternative: [[structure]]

=== Einfache UND Funktion ===
Ob man dieses Konstrukt noch als einfach bezeichnen kann, wage ich mal zu bezweifeln. In FHEM fehlen Loggingfunktionen, die man alle selber mit Perl Code erstellen kann (Danke an MAZ).
Dadurch ist FHEM zwar mächtig, wird aber für viele sehr kompliziert.

In diesem Beispiel soll - wenn drei Rollos geschlossen sind - am Taster eine LED eingeschaltet werden.

==== Vorbereitung ====
KNX:
* 3x GDs für die Rückgabewert Rollo geschlossen == 1 (0/0/50 0/0/51 0/0/52)
* GD LED am Lichtschalter (0/0/106)

FHEM:
define R1ZU KNX 0/0/50:dpt1.009
attr R1ZU dummy 1
define R2ZU KNX 0/0/51:dpt1.009
attr R2ZU dummy 1
define R3ZU KNX 0/0/52:dpt1.009
attr R3ZU dummy 1
define LEDalleRolloZu KNX 0/0/106:dpt1
Durch das Attribut dummy werden keine Schaltfunktion angeboten. Es kann nur Werte anzeigen.

==== notify Befehl ====
define nt.allerolloszu notify (R1ZU|R2ZU|R3ZU) {\
my $r1 = Value("R1ZU");;\
my $r2 = Value("R2ZU");;\
my $r3 = Value("R3ZU");;\
if ($r1 eq "on" && $r2 eq "on" && $r3 eq "on") {\
fhem("set LEDalleRolloZu on");;\
} else {\
fhem("set LEDalleRolloZu off");;\
}\
}

==== Erklärung ====
Es werden die drei Rückgabewerte R1ZU, R2ZU und R3ZU ausgewertet. Danach folgt Perl Code, deswegen beginnt das ganze mit einer { und endet mit }

my $r1 => Variable $r1 definieren
= Value("R1ZU");; ==> weist den Rückgabewert (on oder off) von R1ZU der Variable $r1 zu

Der doppelte ;; ist ein FHEM Thema. Eigentlich würde für Perl ein ; reichen. Aber FHEM nutzt selbst das ; und daher wird ein ;; benötigt. Mit den ersten drei my Zeilen werden die Rückgabewerte den Variablen zugewiesen.

Danach erfolgt ein normales "if then else" Konstrukt. Die Zeile »($r1 eq "on" && $r2 eq "on" && $r3 eq "on")« kann man so lesen: Wenn $r1 den Wert "on" und (&&) $r2 den Wert "on" und $r3 den Wert "on" dann schalte die LEDalleRolloZu ein {fhem("set LEDalleRolloZu on")}
ansonsten else schalte die LED aus. {fhem("set LEDalleRolloZu off")

Alternative: [[structure]]

=== Zeitverzögert schalten ===
{| class="wikitable"
| '''Aufgabe:''' || Zeitverzögert schalten
|-
| '''Beschreibung:''' || Mit einem Notify zeitverzögert eine Aktion auslösen.
|-
| '''Vorbereitung:''' || Gerät "Lampe" ist definiert und es gibt eine Situation, die ein Ereignis "Fernbedienung:.*" generiert.
|-
| '''Befehl:''' || <code>define ntfy1 notify Fernbedienung:.* sleep 7.5;; set Lampe $EVENT</code>
|-
| '''Erläuterungen:''' || Bei Eintreten eines Ereignisses "Fernbedienung*" wird nach einer Pause von siebeneinhalb Sekunden der Befehl <set Lampe ??> ausgeführt, wobei der eigentliche Befehl aus dem auslösenden Ereignis übernommen wird.
:''Quelle: {{Link2Forum|Topic=17161|LinkText=FHEM Forum}}''
|}

=== Eine PV-Anlage (Solarstrom) zur Steuerung der Rollos nutzen (optional Zeit und Datums abhängig) ===
Hier ein kleines Beispiel, wie man mit Hilfe einer PV-Anlage die Sonneneinstrahlung auf der Südseite ermittelt und dies zur Rolladensteuerung nutzt.
Optional: Die Funktion soll allerdings nur zwischen 9:30 und 17:00 stattfinden. (zweites Beispiel)
Optional: Die Funktion soll nur zwischen dem 6. und 9. Monat funktioneren. (drittes Beispiel)

==== Vorbereitung ====
PV Anlage mit SolarView abfragen.
Per Hand ermitteln, ab wieviel erzeugtem Strom es sinnvoll ist die Rollos zu schließen.

==== notify Syntax ====
FHEM:

define sv SolarView solarview 15000 wr1 wr2 wr3 wr4 <----vier Wechselrichter
attr sv event-on-change-reading currentPower

define nt.sonnenlichtpersolar notify sv:currentPower.* { \
if ($EVTPART1 < 3000 ) {\
fhem('set Flur1 Auf')\
}else {\
if ($EVTPART1 > 5000 ) {\
fhem('set Flur1 Ab')\
} \
}\
}

Optional 1: Zeitabhängig (Code gehört in die DEF)
<syntaxhighlight lang="perl">
sv:currentPower.* {
my $hm = sprintf("%02d:%02d", $hour, $min);
if ( $hm gt "09:30" && $hm lt "17:00") {
if ($EVTPART1 < 5000 ) {
fhem('set Flur1 Auf')
}else {
if ($EVTPART1 > 8000 ) {
fhem('set Flur1 Ab')
}
}
}
}
</syntaxhighlight>
Optional 2: Zeit und Datum (Code gehört in die DEF)
<syntaxhighlight lang="perl">
sv:currentPower.* {
my $hm = sprintf("%02d:%02d", $hour, $min);
if ($month >= 6 && $month <= 9) {
if ( $hm gt "09:30" && $hm lt "17:00") {
if ($EVTPART1 < 5000 ) {
fhem('set Flur1,RBUERO1,RBUERO2 Auf');
}else {
if ($EVTPART1 > 8000 ) {
fhem('set Flur1,Flur2,RBUERO1,RBUERO2 Ab');
}
}
}
}
}
</syntaxhighlight>

==== Erklärung ====
* Das define wird in der Kommandozeile im Webbrowser eingegeben.
* Anschließend wird im Webbrowser die DEF bearbeitet, das erspart uns Probleme mit Perl
* define sv SolarView ... <==== ist die Schnittstelle vom SolarView
* define nt.sonnenlichtpersolar notify (sv:currentPower.*) { <==== hier wird ein notify angelegt, der auf das "define sv" Wert "currentPower.*" (.* ist irgendwas) reagiert
if ($EVTPART1 < 3000 ) {
fhem('set Flur1 Auf');
}else {
if ($EVTPART1 > 5000 ) {
fhem('set Flur1 Ab');
}
}
}
Diese if-Funktion wertet den Rückgabewert von currentPower aus. Hierbei muss man wissen, dass $EVTPART1 das Split-Ergebnis vom Rückgabewert ist

Beispiel: Der Rückgabewert (wie im Beispiel) ist "currentPower: 6000".
Jetzt steht im "$EVTPART0 == currentPower:" und im "$EVTPART1 == 6000"
Das bedeutet, dass man sich nicht selbst den richtigen split (Perl Befehl) Aufruf ausdenken muss, dies übernimmt vielmehr FHEM.

Ergebnis:
Das Rollo wird abhängig von der erzeugten IST_Strommenge auf und zu gefahren.
Damit dies nicht dauernd hin und her pendelt, wurde der Auf Wert sehr klein und den Ab Wert sehr groß gewählt.

'''Optional 1:''' Der Block "my $hm = sprintf("%02d:%02d", $hour, $min);" erzeugt die String-Variable $hm mit dem Inhalt $hour:$min. %02d begrenzt die Ausgabe auf zwei Stellen.
Danach wird mit "if ( $hm gt "09:30" && $hm lt "17:00")" mit stringvergleichenden Operatoren geprüft, ob die Uhrzeit zwischen 9:30 und 17:00 liegt (lt = kleiner als; gt = größer als). Es wäre auch ein le und ge möglich: le = kleiner/gleich als, ge = größer/gleich als.

'''Optional 2:'''if( $month >= 6 && $month <= 9) {

Hier wird die numerische FHEM-Standard-Variable $month (Monat) auf größer/gleich bzw kleiner/gleich mit den binären Operatoren überprüft.
Die Funktion arbeitet also nur zwischen dem 6. und dem 9. Monat und dann auch nur zwischen 9:31 und 16:59.

=== Status eines Kippfensters mit 2 Fensterkontakten abbilden ===

==== Vorbereitung ====
Es ist je ein Fensterkontakt der ''open'' oder ''closed'' meldet, oben und unten am Fenster angebracht.
Die Namen der beiden FHEM-Devices sind ''fensterKontaktOben'' und ''fensterKontaktUnten''.

==== notify Syntax ====
FHEM:
define statusFenster notify fensterKontakt(Oben|Unten):(open|closed) {\
if ( ReadingsVal('fensterKontaktOben', 'state', 'undef') eq 'open' && ReadingsVal('fensterKontaktUnten', 'state', 'undef') eq 'open')\
{ fhem 'set Terrassentuer open' }\
if ( ReadingsVal('fensterKontaktOben', 'state', 'undef') eq 'closed' && ReadingsVal('fensterKontaktUnten', 'state', 'undef') eq 'closed')\
{ fhem 'set Terrassentuer closed' }\
if ( ReadingsVal('fensterKontaktOben', 'state', 'undef') eq 'open' && ReadingsVal('fensterKontaktUnten', 'state', 'undef') eq 'closed')\
{ fhem 'set Terrassentuer tilted' }\
if ( ReadingsVal('fensterKontaktOben', 'state', 'undef') eq 'closed' && ReadingsVal('fensterKontaktUnten', 'state', 'undef') eq 'open')\
{ fhem 'set Terrassentuer undef' }\
}

== Weitere Hinweise ==
* Entsprechend zu $EVENT gibt es auch noch $NAME und $TYPE. $NAME und $TYPE enthalten den Namen bzw. Typ des Ereignis auslösenden Gerätes.
* Wird der Perl-Code in einem <code>notify</code> immer länger, lagere den Code wegen der Übersichtlichkeit in eine eigene Programmdatei aus, wie in [[99_myUtils anlegen]] beschrieben.
* Achtung! Wenn man das Skript für den notify-Befehl über mehrere Zeilen schreibt, muss man anscheinend darauf achten, dass keine abschließende Leerzeile mitgespeichert wird. Sonst wird der notify-Befehl ignoriert.
* Dieser {{Link2Forum|Topic=38520|Message=307325}} enthält Vorschläge zur Vorgehensweise bei der Erstellung von komplexen ''notify'' Definitionen bzw. bei deren Fehlerbehebung.

== Weiterführende Links ==
* [[Escapen in Perlbefehlen]]
* [[Klammerebenen]]
* Forenbeitrag zum Thema {{Link2Forum|Topic=115414|LinkText=Optimierung des Suchmusters - NOTIFYDEV}}

== Hinweise ==
<references />

[[Kategorie:HOWTOS]]
[[Kategorie:Hilfsmodul]]

Notify

2023-04-29T15:03:33Z

TomLee: /* Syntax */

{{SEITENTITEL:notify}}
{{Infobox Modul
|ModPurpose=Ausführung von Anweisung(en) als Reaktion auf Ereignisse
|ModType=h
|ModCmdRef=notify
|ModForumArea=Automatisierung
|ModTechName=91_notify.pm
|ModOwner=rudolfkoenig ({{Link2FU|8|Forum}} / [[Benutzer Diskussion:Rudolfkoenig|Wiki]])
}}

== Einführung ==
{{Hinweis|Weitere grundlegende Informationen/Beispiele zu notify enthält [http://fhem.de/Heimautomatisierung-mit-fhem.pdf Heimautomatisierung mit FHEM]}}
Das Hilfsmodul notify dient dazu [[Ereignis|Ereignisse]] über ein Suchmuster zu erkennen und bei einem Treffer eine Aktion auszulösen. Mit ''notify'' und anderen [[Eventhandler|Eventhandlern]] <ref>hierzu gehören u.a. auch [[DOIF]], [[THRESHOLD]] und [[watchdog]]</ref> ist es möglich, Logikfunktionen im FHEM abzubilden.

'''Beispiele:'''
* Wird das Licht in der Küche eingeschaltet, soll FHEM dort auch das Radio einschalten.
* Bei Druck auf einen Taster soll die Umwälzpumpe für das Warmwasser eingeschaltet werden.
* Erweiterte Möglichkeiten: Aber nur, wenn das Radio aus ist bzw. die Temperatur im Rücklauf des Warmwassers unterhalb einer bestimmten Schwelle liegt<ref>vgl. hierzu z.B. {{Link2CmdRef|Anker=devspec|Label=FILTER}} und [[if-condition]]</ref>.

== Syntax ==

define <name> notify <Suchmuster> <command>

Das ''[[Regulärer Ausdruck|Suchmuster]]'' (häufig als Regexp = regular expression = regulärer Ausdruck bezeichnet) ist sehr wichtig: Es ist entweder der Name des auslösenden ("triggernden") Gerätes oder die Kombination aus Gerät und auslösendem Ereignis (Event) <code>Gerätename:Event</code>. Die Events kann man dem [[Event_monitor|Event-Monitor]] entnehmen. Wenn dort z.B. <code>Rollo1</code> steht, dann reagiert ''notify'' auf <code>Rollo1 on</code> und <code>Rollo1 off</code> usw.

Wenn man mehrere Suchmuster kombinieren möchte, kann man diese in Klammer schreiben, als Trenner wird dann Pipe (|) genutzt: <code>(Rollo1|Rollo2|Steckdose5)</code>.

'''Auch die Verwendung von Platzhaltern ist möglich''':
* <code>Rollo.</code> → das notify reagiert auf alles was mit Rollo und '''einem''' weiteren beliebigen Zeichen anfängt. Also auf Rollo1 wie auch auf RolloG, aber nicht auf Rollo_wischundweg
* <code>Rollo.*</code> → notify reagiert auf alles das mit Rollo beginnt
* <code>.*isch</code> → auf alles das mit isch aufhört (Tisch, Fisch)
* <code>Schalter(1|2|3)</code> → hört auf Schalter1, Schalter2 und Schalter3
* <code>dimmer:pct:.(100|7[6-9]|[89][0-9])</code> → reagiert, wenn pct einen Wert über 75 annimmt.

Suchmuster/Regex kann man im Internet beispielsweise auf [http://regexpal.com/| http://regexpal.com/] testen.

Es gibt seit Juli 2020 eine Perlfunktion notifyRegexpCheck zum Testen, wie FHEM über das Suchmuster "denkt" - siehe {{Link2Forum|Topic=111938|Message=1074202|LinkText=diesen Beitrag}} im Forum.

{{Hinweis|Das '''Suchmuster''' wird notify-intern um das Zeichen ^ (beginnt mit) und das Zeichen $ (endet mit) ergänzt<ref>Der Eventhandler [[DOIF]] verwendet die in Perl übliche Syntax für reguläre Ausdrücke als DOIF-Suchmuster.</ref>.

Deshalb darf das Suchmuster nicht mit einem üblichen [[Regulärer Ausdruck|'''Regulären Ausdruck''']], wie er in Perl<ref>https://perldoc.perl.org/perlre.html</ref> verwendet wird, gleichgesetzt werden, da die Ergänzung zu einem grundsätzlich unterschiedlichen Verhalten führt, siehe nachstehendes Beispiel.}}

'''Beispiel für das unterschiedliche Verhalten von ''Suchmuster'' und ''regulären Ausdruck'''''

Für einen '''regulären Audruck''' gilt: Wenn der reguläre Ausdruck ''lampe'' ist und das [[Ereignis]] ''tischlampe'' dann passen ''tischlampe'' und ''lampe'' zueinander.

Für das '''Suchmuster''' gilt: Wenn das Suchmuster ''lampe'' ist und das [[Ereignis]] ''tischlampe'' dann passen ''tischlampe'' und ''lampe'' '''nicht''' zueinander, weil das Suchmuster zu ^lampe$ ergänzt wird und damit exakt nur auf ''lampe'' matcht (passt).

'''Variablen Zuordnung zum Event'''

'''Beispiel 1'''

2020-01-21 22:40:39 HUEDevice VibrationTest1 battery: 88
{| class="wikitable"
|-
! !!$NAME !! colspan="2" |$EVENT
|-
| ||||$EVTPART0 ||$EVTPART1
|-
|2020-01-21 22:40:39 HUEDevice|| VibrationTest1|| battery:|| 88
|}

'''Beispiel 2'''
2021-05-09 19:11:43 FB_CALLMONITOR cm_example external_name: Graf Herzog von und zu ...
{| class="wikitable"
|-
! !!$NAME !! colspan="7" |$EVENT
|-
| ||||$EVTPART0 ||$EVTPART1 || $EVTPART2|| $EVTPART3 || $EVTPART4|| $EVTPART5|| ...
|-
|2021-05-09 19:11:43 FB_CALLMONITOR|| cm_example|| external_name:|| Graf|| Herzog|| von|| und|| zu|| ...
|}

'''Beispiel 3'''

2023-04-29 16:53:04 dummy Demo closed
{| class="wikitable"
|-
! !!$NAME !! colspan="1" |$EVENT
|-
| ||||$EVTPART0
|-
|2020-01-21 22:40:39 dummy|| Demo|| closed
|}

== FHEMWEB-unterstütztes Anlegen eines notify ==
{{Hinweis|Die Erstellung eines notify und insbesondere die korrekte Angabe des Suchmusters (Regex) führt gerade bei Einsteigern immer wieder zu Schwierigkeiten. Zur Fehlerminimierung empfiehlt es sich zum einen, die [[Konfiguration]] nicht direkt zu bearbeiten, sondern die "Befehl-Eingabezeile", die "Objektdetails" oder den [[Import von Code Snippets|Import von RAW-Definitionen]] zur Bearbeitung zu nutzen.}}

=== Event Monitor ===
Die komfortabelste Möglichkeit, die häufigsten Event-Handler zu erstellen, bietet der [[Event monitor|Event-Monitor]]. Die Vorgehensweis ist in dem zugehörigen Artikel dargestellt.

=== Regexp wizard ===
Zudem enthält FHEM einen Regexp wizard mit dem Regex anhand der in FHEM vorhandenen Devices und deren Events aus einer Auswahlbox selektiert werden können. Voraussetzungen sind:
* Aktivierung des Hilfsmoduls [[eventTypes]] (bei allen Neuinstallationen Standard)
* das gesuchte Ereignis (Event) ist nach Aktivierung des Hilfsmoduls bereits mindestens einmal eingetreten

Schrittweise Darstellung der Nutzung des Regexp wizard zur Anlage eines "notify":

In das [[Konfiguration#Befehl-Eingabefeld|Befehls-Eingabefeld]] eingeben und mit {{Taste|Enter}} bestätigen:
define ntest notify a b
Als Beispiel wird ein notify mit <name> "ntest" angelegt. "a" und "b" sind beliebige Platzhalter für <Suchmuster> und <Command>, die bei der weiteren Bearbeitung mit dem endgültigen Werten ersetzt werden.
Der Regexp wizard öffnet sich:
[[Datei:Regexp wizard1.JPG|400px|thumb|center]]
Nun in der Auswahlbox das auslösende Event (Ereignis) auswählen; zunächst das Device und dann das gewünschte Regex. Hier soll das notify bei jeder Veränderung der Temperatur (temperature.*) des Device BTHR918N reagieren. Abschließend mit einem Mausklick auf {{Taste|set}} bestätigen. Wählt man mehrere Regex in dieser Weise aus, so wird das "notify" bei Eintritt jedes dieser Events ausgeführt:
[[Datei:Regexp wizard2.JPG|400px|thumb|center]]
Anschließend den Platzhalter "a" mit Klick auf den Link "removeRegexpPart" löschen:
[[Datei:Regexp wizard3.JPG|400px|thumb|center]]
Den Link "DEF" anklicken, damit sich der DEF-Editor öffnet:
[[Datei:Regexp wizard4.JPG|400px|thumb|center]]
Jetzt den auszuführenden Befehl im "DEF"-Bereich durch Überschreiben des Platzhalters "b" eintragen und mit Klick auf {{Taste|modify ntest}} abschließen:
[[Datei:Regexp wizard5.JPG|400px|thumb|center]]
Das fertige und sofort aktive "notify" sieht abschließend folgendermaßen aus:
[[Datei:Regexp wizard6.JPG|400px|thumb|center]]
Am Schluss das Speichern über {{Taste|Save config}} nicht vergessen.

== Mein notify geht nicht - wie kann ich mir selbst helfen: Debugging ==
Funktioniert ein notify nicht wie gewünscht, kann es nur zwei Hauptursachen haben:
* Entweder das Suchmuster paßt nicht zum gewünschten Auslöser (FHEM Device), und/oder
* die Anweisung enthält einen Fehler.
Sollte kein Fehler im Logfile auftauchen aber das notify ausgelöst werden, stimmt meist der Übertragungsweg zum Zieldevice nicht.
Der STATE des notify zeigt normalerweise mit Datum/Uhrzeit die letzte Auslösung an.

Beim Debuggen sollte man daher beide Elemente getrennt untersuchen. Hier ein Beispiel welches nicht wie gewünscht funktioniert:
<syntaxhighlight lang="perl"> define n_test notify n_test:muster Ausführungsteil</syntaxhighlight>
Zum debuggen benötigen wir
* den [[Event monitor]]
* das [https://fhem.de/commandref.html#trigger trigger-Kommando] - kann man jederzeit verwenden um das Suchmuster als Event unabhängig vom Auslöser zu erzeugen.
* die FHEM Kommandozeile
* den [[DEF-Editor]]
* eventuell einen Texteditor um Codeblöcke zwischen zu lagern und Notizen zu machen.

Das Suchmuster im Beispiel notify triggert auf sich selbst, es soll auf jeden Event mit dem Inhalt '''muster''' ausgelöst werden, Beispiel:
2018-07-14 14:31:03 notify n_test muster bild

=== Suchmuster ===
Sollte das notify nicht funktionieren:
* keine Reaktion wie gewünscht
* keine Fehlermeldung in der Weboberfläche beim Anlegen, keine Fehlermeldung im Logfile
* STATE ist unverändert auf active oder einem altem Datum/Uhrzeit
liegt der Fehler mit Sicherheit im Suchmuster. Man hat die Chance das Suchmuster mit dem trigger Befehl zu erzeugen und zu schauen ob die Anweisung ausgeführt wird. Dabei ist zu beachten: Der erste ":" im Suchmuster ist zusätzlich zwischen Gerät und Event als Trennung. Jeder weiter : ist, wenn vorhanden, Bestandteil des Events! Siehe dazu den Abschnitt [https://fhem.de/commandref_DE.html#notify Hinweise in der commandref]
*Im Beispiel: Event: n_test muster -> Suchmuster n_test:muster
Um aus dem [[Event]] ein passendes Suchmuster zu erzeugen kann der [[Event monitor|Event-Monitor]] direkt verwendet werden. Man kann ein neues notify erzeugen oder ein Bestehendes modifizieren lassen.

Unser Regex im Beispiel ist zu spezifisch, es triggert nur exakt auf '''muster'''. Dieser Trigger erzeugt den folgenden Eintrag im Eventmonitor, entspricht exakt dem Suchmuster und löst das notify aus:
trigger n_test muster
2018-07-13 11:52:08 notify n_test muster
Das Suchmuster für unsere Anforderung muss in <code>n_test:muster.*</code> geändert werden, damit jeder Event der mit muster beginnt das notify auslöst.
Der . im Regex steht für jedes beliebige Zeichen und der * für eine beliebige Anzahl des Zeichens davor: also beliebig viele beliebige Zeichen nach muster.

Das Suchmuster wird häufig in ein komplizierteres Regex umgewandelt um im notify mehrere Aktionen zu starten. Das eigene Regex kann z.B. mit http://regexpal.com/ oder https://regex101.com/ getestet werden.

Funktioniert der Auslöser, das notify tut aber noch nicht was es soll, müssen wir die Anweisung untersuchen. In unserem korrigierten Beispiel
<syntaxhighlight lang="perl"> defmod n_test notify n_test:muster.* Ausführungsteil</syntaxhighlight>
folgt beim Kommando <code>trigger n_test muster bild</code> ein Eintrag im Log:
2018.07.13 11:47:57 3: n_test return value: Unknown command Ausführungsteil, try help.
Das notify wurde zwar getriggert aber die Anweisung war nicht ausführbar.

Ein richtiges Suchmuster und eine fehlerhafte Anweisung wird also normalerweise einen Fehlereintrag im Logfile erzeugen!

=== Spezialfall: notify löst zwar aus - aber zu oft ===
In dem Fall ist das Suchmuster (regExp) zu unscharf oder das triggernde Gerät löst das Event zu oft aus. Das regExp sollte so genau wie möglich konstruiert werden, device:.* ist eine einfache aber oft keine gute Wahl!

Im Device, welches den Event auslöst, kann mit den Attributen event-on-.* die Häufigkeit gesteuert werden. Insbesondere ist hier das regExp .* eine Art Standardwahl um aufeinanderfolgende gleichartige Events zu verhindern.
:<code>attr device event-on-change-reading .*</code>
'''Achtung''': durch falsche Angaben kann man Events ganz leicht völlig verhindern!

Siehe auch [[event-on-change-reading]]

=== Anweisung ===
Wird das notify getriggert oder will man ganz schnell mal ein notify testen, kann man die Anweisung durch folgenden Code ersetzen, man öffnet also einfach nur die DEF, kopiert den ursprünglichen Inhalt an einen sicheren Ort und ersetzt die Anweisung durch eine der beiden Zeilen. Die erste Zeile kann man auch einfach mal in der Kommandozeile testen:
<syntaxhighlight lang="perl">{Log 1, "Das Notify n_test hat ausgeloest."}
{Log 1, "Das Device $NAME hat ausgeloest, der Event sah so aus: $EVENT"}</syntaxhighlight>
Wird das notify ausgelöst, muss anschließend im Logfile ein Eintrag zu finden sein:
2018.07.13 10:28:57 1: Das Notify n_test hat ausgeloest, der Event sah so aus: muster
Unsere Anweisung <code>Ausführungsteil</code> liefert in der Kommandozeile selbst einen Fehler:
<code>Unknown command Ausführungsteil, try help.</code>
Ein Versuch mit geschweiften Klammern <code>{Ausführungsteil}</code> liefert wieder einen Fehler:
<code>Unrecognized character \xC3; marked by <-- HERE after {Ausf<-- HERE near column 6 at (eval 5977) line 1.</code>
Diese Variante <code>{"Ausführungsteil"}</code> liefert den String Ausführungsteil ohne Fehler: Das notify arbeitet fehler- aber sinnfrei.
Der fertige Code:
defmod n_test notify n_test:muster.* {"Ausführungsteil"}

Man kann die Anweisung, normalerweise so wie sie ist, in der FHEM Kommandozeile testen. Sind im Perl Code (in geschweiften Klammern) im DEF Editor Semikolon enthalten muss man diese für den Test in der Kommandozeile (oder Raw Def) verdoppeln.
Laufzeitabhängige Variablen sind in der Kommandozeile meist nicht verfügbar, diese sollte man für den Test einfach durch passende Inhalte austauschen. So kann man die komfortable Variante (loggt den Namen und das komplette Event) nicht in der Kommandozeile ausführen.

Funktioniert ein FHEM Befehl in der Kommandozeile nicht (z.B. Lampe geht nicht an) kann es im notify auch nicht funktionieren, dann muss die Fehlersuche an anderer Stelle fortgeführt werden.

Komplexeren Code im Ausführungsteil sollte man beim Testen in Teilabschnitte aufteilen, von der Laufzeit abhängige Variable ($NAME, $EVENT, $EVTPART) durch Strings ("TestWort") ersetzen, die Teilabschnitte separat testen und anschließend schrittweise wieder komplettieren.

== Beispiele ==
{{Hinweis|Für die nachfolgenden Beispiele wurden einige unterschiedliche Technologien verwendet. Sie können aber recht einfach auf alle anderen Systeme übertragen werden, dabei sollte ggf. darauf geachtet werden, dass sich Schaltbefehle und Events teilweise je nach konkret eingesetzter Technologie unterscheiden können. Dann ist ggf. eine Erweiterung, z.B. durch eine [[if-condition|if-Abfrage]] erforderlich.}}

=== Schalter entprellen ===
Will man ein notify innerhalb eines bestimmten Zeitraumes nur einmal auslösen lassen, auch wenn er in diesem Zeitraum mehrfach getriggered werden sollte, so bietet sich das Attribut disabledAfterTrigger an,
attr <notify_device> disabledAfterTrigger <Anzahl Sekunden>
In dem Zeitraum wird dann nur einmal (beim ersten Mal) der Befehl ausgelöst, auch wenn mehrfach getriggered wurde. Der Zeitraum kann Bruchteile von Sekunden umfassen.

=== Etwas schalten, wenn ein anderes Gerät geschaltet wird ===

==== Vorbedingungen ====
Dieses Beispiel verwendet eine einfache InterTechno-kompatible Funksteckdose für das Radio und einen HM-Aktor für das Licht:

define RadioKueche IT 000000FFFF 0F F0
define LichtKueche CUL_HM 3A37D6
Beachte: beide kennen als Event bzw. Schaltbefehle ''on'' und ''off''.

==== notify Befehl ====
define LichtamRadioan notify LichtKueche set RadioKueche $EVENT
oder alternativ:
define LichtamRadioan notify LichtKueche { fhem "set RadioKueche $EVENT" }

==== Erklärung ====
* Der Name des ''notify'' "LichtamRadioan" kann frei gewählt werden, er dient nur dazu, das notify in FHEM eindeutig zu identifizieren.
* "$EVENT" ist ein Platzhalter für den Zustand vom Pattern. $EVENT enthält ein "off" wenn das LichtKueche aus- und ein "on" wenn das Licht eingeschaltet wird.
* "{ <perlcode> }" alles was zwischen {} steht ist Perl code. Perl kennt das Schlüsselwort fhem. Das Schlüsselwort FHEM dient dazu, FHEM Befehle auszuführen. Es wird also der FHEM Befehl "set RadioKueche on/off" ausgeführt. on oder off ist abhängig vom Pattern. Der eigentliche FHEM Befehl muss in " " stehen.
* Wann ist ein Wechsel auf die Perl-Ebene erforderlich?
** einfache FHEM-Befehle sollten in der Regel direkt verwendet werden, dies ist ressourcenschonender.
** Immer dann, wenn dies nicht möglich ist, weil z.B. komplexerer Code ausgeführt werden soll, (blockierende) Prozesse ausgelagert werden sollten oder Systembefehle ausgeführt werden, ist es günstiger, auf die Perl-Ebene zu wechseln <ref>In diesem {{Link2Forum|Topic=88398|Message=808685|LinkText=Forenbeitrag}} wird z.B. erläutert, wie man nichtblockierend externe Scripte aufrufen kann, die dann ihre Ergebnisse wieder an FHEM übergeben.</ref>.

=== Einschalten von mehreren Geräten/Lampen, wenn das Licht eingeschaltet wird ===
Dieses Beispiel verwendet einen HM-Aktor für das Licht sowie zwei Milight-Birnen, die einzeln geschaltet werden sollen<ref>Dies ist ausdrücklich keine Empfehlung für diese Technologie und der Module</ref> in den Stehlampen:

==== Vorbedingungen ====
FHEM:
define LichtWZ CUL_HM 3A37D8
define Stehlampe1 MilightDevice RGBW Milight_Wohnzimmer 5
define Stehlampe2 MilightDevice RGBW Milight_Wohnzimmer 6

==== notify Befehl ====
define SteckdoseWZein notify LichtWZ set Stehlampe1,Stehlampe2 $EVENT
oder ''in Perl''
define SteckdoseWZein notify LichtWZ { fhem "set Stehlampe1 $EVENT;;set Stehlampe2 $EVENT " }
==== Erklärung ====
Wenn das LichtWZ eingeschaltet wird, dann werden auch die Stehlampen (1 und 2) eingeschaltet.

=== Einfache ODER Funktion ===
Eine einfache ODER Funktion kann sehr einfach realisiert werden

==== Vorbereitung ====
KNX:
* 3x GAs der abzufragende Werte (0/0/40 0/0/41 0/0/42)

FHEM:
define Licht1 CUL_HM 3A37D8
define Licht2 CUL_HM 1B7EC3
define Stehlampe MilightDevice RGBW Milight_Wohnzimmer 7

==== notify Befehl ====
define SteckdoseWZein notify (Licht1|Licht2) set Stehlampe $EVENT
oder
define SteckdoseWZein notify (Licht.) set Stehlampe $EVENT

==== Erklärung ====
Die Werte in der Klammer (wichtig ist das »|«) sind die Rückgabewerte. Alternativ kann in diesem Beispiel auch »Licht.« (zu beachten ist der Punkt) geschrieben werden. Der Punkt ist ein Platzhalter für (genau) ein beliebiges Zeichen.

Danach folgt der set Befehl.
Wenn also das Licht1 oder Licht2 den Wert "on" hat, dann hat auch die Steckdose den Wert "on"

Alternative: [[structure]]

=== Einfache UND Funktion ===
Ob man dieses Konstrukt noch als einfach bezeichnen kann, wage ich mal zu bezweifeln. In FHEM fehlen Loggingfunktionen, die man alle selber mit Perl Code erstellen kann (Danke an MAZ).
Dadurch ist FHEM zwar mächtig, wird aber für viele sehr kompliziert.

In diesem Beispiel soll - wenn drei Rollos geschlossen sind - am Taster eine LED eingeschaltet werden.

==== Vorbereitung ====
KNX:
* 3x GDs für die Rückgabewert Rollo geschlossen == 1 (0/0/50 0/0/51 0/0/52)
* GD LED am Lichtschalter (0/0/106)

FHEM:
define R1ZU KNX 0/0/50:dpt1.009
attr R1ZU dummy 1
define R2ZU KNX 0/0/51:dpt1.009
attr R2ZU dummy 1
define R3ZU KNX 0/0/52:dpt1.009
attr R3ZU dummy 1
define LEDalleRolloZu KNX 0/0/106:dpt1
Durch das Attribut dummy werden keine Schaltfunktion angeboten. Es kann nur Werte anzeigen.

==== notify Befehl ====
define nt.allerolloszu notify (R1ZU|R2ZU|R3ZU) {\
my $r1 = Value("R1ZU");;\
my $r2 = Value("R2ZU");;\
my $r3 = Value("R3ZU");;\
if ($r1 eq "on" && $r2 eq "on" && $r3 eq "on") {\
fhem("set LEDalleRolloZu on");;\
} else {\
fhem("set LEDalleRolloZu off");;\
}\
}

==== Erklärung ====
Es werden die drei Rückgabewerte R1ZU, R2ZU und R3ZU ausgewertet. Danach folgt Perl Code, deswegen beginnt das ganze mit einer { und endet mit }

my $r1 => Variable $r1 definieren
= Value("R1ZU");; ==> weist den Rückgabewert (on oder off) von R1ZU der Variable $r1 zu

Der doppelte ;; ist ein FHEM Thema. Eigentlich würde für Perl ein ; reichen. Aber FHEM nutzt selbst das ; und daher wird ein ;; benötigt. Mit den ersten drei my Zeilen werden die Rückgabewerte den Variablen zugewiesen.

Danach erfolgt ein normales "if then else" Konstrukt. Die Zeile »($r1 eq "on" && $r2 eq "on" && $r3 eq "on")« kann man so lesen: Wenn $r1 den Wert "on" und (&&) $r2 den Wert "on" und $r3 den Wert "on" dann schalte die LEDalleRolloZu ein {fhem("set LEDalleRolloZu on")}
ansonsten else schalte die LED aus. {fhem("set LEDalleRolloZu off")

Alternative: [[structure]]

=== Zeitverzögert schalten ===
{| class="wikitable"
| '''Aufgabe:''' || Zeitverzögert schalten
|-
| '''Beschreibung:''' || Mit einem Notify zeitverzögert eine Aktion auslösen.
|-
| '''Vorbereitung:''' || Gerät "Lampe" ist definiert und es gibt eine Situation, die ein Ereignis "Fernbedienung:.*" generiert.
|-
| '''Befehl:''' || <code>define ntfy1 notify Fernbedienung:.* sleep 7.5;; set Lampe $EVENT</code>
|-
| '''Erläuterungen:''' || Bei Eintreten eines Ereignisses "Fernbedienung*" wird nach einer Pause von siebeneinhalb Sekunden der Befehl <set Lampe ??> ausgeführt, wobei der eigentliche Befehl aus dem auslösenden Ereignis übernommen wird.
:''Quelle: {{Link2Forum|Topic=17161|LinkText=FHEM Forum}}''
|}

=== Eine PV-Anlage (Solarstrom) zur Steuerung der Rollos nutzen (optional Zeit und Datums abhängig) ===
Hier ein kleines Beispiel, wie man mit Hilfe einer PV-Anlage die Sonneneinstrahlung auf der Südseite ermittelt und dies zur Rolladensteuerung nutzt.
Optional: Die Funktion soll allerdings nur zwischen 9:30 und 17:00 stattfinden. (zweites Beispiel)
Optional: Die Funktion soll nur zwischen dem 6. und 9. Monat funktioneren. (drittes Beispiel)

==== Vorbereitung ====
PV Anlage mit SolarView abfragen.
Per Hand ermitteln, ab wieviel erzeugtem Strom es sinnvoll ist die Rollos zu schließen.

==== notify Syntax ====
FHEM:

define sv SolarView solarview 15000 wr1 wr2 wr3 wr4 <----vier Wechselrichter
attr sv event-on-change-reading currentPower

define nt.sonnenlichtpersolar notify sv:currentPower.* { \
if ($EVTPART1 < 3000 ) {\
fhem('set Flur1 Auf')\
}else {\
if ($EVTPART1 > 5000 ) {\
fhem('set Flur1 Ab')\
} \
}\
}

Optional 1: Zeitabhängig (Code gehört in die DEF)
<syntaxhighlight lang="perl">
sv:currentPower.* {
my $hm = sprintf("%02d:%02d", $hour, $min);
if ( $hm gt "09:30" && $hm lt "17:00") {
if ($EVTPART1 < 5000 ) {
fhem('set Flur1 Auf')
}else {
if ($EVTPART1 > 8000 ) {
fhem('set Flur1 Ab')
}
}
}
}
</syntaxhighlight>
Optional 2: Zeit und Datum (Code gehört in die DEF)
<syntaxhighlight lang="perl">
sv:currentPower.* {
my $hm = sprintf("%02d:%02d", $hour, $min);
if ($month >= 6 && $month <= 9) {
if ( $hm gt "09:30" && $hm lt "17:00") {
if ($EVTPART1 < 5000 ) {
fhem('set Flur1,RBUERO1,RBUERO2 Auf');
}else {
if ($EVTPART1 > 8000 ) {
fhem('set Flur1,Flur2,RBUERO1,RBUERO2 Ab');
}
}
}
}
}
</syntaxhighlight>

==== Erklärung ====
* Das define wird in der Kommandozeile im Webbrowser eingegeben.
* Anschließend wird im Webbrowser die DEF bearbeitet, das erspart uns Probleme mit Perl
* define sv SolarView ... <==== ist die Schnittstelle vom SolarView
* define nt.sonnenlichtpersolar notify (sv:currentPower.*) { <==== hier wird ein notify angelegt, der auf das "define sv" Wert "currentPower.*" (.* ist irgendwas) reagiert
if ($EVTPART1 < 3000 ) {
fhem('set Flur1 Auf');
}else {
if ($EVTPART1 > 5000 ) {
fhem('set Flur1 Ab');
}
}
}
Diese if-Funktion wertet den Rückgabewert von currentPower aus. Hierbei muss man wissen, dass $EVTPART1 das Split-Ergebnis vom Rückgabewert ist

Beispiel: Der Rückgabewert (wie im Beispiel) ist "currentPower: 6000".
Jetzt steht im "$EVTPART0 == currentPower:" und im "$EVTPART1 == 6000"
Das bedeutet, dass man sich nicht selbst den richtigen split (Perl Befehl) Aufruf ausdenken muss, dies übernimmt vielmehr FHEM.

Ergebnis:
Das Rollo wird abhängig von der erzeugten IST_Strommenge auf und zu gefahren.
Damit dies nicht dauernd hin und her pendelt, wurde der Auf Wert sehr klein und den Ab Wert sehr groß gewählt.

'''Optional 1:''' Der Block "my $hm = sprintf("%02d:%02d", $hour, $min);" erzeugt die String-Variable $hm mit dem Inhalt $hour:$min. %02d begrenzt die Ausgabe auf zwei Stellen.
Danach wird mit "if ( $hm gt "09:30" && $hm lt "17:00")" mit stringvergleichenden Operatoren geprüft, ob die Uhrzeit zwischen 9:30 und 17:00 liegt (lt = kleiner als; gt = größer als). Es wäre auch ein le und ge möglich: le = kleiner/gleich als, ge = größer/gleich als.

'''Optional 2:'''if( $month >= 6 && $month <= 9) {

Hier wird die numerische FHEM-Standard-Variable $month (Monat) auf größer/gleich bzw kleiner/gleich mit den binären Operatoren überprüft.
Die Funktion arbeitet also nur zwischen dem 6. und dem 9. Monat und dann auch nur zwischen 9:31 und 16:59.

=== Status eines Kippfensters mit 2 Fensterkontakten abbilden ===

==== Vorbereitung ====
Es ist je ein Fensterkontakt der ''open'' oder ''closed'' meldet, oben und unten am Fenster angebracht.
Die Namen der beiden FHEM-Devices sind ''fensterKontaktOben'' und ''fensterKontaktUnten''.

==== notify Syntax ====
FHEM:
define statusFenster notify fensterKontakt(Oben|Unten):(open|closed) {\
if ( ReadingsVal('fensterKontaktOben', 'state', 'undef') eq 'open' && ReadingsVal('fensterKontaktUnten', 'state', 'undef') eq 'open')\
{ fhem 'set Terrassentuer open' }\
if ( ReadingsVal('fensterKontaktOben', 'state', 'undef') eq 'closed' && ReadingsVal('fensterKontaktUnten', 'state', 'undef') eq 'closed')\
{ fhem 'set Terrassentuer closed' }\
if ( ReadingsVal('fensterKontaktOben', 'state', 'undef') eq 'open' && ReadingsVal('fensterKontaktUnten', 'state', 'undef') eq 'closed')\
{ fhem 'set Terrassentuer tilted' }\
if ( ReadingsVal('fensterKontaktOben', 'state', 'undef') eq 'closed' && ReadingsVal('fensterKontaktUnten', 'state', 'undef') eq 'open')\
{ fhem 'set Terrassentuer undef' }\
}

== Weitere Hinweise ==
* Entsprechend zu $EVENT gibt es auch noch $NAME und $TYPE. $NAME und $TYPE enthalten den Namen bzw. Typ des Ereignis auslösenden Gerätes.
* Wird der Perl-Code in einem <code>notify</code> immer länger, lagere den Code wegen der Übersichtlichkeit in eine eigene Programmdatei aus, wie in [[99_myUtils anlegen]] beschrieben.
* Achtung! Wenn man das Skript für den notify-Befehl über mehrere Zeilen schreibt, muss man anscheinend darauf achten, dass keine abschließende Leerzeile mitgespeichert wird. Sonst wird der notify-Befehl ignoriert.
* Dieser {{Link2Forum|Topic=38520|Message=307325}} enthält Vorschläge zur Vorgehensweise bei der Erstellung von komplexen ''notify'' Definitionen bzw. bei deren Fehlerbehebung.

== Weiterführende Links ==
* [[Escapen in Perlbefehlen]]
* [[Klammerebenen]]
* Forenbeitrag zum Thema {{Link2Forum|Topic=115414|LinkText=Optimierung des Suchmusters - NOTIFYDEV}}

== Hinweise ==
<references />

[[Kategorie:HOWTOS]]
[[Kategorie:Hilfsmodul]]

Zeitangaben, rechnen mit

2022-12-22T12:18:14Z

TomLee: Formatierung angepasst

Mit leicht lesbaren Zeitangaben, wie ''07:30'', ''23.05.2017, 09:20'' usw. kann in FHEM nicht ohne Weiteres gerechnet werden, da es sich um Zeichenketten handelt und nicht um Zahlen.

== Verfahren zum Rechnen mit Zeitangaben, die als Zeichenkette vorliegen ==
Die Berechnung erfolgt in Perl. Das Verfahren besteht aus drei Schritten:
* Umwandeln der Zeichenketten in eine Zahl, z.B. Sekunden.
* Berechen einer Zeit als Zahl.
* Umwandeln der Zahl in eine Zeichenkette (Formatierung)

=== Umwandeln eine Zeichenkette in eine Zahl ===
{{Randnotiz|RNTyp=Info|RNText= Hinweis!
* Die von <code>timelocal</code> erwartete Monatsangabe sind Ganzzahlwerte von 0 bis 11 für Januar bis Dezember.}}
Hier hängt das Verfahren von der Struktur der Zeichenkette ab.

Perl und FHEM stellen Funktionen zur Umwandlung bereit.
* <code>time</code> liefert die aktuelle Zeit in Sekunden <ref>http://perldoc.perl.org/functions/time.html</ref>
* <code>time_str2num("YYYY-MM-DD HH:MM:SS")</code> wandelt einen FHEM-Zeitstempel in Sekunden um <ref>{{Link2CmdRef|Lang=de|Anker=perl}}</ref>
* <code>timelocal(<Sekunden>, <Minuten>, <Stunden>, <Tag des Monats>, <Monat>, <Jahr>)</code> wandelt einen Satz von Zeitelementen (Sekunden, Minuten, Stunden usw.) in Sekunden um <ref>http://perldoc.perl.org/Time/Local.html</ref>
* <code>Sekunden + Minuten * 60 + Stunden * 60 * 60 + Tage * 24 * 60 * 60</code> berechnen eines Summanden oder Subtrahenden aus Sekunden, Minuten, Stunden und Tagen.
==== Beispiel: Zeitstempel eines Readings in Sekunden umwandeln ====
time_str2num(ReadingsTimestamp(<devicename>, <reading>,<defaultvalue>))
==== Konstanten innerhalb FHEM ====
FHEM stellt einige Konstanten<ref>{{Link2Forum|Topic=96959|Msg=901268|LinkText=Forum-Thread}}</ref> bereit, um das Rechnen mit Zeiten zu erleichtern, ''DAYSECONDS'', ''HOURSECONDS'', und ''MINUTESECONDS''. Obiger Code kann also auch so geschrieben werden:
Sekunden + Minuten * MINUTESECONDS + Stunden * HOURSECONDS + Tage * DAYSECONDS

=== Umwandeln einer Zahl in eine Zeichenkette ===
{{Randnotiz|RNTyp=Info|RNText= Hinweis!
* Die von <code>localtime</code> zurückgegebene Monatsangabe liegt im Bereich der Ganzzahlwerte 0 bis 11 für Januar bis Dezember.
* Werden keine Parameter angegeben, bezieht sich die Ausgabe auf den aktuellen Zeitpunkt.}}
Zur Umwandlung seien die folgenden Perl-Funktionen genannt:
* <code>"HH:MM, DD.MM.YY" =~ /(\d\d).(\d\d)..(\d\d).(\d\d).(\d\d)/</code> extrahiert HH,MM,DD,MM und YY aus der Zeichenkette HH:MM, DD.MM.YY, die ein Datum in der angegebenen Form enthält. \d steht für eine Ziffer, der Punkt für ein beliebiges Zeichen, die () schreiben den Treffer in spezielle Variablen in der Reihenfolge ihrer Anordnung HH in $1, MM in $2, DD in $3 usw.
* <code>(Sekunden, Minuten, Stunden, Tag des Monats, Monat, Jahr, Nummer des Wochentages, Tag des Jahres, Sommerzeitkennzeichen) = localtime(Zeit in Sekunden)</code> gibt die einzelnen Zeitelemente zurück <ref>http://perldoc.perl.org/functions/localtime.html</ref>
* <code>POSIX::strftime(<Format>,<Array mit Zeitelementen>)</code>, wandelt ein Array aus Zeitelementen, wie es <code>localtime</code> liefert in eine formatierte Zeichenkette um. <Format> wird mit Hilfe bestimmter Formatierungszeichen (%a für den Wochentagnamen, %d für den Tag des Monats usw. <ref>http://search.cpan.org/~dexter/POSIX-strftime-GNU-0.02/lib/POSIX/strftime/GNU.pm</ref>) festgelegt.

==== Beispiel: Wochentag zu Datum ====
Zum heutigen Datum
<syntaxhighlight lang="perl">
{return strftime("%A",localtime)}
</syntaxhighlight>

Zu einem vorgegebenen Datum<syntaxhighlight lang="perl">
{
my ($d,$m,$y) = split(/\./,"06.09.2021");
$m-=1;
return strftime("%A",localtime(timelocal('0','0','0',$d,$m,$y)));
}

</syntaxhighlight>

=== Berechnungsbeispiele ===
Allen Berechnungen zu Grunde liegt die Vorgehensweise in absoluten Sekunden bezogen auf einen Referenzzeitpunkt zu rechnen. Damit umgeht man jeden Wechsel Stunden/Tage/Monate/Jahre.

Die einzeiligen Beispiele sollten im Eingabefeld von FHEMWEB ausführbar sein.

==== Addition zu einem Zeitstempel ====
Gegeben sei ein [[Readings|Reading]] ''motion'' des [[Gerät|Gerätes]] ''BM1'' mit einem Zeitstempel ''2017-08-11 14:17:13''. Es sollen 2 Stunden und 12 Minuten addiert werden und das Ergebnis als HH:MM dargestellt werden.

<syntaxhighlight lang="perl">{POSIX::strftime("%H:%M",localtime(time_str2num(ReadingsTimestamp("BM1","motion","2000-01-01 00:00:00"))+2*60*60+12*60))}</syntaxhighlight>

Schrittweise:
<syntaxhighlight lang="perl">{
my $timestamp = ReadingsTimestamp("BM1","motion","2000-01-01 00:00:00");
my $seconds = time_str2num($timestamp)+2*60*60+12*60;
my $result = POSIX::strftime("%H:%M",localtime($seconds));
return $result;
}</syntaxhighlight>

==== Addition zum aktuellen Zeitpunkt ====
Zur aktuellen Zeit sollen 30 Minuten addiert und das Ergebnis als HH:MM:SS dargestellt werden.

<syntaxhighlight lang="perl">{POSIX::strftime("%H:%M:%S",localtime(time+30*60))}</syntaxhighlight>

==== Subtraktion vom aktuellen Zeitpunkt ====
Zur aktuellen Zeit sollen 45 Minuten subtrahiert und das Ergebnis als HH:MM:SS dargestellt werden.

<syntaxhighlight lang="perl">{POSIX::strftime("%H:%M:%S",localtime(time-45*60))}</syntaxhighlight>

==== Kalendertage von heute bis zu einem Datum ====
Zu einem bestimmten Kalendertag soll die Differenz in ganzen Tagen bestimmt werden.<syntaxhighlight lang="perl">
{(time_str2num('2021-04-30') - time_str2num(strftime '%F',localtime))/86400}
</syntaxhighlight>Das Zieldatum kann z.B. ein Termin aus dem Kalender sein:
:<code>fhem('get AbfallKalender events timeFormat:"%F" format:custom="$T1" limit:from=0,count=1')</code>

=== Weitere Funktionen zur Zeitumwandlung ===
* [[DevelopmentModuleAPI#Time_.2F_Timestamp|Time/Timestamp]]

== Links ==
<references />

[[Kategorie:HOWTOS]]

MQTT2 CLIENT

2022-11-16T21:13:29Z

TomLee: /* Define */

{{Infobox Modul
|ModPurpose=Stellt als Gateway die Verbindung zu einem MQTT-Broker her
|ModType=d
|ModCmdRef=MQTT2_CLIENT
|ModForumArea=MQTT
|ModTechName=10_MQTT2_CLIENT.pm
|ModOwner=rudolfkoenig ({{Link2FU|8|Forum}} / [[Benutzer Diskussion:Rudolfkoenig|Wiki]])}}
Das Modul [[MQTT2_CLIENT]] ermöglicht es, Geräte einzubinden, die über eine MQTT-Schnittstelle verfügen. Es fungiert als [[Interface|Verbindung]] zwischen FHEM und einem externen MQTT Server (z.B. ''mosquitto'') und repräsentiert ein '''''MQTT Gateway'''''. Die durch die Module [[MQTT2_DEVICE]] oder {{Link2CmdRef|Anker=MQTT_GENERIC_BRIDGE|Lang=en|Label=MQTT_GENERIC_BRIDGE}} repräsentierten Client-Geräte sind gesondert anzulegen.

== Voraussetzungen ==
Es muss für jedes MQTT-Gateway ein MQTT-Server eingerichtet und erreichbar sein.
Eine Anleitung zur Einrichtung eines Mosquitto-Brokers finden Sie z.B. im Artikel [[MQTT Einführung]].
{{Hinweis|FHEM selbst kann ebenfalls mit {{Link2CmdRef|Anker=MQTT2_SERVER|Lang=en|Label=MQTT2_SERVER}} als MQTT-Server eingesetzt werden. In diesem Fall ist innerhalb dieser FHEM-Instanz kein MQTT2_CLIENT-Gerät erforderlich. Befindet sich ein MQTT2_SERVER in einer anderen FHEM-Instanz, kann dieser von dort aus mit MQTT2_CLIENT verbunden werden.}}

== Kurzübersicht ==
{{Hinweis|Eine Übersicht über die verschiedenen Möglichkeiten, MQTT in FHEM zu nutzen, ist in [[MQTT#FHEM und MQTT]] zu finden.}}

== Define ==
Das MQTT Gateway wird angelegt mit
<code>define <meinMQTT2ClientName> MQTT2_CLIENT <host>:<port></code>

{{Hinweis|Sofern der MQTT-Server mit FHEM über localhost kommunizieren kann, sollte als IP 127.0.0.1 verwendet werden.}}

== Anwendung ==
Danach können entsprechende Client-Devices angelegt werden, in der Regel als [[MQTT2 DEVICE|MQTT2_DEVICE]]. Dabei kann ein physikalisches Device (Sensor oder Aktor), das über mqtt kommuniziert (z.B. ein ESP8266- oder ESP32-basiertes Gerät), ein oder mehrere Devices des Typs ''MQTT2_DEVICE'' entsprechen.

=== autocreate und bridgeRegexp ===
{{Randnotiz|RNTyp=g|RNText=Für weitere bridge-Geräte wird bei Verwendung des MQTT2_CLIENT empfohlen, die betreffenden templates jeweils auf eine Kopie des "Sammeldevices" MQTT2_CLIENT_general_bridge anzuwenden und dabei vorab die CID auf einen anderen Wert festzulegen als die ClientID des MQTT2_CLIENT-Geräts<ref>Dabei empfielt sich der [[Import von Code Snippets|RAW-Editor]], beachten Sie hierzu aber die Hinweise zur Änderung der CID!</ref>! Hat man neue Geräte mit bridgeRegexp-Einträgen erstellt oder die bridgeRegexp-Einträge verändert, kann in der Regel gefahrlos zunächst die readingList am "Sammeldevice" (bzw. der MQTT2_CLIENT_general_bridge) gelöscht werden, so dass dann eingehende Nachrichten auch tatsächlich gegen die bridgeRegexp geprüft werden müssen.}}Möchte man ''autocreate'' verwenden, um automatisiert MQTT2_DEVICE-Geräte anlegen zu lassen, empfiehlt es sich, auf das erste automatisch angelegte Gerät das [[MQTT2-Module - Praxisbeispiele#attrTemplate_2|template]] ''MQTT2_CLIENT_general_bridge'' anzuwenden. Dadurch werden anschließend bestimmte eingehenden MQTT-Messages für eine Anzahl häufig anzutreffender Gerätetypen in separate, automatisch angelegte MQTT2_DEVICE-Geräte umgeleitet<ref>Näheres zur Entstehung der derzeitigen bridgeRegexp des templates ''MQTT2_CLIENT_general_bridge'' sind diesem {{Link2Forum|Topic=98126|LinkText=Forenthread}} zu entnehmen.</ref>.
{{Hinweis|Da hierzu die typischen Topicstrukturen und Benennungen genutzt werden, sollten die MQTT-Einstellungen hinsichtlich des topictrees auf den Geräten auf den jeweiligen defaults belassen werden.}}

Das attrTemplate ''MQTT2_CLIENT_general_bridge'' löscht die readingList des Geräts, auf das es angewendet wird und ergänzt das Device mit der beschriebenen ''bridgeRegexp''. Dies muß nur einmalig erfolgen, für alle weiteren - mittels bridgeRegexp erstellten - Geräte gilt dann - mit o.g. Einschränkungen bei der Erstellung von weiteren ''bridge''-Geräten - das allgemeine Vorgehen für MQTT2_DEVICE, z.B. auch die Festlegung weiterer Geräten mit ''bridgeRegexp''-Attributen wie in den [[MQTT2-Module - Praxisbeispiele|Praxisbeispielen]] beschrieben, dort findet sich auch ein Abschnitt zum Attribut [[MQTT2-Module_-_Praxisbeispiele#bridgeRegexp|bridgeRegexp]] allgemein.

Will man Geräte unterscheiden, die sich nur z.B im ersten Teil der Topic-Struktur unterscheiden, kann man dies durch Anpassung der ''bridgeRegexp'' erreichen oder dadurch, dass man die betreffenden Geräte manuell anlegt. Dabei sollte man jedoch tendenziell sehr restriktive bridgeRegexp-Ausdrücke verwenden<ref>Zum Hintergrund siehe diese {{Link2Forum|Topic=98206|LinkText=Forendiskussion}}</ref>.

=== ignoreRegexp ===
Da ein externer MQTT-Server auch alle ausgehenden Anweisungen wieder an alle Clients zurückliefert, führt dies iVm. ''autocreate'' dazu, dass in vielen Fälle Events doppelt - und überdies in Teilen sachlich falsch - erzeugt werden. Um nur die Rückmeldung des Geräts über den Vollzug der Anweisung auszuwerten und die ausgehenden Informationen zu verwerfen, kann man am Interface ein ''ignoreRegexp'' setzen. Für typische Befehlsstrukturen von Tasmota, Shelly und zigbee2mqtt sowie das Auswerten von - für HomeAssistant gedachten - autodiscovery-Meldungen wäre z.B. folgendes ''ignoreRegexp'' zu verwenden:

<code>attr MQTT2_Mosquitto_Client ignoreRegexp cmnd/[^:"]+:|homeassistant/[^:"]+/config:|shellies/[^:"]+/command:|zigbee2mqtt/[^/]+/set:|milight/0x[0-9a-fA-F]{1,4}/.*/[0-8]:|tasmota/discovery/</code>

{{Hinweis|Dieses Attribut wäre auch an einem ''MQTT2_SERVER'' sinnvollerweise entsprechend zu setzen, wenn über diesen andere (Software-)Client-Systeme angebunden werden, die ebenfalls direkt MQTT-Anweisungen an die anderen Clients senden können sollen. Beispiele wären verteilte Systeme mit MQTT2_CLIENT auf entfernten FHEM-Installationen oder die Verwendung von MQTT-basierten User-Interfaces (NodeRed oä).}}

== Anmerkungen ==
<references />

[[Kategorie:IP Components|IP Komponenten]]
[[Kategorie:Other Components]]
[[Kategorie:Interfaces]]
[[Kategorie:MQTT]]

MQTT2 CLIENT

2022-11-16T21:12:25Z

TomLee: /* Define */

{{Infobox Modul
|ModPurpose=Stellt als Gateway die Verbindung zu einem MQTT-Broker her
|ModType=d
|ModCmdRef=MQTT2_CLIENT
|ModForumArea=MQTT
|ModTechName=10_MQTT2_CLIENT.pm
|ModOwner=rudolfkoenig ({{Link2FU|8|Forum}} / [[Benutzer Diskussion:Rudolfkoenig|Wiki]])}}
Das Modul [[MQTT2_CLIENT]] ermöglicht es, Geräte einzubinden, die über eine MQTT-Schnittstelle verfügen. Es fungiert als [[Interface|Verbindung]] zwischen FHEM und einem externen MQTT Server (z.B. ''mosquitto'') und repräsentiert ein '''''MQTT Gateway'''''. Die durch die Module [[MQTT2_DEVICE]] oder {{Link2CmdRef|Anker=MQTT_GENERIC_BRIDGE|Lang=en|Label=MQTT_GENERIC_BRIDGE}} repräsentierten Client-Geräte sind gesondert anzulegen.

== Voraussetzungen ==
Es muss für jedes MQTT-Gateway ein MQTT-Server eingerichtet und erreichbar sein.
Eine Anleitung zur Einrichtung eines Mosquitto-Brokers finden Sie z.B. im Artikel [[MQTT Einführung]].
{{Hinweis|FHEM selbst kann ebenfalls mit {{Link2CmdRef|Anker=MQTT2_SERVER|Lang=en|Label=MQTT2_SERVER}} als MQTT-Server eingesetzt werden. In diesem Fall ist innerhalb dieser FHEM-Instanz kein MQTT2_CLIENT-Gerät erforderlich. Befindet sich ein MQTT2_SERVER in einer anderen FHEM-Instanz, kann dieser von dort aus mit MQTT2_CLIENT verbunden werden.}}

== Kurzübersicht ==
{{Hinweis|Eine Übersicht über die verschiedenen Möglichkeiten, MQTT in FHEM zu nutzen, ist in [[MQTT#FHEM und MQTT]] zu finden.}}

== Define ==
Das MQTT Gateway wird angelegt mit
<code>define <meinMQTT2ClientName> MQTT2_CLIENT <host>:<port></code>

{{Hinweis|Sofern der MQTT-Server mit FEHM über localhost kommunizieren kann, sollte als IP 127.0.0.1 verwendet werden.}}

== Anwendung ==
Danach können entsprechende Client-Devices angelegt werden, in der Regel als [[MQTT2 DEVICE|MQTT2_DEVICE]]. Dabei kann ein physikalisches Device (Sensor oder Aktor), das über mqtt kommuniziert (z.B. ein ESP8266- oder ESP32-basiertes Gerät), ein oder mehrere Devices des Typs ''MQTT2_DEVICE'' entsprechen.

=== autocreate und bridgeRegexp ===
{{Randnotiz|RNTyp=g|RNText=Für weitere bridge-Geräte wird bei Verwendung des MQTT2_CLIENT empfohlen, die betreffenden templates jeweils auf eine Kopie des "Sammeldevices" MQTT2_CLIENT_general_bridge anzuwenden und dabei vorab die CID auf einen anderen Wert festzulegen als die ClientID des MQTT2_CLIENT-Geräts<ref>Dabei empfielt sich der [[Import von Code Snippets|RAW-Editor]], beachten Sie hierzu aber die Hinweise zur Änderung der CID!</ref>! Hat man neue Geräte mit bridgeRegexp-Einträgen erstellt oder die bridgeRegexp-Einträge verändert, kann in der Regel gefahrlos zunächst die readingList am "Sammeldevice" (bzw. der MQTT2_CLIENT_general_bridge) gelöscht werden, so dass dann eingehende Nachrichten auch tatsächlich gegen die bridgeRegexp geprüft werden müssen.}}Möchte man ''autocreate'' verwenden, um automatisiert MQTT2_DEVICE-Geräte anlegen zu lassen, empfiehlt es sich, auf das erste automatisch angelegte Gerät das [[MQTT2-Module - Praxisbeispiele#attrTemplate_2|template]] ''MQTT2_CLIENT_general_bridge'' anzuwenden. Dadurch werden anschließend bestimmte eingehenden MQTT-Messages für eine Anzahl häufig anzutreffender Gerätetypen in separate, automatisch angelegte MQTT2_DEVICE-Geräte umgeleitet<ref>Näheres zur Entstehung der derzeitigen bridgeRegexp des templates ''MQTT2_CLIENT_general_bridge'' sind diesem {{Link2Forum|Topic=98126|LinkText=Forenthread}} zu entnehmen.</ref>.
{{Hinweis|Da hierzu die typischen Topicstrukturen und Benennungen genutzt werden, sollten die MQTT-Einstellungen hinsichtlich des topictrees auf den Geräten auf den jeweiligen defaults belassen werden.}}

Das attrTemplate ''MQTT2_CLIENT_general_bridge'' löscht die readingList des Geräts, auf das es angewendet wird und ergänzt das Device mit der beschriebenen ''bridgeRegexp''. Dies muß nur einmalig erfolgen, für alle weiteren - mittels bridgeRegexp erstellten - Geräte gilt dann - mit o.g. Einschränkungen bei der Erstellung von weiteren ''bridge''-Geräten - das allgemeine Vorgehen für MQTT2_DEVICE, z.B. auch die Festlegung weiterer Geräten mit ''bridgeRegexp''-Attributen wie in den [[MQTT2-Module - Praxisbeispiele|Praxisbeispielen]] beschrieben, dort findet sich auch ein Abschnitt zum Attribut [[MQTT2-Module_-_Praxisbeispiele#bridgeRegexp|bridgeRegexp]] allgemein.

Will man Geräte unterscheiden, die sich nur z.B im ersten Teil der Topic-Struktur unterscheiden, kann man dies durch Anpassung der ''bridgeRegexp'' erreichen oder dadurch, dass man die betreffenden Geräte manuell anlegt. Dabei sollte man jedoch tendenziell sehr restriktive bridgeRegexp-Ausdrücke verwenden<ref>Zum Hintergrund siehe diese {{Link2Forum|Topic=98206|LinkText=Forendiskussion}}</ref>.

=== ignoreRegexp ===
Da ein externer MQTT-Server auch alle ausgehenden Anweisungen wieder an alle Clients zurückliefert, führt dies iVm. ''autocreate'' dazu, dass in vielen Fälle Events doppelt - und überdies in Teilen sachlich falsch - erzeugt werden. Um nur die Rückmeldung des Geräts über den Vollzug der Anweisung auszuwerten und die ausgehenden Informationen zu verwerfen, kann man am Interface ein ''ignoreRegexp'' setzen. Für typische Befehlsstrukturen von Tasmota, Shelly und zigbee2mqtt sowie das Auswerten von - für HomeAssistant gedachten - autodiscovery-Meldungen wäre z.B. folgendes ''ignoreRegexp'' zu verwenden:

<code>attr MQTT2_Mosquitto_Client ignoreRegexp cmnd/[^:"]+:|homeassistant/[^:"]+/config:|shellies/[^:"]+/command:|zigbee2mqtt/[^/]+/set:|milight/0x[0-9a-fA-F]{1,4}/.*/[0-8]:|tasmota/discovery/</code>

{{Hinweis|Dieses Attribut wäre auch an einem ''MQTT2_SERVER'' sinnvollerweise entsprechend zu setzen, wenn über diesen andere (Software-)Client-Systeme angebunden werden, die ebenfalls direkt MQTT-Anweisungen an die anderen Clients senden können sollen. Beispiele wären verteilte Systeme mit MQTT2_CLIENT auf entfernten FHEM-Installationen oder die Verwendung von MQTT-basierten User-Interfaces (NodeRed oä).}}

== Anmerkungen ==
<references />

[[Kategorie:IP Components|IP Komponenten]]
[[Kategorie:Other Components]]
[[Kategorie:Interfaces]]
[[Kategorie:MQTT]]

MQTT2 CLIENT

2022-11-16T21:04:12Z

TomLee: /* Define */

{{Infobox Modul
|ModPurpose=Stellt als Gateway die Verbindung zu einem MQTT-Broker her
|ModType=d
|ModCmdRef=MQTT2_CLIENT
|ModForumArea=MQTT
|ModTechName=10_MQTT2_CLIENT.pm
|ModOwner=rudolfkoenig ({{Link2FU|8|Forum}} / [[Benutzer Diskussion:Rudolfkoenig|Wiki]])}}
Das Modul [[MQTT2_CLIENT]] ermöglicht es, Geräte einzubinden, die über eine MQTT-Schnittstelle verfügen. Es fungiert als [[Interface|Verbindung]] zwischen FHEM und einem externen MQTT Server (z.B. ''mosquitto'') und repräsentiert ein '''''MQTT Gateway'''''. Die durch die Module [[MQTT2_DEVICE]] oder {{Link2CmdRef|Anker=MQTT_GENERIC_BRIDGE|Lang=en|Label=MQTT_GENERIC_BRIDGE}} repräsentierten Client-Geräte sind gesondert anzulegen.

== Voraussetzungen ==
Es muss für jedes MQTT-Gateway ein MQTT-Server eingerichtet und erreichbar sein.
Eine Anleitung zur Einrichtung eines Mosquitto-Brokers finden Sie z.B. im Artikel [[MQTT Einführung]].
{{Hinweis|FHEM selbst kann ebenfalls mit {{Link2CmdRef|Anker=MQTT2_SERVER|Lang=en|Label=MQTT2_SERVER}} als MQTT-Server eingesetzt werden. In diesem Fall ist innerhalb dieser FHEM-Instanz kein MQTT2_CLIENT-Gerät erforderlich. Befindet sich ein MQTT2_SERVER in einer anderen FHEM-Instanz, kann dieser von dort aus mit MQTT2_CLIENT verbunden werden.}}

== Kurzübersicht ==
{{Hinweis|Eine Übersicht über die verschiedenen Möglichkeiten, MQTT in FHEM zu nutzen, ist in [[MQTT#FHEM und MQTT]] zu finden.}}

== Define ==
Das MQTT Gateway wird angelegt mit
<code>define <''meinMQTT2ClientName>'' MQTT2_CLIENT <host>:<port></code>

{{Hinweis|Sofern der MQTT-Server mit FEHM über localhost kommunizieren kann, sollte als IP 127.0.0.1 verwendet werden.}}

== Anwendung ==
Danach können entsprechende Client-Devices angelegt werden, in der Regel als [[MQTT2 DEVICE|MQTT2_DEVICE]]. Dabei kann ein physikalisches Device (Sensor oder Aktor), das über mqtt kommuniziert (z.B. ein ESP8266- oder ESP32-basiertes Gerät), ein oder mehrere Devices des Typs ''MQTT2_DEVICE'' entsprechen.

=== autocreate und bridgeRegexp ===
{{Randnotiz|RNTyp=g|RNText=Für weitere bridge-Geräte wird bei Verwendung des MQTT2_CLIENT empfohlen, die betreffenden templates jeweils auf eine Kopie des "Sammeldevices" MQTT2_CLIENT_general_bridge anzuwenden und dabei vorab die CID auf einen anderen Wert festzulegen als die ClientID des MQTT2_CLIENT-Geräts<ref>Dabei empfielt sich der [[Import von Code Snippets|RAW-Editor]], beachten Sie hierzu aber die Hinweise zur Änderung der CID!</ref>! Hat man neue Geräte mit bridgeRegexp-Einträgen erstellt oder die bridgeRegexp-Einträge verändert, kann in der Regel gefahrlos zunächst die readingList am "Sammeldevice" (bzw. der MQTT2_CLIENT_general_bridge) gelöscht werden, so dass dann eingehende Nachrichten auch tatsächlich gegen die bridgeRegexp geprüft werden müssen.}}Möchte man ''autocreate'' verwenden, um automatisiert MQTT2_DEVICE-Geräte anlegen zu lassen, empfiehlt es sich, auf das erste automatisch angelegte Gerät das [[MQTT2-Module - Praxisbeispiele#attrTemplate_2|template]] ''MQTT2_CLIENT_general_bridge'' anzuwenden. Dadurch werden anschließend bestimmte eingehenden MQTT-Messages für eine Anzahl häufig anzutreffender Gerätetypen in separate, automatisch angelegte MQTT2_DEVICE-Geräte umgeleitet<ref>Näheres zur Entstehung der derzeitigen bridgeRegexp des templates ''MQTT2_CLIENT_general_bridge'' sind diesem {{Link2Forum|Topic=98126|LinkText=Forenthread}} zu entnehmen.</ref>.
{{Hinweis|Da hierzu die typischen Topicstrukturen und Benennungen genutzt werden, sollten die MQTT-Einstellungen hinsichtlich des topictrees auf den Geräten auf den jeweiligen defaults belassen werden.}}

Das attrTemplate ''MQTT2_CLIENT_general_bridge'' löscht die readingList des Geräts, auf das es angewendet wird und ergänzt das Device mit der beschriebenen ''bridgeRegexp''. Dies muß nur einmalig erfolgen, für alle weiteren - mittels bridgeRegexp erstellten - Geräte gilt dann - mit o.g. Einschränkungen bei der Erstellung von weiteren ''bridge''-Geräten - das allgemeine Vorgehen für MQTT2_DEVICE, z.B. auch die Festlegung weiterer Geräten mit ''bridgeRegexp''-Attributen wie in den [[MQTT2-Module - Praxisbeispiele|Praxisbeispielen]] beschrieben, dort findet sich auch ein Abschnitt zum Attribut [[MQTT2-Module_-_Praxisbeispiele#bridgeRegexp|bridgeRegexp]] allgemein.

Will man Geräte unterscheiden, die sich nur z.B im ersten Teil der Topic-Struktur unterscheiden, kann man dies durch Anpassung der ''bridgeRegexp'' erreichen oder dadurch, dass man die betreffenden Geräte manuell anlegt. Dabei sollte man jedoch tendenziell sehr restriktive bridgeRegexp-Ausdrücke verwenden<ref>Zum Hintergrund siehe diese {{Link2Forum|Topic=98206|LinkText=Forendiskussion}}</ref>.

=== ignoreRegexp ===
Da ein externer MQTT-Server auch alle ausgehenden Anweisungen wieder an alle Clients zurückliefert, führt dies iVm. ''autocreate'' dazu, dass in vielen Fälle Events doppelt - und überdies in Teilen sachlich falsch - erzeugt werden. Um nur die Rückmeldung des Geräts über den Vollzug der Anweisung auszuwerten und die ausgehenden Informationen zu verwerfen, kann man am Interface ein ''ignoreRegexp'' setzen. Für typische Befehlsstrukturen von Tasmota, Shelly und zigbee2mqtt sowie das Auswerten von - für HomeAssistant gedachten - autodiscovery-Meldungen wäre z.B. folgendes ''ignoreRegexp'' zu verwenden:

<code>attr MQTT2_Mosquitto_Client ignoreRegexp cmnd/[^:"]+:|homeassistant/[^:"]+/config:|shellies/[^:"]+/command:|zigbee2mqtt/[^/]+/set:|milight/0x[0-9a-fA-F]{1,4}/.*/[0-8]:|tasmota/discovery/</code>

{{Hinweis|Dieses Attribut wäre auch an einem ''MQTT2_SERVER'' sinnvollerweise entsprechend zu setzen, wenn über diesen andere (Software-)Client-Systeme angebunden werden, die ebenfalls direkt MQTT-Anweisungen an die anderen Clients senden können sollen. Beispiele wären verteilte Systeme mit MQTT2_CLIENT auf entfernten FHEM-Installationen oder die Verwendung von MQTT-basierten User-Interfaces (NodeRed oä).}}

== Anmerkungen ==
<references />

[[Kategorie:IP Components|IP Komponenten]]
[[Kategorie:Other Components]]
[[Kategorie:Interfaces]]
[[Kategorie:MQTT]]

Notify

2022-04-10T14:11:12Z

TomLee: Nicht nötige Klammern entfernt

{{SEITENTITEL:notify}}
{{Infobox Modul
|ModPurpose=Ausführung von Anweisung(en) als Reaktion auf Ereignisse
|ModType=h
|ModCmdRef=notify
|ModForumArea=Automatisierung
|ModTechName=91_notify.pm
|ModOwner=rudolfkoenig ({{Link2FU|8|Forum}} / [[Benutzer Diskussion:Rudolfkoenig|Wiki]])
}}

== Einführung ==
{{Hinweis|Weitere grundlegende Informationen/Beispiele zu notify enthält [http://fhem.de/Heimautomatisierung-mit-fhem.pdf Heimautomatisierung mit FHEM]}}
Das Hilfsmodul notify dient dazu [[Ereignis|Ereignisse]] über ein Suchmuster zu erkennen und bei einem Treffer eine Aktion auszulösen. Mit ''notify'' und anderen [[Eventhandler|Eventhandlern]] <ref>hierzu gehören u.a. auch [[DOIF]], [[THRESHOLD]] und [[watchdog]]</ref> ist es möglich, Logikfunktionen im FHEM abzubilden.

'''Beispiele:'''
* Wird das Licht in der Küche eingeschaltet, soll FHEM dort auch das Radio einschalten.
* Bei Druck auf einen Taster soll die Umwälzpumpe für das Warmwasser eingeschaltet werden.
* Erweiterte Möglichkeiten: Aber nur, wenn das Radio aus ist bzw. die Temperatur im Rücklauf des Warmwassers unterhalb einer bestimmten Schwelle liegt<ref>vgl. hierzu z.B. {{Link2CmdRef|Anker=devspec|Label=FILTER}} und [[if-condition]]</ref>.

== Syntax ==

define <name> notify <Suchmuster> <command>

Das ''[[Regulärer Ausdruck|Suchmuster]]'' (häufig als Regexp = regular expression = regulärer Ausdruck bezeichnet) ist sehr wichtig: Es ist entweder der Name des auslösenden ("triggernden") Gerätes oder die Kombination aus Gerät und auslösendem Ereignis (Event) <code>Gerätename:Event</code>. Die Events kann man dem [[Event_monitor|Event-Monitor]] entnehmen. Wenn dort z.B. <code>Rollo1</code> steht, dann reagiert ''notify'' auf <code>Rollo1 on</code> und <code>Rollo1 off</code> usw.

Wenn man mehrere Suchmuster kombinieren möchte, kann man diese in Klammer schreiben, als Trenner wird dann Pipe (|) genutzt: <code>(Rollo1|Rollo2|Steckdose5)</code>.

'''Auch die Verwendung von Platzhaltern ist möglich''':
* <code>Rollo.</code> → das notify reagiert auf alles was mit Rollo und '''einem''' weiteren beliebigen Zeichen anfängt. Also auf Rollo1 wie auch auf RolloG, aber nicht auf Rollo_wischundweg
* <code>Rollo.*</code> → notify reagiert auf alles das mit Rollo beginnt
* <code>.*isch</code> → auf alles das mit isch aufhört (Tisch, Fisch)
* <code>Schalter(1|2|3)</code> → hört auf Schalter1, Schalter2 und Schalter3
* <code>dimmer:pct:.(100|7[6-9]|[89][0-9])</code> → reagiert, wenn pct einen Wert über 75 annimmt.

Suchmuster/Regex kann man im Internet beispielsweise auf [http://regexpal.com/| http://regexpal.com/] testen.

Es gibt seit Juli 2020 eine Perlfunktion notifyRegexpCheck zum Testen, wie FHEM über das Suchmuster "denkt" - siehe {{Link2Forum|Topic=111938|Message=1074202|LinkText=diesen Beitrag}} im Forum.

{{Hinweis|Das '''Suchmuster''' wird notify-intern um das Zeichen ^ (beginnt mit) und das Zeichen $ (endet mit) ergänzt<ref>Der Eventhandler [[DOIF]] verwendet die in Perl übliche Syntax für reguläre Ausdrücke als DOIF-Suchmuster.</ref>.

Deshalb darf das Suchmuster nicht mit einem üblichen [[Regulärer Ausdruck|'''Regulären Ausdruck''']], wie er in Perl<ref>https://perldoc.perl.org/perlre.html</ref> verwendet wird, gleichgesetzt werden, da die Ergänzung zu einem grundsätzlich unterschiedlichen Verhalten führt, siehe nachstehendes Beispiel.}}

'''Beispiel für das unterschiedliche Verhalten von ''Suchmuster'' und ''regulären Ausdruck'''''

Für einen '''regulären Audruck''' gilt: Wenn der reguläre Ausdruck ''lampe'' ist und das [[Ereignis]] ''tischlampe'' dann passen ''tischlampe'' und ''lampe'' zueinander.

Für das '''Suchmuster''' gilt: Wenn das Suchmuster ''lampe'' ist und das [[Ereignis]] ''tischlampe'' dann passen ''tischlampe'' und ''lampe'' '''nicht''' zueinander, weil das Suchmuster zu ^lampe$ ergänzt wird und damit exakt nur auf ''lampe'' matcht (passt).

'''Variablen Zuordnung zum Event'''

'''Beispiel 1'''

2020-01-21 22:40:39 HUEDevice VibrationTest1 battery: 88
{| class="wikitable"
|-
! !!$NAME !! colspan="2" |$EVENT
|-
| ||||$EVTPART0 ||$EVTPART1
|-
|2020-01-21 22:40:39 HUEDevice|| VibrationTest1|| battery:|| 88
|}

'''Beispiel 2'''
2021-05-09 19:11:43 FB_CALLMONITOR cm_example external_name: Graf Herzog von und zu ...
{| class="wikitable"
|-
! !!$NAME !! colspan="7" |$EVENT
|-
| ||||$EVTPART0 ||$EVTPART1 || $EVTPART2|| $EVTPART3 || $EVTPART4|| $EVTPART5|| ...
|-
|2021-05-09 19:11:43 FB_CALLMONITOR|| cm_example|| external_name:|| Graf|| Herzog|| von|| und|| zu|| ...
|}

== FHEMWEB-unterstütztes Anlegen eines notify ==
{{Hinweis|Die Erstellung eines notify und insbesondere die korrekte Angabe des Suchmusters (Regex) führt gerade bei Einsteigern immer wieder zu Schwierigkeiten. Zur Fehlerminimierung empfiehlt es sich zum einen, die [[Konfiguration]] nicht direkt zu bearbeiten, sondern die "Befehl-Eingabezeile", die "Objektdetails" oder den [[Import von Code Snippets|Import von RAW-Definitionen]] zur Bearbeitung zu nutzen.}}

=== Event Monitor ===
Die komfortabelste Möglichkeit, die häufigsten Event-Handler zu erstellen, bietet der [[Event monitor|Event-Monitor]]. Die Vorgehensweis ist in dem zugehörigen Artikel dargestellt.

=== Regexp wizard ===
Zudem enthält FHEM einen Regexp wizard mit dem Regex anhand der in FHEM vorhandenen Devices und deren Events aus einer Auswahlbox selektiert werden können. Voraussetzungen sind:
* Aktivierung des Hilfsmoduls [[eventTypes]] (bei allen Neuinstallationen Standard)
* das gesuchte Ereignis (Event) ist nach Aktivierung des Hilfsmoduls bereits mindestens einmal eingetreten

Schrittweise Darstellung der Nutzung des Regexp wizard zur Anlage eines "notify":

In das [[Konfiguration#Befehl-Eingabefeld|Befehls-Eingabefeld]] eingeben und mit {{Taste|Enter}} bestätigen:
define ntest notify a b
Als Beispiel wird ein notify mit <name> "ntest" angelegt. "a" und "b" sind beliebige Platzhalter für <Suchmuster> und <Command>, die bei der weiteren Bearbeitung mit dem endgültigen Werten ersetzt werden.
Der Regexp wizard öffnet sich:
[[Datei:Regexp wizard1.JPG|400px|thumb|center]]
Nun in der Auswahlbox das auslösende Event (Ereignis) auswählen; zunächst das Device und dann das gewünschte Regex. Hier soll das notify bei jeder Veränderung der Temperatur (temperature.*) des Device BTHR918N reagieren. Abschließend mit einem Mausklick auf {{Taste|set}} bestätigen. Wählt man mehrere Regex in dieser Weise aus, so wird das "notify" bei Eintritt jedes dieser Events ausgeführt:
[[Datei:Regexp wizard2.JPG|400px|thumb|center]]
Anschließend den Platzhalter "a" mit Klick auf den Link "removeRegexpPart" löschen:
[[Datei:Regexp wizard3.JPG|400px|thumb|center]]
Den Link "DEF" anklicken, damit sich der DEF-Editor öffnet:
[[Datei:Regexp wizard4.JPG|400px|thumb|center]]
Jetzt den auszuführenden Befehl im "DEF"-Bereich durch Überschreiben des Platzhalters "b" eintragen und mit Klick auf {{Taste|modify ntest}} abschließen:
[[Datei:Regexp wizard5.JPG|400px|thumb|center]]
Das fertige und sofort aktive "notify" sieht abschließend folgendermaßen aus:
[[Datei:Regexp wizard6.JPG|400px|thumb|center]]
Am Schluss das Speichern über {{Taste|Save config}} nicht vergessen.

== Mein notify geht nicht - wie kann ich mir selbst helfen: Debugging ==
Funktioniert ein notify nicht wie gewünscht, kann es nur zwei Hauptursachen haben:
* Entweder das Suchmuster paßt nicht zum gewünschten Auslöser (FHEM Device), und/oder
* die Anweisung enthält einen Fehler.
Sollte kein Fehler im Logfile auftauchen aber das notify ausgelöst werden, stimmt meist der Übertragungsweg zum Zieldevice nicht.
Der STATE des notify zeigt normalerweise mit Datum/Uhrzeit die letzte Auslösung an.

Beim Debuggen sollte man daher beide Elemente getrennt untersuchen. Hier ein Beispiel welches nicht wie gewünscht funktioniert:
<syntaxhighlight lang="perl"> define n_test notify n_test:muster Ausführungsteil</syntaxhighlight>
Zum debuggen benötigen wir
* den [[Event monitor]]
* das [https://fhem.de/commandref.html#trigger trigger-Kommando] - kann man jederzeit verwenden um das Suchmuster als Event unabhängig vom Auslöser zu erzeugen.
* die FHEM Kommandozeile
* den [[DEF-Editor]]
* eventuell einen Texteditor um Codeblöcke zwischen zu lagern und Notizen zu machen.

Das Suchmuster im Beispiel notify triggert auf sich selbst, es soll auf jeden Event mit dem Inhalt '''muster''' ausgelöst werden, Beispiel:
2018-07-14 14:31:03 notify n_test muster bild

=== Suchmuster ===
Sollte das notify nicht funktionieren:
* keine Reaktion wie gewünscht
* keine Fehlermeldung in der Weboberfläche beim Anlegen, keine Fehlermeldung im Logfile
* STATE ist unverändert auf active oder einem altem Datum/Uhrzeit
liegt der Fehler mit Sicherheit im Suchmuster. Man hat die Chance das Suchmuster mit dem trigger Befehl zu erzeugen und zu schauen ob die Anweisung ausgeführt wird. Dabei ist zu beachten: Der erste ":" im Suchmuster ist zusätzlich zwischen Gerät und Event als Trennung. Jeder weiter : ist, wenn vorhanden, Bestandteil des Events! Siehe dazu den Abschnitt [https://fhem.de/commandref_DE.html#notify Hinweise in der commandref]
*Im Beispiel: Event: n_test muster -> Suchmuster n_test:muster
Um aus dem [[Event]] ein passendes Suchmuster zu erzeugen kann der [[Event monitor|Event-Monitor]] direkt verwendet werden. Man kann ein neues notify erzeugen oder ein Bestehendes modifizieren lassen.

Unser Regex im Beispiel ist zu spezifisch, es triggert nur exakt auf '''muster'''. Dieser Trigger erzeugt den folgenden Eintrag im Eventmonitor, entspricht exakt dem Suchmuster und löst das notify aus:
trigger n_test muster
2018-07-13 11:52:08 notify n_test muster
Das Suchmuster für unsere Anforderung muss in <code>n_test:muster.*</code> geändert werden, damit jeder Event der mit muster beginnt das notify auslöst.
Der . im Regex steht für jedes beliebige Zeichen und der * für eine beliebige Anzahl des Zeichens davor: also beliebig viele beliebige Zeichen nach muster.

Das Suchmuster wird häufig in ein komplizierteres Regex umgewandelt um im notify mehrere Aktionen zu starten. Das eigene Regex kann z.B. mit http://regexpal.com/ oder https://regex101.com/ getestet werden.

Funktioniert der Auslöser, das notify tut aber noch nicht was es soll, müssen wir die Anweisung untersuchen. In unserem korrigierten Beispiel
<syntaxhighlight lang="perl"> defmod n_test notify n_test:muster.* Ausführungsteil</syntaxhighlight>
folgt beim Kommando <code>trigger n_test muster bild</code> ein Eintrag im Log:
2018.07.13 11:47:57 3: n_test return value: Unknown command Ausführungsteil, try help.
Das notify wurde zwar getriggert aber die Anweisung war nicht ausführbar.

Ein richtiges Suchmuster und eine fehlerhafte Anweisung wird also normalerweise einen Fehlereintrag im Logfile erzeugen!

=== Spezialfall: notify löst zwar aus - aber zu oft ===
In dem Fall ist das Suchmuster (regExp) zu unscharf oder das triggernde Gerät löst das Event zu oft aus. Das regExp sollte so genau wie möglich konstruiert werden, device:.* ist eine einfache aber oft keine gute Wahl!

Im Device, welches den Event auslöst, kann mit den Attributen event-on-.* die Häufigkeit gesteuert werden. Insbesondere ist hier das regExp .* eine Art Standardwahl um aufeinanderfolgende gleichartige Events zu verhindern.
:<code>attr device event-on-change-reading .*</code>
'''Achtung''': durch falsche Angaben kann man Events ganz leicht völlig verhindern!

Siehe auch [[event-on-change-reading]]

=== Anweisung ===
Wird das notify getriggert oder will man ganz schnell mal ein notify testen, kann man die Anweisung durch folgenden Code ersetzen, man öffnet also einfach nur die DEF, kopiert den ursprünglichen Inhalt an einen sicheren Ort und ersetzt die Anweisung durch eine der beiden Zeilen. Die erste Zeile kann man auch einfach mal in der Kommandozeile testen:
<syntaxhighlight lang="perl">{Log 1, "Das Notify n_test hat ausgeloest."}
{Log 1, "Das Device $NAME hat ausgeloest, der Event sah so aus: $EVENT"}</syntaxhighlight>
Wird das notify ausgelöst, muss anschließend im Logfile ein Eintrag zu finden sein:
2018.07.13 10:28:57 1: Das Notify n_test hat ausgeloest, der Event sah so aus: muster
Unsere Anweisung <code>Ausführungsteil</code> liefert in der Kommandozeile selbst einen Fehler:
<code>Unknown command Ausführungsteil, try help.</code>
Ein Versuch mit geschweiften Klammern <code>{Ausführungsteil}</code> liefert wieder einen Fehler:
<code>Unrecognized character \xC3; marked by <-- HERE after {Ausf<-- HERE near column 6 at (eval 5977) line 1.</code>
Diese Variante <code>{"Ausführungsteil"}</code> liefert den String Ausführungsteil ohne Fehler: Das notify arbeitet fehler- aber sinnfrei.
Der fertige Code:
defmod n_test notify n_test:muster.* {"Ausführungsteil"}

Man kann die Anweisung, normalerweise so wie sie ist, in der FHEM Kommandozeile testen. Sind im Perl Code (in geschweiften Klammern) im DEF Editor Semikolon enthalten muss man diese für den Test in der Kommandozeile (oder Raw Def) verdoppeln.
Laufzeitabhängige Variablen sind in der Kommandozeile meist nicht verfügbar, diese sollte man für den Test einfach durch passende Inhalte austauschen. So kann man die komfortable Variante (loggt den Namen und das komplette Event) nicht in der Kommandozeile ausführen.

Funktioniert ein FHEM Befehl in der Kommandozeile nicht (z.B. Lampe geht nicht an) kann es im notify auch nicht funktionieren, dann muss die Fehlersuche an anderer Stelle fortgeführt werden.

Komplexeren Code im Ausführungsteil sollte man beim Testen in Teilabschnitte aufteilen, von der Laufzeit abhängige Variable ($NAME, $EVENT, $EVTPART) durch Strings ("TestWort") ersetzen, die Teilabschnitte separat testen und anschließend schrittweise wieder komplettieren.

== Beispiele ==
{{Hinweis|Für die nachfolgenden Beispiele wurden einige unterschiedliche Technologien verwendet. Sie können aber recht einfach auf alle anderen Systeme übertragen werden, dabei sollte ggf. darauf geachtet werden, dass sich Schaltbefehle und Events teilweise je nach konkret eingesetzter Technologie unterscheiden können. Dann ist ggf. eine Erweiterung, z.B. durch eine [[if-condition|if-Abfrage]] erforderlich.}}

=== Schalter entprellen ===
Will man ein notify innerhalb eines bestimmten Zeitraumes nur einmal auslösen lassen, auch wenn er in diesem Zeitraum mehrfach getriggered werden sollte, so bietet sich das Attribut disabledAfterTrigger an,
attr <notify_device> disabledAfterTrigger <Anzahl Sekunden>
In dem Zeitraum wird dann nur einmal (beim ersten Mal) der Befehl ausgelöst, auch wenn mehrfach getriggered wurde. Der Zeitraum kann Bruchteile von Sekunden umfassen.

=== Etwas schalten, wenn ein anderes Gerät geschaltet wird ===

==== Vorbedingungen ====
Dieses Beispiel verwendet eine einfache InterTechno-kompatible Funksteckdose für das Radio und einen HM-Aktor für das Licht:

define RadioKueche IT 000000FFFF 0F F0
define LichtKueche CUL_HM 3A37D6
Beachte: beide kennen als Event bzw. Schaltbefehle ''on'' und ''off''.

==== notify Befehl ====
define LichtamRadioan notify LichtKueche set RadioKueche $EVENT
oder alternativ:
define LichtamRadioan notify LichtKueche { fhem "set RadioKueche $EVENT" }

==== Erklärung ====
* Der Name des ''notify'' "LichtamRadioan" kann frei gewählt werden, er dient nur dazu, das notify in FHEM eindeutig zu identifizieren.
* "$EVENT" ist ein Platzhalter für den Zustand vom Pattern. $EVENT enthält ein "off" wenn das LichtKueche aus- und ein "on" wenn das Licht eingeschaltet wird.
* "{ <perlcode> }" alles was zwischen {} steht ist Perl code. Perl kennt das Schlüsselwort fhem. Das Schlüsselwort FHEM dient dazu, FHEM Befehle auszuführen. Es wird also der FHEM Befehl "set RadioKueche on/off" ausgeführt. on oder off ist abhängig vom Pattern. Der eigentliche FHEM Befehl muss in " " stehen.
* Wann ist ein Wechsel auf die Perl-Ebene erforderlich?
** einfache FHEM-Befehle sollten in der Regel direkt verwendet werden, dies ist ressourcenschonender.
** Immer dann, wenn dies nicht möglich ist, weil z.B. komplexerer Code ausgeführt werden soll, (blockierende) Prozesse ausgelagert werden sollten oder Systembefehle ausgeführt werden, ist es günstiger, auf die Perl-Ebene zu wechseln <ref>In diesem {{Link2Forum|Topic=88398|Message=808685|LinkText=Forenbeitrag}} wird z.B. erläutert, wie man nichtblockierend externe Scripte aufrufen kann, die dann ihre Ergebnisse wieder an FHEM übergeben.</ref>.

=== Einschalten von mehreren Geräten/Lampen, wenn das Licht eingeschaltet wird ===
Dieses Beispiel verwendet einen HM-Aktor für das Licht sowie zwei Milight-Birnen, die einzeln geschaltet werden sollen<ref>Dies ist ausdrücklich keine Empfehlung für diese Technologie und der Module</ref> in den Stehlampen:

==== Vorbedingungen ====
FHEM:
define LichtWZ CUL_HM 3A37D8
define Stehlampe1 MilightDevice RGBW Milight_Wohnzimmer 5
define Stehlampe2 MilightDevice RGBW Milight_Wohnzimmer 6

==== notify Befehl ====
define SteckdoseWZein notify LichtWZ set Stehlampe1,Stehlampe2 $EVENT
oder ''in Perl''
define SteckdoseWZein notify LichtWZ { fhem "set Stehlampe1 $EVENT;;set Stehlampe2 $EVENT " }
==== Erklärung ====
Wenn das LichtWZ eingeschaltet wird, dann werden auch die Stehlampen (1 und 2) eingeschaltet.

=== Einfache ODER Funktion ===
Eine einfache ODER Funktion kann sehr einfach realisiert werden

==== Vorbereitung ====
KNX:
* 3x GAs der abzufragende Werte (0/0/40 0/0/41 0/0/42)

FHEM:
define Licht1 CUL_HM 3A37D8
define Licht2 CUL_HM 1B7EC3
define Stehlampe MilightDevice RGBW Milight_Wohnzimmer 7

==== notify Befehl ====
define SteckdoseWZein notify (Licht1|Licht2) set Stehlampe $EVENT
oder
define SteckdoseWZein notify (Licht.) set Stehlampe $EVENT

==== Erklärung ====
Die Werte in der Klammer (wichtig ist das »|«) sind die Rückgabewerte. Alternativ kann in diesem Beispiel auch »Licht.« (zu beachten ist der Punkt) geschrieben werden. Der Punkt ist ein Platzhalter für (genau) ein beliebiges Zeichen.

Danach folgt der set Befehl.
Wenn also das Licht1 oder Licht2 den Wert "on" hat, dann hat auch die Steckdose den Wert "on"

Alternative: [[structure]]

=== Einfache UND Funktion ===
Ob man dieses Konstrukt noch als einfach bezeichnen kann, wage ich mal zu bezweifeln. In FHEM fehlen Loggingfunktionen, die man alle selber mit Perl Code erstellen kann (Danke an MAZ).
Dadurch ist FHEM zwar mächtig, wird aber für viele sehr kompliziert.

In diesem Beispiel soll - wenn drei Rollos geschlossen sind - am Taster eine LED eingeschaltet werden.

==== Vorbereitung ====
KNX:
* 3x GDs für die Rückgabewert Rollo geschlossen == 1 (0/0/50 0/0/51 0/0/52)
* GD LED am Lichtschalter (0/0/106)

FHEM:
define R1ZU KNX 0/0/50:dpt1.009
attr R1ZU dummy 1
define R2ZU KNX 0/0/51:dpt1.009
attr R2ZU dummy 1
define R3ZU KNX 0/0/52:dpt1.009
attr R3ZU dummy 1
define LEDalleRolloZu KNX 0/0/106:dpt1
Durch das Attribut dummy werden keine Schaltfunktion angeboten. Es kann nur Werte anzeigen.

==== notify Befehl ====
define nt.allerolloszu notify (R1ZU|R2ZU|R3ZU) {\
my $r1 = Value("R1ZU");;\
my $r2 = Value("R2ZU");;\
my $r3 = Value("R3ZU");;\
if ($r1 eq "on" && $r2 eq "on" && $r3 eq "on") {\
fhem("set LEDalleRolloZu on");;\
} else {\
fhem("set LEDalleRolloZu off");;\
}\
}

==== Erklärung ====
Es werden die drei Rückgabewerte R1ZU, R2ZU und R3ZU ausgewertet. Danach folgt Perl Code, deswegen beginnt das ganze mit einer { und endet mit }

my $r1 => Variable $r1 definieren
= Value("R1ZU");; ==> weist den Rückgabewert (on oder off) von R1ZU der Variable $r1 zu

Der doppelte ;; ist ein FHEM Thema. Eigentlich würde für Perl ein ; reichen. Aber FHEM nutzt selbst das ; und daher wird ein ;; benötigt. Mit den ersten drei my Zeilen werden die Rückgabewerte den Variablen zugewiesen.

Danach erfolgt ein normales "if then else" Konstrukt. Die Zeile »($r1 eq "on" && $r2 eq "on" && $r3 eq "on")« kann man so lesen: Wenn $r1 den Wert "on" und (&&) $r2 den Wert "on" und $r3 den Wert "on" dann schalte die LEDalleRolloZu ein {fhem("set LEDalleRolloZu on")}
ansonsten else schalte die LED aus. {fhem("set LEDalleRolloZu off")

Alternative: [[structure]]

=== Zeitverzögert schalten ===
{| class="wikitable"
| '''Aufgabe:''' || Zeitverzögert schalten
|-
| '''Beschreibung:''' || Mit einem Notify zeitverzögert eine Aktion auslösen.
|-
| '''Vorbereitung:''' || Gerät "Lampe" ist definiert und es gibt eine Situation, die ein Ereignis "Fernbedienung:.*" generiert.
|-
| '''Befehl:''' || <code>define ntfy1 notify Fernbedienung:.* sleep 7.5;; set Lampe $EVENT</code>
|-
| '''Erläuterungen:''' || Bei Eintreten eines Ereignisses "Fernbedienung*" wird nach einer Pause von siebeneinhalb Sekunden der Befehl <set Lampe ??> ausgeführt, wobei der eigentliche Befehl aus dem auslösenden Ereignis übernommen wird.
:''Quelle: {{Link2Forum|Topic=17161|LinkText=FHEM Forum}}''
|}

=== Eine PV-Anlage (Solarstrom) zur Steuerung der Rollos nutzen (optional Zeit und Datums abhängig) ===
Hier ein kleines Beispiel, wie man mit Hilfe einer PV-Anlage die Sonneneinstrahlung auf der Südseite ermittelt und dies zur Rolladensteuerung nutzt.
Optional: Die Funktion soll allerdings nur zwischen 9:30 und 17:00 stattfinden. (zweites Beispiel)
Optional: Die Funktion soll nur zwischen dem 6. und 9. Monat funktioneren. (drittes Beispiel)

==== Vorbereitung ====
PV Anlage mit SolarView abfragen.
Per Hand ermitteln, ab wieviel erzeugtem Strom es sinnvoll ist die Rollos zu schließen.

==== notify Syntax ====
FHEM:

define sv SolarView solarview 15000 wr1 wr2 wr3 wr4 <----vier Wechselrichter
attr sv event-on-change-reading currentPower

define nt.sonnenlichtpersolar notify sv:currentPower.* { \
if ($EVTPART1 < 3000 ) {\
fhem('set Flur1 Auf')\
}else {\
if ($EVTPART1 > 5000 ) {\
fhem('set Flur1 Ab')\
} \
}\
}

Optional 1: Zeitabhängig (Code gehört in die DEF)
<syntaxhighlight lang="perl">
sv:currentPower.* {
my $hm = sprintf("%02d:%02d", $hour, $min);
if ( $hm gt "09:30" && $hm lt "17:00") {
if ($EVTPART1 < 5000 ) {
fhem('set Flur1 Auf')
}else {
if ($EVTPART1 > 8000 ) {
fhem('set Flur1 Ab')
}
}
}
}
</syntaxhighlight>
Optional 2: Zeit und Datum (Code gehört in die DEF)
<syntaxhighlight lang="perl">
sv:currentPower.* {
my $hm = sprintf("%02d:%02d", $hour, $min);
if ($month >= 6 && $month <= 9) {
if ( $hm gt "09:30" && $hm lt "17:00") {
if ($EVTPART1 < 5000 ) {
fhem('set Flur1,RBUERO1,RBUERO2 Auf');
}else {
if ($EVTPART1 > 8000 ) {
fhem('set Flur1,Flur2,RBUERO1,RBUERO2 Ab');
}
}
}
}
}
</syntaxhighlight>

==== Erklärung ====
* Das define wird in der Kommandozeile im Webbrowser eingegeben.
* Anschließend wird im Webbrowser die DEF bearbeitet, das erspart uns Probleme mit Perl
* define sv SolarView ... <==== ist die Schnittstelle vom SolarView
* define nt.sonnenlichtpersolar notify (sv:currentPower.*) { <==== hier wird ein notify angelegt, der auf das "define sv" Wert "currentPower.*" (.* ist irgendwas) reagiert
if ($EVTPART1 < 3000 ) {
fhem('set Flur1 Auf');
}else {
if ($EVTPART1 > 5000 ) {
fhem('set Flur1 Ab');
}
}
}
Diese if-Funktion wertet den Rückgabewert von currentPower aus. Hierbei muss man wissen, dass $EVTPART1 das Split-Ergebnis vom Rückgabewert ist

Beispiel: Der Rückgabewert (wie im Beispiel) ist "currentPower: 6000".
Jetzt steht im "$EVTPART0 == currentPower:" und im "$EVTPART1 == 6000"
Das bedeutet, dass man sich nicht selbst den richtigen split (Perl Befehl) Aufruf ausdenken muss, dies übernimmt vielmehr FHEM.

Ergebnis:
Das Rollo wird abhängig von der erzeugten IST_Strommenge auf und zu gefahren.
Damit dies nicht dauernd hin und her pendelt, wurde der Auf Wert sehr klein und den Ab Wert sehr groß gewählt.

'''Optional 1:''' Der Block "my $hm = sprintf("%02d:%02d", $hour, $min);" erzeugt die String-Variable $hm mit dem Inhalt $hour:$min. %02d begrenzt die Ausgabe auf zwei Stellen.
Danach wird mit "if ( $hm gt "09:30" && $hm lt "17:00")" mit stringvergleichenden Operatoren geprüft, ob die Uhrzeit zwischen 9:30 und 17:00 liegt (lt = kleiner als; gt = größer als). Es wäre auch ein le und ge möglich: le = kleiner/gleich als, ge = größer/gleich als.

'''Optional 2:'''if( $month >= 6 && $month <= 9) {

Hier wird die numerische FHEM-Standard-Variable $month (Monat) auf größer/gleich bzw kleiner/gleich mit den binären Operatoren überprüft.
Die Funktion arbeitet also nur zwischen dem 6. und dem 9. Monat und dann auch nur zwischen 9:31 und 16:59.

=== Status eines Kippfensters mit 2 Fensterkontakten abbilden ===

==== Vorbereitung ====
Es ist je ein Fensterkontakt der ''open'' oder ''closed'' meldet, oben und unten am Fenster angebracht.
Die Namen der beiden FHEM-Devices sind ''fensterKontaktOben'' und ''fensterKontaktUnten''.

==== notify Syntax ====
FHEM:
define statusFenster notify fensterKontakt(Oben|Unten):(open|closed) {\
if ( ReadingsVal('fensterKontaktOben', 'state', 'undef') eq 'open' && ReadingsVal('fensterKontaktUnten', 'state', 'undef') eq 'open')\
{ fhem 'set Terrassentuer open' }\
if ( ReadingsVal('fensterKontaktOben', 'state', 'undef') eq 'closed' && ReadingsVal('fensterKontaktUnten', 'state', 'undef') eq 'closed')\
{ fhem 'set Terrassentuer closed' }\
if ( ReadingsVal('fensterKontaktOben', 'state', 'undef') eq 'open' && ReadingsVal('fensterKontaktUnten', 'state', 'undef') eq 'closed')\
{ fhem 'set Terrassentuer tilted' }\
if ( ReadingsVal('fensterKontaktOben', 'state', 'undef') eq 'closed' && ReadingsVal('fensterKontaktUnten', 'state', 'undef') eq 'open')\
{ fhem 'set Terrassentuer undef' }\
}

== Weitere Hinweise ==
* Entsprechend zu $EVENT gibt es auch noch $NAME und $TYPE. $NAME und $TYPE enthalten den Namen bzw. Typ des Ereignis auslösenden Gerätes.
* Wird der Perl-Code in einem <code>notify</code> immer länger, lagere den Code wegen der Übersichtlichkeit in eine eigene Programmdatei aus, wie in [[99_myUtils anlegen]] beschrieben.
* Achtung! Wenn man das Skript für den notify-Befehl über mehrere Zeilen schreibt, muss man anscheinend darauf achten, dass keine abschließende Leerzeile mitgespeichert wird. Sonst wird der notify-Befehl ignoriert.
* Dieser {{Link2Forum|Topic=38520|Message=307325}} enthält Vorschläge zur Vorgehensweise bei der Erstellung von komplexen ''notify'' Definitionen bzw. bei deren Fehlerbehebung.

== Weiterführende Links ==
* [[Escapen in Perlbefehlen]]
* [[Klammerebenen]]
* Forenbeitrag zum Thema {{Link2Forum|Topic=115414|LinkText=Optimierung des Suchmusters - NOTIFYDEV}}

== Hinweise ==
<references />

[[Kategorie:HOWTOS]]
[[Kategorie:Hilfsmodul]]

Zeitangaben, rechnen mit

2021-09-07T14:43:35Z

TomLee:

Mit leicht lesbaren Zeitangaben, wie ''07:30'', ''23.05.2017, 09:20'' usw. kann in FHEM nicht ohne Weiteres gerechnet werden, da es sich um Zeichenketten handelt und nicht um Zahlen.

== Verfahren zum Rechnen mit Zeitangaben, die als Zeichenkette vorliegen ==
Die Berechnung erfolgt in Perl. Das Verfahren besteht aus drei Schritten:
* Umwandeln der Zeichenketten in eine Zahl, z.B. Sekunden.
* Berechen einer Zeit als Zahl.
* Umwandeln der Zahl in eine Zeichenkette (Formatierung)

=== Umwandeln eine Zeichenkette in eine Zahl ===
{{Randnotiz|RNTyp=Info|RNText= Hinweis!
* Die von <code>timelocal</code> zurückgegebene Monatsangabe hat die Ganzzahlwerte 0 bis 11 für Januar bis Dezember.}}
Hier hängt das Verfahren von der Struktur der Zeichenkette ab.

Perl und FHEM stellen Funktionen zur Umwandlung bereit.
* <code>time</code> liefert die aktuelle Zeit in Sekunden <ref>http://perldoc.perl.org/functions/time.html</ref>
* <code>time_str2num("YYYY-MM-DD HH:MM:SS")</code> wandelt einen FHEM-Zeitstempel in Sekunden um <ref>{{Link2CmdRef|Lang=de|Anker=perl}}</ref>
* <code>timelocal(<Sekunden>, <Minuten>, <Stunden>, <Tag des Monats>, <Monat>, <Jahr>)</code> wandelt einen Satz von Zeitelementen (Sekunden, Minuten, Stunden usw.) in Sekunden um <ref>http://perldoc.perl.org/Time/Local.html</ref>
* <code>Sekunden + Minuten * 60 + Stunden * 60 * 60 + Tage * 24 * 60 * 60</code> berechnen eines Summanden oder Subtrahenden aus Sekunden, Minuten, Stunden und Tagen.
==== Beispiel: Zeitstempel eines Readings in Sekunden umwandeln ====
time_str2num(ReadingsTimestamp(<devicename>, <reading>,<defaultvalue>))
==== Konstanten innerhalb FHEM ====
FHEM stellt einige Konstanten<ref>{{Link2Forum|Topic=96959|Msg=901268|LinkText=Forum-Thread}}</ref> bereit, um das Rechnen mit Zeiten zu erleichtern, ''DAYSECONDS'', ''HOURSECONDS'', und ''MINUTESECONDS''. Obiger Code kann also auch so geschrieben werden:
Sekunden + Minuten * MINUTESECONDS + Stunden * HOURSECONDS + Tage * DAYSECONDS

=== Umwandeln einer Zahl in eine Zeichenkette ===
{{Randnotiz|RNTyp=Info|RNText= Hinweis!
* Die von <code>localtime</code> als Parameter erwartete Monatsangabe muss im Bereich der Ganzzahlwerte 0 bis 11 für Januar bis Dezember liegen.
* Werden keine Parameter angegeben, bezieht sich die Ausgabe auf den aktuellen Zeitpunkt.}}
Zur Umwandlung seien die folgenden Perl-Funktionen genannt:
* <code>"HH:MM, DD.MM.YY" =~ /(\d\d).(\d\d)..(\d\d).(\d\d).(\d\d)/</code> extrahiert HH,MM,DD,MM und YY aus der Zeichenkette HH:MM, DD.MM.YY, die ein Datum in der angegebenen Form enthält. \d steht für eine Ziffer, der Punkt für ein beliebiges Zeichen, die () schreiben den Treffer in spezielle Variablen in der Reihenfolge ihrer Anordnung HH in $1, MM in $2, DD in $3 usw.
* <code>(Sekunden, Minuten, Stunden, Tag des Monats, Monat, Jahr, Nummer des Wochentages, Tag des Jahres, Sommerzeitkennzeichen) = localtime(Zeit in Sekunden)</code> gibt die einzelnen Zeitelemente zurück <ref>http://perldoc.perl.org/functions/localtime.html</ref>
* <code>POSIX::strftime(<Format>,<Array mit Zeitelementen>)</code>, wandelt ein Array aus Zeitelementen, wie es <code>localtime</code> liefert in eine formatierte Zeichenkette um. <Format> wird mit Hilfe bestimmter Formatierungszeichen (%a für den Wochentagnamen, %d für den Tag des Monats usw. <ref>http://search.cpan.org/~dexter/POSIX-strftime-GNU-0.02/lib/POSIX/strftime/GNU.pm</ref>) festgelegt.

==== Beispiel: Wochentag zu Datum ====
Zum heutigen Datum
<syntaxhighlight lang="perl">
{return strftime("%A",localtime)}
</syntaxhighlight>

Zu einem vorgegebenem Datum<syntaxhighlight lang="perl">
{my ($d,$m,$y) = split(/\./,"06.09.2021");;
$m=$m-1;;
return strftime("%A",localtime(timelocal('0','0','0',$d,$m,$y)))}
</syntaxhighlight>

=== Berechnungsbeispiele ===
Allen Berechnungen zu Grunde liegt die Vorgehensweise in absoluten Sekunden bezogen auf einen Referenzzeitpunkt zu rechnen. Damit umgeht man jeden Wechsel Stunden/Tage/Monate/Jahre.

Die einzeiligen Beispiele sollten im Eingabefeld von FHEMWEB ausführbar sein.

==== Addition zu einem Zeitstempel ====
Gegeben sei ein [[Readings|Reading]] ''motion'' des [[Gerät|Gerätes]] ''BM1'' mit einem Zeitstempel ''2017-08-11 14:17:13''. Es sollen 2 Stunden und 12 Minuten addiert werden und das Ergebnis als HH:MM dargestellt werden.

<syntaxhighlight lang="perl">{POSIX::strftime("%H:%M",localtime(time_str2num(ReadingsTimestamp("BM1","motion","2000-01-01 00:00:00"))+2*60*60+12*60))}</syntaxhighlight>

Schrittweise:
<syntaxhighlight lang="perl">{
my $timestamp = ReadingsTimestamp("BM1","motion","2000-01-01 00:00:00");
my $seconds = time_str2num($timestamp)+2*60*60+12*60;
my $result = POSIX::strftime("%H:%M",localtime($seconds));
return $result;
}</syntaxhighlight>

==== Addition zum aktuellen Zeitpunkt ====
Zur aktuellen Zeit sollen 30 Minuten addiert und das Ergebnis als HH:MM:SS dargestellt werden.

<syntaxhighlight lang="perl">{POSIX::strftime("%H:%M:%S",localtime(time+30*60))}</syntaxhighlight>

==== Subtraktion vom aktuellen Zeitpunkt ====
Zur aktuellen Zeit sollen 45 Minuten subtrahiert und das Ergebnis als HH:MM:SS dargestellt werden.

<syntaxhighlight lang="perl">{POSIX::strftime("%H:%M:%S",localtime(time-45*60))}</syntaxhighlight>

==== Kalendertage von heute bis zu einem Datum ====
Zu einem bestimmten Kalendertag soll die Differenz in ganzen Tagen bestimmt werden.<syntaxhighlight lang="perl">
{(time_str2num('2021-04-30') - time_str2num(strftime '%F',localtime))/86400}
</syntaxhighlight>Das Zieldatum kann z.B. ein Termin aus dem Kalender sein: <code>fhem('get AbfallKalender events timeFormat:"%F" format:custom="$T1" limit:from=0,count=1')</code>

=== Weitere Funktionen zur Zeitumwandlung ===
* [[DevelopmentModuleAPI#Time_.2F_Timestamp|Time/Timestamp]]

[[Kategorie:HOWTOS]]

== Links ==
<references />

Zeitangaben, rechnen mit

2021-09-07T14:35:34Z

TomLee: Zwei Beispiele zum ausgeben des Wochentag ergänzt

Mit leicht lesbaren Zeitangaben, wie ''07:30'', ''23.05.2017, 09:20'' usw. kann in FHEM nicht ohne Weiteres gerechnet werden, da es sich um Zeichenketten handelt und nicht um Zahlen.

== Verfahren zum Rechnen mit Zeitangaben, die als Zeichenkette vorliegen ==
Die Berechnung erfolgt in Perl. Das Verfahren besteht aus drei Schritten:
* Umwandeln der Zeichenketten in eine Zahl, z.B. Sekunden.
* Berechen einer Zeit als Zahl.
* Umwandeln der Zahl in eine Zeichenkette (Formatierung)

=== Umwandeln eine Zeichenkette in eine Zahl ===
{{Randnotiz|RNTyp=Info|RNText= Hinweis!
* Die von <code>timelocal</code> zurückgegebene Monatsangabe hat die Ganzzahlwerte 0 bis 11 für Januar bis Dezember.}}
Hier hängt das Verfahren von der Struktur der Zeichenkette ab.

Perl und FHEM stellen Funktionen zur Umwandlung bereit.
* <code>time</code> liefert die aktuelle Zeit in Sekunden <ref>http://perldoc.perl.org/functions/time.html</ref>
* <code>time_str2num("YYYY-MM-DD HH:MM:SS")</code> wandelt einen FHEM-Zeitstempel in Sekunden um <ref>{{Link2CmdRef|Lang=de|Anker=perl}}</ref>
* <code>timelocal(<Sekunden>, <Minuten>, <Stunden>, <Tag des Monats>, <Monat>, <Jahr>)</code> wandelt einen Satz von Zeitelementen (Sekunden, Minuten, Stunden usw.) in Sekunden um <ref>http://perldoc.perl.org/Time/Local.html</ref>
* <code>Sekunden + Minuten * 60 + Stunden * 60 * 60 + Tage * 24 * 60 * 60</code> berechnen eines Summanden oder Subtrahenden aus Sekunden, Minuten, Stunden und Tagen.
==== Beispiel: Zeitstempel eines Readings in Sekunden umwandeln ====
time_str2num(ReadingsTimestamp(<devicename>, <reading>,<defaultvalue>))
==== Konstanten innerhalb FHEM ====
FHEM stellt einige Konstanten<ref>{{Link2Forum|Topic=96959|Msg=901268|LinkText=Forum-Thread}}</ref> bereit, um das Rechnen mit Zeiten zu erleichtern, ''DAYSECONDS'', ''HOURSECONDS'', und ''MINUTESECONDS''. Obiger Code kann also auch so geschrieben werden:
Sekunden + Minuten * MINUTESECONDS + Stunden * HOURSECONDS + Tage * DAYSECONDS

=== Umwandeln einer Zahl in eine Zeichenkette ===
{{Randnotiz|RNTyp=Info|RNText= Hinweis!
* Die von <code>localtime</code> als Parameter erwartete Monatsangabe muss im Bereich der Ganzzahlwerte 0 bis 11 für Januar bis Dezember liegen.
* Werden keine Parameter angegeben, bezieht sich die Ausgabe auf den aktuellen Zeitpunkt.}}
Zur Umwandlung seien die folgenden Perl-Funktionen genannt:
* <code>"HH:MM, DD.MM.YY" =~ /(\d\d).(\d\d)..(\d\d).(\d\d).(\d\d)/</code> extrahiert HH,MM,DD,MM und YY aus der Zeichenkette HH:MM, DD.MM.YY, die ein Datum in der angegebenen Form enthält. \d steht für eine Ziffer, der Punkt für ein beliebiges Zeichen, die () schreiben den Treffer in spezielle Variablen in der Reihenfolge ihrer Anordnung HH in $1, MM in $2, DD in $3 usw.
* <code>(Sekunden, Minuten, Stunden, Tag des Monats, Monat, Jahr, Nummer des Wochentages, Tag des Jahres, Sommerzeitkennzeichen) = localtime(Zeit in Sekunden)</code> gibt die einzelnen Zeitelemente zurück <ref>http://perldoc.perl.org/functions/localtime.html</ref>
* <code>POSIX::strftime(<Format>,<Array mit Zeitelementen>)</code>, wandelt ein Array aus Zeitelementen, wie es <code>localtime</code> liefert in eine formatierte Zeichenkette um. <Format> wird mit Hilfe bestimmter Formatierungszeichen (%a für den Wochentagnamen, %d für den Tag des Monats usw. <ref>http://search.cpan.org/~dexter/POSIX-strftime-GNU-0.02/lib/POSIX/strftime/GNU.pm</ref>) festgelegt.

=== Berechnungsbeispiele ===
Allen Berechnungen zu Grunde liegt die Vorgehensweise in absoluten Sekunden bezogen auf einen Referenzzeitpunkt zu rechnen. Damit umgeht man jeden Wechsel Stunden/Tage/Monate/Jahre.

Die einzeiligen Beispiele sollten im Eingabefeld von FHEMWEB ausführbar sein.

==== Addition zu einem Zeitstempel ====
Gegeben sei ein [[Readings|Reading]] ''motion'' des [[Gerät|Gerätes]] ''BM1'' mit einem Zeitstempel ''2017-08-11 14:17:13''. Es sollen 2 Stunden und 12 Minuten addiert werden und das Ergebnis als HH:MM dargestellt werden.

<syntaxhighlight lang="perl">{POSIX::strftime("%H:%M",localtime(time_str2num(ReadingsTimestamp("BM1","motion","2000-01-01 00:00:00"))+2*60*60+12*60))}</syntaxhighlight>

Schrittweise:
<syntaxhighlight lang="perl">{
my $timestamp = ReadingsTimestamp("BM1","motion","2000-01-01 00:00:00");
my $seconds = time_str2num($timestamp)+2*60*60+12*60;
my $result = POSIX::strftime("%H:%M",localtime($seconds));
return $result;
}</syntaxhighlight>

==== Addition zum aktuellen Zeitpunkt ====
Zur aktuellen Zeit sollen 30 Minuten addiert und das Ergebnis als HH:MM:SS dargestellt werden.

<syntaxhighlight lang="perl">{POSIX::strftime("%H:%M:%S",localtime(time+30*60))}</syntaxhighlight>

==== Subtraktion vom aktuellen Zeitpunkt ====
Zur aktuellen Zeit sollen 45 Minuten subtrahiert und das Ergebnis als HH:MM:SS dargestellt werden.

<syntaxhighlight lang="perl">{POSIX::strftime("%H:%M:%S",localtime(time-45*60))}</syntaxhighlight>

==== Kalendertage von heute bis zu einem Datum ====
Zu einem bestimmten Kalendertag soll die Differenz in ganzen Tagen bestimmt werden.<syntaxhighlight lang="perl">
{(time_str2num('2021-04-30') - time_str2num(strftime '%F',localtime))/86400}
</syntaxhighlight>Das Zieldatum kann z.B. ein Termin aus dem Kalender sein: <code>fhem('get AbfallKalender events timeFormat:"%F" format:custom="$T1" limit:from=0,count=1')</code>

==== Wochentag zu Datum ====
Zum heutigen Datum
<syntaxhighlight lang="perl">
{return strftime("%A",localtime)}
</syntaxhighlight>

Zu einem vorgegebenem Datum<syntaxhighlight lang="perl">
{my ($d,$m,$y) = split(/\./,"06.09.2021");;
$m=$m-1;;
return strftime("%A",localtime(timelocal('0','0','0',$d,$m,$y)))}
</syntaxhighlight>

=== Weitere Funktionen zur Zeitumwandlung ===
* [[DevelopmentModuleAPI#Time_.2F_Timestamp|Time/Timestamp]]

[[Kategorie:HOWTOS]]

== Links ==
<references />

AutoShuttersControl

2021-06-14T19:37:37Z

TomLee: /* readingsGroup für die Beschattung */

{{Infobox Modul
|ModPurpose=Steuerung von Rollläden
|ModCategory=Automatisierung
|ModType=d
|ModForumArea=Automatisierung
|ModTechName=73_AutoShuttersControl.pm
|ModOwner=CoolTux ({{Link2FU|13684|Forum}}/[[Benutzer Diskussion:CoolTux|Wiki]])}}
Mit [[AutoShuttersControl]] oder kurz '''ASC''' können Rollläden automatisch hoch und herunter gefahren werden. Zum Beispiel Öffnen bei Sonnenaufgang, Schließen bei Sonnenuntergang, Beschatten abhängig vom Sonnenstand oder Anfahren von Lüftungspositionen nach Öffnen des zugehörigen Fensters.

== Basics ==
{{Hinweis|Das Modul befindet sich derzeit noch in der Entwicklung; der derzeit aktuelle Stand ist diesem {{Link2Forum|Topic=112325|LinkText="Thread im Forum"}} zu entnehmen.}}
Als Voraussetzung sollten folgende FHEM-Devices bereits vorhanden sein:
* Rollläden,
* Fensterkontakte,
* Bewohnerstatus auf Basis von Residents/Roomates in englisch. Ersatzweise andere Devices, z.B. Dummys, welche als ''state'' ''home'', ''absent'', ''asleep'', ''gotosleep'' und ''awoken'' setzen sowie ein Reading ''lastState''.
* Helligkeitssensor (Steuerung nach Helligkeit für Beschattung)
* Ein Device zur Bestimmung des Sonnenstands (nur für Beschattung). Unterstützt werden derzeit [[Modul Astro|Astro]] und [[Twilight]]<ref>Dabei müssen ggf. in [[Global|global]] auch Angaben zu ''longitude'' und ''latitude'' vorhanden sein</ref>.
* Wenn Feiertage berücksichtigt werden sollen: Ein oder mehrere {{Link2CmdRef|Anker=holiday2we|Lang=en|Label=holiday2we}}-Angaben in [[Global|global]] samt entsprechender [[Wochenende, Feiertage und Schulferien#Feiertage mittels holiday-Datei|holiday]]-Dateien<ref>Es kann auch z.B. ein Dummy-Device verwendet werden, dieses sollte dann aber neben dem eigentlichen Feiertags-''state'' auch in einem Reading ''tomorrow'' Angaben zu anstehenden Feiertagen enthalten.</ref> <ref>Bitte verfahren Sie entsprechend, wenn Urlaubs- oder Ferientage wie Feiertage behandelt werden sollen.</ref>.

Die Einrichtung des Moduls bzw. dessen Funktionalität erfolgt in mehreren Schritten:
* Definition des ASC-Devices
* Einstellung zentraler Vorgaben am ASC-Device
* Markieren der zukünftig zu steuernden Rollladen-Devices
* Einbinden der Rollladen-Devices in das ASC-Device
* Einstellen der individuellen Vorgaben je Rollladen (am Rollladen-Device)
Dabei geht man am einfachsten schrittweise vor und erweitert die Funktionalität nach und nach um die gewünschten Funktionen. Dann benötigt man jeweils nur einen kleinen Teil der vielen per Attribut einstellbaren Optionen, und kann die Auswirkungen der jeweiligen Änderung besser nachvollziehen.

== Einrichtung ==
{{Hinweis|ASC kann auch verwendet werden, um lediglich Teilaufgaben der Rollladensteuerung zu erfüllen, also z.B. nur das morgendliche Öffnen der Rollläden. Allerdings geht dabei ein erheblicher Teil des Komforts verloren, der dadurch entsteht, dass die Steuerung innerhalb der vollintegrierten Lösung jeweils nachvollzieht, aus welchem Grund eine Fahrt erfolgt war und dies ggf. bei der nächsten Aktion berücksichtigt.}}

=== Vorbereitung ===
Zunächst sollten die in den [[#Basics|Basics]] beschriebenen Geräte vorhanden und funktionsfähig sein.

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

=== Einstellung zentraler Vorgaben ===
Mit Attributen am ASC-Device wird das Verhalten des ASC-Devices eingestellt, z.B. Vermeiden von morgendlichen oder abendlichen Fahrten, Frostschutzfunktion bei Gefahr von festgefrorenen Rollläden oder die Reaktion auf Fensterkontakte. Details sind der Commandref zu entnehmen.
Diese Attribute können jederzeit geändert werden.

=== Auswählen zu steuernder Rollladen-Devices ===
Für jeden vom ASC-Device kontrollierten Rollladen muss das globale Attribut ''ASC'' gesetzt werden. Das steht nach dem Definieren des ASC-Devices zur Verfügung. Das Attribut ist mit 1 oder 2 festzulegen:
# Je ''kleiner'' der <code>pct</code> Wert um so weiter ist der Rollladen geschlossen. Typischerweise ist dann 0 ''offen'' und 100 ''geschlossen''. Dies ist z.B. die passende Wahl für ROLLO-Devices
# Je ''größer'' der <code>pct</code> Wert desto weiter ist der Rollladen geschlossen, also ''offen'' für <code>set <name> pct 100</code>. Typische Vertreter dieses Typs sind HomeMatic (CUL_HM-) Geräte oder die Shelly2-Aktoren.

Basierend auf dem Parameter leitet das Modul bestimmte Voreinstellungen (''defaults'') für den Rollladen ab. Es genügt daher, nur jeweils die Einstellungen zu verändern, die anders gewünscht werden oder für den Rollladenaktortyp anders sein müssen (z.B. ''dim 99'' für vollständiges Öffnen eines ZWave-Aktors).
{{Hinweis|Das Vorstehende gilt jeweils für den nicht-invertierten Modus! Wer z.B. ein HomeMatic-Gerät mit ''levelinverse'' betreibt, sollte ''ASC'' auf "1" setzen usw.. Maßgeblich ist letztlich nur die Frage, ob die Offen-Positionsangabe nummerisch kleiner oder größer als die Geschlossen-Positionsangabe ist; die konkreten Zahlenwerte spielen dabei keine Rolle, die Angabe ''position'' oder ''pct'' kann auch später über ein weiteres Attribut passend eingestellt werden.}}

=== Einbinden in das ASC-Device ===
Nachdem das ASC Attribut für die betreffenden Rollladen-Devices gesetzt ist, muss mit <code>set <name> scanForShutters</code> ein Suchlauf gestartet werden, mit dem diese Rollläden in die Steuerungslogik eingebunden werden.

=== Einstellen der individuellen Vorgaben ===
Die gefundenen Rollladen-Devices erhalten weitere Attribute, mit denen für den jeweiligen Rollladen benötigte Einstellungen vorgenommen werden.
Diese Attribute sind in der commandref beschrieben.

== Readings ==
===Readings im zentralen ASC-Device ===

{| class="wikitable"
|-
! Name !! Datentyp/<BR />Wertebereich !! Bedeutung
|-
|..._nextAstroTimeEvent || || Zeit wird abhängig von der eingestellten Attribute ASC_Time_Up/ASC_Time_Down angezeigt. Bei ''astro'' die Uhrzeit des Sonnenauf- oder Sonnenuntergang, bei ''time'' und ''brightness'' die Zeit aus ASC_Time_Up_Early/ASC_Time_Down_Late pro Rollonamen
|-
|..._lastPosValue || || Position pro Rollonamen, bevor ASC die Rollläden verfahren hat.
|-
|..._PosValue || ||aktuelle Position pro Rollonamen.
|-
|ascEnable||on, off ||globale ASC Steuerung bei den Rollläden aktiv oder inaktiv
|-
|controlShading||on, off ||globale Beschattungsfunktion aktiv oder inaktiv
|-
|hardLockOut || on, off ||Status des hardwareseitigen Aussperrschutzes / gilt nur für Rollläden mit dem Attribut bei denen das Attributs ASC_LockOut entsprechend auf hard gesetzt ist.
|-
|selfDefense || on, off ||globale Selbstschutzfunktion aktiv oder inaktiv
|-
|partyMode ||on, off || globaler Partymodus aktiv oder inaktiv
|-
|state || ||Status des ASC-Devices: active, enabled, disabled oder weitere Statusinformationen wie z.B. Grund der letzen Fahrt.
|-
|room_... || ||Auflistung aller Rollläden, welche in den jeweiligen Räumen gefunden wurden, Bsp.: room_Schlafzimmer,Terrasse.
|-
|sunriseTimeWeHoliday|| on,off ||globale Wochenendunterstützung aktiv oder inaktiv.
|-
|userAttrList || rolled out ||Das ASC-Modul verteilt an die gesteuerten Rollladen-Geräte diverse Benutzerattribute (userattr). In diesem Reading kann der Status dieser Verteilung geprüft werden.

|}

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

{| class="wikitable"
|-
! Name !! Bedeutung
|-
|ASC_Enable ||Status von ASC_Enable (on,off).
|-
|ASC_ShuttersLastDrive ||Grund der letzten Fahrt des Rollladens.
|-
|ASC_Time_DriveDown ||Zeit wird abhängig von der eingestellten Attribute ASC_Time_Down angezeigt. Bei astro die Uhrzeit des Sonnenuntergangs, bei time und brightness die Zeit aus /ASC_Time_Down_Late
|-
|ASC_Time_DriveUp ||Zeit wird abhängig von der eingestellten Attribute ASC_Time_Up angezeigt. Bei astro die Uhrzeit des Sonnenaufgangs, bei time und brightness die Zeit aus /ASC_Time_Up_Early
|}

==set- und get-Befehle für das ASC-Device==
=== set-Anweisungen ===
{| class="wikitable"
|-
! Name !! Datentyp/<BR />Wertebereich !! Beschreibung
|-
|advDriveDown ||on, off ||Nachholen der durch ASC_Adv on ausgesetzten Fahrten.
|-
|ascEnable||on, off ||Aktiviert oder deaktiviert die globale ASC-Steuerung.
|-
|controlShading||on, off ||Aktiviert oder deaktiviert die globale Beschattungssteuerung.
|-
|createNewNotifyDev || ||Legt die interne Struktur für NOTIFYDEV neu an. (Diese Funktion steht nur zur Verfügung, wenn Attribut ASC_expert auf 1 gesetzt ist.)
|-
|hardLockOut ||on, off ||Aktiviert den hardwareseitigen Aussperrschutz für die Rollläden, bei denen das Attributs ASC_LockOut auf hard gesetzt ist. Mehr Informationen in der Beschreibung bei den Attributen für die Rollladengeräten.
|-
|partyMode ||on, off ||Aktiviert den globalen Partymodus. Alle Rollladen-Geräten, in welchen das Attribut ASC_Partymode auf on gesetzt ist, werden durch ASC nicht mehr gesteuert. Der letzte Schaltbefehl, der bspw. durch ein Fensterevent oder Wechsel des Bewohnerstatus an die Rollläden gesendet wurde, wird beim Deaktivieren des Partymodus ausgeführt
|-
|renewAllTimer || ||Erneuert bei allen Rollläden die Zeiten gemäß ASC_UP/ASC_DOWN und setzt die internen Timer neu.
|-
|renewTimer || ||Erneuert bei dem ausgewählten Rollladen die Zeiten gemäß ASC_UP/ASC_DOWN und setzt die internen Timer neu.
|-
|scanForShutters || ||Sucht alle FHEM Devices mit dem Attribut ''ASC'' ''1'' oder ''2'' und legt diese im ASC-Modul an
|-
|selfDefence ||on, off||Aktiviert bzw. deaktiviert die Selbstschutzfunktion. Beispiel 1: Wenn das Residents-Gerät ''gone'' meldet, alle Rollläden dann heruntergefahren. Beispiel 2 : Wenn das Residents-Gerät ''absent'' meldet, das Attribut ASC_ShuttersPlace=terrace ist und ein Fenster im Haus noch geöffnet ist, so wird an diesem Fenster der Rollladen dann heruntergefahren.
|-
|shutterASCenableToggle || ||Aktivieren oder deaktivieren der ASC Kontrolle des einzelnen Rollladens.
|-
|sunriseTimeWeHoliday || on,off ||Aktiviert die Wochenendunterstützung. Dann wird das Attribut ASC_Time_Up_WE_Holiday am Rollladen-Device beachtet.
|-
|wiggle ||||Bewegt einen oder mehrere Rollläden um einen definierten Wert (Default: 5%) und nach einer Minute wieder zurück in die Ursprungsposition. Diese Funktion könnte bspw. zur Abschreckung in einem Alarmsystem eingesetzt werden.
|-
|||||
|}

=== get-Anweisungen ===

{| class="wikitable"
|-
! Name !! Beschreibung
|-
| showNotifyDevsInformations ||Zeigt eine Übersicht der abgelegten NOTIFYDEV Struktur. Diese Funktion wird für das Debugging genutzt. Hierzu ist das Attribut ASC_expert = 1 zu setzen.
|}

== Attribute ==
{{Hinweis|Die Attributnamen haben sich teilweise geändert, nachfolgend ist der Stand von Modulversion v0.8.x wiedergegeben.}}
{{Hinweis|In der commandref findet sich häufig die Schreibweise <code><nowiki>ASC_BrightnessSensor Sensorname[:brightness [400:800]]</nowiki></code>. Dabei sind die Angaben in den eckigen Klammern optional. Dies müssen also nicht angegeben werden, stattdessen verwendet das Modul dann Standardwerte (siehe cref), die in der cref zu findenden Angaben entsprechen dabei den defaults. Werden Werte angegeben, sind die eckigen Klammern '''wegzulassen'''! Beispiel: <code>ASC_BrightnessSensor hm_motion_1 70:100</code> würde das brightness-Reading des Sensors hm_motion_1 verwenden und einen morgendlichen Schwellenwert von 70 bzw. 100 für abends.}}
===Attribute direkt am ASC-Device ===

{| class="wikitable"
|-
! Name !! Datentyp/<BR />Wertebereich !! Default-Wert !! Beschreibung
|-
|ASC_autoAstroModeEvening || ||REAL, CIVIL, NAUTIC, ASTRONOMIC oder HORIZON ||nach welchem ASTRO-Modus soll die Abendfahrt berechnet werden
|-
|ASC_autoAstroModeEveningHorizon || - 9 bis 9 || 0|| Höhe über dem Horizont. Wird nur berücksichtigt, wenn im Attribut ASC_autoAstroModeEvening der Wert HORIZON ausgewählt wurde.
|-
|ASC_autoAstroModeMorning || ||REAL, CIVIL, NAUTIC, ASTRONOMIC oder HORIZON || nach welchem ASTRO-Modus soll die Morgendfahrt berechnet werden
|-
|ASC_autoAstroModeMorningHorizon || - 9 bis 9|| 0|| Höhe über dem Horizont. Wird nur berücksichtigt, wenn im Attribut ASC_autoAstroModeMorning der Wert HORIZON ausgewählt wurde.
|-
|ASC_autoShuttersControlComfort ||on, off || off ||schaltet die Komfortfunktion an. Bedeutet, dass ein Rollladen mit einem threestate-Sensor am Fenster beim Öffnen in eine Offenposition fährt. Hierzu muss beim Rollladen das Attribut ASC_ComfortOpen_Pos entsprechend konfiguriert sein.
|-
|ASC_autoShuttersControlEvening ||on, off || ||Aktiviert die automatische Steuerung durch das ASC-Modul am Abend.
|-
|ASC_autoShuttersControlMorning ||on, off || ||Aktiviert die automatische Steuerung durch das ASC-Modul am Morgen.
|-
|ASC_blockASCDrivesAfterManual ||0, 1 || ||wenn dieser Wert auf 1 gesetzt ist, dann werden Rollläden vom ASC-Modul nicht mehr gesteuert, wenn zuvor manuell eingegriffen wurde. Voraussetzung hierfür ist jedoch, dass im Reading ASC_ShuttersLastDrive der Status manual enthalten ist und sich der Rollladen auf eine unbekannte (nicht in den Attributen anderweitig konfigurierte) Position befindet.
|-
|ASC_brightnessDriveUpDown || || || Werte (z.B. Lux) bei dem Schaltbedingungen für Sonnenauf- und -untergang geprüft werden sollen. Diese globale Einstellung kann durch die WERT-MORGENS:WERT-ABENDS Einstellung von ASC_BrightnessSensor im Rollladen selbst überschrieben werden.
|-
|ASC_debug ||0, 1 || 0||Aktiviert die erweiterte Logausgabe für Debugausgaben (nur nach Aufforderung nutzen)
|-
|ASC_expert ||0, 1 ||0 ||ist der Wert 1, so werden erweiterte Informationen bezüglich des NotifyDevs unter ''set und get'' angezeigt
|-
|ASC_freezeTemp ||-5 bis 5 || ||Temperatur, ab welcher der Frostschutz greifen soll und der Rollladen nicht mehr fährt. Der letzte Fahrbefehl wird gespeichert.
|-
|ASC_rainSensor || || ||DEVICENAME[:READINGNAME] MAXTRIGGER[:HYSTERESE] [CLOSEDPOS] - der Inhalt ist eine Kombination aus Devicename, Readingname, Wert ab dem getriggert werden soll, Hysterese Wert ab dem der Status Regenschutz aufgehoben werden soll und der "wegen Regen geschlossen Position".
|-
|ASC_residentsDev || || ||DEVICENAME[:READINGNAME] - der Inhalt ist eine Kombination aus Devicenamen und Readingnamen des Residents-Device der obersten Ebene (z.B. rgr_Residents:state)
|-
|ASC_shuttersDriveDelay || || ||maximale Zufallsverzögerung in Sekunden bei der Berechnung der Fahrzeiten. 0 bedeutet keine Verzögerung
|-
|ASC_tempSensor || || ||DEVICENAME[:READINGNAME] - der Inhalt ist eine Kombination aus Device und Reading für die Außentemperatur
|-
|ASC_twilightDevice || || ||das Device, welches die Informationen zum Sonnenstand liefert. Wird unter anderem für die Beschattung verwendet.
|-
|ASC_windSensor || || ||DEVICE[:READING] - Sensor für die Windgeschwindigkeit. Kombination aus Device und Reading.
|-
| || || ||
|-
| || || ||
|}

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

{| class="wikitable"
|-
! Name !! Datentyp/<BR />Wertebereich !! Default-Wert !! Beschreibung
|-
|ASC || 0, 1, 2|| ||"kein Anlegen der Attribute beim ersten Scan bzw. keine Beachtung eines Fahrbefehles",1 = "Inverse oder Rollo - Bsp.: Rollo oben 0, Rollo unten 100 und der Befehl zum prozentualen Fahren ist position",2 = "Homematic Style - Bsp.: Rollo oben 100, Rollo unten 0 und der Befehl zum prozentualen Fahren ist pct
|-
|ASC_Adv || on, off||||bei on wird das runterfahren des Rollos während der Weihnachtszeit (1. Advent bis 6. Januar) ausgesetzt! Durch set <ASCDEVICE> advDriveDown werden alle ausgesetzten Fahrten nachgeholt.
|-
|ASC_Antifreeze ||off, soft, hard, am, pm || ||Frostschutz, wenn soft fährt der Rollladen in die ASC_Antifreeze_Pos, bei hard/am/pm wird gar nicht oder innerhalb der entsprechenden Tageszeit nicht gefahren
|-
|ASC_Antifreeze_Pos || || ||Position des Rolllades die angefahren werden soll, wenn der Fahrbefehl komplett schließen lautet, aber der Frostschutz aktiv ist !!!Verwendung von Perlcode ist möglich, dieser muss in {} eingeschlossen sein. Rückgabewert muss eine positive Zahl/Dezimalzahl sein!!!
|-
|ASC_autoAstroModeEvening ||REAL, CIVIL, NAUTIC, ASTRONOMIC oder HORIZON || ||nach welchem ASTRO-Modus soll die Abendfahrt berechnet werden
|-
|ASC_autoAstroModeEveningHorizon || - 9 bis 9 || 0|| Höhe über dem Horizont. Wird nur berücksichtigt, wenn im Attribut ASC_autoAstroModeEvening der Wert HORIZON ausgewählt wurde.
|-
|ASC_autoAstroModeMorning ||REAL, CIVIL, NAUTIC, ASTRONOMIC oder HORIZON || || nach welchem ASTRO-Modus soll die Morgendfahrt berechnet werden
|-
|ASC_autoAstroModeMorningHorizon || - 9 bis 9|| 0|| Höhe über dem Horizont. Wird nur berücksichtigt, wenn im Attribut ASC_autoAstroModeMorning der Wert HORIZON ausgewählt wurde.
|-
|ASC_BlockingTime_afterManual || ||1200 ||wie viel Sekunden soll die Automatik nach einer manuellen Fahrt aussetzen
|-
|ASC_BlockingTime_beforeDayOpen || ||3600 ||wie viel Sekunden vor dem morgendlichen öffnen soll keine schließen Fahrt mehr stattfinden.
|-
|ASC_BlockingTime_beforeNightClose || ||3600 ||ie viel Sekunden vor dem nächtlichen schließen soll keine öffnen Fahrt mehr stattfinden.
|-
|ASC_BrightnessSensor || ||none ||DEVICE[:READING] WERT-MORGENS:WERT-ABENDS / 'Sensorname[:brightness [400:800]]' Angaben zum Helligkeitssensor mit (Readingname, optional) für die Beschattung und dem Fahren der Rollladen nach brightness und den optionalen Brightnesswerten für Sonnenauf- und Sonnenuntergang
|-
|ASC_Closed_Pos || ||default Vorgabe ist abhängig vom Attribut ''ASC''||in 10er-Schritten von 0 bis 100
wird angefahren wenn SelfDefense aktiv ist
|-
|ASC_ComfortOpen_Pos || || || in 10er Schritten von 0 bis 100 !!! Die eingestellte Position wird bei einem threestate Sensor angefahren. Verwendung von Perlcode ist möglich, dieser muss in {} eingeschlossen sein. Rückgabewert muss eine positive Zahl/Dezimalzahl sein!!!
|-
|ASC_Down || time, astro, brightness, roommate || astro||bei ''astro'' wird Sonnenuntergang berechnet, bei time wird der Wert aus ASC_Time_Down_Early als Fahrzeit verwendet und bei brightness muss ASC_Time_Down_Early und ASC_Time_Down_Late korrekt gesetzt werden. Der Timer läuft dann nach ASC_Time_Down_Late Zeit, es wird aber in der Zeit zwischen ASC_Time_Down_Early und ASC_Time_Down_Late geschaut, ob die als Attribut im Moduldevice hinterlegte ASC_brightnessDriveUpDown der Down Wert erreicht wurde. Wenn ja, wird der Rollladen runter gefahren.
|-
|ASC_DiveUpMaxDuration || || 60||die Dauer des Hochfahrens des Rollladens plus 5 Sekunden
|-
|ASC_Drive_Delay || || -1|| maximaler Wert für einen zufällig ermittelte Verzögerungswert in Sekunden bei der Berechnung der Fahrzeiten, 0 bedeutet keine Verzögerung, -1 bedeutet, dass das ??gleichwertige Attribut?? aus dem ASC Device ausgewertet werden soll
|-
|ASC_Drive_DelayStart || || -1|| in Sekunden verzögerter Wert ab welchen dann erst das Offset startet und dazu addiert wird. Funktioniert nur wenn gleichzeitig ASC_DriveDelay gesetzt wird.
|-
|ASC_ExternalTrigger || |||| DEVICE:READING VALUEACTIVE:VALUEINACTIVE POSACTIVE:POSINACTIVE, Beispiel: "WohnzimmerTV:state on:off 66:100" bedeutet das wenn ein "state:on" Event kommt soll das Rollo in Position 66 fahren, kommt ein "state:off" Event soll es in Position 100 fahren. Es ist möglich die POSINACTIVE weg zu lassen dann fährt das Rollo in LastStatus Position.
|-
|ASC_GuestRoom || on, off |||| aktuell noch nicht umgesetzt...
|-
|ASC_LockOut || soft, hard, off ||off || stellt entsprechend den Aussperrschutz ein. Bei global aktivem Aussperrschutz (set ASC-Device lockOut soft) und einem Fensterkontakt open bleibt dann der Rollladen oben. Dies gilt nur bei Steuerbefehlen über das ASC Modul. Stellt man global auf hard, wird bei entsprechender Möglichkeit versucht den Rollladen hardwareseitig zu blockieren. Dann ist auch ein Fahren über die Taster nicht mehr möglich
|-
|ASC_LockOut_Cmd || inhibit, blocked, protection ||none|| set Befehl für das Rollladen-Device zum Hardware sperren. Dieser Befehl wird gesetzt werden, wenn man "ASC_LockOut" auf hard setzt
|-
|ASC_Mode_Down ||absent, always, off, home || always ||Wann darf die Automatik steuern. immer, niemals, bei Abwesenheit des Roommate (ist kein Roommate und absent eingestellt, wird gar nicht gesteuert)
|-
|ASC_Mode_Up ||absent, always, off, home || always ||Wann darf die Automatik steuern. immer, niemals, bei Abwesenheit des Roommate (ist kein Roommate und absent eingestellt, wird gar nicht gesteuert)
|-
|ASC_Open_Pos || ||default Vorgabe ist abhängig vom Attribut ''ASC''||in 10er-Schritten von 0 bis 100
|-
|ASC_Partymode || on, off || off ||schaltet den Partymodus an oder aus. Wird am ASC Device set ASC-DEVICE partyMode on geschalten, werden alle Fahrbefehle an den Rollläden, welche das Attribut auf on haben, zwischengespeichert und später erst ausgeführ
|-
|ASC_Pos_Reading || || ||Name des Readings, welches die Position des Rollladen in Prozent angibt. Wird bei unbekannten Device-Typen auch als ''set'' Befehl zum Fahren verwendet
|-
|ASC_PrivacyDownValue_beforNightClose || || -1||wie viele Sekunden vor dem abendlichen schließen soll der Rollladen in die Sichtschutzposition fahren, oder bei Brightness ab welchem minimum Brightnesswert soll das Rollo in die Privacy Position fahren. Bei Brightness muss zusätzlich zum Zeitwert der Brightnesswert mit angegeben werden 1800:300 bedeutet 30 min vor night close oder bei unter einem Brightnesswert von 300
|-
|ASC_PrivacyDown_Pos || ||50||Position den Rollladens für den abendlichen Sichtschutz!Verwendung von Perlcode ist möglich, dieser muss in {} eingeschlossen sein. Rückgabewert muss eine positive Zahl/Dezimalzahl sein!!!
|-
|ASC_PrivacyUpValue_beforDay || || -1||wie viele Sekunden vor dem morgendlichen öffnen soll der Rollladen in die Sichtschutzposition fahren, oder bei Brightness ab welchem minimum Brightnesswert soll das Rollo in die Privacy Position fahren. Bei Brightness muss zusätzlich zum Zeitwert der Brightnesswert mit angegeben werden 1800:600 bedeutet 30 min vor day open oder bei über einem Brightnesswert von 600
|-
|ASC_PrivacyUp_Pos || ||50||Position den Rollladens für den morgendlichen Sichtschutz!Verwendung von Perlcode ist möglich, dieser muss in {} eingeschlossen sein. Rückgabewert muss eine positive Zahl/Dezimalzahl sein!!!
|-
|ASC_RainProtection ||on, off || ||soll der Rollladen beim Regenschutz beachtet werden. on=JA, off=NEIN.
|-
|ASC_Roommate_Device || || none ||mit Komma getrennte Namen des/der Roommate-Device/s welche den/die Bewohner des Rollladen-Raumes wiedergibt. Macht nur Sinn in Schlaf- oder Kinderzimmern
|-
|ASC_Roommate_Reading || || ||Reading des Roommate-Device, welches den Status wieder gibt
|-
|ASC_Self_Defense_AbsentDelay || || 300||um wie viele Sekunden soll das fahren in Selfdefense bei Residents absent verzögert werden
|-
|ASC_Self_Defense_Mode || || gone||ab welchen Residents Status soll Selfdefense aktiv werden ohne das Fenster auf sind
|-
|ASC_Shading_InOutAzimuth || ||95:265 ||Azimut Wert ab dem bei Überschreiten Beschattet und bei Unterschreiten Endschattet werden soll
|-
|ASC_Shading_MinMax_Elevation || ||25.0:100.0 ||ab welcher min Höhe des Sonnenstandes soll beschattet und ab welcher max Höhe wieder beendet werden, immer in Abhängigkeit der anderen einbezogenen Sensorwerte
|-
|ASC_Shading_MinOutsideTemperature_ || ||18 ||ab welcher Temperatur soll Beschattet werden, immer in Abhängigkeit der anderen einbezogenen Sensorwert
|-
|ASC_ShadingMode ||absent, always, off, home || off||wann soll die Beschattung nur stattfinden
|-
|ASC_Shading_Pos || || ||Position des Rollladens für die Beschattung !!!Verwendung von Perlcode ist möglich, dieser muss in {} eingeschlossen sein. Rückgabewert muss eine positive Zahl/Dezimalzahl sein!!!
|-
|ASC_Shading_StateChange_SunnyCloudy || ||35000:20000 ||Brightness Wert ab welchen die Beschattung stattfinden und aufgehoben werden soll, immer in Abhängigkeit der anderen einbezogenen Sensorwerte
|-
|ASC_Shading_WaitingPeriod || ||1200 ||wie viele Sekunden soll gewartet werden bevor eine weitere Auswertung der Sensordaten für die Beschattung stattfinden soll
|-
|ASC_Shutter_IdleDetection || ||||READING:VALUE gibt das Reading an welches Auskunft über den Fahrstatus des Rollos gibt, sowie als zweites den Wert im Reading welcher aus sagt das das Rollo nicht fährt
|-
|ASC_ShuttersPlace || window, terrace || ||wenn dieses Attribut auf ''terrace'' gesetzt ist und das Residents-Device in den Status ''absent'' geht, ''selfDefence'' aktiv ist und das Fenster geöffnet ist, wird das Rollo geschlossen. Wenn ein twostate Senso genutzt wird und dieses Attribut auf ''terrace'' gesetzt ist wird ASC_Ventilate_Pos ignoriert und das Rollo wird beim öffnen des Fenster komplett geöffnet. Wenn dieses Attribut auf ''window'' gesetzt ist wird ASC_Ventilate_Pos berücksichtigt und das Rollo wird entsprechend der ASC_Ventilate_Pos geöffnet. Wenn das Fenster wieder geschlossen wird, dann wird das Rollo unabhängig von ''windows oder terrace'' vollständig geschlossen.
|-
|ASC_Sleep_Pos || || ||in 10er-Schritten von 0 bis 100, default Vorgabe ist abhängig vom Attribut ''ASC.'' Position wird angefahren wenn Bedingung für modeDown aktiv ist. Hiermit kann z.B. das komplette abendliche Schließen des Rollos begrenzt werden.
|-
|ASC_TempSensor || || ||DEVICENAME[:READINGNAME] - der Inhalt ist eine Kombination aus Device und Reading für die Außentemperatur
|-
|ASC_Time_Down_Early || ||16:00 ||Sonnenuntergang frühste Zeit zum Runterfahren !!!Verwendung von Perlcode ist möglich, dieser muss in {} eingeschlossen sein. Rückgabewert muss ein Zeitformat in Form HH:MM[:SS] sein!!!
|-
|ASC_Time_Down_Late || ||22:00 ||Sonnenuntergang späteste Zeit zum Runterfahren !!!Verwendung von Perlcode ist möglich, dieser muss in {} eingeschlossen sein. Rückgabewert muss ein Zeitformat in Form HH:MM[:SS] sein!!!
|-
|ASC_Time_Up_Early || || 05:00||Sonnenaufgang frühste Zeit zum Hochfahren !!!Verwendung von Perlcode ist möglich, dieser muss in {} eingeschlossen sein. Rückgabewert muss ein Zeitformat in Form HH:MM[:SS] sein!!!
|-
|ASC_Time_Up_Late || ||08:30 ||Sonnenaufgang späteste Zeit zum Hochfahren !!!Verwendung von Perlcode ist möglich, dieser muss in {} eingeschlossen sein. Rückgabewert muss ein Zeitformat in Form HH:MM[:SS] sein!!!
|-
|ASC_Time_Up_WE_Holiday || ||08:00 ||Sonnenaufgang frühste Zeit zum Hochfahren am Wochenende und/oder Urlaub (holiday2we wird beachtet).ACHTUNG!!! in Verbindung mit Brightness für ASC_Up muss die Uhrzeit kleiner sein wie die Uhrzeit aus ASC_Time_Up_Late !!!Verwendung von Perlcode ist möglich, dieser muss in {} eingeschlossen sein. Rückgabewert muss ein Zeitformat in Form HH:MM[:SS] sein!!!
|-
|ASC_Ventilate_Window_Open ||on, off ||on||auf lüften, wenn das Fenster gekippt/geöffnet wird und aktuelle Position unterhalb der Lüften-Position ist
|-
|ASC_WiggleValue || ||5 ||Wert, um welchen sich die Position des Rollladens bei ''Wiggle'' ändern soll
|-
|ASC_WindParameters || ||5 ||TRIGGERMAX[:HYSTERESE] [DRIVEPOSITION] / Angabe von Max Wert ab dem für Wind getriggert werden soll, Hytsrese Wert ab dem der Windschutz aufgehoben werden soll TRIGGERMAX - HYSTERESE / Ist es bei einigen Rollläden nicht gewünscht das gefahren werden soll, so ist der TRIGGERMAX Wert mit -1 an zu geben. (default: '50:20 ClosedPosition')
|-
|ASC_WindProtection ||on, off || ||soll der Rollladen beim Windschutz beachtet werden. on=JA, off=NEIN.
|-
|ASC_WindowRec || ||none ||Name des Fensterkontakts, an welchen Fenster der Rollladen angebracht ist. WINDOWREC:[READING], Name des Fensterkontaktes, an dessen Fenster der Rollladen angebracht ist. Reading ist optional
|-
|ASC_WindowRec_PosAfterDayClosed ||open, lastManual ||open ||Name des Fensterkontakts, an welchen Fenster der Rollladen angebracht ist. Sein Reading ''state'' muss die Werte ''open'', ''closed'' oder ''tilted'' enthalten.
|-
|ASC_WindowRec_subType ||twostate, threestate ||twostate||Typ des verwendeten Fensterkontaktes: twostate (optisch oder magnetisch) oder threestate (Drehgriffkontakt)
|-
| || || ||
| || || ||
|-
| || || ||
|-
| || || ||
|-
| || || ||
|}

== Hilfsmittel ==
{{Hinweis|Die Device-Namen sind auf die eigene Installation anzupassen.}}

{{Hinweis|Codezeilen sind im [[Import von Code Snippets|RAW]]-Format.}}

{{Randnotiz|RNTyp=g|RNText= Stand 2019-05-03
* Erfolgreich getestet mit Homematic Devices, Beta-User
* Die Farbgebung entspricht dem Standard, wenn unter dem Style f18 der Farbpreset ''light'' gewählt wird.
}}

=== readingsGroup für Level ===
<pre style="width:65%;word-wrap: break-word;">defmod rg_ASC_Rolllaeden_Level readingsGroup <Gerät>,<Stand>,<Schliessen bis>,<Öffnen auf>,<Beschattung>,<Komfort>,<Lüften>,<Privacy> (Rollladen_.*|Jalousie_.*)..:level,!?ASC_Closed_Pos,!?ASC_Open_Pos,!?ASC_Shading_Pos,!?ASC_ComfortOpen_Pos,!?ASC_Ventilate_Pos,!?ASC_PrivacyDown_Pos
attr rg_ASC_Rolllaeden_Level commands {level => 'pct:selectnumbers,0,5,100,0,lin',\
ASC_Closed_Pos => 'ASC_Closed_Pos:selectnumbers,0,5,100,0,lin',\
ASC_Open_Pos => 'ASC_Open_Pos:selectnumbers,0,5,100,0,lin',\
ASC_Shading_Pos => 'ASC_Shading_Pos:selectnumbers,0,5,100,0,lin',\
ASC_Ventilate_Pos => 'ASC_Ventilate_Pos:selectnumbers,0,5,100,0,lin',\
ASC_ComfortOpen_Pos => 'ASC_ComfortOpen_Pos:selectnumbers,0,5,100,0,lin',\
ASC_PrivacyDown_Pos => 'ASC_PrivacyDown_Pos:selectnumbers,0,5,100,0,lin'}
</pre>

=== readingsGroup für Zeiten ===
[[Bild:ReadingsGroup ASC times.png|thumb|right|ReadingsGroup - Zeitenbeispiel]]
<pre style="width:65%;word-wrap: break-word;">defmod rg_ASC_Rolllaeden_Times readingsGroup <Gerät>,<Position>,<Time_Up_Early>,<Time_Up_Late>,<Time_Up_WE/Hol>,<Time_Down_Early>,<Time_Down_Late>,<Mode_Down>,<Mode_Up> \
(.*Rollo.*|.*Rollladen|Jalousie_.*):level,!?ASC_Time_Up_Early,!?ASC_Time_Up_Late,!?ASC_Time_Up_WE_Holiday,!?ASC_Time_Down_Early,!?ASC_Time_Down_Late,!?ASC_Mode_Down,!?ASC_Mode_Up
attr rg_ASC_Rolllaeden_Times commands {level => 'pct:0,10,20,30,35,40,45,50,55,60,65,70,75,80,85,90,95,100', \
ASC_Time_Down_Early => 'ASC_Time_Down_Early:15:00,15:15,15:30,15:45,16:00,16:15,16:30,16:45,17:00,17:15,17:30,17:45,18:00,18:15,18:30,18:45,19:00,19:15,19:30,19:45,20:00,20:15,20:30,20:45,21:00,21:15,21:30,21:45,22:00', \
ASC_Time_Down_Late => 'ASC_Time_Down_Late:19:00,19:15,19:30,19:45,20:00,20:15,20:30,20:45,21:00,21:15,21:30,21:45,22:00,22:15,22:30,22:45,23:00,23:15,23:30', \
ASC_Time_Up_WE_Holiday => 'ASC_Time_Up_WE_Holiday:06:00,06:15,06:30,06:45,07:00,07:15,07:30,07:45,08:00,08:15,08:30,08:45,09:00,09:15,09:30,09:45,10:00',\
ASC_Time_Up_Early => 'ASC_Time_Up_Early:05:00,05:05,05:30,05:55,06:00,06:15,06:30,06:45,07:00,07:15,07:30,07:45,08:00,08:15,08:30,08:45,09:00,09:15,09:30,09:45,10:00', \
ASC_Time_Up_Late => 'ASC_Time_Up_Late:06:00,06:15,06:30,06:45,07:00,07:15,07:30,07:45,08:00,08:15,08:30,08:45,09:00,09:15,09:30,09:45,10:00', \
ASC_Mode_Down => 'ASC_Mode_Down:always,absent,off', \
ASC_Mode_Up => 'ASC_Mode_Up:always,absent,off' }
attr rg_ASC_Rolllaeden_Times room Rollladen</pre>

[[Bild:ASC RG Zeiten HM ZWave Siro.png|thumb|right|ReadingsGroup - CUL_HM+ZWave+Siro mit widgets]]Neue Version mit time-Widgets und pct/dim/position-widget (5-er Schritte), passend für CUL_HM, ZWave und Siro-Geräte:
<pre style="width:65%;word-wrap: break-word;">defmod rg_ASC_Rolllaeden_Times readingsGroup <Gerät>,<Stand>,<Time_Up_Early >,<Time_Up_WE >,<Time_Up_Late >,<Time_Down_Early>,<Time_Down_Late>,<Mode_Down>,<Mode_Up> (Rollo_.*|Jalousie_.*)..:(level|dim|position),!?ASC_Time_Up_Early,!?ASC_Time_Up_WE_Holiday,!?ASC_Time_Up_Late,!?ASC_Time_Down_Early,!?ASC_Time_Down_Late,!?ASC_Mode_Down,!?ASC_Mode_Up
attr rg_ASC_Rolllaeden_Times commands {level => 'pct:selectnumbers,0,5,100,0,lin', \
dim => 'dim:selectnumbers,0,5,99,0,lin',\
position => 'pct:selectnumbers,0,5,99,0,lin',\
ASC_Mode_Down => 'ASC_Mode_Down:always,absent,off',\
ASC_Mode_Up => 'ASC_Mode_Up:always,absent,off',\
ASC_Time_Down_Early => 'ASC_Time_Down_Early:time', \
ASC_Time_Down_Late => 'ASC_Time_Down_Late:time',\
ASC_Time_Up_Early => 'ASC_Time_Up_Early:time', \
ASC_Time_Up_Late =>'ASC_Time_Up_Late:time',\
ASC_Time_Up_WE_Holiday =>'ASC_Time_Up_WE_Holiday:time'}
attr rg_ASC_Rolllaeden_Times room Rollladen
</pre>

=== readingsGroup für die Beschattung ===
[[Datei:Shading.png.png|alternativtext=|mini|ReadingsGroup - Beschattungsbeispiel]]
<pre style="width:65%;word-wrap: break-word;">
defmod RG_test readingsGroup <Gerät>,<InAzi>,<OutAzi>,<MinEle>,<MaxEle>,<Sunny>,<Cloudy>\
(Rollo|Jalousie)_.*..:<{ascAPIget('ShadingAzimuthLeft',$DEVICE)}>,<{ascAPIget('ShadingAzimuthRight',$DEVICE)}>,<{ascAPIget('ShadingMinElevation',$DEVICE)}>,<{ascAPIget('ShadingMaxElevation',$DEVICE)}>,<{ascAPIget('ShadingStateChangeSunny',$DEVICE)}>,<{ascAPIget('ShadingStateChangeCloudy',$DEVICE)}></pre>

=== readingsGroup für FIBARO Roller Shutter FGR-222 Devices ===
{{Randnotiz|RNTyp=g|RNText=Getestet von majestro84, Stand 2019-01-28.
* {{Link2Forum|Topic=92628|Message=897099|LinkText=Forenbeitrag dazu}}
* Die Farbgebung entspricht dem Standard, wenn unter dem Style f18 der Farbpreset ''dark'' gewählt wird}}
[[Bild:ASC Jalousien Times.JPG|thumb|right|Beispiel]]
<pre style="width:65%;word-break: break-all;word-wrap: break-word;">define ASC_Jalousien_Times readingsGroup <Gerät>,<Stand>,<Time_Up_Early>,<Time_Up_WE>,<Time_Up_Late>,<Time_Down_Early>,<Time_Down_Late>,<Mode_Down>,<Mode_Up>,<PartyMode>,<LockOut> (.*_Jalousie.*):position,!?ASC_Time_Up_Early,!?ASC_Time_Up_WE_Holiday,!?ASC_Time_Up_Late,!?ASC_Time_Down_Early,!?ASC_Time_Down_Late,!?ASC_Mode_Down,!?ASC_Mode_Up,!?ASC_Partymode,!?ASC_LockOut

attr ASC_Jalousien_Times commands {position => 'dim:0,10,20,30,35,40,45,50,55,60,65,70,75,80,85,90,95,99',
ASC_Mode_Down => 'ASC_Mode_Down:always,absent,off',
ASC_Mode_Up => 'ASC_Mode_Up:always,absent,off',
ASC_Partymode => 'ASC_Partymode:on,off',
ASC_LockOut => 'ASC_LockOut:soft,hard,off',
ASC_Time_Down_Early => 'ASC_Time_Down_Early:15:00,15:15,15:30,15:45,16:00,16:15,16:30,16:45,17:00,17:15,17:30,17:45,18:00,18:15,18:30,18:45,19:00,19:15,19:30,19:45,20:00,20:15,20:30,20:45,21:00,21:15,21:30,21:45,22:00',
ASC_Time_Down_Late => 'ASC_Time_Down_Late:20:15,20:30,20:45,21:00,21:15,21:30,21:45,22:00,22:15,22:30,22:45,23:00,23:15,23:30',
ASC_Time_Up_Early => 'ASC_Time_Up_Early:05:00,05:05,05:30,05:45,06:00,06:15,06:30,06:45,07:00,07:15,07:30,07:45,08:00,08:15,08:30,08:45,09:00,09:15,09:30,09:45,10:00',
ASC_Time_Up_Late =>'ASC_Time_Up_Late:06:00,06:15,06:30,06:45,07:00,07:15,07:30,07:45,08:00,08:15,08:30,08:45,09:00,09:15,09:30,09:45,10:00',
ASC_Time_Up_WE_Holiday => 'ASC_Time_Up_WE_Holiday:06:00,06:15,06:30,06:45,07:00,07:15,07:30,07:45,08:00,08:15,08:30,08:45,09:00,09:15,09:30,09:45,10:00'}
attr ASC_Jalousien_Times room Jalousien</pre>

[[Bild:ASC Jalousien Level.JPG|thumb|right|Beispiel]]
<pre style="width:65%;word-break: break-all;word-wrap: break-word;"> define Jalousien_Level readingsGroup <Gerät>,<Closed_Pos>,<Open_Pos>,<Comfort_Pos>,<Ventilate_Pos>,<PrivacyDown_Pos>,<Shading_Pos> (.*_Jalousie.*):!?ASC_Closed_Pos,!?ASC_Open_Pos,!?ASC_ComfortOpen_Pos,!?ASC_Ventilate_Pos,!?ASC_PrivacyDown_Pos,!?ASC_Shading_Pos
attr Jalousien_Level commands { ASC_Closed_Pos => 'ASC_Closed_Pos:0,10,20,30,35,40,45,50,55,60,65,70,75,80,85,90,95,99',
ASC_Open_Pos => 'ASC_Open_Pos:0,10,20,30,35,40,45,50,55,60,65,70,75,80,85,90,95,99',
ASC_ComfortOpen_Pos => 'ASC_ComfortOpen_Pos:0,10,20,30,35,40,45,50,55,60,65,70,75,80,85,90,95,99',
ASC_Ventilate_Pos => 'ASC_Ventilate_Pos:0,10,20,30,35,40,45,50,55,60,65,70,75,80,85,90,95,99',
ASC_PrivacyDown_Pos => 'ASC_PrivacyDown_Pos:0,10,20,30,35,40,45,50,55,60,65,70,75,80,85,90,95,99',
ASC_Shading_Pos => 'ASC_Shading_Pos:0,10,20,30,35,40,45,50,55,60,65,70,75,80,85,90,95,99'}
attr Jalousien_Level room Jalousien</pre>

== Einrichtungsbeispiel (nach Sonnenstand) ==
=== Ziel und Vorgaben ===
Es sollen die Rollläden und Jalousien innerhalb bestimmter zeitlicher Perioden sonnenstandsabhängig geöffnet und geschlossen werden. An den Wochenenden und an Ferientagen soll etwas später geöffnet werden. Es sind Tür- und Fensterkontakte vorhanden (Türkontakte: twoState, Fensterkontakte: threeState), wobei bei jeder Öffnung ein eventuell geschlossener Rollladen geöffnet werden soll. Bei allen Rollladenaktoren, Tür- und Fensterkontakten handelt es sich um CUL_HM-Geräte.

=== Vorarbeiten ===
Im global-Device sind Angaben zu latitude und longitude vorhanden, holiday2we wie folgt<ref>''ferien'' ist eine automatisiert erstellte holiday-Datei nach diesem {{Link2Forum|Topic=85759|Message=885883|LinkText=Foren-Beitrag}}.</ref>:
attr global holiday2we bw,ferien
Weitere Angaben werden zunächst nicht benötigt, das Astro-Device wird erst in der Beschattungskonfiguration definiert.
Dann erfolgt das ''Define des ASC-Devices'' wie oben beschrieben:
<code>define Rollladenautomatik AutoShuttersControl</code>
Folgen die einzubindenden Rollladenaktoren einem einheitlichen Namensschema, können diese sodann z.B. mit
attr (Jalousie|Rollladen)_.* ASC 2
auf einen Rutsch mit dem passenden ASC-Typ gekennzeichnet werden.

{{Hinweis|Achtung: Das AutoShuttersControl-Device selbst darf kein ASC-Attribut bekommen!}}

Dann werden mit
set Rollladenautomatik scanForShutters
die nachfolgend weiter zu bearbeitenden Attribute angelegt.
=== Schließen morgens und abends ===
{{Randnotiz|RNTyp=g|RNText=Alternative: Fahren nach brightness:
Soll insgesamt oder an einzelnen Rollläden helligkeitsgesteuert gefahren werden, muß zentral oder für jeden Rollladen ein Helligkeitssensor definiert und die Helligkeitsgrenzwerte festgelegt sein (''ASC_BrightnessSensor'' etc.), bei deren Überschreitung geöffnet bzw. Unterschreitung geschlossen werden soll.}}
==== Konfiguration des ASC-Devices ====
Sonnenstandsabhängige Fahrzeiten werden wie folgt aktiviert:
<pre>
attr Rollladenautomatik ASC_autoAstroModeEvening CIVIL
attr Rollladenautomatik ASC_autoAstroModeMorning CIVIL
</pre>
Aus der Angabe ''CIVIL'' und den Vorgaben in den einzelnen Rollladen wird dabei mit Hilfe von [[SUNRISE_EL]] die effektive Fahrzeit berechnet, dort finden sich auch weitere Hinweise, zu den meisten anderen Optionen für die ersten beiden Attribute.
Bei allen Fensteröffnungen soll auf eine Lüften-Position gefahren werden, also schalten wir diese Funktion ebenfalls zentral an<ref>Sonst wird bei threeState-Sensoren nur bei ''tilted'' auf die in ''ASC_Ventilate_Pos'' gefahren.</ref>:
attr Rollladenautomatik ASC_autoShuttersControlComfort on
Zuletzt legen wir noch einen Temperatur-Sensor fest. Dieser wird beim Frostschutz sowie bei der Beschattung berücksichtigt.
<pre>
attr Rollladenautomatik ASC_tempSensor Aussentemperatur_Nord:temperature
attr Rollladenautomatik ASC_freezeTemp 3
</pre>{{Hinweis|Achtung: Für jede weitere Sensor-Information (z.B. zu Regen oder Wind) muß ein eigenes Device verwendet werden. Sollen unterschiedliche Readings desselben Sensors ausgewertet werden, müssen diese in ein eigenes Device übertragen werden, z.B. über einen readingsProxy mit gesetztem event-on-update-reading-Attribut (sonst triggert dieser nicht bei Aktualisierung des Readings)!}}

tbd:
* Rain
* Wind
==== Konfiguration der Rollladendevices ====
{{Hinweis|Positionen dürfen sich innerhalb eines Rollos nicht überschneiden - Auch ASC_Closed_Pos 100 ASC_Shading_Pos 98 ASC_ComfortOpen_Pos 97 usw... sind bereits unterschiedliche Positionen.}}

===== Fahrzeiten =====
Zur Konfiguration der Fahrzeiten bietet es sich an, eine ReadingsGroup zu nutzen, wie unter [[#Hilfsmittel|Hilfsmittel]] dargestellt. Alternativ kann man die Zeiten auch manuell in den einzelnen Rollläden hinterlegen.
===== Bewohner =====
Wird ein Raum von einer oder mehreren bestimmten Person/en bewohnt oder gibt es ein Sammel-Gerät für mehrere Bewohner, kann dies mit den Attributen ''ASC_Roommate_Device'' und ''ASC_Roommate_Reading'' einem Rollladen zugeordnet werden. Ist einer der Bewohner ''asleep'', wird morgens erst geöffnet, wenn auch der letzte Roommate nicht mehr ''asleep'' ist.
===== Fensterkontakte =====
Dann werden ggf. vorhandene Fensterkontakte mit ''ASC_WindowRec'' zugeordnet und der Sensortyp mit ''ASC_WindowRec_subType'' festgelegt. Im Falle von threeState-Sensoren wird das übergreifende ''ASC_autoShuttersControlComfort'' beachtet, wobei dann bei vollständiger Öffnung des Fensters auf den in ''ASC_ComfortOpen_Pos'' festgelegten Wert gefahren wird.
===== Frostschutz =====
Zuletzt können die Attribute ''ASC_Antifreeze'' und ''ASC_Antifreeze_Pos'' festgelegt werden, wenn die Frostschutzfunktion aktiviert werden soll.

=== Beschattung ===
==== Konfiguration des ASC-Devices ====
Im ASC DEVICE das Reading "controlShading" auf ''on'', sowie ein Astro/Twilight Device im Attribut "ASC_twilightDevice" und das Attribut "ASC_tempSensor" definieren.

==== Konfiguration der Rollladendevices ====
Es wird ein Helligkeitssensor als Attribut "ASC_BrightnessSensor" benötigt. Wird der Sensor nur für die Beschattung verwendet, ist der Wert DEVICENAME[:READING] ausreichend.
Alle weiteren Attribute sind optional und wenn nicht gesetzt mit Default-Werten belegt. Sie sollten entsprechend der Gegebenheiten angepasst werden. Die Werte für die Fensterposition und den Vor-/Nachlaufwinkel ''(ASC_Shading_InOutAzimuth)'' sowie die Grenzwerte für <code>''ASC_shading_StateChange_SunnyCloudy''</code> sind besonders wichtig.

==== Bedingungen ====
Damit die Beschattung startet müssen '''alle''' Bedingungen erfüllt sein. Entschattet wird, sobald '''eine''' der Bedingungen wegfällt und die Zeit entsprechend <code>ASC_Shading_WaitingPeriod</code> abgelaufen ist.

Der Sonnensensor <ASC_BrightnessSensor> muss mindestens zwei Messwerte geliefert haben, bevor das ASC-Modul in die Beschattungsposition fährt! Beim (zeitlich) ersten Messwert wird der Zustand ''in-reserved'' gesetzt. Erst beim zweiten Messwert wechselt der Zustand nach ''in shading''. Die Anzahl der berücksichtigten Messwerte ist abhängig vom "moving average window", der mit dem dritten Parameter des Attributs ''ASC_Shading_StateChange_SunnyCloudy'' konfiguriert wird.

'''Von Standardwerten ausgehend ist nachfolgender Ablauf angestrebt:'''
# Ein Event vom Astro oder Helligkeits Device kommt -> sind alle Werte innerhalb des Arbeitsbereiches, ändert sich der ASC Info-Zustand im Rollo von xx auf „in reserved“ (Beschattung vorbereitet)
# Ein erneutes Event vom Astro oder Helligkeits Device kommt -> Überprüfung der Werte -> sind diese weiterhin gegeben folgt der Wechsel von „in reserved“ auf „in“ (Beschattung aktiv)
# Bei Verwendung von ''ASC_Shading_StateChange_SunnyCloudy'' ist zu beachten, dass ein Durchschnitt über die letzten drei Brightness Events gerechnet wird. Möchte man das vermeiden muss man SUNNY:CLOUDY 1[2] setzen.
# Die Zeiten ''ASC_Shading_WaitingPeriod'' und ''ASC_BlockingTime_afterManual'' können hier zusätzlich für eine Verzögerung sorgen.
'''Wichtig zu beachten:''' Es müssen immer mehrere (mind. 2) Events für den Betrieb erfolgen. In den Standardeinstellungen vom Astro Modul erfolgt dieses z.B. nur 1 x pro Stunde. Kommt also ein Helligkeits-Event auch nur 1x pro Stunde, könnte es 2 Std dauern, bis die Beschattungsfunltion greift.

Wenn das Rollo einmal aus der Beschattung manuell (im Rollo Device muss bei ''ASC_ShuttersLastDrive manuel'' stehen gefahren wurde wird das Rollo erst wieder nach einer Entschattung und erneuter Beschattung gefahren. Also es muss einmal shading out kommen und beim nächsten shading in fährt er dann wieder.

=== Weitere Funktionen ===
==== WeekendHoliday Funktion im Brightnessbetrieb ====
Am Wochenende oder Feiertag und wenn am ASC-Device sunriseTimeWeHoliday aktiviert sowie im Rollo das Attribut ASC_Time_Up_WE_Holiday gesetzt sind, wird zur angegebenen ASC_Time_Up_WE_Holiday Zeit das Rollo geöffnet, ungeachtet des Brightnesswertes.

==== Privacy ====
Werden hierfür Werte festgelegt, werden die betreffenden Rollläden die festgelegte Zeit/Helligkeit vor dem abendlichen Schließen vorab teilweise geschlossen. Dies kann z.B. gewünscht sein, um Rollläden zur Straße hin mit viel Fußgängerverkehr zwar nicht vollständig abzudunkeln, aber gleichzeitig zu verhindern, dass von außen in Wohnräume geschaut werden kann, sobald dort das Licht angeschaltet wird

==== BlockingTime====
Bewirkt, dass nach einer manuellen Fahrt, eine vom ASC Modul initiierte Fahrt zunächst ausgesetzt wird, bis die im Attribute angegebene Zeit überschritten ist. Erst dann wird eine vom ASC Modul initiierte Fahrt tatsächlich durchgeführt.
Genau so wird ein Hochfahren eines Rollos durch das ASC Modul nicht mehr ausgeführt, wenn es innerhalb der Zeit von ASC_BlockingTime_beforNightClose und das Runterfahren wird nicht mehr erfolgen, wenn es innerhalb von ASC_BlockingTime_beforDayOpen ist.
Beispiel: Meine Tochter geht früh außer Haus und Ihre Rollos sind nicht hochgefahren. Diese fahren auch nicht mehr hoch, da die ausschließlich bei home (anwesend) fahren sollen. Nun kommt sie am Nachmittag um 16:23 Uhr nach Hause. Eigentlich sollten nun die Rollos fahren. Doch die Sonnenuntergangsfahrt (schließen) wäre schon 16:51 Uhr und damit innerhalb der 3600 ASC_BlockingTime_beforNightClose. Die Rollos bleiben also unten. Es lohnt sich für die paar Minuten einfach nicht mehr.

==== wiggle====
Mit einem <code>set <ASC-Device> wiggle</code> können alle Rollladen mit einem entsprechenden Attribut zu einer kurzen Fahrt veranlasst werden, nach Ablauf von einer Minute wieder um denselben Wert zurück. Dabei wird jeweils in die Richtung gefahren, die den weiteren Weg ermöglicht. Wenn also zu 70% geschlossen ist, wird der Rollladen hoch fahren.
==== Partymode ====
Dieser wird am ASC-Device selbst aktiviert mittels <code>set <ASC-Device> partyMode on</code>. Alle Rollladen-Devices, welche das Attribut ''ASC_Partymode'' auf ''on'' gestellt haben, werden nicht mehr gesteuert. Der letzte Schaltbefehl, der durch ein Fensterevent oder Bewohnerstatus an die Rollläden gesendet wurde, beim Beenden des Modus durch <code>set ASC-Device partyMode off</code> ausgeführt.
==== lock-out ====
Man kann mit dem Befehl <code> set <ASC-Device> hardLockOut</code> auf einen Schlag alle Rollos sperren welche <code> attr <ROLLO-Device> ASC_LockOut hard</code> gesetzt haben.
Das ist dafür gedacht, wenn Du eine gewisse Zeit den Rolloaktor sperren willst. Zum Beispiel das die Kinder nicht schalten sollen.

== Sonstige Hinweise und Problemlösungen ==
* Werden Attribute geändert, kann es vereinzelt vorkommen, dass das ASC-Modul dies nicht mitbekommt und das tatsächliche Verhalten nicht den Erwartungen entspricht. In so einem Fall empfielt es sich, das NOTIFYDEV nochmals aufbauen zu lassen. Dazu werden zunächst mit <code>set <ASC-Modul> expert 1</code> erweiterte Informationen bezüglich des NotifyDevs unter set und get aktiviert und anschließend ein <code>set <ASC-Modul> createNewNotifyDev</code> ausgeführt.

* Hin und wieder berichten Nutzer davon, wenn Sie die ''Privacy Funktion'' nutzen, dass sich im NOTIFYDEV anstelle des Device Namen ein Raumname befindet. Diese Problem kann damit gelöst werden, dass in dem betroffenen '''Rollo Device''' das Atribut <code>attr event-on-change .*</code> gesetzt wird.
'''Wichtig!''' Nicht verwechseln mit dem ASC Device dort darf <code>attr event-on-change</code> '''nicht''' gesetzt sein!
* Wenn mehrere Rollladen gleichzeitig den Fahrbefehl bekommen, kann es (z. B. bei zwave) dazu kommen, dass ein Rollladen seinen Befehl nicht bekommt. Dies kann durch eine zeitverzögerte Aussendung der Fahrbefehle vermieden werden. Dazu in den jeweiligen Rollo Devices das Attribut ASC_Drive_DelayStart wie folgt benutzen im: ersten Rollo Device braucht das Attribut nicht gesetzt werden, im zweiten Rollo Device im Attribut ASC_Drive_DelayStart dann 4 Sekunden eintragen, im dritten Rollo Device im Attribut ASC_Drive_DelayStart 8 Sekunden eintragen, usw. Ein Abstand von 3-4 Sekunden ist dabei zielführend.

==== Spezielle Hardware ====
{{Link2Forum|Topic=101182|LinkText="Thread zu getesteter Hardware im Forum"}}

== Weblinks ==
* {{Link2Forum|Topic=92628|LinkText="Thread zum Modul im Forum"}}
* {{Link2Forum|Topic=90751|LinkText="Thread zur Entwicklung im Forum"}}
* {{Link2Forum|Topic=73964|LinkText="Thread zu den Scripten von user cluni"}}, die der Entwicklung des Moduls zugrunde liegen
* Daten zum Sonnenstand z.B. hier https://www.sonnenverlauf.de/

<references />

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

Datei:Shading.png.png

2021-06-14T19:36:59Z

TomLee:

ReadingsGroup -Beschattungsbeispiel

AutoShuttersControl

2021-06-14T19:34:06Z

TomLee: Änderung 35808 von TomLee (Diskussion) rückgängig gemacht.

{{Infobox Modul
|ModPurpose=Steuerung von Rollläden
|ModCategory=Automatisierung
|ModType=d
|ModForumArea=Automatisierung
|ModTechName=73_AutoShuttersControl.pm
|ModOwner=CoolTux ({{Link2FU|13684|Forum}}/[[Benutzer Diskussion:CoolTux|Wiki]])}}
Mit [[AutoShuttersControl]] oder kurz '''ASC''' können Rollläden automatisch hoch und herunter gefahren werden. Zum Beispiel Öffnen bei Sonnenaufgang, Schließen bei Sonnenuntergang, Beschatten abhängig vom Sonnenstand oder Anfahren von Lüftungspositionen nach Öffnen des zugehörigen Fensters.

== Basics ==
{{Hinweis|Das Modul befindet sich derzeit noch in der Entwicklung; der derzeit aktuelle Stand ist diesem {{Link2Forum|Topic=112325|LinkText="Thread im Forum"}} zu entnehmen.}}
Als Voraussetzung sollten folgende FHEM-Devices bereits vorhanden sein:
* Rollläden,
* Fensterkontakte,
* Bewohnerstatus auf Basis von Residents/Roomates in englisch. Ersatzweise andere Devices, z.B. Dummys, welche als ''state'' ''home'', ''absent'', ''asleep'', ''gotosleep'' und ''awoken'' setzen sowie ein Reading ''lastState''.
* Helligkeitssensor (Steuerung nach Helligkeit für Beschattung)
* Ein Device zur Bestimmung des Sonnenstands (nur für Beschattung). Unterstützt werden derzeit [[Modul Astro|Astro]] und [[Twilight]]<ref>Dabei müssen ggf. in [[Global|global]] auch Angaben zu ''longitude'' und ''latitude'' vorhanden sein</ref>.
* Wenn Feiertage berücksichtigt werden sollen: Ein oder mehrere {{Link2CmdRef|Anker=holiday2we|Lang=en|Label=holiday2we}}-Angaben in [[Global|global]] samt entsprechender [[Wochenende, Feiertage und Schulferien#Feiertage mittels holiday-Datei|holiday]]-Dateien<ref>Es kann auch z.B. ein Dummy-Device verwendet werden, dieses sollte dann aber neben dem eigentlichen Feiertags-''state'' auch in einem Reading ''tomorrow'' Angaben zu anstehenden Feiertagen enthalten.</ref> <ref>Bitte verfahren Sie entsprechend, wenn Urlaubs- oder Ferientage wie Feiertage behandelt werden sollen.</ref>.

Die Einrichtung des Moduls bzw. dessen Funktionalität erfolgt in mehreren Schritten:
* Definition des ASC-Devices
* Einstellung zentraler Vorgaben am ASC-Device
* Markieren der zukünftig zu steuernden Rollladen-Devices
* Einbinden der Rollladen-Devices in das ASC-Device
* Einstellen der individuellen Vorgaben je Rollladen (am Rollladen-Device)
Dabei geht man am einfachsten schrittweise vor und erweitert die Funktionalität nach und nach um die gewünschten Funktionen. Dann benötigt man jeweils nur einen kleinen Teil der vielen per Attribut einstellbaren Optionen, und kann die Auswirkungen der jeweiligen Änderung besser nachvollziehen.

== Einrichtung ==
{{Hinweis|ASC kann auch verwendet werden, um lediglich Teilaufgaben der Rollladensteuerung zu erfüllen, also z.B. nur das morgendliche Öffnen der Rollläden. Allerdings geht dabei ein erheblicher Teil des Komforts verloren, der dadurch entsteht, dass die Steuerung innerhalb der vollintegrierten Lösung jeweils nachvollzieht, aus welchem Grund eine Fahrt erfolgt war und dies ggf. bei der nächsten Aktion berücksichtigt.}}

=== Vorbereitung ===
Zunächst sollten die in den [[#Basics|Basics]] beschriebenen Geräte vorhanden und funktionsfähig sein.

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

=== Einstellung zentraler Vorgaben ===
Mit Attributen am ASC-Device wird das Verhalten des ASC-Devices eingestellt, z.B. Vermeiden von morgendlichen oder abendlichen Fahrten, Frostschutzfunktion bei Gefahr von festgefrorenen Rollläden oder die Reaktion auf Fensterkontakte. Details sind der Commandref zu entnehmen.
Diese Attribute können jederzeit geändert werden.

=== Auswählen zu steuernder Rollladen-Devices ===
Für jeden vom ASC-Device kontrollierten Rollladen muss das globale Attribut ''ASC'' gesetzt werden. Das steht nach dem Definieren des ASC-Devices zur Verfügung. Das Attribut ist mit 1 oder 2 festzulegen:
# Je ''kleiner'' der <code>pct</code> Wert um so weiter ist der Rollladen geschlossen. Typischerweise ist dann 0 ''offen'' und 100 ''geschlossen''. Dies ist z.B. die passende Wahl für ROLLO-Devices
# Je ''größer'' der <code>pct</code> Wert desto weiter ist der Rollladen geschlossen, also ''offen'' für <code>set <name> pct 100</code>. Typische Vertreter dieses Typs sind HomeMatic (CUL_HM-) Geräte oder die Shelly2-Aktoren.

Basierend auf dem Parameter leitet das Modul bestimmte Voreinstellungen (''defaults'') für den Rollladen ab. Es genügt daher, nur jeweils die Einstellungen zu verändern, die anders gewünscht werden oder für den Rollladenaktortyp anders sein müssen (z.B. ''dim 99'' für vollständiges Öffnen eines ZWave-Aktors).
{{Hinweis|Das Vorstehende gilt jeweils für den nicht-invertierten Modus! Wer z.B. ein HomeMatic-Gerät mit ''levelinverse'' betreibt, sollte ''ASC'' auf "1" setzen usw.. Maßgeblich ist letztlich nur die Frage, ob die Offen-Positionsangabe nummerisch kleiner oder größer als die Geschlossen-Positionsangabe ist; die konkreten Zahlenwerte spielen dabei keine Rolle, die Angabe ''position'' oder ''pct'' kann auch später über ein weiteres Attribut passend eingestellt werden.}}

=== Einbinden in das ASC-Device ===
Nachdem das ASC Attribut für die betreffenden Rollladen-Devices gesetzt ist, muss mit <code>set <name> scanForShutters</code> ein Suchlauf gestartet werden, mit dem diese Rollläden in die Steuerungslogik eingebunden werden.

=== Einstellen der individuellen Vorgaben ===
Die gefundenen Rollladen-Devices erhalten weitere Attribute, mit denen für den jeweiligen Rollladen benötigte Einstellungen vorgenommen werden.
Diese Attribute sind in der commandref beschrieben.

== Readings ==
===Readings im zentralen ASC-Device ===

{| class="wikitable"
|-
! Name !! Datentyp/<BR />Wertebereich !! Bedeutung
|-
|..._nextAstroTimeEvent || || Zeit wird abhängig von der eingestellten Attribute ASC_Time_Up/ASC_Time_Down angezeigt. Bei ''astro'' die Uhrzeit des Sonnenauf- oder Sonnenuntergang, bei ''time'' und ''brightness'' die Zeit aus ASC_Time_Up_Early/ASC_Time_Down_Late pro Rollonamen
|-
|..._lastPosValue || || Position pro Rollonamen, bevor ASC die Rollläden verfahren hat.
|-
|..._PosValue || ||aktuelle Position pro Rollonamen.
|-
|ascEnable||on, off ||globale ASC Steuerung bei den Rollläden aktiv oder inaktiv
|-
|controlShading||on, off ||globale Beschattungsfunktion aktiv oder inaktiv
|-
|hardLockOut || on, off ||Status des hardwareseitigen Aussperrschutzes / gilt nur für Rollläden mit dem Attribut bei denen das Attributs ASC_LockOut entsprechend auf hard gesetzt ist.
|-
|selfDefense || on, off ||globale Selbstschutzfunktion aktiv oder inaktiv
|-
|partyMode ||on, off || globaler Partymodus aktiv oder inaktiv
|-
|state || ||Status des ASC-Devices: active, enabled, disabled oder weitere Statusinformationen wie z.B. Grund der letzen Fahrt.
|-
|room_... || ||Auflistung aller Rollläden, welche in den jeweiligen Räumen gefunden wurden, Bsp.: room_Schlafzimmer,Terrasse.
|-
|sunriseTimeWeHoliday|| on,off ||globale Wochenendunterstützung aktiv oder inaktiv.
|-
|userAttrList || rolled out ||Das ASC-Modul verteilt an die gesteuerten Rollladen-Geräte diverse Benutzerattribute (userattr). In diesem Reading kann der Status dieser Verteilung geprüft werden.

|}

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

{| class="wikitable"
|-
! Name !! Bedeutung
|-
|ASC_Enable ||Status von ASC_Enable (on,off).
|-
|ASC_ShuttersLastDrive ||Grund der letzten Fahrt des Rollladens.
|-
|ASC_Time_DriveDown ||Zeit wird abhängig von der eingestellten Attribute ASC_Time_Down angezeigt. Bei astro die Uhrzeit des Sonnenuntergangs, bei time und brightness die Zeit aus /ASC_Time_Down_Late
|-
|ASC_Time_DriveUp ||Zeit wird abhängig von der eingestellten Attribute ASC_Time_Up angezeigt. Bei astro die Uhrzeit des Sonnenaufgangs, bei time und brightness die Zeit aus /ASC_Time_Up_Early
|}

==set- und get-Befehle für das ASC-Device==
=== set-Anweisungen ===
{| class="wikitable"
|-
! Name !! Datentyp/<BR />Wertebereich !! Beschreibung
|-
|advDriveDown ||on, off ||Nachholen der durch ASC_Adv on ausgesetzten Fahrten.
|-
|ascEnable||on, off ||Aktiviert oder deaktiviert die globale ASC-Steuerung.
|-
|controlShading||on, off ||Aktiviert oder deaktiviert die globale Beschattungssteuerung.
|-
|createNewNotifyDev || ||Legt die interne Struktur für NOTIFYDEV neu an. (Diese Funktion steht nur zur Verfügung, wenn Attribut ASC_expert auf 1 gesetzt ist.)
|-
|hardLockOut ||on, off ||Aktiviert den hardwareseitigen Aussperrschutz für die Rollläden, bei denen das Attributs ASC_LockOut auf hard gesetzt ist. Mehr Informationen in der Beschreibung bei den Attributen für die Rollladengeräten.
|-
|partyMode ||on, off ||Aktiviert den globalen Partymodus. Alle Rollladen-Geräten, in welchen das Attribut ASC_Partymode auf on gesetzt ist, werden durch ASC nicht mehr gesteuert. Der letzte Schaltbefehl, der bspw. durch ein Fensterevent oder Wechsel des Bewohnerstatus an die Rollläden gesendet wurde, wird beim Deaktivieren des Partymodus ausgeführt
|-
|renewAllTimer || ||Erneuert bei allen Rollläden die Zeiten gemäß ASC_UP/ASC_DOWN und setzt die internen Timer neu.
|-
|renewTimer || ||Erneuert bei dem ausgewählten Rollladen die Zeiten gemäß ASC_UP/ASC_DOWN und setzt die internen Timer neu.
|-
|scanForShutters || ||Sucht alle FHEM Devices mit dem Attribut ''ASC'' ''1'' oder ''2'' und legt diese im ASC-Modul an
|-
|selfDefence ||on, off||Aktiviert bzw. deaktiviert die Selbstschutzfunktion. Beispiel 1: Wenn das Residents-Gerät ''gone'' meldet, alle Rollläden dann heruntergefahren. Beispiel 2 : Wenn das Residents-Gerät ''absent'' meldet, das Attribut ASC_ShuttersPlace=terrace ist und ein Fenster im Haus noch geöffnet ist, so wird an diesem Fenster der Rollladen dann heruntergefahren.
|-
|shutterASCenableToggle || ||Aktivieren oder deaktivieren der ASC Kontrolle des einzelnen Rollladens.
|-
|sunriseTimeWeHoliday || on,off ||Aktiviert die Wochenendunterstützung. Dann wird das Attribut ASC_Time_Up_WE_Holiday am Rollladen-Device beachtet.
|-
|wiggle ||||Bewegt einen oder mehrere Rollläden um einen definierten Wert (Default: 5%) und nach einer Minute wieder zurück in die Ursprungsposition. Diese Funktion könnte bspw. zur Abschreckung in einem Alarmsystem eingesetzt werden.
|-
|||||
|}

=== get-Anweisungen ===

{| class="wikitable"
|-
! Name !! Beschreibung
|-
| showNotifyDevsInformations ||Zeigt eine Übersicht der abgelegten NOTIFYDEV Struktur. Diese Funktion wird für das Debugging genutzt. Hierzu ist das Attribut ASC_expert = 1 zu setzen.
|}

== Attribute ==
{{Hinweis|Die Attributnamen haben sich teilweise geändert, nachfolgend ist der Stand von Modulversion v0.8.x wiedergegeben.}}
{{Hinweis|In der commandref findet sich häufig die Schreibweise <code><nowiki>ASC_BrightnessSensor Sensorname[:brightness [400:800]]</nowiki></code>. Dabei sind die Angaben in den eckigen Klammern optional. Dies müssen also nicht angegeben werden, stattdessen verwendet das Modul dann Standardwerte (siehe cref), die in der cref zu findenden Angaben entsprechen dabei den defaults. Werden Werte angegeben, sind die eckigen Klammern '''wegzulassen'''! Beispiel: <code>ASC_BrightnessSensor hm_motion_1 70:100</code> würde das brightness-Reading des Sensors hm_motion_1 verwenden und einen morgendlichen Schwellenwert von 70 bzw. 100 für abends.}}
===Attribute direkt am ASC-Device ===

{| class="wikitable"
|-
! Name !! Datentyp/<BR />Wertebereich !! Default-Wert !! Beschreibung
|-
|ASC_autoAstroModeEvening || ||REAL, CIVIL, NAUTIC, ASTRONOMIC oder HORIZON ||nach welchem ASTRO-Modus soll die Abendfahrt berechnet werden
|-
|ASC_autoAstroModeEveningHorizon || - 9 bis 9 || 0|| Höhe über dem Horizont. Wird nur berücksichtigt, wenn im Attribut ASC_autoAstroModeEvening der Wert HORIZON ausgewählt wurde.
|-
|ASC_autoAstroModeMorning || ||REAL, CIVIL, NAUTIC, ASTRONOMIC oder HORIZON || nach welchem ASTRO-Modus soll die Morgendfahrt berechnet werden
|-
|ASC_autoAstroModeMorningHorizon || - 9 bis 9|| 0|| Höhe über dem Horizont. Wird nur berücksichtigt, wenn im Attribut ASC_autoAstroModeMorning der Wert HORIZON ausgewählt wurde.
|-
|ASC_autoShuttersControlComfort ||on, off || off ||schaltet die Komfortfunktion an. Bedeutet, dass ein Rollladen mit einem threestate-Sensor am Fenster beim Öffnen in eine Offenposition fährt. Hierzu muss beim Rollladen das Attribut ASC_ComfortOpen_Pos entsprechend konfiguriert sein.
|-
|ASC_autoShuttersControlEvening ||on, off || ||Aktiviert die automatische Steuerung durch das ASC-Modul am Abend.
|-
|ASC_autoShuttersControlMorning ||on, off || ||Aktiviert die automatische Steuerung durch das ASC-Modul am Morgen.
|-
|ASC_blockASCDrivesAfterManual ||0, 1 || ||wenn dieser Wert auf 1 gesetzt ist, dann werden Rollläden vom ASC-Modul nicht mehr gesteuert, wenn zuvor manuell eingegriffen wurde. Voraussetzung hierfür ist jedoch, dass im Reading ASC_ShuttersLastDrive der Status manual enthalten ist und sich der Rollladen auf eine unbekannte (nicht in den Attributen anderweitig konfigurierte) Position befindet.
|-
|ASC_brightnessDriveUpDown || || || Werte (z.B. Lux) bei dem Schaltbedingungen für Sonnenauf- und -untergang geprüft werden sollen. Diese globale Einstellung kann durch die WERT-MORGENS:WERT-ABENDS Einstellung von ASC_BrightnessSensor im Rollladen selbst überschrieben werden.
|-
|ASC_debug ||0, 1 || 0||Aktiviert die erweiterte Logausgabe für Debugausgaben (nur nach Aufforderung nutzen)
|-
|ASC_expert ||0, 1 ||0 ||ist der Wert 1, so werden erweiterte Informationen bezüglich des NotifyDevs unter ''set und get'' angezeigt
|-
|ASC_freezeTemp ||-5 bis 5 || ||Temperatur, ab welcher der Frostschutz greifen soll und der Rollladen nicht mehr fährt. Der letzte Fahrbefehl wird gespeichert.
|-
|ASC_rainSensor || || ||DEVICENAME[:READINGNAME] MAXTRIGGER[:HYSTERESE] [CLOSEDPOS] - der Inhalt ist eine Kombination aus Devicename, Readingname, Wert ab dem getriggert werden soll, Hysterese Wert ab dem der Status Regenschutz aufgehoben werden soll und der "wegen Regen geschlossen Position".
|-
|ASC_residentsDev || || ||DEVICENAME[:READINGNAME] - der Inhalt ist eine Kombination aus Devicenamen und Readingnamen des Residents-Device der obersten Ebene (z.B. rgr_Residents:state)
|-
|ASC_shuttersDriveDelay || || ||maximale Zufallsverzögerung in Sekunden bei der Berechnung der Fahrzeiten. 0 bedeutet keine Verzögerung
|-
|ASC_tempSensor || || ||DEVICENAME[:READINGNAME] - der Inhalt ist eine Kombination aus Device und Reading für die Außentemperatur
|-
|ASC_twilightDevice || || ||das Device, welches die Informationen zum Sonnenstand liefert. Wird unter anderem für die Beschattung verwendet.
|-
|ASC_windSensor || || ||DEVICE[:READING] - Sensor für die Windgeschwindigkeit. Kombination aus Device und Reading.
|-
| || || ||
|-
| || || ||
|}

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

{| class="wikitable"
|-
! Name !! Datentyp/<BR />Wertebereich !! Default-Wert !! Beschreibung
|-
|ASC || 0, 1, 2|| ||"kein Anlegen der Attribute beim ersten Scan bzw. keine Beachtung eines Fahrbefehles",1 = "Inverse oder Rollo - Bsp.: Rollo oben 0, Rollo unten 100 und der Befehl zum prozentualen Fahren ist position",2 = "Homematic Style - Bsp.: Rollo oben 100, Rollo unten 0 und der Befehl zum prozentualen Fahren ist pct
|-
|ASC_Adv || on, off||||bei on wird das runterfahren des Rollos während der Weihnachtszeit (1. Advent bis 6. Januar) ausgesetzt! Durch set <ASCDEVICE> advDriveDown werden alle ausgesetzten Fahrten nachgeholt.
|-
|ASC_Antifreeze ||off, soft, hard, am, pm || ||Frostschutz, wenn soft fährt der Rollladen in die ASC_Antifreeze_Pos, bei hard/am/pm wird gar nicht oder innerhalb der entsprechenden Tageszeit nicht gefahren
|-
|ASC_Antifreeze_Pos || || ||Position des Rolllades die angefahren werden soll, wenn der Fahrbefehl komplett schließen lautet, aber der Frostschutz aktiv ist !!!Verwendung von Perlcode ist möglich, dieser muss in {} eingeschlossen sein. Rückgabewert muss eine positive Zahl/Dezimalzahl sein!!!
|-
|ASC_autoAstroModeEvening ||REAL, CIVIL, NAUTIC, ASTRONOMIC oder HORIZON || ||nach welchem ASTRO-Modus soll die Abendfahrt berechnet werden
|-
|ASC_autoAstroModeEveningHorizon || - 9 bis 9 || 0|| Höhe über dem Horizont. Wird nur berücksichtigt, wenn im Attribut ASC_autoAstroModeEvening der Wert HORIZON ausgewählt wurde.
|-
|ASC_autoAstroModeMorning ||REAL, CIVIL, NAUTIC, ASTRONOMIC oder HORIZON || || nach welchem ASTRO-Modus soll die Morgendfahrt berechnet werden
|-
|ASC_autoAstroModeMorningHorizon || - 9 bis 9|| 0|| Höhe über dem Horizont. Wird nur berücksichtigt, wenn im Attribut ASC_autoAstroModeMorning der Wert HORIZON ausgewählt wurde.
|-
|ASC_BlockingTime_afterManual || ||1200 ||wie viel Sekunden soll die Automatik nach einer manuellen Fahrt aussetzen
|-
|ASC_BlockingTime_beforeDayOpen || ||3600 ||wie viel Sekunden vor dem morgendlichen öffnen soll keine schließen Fahrt mehr stattfinden.
|-
|ASC_BlockingTime_beforeNightClose || ||3600 ||ie viel Sekunden vor dem nächtlichen schließen soll keine öffnen Fahrt mehr stattfinden.
|-
|ASC_BrightnessSensor || ||none ||DEVICE[:READING] WERT-MORGENS:WERT-ABENDS / 'Sensorname[:brightness [400:800]]' Angaben zum Helligkeitssensor mit (Readingname, optional) für die Beschattung und dem Fahren der Rollladen nach brightness und den optionalen Brightnesswerten für Sonnenauf- und Sonnenuntergang
|-
|ASC_Closed_Pos || ||default Vorgabe ist abhängig vom Attribut ''ASC''||in 10er-Schritten von 0 bis 100
wird angefahren wenn SelfDefense aktiv ist
|-
|ASC_ComfortOpen_Pos || || || in 10er Schritten von 0 bis 100 !!! Die eingestellte Position wird bei einem threestate Sensor angefahren. Verwendung von Perlcode ist möglich, dieser muss in {} eingeschlossen sein. Rückgabewert muss eine positive Zahl/Dezimalzahl sein!!!
|-
|ASC_Down || time, astro, brightness, roommate || astro||bei ''astro'' wird Sonnenuntergang berechnet, bei time wird der Wert aus ASC_Time_Down_Early als Fahrzeit verwendet und bei brightness muss ASC_Time_Down_Early und ASC_Time_Down_Late korrekt gesetzt werden. Der Timer läuft dann nach ASC_Time_Down_Late Zeit, es wird aber in der Zeit zwischen ASC_Time_Down_Early und ASC_Time_Down_Late geschaut, ob die als Attribut im Moduldevice hinterlegte ASC_brightnessDriveUpDown der Down Wert erreicht wurde. Wenn ja, wird der Rollladen runter gefahren.
|-
|ASC_DiveUpMaxDuration || || 60||die Dauer des Hochfahrens des Rollladens plus 5 Sekunden
|-
|ASC_Drive_Delay || || -1|| maximaler Wert für einen zufällig ermittelte Verzögerungswert in Sekunden bei der Berechnung der Fahrzeiten, 0 bedeutet keine Verzögerung, -1 bedeutet, dass das ??gleichwertige Attribut?? aus dem ASC Device ausgewertet werden soll
|-
|ASC_Drive_DelayStart || || -1|| in Sekunden verzögerter Wert ab welchen dann erst das Offset startet und dazu addiert wird. Funktioniert nur wenn gleichzeitig ASC_DriveDelay gesetzt wird.
|-
|ASC_ExternalTrigger || |||| DEVICE:READING VALUEACTIVE:VALUEINACTIVE POSACTIVE:POSINACTIVE, Beispiel: "WohnzimmerTV:state on:off 66:100" bedeutet das wenn ein "state:on" Event kommt soll das Rollo in Position 66 fahren, kommt ein "state:off" Event soll es in Position 100 fahren. Es ist möglich die POSINACTIVE weg zu lassen dann fährt das Rollo in LastStatus Position.
|-
|ASC_GuestRoom || on, off |||| aktuell noch nicht umgesetzt...
|-
|ASC_LockOut || soft, hard, off ||off || stellt entsprechend den Aussperrschutz ein. Bei global aktivem Aussperrschutz (set ASC-Device lockOut soft) und einem Fensterkontakt open bleibt dann der Rollladen oben. Dies gilt nur bei Steuerbefehlen über das ASC Modul. Stellt man global auf hard, wird bei entsprechender Möglichkeit versucht den Rollladen hardwareseitig zu blockieren. Dann ist auch ein Fahren über die Taster nicht mehr möglich
|-
|ASC_LockOut_Cmd || inhibit, blocked, protection ||none|| set Befehl für das Rollladen-Device zum Hardware sperren. Dieser Befehl wird gesetzt werden, wenn man "ASC_LockOut" auf hard setzt
|-
|ASC_Mode_Down ||absent, always, off, home || always ||Wann darf die Automatik steuern. immer, niemals, bei Abwesenheit des Roommate (ist kein Roommate und absent eingestellt, wird gar nicht gesteuert)
|-
|ASC_Mode_Up ||absent, always, off, home || always ||Wann darf die Automatik steuern. immer, niemals, bei Abwesenheit des Roommate (ist kein Roommate und absent eingestellt, wird gar nicht gesteuert)
|-
|ASC_Open_Pos || ||default Vorgabe ist abhängig vom Attribut ''ASC''||in 10er-Schritten von 0 bis 100
|-
|ASC_Partymode || on, off || off ||schaltet den Partymodus an oder aus. Wird am ASC Device set ASC-DEVICE partyMode on geschalten, werden alle Fahrbefehle an den Rollläden, welche das Attribut auf on haben, zwischengespeichert und später erst ausgeführ
|-
|ASC_Pos_Reading || || ||Name des Readings, welches die Position des Rollladen in Prozent angibt. Wird bei unbekannten Device-Typen auch als ''set'' Befehl zum Fahren verwendet
|-
|ASC_PrivacyDownValue_beforNightClose || || -1||wie viele Sekunden vor dem abendlichen schließen soll der Rollladen in die Sichtschutzposition fahren, oder bei Brightness ab welchem minimum Brightnesswert soll das Rollo in die Privacy Position fahren. Bei Brightness muss zusätzlich zum Zeitwert der Brightnesswert mit angegeben werden 1800:300 bedeutet 30 min vor night close oder bei unter einem Brightnesswert von 300
|-
|ASC_PrivacyDown_Pos || ||50||Position den Rollladens für den abendlichen Sichtschutz!Verwendung von Perlcode ist möglich, dieser muss in {} eingeschlossen sein. Rückgabewert muss eine positive Zahl/Dezimalzahl sein!!!
|-
|ASC_PrivacyUpValue_beforDay || || -1||wie viele Sekunden vor dem morgendlichen öffnen soll der Rollladen in die Sichtschutzposition fahren, oder bei Brightness ab welchem minimum Brightnesswert soll das Rollo in die Privacy Position fahren. Bei Brightness muss zusätzlich zum Zeitwert der Brightnesswert mit angegeben werden 1800:600 bedeutet 30 min vor day open oder bei über einem Brightnesswert von 600
|-
|ASC_PrivacyUp_Pos || ||50||Position den Rollladens für den morgendlichen Sichtschutz!Verwendung von Perlcode ist möglich, dieser muss in {} eingeschlossen sein. Rückgabewert muss eine positive Zahl/Dezimalzahl sein!!!
|-
|ASC_RainProtection ||on, off || ||soll der Rollladen beim Regenschutz beachtet werden. on=JA, off=NEIN.
|-
|ASC_Roommate_Device || || none ||mit Komma getrennte Namen des/der Roommate-Device/s welche den/die Bewohner des Rollladen-Raumes wiedergibt. Macht nur Sinn in Schlaf- oder Kinderzimmern
|-
|ASC_Roommate_Reading || || ||Reading des Roommate-Device, welches den Status wieder gibt
|-
|ASC_Self_Defense_AbsentDelay || || 300||um wie viele Sekunden soll das fahren in Selfdefense bei Residents absent verzögert werden
|-
|ASC_Self_Defense_Mode || || gone||ab welchen Residents Status soll Selfdefense aktiv werden ohne das Fenster auf sind
|-
|ASC_Shading_InOutAzimuth || ||95:265 ||Azimut Wert ab dem bei Überschreiten Beschattet und bei Unterschreiten Endschattet werden soll
|-
|ASC_Shading_MinMax_Elevation || ||25.0:100.0 ||ab welcher min Höhe des Sonnenstandes soll beschattet und ab welcher max Höhe wieder beendet werden, immer in Abhängigkeit der anderen einbezogenen Sensorwerte
|-
|ASC_Shading_MinOutsideTemperature_ || ||18 ||ab welcher Temperatur soll Beschattet werden, immer in Abhängigkeit der anderen einbezogenen Sensorwert
|-
|ASC_ShadingMode ||absent, always, off, home || off||wann soll die Beschattung nur stattfinden
|-
|ASC_Shading_Pos || || ||Position des Rollladens für die Beschattung !!!Verwendung von Perlcode ist möglich, dieser muss in {} eingeschlossen sein. Rückgabewert muss eine positive Zahl/Dezimalzahl sein!!!
|-
|ASC_Shading_StateChange_SunnyCloudy || ||35000:20000 ||Brightness Wert ab welchen die Beschattung stattfinden und aufgehoben werden soll, immer in Abhängigkeit der anderen einbezogenen Sensorwerte
|-
|ASC_Shading_WaitingPeriod || ||1200 ||wie viele Sekunden soll gewartet werden bevor eine weitere Auswertung der Sensordaten für die Beschattung stattfinden soll
|-
|ASC_Shutter_IdleDetection || ||||READING:VALUE gibt das Reading an welches Auskunft über den Fahrstatus des Rollos gibt, sowie als zweites den Wert im Reading welcher aus sagt das das Rollo nicht fährt
|-
|ASC_ShuttersPlace || window, terrace || ||wenn dieses Attribut auf ''terrace'' gesetzt ist und das Residents-Device in den Status ''absent'' geht, ''selfDefence'' aktiv ist und das Fenster geöffnet ist, wird das Rollo geschlossen. Wenn ein twostate Senso genutzt wird und dieses Attribut auf ''terrace'' gesetzt ist wird ASC_Ventilate_Pos ignoriert und das Rollo wird beim öffnen des Fenster komplett geöffnet. Wenn dieses Attribut auf ''window'' gesetzt ist wird ASC_Ventilate_Pos berücksichtigt und das Rollo wird entsprechend der ASC_Ventilate_Pos geöffnet. Wenn das Fenster wieder geschlossen wird, dann wird das Rollo unabhängig von ''windows oder terrace'' vollständig geschlossen.
|-
|ASC_Sleep_Pos || || ||in 10er-Schritten von 0 bis 100, default Vorgabe ist abhängig vom Attribut ''ASC.'' Position wird angefahren wenn Bedingung für modeDown aktiv ist. Hiermit kann z.B. das komplette abendliche Schließen des Rollos begrenzt werden.
|-
|ASC_TempSensor || || ||DEVICENAME[:READINGNAME] - der Inhalt ist eine Kombination aus Device und Reading für die Außentemperatur
|-
|ASC_Time_Down_Early || ||16:00 ||Sonnenuntergang frühste Zeit zum Runterfahren !!!Verwendung von Perlcode ist möglich, dieser muss in {} eingeschlossen sein. Rückgabewert muss ein Zeitformat in Form HH:MM[:SS] sein!!!
|-
|ASC_Time_Down_Late || ||22:00 ||Sonnenuntergang späteste Zeit zum Runterfahren !!!Verwendung von Perlcode ist möglich, dieser muss in {} eingeschlossen sein. Rückgabewert muss ein Zeitformat in Form HH:MM[:SS] sein!!!
|-
|ASC_Time_Up_Early || || 05:00||Sonnenaufgang frühste Zeit zum Hochfahren !!!Verwendung von Perlcode ist möglich, dieser muss in {} eingeschlossen sein. Rückgabewert muss ein Zeitformat in Form HH:MM[:SS] sein!!!
|-
|ASC_Time_Up_Late || ||08:30 ||Sonnenaufgang späteste Zeit zum Hochfahren !!!Verwendung von Perlcode ist möglich, dieser muss in {} eingeschlossen sein. Rückgabewert muss ein Zeitformat in Form HH:MM[:SS] sein!!!
|-
|ASC_Time_Up_WE_Holiday || ||08:00 ||Sonnenaufgang frühste Zeit zum Hochfahren am Wochenende und/oder Urlaub (holiday2we wird beachtet).ACHTUNG!!! in Verbindung mit Brightness für ASC_Up muss die Uhrzeit kleiner sein wie die Uhrzeit aus ASC_Time_Up_Late !!!Verwendung von Perlcode ist möglich, dieser muss in {} eingeschlossen sein. Rückgabewert muss ein Zeitformat in Form HH:MM[:SS] sein!!!
|-
|ASC_Ventilate_Window_Open ||on, off ||on||auf lüften, wenn das Fenster gekippt/geöffnet wird und aktuelle Position unterhalb der Lüften-Position ist
|-
|ASC_WiggleValue || ||5 ||Wert, um welchen sich die Position des Rollladens bei ''Wiggle'' ändern soll
|-
|ASC_WindParameters || ||5 ||TRIGGERMAX[:HYSTERESE] [DRIVEPOSITION] / Angabe von Max Wert ab dem für Wind getriggert werden soll, Hytsrese Wert ab dem der Windschutz aufgehoben werden soll TRIGGERMAX - HYSTERESE / Ist es bei einigen Rollläden nicht gewünscht das gefahren werden soll, so ist der TRIGGERMAX Wert mit -1 an zu geben. (default: '50:20 ClosedPosition')
|-
|ASC_WindProtection ||on, off || ||soll der Rollladen beim Windschutz beachtet werden. on=JA, off=NEIN.
|-
|ASC_WindowRec || ||none ||Name des Fensterkontakts, an welchen Fenster der Rollladen angebracht ist. WINDOWREC:[READING], Name des Fensterkontaktes, an dessen Fenster der Rollladen angebracht ist. Reading ist optional
|-
|ASC_WindowRec_PosAfterDayClosed ||open, lastManual ||open ||Name des Fensterkontakts, an welchen Fenster der Rollladen angebracht ist. Sein Reading ''state'' muss die Werte ''open'', ''closed'' oder ''tilted'' enthalten.
|-
|ASC_WindowRec_subType ||twostate, threestate ||twostate||Typ des verwendeten Fensterkontaktes: twostate (optisch oder magnetisch) oder threestate (Drehgriffkontakt)
|-
| || || ||
| || || ||
|-
| || || ||
|-
| || || ||
|-
| || || ||
|}

== Hilfsmittel ==
{{Hinweis|Die Device-Namen sind auf die eigene Installation anzupassen.}}

{{Hinweis|Codezeilen sind im [[Import von Code Snippets|RAW]]-Format.}}

{{Randnotiz|RNTyp=g|RNText= Stand 2019-05-03
* Erfolgreich getestet mit Homematic Devices, Beta-User
* Die Farbgebung entspricht dem Standard, wenn unter dem Style f18 der Farbpreset ''light'' gewählt wird.
}}

=== readingsGroup für Level ===
<pre style="width:65%;word-wrap: break-word;">defmod rg_ASC_Rolllaeden_Level readingsGroup <Gerät>,<Stand>,<Schliessen bis>,<Öffnen auf>,<Beschattung>,<Komfort>,<Lüften>,<Privacy> (Rollladen_.*|Jalousie_.*)..:level,!?ASC_Closed_Pos,!?ASC_Open_Pos,!?ASC_Shading_Pos,!?ASC_ComfortOpen_Pos,!?ASC_Ventilate_Pos,!?ASC_PrivacyDown_Pos
attr rg_ASC_Rolllaeden_Level commands {level => 'pct:selectnumbers,0,5,100,0,lin',\
ASC_Closed_Pos => 'ASC_Closed_Pos:selectnumbers,0,5,100,0,lin',\
ASC_Open_Pos => 'ASC_Open_Pos:selectnumbers,0,5,100,0,lin',\
ASC_Shading_Pos => 'ASC_Shading_Pos:selectnumbers,0,5,100,0,lin',\
ASC_Ventilate_Pos => 'ASC_Ventilate_Pos:selectnumbers,0,5,100,0,lin',\
ASC_ComfortOpen_Pos => 'ASC_ComfortOpen_Pos:selectnumbers,0,5,100,0,lin',\
ASC_PrivacyDown_Pos => 'ASC_PrivacyDown_Pos:selectnumbers,0,5,100,0,lin'}
</pre>

=== readingsGroup für Zeiten ===
[[Bild:ReadingsGroup ASC times.png|thumb|right|ReadingsGroup - Zeitenbeispiel]]
<pre style="width:65%;word-wrap: break-word;">defmod rg_ASC_Rolllaeden_Times readingsGroup <Gerät>,<Position>,<Time_Up_Early>,<Time_Up_Late>,<Time_Up_WE/Hol>,<Time_Down_Early>,<Time_Down_Late>,<Mode_Down>,<Mode_Up> \
(.*Rollo.*|.*Rollladen|Jalousie_.*):level,!?ASC_Time_Up_Early,!?ASC_Time_Up_Late,!?ASC_Time_Up_WE_Holiday,!?ASC_Time_Down_Early,!?ASC_Time_Down_Late,!?ASC_Mode_Down,!?ASC_Mode_Up
attr rg_ASC_Rolllaeden_Times commands {level => 'pct:0,10,20,30,35,40,45,50,55,60,65,70,75,80,85,90,95,100', \
ASC_Time_Down_Early => 'ASC_Time_Down_Early:15:00,15:15,15:30,15:45,16:00,16:15,16:30,16:45,17:00,17:15,17:30,17:45,18:00,18:15,18:30,18:45,19:00,19:15,19:30,19:45,20:00,20:15,20:30,20:45,21:00,21:15,21:30,21:45,22:00', \
ASC_Time_Down_Late => 'ASC_Time_Down_Late:19:00,19:15,19:30,19:45,20:00,20:15,20:30,20:45,21:00,21:15,21:30,21:45,22:00,22:15,22:30,22:45,23:00,23:15,23:30', \
ASC_Time_Up_WE_Holiday => 'ASC_Time_Up_WE_Holiday:06:00,06:15,06:30,06:45,07:00,07:15,07:30,07:45,08:00,08:15,08:30,08:45,09:00,09:15,09:30,09:45,10:00',\
ASC_Time_Up_Early => 'ASC_Time_Up_Early:05:00,05:05,05:30,05:55,06:00,06:15,06:30,06:45,07:00,07:15,07:30,07:45,08:00,08:15,08:30,08:45,09:00,09:15,09:30,09:45,10:00', \
ASC_Time_Up_Late => 'ASC_Time_Up_Late:06:00,06:15,06:30,06:45,07:00,07:15,07:30,07:45,08:00,08:15,08:30,08:45,09:00,09:15,09:30,09:45,10:00', \
ASC_Mode_Down => 'ASC_Mode_Down:always,absent,off', \
ASC_Mode_Up => 'ASC_Mode_Up:always,absent,off' }
attr rg_ASC_Rolllaeden_Times room Rollladen</pre>

[[Bild:ASC RG Zeiten HM ZWave Siro.png|thumb|right|ReadingsGroup - CUL_HM+ZWave+Siro mit widgets]]Neue Version mit time-Widgets und pct/dim/position-widget (5-er Schritte), passend für CUL_HM, ZWave und Siro-Geräte:
<pre style="width:65%;word-wrap: break-word;">defmod rg_ASC_Rolllaeden_Times readingsGroup <Gerät>,<Stand>,<Time_Up_Early >,<Time_Up_WE >,<Time_Up_Late >,<Time_Down_Early>,<Time_Down_Late>,<Mode_Down>,<Mode_Up> (Rollo_.*|Jalousie_.*)..:(level|dim|position),!?ASC_Time_Up_Early,!?ASC_Time_Up_WE_Holiday,!?ASC_Time_Up_Late,!?ASC_Time_Down_Early,!?ASC_Time_Down_Late,!?ASC_Mode_Down,!?ASC_Mode_Up
attr rg_ASC_Rolllaeden_Times commands {level => 'pct:selectnumbers,0,5,100,0,lin', \
dim => 'dim:selectnumbers,0,5,99,0,lin',\
position => 'pct:selectnumbers,0,5,99,0,lin',\
ASC_Mode_Down => 'ASC_Mode_Down:always,absent,off',\
ASC_Mode_Up => 'ASC_Mode_Up:always,absent,off',\
ASC_Time_Down_Early => 'ASC_Time_Down_Early:time', \
ASC_Time_Down_Late => 'ASC_Time_Down_Late:time',\
ASC_Time_Up_Early => 'ASC_Time_Up_Early:time', \
ASC_Time_Up_Late =>'ASC_Time_Up_Late:time',\
ASC_Time_Up_WE_Holiday =>'ASC_Time_Up_WE_Holiday:time'}
attr rg_ASC_Rolllaeden_Times room Rollladen
</pre>

=== readingsGroup für die Beschattung ===
[[Bild:ReadingsGroup ASC shading.png|thumb|right|ReadingsGroup - Beschattungsbeispiel]]
<pre style="width:65%;word-wrap: break-word;">
defmod RG_test readingsGroup <Gerät>,<InAzi>,<OutAzi>,<MinEle>,<MaxEle>,<Sunny>,<Cloudy>\
(Rollo|Jalousie)_.*..:<{ascAPIget('ShadingAzimuthLeft',$DEVICE)}>,<{ascAPIget('ShadingAzimuthRight',$DEVICE)}>,<{ascAPIget('ShadingMinElevation',$DEVICE)}>,<{ascAPIget('ShadingMaxElevation',$DEVICE)}>,<{ascAPIget('ShadingStateChangeSunny',$DEVICE)}>,<{ascAPIget('ShadingStateChangeCloudy',$DEVICE)}></pre>

=== readingsGroup für FIBARO Roller Shutter FGR-222 Devices ===
{{Randnotiz|RNTyp=g|RNText=Getestet von majestro84, Stand 2019-01-28.
* {{Link2Forum|Topic=92628|Message=897099|LinkText=Forenbeitrag dazu}}
* Die Farbgebung entspricht dem Standard, wenn unter dem Style f18 der Farbpreset ''dark'' gewählt wird}}
[[Bild:ASC Jalousien Times.JPG|thumb|right|Beispiel]]
<pre style="width:65%;word-break: break-all;word-wrap: break-word;">define ASC_Jalousien_Times readingsGroup <Gerät>,<Stand>,<Time_Up_Early>,<Time_Up_WE>,<Time_Up_Late>,<Time_Down_Early>,<Time_Down_Late>,<Mode_Down>,<Mode_Up>,<PartyMode>,<LockOut> (.*_Jalousie.*):position,!?ASC_Time_Up_Early,!?ASC_Time_Up_WE_Holiday,!?ASC_Time_Up_Late,!?ASC_Time_Down_Early,!?ASC_Time_Down_Late,!?ASC_Mode_Down,!?ASC_Mode_Up,!?ASC_Partymode,!?ASC_LockOut

attr ASC_Jalousien_Times commands {position => 'dim:0,10,20,30,35,40,45,50,55,60,65,70,75,80,85,90,95,99',
ASC_Mode_Down => 'ASC_Mode_Down:always,absent,off',
ASC_Mode_Up => 'ASC_Mode_Up:always,absent,off',
ASC_Partymode => 'ASC_Partymode:on,off',
ASC_LockOut => 'ASC_LockOut:soft,hard,off',
ASC_Time_Down_Early => 'ASC_Time_Down_Early:15:00,15:15,15:30,15:45,16:00,16:15,16:30,16:45,17:00,17:15,17:30,17:45,18:00,18:15,18:30,18:45,19:00,19:15,19:30,19:45,20:00,20:15,20:30,20:45,21:00,21:15,21:30,21:45,22:00',
ASC_Time_Down_Late => 'ASC_Time_Down_Late:20:15,20:30,20:45,21:00,21:15,21:30,21:45,22:00,22:15,22:30,22:45,23:00,23:15,23:30',
ASC_Time_Up_Early => 'ASC_Time_Up_Early:05:00,05:05,05:30,05:45,06:00,06:15,06:30,06:45,07:00,07:15,07:30,07:45,08:00,08:15,08:30,08:45,09:00,09:15,09:30,09:45,10:00',
ASC_Time_Up_Late =>'ASC_Time_Up_Late:06:00,06:15,06:30,06:45,07:00,07:15,07:30,07:45,08:00,08:15,08:30,08:45,09:00,09:15,09:30,09:45,10:00',
ASC_Time_Up_WE_Holiday => 'ASC_Time_Up_WE_Holiday:06:00,06:15,06:30,06:45,07:00,07:15,07:30,07:45,08:00,08:15,08:30,08:45,09:00,09:15,09:30,09:45,10:00'}
attr ASC_Jalousien_Times room Jalousien</pre>

[[Bild:ASC Jalousien Level.JPG|thumb|right|Beispiel]]
<pre style="width:65%;word-break: break-all;word-wrap: break-word;"> define Jalousien_Level readingsGroup <Gerät>,<Closed_Pos>,<Open_Pos>,<Comfort_Pos>,<Ventilate_Pos>,<PrivacyDown_Pos>,<Shading_Pos> (.*_Jalousie.*):!?ASC_Closed_Pos,!?ASC_Open_Pos,!?ASC_ComfortOpen_Pos,!?ASC_Ventilate_Pos,!?ASC_PrivacyDown_Pos,!?ASC_Shading_Pos
attr Jalousien_Level commands { ASC_Closed_Pos => 'ASC_Closed_Pos:0,10,20,30,35,40,45,50,55,60,65,70,75,80,85,90,95,99',
ASC_Open_Pos => 'ASC_Open_Pos:0,10,20,30,35,40,45,50,55,60,65,70,75,80,85,90,95,99',
ASC_ComfortOpen_Pos => 'ASC_ComfortOpen_Pos:0,10,20,30,35,40,45,50,55,60,65,70,75,80,85,90,95,99',
ASC_Ventilate_Pos => 'ASC_Ventilate_Pos:0,10,20,30,35,40,45,50,55,60,65,70,75,80,85,90,95,99',
ASC_PrivacyDown_Pos => 'ASC_PrivacyDown_Pos:0,10,20,30,35,40,45,50,55,60,65,70,75,80,85,90,95,99',
ASC_Shading_Pos => 'ASC_Shading_Pos:0,10,20,30,35,40,45,50,55,60,65,70,75,80,85,90,95,99'}
attr Jalousien_Level room Jalousien</pre>

== Einrichtungsbeispiel (nach Sonnenstand) ==
=== Ziel und Vorgaben ===
Es sollen die Rollläden und Jalousien innerhalb bestimmter zeitlicher Perioden sonnenstandsabhängig geöffnet und geschlossen werden. An den Wochenenden und an Ferientagen soll etwas später geöffnet werden. Es sind Tür- und Fensterkontakte vorhanden (Türkontakte: twoState, Fensterkontakte: threeState), wobei bei jeder Öffnung ein eventuell geschlossener Rollladen geöffnet werden soll. Bei allen Rollladenaktoren, Tür- und Fensterkontakten handelt es sich um CUL_HM-Geräte.

=== Vorarbeiten ===
Im global-Device sind Angaben zu latitude und longitude vorhanden, holiday2we wie folgt<ref>''ferien'' ist eine automatisiert erstellte holiday-Datei nach diesem {{Link2Forum|Topic=85759|Message=885883|LinkText=Foren-Beitrag}}.</ref>:
attr global holiday2we bw,ferien
Weitere Angaben werden zunächst nicht benötigt, das Astro-Device wird erst in der Beschattungskonfiguration definiert.
Dann erfolgt das ''Define des ASC-Devices'' wie oben beschrieben:
<code>define Rollladenautomatik AutoShuttersControl</code>
Folgen die einzubindenden Rollladenaktoren einem einheitlichen Namensschema, können diese sodann z.B. mit
attr (Jalousie|Rollladen)_.* ASC 2
auf einen Rutsch mit dem passenden ASC-Typ gekennzeichnet werden.

{{Hinweis|Achtung: Das AutoShuttersControl-Device selbst darf kein ASC-Attribut bekommen!}}

Dann werden mit
set Rollladenautomatik scanForShutters
die nachfolgend weiter zu bearbeitenden Attribute angelegt.
=== Schließen morgens und abends ===
{{Randnotiz|RNTyp=g|RNText=Alternative: Fahren nach brightness:
Soll insgesamt oder an einzelnen Rollläden helligkeitsgesteuert gefahren werden, muß zentral oder für jeden Rollladen ein Helligkeitssensor definiert und die Helligkeitsgrenzwerte festgelegt sein (''ASC_BrightnessSensor'' etc.), bei deren Überschreitung geöffnet bzw. Unterschreitung geschlossen werden soll.}}
==== Konfiguration des ASC-Devices ====
Sonnenstandsabhängige Fahrzeiten werden wie folgt aktiviert:
<pre>
attr Rollladenautomatik ASC_autoAstroModeEvening CIVIL
attr Rollladenautomatik ASC_autoAstroModeMorning CIVIL
</pre>
Aus der Angabe ''CIVIL'' und den Vorgaben in den einzelnen Rollladen wird dabei mit Hilfe von [[SUNRISE_EL]] die effektive Fahrzeit berechnet, dort finden sich auch weitere Hinweise, zu den meisten anderen Optionen für die ersten beiden Attribute.
Bei allen Fensteröffnungen soll auf eine Lüften-Position gefahren werden, also schalten wir diese Funktion ebenfalls zentral an<ref>Sonst wird bei threeState-Sensoren nur bei ''tilted'' auf die in ''ASC_Ventilate_Pos'' gefahren.</ref>:
attr Rollladenautomatik ASC_autoShuttersControlComfort on
Zuletzt legen wir noch einen Temperatur-Sensor fest. Dieser wird beim Frostschutz sowie bei der Beschattung berücksichtigt.
<pre>
attr Rollladenautomatik ASC_tempSensor Aussentemperatur_Nord:temperature
attr Rollladenautomatik ASC_freezeTemp 3
</pre>{{Hinweis|Achtung: Für jede weitere Sensor-Information (z.B. zu Regen oder Wind) muß ein eigenes Device verwendet werden. Sollen unterschiedliche Readings desselben Sensors ausgewertet werden, müssen diese in ein eigenes Device übertragen werden, z.B. über einen readingsProxy mit gesetztem event-on-update-reading-Attribut (sonst triggert dieser nicht bei Aktualisierung des Readings)!}}

tbd:
* Rain
* Wind
==== Konfiguration der Rollladendevices ====
{{Hinweis|Positionen dürfen sich innerhalb eines Rollos nicht überschneiden - Auch ASC_Closed_Pos 100 ASC_Shading_Pos 98 ASC_ComfortOpen_Pos 97 usw... sind bereits unterschiedliche Positionen.}}

===== Fahrzeiten =====
Zur Konfiguration der Fahrzeiten bietet es sich an, eine ReadingsGroup zu nutzen, wie unter [[#Hilfsmittel|Hilfsmittel]] dargestellt. Alternativ kann man die Zeiten auch manuell in den einzelnen Rollläden hinterlegen.
===== Bewohner =====
Wird ein Raum von einer oder mehreren bestimmten Person/en bewohnt oder gibt es ein Sammel-Gerät für mehrere Bewohner, kann dies mit den Attributen ''ASC_Roommate_Device'' und ''ASC_Roommate_Reading'' einem Rollladen zugeordnet werden. Ist einer der Bewohner ''asleep'', wird morgens erst geöffnet, wenn auch der letzte Roommate nicht mehr ''asleep'' ist.
===== Fensterkontakte =====
Dann werden ggf. vorhandene Fensterkontakte mit ''ASC_WindowRec'' zugeordnet und der Sensortyp mit ''ASC_WindowRec_subType'' festgelegt. Im Falle von threeState-Sensoren wird das übergreifende ''ASC_autoShuttersControlComfort'' beachtet, wobei dann bei vollständiger Öffnung des Fensters auf den in ''ASC_ComfortOpen_Pos'' festgelegten Wert gefahren wird.
===== Frostschutz =====
Zuletzt können die Attribute ''ASC_Antifreeze'' und ''ASC_Antifreeze_Pos'' festgelegt werden, wenn die Frostschutzfunktion aktiviert werden soll.

=== Beschattung ===
==== Konfiguration des ASC-Devices ====
Im ASC DEVICE das Reading "controlShading" auf ''on'', sowie ein Astro/Twilight Device im Attribut "ASC_twilightDevice" und das Attribut "ASC_tempSensor" definieren.

==== Konfiguration der Rollladendevices ====
Es wird ein Helligkeitssensor als Attribut "ASC_BrightnessSensor" benötigt. Wird der Sensor nur für die Beschattung verwendet, ist der Wert DEVICENAME[:READING] ausreichend.
Alle weiteren Attribute sind optional und wenn nicht gesetzt mit Default-Werten belegt. Sie sollten entsprechend der Gegebenheiten angepasst werden. Die Werte für die Fensterposition und den Vor-/Nachlaufwinkel ''(ASC_Shading_InOutAzimuth)'' sowie die Grenzwerte für <code>''ASC_shading_StateChange_SunnyCloudy''</code> sind besonders wichtig.

==== Bedingungen ====
Damit die Beschattung startet müssen '''alle''' Bedingungen erfüllt sein. Entschattet wird, sobald '''eine''' der Bedingungen wegfällt und die Zeit entsprechend <code>ASC_Shading_WaitingPeriod</code> abgelaufen ist.

Der Sonnensensor <ASC_BrightnessSensor> muss mindestens zwei Messwerte geliefert haben, bevor das ASC-Modul in die Beschattungsposition fährt! Beim (zeitlich) ersten Messwert wird der Zustand ''in-reserved'' gesetzt. Erst beim zweiten Messwert wechselt der Zustand nach ''in shading''. Die Anzahl der berücksichtigten Messwerte ist abhängig vom "moving average window", der mit dem dritten Parameter des Attributs ''ASC_Shading_StateChange_SunnyCloudy'' konfiguriert wird.

'''Von Standardwerten ausgehend ist nachfolgender Ablauf angestrebt:'''
# Ein Event vom Astro oder Helligkeits Device kommt -> sind alle Werte innerhalb des Arbeitsbereiches, ändert sich der ASC Info-Zustand im Rollo von xx auf „in reserved“ (Beschattung vorbereitet)
# Ein erneutes Event vom Astro oder Helligkeits Device kommt -> Überprüfung der Werte -> sind diese weiterhin gegeben folgt der Wechsel von „in reserved“ auf „in“ (Beschattung aktiv)
# Bei Verwendung von ''ASC_Shading_StateChange_SunnyCloudy'' ist zu beachten, dass ein Durchschnitt über die letzten drei Brightness Events gerechnet wird. Möchte man das vermeiden muss man SUNNY:CLOUDY 1[2] setzen.
# Die Zeiten ''ASC_Shading_WaitingPeriod'' und ''ASC_BlockingTime_afterManual'' können hier zusätzlich für eine Verzögerung sorgen.
'''Wichtig zu beachten:''' Es müssen immer mehrere (mind. 2) Events für den Betrieb erfolgen. In den Standardeinstellungen vom Astro Modul erfolgt dieses z.B. nur 1 x pro Stunde. Kommt also ein Helligkeits-Event auch nur 1x pro Stunde, könnte es 2 Std dauern, bis die Beschattungsfunltion greift.

Wenn das Rollo einmal aus der Beschattung manuell (im Rollo Device muss bei ''ASC_ShuttersLastDrive manuel'' stehen gefahren wurde wird das Rollo erst wieder nach einer Entschattung und erneuter Beschattung gefahren. Also es muss einmal shading out kommen und beim nächsten shading in fährt er dann wieder.

=== Weitere Funktionen ===
==== WeekendHoliday Funktion im Brightnessbetrieb ====
Am Wochenende oder Feiertag und wenn am ASC-Device sunriseTimeWeHoliday aktiviert sowie im Rollo das Attribut ASC_Time_Up_WE_Holiday gesetzt sind, wird zur angegebenen ASC_Time_Up_WE_Holiday Zeit das Rollo geöffnet, ungeachtet des Brightnesswertes.

==== Privacy ====
Werden hierfür Werte festgelegt, werden die betreffenden Rollläden die festgelegte Zeit/Helligkeit vor dem abendlichen Schließen vorab teilweise geschlossen. Dies kann z.B. gewünscht sein, um Rollläden zur Straße hin mit viel Fußgängerverkehr zwar nicht vollständig abzudunkeln, aber gleichzeitig zu verhindern, dass von außen in Wohnräume geschaut werden kann, sobald dort das Licht angeschaltet wird

==== BlockingTime====
Bewirkt, dass nach einer manuellen Fahrt, eine vom ASC Modul initiierte Fahrt zunächst ausgesetzt wird, bis die im Attribute angegebene Zeit überschritten ist. Erst dann wird eine vom ASC Modul initiierte Fahrt tatsächlich durchgeführt.
Genau so wird ein Hochfahren eines Rollos durch das ASC Modul nicht mehr ausgeführt, wenn es innerhalb der Zeit von ASC_BlockingTime_beforNightClose und das Runterfahren wird nicht mehr erfolgen, wenn es innerhalb von ASC_BlockingTime_beforDayOpen ist.
Beispiel: Meine Tochter geht früh außer Haus und Ihre Rollos sind nicht hochgefahren. Diese fahren auch nicht mehr hoch, da die ausschließlich bei home (anwesend) fahren sollen. Nun kommt sie am Nachmittag um 16:23 Uhr nach Hause. Eigentlich sollten nun die Rollos fahren. Doch die Sonnenuntergangsfahrt (schließen) wäre schon 16:51 Uhr und damit innerhalb der 3600 ASC_BlockingTime_beforNightClose. Die Rollos bleiben also unten. Es lohnt sich für die paar Minuten einfach nicht mehr.

==== wiggle====
Mit einem <code>set <ASC-Device> wiggle</code> können alle Rollladen mit einem entsprechenden Attribut zu einer kurzen Fahrt veranlasst werden, nach Ablauf von einer Minute wieder um denselben Wert zurück. Dabei wird jeweils in die Richtung gefahren, die den weiteren Weg ermöglicht. Wenn also zu 70% geschlossen ist, wird der Rollladen hoch fahren.
==== Partymode ====
Dieser wird am ASC-Device selbst aktiviert mittels <code>set <ASC-Device> partyMode on</code>. Alle Rollladen-Devices, welche das Attribut ''ASC_Partymode'' auf ''on'' gestellt haben, werden nicht mehr gesteuert. Der letzte Schaltbefehl, der durch ein Fensterevent oder Bewohnerstatus an die Rollläden gesendet wurde, beim Beenden des Modus durch <code>set ASC-Device partyMode off</code> ausgeführt.
==== lock-out ====
Man kann mit dem Befehl <code> set <ASC-Device> hardLockOut</code> auf einen Schlag alle Rollos sperren welche <code> attr <ROLLO-Device> ASC_LockOut hard</code> gesetzt haben.
Das ist dafür gedacht, wenn Du eine gewisse Zeit den Rolloaktor sperren willst. Zum Beispiel das die Kinder nicht schalten sollen.

== Sonstige Hinweise und Problemlösungen ==
* Werden Attribute geändert, kann es vereinzelt vorkommen, dass das ASC-Modul dies nicht mitbekommt und das tatsächliche Verhalten nicht den Erwartungen entspricht. In so einem Fall empfielt es sich, das NOTIFYDEV nochmals aufbauen zu lassen. Dazu werden zunächst mit <code>set <ASC-Modul> expert 1</code> erweiterte Informationen bezüglich des NotifyDevs unter set und get aktiviert und anschließend ein <code>set <ASC-Modul> createNewNotifyDev</code> ausgeführt.

* Hin und wieder berichten Nutzer davon, wenn Sie die ''Privacy Funktion'' nutzen, dass sich im NOTIFYDEV anstelle des Device Namen ein Raumname befindet. Diese Problem kann damit gelöst werden, dass in dem betroffenen '''Rollo Device''' das Atribut <code>attr event-on-change .*</code> gesetzt wird.
'''Wichtig!''' Nicht verwechseln mit dem ASC Device dort darf <code>attr event-on-change</code> '''nicht''' gesetzt sein!
* Wenn mehrere Rollladen gleichzeitig den Fahrbefehl bekommen, kann es (z. B. bei zwave) dazu kommen, dass ein Rollladen seinen Befehl nicht bekommt. Dies kann durch eine zeitverzögerte Aussendung der Fahrbefehle vermieden werden. Dazu in den jeweiligen Rollo Devices das Attribut ASC_Drive_DelayStart wie folgt benutzen im: ersten Rollo Device braucht das Attribut nicht gesetzt werden, im zweiten Rollo Device im Attribut ASC_Drive_DelayStart dann 4 Sekunden eintragen, im dritten Rollo Device im Attribut ASC_Drive_DelayStart 8 Sekunden eintragen, usw. Ein Abstand von 3-4 Sekunden ist dabei zielführend.

==== Spezielle Hardware ====
{{Link2Forum|Topic=101182|LinkText="Thread zu getesteter Hardware im Forum"}}

== Weblinks ==
* {{Link2Forum|Topic=92628|LinkText="Thread zum Modul im Forum"}}
* {{Link2Forum|Topic=90751|LinkText="Thread zur Entwicklung im Forum"}}
* {{Link2Forum|Topic=73964|LinkText="Thread zu den Scripten von user cluni"}}, die der Entwicklung des Moduls zugrunde liegen
* Daten zum Sonnenstand z.B. hier https://www.sonnenverlauf.de/

<references />

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

AutoShuttersControl

2021-06-14T19:19:31Z

TomLee: /* readingsGroup für die Beschattung */

{{Infobox Modul
|ModPurpose=Steuerung von Rollläden
|ModCategory=Automatisierung
|ModType=d
|ModForumArea=Automatisierung
|ModTechName=73_AutoShuttersControl.pm
|ModOwner=CoolTux ({{Link2FU|13684|Forum}}/[[Benutzer Diskussion:CoolTux|Wiki]])}}
Mit [[AutoShuttersControl]] oder kurz '''ASC''' können Rollläden automatisch hoch und herunter gefahren werden. Zum Beispiel Öffnen bei Sonnenaufgang, Schließen bei Sonnenuntergang, Beschatten abhängig vom Sonnenstand oder Anfahren von Lüftungspositionen nach Öffnen des zugehörigen Fensters.

== Basics ==
{{Hinweis|Das Modul befindet sich derzeit noch in der Entwicklung; der derzeit aktuelle Stand ist diesem {{Link2Forum|Topic=112325|LinkText="Thread im Forum"}} zu entnehmen.}}
Als Voraussetzung sollten folgende FHEM-Devices bereits vorhanden sein:
* Rollläden,
* Fensterkontakte,
* Bewohnerstatus auf Basis von Residents/Roomates in englisch. Ersatzweise andere Devices, z.B. Dummys, welche als ''state'' ''home'', ''absent'', ''asleep'', ''gotosleep'' und ''awoken'' setzen sowie ein Reading ''lastState''.
* Helligkeitssensor (Steuerung nach Helligkeit für Beschattung)
* Ein Device zur Bestimmung des Sonnenstands (nur für Beschattung). Unterstützt werden derzeit [[Modul Astro|Astro]] und [[Twilight]]<ref>Dabei müssen ggf. in [[Global|global]] auch Angaben zu ''longitude'' und ''latitude'' vorhanden sein</ref>.
* Wenn Feiertage berücksichtigt werden sollen: Ein oder mehrere {{Link2CmdRef|Anker=holiday2we|Lang=en|Label=holiday2we}}-Angaben in [[Global|global]] samt entsprechender [[Wochenende, Feiertage und Schulferien#Feiertage mittels holiday-Datei|holiday]]-Dateien<ref>Es kann auch z.B. ein Dummy-Device verwendet werden, dieses sollte dann aber neben dem eigentlichen Feiertags-''state'' auch in einem Reading ''tomorrow'' Angaben zu anstehenden Feiertagen enthalten.</ref> <ref>Bitte verfahren Sie entsprechend, wenn Urlaubs- oder Ferientage wie Feiertage behandelt werden sollen.</ref>.

Die Einrichtung des Moduls bzw. dessen Funktionalität erfolgt in mehreren Schritten:
* Definition des ASC-Devices
* Einstellung zentraler Vorgaben am ASC-Device
* Markieren der zukünftig zu steuernden Rollladen-Devices
* Einbinden der Rollladen-Devices in das ASC-Device
* Einstellen der individuellen Vorgaben je Rollladen (am Rollladen-Device)
Dabei geht man am einfachsten schrittweise vor und erweitert die Funktionalität nach und nach um die gewünschten Funktionen. Dann benötigt man jeweils nur einen kleinen Teil der vielen per Attribut einstellbaren Optionen, und kann die Auswirkungen der jeweiligen Änderung besser nachvollziehen.

== Einrichtung ==
{{Hinweis|ASC kann auch verwendet werden, um lediglich Teilaufgaben der Rollladensteuerung zu erfüllen, also z.B. nur das morgendliche Öffnen der Rollläden. Allerdings geht dabei ein erheblicher Teil des Komforts verloren, der dadurch entsteht, dass die Steuerung innerhalb der vollintegrierten Lösung jeweils nachvollzieht, aus welchem Grund eine Fahrt erfolgt war und dies ggf. bei der nächsten Aktion berücksichtigt.}}

=== Vorbereitung ===
Zunächst sollten die in den [[#Basics|Basics]] beschriebenen Geräte vorhanden und funktionsfähig sein.

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

=== Einstellung zentraler Vorgaben ===
Mit Attributen am ASC-Device wird das Verhalten des ASC-Devices eingestellt, z.B. Vermeiden von morgendlichen oder abendlichen Fahrten, Frostschutzfunktion bei Gefahr von festgefrorenen Rollläden oder die Reaktion auf Fensterkontakte. Details sind der Commandref zu entnehmen.
Diese Attribute können jederzeit geändert werden.

=== Auswählen zu steuernder Rollladen-Devices ===
Für jeden vom ASC-Device kontrollierten Rollladen muss das globale Attribut ''ASC'' gesetzt werden. Das steht nach dem Definieren des ASC-Devices zur Verfügung. Das Attribut ist mit 1 oder 2 festzulegen:
# Je ''kleiner'' der <code>pct</code> Wert um so weiter ist der Rollladen geschlossen. Typischerweise ist dann 0 ''offen'' und 100 ''geschlossen''. Dies ist z.B. die passende Wahl für ROLLO-Devices
# Je ''größer'' der <code>pct</code> Wert desto weiter ist der Rollladen geschlossen, also ''offen'' für <code>set <name> pct 100</code>. Typische Vertreter dieses Typs sind HomeMatic (CUL_HM-) Geräte oder die Shelly2-Aktoren.

Basierend auf dem Parameter leitet das Modul bestimmte Voreinstellungen (''defaults'') für den Rollladen ab. Es genügt daher, nur jeweils die Einstellungen zu verändern, die anders gewünscht werden oder für den Rollladenaktortyp anders sein müssen (z.B. ''dim 99'' für vollständiges Öffnen eines ZWave-Aktors).
{{Hinweis|Das Vorstehende gilt jeweils für den nicht-invertierten Modus! Wer z.B. ein HomeMatic-Gerät mit ''levelinverse'' betreibt, sollte ''ASC'' auf "1" setzen usw.. Maßgeblich ist letztlich nur die Frage, ob die Offen-Positionsangabe nummerisch kleiner oder größer als die Geschlossen-Positionsangabe ist; die konkreten Zahlenwerte spielen dabei keine Rolle, die Angabe ''position'' oder ''pct'' kann auch später über ein weiteres Attribut passend eingestellt werden.}}

=== Einbinden in das ASC-Device ===
Nachdem das ASC Attribut für die betreffenden Rollladen-Devices gesetzt ist, muss mit <code>set <name> scanForShutters</code> ein Suchlauf gestartet werden, mit dem diese Rollläden in die Steuerungslogik eingebunden werden.

=== Einstellen der individuellen Vorgaben ===
Die gefundenen Rollladen-Devices erhalten weitere Attribute, mit denen für den jeweiligen Rollladen benötigte Einstellungen vorgenommen werden.
Diese Attribute sind in der commandref beschrieben.

== Readings ==
===Readings im zentralen ASC-Device ===

{| class="wikitable"
|-
! Name !! Datentyp/<BR />Wertebereich !! Bedeutung
|-
|..._nextAstroTimeEvent || || Zeit wird abhängig von der eingestellten Attribute ASC_Time_Up/ASC_Time_Down angezeigt. Bei ''astro'' die Uhrzeit des Sonnenauf- oder Sonnenuntergang, bei ''time'' und ''brightness'' die Zeit aus ASC_Time_Up_Early/ASC_Time_Down_Late pro Rollonamen
|-
|..._lastPosValue || || Position pro Rollonamen, bevor ASC die Rollläden verfahren hat.
|-
|..._PosValue || ||aktuelle Position pro Rollonamen.
|-
|ascEnable||on, off ||globale ASC Steuerung bei den Rollläden aktiv oder inaktiv
|-
|controlShading||on, off ||globale Beschattungsfunktion aktiv oder inaktiv
|-
|hardLockOut || on, off ||Status des hardwareseitigen Aussperrschutzes / gilt nur für Rollläden mit dem Attribut bei denen das Attributs ASC_LockOut entsprechend auf hard gesetzt ist.
|-
|selfDefense || on, off ||globale Selbstschutzfunktion aktiv oder inaktiv
|-
|partyMode ||on, off || globaler Partymodus aktiv oder inaktiv
|-
|state || ||Status des ASC-Devices: active, enabled, disabled oder weitere Statusinformationen wie z.B. Grund der letzen Fahrt.
|-
|room_... || ||Auflistung aller Rollläden, welche in den jeweiligen Räumen gefunden wurden, Bsp.: room_Schlafzimmer,Terrasse.
|-
|sunriseTimeWeHoliday|| on,off ||globale Wochenendunterstützung aktiv oder inaktiv.
|-
|userAttrList || rolled out ||Das ASC-Modul verteilt an die gesteuerten Rollladen-Geräte diverse Benutzerattribute (userattr). In diesem Reading kann der Status dieser Verteilung geprüft werden.

|}

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

{| class="wikitable"
|-
! Name !! Bedeutung
|-
|ASC_Enable ||Status von ASC_Enable (on,off).
|-
|ASC_ShuttersLastDrive ||Grund der letzten Fahrt des Rollladens.
|-
|ASC_Time_DriveDown ||Zeit wird abhängig von der eingestellten Attribute ASC_Time_Down angezeigt. Bei astro die Uhrzeit des Sonnenuntergangs, bei time und brightness die Zeit aus /ASC_Time_Down_Late
|-
|ASC_Time_DriveUp ||Zeit wird abhängig von der eingestellten Attribute ASC_Time_Up angezeigt. Bei astro die Uhrzeit des Sonnenaufgangs, bei time und brightness die Zeit aus /ASC_Time_Up_Early
|}

==set- und get-Befehle für das ASC-Device==
=== set-Anweisungen ===
{| class="wikitable"
|-
! Name !! Datentyp/<BR />Wertebereich !! Beschreibung
|-
|advDriveDown ||on, off ||Nachholen der durch ASC_Adv on ausgesetzten Fahrten.
|-
|ascEnable||on, off ||Aktiviert oder deaktiviert die globale ASC-Steuerung.
|-
|controlShading||on, off ||Aktiviert oder deaktiviert die globale Beschattungssteuerung.
|-
|createNewNotifyDev || ||Legt die interne Struktur für NOTIFYDEV neu an. (Diese Funktion steht nur zur Verfügung, wenn Attribut ASC_expert auf 1 gesetzt ist.)
|-
|hardLockOut ||on, off ||Aktiviert den hardwareseitigen Aussperrschutz für die Rollläden, bei denen das Attributs ASC_LockOut auf hard gesetzt ist. Mehr Informationen in der Beschreibung bei den Attributen für die Rollladengeräten.
|-
|partyMode ||on, off ||Aktiviert den globalen Partymodus. Alle Rollladen-Geräten, in welchen das Attribut ASC_Partymode auf on gesetzt ist, werden durch ASC nicht mehr gesteuert. Der letzte Schaltbefehl, der bspw. durch ein Fensterevent oder Wechsel des Bewohnerstatus an die Rollläden gesendet wurde, wird beim Deaktivieren des Partymodus ausgeführt
|-
|renewAllTimer || ||Erneuert bei allen Rollläden die Zeiten gemäß ASC_UP/ASC_DOWN und setzt die internen Timer neu.
|-
|renewTimer || ||Erneuert bei dem ausgewählten Rollladen die Zeiten gemäß ASC_UP/ASC_DOWN und setzt die internen Timer neu.
|-
|scanForShutters || ||Sucht alle FHEM Devices mit dem Attribut ''ASC'' ''1'' oder ''2'' und legt diese im ASC-Modul an
|-
|selfDefence ||on, off||Aktiviert bzw. deaktiviert die Selbstschutzfunktion. Beispiel 1: Wenn das Residents-Gerät ''gone'' meldet, alle Rollläden dann heruntergefahren. Beispiel 2 : Wenn das Residents-Gerät ''absent'' meldet, das Attribut ASC_ShuttersPlace=terrace ist und ein Fenster im Haus noch geöffnet ist, so wird an diesem Fenster der Rollladen dann heruntergefahren.
|-
|shutterASCenableToggle || ||Aktivieren oder deaktivieren der ASC Kontrolle des einzelnen Rollladens.
|-
|sunriseTimeWeHoliday || on,off ||Aktiviert die Wochenendunterstützung. Dann wird das Attribut ASC_Time_Up_WE_Holiday am Rollladen-Device beachtet.
|-
|wiggle ||||Bewegt einen oder mehrere Rollläden um einen definierten Wert (Default: 5%) und nach einer Minute wieder zurück in die Ursprungsposition. Diese Funktion könnte bspw. zur Abschreckung in einem Alarmsystem eingesetzt werden.
|-
|||||
|}

=== get-Anweisungen ===

{| class="wikitable"
|-
! Name !! Beschreibung
|-
| showNotifyDevsInformations ||Zeigt eine Übersicht der abgelegten NOTIFYDEV Struktur. Diese Funktion wird für das Debugging genutzt. Hierzu ist das Attribut ASC_expert = 1 zu setzen.
|}

== Attribute ==
{{Hinweis|Die Attributnamen haben sich teilweise geändert, nachfolgend ist der Stand von Modulversion v0.8.x wiedergegeben.}}
{{Hinweis|In der commandref findet sich häufig die Schreibweise <code><nowiki>ASC_BrightnessSensor Sensorname[:brightness [400:800]]</nowiki></code>. Dabei sind die Angaben in den eckigen Klammern optional. Dies müssen also nicht angegeben werden, stattdessen verwendet das Modul dann Standardwerte (siehe cref), die in der cref zu findenden Angaben entsprechen dabei den defaults. Werden Werte angegeben, sind die eckigen Klammern '''wegzulassen'''! Beispiel: <code>ASC_BrightnessSensor hm_motion_1 70:100</code> würde das brightness-Reading des Sensors hm_motion_1 verwenden und einen morgendlichen Schwellenwert von 70 bzw. 100 für abends.}}
===Attribute direkt am ASC-Device ===

{| class="wikitable"
|-
! Name !! Datentyp/<BR />Wertebereich !! Default-Wert !! Beschreibung
|-
|ASC_autoAstroModeEvening || ||REAL, CIVIL, NAUTIC, ASTRONOMIC oder HORIZON ||nach welchem ASTRO-Modus soll die Abendfahrt berechnet werden
|-
|ASC_autoAstroModeEveningHorizon || - 9 bis 9 || 0|| Höhe über dem Horizont. Wird nur berücksichtigt, wenn im Attribut ASC_autoAstroModeEvening der Wert HORIZON ausgewählt wurde.
|-
|ASC_autoAstroModeMorning || ||REAL, CIVIL, NAUTIC, ASTRONOMIC oder HORIZON || nach welchem ASTRO-Modus soll die Morgendfahrt berechnet werden
|-
|ASC_autoAstroModeMorningHorizon || - 9 bis 9|| 0|| Höhe über dem Horizont. Wird nur berücksichtigt, wenn im Attribut ASC_autoAstroModeMorning der Wert HORIZON ausgewählt wurde.
|-
|ASC_autoShuttersControlComfort ||on, off || off ||schaltet die Komfortfunktion an. Bedeutet, dass ein Rollladen mit einem threestate-Sensor am Fenster beim Öffnen in eine Offenposition fährt. Hierzu muss beim Rollladen das Attribut ASC_ComfortOpen_Pos entsprechend konfiguriert sein.
|-
|ASC_autoShuttersControlEvening ||on, off || ||Aktiviert die automatische Steuerung durch das ASC-Modul am Abend.
|-
|ASC_autoShuttersControlMorning ||on, off || ||Aktiviert die automatische Steuerung durch das ASC-Modul am Morgen.
|-
|ASC_blockASCDrivesAfterManual ||0, 1 || ||wenn dieser Wert auf 1 gesetzt ist, dann werden Rollläden vom ASC-Modul nicht mehr gesteuert, wenn zuvor manuell eingegriffen wurde. Voraussetzung hierfür ist jedoch, dass im Reading ASC_ShuttersLastDrive der Status manual enthalten ist und sich der Rollladen auf eine unbekannte (nicht in den Attributen anderweitig konfigurierte) Position befindet.
|-
|ASC_brightnessDriveUpDown || || || Werte (z.B. Lux) bei dem Schaltbedingungen für Sonnenauf- und -untergang geprüft werden sollen. Diese globale Einstellung kann durch die WERT-MORGENS:WERT-ABENDS Einstellung von ASC_BrightnessSensor im Rollladen selbst überschrieben werden.
|-
|ASC_debug ||0, 1 || 0||Aktiviert die erweiterte Logausgabe für Debugausgaben (nur nach Aufforderung nutzen)
|-
|ASC_expert ||0, 1 ||0 ||ist der Wert 1, so werden erweiterte Informationen bezüglich des NotifyDevs unter ''set und get'' angezeigt
|-
|ASC_freezeTemp ||-5 bis 5 || ||Temperatur, ab welcher der Frostschutz greifen soll und der Rollladen nicht mehr fährt. Der letzte Fahrbefehl wird gespeichert.
|-
|ASC_rainSensor || || ||DEVICENAME[:READINGNAME] MAXTRIGGER[:HYSTERESE] [CLOSEDPOS] - der Inhalt ist eine Kombination aus Devicename, Readingname, Wert ab dem getriggert werden soll, Hysterese Wert ab dem der Status Regenschutz aufgehoben werden soll und der "wegen Regen geschlossen Position".
|-
|ASC_residentsDev || || ||DEVICENAME[:READINGNAME] - der Inhalt ist eine Kombination aus Devicenamen und Readingnamen des Residents-Device der obersten Ebene (z.B. rgr_Residents:state)
|-
|ASC_shuttersDriveDelay || || ||maximale Zufallsverzögerung in Sekunden bei der Berechnung der Fahrzeiten. 0 bedeutet keine Verzögerung
|-
|ASC_tempSensor || || ||DEVICENAME[:READINGNAME] - der Inhalt ist eine Kombination aus Device und Reading für die Außentemperatur
|-
|ASC_twilightDevice || || ||das Device, welches die Informationen zum Sonnenstand liefert. Wird unter anderem für die Beschattung verwendet.
|-
|ASC_windSensor || || ||DEVICE[:READING] - Sensor für die Windgeschwindigkeit. Kombination aus Device und Reading.
|-
| || || ||
|-
| || || ||
|}

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

{| class="wikitable"
|-
! Name !! Datentyp/<BR />Wertebereich !! Default-Wert !! Beschreibung
|-
|ASC || 0, 1, 2|| ||"kein Anlegen der Attribute beim ersten Scan bzw. keine Beachtung eines Fahrbefehles",1 = "Inverse oder Rollo - Bsp.: Rollo oben 0, Rollo unten 100 und der Befehl zum prozentualen Fahren ist position",2 = "Homematic Style - Bsp.: Rollo oben 100, Rollo unten 0 und der Befehl zum prozentualen Fahren ist pct
|-
|ASC_Adv || on, off||||bei on wird das runterfahren des Rollos während der Weihnachtszeit (1. Advent bis 6. Januar) ausgesetzt! Durch set <ASCDEVICE> advDriveDown werden alle ausgesetzten Fahrten nachgeholt.
|-
|ASC_Antifreeze ||off, soft, hard, am, pm || ||Frostschutz, wenn soft fährt der Rollladen in die ASC_Antifreeze_Pos, bei hard/am/pm wird gar nicht oder innerhalb der entsprechenden Tageszeit nicht gefahren
|-
|ASC_Antifreeze_Pos || || ||Position des Rolllades die angefahren werden soll, wenn der Fahrbefehl komplett schließen lautet, aber der Frostschutz aktiv ist !!!Verwendung von Perlcode ist möglich, dieser muss in {} eingeschlossen sein. Rückgabewert muss eine positive Zahl/Dezimalzahl sein!!!
|-
|ASC_autoAstroModeEvening ||REAL, CIVIL, NAUTIC, ASTRONOMIC oder HORIZON || ||nach welchem ASTRO-Modus soll die Abendfahrt berechnet werden
|-
|ASC_autoAstroModeEveningHorizon || - 9 bis 9 || 0|| Höhe über dem Horizont. Wird nur berücksichtigt, wenn im Attribut ASC_autoAstroModeEvening der Wert HORIZON ausgewählt wurde.
|-
|ASC_autoAstroModeMorning ||REAL, CIVIL, NAUTIC, ASTRONOMIC oder HORIZON || || nach welchem ASTRO-Modus soll die Morgendfahrt berechnet werden
|-
|ASC_autoAstroModeMorningHorizon || - 9 bis 9|| 0|| Höhe über dem Horizont. Wird nur berücksichtigt, wenn im Attribut ASC_autoAstroModeMorning der Wert HORIZON ausgewählt wurde.
|-
|ASC_BlockingTime_afterManual || ||1200 ||wie viel Sekunden soll die Automatik nach einer manuellen Fahrt aussetzen
|-
|ASC_BlockingTime_beforeDayOpen || ||3600 ||wie viel Sekunden vor dem morgendlichen öffnen soll keine schließen Fahrt mehr stattfinden.
|-
|ASC_BlockingTime_beforeNightClose || ||3600 ||ie viel Sekunden vor dem nächtlichen schließen soll keine öffnen Fahrt mehr stattfinden.
|-
|ASC_BrightnessSensor || ||none ||DEVICE[:READING] WERT-MORGENS:WERT-ABENDS / 'Sensorname[:brightness [400:800]]' Angaben zum Helligkeitssensor mit (Readingname, optional) für die Beschattung und dem Fahren der Rollladen nach brightness und den optionalen Brightnesswerten für Sonnenauf- und Sonnenuntergang
|-
|ASC_Closed_Pos || ||default Vorgabe ist abhängig vom Attribut ''ASC''||in 10er-Schritten von 0 bis 100
wird angefahren wenn SelfDefense aktiv ist
|-
|ASC_ComfortOpen_Pos || || || in 10er Schritten von 0 bis 100 !!! Die eingestellte Position wird bei einem threestate Sensor angefahren. Verwendung von Perlcode ist möglich, dieser muss in {} eingeschlossen sein. Rückgabewert muss eine positive Zahl/Dezimalzahl sein!!!
|-
|ASC_Down || time, astro, brightness, roommate || astro||bei ''astro'' wird Sonnenuntergang berechnet, bei time wird der Wert aus ASC_Time_Down_Early als Fahrzeit verwendet und bei brightness muss ASC_Time_Down_Early und ASC_Time_Down_Late korrekt gesetzt werden. Der Timer läuft dann nach ASC_Time_Down_Late Zeit, es wird aber in der Zeit zwischen ASC_Time_Down_Early und ASC_Time_Down_Late geschaut, ob die als Attribut im Moduldevice hinterlegte ASC_brightnessDriveUpDown der Down Wert erreicht wurde. Wenn ja, wird der Rollladen runter gefahren.
|-
|ASC_DiveUpMaxDuration || || 60||die Dauer des Hochfahrens des Rollladens plus 5 Sekunden
|-
|ASC_Drive_Delay || || -1|| maximaler Wert für einen zufällig ermittelte Verzögerungswert in Sekunden bei der Berechnung der Fahrzeiten, 0 bedeutet keine Verzögerung, -1 bedeutet, dass das ??gleichwertige Attribut?? aus dem ASC Device ausgewertet werden soll
|-
|ASC_Drive_DelayStart || || -1|| in Sekunden verzögerter Wert ab welchen dann erst das Offset startet und dazu addiert wird. Funktioniert nur wenn gleichzeitig ASC_DriveDelay gesetzt wird.
|-
|ASC_ExternalTrigger || |||| DEVICE:READING VALUEACTIVE:VALUEINACTIVE POSACTIVE:POSINACTIVE, Beispiel: "WohnzimmerTV:state on:off 66:100" bedeutet das wenn ein "state:on" Event kommt soll das Rollo in Position 66 fahren, kommt ein "state:off" Event soll es in Position 100 fahren. Es ist möglich die POSINACTIVE weg zu lassen dann fährt das Rollo in LastStatus Position.
|-
|ASC_GuestRoom || on, off |||| aktuell noch nicht umgesetzt...
|-
|ASC_LockOut || soft, hard, off ||off || stellt entsprechend den Aussperrschutz ein. Bei global aktivem Aussperrschutz (set ASC-Device lockOut soft) und einem Fensterkontakt open bleibt dann der Rollladen oben. Dies gilt nur bei Steuerbefehlen über das ASC Modul. Stellt man global auf hard, wird bei entsprechender Möglichkeit versucht den Rollladen hardwareseitig zu blockieren. Dann ist auch ein Fahren über die Taster nicht mehr möglich
|-
|ASC_LockOut_Cmd || inhibit, blocked, protection ||none|| set Befehl für das Rollladen-Device zum Hardware sperren. Dieser Befehl wird gesetzt werden, wenn man "ASC_LockOut" auf hard setzt
|-
|ASC_Mode_Down ||absent, always, off, home || always ||Wann darf die Automatik steuern. immer, niemals, bei Abwesenheit des Roommate (ist kein Roommate und absent eingestellt, wird gar nicht gesteuert)
|-
|ASC_Mode_Up ||absent, always, off, home || always ||Wann darf die Automatik steuern. immer, niemals, bei Abwesenheit des Roommate (ist kein Roommate und absent eingestellt, wird gar nicht gesteuert)
|-
|ASC_Open_Pos || ||default Vorgabe ist abhängig vom Attribut ''ASC''||in 10er-Schritten von 0 bis 100
|-
|ASC_Partymode || on, off || off ||schaltet den Partymodus an oder aus. Wird am ASC Device set ASC-DEVICE partyMode on geschalten, werden alle Fahrbefehle an den Rollläden, welche das Attribut auf on haben, zwischengespeichert und später erst ausgeführ
|-
|ASC_Pos_Reading || || ||Name des Readings, welches die Position des Rollladen in Prozent angibt. Wird bei unbekannten Device-Typen auch als ''set'' Befehl zum Fahren verwendet
|-
|ASC_PrivacyDownValue_beforNightClose || || -1||wie viele Sekunden vor dem abendlichen schließen soll der Rollladen in die Sichtschutzposition fahren, oder bei Brightness ab welchem minimum Brightnesswert soll das Rollo in die Privacy Position fahren. Bei Brightness muss zusätzlich zum Zeitwert der Brightnesswert mit angegeben werden 1800:300 bedeutet 30 min vor night close oder bei unter einem Brightnesswert von 300
|-
|ASC_PrivacyDown_Pos || ||50||Position den Rollladens für den abendlichen Sichtschutz!Verwendung von Perlcode ist möglich, dieser muss in {} eingeschlossen sein. Rückgabewert muss eine positive Zahl/Dezimalzahl sein!!!
|-
|ASC_PrivacyUpValue_beforDay || || -1||wie viele Sekunden vor dem morgendlichen öffnen soll der Rollladen in die Sichtschutzposition fahren, oder bei Brightness ab welchem minimum Brightnesswert soll das Rollo in die Privacy Position fahren. Bei Brightness muss zusätzlich zum Zeitwert der Brightnesswert mit angegeben werden 1800:600 bedeutet 30 min vor day open oder bei über einem Brightnesswert von 600
|-
|ASC_PrivacyUp_Pos || ||50||Position den Rollladens für den morgendlichen Sichtschutz!Verwendung von Perlcode ist möglich, dieser muss in {} eingeschlossen sein. Rückgabewert muss eine positive Zahl/Dezimalzahl sein!!!
|-
|ASC_RainProtection ||on, off || ||soll der Rollladen beim Regenschutz beachtet werden. on=JA, off=NEIN.
|-
|ASC_Roommate_Device || || none ||mit Komma getrennte Namen des/der Roommate-Device/s welche den/die Bewohner des Rollladen-Raumes wiedergibt. Macht nur Sinn in Schlaf- oder Kinderzimmern
|-
|ASC_Roommate_Reading || || ||Reading des Roommate-Device, welches den Status wieder gibt
|-
|ASC_Self_Defense_AbsentDelay || || 300||um wie viele Sekunden soll das fahren in Selfdefense bei Residents absent verzögert werden
|-
|ASC_Self_Defense_Mode || || gone||ab welchen Residents Status soll Selfdefense aktiv werden ohne das Fenster auf sind
|-
|ASC_Shading_InOutAzimuth || ||95:265 ||Azimut Wert ab dem bei Überschreiten Beschattet und bei Unterschreiten Endschattet werden soll
|-
|ASC_Shading_MinMax_Elevation || ||25.0:100.0 ||ab welcher min Höhe des Sonnenstandes soll beschattet und ab welcher max Höhe wieder beendet werden, immer in Abhängigkeit der anderen einbezogenen Sensorwerte
|-
|ASC_Shading_MinOutsideTemperature_ || ||18 ||ab welcher Temperatur soll Beschattet werden, immer in Abhängigkeit der anderen einbezogenen Sensorwert
|-
|ASC_ShadingMode ||absent, always, off, home || off||wann soll die Beschattung nur stattfinden
|-
|ASC_Shading_Pos || || ||Position des Rollladens für die Beschattung !!!Verwendung von Perlcode ist möglich, dieser muss in {} eingeschlossen sein. Rückgabewert muss eine positive Zahl/Dezimalzahl sein!!!
|-
|ASC_Shading_StateChange_SunnyCloudy || ||35000:20000 ||Brightness Wert ab welchen die Beschattung stattfinden und aufgehoben werden soll, immer in Abhängigkeit der anderen einbezogenen Sensorwerte
|-
|ASC_Shading_WaitingPeriod || ||1200 ||wie viele Sekunden soll gewartet werden bevor eine weitere Auswertung der Sensordaten für die Beschattung stattfinden soll
|-
|ASC_Shutter_IdleDetection || ||||READING:VALUE gibt das Reading an welches Auskunft über den Fahrstatus des Rollos gibt, sowie als zweites den Wert im Reading welcher aus sagt das das Rollo nicht fährt
|-
|ASC_ShuttersPlace || window, terrace || ||wenn dieses Attribut auf ''terrace'' gesetzt ist und das Residents-Device in den Status ''absent'' geht, ''selfDefence'' aktiv ist und das Fenster geöffnet ist, wird das Rollo geschlossen. Wenn ein twostate Senso genutzt wird und dieses Attribut auf ''terrace'' gesetzt ist wird ASC_Ventilate_Pos ignoriert und das Rollo wird beim öffnen des Fenster komplett geöffnet. Wenn dieses Attribut auf ''window'' gesetzt ist wird ASC_Ventilate_Pos berücksichtigt und das Rollo wird entsprechend der ASC_Ventilate_Pos geöffnet. Wenn das Fenster wieder geschlossen wird, dann wird das Rollo unabhängig von ''windows oder terrace'' vollständig geschlossen.
|-
|ASC_Sleep_Pos || || ||in 10er-Schritten von 0 bis 100, default Vorgabe ist abhängig vom Attribut ''ASC.'' Position wird angefahren wenn Bedingung für modeDown aktiv ist. Hiermit kann z.B. das komplette abendliche Schließen des Rollos begrenzt werden.
|-
|ASC_TempSensor || || ||DEVICENAME[:READINGNAME] - der Inhalt ist eine Kombination aus Device und Reading für die Außentemperatur
|-
|ASC_Time_Down_Early || ||16:00 ||Sonnenuntergang frühste Zeit zum Runterfahren !!!Verwendung von Perlcode ist möglich, dieser muss in {} eingeschlossen sein. Rückgabewert muss ein Zeitformat in Form HH:MM[:SS] sein!!!
|-
|ASC_Time_Down_Late || ||22:00 ||Sonnenuntergang späteste Zeit zum Runterfahren !!!Verwendung von Perlcode ist möglich, dieser muss in {} eingeschlossen sein. Rückgabewert muss ein Zeitformat in Form HH:MM[:SS] sein!!!
|-
|ASC_Time_Up_Early || || 05:00||Sonnenaufgang frühste Zeit zum Hochfahren !!!Verwendung von Perlcode ist möglich, dieser muss in {} eingeschlossen sein. Rückgabewert muss ein Zeitformat in Form HH:MM[:SS] sein!!!
|-
|ASC_Time_Up_Late || ||08:30 ||Sonnenaufgang späteste Zeit zum Hochfahren !!!Verwendung von Perlcode ist möglich, dieser muss in {} eingeschlossen sein. Rückgabewert muss ein Zeitformat in Form HH:MM[:SS] sein!!!
|-
|ASC_Time_Up_WE_Holiday || ||08:00 ||Sonnenaufgang frühste Zeit zum Hochfahren am Wochenende und/oder Urlaub (holiday2we wird beachtet).ACHTUNG!!! in Verbindung mit Brightness für ASC_Up muss die Uhrzeit kleiner sein wie die Uhrzeit aus ASC_Time_Up_Late !!!Verwendung von Perlcode ist möglich, dieser muss in {} eingeschlossen sein. Rückgabewert muss ein Zeitformat in Form HH:MM[:SS] sein!!!
|-
|ASC_Ventilate_Window_Open ||on, off ||on||auf lüften, wenn das Fenster gekippt/geöffnet wird und aktuelle Position unterhalb der Lüften-Position ist
|-
|ASC_WiggleValue || ||5 ||Wert, um welchen sich die Position des Rollladens bei ''Wiggle'' ändern soll
|-
|ASC_WindParameters || ||5 ||TRIGGERMAX[:HYSTERESE] [DRIVEPOSITION] / Angabe von Max Wert ab dem für Wind getriggert werden soll, Hytsrese Wert ab dem der Windschutz aufgehoben werden soll TRIGGERMAX - HYSTERESE / Ist es bei einigen Rollläden nicht gewünscht das gefahren werden soll, so ist der TRIGGERMAX Wert mit -1 an zu geben. (default: '50:20 ClosedPosition')
|-
|ASC_WindProtection ||on, off || ||soll der Rollladen beim Windschutz beachtet werden. on=JA, off=NEIN.
|-
|ASC_WindowRec || ||none ||Name des Fensterkontakts, an welchen Fenster der Rollladen angebracht ist. WINDOWREC:[READING], Name des Fensterkontaktes, an dessen Fenster der Rollladen angebracht ist. Reading ist optional
|-
|ASC_WindowRec_PosAfterDayClosed ||open, lastManual ||open ||Name des Fensterkontakts, an welchen Fenster der Rollladen angebracht ist. Sein Reading ''state'' muss die Werte ''open'', ''closed'' oder ''tilted'' enthalten.
|-
|ASC_WindowRec_subType ||twostate, threestate ||twostate||Typ des verwendeten Fensterkontaktes: twostate (optisch oder magnetisch) oder threestate (Drehgriffkontakt)
|-
| || || ||
| || || ||
|-
| || || ||
|-
| || || ||
|-
| || || ||
|}

== Hilfsmittel ==
{{Hinweis|Die Device-Namen sind auf die eigene Installation anzupassen.}}

{{Hinweis|Codezeilen sind im [[Import von Code Snippets|RAW]]-Format.}}

{{Randnotiz|RNTyp=g|RNText= Stand 2019-05-03
* Erfolgreich getestet mit Homematic Devices, Beta-User
* Die Farbgebung entspricht dem Standard, wenn unter dem Style f18 der Farbpreset ''light'' gewählt wird.
}}

=== readingsGroup für Level ===
<pre style="width:65%;word-wrap: break-word;">defmod rg_ASC_Rolllaeden_Level readingsGroup <Gerät>,<Stand>,<Schliessen bis>,<Öffnen auf>,<Beschattung>,<Komfort>,<Lüften>,<Privacy> (Rollladen_.*|Jalousie_.*)..:level,!?ASC_Closed_Pos,!?ASC_Open_Pos,!?ASC_Shading_Pos,!?ASC_ComfortOpen_Pos,!?ASC_Ventilate_Pos,!?ASC_PrivacyDown_Pos
attr rg_ASC_Rolllaeden_Level commands {level => 'pct:selectnumbers,0,5,100,0,lin',\
ASC_Closed_Pos => 'ASC_Closed_Pos:selectnumbers,0,5,100,0,lin',\
ASC_Open_Pos => 'ASC_Open_Pos:selectnumbers,0,5,100,0,lin',\
ASC_Shading_Pos => 'ASC_Shading_Pos:selectnumbers,0,5,100,0,lin',\
ASC_Ventilate_Pos => 'ASC_Ventilate_Pos:selectnumbers,0,5,100,0,lin',\
ASC_ComfortOpen_Pos => 'ASC_ComfortOpen_Pos:selectnumbers,0,5,100,0,lin',\
ASC_PrivacyDown_Pos => 'ASC_PrivacyDown_Pos:selectnumbers,0,5,100,0,lin'}
</pre>

=== readingsGroup für Zeiten ===
[[Bild:ReadingsGroup ASC times.png|thumb|right|ReadingsGroup - Zeitenbeispiel]]
<pre style="width:65%;word-wrap: break-word;">defmod rg_ASC_Rolllaeden_Times readingsGroup <Gerät>,<Position>,<Time_Up_Early>,<Time_Up_Late>,<Time_Up_WE/Hol>,<Time_Down_Early>,<Time_Down_Late>,<Mode_Down>,<Mode_Up> \
(.*Rollo.*|.*Rollladen|Jalousie_.*):level,!?ASC_Time_Up_Early,!?ASC_Time_Up_Late,!?ASC_Time_Up_WE_Holiday,!?ASC_Time_Down_Early,!?ASC_Time_Down_Late,!?ASC_Mode_Down,!?ASC_Mode_Up
attr rg_ASC_Rolllaeden_Times commands {level => 'pct:0,10,20,30,35,40,45,50,55,60,65,70,75,80,85,90,95,100', \
ASC_Time_Down_Early => 'ASC_Time_Down_Early:15:00,15:15,15:30,15:45,16:00,16:15,16:30,16:45,17:00,17:15,17:30,17:45,18:00,18:15,18:30,18:45,19:00,19:15,19:30,19:45,20:00,20:15,20:30,20:45,21:00,21:15,21:30,21:45,22:00', \
ASC_Time_Down_Late => 'ASC_Time_Down_Late:19:00,19:15,19:30,19:45,20:00,20:15,20:30,20:45,21:00,21:15,21:30,21:45,22:00,22:15,22:30,22:45,23:00,23:15,23:30', \
ASC_Time_Up_WE_Holiday => 'ASC_Time_Up_WE_Holiday:06:00,06:15,06:30,06:45,07:00,07:15,07:30,07:45,08:00,08:15,08:30,08:45,09:00,09:15,09:30,09:45,10:00',\
ASC_Time_Up_Early => 'ASC_Time_Up_Early:05:00,05:05,05:30,05:55,06:00,06:15,06:30,06:45,07:00,07:15,07:30,07:45,08:00,08:15,08:30,08:45,09:00,09:15,09:30,09:45,10:00', \
ASC_Time_Up_Late => 'ASC_Time_Up_Late:06:00,06:15,06:30,06:45,07:00,07:15,07:30,07:45,08:00,08:15,08:30,08:45,09:00,09:15,09:30,09:45,10:00', \
ASC_Mode_Down => 'ASC_Mode_Down:always,absent,off', \
ASC_Mode_Up => 'ASC_Mode_Up:always,absent,off' }
attr rg_ASC_Rolllaeden_Times room Rollladen</pre>

[[Bild:ASC RG Zeiten HM ZWave Siro.png|thumb|right|ReadingsGroup - CUL_HM+ZWave+Siro mit widgets]]Neue Version mit time-Widgets und pct/dim/position-widget (5-er Schritte), passend für CUL_HM, ZWave und Siro-Geräte:
<pre style="width:65%;word-wrap: break-word;">defmod rg_ASC_Rolllaeden_Times readingsGroup <Gerät>,<Stand>,<Time_Up_Early >,<Time_Up_WE >,<Time_Up_Late >,<Time_Down_Early>,<Time_Down_Late>,<Mode_Down>,<Mode_Up> (Rollo_.*|Jalousie_.*)..:(level|dim|position),!?ASC_Time_Up_Early,!?ASC_Time_Up_WE_Holiday,!?ASC_Time_Up_Late,!?ASC_Time_Down_Early,!?ASC_Time_Down_Late,!?ASC_Mode_Down,!?ASC_Mode_Up
attr rg_ASC_Rolllaeden_Times commands {level => 'pct:selectnumbers,0,5,100,0,lin', \
dim => 'dim:selectnumbers,0,5,99,0,lin',\
position => 'pct:selectnumbers,0,5,99,0,lin',\
ASC_Mode_Down => 'ASC_Mode_Down:always,absent,off',\
ASC_Mode_Up => 'ASC_Mode_Up:always,absent,off',\
ASC_Time_Down_Early => 'ASC_Time_Down_Early:time', \
ASC_Time_Down_Late => 'ASC_Time_Down_Late:time',\
ASC_Time_Up_Early => 'ASC_Time_Up_Early:time', \
ASC_Time_Up_Late =>'ASC_Time_Up_Late:time',\
ASC_Time_Up_WE_Holiday =>'ASC_Time_Up_WE_Holiday:time'}
attr rg_ASC_Rolllaeden_Times room Rollladen
</pre>

=== readingsGroup für FIBARO Roller Shutter FGR-222 Devices ===
{{Randnotiz|RNTyp=g|RNText=Getestet von majestro84, Stand 2019-01-28.
* {{Link2Forum|Topic=92628|Message=897099|LinkText=Forenbeitrag dazu}}
* Die Farbgebung entspricht dem Standard, wenn unter dem Style f18 der Farbpreset ''dark'' gewählt wird}}
[[Bild:ASC Jalousien Times.JPG|thumb|right|Beispiel]]
<pre style="width:65%;word-break: break-all;word-wrap: break-word;">define ASC_Jalousien_Times readingsGroup <Gerät>,<Stand>,<Time_Up_Early>,<Time_Up_WE>,<Time_Up_Late>,<Time_Down_Early>,<Time_Down_Late>,<Mode_Down>,<Mode_Up>,<PartyMode>,<LockOut> (.*_Jalousie.*):position,!?ASC_Time_Up_Early,!?ASC_Time_Up_WE_Holiday,!?ASC_Time_Up_Late,!?ASC_Time_Down_Early,!?ASC_Time_Down_Late,!?ASC_Mode_Down,!?ASC_Mode_Up,!?ASC_Partymode,!?ASC_LockOut

attr ASC_Jalousien_Times commands {position => 'dim:0,10,20,30,35,40,45,50,55,60,65,70,75,80,85,90,95,99',
ASC_Mode_Down => 'ASC_Mode_Down:always,absent,off',
ASC_Mode_Up => 'ASC_Mode_Up:always,absent,off',
ASC_Partymode => 'ASC_Partymode:on,off',
ASC_LockOut => 'ASC_LockOut:soft,hard,off',
ASC_Time_Down_Early => 'ASC_Time_Down_Early:15:00,15:15,15:30,15:45,16:00,16:15,16:30,16:45,17:00,17:15,17:30,17:45,18:00,18:15,18:30,18:45,19:00,19:15,19:30,19:45,20:00,20:15,20:30,20:45,21:00,21:15,21:30,21:45,22:00',
ASC_Time_Down_Late => 'ASC_Time_Down_Late:20:15,20:30,20:45,21:00,21:15,21:30,21:45,22:00,22:15,22:30,22:45,23:00,23:15,23:30',
ASC_Time_Up_Early => 'ASC_Time_Up_Early:05:00,05:05,05:30,05:45,06:00,06:15,06:30,06:45,07:00,07:15,07:30,07:45,08:00,08:15,08:30,08:45,09:00,09:15,09:30,09:45,10:00',
ASC_Time_Up_Late =>'ASC_Time_Up_Late:06:00,06:15,06:30,06:45,07:00,07:15,07:30,07:45,08:00,08:15,08:30,08:45,09:00,09:15,09:30,09:45,10:00',
ASC_Time_Up_WE_Holiday => 'ASC_Time_Up_WE_Holiday:06:00,06:15,06:30,06:45,07:00,07:15,07:30,07:45,08:00,08:15,08:30,08:45,09:00,09:15,09:30,09:45,10:00'}
attr ASC_Jalousien_Times room Jalousien</pre>

[[Bild:ASC Jalousien Level.JPG|thumb|right|Beispiel]]
<pre style="width:65%;word-break: break-all;word-wrap: break-word;"> define Jalousien_Level readingsGroup <Gerät>,<Closed_Pos>,<Open_Pos>,<Comfort_Pos>,<Ventilate_Pos>,<PrivacyDown_Pos>,<Shading_Pos> (.*_Jalousie.*):!?ASC_Closed_Pos,!?ASC_Open_Pos,!?ASC_ComfortOpen_Pos,!?ASC_Ventilate_Pos,!?ASC_PrivacyDown_Pos,!?ASC_Shading_Pos
attr Jalousien_Level commands { ASC_Closed_Pos => 'ASC_Closed_Pos:0,10,20,30,35,40,45,50,55,60,65,70,75,80,85,90,95,99',
ASC_Open_Pos => 'ASC_Open_Pos:0,10,20,30,35,40,45,50,55,60,65,70,75,80,85,90,95,99',
ASC_ComfortOpen_Pos => 'ASC_ComfortOpen_Pos:0,10,20,30,35,40,45,50,55,60,65,70,75,80,85,90,95,99',
ASC_Ventilate_Pos => 'ASC_Ventilate_Pos:0,10,20,30,35,40,45,50,55,60,65,70,75,80,85,90,95,99',
ASC_PrivacyDown_Pos => 'ASC_PrivacyDown_Pos:0,10,20,30,35,40,45,50,55,60,65,70,75,80,85,90,95,99',
ASC_Shading_Pos => 'ASC_Shading_Pos:0,10,20,30,35,40,45,50,55,60,65,70,75,80,85,90,95,99'}
attr Jalousien_Level room Jalousien</pre>

== Einrichtungsbeispiel (nach Sonnenstand) ==
=== Ziel und Vorgaben ===
Es sollen die Rollläden und Jalousien innerhalb bestimmter zeitlicher Perioden sonnenstandsabhängig geöffnet und geschlossen werden. An den Wochenenden und an Ferientagen soll etwas später geöffnet werden. Es sind Tür- und Fensterkontakte vorhanden (Türkontakte: twoState, Fensterkontakte: threeState), wobei bei jeder Öffnung ein eventuell geschlossener Rollladen geöffnet werden soll. Bei allen Rollladenaktoren, Tür- und Fensterkontakten handelt es sich um CUL_HM-Geräte.

=== Vorarbeiten ===
Im global-Device sind Angaben zu latitude und longitude vorhanden, holiday2we wie folgt<ref>''ferien'' ist eine automatisiert erstellte holiday-Datei nach diesem {{Link2Forum|Topic=85759|Message=885883|LinkText=Foren-Beitrag}}.</ref>:
attr global holiday2we bw,ferien
Weitere Angaben werden zunächst nicht benötigt, das Astro-Device wird erst in der Beschattungskonfiguration definiert.
Dann erfolgt das ''Define des ASC-Devices'' wie oben beschrieben:
<code>define Rollladenautomatik AutoShuttersControl</code>
Folgen die einzubindenden Rollladenaktoren einem einheitlichen Namensschema, können diese sodann z.B. mit
attr (Jalousie|Rollladen)_.* ASC 2
auf einen Rutsch mit dem passenden ASC-Typ gekennzeichnet werden.

{{Hinweis|Achtung: Das AutoShuttersControl-Device selbst darf kein ASC-Attribut bekommen!}}

Dann werden mit
set Rollladenautomatik scanForShutters
die nachfolgend weiter zu bearbeitenden Attribute angelegt.
=== Schließen morgens und abends ===
{{Randnotiz|RNTyp=g|RNText=Alternative: Fahren nach brightness:
Soll insgesamt oder an einzelnen Rollläden helligkeitsgesteuert gefahren werden, muß zentral oder für jeden Rollladen ein Helligkeitssensor definiert und die Helligkeitsgrenzwerte festgelegt sein (''ASC_BrightnessSensor'' etc.), bei deren Überschreitung geöffnet bzw. Unterschreitung geschlossen werden soll.}}
==== Konfiguration des ASC-Devices ====
Sonnenstandsabhängige Fahrzeiten werden wie folgt aktiviert:
<pre>
attr Rollladenautomatik ASC_autoAstroModeEvening CIVIL
attr Rollladenautomatik ASC_autoAstroModeMorning CIVIL
</pre>
Aus der Angabe ''CIVIL'' und den Vorgaben in den einzelnen Rollladen wird dabei mit Hilfe von [[SUNRISE_EL]] die effektive Fahrzeit berechnet, dort finden sich auch weitere Hinweise, zu den meisten anderen Optionen für die ersten beiden Attribute.
Bei allen Fensteröffnungen soll auf eine Lüften-Position gefahren werden, also schalten wir diese Funktion ebenfalls zentral an<ref>Sonst wird bei threeState-Sensoren nur bei ''tilted'' auf die in ''ASC_Ventilate_Pos'' gefahren.</ref>:
attr Rollladenautomatik ASC_autoShuttersControlComfort on
Zuletzt legen wir noch einen Temperatur-Sensor fest. Dieser wird beim Frostschutz sowie bei der Beschattung berücksichtigt.
<pre>
attr Rollladenautomatik ASC_tempSensor Aussentemperatur_Nord:temperature
attr Rollladenautomatik ASC_freezeTemp 3
</pre>{{Hinweis|Achtung: Für jede weitere Sensor-Information (z.B. zu Regen oder Wind) muß ein eigenes Device verwendet werden. Sollen unterschiedliche Readings desselben Sensors ausgewertet werden, müssen diese in ein eigenes Device übertragen werden, z.B. über einen readingsProxy mit gesetztem event-on-update-reading-Attribut (sonst triggert dieser nicht bei Aktualisierung des Readings)!}}

tbd:
* Rain
* Wind
==== Konfiguration der Rollladendevices ====
{{Hinweis|Positionen dürfen sich innerhalb eines Rollos nicht überschneiden - Auch ASC_Closed_Pos 100 ASC_Shading_Pos 98 ASC_ComfortOpen_Pos 97 usw... sind bereits unterschiedliche Positionen.}}

===== Fahrzeiten =====
Zur Konfiguration der Fahrzeiten bietet es sich an, eine ReadingsGroup zu nutzen, wie unter [[#Hilfsmittel|Hilfsmittel]] dargestellt. Alternativ kann man die Zeiten auch manuell in den einzelnen Rollläden hinterlegen.
===== Bewohner =====
Wird ein Raum von einer oder mehreren bestimmten Person/en bewohnt oder gibt es ein Sammel-Gerät für mehrere Bewohner, kann dies mit den Attributen ''ASC_Roommate_Device'' und ''ASC_Roommate_Reading'' einem Rollladen zugeordnet werden. Ist einer der Bewohner ''asleep'', wird morgens erst geöffnet, wenn auch der letzte Roommate nicht mehr ''asleep'' ist.
===== Fensterkontakte =====
Dann werden ggf. vorhandene Fensterkontakte mit ''ASC_WindowRec'' zugeordnet und der Sensortyp mit ''ASC_WindowRec_subType'' festgelegt. Im Falle von threeState-Sensoren wird das übergreifende ''ASC_autoShuttersControlComfort'' beachtet, wobei dann bei vollständiger Öffnung des Fensters auf den in ''ASC_ComfortOpen_Pos'' festgelegten Wert gefahren wird.
===== Frostschutz =====
Zuletzt können die Attribute ''ASC_Antifreeze'' und ''ASC_Antifreeze_Pos'' festgelegt werden, wenn die Frostschutzfunktion aktiviert werden soll.

=== Beschattung ===
==== Konfiguration des ASC-Devices ====
Im ASC DEVICE das Reading "controlShading" auf ''on'', sowie ein Astro/Twilight Device im Attribut "ASC_twilightDevice" und das Attribut "ASC_tempSensor" definieren.

==== Konfiguration der Rollladendevices ====
Es wird ein Helligkeitssensor als Attribut "ASC_BrightnessSensor" benötigt. Wird der Sensor nur für die Beschattung verwendet, ist der Wert DEVICENAME[:READING] ausreichend.
Alle weiteren Attribute sind optional und wenn nicht gesetzt mit Default-Werten belegt. Sie sollten entsprechend der Gegebenheiten angepasst werden. Die Werte für die Fensterposition und den Vor-/Nachlaufwinkel ''(ASC_Shading_InOutAzimuth)'' sowie die Grenzwerte für <code>''ASC_shading_StateChange_SunnyCloudy''</code> sind besonders wichtig.

==== Bedingungen ====
Damit die Beschattung startet müssen '''alle''' Bedingungen erfüllt sein. Entschattet wird, sobald '''eine''' der Bedingungen wegfällt und die Zeit entsprechend <code>ASC_Shading_WaitingPeriod</code> abgelaufen ist.

Der Sonnensensor <ASC_BrightnessSensor> muss mindestens zwei Messwerte geliefert haben, bevor das ASC-Modul in die Beschattungsposition fährt! Beim (zeitlich) ersten Messwert wird der Zustand ''in-reserved'' gesetzt. Erst beim zweiten Messwert wechselt der Zustand nach ''in shading''. Die Anzahl der berücksichtigten Messwerte ist abhängig vom "moving average window", der mit dem dritten Parameter des Attributs ''ASC_Shading_StateChange_SunnyCloudy'' konfiguriert wird.

'''Von Standardwerten ausgehend ist nachfolgender Ablauf angestrebt:'''
# Ein Event vom Astro oder Helligkeits Device kommt -> sind alle Werte innerhalb des Arbeitsbereiches, ändert sich der ASC Info-Zustand im Rollo von xx auf „in reserved“ (Beschattung vorbereitet)
# Ein erneutes Event vom Astro oder Helligkeits Device kommt -> Überprüfung der Werte -> sind diese weiterhin gegeben folgt der Wechsel von „in reserved“ auf „in“ (Beschattung aktiv)
# Bei Verwendung von ''ASC_Shading_StateChange_SunnyCloudy'' ist zu beachten, dass ein Durchschnitt über die letzten drei Brightness Events gerechnet wird. Möchte man das vermeiden muss man SUNNY:CLOUDY 1[2] setzen.
# Die Zeiten ''ASC_Shading_WaitingPeriod'' und ''ASC_BlockingTime_afterManual'' können hier zusätzlich für eine Verzögerung sorgen.
'''Wichtig zu beachten:''' Es müssen immer mehrere (mind. 2) Events für den Betrieb erfolgen. In den Standardeinstellungen vom Astro Modul erfolgt dieses z.B. nur 1 x pro Stunde. Kommt also ein Helligkeits-Event auch nur 1x pro Stunde, könnte es 2 Std dauern, bis die Beschattungsfunltion greift.

Wenn das Rollo einmal aus der Beschattung manuell (im Rollo Device muss bei ''ASC_ShuttersLastDrive manuel'' stehen gefahren wurde wird das Rollo erst wieder nach einer Entschattung und erneuter Beschattung gefahren. Also es muss einmal shading out kommen und beim nächsten shading in fährt er dann wieder.

=== Weitere Funktionen ===
==== WeekendHoliday Funktion im Brightnessbetrieb ====
Am Wochenende oder Feiertag und wenn am ASC-Device sunriseTimeWeHoliday aktiviert sowie im Rollo das Attribut ASC_Time_Up_WE_Holiday gesetzt sind, wird zur angegebenen ASC_Time_Up_WE_Holiday Zeit das Rollo geöffnet, ungeachtet des Brightnesswertes.

==== Privacy ====
Werden hierfür Werte festgelegt, werden die betreffenden Rollläden die festgelegte Zeit/Helligkeit vor dem abendlichen Schließen vorab teilweise geschlossen. Dies kann z.B. gewünscht sein, um Rollläden zur Straße hin mit viel Fußgängerverkehr zwar nicht vollständig abzudunkeln, aber gleichzeitig zu verhindern, dass von außen in Wohnräume geschaut werden kann, sobald dort das Licht angeschaltet wird

==== BlockingTime====
Bewirkt, dass nach einer manuellen Fahrt, eine vom ASC Modul initiierte Fahrt zunächst ausgesetzt wird, bis die im Attribute angegebene Zeit überschritten ist. Erst dann wird eine vom ASC Modul initiierte Fahrt tatsächlich durchgeführt.
Genau so wird ein Hochfahren eines Rollos durch das ASC Modul nicht mehr ausgeführt, wenn es innerhalb der Zeit von ASC_BlockingTime_beforNightClose und das Runterfahren wird nicht mehr erfolgen, wenn es innerhalb von ASC_BlockingTime_beforDayOpen ist.
Beispiel: Meine Tochter geht früh außer Haus und Ihre Rollos sind nicht hochgefahren. Diese fahren auch nicht mehr hoch, da die ausschließlich bei home (anwesend) fahren sollen. Nun kommt sie am Nachmittag um 16:23 Uhr nach Hause. Eigentlich sollten nun die Rollos fahren. Doch die Sonnenuntergangsfahrt (schließen) wäre schon 16:51 Uhr und damit innerhalb der 3600 ASC_BlockingTime_beforNightClose. Die Rollos bleiben also unten. Es lohnt sich für die paar Minuten einfach nicht mehr.

==== wiggle====
Mit einem <code>set <ASC-Device> wiggle</code> können alle Rollladen mit einem entsprechenden Attribut zu einer kurzen Fahrt veranlasst werden, nach Ablauf von einer Minute wieder um denselben Wert zurück. Dabei wird jeweils in die Richtung gefahren, die den weiteren Weg ermöglicht. Wenn also zu 70% geschlossen ist, wird der Rollladen hoch fahren.
==== Partymode ====
Dieser wird am ASC-Device selbst aktiviert mittels <code>set <ASC-Device> partyMode on</code>. Alle Rollladen-Devices, welche das Attribut ''ASC_Partymode'' auf ''on'' gestellt haben, werden nicht mehr gesteuert. Der letzte Schaltbefehl, der durch ein Fensterevent oder Bewohnerstatus an die Rollläden gesendet wurde, beim Beenden des Modus durch <code>set ASC-Device partyMode off</code> ausgeführt.
==== lock-out ====
Man kann mit dem Befehl <code> set <ASC-Device> hardLockOut</code> auf einen Schlag alle Rollos sperren welche <code> attr <ROLLO-Device> ASC_LockOut hard</code> gesetzt haben.
Das ist dafür gedacht, wenn Du eine gewisse Zeit den Rolloaktor sperren willst. Zum Beispiel das die Kinder nicht schalten sollen.

== Sonstige Hinweise und Problemlösungen ==
* Werden Attribute geändert, kann es vereinzelt vorkommen, dass das ASC-Modul dies nicht mitbekommt und das tatsächliche Verhalten nicht den Erwartungen entspricht. In so einem Fall empfielt es sich, das NOTIFYDEV nochmals aufbauen zu lassen. Dazu werden zunächst mit <code>set <ASC-Modul> expert 1</code> erweiterte Informationen bezüglich des NotifyDevs unter set und get aktiviert und anschließend ein <code>set <ASC-Modul> createNewNotifyDev</code> ausgeführt.

* Hin und wieder berichten Nutzer davon, wenn Sie die ''Privacy Funktion'' nutzen, dass sich im NOTIFYDEV anstelle des Device Namen ein Raumname befindet. Diese Problem kann damit gelöst werden, dass in dem betroffenen '''Rollo Device''' das Atribut <code>attr event-on-change .*</code> gesetzt wird.
'''Wichtig!''' Nicht verwechseln mit dem ASC Device dort darf <code>attr event-on-change</code> '''nicht''' gesetzt sein!
* Wenn mehrere Rollladen gleichzeitig den Fahrbefehl bekommen, kann es (z. B. bei zwave) dazu kommen, dass ein Rollladen seinen Befehl nicht bekommt. Dies kann durch eine zeitverzögerte Aussendung der Fahrbefehle vermieden werden. Dazu in den jeweiligen Rollo Devices das Attribut ASC_Drive_DelayStart wie folgt benutzen im: ersten Rollo Device braucht das Attribut nicht gesetzt werden, im zweiten Rollo Device im Attribut ASC_Drive_DelayStart dann 4 Sekunden eintragen, im dritten Rollo Device im Attribut ASC_Drive_DelayStart 8 Sekunden eintragen, usw. Ein Abstand von 3-4 Sekunden ist dabei zielführend.

==== Spezielle Hardware ====
{{Link2Forum|Topic=101182|LinkText="Thread zu getesteter Hardware im Forum"}}

== Weblinks ==
* {{Link2Forum|Topic=92628|LinkText="Thread zum Modul im Forum"}}
* {{Link2Forum|Topic=90751|LinkText="Thread zur Entwicklung im Forum"}}
* {{Link2Forum|Topic=73964|LinkText="Thread zu den Scripten von user cluni"}}, die der Entwicklung des Moduls zugrunde liegen
* Daten zum Sonnenstand z.B. hier https://www.sonnenverlauf.de/

<references />

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

Notify

2021-05-09T19:16:19Z

TomLee:

{{SEITENTITEL:notify}}
{{Infobox Modul
|ModPurpose=Ausführung von Anweisung(en) als Reaktion auf Ereignisse
|ModType=h
|ModCmdRef=notify
|ModForumArea=Automatisierung
|ModTechName=91_notify.pm
|ModOwner=rudolfkoenig ({{Link2FU|8|Forum}} / [[Benutzer Diskussion:Rudolfkoenig|Wiki]])
}}

== Einführung ==
{{Hinweis|Weitere grundlegende Informationen/Beispiele zu notify enthält [http://fhem.de/Heimautomatisierung-mit-fhem.pdf Heimautomatisierung mit FHEM]}}
Das Hilfsmodul notify dient dazu [[Ereignis|Ereignisse]] über ein Suchmuster zu erkennen und bei einem Treffer eine Aktion auszulösen. Mit ''notify'' und anderen [[Eventhandler|Eventhandlern]] <ref>hierzu gehören u.a. auch [[DOIF]], [[THRESHOLD]] und [[watchdog]]</ref> ist es möglich, Logikfunktionen im FHEM abzubilden.

'''Beispiele:'''
* Wird das Licht in der Küche eingeschaltet, soll FHEM dort auch das Radio einschalten.
* Bei Druck auf einen Taster soll die Umwälzpumpe für das Warmwasser eingeschaltet werden.
* Erweiterte Möglichkeiten: Aber nur, wenn das Radio aus ist bzw. die Temperatur im Rücklauf des Warmwassers unterhalb einer bestimmten Schwelle liegt<ref>vgl. hierzu z.B. {{Link2CmdRef|Anker=devspec|Label=FILTER}} und [[if-condition]]</ref>.

== Syntax ==

define <name> notify <Suchmuster> <command>

Das ''[[Regulärer Ausdruck|Suchmuster]]'' (häufig als Regexp = regular expression = regulärer Ausdruck bezeichnet) ist sehr wichtig: Es ist entweder der Name des auslösenden ("triggernden") Gerätes oder die Kombination aus Gerät und auslösendem Ereignis (Event) <code>Gerätename:Event</code>. Die Events kann man dem [[Event_monitor|Event-Monitor]] entnehmen. Wenn dort z.B. <code>Rollo1</code> steht, dann reagiert ''notify'' auf <code>Rollo1 on</code> und <code>Rollo1 off</code> usw.

Wenn man mehrere Suchmuster kombinieren möchte, kann man diese in Klammer schreiben, als Trenner wird dann Pipe (|) genutzt: <code>(Rollo1|Rollo2|Steckdose5)</code>.

'''Auch die Verwendung von Platzhaltern ist möglich''':
* <code>Rollo.</code> → das notify reagiert auf alles was mit Rollo und '''einem''' weiteren beliebigen Zeichen anfängt. Also auf Rollo1 wie auch auf RolloG, aber nicht auf Rollo_wischundweg
* <code>Rollo.*</code> → notify reagiert auf alles das mit Rollo beginnt
* <code>.*isch</code> → auf alles das mit isch aufhört (Tisch, Fisch)
* <code>Schalter(1|2|3)</code> → hört auf Schalter1, Schalter2 und Schalter3
* <code>dimmer:pct:.(100|7[6-9]|[89][0-9])</code> → reagiert, wenn pct einen Wert über 75 annimmt.

Suchmuster/Regex kann man im Internet beispielsweise auf [http://regexpal.com/| http://regexpal.com/] testen.

Es gibt seit Juli 2020 eine Perlfunktion notifyRegexpCheck zum Testen, wie FHEM über das Suchmuster "denkt" - siehe {{Link2Forum|Topic=111938|Message=1074202|LinkText=diesen Beitrag}} im Forum.

{{Hinweis|Das '''Suchmuster''' wird notify-intern um das Zeichen ^ (beginnt mit) und das Zeichen $ (endet mit) ergänzt<ref>Der Eventhandler [[DOIF]] verwendet die in Perl übliche Syntax für reguläre Ausdrücke als DOIF-Suchmuster.</ref>.

Deshalb darf das Suchmuster nicht mit einem üblichen [[Regulärer Ausdruck|'''Regulären Ausdruck''']], wie er in Perl<ref>https://perldoc.perl.org/perlre.html</ref> verwendet wird, gleichgesetzt werden, da die Ergänzung zu einem grundsätzlich unterschiedlichen Verhalten führt, siehe nachstehendes Beispiel.}}

'''Beispiel für das unterschiedliche Verhalten von ''Suchmuster'' und ''regulären Ausdruck'''''

Für einen '''regulären Audruck''' gilt: Wenn der reguläre Ausdruck ''lampe'' ist und das [[Ereignis]] ''tischlampe'' dann passen ''tischlampe'' und ''lampe'' zueinander.

Für das '''Suchmuster''' gilt: Wenn das Suchmuster ''lampe'' ist und das [[Ereignis]] ''tischlampe'' dann passen ''tischlampe'' und ''lampe'' '''nicht''' zueinander, weil das Suchmuster zu ^lampe$ ergänzt wird und damit exakt nur auf ''lampe'' matcht (passt).

'''Variablen Zuordnung zum Event'''

'''Beispiel 1'''

2020-01-21 22:40:39 HUEDevice VibrationTest1 battery: 88
{| class="wikitable"
|-
! !!$NAME !! colspan="2" |$EVENT
|-
| ||||$EVTPART0 ||$EVTPART1
|-
|2020-01-21 22:40:39 HUEDevice|| VibrationTest1|| battery:|| 88
|}

'''Beispiel 2'''
2021-05-09 19:11:43 FB_CALLMONITOR cm_example external_name: Graf Herzog von und zu ...
{| class="wikitable"
|-
! !!$NAME !! colspan="7" |$EVENT
|-
| ||||$EVTPART0 ||$EVTPART1 || $EVTPART2|| $EVTPART3 || $EVTPART4|| $EVTPART5|| ...
|-
|2021-05-09 19:11:43 FB_CALLMONITOR|| cm_example|| external_name:|| Graf|| Herzog|| von|| und|| zu|| ...
|}

== FHEMWEB-unterstütztes Anlegen eines notify ==
{{Hinweis|Die Erstellung eines notify und insbesondere die korrekte Angabe des Suchmusters (Regex) führt gerade bei Einsteigern immer wieder zu Schwierigkeiten. Zur Fehlerminimierung empfiehlt es sich zum einen, die [[Konfiguration]] nicht direkt zu bearbeiten, sondern die "Befehl-Eingabezeile", die "Objektdetails" oder den [[Import von Code Snippets|Import von RAW-Definitionen]] zur Bearbeitung zu nutzen.}}

=== Event Monitor ===
Die komfortabelste Möglichkeit, die häufigsten Event-Handler zu erstellen, bietet der [[Event monitor|Event-Monitor]]. Die Vorgehensweis ist in dem zugehörigen Artikel dargestellt.

=== Regexp wizard ===
Zudem enthält FHEM einen Regexp wizard mit dem Regex anhand der in FHEM vorhandenen Devices und deren Events aus einer Auswahlbox selektiert werden können. Voraussetzungen sind:
* Aktivierung des Hilfsmoduls [[eventTypes]] (bei allen Neuinstallationen Standard)
* das gesuchte Ereignis (Event) ist nach Aktivierung des Hilfsmoduls bereits mindestens einmal eingetreten

Schrittweise Darstellung der Nutzung des Regexp wizard zur Anlage eines "notify":

In das [[Konfiguration#Befehl-Eingabefeld|Befehls-Eingabefeld]] eingeben und mit {{Taste|Enter}} bestätigen:
define ntest notify a b
Als Beispiel wird ein notify mit <name> "ntest" angelegt. "a" und "b" sind beliebige Platzhalter für <Suchmuster> und <Command>, die bei der weiteren Bearbeitung mit dem endgültigen Werten ersetzt werden.
Der Regexp wizard öffnet sich:
[[Datei:Regexp wizard1.JPG|400px|thumb|center]]
Nun in der Auswahlbox das auslösende Event (Ereignis) auswählen; zunächst das Device und dann das gewünschte Regex. Hier soll das notify bei jeder Veränderung der Temperatur (temperature.*) des Device BTHR918N reagieren. Abschließend mit einem Mausklick auf {{Taste|set}} bestätigen. Wählt man mehrere Regex in dieser Weise aus, so wird das "notify" bei Eintritt jedes dieser Events ausgeführt:
[[Datei:Regexp wizard2.JPG|400px|thumb|center]]
Anschließend den Platzhalter "a" mit Klick auf den Link "removeRegexpPart" löschen:
[[Datei:Regexp wizard3.JPG|400px|thumb|center]]
Den Link "DEF" anklicken, damit sich der DEF-Editor öffnet:
[[Datei:Regexp wizard4.JPG|400px|thumb|center]]
Jetzt den auszuführenden Befehl im "DEF"-Bereich durch Überschreiben des Platzhalters "b" eintragen und mit Klick auf {{Taste|modify ntest}} abschließen:
[[Datei:Regexp wizard5.JPG|400px|thumb|center]]
Das fertige und sofort aktive "notify" sieht abschließend folgendermaßen aus:
[[Datei:Regexp wizard6.JPG|400px|thumb|center]]
Am Schluss das Speichern über {{Taste|Save config}} nicht vergessen.

== Mein notify geht nicht - wie kann ich mir selbst helfen: Debugging ==
Funktioniert ein notify nicht wie gewünscht, kann es nur zwei Hauptursachen haben:
* Entweder das Suchmuster paßt nicht zum gewünschten Auslöser (FHEM Device), und/oder
* die Anweisung enthält einen Fehler.
Sollte kein Fehler im Logfile auftauchen aber das notify ausgelöst werden, stimmt meist der Übertragungsweg zum Zieldevice nicht.
Der STATE des notify zeigt normalerweise mit Datum/Uhrzeit die letzte Auslösung an.

Beim Debuggen sollte man daher beide Elemente getrennt untersuchen. Hier ein Beispiel welches nicht wie gewünscht funktioniert:
<source lang="perl"> define n_test notify n_test:muster Ausführungsteil</source>
Zum debuggen benötigen wir
* den [[Event monitor]]
* das [https://fhem.de/commandref.html#trigger trigger-Kommando] - kann man jederzeit verwenden um das Suchmuster als Event unabhängig vom Auslöser zu erzeugen.
* die FHEM Kommandozeile
* den [[DEF-Editor]]
* eventuell einen Texteditor um Codeblöcke zwischen zu lagern und Notizen zu machen.

Das Suchmuster im Beispiel notify triggert auf sich selbst, es soll auf jeden Event mit dem Inhalt '''muster''' ausgelöst werden, Beispiel:
2018-07-14 14:31:03 notify n_test muster bild

=== Suchmuster ===
Sollte das notify nicht funktionieren:
* keine Reaktion wie gewünscht
* keine Fehlermeldung in der Weboberfläche beim Anlegen, keine Fehlermeldung im Logfile
* STATE ist unverändert auf active oder einem altem Datum/Uhrzeit
liegt der Fehler mit Sicherheit im Suchmuster. Man hat die Chance das Suchmuster mit dem trigger Befehl zu erzeugen und zu schauen ob die Anweisung ausgeführt wird. Dabei ist zu beachten: Der erste ":" im Suchmuster ist zusätzlich zwischen Gerät und Event als Trennung. Jeder weiter : ist, wenn vorhanden, Bestandteil des Events! Siehe dazu den Abschnitt [https://fhem.de/commandref_DE.html#notify Hinweise in der commandref]
*Im Beispiel: Event: n_test muster -> Suchmuster n_test:muster
Um aus dem [[Event]] ein passendes Suchmuster zu erzeugen kann der [[Event monitor|Event-Monitor]] direkt verwendet werden. Man kann ein neues notify erzeugen oder ein Bestehendes modifizieren lassen.

Unser Regex im Beispiel ist zu spezifisch, es triggert nur exakt auf '''muster'''. Dieser Trigger erzeugt den folgenden Eintrag im Eventmonitor, entspricht exakt dem Suchmuster und löst das notify aus:
trigger n_test muster
2018-07-13 11:52:08 notify n_test muster
Das Suchmuster für unsere Anforderung muss in <code>n_test:muster.*</code> geändert werden, damit jeder Event der mit muster beginnt das notify auslöst.
Der . im Regex steht für jedes beliebige Zeichen und der * für eine beliebige Anzahl des Zeichens davor: also beliebig viele beliebige Zeichen nach muster.

Das Suchmuster wird häufig in ein komplizierteres Regex umgewandelt um im notify mehrere Aktionen zu starten. Das eigene Regex kann z.B. mit http://regexpal.com/ oder https://regex101.com/ getestet werden.

Funktioniert der Auslöser, das notify tut aber noch nicht was es soll, müssen wir die Anweisung untersuchen. In unserem korrigierten Beispiel
<source lang="perl"> defmod n_test notify n_test:muster.* Ausführungsteil</source>
folgt beim Kommando <code>trigger n_test muster bild</code> ein Eintrag im Log:
2018.07.13 11:47:57 3: n_test return value: Unknown command Ausführungsteil, try help.
Das notify wurde zwar getriggert aber die Anweisung war nicht ausführbar.

Ein richtiges Suchmuster und eine fehlerhafte Anweisung wird also normalerweise einen Fehlereintrag im Logfile erzeugen!

=== Spezialfall: notify löst zwar aus - aber zu oft ===
In dem Fall ist das Suchmuster (regExp) zu unscharf oder das triggernde Gerät löst das Event zu oft aus. Das regExp sollte so genau wie möglich konstruiert werden, device:.* ist eine einfache aber oft keine gute Wahl!

Im Device, welches den Event auslöst, kann mit den Attributen event-on-.* die Häufigkeit gesteuert werden. Insbesondere ist hier das regExp .* eine Art Standardwahl um aufeinanderfolgende gleichartige Events zu verhindern.
:<code>attr device event-on-change-reading .*</code>
'''Achtung''': durch falsche Angaben kann man Events ganz leicht völlig verhindern!

Siehe auch [[event-on-change-reading]]

=== Anweisung ===
Wird das notify getriggert oder will man ganz schnell mal ein notify testen, kann man die Anweisung durch folgenden Code ersetzen, man öffnet also einfach nur die DEF, kopiert den ursprünglichen Inhalt an einen sicheren Ort und ersetzt die Anweisung durch eine der beiden Zeilen. Die erste Zeile kann man auch einfach mal in der Kommandozeile testen:
<source lang="perl">{Log 1, "Das Notify n_test hat ausgeloest."}
{Log 1, "Das Device $NAME hat ausgeloest, der Event sah so aus: $EVENT"}</source>
Wird das notify ausgelöst, muss anschließend im Logfile ein Eintrag zu finden sein:
2018.07.13 10:28:57 1: Das Notify n_test hat ausgeloest, der Event sah so aus: muster
Unsere Anweisung <code>Ausführungsteil</code> liefert in der Kommandozeile selbst einen Fehler:
<code>Unknown command Ausführungsteil, try help.</code>
Ein Versuch mit geschweiften Klammern <code>{Ausführungsteil}</code> liefert wieder einen Fehler:
<code>Unrecognized character \xC3; marked by <-- HERE after {Ausf<-- HERE near column 6 at (eval 5977) line 1.</code>
Diese Variante <code>{"Ausführungsteil"}</code> liefert den String Ausführungsteil ohne Fehler: Das notify arbeitet fehler- aber sinnfrei.
Der fertige Code:
defmod n_test notify n_test:muster.* {"Ausführungsteil"}

Man kann die Anweisung, normalerweise so wie sie ist, in der FHEM Kommandozeile testen. Sind im Perl Code (in geschweiften Klammern) im DEF Editor Semikolon enthalten muss man diese für den Test in der Kommandozeile (oder Raw Def) verdoppeln.
Laufzeitabhängige Variablen sind in der Kommandozeile meist nicht verfügbar, diese sollte man für den Test einfach durch passende Inhalte austauschen. So kann man die komfortable Variante (loggt den Namen und das komplette Event) nicht in der Kommandozeile ausführen.

Funktioniert ein FHEM Befehl in der Kommandozeile nicht (z.B. Lampe geht nicht an) kann es im notify auch nicht funktionieren, dann muss die Fehlersuche an anderer Stelle fortgeführt werden.

Komplexeren Code im Ausführungsteil sollte man beim Testen in Teilabschnitte aufteilen, von der Laufzeit abhängige Variable ($NAME, $EVENT, $EVTPART) durch Strings ("TestWort") ersetzen, die Teilabschnitte separat testen und anschließend schrittweise wieder komplettieren.

== Beispiele ==
{{Hinweis|Für die nachfolgenden Beispiele wurden einige unterschiedliche Technologien verwendet. Sie können aber recht einfach auf alle anderen Systeme übertragen werden, dabei sollte ggf. darauf geachtet werden, dass sich Schaltbefehle und Events teilweise je nach konkret eingesetzter Technologie unterscheiden können. Dann ist ggf. eine Erweiterung, z.B. durch eine [[if-condition|if-Abfrage]] erforderlich.}}

=== Schalter entprellen ===
Will man ein notify innerhalb eines bestimmten Zeitraumes nur einmal auslösen lassen, auch wenn er in diesem Zeitraum mehrfach getriggered werden sollte, so bietet sich das Attribut disabledAfterTrigger an,
attr <notify_device> disabledAfterTrigger <Anzahl Sekunden>
In dem Zeitraum wird dann nur einmal (beim ersten Mal) der Befehl ausgelöst, auch wenn mehrfach getriggered wurde. Der Zeitraum kann Bruchteile von Sekunden umfassen.

=== Etwas schalten, wenn ein anderes Gerät geschaltet wird ===

==== Vorbedingungen ====
Dieses Beispiel verwendet eine einfache InterTechno-kompatible Funksteckdose für das Radio und einen HM-Aktor für das Licht:

define RadioKueche IT 000000FFFF 0F F0
define LichtKueche CUL_HM 3A37D6
Beachte: beide kennen als Event bzw. Schaltbefehle ''on'' und ''off''.

==== notify Befehl ====
define LichtamRadioan notify LichtKueche set RadioKueche $EVENT
oder alternativ:
define LichtamRadioan notify LichtKueche { fhem "set RadioKueche $EVENT" }

==== Erklärung ====
* Der Name des ''notify'' "LichtamRadioan" kann frei gewählt werden, er dient nur dazu, das notify in FHEM eindeutig zu identifizieren.
* "$EVENT" ist ein Platzhalter für den Zustand vom Pattern. $EVENT enthält ein "off" wenn das LichtKueche aus- und ein "on" wenn das Licht eingeschaltet wird.
* "{ <perlcode> }" alles was zwischen {} steht ist Perl code. Perl kennt das Schlüsselwort fhem. Das Schlüsselwort FHEM dient dazu, FHEM Befehle auszuführen. Es wird also der FHEM Befehl "set RadioKueche on/off" ausgeführt. on oder off ist abhängig vom Pattern. Der eigentliche FHEM Befehl muss in " " stehen.
* Wann ist ein Wechsel auf die Perl-Ebene erforderlich?
** einfache FHEM-Befehle sollten in der Regel direkt verwendet werden, dies ist ressourcenschonender.
** Immer dann, wenn dies nicht möglich ist, weil z.B. komplexerer Code ausgeführt werden soll, (blockierende) Prozesse ausgelagert werden sollten oder Systembefehle ausgeführt werden, ist es günstiger, auf die Perl-Ebene zu wechseln <ref>In diesem {{Link2Forum|Topic=88398|Message=808685|LinkText=Forenbeitrag}} wird z.B. erläutert, wie man nichtblockierend externe Scripte aufrufen kann, die dann ihre Ergebnisse wieder an FHEM übergeben.</ref>.

=== Einschalten von mehreren Geräten/Lampen, wenn das Licht eingeschaltet wird ===
Dieses Beispiel verwendet einen HM-Aktor für das Licht sowie zwei Milight-Birnen, die einzeln geschaltet werden sollen<ref>Dies ist ausdrücklich keine Empfehlung für diese Technologie und der Module</ref> in den Stehlampen:

==== Vorbedingungen ====
FHEM:
define LichtWZ CUL_HM 3A37D8
define Stehlampe1 MilightDevice RGBW Milight_Wohnzimmer 5
define Stehlampe2 MilightDevice RGBW Milight_Wohnzimmer 6

==== notify Befehl ====
define SteckdoseWZein notify LichtWZ set Stehlampe1,Stehlampe2 $EVENT
oder ''in Perl''
define SteckdoseWZein notify LichtWZ { fhem "set Stehlampe1 $EVENT;;set Stehlampe2 $EVENT " }
==== Erklärung ====
Wenn das LichtWZ eingeschaltet wird, dann werden auch die Stehlampen (1 und 2) eingeschaltet.

=== Einfache ODER Funktion ===
Eine einfache ODER Funktion kann sehr einfach realisiert werden

==== Vorbereitung ====
KNX:
* 3x GAs der abzufragende Werte (0/0/40 0/0/41 0/0/42)

FHEM:
define Licht1 CUL_HM 3A37D8
define Licht2 CUL_HM 1B7EC3
define Stehlampe MilightDevice RGBW Milight_Wohnzimmer 7

==== notify Befehl ====
define SteckdoseWZein notify (Licht1|Licht2) set Stehlampe $EVENT
oder
define SteckdoseWZein notify (Licht.) set Stehlampe $EVENT

==== Erklärung ====
Die Werte in der Klammer (wichtig ist das »|«) sind die Rückgabewerte. Alternativ kann in diesem Beispiel auch »Licht.« (zu beachten ist der Punkt) geschrieben werden. Der Punkt ist ein Platzhalter für (genau) ein beliebiges Zeichen.

Danach folgt der set Befehl.
Wenn also das Licht1 oder Licht2 den Wert "on" hat, dann hat auch die Steckdose den Wert "on"

Alternative: [[structure]]

=== Einfache UND Funktion ===
Ob man dieses Konstrukt noch als einfach bezeichnen kann, wage ich mal zu bezweifeln. In FHEM fehlen Loggingfunktionen, die man alle selber mit Perl Code erstellen kann (Danke an MAZ).
Dadurch ist FHEM zwar mächtig, wird aber für viele sehr kompliziert.

In diesem Beispiel soll - wenn drei Rollos geschlossen sind - am Taster eine LED eingeschaltet werden.

==== Vorbereitung ====
KNX:
* 3x GDs für die Rückgabewert Rollo geschlossen == 1 (0/0/50 0/0/51 0/0/52)
* GD LED am Lichtschalter (0/0/106)

FHEM:
define R1ZU KNX 0/0/50:dpt1.009
attr R1ZU dummy 1
define R2ZU KNX 0/0/51:dpt1.009
attr R2ZU dummy 1
define R3ZU KNX 0/0/52:dpt1.009
attr R3ZU dummy 1
define LEDalleRolloZu KNX 0/0/106:dpt1
Durch das Attribut dummy werden keine Schaltfunktion angeboten. Es kann nur Werte anzeigen.

==== notify Befehl ====
define nt.allerolloszu notify (R1ZU|R2ZU|R3ZU) {
my $r1 = Value("R1ZU");;
my $r2 = Value("R2ZU");;
my $r3 = Value("R3ZU");;
if ($r1 eq "on" && $r2 eq "on" && $r3 eq "on") {
fhem("set LEDalleRolloZu on");;
} else {
fhem("set LEDalleRolloZu off");;
}
}

==== Erklärung ====
Es werden die drei Rückgabewerte R1ZU, R2ZU und R3ZU ausgewertet. Danach folgt Perl Code, deswegen beginnt das ganze mit einer { und endet mit }

my $r1 => Variable $r1 definieren
= Value("R1ZU");; ==> weist den Rückgabewert (on oder off) von R1ZU der Variable $r1 zu

Der doppelte ;; ist ein FHEM Thema. Eigentlich würde für Perl ein ; reichen. Aber FHEM nutzt selbst das ; und daher wird ein ;; benötigt. Mit den ersten drei my Zeilen werden die Rückgabewerte den Variablen zugewiesen.

Danach erfolgt ein normales "if then else" Konstrukt. Die Zeile »($r1 eq "on" && $r2 eq "on" && $r3 eq "on")« kann man so lesen: Wenn $r1 den Wert "on" und (&&) $r2 den Wert "on" und $r3 den Wert "on" dann schalte die LEDalleRolloZu ein {fhem("set LEDalleRolloZu on")}
ansonsten else schalte die LED aus. {fhem("set LEDalleRolloZu off")

Alternative: [[structure]]

=== Zeitverzögert schalten ===
{| class="wikitable"
| '''Aufgabe:''' || Zeitverzögert schalten
|-
| '''Beschreibung:''' || Mit einem Notify zeitverzögert eine Aktion auslösen.
|-
| '''Vorbereitung:''' || Gerät "Lampe" ist definiert und es gibt eine Situation, die ein Ereignis "Fernbedienung:.*" generiert.
|-
| '''Befehl:''' || <code>define ntfy1 notify Fernbedienung:.* sleep 7.5;; set Lampe $EVENT</code>
|-
| '''Erläuterungen:''' || Bei Eintreten eines Ereignisses "Fernbedienung*" wird nach einer Pause von siebeneinhalb Sekunden der Befehl <set Lampe ??> ausgeführt, wobei der eigentliche Befehl aus dem auslösenden Ereignis übernommen wird.
:''Quelle: {{Link2Forum|Topic=17161|LinkText=FHEM Forum}}''
|}

=== Eine PV-Anlage (Solarstrom) zur Steuerung der Rollos nutzen (optional Zeit und Datums abhängig) ===
Hier ein kleines Beispiel, wie man mit Hilfe einer PV-Anlage die Sonneneinstrahlung auf der Südseite ermittelt und dies zur Rolladensteuerung nutzt.
Optional: Die Funktion soll allerdings nur zwischen 9:30 und 17:00 stattfinden. (zweites Beispiel)
Optional: Die Funktion soll nur zwischen dem 6. und 9. Monat funktioneren. (drittes Beispiel)

==== Vorbereitung ====
PV Anlage mit SolarView abfragen.
Per Hand ermitteln, ab wieviel erzeugtem Strom es sinnvoll ist die Rollos zu schließen.

==== notify Syntax ====
FHEM:

define sv SolarView solarview 15000 wr1 wr2 wr3 wr4 <----vier Wechselrichter
attr sv event-on-change-reading currentPower

define nt.sonnenlichtpersolar notify (sv:currentPower.*) {
if ($EVTPART1 < 3000 ) {
fhem('set Flur1 Auf');
}else {
if ($EVTPART1 > 5000 ) {
fhem('set Flur1 Ab');
}
}
}

Optional 1: Zeitabhängig
<syntaxhighlight lang="Perl">
(sv:currentPower.*) {
my $hm = sprintf("%02d:%02d", $hour, $min);
if ( $hm gt "09:30" && $hm lt "17:00") {
if ($EVTPART1 < 5000 ) {
fhem('set Flur1 Auf');
}else {
if ($EVTPART1 > 8000 ) {
fhem('set Flur1 Ab');
}
}
}
}
</syntaxhighlight>
Optional 2: Zeit und Datum
<syntaxhighlight lang="Perl">
(sv:currentPower.*) {
my $hm = sprintf("%02d:%02d", $hour, $min);
if ($month >= 6 && $month <= 9) {
if ( $hm gt "09:30" && $hm lt "17:00") {
if ($EVTPART1 < 5000 ) {
fhem('set Flur1,RBUERO1,RBUERO2 Auf');
}else {
if ($EVTPART1 > 8000 ) {
fhem('set Flur1,Flur2,RBUERO1,RBUERO2 Ab');
}
}
}
}
}
</syntaxhighlight>

==== Erklärung ====
* Das define wird in der Kommandozeile im Webbrowser eingegeben.
* Anschließend wird im Webbrowser die DEF bearbeitet, das erspart uns Probleme mit Perl
* define sv SolarView ... <==== ist die Schnittstelle vom SolarView
* define nt.sonnenlichtpersolar notify (sv:currentPower.*) { <==== hier wird ein notify angelegt, der auf das "define sv" Wert "currentPower.*" (.* ist irgendwas) reagiert
if ($EVTPART1 < 3000 ) {
fhem('set Flur1 Auf');
}else {
if ($EVTPART1 > 5000 ) {
fhem('set Flur1 Ab');
}
}
}
Diese if-Funktion wertet den Rückgabewert von currentPower aus. Hierbei muss man wissen, dass $EVTPART1 das Split-Ergebnis vom Rückgabewert ist

Beispiel: Der Rückgabewert (wie im Beispiel) ist "currentPower: 6000".
Jetzt steht im "$EVTPART0 == currentPower:" und im "$EVTPART1 == 6000"
Das bedeutet, dass man sich nicht selbst den richtigen split (Perl Befehl) Aufruf ausdenken muss, dies übernimmt vielmehr FHEM.

Ergebnis:
Das Rollo wird abhängig von der erzeugten IST_Strommenge auf und zu gefahren.
Damit dies nicht dauernd hin und her pendelt, wurde der Auf Wert sehr klein und den Ab Wert sehr groß gewählt.

'''Optional 1:''' Der Block "my $hm = sprintf("%02d:%02d", $hour, $min);" erzeugt die String-Variable $hm mit dem Inhalt $hour:$min. %02d begrenzt die Ausgabe auf zwei Stellen.
Danach wird mit "if ( $hm gt "09:30" && $hm lt "17:00")" mit stringvergleichenden Operatoren geprüft, ob die Uhrzeit zwischen 9:30 und 17:00 liegt (lt = kleiner als; gt = größer als). Es wäre auch ein le und ge möglich: le = kleiner/gleich als, ge = größer/gleich als.

'''Optional 2:'''if( $month >= 6 && $month <= 9) {

Hier wird die numerische FHEM-Standard-Variable $month (Monat) auf größer/gleich bzw kleiner/gleich mit den binären Operatoren überprüft.
Die Funktion arbeitet also nur zwischen dem 6. und dem 9. Monat und dann auch nur zwischen 9:31 und 16:59.

=== Status eines Kippfensters mit 2 Fensterkontakten abbilden ===

==== Vorbereitung ====
Es ist je ein Fensterkontakt der ''open'' oder ''closed'' meldet, oben und unten am Fenster angebracht.
Die Namen der beiden FHEM-Devices sind ''fensterKontaktOben'' und ''fensterKontaktUnten''.

==== notify Syntax ====
FHEM:
define statusFenster notify fensterKontakt(Oben|Unten):(open|closed) {
if ( ReadingsVal('fensterKontaktOben', 'state', 'undef') eq 'open' && ReadingsVal('fensterKontaktUnten', 'state', 'undef') eq 'open')
{ fhem 'set Terrassentuer open' }
if ( ReadingsVal('fensterKontaktOben', 'state', 'undef') eq 'closed' && ReadingsVal('fensterKontaktUnten', 'state', 'undef') eq 'closed')
{ fhem 'set Terrassentuer closed' }
if ( ReadingsVal('fensterKontaktOben', 'state', 'undef') eq 'open' && ReadingsVal('fensterKontaktUnten', 'state', 'undef') eq 'closed')
{ fhem 'set Terrassentuer tilted' }
if ( ReadingsVal('fensterKontaktOben', 'state', 'undef') eq 'closed' && ReadingsVal('fensterKontaktUnten', 'state', 'undef') eq 'open')
{ fhem 'set Terrassentuer undef' }
}

== Weitere Hinweise ==
* Entsprechend zu $EVENT gibt es auch noch $NAME und $TYPE. $NAME und $TYPE enthalten den Namen bzw. Typ des Ereignis auslösenden Gerätes.
* Wird der Perl-Code in einem <code>notify</code> immer länger, lagere den Code wegen der Übersichtlichkeit in eine eigene Programmdatei aus, wie in [[99_myUtils anlegen]] beschrieben.
* Achtung! Wenn man das Skript für den notify-Befehl über mehrere Zeilen schreibt, muss man anscheinend darauf achten, dass keine abschließende Leerzeile mitgespeichert wird. Sonst wird der notify-Befehl ignoriert.
* Dieser {{Link2Forum|Topic=38520|Message=307325}} enthält Vorschläge zur Vorgehensweise bei der Erstellung von komplexen ''notify'' Definitionen bzw. bei deren Fehlerbehebung.

== Weiterführende Links ==
* [[Escapen in Perlbefehlen]]
* [[Klammerebenen]]
* Forenbeitrag zum Thema {{Link2Forum|Topic=115414|LinkText=Optimierung des Suchmusters - NOTIFYDEV}}

== Hinweise ==
<references />

[[Kategorie:HOWTOS]]
[[Kategorie:Hilfsmodul]]

Notify

2021-05-09T18:16:22Z

TomLee:

{{SEITENTITEL:notify}}
{{Infobox Modul
|ModPurpose=Ausführung von Anweisung(en) als Reaktion auf Ereignisse
|ModType=h
|ModCmdRef=notify
|ModForumArea=Automatisierung
|ModTechName=91_notify.pm
|ModOwner=rudolfkoenig ({{Link2FU|8|Forum}} / [[Benutzer Diskussion:Rudolfkoenig|Wiki]])
}}

== Einführung ==
{{Hinweis|Weitere grundlegende Informationen/Beispiele zu notify enthält [http://fhem.de/Heimautomatisierung-mit-fhem.pdf Heimautomatisierung mit FHEM]}}
Das Hilfsmodul notify dient dazu [[Ereignis|Ereignisse]] über ein Suchmuster zu erkennen und bei einem Treffer eine Aktion auszulösen. Mit ''notify'' und anderen [[Eventhandler|Eventhandlern]] <ref>hierzu gehören u.a. auch [[DOIF]], [[THRESHOLD]] und [[watchdog]]</ref> ist es möglich, Logikfunktionen im FHEM abzubilden.

'''Beispiele:'''
* Wird das Licht in der Küche eingeschaltet, soll FHEM dort auch das Radio einschalten.
* Bei Druck auf einen Taster soll die Umwälzpumpe für das Warmwasser eingeschaltet werden.
* Erweiterte Möglichkeiten: Aber nur, wenn das Radio aus ist bzw. die Temperatur im Rücklauf des Warmwassers unterhalb einer bestimmten Schwelle liegt<ref>vgl. hierzu z.B. {{Link2CmdRef|Anker=devspec|Label=FILTER}} und [[if-condition]]</ref>.

== Syntax ==

define <name> notify <Suchmuster> <command>

Das ''[[Regulärer Ausdruck|Suchmuster]]'' (häufig als Regexp = regular expression = regulärer Ausdruck bezeichnet) ist sehr wichtig: Es ist entweder der Name des auslösenden ("triggernden") Gerätes oder die Kombination aus Gerät und auslösendem Ereignis (Event) <code>Gerätename:Event</code>. Die Events kann man dem [[Event_monitor|Event-Monitor]] entnehmen. Wenn dort z.B. <code>Rollo1</code> steht, dann reagiert ''notify'' auf <code>Rollo1 on</code> und <code>Rollo1 off</code> usw.

Wenn man mehrere Suchmuster kombinieren möchte, kann man diese in Klammer schreiben, als Trenner wird dann Pipe (|) genutzt: <code>(Rollo1|Rollo2|Steckdose5)</code>.

'''Auch die Verwendung von Platzhaltern ist möglich''':
* <code>Rollo.</code> → das notify reagiert auf alles was mit Rollo und '''einem''' weiteren beliebigen Zeichen anfängt. Also auf Rollo1 wie auch auf RolloG, aber nicht auf Rollo_wischundweg
* <code>Rollo.*</code> → notify reagiert auf alles das mit Rollo beginnt
* <code>.*isch</code> → auf alles das mit isch aufhört (Tisch, Fisch)
* <code>Schalter(1|2|3)</code> → hört auf Schalter1, Schalter2 und Schalter3
* <code>dimmer:pct:.(100|7[6-9]|[89][0-9])</code> → reagiert, wenn pct einen Wert über 75 annimmt.

Suchmuster/Regex kann man im Internet beispielsweise auf [http://regexpal.com/| http://regexpal.com/] testen.

Es gibt seit Juli 2020 eine Perlfunktion notifyRegexpCheck zum Testen, wie FHEM über das Suchmuster "denkt" - siehe {{Link2Forum|Topic=111938|Message=1074202|LinkText=diesen Beitrag}} im Forum.

{{Hinweis|Das '''Suchmuster''' wird notify-intern um das Zeichen ^ (beginnt mit) und das Zeichen $ (endet mit) ergänzt<ref>Der Eventhandler [[DOIF]] verwendet die in Perl übliche Syntax für reguläre Ausdrücke als DOIF-Suchmuster.</ref>.

Deshalb darf das Suchmuster nicht mit einem üblichen [[Regulärer Ausdruck|'''Regulären Ausdruck''']], wie er in Perl<ref>https://perldoc.perl.org/perlre.html</ref> verwendet wird, gleichgesetzt werden, da die Ergänzung zu einem grundsätzlich unterschiedlichen Verhalten führt, siehe nachstehendes Beispiel.}}

'''Beispiel für das unterschiedliche Verhalten von ''Suchmuster'' und ''regulären Ausdruck'''''

Für einen '''regulären Audruck''' gilt: Wenn der reguläre Ausdruck ''lampe'' ist und das [[Ereignis]] ''tischlampe'' dann passen ''tischlampe'' und ''lampe'' zueinander.

Für das '''Suchmuster''' gilt: Wenn das Suchmuster ''lampe'' ist und das [[Ereignis]] ''tischlampe'' dann passen ''tischlampe'' und ''lampe'' '''nicht''' zueinander, weil das Suchmuster zu ^lampe$ ergänzt wird und damit exakt nur auf ''lampe'' matcht (passt).

'''Variablen Zuordnung zum Event'''

'''Beispiel 1'''

2020-01-21 22:40:39 HUEDevice VibrationTest1 battery: 88
{| class="wikitable"
|-
! !!$NAME !! colspan="2" |$EVENT
|-
| ||||$EVTPART0 ||$EVTPART1
|-
|2020-01-21 22:40:39 HUEDevice|| VibrationTest1|| battery:|| 88
|}

'''Beispiel 2'''
2021-05-09 19:11:43 FB_CALLMONITOR cm_example external_name: Graf Herzog von und zu
{| class="wikitable"
|-
! !!$NAME !! colspan="6" |$EVENT
|-
| ||||$EVTPART0 ||$EVTPART1 || $EVTPART2|| $EVTPART3 || $EVTPART4|| $EVTPART5
|-
|2021-05-09 19:11:43 FB_CALLMONITOR|| cm_example|| external_name:|| Graf|| Herzog|| von|| und|| zu
|}

== FHEMWEB-unterstütztes Anlegen eines notify ==
{{Hinweis|Die Erstellung eines notify und insbesondere die korrekte Angabe des Suchmusters (Regex) führt gerade bei Einsteigern immer wieder zu Schwierigkeiten. Zur Fehlerminimierung empfiehlt es sich zum einen, die [[Konfiguration]] nicht direkt zu bearbeiten, sondern die "Befehl-Eingabezeile", die "Objektdetails" oder den [[Import von Code Snippets|Import von RAW-Definitionen]] zur Bearbeitung zu nutzen.}}

=== Event Monitor ===
Die komfortabelste Möglichkeit, die häufigsten Event-Handler zu erstellen, bietet der [[Event monitor|Event-Monitor]]. Die Vorgehensweis ist in dem zugehörigen Artikel dargestellt.

=== Regexp wizard ===
Zudem enthält FHEM einen Regexp wizard mit dem Regex anhand der in FHEM vorhandenen Devices und deren Events aus einer Auswahlbox selektiert werden können. Voraussetzungen sind:
* Aktivierung des Hilfsmoduls [[eventTypes]] (bei allen Neuinstallationen Standard)
* das gesuchte Ereignis (Event) ist nach Aktivierung des Hilfsmoduls bereits mindestens einmal eingetreten

Schrittweise Darstellung der Nutzung des Regexp wizard zur Anlage eines "notify":

In das [[Konfiguration#Befehl-Eingabefeld|Befehls-Eingabefeld]] eingeben und mit {{Taste|Enter}} bestätigen:
define ntest notify a b
Als Beispiel wird ein notify mit <name> "ntest" angelegt. "a" und "b" sind beliebige Platzhalter für <Suchmuster> und <Command>, die bei der weiteren Bearbeitung mit dem endgültigen Werten ersetzt werden.
Der Regexp wizard öffnet sich:
[[Datei:Regexp wizard1.JPG|400px|thumb|center]]
Nun in der Auswahlbox das auslösende Event (Ereignis) auswählen; zunächst das Device und dann das gewünschte Regex. Hier soll das notify bei jeder Veränderung der Temperatur (temperature.*) des Device BTHR918N reagieren. Abschließend mit einem Mausklick auf {{Taste|set}} bestätigen. Wählt man mehrere Regex in dieser Weise aus, so wird das "notify" bei Eintritt jedes dieser Events ausgeführt:
[[Datei:Regexp wizard2.JPG|400px|thumb|center]]
Anschließend den Platzhalter "a" mit Klick auf den Link "removeRegexpPart" löschen:
[[Datei:Regexp wizard3.JPG|400px|thumb|center]]
Den Link "DEF" anklicken, damit sich der DEF-Editor öffnet:
[[Datei:Regexp wizard4.JPG|400px|thumb|center]]
Jetzt den auszuführenden Befehl im "DEF"-Bereich durch Überschreiben des Platzhalters "b" eintragen und mit Klick auf {{Taste|modify ntest}} abschließen:
[[Datei:Regexp wizard5.JPG|400px|thumb|center]]
Das fertige und sofort aktive "notify" sieht abschließend folgendermaßen aus:
[[Datei:Regexp wizard6.JPG|400px|thumb|center]]
Am Schluss das Speichern über {{Taste|Save config}} nicht vergessen.

== Mein notify geht nicht - wie kann ich mir selbst helfen: Debugging ==
Funktioniert ein notify nicht wie gewünscht, kann es nur zwei Hauptursachen haben:
* Entweder das Suchmuster paßt nicht zum gewünschten Auslöser (FHEM Device), und/oder
* die Anweisung enthält einen Fehler.
Sollte kein Fehler im Logfile auftauchen aber das notify ausgelöst werden, stimmt meist der Übertragungsweg zum Zieldevice nicht.
Der STATE des notify zeigt normalerweise mit Datum/Uhrzeit die letzte Auslösung an.

Beim Debuggen sollte man daher beide Elemente getrennt untersuchen. Hier ein Beispiel welches nicht wie gewünscht funktioniert:
<source lang="perl"> define n_test notify n_test:muster Ausführungsteil</source>
Zum debuggen benötigen wir
* den [[Event monitor]]
* das [https://fhem.de/commandref.html#trigger trigger-Kommando] - kann man jederzeit verwenden um das Suchmuster als Event unabhängig vom Auslöser zu erzeugen.
* die FHEM Kommandozeile
* den [[DEF-Editor]]
* eventuell einen Texteditor um Codeblöcke zwischen zu lagern und Notizen zu machen.

Das Suchmuster im Beispiel notify triggert auf sich selbst, es soll auf jeden Event mit dem Inhalt '''muster''' ausgelöst werden, Beispiel:
2018-07-14 14:31:03 notify n_test muster bild

=== Suchmuster ===
Sollte das notify nicht funktionieren:
* keine Reaktion wie gewünscht
* keine Fehlermeldung in der Weboberfläche beim Anlegen, keine Fehlermeldung im Logfile
* STATE ist unverändert auf active oder einem altem Datum/Uhrzeit
liegt der Fehler mit Sicherheit im Suchmuster. Man hat die Chance das Suchmuster mit dem trigger Befehl zu erzeugen und zu schauen ob die Anweisung ausgeführt wird. Dabei ist zu beachten: Der erste ":" im Suchmuster ist zusätzlich zwischen Gerät und Event als Trennung. Jeder weiter : ist, wenn vorhanden, Bestandteil des Events! Siehe dazu den Abschnitt [https://fhem.de/commandref_DE.html#notify Hinweise in der commandref]
*Im Beispiel: Event: n_test muster -> Suchmuster n_test:muster
Um aus dem [[Event]] ein passendes Suchmuster zu erzeugen kann der [[Event monitor|Event-Monitor]] direkt verwendet werden. Man kann ein neues notify erzeugen oder ein Bestehendes modifizieren lassen.

Unser Regex im Beispiel ist zu spezifisch, es triggert nur exakt auf '''muster'''. Dieser Trigger erzeugt den folgenden Eintrag im Eventmonitor, entspricht exakt dem Suchmuster und löst das notify aus:
trigger n_test muster
2018-07-13 11:52:08 notify n_test muster
Das Suchmuster für unsere Anforderung muss in <code>n_test:muster.*</code> geändert werden, damit jeder Event der mit muster beginnt das notify auslöst.
Der . im Regex steht für jedes beliebige Zeichen und der * für eine beliebige Anzahl des Zeichens davor: also beliebig viele beliebige Zeichen nach muster.

Das Suchmuster wird häufig in ein komplizierteres Regex umgewandelt um im notify mehrere Aktionen zu starten. Das eigene Regex kann z.B. mit http://regexpal.com/ oder https://regex101.com/ getestet werden.

Funktioniert der Auslöser, das notify tut aber noch nicht was es soll, müssen wir die Anweisung untersuchen. In unserem korrigierten Beispiel
<source lang="perl"> defmod n_test notify n_test:muster.* Ausführungsteil</source>
folgt beim Kommando <code>trigger n_test muster bild</code> ein Eintrag im Log:
2018.07.13 11:47:57 3: n_test return value: Unknown command Ausführungsteil, try help.
Das notify wurde zwar getriggert aber die Anweisung war nicht ausführbar.

Ein richtiges Suchmuster und eine fehlerhafte Anweisung wird also normalerweise einen Fehlereintrag im Logfile erzeugen!

=== Spezialfall: notify löst zwar aus - aber zu oft ===
In dem Fall ist das Suchmuster (regExp) zu unscharf oder das triggernde Gerät löst das Event zu oft aus. Das regExp sollte so genau wie möglich konstruiert werden, device:.* ist eine einfache aber oft keine gute Wahl!

Im Device, welches den Event auslöst, kann mit den Attributen event-on-.* die Häufigkeit gesteuert werden. Insbesondere ist hier das regExp .* eine Art Standardwahl um aufeinanderfolgende gleichartige Events zu verhindern.
:<code>attr device event-on-change-reading .*</code>
'''Achtung''': durch falsche Angaben kann man Events ganz leicht völlig verhindern!

Siehe auch [[event-on-change-reading]]

=== Anweisung ===
Wird das notify getriggert oder will man ganz schnell mal ein notify testen, kann man die Anweisung durch folgenden Code ersetzen, man öffnet also einfach nur die DEF, kopiert den ursprünglichen Inhalt an einen sicheren Ort und ersetzt die Anweisung durch eine der beiden Zeilen. Die erste Zeile kann man auch einfach mal in der Kommandozeile testen:
<source lang="perl">{Log 1, "Das Notify n_test hat ausgeloest."}
{Log 1, "Das Device $NAME hat ausgeloest, der Event sah so aus: $EVENT"}</source>
Wird das notify ausgelöst, muss anschließend im Logfile ein Eintrag zu finden sein:
2018.07.13 10:28:57 1: Das Notify n_test hat ausgeloest, der Event sah so aus: muster
Unsere Anweisung <code>Ausführungsteil</code> liefert in der Kommandozeile selbst einen Fehler:
<code>Unknown command Ausführungsteil, try help.</code>
Ein Versuch mit geschweiften Klammern <code>{Ausführungsteil}</code> liefert wieder einen Fehler:
<code>Unrecognized character \xC3; marked by <-- HERE after {Ausf<-- HERE near column 6 at (eval 5977) line 1.</code>
Diese Variante <code>{"Ausführungsteil"}</code> liefert den String Ausführungsteil ohne Fehler: Das notify arbeitet fehler- aber sinnfrei.
Der fertige Code:
defmod n_test notify n_test:muster.* {"Ausführungsteil"}

Man kann die Anweisung, normalerweise so wie sie ist, in der FHEM Kommandozeile testen. Sind im Perl Code (in geschweiften Klammern) im DEF Editor Semikolon enthalten muss man diese für den Test in der Kommandozeile (oder Raw Def) verdoppeln.
Laufzeitabhängige Variablen sind in der Kommandozeile meist nicht verfügbar, diese sollte man für den Test einfach durch passende Inhalte austauschen. So kann man die komfortable Variante (loggt den Namen und das komplette Event) nicht in der Kommandozeile ausführen.

Funktioniert ein FHEM Befehl in der Kommandozeile nicht (z.B. Lampe geht nicht an) kann es im notify auch nicht funktionieren, dann muss die Fehlersuche an anderer Stelle fortgeführt werden.

Komplexeren Code im Ausführungsteil sollte man beim Testen in Teilabschnitte aufteilen, von der Laufzeit abhängige Variable ($NAME, $EVENT, $EVTPART) durch Strings ("TestWort") ersetzen, die Teilabschnitte separat testen und anschließend schrittweise wieder komplettieren.

== Beispiele ==
{{Hinweis|Für die nachfolgenden Beispiele wurden einige unterschiedliche Technologien verwendet. Sie können aber recht einfach auf alle anderen Systeme übertragen werden, dabei sollte ggf. darauf geachtet werden, dass sich Schaltbefehle und Events teilweise je nach konkret eingesetzter Technologie unterscheiden können. Dann ist ggf. eine Erweiterung, z.B. durch eine [[if-condition|if-Abfrage]] erforderlich.}}

=== Schalter entprellen ===
Will man ein notify innerhalb eines bestimmten Zeitraumes nur einmal auslösen lassen, auch wenn er in diesem Zeitraum mehrfach getriggered werden sollte, so bietet sich das Attribut disabledAfterTrigger an,
attr <notify_device> disabledAfterTrigger <Anzahl Sekunden>
In dem Zeitraum wird dann nur einmal (beim ersten Mal) der Befehl ausgelöst, auch wenn mehrfach getriggered wurde. Der Zeitraum kann Bruchteile von Sekunden umfassen.

=== Etwas schalten, wenn ein anderes Gerät geschaltet wird ===

==== Vorbedingungen ====
Dieses Beispiel verwendet eine einfache InterTechno-kompatible Funksteckdose für das Radio und einen HM-Aktor für das Licht:

define RadioKueche IT 000000FFFF 0F F0
define LichtKueche CUL_HM 3A37D6
Beachte: beide kennen als Event bzw. Schaltbefehle ''on'' und ''off''.

==== notify Befehl ====
define LichtamRadioan notify LichtKueche set RadioKueche $EVENT
oder alternativ:
define LichtamRadioan notify LichtKueche { fhem "set RadioKueche $EVENT" }

==== Erklärung ====
* Der Name des ''notify'' "LichtamRadioan" kann frei gewählt werden, er dient nur dazu, das notify in FHEM eindeutig zu identifizieren.
* "$EVENT" ist ein Platzhalter für den Zustand vom Pattern. $EVENT enthält ein "off" wenn das LichtKueche aus- und ein "on" wenn das Licht eingeschaltet wird.
* "{ <perlcode> }" alles was zwischen {} steht ist Perl code. Perl kennt das Schlüsselwort fhem. Das Schlüsselwort FHEM dient dazu, FHEM Befehle auszuführen. Es wird also der FHEM Befehl "set RadioKueche on/off" ausgeführt. on oder off ist abhängig vom Pattern. Der eigentliche FHEM Befehl muss in " " stehen.
* Wann ist ein Wechsel auf die Perl-Ebene erforderlich?
** einfache FHEM-Befehle sollten in der Regel direkt verwendet werden, dies ist ressourcenschonender.
** Immer dann, wenn dies nicht möglich ist, weil z.B. komplexerer Code ausgeführt werden soll, (blockierende) Prozesse ausgelagert werden sollten oder Systembefehle ausgeführt werden, ist es günstiger, auf die Perl-Ebene zu wechseln <ref>In diesem {{Link2Forum|Topic=88398|Message=808685|LinkText=Forenbeitrag}} wird z.B. erläutert, wie man nichtblockierend externe Scripte aufrufen kann, die dann ihre Ergebnisse wieder an FHEM übergeben.</ref>.

=== Einschalten von mehreren Geräten/Lampen, wenn das Licht eingeschaltet wird ===
Dieses Beispiel verwendet einen HM-Aktor für das Licht sowie zwei Milight-Birnen, die einzeln geschaltet werden sollen<ref>Dies ist ausdrücklich keine Empfehlung für diese Technologie und der Module</ref> in den Stehlampen:

==== Vorbedingungen ====
FHEM:
define LichtWZ CUL_HM 3A37D8
define Stehlampe1 MilightDevice RGBW Milight_Wohnzimmer 5
define Stehlampe2 MilightDevice RGBW Milight_Wohnzimmer 6

==== notify Befehl ====
define SteckdoseWZein notify LichtWZ set Stehlampe1,Stehlampe2 $EVENT
oder ''in Perl''
define SteckdoseWZein notify LichtWZ { fhem "set Stehlampe1 $EVENT;;set Stehlampe2 $EVENT " }
==== Erklärung ====
Wenn das LichtWZ eingeschaltet wird, dann werden auch die Stehlampen (1 und 2) eingeschaltet.

=== Einfache ODER Funktion ===
Eine einfache ODER Funktion kann sehr einfach realisiert werden

==== Vorbereitung ====
KNX:
* 3x GAs der abzufragende Werte (0/0/40 0/0/41 0/0/42)

FHEM:
define Licht1 CUL_HM 3A37D8
define Licht2 CUL_HM 1B7EC3
define Stehlampe MilightDevice RGBW Milight_Wohnzimmer 7

==== notify Befehl ====
define SteckdoseWZein notify (Licht1|Licht2) set Stehlampe $EVENT
oder
define SteckdoseWZein notify (Licht.) set Stehlampe $EVENT

==== Erklärung ====
Die Werte in der Klammer (wichtig ist das »|«) sind die Rückgabewerte. Alternativ kann in diesem Beispiel auch »Licht.« (zu beachten ist der Punkt) geschrieben werden. Der Punkt ist ein Platzhalter für (genau) ein beliebiges Zeichen.

Danach folgt der set Befehl.
Wenn also das Licht1 oder Licht2 den Wert "on" hat, dann hat auch die Steckdose den Wert "on"

Alternative: [[structure]]

=== Einfache UND Funktion ===
Ob man dieses Konstrukt noch als einfach bezeichnen kann, wage ich mal zu bezweifeln. In FHEM fehlen Loggingfunktionen, die man alle selber mit Perl Code erstellen kann (Danke an MAZ).
Dadurch ist FHEM zwar mächtig, wird aber für viele sehr kompliziert.

In diesem Beispiel soll - wenn drei Rollos geschlossen sind - am Taster eine LED eingeschaltet werden.

==== Vorbereitung ====
KNX:
* 3x GDs für die Rückgabewert Rollo geschlossen == 1 (0/0/50 0/0/51 0/0/52)
* GD LED am Lichtschalter (0/0/106)

FHEM:
define R1ZU KNX 0/0/50:dpt1.009
attr R1ZU dummy 1
define R2ZU KNX 0/0/51:dpt1.009
attr R2ZU dummy 1
define R3ZU KNX 0/0/52:dpt1.009
attr R3ZU dummy 1
define LEDalleRolloZu KNX 0/0/106:dpt1
Durch das Attribut dummy werden keine Schaltfunktion angeboten. Es kann nur Werte anzeigen.

==== notify Befehl ====
define nt.allerolloszu notify (R1ZU|R2ZU|R3ZU) {
my $r1 = Value("R1ZU");;
my $r2 = Value("R2ZU");;
my $r3 = Value("R3ZU");;
if ($r1 eq "on" && $r2 eq "on" && $r3 eq "on") {
fhem("set LEDalleRolloZu on");;
} else {
fhem("set LEDalleRolloZu off");;
}
}

==== Erklärung ====
Es werden die drei Rückgabewerte R1ZU, R2ZU und R3ZU ausgewertet. Danach folgt Perl Code, deswegen beginnt das ganze mit einer { und endet mit }

my $r1 => Variable $r1 definieren
= Value("R1ZU");; ==> weist den Rückgabewert (on oder off) von R1ZU der Variable $r1 zu

Der doppelte ;; ist ein FHEM Thema. Eigentlich würde für Perl ein ; reichen. Aber FHEM nutzt selbst das ; und daher wird ein ;; benötigt. Mit den ersten drei my Zeilen werden die Rückgabewerte den Variablen zugewiesen.

Danach erfolgt ein normales "if then else" Konstrukt. Die Zeile »($r1 eq "on" && $r2 eq "on" && $r3 eq "on")« kann man so lesen: Wenn $r1 den Wert "on" und (&&) $r2 den Wert "on" und $r3 den Wert "on" dann schalte die LEDalleRolloZu ein {fhem("set LEDalleRolloZu on")}
ansonsten else schalte die LED aus. {fhem("set LEDalleRolloZu off")

Alternative: [[structure]]

=== Zeitverzögert schalten ===
{| class="wikitable"
| '''Aufgabe:''' || Zeitverzögert schalten
|-
| '''Beschreibung:''' || Mit einem Notify zeitverzögert eine Aktion auslösen.
|-
| '''Vorbereitung:''' || Gerät "Lampe" ist definiert und es gibt eine Situation, die ein Ereignis "Fernbedienung:.*" generiert.
|-
| '''Befehl:''' || <code>define ntfy1 notify Fernbedienung:.* sleep 7.5;; set Lampe $EVENT</code>
|-
| '''Erläuterungen:''' || Bei Eintreten eines Ereignisses "Fernbedienung*" wird nach einer Pause von siebeneinhalb Sekunden der Befehl <set Lampe ??> ausgeführt, wobei der eigentliche Befehl aus dem auslösenden Ereignis übernommen wird.
:''Quelle: {{Link2Forum|Topic=17161|LinkText=FHEM Forum}}''
|}

=== Eine PV-Anlage (Solarstrom) zur Steuerung der Rollos nutzen (optional Zeit und Datums abhängig) ===
Hier ein kleines Beispiel, wie man mit Hilfe einer PV-Anlage die Sonneneinstrahlung auf der Südseite ermittelt und dies zur Rolladensteuerung nutzt.
Optional: Die Funktion soll allerdings nur zwischen 9:30 und 17:00 stattfinden. (zweites Beispiel)
Optional: Die Funktion soll nur zwischen dem 6. und 9. Monat funktioneren. (drittes Beispiel)

==== Vorbereitung ====
PV Anlage mit SolarView abfragen.
Per Hand ermitteln, ab wieviel erzeugtem Strom es sinnvoll ist die Rollos zu schließen.

==== notify Syntax ====
FHEM:

define sv SolarView solarview 15000 wr1 wr2 wr3 wr4 <----vier Wechselrichter
attr sv event-on-change-reading currentPower

define nt.sonnenlichtpersolar notify (sv:currentPower.*) {
if ($EVTPART1 < 3000 ) {
fhem('set Flur1 Auf');
}else {
if ($EVTPART1 > 5000 ) {
fhem('set Flur1 Ab');
}
}
}

Optional 1: Zeitabhängig
<syntaxhighlight lang="Perl">
(sv:currentPower.*) {
my $hm = sprintf("%02d:%02d", $hour, $min);
if ( $hm gt "09:30" && $hm lt "17:00") {
if ($EVTPART1 < 5000 ) {
fhem('set Flur1 Auf');
}else {
if ($EVTPART1 > 8000 ) {
fhem('set Flur1 Ab');
}
}
}
}
</syntaxhighlight>
Optional 2: Zeit und Datum
<syntaxhighlight lang="Perl">
(sv:currentPower.*) {
my $hm = sprintf("%02d:%02d", $hour, $min);
if ($month >= 6 && $month <= 9) {
if ( $hm gt "09:30" && $hm lt "17:00") {
if ($EVTPART1 < 5000 ) {
fhem('set Flur1,RBUERO1,RBUERO2 Auf');
}else {
if ($EVTPART1 > 8000 ) {
fhem('set Flur1,Flur2,RBUERO1,RBUERO2 Ab');
}
}
}
}
}
</syntaxhighlight>

==== Erklärung ====
* Das define wird in der Kommandozeile im Webbrowser eingegeben.
* Anschließend wird im Webbrowser die DEF bearbeitet, das erspart uns Probleme mit Perl
* define sv SolarView ... <==== ist die Schnittstelle vom SolarView
* define nt.sonnenlichtpersolar notify (sv:currentPower.*) { <==== hier wird ein notify angelegt, der auf das "define sv" Wert "currentPower.*" (.* ist irgendwas) reagiert
if ($EVTPART1 < 3000 ) {
fhem('set Flur1 Auf');
}else {
if ($EVTPART1 > 5000 ) {
fhem('set Flur1 Ab');
}
}
}
Diese if-Funktion wertet den Rückgabewert von currentPower aus. Hierbei muss man wissen, dass $EVTPART1 das Split-Ergebnis vom Rückgabewert ist

Beispiel: Der Rückgabewert (wie im Beispiel) ist "currentPower: 6000".
Jetzt steht im "$EVTPART0 == currentPower:" und im "$EVTPART1 == 6000"
Das bedeutet, dass man sich nicht selbst den richtigen split (Perl Befehl) Aufruf ausdenken muss, dies übernimmt vielmehr FHEM.

Ergebnis:
Das Rollo wird abhängig von der erzeugten IST_Strommenge auf und zu gefahren.
Damit dies nicht dauernd hin und her pendelt, wurde der Auf Wert sehr klein und den Ab Wert sehr groß gewählt.

'''Optional 1:''' Der Block "my $hm = sprintf("%02d:%02d", $hour, $min);" erzeugt die String-Variable $hm mit dem Inhalt $hour:$min. %02d begrenzt die Ausgabe auf zwei Stellen.
Danach wird mit "if ( $hm gt "09:30" && $hm lt "17:00")" mit stringvergleichenden Operatoren geprüft, ob die Uhrzeit zwischen 9:30 und 17:00 liegt (lt = kleiner als; gt = größer als). Es wäre auch ein le und ge möglich: le = kleiner/gleich als, ge = größer/gleich als.

'''Optional 2:'''if( $month >= 6 && $month <= 9) {

Hier wird die numerische FHEM-Standard-Variable $month (Monat) auf größer/gleich bzw kleiner/gleich mit den binären Operatoren überprüft.
Die Funktion arbeitet also nur zwischen dem 6. und dem 9. Monat und dann auch nur zwischen 9:31 und 16:59.

=== Status eines Kippfensters mit 2 Fensterkontakten abbilden ===

==== Vorbereitung ====
Es ist je ein Fensterkontakt der ''open'' oder ''closed'' meldet, oben und unten am Fenster angebracht.
Die Namen der beiden FHEM-Devices sind ''fensterKontaktOben'' und ''fensterKontaktUnten''.

==== notify Syntax ====
FHEM:
define statusFenster notify fensterKontakt(Oben|Unten):(open|closed) {
if ( ReadingsVal('fensterKontaktOben', 'state', 'undef') eq 'open' && ReadingsVal('fensterKontaktUnten', 'state', 'undef') eq 'open')
{ fhem 'set Terrassentuer open' }
if ( ReadingsVal('fensterKontaktOben', 'state', 'undef') eq 'closed' && ReadingsVal('fensterKontaktUnten', 'state', 'undef') eq 'closed')
{ fhem 'set Terrassentuer closed' }
if ( ReadingsVal('fensterKontaktOben', 'state', 'undef') eq 'open' && ReadingsVal('fensterKontaktUnten', 'state', 'undef') eq 'closed')
{ fhem 'set Terrassentuer tilted' }
if ( ReadingsVal('fensterKontaktOben', 'state', 'undef') eq 'closed' && ReadingsVal('fensterKontaktUnten', 'state', 'undef') eq 'open')
{ fhem 'set Terrassentuer undef' }
}

== Weitere Hinweise ==
* Entsprechend zu $EVENT gibt es auch noch $NAME und $TYPE. $NAME und $TYPE enthalten den Namen bzw. Typ des Ereignis auslösenden Gerätes.
* Wird der Perl-Code in einem <code>notify</code> immer länger, lagere den Code wegen der Übersichtlichkeit in eine eigene Programmdatei aus, wie in [[99_myUtils anlegen]] beschrieben.
* Achtung! Wenn man das Skript für den notify-Befehl über mehrere Zeilen schreibt, muss man anscheinend darauf achten, dass keine abschließende Leerzeile mitgespeichert wird. Sonst wird der notify-Befehl ignoriert.
* Dieser {{Link2Forum|Topic=38520|Message=307325}} enthält Vorschläge zur Vorgehensweise bei der Erstellung von komplexen ''notify'' Definitionen bzw. bei deren Fehlerbehebung.

== Weiterführende Links ==
* [[Escapen in Perlbefehlen]]
* [[Klammerebenen]]
* Forenbeitrag zum Thema {{Link2Forum|Topic=115414|LinkText=Optimierung des Suchmusters - NOTIFYDEV}}

== Hinweise ==
<references />

[[Kategorie:HOWTOS]]
[[Kategorie:Hilfsmodul]]

Notify

2021-05-09T16:16:16Z

TomLee: Wikitabelle bearbeitet

{{SEITENTITEL:notify}}
{{Infobox Modul
|ModPurpose=Ausführung von Anweisung(en) als Reaktion auf Ereignisse
|ModType=h
|ModCmdRef=notify
|ModForumArea=Automatisierung
|ModTechName=91_notify.pm
|ModOwner=rudolfkoenig ({{Link2FU|8|Forum}} / [[Benutzer Diskussion:Rudolfkoenig|Wiki]])
}}

== Einführung ==
{{Hinweis|Weitere grundlegende Informationen/Beispiele zu notify enthält [http://fhem.de/Heimautomatisierung-mit-fhem.pdf Heimautomatisierung mit FHEM]}}
Das Hilfsmodul notify dient dazu [[Ereignis|Ereignisse]] über ein Suchmuster zu erkennen und bei einem Treffer eine Aktion auszulösen. Mit ''notify'' und anderen [[Eventhandler|Eventhandlern]] <ref>hierzu gehören u.a. auch [[DOIF]], [[THRESHOLD]] und [[watchdog]]</ref> ist es möglich, Logikfunktionen im FHEM abzubilden.

'''Beispiele:'''
* Wird das Licht in der Küche eingeschaltet, soll FHEM dort auch das Radio einschalten.
* Bei Druck auf einen Taster soll die Umwälzpumpe für das Warmwasser eingeschaltet werden.
* Erweiterte Möglichkeiten: Aber nur, wenn das Radio aus ist bzw. die Temperatur im Rücklauf des Warmwassers unterhalb einer bestimmten Schwelle liegt<ref>vgl. hierzu z.B. {{Link2CmdRef|Anker=devspec|Label=FILTER}} und [[if-condition]]</ref>.

== Syntax ==

define <name> notify <Suchmuster> <command>

Das ''[[Regulärer Ausdruck|Suchmuster]]'' (häufig als Regexp = regular expression = regulärer Ausdruck bezeichnet) ist sehr wichtig: Es ist entweder der Name des auslösenden ("triggernden") Gerätes oder die Kombination aus Gerät und auslösendem Ereignis (Event) <code>Gerätename:Event</code>. Die Events kann man dem [[Event_monitor|Event-Monitor]] entnehmen. Wenn dort z.B. <code>Rollo1</code> steht, dann reagiert ''notify'' auf <code>Rollo1 on</code> und <code>Rollo1 off</code> usw.

Wenn man mehrere Suchmuster kombinieren möchte, kann man diese in Klammer schreiben, als Trenner wird dann Pipe (|) genutzt: <code>(Rollo1|Rollo2|Steckdose5)</code>.

'''Auch die Verwendung von Platzhaltern ist möglich''':
* <code>Rollo.</code> → das notify reagiert auf alles was mit Rollo und '''einem''' weiteren beliebigen Zeichen anfängt. Also auf Rollo1 wie auch auf RolloG, aber nicht auf Rollo_wischundweg
* <code>Rollo.*</code> → notify reagiert auf alles das mit Rollo beginnt
* <code>.*isch</code> → auf alles das mit isch aufhört (Tisch, Fisch)
* <code>Schalter(1|2|3)</code> → hört auf Schalter1, Schalter2 und Schalter3
* <code>dimmer:pct:.(100|7[6-9]|[89][0-9])</code> → reagiert, wenn pct einen Wert über 75 annimmt.

Suchmuster/Regex kann man im Internet beispielsweise auf [http://regexpal.com/| http://regexpal.com/] testen.

Es gibt seit Juli 2020 eine Perlfunktion notifyRegexpCheck zum Testen, wie FHEM über das Suchmuster "denkt" - siehe {{Link2Forum|Topic=111938|Message=1074202|LinkText=diesen Beitrag}} im Forum.

{{Hinweis|Das '''Suchmuster''' wird notify-intern um das Zeichen ^ (beginnt mit) und das Zeichen $ (endet mit) ergänzt<ref>Der Eventhandler [[DOIF]] verwendet die in Perl übliche Syntax für reguläre Ausdrücke als DOIF-Suchmuster.</ref>.

Deshalb darf das Suchmuster nicht mit einem üblichen [[Regulärer Ausdruck|'''Regulären Ausdruck''']], wie er in Perl<ref>https://perldoc.perl.org/perlre.html</ref> verwendet wird, gleichgesetzt werden, da die Ergänzung zu einem grundsätzlich unterschiedlichen Verhalten führt, siehe nachstehendes Beispiel.}}

'''Beispiel für das unterschiedliche Verhalten von ''Suchmuster'' und ''regulären Ausdruck'''''

Für einen '''regulären Audruck''' gilt: Wenn der reguläre Ausdruck ''lampe'' ist und das [[Ereignis]] ''tischlampe'' dann passen ''tischlampe'' und ''lampe'' zueinander.

Für das '''Suchmuster''' gilt: Wenn das Suchmuster ''lampe'' ist und das [[Ereignis]] ''tischlampe'' dann passen ''tischlampe'' und ''lampe'' '''nicht''' zueinander, weil das Suchmuster zu ^lampe$ ergänzt wird und damit exakt nur auf ''lampe'' matcht (passt).

'''Beispiel Variablen Zuordnung zum Event'''
2020-01-21 22:40:39 HUEDevice VibrationTest1 battery: 88
{| class="wikitable"
|-
! !!$NAME !! colspan="2" |$EVENT
|-
| ||||$EVTPART0 ||$EVTPART1
|-
|2020-01-21 22:40:39 HUEDevice|| VibrationTest1|| battery:|| 88
|}

== FHEMWEB-unterstütztes Anlegen eines notify ==
{{Hinweis|Die Erstellung eines notify und insbesondere die korrekte Angabe des Suchmusters (Regex) führt gerade bei Einsteigern immer wieder zu Schwierigkeiten. Zur Fehlerminimierung empfiehlt es sich zum einen, die [[Konfiguration]] nicht direkt zu bearbeiten, sondern die "Befehl-Eingabezeile", die "Objektdetails" oder den [[Import von Code Snippets|Import von RAW-Definitionen]] zur Bearbeitung zu nutzen.}}

=== Event Monitor ===
Die komfortabelste Möglichkeit, die häufigsten Event-Handler zu erstellen, bietet der [[Event monitor|Event-Monitor]]. Die Vorgehensweis ist in dem zugehörigen Artikel dargestellt.

=== Regexp wizard ===
Zudem enthält FHEM einen Regexp wizard mit dem Regex anhand der in FHEM vorhandenen Devices und deren Events aus einer Auswahlbox selektiert werden können. Voraussetzungen sind:
* Aktivierung des Hilfsmoduls [[eventTypes]] (bei allen Neuinstallationen Standard)
* das gesuchte Ereignis (Event) ist nach Aktivierung des Hilfsmoduls bereits mindestens einmal eingetreten

Schrittweise Darstellung der Nutzung des Regexp wizard zur Anlage eines "notify":

In das [[Konfiguration#Befehl-Eingabefeld|Befehls-Eingabefeld]] eingeben und mit {{Taste|Enter}} bestätigen:
define ntest notify a b
Als Beispiel wird ein notify mit <name> "ntest" angelegt. "a" und "b" sind beliebige Platzhalter für <Suchmuster> und <Command>, die bei der weiteren Bearbeitung mit dem endgültigen Werten ersetzt werden.
Der Regexp wizard öffnet sich:
[[Datei:Regexp wizard1.JPG|400px|thumb|center]]
Nun in der Auswahlbox das auslösende Event (Ereignis) auswählen; zunächst das Device und dann das gewünschte Regex. Hier soll das notify bei jeder Veränderung der Temperatur (temperature.*) des Device BTHR918N reagieren. Abschließend mit einem Mausklick auf {{Taste|set}} bestätigen. Wählt man mehrere Regex in dieser Weise aus, so wird das "notify" bei Eintritt jedes dieser Events ausgeführt:
[[Datei:Regexp wizard2.JPG|400px|thumb|center]]
Anschließend den Platzhalter "a" mit Klick auf den Link "removeRegexpPart" löschen:
[[Datei:Regexp wizard3.JPG|400px|thumb|center]]
Den Link "DEF" anklicken, damit sich der DEF-Editor öffnet:
[[Datei:Regexp wizard4.JPG|400px|thumb|center]]
Jetzt den auszuführenden Befehl im "DEF"-Bereich durch Überschreiben des Platzhalters "b" eintragen und mit Klick auf {{Taste|modify ntest}} abschließen:
[[Datei:Regexp wizard5.JPG|400px|thumb|center]]
Das fertige und sofort aktive "notify" sieht abschließend folgendermaßen aus:
[[Datei:Regexp wizard6.JPG|400px|thumb|center]]
Am Schluss das Speichern über {{Taste|Save config}} nicht vergessen.

== Mein notify geht nicht - wie kann ich mir selbst helfen: Debugging ==
Funktioniert ein notify nicht wie gewünscht, kann es nur zwei Hauptursachen haben:
* Entweder das Suchmuster paßt nicht zum gewünschten Auslöser (FHEM Device), und/oder
* die Anweisung enthält einen Fehler.
Sollte kein Fehler im Logfile auftauchen aber das notify ausgelöst werden, stimmt meist der Übertragungsweg zum Zieldevice nicht.
Der STATE des notify zeigt normalerweise mit Datum/Uhrzeit die letzte Auslösung an.

Beim Debuggen sollte man daher beide Elemente getrennt untersuchen. Hier ein Beispiel welches nicht wie gewünscht funktioniert:
<source lang="perl"> define n_test notify n_test:muster Ausführungsteil</source>
Zum debuggen benötigen wir
* den [[Event monitor]]
* das [https://fhem.de/commandref.html#trigger trigger-Kommando] - kann man jederzeit verwenden um das Suchmuster als Event unabhängig vom Auslöser zu erzeugen.
* die FHEM Kommandozeile
* den [[DEF-Editor]]
* eventuell einen Texteditor um Codeblöcke zwischen zu lagern und Notizen zu machen.

Das Suchmuster im Beispiel notify triggert auf sich selbst, es soll auf jeden Event mit dem Inhalt '''muster''' ausgelöst werden, Beispiel:
2018-07-14 14:31:03 notify n_test muster bild

=== Suchmuster ===
Sollte das notify nicht funktionieren:
* keine Reaktion wie gewünscht
* keine Fehlermeldung in der Weboberfläche beim Anlegen, keine Fehlermeldung im Logfile
* STATE ist unverändert auf active oder einem altem Datum/Uhrzeit
liegt der Fehler mit Sicherheit im Suchmuster. Man hat die Chance das Suchmuster mit dem trigger Befehl zu erzeugen und zu schauen ob die Anweisung ausgeführt wird. Dabei ist zu beachten: Der erste ":" im Suchmuster ist zusätzlich zwischen Gerät und Event als Trennung. Jeder weiter : ist, wenn vorhanden, Bestandteil des Events! Siehe dazu den Abschnitt [https://fhem.de/commandref_DE.html#notify Hinweise in der commandref]
*Im Beispiel: Event: n_test muster -> Suchmuster n_test:muster
Um aus dem [[Event]] ein passendes Suchmuster zu erzeugen kann der [[Event monitor|Event-Monitor]] direkt verwendet werden. Man kann ein neues notify erzeugen oder ein Bestehendes modifizieren lassen.

Unser Regex im Beispiel ist zu spezifisch, es triggert nur exakt auf '''muster'''. Dieser Trigger erzeugt den folgenden Eintrag im Eventmonitor, entspricht exakt dem Suchmuster und löst das notify aus:
trigger n_test muster
2018-07-13 11:52:08 notify n_test muster
Das Suchmuster für unsere Anforderung muss in <code>n_test:muster.*</code> geändert werden, damit jeder Event der mit muster beginnt das notify auslöst.
Der . im Regex steht für jedes beliebige Zeichen und der * für eine beliebige Anzahl des Zeichens davor: also beliebig viele beliebige Zeichen nach muster.

Das Suchmuster wird häufig in ein komplizierteres Regex umgewandelt um im notify mehrere Aktionen zu starten. Das eigene Regex kann z.B. mit http://regexpal.com/ oder https://regex101.com/ getestet werden.

Funktioniert der Auslöser, das notify tut aber noch nicht was es soll, müssen wir die Anweisung untersuchen. In unserem korrigierten Beispiel
<source lang="perl"> defmod n_test notify n_test:muster.* Ausführungsteil</source>
folgt beim Kommando <code>trigger n_test muster bild</code> ein Eintrag im Log:
2018.07.13 11:47:57 3: n_test return value: Unknown command Ausführungsteil, try help.
Das notify wurde zwar getriggert aber die Anweisung war nicht ausführbar.

Ein richtiges Suchmuster und eine fehlerhafte Anweisung wird also normalerweise einen Fehlereintrag im Logfile erzeugen!

=== Spezialfall: notify löst zwar aus - aber zu oft ===
In dem Fall ist das Suchmuster (regExp) zu unscharf oder das triggernde Gerät löst das Event zu oft aus. Das regExp sollte so genau wie möglich konstruiert werden, device:.* ist eine einfache aber oft keine gute Wahl!

Im Device, welches den Event auslöst, kann mit den Attributen event-on-.* die Häufigkeit gesteuert werden. Insbesondere ist hier das regExp .* eine Art Standardwahl um aufeinanderfolgende gleichartige Events zu verhindern.
:<code>attr device event-on-change-reading .*</code>
'''Achtung''': durch falsche Angaben kann man Events ganz leicht völlig verhindern!

Siehe auch [[event-on-change-reading]]

=== Anweisung ===
Wird das notify getriggert oder will man ganz schnell mal ein notify testen, kann man die Anweisung durch folgenden Code ersetzen, man öffnet also einfach nur die DEF, kopiert den ursprünglichen Inhalt an einen sicheren Ort und ersetzt die Anweisung durch eine der beiden Zeilen. Die erste Zeile kann man auch einfach mal in der Kommandozeile testen:
<source lang="perl">{Log 1, "Das Notify n_test hat ausgeloest."}
{Log 1, "Das Device $NAME hat ausgeloest, der Event sah so aus: $EVENT"}</source>
Wird das notify ausgelöst, muss anschließend im Logfile ein Eintrag zu finden sein:
2018.07.13 10:28:57 1: Das Notify n_test hat ausgeloest, der Event sah so aus: muster
Unsere Anweisung <code>Ausführungsteil</code> liefert in der Kommandozeile selbst einen Fehler:
<code>Unknown command Ausführungsteil, try help.</code>
Ein Versuch mit geschweiften Klammern <code>{Ausführungsteil}</code> liefert wieder einen Fehler:
<code>Unrecognized character \xC3; marked by <-- HERE after {Ausf<-- HERE near column 6 at (eval 5977) line 1.</code>
Diese Variante <code>{"Ausführungsteil"}</code> liefert den String Ausführungsteil ohne Fehler: Das notify arbeitet fehler- aber sinnfrei.
Der fertige Code:
defmod n_test notify n_test:muster.* {"Ausführungsteil"}

Man kann die Anweisung, normalerweise so wie sie ist, in der FHEM Kommandozeile testen. Sind im Perl Code (in geschweiften Klammern) im DEF Editor Semikolon enthalten muss man diese für den Test in der Kommandozeile (oder Raw Def) verdoppeln.
Laufzeitabhängige Variablen sind in der Kommandozeile meist nicht verfügbar, diese sollte man für den Test einfach durch passende Inhalte austauschen. So kann man die komfortable Variante (loggt den Namen und das komplette Event) nicht in der Kommandozeile ausführen.

Funktioniert ein FHEM Befehl in der Kommandozeile nicht (z.B. Lampe geht nicht an) kann es im notify auch nicht funktionieren, dann muss die Fehlersuche an anderer Stelle fortgeführt werden.

Komplexeren Code im Ausführungsteil sollte man beim Testen in Teilabschnitte aufteilen, von der Laufzeit abhängige Variable ($NAME, $EVENT, $EVTPART) durch Strings ("TestWort") ersetzen, die Teilabschnitte separat testen und anschließend schrittweise wieder komplettieren.

== Beispiele ==
{{Hinweis|Für die nachfolgenden Beispiele wurden einige unterschiedliche Technologien verwendet. Sie können aber recht einfach auf alle anderen Systeme übertragen werden, dabei sollte ggf. darauf geachtet werden, dass sich Schaltbefehle und Events teilweise je nach konkret eingesetzter Technologie unterscheiden können. Dann ist ggf. eine Erweiterung, z.B. durch eine [[if-condition|if-Abfrage]] erforderlich.}}

=== Schalter entprellen ===
Will man ein notify innerhalb eines bestimmten Zeitraumes nur einmal auslösen lassen, auch wenn er in diesem Zeitraum mehrfach getriggered werden sollte, so bietet sich das Attribut disabledAfterTrigger an,
attr <notify_device> disabledAfterTrigger <Anzahl Sekunden>
In dem Zeitraum wird dann nur einmal (beim ersten Mal) der Befehl ausgelöst, auch wenn mehrfach getriggered wurde. Der Zeitraum kann Bruchteile von Sekunden umfassen.

=== Etwas schalten, wenn ein anderes Gerät geschaltet wird ===

==== Vorbedingungen ====
Dieses Beispiel verwendet eine einfache InterTechno-kompatible Funksteckdose für das Radio und einen HM-Aktor für das Licht:

define RadioKueche IT 000000FFFF 0F F0
define LichtKueche CUL_HM 3A37D6
Beachte: beide kennen als Event bzw. Schaltbefehle ''on'' und ''off''.

==== notify Befehl ====
define LichtamRadioan notify LichtKueche set RadioKueche $EVENT
oder alternativ:
define LichtamRadioan notify LichtKueche { fhem "set RadioKueche $EVENT" }

==== Erklärung ====
* Der Name des ''notify'' "LichtamRadioan" kann frei gewählt werden, er dient nur dazu, das notify in FHEM eindeutig zu identifizieren.
* "$EVENT" ist ein Platzhalter für den Zustand vom Pattern. $EVENT enthält ein "off" wenn das LichtKueche aus- und ein "on" wenn das Licht eingeschaltet wird.
* "{ <perlcode> }" alles was zwischen {} steht ist Perl code. Perl kennt das Schlüsselwort fhem. Das Schlüsselwort FHEM dient dazu, FHEM Befehle auszuführen. Es wird also der FHEM Befehl "set RadioKueche on/off" ausgeführt. on oder off ist abhängig vom Pattern. Der eigentliche FHEM Befehl muss in " " stehen.
* Wann ist ein Wechsel auf die Perl-Ebene erforderlich?
** einfache FHEM-Befehle sollten in der Regel direkt verwendet werden, dies ist ressourcenschonender.
** Immer dann, wenn dies nicht möglich ist, weil z.B. komplexerer Code ausgeführt werden soll, (blockierende) Prozesse ausgelagert werden sollten oder Systembefehle ausgeführt werden, ist es günstiger, auf die Perl-Ebene zu wechseln <ref>In diesem {{Link2Forum|Topic=88398|Message=808685|LinkText=Forenbeitrag}} wird z.B. erläutert, wie man nichtblockierend externe Scripte aufrufen kann, die dann ihre Ergebnisse wieder an FHEM übergeben.</ref>.

=== Einschalten von mehreren Geräten/Lampen, wenn das Licht eingeschaltet wird ===
Dieses Beispiel verwendet einen HM-Aktor für das Licht sowie zwei Milight-Birnen, die einzeln geschaltet werden sollen<ref>Dies ist ausdrücklich keine Empfehlung für diese Technologie und der Module</ref> in den Stehlampen:

==== Vorbedingungen ====
FHEM:
define LichtWZ CUL_HM 3A37D8
define Stehlampe1 MilightDevice RGBW Milight_Wohnzimmer 5
define Stehlampe2 MilightDevice RGBW Milight_Wohnzimmer 6

==== notify Befehl ====
define SteckdoseWZein notify LichtWZ set Stehlampe1,Stehlampe2 $EVENT
oder ''in Perl''
define SteckdoseWZein notify LichtWZ { fhem "set Stehlampe1 $EVENT;;set Stehlampe2 $EVENT " }
==== Erklärung ====
Wenn das LichtWZ eingeschaltet wird, dann werden auch die Stehlampen (1 und 2) eingeschaltet.

=== Einfache ODER Funktion ===
Eine einfache ODER Funktion kann sehr einfach realisiert werden

==== Vorbereitung ====
KNX:
* 3x GAs der abzufragende Werte (0/0/40 0/0/41 0/0/42)

FHEM:
define Licht1 CUL_HM 3A37D8
define Licht2 CUL_HM 1B7EC3
define Stehlampe MilightDevice RGBW Milight_Wohnzimmer 7

==== notify Befehl ====
define SteckdoseWZein notify (Licht1|Licht2) set Stehlampe $EVENT
oder
define SteckdoseWZein notify (Licht.) set Stehlampe $EVENT

==== Erklärung ====
Die Werte in der Klammer (wichtig ist das »|«) sind die Rückgabewerte. Alternativ kann in diesem Beispiel auch »Licht.« (zu beachten ist der Punkt) geschrieben werden. Der Punkt ist ein Platzhalter für (genau) ein beliebiges Zeichen.

Danach folgt der set Befehl.
Wenn also das Licht1 oder Licht2 den Wert "on" hat, dann hat auch die Steckdose den Wert "on"

Alternative: [[structure]]

=== Einfache UND Funktion ===
Ob man dieses Konstrukt noch als einfach bezeichnen kann, wage ich mal zu bezweifeln. In FHEM fehlen Loggingfunktionen, die man alle selber mit Perl Code erstellen kann (Danke an MAZ).
Dadurch ist FHEM zwar mächtig, wird aber für viele sehr kompliziert.

In diesem Beispiel soll - wenn drei Rollos geschlossen sind - am Taster eine LED eingeschaltet werden.

==== Vorbereitung ====
KNX:
* 3x GDs für die Rückgabewert Rollo geschlossen == 1 (0/0/50 0/0/51 0/0/52)
* GD LED am Lichtschalter (0/0/106)

FHEM:
define R1ZU KNX 0/0/50:dpt1.009
attr R1ZU dummy 1
define R2ZU KNX 0/0/51:dpt1.009
attr R2ZU dummy 1
define R3ZU KNX 0/0/52:dpt1.009
attr R3ZU dummy 1
define LEDalleRolloZu KNX 0/0/106:dpt1
Durch das Attribut dummy werden keine Schaltfunktion angeboten. Es kann nur Werte anzeigen.

==== notify Befehl ====
define nt.allerolloszu notify (R1ZU|R2ZU|R3ZU) {
my $r1 = Value("R1ZU");;
my $r2 = Value("R2ZU");;
my $r3 = Value("R3ZU");;
if ($r1 eq "on" && $r2 eq "on" && $r3 eq "on") {
fhem("set LEDalleRolloZu on");;
} else {
fhem("set LEDalleRolloZu off");;
}
}

==== Erklärung ====
Es werden die drei Rückgabewerte R1ZU, R2ZU und R3ZU ausgewertet. Danach folgt Perl Code, deswegen beginnt das ganze mit einer { und endet mit }

my $r1 => Variable $r1 definieren
= Value("R1ZU");; ==> weist den Rückgabewert (on oder off) von R1ZU der Variable $r1 zu

Der doppelte ;; ist ein FHEM Thema. Eigentlich würde für Perl ein ; reichen. Aber FHEM nutzt selbst das ; und daher wird ein ;; benötigt. Mit den ersten drei my Zeilen werden die Rückgabewerte den Variablen zugewiesen.

Danach erfolgt ein normales "if then else" Konstrukt. Die Zeile »($r1 eq "on" && $r2 eq "on" && $r3 eq "on")« kann man so lesen: Wenn $r1 den Wert "on" und (&&) $r2 den Wert "on" und $r3 den Wert "on" dann schalte die LEDalleRolloZu ein {fhem("set LEDalleRolloZu on")}
ansonsten else schalte die LED aus. {fhem("set LEDalleRolloZu off")

Alternative: [[structure]]

=== Zeitverzögert schalten ===
{| class="wikitable"
| '''Aufgabe:''' || Zeitverzögert schalten
|-
| '''Beschreibung:''' || Mit einem Notify zeitverzögert eine Aktion auslösen.
|-
| '''Vorbereitung:''' || Gerät "Lampe" ist definiert und es gibt eine Situation, die ein Ereignis "Fernbedienung:.*" generiert.
|-
| '''Befehl:''' || <code>define ntfy1 notify Fernbedienung:.* sleep 7.5;; set Lampe $EVENT</code>
|-
| '''Erläuterungen:''' || Bei Eintreten eines Ereignisses "Fernbedienung*" wird nach einer Pause von siebeneinhalb Sekunden der Befehl <set Lampe ??> ausgeführt, wobei der eigentliche Befehl aus dem auslösenden Ereignis übernommen wird.
:''Quelle: {{Link2Forum|Topic=17161|LinkText=FHEM Forum}}''
|}

=== Eine PV-Anlage (Solarstrom) zur Steuerung der Rollos nutzen (optional Zeit und Datums abhängig) ===
Hier ein kleines Beispiel, wie man mit Hilfe einer PV-Anlage die Sonneneinstrahlung auf der Südseite ermittelt und dies zur Rolladensteuerung nutzt.
Optional: Die Funktion soll allerdings nur zwischen 9:30 und 17:00 stattfinden. (zweites Beispiel)
Optional: Die Funktion soll nur zwischen dem 6. und 9. Monat funktioneren. (drittes Beispiel)

==== Vorbereitung ====
PV Anlage mit SolarView abfragen.
Per Hand ermitteln, ab wieviel erzeugtem Strom es sinnvoll ist die Rollos zu schließen.

==== notify Syntax ====
FHEM:

define sv SolarView solarview 15000 wr1 wr2 wr3 wr4 <----vier Wechselrichter
attr sv event-on-change-reading currentPower

define nt.sonnenlichtpersolar notify (sv:currentPower.*) {
if ($EVTPART1 < 3000 ) {
fhem('set Flur1 Auf');
}else {
if ($EVTPART1 > 5000 ) {
fhem('set Flur1 Ab');
}
}
}

Optional 1: Zeitabhängig
<syntaxhighlight lang="Perl">
(sv:currentPower.*) {
my $hm = sprintf("%02d:%02d", $hour, $min);
if ( $hm gt "09:30" && $hm lt "17:00") {
if ($EVTPART1 < 5000 ) {
fhem('set Flur1 Auf');
}else {
if ($EVTPART1 > 8000 ) {
fhem('set Flur1 Ab');
}
}
}
}
</syntaxhighlight>
Optional 2: Zeit und Datum
<syntaxhighlight lang="Perl">
(sv:currentPower.*) {
my $hm = sprintf("%02d:%02d", $hour, $min);
if ($month >= 6 && $month <= 9) {
if ( $hm gt "09:30" && $hm lt "17:00") {
if ($EVTPART1 < 5000 ) {
fhem('set Flur1,RBUERO1,RBUERO2 Auf');
}else {
if ($EVTPART1 > 8000 ) {
fhem('set Flur1,Flur2,RBUERO1,RBUERO2 Ab');
}
}
}
}
}
</syntaxhighlight>

==== Erklärung ====
* Das define wird in der Kommandozeile im Webbrowser eingegeben.
* Anschließend wird im Webbrowser die DEF bearbeitet, das erspart uns Probleme mit Perl
* define sv SolarView ... <==== ist die Schnittstelle vom SolarView
* define nt.sonnenlichtpersolar notify (sv:currentPower.*) { <==== hier wird ein notify angelegt, der auf das "define sv" Wert "currentPower.*" (.* ist irgendwas) reagiert
if ($EVTPART1 < 3000 ) {
fhem('set Flur1 Auf');
}else {
if ($EVTPART1 > 5000 ) {
fhem('set Flur1 Ab');
}
}
}
Diese if-Funktion wertet den Rückgabewert von currentPower aus. Hierbei muss man wissen, dass $EVTPART1 das Split-Ergebnis vom Rückgabewert ist

Beispiel: Der Rückgabewert (wie im Beispiel) ist "currentPower: 6000".
Jetzt steht im "$EVTPART0 == currentPower:" und im "$EVTPART1 == 6000"
Das bedeutet, dass man sich nicht selbst den richtigen split (Perl Befehl) Aufruf ausdenken muss, dies übernimmt vielmehr FHEM.

Ergebnis:
Das Rollo wird abhängig von der erzeugten IST_Strommenge auf und zu gefahren.
Damit dies nicht dauernd hin und her pendelt, wurde der Auf Wert sehr klein und den Ab Wert sehr groß gewählt.

'''Optional 1:''' Der Block "my $hm = sprintf("%02d:%02d", $hour, $min);" erzeugt die String-Variable $hm mit dem Inhalt $hour:$min. %02d begrenzt die Ausgabe auf zwei Stellen.
Danach wird mit "if ( $hm gt "09:30" && $hm lt "17:00")" mit stringvergleichenden Operatoren geprüft, ob die Uhrzeit zwischen 9:30 und 17:00 liegt (lt = kleiner als; gt = größer als). Es wäre auch ein le und ge möglich: le = kleiner/gleich als, ge = größer/gleich als.

'''Optional 2:'''if( $month >= 6 && $month <= 9) {

Hier wird die numerische FHEM-Standard-Variable $month (Monat) auf größer/gleich bzw kleiner/gleich mit den binären Operatoren überprüft.
Die Funktion arbeitet also nur zwischen dem 6. und dem 9. Monat und dann auch nur zwischen 9:31 und 16:59.

=== Status eines Kippfensters mit 2 Fensterkontakten abbilden ===

==== Vorbereitung ====
Es ist je ein Fensterkontakt der ''open'' oder ''closed'' meldet, oben und unten am Fenster angebracht.
Die Namen der beiden FHEM-Devices sind ''fensterKontaktOben'' und ''fensterKontaktUnten''.

==== notify Syntax ====
FHEM:
define statusFenster notify fensterKontakt(Oben|Unten):(open|closed) {
if ( ReadingsVal('fensterKontaktOben', 'state', 'undef') eq 'open' && ReadingsVal('fensterKontaktUnten', 'state', 'undef') eq 'open')
{ fhem 'set Terrassentuer open' }
if ( ReadingsVal('fensterKontaktOben', 'state', 'undef') eq 'closed' && ReadingsVal('fensterKontaktUnten', 'state', 'undef') eq 'closed')
{ fhem 'set Terrassentuer closed' }
if ( ReadingsVal('fensterKontaktOben', 'state', 'undef') eq 'open' && ReadingsVal('fensterKontaktUnten', 'state', 'undef') eq 'closed')
{ fhem 'set Terrassentuer tilted' }
if ( ReadingsVal('fensterKontaktOben', 'state', 'undef') eq 'closed' && ReadingsVal('fensterKontaktUnten', 'state', 'undef') eq 'open')
{ fhem 'set Terrassentuer undef' }
}

== Weitere Hinweise ==
* Entsprechend zu $EVENT gibt es auch noch $NAME und $TYPE. $NAME und $TYPE enthalten den Namen bzw. Typ des Ereignis auslösenden Gerätes.
* Wird der Perl-Code in einem <code>notify</code> immer länger, lagere den Code wegen der Übersichtlichkeit in eine eigene Programmdatei aus, wie in [[99_myUtils anlegen]] beschrieben.
* Achtung! Wenn man das Skript für den notify-Befehl über mehrere Zeilen schreibt, muss man anscheinend darauf achten, dass keine abschließende Leerzeile mitgespeichert wird. Sonst wird der notify-Befehl ignoriert.
* Dieser {{Link2Forum|Topic=38520|Message=307325}} enthält Vorschläge zur Vorgehensweise bei der Erstellung von komplexen ''notify'' Definitionen bzw. bei deren Fehlerbehebung.

== Weiterführende Links ==
* [[Escapen in Perlbefehlen]]
* [[Klammerebenen]]
* Forenbeitrag zum Thema {{Link2Forum|Topic=115414|LinkText=Optimierung des Suchmusters - NOTIFYDEV}}

== Hinweise ==
<references />

[[Kategorie:HOWTOS]]
[[Kategorie:Hilfsmodul]]

MQTT2-Module - Praxisbeispiele

2021-03-24T14:39:54Z

TomLee:

== Einführung: MQTT bzw. MQTT2 in FHEM ==
{{Randnotiz|RNTyp=y|RNText=Sollten Sie MQTT2_CLIENT verwenden, beachten Sie bitte, dass der MQTT2_CLIENT die ursprüngliche Herkunft der über MQTT verteilten Informationen nicht kennt. Daher ergeben sich in der Anwendung kleinere Unterschiede, zu deren Verständnis die diesbezüglichen [[MQTT2_CLIENT#Anwendung|Hinweise zu MQTT2_CLIENT]] bekannt sein sollten.}}Zur Einbindung von Geräten, welche zur Nutzung des MQTT-Protokols konfiguriert werden können und darüber mit einem MQTT-Server (früher: Broker) kommunizieren, stehen unter FHEM verschiedene Optionen zur Verfügung, wobei nicht alle Module beliebig miteinander verwendet werden können. Details hierzu sind dieser [[MQTT|Übersicht]] zu entnehmen.

Im Rahmen dieses Artikels wird für die eigentlichen Geräte [[MQTT2 DEVICE|MQTT2_DEVICE]] verwendet, damit wird als IO-Device entweder {{Link2CmdRef|Anker=MQTT2_SERVER|Lang=en|Label=MQTT2_SERVER}} oder [[MQTT2 CLIENT|MQTT2_CLIENT]] benötigt, mit einem IO-Device des Typs [[MQTT (Modul)|MQTT]] funktioniert die nachfolgende Darstellung dagegen nicht<ref>Allerdings können die Konfigurationen in der Regel recht einfach auf die bisherige MQTT-Implementierung übertragen werden</ref>. MQTT2_DEVICE unterstützt u.a. auch die ''setExtensions'' direkt, also z.B. ''on-for-timer<ref>Beachten Sie bei mehrkanaligen Geräten, dass jeweils nur ein Hauptkanal mittels setExtensions verwaltet werden kann! U.a. aus diesen Grund ist es meist sinnvoller, die ''split''-Varianten der attrTemplate-Einrichtung zu verwenden.</ref>'' sowie ''[[MQTT2-Module - Praxisbeispiele#attrTemplate_2|attrTemplate]]''<ref>Auch MQTT_DEVICE unterstützt SetExtensions, allerdings muss dies dort per Attribut eingeschaltet werden</ref>.

=== Allgemeine Einstellungen und Hinweise ===
{{Randnotiz|RNTyp=r|RNText=Beachten Sie, dass für [[autocreate]] in Verbindung mit MQTT2_SERVER '''zwingend''' jeder über MQTT kommunizierende Client eine ClientID angeben muss. Passen Sie daher ggf. die Einstellungen Ihres Geräts an. Manche Geräte verwenden auch "Wegwerf"-ClientID's. Für diese empfiehlt es sich, ggf. dann die durch autocreate erstellten Geräte nachzubearbeiten und die ClientID-Angabe v.a. aus den Inhalten des readingList-Attributs zu entfernen.}}Die nachfolgenden Beispiele gelingen am einfachsten mit '''MQTT2_SERVER als Server ("Broker")''', für diesen sollte dabei ''autocreate'' '''nicht deaktiviert''' sein, damit die erforderlichen MQTT2_DEVICES soweit möglich automatisiert erstellt werden<ref>Dabei wird vorausgesetzt, dass ein allgemeines {{Link2CmdRef|Anker=autocreate|Lang=en|Label=autocreate}}-Device (''TYPE=autocreate'') ebenfalls aktiv ist.</ref> .

Beispiel<ref>MQTT2_SERVER verwendet als default-Einstellung für ''autocreate'' ''simple'', ohne dass ein entsprechendes Attribut gesetzt werden müsste. Die Einstellung ''complex'' empfiehlt sich in der Regel nicht; diese ist jedoch dann zu empfehlen, wenn das Device entweder verschachtelte JSON-Array-Strukturen liefert oder bestimmte Readings nicht gefüllt werden sollen.</ref>:
define MQTT2_FHEM_Server MQTT2_SERVER 1883 global

Falls der MQTT Broker mit Hilfe von [[allowed]] abgesichert wurde, muss in den Geräten ebenfalls User bzw. Passwort eingetragen werden, damit eine MQTT Kommunikation möglich ist.

{{Hinweis|Die Code-Darstellung in diesem Beitrag entspricht jeweils dem RAW-Format zum [[Import von Code Snippets]]. Wer die Attribute direkt und einzeln bearbeitet, muss ggf. die "\" entfernen!}}

=== MQTT-Einstellungen in den Geräten ===
Die Beispiele gehen davon aus, dass die einzubindenden Geräte '''''mit den default-Einstellungen''''' für MQTT betrieben werden, wenn man von den Angaben zum Server und ggf. der Gerätekennung absieht. Es sollten also insbesondere '''keine Veränderungen der topic-Pfade''' vorgenommen werden.

{{Hinweis|Einige der hier beschriebenen Einstellungen haben Änderungen der sich durch die jeweiligen Automatismen eigentlich jeweils ergebenden Standard-Werte zur Folge, insbesondere, was Reading-Namen und von den Geräten gesendete Werte angeht. Sie sollten daher zunächst die Konfiguration des jeweiligen MQTT2-DEVICE-Geräts abschließen, und erst anschließend die weitere Integration mit Event-Handlern, logging usw. vornehmen. }}

=== auto-Konfigurations-features ===
Viele firmwares und Dienste bieten Möglichkeiten an, einer Controller-Software (insbesondere homeassistant) Hilfsdaten zur automatisierten Konfiguration bereitzustellen. Da FHEM diese Daten nicht zu ihrem ursprünglichen Zweck verwenden kann, werden hierdurch lediglich zusätzliche Readings erzeugt, mit denen man als User in der Regel wenig anfangen kann. Es wird daher empfohlen, derartige features '''abzuschalten'''. Wo dies nicht möglich ist, sollte man eine passende [[MQTT2_CLIENT#ignoreRegexp|ignoreRegexp]] setzen bzw. diese passend erweitern!

== zigbee2mqtt ==
[[Bild:MQTT2_zigbee2mqtt_Bulbs.png|400px|thumb|Darstellung in FHEMWEB]]
[https://www.zigbee2mqtt.io zigbee2mqtt] ist ein open-source Projekt, mit dem zigbee-Geräte über MQTT direkt angesprochen werden können, ohne dass hierfür eine Bridge eines Herstellers benötigt wird.

Einzelheiten zur Vorgehensweise sind auf der Detailseite [[Zigbee2mqtt|zigbee2mqtt]] zu finden.

== Tasmota ==
{{Randnotiz|RNTyp=r|RNText=Bitte beachten Sie, dass versicherungsrechtliche Probleme entstehen können, wenn die herstellereigene Firmware ersetzt wird!}}[https://github.com/arendst/Sonoff-Tasmota Tasmota] ('''T'''heo '''A'''rends '''S'''onoff '''M'''QTT '''O'''ver '''T'''he '''A'''ir - einer offenen Firmware von [https://github.com/arendst arendst]) ist eine open-source Software für ESP8266-Geräte, die z.B. statt der originalen Firmware für Sonoff-Geräte und andere ESP8266-basierte WLAN-Steckdosen usw. verwendet werden kann.
{{Hinweis|[[Datei:Tasmota mqtt config.png|120px|thumb|right]]Vor allem, aber nicht nur bei Verwendung des MQTT2_CLIENT als IO, ist es empfehlenswert, in der MQTT-Konfiguration der tasmota-Geräte für den Parameter ''<nowiki>topic = %topic% (tasmota)</nowiki>'' ebenfalls die dynamisch aus der Chip-ID erzeugte Kennung ''DVES_%06X'' zu verwenden. (Kopieren Sie einfach diese Zeichenkette aus dem Eingabefeld für ''"client ..."'', siehe nebenstehende Abbildung). Die eigentliche Umbenennung zu einem "sprechenden Namen" kann dann innerhalb von FHEM - mittels ''rename'' oder ggf. mit einem ''alias'' - erfolgen.}}
=== MQTT2_DEVICE ===
Dieses sollte bei aktiviertem ''autocreate'' am MQTT2_SERVER-Device automatisch angelegt werden, sobald das betreffende Gerät eingesteckt oder neu gestartet oder an einem evtl. vorhandenen Taster geschalten wird. Bislang wurden Tasmota version(en) ab 6.1.1 bis min. 8.1.0 getestet, dies auf verschiedener Hardware, zunächst mit Sonoff Touch und S20, zwischenzeitlich mit einer Vielzahl von Geräten, die per USB-Adapter oder mit der Methode aus dem [https://www.heise.de/ct/artikel/Tuya-Convert-IoT-Geraete-ohne-Loeten-vom-Cloud-Zwang-befreien-4283623.html Tuya-Convert]-Projekt des heise-Verlags auf Tasmota umgeflasht wurden.

=== Manuelle Anpassungen ===
Die RAW-Definition kann dann beispielsweise wie folgt ergänzt werden:
defmod MQTT2_DVES_9B01BD MQTT2_DEVICE DVES_9B01BD
attr MQTT2_DVES_9B01BD IODev m2server
attr MQTT2_DVES_9B01BD readingList DVES_9B01BD:tele/DVES_9B01BD/STATE:.* { json2nameValue($EVENT) }\
DVES_9B01BD:tele/DVES_9B01BD/LWT:.* LWT\
DVES_9B01BD:tele/DVES_9B01BD/UPTIME:.* { json2nameValue($EVENT) }\
DVES_9B01BD:tele/DVES_9B01BD/SENSOR:.* { json2nameValue($EVENT) }\
DVES_9B01BD:tele/DVES_9B01BD/INFO1:.* { json2nameValue($EVENT) }\
DVES_9B01BD:tele/DVES_9B01BD/INFO2:.* { json2nameValue($EVENT) }\
DVES_9B01BD:tele/DVES_9B01BD/INFO3:.* { json2nameValue($EVENT) }\
DVES_9B01BD:stat/DVES_9B01BD/RESULT:.* { json2nameValue($EVENT) }\
DVES_9B01BD:stat/DVES_9B01BD/STATE:.* { json2nameValue($EVENT) }
attr MQTT2_DVES_9B01BD room MQTT2_DEVICE
attr MQTT2_DVES_9B01BD setList on cmnd/DVES_9B01BD/POWER on\
off cmnd/DVES_9B01BD/POWER off\
reboot cmnd/DVES_9B01BD/Restart 1
attr MQTT2_DVES_9B01BD webCmd on:off:reboot

=== attrTemplate ===

===== Allgemeines =====
Für gängige Tasmota-Geräte stehen ''templates'' bereit, mit denen sich diese schnell konfigurieren lassen.
Beachten Sie dazu den Abschnitt ''attrTemplate'' in [[MQTT2 DEVICE#attrTemplate|MQTT2_DEVICE]]. Bei Anwendung eines template mit "split" im Namen werden dabei weitere Geräte angelegt und konfiguriert.{{Hinweis|Bitte attrTemplates nicht verwechseln mit templates, die auf den Tasmota- bzw. Blackadder-Seiten angeboten werden, welche zur Konfiguration der firmware genutzt werden können! Es sollte zunächst die firmware korrekt eingerichtet werden, so dass das Gerät selbst direkt auf dessen Web-Interface korrekt bedient werden kann.}}

===== Kein passendes attrTemplate vorhanden? =====
Exisitert (noch) kein passendes attrTemplate, ist zu empfehlen, zunächst das "''tasmota_basic''" anzuwenden. Dieses führt einige Basiskonfigurationen durch, die für FHEM hilfreich sind, z.B. wird die firmware so eingestellt, dass Schaltzustände in Kleinschreibung übermittelt werden, statt der defaults "ON" bzw. "OFF".

Allerdings stellt dieses das ''autocreate'' an dem MQTT2_DEVICE auf 0, was dann nicht optimal ist, wenn man weitere Readings aus dem Gerät erwartet, etwa, weil zusätzliche Sensoren vorhanden sind. In diesem Fall empfiehlt es sich, das ''autocreate''-Attribut an dem MQTT2_DEVICE zu löschen, damit alle weiteren Informationen verarbeitet werden und ggf. im ''jsonMap''-Attribut nur die Angabe "''POWER1:state''" zu belassen.

=== on-for-timer ===
Um z.B. ein Relais nur für einen Zeitraum anzuschalten, kann man bei Tasmota-Geräten zwischen mehrere Varianten wählen. Ohne speziellen ''setter'' in der ''setList'' werden die '''SetExtensions''' verwendet. Timer laufen damit innerhalb FHEM. Da diese intern als temporäres [[at]] ausgeführt werden, sind diese auch noch nach einem FHEM-Neustart vorhanden, sofern FHEM ordnungsgemäß beendet und neu gestartet wird.

Die Tasmota-firmware bietet ergänzend dazu zwei Möglichkeiten an, bei denen der Timer direkt auf dem ESP-Microcontroller verwaltet wird:

==== delay ====
Zeile zur Erweiterung der ''setList'' (Attributeingabe via FHEMWEB!):
on-for-timer {my $duration = $EVTPART1*10; 'cmnd/DVES_575127/Backlog POWER1 1; delay '.$duration.'; POWER1 0'}

Ohne Auswirkungen auf alles, was danach kommt, hat aber den Nachteil, dass die möglichen Zeitspannen auf 3600 1/10 Sekunden begrenzt sind (siehe https://github.com/arendst/Tasmota/wiki/Commands#delay), also 6 Minuten.

====pulseTime ====
Zeile zur Erweiterung der ''setList'' (s.o.):
on-for-timer {my $duration = $EVTPART1 < 11.2 ? $EVTPART1*10 : $EVTPART1+100; 'CMNDTOPIC/Backlog pulseTime1 '.$duration.'; POWER1 1'}
Auch hier sind die möglichen längsten Einschaltdauern begrenzt, allerdings ist diese mit 18h deutlich länger als mit ''delay''. Diese Implementierung hat den Nachteil, dass der ESP-Microcontroller die jeweils letzte pulseTime auch für alle weiteren "normalen" Einschaltvorgänge berücksichtigt, das Relais also ebenfalls nach Ablauf der übermittelten pulseTime abgeschaltet wird; dies gilt allerdings ohne explizites ''save'' nur bis zum nächsten reboot des Microcontrollers.

=== zigbee2tasmota ===
[https://tasmota.github.io/docs/Zigbee/ zigbee2tasmota] ist eine Erweiterung der Tasmota-firmware für Microcontroller, insbesondere dem ESP8266 (und ESP32)(link), über die einige ZigBee-Chipsätze (insbesondere TI CC2530) als [[ZigBee#Koordinator_.28ZigBee_coordinator.2C_ZC.29|Coordinator]] eingebunden werden können, um ein ZigBee-Netzwerk aufzubauen.
{{Hinweis|Stand 08/2020 war die Einbindung anderer Chipsätze erst in einem Alpha-Stadium; die Zahl der über einen CC2530 einbindbaren ZigBee-Geräte ist daher derzeit relativ begrenzt (ca. 16)!}}
Auch für diese Lösung stehen einige ''attrTemplate'' zur Verfügung. Nähere Informationen hierzu sind dem Artikel [[Zigbee2Tasmota-MQTT]] zu entnehmen.

== ESPurna ==
ESPurna ist eine weitere alternative firmware für ESP8266-basierte Geräte, Details sind der [https://github.com/xoseperez/espurna/wiki Projektseite] zu entnehmen.

Das Format, in dem ESPurna Daten sendet, unterscheidet sich v.a. darin, dass bool'sche Werte als 0 oder 1 gesendet werden, und nicht wie sonst üblich als "on" oder "off" oä.. Es stehen einige Mustertemplates zur Verfügung, um diese Art der Payload in FHEM-konforme Werte zu überführen.

== Shelly ==
=== Vorbemerkung ===
Auch für Shelly-Geräte steht eine Auswahl an [[MQTT2-Module - Praxisbeispiele#attrTemplate_2|templates]] bereit.
Beachten Sie auch hier, dass uU. bei Anwendung eines template mit "split" im Namen weitere Geräte angelegt und konfiguriert werden.

Standardmäßig senden die Shelly-Geräte ihren kompletten Status alle 30 Sekunden. Dies kann man über den Parameter ''mqtt_update_period'' in den ''settings'' ändern, allerdings ist dieser nur über die HTTP-Schnittstelle des Shelly verfügbar. Um diese Statusupdates abzustellen, kann über den Browser folgender Befehl verwendet werden:
http://<ip-des-shelly>/settings?mqtt_update_period=0,
Soweit bekannt, werden dann nur statische updates ausgeschaltet, z.B. für das Relay bzw. angeschlossene Taster oder Schalter; insbesondere Verbrauchswerte werden dennoch aktualisiert.

=== Shelly1 ===

=== Shellybulb ===
Zunächst muss man einen Statusupdate des Shellybulb erzwingen (Aus- und Einschalten, physikalisch oder per Web-UI), damit das Gerät bei eingeschaltetem autocreate angelegt wird. Dies sieht zunächst so aus:
Internals:
CFGFN
CID shellybulb_3CC533
DEF shellybulb_3CC533
DEVICETOPIC MQTT2_shellybulb_3CC533
IODev MQTT2_FHEM_Server
NAME MQTT2_shellybulb_3CC533
NR 246
STATE ???
TYPE MQTT2_DEVICE
READINGS:
2018-12-12 19:28:08 status_blue 0
2018-12-12 19:28:08 status_brightness 61
2018-12-12 19:28:08 status_effect 0
2018-12-12 19:28:08 status_gain 26
2018-12-12 19:28:08 status_green 0
2018-12-12 19:28:08 status_ison true
2018-12-12 19:28:08 status_mode color
2018-12-12 19:28:08 status_red 255
2018-12-12 19:28:08 status_temp 3250
2018-12-12 19:28:08 status_white 0
Attributes:
IODev MQTT2_FHEM_Server
readingList shellybulb_3CC533:shellies/shellybulb-3CC533/color/0/status:.* { json2nameValue($EVENT, 'status_') }
room MQTT2_DEVICE
[[Bild:MQTT2 Shellybulb.png|400px|thumb|Darstellung in FHEMWEB nach Anwendung des template]]Dann bei den set-Anweisungen das attrTemplate "shellybulb" auswählen und setzen. Es erscheint eine Abfrage, ob die vorhandenen Readings gelöscht werden sollen. Diese bitte bestätigen und die Seite neu laden. Danach einmal An- und Ausschalten, damit die Readings auch durch einen neuen Status initialisiert werden und die Seite im Browser neu laden.

=== Shelly Plug S ===
Über die Leistungsmessung des Shelly Plug S lässt sich sehr einfach auch eine Erkennung des Betriebszustandes des angeschlossenen Gerätes realisieren. Dazu stellt man zuerst fest, wieviel Leistung das Gerät in jedem Betriebszustand verbraucht und kann dann z.B. für einen angeschlossenen Fernseher, der im Standby 1 Watt und im Betrieb > 100 Watt verbraucht, den Zustand erkennen und als on/off Status anzeigen. Dazu wird das state Reading wie folgt definiert:
attr readingList shellies/shellyplug-s-123456/relay/0/power:.* { { state => $EVTPART0<100?"off":"on" } }
Der Status des MQTT2 Devices zeigt dann bei <100W "off" und sonst "on" an.

=== HTTP-Commands ===
In diesem {{Link2Forum|Topic=102369|LinkText=Forumsbeitrag}} wird eine Lösung vorgestellt, um über [[99 myUtils anlegen|myUtils-Code]] weitere Kommandos bereitzustellen, die sonst nur direkt über das Web-Interface zu erreichen sind.

== OpenMQTTGateway ==
Um verschiedene Systeme wie BLE usw. auf MQTT zu bringen bietet sich [https://github.com/1technophile/OpenMQTTGateway OpenMQTTGateway] an, z.B. wird für das Auslesen vieler BLE-Seonsoren lediglich ein ESP32-Board ohne Zusatzhardware (ab ca. 5,- Euro in Fernost erhältlich) benötigt, auf das dann eine vorkompilierte firmware geflasht wird (hierfür wird ein USB-seriell-Wandler benötigt).

Nähere Details sind im Artikel [[OpenMQTTGateway]] zu finden.

== 8-Port-Ethernet Board ==
<gallery>
datei:8-relais-ethernetboard closed.jpg|mit Gehäuse
datei:8-Port-MQTT-Relais-Board.jpg|ohne Gehäuse
</gallery>
In diesem {{Link2Forum|Topic=107536|Message=1016379|LinkText=Forenbeitrag}} bzw. dem betreffenden Thread wurde ein Relais-Board vorgestellt, mit dem 8 Relais über Ethernetkabel verbunden werden, die Kommunikation erfolgt dann über MQTT. Über die verwendete Software ist wenig bekannt, es könnte jedoch sein, dass diese Art der Einbindung auch bei weiteren Boards funktioniert, die einen bestimmten Ethernet-Chipset von TI (DP83848) und eine Cortex M3 MCU verwenden.

== Milight-Bridge ==
=== Vorbemerkung ===
Der [https://github.com/sidoh/esp8266_milight_hub esp8266_milight_hub] ist ein open source- Projekt, mit dem auf Basis von ''openmili'' eine Vielzahl von MiLight-Geräten gesteuert werden können. Der MiLight-Hub erstetzt dabei eine beliebige Zahl von Milight-Bridges und ist auch zu verschiedenen Versionen des MiLight-Protokols kompatibel.
Neben MQTT kann dieser auch mit HTTPMOD oder Wifilight (bzw. den MiLight-Modulen) gesteuert werden. Die Hardware entspricht dabei im Wesentlichen einem MySensors-Wifi-Gateway<ref>Es wird lediglich ein anderer CS-PIN genutzt. Dies kann einfach in der Web-Oberfläche der Firmware umgestellt werden.</ref>.
Hier wird vorausgesetzt, dass eine funktionierende Bridge vorhanden ist.
Der Vorteil der MQTT-Lösung liegt darin, dass man bei kompatiblen Fernbedienungen auch direkt Informationen über Schaltvorgänge erhält, die mit der Fernbedienung ausgelöst werden.

=== Einstellungen am MiLight-Hub ===
Die zum FHEM-Server bzw. dem MQTT2_SERVER passenden Vorgaben sind im Web-Interface des Hub einzustellen. Gegebenenfalls passen Sie die vom Hub zurückzugebenden Elemente im Web-Interface des Hub an.
Die Einstellungen für ''MQTT topic pattern'' usw. können auf den default-Werten<ref>Diese sind: <br>''milight/:device_id/:device_type/:group_id'' für "topic pattern"<br>''milight/updates/:hex_device_id/:device_type/:group_id'' für "update topic pattern"<br>''milight/states/:hex_device_id/:device_type/:group_id'' für "state topic pattern". Der Autor hat derzeit folgende Infotypen zum Senden markiert: "status, brightness, hue, color, mode, color_temp, bulb_mode, computed_color, hex_color" (enthält eventuell zu viele Angaben. Bei einem Eventhandler muss man uU. darauf achten, dass kurz hintereinander zweimal dasselbe Event kommen kann (für ON/OFF)).</ref> belassen werden, für die seit Mitte 2019 vorhandene Option, eine LWT-Message zu senden (''MQTT Client Status Topic''), tragen Sie ''milight/LWT'' ein und aktivieren ''Detailed''.

=== FHEM-Devices ===
[[Bild:MQTT2 MiLight.png|400px|thumb|Milight: Darstellung in FHEMWEB]]
==== Bridge ====
Wird nun über den Hub oder eine von diesem erkannte Fernbedienung ein vorhandenes Leuchtmittel geschaltet, wird bei eingeschaltetem autocreate ein erstes Device erstellt, die zunächst erstellte Definition sieht typischerweise etwa so aus:
defmod MQTT2_milight_hub_1370325 MQTT2_DEVICE milight_hub_1370325
attr MQTT2_milight_hub_1370325 IODev MQTT2_FHEM_Server
attr MQTT2_milight_hub_1370325 readingList milight_hub_1370325:milight/updates/0xBE59/rgbw/1:.* { json2nameValue($EVENT, '1_', $JSONMAP) }
attr MQTT2_milight_hub_1370325 room MQTT2_DEVICE

Auf dieses Device wird nun das ''template'' '''esp_milight_hub_bridge''' angewandt.

==== Einzelne Leuchtmittel ====

Wird nun nochmals das oben verwendete Leuchtmittel geschaltet, erstellt autocreate ein weiteres Device:
defmod MQTT2_milight_0xBE59_1 MQTT2_DEVICE milight_0xBE59_1
attr MQTT2_milight_0xBE59_1 IODev MQTT2_FHEM_Server
attr MQTT2_milight_0xBE59_1 readingList milight/states/0xBE59/rgbw/1:.* { json2nameValue($EVENT, '1_', $JSONMAP) }
attr MQTT2_milight_0xBE59_1 room MQTT2_DEVICE

Auf dieses wird nun eines der Bulb-templates angewendet. Wählt man das template X_01_esp_milight_hub_rgbw_bulb, wird eine einfache Variante erstellt, die neben einem toggelnden Icon nur Regler für Helligkeit, die Farbe und zwei Schaltflächen für den Weiß- und Nachtmodus enthält. Wer mehr oder andere Steuerelemente erhalten möchte, verwendet ein anderes template. Nicht benötigte Elemente kann man dabei einfach aus der Definition löschen.

Alle weiteren Devices werden genauso erstellt.

Um ein Device zu erhalten, mit dem sich alle Kanäle gleichzeitig steuern lassen, kann das template ''X_01a_esp_milight_hub_make_rgbw_group'' verwendet werden. Dieses verändert nicht das aktuelle Device, sondern erstellt '''eine Kopie''', die dann modifiziert wird. Diese Kopie ist unter dem Namen ''milight_<RemoteID>_0'' im selben Raum zu finden wie das Ausgangsgerät und kann ebenfalls an die eigenen Wünsche angepasst werden.

Weitere Beispiele:
Beispiel für ein RGB-CCT-Device:
defmod Licht_Wz_all MQTT2_DEVICE
attr Licht_Wz_all IODev MQTT2_Broker
attr Licht_Wz_all eventMap /set_white:Weiss/night_mode:Nacht/white_mode:white/on:on/off:off/ON:on/OFF:off/next_mode:Mode/mode_speed_up:Up/mode_speed_down:Down/
attr Licht_Wz_all group Licht
attr Licht_Wz_all icon light_control
attr Licht_Wz_all readingList milight/0x5D02/rgb_cct/0:.* { json2nameValue($EVENT) }\
milight/updates/0x5D02/rgb_cct/0:.* { json2nameValue($EVENT) }\
milight/states/0x5D02/rgb_cct/0:.* { json2nameValue($EVENT) }\

attr Licht_Wz_all room Wohnzimmer
attr Licht_Wz_all setList on milight/0x5D02/rgb_cct/0 {"status":"ON"}\
off milight/0x5D02/rgb_cct/0 {"status":"OFF"}\
level milight/0x5D02/rgb_cct/0 {"$EVTPART0":"$EVTPART1"}\
hue:colorpicker,HUE,0,1,359 milight/0x5D02/rgb_cct/0 {"$EVTPART0":"$EVTPART1"}\
command:uzsuSelectRadio,Weiss,Nacht,Mode,Up,Down milight/0x5D02/rgb_cct/0 {"$EVTPART0":"$EVTPART1"}\
brightness:colorpicker,BRI,0,1,255 milight/0x5D02/rgb_cct/0 {"$EVTPART0":"$EVTPART1"}\
next_mode milight/0x5D02/rgb_cct/0 {"$EVTPART0":"$EVTPART1"}\
mode_speed_up milight/0x5D02/rgb_cct/0 {"$EVTPART0":"$EVTPART1"}\
mode_speed_down milight/0x5D02/rgb_cct/0 {"$EVTPART0":"$EVTPART1"}\
saturation:colorpicker,BRI,0,1,100 milight/0x5D02/rgb_cct/0 {"$EVTPART0":"$EVTPART1"}\
color_temp:colorpicker,CT,153,1,370 milight/0x5D02/rgb_cct/0 {"$EVTPART0":"$EVTPART1"}\
device_id milight/0x5D02/rgb_cct/0 {"$EVTPART0":"$EVTPART1"}\
effect milight/0x5D02/rgb_cct/0 {"$EVTPART0":"$EVTPART1"}\
mode milight/0x5D02/rgb_cct/0 {"$EVTPART0":"$EVTPART1"}\
commands milight/0x5D02/rgb_cct/0 {"$EVTPART0":"$EVTPART1"}
attr Licht_Wz_all sortby 1
attr Licht_Wz_all webCmd command:brightness:saturation:color_temp:hue
attr Licht_Wz_all webCmdLabel command\
:brightness:saturation\
:color_temp:hue
==== Ein Leuchtmittel, mehrere Fernbedienungen ====
Pairt man mehrere Fernbedienungen mit einem Leuchtmittel, sollten auch alle entsprechenden Fernbedienungscodes in das readingList-Attribut übernommen werden. Dazu übernimmt man am einfachsten die Einträge aus den zusätzlichen MQTT2_DEVICEs. Benötigt man das zusätzliche Device nicht separat, um z.B. eine getrennte Gruppenschaltung zu realisieren, kann man dieses löschen. Beispiel-readingList für ein Device, das auf zwei Fernbedienungscodes und zwei Gruppen "hört":

attr Licht_Wz_all readingList milight/states/0x1234/rgbw/2:.* {json2nameValue($EVENT) }\
milight/updates/0x1234/rgbw/2:.* { json2nameValue($EVENT) }\
milight/states/0x1234/rgbw/0:.* { json2nameValue($EVENT) }\
milight/updates/0x1234/rgbw/0:.* { json2nameValue($EVENT) }\
milight/states/0xABCD/rgbw/0:.* { json2nameValue($EVENT) }\
milight/updates/0xABCD/rgbw/0:.* { json2nameValue($EVENT) }\
milight/states/0xABCD/rgbw/4:.* { json2nameValue($EVENT) }\
milight/updates/0xABCD/rgbw/4:.* { json2nameValue($EVENT) }

==== Fernbedienung als Input-Device nutzen ====
In diesem {{Link2Forum|Topic=103493|LinkText=Thread}} ist dargestellt, wie man eine Fernbedingung des Typs FUT089 dazu verwenden kann, einen [[MPD]] oder Rollladenaktoren zu steuern, oder diese Fernbedienung für [[Hue#HUE-Device|HUEDevice]]-Leuchtmittel zu nutzen.
Um hier nur Differenz-Meldungen direkt an die betreffende myUtils-Funktion zu übergeben und doppelte Events zu verhindern, sollte hier die readingList so angepasst werden, dass nur Messages aus dem "updates"-Zweig ausgewertet werden:
defmod MiLight_RC1_0 MQTT2_DEVICE milight_0xABCD_0
attr MiLight_RC1_0 readingList milight/states/0xABCD/fut089/[0-8]:.* {}
milight/updates/0xABCD/fut089/0:.* { FHEM::attrT_MiLight_Utils::MPDcontrol('myMPD',$EVENT, 'Yamaha_Main') }\
milight/updates/0x5D47/fut089/1:.* { FHEM::attrT_MiLight_Utils::FUT_to_RGBW('Licht_Stehlampe_links',$EVENT) }\
milight/updates/0x5D47/fut089/2:.* { FHEM::attrT_MiLight_Utils::FUT_to_RGBW('Licht_Stehlampe_rechts',$EVENT) }\
milight/updates/0x5D47/fut089/3:.* { FHEM::attrT_MiLight_Utils::four_Lights_matrix($EVENT, 'Licht_WoZi_Vorn_Aussen', 'Licht_WoZi_Vorn_Mitte', 'Licht_WoZi_Hinten_Aussen', 'Licht_WoZi_Hinten_Mitte') }\
milight/updates/0x5D47/fut089/4:.* { FHEM::attrT_MiLight_Utils::shuttercontrol('Jalousie_WZ',$EVENT) }\
milight/updates/0x5D47/fut089/5:.* { FHEM::attrT_MiLight_Utils::shuttercontrol('Rollladen_WZ_SSO',$EVENT) }\
milight/updates/0x5D47/fut089/6:.* { FHEM::attrT_MiLight_Utils::shuttercontrol('Rollladen_WZ_SSW',$EVENT) }\
milight/updates/0x5D47/fut089/7:.* {}\
milight/updates/0x5D47/fut089/8:.* {}
attr MiLight_RC_WZ stateFormat CommandSet

== eBus ==
An dieser Stelle sollen lediglich die Grundzüge erläutert werden, eine ausführliche Anleitung über die Konfiguration des [[EBUS-MQTT2|eBus mit MQTT2 gibt es hier]].

=== Vorbereitung und Definition am eBus ===
Vorausgesetzt wird ein laufender eBus-Dämon. Dessen Einrichtung wird im Artikel [[EBUS#Software|EBUS]] beschrieben.
In der Konfiguration des Dämons ( /etc/default/ebusd ) ist die Kommunikation über MQTT zu aktivieren und die Topic-Struktur festzulegen, z.B. ''ebusd/%circuit/%name''.
--accesslevel=* --mqttport=1883 --mqttjson --mqtthost=IpAdresseMQTTSERVER --mqtttopic=ebusd/%circuit/%name
{{Hinweis|Nachfolgend wird davon ausgegangen, dass als Vorgabe für mqtttopic ''ebusd'' verwendet wurde. Dies kann geändert werden, es wird aber dringend empfohlen, das mqtttopic in jedem Fall mit ''ebus...'' zu beginnen!}}

=== Vorbereitung und Definition in FHEM ===
Unabhängig von dem konkret genutzten IO-Modul (MQTT2_SERVER oder MQTT2_CLIENT) sollte an diesem '''''vor''''' den nachfolgenden Schritten zunächst das autocreate ausgeschaltet werden. Weiter sollte geprüft werden, ob es bereits MQTT2_DEVICE-Geräte gibt, die Einträge in der ''readingList'' enthalten, die vom ebus stammen. Da wir die ''readingList'' anschließend mit erweiterten JSON-Optionen erstellen wollen, müssen zumindest sämtliche ''readingList''-Attribute entsprechend bereinigt oder gelöscht werden; in der Regel ist es einfacher, diese Geräte nach dem Deaktivieren des autocreate am IO zu löschen.
{{Randnotiz|RNTyp=y|RNText=Sollten Sie MQTT2_CLIENT als IO nutzen, sollte für das weitere Vorgehen eine Kopie des MQTT2-"Sammeldevices" genutzt werden, und dessen ''CID'' auf ''ebusd'' geändert werden. Nach Anwendung des ebusd-splitter-templates müssen dann alle den ebus betreffenden Einträge aus der ''readingList'' des "Sammeldevices" gelöscht werden oder diese ganz gelöscht.}}Ist der ebus-Dämon lauffähig und für MQTT konfiguriert, sendet dieser regelmäßige Messages.

Sind die Vorbereitungen abgeschlossen, aktivieren wir ''autocreate'' wieder, allerdings wählen wir als autocreate-Methode ''complex'' aus, da der eBus-Dämon teilweise<ref>Dies betrifft vorrangig die Statusmeldungen</ref> eine weiter verschachtelte JSON-Struktur zum Versenden der Informationen verwendet als üblich. Danach wird wie bei den anderen o.g. Geräten automatisch ein neues MQTT2_DEVICE angelegt<ref>Bei Verwendung des MQTT2_CLIENT wird dann die ''readingList'' am bereits definierten MQTT2_DEVICE aus der Kopie des "Sammeldevice" automatisch wieder erstellt bzw. gefüllt.</ref>

==== "ebus-Bridge" ====
Auf das von ''autocreate'' erstellte MQTT2_DEVICE wird nunmehr das template ''eBus_daemon_splitter'' angewendet. Nach einiger Zeit sollte sowohl die readingList an diesem Device erweitert worden sein, wie auch ein oder mehrere neue MQTT2_DEVICE-Geräte angelegt.
Dieses Device liefert zukünftig Readings zum Dämon selbst, wie dessen ''uptime'', alle weiteren am eBus angeschlossenen Teilnehmer werden dagegen zweckmäßigerweise durch ein oder mehrere weitere MQTT2_DEVICE-Geräte dargestellt.

Das ''attrTemplate'' läd eine weitere ''attrTemplate''-file und [[99 myUtils anlegen|99_myUtils-Code]] vom FHEM-Server nach. Beides steht dann auch unmittelbar zur Nutzung zur Verfügung.
==== "ebusd_bai" und weitere Geräte ====
{{Hinweis|Der eBus-Dämon sendet nicht alle Informationen zu allen am eBus angeschlossenen Geräte automatisch. Diese müssen teilweise erst aktiv angefragt werden. Wie das im einzelnen erfolgen kann, ist dem o.g. Detailartikel zu entnehmen.}}
Funktioniert die Kommunikation zwischen dem eBus-Dämon und FHEM, sollte nach einigen Minuten zumindest ein weiteres Gerät namens ''MQTT2_ebus_bai'' angelegt worden sein.

== Sonos2Mqtt ==
Aus einem Versuch heraus ist ein {{Link2Forum|Topic=111711|LinkText=kleines Projekt}} geworden: Die Sonos Umgebung mit Hilfe von sonos2mqtt als generisches MQTT2_DEVICE komfortabel in FHEM einzubinden.

Mit Hilfe von ein paar Templates ist die grundlegende Einbindung in FHEM nach einer kleinen Installation auf Systemebene schnell erledigt. Es läuft derzeit noch zahlreiche Entwicklung und Ideenfindung, die Fortschritte sind live im Thread oder [[Sonos2mqtt|konsolidiert im Wiki]] zu finden.

=== Setup im System ===
Für dies Funktion wird der nodejs Server [https://github.com/svrooij/sonos2mqtt sonos2mqtt] benötigt. Entweder installiert man den lokal, irgendwo im Netzwerk oder nutzt den [[MQTT2-Module - Praxisbeispiele#Verwendung des Docker Containers|Docker Container.]]

Der nodejs Server sonos2mqtt kann aus Sicht von FHEM irgendwo im Netzwerk stehen - aber er muss im gleichen Netzwerk wie die Sonosplayer stehen. Das UPNP Sonosnetzwerk funktioniert nicht über Netzwerksegmente hinweg.

Erreicht der nodejs Server sonos2mqtt den MQTT Server nicht über - default: localhost, Port 1883, keine Anmeldung" - muss der Parameter --mqtt gesetzt werden!

Beispiele:
:<code>--mqtt mqtt://myuser:the_secret_password@192.168.0.3:1800</code> # alles gesetzt
:<code>--mqtt mqtt://192.168.0.3:1800</code> # IP Adresse und Port gesetzt, keine Anmeldung am MQTT Server
:<code>--mqtt mqtt://192.168.0.3</code> # IP Adresse gesetzt, Port ist Standard 1883

Erfolgt der Start mit pm2, werden die Parameter mit einem ''zusätzlichen'' doppelten Bindestrich (--) hinter dem nodejs Modul übergeben.

Beispiel:
<syntaxhighlight lang="perl">
pm2 start sonos2mqtt -- --mqtt mqtt://myuser:the_secret_password@192.168.0.3:1800
</syntaxhighlight>

'''Lokales Setup'''

Voraussetzung: nodejs und pm2 ist installiert und für alle Benutzer verfügbar. <syntaxhighlight lang="bash">
sudo npm install -g sonos2mqtt
</syntaxhighlight>
Je nach Entwicklungsstand sind auch Betaversionen verfügbar. Für aktuelle Betaversionen wird dieser Zusatz beim Setup verwendet. -> sonosmqtt@3.1.0-beta.1

Wird der sonos2mqtt Server auf einer anderen Maschine eingerichtet, ist der Start entsprechend diesem Absatz [[MQTT2-Module - Praxisbeispiele#Autostart von sonos2mqtt im System mit pm2 .28Alternative.29|Autostart von Sonos2mqtt im System mit pm2]] einzurichten.

=== Setup in FHEM ===
Man definiert lediglich ein Bridge Device, der Rest wird automatisch erledigt.

Voraussetzung:
* autocreate im System ist aktiv.
* Der verwendete MQTT2_SERVER steht auf '''autocreate simple''' (default/Standard).
* Templates aktuell kann man leicht in der FHEM Kommandozeile aktualisieren:
<pre>
{ Svn_GetFile("FHEM/lib/AttrTemplate/mqtt2.template", "FHEM/lib/AttrTemplate/mqtt2.template", sub(){ AttrTemplate_Initialize() }) }
</pre>
Bei der Anwendung des Templates für die Bridge wird das Attribut devicetopic ausgelesen oder auf default sonos gesetzt! Wird ein anderer Devicetopic verwendet, muss der bei der Anlage der Bridge gesetzt werden!

'''Achtung dieser Code muss "am Block" in der Raw Def ausgeführt werden!'''
# man kopiert diesen Codeblock,
# drückt im [[Raw definition|Webinterface]] das große {{Taste|+}},
# und fügt den Code ins Editorfenster ein.
# Dort muss/kann man die persönlichen Anpassungen machen.
# Zum Abschluss execute - fertig
Im folgenden Code muss der Name des MQTT2 Servers ersetzt werden!
<syntaxhighlight lang="perl">
define SonosBridge MQTT2_DEVICE
attr SonosBridge IODev NameDesVorhandenenMQTT2Servers
attr SonosBridge room MQTT2_DEVICE
set SonosBridge attrTemplate sonos2mqtt_bridge_comfort
</syntaxhighlight>
Das Template sonos2mqtt_bridge_comfort:
* setzt das Template sonos2mqtt_bridge auf das Device,
* lädt die Datei 99_sonos2mqttUtils.pm aus dem contrib Ordner nach,
* definiert ein notify, dies erledigt im weiteren Betrieb die automatische Konfiguration der automatisch erzeugten MQTT2_DEVICEs.
** mit dem Template sonos2mqtt_speaker (das Template kann auch manuell auf vorhandene Player angewendet werden, die automatische Erzeugung der Player wird aber empfohlen)
** Ermittelt Detailinformation des jeweiligen Players (vor allem IP Adresse und Modelnumber)
** Lädt die Sonosgeräte Icons von den UPNP Devices herunter
** erweitert das setList input Kommando um den TV Eingang (HDMI, spdif) bzw. Line_IN Eingang falls vorhanden (Modelnumber)
* Die Player werden automatisch einzeln erzeugt wenn sie mqtt Nachrichten senden (Play/Stop) oder (alle sofort) wenn der sonos2mqtt Server gestartet wird.

==== Wozu dient die Bridge? ====
Sie stellt ein paar wesentliche Funktionen zu Verfügung
# Auffangen von nicht benötigten MQTT Nachrichten.
# Erzeugung/Weiterleitung von Nachrichten für die einzelnen Player - damit auch die Erzeugung von separaten Playern nach dem Schema MQTT2_RINCON12345678901234567.
# Statusanzeige sonos2mqtt als Reading connected (0 offline, 1 connected, 2 Player connected).
Sie kann zusätzlich als zentrales Device verwendet werden, um die Sonos Umgebung abzubilden, z.B. Readings für Favoriten u.ä.

==== Start sonos2mqtt lokal ====
Der Start / Stop des sonos2mqtt Servers innerhalb von FHEM ist nur lokal simpel möglich. Ist der Server irgendwo im Netzwerk oder im Docker Container, muss man andere Möglichkeiten finden. Der Neustart aus FHEM ist zwar praktisch, aber nicht erforderlich.

Wird eine existierenden Sonos Landschaft inhaltlich verändert (Player dazu/weg), muss der Server neu gestartet werden. Werden Player temporär abgeschaltet, merkt das der Server nach einer Zeit selbst, oder man forciert dies mit einem CheckSubscription an der Bridge.

Soll das Modul sonos2mqtt mit seinen default Einstellungen gestartet werden, genügt dieser kurze Befehl (in der FHEM Kommandozeile):
<syntaxhighlight lang="bash">
"pm2 start sonos2mqtt"
</syntaxhighlight>
Tipp: Verwendet man anstatt "Befehl" den Syntax {qx(Befehl)} in der FHEM Kommandozeile, wirkt der Befehl zwar blockierend aber die Ausgabe erfolgt im Browser und nicht im Logfile. Mit dem Parameter -s erfolgt keine Ausgabe.

==== Autostart von sonos2mqtt mit FHEM ====
Der Code startet sowohl das sonso2mqtt Modul sofort und implementiert ein notify für den zukünftigen automatischen Start beim Start von FHEM.
<syntaxhighlight lang="perl">
define n_pm2_sonos notify global:INITIALIZED|n_pm2_sonos:start "pm2 -s start sonos2mqtt"
trigger n_pm2_sonos start
</syntaxhighlight>

=== Autostart von sonos2mqtt im System mit pm2 (Alternative) ===
Der obige Code startet das sonos2mqtt nodejs Modul mit pm2 beim Start von FHEM. Sollte das nicht funktionieren oder nicht ins gesamte Konzept passen (weil z.B. mehrere nodejs Module geladen werden) kann der automatische Start direkt im System erfolgen. Zunächst dafür das oben eventuell schon definierte notify löschen!<syntaxhighlight lang="perl">
delete n_pm2_sonos
</syntaxhighlight>Der Start des Modul muss nicht mit erhöhten Rechten geschehen! Im Terminal folgendes eingeben (unter dem angemeldeten Benutzer wird sonos2mqtt später immer gestartet):<syntaxhighlight lang="bash">
pm2 start sonos2mqtt
pm2 startup
</syntaxhighlight>
Der letzte Befehl "redet", d.h. es gibt eine Ausgabe in der Art:
<syntaxhighlight lang="bash">
[PM2] To setup the Startup Script, copy/paste the following command:
sudo env PATH=$PATH:/usr/bin /usr/lib/node_modules/pm2/bin/pm2 startup systemd -u pi --hp /home/pi
</syntaxhighlight>
Man tut einfach genau das, was dasteht: die letzte Zeile kopieren und wieder einfügen und ausführen. Danach muss man die Konfiguration von pm2 noch sichern:
<syntaxhighlight lang="bash">
pm2 save
</syntaxhighlight>

=== Verwendung des Docker Containers ===
Beim Container findet die Konfiguration der Verbindung zum FHEM in den Environment Variablen statt:
<syntaxhighlight lang="perl">
environment:
- SONOS2MQTT_DEVICE=192.168.56.207 # hier muss einer der Sonos Lautsprecher stehen
- SONOS2MQTT_MQTT=mqtt://192.168.56.121:1883 # mqtt2_server FHEM, erweiterter Syntax siehe oben
- SONOS_LISTENER_HOST=192.168.56.121 # Docker host IP
</syntaxhighlight>

=== Sonos2mqtt mit mehr Komfort ===
Im Wiki Artikel [[Sonos2mqtt]] geht es weiter.

== Owntracks GPS Tracking in FHEM ==
Diese Beispiel verwendet eine MQTT Instanz im Internet, die mit einem MQTT2_CLIENT angebunden wird. Da wenig Traffic benötigt wird, genügt z.B. eine kostenfreie Instanz z.B. bei myqtthub (Stand. Dezember 2020)

=== owntracks auf dem Smartphone konfigurieren ===
Menü / Einstellung / Verbindung

Dort sind insgesamt 4 Registerkarten mit Werten zu füllen (Beispiel):
* Modus -> MQTT
* Hostname ->
** Hostnamen: host.cloud.com
** Port: 8883
** ClientID: ID vom Provider
** WebSockets (nicht nutzen)
* Identifikation ->
** Benutzername: user-name
** Passwort: user-password
** GeräteID: mi6 (erscheint in FHEM im Device Namen verwendet)
** TrackerID: hk (nur zweistellig, erscheint als ID in der owntracks Karte)
* Sicherheit -> TLS aktivieren
=== Definition in FHEM ===
Der MQTT2_CLIENT wird so eingerichtet, man braucht eine andere ClientID als auf dem Smartphone! Stimmt alles sollte das Gerät sofort open anzeigen.<syntaxhighlight lang="perl">
MQTT2_CLIENT einrichten, autocreate simpel
define mqtt2Cloud MQTT2_CLIENT host.cloud.com:8883
attr mqtt2Cloud SSL 1
attr mqtt2Cloud autocreate simple
attr mqtt2Cloud clientId fhem1
attr mqtt2Cloud room MQTT2_IO
attr mqtt2Cloud username user-name
set mqtt2Cloud password user-password
</syntaxhighlight>Für die automatische Erzeugung der Trackergeräte in FHEM richtig man zuerst ein Bridge Device ein:<syntaxhighlight lang="perl">
define MQTT2_Cloud_bridge MQTT2_DEVICE
attr MQTT2_Cloud_bridge IODev mqtt2Cloud
attr MQTT2_Cloud_bridge autocreate 1
attr MQTT2_Cloud_bridge room MQTT2_DEVICE
</syntaxhighlight>Dies wird entweder mit dem Template allgemein konfiguriert<syntaxhighlight lang="perl">
set MQTT2_Cloud_bridge attrTemplate MQTT2_CLIENT_general_bridge
</syntaxhighlight>oder manuell nur für owntracks eingerichtet<syntaxhighlight lang="perl">
attr MQTT2_Cloud_bridge bridgeRegexp owntracks/[^/]+/([^/:]+).* "owntracks_$1"
</syntaxhighlight>MQTT2 Geräte für owntracks werden jetzt automatisch mit dem Namen MQTT2_owntracks_<GeräteID> erzeugt. Diese werden einfach mit dem Template owntracks_device fertig konfiguriert. Bei einem IOS Gerät kann man danach noch das Template owntracks_device_IOS als Erweiterung anwenden.

==== Anwesenheitserkennung ====
Die Anwesenheit kann im owntracks Device direkt für die selbst definierten Plätze abgelesen werden: entweder steht im reading place der jeweilige Ort oder away. Um hier noch eine gewisse Einheitlichkeit in der Verwendung zu bekommen kann man ein PRESENCE Device verwenden: <syntaxhighlight lang="perl">
define OT_Mi6 PRESENCE event MQTT2_owntracks_mi6:place:.away MQTT2_owntracks_mi6:place:.<Home>
</syntaxhighlight>Im Move Modus erfolgt die Erkennung sehr schnell und damit einige Sekunden eher als eine BT Erkennung im Haus - der Akkuverbrauch steigt enorm. Im Significant Modus kann es schon mal ein paar Minuten dauern - ein relevanter Akku Verbrauch ist nicht erkennbar.

Alternativ kann man einen MQTT2_SERVER auch direkt verfügbar machen, wenn man sich sicher ist was man da tut! Siehe {{Link2Forum|Topic=99666|Message=1028576|LinkText=diesen Forenbeitrag}}.

Das Bridge Device wird dabei genau so benötigt, nur der IODev ist ein anderer.

== Allgemeine Hinweise ==
=== MQTT2_SERVER und MQTT2_CLIENT für Debugging nutzen ===
Nutzt man das rawEvents-Attribut am MQTT2-IO<ref>z.B. <code>attr MQTT2_FHEM_Server rawEvents .*</code>, der regex-Filter kann wie üblich angepasst werden</ref>, kann man den Datenverkehr des Servers am Event-Monitor mitschneiden. Dies ist insbesondere für unbekannte Geräte nützlich, deren Topic- und Payload-Struktur noch nicht bekannt ist.
Um den kompletten MQTT Datenaustausch mitzuschneiden, kann man mit <code>attr mqtt2_server verbose 5</code> auch alles ins FHEM-Log schreiben lassen.

=== autocreate funktioniert anscheinend nicht? ===
In der Regel wird bei neu eingehenden MQTT-Messages über ''autocreate'' ein neues Device erstellt, wenn Nachrichten von einem bisher unbekannten Gerät kommen. Geschieht dies nicht, sollten folgende Punkte geprüft werden:
# (nur bei MQTT2_SERVER:) Der Client muss eine ClientID angeben, diese darf nicht den defaults von ''mosquito_sub'' entsprechen.
# Ein allgemeines {{Link2CmdRef|Anker=autocreate|Lang=en|Label=autocreate}}-Device (''TYPE=autocreate'') muss vorhanden und aktiv sein.
# ''autocreate'' am IO muss eingeschaltet sein, was für MQTT2_SERVER bedeutet, dass es nicht auf "0" stehen darf (hier ist dann ''simple'' die aktive Voreinstellung), für MQTT2_CLIENT sollte ebenfalls ''simple'' verwendet werden; dies muss hier allerdings explizit gesetzt werden.

Wird dann immer noch kein Device erstellt, gibt es in aller Regel ein Device, das bereits einen entsprechenden Eintrag in der readingList enthält, oder es sind keine Nachrichten eingegangen. Überprüfen Sie daher dann ggf. die Einstellungen am Client-Gerät (z.B. im Web-Interface des Shelly oder Tasmota-geflashten ESP8266).

Das ''autocreate'' am Device schließlich bestimmt, ob die ''readingsList'' erweitert werden darf, wenn Informationen über bisher nicht über die readingList abgedeckte Topics empfangen werden und vom MQTT2-IO als zu diesem Device/ClientID gehörend identifiziert wurden.

=== attrTemplate ===
Zur Konfiguration von MQTT2_DEVICE-Geräten kann die Funktion ''[[AttrTemplate|attrTemplate]]'' genutzt werden.
Die Anwendung für MQTT2_DEVICE ist [[MQTT2 DEVICE#attrTemplate|hier]] beschrieben.

{{Hinweis|In einigen Fällen kann es vorkommen, dass die template-Bezeichnung zwischenzeitlich geändert wurde. Seit 21.09.2019 erfolgt die Sortierung der auswählbaren templates nicht mehr nur nach den Namen, so dass die entsprechenden Namensbestandteile entfallen sind, die einer besseren Sortierung dienten.}}

=== attrTemplate: Es werden nicht alle templates angezeigt ===
Siehe Beitrag [[AttrTemplate#Warum finde ich das Template xyz nicht.3F|AttrTemplate: Warum finde ich das Template xyz nicht.]]

=== attrTemplate und Sprachsteuerung ===
Konfiguriert man MQTT2_DEVICE-Geräte mit attrTemplate, werden in der Regel auch direkt die für die Sprachsteuerung der Geräte erforderlichen Attribute mit gesetzt. Weiterführende Hinweise sind auch zu diesem Teilaspekt von ''[[AttrTemplate|attrTemplate]]'' dem betreffenden Hauptartikel zu entnehmen.

=== bridgeRegexp ===
[[Datei:Mqtt2 server.png|300px|thumb|left|Logische Verortung der bridgeRegexp-Angaben]]{{Randnotiz|RNTyp=y|RNText=Beachten Sie, dass aufgrund des geschilderten Prinzips eine Änderung einer bridgeRegexp bei einem Gerät auch dazu führt, dass alle Readings eines Geräts und alle readingList-Einträge gelöscht werden.}}Üblicherweise werden alle Informationen, die aus einer Quelle stammen auch '''''einem''''' ''MQTT2_DEVICE'' zugeordnet, wobei im Falle des dort nicht aktivierten autocreate-Attributs entsprechende readingList-Einträge erzeugt werden. In dem nebenstehenden Schaubild wären dies die Geräte ''A'' bis ''D''. Das '''Attribut''' ''bridgeRegexp'' kann dazu genutzt werden, um neue, bisher unbekannte Topic-Strukturen im Rahmen des autocreate-Vorgangs anders zu strukturieren. Diese werden dabei im Ergebnis einem '''anderen Device''' (das ggf. erst erstellt wird) zugeschlagen, sollte eine zu der topic-Struktur passende regex in diesem Attribut gesetzt sein. Für dessen CID und die Bildung des Names wird die im 2. Teil jedes Eintrags als ''newClientId'' hinterlegte Angabe verwendet. In nebenstehendem Schaubild ist dies exemplarisch für die Gerätegruppe ''D'' mit dem ''bridge''-Device ''D'' und dessen ''Satelliten'' ''D1'' bis ''D4'' dargestellt.
Dementsprechend sind in den hier aufgeführten Beispielen ''bridgeRegexp''-Attribute immer dort zu finden, wo ein Gerät oder Dienst dazu dient, mit weiteren, ggf. auf andere Weise kommunizierende Geräte oder Baugruppen zu kommunizieren, wie z.B. für über hier dargestellten ''zigbee2mqtt'' oder ''zigbee2tasmota''. Ein Sonderfall hierbei ist das template ''MQTT2_CLIENT_general_bridge'' zur Verwendung mit dem [[MQTT2_CLIENT#Anwendung|MQTT2_CLIENT]], denn aus dessen Sicht stammen alle Informationen aus derselben Quelle, nämlich z.B. dem ''mosquitto''-Server und würden sonst alle einem einem MQTT2_DEVICE zugewiesen.

=== Ständig neue Devices? ===
MQTT2_SERVER kann zwischen verschiedenen Geräten auch anhand der ClientID unterscheiden. Für jedes neu erkannte Gerät wird auch ein eigenes MQTT2_DEVICE angelegt. Abhilfemaßnahmen:
==== Vergabe einer ClientID ====
Die meisten MQTT-fähigen Geräte enthalten Optionen zur Vergabe einer eindeutigen ClientID (siehe das Beispiel des zigbee2mqtt-Dienstes oben).
Wird keine ClientID vergeben, verwenden manche Clients für jede Verbindung wieder neue ID's. Es wird empfohlen, möglichst von diesen Einstelloptionen Gebrauch zu machen.

==== Löschen der ClientID aus der readingList usw. ====
Ist dies nicht möglich oder erwünscht, kann man auch die ClientID aus den readingList-, setList- und getList-Attributen entfernen. Dies ist jedenfalls solange unschädlich als nicht mehrere Geräte identische Topic-Pfade verwenden (daher die Empfehlung, insbesondere bei Tasmota-Geräten den ''default'' "sonoff" zu ändern).
Beispielsweise wäre <code>attr Milight_Bridge readingList milight_hub_1370325:milight/LWT:.* {json2nameValue($EVENT) }</code> zu ändern in <code>attr Milight_Bridge readingList milight/LWT:.* {json2nameValue($EVENT) }</code>
Die über ''attrTemplate'' verfügbaren Konfigurationen verwenden in der Regel keine ClientID's bzw. entfernen diese.

=== Wildcards in readingList und setList ===
Auch in readingList und in setList sollten sich sog. wildcards verwenden lassen. Die Vorgehensweise ist jedoch unterschiedlich:

In ''readingList'' werden normale regex-Ausdrücke verwendet. Ein Punkt steht daher z.B. für ein beliebiges Zeichen, alles zwischen zwei Topic-Tree-Elementen (getrennt typischerweise durch einen "/") kann man so schreiben: "[^/]+" (entspricht: "Mindestens ein Zeichen, das kein Schrägstrich ist"). Ergänzender Hinweis: Will man z.B. Informationen aus einem beliebigen Teil des Topic-trees extrahieren und als Reading-Namen verwenden, kann dies im Rahmen eines Perl-Aufrufs geschehen. Beispiele aus der mqtt2.template-file: OpenMQTTGateway_BT_scanner und OpenMQTTGateway_BT_gtag (letzteres überführt die Information, über welches Gateway bestimmte Informationen eingegangen ist jeweils in eigene Readings pro Gateway).

In ''setList'' gelten dagegen die wildcard-Konventionen aus der MQTT-Welt. Dort steht "+" für einen austauschbaren Teil des Topic-Trees (zwischen zwei Schrägstrichen). Anmerkung: Bitte vorher prüfen, ob es wirklich sinnvoll ist, derart unspezifische Publishes vorzunehmen. Meist gibt es "Gruppen-Topics", auf die mehrere Geräte eines bestimmten Typs hören bzw. man kann dies dort (in der firmware bzw. auf den Konfigurationsseiten der Geräte) einstellen.

=== Die JSON-Daten sollen ausnahmsweise nicht ausgepackt werden ===
In manchen Fällen ist das automatische Auspacken der JSON-Payload nicht erwünscht. In diesen Fällen kann man einfach den gewünschten Reading-Namen in die readingList eintragen, statt der Anweisung, den JSON an json2NameValue() zu übergeben. Aus
<pre>
attr MQTT_OwnTracks readingList owntracks/clouduser/mi6:.* { json2nameValue($EVENT) }\
owntracks/clouduser/mi6/waypoints:.* { json2nameValue($EVENT) }\
owntracks/clouduser/mi6/event:.* { json2nameValue($EVENT) }
</pre>
wird dann:
<pre>
attr MQTT_OwnTracks readingList owntracks/clouduser/mi6:.* json_mi6\
owntracks/clouduser/mi6/waypoints:.* json_waypoints\
owntracks/clouduser/mi6/event:.* json_event
</pre>
Erforderlichenfalls kann man die Einträge auch doppelt erstellen, um sowohl den JSON wie auch die ausgepackten Readings zu erhalten.

=== Die JSON-Daten vor dem auspacken manipulieren ===
Aus diversen Gründen kann es zweckmäßig sein, einen bestimmten Wert der JSON-Payload zu ignorieren.
Z.B. sendet ein Client statt eines Messwertes die Info "bad". Dieser Fehlerwert soll aus der JSON-Payload "ausgefiltert" werden:
<pre>
attr DEVICE readingList <your topic>:.* { my $rets = json2nameValue($EVENT,'',$JSONMAP);; my %cleaned = map { $_,$rets->{$_} } grep { 'bad' ne $rets->{$_} } keys %{$rets};; return \%cleaned }
</pre>

Oder auch einen Wert umzubenennen wenn die JSON-Payload nur ein Objekt beinhaltet:
<pre>
attr DEVICE readingList <your topic>:.* {my %h=(0=>'SofortLaden',1=>'MinPV',2=>'NurPV',3=>'Stop',4=>'Standby');; return {ChargeMode=>$h{$EVENT}}}
</pre>

=== Unnötige Konfigurationsinformationen verwerfen ===
Siehe Einleitung und den [[MQTT2_CLIENT#ignoreRegexp|ignoreRegexp-Abschnitt zu MQTT2_CLIENT]].

=== Weiterführende Themen ===
==== Verbinden mehrerer FHEM-Instanzen über MQTT ====
Wie im Hauptartikel zu [[MQTT#Kommunikation zu sonstigen FHEM-Geräten über MQTT|MQTT]] erläutert, gibt es mehrere Varianten, wie man mit Hilfe von FHEM aus Events an beliebigen Geräten MQTT-Messages erzeugen kann. So kann man z.B. Messdaten eines Systems über ein ''notify'' iVm. einer einfachen ''publish''-Anweisung an ein zweites FHEM schicken, das diese Daten dann z.B. mit Hilfe der MQTT2-Module auswerten kann.
Damit dabei Nachrichten unterschiedlicher Quellen auch als getrennte Readings bzw. ggf. auch gesonderten MQTT2_DEVICE-Instanzen zugeordnet werden, sollte man entsprechende Topic-Strukturen wählen, die dann auch mit Hilfe einer geeigneten ''bridgeRegexp'' automatisiert ausgewertet werden kann, siehe z.B. dieser {{Link2Forum|Topic=107145|LinkText=Forumsthread}}:
attr MQTT2_myMqttServer bridgeRegexp \
SmartHome/MqttGenericBridge2/([A-Za-z0-9]*)/.*:.* "mgb2_$1"
Dabei werden die betreffenden Informationen der entfernten FHEM-Instanz alle nach dem Schema ''SmartHome/MqttGenericBridge2/<Device-Name>/<Reading-Name>'' versendet.

==== Umstellung von MQTT_DEVICE (und Derivaten wie XiaomiMQTTDevice) zu MQTT2_DEVICE ====
Wer beabsichtigt, von der Implementierung MQTT+MQTT_DEVICE zu MQTT2-IO und MQTT2_DEVICE zu wechseln, sollte einige Punkte beachten. Viele diesbezügliche Fragen sind vor allem in {{Link2Forum|Topic=103762|LinkText=diesem Foren-Thread}}

näher erläutert.

== Links ==
* {{Link2Forum|Topic=91394|LinkText=Thread, aus dem diese Anleitung ursprünglich entstanden ist}}
* {{Link2Forum|Topic=91807|LinkText=Thread zum Tasmota-Device}}
* {{Link2Forum|Topic=97989|LinkText=Thread, aus dem diese Anleitung für den eBus ursprünglich entstanden ist}}
* {{Link2Forum|Topic=94495|LinkText=Neue templates einreichen}}
* {{Link2Forum|Topic=94494|LinkText=Fragen, Wünsche und Kritik zu mqtt2.template}}

== Hinweise ==
<references />
[[Kategorie:HOWTOS]]
[[Kategorie:MQTT]]
[[Kategorie:IP Components|IP Komponenten]]
[[Kategorie:Other Components]]
[[Kategorie:Interfaces]]

UserReadings

2021-01-20T20:24:02Z

TomLee:

{{SEITENTITEL:userReadings}} 
Über das Attribut [[userReadings]] können bei einem Device benutzerdefinierte Readings einschließlich der Anweisungen zum Befüllen derselben festgelegt werden. Das können zum Einen Formatänderungen ("sprintf"), oder aber auch durch die ''Modifier''
* difference
* differential
* integral
* offset
* monotonic
gesteuerte Berechnungen sein.

== Syntax ==
{{Randnotiz|RNTyp=y|RNText='''Geändertes Verhalten - bitte beachten'''
Im April 2016 hat sich die Verarbeitung des ''Triggers'' dahingehend geändert, dass die Trigger-Spezifikation jetzt als [[Regulärer Ausdruck]] interpretiert wird, damit also z.B. ein <code>avgTemp:temperature</code> geändert werden muss in <code>avgTemp:temperature.*</code>.

Technische Details dazu wurden in {{Link2Forum|Topic=52165|LinkText=diesem Forenthread}} diskutiert.}}
Siehe {{Link2CmdRef|Anker=readingFnAttributes}}.

* Bei Eingabe im Editor-Feld müssen mehrere Befehle mit einem ";" getrennt werden, bei Änderung in der Eingabezeile sind zwei ";" notwendig.
* Die Variable, dessen Wert man im Reading haben möchte, kann man einfach ans Ende stellen[https://perldoc.perl.org/functions/return.html]
* mehrere UserReadings werden durch Komma getrennt.

:<code>myreading {my $v = ReadingsVal($name,"actuation","error")+62; fhem("set PID desired $v"); $v},</code>
:<code>myreading2 {my $v = ReadingsVal($name,"actuation","error")+62; fhem("set PID2 desired $v"); $v}</code>

== Beispiele ==
{{Hinweis|Die nachfolgenden Beispiele sind ohne Trigger notiert. In der Regel sollte jedoch geprüft werden, ob nicht ein solcher Trigger gesetzt werden kann. Dies ist insbesondere in den Fällen sinnvoll, in denen in einem Gerät sehr viele Readings vorhanden sind, die ggf. zu unterschiedlichen Zeitpunkten aktualisiert werden. Das erste Beispiel wäre daher besser so zu schreiben:<br><code>attr ElbePegelSchoena userReadings Pegel:value.* { ReadingsVal("ElbePegelSchoena","value",0) }</code> }}

==== Ein Reading soll einen anderen Namen bekommen ====
Das vorhandene Reading "value" des Devices "ElbePegelSchoena" soll künftig in "Pegel" umbenannt werden. Das geht nicht. Man kann aber ein neues Reading "Pegel" mit genau gleichem Wert erzeugen:
:<code>attr ElbePegelSchoena userReadings Pegel { ReadingsVal("ElbePegelSchoena1","value",0) }</code>

==== Ausgabe eines Homematic 3-State Fenstersensor als Zahl für Visualisierung mit Icons ====
:<code>attr HM_XXXXXX userReadings Statenum {if(ReadingsVal("HM_XXXXXX","state","") eq "closed") {return 0} elsif (ReadingsVal("HM_XXXXXX","state","") eq "tilted") {return 1} elsif (ReadingsVal("HM_XXXXXX","state","") eq "open") {return 2} else {return -1}}</code>

==== Ausgabe als Moving Average und formatierung mit sprintf ====
:<code>attr HZ_EINSTRAHLUNG_RAW userReadings Einstr_Mean.av {sprintf("%.1f",movingAverage("HZ_EINSTRAHLUNG_RAW","reading",1200))}</code>

==== Umrechnung der Temperatur (durch 10 geteilt) und Einheit [°C] angehängt ====
:<code>attr HZ_EINSTRAHLUNG_T userReadings SolarTemp {ReadingsVal("HZ_EINSTRAHLUNG_T","reading",0)/10 ." °C"}</code>

==== Batterieüberwachung durch Erweiterung mit notify und userReading ====
... ist im Detail auf der Seite [[Batterieüberwachung]] beschrieben.

==== Integralfunktion - integral ====
Die Verwendung der Integralfunktion bei ''userReadings'' ist ausführlich im Forenbeitrag {{Link2Forum|Topic=26300|Message=193084|LinkText=Integralfunktion bei UserReadings}} erklärt.

== Links ==
* {{Link2CmdRef|Lang=de|Anker=userReadings}} - userReadings

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

Sonos2mqtt

2020-12-18T13:31:20Z

TomLee:

== Grundeinrichtung ==
Die Grundeinrichtung ist bereits im Artikel [[MQTT2-Module - Praxisbeispiele#Sonos2Mqtt|MQTT2-Module - Praxisbeispiele]] beschrieben. Hier soll es um die praktische Verwendung und Erweiterung gehen.

Für alle Erweiterungen wird versucht vorhandene Devices in FHEM zu verwenden.

Viele Dinge werden derzeit noch entwickelt und können frei gestaltet werden - der Vorteil von generischen FHEM Devices.

== Tipps zur Verwendung ==
Die automatische Konfiguration setzt den alias entsprechend dem Namen im Sonos vergeben. Die langen MQTT2_RINCON_ Namen sind unhandlich und schlecht lesbar. Man kann Player mit einem devspec ansprechen, das simpelste ist:

set alias=Büro play

Oder alle Player

set model=sonos2mqtt_speaker leaveGroup

== Ansicht der Player ==
Im Template wird nur ein simples devStateIcon ausgeliefert. Dort kann man sehr viel mehr reinpacken. Hier mal die aktuelle Arbeitsvariante zum nachrüsten in der [[Import von Code Snippets|Raw Definition]]:<syntaxhighlight lang="perl">
attr model=sonos2mqtt_speaker devStateIcon {\
my $wpix = '250px';;\
my $groupname = ReadingsVal($name,'groupName','0');;\
my $sgroupname = (split(' ',ReadingsVal($name,'groupName','')))[0];;\
my $uuidtoname = (devspec2array('DEF='.ReadingsVal($name,'coordinatorUuid','0')))[0];;\
my $vol = ReadingsVal($name,'volume','');;\
my $img = ReadingsVal($name,'currentTrack_AlbumArtUri','');;\
my $mystate = $name eq $uuidtoname \
? ReadingsVal($name,'state','FEHLER') : ReadingsVal($uuidtoname,'state','');;\
my $playpic = $mystate eq 'PLAYING'\
? 'rc_PAUSE@red' : $mystate eq 'PAUSED_PLAYBACK'\
? 'rc_PLAY@green' : $mystate eq 'STOPPED'\
? 'rc_PLAY@green' : $mystate eq 'TRANSITIONING'\
? 'rc_PLAY@blue' : $mystate eq 'set_next'\
? 'rc_NEXT@blue' : $mystate eq 'set_previous'\
? 'rc_PREVIOUS@blue': $mystate eq 'set_volumeUp'\
? 'rc_VOLUP@blue' : $mystate eq 'set_volumeDown'\
? 'rc_VOLDOWN@blue' : $mystate eq 'set_mute'\
? 'rc_MUTE@blue' : 'rc_PLAY@yellow';;\
my $mutecmd = ReadingsVal($name,'mute','0') eq 'false'?'true':'false';;\
my $mutepic = $mutecmd eq 'on'?'rc_MUTE':'rc_VOLUP';;\
my $show = 'FEHLER';;\
my $currentTrack_Artist = ReadingsVal($name,'currentTrack_Artist','FEHLER');;\
my $currentTrack_Title = ReadingsVal($name,'currentTrack_Title','FEHLER');;\
if ($currentTrack_Title =~ 'x-sonosapi-stream:'){$currentTrack_Title=''};;\
my $currentTrack = $mystate eq 'TRANSITIONING'\
? 'Puffern...' : $currentTrack_Artist.' - '.$currentTrack_Title;;\
my $nextTrack_Artist = ReadingsVal($name,'nextTrack_Artist','FEHLER');;\
my $nextTrack_Title = ReadingsVal($name,'nextTrack_Title','FEHLER');;\
my $nextTrack = $nextTrack_Artist.' - '.$nextTrack_Title;;\
my $previouspic = 'rc_PREVIOUS';;\
my $nextpic = 'rc_NEXT';;\
my $voldownpic = 'rc_VOLDOWN';;\
my $voluppic = 'rc_VOLUP';;\
my $leavegrouppic = 'rc_LEFT';;\
my $showlg = ReadingsVal($name,"name","0") ne $groupname ? "<a href=\"/fhem?cmd.dummy=set $name leaveGroup&XHR=1\">".FW_makeImage($leavegrouppic)."</a>" : "";;\
if (($mystate eq 'PLAYING')\
|| ($mystate eq 'TRANSITIONING' )\
|| ($mystate eq 'set_next' )\
|| ($mystate eq 'set_previous' )\
|| ($mystate eq 'set_volumeUp' )\
|| ($mystate eq 'set_volumeDown' )\
|| ($mystate eq 'set_mute' )) { \
my $shownp = ReadingsVal($name,'name','') eq $sgroupname \
? "<a href=\"/fhem?cmd.dummy=set $name previous&XHR=1\">".FW_makeImage($previouspic)."</a>\
<a href=\"/fhem?cmd.dummy=set $name next&XHR=1\">".FW_makeImage($nextpic)."</a>" : "";; \
$show = "$showlg <a href=\"/fhem?cmd.dummy=set $name toggle&XHR=1\">".FW_makeImage($playpic)."</a>\
<a href=\"/fhem?cmd.dummy=set $name volumeDown&XHR=1\">".FW_makeImage($voldownpic)."</a>\
$shownp\
<a href=\"/fhem?cmd.dummy=set $name volumeUp&XHR=1\">".FW_makeImage($voluppic)."</a>\
 ; ; ; ;\
<a href=\"/fhem?cmd.dummy=set $name mute $mutecmd&XHR=1\">".FW_makeImage($mutepic)."</a><br>";;\
\
if (ReadingsVal($name,'name','') eq $sgroupname) {\
$show = ReadingsVal($name,'currentTrack_TrackUri','') =~ 'spdif'\
? 'TV': ReadingsVal($name,'enqueuedMetadata_UpnpClass','FEHLER') ne 'object.item.audioItem.audioBroadcast'\
? "$show<marquee style='width: $wpix'>Aktueller Track: $currentTrack<br>Nächster Track: $nextTrack</marquee>"\
: "$show<marquee style='width: $wpix'>Radio: $currentTrack</marquee>"\
}\
elsif (ReadingsVal($name,'name','') ne $groupname) {\
$show = "$show Master: $sgroupname"}\
}\
else {\
$show = $name eq $uuidtoname\
? "$showlg <a href=\"/fhem?cmd.dummy=set $name toggle&XHR=1\">".FW_makeImage($playpic)."</a>"\
: "$showlg <a href=\"/fhem?cmd.dummy=set $name toggle&XHR=1\">".FW_makeImage($playpic)."</a><br>Master: $sgroupname"\
}\
"<div>\
<table>\
<tr>\
<td><div style='display: inline-block;; margin-right: 5px;; border: 1px solid lightgray;;\
height: 4.00em;; width: 4.00em;; background-image: url($img);; background-size: contain;;'></div></td>\
<td>$show</td>\
</tr>\
</table>\
</div>"\
}
</syntaxhighlight>

== Befehle nachrüsten ==
Um Befehle nicht manuell in die setList / readingList Einträge jedes Players machen zu müssen, wird diese Routine verwendet.

Der Code ist für die Raw Definition gedacht. Die ersten drei Zeilen sind jeweils anzupassen!

Hier im Beispiel wird der setter für den folgenden Speak Befehl eingefügt bzw. ersetzt. <syntaxhighlight lang="perl">
{my @devlist = devspec2array('MQTT2_RINCON_.*');;\
my $attr = 'setList';;\
my $item = q( speak:textField { my $tts="SonosTTS";;my ($cmd,$vol,$text)=split(' ', $EVENT,3);;fhem("set $tts tts $text;;sleep $tts:playing:.0 ;;set $NAME notify $vol [$tts:httpName]")});;\
my ($first,$sec)=split(' ',$item,2);;\
$first=~s/^\s+//;;\
foreach (@devlist) {\
my @arr = grep {$_ !~ $first} split("\n",AttrVal($_,$attr,''));;\
push @arr,$item;;\
my $val = join "\n",@arr;;\
$val =~ s/;;/;;;;/g;;\
fhem("attr $_ $attr $val")}\
return "$attr in ".scalar(@devlist)." Definitionen modifiziert"\
}
</syntaxhighlight>Vorhandenen Zeilen werden ersetzt. Identifiziert wird nur der erste Teil.

=== Speak Befehl ===
Verwendet wird ein Befehl ähnlich wie in der Sonos Umgebung:

set Player speak <volume> text

Zwei zusätzliche Geräte sind notwendig:
* [[Text2Speech]] im Servermodus, erzeugt mp3 Dateien im cache Verzeichnis und legt einen Link im Reading httpName ab.
* Ein HTTP Server stellt die Dateien im gleichen Verzeichnis bereit
Der speak Befehl im Player Device läuft in 3 Schritten:
# mit dem TTS Gerät wird die mp3 Datei erzeugt,
# mit dem sleep wird auf die Fertigstellung gewartet,
# die Datei wird mit set Player notify volume uri abgespielt.
Für die Funktion ist wichtig, dass das Sonos System den Host im Link zur Datei richtig auflösen kann. Deshalb wird der Hostname und Port des Servers im Reading host des TTS Device als Name oder IP Adresse abgelegt! Dies kann entweder mit dem hier gezeigten Befehl oder vollständig manuell erfolgen.<syntaxhighlight lang="perl">
defmod SonosTTS Text2Speech none
attr SonosTTS TTS_UseMP3Wrap 1
attr SonosTTS userReadings httpName:lastFilename.* {'http://'.ReadingsVal($name,'host','set host:port first').'/fhem/'.ReadingsVal($name,'lastFilename','')}
attr SonosTTS TTS_CacheFileDir cache
setreading SonosTTS host {(qx(hostname -s|tr -d '\n').':'.InternalVal('WEB','PORT','8083'))}
#setreading SonosTTS host {((split(' ', qx(hostname -I)))[0].':'.InternalVal('WEB','PORT','8083'))}

defmod SonosSpeakWeb HTTPSRV cache cache SonosSpeakWeb
</syntaxhighlight>Durch den "sonos2mqtt notify" Befehl wird die laufende Umgebung wiederhergestellt.
* Wird der speak Befehl an den Gruppenmaster gesendet wird die mp3 Datei in der gesamten Gruppe gespielt.
* Wird der speak Befehl an ein Mitglied einer Gruppe gesendet (nicht den Master) wird die Gruppe aufgetrennt und später wieder hergestellt.
Die Erweiterung der setList im MQTT2 Player Device sieht wie folgt aus. Man kann den Befehl einfach bei allen Playern mit dem obigen [[Sonos2mqtt#Befehle nachr.C3.BCsten|Codeschnipsel]] nachrüsten.<syntaxhighlight lang="perl">
speak:textField { my $tts="SonosTTS";my ($cmd,$vol,$text)=split(' ', $EVENT,3);fhem("set $tts tts $text;sleep $tts:playing:.0 ;set $NAME notify $vol [$tts:httpName]")}
</syntaxhighlight>Will man keine laufenden Sendung unterbrechen sondern einfach eine Ansage machen und danach etwas starten, kann man so vorgehen:<syntaxhighlight lang="perl">
set SonosTTS tts Hier steht die Ansage;sleep SonosTTS:playing:.0 ; set alias=PlayerAlias playUri [SonosTTS:httpName]
</syntaxhighlight>

==== Spiele feste Sounds ====
Generell kann man feste mp3 Dateien (Klingeltöne, Klänge usw.) auch im cache Verzeichnis ablegen und direkt mit dem Link starten.

Es gibt zahlreiche Soundquellen im Internet, ist der gewünschte Sound dabei kann man ihn innerhalb FHEM herunterladen und an Ort und Stelle platzieren. (Beispiel ohne und mit Umbennung)<syntaxhighlight lang="perl">
"wget -qP ./cache https://cdn.smartersoft-group.com/various/pull-bell-short.mp3"
"wget -qO ./cache/KlingelTon.mp3 https://cdn.smartersoft-group.com/various/pull-bell-short.mp3"
</syntaxhighlight>Vergewissern ob der gewünschte Sound auch da ist: {qx(ls -lha ./cache)}

Mit set magic kann man dabei einfach Teile aus anderen Readings holen.<syntaxhighlight lang="perl">
set alias=Büro notify 25 {('http://[SonosTTS:host]/fhem/cache/KlingelTon.mp3')}
</syntaxhighlight>Man kann auch den setter im Gerät erweitern:<syntaxhighlight lang="perl">
playSound:textField {my $tts="SonosTTS";my ($cmd,$vol,$file)=split(' ', $EVENT,3);$file=($file=~m/.*\.mp3$/)?"$file":"$file.mp3";fhem("set $NAME notify $vol http://[$tts:host]/fhem/[a:$tts:TTS_CacheFileDir]/$file")}
</syntaxhighlight>Damit sind dann diese Syntaxen möglich:<syntaxhighlight lang="perl">
set alias=Büro playSound 40 KlingelTon.mp3
</syntaxhighlight>
<syntaxhighlight lang="perl">
set alias=Büro playSound 40 KlingelTon
</syntaxhighlight>

=== SonosBridge aufrüsten ===
Einige zentrale Dinge sind im SonosBridge Device gut aufgehoben. Seit der Beta 3.1.0-beta.1 ist es möglich die Sonos Umgebung zu aktualisieren ohne sonos2mqtt neu starten zu müssen.

Die setList stattet die Bridge mit der Möglichkeit aus alle Player zu stoppen und die Umgebung neu einzulesen (das ist nützlich wenn man Player on/off betreibt)<syntaxhighlight lang="perl">
PauseAll:noArg sonos/cmd/pauseall
CheckSubscription:noArg sonos/cmd/check-subscriptions
</syntaxhighlight>Die Favoritenliste kann einmal zentral in der SonosBridge abgelegt werden. Dazu müssen wird dort die readingList ergänzen.<syntaxhighlight lang="perl">
sonos/RINCON_([0-9A-Z]+)/Favorites:.* Favorites
</syntaxhighlight>Für eine einfache Abholung der aktuellen Favoriten kann der SonosBridge eine getList spendiert werden, man muss dazu einen Player eintragen (RINCON_).<syntaxhighlight lang="perl">
Favorites:noArg Favorites sonos/RINCON_XXXXXXXXXXXXX/control {"command": "adv-command","input": {"cmd": "GetFavorites","reply": "Favorites"}}
</syntaxhighlight>ToDo: Code straffen und setList mit einbauen.

Wer das nicht per Hand machen will hier zwei Codeblöcke für die Raw Definition:<syntaxhighlight lang="perl">
{my @devlist = devspec2array('model=sonos2mqtt_bridge');;\
my $attr = 'readingList';;\
my $item = q( sonos/RINCON_([0-9A-Z]+)/Favorites:.* Favorites);;\
my ($first,$sec)=split(' ',$item,2);;\
$first=~s/^\s+//;;\
foreach (@devlist) {\
my @arr = grep {$_ !~ $first} split("\n",AttrVal($_,$attr,''));;\
push @arr,$item;;\
my $val = join "\n",@arr;;\
$val =~ s/;;/;;;;/g;;\
fhem("attr $_ $attr $val")}\
return "$attr in ".scalar(@devlist)." Definitionen modifiziert"\
}
</syntaxhighlight>Achtung dieser Code schreibt eine neue getList in die SonosBridge, zum Ergänzen müsste der Code analog der bisherigen Beispiele verändert werden.<syntaxhighlight lang="perl">
{my @devlist2 = devspec2array('MQTT2_RINCON_.*');;\
my @arr2;;\
foreach (@devlist2) {push @arr2,InternalVal($_,'DEF','')};;\
my $item= q(Favorites:noArg Favorites sonos/).$arr2[int(rand(@arr2))].q(/control {"command": "adv-command","input": {"cmd": "GetFavorites","reply": "Favorites"}});;\
fhem("attr model=sonos2mqtt_bridge getList $item")\
}
</syntaxhighlight>

=== Player mit Favoritenliste ausstatten ===
Wenn nicht schon geschehen muss man jetzt die Favoriten zum ersten Mal einlesen: get SonosBridge Favorites

Nachdem die SonosBridge "aufgerüstet" ist kann man allen Playern die Favoritenliste zum Auswählen eintragen. Dieser Code ist etwas umfangreicher und wieder ein "Script" für die Raw Def.<syntaxhighlight lang="perl">
{use JSON;;use HTML::Entities;;use Encode qw(encode decode);;\
my $enc = 'UTF8';;\
my $dev = (devspec2array('model=sonos2mqtt_bridge'))[0];;\
my $read = 'Favorites';;\
my $decoded = decode_json(ReadingsVal($dev,$read,''));;\
my @arr = @{$decoded->{'Result'}};;\
my @out;;\
foreach (@arr) {\
my $dec=encode($enc, decode_entities($_->{'Title'}));;\
$dec =~ s/\s/./g;;\
push @out,$dec}\
my $favliste= join ',', sort @out;;\
\
my @devlist = devspec2array('MQTT2_RINCON_.*');;\
my $attr = 'setList';;\
my $item = ' playFav:'.$favliste.q( {use JSON;;use HTML::Entities;;use Encode qw(encode decode);;my $enc = 'UTF8';;my $uri='';;my $search=(split(' ', $EVENT,2))[1];;$search=~s/[\/()]/./g;;my $dev = (devspec2array('model=sonos2mqtt_bridge'))[0];;my $read='Favorites';;my $decoded = decode_json(ReadingsVal($dev,$read,''));;my @arr=@{$decoded->{'Result'}};;foreach (@arr) {if (encode($enc, decode_entities($_->{'Title'}))=~/$search/i){$uri = $_->{'TrackUri'} }};;fhem("set $NAME playUri $uri") if ($uri ne '')});;\
my ($first,$sec)=split(':',$item,2);;\
$first=~s/^\s+//;;\
foreach (@devlist) {\
my @arr = grep {$_ !~ $first} split("\n",AttrVal($_,$attr,''));;\
push @arr,$item;;\
my $val = join "\n",@arr;;\
$val =~ s/;;/;;;;/g;;\
fhem("attr $_ $attr $val")}\
return "$attr in ".scalar(@devlist)." Definitionen modifiziert"\
}
</syntaxhighlight>Der erste Teil des Codes erzeugt aus den Favoriten ein Komma separierte, sortierte Liste der Titel und ersetzt die Leerzeichen durch Punkte. Damit eignet sich diese Liste für die Auswahlbox. Dies wird als Ergänzung der setList im zweiten Teil des Codes erzeugt und bei allen Playern eingetragen.

Man kann den playFav Befehl auch mit im set Befehl mit einem Teil des Favoriten Namen verwenden. Enthält die Favoritenliste z.B. Radio Leipzig würde der auch mit diesem Befehl angesteuert werden:<syntaxhighlight lang="perl">
set alias=Bad playFav leipzig
</syntaxhighlight>

=== Radioliste durchtasten ===
Will man eine Liste von bestimmten Radiostation mit einem Taster "durchtasten" kann man das wie folgt tun:

Eigene Radio Liste in ein Reading schreiben (Die Namen müssen zumindest in Teilen mit den Favoriten Titeln übereinstimmen)<syntaxhighlight lang="perl">
setreading model=sonos2mqtt_bridge favRadios Deutschlandfunk Kultur,Radio Leipzig,Radio Station 3
</syntaxhighlight>Der Befehl zum weiterschalten. Jedesmal wenn dieser Befehl ausgeführt wird, wird der nächste Favorit gestartet.<syntaxhighlight lang="perl">
set alias=Arbeitszimmer playFav {(my $dev = (devspec2array('model=sonos2mqtt_bridge'))[0];;Each($dev,ReadingsVal($dev,'favRadios','')))}
</syntaxhighlight>

Will man vor dem Radiostart noch die Ansage des Senders haben, geht das zwar auch mit dem speak Befehl, die direkte Ausgabe ohne Restore der Umgebung (sonos2mqtt notify) ist aber effektiver.

Damit das funktioniert müssen wir die Events einschränken: <syntaxhighlight lang="perl">
attr model=sonos2mqtt_speaker event-on-change-reading .*
{my $dev = (devspec2array('model=sonos2mqtt_bridge'))[0];;my $r=Each($dev,ReadingsVal($dev,'favRadios',''));;my $play = (devspec2array('alias=Büro'))[0];;my $tts="SonosTTS";;fhem("set $tts tts Es folgt $r;;sleep $tts:playing:.0;;set $play playUri [$tts:httpName];;sleep $play:play;;sleep $play:PLAYING;;sleep $play:STOPPED;;set $play playFav $r")}
</syntaxhighlight>Kurze Erklärung zum Code
* ermittelt den nächsten Radiosender in der Liste,
* erzeugt die Ansage "Es folgt SenderXY",
* wenn die mp3 Datei fertig erzeugt ist wird sie mit dem Befehl playUri an den Player gesendet,
* es wird eine Eventfolge abgewartet -> play / PLAYING / STOPPED,
* danach wird der Radiosender gestartet.
Der Code ist so einfach und relativ "steif" für die Kommandozeile. Man kann das auch in einen Setter packen:<syntaxhighlight lang="perl">
toggleRadio:noArg {my $dev = (devspec2array('model=sonos2mqtt_bridge'))[0];my $r=Each($dev,ReadingsVal($dev,'favRadios',''));my $tts="SonosTTS";fhem("set $tts tts Es folgt $r;sleep $tts:playing:.0;set $NAME playUri [$tts:httpName];sleep $NAME:play;sleep $NAME:PLAYING;sleep $NAME:STOPPED;set $NAME playFav $r")}
</syntaxhighlight>

== Dokumentationen und weitere Entwicklungen ==
ToDo

Sonos2mqtt

2020-12-18T13:23:46Z

TomLee:

== Grundeinrichtung ==
Die Grundeinrichtung ist bereits im Artikel [[MQTT2-Module - Praxisbeispiele#Sonos2Mqtt|MQTT2-Module - Praxisbeispiele]] beschrieben. Hier soll es um die praktische Verwendung und Erweiterung gehen.

Für alle Erweiterungen wird versucht vorhandene Devices in FHEM zu verwenden.

Viele Dinge werden derzeit noch entwickelt und können frei gestaltet werden - der Vorteil von generischen FHEM Devices.

== Tipps zur Verwendung ==
Die automatische Konfiguration setzt den alias entsprechend dem Namen im Sonos vergeben. Die langen MQTT2_RINCON_ Namen sind unhandlich und schlecht lesbar. Man kann Player mit einem devspec ansprechen, das simpelste ist:

set alias=Büro play

Oder alle Player

set model=sonos2mqtt_speaker leaveGroup

== Ansicht der Player ==
Im Template wird nur ein simples devStateIcon ausgeliefert. Dort kann man sehr viel mehr reinpacken. Hier mal die aktuelle Arbeitsvariante zum nachrüsten in der [[Import von Code Snippets|Raw Definition]]:<syntaxhighlight lang="perl">
attr model=sonos2mqtt_speaker devStateIcon {\
my $wpix = '250px';;\
my $groupname = ReadingsVal($name,'groupName','0');;\
my $sgroupname = (split(' ',ReadingsVal($name,'groupName','')))[0];;\
my $uuidtoname = (devspec2array('DEF='.ReadingsVal($name,'coordinatorUuid','0')))[0];;\
my $vol = ReadingsVal($name,'volume','');;\
my $img = ReadingsVal($name,'currentTrack_AlbumArtUri','');;\
my $mystate = $name eq $uuidtoname \
? ReadingsVal($name,'state','FEHLER') : ReadingsVal($uuidtoname,'state','');;\
my $playpic = $mystate eq 'PLAYING'\
? 'rc_PAUSE@red' : $mystate eq 'PAUSED_PLAYBACK'\
? 'rc_PLAY@green' : $mystate eq 'STOPPED'\
? 'rc_PLAY@green' : $mystate eq 'TRANSITIONING'\
? 'rc_PLAY@blue' : $mystate eq 'set_next'\
? 'rc_NEXT@blue' : $mystate eq 'set_previous'\
? 'rc_PREVIOUS@blue': $mystate eq 'set_volumeUp'\
? 'rc_VOLUP@blue' : $mystate eq 'set_volumeDown'\
? 'rc_VOLDOWN@blue' : $mystate eq 'set_mute'\
? 'rc_MUTE@blue' : 'rc_PLAY@yellow';;\
my $mutecmd = ReadingsVal($name,'mute','0') eq 'false'?'true':'false';;\
my $mutepic = $mutecmd eq 'on'?'rc_MUTE':'rc_VOLUP';;\
my $show = 'FEHLER';;\
my $currentTrack_Artist = ReadingsVal($name,'currentTrack_Artist','FEHLER');;\
my $currentTrack_Title = ReadingsVal($name,'currentTrack_Title','FEHLER');;\
if ($currentTrack_Title =~ 'x-sonosapi-stream:'){$currentTrack_Title=''};;\
my $currentTrack = $mystate eq 'TRANSITIONING'\
? 'Puffern...' : $currentTrack_Artist.' - '.$currentTrack_Title;;\
my $nextTrack_Artist = ReadingsVal($name,'nextTrack_Artist','FEHLER');;\
my $nextTrack_Title = ReadingsVal($name,'nextTrack_Title','FEHLER');;\
my $nextTrack = $nextTrack_Artist.' - '.$nextTrack_Title;;\
my $previouspic = 'rc_PREVIOUS';;\
my $nextpic = 'rc_NEXT';;\
my $voldownpic = 'rc_VOLDOWN';;\
my $voluppic = 'rc_VOLUP';;\
my $leavegrouppic = 'rc_LEFT';;\
my $showlg = ReadingsVal($name,"name","0") ne $groupname ? "<a href=\"/fhem?cmd.dummy=set $name leaveGroup&XHR=1\">".FW_makeImage($leavegrouppic)."</a>" : "";;\
if (($mystate eq 'PLAYING')\
|| ($mystate eq 'TRANSITIONING' )\
|| ($mystate eq 'set_next' )\
|| ($mystate eq 'set_previous' )\
|| ($mystate eq 'set_volumeUp' )\
|| ($mystate eq 'set_volumeDown' )\
|| ($mystate eq 'set_mute' )) { \
my $shownp = ReadingsVal($name,'name','') eq $sgroupname \
? "<a href=\"/fhem?cmd.dummy=set $name previous&XHR=1\">".FW_makeImage($previouspic)."</a>\
<a href=\"/fhem?cmd.dummy=set $name next&XHR=1\">".FW_makeImage($nextpic)."</a>" : "";; \
$show = "$showlg <a href=\"/fhem?cmd.dummy=set $name toggle&XHR=1\">".FW_makeImage($playpic)."</a>\
<a href=\"/fhem?cmd.dummy=set $name volumeDown&XHR=1\">".FW_makeImage($voldownpic)."</a>\
$shownp\
<a href=\"/fhem?cmd.dummy=set $name volumeUp&XHR=1\">".FW_makeImage($voluppic)."</a>\
 ; ; ; ;\
<a href=\"/fhem?cmd.dummy=set $name mute $mutecmd&XHR=1\">".FW_makeImage($mutepic)."</a><br>";;\
\
if (ReadingsVal($name,'name','') eq $sgroupname) {\
$show = ReadingsVal($name,'currentTrack_TrackUri','') =~ 'spdif'\
? 'TV': ReadingsVal($name,'enqueuedMetadata_UpnpClass','FEHLER') ne 'object.item.audioItem.audioBroadcast'\
? "$show<marquee style='width: $wpix'>Aktueller Track: $currentTrack<br>Nächster Track: $nextTrack</marquee>"\
: "$show<marquee style='width: $wpix'>Radio: $currentTrack</marquee>"\
}\
elsif (ReadingsVal($name,'name','') ne $groupname) {\
$show = "$show Master: $sgroupname"}\
}\
else {\
$show = $name eq $uuidtoname\
? "$showlg <a href=\"/fhem?cmd.dummy=set $name toggle&XHR=1\">".FW_makeImage($playpic)."</a>"\
: "$showlg <a href=\"/fhem?cmd.dummy=set $name toggle&XHR=1\">".FW_makeImage($playpic)."</a><br>Master: $sgroupname"\
}\
"<div>\
<table>\
<tr>\
<td><div style='display: inline-block;; margin-right: 5px;; border: 1px solid lightgray;;\
height: 4.00em;; width: 4.00em;; background-image: url($img);; background-size: contain;;'></div></td>\
<td>$show</td>\
</tr>\
</table>\
</div>"\
}
</syntaxhighlight>

== Befehle nachrüsten ==
Um Befehle nicht manuell in die setList / readingList Einträge jedes Players machen zu müssen, wird diese Routine verwendet.

Der Code ist für die Raw Definition gedacht. Die ersten drei Zeilen sind jeweils anzupassen!

Hier im Beispiel wird der setter für den folgenden Speak Befehl eingefügt bzw. ersetzt. <syntaxhighlight lang="perl">
{my @devlist = devspec2array('MQTT2_RINCON_.*');;\
my $attr = 'setList';;\
my $item = q( speak:textField { my $tts="SonosTTS";;my ($cmd,$vol,$text)=split(' ', $EVENT,3);;fhem("set $tts tts $text;;sleep $tts:playing:.0 ;;set $NAME notify $vol [$tts:httpName]")});;\
my ($first,$sec)=split(' ',$item,2);;\
$first=~s/^\s+//;;\
foreach (@devlist) {\
my @arr = grep {$_ !~ $first} split("\n",AttrVal($_,$attr,''));;\
push @arr,$item;;\
my $val = join "\n",@arr;;\
$val =~ s/;;/;;;;/g;;\
fhem("attr $_ $attr $val")}\
return "$attr in ".scalar(@devlist)." Definitionen modifiziert"\
}
</syntaxhighlight>Vorhandenen Zeilen werden ersetzt. Identifiziert wird nur der erste Teil.

=== Speak Befehl ===
Verwendet wird ein Befehl ähnlich wie in der Sonos Umgebung:

set Player speak <volume> text

Zwei zusätzliche Geräte sind notwendig:
* [[Text2Speech]] im Servermodus, erzeugt mp3 Dateien im cache Verzeichnis und legt einen Link im Reading httpName ab.
* Ein HTTP Server stellt die Dateien im gleichen Verzeichnis bereit
Der speak Befehl im Player Device läuft in 3 Schritten:
# mit dem TTS Gerät wird die mp3 Datei erzeugt,
# mit dem sleep wird auf die Fertigstellung gewartet,
# die Datei wird mit set Player notify volume uri abgespielt.
Für die Funktion ist wichtig, dass das Sonos System den Host im Link zur Datei richtig auflösen kann. Deshalb wird der Hostname und Port des Servers im Reading host des TTS Device als Name oder IP Adresse abgelegt! Dies kann entweder mit dem hier gezeigten Befehl oder vollständig manuell erfolgen.<syntaxhighlight lang="perl">
defmod SonosTTS Text2Speech none
attr SonosTTS TTS_UseMP3Wrap 1
attr SonosTTS userReadings httpName:lastFilename.* {'http://'.ReadingsVal($name,'host','set host:port first').'/fhem/'.ReadingsVal($name,'lastFilename','')}
attr SonosTTS TTS_CacheFileDir cache
setreading SonosTTS host {(qx(hostname -s|tr -d '\n').':'.InternalVal('WEB','PORT','8083'))}
#setreading SonosTTS host {((split(' ', qx(hostname -I)))[0].':'.InternalVal('WEB','PORT','8083'))}

defmod SonosSpeakWeb HTTPSRV cache cache SonosSpeakWeb
</syntaxhighlight>Durch den "sonos2mqtt notify" Befehl wird die laufende Umgebung wiederhergestellt.
* Wird der speak Befehl an den Gruppenmaster gesendet wird die mp3 Datei in der gesamten Gruppe gespielt.
* Wird der speak Befehl an ein Mitglied einer Gruppe gesendet (nicht den Master) wird die Gruppe aufgetrennt und später wieder hergestellt.
Die Erweiterung der setList im MQTT2 Player Device sieht wie folgt aus. Man kann den Befehl einfach bei allen Playern mit dem obigen [[Sonos2mqtt#Befehle nachr.C3.BCsten|Codeschnipsel]] nachrüsten.<syntaxhighlight lang="perl">
speak:textField { my $tts="SonosTTS";my ($cmd,$vol,$text)=split(' ', $EVENT,3);fhem("set $tts tts $text;sleep $tts:playing:.0 ;set $NAME notify $vol [$tts:httpName]")}
</syntaxhighlight>Will man keine laufenden Sendung unterbrechen sondern einfach eine Ansage machen und danach etwas starten, kann man so vorgehen:<syntaxhighlight lang="perl">
set SonosTTS tts Hier steht die Ansage;sleep SonosTTS:playing:.0 ; set alias=PlayerAlias playUri [SonosTTS:httpName]
</syntaxhighlight>

==== Spiele feste Sounds ====
Generell kann man feste mp3 Dateien (Klingeltöne, Klänge usw.) auch im cache Verzeichnis ablegen und direkt mit dem Link starten.

Es gibt zahlreiche Soundquellen im Internet, ist der gewünschte Sound dabei kann man ihn innerhalb FHEM herunterladen und an Ort und Stelle platzieren. (Beispiel ohne und mit Umbennung)<syntaxhighlight lang="perl">
"wget -qP ./cache https://cdn.smartersoft-group.com/various/pull-bell-short.mp3"
"wget -qO ./cache/KlingelTon.mp3 https://cdn.smartersoft-group.com/various/pull-bell-short.mp3"
</syntaxhighlight>Vergewissern ob der gewünschte Sound auch da ist: {qx(ls -lha ./cache)}

Mit set magic kann man dabei einfach Teile aus anderen Readings holen.<syntaxhighlight lang="perl">
set alias=Büro notify 25 {('http://[SonosTTS:host]/fhem/cache/KlingelTon.mp3')}
</syntaxhighlight>Man kann auch den setter im Gerät erweitern:<syntaxhighlight lang="perl">
playSound:textField {my $tts="SonosTTS";my ($cmd,$vol,$file)=split(' ', $EVENT,3);$file=($file=~m/.*\.mp3$/)?"$file":"$file.mp3";fhem("set $NAME notify $vol http://[$tts:host]/fhem/[a:$tts:TTS_CacheFileDir]/$file")}
</syntaxhighlight>Damit sind dann diese Syntaxen möglich:<syntaxhighlight lang="perl">
set alias=Büro playSound 40 KlingelTon.mp3
</syntaxhighlight>
<syntaxhighlight lang="perl">
set alias=Büro playSound 40 KlingelTon
</syntaxhighlight>

=== SonosBridge aufrüsten ===
Einige zentrale Dinge sind im SonosBridge Device gut aufgehoben. Seit der Beta 3.1.0-beta.1 ist es möglich die Sonos Umgebung zu aktualisieren ohne sonos2mqtt neu starten zu müssen.

Die setList stattet die Bridge mit der Möglichkeit aus alle Player zu stoppen und die Umgebung neu einzulesen (das ist nützlich wenn man Player on/off betreibt)<syntaxhighlight>
PauseAll:noArg sonos/cmd/pauseall
CheckSubscription:noArg sonos/cmd/check-subscriptions
</syntaxhighlight>Die Favoritenliste kann einmal zentral in der SonosBridge abgelegt werden. Dazu müssen wird dort die readingList ergänzen.<syntaxhighlight lang="perl">
sonos/RINCON_([0-9A-Z]+)/Favorites:.* Favorites
</syntaxhighlight>Für eine einfache Abholung der aktuellen Favoriten kann der SonosBridge eine getList spendiert werden, man muss dazu einen Player eintragen (RINCON_).<syntaxhighlight lang="perl">
Favorites:noArg Favorites sonos/RINCON_XXXXXXXXXXXXX/control {"command": "adv-command","input": {"cmd": "GetFavorites","reply": "Favorites"}}
</syntaxhighlight>ToDo: Code straffen und setList mit einbauen.

Wer das nicht per Hand machen will hier zwei Codeblöcke für die Raw Definition:<syntaxhighlight lang="perl">
{my @devlist = devspec2array('model=sonos2mqtt_bridge');;\
my $attr = 'readingList';;\
my $item = q( sonos/RINCON_([0-9A-Z]+)/Favorites:.* Favorites);;\
my ($first,$sec)=split(' ',$item,2);;\
$first=~s/^\s+//;;\
foreach (@devlist) {\
my @arr = grep {$_ !~ $first} split("\n",AttrVal($_,$attr,''));;\
push @arr,$item;;\
my $val = join "\n",@arr;;\
$val =~ s/;;/;;;;/g;;\
fhem("attr $_ $attr $val")}\
return "$attr in ".scalar(@devlist)." Definitionen modifiziert"\
}
</syntaxhighlight>Achtung dieser Code schreibt eine neue getList in die SonosBridge, zum Ergänzen müsste der Code analog der bisherigen Beispiele verändert werden.<syntaxhighlight lang="perl">
{my @devlist2 = devspec2array('MQTT2_RINCON_.*');;\
my @arr2;;\
foreach (@devlist2) {push @arr2,InternalVal($_,'DEF','')};;\
my $item= q(Favorites:noArg Favorites sonos/).$arr2[int(rand(@arr2))].q(/control {"command": "adv-command","input": {"cmd": "GetFavorites","reply": "Favorites"}});;\
fhem("attr model=sonos2mqtt_bridge getList $item")\
}
</syntaxhighlight>

=== Player mit Favoritenliste ausstatten ===
Wenn nicht schon geschehen muss man jetzt die Favoriten zum ersten Mal einlesen: get SonosBridge Favorites

Nachdem die SonosBridge "aufgerüstet" ist kann man allen Playern die Favoritenliste zum Auswählen eintragen. Dieser Code ist etwas umfangreicher und wieder ein "Script" für die Raw Def.<syntaxhighlight lang="perl">
{use JSON;;use HTML::Entities;;use Encode qw(encode decode);;\
my $enc = 'UTF8';;\
my $dev = (devspec2array('model=sonos2mqtt_bridge'))[0];;\
my $read = 'Favorites';;\
my $decoded = decode_json(ReadingsVal($dev,$read,''));;\
my @arr = @{$decoded->{'Result'}};;\
my @out;;\
foreach (@arr) {\
my $dec=encode($enc, decode_entities($_->{'Title'}));;\
$dec =~ s/\s/./g;;\
push @out,$dec}\
my $favliste= join ',', sort @out;;\
\
my @devlist = devspec2array('MQTT2_RINCON_.*');;\
my $attr = 'setList';;\
my $item = ' playFav:'.$favliste.q( {use JSON;;use HTML::Entities;;use Encode qw(encode decode);;my $enc = 'UTF8';;my $uri='';;my $search=(split(' ', $EVENT,2))[1];;$search=~s/[\/()]/./g;;my $dev = (devspec2array('model=sonos2mqtt_bridge'))[0];;my $read='Favorites';;my $decoded = decode_json(ReadingsVal($dev,$read,''));;my @arr=@{$decoded->{'Result'}};;foreach (@arr) {if (encode($enc, decode_entities($_->{'Title'}))=~/$search/i){$uri = $_->{'TrackUri'} }};;fhem("set $NAME playUri $uri") if ($uri ne '')});;\
my ($first,$sec)=split(':',$item,2);;\
$first=~s/^\s+//;;\
foreach (@devlist) {\
my @arr = grep {$_ !~ $first} split("\n",AttrVal($_,$attr,''));;\
push @arr,$item;;\
my $val = join "\n",@arr;;\
$val =~ s/;;/;;;;/g;;\
fhem("attr $_ $attr $val")}\
return "$attr in ".scalar(@devlist)." Definitionen modifiziert"\
}
</syntaxhighlight>Der erste Teil des Codes erzeugt aus den Favoriten ein Komma separierte, sortierte Liste der Titel und ersetzt die Leerzeichen durch Punkte. Damit eignet sich diese Liste für die Auswahlbox. Dies wird als Ergänzung der setList im zweiten Teil des Codes erzeugt und bei allen Playern eingetragen.

Man kann den playFav Befehl auch mit im set Befehl mit einem Teil des Favoriten Namen verwenden. Enthält die Favoritenliste z.B. Radio Leipzig würde der auch mit diesem Befehl angesteuert werden:<syntaxhighlight lang="perl">
set alias=Bad playFav leipzig
</syntaxhighlight>

=== Radioliste durchtasten ===
Will man eine Liste von bestimmten Radiostation mit einem Taster "durchtasten" kann man das wie folgt tun:

Eigene Radio Liste in ein Reading schreiben (Die Namen müssen zumindest in Teilen mit den Favoriten Titeln übereinstimmen)<syntaxhighlight lang="perl">
setreading model=sonos2mqtt_bridge favRadios Deutschlandfunk Kultur,Radio Leipzig,Radio Station 3
</syntaxhighlight>Der Befehl zum weiterschalten. Jedesmal wenn dieser Befehl ausgeführt wird, wird der nächste Favorit gestartet.<syntaxhighlight lang="perl">
set alias=Arbeitszimmer playFav {(my $dev = (devspec2array('model=sonos2mqtt_bridge'))[0];;Each($dev,ReadingsVal($dev,'favRadios','')))}
</syntaxhighlight>

Will man vor dem Radiostart noch die Ansage des Senders haben, geht das zwar auch mit dem speak Befehl, die direkte Ausgabe ohne Restore der Umgebung (sonos2mqtt notify) ist aber effektiver.

Damit das funktioniert müssen wir die Events einschränken: <syntaxhighlight lang="perl">
attr model=sonos2mqtt_speaker event-on-change-reading .*
{my $dev = (devspec2array('model=sonos2mqtt_bridge'))[0];;my $r=Each($dev,ReadingsVal($dev,'favRadios',''));;my $play = (devspec2array('alias=Büro'))[0];;my $tts="SonosTTS";;fhem("set $tts tts Es folgt $r;;sleep $tts:playing:.0;;set $play playUri [$tts:httpName];;sleep $play:play;;sleep $play:PLAYING;;sleep $play:STOPPED;;set $play playFav $r")}
</syntaxhighlight>Kurze Erklärung zum Code
* ermittelt den nächsten Radiosender in der Liste,
* erzeugt die Ansage "Es folgt SenderXY",
* wenn die mp3 Datei fertig erzeugt ist wird sie mit dem Befehl playUri an den Player gesendet,
* es wird eine Eventfolge abgewartet -> play / PLAYING / STOPPED,
* danach wird der Radiosender gestartet.
Der Code ist so einfach und relativ "steif" für die Kommandozeile. Man kann das auch in einen Setter packen:<syntaxhighlight lang="perl">
toggleRadio:noArg {my $dev = (devspec2array('model=sonos2mqtt_bridge'))[0];my $r=Each($dev,ReadingsVal($dev,'favRadios',''));my $tts="SonosTTS";fhem("set $tts tts Es folgt $r;sleep $tts:playing:.0;set $NAME playUri [$tts:httpName];sleep $NAME:play;sleep $NAME:PLAYING;sleep $NAME:STOPPED;set $NAME playFav $r")}
</syntaxhighlight>

== Dokumentationen und weitere Entwicklungen ==
ToDo

Mi vacuum

2020-11-16T16:47:26Z

TomLee: /* Vorarbeiten (Linux) */

{{Todo|Aktualiserung / Einbindung Info-Box}}
=Mi Vacuum=
Wie der preiswerte Staubsaugerroboter auch auf FHEM hört...

==Für wen ist die Anleitung gedacht?==
Ich gehe davon aus, dass ihr ein funktionierendes FHEM auf einem Linux Rechner (Debian) betreibt.

Weiterhin denke ich, dass euer Hauptarbeitsrechner unter Windows läuft.

Als Smartphone OS Android (wer Apple hat, kann gerne die Token-Auslese-Geschichte hier beschreiben).

Um das Teil auch von Alexa aus ein und aus zu schalten, sollte auch die Installation von Alexa in FHEM fertig sein.

==Die Einrichtung des Moduls==
===Vorarbeiten (Linux)===
Zunächst fangen wir mal auf unserem FHEM Rechner an. Mit Putty verbinden wir uns per SSH mit dem FHEM Computer.

Folgende Befehle können benötigt werden (Debian):
* <code>sudo apt-get install libjson-perl</code>
* <code>sudo apt-get install libdigest-md5-perl</code>
* <code>sudo apt-get install libcrypt-cbc-perl</code>
* <code>sudo apt install libcryptx-perl</code>

* <code>sudo apt-get install libcrypt-ecb-perl</code> (nur nötig, wenn ihr einen verschlüsselten Token mit 96 Zeichen habt)
* <code>sudo cpan Crypt::Rijndael_PP</code> (nur nötig, wenn libcryptx-perl aus irgendwelchen Gründen nicht funktioniert)
* <code>sudo cpan Crypt::Cipher::AES</code> (nur nötig, wenn Crypt::Rijndael_PP aus irgendwelchen Gründen nicht funktioniert)

Wenn bei dem ein oder anderen Modul die Meldung kommt, dass es schon installiert ist, einfach mit dem nächsten Befehl weiter machen. Das CPAN Teil würde ich am Schluss machen, das braucht ziemlich lang zum installieren.

===Vorarbeiten am Smartphone (Token)===
Das Problem ist folgendes:

Wenn der Roboter mit dem WLAN verbunden wird, generiert er einen Token. Das ist ein Schlüssel, ohne den er sich nicht steuern lässt. Damit FHEM drauf zugreifen kann, benötigt man diesen Token.

Mit den neueren Versionen der MiHome App klappt das Auslesen der Tokens leider nicht mehr.

====Auslesen bei Android Endgeräten====

Ich gehe davon aus, dass der Staubsauger mit der original MiHome App eingebunden ist und funktioniert. (Ich habe bei der Einrichtung des Servers => "other" gewählt. Offenbar wollen neuere Staubsauger sich mit "China Mainland" nicht mehr verbinden. Tut hier an dieser Stelle zwar nichts zur Sache, aber vielleicht hilft es dem ein oder anderen. Wenn man die Region gewechselt hat, muss man auch den Staubsauger neu einbinden)

* MiHome löschen
* alte MiHome suchen (APKMirror z.B., Version 5.0.19 hat bei mir funktioniert, unsichere Quellen müssen erlaubt sein)
* runtergeladene MiHome App öffnen und anmelden (sollte ganz normal den Sauger finden)
* USB-Debugging am Handy einschalten (Entwickleroptionen...)
* Handy mit USB Kabel und PC verbinden
* [https://github.com/ultrara1n/MiToolkit/releases MiToolkit] 1.6 runterladen und öffnen
* [https://github.com/ultrara1n/MiToolkit/releases MiToolkit] erzeugt nun am Handy ein Backup
* anschließend zeigt es den Token direkt am PC an

====Auslesen bei iOS Endgeräten====

Zum Auslesen des Tokens mit iOS Endgeräten kann die Anleitung unter folgendem Link befolgt werden: [https://forum.smartapfel.de/forum/thread/370-xiaomi-token-auslesen/]

===Installation des inoffiziellen Moduls===
Das Modul ist seit 28.02.2018 ein offizielles Modul. Eine separates Installation ist nicht (mehr) notwendig.

==Einrichten des Moduls==
<pre>
define Mi_Vacuum XiaomiDevice 192.168.222.77 55387753545937326a33396943557999

attr Mi_Vacuum subType VacuumCleaner
</pre>

Und schon (=etwa nach 10 Sekunden) sollte euer Roboter in FHEM mit ganz vielen Readings auftauchen.

==Anwendung: Sprachsteuerung mit Alexa (einfach, ein und aus)==
Wie bindet man das jetzt schnell in Alexa ein?

Wir legen uns in FHEM einen Dummy an. Dieser wird ein Switch (on off). Dazu noch ein DOIF oder ein notify, welches diesen Switch überwacht. Je nach Status des Dummys schalten wir den Roboter.

Ein List meines Dummys:
<pre>
Internals:
CFGFN
NAME Mi_Vacuum_Staubsauger
NR 719473
STATE on
TYPE dummy
Readings:
2017-09-18 21:10:12 state on
Attributes:
alexaName Mi_Vacuum_Staubsauger
genericDeviceType switch
room alexa
setList on off
</pre>

Mein DOIF:

<pre>
define di_Mi_Vacuum DOIF ([Mi_Vacuum_Staubsauger:"on"]) (set Mi_Vacuum start) DOELSE (set Mi_Vacuum charge)
</pre>

Das Attribut do always nicht vergessen!

Den Dummy setzen wir in den Raum, der unsere Alexa Geräte beinhaltet. Nun den Alexa FHEM Service neu starten. Anschließend sollte eine Suche nach neuen Geräten in Alexa unseren Dummy finden. Für diesen legen wir in Alexa einen neuen Raum an, z.B. Staubsauger.

Fertig.

Ein "Alexa schaltet den Staubsauger ein" lässt unseren Mi-Vacuum loslegen. "Alexa schalte den Staubsauger aus" schickt ihn wieder zurück zu seiner Station.

==Zonenreinigung==
Um nur Teilbereiche einer Wohnung zu reinigen, ist es möglich über das Modul Zonen zu definieren. Hierzu ist es notwendig, die Koordinaten der gewünschten Zone zu ermitteln. Hierzu eignet sich die [https://xiaomi.flole.de/ FloleVac App] die entweder auf einem Android Device oder auf einem Android Emulator (z.B. [https://www.bluestacks.com/download.html BlueStacks]) verwendet werden kann. In der App kann man in der Karte eine Zone für die Reinigung markieren und durch langes Gedrückthalten des "Reinigen-Buttons" in der FloleVac App die Koordinaten dieser Zone in die Zwischenablage kopieren.

Mit diesen Koordindaten im Format [16200,27250,31650,27650,1] kann man dann loslegen die Zonen in FHEM zu definieren:

Entweder direkt über die Werte:

<pre>
set vacuum zone 16200,27250,31650,27650,1 23700,23050,25200,24200,2
</pre>

Oder über die passenden Attribute erst ein Alias anlegen:

<pre>
attr vacuum zone_names home:[16200,27250,31650,27650,1],[23700,23050,25200,24200,2] livingroom:[16200,26250,23000,30150,1]
</pre>

Ein Alias kann dann wie folgt genutzt werden:

<pre>
set vacuum zone home
</pre>

==Quellen==
* {{Link2Forum|Topic=73052|LinkText=Forums-Thread}}
* {{Link2Forum|Topic=76940|LinkText=Diskussionsthread}}
* [http://miniweb.sourceforge.net/ MiniWeb], kleiner WebServer für Windows
* [https://xiaomi.flole.de/ Flole], alternative App für Android, die das Token nach GoogleDrive exportiert
* [http://www.roboter-forum.com/forumdisplay.php?130-Xiaomi Roboter-Forum] deutschsprachiges Forum, welches sich mit dem Mi Vacuum beschäftigt (auch vor dem Kauf des Roboters lohnt sich ein Besuch dort)
* [https://paypal.me/mm0 PayPal]-Link, um Markus M. Dankeschön zu sagen

UserReadings

2020-08-26T20:12:37Z

TomLee:

{{SEITENTITEL:userReadings}} 
Über das Attribut [[userReadings]] können bei einem Device benutzerdefinierte Readings einschließlich der Anweisungen zum Befüllen derselben festgelegt werden. Das können zum Einen Formatänderungen ("sprintf"), oder aber auch durch die ''Modifier''
* difference
* differential
* integral
* offset
* monotonic
gesteuerte Berechnungen sein.

== Syntax ==
{{Randnotiz|RNTyp=y|RNText='''Geändertes Verhalten - bitte beachten'''
Im April 2016 hat sich die Verarbeitung des ''Triggers'' dahingehend geändert, dass die Trigger-Spezifikation jetzt als [[Regulärer Ausdruck]] interpretiert wird, damit also z.B. ein <code>avgTemp:temperature</code> geändert werden muss in <code>avgTemp:temperature.*</code>.

Technische Details dazu wurden in {{Link2Forum|Topic=52165|LinkText=diesem Forenthread}} diskutiert.}}
Siehe {{Link2CmdRef|Anker=readingFnAttributes}}.

* Bei Eingabe im Editor-Feld müssen mehrere Befehle mit einem ";" getrennt werden, bei Änderung in der Eingabezeile sind zwei ";" notwendig.
* Die Variable, dessen Wert man im Reading haben möchte, kann man einfach ans Ende stellen[https://perldoc.perl.org/functions/return.html]
* mehrere UserReadings werden durch Komma getrennt.

:<code>myreading {my $v = ReadingsVal($name,"actuation","error")+62; fhem("set PID desired $v"); $v},</code>
:<code>myreading2 {my $v = ReadingsVal($name,"actuation","error")+62; fhem("set PID2 desired $v"); $v}</code>

* die mehrzeilige Definition mehrerer UserReadings setzt ein Leerzeichen nach dem Komma voraus
myreading {my $v = ReadingsVal($name,"actuation","error")+62;
fhem("set PID desired $v");
$v;},<span style="background:grey"> </span>
myreading2 {my $v = ReadingsVal($name,"actuation","error")+62;
fhem("set PID2 desired $v");
$v;}
== Beispiele ==
{{Hinweis|Die nachfolgenden Beispiele sind ohne Trigger notiert. In der Regel sollte jedoch geprüft werden, ob nicht ein solcher Trigger gesetzt werden kann. Dies ist insbesondere in den Fällen sinnvoll, in denen in einem Gerät sehr viele Readings vorhanden sind, die ggf. zu unterschiedlichen Zeitpunkten aktualisiert werden. Das erste Beispiel wäre daher besser so zu schreiben:<br><code>attr ElbePegelSchoena userReadings Pegel:value.* { ReadingsVal("ElbePegelSchoena","value",0) }</code> }}

==== Ein Reading soll einen anderen Namen bekommen ====
Das vorhandene Reading "value" des Devices "ElbePegelSchoena" soll künftig in "Pegel" umbenannt werden. Das geht nicht. Man kann aber ein neues Reading "Pegel" mit genau gleichem Wert erzeugen:
:<code>attr ElbePegelSchoena userReadings Pegel { ReadingsVal("ElbePegelSchoena1","value",0) }</code>

==== Ausgabe eines Homematic 3-State Fenstersensor als Zahl für Visualisierung mit Icons ====
:<code>attr HM_XXXXXX userReadings Statenum {if(ReadingsVal("HM_XXXXXX","state","") eq "closed") {return 0} elsif (ReadingsVal("HM_XXXXXX","state","") eq "tilted") {return 1} elsif (ReadingsVal("HM_XXXXXX","state","") eq "open") {return 2} else {return -1}}</code>

==== Ausgabe als Moving Average und formatierung mit sprintf ====
:<code>attr HZ_EINSTRAHLUNG_RAW userReadings Einstr_Mean.av {sprintf("%.1f",movingAverage("HZ_EINSTRAHLUNG_RAW","reading",1200))}</code>

==== Umrechnung der Temperatur (durch 10 geteilt) und Einheit [°C] angehängt ====
:<code>attr HZ_EINSTRAHLUNG_T userReadings SolarTemp {ReadingsVal("HZ_EINSTRAHLUNG_T","reading",0)/10 ." °C"}</code>

==== Batterieüberwachung durch Erweiterung mit notify und userReading ====
... ist im Detail auf der Seite [[Batterieüberwachung]] beschrieben.

==== Integralfunktion - integral ====
Die Verwendung der Integralfunktion bei ''userReadings'' ist ausführlich im Forenbeitrag {{Link2Forum|Topic=26300|Message=193084|LinkText=Integralfunktion bei UserReadings}} erklärt.

== Links ==
* {{Link2CmdRef|Lang=de|Anker=userReadings}} - userReadings

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

MQTT2-Module - Praxisbeispiele

2020-06-02T13:05:39Z

TomLee: /* Verbinden mehrerer FHEM-Instanzen über MQTT */

MQTT2-Module - Praxisbeispiele

2020-06-02T13:04:13Z

TomLee: /* Wildcards in readingList und setList */

MQTT2-Module - Praxisbeispiele

2020-06-02T13:02:16Z

TomLee: /* Wildcards in readingList und setList */Tippfehler korrigiert

FHEM Connector für Amazon Alexa

2020-06-01T18:55:47Z

TomLee: /* Weitergehende Informationen */Test, sry

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

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

* SONOS Beam und SONOS One

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

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

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

==Einführung==

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

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

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

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

==Installation==

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

===node.js installieren===

Ab Jessy liegt NodeJS bereits in einer ausreichend aktuellen Version vor (Stretch und Buster funktionieren ebenfalls). Mit

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

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

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

=== Alexa-FHEM installieren ===

Nun installieren wir Alexa-fhem aus dem offiziellen Repository:

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

Der Vorgang benötigt etwas Zeit.

=== Alexa-FHEM aktivieren ===

Wechsele jetzt in FHEM-Web!

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

* Zuerst bitte einfach einmal die Seite neu laden.

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

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

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

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

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

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

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

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

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

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

Du solltest dann folgende Ausgabe erhalten:

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

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

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

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

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

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

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

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

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

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

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

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

Wähle die Geräte aus, rufe sie auf und setze das Attribut "alexaName". Hierbei in Kürze nur der Hinweis:
* Keine Angst vor Leerzeichen und Umlauten, funktioniert.
* Große Angst vor Rechtschreibfehlern (Terrasse, Rollladen) oder komplizierten Wörtern "handgebastelte Martinslaterne im Kinderzimmer Iphigenie-Chantal".
* Mehrere Namen für dasselbe Gerät/Device in fhem werden unterstützt. Mehrere Namen werden durch Strichpunkt getrennt<ref>Feature nicht dokumentiert {{Link2Forum|Topic=74041|LinkText=Forumsthread}}</ref>.
* Das Attribut "alexaRoom" ist NUR FÜR DEN CUSTOM SKILL relevant. Ausnahme: structure und LightScene Devices, siehe: [[FHEM_Connector_f%C3%BCr_Amazon_Alexa#Was_geht_alles_.3F]].

Lade die Geräte neu in die Software, indem Du <code>set <alexa> restart</code> ausführst!
[[Datei:HowToSet alexaName.png|alternativtext=How to set alexaName|ohne|mini|Wie setzt man das Attribut alexaName]]

'''Anmerkungen (weil oft gestellte Fragen im Forum) bzgl. Erkennung von Geräten:'''

* Wichtig ist, dass die Filtereinstellung in der alexa-fhem.cfg (zu finden unter "Edit Files") passt.
Das, was dort eingetragen ist (Standard: alexaName=..* / also es ist ein alexaName vergeben) auch an den entsprechenden Devices in fhem vorhanden ist.
Stimmt das nicht überein, kann alexa-fhem keine Devices von fhem abfragen/finden.
Ob der Filter entsprechend funktioniert kann man wie folgt testen: ''list Filtereinstellung'' beispiel mit Standardfilter: ''list alexaName=..*''

* Hat alexa-fhem per Filter Devices aus fhem "gefunden", geht es weiter mit der "Erkennung". Also um welches Device (Typ und "Fähigkeiten") handelt es sich. Dazu gilt folgendes:
** sind entsprechende Readings beim Device vorhanden (z.B. temperature, state mit on/off, ...) erkennt das alexa-fhem automatisch. Die Liste der automatisch erkannten Readings wächst ständig. Daher erst mal schauen ob das Device bereits entsprechend erkannt (typisiert) wurde. Das kann durch prüfen des alexa-fhem-Logs geschehen (NICHT fhem-log!).
** sind entsprechende "set-Befehle" erkennbar (oft auch durch Readings). Also ist beispielsweise (wie beim Dummy nötig) ein ''setList'' mit entsprechenden Einträgen vorhanden oder entsprechende Readings, z.B. desired-temp zum Stellen der Temperatur etc.
** wird das Device nicht richtig oder "unvollständig" erkannt helfen folgende Attribute:
*** genericDeviceType: hiermit kann alexa-fhem in die gewünschte Richtung "geschubbst" werden. Anmerkung: man kann nicht alles erzwingen, Readings bzw. set-Befehle müssen passen (oder per homebridgeMapping passend gemacht werden). Wenn ein genericDeviceType nicht per "Drop-Down" erscheint, dann kann er auch (wenn bekannt) einfach per WEB-cmd eingegeben werden: ''attr Devicename genericDeviceType media''
*** homebridgeMapping: hierdurch kann alexa-fhem bei der Erkennung von Zuständen und möglichen Einstellungen (also WAS kann das Device) unterstützt werden. Mittels homebridgeMapping können vorhandene Readings (Zustände) auf für alexa-fhem bekannte Zustände gemappt werden. Ebenso können damit Standard-fhem-Kommandos von alexa-fhem auf Device-spezifische gemappt werden. Beispiel: on/off auf Ein/Aus (falls das Device statt on/off eben ein Ein/Aus erwartet). Zum Beispiel: <syntaxhighlight lang="bash" style="width:50%;">
attr <thermostat> homebridgeMapping TargetTemperature=target::target,minValue=18,maxValue=25,minStep=0.5 CurrentTemperature=myTemp:temperature
</syntaxhighlight> [https://github.com/justme-1968/homebridge-fhem/blob/master/README.md weitere Beispiele]

</br>'''Mehrere Namen für dasselbe Gerät/Device in fhem sind möglich.'''</br>
Die Namen werden durch Strichpunkt getrennt.</br>
Beispiel:</br>
<code>attr dmLampe alexaName Lichtkuppel;Lichtkugel</code>

'''Anmerkung bzgl. genericDeviceType und homebridgeMapping:'''<br>
* diese Attribute werden von verschiedenen "Sprachsteuerungsmodulen" in fhem verwendet (homebridge [dort wurde es "erfunden"], alexa-fhem, gassistant, ...). Daher ist nicht jedes Mapping für alle "Dienste" verwendbar. Ausprobieren schadet aber nicht.
* ebenso kann man mit diesen Attributen (homebridgeMapping wird gerne so "missbraucht") nichts erzwingen, was seitens Amazon/Alexa nicht unterstützt bzw. verstanden wird! D.h. zunächst ist zu prüfen, ob ein bestimmter (gewünschter) Sprachbefehl seitens Amazon/Alexa unterstützt wird! Aktuelles Beispiel (Stand Jan 2020): "Alexa, fahre den Rollo hoch/runter". Da ist Amazon/Alexa gerade dabei etwas zu tun. Bislang wird das nicht unterstützt, also ist das auch mit einem entsprechenden homebridgeMapping nicht zu erzwingen! Was unterstützt wird kann man bei Amazon nachlesen: [https://developer.amazon.com/es-ES/docs/alexa/device-apis/list-of-interfaces.html]

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

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

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

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

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

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

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

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

== Was geht alles ? ==

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

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

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

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

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

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

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

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

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

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

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

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

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

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

* Geräte, die sich ein- (und optional) ausschalten lassen als Szene (ab alexa-fhem version 0.5.26)
** Über <code>genericDeviceType</code> scene
** Automatisch: Müssen <code>set on</code> und <code>set off</code> Kommandos haben
** homebridgeMapping On:reading=<reading>,cmdOn=<cmd>[,cmdOff=<cmd>]
** Hinweis: Fehlende Kommandos lassen sich mit cmdalias erzeugen
** Wichtig:
*** Ein Skill darf nur 12 Szenen automatisch erkennen und einbinden.
* Rollläden. Lange ein Problemthema, das nur mit "Schalte auf 0%, schalte auf 100% lief". Wichtig: "alexa-fhem" ab Version 0.5.39 einsetzen. GenericDevice-Type auf "blind" setzen. Nach Restart von alexa-fhem und neuer Gerätesuche sollte folgendes funktionieren:
** "..., öffne <Name> ganz"
** "..., schließe <Name> komplett"
** "hoch" und "runter" (ohne "ganz" oder "komplett") schalten jeweils nur einen bestimmten Prozentsatz hoch oder runter. Dieser kann mit <code>attr <name> homebridgeMapping TargetPosition:minStep=<wert></code>geändert werden. Aber Achtung: In diesem Intervall kann dann auch nur noch ein absoluter Prozentwert per Sprache oder Slider eingestellt werden! Bei z.B. 25% würden 13% zu 25% aufgerundet, 12% zu 0% abgerundet werden.
* Kontaktsensoren (ab alexa-fhem version 0.5.47)
** Automatisch wenn ein Reading <code>motion</code> vorhanden ist oder es sich um einen Zigbee bewgungsmelder an einer HUE oder deCONZ Bridge handelt
** Über <code>genericDeviceType</code> MotionSensor
** homebridgeMapping MotionDetected:reading=<reading>,values=<wert für bewgung>:1;<wert für keine bewegung>:0

* Alarmmelder (noch nicht in Deutschland):
** genericDeviceType Security
** homebridgeMapping Alarm=<reading>[,type=[fireAlarm|waterAlarm|burglaryAlarm|carbonMonoxideAlarm]]
** wenn der type nicht angegeben wird ist fireAlarm der default
** automatisch werden 0, ok und alles was mit no anfängt als OK erkannt. alles andere gilt als ALARM.

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

to be continued ...

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

=== Aktiv Routinen starten ===
Routinen (eine Funktionalität, die rein - genauso wie "Räume" - bei Amazon liegt und nicht von FHEM Connector beeinflusst wird) waren lange die ewige Antwort auf die Frage: "Meine Frau möchte aber '''Öffne Rollläden''<nowiki/>' sagen": In der Alexa-App gibt es im Menü den Punkt "Routinen", und hier lässt sich eine gewisse Anzahl von Aktionen (unter optionalen Bedingungen) an ein Sprachkommando knüpfen.

Neu: Routinen können inzwischen auch von Skills getriggert werden, und seit Version 0.5.47 (Februar 2020) auch von FHEM Connector. Das braucht niemand, um die Rollläden hochzufahren, denn das kann FHEM ja selber, aber um z.B. eine Ansage auf einem Alexa-Gerät zu triggern. Dafür gibt es auch das FHEM-Modul "echodevice", aber es erfordert ein paar Klimmzüge. Mit dem aktiven Triggern von Routinen kann FHEM auslösen, dass Alexa ungefragt (!) Dinge wie

''"Die Temperatur in der Tiefkühltruhe hat -16 Grad überschritten"''

in den Raum sagt. Also eine Alternative bzw. Ergänzung zu Alarmen / Erinnerungen per Telegram o.ä.

'''Vorgeschichte''':

Die Smarthome-Skill-API von Amazon sah schon lange das "proactiveReporting" vor: Also z.B. die gemessene Temperatur nicht erst auf Anfrage hin zu übermitteln, sondern laufend aktiv zu pushen. Aber warum Daten an Amazon senden, wenn es dafür keinen Mehrwert gibt? Beim Öffnen z.B. des Thermostaten in der Alexa-App kommen ohnehin laufend Statusabfragen. Warum also einen Datenpool bei Amazon über die Haustemperatur aufbauen und Änderungen pushen, wenn es keinen Mehrwert dafür gibt?

Inzwischen lassen sich (reale oder vermeintliche) Änderungen von ''Bewegungssensoren'' und ''Fensterkontakten'' als Startbedingung an Alexa-Routinen koppeln. Man kann in der Alexa-App (ggf. fiktive) Öffnen eines Fensterkontaktes an das Aufsagen eines freien Textes durch die Hausbutlerin knüpfen.

'''Umsetzung''':
* Jedes Alexa-Device, dessen Status aktiv zu Amazon gepusht werden soll, im Attribut "alexaProactiveEvents" mit einer "1" versehen. Per Default wird ''kein'' Gerät laufend aktiv zu Amazon gepusht!
* das geänderte Device einmal zu Amazon pushen "set <alexa> add <device>" (oder 'Alexa, suche neue Geräte' murmeln)
* Das Gerät sollte jetzt beim Anlegen einer neuen Routine ("Neue Routine", "Wenn Folgendes passiert", "Smart Home") als möglicher Triggerpunkt erscheinen.

==== Dummygeräte: ====
Ein Dummydevice sollte einen Kontaktschalter oder Bewegungssensor simulieren, um dann in FHEM eine beliebige Bedingung als Trigger zu definieren, und eine freie Ansage in Alexa als Routine zu definieren. Hier ein Beispiel:

<syntaxhighlight lang="bash" style="width:90%;">
define voicetrigger1 dummy
attr voicetrigger1 alexaName Trigger 1
attr voicetrigger1 alexaProactiveEvents 1
attr voicetrigger1 genericDeviceType contact
attr voicetrigger1 homebridgeMapping ContactSensorState=state,values=closed:CONTACT_DETECTED;;open:CONTACT_NOT_DETECTED
attr voicetrigger1 readingList 0:closed 1:open
attr voicetrigger1 setList closed open

set alexa add voicetrigger1
set alexa restart
</syntaxhighlight>

'''Fehlersuche:'''

Der Push setzt ein intaktes Push-Token voraus. Sollte im Alexa-Logfile Folgendes erscheinen:

<code>failed to refresh token: invalid_grant: 'The request has an invalid grant parameter : refresh_token'</code>

so ist das Push-Token nicht aktuell. Weil die Auswirkung lange nur war, dass Geräteänderungen nicht aktiv an Amazon gemeldet wurden, gibt es noch keine umfassende Analyse des Problems. Es lässt sich lösen, indem eine oder beide folgenden Aktionen ausgeführt werden:
* Löschen des ".eventToken" im Alexa-Device über "deletereading"
* "FHEM-Connector"-Skill auf "alexa.amazon.de" einmal deaktivieren und dann neu verbinden

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

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

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

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

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

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

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

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

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

Auf der Kommandoshell:

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

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

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

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

== Sicherheitskonzept und Secrets ==

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

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

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

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

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

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

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

== alexa-fhem Updaten bzw. "Upgraden" ==

'''Updaten einer "Connector" Installation:'''
* alexa-fhem über FHEM anhalten (Name des Alexa-Device: alexa):
:<syntaxhighlight lang="perl" style="width:50%;">set alexa stop</syntaxhighlight>

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

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

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

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

'''"Upgraden von einer "Nicht-Connector" Installation (z.B. manuelle Installation per pm-Download):'''
* Daten der aktuellen Installation sichern (v.a. config.json / man weiß ja nie)
* Autostart der aktuellen alexa-fhem Installation deaktivieren:
** Bei initd: Service deaktivieren mittels: <code>sudo update-rc.d -f alexa remove</code> Vorher mittels stoppen: <code>sudo service alexa stop</code> Startscript unter /etc/init.d/ löschen.
** Bei systemd: Service deaktivieren mittels: <code>sudo systemctl disable alexa</code> Vorher mittels stoppen: <code>sudo systemctl alexa stop</code> Startscript unter /etc/systemd/system/ löschen.
* ALLE vorhandenen alexa-fhem Daten LÖSCHEN! Bleiben Dinge zurück und wird dann laut Connector installiert kann es zu Problemen kommen!
* (reboot)
* Installation von alexa-fhem laut Anleitung (Beginn dieses Wiki)
* Falls eigene Dinge von früher genutzt werden wollen/sollen (z.B. Custom Skill), dann die entsprechenden Einträge aus der gesicherten config.json in die neu angelegte alexa-fhem.cfg (zu finden unter "Edit files") übernehmen.
* Werden keine eigenen Dinge verwendet, dann kann der Port (Standard: 3000) geschlossen werden und auch die Daten unter Amazon-Developer können gelöscht werden.

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

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

==Hinweise==
<references />

FHEM Connector für Amazon Alexa

2020-06-01T18:53:15Z

TomLee: /* Weitergehende Informationen */<references /> ergänzt ?

FHEM Connector für Amazon Alexa

2020-06-01T18:33:50Z

TomLee: /* Geräte im FHEM-Webfrontend zuweisen */Test

FHEM Connector für Amazon Alexa

2020-06-01T18:24:22Z

TomLee: /* Geräte im FHEM-Webfrontend zuweisen */Link korrigiert

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

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

* SONOS Beam und SONOS One

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

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

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

==Einführung==

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

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

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

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

==Installation==

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

===node.js installieren===

Ab Jessy liegt NodeJS bereits in einer ausreichend aktuellen Version vor (Stretch und Buster funktionieren ebenfalls). Mit

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

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

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

=== Alexa-FHEM installieren ===

Nun installieren wir Alexa-fhem aus dem offiziellen Repository:

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

Der Vorgang benötigt etwas Zeit.

=== Alexa-FHEM aktivieren ===

Wechsele jetzt in FHEM-Web!

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

* Zuerst bitte einfach einmal die Seite neu laden.

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

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

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

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

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

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

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

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

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

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

Du solltest dann folgende Ausgabe erhalten:

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

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

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

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

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

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

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

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

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

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

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

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

Wähle die Geräte aus, rufe sie auf und setze das Attribut "alexaName". Hierbei in Kürze nur der Hinweis:
* Keine Angst vor Leerzeichen und Umlauten, funktioniert.
* Große Angst vor Rechtschreibfehlern (Terrasse, Rollladen) oder komplizierten Wörtern "handgebastelte Martinslaterne im Kinderzimmer Iphigenie-Chantal".
* Mehrere Namen für dasselbe Gerät/Device in fhem werden unterstützt. Mehrere Namen werden durch Strichpunkt getrennt <ref>Feature nicht dokumentiert {{Link2Forum|Topic=74041|LinkText=Forumsthread}} </ref>.
* Das Attribut "alexaRoom" ist NUR FÜR DEN CUSTOM SKILL relevant. Ausnahme: structure und LightScene Devices, siehe: [[FHEM_Connector_f%C3%BCr_Amazon_Alexa#Was_geht_alles_.3F]].

Lade die Geräte neu in die Software, indem Du <code>set <alexa> restart</code> ausführst!
[[Datei:HowToSet alexaName.png|alternativtext=How to set alexaName|ohne|mini|Wie setzt man das Attribut alexaName]]

'''Anmerkungen (weil oft gestellte Fragen im Forum) bzgl. Erkennung von Geräten:'''

* Wichtig ist, dass die Filtereinstellung in der alexa-fhem.cfg (zu finden unter "Edit Files") passt.
Das, was dort eingetragen ist (Standard: alexaName=..* / also es ist ein alexaName vergeben) auch an den entsprechenden Devices in fhem vorhanden ist.
Stimmt das nicht überein, kann alexa-fhem keine Devices von fhem abfragen/finden.
Ob der Filter entsprechend funktioniert kann man wie folgt testen: ''list Filtereinstellung'' beispiel mit Standardfilter: ''list alexaName=..*''

* Hat alexa-fhem per Filter Devices aus fhem "gefunden", geht es weiter mit der "Erkennung". Also um welches Device (Typ und "Fähigkeiten") handelt es sich. Dazu gilt folgendes:
** sind entsprechende Readings beim Device vorhanden (z.B. temperature, state mit on/off, ...) erkennt das alexa-fhem automatisch. Die Liste der automatisch erkannten Readings wächst ständig. Daher erst mal schauen ob das Device bereits entsprechend erkannt (typisiert) wurde. Das kann durch prüfen des alexa-fhem-Logs geschehen (NICHT fhem-log!).
** sind entsprechende "set-Befehle" erkennbar (oft auch durch Readings). Also ist beispielsweise (wie beim Dummy nötig) ein ''setList'' mit entsprechenden Einträgen vorhanden oder entsprechende Readings, z.B. desired-temp zum Stellen der Temperatur etc.
** wird das Device nicht richtig oder "unvollständig" erkannt helfen folgende Attribute:
*** genericDeviceType: hiermit kann alexa-fhem in die gewünschte Richtung "geschubbst" werden. Anmerkung: man kann nicht alles erzwingen, Readings bzw. set-Befehle müssen passen (oder per homebridgeMapping passend gemacht werden). Wenn ein genericDeviceType nicht per "Drop-Down" erscheint, dann kann er auch (wenn bekannt) einfach per WEB-cmd eingegeben werden: ''attr Devicename genericDeviceType media''
*** homebridgeMapping: hierdurch kann alexa-fhem bei der Erkennung von Zuständen und möglichen Einstellungen (also WAS kann das Device) unterstützt werden. Mittels homebridgeMapping können vorhandene Readings (Zustände) auf für alexa-fhem bekannte Zustände gemappt werden. Ebenso können damit Standard-fhem-Kommandos von alexa-fhem auf Device-spezifische gemappt werden. Beispiel: on/off auf Ein/Aus (falls das Device statt on/off eben ein Ein/Aus erwartet). Zum Beispiel: <syntaxhighlight lang="bash" style="width:50%;">
attr <thermostat> homebridgeMapping TargetTemperature=target::target,minValue=18,maxValue=25,minStep=0.5 CurrentTemperature=myTemp:temperature
</syntaxhighlight> [https://github.com/justme-1968/homebridge-fhem/blob/master/README.md weitere Beispiele]

</br>'''Mehrere Namen für dasselbe Gerät/Device in fhem sind möglich.'''</br>
Die Namen werden durch Strichpunkt getrennt.</br>
Beispiel:</br>
<code>attr dmLampe alexaName Lichtkuppel;Lichtkugel</code>

'''Anmerkung bzgl. genericDeviceType und homebridgeMapping:'''<br>
* diese Attribute werden von verschiedenen "Sprachsteuerungsmodulen" in fhem verwendet (homebridge [dort wurde es "erfunden"], alexa-fhem, gassistant, ...). Daher ist nicht jedes Mapping für alle "Dienste" verwendbar. Ausprobieren schadet aber nicht.
* ebenso kann man mit diesen Attributen (homebridgeMapping wird gerne so "missbraucht") nichts erzwingen, was seitens Amazon/Alexa nicht unterstützt bzw. verstanden wird! D.h. zunächst ist zu prüfen, ob ein bestimmter (gewünschter) Sprachbefehl seitens Amazon/Alexa unterstützt wird! Aktuelles Beispiel (Stand Jan 2020): "Alexa, fahre den Rollo hoch/runter". Da ist Amazon/Alexa gerade dabei etwas zu tun. Bislang wird das nicht unterstützt, also ist das auch mit einem entsprechenden homebridgeMapping nicht zu erzwingen! Was unterstützt wird kann man bei Amazon nachlesen: [https://developer.amazon.com/es-ES/docs/alexa/device-apis/list-of-interfaces.html]

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

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

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

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

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

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

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

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

== Was geht alles ? ==

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

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

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

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

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

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

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

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

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

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

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

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

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

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

* Geräte, die sich ein- (und optional) ausschalten lassen als Szene (ab alexa-fhem version 0.5.26)
** Über <code>genericDeviceType</code> scene
** Automatisch: Müssen <code>set on</code> und <code>set off</code> Kommandos haben
** homebridgeMapping On:reading=<reading>,cmdOn=<cmd>[,cmdOff=<cmd>]
** Hinweis: Fehlende Kommandos lassen sich mit cmdalias erzeugen
** Wichtig:
*** Ein Skill darf nur 12 Szenen automatisch erkennen und einbinden.
* Rollläden. Lange ein Problemthema, das nur mit "Schalte auf 0%, schalte auf 100% lief". Wichtig: "alexa-fhem" ab Version 0.5.39 einsetzen. GenericDevice-Type auf "blind" setzen. Nach Restart von alexa-fhem und neuer Gerätesuche sollte folgendes funktionieren:
** "..., öffne <Name> ganz"
** "..., schließe <Name> komplett"
** "hoch" und "runter" (ohne "ganz" oder "komplett") schalten jeweils nur einen bestimmten Prozentsatz hoch oder runter. Dieser kann mit <code>attr <name> homebridgeMapping TargetPosition:minStep=<wert></code>geändert werden. Aber Achtung: In diesem Intervall kann dann auch nur noch ein absoluter Prozentwert per Sprache oder Slider eingestellt werden! Bei z.B. 25% würden 13% zu 25% aufgerundet, 12% zu 0% abgerundet werden.
* Kontaktsensoren (ab alexa-fhem version 0.5.47)
** Automatisch wenn ein Reading <code>motion</code> vorhanden ist oder es sich um einen Zigbee bewgungsmelder an einer HUE oder deCONZ Bridge handelt
** Über <code>genericDeviceType</code> MotionSensor
** homebridgeMapping MotionDetected:reading=<reading>,values=<wert für bewgung>:1;<wert für keine bewegung>:0

* Alarmmelder (noch nicht in Deutschland):
** genericDeviceType Security
** homebridgeMapping Alarm=<reading>[,type=[fireAlarm|waterAlarm|burglaryAlarm|carbonMonoxideAlarm]]
** wenn der type nicht angegeben wird ist fireAlarm der default
** automatisch werden 0, ok und alles was mit no anfängt als OK erkannt. alles andere gilt als ALARM.

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

to be continued ...

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

=== Aktiv Routinen starten ===
Routinen (eine Funktionalität, die rein - genauso wie "Räume" - bei Amazon liegt und nicht von FHEM Connector beeinflusst wird) waren lange die ewige Antwort auf die Frage: "Meine Frau möchte aber '''Öffne Rollläden''<nowiki/>' sagen": In der Alexa-App gibt es im Menü den Punkt "Routinen", und hier lässt sich eine gewisse Anzahl von Aktionen (unter optionalen Bedingungen) an ein Sprachkommando knüpfen.

Neu: Routinen können inzwischen auch von Skills getriggert werden, und seit Version 0.5.47 (Februar 2020) auch von FHEM Connector. Das braucht niemand, um die Rollläden hochzufahren, denn das kann FHEM ja selber, aber um z.B. eine Ansage auf einem Alexa-Gerät zu triggern. Dafür gibt es auch das FHEM-Modul "echodevice", aber es erfordert ein paar Klimmzüge. Mit dem aktiven Triggern von Routinen kann FHEM auslösen, dass Alexa ungefragt (!) Dinge wie

''"Die Temperatur in der Tiefkühltruhe hat -16 Grad überschritten"''

in den Raum sagt. Also eine Alternative bzw. Ergänzung zu Alarmen / Erinnerungen per Telegram o.ä.

'''Vorgeschichte''':

Die Smarthome-Skill-API von Amazon sah schon lange das "proactiveReporting" vor: Also z.B. die gemessene Temperatur nicht erst auf Anfrage hin zu übermitteln, sondern laufend aktiv zu pushen. Aber warum Daten an Amazon senden, wenn es dafür keinen Mehrwert gibt? Beim Öffnen z.B. des Thermostaten in der Alexa-App kommen ohnehin laufend Statusabfragen. Warum also einen Datenpool bei Amazon über die Haustemperatur aufbauen und Änderungen pushen, wenn es keinen Mehrwert dafür gibt?

Inzwischen lassen sich (reale oder vermeintliche) Änderungen von ''Bewegungssensoren'' und ''Fensterkontakten'' als Startbedingung an Alexa-Routinen koppeln. Man kann in der Alexa-App (ggf. fiktive) Öffnen eines Fensterkontaktes an das Aufsagen eines freien Textes durch die Hausbutlerin knüpfen.

'''Umsetzung''':
* Jedes Alexa-Device, dessen Status aktiv zu Amazon gepusht werden soll, im Attribut "alexaProactiveEvents" mit einer "1" versehen. Per Default wird ''kein'' Gerät laufend aktiv zu Amazon gepusht!
* das geänderte Device einmal zu Amazon pushen "set <alexa> add <device>" (oder 'Alexa, suche neue Geräte' murmeln)
* Das Gerät sollte jetzt beim Anlegen einer neuen Routine ("Neue Routine", "Wenn Folgendes passiert", "Smart Home") als möglicher Triggerpunkt erscheinen.

==== Dummygeräte: ====
Ein Dummydevice sollte einen Kontaktschalter oder Bewegungssensor simulieren, um dann in FHEM eine beliebige Bedingung als Trigger zu definieren, und eine freie Ansage in Alexa als Routine zu definieren. Hier ein Beispiel:

<syntaxhighlight lang="bash" style="width:90%;">
define voicetrigger1 dummy
attr voicetrigger1 alexaName Trigger 1
attr voicetrigger1 alexaProactiveEvents 1
attr voicetrigger1 genericDeviceType contact
attr voicetrigger1 homebridgeMapping ContactSensorState=state,values=closed:CONTACT_DETECTED;;open:CONTACT_NOT_DETECTED
attr voicetrigger1 readingList 0:closed 1:open
attr voicetrigger1 setList closed open

set alexa add voicetrigger1
set alexa restart
</syntaxhighlight>

'''Fehlersuche:'''

Der Push setzt ein intaktes Push-Token voraus. Sollte im Alexa-Logfile Folgendes erscheinen:

<code>failed to refresh token: invalid_grant: 'The request has an invalid grant parameter : refresh_token'</code>

so ist das Push-Token nicht aktuell. Weil die Auswirkung lange nur war, dass Geräteänderungen nicht aktiv an Amazon gemeldet wurden, gibt es noch keine umfassende Analyse des Problems. Es lässt sich lösen, indem eine oder beide folgenden Aktionen ausgeführt werden:
* Löschen des ".eventToken" im Alexa-Device über "deletereading"
* "FHEM-Connector"-Skill auf "alexa.amazon.de" einmal deaktivieren und dann neu verbinden

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

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

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

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

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

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

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

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

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

Auf der Kommandoshell:

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

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

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

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

== Sicherheitskonzept und Secrets ==

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

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

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

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

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

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

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

== alexa-fhem Updaten bzw. "Upgraden" ==

'''Updaten einer "Connector" Installation:'''
* alexa-fhem über FHEM anhalten (Name des Alexa-Device: alexa):
:<syntaxhighlight lang="perl" style="width:50%;">set alexa stop</syntaxhighlight>

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

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

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

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

'''"Upgraden von einer "Nicht-Connector" Installation (z.B. manuelle Installation per pm-Download):'''
* Daten der aktuellen Installation sichern (v.a. config.json / man weiß ja nie)
* Autostart der aktuellen alexa-fhem Installation deaktivieren:
** Bei initd: Service deaktivieren mittels: <code>sudo update-rc.d -f alexa remove</code> Vorher mittels stoppen: <code>sudo service alexa stop</code> Startscript unter /etc/init.d/ löschen.
** Bei systemd: Service deaktivieren mittels: <code>sudo systemctl disable alexa</code> Vorher mittels stoppen: <code>sudo systemctl alexa stop</code> Startscript unter /etc/systemd/system/ löschen.
* ALLE vorhandenen alexa-fhem Daten LÖSCHEN! Bleiben Dinge zurück und wird dann laut Connector installiert kann es zu Problemen kommen!
* (reboot)
* Installation von alexa-fhem laut Anleitung (Beginn dieses Wiki)
* Falls eigene Dinge von früher genutzt werden wollen/sollen (z.B. Custom Skill), dann die entsprechenden Einträge aus der gesicherten config.json in die neu angelegte alexa-fhem.cfg (zu finden unter "Edit files") übernehmen.
* Werden keine eigenen Dinge verwendet, dann kann der Port (Standard: 3000) geschlossen werden und auch die Daten unter Amazon-Developer können gelöscht werden.

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

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

FHEM Connector für Amazon Alexa

2020-06-01T18:07:07Z

TomLee: /* Geräte im FHEM-Webfrontend zuweisen */Fußnote ergänzt

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

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

* SONOS Beam und SONOS One

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

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

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

==Einführung==

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

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

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

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

==Installation==

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

===node.js installieren===

Ab Jessy liegt NodeJS bereits in einer ausreichend aktuellen Version vor (Stretch und Buster funktionieren ebenfalls). Mit

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

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

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

=== Alexa-FHEM installieren ===

Nun installieren wir Alexa-fhem aus dem offiziellen Repository:

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

Der Vorgang benötigt etwas Zeit.

=== Alexa-FHEM aktivieren ===

Wechsele jetzt in FHEM-Web!

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

* Zuerst bitte einfach einmal die Seite neu laden.

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

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

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

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

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

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

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

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

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

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

Du solltest dann folgende Ausgabe erhalten:

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

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

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

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

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

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

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

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

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

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

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

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

Wähle die Geräte aus, rufe sie auf und setze das Attribut "alexaName". Hierbei in Kürze nur der Hinweis:
* Keine Angst vor Leerzeichen und Umlauten, funktioniert.
* Große Angst vor Rechtschreibfehlern (Terrasse, Rollladen) oder komplizierten Wörtern "handgebastelte Martinslaterne im Kinderzimmer Iphigenie-Chantal".
* Mehrere Namen für dasselbe Gerät/Device in fhem werden unterstützt. Mehrere Namen werden durch Strichpunkt getrennt <ref>Feature nicht dokumentiert {{Link2Forum|Topic=664492|LinkText=Forumsthread}} </ref>.
* Das Attribut "alexaRoom" ist NUR FÜR DEN CUSTOM SKILL relevant. Ausnahme: structure und LightScene Devices, siehe: [[FHEM_Connector_f%C3%BCr_Amazon_Alexa#Was_geht_alles_.3F]].

Lade die Geräte neu in die Software, indem Du <code>set <alexa> restart</code> ausführst!
[[Datei:HowToSet alexaName.png|alternativtext=How to set alexaName|ohne|mini|Wie setzt man das Attribut alexaName]]

'''Anmerkungen (weil oft gestellte Fragen im Forum) bzgl. Erkennung von Geräten:'''

* Wichtig ist, dass die Filtereinstellung in der alexa-fhem.cfg (zu finden unter "Edit Files") passt.
Das, was dort eingetragen ist (Standard: alexaName=..* / also es ist ein alexaName vergeben) auch an den entsprechenden Devices in fhem vorhanden ist.
Stimmt das nicht überein, kann alexa-fhem keine Devices von fhem abfragen/finden.
Ob der Filter entsprechend funktioniert kann man wie folgt testen: ''list Filtereinstellung'' beispiel mit Standardfilter: ''list alexaName=..*''

* Hat alexa-fhem per Filter Devices aus fhem "gefunden", geht es weiter mit der "Erkennung". Also um welches Device (Typ und "Fähigkeiten") handelt es sich. Dazu gilt folgendes:
** sind entsprechende Readings beim Device vorhanden (z.B. temperature, state mit on/off, ...) erkennt das alexa-fhem automatisch. Die Liste der automatisch erkannten Readings wächst ständig. Daher erst mal schauen ob das Device bereits entsprechend erkannt (typisiert) wurde. Das kann durch prüfen des alexa-fhem-Logs geschehen (NICHT fhem-log!).
** sind entsprechende "set-Befehle" erkennbar (oft auch durch Readings). Also ist beispielsweise (wie beim Dummy nötig) ein ''setList'' mit entsprechenden Einträgen vorhanden oder entsprechende Readings, z.B. desired-temp zum Stellen der Temperatur etc.
** wird das Device nicht richtig oder "unvollständig" erkannt helfen folgende Attribute:
*** genericDeviceType: hiermit kann alexa-fhem in die gewünschte Richtung "geschubbst" werden. Anmerkung: man kann nicht alles erzwingen, Readings bzw. set-Befehle müssen passen (oder per homebridgeMapping passend gemacht werden). Wenn ein genericDeviceType nicht per "Drop-Down" erscheint, dann kann er auch (wenn bekannt) einfach per WEB-cmd eingegeben werden: ''attr Devicename genericDeviceType media''
*** homebridgeMapping: hierdurch kann alexa-fhem bei der Erkennung von Zuständen und möglichen Einstellungen (also WAS kann das Device) unterstützt werden. Mittels homebridgeMapping können vorhandene Readings (Zustände) auf für alexa-fhem bekannte Zustände gemappt werden. Ebenso können damit Standard-fhem-Kommandos von alexa-fhem auf Device-spezifische gemappt werden. Beispiel: on/off auf Ein/Aus (falls das Device statt on/off eben ein Ein/Aus erwartet). Zum Beispiel: <syntaxhighlight lang="bash" style="width:50%;">
attr <thermostat> homebridgeMapping TargetTemperature=target::target,minValue=18,maxValue=25,minStep=0.5 CurrentTemperature=myTemp:temperature
</syntaxhighlight> [https://github.com/justme-1968/homebridge-fhem/blob/master/README.md weitere Beispiele]

</br>'''Mehrere Namen für dasselbe Gerät/Device in fhem sind möglich.'''</br>
Die Namen werden durch Strichpunkt getrennt.</br>
Beispiel:</br>
<code>attr dmLampe alexaName Lichtkuppel;Lichtkugel</code>

'''Anmerkung bzgl. genericDeviceType und homebridgeMapping:'''<br>
* diese Attribute werden von verschiedenen "Sprachsteuerungsmodulen" in fhem verwendet (homebridge [dort wurde es "erfunden"], alexa-fhem, gassistant, ...). Daher ist nicht jedes Mapping für alle "Dienste" verwendbar. Ausprobieren schadet aber nicht.
* ebenso kann man mit diesen Attributen (homebridgeMapping wird gerne so "missbraucht") nichts erzwingen, was seitens Amazon/Alexa nicht unterstützt bzw. verstanden wird! D.h. zunächst ist zu prüfen, ob ein bestimmter (gewünschter) Sprachbefehl seitens Amazon/Alexa unterstützt wird! Aktuelles Beispiel (Stand Jan 2020): "Alexa, fahre den Rollo hoch/runter". Da ist Amazon/Alexa gerade dabei etwas zu tun. Bislang wird das nicht unterstützt, also ist das auch mit einem entsprechenden homebridgeMapping nicht zu erzwingen! Was unterstützt wird kann man bei Amazon nachlesen: [https://developer.amazon.com/es-ES/docs/alexa/device-apis/list-of-interfaces.html]

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

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

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

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

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

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

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

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

== Was geht alles ? ==

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

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

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

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

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

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

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

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

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

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

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

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

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

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

* Geräte, die sich ein- (und optional) ausschalten lassen als Szene (ab alexa-fhem version 0.5.26)
** Über <code>genericDeviceType</code> scene
** Automatisch: Müssen <code>set on</code> und <code>set off</code> Kommandos haben
** homebridgeMapping On:reading=<reading>,cmdOn=<cmd>[,cmdOff=<cmd>]
** Hinweis: Fehlende Kommandos lassen sich mit cmdalias erzeugen
** Wichtig:
*** Ein Skill darf nur 12 Szenen automatisch erkennen und einbinden.
* Rollläden. Lange ein Problemthema, das nur mit "Schalte auf 0%, schalte auf 100% lief". Wichtig: "alexa-fhem" ab Version 0.5.39 einsetzen. GenericDevice-Type auf "blind" setzen. Nach Restart von alexa-fhem und neuer Gerätesuche sollte folgendes funktionieren:
** "..., öffne <Name> ganz"
** "..., schließe <Name> komplett"
** "hoch" und "runter" (ohne "ganz" oder "komplett") schalten jeweils nur einen bestimmten Prozentsatz hoch oder runter. Dieser kann mit <code>attr <name> homebridgeMapping TargetPosition:minStep=<wert></code>geändert werden. Aber Achtung: In diesem Intervall kann dann auch nur noch ein absoluter Prozentwert per Sprache oder Slider eingestellt werden! Bei z.B. 25% würden 13% zu 25% aufgerundet, 12% zu 0% abgerundet werden.
* Kontaktsensoren (ab alexa-fhem version 0.5.47)
** Automatisch wenn ein Reading <code>motion</code> vorhanden ist oder es sich um einen Zigbee bewgungsmelder an einer HUE oder deCONZ Bridge handelt
** Über <code>genericDeviceType</code> MotionSensor
** homebridgeMapping MotionDetected:reading=<reading>,values=<wert für bewgung>:1;<wert für keine bewegung>:0

* Alarmmelder (noch nicht in Deutschland):
** genericDeviceType Security
** homebridgeMapping Alarm=<reading>[,type=[fireAlarm|waterAlarm|burglaryAlarm|carbonMonoxideAlarm]]
** wenn der type nicht angegeben wird ist fireAlarm der default
** automatisch werden 0, ok und alles was mit no anfängt als OK erkannt. alles andere gilt als ALARM.

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

to be continued ...

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

=== Aktiv Routinen starten ===
Routinen (eine Funktionalität, die rein - genauso wie "Räume" - bei Amazon liegt und nicht von FHEM Connector beeinflusst wird) waren lange die ewige Antwort auf die Frage: "Meine Frau möchte aber '''Öffne Rollläden''<nowiki/>' sagen": In der Alexa-App gibt es im Menü den Punkt "Routinen", und hier lässt sich eine gewisse Anzahl von Aktionen (unter optionalen Bedingungen) an ein Sprachkommando knüpfen.

Neu: Routinen können inzwischen auch von Skills getriggert werden, und seit Version 0.5.47 (Februar 2020) auch von FHEM Connector. Das braucht niemand, um die Rollläden hochzufahren, denn das kann FHEM ja selber, aber um z.B. eine Ansage auf einem Alexa-Gerät zu triggern. Dafür gibt es auch das FHEM-Modul "echodevice", aber es erfordert ein paar Klimmzüge. Mit dem aktiven Triggern von Routinen kann FHEM auslösen, dass Alexa ungefragt (!) Dinge wie

''"Die Temperatur in der Tiefkühltruhe hat -16 Grad überschritten"''

in den Raum sagt. Also eine Alternative bzw. Ergänzung zu Alarmen / Erinnerungen per Telegram o.ä.

'''Vorgeschichte''':

Die Smarthome-Skill-API von Amazon sah schon lange das "proactiveReporting" vor: Also z.B. die gemessene Temperatur nicht erst auf Anfrage hin zu übermitteln, sondern laufend aktiv zu pushen. Aber warum Daten an Amazon senden, wenn es dafür keinen Mehrwert gibt? Beim Öffnen z.B. des Thermostaten in der Alexa-App kommen ohnehin laufend Statusabfragen. Warum also einen Datenpool bei Amazon über die Haustemperatur aufbauen und Änderungen pushen, wenn es keinen Mehrwert dafür gibt?

Inzwischen lassen sich (reale oder vermeintliche) Änderungen von ''Bewegungssensoren'' und ''Fensterkontakten'' als Startbedingung an Alexa-Routinen koppeln. Man kann in der Alexa-App (ggf. fiktive) Öffnen eines Fensterkontaktes an das Aufsagen eines freien Textes durch die Hausbutlerin knüpfen.

'''Umsetzung''':
* Jedes Alexa-Device, dessen Status aktiv zu Amazon gepusht werden soll, im Attribut "alexaProactiveEvents" mit einer "1" versehen. Per Default wird ''kein'' Gerät laufend aktiv zu Amazon gepusht!
* das geänderte Device einmal zu Amazon pushen "set <alexa> add <device>" (oder 'Alexa, suche neue Geräte' murmeln)
* Das Gerät sollte jetzt beim Anlegen einer neuen Routine ("Neue Routine", "Wenn Folgendes passiert", "Smart Home") als möglicher Triggerpunkt erscheinen.

==== Dummygeräte: ====
Ein Dummydevice sollte einen Kontaktschalter oder Bewegungssensor simulieren, um dann in FHEM eine beliebige Bedingung als Trigger zu definieren, und eine freie Ansage in Alexa als Routine zu definieren. Hier ein Beispiel:

<syntaxhighlight lang="bash" style="width:90%;">
define voicetrigger1 dummy
attr voicetrigger1 alexaName Trigger 1
attr voicetrigger1 alexaProactiveEvents 1
attr voicetrigger1 genericDeviceType contact
attr voicetrigger1 homebridgeMapping ContactSensorState=state,values=closed:CONTACT_DETECTED;;open:CONTACT_NOT_DETECTED
attr voicetrigger1 readingList 0:closed 1:open
attr voicetrigger1 setList closed open

set alexa add voicetrigger1
set alexa restart
</syntaxhighlight>

'''Fehlersuche:'''

Der Push setzt ein intaktes Push-Token voraus. Sollte im Alexa-Logfile Folgendes erscheinen:

<code>failed to refresh token: invalid_grant: 'The request has an invalid grant parameter : refresh_token'</code>

so ist das Push-Token nicht aktuell. Weil die Auswirkung lange nur war, dass Geräteänderungen nicht aktiv an Amazon gemeldet wurden, gibt es noch keine umfassende Analyse des Problems. Es lässt sich lösen, indem eine oder beide folgenden Aktionen ausgeführt werden:
* Löschen des ".eventToken" im Alexa-Device über "deletereading"
* "FHEM-Connector"-Skill auf "alexa.amazon.de" einmal deaktivieren und dann neu verbinden

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

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

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

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

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

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

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

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

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

Auf der Kommandoshell:

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

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

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

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

== Sicherheitskonzept und Secrets ==

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

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

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

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

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

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

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

== alexa-fhem Updaten bzw. "Upgraden" ==

'''Updaten einer "Connector" Installation:'''
* alexa-fhem über FHEM anhalten (Name des Alexa-Device: alexa):
:<syntaxhighlight lang="perl" style="width:50%;">set alexa stop</syntaxhighlight>

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

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

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

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

'''"Upgraden von einer "Nicht-Connector" Installation (z.B. manuelle Installation per pm-Download):'''
* Daten der aktuellen Installation sichern (v.a. config.json / man weiß ja nie)
* Autostart der aktuellen alexa-fhem Installation deaktivieren:
** Bei initd: Service deaktivieren mittels: <code>sudo update-rc.d -f alexa remove</code> Vorher mittels stoppen: <code>sudo service alexa stop</code> Startscript unter /etc/init.d/ löschen.
** Bei systemd: Service deaktivieren mittels: <code>sudo systemctl disable alexa</code> Vorher mittels stoppen: <code>sudo systemctl alexa stop</code> Startscript unter /etc/systemd/system/ löschen.
* ALLE vorhandenen alexa-fhem Daten LÖSCHEN! Bleiben Dinge zurück und wird dann laut Connector installiert kann es zu Problemen kommen!
* (reboot)
* Installation von alexa-fhem laut Anleitung (Beginn dieses Wiki)
* Falls eigene Dinge von früher genutzt werden wollen/sollen (z.B. Custom Skill), dann die entsprechenden Einträge aus der gesicherten config.json in die neu angelegte alexa-fhem.cfg (zu finden unter "Edit files") übernehmen.
* Werden keine eigenen Dinge verwendet, dann kann der Port (Standard: 3000) geschlossen werden und auch die Daten unter Amazon-Developer können gelöscht werden.

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

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

MQTT2-Module - Praxisbeispiele

2020-03-16T15:27:01Z

TomLee: /* Allgemeines */Tippfehler korrigiert

MQTT2-Module - Praxisbeispiele

2020-03-03T12:33:13Z

TomLee: /* Tasmota */default Wert angepasst

EBUS-MQTT2

2019-10-23T15:21:02Z

TomLee: /* eBus mit MQTT2 auswerten */Denke der Thread war gemeint

== eBus - MQTT2 ==
Vorausgesetzt wird hier ein laufender eBus-Dämon. Dessen Einrichtung wird im Artikel [[EBUS#Software|EBUS]] beschrieben.
=== eBus mit MQTT2 auswerten ===
https://forum.fhem.de/index.php/topic,97989.0.html

Für die MQTT Kommunikation des eBus wird für die eigentlichen Geräte [https://forum.fhem.de/index.php/topic,91394.0.html MQTT2 DEVICE ] verwendet, damit wird als IO-Device entweder [https://forum.fhem.de/index.php/topic,91394.0.html MQTT2_SERVER ] oder MQTT2_CLIENT verwendet, NICHT beides gleichzeitig!
Bitte auch zu beachten, die alten Module MQTT funktionieren nicht nach der Beschreibung in diesem Artikel. Es geht hier um die komplett überarbeitete Version mit dem Namen MQTT2!

Bei der hier beschriebenen Konfiguration der angelegten Devices muss unbedingt die Reihenfolge eingehalten werden.

=== Anwendung: ===
Wer eBus komfortabel in FHEM einbinden will, kann dies nun erstmals mit wenigen Mausklicks realisieren. Erstmalig kommt diese neue Technik der von rudolfkönig implementierten Templates zur Anwendung. Templates sind im Prinzip vorgefertigte Schablonen die durch Anklicken dann selbständig den Device mit den darin enthaltenen Vorgaben konfigurieren. Beta-User hat diese Technik dann soweit für den eBus angepasst ( unter anderem die Filter erstellt ) , das sie allen eBus Anwendern zur Verfügung steht. Es kann nun jeder selbst Templates erstellen oder einfach die von mir erstellten vorhandenen Beispiele benutzen. In wenigen Minuten sollte die komplette FHEM Konfiguration dann abgeschlossen sein.

Wer bereits einen Mosquitto Broker installiert hat, kann diesen weiter verwenden, ist aber für die Komunikation mit dem eBus Dämon nicht mehr notwendig!

[[Bild:MQTT2_MQTT2.jpg|600px|thumb|left|Uebersicht eBus MQTT]]

<div style="clear:both;"></div>
=== Welches FHEM Modul benötigt man ===
{{Randnotiz|RNTyp=r|RNText=Nicht MQTT2_SERVER und Mosquitto gleichzeitig laufen lassen, es kann zu verschiedenen Problemen kommen wie gegenseitiges Löschen von Einträgen in FHEM.}}
Beispiel: Mosquitto Broker ist vorhanden
dann benötigt man MQTT2_DEVICE und MQTT2_CLIENT

Beispiel: Mosquitto Broker ist NICHT vorhanden
dann benötigt man MQTT2_DEVICE und MQTT2_SERVER

<div style="clear:both;"></div>

=== Vorbereitung und Definition am eBus ===
In der Konfiguration des Dämons ( /etc/default/ebusd ) sollten diese Parameter hinzugefügt werden. Die Topic „ebusd/%circuit/%name“ bitte nicht abändern, da verschiedene Filter auf diesen Ausdruck eingestellt sind.
--accesslevel=* --mqttport=1883 --mqttjson --mqtthost=IpAdresseMQTTSERVER --mqtttopic=ebusd/%circuit/%name
Der MQTTSERVER kann wahlweise der Mosquitto Broker sein, oder der MQTT2_SERVER. Beides wird vermutlich am Raspberry der FHEM Hauptinstanz sein, also die IP-Adresse des Raspberry einsetzen.

{{Hinweis|Nachfolgend wird davon ausgegangen, dass als Vorgabe für mqtttopic ''ebusd'' verwendet wurde. Dies kann geändert werden, es wird aber dringend empfohlen, das mqtttopic in jedem Fall mit ''ebus...'' zu beginnen!}}

=== Vorbereitung und Definition in FHEM ===

Unabhängig von dem konkret genutzten IO-Modul (MQTT2_SERVER oder MQTT2_CLIENT) sollte an diesem '''''vor''''' den nachfolgenden Schritten zunächst das autocreate ausgeschaltet werden. Weiter sollte geprüft werden, ob es bereits MQTT2_DEVICE-Geräte gibt, die Einträge in der readingList enthalten, die vom ebus stammen. Da wir die readingList anschließend mit erweiterten JSON-Optionen erstellen wollen, müssen entweder diese Geräte nach dem Deaktivieren des autocreate am IO gelöscht, oder zumindest die readingList entsprechend bereinigt oder gelöscht werden.

==== Externer Broker ====
Wer bereits den Mosquitto installiert hat und diesen weiter verwenden möchte, dann diese Konfiguration wählen.
### 1a. Broker in FHEM anlegen ###
define MQTT_via_mosquitto MQTT2_CLIENT 127.0.0.1:1883
attr MQTT_via_mosquitto room MQTT2_DEVICE,System
==== FHEM-Interner Server ====
Wer keinen Mosquitto installiert hat kann diese Konfiguration wählen. Dazu wird einfach der MQTT2-SERVER definiert.

### 1b. oder MQTT Server anlegen ###
define ebusMQTT MQTT2_SERVER 1883 global
attr ebusMQTT room MQTT2_SERVER

==== "ebus-Bridge" ====
Nun wird noch ein Device benötigt, welcher mit einem der oben genannten Module kommuniziert und das Filter (bridgeRegexp) für den eBus beinhaltet. Auf Basis dieses Device werden später alle ankommenden JSON Telegramme vom eBus Dämon automatisch als Reading angelegt.

### 2. MQTT_Device definieren
define MQTT2_ebusd MQTT2_DEVICE ebusd
attr MQTT2_ebusd IODev ebusMQTT
attr MQTT2_ebusd room MQTT2_DEVICE

Es kann auch ein ggf. vom MQTT2_SERVER bereits automatisch angelegtes Device genutzt werden, bei Verwendung von MQTT2_CLIENT sollte das Device wie oben dargestellt manuell erstellt werden; es ist dabei darauf zu achten, dass die CID dem Basispfad des Topic-trees entspricht, der bei der Konfiguration des ebus-Dämons verwendet wurde.

Auf das Device MQTT2_ebusd wird nun folgendes Template angwendet:

[[Bild:MQTT2_1template E_00 installieren.png|400px|thumb|left|Template E_00_eBus_daemon_splitter]]
<div style="clear:both;"></div>

[[Bild:MQTT2_2splitter.png|400px|thumb|left|Eingabe im Splitter aendern]]
<div style="clear:both;"></div>

Gibt es noch keine readingList mit ebus-spezifischen Einträgen, erscheint ein Fenster. In diesem kann der Name ausgewählt werden, gebt hier anstatt DEV_ID „ebus“ ein und drückt „ok“

Zur Kontrolle bitte prüfen ob hier auch die „bridgeRegexp“ vom Template richtig gesetzt wurde.

[[Bild:MQTT2_3Attribute_ebusd.png|400px|thumb|left|bridgeRegexp prüfen]]

<div style="clear:both;"></div>
(ebus..*?)/(bai|\d+|cc|e7f|ehp|f\d\d|hc|he.|hmu|hwc|mc|mc.\d|omu|omu.\d|pms|rcc|rcc.\d|sc|sdr_p|ui|uih|v\d\d|v81.\d|vd\d|vl\d|vr_\d\d|zeo)/.*:.* "$1_$2"
(ebus..*?)/(global|broadcast|general|scan([^/]*))/.*:.* "$1"

Nach der Konfiguration des bridge-Devices muß autocreate am IO-Device wieder aktiviert werden. Da hierbei die vom ebus-Dämon gesendeten JSON-Informationen in vielen Installationen nur sinnvoll genutzt werden können, wenn die Statusmeldungen jeweils getrennt dargestellt werden, setzen wir auf dem MQTT2_SERVER oder dem MQTT2_CLIENT ( je nachdem welcher verwendet wurde) das Attribut „autocreate“ auf „complex“.

[[Bild:MQTT2_4autocreate-complex.png|400px|thumb|left|autocreate auf complex setzen]]

<div style="clear:both;"></div>

Complex hat den Sinn, das JSONMAP mit dem Namen des Readings automatisch gesetzt wird.
Statt dem Reading 0_value wird daraus dann ein Stautus01_0_value. Dies ist gerade bei den Statusmeldungen wichtig, da sie sich sonst mit gleichem Readingnamen gegenseitig überschreiben.

Nun heißt es etwas zurück lehnen und warten bis die MQTT Telegramme vom eBus eingetroffen sind, das kann einige Minuten dauern. Dabei wird in der Regel sowohl die readingList am Device ''MQTT2_ebusd'' erweitert, wie auch ein oder mehrere neue MQTT2_DEVICE-Geräte angelegt.

==== myUtils-Code ====
Nun benötigen wir noch etwas Code für die Balkendarstellung in FHEM. Dieser Code wird in die 99_myUtils.pm kopiert.
<syntaxhighlight lang="php">
sub Balkenanzeige($)
{
# Zuweisung der übergebenen Variablen
my ($val) = @_;
# Konfiguration des maximal übergebenen Werts (hier wäre der höchste zu erwartende Wert = 3)
my $maxValue = 70;
# Normalisierung auf 100%-Wert
my $percent = $val / $maxValue * 100;
# Definition des valueStyles
my $stylestring = 'style="'.
'width: 200px; '.
'text-align:center; '.
'border: 1px solid #ccc ;'.
'background-image: -webkit-linear-gradient(left,red '.$percent.'%, rgba(0,0,0,0) '.$percent.'%); '.
'background-image: -moz-linear-gradient(left,blue '.$percent.'%, rgba(0,0,0,0) '.$percent.'%); '.
'background-image: -ms-linear-gradient(left,red '.$percent.'%, rgba(0,0,0,0) '.$percent.'%); '.
'background-image: -o-linear-gradient(left,red '.$percent.'%, rgba(0,0,0,0) '.$percent.'%); '.
'background-image: linear-gradient(left,red '.$percent.'%, rgba(0,0,0,0) '.$percent.'%);"';
# Rückgabe des definierten Strings
return $stylestring;
}
</syntaxhighlight>

Ebenfalls muss noch das Modul Color.pm ordnungsgemäß eingebunden werden. Dieses Modul wird zur farbigen Darstellung wie es in den Templates verwendet wird benötigt.
define colorInit notify global:INITIALIZED {use Color}

==== Regelmäßige Werteabfrage ====

Es kann aber in der Zwischenzeit noch die Timer gesteuerte Abfrage definiert werden.

defmod get_ebus_updates at +*00:15:00 set ebusMQTT publish ebusd/430/Hc1HeatCurve/get;
set ebusMQTT publish ebusd/430/HwcTempDesired/get;
set ebusMQTT publish ebusd/bai/WaterPressure/get;
set ebusMQTT publish ebusd/bai/FlowTemp/get;
set ebusMQTT publish ebusd/bai/ReturnTemp/get;
set ebusMQTT publish ebusd/bai/FanSpeed/get;
set ebusMQTT publish ebusd/bai/WPPWMPower/get;
set ebusMQTT publish ebusd/bai/OutdoorstempSensor/get;
set ebusMQTT publish ebusd/bai/Status02/get
set ebusMQTT publish ebusd/bai/FanHours/get
set ebusMQTT publish ebusd/bai/HcHours/get
set ebusMQTT publish ebusd/bai/HwcHours/get
set ebusMQTT publish ebusd/bai/HwcStarts/get

Diese „get“ sind nur Beispiele, wer weitere Readings abfragen möchte einfach die Liste in der FHEM Eingabe erweitern. Ebenfalls kann der Timer auf persönliche Bedürfnisse angepasst werden.

=== ebus-Spezifische weitere Templates ===
==== Installation ====

Um die eBus Templates benutzen zu können, müssen sie erst im Verzeichnis „/opt/fhem/FHEM/lib/AttrTemplate“ installiert werden. Hier kann das Mustertemplate „{{Link2Forum|Topic=79600|LinkText=mqtt2.ebus.template}}“ herunter geladen werden. Dieses Template dann in das Verzeichnis kopieren.
Vor der erstmaligen Benutzung muss dieses template noch Initialisiert werden, sonst wird es in der Templateliste nicht angezeigt.

{{Randnotiz|RNTyp=r|RNText=Bitte das Template immer aus dem richtigen Device (zB: MQTT2_ebusd_430 für die Heizkurve) installieren, ansonsten wird das Reading des Device nicht gefunden bzw. falsch zugeordnet.}}

[[Bild:MQTT2_7templateinitialize.png|400px|thumb|left|vor der ersten Benutzung in der Eingabezeile eingeben]]

<div style="clear:both;"></div>
Dazu in der FHEM Eingabezeile eingeben:
{ AttrTemplate_Initialize() }

==== Anwendung der Templates ====

Wenn bereits die ersten Messwerte eingetroffen sind und die Devices mit den Readings angelegt wurden, können die Templates angelegt werden. D.h. in der Templateliste das gewünschte auswählen (hier MQTT2_ebusd_bai). Die eBus Templates beginnen alle mit E….

[[Bild:MQTT2_8templateselect.png|400px|thumb|left|Das gewünschte Template auswählen, die Readings müssen allerdings in diesem Device enthalten sein]]

<div style="clear:both;"></div>
Hier wird E_07_eBus_bai_Status01+Status02_HWC gewählt.

<div style="clear:both;"></div>
[[Bild:MQTT2_5statustemplate.png|400px|thumb|left|Das Template hat die gewünschte Konfiguration in FHEM durchgeführt]]

[[Bild:MQTT2_6status1template.png|400px|thumb|left|Ergebnis des Template, Heizkurve und Warmwassertemperatur]]
Hier das Ergebnis von HC1HeatCurve+HWCTempDesired

<div style="clear:both;"></div>

==== Muster Templates ====

Es sind auch noch einige Mustertemplates vorhanden die auf Basis von readingsGroup erstellt wurden und ein farbiges Design besitzen. Diese Templates werden nicht im Device, sondern im Room „eBus“ angelegt.
Der Kreativität der Anwender sind hier fast keine Grenzen gesetzt, die Werkzeuge sind vorhanden.

Achtung: die hier gewählte Nummerierung kann sich im Laufe der Zeit ändern, da die Templates öfters erweitert/geändert werden.

Template: E_05_eBus_bai_readingsgroup_Set_Hcurve_Hotwater
[[Bild:MQTT2_ebusset.png|250px|thumb|left|Set hcurve und HWCtemdesired]]
<div style="clear:both;"></div>

Template: E_01_eBus_bai_readingsgroup_Status01
[[Bild:MQTT2_ebustemp.png|250px|thumb|left|Statusmeldung als Readingsgroup]]

<div style="clear:both;"></div>

Template: E_02_eBus_bai_readingsgroup_Status01_Balken
[[Bild:MQTT2_ebustempbalken.png|400px|thumb|left|EStatusmeldung als Readingsgroup mit Balkenanzeige]]

<div style="clear:both;"></div>
Template: E_03_eBus_bai_readingsgroup_Status02
[[Bild:MQTT2_ebuswarmwasser.png|250px|thumb|left|Statusmeldung als Readingsgroup]]

<div style="clear:both;"></div>

Template: E_04_eBus_bai_readingsgroup_Status02_Balken
[[Bild:MQTT2_ebuswarmwasserbalken.png|400px|thumb|left|Statusmeldung als Readingsgroup mit Balkenanzeige]]

<div style="clear:both;"></div>

Template: hier noch einige Beispiel Templates die mit devStateIcon erzeugt wurden.
[[Bild:MQTT2_devStateIcon.png|400px|thumb|left|Templates auf Basis devStateIcon]]

<div style="clear:both;"></div>

==== Templates erweitern ====

Die Templates können vom User selbst leicht erweitert werden. Dies kann entweder im fertigen "define/defmod" oder aber auch im Template vorgenommen werden.

Als Beispiel erweitern wir hier die readingsgroup "eBusset" um die Temperatur zur Nachtabsenkung.

<>,<Name>,< Ist>,<      Soll>
MQTT2_ebusd_430:<%message_tendency_steady>,<Heizkurve>,Hc1HeatCurve_curve_value,<sollcurve>
MQTT2_ebusd_430:<%sani_water_hot>,<Warmwasser>,HwcTempDesired_temp1_value,<sollwater>
MQTT2_ebusd_430:<%temp_temperature_min>,<Nachtabsenkung>,Hc1NightTemp_temp1_value,<sollnight>
Dazu erweitern wir als erstes hier die letzte Zeile der Definition

{'eBusSet.sollcurve'=>'Hc1HeatCurve_curve_value:uzsuDropDown,0.20,0.70,0.90,1.00,1.10,1.20,1.30,1.40,1.50,1.60,1.70',
'eBusSet.sollwater'=>'HwcTempDesired_temp1_value:uzsuDropDown,50.0,51.0,52.0,53.0,54.0,55.0,56.0,57.0,58.0,59.0,60.0',
'eBusSet.sollnight'=>'Hc1NightTemp_temp1_value:uzsuDropDown,10.0,11.0,12.0,13.0,14.0,15.0,15.5,16.0,16.5,17.0,17.5,18.0,18.5,19.0,19.5,20.0,20.5,21.0,21.5,22.0'}
dann die Sollwertvorgabe um die Hc1NightTemp_temp1_value mit den Vorgaben

{'Hc1HeatCurve_curve_value' => '{"style=\"color:\x23".substr(Color::pahColor(5,10,15,$VALUE*10,0),0,6)."\""}',
'HwcTempDesired_temp1_value' => '{"style=\"color:\x23".substr(Color::pahColor(20,40,60,$VALUE,0),0,6)."\""}',
'Hc1NightTemp_temp1_value' => '{"style=\"color:\x23".substr(Color::pahColor(10,15,20,$VALUE,0),0,6)."\""}'}
und schließlich wird noch die dynamische Farbgebung des Sollwertes angepasst.

set ebusMQTT publish ebusd/430/Hc1NightTemp/get;
damit auch der Messwert abgefragt wird, muss noch ein Eintrag im EBUS.TIMER dazu gehängt werden.
[[Bild:MQTT2_Nighttemp.png|400px|thumb|left|Nachtabsenkung Sollwert über readingsgroup]]
Nach Erweiterung der 3 Zeilen sieht das dann so aus.

<div style="clear:both;"></div>

=Weiterführende Links=
Diskussionsthread aus dem Forum:
*{{Link2Forum|Topic=97989|LinkText=ebusd.mqtt2.template: Fragen, Anregungen}}
*{{Link2Forum|Topic=79600|LinkText=Läuft: MQTT2 Teil3 Realisierung mit MQTT2_Client mit oder ohne Mosquitto}}
*{{Link2Forum|Topic=91394|LinkText=zigbee2mqtt mit MQTT2_SERVER und MQTT2_DEVICE}}
*{{Link2Forum|Topic=97989|LinkText=ebusd.mqtt2.template: Fragen, Anregungen}}

[[Kategorie:Other Components]]
[[Kategorie:Heizungssteuerung]]
[[Kategorie:Interfaces]]

AutoShuttersControl

2019-07-29T20:13:52Z

TomLee: /* readingsGroup für die Beschattung */

{{Baustelle}}
{{Infobox Modul
|ModPurpose=Steuerung von Rollläden
|ModCategory=Automatisierung
|ModType=d
|ModForumArea=Automatisierung
|ModTechName=73_AutoShuttersControl.pm
|ModOwner=CoolTux ({{Link2FU|13684|Forum}}/[[Benutzer Diskussion:CoolTux|Wiki]])}}

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

== Basics ==
{{Hinweis|Das Modul befindet sich derzeit noch in der Entwicklung; der jeweils aktuelle Stand ist diesem {{Link2Forum|Topic=90751|LinkText="Thread im Forum"}} zu entnehmen.}}
Zur Nutzung des Moduls sollten folgende andere FHEM-Devices vorhanden sein:
* Rollläden
* Fensterkontakte und
* Bewohnerstatus auf Basis von Residents/Roomates in englisch. Ersatzweise andere Devices, z.B. Dummys, welche als ''state'' ''home'', ''asleep'', ''gotosleep'' und ''awoken'' setzen sowie ein Reading ''lastState''.
* Optional:
** Ein Helligkeitssensor (Steuerung nach Helligkeit und Beschattung)
** Ein Device zur Bestimmung des Sonnenstands (nur für Beschattung). Unterstützt werden derzeit [[Modul Astro|Astro]] und [[Twilight]]<ref>Dabei müssen ggf. in [[Global|global]] auch Angaben zu ''longitude'' und ''latitude'' vorhanden sein</ref>.
** Wenn Feiertage berücksichtigt werden sollen: Ein oder mehrere {{Link2CmdRef|Anker=holiday2we|Lang=en|Label=holiday2we}}-Angaben in [[Global|global]] samt entsprechender [[Wochenende, Feiertage und Schulferien#Feiertage mittels holiday-Datei|holiday]]-Dateien<ref>Es kann auch z.B. ein Dummy-Device verwendet werden, dieses sollte dann aber neben dem eigentlichen Feiertags-''state'' auch in einem Reading ''tomorrow'' Angaben zu anstehenden Feiertagen enthalten.</ref> <ref>Bitte verfahren Sie entsprechend, wenn Urlaubs- oder Ferientage wie Feiertage behandelt werden sollen.</ref>.

Die Einrichtung des Moduls bzw. dessen Funktionalität erfolgt in mehreren Schritten:
* Definition des ASC-Devices
* Einstellung zentraler Vorgaben am ASC-Device
* Markieren der zukünftig zu steuernden Rollladen-Devices
* Einbinden der Rollladen-Devices in das ASC-Device
* Einstellen der individuellen Vorgaben je Rollladen (am Rollladen-Device)
Dabei geht man am einfachsten schrittweise vor und erweitert die Funktionalität nach und nach um die gewünschten Funktionen. Dann benötigt man jeweils nur einen kleinen Teil der vielen per Attribut einstellbaren Optionen, und kann die Auswirkungen der jeweiligen Änderung besser nachvollziehen.

== Einrichtung ==
{{Hinweis|ASC kann auch verwendet werden, um lediglich Teilaufgaben der Rollladensteuerung zu erfüllen, also z.B. nur das morgendliche Öffnen der Rollläden. Allerdings geht dabei ein erheblicher Teil des Komforts verloren, der dadurch entsteht, dass die Steuerung innerhalb der vollintegrierten Lösung jeweils nachvollzieht, aus welchem Grund eine Fahrt erfolgt war und dies ggf. bei der nächsten Aktion berücksichtigt.}}

=== Vorbereitung ===
Zunächst sollten die in den [[#Basics|Basics]] beschriebenen Geräte vorhanden und funktionsfähig sein.

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

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

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

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

Aus dieser Vorgabe leitet das Modul dann jeweils bestimmte Voreinstellungen (''defaults'') für den Rolladen ab, ohne dass die betreffenden, dafür vorgesehenen Attribute ausdrücklich gesetzt werden müssen. Es genügt daher, nur jeweils die Einstellungen zu verändern, die anders gewünscht werden oder für den Rollladenaktortyp anders sein müssen (z.B. ''dim 99'' für vollständiges Öffnen eines ZWave-Aktors).
{{Hinweis|Das Vorstehende gilt jeweils für den nicht-invertierten Modus! Wer z.B. ein HomeMatic-Gerät mit ''levelinverse'' betreibt, sollte ''ASC'' auf "1" setzen usw.. Maßgeblich ist letztlich nur die Frage, ob die Offen-Positionsangabe nummerisch kleiner oder größer als die Geschlossen-Positionsangabe ist; die konkreten Zahlenwerte spielen dabei keine Rolle, die Angabe ''position'' oder ''pct'' kann auch später über ein weiteres Attribut passend eingestellt werden.}}

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

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

== Readings ==

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

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

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

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

==set- und get-Befehle für das ASC-Device==

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

=== get-Anweisungen ===

{|class="wikitable"
|-
! Name !! Beschreibung
|-
| showShuttersInformations ||zeigt eine Übersicht der Automatik-Fahrzeiten
|-
| showNotifyDevsInformations ||zeigt eine Übersicht der abgelegten NOTIFYDEV Struktur. Dient zur Kontrolle
|}
== Attribute ==
{{Hinweis|Die Attributnamen haben sich teilweise geändert, nachfolgend ist noch ein Stand vor Modulversion 0.6.5.x wiedergegeben. Die aktuellen Benennungen sind der Commandref zu entnehmen.}}
{{Hinweis|In der commandref findet sich häufig die Schreibweise <code>ASC_BrightnessSensor Sensorname[:brightness [400:800]]</code>. Dabei sind die Angaben in den eckigen Klammern optional. Dies müssen also nicht angegeben werden, stattdessen verwendet das Modul dann Standardwerte (siehe cref), die in der cref zu findenden Angaben entsprechen dabei den defaults. Werden Werte angegeben, sind die eckigen Klammern '''wegzulassen'''! Beispiel: <code>ASC_BrightnessSensor hm_motion_1 70:100</code> würde das brightness-Reading des Sensors hm_motion_1 verwenden und einen morgendlichen Schwellenwert von 70 bzw. 100 für abends.}}
===Attribute direkt am ASC-Device ===

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

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

{|class="wikitable"
|-
! Name !! Datentyp/<BR/>Wertebereich !! Default-Wert !! Beschreibung
|-
|ASC || 0, 1, 2|| ||0 = "kein Anlegen der Attribute beim ersten Scan bzw. keine Beachtung eines Fahrbefehles",1 = "Inverse oder Rollo - Bsp.: Rollo Oben 0, Rollo Unten 100 und der Befehl zum prozentualen Fahren ist position",2 = "Homematic Style - Bsp.: Rollo Oben 100, Rollo Unten 0 und der Befehl zum prozentualen Fahren ist pct
|-
|ASC_Antifreeze || soft, am, pm, hard, off|| ||Frostschutz, wenn ''soft'' fährt der Rollladen in die ''ASC_Antifreeze_Pos'', bei ''hard/am/pm'' wird gar nicht oder innerhalb der entsprechenden Tageszeit nicht gefahren
|-
|ASC_Antifreeze_Pos || || ||Position, die angefahren werden soll, wenn der Fahrbefehl komplett schließen lautet, aber der Frostschutz aktiv ist
|-
|ASC_AutoAstroModeEvening ||REAL, CIVIL, NAUTIC, ASTRONOMIC, HORIZON || ||aktuell REAL,CIVIL,NAUTIC,ASTRONOMIC
|-
|ASC_AutoAstroModeEveningHorizon || || ||Höhe über Horizont, wenn beim Attribut ''ASC_autoAstroModeEvening'' ''HORIZON'' ausgewählt ist
|-
|ASC_AutoAstroModeMorning ||REAL, CIVIL, NAUTIC, ASTRONOMIC, HORIZON || ||aktuell REAL,CIVIL,NAUTIC,ASTRONOMIC
|-
|ASC_AutoAstroModeMorningHorizon || || ||Höhe über Horizont, wenn beim Attribut ''ASC_autoAstroModeMorning'' ''HORIZON'' ausgewählt ist
|-
|ASC_Closed_Pos || || ||in 10er Schritten von 0 bis 100,default Vorgabe ist abhängig vom Attribut ''ASC''
|-
|ASC_Down || astro, time, brightness || ||bei ''astro'' wird Sonnenuntergang berechnet, bei ''time'' wird der Wert aus ''ASC_Time_Down_Early'' als Fahrzeit verwendet und bei ''brightness'' muss ''ASC_Time_Down_Early'' und ''ASC_Time_Down_Late'' korrekt gesetzt werden. Der Timer läuft dann nach ''ASC_Time_Down_Late''-Zeit,es wird aber in der Zeit zwischen ''ASC_Time_Down_Early'' und ''ASC_Time_Down_Late'' geschaut, ob die als Attribut im Moduldevice hinterlegte ''ASC_brightnessMinVal'' erreicht wurde. Wenn ja, wird der Rolladen runter gefahren
|-
|ASC_Mode_Down ||always, home, absent, off || ||wann darf die Automatik herunterfahren. immer, niemals oder bei Abwesenheit des Roommate (ist kein Roommate und ''absent'' eingestellt, wird gar nicht gesteuert)
|-
|ASC_Mode_Up ||always, home, absent, off || ||wann darf die Automatik hochfahren. immer, niemals oder bei Abwesenheit des Roommate (ist kein Roommate und ''absent'' eingestellt, wird gar nicht gesteuert)
|-
|ASC_Drive_Offset || || ||maximale zufällige Verzögerung in Sekunden bei der Berechnung der Fahrzeiten, ''0'' bedeutet sofort, ''-1'' bedeutet, dass das gleichwertige Attribut aus dem ASC-Device ausgewertet werden soll
|-
|ASC_Open_Pos || || ||in 10er-Schritten von 0 bis 100, default Vorgabe ist abhängig vom Attribut ''ASC''
|-
|ASC_Partymode || on, off || ||schaltet den Partymodus an oder aus. Wird dann am ASC Device ''set <ASC-DEVICE> partyMode on'' geschaltet, werden alle Fahrbefehle an den Rollläden, welche das Attribut auf ''on'' haben, zwischengespeichert und erst später ausgeführt
|-
|ASC_Pos_Reading || || ||Name des Readings, welches die Position des Rollladen in Prozent angibt. Wird bei unbekannten Device-Typen auch als ''set'' Befehl zum Fahren verwendet
|-
|ASC_Pos_after_ComfortOpen || || ||in 10er-Schritten von 0 bis 100, default Vorgabe ist abhängig vom Attribut ''ASC''
|-
|ASC_Roommate_Reading || || ||Reading des Roommate-Device, welches den Status wieder gibt
|-
|ASC_Roommate_Device || || ||mit Komma getrennte Namen des/der Roommate-Device/s welche den/die Bewohner des Rollladen-Raumes wiedergibt. Macht nur Sinn in Schlaf- oder Kinderzimmern
|-
|ASC_Time_Down_Early || || ||Sunset früheste Zeit zum Runterfahren
|-
|ASC_Time_Down_Late || || ||Sunset späteste Zeit zum Runterfahren
|-
|ASC_Time_Up_Early || || ||Sunrise früheste Zeit zum Hochfahren
|-
|ASC_Time_Up_Late || || ||Sunrise späteste Zeit zum Hochfahren
|-
|ASC_Time_Up_WE_Holiday || || ||Sunrise früheste Zeit zum Hochfahren am Wochenende und/oder Urlaub (holiday2we wird beachtet).
|-
|ASC_Up || astro, time, brightness || ||bei ''astro'' wird Sonnenaufgang berechnet, bei ''time'' wird der Wert aus ''ASC_Time_Up_Early'' als Fahrzeit verwendet und bei ''brightness'' müssen ''ASC_Time_Up_Early'' und ''ASC_Time_Up_Late'' korrekt gesetzt werden. Der Timer läuft dann nach ''ASC_Time_Up_Late''-Zeit, es wird aber in der Zeit zwischen ''ASC_Time_Up_Early'' und ''ASC_Time_Up_Late'' geschaut, ob die als Attribut im Moduldevice hinterlegte ''ASC_brightnessMinVal'' erreicht wurde. Wenn ja, wird der Rolladen runter gefahren
|-
|ASC_Ventilate_Pos || || ||in 10er-Schritten von 0 bis 100, default Vorgabe ist abhängig vom Attribut ''ASC''
|-
|ASC_Ventilate_Window_Open || || ||auf lüften, wenn das Fenster gekippt/geöffnet wird und aktuelle Position unterhalb der Lüften-Position ist
|-
|ASC_WindowRec || || ||Name des Fensterkontakts, an welchen Fenster der Rollladen angebracht ist. Sein Reading ''state'' muss die Werte ''open'', ''closed'' oder ''tilted'' enthalten.
|-
|ASC_WindowRec_subType || || ||Typ des verwendeten Fensterkontakts: ''twostate'' (optisch oder magnetisch) oder ''threestate'' (Drehgriffkontakt)
|-
|ASC_LockOut || soft, hard || ||stellt entsprechend den Aussperrschutz ein. Bei global aktiven Aussperrschutz (''set ASC-Device lockOut soft'') und einem Fensterkontakt ''open'' bleibt dann der Rolladen oben. Dies gilt nur bei Steuerbefehle über das ASC-Modul. Stellt man global auf ''hard'', wird bei entsprechender Möglichkeit versucht, den Rollladen hardwareseitig zu blockieren. Dann ist auch ein Fahren über die Taster nicht mehr möglich.
|-
|ASC_LockOutCmd || inhibit, blocked || ||set Befehl für das Rolladen-Device zum Sperren per Hardware. Der Befehl wird verwendet, wenn ''ASC_LockOut'' auf ''hard'' gesetzt ist
|-
|ASC_Self_Defense_Exclude || on, off || ||bei ''on'' wird dieser Rolladen bei aktiven ''selfDefence'' und offenen Fenster nicht runter gefahren, wenn Residents absent ist
|-
|ASC_Shading_Brightness_Sensor || || ||Sensor-Device, welches für die Lichtwerte verwendet wird. ACHTUNG! Findet auch Verwendung bei ASC_Down - brightness
|-
|ASC_BrightnessMinVal || || ||minimaler Lichtwert, bei dem Schaltbedingungen noch geprüft werden sollen / wird der Wert von ''-1'' nicht geändert, so wird automatisch der Wert aus dem Moduldevice genommen
|-
|ASC_BrightnessMaxVal || || ||maximaler Lichtwert, bei dem Schaltbedingungen noch geprüft werden sollen / wird der Wert von ''-1'' nicht geändert, so wird automatisch der Wert aus dem Moduldevice genommen
|-
|ASC_ShuttersPlace || window, terrace || ||wenn dieses Attribut auf ''terrace'' gesetzt ist und das Residents-Device in den Status ''gone'' geht und ''selfDefence'' aktiv ist, wird das Rollo geschlossen
|-
|ASC_WiggleValue || || ||Wert, um welchen sich die Position des Rollladens bei ''Wiggle'' ändern soll
|-
|ASC_BlockingTime_afterManual || || ||Wartezeit in Sekunden, die die Automatik nach einer manuellen Fahrt aussetzen soll
|-
|ASC_BlockingTime_beforNightClose || || ||Vorgabezeit in Sekunden, innerhalb derer vor dem nächtlichen Schließen keine Öffnen-Fahrt mehr ausgeführt werden soll
|-
|ASC_BlockingTime_beforDayOpen || || ||Vorgabezeit in Sekunden, innerhalb derer vor dem morgendlichen Öffnen keine Schließen-Fahrt mehr ausgeführt werden soll
|-
|ASC_Shading_Direction || || ||Position in Grad, auf der das Fenster liegt - genau Osten wäre 90, Süden 180 und Westen 270
|-
|ASC_Shading_Pos || || ||Position des Rollladens für die Beschattung
|-
|ASC_Shading_Angle_Left || || ||Vorlaufwinkel im Bezug zum Fenster, ab wann abgeschattet wird. Beispiel: Fenster 180° - 85° ==> ab Sonnenpos. 95° wird abgeschattet
|-
|ASC_Shading_Angle_Right || || ||Nachlaufwinkel im Bezug zum Fenster, bis wann abgeschattet wird. Beispiel: Fenster 180° + 85° ==> bis Sonnenpos. 265° wird abgeschattet
|-
|ASC_Shading_Mode || || ||absent,always,off,home / Vorgabe, wann Beschattungsaktionen durchzuführen sind
|-
|ASC_Shading_StateChange_Sunny || || ||Brightness Wert ab welchen Beschattung statt finden soll, immer in Abhängikkeit der anderen einbezogenden Sensorwerte
|-
|ASC_Shading_StateChange_Cloudy || || ||Brightness Wert ab welchen die Beschattung aufgehoben werden soll, immer in Abhängikkeit der anderen einbezogenden Sensorwerte
|-
|ASC_Shading_Min_Elevation || || ||ab welcher Höhe des Sonnenstandes soll beschattet werden, immer in Abhängikkeit der anderen einbezogenden Sensorwerte
|-
|ASC_Shading_Min_OutsideTemperature || || ||ab welcher Temperatur soll Beschattet werden, immer in Abhängikkeit der anderen einbezogenden Sensorwerte
|-
|ASC_Shading_WaitingPeriod || || ||wie viele Sekunden soll gewartet werden bevor eine weitere Auswertung der Sensordaten für die Beschattung statt finden soll
|-
|ASC_PrivacyDownTime_beforNightClose || || ||wie viele Sekunden vor dem abendlichen schlie&zlig;en soll der Rollladen in die Sichtschutzposition fahren, -1 bedeutet das diese Funktion unbeachtet bleiben soll
|-
|ASC_PrivacyDown_Pos || || ||Position den Rollladens für den Sichtschutz
|-
| || || ||
| || || ||
|-
| || || ||
|-
| || || ||
|-
| || || ||
|}

== Hilfsmittel ==
{{Hinweis|Die Device-Namen sind auf die eigene Installation anzupassen.}}

=== Interne Übersicht ===
[[Bild:ASC Overview.JPG|thumb|right|weblink - Beispiel]]
<pre style="width:65%;word-break: break-all;word-wrap: break-word;">
define ASC_Jalousie_Info weblink htmlCode {AutoShuttersControl::GetShuttersInformation($defs{'JalousieControl'})}
</pre>

{{Hinweis|Codezeilen sind im [[Import von Code Snippets|RAW]]-Format.}}

=== readingsGroup für Level ===

{{Randnotiz|RNTyp=g|RNText= Stand 2019-05-03
* Erfolgreich getestet mit Homematic Devices, Beta-User
* Die Farbgebung entspricht dem Standard, wenn unter dem Style f18 der Farbpreset ''light'' gewählt wird.
}}

<pre style="width:65%;word-wrap: break-word;">defmod rg_ASC_Rolllaeden_Level readingsGroup <Gerät>,<Stand>,<Schliessen bis>,<Öffnen auf>,<Beschattung>,<Komfort>,<Lüften>,<Privacy> (Rollladen_.*|Jalousie_.*)..:level,!?ASC_Closed_Pos,!?ASC_Open_Pos,!?ASC_Shading_Pos,!?ASC_ComfortOpen_Pos,!?ASC_Ventilate_Pos,!?ASC_PrivacyDown_Pos
attr rg_ASC_Rolllaeden_Level commands {level => 'pct:selectnumbers,0,5,100,0,lin',\
ASC_Closed_Pos => 'ASC_Closed_Pos:selectnumbers,0,5,100,0,lin',\
ASC_Open_Pos => 'ASC_Open_Pos:selectnumbers,0,5,100,0,lin',\
ASC_Shading_Pos => 'ASC_Shading_Pos:selectnumbers,0,5,100,0,lin',\
ASC_Ventilate_Pos => 'ASC_Ventilate_Pos:selectnumbers,0,5,100,0,lin',\
ASC_ComfortOpen_Pos => 'ASC_ComfortOpen_Pos:selectnumbers,0,5,100,0,lin',\
ASC_PrivacyDown_Pos => 'ASC_PrivacyDown_Pos:selectnumbers,0,5,100,0,lin'}
</pre>

=== readingsGroup für Zeiten ===
[[Bild:ReadingsGroup ASC times.png|thumb|right|ReadingsGroup - Zeitenbeispiel]]
<pre style="width:65%;word-wrap: break-word;">defmod rg_ASC_Rolllaeden_Times readingsGroup <Gerät>,<Position>,<Time_Up_Early>,<Time_Up_Late>,<Time_Up_WE/Hol>,<Time_Down_Early>,<Time_Down_Late>,<Mode_Down>,<Mode_Up> \
(.*Rollo.*|.*Rollladen|Jalousie_.*):level,!?ASC_Time_Up_Early,!?ASC_Time_Up_Late,!?ASC_Time_Up_WE_Holiday,!?ASC_Time_Down_Early,!?ASC_Time_Down_Late,!?ASC_Mode_Down,!?ASC_Mode_Up
attr rg_ASC_Rolllaeden_Times commands {level => 'pct:0,10,20,30,35,40,45,50,55,60,65,70,75,80,85,90,95,100', \
ASC_Time_Down_Early => 'ASC_Time_Down_Early:15:00,15:15,15:30,15:45,16:00,16:15,16:30,16:45,17:00,17:15,17:30,17:45,18:00,18:15,18:30,18:45,19:00,19:15,19:30,19:45,20:00,20:15,20:30,20:45,21:00,21:15,21:30,21:45,22:00', \
ASC_Time_Down_Late => 'ASC_Time_Down_Late:19:00,19:15,19:30,19:45,20:00,20:15,20:30,20:45,21:00,21:15,21:30,21:45,22:00,22:15,22:30,22:45,23:00,23:15,23:30', \
ASC_Time_Up_WE_Holiday => 'ASC_Time_Up_WE_Holiday:06:00,06:15,06:30,06:45,07:00,07:15,07:30,07:45,08:00,08:15,08:30,08:45,09:00,09:15,09:30,09:45,10:00',\
ASC_Time_Up_Early => 'ASC_Time_Up_Early:05:00,05:05,05:30,05:55,06:00,06:15,06:30,06:45,07:00,07:15,07:30,07:45,08:00,08:15,08:30,08:45,09:00,09:15,09:30,09:45,10:00', \
ASC_Time_Up_Late => 'ASC_Time_Up_Late:06:00,06:15,06:30,06:45,07:00,07:15,07:30,07:45,08:00,08:15,08:30,08:45,09:00,09:15,09:30,09:45,10:00', \
ASC_Mode_Down => 'ASC_Mode_Down:always,absent,off', \
ASC_Mode_Up => 'ASC_Mode_Up:always,absent,off' }
attr rg_ASC_Rolllaeden_Times room Rollladen</pre>

[[Bild:ASC RG Zeiten HM ZWave Siro.png|thumb|right|ReadingsGroup - CUL_HM+ZWave+Siro mit widgets]]Neue Version mit time-Widgets und pct/dim/position-widget (5-er Schritte), passend für CUL_HM, ZWave und Siro-Geräte:
<pre style="width:65%;word-wrap: break-word;">defmod rg_ASC_Rolllaeden_Times readingsGroup <Gerät>,<Stand>,<Time_Up_Early >,<Time_Up_WE >,<Time_Up_Late >,<Time_Down_Early>,<Time_Down_Late>,<Mode_Down>,<Mode_Up> (Rollo_.*|Jalousie_.*)..:(level|dim|position),!?ASC_Time_Up_Early,!?ASC_Time_Up_WE_Holiday,!?ASC_Time_Up_Late,!?ASC_Time_Down_Early,!?ASC_Time_Down_Late,!?ASC_Mode_Down,!?ASC_Mode_Up
attr rg_ASC_Rolllaeden_Times commands {level => 'pct:selectnumbers,0,5,100,0,lin', \
dim => 'dim:selectnumbers,0,5,99,0,lin',\
position => 'pct:selectnumbers,0,5,99,0,lin',\
ASC_Mode_Down => 'ASC_Mode_Down:always,absent,off',\
ASC_Mode_Up => 'ASC_Mode_Up:always,absent,off',\
ASC_Time_Down_Early => 'ASC_Time_Down_Early:time', \
ASC_Time_Down_Late => 'ASC_Time_Down_Late:time',\
ASC_Time_Up_Early => 'ASC_Time_Up_Early:time', \
ASC_Time_Up_Late =>'ASC_Time_Up_Late:time',\
ASC_Time_Up_WE_Holiday =>'ASC_Time_Up_WE_Holiday:time'}
attr rg_ASC_Rolllaeden_Times room Rollladen
</pre>

=== readingsGroup für die Beschattung ===
[[Bild:ReadingsGroup ASC shading.png|thumb|right|ReadingsGroup - Beschattungsbeispiel]]
<pre style="width:65%;word-wrap: break-word;">
defmod rg_ASC_Rolllaeden_Shading readingsGroup <Gerät>,<Modus>,<Position>,<Richtung>,<°links>,<°rechts>,<Elevation>,<Sunny>,<Cloudy>,<Min Temp> (Rollo|Jalousie)_.*..:!?ASC_Shading_Mode,!?ASC_Shading_Pos,!?ASC_Shading_Direction,!?ASC_Shading_Angle_Left,!?ASC_Shading_Angle_Right,!?ASC_Shading_MinMax_Elevation,!?ASC_Shading_StateChange_Sunny,!?ASC_Shading_StateChange_Cloudy,!?ASC_Shading_Min_OutsideTemperature
attr rg_ASC_Rolllaeden_Shading alias Rollläden: Beschattung
attr rg_ASC_Rolllaeden_Shading commands {ASC_Shading_Pos => 'ASC_Shading_Pos:knob,min:0,max:100,width:50,height:50,fgColor:#FF9900,bgColor:#CCCCCC,step:5,lineCap:round',\
ASC_Shading_Mode => 'ASC_Shading_Mode:always,home,absent,off',\
ASC_Shading_Direction => 'ASC_Shading_Direction:knob,min:0,max:360,width:50,height:50,fgColor:#FF9900,bgColor:#CCCCCC,step:1,cursor:true,lineCap:round',\
ASC_Shading_Angle_Left => 'ASC_Shading_Angle_Left:knob,min:0,max:85,angleArc:85,rotation:anticlockwise,width:50,height:50,fgColor:#FF9900,bgColor:#CCCCCC,step:5,lineCap:round,angleOffset:270',\
ASC_Shading_Angle_Right => 'ASC_Shading_Angle_Right:knob,min:0,max:85,angleArc:85,width:50,height:50,fgColor:#FF9900,bgColor:#CCCCCC,step:5,lineCap:round,',\
ASC_Shading_MinMax_Elevation => 'ASC_Shading_MinMax_Elevation:knob,min:0,max:35,width:50,height:50,fgColor:#FF9900,bgColor:#CCCCCC,step:1,lineCap:round,angleArc:120,angleOffset:270',\
ASC_Shading_StateChange_Sunny => 'ASC_Shading_StateChange_Sunny:knob,min:100,max:40000,angleArc:85,rotation:anticlockwise,width:50,height:50,fgColor:#FF9900,bgColor:#CCCCCC,step:20,lineCap:round,angleOffset:270',\
ASC_Shading_StateChange_Cloudy => 'ASC_Shading_StateChange_Cloudy:knob,min:100,max:40000,angleArc:85,width:50,height:50,fgColor:#FF9900,bgColor:#CCCCCC,step:20,lineCap:round,',\
ASC_Shading_Min_OutsideTemperature => 'ASC_Shading_Min_OutsideTemperature:knob,min:5,max:30,width:50,height:50,fgColor:#FF9900,bgColor:#CCCCCC,step:0.5,lineCap:round,angleArc:120,angleOffset:270'}
attr rg_ASC_Rolllaeden_Shading room Rollladen</pre>
<br>
Anderes {{Link2Forum|Topic=99980|Message=946357|LinkText=Foren-Beispiel}} für eine RG zu Beschattung (für V. 0.6.x):
[[Bild:ReadingsGroup ASC shading2.png|thumb|right|ReadingsGroup - Beschattungsbeispiel]]
<pre style="width:65%;word-wrap: break-word;">
defmod rg_ASC_Shading readingsGroup <Gerät>,<Grad>,<Position>,<Mode>,<Links>,<Rechts>,<Wait>,<ShadeIn>,<ShadeOut>,<Elevation>,<Temperature>,<Device>\
(Rollo_.*|Jalousie.*):!?ASC_Shading_Direction,!?ASC_Shading_Pos,!?ASC_Shading_Mode,!?ASC_Shading_Angle_Left,!?ASC_Shading_Angle_Right,!?ASC_Shading_WaitingPeriod,!?ASC_Shading_StateChange_Sunny,!?ASC_Shading_StateChange_Cloudy,!?ASC_Shading_MinMax_Elevation,!?ASC_Shading_Min_OutsideTemperature,!?ASC_BrightnessSensor\

attr rg_ASC_Shading commands {ASC_Shading_Direction => 'ASC_Shading_Direction:129,255,309',\
ASC_Shading_Pos => 'ASC_Shading_Pos:selectnumbers,0,5,100,0,lin',\
ASC_Shading_Mode => 'ASC_Shading_Mode:absent,always,off,home',\
ASC_Shading_Angle_Left => 'ASC_Shading_Angle_Left:selectnumbers,0,5,100,0,lin',\
ASC_Shading_Angle_Right => 'ASC_Shading_Angle_Right:selectnumbers,0,5,100,0,lin',\
ASC_Shading_WaitingPeriod => 'ASC_Shading_WaitingPeriod:selectnumbers,0,60,1200,0,lin',\
ASC_Shading_StateChange_Sunny => 'ASC_Shading_StateChange_Sunny:selectnumbers,0,20,1000,0,lin',\
ASC_Shading_StateChange_Cloudy => 'ASC_Shading_StateChange_Cloudy:selectnumbers,0,20,1000,0,lin',\
ASC_Shading_MinMax_Elevation =>\
'ASC_Shading_Min_Elevation:selectnumbers,0,1,40,0,lin' ,\
ASC_Shading_Min_OutsideTemperature =>\
'ASC_Shading_Min_OutsideTemperature:selectnumbers,0,1,30,0,lin'}
attr rg_ASC_Shading room Rollladen</pre>

=== readingsGroup für FIBARO Roller Shutter FGR-222 Devices ===
{{Randnotiz|RNTyp=g|RNText=Getestet von majestro84, Stand 2019-01-28.
* https://forum.fhem.de/index.php/topic,92628.msg897099.html#msg897099
* Die Farbgebung entspricht dem Standard, wenn unter dem Style f18 der Farbpreset ''dark'' gewählt wird}}

[[Bild:ASC Jalousien Times.JPG|thumb|right|Beispiel]]
<pre style="width:65%;word-break: break-all;word-wrap: break-word;">define ASC_Jalousien_Times readingsGroup <Gerät>,<Stand>,<Time_Up_Early>,<Time_Up_WE>,<Time_Up_Late>,<Time_Down_Early>,<Time_Down_Late>,<Mode_Down>,<Mode_Up>,<PartyMode>,<LockOut> (.*_Jalousie.*):position,!?ASC_Time_Up_Early,!?ASC_Time_Up_WE_Holiday,!?ASC_Time_Up_Late,!?ASC_Time_Down_Early,!?ASC_Time_Down_Late,!?ASC_Mode_Down,!?ASC_Mode_Up,!?ASC_Partymode,!?ASC_LockOut

attr ASC_Jalousien_Times commands {position => 'dim:0,10,20,30,35,40,45,50,55,60,65,70,75,80,85,90,95,99',
ASC_Mode_Down => 'ASC_Mode_Down:always,absent,off',
ASC_Mode_Up => 'ASC_Mode_Up:always,absent,off',
ASC_Partymode => 'ASC_Partymode:on,off',
ASC_LockOut => 'ASC_LockOut:soft,hard,off',
ASC_Time_Down_Early => 'ASC_Time_Down_Early:15:00,15:15,15:30,15:45,16:00,16:15,16:30,16:45,17:00,17:15,17:30,17:45,18:00,18:15,18:30,18:45,19:00,19:15,19:30,19:45,20:00,20:15,20:30,20:45,21:00,21:15,21:30,21:45,22:00',
ASC_Time_Down_Late => 'ASC_Time_Down_Late:20:15,20:30,20:45,21:00,21:15,21:30,21:45,22:00,22:15,22:30,22:45,23:00,23:15,23:30',
ASC_Time_Up_Early => 'ASC_Time_Up_Early:05:00,05:05,05:30,05:45,06:00,06:15,06:30,06:45,07:00,07:15,07:30,07:45,08:00,08:15,08:30,08:45,09:00,09:15,09:30,09:45,10:00',
ASC_Time_Up_Late =>'ASC_Time_Up_Late:06:00,06:15,06:30,06:45,07:00,07:15,07:30,07:45,08:00,08:15,08:30,08:45,09:00,09:15,09:30,09:45,10:00',
ASC_Time_Up_WE_Holiday => 'ASC_Time_Up_WE_Holiday:06:00,06:15,06:30,06:45,07:00,07:15,07:30,07:45,08:00,08:15,08:30,08:45,09:00,09:15,09:30,09:45,10:00'}
attr ASC_Jalousien_Times room Jalousien</pre>

[[Bild:ASC Jalousien Level.JPG|thumb|right|Beispiel]]
<pre style="width:65%;word-break: break-all;word-wrap: break-word;"> define Jalousien_Level readingsGroup <Gerät>,<Closed_Pos>,<Open_Pos>,<Comfort_Pos>,<Ventilate_Pos>,<PrivacyDown_Pos>,<Shading_Pos> (.*_Jalousie.*):!?ASC_Closed_Pos,!?ASC_Open_Pos,!?ASC_ComfortOpen_Pos,!?ASC_Ventilate_Pos,!?ASC_PrivacyDown_Pos,!?ASC_Shading_Pos
attr Jalousien_Level commands { ASC_Closed_Pos => 'ASC_Closed_Pos:0,10,20,30,35,40,45,50,55,60,65,70,75,80,85,90,95,99',
ASC_Open_Pos => 'ASC_Open_Pos:0,10,20,30,35,40,45,50,55,60,65,70,75,80,85,90,95,99',
ASC_ComfortOpen_Pos => 'ASC_ComfortOpen_Pos:0,10,20,30,35,40,45,50,55,60,65,70,75,80,85,90,95,99',
ASC_Ventilate_Pos => 'ASC_Ventilate_Pos:0,10,20,30,35,40,45,50,55,60,65,70,75,80,85,90,95,99',
ASC_PrivacyDown_Pos => 'ASC_PrivacyDown_Pos:0,10,20,30,35,40,45,50,55,60,65,70,75,80,85,90,95,99',
ASC_Shading_Pos => 'ASC_Shading_Pos:0,10,20,30,35,40,45,50,55,60,65,70,75,80,85,90,95,99'}
attr Jalousien_Level room Jalousien</pre>

== Einrichtungsbeispiel ==
=== Zielsetzung und Vorgaben ===
Es sollen alle Rollläden und Jalousien in einem Haus innerhalb bestimmter zeitlicher Grenzen Morgens und Abends sonnenstandsabhängig gefahren werden, an den Wochenenden und an Ferientagen soll etwas später geöffnet werden. Es sind Tür- und Fensterkontakte vorhanden (Türkontakte: twoState, Fensterkontakte: threeState), wobei bei jeder Öffnung ein eventuell geschlossener Rollladen geöffnet werden soll. Bei allen Rollladenaktoren, Tür- und Fensterkontakten handelt es sich um CUL_HM-Geräte.

=== Vorarbeiten ===
Im global-Device sind Angaben zu latitude und longitude vorhanden, holiday2we wie folgt<ref>''ferien'' ist eine automatisiert erstellte holiday-Datei nach diesem {{Link2Forum|Topic=85759|Message=885883|LinkText=Foren-Beitrag}}.</ref>:
attr global holiday2we bw,ferien
Weitere Angaben benötigen wir zunächst nicht, die Festlegung eines Astro-Devices erfolgt hier erst im Rahmen der Beschattung.
Dann erfolgt das ''Define des ASC-Devices'' wie oben beschrieben:
<code>define Rollladenautomatik AutoShuttersControl</code>
Folgen die einzubindenden Rollladenaktoren einem einheitlichen Namensschema, können diese sodann z.B. mit
attr (Jalousie|Rollladen)_.* ASC 2
auf einen Rutsch mit dem passenden ASC-Typ gekennzeichnet werden. Dann verteilen wir mir
set Rollladenautomatik scanForShutters
die nachfolgend weiter zu bearbeitenden Attribute.
=== Schließen morgens und abends ===
{{Randnotiz|RNTyp=g|RNText=Alternative: Fahren nach brightness:
Will man insgesamt oder nur an einzelnen Rollläden stattdessen helligkeitsgesteuert fahren, muß für jeden Rollladen ein Helligkeitssensor definiert und entweder zentral oder am einzelnen Rollladen jeweils ein Höchst- bzw. Mindestwert festgelegt werden (''ASC_BrightnessMinVal'' etc.), bei dessen Überschreitung geöffnet bzw. Unterschreitung geschlossen werden soll.}}
==== Konfiguration des ASC-Devices ====
Da wir sonnenstandsabhängig Fahrzeiten wollen, legen wir erst einmal fest, dass dies morgens und abends berücksichtigt werden soll:
<pre>
attr Rollladenautomatik ASC_autoAstroModeEvening CIVIL
attr Rollladenautomatik ASC_autoAstroModeMorning CIVIL
attr Rollladenautomatik ASC_autoShuttersControlEvening on
attr Rollladenautomatik ASC_autoShuttersControlMorning on
</pre>
Aus der Angabe ''CIVIL'' und den Vorgaben in den einzelnen Rollladen wird dabei mit Hilfe von [[SUNRISE_EL]] die effektive Fahrzeit berechnet, dort finden sich auch weitere Hinweise, zu den meisten anderen Optionen für die ersten beiden Attribute.
Bei allen Fensteröffnungen soll auf eine Lüften-Position gefahren werden, also schalten wir diese Funktion ebenfalls zentral an<ref>Sonst wird bei threeState-Sensoren nur bei ''tilted'' auf die in ''ASC_Ventilate_Pos'' gefahren.</ref>:
attr Rollladenautomatik ASC_autoShuttersControlComfort on
Zuletzt legen wir noch einen Temperatur-Sensor fest. Dieser wird beim Frostschutz sowie bei der Beschattung berücksichtigt.
<pre>
attr Rollladenautomatik ASC_temperatureSensor Aussentemperatur_Nord
attr Rollladenautomatik ASC_temperatureReading temperature
attr Rollladenautomatik ASC_freezeTemp 3
</pre>

tbd:
* Rain
* Wind
==== Konfiguration der Rollladendevices ====
===== Fahrzeiten =====
Zur Konfiguration der Fahrzeiten bietet es sich an, eine ReadingsGroup zu nutzen, wie unter [[#Hilfsmittel|Hilfsmittel]] dargestellt. Alternativ kann man die Zeiten auch manuell in den einzelnen Rollläden hinterlegen.
===== Bewohner =====
Wird ein Raum von einer oder mehreren bestimmten Person/en bewohnt oder gibt es ein Sammel-Gerät für mehrere Bewohner, kann dies mit den Attributen ''ASC_Roommate_Device'' und ''ASC_Roommate_Reading'' einem Rollladen zugeordnet werden. Ist einer der Bewohner ''asleep'', wird morgens erst geöffnet, wenn auch der letzte Roommate nicht mehr ''asleep'' ist.
===== Fensterkontakte =====
Dann werden ggf. vorhandene Fensterkontakte zugeordnet und der Typ festgelegt, wobei im Falle von threeState-Sensoren das übergreifende ''ASC_autoShuttersControlComfort'' beachtet wird, wobei dann bei vollstäniger Öffnung des Fensters auf den in ''ASC_ComfortOpen_Pos'' festgelegten Wert gefahren wird.
===== Frostschutz =====
Zuletzt können die Attribute ''ASC_Antifreeze'' und ''ASC_Antifreeze_Pos'' festgelegt werden, wenn die Frostschutzfunktion aktiviert werden soll.
=== Beschattung ===
==== Konfiguration des ASC-Devices ====
Benötigt werden Informationen zum Sonnenstand. Hierfür wird ein astro- oder twilight-Device benötigt. Ist ein solches definiert, wird dies - ggf. auch nach einem Neustart vom Modul automatisch erkannt und in das Attribut ''ASC_twilightDevice'' eingetragen. Wir legen daher zunächst ein entsprechendes Device an bzw. passen die Angabe ggf. an, wenn ein anderes als das eingetragene genutzt werden soll.
Weiter ist ein Temperatursensor für die Beschattung festzulegen (''ASC_temperatureSensor.*''-Attribute) wie bereits oben beschrieben.

==== Konfiguration der Rollladendevices ====
Zum einen legt man einen Helligkeitssensor fest (''ASC_Brightness_Sensor'' und ''ASC_Brightness_Reading''). Dieser ist der eigentliche Trigger. Nur, wenn sich der Brightness Wert ändert, werden Azimut, Elevation, Temperatur und die Ein- und Ausfallswinkel ausgelesen und/oder berechnet und basierend auf diesen Werten entschieden ob shading in oder shading out stattfinden soll, die Schwellwerte werden in ''ASC_Shading_StateChange_Sunny'' (Beschattung soll eingeschaltet werden) und ''ASC_Shading_StateChange_Cloudy'' (Beschattung soll beendet werden) festgelegt, wobei immer nur gefahren wird, wenn auch alles andere - insbesondere die Mindesthöhe des Sonnenstands (''ASC_Shading_Min_Elevation'') und die Mindesttemperatur ''ASC_Shading_Min_OutsideTemperature'' - passt.
Dann sind die Winkelangaben festzulegen, ggf. kann ein Kompass zu Hilfe genommen werden (''ASC_Shading_Direction'' ist die Richtung des Fensters, 90 Grad entspricht Ost, 180 Grad Süden, ''ASC_Shading_Angle_Left'' ist der Sonneneintritt ins Zimmer, wird von -Direction abgezogen, ''ASC_Shading_Angle_Right'' hat diesselbe Funktion für den Austrittswinkel.

=== Weitere Funktionen ===
==== Privacy ====
Werden hierfür Werte festgelegt, werden die betreffenden Rollläden die festgelegte Zeit vor dem abendlichen Schließen vorab teilweise geschlossen. Dies kann z.B. gewünscht sein, um Rollläden zur Straße hin mit viel Fußgängerverkehr zwar nicht vollständig abzudunkeln, aber gleichzeitig zu verhindern, dass von außen in Wohnräume geschaut werden kann, sobald dort das Licht angeschaltet wird
==== BlockingTime====
Bewirkt, dass nach einer manuellen Fahrt wird eine vom ASC Modul initiierte Fahrt zunächst ausgesetzt wird, bis die im Attribute angegebene Zeit überschritten ist. Erst dann wird eine dann vom ASC Modul initiierte Fahrt tatsächlich durchgeführt.
Genau so wird ein hochfahren eines Rollos durch das ASC Modul nicht mehr ausgeführt wenn es innerhalb der Zeit von ASC_BlockingTime_beforNightClose und das runterfahren wird nicht mehr erfolgen wenn es innerhalb von ASC_BlockingTime_beforDayOpen ist.
Beispiel: Meine Tochter geht früh aus Haus und Ihre Rollos sind nicht hoch gefahren. Diese fahren auch nicht mehr hoch da die ausschließlich bei home (anwesend) fahren sollen. Nun kommt sie am Nachmittag um 16:23 Uhr nach Hause, eigentlich sollten nun die Rollos fahren. Doch die Sonnenuntergangsfahrt (schließen) wäre schon 16:51 Uhr und damit innerhalb der 3600 ASC_BlockingTime_beforNightClose. Die Rollos bleiben also unten. Es lohnt sich für die paar Minuten einfach nicht mehr.
==== wiggle====
Mit einem <code>set <ASC-Device> wiggle</code> können alle Rollladen mit einem entsprechenden Attribut zu einer kurzen Fahrt veranlasst werden, nach Ablauf von einer Minute wieder um denselben Wert zurück. Dabei wird jeweils in die Richtung gefahren, die den weiteren Weg ermöglicht. Wenn also zu 70% geschlossen ist, wird der Rollladen hoch fahren.
==== Partymode ====
Dieser wird am ASC-Device selbst aktiviert mittels <code>set <ASC-Device> partyMode on</code>. Alle Rollladen-Devices, welche das Attribut ''ASC_Partymode'' auf ''on'' gestellt haben, werden nicht mehr gesteuert. Der letzte Schaltbefehl, der durch ein Fensterevent oder Bewohnerstatus an die Rollläden gesendet wurde, beim Beenden des Modus durch <code>set ASC-Device partyMode off</code> ausgeführt.
==== lock-out ====
(tbd auch hier: Doku ist etwas verteilt, könnte man im Wiki jeweils unter einem eigenen Unterabschnitt im Zusammenhang darstellen)

==== SelfDefense ====
Das bei einem absent nur da die Rollläden geschlossen werden wo das Fenster vergessen wurde zu schließen.
Beim wechsel in gone wird nur an den makierten Terassentüren (''ASC_ShuttersPlace terrace'') der Rollladen runter gefahren.
Weitere Attribute dazu: ''ASC_Self_Defense_Exclude''

== Sonstige Hinweise ==
* Werden Attribute geändert, kann es vereinzelt vorkommen, dass das ASC-Modul dies nicht mitbekommt und das tatsächliche Verhalten nicht den Erwartungen entspricht. In so einem Fall empfielt es sich, das NOTIFYDEV nochmals aufbauen zu lassen. Dazu werden zunächst mit <code>set <ASC-Modul> expert 1</code> erweiterte Informationen bezüglich des NotifyDevs unter set und get aktiviert und anschließend ein <code>set <ASC-Modul> createNewNotifyDev</code> ausgeführt.

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

<references />

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