FHEMWiki - Benutzerbeiträge [de]

FS20 WS1 Wechselschalter

2018-05-07T08:00:48Z

Krokofant: /* Links */ Link war nicht erreichbar, auf archive.org umgebogen

{{Infobox Hardware
|Bild=FS20WS1.jpg
|Bildbeschreibung=FS20 WS1 Wechselschalter
|HWProtocol=FS20
|HWType=Empfänger / Aktor
|HWCategory=FS20
|HWComm=868 MHz
|HWChannels=1
|HWVoltage=230V AC
|HWPowerConsumption=<0,3 Watt
|HWPoweredBy=Netzspannung
|HWSize=53,8 x 45,5 x 20,4 mm
|HWDeviceFHEM=[http://fhem.de/commandref.html#FS20 10_FS20.pm]
|HWManufacturer=ELV / eQ-3
}}
'''FS20 WS1''' ist ein FS20 Schaltaktor, ausgeführt als Unterputzschalter für 230V Netzspannung, diese übernimmt auch die Stromversorgung (Verbrauch ca. 0,4 W).

Die geschalteten Kontakte (1x Wechsler) sind unabhängig vom Versorgungskreis. Es können also auch z.B. 12V- oder 24V-Geräte geschaltet werden.

Ausserdem ist ein bistabiles Relais verbaut, der Schalter eignet sich also für Anwendungen, in denen über lange Zeiträume 'eingeschaltet' werden soll.

== Hinweise zum Betrieb mit FHEM ==
Einsetzbar

== Bekannte Probleme ==
Der FS20-Befehlssatz ist hier insofern nicht vollständig implementiert, als nach dem Ende eines Timer-Einschaltens keine Rückkehr in den alten Zustand erfolgen kann. Beispiel: Eine Hofleuchte soll sowohl über Timer (vom Bewegungssensor) als auch per Hand geschaltet werden => mit FS20 WS1 geht die Leuchte nach dem Timerlauf immer aus, obwohl sie vorher von Hand angeschaltet worden war.

== Lieferbarkeit ==
Der Artikel wird nicht mehr hergestellt/verkauft. Der offizielle Nachfolger ist [[FS20 UWS Unterputz-Wechselschalter]], der allerdings mechanisch ein deutlich abweichendes Format hat.

== Links ==
* [http://www.elv.de/FS20-Funk-Wechselschalter-FS20-WS1/x.aspx/cid_726/detail_30900 Artikel in ELVjournal 05/2009]
* [https://web.archive.org/web/20120105120721/http://www.elv-downloads.de:80/Assets/Produkte/8/858/85839/Downloads/85839_FS20WS1_um.pdf Bedienungsanleitung] im Internet Archiv, Original-Link nicht mehr erreichbar

[[Kategorie:Schalter (Empfänger)]]

{{SORTIERUNG:Wechselschalter, FS20 WS1}}
[[Kategorie:FS20 Components|Wechselschalter, FS20 WS1]]

FS20 RSU Rollladenschalter (Unterputz)

2018-05-07T07:58:20Z

Krokofant: /* Links */

{{Infobox Hardware
|Bild=FS20RSU.jpg
|Bildbeschreibung=FS20 RSU - Unterputz-Rollladenschalter
|HWProtocol=FS20
|HWType=Aktor
|HWCategory=FS20
|HWComm=868 MHz
|HWChannels=1
|HWVoltage=230V
|HWPowerConsumption=<0,5W (Ruhebetrieb)
|HWPoweredBy=Netz
|HWSize=?
|HWDeviceFHEM=[http://fhem.de/commandref.html#FS20 10_FS20.pm]
|HWManufacturer=ELV / eQ-3
}}

Der FS20 RSU wurde Ende 2013 aus dem Programm genommen. Nachfolger ist der [[FS20 RSU-2 Funk-Rollladenaktor für Markenschalter]].

== Features ==
Aktor

== Hinweise zum Betrieb mit FHEM ==
Einsetzbar

== Befehlssatz ==
* on | off | toogle ... mit dem internen Timer des Moduls (standardmässig 1 min)
* on-till ... fährt die Rollläden sofort hoch und zur angegebenen Zeit wieder runter
* on-for-timer | off-for-timer
* dimup | dimdown ... schaltet den jeweiligen Ausgang nur so lange der Befehl gesendet wird
* reset ... setzt alle Programmierungen (Timer, FS20-Kanal) zurück

== Bekannte Probleme ==
Ein erneutes Aufrufen eines gerade durchgeführten "on" oder "off"-Befehls (auch als *-for-timer und egal ob per Schalter oder per Funk), führt zum Abschalten (Stop) des jeweiligen Ausganges. Work-around: dimup oder dimdown vor dem automatischen Verfahren.

== Links ==
* [https://web.archive.org/web/20140630103049/http://www.elv-downloads.de:80/service/manuals/FS20RSU/FS20RSU_UM_G_080430.pdf Bedienungsanleitung] im Internet Archiv, Original-Link nicht mehr erreichbar
* [https://web.archive.org/web/20110910222342/http://www.elv-downloads.de:80/service/manuals/FS20RSU_83557_km_um.pdf Bauanleitung für den Bausatz] im Internet Archiv, Original-Link nicht mehr erreichbar

[[Kategorie:FS20 Components|R]]
[[Kategorie:Schalter (Empfänger)]]
[[Kategorie:Rollladensteuerung]]

FS20 RSU-2 Funk-Rollladenaktor für Markenschalter

2018-05-07T07:54:44Z

Krokofant: /* Weblinks */ Kat

{{Infobox Hardware
|Bild=PlatzHalter.png
|Bildbeschreibung=FS20 RSU-2
|HWProtocol=FS20
|HWType=Aktor
|HWCategory=FS20
|HWComm=868 MHz
|HWChannels=1
|HWVoltage=230V
|HWPowerConsumption=<0,5W (Ruhebetrieb)
|HWPoweredBy=Netz
|HWSize=71x71x37mm
|HWDeviceFHEM=[http://fhem.de/commandref.html#FS20 10_FS20.pm]
|HWManufacturer=ELV / eQ-3
}}

[[FS20 RSU-2 Funk-Rollladenaktor für Markenschalter]] ist ein Funk-Aktor zur Steuerung von Rollläden, der als Unterputzgerät mit Abdeckungen von Markenschalter-Programmen verwendet werden kann.

== Features / Funktionen ==
Die Haupteigenschaften von XYZ sind
* a
* b
* c

== Hinweise zum Betrieb mit FHEM ==
Um das Gerät von FHEM ansprechen zu können wird/werden benötigt...
# ...

== Bekannte Probleme ==
Keine.

== Weblinks ==
* [http://files.elv.de/Assets/Produkte/13/1322/132222/Downloads/132222_fs20_rsu2_um.pdf Bedienungsanleitung] (ELV)

[[Kategorie:FS20 Components|R]]
[[Kategorie:Schalter (Empfänger)]]
[[Kategorie:Rollladensteuerung]]

FS20 RST Rollladensteuerung

2018-05-07T07:53:51Z

Krokofant: /* Links */ Kat

Einsteckbares Funkmodul; ermöglicht die Funk-Fernsteuerung kompatibler EcoRoll-Rollladenantriebe per FS20.

== Features ==
Aktor, wird in passende EcoRoll-Rollladenantriebe eingebaut und macht diese FS20-fähig

== Hinweise zum Betrieb mit FHEM ==
Einsetzbar.

Da der EcoRoll anhand der Gurtspannung bzw. des Rollwiderstands die Endpositionen der Rolllade selbst erkennt, muss man sich nicht per FHEM oder on-for-timer um die korrekte Ansteuerungszeit kümmern.

== Befehlssatz ==
on = Rollade wird bis komplett aufgefahren, oder - falls vorhanden - bis zur Höhe eines (beim EcoRoll beiligenden) Schattensensors, erneutes ON fährt auf.

off = Rollade wird geschlossen.

== Bekannte Probleme ==
Keine

== Links ==
* [http://www.elv-downloads.de:80/service/manuals/FS20RST/FS20RST_UM_G_030507.pdf Bedienungsanleitung] im Internet Archiv, Original-Link nicht mehr erreichbar

[[Kategorie:FS20 Components|R]]
[[Kategorie:Rollladensteuerung]]

FS20 RST Rollladensteuerung

2018-05-07T07:53:18Z

Krokofant: /* Links */

FS20 PIRA Infrarot-Bewegungsmelder

2018-05-06T22:08:54Z

Krokofant: /* Links */ Kat

{{Infobox Hardware
|Bild=FS20-PIRA.jpg
|Bildbeschreibung= FS20 PIRA mit Streichhölzern zum Größenvergleich
|HWProtocol=FS20
|HWType=Sensor
|HWCategory=FS20
|HWComm=868MHz
|HWChannels=2
|HWVoltage=3V
|HWPowerConsumption=ca. 1 Jahr bei 1000 x Senden täglich
|HWPoweredBy=Batterie
|HWSize=53x50x35mm
|HWDeviceFHEM=FS20

|HWManufacturer=ELV Elektronik AG
}}
Infrarot-Bewegungsmelder in kompakten Gehäuse, auch für Außeneinsatz geeignet.
= Features =
Wasserdichtes IP65-Gehäuse, das zum Betätigen der Tasten aufgeschraubt werden muss.
Im Innenbereich durch geringe Grösse unauffällig.

Features unterscheiden sich darüber hinaus kaum von anderen FS 20 Infrarot-Bewegungsmeldern, also 2 Sendekanäle, Dämmerungsautomatik, einstellbarer Sendeabstand etc.

Gerät ist vergleichsweise teuer.

= Hinweise zum Betrieb mit FHEM =
Es gibt Anzeichen dafür, dass die FS20PIRA besser empfangen werden, wenn das CUL/CUN auf 868.3 MHz und eine leicht erweiterte Bandbreite von bWidth:464KHz eingestellt sind.

Beim kürzesten einstellbaren Sendeintervall (8 Sekunden), provoziert der PIRA schnell [[LOVF]] Meldungen in FHEM , wenn jede Bewegung in FHEM eine Aktion auslöst, die ihrerseits einen Sendebefehl beinhaltet. Im schlimmsten Fall ist das Sendekontingent einer Stunde nach 22 Minuten verbraucht, bei Aussendung von 2 Befehlen je Bewegung sogar schon nach 11 Minuten.

= Bekannte Probleme =
Die benötigten 2 x Batterien "Lady" LR1/HR1/E90 sind schwer zu beschaffen und teuer, da unübliche Grösse (keine Mignon oder Micro).
Jedoch: Lebensdauer auch bei 30 Auslösungen pro Tag mehrere Jahre.

Wie bei allen Geräten im 868 Mhz Band gilt die [[1%_Regel]] auch für Bewegungsmelder. Der FS20 PIRA gestattet als kürzesten Sendeabstand 8 Sekunden. Kommt es in einem Raum (in dem sich ständig Personen aufhalten und bewegen) tatsächlich zu einer Auslösung alle 8 Sekunden, ist das Sendekontigent des PIRA einer ganzen Stunde nach 22 Minuten aufgebraucht und danach wird der Bewegungsmelder für den Rest der Stunde nicht mehr senden. Daher sollte immer ein möglichst langer Sendeabstand eingestellt werden.

= Links =
* [https://web.archive.org/web/20100415071131/http://www.elv-downloads.de/service/manuals/FS20PIRA/66818_um.pdf Bedienungsanleitung] im Internet Archiv, Original-Link nicht mehr erreichbar

[[Kategorie:FS20 Components|P]]
[[Kategorie:Bewegungs- und Anwesenheitsmelder]]

FS20 MS Markisensteuerung

2018-05-06T22:07:54Z

Krokofant: /* Links */ Link war nicht erreichbar, auf archive.org umgebogen, Kat

{{Infobox Hardware
|Bild=Fs20Ms.jpg
|Bildbeschreibung=FS20 MS - Markisensteuerung
|HWProtocol=FS20
|HWType=Aktor
|HWCategory=FS20
|HWComm=868 MHz
|HWChannels=1
|HWVoltage=230V
|HWPowerConsumption=?
|HWPoweredBy=Netz
|HWSize=160x55x80mm
|HWDeviceFHEM=[http://fhem.de/commandref.html#FS20 10_FS20.pm]
|HWManufacturer=Conrad / ELV / eQ-3
}}

[[FS20 MS Markisensteuerung]] ein einkanaliger Funk-Rollladenaktor zur Aufputzmontage.

== Features ==
Markisen-/Rollladenaktor in Aufputzgehäuse, Ausführung "IP65 spritzwassergeschützt".

Funktionalität vergleichbar mit [[FS20 RSU Rollladenschalter (Unterputz)]].

== Hinweise zum Betrieb mit FHEM ==
Einsetzbar

== Befehlssatz ==
...

== Bekannte Probleme ==
Keine.

== Sonstiges ==
Dieses Gerät wird offensichtlich (Stand: Juni 2014) nicht mehr hergestellt.

== Links ==
* [https://web.archive.org/web/20100415071131/https://web.archive.org/web/20130612145109/http://www.elv-downloads.de:80/service/manuals/FS20MS-2/FS20MS-2_UM_G_040211.pdf Bedienungsanleitung] im Internet Archiv, Original-Link nicht mehr erreichbar
[[Kategorie:FS20 Components|M]]
[[Kategorie:Schalter (Empfänger)]]
[[Kategorie:Rollladensteuerung]]

FS20 KSE KlingelSignal-Erkennung

2018-05-06T22:04:02Z

Krokofant: /* Links */ Kat

KlingelSignal-Erkennung 2 Kanal

== Features ==
Das Bauteil FS20 KSE reagiert auf das Anliegen der Spannung an der Haustürklingel. Neben der Haustürklingel können auch andere Spannungen zum Auslösen des Schaltvorgangs genutzt werden. Besonders flexibel ist die Schaltung bezüglich der Spannungsversorgung, da in vielen Anwendungsfällen das Klingelsignal bereits direkt zur Spannungsversorgung der Schaltung genutzt werden kann.

Sobald am Klingeleingang eine Gleichspannung zwischen 5 V und 16 V oder eine Wechselspannung zwischen 4,5 V und 11 V angelegt wird, sendet die FS20 KSE den Einschaltbefehl. Mit dem Abfallen der Klingelspannung wird entweder sofort oder nach einer Verzögerung das Ausschaltsignal gesendet. Bereits ein kurzer Spannungsimpuls von ca. 0,5 bis 1 Sekunde liefert genügend Energie für die Ein- und Ausschaltbefehle. Die Konfiguration des Gerätes kann getrennt auf zwei FS20-Sendekanälen erfolgen.

Die Platine ist recht klein - Lieferung ohne Gehäuse.

== Hinweise zum Betrieb mit FHEM ==
Einsetzbar

== Links ==
* Bedienungsanleitung [https://files.elv.com/service/manuals/FS20KSE/FS20KSE_UM_G_071227.pdf PDF]

[[Kategorie:FS20 Components|K]]
[[Kategorie:Schalter (Sender)]]

FS20 KSE KlingelSignal-Erkennung

2018-05-06T22:03:32Z

Krokofant: /* Links */ Kat

FS20 IRF Infrarot-Fernbedienung

2018-05-06T22:02:13Z

Krokofant: /* Links */ Link war nicht erreichbar, auf archive.org umgebogen, Kat

FS20 IRF ist eine lernfähige Infrarot-Fernbedienung. Auf jedem der 16 Speicherplätze kann eine Sequenz von ein bis fünf IR-Befehlen von der/den Original-Fernbedienung(en) angelernt werden. Jeder Speicherplatz kann als FS20-Kanal definiert und damit separat angesprochen werden.
== Features ==
Aktor / Receiver

Bei Empfang eines FS20-'on' sendet FS20 IRF die zugehörige angelernte Infrarot-Sequenz. Damit können beliebige über IR bedienbare Geräte gesteuert werden.

Einige Anwendungsbeispiele sind in der Bedienungsanleitung dargestellt.

== Hinweise zum Betrieb mit FHEM ==
Einsetzbar

== Bekannte Probleme ==
keine

== Links ==
* [https://web.archive.org/web/20111215164854/http://www.elv-downloads.de/Assets/Produkte/8/858/85811/Downloads/85811_FS20IRF_KM_um.pdf Bedienungsanleitung] im Internet Archiv, Original-Link nicht mehr erreichbar

[[Kategorie:FS20 Components|I]]
[[Kategorie:Schalter (Empfänger)]]

FS20 IRB Internetradio

2018-05-06T21:58:55Z

Krokofant: /* Links */ Kat

= Features =
The ELV Internetradio FS20 IRB is an Internetradio that can be controlled wirelessly with any FS20 transmitter.
It has Ethernet connectivity and includes a stereo 1.5W at 8 Ohm amplifier.
Power consumption is 100 mA up to 1,5 A depending on volume when switched on.
An external power supply with 4,5–5,5 V DC is required.
It can be switched on via FS20. LAN wakeup is not supported.
Line-out with a standard 3.5 mm TRS connector (audio jack)is included.
It includes a webserver that allows to control all functions including switching to next sender or favorite sender, volume, mute, bass, and treble.
There is no display on the device. The IRB has two buttons, for FS20 learn mode and to reset to manufacturing settings.
A maximum of up to 4096 livestream adresses can be stored in one sender list.
The sender list can also include direct links to a MP3 file on any webserver.
Playing modes: Internetradio and MP3-Player favorit and random.
Sender lists can be imported and exported using any webserver.
Configuration data is persistently stored in a flash.
Network TCP/IP address is static or dynamic via DHCP.

= Known limitations =
* A maximum of up to 4096 livestream adresses can be stored in one sender list.
* MP3 bit rate is limited to approx. 192kbit/s.
* Playing directories of MP3 files is not supported.
* There is no documented API but it supports passing variables with forms using PHP.
* Home page is German only.
= Webserver API =
There is no documented API but it supports passing variables with forms using PHP.
A blog entry by Maximilian Roth (see below) describes the variables and how to control the IRB using curl.
After switch on the IRB via FS20 its webserver can be used e.g to switch on or off the amplifier:

<nowiki>curl --data-urlencode btnAmplifierSwitch=Einschalten -s -k 'http://192.168.2.9/index.htm'
curl --data-urlencode btnAmplifierSwitch=Ausschalten -s -k 'http://192.168.2.9/index.htm'</nowiki>
Explanation:
Variable btnAmplifierSwitch is set to e.g. Einschalten.
The page URL is specified in quotes.
Hint: Display IRB pages in source mode to find out variables and values.

== IRB home page ==
<IP_address>/index.htm is the URL of the IRB home page.

* Select playing mode: Internetradio, MP3-Player, MP3-Player (Favorit), MP3-Player (Random), MP3-Player (Favorit, Random)
* Switching to next sender or favorite sender, volume, mute, bass, and treble.
== IRB configuration page ==
<IP_address>/config.htm is the URL of the IRB configuration page.

* Admin password
* Network configuration including static IP address, subnet ID, DHCP, gateway, DNS-Server, and NetBIOS-Name.
== IRB sender page ==
<IP_address>/stations.htm is the URL of the IRB sender page.

* Displays the sender list
* Exports or imports sender lists from any webserver.
* Senders can be selected, deleted, and edited.
* After selecting a sender for editing the sender address and display name can be changed and a sender can be defines as favorite.
= Usage Scenarios =
* Playing internet radio or MP3 files controlled wirelessly with any FS20 remote or internet browser.
* The internet radio can be switched on automatically when a person is detected by a FS20 sensor like the PIRA or PIRI infrared sensors.
* Using FHEM the internet radio can be switched on via timers e.g. to simulate presence.
* Using FHEM the internet radio can be switched to play MP3s (barking dogs, voices) to simulate presence.
= FS20 setup =
press FS20 learn mode button for ca. 5s until the control LED starts blinking.
The first received FS20 signal determines house code and button for switching the device on.
The subsequent orders are implicitely defined by increasing the channel number

== FS20 buttons ==
16 FS20 buttons are supported: On, off, Volume +/-, list +/-, favorite +/-, and 8 station presets.

== Definition in FHEM ==
In fhem.conf the Internetradio FS20 IRB is defined as follows:

<nowiki>define <name> FS20 <house code> <button></nowiki>
Optional kann als Attribut noch das Model angegeben werden:

<nowiki>attr <name> model fs20st</nowiki>
Example:

<nowiki># FS20 Internet Radio IRB
define Radio_ON FS20 ec70 00
define Radio_Volume FS20 ec70 01
define Radio_List FS20 ec70 02
define Radio_Favoriten FS20 ec70 03
define Radio_Channel_1_2 FS20 ec70 04
define Radio_Channel_3_4 FS20 ec70 05
attr Radio_ON room Radio
attr Radio_Volume room Radio
attr Radio_List room Radio
attr Radio_Favoriten room Radio
attr Radio_Channel_1_2 room Radio
attr Radio_Channel_3_4 room Radio</nowiki>
To setup the IRB FS20 address put the unit in programming mode (see above)and use FHEM to send the on order:

<nowiki>set Radio_ON on</nowiki>
The LED on the URB now stops blinking and the IRB is set to the chosen house code and button.
The IRB can now be switched on and off using

<nowiki>set Radio_ON on
set Radio_ON off</nowiki>
or via the webinterface of fhem.

== Known problems ==
none

== Links ==
* user manual (no link available)
* Seller [http://www.elv.de/elv-fs20-internet-radio-box-fs20-irb-komplettbausatz.html]
* IRB project blog entry by Maximilian Roth [http://maximilian-roth.de/?p=413]

[[Kategorie:Unterhaltungselektronik]]
[[Kategorie:FS20 Components|I]]

FS20 HGS Funk-Hygrostat

2018-05-06T18:13:52Z

Krokofant: /* Links */ Kat

{{Infobox Hardware
|Bild=FS20HGS.jpeg
|Bildbeschreibung=FS20 HGS - Funk-Hygrostat
|HWProtocol=FS20
|HWType=Sender
|HWCategory=FS20
|HWComm=868MHz
|HWChannels=1
|HWVoltage=3V
|HWPowerConsumption=(2 Jahre)
|HWPoweredBy=Batterie, 2xLR6
|HWSize=80x103x23mm
|HWDeviceFHEM=FS20
|HWManufacturer=ELV / eq3
}}
== Features ==
Der FS20 HGS dient der Ermittlung von Luftfeuchtigkeits- und Temperaturwerten, er wertet einstellbare Luftfeuchtigkeitsgrenzen aus und schaltet bei Über- bzw. Unterschreiten dieser Grenzen per Funk einen beliebigen Empfänger der FS20-Reihe.

Features unterscheiden sich darüber hinaus kaum von anderen FS 20 Sendern.

== Hinweise zum Betrieb mit FHEM ==
Die Temperatur- und Feuchtedaten sind nicht für FHEM verfügbar. Diese Werte werden nur intern im Gerät gehalten und für das Absetzen des Ein-/Ausschaltsignals verwendet.

== Bekannte Probleme ==
Keine.

== Readings ==
ON, OFF

== Links ==
* Bedienungsanleitung (PDF {{DocLink|elv|/service/manuals/FS20HGS/FS20HGS_UM_G_051114.pdf}})

[[Kategorie:FS20 Components|H]]

FS20 FMS Funk-Master-Slave

2018-05-06T18:12:19Z

Krokofant: /* Links */ Link war nicht erreichbar, auf archive.org umgebogen

== Features ==
Der FS20 FMS ist ein Schutzkontaktzwischenstecker zur Ermittlung von Strömen, er wertet einstellbare Ansprechschwellen aus und schaltet bei Über- bzw. Unterschreiten dieser Grenzen per Funk einen beliebigen Empfänger der FS20-Reihe.

Features unterscheiden sich darüber hinaus kaum von anderen FS 20 Sendern.

*Standby-Verbrauch: 32 mA = 7,4 W !!!
*Kleinste Ansprechschwelle: 20 mA = 4,6 W

== Hinweise zum Betrieb mit FHEM ==
keine

== Readings ==
ON,OFF

== Bekannte Probleme ==
keine

== Links ==
* [https://web.archive.org/web/20140513151026/http://www.elv-downloads.de:80/service/manuals/FS20FMS/61089_um.pdf Bedienungsanleitung] im Internet Archiv, Original-Link nicht mehr erreichbar

[[Kategorie:FS20 Components|F]]
[[Kategorie:Schalter (Sender)]]

FS20 ES1 Erschütterungssensor

2018-05-06T18:09:50Z

Krokofant: /* Links */ Kat

{{Infobox Hardware
|Bild=PlatzHalter.png
|Bildbeschreibung=Front, Rückseite, Platine (Bestückungsseite)
|HWProtocol=FS20
|HWType=Sensor
|HWCategory=FS20
|HWComm=868MHz
|HWChannels=2
|HWVoltage=3V
|HWPowerConsumption=??
|HWPoweredBy=1x CR 2450
|HWSize=90 x 40 x 24 mm
|HWDeviceFHEM=[[FS20]]
|HWManufacturer=ELV / eQ-3
}}

[[FS20 ES1 Erschütterungssensor]] ist batteriebetriebener Erschütterungssensor aus der [[FS20 Allgemein|FS20]] Produktfamilie für den Betrieb in geschlossenen Räumen.

== Features ==
FS20 ES1 reagiert auf Erschütterungen und sendet im Auslösefall auf zwei Kanälen (Kanäle können auf '''inaktiv''' gesetzt werden) einen konfigurierbaren Funkbefehl ab.

Einstellbare Parameter sind:
* Hauscode
* Adressen (2 Kanäle)
* Sendebefehl bei Auslösung (unterschiedlich für Kanal 1 und Kanal 2)
* Einschaltdauer (gilt für beide Kanäle)
* Sendeabstand: Mindestzeitdauer zwischen zwei Auslösungen (gilt für beide Kanäle)
* Empfindlichkeit (gilt für beide Kanäle)

Die Empfindlichkeit wird zusätzlich noch durch die Montageposition beeinflusst (sehr empfindlich, wenn die LED oben ist).

== Hinweise zum Betrieb mit FHEM ==
FS20 ES1 wird ([[autocreate]] vorausgesetzt) von FHEM automatisch erkannt, wobei das Modell nicht gesondert definiert ist. Es sollte sinnvollerweise auf den Wert ''dummySender'' gesetzt werden mit dem Befehl
:<code>attr <nowiki><meinES1></nowiki> model dummySender</code>
oder über die entsprechende Auswahlliste im [[FHEMWEB|Webinterface]].

=== Definition ===
Siehe {{Link2CmdRef|Anker=FS20define}}.

== Bekannte Probleme / Einschränkungen ==
* Obwohl als "reagiert auf Neigung" beschrieben: der Sensor reagiert nur auf Lage'''veränderung''' und gibt keinerlei Informationen über die aktuelle Neigung des Geräts wider
* Programmierung / Einstellung nur über die Tasten am Gerät (kann nicht mit dem FS20 IRP konfiguriert werden)

== Links ==
* [http://files.elv.de/Assets/Produkte/8/858/85800/Downloads/85800_FS20ES1_d_UM.pdf Bedienungsanleitung] (ELV)

[[Kategorie:FS20 Components|E]]
[[Kategorie:Neigungssensor]]

FS20 DU Unterputz Dimmer

2018-05-06T18:08:09Z

Krokofant: /* Bekannten Probleme */ typo

= FS20DU Unterputz Dimmer =
Kurzbeschreibung

== Features ==
Aktor oder Sender

== Hinweise zum Betrieb mit FHEM ==
Einsetzbar

== Bekannte Probleme ==
keine

== Links ==
* [https://files.elv.com/service/manuals/FS20DU/FS20DU_UM_G_060510.pdf Bedienungsanleitung FS20 DU]
* [https://files.elv.com/Assets/Produkte/8/852/85282/Downloads/85282-FS20DU-2_um_web.pdf Bedienungsanleitung FS20 DU-2, Phasenanschnitt]
[[Kategorie:FS20 Components|D]]
[[Kategorie:Dimmer]]

FS20 DU Unterputz Dimmer

2018-05-06T18:07:54Z

Krokofant: /* Links */ 2x Links, Kat

= FS20DU Unterputz Dimmer =
Kurzbeschreibung

== Features ==
Aktor oder Sender

== Hinweise zum Betrieb mit FHEM ==
Einsetzbar

== Bekannten Probleme ==
keine

== Links ==
* [https://files.elv.com/service/manuals/FS20DU/FS20DU_UM_G_060510.pdf Bedienungsanleitung FS20 DU]
* [https://files.elv.com/Assets/Produkte/8/852/85282/Downloads/85282-FS20DU-2_um_web.pdf Bedienungsanleitung FS20 DU-2, Phasenanschnitt]
[[Kategorie:FS20 Components|D]]
[[Kategorie:Dimmer]]

FS20 DT Diagnosetool

2018-05-06T18:04:43Z

Krokofant: /* Bekannte Probleme */ Abschnitt Links und Bedienungsanleitung hinzugefügt

Gerät, mit dem im Nahbereich Hauscode und Kanalbelegung eines FS20 Senders ermittelt werden können.
== Eigenschaften ==
Das FS20 DT ist ein FS20 Empfänger mit absichtlich niedriger Empfangsempfindlichkeit, der Signale von FS20 Sendern nur empfangen kann, wenn er unmittelbar an das sendende Gerät gehalten wird (rechte Seite des FS20 DT 1-10 Zentimeter vom Sender entfernt).

Das FS20 DT zeigt in einem Display Hauscode und eingestellte Adresse des Senders an und eignet sich daher z.B. für die Ermittlung falsch eingestellter Sender. Betrieb mit 9 Volt Block.

== Hinweise zum Betrieb mit FHEM ==
Das Tool kann auch in einer FHEM Umgebung sinnvoll eingesetzt werden, da Signale aufgrund der geringen Empfangsempfindlichkeit des Diagnosetools leichter einem bestimmten Sender zugeordnet werden können. Signale eines CUL werden jedoch meist nicht korrekt erkannt.

== Bekannte Probleme ==
Da der Einschalter ein sehr leichtgängiger Taster auf der Oberseite ist, wird das Gerät gerne unbeabsichtigt (z.B. beim Wegräumen) eingeschaltet, die Batterie ist dann in wenigen Tagen leer.

== Links ==
* [https://files.elv.com/service/manuals/FS20DT/66813_um.pdf Bedienungsanleitung]

[[Kategorie:FS20 Components|D]]

FS20 DT Diagnosetool

2018-05-06T18:00:09Z

Krokofant: /* Links */ Leeren Abschnitt entfernt, Kat

FS20

2018-05-06T17:59:04Z

Krokofant: Leeren Abschnitt entfernt, Kat

{{Infobox Modul
|ModPurpose=Unterstützung der FS20 Produktfamilie
|ModType=d
|ModForumArea=SlowRF
|ModTechName=10_FS20.pm
|ModOwner=rudolfkoenig ({{Link2FU|8|Forum}}) / [[Benutzer Diskussion:Rudolfkoenig|Wiki]])
}}

[[FS20]] ist das Basismodul für die Unterstützung der [[FS20 Allgemein|FS20]] [[:Kategorie:FS20 Components|Produktfamilie]].

== Voraussetzungen ==
Am FHEM Server muss ein [[Interface]] für das FS20 Protokoll ("SlowRF", FHZ oder [[CUL]]) installiert sein.

== Anwendung ==
=== Define ===
Siehe {{Link2CmdRef|Anker=FS20define}}.

=== Attribute ===
Siehe {{Link2CmdRef|Anker=FS20attr}}.

=== Internals ===
FS20 Devices erhalten unter bestimmten Umständen ''Internals'' mit den Namen <IODevName>''_MSGCNT'', <IODevName>''_RAWMSG'', <IODevName>''_RSSI'' und <IODevName>''_TIME''. Diese Internals werden nur gesetzt, wenn das IODevice eine Nachricht mit der Adresse des FS20 Devices '''empfangen''' hat. Da FS20 Geräte unidirektional sind, werden von Aktoren (z.B. [[FS20 RSU Rollladenschalter (Unterputz)|RSU]]) keine Nachrichten '''geschickt'''. Trotzdem können bei derartigen Geräten die genannten Internals auftauchen - nämlich dann, wenn der Aktor beispielsweise durch einen Wand- oder Handsender direkt geschaltet wird. In diesen Fällen reflektiert aber dann der _RSSI-Wert nicht die Qualität der Signalverbindung zwischen IODevice/FHEM und dem Aktor, sondern zwischen FHEM und dem Sender!

== Anwendungsbeispiele ==

[[Kategorie:FS20 Components|!]]

FS20 DI Steckdosendimmer

2018-05-06T17:58:20Z

Krokofant: /* Links */ Kat

Steckdosenfunkdimmer
== Features ==
Funkdimmer als Zwischenstecker. Auf der Oberseite befindet sich ein Taster. Wird dieser beim Einstecken in eine Steckdose gedrückt gehalten, so befindet sich das Gerät im Programmiermodus: Die Kontoll-LED blinkt. Der erste empfangene Befehl bestimmt Hauscode und Kanaleinstellung des Schalters. Eingebaute Timer Funktion: automatische Abschaltung nach 1 Sek. bis 4,25 Stunden einstellbar. Schaltleistung 16 A.

Zusätzlich zu den Befehlen 'on' und 'off' sowie timer-Befehlen beherrscht FS20-DI auch alle Dimm-Befehle. Der Gesamtbefehlssatz steht in der [http://fhem.de/commandref.html#FS20 commandsref] im Abschnitt 'Set'.

== Hinweise zum Betrieb mit FHEM ==
Einsetzbar

== Bekannte Probleme ==
keine

== Links ==
* [https://web.archive.org/web/20140327065342/http://www.elv-downloads.de:80/service/manuals/FS20DI3/57787_UM.pdf Bedienungsanleitung] im Internet Archiv, Original-Link nicht mehr erreichbar

[[Kategorie:FS20 Components|D]]
[[Kategorie:Dimmer]]

FS20 BS Beschattungssteuerung

2018-05-06T17:57:52Z

Krokofant: /* Links */ Kat

{{Infobox Hardware
|Bild=PlatzHalter.png
|Bildbeschreibung=FS20 BS - Funk-Beschattungssteuerung
|HWProtocol=FS20
|HWType=Sensor, Sender
|HWCategory=FS20
|HWComm=868 MHz
|HWChannels=1
|HWVoltage=3V
|HWPowerConsumption=nicht bekannt
|HWPoweredBy=2xMicro (LR03/AAA)
|HWSize=26x119x17mm (Steuereinheit)
|HWDeviceFHEM=[http://fhem.de/commandref.html#FS20 10_FS20.pm]
|HWManufacturer=ELV / eQ-3
}}

Die [[FS20 BS Beschattungssteuerung]] ist ein Helligkeitssensor, der über die mit einem Kabel verbundene Steuereinheit FS20 Telegramme absetzen kann. FS20 BS ist für die direkte Verknüpfung mit [[FS20 RSU Rollladenschalter (Unterputz)|FS20RSU]] oder [[FS20 MS Markisensteuerung|FS20MS]] ausgelegt.

== Features ==
* Helligkeitssensor + Schalter (Sender)
* zwei Betriebsmodi:
** Modus 1 (einfache Steuerung): Rollo fährt bis über den Sensor und dann wieder soweit zurück, dass der Sensor nicht mehr abgedeckt ist
** Modus 2 (Positionssteuerung): Rollo wird um vorher festgelegte Zeitdauer aus-/eingefahren
* zwei Helligkeits-Schwellenwerte sind einstellbar:
** maximale Helligkeit (bei Überschreiten sollen die Rollläden heruntergefahren werden)
** minimale Helligkeit (bei Unterschreiten sollen die Rollläden heraufgefahren werden)

== Hinweise zum Betrieb mit FHEM ==
Einsetzbar.

Da die FS20 BS "eigentlich" die vollständige Kontrolle über die Steuerung des Rollladen übernimmt, sollte sie für einen Betrieb mit FHEM '''nicht''' mit dem Aktor direkt verknüpft werden (es sollte also am FS20 BS nicht die Adresse des Aktors eingestellt werden).

Weitere Informationen für die Anwendung des FS20 BS finden sich in [[Rolladensteuerung mit fs20rsu und fs20bs]].

== Befehlssatz ==
FS20 BS sendet je nach eingestelltem Modus die Befehle
* off 2.5
* on 2
* ...

== Bekannte Probleme ==
Keine.

== Links ==
* [https://web.archive.org/web/20090806190027/http://www.elv-downloads.de:80/service/manuals/84394_FS20BS_um_web.pdf Bedienungsanleitung] im Internet Archiv, Original-Link nicht mehr erreichbar

[[Kategorie:FS20 Components|B]]
[[Kategorie:Schalter (Sender)]]
[[Kategorie:Lichtsensoren]]
[[Kategorie:Rollladensteuerung]]

FS20 AS1 1-Kanal Funk Aufputzschalter

2018-05-06T17:57:19Z

Krokofant: /* Links */ Kat

[[Bild:FS20AS1.jpg|thumb|right|FS20 AS1 - 1-Kanal Funk Aufputzschalter]]
'''FS20 AS1''' ist ein einkanaliger Funk-Aufputzschalter.

== Features ==
Aktor in wetterfestem Gehäuse; verfügt über galvanisch vom Stromnetz getrenntes potentialfreis Relais und eignet sich daher auch für das Schalten von Niederspannungen, also z.b. Halogen 12 Volt Anlagen oder Torsteuerungen. Programmierbarer Abschalttimer von 1 Sekunde bis 4,5 Stunden.

== Hinweise zum Betrieb mit FHEM ==
Einsetzbar

== Bekannte Probleme ==
Betätigen des Programiertasters erfordert Abschrauben des wasserdichten Deckels. Schalten am FS20 AS1 selbst ist daher im Normalzustand nicht möglich.

== Links ==
* [https://web.archive.org/web/20120831223247/http://www.elv-downloads.de/Assets/Produkte/10/1036/103605/Downloads/103605_FS20AS1_2_UM_.pdf Bedienungsanleitung] im Internet Archiv, Original-Link nicht mehr erreichbar

[[Kategorie:FS20 Components|A]]
[[Kategorie:Schalter (Empfänger)]]

FS20 DI Steckdosendimmer

2018-05-06T17:56:25Z

Krokofant: /* Links */ Link war nicht erreichbar, auf archive.org umgebogen

FS20 BS Beschattungssteuerung

2018-05-06T17:54:44Z

Krokofant: /* Links */ Link war nicht erreichbar, auf archive.org umgebogen

{{Infobox Hardware
|Bild=PlatzHalter.png
|Bildbeschreibung=FS20 BS - Funk-Beschattungssteuerung
|HWProtocol=FS20
|HWType=Sensor, Sender
|HWCategory=FS20
|HWComm=868 MHz
|HWChannels=1
|HWVoltage=3V
|HWPowerConsumption=nicht bekannt
|HWPoweredBy=2xMicro (LR03/AAA)
|HWSize=26x119x17mm (Steuereinheit)
|HWDeviceFHEM=[http://fhem.de/commandref.html#FS20 10_FS20.pm]
|HWManufacturer=ELV / eQ-3
}}

Die [[FS20 BS Beschattungssteuerung]] ist ein Helligkeitssensor, der über die mit einem Kabel verbundene Steuereinheit FS20 Telegramme absetzen kann. FS20 BS ist für die direkte Verknüpfung mit [[FS20 RSU Rollladenschalter (Unterputz)|FS20RSU]] oder [[FS20 MS Markisensteuerung|FS20MS]] ausgelegt.

== Features ==
* Helligkeitssensor + Schalter (Sender)
* zwei Betriebsmodi:
** Modus 1 (einfache Steuerung): Rollo fährt bis über den Sensor und dann wieder soweit zurück, dass der Sensor nicht mehr abgedeckt ist
** Modus 2 (Positionssteuerung): Rollo wird um vorher festgelegte Zeitdauer aus-/eingefahren
* zwei Helligkeits-Schwellenwerte sind einstellbar:
** maximale Helligkeit (bei Überschreiten sollen die Rollläden heruntergefahren werden)
** minimale Helligkeit (bei Unterschreiten sollen die Rollläden heraufgefahren werden)

== Hinweise zum Betrieb mit FHEM ==
Einsetzbar.

Da die FS20 BS "eigentlich" die vollständige Kontrolle über die Steuerung des Rollladen übernimmt, sollte sie für einen Betrieb mit FHEM '''nicht''' mit dem Aktor direkt verknüpft werden (es sollte also am FS20 BS nicht die Adresse des Aktors eingestellt werden).

Weitere Informationen für die Anwendung des FS20 BS finden sich in [[Rolladensteuerung mit fs20rsu und fs20bs]].

== Befehlssatz ==
FS20 BS sendet je nach eingestelltem Modus die Befehle
* off 2.5
* on 2
* ...

== Bekannte Probleme ==
Keine.

== Links ==
* [https://web.archive.org/web/20090806190027/http://www.elv-downloads.de:80/service/manuals/84394_FS20BS_um_web.pdf Bedienungsanleitung] im Internet Archiv, Original-Link nicht mehr erreichbar

[[Kategorie:FS20 Components]]
[[Kategorie:Schalter (Sender)]]
[[Kategorie:Lichtsensoren]]
[[Kategorie:Rollladensteuerung]]

FS20 AS1 1-Kanal Funk Aufputzschalter

2018-05-06T17:52:56Z

Krokofant: Link umgebogen auf Archive.org

FS20 PIRA Infrarot-Bewegungsmelder

2018-05-06T17:47:43Z

Krokofant: +Bild, Infobox

Datei:FS20-PIRA.jpg

2018-05-06T17:33:37Z

Krokofant: Selbst erstellt, Streichholzschachtel zum Größenvergleich

Selbst erstellt, Streichholzschachtel zum Größenvergleich

FS20 ST Steckdosenfunkschalter

2018-05-04T18:44:27Z

Krokofant: Formatierung

= Features =
Funkschalter als Zwischenstecker. Auf der Oberseite befindet sich ein Taster. Wird dieser beim Einstecken in eine Steckdose gedrückt gehalten, so befindet sich das Gerät im Programmiermodus: Die Kontoll-LED blinkt. Der erste empfangene Befehl bestimmt Hauscode und Kanaleinstellung des Schalters. Eingebaute Timer Funktion: automatische Abschaltung nach 1 Sek. bis 4,25 Stunden einstellbar. Schaltleistung 16 A.

= Hinweise zum Betrieb mit FHEM =
In der fhem.conf wird der Funkschalter (wie alle Aktoren) folgendermaßen definiert:

<nowiki>define <name> FS20 <Hauscode> <Gerätecode></nowiki>
Optional kann als Attribut noch das Model angegeben werden:

<nowiki>attr <name> model fs20st</nowiki>
Diese Angabe hat keinen funktionalen Charakter. Die Information wird in FHEM nicht ausgewertet, kann jedoch in Webinterfaces etc. als ordnendes Element verwendet werden, von externen Programmen ausgewertet werden beziehungsweise dient der besseren Lesbarkeit.

Beispiel:

<nowiki>define Schalter1 FS20 7491 54
attr Schalter1 model fs20st</nowiki>
Um den Schalter mit FHEM zu verbinden, muss nun der Schalter in den Programmiermodus versetzt (s.o.) und mit FHEM ein Befehl an den Schalter gesendet werden. Z.B..:

<nowiki>set Schalter1 on</nowiki>
Die LED am Schalter hört nun auf zu blinken und das Gerät ist auf den gewählten Haus- und Gerätecode programmiert. Der Schalter lässt sich nun mit

<nowiki>set Schalter1 on
set Schalter1 off</nowiki>
oder über das Webinterface von FHEM an- und ausschalten.

= Befehlssatz =
fs20-st beherrscht neben den Befehlen 'on' und 'off' auch timer-Befehle, siehe Abschnitt FS20 'Set' in der {{Link2CmdRef|Anker=FS20set}}.

Die dort genannten Dimm-Befehle beherrscht fs20-st nicht, hierfür wird ein Dimmer wie z.B. [http://fhemwiki.de/index.php/FS20_DI fs20-di] benötigt.

= Bekannte Probleme =
keine

= Links =
* [https://web.archive.org/web/20121021125321/http://www.elv-downloads.de:80/service/manuals/85286_FS20ST3V1_um.pdf Bedienungsanleitung] im Internet Archiv, Original-Link nicht mehr erreichbar
* Umbau zur Aufputz-Variante [[FS20 ST Funkschalter modifizieren]]

[[Kategorie:FS20 Components]]
[[Kategorie:Schalter (Empfänger)]]

FS20 ST Steckdosenfunkschalter

2018-05-04T18:43:46Z

Krokofant: Link nicht mehr erreichbar, umgebogen auf archive.org

= Features =
Funkschalter als Zwischenstecker. Auf der Oberseite befindet sich ein Taster. Wird dieser beim Einstecken in eine Steckdose gedrückt gehalten, so befindet sich das Gerät im Programmiermodus: Die Kontoll-LED blinkt. Der erste empfangene Befehl bestimmt Hauscode und Kanaleinstellung des Schalters. Eingebaute Timer Funktion: automatische Abschaltung nach 1 Sek. bis 4,25 Stunden einstellbar. Schaltleistung 16 A.

= Hinweise zum Betrieb mit FHEM =
In der fhem.conf wird der Funkschalter (wie alle Aktoren) folgendermaßen definiert:

<nowiki>define <name> FS20 <Hauscode> <Gerätecode></nowiki>
Optional kann als Attribut noch das Model angegeben werden:

<nowiki>attr <name> model fs20st</nowiki>
Diese Angabe hat keinen funktionalen Charakter. Die Information wird in FHEM nicht ausgewertet, kann jedoch in Webinterfaces etc. als ordnendes Element verwendet werden, von externen Programmen ausgewertet werden beziehungsweise dient der besseren Lesbarkeit.

Beispiel:

<nowiki>define Schalter1 FS20 7491 54
attr Schalter1 model fs20st</nowiki>
Um den Schalter mit FHEM zu verbinden, muss nun der Schalter in den Programmiermodus versetzt (s.o.) und mit FHEM ein Befehl an den Schalter gesendet werden. Z.B..:

<nowiki>set Schalter1 on</nowiki>
Die LED am Schalter hört nun auf zu blinken und das Gerät ist auf den gewählten Haus- und Gerätecode programmiert. Der Schalter lässt sich nun mit

<nowiki>set Schalter1 on
set Schalter1 off</nowiki>
oder über das Webinterface von FHEM an- und ausschalten.

= Befehlssatz =
fs20-st beherrscht neben den Befehlen 'on' und 'off' auch timer-Befehle, siehe Abschnitt FS20 'Set' in der {{Link2CmdRef|Anker=FS20set}}.

Die dort genannten Dimm-Befehle beherrscht fs20-st nicht, hierfür wird ein Dimmer wie z.B. [http://fhemwiki.de/index.php/FS20_DI fs20-di] benötigt.

= Bekannte Probleme =
keine

= Links =
* [https://web.archive.org/web/20121021125321/http://www.elv-downloads.de:80/service/manuals/85286_FS20ST3V1_um.pdf Bedienungsanleitung im Internet Archiv, Original-Link nicht mehr erreichbar]
* Umbau zur Aufputz-Variante [[FS20 ST Funkschalter modifizieren]]

[[Kategorie:FS20 Components]]
[[Kategorie:Schalter (Empfänger)]]

FS20 PIRA Infrarot-Bewegungsmelder

2018-05-04T17:54:49Z

Krokofant: Link war nicht mehr erreichbar, auf archive.org umgebogen

Infrarot-Bewegungsmelder in kompakten Gehäuse, auch für Außeneinsatz geeignet.
= Features =
Wasserdichtes IP65-Gehäuse, das zum Betätigen der Tasten aufgeschraubt werden muss.
Im Innenbereich durch geringe Grösse unauffällig.

Features unterscheiden sich darüber hinaus kaum von anderen FS 20 Infrarot-Bewegungsmeldern, also 2 Sendekanäle, Dämmerungsautomatik, einstellbarer Sendeabstand etc.

Gerät ist vergleichsweise teuer.

= Hinweise zum Betrieb mit FHEM =
Es gibt Anzeichen dafür, dass die FS20PIRA besser empfangen werden, wenn das CUL/CUN auf 868.3 MHz und eine leicht erweiterte Bandbreite von bWidth:464KHz eingestellt sind.

Beim kürzesten einstellbaren Sendeintervall (8 Sekunden), provoziert der PIRA schnell [[LOVF]] Meldungen in FHEM , wenn jede Bewegung in FHEM eine Aktion auslöst, die ihrerseits einen Sendebefehel beinhaltet. Im schlimmsten Fall ist das Sendekontingent einer Stunde nach 22 Minuten verbraucht, bei Aussendung von 2 Befehlen je Bewegung sogar schon nach 11 Minuten.

= Bekannte Probleme =
Die benötigten 2 x Batterien "Lady" LR1/HR1/E90 sind schwer zu beschaffen und teuer, da unübliche Grösse (keine Mignon oder Micro).
Jedoch: Lebensdauer auch bei 30 Auslösungen pro Tag mehrere Jahre.

Wie bei allen Geräten im 868 Mhz Band gilt die [[1%_Regel]] auch für Bewegungsmelder. Der FS20 PIRA gestattet als kürzesten Sendeabstand 8 Sekunden. Kommt es in einem Raum (in dem sich ständig Personen aufhalten und bewegen) tatsächlich zu einer Auslösung alle 8 Sekunden, ist das Sendekontigent des PIRA einer ganzen Stunde nach 22 Minuten aufgebraucht und danach wird der Bewegungsmelder für den Rest der Stunde nicht mehr senden. Daher sollte immer ein möglichst langer Sendeabstand eingestellt werden.

= Links =
* [https://web.archive.org/web/20100415071131/http://www.elv-downloads.de/service/manuals/FS20PIRA/66818_um.pdf Bedienungsanleitung] im Internet Archiv, Original-Link nicht mehr erreichbar

[[Kategorie:FS20 Components]]
[[Kategorie:Bewegungs- und Anwesenheitsmelder]]

HM-CC-TC Funk-Wandthermostat

2017-11-05T18:46:24Z

Krokofant: /* Links */ entnummeriert

Programmierbarer Raumthermostat, der bis zu vier [[HM-CC-VD Funk-Stellantrieb]] steuern kann.

'''Achtung: Dieses Gerät ist abgekündigt (wird nicht mehr hergestellt).'''

Nachfolgeprodukt ist der [[HM-CC-RT-DN]] bzw. (ab März 2014) [[HM-TC-IT-WM-W-EU_Funk-Wandthermostat_AP|HM-TC-IT-WM-W-EU]].

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

= Features =
* Am Raumthermostat programmierbare Tages- und Nachttemperatur.
* Pro Wochentag können bis zu 24 Schaltpunkte definiert werden.
* Anbindung von <ins>jeweils</ins> '''maximal''' 4 Tür- bzw. Fensterkontakten ([[HM-Sec-RHS]]) zur Absenkung der Temperatur auf einen eigens eingestellten Temperaturwert (ab Werk: 12°C) bei offenem Fenster bzw. offener Tür.
* Anzeige der Temperatur und Luftfeuchtigkeit im Raum und Hintergrundbeleuchtung des Displays.

Alle 120 bis 184 Sekunden überträgt der Wandthermostat vorhandene Befehle zu den Stellantrieben. Jeder empfangene Befehl wird vom Stellantrieb bestätigt und dann ausgeführt. Täglich gegen Mitternacht synchronisiert ein HM-CC-TC seine Uhrzeit mit der HomeMatic-Zentrale (CCU, HMLAN).

= Hinweise zum Betrieb mit FHEM =
Vor dem Einsatz mit einer Zentrale müssen zunächst alle Stellantriebe und Tür-/Fensterkontakte mit dem HM-CC-TC verbunden bzw. [[Peering (HomeMatic)|gepeert]] werden .
Damit das Ganze dann in FHEM auftaucht, muss der TC noch [[Pairing (HomeMatic)|gepairt]] werden.

Mit

<nowiki>set CUL hmPairForSec 300</nowiki>
setzt man das CUL / den HMLAN-Konfigurator für 5 Minuten in den Anlernmodus. Danach am Thermostaten 5 Sekunden lang die OK-Taste drücken und es wird eine Zeit von 20 auf 0 Sekunden gezählt:

* Klappt das Anlernen in diesen 20 Sekunden, wird der Countdown sofort beendet, anschließend für ca. 2-3 Sekunden "OK" angezeigt und der Thermostat ist in FHEM eingebunden.
* Gelingt das Anlernen nicht in den 20 Sekunden, erscheint nach Erreichen der "0" noch für 2 bis 3 Sekunden ein "NOK" ('''N'''ot '''OK''') im Display des TCs.

'''Alternativ '''(und so vom Entwickler des FHEM-HomeMatic-Moduls empfohlen) kann wie folgt vorgegangen werden:

* Alle Stellantriebe und Tür-/Fensterkontakte sowie den HM-CC-TC mit FHEM p'''ai'''ren (also ''set CUL hmPairForSec 300'' und an allen Devices den Anlernknopf drücken innerhalb des Zeitfensters von 300 Sekunden).
* Die Stellantriebe und Tür-/Fensterkontakte mit den ''Channels'' (siehe unten) p'''ee'''ren (siehe <nowiki>[http://fhem.de/commandref.html#CUL_HMpeerChan commandref :peerChan]</nowiki>). Hierzu werden die entsprechenden FHEM-Befehle über das Webinterface von FHEM erteilt.

'''Hinweis:'''
* Alle in der FHEM-Eingabezeile eingegebenen ''attr''-, ''define''-Befehle usw. müssen zum Schluss noch per Klick auf den "Save"-Button dauerhaft in der ''fhem.cfg'' gespeichert werden, sonst sind sie nach z.B. einem Systemabsturz verloren.
* Falls in der FHEM-Weboberfläche für ihren HM-CC-TC etwas wie ''X CMDs pending'' steht, sollten Sie ihren HM-CC-TC zur Hand nehmen und für 20 Sekunden auf die OK-Taste drücken. Dadurch werden alle noch ausstehenden Befehle eingelesen.

== Auszug aus der fhem.cfg ==
Die nachfolgenden Einstellungen zum HM-CC-TC werden von FHEM <ins>weitestgehend</ins> automatisch gesetzt. Die Pfadangaben für die Log-Dateien sind system-, die Raumbenennungen benutzerabhängig. Zu ''autoReadReg''und ''expert''siehe unten. Neben dem eigentlichen Basis-Gerät (HM-CC-TC) werden in FHEM automatisch noch 3 weitere "Unter"-Geräte (Channels/Kanäle), nämlich

* ''_Weather''
* ''_Climate''
* ''_WindowRec''

definiert (durch das Anlernen des TC an FHEM; siehe unten), deren Benennung sich (jeweils mit einem vorangestellten Unterstrich "_") am Namen des Basis-Gerätes orientiert.

'''Anmerkung: '''Die in den unten gezeigten ''fhem.cfg''-Auszügen markierten <ins>Peer</ins>-Einträge tauchen erst auf, sobald man die Daten aus dem TC mit ''set HM-CC-TC-Basisname getConfig''bzw. ''autoReadReg''ausgelesen hat.

=== Hauptgerät ===
<nowiki>define <HM-CC-TC>.Heizung CUL_HM 1DA491
attr <HM-CC-TC>.Heizung actCycle 000:10
attr <HM-CC-TC>.Heizung actStatus alive
attr <HM-CC-TC>.Heizung autoReadReg 1
attr <HM-CC-TC>.Heizung devInfo 00FFFF
attr <HM-CC-TC>.Heizung expert 2_full
attr <HM-CC-TC>.Heizung firmware 2.1
attr <HM-CC-TC>.Heizung hmClass receiver
attr <HM-CC-TC>.Heizung model HM-CC-TC
attr <HM-CC-TC>.Heizung room <IhrRaum>
attr <HM-CC-TC>.Heizung serialNr JE********
attr <HM-CC-TC>.Heizung subType thermostat</nowiki>
=== Channel (Kanal) 01 _Weather ===
<nowiki>define <HM-CC-TC>.Heizung_Weather CUL_HM 1DA49101 <<<=== 01 = Kanal 1
attr <HM-CC-TC>.Heizung_Weather model HM-CC-TC
attr <HM-CC-TC>.Heizung_Weather peerIDs
attr <HM-CC-TC>.Heizung_Weather room <IhrRaum>
define FileLog_<HM-CC-TC>.Heizung_Weather FileLog /opt/fhem/log/<HM-CC-TC>.Heizung_Weather-%Y-%m.log <HM-CC-TC>.Heizung_Weather
attr FileLog_<HM-CC-TC>.Heizung_Weather logtype text
attr FileLog_<HM-CC-TC>.Heizung_Weather room CUL_HM,<IhrRaum></nowiki>
=== Channel (Kanal) 02 _Climate ===
<nowiki>define <HM-CC-TC>.Heizung_Climate CUL_HM 1DA49102 <<<=== 02 = Kanal 2
attr <HM-CC-TC>.Heizung_Climate model HM-CC-TC
attr <HM-CC-TC>.Heizung_Climate peerIDs 1AD52B01,1B7A4C01,1C4CD101,1C48EC01, <<<=== gepeerte HM-CC-VDs
attr <HM-CC-TC>.Heizung_Climate room <IhrRaum>
define FileLog_<HM-CC-TC>.Heizung_Climate FileLog /opt/fhem/log/<HM-CC-TC>.Heizung_Climate-%Y-%m.log <HM-CC-TC>.Heizung_Climate
attr FileLog_<HM-CC-TC>.Heizung_Climate logtype text
attr FileLog_<HM-CC-TC>.Heizung_Climate room CUL_HM,<IhrRaum></nowiki>
=== Channel (Kanal) 03 _WindowRec ===
<nowiki>define <HM-CC-TC>.Heizung_WindowRec CUL_HM 1DA49103 <<<=== 03 = Kanal 3
attr <HM-CC-TC>.Heizung_WindowRec model HM-CC-TC
attr <HM-CC-TC>.Heizung_WindowRec peerIDs 1CFBB001, <<<=== gepeerte HM-Sec-SCs
attr <HM-CC-TC>.Heizung_WindowRec room <IhrRaum>
define FileLog_<HM-CC-TC>.Heizung_WindowRec FileLog /opt/fhem/log/<HM-CC-TC>.Heizung_WindowRec-%Y-%m.log <HM-CC-TC>.Heizung_WindowRec
attr FileLog_<HM-CC-TC>.Heizung_WindowRec logtype text
attr FileLog_<HM-CC-TC>.Heizung_WindowRec room CUL_HM,<IhrRaum></nowiki>
== Einstellungen eines HM-CC-TC lesen, anzeigen und sichern ==
=== expert ===
Anfang Februar 2013 wurde eine Änderung bei der Anzeige der so genannten ''Readings'' (Register usw.), also der Einstellungen bzw. Eigenschaften eines HM-Devices, eingeführt. '''Alle''' Werte sieht man nur noch, wenn man am HM-CC-TC das Attribut ''expert'' auf ''2_all'' setzt. Per '''default''' (nicht in ''fhem.cfg'' gesetzt) steht dieser Wert auf ''0_off'' (nur die notwendigsten Readings/Eigenschaften werden angezeigt). Mittelweg ist der Wert ''1_on''.

Mittels

<nowiki>attr <HM-CC-TC-Name> expert 2_full</nowiki>
in der FHEM-Befehlszeile mit anschließendem <Enter> setzt man diesen Level.

Falls man mit '''Temperaturlisten''' arbeitet (siehe unten), dann kann man die komplette Liste im "Channel" (Kanal) ''<HM-CC-TC-Name>__Climate'' einsehen. Auch für diesen Kanal ist evtl. ein setzen des Attributes ''expert 2_full'' angeraten.

<ins>Anmerkung:</ins> Es gibt auch noch sogenannte "hidden datas" (versteckte interne Werte, Register oder Eigenschaften deren Namen mit einem "." beginnen). Diese sieht man nur dann, wenn auch das Attribut ''showInternalValues 1'' gesetzt ist (default: 0 bzw. nicht gesetzt).

=== autoReadReg ===
Mitte Januar 2013 wurde das neue Attribut ''autoReadReg'' eingeführt, welches auf ''0'' voreingestellt ist (kein Eintrag in der ''fhem.cfg''). Das Setzen dieses Attributes auf ''1'' bewirkt, dass <ins>beim Neustart von FHEM</ins> die Einstellungen des entsprechenden HM-Gerätes ausgelesen werden. Dies wird bei mehreren ''autoReadReg''s automatisch zeitversetzt vorgenommen, um die Funk-Kommunikation nicht unnötig zu belasten.

Mittels

<nowiki>attr <HM-CC-TC-Name> autoReadReg 1 </nowiki>
in der FHEM-Befehlszeile mit anschließendem <Enter> setzt man diesen Wert.

=== list ===
Um sich alle Eigenschaften/Readings eines Gerätes anzusehen, gibt es den Befehl [[list]].

Mittels

<nowiki>list <HM-CC-TC-Name></nowiki>
und Bestätigung mit <Enter> erhalten Sie die gewünschte Anzeige Ihres TCs <ins>incl.</ins> seiner 3 Channels. Über

<nowiki>list <HM-CC-TC-Name>_<Channel-Name></nowiki>
werden nur die Daten des angegebenen Channels angezeigt.

=== Einstellungen sichern ===
Die Durchführung von ''autoReadReg'' kann durchaus mehrere Minuten dauern. Anschließend besteht die Möglichkeit, diese per

<nowiki>get HM-CC-TC-Basisname saveConfig [/Verzeichnis/mit/Schreibrechten/]<Dateiname></nowiki>
für jedes HM-CC-TC getrennt zu sichern (für eine später notwendige Wiederherstellung). Die Sicherungsdatei wird regulär im ''modpath'' (siehe ''fhem.cfg'') abgelegt. Falls dies nicht zum Erfolg führt (es wird - ohne Fehlermeldungen bei regulärem ''verbose'' und ''loglevel'' - im ''modpath'' keine Datei angelegt), müssen Sie vor dem Dateinamen einen vollständigen Pfad mit Schreibrechten für den Benutzer, unter dem FHEM läuft, angeben.

In der <ins>Log-Datei</ins> von FHEM erscheinen danach Meldungen folgender Art

<nowiki><Datum>_<Zeit> 2: CUL_HM set <HM-CC-TC-Name> statusRequest rxt:12
<Datum>_<Zeit> 2: CUL_HM set <HM-CC-TC-Name> getConfig rxt:12</nowiki>
Hierbei kann es (im <ins>Event monitor</ins> von FHEM) zu folgenden Fehlermeldungen kommen

<nowiki><Datum>_<Zeit> CUL_HM <HM-CC-TC-Name> RESPONSE TIMEOUT:RegisterRead
<Datum>_<Zeit> CUL_HM <HM-CC-TC-Name> RESPONSE TIMEOUT:PeerList
<Datum>_<Zeit> CUL_HM <HM-CC-TC-Name> RESPONSE TIMEOUT:StatusReq</nowiki>
Diese Meldungen können auch mehrfach pro Gerät auftreten. Dann hat das Auslesen der Einstellungen nicht geklappt und sollte nochmals durchgeführt werden. Dafür muss man FHEM aber nicht neu starten, sondern das HM-Device per

<nowiki>set <HM-CC-TC-Name> getConfig</nowiki>
in der Befehlszeile von FHEM und anschließendem <Enter> (nicht "save") darauf einstellen.

Die Channels (z.B. <HM-CC-TC-Name>_Climate, _Weather, _WindowRec) eines HM-Gerätes brauchen nicht (können aber bei Bedarf) separat ausgelesen bzw. gesichert zu werden, da sie Bestandteil der Basisabfrage sind.

== Funkprobleme auffangen ==
Der wohl am häufigsten an den HM-CC-TC gesendete Befehl ist "set desired-temp", mit dem die Wunschtemperatur neu gesetzt wird.
Funktioniert dieser Befehl jedoch nicht zuverlässig, wird die Wohnung ggf. zu lange oder nicht rechtzeitig beheizt.
Der folgende Mechanismus soll die Sicherheit erhöhen, indem die Antworten des HM-CC-TC geprüft werden und ggf. das Funktelegramm erneut gesendet wird.

Um den Sollwert zum erneuten Senden des Funktelegramms verfügbar zu haben, wird ein dummy definiert:

<nowiki>define HM_TC_Solltemperatur dummy</nowiki>
Wann immer die Solltemperatur geändert wird, setzt man die neue desired-temp nicht nur auf dem HM-TC-CC (hier HM_TC genannt), sondern auch auf dem dummy. Der Befehl (z.B. in der [[Zuhause-Status|Routine zum HomeStatus]]) sieht dann so aus:

<nowiki>set HM_TC desired-temp 21;set HM_TC_Solltemperatur 21</nowiki>
Falls das ausgehende Funktelegramm verlorengeht, fehlt die Antwort "command accepted". Dies kann mit einem watchdog aufgefangen werden, der dann den Befehl an den HM-CC-TC erneut sendet:

<nowiki>define w_HM_TC watchdog HM_TC:set_desired-temp.* 00:02:30 HM_TC_Climate:CommandAccepted:.yes { \
Log 1, ">>>>>>>>> w_HM_TC desired temp - missing response.";\
fhem("set HM_TC desired-temp ".Value("HM_TC_Solltemperatur"));\
}</nowiki>
Falls ein Fehler bei der Funkkommunikation auftritt, erhält man die Antwort "missing ACK" oder "NACK". Auch in diesem Fall soll das Telegramm zum Ändern der Wunschtemperatur erneut an den HM-CC-TC gesendet werden:

<nowiki>define n_HM_TC_err notify HM_TC:(MISSING.ACK.*|.*NACK.*) {\
Log 1, ">>>>>>>>> n_HM_TC desired temp - missing ack/nack.\n";\
fhem("set HM_TC desired-temp ".Value("HM_TC_Solltemperatur"));\
}</nowiki>
Mit diesen beiden Helfern ist die Funkkommunikation zum HM-CC-TC sehr zuverlässig.

== Plots / Grafiken ==
=== Problem ===
Durch ''autocreate'' wird zwar ein Log angelegt, aber kein Plot (Grafische Auswertung). Dem kann man aber abhelfen (siehe unten).

=== Plots erzeugen ===
''PGM2'' ist die Standardansicht des FHEM-Web-Interfaces. Um hier Plots/Grafiken zu erzeugen einfach unter dem ''Filelog'' des Thermostaten das ''attr logtype'' auf ''temp4hum6:Plot,text'' setzen und es wird ein Plot-Link neben dem Text-Link angezeigt. Nun können Sie auf diesen Plot-Link klicken und ...

=== alternative Plots ===
Mit dem fht.gplot funktioniert die Anzeige der Ventilstellung (actuator) nicht.

Mit folgendem angepassten .gplot File wird die gemessene Temperatur und Ventilstellung angezeigt.

<nowiki>############################
# Display the measured temp and the actuator.
# Corresponding FileLog definition:
# define <filelogname> FileLog /var/log/fhem/actuator_name-%Y.log <actuator_name>:(measured-temp|actuator).*

set terminal png transparent size <SIZE> crop
set output '<OUT>.png'
set xdata time
set timefmt "%Y-%m-%d_%H:%M:%S"
set xlabel " "
set ytics nomirror
set y2tics
#set ytics
set title '<L1>'
set grid xtics y2tics

set y2label "Temperatur in C"
set ylabel "Ventil (%)"

#FileLog 4:measured:10:
#FileLog 4:actuator:50:

plot \
"< egrep 'temperature' <IN>"\
using 1:4 axes x1y2 title 'Temperatur in C' with lines,\
"< egrep 'actuator' <IN>"\
using 1:4 axes x1y1 title 'Ventil (%)' with lines\</nowiki>
=== Alles-drin-Plot ===
Dazu nimmt man folgendes .gplot (bitte beachten, dass hierfür alle Parameter nach der define-Anweisung in das Logfile geschrieben werden):

<nowiki>############################
# Display the measured temp and the actuator.
# Corresponding FileLog definition:
# define <filelogname> FileLog /var/log/fhem/HM_CC_TC-%Y.log <HM_CC_TC-name>
set terminal png transparent size <SIZE> crop
set output '<OUT>.png'
set xdata time
set timefmt "%Y-%m-%d_%H:%M:%S"
set xlabel " "
set ytics nomirror
set y2tics
#set ytics
set title '<L1>'
set grid xtics y2tics
set y2label "Temperature in C"
set ylabel "Actuator (%)"
#FileLog 4:temperature:0:
#FileLog 4:desired:0:
#FileLog 4:humidity:0:
#FileLog 4:actuator:0:int
plot \
"< awk '/temperature/{print $1, $4}' <IN>"\
using 1:2 axes x1y2 title 'Measured temperature' with lines lw 2,\
"< awk '/desired/{print $1, $4}' <IN>"\
using 1:2 axes x1y2 title 'Desired temperature' with steps,\
"< awk '/humidity/ {print $1, $4+0}' <IN>"\
using 1:2 axes x1y1 title 'Humidity (%)' with lines,\
"< awk '/actuator/ {print $1, $4+0}' <IN>"\
using 1:2 axes x1y1 title 'Actuator (%)' with lines\</nowiki>

Anmerkung: Möglicherweise ist die obige Definiton fehlerhaft. Im Forum wird in {{Link2Forum|Topic=14812|LinkText=diesem Thread}} dargelegt, dass die Definition vielmehr wie folgt lauten müsse:

<nowiki>############################
# Display the measured temp and the actuator.

# Corresponding FileLog definition:

# define <filelogname> FileLog /var/log/fhem/HM_CC_TC-%Y.log <HM_CC_TC-name>

set terminal png transparent size <SIZE> crop
set output '<OUT>.png'
set xdata time
set timefmt "%Y-%m-%d_%H:%M:%S"
set xlabel " "
set ytics nomirror
set y2tics
#set ytics
set title '<L1>'
set grid xtics y2tics
set y2label "Temperatur in °C"
set ylabel "Ventil (%)"
#FileLog 4:measured-temp:0:
#FileLog 4:desired-temp:0:
#FileLog 4:humidity:0:
#FileLog 4:actuator:0:int
plot \
"< awk '/temperature/{print $1, $4}' <IN>"\
using 1:2 axes x1y2 title 'Temperatur' with lines lw 2,\
"< awk '/desired/{print $1, $4}' <IN>"\
using 1:2 axes x1y2 title 'Wunschtemperatur' with steps,\
"< awk '/humidity/ {print $1, $4+0}' <IN>"\
using 1:2 axes x1y1 title 'Feuchte (%)' with lines,\
"< awk '/actuator/ {print $1, $4+0}' <IN>"\
using 1:2 axes x1y1 title 'Ventil (%)' with lines</nowiki>

== Steuerungsmodi ==
Das Wandthermostat hat 4 verschiedene Steuerungsmöglichkeiten:

* Auto (automatisch)
* Cent (Zentrale)
* Manu (manuell)
* Prog / Koffer-Symbol (Urlaubs/Party-Modus, wird hier nicht näher erörtert)

Der Steuerungsmodus wird über wiederholtes Drücken der linken Taste des HM-CC-TC ausgewählt bzw. gewechselt.

'''Hinweis:''' Durch das P'''ai'''ren des HM-CC-TC <ins>und</ins> der Stellantrieb sowie Tür-/Fensterkontakte an FHEM verlieren Sie '''nicht''' die Steuerungsmöglichkeiten. Im Gegenteil: Nur wenn auch die VDs usw. mit FHEM gep'''ai'''rt sind, haben Sie die Möglichkeit, auch diese zu überwachen. Die Steuerung '''können''' Sie dennoch allein dem HM-CC-TC überlassen.

=== Auto-Modus ===
Im Modus '''Auto''' wird die Temperaturregelung über die im TC hinterlegten Temperaturlisten vorgenommen. Das Thermostat arbeitet also selbständig, somit unabhängig von einer Zentrale / FHEM. Nur in diesem Modus werden die evtl. per FHEM an das TC übermittelten "templist" abgearbeitet. Über das Senden von angepassten Temperatur-Listen kann eine indirekte Steuerung per FHEM erfolgen. '''Jederzeit''' kann zudem die Raumtemperatur über das Drehrad des Wandthermostaten oder die FHEM-Web-Oberfläche verändert werden. Diese ''Übersteuerung'' der Temperaturliste gilt bis zur nächsten Temperaturänderung nach der vorgenannten Liste.

=== Cent-Modus ===
Im Modus '''Cent''' steuert eine HomeMatic-Zentrale (CCU) oder eben ein FHEM-Server mit z.B. [[HMLAN Konfigurator]] zu den in der FHEM-Config hinterlegten Zeiten und mit den dort festgelegten Temperaturen. Fällt also die HM-Zentrale aus, erfolgt keine Steuerung der Thermostaten bzw. Heizungsventile mehr.

<ins>Anmerkung</ins>: Der Modus ''cent'' erscheint nur dann im Display des HM-CC-TC, wenn er an eine Zentrale bzw. das [[CUL]] angelernt (gepairt) wurde.

=== Manu-Modus ===
Der Modus '''Manu''' übersteuert die im TC hinterlegten Temperaturlisten und die evtl. von der HM-Zentrale / dem FHEM <ins>vor Umstellung auf ''Manu''</ins> gesendeten Einstellungen. Es wird also bis zur nächsten Modusumstellung bzw. manuellen Temperaturverstellung der per Einstellrad gesetzte Temperaturwert gefahren.

Aber auch in diesem Modus kann man die ''desired-temperature'' per FHEM verstellen. Der dadurch eingestellte Wert gilt ab sofort als der neue im ''Manu-Modus'' zu haltende Wert.

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

set <HM-CC-TC> regSet btnLock on

Rückgängig machen geht per:

set <HM-CC-TC> regSet btnLock off

=== Auslesen des eingestellten Steuerungsmodus ===
Der eingestellte Steuerungsmodus erscheint normalerweise in den ''Readings'' des HM-CC-TC unter ''controlMode''. Zusätzlich haben Sie die Möglichkeit, diesen Modus auch in der FHEM-Weboberfläche ''everything'' => Abschnitt ''thermostat'' zu sehen, '''wenn''' Sie für den HM-CC-TC das folgende Attribut setzen:

<nowiki>attr <HM-CC-TC-Name> stateFormat T:measured-temp, H:humidity, VD:actuator, controlMode</nowiki>
Erscheint dort selbst nach einem

<nowiki>set <HM-CC-TC-Name> getConfig</nowiki>
kein "Reading" ''controlMode'' oder keine Angabe des aktuell eingestellten Modus bzw. nur das Wort "controlMode", dann setzen Sie ihren HM-CC-TC von Hand in einen anderen Kontrollmodus und machen einen Browser-Refresh. Klappt dies nicht, geben Sie bitte erneut den Befehl

<nowiki>set <HM-CC-TC-Name> getConfig</nowiki>
ein. Halten Sie anschließend die Taste <OK> am HM-CC-TC für 5 Sekunden gedrückt (oder warten ca. 5 Minuten) und machen in der FHEM-Weboberfläche einen Browser-Refresh (FF => <F5>). Jetzt sollte der manuell eingestellte Kontrollmodus erscheinen (ggfls. muss dieser Vorgang einmal wiederholt werden). Jetzt können Sie wieder den gewünschten Modus einstellen, erneut ein

<nowiki>set <HM-CC-TC-Name> getConfig</nowiki>
absetzen und nach erneutem Drücken der <OK>-Taste für 5 Sekunden mit nachfolgendem Browser-Refresh sollte alles richtig angezeigt werden.

Dies setzt natürlich voraus, dass der HM-CC-TC richtig gepairt ist.

== Temperaturlisten ==
Die Temperaturlisten des TC werden identisch mit denen anderer HomeMatic Thermostate verwaltet, siehe [[HomeMatic Type Thermostat#Temperaturlisten|HomeMatic Type Thermostat]].
Beim TC ist der Kanal 4 (_Climate) für die Temperaturlisten zuständig.

== Batteriealarme des HM-CC-VD in Verbindung mit HM-CC-TC ==
1. bei U-Bat. < 2,4 V erscheint im Display des VD und des TC das Batteriesymbol mit '''battery: low''' in den Readings und Events!

2. bei U-Bat. < 2,3 V erscheint im Display des VD zusätzlich '''F4''' mit '''battery: critical''' in den Readings und Events!

Es wird dringend geraten, die Batterien bei battery: low zu tauschen!

== Log-Auszug ==
HM-CC-TC sendet alle 2 Minuten folgenden Statusbericht:

<nowiki>Datum-Zeit <Device Name> T: 17.3 H: 66
Datum-Zeit <Device Name> measured-temp: 17.3
Datum-Zeit <Device Name> temperature: 17.3
Datum-Zeit <Device Name> humidity: 66
Datum-Zeit <Device Name> actuator: 96 %</nowiki>
Bei Status-Änderungen sendet HM-CC-TC auch entsprechende Meldungen, z.b.:

<nowiki>Datum-Zeit <Device Name> desired-temp: 15.5</nowiki>

= Probleme =

== Verstellen der Solltemperatur am HM-CC-TC per Drehrad ==

'''Symptom:''' Beim Verstellen der Solltemperatur per seitlichem Drehrad wurde die aktuelle Solltemperatur - '''egal ob''' man hoch oder runter drehte - immer nur in 0,5 °C Schritten '''runter''' gestellt, bis schließlich die Mindesttemperatur von 6,0 °C erreicht war. Weitere Änderungen waren nicht möglich

'''Abhilfeversuch:''' Letztlich half nur das kurzzeitige Entfernen einer Batterie. Das danach für einige Zeit erscheinende Batteriesymbol zeigte den kleinstmöglichen guten Zustand an, in FHEM wurde das ''Reading'' des Batteriezustandes mit ''ok'' ausgegeben (wie in den Logs aber vorher auch). '''Letztlich half aber nur''' das Einsetzen neuer Batterien, denn die o.a. Störung trat nach ca. 2 Stunden erneut auf. Die "alten" Batterien (die, die dem HM-CC-TC ab Werk beilagen) hatten somit eine Nutzungsdauer von knapp 11 Monaten, waren aber auch in einem HM-CC-TC, der mit 4 Stck. HM-Sec-SC (mussten sehr oft "Meldung machen") und 4 Stck. HM-CC-VD gepeert war. ''Ohne Last'' zeigten die beiden alten AA-Batterien eine Spannung von jeweils 1,29 V an.
'''Hinweis:''' Die unter ''Abhilfeversuch'' beschriebene Lösung war leider nur von kurzer Dauer. Bereits kurz danach zeigte der HM-CC-TC die gleichen Ausfallerscheinungen. Bei ELV gibt es das Bauteil für das Drehrad (Inkrementalgeber) als [http://www.elv.de/inkrementalgeber-fuer-fs20-str-fht-8-und-homematic-hm-cc-tc.html Ersatzteil]. Sobald dieses geliefert und ein Reparaturversuch unternommen wurde, wird an dieser Stelle weiter berichtet.

'''Abhilfe: Autausch des Inkrementalgebers [1]:''' Löst das Problem zu 70%. Ganz exakt reagiert er auch danach nicht. Teile des Problems scheinen also tiefer zu liegen.

Diese Anweisung ist nur für Fachpersonal in Elektronik geeignet, die über Erfahrung mit µ-Elektronik und einen ESD geeigneten Arbeitsplatz verfügen

Benötigtes Werkzeug (Erfahrene THT Löter brauchen evtl. nicht alles)

* Torx-Schraubendreher T7
* Seitenschneider für Elektronik
* Entlötsaugpumpe
* Sauglitze
* Lötzinn

# Batteriedeckel entfernen und Batterie entnehmen
# Auf der Rückseite vier Torx Schrauben lösen
# Rückseite abnehmen
# Acht Torx lösen (die drei um den Inkrementalgeber kommen später)
# Baugruppe von der Frontseite trennen. Hinweis: Das LCD ist mit Leitgummi mit der Leiterplatte verbunden. Es kann daher sein, dass das LCD auf der Baugruppe klebt. In diesem Fall vorsichtig abnehmen, nicht die Verbindungsfläche zur Leiterplatte berühren oder zum LCD berühren, der Handschweiß verringert die Leitfähigkeit und ein Ausfall des LCD kann die Folge sein.
# Drei Torx lösen, die das Handrad halten
# die fünf Füße des Inkrementalgeber mit dem Seitenschneider lösen
# Füße auslöten, Bohrungen mit Entlösaugpumpe und Sauglitze reinigen
# Neuen Inrementalgeber einlöten (Einbauseite beachten)
# In umgekehrter Reihenfolge wieder zusammenbauen

Auf Wunsch stelle ich auch Bilder rein, das ganze ist mechanisch aber nicht sehr anspruchsvoll. Wer löten kann sollte keine Probleme haben.

== HM-CC-TC misst zu hohe/niedrige Luftfeuchte-Werte oder Temperaturen > 100°C ==

'''Symptom:''' In den FHEM-Logs und demzufolge auch in den Plots/Grafiken eines seit über 18 Monaten im Einsatz befindlichen HM-CC-TC wurden viel zu hohe (einzelne Spitzenwerte von 98 oder 99 %) bzw. ständig zu niedrige (um die 20 oder sogar vereinzelt nur 2 %) Werte für die relative Luftfeuchte gemessen (im direkten Vergleich zu anderen HM-CC-TCs). Die anderen Werte (Temperatur, Actuator) waren aber schlüssig.

'''Abhilfe:''' Batteriewechsel. Die alten Batterien hatten (unbelastet) noch knapp über 1 V Spannung.

'''Hinweis:''' Eine Batteriewarnung des Gerätes gab es nicht. Im Display war das entsprechende Symbol noch auf 1 Balken.

= Firmware =
Aktuelle Firmware-Version: 2.1

= Links =
* [https://web.archive.org/web/20150318044425/http://www.eq-3.de/Downloads/eq3/pdf_produkte/HM-CC-TC_UM_GE_eQ-3_110405.pdf Anleitung (PDF)] (Archiviert bei [https://www.archive.org/ Archive.org])
* [http://www.elv.de/output/controller.aspx?cid=74&detail=10&detail2=41344 Ersatzteil Inkrementalgeber bei ELV]

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

HM-CC-TC Funk-Wandthermostat

2017-11-05T18:45:21Z

Krokofant: Anleitung gibts nur noch im Internt-Archiv

Programmierbarer Raumthermostat, der bis zu vier [[HM-CC-VD Funk-Stellantrieb]] steuern kann.

'''Achtung: Dieses Gerät ist abgekündigt (wird nicht mehr hergestellt).'''

Nachfolgeprodukt ist der [[HM-CC-RT-DN]] bzw. (ab März 2014) [[HM-TC-IT-WM-W-EU_Funk-Wandthermostat_AP|HM-TC-IT-WM-W-EU]].

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

= Features =
* Am Raumthermostat programmierbare Tages- und Nachttemperatur.
* Pro Wochentag können bis zu 24 Schaltpunkte definiert werden.
* Anbindung von <ins>jeweils</ins> '''maximal''' 4 Tür- bzw. Fensterkontakten ([[HM-Sec-RHS]]) zur Absenkung der Temperatur auf einen eigens eingestellten Temperaturwert (ab Werk: 12°C) bei offenem Fenster bzw. offener Tür.
* Anzeige der Temperatur und Luftfeuchtigkeit im Raum und Hintergrundbeleuchtung des Displays.

Alle 120 bis 184 Sekunden überträgt der Wandthermostat vorhandene Befehle zu den Stellantrieben. Jeder empfangene Befehl wird vom Stellantrieb bestätigt und dann ausgeführt. Täglich gegen Mitternacht synchronisiert ein HM-CC-TC seine Uhrzeit mit der HomeMatic-Zentrale (CCU, HMLAN).

= Hinweise zum Betrieb mit FHEM =
Vor dem Einsatz mit einer Zentrale müssen zunächst alle Stellantriebe und Tür-/Fensterkontakte mit dem HM-CC-TC verbunden bzw. [[Peering (HomeMatic)|gepeert]] werden .
Damit das Ganze dann in FHEM auftaucht, muss der TC noch [[Pairing (HomeMatic)|gepairt]] werden.

Mit

<nowiki>set CUL hmPairForSec 300</nowiki>
setzt man das CUL / den HMLAN-Konfigurator für 5 Minuten in den Anlernmodus. Danach am Thermostaten 5 Sekunden lang die OK-Taste drücken und es wird eine Zeit von 20 auf 0 Sekunden gezählt:

* Klappt das Anlernen in diesen 20 Sekunden, wird der Countdown sofort beendet, anschließend für ca. 2-3 Sekunden "OK" angezeigt und der Thermostat ist in FHEM eingebunden.
* Gelingt das Anlernen nicht in den 20 Sekunden, erscheint nach Erreichen der "0" noch für 2 bis 3 Sekunden ein "NOK" ('''N'''ot '''OK''') im Display des TCs.

'''Alternativ '''(und so vom Entwickler des FHEM-HomeMatic-Moduls empfohlen) kann wie folgt vorgegangen werden:

* Alle Stellantriebe und Tür-/Fensterkontakte sowie den HM-CC-TC mit FHEM p'''ai'''ren (also ''set CUL hmPairForSec 300'' und an allen Devices den Anlernknopf drücken innerhalb des Zeitfensters von 300 Sekunden).
* Die Stellantriebe und Tür-/Fensterkontakte mit den ''Channels'' (siehe unten) p'''ee'''ren (siehe <nowiki>[http://fhem.de/commandref.html#CUL_HMpeerChan commandref :peerChan]</nowiki>). Hierzu werden die entsprechenden FHEM-Befehle über das Webinterface von FHEM erteilt.

'''Hinweis:'''
* Alle in der FHEM-Eingabezeile eingegebenen ''attr''-, ''define''-Befehle usw. müssen zum Schluss noch per Klick auf den "Save"-Button dauerhaft in der ''fhem.cfg'' gespeichert werden, sonst sind sie nach z.B. einem Systemabsturz verloren.
* Falls in der FHEM-Weboberfläche für ihren HM-CC-TC etwas wie ''X CMDs pending'' steht, sollten Sie ihren HM-CC-TC zur Hand nehmen und für 20 Sekunden auf die OK-Taste drücken. Dadurch werden alle noch ausstehenden Befehle eingelesen.

== Auszug aus der fhem.cfg ==
Die nachfolgenden Einstellungen zum HM-CC-TC werden von FHEM <ins>weitestgehend</ins> automatisch gesetzt. Die Pfadangaben für die Log-Dateien sind system-, die Raumbenennungen benutzerabhängig. Zu ''autoReadReg''und ''expert''siehe unten. Neben dem eigentlichen Basis-Gerät (HM-CC-TC) werden in FHEM automatisch noch 3 weitere "Unter"-Geräte (Channels/Kanäle), nämlich

* ''_Weather''
* ''_Climate''
* ''_WindowRec''

definiert (durch das Anlernen des TC an FHEM; siehe unten), deren Benennung sich (jeweils mit einem vorangestellten Unterstrich "_") am Namen des Basis-Gerätes orientiert.

'''Anmerkung: '''Die in den unten gezeigten ''fhem.cfg''-Auszügen markierten <ins>Peer</ins>-Einträge tauchen erst auf, sobald man die Daten aus dem TC mit ''set HM-CC-TC-Basisname getConfig''bzw. ''autoReadReg''ausgelesen hat.

=== Hauptgerät ===
<nowiki>define <HM-CC-TC>.Heizung CUL_HM 1DA491
attr <HM-CC-TC>.Heizung actCycle 000:10
attr <HM-CC-TC>.Heizung actStatus alive
attr <HM-CC-TC>.Heizung autoReadReg 1
attr <HM-CC-TC>.Heizung devInfo 00FFFF
attr <HM-CC-TC>.Heizung expert 2_full
attr <HM-CC-TC>.Heizung firmware 2.1
attr <HM-CC-TC>.Heizung hmClass receiver
attr <HM-CC-TC>.Heizung model HM-CC-TC
attr <HM-CC-TC>.Heizung room <IhrRaum>
attr <HM-CC-TC>.Heizung serialNr JE********
attr <HM-CC-TC>.Heizung subType thermostat</nowiki>
=== Channel (Kanal) 01 _Weather ===
<nowiki>define <HM-CC-TC>.Heizung_Weather CUL_HM 1DA49101 <<<=== 01 = Kanal 1
attr <HM-CC-TC>.Heizung_Weather model HM-CC-TC
attr <HM-CC-TC>.Heizung_Weather peerIDs
attr <HM-CC-TC>.Heizung_Weather room <IhrRaum>
define FileLog_<HM-CC-TC>.Heizung_Weather FileLog /opt/fhem/log/<HM-CC-TC>.Heizung_Weather-%Y-%m.log <HM-CC-TC>.Heizung_Weather
attr FileLog_<HM-CC-TC>.Heizung_Weather logtype text
attr FileLog_<HM-CC-TC>.Heizung_Weather room CUL_HM,<IhrRaum></nowiki>
=== Channel (Kanal) 02 _Climate ===
<nowiki>define <HM-CC-TC>.Heizung_Climate CUL_HM 1DA49102 <<<=== 02 = Kanal 2
attr <HM-CC-TC>.Heizung_Climate model HM-CC-TC
attr <HM-CC-TC>.Heizung_Climate peerIDs 1AD52B01,1B7A4C01,1C4CD101,1C48EC01, <<<=== gepeerte HM-CC-VDs
attr <HM-CC-TC>.Heizung_Climate room <IhrRaum>
define FileLog_<HM-CC-TC>.Heizung_Climate FileLog /opt/fhem/log/<HM-CC-TC>.Heizung_Climate-%Y-%m.log <HM-CC-TC>.Heizung_Climate
attr FileLog_<HM-CC-TC>.Heizung_Climate logtype text
attr FileLog_<HM-CC-TC>.Heizung_Climate room CUL_HM,<IhrRaum></nowiki>
=== Channel (Kanal) 03 _WindowRec ===
<nowiki>define <HM-CC-TC>.Heizung_WindowRec CUL_HM 1DA49103 <<<=== 03 = Kanal 3
attr <HM-CC-TC>.Heizung_WindowRec model HM-CC-TC
attr <HM-CC-TC>.Heizung_WindowRec peerIDs 1CFBB001, <<<=== gepeerte HM-Sec-SCs
attr <HM-CC-TC>.Heizung_WindowRec room <IhrRaum>
define FileLog_<HM-CC-TC>.Heizung_WindowRec FileLog /opt/fhem/log/<HM-CC-TC>.Heizung_WindowRec-%Y-%m.log <HM-CC-TC>.Heizung_WindowRec
attr FileLog_<HM-CC-TC>.Heizung_WindowRec logtype text
attr FileLog_<HM-CC-TC>.Heizung_WindowRec room CUL_HM,<IhrRaum></nowiki>
== Einstellungen eines HM-CC-TC lesen, anzeigen und sichern ==
=== expert ===
Anfang Februar 2013 wurde eine Änderung bei der Anzeige der so genannten ''Readings'' (Register usw.), also der Einstellungen bzw. Eigenschaften eines HM-Devices, eingeführt. '''Alle''' Werte sieht man nur noch, wenn man am HM-CC-TC das Attribut ''expert'' auf ''2_all'' setzt. Per '''default''' (nicht in ''fhem.cfg'' gesetzt) steht dieser Wert auf ''0_off'' (nur die notwendigsten Readings/Eigenschaften werden angezeigt). Mittelweg ist der Wert ''1_on''.

Mittels

<nowiki>attr <HM-CC-TC-Name> expert 2_full</nowiki>
in der FHEM-Befehlszeile mit anschließendem <Enter> setzt man diesen Level.

Falls man mit '''Temperaturlisten''' arbeitet (siehe unten), dann kann man die komplette Liste im "Channel" (Kanal) ''<HM-CC-TC-Name>__Climate'' einsehen. Auch für diesen Kanal ist evtl. ein setzen des Attributes ''expert 2_full'' angeraten.

<ins>Anmerkung:</ins> Es gibt auch noch sogenannte "hidden datas" (versteckte interne Werte, Register oder Eigenschaften deren Namen mit einem "." beginnen). Diese sieht man nur dann, wenn auch das Attribut ''showInternalValues 1'' gesetzt ist (default: 0 bzw. nicht gesetzt).

=== autoReadReg ===
Mitte Januar 2013 wurde das neue Attribut ''autoReadReg'' eingeführt, welches auf ''0'' voreingestellt ist (kein Eintrag in der ''fhem.cfg''). Das Setzen dieses Attributes auf ''1'' bewirkt, dass <ins>beim Neustart von FHEM</ins> die Einstellungen des entsprechenden HM-Gerätes ausgelesen werden. Dies wird bei mehreren ''autoReadReg''s automatisch zeitversetzt vorgenommen, um die Funk-Kommunikation nicht unnötig zu belasten.

Mittels

<nowiki>attr <HM-CC-TC-Name> autoReadReg 1 </nowiki>
in der FHEM-Befehlszeile mit anschließendem <Enter> setzt man diesen Wert.

=== list ===
Um sich alle Eigenschaften/Readings eines Gerätes anzusehen, gibt es den Befehl [[list]].

Mittels

<nowiki>list <HM-CC-TC-Name></nowiki>
und Bestätigung mit <Enter> erhalten Sie die gewünschte Anzeige Ihres TCs <ins>incl.</ins> seiner 3 Channels. Über

<nowiki>list <HM-CC-TC-Name>_<Channel-Name></nowiki>
werden nur die Daten des angegebenen Channels angezeigt.

=== Einstellungen sichern ===
Die Durchführung von ''autoReadReg'' kann durchaus mehrere Minuten dauern. Anschließend besteht die Möglichkeit, diese per

<nowiki>get HM-CC-TC-Basisname saveConfig [/Verzeichnis/mit/Schreibrechten/]<Dateiname></nowiki>
für jedes HM-CC-TC getrennt zu sichern (für eine später notwendige Wiederherstellung). Die Sicherungsdatei wird regulär im ''modpath'' (siehe ''fhem.cfg'') abgelegt. Falls dies nicht zum Erfolg führt (es wird - ohne Fehlermeldungen bei regulärem ''verbose'' und ''loglevel'' - im ''modpath'' keine Datei angelegt), müssen Sie vor dem Dateinamen einen vollständigen Pfad mit Schreibrechten für den Benutzer, unter dem FHEM läuft, angeben.

In der <ins>Log-Datei</ins> von FHEM erscheinen danach Meldungen folgender Art

<nowiki><Datum>_<Zeit> 2: CUL_HM set <HM-CC-TC-Name> statusRequest rxt:12
<Datum>_<Zeit> 2: CUL_HM set <HM-CC-TC-Name> getConfig rxt:12</nowiki>
Hierbei kann es (im <ins>Event monitor</ins> von FHEM) zu folgenden Fehlermeldungen kommen

<nowiki><Datum>_<Zeit> CUL_HM <HM-CC-TC-Name> RESPONSE TIMEOUT:RegisterRead
<Datum>_<Zeit> CUL_HM <HM-CC-TC-Name> RESPONSE TIMEOUT:PeerList
<Datum>_<Zeit> CUL_HM <HM-CC-TC-Name> RESPONSE TIMEOUT:StatusReq</nowiki>
Diese Meldungen können auch mehrfach pro Gerät auftreten. Dann hat das Auslesen der Einstellungen nicht geklappt und sollte nochmals durchgeführt werden. Dafür muss man FHEM aber nicht neu starten, sondern das HM-Device per

<nowiki>set <HM-CC-TC-Name> getConfig</nowiki>
in der Befehlszeile von FHEM und anschließendem <Enter> (nicht "save") darauf einstellen.

Die Channels (z.B. <HM-CC-TC-Name>_Climate, _Weather, _WindowRec) eines HM-Gerätes brauchen nicht (können aber bei Bedarf) separat ausgelesen bzw. gesichert zu werden, da sie Bestandteil der Basisabfrage sind.

== Funkprobleme auffangen ==
Der wohl am häufigsten an den HM-CC-TC gesendete Befehl ist "set desired-temp", mit dem die Wunschtemperatur neu gesetzt wird.
Funktioniert dieser Befehl jedoch nicht zuverlässig, wird die Wohnung ggf. zu lange oder nicht rechtzeitig beheizt.
Der folgende Mechanismus soll die Sicherheit erhöhen, indem die Antworten des HM-CC-TC geprüft werden und ggf. das Funktelegramm erneut gesendet wird.

Um den Sollwert zum erneuten Senden des Funktelegramms verfügbar zu haben, wird ein dummy definiert:

<nowiki>define HM_TC_Solltemperatur dummy</nowiki>
Wann immer die Solltemperatur geändert wird, setzt man die neue desired-temp nicht nur auf dem HM-TC-CC (hier HM_TC genannt), sondern auch auf dem dummy. Der Befehl (z.B. in der [[Zuhause-Status|Routine zum HomeStatus]]) sieht dann so aus:

<nowiki>set HM_TC desired-temp 21;set HM_TC_Solltemperatur 21</nowiki>
Falls das ausgehende Funktelegramm verlorengeht, fehlt die Antwort "command accepted". Dies kann mit einem watchdog aufgefangen werden, der dann den Befehl an den HM-CC-TC erneut sendet:

<nowiki>define w_HM_TC watchdog HM_TC:set_desired-temp.* 00:02:30 HM_TC_Climate:CommandAccepted:.yes { \
Log 1, ">>>>>>>>> w_HM_TC desired temp - missing response.";\
fhem("set HM_TC desired-temp ".Value("HM_TC_Solltemperatur"));\
}</nowiki>
Falls ein Fehler bei der Funkkommunikation auftritt, erhält man die Antwort "missing ACK" oder "NACK". Auch in diesem Fall soll das Telegramm zum Ändern der Wunschtemperatur erneut an den HM-CC-TC gesendet werden:

<nowiki>define n_HM_TC_err notify HM_TC:(MISSING.ACK.*|.*NACK.*) {\
Log 1, ">>>>>>>>> n_HM_TC desired temp - missing ack/nack.\n";\
fhem("set HM_TC desired-temp ".Value("HM_TC_Solltemperatur"));\
}</nowiki>
Mit diesen beiden Helfern ist die Funkkommunikation zum HM-CC-TC sehr zuverlässig.

== Plots / Grafiken ==
=== Problem ===
Durch ''autocreate'' wird zwar ein Log angelegt, aber kein Plot (Grafische Auswertung). Dem kann man aber abhelfen (siehe unten).

=== Plots erzeugen ===
''PGM2'' ist die Standardansicht des FHEM-Web-Interfaces. Um hier Plots/Grafiken zu erzeugen einfach unter dem ''Filelog'' des Thermostaten das ''attr logtype'' auf ''temp4hum6:Plot,text'' setzen und es wird ein Plot-Link neben dem Text-Link angezeigt. Nun können Sie auf diesen Plot-Link klicken und ...

=== alternative Plots ===
Mit dem fht.gplot funktioniert die Anzeige der Ventilstellung (actuator) nicht.

Mit folgendem angepassten .gplot File wird die gemessene Temperatur und Ventilstellung angezeigt.

<nowiki>############################
# Display the measured temp and the actuator.
# Corresponding FileLog definition:
# define <filelogname> FileLog /var/log/fhem/actuator_name-%Y.log <actuator_name>:(measured-temp|actuator).*

set terminal png transparent size <SIZE> crop
set output '<OUT>.png'
set xdata time
set timefmt "%Y-%m-%d_%H:%M:%S"
set xlabel " "
set ytics nomirror
set y2tics
#set ytics
set title '<L1>'
set grid xtics y2tics

set y2label "Temperatur in C"
set ylabel "Ventil (%)"

#FileLog 4:measured:10:
#FileLog 4:actuator:50:

plot \
"< egrep 'temperature' <IN>"\
using 1:4 axes x1y2 title 'Temperatur in C' with lines,\
"< egrep 'actuator' <IN>"\
using 1:4 axes x1y1 title 'Ventil (%)' with lines\</nowiki>
=== Alles-drin-Plot ===
Dazu nimmt man folgendes .gplot (bitte beachten, dass hierfür alle Parameter nach der define-Anweisung in das Logfile geschrieben werden):

<nowiki>############################
# Display the measured temp and the actuator.
# Corresponding FileLog definition:
# define <filelogname> FileLog /var/log/fhem/HM_CC_TC-%Y.log <HM_CC_TC-name>
set terminal png transparent size <SIZE> crop
set output '<OUT>.png'
set xdata time
set timefmt "%Y-%m-%d_%H:%M:%S"
set xlabel " "
set ytics nomirror
set y2tics
#set ytics
set title '<L1>'
set grid xtics y2tics
set y2label "Temperature in C"
set ylabel "Actuator (%)"
#FileLog 4:temperature:0:
#FileLog 4:desired:0:
#FileLog 4:humidity:0:
#FileLog 4:actuator:0:int
plot \
"< awk '/temperature/{print $1, $4}' <IN>"\
using 1:2 axes x1y2 title 'Measured temperature' with lines lw 2,\
"< awk '/desired/{print $1, $4}' <IN>"\
using 1:2 axes x1y2 title 'Desired temperature' with steps,\
"< awk '/humidity/ {print $1, $4+0}' <IN>"\
using 1:2 axes x1y1 title 'Humidity (%)' with lines,\
"< awk '/actuator/ {print $1, $4+0}' <IN>"\
using 1:2 axes x1y1 title 'Actuator (%)' with lines\</nowiki>

Anmerkung: Möglicherweise ist die obige Definiton fehlerhaft. Im Forum wird in {{Link2Forum|Topic=14812|LinkText=diesem Thread}} dargelegt, dass die Definition vielmehr wie folgt lauten müsse:

<nowiki>############################
# Display the measured temp and the actuator.

# Corresponding FileLog definition:

# define <filelogname> FileLog /var/log/fhem/HM_CC_TC-%Y.log <HM_CC_TC-name>

set terminal png transparent size <SIZE> crop
set output '<OUT>.png'
set xdata time
set timefmt "%Y-%m-%d_%H:%M:%S"
set xlabel " "
set ytics nomirror
set y2tics
#set ytics
set title '<L1>'
set grid xtics y2tics
set y2label "Temperatur in °C"
set ylabel "Ventil (%)"
#FileLog 4:measured-temp:0:
#FileLog 4:desired-temp:0:
#FileLog 4:humidity:0:
#FileLog 4:actuator:0:int
plot \
"< awk '/temperature/{print $1, $4}' <IN>"\
using 1:2 axes x1y2 title 'Temperatur' with lines lw 2,\
"< awk '/desired/{print $1, $4}' <IN>"\
using 1:2 axes x1y2 title 'Wunschtemperatur' with steps,\
"< awk '/humidity/ {print $1, $4+0}' <IN>"\
using 1:2 axes x1y1 title 'Feuchte (%)' with lines,\
"< awk '/actuator/ {print $1, $4+0}' <IN>"\
using 1:2 axes x1y1 title 'Ventil (%)' with lines</nowiki>

== Steuerungsmodi ==
Das Wandthermostat hat 4 verschiedene Steuerungsmöglichkeiten:

* Auto (automatisch)
* Cent (Zentrale)
* Manu (manuell)
* Prog / Koffer-Symbol (Urlaubs/Party-Modus, wird hier nicht näher erörtert)

Der Steuerungsmodus wird über wiederholtes Drücken der linken Taste des HM-CC-TC ausgewählt bzw. gewechselt.

'''Hinweis:''' Durch das P'''ai'''ren des HM-CC-TC <ins>und</ins> der Stellantrieb sowie Tür-/Fensterkontakte an FHEM verlieren Sie '''nicht''' die Steuerungsmöglichkeiten. Im Gegenteil: Nur wenn auch die VDs usw. mit FHEM gep'''ai'''rt sind, haben Sie die Möglichkeit, auch diese zu überwachen. Die Steuerung '''können''' Sie dennoch allein dem HM-CC-TC überlassen.

=== Auto-Modus ===
Im Modus '''Auto''' wird die Temperaturregelung über die im TC hinterlegten Temperaturlisten vorgenommen. Das Thermostat arbeitet also selbständig, somit unabhängig von einer Zentrale / FHEM. Nur in diesem Modus werden die evtl. per FHEM an das TC übermittelten "templist" abgearbeitet. Über das Senden von angepassten Temperatur-Listen kann eine indirekte Steuerung per FHEM erfolgen. '''Jederzeit''' kann zudem die Raumtemperatur über das Drehrad des Wandthermostaten oder die FHEM-Web-Oberfläche verändert werden. Diese ''Übersteuerung'' der Temperaturliste gilt bis zur nächsten Temperaturänderung nach der vorgenannten Liste.

=== Cent-Modus ===
Im Modus '''Cent''' steuert eine HomeMatic-Zentrale (CCU) oder eben ein FHEM-Server mit z.B. [[HMLAN Konfigurator]] zu den in der FHEM-Config hinterlegten Zeiten und mit den dort festgelegten Temperaturen. Fällt also die HM-Zentrale aus, erfolgt keine Steuerung der Thermostaten bzw. Heizungsventile mehr.

<ins>Anmerkung</ins>: Der Modus ''cent'' erscheint nur dann im Display des HM-CC-TC, wenn er an eine Zentrale bzw. das [[CUL]] angelernt (gepairt) wurde.

=== Manu-Modus ===
Der Modus '''Manu''' übersteuert die im TC hinterlegten Temperaturlisten und die evtl. von der HM-Zentrale / dem FHEM <ins>vor Umstellung auf ''Manu''</ins> gesendeten Einstellungen. Es wird also bis zur nächsten Modusumstellung bzw. manuellen Temperaturverstellung der per Einstellrad gesetzte Temperaturwert gefahren.

Aber auch in diesem Modus kann man die ''desired-temperature'' per FHEM verstellen. Der dadurch eingestellte Wert gilt ab sofort als der neue im ''Manu-Modus'' zu haltende Wert.

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

set <HM-CC-TC> regSet btnLock on

Rückgängig machen geht per:

set <HM-CC-TC> regSet btnLock off

=== Auslesen des eingestellten Steuerungsmodus ===
Der eingestellte Steuerungsmodus erscheint normalerweise in den ''Readings'' des HM-CC-TC unter ''controlMode''. Zusätzlich haben Sie die Möglichkeit, diesen Modus auch in der FHEM-Weboberfläche ''everything'' => Abschnitt ''thermostat'' zu sehen, '''wenn''' Sie für den HM-CC-TC das folgende Attribut setzen:

<nowiki>attr <HM-CC-TC-Name> stateFormat T:measured-temp, H:humidity, VD:actuator, controlMode</nowiki>
Erscheint dort selbst nach einem

<nowiki>set <HM-CC-TC-Name> getConfig</nowiki>
kein "Reading" ''controlMode'' oder keine Angabe des aktuell eingestellten Modus bzw. nur das Wort "controlMode", dann setzen Sie ihren HM-CC-TC von Hand in einen anderen Kontrollmodus und machen einen Browser-Refresh. Klappt dies nicht, geben Sie bitte erneut den Befehl

<nowiki>set <HM-CC-TC-Name> getConfig</nowiki>
ein. Halten Sie anschließend die Taste <OK> am HM-CC-TC für 5 Sekunden gedrückt (oder warten ca. 5 Minuten) und machen in der FHEM-Weboberfläche einen Browser-Refresh (FF => <F5>). Jetzt sollte der manuell eingestellte Kontrollmodus erscheinen (ggfls. muss dieser Vorgang einmal wiederholt werden). Jetzt können Sie wieder den gewünschten Modus einstellen, erneut ein

<nowiki>set <HM-CC-TC-Name> getConfig</nowiki>
absetzen und nach erneutem Drücken der <OK>-Taste für 5 Sekunden mit nachfolgendem Browser-Refresh sollte alles richtig angezeigt werden.

Dies setzt natürlich voraus, dass der HM-CC-TC richtig gepairt ist.

== Temperaturlisten ==
Die Temperaturlisten des TC werden identisch mit denen anderer HomeMatic Thermostate verwaltet, siehe [[HomeMatic Type Thermostat#Temperaturlisten|HomeMatic Type Thermostat]].
Beim TC ist der Kanal 4 (_Climate) für die Temperaturlisten zuständig.

== Batteriealarme des HM-CC-VD in Verbindung mit HM-CC-TC ==
1. bei U-Bat. < 2,4 V erscheint im Display des VD und des TC das Batteriesymbol mit '''battery: low''' in den Readings und Events!

2. bei U-Bat. < 2,3 V erscheint im Display des VD zusätzlich '''F4''' mit '''battery: critical''' in den Readings und Events!

Es wird dringend geraten, die Batterien bei battery: low zu tauschen!

== Log-Auszug ==
HM-CC-TC sendet alle 2 Minuten folgenden Statusbericht:

<nowiki>Datum-Zeit <Device Name> T: 17.3 H: 66
Datum-Zeit <Device Name> measured-temp: 17.3
Datum-Zeit <Device Name> temperature: 17.3
Datum-Zeit <Device Name> humidity: 66
Datum-Zeit <Device Name> actuator: 96 %</nowiki>
Bei Status-Änderungen sendet HM-CC-TC auch entsprechende Meldungen, z.b.:

<nowiki>Datum-Zeit <Device Name> desired-temp: 15.5</nowiki>

= Probleme =

== Verstellen der Solltemperatur am HM-CC-TC per Drehrad ==

'''Symptom:''' Beim Verstellen der Solltemperatur per seitlichem Drehrad wurde die aktuelle Solltemperatur - '''egal ob''' man hoch oder runter drehte - immer nur in 0,5 °C Schritten '''runter''' gestellt, bis schließlich die Mindesttemperatur von 6,0 °C erreicht war. Weitere Änderungen waren nicht möglich

'''Abhilfeversuch:''' Letztlich half nur das kurzzeitige Entfernen einer Batterie. Das danach für einige Zeit erscheinende Batteriesymbol zeigte den kleinstmöglichen guten Zustand an, in FHEM wurde das ''Reading'' des Batteriezustandes mit ''ok'' ausgegeben (wie in den Logs aber vorher auch). '''Letztlich half aber nur''' das Einsetzen neuer Batterien, denn die o.a. Störung trat nach ca. 2 Stunden erneut auf. Die "alten" Batterien (die, die dem HM-CC-TC ab Werk beilagen) hatten somit eine Nutzungsdauer von knapp 11 Monaten, waren aber auch in einem HM-CC-TC, der mit 4 Stck. HM-Sec-SC (mussten sehr oft "Meldung machen") und 4 Stck. HM-CC-VD gepeert war. ''Ohne Last'' zeigten die beiden alten AA-Batterien eine Spannung von jeweils 1,29 V an.
'''Hinweis:''' Die unter ''Abhilfeversuch'' beschriebene Lösung war leider nur von kurzer Dauer. Bereits kurz danach zeigte der HM-CC-TC die gleichen Ausfallerscheinungen. Bei ELV gibt es das Bauteil für das Drehrad (Inkrementalgeber) als [http://www.elv.de/inkrementalgeber-fuer-fs20-str-fht-8-und-homematic-hm-cc-tc.html Ersatzteil]. Sobald dieses geliefert und ein Reparaturversuch unternommen wurde, wird an dieser Stelle weiter berichtet.

'''Abhilfe: Autausch des Inkrementalgebers [1]:''' Löst das Problem zu 70%. Ganz exakt reagiert er auch danach nicht. Teile des Problems scheinen also tiefer zu liegen.

Diese Anweisung ist nur für Fachpersonal in Elektronik geeignet, die über Erfahrung mit µ-Elektronik und einen ESD geeigneten Arbeitsplatz verfügen

Benötigtes Werkzeug (Erfahrene THT Löter brauchen evtl. nicht alles)

* Torx-Schraubendreher T7
* Seitenschneider für Elektronik
* Entlötsaugpumpe
* Sauglitze
* Lötzinn

# Batteriedeckel entfernen und Batterie entnehmen
# Auf der Rückseite vier Torx Schrauben lösen
# Rückseite abnehmen
# Acht Torx lösen (die drei um den Inkrementalgeber kommen später)
# Baugruppe von der Frontseite trennen. Hinweis: Das LCD ist mit Leitgummi mit der Leiterplatte verbunden. Es kann daher sein, dass das LCD auf der Baugruppe klebt. In diesem Fall vorsichtig abnehmen, nicht die Verbindungsfläche zur Leiterplatte berühren oder zum LCD berühren, der Handschweiß verringert die Leitfähigkeit und ein Ausfall des LCD kann die Folge sein.
# Drei Torx lösen, die das Handrad halten
# die fünf Füße des Inkrementalgeber mit dem Seitenschneider lösen
# Füße auslöten, Bohrungen mit Entlösaugpumpe und Sauglitze reinigen
# Neuen Inrementalgeber einlöten (Einbauseite beachten)
# In umgekehrter Reihenfolge wieder zusammenbauen

Auf Wunsch stelle ich auch Bilder rein, das ganze ist mechanisch aber nicht sehr anspruchsvoll. Wer löten kann sollte keine Probleme haben.

== HM-CC-TC misst zu hohe/niedrige Luftfeuchte-Werte oder Temperaturen > 100°C ==

'''Symptom:''' In den FHEM-Logs und demzufolge auch in den Plots/Grafiken eines seit über 18 Monaten im Einsatz befindlichen HM-CC-TC wurden viel zu hohe (einzelne Spitzenwerte von 98 oder 99 %) bzw. ständig zu niedrige (um die 20 oder sogar vereinzelt nur 2 %) Werte für die relative Luftfeuchte gemessen (im direkten Vergleich zu anderen HM-CC-TCs). Die anderen Werte (Temperatur, Actuator) waren aber schlüssig.

'''Abhilfe:''' Batteriewechsel. Die alten Batterien hatten (unbelastet) noch knapp über 1 V Spannung.

'''Hinweis:''' Eine Batteriewarnung des Gerätes gab es nicht. Im Display war das entsprechende Symbol noch auf 1 Balken.

= Firmware =
Aktuelle Firmware-Version: 2.1

= Links =
* [1] [https://web.archive.org/web/20150318044425/http://www.eq-3.de/Downloads/eq3/pdf_produkte/HM-CC-TC_UM_GE_eQ-3_110405.pdf Anleitung (PDF)] (Archiviert bei [https://www.archive.org/ Archive.org])
* [2] Ersatzteil Inkrementalgeber [http://www.elv.de/output/controller.aspx?cid=74&detail=10&detail2=41344 ELV]

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

Benutzer Diskussion:Morgennebel

2016-12-31T06:21:24Z

Krokofant: Neuer Abschnitt /* Homematic-Geräteübersicht */

== Willkommen! ==
{| width="100%" cellspacing="0" cellpadding="6" style="line-height: 20px; background: #E0E0E0; border: 2px solid #1874CD;"
|-
| colspan="4" style="background:#1874CD;" |<big>'''Hallo Morgennebel,''' willkommen im FHEM Wiki!</big>
|-
| colspan="4" | Danke für dein Interesse an unserem Projekt, ich freue mich schon auf deine weiteren Beiträge. Die folgenden Seiten sollten dir die ersten Schritte erleichtern, bitte nimm dir daher etwas Zeit, sie zu lesen.

----
'''FHEM-spezifische Informationen'''

|-
| width="8%" |  
| width="38%" | '''[[Systemübersicht]]''' ''FHEM Systemübersicht''
| width="8%" |  
| width="38%" | '''[[FHEMWiki:Über FHEMWiki]]''' ''Informationen über dieses Wiki''

|-
| colspan="4" |
----
'''Generelle Informationen über (Media)Wikis'''
|-
| width="8%" | [[Datei:Crystal Clear app kedit.svg|rechts|30px|link=Hilfe:Bearbeiten]]
| width="38%" | '''[[Hilfe:Bearbeiten]]''' ''Zugang zu allen wichtigen Informationen.''
| width="8%" | [[Datei:X-office-presentation.svg|rechts|30px|link=Wikipedia:Tutorial]]
| width="38%" | '''[http://de.wikipedia.org/wiki/Wikipedia:Tutorial Wikipedia:Tutorial]''' ''Schritt-für-Schritt-Anleitung für Einsteiger.''
|-
| [[Datei:Applications-system.svg|rechts|30px|link=Wikipedia:Grundprinzipien]]
| '''[http://de.wikipedia.org/wiki/Wikipedia:Grundprinzipien Wikipedia:Grundprinzipien]''' ''Die grundlegende Philosophie unseres Projekts.''
| [[Datei:MentorenProgrammLogo-7.svg|rechts|60px|link=Wikipedia:Mentorenprogramm]]
| '''[http://de.wikipedia.org/wiki/Wikipedia:Mentorenprogramm Wikipedia:Mentorenprogramm]''' ''Persönliche Einführung in die Beteiligung bei Wikipedia.''
|-
| colspan="4" |
----
Bitte beachte, [[Wikipedia:Was Wikipedia nicht ist|was Wikipedia nicht ist]], und "unterschreibe" deine Diskussionsbeiträge durch Eingabe von <code>--<nowiki>~~~~</nowiki></code> oder durch Drücken der Schaltfläche [[Datei:button_sig.png|Signaturknopf|20px|link=Hilfe:Signatur]] über dem Bearbeitungsfeld. Artikel werden jedoch nicht unterschrieben, und wofür die Zusammenfassungszeile da ist, erfährst du unter [[wikipedia:Hilfe:Zusammenfassung und Quellen|Hilfe:Zusammenfassung und Quellen]]. 
[[Datei:Nuvola apps ksirc.png|25px|link=Benutzer Diskussion:Ph1959de]]    '''Hast du Fragen an mich?''' Schreib mir auf [[Benutzer Diskussion:Ph1959de|meiner Diskussionsseite]]! Viele Grüße, [[Benutzer:Ph1959de|Greetz, Peter]] ([[Benutzer Diskussion:Ph1959de|Diskussion]]) 06:34, 30. Jan. 2014 (UTC)
|}

Regarding your contribution [[MAX!CubeMigrationToFhem‎]]: please make yourself familiar with the information about Wikis in general and this wiki in particular. How do you think, your new page should / could be found? It is not in any category, does not link to any other pages of this wiki and is not linked to from any other page of this wiki.

If you need help to get going here, please ask (as already mentioned in the welcome information above).

--[[Benutzer:Ph1959de|Greetz, Peter]] ([[Benutzer Diskussion:Ph1959de|Diskussion]]) 06:34, 30. Jan. 2014 (UTC)

== Max Cube Migration to Fhem ==

Hallo Morgennebel,

vielleicht kannst Du für deinen Migration-Artikel aus diesem Forenbeitrag noch Informationen sinnvoll verwenden: http://forum.fhem.de/index.php/topic,19473.msg131095.html#msg131095

--[[Benutzer:Ph1959de|Greetz, Peter]] ([[Benutzer Diskussion:Ph1959de|Diskussion]]) 11:19, 30. Jan. 2014 (UTC)

== Z-Wave-EVR ST812-Temperatur- und Feuchtesensor Inklusion ==
Hallo Morgennebel,
zunächst vielen Dank für Deinen obigen Zwave-Artikel. Wirklich gut gelungen. Eine Kleinigkeit ist für mich aber leider nicht verständlich:
Unter [[Z-Wave-EVR_ST814-Temperatur-_und_Feuchtesensor#Inklusion]] schreibst Du: "Bei der Verwendung von batteriegestützten USB-ZWave-Sticks (wie z.B. dem Aeon Labs Z-Wave-Stick) sollte die erste Inklusion sollte durch fhem erfolgen, wobei der USB-Stick im fhem-Server gesteckt sein sollte. Eine Inklusion mit dem USB-Stick alleine läßt fhem nicht die richtigen autocreate-Einträge erzeugen." Wenn Du mit nicht am Server angesteckten Stick inkludierst, sollte nach dem Anstecken des Sticks an den Fhem-Server mit dem Befehl <code> set <zwdongle> createNode <ID> </code> das Device in Fhem problemlos angelegt/definiert werden. Die Fhem-Definition sollte dann Deinem Vorgehen mit angesteckten Stick und <code> set <zwdongle> addNode on </code> entsprechen. Oder hast Du etwas anderes gemeint?

Viele Grüße, Christian --[[Benutzer:Krikan|Krikan]] ([[Benutzer Diskussion:Krikan|Diskussion]]) 03:35, 25. Nov. 2014 (UTC)

:Hi Christian,
:
:ich hab den Text zum Everspring etwas angepaßt und hoffe, es ist jetzt verständlicher. Der Tip mit dem eingesteckten USB-Stick richtet sich eher an die Einsteiger in :fhem und ZWave (obwohl ich fhem mit MAX! und Homematic kenne, finde ich ZWave recht herausfordernd).
:Danke für das Feedback --Morgennebel (Diskussion) 08:18, 25. Nov. 2014 (UTC)

::Hallo Morgennebel,
::habe eben die Handbücher im Artikel verlinkt und musste dabei feststellen, dass Du wohl über den STR81'''4''' geschrieben hast, statt über den STR812 (einen Z-Wave Wassersensor). Wenn ich richtig liege, könntest Du bitte den Artikel (komplett) nach Z-Wave-EVR_ST814-Temperatur-_und_Feuchtesensor verschieben oder einen Admin (bspw. [[Benutzer:Ph1959de|Peter]]) dazu um Hilfe bitten? Vielen Dank, Christian --[[Benutzer:Krikan|Krikan]] ([[Benutzer Diskussion:Krikan|Diskussion]]) 16:57, 7. Dez. 2014 (UTC)

== Vorschaufunktion ==
Hallo Morgennebel,

vielen Dank für Deine Beiträge zum Fhem-Wiki.
[[Datei:Vorschau (de).png|rechts|350px|verweis=Hilfe:Seite bearbeiten|Schaltfläche „Vorschau zeigen“]]
Mir ist aufgefallen, dass Du kurz hintereinander mehrere kleine Änderungen an einem Artikel vorgenommen hast. Solche sollten jedoch gesammelt durchgeführt werden, damit die [http://de.wikipedia.org/wiki/Wikipedia:Hilfe:Versionen Versionsgeschichte] für andere Benutzer übersichtlich und nachvollziehbarer bleibt. Daher ist es stets zu empfehlen, die Schaltfläche {{Taste|[http://de.wikipedia.org/wiki/Wikipedia:Hilfe:Seite_bearbeiten#Vorschau_und_Speichern Vorschau zeigen]}} unterhalb des Artikels zu benutzen (siehe Bild). Das erlaubt Dir zudem, Deine Änderungen auf Richtigkeit zu überprüfen, bevor Du sie durch Klicken auf {{Taste|Seite speichern}} veröffentlichst und sie in der Versionsgeschichte des Artikels sowie den [http://de.wikipedia.org/wiki/Wikipedia:Hilfe:Beobachtungsliste Beobachtungslisten] anderer Benutzer erscheinen.

Solltest Du eine größere Überarbeitung aus Sorge vor [http://de.wikipedia.org/wiki/Wikipedia:Hilfe:Bearbeitungskonflikt Bearbeitungskonflikten] in viele Einzeländerungen aufgeteilt haben, könnte der Textbaustein <nowiki>{{Baustelle}}</nowiki> nützlich sein.

Trage zudem vor dem Speichern bitte immer eine kurze Zusammenfassung der Änderungen in das Feld [http://de.wikipedia.org/wiki/Wikipedia:Hilfe:Zusammenfassung_und_Quellen Zusammenfassung] ein.

Danke und viele Grüße --[[Benutzer:Ph1959de|Peter]] ([[Benutzer Diskussion:Ph1959de|Diskussion]]) 15:48, 4. Feb. 2016 (CET)

== Homematic-Geräteübersicht ==

Hallo Morgennebel,

Danke für die Übersichtsseite, die werde ich wohl noch öfter besuchen.

Ein Vorschlag: Wie wäre es, wenn Du auch die Geräte ohne Wiki-Artikel mit aufführst? So zeigt die Übersicht diese Geräte als existent bzw. unterstützt und die Wiki-Autoren erkennen gleich am roten Link, wo noch etwas zu tun ist. In der Einleitung könnte man dann noch einen Satz unterbringen, der die roten Links erklärt. Glück auf, --[[Benutzer:Krokofant|Krokofant]] ([[Benutzer Diskussion:Krokofant|Diskussion]]) 07:21, 31. Dez. 2016 (CET)

HM-CC-VD Funk-Stellantrieb

2016-12-16T02:51:22Z

Krokofant: /* Allgemeines */ Peering,, Link

'''HM-CC-VD Funk-Stellantrieb'''

'''Achtung: Dieses Gerät ist abgekündigt (wird nicht mehr hergestellt). Nachfolgeprodukt ist der [[HM-CC-RT-DN]].'''

= Allgemeines =

Stellantrieb für den [[HM-CC-TC Funk-Wandthermostat|HM-CC-TC]]. Es können maximal 4 HM-CC-VD an ein HM-CC-TC angelernt werden.

Aktuelle Firmware: 2.0

Der HM-CC-VD '''misst nicht selbst''' die Temperatur. Diese wird von dem [[HM-CC-TC Funk-Wandthermostat]]

, mit dem der Stellantrieb [[Peering (HomeMatic)|gepeert]] wurde, gemessen.

= Probleme =

Bei Firmwareversionen vor 2.0 kann es vorkommen, dass sich der Stellantrieb bei einer bestimmten Stellung "festfährt" (z.B. 4%) und der Raum sich kontinuierlich erhitzt, obwohl eine niedrigere Temperatur am Wandthermostat eingestellt ist. Erst nach einem Reset des Stellantriebs oder manuellen Erhöhung der Temperatur am Wandthermostat/FHEM verrichtet der Stellantrieb wieder wie gewohnt seine Arbeit.

Quelle: [[http://www.elv.de/output/controller.aspx?cid=834&detail=2&detail2=582 1]]

Ein Firmwareupdate kann derzeit nur mittels Einschicken des Stellantriebs erfolgen.

Ist der Stellantrieb mit dem HM-CC-TC gepairt (zu sehen im Menü des HM-CC-TC als VST Nummer X), erscheint aber nicht in Fhem (hier mit HMLAN), dann hilft der Befehl ''set <HMLAN-Name> hmPairForSec 300'' und das Drücken des Anlernknopfes am HM-CC-VD für mind. 5 Sekunden.

= Betrieb mit FHEM =

HM-CC-VDs werden mit dem für ihren Betrieb/Raum zuständigen HM-CC-TC [[Peering (HomeMatic)|gepeert]]. Dadurch ist der TC für die Ansteuerung der Ventiltriebe da.

== Log-Daten ==
=== Device-Log ===

Zur Behebung des "1 bzw. 4 % Fehlers" wurde die Raumtemperatur über die Ansteuerung des HM-CC-TC temporär auf 28 °C erhöht. Nachdem das Thermostat (VD) laut Logs das Ventil auf hier 68 % geöffnet hat, wurde die Temperatur wieder auf die gewünschte (desired) Temperatur (am TC) gesetzt. Diese Befehle mussten allerdings einige Male wiederholt werden und es bedurfte einiger Minuten Wartezeit zwischen den Umstellungen.
<pre>
2013-03-18_22:34:57 OG.AZ.Thermostat set_0 %
2013-03-18_22:34:57 OG.AZ.Thermostat ValveDesired: 0 %
2013-03-18_22:34:58 OG.AZ.Thermostat ValvePosition: 1 %
2013-03-18_22:34:58 OG.AZ.Thermostat 1 %
2013-03-18_22:34:58 OG.AZ.Thermostat battery: ok
2013-03-18_22:34:58 OG.AZ.Thermostat motorErr: ok
2013-03-18_22:34:58 OG.AZ.Thermostat motor: stop
2013-03-18_22:34:58 OG.AZ.Thermostat operState: errorTargetNotMet
2013-03-18_22:34:58 OG.AZ.Thermostat operStateErrCnt: 1
2013-03-18_22:37:42 OG.AZ.Thermostat set_68 %
2013-03-18_22:37:42 OG.AZ.Thermostat ValveDesired: 68 %
2013-03-18_22:37:43 OG.AZ.Thermostat ValvePosition: 1 %
2013-03-18_22:37:43 OG.AZ.Thermostat 1 %
2013-03-18_22:40:20 OG.AZ.Thermostat set_68 %
2013-03-18_22:40:20 OG.AZ.Thermostat ValveDesired: 68 %
2013-03-18_22:40:22 OG.AZ.Thermostat ValvePosition: 68 %
2013-03-18_22:40:22 OG.AZ.Thermostat 68 %
2013-03-18_22:40:22 OG.AZ.Thermostat battery: ok
2013-03-18_22:40:22 OG.AZ.Thermostat motorErr: ok
2013-03-18_22:40:22 OG.AZ.Thermostat motor: stop
2013-03-18_22:40:22 OG.AZ.Thermostat operState: onTarget
2013-03-18_22:42:31 OG.AZ.Thermostat set_0 %
2013-03-18_22:42:31 OG.AZ.Thermostat ValveDesired: 0 %
2013-03-18_22:42:33 OG.AZ.Thermostat ValvePosition: 68 %
2013-03-18_22:42:33 OG.AZ.Thermostat 68 %
2013-03-18_22:42:33 OG.AZ.Thermostat battery: ok
2013-03-18_22:42:33 OG.AZ.Thermostat motorErr: ok
2013-03-18_22:42:33 OG.AZ.Thermostat motor: closing
2013-03-18_22:42:33 OG.AZ.Thermostat operState: adjusting
2013-03-18_22:44:34 OG.AZ.Thermostat set_0 %
2013-03-18_22:44:34 OG.AZ.Thermostat ValveDesired: 0 %
2013-03-18_22:44:36 OG.AZ.Thermostat ValvePosition: 0 %
2013-03-18_22:44:36 OG.AZ.Thermostat 0 %
</pre>

=== Event monitor ===
<pre>
2013-03-18 22:42:33 CUL_HM OG.AZ.Thermostat motor: closing
2013-03-18 22:42:33 CUL_HM OG.AZ.Thermostat operState: adjusting
</pre>

== Batteriealarme des HM-CC-VD in Verbindung mit HM-CC-TC ==
1. bei U-Bat. < 2,4 V erscheint im Display des VD und des TC das Batteriesymbol mit battery: low in den Readings und Events!
2. bei U-Bat. < 2,3 V erscheint im Display des VD zusätzlich F4 mit battery: critical in den Readings und Events!
Es wird dringend geraten, die Batterien bei battery: low zu tauschen!

= Links =
Anleitung: [http://www.eq-3.de/Downloads/eq3/downloads_produktkatalog/homematic/bda/HM-CC-VD_UM_GE_eQ-3_081013.pdf HM-CC-VD Funk-Stellantrieb]

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

Anwesenheitserkennung

2016-12-08T18:46:08Z

Krokofant: /* Alle Räume gemeinsam ansprechen (collectord) */ Link zur Commandref

Viele Benutzer führen bereits eine eigene '''Anwesenheitserkennung''' durch. Diese basiert in den meisten Fällen auf Ping Checks oder bei [[AVM Fritz!Box|FritzBoxen]] auf dem Befehl ''ctlmgr_ctl''. Diese Lösungen können aber je nach Aufbau und Funktion FHEM massiv beeinträchtigen. Aufgrund des Aufbaus vom FHEM kann dieses dadurch für mehrere Sekunden zum völligen Stillstand gebracht werden.

In FHEM gibt es mittlerweile mehrere Module, die eine zuverlässige Anwesenheitserkennung bieten, ohne dabei FHEM bei der Ausführung zu beeinträchtigen.

Eine erweiterte Funktion der Anwesenheitserkennung ist die Standortverfolgung, die sich nicht nur auf ein oder sehr wenige mit (eigenem) WLAN versorgte Gebiete beschränkt.

== Vorüberlegungen ==
Generell gibt es mehrere Ansätze um Anwesenheitserkennung mit Handys/Smartphones durchzuführen.

* via PING Checks im gesamten WLAN
* Aktivitätsprüfung auf einer FritzBox
* Bluetooth Checks in der gesamten Wohnung
* eigene Perl-Funktion
* aktive Benachrichtigung des Smartphones, ausgelöst z.B. über Geo-Lokation/Geofence

Dabei gilt bei der Auswahl der Art darauf zu achten wie sich das jeweilige Device verhält. Aufgrund der Vielfältigkeit kann man hier keine allgemeine Vorgehensweise empfehlen. Als einfacher Start (zumindest für Nicht-Apfel Telefone) eignet sich die Ping-Überprüfung und die FritzBox-Abfrage sehr gut.

=== Randbedingungen ===
Es gibt Geräte, die ihr WLAN/Bluetooth auch im Standby ständig aktiv haben und auf Anfragen antworten können (fast alle Android-Geräte). Gerade bei Tests über WLAN kann sich das aber signifikant auf die Akku Leistung auswirken.

Andere Geräte wiederum schalten WLAN im Standby Betrieb aus, um Akkukapazität zu sparen. Bluetooth hingegen bleibt weiterhin aktiviert und kann auf Anfragen reagieren. (iPhone)

Wenn man bei einem iPhone die Funktion "über WLAN synchronisieren" aktiviert hat, so ist dies auch im Standby jederzeit pingbar, wenn der Recher auf dem iTunes zum synchroniseren läuft auch an ist. Ansonsten ist bei iPhone Geräten nur die Aktivitätsprüfung mit einer FritzBox oder das überwachen der DHCP Lease auf einer Airport Basestation wirklich zuverlässig.

Auch wenn Bluetooth aktiviert ist, so bleiben einige Mobiltelefone erst dann empfangsbereit, wenn sie bereits zu irgend einem Bluetoothgerät gekoppelt wurden. Sind diese Geräte noch nie gekoppelt worden, deaktivieren diese ihren Bluetooth Empfänger beim verlassen des Bluetooth-Menüs im Gerät (iPhone).

Hier gilt es vor allem auszuprobieren, wie stark der Akku durch eine Anwesenheitserkennung belastet wird. Entscheidend ist hier, in welchem Abstand man eine Anwesenheitserkennung durchführt. Viele Abfragen wirken sich stärker auf den Akku aus als wenige. Wenige Abfragen bieten aber keine zuverlässige und zeitnahe Erkennung.

Als Alternative, unabhängig vom WLAN und der Erkennung, ob ein Gerät dort eingebucht ist oder nicht, bzw. unabhängig von Bluetooth kann zumindest bei einem iPhone die seit iOS 7 nochmals stark verbesserte Geo-Lokation (Geofencing) genutzt werden. Die iPhone Apps [http://geofency.com/ Geofency] oder [http://geofancy.com/ Geofancy] werden über das FHEM-Modul GEOFANCY angebunden und übertragen ihren Status immer dann, wenn ein definierter Standort betreten oder verlassen wird. Gekoppelt mit entsprechenden Notify und/oder Watchdog Kommandos ist so ebenfalls eine sehr zuverlässige Anwesenheitserkennung möglich (und das nicht nur für das eigene Zuhause).

== Das PRESENCE Modul ==
Das [[PRESENCE]] Modul bietet für die Anwesenheitserkennung mehrere Varianten an. Diese sind aktuell folgende:

* '''lan-ping''' - Das Überwachen via PING Checks, die durch den FHEM Server versandt werden.
* '''fritzbox''' - Das Überwachen von Geräten auf einer FritzBox via ctlmgr_ctl (Nur auf einer FritzBox möglich)
* '''local-bluetooth''' - Das Überwachen via Bluetooth Checks, die vom FHEM Server direkt durchgeführt werden (angeschlossener Bluetooth-Stick und die Software bluez voraussgesetzt)
* '''lan-bluetooth''' - Das Überwachen von Bluetoothgeräte, über Netzwerk. Auf einer oder mehreren Maschinen im Netzwerk (z.B. [[:Kategorie:Raspberry Pi|Raspberry Pi]]) läuft ein Presence-Daemon, der nach Bluetooth-Geräten sucht. Um mehrere Presence-Daemon mit FHEM zu verbinden, gibt es den Collector-Daemon, der sich zu allen Presence-Damons im Netzwerk verbindet und das Ergebnis von allen zusammenfasst.
* '''function''' - Das Überwachen mithilfe einer selbst geschrieben Perl-Funktion, die den Anwesenheitsstatus zurückgibt (0 oder 1)
* '''shell-script''' - Das Überwachen mithilfe eines selbst geschriebenen Shell-Programms/Skript, das eine 0 oder 1 ausgibt, um den Anwesenheitsstatus mitzuteilen.

=== Ping-Überwachung von Geräten im WLAN/LAN ===
{{Randnotiz|RNText=Um diese Methode auf einer FritzBox nutzen zu können, muss FHEM mit root-Rechten laufen. Dies ist standardmäßig nicht der Fall. Bitte dazu den Wiki Artikel [[FritzBox: fhem unter root starten]] beachten.}}
Um ein Gerät via Ping zu überwachen, muss folgende Definition durchgeführt werden:
:<code>define Handy PRESENCE lan-ping 192.168.0.30</code>

Dadurch wird die IP-Addresse 192.168.0.30 alle 30 Sekunden geprüft, ob sie erreichbar ist. Wenn sie erreichbar ist, ist der Status "present" (anwesend), ansonsten "absent" (abwesend).

Der Timeout kann verändert werden, indem ein Wert (in Sekunden) an das Define anhängt wird:
:<code>define Handy PRESENCE lan-ping 192.168.0.30 '''60'''</code>

Nun würde das Handy alle 60 Sekunden geprüft werden.

Nur wenn bei einem iPhone/iPad die Funktion "über WLAN synchronisieren" aktiviert ist, ist es auch im Standby zuverlässig pingbar. Standardmäßig deaktivieren Apple-Geräte ihr WLAN im Standby-Betrieb um die Akkulaufzeit zu verlängern.

Sollte die Fehlermeldung
:<code> PRESENCE (Handy) - ping command returned with output: ping: icmp open socket: Operation not permitted </code>
im Log auftauchen und lan-ping dadurch nicht funktionieren, liegt ein Berechtigungsproblem vor. Kein Grund den User fhem zu root zu machen!
So sollten die Berechtigungen aussehen
:<code>sudo ls -la /bin/ping</code>
unter Jessie
:<code>-rwxr-xr-x 1 root root 38844 Feb 12 2014 /bin/ping</code>
unter Wheezy
:<code>-rwsr-xr-x 1 root root 33220 Mär 30 2012 /bin/ping</code>
Sollte es trotzdem unter Jessie nicht funktionieren kann man auch dort die Berechtigung analog wheezy setzen:
:<code>sudo chmod u+s /bin/ping</code>

=== FritzBox: direktes Abfragen der Aktivität via ctlmgr_ctl ===
{{Randnotiz|RNText=Um diese Methode auf einer FritzBox nutzen zu können, muss FHEM mit root-Rechten laufen. Dies ist standardmäßig nicht der Fall. Bitte dazu den Wiki Artikel [[FritzBox: fhem unter root starten]] beachten.}}
Eine sehr häufige und auch zuverlässige Methode ist auf einer FritzBox die Abfrage mittels ctlmgr_ctl Befehl. Über diesen lassen sich alle Geräte abfragen ob sie aktiv sind. Ist ein Gerät aktiv, so gilt es als anwesend.

Dieser Modus kann allerdings nur in FHEM Installationen direkt auf einer FritzBox verwendet werden. Des weiteren muss FHEM unter dem User root laufen. Um ein Gerät zu überwachen, wird lediglich der Gerätename benötigt, so wie er unter dem Menüpunkt "Heimnetz" auftaucht.

Die erforderliche Definition:
:<code>define Handy PRESENCE fritzbox iPhone-4S</code>

=== Bluetooth-Überwachung von Geräten durch den FHEM Server ===
[[Datei:Bluetooth-Adresse-iPhone.png|thumb|Bluetooth-Adresse eines iPhones]]
Jenach Aufstellungsort des FHEM Servers kann es sinnvoll sein, eine Bluetooth-Überwachung direkt durch den FHEM Server durchzuführen. Hierbei gilt allerdings zu beachten, dass Bluetooth nicht für große Reichweiten gedacht ist und in den meisten Fällen keine Wände überwinden kann. Das heisst, dass in den meisten Fällen damit nur ein Raum überwacht werden kann.

Je nach Einsatzzweck kann das auch so gewollt sein. Bluetooth USB Sticks, die bereits Bluetooth 4.0 unterstützen, können höhere Reichweiten über Zimmerwände hinaus erreichen. Vorausgesetzt, das Mobilgerät unterstützt Bluetooth 4.0.

Um eine Überwachung per Bluetooth durchführen zu können, benötigt man die Bluetooth-Adresse eines Gerätes. Diese ähnelt vom Aufbau einer MAC-Adresse. Generell wird die Adresse in den Telefon-Informationen bei Smartphones angezeigt.

Um eine Anwesenheitserkennung via Bluetooth durchzuführen, wird folgende Definition in der [[Konfiguration]] benötigt:
:<code>define Handy PRESENCE local-bluetooth XX:XX:XX:XX:XX:XX</code>

=== Bluetooth-Überwachung von Geräten durch verteilte Agenten in der Wohnung (presencd/collectord) ===
[[Datei:Raspberry-Pi-mit-WLAN-und-Bluetooth-Stick.jpg|thumb|left|Raspberry Pi mit Bluetooth- und WLAN-USB-Stick]]
Um eine zuverlässige und flächendeckende Bluetooth-Anwesenheitserkennung durchzuführen, ist es unerlässlich, mehrere Bluetooth-Empfänger zu verwenden, die auf mehrere oder alle Räume verteilt sind.

Hierfür bietet sich zum Beispiel ein [[Raspberry Pi]] mit einem Mini-Bluetooth-USB-Stick und evtl. einem WLAN-USB-Stick an. Jeder Raum wird mit solch einem Raspberry ausgestattet und ist im WLAN Netz verfügbar.

Dieses Netz aus Raspberrys wird mit dem presenced (Download-Link ist in der [http://fhem.de/commandref_DE.html#PRESENCE Commandref] zum Modul enthalten) ausgestattet. Es stehen bereits entsprechende Pakete für den Raspberry zur Verfügung.

Beide Programme (presenced/collectord) sind Perl-Skripte, die als Daemon im Hintergrund laufen und auf Anfragen via Netzwerk warten. Es wird lediglich eine vollständige Perl-Grundinstallation mit Standardmodulen benötigt. Nach Installation der *.deb Pakete sollten diese noch angewiesen werden, automatisch beim Rechner-Neustart gestartet zu werden:

<pre>
sudo update-rc.d presenced defaults
sudo update-rc.d collectord defaults
</pre>

Eine detaillierte Benutzung von presenced ist in der [http://fhem.de/commandref_DE.html#PRESENCE Commandref] Beschreibung zum PRESENCE Modul enthalten.

==== Jeden Raum einzeln ansprechen (presenced) ====
Nun kann zuallererst jeder Raum einzeln angesprochen werden. Dabei ist zu beachten, dass pro Definition in der Konfiguration nur ein Gerät in einem Raum spezifisch überwacht werden kann.

Eine Definition sieht dabei folgendermaßen aus:
:<code>define Handy_Wohnzimmer PRESENCE lan-bluetooth XX:XX:XX:XX:XX:XX 192.168.0.10:5111</code>

Damit wird nun das Gerät nur im Wohnzimmer (Raspberry mit IP 192.168.0.10) überwacht.

==== Alle Räume gemeinsam ansprechen (collectord) ====
Um jedoch alle Räume gemeinsam zu verwenden, gibt es den Collector-Daemon. Dieser kennt alle presenced-Installationen im Netzwerk und führt eine koordinierte Suche nach den gewünschten Geräten durch. Sobald ein Gerät in einem Raum erkannt wurde, meldet der collectord den Status einschließlich der Angabe des Raumes, in dem das Gerät erkannt wurde.

Um alle Räume zu kennen, müssen diese mit einem Config-File dem collectord mitgeteilt werden. Dieses sieht folgendermaßen aus:

<pre>
[Schlafzimmer] # Name des Raumes (wird in FHEM als Reading angezeigt)
address=192.168.179.31 # IP-Adresse oder Hostname des presenced
port=5111 # TCP Port, der verwendet werden soll (standardmäßig Port 5111)
presence_timeout=120 # Prüfinterval, das verwendet werden soll, wenn ein Gerät anwesend ist
absence_timeout=20 # Prüfinterval, das verwendet werden soll, wenn ein Gerät abwesend ist

[Wohnzimmer]
address=192.168.179.34
port=5111
presence_timeout=180
absence_timeout=20
</pre>

Standardmäßig ist dieses Config-File unter /etc/collectord.conf zu finden. Mit dieser Konfiguration kann der Collectord gestartet werden. Es empfiehlt sich diesen mit auf dem FHEM Server zu betreiben. Die erforderliche Definition in der Fhem-Konfiguration:
:<code>define Handy PRESENCE lan-bluetooth XX:XX:XX:XX:XX:XX 127.0.0.1:5222</code>

Sobald das Handy irgendwo in der Wohnung erkannt wurde, meldet der Collectord dies sofort an FHEM und teilt den Raum mit.

Eine detaillierte Benutzung von collectord findet man in der [http://fhem.de/commandref.html#PRESENCE Commandref zum PRESENCE Modul].

=== Überwachung von Geräten mit Perl-Code ===
Es ist möglich zum Überwachen von Geräten eine eigene Perl-Funktion zu verwenden die dann vom PRESENCE Modul im Hintergrund aufgerufen wird.

define <name> PRESENCE function {...} [ <check-interval> [ <present-check-interval> ] ]

Sobald die Funktion den Rückgabewert 1 hat, ist das Gerät anwesend, bei 0 abwesend.

==== Beispiel DHCP Überwachung auf Airport Basestation ====
Die hier vorgestellte Überwachung der DHCP Lease auf Airport Basestations per SNMP ist absolut robust gegenüber dem Ruhezustand von iOS und setzt keine weitere Konfiguration auf dem iPhone voraus. Das Abmelden beim Verlassen des Empfangsbereiches der Basestation geschieht mit etwa 5-10 Minuten Verzögerung und ist somit auch vor kurzzeitigen Empfangsproblemen sicher. Das nebenstehende Bild (???) verdeutlicht noch mal die Unterschiede zwischen einer IP-Basierten Ping-Überwachung und der Überwachung auf Ebene der Basestation oder FritzBox.

Bevor der folgende Code verwendet werden kann ist das Perl Modul Net:SNMP zu installieren (z. B. mit: <code>cpan install use Net::SNMP</code>).

Zuerst ist folgender Code in 99_myUtils.pl einzufügen:

<pre>
use Net::SNMP;
sub
snmpCheck($$)
{
my ($airport,$client)= @_;

my $community = "public";
my $host = $airport;
my $oid = ".1.3.6.1.2.1.3.1.1.2";
#my $oid = ".1.3.6.1.2.1.3.1.1.2.25.1.10.0.1";

my ( $session, $error ) = Net::SNMP->session(
-hostname => $host,
-community => $community,
-port => 161,
-version => 1
);

if( !defined($session) ) {
return 0;
return "Can't connect to host $host.";
}

my @snmpoids = ();

my $response = $session->get_next_request($oid);
my @nextid = keys %$response;
while ( @nextid && $nextid[0] && $nextid[0] =~ m/^$oid/ ) {
push( @snmpoids, $nextid[0] );

$response = $session->get_next_request( $nextid[0] );
@nextid = keys %$response;
}

if( !defined($response = $session->get_request( @snmpoids ) ) ) {
return 0;
}

foreach my $value (values %$response) {
return 1 if( $value eq $client )
}

return 0;
}
</pre>

Danach lässt sich das Mobilgerät so überwachen:
:<code>define iPhone PRESENCE function {snmpCheck("10.0.1.1","0x44d77429f35c")} 30 30</code>

wobei 10.0.1.1 durch die IP-Adresse der Basestation und 0x44d77429f35c durch die MAC Adresse des Geräts als HEX-Zahl ersetzt werden muss.

== Das GEOFANCY Modul ==
Das Modul ermöglicht über einen sogenannten Webhook Mechanismus (umgangssprachlich oft auch als "Push" benannt) das aktive Melden des aktuellen Standortes. Die iPhone Apps [http://geofency.com/ Geofency] und [http://geofancy.com/ Geofancy] können dann aktiv und quasi in dem Moment, wo man den Wohnbereich betritt oder verlässt, benachrichtigen. Android Nutzern können [https://play.google.com/store/apps/details?id=de.egi.geofence.geozone&hl=de EgiGeoZone Geofence] nutzen. Das geht nochmals um einiges schneller, als die Erkennung im WLAN, bei der die Anwesenheit nur in (engen) Zyklen aktiv geprüft werden muss. Gleichzeitig werden Ressourcen in FHEM geschont. Die aktuelle Implementierung im iPhone 5S mit dediziert für das Tracking zuständigem Chip ist so gut, dass der Akku ebenfalls sehr geschont wird.

=== Modul in FHEM einrichten ===
Das Modul ist mit einer einfachen Definition sofort betriebsbereit:
:<code>define geofancy GEOFANCY geo</code>

Damit nimmt FHEM unter <nowiki>http://192.168.178.1:8083/fhem/geo</nowiki> entsprechende Meldungen des iPhones entgegen. Damit das nicht nur über das lokale WLAN funktioniert, bedarf es allerdings noch einiger zusätzlicher Maßnahmen. FHEM muss vom Internet erreichbar gemacht werden, dabei sollte unbedingt an die Absicherung des Zugriffs gedacht werden.

Zunächst einmal habe ich bei mir eine eigene FHEMWEB Instanz dafür angelegt:
<pre>
define WEBhook FHEMWEB 8088 global
attr WEBhook column Alarms: Apartment: Living: Bedroom: Kitchen: Sonos: Residents: Weather: Bathroom: Logs: Statistics: DashboardRoom: System: hidden: all:
attr WEBhook hiddenroom input,detail,save,Unsorted,Everything,CUL_HM,FS20,Commandref,style,Edit files,Select style,Logfile,Floorplans,Remote doc,FileLogs,Apartment,Bathroom,Bedroom,Kitchen,Living,Residents,System,Weather,Event monitor,NEW
attr WEBhook room hidden
attr WEBhook webname webhook
</pre>

Damit ist unter der URL <nowiki>http://192.168.178.1:8088/webhook/geo</nowiki> das GEOFANCY Modul erreichbar. Ich verstecke in dieser Ansicht noch alle Räume, die ich so habe. Wer die Raumnamen allerdings kennt, kann sie trotzdem aufrufen. Die Anzeige in den Räumen kann man mit dem Attribut column und entsprechend leeren Definitionen verstecken. Nun muss man explizit den Devicenamen kennen, um noch etwas über die Konfiguration in Erfahrung bringen zu können.
Auch wenn das Security-by-Obscurity ist - ich fühle mich wohler damit.

=== Webhook weiter absichern ===
Mit Hilfe eines [http://fhem.de/commandref.html#allowed allowed]-Devices lässt sich die FHEMWEB Instanz noch weiter absichern indem nur die tatsächlich benötigten Kommandos erlaubt werden (in diesem Fall keine) und damit alle anderen nicht erlaubten (attr,define,get,set,...) automatisch nicht mehr zur Verfügung stehen:
<pre>
define allowedWEBhook allowed
attr allowedWEBhook allowedCommands ,
attr allowedWEBhook allowedDevices ,
attr allowedWEBhook validFor WEBhook
</pre>

Außerdem ist dringend zu empfehlen, den Zugriff über TLS/SSL und HTTP Basic-Authentication weiter abzusichern. Läuft FHEM auf einem Raspberry Pi, dann empfehle ich dazu die Konfiguration eines ReverseProxy (vorzugsweise HAproxy, Pound oder Varnish, notfalls auch Nginx oder Apache); damit ist man am flexibelsten und kann auch alle FHEMWEB Instanzen direkt über einen einzigen Port (meist 443, der HTTPS Standard Port) zusammenfassen. Ich möchte hier allerdings beschreiben, wie weit man mit FHEM Bordmitteln kommt und nehme das Beispiel einer Installation auf einer Fritzbox.

Wie TLS aktiviert wird, steht in der Commandref für [[FHEMWEB]]. Um die Kommandos auf der Fritzbox ausführen zu können, muss zuerst Telnet aktiviert werden (bitte Google benutzen). Anschließend wechselt man auf der Fritzbox ins Verzeichnis /var/media/ftp/fhem und kann dann den Hinweisen aus der [http://fhem.de/commandref.html#FHEMWEB Commandref] unter dem Punkt HTTPS folgen. Letztlich fehlt noch das entsprechende Attribut:

<pre>
attr WEBhook HTTPS
</pre>

Als nächstes aktivieren wir Benutzername+Passwort für den Zugriff. Die commandref für allowed gibt auch hier unter dem Punkt basicAuth entsprechende Hinweise. Wir fügen hier einfach mal einen Benutzer "webhook" mit dem Passwort "Geofancy" hinzu, das sieht dann so aus:

<pre>
attr allowedWEBhook basicAuth { "$user:$password" eq "webhook:Geofancy" }
</pre>

Weitere Infos zur Absicherung gibt auch [[FritzBox Webzugriff absichern]].

Um zu testen, ob unsere Absicherung erfolgreich war, kann man die URL <nowiki>https://192.168.178.1:8088/webhook/geo</nowiki> aufrufen (wichtig ist, dass man jetzt https und nicht mehr http eingibt; ansonsten bekommt man keine Antwort). Eine Zertifikatswarnung kann getrost ignoriert werden, verschlüsselt wird trotzdem. Es sollte auch eine Passwort Abfrage kommen und die Eingabe der entsprechenden Daten sollte dann zu einer entsprechenden Meldung vom GEOFANCY Modul führen:

<pre>
NOK No data received, see API information on http://wiki.geofancy.com
</pre>

Das ist ok, schließlich sind wir keine App, sondern der Mensch, der nur mal eben prüfen will :-)

=== Zugriff vom Internet ermöglichen ===
Das ist je nach Fritzbox und Software Version unterschiedlich. Grundsätzlich gilt: Eine Weiterleitung des ports 8088 vom Internet auf das laufende FHEM auf Port 8088 intern ist von AVM so nicht vorgesehen.
Bei mir führte folgendes zum Erfolg:

* Einloggen per Telnet auf der Fritzbox (ich habe FritzOS 6 installiert)
* Konfiguration editieren mittels "nvi /var/flash/ar7.cfg"
* Suchen nach richtiger Zeile durch Eingabe von "/internet_forwardrules" und Enter
* Hinzufügen einer weiteren Zeile (Vorsicht, die bestehende Zeile endet mit ; und das muss in , umgeändert werden, so dass das ; schließlich am Ende der Zeile steht.

So sieht es bei mir vorher aus:
:<code>internet_forwardrules = "tcp 0.0.0.0:488 0.0.0.0:488 0";</code>
Hinterher:
:<code>internet_forwardrules = "tcp 0.0.0.0:488 0.0.0.0:488 0", "tcp 0.0.0.0:8088 0.0.0.0:8088 0";</code>

Danach mittels ":x" abspeichern und sofort per "reboot" die Box neu starten, um diese Änderungen zu aktivieren. Das ist wichtig; ansonsten zeigt die Erfahrung, dass die Änderung nicht dauerhaft erhalten bleibt und die gerade gemachten Änderungen verloren gehen.

Wer die Einstellungen zu "internet_forwardrules" bei sich nicht finden kann, hat womöglich eine andere Version als ich oder ein leicht anderes Gerät und bemüht am besten Google, was er tun kann, um das Gleiche zu erreichen. Möglicherweise tauchen die Einträge auch erst auf, wenn man mal über das Webinterface ein Forwarding eingerichtet hatte.

Hat man einen DynDNS Dienst oder myFritz auf der Fritzbox aktiviert, so kann man jetzt auch von draußen auf den Webhook zugreifen. Das kann man prüfen, indem man das iPhone aus dem WLAN ausbucht und einmal die externe Adresse eingibt, also z.B. https://meindyndns.org:8088/webhook/geo.

=== Weitere Alternativen für den Zugriff aus dem Internet ===
Als Alternative zum Port Forwarding kann man sich auch per VPN in das lokale Netzwerk einwählen. iOS bietet dazu auch eine automatische Aktivierung des VPN (VPN on Demand), wie z.B. [http://forum.loxone.com/dede/netzwerk-firewall-and-security/8121-vpn-demand-ios-8-1-1-fritz-box-kleine-how.html hier] beschrieben wird.

Auch eine Alternative ist, das Portforwarding nicht direkt an FHEM einzurichten, sondern an einem im Netzwerk laufenden Reverse-Proxy, der dann seinerseits die Anfragen an FHEM weiterleitet. Dies kann z.B. Apache, Nginx oder am besten HAproxy sein.
Letzterer ist dabei sehr flexibel, allerdings nicht unbedingt einfach zu konfigurieren. Ein paar Inspirationen diesbezüglich gibt es z.B. [https://github.com/Hoanoho/HSE/tree/develop/lib/cfg/any/stat/etc/haproxy hier] und [https://github.com/Hoanoho/HSE/tree/develop/lib/cfg/any/dyn/etc/haproxy hier]. Wer pfSense nutzt, findet [http://loredo.me/post/116633549315/geeking-out-with-haproxy-on-pfsense-the-ultimate diesen Artikel] womöglich auch interessant. Er zeigt auch, dass mit HAproxy noch weit mehr möglich ist.
Der Reverse-Proxy sollte dabei auch unbedingt der TLS Termination Point sein (TLS Offloading). Nicht nur spart man sich dann die Aktivierung von TLS in FHEM, sondern man hat auch mehr Einfluss darauf, wie TLS arbeitet (z.B. Deaktivierung von SSLv3, forcieren von TLSv1.2, nur als sicher eingestufte Cipher Suite... siehe auch Infos auf der [https://wiki.mozilla.org/Security/Server_Side_TLS Mozilla Website]).

=== Einrichten in der Geof[e|a]ncy.app ===
Hat das alles soweit geklappt, können endlich in der Geofency.app bzw. Geofancy.app am iPhone die gewünschten Bereiche definiert werden. Am Besten zuvor in den Global Settings die folgenden Einstellungen hinterlegen:

* URL: https://meindyndns.org:8088/webhook/geo
* POST (oder GET, ist egal - das FHEM Modul kann beides)
* HTTP Basic Authentication: EIN (entsprechend Username und Password eintragen)

Anfänglich ist es empfehlenswert noch "Notification on success" und "Notification on Failure" einzuschalten. Ersteres kann man ausmachen wenn man weiß, dass es soweit funktioniert. Über "Send Test-Request" kann man einmal einen Test schicken und erhält das Ergebnis entsprechend dargestellt. Es sollte sowas kommen wie
:<code>POST Success: test OK</code>. In Geofancy.app gibt es keine Rückmeldung über den Erfolg des Testrequests. In FHEM sollten sich durch den Testrequest jedoch die Readings sofort aktualisieren (Ggf. ist ein Reload der FHEMWEB-Seite nötig da zusätzliche Tabellenzeilen nicht via Longpoll ergänzt werden).

Funktioniert das soweit, kann man eine neue Lokation als sein Zuhause anlegen. Es empfiehlt sich einen ID-Namen zu setzen; dieser ist dann in FHEM als Name für die Lokation sichtbar. Für die eigene Wohnung empfiehlt sich hier "home" (da dies auch direkt vom RESIDENTS Modul so verwendet werden kann). Man kann auch Trigger für andere Standorte anlegen. FHEM weiß dann sogar, wenn ihr im Büro seid und könnte sich dabei auch unterschiedlich verhalten, als wenn ihr "auf Achse" seid. Bei letzterem ist der Status im GEOFANCY Modul "underway", was so viel heißt wie "unbekannter Aufenthaltsort".

Hinweis: Zumindest für Geofancy.app liefert ein Testrequest wohl zufällige Locations zurück. Die eigenen Location-IDs werden also nicht übergeben, selbst wenn man sich in einem Geofence befindet. Um zu testen muss man sich wohl oder übel selbst bewegen ;-).

=== GEOFANCY Modul individualisieren ===
Die im GEOFANCY Modul dargestellten Readings sind nun in etwa so, wenn ihr euch bewegt:

<pre>
Readings:
2014-01-18 14:37:42 lastDevice -
2014-01-18 14:37:42 lastDeviceUUID 51F23894-AAAA-BBBB-CCCC-0123456789AB
2014-01-18 14:37:42 state dev:51F23894-AAAA-BBBB-CCCC-0123456789AB trig:test id:home lat:48.9999 long:11.9999
</pre>

Wer genauer hinschaut sieht: Mein iPhone heißt wohl 51F23894-AAAA-BBBB-CCCC-0123456789AB.
Damit nun die Readings für mein iPhone richtig angelegt werden, muss ein Device Alias gesetzt werden. Sinnvoll erscheint mir der Vorname des Besitzers:
:<code>attr geofancy devAlias 51F23894-AAAA-BBBB-CCCC-0123456789AB:Julian</code>

Weitere Alias-Namen können mit Leerzeichen einfach angehängt werden.
Jetzt werden weitere Readings angelegt, sobald GEOFANCY entsprechende Daten vom Mobilgerät empfängt:

<pre>
Readings:
2014-01-18 14:37:42 Julian arrived home
2014-01-18 14:37:42 currLocLat_Julian 48.9999
2014-01-18 14:37:42 currLocLong_Julian 11.9999
2014-01-18 14:37:42 currLocTime_Julian 2014-01-18 14:37:42
2014-01-18 14:37:42 currLoc_Julian home
2014-01-17 19:18:23 lastArr Julian home
2014-01-17 18:41:46 lastDep Julian Office
2014-01-18 14:37:42 lastDevice Julian
2014-01-18 14:37:42 lastDeviceUUID 51F23894-AAAA-BBBB-CCCC-0123456789AB
2014-01-17 18:41:46 lastLocArr_Julian 2014-01-17 08:58:37
2014-01-17 18:41:46 lastLocDep_Julian 2014-01-17 18:41:46
2014-01-17 18:41:46 lastLocLat_Julian 48.1111
2014-01-17 18:41:46 lastLocLong_Julian 11.1111
2014-01-17 18:41:46 lastLoc_Julian Office
2014-01-18 14:37:42 state dev:Julian trig:test id:home lat:48.9999 long:11.9999
</pre>

Möchte man nun etwas bestimmtes tun, wenn man nach Hause kommt oder das Heim verlässt, kann man am Besten ein entsprechendes Notify auf das Reading currLoc_Name setzen. Ich aktualisiere lediglich zwei Dummies, durch die dann alle weiteren Notifies ausgelöst werden:

<pre>
define n_Julian.Presence notify geofancy:currLoc_Julian:.home set Julian.homestatus:FILTER=STATE!=home home
attr n_Julian.Presence room Residents
define n_Julian.absence notify geofancy:currLoc_Julian:.underway {\
if (Value("Julian.homestatus") ne "gone") {\
fhem("set Julian.homestatus:FILTER=STATE!=absent absent");;\
}\
}
define n_Julian.whereabout notify geofancy:currLoc_Julian:.* set Julian.whereabout:FILTER=STATE!=$EVTPART1 $EVTPART1
</pre>

Wer es noch einfacher möchte (bzw. auch noch mehr Features) schaut sich einmal die neue Modulfamilie aus RESIDENTS[http://fhem.de/commandref_DE.html#RESIDENTS], ROOMMATE[http://fhem.de/commandref_DE.html#ROOMMATE] und GUEST[http://fhem.de/commandref_DE.html#GUEST] an. Diese sind direkt auf GEOFANCY abgestimmt. Dabei kann das devAlias Attribut entfallen und man hinterlegt die UUID stattdessen direkt im ROOMMATE oder GUEST Device (Attribut r*_geofenceUUIDs). Das erspart es für jeden Bewohner und jedes Device zig unterschiedliche Devices der Typen Notify, DOIF oder Watchdog anlegen und pflegen zu müssen.

Wer mehr Kontrolle möchte kann natürlich bei notify, DOIF und Co. bleiben: <code>define n_rr_Julian.location notify geofancy:currLoc_Julian:.* set rr_Julian:FILTER=location!=$EVTPART1 location $EVTPART1</code>. Wobei "Julian" dabei als devAlias in GEOFANCY eingtragen wurde, rr_Julian der Name des ROOMMATE aus RESIDENTS ist. Außerdem wurden die Location-IDs in der Geofency.app bzw. Geofancy.app so gewählt, dass diese direkt einem ROOMMATE-Status entsprechen (also z.B. home, wayhome...).

== Beispiele für die Nutzung der Anwesenheitserkennung ==
Hier sollen Beispiele für den Nutzen von Anwesenheitserkennung aufgezeigt werden.

=== Abschalten aller Verbraucher (Licht, Musikanlage) beim Verlassen der Wohnung ===
Typisches Szenario: Man geht ausser Haus, aber hat vergessen im Bad das Licht aus zu machen. Allerdings geht man heutzutage fast garnicht mehr ohne Handy aus dem Haus.

Nun soll FHEM in der gesamten Wohnung das Licht, sowie sonstige Verbraucher ausschalten, wenn ich länger als 15 Minuten ausser Haus bin. Dazu benötigt man zuerst eine structure, die alle Verbraucher und sonstigen Devices, die das betrifft, zusammenfasst.

<pre>
define Gesamte_Wohnung structure Gesamtes_Licht Licht_Wohnzimmer Licht_Kueche LED_Kueche Licht_Bad Licht_Schlafzimmer AV_Receiver TV_Steckdose
attr Gesamte_Wohnung room Wohnung
</pre>

Nun kann man mittels eines watchdogs eine Überwachung für sein Handy anlegen:

<pre>
# Überwachen der gesamten Wohnung mittels collectord sowie presenced in jedem Raum
define Handy PRESENCE lan-bluetooth XX:XX:XX:XX:XX:XX 127.0.0.1:5222
attr Handy event-on-change-reading state # Ein Event soll nur bei der Änderung des Anwesenheitsstatus (Reading: status) erfolgen. Wichtig für den watchdog!!!

# Nach 15 Minuten Abwesenheit (Handy im Status "absent") soll die gesamte Wohnung ausgeschaltet werden.
define watchdog_Anwesenheit watchdog Handy:absent 00:15 Handy:present set Gesamte_Wohnung off ; trigger watchdog_Anwesenheit .
attr watchdog_Anwesenheit regexp1WontReactivate 1
</pre>

== Anwesenheitserkennung Bluetooth PebbleBee mit PRESENCE Modul ==
Im Forum gibt es einen {{Link2Forum|Topic=28753|LinkText=langen Beitrag}} über die Einrichtung eines BT-Tag an einem RaspberryPI mit FHEM. Dabei werden Skripte wie blescan.pl und lepresenced genannt.
Da mittlerweile viele neue Informationen zusammen gekommen sind wurde der Wiki Eintrag erstellt.

Im Folgenden wird die Konfiguration für '''LE Deviced (z.B. Gtags,Pebbles etc.)''' und '''NICHT LE Device (z.B. IPhone)''' beschreiben.

'''Wo finde ich denn lepresenced?'''

lepresenced kann über Github heruntergeladen werden (Link weiter unten)

'''Was ist der Vorteil gegenüber blescan.pl?'''

{{Randnotiz|RNText=Beide hier beschriebenen Wege (presenced/lepresenced) können parallel auf dem selben BT-Dongle laufen, da sich die Ports unterscheiden!}}
blescan.pl hat u. a. das Problem, dass dank der wundervollen Bluetooth-Implementierung unter Linux ab und zu der Scan fehlschlägt und das Interface resettet werden muss. Das tut blescan.pl auch mit aller Gewalt. Dazu kommt, dass bei längeren Scanzeiten und vielen Tags sich die Prozesse anstauen, weil immer nur auf einen Tag "gewartet" wird. Außerdem wurden mit der Einführung von lepresenced sämtliche Supportverträge gekündigt lepresenced läuft dauerhaft und merkt sich bei allen sendenden Tags den Zeitstempel des letzten Empfangs.

=== Getestete Hardware/Software===
* '''Raspbian System''' - wheezy, Jessie
* '''BT-Dongle''' - CSL NET BT USB2.0 Stick, Bluetooth V4.0, Nano '''Achtung''': Es muss ein BT V4.0 oder höher verwendet werden. Nur dieser unterstützt ''LowEnergy''
* '''BT-TAG''' - Gtag von Gigaset, TrackR, UDOO Neo, PebbleBee, iTag von Unitec, X4-LIFE Multifunkti BL-Anhänger, iTag Wireless Anti, Trackr bravo

=== BT Dongel am PI installieren ===

Um den BT Dongle ''(hier: CSL NET BT USB2.0)'' am PI verwenden zu können, müssen die notwendigen Pakete über die Paketverwaltung von debain nachinstalliert werden.
Wer bereits ein BT-Dongle installiert hat, kann diesen Schritt überspringen.
<pre>
apt-get install bluetooth
</pre>
Nach erfolgreicher Installation der Pakete sollte der RaspberryPI neu gestartet werden.
<pre>
sudo reboot
</pre>

Nach dem erfolgten Reboot bitte das Log des Raspberry auf folgende Einträge prüfen:
<pre>
Feb 12 19:52:55 fhem kernel: [ 4.773600] Bluetooth: Core ver 2.20
Feb 12 19:52:55 fhem kernel: [ 4.773748] NET: Registered protocol family 31
Feb 12 19:52:55 fhem kernel: [ 4.773765] Bluetooth: HCI device and connection manager initialized
Feb 12 19:52:55 fhem kernel: [ 4.773797] Bluetooth: HCI socket layer initialized
Feb 12 19:52:55 fhem kernel: [ 4.773821] Bluetooth: L2CAP socket layer initialized
Feb 12 19:52:55 fhem kernel: [ 4.773890] Bluetooth: SCO socket layer initialized
Feb 12 19:52:55 fhem kernel: [ 4.797531] usbcore: registered new interface driver btusb
</pre>
Sobald der BT-Dongle erkannt wurde ''leuchtet'' (wenn vorhanden) auch die ''blaue/gelbe'' LED am Dongle auf.

=== BT-Tags aktivieren ===
Jetzt kann der BT-Tag aktiviert werden. Bei einigen Tags muss dafür die '''Batteriesicherung''' gezogen werden.

Einen Tag wird mit folgendem Befehl auf der Konsole gesucht:
<source lang="bash">
sudo hcitool lescan

Ausgabe z.B.:
LE Scan ...
7C:2F:80:A1:XA:XD (unknown)
7C:2F:80:A1:XA:XD Gigaset G-tag
7C:2F:80:A1:X4:X1 (unknown)</source>
Eine Übersicht über die möglichen Befehle von hcitool gibt es mit der Eingabe von:
<pre>
sudo hcitool

Ausgabe z.B.:
hcitool - HCI Tool ver 5.23
Usage:
hcitool [options] <command> [command parameters]
Options:
--help Display help
-i dev HCI device
Commands:
dev Display local devices
inq Inquire remote devices
scan Scan for remote devices
name Get name from remote device
info Get information from remote device
spinq Start periodic inquiry
epinq Exit periodic inquiry
cmd Submit arbitrary HCI commands
con Display active connections
cc Create connection to remote device
dc Disconnect from remote device
sr Switch master/slave role
cpt Change connection packet type
rssi Display connection RSSI
lq Display link quality
tpl Display transmit power level
afh Display AFH channel map
lp Set/display link policy settings
lst Set/display link supervision timeout
auth Request authentication
enc Set connection encryption
key Change connection link key
clkoff Read clock offset
clock Read local or remote clock
lescan Start LE scan
lewladd Add device to LE White List
lewlrm Remove device from LE White List
lewlsz Read size of LE White List
lewlclr Clear LE White list
lecc Create a LE Connection
ledc Disconnect a LE Connection
lecup LE Connection Update
</pre>

Falls beim SCAN kein Tag gefunden wird, sollte das BT Interface neu gestartet werden. Dazu ist kein Reboot des PI notwendig.
<source lang="bash">
sudo hciconfig hci0 down
sudo hciconfig hci0 up
sudo hcitool dev
</source>

=== Anleitung für ein LE Device (z.B. Gtags,Pebbles etc.) ===

Herunterladen des Skripts lepresenced.
<pre>
https://github.com/mhop/fhem-mirror/blob/master/fhem/contrib/PRESENCE/lepresenced
</pre>

Zur "Installation" des Skripts folgendermaßen vorgehen:
Unter /fhem manuell den Ordner „script“ anlegen:
<pre>
mkdir script
</pre>
Datei lepresenced reinkopieren und ausführbar machen:
<pre>
sudo chmod +x /opt/fhem/script/lepresenced
sudo chgrp -cR dialout lepresenced
</pre>
Skript erstmalig starten:
<pre>
sudo ./lepresenced --loglevel LOG_EMERG -d
</pre>
Kommt beim Starten des Skript eine Fehlermeldung, müssen die Abhängigkeiten aufgelöst werden.
<pre>
Can't locate Net/Server/Daemonize.pm in @INC (@INC contains: /etc/perl /usr/local/lib/perl/5.14.2 /usr/local/share/perl/5.14.2 /usr/lib/perl5 /usr/share/perl5 / usr/lib/perl/5.14 /usr/share/perl/5.14 /usr/local/lib/site_perl .) at /opt/fhem/lepresenced line 17.
BEGIN failed--compilation aborted at /opt/fhem/lepresenced line 17.
</pre>
Um die Abhängigkeiten aufzulösen muss folgendes nachinstalliert werden und anschließend ein Reboot durchgeführt werden.
<pre>
sudo apt-get install libnet-server-*
</pre>

Nach dem letzten Schritt sind alle Bedingungen für eine abschließende Konfiguration der BT-Tags in FHEM abgeschlossen worden.
Jetzt kann der Tag dem FHEM-Server bekannt gemacht werden.
<pre>
-- Name Modul Modus MAC vom Gtag IP vom PI Port Abfragezeit in Sekunden
define MeinGtAG PRESENCE lan-bluetooth xx:xx:xx:xx:xx:xx 127.0.0.1:5333 120
</pre>

Den absent und present Mode kann man einfach testen, in dem man den Gtag mit Alufolie einwickelt.

=== Anleitung für ein NICHT LE Device (z.B. IPhone) ===
Die Installation kann (wie in der commanref beschrieben) über Debian Pakete erfolgen.
<pre>
.deb package for Debian (noarch): presenced-1.3.deb http://svn.code.sf.net/p/fhem/code/trunk/fhem/contrib/PRESENCE/deb/presenced-1.3.deb

.deb package for Raspberry Pi (raspbian): presenced-rpi-1.3.deb http://svn.code.sf.net/p/fhem/code/trunk/fhem/contrib/PRESENCE/deb/presenced-rpi-1.3.deb
</pre>

<pre>
sudo dpkg -i presenced-rpi-1.3.de
</pre>

Installation perl script file (Auszug commanref)
<pre>
direct perl script file: presenced http://svn.code.sf.net/p/fhem/code/trunk/fhem/contrib/PRESENCE/presenced
</pre>

Nach dem letzten Schritt sind alle Bedingungen für eine abschließende Konfiguration der BT-Tags in FHEM abgeschlossen worden.
Jetzt kann der Tag dem FHEM-Server bekannt gemacht werden.
{{Randnotiz|RNText=Wenn man mit collectord arbeitet muß man die Erkennung bei allen Devices auf port 5222 setzen.
lan-bluetooth xx:xx:80:xx:xx:AC 127.0.0.1:5222 20 120}}
<pre>
-- Name Modul Modus MAC vom Gtag IP vom PI Port Abfragezeit in Sekunden
define MeinGtAG PRESENCE lan-bluetooth xx:xx:xx:xx:xx:xx 127.0.0.1:5333 120
</pre>

=== Automatischer Start ===

Damit das leprecend Skript beim Systemstart mitgestartet wird, sollte eine Crontab Eintrag gesetzt werden. Alternativ die rc.local anpassen.
Ersteres würde so aussehen:

Ein sh-Skript mit dem Inhalt:
<pre>
sudo start-stop-daemon -d /opt/fhem/script -S -x /opt/fhem/script/lepresenced
</pre>
unter dem Verzeichnis /home/pi ablegen, welches sich init_start.sh nennt.

Das Skript dann unter: sudo crontab -e einhängen mit folgender Folge:
<pre>
@reboot /home/pi/init_start.sh
</pre>

Zweiteres so:
<pre>
sudo nano /etc/rc.local
</pre>

Datei rc.local, freie Stelle suchen, vor "exit 0":

<pre>
# Start lepresenced
/opt/fhem/script/lepresenced --loglevel LOG_EMERG -d
exit 0
</pre>

=== Batterieüberwachung (aktuell nur G-Tags) ===

Leider überträgt der G-Tag nach der Einrichtung als Device in FHEM kein Reading mit seinem aktuellen Batteriestatus.
Dem wurde mit Hilfe des Forum Abhilfe geschaffen.
Im Folgenden wird erläutert wie die Batterieüberwachung eingerichtet werden kann.

'''Voraussetzung:'''

bc - Basiscalculator [https://packages.debian.org/de/sid/bc Bc-Paket]
<pre> sudo apt-get install bc </pre>

Anlegen eines Shellskript auf dem Raspberry System.
Die Parameter <<MAC-Adresse>> und <<TagName>> müssen durch die Werte des auszulesenden G-Tags ersetzt werden.
<pre>
#!/bin/bash
stringZ=$(sudo gatttool -b 5C:2B:80:C1:14:41 --char-read --handle=0x001b)
stringZ=${stringZ:33:2}
stringZ=$(echo "$stringZ" | tr a-f A-F)
decimal=$(echo "ibase=16; $stringZ" | bc)
perl /opt/fhem/fhem.pl 7072 "setreading MeinGtag Batterie $decimal"
</pre>

Dem Device in FHEM (hier MeinGtag) ein userReading mit dem Namen '''Batterie''' hinzufügen.
Das Shellskript mit folgendem Befehl starten:
<pre>
./GtagBatterie.sh
</pre>
'''Wichtig ist hierbei,''' dass Skript mit "./" und nicht mit "sh" aufzurufen. Beim Aufruf mit "sh GtagBatterie.sh" produziert es einen Fehler
<pre>GtagBatterie.sh: 3: GtagBatterie.sh: Bad substitution </pre>

Das Reading wird auf den ausgelesenen Wert der Batterie gesetzt.

Hinweis: Es sollte für jeden G-Tag ein eigenes Skript abgelegt werden. Das Skript kann per crontab oder fhem Kommando (system) regelmäßig aufgerufen werden.

=== Batterieüberwachung (alle Devices vom Typ "MODE=lan-bluetooth") ===

Es gibt eine weitere Möglichkeit um den Batteriestatus von LE Devices abzurufen und in FHEM als Reading darzustellen.
Dabei wird der Batteriezustand für alle LE Devices, die bereits in FHEM konfiguriert sind und per lepresenced überwacht werden, automatisch in einem shell-Script ermittelt.
Näheres dazu im Forumartikel [https://forum.fhem.de/index.php/topic,56960.0.html [Erweiterung]: Anwesenheitserkennung/Batterieüberwachung].

Vorteile:
* Automatische Ermittlung aller in FHEM konfigurierten LE Devices
* Möglichkeit, diese Devices alternativ manuell im Script einzutragen
* Es werden nur Devices abgefragt, die im Status "present" sind, also mit ziemlicher Sicherheit auch verfügbar sind
* Ein eventuell auf dem FHEM telnet-Port gesetztes Passwort kann im Script hinterlegt werden

'''Voraussetzung:'''

'''Funktionierendes lepresenced''' - siehe [[Anwesenheitserkennung#Anleitung_f.C3.BCr_ein_LE_Device_.28z.B._Gtags.2CPebbles_etc..29|Anleitung für ein LE Device (z.B. Gtags,Pebbles etc.)]]

'''socat''' - TCP port forwarder
<pre>
sudo apt-get update && sudo apt-get install socat
</pre>

'''gatttool''' - Bestandteil von bluez

gatttool ist auf den meisten Distributionen im bluez-Paket, allerdings nicht bei Opensuse. Dort muss man das Sourcepaket von bluez installieren und selbst kompilieren.
gatttool sollte dann nach /usr/bin oder /usr/local/bin kopiert werden,

Zusätzlich zu den notwendigen Erweiterungen werden für die Ausführung von gatttool '''Root-Rechte benötigt'''!

Das Script selbst gibt es hier: [https://raw.githubusercontent.com/micky0867/lebattery/master/lebattery lebattery]

Am Besten unter /opt/fhem/script/lebattery speichern und ausführbar machen:
<source lang="bash">
sudo su -
mkdir /opt/fhem/script
cd /opt/fhem/script
wget https://raw.githubusercontent.com/micky0867/lebattery/master/lebattery
chmod 755 lebattery
</source>

Je nach Bedarf können im Script noch die folgenden 3 Parameter angepasst werden:
<source lang="bash">
# If allowed_telnetPort is protected by a password, add the password here
TELNETPASSWORD=""
# Attribute for batterylevel in FHEM
ATTRIBUT="batterylevel"
# Use this, if you dont want the script to determine the tags on its own
LETAGS=""
</source>

Das Skript wird dann unter root folgendermaßen gestartet:
<pre>
/opt/fhem/script/lebattery -v
</pre>

Ausgabe des Skripts, wenn es mit dem Verbose Parameter -v gestartet wird.

Beide Devices sind vom Typ NUT mini, das Device mit dem FHEM-Namen '''nut_Micky''' ist im Status '''absent'''. Das zweite Device ist im Status '''present'''.
<pre>
Determining address for nut_Micky ...
nut_Micky is in state absent, no further action required

Determining address for nut_Test ...
Fetching batterylevel for nut_Test (F3:44:04:81:54:89) ...
Setting batterylevel for nut_Test to 100%
</pre>

Mein crontab-Eintrag (User root) sieht so aus:
<pre>
3 3 * * * /opt/fhem/script/lebattery -v >/opt/fhem/script/lebattery.log 2>&1
</pre>
Damit wird jeden Morgen um 3 Minuten nach 3 Uhr der Zustand der Batterien aller Devices ermittelt und in FHEM abgespeichert. 
Bevor man das mit crontab macht, sollte man allerdings zunächst sicher stellen, dass es auch ohne crontab funktioniert....

Bei Problemen kann man auch erstmal schauen, ob das mit dem gattool überhaupt funktioniert:
<pre>
gatttool -t random -b <MAC-Adresse> --char-read --uuid 0x2a19

handle: 0x0017 value: 64
</pre>
In diesem Fall hat die Batterie noch 100% (hex 64).

=== Problemlösungen ===
Falls es Probleme beim Starten des Skripts gibt bzw. man das Skript ohne Reboot des Systems neustarten möchte, kann man dies per kill Befehl erledigen.
<source lang="bash">
ps -ef | grep lepresenced
sudo kill <pid>
</source>

Debuglevel lepresenced setzen:
{{Randnotiz|RNText=Um Debug-Meldungen zu bekommen (Vorsicht bei SD-Karten-Systemen wie dem RPi) - Hierbei werden die Schreibzyklen auf die SD-Karte erhöht.}}
<pre>
lepresenced --loglevel LOG_DEBUG
</pre>
Nur das wichtigste Loggen:
<pre>
lepresenced --loglevel LOG_WARNING
</pre>
Keinerlei LOG-Einträge
<pre>
lepresenced --loglevel LOG_EMERG
</pre>

==== Ansprechpartner ====
# {{Link2FU|5068|PatrikR}} (Patrick) für lepresenced
# [[Benutzer Diskussion:Devender|Devender]] ({{Link2FU|20043|Dirk}}) für Wiki und Doku

[[Kategorie:Code Snippets]]
[[Kategorie:Glossary]]

Diskussion:MAX

2016-12-07T18:54:55Z

Krokofant: /* MAX! Komponenten */

Hallo zusammen,

so wie es aussieht, funktioniert die gplot Datei nicht mehr (warum auch immer). Ich versuche mal, eine neue zu bauen und werde Sie hier einstellen.

Gruß PeMue

== MAX! Komponenten ==
Sollte dies nicht eigentlich der Grundlagenartikel sein und die einzelnen Hardwarekomponenten eigene Artikel haben ähnlich wie die Struktur im Homematik-Bereich des Wikis angelegt ist?

Ich besitze keine MAX!-Komponenten würde aber die Artikel anlegen und hier herausnehmen, wenn niemand dagegen spricht. Kommt erstmal auf meine ToDo-Liste, und ich frage vorher im Forum und/oder bei den Autoren nach... --[[Benutzer:Krokofant|Krokofant]] ([[Benutzer Diskussion:Krokofant|Diskussion]]) 13:11, 5. Dez. 2016 (CET)
<hr />
:Ich würde jetzt hier nicht unbedingt eine Aufteilung in Einzelartikel erzwingen. Wenn jemand ein einzelnes Gerät genauer beschreiben will (z.B. weil er es besitzt), kann das gern ein eigener Artikel werden. Derzeit sehe ich den Bedarf nicht - und MAX! ist auch bei weitem nicht so komplex wie HomeMatic. --[[Benutzer:Ph1959de|Peter]] ([[Benutzer Diskussion:Ph1959de|Diskussion]]) 16:36, 5. Dez. 2016 (CET)
:: Stimmt schon. Ich versuche immer in Wikis eine einheitliche Struktur zu finden und diese dann fortzuschreiben. Und beim Komponentenkauf hätte ich jetzt fast übersehen, dass es den MAX!-Eco-Taster (in fhem) überhaupt gibt, weil er hier nur im Sammelartikel vorkommt. Wie wäre es denn mit <nowiki>#REDIRECT</nowiki>-Artikeln zum entsprechenden Abschnitt im Sammelartikel? --[[Benutzer:Krokofant|Krokofant]] ([[Benutzer Diskussion:Krokofant|Diskussion]]) 19:53, 7. Dez. 2016 (CET)

Diskussion:MAX

2016-12-07T18:53:53Z

Krokofant: /* MAX! Komponenten */

Hallo zusammen,

so wie es aussieht, funktioniert die gplot Datei nicht mehr (warum auch immer). Ich versuche mal, eine neue zu bauen und werde Sie hier einstellen.

Gruß PeMue

== MAX! Komponenten ==
Sollte dies nicht eigentlich der Grundlagenartikel sein und die einzelnen Hardwarekomponenten eigene Artikel haben ähnlich wie die Struktur im Homematik-Bereich des Wikis angelegt ist?

Ich besitze keine MAX!-Komponenten würde aber die Artikel anlegen und hier herausnehmen, wenn niemand dagegen spricht. Kommt erstmal auf meine ToDo-Liste, und ich frage vorher im Forum und/oder bei den Autoren nach... --[[Benutzer:Krokofant|Krokofant]] ([[Benutzer Diskussion:Krokofant|Diskussion]]) 13:11, 5. Dez. 2016 (CET)
<hr />
:Ich würde jetzt hier nicht unbedingt eine Aufteilung in Einzelartikel erzwingen. Wenn jemand ein einzelnes Gerät genauer beschreiben will (z.B. weil er es besitzt), kann das gern ein eigener Artikel werden. Derzeit sehe ich den Bedarf nicht - und MAX! ist auch bei weitem nicht so komplex wie HomeMatic. --[[Benutzer:Ph1959de|Peter]] ([[Benutzer Diskussion:Ph1959de|Diskussion]]) 16:36, 5. Dez. 2016 (CET)
:: Stimmt schon. Ich versuche immer in Wikis eine einheitliche Struktur zu finden und diese dann fortzuschreiben. Und beim Komponentenkauf hätte ich jetzt fast übersehen, dass es den MAX!-Eco-Taster überhaupt gibt, weil er hier nur im Sammelartikel vorkommt. Wie wäre es denn mit <nowiki>#REDIRECT</nowiki>-Artikeln zum entsprechenden Abschnitt im Sammelartikel? --[[Benutzer:Krokofant|Krokofant]] ([[Benutzer Diskussion:Krokofant|Diskussion]]) 19:53, 7. Dez. 2016 (CET)

Diskussion:MAX

2016-12-05T12:11:44Z

Krokofant: Artikelstruktur

Diskussion:HM-LC-Sw1PBU-FM Alternative Firmware

2016-12-05T06:09:50Z

Krokofant: Frage

Mir fehlen da ja 3-4 Einleitungssätze. Was ist der HM-LC-Sw1PBU-FM noch mal für ein Gerät? Warum will man da alternative FW drauf [[Benutzer:Soulman|Soulman]] ([[Benutzer Diskussion:Soulman|Diskussion]]) 01:32, 21. Mai 2014 (UTC)
:Ich habe die Basisüberarbeitung gerade mal gemacht und den Artikel verlinkt und kategorisiert. Technisch/inhaltlich müssen ggf. die derzeit aktiven Entwickler/Anwender noch mal ran. Das "Warum" der alternativen Firmware ist meiner Meinung nach im Abschnitt "Neue Funktionen" aber schon ganz gut erklärt. --[[Benutzer:Ph1959de|Peter]] ([[Benutzer Diskussion:Ph1959de|Diskussion]]) 07:39, 21. Mai 2014 (UTC)
:: Mir fehlen da 3-4 Einleitungssätze. Was ist der HM-LC-Sw1PBU-FM noch mal für ein Gerät? Warum will man da alternative FW drauf? Nur wegen Kreuzschaltung? Sicher, wenn ich mich jetzt 10 Minuten mit dem Thema befasse (z.b. den original Artikel zu dem Geräte durchlese), dann werde ich das verstehen. Wikiartikel sollten einem diese 10 Minuten ersparen finde ich, bzw dafür sorgen, dass sie nur EINMAL erbracht werden müssen, nämlich von Autor und nicht 1900 mal, nämlich von allen Lesern jeweils neu.[[Benutzer:Soulman|Soulman]] ([[Benutzer Diskussion:Soulman|Diskussion]]) 18:37, 28. Feb. 2015 (CET)

== Falscher Befehl? ==

In 3.4 "Advanced Settings" sollte es anstatt

set <HM-LC-SW1PBU-FM_Sw_01> intKeyVisib visib

sollte es

set <HM-LC-SW1PBU-FM_Sw_01> '''regSet''' intKeyVisib visib

heissen - oder?
--[[Benutzer:Farion|Farion]] ([[Benutzer Diskussion:Farion|Diskussion]]) 13:07, 10. Jan. 2016 (CET)

== Hinweis zum Einbau? ==
Ich lese gerade nur quer und werde deshalb mangels sicherem Durchblick an dieser Stelle keine Änderung machen, aber gilt der Abschnitt nicht für jeden Aktor, egal mit welcher Firmware?

Wenn ja, sollte der Abschnitt meiner Meinung nach in den Hauptartikel _verschoben_ werden. --[[Benutzer:Krokofant|Krokofant]] ([[Benutzer Diskussion:Krokofant|Diskussion]]) 07:09, 5. Dez. 2016 (CET)

HomeMatic

2016-11-29T12:56:34Z

Krokofant: /* Pairen */

'''Achtung, diese Seite wird derzeit im Sinne einer klareren Beschreibung überarbeitet'''

'''HomeMatic''' (HM) ist ein System des Herstellers eQ-3 zur Steuerung und Überwachung von zahlreichen Aufgaben und Situationen im Haus. Erhältlich sind sowohl Geräte mit Funkschnittstelle 868.3 MHz, als auch (seit 2008) drahtgebundene Geräte mit RS485-Schnittstelle. Im Programm sind Geräte zur Heizungs- und Lichtsteuerung, Temperatur-, Luftfeuchte- und Feuchtemessung, Zutrittskontrolle, als Wasser-, Brand- und Bewegungsmelder sowie als Wetterstation, ferner gibt es noch Fernbedienungen und Statusdisplays.

=Grundlagen=
HomeMatic-Geräte können untereinander ''gepeert'' werden (engl. ''peers'' = "Gleiche"), im einfachsten Fall kann deshalb bereits ein Sensor (z.B. ein Temperatursensor) mit einem Aktor (z.B. einem Heizkörperregler) verbunden werden und diesen steuern. Hierbei können mehrere Sensoren und Aktoren untereinander verbunden werden, die Vorstellung der "Gleichen" ist also zutreffend.

HomeMatic-Geräte können auch mit einer Zentrale verbunden (''gepairt'') werden, die dann einen Teil der Steuerungslogik übernehmen kann. Bei dieser Verbindung spricht man vom ''Pairing'', weil jedes HomeMatic-Gerät nur mit einer Zentrale verbunden werden kann. Gepairte Geräte können auch nicht mehr direkt gepeert werden - dies geht dann nur noch unter Beteiligung der Zentrale.

==Voraussetzungen==
Für den Betrieb ohne Zentrale sind keine weiteren Voraussetzungen zu erfüllen.
===Zentrale von eQ-3===
Vom Hersteller eQ-3 selbst wird eine Zentrale (derzeit aktuell CCU-2) und Windows-Software zur Steuerung und Auswertung der HM-Komponenten angeboten.

===Fhem als Zentrale===
Zur Kommunikation mit HomeMatic benötigt Fhem eine Schnittstelle, die im 868,3-MHz-Band funken kann. Infrage kommen:
* [[CUL]] (USB)
* [[HM-CFG-USB USB Konfigurations-Adapter|HM-CFG-USB]] (USB)
* [[CUNO]] (LAN)
* [[HM-CFG-LAN]] (oft auch "HMLAN" genannt; LAN)
* [[HM-MOD-RPI-PCB HomeMatic Funkmodul f%C3%BCr Raspberry_Pi]]
* [[HM-LGW-O-TW-W-EU Funk-LAN Gateway]] (LAN)

Für ''HomeMatic Wired'' benötigt man eine RS485-Schnittstelle. Verfügbar sind:
* [[HomeMatic Wired RS485 LAN Gateway|HMW-LGW-O-DR-GS-EU]] (LAN)

===Migration von CCU-2 zu Fhem===
Der Umzug einer bestehenden HomeMatic Installation von einer HomeMatic CCU-2 auf Fhem ist möglich. Um die an die Zentrale angebundenen Devices in Fhem ohne größere Umkonfiguration weiter verwenden zu können, muß die HM-Id und, falls verwendet, die AES-Schlüssel der CCU-2 in Fhem übernommen werden. Um diese Daten aus der CCU-2 auszulesen, wird eine SSH-Verbindung (zum Beispiel mit PuTTY unter Windows) aufgebaut. Die HM-Id befindet sich in der Datei <code>/usr/local/etc/config/rfd/BidCoS-RF.dev</code> in einer Zeile wie dieser:

<device serial="BidCoS-RF" type="HM-RCV-50" address="0xABCDEF" aes_key_index="0" firmware_version="2.11.9" bidcos_interface="KEQ1234567" roaming="true">

Die HM-Id ist der Wert des <code>address</code>-Attributs. Die dort angegebene hexadezimale Zahl (hier <code>0xABCDEF</code>) ist die HM-Id und wird in Fhem ohne das "0x"-Präfix verwendet.

Falls AES-Schlüssel eingerichtet sind, sind diese in der Datei <code>/etc/config_templates/crypttool.cfg</code> zu finden und können 1:1 als Schlüssel im [[HM-CFG-LAN]] in der gleichen Reihenfolge hinterlegt werden.
{{Todo|Wie werden AES-Schlüssel in HM-CFG-LAN "hinterlegt"?}}

==Prototokoll==
HM-Geräte kommunizieren untereinander mit dem Protokoll ''Bidirectional Communication Standard'', abgekürzt ''BidCoS''. Jedes HM-Gerät enthält also Sender und Empfänger, das ist einer der wesentlichen Unterschiede z.B. zum FS20-System.
*Jedes HM-Gerät meldet beim Empfang eines Steuerbefehls durch einen Peer an diesen eine Bestätigung „ACK“ zurück. Erkennt das HM-Gerät den Befehl nicht, sendet es ein ''NACK''. Kommt vom HM-Gerät keine Rückmeldung innerhalb einer festgelegten Zeit, meldet der steuernde Peer ein ''MISSING ACK''.
*Jedes HM-Gerät meldet ferner seinen Status nach dem Erhalt eines Steuerbefehls zurück - so kann auch ein lokal am Gerät erfolgender Tastendruck in beim steuernden Peer oder in der Zentrale registriert werden.

Das Protokoll ''BidCoS'' wurde zum großen Teil entschlüsselt, seine offen verfügbare Variante heißt ''AskSin''. Unter Verwendung der AskSin-Library entstehen derzeit erste Geräte, die in das HomeMatic-System eingebunden werden können. Zur Unterscheidung zwischen HM und den neuen Geräten werden diese als [[HomeBrew]] (HB) bezeichnet.

=Betrieb mit Fhem=
Die Kenntnis des Dokumentes [http://fhem.de/Heimautomatisierung-mit-fhem.pdf Einsteigerdokuments "Heimautomatisierung mit Fhem"] wird vorausgesetzt. Im Anhang dieses Dokuments findet sich ein Teil über den Aufbau und die Funktion von HM-Geräten.

=== Einrichten des IO-Devices (Funkschnittstelle)===
Zuerst muss ein IO-Device eingerichtet werden, um mit HM Geräten kommunizieren zu können. Siehe hierzu [[HMLAN Konfigurator]].

=== Struktur von HM Geräten===
HM Geräte sind logisch in ein '''Device (Gerät)''' und ein oder mehrere '''Channels (Kanäle)''' gegliedert. Jedes Device und jeder Channel wird in einer Entity in FHEM repräsentiert. 
Ausnahme: Sollte ein Gerät nur einen Kanal haben werden diese zusammen in einer Entity angelegt.
====Device====
Das Device ist für die Kommunikation verantwortlich. Es sortiert und ordnet die zu sendenden und empfangenden Nachrichten.
Man kann prüfen, ob alle Nachrichten übertragen sind, oder ob es Probleme gegeben hat. Die Variablen "prot..." geben Auskunft darüber. Siehe auch [[Homematic_HMInfo#protoEvents]].
Zu beachten sind zudem die Übertragungsmodi. Nicht alle Devices sind ständig auf Empfang - FHEM muss berücksichtigen, wann gesendet werden kann. In '''protState''' kann man sehen, ob Kommandos auf Verarbeitung warten, also pending sind. Einige Devices unterstützen mehrere Modi parallel.

===== Config=====
Wird von allen Devices unterstützt, auch wenn es bei Always kaum genutzt werden kann.
Man setzt die Kommandos in FHEM ab und diese warten in der Kommando-queue.
Wenn die config-funktion am Device ausgelöst wird (Anlerntaste drücken) sendet FHEM die wartenden Nachrichten der Reihe nach. Config wird bei allen Devices zum pairen genutzt.

===== Always=====
Trifft man meist bei netzbetriebenen Geräten an, da diese kein Problem mit dem Energieverbrauch haben. Man kann immer mit dem Device kommunizieren.

===== Burst=====
Nur der Empfänger des Device ist aktiv. Über eine Aufweck-sequenz kann das Device geweckt werden. Man kann quasi immer mit dem Device kommunizieren. Nachteil des Aufwecken ist zum Einen, dass immer ALLE Devices im Funknetz geweckt werden, was deren Batterie belastet. Zum Andere ist die Aufweck-sequenz funktechnisch aufwändig und belastet die maximal erlaubte Sendekapazität des IO device je Stunde.

===== ConditionalBurst=====
Bei einigen Devices kann man den Burst mode zuschalten. Dies sind Devices, die zusätzlich über andere modi verfügen, so z.B. wakeup. Schaltet man burst-empfang ein kann man immer und sofort mit dem Device reden, es kostet aber etwas mehr Batterie. Siehe hierzu Attribut '''burstAccess''', Kommando '''burstXmit''' und Register '''burstRx'''
===== LazyConfig=====
Kommandos in der Queue werden bearbeitet, wenn eine Aktion vom Device ausgeht. So zum Beispiel ein Tastendruck bei einer Fernbedienung.
Dieser mode wird von CUL/CUNO nicht unterstützt. FHEM ignoriert diese Option automatisch und wartet i.a. auf ein Config.
===== Wakeup=====
Die Devices wachen regelmäßig auf und senden Daten, z.B. Temperatursensoren. Zu diesem Zeitpunkt kann FHEM die Nachrichten übertragen. Die Aufwachperiode ist unterschiedlich von 3 min bis zu 24h.

====Channel====
Ein Kanal ist die Funktionseinheit des Geräts. Hier ist die Funktion des Sensors oder Aktors realisiert.

Nutzt ein Gerät nur einen Kanal, wird dieser in FHEM der Übersichtlichkeit halber nicht einzeln angelegt. Für die Kommandos und das Peering wird trotzdem die HM-ID des 1. Kanals verwendet.

Nutzt ein Gerät hingegen mehrere Kanäle, werden diese per [[autocreate]] zusätzlich zum Device angelegt. Es ist aber möglich, bei Geräten mit virtuellen Kanälen, diese zu löschen und fehlende Attribute manuell dem Device hinzu zu fügen. Danach kann es wie ein 1-Kanal-Gerät genutzt werden. Allerdings werden die Kanäle beim erneuten Pairing von [[autocreate]] neu angelegt.

=====virtuelle Kanäle=====
Einige Dimmer unterstützen virtuelle Kanäle. Eigentlich haben sie keinen Hauptkanal sondern nur 3 virtuelle Kanäle, die je nach Verknüpfungslogik, den endgültigen Zustand des Aktors bestimmen. Dieses Verhalten wird in jedem Kanal per Register '''logicCombination''' gesetzt. 
Folgende Logik wird dabei angewendet: <tt>phyLevel = (((0% o Ch1) o Ch2) o Ch3)</tt> [o = Logik-Platzhalter]

D.h. es wird immer der Kanal mit dem gesetzten Register mit dem vorherigen Teilergebnis kombiniert, angefangen mit Kanal1. 
Es gibt folgende Logik-Optionen: [einzelne Betrachtung von <tt>(Vorergebnis o Kanal)</tt>]
{|
!style="text-align:left;"|Wert!!style="text-align:left;"|Bedeutung!!style="text-align:left;"|Beispiel (alle Werte in %)
|-
|inactive||keine Verknüpfung|| 30 inactive 80 = 30
|-
|or||oder (höchster Wert zählt)|| 30 or 80 = 80
|-
|and||und (kleinster Wert zählt)|| 30 and 80 = 30
|-
|xor||entweder-oder (nur 1 Kanal darf über 0% sein)|| 30 xor 80 = 0 ''aber'' 30 xor 0 = 30
|-
|nor||oder negiert (höchster Wert subtrahiert von 100%)|| 30 nor 80 ''= !80'' = 20
|-
|nand||und negiert (niedrigster Wert subtrahiert von 100%)|| 30 nand 80 ''= !30'' = 70
|-
|orinv||oder mit invertiertem Kanal|| 30 orinv 80 ''= 30 or 20'' = 30
|-
|andinv||und mit invertiertem Kanal|| 30 andinv 80 ''= 30 and 20'' = 20
|-
|plus||Vorergebnis addiert mit Kanal|| 30 plus 80 = 100
|-
|minus||Vorergebnis subtrahiert mit Kanal|| 30 minus 80 = 0
|-
|mul||Vorergebnis multipliziert mit Kanal|| 30 mul 80 = 24
|-
|plusinv||Vorergebnis addiert mit invertiertem Kanal|| 30 plusinv 80 ''= 30 plus 20'' = 50
|-
|minusinv||Vorergebnis subtrahiert mit invertiertem Kanal|| 30 minusinv 80 ''= 30 minus 20'' = 10
|-
|mulinv||Vorergebnis multipliziert mit invertiertem Kanal|| 30 mulinv 80 ''= 30 mul 20'' = 6
|-
|invPlus||invertiertes Vorergebnis addiert mit Kanal|| 30 invPlus 80 ''= 70 plus 80'' = 100
|-
|invMinus||invertiertes Vorergebnis subtrahiert mit Kanal|| 30 invMinus 80 ''= 70 minus 80'' = 0
|-
|invMul||invertiertes Vorergebnis multipliziert mit Kanal|| 30 invMul 80 ''= 70 mul 80'' = 56
|}
: ''→ Siehe auch: [[HM-LC-Dim1PWM-CV Dimmaktor PWM DC-LED#Beispiele|Verknüpfungsbeispiel]]''

=== Variablen===
Wie alle FHEM Entities werden 4 Gruppen von Daten unterstützt:
* Internals: Im Web-Interface sichtbare Variablen, die allgemeine Informationen über den Zustand enthalten.
* Readings: Im Web-Interface sichtbare Variablen. Sie werden aus von Entites empfangenen Nachrichten generiert. Man kann mit notify Trigger auf die setzen. Readings werden im Statefile bei save und gewissen neustarts gesichert und beim Booten eingelesen. Readings haben einen Zeitstempel.
* Attribute: Im Web-Interface sichtbare Variablen. Über sie kann man die Eigenschaften der Entity in FHEM steuern.
* Helper: Im Web-Interface nicht sichtbare Variablen. Man kann sie mit dem Kommando 'list' sehen. Es sind hilfsvariablen, die für den User keine Bedeutung haben sollen.
==== Internals====
Viele Variablen sind nicht HM spezifisch - deren Bedeutung muss in allgemeinen Teil nachgelesen werden. Spezifische Variablen sind:
*Device
** channel_xx: Liste der Kanäle, die dem Device zugeordnet sind.
** prot... : Gruppe von Daten zum Zustand des [[HomeMatic#Protokol|Protokolls]], also der Kommunikation mit dem Device.
** rssi...: Gruppe von Daten die den [[HomeMatic#Rssi|Empfangspegel]] des Device bei IOs, Peers und Repeatern darstellt.

*Kanäle
** device: Das übergeordnete Device
** chanNo: Die Kanalnummer
** peerList: Ist die Entity mit einem anderen gepeert ist steht hier der Name der Peers. Siehe auch attribut peerIDs und Reading peerList. Diese Variable ist mit dem peer verlinkt, man kann darauf 'clicken'.

==== Readings====
Readings für HM Entites unterliegenden allgemeinen FHEM Regeln.
Generell gilt, dass ein Wert, der von FHEM gesetzt wurde mit dem prefix '''"set_"''' versehen wird. Wenn der Zustand bestätigt ist wird das set_ entfernt. Sollte man also ein Reading mit diesem prefix haben, das sich nicht selbst entfernt sollt man unbedingt den Zustand kontrollieren. 
So ist nach einem "set Licht on" der Zustand des Licht erst einemal "set_on". Mit der Antwort des Device wird es dann auf "on" gesetzt. 
Register machen eine Ausnahme:

=====Register=====
Register sind Konfigurationsparameter, die '''im Device flash''' gespeichert werden. Daten, die Registern zureordnet sind beginnen mit "R-". Sollte das Register einem peer zugeordnet sein kommt dieser danach. Der Namen ist also '''R-<peer>-<registerName>'''.

Der Zugriff ist indirekt, geht also nur über Methoden und Kommandos. Man kann die Konfiguration (Register und peers) mit '''getConfig''' aus dem Device lesen und in FHEM dargestellen. FHEM bemüht sich, die angezeigten Register aktuell zu halten - der User muss aber ein gewisse Vorsicht im Umgang damit walten lassen. Register können mit '''regSet''' gesetzt werden. Ob die gelesenen Register komplett sind prüft [[Homematic_HMInfo#Integrit.C3.A4tspr.C3.BCfungen|configCheck]]. Da einige Entities viele Register haben kann man mit dem Attribut '''expert''' die Sichtbarkeit steuern (siehe auch [[Homematic_HMInfo#Infos|Register]]).

Von einigen Devices sind Register schwer zu lesen, z.B. config devices. Man kann die Register-Readings [[Homematic_HMInfo#archConfig|archivieren]] und beim reboot wieder [[Homematic_HMInfo#archConfig|laden]].

==== Attribute====
Attribute sind i.a. Parameter, die das Verhalten der Entity steuern. Sie werden mit '''save''' in fhem.cfg oder einem seiner subfiles gespeichert. Nach einer Änderung sollte der User ein "save" machen, sonst sind diese nach einem Reboot verloren. 
Hier werden nur '''HM spezifische Attribute''' besprochen. 
Attribute, die das System '''automatisch''' anlegt. Sollten diese nicht mehr stimmen kann der User anlernen am Device drücken und sie werden wieder hergestellt. Der User sollte sie '''nicht ändern'''.
* model
* subType
* peerIDs: HMIds der peers. Wird gelegentlich verschoben!
* serialNr: auslaufend - durch Reading D-serianNr ersetzt
* firmware: auslaufend - durch Reading D-firmware ersetzt

Attribute für HM Entities, die der User steuern kann
* webCmd: FHEM setzt ggf. einen Default, der User kann dies anpassen
* expert: schaltet mehr oder weniger Readings sichtbar - dient der Übersichtlichkeit des Web-Interface.
* autoReadReg: steuert das automatische Lesen der Konfiguration - ggf. zeitverzögert um Resourcen zu schonen. Es wird Level 5 empfohlen

Attribute für HM Entities am Device, die der User steuern kann
* msgRepeat: kann man im Device einstellen. Es legt fest wir oft eine Nachricht wiederholt werden soll, falls sie nicht empfangen wird. Beachte, dass unabhängig davon ein HMLAN/USB immer 3-mal probiert zu senden. Insbesondere bei Burst Devices sollte man einen niedrigen level einstellen.
* IODev: Sollte man auf das IO device setzen, über das zu diesem Device gesendet werden soll. Es wird i.a. beim Pairen gesetzt.

Empfohlene Attribute außerhalb von HM
* event-on-change-reading .*

===Kommandos===
====Allgemein====
* get <name> cmdList ''# zeigt alle Kommandos mit Parametern für diese Entity an''
* clear [readings|register|rssi|msgEvents] ''# löschen von Readings oder Zählern''
====Register kommandos====
* set <name> getConfig ''# liest alle Peers und Register. Auf ein Device angewendet werden ALLE channels auch gelesen''
* set <name> regSet [prep|exec] <regName> <value> ... [<peerChannel>]'' #schreiben eines Registerwerts. Das Kommando landet im Kommandstack''
* set <name> regbulk ...''# kommando zum setzen von rohdaten und ganzen Registerlisten. Ausser zum re-configurieren eines ganzen Device eher nicht für den User zu gebrauchen''

* set <name> sign [on|off ''# setzt das Register um AES einzuschalten. Man sollte sich über AES '''vorher''' einlesen!!''

* get <name> regList ''# zeigt alle Register, die diese Entity '''unterstützt''' - incl Beschreibung und Wertebereich. Als Anfänger sollte man einmal hinsehen!''
* get <name> reg all ''# zeigt alle Register, die diese Entity '''hat''' und den aktuellen Wert''

===Kommunikation===
Die Kommunikation zwischen Device und der Zentrale folgt einem Protokoll. Für die meisten Nachrichten erwartet der Sender eine Empfangsbestätigung. FHEM beachtet das Protokoll und implementiert es entsprechend der Fähigkeiten des IO device.

Grundsätzlich kann jedes Device an jedes andere Nachrichten senden. Damit dies auch einen erfolg hat, müssen die Kanäle gepeert werden.

Um FHEM zu erlauben, Nachrichten an das Device zu richten muss FHEM gepairt werden. 
Das Senden der Nachrichten macht IMMER das Device - ein Kanal selbst kann nicht wirklich senden.

====Protokoll====
Da für das Senden das Device verantwortlich ist sind hier die entsprechenden Informationen zu finden. Zu Beachten sind die [[HomeMatic#Device|Übertragungsmodi]], die ein Device unterstützt. Die Internals "prot..." enthalten alle notwendigen Daten.
* protState: Der Zustand der Protokollmaschine
** CMDs_done: alle Nachrichten übertragen, keine Fehler in diesem Durchgang aufgetreten
** CMDs_done_Error:xx : es hat xx Fehler bei der letzten Übertragung gegeben.
** CMDs_pending: Nachrichten warten auf das Senden
** CMDs_processing... : die Nachrichtenübertragung ist im Gange
** Info_Cleared: die Protokoll Statistik wurde rückgesetzt
* protCmdPend: Anzahl der Nachrichten, die auf das Senden warten
* protCmdDel: Anzahl gelöschter Nachrichten aufgrund von Fehlern
* protCmdNack: Anzahl der negativen Acknowledges
* protCmdResnd: Anzahl der Wiederholungen - die Nachrichten wurden nicht gelöscht.
* protCmdResndFail: Anzahl der fehlgeschlagenen Wiederholungen - die Nachrichten wurden gelöscht.
* protCmdIOerr: Anzahl der IO Fehler - Übertragung war nicht Möglich, weil das IO Device Probleme hatte. Der Grund sollte im IO Device nachgesehen werden.
* protCmdIOdly: Anzahl der Verzögerungen aufgrund von IO Problemen
* protCmdTimedOn: Anzahl der Nachrichten, wenn ein Timer im Device genutzt wird - z.B. durch on-for-timer
* protCmdRcv: Anzahl empfangene Nachrichten
* protCmdSnd: Anzahl gesendete Nachrichten
* protCmdErrIoId_...: Anzahl der Sendeversuche zum Device von einer anderen Zentrale
* protCmdErrIoAttack: Anzahl der Sendeversuche zum Device die nicht von FHEM kam- es könnte ein Versuch sein, das System zu hacken. Dies wird auch im Reading '''sabotageAttack''' ausgegeben und man kann ein notify darauf ansetzen.

* protCmdEvt_AESCom: Anzahl der AES Nachrichten von Device
* protCmdEvt_AESKey: Benutzter AES key

Die Zähler können mit '''set <device> clear msgEvents''' rückgesetzt werden. Dies kann vor Konfigurationsänderungen Sinn machen, um Probleme besser erkennen zu können. 
Eine Übersicht kann man mit HMInfo [[Homematic_HMInfo#protoEvents|protoEvents]] erhalten. Auch das Löschen aller Zähler ist von HMInfo aus möglich.

====Rssi====
Zeigt den Empfangspegel, den ein Device von einem Anderen misst. Die Variablen sind in Internals abgelegt. Angegeben werden minimale und maximale Wert. Außerdem wird der Durchschnitt und die Anzahl der Nachrichten ausgewertet. 
HM liefert Empfangspegel am IO Device (FHEM standard) aber auch den Empfangspegel am Device selbst. Ebenfalls ausgewertet werden Pegel, die beim Senden zwischen Peers erreicht werden. 
Die Zähler können mit '''set <device> clear rssi''' rückgesetzt werden. 
Eine Übersicht erhält man mit HMInfo [[Homematic_HMInfo#RSSI|Rssi]]. Das Löschen der Zähler aller HM devices ist von HMInfo aus möglich. 

Man kann RSSI kontinuierlich aufzeichnen, wenn das Attribut '''rssiLog''' im Device gesetzt ist. Es wird ein Reading rssi_<name> erzeugt. Das generelle setzen dieses Attributs wird aus Performance-gründen nicht empfohlen.

== Pairen und Peeren ==
: ''→ Siehe auch: [[Pairing und Peering]]''

HomeMatic-Geräte können mit einer Zentrale (Fhem) ''gepairt'' und mit anderen HM-Geräten ''gepeert'' werden.

=== Pairen ===
: ''→ Siehe auch: [[Pairing (HomeMatic)]]''
: ''→ Anleitung: [[HomeMatic Devices pairen]]''

HM-Geräte können mit und ohne Zentrale betrieben werden. Fhem geht davon aus, dass Geräte immer von einer Zentrale aus gesteuert werden können. Dazu muss das Gerät mit der Zentrale ''gepairt'' werden.

=== Peeren ===
: ''→ Siehe auch: [[Peering (HomeMatic)]]

Um es Geräten zu ermöglichen auch ohne Zentrale zu interagieren (zum Beispiel wenn die Zentrale einen Defekt hat), können HM-Geräte untereinander ''gepeert'' werden.
Dazu wird ein Sensor-Kanal mit einem Aktor-Kanal verknüpft.

== HMInfo ==
: ''→ Siehe auch: [[Homematic HMInfo]]''

Bei der Betreuung einer HomeMatic-Installation ist das Modul [[Homematic_HMInfo|HMInfo]] sehr hilfreich. Es stellt eine Übersicht der HomeMatic-Komponenten zur Verfügung, kann die Konfiguration prüfen und Alarmierungen gesammelt auswerten.

== Besondere Entites ==

=== Virtuelle Entities ===
Virtuelle Entities sind nicht reale HM Devices und Kanäle. Man kann sie als Sender und Empfänger nutzen, auch im Zusammenhang mit Rauchmeldern oder zur Steuerung von Heizungsventilen. Die spezifischen Anwendungen sind im entsprechenden Kapitel nachzulesen. 
Angelegt wird das Device, dann wird per Kommando eine Anzahl Kanäle angelegt.
define <virtDev> CUL_HM 112233
set <virtDev> virtual 10
jetzt hat man ein virtuelles Device mit 10 Kanälen angelegt.
Die die gültigen Kommandos kann man wie immer mit '''get <entity> cmdList''' erfahren. 
Auch einem Virtuellen Device sollte man das '''Attribut IODev setzen '''.
=== IO Entities ===
: ''→ Siehe auch: [[Virtueller Controller VCCU#Virtuelle Kanäle der VCCU]]

'''IO-Entities''' sind virtuelle Kanäle der Zentrale, mit denen andere HomeMatic-Geräte gepeert werden können. Diese Kanäle sind einem ''IO-Device'' zugeordnet – im Unterschied zu ''virtuellen Entities'' gibt es kein virtuelles Homematic-Gerät welches die Kanäle beherbergt.

Jedem IO-Device können bis zu 50 Kanäle zugewiesen werden. Wenn mehrere IO-Devices die gleiche HMId nutzen, zum Beispiel wenn ein [[Virtueller Controller VCCU|virtueller Controller]] verwendet wird, teilen sich diese IO-Devices die Kanäle.

'''Anlegen:'''

# IO-Device definieren
define <IO-Device> CUL_HM c0ffee
attr <IO-Device> model CCU-FHEM

# 4 IO-Entities definieren
set <IO-Device> virtual 4

=== Action Detector===
Einige Devices der HM-Geräteserie senden periodisch Nachrichten. Manche alle 3 Minuten, andere alle 3 Tage. Wenn so eine Zeit für einen Device spezifiziert ist wird diese automatisch vom ActionDetector überwacht. 
Meist sind dies batteriebetriebene Geräte. Sollte aus irgendwelchen Gründen der Batteriealarm übersehen werden und das Gerät keine Nachricht mehr senden wird es auf Dead gesetzt.
Die Kontrollinstanz ist ein Pseudo-Gerät "ActionDetector" mit der HMId "000000"

* attribut
** actCycle: gibt an, in welchen Abständen sich das Device melden muss
** actStatus: gibt den Zustand an
*** alive: Device hat sich in der erwarteten Zeit min einmal gemeldet
*** dead: Device hat sich in der erwarteten Zeit nicht gemeldet
*** unknown: Device hat sich nicht gemeldet, es ist aber seit dem letzten reboot die Zykluszeit noch nicht abgelaufen.

* readings
** Activity: entsprechend dem actStatus.

* get
** listDevice: Gibt alle Objekte zurück
** listDevice notActive: Gibt alle Objekte zurück die nicht "alive" sind
** listDevice alive: Gibt alle Objekte zurück die "alive" sind
** listDevice unknown: Gibt alle Objekte zurück die "unknown" sind
** listDevice dead: Gibt alle Objekte zurück die "dead" sind

Durch das Setzen des Attributs im HM device wird der ActionDetector automatisch definiert - nach einem save steht er auch in der fhem.cfg.
Alternativ ist auch eine manuelle Definition möglich und sollte in etwa so aussehen:

define ActionDetector CUL_HM 000000
attr ActionDetector actCycle 30
attr ActionDetector event-on-change-reading .*
attr ActionDetector model ActionDetector

Die HMId "000000" darf nicht geändert werden.

In der Entity actionDetector kann man die Infos gesammelt einsehen.
Der User kann durch das Setzen des Attributs actCycle jedes Device in diese Liste aufnehmen. Es wird dann geprüft, ob sich das Device in dieser Zeit auch meldet. Der User muss dies aber selbst sicherstellen.

== Tipps / HowTos / Beispiele ==

* [[HomeMatic Devices pairen|HM Devices pairen]] zum '''Pairen''' der Geräte untereinander.
* [[CUL]] (also gleichzeitig)?
* [[Slider für HM-Rolladensteuerung anzeigen]]
* Für den "Fall der Fälle": Erstellen Sie eine Liste aller HM-Geräte mit den Installationsorten, HM-Namen, Fhem-Namen '''und''' den Geräte-IDs. Falls Sie sich ihr Fhem einmal zerschießen, wird diese Liste sehr hilfreich sein. Zur Abwicklung von Gewährleistungsansprüchen sind Daten über Kaufdatum und Lieferant (bei größeren Installationen mit Zukauf in zeitlichen Abständen) ebenfalls angebracht.

== Probleme ==

=== Messages Sniffen ===
Um Probleme besser nachvollziehen zu können, kann man [[Homematic_Nachrichten_sniffen|Nachrichten mitsniffen]]

=== Daten können empfangen werden, Befehle werden nicht übertragen ===

Das kann mehrere Ursachen haben:
* Pairing nicht abgeschlossen (bei den ''Readings'' "PairedTo" bzw. "R-pairCentral" steht der Wert '''set_'''0x1A2B3C). Das Pairing ist erst dann erfolgreich abgeschlossen, wenn das '''set_''' fehlt, also nur noch (beispielhaft) "0x1A2B3C" steht. Siehe [[HomeMatic_Devices_pairen]]
* Sender (CUL/HM-LAN) und Empfänger (HM-Device) stehen zu nah (RSSI-Werte bei ~ "-17") beieinander
* Sender (CUL/HM-LAN) und Empfänger (HM-Device) stehen zu weit (RSSI-Werte bei unter ~ "-80") voneinander entfernt
* ...

=== Notifys und anderes funktionieren nach einem Fhem-Neustart nicht mehr oder nicht mehr zeitnah ===

Obwohl HomeMatic wegen der höhren Datenübertragungsrate wesentlich weniger von der [[1% Regel]] betroffen ist als z.b. FS20 oder FHT, so kann es dennoch zu Funkkontingentüberschreitungen kommen.

Insbesondere ist bei FHEM Versionen ab Oktober 2013 das Attribut ''autoReadReg'' auf "4_reqStatus" gesetzt. Damit wird für jedes HM-Device mit diesem so gesetzten Attribut beim Fhem-Start ein ''getConfig'' durchgeführt, was viel Funkverkehr erfordert.

Je nach Anzahl der Geräte kann dazu führen, dass insgesamt zu viel Funklast erzeugt wird, im Logfile erscheint dann eine Meldung wie:

2013.10.03 13:41:18 2: HMLAN_Parse: HMLAN1 new condition ERROR-Overload

Ab diesem Moment werden eben auch keine anderen Befehle mehr an weitere HM-Geräte geschickt, da das Funkkontigent aufgebraucht ist. Erst nach einer Stunde kann erneut gesendet werden. Als '''Notbehelf''' kann die Funkschnittstelle resetted oder ([[HMLAN Konfigurator]]) kurz stromlos gemacht werden. Dann wird der Zähler wieder auf Null gesetzt.

Alternativ können so viele HM-Geräte wie möglich auf ''autoReadReg 0_off'' gesetzt werden.

Siehe auch: [[1% Regel]]

=== Spannungsversorgung ===
Die Batterielebensdauer der HomaMatic Komponenten ist durchwachsen. Besonders die mitgelieferten Batterien sind mitunter schon nach wenigen Wochen leer, trotzdem werden öfters keine ''battery low'' Meldung erzeugt. Bei Störung des Funkverkehrs (z.b. blinkendes Antennensymbol im HM-CC-TC und kurzes piepen zur vollen Stunde von morgens bis abends, fehlende ACK Meldungen, nicht auslösende IR-Bewegungssensoren und ähnliches) sollte also immer auch eine schlechte Spannungsversorgung in Betracht gezogen werden.

Gute neue Batterien halten jedoch i.d.R. 12 Monate und mehr, auch Lebensdauern über 2 Jahre sind bei einigen Geräten (Tür/Fensterkontakte, Sender, Retroanzeige, IR-Bewegungsmelder) keine Seltenheit.

== Links ==
* [http://www.homematic.com/ HomeMatic] Homepage
* Hersteller [http://www.eq-3.de eQ-3]

[[Kategorie:HomeMatic Components]]
[[Kategorie:Glossary]]

HomeMatic

2016-11-29T12:51:25Z

Krokofant: /* Peeren */

'''Achtung, diese Seite wird derzeit im Sinne einer klareren Beschreibung überarbeitet'''

'''HomeMatic''' (HM) ist ein System des Herstellers eQ-3 zur Steuerung und Überwachung von zahlreichen Aufgaben und Situationen im Haus. Erhältlich sind sowohl Geräte mit Funkschnittstelle 868.3 MHz, als auch (seit 2008) drahtgebundene Geräte mit RS485-Schnittstelle. Im Programm sind Geräte zur Heizungs- und Lichtsteuerung, Temperatur-, Luftfeuchte- und Feuchtemessung, Zutrittskontrolle, als Wasser-, Brand- und Bewegungsmelder sowie als Wetterstation, ferner gibt es noch Fernbedienungen und Statusdisplays.

=Grundlagen=
HomeMatic-Geräte können untereinander ''gepeert'' werden (engl. ''peers'' = "Gleiche"), im einfachsten Fall kann deshalb bereits ein Sensor (z.B. ein Temperatursensor) mit einem Aktor (z.B. einem Heizkörperregler) verbunden werden und diesen steuern. Hierbei können mehrere Sensoren und Aktoren untereinander verbunden werden, die Vorstellung der "Gleichen" ist also zutreffend.

HomeMatic-Geräte können auch mit einer Zentrale verbunden (''gepairt'') werden, die dann einen Teil der Steuerungslogik übernehmen kann. Bei dieser Verbindung spricht man vom ''Pairing'', weil jedes HomeMatic-Gerät nur mit einer Zentrale verbunden werden kann. Gepairte Geräte können auch nicht mehr direkt gepeert werden - dies geht dann nur noch unter Beteiligung der Zentrale.

==Voraussetzungen==
Für den Betrieb ohne Zentrale sind keine weiteren Voraussetzungen zu erfüllen.
===Zentrale von eQ-3===
Vom Hersteller eQ-3 selbst wird eine Zentrale (derzeit aktuell CCU-2) und Windows-Software zur Steuerung und Auswertung der HM-Komponenten angeboten.

===Fhem als Zentrale===
Zur Kommunikation mit HomeMatic benötigt Fhem eine Schnittstelle, die im 868,3-MHz-Band funken kann. Infrage kommen:
* [[CUL]] (USB)
* [[HM-CFG-USB USB Konfigurations-Adapter|HM-CFG-USB]] (USB)
* [[CUNO]] (LAN)
* [[HM-CFG-LAN]] (oft auch "HMLAN" genannt; LAN)
* [[HM-MOD-RPI-PCB HomeMatic Funkmodul f%C3%BCr Raspberry_Pi]]
* [[HM-LGW-O-TW-W-EU Funk-LAN Gateway]] (LAN)

Für ''HomeMatic Wired'' benötigt man eine RS485-Schnittstelle. Verfügbar sind:
* [[HomeMatic Wired RS485 LAN Gateway|HMW-LGW-O-DR-GS-EU]] (LAN)

===Migration von CCU-2 zu Fhem===
Der Umzug einer bestehenden HomeMatic Installation von einer HomeMatic CCU-2 auf Fhem ist möglich. Um die an die Zentrale angebundenen Devices in Fhem ohne größere Umkonfiguration weiter verwenden zu können, muß die HM-Id und, falls verwendet, die AES-Schlüssel der CCU-2 in Fhem übernommen werden. Um diese Daten aus der CCU-2 auszulesen, wird eine SSH-Verbindung (zum Beispiel mit PuTTY unter Windows) aufgebaut. Die HM-Id befindet sich in der Datei <code>/usr/local/etc/config/rfd/BidCoS-RF.dev</code> in einer Zeile wie dieser:

<device serial="BidCoS-RF" type="HM-RCV-50" address="0xABCDEF" aes_key_index="0" firmware_version="2.11.9" bidcos_interface="KEQ1234567" roaming="true">

Die HM-Id ist der Wert des <code>address</code>-Attributs. Die dort angegebene hexadezimale Zahl (hier <code>0xABCDEF</code>) ist die HM-Id und wird in Fhem ohne das "0x"-Präfix verwendet.

Falls AES-Schlüssel eingerichtet sind, sind diese in der Datei <code>/etc/config_templates/crypttool.cfg</code> zu finden und können 1:1 als Schlüssel im [[HM-CFG-LAN]] in der gleichen Reihenfolge hinterlegt werden.
{{Todo|Wie werden AES-Schlüssel in HM-CFG-LAN "hinterlegt"?}}

==Prototokoll==
HM-Geräte kommunizieren untereinander mit dem Protokoll ''Bidirectional Communication Standard'', abgekürzt ''BidCoS''. Jedes HM-Gerät enthält also Sender und Empfänger, das ist einer der wesentlichen Unterschiede z.B. zum FS20-System.
*Jedes HM-Gerät meldet beim Empfang eines Steuerbefehls durch einen Peer an diesen eine Bestätigung „ACK“ zurück. Erkennt das HM-Gerät den Befehl nicht, sendet es ein ''NACK''. Kommt vom HM-Gerät keine Rückmeldung innerhalb einer festgelegten Zeit, meldet der steuernde Peer ein ''MISSING ACK''.
*Jedes HM-Gerät meldet ferner seinen Status nach dem Erhalt eines Steuerbefehls zurück - so kann auch ein lokal am Gerät erfolgender Tastendruck in beim steuernden Peer oder in der Zentrale registriert werden.

Das Protokoll ''BidCoS'' wurde zum großen Teil entschlüsselt, seine offen verfügbare Variante heißt ''AskSin''. Unter Verwendung der AskSin-Library entstehen derzeit erste Geräte, die in das HomeMatic-System eingebunden werden können. Zur Unterscheidung zwischen HM und den neuen Geräten werden diese als [[HomeBrew]] (HB) bezeichnet.

=Betrieb mit Fhem=
Die Kenntnis des Dokumentes [http://fhem.de/Heimautomatisierung-mit-fhem.pdf Einsteigerdokuments "Heimautomatisierung mit Fhem"] wird vorausgesetzt. Im Anhang dieses Dokuments findet sich ein Teil über den Aufbau und die Funktion von HM-Geräten.

=== Einrichten des IO-Devices (Funkschnittstelle)===
Zuerst muss ein IO-Device eingerichtet werden, um mit HM Geräten kommunizieren zu können. Siehe hierzu [[HMLAN Konfigurator]].

=== Struktur von HM Geräten===
HM Geräte sind logisch in ein '''Device (Gerät)''' und ein oder mehrere '''Channels (Kanäle)''' gegliedert. Jedes Device und jeder Channel wird in einer Entity in FHEM repräsentiert. 
Ausnahme: Sollte ein Gerät nur einen Kanal haben werden diese zusammen in einer Entity angelegt.
====Device====
Das Device ist für die Kommunikation verantwortlich. Es sortiert und ordnet die zu sendenden und empfangenden Nachrichten.
Man kann prüfen, ob alle Nachrichten übertragen sind, oder ob es Probleme gegeben hat. Die Variablen "prot..." geben Auskunft darüber. Siehe auch [[Homematic_HMInfo#protoEvents]].
Zu beachten sind zudem die Übertragungsmodi. Nicht alle Devices sind ständig auf Empfang - FHEM muss berücksichtigen, wann gesendet werden kann. In '''protState''' kann man sehen, ob Kommandos auf Verarbeitung warten, also pending sind. Einige Devices unterstützen mehrere Modi parallel.

===== Config=====
Wird von allen Devices unterstützt, auch wenn es bei Always kaum genutzt werden kann.
Man setzt die Kommandos in FHEM ab und diese warten in der Kommando-queue.
Wenn die config-funktion am Device ausgelöst wird (Anlerntaste drücken) sendet FHEM die wartenden Nachrichten der Reihe nach. Config wird bei allen Devices zum pairen genutzt.

===== Always=====
Trifft man meist bei netzbetriebenen Geräten an, da diese kein Problem mit dem Energieverbrauch haben. Man kann immer mit dem Device kommunizieren.

===== Burst=====
Nur der Empfänger des Device ist aktiv. Über eine Aufweck-sequenz kann das Device geweckt werden. Man kann quasi immer mit dem Device kommunizieren. Nachteil des Aufwecken ist zum Einen, dass immer ALLE Devices im Funknetz geweckt werden, was deren Batterie belastet. Zum Andere ist die Aufweck-sequenz funktechnisch aufwändig und belastet die maximal erlaubte Sendekapazität des IO device je Stunde.

===== ConditionalBurst=====
Bei einigen Devices kann man den Burst mode zuschalten. Dies sind Devices, die zusätzlich über andere modi verfügen, so z.B. wakeup. Schaltet man burst-empfang ein kann man immer und sofort mit dem Device reden, es kostet aber etwas mehr Batterie. Siehe hierzu Attribut '''burstAccess''', Kommando '''burstXmit''' und Register '''burstRx'''
===== LazyConfig=====
Kommandos in der Queue werden bearbeitet, wenn eine Aktion vom Device ausgeht. So zum Beispiel ein Tastendruck bei einer Fernbedienung.
Dieser mode wird von CUL/CUNO nicht unterstützt. FHEM ignoriert diese Option automatisch und wartet i.a. auf ein Config.
===== Wakeup=====
Die Devices wachen regelmäßig auf und senden Daten, z.B. Temperatursensoren. Zu diesem Zeitpunkt kann FHEM die Nachrichten übertragen. Die Aufwachperiode ist unterschiedlich von 3 min bis zu 24h.

====Channel====
Ein Kanal ist die Funktionseinheit des Geräts. Hier ist die Funktion des Sensors oder Aktors realisiert.

Nutzt ein Gerät nur einen Kanal, wird dieser in FHEM der Übersichtlichkeit halber nicht einzeln angelegt. Für die Kommandos und das Peering wird trotzdem die HM-ID des 1. Kanals verwendet.

Nutzt ein Gerät hingegen mehrere Kanäle, werden diese per [[autocreate]] zusätzlich zum Device angelegt. Es ist aber möglich, bei Geräten mit virtuellen Kanälen, diese zu löschen und fehlende Attribute manuell dem Device hinzu zu fügen. Danach kann es wie ein 1-Kanal-Gerät genutzt werden. Allerdings werden die Kanäle beim erneuten Pairing von [[autocreate]] neu angelegt.

=====virtuelle Kanäle=====
Einige Dimmer unterstützen virtuelle Kanäle. Eigentlich haben sie keinen Hauptkanal sondern nur 3 virtuelle Kanäle, die je nach Verknüpfungslogik, den endgültigen Zustand des Aktors bestimmen. Dieses Verhalten wird in jedem Kanal per Register '''logicCombination''' gesetzt. 
Folgende Logik wird dabei angewendet: <tt>phyLevel = (((0% o Ch1) o Ch2) o Ch3)</tt> [o = Logik-Platzhalter]

D.h. es wird immer der Kanal mit dem gesetzten Register mit dem vorherigen Teilergebnis kombiniert, angefangen mit Kanal1. 
Es gibt folgende Logik-Optionen: [einzelne Betrachtung von <tt>(Vorergebnis o Kanal)</tt>]
{|
!style="text-align:left;"|Wert!!style="text-align:left;"|Bedeutung!!style="text-align:left;"|Beispiel (alle Werte in %)
|-
|inactive||keine Verknüpfung|| 30 inactive 80 = 30
|-
|or||oder (höchster Wert zählt)|| 30 or 80 = 80
|-
|and||und (kleinster Wert zählt)|| 30 and 80 = 30
|-
|xor||entweder-oder (nur 1 Kanal darf über 0% sein)|| 30 xor 80 = 0 ''aber'' 30 xor 0 = 30
|-
|nor||oder negiert (höchster Wert subtrahiert von 100%)|| 30 nor 80 ''= !80'' = 20
|-
|nand||und negiert (niedrigster Wert subtrahiert von 100%)|| 30 nand 80 ''= !30'' = 70
|-
|orinv||oder mit invertiertem Kanal|| 30 orinv 80 ''= 30 or 20'' = 30
|-
|andinv||und mit invertiertem Kanal|| 30 andinv 80 ''= 30 and 20'' = 20
|-
|plus||Vorergebnis addiert mit Kanal|| 30 plus 80 = 100
|-
|minus||Vorergebnis subtrahiert mit Kanal|| 30 minus 80 = 0
|-
|mul||Vorergebnis multipliziert mit Kanal|| 30 mul 80 = 24
|-
|plusinv||Vorergebnis addiert mit invertiertem Kanal|| 30 plusinv 80 ''= 30 plus 20'' = 50
|-
|minusinv||Vorergebnis subtrahiert mit invertiertem Kanal|| 30 minusinv 80 ''= 30 minus 20'' = 10
|-
|mulinv||Vorergebnis multipliziert mit invertiertem Kanal|| 30 mulinv 80 ''= 30 mul 20'' = 6
|-
|invPlus||invertiertes Vorergebnis addiert mit Kanal|| 30 invPlus 80 ''= 70 plus 80'' = 100
|-
|invMinus||invertiertes Vorergebnis subtrahiert mit Kanal|| 30 invMinus 80 ''= 70 minus 80'' = 0
|-
|invMul||invertiertes Vorergebnis multipliziert mit Kanal|| 30 invMul 80 ''= 70 mul 80'' = 56
|}
: ''→ Siehe auch: [[HM-LC-Dim1PWM-CV Dimmaktor PWM DC-LED#Beispiele|Verknüpfungsbeispiel]]''

=== Variablen===
Wie alle FHEM Entities werden 4 Gruppen von Daten unterstützt:
* Internals: Im Web-Interface sichtbare Variablen, die allgemeine Informationen über den Zustand enthalten.
* Readings: Im Web-Interface sichtbare Variablen. Sie werden aus von Entites empfangenen Nachrichten generiert. Man kann mit notify Trigger auf die setzen. Readings werden im Statefile bei save und gewissen neustarts gesichert und beim Booten eingelesen. Readings haben einen Zeitstempel.
* Attribute: Im Web-Interface sichtbare Variablen. Über sie kann man die Eigenschaften der Entity in FHEM steuern.
* Helper: Im Web-Interface nicht sichtbare Variablen. Man kann sie mit dem Kommando 'list' sehen. Es sind hilfsvariablen, die für den User keine Bedeutung haben sollen.
==== Internals====
Viele Variablen sind nicht HM spezifisch - deren Bedeutung muss in allgemeinen Teil nachgelesen werden. Spezifische Variablen sind:
*Device
** channel_xx: Liste der Kanäle, die dem Device zugeordnet sind.
** prot... : Gruppe von Daten zum Zustand des [[HomeMatic#Protokol|Protokolls]], also der Kommunikation mit dem Device.
** rssi...: Gruppe von Daten die den [[HomeMatic#Rssi|Empfangspegel]] des Device bei IOs, Peers und Repeatern darstellt.

*Kanäle
** device: Das übergeordnete Device
** chanNo: Die Kanalnummer
** peerList: Ist die Entity mit einem anderen gepeert ist steht hier der Name der Peers. Siehe auch attribut peerIDs und Reading peerList. Diese Variable ist mit dem peer verlinkt, man kann darauf 'clicken'.

==== Readings====
Readings für HM Entites unterliegenden allgemeinen FHEM Regeln.
Generell gilt, dass ein Wert, der von FHEM gesetzt wurde mit dem prefix '''"set_"''' versehen wird. Wenn der Zustand bestätigt ist wird das set_ entfernt. Sollte man also ein Reading mit diesem prefix haben, das sich nicht selbst entfernt sollt man unbedingt den Zustand kontrollieren. 
So ist nach einem "set Licht on" der Zustand des Licht erst einemal "set_on". Mit der Antwort des Device wird es dann auf "on" gesetzt. 
Register machen eine Ausnahme:

=====Register=====
Register sind Konfigurationsparameter, die '''im Device flash''' gespeichert werden. Daten, die Registern zureordnet sind beginnen mit "R-". Sollte das Register einem peer zugeordnet sein kommt dieser danach. Der Namen ist also '''R-<peer>-<registerName>'''.

Der Zugriff ist indirekt, geht also nur über Methoden und Kommandos. Man kann die Konfiguration (Register und peers) mit '''getConfig''' aus dem Device lesen und in FHEM dargestellen. FHEM bemüht sich, die angezeigten Register aktuell zu halten - der User muss aber ein gewisse Vorsicht im Umgang damit walten lassen. Register können mit '''regSet''' gesetzt werden. Ob die gelesenen Register komplett sind prüft [[Homematic_HMInfo#Integrit.C3.A4tspr.C3.BCfungen|configCheck]]. Da einige Entities viele Register haben kann man mit dem Attribut '''expert''' die Sichtbarkeit steuern (siehe auch [[Homematic_HMInfo#Infos|Register]]).

Von einigen Devices sind Register schwer zu lesen, z.B. config devices. Man kann die Register-Readings [[Homematic_HMInfo#archConfig|archivieren]] und beim reboot wieder [[Homematic_HMInfo#archConfig|laden]].

==== Attribute====
Attribute sind i.a. Parameter, die das Verhalten der Entity steuern. Sie werden mit '''save''' in fhem.cfg oder einem seiner subfiles gespeichert. Nach einer Änderung sollte der User ein "save" machen, sonst sind diese nach einem Reboot verloren. 
Hier werden nur '''HM spezifische Attribute''' besprochen. 
Attribute, die das System '''automatisch''' anlegt. Sollten diese nicht mehr stimmen kann der User anlernen am Device drücken und sie werden wieder hergestellt. Der User sollte sie '''nicht ändern'''.
* model
* subType
* peerIDs: HMIds der peers. Wird gelegentlich verschoben!
* serialNr: auslaufend - durch Reading D-serianNr ersetzt
* firmware: auslaufend - durch Reading D-firmware ersetzt

Attribute für HM Entities, die der User steuern kann
* webCmd: FHEM setzt ggf. einen Default, der User kann dies anpassen
* expert: schaltet mehr oder weniger Readings sichtbar - dient der Übersichtlichkeit des Web-Interface.
* autoReadReg: steuert das automatische Lesen der Konfiguration - ggf. zeitverzögert um Resourcen zu schonen. Es wird Level 5 empfohlen

Attribute für HM Entities am Device, die der User steuern kann
* msgRepeat: kann man im Device einstellen. Es legt fest wir oft eine Nachricht wiederholt werden soll, falls sie nicht empfangen wird. Beachte, dass unabhängig davon ein HMLAN/USB immer 3-mal probiert zu senden. Insbesondere bei Burst Devices sollte man einen niedrigen level einstellen.
* IODev: Sollte man auf das IO device setzen, über das zu diesem Device gesendet werden soll. Es wird i.a. beim Pairen gesetzt.

Empfohlene Attribute außerhalb von HM
* event-on-change-reading .*

===Kommandos===
====Allgemein====
* get <name> cmdList ''# zeigt alle Kommandos mit Parametern für diese Entity an''
* clear [readings|register|rssi|msgEvents] ''# löschen von Readings oder Zählern''
====Register kommandos====
* set <name> getConfig ''# liest alle Peers und Register. Auf ein Device angewendet werden ALLE channels auch gelesen''
* set <name> regSet [prep|exec] <regName> <value> ... [<peerChannel>]'' #schreiben eines Registerwerts. Das Kommando landet im Kommandstack''
* set <name> regbulk ...''# kommando zum setzen von rohdaten und ganzen Registerlisten. Ausser zum re-configurieren eines ganzen Device eher nicht für den User zu gebrauchen''

* set <name> sign [on|off ''# setzt das Register um AES einzuschalten. Man sollte sich über AES '''vorher''' einlesen!!''

* get <name> regList ''# zeigt alle Register, die diese Entity '''unterstützt''' - incl Beschreibung und Wertebereich. Als Anfänger sollte man einmal hinsehen!''
* get <name> reg all ''# zeigt alle Register, die diese Entity '''hat''' und den aktuellen Wert''

===Kommunikation===
Die Kommunikation zwischen Device und der Zentrale folgt einem Protokoll. Für die meisten Nachrichten erwartet der Sender eine Empfangsbestätigung. FHEM beachtet das Protokoll und implementiert es entsprechend der Fähigkeiten des IO device.

Grundsätzlich kann jedes Device an jedes andere Nachrichten senden. Damit dies auch einen erfolg hat, müssen die Kanäle gepeert werden.

Um FHEM zu erlauben, Nachrichten an das Device zu richten muss FHEM gepairt werden. 
Das Senden der Nachrichten macht IMMER das Device - ein Kanal selbst kann nicht wirklich senden.

====Protokoll====
Da für das Senden das Device verantwortlich ist sind hier die entsprechenden Informationen zu finden. Zu Beachten sind die [[HomeMatic#Device|Übertragungsmodi]], die ein Device unterstützt. Die Internals "prot..." enthalten alle notwendigen Daten.
* protState: Der Zustand der Protokollmaschine
** CMDs_done: alle Nachrichten übertragen, keine Fehler in diesem Durchgang aufgetreten
** CMDs_done_Error:xx : es hat xx Fehler bei der letzten Übertragung gegeben.
** CMDs_pending: Nachrichten warten auf das Senden
** CMDs_processing... : die Nachrichtenübertragung ist im Gange
** Info_Cleared: die Protokoll Statistik wurde rückgesetzt
* protCmdPend: Anzahl der Nachrichten, die auf das Senden warten
* protCmdDel: Anzahl gelöschter Nachrichten aufgrund von Fehlern
* protCmdNack: Anzahl der negativen Acknowledges
* protCmdResnd: Anzahl der Wiederholungen - die Nachrichten wurden nicht gelöscht.
* protCmdResndFail: Anzahl der fehlgeschlagenen Wiederholungen - die Nachrichten wurden gelöscht.
* protCmdIOerr: Anzahl der IO Fehler - Übertragung war nicht Möglich, weil das IO Device Probleme hatte. Der Grund sollte im IO Device nachgesehen werden.
* protCmdIOdly: Anzahl der Verzögerungen aufgrund von IO Problemen
* protCmdTimedOn: Anzahl der Nachrichten, wenn ein Timer im Device genutzt wird - z.B. durch on-for-timer
* protCmdRcv: Anzahl empfangene Nachrichten
* protCmdSnd: Anzahl gesendete Nachrichten
* protCmdErrIoId_...: Anzahl der Sendeversuche zum Device von einer anderen Zentrale
* protCmdErrIoAttack: Anzahl der Sendeversuche zum Device die nicht von FHEM kam- es könnte ein Versuch sein, das System zu hacken. Dies wird auch im Reading '''sabotageAttack''' ausgegeben und man kann ein notify darauf ansetzen.

* protCmdEvt_AESCom: Anzahl der AES Nachrichten von Device
* protCmdEvt_AESKey: Benutzter AES key

Die Zähler können mit '''set <device> clear msgEvents''' rückgesetzt werden. Dies kann vor Konfigurationsänderungen Sinn machen, um Probleme besser erkennen zu können. 
Eine Übersicht kann man mit HMInfo [[Homematic_HMInfo#protoEvents|protoEvents]] erhalten. Auch das Löschen aller Zähler ist von HMInfo aus möglich.

====Rssi====
Zeigt den Empfangspegel, den ein Device von einem Anderen misst. Die Variablen sind in Internals abgelegt. Angegeben werden minimale und maximale Wert. Außerdem wird der Durchschnitt und die Anzahl der Nachrichten ausgewertet. 
HM liefert Empfangspegel am IO Device (FHEM standard) aber auch den Empfangspegel am Device selbst. Ebenfalls ausgewertet werden Pegel, die beim Senden zwischen Peers erreicht werden. 
Die Zähler können mit '''set <device> clear rssi''' rückgesetzt werden. 
Eine Übersicht erhält man mit HMInfo [[Homematic_HMInfo#RSSI|Rssi]]. Das Löschen der Zähler aller HM devices ist von HMInfo aus möglich. 

Man kann RSSI kontinuierlich aufzeichnen, wenn das Attribut '''rssiLog''' im Device gesetzt ist. Es wird ein Reading rssi_<name> erzeugt. Das generelle setzen dieses Attributs wird aus Performance-gründen nicht empfohlen.

== Pairen und Peeren ==
: ''→ Siehe auch: [[Pairing und Peering]]''

HomeMatic-Geräte können mit einer Zentrale (Fhem) ''gepairt'' und mit anderen HM-Geräten ''gepeert'' werden.

=== Pairen ===
: ''→ Hauptartikel: [[HomeMatic Devices pairen]]''

HM-Geräte können mit und ohne Zentrale betrieben werden. Fhem geht davon aus, dass Geräte immer von einer Zentrale aus gesteuert werden können. Dazu muss das Gerät mit der Zentrale ''gepairt'' werden.

=== Peeren ===
: ''→ Siehe auch: [[Peering (HomeMatic)]]

Um es Geräten zu ermöglichen auch ohne Zentrale zu interagieren (zum Beispiel wenn die Zentrale einen Defekt hat), können HM-Geräte untereinander ''gepeert'' werden.
Dazu wird ein Sensor-Kanal mit einem Aktor-Kanal verknüpft.

== HMInfo ==
: ''→ Siehe auch: [[Homematic HMInfo]]''

Bei der Betreuung einer HomeMatic-Installation ist das Modul [[Homematic_HMInfo|HMInfo]] sehr hilfreich. Es stellt eine Übersicht der HomeMatic-Komponenten zur Verfügung, kann die Konfiguration prüfen und Alarmierungen gesammelt auswerten.

== Besondere Entites ==

=== Virtuelle Entities ===
Virtuelle Entities sind nicht reale HM Devices und Kanäle. Man kann sie als Sender und Empfänger nutzen, auch im Zusammenhang mit Rauchmeldern oder zur Steuerung von Heizungsventilen. Die spezifischen Anwendungen sind im entsprechenden Kapitel nachzulesen. 
Angelegt wird das Device, dann wird per Kommando eine Anzahl Kanäle angelegt.
define <virtDev> CUL_HM 112233
set <virtDev> virtual 10
jetzt hat man ein virtuelles Device mit 10 Kanälen angelegt.
Die die gültigen Kommandos kann man wie immer mit '''get <entity> cmdList''' erfahren. 
Auch einem Virtuellen Device sollte man das '''Attribut IODev setzen '''.
=== IO Entities ===
: ''→ Siehe auch: [[Virtueller Controller VCCU#Virtuelle Kanäle der VCCU]]

'''IO-Entities''' sind virtuelle Kanäle der Zentrale, mit denen andere HomeMatic-Geräte gepeert werden können. Diese Kanäle sind einem ''IO-Device'' zugeordnet – im Unterschied zu ''virtuellen Entities'' gibt es kein virtuelles Homematic-Gerät welches die Kanäle beherbergt.

Jedem IO-Device können bis zu 50 Kanäle zugewiesen werden. Wenn mehrere IO-Devices die gleiche HMId nutzen, zum Beispiel wenn ein [[Virtueller Controller VCCU|virtueller Controller]] verwendet wird, teilen sich diese IO-Devices die Kanäle.

'''Anlegen:'''

# IO-Device definieren
define <IO-Device> CUL_HM c0ffee
attr <IO-Device> model CCU-FHEM

# 4 IO-Entities definieren
set <IO-Device> virtual 4

=== Action Detector===
Einige Devices der HM-Geräteserie senden periodisch Nachrichten. Manche alle 3 Minuten, andere alle 3 Tage. Wenn so eine Zeit für einen Device spezifiziert ist wird diese automatisch vom ActionDetector überwacht. 
Meist sind dies batteriebetriebene Geräte. Sollte aus irgendwelchen Gründen der Batteriealarm übersehen werden und das Gerät keine Nachricht mehr senden wird es auf Dead gesetzt.
Die Kontrollinstanz ist ein Pseudo-Gerät "ActionDetector" mit der HMId "000000"

* attribut
** actCycle: gibt an, in welchen Abständen sich das Device melden muss
** actStatus: gibt den Zustand an
*** alive: Device hat sich in der erwarteten Zeit min einmal gemeldet
*** dead: Device hat sich in der erwarteten Zeit nicht gemeldet
*** unknown: Device hat sich nicht gemeldet, es ist aber seit dem letzten reboot die Zykluszeit noch nicht abgelaufen.

* readings
** Activity: entsprechend dem actStatus.

* get
** listDevice: Gibt alle Objekte zurück
** listDevice notActive: Gibt alle Objekte zurück die nicht "alive" sind
** listDevice alive: Gibt alle Objekte zurück die "alive" sind
** listDevice unknown: Gibt alle Objekte zurück die "unknown" sind
** listDevice dead: Gibt alle Objekte zurück die "dead" sind

Durch das Setzen des Attributs im HM device wird der ActionDetector automatisch definiert - nach einem save steht er auch in der fhem.cfg.
Alternativ ist auch eine manuelle Definition möglich und sollte in etwa so aussehen:

define ActionDetector CUL_HM 000000
attr ActionDetector actCycle 30
attr ActionDetector event-on-change-reading .*
attr ActionDetector model ActionDetector

Die HMId "000000" darf nicht geändert werden.

In der Entity actionDetector kann man die Infos gesammelt einsehen.
Der User kann durch das Setzen des Attributs actCycle jedes Device in diese Liste aufnehmen. Es wird dann geprüft, ob sich das Device in dieser Zeit auch meldet. Der User muss dies aber selbst sicherstellen.

== Tipps / HowTos / Beispiele ==

* [[HomeMatic Devices pairen|HM Devices pairen]] zum '''Pairen''' der Geräte untereinander.
* [[CUL]] (also gleichzeitig)?
* [[Slider für HM-Rolladensteuerung anzeigen]]
* Für den "Fall der Fälle": Erstellen Sie eine Liste aller HM-Geräte mit den Installationsorten, HM-Namen, Fhem-Namen '''und''' den Geräte-IDs. Falls Sie sich ihr Fhem einmal zerschießen, wird diese Liste sehr hilfreich sein. Zur Abwicklung von Gewährleistungsansprüchen sind Daten über Kaufdatum und Lieferant (bei größeren Installationen mit Zukauf in zeitlichen Abständen) ebenfalls angebracht.

== Probleme ==

=== Messages Sniffen ===
Um Probleme besser nachvollziehen zu können, kann man [[Homematic_Nachrichten_sniffen|Nachrichten mitsniffen]]

=== Daten können empfangen werden, Befehle werden nicht übertragen ===

Das kann mehrere Ursachen haben:
* Pairing nicht abgeschlossen (bei den ''Readings'' "PairedTo" bzw. "R-pairCentral" steht der Wert '''set_'''0x1A2B3C). Das Pairing ist erst dann erfolgreich abgeschlossen, wenn das '''set_''' fehlt, also nur noch (beispielhaft) "0x1A2B3C" steht. Siehe [[HomeMatic_Devices_pairen]]
* Sender (CUL/HM-LAN) und Empfänger (HM-Device) stehen zu nah (RSSI-Werte bei ~ "-17") beieinander
* Sender (CUL/HM-LAN) und Empfänger (HM-Device) stehen zu weit (RSSI-Werte bei unter ~ "-80") voneinander entfernt
* ...

=== Notifys und anderes funktionieren nach einem Fhem-Neustart nicht mehr oder nicht mehr zeitnah ===

Obwohl HomeMatic wegen der höhren Datenübertragungsrate wesentlich weniger von der [[1% Regel]] betroffen ist als z.b. FS20 oder FHT, so kann es dennoch zu Funkkontingentüberschreitungen kommen.

Insbesondere ist bei FHEM Versionen ab Oktober 2013 das Attribut ''autoReadReg'' auf "4_reqStatus" gesetzt. Damit wird für jedes HM-Device mit diesem so gesetzten Attribut beim Fhem-Start ein ''getConfig'' durchgeführt, was viel Funkverkehr erfordert.

Je nach Anzahl der Geräte kann dazu führen, dass insgesamt zu viel Funklast erzeugt wird, im Logfile erscheint dann eine Meldung wie:

2013.10.03 13:41:18 2: HMLAN_Parse: HMLAN1 new condition ERROR-Overload

Ab diesem Moment werden eben auch keine anderen Befehle mehr an weitere HM-Geräte geschickt, da das Funkkontigent aufgebraucht ist. Erst nach einer Stunde kann erneut gesendet werden. Als '''Notbehelf''' kann die Funkschnittstelle resetted oder ([[HMLAN Konfigurator]]) kurz stromlos gemacht werden. Dann wird der Zähler wieder auf Null gesetzt.

Alternativ können so viele HM-Geräte wie möglich auf ''autoReadReg 0_off'' gesetzt werden.

Siehe auch: [[1% Regel]]

=== Spannungsversorgung ===
Die Batterielebensdauer der HomaMatic Komponenten ist durchwachsen. Besonders die mitgelieferten Batterien sind mitunter schon nach wenigen Wochen leer, trotzdem werden öfters keine ''battery low'' Meldung erzeugt. Bei Störung des Funkverkehrs (z.b. blinkendes Antennensymbol im HM-CC-TC und kurzes piepen zur vollen Stunde von morgens bis abends, fehlende ACK Meldungen, nicht auslösende IR-Bewegungssensoren und ähnliches) sollte also immer auch eine schlechte Spannungsversorgung in Betracht gezogen werden.

Gute neue Batterien halten jedoch i.d.R. 12 Monate und mehr, auch Lebensdauern über 2 Jahre sind bei einigen Geräten (Tür/Fensterkontakte, Sender, Retroanzeige, IR-Bewegungsmelder) keine Seltenheit.

== Links ==
* [http://www.homematic.com/ HomeMatic] Homepage
* Hersteller [http://www.eq-3.de eQ-3]

[[Kategorie:HomeMatic Components]]
[[Kategorie:Glossary]]

Raumbedarfsabhängige Heizungssteuerung

2016-11-29T12:36:58Z

Krokofant: Link repariert

{{SEITENTITEL:Mischerregelung }}
{{Infobox Modul
|ModPurpose=Dieses Modul ist noch Entwicklung
|ModType=x


|ModForumArea=Codeschnipsel
|ModTechName=39_VALVES.pm
|ModOwner=epsrw1,cwagner}}

Das Fhem-[[:Kategorie:Hilfsmodul|Hilfsmodul]] [[VALVES]] bietet eine einfache Möglichkeit, eine raumbedarfsabhängige Steuerung des Vorlaufes (Brenner oder Mischer, dazu siehe auch [[Mischersteuerung]]) einer Zentralheizung umzusetzen. Diese berücksichtigt besser als eine Außentemperatursteuerung interne und externe Wärmequellen.

== Features ==

Diese Wiki-Seite beschreibt den derzeitigen Stand des VALVES-Moduls.

----

Thread im Forum:[http://forum.fhem.de/index.php/topic,24658.msg177528.html#msg177528]

== Beschreibung ==

[[Datei:dok39_VALVES.jpg|mini|Funktionsweise]]
VALVES bietet als kleines Helferlein die Möglichkeit, einen halbwegs sinnvollen und individuell gewichteten Durchschnittswert der Ventilpositionen mehrerer Heizungsthermostate zu berechnen.

Dieser (gewichtete) Durchschnittswert der Ventilöffnungen ist ein Ausdruck der Wärmeanforderung im Haus. Da die Raumthermostate aus der FS20-, der Homematic und der Max-Reihe ihrerseits immer bessere Strategien verfolgen, um die Entwicklung der Temperatur in jeweils "ihrem" Raum zu erkennen, hat die Ventilposition eine große Aussagekraft.

Zugleich wird auch Vorlaufsteuerung des Heizkessels oder der Heiztherme autoamtisch durch Nachabsenkungen, aBwesentheitsschaltungen einerseits und durch zusätzliche Wärmequellen, die das Haus aufheizen, beeinflusst.

Idealerweise ist der Vorlauf dann gerade so groß, dass der Wärmebedarf im Haus überall gestillt wird.

Die Liste aller Thermostate wird in einem attr eingestellt, der Name des readings mit der Ventilposition in einem weiteren. Das Modul prüft dann regelmäßig (attr: poll interval) die Daten des Fhem-Devices und berechnet neu, wenn ein Änderung festgestellt wird.

Für die Beeinflussung des Durchschnittes hat man folgende Attribute:

* ignoriere niedrigste 0...3 Positionen

* ignoriere höchste 0...3 Positionen

* ignoriere namentlich genannte Devices

* priority-device Liste (zählen doppelt)

* valves<Devicename>Gewichtung optionale Einzeleinstellung für jeden Thermostat, multipliziere mit attr-wert (zB:0,95 um 5% der position abzuziehen). Damit können Unterschiede im hydraulischen Abgleich kompensiert werden, oder inidividuelles Nutzungsverhalten feinjustiert.

== Define ==
<code>
define <name> VALVES
</code>

----

== Attribute ==

Alle Attributes sind auch in fhem durch das kommando get attrHelp <varname> erklärt, für's "schnelle Nachschauen zwischendurch".

valvesInitialDelay ->startverzögerung

valvesPollInterval ->berechnungsfrequenz

valvesDeviceList ->'''Pflicht-Attr''', liste thermostate mit valve-pos readings

valvesDeviceReading ->'''Pflicht-Attr''', bezeichnung valve-pos reading

valvesIgnoreLowest ->niedrigste N werte ignorieren

valvesIgnoreHighest ->höchste N werte ignorieren

valvesIgnoreDeviceList ->device(s) die komplett ignoriert werden, zB. temporärer eintrag für gästezimmer

valvesPriorityDeviceList ->devices, die doppelt gezählt werden

valves<Devicename>Gewichtung ->faktor für einzelnes device für individuelle gewichtung

== Settings ==
reset ->alle readings zurücksetzen

== Readings ==

state -> Fehlermeldung oder Mittelwert nach oben beschriebener Berechnung

valve_<Devicename> -> berechnete virtuelle Ventilstellung pro Gerät

valveDetail_<Devicename> -> Debug-Info mit Details

raw_average -> simpler Mittelwert ohne Berücksichtigung der Gewichtungen (ignores werden auch hier ignoriert)

valve_average -> Mittelwert nach oben beschriebener Berechnung

valve_max -> größte aktuelle Ventilöffnung seit letztem Reset

valve_min -> kleinste aktuelle Ventilöffnung seit letzutem Reset

== Weblinks ==
* [http://forum.fhem.de/index.php/topic,24658.msg177528.html#msg177528] Thread im Forum, in dem dieses Modul vorgestellt wurde
* to be continued

[[Kategorie:Regelungstechnik]]
[[Kategorie:Examples]]
[[Kategorie:Heizungssteuerung]]

FHT8v

2016-11-20T18:28:38Z

Krokofant: Abgekündigt

{{Infobox Hardware
|Bild=FHT8V-3.jpg
|Bildbeschreibung=FHT8V (hier FHT8V-3) Funk Stellantrieb
|HWProtocol=FHT
|HWType=Empfänger
|HWCategory=FHT
|HWComm=868,35 MHz
|HWChannels=1
|HWVoltage=3 V
|HWPowerConsumption=(ca. 2 Jahre)
|HWPoweredBy=2x AA
|HWSize=100 x 60 x 60 mm
|HWDeviceFHEM=11_FHT8V.pm
|HWManufacturer=ELV / eQ-3
}}

[[FHT8v]] ist ein Stellantrieb/Ventilantrieb für Heizungsventile.

'''Achtung: Dieses Gerät ist abgekündigt (wird nicht mehr hergestellt).'''[https://forum.fhem.de/index.php/topic,60219.0.html]

== Features ==
Dieser Aktuator ersetzt die manuellen Thermostate einer bestehenden Heizung. Er öffnet und schliesst das Heizungsventil mittels eines batteriebetriebenen Motors. Die Regelung erfolgt standardgemäß durch ein ("gepairtes") Raumthermostat [[FHT80b]]. In dem kleinen Display kann der aktuelle Öffnungsgrad (0-99%), Funklage, Batteriekapazität und Status abgelesen werden.

== Hinweise zum Betrieb mit FHEM ==
Einsetzbar. Im Normalfall "spricht" FHEM mit dem gepairten FHT80b, es ist jedoch auch möglich, die Stellantriebe mit FHEM [[FHT 8v direkt ansprechen|direkt anzusprechen]].

Darüber hinaus werden die Informationen der FHT8v auch von einem ggf. vorhandenen und entsprechend konfigurierten [[FHT8w|Wärmebedarfsrelais]] empfangen und ausgewertet.

== Versionen ==
Aktuell (2015) sind FHT8V'''-3''' im Handel.

Unterschiede zu vorhergeneden Versionen:
* (bitte hier eintragen/ergänzen)

== Bekannte Probleme ==
Keine (früher vorhandene Timing Probleme bei Direktsteuerung mittels CUNO gelöst).

== Links ==
* {{DocLink|elv|/service/manuals/57644_FHT8V_2_um_web.pdf Anleitung}}
* {{DocLink|elv|/service/manuals/ventilkompatibilitaet.pdf Liste kompatibler Heizungsventile}}

[[Kategorie:FHT Components]]
[[Kategorie:Heizungsventile]]

FHT8b

2016-11-20T18:27:56Z

Krokofant: Abgekündigt

= FHT8b Heizungs-Controller =
Programmierbarer Raumthermostat, der bis zu 8 Stellantriebe [[FHT8v]] steuern kann.

'''Achtung: Dieses Gerät ist abgekündigt (wird nicht mehr hergestellt).'''[https://forum.fhem.de/index.php/topic,60219.0.html]

== Features ==
Lokal programmierbare Tages- und Nachtemperatur, die pro Tag mit 4 Schaltpunkten programmiert werden kann.

== Hinweise zum Betrieb mit FHEM ==
Vor dem Einsatz muss der FHT8b mit der Zentrale gepairt werden. Geschieht dies nicht, können nach einer Definition in FHEM zwar Daten des FHT8b empfangen werden (z.B. Raumtemperatur), es können jedoch keine Befehle gesendet werden. Zum pairen den FHT8b in Sonderfunktionen "cENT" auf "n/a" stellen, danach sofort einen Befehl (egal welchen) an den FHT8b senden. Wenn ca. zwei Minuten später Sonderfunktion cENT auf "ON" steht, war das Pairing erfolgreich.

Weitere Hinweise: [[FHT mit RFR CUL pairen]].

Der FHT8b akzeptiert Befehle von FHZ1X00 (oder CUL/CUN) nur alle 115+x Sekunden, der Wert x errechnet sich aus dem Hauscode. In der Praxis ergeben sich ca. zwei Minuten.
Wenn man also mit FHEM z.B. fünf desired-temp Wechsel sendet, kann es bis zu zehn Minuten dauern, bis der letzte ausgeführt wird.

Dies muss insbesondere beim Debuggen von Automationsszenarien berücksichtig werden. Nicht absetzbare Kommandos werden im einem Puffer der FHZ1x00/CUL/CUN gespeichert, obwohl sie im FHEM Log als abgesetzt erscheinen. Bei größeren Installationen kann auch der Puffer überlaufen (EOB Fehlermeldung im FHEM Log). Die Puffer sind unterschiedlich gross. Am kleinsten ist er bei den FHZ1x00 mit ca. 40 Byte, was für ca. acht FHT Befehle reicht. Am grössten ist er im CULv3 oder CUN mit 200 Bytes, das reicht für ca. 40 Befehle.

Bei zu kleinem Puffer bietet FHEM die Möglichkeit, einen Softpuffer (fhtsoftbuffer) zu konfigurieren. Dies ist vermutlich bei CUL/CUN weniger sinnvoll, da die Abarbeitung des gesamte Puffers sehr viel Zeit in Anspruch nehmen kann. Dies könnte dazu führen, dass Kommandos an FHTs erst Stunden später ausgeführt werden.

Um mehr Befehle an ein FHT8b senden zu können, können bis zu acht Befehle zusammengefasst werden, diese belegen dann nur einen "Zeitslot", zum Beispiel so:

<nowiki>set heizung_wohn desired-temp 20.5 day-temp 19.0 night-temp 16.0</nowiki>

Die Kommunikation des FHT8b mit den Stellventilen erfolgt ebenso in Zeitabständen von ca. zwei Minuten. In den Pausen sind die Sender und Empfänger von FHT8b und FHT8v abgeschaltet, um Batteriestrom zu sparen.

Die Übermittlung der aktuellen Temperaturdaten an die Zentrale (FHZ, [[CUN]]) erfolgt alle 15 Minuten.

Die Kommunikation mit der Zentrale ist bidirektional, d.h. die Funkzentrale sendet auch Daten an die FHT80b zurück (insbesondere Bestätigungsmeldungen). Dies führt dazu, dass im Zusammenhang mit der [[Maximal nutzbare Geräte|Sendezeitbegrenzung]] die Anzahl von einer Zentrale unterstützten FHT8b begrenzt ist. Theoretisch lassen sich 17, praktisch ca. zehn FHT8b sinnvoll mit einer Zentrale steuern.

== Bekannte Probleme ==
* Die Sendefrequenz einiger FHT8b ist nicht besonders genau auf den eigentlichen Wert von 868,35 Mhz justiert und streut bei verschiedenen Geräten. Die FHZ 1x00PC Geräte sind gegenüber leichten Abweichungen der Frequenz durch eine etwas höhere Empfangsbandbreite eher unempfindlich. Die [[CUN]] halten die eingestellte Frequenz etwas trennschärfer ein, sodass es zu Empfangsproblemen kommen kann. Können Signale eines FHT nicht empfangen werden, kann es sinnvoll sein, probeweise die Frequenz des CUL zu ändern (in 0,05 Mhz Schritten), oder die Bandbreite des CUL/CUN zu erhöhen.
* Der äußerlich gleich aussehende [[FHT8]] ist nicht mit einer Zentrale/FHEM einsetzbar.
* In seltenen Fällen fehlerhafte Aktuator Meldungen, siehe [[Lime-Protection Bug]]
* Das Gerät ist vergleichbar mit [[FHT80b]], kann jedoch im Gegensatz zu diesem keine [[FHT80TF|Fensterkontakte]] einbinden.

== Links ==

[[Kategorie:FHT Components]]
[[Kategorie:Heizungssteuerung]]

FHT80TF-2

2016-11-20T18:27:28Z

Krokofant: Abgekündigt

{{Infobox Hardware
|Bild=FHT80TF.jpg
|Bildbeschreibung=Tür-/ Fensterkontakt, kleine Bauform
|HWProtocol=FHT
|HWType=Sensor
|HWCategory=FHT
|HWComm=868 MHz
|HWChannels=1
|HWVoltage=3V
|HWPowerConsumption=Batterielaufzeit bis zu 5 Jahre
|HWPoweredBy=2xLR03 (AAA)
|HWSize=25x117x17 mm (Sensor) 11x48x12 mm (Magnet)
|HWDeviceFHEM=[[CUL_FHTTK|09_CUL_FHTTK.pm]]
|HWManufacturer=ELV
}}

Der '''FHT80TF Tür-/Fensterkontakt''', ein Zubehörteil zum [[FHT80b]] Raumregler, dient zur Erkennung einer offenen Tür, eines offenen Fensters oder ähnlicher Meldesituationen. Das Geräte existiert in zwei Bauformen, dem älteren und deutlich grösseren FHT80TF und dem kleineren FHT80TF-2 (Bild). Die Geräte sind funktional identisch.

'''Achtung: Dieses Gerät ist abgekündigt (wird nicht mehr hergestellt).'''[https://forum.fhem.de/index.php/topic,60219.0.html]

== Features ==
Mittels des FHT80TF kann überprüft werden, ob eine Tür oder ein Fenster im zu heizenden Raum offen ist. Ist dies der Fall, wird der FHT80b, mit dem der Tür/Fensterkontakt gepairt ist, die Heiztemperatur auf die separat einstellbare "Fenstertemperatur" einregeln. Wird das Fenster (und damit der Kontakt) wieder geschlossen, so regelt der FHT80b wieder auf die aktuell eingestellte Temperatur hoch.

Der FHT80TF besteht aus dem eigentlichen Gehäuse mit Sender und Batteriefach (2x Micro) und einem separaten Magneten, der im geschlossenen Zustand des Fensters oder der Tür einen Reedkontakt im Inneren des Sendergehäuses betätigt. Das FHT80TF Gehäuse hat zwecks wahlfreier Installation einen solchen Kontakt auf beiden Gehäuseseiten, sowie einen Anschluss für externe Kontakte (normally Closed). Es kann nur einer der internen Kontakte verwendet werden, ein interner und externe Kontakte oder nur externe. Alle Kontakte sind in Reihe geschaltet, es ist also keine Einzelauswertung möglich.

== Hinweise zum Betrieb mit FHEM ==
In der Standard FHT/FS20 Umgebung ist die Einsetzbarkeit des FHT80TF eingeschränkt, da er nur vom gepairten FHT80b zwecks Temperaturabsenkung ausgewertet wird.

FHEM kann einen FHT80TF jedoch überdies direkt als Device auswerten, sodass sich damit ähnlich wie beim HMS Device [[HMS 100 TFK]] oder dem FS20 TFK Schließzustände von Türen, Toren und Fenstern direkt auswerten lassen. Voraussetzung ist allerdings ein [[CUL]], CUNO oder COC als [[Interface|Funkschnittstelle / Zentrale]].

Der sechsstellige (hexadezimale) Devicecode des FHT80TF lässt sich nicht ändern und wird während der Produktion eindeutig vergeben. Es wird also kein Hauscode vergeben und der FHT80TF ist auch kein FS20 Sender.
=== Definition ===
Der jeweilige Devicecode kann über das Logfile ermittelt werden. Wird ein neuer Türkontakt erkannt, erscheint im Logfile "FHTTK unknown device 123abc, please define it." (wobei 123abc ein Stellvertreter für den tatsächlichen Devicecode des Fensterkontaktes ist, der dem Logfileeintrag zu entnehmen ist), der Fensterkontakt kann dann mit
:<code>define <name> [[CUL_FHTTK]] <devicecode></code>
definiert werden.

Im Gegensatz zum FS20 TFK wird die Statusänderung des Kontaktes nicht sofort übermittelt. Die Sendung wird nicht durch Öffnen oder Schliessen unmittelbar ausgelöst, vielmehr sendet das Modul in Abständen zwischen um die vier Minuten eine Statusnachricht über den aktuellen Zustand der Kontakte. Mehr dazu unter [[FHT80TF-2#Protokoll|Protokoll]]. Der Einsatz in [[Alarmanlage|Alarmanlagen]] oder ähnlichen Anwendungen ist daher nur eingeschränkt möglich. Vorteilhaft ist jedoch der geringere Preis gegenüber einem FS20 TFK.

=== Anwendungsbeispiel ===
Die Programmierung eines [[notify]] ist unter [[FHTTK: Benachrichtigung bei offenem Fenster]] beschrieben.

Im Wesentlichen ist zu beachten, dass das FHTTK neben dem Fensterzustand (Open oder Closed) auch den Batteriezustand (ok oder Low.Batt) meldet. Ein bedingtes Notify muss also definieren, welcher Wert abgefragt werden soll.

z. B.: <code>define mach_was_bei_Fenster_auf notify myFHTTK:Window:Open ...</code>

== Batterielebensdauer ==
Der Stromverbrauch des Gerätes ist sehr gering. (Gute) Batterien halten bis zu mehrere Jahre. Da in diesen Zeiträumen die Selbstentladung eine ebenso grosse Rolle spielt wie der Stromverbrauch des Gerätes, halten die Batterien um so länger, je '''kälter''' es ist (Selbstentladung sinkt mit der Temperatur deutlich ab). Im Aussenbereich wurden Batterielebensdauern von bis zu acht Jahren beobachtet.

== Bekannte Probleme ==
Keine.

== Sonstiges ==
* Das Gerät arbeitet zuverlässig bis ca. -20 Grad, kann bei entsprechend wasserdichter Anbringung auch im Aussenbereich eingesetzt werden.
* Durch die Möglichkeit, einen eigenen Kontakt an Klemmen im Inneren anzuschliessen, lassen sich auch Lösungen für andere Einsatzzwecke realisieren.
* Da der Tür-/Fensterkontakt von alleine ca. alle vier Minuten seinen Status sendet, lässt er sich auch gut zum Ausmessen der [[SlowRF]] Funklage eines Gebäudes verwenden. Den Tür-/Fensterkontakt im Haus an die zu untersuchenden Stellen legen und mittels FHEM RSSI beobachten. FS20 / FHT etc. arbeitet gut bei RSSI oberhalb -80, mäßig zwischen -80 und -85 und bei RSSI kleiner als -85 unzuverlässig bis gar nicht.

== Protokoll ==

Das benutzte Protokoll der FHT Baugruppen wird auf der Seite von FHZ4Linux [http://fhz4linux.info/tiki-index.php?page=FHT%20protocol FHT Protokoll] beschrieben. Ein FHT80TF-2 sendet in bestimmten Zeitabständen seinen momentanen Status. Dabei kann man in einen Hauptintervall und in einen Statusänderungsintervall unterscheiden. Erst genannter Intervall sendet immer in einem gleichen Abstand von 240 + x Sekunden seinen Status (unten Fett hervorgehoben) und zweit genannter geschieht intern immer in (240 + x) / 4 Sekunden. Sollte nun innerhalb des Hauptintervalls ein Statuswechsel von "on" auf "off" bzw. "Open" auf "Closed" eintreten, wird nach Ablauf von 1x (240 + x) / 4 (Statusänderungsintervall) der neue Status gesendet und noch einmal nach (240 + x) / 4 wiederholt. Danach verfällt der TF-2 wieder in den Hauptintervall, beginnend bei 0. Die Variable x wird aus dem Adressbyte vom Fensterkontakt berechnet, ähnlich dem Intervall für den [[FHT80b#Hinweise_zum_Betrieb_mit_FHEM|FHT8v]]. Es werden nur die 3 niederwertigen Bits verwendet. Beispiel: FHTTF-2 ID 8631'''0A''' -> 0x0A & 0x07 = '''2''' -> (16 - ('''2''' * 2)) = 12 Sekunden. 
 
Formel: 
:x = (16 - (Adressbyte & 0x7) * 2) 
:y = 240 + x
:y == Hauptintervall von 4 min + x
 
{| class="wikitable"
|-
! FHT Code !! HC1 !! HC2 !! Adressbyte !! Adressbyte & 0x7 !! Intervall
|-
| F7 FD 57 || 1111 0111 || 1111 1101 || 0101 0'''111''' || 7 || 4:02
|-
| 83 C0 D7 || 1000 0011 || 1100 0000 || 1101 0'''111''' || 7 || 4:02
|-
| 86 30 0A || 1000 0110 || 0011 0000 || 0000 1'''010''' || 2 || 4:12
|-
| 86 31 0A || 1000 0110 || 0011 0001 || 0000 1'''010''' || 2 || 4:12
|-
| CA 54 01 || 1100 1010 || 0101 0100 || 0000 0'''001''' || 1 || 4:14
|-
| 64 C8 70 || 0110 0100 || 1100 1000 || 0111 0'''000''' || 0 || 4:16
|}
 
<code>
2013-10-07_21:17:15 Fenster Window: off 
2013-10-07_21:21:17 Fenster Window: on 
2013-10-07_21:22:17 Fenster Window: on 
2013-10-07_21:26:19 Fenster Window: on 
2013-10-07_21:30:21 Fenster Window: on 
'''2013-10-07_21:34:23 Fenster Window: on''' 
'''2013-10-07_21:38:25 Fenster Window: on''' 
2013-10-07_21:50:32 Fenster Window: on 
2013-10-07_21:54:34 Fenster Window: off 
2013-10-07_21:55:34 Fenster Window: off 
2013-10-07_21:59:36 Fenster Window: off 
2013-10-07_22:03:38 Fenster Window: off 
2013-10-07_22:06:40 Fenster Window: on 
2013-10-07_22:07:40 Fenster Window: on 
2013-10-07_22:08:41 Fenster Window: off 
2013-10-07_22:09:41 Fenster Window: off 
2013-10-07_22:13:43 Fenster Window: off 
</code>
 
Ergänzung zur Synchronisierung:

Der Synchronisierungsprozess mit einem FHT 80 Regler wird mit einer Nachricht 0x0C (Befehlsbyte) begonnen und einem folgenden 0x0F (Befehlsbyte) abgeschlossen. Erst dann ist der TF am FHT angemeldet.

== Links ==
* Bedienungsanleitung (PDF {{DocLink|elv|/service/manuals/84919_FHT80TF_2_UM.pdf}})
* {{Link2Forum|Topic=27465|LinkText=Diskussionsthread}} dazu

[[Kategorie:FHT Components]]
[[Kategorie:Kontaktsensor (magnetisch)]]

FHT8

2016-11-20T18:26:47Z

Krokofant: Abgekündigt

FHT8 ist ein programmierbarer Raumthermostat, der bis zu 8 Stellantriebe [[FHT8v]] steuern kann. Im Gegensatz zu den optisch gleich aussehenden [[FHT80b]] oder [[FHT8b]] ist jedoch keine Kommunikation mit einer Zentrale möglich, der FHT8 ist ein standalone Gerät.

'''Achtung: Dieses Gerät ist abgekündigt (wird nicht mehr hergestellt).'''[https://forum.fhem.de/index.php/topic,60219.0.html]

==Features==
Lokal programmierbare Tages- und Nachttemperatur, die pro Tag mit 4 Schaltpunkten programmiert werden kann.

==Hinweise zum Betrieb mit FHEM==
NICHT einsetzbar

==Bekannte Probleme==
Sieht so aus wie ein FHT80b, geht aber trotzdem nicht mit FHEM, es handelt sich um ein standalone Gerät. Daher auch keine Steuerung durch andere Zentralen wie [[FHZ 1000]]. Bitte auch beim Kauf baugleich aussehender Regler von Drittanbietern (z.B.: FTS 800 C oder Reichelt FHS Set 1 / FHT8r) darauf achten, dass diese oft anders bedruckte FHT8 und daher nicht mit FHEM steuerbar sind.

[[Datei:FTS800C-2.jpg|200px|thumb|right|FTS800C-2]]

[[Datei:FTS800C-2_back.jpg|200px|thumb|right|FTS800C-2 Rückseite]]

[[Kategorie:FHT Components]]
[[Kategorie:Heizungssteuerung]]

FHT80b

2016-11-20T18:25:50Z

Krokofant: Abgekündigt

{{Infobox Hardware
|Bild=PlatzHalter.png
|Bildbeschreibung=FHT80b
|HWProtocol=FHT
|HWType=Empfänger
|HWCategory=FHT
|HWComm=868,35 MHz
|HWChannels=1
|HWVoltage=3 V
|HWPowerConsumption=(ca. 2 Jahre)
|HWPoweredBy=2x AA
|HWSize=100 x 60 x 60 mm
|HWDeviceFHEM=11_FHT8V.pm
|HWManufacturer=ELV / eQ-3}}

Der [[FHT80b]] ist ein programmierbarer Raumthermostat, der bis zu 8 Stellantriebe [[FHT8v]] steuern kann.

'''Achtung: Dieses Gerät ist abgekündigt (wird nicht mehr hergestellt).'''[https://forum.fhem.de/index.php/topic,60219.0.html]

== Features ==
Lokal programmierbare Tages- und Nachttemperatur, die pro Tag mit 4 Schaltpunkten programmiert werden kann.
Zusätzliche Anbindung eines Tür/Fensterkontaktes [[FHT80TF]] zur Absenkung der Temperatur auf separat einstellbaren Wert bei offenem Fenster (windowopen-temp).

== Readings ==
{| class="wikitable"
! Parameter
! Wertbeispiel
! Erklärung
|-
| actuator
| 0%
| Position des Stellantriebes in %
|-
| battery
| ok low
| Ladezustand der Batterien
|-
| mode
| auto manual holiday_short 
| Funktionsmodus (auto, manuell oder Urlaub/Party)
|-
| state
| measured-temp: 20.9
| Ist-Temperatur in ° (C oder F in FHT80B wählbar)
|-
| desired-temp
| 21.0
| Solltemperatur in ° (C oder F in FHT80B wählbar)
|-
| holiday1
| 126
| Endzeit der Urlraubs-/Partyfunktion. Uhrzeit in Minuten seit 00:00 geteilt 10 (im Beispiel 21:00 Uhr)
|-
| holiday2
| 31
| Tag im Monat an der die Urlaubs-/Partyfunktion endet
|-
| lowtemp
| ok warn
| Untertemperatur-Alarm: Im Raum wird der Temperatur-Sollwert nicht erreicht
|-
| manu-temp
|
| Solltemperatur bei Manuell-Modus
|-
| night-temp
|
| Solltemperatur bei Absenkung
|-
| warnings
| none Battery low Temperature too low Fault on window sensor
| Auflistung der Fehler
|-
| window
| closed open
| Statusmeldungen vom FHT80-TF
|-
| windowsensor
| ok fault
| fault, wenn ein angemeldeter Fenstermelder nicht erreicht werden kann.
|-
| windowopentemp
| 9.0
| Solltemperatur bei offenem Fenster
|-
| year 
month 
day 
hour 
minute
|
| Zeitangaben für interne Uhr
|-
| mon-from1 
mon-from2 
mon-to1 
mon-to2 
tue-from1 
tue-from2 
tue-to1 
tue-to2 
wed-from1 
wed-from2 
wed-to1 
wed-to2 
thu-from1 
thu-from2 
thu-to1 
thu-to2 
fri-from1 
fri-from2 
fri-to1 
fri-to2 
sat-from1 
sat-from2 
sat-to1 
sat-to2 
sun-from1 
sun-from2 
sun-to1 
sun-to2
| 06:00
| Angabe von Schaltzeiten im Format HH:MM
|}

== Hinweise zum Betrieb mit FHEM ==
Vor dem Einsatz muss der FHT80b mit der Zentrale (z.B. CUL) gepairt werden. Geschieht dies nicht, können nach einer Definition in FHEM zwar Daten des FHT80b empfangen werden (z. B. Raumtemperatur), es können jedoch keine Befehle gesendet werden. Zum pairen den FHT80b in Sonderfunktionen "cENT" auf "n/a" stellen, danach sofort einen Befehl (egal welchen) an die FHT80b senden. Wenn ca. zwei Minuten später Sonderfunktion cENT auf "ON" steht, war das Pairing erfolgreich.

Weitere Hinweise: [[FHT mit RFR CUL pairen]]

Ausserdem muss das FHT per Hand oder Autocreate angelegt werden. Die Adresse des FHT wird beim Anlegen mit Autocreate in Fhem hexadezimal angegeben, im Gerät jedoch dezimal. Dabei muss die Adresse paarweise umgerechnet werden. Beispiel: Fhem habe ein FHT mit der Adresse 162c angelegt. Dies entspricht dann
hex 16 = 22 dez
hex 2c = 44 dez
dem FHT mit der am FHT eingestellten Adresse 2244.
Genauso gut kann man aber auch eine am FHT eingestellt Adresse nach der selben paarweisen Methode in hex umrechnen und in Fhem das FHT dann per Hand anlegen.

Das FHT80b akzeptiert Befehle vom FHZ1X00 (oder CUL/CUN) nur alle 115+x Sekunden (x = 0.5*letztes Byte des FHT-Hauscodes (auch ''FHT-ID'' genannt), Beispiel: FHT-ID 1234, Sendeintervall = 115+0,5*4 = 117 Sekunden)
Praktisch ergeben sich so ca. zwei Minuten.
Wenn man also mit FHEM z.B. fünf desired-temp Wechsel sendet, so wird es selbst unter optimalen Bedingungen 9-10 Minuten dauern, bis der letzte ausgeführt wird.

Dies muss insbesondere beim Debuggen von Automationszenarien berücksichtigt werden. Nicht absetzbare Kommandos werden im einem Puffer der FHZ1x00/CUL/CUN gespeichert, obwohl sie im FHEM Log als abgesetzt erscheinen. Bei größeren Installationen kann auch der Puffer überlaufen ([[EOB]] Fehlermeldung im FHEM Log). Die Puffer sind unterschiedlich gross. Am kleinsten ist er bei den FHZ1x00 mit ca. 40 Byte, was für ca. acht FHT Befehle reicht. Am grössten ist er im CULv3 oder CUN mit 200 Bytes, das reicht für ca. 40 Befehle.

Bei zu kleinem Puffer bietet FHEM die Möglichkeit, einen Softpuffer (fhtsoftbuffer) zu konfigurieren (dieser wirkt jedoch nur bei FHZ1X00PC Zentralen). Insgesamt ist fhtsoftbuffer nur dann sinnvoll einsetzbar, wenn die Funklage an sich gut ist und der Puffer zügig abgearbeitet wird. Softbuffer sollte '''nicht''' eingesetzt werden, wenn die Übertragung der FHT Befehle gestört ist, da sich dann schnell sehr lange Befehlsketten im Puffer aufbauen können, deren Abarbeitung sehr viel Zeit in Anspruch nehmen kann. Dies kann dazu führen, dass Kommandos an FHTs erst Stunden später ausgeführt werden.

Um mehr Befehle an ein FHT80b senden zu können, können bis zu 8 Befehle zusammengefasst werden, diese belegen dann nur einen "Zeitslot"

Beispiele:
:<code>set heizung_wohn desired-temp 20.5 day-temp 19.0 night-temp 16.0</code>

:<code>set hzg_WC mon-from1 07:00 mon-to1 10:00 mon-from2 14:00 mon-to2 23:00</code>

Die Kommunikation des FHT80b mit den Stellantrieben und dem Türkontakt erfolgt ebenso in Zeitabständen von ca. zwei Minuten. In den Pausen sind die Sender und Empfänger von FHT80b und FHT8v abgeschaltet, um Batteriestrom zu sparen.

Die Übermittlung der aktuellen Temperaturdaten an die Zentrale (FHZ, [[CUN]]) erfolgt alle 15 Minuten.

Die Kommunikation mit der Zentrale ist bidirektional, d.h. die Funkzentrale sendet auch Daten an die FHT80b zurück (insbesondere Acknowledge Meldungen etc). Dies führt dazu, dass im Zusammenhang mit der Sendzeitbegrenzung die Anzahl der [[Maximal nutzbare Geräte|maximal nutzbaren Geräte]] begrenzt ist. Theoretisch lassen sich bis zu 17, in der Praxis eher nur ca. 10 FHT80b sinnvoll mit einer Zentrale steuern.

== Verschiedene Betriebsarten mit FHEM ==
Da das FHT80 selbst ein Heizprogramm speichern und daher eigentlich auch autark arbeiten kann, stellt sich die Frage, wie FHT80 am Besten in Fhem integriert werden sollte. Es gibt dazu drei wesentliche Szenarien:

* das FHT80 heizt nur über seine eigenen Heizprogramme, steht also im Automatik Modus. Diese werden jedoch nicht umständlich am FHT80 selber einprogramiert sondern über Fhem gesetzt. Auch alle gewünschten Änderungen werden über eine Anpassung der im FHT gespeicherten Programme und setzen von day-temp und night-temp realisiert. Vorteil: Volle Funktionalität auch ohne Fhem, daher ausfallsicher. Nachteil: Änderungen erzeugen hohe Funklast, da ganze Wochenprogramme übertragen werden müssen. Führt bei mehr als fünf bis sechs FHTs idR. zu [[EOB]] und [[LOVF]] Problemen. Ausserdem: Beschränkung auf die FHT80 typisch geringe Zahl von Schaltpunkten (vier pro Tag), mehrstufige Temperaturänderungen sind umständlich. Abhängigkeiten in Fhem (Anwesenheitskontrolle, Bedingungen wie Nutzungserkennung durch Bewegungssensoren etc.) sind schwerer umsetzbar.

* das FHT80 heizt über seine eigenen Heizprogramme, steht also im Automatik Modus. Zusätzlich sendet Fhem Z.B. desired-temp Meldungen und greift so in das Heizprofil ein. Vorteil: Grundfunktionalität auch ohne Fhem, daher ausfallsicher: Das Wochenprogramm des FHT80 wird als Grundprogramm und Fallback genutzt. Zusätzliche Heizpunkte oder höhere/niedrigere Temperaturen werden durch Fhem gesteuert. Geringere Funklast, sofern das Grundprogramm selten geändert wird. Beliebige Schaltpunkte, beliebige Temperaturänderungen leicht einstellbar. Nachteil: Komplex. Das Heizverhalten hängt sowohl vom lokalen Programm im FHT80 ab, als auch von Kommandos die Fhem sendet. Das macht die Steuerung unübersichtlich. Problematisch ist insbesondere, wenn lokale Schaltpunkte kurz vorher gesendete Fhem Kommandos negieren. Dies mach z.b. das Herunterfahren der Heizung bei ungeplanter Abwesenheit schwierig.

* das FHT80 wird in den manuellen Mode geschaltet und nur über Fhem mittels desired-temp Kommandos gesteuert. Vorteil: Da Fhem volle Kontrolle hat, einfache Umsetzung von Abhängigkeiten (Anwesenheitskontrolle, Bedingungen wie Nutzungserkennung durch Bewegungssensoren etc.). Beliebige Schaltpunkte, beliebige Temperaturänderungen leicht einstellbar. Unkomplex: Temperatur hängt nur vom letzt-gesendeten desired-temp Kommando ab. Nachteil: Bei Ausfall von Fhem wird das FHT80 quasi funktionslos und hält nur die letzte eingestellt Temperatur. Es könnten allerdings im FHT gespeicherte Heizprogramme durch manuelles Umschalten am FHT80 auf den Automatikmodus (Tastendruck) aktiviert werden.

Da das FHT80 auch per Fhem-Befehl zwischen manuellem und automatischem Modus umgestellt werden kann, sind auch Mischformen speziell zwischen den letzten beiden Varianten einsetzbar. Dies wird z.b. im Code Snippet [[FHT80b Automatik setzen]] genutzt.

== Log-Auszug ==
FHT80b sendet ca alle zwei Minuten Steuerbefehle an ggf. angeschlossene Ventilstellantriebe. Der einzustellende Wert liegt zwischen 0% und 100% und wird von FHT80b auf Basis der am Gerät eingestellten Solltemperatur und der vom Gerät gemessenen Ist-Temperatur berechnet:

FHT <device-name> actuator: 0%

Ausserdem sendet FHT80b ca 4 mal pro Stunde folgenden Statusbericht:

FHT <device-name> actuator: 0%
FHT <device-name> measured-temp: 23.1 (Celsius)
FHT <device-name> battery: ok
FHT <device-name> lowtemp: ok
FHT <device-name> window: closed
FHT <device-name> windowsensor: ok
FHT <device-name> warnings: none

Die dazu nötige bidirektionale Kommunikation kann mit FHEM
mitprotokolliert werden ("set CUL raw X61" vorher nicht vergessen). Hier ein
beispielhafter Mitschnitt:

2008-09-28 13:04:18 FHT wz actuator: 0%
2008-09-28 13:04:18 FHT wz actuator: 0%
2008-09-28 13:04:18 FHT wz start-xmit: 17
2008-09-28 13:04:18 FHT wz FHZ:start-xmit: 17
2008-09-28 13:04:19 FHT wz measured-low: 21.9 (Celsius)
2008-09-28 13:04:19 FHT wz FHZ:measured-low: 21.9 (Celsius)
2008-09-28 13:04:19 FHT wz measured-high: 0
2008-09-28 13:04:19 FHT wz FHZ:measured-high: 0
2008-09-28 13:04:19 FHT wz ack: 0
2008-09-28 13:04:20 FHT wz FHZ:ack: 0
2008-09-28 13:04:20 FHT wz warnings: none
2008-09-28 13:04:20 FHT wz FHZ:warnings: none
2008-09-28 13:04:20 FHT wz ack: 0
2008-09-28 13:04:20 FHT wz FHZ:ack: 0
2008-09-28 13:04:20 FHT wz end-xmit: 0
2008-09-28 13:04:20 FHT wz FHZ:end-xmit: 0

Jede Zeile steht für ein Telegramm (und nicht für 3, wie beim FS20).

FHZ:xxx Telegramme wurden von der FHZ (oder CUN/CUL) gesendet, die anderen vom FHT.

Fhem fasst measured-low und measured-high zu measured-temp zusammen, es werden also im normalen log (telnet: inform timer) zwei Zeilen weniger gemeldet.

17 ist der Hauscode der protokollierten FHZ. Wenn die FHZ nicht mit dem richtigen Hauscode antwortet, dann geht die Kommunikation nicht weiter.

Wenn das FHT nicht an der FHZ angemeldet ist (d.h., das FHT hat nicht den Hauscode des FHZ gespeichert), werden keine Temperaturdaten uebermittelt. Set Prog:Cent:N/A setzt den FHT Hauscode auf 100, dann sollte jede FHZ auf "start-xmit" antworten, und das FHT merkt den ersten. Noch besser ist es, dem FHT via fhem etwas zu senden, dann muss nicht auf die nächste Temperaturmeldung (bis zu 15 Minuten) gewartet werden.

Mehr dazu auch hier: [[FHT mit RFR CUL pairen]]

Falls die Gegenseite nicht wie erwartet antwortet, wird nach einem Timeout das Telegramm einmal wiederholt. Falls immer noch keine korrekte Antwort vorliegt, wird nach 115+x Sekunden der ganze Vorgang einmal wiederholt.

Durch diese recht umfangreiche Kommunikation entsteht im Zusammenhang mit der Sendezeitbeschränkung die maximale Anzahl nutzbarer Geräte von ca. einem Dutzend.

== Bekannte Probleme ==
* Es gibt zwei weitere, gleich aussehende Geräte mit geringerem Funktionsumfang. Der [[FHT8b]] hat keine Verbindung zu Fensterkontakten. Der [[FHT8]] hat keinen bidirektionalen Funk und kann nicht mit einer Zentrale/FHEM verbunden werden.
* Die Sendefrequenzen einiger FHT80b sind nicht besonders genau auf den eigentlichen Wert von 868,35 MHz justiert und streuen bei verschiedenen Geräten. Die FHZ 1x00PC Geräte sind gegenüber leichten Abweichungen der Frequenz durch eine etwas höhere Empfangsbandbreite eher unempfindlich. Die [[CUL]] oder [[CUNO]] halten die eingestellte Frequenz dagegen trennschärfer ein, sodass es zu Empfangsproblemen kommen kann. Können Signale eines FHT nicht empfangen werden, kann es sinnvoll sein, probeweise die Frequenz des CUL zu ändern (in 0,05 MHz Schritten), oder die Bandbreite aufzuweiten, z.b. auf 464 KHz.
* In seltenen Fällen fehlerhafte Aktuator Meldungen, siehe [[Lime-Protection Bug]]
* FHTs hören in der Regel nach 5-10 Tagen auf, von sich aus Daten zur Zentrale zu senden, wenn sonst keine Kommunikation mit dem FHT stattfindet. Ein regelmässiges z.b. wöchentliches Stellen der Uhrzeit oder wöchentliches Abfragen der wichtigsten Parameter (report2 = 255) vorteilhaft zu eher "funklastarmen" Zeiten schafft Abhilfe; z.B.: <code>define fht_reportZimmer1 at *04:00:00 {if ($wday == 1) { fhem("set hzg_Zimmer1 report2 255") } }</code>
* Die o.g. Situation bringt häufig auch die Actuator-Meldung "'''unknown_69'''" mit sich. Eine Beschreibung zur Behebung findet sich in [https://groups.google.com/d/msg/fhem-users/aft8E1LrsDE/8D-TsMrYY5wJ diesem Forums-post] .
* Der Betrieb von FHTs mit einen [[RFR CUL]] kann zu besonderen Problemen führen, siehe [[RFR CUL und FHT80]]

== Links ==
* Anleitung [http://www.eq-3.de/Downloads/eq3/downloads_produktkatalog/andere_produkte_bda/FHT80B_UM_G_080812.pdf hier (eQ-3)] oder {{DocLink|elv|/Assets/Produkte/8/856/85643/Downloads/85643_FHT80B_UM.pdf hier (ELV)}} als PDF
* Baugleich auch als Set ('''FHT80b''', [[FHT80TF]]) von Medion (bei Aldi oder ebay): [http://www.discounter-archiv.de/de/archiv/ALDI-Nord/2011-01-06/Automatische-Funk-Heizkoerpersteuerung/692135/ Lifetec MD12050]
* [[Kommunikationsprobleme mit FHT]]
* [[Was ist der Hauscode?]]

Eine Reihe von Code Snippets zum Thema FHT80b:
* [[FHT80b Einstellungen]]
* [[FHT80b Automatik setzen]]
* [[FHT: Datum und Zeit von fhem setzen lassen]]

[[Kategorie:FHT Components]] [[Kategorie:Heizungssteuerung]]

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

2016-11-19T05:14:43Z

Krokofant: /* Betrieb mit FHEM */ Das Wörtchen "natürlich" gestrichen, da die Reihenfolge z.B. beim Vorgänger genau umgekehrt beschrieben ist

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

Diskussion:FlammEx Rauchmelder

2016-11-19T05:02:09Z

Krokofant: Die Seite wurde neu angelegt: „ == Kategorie Homematic Components == Ich finde das problematisch, weil ja hier "nur" ein Fensterkontakt als Ergänzung verwendet wird. Das könnte man ja auc…“

== Kategorie Homematic Components ==

Ich finde das problematisch, weil ja hier "nur" ein Fensterkontakt als Ergänzung verwendet wird. Das könnte man ja auch mit einem anderen System wie FS20 tun. So oder so macht das den Rauchmelder selbst nicht zum systembestandteil Homematic.

Wenn sich hier kein Widerspruch regt, werde ich den Artikel demnächst hier herausnehmen und im Artikel des Fenstermelders einen Verweis hierher unterbringen. --[[Benutzer:Krokofant|Krokofant]] ([[Benutzer Diskussion:Krokofant|Diskussion]]) 06:02, 19. Nov. 2016 (CET)

FHT8

2016-11-10T08:52:06Z

Krokofant: +Kat

FHT8 ist ein programmierbarer Raumthermostat, der bis zu 8 Stellantriebe [[FHT8v]] steuern kann. Im Gegensatz zu den optisch gleich aussehenden [[FHT80b]] oder [[FHT8b]] ist jedoch keine Kommunikation mit einer Zentrale möglich, der FHT8 ist ein standalone Gerät.

==Features==
Lokal programmierbare Tages- und Nachttemperatur, die pro Tag mit 4 Schaltpunkten programmiert werden kann.

==Hinweise zum Betrieb mit FHEM==
NICHT einsetzbar

==Bekannte Probleme==
Sieht so aus wie ein FHT80b, geht aber trotzdem nicht mit FHEM, es handelt sich um ein standalone Gerät. Daher auch keine Steuerung durch andere Zentralen wie [[FHZ 1000]]. Bitte auch beim Kauf baugleich aussehender Regler von Drittanbietern (z.B.: FTS 800 C oder Reichelt FHS Set 1 / FHT8r) darauf achten, dass diese oft anders bedruckte FHT8 und daher nicht mit FHEM steuerbar sind.

[[Datei:FTS800C-2.jpg|200px|thumb|right|FTS800C-2]]

[[Datei:FTS800C-2_back.jpg|200px|thumb|right|FTS800C-2 Rückseite]]

[[Kategorie:FHT Components]]
[[Kategorie:Heizungssteuerung]]