FHEMWiki - Benutzerbeiträge [de]

Modul Shelly

2021-04-16T09:08:02Z

Stephan1965: Aktualisierung der attr model

{{Infobox Modul
|ModPurpose=Das Modul 36_Shelly.pm stellt ein Interface zur Bedienung von Shelly Devices zur Verfügung
|ModType=d

|ModCmdRef=Shelly
|ModForumArea=Sonstige Systeme
|ModFTopic=118446
|ModTechName=36_Shelly.pm
|ModOwner=Prof. Dr. Peter A. Henning
}}
Auf dieser Seite werden die Aktoren des bulgarischen Herstellers Allterco Robotics beschrieben ((Markenname Shelly) sowie deren Ansteuerung mit FHEM und aufgetretene Probleme.
Für Supportanfragen bitte ''{{Link2Forum|Topic=118446.0|LinkText=diesen Forenthread}}'' verwenden.
{{Baustelle}}
'''Achtung: Diese Seite ist teilweise veraltet, insbesondere unterstützt das Modul weitere Aktoren. Bitte Commandref lesen - diese Seite ist in Überarbeitung'''

Es handelt sich um IP-basierte Schalt- und Dimmaktoren, die auf verschiedene Weise angesteuert werden können
*über die Web-Oberfläche des eingebauten Mikro-Webservers,
*über eine proprietäre App des Herstellers (Achtung, Cloud!),
*über das hier beschriebene FHEM-Modul 36_Shelly.pm
*über MQTT
Ein Teil der Aktoren verfügt über eine eingebaute Leistungsmessung.

== Geräteübersicht ==
{| class="wikitable mw-datatable"
! style="width:50px" |Modell
! style="width:50px" |Typ
! style="width:20px" |Schaltkanäle
! style="width:20px" |Dimmkanäle
! style="width:20px" |Messkanäle
! style="width:650px" |Bemerkungen
|-
|Shelly1
|Schalter
|1
|
|
|-
|Shelly1PM
|Schalter mit Leistungsmessung
|1
|
|1
|-
|ShellyPlug, ShellyPlugS
|Schalter mit Leistungsmessung
|1
|
|1
|-
|ShellyEM
|Leistungsmessung
|1
|
|2
|-
|Shelly2
|Schalter/Rollladenaktor
|2/1
|
|1
|-
|Shelly2.5
|Schalter/Rollladenaktor
|2/1
|
|2
|-
|Shelly4Pro
|Schalter
|4
|
|4
|-
|ShellyRGBW
|Dimmer
|
|4
|1
|-
|ShellyDimmer
|Dimmer
|
|1
|1
|}

== Einbindung in FHEM ==
*Schließen Sie den Aktor nach Vorschrift an
*Suchen Sie mit einem WLAN-fähigen Gerät (Laptop oder Smartphone) nach dem internen Access Point, der durch den Aktor erzeugt wird. Typischerweise hat dieser eine SSID ähnlich wie
shelly1-..., shellyswitch-..., shelly4pro-...,
*Verbinden Sie Ihr Gerät mit diesem Access Point. Typischerweise bekommt Ihr Gerät dabei die IP-Adresse 192.168.33.2 zugewiesen.
*Im Browser dieses Gerätes einfach die IP-Adresse 192.168.33.1 aufrufen - das ist der Shelly selbst, in dieser Web-Oberfläche kann man alles konfigurieren.
**Internen Access Point abschalten
**Shelly ins häusliche WLAN anmelden. Mit fester IP-Adresse <shelly-ip> natürlich...
**Testen: Ihr Gerät wieder mit dem häuslichen WLAN verbinden, und im Browser die Adresse <shelly-ip> aufrufen
*In FHEM definieren
define myShelly Shelly <shelly-ip>
*Auf der Detailseite des Devices muss unbedingt noch das Attribut <code>model</code> gesetzt werden:
attr myShelly model shellyrgbw|shellydimmer|shelly2.5|generic|shelly2|shellyem|shelly4|shellyplug|shelly1|shellybulb|shelly1pm|shellyuni
Falls es sich um einen Shelly2 oder 2.5 handelt, muss ferner das Attribut <code>mode</code> auf "roller" oder "relay" gesetzt werden. Mit diesem Modul können alle Daten übertragen und (prinzipiell) alle Konfigurationsänderungen durchgeführt werden, außerdem ist es auf einfachste Weise zu installieren. Das Modul pollt im per Attribut <code>interval</code> einstellbaren Abstand zyklisch den Aktor auf Statusänderungen (Wert 0 => kein Polling). Damit der Aktor im Stande ist, irgendwelche Zustandsänderungen ''von sich aus'' an FHEM zu melden, müssen diese als REST-Befehle (also URL-Aufrufe, für Nicht-Experten) in der Konfigurationsoberfläche des Shelly-Aktors eingetragen werden. Siehe CommandRef.

Zum Betrieb ist ferner noch zu bemerken, dass das Modul zwar meldet, ob ein Firmware-Update nötig ist - ausgelöst werden muss dieses aber über die Web-Oberfläche des Shelly selber.

=== MQTT ===
MQTT (Message Queue Telemetry Transport) ist ein nachrichtenbasiertes Protokoll, bei dem Geräte (Devices) nicht direkt miteinander, sondern mit einem zentralen MQTT-Server (in alter Nomenklatur ''Broker'' genannt) kommunizieren. Eine kurze Einführung in MQTT findet man auf der Seite [[MQTT Einführung]]. Mit entsprechend gesetzten Attributen lassen sich die Shelly-Aktoren auch steuern, für Anfnger ist das allerdings nicht unbedingt zu empfehlen.

AutoShuttersControl

2020-11-16T08:53:25Z

Stephan1965: Daten zum Sonnenstand für die Beschattung können z. B. auf dieser Webseite ermittelt werden.

{{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 derzeit aktuelle Stand ist diesem {{Link2Forum|Topic=112325|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'', ''absent'', ''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/ 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 Rollä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 Rollä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 des letzten Fahrens des Rolladens
|-
|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/ Wertebereich !! Beschreibung
|-
|advDriveDown ||on, off ||holt bei allen Rollläden durch ASC_Adv on ausgesetzte Fahrten nach
|-
|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 entsprechend 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 Rolladen die Zeiten gemäß ASC_UP/ASC_DOWN und setzt die internen Timer neu.
|-
|scanForShutters || ||sucht alle FHEM Devices mit dem Attribut ''ASDC'' ''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 beim einzelnen Rollladens
|-
|sunriseTimeWeHoliday || on,off ||Aktiviert die Wochenendunterstützung und somit, ob im Rollladen das Attribut ASC_Time_Up_WE_Holiday beachtet werden soll oder nicht.
|-
|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 primär fürs 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/ 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/ 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_DriveDelayStart || || -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_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>
 
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 (nach Sonnenstand) ==
=== 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.

{{Hinweis|Achtung: Das AutoShuttersControl-Device selbst darf kein ASC-Attribut bekommen!}}

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_BrightnessSensor'' 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
</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" mit dem Wert on, sowie ein Astro/Twilight Device im Attribut "ASC_twilightDevice" und das Attribut "ASC_tempSensor".

==== Konfiguration der Rollladendevices ====
Ihr benötigt einen Helligkeitssensor als Attribut "ASC_BrightnessSensor", sofern noch nicht vorhanden. Findet der Sensor nur für die Beschattung Verwendung ist der Wert DEVICENAME[:READING] ausreichend.
Alle weiteren Attribute sind optional und wenn nicht gesetzt mit Default-Werten belegt. Ihr solltet sie dennoch einmal anschauen und entsprechend Euren Gegebenheiten setzen. Die Werte für die Fensterposition und den Vor- Nachlaufwinkel ''(ASC_Shading_InOutAzimuth)'' sowie die Grenzwerte für <code>''ASC_shading_StateChange_SunnyCloudy''</code> solltet ihr besondere Beachtung dabei schenken.

==== Bedingungen ====
Damit die Beschattung startet müssen '''alle''' Bedingungen erfüllt sein. Entschattet wird sobald '''einer''' der Bedingungen wegfällt und die Zeit aus <code>ASC_Shading_WaitingPeriod</code> abgelaufen ist.

Der Sonnensensor <ASC_BrightnessSensor> muss mindestens 2 Messwerte liefern, bevor das ASC-Modul in die Beschattungsposition fährt! Beim (zeitlich gesehen) ersten Messwert wird der Zustand ''in-reserved'' eingenommen und erst beim zweiten Messwert dann der Zustand ''in shading'' eingenommen. Die Anzahl der 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 ===

==== '''Beschreibung WeekendHoliday Funktion im Brightnessbetrieb.''' ====
Wenn Wochenende oder Feiertag ist und WeekendHoliday aktiviert wurde und im Rollo das Attribut ASC_Time_Up_WE_Holiday gesetzt ist dann wird ausschließlich zur angebenden ASC_Time_Up_WE_Holiday Zeit gefahren 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

2020-09-20T11:40:22Z

Stephan1965: /* Sonstige Hinweise und Problemlösungen */ Lösungsvorschlag, falls zu viele Fahrbefehle gesendet werden und ein Device den Befehl nicht bekommt (zeitverzögertes Fahren)

{{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 derzeit aktuelle Stand ist diesem {{Link2Forum|Topic=112325|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'', ''absent'', ''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/ 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 Rollä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 Rollä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 des letzten Fahrens des Rolladens
|-
|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/ Wertebereich !! Beschreibung
|-
|advDriveDown ||on, off ||holt bei allen Rollläden durch ASC_Adv on ausgesetzte Fahrten nach
|-
|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 entsprechend 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 Rolladen die Zeiten gemäß ASC_UP/ASC_DOWN und setzt die internen Timer neu.
|-
|scanForShutters || ||sucht alle FHEM Devices mit dem Attribut ''ASDC'' ''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 beim einzelnen Rollladens
|-
|sunriseTimeWeHoliday || on,off ||Aktiviert die Wochenendunterstützung und somit, ob im Rollladen das Attribut ASC_Time_Up_WE_Holiday beachtet werden soll oder nicht.
|-
|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 primär fürs 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/ 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/ 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_DriveDelayStart || || -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_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>
 
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 (nach Sonnenstand) ==
=== 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.

{{Hinweis|Achtung: Das AutoShuttersControl-Device selbst darf kein ASC-Attribut bekommen!}}

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_BrightnessSensor'' 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
</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" mit dem Wert on, sowie ein Astro/Twilight Device im Attribut "ASC_twilightDevice" und das Attribut "ASC_tempSensor".

==== Konfiguration der Rollladendevices ====
Ihr benötigt einen Helligkeitssensor als Attribut "ASC_BrightnessSensor", sofern noch nicht vorhanden. Findet der Sensor nur für die Beschattung Verwendung ist der Wert DEVICENAME[:READING] ausreichend.
Alle weiteren Attribute sind optional und wenn nicht gesetzt mit Default-Werten belegt. Ihr solltet sie dennoch einmal anschauen und entsprechend Euren Gegebenheiten setzen. Die Werte für die Fensterposition und den Vor- Nachlaufwinkel ''(ASC_Shading_InOutAzimuth)'' sowie die Grenzwerte für <code>''ASC_shading_StateChange_SunnyCloudy''</code> solltet ihr besondere Beachtung dabei schenken.

==== Bedingungen ====
Damit die Beschattung startet müssen '''alle''' Bedingungen erfüllt sein. Entschattet wird sobald '''einer''' der Bedingungen wegfällt und die Zeit aus <code>ASC_Shading_WaitingPeriod</code> abgelaufen ist.

Der Sonnensensor <ASC_BrightnessSensor> muss mindestens 2 Messwerte liefern, bevor das ASC-Modul in die Beschattungsposition fährt! Beim (zeitlich gesehen) ersten Messwert wird der Zustand ''in-reserved'' eingenommen und erst beim zweiten Messwert dann der Zustand ''in shading'' eingenommen. Die Anzahl der 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 ===

==== '''Beschreibung WeekendHoliday Funktion im Brightnessbetrieb.''' ====
Wenn Wochenende oder Feiertag ist und WeekendHoliday aktiviert wurde und im Rollo das Attribut ASC_Time_Up_WE_Holiday gesetzt ist dann wird ausschließlich zur angebenden ASC_Time_Up_WE_Holiday Zeit gefahren 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

<references />

[[Kategorie:Code Snippets]]
[[Kategorie:Rollladensteuerung]]

NUKI

2020-02-14T22:58:31Z

Stephan1965: Befehl nicht vorhanden

<div style="float:right">
{{Infobox Modul
|ModPurpose=Einbindung der Nuki Bridge HW/APP
|ModType=d
|ModCmdRef=NUKIBridge
|ModForumArea=Sonstige Systeme
|ModTechName=73_NUKIBridge.pm
|ModOwner=CoolTux ({{Link2FU|13684|Forum}} / [[Benutzer:CoolTux|Wiki]])
}}
{{Infobox Modul
|ModPurpose=Steuern von Nuki Smartlocks über NUKIBridge
|ModType=d
|ModCmdRef=NUKIDevice
|ModForumArea=Sonstige Systeme
|ModTechName=73_NUKIDevice.pm
|ModOwner=CoolTux ({{Link2FU|13684|Forum}} / [[Benutzer:CoolTux|Wiki]])
}}
</div>

==NUKIBridge==
NUKIBridge - Steuert das Nuki Smartlock über die Nuki Bridge

Das Nuki Bridge Modul verbindet FHEM mit der Nuki Bridge und liest dann alle auf der Bridge verfügbaren Smartlocks ein. Desweiteren werden automatisch die erkannten Smartlocks als eigenständige Devices angelegt.

Für eine aktive Callback Funktion müssen noch zwei Attribute der Bridge eingerichtet werden:
* webhookFWinstance - zu verwendende Webinstanz (darf keine Passwortabfrage beinhalten)
* webhookHttpHostname - IP oder FQDN des FHEM Servers

Voraussetzung für ein fehlerfreies Laden ist die Installation von JSON (libperl-json).

===Definition===
:<code>define <name> NUKIBridge <HOST> <API-TOKEN></code>

'''Beispiel:'''
:<code>define NBridge1 NUKIBridge 192.168.0.23 F34HK6</code>

Diese Anweisung erstellt ein NUKIBridge Device mit Namen NBridge1 und der IP 192.168.0.23 sowie dem Token F34HK6. Nach dem Anlegen des Bridge Devices werden alle zur Verfügung stehende Smartlock automatisch in FHEM angelegt.

===Readings===
* 0_nukiId - ID des ersten gefundenen Nuki Smartlocks
* 0_name - Name des ersten gefunden Nuki Smartlocks
* smartlockCount - Anzahl aller gefundenen Smartlock
* bridgeAPI - API Version der Bridge
* bridgeType - Hardware oder Software/App Bridge
* currentTime - aktuelle Zeit auf der Bridge zum zeitpunkt des Info holens
* firmwareVersion - aktuell auf der Bridge verwendete Firmwareversion
* hardwareId - ID der Hardware Bridge
* lastError - gibt die letzte HTTP Errormeldung wieder
* serverConnected - true/false gibt an ob die Hardwarebridge Verbindung zur Nuki-Cloude hat.
* serverId - gibt die ID des Cloudeservers wieder
* uptime - Uptime der Bridge in Sekunden
* wifiFirmwareVersion- Firmwareversion des Wifi Modules der Bridge
* Die vorangestellte Zahl ist forlaufend und gibt beginnend bei 0 die Eigenschaften Eines Smartlocks wieder.

===Set===
* <s>autocreate - veranlasst ein erneutes Einlesen aller Smartlocks von der Bridge und falls noch nicht in FHEM vorhanden das automatische Anlegen.</s>
* callbackRemove - löschen einer Callback Instanz auf der Bridge. Die Instanz ID kann mittels get callbackList ermittelt werden
* clearLog - löscht das Logfile auf der Bridge
* fwUpdate - schaut nach einer neueren Firmware und installiert diese, sofern vorhanden
* info - holt aktuelle Informationen über die Bridge
* reboot - veranlasst ein reboot der Bridge

===Get===
* callbackList - gibt die Liste der eingetragenen Callback URLs wieder. Die Bridge nimmt maximal drei auf
* logFile - Zeigt das Logfile der Bridge an

===Attribute===
* disable - deaktiviert die Nuki Bridge

==NUKIDevice==
NUKIDevice - Steuert das Nuki Smartlock

Das Nuki Modul verbindet FHEM über die Nuki Bridge mit einem Nuki Smartlock. Es ist dann möglich das Schloss zu ver- und entriegeln. In der Regel werden die Nuki Devices automatisch durch das Bridgemodul angelegt.

===Definition===
:<code>define <name> NUKIDevice <Nuki-Id> <IODev-Device></code>

'''Beispiel:'''
:<code>define Haustuer NUKIDevice 1 NBridge1</code>

Diese Anweisung erstellt ein NUKIDevice mit Namen Haustuer, der NukiId 1 sowie dem IODev Device NBridge1. Nach dem Anlegen des Devices wird automatisch der aktuelle Zustand des Smartlocks aus der Bridge gelesen.
Damit das NUKIDevice auch Statusänderungen mitbekommt, die beispielsweise aus der nativen NUKI-App oder der manuellen Betätigung des Devices herrühren, ist es notwendig, die Attribute webhookFWinstance und webhookHttpHostname zu setzen.

:<code>attr Haustuer webhookFWinstance WEB (Name der FHEMWEB Instanz)</code>
:attr Haustuer webhookHttpHostname 192.168.0.1 (IP/FQDN vom FHEM Server)

Zum Überprüfen kann die Funktion
:<code>get NUKIBridge callbackList</code>
aufgerufen werden. Es sollte nur ein Callback eingetragen
sein, der in dieser Form hinterlegt sein sollte.
:<code><nowiki>0 http://192.168.0.1:8083/fhem/NUKIDevice-123456789</nowiki></code>

===Readings===
* state - Status des Smartlock bzw. Fehlermeldung von Fehler vorhanden.
* lockState - aktueller Schließstatus: uncalibrated, locked, unlocked, unlocked (lock ‘n’ go), unlatched, locking, unlocking, unlatching, motor blocked, undefined
* succes - true, false; gibt des Status des letzten Schließbefehles wieder. Geklappt oder nicht geklappt.
* batteryCritical - ist die Batterie in einem kritischen Zustand? true, false
* battery - Status der Batterie, ok, low

===Set===
* statusRequest - ruft den aktuellen Status des Smartlocks von der Bridge ab
* lock - verschließen
* unlock - aufschließen
* unlatch - entriegeln/Falle öffnen
* locknGo - verschließen wenn gegangen
* locknGoWithUnlatch - verschließen nachdem die Falle geöffnet wurde

===Attribute===
* disable - deaktiviert das Nuki Device
* webhookFWinstance - zu verwendene Webinstanz für den Callbackaufruf
* webhookHttpHostname - IP oder FQDN vom FHEM Server für den Callbackaufruf

== Links ==
* [https://nuki.io/de/ Webseite des Herstellers]

[[Kategorie:Türschlosssteuerung]]

ROLLO

2019-09-02T15:23:29Z

Stephan1965:

{{SEITENTITEL:ROLLO}}
{{Infobox Modul
|ModPurpose=Rollo-Steuerung zur einfachen Anzeige/Programmierung
|ModType=h
|ModFTopic=95832


|ModForumArea=Unterstützende Dienste
|ModTechName=44_ROLLO.pm
|ModOwner=KernSani}}
Das Modul [[ROLLO]] bietet eine einfache Möglichkeit, mit ein bis zwei Relais den Hoch-/Runterlauf eines Rolladen zu steuern und punktgenau anzuhalten. Außerdem wird die aktuelle Position in fhem abgebildet.
Über welche Hardware/Module die Ausgänge angesprochen werden ist dabei egal.
__TOC__
Das Modul unterstützt beliebige Konfigurationen welche Befehle ausgeführt werden müssen um die Hardware des Rollos zu steuern.

* Die Rollo-Position wird in 10%-Schritten von 0% (offen) bis 100% (geschlossen) zwischengespeichert um auf der Oberfläche für jede Position ein Icon festlegen zu können.

[[Datei:Rolladen Eintrag.PNG|right|thumb|400px|Verschiedene Ansichten des Rollo:offen, fährt gerade herunter, position 50, fährt gerade hoch, geschlossen]]
Vorteil dieses Moduls:

Ist ein Rollo mit diesem Modul definiert kann man auf der Oberfläche per Klick das Rollo hoch/runter oder auf eine bestimmte Position fahren. Der aktuelle Status des Rollo (fährt hoch/runter,offen,geschlossen,etc.) wird angezeigt.
Die Oberflächenicons werden per devStateIcon gesteuert, Icons und Farben können für jeden Status individuell formatiert werden, die Standard Kommandos auf der Oberfläche (hier: offen, geschlossen, schlitz, Position) können ebenfalls per Attribut angepasst werden. Das Status-Icon ist anklickbar.
Beim Anlegen des Moduls werden die Attribute zur Darstellung in fhem mit Standardwerten angelegt, so dass man sich einiges an Tipparbeit sparen kann, aber trotzdem die Möglichkeit hat die Darstellung individuell anzupassen.

== Voraussetzungen ==
Das eigentliche ansteuern des Rollo muss mit FHEM Befehlen ausführbar sein, diese Modul ist "nur" eine Oberfläche/Bedienmodul, kein Hardwaremodul.

Wenn ROLLO installiert wurde, bevor es Bestandteil von FHEM wurde und lange kein Update gemacht wurde, wirst du die "position" readings und das entsprechende set Kommando vermissen. "position" wurde durch "pct" ersetzt, um Kompatibilität mit anderen Modulen [https://fhem.de/commandref_DE.html#AutoShuttersControl Automatic Shutter Control - ASC] sicher zu stellen. Bitte passe deine NOTIFYs/DOIFs entsprechend an.

== Installation ==

{{Hinweis|Dieses Modul ist in der offiziellen FHEM-Auslieferung enthalten.}}

== Anwendung ==
=== Define ===
define <name> ROLLO

=== Attribute ===
{|class="wikitable"
|-
! Name !! Datentyp/ Wertebereich !! Default-Wert !! Beschreibung
|-
|rl_type ||attr <Rollo-Device> rl_type [normal|HomeKit] ||||Typunterscheidung zur unterstützung verschiedener Hardware. Abhängig vom gewählten Typ wird die Richtung von der die pct gerechnet wird festgelegt:

normal = pct 0 ist offen, pct 100 ist geschlossen
HomeKit = pct 100 ist offen, pct 0 ist geschlossen
|-
|rl_secondsDown||attr <Rollo-Device> rl_secondsDown <number> ||||Sekunden zum hochfahren
|-
|rl_secondsUp ||attr <Rollo-Device> rl_secondsUp <number> ||||Sekunden zum herunterfahren
|-
|rl_excessTop ||attr <Rollo-Device> rl_excessTop <number> ||||Zeit, die mein Rollo fahren muss, ohne dass sich die Rollo-pct ändert (bei mir fährt der Rollo noch in die Wand, ohne dass man es am Fenster sieht, die pct ist also schon bei 0%).
|-
|rl_excessBottom ||attr <Rollo-Device> rl_excessBottom <number> ||||(siehe excessTop)
|-
|rl_switchTime ||attr <Rollo-Device> rl_switchTime <number> ||||Zeit, die zwischen 2 gegensätzlichen Laufbefehlen pausiert werden soll, also wenn der Rollo z.B. gerade runter fährt und ich den Befehl gebe hoch zu fahren, dann soll 1 Sekunde gewartet werden bis der Motor wirklich zum stillstand kommt, bevor es wieder in die andere Richtung weiter geht. Dies ist die einzige Zeit, die nichts mit der eigentlichen Laufzeit des Motors zu tun hat, sondern ein Timer zwischen den Laufzeiten.
|-
|rl_resetTime ||attr <Rollo-Device> rl_resetTime <number> ||||Zeit, die beim Anfahren von Endpositionen (offen,geschlossen) der Motor zusätzlich an bleiben soll, um sicherzustellen, dass die Endposition wirklich angefahren wurde. Dadurch können Differenzen in der Positionsberechnung korrigiert werden.
|-
|rl_reactionTime ||attr <Rollo-Device> rl_reactionTime <number> ||||Zeit für den Motor zum reagieren
|-
|rl_autoStop ||attr <Rollo-Device> rl_autoStop [0|1] ||||Es muss kein Stop-Befehl ausgeführt werden, das Rollo stoppt von selbst.
|-
|rl_commandUp ||attr <Rollo-Device> rl_commandUp <string> ||||Es werden bis zu 3 beliebige Befehle zum hochfahren ausgeführt
|-
|rl_commandDown ||attr <Rollo-Device> rl_commandDown <string> ||||Es werden bis zu 3 beliebige Befehle zum runterfahren ausgeführt
|-
|rl_commandStop ||attr <Rollo-Device> rl_commandStop <string> ||||Befehl der zum Stoppen ausgeführt wird, sofern nicht commandStopDown bzw. commandStopUp definiert sind
|-
|rl_commandStopDown ||attr <Rollo-Device> rl_commandStopDown <string> ||||Befehl der zum stoppen ausgeführt wird, wenn der Rollo gerade herunterfährt. Wenn nicht definiert wird commandStop ausgeführt
|-
|rl_commandStopUp ||attr <Rollo-Device> rl_commandStopUp <string> ||||Befehl der zum Stoppen ausgeführt wird,wenn der Rollo gerade hochfährt. Wenn nicht definiert wird commandStop ausgeführt
|-
|rl_blockMode ||attr <Rollo-Device> rl_blockMode [blocked|force-open|force-closed|only-up|only-down|half-up|half-down|none] ||||wenn ich den Befehl blocked ausführe, dann wird aufgrund der blockMode-Art festgelegt wie mein Rollo reagieren soll:

blocked = Rollo lässt sich nicht mehr bewegen
force-open = bei einem beliebigen Fahrbefehl wird Rollo hochgefahren
force-closed = bei einem beliebigen Fahrbefehl wird Rollo runtergefahren
only-up = Befehle zum runterfahren werden ignoriert
only-down = Befehle zum hochfahren werden ignoriert
half-up = es werden nur die Positionen 50-100 angefahren, bei pct <50 wird pct 50% angefahren,
half-down = es werden nur die Positionen 0-50 angefahren, bei pct >50 wird pct 50 angefahren
none = block-Modus ist deaktiviert
|-
|automatic-enabled ||attr <Rollo-Device> automatic-enabled [on|off] ||||Wenn auf off gestellt, haben Befehle über Modul ROLLO_Automatic keine Auswirkungen auf diesen Rollo
|-
|automatic-delay ||attr <Rollo-Device> automatic-delay <number> ||||Dieses Attribut wird nur fuer die Modulerweiterung ROLLADEN_Automatic benoetigt.
Hiermit kann einge Zeitverzoegerund fuer den Rolladen eingestellt werden, werden die Rolladen per Automatic heruntergefahren, so wird dieser um die angegebenen minuten spaeter heruntergefahren.
|-
|rl_forceDrive ||attr <Rollo-Device> rl_forceDrive [0|1] ||||open/closed wird ausgeführt, auch wenn das ROLLO bereits in der Zielposition ist
|-
|rl_noSetPosBlocked ||attr <Rollo-Device> rl_noSetPosBlocked [0|1] ||||Wenn deaktiviert, können Positionsn (pct) auch gesetzt werden, wenn der ROLLO geblockt ist. Nach dem unblocken wird die entsprechende Position angefahren.
|-
|||disableattr <Rollo-Device> disable [0|1] ||||Wenn deaktiviert, können keine set oder get commandos für den ROLLO ausgeführt werden.
|-
|||||||
|-
|||||||
|-
|||||||
|}

=== Set ===

{|class="wikitable"
|-
!Name !!set Befehl !!Beschreibung
|-
|open ||set <Rollo-Device> open ||Faehrt das Rollo komplett auf (pct 0)
|-
|closed ||set <Rollo-Device> closed||Faehrt das Rollo komplett zu (pct 100)
|-
|up ||set <Rollo-Device> up ||Faehrt das Rollo um 10 auf (pct +10)
|-
|down ||set <Rollo-Device> down ||Faehrt das Rollo um 10 zu (pct -10)
|-
|half || set <Rollo-Device> half ||Faehrt das Rollo zur haelfte runter bzw. hoch (pct 50)
|-
|stop ||set <Rollo-Device> stop ||Stoppt das Rollo
|-
|drive ||set <Rollo-Device> drive up 5||Fährt das Rollo in die angegebene Richtung für die angegebene Zeit (in Sekunden)
|-
|blocked ||set <Rollo-Device> blocked ||wenn aktiviert, kann der ROLLO nur noch eingeschränkt gesteuert werden. Siehe Attribut block_mode für Details.
|-
|unblocked ||set <Rollo-Device> unblocked ||Aktiviert einen geblockten ROLLO wieder für die normale Benutzung
|-
|pct ||set <Rollo-Device> pct <value> ||Faehrt das Rollo auf eine beliebige pct zwischen 0 (offen) - 100 (geschlossen)
|-
|reset ||set <Rollo-Device> reset <value> ||Sagt dem Modul in welcher pct sich der Rollo befindet
|-
|extern ||set <Rollo-Device> extern <value> ||Der Software mitteilen dass gerade Befehl X bereits ausgeführt wurde und nun z.B,. das berechnen der aktuellen pct gestartet werden soll
|}

=== Get ===

{|class="wikitable"
|-
!Name !!set Befehl !!Beschreibung
|-
|version ||get <Rollo-Device> version ||Gibt die version des Modul Rollos aus
|}

=== Readings ===
{|class="wikitable"
|-
!Name !!Wert !!Beschreibung
|-
|command||open,stop,closed||
|-
|desired_pct||0-100||Zielposition die angefahren werden soll (nur sinnvoll während das Rollo fährt)
|-
|drive-type||modul,extern||bei dem Befehl "set rollo extern .." wird dieses attribut auf "extern" gestellt, sonst immer "modul"
|-
|last_drive||drive-up,drive-down||die zuletzt benutzte Fahrtrichtung
|-
|pct||0-100||exakte Position des Rollo
|-
|state||open,closed,position-[0-100]||die Position gerundet auf ganze 10% Schritte, identisch mit dem Internal STATE
|}

== Anwendungsbeispiele ==
===Set===
set RolladenWohnzimmer pct 50
set RolladenWohnzimmer geschlossen
set RolladenWohnzimmer offen
Drei Beispiele das Rollo-Modul anzuweisen verschiedene Positionen anzufahren.

set RolladenWohnzimmer extern stop
Das Rollo-Modul wird angewiesen den status auf "nicht fahren" zu setzen, die aktuelle Rollo-Position zu berechnen und als neue Position abzuspeichern. Der eigentliche Rollo-Stop-Befehl wird dabei aber nicht gesendet.

set RolladenWohnzimmer reset closed
In der Oberfläche von fhem wird für das Rollo die Position "geschlossen" gespeichert, ohne Berechnungen durchzuführen oder Hardware zu steuern. Wird evtl. benötigt wenn der Ist-Status von den Soll-Werten aus fhem abweicht.

===Zusammenspiel mit externem Taster===
In einem Anwendungszenario hat ein Nutzer zusätzliche Taster an seinem Rollo-Motor über die er ihn ebenfalls steuern kann.
Die Taster selber senden keine Events an fhem, nur der Rollo-Motor.
Hier ein Beispiel wie das ganze für aussehen könnte und diese Taster in das ROLLO-Modul integriert werden:

define rollo_manuell_auf DOIF ([meinRollo_Kanal1] eq "on" and [?meinRolloModul] ne "drive-up") (set meinRolloModul extern open) DOELSEIF ([meinRollo_Kanal1] eq "off" and [?meinRolloModul] eq "drive-up") (set meinRolloModul extern stop)
define rollo_manuell_ab DOIF ([meinRollo_Kanal2] eq "on" and [?meinRolloModul] ne "drive-down") (set meinRolloModul extern closed) DOELSEIF ([meinRollo_Kanal2] eq "off" and [?meinRolloModul] eq "drive-down") (set meinRolloModul extern stop)

meinRollo_Kanal1 und meinRollo_Kanal2 sind die Hardwarekanäle die in dem Rollo-Modul zum hochfahren/runterfahren benutzt werden.
Das erste DOIF prüft ob das Rollo hoch fährt, ohne das das Rollo-Modul davon etwas weis. Ist dem so wird dem Rollo Modul mithilfe des set <extern> mitgeteilt das das Rollo bereits gestartet wurde. Das Modul fängt an die Zeit zu zählen und aktualisiert den Status der Oberfläche auf "fahre hoch".
IM DOELSEIF wird abgefragt ob das Rollo steht, obwohl das Modul denkt das Rollo würde noch fahren. Ist dem so wird wieder mithilfe des set <extern> dem Modul mitgeteilt das das Rollo gestoppt wurde. Das Modul berechnet nun aufgrund der gefahrenen Zeit die aktuelle Position und aktualisiert den Status der Oberfläche auf die Position.

Das gleiche wird dann im zweiten DOIF nochmal für das herunterfahren gemacht.

Man kann nun das Rollo sowohl über die Oberfläche als auch per Taster bedienen und fhem und der reale Ist-Status sind synchron. Ach eine gleichzeitige Bedienung ist möglich, Das Rollo startet z.B. aufgrund einer Automatisierung morgens zum hochfahren und man klickt schnell auf den Taster neben dem Bett und stoppt das ganze wieder.

== Links ==

Thread im {{Link2Forum|Topic=95832|LinkText=Forum}} seit das Modul Bestandteil der offiziellen FHEM Auslieferung ist

Thread im {{Link2Forum|Topic=47202|LinkText=Forum}} bevor das Modul Bestandteil von FHEM war

AutoShuttersControl

2019-09-02T08:29:57Z

Stephan1965:

{{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/ 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/ 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/ 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/ 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>
 
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 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 ====
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]]

AutoShuttersControl

2019-09-02T08:13:06Z

Stephan1965:

{{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/ 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/ 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/ 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/ 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>
 
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 mit ''ASC_WindowRec'' zugeordnet und der Sensortyp mit ''ASC_WindowRec_subType'' 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]]

AutoShuttersControl

2018-10-15T15:03:00Z

Stephan1965: /* Vorbereitung */

{{Baustelle}}
{{Infobox Modul
|ModPurpose=Steuerung von Rollläden
|ModCategory=Automatisierung
|ModType=x

|ModForumArea=Automatisierung
|ModTechName=73_AutoShuttersControl.pm
|ModOwner=CoolTux}}
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.

{{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.}}

== Basics ==
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''.

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)

== Einrichtung ==

=== Vorbereitung ===

{{Hinweis|Ihr benötigt ein aktuelles FHEM. Update ab dem 04.09.2018 Voraussetzung!}}

Zunächst müssen das Modul (aus dem Link im Forum) entpackt, die Datei 73_AutoShuttersControl.pm in das Unterverzeichnis für die Module kopiert und die Rechte angepaßt werden.

Speicherort für Linux-Standardinstallationen: /opt/fhem/FHEM 
Rechte: <code>sudo chown 73_AutoShuttersControl.pm</code> und <code>sudo chmod 644 73_AutoShuttersControl.pm</code>

Danach sollte ein <code>reload AutoShuttersControl</code> in FHEM-Eingabefeld ausreichen, um das Modul verfügbar zu machen.

{{Hinweis|Eventuell muß FHEM auch einmalig neu gestartet werden, um das Modul nutzen zu können.}}

=== 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 ''AutoShuttersControl'' 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äßt, 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 ''AutoShuttersControl'' 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.

=== 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 ===
Danach sind jeweils 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 AutoShuttersControl Device selbst.===

{|class="wikitable"
|-
! Name !! Datentyp/ Wertebereich !! Bedeutung
|-
|..._nextAstroTimeEvent || ||Uhrzeit des nächsten Astro Events, Sonnenauf, Sonnenuntergang oder feste Zeit pro Rollonamen
|-
|..._lastPosValue || ||letzter abgesetzter Fahrbefehl pro Rollonamen
|-
|..._lastDelayPosValue || ||letzter 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 Schaltbefehle welcher durch ein Fensterevent oder Bewohnerstatus an die Rollläden gesendet wurde, wird beim off setzen durch set ASC-Device partyMode off ausgeführt
|-
|lockOut || on, off ||für das aktivieren des Aussperrschutzes gemäß dem entsprechenden Attribut 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ämen gefunden wurde, Bsp.: room_Schlafzimmer,Terrasse
|-
|state || ||Status des Devices active, enabled, disabled
|-
|sunriseTimeWeHoliday|| on,off ||wird das Rolladen Device Attribut Attributes 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_Sunrise ||Sonnenaufgangszeit für das Rollo
|-
|ASC_Time_Sunset ||Sonnenuntergangszeit für das Rollo
|}

== Settings ==

===Set Befehle für AutoShuttersControl Device===

{|class="wikitable"
|-
! Name !! Datentyp/ Wertebereich !! Beschreibung
|-
|partyMode ||on, off ||aktiviert den globalen Partymodus. Siehe Reading partyMode
|-
|lockOut ||on, off ||aktiviert den globalen Aussperrschutz. Siehe Reading partyMode
|-
|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/2
|-
|sunriseTimeWeHoliday || on,off ||aktiviert/deaktiviert die Beachtung des Rolladen Device Attributes AutoShuttersControl_Time_Up_WE_Holiday
|-
|createNewNotifyDev || ||Legt die interne Struktur für NOTIFYDEV neu an
|-
|selfDefence ||on, off||aktiviert/deaktiviert den Selbstschutz, wenn das Residents Device absent meldet und selfDefence aktiv ist und ein Fenster im Haus steht noch offen, wird an diesem Fenster das Rollo runter gefahren
|}

== Attribute ==

===Attribute im AutoShuttersControl Device selbst.===

{|class="wikitable"
|-
! Name !! Datentyp/ Wertebereich !! Default-Wert !! Beschreibung
|-
|ASC_antifreezeTemp || || ||Temperatur ab welcher der Frostschutz greifen soll und das Rollo nicht mehr fährt. Der letzte Fahrbefehl wird gespeichert.
|-
|ASC_autoAstroModeEvening ||aktuell REAL, CIVIL, NAUTIC, ASTRONOMIC || || (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 || ||(in genau dieser Schreibweise)
|-
|ASC_autoAstroModeMorningHorizon || || ||Höhe über Horizont wenn beim Attribut AutoShuttersControl_autoAstroModeMorning HORIZON ausgewählt
|-
|ASC_autoShuttersControlComfort ||on, off || ||schaltet die Komfortfunktion an. Bedeutet das ein Rollladen mit einem threestate Sensor am Fenster beim öffnen in eine weit offen Position fährt. Die Offenposition wird beim Rollladen über das Attribut AutoShuttersControl_Pos_after_ComfortOpen eingestellt.
|-
|ASC_autoShuttersControlEvening ||on, off || ||ob Abends die Rollläden automatisch nach Zeit gesteuert werden sollen
|-
|ASC_autoShuttersControlMorning ||on, off || ||ob Morgens die Rollläden automatisch nach Zeit gesteuert werden sollen
|-
|ASC_temperatureReading || || ||Reading für die Aussentemperatur
|-
|ASC_temperatureSensor || || ||Device für die Aussentemperatur
|-
|ASC_timeUpHolidayDevice || || ||Device zur Urlaubserkennung oder Sonstiges / muss 0 oder 1 im Reading state beinhalten.
|-
|ASC_residentsDevice|| || ||Devicenamen vom Residents Device der obersten Ebene
|-
|ASC_residentsDeviceReading|| || ||Status Reading vom Residents Device der obersten Ebene
|-
| || || ||
|}

===Attribute in den Rolllädendevices===

{|class="wikitable"
|-
! Name !! Datentyp/ Wertebereich !! Default-Wert !! Beschreibung
|-
|AutoShuttersControl || 0, 1, 2 || ||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 ||on, off || ||Frostschutz an oder aus
|-
|ASC_AutoAstroModeEvening ||aktuell REAL, CIVIL, NAUTIC, ASTRONOMIC || ||
|-
|ASC_AutoAstroModeEveningHorizon || || ||Höhe über Horizont wenn beim Attribut ASC_autoAstroModeEvening HORIZON ausgewählt
|-
|ASC_AutoAstroModeMorning ||aktuell REAL, CIVIL, NAUTIC, ASTRONOMIC || ||
|-
|ASC_AutoAstroModeMorningHorizon || || ||Höhe über Horizont wenn beim Attribut ASC_autoAstroModeMorning HORIZON ausgewählt
|-
|ASC_Closed_Pos || || ||in 10 Schritten von 0 bis 100, default Vorgabe ist abhängig vom Attribut AutoShuttersControl
|-
|ASC_Down ||astro, time || ||bei Astro wird Sonnenuntergang berechnet, bei time wird der Wert aus ASC_Time_Down_Early als Fahrzeit verwendet
|-
|ASC_Mode_Down ||always, absent, off || ||wann darf die Automatik steuern. immer, niemals, bei abwesenheit des Roomate (ist kein Roommate und absent eingestellt wird gar nicht gesteuert)
|-
|ASC_Mode_Up ||always, absent, off || ||wann darf die Automatik steuern. immer, niemals, bei abwesenheit des Roomate (ist kein Roommate und absent eingestellt wird gar nicht gesteuert)
|-
|ASC_Offset_Minutes_Evening || || ||maximale zufällige Verzögerung in Minuten (minimal 1) bei der Berechnung der Fahrzeiten für Abends
|-
|ASC_Offset_Minutes_Morning || || ||maximale zufällige Verzögerung in Minuten (minimal 1) bei der Berechnung der Fahrzeiten für Morgens
|-
|ASC_Open_Pos || || ||in 10 Schritten von 0 bis 100, default Vorgabe ist abhängig vom Attribut AutoShuttersControl
|-
|ASC_Partymode ||on, off || ||schaltet den Partymodus an oder aus, Wird dann am ASC Device set ASC-DEVICE partyMode on geschalten, werden alle Fahrbefehle an den Rollläden welche das Attribut auf on haben zwischen gespeichert und später erst ausgeführt
|-
|ASC_Pos_Cmd || || ||der set Befehl um den Rollladen in Prozent Angaben zu fahren, muss der selbe sein wie das Reading welches die Position des Rollladen in Prozent an gibt
|-
|ASC_Pos_after_ComfortOpen || || ||in 10 Schritten von 0 bis 100, default Vorgabe ist abhängig vom Attribut AutoShuttersControl
|-
|ASC_Roommate_Reading || || ||das Reading zum Roommate Device welches den Status wieder gibt
|-
|ASC_Roommate_Device || || ||Name des Roommate Devices welcher den Bewohner des Raumes vom Rollladen wieder gibt
|-
|ASC_Time_Down_Early || || ||Sunset frühste Zeit zum runter fahren
|-
|ASC_Time_Down_Late || || ||Sunset späteste Zeit zum runter fahren
|-
|ASC_Time_Up_Early || || ||Sunrise frühste Zeit zum hoch fahren
|-
|ASC_Time_Up_Late || || ||Sunrise späteste Zeit zum hoch fahren
|-
|ASC_Time_Up_WE_Holiday || || ||Sunrise frühste Zeit zum hochfahren am Wochenende und/oder Urlaub (we2holiday wird beachtet), Achtung sollte nicht größer sein wie ASC_Time_Up_Late sonst wird ASC_Time_Up_Late verwendet
|-
|ASC_Up ||astro, time || ||bei Astro wird Sonnenaufgang berechnet, bei time wird der Wert aus ASC_Time_Up_Early als Fahrzeit verwendet
|-
|ASC_Ventilate_Pos || || ||in 10 Schritten von 0 bis 100, default Vorgabe ist abhängig vom Attribut AutoShuttersControl
|-
|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 Fensterkontaktes an welchen Fenster der Rolladen angebracht ist
|-
|ASC_WindowRec_subType || || ||Typ des verwendeten Fensterkontakts: twostate (optisch oder magnetisch) oder threestate (Drehgriffkontakt)
|-
|ASC_lock-out ||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 Rolladen Hardwareseitig zu blockieren. Dann ist auch ein fahren über die Taster nicht mehr möglich.
|-
|ASC_lock-outCmd ||inhibit, blocked || ||set Befehl für das Rolladen-Device zum Hardware sperren. Zum gesetzt werden wenn man "ASC_lock-out" auf hard setzt
|-
| || || ||
|-
|}

== Hilfsmittel ==
tbd

readingsGroup, um die diversen Level einzustellen:

{{Hinweis|Die Readingsgroup muss noch angepasst werden.}}

define rg_ASC_Rollaeden_Level readingsGroup <Gerät>,<Closed_Pos>,<Open_Pos>,<Shading_Pos>,<Ventilate_Pos> (Rolladen_.*|Jalousie_.*)..:?AutoShuttersControl_Closed_Pos,?AutoShuttersControl_Open_Pos,?AutoShuttersControl_Shading_Pos,?AutoShuttesControl_Ventilate_Pos
attr rg_ASC_Rollaeden_Level commands { AutoShuttersControl_Closed_Pos => 'AutoShuttersControl_Closed_Pos:0,10,20,30,35,40,45,50,55,60,65,70,75,80,85,90,95,100',\
AutoShuttersControl_Open_Pos => 'AutoShuttersControl_Open_Pos:0,10,20,30,35,40,45,50,55,60,65,70,75,80,85,90,95,100',\
AutoShuttersControl_Shading_Pos => 'AutoShuttersControl_Shading_Pos:0,10,20,30,35,40,45,50,55,60,65,70,75,80,85,90,95,100',\
AutoShuttersControl_Ventilate_Pos => 'AutoShuttersControl_Ventilate_Pos:0,10,20,30,35,40,45,50,55,60,65,70,75,80,85,90,95,100'}
[[Datei:ReadingsGroup ASC Level.png|600px|]]
readingsGroup, um die diversen Zeiten einzustellen:

define rg_ASC_Rollaeden_Times readingsGroup <Gerät>,<Stand>,<Time_Up_Early>,<Time_Up_WE>,<Time_Up_Late>,<Time_Down_Early>,Time_Down_Late>,<Mode_Down>,<Mode_Up> (Rolladen_.*|Jalousie_.*)..:level,?AutoShuttersControl_Time_Up_Early,?AutoShuttersControl_Time_Up_WE_Holiday,?AutoShuttersControl_Time_Up_Late,?AutoShuttersControl_Time_Down_Early,?AutoShuttersControl_Time_Down_Late,?AutoShuttersControl_Mode_Down,?AutoShuttersControl_Mode_Up
attr rg_ASC_Rollaeden_Times commands {level => 'pct:0,10,20,30,35,40,45,50,55,60,65,70,75,80,85,90,95,100', \
AutoShuttersControl_Mode_Down => 'AutoShuttersControl_Mode_Down:always,absent,off',\
AutoShuttersControl_Mode_Up => 'AutoShuttersControl_Mode_Up:always,absent,off',\
AutoShuttersControl_Time_Down_Early => 'AutoShuttersControl_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', \
AutoShuttersControl_Time_Down_Late => 'AutoShuttersControl_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',\
AutoShuttersControl_Time_Up_Early => 'AutoShuttersControl_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', \
AutoShuttersControl_Time_Up_Late =>'AutoShuttersControl_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',AutoShuttersControl_Time_Up_WE_Holiday => 'AutoShuttersControl_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'}
[[Datei:ReadingsGroup ASC Times.png|600px|]]

== Weblinks ==
* {{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

[[Kategorie:Codeschnipsel]]
[[Kategorie:Rollladensteuerung]]

AutoShuttersControl

2018-10-15T14:55:41Z

Stephan1965: /* Einstellung zentraler Vorgaben */

{{Baustelle}}
{{Infobox Modul
|ModPurpose=Steuerung von Rollläden
|ModCategory=Automatisierung
|ModType=x

|ModForumArea=Automatisierung
|ModTechName=73_AutoShuttersControl.pm
|ModOwner=CoolTux}}
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.

{{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.}}

== Basics ==
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''.

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)

== Einrichtung ==

=== Vorbereitung ===

{{Hinweis|Ihr benötigt ein aktuelles FHEM. Update ab dem 04.09.2018 Voraussetzung!}}

Zunächst müssen das Modul (aus dem Link im Forum) entpackt, die Datei 73_AutoShuttersControl.pm in das Unterverzeichnis für die Module kopiert und die Rechte angepaßt werden.

Speicherort für Linux-Standardinstallationen: /opt/fhem/FHEM
Rechte: <code>sudo chown 73_AutoShuttersControl.pm</code> und <code>sudo chmod 644 73_AutoShuttersControl.pm</code>

Danach sollte ein <code>reload AutoShuttersControl</code> in FHEM-Eingabefeld ausreichen, um das Modul verfügbar zu machen.

{{Hinweis|Eventuell muß FHEM auch einmalig neu gestartet werden, um das Modul nutzen zu können.}}

=== 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 ''AutoShuttersControl'' 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äßt, 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 ''AutoShuttersControl'' 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.

=== 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 ===
Danach sind jeweils 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 AutoShuttersControl Device selbst.===

{|class="wikitable"
|-
! Name !! Datentyp/ Wertebereich !! Bedeutung
|-
|..._nextAstroTimeEvent || ||Uhrzeit des nächsten Astro Events, Sonnenauf, Sonnenuntergang oder feste Zeit pro Rollonamen
|-
|..._lastPosValue || ||letzter abgesetzter Fahrbefehl pro Rollonamen
|-
|..._lastDelayPosValue || ||letzter 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 Schaltbefehle welcher durch ein Fensterevent oder Bewohnerstatus an die Rollläden gesendet wurde, wird beim off setzen durch set ASC-Device partyMode off ausgeführt
|-
|lockOut || on, off ||für das aktivieren des Aussperrschutzes gemäß dem entsprechenden Attribut 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ämen gefunden wurde, Bsp.: room_Schlafzimmer,Terrasse
|-
|state || ||Status des Devices active, enabled, disabled
|-
|sunriseTimeWeHoliday|| on,off ||wird das Rolladen Device Attribut Attributes 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_Sunrise ||Sonnenaufgangszeit für das Rollo
|-
|ASC_Time_Sunset ||Sonnenuntergangszeit für das Rollo
|}

== Settings ==

===Set Befehle für AutoShuttersControl Device===

{|class="wikitable"
|-
! Name !! Datentyp/ Wertebereich !! Beschreibung
|-
|partyMode ||on, off ||aktiviert den globalen Partymodus. Siehe Reading partyMode
|-
|lockOut ||on, off ||aktiviert den globalen Aussperrschutz. Siehe Reading partyMode
|-
|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/2
|-
|sunriseTimeWeHoliday || on,off ||aktiviert/deaktiviert die Beachtung des Rolladen Device Attributes AutoShuttersControl_Time_Up_WE_Holiday
|-
|createNewNotifyDev || ||Legt die interne Struktur für NOTIFYDEV neu an
|-
|selfDefence ||on, off||aktiviert/deaktiviert den Selbstschutz, wenn das Residents Device absent meldet und selfDefence aktiv ist und ein Fenster im Haus steht noch offen, wird an diesem Fenster das Rollo runter gefahren
|}

== Attribute ==

===Attribute im AutoShuttersControl Device selbst.===

{|class="wikitable"
|-
! Name !! Datentyp/ Wertebereich !! Default-Wert !! Beschreibung
|-
|ASC_antifreezeTemp || || ||Temperatur ab welcher der Frostschutz greifen soll und das Rollo nicht mehr fährt. Der letzte Fahrbefehl wird gespeichert.
|-
|ASC_autoAstroModeEvening ||aktuell REAL, CIVIL, NAUTIC, ASTRONOMIC || || (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 || ||(in genau dieser Schreibweise)
|-
|ASC_autoAstroModeMorningHorizon || || ||Höhe über Horizont wenn beim Attribut AutoShuttersControl_autoAstroModeMorning HORIZON ausgewählt
|-
|ASC_autoShuttersControlComfort ||on, off || ||schaltet die Komfortfunktion an. Bedeutet das ein Rollladen mit einem threestate Sensor am Fenster beim öffnen in eine weit offen Position fährt. Die Offenposition wird beim Rollladen über das Attribut AutoShuttersControl_Pos_after_ComfortOpen eingestellt.
|-
|ASC_autoShuttersControlEvening ||on, off || ||ob Abends die Rollläden automatisch nach Zeit gesteuert werden sollen
|-
|ASC_autoShuttersControlMorning ||on, off || ||ob Morgens die Rollläden automatisch nach Zeit gesteuert werden sollen
|-
|ASC_temperatureReading || || ||Reading für die Aussentemperatur
|-
|ASC_temperatureSensor || || ||Device für die Aussentemperatur
|-
|ASC_timeUpHolidayDevice || || ||Device zur Urlaubserkennung oder Sonstiges / muss 0 oder 1 im Reading state beinhalten.
|-
|ASC_residentsDevice|| || ||Devicenamen vom Residents Device der obersten Ebene
|-
|ASC_residentsDeviceReading|| || ||Status Reading vom Residents Device der obersten Ebene
|-
| || || ||
|}

===Attribute in den Rolllädendevices===

{|class="wikitable"
|-
! Name !! Datentyp/ Wertebereich !! Default-Wert !! Beschreibung
|-
|AutoShuttersControl || 0, 1, 2 || ||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 ||on, off || ||Frostschutz an oder aus
|-
|ASC_AutoAstroModeEvening ||aktuell REAL, CIVIL, NAUTIC, ASTRONOMIC || ||
|-
|ASC_AutoAstroModeEveningHorizon || || ||Höhe über Horizont wenn beim Attribut ASC_autoAstroModeEvening HORIZON ausgewählt
|-
|ASC_AutoAstroModeMorning ||aktuell REAL, CIVIL, NAUTIC, ASTRONOMIC || ||
|-
|ASC_AutoAstroModeMorningHorizon || || ||Höhe über Horizont wenn beim Attribut ASC_autoAstroModeMorning HORIZON ausgewählt
|-
|ASC_Closed_Pos || || ||in 10 Schritten von 0 bis 100, default Vorgabe ist abhängig vom Attribut AutoShuttersControl
|-
|ASC_Down ||astro, time || ||bei Astro wird Sonnenuntergang berechnet, bei time wird der Wert aus ASC_Time_Down_Early als Fahrzeit verwendet
|-
|ASC_Mode_Down ||always, absent, off || ||wann darf die Automatik steuern. immer, niemals, bei abwesenheit des Roomate (ist kein Roommate und absent eingestellt wird gar nicht gesteuert)
|-
|ASC_Mode_Up ||always, absent, off || ||wann darf die Automatik steuern. immer, niemals, bei abwesenheit des Roomate (ist kein Roommate und absent eingestellt wird gar nicht gesteuert)
|-
|ASC_Offset_Minutes_Evening || || ||maximale zufällige Verzögerung in Minuten (minimal 1) bei der Berechnung der Fahrzeiten für Abends
|-
|ASC_Offset_Minutes_Morning || || ||maximale zufällige Verzögerung in Minuten (minimal 1) bei der Berechnung der Fahrzeiten für Morgens
|-
|ASC_Open_Pos || || ||in 10 Schritten von 0 bis 100, default Vorgabe ist abhängig vom Attribut AutoShuttersControl
|-
|ASC_Partymode ||on, off || ||schaltet den Partymodus an oder aus, Wird dann am ASC Device set ASC-DEVICE partyMode on geschalten, werden alle Fahrbefehle an den Rollläden welche das Attribut auf on haben zwischen gespeichert und später erst ausgeführt
|-
|ASC_Pos_Cmd || || ||der set Befehl um den Rollladen in Prozent Angaben zu fahren, muss der selbe sein wie das Reading welches die Position des Rollladen in Prozent an gibt
|-
|ASC_Pos_after_ComfortOpen || || ||in 10 Schritten von 0 bis 100, default Vorgabe ist abhängig vom Attribut AutoShuttersControl
|-
|ASC_Roommate_Reading || || ||das Reading zum Roommate Device welches den Status wieder gibt
|-
|ASC_Roommate_Device || || ||Name des Roommate Devices welcher den Bewohner des Raumes vom Rollladen wieder gibt
|-
|ASC_Time_Down_Early || || ||Sunset frühste Zeit zum runter fahren
|-
|ASC_Time_Down_Late || || ||Sunset späteste Zeit zum runter fahren
|-
|ASC_Time_Up_Early || || ||Sunrise frühste Zeit zum hoch fahren
|-
|ASC_Time_Up_Late || || ||Sunrise späteste Zeit zum hoch fahren
|-
|ASC_Time_Up_WE_Holiday || || ||Sunrise frühste Zeit zum hochfahren am Wochenende und/oder Urlaub (we2holiday wird beachtet), Achtung sollte nicht größer sein wie ASC_Time_Up_Late sonst wird ASC_Time_Up_Late verwendet
|-
|ASC_Up ||astro, time || ||bei Astro wird Sonnenaufgang berechnet, bei time wird der Wert aus ASC_Time_Up_Early als Fahrzeit verwendet
|-
|ASC_Ventilate_Pos || || ||in 10 Schritten von 0 bis 100, default Vorgabe ist abhängig vom Attribut AutoShuttersControl
|-
|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 Fensterkontaktes an welchen Fenster der Rolladen angebracht ist
|-
|ASC_WindowRec_subType || || ||Typ des verwendeten Fensterkontakts: twostate (optisch oder magnetisch) oder threestate (Drehgriffkontakt)
|-
|ASC_lock-out ||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 Rolladen Hardwareseitig zu blockieren. Dann ist auch ein fahren über die Taster nicht mehr möglich.
|-
|ASC_lock-outCmd ||inhibit, blocked || ||set Befehl für das Rolladen-Device zum Hardware sperren. Zum gesetzt werden wenn man "ASC_lock-out" auf hard setzt
|-
| || || ||
|-
|}

== Hilfsmittel ==
tbd

readingsGroup, um die diversen Level einzustellen:

{{Hinweis|Die Readingsgroup muss noch angepasst werden.}}

define rg_ASC_Rollaeden_Level readingsGroup <Gerät>,<Closed_Pos>,<Open_Pos>,<Shading_Pos>,<Ventilate_Pos> (Rolladen_.*|Jalousie_.*)..:?AutoShuttersControl_Closed_Pos,?AutoShuttersControl_Open_Pos,?AutoShuttersControl_Shading_Pos,?AutoShuttesControl_Ventilate_Pos
attr rg_ASC_Rollaeden_Level commands { AutoShuttersControl_Closed_Pos => 'AutoShuttersControl_Closed_Pos:0,10,20,30,35,40,45,50,55,60,65,70,75,80,85,90,95,100',\
AutoShuttersControl_Open_Pos => 'AutoShuttersControl_Open_Pos:0,10,20,30,35,40,45,50,55,60,65,70,75,80,85,90,95,100',\
AutoShuttersControl_Shading_Pos => 'AutoShuttersControl_Shading_Pos:0,10,20,30,35,40,45,50,55,60,65,70,75,80,85,90,95,100',\
AutoShuttersControl_Ventilate_Pos => 'AutoShuttersControl_Ventilate_Pos:0,10,20,30,35,40,45,50,55,60,65,70,75,80,85,90,95,100'}
[[Datei:ReadingsGroup ASC Level.png|600px|]]
readingsGroup, um die diversen Zeiten einzustellen:

define rg_ASC_Rollaeden_Times readingsGroup <Gerät>,<Stand>,<Time_Up_Early>,<Time_Up_WE>,<Time_Up_Late>,<Time_Down_Early>,Time_Down_Late>,<Mode_Down>,<Mode_Up> (Rolladen_.*|Jalousie_.*)..:level,?AutoShuttersControl_Time_Up_Early,?AutoShuttersControl_Time_Up_WE_Holiday,?AutoShuttersControl_Time_Up_Late,?AutoShuttersControl_Time_Down_Early,?AutoShuttersControl_Time_Down_Late,?AutoShuttersControl_Mode_Down,?AutoShuttersControl_Mode_Up
attr rg_ASC_Rollaeden_Times commands {level => 'pct:0,10,20,30,35,40,45,50,55,60,65,70,75,80,85,90,95,100', \
AutoShuttersControl_Mode_Down => 'AutoShuttersControl_Mode_Down:always,absent,off',\
AutoShuttersControl_Mode_Up => 'AutoShuttersControl_Mode_Up:always,absent,off',\
AutoShuttersControl_Time_Down_Early => 'AutoShuttersControl_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', \
AutoShuttersControl_Time_Down_Late => 'AutoShuttersControl_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',\
AutoShuttersControl_Time_Up_Early => 'AutoShuttersControl_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', \
AutoShuttersControl_Time_Up_Late =>'AutoShuttersControl_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',AutoShuttersControl_Time_Up_WE_Holiday => 'AutoShuttersControl_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'}
[[Datei:ReadingsGroup ASC Times.png|600px|]]

== Weblinks ==
* {{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

[[Kategorie:Codeschnipsel]]
[[Kategorie:Rollladensteuerung]]

AutoShuttersControl

2018-10-15T14:53:33Z

Stephan1965: /* Vorbereitung */

{{Baustelle}}
{{Infobox Modul
|ModPurpose=Steuerung von Rollläden
|ModCategory=Automatisierung
|ModType=x

|ModForumArea=Automatisierung
|ModTechName=73_AutoShuttersControl.pm
|ModOwner=CoolTux}}
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.

{{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.}}

== Basics ==
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''.

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)

== Einrichtung ==

=== Vorbereitung ===

{{Hinweis|Ihr benötigt ein aktuelles FHEM. Update ab dem 04.09.2018 Voraussetzung!}}

Zunächst müssen das Modul (aus dem Link im Forum) entpackt, die Datei 73_AutoShuttersControl.pm in das Unterverzeichnis für die Module kopiert und die Rechte angepaßt werden.

Speicherort für Linux-Standardinstallationen: /opt/fhem/FHEM
Rechte: <code>sudo chown 73_AutoShuttersControl.pm</code> und <code>sudo chmod 644 73_AutoShuttersControl.pm</code>

Danach sollte ein <code>reload AutoShuttersControl</code> in FHEM-Eingabefeld ausreichen, um das Modul verfügbar zu machen.

{{Hinweis|Eventuell muß FHEM auch einmalig neu gestartet werden, um das Modul nutzen zu können.}}

=== 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 ''AutoShuttersControl'' 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äßt, 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 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 ''AutoShuttersControl'' 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.

=== 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 ===
Danach sind jeweils 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 AutoShuttersControl Device selbst.===

{|class="wikitable"
|-
! Name !! Datentyp/ Wertebereich !! Bedeutung
|-
|..._nextAstroTimeEvent || ||Uhrzeit des nächsten Astro Events, Sonnenauf, Sonnenuntergang oder feste Zeit pro Rollonamen
|-
|..._lastPosValue || ||letzter abgesetzter Fahrbefehl pro Rollonamen
|-
|..._lastDelayPosValue || ||letzter 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 Schaltbefehle welcher durch ein Fensterevent oder Bewohnerstatus an die Rollläden gesendet wurde, wird beim off setzen durch set ASC-Device partyMode off ausgeführt
|-
|lockOut || on, off ||für das aktivieren des Aussperrschutzes gemäß dem entsprechenden Attribut 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ämen gefunden wurde, Bsp.: room_Schlafzimmer,Terrasse
|-
|state || ||Status des Devices active, enabled, disabled
|-
|sunriseTimeWeHoliday|| on,off ||wird das Rolladen Device Attribut Attributes 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_Sunrise ||Sonnenaufgangszeit für das Rollo
|-
|ASC_Time_Sunset ||Sonnenuntergangszeit für das Rollo
|}

== Settings ==

===Set Befehle für AutoShuttersControl Device===

{|class="wikitable"
|-
! Name !! Datentyp/ Wertebereich !! Beschreibung
|-
|partyMode ||on, off ||aktiviert den globalen Partymodus. Siehe Reading partyMode
|-
|lockOut ||on, off ||aktiviert den globalen Aussperrschutz. Siehe Reading partyMode
|-
|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/2
|-
|sunriseTimeWeHoliday || on,off ||aktiviert/deaktiviert die Beachtung des Rolladen Device Attributes AutoShuttersControl_Time_Up_WE_Holiday
|-
|createNewNotifyDev || ||Legt die interne Struktur für NOTIFYDEV neu an
|-
|selfDefence ||on, off||aktiviert/deaktiviert den Selbstschutz, wenn das Residents Device absent meldet und selfDefence aktiv ist und ein Fenster im Haus steht noch offen, wird an diesem Fenster das Rollo runter gefahren
|}

== Attribute ==

===Attribute im AutoShuttersControl Device selbst.===

{|class="wikitable"
|-
! Name !! Datentyp/ Wertebereich !! Default-Wert !! Beschreibung
|-
|ASC_antifreezeTemp || || ||Temperatur ab welcher der Frostschutz greifen soll und das Rollo nicht mehr fährt. Der letzte Fahrbefehl wird gespeichert.
|-
|ASC_autoAstroModeEvening ||aktuell REAL, CIVIL, NAUTIC, ASTRONOMIC || || (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 || ||(in genau dieser Schreibweise)
|-
|ASC_autoAstroModeMorningHorizon || || ||Höhe über Horizont wenn beim Attribut AutoShuttersControl_autoAstroModeMorning HORIZON ausgewählt
|-
|ASC_autoShuttersControlComfort ||on, off || ||schaltet die Komfortfunktion an. Bedeutet das ein Rollladen mit einem threestate Sensor am Fenster beim öffnen in eine weit offen Position fährt. Die Offenposition wird beim Rollladen über das Attribut AutoShuttersControl_Pos_after_ComfortOpen eingestellt.
|-
|ASC_autoShuttersControlEvening ||on, off || ||ob Abends die Rollläden automatisch nach Zeit gesteuert werden sollen
|-
|ASC_autoShuttersControlMorning ||on, off || ||ob Morgens die Rollläden automatisch nach Zeit gesteuert werden sollen
|-
|ASC_temperatureReading || || ||Reading für die Aussentemperatur
|-
|ASC_temperatureSensor || || ||Device für die Aussentemperatur
|-
|ASC_timeUpHolidayDevice || || ||Device zur Urlaubserkennung oder Sonstiges / muss 0 oder 1 im Reading state beinhalten.
|-
|ASC_residentsDevice|| || ||Devicenamen vom Residents Device der obersten Ebene
|-
|ASC_residentsDeviceReading|| || ||Status Reading vom Residents Device der obersten Ebene
|-
| || || ||
|}

===Attribute in den Rolllädendevices===

{|class="wikitable"
|-
! Name !! Datentyp/ Wertebereich !! Default-Wert !! Beschreibung
|-
|AutoShuttersControl || 0, 1, 2 || ||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 ||on, off || ||Frostschutz an oder aus
|-
|ASC_AutoAstroModeEvening ||aktuell REAL, CIVIL, NAUTIC, ASTRONOMIC || ||
|-
|ASC_AutoAstroModeEveningHorizon || || ||Höhe über Horizont wenn beim Attribut ASC_autoAstroModeEvening HORIZON ausgewählt
|-
|ASC_AutoAstroModeMorning ||aktuell REAL, CIVIL, NAUTIC, ASTRONOMIC || ||
|-
|ASC_AutoAstroModeMorningHorizon || || ||Höhe über Horizont wenn beim Attribut ASC_autoAstroModeMorning HORIZON ausgewählt
|-
|ASC_Closed_Pos || || ||in 10 Schritten von 0 bis 100, default Vorgabe ist abhängig vom Attribut AutoShuttersControl
|-
|ASC_Down ||astro, time || ||bei Astro wird Sonnenuntergang berechnet, bei time wird der Wert aus ASC_Time_Down_Early als Fahrzeit verwendet
|-
|ASC_Mode_Down ||always, absent, off || ||wann darf die Automatik steuern. immer, niemals, bei abwesenheit des Roomate (ist kein Roommate und absent eingestellt wird gar nicht gesteuert)
|-
|ASC_Mode_Up ||always, absent, off || ||wann darf die Automatik steuern. immer, niemals, bei abwesenheit des Roomate (ist kein Roommate und absent eingestellt wird gar nicht gesteuert)
|-
|ASC_Offset_Minutes_Evening || || ||maximale zufällige Verzögerung in Minuten (minimal 1) bei der Berechnung der Fahrzeiten für Abends
|-
|ASC_Offset_Minutes_Morning || || ||maximale zufällige Verzögerung in Minuten (minimal 1) bei der Berechnung der Fahrzeiten für Morgens
|-
|ASC_Open_Pos || || ||in 10 Schritten von 0 bis 100, default Vorgabe ist abhängig vom Attribut AutoShuttersControl
|-
|ASC_Partymode ||on, off || ||schaltet den Partymodus an oder aus, Wird dann am ASC Device set ASC-DEVICE partyMode on geschalten, werden alle Fahrbefehle an den Rollläden welche das Attribut auf on haben zwischen gespeichert und später erst ausgeführt
|-
|ASC_Pos_Cmd || || ||der set Befehl um den Rollladen in Prozent Angaben zu fahren, muss der selbe sein wie das Reading welches die Position des Rollladen in Prozent an gibt
|-
|ASC_Pos_after_ComfortOpen || || ||in 10 Schritten von 0 bis 100, default Vorgabe ist abhängig vom Attribut AutoShuttersControl
|-
|ASC_Roommate_Reading || || ||das Reading zum Roommate Device welches den Status wieder gibt
|-
|ASC_Roommate_Device || || ||Name des Roommate Devices welcher den Bewohner des Raumes vom Rollladen wieder gibt
|-
|ASC_Time_Down_Early || || ||Sunset frühste Zeit zum runter fahren
|-
|ASC_Time_Down_Late || || ||Sunset späteste Zeit zum runter fahren
|-
|ASC_Time_Up_Early || || ||Sunrise frühste Zeit zum hoch fahren
|-
|ASC_Time_Up_Late || || ||Sunrise späteste Zeit zum hoch fahren
|-
|ASC_Time_Up_WE_Holiday || || ||Sunrise frühste Zeit zum hochfahren am Wochenende und/oder Urlaub (we2holiday wird beachtet), Achtung sollte nicht größer sein wie ASC_Time_Up_Late sonst wird ASC_Time_Up_Late verwendet
|-
|ASC_Up ||astro, time || ||bei Astro wird Sonnenaufgang berechnet, bei time wird der Wert aus ASC_Time_Up_Early als Fahrzeit verwendet
|-
|ASC_Ventilate_Pos || || ||in 10 Schritten von 0 bis 100, default Vorgabe ist abhängig vom Attribut AutoShuttersControl
|-
|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 Fensterkontaktes an welchen Fenster der Rolladen angebracht ist
|-
|ASC_WindowRec_subType || || ||Typ des verwendeten Fensterkontakts: twostate (optisch oder magnetisch) oder threestate (Drehgriffkontakt)
|-
|ASC_lock-out ||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 Rolladen Hardwareseitig zu blockieren. Dann ist auch ein fahren über die Taster nicht mehr möglich.
|-
|ASC_lock-outCmd ||inhibit, blocked || ||set Befehl für das Rolladen-Device zum Hardware sperren. Zum gesetzt werden wenn man "ASC_lock-out" auf hard setzt
|-
| || || ||
|-
|}

== Hilfsmittel ==
tbd

readingsGroup, um die diversen Level einzustellen:

{{Hinweis|Die Readingsgroup muss noch angepasst werden.}}

define rg_ASC_Rollaeden_Level readingsGroup <Gerät>,<Closed_Pos>,<Open_Pos>,<Shading_Pos>,<Ventilate_Pos> (Rolladen_.*|Jalousie_.*)..:?AutoShuttersControl_Closed_Pos,?AutoShuttersControl_Open_Pos,?AutoShuttersControl_Shading_Pos,?AutoShuttesControl_Ventilate_Pos
attr rg_ASC_Rollaeden_Level commands { AutoShuttersControl_Closed_Pos => 'AutoShuttersControl_Closed_Pos:0,10,20,30,35,40,45,50,55,60,65,70,75,80,85,90,95,100',\
AutoShuttersControl_Open_Pos => 'AutoShuttersControl_Open_Pos:0,10,20,30,35,40,45,50,55,60,65,70,75,80,85,90,95,100',\
AutoShuttersControl_Shading_Pos => 'AutoShuttersControl_Shading_Pos:0,10,20,30,35,40,45,50,55,60,65,70,75,80,85,90,95,100',\
AutoShuttersControl_Ventilate_Pos => 'AutoShuttersControl_Ventilate_Pos:0,10,20,30,35,40,45,50,55,60,65,70,75,80,85,90,95,100'}
[[Datei:ReadingsGroup ASC Level.png|600px|]]
readingsGroup, um die diversen Zeiten einzustellen:

define rg_ASC_Rollaeden_Times readingsGroup <Gerät>,<Stand>,<Time_Up_Early>,<Time_Up_WE>,<Time_Up_Late>,<Time_Down_Early>,Time_Down_Late>,<Mode_Down>,<Mode_Up> (Rolladen_.*|Jalousie_.*)..:level,?AutoShuttersControl_Time_Up_Early,?AutoShuttersControl_Time_Up_WE_Holiday,?AutoShuttersControl_Time_Up_Late,?AutoShuttersControl_Time_Down_Early,?AutoShuttersControl_Time_Down_Late,?AutoShuttersControl_Mode_Down,?AutoShuttersControl_Mode_Up
attr rg_ASC_Rollaeden_Times commands {level => 'pct:0,10,20,30,35,40,45,50,55,60,65,70,75,80,85,90,95,100', \
AutoShuttersControl_Mode_Down => 'AutoShuttersControl_Mode_Down:always,absent,off',\
AutoShuttersControl_Mode_Up => 'AutoShuttersControl_Mode_Up:always,absent,off',\
AutoShuttersControl_Time_Down_Early => 'AutoShuttersControl_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', \
AutoShuttersControl_Time_Down_Late => 'AutoShuttersControl_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',\
AutoShuttersControl_Time_Up_Early => 'AutoShuttersControl_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', \
AutoShuttersControl_Time_Up_Late =>'AutoShuttersControl_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',AutoShuttersControl_Time_Up_WE_Holiday => 'AutoShuttersControl_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'}
[[Datei:ReadingsGroup ASC Times.png|600px|]]

== Weblinks ==
* {{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

[[Kategorie:Codeschnipsel]]
[[Kategorie:Rollladensteuerung]]

AutoShuttersControl

2018-10-15T14:52:38Z

Stephan1965: /* Vorbereitung */

{{Baustelle}}
{{Infobox Modul
|ModPurpose=Steuerung von Rollläden
|ModCategory=Automatisierung
|ModType=x

|ModForumArea=Automatisierung
|ModTechName=73_AutoShuttersControl.pm
|ModOwner=CoolTux}}
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.

{{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.}}

== Basics ==
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''.

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)

== Einrichtung ==

=== Vorbereitung ===

{{Hinweis|Ihr benötigt ein aktuelles FHEM. Update ab dem 04.09.2018 Voraussetzung!}}

Zunächst muß das Modul (aus dem Link im Forum) entpackt, die Datei 73_AutoShuttersControl.pm in das Unterverzeichnis für die Module kopiert und die Rechte angepaßt werden.

Speicherort für Linux-Standardinstallationen: /opt/fhem/FHEM
Rechte: <code>sudo chown 73_AutoShuttersControl.pm</code> und <code>sudo chmod 644 73_AutoShuttersControl.pm</code>

Danach sollte ein <code>reload AutoShuttersControl</code> in FHEM-Eingabefeld ausreichen, um das Modul verfügbar zu machen.

{{Hinweis|Eventuell muß FHEM auch einmalig neu gestartet werden, um das Modul nutzen zu können.}}

=== 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 ''AutoShuttersControl'' 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äßt, 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 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 ''AutoShuttersControl'' 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.

=== 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 ===
Danach sind jeweils 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 AutoShuttersControl Device selbst.===

{|class="wikitable"
|-
! Name !! Datentyp/ Wertebereich !! Bedeutung
|-
|..._nextAstroTimeEvent || ||Uhrzeit des nächsten Astro Events, Sonnenauf, Sonnenuntergang oder feste Zeit pro Rollonamen
|-
|..._lastPosValue || ||letzter abgesetzter Fahrbefehl pro Rollonamen
|-
|..._lastDelayPosValue || ||letzter 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 Schaltbefehle welcher durch ein Fensterevent oder Bewohnerstatus an die Rollläden gesendet wurde, wird beim off setzen durch set ASC-Device partyMode off ausgeführt
|-
|lockOut || on, off ||für das aktivieren des Aussperrschutzes gemäß dem entsprechenden Attribut 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ämen gefunden wurde, Bsp.: room_Schlafzimmer,Terrasse
|-
|state || ||Status des Devices active, enabled, disabled
|-
|sunriseTimeWeHoliday|| on,off ||wird das Rolladen Device Attribut Attributes 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_Sunrise ||Sonnenaufgangszeit für das Rollo
|-
|ASC_Time_Sunset ||Sonnenuntergangszeit für das Rollo
|}

== Settings ==

===Set Befehle für AutoShuttersControl Device===

{|class="wikitable"
|-
! Name !! Datentyp/ Wertebereich !! Beschreibung
|-
|partyMode ||on, off ||aktiviert den globalen Partymodus. Siehe Reading partyMode
|-
|lockOut ||on, off ||aktiviert den globalen Aussperrschutz. Siehe Reading partyMode
|-
|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/2
|-
|sunriseTimeWeHoliday || on,off ||aktiviert/deaktiviert die Beachtung des Rolladen Device Attributes AutoShuttersControl_Time_Up_WE_Holiday
|-
|createNewNotifyDev || ||Legt die interne Struktur für NOTIFYDEV neu an
|-
|selfDefence ||on, off||aktiviert/deaktiviert den Selbstschutz, wenn das Residents Device absent meldet und selfDefence aktiv ist und ein Fenster im Haus steht noch offen, wird an diesem Fenster das Rollo runter gefahren
|}

== Attribute ==

===Attribute im AutoShuttersControl Device selbst.===

{|class="wikitable"
|-
! Name !! Datentyp/ Wertebereich !! Default-Wert !! Beschreibung
|-
|ASC_antifreezeTemp || || ||Temperatur ab welcher der Frostschutz greifen soll und das Rollo nicht mehr fährt. Der letzte Fahrbefehl wird gespeichert.
|-
|ASC_autoAstroModeEvening ||aktuell REAL, CIVIL, NAUTIC, ASTRONOMIC || || (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 || ||(in genau dieser Schreibweise)
|-
|ASC_autoAstroModeMorningHorizon || || ||Höhe über Horizont wenn beim Attribut AutoShuttersControl_autoAstroModeMorning HORIZON ausgewählt
|-
|ASC_autoShuttersControlComfort ||on, off || ||schaltet die Komfortfunktion an. Bedeutet das ein Rollladen mit einem threestate Sensor am Fenster beim öffnen in eine weit offen Position fährt. Die Offenposition wird beim Rollladen über das Attribut AutoShuttersControl_Pos_after_ComfortOpen eingestellt.
|-
|ASC_autoShuttersControlEvening ||on, off || ||ob Abends die Rollläden automatisch nach Zeit gesteuert werden sollen
|-
|ASC_autoShuttersControlMorning ||on, off || ||ob Morgens die Rollläden automatisch nach Zeit gesteuert werden sollen
|-
|ASC_temperatureReading || || ||Reading für die Aussentemperatur
|-
|ASC_temperatureSensor || || ||Device für die Aussentemperatur
|-
|ASC_timeUpHolidayDevice || || ||Device zur Urlaubserkennung oder Sonstiges / muss 0 oder 1 im Reading state beinhalten.
|-
|ASC_residentsDevice|| || ||Devicenamen vom Residents Device der obersten Ebene
|-
|ASC_residentsDeviceReading|| || ||Status Reading vom Residents Device der obersten Ebene
|-
| || || ||
|}

===Attribute in den Rolllädendevices===

{|class="wikitable"
|-
! Name !! Datentyp/ Wertebereich !! Default-Wert !! Beschreibung
|-
|AutoShuttersControl || 0, 1, 2 || ||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 ||on, off || ||Frostschutz an oder aus
|-
|ASC_AutoAstroModeEvening ||aktuell REAL, CIVIL, NAUTIC, ASTRONOMIC || ||
|-
|ASC_AutoAstroModeEveningHorizon || || ||Höhe über Horizont wenn beim Attribut ASC_autoAstroModeEvening HORIZON ausgewählt
|-
|ASC_AutoAstroModeMorning ||aktuell REAL, CIVIL, NAUTIC, ASTRONOMIC || ||
|-
|ASC_AutoAstroModeMorningHorizon || || ||Höhe über Horizont wenn beim Attribut ASC_autoAstroModeMorning HORIZON ausgewählt
|-
|ASC_Closed_Pos || || ||in 10 Schritten von 0 bis 100, default Vorgabe ist abhängig vom Attribut AutoShuttersControl
|-
|ASC_Down ||astro, time || ||bei Astro wird Sonnenuntergang berechnet, bei time wird der Wert aus ASC_Time_Down_Early als Fahrzeit verwendet
|-
|ASC_Mode_Down ||always, absent, off || ||wann darf die Automatik steuern. immer, niemals, bei abwesenheit des Roomate (ist kein Roommate und absent eingestellt wird gar nicht gesteuert)
|-
|ASC_Mode_Up ||always, absent, off || ||wann darf die Automatik steuern. immer, niemals, bei abwesenheit des Roomate (ist kein Roommate und absent eingestellt wird gar nicht gesteuert)
|-
|ASC_Offset_Minutes_Evening || || ||maximale zufällige Verzögerung in Minuten (minimal 1) bei der Berechnung der Fahrzeiten für Abends
|-
|ASC_Offset_Minutes_Morning || || ||maximale zufällige Verzögerung in Minuten (minimal 1) bei der Berechnung der Fahrzeiten für Morgens
|-
|ASC_Open_Pos || || ||in 10 Schritten von 0 bis 100, default Vorgabe ist abhängig vom Attribut AutoShuttersControl
|-
|ASC_Partymode ||on, off || ||schaltet den Partymodus an oder aus, Wird dann am ASC Device set ASC-DEVICE partyMode on geschalten, werden alle Fahrbefehle an den Rollläden welche das Attribut auf on haben zwischen gespeichert und später erst ausgeführt
|-
|ASC_Pos_Cmd || || ||der set Befehl um den Rollladen in Prozent Angaben zu fahren, muss der selbe sein wie das Reading welches die Position des Rollladen in Prozent an gibt
|-
|ASC_Pos_after_ComfortOpen || || ||in 10 Schritten von 0 bis 100, default Vorgabe ist abhängig vom Attribut AutoShuttersControl
|-
|ASC_Roommate_Reading || || ||das Reading zum Roommate Device welches den Status wieder gibt
|-
|ASC_Roommate_Device || || ||Name des Roommate Devices welcher den Bewohner des Raumes vom Rollladen wieder gibt
|-
|ASC_Time_Down_Early || || ||Sunset frühste Zeit zum runter fahren
|-
|ASC_Time_Down_Late || || ||Sunset späteste Zeit zum runter fahren
|-
|ASC_Time_Up_Early || || ||Sunrise frühste Zeit zum hoch fahren
|-
|ASC_Time_Up_Late || || ||Sunrise späteste Zeit zum hoch fahren
|-
|ASC_Time_Up_WE_Holiday || || ||Sunrise frühste Zeit zum hochfahren am Wochenende und/oder Urlaub (we2holiday wird beachtet), Achtung sollte nicht größer sein wie ASC_Time_Up_Late sonst wird ASC_Time_Up_Late verwendet
|-
|ASC_Up ||astro, time || ||bei Astro wird Sonnenaufgang berechnet, bei time wird der Wert aus ASC_Time_Up_Early als Fahrzeit verwendet
|-
|ASC_Ventilate_Pos || || ||in 10 Schritten von 0 bis 100, default Vorgabe ist abhängig vom Attribut AutoShuttersControl
|-
|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 Fensterkontaktes an welchen Fenster der Rolladen angebracht ist
|-
|ASC_WindowRec_subType || || ||Typ des verwendeten Fensterkontakts: twostate (optisch oder magnetisch) oder threestate (Drehgriffkontakt)
|-
|ASC_lock-out ||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 Rolladen Hardwareseitig zu blockieren. Dann ist auch ein fahren über die Taster nicht mehr möglich.
|-
|ASC_lock-outCmd ||inhibit, blocked || ||set Befehl für das Rolladen-Device zum Hardware sperren. Zum gesetzt werden wenn man "ASC_lock-out" auf hard setzt
|-
| || || ||
|-
|}

== Hilfsmittel ==
tbd

readingsGroup, um die diversen Level einzustellen:

{{Hinweis|Die Readingsgroup muss noch angepasst werden.}}

define rg_ASC_Rollaeden_Level readingsGroup <Gerät>,<Closed_Pos>,<Open_Pos>,<Shading_Pos>,<Ventilate_Pos> (Rolladen_.*|Jalousie_.*)..:?AutoShuttersControl_Closed_Pos,?AutoShuttersControl_Open_Pos,?AutoShuttersControl_Shading_Pos,?AutoShuttesControl_Ventilate_Pos
attr rg_ASC_Rollaeden_Level commands { AutoShuttersControl_Closed_Pos => 'AutoShuttersControl_Closed_Pos:0,10,20,30,35,40,45,50,55,60,65,70,75,80,85,90,95,100',\
AutoShuttersControl_Open_Pos => 'AutoShuttersControl_Open_Pos:0,10,20,30,35,40,45,50,55,60,65,70,75,80,85,90,95,100',\
AutoShuttersControl_Shading_Pos => 'AutoShuttersControl_Shading_Pos:0,10,20,30,35,40,45,50,55,60,65,70,75,80,85,90,95,100',\
AutoShuttersControl_Ventilate_Pos => 'AutoShuttersControl_Ventilate_Pos:0,10,20,30,35,40,45,50,55,60,65,70,75,80,85,90,95,100'}
[[Datei:ReadingsGroup ASC Level.png|600px|]]
readingsGroup, um die diversen Zeiten einzustellen:

define rg_ASC_Rollaeden_Times readingsGroup <Gerät>,<Stand>,<Time_Up_Early>,<Time_Up_WE>,<Time_Up_Late>,<Time_Down_Early>,Time_Down_Late>,<Mode_Down>,<Mode_Up> (Rolladen_.*|Jalousie_.*)..:level,?AutoShuttersControl_Time_Up_Early,?AutoShuttersControl_Time_Up_WE_Holiday,?AutoShuttersControl_Time_Up_Late,?AutoShuttersControl_Time_Down_Early,?AutoShuttersControl_Time_Down_Late,?AutoShuttersControl_Mode_Down,?AutoShuttersControl_Mode_Up
attr rg_ASC_Rollaeden_Times commands {level => 'pct:0,10,20,30,35,40,45,50,55,60,65,70,75,80,85,90,95,100', \
AutoShuttersControl_Mode_Down => 'AutoShuttersControl_Mode_Down:always,absent,off',\
AutoShuttersControl_Mode_Up => 'AutoShuttersControl_Mode_Up:always,absent,off',\
AutoShuttersControl_Time_Down_Early => 'AutoShuttersControl_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', \
AutoShuttersControl_Time_Down_Late => 'AutoShuttersControl_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',\
AutoShuttersControl_Time_Up_Early => 'AutoShuttersControl_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', \
AutoShuttersControl_Time_Up_Late =>'AutoShuttersControl_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',AutoShuttersControl_Time_Up_WE_Holiday => 'AutoShuttersControl_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'}
[[Datei:ReadingsGroup ASC Times.png|600px|]]

== Weblinks ==
* {{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

[[Kategorie:Codeschnipsel]]
[[Kategorie:Rollladensteuerung]]

AutoShuttersControl

2018-10-15T14:48:47Z

Stephan1965: /* Hilfsmittel */

{{Baustelle}}
{{Infobox Modul
|ModPurpose=Steuerung von Rollläden
|ModCategory=Automatisierung
|ModType=x

|ModForumArea=Automatisierung
|ModTechName=73_AutoShuttersControl.pm
|ModOwner=CoolTux}}
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.

{{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.}}

== Basics ==
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''.

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)

== Einrichtung ==

=== Vorbereitung ===

{{Hinweis|Ihr benötigt ein aktuelles FHEM. Update ab dem 04.09.2018 Voraussetzung!}}

Zunächst muß das Modul aus dem Link im Forum entpackt werden und die Datei 73_AutoShuttersControl.pm in das Unterverzeichnis für die Module kopiert werden und die Rechte angepaßt.

Speicherort für Linux-Standardinstallationen: /opt/fhem/FHEM
Rechte: <code>sudo chown 73_AutoShuttersControl.pm</code> und <code>sudo chmod 644 73_AutoShuttersControl.pm</code>

Danach sollte ein <code>reload AutoShuttersControl</code> in FHEM-Eingabefeld ausreichen, um das Modul verfügbar zu machen.

{{Hinweis|Eventuell muß FHEM auch einmalig neu gestartet werden, um das Modul nutzen zu können.}}

=== 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 ''AutoShuttersControl'' 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äßt, 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 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 ''AutoShuttersControl'' 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.

=== 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 ===
Danach sind jeweils 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 AutoShuttersControl Device selbst.===

{|class="wikitable"
|-
! Name !! Datentyp/ Wertebereich !! Bedeutung
|-
|..._nextAstroTimeEvent || ||Uhrzeit des nächsten Astro Events, Sonnenauf, Sonnenuntergang oder feste Zeit pro Rollonamen
|-
|..._lastPosValue || ||letzter abgesetzter Fahrbefehl pro Rollonamen
|-
|..._lastDelayPosValue || ||letzter 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 Schaltbefehle welcher durch ein Fensterevent oder Bewohnerstatus an die Rollläden gesendet wurde, wird beim off setzen durch set ASC-Device partyMode off ausgeführt
|-
|lockOut || on, off ||für das aktivieren des Aussperrschutzes gemäß dem entsprechenden Attribut 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ämen gefunden wurde, Bsp.: room_Schlafzimmer,Terrasse
|-
|state || ||Status des Devices active, enabled, disabled
|-
|sunriseTimeWeHoliday|| on,off ||wird das Rolladen Device Attribut Attributes 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_Sunrise ||Sonnenaufgangszeit für das Rollo
|-
|ASC_Time_Sunset ||Sonnenuntergangszeit für das Rollo
|}

== Settings ==

===Set Befehle für AutoShuttersControl Device===

{|class="wikitable"
|-
! Name !! Datentyp/ Wertebereich !! Beschreibung
|-
|partyMode ||on, off ||aktiviert den globalen Partymodus. Siehe Reading partyMode
|-
|lockOut ||on, off ||aktiviert den globalen Aussperrschutz. Siehe Reading partyMode
|-
|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/2
|-
|sunriseTimeWeHoliday || on,off ||aktiviert/deaktiviert die Beachtung des Rolladen Device Attributes AutoShuttersControl_Time_Up_WE_Holiday
|-
|createNewNotifyDev || ||Legt die interne Struktur für NOTIFYDEV neu an
|-
|selfDefence ||on, off||aktiviert/deaktiviert den Selbstschutz, wenn das Residents Device absent meldet und selfDefence aktiv ist und ein Fenster im Haus steht noch offen, wird an diesem Fenster das Rollo runter gefahren
|}

== Attribute ==

===Attribute im AutoShuttersControl Device selbst.===

{|class="wikitable"
|-
! Name !! Datentyp/ Wertebereich !! Default-Wert !! Beschreibung
|-
|ASC_antifreezeTemp || || ||Temperatur ab welcher der Frostschutz greifen soll und das Rollo nicht mehr fährt. Der letzte Fahrbefehl wird gespeichert.
|-
|ASC_autoAstroModeEvening ||aktuell REAL, CIVIL, NAUTIC, ASTRONOMIC || || (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 || ||(in genau dieser Schreibweise)
|-
|ASC_autoAstroModeMorningHorizon || || ||Höhe über Horizont wenn beim Attribut AutoShuttersControl_autoAstroModeMorning HORIZON ausgewählt
|-
|ASC_autoShuttersControlComfort ||on, off || ||schaltet die Komfortfunktion an. Bedeutet das ein Rollladen mit einem threestate Sensor am Fenster beim öffnen in eine weit offen Position fährt. Die Offenposition wird beim Rollladen über das Attribut AutoShuttersControl_Pos_after_ComfortOpen eingestellt.
|-
|ASC_autoShuttersControlEvening ||on, off || ||ob Abends die Rollläden automatisch nach Zeit gesteuert werden sollen
|-
|ASC_autoShuttersControlMorning ||on, off || ||ob Morgens die Rollläden automatisch nach Zeit gesteuert werden sollen
|-
|ASC_temperatureReading || || ||Reading für die Aussentemperatur
|-
|ASC_temperatureSensor || || ||Device für die Aussentemperatur
|-
|ASC_timeUpHolidayDevice || || ||Device zur Urlaubserkennung oder Sonstiges / muss 0 oder 1 im Reading state beinhalten.
|-
|ASC_residentsDevice|| || ||Devicenamen vom Residents Device der obersten Ebene
|-
|ASC_residentsDeviceReading|| || ||Status Reading vom Residents Device der obersten Ebene
|-
| || || ||
|}

===Attribute in den Rolllädendevices===

{|class="wikitable"
|-
! Name !! Datentyp/ Wertebereich !! Default-Wert !! Beschreibung
|-
|AutoShuttersControl || 0, 1, 2 || ||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 ||on, off || ||Frostschutz an oder aus
|-
|ASC_AutoAstroModeEvening ||aktuell REAL, CIVIL, NAUTIC, ASTRONOMIC || ||
|-
|ASC_AutoAstroModeEveningHorizon || || ||Höhe über Horizont wenn beim Attribut ASC_autoAstroModeEvening HORIZON ausgewählt
|-
|ASC_AutoAstroModeMorning ||aktuell REAL, CIVIL, NAUTIC, ASTRONOMIC || ||
|-
|ASC_AutoAstroModeMorningHorizon || || ||Höhe über Horizont wenn beim Attribut ASC_autoAstroModeMorning HORIZON ausgewählt
|-
|ASC_Closed_Pos || || ||in 10 Schritten von 0 bis 100, default Vorgabe ist abhängig vom Attribut AutoShuttersControl
|-
|ASC_Down ||astro, time || ||bei Astro wird Sonnenuntergang berechnet, bei time wird der Wert aus ASC_Time_Down_Early als Fahrzeit verwendet
|-
|ASC_Mode_Down ||always, absent, off || ||wann darf die Automatik steuern. immer, niemals, bei abwesenheit des Roomate (ist kein Roommate und absent eingestellt wird gar nicht gesteuert)
|-
|ASC_Mode_Up ||always, absent, off || ||wann darf die Automatik steuern. immer, niemals, bei abwesenheit des Roomate (ist kein Roommate und absent eingestellt wird gar nicht gesteuert)
|-
|ASC_Offset_Minutes_Evening || || ||maximale zufällige Verzögerung in Minuten (minimal 1) bei der Berechnung der Fahrzeiten für Abends
|-
|ASC_Offset_Minutes_Morning || || ||maximale zufällige Verzögerung in Minuten (minimal 1) bei der Berechnung der Fahrzeiten für Morgens
|-
|ASC_Open_Pos || || ||in 10 Schritten von 0 bis 100, default Vorgabe ist abhängig vom Attribut AutoShuttersControl
|-
|ASC_Partymode ||on, off || ||schaltet den Partymodus an oder aus, Wird dann am ASC Device set ASC-DEVICE partyMode on geschalten, werden alle Fahrbefehle an den Rollläden welche das Attribut auf on haben zwischen gespeichert und später erst ausgeführt
|-
|ASC_Pos_Cmd || || ||der set Befehl um den Rollladen in Prozent Angaben zu fahren, muss der selbe sein wie das Reading welches die Position des Rollladen in Prozent an gibt
|-
|ASC_Pos_after_ComfortOpen || || ||in 10 Schritten von 0 bis 100, default Vorgabe ist abhängig vom Attribut AutoShuttersControl
|-
|ASC_Roommate_Reading || || ||das Reading zum Roommate Device welches den Status wieder gibt
|-
|ASC_Roommate_Device || || ||Name des Roommate Devices welcher den Bewohner des Raumes vom Rollladen wieder gibt
|-
|ASC_Time_Down_Early || || ||Sunset frühste Zeit zum runter fahren
|-
|ASC_Time_Down_Late || || ||Sunset späteste Zeit zum runter fahren
|-
|ASC_Time_Up_Early || || ||Sunrise frühste Zeit zum hoch fahren
|-
|ASC_Time_Up_Late || || ||Sunrise späteste Zeit zum hoch fahren
|-
|ASC_Time_Up_WE_Holiday || || ||Sunrise frühste Zeit zum hochfahren am Wochenende und/oder Urlaub (we2holiday wird beachtet), Achtung sollte nicht größer sein wie ASC_Time_Up_Late sonst wird ASC_Time_Up_Late verwendet
|-
|ASC_Up ||astro, time || ||bei Astro wird Sonnenaufgang berechnet, bei time wird der Wert aus ASC_Time_Up_Early als Fahrzeit verwendet
|-
|ASC_Ventilate_Pos || || ||in 10 Schritten von 0 bis 100, default Vorgabe ist abhängig vom Attribut AutoShuttersControl
|-
|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 Fensterkontaktes an welchen Fenster der Rolladen angebracht ist
|-
|ASC_WindowRec_subType || || ||Typ des verwendeten Fensterkontakts: twostate (optisch oder magnetisch) oder threestate (Drehgriffkontakt)
|-
|ASC_lock-out ||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 Rolladen Hardwareseitig zu blockieren. Dann ist auch ein fahren über die Taster nicht mehr möglich.
|-
|ASC_lock-outCmd ||inhibit, blocked || ||set Befehl für das Rolladen-Device zum Hardware sperren. Zum gesetzt werden wenn man "ASC_lock-out" auf hard setzt
|-
| || || ||
|-
|}

== Hilfsmittel ==
tbd

readingsGroup, um die diversen Level einzustellen:

{{Hinweis|Die Readingsgroup muss noch angepasst werden.}}

define rg_ASC_Rollaeden_Level readingsGroup <Gerät>,<Closed_Pos>,<Open_Pos>,<Shading_Pos>,<Ventilate_Pos> (Rolladen_.*|Jalousie_.*)..:?AutoShuttersControl_Closed_Pos,?AutoShuttersControl_Open_Pos,?AutoShuttersControl_Shading_Pos,?AutoShuttesControl_Ventilate_Pos
attr rg_ASC_Rollaeden_Level commands { AutoShuttersControl_Closed_Pos => 'AutoShuttersControl_Closed_Pos:0,10,20,30,35,40,45,50,55,60,65,70,75,80,85,90,95,100',\
AutoShuttersControl_Open_Pos => 'AutoShuttersControl_Open_Pos:0,10,20,30,35,40,45,50,55,60,65,70,75,80,85,90,95,100',\
AutoShuttersControl_Shading_Pos => 'AutoShuttersControl_Shading_Pos:0,10,20,30,35,40,45,50,55,60,65,70,75,80,85,90,95,100',\
AutoShuttersControl_Ventilate_Pos => 'AutoShuttersControl_Ventilate_Pos:0,10,20,30,35,40,45,50,55,60,65,70,75,80,85,90,95,100'}
[[Datei:ReadingsGroup ASC Level.png|600px|]]
readingsGroup, um die diversen Zeiten einzustellen:

define rg_ASC_Rollaeden_Times readingsGroup <Gerät>,<Stand>,<Time_Up_Early>,<Time_Up_WE>,<Time_Up_Late>,<Time_Down_Early>,Time_Down_Late>,<Mode_Down>,<Mode_Up> (Rolladen_.*|Jalousie_.*)..:level,?AutoShuttersControl_Time_Up_Early,?AutoShuttersControl_Time_Up_WE_Holiday,?AutoShuttersControl_Time_Up_Late,?AutoShuttersControl_Time_Down_Early,?AutoShuttersControl_Time_Down_Late,?AutoShuttersControl_Mode_Down,?AutoShuttersControl_Mode_Up
attr rg_ASC_Rollaeden_Times commands {level => 'pct:0,10,20,30,35,40,45,50,55,60,65,70,75,80,85,90,95,100', \
AutoShuttersControl_Mode_Down => 'AutoShuttersControl_Mode_Down:always,absent,off',\
AutoShuttersControl_Mode_Up => 'AutoShuttersControl_Mode_Up:always,absent,off',\
AutoShuttersControl_Time_Down_Early => 'AutoShuttersControl_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', \
AutoShuttersControl_Time_Down_Late => 'AutoShuttersControl_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',\
AutoShuttersControl_Time_Up_Early => 'AutoShuttersControl_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', \
AutoShuttersControl_Time_Up_Late =>'AutoShuttersControl_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',AutoShuttersControl_Time_Up_WE_Holiday => 'AutoShuttersControl_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'}
[[Datei:ReadingsGroup ASC Times.png|600px|]]

== Weblinks ==
* {{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

[[Kategorie:Codeschnipsel]]
[[Kategorie:Rollladensteuerung]]

AutoShuttersControl

2018-10-15T14:47:27Z

Stephan1965: /* Readings in den Rolllädendevices */

{{Baustelle}}
{{Infobox Modul
|ModPurpose=Steuerung von Rollläden
|ModCategory=Automatisierung
|ModType=x

|ModForumArea=Automatisierung
|ModTechName=73_AutoShuttersControl.pm
|ModOwner=CoolTux}}
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.

{{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.}}

== Basics ==
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''.

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)

== Einrichtung ==

=== Vorbereitung ===

{{Hinweis|Ihr benötigt ein aktuelles FHEM. Update ab dem 04.09.2018 Voraussetzung!}}

Zunächst muß das Modul aus dem Link im Forum entpackt werden und die Datei 73_AutoShuttersControl.pm in das Unterverzeichnis für die Module kopiert werden und die Rechte angepaßt.

Speicherort für Linux-Standardinstallationen: /opt/fhem/FHEM
Rechte: <code>sudo chown 73_AutoShuttersControl.pm</code> und <code>sudo chmod 644 73_AutoShuttersControl.pm</code>

Danach sollte ein <code>reload AutoShuttersControl</code> in FHEM-Eingabefeld ausreichen, um das Modul verfügbar zu machen.

{{Hinweis|Eventuell muß FHEM auch einmalig neu gestartet werden, um das Modul nutzen zu können.}}

=== 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 ''AutoShuttersControl'' 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äßt, 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 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 ''AutoShuttersControl'' 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.

=== 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 ===
Danach sind jeweils 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 AutoShuttersControl Device selbst.===

{|class="wikitable"
|-
! Name !! Datentyp/ Wertebereich !! Bedeutung
|-
|..._nextAstroTimeEvent || ||Uhrzeit des nächsten Astro Events, Sonnenauf, Sonnenuntergang oder feste Zeit pro Rollonamen
|-
|..._lastPosValue || ||letzter abgesetzter Fahrbefehl pro Rollonamen
|-
|..._lastDelayPosValue || ||letzter 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 Schaltbefehle welcher durch ein Fensterevent oder Bewohnerstatus an die Rollläden gesendet wurde, wird beim off setzen durch set ASC-Device partyMode off ausgeführt
|-
|lockOut || on, off ||für das aktivieren des Aussperrschutzes gemäß dem entsprechenden Attribut 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ämen gefunden wurde, Bsp.: room_Schlafzimmer,Terrasse
|-
|state || ||Status des Devices active, enabled, disabled
|-
|sunriseTimeWeHoliday|| on,off ||wird das Rolladen Device Attribut Attributes 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_Sunrise ||Sonnenaufgangszeit für das Rollo
|-
|ASC_Time_Sunset ||Sonnenuntergangszeit für das Rollo
|}

== Settings ==

===Set Befehle für AutoShuttersControl Device===

{|class="wikitable"
|-
! Name !! Datentyp/ Wertebereich !! Beschreibung
|-
|partyMode ||on, off ||aktiviert den globalen Partymodus. Siehe Reading partyMode
|-
|lockOut ||on, off ||aktiviert den globalen Aussperrschutz. Siehe Reading partyMode
|-
|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/2
|-
|sunriseTimeWeHoliday || on,off ||aktiviert/deaktiviert die Beachtung des Rolladen Device Attributes AutoShuttersControl_Time_Up_WE_Holiday
|-
|createNewNotifyDev || ||Legt die interne Struktur für NOTIFYDEV neu an
|-
|selfDefence ||on, off||aktiviert/deaktiviert den Selbstschutz, wenn das Residents Device absent meldet und selfDefence aktiv ist und ein Fenster im Haus steht noch offen, wird an diesem Fenster das Rollo runter gefahren
|}

== Attribute ==

===Attribute im AutoShuttersControl Device selbst.===

{|class="wikitable"
|-
! Name !! Datentyp/ Wertebereich !! Default-Wert !! Beschreibung
|-
|ASC_antifreezeTemp || || ||Temperatur ab welcher der Frostschutz greifen soll und das Rollo nicht mehr fährt. Der letzte Fahrbefehl wird gespeichert.
|-
|ASC_autoAstroModeEvening ||aktuell REAL, CIVIL, NAUTIC, ASTRONOMIC || || (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 || ||(in genau dieser Schreibweise)
|-
|ASC_autoAstroModeMorningHorizon || || ||Höhe über Horizont wenn beim Attribut AutoShuttersControl_autoAstroModeMorning HORIZON ausgewählt
|-
|ASC_autoShuttersControlComfort ||on, off || ||schaltet die Komfortfunktion an. Bedeutet das ein Rollladen mit einem threestate Sensor am Fenster beim öffnen in eine weit offen Position fährt. Die Offenposition wird beim Rollladen über das Attribut AutoShuttersControl_Pos_after_ComfortOpen eingestellt.
|-
|ASC_autoShuttersControlEvening ||on, off || ||ob Abends die Rollläden automatisch nach Zeit gesteuert werden sollen
|-
|ASC_autoShuttersControlMorning ||on, off || ||ob Morgens die Rollläden automatisch nach Zeit gesteuert werden sollen
|-
|ASC_temperatureReading || || ||Reading für die Aussentemperatur
|-
|ASC_temperatureSensor || || ||Device für die Aussentemperatur
|-
|ASC_timeUpHolidayDevice || || ||Device zur Urlaubserkennung oder Sonstiges / muss 0 oder 1 im Reading state beinhalten.
|-
|ASC_residentsDevice|| || ||Devicenamen vom Residents Device der obersten Ebene
|-
|ASC_residentsDeviceReading|| || ||Status Reading vom Residents Device der obersten Ebene
|-
| || || ||
|}

===Attribute in den Rolllädendevices===

{|class="wikitable"
|-
! Name !! Datentyp/ Wertebereich !! Default-Wert !! Beschreibung
|-
|AutoShuttersControl || 0, 1, 2 || ||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 ||on, off || ||Frostschutz an oder aus
|-
|ASC_AutoAstroModeEvening ||aktuell REAL, CIVIL, NAUTIC, ASTRONOMIC || ||
|-
|ASC_AutoAstroModeEveningHorizon || || ||Höhe über Horizont wenn beim Attribut ASC_autoAstroModeEvening HORIZON ausgewählt
|-
|ASC_AutoAstroModeMorning ||aktuell REAL, CIVIL, NAUTIC, ASTRONOMIC || ||
|-
|ASC_AutoAstroModeMorningHorizon || || ||Höhe über Horizont wenn beim Attribut ASC_autoAstroModeMorning HORIZON ausgewählt
|-
|ASC_Closed_Pos || || ||in 10 Schritten von 0 bis 100, default Vorgabe ist abhängig vom Attribut AutoShuttersControl
|-
|ASC_Down ||astro, time || ||bei Astro wird Sonnenuntergang berechnet, bei time wird der Wert aus ASC_Time_Down_Early als Fahrzeit verwendet
|-
|ASC_Mode_Down ||always, absent, off || ||wann darf die Automatik steuern. immer, niemals, bei abwesenheit des Roomate (ist kein Roommate und absent eingestellt wird gar nicht gesteuert)
|-
|ASC_Mode_Up ||always, absent, off || ||wann darf die Automatik steuern. immer, niemals, bei abwesenheit des Roomate (ist kein Roommate und absent eingestellt wird gar nicht gesteuert)
|-
|ASC_Offset_Minutes_Evening || || ||maximale zufällige Verzögerung in Minuten (minimal 1) bei der Berechnung der Fahrzeiten für Abends
|-
|ASC_Offset_Minutes_Morning || || ||maximale zufällige Verzögerung in Minuten (minimal 1) bei der Berechnung der Fahrzeiten für Morgens
|-
|ASC_Open_Pos || || ||in 10 Schritten von 0 bis 100, default Vorgabe ist abhängig vom Attribut AutoShuttersControl
|-
|ASC_Partymode ||on, off || ||schaltet den Partymodus an oder aus, Wird dann am ASC Device set ASC-DEVICE partyMode on geschalten, werden alle Fahrbefehle an den Rollläden welche das Attribut auf on haben zwischen gespeichert und später erst ausgeführt
|-
|ASC_Pos_Cmd || || ||der set Befehl um den Rollladen in Prozent Angaben zu fahren, muss der selbe sein wie das Reading welches die Position des Rollladen in Prozent an gibt
|-
|ASC_Pos_after_ComfortOpen || || ||in 10 Schritten von 0 bis 100, default Vorgabe ist abhängig vom Attribut AutoShuttersControl
|-
|ASC_Roommate_Reading || || ||das Reading zum Roommate Device welches den Status wieder gibt
|-
|ASC_Roommate_Device || || ||Name des Roommate Devices welcher den Bewohner des Raumes vom Rollladen wieder gibt
|-
|ASC_Time_Down_Early || || ||Sunset frühste Zeit zum runter fahren
|-
|ASC_Time_Down_Late || || ||Sunset späteste Zeit zum runter fahren
|-
|ASC_Time_Up_Early || || ||Sunrise frühste Zeit zum hoch fahren
|-
|ASC_Time_Up_Late || || ||Sunrise späteste Zeit zum hoch fahren
|-
|ASC_Time_Up_WE_Holiday || || ||Sunrise frühste Zeit zum hochfahren am Wochenende und/oder Urlaub (we2holiday wird beachtet), Achtung sollte nicht größer sein wie ASC_Time_Up_Late sonst wird ASC_Time_Up_Late verwendet
|-
|ASC_Up ||astro, time || ||bei Astro wird Sonnenaufgang berechnet, bei time wird der Wert aus ASC_Time_Up_Early als Fahrzeit verwendet
|-
|ASC_Ventilate_Pos || || ||in 10 Schritten von 0 bis 100, default Vorgabe ist abhängig vom Attribut AutoShuttersControl
|-
|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 Fensterkontaktes an welchen Fenster der Rolladen angebracht ist
|-
|ASC_WindowRec_subType || || ||Typ des verwendeten Fensterkontakts: twostate (optisch oder magnetisch) oder threestate (Drehgriffkontakt)
|-
|ASC_lock-out ||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 Rolladen Hardwareseitig zu blockieren. Dann ist auch ein fahren über die Taster nicht mehr möglich.
|-
|ASC_lock-outCmd ||inhibit, blocked || ||set Befehl für das Rolladen-Device zum Hardware sperren. Zum gesetzt werden wenn man "ASC_lock-out" auf hard setzt
|-
| || || ||
|-
|}

== Hilfsmittel ==
tbd

readingsGroup, um die diversen Level einzustellen:

{{Hinweis|Die Riedingsgroup muss noch angepasst werden.}}

define rg_ASC_Rollaeden_Level readingsGroup <Gerät>,<Closed_Pos>,<Open_Pos>,<Shading_Pos>,<Ventilate_Pos> (Rolladen_.*|Jalousie_.*)..:?AutoShuttersControl_Closed_Pos,?AutoShuttersControl_Open_Pos,?AutoShuttersControl_Shading_Pos,?AutoShuttesControl_Ventilate_Pos
attr rg_ASC_Rollaeden_Level commands { AutoShuttersControl_Closed_Pos => 'AutoShuttersControl_Closed_Pos:0,10,20,30,35,40,45,50,55,60,65,70,75,80,85,90,95,100',\
AutoShuttersControl_Open_Pos => 'AutoShuttersControl_Open_Pos:0,10,20,30,35,40,45,50,55,60,65,70,75,80,85,90,95,100',\
AutoShuttersControl_Shading_Pos => 'AutoShuttersControl_Shading_Pos:0,10,20,30,35,40,45,50,55,60,65,70,75,80,85,90,95,100',\
AutoShuttersControl_Ventilate_Pos => 'AutoShuttersControl_Ventilate_Pos:0,10,20,30,35,40,45,50,55,60,65,70,75,80,85,90,95,100'}
[[Datei:ReadingsGroup ASC Level.png|600px|]]
readingsGroup, um die diversen Zeiten einzustellen:

define rg_ASC_Rollaeden_Times readingsGroup <Gerät>,<Stand>,<Time_Up_Early>,<Time_Up_WE>,<Time_Up_Late>,<Time_Down_Early>,Time_Down_Late>,<Mode_Down>,<Mode_Up> (Rolladen_.*|Jalousie_.*)..:level,?AutoShuttersControl_Time_Up_Early,?AutoShuttersControl_Time_Up_WE_Holiday,?AutoShuttersControl_Time_Up_Late,?AutoShuttersControl_Time_Down_Early,?AutoShuttersControl_Time_Down_Late,?AutoShuttersControl_Mode_Down,?AutoShuttersControl_Mode_Up
attr rg_ASC_Rollaeden_Times commands {level => 'pct:0,10,20,30,35,40,45,50,55,60,65,70,75,80,85,90,95,100', \
AutoShuttersControl_Mode_Down => 'AutoShuttersControl_Mode_Down:always,absent,off',\
AutoShuttersControl_Mode_Up => 'AutoShuttersControl_Mode_Up:always,absent,off',\
AutoShuttersControl_Time_Down_Early => 'AutoShuttersControl_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', \
AutoShuttersControl_Time_Down_Late => 'AutoShuttersControl_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',\
AutoShuttersControl_Time_Up_Early => 'AutoShuttersControl_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', \
AutoShuttersControl_Time_Up_Late =>'AutoShuttersControl_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',AutoShuttersControl_Time_Up_WE_Holiday => 'AutoShuttersControl_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'}
[[Datei:ReadingsGroup ASC Times.png|600px|]]

== Weblinks ==
* {{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

[[Kategorie:Codeschnipsel]]
[[Kategorie:Rollladensteuerung]]

UWZ

2018-04-13T08:49:54Z

Stephan1965: alternative Installation des Perl-Moduls mit apt-get

{{Infobox Modul
|ModPurpose=Daten von Unwetterzentrale.de holen
|ModType=d
|ModForumArea=Unterstützende Dienste/Wettermodule
|ModTechName=77_UWZ.pm
|ModOwner=Tdoe, CoolTux ({{Link2Forum|Topic=51233|LinkText=Forum}})
}}

Das Modul [[UWZ]] holt Informationen für eine zu spezifizierende Postleitzahl von der Seite [http://unwetterzentrale.de/ Unwetterzentrale.de] und bereitet sie für die Darstellung in FHEM auf.

== Voraussetzungen ==
{{Randnotiz|RNTyp=y|RNText=Diese Anleitung ist etwas in die Tage gekommen. Es hat viele Änderungen und Neuerungen gegeben. Die {{Link2CmdRef|Anker=UWZ}} ist aktuell und sollte eine gute Hilfestellung geben. Ansonsten bitte ins Forum schauen, ob hier bereits Lösungen zum Problem bestehen.

Die Wikiseite wird nach und nach aktualisiert. Wenn du dies liest und du dich mit dem Modul auskennst, bist du recht herzlich eingeladen, den Artikel zu aktualisieren. So bleibt uns (Entwicklern) mehr Zeit, um uns um das Modul zu kümmern und dies zu verbessern/erweitern.}}
Standardinstallation und eine Internetverbindung werden für das Funktionieren des Moduls benötigt.

== Installation ==
Das Modul wird als offizielles Modul per [[update]] verteilt und muss nicht extra installiert werden.

Falls nach dem "define" der Fehler "unable..." kommt und im Log "...Can't locate XML/Simple.pm in @INC (you may need to install the XML::Simple module)..." steht, so kommt man auf der Konsole mit der folgenden Installation weiter:

<code>cpan install XML::Simple</code>

Es geht auf der Konsole aber auch mit:

<code>apt-get install libxml-simple-perl</code>

== Anwendung ==
=== Define ===
Abhängig davon, ob man Unwetterwarnungen aus Deutschland oder einem anderen Land abfragen möchte, muss für das Attribut PLZ entweder die Postleitzahl (Deutschland) oder die AREA_ID (Rest der Welt) verwendet werden.

==== Deutschland ====
:<code><nowiki>define <name> UWZ <Ländercode> <PLZ> <INTERVAL> </nowiki></code>

==== Rest der Welt ====
:<code><nowiki>define <name> UWZ <Ländercode> <AREA_ID> <INTERVAL> </nowiki></code>

Die AREA_ID kann folgendermaßen ermittelt werden:

===== Geokoordinaten ermitteln =====
Dazu wird folgende URL aufgerufen, und am Ende der URL bei dem ''search'' Parameter der Name des Ortes eingegeben. Im Fall von Oberwaltersdorf AT:
:<code><nowiki>http://alertspro.geoservice.meteogroup.de/weatherpro/SearchFeed.php?search=oberwalt</nowiki></code>

Als Antwort bekommt man eine XML Struktur mit gefundenen Orten:
<pre>
<result>
<cities previousOffset="-1" nextOffset="-1">
<city country="49" city="8512" id="18226609" country-name="Germany" province-name="Bavaria" continent="6" inhabitants="7500" longitude="12.17092" latitude="48.57422" name="Oberwaltenkofen (Ergolding)" timezone="Europe/Berlin"/>
<city country="49" city="8671" id="18226768" country-name="Germany" province-name="Bavaria" continent="6" inhabitants="4000" longitude="12.51418" latitude="48.77301" name="Oberwalting (Leiblfing)" timezone="Europe/Berlin"/>
<city country="43" city="1161" id="18134912" country-name="Austria" province-name="Niederösterreich" continent="6" inhabitants="2500" longitude="16.3203" latitude="47.9756" name="Oberwaltersdorf" timezone="Europe/Vienna"/>
<city country="43" city="1305915" id="182199490" country-name="Austria" province-name="Niederösterreich" continent="6" inhabitants="150" longitude="15.0844" latitude="48.5394" name="Oberwaltenreith" timezone="Europe/Vienna"/>
</cities>
</result>
</pre>

Dort sucht man sich die beiden Attribute ''latitude'' und ''longitude'' für den passenden Ort heraus. Im verwendeten Beispiel wäre es für Oberwaltersdorf in Österreich:
:<code>latitude="47.9756" </code>
:<code>longitude="16.3203" </code>

===== AREA_ID abfragen =====
Mit diesen Werten wird nun die nächste URL zusammengebaut (Parameter ''lat'' + ''lon''):
:<code><nowiki> http://feed.alertspro.meteogroup.com/AlertsPro/AlertsProPollService.php?method=lookupCoord&lat=47.9756&lon=16.3203 </nowiki></code>

Das Resultat:
:<code><nowiki>[{"AREA_TYPE":"UWZ","AREA_ID":"UWZAT00234","CENTER_ID":"2"}] </nowiki></code>

Nun wissen wir, dass die AREA_ID für Oberwaltersdorf:
:<code>UWZAT00234 </code>
ist. Bei der Definition wird nun die Nummer ''00234'' anstelle der PLZ, und ''AT'' beim Ländercode verwendet:
:<code>define Unwetterzentrale UWZ AT 00234 3600 </code>

=== Attribute ===
Siehe Dokumentation.

== Anwendungsbeispiele ==
Zur Anzeige der Warnhinweise bietet das Modul vordefinierte Funktionen an, die in [[weblink|Weblinks]] benutzt werden können.


[[Datei:UWZAsHtmlFP.png|mini|right|400px|Warnmeldungen als reine Icons (Format ''UWZAsHtmlFP'') mit Teilen der Objektdetails]]
=== Anzeige der Warnhinweise nur als Icon ===
Die UWZ-Warnhinweise können über die Definition
:<code>define ''UnwetterFloorplan'' weblink htmlCode {UWZAsHtmlFP("''Unwetterzentrale''")}</code>
als reine Icons angezeigt werden. Diese Darstellung eignet sich besonders für die Einbindung in einen [[FLOORPLAN]].

Im gezeigten Beispiel ist ''Unwetterzentrale'' der Name des UWZ-Objekts und ''UnwetterDetailliert'' der Name des erzeugten weblink-Objekts.

 
[[Datei:UWZAsHtml.png|mini|right|400px|Warnmeldungen im Format ''UWZAsHtml'']]
=== Detaillierte Anzeige der Warnhinweise ===
Zur Anzeige der Warnhinweise in der ausführlichsten Form kann mit
:<code>define ''UnwetterDetailliert'' weblink htmlCode {UWZAsHtml("''Unwetterzentrale''")}</code>
ein weblink definiert werden.

Im gezeigten Beispiel ist ''Unwetterzentrale'' der Name des UWZ-Objekts und ''UnwetterDetailliert'' der Name des erzeugten weblink-Objekts.

=== Unwetterkarten ===
Auch diverse Unwetterkarten können eingebunden und gedownloadet werden.
Hierfür stehen eine Reihe von Karten zur Verfügung.
Mögliche Karten sind:
*europa

*deutschland
*deutschland-small
*bayern
*bremen
*baden-wuerttemberg
*brandenburg
*berlin
*hessen
*niedersachsen
*rheinland-pfalz
*saarland
*sachsen
*sachsen-anhalt
*thueringen
*nordrhein-westfalen
*mecklenburg-vorpommern
*schleswig-holstein
*hamburg

*oesterreich
*burgenland
*kaernten
*niederoesterreich
*oberoesterreich
*salzburg
*steiermark
*tirol
*vorarlberg
*wien

*schweiz
*aargau
*appenzell_ausserrhoden
*appenzell_innerrhoden
*basel_landschaft
*basel_stadt
*bern
*fribourg
*geneve
*glarus
*graubuenden
*jura
*luzern
*neuchatel
*nidwalden
*obwalden
*schaffhausen
*schwyz
*solothurn
*stgallen
*ticino
*thurgau
*uri
*waadt
*wallis
*zug
*zuerich

*liechtenstein

*belgique

*denmark

*finnland

*france

*letzebuerg

*nederland

*norwegen

*portugal

*sverige

*espana

*unitedkingdom
*eastofengland
*eastmidlands
*london
*northeastengland
*northernireland
*northwestengland
*scotland
*southeastengland
*southwestengland
*wales
*westmidlands
*yorkshireandthehumber

*isobaren1
*isobaren2
*isobaren3

==== Anzeige von Unwetterkarten ====
Dies erfolgt ebenfalls durch einem weblink.
:<code>define ''UnwetterKarteDeutschland'' weblink htmlCode {UWZAsHtmlKarteLand("''Unwetterzentrale''","''Deutschland''")}</code>

==== Download von Unwetterkarten ====
Um die Karten herunterzuladen um sie beispielsweise mit dem RSS Modul zu nutzen, muss dies am UWZ Device via Attribute konfiguriert werden.
Hierfür stehen folgende Attribute zur Verfügung:
*download [0|1]
*savepath (default:"/tmp/")
*maps (leerzeichen separierte Liste der zu speichernden Unwetterkarten)

:<code>attr ''Unwetterzentrale'' download 1</code>
:<code>attr ''Unwetterzentrale'' savepath /tmp/</code>
:<code>attr ''Unwetterzentrale'' maps deutschland europa bayern</code>

Die angegebenen Karten werden bei jedem Lauf erneut heruntergeladen und überschreiben das alte File.

==== Wetteranimation ====
Ab der Version 1.4.1 bietet das Modul auch die Möglichkeit diverse Wetteranimationen zu integrieren. Diese können ebenfalls mittels weblink genutzt werden.

Beispiel:
:<code>define ''UnwetterKarteMovie'' weblink htmlCode {UWZAsHtmlMovie("Unwetterzentrale","stroemung")}</code>

Der erste Parameter definiert das zugehörige UWZ Device.

Der zweite Parameter kann einer der folgenden sein:

*niederschlag-wolken
*stroemung
*temperatur

*niederschlag-wolken-de
*stroemung-de

*niederschlag-wolken-ch
*stroemung-ch

*niederschlag-wolken-at
*stroemung-at

*niederschlag-wolken-uk
*stroemung-uk

== Links ==
* [http://www.unwetterzentrale.de Unwetterzentrale] (für Deutschland)
* [http://unwetter.wetteralarm.at wetteralarm] (für Österreich)
* Geoservice [http://alertspro.geoservice.meteogroup.de/] zur Bestimmung von Geokoordinaten und Areacode
* Modulthread im Forum: {{Link2Forum|Topic=51233}}

Msg

2018-04-06T14:28:58Z

Stephan1965: kleine Korrektur

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Die Syntax ist sehr einfach gehalten:

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

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

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

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

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

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

===Konfiguration===

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Beide Devices sind als globales Attribut verlinkt:

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

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

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

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

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

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

Bei '''mehreren''' Pushover Empfängern muss man nicht mehr für jeden Empfänger ein einzelnes Pushover-Device anlegen. Es genügt auch ein Gerät, man kann die Empfänger dann einfach als Sub-Empfänger ansprechen:
:<code>msg push @PushoverDevice:uQiRzpo4DXghDmr9QzzfQu27cmVRsG Dies ist eine Nachricht</code>
Wie man sieht kann man einfach den User-Identifier (oder natürlich Group-Identifier) anhängen und adressiert somit einen alternativen Empfänger. Der im define des Device "PushoverDevice" angegebene User ist dann nur noch der Default-Empfänger.
Man kann auch an ein spezielles Endgerät adressieren:
:<code>msg push @PushoverDevice:uQiRzpo4DXghDmr9QzzfQu27cmVRsG:iPhone Dies ist eine Nachricht, die nur an das iPhone geschickt wird.</code>
Natürlich kann man das auch in ein msgContactPush Attribut schreiben...
:<code>attr myDevice msgContactPush PushoverDevice:uQiRzpo4DXghDmr9QzzfQu27cmVRsG</code>
...und anschließend so wie gewohnt über die Device-Adressierung verschicken:
:<code>msg push @myDevice Nachrichtentext</code>

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

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

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

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

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

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

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

Falls es '''mehrere''' Roommates gibt, die (separat) mit Telegram angeschrieben werden sollen, sollte man für Telegram folgende Syntax für die Eintragung bei jedem Roommate verwenden:
:<code>attr rr_KONTAKT msgContactPush <NAME-DES-TELEGRAMBOT>:@<ID-NR-DES-KONTAKT></code>

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

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

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

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

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

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

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

Sollen Nachrichten an eine Konferenz/an einem Raum gesendet werden, muss nur der Parameter ''Jabber_MTYPE=muc'' mit angegeben werden.
:<code>msg Jabber_MTYPE=muc test</code>
bzw. - sollte msgContactPush nicht definiert sein - ganz ausgeschrieben:
:<code>msg push Jabber_MTYPE=muc @JabberClient:raum@conference.jabber.xy Das ist eine Nachricht</code>

Ist ein standardmäßiger Versand an einen Raum gewünscht, kann dieser Parameter auch im Device ''globalMsg'' als Attribut ''msgParamsPush'' hinterlegt werden
:<code>attr globalMsg msgParamsPush Jabber_MTYPE=muc</code>
Danach reicht dann wieder das bekannte
:<code>msg test</code>

{{Hinweis| Weitere Beispiele folgen.}}

Msg

2018-04-06T14:21:18Z

Stephan1965: Syntax des Telegrameintrags für Roommates explicit dargestellt.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Die Syntax ist sehr einfach gehalten:

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

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

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

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

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

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

===Konfiguration===

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Beide Devices sind als globales Attribut verlinkt:

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

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

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

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

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

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

Bei '''mehreren''' Pushover Empfängern muss man nicht mehr für jeden Empfänger ein einzelnes Pushover-Device anlegen. Es genügt auch ein Gerät, man kann die Empfänger dann einfach als Sub-Empfänger ansprechen:
:<code>msg push @PushoverDevice:uQiRzpo4DXghDmr9QzzfQu27cmVRsG Dies ist eine Nachricht</code>
Wie man sieht kann man einfach den User-Identifier (oder natürlich Group-Identifier) anhängen und adressiert somit einen alternativen Empfänger. Der im define des Device "PushoverDevice" angegebene User ist dann nur noch der Default-Empfänger.
Man kann auch an ein spezielles Endgerät adressieren:
:<code>msg push @PushoverDevice:uQiRzpo4DXghDmr9QzzfQu27cmVRsG:iPhone Dies ist eine Nachricht, die nur an das iPhone geschickt wird.</code>
Natürlich kann man das auch in ein msgContactPush Attribut schreiben...
:<code>attr myDevice msgContactPush PushoverDevice:uQiRzpo4DXghDmr9QzzfQu27cmVRsG</code>
...und anschließend so wie gewohnt über die Device-Adressierung verschicken:
:<code>msg push @myDevice Nachrichtentext</code>

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

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

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

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

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

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

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

Falls es '''mehrere''' Roommates gibt, die (separat) mit Telegram angeschrieben werden sollen, sollte man folgende Syntax für die Eintragung bei jedem Roommate verwenden:
:<code>attr rr_KONTAKT msgContactPush <NAME-DES-TELEGRAMBOT>:@<ID-NR-DES-KONTAKT></code>

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

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

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

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

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

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

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

Sollen Nachrichten an eine Konferenz/an einem Raum gesendet werden, muss nur der Parameter ''Jabber_MTYPE=muc'' mit angegeben werden.
:<code>msg Jabber_MTYPE=muc test</code>
bzw. - sollte msgContactPush nicht definiert sein - ganz ausgeschrieben:
:<code>msg push Jabber_MTYPE=muc @JabberClient:raum@conference.jabber.xy Das ist eine Nachricht</code>

Ist ein standardmäßiger Versand an einen Raum gewünscht, kann dieser Parameter auch im Device ''globalMsg'' als Attribut ''msgParamsPush'' hinterlegt werden
:<code>attr globalMsg msgParamsPush Jabber_MTYPE=muc</code>
Danach reicht dann wieder das bekannte
:<code>msg test</code>

{{Hinweis| Weitere Beispiele folgen.}}

Msg

2018-04-06T12:05:10Z

Stephan1965: Eine Pushnachricht an andere Pushover-Empfänger (als der ursprünglich konfigurierte) schicken bei Verwendung nur eines Pushover-Devices. Aus dem Forum übernommen...

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Die Syntax ist sehr einfach gehalten:

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

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

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

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

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

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

===Konfiguration===

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Beide Devices sind als globales Attribut verlinkt:

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

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

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

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

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

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

Bei '''mehreren''' Pushover Empfängern muss man nicht mehr für jeden Empfänger ein einzelnes Pushover-Device anlegen. Es genügt auch ein Gerät, man kann die Empfänger dann einfach als Sub-Empfänger ansprechen:
:<code>msg push @PushoverDevice:uQiRzpo4DXghDmr9QzzfQu27cmVRsG Dies ist eine Nachricht</code>
Wie man sieht kann man einfach den User-Identifier (oder natürlich Group-Identifier) anhängen und adressiert somit einen alternativen Empfänger. Der im define des Device "PushoverDevice" angegebene User ist dann nur noch der Default-Empfänger.
Man kann auch an ein spezielles Endgerät adressieren:
:<code>msg push @PushoverDevice:uQiRzpo4DXghDmr9QzzfQu27cmVRsG:iPhone Dies ist eine Nachricht, die nur an das iPhone geschickt wird.</code>
Natürlich kann man das auch in ein msgContactPush Attribut schreiben...
:<code>attr myDevice msgContactPush PushoverDevice:uQiRzpo4DXghDmr9QzzfQu27cmVRsG</code>
...und anschließend so wie gewohnt über die Device-Adressierung verschicken:
:<code>msg push @myDevice Nachrichtentext</code>

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Sollen Nachrichten an eine Konferenz/an einem Raum gesendet werden, muss nur der Parameter ''Jabber_MTYPE=muc'' mit angegeben werden.
:<code>msg Jabber_MTYPE=muc test</code>
bzw. - sollte msgContactPush nicht definiert sein - ganz ausgeschrieben:
:<code>msg push Jabber_MTYPE=muc @JabberClient:raum@conference.jabber.xy Das ist eine Nachricht</code>

Ist ein standardmäßiger Versand an einen Raum gewünscht, kann dieser Parameter auch im Device ''globalMsg'' als Attribut ''msgParamsPush'' hinterlegt werden
:<code>attr globalMsg msgParamsPush Jabber_MTYPE=muc</code>
Danach reicht dann wieder das bekannte
:<code>msg test</code>

{{Hinweis| Weitere Beispiele folgen.}}

DOIF/Zeitspanne zwischen zwei Terminen schalten

2016-12-01T08:10:02Z

Stephan1965:

{{Randnotiz|RNTyp=g|RNText=Eine aktuelle DOIF-Version ist erforderlich}} 
[[Datei:Terminspanne_datetimepicker.png|mini|600px|right|]]
[[Datei:Terminspanne_generisch.png|mini|600px|right|]]
Die hier gezeigten DOIF schalten eine Zeitspanne zwischen zwei Terminen.

== Zeitspanne zwischen zwei Terminen mit DateTimePicker ==

=== Voraussetzung ===
Das erste DOIF nutzt das DateTimePicker-Widget. Dieses Widget muss vor der Nutzung des DOIF installiert werden. 
Die Installation ist hier beschrieben: [https://github.com/mhop/fhem-mirror/tree/master/fhem/contrib/Widgets/DateTimePicker DateTimePicker: Download und Installation]

===Beschreibung===
{{Randnotiz|RNText=Hinweis: Verwendung von
* '''DateTimePicker'''
* '''readingList''', '''setList''', '''webCmd''', '''cmdState'''
* '''$SELF''' für den Eigennamen des DOIF
* '''P_''' für persistente Readings
* '''Defaultwert'''
* '''userReadings''' zur Formatierung der Widgetdaten
* '''["^global$:^MODIFIED $SELF$"]''' damit nach einem Modify DOIF in Status 2 schaltet
}}
Das DOIF schaltet zwischen den angegebenen Terminen den Status auf 1, ausserhalb der Termispanne ist der Status 0. 
Die Bedingung des DOIF wird täglich zur angegebenen Uhrzeit geprüft und es wird die vom Widget erzeugte Datumszeichenkette mit der Zeichenkette des aktuellen Datums verglichen. Wenn die Zeichenketten identisch sind wird der entsprechende Zweig geschaltet und ein Logeintrag erzeugt. 
In den userReadings wird die Uhrzeit extrahiert und es wird das Datum extrahiert und in das passende Vergleichsformat gebracht. Das Widget liefert Tag und Monat mit zweistellig und ergänzt einstellige Angaben mit einer führenden Null. Der aktuelle Tag '''$mday''' und der Monat '''$month''' werden ohne führende Null geliefert, daher ist eine Formatanpassung notwendig
====Readings====
* '''<nowiki>[[$SELF:P_bhm,"00:00"]]</nowiki>''' enthält die Beginnzeit, mit Vorgabe
* '''<nowiki>[[$SELF:P_ehm,"00:00"]]</nowiki>''' enthält die Endzeit, mit Vorgabe
* '''[?$SELF:P_dbegin]''' enthält das Beginndatum
* '''[?$SELF:P_ebegin]''' enthält das Enddatum
* '''"$year-$month-$mday"''' enthält das aktuelle Datum
* '''P_begin''' enthält die vom Widget gelieferte Zeichenkette für Startdatum und Startuhrzeit
* '''P_ende''' enthält die vom Widget gelieferte Zeichenkette für Enddatum und Enduhrzeit

===Definition===
<pre>
([[$SELF:P_bhm,"00:00"]] and [?$SELF:P_dbegin] eq "$year-$month-$mday")\
({Log 1, "Alarmstart"})\
DOELSEIF ([[$SELF:P_ehm,"00:00"]] and [?$SELF:P_dende] eq "$year-$month-$mday" or ["^global$:^MODIFIED $SELF$"])\
({Log 1, "Alarmstop"})
</pre>

===wesentliche Attribute===
<pre>
cmdState 1|0
readingList P_begin P_ende
setList P_begin:datetime,theme:"default",step:5,inline:true P_ende:datetime,theme:"default",step:5,inline:true
userReadings P_bhm:P_begin.* {\
my ($d,$m,$y,$hm) = split(/\.| /,ReadingsVal($name,"P_begin","none"));;\
return $hm;;\
},\
P_dbegin:P_begin.* {\
my ($d,$m,$y,$hm) = split(/\.| /,ReadingsVal($name,"P_begin","none"));;\
return $y."-".int($m)."-".int($d);;\
},\
P_ehm:P_ende.* {\
my ($d,$m,$y,$hm) = split(/\.| /,ReadingsVal($name,"P_ende","none"));;\
return $hm;;\
},\
P_dende:P_ende.* {\
my ($d,$m,$y,$hm) = split(/\.| /,ReadingsVal($name,"P_ende","none"));;\
return $y."-".int($m)."-".int($d);;\
}\

webCmd P_begin:P_ende
</pre>

===Laborgruppe zum Import mit [[DOIF/Import von Code Snippets|Raw definition]]===
<pre>
define datumsbereich_Labor1 DOIF ([[$SELF:P_bhm,"00:00"]] and [?$SELF:P_dbegin] eq "$year-$month-$mday")\
({Log 1, "Alarmstart"})\
DOELSEIF ([[$SELF:P_ehm,"00:00"]] and [?$SELF:P_dende] eq "$year-$month-$mday" or ["^global$:^MODIFIED $SELF$"])\
({Log 1, "Alarmstop"})
attr datumsbereich_Labor1 alias Terminspanne über Jahre,Monate und Tage
attr datumsbereich_Labor1 cmdState 1|0
attr datumsbereich_Labor1 group Labor: Datumsbereich von HH:MM dd.mm.yyyy bis HH:MM dd.mm.yyyy
attr datumsbereich_Labor1 icon time_calendar
attr datumsbereich_Labor1 readingList P_begin P_ende
attr datumsbereich_Labor1 room DOIF_Labor
attr datumsbereich_Labor1 setList P_begin:datetime,theme:"default",step:5,inline:true P_ende:datetime,theme:"default",step:5,inline:true
attr datumsbereich_Labor1 userReadings P_bhm:P_begin.* {\
my ($d,$m,$y,$hm) = split(/\.| /,ReadingsVal($name,"P_begin","none"));;\
return $hm;;\
},\
P_dbegin:P_begin.* {\
my ($d,$m,$y,$hm) = split(/\.| /,ReadingsVal($name,"P_begin","none"));;\
return $y."-".int($m)."-".int($d);;\
},\
P_ehm:P_ende.* {\
my ($d,$m,$y,$hm) = split(/\.| /,ReadingsVal($name,"P_ende","none"));;\
return $hm;;\
},\
P_dende:P_ende.* {\
my ($d,$m,$y,$hm) = split(/\.| /,ReadingsVal($name,"P_ende","none"));;\
return $y."-".int($m)."-".int($d);;\
}\

attr datumsbereich_Labor1 webCmd P_begin:P_ende
attr datumsbereich_Labor1 widgetOverride setList:textField-long

save
</pre>

== Zeitspanne zwischen zwei Terminen ==
===Beschreibung===
{{Randnotiz|RNText=Hinweis: Verwendung von
* '''readingList''', '''setList''', '''webCmd''', '''cmdState'''
* '''$SELF''' und '''P_''' für persistente Readings
* '''userReadings''' zur Formatierung der Widgetdaten
* '''["^global$:^MODIFIED $SELF$"]''' damit nach einem Modify DOIF in Status 2 schaltet
}}
Das DOIF schaltet zwischen den angegebenen Terminen den Status auf 1, ausserhalb der Termispanne ist der Status 0.
Die Bedingung des DOIF wird täglich zur angegebenen Uhrzeit geprüft und es wird die vom Widget erzeugte Datumszeichenkette mit der Zeichenkette des aktuellen Datums verglichen. Wenn die Zeichenketten identisch sind wird der entsprechende Zweig geschaltet und ein Logeintrag erzeugt. 
In den userReadings werden Tag '''$mday''' und der Monat '''$month''' und Jahr '''$year''' in das passende Vergleichsformat gebracht. 
Es wird nicht geprüft, ob das angegebene Datum existiert. Es ist z.B. möglich, den 31.2.2017 einzustellen.

====Readings====
* '''<nowiki>[[$SELF:P_bhm,"00:00"]]</nowiki>''' enthält die Startzeit, mit Vorgabe
* '''<nowiki>[[$SELF:P_ehm,"00:00"]]</nowiki>''' enthält die Endzeit, mit Vorgabe
* '''[?$SELF:P_dbegin]''' enthält das Startdatum
* '''[?$SELF:P_ebegin]''' enthält das Enddatum
* '''"$year-$month-$mday"''' enthält das aktuelle Datum
* '''P_bday''' enthält den gewählten Starttag
* '''P_bmon''' enthält den gewählten Startmonat
* '''P_byear''' enthält das gewählte Startjahr
* '''P_eday''' enthält den gewählten Endtag
* '''P_emon''' enthält den gewählten Endmonat
* '''P_eyear''' enthält das gewählte Endjahr

===Definition===
<pre>
([[$SELF:P_bhm,"00:00"]] and [?$SELF:P_dbegin] eq "$year-$month-$mday")\
({Log 1, "Alarmstart"})\
DOELSEIF ([[$SELF:P_ehm,"00:00"]] and [?$SELF:P_dende] eq "$year-$month-$mday" or ["^global$:^MODIFIED $SELF$"])\
({Log 1, "Alarmstop"})</pre>
===wesentliche Attribute===
<pre>
cmdState 1|0
readingList P_bhm P_bday P_bmon P_byear P_ehm P_eday P_emon P_eyear
setList P_bhm:time P_bday:1,2,3,4,5,6,7,8,9,10,11,12,13,14,15,16,17,18,19,20,21,22,23,24,25,26,27,28,29,30,31 P_bmon:1,2,3,4,5,6,7,8,9,10,11,12 P_byear:2016,2017,2018,2019,2020,2021,2022,2023,2024,2025,2026 P_ehm:time P_eday:1,2,3,4,5,6,7,8,9,10,11,12,13,14,15,16,17,18,19,20,21,22,23,24,25,26,27,28,29,30,31 P_emon:1,2,3,4,5,6,7,8,9,10,11,12 P_eyear:2016,2017,2018,2019,2020,2021,2022,2023,2024,2025,2026
userReadings P_dbegin:P_b(year|mon|day).* {\
return ReadingsVal($name,"P_byear","none")."-".ReadingsVal($name,"P_bmon","none")."-".ReadingsVal($name,"P_bday","none");;\
}, \
P_dende:P_e(year|mon|day).* {\
return ReadingsVal($name,"P_eyear","none")."-".ReadingsVal($name,"P_emon","none")."-".ReadingsVal($name,"P_eday","none");;\
}
</pre>

===Laborgruppe zum Import mit [[DOIF/Import von Code Snippets|Raw definition]]===
<pre>
define datumsbereich_Labor0 DOIF ([[$SELF:P_bhm,"00:00"]|8] and [?$SELF:P_dbegin] eq "$year-$month-$mday")\
({Log 1, "Alarmstart"})\
DOELSEIF ([[$SELF:P_ehm,"00:00"]] and [?$SELF:P_dende] eq "$year-$month-$mday" or ["^global$:^MODIFIED $SELF$"])\
({Log 1, "Alarmstop"})
attr datumsbereich_Labor0 alias Terminspanne
attr datumsbereich_Labor0 cmdState 1|0
attr datumsbereich_Labor0 group Labor: Datumsbereich von HH:MM dd.mm.yyyy bis HH:MM dd.mm.yyyy ohne datetimepicker Widget
attr datumsbereich_Labor0 icon time_calendar
attr datumsbereich_Labor0 readingList P_bhm P_bday P_bmon P_byear P_ehm P_eday P_emon P_eyear
attr datumsbereich_Labor0 room DOIF_Labor
attr datumsbereich_Labor0 setList P_bhm:time P_bday:1,2,3,4,5,6,7,8,9,10,11,12,13,14,15,16,17,18,19,20,21,22,23,24,25,26,27,28,29,30,31 P_bmon:1,2,3,4,5,6,7,8,9,10,11,12 P_byear:2016,2017,2018,2019,2020,2021,2022,2023,2024,2025,2026 P_ehm:time P_eday:1,2,3,4,5,6,7,8,9,10,11,12,13,14,15,16,17,18,19,20,21,22,23,24,25,26,27,28,29,30,31 P_emon:1,2,3,4,5,6,7,8,9,10,11,12 P_eyear:2016,2017,2018,2019,2020,2021,2022,2023,2024,2025,2026
attr datumsbereich_Labor0 userReadings P_dbegin:P_b(year|mon|day).* {\
return ReadingsVal($name,"P_byear","none")."-".ReadingsVal($name,"P_bmon","none")."-".ReadingsVal($name,"P_bday","none");;\
}, \
P_dende:P_e(year|mon|day).* {\
return ReadingsVal($name,"P_eyear","none")."-".ReadingsVal($name,"P_emon","none")."-".ReadingsVal($name,"P_eday","none");;\
}
attr datumsbereich_Labor0 webCmd P_bhm:P_bday:P_bmon:P_byear:P_ehm:P_eday:P_emon:P_eyear
attr datumsbereich_Labor0 widgetOverride setList:textField-long

save
</pre>

==Links==
* [[DOIF]]
* [[DOIF/Labor - ausführbare, praxisnahe Beispiele als Problemlösung zum Experimetieren]]

[[Kategorie:Code Snippets]]

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

2016-11-01T13:25:28Z

Stephan1965: /* Channel (Kanal) 03 _WindowRec */ Bei dem Peer-Befehl fehlte das letzte SET. Und erst muss der Fenstersensor gedrückt werden und dann der FHEM Befehl abgesetzt werden.

{{Infobox Hardware
|Bild=HM-CC-RT-DN.jpg
|Bildbeschreibung=HM-CC-RT-DN an Heizkörper montiert
|HWProtocol=[[HomeMatic]]
|HWType=[[HomeMatic Type Thermostat|thermostat]]
|HWCategory=[[:Kategorie:Heizungsventile|Heizungsventile]]
|HWComm=868 MHz
|HWChannels=6
|HWVoltage=3 V
|HWPowerConsumption=180 mA
|HWPoweredBy=2x LR6/Mignon/AA
|HWSize=54x65x93 mm (BxHxT)
|HWDeviceFHEM=[[CUL_HM]]

|HWManufacturer=ELV / eQ-3
}}

'''HM-CC-RT-DN''' (häufig einfach '''RT''' genannt) ist ein Funk-''Heizkörperthermostate'' mit integriertem ''Stellantrieb''. Das Thermostat ist seit September 2013 verfügbar und ist der Nachfolger des [[HM-CC-VD Funk-Stellantrieb]]s.

== Vorbemerkungen ==
: ''→ Einstellungen und Informationen, die alle [[HomeMatic]] Thermostate betreffen, sind unter [[HomeMatic Type Thermostat#Temperaturlisten|HomeMatic Type Thermostat]] zu finden.''

Der HM-CC-RT-DN kann die Temperatur selbst messen (im Gegensatz zum [[HM-CC-VD Funk-Stellantrieb|Vorgänger]]) und verfügt über eine Fenster-Offen-Erkennung sowie eine Boost-Funktion. Der HM-CC-RT-DN ''kann'' von einem [[HM-TC-IT-WM-W-EU Funk-Wandthermostat AP]] gesteuert werden, das ist aber ''optional''.

Das Gerät wird seit Anfang Oktober 2013 von Fhem unterstützt (siehe Diskussion im {{Link2Forum|Topic=14738|LinkText=Forum}}).

Der HM-CC-RT-DN scheint das erste HomeMatic-Device zu sein, bei dem ein Update der Firmware auch vom Anwender durchgeführt werden kann. Ein Firmware-Update erfordert einen [[HM-CFG-USB_USB_Konfigurations-Adapter|USB Konfigurations-Adapter]] und eine auf der eQ-3 Webseite herunterladbare Firmwareupdate-Software. Weitere Details sind unter [[#Firmware Update|Firmware Update]] beschrieben.
{{Hinweis|Die Solltemperaturen eines HM-CC-RT-DN lassen sich ''nicht'' durch einen [[HM-CC-TC Funk-Wandthermostat]] ''steuern''. Dieser kann nur die Ist-Temperatur an den HM-CC-RT-DN weitergeben, damit nicht die am HM-CC-RT-DN direkt gemessene Raumtemperatur zur Regelung verwendet wird.}}
Mit einem HM-CC-RT-DN können maximal (neben der Zentrale/Fhem):
* 7 HomeMatic Heizkörperthermostate
* 8 HomeMatic Tür-Fensterkontakte / Fenster-Drehgriffkontakte
* 8 Tastenpaare von HomeMatic Fernbedienungen bzw. Display-Wandtaster
* 1 HomeMatic Innen-Temperatur-Sensor
[[Peering (HomeMatic)|gepeert]] werden.

{{Hinweis|Wird für Wartungs-/Umbaumaßnahmen das Wasser der Heizung abgelassen bzw. diese neubefüllt, sind alle Stellantriebe manuell dauerhaft auf '''on''' zu setzen: set <HM_Stellantrieb>_Clima controlManu on. Beim Einsatz eines Wandthermostaten ist der Wandthermostat entsprechend einzustellen.}}

== Technische Daten ==
* Betriebsspannung: 2 Stck. 1,5V LR6/Mignon/AA
* Stromaufnahme: 180 mA max.
* Abmessungen (B x H x T): 54 x 65 x 93 mm
* Gewicht: 180 g (ohne Batterien)
* Ventilanschluss: M30 x 1,5 mm

Aktuelle Firmware: 1.4

== Betrieb mit FHEM ==
Der Funk-Heizkörperthermostat muss zuerst mit Fhem [[Pairing (HomeMatic)|gepairt]] werden. Stellen Sie sicher, dass Fhem aktuell ist (update durchführen)

Das Pairing sollte wie in [[HomeMatic Devices pairen]] beschrieben durchgeführt werden

=== Channels (Kanäle) ===
==== Channel (Kanal) 01 _Weather ====

Dieser Kanal dient zur Einspeisung der (gemessenen) ''Ist-Temperatur''. Als Sensor können zum Beispiel das [[HM-TC-IT-WM-W-EU Funk-Wandthermostat AP|HM-TC-IT-WM-W-EU Funk-Wandthermostat]] oder ein [[HM-WDS40-TH-I Funk-Temperatur-/Feuchtesensor innen (IT)|HM-WDS40-TH-I Funk-Temperatur-/Feuchtesensor]] dienen.

Ein Temperatur-Sensor ''tempSensor'' kann mit dem ''_Weather''-Kanal wie folgt [[Peering (HomeMatic)|gepeert]] werden:

set <tempSensor> peerChan 0 <HM-CC-RT-DN>_Weather single

==== Channel (Kanal) 02 _Climate ====
Dieser Kanal erlaubt es dem [[HM-TC-IT-WM-W-EU Funk-Wandthermostat AP|HM-TC-IT-WM-W-EU Funk-Wandthermostat]] den HM-CC-RT-DN zu steuern. Dazu müssen die beiden Geräte gepeert werden:

set <HM-TC-IT-WM-W-EU>_Climate peerChan 0 <HM-CC-RT-DN>_Climate single set

==== Channel (Kanal) 03 _WindowRec ====
Mit diesem Kanal können Fensterkontakte ([[HM-SEC-SC Tür-Fensterkontakt|HM-SEC-SC]] und [[HM-Sec-RHS Funk-Fenster-Drehgriffkontakt|HM-SEC-RHS]]) ihren Fensterstatus (geöffnet / gekippt) an ein oder mehrere Thermostate senden. Die Thermostate stellen anschließend die entsprechende (konfigurierbare) Temperatur ein. Der Temperaturwert kann je Fenster-Sensor unterschiedlich definiert werden. Sind mehrere Fenster gleichzeitig geöffnet, so wird der Thermostat auf die Temperatur des Sensors mit dem geringsten Temperaturwert eingestellt.
Ferner wird empfohlen, bei Einsatz von externen Sensoren, die interne „Fenster auf Erkennung“ zu deaktivieren (weitere Details sind im [[HM-CC-RT-DN Funk-Heizkörperthermostat#Channel .28Kanal.29 04 _Clima|Channel (Kanal) 04 _Clima]] beschrieben).

Der Befehl zum Peeren lautet, wobei <fensterSensor> die Fhem-Kanalbezeichnung für den Fensterkontakt ist und <rt_WindowRec> die Kanalbezeichnung für den entsprechenden Kanal des Heizkörperthermostates:
set <fensterSensor> peerChan 0 <HM-CC-RT-DN>_WindowRec single set

Zum Löschen (=unpeeren) dieser Kopplung:
set <fensterSensor> peerChan 0 <HM-CC-RT-DN>_WindowRec single unset

'''Achtung''': Der Peer-(Lösch)Vorgang muss erst am Fensterkontakt durch Drücken der Anlerntaste ausgelöst werden, und zwar auch dann, wenn der Fensterkontakt schon vorher mit Fhem gepairt wurde. Dann kann der oben genannte Befehl in FHEM abgesetzt werden. Wichtig scheint auch, dass der Fensterkontakt geschlossen ist wenn man die Anlerntaste drückt.

Der Befehl zur Temperatureinstellung des Heizkörperthermostaten für den Zustand "Fenster offen" lautet, wobei <fensterSensor> die Fhem-Kanalbezeichnung für den Fensterkontakt ist und <rt_WindowRec> die Kanalbezeichnung für den entsprechenden Kanal des Heizkörperthermostates, sowie <Temp> die einzustellende Temperatur (ganzzahliger Wert):
set <HM-CC-RT-DN>_WindowRec regSet winOpnTemp <Temp> <fensterSensor>

==== Channel (Kanal) 04 _Clima ====
Dieser Kanal dient zum Einstellen der Betriebsparameter, auch [[#Temperaturlisten|Temperaturlisten]] sind hierauf zu übertragen.

{{Hinweis|In älteren Versionen von Fhem wurde dieser Kanal durch ''autocreate'' als <code>_ClimRT_tr</code> angelegt. Der Hersteller hat hier offenbar die internen Bezeichnungen geändert, denn beim Vorläufernmodell HM-CC-TC mussten Temperaturlisten auf den Kanal ''Climate'' übertragen werden.}}

Die maximale Öffnung des Ventils kann mittels folgendem Befehl eingestellt werden (hier auf 80 %):
set <HM-CC-RT-DN>_Clima regSet valveMaxPos 80

Die interne "Fenster-auf"-Erkennung kann man wie folgt abschalten:
set <HM-CC-RT-DN>_Clima regSet winOpnMode off

==== Channel (Kanal) 05 _ClimaTeam ====
Dieser Kanal erlaubt es mehrere HM-CC-RT-DN zu einem "Team" zu gruppieren. Ein Mitglied des Teams meldet
* Änderungen der Temperatur am Handrad
* Einschalten des Boost-Modus am Taster
an seine "Teamkollegen" weiter. Folgende Änderungen werden '''nicht''' weitergegeben:
* Status der Fensterkontakte
* Temperaturlisten/Wochenplan und daraus folgende Änderungen
* Änderungen durch Fernbedienungen
* Änderungen durch eine HomeMatic-Zentrale

Befehl zum Peeren, wobei ''<HM-CC-RT-DN#1>_ClimaTeam'' und ''<HM-CC-RT-DN#2>_ClimaTeam'' die Kanalbezeichnungen der beiden ClimaTeam-Kanäle sind:
set <HM-CC-RT-DN#1>_ClimaTeam peerChan 0 <HM-CC-RT-DN#2>_ClimaTeam single

==== Channel (Kanal) 06 _remote ====
Dieser Kanal kann an eine Fernbedienung gekoppelt werden. Per Tastendruck kann man einen bestimmten Mode und/oder eine bestimmte Temperatur wählen. Dabei kann die Reaktion auf einen langen oder kurzen Tastendruck gesondert eingestellt werden.

Der Befehl zum peeren lautet, wobei <button> die Kanalbezeichnung der Fernbedienung und <rt-remote> die Kanalbezeichnung des Heizkörperthermostates ist:
set <button> peerChan 0 <HM-CC-RT-DN>_remote single

=== Betriebsmodus Auto, Manu, Party (Urlaub) ===

Der HM-CC-RT-DN verfügt über drei Betriebsmodus: Auto, Manu (Manuell) und Party (Urlaub).

==== Modus Auto ====
Das Gerät arbeitet gemäß des gespeicherten Wochenprogramms. Manuelle Änderungen sind möglich, werden aber beim nächsten Schaltpunkt überschrieben.

==== Modus Manu ====
Die Temperatur wird manuell eingestellt, das Wochenprogramm wird nicht abgearbeitet.

==== Modus Party (Urlaub) ====
Die eingestellte Temperatur gilt bis zu einem gegebenen Endzeitpunkt, anschließend wechselt das Thermostat in den ''Auto''-Modus. So kann beispielsweise bei Abwesenheit ein niedrigeres Temperaturprofil eingestellt werden ohne dass die Temperaturlisten verändert werden müssen.

set <HM-CC-RT-DN>_Clima controlParty 16 06.12.13 16:30 09.12.13 05:00

Dadurch wird
* von 06.12.2013, 16:30 Uhr
* bis 09.12.2013, 05:00 Uhr
* die gewünschte Raumtemperatur auf 16 °C eingestellt.

{{Hinweis|
* Der Befehl muss auf dem Kanal 4 ''(_Clima)'' erfolgen.
* Es werden nur Uhrzeiten zu jeder vollen oder halben Stunde angenommen (Minuten also 00 oder 30).}}

Mit der folgenden Funktion <code>Urlaub()</code> kann man eine ganze Wohnung (also mehrere RTs) mit nur einem Befehl in den Party-Modus versetzen. Im Beispiel werden zwei Heizkörper ("Treppenhaus" und "Kammer") angesteuert.

Zu beachten sind folgende Dinge:
# Aktuelle Dateien (z.B. <code>10_CUL_HM</code>) verwenden!
# Bei dem ''controlParty''-Befehl ''kein'' Komma zwischen den Parametern.
# Bei der Funktion die Parameterübergabe definieren <code>($$$$$)</code>

'''Aufruf:'''
:<code>{Urlaub ("16", "06.12.13", "16:30", "09.12.13" ,"05:00")}</code>

'''Funktion:'''
<source lang=perl>
my $Urlaub;
sub
Urlaub($$$$$)
{
my ($temp, $startDate, $startTime, $endDate, $endTime) = @_;

# HM-CC-RT-DN akzeptiert nur Zeiten, die auf Minute 00 oder 30 enden.
# Daher $startTime und $endTime abrunden
$startTime =~ s/\:[0-2].$/:00/;
$startTime =~ s/\:[3-5].$/:30/;
$endTime =~ s/\:[0-2].$/:00/;
$endTime =~ s/\:[3-5].$/:30/;

# controlParty bei jedem HM-CC-RT-DN setzen.
for my $rt (qw(Kammer Treppenhaus)) {
fhem ("set $rt controlParty $temp $startDate $startTime $endDate $endTime");
}
}
</source>

=== Tastensperre ===

Um zu verhindern, dass der Modus oder die Temperatur per Tasten bzw. Drehrad am HM-CC-RT-DN verändert wird, kann eine Tastensperre gesetzt werden. Dies erfolgt mittels des Befehls:

set <HM-CC-RT-DN> regSet btnLock on

Rückgängig machen geht per:

set <HM-CC-RT-DN> regSet btnLock off

Diese Tastensperre kann man aber am HM-CC-RT-DN durch eine Tastenkombination wieder zurücksetzen. Um sie nur per Fhem rücksetzen zu können, muss

set <HM-CC-RT-DN> regSet globalBtnLock on

eingegeben werden. Rückgängig geht wieder per:

set <HM-CC-RT-DN> regSet globalBtnLock off

Es gibt auch eine Tastensperre die nur das Umschalten des Modus (Auto, Manuell, Urlaub) am Gerät verhindert. Diese wird mit

set <HM-CC-RT-DN> regSet modusBtnLock on

eingeschaltet. Abschalten geht mit:

set <HM-CC-RT-DN> regSet modusBtnLock off

=== Burst-Modus ===
Das ist ein '''Übertragungs'''modus für Nachrichten zwischen HM-Geräten und der Zentrale. Der RT erwacht alle 2,5 Minuten und dann überträgt die Zentrale die Kommandos. Wenn man einen Fensterkontakt oder eine Fernsteuerung nutzt, muss der RT sofort reagieren - dann muss man den Burst ''enablen''. Der RT kann in diesem Fall sofort aufgeweckt werden und bearbeitet die Anforderung (Request). Das kann man auch von der Zentrale aus nutzen (so man möchte). Das ist der '''Vorteil''' des eingeschalteten Burst-Modus.

'''Nachteil:''' Der Burst-Modus benötigt mehr Leistung, das heißt die Batterien müssen häufiger gewechselt werden: Der RT muss den Receiver ständig empfangsbereit halten. Außerdem wachen bei jedem Burst wachen ''alle'' Burst-Empfänger auf – egal an wen die Kommunikation gerichtet war.

'''Burst – wie es funktioniert'''

Schickt ein Sender eine burst Sequenz, wachen alle burst-Empfänger auf und prüfen die Message.
Wenn sie betroffen sind bleiben sie eine Zeit lang wach, ansonsten schlafen sie wieder ein.
Man beachte also, dass Senden eines Burst Energie in ALLEN burst-Empfängern verbraucht, egal ob sie angesprochen sind.

'''HMLAN und burst'''

[[HMLAN]] hat ein Sendebudget das über eine Stunde berechnet wird. Burst belastet diese Konto deutlich - so können nicht mehr als 100 bursts /h gesendet werden - dann geht HMLAN in overload Wenn zusätzliche Nachrichten gesendet werden sind es entsprechend weniger.
Es ist als nicht vorteilhaft, unnötig bursts zu senden.

'''Burst devices'''

Es gibt Devices, die immer auf burst reagieren und solche bei denen es abgeschaltet werden kann. So reagiert ein Rauchmelder immer auf Burst damit er seine Team-Kollegen hören kann.
Ein TC oder RT hingegen hat diese Funktion abschaltbar. 'Per default ist dies ausgeschaltet um Batterie zu sparen'. Wenn ein VD gesteuert wird ist der TC ja selbst wach. Wird er aber mit einem Fensterkontakt gekoppelt muss es eingeschaltet werden – sonst verpasst er die Nachricht.

'''ConditionalBurst devices'''

Devices mit abschaltbarem Burst wie z.B. der ''HM-CC-RT-DN'' haben ein Register, ''burstRx'', mit dem das burst-Erwachen eingestellt werden kann.
Sendern, die einen burst-Aktor erwecken sollen, muss man sagen, welcher Peer Burst benötigt. Hier kann ggf. das Register ''peerNeedsBurst'' nach dem Peeren gesetzt werden. FHEM versucht dies automatisch beim Peeren zu erledigen. Siehe [[HomeMatic HMInfo|HMinfo]] Befehl ''models'' um herauszufinden, welche Devices welchen Modus unterstützen.

'''Attribut burstAccess'''

Devices, die abschaltbaren burst haben kann man ein attribut bustAccess 1_auto setzen. Es wird beim Abschicken eines Kommandos versucht, das Device mit burst zu wecken. Sollte es nicht funktionieren wird gewartet, bis das Device aufwacht (meist reagieren solche Devices auch auf wakeup). Das Setzen des Attributs ist angenehm – es werden aber ggf. viele bursts gesendet.

'''Kommando burstXmit'''

Mit diesem Kommando, das bei Devices mit contitional-Burst zu Verfügung steht, wird der burst gezielt von User angestossen.

Der User schickt erst seine Kommandos an das device. Die Kommandos werden im Command-stack gesammelt.

Dann sendet der User ein set burstXmit.

Es passiert das gleiche wie bei burstAccess.

FHEM versucht mittels burst zu wecken und sendet bei Erfolg die Messages aus dem Kommandostack.

Im Gegensatz zu burstAccess ist burstXmit gezielt einsetzbar und kann sparsamer verwendet werden.

''' FHEM und burst devices'''

FHEM sendet eine burst automatisch mit Kommandos zu Devices, die nur burst unterstützen.

'''So aktiviert man den burst-Betrieb am HM-CC-RT-DN'''

''Burst Mode einschalten'' (der Kanal 4 des Device WZ1 heisst hier WZ1_4)
:<code>set WZ1_4 regSet burstRx on </code>
prüfen mit:
:<code>get WZ1_4 reg burstRx </code>
''Nun in FHEM den Burst mode einschalten (sofern nicht burstXmit verwendet wird)''
:<code>attr WZ1 burstAccess 1_auto</code>

Hinweis: Das Attribut im Device und nicht im Kanal setzen, ansonsten gibt es eine Fehlermeldung.

=== Temperaturlisten ===
Die Temperaturlisten des HM-CC-RT-DN werden identisch mit denen anderer HomeMatic Thermostate verwaltet (siehe [[HomeMatic Type Thermostat#Temperaturlisten|HomeMatic Type Thermostat]]). Beim HM-CC-RT-DN ist der Kanal 4 (_Clima) für die Temperaturlisten zuständig.

==Fhem-Log==
In den folgenden Logs heißt Kanal 4 noch "_ClimRT_tr". Inzwischen würde man dort "_Clima" sehen.

=== Device-Log ===
2013.10.10 20:03:24 3: CUL_HM Unknown device CUL_HM_HM_CC_RT_DN_2212BC, please define it
2013.10.10 20:03:24 2: autocreate: define CUL_HM_HM_CC_RT_DN_2212BC CUL_HM 2212BC A1A0184002212BC0000001000954B4551303531303031375900FFFF
2013.10.10 20:03:24 3: Device CUL_HM_HM_CC_RT_DN_2212BC added to ActionDetector with 000:10 time
2013.10.10 20:03:24 3: CUL_HM pair: CUL_HM_HM_CC_RT_DN_2212BC thermostat, model HM-CC-RT-DN serialNr KEQ0510017
2013.10.10 20:03:24 3: LANCUL pairing (hmPairForSec) not enabled
2013.10.10 20:03:24 2: autocreate: define FileLog_CUL_HM_HM_CC_RT_DN_2212BC FileLog /usr/local/FHEM/var/log/CUL_HM_HM_CC_RT_DN_2212BC-%Y.log CUL_HM_HM_CC_RT_DN_2212BC
2013.10.10 20:03:24 3: Device Heizung_Wohnzimmer added to ActionDetector with 000:10 time
2013.10.10 20:03:24 3: CUL_HM pair: Heizung_Wohnzimmer thermostat, model HM-CC-TC serialNr JEQ0044286
2013.10.10 20:03:24 3: Device CUL_HM_HM_CC_RT_DN_2212BC added to ActionDetector with 000:10 time
2013.10.10 20:03:24 3: CUL_HM pair: CUL_HM_HM_CC_RT_DN_2212BC thermostat, model HM-CC-RT-DN serialNr KEQ0510017
2013.10.10 20:03:25 2: autocreate: define CUL_HM_HM_CC_RT_DN_2212BC_Weather CUL_HM 2212BC01
2013.10.10 20:03:25 2: autocreate: define FileLog_CUL_HM_HM_CC_RT_DN_2212BC_Weather FileLog /usr/local/FHEM/var/log/CUL_HM_HM_CC_RT_DN_2212BC_Weather-%Y.log CUL_HM_HM_CC_RT_DN_2212BC_Weather
2013.10.10 20:03:25 2: autocreate: define FileLog_CUL_HM_HM_CC_RT_DN_2212BC_Weather FileLog /usr/local/FHEM/var/log/CUL_HM_HM_CC_RT_DN_2212BC_Weather-%Y.log CUL_HM_HM_CC_RT_DN_2212BC_Weather
2013.10.10 20:03:26 2: autocreate: define CUL_HM_HM_CC_RT_DN_2212BC_Climate CUL_HM 2212BC02
2013.10.10 20:03:26 2: autocreate: define FileLog_CUL_HM_HM_CC_RT_DN_2212BC_Climate FileLog /usr/local/FHEM/var/log/CUL_HM_HM_CC_RT_DN_2212BC_Climate-%Y.log CUL_HM_HM_CC_RT_DN_2212BC_Climate
2013.10.10 20:03:26 2: autocreate: define FileLog_CUL_HM_HM_CC_RT_DN_2212BC_Climate FileLog /usr/local/FHEM/var/log/CUL_HM_HM_CC_RT_DN_2212BC_Climate-%Y.log CUL_HM_HM_CC_RT_DN_2212BC_Climate
2013.10.10 20:03:27 2: autocreate: define CUL_HM_HM_CC_RT_DN_2212BC_WindowRec CUL_HM 2212BC03
2013.10.10 20:03:27 2: autocreate: define FileLog_CUL_HM_HM_CC_RT_DN_2212BC_WindowRec FileLog /usr/local/FHEM/var/log/CUL_HM_HM_CC_RT_DN_2212BC_WindowRec-%Y.log CUL_HM_HM_CC_RT_DN_2212BC_WindowRec
2013.10.10 20:03:27 2: autocreate: define FileLog_CUL_HM_HM_CC_RT_DN_2212BC_WindowRec FileLog /usr/local/FHEM/var/log/CUL_HM_HM_CC_RT_DN_2212BC_WindowRec-%Y.log CUL_HM_HM_CC_RT_DN_2212BC_WindowRec
2013.10.10 20:03:28 2: autocreate: define CUL_HM_HM_CC_RT_DN_2212BC_ClimRT_tr CUL_HM 2212BC04
2013.10.10 20:03:28 2: autocreate: define FileLog_CUL_HM_HM_CC_RT_DN_2212BC_ClimRT_tr FileLog /usr/local/FHEM/var/log/CUL_HM_HM_CC_RT_DN_2212BC_ClimRT_tr-%Y.log CUL_HM_HM_CC_RT_DN_2212BC_ClimRT_tr
2013.10.10 20:03:28 2: autocreate: define FileLog_CUL_HM_HM_CC_RT_DN_2212BC_ClimRT_tr FileLog /usr/local/FHEM/var/log/CUL_HM_HM_CC_RT_DN_2212BC_ClimRT_tr-%Y.log CUL_HM_HM_CC_RT_DN_2212BC_ClimRT_tr
2013.10.10 20:03:29 2: autocreate: define CUL_HM_HM_CC_RT_DN_2212BC_ClimaTeam CUL_HM 2212BC05
2013.10.10 20:03:29 2: autocreate: define FileLog_CUL_HM_HM_CC_RT_DN_2212BC_ClimaTeam FileLog /usr/local/FHEM/var/log/CUL_HM_HM_CC_RT_DN_2212BC_ClimaTeam-%Y.log CUL_HM_HM_CC_RT_DN_2212BC_ClimaTeam
2013.10.10 20:03:29 2: autocreate: define FileLog_CUL_HM_HM_CC_RT_DN_2212BC_ClimaTeam FileLog /usr/local/FHEM/var/log/CUL_HM_HM_CC_RT_DN_2212BC_ClimaTeam-%Y.log CUL_HM_HM_CC_RT_DN_2212BC_ClimaTeam
2013.10.10 20:03:30 2: autocreate: define CUL_HM_HM_CC_RT_DN_2212BC_remote CUL_HM 2212BC06
2013.10.10 20:03:30 2: autocreate: define FileLog_CUL_HM_HM_CC_RT_DN_2212BC_remote FileLog /usr/local/FHEM/var/log/CUL_HM_HM_CC_RT_DN_2212BC_remote-%Y.log CUL_HM_HM_CC_RT_DN_2212BC_remote
2013.10.10 20:03:30 2: autocreate: define FileLog_CUL_HM_HM_CC_RT_DN_2212BC_remote FileLog /usr/local/FHEM/var/log/CUL_HM_HM_CC_RT_DN_2212BC_remote-%Y.log CUL_HM_HM_CC_RT_DN_2212BC_remote
2013.10.10 20:03:35 3: Device CUL_HM_HM_CC_RT_DN_2212BC added to ActionDetector with 000:10 time
2013.10.10 20:03:40 2: CUL_HM set CUL_HM_HM_CC_RT_DN_2212BC getSerial
2013.10.10 20:03:40 2: CUL_HM set CUL_HM_HM_CC_RT_DN_2212BC getConfig
2013.10.10 20:03:54 3: Device CUL_HM_HM_CC_RT_DN_2212BC added to ActionDetector with 000:10 time

=== Event monitor ===
2013-10-12 12:05:35.610 CUL_HM CUL_HM_HM_CC_RT_DN_2212BC_ClimRT_tr motorErr: ok
2013-10-12 12:05:35.610 CUL_HM CUL_HM_HM_CC_RT_DN_2212BC_ClimRT_tr measured-temp: 18.4
2013-10-12 12:05:35.610 CUL_HM CUL_HM_HM_CC_RT_DN_2212BC_ClimRT_tr desired-temp: 18
2013-10-12 12:05:35.610 CUL_HM CUL_HM_HM_CC_RT_DN_2212BC_ClimRT_tr ValvePosition: 3 %
2013-10-12 12:05:35.610 CUL_HM CUL_HM_HM_CC_RT_DN_2212BC_ClimRT_tr mode: manu
2013-10-12 12:05:35.610 CUL_HM CUL_HM_HM_CC_RT_DN_2212BC_ClimRT_tr unknown0: 24
2013-10-12 12:05:35.610 CUL_HM CUL_HM_HM_CC_RT_DN_2212BC_ClimRT_tr T: 18.4 desired: 18 valve: 3 %
2013-10-12 12:05:35.646 CUL_HM CUL_HM_HM_CC_RT_DN_2212BC battery: ok
2013-10-12 12:05:35.646 CUL_HM CUL_HM_HM_CC_RT_DN_2212BC batteryLevel: 3.1 V
2013-10-12 12:05:35.646 CUL_HM CUL_HM_HM_CC_RT_DN_2212BC measured-temp: 18.4
2013-10-12 12:05:35.646 CUL_HM CUL_HM_HM_CC_RT_DN_2212BC desired-temp: 18
2013-10-12 12:05:35.646 CUL_HM CUL_HM_HM_CC_RT_DN_2212BC actuator: 3 %

== Firmware Update ==
Seit 24.10.2014 gibt es für den HM-CC-RT-DN die neue Firmware Version 1.4. Diese kann von der eQ-3 Webseite heruntergeladen werden. Genauere Informationen gibt es unter [[HomeMatic Firmware Update]].

=== HM-CC-RT-DN spezifische Update Informationen ===
Durch gleichzeitiges Drücken der "Auto-/Manu"-Taste und der "Comfort-/Eco"-Taste am HM-CC-RT-DN während man die Batterien wieder einlegt wird der updatemodus gestartet. Während des Updates steht "FUP" im Display. Nach erfolgreichem Update erscheint "Ins" im Display und es muss eine erneute Adaptierfahrt durch drücken der Boost-Taste ausgelöst werden. Anschließend sollte der HM-CC-RT-DN wieder normal funktionieren. Die eingestellten Parameter und das Pairing mit FHEM gehen beim Update nicht verloren. Sollte das Update fehlschlagen, erscheint "Err" bzw. "CrC" im Display.

Normalerweise sollte dann durch erneutes starten der Prozedur am PC und HM-CC-RT-DN das ganze erneut durchführbar sein.

Es gibt einige Readings, die nicht durch ein einfaches ''getConfig'' aktualisisert werden, z.B. "battery"(nicht batteryLevel). Um diese Readings zu bekommen, ist ein
:<code>set Device_Channel04 controlMode auto </code>
notwendig. Daraufhin werden die Readings übertragen/aktualisiert.

== Simulation von Fensterkontakten und externen Temperatursensoren ==
grober Ablauf:
* erstellen ein virtuelles Device
* erstelle dazu einen virtuellen Kanal
* peeren den Kanal mit dem RT (als fenster-kontakt oder als remote, wen du willst)
* sende ein postEvent

=== Fensterkontakte ===
''Entnommen aus diesem {{Link2Forum|Topic=31078|Message=236245|LinkText=Forenbeitrag}}''
define virSC CUL_HM 221133
attr virSC autoReadReg 4_reqStatus
attr virSC expert 2_full
attr virSC model virtual_1
attr virSC peerIDs
attr virSC subType virtual
attr virSC webCmd press short:press long

define virtualKitchenDoor CUL_HM 22113301
attr virtualKitchenDoor dummy 1
attr virtualKitchenDoor expert 1
attr virtualKitchenDoor group Virtual
attr virtualKitchenDoor model virtual_1
attr virtualKitchenDoor webCmd postEvent open:postEvent closed

Anschließend peeren und Temperatur festlegen mit:
set virtualKitchenDoor peerChan 0 <Thermostat_Window_Rec> single set
set <Thermostat_Window_Rec> regSet winOpnTemp 5 virtualKitchenDoor

Die virtuelle Tür wird dann entsprechend über ein Notify getriggert:
define notify_virtualKitchenDoor notify (Fensterkontakt_1|Fensterkontakt_2) {if(Value("Fensterkontakt") eq "open" && Value("Fensterkontakt_2") eq "open"){fhem("set virtualKitchenDoor postEvent open")}else{fhem("set virtualKitchenDoor postEvent closed")}}

=== Temperatursensoren ===
''Entnommen aus diesem {{Link2Forum|Topic=19686|Message=233788|LinkText=Forenbeitrag}}''

1. Virtuelles HomeMatic Device mit _deiner_ HM Id definieren:
define wz_vT CUL_HM <hmId>

2. Dem Device einen virtuellen Kanal (Default ist ein virtueller Button) hinzufügen:
set wz_vT virtual 1

3. Es ist kein virtueller Button sondern ein virtueller Temperatursensor - darum rename:
rename wz_vT_Btn1 wz_vT_Sensor1

4. Virtuellen Peer Sensor mit dem Weather Channel des RT-DN peeren:
set wz_vT_Sensor1 peerChan 0 <RT_DN>_Weather single

5. Peering kontrollieren (Voraussetzung: Device ''hm'' vom Typ [[HomeMatic HMInfo|HMinfo]] existiert):
:<code>set hm peerXref</code>
Beispiel-Ausgabe:
peerXref done:
x-ref list
wz_Thermostat_Weather => wz_vT_Sensor1
wz_vT_Sensor1 => wz_Thermostat_Weather

6. Gemessene Temperatur vom z.B. 1-Wire DS1820 dem virtuellen HM Sensor übergeben. Z.B. alle zwei Minuten per at:
define at_wz_vT at +*00:02 { my $T=(ReadingsVal("<DS1820B>","temperature",20.0)); fhem "set wz_vT_Sensor1 virtTemp $T" }

Fertig.

== Bekannte Probleme ==
=== TempList: Bad format ... ===
Wenn Sie beim Setzen einer Temperaturliste nach dem o.a. Schema ("SetTempList...") die Meldung

Bad format, use HH:MM TEMP ......

erhalten, sollten Sie zunächst ein [[update]] von Fhem durchführen.

== Links ==
* [http://www.eq-3.de/produkt-detail-aktoren/items/homematic-funk-heizkoerperthermostat.html Produktinfo]
* [http://www.eq-3.de/Downloads/eq3/pdf_produkte/HM-CC-RT-DN_UM_GE_eQ-3_web.pdf Bedienungsanleitung (PDF)]
* [http://www.eq-3.de/Downloads/eq3/pdf_produkte/Funk-Heizkoerperthermostat_105155_Produktdatenblatt_V2.2.pdf Datenblatt (PDF)]
* [http://www.eq-3.de/Downloads/eq3/downloads/Ventilkompatibilitaeten.pdf Ventil-Kompatibilitätsliste (PDF)]
* {{Link2Forum|Topic=14738|LinkText=Forenthema zum Thermostat}}

[[Kategorie:HomeMatic Components]]
[[Kategorie:Heizungsventile]]

HM-TC-IT-WM-W-EU Funk-Wandthermostat AP

2016-11-01T12:22:40Z

Stephan1965: /* Channel (Kanal) 06 _remote */

{{Infobox Hardware
|Bild=HM-TC-IT-WM-W-EU.jpg
|Bildbeschreibung=HM-TC-IT-WM-W-EU mit Standard-Einstellungen
|HWProtocol=[[HomeMatic]]
|HWType=[[HomeMatic Type Thermostat|thermostat]]
|HWCategory=[[:Kategorie:Temperatursensoren|Temperatursensoren]] [[:Kategorie:Feuchtesensoren|Feuchtesensoren]]
|HWComm=868,3 MHz
|HWChannels=7
|HWVoltage=3 V
|HWPowerConsumption=40 mA (max)
|HWPoweredBy=2 x LR6/Mignon/AA
|HWSize=ohne Rahmen: 55 x 55 x 20 mm mit Rahmen: 86 x 86 x 21,5 mm
|HWDeviceFHEM=[[CUL_HM]]

|HWManufacturer=ELV / eQ-3
}}
'''HM-TC-IT-WM-W-EU Funk-Wandthermostat AP'''

HomeMatic-Wandthermostat Aufputz. Verfügbar seit Februar 2014. Nachfolger des [[HM-CC-TC_Funk-Wandthermostat|HM-CC-TC]].

== Vorbemerkungen ==
: ''→ Allgemeine Informationen, die alle HomeMatic Thermostate betreffen, sind unter [[HomeMatic Type Thermostat]] zu finden.''

Der '''HM-TC-IT-WM-W-EU Funk-Wandthermostat''' misst die Raumtemperatur und Luftfeuchtigkeit. Er verfügt über individuell einstellbare Wochenprogramme und Programmierung direkt am Gerät. Zusätzlich ist auch eine Boost-Funktion vorhanden (ermöglicht ein schnelles, kurzzeitiges Aufheizen des Heizkörpers). Er verfügt über ein eigenes Anzeigedisplay für Soll- und Isttemperatur sowie Luftfeuchtigkeit. Er kann mittels Klebestreifen irgendwo aufgeklebt werden, soll aber auch in Mehrfachrahmen von Berker, ELSO, Gira, Merten und JUNG passen.

== Technische Daten ==

'''Technische Daten:'''
* Versorgungsspannung: 2 Stck. 1,5 V LR03/Micro/AAA
* Stromaufnahme (max.): 40 mA
* Schutzart: IP20
* Schutzklasse: III
* Abmessungen (BxHxT ohne Rahmen): 55 x 55 x 20 mm
* Abmessungen (BxHxT mit Rahmen): 86 x 86 x 21,5 mm
* Gewicht (ohne Batterien): 74 g
* Temperaturwahl in Schritten von: 0,5 °C

Im Gegensatz zum HM-CC-TC kann der HM-TC-IT-WM-W-EU auch andere HomeMatic-Schaltaktoren (z.B. [[HM-LC-SW1-FM_Schaltaktor_1-fach_UP|HM-LC-SW1-FM]]) über den Channel 07 SwitchTr direkt anlernen, womit z.B. die Steuerung elektrischer Heizungen möglich wird. Der HM-CC-TC konnte direkt nur die HM-CC-VD steuern.

== Betrieb mit FHEM ==

Zuerst muss das Wandthermostat natürlich mit FHEM gepairt werden.

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

Danach kann das [[Peering (HomeMatic)|Peering]] mit den Heizkörperthermostaten des betreffenden Raumes stattfinden:

=== Channels (Kanäle) ===

==== Channel (Kanal) 01 _Weather ====
Damit das Heizkörperthermostat HM-CC-RT-DN die Temperatur des Wandthermostats übernimmt, muss der Weather Kanal gepeert werden:

set <HM-TC-IT-WM-W-EU-Gerät>_Weather peerChan 0 <HM-CC-RT-DN-Gerät>_Weather single set

==== Channel (Kanal) 02 _Climate ====
Damit der Heizkörperthermostat vom Wandthermostat auch eingestellt werden kann (Soll-Temperatur, Mode etc.), muss der Climate Kanal gepeert werden:

set <HM-TC-IT-WM-W-EU-Gerät>_Climate peerChan 0 <HM-CC-RT-DN-Gerät>_Climate single set
Dies muss für jedes zu steuernde Heizkörperthermostat wiederholt werden.

==== Channel (Kanal) 03 _WindowRec ====
Mit diesem Kanal lassen sich Fensterkontakte (HM-SEC-SC oder HM-SEC-RHS) peeren, die ihren Fensterstatus (geöffnet/gekippt) an ein oder mehrere Thermostate senden. Die Thermostate stellen anschließend die entsprechende (konfigurierbare) Temperatur ein. Der Temperaturwert kann je Fenster-Sensor unterschiedlich definiert werden. Sind mehrere Fenster gleichzeitig geöffnet, so wird der Thermostat auf die Temperatur des Sensors mit dem geringsten Temperaturwert eingestellt.

Das Peering mit einem Tür-Fensterkontakt läuft wie folgt ab:

set <HM-Sec-SC> peerChan 0 <HM-TC-IT-WM-W-EU-Gerät>_WindowRec single set

Der Befehl zur Temperatureinstellung des Heizkörperthermostaten für den Zustand "Fenster offen" lautet, wobei <fensterSensor> die Fhem-Kanalbezeichnung für den Fensterkontakt ist und <tc_WindowRec> die Kanalbezeichnung für den entsprechenden Kanal des Heizkörperthermostates, sowie <Temp> die einzustellende Temperatur (ganzzahliger Wert):
set <tc_WindowRec> regSet winOpnTemp <Temp> <fensterSensor>

==== Channel (Kanal) 06 _remote ====
Dieser Kanal kann an eine Fernbedienung gekoppelt werden. Per Tastendruck kann man einen bestimmten Mode und/oder eine bestimmte Temperatur wählen. Dabei kann die Reaktion auf einen langen oder kurzen Tastendruck gesondert eingestellt werden.

Der Befehl zum peeren lautet, wobei <button> die Kanalbezeichnung der Fernbedienung und <tc-remote> die Kanalbezeichnung des Heizkörperthermostates ist:
<pre>set <button> peerChan 0 <rt-remote> single</pre>

==== Channel (Kanal) 07 _SwitchTr ====
Das Peering mit einem Schaltaktor läuft z.B. wie folgt ab:

set <HM-TC-IT-WM-W-EU_SwitchTr> peerChan 0 <HM-LC-SW1-FM> single set
set <HM-LC-SW1-FM> regSet shCtOn ltLo <HM-TC-IT-WM-W-EU_SwitchTr>

== Einstellungen ==

Die folgenden Einstellungen werden in **Registern** des HM-TC-IT-WM-W-EU vorgenommen. Das heißt, dass diese Einstellungen im Gerät selbst gespeichert werden, nicht in der Konfigurations-Datei von Fhem.

=== Anzeige ===

Register im Kanal 2 ''(_Climate)'' erlauben es zu konfigurieren, welche Daten der HM-TC-IT-WM-W-EU in seinem LC-Display anzeigt.

==== showInfo time|date ====

Wählt aus, ob die ''Uhrzeit'' (<code>time</code>, Standard-Einstellung) oder das ''Datum'' (<code>date</code>) angezeigt wird. Der folgende Befehl erlaubt es das Datum anzeigen zu lassen:

set <HM-TC-IT-WM-W-EU>_Climate regSet showInfo date

==== showSetTemp actTemp|setTemp ====

Wählt aus, ob die ''Ist-Temperatur'' (<code>actTemp</code>, Standard-Einstellung) oder die ''Soll-Temperatur'' (<code>setTemp</code>) im Display angezeigt wird.

set <HM-TC-IT-WM-W-EU>_Climate regSet showSetTemp setTemp

==== showHumidity temp|tempHum ====

Wählt aus, ob dauerhaft die ''Temperatur'' (<code>temp</code>, Standard-Einstellung) oder ''Temperatur und Luftfeuchtigkeit'' im Wechsel (<code>tempHum</code>) im Display angezeigt werden.

set <HM-TC-IT-WM-W-EU>_Climate regSet showHumidity tempHum

=== Tastensperre ===

Um zu verhindern, dass der Modus oder die Temperatur per Tasten bzw. Drehrad am HM-TC-IT-WM-W-EU verändert wird, kann eine Tastensperre gesetzt werden. Dies erfolgt mittels des Befehls:

set <HM-TC-IT-WM-W-EU> regSet btnLock on

Rückgängig machen geht per:

set <HM-TC-IT-WM-W-EU> regSet btnLock off

Diese Tastensperre kann man aber am Thermostat durch eine Tastenkombination wieder zurücksetzen. Um sie nur per Fhem rücksetzen zu können, muss

set <HM-TC-IT-WM-W-EU> regSet globalBtnLock on

abgesetzt werden. Rückgängig wieder per:

set <HM-TC-IT-WM-W-EU> regSet globalBtnLock off

=== Temperaturlisten ===

Die Temperaturlisten des HM-TC-IT-WM-W-EU werden identisch zu anderern HomeMatic Thermostaten verwaltet, siehe [[HomeMatic Type Thermostat#Temperaturlisten|HomeMatic Type Thermostat]]. Beim HM-TC-IT-WM-W-EU ist der Kanal 2 ''(_Climate)'' für die Temperaturlisten zuständig.

== Fhem-Log ==
=== Event monitor ===

Hier habe ich einmal die Wunschtemperatur erhöht, damit auch was passiert:

2014-04-09 09:35:11 CUL_HM KH_Bad_Therm CMDs_pending
2014-04-09 09:35:11 CUL_HM KH_Bad_Therm_Climate set_desired-temp 18.0
2014-04-09 09:35:11 CUL_HM KH_Bad_Therm CMDs_done

Bei mir ist es so, das der SwitchTr Kanal nur mit dem gepeerten Device spricht, hier ein HM-LC-SW1-FM:

2014-04-09 09:35:17 CUL_HM KH_Bad_Heizung trig_KH_Bad_Therm_SwitchTr: 200
2014-04-09 09:35:17 CUL_HM KH_Bad_Heizung trigLast: KH_Bad_Therm_SwitchTr :200

Der hat auch prompt reagiert und die Heizung eingeschaltet:

2014-04-09 09:35:17 CUL_HM KH_Bad_Heizung level: 100
2014-04-09 09:35:17 CUL_HM KH_Bad_Heizung pct: 100
2014-04-09 09:35:17 CUL_HM KH_Bad_Heizung deviceMsg: on (to KH_Bad_Therm)
2014-04-09 09:35:17 CUL_HM KH_Bad_Heizung on
2014-04-09 09:35:17 CUL_HM KH_Bad_Heizung timedOn: off

und noch ein wenig Geplauder der vorhandenen Kanäle:

2014-04-09 09:36:39 CUL_HM KH_Bad_Therm_Climate measured-temp: 16.0
2014-04-09 09:36:39 CUL_HM KH_Bad_Therm_Climate desired-temp: 18.0
2014-04-09 09:36:39 CUL_HM KH_Bad_Therm_Climate humidity: 50
2014-04-09 09:36:39 CUL_HM KH_Bad_Therm_Climate T: 16.0 desired: 18.0
2014-04-09 09:36:49 CUL_HM KH_Bad_Therm battery: ok
2014-04-09 09:36:49 CUL_HM KH_Bad_Therm batteryLevel: 3
2014-04-09 09:36:49 CUL_HM KH_Bad_Therm measured-temp: 16.0
2014-04-09 09:36:49 CUL_HM KH_Bad_Therm desired-temp: 18.0
2014-04-09 09:36:49 CUL_HM KH_Bad_Therm_Climate measured-temp: 16.0
2014-04-09 09:36:49 CUL_HM KH_Bad_Therm_Climate desired-temp: 18.0
2014-04-09 09:36:49 CUL_HM KH_Bad_Therm_Climate mode: auto
2014-04-09 09:36:49 CUL_HM KH_Bad_Therm_Climate T: 16.0 desired: 18.0
2014-04-09 09:36:59 CUL_HM KH_Bad_Therm_Weather temperature: 16.0
2014-04-09 09:36:59 CUL_HM KH_Bad_Therm_Weather humidity: 50
2014-04-09 09:36:59 CUL_HM KH_Bad_Therm_Weather T: 16.0 H: 50

== Firmware Update ==
Updates für den HM-TC-IT-WM-W-EU können von der eQ-3 Webseite heruntergeladen werden. Genauere Informationen gibt es unter [[HomeMatic_Firmware_Update]]. Das Thermostat wird in den Updatemodus gebracht, indem beide äußeren Tasten gedrückt werden, während die Batterien eingesetzt werden. Das Display zeigt "FUP" an.

== Bekannte Probleme ==
Bei der Firmware 1.2 und dem Kanal Climate funktioniert die Einstellung der Hysterese über das Register hyst2point nicht. Der Eintrag wird ignoriert.

Siehe auch Bericht im [http://www.elv.de/topic/hystereseeinstellung-bei-hm-tc-it-wm-w-eu-firmware-1-2-wird-ignoriert.html Forum von ELV]

== Links ==
* [http://www.eq-3.de/Downloads/eq3/pdf_produkte/HM-TC-IT-WM-W-EU_UM_GE_eQ-3_web.pdf Manual]
* [http://www.eq-3.de/Downloads/eq3/pdf_produkte/Funk-Wandthermostat_132030A0_Produktdatenblatt_V1.2.pdf Produktdatenblatt]

[[Kategorie:HomeMatic Components]]
[[Kategorie:Feuchtesensoren]]
[[Kategorie:Temperatursensoren]]

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

2016-11-01T12:18:06Z

Stephan1965: /* Modus Auto */

{{Infobox Hardware
|Bild=HM-CC-RT-DN.jpg
|Bildbeschreibung=HM-CC-RT-DN an Heizkörper montiert
|HWProtocol=[[HomeMatic]]
|HWType=[[HomeMatic Type Thermostat|thermostat]]
|HWCategory=[[:Kategorie:Heizungsventile|Heizungsventile]]
|HWComm=868 MHz
|HWChannels=6
|HWVoltage=3 V
|HWPowerConsumption=180 mA
|HWPoweredBy=2x LR6/Mignon/AA
|HWSize=54x65x93 mm (BxHxT)
|HWDeviceFHEM=[[CUL_HM]]

|HWManufacturer=ELV / eQ-3
}}

'''HM-CC-RT-DN''' (häufig einfach '''RT''' genannt) ist ein Funk-''Heizkörperthermostate'' mit integriertem ''Stellantrieb''. Das Thermostat ist seit September 2013 verfügbar und ist der Nachfolger des [[HM-CC-VD Funk-Stellantrieb]]s.

== Vorbemerkungen ==
: ''→ Einstellungen und Informationen, die alle [[HomeMatic]] Thermostate betreffen, sind unter [[HomeMatic Type Thermostat#Temperaturlisten|HomeMatic Type Thermostat]] zu finden.''

Der HM-CC-RT-DN kann die Temperatur selbst messen (im Gegensatz zum [[HM-CC-VD Funk-Stellantrieb|Vorgänger]]) und verfügt über eine Fenster-Offen-Erkennung sowie eine Boost-Funktion. Der HM-CC-RT-DN ''kann'' von einem [[HM-TC-IT-WM-W-EU Funk-Wandthermostat AP]] gesteuert werden, das ist aber ''optional''.

Das Gerät wird seit Anfang Oktober 2013 von Fhem unterstützt (siehe Diskussion im {{Link2Forum|Topic=14738|LinkText=Forum}}).

Der HM-CC-RT-DN scheint das erste HomeMatic-Device zu sein, bei dem ein Update der Firmware auch vom Anwender durchgeführt werden kann. Ein Firmware-Update erfordert einen [[HM-CFG-USB_USB_Konfigurations-Adapter|USB Konfigurations-Adapter]] und eine auf der eQ-3 Webseite herunterladbare Firmwareupdate-Software. Weitere Details sind unter [[#Firmware Update|Firmware Update]] beschrieben.
{{Hinweis|Die Solltemperaturen eines HM-CC-RT-DN lassen sich ''nicht'' durch einen [[HM-CC-TC Funk-Wandthermostat]] ''steuern''. Dieser kann nur die Ist-Temperatur an den HM-CC-RT-DN weitergeben, damit nicht die am HM-CC-RT-DN direkt gemessene Raumtemperatur zur Regelung verwendet wird.}}
Mit einem HM-CC-RT-DN können maximal (neben der Zentrale/Fhem):
* 7 HomeMatic Heizkörperthermostate
* 8 HomeMatic Tür-Fensterkontakte / Fenster-Drehgriffkontakte
* 8 Tastenpaare von HomeMatic Fernbedienungen bzw. Display-Wandtaster
* 1 HomeMatic Innen-Temperatur-Sensor
[[Peering (HomeMatic)|gepeert]] werden.

{{Hinweis|Wird für Wartungs-/Umbaumaßnahmen das Wasser der Heizung abgelassen bzw. diese neubefüllt, sind alle Stellantriebe manuell dauerhaft auf '''on''' zu setzen: set <HM_Stellantrieb>_Clima controlManu on. Beim Einsatz eines Wandthermostaten ist der Wandthermostat entsprechend einzustellen.}}

== Technische Daten ==
* Betriebsspannung: 2 Stck. 1,5V LR6/Mignon/AA
* Stromaufnahme: 180 mA max.
* Abmessungen (B x H x T): 54 x 65 x 93 mm
* Gewicht: 180 g (ohne Batterien)
* Ventilanschluss: M30 x 1,5 mm

Aktuelle Firmware: 1.4

== Betrieb mit FHEM ==
Der Funk-Heizkörperthermostat muss zuerst mit Fhem [[Pairing (HomeMatic)|gepairt]] werden. Stellen Sie sicher, dass Fhem aktuell ist (update durchführen)

Das Pairing sollte wie in [[HomeMatic Devices pairen]] beschrieben durchgeführt werden

=== Channels (Kanäle) ===
==== Channel (Kanal) 01 _Weather ====

Dieser Kanal dient zur Einspeisung der (gemessenen) ''Ist-Temperatur''. Als Sensor können zum Beispiel das [[HM-TC-IT-WM-W-EU Funk-Wandthermostat AP|HM-TC-IT-WM-W-EU Funk-Wandthermostat]] oder ein [[HM-WDS40-TH-I Funk-Temperatur-/Feuchtesensor innen (IT)|HM-WDS40-TH-I Funk-Temperatur-/Feuchtesensor]] dienen.

Ein Temperatur-Sensor ''tempSensor'' kann mit dem ''_Weather''-Kanal wie folgt [[Peering (HomeMatic)|gepeert]] werden:

set <tempSensor> peerChan 0 <HM-CC-RT-DN>_Weather single

==== Channel (Kanal) 02 _Climate ====
Dieser Kanal erlaubt es dem [[HM-TC-IT-WM-W-EU Funk-Wandthermostat AP|HM-TC-IT-WM-W-EU Funk-Wandthermostat]] den HM-CC-RT-DN zu steuern. Dazu müssen die beiden Geräte gepeert werden:

set <HM-TC-IT-WM-W-EU>_Climate peerChan 0 <HM-CC-RT-DN>_Climate single set

==== Channel (Kanal) 03 _WindowRec ====
Mit diesem Kanal können Fensterkontakte ([[HM-SEC-SC Tür-Fensterkontakt|HM-SEC-SC]] und [[HM-Sec-RHS Funk-Fenster-Drehgriffkontakt|HM-SEC-RHS]]) ihren Fensterstatus (geöffnet / gekippt) an ein oder mehrere Thermostate senden. Die Thermostate stellen anschließend die entsprechende (konfigurierbare) Temperatur ein. Der Temperaturwert kann je Fenster-Sensor unterschiedlich definiert werden. Sind mehrere Fenster gleichzeitig geöffnet, so wird der Thermostat auf die Temperatur des Sensors mit dem geringsten Temperaturwert eingestellt.
Ferner wird empfohlen, bei Einsatz von externen Sensoren, die interne „Fenster auf Erkennung“ zu deaktivieren (weitere Details sind im [[HM-CC-RT-DN Funk-Heizkörperthermostat#Channel .28Kanal.29 04 _Clima|Channel (Kanal) 04 _Clima]] beschrieben).

Der Befehl zum Peeren lautet, wobei <fensterSensor> die Fhem-Kanalbezeichnung für den Fensterkontakt ist und <rt_WindowRec> die Kanalbezeichnung für den entsprechenden Kanal des Heizkörperthermostates:
set <fensterSensor> peerChan 0 <HM-CC-RT-DN>_WindowRec single

Zum Löschen (=unpeeren) dieser Kopplung:
set <fensterSensor> peerChan 0 <HM-CC-RT-DN>_WindowRec single unset

'''Achtung''': Der Peer-(Lösch)Vorgang muss am Fensterkontakt durch Drücken der Anlerntaste bestätigt werden, und zwar auch dann, wenn der Fensterkontakt schon vorher mit Fhem gepairt wurde. Wichtig scheint auch, dass der Fensterkontakt geschlossen ist wenn man die Anlerntaste drückt.

Der Befehl zur Temperatureinstellung des Heizkörperthermostaten für den Zustand "Fenster offen" lautet, wobei <fensterSensor> die Fhem-Kanalbezeichnung für den Fensterkontakt ist und <rt_WindowRec> die Kanalbezeichnung für den entsprechenden Kanal des Heizkörperthermostates, sowie <Temp> die einzustellende Temperatur (ganzzahliger Wert):
set <HM-CC-RT-DN>_WindowRec regSet winOpnTemp <Temp> <fensterSensor>

==== Channel (Kanal) 04 _Clima ====
Dieser Kanal dient zum Einstellen der Betriebsparameter, auch [[#Temperaturlisten|Temperaturlisten]] sind hierauf zu übertragen.

{{Hinweis|In älteren Versionen von Fhem wurde dieser Kanal durch ''autocreate'' als <code>_ClimRT_tr</code> angelegt. Der Hersteller hat hier offenbar die internen Bezeichnungen geändert, denn beim Vorläufernmodell HM-CC-TC mussten Temperaturlisten auf den Kanal ''Climate'' übertragen werden.}}

Die maximale Öffnung des Ventils kann mittels folgendem Befehl eingestellt werden (hier auf 80 %):
set <HM-CC-RT-DN>_Clima regSet valveMaxPos 80

Die interne "Fenster-auf"-Erkennung kann man wie folgt abschalten:
set <HM-CC-RT-DN>_Clima regSet winOpnMode off

==== Channel (Kanal) 05 _ClimaTeam ====
Dieser Kanal erlaubt es mehrere HM-CC-RT-DN zu einem "Team" zu gruppieren. Ein Mitglied des Teams meldet
* Änderungen der Temperatur am Handrad
* Einschalten des Boost-Modus am Taster
an seine "Teamkollegen" weiter. Folgende Änderungen werden '''nicht''' weitergegeben:
* Status der Fensterkontakte
* Temperaturlisten/Wochenplan und daraus folgende Änderungen
* Änderungen durch Fernbedienungen
* Änderungen durch eine HomeMatic-Zentrale

Befehl zum Peeren, wobei ''<HM-CC-RT-DN#1>_ClimaTeam'' und ''<HM-CC-RT-DN#2>_ClimaTeam'' die Kanalbezeichnungen der beiden ClimaTeam-Kanäle sind:
set <HM-CC-RT-DN#1>_ClimaTeam peerChan 0 <HM-CC-RT-DN#2>_ClimaTeam single

==== Channel (Kanal) 06 _remote ====
Dieser Kanal kann an eine Fernbedienung gekoppelt werden. Per Tastendruck kann man einen bestimmten Mode und/oder eine bestimmte Temperatur wählen. Dabei kann die Reaktion auf einen langen oder kurzen Tastendruck gesondert eingestellt werden.

Der Befehl zum peeren lautet, wobei <button> die Kanalbezeichnung der Fernbedienung und <rt-remote> die Kanalbezeichnung des Heizkörperthermostates ist:
set <button> peerChan 0 <HM-CC-RT-DN>_remote single

=== Betriebsmodus Auto, Manu, Party (Urlaub) ===

Der HM-CC-RT-DN verfügt über drei Betriebsmodus: Auto, Manu (Manuell) und Party (Urlaub).

==== Modus Auto ====
Das Gerät arbeitet gemäß des gespeicherten Wochenprogramms. Manuelle Änderungen sind möglich, werden aber beim nächsten Schaltpunkt überschrieben.

==== Modus Manu ====
Die Temperatur wird manuell eingestellt, das Wochenprogramm wird nicht abgearbeitet.

==== Modus Party (Urlaub) ====
Die eingestellte Temperatur gilt bis zu einem gegebenen Endzeitpunkt, anschließend wechselt das Thermostat in den ''Auto''-Modus. So kann beispielsweise bei Abwesenheit ein niedrigeres Temperaturprofil eingestellt werden ohne dass die Temperaturlisten verändert werden müssen.

set <HM-CC-RT-DN>_Clima controlParty 16 06.12.13 16:30 09.12.13 05:00

Dadurch wird
* von 06.12.2013, 16:30 Uhr
* bis 09.12.2013, 05:00 Uhr
* die gewünschte Raumtemperatur auf 16 °C eingestellt.

{{Hinweis|
* Der Befehl muss auf dem Kanal 4 ''(_Clima)'' erfolgen.
* Es werden nur Uhrzeiten zu jeder vollen oder halben Stunde angenommen (Minuten also 00 oder 30).}}

Mit der folgenden Funktion <code>Urlaub()</code> kann man eine ganze Wohnung (also mehrere RTs) mit nur einem Befehl in den Party-Modus versetzen. Im Beispiel werden zwei Heizkörper ("Treppenhaus" und "Kammer") angesteuert.

Zu beachten sind folgende Dinge:
# Aktuelle Dateien (z.B. <code>10_CUL_HM</code>) verwenden!
# Bei dem ''controlParty''-Befehl ''kein'' Komma zwischen den Parametern.
# Bei der Funktion die Parameterübergabe definieren <code>($$$$$)</code>

'''Aufruf:'''
:<code>{Urlaub ("16", "06.12.13", "16:30", "09.12.13" ,"05:00")}</code>

'''Funktion:'''
<source lang=perl>
my $Urlaub;
sub
Urlaub($$$$$)
{
my ($temp, $startDate, $startTime, $endDate, $endTime) = @_;

# HM-CC-RT-DN akzeptiert nur Zeiten, die auf Minute 00 oder 30 enden.
# Daher $startTime und $endTime abrunden
$startTime =~ s/\:[0-2].$/:00/;
$startTime =~ s/\:[3-5].$/:30/;
$endTime =~ s/\:[0-2].$/:00/;
$endTime =~ s/\:[3-5].$/:30/;

# controlParty bei jedem HM-CC-RT-DN setzen.
for my $rt (qw(Kammer Treppenhaus)) {
fhem ("set $rt controlParty $temp $startDate $startTime $endDate $endTime");
}
}
</source>

=== Tastensperre ===

Um zu verhindern, dass der Modus oder die Temperatur per Tasten bzw. Drehrad am HM-CC-RT-DN verändert wird, kann eine Tastensperre gesetzt werden. Dies erfolgt mittels des Befehls:

set <HM-CC-RT-DN> regSet btnLock on

Rückgängig machen geht per:

set <HM-CC-RT-DN> regSet btnLock off

Diese Tastensperre kann man aber am HM-CC-RT-DN durch eine Tastenkombination wieder zurücksetzen. Um sie nur per Fhem rücksetzen zu können, muss

set <HM-CC-RT-DN> regSet globalBtnLock on

eingegeben werden. Rückgängig geht wieder per:

set <HM-CC-RT-DN> regSet globalBtnLock off

Es gibt auch eine Tastensperre die nur das Umschalten des Modus (Auto, Manuell, Urlaub) am Gerät verhindert. Diese wird mit

set <HM-CC-RT-DN> regSet modusBtnLock on

eingeschaltet. Abschalten geht mit:

set <HM-CC-RT-DN> regSet modusBtnLock off

=== Burst-Modus ===
Das ist ein '''Übertragungs'''modus für Nachrichten zwischen HM-Geräten und der Zentrale. Der RT erwacht alle 2,5 Minuten und dann überträgt die Zentrale die Kommandos. Wenn man einen Fensterkontakt oder eine Fernsteuerung nutzt, muss der RT sofort reagieren - dann muss man den Burst ''enablen''. Der RT kann in diesem Fall sofort aufgeweckt werden und bearbeitet die Anforderung (Request). Das kann man auch von der Zentrale aus nutzen (so man möchte). Das ist der '''Vorteil''' des eingeschalteten Burst-Modus.

'''Nachteil:''' Der Burst-Modus benötigt mehr Leistung, das heißt die Batterien müssen häufiger gewechselt werden: Der RT muss den Receiver ständig empfangsbereit halten. Außerdem wachen bei jedem Burst wachen ''alle'' Burst-Empfänger auf – egal an wen die Kommunikation gerichtet war.

'''Burst – wie es funktioniert'''

Schickt ein Sender eine burst Sequenz, wachen alle burst-Empfänger auf und prüfen die Message.
Wenn sie betroffen sind bleiben sie eine Zeit lang wach, ansonsten schlafen sie wieder ein.
Man beachte also, dass Senden eines Burst Energie in ALLEN burst-Empfängern verbraucht, egal ob sie angesprochen sind.

'''HMLAN und burst'''

[[HMLAN]] hat ein Sendebudget das über eine Stunde berechnet wird. Burst belastet diese Konto deutlich - so können nicht mehr als 100 bursts /h gesendet werden - dann geht HMLAN in overload Wenn zusätzliche Nachrichten gesendet werden sind es entsprechend weniger.
Es ist als nicht vorteilhaft, unnötig bursts zu senden.

'''Burst devices'''

Es gibt Devices, die immer auf burst reagieren und solche bei denen es abgeschaltet werden kann. So reagiert ein Rauchmelder immer auf Burst damit er seine Team-Kollegen hören kann.
Ein TC oder RT hingegen hat diese Funktion abschaltbar. 'Per default ist dies ausgeschaltet um Batterie zu sparen'. Wenn ein VD gesteuert wird ist der TC ja selbst wach. Wird er aber mit einem Fensterkontakt gekoppelt muss es eingeschaltet werden – sonst verpasst er die Nachricht.

'''ConditionalBurst devices'''

Devices mit abschaltbarem Burst wie z.B. der ''HM-CC-RT-DN'' haben ein Register, ''burstRx'', mit dem das burst-Erwachen eingestellt werden kann.
Sendern, die einen burst-Aktor erwecken sollen, muss man sagen, welcher Peer Burst benötigt. Hier kann ggf. das Register ''peerNeedsBurst'' nach dem Peeren gesetzt werden. FHEM versucht dies automatisch beim Peeren zu erledigen. Siehe [[HomeMatic HMInfo|HMinfo]] Befehl ''models'' um herauszufinden, welche Devices welchen Modus unterstützen.

'''Attribut burstAccess'''

Devices, die abschaltbaren burst haben kann man ein attribut bustAccess 1_auto setzen. Es wird beim Abschicken eines Kommandos versucht, das Device mit burst zu wecken. Sollte es nicht funktionieren wird gewartet, bis das Device aufwacht (meist reagieren solche Devices auch auf wakeup). Das Setzen des Attributs ist angenehm – es werden aber ggf. viele bursts gesendet.

'''Kommando burstXmit'''

Mit diesem Kommando, das bei Devices mit contitional-Burst zu Verfügung steht, wird der burst gezielt von User angestossen.

Der User schickt erst seine Kommandos an das device. Die Kommandos werden im Command-stack gesammelt.

Dann sendet der User ein set burstXmit.

Es passiert das gleiche wie bei burstAccess.

FHEM versucht mittels burst zu wecken und sendet bei Erfolg die Messages aus dem Kommandostack.

Im Gegensatz zu burstAccess ist burstXmit gezielt einsetzbar und kann sparsamer verwendet werden.

''' FHEM und burst devices'''

FHEM sendet eine burst automatisch mit Kommandos zu Devices, die nur burst unterstützen.

'''So aktiviert man den burst-Betrieb am HM-CC-RT-DN'''

''Burst Mode einschalten'' (der Kanal 4 des Device WZ1 heisst hier WZ1_4)
:<code>set WZ1_4 regSet burstRx on </code>
prüfen mit:
:<code>get WZ1_4 reg burstRx </code>
''Nun in FHEM den Burst mode einschalten (sofern nicht burstXmit verwendet wird)''
:<code>attr WZ1 burstAccess 1_auto</code>

Hinweis: Das Attribut im Device und nicht im Kanal setzen, ansonsten gibt es eine Fehlermeldung.

=== Temperaturlisten ===
Die Temperaturlisten des HM-CC-RT-DN werden identisch mit denen anderer HomeMatic Thermostate verwaltet (siehe [[HomeMatic Type Thermostat#Temperaturlisten|HomeMatic Type Thermostat]]). Beim HM-CC-RT-DN ist der Kanal 4 (_Clima) für die Temperaturlisten zuständig.

==Fhem-Log==
In den folgenden Logs heißt Kanal 4 noch "_ClimRT_tr". Inzwischen würde man dort "_Clima" sehen.

=== Device-Log ===
2013.10.10 20:03:24 3: CUL_HM Unknown device CUL_HM_HM_CC_RT_DN_2212BC, please define it
2013.10.10 20:03:24 2: autocreate: define CUL_HM_HM_CC_RT_DN_2212BC CUL_HM 2212BC A1A0184002212BC0000001000954B4551303531303031375900FFFF
2013.10.10 20:03:24 3: Device CUL_HM_HM_CC_RT_DN_2212BC added to ActionDetector with 000:10 time
2013.10.10 20:03:24 3: CUL_HM pair: CUL_HM_HM_CC_RT_DN_2212BC thermostat, model HM-CC-RT-DN serialNr KEQ0510017
2013.10.10 20:03:24 3: LANCUL pairing (hmPairForSec) not enabled
2013.10.10 20:03:24 2: autocreate: define FileLog_CUL_HM_HM_CC_RT_DN_2212BC FileLog /usr/local/FHEM/var/log/CUL_HM_HM_CC_RT_DN_2212BC-%Y.log CUL_HM_HM_CC_RT_DN_2212BC
2013.10.10 20:03:24 3: Device Heizung_Wohnzimmer added to ActionDetector with 000:10 time
2013.10.10 20:03:24 3: CUL_HM pair: Heizung_Wohnzimmer thermostat, model HM-CC-TC serialNr JEQ0044286
2013.10.10 20:03:24 3: Device CUL_HM_HM_CC_RT_DN_2212BC added to ActionDetector with 000:10 time
2013.10.10 20:03:24 3: CUL_HM pair: CUL_HM_HM_CC_RT_DN_2212BC thermostat, model HM-CC-RT-DN serialNr KEQ0510017
2013.10.10 20:03:25 2: autocreate: define CUL_HM_HM_CC_RT_DN_2212BC_Weather CUL_HM 2212BC01
2013.10.10 20:03:25 2: autocreate: define FileLog_CUL_HM_HM_CC_RT_DN_2212BC_Weather FileLog /usr/local/FHEM/var/log/CUL_HM_HM_CC_RT_DN_2212BC_Weather-%Y.log CUL_HM_HM_CC_RT_DN_2212BC_Weather
2013.10.10 20:03:25 2: autocreate: define FileLog_CUL_HM_HM_CC_RT_DN_2212BC_Weather FileLog /usr/local/FHEM/var/log/CUL_HM_HM_CC_RT_DN_2212BC_Weather-%Y.log CUL_HM_HM_CC_RT_DN_2212BC_Weather
2013.10.10 20:03:26 2: autocreate: define CUL_HM_HM_CC_RT_DN_2212BC_Climate CUL_HM 2212BC02
2013.10.10 20:03:26 2: autocreate: define FileLog_CUL_HM_HM_CC_RT_DN_2212BC_Climate FileLog /usr/local/FHEM/var/log/CUL_HM_HM_CC_RT_DN_2212BC_Climate-%Y.log CUL_HM_HM_CC_RT_DN_2212BC_Climate
2013.10.10 20:03:26 2: autocreate: define FileLog_CUL_HM_HM_CC_RT_DN_2212BC_Climate FileLog /usr/local/FHEM/var/log/CUL_HM_HM_CC_RT_DN_2212BC_Climate-%Y.log CUL_HM_HM_CC_RT_DN_2212BC_Climate
2013.10.10 20:03:27 2: autocreate: define CUL_HM_HM_CC_RT_DN_2212BC_WindowRec CUL_HM 2212BC03
2013.10.10 20:03:27 2: autocreate: define FileLog_CUL_HM_HM_CC_RT_DN_2212BC_WindowRec FileLog /usr/local/FHEM/var/log/CUL_HM_HM_CC_RT_DN_2212BC_WindowRec-%Y.log CUL_HM_HM_CC_RT_DN_2212BC_WindowRec
2013.10.10 20:03:27 2: autocreate: define FileLog_CUL_HM_HM_CC_RT_DN_2212BC_WindowRec FileLog /usr/local/FHEM/var/log/CUL_HM_HM_CC_RT_DN_2212BC_WindowRec-%Y.log CUL_HM_HM_CC_RT_DN_2212BC_WindowRec
2013.10.10 20:03:28 2: autocreate: define CUL_HM_HM_CC_RT_DN_2212BC_ClimRT_tr CUL_HM 2212BC04
2013.10.10 20:03:28 2: autocreate: define FileLog_CUL_HM_HM_CC_RT_DN_2212BC_ClimRT_tr FileLog /usr/local/FHEM/var/log/CUL_HM_HM_CC_RT_DN_2212BC_ClimRT_tr-%Y.log CUL_HM_HM_CC_RT_DN_2212BC_ClimRT_tr
2013.10.10 20:03:28 2: autocreate: define FileLog_CUL_HM_HM_CC_RT_DN_2212BC_ClimRT_tr FileLog /usr/local/FHEM/var/log/CUL_HM_HM_CC_RT_DN_2212BC_ClimRT_tr-%Y.log CUL_HM_HM_CC_RT_DN_2212BC_ClimRT_tr
2013.10.10 20:03:29 2: autocreate: define CUL_HM_HM_CC_RT_DN_2212BC_ClimaTeam CUL_HM 2212BC05
2013.10.10 20:03:29 2: autocreate: define FileLog_CUL_HM_HM_CC_RT_DN_2212BC_ClimaTeam FileLog /usr/local/FHEM/var/log/CUL_HM_HM_CC_RT_DN_2212BC_ClimaTeam-%Y.log CUL_HM_HM_CC_RT_DN_2212BC_ClimaTeam
2013.10.10 20:03:29 2: autocreate: define FileLog_CUL_HM_HM_CC_RT_DN_2212BC_ClimaTeam FileLog /usr/local/FHEM/var/log/CUL_HM_HM_CC_RT_DN_2212BC_ClimaTeam-%Y.log CUL_HM_HM_CC_RT_DN_2212BC_ClimaTeam
2013.10.10 20:03:30 2: autocreate: define CUL_HM_HM_CC_RT_DN_2212BC_remote CUL_HM 2212BC06
2013.10.10 20:03:30 2: autocreate: define FileLog_CUL_HM_HM_CC_RT_DN_2212BC_remote FileLog /usr/local/FHEM/var/log/CUL_HM_HM_CC_RT_DN_2212BC_remote-%Y.log CUL_HM_HM_CC_RT_DN_2212BC_remote
2013.10.10 20:03:30 2: autocreate: define FileLog_CUL_HM_HM_CC_RT_DN_2212BC_remote FileLog /usr/local/FHEM/var/log/CUL_HM_HM_CC_RT_DN_2212BC_remote-%Y.log CUL_HM_HM_CC_RT_DN_2212BC_remote
2013.10.10 20:03:35 3: Device CUL_HM_HM_CC_RT_DN_2212BC added to ActionDetector with 000:10 time
2013.10.10 20:03:40 2: CUL_HM set CUL_HM_HM_CC_RT_DN_2212BC getSerial
2013.10.10 20:03:40 2: CUL_HM set CUL_HM_HM_CC_RT_DN_2212BC getConfig
2013.10.10 20:03:54 3: Device CUL_HM_HM_CC_RT_DN_2212BC added to ActionDetector with 000:10 time

=== Event monitor ===
2013-10-12 12:05:35.610 CUL_HM CUL_HM_HM_CC_RT_DN_2212BC_ClimRT_tr motorErr: ok
2013-10-12 12:05:35.610 CUL_HM CUL_HM_HM_CC_RT_DN_2212BC_ClimRT_tr measured-temp: 18.4
2013-10-12 12:05:35.610 CUL_HM CUL_HM_HM_CC_RT_DN_2212BC_ClimRT_tr desired-temp: 18
2013-10-12 12:05:35.610 CUL_HM CUL_HM_HM_CC_RT_DN_2212BC_ClimRT_tr ValvePosition: 3 %
2013-10-12 12:05:35.610 CUL_HM CUL_HM_HM_CC_RT_DN_2212BC_ClimRT_tr mode: manu
2013-10-12 12:05:35.610 CUL_HM CUL_HM_HM_CC_RT_DN_2212BC_ClimRT_tr unknown0: 24
2013-10-12 12:05:35.610 CUL_HM CUL_HM_HM_CC_RT_DN_2212BC_ClimRT_tr T: 18.4 desired: 18 valve: 3 %
2013-10-12 12:05:35.646 CUL_HM CUL_HM_HM_CC_RT_DN_2212BC battery: ok
2013-10-12 12:05:35.646 CUL_HM CUL_HM_HM_CC_RT_DN_2212BC batteryLevel: 3.1 V
2013-10-12 12:05:35.646 CUL_HM CUL_HM_HM_CC_RT_DN_2212BC measured-temp: 18.4
2013-10-12 12:05:35.646 CUL_HM CUL_HM_HM_CC_RT_DN_2212BC desired-temp: 18
2013-10-12 12:05:35.646 CUL_HM CUL_HM_HM_CC_RT_DN_2212BC actuator: 3 %

== Firmware Update ==
Seit 24.10.2014 gibt es für den HM-CC-RT-DN die neue Firmware Version 1.4. Diese kann von der eQ-3 Webseite heruntergeladen werden. Genauere Informationen gibt es unter [[HomeMatic Firmware Update]].

=== HM-CC-RT-DN spezifische Update Informationen ===
Durch gleichzeitiges Drücken der "Auto-/Manu"-Taste und der "Comfort-/Eco"-Taste am HM-CC-RT-DN während man die Batterien wieder einlegt wird der updatemodus gestartet. Während des Updates steht "FUP" im Display. Nach erfolgreichem Update erscheint "Ins" im Display und es muss eine erneute Adaptierfahrt durch drücken der Boost-Taste ausgelöst werden. Anschließend sollte der HM-CC-RT-DN wieder normal funktionieren. Die eingestellten Parameter und das Pairing mit FHEM gehen beim Update nicht verloren. Sollte das Update fehlschlagen, erscheint "Err" bzw. "CrC" im Display.

Normalerweise sollte dann durch erneutes starten der Prozedur am PC und HM-CC-RT-DN das ganze erneut durchführbar sein.

Es gibt einige Readings, die nicht durch ein einfaches ''getConfig'' aktualisisert werden, z.B. "battery"(nicht batteryLevel). Um diese Readings zu bekommen, ist ein
:<code>set Device_Channel04 controlMode auto </code>
notwendig. Daraufhin werden die Readings übertragen/aktualisiert.

== Simulation von Fensterkontakten und externen Temperatursensoren ==
grober Ablauf:
* erstellen ein virtuelles Device
* erstelle dazu einen virtuellen Kanal
* peeren den Kanal mit dem RT (als fenster-kontakt oder als remote, wen du willst)
* sende ein postEvent

=== Fensterkontakte ===
''Entnommen aus diesem {{Link2Forum|Topic=31078|Message=236245|LinkText=Forenbeitrag}}''
define virSC CUL_HM 221133
attr virSC autoReadReg 4_reqStatus
attr virSC expert 2_full
attr virSC model virtual_1
attr virSC peerIDs
attr virSC subType virtual
attr virSC webCmd press short:press long

define virtualKitchenDoor CUL_HM 22113301
attr virtualKitchenDoor dummy 1
attr virtualKitchenDoor expert 1
attr virtualKitchenDoor group Virtual
attr virtualKitchenDoor model virtual_1
attr virtualKitchenDoor webCmd postEvent open:postEvent closed

Anschließend peeren und Temperatur festlegen mit:
set virtualKitchenDoor peerChan 0 <Thermostat_Window_Rec> single set
set <Thermostat_Window_Rec> regSet winOpnTemp 5 virtualKitchenDoor

Die virtuelle Tür wird dann entsprechend über ein Notify getriggert:
define notify_virtualKitchenDoor notify (Fensterkontakt_1|Fensterkontakt_2) {if(Value("Fensterkontakt") eq "open" && Value("Fensterkontakt_2") eq "open"){fhem("set virtualKitchenDoor postEvent open")}else{fhem("set virtualKitchenDoor postEvent closed")}}

=== Temperatursensoren ===
''Entnommen aus diesem {{Link2Forum|Topic=19686|Message=233788|LinkText=Forenbeitrag}}''

1. Virtuelles HomeMatic Device mit _deiner_ HM Id definieren:
define wz_vT CUL_HM <hmId>

2. Dem Device einen virtuellen Kanal (Default ist ein virtueller Button) hinzufügen:
set wz_vT virtual 1

3. Es ist kein virtueller Button sondern ein virtueller Temperatursensor - darum rename:
rename wz_vT_Btn1 wz_vT_Sensor1

4. Virtuellen Peer Sensor mit dem Weather Channel des RT-DN peeren:
set wz_vT_Sensor1 peerChan 0 <RT_DN>_Weather single

5. Peering kontrollieren (Voraussetzung: Device ''hm'' vom Typ [[HomeMatic HMInfo|HMinfo]] existiert):
:<code>set hm peerXref</code>
Beispiel-Ausgabe:
peerXref done:
x-ref list
wz_Thermostat_Weather => wz_vT_Sensor1
wz_vT_Sensor1 => wz_Thermostat_Weather

6. Gemessene Temperatur vom z.B. 1-Wire DS1820 dem virtuellen HM Sensor übergeben. Z.B. alle zwei Minuten per at:
define at_wz_vT at +*00:02 { my $T=(ReadingsVal("<DS1820B>","temperature",20.0)); fhem "set wz_vT_Sensor1 virtTemp $T" }

Fertig.

== Bekannte Probleme ==
=== TempList: Bad format ... ===
Wenn Sie beim Setzen einer Temperaturliste nach dem o.a. Schema ("SetTempList...") die Meldung

Bad format, use HH:MM TEMP ......

erhalten, sollten Sie zunächst ein [[update]] von Fhem durchführen.

== Links ==
* [http://www.eq-3.de/produkt-detail-aktoren/items/homematic-funk-heizkoerperthermostat.html Produktinfo]
* [http://www.eq-3.de/Downloads/eq3/pdf_produkte/HM-CC-RT-DN_UM_GE_eQ-3_web.pdf Bedienungsanleitung (PDF)]
* [http://www.eq-3.de/Downloads/eq3/pdf_produkte/Funk-Heizkoerperthermostat_105155_Produktdatenblatt_V2.2.pdf Datenblatt (PDF)]
* [http://www.eq-3.de/Downloads/eq3/downloads/Ventilkompatibilitaeten.pdf Ventil-Kompatibilitätsliste (PDF)]
* {{Link2Forum|Topic=14738|LinkText=Forenthema zum Thermostat}}

[[Kategorie:HomeMatic Components]]
[[Kategorie:Heizungsventile]]

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

2016-11-01T12:17:21Z

Stephan1965: /* Channel (Kanal) 06 _remote */

{{Infobox Hardware
|Bild=HM-CC-RT-DN.jpg
|Bildbeschreibung=HM-CC-RT-DN an Heizkörper montiert
|HWProtocol=[[HomeMatic]]
|HWType=[[HomeMatic Type Thermostat|thermostat]]
|HWCategory=[[:Kategorie:Heizungsventile|Heizungsventile]]
|HWComm=868 MHz
|HWChannels=6
|HWVoltage=3 V
|HWPowerConsumption=180 mA
|HWPoweredBy=2x LR6/Mignon/AA
|HWSize=54x65x93 mm (BxHxT)
|HWDeviceFHEM=[[CUL_HM]]

|HWManufacturer=ELV / eQ-3
}}

'''HM-CC-RT-DN''' (häufig einfach '''RT''' genannt) ist ein Funk-''Heizkörperthermostate'' mit integriertem ''Stellantrieb''. Das Thermostat ist seit September 2013 verfügbar und ist der Nachfolger des [[HM-CC-VD Funk-Stellantrieb]]s.

== Vorbemerkungen ==
: ''→ Einstellungen und Informationen, die alle [[HomeMatic]] Thermostate betreffen, sind unter [[HomeMatic Type Thermostat#Temperaturlisten|HomeMatic Type Thermostat]] zu finden.''

Der HM-CC-RT-DN kann die Temperatur selbst messen (im Gegensatz zum [[HM-CC-VD Funk-Stellantrieb|Vorgänger]]) und verfügt über eine Fenster-Offen-Erkennung sowie eine Boost-Funktion. Der HM-CC-RT-DN ''kann'' von einem [[HM-TC-IT-WM-W-EU Funk-Wandthermostat AP]] gesteuert werden, das ist aber ''optional''.

Das Gerät wird seit Anfang Oktober 2013 von Fhem unterstützt (siehe Diskussion im {{Link2Forum|Topic=14738|LinkText=Forum}}).

Der HM-CC-RT-DN scheint das erste HomeMatic-Device zu sein, bei dem ein Update der Firmware auch vom Anwender durchgeführt werden kann. Ein Firmware-Update erfordert einen [[HM-CFG-USB_USB_Konfigurations-Adapter|USB Konfigurations-Adapter]] und eine auf der eQ-3 Webseite herunterladbare Firmwareupdate-Software. Weitere Details sind unter [[#Firmware Update|Firmware Update]] beschrieben.
{{Hinweis|Die Solltemperaturen eines HM-CC-RT-DN lassen sich ''nicht'' durch einen [[HM-CC-TC Funk-Wandthermostat]] ''steuern''. Dieser kann nur die Ist-Temperatur an den HM-CC-RT-DN weitergeben, damit nicht die am HM-CC-RT-DN direkt gemessene Raumtemperatur zur Regelung verwendet wird.}}
Mit einem HM-CC-RT-DN können maximal (neben der Zentrale/Fhem):
* 7 HomeMatic Heizkörperthermostate
* 8 HomeMatic Tür-Fensterkontakte / Fenster-Drehgriffkontakte
* 8 Tastenpaare von HomeMatic Fernbedienungen bzw. Display-Wandtaster
* 1 HomeMatic Innen-Temperatur-Sensor
[[Peering (HomeMatic)|gepeert]] werden.

{{Hinweis|Wird für Wartungs-/Umbaumaßnahmen das Wasser der Heizung abgelassen bzw. diese neubefüllt, sind alle Stellantriebe manuell dauerhaft auf '''on''' zu setzen: set <HM_Stellantrieb>_Clima controlManu on. Beim Einsatz eines Wandthermostaten ist der Wandthermostat entsprechend einzustellen.}}

== Technische Daten ==
* Betriebsspannung: 2 Stck. 1,5V LR6/Mignon/AA
* Stromaufnahme: 180 mA max.
* Abmessungen (B x H x T): 54 x 65 x 93 mm
* Gewicht: 180 g (ohne Batterien)
* Ventilanschluss: M30 x 1,5 mm

Aktuelle Firmware: 1.4

== Betrieb mit FHEM ==
Der Funk-Heizkörperthermostat muss zuerst mit Fhem [[Pairing (HomeMatic)|gepairt]] werden. Stellen Sie sicher, dass Fhem aktuell ist (update durchführen)

Das Pairing sollte wie in [[HomeMatic Devices pairen]] beschrieben durchgeführt werden

=== Channels (Kanäle) ===
==== Channel (Kanal) 01 _Weather ====

Dieser Kanal dient zur Einspeisung der (gemessenen) ''Ist-Temperatur''. Als Sensor können zum Beispiel das [[HM-TC-IT-WM-W-EU Funk-Wandthermostat AP|HM-TC-IT-WM-W-EU Funk-Wandthermostat]] oder ein [[HM-WDS40-TH-I Funk-Temperatur-/Feuchtesensor innen (IT)|HM-WDS40-TH-I Funk-Temperatur-/Feuchtesensor]] dienen.

Ein Temperatur-Sensor ''tempSensor'' kann mit dem ''_Weather''-Kanal wie folgt [[Peering (HomeMatic)|gepeert]] werden:

set <tempSensor> peerChan 0 <HM-CC-RT-DN>_Weather single

==== Channel (Kanal) 02 _Climate ====
Dieser Kanal erlaubt es dem [[HM-TC-IT-WM-W-EU Funk-Wandthermostat AP|HM-TC-IT-WM-W-EU Funk-Wandthermostat]] den HM-CC-RT-DN zu steuern. Dazu müssen die beiden Geräte gepeert werden:

set <HM-TC-IT-WM-W-EU>_Climate peerChan 0 <HM-CC-RT-DN>_Climate single set

==== Channel (Kanal) 03 _WindowRec ====
Mit diesem Kanal können Fensterkontakte ([[HM-SEC-SC Tür-Fensterkontakt|HM-SEC-SC]] und [[HM-Sec-RHS Funk-Fenster-Drehgriffkontakt|HM-SEC-RHS]]) ihren Fensterstatus (geöffnet / gekippt) an ein oder mehrere Thermostate senden. Die Thermostate stellen anschließend die entsprechende (konfigurierbare) Temperatur ein. Der Temperaturwert kann je Fenster-Sensor unterschiedlich definiert werden. Sind mehrere Fenster gleichzeitig geöffnet, so wird der Thermostat auf die Temperatur des Sensors mit dem geringsten Temperaturwert eingestellt.
Ferner wird empfohlen, bei Einsatz von externen Sensoren, die interne „Fenster auf Erkennung“ zu deaktivieren (weitere Details sind im [[HM-CC-RT-DN Funk-Heizkörperthermostat#Channel .28Kanal.29 04 _Clima|Channel (Kanal) 04 _Clima]] beschrieben).

Der Befehl zum Peeren lautet, wobei <fensterSensor> die Fhem-Kanalbezeichnung für den Fensterkontakt ist und <rt_WindowRec> die Kanalbezeichnung für den entsprechenden Kanal des Heizkörperthermostates:
set <fensterSensor> peerChan 0 <HM-CC-RT-DN>_WindowRec single

Zum Löschen (=unpeeren) dieser Kopplung:
set <fensterSensor> peerChan 0 <HM-CC-RT-DN>_WindowRec single unset

'''Achtung''': Der Peer-(Lösch)Vorgang muss am Fensterkontakt durch Drücken der Anlerntaste bestätigt werden, und zwar auch dann, wenn der Fensterkontakt schon vorher mit Fhem gepairt wurde. Wichtig scheint auch, dass der Fensterkontakt geschlossen ist wenn man die Anlerntaste drückt.

Der Befehl zur Temperatureinstellung des Heizkörperthermostaten für den Zustand "Fenster offen" lautet, wobei <fensterSensor> die Fhem-Kanalbezeichnung für den Fensterkontakt ist und <rt_WindowRec> die Kanalbezeichnung für den entsprechenden Kanal des Heizkörperthermostates, sowie <Temp> die einzustellende Temperatur (ganzzahliger Wert):
set <HM-CC-RT-DN>_WindowRec regSet winOpnTemp <Temp> <fensterSensor>

==== Channel (Kanal) 04 _Clima ====
Dieser Kanal dient zum Einstellen der Betriebsparameter, auch [[#Temperaturlisten|Temperaturlisten]] sind hierauf zu übertragen.

{{Hinweis|In älteren Versionen von Fhem wurde dieser Kanal durch ''autocreate'' als <code>_ClimRT_tr</code> angelegt. Der Hersteller hat hier offenbar die internen Bezeichnungen geändert, denn beim Vorläufernmodell HM-CC-TC mussten Temperaturlisten auf den Kanal ''Climate'' übertragen werden.}}

Die maximale Öffnung des Ventils kann mittels folgendem Befehl eingestellt werden (hier auf 80 %):
set <HM-CC-RT-DN>_Clima regSet valveMaxPos 80

Die interne "Fenster-auf"-Erkennung kann man wie folgt abschalten:
set <HM-CC-RT-DN>_Clima regSet winOpnMode off

==== Channel (Kanal) 05 _ClimaTeam ====
Dieser Kanal erlaubt es mehrere HM-CC-RT-DN zu einem "Team" zu gruppieren. Ein Mitglied des Teams meldet
* Änderungen der Temperatur am Handrad
* Einschalten des Boost-Modus am Taster
an seine "Teamkollegen" weiter. Folgende Änderungen werden '''nicht''' weitergegeben:
* Status der Fensterkontakte
* Temperaturlisten/Wochenplan und daraus folgende Änderungen
* Änderungen durch Fernbedienungen
* Änderungen durch eine HomeMatic-Zentrale

Befehl zum Peeren, wobei ''<HM-CC-RT-DN#1>_ClimaTeam'' und ''<HM-CC-RT-DN#2>_ClimaTeam'' die Kanalbezeichnungen der beiden ClimaTeam-Kanäle sind:
set <HM-CC-RT-DN#1>_ClimaTeam peerChan 0 <HM-CC-RT-DN#2>_ClimaTeam single

==== Channel (Kanal) 06 _remote ====
Dieser Kanal kann an eine Fernbedienung gekoppelt werden. Per Tastendruck kann man einen bestimmten Mode und/oder eine bestimmte Temperatur wählen. Dabei kann die Reaktion auf einen langen oder kurzen Tastendruck gesondert eingestellt werden.

Der Befehl zum peeren lautet, wobei <button> die Kanalbezeichnung der Fernbedienung und <rt-remote> die Kanalbezeichnung des Heizkörperthermostates ist:
set <button> peerChan 0 <HM-CC-RT-DN>_remote single

=== Betriebsmodus Auto, Manu, Party (Urlaub) ===

Der HM-CC-RT-DN verfügt über drei Betriebsmodus: Auto, Manu (Manuell) und Party (Urlaub).

==== Modus Auto ====
Das Gerät arbeitet gemäß des gespeicherten Wochenprogramms. Manuelle Änderungen sind möglich, werden beim nächsten Schaltpunkt überschrieben.

==== Modus Manu ====
Die Temperatur wird manuell eingestellt, das Wochenprogramm wird nicht abgearbeitet.

==== Modus Party (Urlaub) ====
Die eingestellte Temperatur gilt bis zu einem gegebenen Endzeitpunkt, anschließend wechselt das Thermostat in den ''Auto''-Modus. So kann beispielsweise bei Abwesenheit ein niedrigeres Temperaturprofil eingestellt werden ohne dass die Temperaturlisten verändert werden müssen.

set <HM-CC-RT-DN>_Clima controlParty 16 06.12.13 16:30 09.12.13 05:00

Dadurch wird
* von 06.12.2013, 16:30 Uhr
* bis 09.12.2013, 05:00 Uhr
* die gewünschte Raumtemperatur auf 16 °C eingestellt.

{{Hinweis|
* Der Befehl muss auf dem Kanal 4 ''(_Clima)'' erfolgen.
* Es werden nur Uhrzeiten zu jeder vollen oder halben Stunde angenommen (Minuten also 00 oder 30).}}

Mit der folgenden Funktion <code>Urlaub()</code> kann man eine ganze Wohnung (also mehrere RTs) mit nur einem Befehl in den Party-Modus versetzen. Im Beispiel werden zwei Heizkörper ("Treppenhaus" und "Kammer") angesteuert.

Zu beachten sind folgende Dinge:
# Aktuelle Dateien (z.B. <code>10_CUL_HM</code>) verwenden!
# Bei dem ''controlParty''-Befehl ''kein'' Komma zwischen den Parametern.
# Bei der Funktion die Parameterübergabe definieren <code>($$$$$)</code>

'''Aufruf:'''
:<code>{Urlaub ("16", "06.12.13", "16:30", "09.12.13" ,"05:00")}</code>

'''Funktion:'''
<source lang=perl>
my $Urlaub;
sub
Urlaub($$$$$)
{
my ($temp, $startDate, $startTime, $endDate, $endTime) = @_;

# HM-CC-RT-DN akzeptiert nur Zeiten, die auf Minute 00 oder 30 enden.
# Daher $startTime und $endTime abrunden
$startTime =~ s/\:[0-2].$/:00/;
$startTime =~ s/\:[3-5].$/:30/;
$endTime =~ s/\:[0-2].$/:00/;
$endTime =~ s/\:[3-5].$/:30/;

# controlParty bei jedem HM-CC-RT-DN setzen.
for my $rt (qw(Kammer Treppenhaus)) {
fhem ("set $rt controlParty $temp $startDate $startTime $endDate $endTime");
}
}
</source>

=== Tastensperre ===

Um zu verhindern, dass der Modus oder die Temperatur per Tasten bzw. Drehrad am HM-CC-RT-DN verändert wird, kann eine Tastensperre gesetzt werden. Dies erfolgt mittels des Befehls:

set <HM-CC-RT-DN> regSet btnLock on

Rückgängig machen geht per:

set <HM-CC-RT-DN> regSet btnLock off

Diese Tastensperre kann man aber am HM-CC-RT-DN durch eine Tastenkombination wieder zurücksetzen. Um sie nur per Fhem rücksetzen zu können, muss

set <HM-CC-RT-DN> regSet globalBtnLock on

eingegeben werden. Rückgängig geht wieder per:

set <HM-CC-RT-DN> regSet globalBtnLock off

Es gibt auch eine Tastensperre die nur das Umschalten des Modus (Auto, Manuell, Urlaub) am Gerät verhindert. Diese wird mit

set <HM-CC-RT-DN> regSet modusBtnLock on

eingeschaltet. Abschalten geht mit:

set <HM-CC-RT-DN> regSet modusBtnLock off

=== Burst-Modus ===
Das ist ein '''Übertragungs'''modus für Nachrichten zwischen HM-Geräten und der Zentrale. Der RT erwacht alle 2,5 Minuten und dann überträgt die Zentrale die Kommandos. Wenn man einen Fensterkontakt oder eine Fernsteuerung nutzt, muss der RT sofort reagieren - dann muss man den Burst ''enablen''. Der RT kann in diesem Fall sofort aufgeweckt werden und bearbeitet die Anforderung (Request). Das kann man auch von der Zentrale aus nutzen (so man möchte). Das ist der '''Vorteil''' des eingeschalteten Burst-Modus.

'''Nachteil:''' Der Burst-Modus benötigt mehr Leistung, das heißt die Batterien müssen häufiger gewechselt werden: Der RT muss den Receiver ständig empfangsbereit halten. Außerdem wachen bei jedem Burst wachen ''alle'' Burst-Empfänger auf – egal an wen die Kommunikation gerichtet war.

'''Burst – wie es funktioniert'''

Schickt ein Sender eine burst Sequenz, wachen alle burst-Empfänger auf und prüfen die Message.
Wenn sie betroffen sind bleiben sie eine Zeit lang wach, ansonsten schlafen sie wieder ein.
Man beachte also, dass Senden eines Burst Energie in ALLEN burst-Empfängern verbraucht, egal ob sie angesprochen sind.

'''HMLAN und burst'''

[[HMLAN]] hat ein Sendebudget das über eine Stunde berechnet wird. Burst belastet diese Konto deutlich - so können nicht mehr als 100 bursts /h gesendet werden - dann geht HMLAN in overload Wenn zusätzliche Nachrichten gesendet werden sind es entsprechend weniger.
Es ist als nicht vorteilhaft, unnötig bursts zu senden.

'''Burst devices'''

Es gibt Devices, die immer auf burst reagieren und solche bei denen es abgeschaltet werden kann. So reagiert ein Rauchmelder immer auf Burst damit er seine Team-Kollegen hören kann.
Ein TC oder RT hingegen hat diese Funktion abschaltbar. 'Per default ist dies ausgeschaltet um Batterie zu sparen'. Wenn ein VD gesteuert wird ist der TC ja selbst wach. Wird er aber mit einem Fensterkontakt gekoppelt muss es eingeschaltet werden – sonst verpasst er die Nachricht.

'''ConditionalBurst devices'''

Devices mit abschaltbarem Burst wie z.B. der ''HM-CC-RT-DN'' haben ein Register, ''burstRx'', mit dem das burst-Erwachen eingestellt werden kann.
Sendern, die einen burst-Aktor erwecken sollen, muss man sagen, welcher Peer Burst benötigt. Hier kann ggf. das Register ''peerNeedsBurst'' nach dem Peeren gesetzt werden. FHEM versucht dies automatisch beim Peeren zu erledigen. Siehe [[HomeMatic HMInfo|HMinfo]] Befehl ''models'' um herauszufinden, welche Devices welchen Modus unterstützen.

'''Attribut burstAccess'''

Devices, die abschaltbaren burst haben kann man ein attribut bustAccess 1_auto setzen. Es wird beim Abschicken eines Kommandos versucht, das Device mit burst zu wecken. Sollte es nicht funktionieren wird gewartet, bis das Device aufwacht (meist reagieren solche Devices auch auf wakeup). Das Setzen des Attributs ist angenehm – es werden aber ggf. viele bursts gesendet.

'''Kommando burstXmit'''

Mit diesem Kommando, das bei Devices mit contitional-Burst zu Verfügung steht, wird der burst gezielt von User angestossen.

Der User schickt erst seine Kommandos an das device. Die Kommandos werden im Command-stack gesammelt.

Dann sendet der User ein set burstXmit.

Es passiert das gleiche wie bei burstAccess.

FHEM versucht mittels burst zu wecken und sendet bei Erfolg die Messages aus dem Kommandostack.

Im Gegensatz zu burstAccess ist burstXmit gezielt einsetzbar und kann sparsamer verwendet werden.

''' FHEM und burst devices'''

FHEM sendet eine burst automatisch mit Kommandos zu Devices, die nur burst unterstützen.

'''So aktiviert man den burst-Betrieb am HM-CC-RT-DN'''

''Burst Mode einschalten'' (der Kanal 4 des Device WZ1 heisst hier WZ1_4)
:<code>set WZ1_4 regSet burstRx on </code>
prüfen mit:
:<code>get WZ1_4 reg burstRx </code>
''Nun in FHEM den Burst mode einschalten (sofern nicht burstXmit verwendet wird)''
:<code>attr WZ1 burstAccess 1_auto</code>

Hinweis: Das Attribut im Device und nicht im Kanal setzen, ansonsten gibt es eine Fehlermeldung.

=== Temperaturlisten ===
Die Temperaturlisten des HM-CC-RT-DN werden identisch mit denen anderer HomeMatic Thermostate verwaltet (siehe [[HomeMatic Type Thermostat#Temperaturlisten|HomeMatic Type Thermostat]]). Beim HM-CC-RT-DN ist der Kanal 4 (_Clima) für die Temperaturlisten zuständig.

==Fhem-Log==
In den folgenden Logs heißt Kanal 4 noch "_ClimRT_tr". Inzwischen würde man dort "_Clima" sehen.

=== Device-Log ===
2013.10.10 20:03:24 3: CUL_HM Unknown device CUL_HM_HM_CC_RT_DN_2212BC, please define it
2013.10.10 20:03:24 2: autocreate: define CUL_HM_HM_CC_RT_DN_2212BC CUL_HM 2212BC A1A0184002212BC0000001000954B4551303531303031375900FFFF
2013.10.10 20:03:24 3: Device CUL_HM_HM_CC_RT_DN_2212BC added to ActionDetector with 000:10 time
2013.10.10 20:03:24 3: CUL_HM pair: CUL_HM_HM_CC_RT_DN_2212BC thermostat, model HM-CC-RT-DN serialNr KEQ0510017
2013.10.10 20:03:24 3: LANCUL pairing (hmPairForSec) not enabled
2013.10.10 20:03:24 2: autocreate: define FileLog_CUL_HM_HM_CC_RT_DN_2212BC FileLog /usr/local/FHEM/var/log/CUL_HM_HM_CC_RT_DN_2212BC-%Y.log CUL_HM_HM_CC_RT_DN_2212BC
2013.10.10 20:03:24 3: Device Heizung_Wohnzimmer added to ActionDetector with 000:10 time
2013.10.10 20:03:24 3: CUL_HM pair: Heizung_Wohnzimmer thermostat, model HM-CC-TC serialNr JEQ0044286
2013.10.10 20:03:24 3: Device CUL_HM_HM_CC_RT_DN_2212BC added to ActionDetector with 000:10 time
2013.10.10 20:03:24 3: CUL_HM pair: CUL_HM_HM_CC_RT_DN_2212BC thermostat, model HM-CC-RT-DN serialNr KEQ0510017
2013.10.10 20:03:25 2: autocreate: define CUL_HM_HM_CC_RT_DN_2212BC_Weather CUL_HM 2212BC01
2013.10.10 20:03:25 2: autocreate: define FileLog_CUL_HM_HM_CC_RT_DN_2212BC_Weather FileLog /usr/local/FHEM/var/log/CUL_HM_HM_CC_RT_DN_2212BC_Weather-%Y.log CUL_HM_HM_CC_RT_DN_2212BC_Weather
2013.10.10 20:03:25 2: autocreate: define FileLog_CUL_HM_HM_CC_RT_DN_2212BC_Weather FileLog /usr/local/FHEM/var/log/CUL_HM_HM_CC_RT_DN_2212BC_Weather-%Y.log CUL_HM_HM_CC_RT_DN_2212BC_Weather
2013.10.10 20:03:26 2: autocreate: define CUL_HM_HM_CC_RT_DN_2212BC_Climate CUL_HM 2212BC02
2013.10.10 20:03:26 2: autocreate: define FileLog_CUL_HM_HM_CC_RT_DN_2212BC_Climate FileLog /usr/local/FHEM/var/log/CUL_HM_HM_CC_RT_DN_2212BC_Climate-%Y.log CUL_HM_HM_CC_RT_DN_2212BC_Climate
2013.10.10 20:03:26 2: autocreate: define FileLog_CUL_HM_HM_CC_RT_DN_2212BC_Climate FileLog /usr/local/FHEM/var/log/CUL_HM_HM_CC_RT_DN_2212BC_Climate-%Y.log CUL_HM_HM_CC_RT_DN_2212BC_Climate
2013.10.10 20:03:27 2: autocreate: define CUL_HM_HM_CC_RT_DN_2212BC_WindowRec CUL_HM 2212BC03
2013.10.10 20:03:27 2: autocreate: define FileLog_CUL_HM_HM_CC_RT_DN_2212BC_WindowRec FileLog /usr/local/FHEM/var/log/CUL_HM_HM_CC_RT_DN_2212BC_WindowRec-%Y.log CUL_HM_HM_CC_RT_DN_2212BC_WindowRec
2013.10.10 20:03:27 2: autocreate: define FileLog_CUL_HM_HM_CC_RT_DN_2212BC_WindowRec FileLog /usr/local/FHEM/var/log/CUL_HM_HM_CC_RT_DN_2212BC_WindowRec-%Y.log CUL_HM_HM_CC_RT_DN_2212BC_WindowRec
2013.10.10 20:03:28 2: autocreate: define CUL_HM_HM_CC_RT_DN_2212BC_ClimRT_tr CUL_HM 2212BC04
2013.10.10 20:03:28 2: autocreate: define FileLog_CUL_HM_HM_CC_RT_DN_2212BC_ClimRT_tr FileLog /usr/local/FHEM/var/log/CUL_HM_HM_CC_RT_DN_2212BC_ClimRT_tr-%Y.log CUL_HM_HM_CC_RT_DN_2212BC_ClimRT_tr
2013.10.10 20:03:28 2: autocreate: define FileLog_CUL_HM_HM_CC_RT_DN_2212BC_ClimRT_tr FileLog /usr/local/FHEM/var/log/CUL_HM_HM_CC_RT_DN_2212BC_ClimRT_tr-%Y.log CUL_HM_HM_CC_RT_DN_2212BC_ClimRT_tr
2013.10.10 20:03:29 2: autocreate: define CUL_HM_HM_CC_RT_DN_2212BC_ClimaTeam CUL_HM 2212BC05
2013.10.10 20:03:29 2: autocreate: define FileLog_CUL_HM_HM_CC_RT_DN_2212BC_ClimaTeam FileLog /usr/local/FHEM/var/log/CUL_HM_HM_CC_RT_DN_2212BC_ClimaTeam-%Y.log CUL_HM_HM_CC_RT_DN_2212BC_ClimaTeam
2013.10.10 20:03:29 2: autocreate: define FileLog_CUL_HM_HM_CC_RT_DN_2212BC_ClimaTeam FileLog /usr/local/FHEM/var/log/CUL_HM_HM_CC_RT_DN_2212BC_ClimaTeam-%Y.log CUL_HM_HM_CC_RT_DN_2212BC_ClimaTeam
2013.10.10 20:03:30 2: autocreate: define CUL_HM_HM_CC_RT_DN_2212BC_remote CUL_HM 2212BC06
2013.10.10 20:03:30 2: autocreate: define FileLog_CUL_HM_HM_CC_RT_DN_2212BC_remote FileLog /usr/local/FHEM/var/log/CUL_HM_HM_CC_RT_DN_2212BC_remote-%Y.log CUL_HM_HM_CC_RT_DN_2212BC_remote
2013.10.10 20:03:30 2: autocreate: define FileLog_CUL_HM_HM_CC_RT_DN_2212BC_remote FileLog /usr/local/FHEM/var/log/CUL_HM_HM_CC_RT_DN_2212BC_remote-%Y.log CUL_HM_HM_CC_RT_DN_2212BC_remote
2013.10.10 20:03:35 3: Device CUL_HM_HM_CC_RT_DN_2212BC added to ActionDetector with 000:10 time
2013.10.10 20:03:40 2: CUL_HM set CUL_HM_HM_CC_RT_DN_2212BC getSerial
2013.10.10 20:03:40 2: CUL_HM set CUL_HM_HM_CC_RT_DN_2212BC getConfig
2013.10.10 20:03:54 3: Device CUL_HM_HM_CC_RT_DN_2212BC added to ActionDetector with 000:10 time

=== Event monitor ===
2013-10-12 12:05:35.610 CUL_HM CUL_HM_HM_CC_RT_DN_2212BC_ClimRT_tr motorErr: ok
2013-10-12 12:05:35.610 CUL_HM CUL_HM_HM_CC_RT_DN_2212BC_ClimRT_tr measured-temp: 18.4
2013-10-12 12:05:35.610 CUL_HM CUL_HM_HM_CC_RT_DN_2212BC_ClimRT_tr desired-temp: 18
2013-10-12 12:05:35.610 CUL_HM CUL_HM_HM_CC_RT_DN_2212BC_ClimRT_tr ValvePosition: 3 %
2013-10-12 12:05:35.610 CUL_HM CUL_HM_HM_CC_RT_DN_2212BC_ClimRT_tr mode: manu
2013-10-12 12:05:35.610 CUL_HM CUL_HM_HM_CC_RT_DN_2212BC_ClimRT_tr unknown0: 24
2013-10-12 12:05:35.610 CUL_HM CUL_HM_HM_CC_RT_DN_2212BC_ClimRT_tr T: 18.4 desired: 18 valve: 3 %
2013-10-12 12:05:35.646 CUL_HM CUL_HM_HM_CC_RT_DN_2212BC battery: ok
2013-10-12 12:05:35.646 CUL_HM CUL_HM_HM_CC_RT_DN_2212BC batteryLevel: 3.1 V
2013-10-12 12:05:35.646 CUL_HM CUL_HM_HM_CC_RT_DN_2212BC measured-temp: 18.4
2013-10-12 12:05:35.646 CUL_HM CUL_HM_HM_CC_RT_DN_2212BC desired-temp: 18
2013-10-12 12:05:35.646 CUL_HM CUL_HM_HM_CC_RT_DN_2212BC actuator: 3 %

== Firmware Update ==
Seit 24.10.2014 gibt es für den HM-CC-RT-DN die neue Firmware Version 1.4. Diese kann von der eQ-3 Webseite heruntergeladen werden. Genauere Informationen gibt es unter [[HomeMatic Firmware Update]].

=== HM-CC-RT-DN spezifische Update Informationen ===
Durch gleichzeitiges Drücken der "Auto-/Manu"-Taste und der "Comfort-/Eco"-Taste am HM-CC-RT-DN während man die Batterien wieder einlegt wird der updatemodus gestartet. Während des Updates steht "FUP" im Display. Nach erfolgreichem Update erscheint "Ins" im Display und es muss eine erneute Adaptierfahrt durch drücken der Boost-Taste ausgelöst werden. Anschließend sollte der HM-CC-RT-DN wieder normal funktionieren. Die eingestellten Parameter und das Pairing mit FHEM gehen beim Update nicht verloren. Sollte das Update fehlschlagen, erscheint "Err" bzw. "CrC" im Display.

Normalerweise sollte dann durch erneutes starten der Prozedur am PC und HM-CC-RT-DN das ganze erneut durchführbar sein.

Es gibt einige Readings, die nicht durch ein einfaches ''getConfig'' aktualisisert werden, z.B. "battery"(nicht batteryLevel). Um diese Readings zu bekommen, ist ein
:<code>set Device_Channel04 controlMode auto </code>
notwendig. Daraufhin werden die Readings übertragen/aktualisiert.

== Simulation von Fensterkontakten und externen Temperatursensoren ==
grober Ablauf:
* erstellen ein virtuelles Device
* erstelle dazu einen virtuellen Kanal
* peeren den Kanal mit dem RT (als fenster-kontakt oder als remote, wen du willst)
* sende ein postEvent

=== Fensterkontakte ===
''Entnommen aus diesem {{Link2Forum|Topic=31078|Message=236245|LinkText=Forenbeitrag}}''
define virSC CUL_HM 221133
attr virSC autoReadReg 4_reqStatus
attr virSC expert 2_full
attr virSC model virtual_1
attr virSC peerIDs
attr virSC subType virtual
attr virSC webCmd press short:press long

define virtualKitchenDoor CUL_HM 22113301
attr virtualKitchenDoor dummy 1
attr virtualKitchenDoor expert 1
attr virtualKitchenDoor group Virtual
attr virtualKitchenDoor model virtual_1
attr virtualKitchenDoor webCmd postEvent open:postEvent closed

Anschließend peeren und Temperatur festlegen mit:
set virtualKitchenDoor peerChan 0 <Thermostat_Window_Rec> single set
set <Thermostat_Window_Rec> regSet winOpnTemp 5 virtualKitchenDoor

Die virtuelle Tür wird dann entsprechend über ein Notify getriggert:
define notify_virtualKitchenDoor notify (Fensterkontakt_1|Fensterkontakt_2) {if(Value("Fensterkontakt") eq "open" && Value("Fensterkontakt_2") eq "open"){fhem("set virtualKitchenDoor postEvent open")}else{fhem("set virtualKitchenDoor postEvent closed")}}

=== Temperatursensoren ===
''Entnommen aus diesem {{Link2Forum|Topic=19686|Message=233788|LinkText=Forenbeitrag}}''

1. Virtuelles HomeMatic Device mit _deiner_ HM Id definieren:
define wz_vT CUL_HM <hmId>

2. Dem Device einen virtuellen Kanal (Default ist ein virtueller Button) hinzufügen:
set wz_vT virtual 1

3. Es ist kein virtueller Button sondern ein virtueller Temperatursensor - darum rename:
rename wz_vT_Btn1 wz_vT_Sensor1

4. Virtuellen Peer Sensor mit dem Weather Channel des RT-DN peeren:
set wz_vT_Sensor1 peerChan 0 <RT_DN>_Weather single

5. Peering kontrollieren (Voraussetzung: Device ''hm'' vom Typ [[HomeMatic HMInfo|HMinfo]] existiert):
:<code>set hm peerXref</code>
Beispiel-Ausgabe:
peerXref done:
x-ref list
wz_Thermostat_Weather => wz_vT_Sensor1
wz_vT_Sensor1 => wz_Thermostat_Weather

6. Gemessene Temperatur vom z.B. 1-Wire DS1820 dem virtuellen HM Sensor übergeben. Z.B. alle zwei Minuten per at:
define at_wz_vT at +*00:02 { my $T=(ReadingsVal("<DS1820B>","temperature",20.0)); fhem "set wz_vT_Sensor1 virtTemp $T" }

Fertig.

== Bekannte Probleme ==
=== TempList: Bad format ... ===
Wenn Sie beim Setzen einer Temperaturliste nach dem o.a. Schema ("SetTempList...") die Meldung

Bad format, use HH:MM TEMP ......

erhalten, sollten Sie zunächst ein [[update]] von Fhem durchführen.

== Links ==
* [http://www.eq-3.de/produkt-detail-aktoren/items/homematic-funk-heizkoerperthermostat.html Produktinfo]
* [http://www.eq-3.de/Downloads/eq3/pdf_produkte/HM-CC-RT-DN_UM_GE_eQ-3_web.pdf Bedienungsanleitung (PDF)]
* [http://www.eq-3.de/Downloads/eq3/pdf_produkte/Funk-Heizkoerperthermostat_105155_Produktdatenblatt_V2.2.pdf Datenblatt (PDF)]
* [http://www.eq-3.de/Downloads/eq3/downloads/Ventilkompatibilitaeten.pdf Ventil-Kompatibilitätsliste (PDF)]
* {{Link2Forum|Topic=14738|LinkText=Forenthema zum Thermostat}}

[[Kategorie:HomeMatic Components]]
[[Kategorie:Heizungsventile]]

HomeMatic HMinfo Templates erstellen

2016-10-29T16:01:25Z

Stephan1965: /* Kurzerklärung Tempaltes */

Mit diesem kleine HowTo soll gezeigt werden wie ein eigenes Template für die Konfiguration von Aktoren (Type switch) mit Tastern (Type remote) erstellt werden kann.

Grundlegende Infos findet man hier: [[HomeMatic_HMInfo]]
== Kurzerklärung Templates==
Templates erleichtern den Umgang mit Register. Wie in HMinfo erläutert muss man den möglichen Umfang eines einzelnen Templates verstehen. Ein Template beinhaltet mindestens ein Register, typisch sicher mehrere. Maximal beschränkt sich ein einzelnes Template auf
* eine Entity (einen Kanal)
* 0-Template: alle Register die NICHT einem peer zugeordnet sind
* peer-Template: Register die einem Peer zugeordnet sind
** short/long-Template: Alle Regiser eines Peers für short ODER long. Beschrieben wird das short ODER long Verhalten
** both-Template: Alle Register eines Peers - beschrieben wird short UND long Verhalten

Wie feingranular man ein Tempalate erstellt ist Geschmackssache. Man kann einer Entity beliebig viele Templates zuweisen. Wenn sich Inhalte überschneiden kommt es zu Problemen, welche mit configCheck aufgedeckt werden.

== Erstellen eines Templates==
Ziel ist es die Funktion der Tasten zu ändern/tauschen.
Peert man das Tastenpaar 5/6 eines HM-PB-6-WM55 mit dem Channel 1 von einem HM-LC-SW2-FM mittels
set RC61_5 peerChan 0 SW01_Sw01 dual set both

ensteht der Ausgangzustand:
Taste 5 RC61_5 schaltet SW01_Sw01 aus.
Taste 6 RC61_6 schaltet SW01_Sw01 ein.

Die regTable dazu sieht so aus:
RC61_5 RC61_6
lg sh lg sh
ActionType jmpToTarget jmpToTarget jmpToTarget jmpToTarget
CtDlyOff geLo geLo geLo geLo
CtDlyOn geLo geLo geLo geLo
CtOff geLo geLo geLo geLo
CtOn geLo geLo geLo geLo
CtValHi 100 100 100 100
CtValLo 50 50 50 50
MultiExec on off on off
OffDly [s] 0 0 0 0
OffTime unused unused unused unused
OffTimeMode absolut absolut absolut absolut
OnDly [s] 0 0 0 0
OnTime unused unused unused unused
OnTimeMode absolut absolut absolut absolut
SwJtDlyOff off off on on
SwJtDlyOn off off on on
SwJtOff off off dlyOn dlyOn
SwJtOn dlyOff dlyOff on on

Damit der gewünschte Effekt ensteht sollen die Register wie folgt geändert werden, es werden nur die Register für sh geändert!

SwJtDlyOff off no on no
SwJtDlyOn off no on no
SwJtOff off on dlyOn no
SwJtOn dlyOff no on off

Jetzt werden zwei Templates definiert

set hminfo templateDef tmpl_SwOnOnly 0 "Template für nur an" ActionType:jmpToTarget SwJtDlyOff:no SwJtDlyOn:no SwJtOff:on SwJtOn:no
set hminfo templateDef tmpl_SwOffOnly 0 "Template für nur aus" ActionType:jmpToTarget SwJtDlyOff:no SwJtDlyOn:no SwJtOff:no SwJtOn:off

und entsprechend übertragen
set hm templateSet SW01_Sw01 tmpl_SwOnOnly RC61_5:short
set hm templateSet SW01_Sw01 tmpl_SwOffOnly RC61_6:short

Die Konfiguration kann auf unterschiedliche Art gesichert werden, z.B:
set hm saveConfig config.txt
schreibt alles (Die gesamte Konfiguration die hmInfo aus FHEM ermitteln kann - also nicht aus den Geräten selbst) in eine Datei /opt/fhem/config.txt.

Aus der Datei können im Bedarfsfall einzelne Befehle zum Setzen der Register herausgezogen werden.

Weiter Möglichkeiten bietet das Modul mit archConfig
== Templates Repository==
Hier werden einige Templates angeboten, welche im System integriert werden könne
=== Generelle Einstellungen ===
define hm HMinfo
attr hm autoArchive 1
attr hm autoLoadArchive 1_load
attr hm autoUpdate 0:3
attr hm configFilename regConfig.cfg
=== switch Templates ===
==== long-short ====
Templates zum Setzen der Condition-Table
set hm templateDef SwOnCond level:cond "switch: execute only if condition [geLo|ltLo] level is below limit" CtValLo:p0 CtOn:p1 CtOff:p1 CtDlyOn:p1 CtDlyOff:p1
set hm templateDef SwCondAbove condition "Switch: execute only if condition level is above limit" CtValLo:p0 CtOn:geLo CtOff:geLo CtDlyOn:geLo CtDlyOff:geLo
set hm templateDef SwCondBelow condition "Switch: execute only if condition level is below limit" CtValLo:p0 CtOn:ltLo CtOff:ltLo CtDlyOn:ltLo CtDlyOff:ltLo
set hm templateDef autoOff time "staircase - auto off after -time-, extend time with each trigger" SwJtDlyOn:no ActionType:jmpToTarget SwJtDlyOff:dlyOn OnTime:p0 OffTime:unused SwJtOn:on SwJtOff:dlyOn

Templates zur Definiton einer Aktion
set hm templateDef SwIgnore 0 "ignore event" ActionType:off
set hm templateDef SwOff 0 "Switch: off if trigger" SwJtDlyOn:dlyOff ActionType:jmpToTarget SwJtDlyOff:off OnTime:unused OffTime:unused SwJtOn:dlyOff SwJtOff:no
set hm templateDef SwOn 0 "Switch: on if trigger" SwJtDlyOn:on ActionType:jmpToTarget SwJtDlyOff:dlyOn OnTime:unused OffTime:unused SwJtOn:no SwJtOff:dlyOn
set hm templateDef SwToggle 0 "Switch: toggle on trigger" SwJtDlyOn:on ActionType:jmpToTarget SwJtDlyOff:off OnTime:unused OffTime:unused SwJtOn:dlyOff SwJtOff:dlyOn

Beispiel Nutzung: nutze den Trigger "short" des Peers "MeinPeer" wenn der Level größer als 30 ist. Als Aktion ist ein 2. Tempalte zum Einschalten aktiviert. Bei langen Trigger soll ausgeschaltet werden
set hm templateSet <MeinLicht> SwOnCond <MeinPeer:short> 30 gtLo
set hm templateSet <MeinLicht> SwOn <MeinPeer:short>
set hm templateSet <MeinLicht> SwOff <MeinPeer:long>

==== both ====
Both ist ein kompakterer Ansatz - man definiert das komplette Verhalten eines Peers, also short und long in einem.
set hm templateDef SwMdir onTime:minBright "switch action when peered motionDetector" shOnDly:0 shSwJtOn:no shOffDly:p0 lgActionType:off shCtDlyOff:ltHi shOffTimeMode:minimal shCtValLo:p1 lgMultiExec:off shOnTime:0 shCtValHi:255 shOffTime:unused shMultiExec:off shOnTimeMode:minimal shSwJtOff:dlyOff shSwJtDlyOff:dlyOff shCtOff:ltLo shActionType:jmpToTarget shCtOn:ltLo shSwJtDlyOn:no shCtDlyOn:ltLo
set hm templateDef SwSonLoff 0 "Switch: shortOn, long Off" lgSwJtOff:no lgOffTime:unused shOffTime:unused shSwJtOn:no lgSwJtOn:dlyOff lgActionType:jmpToTarget shSwJtOff:dlyOn shSwJtDlyOff:dlyOn shActionType:jmpToTarget lgSwJtDlyOff:off shSwJtDlyOn:on lgSwJtDlyOn:dlyOff lgOnTime:unused shOnTime:unused
set hm templateDef SwSoffLignore 0 "Switch: shortOff, long Ignore" shOffTime:unused shSwJtOn:dlyOff lgActionType:off shSwJtDlyOff:off shSwJtOff:no shActionType:jmpToTarget shSwJtDlyOn:dlyOff shOnTime:unused

Beispiel: Konfiguration eines Aussenlichts mit Motion-Detector. Erzielt werden soll das Einschalten bei Dunkelheit (brght kleiner 70) für 30sec. Per Tastendruck soll das Licht eingeschaltet werden und endloc anbleiben (Ausschalten nicht vergessen). Alternativ einschalten für einige Stunden - das sollte auch reichen - und es geht irgendwann doch aus. Im Beispiel für Button2 4 Stunden.
set hm templateSet <MeinLicht> SwMdir <MotionPeer:both> 30 70
set hm templateSet <MeinLicht> SwSonLoff <ButtonPeer:both>
set hm templateSet <MeinLicht> autoOff <Button2Peer:short> 14400

=== Dimmer Templates ===
==== long-short ====
set hm templateDef DimDown rampTime "ramp down to 0, ramp valiable" DimJtRampOff:off OnTime:unused DimJtOn:dlyOff OffTime:unused OffDlyStep:5 DimJtOff:rampOff OffTimeMode:absolut OffDlyBlink:on OnDlyMode:setToOff DimJtRampOn:dlyOff OffDlyOldTime:0.4 RampOnTime:p0 DimMaxLvl:100 OnTimeMode:absolut RampSstep:5 OnLvlPrio:high DimMinLvl:0 DimStep:5 DimJtDlyOff:rampOff OffLevel:0 OnMinLevel:10 ActionTypeDim:jmpToTarget OnDly:0 OffDly:0 OffDlyNewTime:0.4 RampOffTime:p0 OnLevel:100 DimJtDlyOn:dlyOff
set hm templateDef DimOff 0 "Dimmer: off if trigger" DimJtDlyOff:off DimJtRampOff:dlyOff DimJtOn:dlyOff OnTime:unused ActionTypeDim:jmpToTarget DimJtOff:no OffTime:unused DimJtRampOn:dlyOff DimJtDlyOn:dlyOff
set hm templateDef DimOn 0 "Dimmer: on if trigger" DimJtDlyOff:dlyOn DimJtRampOff:dlyOn DimJtOn:no OnTime:unused ActionTypeDim:jmpToTarget DimJtOff:dlyOn OffTime:unused DimJtRampOn:dlyOn DimJtDlyOn:on
set hm templateDef DimUp onLevel:rampTime:onTime "ramp up soft" DimJtRampOff:dlyOn OnTime:p2 DimJtOn:rampOn OffTime:unused OffDlyStep:5 DimJtOff:dlyOn OffTimeMode:absolut OffDlyBlink:on OnDlyMode:setToOff DimJtRampOn:on OffDlyOldTime:0.4 RampOnTime:p1 DimMaxLvl:p0 OnTimeMode:absolut RampSstep:5 OnLvlPrio:high DimMinLvl:0 DimStep:5 DimJtDlyOff:dlyOn OffLevel:0 OnMinLevel:10 ActionTypeDim:jmpToTarget OnDly:0 OffDly:0 OffDlyNewTime:0.4 RampOffTime:p1 OnLevel:p0 DimJtDlyOn:rampOn

==== both ====

=== Blind (Rollo) Templates ===

==== devicelevel ====
set hm templateDef BlSetDrive up:down:turn "drive times up, down and turn plus gen defaults" statusInfoRandom:0 localResDis:off refRunCounter:0 statusInfoMinDly:3 driveUp:p0 driveDown:p1 transmitTryMax:6 driveTurn:p2 intKeyVisib:visib confBtnTime:permanent sign:off
set hm templateSet Blind BlSetDrive 100 105 0.5 # Setze Fahrzeiten auf 100s, runter 105s, turn 0.5s

==== long-short ====
set hm templateDef BlStopDnLg 0 "Blind: stop drive on any key - for long drive down" BlJtOn:dlyOff BlJtDlyOff:refOff BlJtDlyOn:dlyOff ActionType:jmpToTarget BlJtOff:dlyOff BlJtRampOff:rampOff BlJtRampOn:on BlJtRefOn:on BlJtRefOff:rampOff
set hm templateDef BlStopDnSh 0 "Blind: stop drive on any key - for short drive down" BlJtOn:dlyOff BlJtDlyOff:refOff BlJtDlyOn:dlyOff ActionType:jmpToTarget BlJtOff:dlyOff BlJtRampOff:off BlJtRampOn:on BlJtRefOn:on BlJtRefOff:rampOff
set hm templateDef BlStopUpLg 0 "Blind: stop drive on any key - for long drive up" BlJtOn:dlyOn BlJtDlyOff:dlyOn BlJtDlyOn:refOn ActionType:jmpToTarget BlJtOff:dlyOn BlJtRampOff:off BlJtRampOn:rampOn BlJtRefOn:rampOn BlJtRefOff:off
set hm templateDef BlStopUpSh 0 "Blind: stop drive on" BlJtOn:dlyOn BlJtDlyOff:dlyOn BlJtDlyOn:refOn ActionType:jmpToTarget BlJtOff:dlyOn BlJtRampOff:off BlJtRampOn:on BlJtRefOn:rampOn BlJtRefOff:off
set hm templateDef BlToggle 0 "toggle mein Rollo" BlJtDlyOff:no BlJtOn:dlyOff ActionType:jmpToTarget BlJtDlyOn:no BlJtOff:dlyOn BlJtRampOff:dlyOn BlJtRampOn:dlyOff BlJtRefOn:dlyOff BlJtRefOff:dlyOn

==== both ====
set hm templateDef BlSmartStopDn 0 "from Master BlSmartStopDn > FB_09:both" shBlJtOff:dlyOff lgCtDlyOff:geLo lgDriveMode:direct lgOffLevel:0 lgActionType:jmpToTarget shBlJtDlyOn:dlyOff shOffLevel:0 lgCtValLo:50 lgCtRefOn:geLo lgBlJtOff:dlyOff shCtDlyOff:geLo shOffTimeMode:absolut lgOnLevel:100 lgBlJtDlyOn:dlyOff lgBlJtDlyOff:refOff shBlJtDlyOff:refOff lgMultiExec:on lgOffDly:0 lgBlJtRefOff:rampOff shCtValHi:100 lgMaxTimeF:0.5 shBlJtRefOn:on lgCtValHi:100 shBlJtRampOff:off shCtRefOff:geLo shCtRampOn:geLo shMaxTimeF:unused shOnTimeMode:absolut shBlJtRefOff:rampOff lgOnTime:unused lgCtRefOff:geLo lgOnTimeMode:absolut lgCtRampOff:geLo shOnDly:0 lgCtRampOn:geLo lgOffTime:unused lgBlJtRefOn:on shOffDly:0 shCtRefOn:geLo lgCtOff:geLo lgCtOn:geLo shCtValLo:50 lgBlJtOn:dlyOff lgOnDly:0 lgOffTimeMode:absolut shBlJtRampOn:on shBlJtOn:dlyOff shOnTime:unused shDriveMode:direct shOffTime:unused lgCtDlyOn:geLo shOnLevel:100 lgBlJtRampOn:on shCtRampOff:geLo shMultiExec:off shCtOff:geLo shActionType:jmpToTarget shCtOn:geLo shCtDlyOn:geLo lgBlJtRampOff:rampOff
set hm templateDef BlSmartStopUp 0 "from Master BlSmartStopUp > FB_10:both" shBlJtOff:dlyOn lgCtDlyOff:geLo lgDriveMode:direct lgOffLevel:0 lgActionType:jmpToTarget shBlJtDlyOn:refOn shOffLevel:0 lgCtValLo:50 lgCtRefOn:geLo lgBlJtOff:dlyOn shCtDlyOff:geLo lgOnLevel:100 shOffTimeMode:absolut lgBlJtDlyOff:dlyOn lgBlJtDlyOn:refOn shBlJtDlyOff:dlyOn lgMultiExec:on lgOffDly:0 lgBlJtRefOff:off shCtValHi:100 lgMaxTimeF:0.5 shBlJtRefOn:rampOn lgCtValHi:100 shCtRefOff:geLo shCtRampOn:geLo shBlJtRampOff:off shMaxTimeF:unused shBlJtRefOff:off shOnTimeMode:absolut lgCtRefOff:geLo lgOnTime:unused lgOnTimeMode:absolut lgCtRampOff:geLo lgCtRampOn:geLo shOnDly:0 lgOffTime:unused lgBlJtRefOn:rampOn shOffDly:0 shCtRefOn:geLo lgCtOff:geLo lgCtOn:geLo shCtValLo:50 lgBlJtOn:dlyOn lgOnDly:0 lgOffTimeMode:absolut shBlJtRampOn:on shBlJtOn:dlyOn shOnTime:unused shDriveMode:direct shOffTime:unused lgCtDlyOn:geLo shOnLevel:100 lgBlJtRampOn:rampOn shCtRampOff:geLo shMultiExec:off shCtOff:geLo shActionType:jmpToTarget shCtOn:geLo shCtDlyOn:geLo lgBlJtRampOff:off

=== Heizung RT Templates ===
Man muss hier die einzelnen Kanäle unterscheiden. Da sich die Register unterscheiden sind für jeden Kanal eigenen Templates erstellt werden.
Achtung: Die Templates sind in diesem Fall Beispiele. Evtl sind andere Einstellungen gewünscht.
==== RT-device ====
Selektierbat ist, ob Buttonlock ein oder ausgeschaltet sein soll.Mit Beispielnutzung
set hm templateDef HeatDefDev BtnLock "Default RT Device register" globalBtnLock:off modusBtnLock:off localResDis:off cyclicInfoMsg:on backOnTime:10 lowBatLimitRT:2.1 burstRx:on cyclicInfoMsgDis:0 btnLock:p0

set hm templateSet rtDevice HeatDefDev 0 on # buttonLock ist eingeschaltet

Eine Alternative - wenn man auch den Batterielevel selektiv einstellen will. Da es bei allem meinen RTs identisch ist stelle ich es im Define ein, nicht im Set. Aber dennoch hier das Beispiel
set hm templateDef HeatDefDev BtnLock:BatLevel "Default RT Device register" globalBtnLock:off modusBtnLock:off localResDis:off cyclicInfoMsg:on backOnTime:10 lowBatLimitRT:p1 burstRx:on cyclicInfoMsgDis:0 btnLock:p0

set hm templateSet rtDevice HeatDefDev 0 2.3 on # buttonLock ist eingeschaltet, BatMinLevel ist 2.3V

==== RT-Clima====
set hm templateDef HeatDefault boost "myDefault RT settings, enter boostTime" reguIntI:20 regAdaptive:offDeter nightTemp:17 tempOffset:0.0K dayTemp:21 reguIntPstart:5 reguExtI:20 reguIntP:25 reguExtP:25 showWeekday:off tempMin:4.5 tempMax:30.5 valveMaxPos:15 valveOffsetRt:0 modePrioManu:all daylightSaveTime:on boostPos:30 showInfo:time decalcWeekday:Sat btnNoBckLight:off decalcTime:11:00 noMinMax4Manu:off reguExtPstart:5 valveErrPos:15 modePrioParty:all boostPeriod:p0
set hm templateSet RT1_Clima HeatDefault 20 on # Clima-defaults - Boost fpr RT1 ist auf 20 min eingestellt
set hm templateSet RT2_Clima HeatDefault 5 on # Clima-defaults - Boost fpr RT1 ist auf 5 min eingestellt

==== RT-Remote====
Um mit einem Button "gute Nacht" zu sagen und alle Lichter auszuschalten kann man den Button auch mit den RTs koppeln und auf Nachttemp zu schalten. Man muss hier - wie beim Switch - long/short und both unterschieden. Im Beispiel ist ein long/short template genutzt.
set hm templateDef HeatRemote temp "heatRemote set temperature CtrlRc:autoAndTemp" TempRC:p0

set hm templateSet RT1_Remote HeatRemote <Button1:long> 18 # schalte bei trigger long auf 18 Grad(Nacht)
set hm templateSet RT1_Remote HeatRemote <Button1:short> 23 # schalte bei trigger short auf 23 Grad(Tag)
set hm templateSet RT1_Remote HeatRemote <Button2:long> 15 # schalte bei trigger long auf 15 Grad
set hm templateSet RT1_Remote HeatRemote <Button2:short> 28 # schalte bei trigger short auf 28 Grad

=== SmokeDetector SD2 ===
Entschieden, ob der Repeater eingeschaltet werden soll oder nicht.
set hm templateDef sd2Rep repeat "SD2 setup as repeater (1) or not (0)" devRepeatCntMax:p0

== Links ==
* Commandref: [http://fhem.de/commandref_DE.html#HMinfo]
* hmInfo Wiki: [[HomeMatic_HMInfo]]

[[Kategorie:HomeMatic Components]]
[[Kategorie:HOWTOS]]

Virtueller Controller VCCU

2016-10-29T14:51:08Z

Stephan1965: /* Mehrere VCCUs in einer Installation */

Eine '''Virtuelle CCU''', auch '''VCCU''' genannt, ist eine Zentrale für [[HomeMatic]]-Geräte. Die VCCU tritt beim [[Pairing (HomeMatic)|Pairing]] an die Stelle des ''I/O-Devices'' (auch "Schnittstelle" genannt, zum Beispiel [[CUL]] und [[HM-CFG-LAN]]).

HomeMatic-Geräte werden überlicherweise mit einer Zentrale gepaired, um sie zentral verwalten zu können. Der Pairing-Partner ist im einfachsten Fall das I/O-Device ([[CUL]], [[HM-CFG-LAN]], …) selbst. Nachteilig dabei ist, dass der Ausfall der Schnittstelle bewirkt, dass alle gepairten Geräte nicht mehr bedient werden können. Dies lässt sich im Gegensatz zu ungepairten Protokollen (z.b. FS20) auch nicht durch doppelte Definition mit abweichenden IO-Devices lösen, da das Pairing nur mit einer ''hmId'' erfolgen kann. Daher kann auch durch mehrere Schnittstellen / IOs keine Redundanz erreicht werden. Ähnliches gilt für eine Vergrösserung der Funkabdeckung durch mehrere Schnittstellen.

Dieses Problem kann durch eine VCCU gelöst werden. Die VCCU ist eine virtuelle Zentrale; sie tritt beim Pairing an die Stelle der Schnittstelle. Sie erhält eine eigene ''hmId'', mit der die HM Sensoren und Geräte gepaired werden. Die Funkschnittstelle(n) werden dann von der VCCU als reine "dumme" IOs verwaltet. Dieses bietet vielfältige Möglichkeiten, z.b. die Verwendung mehrerer IOs, aus denen die VCCU die "beste" nach diversen Kriterien (z.B. RSSI) auswählt. Dadurch kann sowohl die Redundanz als auch die Funkabdeckung erhöht werden.

Durch das Pairen der Geräte mit einer virtuellen CCU ergeben sich folgende Vorteile:

* Die Verwendung mehrerer I/O-Devices wird möglich. Das sorgt für Redundanz (Ausfallsicherheit) und/oder Reichweiten-Vergrößerung.
* Der Tausch eines I/O-Devices ist transparent für gepairte Geräte.
* Die VCCU stellt virtuelle Kanäle zur Verfügung, mit denen HomeMatic-Geräte [[Homematic Peering Beispiele|gepeert]] werden können.
* "Geordnete" Termination von Nachrichten. (Da die üblichen Funkschnittstellen (wie CUL im HM-Mode oder HM-LAN-Konfigurator) relativ "dumm" sind, führen viele Zustände zu den bekannten "Help me" Einträge im Log.)

Der einzige Nachteil einer VCCU gegenüber dem direkten Pairing mit dem I/O-Device ist ein Mehraufwand bei der initialen Konfiguration vom Fhem.

== Kurzbeschreibung ==

Ein virtueller Controller '''VCCU''' ist der Protokoll-Endpunkt der Zentrale und ersetzt dabei logisch (jedoch nicht physikalisch) z.b. den [[HM-CFG-LAN LAN Konfigurations-Adapter]] einer "klassichen" FHEM Konfiguration

Es können einer VCCU einzelne oder mehrere IO Devices zugeordnet werden. Man bündelt dadurch mehrere I/O Devices (z.B. CULs und HM-CFG-LANs) zu einem ''Pool''. Den HM-Devices in FHEM (Aktoren, Sensoren) kann dann als I/O Device die ''VCCU'' zugeordnet werden, dies geschieht durch das Attribut ''IOgrp.''

Durch diese Gruppierung der I/O Devices und dem Zuordnen der VCCU zu einem Device entstehen verschieden Vorteile, abhängig des Einsatzes der VCCU. So kann ein beliebiges I/O Device im Device Pool der VCCU ausfallen und das oder die verbliebenden I/O Devices übernehmen diese Funktion (abhängig von der Funkreichweite/Erreichbarkeit). Die VCCU wird das nächst verfügbare I/O Device zum Senden/Empfangen verwenden.

Ein weitere Vorteil ist, dass durch die VCCU auch das I/O Device genutzt werden kann, welches die beste Funkqualität aufweist. Dies kann z.B. bei beweglichen Sensoren/Aktoren (Fernbedienungen) sinnvoll sein, oder wenn die Funkqualität durch andere Faktoren beeinflusst wird (z.B. Tür/Tor oder andere "bewegliche" Störfaktoren)

== Mehrere VCCUs in einer Installation==

Theoretisch erlaubt Fhem die parallele Nutzung mehrer VCCUs, praktisch ergeben sich dadurch jedoch keine Vorteile gegenüber einer einzigen VCCU. Insbesondere kann eine VCCU verschiedene I/O-Devices bedienen, zum Beispiel einen [[CUL]] ''und'' ein [[HM-CFG-LAN]].

Jede VCCUs muss eine eindeutige ''HomeMatic-ID'' haben, mit der HomeMatic-Geräte gepaired werden. Folglich kann jedes HomeMatic-Gerät nur mit ''einer'' VCCU gepaired werden.

Die VCCU überschreibt die hmid eines I/O Device mit seiner eignen, daher können nicht mehrere VCCUs das selbe I/O Device verwenden.

== Definition der VCCU==
=== hmId wählen ===
Eine VCCU benötigt wie alle HM Devices eine Adresse, mit der sie angesprochen wird. Bei Schnittstellen und Zentralen ist dies eine ''hmId''. Da die VCCU eine (virtuelle) Zentrale ist, muss sie auch mit einer ''hmId'' versehen werden. Dies geschieht per define analog zur Anlage einer physischen Schnittstelle (siehe weiter unten)

Eine VCCU gibt die ''hmId'' an die ihr zugewiesenen IOs (Funkschnittstellen) weiter. D.H. alle von einer VCCU genutzen I/Os haben nach der Zuweisung die selbe ''hmId''.

Definiert man eine VCCU nachdem I/Os (CUL oder HMLAN) für Homematic angelegt sind, sollte die ''hmId'' der bereits vorhandene Funkschnittstelle verwenden, hierdurch kann man sich das Neupairen der HM Devices ersparen. Hat man bereits mehre Funkschnittstellen im Einsatz, werde diese unterschiedliche ''hmId''s haben, zumindest eine Schnittstelle wird nach der Zuweisung zur VCCU seine ''hmId'' also ändern. Für mit dieser Schnittstelle schon gepairte Devices ist ein Neupairen unumgänglich.

Ausserdem muss in jedem Fall das attr IOgrp eines vor Anlage der VCCU gepairten Gerätes auf die VCCU angelegt/geändert werden., z.B. so
attr <device> IOgrp VCCU
(Siehe weiter unten ein Tipp, wie dies leicht nachträglich erledigt werden kann)

Mit der Anlage einer VCCU hat das eventuell angelegte attribut IODev eines HM_Devices keine Funktion mehr. Vielmehr setzt die VCCU das IODev automatisch je nach Verfügbarkeit und Funklage. Es ist jedoch nicht erforderlich angelegte IODev Attribute zu entfernen.

=== Einrichten ===
define VCCU CUL_HM <hmId>
attr VCCU model CCU-FHEM
attr VCCU IOList <io1>[,<io2>,...]

Das Attribut IOList dient dazu festzulegen, welche physikalischen Schnittstellen ("IO") von der VCCU genutzt werden, dies sind in der Regel alle HM-fähigen Schnittstellen einer Installtion.
IOList beinhaltet die Komma-getrennte Liste der IOs, so wie sie in FHEM angelegt sind.

Es seien z.b. in FHEM bereits die beiden Schnittstellen HMLAN und CULHM angelegt:

define HMLAN0 HMLAN 192.168.168.2:1000
attr HMLAN0 hmId 123456
attr HMLAN0 hmLanQlen 1_min
attr HMLAN0 icon hm_lan

define CUL0 CUL /dev/ttyACM0@9600 0000
attr CUL0 hmId 123456
attr CUL0 icon cul_cul
attr CUL0 rfmode HomeMatic

Dann kann zusätzlich die VCCU mit der selben hmId angelgt werden und die beiden physikalischen Schnittstellen ihr zugewiesen:

define VCCU CUL_HM 123456
attr VCCU IOList CUL0,HMLAN0
attr VCCU model CCU-FHEM
attr VCCU subType virtual
attr VCCU webCmd virtual:update

Wird die VCCU mit einer von vorhandene Schnittstellen abweichenden ''hmId'' angelegt, so wird die ''hmId'' der ihr zugewiesenen Schnittstelle(n) automatische angepasst. Dies hat in der Regel zur Folge, das HM Devices neu gepairt werden müssen.

Dies trifft auch zu, wenn bereits vorhandene Schnittstellen unterschiedliche hmIDs haben, dann wird sich die hmID mindestens einer Schnittstelle ändern. (Der Einfachheit halber war im obigen Beispiel angenommen, dass auch vorher die beiden Schnittstellen bereits die gleiche ID hatten.)

=== Auswirkungen auf IOs / Funkschnittstellen===
Sind IOs durch das Attribut IOList einer VCCU zugewiesen, werden die notwendigen Attribute im IO gesetzt, so wird die hmId durch die VCCU kontrolliert. Ein HMLAN/USB ist etwas enger verbunden als CUL IOs. Beim HMLAN kann die HMId nicht mehr geändert werden. Die kontrollierende VCCU wird in den Internals ''owner'' und ''owner_CCU'' des IO automatisch eingetragen. 

=== Pairen von HM Devices===
HM Devices sollten vorzugsweise direkt mit der VCCU gepairt werden, hierzu werden die normalen Befehle
hmPairForSec
hmPairSerial
verwendet. Es ist im übrigen weiter möglich (aber nicht sinnvoll / empfehlenswert) auch nach Anlage einer VCCU HM Devices mit diesen Kommandos direkt an ein IO zu pairen, d.h. diese Kommandos haben auch nach Anlage einer VCCU noch eine Funktion an der physikalischen Schnittstelle (im Gegensatz z.b. zum attr IODev)

== Dynamisches IO ==
FHEM sendet Befehle an an ein HM Device in der Regel immer über das gleiche IO-Device. Fällt es aus, wird nicht mehr gesendet, selbst wenn ein zweites IO verfügbar wäre. Ausserdem gibt es ''bewegliche'' Fernbedienungen welche ihre Verbindung zu einem IO verlieren, aber über ein andere IO gut empfangen werden könnten.

Die VCCU adressiert beide Probleme:

Durch das Attibut IOgrp
attr <dev> IOgrp <vccu>:<preferredIO>
kann bestimmt werden, wie die VCCU die IO Devices genau nutzt. Insbesondere ist optional ein Preferd IO Device definierbar: bei stationären Devices - der häufigste Fall - sollte man das beste IO auswählen und als Default nutzen. Ein weiteres IO wird bei Ausfall des Ersten genutzt.

Das preferredIO ist jedoch optional und kann insbesondere bei beweglichen HM Devices (Fernbedienungen) weggelassen werden.

Es können auch mehrere preferredIO definiert werden, diese werden in der definierten Reihenfolge genutzt
attr <dev> IOgrp <vccu>:<prefIO1>,<prefIO2>,<prefIO3>

Beispiele:

Durch
attr <device> IOgrp VCCU:HMLAN1
wird die VCCU zuerst versuchen Befehle an <device> mit HMLAN1 zu senden, falls seine condition=ok.
Falls nicht wird (einer) der verbleibende(n) IOs verwendet, hier der mit dem besten RSSI.

Durch
attr <device> IOgrp VCCU
wird durch die VCCU der IO mit dem besten RSSI zum Device gewählt, falls seine condition=ok ist.

Da dies für jedes angelegte HM Device einzeln definiert werden kann/muss, kann so auch eine Verteilung des Funkverkehrs vorgenommen werden, z.b. um die 1%-Regel (HighLoad) zu berücksichtigen, dennoch bleibt die Redunanz bei Ausfall einer Schnittstelle erhalten.

=== Bemerkungen ===
Es wird empfohlen, das Attribut IOgrp in allen Devices zu setzen. Kanäle senden nicht selbständig, haben daher kein Attribut IOgrp. 
Das Attribut '''IODev''' wird automatisch gesetzt, Usereinträge haben keine Funktion. Es zeigt jedoch indirekt das letzte genutzte output-device. 
Die besprochene Steuerung betrifft das '''Senden'''. Empfangen und verarbeitet werden Nachrichten immer von allen verfügbaren Quellen.

=== Setzen der IOgrp auf (fast) allen Devices mit einem einzigen Befehl ===
Hat man eine bestehende Fhem-Installation mit mehreren/vielen Devices, kann das Setzen der ''IOgrp'' aufwändig sein.
Relativ einfach geht es bei allen HM Geräten durch Filtern der sechstelligen DEF (HMID):

attr TYPE=CUL_HM:FILTER=DEF=...... IOgrp VCCU

Den obigen Befehl in der Fhem-Eingabezeile eingeben und mit <Return> bestätigen.
VCCU steht für den Namen der VCUU und ist entsprechend zu ersetzen.
Durch die 6 Punkte werden nur die Geräte erfasst, die Kanäle haben 8 stellige IDs und bleiben unberührt.

Anschließend nicht vergessen die Konfiguration mit save zu speichern.

== Virtuelle Kanäle der VCCU==
: ''→ Siehe auch: [[HomeMatic#IO_Entities]]''

Eine VCCU kann bis zu 50 virtuelle Kanäle, sogenannte '''IO-Entities''', bedienen. Diese können als Sender/Sensoren oder Empfänger genutzt werden. Man kann diese Kanäle mit einem realen Kanal peeren und Aktionen triggern.

Man peert beispielsweise einen Dimmer mit einer IO-Entity um "Tastendrücke" in der Zentrale auslösen zu können. Sowohl kurze (short) als auch lange (long) Tastendrücke können so an den Dimmer gesendet werden.
Auch mehrere Aktoren können mit einer IO-Entity gepeert werden, beispielsweise um alle Lichter der Gruppe mit einem "press" gleichzeitig zu schalten.

=== Anlegen ===
set VCCU virtual <AnzahlButton>
z.B.
set VCCU virtual 10
legt 10 Kanäle für die VCCU an, die Kanäle 1-10. Evtl. vorhandene Kanäle größer 10 werden gelöscht.

=== Kommandos ===
: ''→ Siehe auch: [http://fhem.de/commandref.html#CUL_HMvirtual CommandRef]''

Verfügbare Kommandos auflisten:

get vccu_Btn1 cmdList

Insbesondere gibt es:

set vccu_Btn1 press short
set vccu_Btn1 press long
set vccu_Btn1 postEvent <condition>

[[Kategorie:HomeMatic Components]]
[[Kategorie:HOWTOS]]

Erste Schritte in FHEM

2016-06-30T15:48:49Z

Stephan1965: Es sollte myLampe2 in myStehlampe umbenannt werden. War aber im Befehl myLampe1 und dass passt nicht zum Notify.

Für alle, die das erste mal mit fhem arbeiten, hier ein kleiner Kurs zum Einstieg.
Dieser ist so aufgebaut, dass man noch keine Hardware benötigt und nach dem Installieren der fhem-Software sofort loslegen kann.

Diese Anleitung wurde ursprünglich von Ulrich Maass publiziert, der die Genehmigung erteilt hat, sie auch im Wiki zu veröffentlichen.

Anmerkung zur Bearbeitung: Korrekturen von Tippfehlern kann jeder machen. Redaktionelle Änderungen und Erweiterungen aber bitte mit dem Autor (z.B. auf der zugehörigen Diskussionsseite) abstimmen.

==Der erste Einstieg==
Um fhem zum ersten Mal aufzurufen, geben Sie im Browser ein:
<nowiki>http://<ip-Adresse>:8083</nowiki>
also z.B. <nowiki>http://192.168.1.1:8083</nowiki>.
Sie gelangen auf den Startbildschirm:

[[Datei:ErsteSchritteInFhem01.png]]

*Am oberen Bildschirmrand sehen Sie das weiße ''Kommandofeld'', in das Sie Befehle tippen können.
*Als ersten Menüpunkt sehen Sie die Schaltfläche ''Save config'', mit der Änderungen so gespeichert werden, dass sie auch nach einem Neustart noch vorhanden sind.
*Außerdem gibt es bereits die Räume ''Unsorted'' und ''Everything'', die wir bald kennenlernen.
*Im unteren Block befinden sich weitere Links, auf die wir später ebenfalls eingehen.

Der Hinweis ''Security Check'' besagt, dass Sie noch kein Passwort für fhem eingerichtet haben. Wie man einen Passwortschutz einrichten kann, steht in der fhem-Befehlsreferenz [http://fhem.de/commandref_DE.html commandref], in der es übrigens eine Beschreibung zu allen Funktionen und Modulen von fhem gibt. Um diese Meldung erst einmal zu unterdrücken, geben Sie in das Kommandofeld ein:
attr global motd none
und bestätigen Ihre Eingabe mit der {{Taste|Enter}}-Taste.

[[Datei:ErsteSchritteInFhem02.png]]

==Device anlegen - define==

Um fhem kennenzulernen, legen wir erst einmal einige "Dummy"-Devices an. So können Sie diese Tests auch ohne ein Hardware-System durchführen bzw. kann hier eine allgemeine Einführung erfolgen, ohne auf die Unterschiede der einzelnen Hardwaresysteme einzugehen. Ein Dummy-Device sieht auf der fhem-Oberfläche im Allgemeinen genau so aus, wie ein fhem-Device zu einem "echten" Gerät Ihres Hardwaresystems.

Zunächst legen wir einen Schalter an. Dieser soll einen Lichtschalter an der Wand simulieren. Geben Sie dazu folgenden Befehl in das Kommandofeld ein:
define mySchalter1 dummy
Nach drücken der {{Taste|Enter}}-Taste wird die Detail-Ansicht des neuen fhem-Device ''mySchalter1'' angezeigt.

[[Datei:ErsteSchritteInFhem03.png]]

{{Hinweis|Der Block '''''Internals''''' zeigt immer die grundlegende Ausprägung eines fhem-device an:
*'''''NAME''''' ist der von Ihnen vergebene Name.
*'''''TYPE''''' ist der Typ des fhem-device, hier dummy.
*'''''STATE''''' ist der in allen Übersichten angezeigte Status des Geräts. Da noch keine Zuordnung stattgefunden hat, ist dieser zunächst '''''???'''''.}}

==Räume definieren==
In Räumen können Sie Geräte gruppieren, die sich auch physisch in einem Raum (Wohnzimmer, Schlafzimmer, etc.) befinden.

Um ein Device einem Raum zuzuordnen (der Raum muss zu diesem Zeitpunkt noch nicht existieren), verwenden Sie folgenden Befehl:
attr mySchalter1 room Schulungsraum

Nach Eingabe dieses Befehls in das Kommandofeld und Abschließen der Eingabe mit {{Taste|Enter}} ist das Device dem Raum ''Schulungsraum'' zugeordnet. Durch diese Zuordnung ist dieser Raum in der Navigationsleiste links zur Liste der Räume hinzugefügt worden.

Klicken Sie einmal auf den Raum ''Schulungsraum''.

[[Datei:ErsteSchritteInFhem04.png]]

Es werden nun alle Geräte angezeigt, die diesem Raum zugeordnet wurden. Bisher haben wir hier nur ein Gerät: ''mySchalter1''. Es wird in einem Block mit der Typbezeichnung ''dummy'' dargestellt.
Neben dem Device-Namen wird immer der Status des Device angezeigt, hier noch ''???''.
Wenn Sie auf den Namen ''mySchalter1'' klicken, gelangen Sie wieder in dessen Detailansicht.

==Schaltbefehle definieren==
Nun soll unser ''mySchalter1'' Schalterflächen für ''on'' und ''off'' bekommen.
attr mySchalter1 webCmd on:off

Statt den o.g. Befehl in das Kommandofeld einzugeben, können Sie auch im unteren Bereich der Detailansicht das gewünschte Attribut (hier: '''''webCmd''''') auswählen und in dem Textfeld rechts daneben die gewünschten Werte eintragen, hier '''''on:off'''''. Schließen Sie Ihre Eingabe durch Klick auf den Button {{Taste|attr}} ab.

[[Datei:ErsteSchritteInFhem05.png]]

{{Hinweis|'''''Attribute''''' können vom Anwender gesetzt und geändert werden. Sie beeinflussen das Erscheinungsbild und die Funktion eines bereits bestehenden fhem-device. Welche Attribute verfügbar sind, hängt vom device-TYPE ab.}}

Klicken Sie nun wieder links auf den ''Schulungsraum''.

Sie sehen, dass durch die Attribut-Angabe im vorhergehenden Schritt, nun in der Raumansicht die Schaltflächen für ''on'' und ''off'' hinzugekommen sind.

[[Datei:ErsteSchritteInFhem06.png]]

Klicken Sie versuchsweise auf ''on'' und ''off'': Statt der bisher angezeigten ''???'' erscheint nun ein Glühbirnensymbol, das den aktuellen Status darstellt.

Wenn Sie durch Klicken auf den Device-Namen ''mySchalter1'' wieder in die Detailansicht wechseln, sehen Sie, dass im Block ''Internals'' nun auch der aktuelle Zustand ''STATE'' angezeigt wird. Dieser wird in der Raumansicht als Icon (Glühbirne) dargestellt.

[[Datei:ErsteSchritteInFhem07.png]]

Auch sehen Sie im Detail-Bildschirm einen neuen Block ''Readings''.
{{Hinweis|'''''Readings''''' zeigen Informationen an, die - anders als Attribute - nicht direkt vom Anwender verändert werden können. Unter anderem werden hier Datum und Uhrzeit der letzten Zustandsänderung angezeigt. Welche Readings angezeigt werden, hängt vom device-TYPE ab.}}

Schalten Sie ''mySchalter1'' noch einmal aus und prüfen Sie, ob das Reading ''STATE'' incl. seines Zeitstempels aktualisiert wurde.

==Event Monitor==

Öffnen Sie nun in Ihrem Browser ein zusätzliches Fenster, in dem Sie ebenfalls fhem und darin den '''Event Monitor''' anzeigen. Am Schnellsten geht das, indem Sie mit der rechten Maustaste auf ''Event Monitor'' klicken und aus dem Kontextmenü des Browsers ''Öffnen in neuem Fenster'' auswählen. Legen Sie die Fenster so übereinander, dass Sie gleichzeitig den Event Monitor sehen und Ihren ''mySchalter1'' bedienen können. Unter Windows ab Version 7 geht das am Einfachsten, wenn Sie zuerst das eine Fenster aktivieren und {{Taste|Windows}}+{{Taste|Pfeil rechts}} drücken, anschließend das selbe mit dem anderen Fenster und {{Taste|Windows}}+{{Taste|Pfeil links}} wiederholen.

[[Datei:ErsteSchritteInFhem08.png]]

Bei jedem Schalten von ''mySchalter1'' wird in fhem ein Ereignis, englisch event, ausgelöst. Bei jeder Betätigung des Schalters erscheint ein neuer Event im ''Event Monitor''. Probieren Sie auch, was passiert, wenn Sie zweimal hintereinander auf ''on'' klicken.

Ein Event besteht immer aus dem Zeitstempel, gefolgt vom Typ des auslösenden Gerätes (hier ''dummy''), dem auslösenden Device-Namen (hier ''mySchalter1''), sowie dem ausgelösten Befehl (hier ''on'' oder ''off'').

Auch "echte" sendende fhem-Geräte, also z.B. eine Fernbedienung oder ein Funkschalter an der Wand, lösen bei jedem Tastendruck auf dieses Gerät oder bei Klick auf das zugehörige fhem-Device einen Event aus. Das Verständnis von Events und wie sie aufgebaut sind ist also elementar, wir werden sie noch oft benötigen. Probieren Sie ein wenig damit herum.

==Schalten von Geräten - set==
''mySchalter1'' kann also über Klicken auf ''on'' oder ''off'' geschaltet werden. Alternativ geht das auch über die Eingabe eines Befehls in das Kommandofeld.

Geben Sie dazu in das Kommandofeld <code>set mySchalter1 on</code> oder <code>set mySchalter1 off</code> ein und bestätigen jeweils mit der {{Taste|Enter}}-Taste. Auch hierbei ändert sich der Schaltzustand und ein Event wird ausgelöst. Den ''set''-Befehl werden wir ebenfalls noch häufig verwenden.

Für weitere Tests legen wir nun ein neues Device '''''myLampe1''''' an. Diese wollen wir später mit '''''mySchalter1''''' bedienen.
define myLampe1 dummy
Da dies eine Lampe, also einen Aktor darstellen soll, werden wir der Lampe selbst keine Buttons für ''on'' oder ''off'' geben.

Die Lampe soll im Schulungsraum stehen. Diese Zuordnung könnten Sie wie zuvor über die Kommandozeile erreichen. Diesmal sind wir aber tippfaul und möchten die Zuordnung durch Klicken vornehmen.

Da ''myLampe1'' noch keinem Raum zugeordnet ist, erscheint sie im Raum ''Unsorted''. Wechseln Sie in diesen Raum und klicken Sie auf den Namen von ''myLampe1'', um in die Detailansicht zu gelangen.

[[Datei:ErsteSchritteInFhem09.png]]

Im unteren Bereich können wir wieder die Attributzuordnung vornehmen.

Praktischerweise ist das Attribut ''room'' bereits ausgewählt, auch der Raum ''Schulungsraum'' ist bereits voreingestellt. Sie müssen also nur noch auf den Button {{Taste|attr}} klicken.

Wechseln Sie nun wieder in den Raum ''Schulungsraum''. Es werden beide Geräte angezeigt.

[[Datei:ErsteSchritteInFhem10.png]]

==Bei Event ausführen - notify==

Im nächsten Schritt werden wir fhem beibringen, auf einen Event von ''mySchalter1'' zu reagieren. Immer dann, wenn ''mySchalter1'' einen Event mit dem Befehl ''on'' auslöst, soll ''myLampe1'' eingeschaltet werden.
Dazu wird in fhem ein "notify" verwendet. Die Befehlsstruktur ist
define <NAME> notify <REGEXP> <command>

*Der Name '''<name>''' dient später dazu, dieses fhem-Device anzeigen und wiederfinden zu können. Als Name verwende ich hier ''n_mySchalter1_on'', also ''n_'' um es als Notify kenntlich zu machen, dann das auslösende Gerät ''mySchalter1'' und den auslösenden Event ''on''. Dieser Name scheint jetzt kompliziert, ist aber hilfreich, wenn Sie später mehrere Notify angelegt haben. Sie können es ganz nach Gusto auch ''n1'' nennen oder ''Karlheinz''. Device-Namen dürfen aus den Zeichen '''a-z''', '''A-Z''', '''0-9''', '''Unterstrich _''' und '''Punkt .''' bestehen, wobei ein Punkt nicht an erster Stelle stehen darf. Sie werden später sehen, dass der Punkt in perl und damit fhem eine besondere Bedeutung hat, wenn möglich sollten Sie daher auf seine Verwendung in Device-Namen verzichten.
*'''<regex>''' steht für "Regular Expression" und ist die Bedingung, unter der das Notify ausgeführt werden soll. Wann immer in fhem ein Event auftritt, wird für alle vorhandenen Notify geprüft, ob die angegebene Regex zutrifft. Der auslösende Event ist in unserem Fall, dass ''mySchalter1'' ein Event mit dem Befehl ''on'' erzeugt. Dafür wird für die Regular Expression die Schreibweise <code>mySchalter1:on</code> verwendet. Regular Expressions werden in perl und fhem häufig verwendet, Sie werden sich damit später detaillierter auseinandersetzen dürfen :)
*'''<command>''' definiert, was denn eigentlich ausgeführt werden soll. In unserem Beispiel soll das <code>set myLampe1 on</code> sein.

Unser Notify wird also erstellt mit
define n_mySchalter1_on notify mySchalter1:on set myLampe1 on

Nach Eingabe dieses Befehls in das Kommandofeld, abgeschlossen durch {{Taste|Enter}}, sehen Sie wieder die Detailansicht des neuen fhem-Device, also des Notify (siehe TYPE).

[[Datei:ErsteSchritteInFhem11.png]]

Im Block ''Internals'' sehen Sie hier die Definition '''DEF'''. Angezeigt wird hier alles, was bei der Definition nach dem Wort "notify", also nach dem Gerätetyp angegeben wurde. Es erscheinen also ''<regexp>'' und ''<command>''.
{{Hinweis|Im Block '''''Probably associated with''''' werden alle fhem-Devices angezeigt, die mit dem Notify verbunden sind. Die Geräte werden als klickbare Device-Namen angezeigt. Das ist praktisch, da man so mit einem Klick zur Detailansicht des jeweiligen Geräts springen kann.}}

Ordnen Sie auch das Notify unserem Schulungsraum zu (im unteren Bereich das Attribut ''room'' und den passenden Raum auswählen und dann auf ''attr'' klicken).

Wenn Sie nun im fhem-Menü auf ''Schulungsraum'' klicken, werden unsere drei fhem-Devices angezeigt.

[[Datei:ErsteSchritteInFhem12.png]]

{{Hinweis|Üblicherweise würde man das Notify keinem Raum zuordnen, da es später für den Benutzer gar nicht sichtbar sein soll. Für unsere Testdurchläufe ist es aber praktischer.}}

Wenn Sie nun ''mySchalter1'' auf ''on'' schalten, wird auch ''myLampe1'' auf ''on'' geschaltet. Das funktioniert scheinbar nur beim ersten Mal – wenn Sie aber den Event Monitor prüfen oder in der Detailansicht von ''myLampe1'' auf den Zeitstempel der letzten Statusänderung schauen, werden Sie sehen, dass es jedes Mal ausgeführt wird.

Damit das Ganze auch beim Ausschalten funktioniert, legen Sie ein zweites notify an:
define n_mySchalter1_off notify mySchalter1:off set myLampe1 off
Funktioniert es wie erwartet?

Natürlich möchte man nicht für jeden Befehl, den ein Device auslöst, ein eigenes Notify anlegen. Es geht auch einfacher.
Statt
define n_mySchalter1_on notify mySchalter1:on set myLampe1 on
define n_mySchalter1_off notify mySchalter1:off set myLampe1 off
definieren wir nun
define n_mySchalter1 notify mySchalter1 set myLampe1 '''$EVENT'''
Wir sehen, dass die Regex nun nicht mehr unterscheidet, ob ''mySchalter1'' den Event ''on'' oder ''off'' sendet. Lassen wir diese Angabe weg, löst dieses Notify bei jedem Event von ''mySchalter1'' aus, egal mit welchem Kommando. Im auszuführenden ''set''-Befehl verwenden wir nun die fhem-Variable '''$EVENT''' (Groß/Kleinschreibung beachten!). Dies ist ein Platzhalter für den Befehl, der vom auslösenden Event übernommen wird. Wenn also ''mySchalter1'' ein ''on'' auslöst, nimmt '''$EVENT''' den Wert ''on'' an. Entsprechend für ''off'' oder jeden anderen Befehl.

==Devices löschen oder deaktivieren – delete, disable==
Wenn Sie den Event Monitor beachten, werden Sie sehen, dass nach jeder Betätigung von ''mySchalter1'' der Befehl für ''myLampe1'' nun zweimal ausgeführt wird. Das liegt daran, dass auf jeden Event von ''mySchalter1'' zwei Notify reagieren – sowohl die "alten" Notify wie auch das Neue. Um dies zu umgehen, müssen wir die alten Notify loswerden. Dazu gibt es zwei Möglichkeiten.

#Löschen Sie ein Notify mit dem Befehl <code>delete <name></code>, z.B. mit <code>delete n_mySchalter1_on</code>. Der <code>delete</code> Befehl funktioniert übrigens für jedes Objekt in fhem. Sie können damit also auch "echte" Devices löschen.
#Deaktivieren Sie ein Notify, indem Sie das Attribut ''disable'' verwenden. Das können Sie wieder über die Detailansicht des Notify setzen (im unteren Bereich das Attribut ''disable'' und den Wert ''1'' auswählen, dann {{Taste|attr}} klicken), oder in der Kommandozeile <code>attr n_mySchalter1_off disable 1</code> eingeben.

==Save Config==

Wann immer Sie mit dem aktuellen Zustand Ihrer fhem-Konfiguration zufrieden sind, klicken Sie im fhem-Menü oben links einmal auf '''''Save config''''' oder geben Sie in das Kommandofeld den Befehl <code>save</code> ein. Ihre Konfiguration wird nun gespeichert. Tun Sie das nicht, sind alle Änderungen nach dem nächsten fhem-Neustart '''verloren'''.

==Bestehende Devices verändern – modify==

Wir legen nun eine zweite Lampe an, die ebenfalls durch unseren ''mySchalter1'' und unser Notify geschaltet werden soll.
Die neue Lampe wird durch folgende Eingabe in das Kommandofeld erzeugt:
define myLampe2 dummy

Durch "Zusammenklicken" im Detail-Bildschirm von ''myLampe2'' ordnen Sie diese ebenfalls dem Raum ''Schulungsraum'' zu und weisen ihr über das Attribut ''webCmd'' Schaltflächen für ''on'' und ''off'' zu.

[[Datei:ErsteSchritteInFhem13.png]]

Nun passen wir das Notify ''n_mySchalter1'' an. Dazu navigieren Sie auf den Detail-Bildschirm des Notify: Wechseln Sie in den Raum ''Schulungsraum'' und klicken Sie auf den Namen von ''n_mySchalter1''.

Im Detail-Bildschirm befindet sich die Zeile ''DEF'', die wir uns vorhin schon einmal angeschaut haben. Wenn Sie auf das Wort ''DEF'' klicken, können Sie die Definition eines fhem-Objekts bearbeiten.

{{Hinweis|Im Feld ''DEF'' wird nur der Teil der Definition angezeigt, der beim Anlegen dieses Notify nach dem Objekttyp, also ''notify'' folgt. Sie finden hier also zunächst die Regex auf die das Notify reagiert, dann nach einer Leerstelle den auszuführenden Befehl.
Der Lesbarkeit halber ist im Folgenden immer das gesamte define-Statement dargestellt, auch wenn man es im Feld ''DEF'' nicht vollständig sieht.}}

Wir ändern hier also von
define n_mySchalter1 notify mySchalter1 set myLampe1 $EVENT
zu
define n_mySchalter1 notify mySchalter1 set myLampe1,myLampe2 $EVENT

[[Datei:ErsteSchritteInFhem14.png]]

Zum Beenden der Bearbeitung klicken Sie auf die Schaltfläche '''''modify <name>''''', hier also {{Taste|modify n_mySchalter1}}. Wenn Sie die Angaben im Detail-Bildschirm prüfen, sehen Sie, dass die ''DEF''inition des Notify angepasst wurde.

[[Datei:ErsteSchritteInFhem14B.png]]

Beachten Sie auch hier wieder, dass im Detailscreen im unteren Bereich unter ''Probably associated with'' die geschalteten Lampen erscheinen – das wird noch oft nützlich sein.

{{Hinweis|Über den Link '''''Device specific help''''' können Sie sich übrigens den gesamten Hilfe-Text zu Ihrem device-Typ aus der commandref anschauen, hier also den Hilfetext zu ''notify''. Dieser Link ist gerade zu Beginn häufig hilfreich.}}

Nun können Sie testen, ob ein Klick auf ''mySchalter1'' auch wirklich beide Lampen schaltet. Schauen Sie sich dabei auch wieder in einem separaten Fenster mit dem Event Monitor die entstehenden Events an.

[[Datei:ErsteSchritteInFhem15.png]]

==Mehrere Devices schalten==

Zum Schalten mehrerer Devices kann also verwendet werden
set <device1>,<device2> on

Eine alternative Schreibweise dafür ist
set <device1> on; set <device2> on

Auch eine Kombination ist möglich:
set <device1>,<device2> on; set <device3> off

Auch innerhalb eines notify (oder anderen fhem-Befehlen) kann man mehrere Befehle auflisten, jedoch ist hier eines zu beachten:
define n1 notify mySchalter1:on set myLampe1 on;set myLampe2 off
Die Befehle sind durch ein Semikolon getrennt. Effekt ist: Das notify schaltet myLampe1 wann immer mySchalter1 den Event on sendet. Der nächste Befehl in dieser Zeile ist ''set myLampe2 off''. Dieser wird '''sofort''' bei der Eingabe der o.g. Befehlszeile abgearbeitet. Es schaltet also myLampe2 sofort, myLampe1 erst nach dem Event von mySchalter1.

Soll auch der zweite Befehl ''set myLampe2 off'' erst nach dem Event ausgeführt werden, muss ein doppeltes Semikolon genutzt werden:
define n1 notify mySchalter1:on set myLampe1 on;;set myLampe2 off

Die kombinierte Variante könnte so aussehen:
define n1 notify mySchalter1:on set myLampe1 on;;set myLampe2 off;set myLampe3 on
Diese Befehlszeile würde also myLampe3 sofort schalten, aber erst nach dem Event von mySchalter1 schalten myLampe1 und myLampe2.

==Devices umbenennen==

Schließlich wollen wir (zur Übung) noch ein Device umbenennen: Aus '''''myLampe2''''' soll '''''myStehlampe''''' werden. Dafür verwenden wir
rename <alterName> <neuerName>

Hierbei ist zu beachten, dass zugehörige notify-Anweisungen '''nicht''' automatisch aktualisiert werden. Beachten Sie also vor dem Umbenennen im unteren Bereich des Detail-Bildschirms die Liste ''Probably associated with'', damit Sie bei der folgenden Anpassung keines Ihrer Notify vergessen.

Geben Sie also in das Kommandofeld ein
rename myLampe2 myStehlampe
und passen Sie anschließend ''n_mySchalter1'' an, indem Sie auf dessen Detail-Bildschirm im Bereich ''DEF'' die Definition anpassen.

Nach der Änderung muss das Notify lauten
define n_mySchalter1 notify mySchalter1 set myLampe1,myStehlampe $EVENT

[[Datei:ErsteSchritteInFhem16.png]]

==Zeitgesteuert schalten - at==

Im nächsten Schritt soll eine Zeitsteuerung eingerichtet werden.
Zunächst möchten wir erreichen, dass ''myLampe1'' nach einer Minute ausgeschaltet wird wie z.B. ein Treppenhauslicht.

{{Hinweis|Damit Sie den Effekt sehen können, schalten Sie ''myLampe1'' vorher auf ''on''.}}

Für Zeitsteuerungen gibt es den fhem-Device-Typ ''at''. Die Befehlsstruktur ist
define <name> at <timespec> <command>
'''<name>''' und '''<command>''' haben hier dieselbe Funktion wie bei notify. Neu ist hier lediglich '''<timespec>''' (time specification), also die Zeitangabe. Diese erfolgt in der Schreibweise ''HH:MM:SS'' oder ''HH:MM''.

Um '''''myLampe1''''' also '''in einer Minute auszuschalten''', erzeugen Sie folgendes ''at'':
define a_myLampe1 at +00:01:00 set myLampe1 off

[[Datei:ErsteSchritteInFhem17.png]]

Probieren Sie es aus.
Wird ''myLampe1'' nach einer Minute ausgeschaltet?
Wird dabei ein Event erzeugt?

Wenn Sie sich die Detailansicht des ''at'' anschauen möchten, müssen Sie sich übrigens beeilen: Nach der einmaligen Ausführung wird das ''at'' automatisch gelöscht. Falls fhem schneller war, können Sie es ja noch einmal anlegen und ggf. eine längere Zeitspanne angeben :-)

Bei <timespec> kann man die Sekunden auch weglassen und einfach nur HH:MM schreiben. Außerdem gibt es mehrere Varianten:
{|class="wikitable"
|+Varianten von Zeitangaben für ''at''
|-
!Notation
!Erklärung
|-
|style="text-align: right;"|+00:02:00
|In zwei Minuten; einmalige Ausführung
|-
|style="text-align: right;"|00:02:00
|Um zwei Minuten nach Mitternacht, also um 00:02 Uhr und 0 Sekunden; einmalige Ausführung
|-
|style="text-align: right;"|*00:02:00
|Täglich um 00:02 Uhr
|-
|style="text-align: right;"|+*00:02:00
|Alle 2 Minuten
|-
|style="text-align: right;"|+*{3}00:02
|Dreimal, alle zwei Minuten
|-
|style="text-align: right;"|*{3}00:02
|Dreimal um 00:02 Uhr
|-
|style="text-align: right;"|*{sunset_rel()}
|Täglich zu Sonnenuntergang
|-
|style="text-align: right;"|*{sunrise(+120)}
|Täglich 2 Minuten (120 Sekunden) nach Sonnenaufgang
|}
*Durch die Angabe von '''*''' wird also eine dauerhafte Wiederholung definiert. Die Wiederholungen laufen so lange, bis das ''at'' gelöscht oder disabled wird.
*Durch die Angabe von '''+''' wird die angegebene Zeit nicht mehr als absolute Uhrzeit interpretiert, sondern als Timer, nach wie vielen Stunden:Minuten:Sekunden der Befehl ausgeführt wird.
*Durch die Angabe von '''''{n}''''' wird das ''at'' nur n-mal durchlaufen.
*Die Funktionen '''''{sunset_rel()}''''' und '''''{sunrise()}''''' liefern die passende Uhrzeit zurück. Durch Angabe von '''''*''''' wird dies täglich wiederholt.

Um bspw. täglich zu Sonnenaufgang die Gartenbeleuchtung auszuschalten, definieren Sie so etwas wie
define a_GartenLicht_morgens_off at *{sunrise()} set GartenLicht off

[[Datei:ErsteSchritteInFhem18.png]]

Im Detailscreen eines ''at'' wird übrigens im ''STATE'' der Zeitpunkt der nächsten Ausführung angezeigt.

Diese Info erscheint auch in der Raum-Ansicht, falls Sie das ''at'' dort anzeigen lassen:

[[Datei:ErsteSchritteInFhem18B.png]]

==Timer bei einem Event starten - notify und at==

Als letzte Übung wollen wir ein ''notify'' und ein ''at'' verbinden. Der Timer soll nun nicht starten, wenn Sie den Befehl in das Kommandofeld eingeben, sondern wenn ein Event eintritt.

Dazu basteln wir uns ein Treppenhaus: Legen Sie dafür die Dummy-Devices ''th_Schalter'' und ''th_Licht'' im Raum ''Treppenhaus'' an. Zum Anlegen des Raums ''Treppenhaus'' ordnen Sie dem ersten Device den Raum über das Kommandofeld zu, alle weiteren Attribute dann durch Klicken im Detail-Bildschirm:
define th_Schalter dummy
attr th_Schalter room Treppenhaus
attr th_Schalter webCmd on
define th_Licht dummy
attr th_Licht room Treppenhaus

Nun fehlt noch das Notify, welches auf ''th_Schalter:on'' reagiert und daraufhin zwei Befehle ausführt:
*Einschalten des Treppenhauslichts mit <code>set th_Licht on</code>
*Einen Timer starten, der es nach einer Minute wieder ausschaltet. Also <code>define a1 at +00:01 set th_Licht off</code>.

Das sieht dann so aus (und muss ins Kommandofeld als '''eine''' Zeile eingegeben werden):
define n_th_Schalter_on notify th_Schalter:on
set th_Licht on;;define a1 at +00:01 set th_Licht off
Beim Auslösen des Notify wird also als Kommando das Einschalten des Treppenhauslichts ausgelöst, wie auch das Definieren eines Timers, der es eine Minute später wieder ausschaltet.
Funktioniert es?

[[Datei:ErsteSchritteInFhem19.png]]

Da das ja doch recht sperrig ist, gibt es noch eine etwas einfachere Alternative:
define n_th_Schalter_on notify th_Schalter:on set th_Licht on;;sleep 60;;set th_Licht off

Manche Hardwaresysteme bieten auch den Befehl ''on-for-timer'', mit dem man alternativ schreiben kann
define n_th_Schalter_on notify th_Schalter:on set th_Licht on-for-timer 60

==Wie geht es weiter?==

Sie haben nun kennengelernt:
* Das Anlegen von fhem-Devices mit '''define'''
* '''Events''' und den Event-Monitor
* Schalten von Devices mit '''set'''
* Verändern von Devices mit '''modify''', '''rename''' und '''delete'''
* Das Setzen und Bearbeiten von '''Attributen'''
* Event-getriebene Aktionen durch '''notify'''
* Zeitgesteuertes Schalten mit '''at'''

Damit kennen Sie die grundlegendsten Mechanismen von fhem. Details zu diesen Befehlen finden Sie in der fhem Befehlsreferenz [http://fhem.de/commandref.html commandref]

'''Tipp:''' Zu vielen fhem-Befehlen und Gerätetypen gibt es auch eine deutschsprachige Beschreibung. Klicken Sie dazu in der commandref oben links auf den Link "DE".

In der commandref finden Sie neben der Beschreibung aller fhem-Befehle auch die Liste aller Gerätetypen, die in fhem eingebunden werden können.

Sie werden feststellen, dass "echte" fhem-Devices grundsätzlich genau so aussehen, wie die dummy-Devices, die Sie hier bereits kennengelernt haben. Der wesentliche Unterschied ist, dass Sie die verfügbaren Befehle nicht mehr selbst mittels ''attr webCmd'' festlegen müssen, da diese bereits durch das fhem-Device vorgegeben sind. Und Events werden nicht nur ausgelöst, wenn Sie im fhem-Webfrontend klicken, sondern auch, wenn das physische Gerät (also der Bewegungssensor oder der Lichtschalter an der Wand) auslöst.

Sobald Sie ihre ersten Geräte an fhem gekoppelt haben, schauen Sie sich den Event-Monitor an, um zu sehen, wann welche Events ausgelöst werden.

Einen umfangreicheren Einstieg in fhem finden Sie im Dokument [http://fhem.de/Heimautomatisierung-mit-fhem.pdf Heimautomatisierung-mit-fhem]

Viel Spaß und Erfolg mit fhem !

[[Kategorie:HOWTOS]]