FHEMWiki - Benutzerbeiträge [de]

Luxtronik 1 in FHEM

2023-09-28T16:29:02Z

Hmcontrol: ESPHOME Lösung unter Weblinks eingetragen.

{{Todo|Fertigstellung; Erläuterungen ob und wie FHEM-Anbindung erfolgen kann}}

== Features / Funktionen ==
Die Luxtronik 1.0 ist eine Heizungssteuerung, die in Wärmepumpen von Alpha Innotec, Siemens und Novelan verbaut ist. Ihr fehlt ein Ethernet Anschluss, so dass sie über die vorhandene RS232-Schnittstelle integriert werden muss. Sie ist die Vorgängerversion der LAN-fähigen [[Luxtronik 2.0]], für die ein FHEM-Modul existiert.

== Hinweise zum Betrieb mit FHEM ==
Falls es besondere Einschränkungen / Voraussetzungen, etc. gibt...
# Die Wärmepumpe kann nur über die serielle Schnittstelle angesprochen werden.
# Derzeit wird nur das Auslesen der Konfiguration und Werte unterstützt.

== Verbindung herstellen ==
Damit man die Schnittstelle - die insbesondere für Wartungszwecke da ist - nutzen kann, musst du die nachfolgenden Schritte durchführen.
=== Schnittstelle freigeben ===
Unter ''Einstellungen --> Datenzugang'' die PIN 9445 für den Kundendienstzugang eingeben und bestätigen. Es passiert erstmal nix, es sind jetzt aber weitere Menüs erreichbar. Unter ''Einstellungen --> Diagnose'' Standard auswählen. Damit ist die Schnittstelle freigegeben.
=== Kabel anschließen ===
Jetzt geht es an die Wärmepumpe, diese öffnen. Bei meiner Alpha Innotec ist die Steuerung an der linken Seite hinter einer Metallabdeckung. Dort sieht es dann so aus:

:[[Datei:Luxtronik1-kabel-anschliessen.jpg]]

Der rote Pfeil zeigt den seriellen Anschluss, hier muss das Kabel eingesteckt werden.
=== Das Kabel ===
Es gibt leider viele verschiedene Kabelbelegungen. Daher ist es am einfachsten sich ein Kabel selbst zu löten. Drei PINs müssen verbunden sein: 5 (GND), 3 (TX) und 2(RX). Auf beiden Seiten sind die Anschlüsse gleich, es ist ein 1:1-Kabel, also keine Drehung von 2 auf 3 o.Ä.

:[[Datei:Luxtronik1-serielles-kabel.jpg]]

Das Bild zeigt ein gelötetes Kabel am USB-RS23-Adapter.
=== Der RS232-USB-Adapter ===
In meinem Fall war das ein USB-Seriell-Adapter (Typ Targus PA088E bzw MCT U232 - gibt es für 13 € bei Ebay. Software ist von MCT.com.tw und läuft bei mir unter Win10 und Win7/64Bit). Andere Adapter sollten genauso funktionieren, wenn es Treiber dafür gibt.

Der FHEM läuft bei mir auf einem BananPi, für den RaspberryPi sollte das selbe gelten. Steckt man den Adapter ein, wird er erkannt. Man kann das leicht mit dem Befehl <code>lsusb</code> prüfen.

Nach Eingabe des Befehls <code>dmesg</code> sieht man, wie das Gerät eingebunden ist:

<pre>[278127.624239] mct_u232 ttyUSB0: MCT U232 converter now disconnected from ttyUSB0
[278127.632780] mct_u232 3-1:1.0: device disconnected
[278206.689646] ehci_irq: port change detect
[278206.912197] ehci_irq: port change detect
[278206.972264] The port change to OHCI now!
[278207.277779] usb 3-1: new full-speed USB device number 4 using sw-ohci
[278207.474278] usb 3-1: New USB device found, idVendor=0711, idProduct=0230
[278207.486502] usb 3-1: New USB device strings: Mfr=1, Product=2, SerialNumber=3
[278207.493495] usb 3-1: Product: Targus Group Intl
[278207.503430] usb 3-1: Manufacturer: Targus Group Intl
[278207.509376] usb 3-1: SerialNumber: 489991
[278207.520277] mct_u232 3-1:1.0: MCT U232 converter detected
[278207.530816] usb 3-1: MCT U232 converter now attached to ttyUSB0</pre>

Wichtig ist die Information welches Devices das nun ist "attached to...", hier <code>/dev/ttyUSB0</code>.
=== Einstellungen der seriellen Schnittstelle ===
Anders, als ich zunächst dachte funktioniert eine Verbindung mit der Standardrate 9.600 Baud nicht. Die richtigen Einstellungen sind:
* 57600 baud
* 8 Bit
* 1 Stopbit
* kein Paritätsbit
* Xon/Xoff Flusskontrolle

==== Minicom (Linux) ====
Damit man ausprobieren kann, ob bis hierher alles funktioniert, kann man das Terminalprogramm minicom (für Linuxkonsolen) verwenden. Der Befehl <code>sudo apt-get install minicom</code> installiert das Programm. Unter <code>/etc/minicom</code> liegt die Datei minirc.dfl, diese enthält bei mir folgende Einstellungen:

<pre># Machine-generated file - use "minicom -s" to change parameters.
pu port /dev/ttyUSB0
pu baudrate 57600
pu bits 8
pu parity N
pu stopbits 1
pu rtscts No</pre>

==== PuTTY (Windows/Linux) ====
Wer den ersten Test von Windows oder der grafischen Konsole von Linux machen will, der kann [http://www.chiark.greenend.org.uk/~sgtatham/putty/ PuTTY] verwenden.

:[[Datei:Luxtronik1_putty.png]]

Ihr müsst dann unter Sessions von "ssh" auf "serial" umstellen. COM1 stimmt natürlich auch nur, wenn es bei euch ebenfalls COM1 ist, dies könnt ihr im Geräte-Manager prüfen.

=== Verbindungstest ===
Der spannende Moment, wenn ihr alles richtig gemacht habt, könnt ihr nun mit der Luxtronik 1 kommunzieren. Für den ersten Test unterstelle ich, dass ihr entweder PuTTY oder Minicom verwendet.
Wenn ihr nun Enter drückt, bekommt ihr ein freundliches <code>777</code> zurück. Gebt ihr <code>1800</code> ein, kommt eine ganze Seite von Zahlen zurück. Super.

== FHEM-Modul Luxtronik1 ==
Leider gibt es kein offizielles FHEM-Modul Luxtronik1 :-(

Todo: Wo bekommt man das inoffizielle Modul her?

== MQTT-Client für Luxtronik 1 ==
Es gibt eine Open Source Software, die einen MQTT-Client für die Luxtronik 1 implementiert hat.
Damit sollte es möglich sein, die Wärmepumpe über den FHEM-eigenen [[MQTT]] Gateway einzubinden.
Die Software ist verfügbar unter: https://bitbucket.org/tobylorenz/ait_luxtronik/.
Sie wird laufend gewartet und um weitere Wärmepumpen ergänzt.

== Bekannte Probleme ==
Keine

== Weblinks ==
* heatpumpctl [https://github.com/christophgysin/heatpumpctl/tree/master/doc Dokumentation der Schnittstelle + C-Sourcen]
* Hoerndlein [http://www.hoerndlein.de/cms/index.php/luxtronik-1 Perl-Modul]
* Forumsdiskussion [https://forum.fhem.de/index.php?topic=29740.0]
* ESPHOME Lösung für die Einbindung in Home Assistant [https://github.com/CBrosius/luxtronik_v1]

[[Kategorie:Other Components]]
[[Kategorie:MQTT]]

SIGNALduino

2017-11-15T15:07:28Z

Hmcontrol: /* Einfache Module */

{{Infobox Modul
|ModPurpose=Empfang und Verarbeitung von digitalen Signalen
|ModType=d
|ModFTopic=38402
|ModCmdRef=SIGNALduino
|ModForumArea=Sonstige Systeme
|ModTechName=00_SIGNALduino.pm
|ModOwner=Sidey ({{Link2FU|8018|Forum}}/[[Benutzer Diskussion:Sidey|Wiki]])
}}

== Einleitung ==
=== Übersicht ===
Unter den Namen SIGNALduino versteht man sowohl den Low-Cost Empfänger für digitale Signale (vergleichbar dem [[CUL]]) als auch das gleichnamige Modul mit dem Dateinamen 00_SIGNALduino.pm. Mit dem SIGNALduino kann man entweder 433 oder 868 MHz-Geräte auslesen und ansprechen. Der SIGNALduino funktioniert auch mit anderen Medien wie Infrarot oder direkter Kabelverbindung.

Der SIGNALduino erkennt Signale anhand von Mustern und gibt sie an FHEM zur Auswertung (Dekodierung) weiter. Auch nicht erkannte Signale werden an FHEM übergeben.

=== Vorteil gegenüber einem CUL/FHEMduino ===
Ein großer Vorteil des SIGNALduino besteht darin, dass auch Geräte mit leicht abweichende Frequenzen steuerbar sind; so empfangen die Somfy-Rolladenmotoren beispielsweise auf 433.42 und nicht, wie bei anderen Geräten sehr oft üblich, auf 433.92 MHz. Die Frequenzumstellung stellt für den SIGNALduino kein Problem dar.

Der SIGNALduino hat den Vorteil einer sehr schnellen Demodulation des Funksignals. Sollen weitere Protokolle dekodiert werden, so muss dazu nur ein passendes FHEM Modul entwickelt oder ein universelles Modul erweitert werden. Änderungen am Arduino-Code sind normalerweise nicht notwendig.

Ebenso kann man den SIGNALduino direkt an den Sendeausgang eines Sensors anbinden und die digitalen Signale empfangen, dabei bitte aber auf die passenden Spannungen achten, denn ein Arduino Nano verträgt nur 5V.

== Hardware ==

Der SIGNALduino (Hardware) wird über den USB Port angeschlossen, er kann aber auch mit zusätzlichen ESP Modulen über ein WLAN angebunden werden.

Der SIGNALduino basiert auf einem [http://arduino.cc/de/Main/ArduinoBoardNano Arduino Nano], die Schaltung entspricht der des [[FHEMduino]] oder dem [[Selbstbau_CUL]]:
* Entweder wird ein Arduino mit einfachen Sende- und Empfangsmodulen verwendet, dann ist die Verkabelung identisch zum [[FHEMduino]]
* Oder es wird ein CC1101 Transceiver verwendet, dann ist die Verkabelung identisch zum [[Selbstbau_CUL]].
* Zuletzt gibt ein fertig konfektionierte Modul von In-Circuit mit Radino CC1101 Varianten, link zum [http://shop.in-circuit.de/index.php Hersteller].

Achten Sie beim Selbstbau auf die entsprechenden Sender-Empfänger. Der sehr preiswert angebotene XY-MK-5V hat sich als zu unzuverlässig erwiesen, während anscheinend beim CC1101 (insbesondere der "grünen Version") keine Probleme auftreten.

Es stehen auch für den [https://www.arduino.cc/en/Main/arduinoBoardUno UNO] und [https://www.arduino.cc/en/Main/ArduinoBoardProMini PRO Mini] Firmware-Dateien zur Verfügung. Die ausgelieferte Firmware läuft nur auf Mikrocontrollern mit 16 Mhz; wer einen Mikrocontroller mit 8 Mhz verwenden möchte, muss die Firmware selbst compilieren.

Es gibt auch eine Variante des SIGNALduino, die auf einem [[ESP8266]] nativ läuft, diese funktioniert derzeit aber noch nicht zufiedenstellend. Das Modul wird derzeit (2017) stetig weiterentwickelt.

=== Einfache Module ===

[[Datei:Fhemduino_schematic.png|200px|thumb|right|Beispielschaltplan SIGNAL(FHEM)duino]]

Mit einem Arduino-Nano und folgenen, billigen Sende- und Empfangsmodulen können Sie einen SIGNALduino bauen:
* FS1000A Dies ist das Sendemodul (TX) und wird oft im Set mit dem billigen XY-MK-5V-Empfänger angeboten (etwa 5€).
* RXB6 Das ist das empfohlene Emfpangsmodul (RX), statt XY-MK-5V, etwa 5€ aus Deutschland.

Die Verkabelung erfolgt analog zum [[FHEMduino]] und das bedeutet (Arduino-> Modul):
* PIN D2 an DATA des RX-Moduls
* PIN D11 an DATA des TX-Moduls (PIN links mit Beschriftung ATAD)

Zusätzlich muss noch jeweils GND und 5V des Arduino mit dem GND bzw. VCC des Moduls verbunden werden.

Jetzt fehlen noch die Antennen. Dafür braucht man ein 17,2 cm langes Stück Kupferdraht, das wird beim Anschluss "ANT" jeweils am Modul angelötet (anfängergeeignet).

== Software: Modul ==

=== USB-ID ermitteln ===
Bevor der SIGNALduino mit dem FHEM Server (im Beispiel hier ein Raspberry PI) angeschlossen werden kann, muss die USB-Schnittstelle ermittelt werden. Hierzu bitte auf dem Terminal den Befehl
<pre> ls -l /dev/serial/by-id </pre>
ausführen. Beispielhaft sieht das Ergebnis etwa so aus:
''lrwxrwxrwx 1 root root 13 Jan 31 00:02 '''usb-FTDI_FT232R_USB_UART_A903N5T5-if00-port''' -> ../../ttyUSB0''
Damit ist der Anschluss des SIGNALduino bestimmt und das Gerät kann wie im nächsten Abschnitt beschrieben definiert werden. Zuvor muss noch das Modul geladen werden.

=== FHEM-Modul laden ===
Die SIGNALduino Module werden über das FHEM [[update]] verteilt.

Die in der Entwicklung befindliche Version kann mit folgenden Befehlen geladen werden:

* FHEM aktualisieren: <code>update</code>
* SIGNALduino Modul und Firmware aktualisieren: <code>update all <nowiki>https://raw.githubusercontent.com/RFD-FHEM/RFFHEM/dev-r33/controls_signalduino.txt</nowiki></code> Durch das Update von FHEM wird sichergestellt, dass das Modul mit FHEM arbeitet. Außerdem wird auch die Firmware geladen, im Log-File sieht man, wo diese hinkopiert wurden: z.B. nach FHEM/firmware/SIGNALduino_nano328.hex
*Danach kann das Gerät wie folgt definiert werden (die Spezifikation des USB Anschlusses muss dabei an die aktuellen Gegebenheiten angepasst werden):
:<code>define <eigener-SIGNALduino-Name> SIGNALduino /dev/serial/by-id/usb-FTDI_FT232R_USB_UART_A903N5T5-if00-port0@57600</code>
Nach dem Einbinden wird der SIGNALduino, falls er erkannt wird, im Status "Opened" angezeigt.

Für neuere Entwicklungen kann in FHEM auch dauerhaft die developer Version aktualisiert werden:
<code>update add <nowiki>https://raw.githubusercontent.com/RFD-FHEM/RFFHEM/dev-r33/controls_signalduino.txt</nowiki></code>
Danach wird FHEM bei dem normalen Update-Befehl immer automatisch die aktuelle dev Version laden.

Die nachfolgenden Beispiel-Befehle verwenden "sduino" als <eigener-SIGNALduino-Name>.

==== Flashen des Ardunio mit der SIGNALduino Firmware ====
Falls avrdude noch nicht vorhanden ist, kann es mit folgendem Befehl installiert werden:
:<code>sudo apt-get install avrdude</code>

In FHEM ist der SIGNALduino mit dem Status "Open" vorhanden. Jetzt müssen wir FHEM noch mitteilen, welche Hardware wir angeschlossen haben. Über das Attribut ''hardware'' lässt sich zwischen den mitgelieferten Firmware-Dateien wechseln. Solltet ihr einen Nano mit cc1101 Transreceiver verwenden, so wählt bitte folgende Hardware
<code>attr sduino hardware nanoCC1101</code>
sonst üblicherweise
<code>attr sduino hardware nano328</code>

Anschließend kann der ''flash'' Befehl abgesetzt werden:
<code>set sduino flash </code>
Dadurch wird der Arduino mit der gewählten Firmware geflasht. Das Ergebnis wird im Webinterface direkt angezeigt.

Alternativ kann auch der Flash-Befehl mit einem Dateinamen aufgerufen werden. Diese Möglichkeit sollte jedoch nur verwendet werden, wenn die SIGNALduino Firmware selbst compiliert wurde und eine andere Hardware verwendet wird. Der Flash-Befehl wird wie folgt aufgerufen:
:<code>set sduino flash FHEM/firmware/SIGNALduino_mega2560.hex</code>
(je nachdem wo und unter welchem Namen die .hex Datei abgelegt wurde)

==== Flashen eines radino Boards mit ATmega32U4 ====

Diese Funktion steht nur in der Entwicklungsversion dev-r33 zur Verfügung:
Das Radino Board muss derzeit noch mit Angabe des Dateinamens geflasht werden:
<code>set sduino flash FHEM/firmware/SIGNALDuino_radinoCC1101.hex</code>

Auch sind berichte bekannt, dass der Radino beim Neustart von FHEM nicht korrekt initalisiert wird.

=== Geräteerkennung ===
==== Unterstützte Geräte ====
Für die folgenden Geräte gibt es derzeit (2017) eine Unterstützung für den Betrieb mit FHEM. Die Geräte werden [[autocreate|automatisch erkannt]] und in der Konfiguration eingetragen, wenn der SIGNALduino läuft.
{|class="wikitable"
! style="text-align:left;"| Produkt
! (E)mpfangen (S)enden
! Hinweise
! Verwendetes Modul
! Protokoll ID
|-
|TCM Wetterstation (97001 und 21xxx Serie)||E|| || CUL_TCM97001 || 0
|-
|ABS Wetterstation (ABS 700)||E|| || CUL_TCM97001 || 0
|-
|Prologue Wetterstation ||E|| ||CUL_TCM97001 || 0
|-
|Rubicson Wetterstation ||E|| ||CUL_TCM97001 ||0
|-
|NC_WS Wetterstation ||E|| ||CUL_TCM97001 || 0
|-
|[http://www.gt-support.de/ GT-WT-02 Wetterstation]||E|| ||CUL_TCM97001 || 0
|-
|AURIOL Wetterstation ||E|| ||CUL_TCM97001 || 0
|-
|Mebus Wetterstation ||E|| ||CUL_TCM97001 || 0
|-
|Intertechno Funkschalter||E S|| ||IT || 3,4,5,17
|-
|<strike>Conrad RSL Funkschalter</strike>||E S|| Funktioniert aktuell nicht || SIGNALduino_RSL ||
|-
|[http://global.oregonscientific.com/product_view.php?id=5 Oregon Scientific Wettersensoren]||E || Protokoll V2 & V3 implementiert || OREGON || 10
|-
|Bresser Temp/Hydro Sensor||E || || Hideki || 12
|-
|[https://de.hama.com/00104985/hama-aussensensor-ts33c-fuer-wetterstation Hama TS33C]||E || || Hideki || 12
|-
|TFA Temp/Hydro Sensor||E || || Hideki || 12
|-
|Lacrosse TX2/TX3 Sensoren||E || || CUL_TX || 8
|-
|TFA 30320902||E || || SD_WS07 || 7
|-
|Eurochon eas800z||E || || SD_WS07 || 7
|-
|Technoline WS6750/TX70DTH||E || || SD_WS07 || 7
|-
|FreeTec Außenmodul NC-7344||E || || SD_WS07 || 7
|-
|CTW600||E || || SD_WS09 || 9
|-
|WH1080||E || || SD_WS09 || 9
|-
|Visivon remote pt4450||E || || none || 24
|-
|Einhel HS 434/6||E || || none || 21
|-
|Flamingo FA20RF / FA21RF Rauchmelder||E || || none || 13
|-
|mumbi m-FS300||E || || none || 26,27
|-
|TFA 30.3200||E || || none || 33
|-
|Livolo||E|| || none || 20
|-
|Smartwares SH5-TSO-A||E S|| || IT || ?
|-
|X10 Security Devices||E|| || || 39
|-
|[[Somfy_via_SIGNALduino|Somfy RTS]]||E S|| || SOMFY || 43
|}
Bei einigen Intertechno-Funksteckdosen (Brennenstuhl) kann es zu Empfangsproblemen kommen. Hier muss die Taktrate, mit der gesendet wird, angepasst werden. Dazu muss für Funksteckdose das Attribut
:<code>attr <Funksteckdose> ITclock 300</code>
gesetzt werden, der Standardwert ist 250.

==== Mein Gerät wird in FHEM nicht erkannt ====
1. Prüfen, ob vom Sensor die Signaldaten (verbose >=4) erkannt werden. Sobald ihr die empfangenen Signaldaten im Logfile zuordnen könnt, geht es weiter mit:

2. Eröffnet ein Thema unter [https://github.com/RFD-FHEM/RFFHEM/issues github] nach folgendem Muster:
:''Thema : Protokoll für <Das verwendete Gerät>
:Inhalt: Eure Hardware z.B. Arduino Nano mit XYZ Empfänger, oder Arduino Nano direkt an Gerät x

3. Auszug aus dem Logfile, welches zum Gerät gehört.
:''Alles was ihr sonst noch über das Gerät und die übertragenen Daten wisst.

Alternativ könnt ihr auch im Forum posten. Um einzelne Erweiterungen besser im Überblick zu behalten, eignet sich das github jedoch besser.

==== Es wird ein Protokoll erkannt, Autocreate legt aber kein device an ====
Im SIGNALduino sind >30 Protokolle implementiert. Jedoch gibt es nur wenige Module, welche diese Protokolle verarbeiten.
Teilweise ist das auch nicht zwingend notwendig, um seine Anforderungen zu erfüllen. Insbesondere für Schalter bzw. Sensoren, die nur zwei Zustände kennen, geht es meist ohne Modul und automatisch angelegtem Gerät.

Nehmen wir an, wir haben einen Schalter. Dieser kann einen oder zwei Zustände senden.
Im FHEM Log tauchen Meldungen ähnlich dieser auf

<code>
2015.11.15 15:52:23 4: SIGNALduino_unknown incomming msg: u85#FF8081
</code>

Wir können mit Hilfe des Modules DOIF auf diese Nachricht eine Aktion ausführen:

Entweder, wenn wir den Inhalt der Nachricht nur zu teilen wissen, da er sich ändert:
<code>
define mydoif DOIF ([sduino:&DMSG] =~ "u85#FF8081") (set Lamp on)
attr mydoif do always
</code>

Oder, wenn wir den Inhalt exakt kennen, dann auch als Vergleichsstring
<code>
define mydoif DOIF ([sduino:&DMSG] eq "u85#FF8081") (set relais on)
attr mydoif do always
</code>

Der Teil u85#FF8081 muss individuell angepasst werden, der Name eures SIGNALduino möglicherweise auch.

=== Der Logfile ===
Im Logfile ab [[Verbose]] 4 tauchen diverse Meldungen auf, deren Bedeutung kurz erläutert wird (verbose 3 unterdrückt diese Meldungen):

"Unknown Code" bedeutet, dass der SIGNALduino Signaldaten empfangen und diese binär interpretiert hat. Diese Meldung soll uns nun aber mitteilen, dass es dann nicht weiter verarbeitet werden kann, da kein Modul existiert, welches diese Daten jetzt in ihre Bedeutung umwandeln kann.
:<code>sduino: Unknown code u1FFFFF0, help me!</code>

Mittlerweile sind über 50 Protokolle für den SIGNALduino definiert. Dadurch kommt es vor, dass sich ein Signal mit mehr als einem Protokoll demodulieren lässt. Meist führt dies dann zu zusätzlichen "Unknown code"-Einträgen.

Derartige Einträge können mit dem Attribut WhitelistID minimiert werden. Dabei werden die Geräte, empfangen werden sollen, mit ihrer Protokollnummer in die WhitelistID aufgenommen. Die Protokollnummer kann der obigen Tabelle entnommen werden (hilfreich ist es auch, wenn in den verwendeten Geräten im Internal <gerätename>_DMSG nachgesehen wird). So bedeutet beispielsweise ein Eintrag der Form <code>W50#FF553335FFBC</code> dass dann das Protokoll #50 in die Whitelist aufzunehmen wäre (<code>attr sduino Whitelist_IDs 50</code>).

Es erscheinen viele Meldungen dieser Art:

<pre>
Fingerprint for MU Protocol id xxxx -> yyy matches, trying to demodulate
sduino: Starting demodulation at Position 1
Fingerprint for MU Protocol id 28 -> IC Ledspot matches, trying to demodulate
sduino: Starting demodulation at Position 1
Fingerprint for MU Protocol id 29 -> HT12e remote matches, trying to demodulate
</pre>

Die Protokolle können wie folgt unterschieden werden:

*MS - Nachricht mit Sync Puls: Hierzu ein Beispiel
:<code>MS;P0=-108;P1=395;P2=-1033;P3=-547;P4=-19932;P5=-8916;P6=1368;D=151313131312131313131313131313131312121212121313131313131312131212132;CP=1;SP=5;</code> P0-P6 sind die Signalpegel (Dauer und positiv/negativ). Hinter D= befindet sich die Abfolge der Signale. Die ersten beiden Ziffern 15 in D sind wie folgt zu lesen. Zuerst wurde ein Signal mit 395 Mikrosekunden high (die Zeitdauer ergibt sich aufgrund der Mitteilung "P1=395") und anschließend ein Signal 8916 Mikrosekunden low (die Zeitdauer ergibt sich aufgrund der Mitteilung "P5=-8916") gemessen. CP=1 ist die Referenz auf den Takt des Signales, der Basistakt ist in diesem Fall ~395 Mikrosekunden. SP=5 gibt die Referenz zum Syncpuls an, der das gesamte Signal einleitet. Welche Signalfolge nun eine binäre 1 bzw. 0 bedeutet, wird im SIGNALduino über die integrierte Protokoll Liste realisiert.

*MC - Nachricht vom Typ Manchester: Manchesterkodierte Signale können bereits sehr einfach im Arduino in eine Binärform umgewandelt werden. Es wird hier nach IEEE 802.3 umgewandelt. In Manchester Signalen gibt es lange und kurze Pulse. Deren Durchschnittswert wird mit LL (long low), LH (long high), SL (short low) und SH (short high) übermittelt. Zusätzlich, um das Protokoll schneller erkennen zu können, wird die Taktfrequenz mit übermittelt (C=429 Mikrosekunden). Die Daten befinden sich hinter D= und werden in HEX Form übergeben.
:<code>MC;LL=-1066;LH=904;SL=-562;SH=385;D=332B4B4D54D5554B552CD2D554B2B5354A;C=429;</code>

*MU - Message unsynced: Diese Art von Nachrichten, sind nicht nach Manchester codiert und haben auch keinen erkennbaren Sync / Clock Signalpegel am Start der Nachricht. Bei diesen Nachrichtentypen ist es, im Vergleich zu den anderen, am wahrscheinlichsten, dass das übermittelte Signal unvollständig oder überhaupt kein Signal ist. Wie bei MS sind P0-P6 die Signalpegel und in D= wird die Abfolge der Signalpegel referenziert. CP=2 gibt auch hier die Referenz zum Takt an, allerdings muss dieser nicht korrekt erkannt worden sein.
:<code>MU;P0=1372;P1=-580;P2=362;P3=-1047;D=01212321212321212121212121212123212123212321232121212121212321;CP=2;</code>

Dennoch kommt es gehäuft zu Logmeldungen und auch Events in ähnlicher Form:
:<code>SIGNALduino_unknown incomming msg: u85#FF8081</code>

Das Attribut ''whitelistIDs'' erlaubt es, anzugeben, welche Protokolle vom FHEM Modul berücksichtigt werden. Für Protokolle, die nicht berücksichtigt werden, gibt es weder Logeinträge noch Events. Diese werden im Programmablauf nicht berücksichtigt. Das spart zum einen Ressourcen und trägt auch zur Übersichtlichkeit bei. Die Angabe erfolgt durch Komma getrennt: z.B.:
:<code>1,2,5,10</code>

=== Senden mit dem SIGNALduino ===
Der SIGNALduino kann etwas "raw senden", indem ihm das SIGNAL so übermittelt wird, wie er es moduliert. Hierzu muss der Befehl wie folgt eingegeben werden:

<code>
set sduino sendMsg P3#00111010#R4
</code>

Dieser Befehl moduliert die Bitfolge 00111010 mittels Protokoll #3 und wiederholt die Nachricht 4x.
Die Protokoll Nummer kann aus einer empfangenen Nachricht extrahiert werden. Ebenso die Bits.
<code>
sduino: extracted data 00111010 (bin)
sduino: Found Protocol id 3
</code>

Alternativ kann das Signal auch in einer "rohform" angegeben werden. Dies ist manchmal in speziellen Fällen notwendig:
<code>
set sduino raw SR;;R=3;;P0=4742;;P1=-1554;;P2=286;;P3=-786;;P4=649;;P5=-420;;D=0123234545234545452323232323454523234523454523232345454523232323452345234523452345;;
</code>

R=3 bedeutet, das Signal wird 3x gesendet.
Die Übertragung besteht aus den in D angegeben Pulsen, welche in P0-P5 definiert werden.
Die Daten kann man aus einer empfangenen MS oder MU Nachricht extrahieren.

Alternativ kann ab Version 3.2 auch eine vereinfachte Form eingegeben werden.

== Fehlerbehandlung ==
Der SIGNALduino kann mit folgendem Befehl auf Werkseinstellungen zurückgesetzt werden:
:<code>get raw e</code>
als Antwort kommt dann "ccFactoryReset done". Ob ein solcher Reset nötig ist, erkennt man an der Antwort auf den Befehl "get config", auf den dann die Meldung "config: MS=1;MU=1;MC=1" folgen sollte.

In der Firmware sind die folgenden Befehle eingebaut

*:<code>get raw C<reg></code>
<reg> is a (two digit) hex number: return the value of the cc1101 register. <reg>=99 dumps the first 48 registers.
Example: C35 -> C35 = 0D
*:<code>get raw e</code>
EEPROM / factory reset. resets all eeprom values without reboot
*:<code>get raw r<AA></code>
Read eeprom (da das "R" beim SIGNALDuino bereits mit freeram belegt ist, habe ich das "r" verwendet)
*:<code>get raw r<AA>n</code>
Read 16 byte from eeprom (z.B. r00n)
*:<code>get raw W<AA><DD></code>
Write eeprom (schreibt einen Wert ins EEPROM und ins CC1101 Register. Die eeprom Adresse hat einen Offset von 2. z.B W041D schreibt 1D ins Register 2)

Die Sendeleistung lässt sich mit
:<code>get sduino ccreg 3E</code>

prüfen, wobei die Rückmeldung wie folgt zu lesen ist:
"-10_dBm" => '34',
"-5_dBm" => '68',
"0_dBm" => '60',
"5_dBm" => '84',
"7_dBm" => 'C8',
"10_dBm" => 'C0'
Dabei wird die Sendeleistung dauerhaft mit dem Befehl
:<code>set sduino cc1101_patable <value></code>
hochgeschaltet (<value> durch den Wert ersetzen).

Weitere Firmware-Befehle sind im Thread-Beitrag {{Link2Forum|Topic=58396|Message=497921}} zu finden.

== Foren Links ==
* {{Link2Forum|Topic=38402|LinkText=Forenthread - Ankündigung}}
* {{Link2Forum|Topic=58396|LinkText=SIGNALDuino Empfänger Firm- und Hardware}}
* {{Link2Forum|Topic=58397|LinkText=Signalduino Entwicklung Version 3.3.1 }}
* [http://www.nemcon.nl/blog2/wiring Beschreibung zu diversen Empfängern und Verbesserung der Empfangsleistung]
* [[SIGNALduino in die Arduino Entwicklungsumgebung einbinden]]
* [[Somfy via SIGNALduino]]

[[Kategorie:Interfaces]]
[[Kategorie:Arduino]]

SIGNALduino

2017-11-15T10:13:20Z

Hmcontrol: Bau des SIGNALduino mit einfachen Modulen erweitert.

{{Infobox Modul
|ModPurpose=Empfang und Verarbeitung von digitalen Signalen
|ModType=d
|ModFTopic=38402
|ModCmdRef=SIGNALduino
|ModForumArea=Sonstige Systeme
|ModTechName=00_SIGNALduino.pm
|ModOwner=Sidey ({{Link2FU|8018|Forum}}/[[Benutzer Diskussion:Sidey|Wiki]])
}}

== Einleitung ==
=== Übersicht ===
Unter den Namen SIGNALduino versteht man sowohl den Low-Cost Empfänger für digitale Signale (vergleichbar dem [[CUL]]) als auch das gleichnamige Modul mit dem Dateinamen 00_SIGNALduino.pm. Mit dem SIGNALduino kann man entweder 433 oder 868 MHz-Geräte auslesen und ansprechen. Der SIGNALduino funktioniert auch mit anderen Medien wie Infrarot oder direkter Kabelverbindung.

Der SIGNALduino erkennt Signale anhand von Mustern und gibt sie an FHEM zur Auswertung (Dekodierung) weiter. Auch nicht erkannte Signale werden an FHEM übergeben.

=== Vorteil gegenüber einem CUL/FHEMduino ===
Ein großer Vorteil des SIGNALduino besteht darin, dass auch Geräte mit leicht abweichende Frequenzen steuerbar sind; so empfangen die Somfy-Rolladenmotoren beispielsweise auf 433.42 und nicht, wie bei anderen Geräten sehr oft üblich, auf 433.92 MHz. Die Frequenzumstellung stellt für den SIGNALduino kein Problem dar.

Der SIGNALduino hat den Vorteil einer sehr schnellen Demodulation des Funksignals. Sollen weitere Protokolle dekodiert werden, so muss dazu nur ein passendes FHEM Modul entwickelt oder ein universelles Modul erweitert werden. Änderungen am Arduino-Code sind normalerweise nicht notwendig.

Ebenso kann man den SIGNALduino direkt an den Sendeausgang eines Sensors anbinden und die digitalen Signale empfangen, dabei bitte aber auf die passenden Spannungen achten, denn ein Arduino Nano verträgt nur 5V.

== Hardware ==

Der SIGNALduino (Hardware) wird über den USB Port angeschlossen, er kann aber auch mit zusätzlichen ESP Modulen über ein WLAN angebunden werden.

Der SIGNALduino basiert auf einem [http://arduino.cc/de/Main/ArduinoBoardNano Arduino Nano], die Schaltung entspricht der des [[FHEMduino]] oder dem [[Selbstbau_CUL]]:
* Entweder wird ein Arduino mit einfachen Sende- und Empfangsmodulen verwendet, dann ist die Verkabelung identisch zum [[FHEMduino]]
* Oder es wird ein CC1101 Transceiver verwendet, dann ist die Verkabelung identisch zum [[Selbstbau_CUL]].
* Zuletzt gibt ein fertig konfektionierte Modul von In-Circuit mit Radino CC1101 Varianten, link zum [http://shop.in-circuit.de/index.php Hersteller].

Achten Sie beim Selbstbau auf die entsprechenden Sender-Empfänger. Der sehr preiswert angebotene XY-MK-5V hat sich als zu unzuverlässig erwiesen, während anscheinend beim CC1101 (insbesondere der "grünen Version") keine Probleme auftreten.

Es stehen auch für den [https://www.arduino.cc/en/Main/arduinoBoardUno UNO] und [https://www.arduino.cc/en/Main/ArduinoBoardProMini PRO Mini] Firmware-Dateien zur Verfügung. Die ausgelieferte Firmware läuft nur auf Mikrocontrollern mit 16 Mhz; wer einen Mikrocontroller mit 8 Mhz verwenden möchte, muss die Firmware selbst compilieren.

Es gibt auch eine Variante des SIGNALduino, die auf einem [[ESP8266]] nativ läuft, diese funktioniert derzeit aber noch nicht zufiedenstellend. Das Modul wird derzeit (2017) stetig weiterentwickelt.

=== Einfache Module ===

[[Datei:Fhemduino_schematic.png|200px|thumb|right|Beispielschaltplan SIGNAL(FHEM)duino]]

Mit einem Arduino-Nano und folgenen, billigen Sende- und Empfangsmodulen können Sie einen SIGNALduino bauen:
* FS1000A Dies ist das Sendemodul (TX) und wird oft im Set mit dem billigen XY-MK-5V-Empfänger angeboten (etwa 5€).
* RXB6 Das ist das empfohlene Emfpangsmodul (RX), statt XY-MK-5V, etwa 5€ aus Deutschland.

Die Verkabelung erfolgt analog zum [[FHEMduino]] und das bedeutet (Arduino-> Modul):
* PIN D2 an DATA des RX-Moduls
* PIN D11 an DATA des TX-Moduls (PIN in der Mitte)

Zusätzlich muss noch jeweils GND und 5V des Arduino mit dem GND bzw. VCC des Moduls verbunden werden.

Jetzt fehlen noch die Antennen. Dafür braucht man ein 17,2 cm langes Stück Kupferdraht, das wird beim Anschluss "ANT" jeweils am Modul angelötet (anfängergeeignet).

== Software: Modul ==

=== USB-ID ermitteln ===
Bevor der SIGNALduino mit dem FHEM Server (im Beispiel hier ein Raspberry PI) angeschlossen werden kann, muss die USB-Schnittstelle ermittelt werden. Hierzu bitte auf dem Terminal den Befehl
<pre> ls -l /dev/serial/by-id </pre>
ausführen. Beispielhaft sieht das Ergebnis etwa so aus:
''lrwxrwxrwx 1 root root 13 Jan 31 00:02 '''usb-FTDI_FT232R_USB_UART_A903N5T5-if00-port''' -> ../../ttyUSB0''
Damit ist der Anschluss des SIGNALduino bestimmt und das Gerät kann wie im nächsten Abschnitt beschrieben definiert werden. Zuvor muss noch das Modul geladen werden.

=== FHEM-Modul laden ===
Die SIGNALduino Module werden über das FHEM [[update]] verteilt.

Die in der Entwicklung befindliche Version kann mit folgenden Befehlen geladen werden:

* FHEM aktualisieren: <code>update</code>
* SIGNALduino Modul und Firmware aktualisieren: <code>update all <nowiki>https://raw.githubusercontent.com/RFD-FHEM/RFFHEM/dev-r33/controls_signalduino.txt</nowiki></code> Durch das Update von FHEM wird sichergestellt, dass das Modul mit FHEM arbeitet. Außerdem wird auch die Firmware geladen, im Log-File sieht man, wo diese hinkopiert wurden: z.B. nach FHEM/firmware/SIGNALduino_nano328.hex
*Danach kann das Gerät wie folgt definiert werden (die Spezifikation des USB Anschlusses muss dabei an die aktuellen Gegebenheiten angepasst werden):
:<code>define <eigener-SIGNALduino-Name> SIGNALduino /dev/serial/by-id/usb-FTDI_FT232R_USB_UART_A903N5T5-if00-port0@57600</code>
Nach dem Einbinden wird der SIGNALduino, falls er erkannt wird, im Status "Opened" angezeigt.

Für neuere Entwicklungen kann in FHEM auch dauerhaft die developer Version aktualisiert werden:
<code>update add <nowiki>https://raw.githubusercontent.com/RFD-FHEM/RFFHEM/dev-r33/controls_signalduino.txt</nowiki></code>
Danach wird FHEM bei dem normalen Update-Befehl immer automatisch die aktuelle dev Version laden.

Die nachfolgenden Beispiel-Befehle verwenden "sduino" als <eigener-SIGNALduino-Name>.

==== Flashen des Ardunio mit der SIGNALduino Firmware ====
Falls avrdude noch nicht vorhanden ist, kann es mit folgendem Befehl installiert werden:
:<code>sudo apt-get install avrdude</code>

In FHEM ist der SIGNALduino mit dem Status "Open" vorhanden. Jetzt müssen wir FHEM noch mitteilen, welche Hardware wir angeschlossen haben. Über das Attribut ''hardware'' lässt sich zwischen den mitgelieferten Firmware-Dateien wechseln. Solltet ihr einen Nano mit cc1101 Transreceiver verwenden, so wählt bitte folgende Hardware
<code>attr sduino hardware nanoCC1101</code>
sonst üblicherweise
<code>attr sduino hardware nano328</code>

Anschließend kann der ''flash'' Befehl abgesetzt werden:
<code>set sduino flash </code>
Dadurch wird der Arduino mit der gewählten Firmware geflasht. Das Ergebnis wird im Webinterface direkt angezeigt.

Alternativ kann auch der Flash-Befehl mit einem Dateinamen aufgerufen werden. Diese Möglichkeit sollte jedoch nur verwendet werden, wenn die SIGNALduino Firmware selbst compiliert wurde und eine andere Hardware verwendet wird. Der Flash-Befehl wird wie folgt aufgerufen:
:<code>set sduino flash FHEM/firmware/SIGNALduino_mega2560.hex</code>
(je nachdem wo und unter welchem Namen die .hex Datei abgelegt wurde)

==== Flashen eines radino Boards mit ATmega32U4 ====

Diese Funktion steht nur in der Entwicklungsversion dev-r33 zur Verfügung:
Das Radino Board muss derzeit noch mit Angabe des Dateinamens geflasht werden:
<code>set sduino flash FHEM/firmware/SIGNALDuino_radinoCC1101.hex</code>

Auch sind berichte bekannt, dass der Radino beim Neustart von FHEM nicht korrekt initalisiert wird.

=== Geräteerkennung ===
==== Unterstützte Geräte ====
Für die folgenden Geräte gibt es derzeit (2017) eine Unterstützung für den Betrieb mit FHEM. Die Geräte werden [[autocreate|automatisch erkannt]] und in der Konfiguration eingetragen, wenn der SIGNALduino läuft.
{|class="wikitable"
! style="text-align:left;"| Produkt
! (E)mpfangen (S)enden
! Hinweise
! Verwendetes Modul
! Protokoll ID
|-
|TCM Wetterstation (97001 und 21xxx Serie)||E|| || CUL_TCM97001 || 0
|-
|ABS Wetterstation (ABS 700)||E|| || CUL_TCM97001 || 0
|-
|Prologue Wetterstation ||E|| ||CUL_TCM97001 || 0
|-
|Rubicson Wetterstation ||E|| ||CUL_TCM97001 ||0
|-
|NC_WS Wetterstation ||E|| ||CUL_TCM97001 || 0
|-
|[http://www.gt-support.de/ GT-WT-02 Wetterstation]||E|| ||CUL_TCM97001 || 0
|-
|AURIOL Wetterstation ||E|| ||CUL_TCM97001 || 0
|-
|Mebus Wetterstation ||E|| ||CUL_TCM97001 || 0
|-
|Intertechno Funkschalter||E S|| ||IT || 3,4,5,17
|-
|<strike>Conrad RSL Funkschalter</strike>||E S|| Funktioniert aktuell nicht || SIGNALduino_RSL ||
|-
|[http://global.oregonscientific.com/product_view.php?id=5 Oregon Scientific Wettersensoren]||E || Protokoll V2 & V3 implementiert || OREGON || 10
|-
|Bresser Temp/Hydro Sensor||E || || Hideki || 12
|-
|[https://de.hama.com/00104985/hama-aussensensor-ts33c-fuer-wetterstation Hama TS33C]||E || || Hideki || 12
|-
|TFA Temp/Hydro Sensor||E || || Hideki || 12
|-
|Lacrosse TX2/TX3 Sensoren||E || || CUL_TX || 8
|-
|TFA 30320902||E || || SD_WS07 || 7
|-
|Eurochon eas800z||E || || SD_WS07 || 7
|-
|Technoline WS6750/TX70DTH||E || || SD_WS07 || 7
|-
|FreeTec Außenmodul NC-7344||E || || SD_WS07 || 7
|-
|CTW600||E || || SD_WS09 || 9
|-
|WH1080||E || || SD_WS09 || 9
|-
|Visivon remote pt4450||E || || none || 24
|-
|Einhel HS 434/6||E || || none || 21
|-
|Flamingo FA20RF / FA21RF Rauchmelder||E || || none || 13
|-
|mumbi m-FS300||E || || none || 26,27
|-
|TFA 30.3200||E || || none || 33
|-
|Livolo||E|| || none || 20
|-
|Smartwares SH5-TSO-A||E S|| || IT || ?
|-
|X10 Security Devices||E|| || || 39
|-
|[[Somfy_via_SIGNALduino|Somfy RTS]]||E S|| || SOMFY || 43
|}
Bei einigen Intertechno-Funksteckdosen (Brennenstuhl) kann es zu Empfangsproblemen kommen. Hier muss die Taktrate, mit der gesendet wird, angepasst werden. Dazu muss für Funksteckdose das Attribut
:<code>attr <Funksteckdose> ITclock 300</code>
gesetzt werden, der Standardwert ist 250.

==== Mein Gerät wird in FHEM nicht erkannt ====
1. Prüfen, ob vom Sensor die Signaldaten (verbose >=4) erkannt werden. Sobald ihr die empfangenen Signaldaten im Logfile zuordnen könnt, geht es weiter mit:

2. Eröffnet ein Thema unter [https://github.com/RFD-FHEM/RFFHEM/issues github] nach folgendem Muster:
:''Thema : Protokoll für <Das verwendete Gerät>
:Inhalt: Eure Hardware z.B. Arduino Nano mit XYZ Empfänger, oder Arduino Nano direkt an Gerät x

3. Auszug aus dem Logfile, welches zum Gerät gehört.
:''Alles was ihr sonst noch über das Gerät und die übertragenen Daten wisst.

Alternativ könnt ihr auch im Forum posten. Um einzelne Erweiterungen besser im Überblick zu behalten, eignet sich das github jedoch besser.

==== Es wird ein Protokoll erkannt, Autocreate legt aber kein device an ====
Im SIGNALduino sind >30 Protokolle implementiert. Jedoch gibt es nur wenige Module, welche diese Protokolle verarbeiten.
Teilweise ist das auch nicht zwingend notwendig, um seine Anforderungen zu erfüllen. Insbesondere für Schalter bzw. Sensoren, die nur zwei Zustände kennen, geht es meist ohne Modul und automatisch angelegtem Gerät.

Nehmen wir an, wir haben einen Schalter. Dieser kann einen oder zwei Zustände senden.
Im FHEM Log tauchen Meldungen ähnlich dieser auf

<code>
2015.11.15 15:52:23 4: SIGNALduino_unknown incomming msg: u85#FF8081
</code>

Wir können mit Hilfe des Modules DOIF auf diese Nachricht eine Aktion ausführen:

Entweder, wenn wir den Inhalt der Nachricht nur zu teilen wissen, da er sich ändert:
<code>
define mydoif DOIF ([sduino:&DMSG] =~ "u85#FF8081") (set Lamp on)
attr mydoif do always
</code>

Oder, wenn wir den Inhalt exakt kennen, dann auch als Vergleichsstring
<code>
define mydoif DOIF ([sduino:&DMSG] eq "u85#FF8081") (set relais on)
attr mydoif do always
</code>

Der Teil u85#FF8081 muss individuell angepasst werden, der Name eures SIGNALduino möglicherweise auch.

=== Der Logfile ===
Im Logfile ab [[Verbose]] 4 tauchen diverse Meldungen auf, deren Bedeutung kurz erläutert wird (verbose 3 unterdrückt diese Meldungen):

"Unknown Code" bedeutet, dass der SIGNALduino Signaldaten empfangen und diese binär interpretiert hat. Diese Meldung soll uns nun aber mitteilen, dass es dann nicht weiter verarbeitet werden kann, da kein Modul existiert, welches diese Daten jetzt in ihre Bedeutung umwandeln kann.
:<code>sduino: Unknown code u1FFFFF0, help me!</code>

Mittlerweile sind über 50 Protokolle für den SIGNALduino definiert. Dadurch kommt es vor, dass sich ein Signal mit mehr als einem Protokoll demodulieren lässt. Meist führt dies dann zu zusätzlichen "Unknown code"-Einträgen.

Derartige Einträge können mit dem Attribut WhitelistID minimiert werden. Dabei werden die Geräte, empfangen werden sollen, mit ihrer Protokollnummer in die WhitelistID aufgenommen. Die Protokollnummer kann der obigen Tabelle entnommen werden (hilfreich ist es auch, wenn in den verwendeten Geräten im Internal <gerätename>_DMSG nachgesehen wird). So bedeutet beispielsweise ein Eintrag der Form <code>W50#FF553335FFBC</code> dass dann das Protokoll #50 in die Whitelist aufzunehmen wäre (<code>attr sduino Whitelist_IDs 50</code>).

Es erscheinen viele Meldungen dieser Art:

<pre>
Fingerprint for MU Protocol id xxxx -> yyy matches, trying to demodulate
sduino: Starting demodulation at Position 1
Fingerprint for MU Protocol id 28 -> IC Ledspot matches, trying to demodulate
sduino: Starting demodulation at Position 1
Fingerprint for MU Protocol id 29 -> HT12e remote matches, trying to demodulate
</pre>

Die Protokolle können wie folgt unterschieden werden:

*MS - Nachricht mit Sync Puls: Hierzu ein Beispiel
:<code>MS;P0=-108;P1=395;P2=-1033;P3=-547;P4=-19932;P5=-8916;P6=1368;D=151313131312131313131313131313131312121212121313131313131312131212132;CP=1;SP=5;</code> P0-P6 sind die Signalpegel (Dauer und positiv/negativ). Hinter D= befindet sich die Abfolge der Signale. Die ersten beiden Ziffern 15 in D sind wie folgt zu lesen. Zuerst wurde ein Signal mit 395 Mikrosekunden high (die Zeitdauer ergibt sich aufgrund der Mitteilung "P1=395") und anschließend ein Signal 8916 Mikrosekunden low (die Zeitdauer ergibt sich aufgrund der Mitteilung "P5=-8916") gemessen. CP=1 ist die Referenz auf den Takt des Signales, der Basistakt ist in diesem Fall ~395 Mikrosekunden. SP=5 gibt die Referenz zum Syncpuls an, der das gesamte Signal einleitet. Welche Signalfolge nun eine binäre 1 bzw. 0 bedeutet, wird im SIGNALduino über die integrierte Protokoll Liste realisiert.

*MC - Nachricht vom Typ Manchester: Manchesterkodierte Signale können bereits sehr einfach im Arduino in eine Binärform umgewandelt werden. Es wird hier nach IEEE 802.3 umgewandelt. In Manchester Signalen gibt es lange und kurze Pulse. Deren Durchschnittswert wird mit LL (long low), LH (long high), SL (short low) und SH (short high) übermittelt. Zusätzlich, um das Protokoll schneller erkennen zu können, wird die Taktfrequenz mit übermittelt (C=429 Mikrosekunden). Die Daten befinden sich hinter D= und werden in HEX Form übergeben.
:<code>MC;LL=-1066;LH=904;SL=-562;SH=385;D=332B4B4D54D5554B552CD2D554B2B5354A;C=429;</code>

*MU - Message unsynced: Diese Art von Nachrichten, sind nicht nach Manchester codiert und haben auch keinen erkennbaren Sync / Clock Signalpegel am Start der Nachricht. Bei diesen Nachrichtentypen ist es, im Vergleich zu den anderen, am wahrscheinlichsten, dass das übermittelte Signal unvollständig oder überhaupt kein Signal ist. Wie bei MS sind P0-P6 die Signalpegel und in D= wird die Abfolge der Signalpegel referenziert. CP=2 gibt auch hier die Referenz zum Takt an, allerdings muss dieser nicht korrekt erkannt worden sein.
:<code>MU;P0=1372;P1=-580;P2=362;P3=-1047;D=01212321212321212121212121212123212123212321232121212121212321;CP=2;</code>

Dennoch kommt es gehäuft zu Logmeldungen und auch Events in ähnlicher Form:
:<code>SIGNALduino_unknown incomming msg: u85#FF8081</code>

Das Attribut ''whitelistIDs'' erlaubt es, anzugeben, welche Protokolle vom FHEM Modul berücksichtigt werden. Für Protokolle, die nicht berücksichtigt werden, gibt es weder Logeinträge noch Events. Diese werden im Programmablauf nicht berücksichtigt. Das spart zum einen Ressourcen und trägt auch zur Übersichtlichkeit bei. Die Angabe erfolgt durch Komma getrennt: z.B.:
:<code>1,2,5,10</code>

=== Senden mit dem SIGNALduino ===
Der SIGNALduino kann etwas "raw senden", indem ihm das SIGNAL so übermittelt wird, wie er es moduliert. Hierzu muss der Befehl wie folgt eingegeben werden:

<code>
set sduino sendMsg P3#00111010#R4
</code>

Dieser Befehl moduliert die Bitfolge 00111010 mittels Protokoll #3 und wiederholt die Nachricht 4x.
Die Protokoll Nummer kann aus einer empfangenen Nachricht extrahiert werden. Ebenso die Bits.
<code>
sduino: extracted data 00111010 (bin)
sduino: Found Protocol id 3
</code>

Alternativ kann das Signal auch in einer "rohform" angegeben werden. Dies ist manchmal in speziellen Fällen notwendig:
<code>
set sduino raw SR;;R=3;;P0=4742;;P1=-1554;;P2=286;;P3=-786;;P4=649;;P5=-420;;D=0123234545234545452323232323454523234523454523232345454523232323452345234523452345;;
</code>

R=3 bedeutet, das Signal wird 3x gesendet.
Die Übertragung besteht aus den in D angegeben Pulsen, welche in P0-P5 definiert werden.
Die Daten kann man aus einer empfangenen MS oder MU Nachricht extrahieren.

Alternativ kann ab Version 3.2 auch eine vereinfachte Form eingegeben werden.

== Fehlerbehandlung ==
Der SIGNALduino kann mit folgendem Befehl auf Werkseinstellungen zurückgesetzt werden:
:<code>get raw e</code>
als Antwort kommt dann "ccFactoryReset done". Ob ein solcher Reset nötig ist, erkennt man an der Antwort auf den Befehl "get config", auf den dann die Meldung "config: MS=1;MU=1;MC=1" folgen sollte.

In der Firmware sind die folgenden Befehle eingebaut

*:<code>get raw C<reg></code>
<reg> is a (two digit) hex number: return the value of the cc1101 register. <reg>=99 dumps the first 48 registers.
Example: C35 -> C35 = 0D
*:<code>get raw e</code>
EEPROM / factory reset. resets all eeprom values without reboot
*:<code>get raw r<AA></code>
Read eeprom (da das "R" beim SIGNALDuino bereits mit freeram belegt ist, habe ich das "r" verwendet)
*:<code>get raw r<AA>n</code>
Read 16 byte from eeprom (z.B. r00n)
*:<code>get raw W<AA><DD></code>
Write eeprom (schreibt einen Wert ins EEPROM und ins CC1101 Register. Die eeprom Adresse hat einen Offset von 2. z.B W041D schreibt 1D ins Register 2)

Die Sendeleistung lässt sich mit
:<code>get sduino ccreg 3E</code>

prüfen, wobei die Rückmeldung wie folgt zu lesen ist:
"-10_dBm" => '34',
"-5_dBm" => '68',
"0_dBm" => '60',
"5_dBm" => '84',
"7_dBm" => 'C8',
"10_dBm" => 'C0'
Dabei wird die Sendeleistung dauerhaft mit dem Befehl
:<code>set sduino cc1101_patable <value></code>
hochgeschaltet (<value> durch den Wert ersetzen).

Weitere Firmware-Befehle sind im Thread-Beitrag {{Link2Forum|Topic=58396|Message=497921}} zu finden.

== Foren Links ==
* {{Link2Forum|Topic=38402|LinkText=Forenthread - Ankündigung}}
* {{Link2Forum|Topic=58396|LinkText=SIGNALDuino Empfänger Firm- und Hardware}}
* {{Link2Forum|Topic=58397|LinkText=Signalduino Entwicklung Version 3.3.1 }}
* [http://www.nemcon.nl/blog2/wiring Beschreibung zu diversen Empfängern und Verbesserung der Empfangsleistung]
* [[SIGNALduino in die Arduino Entwicklungsumgebung einbinden]]
* [[Somfy via SIGNALduino]]

[[Kategorie:Interfaces]]
[[Kategorie:Arduino]]

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

2017-10-26T12:45:02Z

Hmcontrol: Kontrolle: Anpassung Stretch

{{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 / STRETCH ===
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, bitte entweder core_freq oder force_turbo setzen. Wichtig ist lediglich, dass damit eine feste Taktfrequenz gesetzt wird.

<pre>dtoverlay=pi3-miniuart-bt
core_freq=250
#Alternativ kann auch dieser Eintrag gesetzt werden
force_turbo=1</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! Bitte kontrollieren.
<pre>groups fhem </pre>

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 / Stretch
<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>
Nur unter Jessie

Bitte kontrollieren, dass serial1 auf ttyS0 verlinkt ist. Andernfalls muss die Datei /lib/systemd/system/hciuart.service angepasst werden. Dort müsste ttyAMA0 durch ttyS0 ersetzt werden. Dies ist aber seit jessie Version Herbst 2016 nicht mehr nötig.
<pre>ls -l /dev/serial1
lrwxrwxrwx 1 root root 5 Jan 11 20:00 /dev/serial1 -> ttyS0</pre>

Bei Stretch wird serial0 auf ttyS0 verlinkt:
<pre>
ls -l /dev/serial0
lrwxrwxrwx 1 root root 7 Okt 26 12:39 /dev/serial0 -> 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
# Version 1.4.1
wget https://raw.githubusercontent.com/eq-3/occu/28045df83480122f90ab92f7c6e625f9bf3b61aa/firmware/HM-MOD-UART/coprocessor_update.eq3
# Alternativ die aktuellste
wget https://raw.githubusercontent.com/eq-3/occu/HEAD/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 ==
{{Randnotiz|RNText=Tipp: Dieser Abschnitt ist noch in Bearbeitung und unter Umständen noch nicht "perfekt". Bitte gesamten Artikel durchlesen und beachten!}}

Die Remoteanbindung ist kein Sharing des Moduls! Es darf an dem Remote Pi (wo das Modul sitzt) '''keinerlei''' Zugriff auf das Modul seitens einer etwaigen lokalen FHEM Instanz erfolgen.

'''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

Auf einen Debian Jessie mit systemd legt man am besten folgende Datei an:
/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://<IP-Adresse>:2000
attr RM_HmUART hmId xxxxxx

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.

Lokaler Pi: FHEM -> uart://IP:Port -> Netzwerk -> socat listener -> socat serial -> RPI Modul auf Remote Pi
Remote Pi: RPI Modul -> serial -> socat -> Netzwerk -> uart://IP:Port -> FHEM auf lokalem Pi

== 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-MOD-RPI-PCB HomeMatic Funkmodul für Raspberry Pi

2017-10-26T12:41:01Z

Hmcontrol: Überschrift um STRETCH ergänzt

{{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 / STRETCH ===
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, bitte entweder core_freq oder force_turbo setzen. Wichtig ist lediglich, dass damit eine feste Taktfrequenz gesetzt wird.

<pre>dtoverlay=pi3-miniuart-bt
core_freq=250
#Alternativ kann auch dieser Eintrag gesetzt werden
force_turbo=1</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! Bitte kontrollieren.
<pre>groups fhem </pre>

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>
Nur unter Jessie

Bitte kontrollieren, dass serial1 auf ttyS0 verlinkt ist. Andernfalls muss die Datei /lib/systemd/system/hciuart.service angepasst werden. Dort müsste ttyAMA0 durch ttyS0 ersetzt werden. Dies ist aber seit jessie Version Herbst 2016 nicht mehr nötig.
<pre>ls -l /dev/serial1
lrwxrwxrwx 1 root root 5 Jan 11 20:00 /dev/serial1 -> ttyS0</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
# Version 1.4.1
wget https://raw.githubusercontent.com/eq-3/occu/28045df83480122f90ab92f7c6e625f9bf3b61aa/firmware/HM-MOD-UART/coprocessor_update.eq3
# Alternativ die aktuellste
wget https://raw.githubusercontent.com/eq-3/occu/HEAD/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 ==
{{Randnotiz|RNText=Tipp: Dieser Abschnitt ist noch in Bearbeitung und unter Umständen noch nicht "perfekt". Bitte gesamten Artikel durchlesen und beachten!}}

Die Remoteanbindung ist kein Sharing des Moduls! Es darf an dem Remote Pi (wo das Modul sitzt) '''keinerlei''' Zugriff auf das Modul seitens einer etwaigen lokalen FHEM Instanz erfolgen.

'''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

Auf einen Debian Jessie mit systemd legt man am besten folgende Datei an:
/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://<IP-Adresse>:2000
attr RM_HmUART hmId xxxxxx

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.

Lokaler Pi: FHEM -> uart://IP:Port -> Netzwerk -> socat listener -> socat serial -> RPI Modul auf Remote Pi
Remote Pi: RPI Modul -> serial -> socat -> Netzwerk -> uart://IP:Port -> FHEM auf lokalem Pi

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

Raspberry Pi

2017-10-26T10:59:10Z

Hmcontrol: Anpassung, Telnet für Fritz!Box

Beim '''Raspberry Pi''' handelt es sich um einen postkartengroßen Einplatinen-Computer, der von der Raspberry Pi Foundation entwickelt wird. Die Hardware basiert auf dem BCM 283x SoC (System-on-Chip) von Broadcom, einem ARM-Prozessor. Zu Hardwaredetails und den verschiedenen Modellen sowie Produktentwicklungen siehe [http://de.wikipedia.org/wiki/Raspberry_Pi#Hardware Wikipedia].
Dank der kleinen Abmessungen, dem recht geringen Energieverbrauch (bis ca. 4 Watt) sowie der günstigen Anschaffungskosten (ca. 30€) ist der Raspberry Pi eine attraktive Hardware für die Heimautomatisierung mit FHEM. Er ist dank dem Linux-Betriebssystem vollständig kompatibel zur aktuell vorhandenen und von FHEM unterstützen Hardware. Das derzeit empfohlene Standard-Image zum Betrieb des Raspberry Pi ist die auf Debian basierende Raspbian Distribution.

== Installation / Setup ==
=== Betriebssystem ===
Raspbian ist direkt bei raspberrybi.org unter [https://www.raspberrypi.org/downloads/raspbian/ https://www.raspberrypi.org/downloads/raspbian/] herunterladbar. Üblicherweise wählt man für einen FHEM-Server die lite-Version ohne grafischen Desktop.

Die heruntergeladene Datei muss entpackt werden. Anschließend wird das Image auf die Speicherkarte geschrieben. Detaillierte Anleitungen zur Vorgehensweise finden sich für die Betriebssysteme Linux, Mac OS und Windows unter [https://www.raspberrypi.org/documentation/installation/installing-images/README.md Writing an image to the SD card]

Der Zugriff auf den Raspberry erfolgt typischerweise Remote per SSH (headless) von einem anderen Computer. Der Remote-Zugriff per SSH ist gemäß der [https://www.raspberrypi.org/documentation/remote-access/ssh/ Raspberrpi.org-Anleitung] zu aktivieren.

Nach der Installation des Images sollte der Raspberry Pi von der Speicherkarte booten.

Weitergehende Informationen zur Anpassung der Konfiguration von Raspbian sind nachzulesen auf [https://www.raspberrypi.org/documentation/configuration/ https://www.raspberrypi.org/documentation/configuration/].

=== FHEM ===
Die Installation von FHEM kann nach der Raspbian-Installation über das Debian-Repository [http://debian.fhem.de http://debian.fhem.de] (hohe Integration), das Debian-Paket auf [https://fhem.de/fhem.html#Download http://fhem.de] oder auch automatisiert per Skript erfolgen.

==== Debian-Repository auf debian.fhem.de ====
{{Randnotiz|RNTyp=Fehl|RNText=FHEM-Updates sind nur über den [[update]]-Befehl durchzuführen. Die Debian-Paketverwaltung dient aussschließlich zur FHEM-Erstinstallation.}}
Bei der Installation von FHEM aus dem Debian-Repository [http://debian.fhem.de http://debian.fhem.de] werden neben FHEM selbst alle für den Betrieb von FHEM und vieler Module unabdingbaren Perl-Pakete automatisch mit installiert und eine Reihe weiterer Pakete für die Installation vorgeschlagen. Details zur Vorgehensweise finden sich immer aktuell direkt auf [http://debian.fhem.de http://debian.fhem.de].

==== Debian-Paket auf fhem.de ====
Alternativ kann FHEM mit dem Debian-Paket von fhem.de installiert werden. Die für FHEM grundlegenden Perl-Pakete libdevice-serialport-perl und libio-socket-ssl-perl sollten immer direkt mit installiert werden. Weitere Perl-Pakete sind je nach verwendeten FHEM-Modulen notwendig und manuell nachzuinstallieren. Informationen hierzu liefert üblicherweise die commandref zum jeweiligen Modul.

sudo apt-get install libdevice-serialport-perl
sudo apt-get install libio-socket-ssl-perl
# fhem-X.Y.deb bitte mit der [http://fhem.de/fhem.html#Download aktuellsten, stabilen Version] ersetzen
wget [http://fhem.de/fhem-X.Y.deb http://fhem.de/fhem-X.Y.deb]
sudo dpkg -i fhem-X.Y.deb

Möglicherweise ist es noch nötig, fehlende Abhängigkeiten aufzulösen. Das kann mit folgendem Befehl erledigt werden:
:<code>sudo apt-get install -f</code>

==== Skript-basiert ====
Durch Ausführung des in diesem {{Link2Forum|Topic=15848|Message=103268}} dargestellten Skriptes nach Installation eines "nackten" Raspian OS wird automatisiert ein funktionsfähiges FHEM (inkl. korrekter Rechtevergabe) auf dem Raspberry Pi installiert.

=== Nützliche Zusatzpakete ===
Nachdem der Rpi eingerichtet ist, können weitere Pakete installiert werden. Keines davon ist zwingend erforderlich, um FHEM grundsätzlich betreiben zu können. Einige Pakete erhöhen aber den Bedienungskomfort oder sind zur Nutzung bestimmter FHEM-Module (siehe commandref) erforderlich. Hier eine Übersicht.
{| class="wikitable"
! style="width:10%" | Beschreibung
! style="width:10%" | Paketname
! style="width:50%" | Kontext
! style="width:30%" | Installieren
|-
|Zeitserver
|ntpdate
|Setzt die Systemzeit bei Start des RPi. Wird für FHEM benötigt, da es sonst nicht startet.
|<code>sudo apt-get install ntpdate
sudo ntpdate -u de.pool.ntp.org</code>
|-
|Perl JSON
|JSON
|Wird von einigen Modulen benötigt, z.B. harmony, iTunes
|<code>sudo apt-get install libjson-perl</code>
|-
|Samba-Server
|samba
|Mittels Samba kann man z.B. den Ordner /opt/fhem als Share freigeben. Dieser Share kann z.B. im Windows-Explorer als Laufwerk verbunden werden, so dass die Bearbeitung von config- und Programmdateien bequem möglich ist. Hier eine hilfreiche [https://www.elektronik-kompendium.de/sites/raspberry-pi/2007071.htm Kurzanleitung] aus der (wenn man auf einen speziellen user verzichtet) nur die Einträge für smb.conf gesetzt werden müssen.
|<code>sudo apt-get install samba cifs-utils</code>
Danach muss der share definiert werden mittels

<code>sudo nano /etc/samba/smb.conf</code>
|-
|Mailversand
|sendEmail (bzw. sendemail)
|Wird benötigt, um Mails versenden zu können, bspw. für Alarm-Benachrichtigungen.
Nach Installation des Paketes benötigt man noch eine Routine in FHEM gemäß [[E-Mail senden#Raspberry Pi]]
|<code>sudo apt-get install sendEmail</code> bzw. <code>sudo apt-get install sendemail</code>
|-
|Wake-on-LAN
|etherwake
|Wird z.B. für das Modul WOL benötigt.
|<code>sudo apt-get install etherwake</code>
|-
|Perl Telnet
|telnet
|Wurde vor Fritz!OS 6.2x z.B. für das Modul [[FRITZBOX]] benötigt, da es eine im Netzwerk vorhandene Fritzbox über deren Telnet-Port ansprach. Mittlerweile wird TR-64 und SOAP verwendet.
|<code>sudo apt-get install libnet-telnet-perl</code>
|-
|Socat
|socat
|Kann verwendet werden, um auf anderen Rechnern im Netzwerk Linux-Befehle oder Skripts auszuführen. Auch können auf Slave-FHEM-Installationen Befehl ausgeführt werden, z.B. mit

<code><nowiki>system("echo 'set lampe on' | /usr/bin/socat - TCP:1.2.3.4:7072");</nowiki></code>

1.2.3.4 muss natürlich durch die IP-Adresse des Zielrechners ersetzt werden.
|<code>sudo apt-get install socat</code>
|-
|Libcrypt
|Libcrypt
|Perl libcrypt, erforderlich falls Homematic-devices mit AES verwendet werden sollen.
|<code>sudo apt-get install libcrypt-rijndael-perl</code>
|-
|libdatetime
|libdatetime
|Perl libdatetime, erforderlich für das Weather-Modul.
|<code>sudo apt-get install libdatetime-format-strptime-perl</code>
|}

== Bekannte Probleme ==
=== Netzteil ===
Der RPi verwendet ein USB Netzteil als Spannungsversorgung. Gemessen kann der RPi allein bereits um die 900mA Strom fordern. Das bringt kleine Netzteile, besonders wenn noch CULs oder WLAN Sticks an USB hängen schnell an die Grenze. Die Fehler die daraus resultieren sind Abstürze, Netzwerkprobleme uvm. Daher bitte ein ausreichend starkes Netzteil mit mind. 2000mA oder einen aktiven USB-HUB für die Periperie verwenden.

=== Echtzeituhr ===
Der RPi hat keine [http://de.wikipedia.org/wiki/Echtzeituhr Real-Time-Clock] (RTC), das heißt, dass er nach einem Neustart keine gültige (im Sinne von aktuell) Systemzeit hat, sondern ein Datum in der Vergangenheit. Dieses Problem wird sinnvollerweise mit einer [http://de.wikipedia.org/wiki/Network_Time_Protocol NTP-Konfiguration] umgangen.

Dabei muss Sorge getragen werden, dass der [http://wiki.debian.org/NTP ntpd] schon einen Datums-/Zeitabgleich gemacht hat, bevor FHEM gestartet wird. Geschieht der Abgleich nicht vorher, sondern erst nachdem FHEM schon läuft, stellt FHEM die Logs zwar auf das nun aktuelle Datum um (die "alten" Logs mit dem eigentlich ungültigen Datum werden natürlich behalten), aber irgendetwas scheint FHEM dabei so zu belasten, dass es eine Last von über 0.8 bis 0.9 erzeugt. Diese Last besteht auf Dauer und verschwindet erst, wenn man das Ganze sauber durchkonfiguriert und FHEM neu gestartet hat. Die hohe Systemauslastung zeigt sich auch in einem sehr trägen Laden der FHEM-Webseiten in einem beliebigen Browser. (siehe {{Link2Forum|Topic=70741}})

=== Last durch Backup (während update) ===
Bei einen [[Update]] von FHEM durch den Befehl <code>update</code> kann durch Setzen des Attributs "<code>attr global backup_before_update 1</code>" automatisch vorab ein [[Backup]] durchgeführt werden. Die (ggf. großen) Log-Dateien werden dabei ebenfalls archiviert. Während der Archivierung ist FHEM blockiert. Durch die beschränkte Leistungsfähigkeit des Raspberry Pi kann das Backup zudem lange dauern. Durch ein "<code>attr global updateInBackground 1</code>" wird ein Backup im Hintergrund ausgeführt (Quelle: {{Link2Forum|Topic=15729}}).

Alternative Möglichkeiten:
* Backup ausschalten und manuell durchführen
* Backup-Befehl anpassen und so große Dateien bzw. Verzeichnisse (log/) nicht archivieren

== Watchdog einrichten ==
Man kann den RPi alle halbe Stunde prüfen lassen, ob FHEM noch läuft und gegebenenfalls einen Neustart durchführen lassen. Eine mögliche Vorgehensweise ist in diesem {{Link2Forum|Topic=20553|LinkText=Forumsthema}} beschrieben.

== Interne Links ==
* [[CUL am Raspberry Pi flashen]]
* [[Raspberry Pi und 1-Wire]]

== Externe Links ==
* {{Link2Forum|Topic=33460|Message=264679}} zum Umzug von Raspberry B auf Raspberry Pi 2
* [http://www.raspberrypi.org/ Offizielle Webseite der Raspberry Pi Foundation]
* [http://www.raspberrypi.org/downloads Offizielle Downloads der Raspberry Pi Foundation]

[[Kategorie:Raspberry Pi]]
[[Kategorie:HOWTOS]]

E-Mail senden

2017-10-26T10:50:15Z

Hmcontrol: sudo-Aufruf für sendemail mit kleinem e hinzugefügt

Um aus FHEM heraus '''E-Mail senden''' zu können, sind abhängig von der verwendeten Platform unterschiedliche Vorgehensweisen erforderlich.

{{Randnotiz|RNTyp=y|RNText=Anleitung zur Einrichtung von Exim4 auf Debian mit GMX als Smarthost:[[Media:Anleitung_Exim4_Debian_GMX.pdf|PDF]]}}

== Linux ==
=== FritzBox 7170 (non-chroot) oder "reine" Linuxe ===
Datei 99_email.pm im Modul-Verzeichnis mit folgender Funktion anlegen (oder in bestehende 99_irgendwas.pm kopieren):

<nowiki>sub fb_mail {
my $rcpt = $_[0];
my $subject = $_[1];
my $text = $_[2];
system("/bin/echo \"$text\" | /usr/bin/mail send -i - -s \"$subject\" -t \"$rcpt\"");
}</nowiki>
Aufruf dann mittels
:<code>{ fb_mail('empfaenger@mail.de','Subject','text 123') }</code>
Darauf achten, dass der fhem-User Mails senden darf (in richtige Gruppe eintragen. Ggf. vorher einmal su fhem und probieren).

=== Fritz!Box 7390 ===
Auf der [[AVM Fritz!Box|FritzBox 7390]] ist diese Funktion seit 10/2012 Bestandteil der FHEM Standardauslieferung. Sie ist untergebracht in FritzBoxUtils.pm und heisst dort FB_mail($$$) (Groß-Kleinschreibung beachten).

Da der Dateiname von FritzBoxUtils.pm nicht mit 99_ beginnt, wird diese Programmdatei nicht automatisch beim Start von FHEM geladen. FHEM muss zum Laden dieser Programmdatei aufgefordert werden. Dazu (z. B. in 99_myUtils.pm) die Zeile ''use FritzBoxUtils;'' einfügen.

Mit dem Install von AVM.de wird fhem in einer chroot-Umgebung ausgeführt, die den Zugriff auf die Mailfunktion der Fritzbox nicht zulässt. Daher muss FHEM in der [http://fhem.de/fhem.html#Download Version von fhem.de] installiert sein. Sollte Ihre Fritzbox bisher mit dem install von AVM laufen, kann (nach einem backup!) das image von fhem.de einfach drüberinstalliert werden. Es sollten dabei alle Einstellungen erhalten bleiben.

<nowiki>sub fb_mail {
my $rcpt = $_[0];
my $subject = $_[1];
my $text = $_[2];
system("/bin/echo \"$text\" > /var/tmp/fhem_nachricht.txt");
system("/sbin/mailer send -i '/var/tmp/fhem_nachricht.txt' -s \"$subject\" -t \"$rcpt\"");
system("rm /var/tmp/fhem_nachricht.txt");
}</nowiki>

Aufruf dann mittels
:<code>{ fb_mail('empfaenger@mail.de','Subject','text 123') }</code>
bzw.
:<code>{ FB_mail('empfaenger@mail.de','Subject','text 123') }</code>

Dem Mailer können noch weitere Parameter hinzugefügt werden. Mehr dazu siehe: [http://www.wehavemorefun.de/fritzbox/Mailer Mailer]

=== OpenWRT ===
Die Anleitung wurde mit einer frühen Beta von Barrier Breaker (r391xx) mit einem TP_Lind WDR 4900 getestet. Da "sendEmail" nicht als Package vorliegt wird in dieser Anleitung "ssmtp" verwendet.
Die Installation erfolgt mittels:

<pre>
opkg update
opkg install ssmtp_2.64-4_mpc85xx.ipk
</pre>

Hierbei werden die Packete libopenssl und zlib mit installiert. Damit ssmtp funktioniert müssen die Dateien /etc/ssmtp/ssmtp.conf und /etc/ssmtp/revaliases angepasst werden.

/etc/ssmtp/ssmtp.conf
<nowiki>root=arnold@gmx.net
mailhub=mail.gmx.net:465
rewriteDomain=gmx.net
hostname=gmx.net
FromLineOverride=YES
UseTLS=YES
#UseSTARTTLS=YES
AuthUser=arnold@gmx.net
AuthPass=Passwort_von_arnold@gmx.net
</nowiki>

/etc/ssmtp/revaliases
<nowiki>
root:arnold@gmx.net:mail.gmx.net:465</nowiki>

In der [[99_myUtils_anlegen|99_myUtils]] folgende Unterroutine einfügen (von der RPi-Anleitung übernommen):

<nowiki>sub
OpenWRTMail
{
my $rcpt = shift;
my $subject = shift;
my $text = shift;
my $ret = "";
my $sender = "dockstar\@heye-tammo.de";
Log 1, "sendEmail RCP: $rcpt, Subject: $subject, Text: $text";
$ret .= qx(echo -e 'to:$rcpt\n from:$sender\nsubject:$subject\n$text\n' | ssmtp $rcpt);
$ret =~ s,[\r\n]*,,g; # remove CR from return-string
Log 1, "sendEmail returned: $ret";
}</nowiki>

Ab hier den entsprechenden Abschnitt unter "Raspberry Pi" lesen.

=== Synology DiskStation ===
Beim DSM 3.2 gab es keinen <code>sendmail</code>-Befehl, sondern nur eine Funktion für den Versand der System-Benachrichtigungen. Interessanterweise funktionierte aber der <code>php-mail</code>-Befehl, so dass man mittels folgendem Modul Mails frei versenden kann:

<nowiki>sub sendmail($$$) {
my($empf, $subj, $nachricht) = @_;
system("php -r 'mail(\"$empf\",\"$subj\",\"$nachricht\");'");
undef;
}</nowiki>

=== Raspberry Pi ===
In der weezy-Version, wie sie von busware zur Verfügung gestellt wird, muss auf einem [[Raspberry Pi]] noch sendEmail nachinstalliert werden. Diese Anleitung funktioniert auch unter '''Ubuntu'''.
{{Randnotiz|RNTyp=o|RNText=In späteren Distributionen wird das Paket uU. mit kleinem "e" geschrieben: sendemail.}}
<pre>
sudo apt-get update
sudo apt-get install sendEmail libio-socket-ssl-perl libnet-ssleay-perl perl
</pre>

In der Stretch-Version von Raspbian erfolgt der Aufruf mit kleinem "e":

<pre>
sudo apt-get update
sudo apt-get install sendemail libio-socket-ssl-perl libnet-ssleay-perl perl
</pre>

in der [[99_myUtils_anlegen|99_myUtils]] folgende Unterroutine einfügen:

<nowiki>######## DebianMail Mail auf dem RPi versenden ############
sub
DebianMail
{
my $rcpt = shift;
my $subject = shift;
my $text = shift;
my $attach = shift;
my $ret = "";
my $sender = "absender\@account.de";
my $konto = "kontoname\@account.de";
my $passwrd = "passwrd";
my $provider = "smtp.provider.de:587";
Log 1, "sendEmail RCP: $rcpt";
Log 1, "sendEmail Subject: $subject";
Log 1, "sendEmail Text: $text";
Log 1, "sendEmail Anhang: $attach";

$ret .= qx(sendEmail -f '$sender' -t '$rcpt' -u '$subject' -m '$text' -a $attach -s '$provider' -xu '$konto' -xp '$passwrd' -o tls=auto -o message-charset=utf-8);
$ret =~ s,[\r\n]*,,g; # remove CR from return-string
Log 1, "sendEmail returned: $ret";
}</nowiki>

Um die TLS Verschlüsselung (ehem. SSL) nicht zu nutzen, muss in der 4. letzten Zeile tls=no verwendet und der Port des Mailproviders auf 25 eigetragen werden. Sollte anschließend keine Mail verschickt werden, siehe Probleme.

Falls der Body-Text in einem (Android-)Mailer auf dem Handy nicht gezeigt wird, kann der Parameter '''-o message-content-type=html''' helfen.

Die Funktion kann beispielsweise folgendermaßen aufgerufen werden:
{{Randnotiz|RNTyp=g|RNText=Bei allen Feldern können generell doppelte " oder einfache ' Anführungszeichen verwendet werden. Innerhalb von "" müssen Sonderzeichen wie @ aber maskiert werden, da sie sonst als Steuerzeichen interpretiert werden:
<nowiki>"email\@email.domain" oder 'email@email.domain'</nowiki> }}

<nowiki>define Sonstiges notify Fenster:Window:.*,.*Low.Batt*. {\
DebianMail("email\@email.domain","Subject","Text","'Anhang1' 'Anhang2' ...");;\
}</nowiki>

oder (mehr als einen Empfänger, diese können durch Leerzeichen, Semikolon oder Komma getrennt sein)

<nowiki>define Sonstiges at *01:00:00 {\
DebianMail('email@email.domain,email2@email.domain',"Subject","Text","'Anhang1' 'Anhang2' ...");;\
}</nowiki>

Es ist wichtig die Dateinamen mit ' ' zu klammern, da hierdurch auch Leerzeichen im Pfad/Dateinamen möglich sind.

=== BeagleBoard-xM ===
Auf einem [[:Kategorie:BeagleBoard-xM|BeagleBoard-xM]] mit einem [http://en.opensuse.org/HCL:BeagleBoard-xM OpenSUSE 12.2] kann man ebenfalls das Perl-Programm ''sendEmail'' wie beim RPi nutzen. Dies gibt es aber nicht in den Repositories von openSUSE, sondern man muss sich ''sendEmail'' als Source herunterladen. Das geht am einfachsten per ''wget'', welches man ebenfalls erst installieren muss (aber aus einem Repository).

<nowiki>$ zypper in wget
$ cd /opt
$ wget http://caspian.dotconf.net/menu/Software/SendEmail/sendEmail-v1.56.tar.gz
$ tar xvfz sendEmail-v1.56.tar.gz
$ cd sendEmail-v1.56
$ cp sendMail /usr/local/bin</nowiki>
Dann geht man weiter vor wie unter RPi beschrieben (anlegen der SUB-Routine in 99_myUtils usw.).

'''Hinweis:''' Die Version 1.56 von ''sendEmail'' ist Stand Januar 2013 die aktuelle. Da diese Programmversion von 2009 stammt, ist mit neuen Versionen selten zu rechnen. Vielleicht schauen Sie trotzdem vorher auf der [http://caspian.dotconf.net/menu/Software/SendEmail/ Homepage von sendEmail] nach.

== Windows ==
# Kopiere die Datei sendEmail.exe* in Dein FHEM Verzeichnis (hier c:\fhem-5.0\); Quelle: [http://caspian.dotconf.net/menu/Software/SendEmail/ http://caspian.dotconf.net/menu/Software/SendEmail/]
# Erstelle im FHEM Verzeichnis die Datei wmail.bat mit folgendem Inhalt (eine Zeile): <code>sendEmail -f absender@domain.de -u "%1" -m " " -s SMTP-SERVERAdresse -xu SMTP_USERNAME -xp SMTP_PASSWORT -t empfänger@domain.de -o message-header="X-Message-Flag: FHEM"</code>
# Beispiel fhem.cfg
## Mail wenn sich der Status von Heizung.* oder Hzg.* ändert <code>define Mail_Heizung notify Heizung.*|Hzg.* { system("wmail $NAME:$EVENT")}</code>
## Mail bei Signal Aussentemperatur (für dieses Beispiel wird [http://fhem.de/commandref.html#getstate http://fhem.de/commandref.html#getstate getstate] benötigt) <code>define Mail_Aussentemperatur notify Aussentemperatur {\</code> <code>my ($val);;\</code> <code>$val = fhem "getstate $NAME";;\</code> <code>system("wmail \"$NAME: $val\"");;\</code> <code>}</code>

== Probleme ==
=== sendEmail ===
Falls man keine E-Mails verschicken kann, kann man in einem ersten Test prüfen, ob sendEmail als solches funktioniert und die Konfiguration (Benutzer, Passwort, Server-Name usw.) des Mail-Kontos, über das die Mails abgesetzt werden sollen, richtig ist.

Hierzu setzt man in der FHEM-Befehlszeile die folgende Anweisung ab:
:<code>{ SUB-Routinen-Name('EMailAdresse@Mail.Domain','Test','Test-Text');; }</code>
und ersetzt ''SUB-Routinen-Name'' durch den Namen der in 99_myUtils erzeugten Prozedur. Statt ''EMailAdresse@Mail.Domain'' trägt man noch eine gültige E-Mail-Adresse ein und bestätigt den Befehl dann mittels <Enter> (nicht "save"). Empfangen Sie nicht kurzfristig eine entsprechende E-Mail, ist sehr wahrscheinlich an den Zugangsdaten etwas verkehrt.

Vor dem testen der Routine oben kann sendEmail auch über die Konsole (z. B. via Putty) getestet werden:
:<code>sendEmail -f 'Absender@AbsDomain.de' -t 'Empfänger@EmpfDomain.de' -u 'subject' -m 'body' -s 'smtp.AbsDomain.de' -xu 'AbsenderBenutzername' -xp 'AbsenderPasswort' -o tls=yes</code>

=== Keine Mail mit TLS Verschlüsselung ===
Den Test über die Konsole durchführen. Erhält man folgende Fehlermeldung:
''invalid SSL_version specified at /usr/share/perl5/IO/Socket/SSL.pm line 332''
muss auf dem Raspberry folgende Datei angepasst werden: ''/usr/bin/sendEmail''.
In Zeile 1907 muss
if (! IO::Socket::SSL->start_SSL($SERVER, SSL_version => 'SSLv3 TLSv1')) {

in folgendes geändert werden
if (! IO::Socket::SSL->start_SSL($SERVER, SSL_version => 'SSLv23:!SSLv2')) {

Der frühere Tipp direkt in der SSL.pm Datei zu editieren führt zu Problemen wenn man auf FHEM per HTTPS zugreifen will und ist daher nicht zu empfehlen.

== Email laut Log gesendet aber nicht angekommen? ==
Dann bitte in der Fritzbox Oberfläche überpüfen, ob unter "System" -> "Push Service" selbiger eingerichtet und aktiviert wurde.

[[Kategorie:HOWTOS]]
[[Kategorie:FritzBox]]
[[Kategorie:BeagleBoard-xM]]
[[Kategorie:Raspberry Pi]]

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

2017-03-09T20:33:18Z

Hmcontrol: Anpassung

hmcontrol: Hallo, bei mir gibt es unter Jessy kein serial1 und auch kein ttyS0. Auch liefert unter Jessie (raspbian-lite) das ls auf <nowiki>ttyAMA0 andere Werte:
pi@raspberrypi:/opt/fhem $ ls -l /dev/ttyAMA0
crw--w---- 1 root tty 204, 64 Mär 7 20:17 /dev/ttyAMA0</nowiki>

Da für ttyAMA0 nicht die Gruppe dialout, sondern die Gruppe tty benutzt wird, habe ich den User fhem der Gruppe hinzugefügt:

<nowiki>pi@raspberrypi:/opt/fhem $ sudo adduser fhem tty
Füge Benutzer »fhem« der Gruppe »tty« hinzu ...
Benutzer fhem wird zur Gruppe tty hinzugefügt.
Fertig.
pi@raspberrypi:/opt/fhem $ groups fhem
fhem : dialout tty</nowiki>

Damit konnten zwar Informationen via HM gelesen werden, aber senden funktionierte nicht. Daher habe ich die Gruppe für /dev/ttyAMA0 mit dem Befehl <nowiki>sudo chgrp tty /dev/ttyAMA0</nowiki> die Gruppe auf tty geändert, fhem neugestartet und es ging.

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

2017-03-08T18:24:30Z

Hmcontrol: Eintrag angepasst

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

2017-02-23T20:49:01Z

Hmcontrol: serial nachfrage

Hallo, bei mir gibt es unter Jessy kein serial1 und auch kein ttyS0. Das Modul funktioniert aber trotzdem.

FHEM auf Raspberry PI mit COC betreiben

2017-02-23T17:39:42Z

Hmcontrol: sudo beim fhem stop hinzugefügt

Um einen [[COC]] mit einem Raspberry Pi und FHEM zu nutzen sind mehrere Schnitte notwendig. Die folgende Anleitung zeigt diese entsprechend auf.

== Vorausetzung ==
Erforderliche Hardware:
* [[Raspberry Pi]]
* Busware [[COC]]

Erforderliche Software:
* Raspbian OS (Debian Wheezy Version June 2014, oder aktueller)

Notwendige Vorbereitungen:
* Busware [[COC]] ist auf dem [[Raspberry Pi]] montiert
* [[Raspberry Pi]] ist per LAN Kabel an den Router angeschlossen und hat eine IP via DHCP bekommen und kann in das Internet (keine Firewall Restriktion)

== Raspberry Pi Grundinstallation ==
# Die Beschreibung der Installation im nachfolgenden Abschnitt ist veraltet.
# Bitte immer zuerst http://fhem.de/fhem.html#Installation lesen!
# Eine Anleitung zur Grundinstallation des Raspberry Pi findet sich hier [[Raspberry_Pi]]. Die nachfolgenden Installationanleitung für das Grundsystem wird überarbeitet und ist nicht als Standardvariante zu verwenden!

== FHEM Installieren ==
{{Randnotiz|RNTyp=Fehl|RNText=Diese Anleitung zur Installation von FHEM entspricht nicht dem aktuellen Stand. Dieser Abschnitt muss überarbeitet werden.
Hier wird die "manuelle" Installationsvariante von Fhem (11.-13.) angewendet. Mittlerweile ist auch die Installation aus einem [[Raspberry_Pi#Debian-Repository|Debian-Repository ]] möglich.}}
# Raspberry Pi booten
# Einloggen als User: pi mit dem Password: raspberry
# Danach sollte das Raspberry OS upgedatet werden: <code>sudo apt-get update && sudo apt-get upgrade -y && sudo apt-get autoremove -y && sudo reboot</code>
# nach dem neustart sollte auch kurz die Firmware aktuallisiert werden. Das geht wie folgt: <code>sudo apt-get install rpi-update</code> <code>sudo rpi-update</code>
# Anschließend sollte der Raspberry PI neu gestarted werden mittels <code>sudo shutdown -r now</code>
# Danach muss die richtige Zeitzone für unseren RPI eingestellt werden, das geht mittels <code>sudo dpkg-reconfigure tzdata</code>
# Damit der RPI den gesamten Speicherplatz der SD-Karte nutzt, kann man (sofern noch nicht nach dem ersten Start getan) das Filesystem mit folgendem Menü erweitern <code>sudo raspi-config</code>
# Anschließend rebooten wir den RPI mittels <code>sudo shutdown -r now</code>
# Einloggen als User: Pi mit dem Password: Raspberry
# Da wir davon ausgehen das wir FHEM mit Zeitprofilen verwenden werden ist das korrekte Datum sehr wichtig. Daher installieren wir einen NTP Client, der die Zeit aktuell hält und richten ihn für Deutschland ein. Dies geht wie folgt: <code>sudo apt-get install ntpdate</code> <code>sudo ntpdate -u de.pool.ntp.org</code>
# Da der FHEM auf Perl basiert müssen jetzt die notwendigen Packete installiert werden: <code>sudo apt-get -f install && sudo apt-get install perl libdevice-serialport-perl libio-socket-ssl-perl libwww-perl libxml-simple-perl -y</code>
# Jetzt können wir FHEM herunterladen und zwischenspeichern: <code>sudo wget http://fhem.de/fhem-5.7.deb -O /tmp/fhem-5.7.deb</code> Es ist darüber hinaus sinvoll kurz zu kontrollieren, ob die Version aktuell ist. Das kann auf der FHEM Webseite http://fhem.de/fhem.html getan werden.
# Anschließend kann FHEM installiert werden: <code>sudo dpkg -i /tmp/fhem-5.7.deb</code>
# Da FHEM automatisch gestarted hat, müssen wir ihn jetzt kurz beenden via:<code>sudo /etc/init.d/fhem stop</code>
# Jetzt müssen wir noch die Rechte des FHEM Verzeichnisses anpassen. Dafür vergeben wir auf alle Dateien unter /opt/fhem Schreibrechte<code>sudo chmod -R a+w /opt/fhem</code> (Bedenken gegen diese Rechtevergabe und Alternative: {{Link2Forum|Topic=39353|Message=320936}})
# Nun fügen wir die Benutzer pi und fhem der Gruppe tty hinzu (Zugriffsrechte auf Serial- und USB-Ports) <code>sudo usermod -aG tty pi && sudo usermod -aG tty fhem</code>
# Jetzt müssen wir den Speicherort des Logfiles anpassen. Dafür editieren wir die FHEM config via <code>nano /opt/fhem/fhem.cfg</code> und ändern alle einträge der art "./log/" nach "/opt/fhem/log"
# Jetzt starten wir FHEM kurz neu <code>/etc/init.d/fhem stop</code> <code>/etc/init.d/fhem start</code>
# Anschließend können wir uns über <code><nowiki>http://<dieRaspberryIP>:8083/fhem</nowiki></code> am FHEM anmelden. In der Dialogbox oben geben wir nun folgendes ein, um FHEM zu aktualisieren <code>attr global sendStatistics onUpdate</code> <code>update</code> und wenn uns FHEM nach einem Neustart fragt, kommen wir dem mittels <code>shutdown restart</code> nach.

== COC in Betrieb nehmen ==
# Nun muss der serielle Port für den Raspberry freigegeben werden.
#* Dazu muss die Datei /etc/inittab mittels <code>sudo nano /etc/inittab</code> angepasst werden und folgende Zeile löschen <code>T0:23:respawn:/sbin/getty -L ttyAMA0 115200 vt100</code> oder auskommentieren
#* Bei jessie: <code>sudo systemctl stop serial-getty@ttyAMA0.service</code> <code>sudo systemctl disable serial-getty@ttyAMA0.service</code> 
# Anpassen der boot parameter
#* Dazu wird die Datei /boot/cmdline.txt bearbeitet. Sie wird mittels <code>sudo nano /boot/cmdline.txt</code> editiert und Referenzen auf ttyAMA0 entfernt <code>console=ttyAMA0,115200 kgdboc=ttyAMA0,115200</code>
#* Bei jessie: Hier muss in der Datei /boot/config.txt der Wert <code>dtoverlay=pi3-miniuart-bt</code> eingetragen werden. Die Datei /boot/cmdline.txt sollte so aussehen: <code>dwc_otg.lpm_enable=0 console=tty1 root=/dev/mmcblk0p2 rootfstype=ext4 elevator=deadline fsck.repair=yes rootwait</code>
# Damit der COC beim Start vom FHEM initialisiert wird, muss die /etc/init.d/fhem editiert werden. Dies machen wir mittels <code>sudo nano /etc/init.d/fhem</code> und fügen unterhalb von "Start)" folgendes in die Datei ein <code>echo "resetting 868MHz extension..." </code> <code> if test ! -d /sys/class/gpio/gpio17; then echo 17 > /sys/class/gpio/export; fi </code> <code> if test ! -d /sys/class/gpio/gpio18; then echo 18 > /sys/class/gpio/export; fi </code> <code> echo out > /sys/class/gpio/gpio17/direction </code> <code> echo out > /sys/class/gpio/gpio18/direction </code> <code> echo 1 > /sys/class/gpio/gpio18/value </code> <code> echo 0 > /sys/class/gpio/gpio17/value </code> <code> sleep 1 </code> <code> echo 1 > /sys/class/gpio/gpio17/value </code> <code> sleep 1 </code> Achtung: Nach einem Update von FHEM könnte diese Datei überschrieben werden. Dann muss die Änderung oben wieder hinzugefügt werden.
# nun wird der COC in die Fhem [[Konfiguration]] eingefügt. Dafür wird (z.B., aber nicht die empfohlene Vorgehensweise) die Konfigurationsdatei editiert: <code>"sudo nano /opt/fhem/fhem.cfg"</code> und ganz zum Schluss folgendes hinzugefügt: <code>"define COC CUL /dev/ttyAMA0@38400 1234"</code>
# Nun wird der Raspberry PI vollständig neu gestarted <code>sudo shutdown -r now</code>
# Der Raspberry PI sollte nun via auto detect die Komponenten auffinden

[[Kategorie:Raspberry Pi]]
[[Kategorie:HOWTOS]]

FHEM auf Raspberry PI mit COC betreiben

2017-02-23T17:37:41Z

Hmcontrol: fhem-5.7.deb

Um einen [[COC]] mit einem Raspberry Pi und FHEM zu nutzen sind mehrere Schnitte notwendig. Die folgende Anleitung zeigt diese entsprechend auf.

== Vorausetzung ==
Erforderliche Hardware:
* [[Raspberry Pi]]
* Busware [[COC]]

Erforderliche Software:
* Raspbian OS (Debian Wheezy Version June 2014, oder aktueller)

Notwendige Vorbereitungen:
* Busware [[COC]] ist auf dem [[Raspberry Pi]] montiert
* [[Raspberry Pi]] ist per LAN Kabel an den Router angeschlossen und hat eine IP via DHCP bekommen und kann in das Internet (keine Firewall Restriktion)

== Raspberry Pi Grundinstallation ==
# Die Beschreibung der Installation im nachfolgenden Abschnitt ist veraltet.
# Bitte immer zuerst http://fhem.de/fhem.html#Installation lesen!
# Eine Anleitung zur Grundinstallation des Raspberry Pi findet sich hier [[Raspberry_Pi]]. Die nachfolgenden Installationanleitung für das Grundsystem wird überarbeitet und ist nicht als Standardvariante zu verwenden!

== FHEM Installieren ==
{{Randnotiz|RNTyp=Fehl|RNText=Diese Anleitung zur Installation von FHEM entspricht nicht dem aktuellen Stand. Dieser Abschnitt muss überarbeitet werden.
Hier wird die "manuelle" Installationsvariante von Fhem (11.-13.) angewendet. Mittlerweile ist auch die Installation aus einem [[Raspberry_Pi#Debian-Repository|Debian-Repository ]] möglich.}}
# Raspberry Pi booten
# Einloggen als User: pi mit dem Password: raspberry
# Danach sollte das Raspberry OS upgedatet werden: <code>sudo apt-get update && sudo apt-get upgrade -y && sudo apt-get autoremove -y && sudo reboot</code>
# nach dem neustart sollte auch kurz die Firmware aktuallisiert werden. Das geht wie folgt: <code>sudo apt-get install rpi-update</code> <code>sudo rpi-update</code>
# Anschließend sollte der Raspberry PI neu gestarted werden mittels <code>sudo shutdown -r now</code>
# Danach muss die richtige Zeitzone für unseren RPI eingestellt werden, das geht mittels <code>sudo dpkg-reconfigure tzdata</code>
# Damit der RPI den gesamten Speicherplatz der SD-Karte nutzt, kann man (sofern noch nicht nach dem ersten Start getan) das Filesystem mit folgendem Menü erweitern <code>sudo raspi-config</code>
# Anschließend rebooten wir den RPI mittels <code>sudo shutdown -r now</code>
# Einloggen als User: Pi mit dem Password: Raspberry
# Da wir davon ausgehen das wir FHEM mit Zeitprofilen verwenden werden ist das korrekte Datum sehr wichtig. Daher installieren wir einen NTP Client, der die Zeit aktuell hält und richten ihn für Deutschland ein. Dies geht wie folgt: <code>sudo apt-get install ntpdate</code> <code>sudo ntpdate -u de.pool.ntp.org</code>
# Da der FHEM auf Perl basiert müssen jetzt die notwendigen Packete installiert werden: <code>sudo apt-get -f install && sudo apt-get install perl libdevice-serialport-perl libio-socket-ssl-perl libwww-perl libxml-simple-perl -y</code>
# Jetzt können wir FHEM herunterladen und zwischenspeichern: <code>sudo wget http://fhem.de/fhem-5.7.deb -O /tmp/fhem-5.7.deb</code> Es ist darüber hinaus sinvoll kurz zu kontrollieren, ob die Version aktuell ist. Das kann auf der FHEM Webseite http://fhem.de/fhem.html getan werden.
# Anschließend kann FHEM installiert werden: <code>sudo dpkg -i /tmp/fhem-5.7.deb</code>
# Da FHEM automatisch gestarted hat, müssen wir ihn jetzt kurz beenden via:<code>/etc/init.d/fhem stop</code>
# Jetzt müssen wir noch die Rechte des FHEM Verzeichnisses anpassen. Dafür vergeben wir auf alle Dateien unter /opt/fhem Schreibrechte<code>sudo chmod -R a+w /opt/fhem</code> (Bedenken gegen diese Rechtevergabe und Alternative: {{Link2Forum|Topic=39353|Message=320936}})
# Nun fügen wir die Benutzer pi und fhem der Gruppe tty hinzu (Zugriffsrechte auf Serial- und USB-Ports) <code>sudo usermod -aG tty pi && sudo usermod -aG tty fhem</code>
# Jetzt müssen wir den Speicherort des Logfiles anpassen. Dafür editieren wir die FHEM config via <code>nano /opt/fhem/fhem.cfg</code> und ändern alle einträge der art "./log/" nach "/opt/fhem/log"
# Jetzt starten wir FHEM kurz neu <code>/etc/init.d/fhem stop</code> <code>/etc/init.d/fhem start</code>
# Anschließend können wir uns über <code><nowiki>http://<dieRaspberryIP>:8083/fhem</nowiki></code> am FHEM anmelden. In der Dialogbox oben geben wir nun folgendes ein, um FHEM zu aktualisieren <code>attr global sendStatistics onUpdate</code> <code>update</code> und wenn uns FHEM nach einem Neustart fragt, kommen wir dem mittels <code>shutdown restart</code> nach.

== COC in Betrieb nehmen ==
# Nun muss der serielle Port für den Raspberry freigegeben werden.
#* Dazu muss die Datei /etc/inittab mittels <code>sudo nano /etc/inittab</code> angepasst werden und folgende Zeile löschen <code>T0:23:respawn:/sbin/getty -L ttyAMA0 115200 vt100</code> oder auskommentieren
#* Bei jessie: <code>sudo systemctl stop serial-getty@ttyAMA0.service</code> <code>sudo systemctl disable serial-getty@ttyAMA0.service</code> 
# Anpassen der boot parameter
#* Dazu wird die Datei /boot/cmdline.txt bearbeitet. Sie wird mittels <code>sudo nano /boot/cmdline.txt</code> editiert und Referenzen auf ttyAMA0 entfernt <code>console=ttyAMA0,115200 kgdboc=ttyAMA0,115200</code>
#* Bei jessie: Hier muss in der Datei /boot/config.txt der Wert <code>dtoverlay=pi3-miniuart-bt</code> eingetragen werden. Die Datei /boot/cmdline.txt sollte so aussehen: <code>dwc_otg.lpm_enable=0 console=tty1 root=/dev/mmcblk0p2 rootfstype=ext4 elevator=deadline fsck.repair=yes rootwait</code>
# Damit der COC beim Start vom FHEM initialisiert wird, muss die /etc/init.d/fhem editiert werden. Dies machen wir mittels <code>sudo nano /etc/init.d/fhem</code> und fügen unterhalb von "Start)" folgendes in die Datei ein <code>echo "resetting 868MHz extension..." </code> <code> if test ! -d /sys/class/gpio/gpio17; then echo 17 > /sys/class/gpio/export; fi </code> <code> if test ! -d /sys/class/gpio/gpio18; then echo 18 > /sys/class/gpio/export; fi </code> <code> echo out > /sys/class/gpio/gpio17/direction </code> <code> echo out > /sys/class/gpio/gpio18/direction </code> <code> echo 1 > /sys/class/gpio/gpio18/value </code> <code> echo 0 > /sys/class/gpio/gpio17/value </code> <code> sleep 1 </code> <code> echo 1 > /sys/class/gpio/gpio17/value </code> <code> sleep 1 </code> Achtung: Nach einem Update von FHEM könnte diese Datei überschrieben werden. Dann muss die Änderung oben wieder hinzugefügt werden.
# nun wird der COC in die Fhem [[Konfiguration]] eingefügt. Dafür wird (z.B., aber nicht die empfohlene Vorgehensweise) die Konfigurationsdatei editiert: <code>"sudo nano /opt/fhem/fhem.cfg"</code> und ganz zum Schluss folgendes hinzugefügt: <code>"define COC CUL /dev/ttyAMA0@38400 1234"</code>
# Nun wird der Raspberry PI vollständig neu gestarted <code>sudo shutdown -r now</code>
# Der Raspberry PI sollte nun via auto detect die Komponenten auffinden

[[Kategorie:Raspberry Pi]]
[[Kategorie:HOWTOS]]

Luxtronik 1 in FHEM

2017-01-21T17:06:08Z

Hmcontrol:

== Features / Funktionen ==
Die Luxtronik 1.0 ist eine Heizungssteuerung, die in Wärmepumpen von Alpha Innotec, Siemens und Novelan verbaut ist. Ihr fehlt ein Ethernet Anschluss, so dass sie über die vorhandene RS232-Schnittstelle integriert werden muss. Sie ist die Vorgängerversion der LAN-fähigen [[Luxtronik 2.0]], für die ein FHEM-Modul existiert.

== Hinweise zum Betrieb mit FHEM ==
Falls es besondere Einschränkungen / Voraussetzungen, etc. gibt...
# Die Wärmepumpe kann nur über die serielle Schnittstelle angesprochen werden.
# Derzeit wird nur das Auslesen der Konfiguration und Werte unterstützt.

== Verbindung herstellen ==
Damit man die Schnittstelle - die insbesondere für Wartungszwecke da ist - nutzen kann, musst du die nachfolgenden Schritte durchführen.
=== Schnittstelle freigeben ===
Unter ''Einstellungen --> Datenzugang'' die PIN 9445 für den Kundendienstzugang eingeben und bestätigen. Es passiert erstmal nix, es sind jetzt aber weitere Menüs erreichbar. Unter ''Einstellungen --> Diagnose'' Standard auswählen. Damit ist die Schnittstelle freigegeben.
=== Kabel anschließen ===
Jetzt geht es an die Wärmepumpe, diese öffnen. Bei meiner Alpha Innotec ist die Steuerung an der linken Seite hinter einer Metallabdeckung. Dort sieht es dann so aus:

:[[Datei:Luxtronik1-kabel-anschliessen.jpg]]

Der rote Pfeil zeigt den seriellen Anschluss, hier muss das Kabel eingesteckt werden.
=== Das Kabel ===
Es gibt leider viele verschiedene Kabelbelegungen. Daher ist es am einfachsten sich ein Kabel selbst zu löten. Drei PINs müssen verbunden sein: 5 (GND), 3 (TX) und 2(RX). Auf beiden Seiten sind die Anschlüsse gleich, es ist ein 1:1-Kabel, also keine Drehung von 2 auf 3 o.Ä.

:[[Datei:Luxtronik1-serielles-kabel.jpg]]

Das Bild zeigt ein gelötetes Kabel am USB-RS23-Adapter.
=== Der RS232-USB-Adapter ===
In meinem Fall war das ein USB-Seriell-Adapter (Typ Targus PA088E bzw MCT U232 - gibt es für 13 € bei Ebay. Software ist von MCT.com.tw und läuft bei mir unter Win10 und Win7/64Bit). Andere Adapter sollten genauso funktionieren, wenn es Treiber dafür gibt.

Der FHEM läuft bei mir auf einem BananPi, für den RaspberryPi sollte das selbe gelten. Steckt man den Adapter ein, wird er erkannt. Man kann das leicht mit dem Befehl <code>lsusb</code> prüfen.

Nach Eingabe des Befehls <code>dmesg</code> sieht man, wie das Gerät eingebunden ist:

<pre>[278127.624239] mct_u232 ttyUSB0: MCT U232 converter now disconnected from ttyUSB0
[278127.632780] mct_u232 3-1:1.0: device disconnected
[278206.689646] ehci_irq: port change detect
[278206.912197] ehci_irq: port change detect
[278206.972264] The port change to OHCI now!
[278207.277779] usb 3-1: new full-speed USB device number 4 using sw-ohci
[278207.474278] usb 3-1: New USB device found, idVendor=0711, idProduct=0230
[278207.486502] usb 3-1: New USB device strings: Mfr=1, Product=2, SerialNumber=3
[278207.493495] usb 3-1: Product: Targus Group Intl
[278207.503430] usb 3-1: Manufacturer: Targus Group Intl
[278207.509376] usb 3-1: SerialNumber: 489991
[278207.520277] mct_u232 3-1:1.0: MCT U232 converter detected
[278207.530816] usb 3-1: MCT U232 converter now attached to ttyUSB0</pre>

Wichtig ist die Information welches Devices das nun ist "attached to...", hier <code>/dev/ttyUSB0</code>.
=== Einstellungen der seriellen Schnittstelle ===
Anders, als ich zunächst dachte funktioniert eine Verbindung mit der Standardrate 9.600 Baud nicht. Die richtigen Einstellungen sind:
* 57600 baud
* 8 Bit
* 1 Stopbit
* kein Paritätsbit
* Xon/Xoff Flusskontrolle

==== Minicom (Linux) ====
Damit man ausprobieren kann, ob bis hierher alles funktioniert, kann man das Terminalprogramm minicom (für Linuxkonsolen) verwenden. Der Befehl <code>sudo apt-get install minicom</code> installiert das Programm. Unter <code>/etc/minicom</code> liegt die Datei minirc.dfl, diese enthält bei mir folgende Einstellungen:

<pre># Machine-generated file - use "minicom -s" to change parameters.
pu port /dev/ttyUSB0
pu baudrate 57600
pu bits 8
pu parity N
pu stopbits 1
pu rtscts No</pre>

==== PuTTY (Windows/Linux) ====
Wer den ersten Test von Windows oder der grafischen Konsole von Linux machen will, der kann [http://www.chiark.greenend.org.uk/~sgtatham/putty/ PuTTY] verwenden.

:[[Datei:Luxtronik1_putty.png]]

Ihr müsst dann unter Sessions von "ssh" auf "serial" umstellen. COM1 stimmt natürlich auch nur, wenn es bei euch ebenfalls COM1 ist, dies könnt ihr im Geräte-Manager prüfen.

=== Verbindungstest ===
Der spannende Moment, wenn ihr alles richtig gemacht habt, könnt ihr nun mit der Luxtronik 1 kommunzieren. Für den ersten Test unterstelle ich, dass ihr entweder PuTTY oder Minicom verwendet.
Wenn ihr nun Enter drückt, bekommt ihr ein freundliches <code>777</code> zurück. Gebt ihr <code>1800</code> ein, kommt eine ganze Seite von Zahlen zurück. Super.

== FHEM-Modul Luxtronik1 ==
Leider gibt es kein offizielles FHEM-Modul Luxtronik1 :-(

Todo: Wo bekommt man das inoffizielle Modul her?
== Bekannte Probleme ==
Keine

== Weblinks ==
* heatpumpctl [https://github.com/christophgysin/heatpumpctl/tree/master/doc Dokumentation der Schnittstelle + C-Sourcen]
* Hoerndlein [http://www.hoerndlein.de/cms/index.php/luxtronik-1 Perl-Modul]
* Forumsdiskussion [https://forum.fhem.de/index.php?topic=29740.0]

Luxtronik 1 in FHEM

2017-01-21T16:52:57Z

Hmcontrol:

== Features / Funktionen ==
Die Luxtronik 1.0 ist eine Heizungssteuerung, die in Wärmepumpen von Alpha Innotec, Siemens und Novelan verbaut ist. Ihr fehlt ein Ethernet Anschluss, so dass sie über die vorhandene RS232-Schnittstelle integriert werden muss. Sie ist die Vorgängerversion der LAN-fähigen [[Luxtronik 2.0]], für die ein FHEM-Modul existiert.

== Hinweise zum Betrieb mit FHEM ==
Falls es besondere Einschränkungen / Voraussetzungen, etc. gibt...
# Die Wärmepumpe kann nur über die serielle Schnittstelle angesprochen werden.
# Derzeit wird nur das Auslesen der Konfiguration und Werte unterstützt.

== Verbindung herstellen ==
Damit man die Schnittstelle - die insbesondere für Wartungszwecke da ist - nutzen kann, musst du die nachfolgenden Schritte durchführen.
=== Schnittstelle freigeben ===
Unter ''Einstellungen --> Datenzugang'' die PIN 9445 für den Kundendienstzugang eingeben und bestätigen. Es passiert erstmal nix, es sind jetzt aber weitere Menüs erreichbar. Unter ''Einstellungen --> Diagnose'' Standard auswählen. Damit ist die Schnittstelle freigegeben.
=== Kabel anschließen ===
Jetzt geht es an die Wärmepumpe, diese öffnen. Bei meiner Alpha Innotec ist die Steuerung an der linken Seite hinter einer Metallabdeckung. Dort sieht es dann so aus:

:[[Datei:Luxtronik1-kabel-anschliessen.jpg]]

Der rote Pfeil zeigt den seriellen Anschluss, hier muss das Kabel eingesteckt werden.
=== Das Kabel ===
Es gibt leider viele verschiedene Kabelbelegungen. Daher ist es am einfachsten sich ein Kabel selbst zu löten. Drei PINs müssen verbunden sein: 5 (GND), 3 (TX) und 2(RX). Auf beiden Seiten sind die Anschlüsse gleich, es ist ein 1:1-Kabel, also keine Drehung von 2 auf 3 o.Ä.

:[[Datei:Luxtronik1-serielles-kabel.jpg]]

Das Bild zeigt ein gelötetes Kabel am USB-RS23-Adapter.
=== Der RS232-USB-Adapter ===
In meinem Fall war das ein USB-Seriell-Adapter (Typ Targus PA088E bzw MCT U232 - gibt es für 13 € bei Ebay. Software ist von MCT.com.tw und läuft bei mir unter Win10 und Win7/64Bit). Andere Adapter sollten genauso funktionieren, wenn es Treiber dafür gibt.

Der FHEM läuft bei mir auf einem BananPi, für den RaspberryPi sollte das selbe gelten. Steckt man den Adapter ein, wird er erkannt. Man kann das leicht mit dem Befehl <code>lsusb</code> prüfen.

Nach Eingabe des Befehls <code>dmesg</code> sieht man, wie das Gerät eingebunden ist:

:<code>
[278127.624239] mct_u232 ttyUSB0: MCT U232 converter now disconnected from ttyUSB0
[278127.632780] mct_u232 3-1:1.0: device disconnected
[278206.689646] ehci_irq: port change detect
[278206.912197] ehci_irq: port change detect
[278206.972264] The port change to OHCI now!
[278207.277779] usb 3-1: new full-speed USB device number 4 using sw-ohci
[278207.474278] usb 3-1: New USB device found, idVendor=0711, idProduct=0230
[278207.486502] usb 3-1: New USB device strings: Mfr=1, Product=2, SerialNumber=3
[278207.493495] usb 3-1: Product: Targus Group Intl
[278207.503430] usb 3-1: Manufacturer: Targus Group Intl
[278207.509376] usb 3-1: SerialNumber: 489991
[278207.520277] mct_u232 3-1:1.0: MCT U232 converter detected
[278207.530816] usb 3-1: MCT U232 converter now attached to ttyUSB0
</code>

Wichtig ist die Information welches Devices das nun ist "attached to...", hier <code>/dev/ttyUSB0</code>.
=== Einstellungen der seriellen Schnittstelle ===
Anders, als ich zunächst dachte funktioniert eine Verbindung mit der Standardrate 9.600 Baud nicht. Die richtigen Einstellungen sind:
* 57600 baud
* 8 Bit
* 1 Stopbit
* kein Paritätsbit
* Xon/Xoff Flusskontrolle

==== Minicom (Linux) ====
Damit man ausprobieren kann, ob bis hierher alles funktioniert, kann man das Terminalprogramm minicom (für Linuxkonsolen) verwenden. Der Befehl <code>sudo apt-get install minicom</code> installiert das Programm. Unter <code>/etc/minicom</code> liegt die Datei minirc.dfl, diese enthält bei mir folgende Einstellungen:

:<code>
# Machine-generated file - use "minicom -s" to change parameters.
pu port /dev/ttyUSB0
pu baudrate 57600
pu bits 8
pu parity N
pu stopbits 1
pu rtscts No
</code>

==== PuTTY (Windows/Linux) ====
Wer den ersten Test von Windows oder der grafischen Konsole von Linux machen will, der kann [http://www.chiark.greenend.org.uk/~sgtatham/putty/ PuTTY] verwenden.

:[[Datei:Luxtronik1_putty.png]]

Ihr müsst dann unter Sessions von "ssh" auf "serial" umstellen. COM1 stimmt natürlich auch nur, wenn es bei euch ebenfalls COM1 ist, dies könnt ihr im Geräte-Manager prüfen.

== Bekannte Probleme ==
Keine

== Weblinks ==
* heatpumpctl [https://github.com/christophgysin/heatpumpctl/tree/master/doc Dokumentation der Schnittstelle + C-Sourcen]
* Hoerndlein [http://www.hoerndlein.de/cms/index.php/luxtronik-1 Perl-Modul]
* Forumsdiskussion [https://forum.fhem.de/index.php?topic=29740.0]

Datei:Luxtronik1 putty.png

2017-01-21T16:50:40Z

Hmcontrol:

Datei:Luxtronik1-serielles-kabel.jpg

2017-01-21T16:10:41Z

Hmcontrol: Belegung des 1:1 Kabel für die Luxtronik 1.0 Anbindung.

Belegung des 1:1 Kabel für die Luxtronik 1.0 Anbindung.

Datei:Luxtronik1-kabel-anschliessen.jpg

2017-01-21T15:56:22Z

Hmcontrol: Serielle Schnittstelle der Luxtronik 1.0

Serielle Schnittstelle der Luxtronik 1.0

Luxtronik 1 in FHEM

2017-01-21T15:55:02Z

Hmcontrol: Die Seite wurde neu angelegt: „== Features / Funktionen == Die Luxtronik 1.0 ist eine Heizungssteuerung, die in Wärmepumpen von Alpha Innotec, Siemens und Novelan verbaut ist. Ihr fehlt ein…“

Anwendungsszenarien

2017-01-21T15:17:36Z

Hmcontrol:

Diese Seite stellt eine "redaktionell bearbeitete" Liste von Anwendungsszenarien dar. Weitere, ähnliche Aufstellungen finden sich in den Kategorielisten
* [[:Kategorie:Examples|Examples]] für komplette Beispiele
* [[:Kategorie:Code Snippets|Code Snippets]] für kleine Schnipsel mit einzelnen Befehlen und/oder Definitionen
* und auf der Seite "[[Wie kann ich...]]"

Finden sich hier Links auf Forenbeiträge oder externe Seiten, so sind diese als "gewünschte Seite" zu interpretieren.

== Szenarien ==
{| class="wikitable"
|-
| style="width:50%" | 
* (Haus-)Informations- und Steuerzentrale
** Mittels [[RSS]] generiertes Übersichtsbild (ausführlicher Workshop verfügbar)
** Digitaler Bilderrahmen mit [[Digitaler Bilderrahmen | eingeblendeten FHEM-Daten]] oder zur [[Digitaler_Bilderrahmen_mit_lcd4linux| Anzeige von FHEM-Grafiken]]
** [[Statusdisplay Fritzbox 7390]]
** [[Kindle_Display]] (Fhem Informationen als Screensaver)

* Telefon
** [[Telefonat als Auslöser für Aktionen]]
** ...

* Rollladensteuerung
** [[Jalousie und Beleuchtung in mehreren Räumen]]
** [[Slider für HM-Rolladensteuerung anzeigen]]
** [[Rolladensteuerung mit FS20SM8]]
** ...

* Heizungssteuerung
** [[Grundlagen der Heizungssteuerung]]
** [[Heizungskontrolle Einfach]] (Englische Version: [[Heating Control Basic]])
** [[Junkers Therme Stetigregelung]]
** Heizungssteuerung mit [[HCS]] und/oder [[Heating Control]]
** 3/4-Wege-Mischer-Steuerung mit [[STELLMOTOR]]: [[Mischersteuerung]]
** Vorlauf-Energiebedarf mit [[VALVES]]: [[Raumbedarfsabhängige Heizungssteuerung]]
** Heizungsoptimierung (Mischer, Pumpe) [[Heizung:_Verbrauchsoptimierung,_Radiator/Fußboden-Steuerung]]
** [[Luxtronik 1 in FHEM]] einbinden

* Balkon und Garten
** [[Bewässerungssteuerung]]
** ...

* Lüftung und Klima
** [[Energiesparende Schimmelbekämpfung / Luftentfeuchtung in kritischen Räumen‎]]
** ...

* Auto, Verkehr
** [[Spritpreismonitor]] sammelt und visualisiert die Preisentwicklung an ausgewählten Tankstellen

| style="width:50%" | 

* Finanzen
** [[STOCKQUOTES|Wertpapierkurse verfolgen/protokollieren]]
** ...

* Helligkeitsgeführte Steuerung
** [[Twilight Anwendungsbeispiel]]
** ...

* Terminerinnerungen, Kalenderintegration
** Erinnerung an Müllabfuhr, etc.: {{Link2Forum|Topic=26209|LinkText=Forenthema}} und ein {{Link2Forum|Topic=32382|LinkText=weiteres Forenthema}}
** ...

* Zugriff auf FHEM "von außen"
** [[FritzBox Webzugriff absichern]]
** [[FB7390 VPN-Zugang einrichten]]
** ...

* Anwesenheitssimulation / -steuerung
** [[Anwesenheitserkennung]]
** ...

* Zugangskontrolle, Fenster, Tür und Tor
** [[DoorPi_und_FHEM | Türsprechstelle mit DoorPi]]
** [[Garagentorsteuerung]]
** {{Link2Forum|Topic=11715|LinkText=Zugangskontrolle mit Keymatic, Fingerabdruck, RFID}} (Forum; sollte noch ins Wiki integriert werden)
** ...

* (Video-)Überwachung
** Einbindung von (Web-)Cam Bildern / Streams
** ...

* Energieverbrauch / -erzeugung
** [[Ertragsmessung Solarthermie]]
** [[Heizleistung und Gasverbrauch]]

* Rundfunk / Fernsehen / Multimedia
** {{Link2Forum|Topic=28123|LinkText=Aktuelles TV-Programm}} auflisten (Forenthema)
** ...

* Sonstiges
** [[Watchdog kombiniert mit Threshold|Auf ausbleibende Aktionen oder Ereignisse reagieren]]
** mit Fhem realisierte [[Zeitschaltuhr]]
** [[Temperaturfarbe | Temperatur in Farbe]]
|}

Sofern hier statt Verweisen auf andere Wiki-Seiten Forenthemen verlinkt sind, sind alle Wiki-Schreiber herzlich eingeladen, die Informationen aus dem Forum in einer (neuen) Wiki-Seite zu konsolidieren.

[[Kategorie:Examples]]

HM-Sec-SCo Tür-Fensterkontakt, optisch

2017-01-21T15:10:34Z

Hmcontrol:

{{Infobox Hardware
|Bild=HM-SEC-SCo.jpg
|Bildbeschreibung=HomeMatic Tür-Fensterkontakt, optisch
|HWProtocol=HomeMatic
|HWType=Sensor
|HWCategory=HomeMatic
|HWComm=868MHz
|HWChannels=1
|HWVoltage=1,5 V DC
|HWPowerConsumption=max. 100 mA
|HWPoweredBy=Batterie (1x 1,5V LR03/Micro/AAA)
|HWSize=15x100x18mm
|HWDeviceFHEM=[[CUL_HM]]
|HWManufacturer=ELV / eQ-3
}}

== Features ==
[[HomeMatic]] Funk-Tür-/Fensterkontakt zur optischen Erkennung von Tür- bzw. Fensteröffnungen oder -schließungen, z.B. zur Sicherheit oder um automatisch, bei vorhandenem [[HM-CC-RT-DN]], die Heizung herunter zu regeln, sobald ein Fenster oder eine Tür geöffnet wird.

== Hinweis ==
Das meiste zum [[HM-SEC-SC Tür-Fensterkontakt|HM-SEC-SC]] Beschriebene zur Nutzung gilt auch für den HM-Sec-SCo.

Wird mit aktiviertem [[AES Encryption|AES]] ausgeliefert und kann nur mit Gateways, die AES unterstützen, gepaired werden ([[HM-CFG-USB USB Konfigurations-Adapter|HM-LAN-CFG]], [[HM-CFG-LAN LAN Konfigurations-Adapter|HM-USB-CFG]] und [[CUL]] (seit Juli 2015)).

Mindestens bei Benutzung mit einem CUL (vermutlich auch via HM-CFG-USB und HM-CFG-LAN) muss FHEM auf das Perl-Modul Crypt::Rijndael zugreifen können. Wenn es nicht zur Verfügung steht, bleibt das Pairing unvollständig. Siehe auch [[AES_Encryption#IO <-> Gerät|den Abschnitt über AES-Encryption zwischen IO-Device und Gerät]].

== Betrieb mit FHEM ==
=== Event-Monitor ===
Wird z. B. das Fenster geöffnet, wird Folgendes vom Gerät übermittelt:
<pre>
2015-02-08 20:04:24 CUL_HM HM_Fensterstatus_BadEG trigger_cnt: 11
2015-02-08 20:04:24 CUL_HM HM_Fensterstatus_BadEG trigDst_2573FB: noConfig
2015-02-08 20:04:24 CUL_HM HM_Fensterstatus_BadEG battery: ok
2015-02-08 20:04:24 CUL_HM HM_Fensterstatus_BadEG open
2015-02-08 20:04:24 CUL_HM HM_Fensterstatus_BadEG contact: open (to MyHMLAN)
</pre>

Beim Schließen wird Folgendes übermittelt:
<pre>
2015-02-08 20:04:31 CUL_HM HM_Fensterstatus_BadEG trigger_cnt: 12
2015-02-08 20:04:31 CUL_HM HM_Fensterstatus_BadEG trigDst_2573FB: noConfig
2015-02-08 20:04:31 CUL_HM HM_Fensterstatus_BadEG battery: ok
2015-02-08 20:04:31 CUL_HM HM_Fensterstatus_BadEG closed
2015-02-08 20:04:31 CUL_HM HM_Fensterstatus_BadEG contact: closed (to MyHMLAN)
</pre>

=== Konfiguration ===
{{Randnotiz|RNText='''Info zum Bausatz'''
Das Gerät ist als Bausatz verfügbar, es sind nur
* das Funkmodul mit einer 8-poligen Stiftleiste
* der Batteriekontakt (Minuspol) mit einem kurzen Drahtstück
[[Datei:HM-Sec-SCo_Basisplatine.jpg|mini|250px|Markiert: Antennendurchführung (1), Batterieanschluss (2), sehr schmaler Platinensteg (3)]]
an der Basisplatine anzulöten.
Zu beachten ist noch, dass die Antenne '''vor''' dem Auflöten des Funkmoduls durch das markierte Loch der Basisplatine geführt werden muss.

Die fertig montierte Platine muss sich leicht in das Gehäuse einsetzen lassen, anderenfalls wird der schmale Platinensteg u.U. zu stark belastet und kann brechen!
'''Bauzeit''': < 15 Minuten
}}
Bei eingeschaltetem [[autocreate]] werden die erforderlichen Definitionen beim Pairen selbstständig erstellt.

<pre>
define HM_Fensterstatus_BadEG CUL_HM 35E390
attr HM_Fensterstatus_BadEG IODev MyHMLAN
attr HM_Fensterstatus_BadEG actCycle 000:50
attr HM_Fensterstatus_BadEG actStatus dead
attr HM_Fensterstatus_BadEG autoReadReg 4_reqStatus
attr HM_Fensterstatus_BadEG expert 2_full
attr HM_Fensterstatus_BadEG firmware 1.0
attr HM_Fensterstatus_BadEG model HM-SEC-SCo
attr HM_Fensterstatus_BadEG peerIDs 00000000,
attr HM_Fensterstatus_BadEG room CUL_HM
attr HM_Fensterstatus_BadEG serialNr LEQxxxxxxx
attr HM_Fensterstatus_BadEG subType threeStateSensor
</pre>

== Beispiele ==
=== Aktionen durchführen, wenn Fenster zu lange geöffnet ist ===
==== DOIF-Variante ====
Mit der nachfolgenden [[DOIF]]-Definition wird ein [[FileLog|Log]]-Eintrag erzeugt, eine Meldung auf der [[Enigma2 Receiver (Dreambox, VUplus etc.) steuern|Dreambox]] angezeigt, falls diese angeschaltet ist, und eine Nachricht per Prowl (funktioniert vermutlich nur unter Linux) verschickt.

Der Code ist hier so angegeben, wie er in der Weboberfläche nach einem Klick auf das [[Konfiguration|DEF-Feld]] übernommen werden kann. Das DOIF ist vorab zu definieren, zum Beispiel mit:
:<code>def DOIF_FensterOffenMsg DOIF ([HM_Fensterstatus_BadEG])</code>
und kann dann anschließend in den Device-Details vervollständigt werden:
<source lang="perl">
([HM_Fensterstatus_BadEG] eq "open") ({
Log 1, "Fenster seit mehr als 2 Stunden (7200 Sekunden) offen";;
system( "/path/to/prowl.pl -apikeyfile=/path/to/prowl-apikey -event=Info -notification='Fenster ist noch offen' &" );;
fhem( "set E2_Dreambox showText Fenster ist noch offen" ) if ReadingsVal("E2_Dreambox","state","") eq "on";;
})
DOELSE
</source>

Damit der Code-Block erst nach 7200 Sekunden getriggert wird, ist noch Folgendes auszuführen:

:<code>attr DOIF_FensterOffenMsg wait 7200:0</code>
==== Watchdog-Variante ====
Alternativ zu der DOIF-Lösung gibt es auch eine einfache Lösung mit [[Watchdog]]. Dazu legt ihr einen Watchdog an:
:<code>define watchdogBadEG watchdog HM_Fenster_BadEG:open 00:15 HM_Fenster_BadEG:closed set myTelegram message Das Fenster ist seit 15 min offen!</code>
Der Watchdog besagt, dass er beim Status "open" des Gerätes/Devices "HM_Fenster_BadEG" (also dem Fenstersensor) aktiviert wird. Nach 15 Minuten schickt er eine Nachricht über [[Telegram]], es sei denn es kommt zwischenzeitlich der Statu "closed".

=== Anzeige des Zeitpunkts der letzten Öffnung im STATE ===
Das Reading ''contact'' beinhaltet die Zustände ''open'' und ''closed''. Und der Zeitstempel der Änderung wird regelmäßig aktualisiert. Aus diesem Grund fällt die Nutzung des Attributs ''showtime'' hier weg. Wenigstens, wenn man nicht den Zeitpunkt des letzten Auslesens wissen will, sondern den der letzten Öffnung.

Folgende Schreibweise ermöglicht es, dass im STATE-Internal der Zeitpunkt des letzten ''open'' verbleibt (zum Übernehmen als Einzeler kopieren):
:<code><nowiki>attr Sensor stateFormat {if (ReadingsVal("Sensor","contact","") =~ "open.*") {"open " . ReadingsTimestamp("Sensor","contact","")} else {InternalVal("Sensor","STATE","")}}</nowiki></code>

Ein Thread zu diesem Thema findet sich im Forum unter dem Titel {{Link2Forum|Topic=41347|LinkText=HM-SEC-SCo: Letzte Türöffnung im State anzeigen}}.

== Bekannte Probleme ==
Teilweise (siehe Diskussion im {{Link2Forum|Topic=33264|LinkText=Forum}}) werden die Fensterkontakte regelmäßig wiederkehrend als "dead" angezeigt. Grund ist, dass beim Anlernen ein actCycle von 50 Minuten eingetragen wird, während die Kontakte auch gerne mal länger brauchen, um sich bei der Zentrale zu melden.
<pre style="width:500px;">
2015-01-31_17:57:39 Fstr_AusgTerrasse alive: yes
2015-01-31_17:57:39 Fstr_AusgTerrasse battery: ok
2015-01-31_17:57:39 Fstr_AusgTerrasse sabotageError: off
2015-01-31_17:57:39 Fstr_AusgTerrasse closed
2015-01-31_17:57:39 Fstr_AusgTerrasse contact: closed (to HMLAN1)
2015-01-31_18:54:09 Fstr_AusgTerrasse Activity: dead
2015-01-31_18:58:03 Fstr_AusgTerrasse alive: yes
2015-01-31_18:58:03 Fstr_AusgTerrasse battery: ok
2015-01-31_18:58:03 Fstr_AusgTerrasse sabotageError: off
2015-01-31_18:58:03 Fstr_AusgTerrasse closed
2015-01-31_18:58:03 Fstr_AusgTerrasse contact: closed (to HMUSB)
2015-01-31_19:04:09 Fstr_AusgTerrasse Activity: alive
</pre>

Um Abhilfe zu schaffen, den actCycle auf 01:05 setzen:
:<code>attr <HM-SEC-SCo> actCycle 001:05</code>

Save config nicht vergessen.

== Links ==
* Anleitung [http://www.eq-3.de/Downloads/eq3/downloads_produktkatalog/homematic/bda/HM-Sec-SCo_UM_GE_eQ-3_web.pdf PDF]
* Datenblatt [http://www.eq-3.de/service/downloads.html?id=235&download=produkt&pid=1947 PDF] (der direkte Link auf das PDF klappt nicht, vermutlich wegen der Codierung des Umlautes :-( )
[[Kategorie:HomeMatic Components]]
[[Kategorie:Kontaktsensor (optisch)]]

Diskussion:MAX

2017-01-21T12:55:30Z

Hmcontrol: /* Codeschnipsel für HomeMatic-Fenster im MAX-Artikel */

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)

== Codeschnipsel für HomeMatic-Fenster im MAX-Artikel ==
Hier [[MAX#Telegram-Benachrichtigung_bei_dauerge.C3.B6ffnetem_Fenster]] wurden Code-Anpassungen für HomeMatic-Fensterkontakt mit dem Hinweis aufgenommen, dass der HomeMatic-Fensterkontakt baugleich zum MAX-Fensterkontakt ist. Das ist meiner Meinung nach nicht so. Einen MAX-Fensterkontakt kann ich nicht mit HomeMatic-Protokoll ansprechen und umgekehrt. Daher ist die Ergänzung in diesem Artikel deplaziert und falsch. Zudem verwirrt dies. Plane daher das rückgängig zu machen und erbitte Kommentare.
Gruß, --[[Benutzer:Krikan|Christian]] ([[Benutzer Diskussion:Krikan|Diskussion]]) 12:29, 21. Jan. 2017 (CET)
<hr />
:Hallo Christian - ist mir mit genau den gleichen Gedanken aufgefallen. Sollte da keine Erklärung / Erläuterung kommen, bin ich auch für "revert". --[[Benutzer:Ph1959de|Peter]] ([[Benutzer Diskussion:Ph1959de|Diskussion]]) 12:43, 21. Jan. 2017 (CET)
::Ersteller der Änderung ist per PM informiert. --[[Benutzer:Krikan|Christian]] ([[Benutzer Diskussion:Krikan|Diskussion]]) 12:52, 21. Jan. 2017 (CET)
<hr />
: Hallo, ich habe die Änderung gemacht. Ist der Status bei wirklich "opened" oder auch "open"? In letzterem Fall - hier geht es ja nur um den Watchdog! - ist meine Ergänzung natürlich überflüssig. Der Watchdog funktioniert natürlich unabhängig ob es MAX oder Homematic ist. Zum Thema baugleich: Sollte der Status bei MAX "opened" sein, schlage ich vor, dass ich es in "optisch ähnlich" ändere, das wollte ich ausdrücken. 13:55, 21.01.2017

MAX

2017-01-21T09:43:54Z

Hmcontrol: Status open für Homematic ergänzt.

'''MAX!''' ist eine Heizungssteuerung, die die Raumtemperatur durch funkvernetzte Heizkörperthermostate an den Heizkörpern regelt. MAX! stellt eine Alternative zur [[:Kategorie:FHT Components|FHT]] und [[HomeMatic]] Heizungsteuerung dar.

== Features ==
* Bidirektionale Kommuniktion (jeder Befehl wird mit ACK quittiert)
* Heizkörperthermostate übertragen auch die gemessene Temperatur

== FHEM Module ==
Die MAX Komponenten können über den MAX!Cube per Modul 00_MAXLAN oder über einen [[CUL]] oder [[CUNO]] per 14_CUL_MAX gesteuert werden. In beiden Fällen werden die einzelnen MAX! Geräte vom Modul 10_MAX
bereitgestellt. Alternativ kann man nach [http://forum.fhem.de/index.php/topic,38404.0.html] einen MAX!CUBE als CUNO umflaschen.

Nachteil vom Cube ist, dass man ein Polling machen muss, um zu sehen ob sich der Status eines Gerätes geändert hat. Z.B. checkt man das alle 30 Sekunden. Dann sieht man aber auch Änderungen möglicherweise erst nach 30 Sekunden. Beim CUL sieht man die Funknachrichten direkt. Es wird aber auch ein Kombimodus unterstützt, in welchem man alles über den MAXLAN steuert, der CUL_MAX aber für zeitnahe Benachrichtigungen sorgt.

== Komponenten ==
=== Limit ===
* Auf 8 Thermostate pro Raum beschränkt
* Limit mit Cube liegt bei ca. 140 Geräten. Durch die [[1% Regel]] dürften es aber in der Praxis weniger sein

=== Heizkörperthermostate ===
Unterstützt wird das Einstellen von

* desiredTemperature = auto (Wochenprogramm), manuell (4.5 - 30.5), eco, comfort, boost, until
** (Besonderheit der Werte: 4.5 = Off und 30.5 = On)
* ecoTemperature, comfortTemperature, measurementOffset, maximumTemperature, minimumTemperature, windowOpenTemperature, windowOpenDuration

und das Auslesen

* der gemessenen Temperatur. (Hinweis: Wird bei Verwendung des MAX CUBE nicht regelmäßig aktualisiert)

=== Fensterkontakte ===
Der aktuelle Status (offen/geschlossen) wird (praktisch ohne Verzögerung) angezeigt.

Falls wir nicht mit Ack antworten, wird er mehrmals wiederholt.

Die Fensterkontakte können zusätzlich direkt an mehrere Heizkörperthermostate angelernt werden, und versetzen diese dann automatisch in windowOpenTemperature während sie geöffnet sind.

Wenn der Fensterkontakt an mindestens ein Heizkörperthermostat angelernt ist, dann sendet er zusätzlich stündlich seinen aktuellen Zustand.

'''Beispiel Autocreate'''
MAXLAN_Parse: Paired new device, type ShutterContact, addr 1a2b3c, serial JEQ0123456
autocreate: define MAX_1a2b3c MAX ShutterContact 1a2b3c
autocreate: define FileLog_MAX_1a2b3c FileLog /fhem/log/MAX_1a2b3c-%Y.log MAX_1a2b3c

'''Beispiel Definition'''
define MAX_1a2b3c MAX ShutterContact 1a2b3c

'''Beispiel Log'''
==> MAX_1a2b3c-2013.log <==
2013-10-20_18:52:08 MAX_1a2b3c battery: ok
2013-10-20_18:52:08 MAX_1a2b3c onoff: 0
2013-10-20_18:52:08 MAX_1a2b3c closed

=== Wandthermostate ===
Unterstützt wird das Einstellen von

* desiredTemperature (siehe Heizkörperthermostate), ecoTemperature, comfortTemperature

und das Auslesen

* der gemessenen Temperatur.

=== Eco-Taster ===
'''Achtung''': Zumindest über MAXLAN lässt sich der Zustand weder auslesen, noch wird man über Veränderungen informiert.

Per CUL_MAX funktioniert der Eco-Taster problemlos.

==== Beispielhafte Definition ====
:<code>define BUTTON.EG MAX PushButton 069d33</code>

==== Beispielhafte Event-Ausgabe ====

2013-07-02 21:06:14 MAX BUTTON.EG battery: ok
2013-07-02 21:06:14 MAX BUTTON.EG onoff: 0
2013-07-02 21:06:14 MAX BUTTON.EG closed

Wobei gilt
{| class="wikitable"
|-
! onoff !! Bedeutung
|-
| 0 || Eco
|-
| 1 || Auto
|}

== Anlernen per CUL ==
Das Anlernen funktioniert nur mit zurückgesetzen (Werksreset, also entweder alle 3 Tasten am Heizkörperthermostate betätigen, Batterien einlegen, Anzeige rES; oder in FHEM set factoryReset) Heizkörperthermostaten. Bereits an einen Cube angelernte Heizungsregler können '''nicht''' an ein CUL angemeldet werden, hier ist dann nur das "mitlesen" der Funkbotschaften möglich.

Info: Durch den Reset geht auch ein evtl. per Cube eingestelltes Automatikprogramm verloren.

== Konfiguration ==
Siehe [http://fhem.de/commandref.html#CUL_MAX commandref].

Die Module sind so konzipiert, dass man die offizielle Max! Software nicht benutzen muss. Man kann alles aus FHEM heraus machen. Nachdem das MAXLAN oder CUL_MAX Modul konfiguriert wurden (siehe unten), werden bereits gepairte Geräte automatisch erkannt.

=== MAXLAN ===
Minimale Konfiguration:
:<code>define ml MAXLAN 192.168.178.2</code>
wobei 192.168.178.2 die IP des MAX! Cube ist. Das MAXLAN-Modul findet selbstständig bereits gepairte Geräte und trägt diese in die Konfigurationsdatei fhem.cfg ein. Diese können dann im WEB-Interface mittels „alias“ einen eindeutigen Namen bekommen.

=== CUL_MAX ===
Minimale Konfiguration:

<nowiki>define CUL0 CUL /dev/ttyACM0@9600 0000
attr CUL0 rfmode MAX
define cm CUL_MAX 123456</nowiki>

=== Anlernen ===
Dazu muss der "pairmode" auf MAXLAN mit
:<code>set ml pairmode</code>
bzw. bei CUL_MAX mit
:<code>set cm pairmode</code>
oder über das Web-Interface aktiviert werden. Falls kein Parameter angegeben wird, ist er standardmäßig für 60 Sekunden aktiviert. In dieser Zeit können MAX! Geräte nach deren Anleitung in den Anlernmodus versetzt werden, um sie mit FHEM zu pairen.

=== Geräte untereinander anlernen ===
Die MAX-Devices können direkt untereinander angelernt werden. Dazu gibt es den "associate"-Befehl in FHEM, mit dem die Geräte untereinander
angelernt werden. Er muss in jede Richtung einmal verwendet werden, also sowohl z.B. Fensterkontakt an Thermostat wie auch umgekehrt.
Also
:<code>set Heizthermostat1 associate Fensterkontakt1</code>
:<code>set Fensterkontakt1 associate Heizthermostat1</code>
Während Wand- und Heizkörperthermostat stets empfangsbereit sind, benötigt der Fensterkontakt zum "Wecken" einen Schaltvorgang
des Reed-Relays (Fenster öffnen oder schließen). Von einer eventuellen Log-Meldung
:<code>There is a packet for ShutterContact Fensterkontakt1 in queue. Please push the button on the respective ShutterContact so the packet can be send.</code>
bitte nicht verwirren lassen: Den Anlern-Button auf der Rückseite zu drücken, wäre völlig falsch! Sofern das Paring erfolgreich war, sich im Logfile aber diese
Meldung trotzdem alle 3 Sekunden wiederholt, hilft ein Restart von FHEM.

Jetzt wechselt Heizthermostat1 immer dann auf die windowOpenTemperature, wenn der Fensterkontakt1 offen ist. Dabei muss die groupId von beiden Geräte nicht gleich sein.

Ebenso können Wand- mit Heizkörperthermostaten gekoppelt werden. Temperaturänderung am Wandthermostaten werden so an den / die Heizkörper gesendet.
Allerdings leitet das Wandthermostat nur Änderungen weiter, die am Wandgerät selbst (manuell) vorgenommen wurden. Wer also via FHEM die <code>desiredTemperature</code> an den
Wandthermostaten sendet, verändert damit weder direkt noch indirekt die Einstellung der assoziierten Heizkörper, sondern muss auch an diese Heizkörper senden.

=== Temperatursturzerkennung ===
Die Heizkörperthermostate verfügen über eine interne "Fenster-offen Erkennung" (Temperatursturzerkennung). Wird diese ausgelöst, regeln sie für die Zeit die unter "windowOpenDuration" festgelegt wurde auf die als "windowOpenTemperature" festgelegt Temperatur herunter und danach wieder auf die zuvor eingestellte Temperatur zurück.

Nachteil: Die Erkennung benötigt etwas Zeit und reagiert nicht sofort wie es beim Fensterkontakt oben der Fall ist

Vorteil: Es ist kein Fensterkontakt erforderlich

'''Wichtig:''' Setzt man die windowOpenTemperature auf "Off" (= 4.5 Grad), dann ist die Fenster-offen-Funktion abgeschaltet. Und auch wenn die desiredTemperature gerade auf "On" (= 30.5 Grad") steht, geht der Heizkörper nicht in die Fenster-offen-Funktion.

=== Telegram-Benachrichtigung bei dauergeöffnetem Fenster ===
Einen schönen Einstieg in die Event- und Watchdog-Verarbeitung von FHEM bildet die zeitversetzte Benachrichtigung per Telegram, wenn
das Fenster länger offen stehen gelassen wurde.

Ist ein Telegram-Bot eingerichtet (siehe [[TelegramBot]], und der Default-Peer gesetzt, so
reicht ein

:<code> define w1 watchdog Fensterkontakt1:opened 00:12 Fensterkontakt1:closed set Telegram message Das Fenster ist seit 12 min offen!</code>

um pünktlich nach 12 Minuten eine Erinnerungs-Nachricht zu erhalten: Penetrant und schnell wie SMS, kostenlos wie Mail!

Bei den baugleichen Fensterkontakten aus dem Homematic-Programm (HM-SEC-SCo) heißt der Status "open" (nicht opened), daher muss der o.g. Watchdog wie folgt aussehen:

:<code> define w1 watchdog Fensterkontakt1:open 00:12 Fensterkontakt1:closed set Telegram message Das Fenster ist seit 12 min offen!</code>

=== Externer Sensor für Fenster-offen-Erkennung ===
'''Achtung''': Wird nur von CUL_MAX unterstützt!

Ziel dieses Abschnittes ist es, einen externen Sensor (z.B. 1-Wire o.ä.) zu benutzen, um die MAX Heizkörperthermostate in und aus dem Fenster-offen Modus zu holen. Dazu sei bereits ein CUL, ein CUL_MAX und ein MAX Heizkörper definiert:

<nowiki>define CUL0 CUL /dev/ttyACM0@9600 0000
define cm CUL_MAX 123456
define Heizung MAX HeatingThermostat abcdef
attr Heizung IODev cm</nowiki>

Wir müssen einmalig den internen Fake-Fensterkontakt mit dem Heizkörper assozieren
:<code>set Heizung associate fakeShutterContact</code>
damit dieser die Nachrichten vom Fensterkontakt akzeptiert.

Nun können wir per
:<code>set cm fakeSC Heizung 1</code>
die Nachricht "Fenster offen" an die Heizung senden und per
:<code>set cm fakeSC Heizung 0</code>
die Nachricht "Fenster zu".

=== Externer Temperatursensor für Heizkörperregelung ===
'''Achtung''': Wird nur von CUL_MAX unterstützt!

Ziel dieses Abschnittes ist es, einen externen Sensor (z.B. 1-Wire o.ä.) zu benutzen, um die MAX Heizkörperthermostate zu regeln. Dazu sei bereits ein CUL, ein CUL_MAX und ein MAX Heizkörper definiert:

<nowiki>define CUL0 CUL /dev/ttyACM0@9600 0000
define cm CUL_MAX 123456
define Heizung MAX HeatingThermostat abcdef
attr Heizung IODev cm</nowiki>

Wir müssen einmalig das interne Fake-Wandthermostat mit dem Heizkörper assozieren:
:<code>set Heizung associate fakeWallThermostat</code>
damit dieser die Nachrichten vom Wandthermostat akzeptiert. Achtung: Dies schaltet im
Heizkörperthermostat die Regelung mit dem internen Temperaturfühler aus. Ohne die gleich kommenden "fakeWT" Nachrichten wird das Heizkörperthermostat nicht mehr regeln.

Nun können wir per
:<code>set cm fakeWT Heizung 14.5 12.1</code>
die desiredTemperature 14.5 und gemessene Temperatur 12.1 an die Heizung senden. Diese wird dann die Ventile öffnen, bis wir ein "fakeWT" absetzten, dessen gemessene Temperatur höher als die desiredTemperature ist.

Falls man zu lange Zeit (ca. 30 Minuten) kein neues "fakeWT" sendet, wird bei der Heizung das Attribut rferror gleich 1. Es ist nicht klar, ob das neben diesem Attribut auch Auswirkung auf die Funktionalität hat. Es wurde beobachtet, dass dann der interne Temperatursensor bis zum nächsten FakeWT aktiviert wird.

Beispiel eines automatischen Sendens einer externen Temperatur, der externe Temperatursensor heißt "WS300":

<nowiki>define SendExtTemp notify WS300:temperature.* {
MaxFakeWallThermostat("Heizung", $EVTPART1);
}</nowiki>

Dazu die Funktion, bitte in 99_MyUtils.pm eintragen:

sub MaxFakeWallThermostat($$)
{
my ($heizung, $aktTemp) = @_;
my $CULMAX = $defs{$heizung}{LASTInputDev};
my $desiredTemp = ReadingsVal($heizung, "desiredTemperature", undef);
my $windowOpenTemp = ReadingsVal($heizung, "windowOpenTemperature", undef);
my $lastTemp = ReadingsVal($heizung, "LastExtTemperature", 0);
my $lastSet = ReadingsTimestamp($heizung, "LastExtTemperature", 0);
if($desiredTemp && $windowOpenTemp &&
$desiredTemp != $windowOpenTemp &&
(time()-time_str2num($lastSet) >= 600 || abs($aktTemp-$lastTemp)>=0.2 )) {
Log 3, "set $CULMAX fakeWT $heizung $desiredTemp $aktTemp";
readingsSingleUpdate($defs{$heizung}, "LastExtTemperature", $aktTemp, 0);
fhem("set $CULMAX fakeWT $heizung $desiredTemp $aktTemp");
}
}

In diesem Beispiel heißt das zu steuernde Thermostat "Heizung". Die vom externen Sensor gemessene Temperatur wird nur unter den folgenden Voraussetzungen gesendet:
* das Thermostat befindet sich nicht im "Fenster-offen" Modus, und
* das letzte Senden liegt mindestens 10min zurück
* oder die gemessene Temperatur weicht um mindestens 0.2°C von der letzten gesendeten Temperatur ab

=== Wochenheizplan für Wandthermostat/Ventilantriebe erstellen ===
Ein Heizplan, den das Wandthermostat und auch der Ventilantrieb versteht und speichern kann, sieht folgendermaßen aus:
:<code>set WZ_Wandthermostat weekProfile Mon 17,17:30,20,23:00,17 Tue 17,17:30,20,23:00,17 Wed 17,17:30,20,23:00,17 Thu 17,17:30,20,23:00,17 Fri 17,15:00,20,23:00,17 Sat 17,11:00,20,23:00,17 Sun 17,11:00,20,23:00,17</code>
Genauer erläutert wird die Funktionsweise auch in der [http://fhem.de/commandref.html#MAX commandref].

Der gesamte Block kann kopiert und als FHEM Befehl abgesetzt werden. Unter Umständen benötigt das Speichern bzw. Übertragen wegen der Größe etwas Zeit, bevor die aktuellen, neu gesetzten Werte wieder ausgelesen werden können.

'''Bitte folgendes beachten:'''

Es gibt im Zusammenhang mit dem Wochenprogramm ein Problem mit dem letzten Schaltpunkt des Tages.
Der Workaround wurde [http://forum.fhem.de/index.php/topic,17231.msg112738.html#msg112738 hier]
beschrieben.
Man muss dafür sorgen, dass man kurz vor Ende des Tages noch einen Schaltpunkt setzt! Bei mir hat sich ein Schaltpunkt (ohne Änderung der Soll-Temperatur) um 23:55 bewährt:
:<code>set WZ_Wandthermostat weekProfile Mon 17,17:30,20,22:00,17,23:55,17</code>

=== Werte Plotten ===
[[File:Plot_MAX_Beispiel.png|thumb|right|Plot eines MAX Heizkörperthermostates]]
In den Log-Dateien wird regelmäßig der Batteriestatus, die Soll-Temperatur, die Ventilstellung und die Ist-Temperatur (Vorsicht: Wird nicht zuverlässig, möglicherweise nur bei einer Änderung der Ventilstellung übertragen.)

Inhalt der LOG-Datei eines Heizkörperthermostates:

<nowiki>2012-12-30_08:55:31 MAX_018d3f battery: ok
2012-12-30_08:55:31 MAX_018d3f desiredTemperature: 19.5
2012-12-30_08:55:31 MAX_018d3f valveposition: 83
2012-12-30_08:55:31 MAX_018d3f temperature: 16.4</nowiki>

Mit folgender Plot-Datei (max_temp.gplot) kann der Verlauf der Sensordaten gut angezeigt werden.

<nowiki>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 y2tics
set title '<L1>'
set grid xtics y2tics
set y2label "Temperatur in Grad Celsius"
set ylabel "Signal in %"
#FileLog 4:desiredTemperature:0:
#FileLog 4:temperature:0:
#FileLog 4:valveposition:0:
plot \
"< egrep 'desiredTemperature' <IN>"\
using 1:4 axes x1y2 title 'Soll-Temperatur (C)' with lines lw 2 \
"< egrep 'temperature' <IN>"\
using 1:4 axes x1y2 title 'Ist-Temperatur(ungenau)(C)' with lines lw 2 \
"< egrep 'valveposition' <IN>"\
using 1:4 axes x1y1 title 'Ventil (%)' with lines lw 2</nowiki>
Einbinden eines Plots in der fhem.cgf

<nowiki>#Werte plotten
define MAX_017840_weblink weblink fileplot FileLog_MAX_017840:max_temp:CURRENT
attr MAX_017840_weblink label "Kueche Soll-Temperatur Min $data{min1}, Max $data{max1}, Last $data{currval1}"
attr MAX_017840_weblink room MAX</nowiki>

=== Nützliche kleine Erweiterungen ===
'''Einen Alias-Namen vergeben für eine bessere Lesbarkeit im Webinterface'''
:<code>attr MAX_018d3f alias Kueche</code>
'''Die Anzeigen für die einzelnen File-Logs füllen das Webinterface schnell und machen es unübersichtlich.''' Die File-Logs können einfach in einen separaten Raum verbannt werden.
:<code>attr FileLog_MAX_018d3f room LOG</code>
'''Einstellmöglichkeit für die Soll-Temperatur direkt in der „Raum-Seite“ schaffen.''' Die Temperatur wird dauerhaft auf einen bestimmten Wert gestellt. Das Wochenprogramm in dem Thermostat wird deaktiviert.
:<code>attr MAX_018d3f webCmd desiredTemperature</code>

'''Soll-Temperatur setzen, ohne das automatische Programm des Thermostates abzuschalten.'''
Es besteht die Möglichkeit eine Soll-Temperatur bis zum nächsten Schaltzeitpunkt zu setzen. Zum Beispiel kann das automatische Wochenprogramm in den Thermostaten dazu genutzt werden, nur abends die Soll-Temperatur zu senken. So läuft die Heizung nachts nicht voll durch. Wenn jedoch die Temperatur im Web-Interface von Fhem verändert wird, wird auch der Thermostat auf manuell gesetzt. So greift das Wochenprogramm nicht mehr. Abhilfe schafft der Befehl
:<code>set MAX_04711 desiredTemperature auto 20</code>
Damit die Eingabe komfortabel aus Fhem möglich ist, kann ein Dummy-Device erstellt werden:

<nowiki>#Dummy für die Schnell-Einstellung der Temperatur bis zum nächsten automatischen Schaltzeitpunkt
define HeizkoerperBad dummy
attr HeizkoerperBad room MAX,Heizungen
attr HeizkoerperBad setList state:eco,auto,14.0,16.0,17.0,18.0,19.0,20.0,21.0,22.0,23.0
attr HeizkoerperBad webCmd state
define HeizkoerperBad.ntfy notify HeizkoerperBad.* {\
my $valtemp = "$EVENT";;\
my $device = "MAX_04711";;\
my $cmd = 'set '.$device.' desiredTemperature auto '.$valtemp;;\
fhem($cmd);;\
}</nowiki>
Dieses Dummy-Device kann alternativ oder ergänzend zu <code>attr MAX_018d3f webCmd desiredTemperature</code> verwendet werden.

== Internals ==
=== IST-Temperaturwerte ===
[[File:Plot_MAX_Beispiel.png|thumb|right|Plot eines MAX Heizkörperthermostates]]
Diese Abbildung zeigt, dass die IST-Temperatur nicht regelmäßig dem MAX CUBE mitgeteilt wird. Im Automatikbetrieb wird bei einer Änderung der Ventilstellung die neue Ventilstellung zusammen mit der aktuellen IST-Temperatur gesendet. Bei der Abbildung war die Therme in der Nacht ausgeschaltet. Daraufhin sank die Temperatur soweit ab, dass das Heizungsthermostat das Ventil in Maximalstellung geöffnet hat. Gegen 08:50 wurde die Therme eingeschaltet und die Soll-Temperatur an diesem Heizungsthermostat erhöht. Während dieser ganzen Zeit erfolgt keine Aktualisierung der Ist-Temperatur. So kommt es auch gegen 10:30 zu einem sprunghaften Temperaturanstieg von 13,5°C auf 19°C (siehe Markierung *A).

Die IST-Temperatur wird anscheinend aktualisiert bei einer Änderung der:

* Ventilstellung
* Soll-Temperatur
* des Betriebsmodus (Auto/Manuell)

Wer eine detaillierte Kurve wünscht, sollte sich den [[MAX! Temperatur-Scanner]] ansehen.

=== MAXLAN ===
=== CUL_MAX ===
The Max devices use a CC1100 chip. For parameters see rf_moritz.c in culfw.
The thermostats use a Wake-On-Radio, thus one has to send packets at the right time.

CC1100 initialization sequence on one of the max devices (not Cube) (format: addr value, both in hex):

<nowiki>00 08
02 46
04 C6
05 26
0B 06
10 C8 //MDMCFG4 DRATE_E=8
11 93 //MDMCFG3 DRATE_M=147, data rate = (256+DRATE_M)*2^DRATE_E/2^28*f_xosc = (9992.599) 1kbit/s (at f_xosc=26 Mhz)
12 03
15 34
17 00
18 18
19 16
1B 43
21 56
25 00
26 11
0D 21
0E 65
0F 6A
07 4C //PKTCTRL1: ADR_CHK=0 APPEND_STATUS=1 CRC_AUTOFLUSH=1 PQT=2 (preamble must have 8 toggling bits before sync word detection)
16 1C //RXTIME=4
RX_TIME_QUAL=1 (when rx timeout expires, keep receiving if either sync word is found or PQI is set (see PQT))
RX_TIME_RSSI=1 (terminate RX if there is no carrier sense within the first 8 symbol periods)
20 78 //WORCTRL, WOR_RES=00 (1.8-1.9 sec), RC_CAL=1, EVENT1=7 (48 ticks), RC_PD=0
1E 87 //WOREVT1
1F 6B //WOREVT0, i.e. EVENT0 = 34667
29 59
2C 81
2D 35
3E C3</nowiki>
<nowiki>Not set, i.e. factory defaults:
13 MDMCFG1 NUM_PREAMBLE=2 (4 preamble bytes)</nowiki>
From the configuration, we see that the

<nowiki>RC Oscillator: f_xosc/750 = 34666.66 Hz
Event1 = Event1(=48 ticks)/RC Oscillator = 1.385 ms
t_Event0 = 750/26Mhz * EVENT0 * 2^(5*WOR_RES) = 1.00 second
C(RX_TIME, WOR_RES)= 0.2254
rx timeout = EVENT0·C(RX_TIME, WOR_RES) ·26/X(=26) = 34667*0.2254 us = 7.8139 ms</nowiki>

The ShutterContact seems to always sleep. Thus it is necessary to trigger it manually (by opening/closing the window) to make it receive messages. Pushing the button may work to. It is also awake just after
pairing, so one may send messages right then. One can use the WakeUp message to keep it from sleeping for some time. (This is also the reason why in the official MAX software, one must trigger the ShutterContact
after removing it from the house. The "factoryReset" packet is sent directly after the "ShutterContactState" packet has been acked.)

== Probleme und Lösungen ==
=== Der Wandthermostat oder Heizthermostat reagieren nicht auf Änderungen über FHEM ===
Das Autocreate von FHEM erkennt, wenn aktiviert, die Geräte initial und legt auch Einträge an. Es fehlt aber noch das Pairing, da sonst keine Steuerung möglich ist!
Wenn im Log also Meldungen wie

<nowiki>2013.03.20 15:12:30 5: CUL_MAX_SendQueueHandler: 1 items in queue
2013.03.20 15:12:30 5: CUL_MAX_SendQueueHandler: 1 items in queue
2013.03.20 15:12:30 2: CUL_MAX_SendQueueHandler: Missing ack from 01c9bb for 0b05008212345601c9bb0000</nowiki>
auftauchen (im Verbose Modus 5), dann wurde vermutlich kein oder ein inkorrektes Paring durchgeführt.
Nach dem Pairing sollten diese Meldungen verschwinden und stattdessen etwas wie
:<code>2013.03.20 15:21:43 5: Got matching ack</code>
auftauchen.

[[Kategorie:Kontaktsensor (magnetisch)]]
[[Kategorie:MAX]]
[[Kategorie:Heizungsventile]]