FHEMWiki - Benutzerbeiträge [de]

SiSi

2019-02-13T08:24:01Z

Michael: /* Einrichten der Kommunikation über D-Bus */

{{Infobox Modul
|ModPurpose=Senden und Empfangen von Nachrichten (Text und Fotos) mit dem freien Messenger Signal
|ModType=x
|ModForumArea=Codeschnipsel
|ModFTopic=84996
|ModTechName=32_SiSi.pm
|ModOwner=Quantum ({{Link2FU|35410|Forum}})}}
Das Modul [[SiSi]] ermöglicht den Versand von Nachrichten über den Instant-Messaging-Dienst [https://signal.org Signal] aus FHEM heraus.

Um dies zu ermöglichen, sind mehrere Schritte notwendig:
#Installation des [https://github.com/AsamK/signal-cli Signal Messenger Command Line Interface (signal-cli)].
#Registrierung einer Rufnummer bei Signal
#Einrichtung der [https://de.wikipedia.org/wiki/D-Bus D-Bus]-Schnittstelle
#Inbetriebnahme des FHEM-Moduls

Diese Anleitung geht davon aus, dass
*als Betriebssystem Debian oder Raspbian verwendet wird
*FHEM im Verzeichnis ''/opt/fhem'' installiert wurde (ansonsten müssen die Pfade in der Anleitung angepasst werden)

Alle in dieser Anleitung vorkommenden Textstellen in spitzen Klammern (z.B. <ErsetzMich>) sind durch eigene Werte zu ersetzen, sofern es sich nicht um Auszüge aus Konfigurationsdateien handelt.

==Voraussetzungen==
Um sowohl das ''signal-cli'' als auch das Modul verwenden zu können, müssen bestimmmte Linux-Pakete installiert sein. Im Folgenden eine Liste der Pakete für Debian/Raspbian:
*'''''libunixsocket-java'''''
*'''''dbus'''''
*'''''libnet-dbus-perl'''''
*'''''haveged''''' (Dient dazu, genügend Entropie für den Zufallszahlengenerator zu erzeugen.)
*'''''openjdk-9-jre-headless''''' (Es sollte eine Version > 7 installiert werden. Welche genau, hängt von Betriebssystem und dem Installationszeitpunkt ab.)

Optional kann noch das Paket '''''shared-mime-info''''' installiert werden wenn ein gesendeter Anhang nicht direkt im Chatverlauf angezeigt werden soll, sondern erst durch einen Klick auf das Datei-Icon.

Installation der Pakete in einem Rutsch:
sudo apt-get update
sudo apt-get install libunixsocket-java dbus libnet-dbus-perl shared-mime-info haveged openjdk-9-jre-headless

==Installation des signal-cli==
[https://github.com/AsamK/signal-cli signal-cli] ist ein Kommandozeilen-Interface für [https://github.com/signalapp/libsignal-service-java libsignal-service-java]<ref>libsignal-service-java ist eine Java/Android Bibliothek zur Kommunikation mit dem Signal Messaging Service</ref>. Es unterstützt das Registrieren und Verifizieren einer Rufnummer sowie das Senden und Empfangen von Nachrichten.

Der erste Schritt zur Installation von ''signal-cli'' ist, die aktuellste Versionsnummer auf der GitHub-Seite des Projektes unter "[https://github.com/AsamK/signal-cli/releases Releases]" zu finden. Zum Zeitpunkt der Erstfassung dieser Anleitung war das die Version 0.6.0.

Anschließend wird die Release heruntergeladen und als Benutzer '''''fhem''''' in den Wurzelordner von FHEM (z.B. ''/opt/fhem'') entpackt.
<source lang="text">
export VERSION=0.6.0
wget https://github.com/AsamK/signal-cli/releases/download/v"${VERSION}"/signal-cli-"${VERSION}".tar.gz
sudo -u fhem tar xf signal-cli-"${VERSION}".tar.gz -C /opt/fhem
</source>

Zur einfacheren Handhabung kann der neu erstellte Ordner umbenannt und ein symbolischer Link in ''/usr/local/bin/'' erstellt werden.
<source lang="text">
sudo mv /opt/fhem/signal-cli-"${VERSION}" /opt/fhem/signal-cli
sudo ln -sf /opt/fhem/signal-cli/bin/signal-cli /usr/local/bin/
</source>

==Registrierung einer Rufnummer==
Um Signal nutzen zu können, ist eine Rufnummer zwingend erforderlich. Für diesen Fall empfiehlt es sich, eine Nummer zu verwenden, die nicht schon für die Kommunikation mit Signal verwendet wird. Zum Beispiel eine Festnetznummer.

Die Registrierung einer Nummer läuft wie folgt ab:
#Registrierung der Nummer mittels ''signal-cli''
#Erhalt einer Textnachricht mit dem Verifizierungscode an angegebene Nummer. Wenn an der Rufnummer keine Textnachrichten empfangen werden können, kann - wie in diesem Beispiel - mit dem Parameter ''--voice'' ein Sprachanruf erzwungen werden. In beiden Fällen kann es durchaus etwas länger dauern, bis man den Verifizierungscode erhält.
#Verifizierung der Nummer mittels ''signal-cli''

{{Hinweis|Alle der folgenden Befehle werden als Benutzer '''''fhem''''' ausgeführt, damit die Konfigurationsdateien im Home-Verzeichnis des Benutzers (z.B. ''<FHEM-Root>/.config/signal'') landen.}}

Im ersten Schritt registriert man eine Nummer mittels ''signal-cli''.
<source lang="text">sudo -u fhem signal-cli -u <Telefonnummer> register --voice</source>
Wenn alles in Ordnung ist, erhält man keine Rückmeldung. Wenn es lange dauert, hat man nicht genug Entropie.
Kurz darauf erhält man einen Sprachanruf auf Englisch, mit dem einem der sechsstellige Verifizierungscode yyyyyy mitgeteilt wird.

Im zweiten Schritt wird diese Nummer mit Hilfe des erhaltenen Codes verifiziert.
<source lang="text">sudo -u fhem signal-cli -u <Telefonnummer> verify <VerificationCode></source>
Auch hier gibt es keine Rückmeldung, solange alles funktioniert hat.

War die Registrierung erfolgreich, können nun Nachrichten via ''signal-cli'' versendet werden:
<source lang="text">signal-cli -u <RegistrierteNummer> send -m "Greetings from FHEM!" <Empfängernummer></source>

== Einrichten der Kommunikation über D-Bus ==
Damit das FHEM-Modul über die D-Bus Schnittstelle mit ''signal-cli'' kommunizieren kann, ist die Einrichtung von D-Bus sowie die Erstellung eines [https://de.wikipedia.org/wiki/Systemd systemd]-Scripts notwendig.

{{Hinweis|Alle der folgenden drei Dateien müssen als Benutzer '''''root''''' angelegt und editiert werden.}}

;/etc/dbus-1/system.d/org.asamk.Signal.conf
Die Datei in einem Editor öffnen
sudo nano /etc/dbus-1/system.d/org.asamk.Signal.conf
und mit folgendem Inhalt befüllen
<source lang="xml">
<?xml version="1.0"?> 
<!DOCTYPE busconfig PUBLIC "-//freedesktop//DTD D-BUS Bus Configuration 1.0//EN"
"http://www.freedesktop.org/standards/dbus/1.0/busconfig.dtd">

<busconfig>
<policy user="fhem">
<allow own="org.asamk.Signal"/>
<allow send_destination="org.asamk.Signal"/>
<allow receive_sender="org.asamk.Signal"/>
</policy>

<policy context="default">
<allow send_destination="org.asamk.Signal"/>
<allow receive_sender="org.asamk.Signal"/>
</policy>
</busconfig>
</source>

;/usr/share/dbus-1/system-services/org.asamk.Signal.service
Die Datei in einem Editor öffnen
sudo nano /usr/share/dbus-1/system-services/org.asamk.Signal.service
und mit folgendem Inhalt befüllen
<source lang="ini">
[D-BUS Service]
Name=org.asamk.Signal
Exec=/bin/false
SystemdService=dbus-org.asamk.Signal.service
</source>

;/etc/systemd/system/signal.service
Die Datei in einem Editor öffnen
sudo nano /etc/systemd/system/signal.service
und mit folgendem Inhalt befüllen.
Achtung! Die Rufnummer im Script muss durch die in den vorigen Schritten registrierte ersetzt werden. Außerdem muss unter Umständen der Pfad des FHEM-Wurzelverzeichnisses angepasst werden.
<source lang="ini">
[Unit]
Description=Send secure messages to Signal clients
Requires=dbus.socket
After=dbus.socket
Wants=network-online.target
After=network-online.target

[Service]
Type=dbus
Environment="SIGNAL_CLI_OPTS=-Xms2m"
ExecStart=/opt/fhem/signal-cli/bin/signal-cli -u +49xxxxxxxxxxx --config /opt/fhem/.local/share/signal-cli daemon --system
User=fhem
BusName=org.asamk.Signal

[Install]
Alias=dbus-org.asamk.Signal.service
</source>

Sind alle Dateien angelegt, können die Services mit diesen Befehlen aktiviert und gestartet werden.
<source lang="text">
sudo systemctl daemon-reload
sudo systemctl reload dbus.service
sudo systemctl enable signal.service
sudo systemctl start signal.service
</source>

Ob alles funktioniert, kann wie folgt getestet werden:
*D-Bus:
sudo -u fhem dbus-send --system --type=method_call --print-reply --dest="org.asamk.Signal" /org/asamk/Signal org.asamk.Signal.sendMessage string:<Nachricht> array:string: string:<EmpfängerNummer>
*signal-cli über D-Bus:
signal-cli --dbus-system send -m "<Nachricht>" <EmpfängerNummer>

== Einbindung des FHEM-Moduls ==
Solange das Modul '''32_SiSi.pm''' noch nicht via FHEM-Update verteilt wird, ist eine manuelle Installation notwendig. Das geschieht, in dem es von der [https://github.com/Quantum1337/32_SiSi.pm GitHub-Seite] des Modul-Autors heruntergeladen und in den FHEM-Ordner kopiert wird.

Der Befehl
wget https://raw.githubusercontent.com/Quantum1337/32_SiSi.pm/master/FHEM/32_SiSi.pm
speichert das Modul im aktuellen Verzeichnis.

Mit den folgenden Befehlen wird das Modul ins das FHEM-Verzeichnis verschoben und anschließend die Datei-Rechte angepasst.
sudo mv 32_SiSi.pm /opt/fhem/FHEM/
sudo chown fhem:dialout /opt/fhem/FHEM/32_SiSi.pm

Anschließend wird noch die lokale CommandRef aktualisiert:
cd /opt/fhem
sudo /usr/bin/perl contrib/commandref_join.pl

Zum Abschluss wird das Modul noch FHEM bekannt gemacht. Dazu in der FHEM-Kommandozeile folgenden Befehl eingeben:
reload 32_SiSi.pm

==Verwendung des FHEM-Moduls==
Die genaue Verwendung des Moduls 32_SiSi.pm ist in der CommandRef beschrieben. Hier deshalb nur ein kleines Beispiel.

SiSi-Device definieren:
define Signal SiSi

Dem Device mitteilen, dass es eine Verbindung zum signal-cli D-Bus Service herstellen soll:
attr sisi enable yes

Eine Standard-Empfängernummer definieren, falls im Befehlsaufruf keine angegeben ist:
attr sisi defaultPeer +49170zzzzzzzz

Anschließend kann aus FHEM heraus eine Nachricht gesendet werden:
set Signal msg Hurra, es funktioniert!

===Zusammenspiel mit den Modulen Msg und Roommate===
Um mithilfe des Moduls [[Msg]] Signal-Nachrichten versenden zu können, ist im Device ''globalMsg'' das Attribut '''msgCmdPush''' zu setzen.
attr globalMsg msgCmdPush set %DEVICE% msg @%RECIPIENT% %MSG%

Optional kann ein Standard-Empfänger gesetzt werden der die Nachricht erhält, wenn beim Aufruf von ''Msg'' kein Empfänger angegeben wurde:
attr globalMsg msgContactPush <Signal-Device>:<Empfängernummer>
Danach kann mit <code>msg Testnachricht</code> eine Signal-Nachricht versendet werden.

Werden {{Link2CmdRef|Anker=ROOMMATE|Lang=de|Label=ROOMMATE-Devices}} verwendet, kann jedem eine Kontaktadresse hinterlegt werden, damit beim Aufruf von ''Msg'' einfach der Device-Name anstatt der Nummer angegeben werden kann. (Funktioniert natürlich bei jedem anderen Device auch. Aber ein ROOMMATE-Device macht das ganze anschaulicher.)
<source lang="text">
attr <ROOMMATE-Device> msgContactPush <Signal-Device>:<Empfängernummer>

z.B.:
attr rr_Max msgContactPush Signal:+49...
</source>
Anschließend kann mit <code>msg @rr_Max Testnachricht</code> eine Nachricht an Max gesendet werden.

==Hinweise==
Derzeit ist es aufgrund von Einschränkungen in der D-Bus-API noch nicht möglich, mit dem SiSi-Modul neue Fingerprints von Kontakten hinzuzufügen oder aus Gruppen auszutreten. Daher muss beides noch manuell auf der Linux-Kommandozeile erfolgen.

;Neuer Fingerprint
:Mit folgendem Befehl wird dieser Nummer wieder vertraut und ''signal-cli'' fügt den geänderten Fingerprint dann automatisch zu seiner Liste hinzu.
:<source lang="text">sudo -u fhem signal-cli -u <FHEM-NUMMER> trust -a <Nummer mit geänderten Fingerprint></source>

;Aus einer Gruppe austreten
:Soll die "FHEM-Signal-Rufnummer" aus einer bestehende Gruppe entfernt werden, kann dieser Aufruf von ''signal-cli'' verwendet werden.
:<source lang="text">sudo -u fhem signal-cli -u <FHEM-NUMMER> quitGroup -g <GroupID></source>

==Querverweise==
<references/>
[[Kategorie:Signal]]

HM-MOD-RPI-PCB HomeMatic Funkmodul für Raspberry Pi

2017-01-07T13:39:57Z

Michael: /* Remoteanbindung - Pi + RPI Modul = LAN Modul */ Autostart auf Debian Jessie (systemd)

{{Infobox Hardware
|Bild=HM-MOD-RPI-PCB.jpg
|Bildbeschreibung=HomeMatic Funkmodul für Raspberry Pi
|HWProtocol=HomeMatic
|HWType=Gateway
|HWCategory=HomeMatic
|HWComm=868,3/869,525 MHz
|HWChannels=n/a
|HWVoltage=1,8–3,6 V DC
|HWPowerConsumption=50 mA max.
|HWPoweredBy=RasPi
|HWSize=19x41x14mm
|HWDeviceFHEM=[[HMUARTLGW]]
|HWManufacturer=ELV / eQ-3
}}

Das [[HM-MOD-RPI-PCB HomeMatic Funkmodul für Raspberry Pi]] ist eine Zusatzplatine, die auf die GPIO-Schnittstelle des [[Raspberry Pi]] aufgesteckt werden und damit als [[Interface]] zu [[HomeMatic]] Geräten dienen kann.

== Features ==
(Noch zu ergänzen)
* ...

== Hinweise zum Betrieb mit FHEM ==
Juni 2016: Beginn der Entwicklung eines FHEM-Moduls (HMUARTLGW) für dieses Interface, beschrieben im Forum unter dem Titel {{Link2Forum|Topic=54511|LinkText=Modul für HomeMatic UART-Modul (RPi) und HomeMatic LAN Gateway}}. Dieses Modul unterstützt gleichzeitig auch das "neue" [[HM-LGW-O-TW-W-EU Funk-LAN Gateway|Funk-LAN Gateway HM-LGW-O-TW-W-EU]].

Juli 2016: [[HMUARTLGW]] wird über FHEM [[update]] verteilt, damit ist dieses Funkmodul offiziell unterstützt.

=== Vorbereitung serielle Schnittstelle unter Jessie===
Diese Beschreibung gilt für Jessie Version 27.05.2016.
Die Grundlagen findet man hier: [[Raspberry Pi 3: GPIO-Port Module und Bluetooth]]

Die Datei /boot/config.txt um diese Zeile ergänzen

<pre>enable_uart=1</pre>

Beim PI 3 zusätzlich diese Zeilen ergänzen

<pre>dtoverlay=pi3-miniuart-bt
core_freq=250</pre>

In der Datei /boot/cmdline.txt diesen Eintrag löschen:
<pre>console=serial0,115200 </pre>

Den Dienst serial-getty deaktivieren

<pre>systemctl disable serial-getty@ttyAMA0.service</pre>

Der Benutzer fhem muss Mitglied in der Gruppe dialout sein!
Beim PI 3 kann man wegen Timingproblemen den Start von FHEM etwas verzögern. Dazu die /etc/init.d/fhem um sleep 10 am Anfang ergänzen.

Das System unbedingt neu starten!

=== Vorbereitung serielle Schnittstelle unter Wheezy===
Diese Beschreibung gilt für Wheezy Version Stand 26.07.2016.

Die Datei /boot/config.txt um diese Zeile ergänzen

<pre>enable_uart=1</pre>

In der Datei /boot/cmdline.txt diesen Eintrag löschen:

<pre>console=ttyAMA0,115200</pre>

Die Datei sollte dann den folgenden Inhalt aufweisen:

<pre>dwc_otg.lpm_enable=0 console=tty1 root=/dev/mmcblk0p2 rootfstype=ext4 elevator=deadline rootwait</pre>

Den Dienst serial-getty deaktivieren

in der Datei /etc/inittab wie folgt die Zeile (ziemlich am Ende) mit einer # auskommentieren

<pre># T0:23:respawn:/sbin/getty -L ttyAMA0 115200 vt100</pre>
Mit folgendem Befehlen überprüfen, dass kein getty auf der Schnittstelle läuft
<pre>ps -A |grep getty
cat /etc/inittab</pre>
{{Randnotiz|RNText=Tipp: Sollte der HM-MOD-RPI-PCB nach der Einrichtung immer wieder den Status zwischen init und disconnect wechseln, alle aufgeführten Punkte erneut kontrollieren! reboot nicht vergessen! In ganz hartnäckigen Fällen von der Stromversorgung trennen!}}

Der Benutzer fhem muss Mitglied in der Gruppe dialout sein! Bitte prüfen:
<pre>groups fhem</pre>

'''Das System unbedingt neu starten!'''

=== Kontrolle ===
Berechtigungen der Schnittstelle kontrollieren
<pre>ls -l /dev/ttyAMA0</pre> liefert die Ausgabe unter Jessie
<pre>crw-rw---- 1 root dialout 204, 64 Jul 27 23:39 /dev/ttyAMA0</pre>
bzw. unter wheezy
<pre>crw-rw---T 1 root dialout 204, 64 Aug 9 18:07 /dev/ttyAMA0</pre>

=== Definition in FHEM===
<pre>define myHmUART HMUARTLGW /dev/ttyAMA0
attr myHmUART hmId xxxxxx</pre>

=== Verwendung AES in FHEM===
Das Modul beherrscht AES.
Für weitere Informationen gibt es einen separaten Wiki Eintrag [[AES Encryption]]

=== Logbeispiel ===
Typischerweise meldet sich das Modul beim Start so:
2016.10.06 17:11:16 3: Opening myHmUART device /dev/ttyAMA0
2016.10.06 17:11:16 3: Setting myHmUART serial parameters to 115200,8,N,1
2016.10.06 17:11:16 3: myHmUART device opened
2016.10.06 17:11:17 3: HMUARTLGW myHmUART currently running Co_CPU_BL
2016.10.06 17:11:17 3: HMUARTLGW myHmUART currently running Co_CPU_App

=== Firmware Update HM-MOD-RPI-PCB ===

Die Module werden mit einer Firmware 1.2.1 ausgeliefert. Dies Firmware ist nicht für einen stabilen Betrieb geeignet!
Firmware 1.4.1 ist die minimal lauffähige Version!

1. Firmware herunterladen
wget https://raw.githubusercontent.com/eq-3/occu/28045df83480122f90ab92f7c6e625f9bf3b61aa/firmware/HM-MOD-UART/coprocessor_update.eq3

2. Kopieren an einen Ort wo FHEM Zugriff hat, am Besten nach /opt/fhem/FHEM/firmware
sudo cp coprocessor_update.eq3 /opt/fhem/FHEM/firmware/
3. Flashen der neuen Firmware aus Fhem
fhem> set myHmUART updateCoPro /opt/fhem/FHEM/firmware/coprocessor_update.eq3

=== Alternative Methode zum Firmware Update ohne FHEM ===

Sollte das Update über FHEM nicht funktionieren oder FHEM nicht verfügbar sein, kann die Firmware auch wie folgt eingespielt werden (Quelle: [http://heinz-otto.blogspot.com/2016/07/raspberry-pi-homematic-modul.html Ottos Technik Blog])

sudo su
apt-get update && apt-get -y install libusb-1.0-0-dev build-essential git
systemctl stop fhem
git clone git://git.zerfleddert.de/hmcfgusb
cd hmcfgusb/
make
# Firmware runterladen
wget https://raw.githubusercontent.com/eq-3/occu/ee68faf77e42ed5e3641790b43a710a3301cea7e/firmware/HM-MOD-UART/coprocessor_update.eq3
# eigentliches flashen:
./flash-hmmoduart -U /dev/ttyAMA0 coprocessor_update.eq3

== Remoteanbindung - Pi + RPI Modul = LAN Modul ==
''Noch in Bearbeitung''

Es ist nicht dazu gedacht zwei FHEM Instanzen zu koppeln, sondern das RPI Modul über socat auf dem entfernten Raspi verfügbar zu machen.
auf dem Pi wo das Modul angeschlossen ist:
Kein FHEM Zugriff!
Kein define HmUART_EG HMUARTLGW /dev/ttyAMA0
Kein define RM_HmUART_EG HMUARTLGW uart://192.168.17.185:2000

Installation auf Remote Instanz

sudo apt-get install socat

Auf diesem Pi, also wo das Modul steckt:

sudo socat TCP4-LISTEN:2000,fork,reuseaddr /dev/ttyAMA0,raw,echo=0,b115200

In welcher Datei lege ich diesen Befehl am besten ab damit dieser bei einem Neustart ausgeführt wird.
Würde die rc.local ohne sudo dafür verwenden.

Auf einen Debian Jessie mit systemd legt man am besten folgende Datei an:

$cat /etc/systemd/system/hmlangw.service
[Install]
WantedBy=multi-user.target
Type=forking

[Service]
ExecStart=/usr/bin/socat TCP4-LISTEN:2000,fork,reuseaddr /dev/ttyAMA0,raw,echo=0,b115200
User=root
Restart=always
RestartSec=10

Dann kann mit

sudo systemctl enable hmlangw

der Service zum Autostart konfiguriert werden.
Auf dem Modul wo FHEM läuft und das Modul Remote angeschlossen werden soll:

define RM_HmUART_EG HMUARTLGW uart://192.168.17.185:2000

Es handelt sich nicht um sharing der seriellen Schnittstelle und damit "verfügbar machen" des Moduls all over the World!
Es handelt sich um ein exklusives "Kabel" von Pi zu Pi zur Schnittstelle zum RPI Modul.

PI1: FHEM -> uart://IP:Port -> Netzwerk ->
Remote PI2: Netzwerk -> socat listener -> socat serial -> RPI Modul auf PI2

RPI Modul auf PI2 -> serial -> socat -> Netzwerk -> uart://IP:Port -> FHEM auf PI1

== Bekannte Probleme ==
Sollten beim Flashen der Firmware hartnäckige Probleme auftreten (kein Erfolg aber auch gar keine Fehlermeldungen) ist das Modul vom Strom zu trennen, ein Neustart des Pi reicht nicht!

Ein {{Link2Forum|Topic=41203|Message=340320|LinkText=Beitrag}} aus dem genannten Forenthread: ''Das Ding ist anscheinend wirklich einfach das Funkmodul aus der CCU2 (wird zumindest in der eQ-3 SW als CCU2 angesprochen) und spricht ein für Fhem vollkommen neues Protokoll.''

== Links ==
* {{Link2Forum|Topic=41203|LinkText=Forenthread}} mit Nachfrage zur Unterstützung dieses Geräts in FHEM
* {{Link2Forum|Topic=54511|LinkText=Modul für HomeMatic UART-Modul (RPi) und HomeMatic LAN Gateway}}
* [http://www.elv.de/homematic-funkmodul-fuer-raspberry-pi-bausatz.html Produktseite] bei ELV
* {{DocLink|elv|/Assets/Produkte/10/1040/104029/Downloads/104029_lan_gateway_um.pdf Bedienungsanleitung}}

[[Kategorie:HomeMatic Components]]
[[Kategorie:Interfaces]]
[[Kategorie:Raspberry Pi]]

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

2015-12-14T07:16:49Z

Michael: modusBtnLock Tastensperre

'''HM-CC-RT-DN''' ist ein '''Funk-Heizkörperthermostate mit integriertem Stellantrieb''', der als Nachfolger den [[HM-CC-VD]] ablöst und seit Mitte September 2013 verfügbar ist.

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

Im Gegensatz zum Vorgänger misst der HM-CC-RT-DN selbst die Temperatur und verfügt über eine Boost-Funktion. Er braucht zur Steuerung kein separates Raumregelungsgerät mehr und hat eine eigene Fenster-Offen-Erkennung. Ein passender Wandthermostat ([[HM-TC-IT-WM-W-EU_Funk-Wandthermostat_AP|HM-TC-IT-WM-W-EU]]) ist seit Februar 2014 verfügbar.

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

Der '''HM-CC-RT-DN''' scheint das erste HomeMatic-Device zu sein, bei dem ein Update der Firmware auch vom Anwender durchgeführt werden kann. Ein Firmware-Update erfordert einen [[HM-CFG-USB_USB_Konfigurations-Adapter|USB Konfigurations-Adapter]] und eine auf der eQ-3 Webseite herunterladbare Firmware Update Software. Weitere Details sind unter [[HM-CC-RT-DN_Funk-Heizkörperthermostat#Firmware Update|Firmware Update]] beschrieben.

'''Achtung:''' Die Solltemperaturen eines HM-CC-RT-DN lassen sich <ins>nicht</ins> durch einen [[HM-CC-TC Funk-Wandthermostat|HM-CC-TC]] steuern. Dieser kann höchstens die Ist-Temperatur an den RT weiter geben, damit die Raumtemperatur nicht am RT selbst zur Ventilsteuerung genommen wird.

Mit einem HM-CC-RT-DN können maximal (neben der Zentrale/Fhem):
* 7 HomeMatic Heizkörperthermostate
* 8 HomeMatic Tür-Fensterkontakte / Fenster-Drehgriffkontakte
* 8 Tastenpaare von HomeMatic Fernbedienungen bzw. Display-Wandtaster
* 1 HomeMatic Innen-Temperatur-Sensor
gep'''ee'''rt werden.

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

Aktuelle Firmware: 1.4

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

=== Channels (Kanäle) ===
==== Channel (Kanal) 01 _Weather ====
Dieser Kanal dient zur Einspeisung der gemessenen ("Ist"-) Temperatur, als Sensor kann z.B. ein HomeMatic HM-WDS10-TH-O Funk-Temperatur-/Luftfeuchtesensor OTH dienen.

Der Befehl zum peeren lautet, wobei <tempSensor> die Fhem-Kanalbezeichnung für den Sensor ist und <rt_Weather> die Kanalbezeichnung für den entsprechenden Kanal des Heizkörperthermostates:
set <tempSensor> peerChan 0 <rt_Weather> single

==== Channel (Kanal) 02 _Climate ====
Der Climate-channel dient der Kommunikation mit einem Temperatur-Kontroller (aktuell nur [[HM-TC-IT-WM-W-EU_Funk-Wandthermostat_AP|HM-TC-IT-WM-W-EU]]).
Zum peeren von TC und RT siehe [[HM-TC-IT-WM-W-EU_Funk-Wandthermostat_AP#Hinweise zur Inbetriebnahme und Installation|HM-TC-IT-WM-W-EU]].

==== 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.
Ferner wird empfohlen, bei Einsatz von externen Sensoren, die interne „Fenster auf Erkennung“ zu deaktivieren (weitere Details sind im [[HM-CC-RT-DN Funk-Heizkörperthermostat#Channel .28Kanal.29 04 _Clima|Channel (Kanal) 04 _Clima]] beschrieben).

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

Zum Löschen (=unpeeren) dieser Kopplung:
set <fensterSensor> peerChan 0 <rt_WindowRec> single unset

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

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

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

'''Achtung:''' In älteren Versionen von Fhem wurde dieser Kanal durch autocreate als "_ClimRT_tr" angelegt. Der Hersteller hat hier offenbar die internen Bezeichnunen geändert, denn beim Vorläufernmodell HM-CC-TC mussten Temperaturlisten auf den Kanal ''Climate'' übertragen werden.

Die maximale Öffnung des Ventils kann mittels folgendem Befehl eingestellt werden (hier auf 80 %):
set <rt_Clima> regSet valveMaxPos 80

Die interne "Fenster-auf" Erkennung kann man wie folgt abschalten:
set <rt_Clima> regSet winOpnMode off

==== Channel (Kanal) 05 _ClimaTeam ====
Dieser Kanal dient zum peeren von mehreren Heizkörperthermostaten untereinander. Ein Mitglied des "Teams" meldet
* Änderungen der Temperatur am Handrad
* Einschalten des Boost-Modus am Taster
an seine "Teamkollegen" weiter. Folgende Änderungen werden '''nicht''' weitergegeben:
* Status der Fensterkontakte
* Temperaturlisten/Wochenplan und daraus folgende Änderungen
* Änderungen durch Fernbedienungen
* Änderungen durch eine HomeMatic-Zentrale

Befehl zum peeren, wobei <rt1-ClimaTeam> und <rt2-ClimaTeam> die Kanalbezeichnungen der beiden ClimaTeam-Kanäle sind:
set <rt1-ClimaTeam> peerChan 0 <rt2-ClimaTeam> single

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

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

=== Betriebsmodus Auto, Manu, Party (Urlaub) ===
Im Automode kann man die Temperatur am Einstellrad des RT ändern. Zum nächsten Schaltpunkt wird dies dann überschrieben. Will man dies nicht (z.B. lange Party, ...), kann man auf manuell schalten. Dann bleibt die mit dem Drehregler (oder der Zentrale) eingestellte Temperatur stehen bis ''ultimo''. Es gibt dann noch den Party- oder Urlaubsmodus. In diesen kann man den Automodus für eine gegebene Zeit überschreiben.

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

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

Rückgängig machen geht per:

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

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

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

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

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

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

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

eingeschaltet. Abschalten geht mit:

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

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

==== Modus Manu ====
Das Wochenprogramm wird nicht abgearbeitet, die Temperatur wird manuell eingestellt.

==== Modus Party (Urlaub) ====
Will man für eine festgesetzte Zeit (Stunden oder Tage) die Temperatur auf einen festen Wert einstellen (z.B. weil man in Urlaub fährt), kann man dies zwar auch durch Änderungen der Temperaturlisten erreichen, einfacher ist aber die Zuweisung über den Urlaubsmodus, da nach dessen Ablaufdatum und -zeitpunkt automatisch in den Auto-Modus gewechselt wird.

'''Ein Beispiel:'''
:<code>set HM-CC-RT-DN_Clima controlParty 16 06.12.13 16:30 09.12.13 05:00</code>

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

eingestellt.

'''Hinweise:'''
* Der Befehl muss auf den Channel 4 ("_Clima") erfolgen.
* Es werden nur Uhrzeiten zu jeder vollen oder halben Stunde angenommen (Minuten also 00 oder 30).

Mit der Funktion "Urlaub" kann man eine ganze Wohnung (also mehrere RT´s) mit nur einem Befehl in den Party-mode versetzen.

Der Name "Urlaub" kann natürlich frei gewählt werden. Im Beispiel werden zwei Heizkörper (Treppenhaus und Kammer) angesteuert.

Zu beachten sind folgende Dinge:
# Aktuelle Dateien (z.B. 10_CUL_HM) verwenden!
# Bei dem partycontrol-Befehl in der Funktion KEIN Komma zwischen den Parametern.
# Bei der Funktion die Parameterübergabe definieren ($$$$$)

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

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

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

#Sendebefehl für ein HM-CC-RT-DN
{fhem ("set Kammer controlParty $temp $startDate $startTime $endDate $endTime")}

# alternative Schreibweise der Parameter:
{fhem ("set Treppenhaus controlParty @_[0] @_[1] @_[2] @_[3] @_[4]")};
}
</source>

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

'''Nachteil:''' Der RT muss den Receiver wach halten. Der RT und alle anderen Burst-Devices erwachen bei '''jedem''' Burst (egal für wen) und legen sich dann wieder schlafen.
* jeder Burst-trigger kostet Batterie für '''alle''' Burst-Geräte im System
* wenn Burst enabled ist kostet es dem RT Batteriekapazität

'''Burst – wie es funktioniert'''

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

'''HMLAN und burst'''

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

'''Burst devices'''

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

'''ConditionalBurst devices'''

Devices mit abschaltbarem burst wie z.B. der 'HM-CC-RT-DN', gibt es ein Register burstRx mit dem das burst-erwachen eingestellt werden kann.
Sender, die einen burst-Aktor erwecken sollen muss man sagen, welcher peer burst benötigt. Hier kann ggf. das Register peerNeedsBurst nach dem peeren gesetzt werden. FHEM versucht dies automatisch beim Peeren zu erledigen. Siehe Hminfo Befehl 'models', um festzustellen, welche Devices welchen Modus unterstützen.

'''Attribut burstAccess'''

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

'''Kommando burstXmit'''

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

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

Dann sendet der User ein set burstXmit.

Es passiert das gleiche wie bei burstAccess.

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

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

''' FHEM und burst devices'''

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Fertig.

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

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

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

== Links ==
* [http://www.elv.de/homematic-heizkoerperthermostat-1.html Produktinfo]
* [http://www.elv-downloads.de/Assets/Produkte/10/1051/105155/Downloads/105155_thermostat_um.pdf Bedienungsanleitung (PDF)]
* [http://www.elv-downloads.de/Assets/Produkte/10/1051/105155/Downloads/105155_thermostat_data.pdf Datenblatt (PDF)]
* [http://www.elv-downloads.de/service/manuals/ventilkompatibilitaet.pdf Ventil-Kompatibilitätsliste (PDF)]
* {{Link2Forum|Topic=14738|LinkText=Forenthema zum Thermostat}}

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

HM-CFG-USB USB Konfigurations-Adapter

2015-11-02T16:01:09Z

Michael: Packages für DSM hinzugefügt.

{{Infobox Hardware
|Bild=platzHalter.png
|Bildbeschreibung=todo
|HWProtocol=HomeMatic
|HWType=Interface/Gateway
|HWCategory=HomeMatic
|HWComm=868,3MHz
|HWChannels=
|HWVoltage=
|HWPowerConsumption=
|HWPoweredBy=USB-Bus
|HWSize=
|HWDeviceFHEM=[http://fhem.de/commandref.html#CUL_HM CUL_HM]

|HWManufacturer=HomeMatic
}}
Der [[HomeMatic]] '''USB Konfigurations-Adapter''' ist ein USB-Stick, der außer zur Konfiguration von HomeMatic Komponenten auch als [[Interface]] zwischen Fhem und HomeMatic Geräten benutzt werden kann. Er existiert in zwei Versionen: der älteren HM-CFG-USB und der neueren HM-CFG-USB2. Die folgenden Beschreibungen gelten für beide Versionen, es sei denn, es ist ausdrücklich eine spezifische Version genannt.

== Einbindung in Fhem ==
Im Fhem-Forum wird die Einbindung als Interface in diesem {{Link2Forum|Topic=13071}} beschrieben und diskutiert. Im {{Link2Forum|Topic=13071|Message=79872|LinkText=Eröffnungsbeitrag}} wird eine gut funktionierende HMLAN-Emulationssoftware [https://git.zerfleddert.de/cgi-bin/gitweb.cgi/hmcfgusb hmland] von ihrem Entwickler vorgestellt, um den HM-CFG-USB in Fhem zu integrieren. Die HMLAN-Emulationssoftware muss zunächst kompiliert und installiert werden. Anschließend wird der HM-CFG-USB (üblicherweise auf localhost) genau wie [[HM-CFG-LAN LAN Konfigurations-Adapter|HMLAN]] in Fhem eingebunden.

=== Einrichtung unter Linux ===
Die Schritte zur Kompilierung und Installation hat der hmland-Entwickler sowohl auf der [https://git.zerfleddert.de/cgi-bin/gitweb.cgi/hmcfgusb hmland-Internetseite] in Englisch (kurz) als auch im oben genannten {{Link2Forum|Topic=13071|Message=79872|LinkText=Eröffnungsbeitrag}} in Deutsch (ausführlich) dargestellt. Die dort gemachten Angaben werden auch bei Bedarf aktualisiert und sind deshalb der beste Anlaufpunkt für Kompilierung und Installation.

Die nachfolgenden Angaben in diesem Abschnitt sind rein zu Informationszwecken (noch) enthalten:

Zunächst muss die HMLAN-Emulationssoftware kompiliert werden. Analog zu [https://git.zerfleddert.de/cgi-bin/gitweb.cgi/hmcfgusb dieser Beschreibung] ist die Vorgehensweise die folgende (in Debian/Ubuntu/Raspbian):
cd /opt/
apt-get install build-essential libusb-1.0-0-dev make gcc git-core
git clone git://git.zerfleddert.de/hmcfgusb
cd hmcfgusb
make

Danach kann der Dienst zu Testzwecken gestartet werden (in /opt/hmcfgusb):
:<code>./hmland -p 1234 -D</code>

==== Start als Daemon ====
Um den hmland als Daemon mit dem Betriebsystem automatisiert zu starten, kann ein init-script genutzt werden. In diesem {{Link2Forum|Topic=13071|Message=190887}} ist ein Skript zur automatischen Einrichtung von hmland als Daemon über init mit Installationsanweisung enthalten. Dieses Skript enthält zudem auch die Befehle zum Download, Kompilierung und Installation von hmland, so dass fast keine manuellen Eingriffe notwendig sind.

Alternativ ist auch der (umständlichere) manuelle Weg möglich:
<pre>
#!/bin/sh
### BEGIN INIT INFO
# Provides: hmland
# Required-Start: $localfs $syslog $remote_fs
# Required-Stop:
# Default-Start: 2 3 4 5
# Default-Stop: 0 1 6
# Short-Description: hmland daemon
# Description: hmland daemon, Homematic USB Adapter on port 1234
### END INIT INFO

# simple init for hmland

pidfile=/var/run/hmland.pid
port=1234

case "$1" in
start|"")
chrt 50 /opt/hmcfgusb/hmland -d -P -l 127.0.0.1 -p $port 2>&1 | perl -ne '$|=1; print localtime . ": [hmland] $_"' >> /var/log/hmland.log &
;;
restart|reload|force-reload)
echo "Error: argument '$1' not supported" >&2
exit 3
;;
stop)
killall hmland
;;
status)
if [ ! -e $pidfile ]; then
echo "No pid"
exit 1
fi
pid=`cat $pidfile`
if kill -0 $pid &>1 > /dev/null; then
echo "Running"
exit 0
else
rm $pidfile
echo "Not running"
exit 1
fi

;;
*)
echo "Usage: hmland [start|stop|status]" >&2
exit 3
;;
esac
</pre>

Bei Distributionen, die Upstart einsetzen (z.B. xbian) kann folgendes Konfigurationsfile verwendet werden:
<pre>
# HMLAND

description "hmland"

start on starting fhem
stop on stopped fhem

respawn
expect fork

chdir /opt/hmcfgusb
exec /opt/hmcfgusb/hmland -d -l 127.0.0.1 -p 1234
</pre>

Die Datei sollte als "/etc/init/hmland.conf" angelegt werden. Mit dem Befehl
initctl reload-configuration
wird Upstart angewiesen, seine Konfiguration erneut einzulesen. Danach kann der neue Dienst
mit
service hmland start
gestartet werden. <code>hmland</code> wird jetzt immer vor Fhem gestartet und nach Fhem beendet.

==== Start über Fhem Startskript ====

Ausprobiert auf einem BBB mit Debian, eigentlich ist das alles von Betateilchen:

Zunächst hmland kompilieren wie oben beschrieben, bis zum make. Das muss erfolgreich durchgelaufen sein.

Dann geht es weiter:

sudo cp hmcfgusb.rules /etc/udev/rules.d/

Jetzt das Fhem Startskript anpassen (in den Blöcken 'start' und 'stop' muss quasi nur jeweils 1 Zeile eingefügt werden:

Damit editiert man das Fhem Startskript:
sudo nano /etc/init.d/fhem

Und so sollten die Blöcke anschließend aussehen (bitte nur jeweils die Zeile mit hmland einfügen)

'start')
echo "Starting fhem..."
/opt/hmcfgusb/hmland -d -p 1234
perl fhem.pl fhem.cfg
RETVAL=$?
;;

'stop')
echo "Stopping fhem..."
perl fhem.pl $port "shutdown"
RETVAL=$?
pkill hmland

So wird hmland vor Fhem gestartet und nach Fhem beendet. Letztlich erspart es Probleme mit den diversen Startskripten und ihren Rechten.

Es dauert nach dem Start von Fhem noch einige Sekunden, bis hmland fertig geladen ist. In dieser Zeit kann es zu fehlerhaften Einträgen im Logfile kommen.

=== Einrichtung auf Synology DiskStations ===

Packages für DSM5.2 finden sich hier:
https://github.com/mkunzmann/spksrc/releases/tag/0.101-3

Welches Package für welche DS kann man hier sehen:
https://github.com/SynoCommunity/spksrc/wiki/Architecture-per-Synology-model

Einfach das passende Package installieren und dann kann man den hmland über den Synology Package-Manager starten und stoppen.
Während der Installation kann man den Port für hmland festlegen. Bitte einen Port > 1024 wählen, da der hmland nicht als root läuft.
Außerdem kann ein Logfile angegeben werden. Hier am besten eine Datei auf einem USB Stick angeben die für jedermann schreibbar sein muss.
Damit sollten die Platten nach wie vor in den Standby gehen.

=== Einrichtung unter Mac OS X ===
Wie unter Linux braucht man die HMLAN-Emulationssoftware hmland, die man aus Quelltexten erstellen muss. Dazu muss man die Bibliothek libusb installieren, entweder mit einem der Paketmanager wie Fink, MacPorts oder Homebrew oder direkt aus den Quellentexten (Beispiel: "fink install libusb1-shlibs libusb1"). Hat man wie bei Linux das Quelltextarchiv für hmland heruntergeladen und ausgepackt, müssen die Dateien Makefile und hmcfgusb.c angepasst werden.

Im Makefile muss man den Pfad zur libusb anpassen. Hat man libusb mit fink installiert, muss man, "/opt/local/" durch "/sw/" bei den CFLAGS und den LDFLAGS ersetzen und
das "-lrt" aus den LDLIBS entfernen. Die Library librt gibt es bei Mac OS X nicht und wird anscheinend auch nicht gebraucht. (Stimmt das eigentlich?)

In der Datei hmcfgusb.c muss man die Zeilen 130-134 mit dem Aufruf libusb_detach_kernel_driver auskommentieren oder löschen. Der geht nicht auf Mac OS X.

Nach den Änderungen in den zwei Dateien, kann man wie bei Linux den Dämon hmland mit dem Kommando "make" erzeugen und mit "./hmland" ausführen. Automatisches Starten beim Booten mit launchd ist noch nicht probiert.

Beim Start von hmland sollte man folgende Fehlermeldung in einer Endlos-Schleife erhalten:

Datum Zeit: Client 127.0.0.1 connected! <br />
Can't claim interface: Access denied (insufficient permissions) <br />
Can't find/open hmcfgusb! <br />
Datum Zeit: Connection to 127.0.0.1 closed! <br />

Auch ein Start von hmland mit Superuser-Rechten ändert daran nichts. Damit das claim interface klappt, muss man eine codeless kext in den Ordner /Library/Extensions legen. Ich habe dieses (http://mspdebug.sourceforge.net/misc/ex430rf2500-kext.zip) herunter geladen. Damit es funktioniert, muss man aber in der Datei Info.plist des Bundle die Properties idProduct und idVendor ändern, entweder mit dem Property List Editor oder einem anderen Texteditor. Die beiden Properties sind etwas versteckt bei Information Property List → IOKitPersonalities → ComIntf. Bei DebugIntf und DeviceDriver scheint man es nicht ändern zu müssen, aber schaden kann es nicht.<br />

idProduct: 49167<br />
idVendor: 6943

Die Rechte des kext-Bundles müssen auch noch gesetzt werden:

chmod -R 755 ex430rf2500.kext
chown -R root:wheel ex430rf2500.kext

Danach die Datei ex430rf2500.kext in den Ordner /Library/Extensions legen und hmland sollte dann funktionieren.

Es kann sein, dass ab Mac OS X 10.9 der Trick mit dem codeless kext nicht mehr funktioniert, aber noch ist das nicht getestet oder bestätigt. Langfristig kann man vielleicht auch eine kext mit einem Treiber für den HM-CFG-USB USB erstellen

=== Einrichtung unter Windows ===
Bei der Einrichtung und vermutlich auch dem Betrieb unter Windows 8.1 sind wegen der erweiterten Energieverwaltungsfunktionen die von eQ-3 [http://www.eq-3.de/Downloads/eq3/pdf_FAQ/Funk-Konfigurationsdapter-USB_Windos_8.1.pdf zusammengestellten Tipps] zu befolgen.

== Bekannte Probleme ==
=== Verbindung zu neueren hmland-Versionen nicht stabil ===
Seit Version 0.100 meldet sich die HMLAN-Emulationssoftware als USB-Interface bei Fhem. Ältere Fhem-Versionen (vor dem 19.6.2015) brechen deshalb die Verbindung ab, da sie nur ein LAN-Interface erwarten.

Lösung: Kommandozeilenparameter <code>-I</code> dem hmland-Aufruf hinzufügen, dann meldet sich dieser wieder als LAN-Interface.

=== Stick nicht (mehr) ansprechbar ===
Zitat aus dem {{Link2Forum|Topic=32502|Message=249122|LinkText=Fhem-Forum}}:
:''... befürchte ich, dass dein Stick das Zeitliche gesegnet hat. Machen die Dinger leider sehr gerne... Ganz besonders beim Modus-Wechsel vom 10k- in den 100k-Modus, wenn man bei irgendeinem Device ein Firmwareupdate durchführt. <br />Die gute Nachricht ist, dass der Fehler bei sämtlichen Händlern bekannt ist und anstandslos getauscht wird.''

=== Raspberry Pi ===
Der USB-Stack am Raspberry Pi ist für viele Probleme verantwortlich. Daher sieht man öfter Fehlermeldungen:
:<code>usb-transfer took more than 100ms (1039ms), this may lead to timing problems!</code>

Da das Timing bei Homematic wichtig ist führt das zu vielen Retransmits und zu unzuverlässigen Aktoren. Als Workaround kann man den USB-Stack auf die deutlich langsamere Version 1.1 stellen. Dazu fügt man folgenden Text am Anfang der Datei /boot/cmdline.txt ein:
:<code>dwc_otg.speed=1</code>

=== Windows ===
Die erweiterte Energieverwaltung unter Windows 8.1 kann dazu führen, dass der Adapter unerwünschterweise in den Stand-by Modus versetzt wird (siehe [[HM-CFG-USB USB Konfigurations-Adapter#Einrichtung unter Windows|Einrichtung unter Windows]]).

== Weitergehende Informationen ==
Es sind zwei Versionen des HM-CFG-USB im Umlauf:
* HM-CFG-USB-2: die aktuelle Version; Dokumentation derzeit (12/2013) nicht über die ELV-Artikelseite verfügbar, alternativ jedoch bei [http://files.voelkner.de/625000-649999/640558-an-01-ml-USB_FUNK_KONFIGURATIONSADAPTER_de_en.pdf Völkner]; Kennzeichen dieser Version:
** Größe: 28 x 84 x 11,5 mm
** Gewicht: 18 g
** Antenne innenliegend
* HM-CFG-USB: Vorgängerversion; Stand 12/2013 noch Restbestände im Handel verfügbar. Dokumentation ([http://files.voelkner.de/625000-649999/646462-an-01-ml-HM_Konfigurationsadapter_CFG_USB_de_en.pdf Völkner]); Kennzeichen:
** Anschluss per separatem USB-Kabel
** abstehende Stabantenne
** Größe: 40 x 90 x 25 mm
** Gewicht: 45 g

== Links ==
* Fhem-Forums {{Link2Forum|Topic=13071}}: HomeMatic USB Konfigurations-Adapter (HM-CFG-USB) in Fhem nutzen
* [http://www.elv.de/homematic-usb-konfigurations-adapter-1.html ELV Shopseite] zum HM-CFG-USB
* [http://www.eq-3.de/produkt-detail-zentralen-und-gateways/items/homematic-funk-konfigurationsadapter-usb.html eQ-3 Produktseite] zum "HomeMatic Funk-Konfigurationsadapter USB"; Downloads, technische Daten, etc.

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