FHEMWiki - Benutzerbeiträge [de]

HomeMatic Type Thermostat

2015-12-28T14:40:03Z

Kossmann: Beispiel passte nicht zum Code

{{HMType}} 
== HomeMatic Geräte vom Typ Thermostat ==
(Auswahl) derzeit unterstützter Geräte des Typs ''Thermostat'':
*[[HM-CC-RT-DN Funk-Heizkörperthermostat]]
*[[HM-CC-TC Funk-Wandthermostat]]
*[[HM-TC-IT-WM-W-EU Funk-Wandthermostat AP]]

== Hinweise zur Konfiguration ==
Die Thermostate unterscheiden sich in vielen Details und Funktionen. Daher sind Einzelheiten im Device nachzulesen.
Gemeinsam ist den Controllern, dass sie eine oder mehrere Temperaturlisten als Wochenprogramm unterstützen.

=== Temperaturlisten ===
====Manuell====
Hinweis: Bei den Wandthermostaten heißt der relevante Kanal ''..._climate'', beim HM-CC-RT-DN ist der Kanal ''..._Clima'' zuständig für die Wochenprogramme.

===== Allgemein =====
Mit dem Kommando
set Thermostat_Climate tempListMon 05:30 16.0 07:00 18.0 16:00 18.5 20:30 19.0 24:00 16.0
kann man das Temperaturprofil für den Wochentag ''Montag'' einstellen. Die nach dem Schaltzeitpunkt stehende Temperatur gilt immer '''bis''' zu diesen Zeitpunkt, nicht ab diesem Zeitpunkt. Der letzte Wert muss immer Mitternacht (24:00) sein.
damit ist also 00:00 - 05:30 = 16Grad, 05:30 - 07:00 = 18 Grad. Die Zeit kann in Schritten von 30min eingestellt werden, die Temperatur in 0.1 Grad.
Der Tage beginnt immer um 00:00, der letzte Abschnitt MUSS 24:00 sein.

Ändert man mehrere Tage auf einmal sollte man unbedingt mit "prep" und "exec" arbeiten, da es sonst zu Wiederholungen und langen Bearbeitungen kommen kann. Prep bereitet die Änderung in FHEM nur vor, mit exec werden die Daten dann an das Device übertragen. Das könnte in einem Fhem-Script lauten

######################################################
# Temperatur-Liste für Zimmer
# setzen per Aufruf von "{SetTempList_Heizung}"
######################################################
sub
SetTempList_Heizung()
{
{ fhem ("set Thermostat_Climate tempListMon prep 05:30 19.0 07:00 20.5 16:00 19.0 20:30 20.0 24:00 17.0")};
{ fhem ("set Thermostat_Climate tempListTue prep 05:30 19.0 07:00 20.5 16:00 19.0 20:30 20.0 24:00 17.0")};
{ fhem ("set Thermostat_Climate tempListWed prep 05:30 19.0 07:00 20.5 16:00 19.0 20:30 20.0 24:00 17.0")};
{ fhem ("set Thermostat_Climate tempListThu prep 05:30 19.0 07:00 20.5 16:00 19.0 20:30 20.0 24:00 17.0")};
{ fhem ("set Thermostat_Climate tempListFri prep 05:30 19.0 07:00 20.5 15:00 19.0 20:30 20.0 24:00 17.0")};
{ fhem ("set Thermostat_Climate tempListSat prep 07:00 19.0 09:00 21.0 15:00 19.0 21:00 21.0 24:00 17.0")};
{ fhem ("set Thermostat_Climate tempListSun exec 07:00 19.0 09:00 21.0 15:00 19.0 21:00 21.0 24:00 17.0")};
}
# End SetTempList_Heizung

===== Wochenprogramme des HM-TC-IT-WM-W-EU setzen =====

Der HM-TC-IT-WM-W-EU verfügt über weitere Wochenprogramme P2 und P3.

Um z.B. das 2. Wochenprogramm eines HM-TC-IT-WM-W-EU zu setzen, kann man (hier beispielhaft für den Samstag) folgenden Befehl benutzen:

set <HM-TC-IT-WM-W-EU>_Climate tempListSat p2 07:30 16.0 17:00 20.0 19:00 21.0 24:00 16.0

====Templates ====
Etwas komfortabler kann man Wochenprogramme in einem File verwalten. Man kann beliebig viele templates erzeugen und diese in einem File ablegen. Diese unterschiedlichen Wochenprogramme kann man den Thermostaten zuweisen. So kann man ein Wochenprogramm beliebig vielen Thermostaten zuweisen. Bei Änderungen kann man alle betroffenen Thermostate, die das gleiche Template nutzen sollen, erreichen.

Zusammenfassend:
* Temperaturlisten der Devices in ein file schreiben
* Templates definieren, die man mehreren Devices zuordnen kann
* Template-Änderungen gleichzeitig in mehrere Devices einspielen
* Temperaturlisten gegen ein Template prüfen

=====File erstellen und verwalten =====
Ein File mit den Temperaturlisten (Wochenplänen) muss erzeugt werden. Zur Verwaltung der Temperaturprofile sollte die Datei tempList.cfg im Verzeichnis FHEM liegen, dann kann sie mit dem Web-Interface editiert werden.
HMInfo unterstützt das speichern allen temperaturlisten in ein File mit [[Homematic_HMInfo#Speichern|temperaturListen speichern]]. Dies kann man gut als Startpunkt nutzen.
Bsp:

Angenommen HMInfo ist definiert per
define hm HMinfo
legt dieser Aufruf ein initiales Template an.
set hm tempList save FHEM/tempList.cfg

Die Wochenprogramme sollten in FHEM vorliegen. ggf. mit getConfig auslesen.

entities:tempTmpl1
tempListSat>08:00 14.0 15:00 18.0 21:30 19.0 24:00 14.0
tempListSun>08:00 14.0 15:00 18.0 21:30 19.0 24:00 17.0
tempListMon>07:00 14.0 16:00 18.0 21:00 19.0 24:00 14.0
tempListTue>07:00 14.0 13:00 16.0 16:00 18.0 21:00 19.0 24:00 15.0
tempListWed>07:00 14.0 16:00 18.0 21:00 19.0 24:00 14.0
tempListThu>07:00 14.0 16:00 18.0 21:00 19.0 24:00 14.0
tempListFri>07:00 14.0 13:00 16.0 16:00 18.0 21:00 19.0 24:00 14.0
entities:tempTWohnzimmer
tempListSat>08:00 14.0 15:00 18.0 21:30 19.0 24:00 17.0
tempListSun>08:00 14.0 15:00 18.0 21:30 19.0 24:00 14.0
tempListMon>07:00 14.0 16:00 18.0 21:00 19.0 24:00 14.0
tempListTue>07:00 14.0 13:00 16.0 16:00 18.0 21:00 19.0 24:00 15.0
tempListWed>07:00 14.0 16:00 18.0 21:00 19.0 24:00 14.0
tempListThu>07:00 14.0 16:00 18.0 21:00 19.0 24:00 14.0
tempListFri>07:00 14.0 13:00 16.0 16:00 18.0 21:00 19.0 24:00 14.0

=====Templates zuweisen =====
Das Attribut tempListTmpl sollte man allen Thermostaten zuweisen. Dies ist dem jeweiligen Steuerungschannel zuzuweisen
attr hk1_Clima tempListTmpl setup/tempList.cfg:tempTmpl1
attr hk2_Clima tempListTmpl setup/tempList.cfg:tempTmpl1
attr hk3_Clima tempListTmpl setup/tempList.cfg:tempTWohnzimmer

In entsprechenden Kommandos muss man nun nicht mehr den Namen des Templates für den HK angeben, es wird der aus dem Attribut genommen. Man gibt das File an und dann den Namen des Templates im File.

===== Überprüfen/Einlesen =====
Mit dem verify-Kommando wird überprüft, ob das gegenwärtig vorhandene Temperaturprofil mit dem in der Datei befindlichen übereinstimmt.
set thermostat_Climate tempListTmpl verify FHEM/tempList.cfg:room1
Mit dem restore-Kommando wird das Temperaturprofil des Heizkörperthermostaten mit dem in der Datei befindlichen überschrieben.
set thermostat_Climate tempListTmpl restore FHEM/tempList.cfg:room1
* FHEM/tempList.cfg ist die Datei, in dem das Temperaturprofil zu suchen ist. '''room1''' ist der Name des Temperaturprofils, welches in der Datei gesucht wird. Wird keine Datei angegeben wird "template.cfg" im "fhem"-Verzeichnis angenommen.
Man kann einem Thermostat das '''Attribut tempListTmpl''' geben. Damit wird der Default-Name des Temperaturprofils für dieses Device gesetzt.
attr thermostat_Climate tempListTmpl FHEM/tempList.cfg:room1
set thermostat_Climate tempListTmpl
prüft das gegenwärtige Temperaturprofil gegen FHEM/tempList.cfg:room1 (da verify der Default ist). Die Prüfung des Profils ist auch Teil des configCheck von HMInfo.
Will man explizit kein Temperaturprofil zuweisen sollte man tempListTmpl auf none setzen.
set thermostat_Climate tempListTmpl restore
überschreibt das gegenwärtige Temperaturprofil des Heizkörperthermostaten mit dem in der Datei befindlichen überschrieben.

=====Templates systemweit nutzen=====
Sinnvoll erscheint es, das ganze systemweit zu machen. Man legt ein File mit allen Wochenplänen an, die man nutzen will. Dann weißt man die TemplateNamen den Thermostaten zu. Und schließlich prüft oder updates man alle Thermostate in einem System mit einem Kommando. Siehe hierzu [[Homematic_HMInfo#Temperaturlisten|HMInfo temperaturlisten]].

[[Kategorie:HomeMatic Components]]
[[Kategorie:Heizungssteuerung]]

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

2015-12-23T15:18:29Z

Kossmann: Firmware Update

[[Datei:HM-TC-IT-WM-W-EU.jpg|thumb|right|HM-TC-IT-WM-W-EU Funk-Wandthermostat AP]]
'''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 ==
'''Einstellungen und Informationen die alle HomeMatic Thermostat betreffen sind unter [http://www.fhemwiki.de/wiki/HomeMatic_Type_Thermostat#Temperaturlisten|HomeMatic Type Thermostat] zu finden.'''

Er 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. Danach kann das 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 ann 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> dual set
set <HM-LC-SW1-FM> regSet shCtOn ltLo <HM-TC-IT-WM-W-EU_SwitchTr>

=== 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 mit denen anderer HomeMatic Thermostate verwaltet, siehe [http://www.fhemwiki.de/wiki/HomeMatic_Type_Thermostat#Temperaturlisten|HomeMatic Type Thermostat]. Beim HM-TC-IT-WM-W-EU ist der Kanal 4 (_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_V1.0_GE_eQ-3_20131211_web.pdf Manual]
* [http://www.eq-3.de/Downloads/eq3/pdf_produkte/Funk-Wandthermostat_132030_Produktdatenblatt_V1.0.pdf Produktdatenblatt]

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

Virtueller Controller VCCU

2015-08-31T09:57:55Z

Kossmann:

== Kurzbeschreibung ==
Ein virtueller Controller '''VCCU''' ist der Protokoll-Endpunkt der Zentrale. 
Es können einer VCCU einzelne, oder mehrere IO Devices zugeordnet werden. Man bündelt dadurch mehrere IO Devices (z.B. CULs) zu einem ''Pool''. Den Devices in FHEM (Aktoren, Sensoren) kann dann als IO Device die ''VCCU'' zugeordnet werden. Dies wird im weiteren als ''dynamische IOs'' bezeichnet

Durch diese Gruppierung der IO Devices und dem zuordnen der VCCU zu einem Device entstehen verschieden Vorteile, abhängig des Einsatzes der VCCU. So kann ein beliebiges IO Device im Device Pool der VCCU ausfallen und das oder die verbliebenden IO Devices übernehmen diese Funktion (abhängig der Funkreichweite/Erreichbarkeit). Die VCCU wird das nächst verfügbare IO Device zum senden/empfangen verwenden. Dies ist empfehlenswert für jeden der eine gewisse Ausfallsicherheit einzelner Komponenten erreichen möchte.

Ein weitere Vorteil ist das durch die VCCU auch das IO 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).

== Wann ist eine VCCU sinnvoll ==
Der Einsatz einer VCCU ist '''immer''' sinnvoll und sollte auch nur bei der Nutzung eines einzelnen IO Devices in FHEM angelegt sein. Es entstehen keine Nachteile.

Daher gilt die Empfehlung '''immer''' eine VCCU anzulegen.

== Mehrere VCCUs in einer Installation==
FHEM erlaubt die Nutzung mehrer VCCUs parallel. Das System kann in Gruppen aufgeteilt und jeder VCCU eine Reihe von IOs zuwiesen werden.

Empfohlen wird die Definition '''einer einzigen''' VCCU, welcher man alle IOs für HM zuweist.

== Definition ==
=== HMId wählen ===
Eine VCCU benötigt wie alle HM Devices eine Adresse, mit der sie angesprochen wird. Diese muss eindeutig in System sein. Man muss also eine noch nicht verwendete wählen. 
Eindeutig ist im Bereich CUL_HM. Eine HMId eines IO kann/sollte verwendet werden da diese keine CUL_HM Devices sind.

Eine VCCU gibt HMId an die ihr zugewiesenen IOs (Funkschnittstellen) weiter. Definiert man eine VCCU nachdem IOs (CUL oder HMLAN) für Homematic angelegt sind, sollte die HMId des IO verwendet werden.

In der Regel nimmt man die HMId des IOs, welcher später der VCCU zugeordnet werden soll.

=== Einrichten ===
define vccu CUL_HM <HMId>
attr vccu model CCU-FHEM
attr vccu IOList <io1>[,<io2>,...]

IOList beinhaltet die Komma-getrennte Liste der IOs welche die VCCU nutzen soll/darf.

=== Auswirkungen auf IOs===
Sind IOs durch das Attribut IOList einer VCCU zugewiesen werden die notwendigen Attribute im IO gesetzt. Die HMId wird 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 Internals ''owner'' und ''owner_CCU'' des IO automatisch eingetragen. 

=== Best Current Practice ===
Folgenden Aktionen sind weiter im IO möglich, sollten aber in der VCCU genutzt werden.
hmPairForSec
hmPairSerial

== Dynamisches IO ==
Devices senden 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. Weiter gibt es ''bewegliche'' Fernbedienungen welche ihre Verbindung zu einem IO verlieren, aber über ein andere IO gut empfangen könnten.

FHEM stellt hierzu 2 Methoden zu Verfügung.

=== IO Ersatzschaltung ===
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. Man definiert ein preferredIO.
attr <dev> IOgrp <vccu>:<preferredIO>
Beispiel:
attr LichtFlur IOgrp vccu:HMLAN1
FHEM sendet zum Device LichtFlur über HMLAN1 so lange dies verfügbar ist. Bei Ausfall von HMLAN1 aus der IOList des VCCU nach einem Ersatz gesucht.

HMLAN1 muss in der IOList der VCCU enthalten sein.

=== IO nach Empfangspegel ===
Bewegliche Fernbedienungen haben naturgemäß kein preferredIO. Daher wird dieser Eintrag nicht gesetzt. Es wird nun das IO mit dem aktuell besten Empfangspegel genutzt.
attr Fernbedienung1 IOgrp vccu

=== 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 sind irrelevant. Es zeigt 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. Erleichtern kann man dies mittels des Befehls:

attr TYPE=CUL_HM:FILTER=DEF=...... IOgrp vccu
save

Dieser Befehl (in der Fhem-Eingabezeile eingeben und mit <Return> bestätigen).

== Virtuelle Kanäle der VCCU==
Eine VCCU kann bis zu 50 virtuelle Kanäle 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 eine virtuellen Kanal mit einem Dimmer um das Verhalten bei Tastendruck lang und kurz festzulegen. Aus der Zentrale kann man den Tastendruck auslösen. Es können mehrere Aktoren an einen virtuellen Kanal gepeert werden und so alle Lichter der Gruppe mit einem "press" verzögerungslos 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 ===
für Kommandos siehe CommandRef und
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]]

Virtueller Controller VCCU

2015-08-31T09:57:35Z

Kossmann:

== Kurzbeschreibung ==
Ein virtueller Controller '''VCCU''' ist der Protokoll-Endpunkt der Zentrale. 
Es können einer VCCU einzelne, oder mehrere IO Devices zugeordnet werden. Man bündelt dadurch mehrere IO Devices (z.B. CULs) zu einem ''Pool''. Den Devices in FHEM (Aktoren, Sensoren) kann dann als IO Device die ''VCCU'' zugeordnet werden. Dies wird im weiteren als ''dynamische IOs'' bezeichnet

Durch diese Gruppierung der IO Devices und dem zuordnen der VCCU zu einem Device entstehen verschieden Vorteile, abhängig des Einsatzes der VCCU. So kann ein beliebiges IO Device im Device Pool der VCCU ausfallen und das oder die verbliebenden IO Devices übernehmen diese Funktion (abhängig der Funkreichweite/Erreichbarkeit). Die VCCU wird das nächst verfügbare IO Device zum senden/empfangen verwenden. Dies ist empfehlenswert für jeden der eine gewisse Ausfallsicherheit einzelner Komponenten erreichen möchte.

Ein weitere Vorteil ist das durch die VCCU auch das IO 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).

== Wann ist eine VCCU sinnvoll ==
Der Einsatz einer VCCU ist '''immer''' sinnvoll und sollte auch nur bei der Nutzung eines einzelnen IO Devices in FHEM angelegt sein. Es entstehen keine Nachteile.

Daher gilt die Empfehlung '''immer''' eine VCCU anzulegen.

== Mehrere VCCUs in einer Installation==
FHEM erlaubt die Nutzung mehrer VCCUs parallel. Das System kann in Gruppen aufgeteilt und jeder VCCU eine Reihe von IOs zuweisen werden.

Empfohlen wird die Definition '''einer einzigen''' VCCU, welcher man alle IOs für HM zuweist.

== Definition ==
=== HMId wählen ===
Eine VCCU benötigt wie alle HM Devices eine Adresse, mit der sie angesprochen wird. Diese muss eindeutig in System sein. Man muss also eine noch nicht verwendete wählen. 
Eindeutig ist im Bereich CUL_HM. Eine HMId eines IO kann/sollte verwendet werden da diese keine CUL_HM Devices sind.

Eine VCCU gibt HMId an die ihr zugewiesenen IOs (Funkschnittstellen) weiter. Definiert man eine VCCU nachdem IOs (CUL oder HMLAN) für Homematic angelegt sind, sollte die HMId des IO verwendet werden.

In der Regel nimmt man die HMId des IOs, welcher später der VCCU zugeordnet werden soll.

=== Einrichten ===
define vccu CUL_HM <HMId>
attr vccu model CCU-FHEM
attr vccu IOList <io1>[,<io2>,...]

IOList beinhaltet die Komma-getrennte Liste der IOs welche die VCCU nutzen soll/darf.

=== Auswirkungen auf IOs===
Sind IOs durch das Attribut IOList einer VCCU zugewiesen werden die notwendigen Attribute im IO gesetzt. Die HMId wird 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 Internals ''owner'' und ''owner_CCU'' des IO automatisch eingetragen. 

=== Best Current Practice ===
Folgenden Aktionen sind weiter im IO möglich, sollten aber in der VCCU genutzt werden.
hmPairForSec
hmPairSerial

== Dynamisches IO ==
Devices senden 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. Weiter gibt es ''bewegliche'' Fernbedienungen welche ihre Verbindung zu einem IO verlieren, aber über ein andere IO gut empfangen könnten.

FHEM stellt hierzu 2 Methoden zu Verfügung.

=== IO Ersatzschaltung ===
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. Man definiert ein preferredIO.
attr <dev> IOgrp <vccu>:<preferredIO>
Beispiel:
attr LichtFlur IOgrp vccu:HMLAN1
FHEM sendet zum Device LichtFlur über HMLAN1 so lange dies verfügbar ist. Bei Ausfall von HMLAN1 aus der IOList des VCCU nach einem Ersatz gesucht.

HMLAN1 muss in der IOList der VCCU enthalten sein.

=== IO nach Empfangspegel ===
Bewegliche Fernbedienungen haben naturgemäß kein preferredIO. Daher wird dieser Eintrag nicht gesetzt. Es wird nun das IO mit dem aktuell besten Empfangspegel genutzt.
attr Fernbedienung1 IOgrp vccu

=== 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 sind irrelevant. Es zeigt 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. Erleichtern kann man dies mittels des Befehls:

attr TYPE=CUL_HM:FILTER=DEF=...... IOgrp vccu
save

Dieser Befehl (in der Fhem-Eingabezeile eingeben und mit <Return> bestätigen).

== Virtuelle Kanäle der VCCU==
Eine VCCU kann bis zu 50 virtuelle Kanäle 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 eine virtuellen Kanal mit einem Dimmer um das Verhalten bei Tastendruck lang und kurz festzulegen. Aus der Zentrale kann man den Tastendruck auslösen. Es können mehrere Aktoren an einen virtuellen Kanal gepeert werden und so alle Lichter der Gruppe mit einem "press" verzögerungslos 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 ===
für Kommandos siehe CommandRef und
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]]

HM-CFG-LAN LAN Konfigurations-Adapter

2014-08-05T10:59:38Z

Kossmann: /* Wechsel von CUL zu HMLAN */

[[Datei:HM-CFG-LAN.jpg|thumb|right|HomeMatic LAN Konfigurations-Adapter]]
== Vorbemerkungen ==
Der HomeMatic Konfigurations-Adapter LAN ([http://www.eq-3.de/produkt-detail-zentralen-und-gateways/items/hm-cfg-lan.html HM-CFG-LAN]), kurz HMLAN, ist ein Schnittstellengerät (IO) ohne wesentliche Intelligenz. Die Aufgabe ist, ein Interface von der Zentrale zu den Geräten bereitzustellen. Ein HMLAN selbst steuert keine Geräte, es überträgt nur Nachrichten in beide Richtungen.

=== Alternativen ===
Alternativen zu einem HMLAN sind [[HM-CFG-USB USB Konfigurations-Adapter]], [[CUN]], [[CUNO]] und [[CUL]].

==== HMUSB ====
Ein HMUSB hat nahezu identische Eigenschaften wie ein HMLAN. Der wesentliche Unterschied ist die Anbindung über USB anstatt Ethernet. Es hat sich erwiesen, dass USB eine bessere Latenz hat als LAN - also eine kürzere Verzögerung. Damit hat ein HMUSB leichte Vorteile zu HMLAN, was aber in den bei Weitem meisten Fällen durch die interne Timing Kalkulation abgefangen wird.
Dafür bietet der HMLAN mit seinem Netzwerkanschluss Vorteile bei der Platzierung.

==== CUL/CUN(O) ====
* Die Devices liefern keine eigenen Zeitstempel, wodurch eine Timingkorrektur durch FHEM nicht möglich ist. Je nach Systemgeschwindigkeit kann dies zu Problemen, Nachrichten wiederholen und ggf. auch Nachrichtenverlust führen
* Da USB kurze Reaktionszeiten und geringe Timingschwankungen hat ist der Einsatz von [[CUL]] und [[CUNO]] mit HM möglich. Die Timingschwankungen der Ethernet-schnittstelle hingegen können in FHEM nicht ausgeglichen werden. Daher kann der Einsatz der [[CUNO]] über Ethernet '''nicht empfohlen''' werden.
* [[AES Encryption]] wird nicht unterstützt
* lacyConfig (ein Übertragungsmode) wird nicht unterstützt

=== Funktionen ===
==== AES ====
siehe [[AES Encryption]].

==== Übertragungsmode ====
Es werden alle HM-Modi unterstützt. Diese sind Always, Burst, Wakeup und Config. Weiter gibt es lacyConfig und conditionalBurst. Siehe [[HomeMatic]] für Details.

==== KeepAlive ====
Das HMLAN baut eine Verbindung zur Zentrale über das LAN Interface auf. HMLAN erwartet alle 30sec eine keep-alive Nachricht von der Zentrale. Sollte diese ausbleiben baut HMLAN die LAN-Verbindung ab. Das führt zu einem Disconnect, welcher in State gemeldet wird. Die Verbindung wird automatisch wieder aufgebaut.
FHEM sendet den keep-alive alle 25 sec, was einen 5sec Puffer einräumt. In Internals '''msgKeepAlive''' kann man sehen, wie hoch die maximale Verzögerung der Zentrale beim Senden war und wie viel Puffer (in sec) noch war.
Die Wiederholrate von 25 sec des keep-alive kann man mit dem Attribut '''wdTimer''' reduzieren werden, was den Puffer erhöhen. Es wird jedoch dringend geraten, im Problemfall die Ursache der Verzögerung zu finden und zu eliminieren.

==== Nachrichtenübertragung - Performance ====
* Mit Internal '''msgParseDly''' kann man ablesen, wie viel Verzögerung eine Nachricht von Empfangen im HMLAN bis zur Verarbeitung in der Zentrale hat.
* HMLAN hält sich an den Funkstandard, welcher einem Sender eine maximale Sendezeit je Stunde erlaubt. Wird dieser Wert überschritten stellt HMLAN das Senden ein. Empfangen wird weiter. Ist eine Kapazität von 90% erreicht wird im Reading '''cond''' '''Warning-HighLoad''' gemeldet. Bei cond '''ERROR-Overload''' wird das Senden eingestellt ist.

==== Loggen/Mitschneiden ====
Es stehen die üblichen Funktionen des Attribute '''verbose''' zu Verfügung. Darüber hinaus gibt es die Attribute hmProtocolEvents und logIDs. Siehe auch [[Homematic Nachrichten sniffen|Homematic Nachrichten sniffen]].

== Vorbereitung ==
[[Datei:HMLAN_CONFIG_IP_AES.png|300px|thumb|right|HomeMatic Lan-Interface Configurator]][[Datei:HMLAN_CONFIG_AES.png|300px|thumb|right|HomeMatic Konfigurator]]Bevor man den HMLAN mit Fhem nutzen kann, müssen noch Einstellungen vorgenommen werden. Dazu braucht man Software die bei [http://www.eq-3.de/software.html HomeMatic] in der Version 1.512 (Stand 19. Dezember 2013) herunter zu laden ist und nach der Installation mit der Verknüpfung "HomeMatic-Lan-Interface konfigurieren" oder "HomeMatic-Komponenten konfigurieren" gestartet wird und unter Windows läuft. Für andere Betriebssystem ([http://forum.fhem.de/index.php?t=msg&th=11506&goto=67417&rid=417#msg_67417 Anleitung für OS X]) braucht man eine Windows-Emulation. Dem HMLAN liegen zwei Konfigurationsprogramme bei, bitte darauf achten, das richtige zu verwenden. Wenn das Konfigurationsprogramm den HMLAN-Konfigurator nicht findet, sollten alle nicht benutzten Netzwerkinterfaces vorübergehend deaktiviert werden, siehe [http://forum.fhem.de/index.php?t=msg&th=10933&goto=62960&rid=42#msg_62960 Beitrag im Fhem Forum] und [[HM-CFG-LAN_LAN_Konfigurations-Adapter#Bekannte_Probleme|bekannte Probleme]]

=== Firmware ===
Die aktuelle Firmware Version des HMLAN ist 0.961 (Stand September 2013). Ein Update ist unter ''"Update Firmware"'' mit der ''"HomeMatic Lan-Interface Configurator"'' Software möglich.

=== IP Adresse ===
Der HMLAN Konfigurator ist ähnlich wie der CUN(O) ein Netzwerkgerät. Er beherrscht DHCP und bezieht bei einem im Netzwerk erreichbaren DHCP Servers von diesem eine IP-Adresse. Da Fhem zwecks Kommunikation die IP-Adresse wissen muss, ist es sinnvoll, dem HMLAN eine statische Adresse zuzuweisen.
* mit der auf der CD mitgelieferten ''"HomeMatic Lan-Interface Configurator"'' Software unter ''"Change IP Settings"'' oder
* im DHCP-Server eine feste IP-Adresse zuzuweisen (sofern dies vom gegeben DHCP Server als Konfigurationsoption unterstützt wird).

=== AES Encryptet LAN Communication ===
Wichtig ist, dass vor Verwendung die "AES Encryptet LAN Communication" abgeschaltet wird, da diese FHEM nicht unterstützt. Dies ist unter ''"Change IP Settings"'' der ''"HomeMatic Lan-Interface Configurator"'' Software möglich. AES auf dem LAN ist zu unterscheiden von HMLAN auf der Funktschnittstelle. siehe [[AES Encryption]].

== Einbindung in FHEM ==
Der HMLAN-Konfigurator muss in FHEM definiert werden. Dazu in die fhem.cfg eintragen:

define HMLAN1 HMLAN <IP Adresse>:1000
attr HMLAN1 hmId 123ABC
Der Name HMLAN1 kann frei vergeben werden. Standard IP-Port des HMLAN-Konfigurators ist 1000.

HMLAN kennt mehrere Attribute ([http://fhem.de/commandref.html#HMLAN commandref]).
Wichtig ist die '''hmId''' zu vergeben. Diese ist ein 3-Byte hexadezimal-Wert, somit ein 6-steliger String in '''Großbuchstaben'''. 000000 und FFFFFF sind ungültig.
Wenn HM-Geräte mit der Zentrale gepairt werden wir ihnen diese hmId eingetragen. Wechselt man die hmId müssen '''aller''' damit gepairten Geräte neu gepairt werden.

Die Adresse wird in Grossbuchstaben eingegeben, siehe [[HMLAN_Konfigurator#Bekannte_Probleme|"Bekannte Probleme"]].

Ein '''gleichzeitiger''' Zugriff von Fhem und der HomeMatic-Software auf den HMLAN-Konfigurator ist nicht möglich, da letzterer nur eine Verbindung zulässt. Wollen Sie temporär z.B. mit der Windows-Software von HomeMatic zugreifen, ist Fhem zu deaktivieren.
Sinnvoll ist es, die hmId mit der der PC-Software gleichzusetzen. Dann kann man von beiden Zentralen alternativ zugreifen ohne pairen zu müssen.

=== Nutzung mehrere IOs ===
==== Empfangen ====
Man kann an einem FHEM mehrere IOs (HMLAN/USB, CUL/CUNO) betreiben. Generell empfangen alle IOs von allen Geräten in ihrem Empfangsbereich - unabhängig von der hmId.

==== Senden ====
An ein Gerät wird nur über das IO gesendet welches in Internals->IODev angezeigt wird. Nutzt man mehrere IOs sollte im HM Device das Attribut IODev auf das gewünschte IO setzen. Ansonsten sucht FHEM zufällig ein IO aus.

==== hmId bei mehreren IOs ====
Man kann allen IOs die gleiche HMId setzen. Das erlaubt die wahlfreie Umschaltung des Sende-IOs für das Device.
Sollte man unterschiedliche hmIds wählen simuliert dies mehrere Zentralen. Das Device an welches man sendet muss über ein IO angesprochen werden, mit einer hmId auf die das Device gepairt ist.

=== Attribute ===
* '''hmId''': Adresse, die das IO auf der funkstrecke nutzt. Es ist ein 3-byte hexwert (6 Zeichen) in Großbuchstaben.
* '''hmkey, hmkey2..5''': bis zu 5 AES keys, welche auf der Funkstrecke genutzt werden. Siehe [[AES Encryption]]
* '''hmLanQlen''' legt fest, wie viele Nachrichten parallel gesendet werden dürfen, also auf wie viele Antworten die Zentrale parallel warten darf. Ein Wert von 1 ist max defensiv, erzeugt aber eine höhere Verzögerung. Wählt man einen höheren Wert kann es zu Nachrichten-Wiederholern kommen.
* '''hmProtocolEvents''': alle Nachrichten werden dekodiert ausgegeben. Diese Einstellung benötigt einige Performance insbesondere bei höheren Level. Man sollte es vorsichtig nutzen.
* '''logIDs''': zeichnet Rohmessages auf und bietet die genaueste Methode bei der Fehlersuche. Da Nachrichten undekodiert ausgegeben werden ist es im Wesentlichen für Spezialisten von Bedeutung. Man gibt eine Komma getrennte Liste von IDs an, die geloggt werden sollen. Mit '''all''' werden alle IDs aufgezeichnet. '''sys''' zeichnet zusätzlich Systemmessages auf. '''sys,all''' somit alles.
* '''respTime''': Antwortzeit des HMLAN auf ein keep-alive kann hier eingestellt werden. Normal sollte das HMLAN in 1 sec der Zentrale antworten. Sollte dies nicht passieren, wird die Message wiederholt. Der Wert sollte nur in Ausnahmefällen verändert werden.

=== Readings ===
* '''Xmit-Events''': Anzahl der Ereignisse
* '''cond''': aktueller Zustand des IO.
** ok
** Warning-HighLoad: 90% der 1h sendekapazität sind erreicht
** ERROR-Overload: 100% der sendekapazität sind erreicht, '''das IO sendet nicht mehr'''
** timeout
** disconnected: die Verbindung FHEM /IO ist unterbrochen
** Overload-released: das IO ist aus ERROR-Overload zurück im Sendebetrieb
** init: Das IO wurde neu initialisiert.
* '''prot_ERROR-Overload''': Anzahl des Events, Zeitstempel des letzten Auftretens
* '''prot_Warning-HighLoad''': Anzahl des Events, Zeitstempel des letzten Auftretens
* '''prot_disconnected''': Anzahl des Events, Zeitstempel des letzten Auftretens
* '''prot_init''': Anzahl des Events, Zeitstempel des letzten Auftretens
* '''prot_ok''': Anzahl des Events, Zeitstempel des letzten Auftretens
* '''prot_timeout''': Anzahl des Events, Zeitstempel des letzten Auftretens

=== Internals ===
* '''XmitOpen''': 1 = HMLAN ist sende bereit
* '''assignedIDs''': HMIDs der HM Devices, die über dieses IO bedient werden
* '''assignedIDsCnt''': Anzahl der zugewiesenen HMIds von FHEM
* '''assignedIDsReport''': Anzahl der HMIds, die das HMLAN angibt zu bedienen. Die Zahl sollte identisch sein mit assignedIDsCnt
* '''msgKeepAlive''': dlyMax: maximale Verzögerung, die ein keep-alive hatte. bufferMin: der minimale Zeitpuffer, der übrig blieb, bis das keep-alive zu spät gekommen wäre. Der Puffer sollte 2 oder größer sein, sonst könnte man gelegentlich disconnects bekommen.
* '''msgLoadEst''': Funkbelastung des HMLAN. Der Wert wird über 1 Stunde akkumuliert. Sollten 100% erreicht sein, wird das HMLAN den Sendebetrieb einstellen. Der Wert ist eine Hochrechnung in FHEM. Es ist möglich, dass das HMLAN mehr belastet ist. Die 10 min werte zeigen die Belastung in den letzten 10min Perioden an.
* '''msgParseDly''': Verzögerung der Message Verarbeitung vom Empfang im IO bis zur Verarbeitung in FHEM. Eine Verzögerung kann durch Prozesse an LAN, durch FHEM Prozesse oder sonstige Prozesse/Applikationen der CPU hervorgerufen werden.

== Pairen von Geräten ==
Jedes HM Geräte muss vor Verwendung mit der HM-Zentrale gepairt werden. Dabei wird die hmId des gewählten IOs in das Device programmiert. Ändert man die hmId des IO, mit welchem an das Device anspricht muss man das Device neu pairen.
Alle Geräte haben eine eigene hmId, welche nicht änderbar ist. Details zum Pairen auf der Seite [[HomeMatic Devices pairen]].

== Bekannte Probleme ==
Selten lehnt der HMLAN-Konfigurator ohne erkennbaren Grund nach monatelangem störungsfreiem Betrieb die Verbindung ab:

Opening HMLAN1 device 192.168.168.60:1000
192.168.168.60:1000 connection refused
Der HMLAN-Konfigurator kann aber über die mitgelieferte Konfigurationssoftware problemlos erreicht werden. Der Zustand lässt sich auch durch einen Reboot des HMLAN-Konfigurators (oder Fhem) nicht beheben, wohl aber durch eine Aktualisierung der Firmware des HMLAN-Konfigurators, selbst wenn die installierte Version aktuell ist.

Wenn das Konfigurationsprogramm den HM-CFG-LAN LAN Konfigurations-Adapter zu finden, sollten alle nicht benutzten Netzwerkinterfaces vorübergehend deaktiviert werden. Vereinzelt gibt es Hinweise darauf, dass es unter Windows 7 eventuell nicht reicht, die Netzwerkverbindungen im "Netzwerk- und Freigabecenter" zu deaktivieren, sondern ein Deaktivierung der Netzwerkadapter im Gerätemanager erforderlich ist.

== Wechsel von CUL zu HMLAN ==
Sollten Sie ein [[CUL]] als IO für Homematic-Geräte eingesetzt haben und jetzt einen Wechsel auf den HMLAN Konfigurator planen, hält sich der Aufwand in Grenzen:

* deaktivieren Sie das CUL in der ''fhem.cfg''.
* konfigurieren Sie den HMLAN Konfigurator '''von Hand'''
* Ändern sie das Attribut IODev aller HM-Devices vom Namen der CUL auf den Namen des HMLAN
* sollte sie das Attribut IODev nicht nutzen (nicht empfohlen) achten sie darauf, dass im fhem.cfg das IO vor allen HM-devices definiert wird. Eine automatischen Zuweisung des IO zu den Devices ist sonst nicht möglich.
** der HMLAN '''muss''' die gleiche ''hmId'' wie das bisherige CUL erhalten. Ansonsten müssen alle Geräte neu gepairt / angelernt werden.
** AES muss im HMLAN abgeschaltet werden.
* verbinden Sie den HMLAN Konfigurator mit ihrem Netzwerk und ziehen das CUL aus der USB-Buchse.
* geben Sie in der FHEM-Befehlszeile ''shutdown restart'' gefolgt von <Enter> (nicht "save") ein (evtl. reicht auch ein ''rereadcfg'').
* kontrollieren Sie im Event-Monitor und in den HM-Device-Logs von Fhem die Kommunikation.

Bitte beachten: Falls dem CUL keine explizite hmId per Attribut zugewiesen wurde, wird diese ID aus "F1<FHT-ID>" zusammengebaut. Die hmId muss auf dem HMLAN explizit gesetzt werden.

== Links ==
* [http://www.eq-3.de/software.html Software] für den Konfigurationsadapter von der eQ-3 Site

[[Kategorie:HomeMatic Components]]
[[Kategorie:Interfaces]]

HM-LC-Bl1PBU-FM Funk-Rollladenaktor für Markenschalter

2014-01-17T14:31:26Z

Kossmann: /* Mögliche Schaltoperationen */ - nicht "um" sondern "auf absolut prozentual"

= Features =

Schalten eines angeschlossenen Jalousiemotors mittels CUL/CUN/HMLAN Konfigurator und über lokalen, in bestehendes Schalterprogramm integrierte Schaltwippe.

Technische Daten:
* Gerätebezeichnung: HM-LC-Bl1PBU-FM
* Versorgungsspannung: 230 V / 50 Hz
* Maximale Schaltleistung: 230 VA (Motorlast)
* Standby-Verbrauch: 0,5 W
* Schaltvermögen: 1 A (Motorlast)
* Funkfrequenz: 868,3 MHz
* Empfängerklasse: SRD Class 2
* Maximale Sendeleistung: 10 mW
* Schutzart: IP20
* Schutzklasse: II
* Umgebungstemperatur: +5°C bis +35°C
* Abmessungen (B x H x T): 71 x 71 x 37 mm
* Gewicht: 43 g

= Hinweise zur Hardware-Installation =

Der Schaltaktor ersetzt den Unterputzschalter der bestehenden Elektroinstallation. Arbeiten am 230 V Netz dürfen nur von einer Elektrofachkraft durchgeführt werden! Sicherheitsregeln anwenden:

* Freischalten (Sicherung abschalten),
* gegen Wiedereinschalten sichern,
* Spannungsfreiheit feststellen,
* Erden und Kurzschließen,
* benachbarte, unter Spannung stehende Teile abdecken.

Zur Integration in ein bestehendes Schalterprogramm bitte den entsprechenden Adapter mit bestellen.

<gallery>
Datei:HM-LC-BL1PBU schritt 01.jpg|Ausgangssituation
Datei:HM-LC-BL1PBU schritt 02.jpg|Schalter abbauen, Rahmen entfernen, Unterputzschalter lösen
Datei:HM-LC-BL1PBU schritt 03.jpg|Bestehender Anschluss
Datei:HM-LC-BL1PBU schritt 04.jpg|Neuer Anschluss. Achtung: zusätzlicher Nullleiteranschluss!
Datei:HM-LC-BL1PBU schritt 05.jpg|Einbau ohne Adapter
Datei:HM-LC-BL1PBU schritt 06.jpg|Adapter aufsetzen
Datei:HM-LC-BL1PBU schritt 07.jpg|Fertig eingebauter HM-LC-BL1PBU-FM
</gallery>

= Hinweise zum Betrieb mit FHEM =

Der Schalter wird mit FHEM 5.3 unterstützt.

= Einrichtung über FHEMWEB mit HMLAN =

'''1. HMLAN in den pairing Modus versetzen''' (z.B. 180 Sekunden)
set <HMLAN> hmPairForSec 180

'''2. Pairing'''
set <HMLAN> hmPairSerial JEQxxxxxx

'''3. ggf. zusätzliche Attribute setzen''', z.B.
attr <DEVICE_NAME> eventMap on:hoch off:runter stop:stop
attr <DEVICE_NAME> webCmd pct
attr <DEVICE_NAME> room Wohnzimmer

'''4. Jalousielaufzeiten einstellen.''' Im folgenden Beispiel 25 Sekunden von ganz untern nach ganz oben (driveUp). 0 Sekunden Umschaltung (driveTurn - normaler Rollo, bei Lamellenjalousien hier Wert angeben!). 25 Sekunden von ganz oben nach ganz unten (driveDown)
set <DEVICE_NAME> regSet driveUp 25
set <DEVICE_NAME> regSet driveTurn 0
set <DEVICE_NAME> regSet driveDown 25

'''5.Speichern:'''
save

== FHEM Config-Auszug ==
Ein exemplarischer Auszug aus der fhem.cfg:

define WZ_Rollo_Links CUL_HM ABCDEF
attr WZ_Rollo_Links devInfo 010100
attr WZ_Rollo_Links eventMap on:hoch off:runter stop:stop
attr WZ_Rollo_Links firmware 2.1
attr WZ_Rollo_Links hmClass receiver
attr WZ_Rollo_Links model HM-LC-Bl1PBU-FM
attr WZ_Rollo_Links room Wohnzimmer
attr WZ_Rollo_Links serialNr JEQxxxxxxx
attr WZ_Rollo_Links subType blindActuator
attr WZ_Rollo_Links webCmd pct

= Mögliche Schaltoperationen =

Der Aktor versteht folgende Befehle:
set <name> on -> Schaltet den Aktor ein
set <name> off -> Schaltet den Aktor aus
set <name> toggle -> Ändert den logischen Zustand des Aktors.
set <name> <Prozentangabe[0 bis 100]> -> Öffnet die Jalousie auf absolut prozentuale Öffnungsposition, berechnet aus definierter Laufzeit.

== Log-Auszug ==
In FHEM ist nach dem Schalten des HM-LC-BL1-FM folgendes Log zu sehen:
2013.02.26 07:00:12 2: CUL_HM set WZ_Rollo_Rechts on rxt:1

== Links ==
* [http://www.elv-downloads.de/Assets/Produkte/10/1030/103038/Downloads/103038_FunkRollladenaktor_um.pdf Bedienungsanleitung (PDF)]

[[Kategorie:HomeMatic Components]]
[[Kategorie:Rolladensteuerung]]

Wochenende, Feiertage und Schulferien

2014-01-17T14:25:15Z

Kossmann:

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

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

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

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

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

<nowiki>attr global holiday2we NRW_Feiertag
define NRW_Feiertag holiday</nowiki>
Theoretisch kann man in o.a. Datei auch seine persönlichen Urlaube oder die Schulferien definieren. Hier eignet sich jedoch die ''Calendar''-Funktion wesentlich besser. V.a. die Schulferien der einzelnen Bundesländer sind im Internet (z.B. unter [http://www.schulferien.org schulferien.org]) als iCal-Datei verfügbar und können wie folgt in FHEM eingebunden werden:

<nowiki>define NRW_Ferien Calendar ical url http://www.schulferien.org/iCal/Ferien/icals/Ferien_Nordrhein_Westfalen_2013.ics 43200</nowiki>
Das Intervall von 43200 Sekunden (entspricht 12 Stunden) für die Aktualisierung der Schulferien sollte im Normalbetrieb mehr als ausreichen. Wenn eigene Kalender (z.B. bei Google) für Urlaubstage genutzt werden, muss man individuell abwägen, wie oft dieser aktualisiert werden soll.

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

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

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

<nowiki>define RolloHoch at *07:00 { if ( !($we) && !(Value("NRW_Ferientag")) ) { fhem("set Rollo hoch");; } }</nowiki>

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

[[Kategorie:Code Snippets]]

AT an einem bestimmten Wochentag ausführen

2013-07-03T15:33:26Z

Kossmann: Minuten dem Beispiel angepasst

'''AT'''
<ins>Zielvorgabe:</ins>

An jedem Mittwoch um 21:00 Uhr soll ein Schaltaktor (hier das FHEM-Gerät "Signallampe") einen Verbraucher ein- und 5 Minuten später wieder ausschalten.

'''Vorbemerkung zu den Wochentagen:''' Wochenbeginn ist in Perl der Sonntag, welcher mit 0 definiert ist, also ist 3 = Mittwoch, 4 = Donnerstag usw.

Der Befehl für die ''fhem.cfg'' lautet dazu wie folgt:

Einzeiler (kein expliziter Zeilenumbruch):

:<code><nowiki>define Licht4An at *21:00:00 { if ($wday == 3) { fhem ("set Signallampe on");; fhem ("define Licht4Aus at +00:05:00 set Signallampe off ") } }</nowiki></code>

Mehrzeiler:

<nowiki>define Licht4An at *21:00:00 {\
if ($wday == 3) {\
fhem ("set Signallampe on");;\
fhem ("define Licht4Aus at +00:05:00 set Signallampe off ")\
}\
}</nowiki>

Im Detail:
* ''define Licht4An'' => lege ein neues Objekt ''Licht4An'' und ...
* ''at *21:00:00'' => ... prüfe immer um 21:00 Uhr ...
* ''if ($wday == 3)'' => ... ob der 3. Wochentag ist, wenn ja dann ...
* ''fhem ("set Signallampe on");;'' => ... soll FHEM die Signallampe einschalten und ...
* ''fhem ("define Licht4Aus'' => noch ein Objekt ''Licht4Aus'' anlegen ...
* ''at +00:05:00'' => ... welches in 5 Minuten ...
* ''set Signallampe off")'' => ... die Signallampe wieder ausschaltet.

Das Objekt Licht4'''Aus''' wird in der FHEM-Weboberfläche nur in den knapp 5 Minuten sichtbar, wo die Signallampe eingeschaltet ist, also bitte nicht wundern, dass nur Licht4'''An''' in der Übersicht auftaucht.

[[Kategorie:Code Snippets]]

Google-Kalender zur Steuerung von Dummies

2013-05-27T11:44:08Z

Kossmann: Lesbarkeit verbessert

Mit dem Kalendermodul [http://fhem.de/commandref.html Calendar] ist es möglich, Ereignisse aus Kalendern im
ICal-Format abzufragen.
Dies und der Wiki-Eintrag [[Wochenende, Feiertage und Schulferien]] hat mich dazu veranlasst, dass ich durch
Kalendereinträge im Google-Kalender den Status meiner beiden Dummies "Urlaub" und "Besuch" steuere. Durch diese
beiden Dummies werden zum Beispiel die Rolläden im Schlafzimmer oder Gästezimmer bei Besuch oder Urlaub anders
gesteuert als ohne Besuch oder unter der Woche. Auch meine Zirkulationspumpe soll so bedarfsgerecht gesteuert werden.
Dass am Wochenende anders gesteuert wird, ist ja mit $we kein Problem.
Zuerst wird dafür der Kalender definiert:
<pre>define Kalender_Christian Calendar ical url <der richtige Kalenderlink> 14400</pre>

Den Kalenderlink [https://support.google.com/calendar/answer/37103?hl=de] findet man wie beschrieben heraus.
Dann habe ich meine Dummies definiert:
<pre>define Urlaub_dummy dummy
attr Urlaub_dummy room Kalender
attr Urlaub_dummy setList ja nein
attr Urlaub_dummy webCmd ja:nein
define Gast_dummy dummy
attr Gast_dummy room Kalender
attr Gast_dummy setList ja nein
attr Gast_dummy webCmd ja:nein</pre>

Und nun mussten die Notifys definiert werden, um bei entsprechenden Einträgen im Google-Kalender den Status der
Dummies zu setzen.
<pre>define Kalender_Christian_Start notify Kalender_Christian:modeStarted.*googlecom.* {\
Kalenderstart("$EVENT");;\
}
define Kalender_Christian_Ende notify Kalender_Christian:modeEnded.*googlecom.* { Kalenderende("$EVENT");;\
}</pre>

Um nicht für verschiedene Dummies immer einzelne Notifys zu bauen, wird hier bei mir je eine Funktion aus meiner
99_MyUtils.pm [[99 myUtils anlegen]] aufgerufen und das Event als Parameter übergeben. Die beiden zugehörigen
Funktionen für den Start und das Ende des Kalenderevents schauen so aus:
<pre>sub
Kalenderstart ($)
{
my ($Ereignis) = @_;
my @Ereignisarray = split(/.*:\s/,$Ereignis);
my $Ereignisteil1 = $Ereignisarray[1];
my @uids=split(/;/,$Ereignisteil1);
foreach my $uid (@uids) {
my $Kalendertext = fhem("get Kalender_Christian summary $uid");
if ($Kalendertext =~ /Urlaub/) {
fhem("set Urlaub_dummy ja");
};
if ($Kalendertext =~ /Besuch/) {
fhem("set Gast_dummy ja");
};
};
}
sub Kalenderende ($) {
my ($Ereignis) = @_;
my @Ereignisarray = split(/.*:\s/,$Ereignis);
my $Ereignisteil1 = $Ereignisarray[1];
my @uids=split(/;/,$Ereignisteil1);
foreach my $uid (@uids) {
my $Kalendertext = fhem("get Kalender_Christian summary $uid");
if ($Kalendertext =~ /Urlaub/) {
fhem("set Urlaub_dummy nein");
};
if ($Kalendertext =~ /Besuch/) {
fhem("set Gast_dummy nein");
};
};
}
</pre>

Zur Erläuterung: Als Ereignis wird z.B. "''modeStarted: 9aas2amo7td47th4sf7mlocl48googlecom''" oder bei 2 gleichzeitigen
Ereignissen: "''modeStarted: arqpe2a2snu6qn64dt0men7nd0googlecom;j0pjiupfb1sk3m5s64hbeo6880googlecom''"
übergeben. Da uns aber nur die eindeutige UID interessiert, wird das Ergeinis beim Vorkommen der Zeichen ": Leerzeichen"
also nach modeStarted: geteilt (''split(/.*:\s/,$Ereignis'')). Die beiden Teile werden in ein Array (@Ereignisarray) gespeichert.
Und als 2. Element in dem Array ist nun die uns interessierende UID ($Ereignisarray[1]) vorhanden, mit welcher wir weiter
arbeiten. Da auch mit dem Fall mehrerer gleichzeitiger Ereignisse umgegangen werden können soll, müssen wir bei mehreren
UID´s diese wieder splitten. Diesmal beim Vorkommen des Semikolons als Trennzeichen (''split(/;/,$Ereignisteil1'')). Auch die
UID´s werden wieder in einem Array gespeichert und dann mittels der foreach-Schleife nacheinander abgearbeitet. Und
hierbei wird abhängig von der mittels UID abgerufenen Kalenderbeschreibung (''fhem("get Kalender_Christian summary
$uid''")) ein Vergleich auf die Werte "Besuch" oder "Urlaub" durchgeführt (''if ($Kalendertext =~ /Urlaub/'')) und davon
abhängig der Dummy-Status gesetzt.
Abhängig von diesen Dummies reagiert dann meine Rollosteuerung.

[[Kategorie:Code Snippets]]

Wochenende, Feiertage und Schulferien

2013-05-27T11:42:50Z

Kossmann: "ich" Schreibweise korrigiert

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

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

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

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

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

<nowiki>attr global holiday2we NRW_Feiertag
define NRW_Feiertag holiday</nowiki>
Theoretisch kann man in o.a. Datei auch seine persönlichen Urlaube oder die Schulferien definieren. Hier eignet sich jedoch die ''Calendar''-Funktion wesentlich besser. V.a. die Schulferien der einzelnen Bundesländer sind im Internet (z.B. unter [http://www.schulferien.org schulferien.org]) als iCal-Datei verfügbar und können wie folgt in FHEM eingebunden werden:

<nowiki>define NRW_Ferien Calendar ical url http://www.schulferien.org/iCal/Ferien/icals/Ferien_Nordrhein_Westfalen_2013.ics 43200</nowiki>
Das Intervall von 43200 Sekunden (entspricht 12 Stunden) für die Aktualisierung der Schulferien sollte im Normalbetrieb mehr als ausreichen. Wenn eigene Kalender (z.B. bei Google) für Urlaubstage genutzt werden, muss man individuell abwägen, wie oft dieser aktualisiert werden soll.

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

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

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

<nowiki>define RolloHoch at *07:00 { if ( !($we) && !(Value("NRW_Ferientag")) ) { fhem("set Rollo hoch");; } }</nowiki>

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

[[Kategorie:Code Snippets]]