http://wiki.fhem.de/w/api.php?action=feedcontributions&user=MGu&feedformat=atomFHEMWiki - Benutzerbeiträge [de]2024-03-28T13:52:49ZBenutzerbeiträgeMediaWiki 1.39.3http://wiki.fhem.de/w/index.php?title=HM-Sen-MDIR-O_Funk-IR-Bewegungsmelder_au%C3%9Fen&diff=33479HM-Sen-MDIR-O Funk-IR-Bewegungsmelder außen2020-07-14T12:56:12Z<p>MGu: /* Anzeige aller dekodierten Register */</p>
<hr />
<div>{{Infobox Hardware|Bild=HM-Sen-MDIR-O.jpg<br />
|Bildbeschreibung=HM-Sen-MDIR-O<br />
|HWProtocol=HomeMatic<br />
|HWType=[[HomeMatic Type motionDetector|motionDetector]]<br />
|HWCategory=HomeMatic<br />
|HWComm=868,3 MHz<br />
|HWChannels=1<br />
|HWPowerConsumption=unbekannt<br />
|HWVoltage=4,5 V<br />
|HWPoweredBy=Batterie, 3x LR06 (Mignon)<br />
|HWSize=76 x 74 x 90 mm<br />
|HWDeviceFHEM=[[CUL_HM]]<br />
|HWManufacturer=eQ-3 <br />
}}<br />
<br />
'''HM-Sen-MDIR-O'''<br />
HomeMatic Funk-IR-Bewegungsmelder außen<br />
<br />
== Features ==<br />
PIR-Bewegungsmelder mit Helligkeitssensor zur Tag-/Nachtumschaltung.<br />
<br />
Neu: ca. 45 € (Oktober 2018)<br />
<br />
'''Technische Daten:'''<br />
* Erfassungswinkel: ca. 90°<br />
* Erfassungsbereich: ca. 9 m<br />
* Drehbar: 360°<br />
* Neigbar: 45°<br />
* Schutzart: IP 44<br />
<br />
== Hinweise zur Inbetriebnahme und Installation ==<br />
&lt;Bitte ergänzen&gt;<br />
<br />
== Betrieb mit FHEM ==<br />
Das Pairing sollte wie in [[HomeMatic Devices pairen]] beschrieben durchgeführt werden. Die Anlerntaste am Bewegungsmelder sollte hierzu nur kurz betätigt werden. Bei einer Betätigung von vier Sekunden wird der Melder nur bei Unterschreiten einer festgelegten Helligkeitsschwelle auslösen (weitere Informationen siehe Abschnitt ''Anlernen'' der Herstellerdokumentation).<br />
<br />
'''Hinweis''': sobald einmal ein motion-Status erkannt wurde, verbleibt das Gerät in diesem Modus. Alle Konfigurationsbeispiele setzen also einen zusätzlichen watchdog voraus:<br />
<br />
define WD_Reset_EG.Scheune.MotionDetect watchdog EG.Scheune.MotionDetect:motion 00:04:05 SAME setreading EG.Scheune.MotionDetect state nomotion<br />
<br />
Dieser Umweg mit einem Watchdog läßt sich auch mit einer DOIF-Lösung verheiraten, siehe Beispiel '''Außenbeleuchtung zeitgesteuert und bei Bewegung schalten'''. Als Alternative kann auch auf die Uhrzeit der letzten Erkennung geprüft werden:<br />
<br />
define di_lamp DOIF ([BM:state:sec] < 5)(set lamp on-for-timer 300)<br />
attr di_lamp do always<br />
<br />
=== Event-Monitor ===<br />
In regelmäßigen Abständen werden die folgenden Daten vom Bewegungsmelder (hier: HM-Sen-MDIR-O-2) übermittelt:<br />
<pre><br />
2014-11-19 16:31:24 CUL_HM HM_Sen_MDIR_O_2_2B033A_BewegMelderHaustuer brightness: 120<br />
2014-11-19 16:31:24 CUL_HM HM_Sen_MDIR_O_2_2B033A_BewegMelderHaustuer cover: closed<br />
2014-11-19 16:31:24 CUL_HM HM_Sen_MDIR_O_2_2B033A_BewegMelderHaustuer battery: ok<br />
</pre><br />
<br />
Wird Bewegung erkannt, wird Folgendes vom Gerät (hier: HM-Sen-MDIR-O-2) übermittelt:<br />
<pre><br />
2014-11-19 16:27:55 CUL_HM HM_Sen_MDIR_O_2_2B033A_BewegMelderHaustuer trigDst_2573FB: noConfig<br />
2014-11-19 16:27:55 CUL_HM HM_Sen_MDIR_O_2_2B033A_BewegMelderHaustuer motion<br />
2014-11-19 16:27:55 CUL_HM HM_Sen_MDIR_O_2_2B033A_BewegMelderHaustuer motion: on (to MyHMLAN)<br />
2014-11-19 16:27:55 CUL_HM HM_Sen_MDIR_O_2_2B033A_BewegMelderHaustuer motionCount: 235_next:116s<br />
2014-11-19 16:27:55 CUL_HM HM_Sen_MDIR_O_2_2B033A_BewegMelderHaustuer brightness: 120<br />
</pre><br />
<br />
=== Log-Auszug ===<br />
&lt;Bitte ergänzen&gt;<br />
<br />
=== Konfiguration ===<br />
Bei eingeschaltetem Autocreate werden die erforderlichen Definitionen beim Pairen selbstständig erstellt (Beispiel: HM-Sen-MDIR-O-2).<br />
<br />
<pre><br />
define HM_Sen_MDIR_O_2_2B033A_BewegMelderHaustuer CUL_HM 2B033A<br />
attr HM_Sen_MDIR_O_2_2B033A_BewegMelderHaustuer IODev MyHMLAN<br />
attr HM_Sen_MDIR_O_2_2B033A_BewegMelderHaustuer actCycle 000:10<br />
attr HM_Sen_MDIR_O_2_2B033A_BewegMelderHaustuer actStatus alive<br />
attr HM_Sen_MDIR_O_2_2B033A_BewegMelderHaustuer autoReadReg 4_reqStatus<br />
attr HM_Sen_MDIR_O_2_2B033A_BewegMelderHaustuer expert 2_full<br />
attr HM_Sen_MDIR_O_2_2B033A_BewegMelderHaustuer firmware 1.6<br />
attr HM_Sen_MDIR_O_2_2B033A_BewegMelderHaustuer model HM-Sen-MDIR-O-2<br />
attr HM_Sen_MDIR_O_2_2B033A_BewegMelderHaustuer peerIDs 00000000,<br />
attr HM_Sen_MDIR_O_2_2B033A_BewegMelderHaustuer room CUL_HM<br />
attr HM_Sen_MDIR_O_2_2B033A_BewegMelderHaustuer serialNr LEQ0xxxxxx<br />
attr HM_Sen_MDIR_O_2_2B033A_BewegMelderHaustuer subType motionDetector<br />
</pre><br />
<br />
=== Konfiguration über Register ===<br />
==== Anzeige aller dekodierten Register ====<br />
<nowiki>get &lt;name&gt; regList</nowiki><br />
zeigt alle moeglichen 'dekodierten' Register an. Fuer mdir sind dies alle, sollte also komplett sein. Hier findet man sowohl den Wertebereich alsauch eine (sehr) kleine Beschreibung.<br />
Ausgabe:<br />
<br />
<nowiki><br />
list: register | range | peer | description<br />
0: pairCentral | 0 to 16777215 | | pairing to central<br />
1: brightFilter | 0 to 7 | | brightness filter - ignore light at night<br />
1: captInInterval | literal | | capture within interval options:on,off<br />
1: evtFltrNum | 1 to 15 | | sensitivity - read each n-th puls<br />
1: evtFltrPeriod | 0.5 to 7.5s | | event filter period<br />
1: ledOnTime | 0 to 1.275s | | LED ontime<br />
1: minInterval | literal | | minimum interval in sec options:240,60,120,30,15<br />
4: peerNeedsBurst | literal | required | peer expects burst options:on,off<br />
</nowiki><br />
<br />
;minInterval<br />
: Minimales Intervall in Sekunden vor dem Senden einer neuen Funknachricht. Der Standard ist 240. D.h. nach einer Bewegungs-Meldung werden erst nach min. 4 Minuten weitere Meldungen gesendet. Ob dafür neue Bewegungen nötig sind oder Bewegungen innerhalb des Intervalls ausreichen, regelt das Register captInInterval.<br />
;captInInterval<br />
: Sendet am Ende der "Sendepause" (minInterval) eine Funkmeldung, wenn Bewegungen innerhalb der Pause gemäss Filtereinstellungen eine Meldung ausgelöst hätten.<br />
;brightFilter<br />
: Gibt als <code>brightness</code> das Minimum der letzten <code>brightFilter+1</code> Messungen aus. Damit werden kurze Erhöhungen der Beleuchtung ignoriert. Bei einer Messung alle 6 Minuten führt z.B. der Wert 5 dazu, dass <code>brightness</code> dem kleinsten Wert der letztzen 30 bis 36 Minuten entspricht. Bei 0 wird entsprechend der ungefilterte letzte Messwert verwendet. Damit kann bei motion-Meldungen an einen Aktor verhindern werden, dass kurzzeitige Beleuchtung zu fehlerhaften Helligkeitswerten führt (siehe [https://forum.fhem.de/index.php/topic,10226.msg57438.html#msg57438]).<br />
;evtFltrNum<br />
: Filtert Bewegungen aus. Steht dieser Wert z.B. auf 5 so wird erst bei der fünften Bewegung die Meldung gesendet.<br />
;evtFltrPeriod<br />
: Gibt an wie viel Zeit zwischen zwei Bewegungen vergehen muss um für den evtFltrNum Filter gezählt zu werden. Steht dieser Wert auf 1 und evtFltrNum auf 5 so muss der Sensor 5 Sekunden Bewegungen registrieren um eine Meldung zu senden.<br />
;ledOnTime<br />
: Legt die Aufleuchtdauer der internen LED zur optischen Rückmeldung fest. Die LED leuchtet jedoch nur bei einer Funkübertragung auf. D.h. ist auch von minInterval abhängig.<br />
<br />
=== Einsatzbeispiele (per Notify) ===<br />
==== Gerät bei Bewegung schalten ====<br />
Mit dem folgenden [[Notify]] kann z. B ein [[HM-LC-SW1-FM Schaltaktor 1-fach UP|Unterputz-Schaltaktor]] für die angegebene Zeit (in Sekunden) eingeschaltet werden - ein [[Peering (HomeMatic)|Peeren]] ist dazu vorher nicht erforderlich. Das Einschalten passiert in diesem Beispiel unabhängig von der Helligkeit.<br />
<br />
<pre><br />
define Notify_Bewegungsmelder_Haustuer notify HM_Sen_MDIR_O_2_2B033A_BewegMelderHaustuer:motion set HM_LC_SW1_FM_298FB2_HaustuerLicht on-for-timer 300<br />
</pre><br />
<br />
==== Außenbeleuchtung zeitgesteuert und bei Bewegung schalten ====<br />
Das fortgeschrittene Beispiel steuert die Beleuchtung in Abhängigkeit von Uhrzeiten und zwei Bewegungsmeldern.<br />
<br />
Dazu wird das Twilight-Modul verwendet:<br />
<br />
define MyTwilight Twilight 54.2539407 9.0650127 1 12833034<br />
<br />
wobei die Koordinaten und die Stadt-ID (letzte Zahl) angepaßt werden müßen.<br />
<br />
''Zeitgesteuerte Außenbeleuchtung''<br><br />
Ein Dummy namens '''D_TimerAussenlicht''' speichert, ob das Außenlicht über die Uhrzeitregelung aktiviert wurde:<br />
<br />
define D_TimerAussenlicht dummy<br />
attr D_TimerAussenlicht room Aussen<br />
<br />
define AussenlichtONOFF DOIF (( [05:30-07:40|8] or [06:30-08:00|7] or [15:30-22:30] or ([15:30-01:00] and [PresTVWintergarten:state] eq "present")) and [MyTwilight:twilight_weather] < 40) \<br />
(set D_TimerAussenlicht on, set Aussenlicht on) \<br />
DOELSE \<br />
(set D_TimerAussenlicht off, set Aussenlicht off)<br />
<br />
Dies aktiviert die Außenbeleuchtung zwischen 05:30-07:40 an Werktagen oder zwischen 06:30-08:00 an Wochenenden oder Ferientagen oder zwischen 15:30-22:30 oder zwischen 15:30-01:00 sofern der Fernseher ('''PresTVWintergarten''') mit Hilfe des PRESENCE-Moduls erkannt wurde - aber nur, wenn es dunkel ist. Für die Erkennung der Dunkelheit wurde des Twilight-Modul verwendet und der Schwellwert auf 40 definiert. Wie in der Dokumentation ersichtlich, sind die angegebenen Uhrzeiten die möglichen START- und END-Zeiten - sollte die Dunkelheit (AND-Verknüpfung des Twilight-Modules) nicht ausreichen, wird das Licht später ein- oder früher ausgeschaltet.<br />
<br />
''Bewegungsmelder''<br />
<br />
Diese Lösung basiert auf der vorgeschlagenen Bewegungsmelder-Lösung mit DOIF, integriert jedoch das löschen des '''motion'''-Zustandes in den Bewegungsmeldern:<br />
<br />
define D_MotionDetectHinten dummy<br />
<br />
define DI_MotionHintenScheune DOIF ([EG.Scheune.MotionDetect] eq "motion" ) (set D_MotionDetectHinten on, set D_MotionDetectHinten off, setreading EG.Scheune.MotionDetect state nomotion)<br />
attr DI_MotionHintenScheune do always<br />
<br />
define DI_MotionHintenDurchgang DOIF ([EG.Durchgang.MotionDetect] eq "motion" ) (set D_MotionDetectHinten on, set D_MotionDetectHinten off, setreading EG.Durchgang.MotionDetect state nomotion)<br />
attr DI_MotionHintenDurchgang do always<br />
<br />
define DI_MotionLichtHinten DOIF ([D_MotionDetectHinten] eq "on" and [D_TimerAussenlicht] eq "off" and [MyTwilight:twilight_weather] < 40) \<br />
(set LichtStruc.Aussen.Hinten on) \<br />
DOELSE \<br />
(set LichtStruc.Aussen.Hinten off)<br />
attr DI_MotionLichtHinten wait 0:240<br />
<br />
Der Dummy '''D_MotionDetectHinten''' wird von beiden Bewegungsmeldern (EG.Durchgang.MotionDetect und EG.Scheune.MotionDetect) getriggert. Sobald diese eine Bewegung erkennen, werden diese auf das Muster '''on''' gefolgt von '''off''' gesetzt. Direkt danach wird der motion-Status des auslösenden Bewegungsmelders gelöscht.<br />
<br />
Das dritte DOIF reagiert auf einen Wechsel des Dummys (D_MotionDetectHinten) und prüft, ob das Außenlicht bereits zeitgesteuert (D_TimerAussenlicht, siehe Abschnitt oben) aktiviert wurde. Ist dies nicht der Fall und dunkel (Twilight-Modul und Abfrage) genug, wird die structure (LichtStruc.Aussen.Hinten) ohne Verzögerung für 240 Sekunden aktiviert.<br />
<br />
Die Bewegungsmelder können dann ebenfalls auf eine 240-Sekunden-Verzögerung konfiguriert werden - die Lichter brennen ja bereits für diese Zeitdauer.<br />
<br />
==== Gerät bei Bewegung in Abhängigkeit der Helligkeit schalten ====<br />
Mit der nachfolgenden Notify-Definition werden zwei Log-Einträge erzeugt, eine Meldung auf der [[Enigma2 Receiver (Dreambox, VUplus etc.) steuern|Dreambox]] angezeigt, falls diese angeschaltet ist, und ein [[HM-LC-SW1-FM Schaltaktor 1-fach UP|Unterputz-Schaltaktor]] für die angegebene Zeit (in Sekunden) eingeschaltet, falls die gemessene Helligkeit am Bewegungsmelder kleiner oder gleich 90 ist.<br />
<br />
Der Code ist hier so angegeben, wie er in der Weboberfläche nach einem Klick auf das [[Konfiguration|DEF-Feld]] übernommen werden kann.<br />
<br />
<pre><br />
HM_BewegMelder_Carport:motion { <br />
Log 1, "Trigger-Notify von BewegMelderCarport: @";<br />
Log 1, ReadingsVal( "HM_BewegMelder_Carport", "brightness", "");<br />
fhem( "set E2_Dreambox showText Bewegung am Carport" ) if ReadingsVal("E2_Dreambox","state","") eq "on"; <br />
if ( ReadingsVal( "HM_BewegMelder_Carport", "brightness", "") <= 90 ) {<br />
fhem( "set HM_Sw1_GarageLED on-for-timer 300" );<br />
}<br />
}<br />
</pre><br />
<br />
=== Einsatzbeispiele (per DOIF) ===<br />
==== Aktor in Abhängigkeit der Helligkeit und innerhalb eines Zeitraums schalten ====<br />
Voraussetzung: [[Twilight]]-Modul<br />
Die Twilight-Abfragen könnten natürlich auch entfernt werden.<br />
<br />
<pre><br />
define di_lampe DOIF (<br />
(<br />
[sensor:brightness] < 120 and<br />
[?[twilight:ss_indoor]-23:59]<br />
)<br />
(set lampe on)<br />
DOELSEIF <br />
(<br />
[sensor:brightness] > 80 and<br />
[?04:00-[twilight:sr_indoor]]<br />
)<br />
(set lampe off)<br />
</pre><br />
<br />
==== Aktor bei Bewegung einschalten (inkl. weiterer Gimmicks) ====<br />
Benötigte Module: [[Twilight]] und [[Anwesenheitserkennung|Residents]]<br />
<br />
Die Zeilen zum Residents und Twilight-Modul könnten natürlich auch entfernt werden.<br />
<br />
<pre><br />
define di_lampe2 DOIF (<br />
(<br />
(<br />
## Bewegungsmelder löst aus<br />
[sensor:?motion] and<br />
## nur wenn Lampe nicht zuvor manuell eingeschaltet wurde<br />
[lampe:state] ne "on" and<br />
## und wenn es nicht sowieso hell genug ist.<br />
[?sensor:brightness] < 50<br />
) <br />
and<br />
(<br />
## entweder immer nachts<br />
[?00:00-[twilight:sr_civil]] or<br />
## oder wenn niemand daheim<br />
[?rgr_Residents] ne "home"<br />
)<br />
) <br />
(set lampe2 on-for-timer 180)<br />
</pre><br />
<br />
=== Einsatzbeispiele (BM und Aktor direkt peeren) ===<br />
Man kann den Bewegungsmelder direkt mit einem Schaltaktor von Homematic peeren. Für die Übertragung der Befehle zum Bewegungsmelder muss dieser jeweils ausgelöst werden, drücken des Konfigtasters ist nicht notwendig!<br />
<br />
* LichtKeAussen ist ein Kanal eines 4-fach Aktors.<br />
* PIRWg ist der Bewegungsmelder.<br />
<pre><br />
set PIRWg peerChan 0 LichtKeAussen single set<br />
</pre><br />
Auslösen und dann die Funktion überprüfen mit <br />
<pre><br />
get hm configCheck<br />
</pre><br />
Nach dem Peeren wird der BM den Aktor bei jeder Bewegung toggeln.<br />
<br />
Soll das Schaltverhalten des Aktors verändert werden sind die entsprechenden Short (sh) Register zu setzen.<br />
Für eine Zeitabhängige Schaltung müssen zwei Register im Schaltaktor gesetzt werden:<br />
<pre><br />
set LichtKeAussen regSet shOnTime 300 PIRWg<br />
set LichtKeAussen regSet shSwJtOn on PIRWg<br />
</pre><br />
Jetzt wird der BM (minInterval=240) den Aktor für 5 min anschalten und auch innerhalb der Spanne 240-300 Sekunden nachtriggern. Will man diese Zeit verkürzen müssen OnTime im Aktor und minInterval im BM passend gesetzt werden: <br />
* minInterval nur feste Intervalle in sec 120,60,240,30,15 <br />
* minInterval < OnTime-10<br />
<br />
Die Schaltschwelle für die Helligkeit ist per default => 50 (CtOff=geLo und CtValLo=50)<br />
<br />
Diese Betriebsart normalerweise keinen Sinn. Mit zwei Registern kann die Schaltschwelle auf Unterschreiten (ltLo) der Helligkeit < 10 gesetzt werden:<br />
<pre><br />
set LichtKeAussen regSet shCtOff ltLo PIRWg<br />
set LichtKeAussen regSet shCtValLo 10 PIRWg<br />
</pre><br />
Achtung! per default ist Hi=100 und Lo=50 , der Wert für Lo muss kleiner als Hi sein!<br />
<br />
Für größer Helligkeitswerte kann man alternativ shCtOff auch auf ltHi setzen. Die Bedeutung (aus get regList):<br />
shCtOff - Jmp on condition from off options:geHi,outside,geLo,ltHi,ltLo,between <br />
<br />
Peeren per peerSmart und setzen der Register per Template ist derzeit (August 2019) nicht funktional.<br />
<br />
=== Sonstiges ===<br />
==== Anzeige der Uhrzeit der letzten Bewegung ====<br />
Möchte man den Zeitpunkt der letzten erfassten Bewegung in der GUI sehen, so muss hierzu folgendes Attribut gesetzt werden.<br />
<br />
<pre><br />
attr Sensor showtime 1<br />
</pre><br />
<br />
== Bekannte Probleme ==<br />
Geräte verfügen über keinen Sabotage-Kontakt.<br />
<br />
== Links ==<br />
* [https://www.eq-3.de/Downloads/eq3/downloads_produktkatalog/homematic/bda/HM-Sen-MDIR-O-2_UM_GE_eQ-3_web.pdf Bedienungsanleitung]<br />
<br />
[[Kategorie:HomeMatic Components]]<br />
[[Kategorie:Lichtsensoren]]<br />
[[Kategorie:Bewegungs- und Anwesenheitsmelder]]<br />
[[Kategorie:868MHz]]</div>MGuhttp://wiki.fhem.de/w/index.php?title=HM-SEC-SD_Rauchmelder&diff=31314HM-SEC-SD Rauchmelder2019-10-04T16:50:01Z<p>MGu: /* Teams */ case sensitive</p>
<hr />
<div>{{Infobox Hardware<br />
|Bild=HM-SEC-SD o.jpeg <!-- HM-SEC-SD o.jpeg --><br />
|Bildbeschreibung=HomeMatic HM-SEC-SD Rauchmelder Oberseite<br />
|HWProtocol=HomeMatic<br />
|HWType=[[HomeMatic Type smokeDetector|smokeDetector]]<br />
|HWCategory=HomeMatic<br />
|HWComm=868MHz<br />
|HWChannels=<br />
|HWVoltage=9V<br />
|HWPowerConsumption= W im Standby<br />
|HWPoweredBy=3 x 1,5 V LR6/AA<br />
|HWSize=120x44mm<br />
|HWDeviceFHEM=[http://fhem.de/commandref.html#CUL_HM CUL_HM]<br />
|HWManufacturer=ELV / eQ-3<br />
}}<br />
<br />
== Features ==<br />
Der [[HM-SEC-SD Rauchmelder|HM-SEC-SD]] ist ein VdS-zertifizierter Rauchmelder. Mehrere Rauchmelder können unabhängig von einer Zentrale zu einer Gruppe zusammengefasst werden. Auch ohne FHEM-Zentrale meldet ein Rauchmelder seinen Alarm immer an die anderen vernetzten Rauchmelder weiter. <br />
<br />
Der [[HM-SEC-SD Rauchmelder|HM-SEC-SD-2]] (ca. 50€) ist die neue Version seit 2016. Auch dieser Melder wird in FHEM unterstützt. ''Das Gerät kann ausschließlich in Gruppen mit Rauchwarnmeldern des gleichen Typs (HM-Sec-SD-2) und nicht in einer Gruppe mit anderen Rauchwarnmeldern (z. B. HM-Sec-SD) genutzt werden.''<ref>[http://www.eq-3.de/produkte/homematic/sicherheit-und-ueberwachung/homematic-funk-rauchwarnmelder-293.html#beschreibung "Highlights" bei der Produktbeschreibung auf der EQ3-Site]</ref><br />
<br />
<br />
[[Datei: HM-SEC-SD-2.jpg|300px|thumb|right|HM-SEC-SD-2]]<br />
<br />
== Hinweise zum Betrieb mit FHEM ==<br />
Der HM-SEC-SD Rauchmelder beherrscht kein AES. Der Betrieb ist mit [[HMLAN Konfigurator]] oder mit [[CUL]] möglich. Das Pairing sollte wie in [[HomeMatic Devices pairen]] beschrieben durchgeführt werden.<br />
<br />
Der HM-SEC-SD-2 Rauchmelder arbeitet mit aesCBC, er benötigt dafür zwingend das Modul libcrypt-rijndael-perl unabhängig vom IO Device, auch für den HM-CFG-LAN!<br />
<br />
=== Teams ===<br />
Rauchmelder können mittels [[Peering (HomeMatic)|Peering]] in Teams gruppiert werden. Jeder SD kann einem Team angehören - und das sollte man auch einrichten. Nutzt man nur einen SD sollte man diesen mit sich selbst peeren.<br />
<br />
Beispiele:<br />
nutzt man einen SD und will diesen nicht mit anderen in einem Team haben peert man ihn mit sich selbst. Damit ist der SD sein eigener TeamLead. <br />
:<code>set Rauchmelder_Flur peerChan 0 Rauchmelder_Flur single set actor</code><br />
<br />
Hat man mehrere SDs, die in einem Team zusammengefasst werden sollen, wird der TeamLead festgelegt und alle SDs werden mit ihm gepeert. Das Team kann jederzeit erweitert werden. <br />
<pre>set Rauchmelder_Flur peerChan 0 Rauchmelder_Flur single set actor <br />
set Rauchmelder_Flur peerChan 0 Rauchmelder_WZ single set actor <br />
set Rauchmelder_Flur peerChan 0 Rauchmelder_SZ single set actor <br />
set Rauchmelder_Flur peerChan 0 Rauchmelder_KZ single set actor </pre><br />
<br />
Nutzt man einen virtuellen TeamLead - (siehe [[#Virtueller_TeamLead|virtueller TeamLead]]) - werden alle realen SDs mit diesem gepeert<br />
<pre>set Rauchmelder_Team peerChan 0 Rauchmelder_Flur single set actor<br />
set Rauchmelder_Team peerChan 0 Rauchmelder_WZ single set actor<br />
set Rauchmelder_Team peerChan 0 Rauchmelder_SZ single set actor<br />
set Rauchmelder_Team peerChan 0 Rauchmelder_KZ single set actor<br />
</pre><br />
<br />
Ein SD kann aus einem Team mittels unset entfernt werden.<br />
:<code>set Rauchmelder_Flur peerChan 0 Rauchmelder_Flur single unset actor </code><br />
<br />
Um einen SD von einem Team in ein anderes zu transferieren, muss man ihn erst mit ''unset'' aus dem Team entfernen, dann mit ''set'' in das neue Team eintragen. Einen physkalischen TeamLead kann man nur aus dem Team nehmen, indem man ihn aus allen Teammitgliedern entfernt. <br />
<br />
Die korrekte Gruppierung sollte nach der Konfiguration durch einen Teamcall geprüft werden.<br />
<br />
Der Betrieb mehrer Teams ist möglich, ein SD kann aber nur einem Team angehören. Will man einen SD von einem Team in ein anderes umhängen, muss man ihn erst aus dem ersten Team entfernen und dann in das Neue aufnehmen.<br />
<br />
=== TeamLead ===<br />
Für ein Team muss immer ein TeamLead festgelegt werden. Anders als der Name suggeriert, gibt es hier keinen Master. Sinn und Zweck ist einzig, eine Team-Adresse (HMId) festzulegen, unter der man alle SDs eines Teams ansprechen kann. Diese muss, wie alle HMIds, einzig im System sein. Um dies zu erreichen, verwendet HM beim Teamen ohne Zentrale die HMId eines der SDs. Verwendet man eine Zentrale (FHEM) kann man dies auch entzerren und einen virtuellen SD als TeamLead nutzen. Siehe hierzu [[#virtueller TeamLead|virtueller TeamLead]].<br />
<br />
Nutzt man nur einen einzelnen SD, sollte man diesen mit sich selbst peeren.<br />
<br />
=== Kommandos ===<br />
Es gibt Team-Nachrichten, die jeder SD senden kann und auf die jeder SD im Team reagiert. Jeder SD kann somit einen Teamcall auslösen oder einen Alarm ausgeben. Die Kommandos werden '''nicht''' von einem SD zum anderen weitergereicht. Auch der TeamLead hat '''keine''' Sonderfunktion. Der einzelne SD sendet seine Nachricht an das Team und jeder im Team reagiert darauf.<br />
<br />
Es ist somit darauf zu achten, dass auch die entferntesten SDs sich gegenseitig erreichen können.<br />
<br />
Die Kommandos können von der Zentrale getriggert werden. Da sie unter der Team-ID gesendet werden, stehen sie nur bei der Komponente des TeamLeads zu Verfügung.<br />
<br />
Dazu gehören teamCall, teamCallBat, alarmOn und alarmOff.<br />
<br />
Sie stehen nur für die Entity des TeamLeads zu Verfügung.<br />
<pre>set EurerTeamLeader alarmOn<br />
set EurerTeamLeader alarmOff<br />
set EurerTeamLeader teamCall<br />
set EurerTeamLeader teamCallBat ## nur für alte SDs <br />
</pre><br />
<br />
'''teamCall''' testet die Zugehörigkeit und Erreichbarkeit aller SDs im Team. Alle SDs sollten 10 mal leise piepen. '''teamCallBat''' erzeugt einen kürzeren Teamcall mit anderer Signalfolge, wie er bei schwacher Batterie eines Melders automatisch ausgelöst wird.<br />
<br />
Einzelne SDs kann man mit "statusRequest" abfragen.<br />
<br />
== Virtueller TeamLead ==<br />
Nutzt man nur einen einzelnen SD, kann/sollte man diesen mit sich selbst teamen (peerChan). In allen andere Fällen braucht man einen TeamLead um eine Team-ID zu erhalten. Man kann hierzu einen der SDs nutzen. Wird dieser einmal ausgewechselt, hat man allerdings seine Team-ID verloren.<br />
<br />
Wenn man mit Zentrale (FHEM) arbeitet, gibt es eigentlich keinen vernünftigen Grund (ausser 1-SD-Teams), einen der SDs als Lead zu nutzen. Man kann genauso gut einen virtuellen Aktor bauen und diesen zum Lead machen. Das ergibt eine bessere Struktur, da dieser virtuelle Aktor nicht verloren gehen kann.<br />
<br />
Erzeugen eines virtuellen TeamLeads könnte so aussehen. Es wird ein virtuelles Gerät und ein virtueller Kanal definiert und mit einem sprechenden Namen versehen:<br />
<pre>define TeamDev CUL_HM 111111 <br />
set TeamDev virtual 1<br />
rename TeamDev_Btn1 Rauchmelder_Team</pre><br />
<br />
'''Bitte beachten''': die HMID (im obigen Beispiel 111111) '''muss''' für die gesamte Installation einmalig sein und es darf '''nur''' Btn1 (HM Channel ID xxxxxx01) als TeamLead verwendet werden.<br />
<br />
Nach der Definition bitte '''unbedingt''' überprüfen, dass TeamDev das Attribut ('''attr''') '''IODev''' bzw. '''IOgrp''' gesetzt hat (das sollte normalerweise automatisch passieren)! Am Besten die Konfiguration mit HMinfo '''configCheck''' prüfen, die ordnungsgemäße Funktion des TeamDev ist wichtig für den Erfolg des folgenden Peerings der Rauchmelder.<br />
<br />
Man '''kann''' anstatt des separaten virtuellen Gerätes auch den '''ersten''' Kanal einer VCCU verwenden, falls der noch nicht anderweitig genutzt wird. <br />
<br />
Jeder Rauchmelder muss jetzt in das Team aufgenommen werden:<br />
<pre>set Rauchmelder_Team peerChan 0 Rauchmelder_Flur single set actor<br />
set Rauchmelder_Team peerChan 0 Rauchmelder_WZ single set actor<br />
...<br />
save</pre><br />
<br />
Hierbei ist "Rauchmelder_Team" der Name des virtuellen TeamLeaders und "Rauchmelder_Flur" der Name des jeweiligen Rauchmelders.<br />
<br />
Das "save" ist notwendig, um auch die Einstellungen des virtuellen SDs in der [[Konfiguration]] zu sichern.<br />
<br />
Bei jedem Rauchmelder sollte der Name des virtuellen TeamLeaders in der peerList stehen und beim virtuellen TeamLeader jeder Rauchmelder.<br />
<br />
Mit teamCall sollte man die korrekte Funktion des Teams prüfen, wer will auch mit alarmOn.<br />
<br />
== Variablen ==<br />
=== Internals ===<br />
Keine Spezifischen.<br />
<br />
=== Readings ===<br />
==== Einzelne SDs ====<br />
Für '''jeden''' SD sind folgende Readings relevant:<br />
<br />
teamCall from <name>:<count><br />
state:[off|smoke-Alarm_<count>]<br />
smoke_detect:<von_name><br />
battery:[ok|low]<br />
level:<0..200><br />
sdRepeat:[on|off]<br />
<br />
*'''count''' ist ein Zähler, den das Gerät liefert um neue Alarme unterscheiden zu können<br />
*'''level''' ist ein Wert zwischen 0 und 200. 200 ist Alarm, 199 bedeutet Alarm, aber die Sirene ist abgeschaltet.<br />
*'''sdRepeat''' ist ein Flag ob der SD als Reapeater für Nachrichten anderer SDs arbeitet. Das kann nötig sein, wenn nicht jeder SD jeden anderen empfängt. Das Flag kann über die Taste am SD eingestellt werden (siehe Gebrauchsanleitung). Es dürfen maximal 3 SDs in einer Gruppe als Reapeater konfiguriert sein. Ansonsten kann es zu verzögerten Alarmmeldungen kommen.<br />
<br />
==== TeamLead ====<br />
Beim '''TeamLead''' laufen alle Alarme auf:<br />
<br />
teamCall: from <name>:<count><br />
recentAlarm:<von_name><br />
level:<0..200><br />
eventNo:<count><br />
state:[off|smoke-Alarm_<count>]<br />
smoke_detect:<von_name><br />
SDteam:[add_<name>|remove_<name>]<br />
<br />
*'''von_name''' ist der Name des SD, der gemeldet hat. <br />
*'''smoke_detect''' ist der aktuelle Alarm, während '''recentAlarm''' die letzte Alarmquelle anzeigt, auch wenn der Alarm schon behoben ist.<br />
*'''SDteam''' kommt gelegentlich bei Konfigurationsereignissen zum Tragen.<br />
<br />
=== Attribute ===<br />
Besondere Attribute<br />
* '''msgRepeat''' sollte auf 1 stehen. SD ist ein burst device, wiederholen von Nachrichten belastet das HMLAN besonders. Die Team-Kommandos sind hiervon nicht beeinflusst, also auch nicht das Auslösen eines Alarms. <br />
* '''actCycle''' wird auf 99 Stunden gesetzt. Ein SD meldet sich alle 3 Tage bei der Zentrale, was der ActionDetector prüft.<br />
* '''msgRepeat''' 1<br />
Allgemein vorgeschlagen<br />
:'''IODev''' [HMLAN/HMUSB/CUL]<br />
:'''autoReadReg''' 5_readMissing<br />
:'''event-on-change-reading''' .*<br />
Optional, nur als Anregung zu verstehen<br />
:'''devStateIcon''' off:general_ok .*:secur_alarm<br />
:'''group''' smokeDetect<br />
:'''icon''' secur_smoke_detector<br />
Ebenfalls optional, jedoch nützlich für Homebridge-/Homekit-Anbindung:<br />
:'''genericDeviceType''' security<br />
<br />
== Alarme ==<br />
Meldet ein SD einen Alarm, wird dieser in dem SD und im TeamLead angezeigt.<br />
<br />
Nutzt man [[HomeMatic HMInfo|HMinfo]], wird ein Rauchalarm auch hier als "Error" gemeldet. In HMinfo wird dies für alle SD-Teams im System gemacht.<br />
<br />
== Probleme beim SD-2 ==<br />
<br />
Das Senden von TeamCall-/Alarmkommandos an die SD2 ist leider fragil. Bei jedem Befehl muss entweder der MessageCounter der Nachricht größer sein als der letzte oder (falls dies nicht der Fall ist) der Generationenzähler inkrementiert werden. Beide Werte werden in dem Reading aesCBCCounter des Teamleads abgelegt:<br />
<br />
<pre><br />
aesCBCCounter GGGGMM<br />
</pre><br />
<br />
Hierbei ist GGGG der Generationenzähler in Hex und MM der Messagecounter in Hex. Sollte dieses Reading gelöscht werden, reagieren die SD2 nicht mehr, da sie denken, eine alte Nachricht empfangen zu haben. Leider kann man die aktuellen Werte auch nicht mehr aus den SD2 auslesen...<br />
<br />
Falls die SD2 also nicht mehr reagieren, kann man mal probieren den Generationenzähler per Hand zu inkrementieren und den MessageCounter auf 0 zu setzen (aesCBCCounter hier vorher 0000XX):<br />
<br />
<pre><br />
setreading TeamLead aesCBCCounter 000100<br />
</pre><br />
<br />
Falls das Reading komplett gelöscht wurde, bitte langsam rantasten und den Generationenzähler immer nur um 1 erhöhen, denn was passiert, wenn der Generationencounter nach FFFF überläuft hat bisher noch niemand ausprobiert...<br />
<br />
<br />
== Nützliche Notifies ==<br />
Codefragmente, die man einsetzen kann. Ggf. muss man etwas anpassen, zumindest können sie als Anregung nützlich sein. <br />
* Bei Alarm E-Mail schicken und Licht im Flur anschalten<br />
<pre><br />
define sd.nf.report notify Rauchmelder_Team:.*smoke-Alarm.* {\<br />
<Mail versenden>;;<br />
fhem("set LichtTreppenhaus on");;<br />
}\<br />
</pre><br />
<br />
* Bei Alarm alle SDs des Teams stumm schalten durch Stummschalten eines einzelnen<br />
:<code>define sd.nf.quiet notify Rauchmelder_Team:.*level:.199 set Rauchmelder_Team alarmOff</code><br />
<br />
== Links ==<br />
* [http://www.eq-3.de/Downloads/eq3/downloads_produktkatalog/homematic/bda/HM-Sec-SD_GE_UM_V1.5_150407.pdf Montage- und Inbetriebnahmeanleitung HM-SEC-SD (PDF)]<br />
* [http://www.eq-3.de/Downloads/eq3/downloads_produktkatalog/homematic/bda/HM-Sec-SD-2_UM_eQ-3_GE_web.pdf Montage- und Inbetriebnahmeanleitung HM-SEC-SD-2 (PDF)]<br />
* [http://www.eq-3.de/Downloads/eq3/downloads_produktkatalog/homematic/pdb/Funk-Rauchwarnmelder_131408_Produktdatenblatt_V1.7.pdf Produktdatenblatt HM-SEC-SD-2 (PDF)]<br />
<br />
== Quellen ==<br />
<references /><br />
<br />
<br />
[[Kategorie:HomeMatic Components]]<br />
[[Kategorie:Rauchmelder]]</div>MGuhttp://wiki.fhem.de/w/index.php?title=HM-SEC-SD_Rauchmelder&diff=30803HM-SEC-SD Rauchmelder2019-06-21T13:39:23Z<p>MGu: /* Readings */</p>
<hr />
<div>{{Infobox Hardware<br />
|Bild=HM-SEC-SD o.jpeg <!-- HM-SEC-SD o.jpeg --><br />
|Bildbeschreibung=HomeMatic HM-SEC-SD Rauchmelder Oberseite<br />
|HWProtocol=HomeMatic<br />
|HWType=[[HomeMatic Type smokeDetector|smokeDetector]]<br />
|HWCategory=HomeMatic<br />
|HWComm=868MHz<br />
|HWChannels=<br />
|HWVoltage=9V<br />
|HWPowerConsumption= W im Standby<br />
|HWPoweredBy=3 x 1,5 V LR6/AA<br />
|HWSize=120x44mm<br />
|HWDeviceFHEM=[http://fhem.de/commandref.html#CUL_HM CUL_HM]<br />
|HWManufacturer=ELV / eQ-3<br />
}}<br />
<br />
== Features ==<br />
Der [[HM-SEC-SD Rauchmelder|HM-SEC-SD]] ist ein VdS-zertifizierter Rauchmelder. Mehrere Rauchmelder können unabhängig von einer Zentrale zu einer Gruppe zusammengefasst werden. Auch ohne FHEM-Zentrale meldet ein Rauchmelder seinen Alarm immer an die anderen vernetzten Rauchmelder weiter. <br />
<br />
Der [[HM-SEC-SD Rauchmelder|HM-SEC-SD-2]] (ca. 50€) ist die neue Version seit 2016. Auch dieser Melder wird in FHEM unterstützt. ''Das Gerät kann ausschließlich in Gruppen mit Rauchwarnmeldern des gleichen Typs (HM-Sec-SD-2) und nicht in einer Gruppe mit anderen Rauchwarnmeldern (z. B. HM-Sec-SD) genutzt werden.''<ref>[http://www.eq-3.de/produkte/homematic/sicherheit-und-ueberwachung/homematic-funk-rauchwarnmelder-293.html#beschreibung "Highlights" bei der Produktbeschreibung auf der EQ3-Site]</ref><br />
<br />
<br />
[[Datei: HM-SEC-SD-2.jpg|300px|thumb|right|HM-SEC-SD-2]]<br />
<br />
== Hinweise zum Betrieb mit FHEM ==<br />
Der HM-SEC-SD Rauchmelder beherrscht kein AES. Der Betrieb ist mit [[HMLAN Konfigurator]] oder mit [[CUL]] möglich. Das Pairing sollte wie in [[HomeMatic Devices pairen]] beschrieben durchgeführt werden.<br />
<br />
Der HM-SEC-SD-2 Rauchmelder arbeitet mit aesCBC, er benötigt dafür zwingend das Modul libcrypt-rijndael-perl unabhängig vom IO Device, auch für den HM-CFG-LAN!<br />
<br />
=== Teams ===<br />
Rauchmelder können mittels [[Peering (HomeMatic)|Peering]] in Teams gruppiert werden. Jeder SD kann einem Team angehören - und das sollte man auch einrichten. Nutzt man nur einen SD sollte man diesen mit sich selbst peeren.<br />
<br />
Beispiele:<br />
nutzt man einen SD und will diesen nicht mit anderen in einem Team haben peert man ihn mit sich selbst. Damit ist der SD sein eigener TeamLead. <br />
:<code>set Rauchmelder_Flur peerChan 0 Rauchmelder_Flur single set actor</code><br />
<br />
Hat man mehrere SDs, die in einem Team zusammengefasst werden sollen, wird der TeamLead festgelegt und alle SDs werden mit ihm gepeert. Das Team kann jederzeit erweitert werden. <br />
<pre>set Rauchmelder_Flur peerChan 0 Rauchmelder_Flur single set actor <br />
set Rauchmelder_Flur peerChan 0 Rauchmelder_WZ single set actor <br />
set Rauchmelder_Flur peerChan 0 Rauchmelder_SZ single set actor <br />
set Rauchmelder_Flur peerChan 0 Rauchmelder_KZ single set actor </pre><br />
<br />
Nutzt man einen virtuellen TeamLead - (siehe [[#virtueller TeamLead|virtueller TeamLead]]) - werden alle realen SDs mit diesem gepeert<br />
<pre>set Rauchmelder_Team peerChan 0 Rauchmelder_Flur single set actor<br />
set Rauchmelder_Team peerChan 0 Rauchmelder_WZ single set actor<br />
set Rauchmelder_Team peerChan 0 Rauchmelder_SZ single set actor<br />
set Rauchmelder_Team peerChan 0 Rauchmelder_KZ single set actor<br />
</pre><br />
<br />
Ein SD kann aus einem Team mittels unset entfernt werden.<br />
:<code>set Rauchmelder_Flur peerChan 0 Rauchmelder_Flur single unset actor </code><br />
<br />
Um einen SD von einem Team in ein anderes zu transferieren, muss man ihn erst mit ''unset'' aus dem Team entfernen, dann mit ''set'' in das neue Team eintragen. Einen physkalischen TeamLead kann man nur aus dem Team nehmen, indem man ihn aus allen Teammitgliedern entfernt. <br />
<br />
Die korrekte Gruppierung sollte nach der Konfiguration durch einen Teamcall geprüft werden.<br />
<br />
Der Betrieb mehrer Teams ist möglich, ein SD kann aber nur einem Team angehören. Will man einen SD von einem Team in ein anderes umhängen, muss man ihn erst aus dem ersten Team entfernen und dann in das Neue aufnehmen.<br />
<br />
=== TeamLead ===<br />
Für ein Team muss immer ein TeamLead festgelegt werden. Anders als der Name suggeriert, gibt es hier keinen Master. Sinn und Zweck ist einzig, eine Team-Adresse (HMId) festzulegen, unter der man alle SDs eines Teams ansprechen kann. Diese muss, wie alle HMIds, einzig im System sein. Um dies zu erreichen, verwendet HM beim Teamen ohne Zentrale die HMId eines der SDs. Verwendet man eine Zentrale (FHEM) kann man dies auch entzerren und einen virtuellen SD als TeamLead nutzen. Siehe hierzu [[#virtueller TeamLead|virtueller TeamLead]].<br />
<br />
Nutzt man nur einen einzelnen SD, sollte man diesen mit sich selbst peeren.<br />
<br />
=== Kommandos ===<br />
Es gibt Team-Nachrichten, die jeder SD senden kann und auf die jeder SD im Team reagiert. Jeder SD kann somit einen Teamcall auslösen oder einen Alarm ausgeben. Die Kommandos werden '''nicht''' von einem SD zum anderen weitergereicht. Auch der TeamLead hat '''keine''' Sonderfunktion. Der einzelne SD sendet seine Nachricht an das Team und jeder im Team reagiert darauf.<br />
<br />
Es ist somit darauf zu achten, dass auch die entferntesten SDs sich gegenseitig erreichen können.<br />
<br />
Die Kommandos können von der Zentrale getriggert werden. Da sie unter der Team-ID gesendet werden, stehen sie nur bei der Komponente des TeamLeads zu Verfügung.<br />
<br />
Dazu gehören teamCall, teamCallBat, alarmOn und alarmOff.<br />
<br />
Sie stehen nur für die Entity des TeamLeads zu Verfügung.<br />
<pre>set EurerTeamLeader alarmOn<br />
set EurerTeamLeader alarmOff<br />
set EurerTeamLeader teamCall<br />
set EurerTeamLeader teamCallBat ## nur für alte SDs <br />
</pre><br />
<br />
'''teamCall''' testet die Zugehörigkeit und Erreichbarkeit aller SDs im Team. Alle SDs sollten 10 mal leise piepen. '''teamCallBat''' erzeugt einen kürzeren Teamcall mit anderer Signalfolge, wie er bei schwacher Batterie eines Melders automatisch ausgelöst wird.<br />
<br />
Einzelne SDs kann man mit "statusRequest" abfragen.<br />
<br />
== Virtueller TeamLead ==<br />
Nutzt man nur einen einzelnen SD, kann/sollte man diesen mit sich selbst teamen (peerChan). In allen andere Fällen braucht man einen TeamLead um eine Team-ID zu erhalten. Man kann hierzu einen der SDs nutzen. Wird dieser einmal ausgewechselt, hat man allerdings seine Team-ID verloren.<br />
<br />
Wenn man mit Zentrale (FHEM) arbeitet, gibt es eigentlich keinen vernünftigen Grund (ausser 1-SD-Teams), einen der SDs als Lead zu nutzen. Man kann genauso gut einen virtuellen Aktor bauen und diesen zum Lead machen. Das ergibt eine bessere Struktur, da dieser virtuelle Aktor nicht verloren gehen kann.<br />
<br />
Erzeugen eines virtuellen TeamLeads könnte so aussehen. Es wird ein virtuelles Gerät und ein virtueller Kanal definiert und mit einem sprechenden Namen versehen:<br />
<pre>define TeamDev CUL_HM 111111 <br />
set TeamDev virtual 1<br />
rename TeamDev_Btn1 Rauchmelder_Team</pre><br />
<br />
'''Bitte beachten''': die HMID (im obigen Beispiel 111111) '''muss''' für die gesamte Installation einmalig sein und es darf '''nur''' Btn1 (HM Channel ID xxxxxx01) als TeamLead verwendet werden.<br />
<br />
Nach der Definition bitte '''unbedingt''' überprüfen, dass TeamDev das Attribut ('''attr''') '''IODev''' bzw. '''IOgrp''' gesetzt hat (das sollte normalerweise automatisch passieren)! Am Besten die Konfiguration mit HMinfo '''configCheck''' prüfen, die ordnungsgemäße Funktion des TeamDev ist wichtig für den Erfolg des folgenden Peerings der Rauchmelder.<br />
<br />
Man '''kann''' anstatt des separaten virtuellen Gerätes auch den '''ersten''' Kanal einer VCCU verwenden, falls der noch nicht anderweitig genutzt wird. <br />
<br />
Jeder Rauchmelder muss jetzt in das Team aufgenommen werden:<br />
<pre>set Rauchmelder_Team peerChan 0 Rauchmelder_Flur single set actor<br />
set Rauchmelder_Team peerChan 0 Rauchmelder_WZ single set actor<br />
...<br />
save</pre><br />
<br />
Hierbei ist "Rauchmelder_Team" der Name des virtuellen TeamLeaders und "Rauchmelder_Flur" der Name des jeweiligen Rauchmelders.<br />
<br />
Das "save" ist notwendig, um auch die Einstellungen des virtuellen SDs in der [[Konfiguration]] zu sichern.<br />
<br />
Bei jedem Rauchmelder sollte der Name des virtuellen TeamLeaders in der peerList stehen und beim virtuellen TeamLeader jeder Rauchmelder.<br />
<br />
Mit teamCall sollte man die korrekte Funktion des Teams prüfen, wer will auch mit alarmOn.<br />
<br />
== Variablen ==<br />
=== Internals ===<br />
Keine Spezifischen.<br />
<br />
=== Readings ===<br />
==== Einzelne SDs ====<br />
Für '''jeden''' SD sind folgende Readings relevant:<br />
<br />
teamCall from <name>:<count><br />
state:[off|smoke-Alarm_<count>]<br />
smoke_detect:<von_name><br />
battery:[ok|low]<br />
level:<0..200><br />
sdRepeat:[on|off]<br />
<br />
*'''count''' ist ein Zähler, den das Gerät liefert um neue Alarme unterscheiden zu können<br />
*'''level''' ist ein Wert zwischen 0 und 200. 200 ist Alarm, 199 bedeutet Alarm, aber die Sirene ist abgeschaltet.<br />
*'''sdRepeat''' ist ein Flag ob der SD als Reapeater für Nachrichten anderer SDs arbeitet. Das kann nötig sein, wenn nicht jeder SD jeden anderen empfängt. Das Flag kann über die Taste am SD eingestellt werden (siehe Gebrauchsanleitung). Es dürfen maximal 3 SDs in einer Gruppe als Reapeater konfiguriert sein. Ansonsten kann es zu verzögerten Alarmmeldungen kommen.<br />
<br />
==== TeamLead ====<br />
Beim '''TeamLead''' laufen alle Alarme auf:<br />
<br />
teamCall: from <name>:<count><br />
recentAlarm:<von_name><br />
level:<0..200><br />
eventNo:<count><br />
state:[off|smoke-Alarm_<count>]<br />
smoke_detect:<von_name><br />
SDteam:[add_<name>|remove_<name>]<br />
<br />
*'''von_name''' ist der Name des SD, der gemeldet hat. <br />
*'''smoke_detect''' ist der aktuelle Alarm, während '''recentAlarm''' die letzte Alarmquelle anzeigt, auch wenn der Alarm schon behoben ist.<br />
*'''SDteam''' kommt gelegentlich bei Konfigurationsereignissen zum Tragen.<br />
<br />
=== Attribute ===<br />
Besondere Attribute<br />
* '''msgRepeat''' sollte auf 1 stehen. SD ist ein burst device, wiederholen von Nachrichten belastet das HMLAN besonders. Die Team-Kommandos sind hiervon nicht beeinflusst, also auch nicht das Auslösen eines Alarms. <br />
* '''actCycle''' wird auf 99 Stunden gesetzt. Ein SD meldet sich alle 3 Tage bei der Zentrale, was der ActionDetector prüft.<br />
* '''msgRepeat''' 1<br />
Allgemein vorgeschlagen<br />
:'''IODev''' [HMLAN/HMUSB/CUL]<br />
:'''autoReadReg''' 5_readMissing<br />
:'''event-on-change-reading''' .*<br />
Optional, nur als Anregung zu verstehen<br />
:'''devStateIcon''' off:general_ok .*:secur_alarm<br />
:'''group''' smokeDetect<br />
:'''icon''' secur_smoke_detector<br />
Ebenfalls optional, jedoch nützlich für Homebridge-/Homekit-Anbindung:<br />
:'''genericDeviceType''' security<br />
<br />
== Alarme ==<br />
Meldet ein SD einen Alarm, wird dieser in dem SD und im TeamLead angezeigt.<br />
<br />
Nutzt man [[HomeMatic HMInfo|HMinfo]], wird ein Rauchalarm auch hier als "Error" gemeldet. In HMinfo wird dies für alle SD-Teams im System gemacht.<br />
<br />
== Probleme beim SD-2 ==<br />
<br />
Das Senden von TeamCall-/Alarmkommandos an die SD2 ist leider fragil. Bei jedem Befehl muss entweder der MessageCounter der Nachricht größer sein als der letzte oder (falls dies nicht der Fall ist) der Generationenzähler inkrementiert werden. Beide Werte werden in dem Reading aesCBCCounter des Teamleads abgelegt:<br />
<br />
<pre><br />
aesCBCCounter GGGGMM<br />
</pre><br />
<br />
Hierbei ist GGGG der Generationenzähler in Hex und MM der Messagecounter in Hex. Sollte dieses Reading gelöscht werden, reagieren die SD2 nicht mehr, da sie denken, eine alte Nachricht empfangen zu haben. Leider kann man die aktuellen Werte auch nicht mehr aus den SD2 auslesen...<br />
<br />
Falls die SD2 also nicht mehr reagieren, kann man mal probieren den Generationenzähler per Hand zu inkrementieren und den MessageCounter auf 0 zu setzen (aesCBCCounter hier vorher 0000XX):<br />
<br />
<pre><br />
setreading TeamLead aesCBCCounter 000100<br />
</pre><br />
<br />
Falls das Reading komplett gelöscht wurde, bitte langsam rantasten und den Generationenzähler immer nur um 1 erhöhen, denn was passiert, wenn der Generationencounter nach FFFF überläuft hat bisher noch niemand ausprobiert...<br />
<br />
<br />
== Nützliche Notifies ==<br />
Codefragmente, die man einsetzen kann. Ggf. muss man etwas anpassen, zumindest können sie als Anregung nützlich sein. <br />
* Bei Alarm E-Mail schicken und Licht im Flur anschalten<br />
<pre><br />
define sd.nf.report notify Rauchmelder_Team:.*smoke-Alarm.* {\<br />
<Mail versenden>;;<br />
fhem("set LichtTreppenhaus on");;<br />
}\<br />
</pre><br />
<br />
* Bei Alarm alle SDs des Teams stumm schalten durch Stummschalten eines einzelnen<br />
:<code>define sd.nf.quiet notify Rauchmelder_Team:.*level:.199 set Rauchmelder_Team alarmOff</code><br />
<br />
== Links ==<br />
* [http://www.eq-3.de/Downloads/eq3/downloads_produktkatalog/homematic/bda/HM-Sec-SD_GE_UM_V1.5_150407.pdf Montage- und Inbetriebnahmeanleitung HM-SEC-SD (PDF)]<br />
* [http://www.eq-3.de/Downloads/eq3/downloads_produktkatalog/homematic/bda/HM-Sec-SD-2_UM_eQ-3_GE_web.pdf Montage- und Inbetriebnahmeanleitung HM-SEC-SD-2 (PDF)]<br />
* [http://www.eq-3.de/Downloads/eq3/downloads_produktkatalog/homematic/pdb/Funk-Rauchwarnmelder_131408_Produktdatenblatt_V1.7.pdf Produktdatenblatt HM-SEC-SD-2 (PDF)]<br />
<br />
== Quellen ==<br />
<references /><br />
<br />
<br />
[[Kategorie:HomeMatic Components]]<br />
[[Kategorie:Rauchmelder]]</div>MGuhttp://wiki.fhem.de/w/index.php?title=HM-SEC-SD_Rauchmelder&diff=30802HM-SEC-SD Rauchmelder2019-06-21T13:37:38Z<p>MGu: /* Readings */</p>
<hr />
<div>{{Infobox Hardware<br />
|Bild=HM-SEC-SD o.jpeg <!-- HM-SEC-SD o.jpeg --><br />
|Bildbeschreibung=HomeMatic HM-SEC-SD Rauchmelder Oberseite<br />
|HWProtocol=HomeMatic<br />
|HWType=[[HomeMatic Type smokeDetector|smokeDetector]]<br />
|HWCategory=HomeMatic<br />
|HWComm=868MHz<br />
|HWChannels=<br />
|HWVoltage=9V<br />
|HWPowerConsumption= W im Standby<br />
|HWPoweredBy=3 x 1,5 V LR6/AA<br />
|HWSize=120x44mm<br />
|HWDeviceFHEM=[http://fhem.de/commandref.html#CUL_HM CUL_HM]<br />
|HWManufacturer=ELV / eQ-3<br />
}}<br />
<br />
== Features ==<br />
Der [[HM-SEC-SD Rauchmelder|HM-SEC-SD]] ist ein VdS-zertifizierter Rauchmelder. Mehrere Rauchmelder können unabhängig von einer Zentrale zu einer Gruppe zusammengefasst werden. Auch ohne FHEM-Zentrale meldet ein Rauchmelder seinen Alarm immer an die anderen vernetzten Rauchmelder weiter. <br />
<br />
Der [[HM-SEC-SD Rauchmelder|HM-SEC-SD-2]] (ca. 50€) ist die neue Version seit 2016. Auch dieser Melder wird in FHEM unterstützt. ''Das Gerät kann ausschließlich in Gruppen mit Rauchwarnmeldern des gleichen Typs (HM-Sec-SD-2) und nicht in einer Gruppe mit anderen Rauchwarnmeldern (z. B. HM-Sec-SD) genutzt werden.''<ref>[http://www.eq-3.de/produkte/homematic/sicherheit-und-ueberwachung/homematic-funk-rauchwarnmelder-293.html#beschreibung "Highlights" bei der Produktbeschreibung auf der EQ3-Site]</ref><br />
<br />
<br />
[[Datei: HM-SEC-SD-2.jpg|300px|thumb|right|HM-SEC-SD-2]]<br />
<br />
== Hinweise zum Betrieb mit FHEM ==<br />
Der HM-SEC-SD Rauchmelder beherrscht kein AES. Der Betrieb ist mit [[HMLAN Konfigurator]] oder mit [[CUL]] möglich. Das Pairing sollte wie in [[HomeMatic Devices pairen]] beschrieben durchgeführt werden.<br />
<br />
Der HM-SEC-SD-2 Rauchmelder arbeitet mit aesCBC, er benötigt dafür zwingend das Modul libcrypt-rijndael-perl unabhängig vom IO Device, auch für den HM-CFG-LAN!<br />
<br />
=== Teams ===<br />
Rauchmelder können mittels [[Peering (HomeMatic)|Peering]] in Teams gruppiert werden. Jeder SD kann einem Team angehören - und das sollte man auch einrichten. Nutzt man nur einen SD sollte man diesen mit sich selbst peeren.<br />
<br />
Beispiele:<br />
nutzt man einen SD und will diesen nicht mit anderen in einem Team haben peert man ihn mit sich selbst. Damit ist der SD sein eigener TeamLead. <br />
:<code>set Rauchmelder_Flur peerChan 0 Rauchmelder_Flur single set actor</code><br />
<br />
Hat man mehrere SDs, die in einem Team zusammengefasst werden sollen, wird der TeamLead festgelegt und alle SDs werden mit ihm gepeert. Das Team kann jederzeit erweitert werden. <br />
<pre>set Rauchmelder_Flur peerChan 0 Rauchmelder_Flur single set actor <br />
set Rauchmelder_Flur peerChan 0 Rauchmelder_WZ single set actor <br />
set Rauchmelder_Flur peerChan 0 Rauchmelder_SZ single set actor <br />
set Rauchmelder_Flur peerChan 0 Rauchmelder_KZ single set actor </pre><br />
<br />
Nutzt man einen virtuellen TeamLead - (siehe [[#virtueller TeamLead|virtueller TeamLead]]) - werden alle realen SDs mit diesem gepeert<br />
<pre>set Rauchmelder_Team peerChan 0 Rauchmelder_Flur single set actor<br />
set Rauchmelder_Team peerChan 0 Rauchmelder_WZ single set actor<br />
set Rauchmelder_Team peerChan 0 Rauchmelder_SZ single set actor<br />
set Rauchmelder_Team peerChan 0 Rauchmelder_KZ single set actor<br />
</pre><br />
<br />
Ein SD kann aus einem Team mittels unset entfernt werden.<br />
:<code>set Rauchmelder_Flur peerChan 0 Rauchmelder_Flur single unset actor </code><br />
<br />
Um einen SD von einem Team in ein anderes zu transferieren, muss man ihn erst mit ''unset'' aus dem Team entfernen, dann mit ''set'' in das neue Team eintragen. Einen physkalischen TeamLead kann man nur aus dem Team nehmen, indem man ihn aus allen Teammitgliedern entfernt. <br />
<br />
Die korrekte Gruppierung sollte nach der Konfiguration durch einen Teamcall geprüft werden.<br />
<br />
Der Betrieb mehrer Teams ist möglich, ein SD kann aber nur einem Team angehören. Will man einen SD von einem Team in ein anderes umhängen, muss man ihn erst aus dem ersten Team entfernen und dann in das Neue aufnehmen.<br />
<br />
=== TeamLead ===<br />
Für ein Team muss immer ein TeamLead festgelegt werden. Anders als der Name suggeriert, gibt es hier keinen Master. Sinn und Zweck ist einzig, eine Team-Adresse (HMId) festzulegen, unter der man alle SDs eines Teams ansprechen kann. Diese muss, wie alle HMIds, einzig im System sein. Um dies zu erreichen, verwendet HM beim Teamen ohne Zentrale die HMId eines der SDs. Verwendet man eine Zentrale (FHEM) kann man dies auch entzerren und einen virtuellen SD als TeamLead nutzen. Siehe hierzu [[#virtueller TeamLead|virtueller TeamLead]].<br />
<br />
Nutzt man nur einen einzelnen SD, sollte man diesen mit sich selbst peeren.<br />
<br />
=== Kommandos ===<br />
Es gibt Team-Nachrichten, die jeder SD senden kann und auf die jeder SD im Team reagiert. Jeder SD kann somit einen Teamcall auslösen oder einen Alarm ausgeben. Die Kommandos werden '''nicht''' von einem SD zum anderen weitergereicht. Auch der TeamLead hat '''keine''' Sonderfunktion. Der einzelne SD sendet seine Nachricht an das Team und jeder im Team reagiert darauf.<br />
<br />
Es ist somit darauf zu achten, dass auch die entferntesten SDs sich gegenseitig erreichen können.<br />
<br />
Die Kommandos können von der Zentrale getriggert werden. Da sie unter der Team-ID gesendet werden, stehen sie nur bei der Komponente des TeamLeads zu Verfügung.<br />
<br />
Dazu gehören teamCall, teamCallBat, alarmOn und alarmOff.<br />
<br />
Sie stehen nur für die Entity des TeamLeads zu Verfügung.<br />
<pre>set EurerTeamLeader alarmOn<br />
set EurerTeamLeader alarmOff<br />
set EurerTeamLeader teamCall<br />
set EurerTeamLeader teamCallBat ## nur für alte SDs <br />
</pre><br />
<br />
'''teamCall''' testet die Zugehörigkeit und Erreichbarkeit aller SDs im Team. Alle SDs sollten 10 mal leise piepen. '''teamCallBat''' erzeugt einen kürzeren Teamcall mit anderer Signalfolge, wie er bei schwacher Batterie eines Melders automatisch ausgelöst wird.<br />
<br />
Einzelne SDs kann man mit "statusRequest" abfragen.<br />
<br />
== Virtueller TeamLead ==<br />
Nutzt man nur einen einzelnen SD, kann/sollte man diesen mit sich selbst teamen (peerChan). In allen andere Fällen braucht man einen TeamLead um eine Team-ID zu erhalten. Man kann hierzu einen der SDs nutzen. Wird dieser einmal ausgewechselt, hat man allerdings seine Team-ID verloren.<br />
<br />
Wenn man mit Zentrale (FHEM) arbeitet, gibt es eigentlich keinen vernünftigen Grund (ausser 1-SD-Teams), einen der SDs als Lead zu nutzen. Man kann genauso gut einen virtuellen Aktor bauen und diesen zum Lead machen. Das ergibt eine bessere Struktur, da dieser virtuelle Aktor nicht verloren gehen kann.<br />
<br />
Erzeugen eines virtuellen TeamLeads könnte so aussehen. Es wird ein virtuelles Gerät und ein virtueller Kanal definiert und mit einem sprechenden Namen versehen:<br />
<pre>define TeamDev CUL_HM 111111 <br />
set TeamDev virtual 1<br />
rename TeamDev_Btn1 Rauchmelder_Team</pre><br />
<br />
'''Bitte beachten''': die HMID (im obigen Beispiel 111111) '''muss''' für die gesamte Installation einmalig sein und es darf '''nur''' Btn1 (HM Channel ID xxxxxx01) als TeamLead verwendet werden.<br />
<br />
Nach der Definition bitte '''unbedingt''' überprüfen, dass TeamDev das Attribut ('''attr''') '''IODev''' bzw. '''IOgrp''' gesetzt hat (das sollte normalerweise automatisch passieren)! Am Besten die Konfiguration mit HMinfo '''configCheck''' prüfen, die ordnungsgemäße Funktion des TeamDev ist wichtig für den Erfolg des folgenden Peerings der Rauchmelder.<br />
<br />
Man '''kann''' anstatt des separaten virtuellen Gerätes auch den '''ersten''' Kanal einer VCCU verwenden, falls der noch nicht anderweitig genutzt wird. <br />
<br />
Jeder Rauchmelder muss jetzt in das Team aufgenommen werden:<br />
<pre>set Rauchmelder_Team peerChan 0 Rauchmelder_Flur single set actor<br />
set Rauchmelder_Team peerChan 0 Rauchmelder_WZ single set actor<br />
...<br />
save</pre><br />
<br />
Hierbei ist "Rauchmelder_Team" der Name des virtuellen TeamLeaders und "Rauchmelder_Flur" der Name des jeweiligen Rauchmelders.<br />
<br />
Das "save" ist notwendig, um auch die Einstellungen des virtuellen SDs in der [[Konfiguration]] zu sichern.<br />
<br />
Bei jedem Rauchmelder sollte der Name des virtuellen TeamLeaders in der peerList stehen und beim virtuellen TeamLeader jeder Rauchmelder.<br />
<br />
Mit teamCall sollte man die korrekte Funktion des Teams prüfen, wer will auch mit alarmOn.<br />
<br />
== Variablen ==<br />
=== Internals ===<br />
Keine Spezifischen.<br />
<br />
=== Readings ===<br />
Für '''jeden''' SD sind folgende Readings relevant:<br />
<br />
teamCall from <name>:<count><br />
state:[off|smoke-Alarm_<count>]<br />
smoke_detect:<von_name><br />
battery:[ok|low]<br />
level:<0..200><br />
sdRepeat:[on|off]<br />
<br />
*'''count''' ist ein Zähler, den das Gerät liefert um neue Alarme unterscheiden zu können<br />
*'''level''' ist ein Wert zwischen 0 und 200. 200 ist Alarm, 199 bedeutet Alarm, aber die Sirene ist abgeschaltet.<br />
*'''sdRepeat''' ist ein Flag ob der SD als Reapeater für Nachrichten anderer SDs arbeitet. Das kann nötig sein, wenn nicht jeder SD jeden anderen empfängt. Das Flag kann über die Taste am SD eingestellt werden (siehe Gebrauchsanleitung). Es dürfen maximal 3 SDs in einer Gruppe als Reapeater konfiguriert sein. Ansonsten kann es zu verzögerten Alarmmeldungen kommen.<br />
<br />
Beim '''TeamLead''' laufen alle Alarme auf<br />
<br />
teamCall: from <name>:<count><br />
recentAlarm:<von_name><br />
level:<0..200><br />
eventNo:<count><br />
state:[off|smoke-Alarm_<count>]<br />
smoke_detect:<von_name><br />
SDteam:[add_<name>|remove_<name>]<br />
<br />
*'''von_name''' ist der Name des SD, der gemeldet hat. <br />
*'''smoke_detect''' ist der aktuelle Alarm, während '''recentAlarm''' die letzte Alarmquelle anzeigt, auch wenn der Alarm schon behoben ist.<br />
*'''SDteam''' kommt gelegentlich bei Konfigurationsereignissen zum Tragen.<br />
<br />
=== Attribute ===<br />
Besondere Attribute<br />
* '''msgRepeat''' sollte auf 1 stehen. SD ist ein burst device, wiederholen von Nachrichten belastet das HMLAN besonders. Die Team-Kommandos sind hiervon nicht beeinflusst, also auch nicht das Auslösen eines Alarms. <br />
* '''actCycle''' wird auf 99 Stunden gesetzt. Ein SD meldet sich alle 3 Tage bei der Zentrale, was der ActionDetector prüft.<br />
* '''msgRepeat''' 1<br />
Allgemein vorgeschlagen<br />
:'''IODev''' [HMLAN/HMUSB/CUL]<br />
:'''autoReadReg''' 5_readMissing<br />
:'''event-on-change-reading''' .*<br />
Optional, nur als Anregung zu verstehen<br />
:'''devStateIcon''' off:general_ok .*:secur_alarm<br />
:'''group''' smokeDetect<br />
:'''icon''' secur_smoke_detector<br />
Ebenfalls optional, jedoch nützlich für Homebridge-/Homekit-Anbindung:<br />
:'''genericDeviceType''' security<br />
<br />
== Alarme ==<br />
Meldet ein SD einen Alarm, wird dieser in dem SD und im TeamLead angezeigt.<br />
<br />
Nutzt man [[HomeMatic HMInfo|HMinfo]], wird ein Rauchalarm auch hier als "Error" gemeldet. In HMinfo wird dies für alle SD-Teams im System gemacht.<br />
<br />
== Probleme beim SD-2 ==<br />
<br />
Das Senden von TeamCall-/Alarmkommandos an die SD2 ist leider fragil. Bei jedem Befehl muss entweder der MessageCounter der Nachricht größer sein als der letzte oder (falls dies nicht der Fall ist) der Generationenzähler inkrementiert werden. Beide Werte werden in dem Reading aesCBCCounter des Teamleads abgelegt:<br />
<br />
<pre><br />
aesCBCCounter GGGGMM<br />
</pre><br />
<br />
Hierbei ist GGGG der Generationenzähler in Hex und MM der Messagecounter in Hex. Sollte dieses Reading gelöscht werden, reagieren die SD2 nicht mehr, da sie denken, eine alte Nachricht empfangen zu haben. Leider kann man die aktuellen Werte auch nicht mehr aus den SD2 auslesen...<br />
<br />
Falls die SD2 also nicht mehr reagieren, kann man mal probieren den Generationenzähler per Hand zu inkrementieren und den MessageCounter auf 0 zu setzen (aesCBCCounter hier vorher 0000XX):<br />
<br />
<pre><br />
setreading TeamLead aesCBCCounter 000100<br />
</pre><br />
<br />
Falls das Reading komplett gelöscht wurde, bitte langsam rantasten und den Generationenzähler immer nur um 1 erhöhen, denn was passiert, wenn der Generationencounter nach FFFF überläuft hat bisher noch niemand ausprobiert...<br />
<br />
<br />
== Nützliche Notifies ==<br />
Codefragmente, die man einsetzen kann. Ggf. muss man etwas anpassen, zumindest können sie als Anregung nützlich sein. <br />
* Bei Alarm E-Mail schicken und Licht im Flur anschalten<br />
<pre><br />
define sd.nf.report notify Rauchmelder_Team:.*smoke-Alarm.* {\<br />
<Mail versenden>;;<br />
fhem("set LichtTreppenhaus on");;<br />
}\<br />
</pre><br />
<br />
* Bei Alarm alle SDs des Teams stumm schalten durch Stummschalten eines einzelnen<br />
:<code>define sd.nf.quiet notify Rauchmelder_Team:.*level:.199 set Rauchmelder_Team alarmOff</code><br />
<br />
== Links ==<br />
* [http://www.eq-3.de/Downloads/eq3/downloads_produktkatalog/homematic/bda/HM-Sec-SD_GE_UM_V1.5_150407.pdf Montage- und Inbetriebnahmeanleitung HM-SEC-SD (PDF)]<br />
* [http://www.eq-3.de/Downloads/eq3/downloads_produktkatalog/homematic/bda/HM-Sec-SD-2_UM_eQ-3_GE_web.pdf Montage- und Inbetriebnahmeanleitung HM-SEC-SD-2 (PDF)]<br />
* [http://www.eq-3.de/Downloads/eq3/downloads_produktkatalog/homematic/pdb/Funk-Rauchwarnmelder_131408_Produktdatenblatt_V1.7.pdf Produktdatenblatt HM-SEC-SD-2 (PDF)]<br />
<br />
== Quellen ==<br />
<references /><br />
<br />
<br />
[[Kategorie:HomeMatic Components]]<br />
[[Kategorie:Rauchmelder]]</div>MGuhttp://wiki.fhem.de/w/index.php?title=HM-SEC-SD_Rauchmelder&diff=30801HM-SEC-SD Rauchmelder2019-06-21T13:34:03Z<p>MGu: /* Readings */ sdRepeat</p>
<hr />
<div>{{Infobox Hardware<br />
|Bild=HM-SEC-SD o.jpeg <!-- HM-SEC-SD o.jpeg --><br />
|Bildbeschreibung=HomeMatic HM-SEC-SD Rauchmelder Oberseite<br />
|HWProtocol=HomeMatic<br />
|HWType=[[HomeMatic Type smokeDetector|smokeDetector]]<br />
|HWCategory=HomeMatic<br />
|HWComm=868MHz<br />
|HWChannels=<br />
|HWVoltage=9V<br />
|HWPowerConsumption= W im Standby<br />
|HWPoweredBy=3 x 1,5 V LR6/AA<br />
|HWSize=120x44mm<br />
|HWDeviceFHEM=[http://fhem.de/commandref.html#CUL_HM CUL_HM]<br />
|HWManufacturer=ELV / eQ-3<br />
}}<br />
<br />
== Features ==<br />
Der [[HM-SEC-SD Rauchmelder|HM-SEC-SD]] ist ein VdS-zertifizierter Rauchmelder. Mehrere Rauchmelder können unabhängig von einer Zentrale zu einer Gruppe zusammengefasst werden. Auch ohne FHEM-Zentrale meldet ein Rauchmelder seinen Alarm immer an die anderen vernetzten Rauchmelder weiter. <br />
<br />
Der [[HM-SEC-SD Rauchmelder|HM-SEC-SD-2]] (ca. 50€) ist die neue Version seit 2016. Auch dieser Melder wird in FHEM unterstützt. ''Das Gerät kann ausschließlich in Gruppen mit Rauchwarnmeldern des gleichen Typs (HM-Sec-SD-2) und nicht in einer Gruppe mit anderen Rauchwarnmeldern (z. B. HM-Sec-SD) genutzt werden.''<ref>[http://www.eq-3.de/produkte/homematic/sicherheit-und-ueberwachung/homematic-funk-rauchwarnmelder-293.html#beschreibung "Highlights" bei der Produktbeschreibung auf der EQ3-Site]</ref><br />
<br />
<br />
[[Datei: HM-SEC-SD-2.jpg|300px|thumb|right|HM-SEC-SD-2]]<br />
<br />
== Hinweise zum Betrieb mit FHEM ==<br />
Der HM-SEC-SD Rauchmelder beherrscht kein AES. Der Betrieb ist mit [[HMLAN Konfigurator]] oder mit [[CUL]] möglich. Das Pairing sollte wie in [[HomeMatic Devices pairen]] beschrieben durchgeführt werden.<br />
<br />
Der HM-SEC-SD-2 Rauchmelder arbeitet mit aesCBC, er benötigt dafür zwingend das Modul libcrypt-rijndael-perl unabhängig vom IO Device, auch für den HM-CFG-LAN!<br />
<br />
=== Teams ===<br />
Rauchmelder können mittels [[Peering (HomeMatic)|Peering]] in Teams gruppiert werden. Jeder SD kann einem Team angehören - und das sollte man auch einrichten. Nutzt man nur einen SD sollte man diesen mit sich selbst peeren.<br />
<br />
Beispiele:<br />
nutzt man einen SD und will diesen nicht mit anderen in einem Team haben peert man ihn mit sich selbst. Damit ist der SD sein eigener TeamLead. <br />
:<code>set Rauchmelder_Flur peerChan 0 Rauchmelder_Flur single set actor</code><br />
<br />
Hat man mehrere SDs, die in einem Team zusammengefasst werden sollen, wird der TeamLead festgelegt und alle SDs werden mit ihm gepeert. Das Team kann jederzeit erweitert werden. <br />
<pre>set Rauchmelder_Flur peerChan 0 Rauchmelder_Flur single set actor <br />
set Rauchmelder_Flur peerChan 0 Rauchmelder_WZ single set actor <br />
set Rauchmelder_Flur peerChan 0 Rauchmelder_SZ single set actor <br />
set Rauchmelder_Flur peerChan 0 Rauchmelder_KZ single set actor </pre><br />
<br />
Nutzt man einen virtuellen TeamLead - (siehe [[#virtueller TeamLead|virtueller TeamLead]]) - werden alle realen SDs mit diesem gepeert<br />
<pre>set Rauchmelder_Team peerChan 0 Rauchmelder_Flur single set actor<br />
set Rauchmelder_Team peerChan 0 Rauchmelder_WZ single set actor<br />
set Rauchmelder_Team peerChan 0 Rauchmelder_SZ single set actor<br />
set Rauchmelder_Team peerChan 0 Rauchmelder_KZ single set actor<br />
</pre><br />
<br />
Ein SD kann aus einem Team mittels unset entfernt werden.<br />
:<code>set Rauchmelder_Flur peerChan 0 Rauchmelder_Flur single unset actor </code><br />
<br />
Um einen SD von einem Team in ein anderes zu transferieren, muss man ihn erst mit ''unset'' aus dem Team entfernen, dann mit ''set'' in das neue Team eintragen. Einen physkalischen TeamLead kann man nur aus dem Team nehmen, indem man ihn aus allen Teammitgliedern entfernt. <br />
<br />
Die korrekte Gruppierung sollte nach der Konfiguration durch einen Teamcall geprüft werden.<br />
<br />
Der Betrieb mehrer Teams ist möglich, ein SD kann aber nur einem Team angehören. Will man einen SD von einem Team in ein anderes umhängen, muss man ihn erst aus dem ersten Team entfernen und dann in das Neue aufnehmen.<br />
<br />
=== TeamLead ===<br />
Für ein Team muss immer ein TeamLead festgelegt werden. Anders als der Name suggeriert, gibt es hier keinen Master. Sinn und Zweck ist einzig, eine Team-Adresse (HMId) festzulegen, unter der man alle SDs eines Teams ansprechen kann. Diese muss, wie alle HMIds, einzig im System sein. Um dies zu erreichen, verwendet HM beim Teamen ohne Zentrale die HMId eines der SDs. Verwendet man eine Zentrale (FHEM) kann man dies auch entzerren und einen virtuellen SD als TeamLead nutzen. Siehe hierzu [[#virtueller TeamLead|virtueller TeamLead]].<br />
<br />
Nutzt man nur einen einzelnen SD, sollte man diesen mit sich selbst peeren.<br />
<br />
=== Kommandos ===<br />
Es gibt Team-Nachrichten, die jeder SD senden kann und auf die jeder SD im Team reagiert. Jeder SD kann somit einen Teamcall auslösen oder einen Alarm ausgeben. Die Kommandos werden '''nicht''' von einem SD zum anderen weitergereicht. Auch der TeamLead hat '''keine''' Sonderfunktion. Der einzelne SD sendet seine Nachricht an das Team und jeder im Team reagiert darauf.<br />
<br />
Es ist somit darauf zu achten, dass auch die entferntesten SDs sich gegenseitig erreichen können.<br />
<br />
Die Kommandos können von der Zentrale getriggert werden. Da sie unter der Team-ID gesendet werden, stehen sie nur bei der Komponente des TeamLeads zu Verfügung.<br />
<br />
Dazu gehören teamCall, teamCallBat, alarmOn und alarmOff.<br />
<br />
Sie stehen nur für die Entity des TeamLeads zu Verfügung.<br />
<pre>set EurerTeamLeader alarmOn<br />
set EurerTeamLeader alarmOff<br />
set EurerTeamLeader teamCall<br />
set EurerTeamLeader teamCallBat ## nur für alte SDs <br />
</pre><br />
<br />
'''teamCall''' testet die Zugehörigkeit und Erreichbarkeit aller SDs im Team. Alle SDs sollten 10 mal leise piepen. '''teamCallBat''' erzeugt einen kürzeren Teamcall mit anderer Signalfolge, wie er bei schwacher Batterie eines Melders automatisch ausgelöst wird.<br />
<br />
Einzelne SDs kann man mit "statusRequest" abfragen.<br />
<br />
== Virtueller TeamLead ==<br />
Nutzt man nur einen einzelnen SD, kann/sollte man diesen mit sich selbst teamen (peerChan). In allen andere Fällen braucht man einen TeamLead um eine Team-ID zu erhalten. Man kann hierzu einen der SDs nutzen. Wird dieser einmal ausgewechselt, hat man allerdings seine Team-ID verloren.<br />
<br />
Wenn man mit Zentrale (FHEM) arbeitet, gibt es eigentlich keinen vernünftigen Grund (ausser 1-SD-Teams), einen der SDs als Lead zu nutzen. Man kann genauso gut einen virtuellen Aktor bauen und diesen zum Lead machen. Das ergibt eine bessere Struktur, da dieser virtuelle Aktor nicht verloren gehen kann.<br />
<br />
Erzeugen eines virtuellen TeamLeads könnte so aussehen. Es wird ein virtuelles Gerät und ein virtueller Kanal definiert und mit einem sprechenden Namen versehen:<br />
<pre>define TeamDev CUL_HM 111111 <br />
set TeamDev virtual 1<br />
rename TeamDev_Btn1 Rauchmelder_Team</pre><br />
<br />
'''Bitte beachten''': die HMID (im obigen Beispiel 111111) '''muss''' für die gesamte Installation einmalig sein und es darf '''nur''' Btn1 (HM Channel ID xxxxxx01) als TeamLead verwendet werden.<br />
<br />
Nach der Definition bitte '''unbedingt''' überprüfen, dass TeamDev das Attribut ('''attr''') '''IODev''' bzw. '''IOgrp''' gesetzt hat (das sollte normalerweise automatisch passieren)! Am Besten die Konfiguration mit HMinfo '''configCheck''' prüfen, die ordnungsgemäße Funktion des TeamDev ist wichtig für den Erfolg des folgenden Peerings der Rauchmelder.<br />
<br />
Man '''kann''' anstatt des separaten virtuellen Gerätes auch den '''ersten''' Kanal einer VCCU verwenden, falls der noch nicht anderweitig genutzt wird. <br />
<br />
Jeder Rauchmelder muss jetzt in das Team aufgenommen werden:<br />
<pre>set Rauchmelder_Team peerChan 0 Rauchmelder_Flur single set actor<br />
set Rauchmelder_Team peerChan 0 Rauchmelder_WZ single set actor<br />
...<br />
save</pre><br />
<br />
Hierbei ist "Rauchmelder_Team" der Name des virtuellen TeamLeaders und "Rauchmelder_Flur" der Name des jeweiligen Rauchmelders.<br />
<br />
Das "save" ist notwendig, um auch die Einstellungen des virtuellen SDs in der [[Konfiguration]] zu sichern.<br />
<br />
Bei jedem Rauchmelder sollte der Name des virtuellen TeamLeaders in der peerList stehen und beim virtuellen TeamLeader jeder Rauchmelder.<br />
<br />
Mit teamCall sollte man die korrekte Funktion des Teams prüfen, wer will auch mit alarmOn.<br />
<br />
== Variablen ==<br />
=== Internals ===<br />
Keine Spezifischen.<br />
<br />
=== Readings ===<br />
Für '''jeden''' SD sind folgende Readings relevant:<br />
<br />
teamCall from <name>:<count><br />
state:[off|smoke-Alarm_<count>]<br />
smoke_detect:<von_name><br />
battery:[ok|low]<br />
level:<0..200><br />
sdRepeat:[on|off]<br />
<br />
*'''count''' ist ein Zähler, den das Gerät liefert um neue Alarme unterscheiden zu können<br />
*'''level''' ist ein Wert zwischen 0 und 200. 200 ist Alarm, 199 bedeutet Alarm, aber die Sirene ist abgeschaltet.<br />
*'''sdRepeat''' ist ein Flag ob der SD als Reapeater für Nachrichten anderer SDs arbeitet. Diese Flag kann über die Taste am SD eingestellt werden (siehe Gebrauchsanleitung). Es dürfen maximal 3 SDs in einer Gruppe als Reapeater konfiguriert sein. Ansonsten kann es zu verzögerten Alarmmeldungen kommen.<br />
<br />
Beim '''TeamLead''' laufen alle Alarme auf<br />
<br />
teamCall: from <name>:<count><br />
recentAlarm:<von_name><br />
level:<0..200><br />
eventNo:<count><br />
state:[off|smoke-Alarm_<count>]<br />
smoke_detect:<von_name><br />
SDteam:[add_<name>|remove_<name>]<br />
<br />
*'''von_name''' ist der Name des SD, der gemeldet hat. <br />
*'''smoke_detect''' ist der aktuelle Alarm, während '''recentAlarm''' die letzte Alarmquelle anzeigt, auch wenn der Alarm schon behoben ist.<br />
*'''SDteam''' kommt gelegentlich bei Konfigurationsereignissen zum Tragen.<br />
<br />
=== Attribute ===<br />
Besondere Attribute<br />
* '''msgRepeat''' sollte auf 1 stehen. SD ist ein burst device, wiederholen von Nachrichten belastet das HMLAN besonders. Die Team-Kommandos sind hiervon nicht beeinflusst, also auch nicht das Auslösen eines Alarms. <br />
* '''actCycle''' wird auf 99 Stunden gesetzt. Ein SD meldet sich alle 3 Tage bei der Zentrale, was der ActionDetector prüft.<br />
* '''msgRepeat''' 1<br />
Allgemein vorgeschlagen<br />
:'''IODev''' [HMLAN/HMUSB/CUL]<br />
:'''autoReadReg''' 5_readMissing<br />
:'''event-on-change-reading''' .*<br />
Optional, nur als Anregung zu verstehen<br />
:'''devStateIcon''' off:general_ok .*:secur_alarm<br />
:'''group''' smokeDetect<br />
:'''icon''' secur_smoke_detector<br />
Ebenfalls optional, jedoch nützlich für Homebridge-/Homekit-Anbindung:<br />
:'''genericDeviceType''' security<br />
<br />
== Alarme ==<br />
Meldet ein SD einen Alarm, wird dieser in dem SD und im TeamLead angezeigt.<br />
<br />
Nutzt man [[HomeMatic HMInfo|HMinfo]], wird ein Rauchalarm auch hier als "Error" gemeldet. In HMinfo wird dies für alle SD-Teams im System gemacht.<br />
<br />
== Probleme beim SD-2 ==<br />
<br />
Das Senden von TeamCall-/Alarmkommandos an die SD2 ist leider fragil. Bei jedem Befehl muss entweder der MessageCounter der Nachricht größer sein als der letzte oder (falls dies nicht der Fall ist) der Generationenzähler inkrementiert werden. Beide Werte werden in dem Reading aesCBCCounter des Teamleads abgelegt:<br />
<br />
<pre><br />
aesCBCCounter GGGGMM<br />
</pre><br />
<br />
Hierbei ist GGGG der Generationenzähler in Hex und MM der Messagecounter in Hex. Sollte dieses Reading gelöscht werden, reagieren die SD2 nicht mehr, da sie denken, eine alte Nachricht empfangen zu haben. Leider kann man die aktuellen Werte auch nicht mehr aus den SD2 auslesen...<br />
<br />
Falls die SD2 also nicht mehr reagieren, kann man mal probieren den Generationenzähler per Hand zu inkrementieren und den MessageCounter auf 0 zu setzen (aesCBCCounter hier vorher 0000XX):<br />
<br />
<pre><br />
setreading TeamLead aesCBCCounter 000100<br />
</pre><br />
<br />
Falls das Reading komplett gelöscht wurde, bitte langsam rantasten und den Generationenzähler immer nur um 1 erhöhen, denn was passiert, wenn der Generationencounter nach FFFF überläuft hat bisher noch niemand ausprobiert...<br />
<br />
<br />
== Nützliche Notifies ==<br />
Codefragmente, die man einsetzen kann. Ggf. muss man etwas anpassen, zumindest können sie als Anregung nützlich sein. <br />
* Bei Alarm E-Mail schicken und Licht im Flur anschalten<br />
<pre><br />
define sd.nf.report notify Rauchmelder_Team:.*smoke-Alarm.* {\<br />
<Mail versenden>;;<br />
fhem("set LichtTreppenhaus on");;<br />
}\<br />
</pre><br />
<br />
* Bei Alarm alle SDs des Teams stumm schalten durch Stummschalten eines einzelnen<br />
:<code>define sd.nf.quiet notify Rauchmelder_Team:.*level:.199 set Rauchmelder_Team alarmOff</code><br />
<br />
== Links ==<br />
* [http://www.eq-3.de/Downloads/eq3/downloads_produktkatalog/homematic/bda/HM-Sec-SD_GE_UM_V1.5_150407.pdf Montage- und Inbetriebnahmeanleitung HM-SEC-SD (PDF)]<br />
* [http://www.eq-3.de/Downloads/eq3/downloads_produktkatalog/homematic/bda/HM-Sec-SD-2_UM_eQ-3_GE_web.pdf Montage- und Inbetriebnahmeanleitung HM-SEC-SD-2 (PDF)]<br />
* [http://www.eq-3.de/Downloads/eq3/downloads_produktkatalog/homematic/pdb/Funk-Rauchwarnmelder_131408_Produktdatenblatt_V1.7.pdf Produktdatenblatt HM-SEC-SD-2 (PDF)]<br />
<br />
== Quellen ==<br />
<references /><br />
<br />
<br />
[[Kategorie:HomeMatic Components]]<br />
[[Kategorie:Rauchmelder]]</div>MGuhttp://wiki.fhem.de/w/index.php?title=SIGNALduino_Compilieren&diff=25365SIGNALduino Compilieren2018-02-18T14:16:28Z<p>MGu: /* SIGNALDuino konfigurieren und testen */</p>
<hr />
<div>__TOC__<br />
== SIGNALduino in die Arduino Entwicklungsumgebung einbinden ==<br />
Zur Inbetriebnahme von [[SIGNALduino]] auf der Arduino IDE (getestet mit auf Arduino V1.6.7) müssen die Quelltexte von [https://github.com/RFD-FHEM/SIGNALDuino/ GitHub] (Stand Feb. 2017) geladen werden.<br />
<br />
Dort <code>Clone or download</code> und danach <code>Download ZIP</code> klicken und das ZIP-Archiv auspacken oder auf der Kommandozeile <code>git clone https://github.com/RFD-FHEM/SIGNALDuino.git</code> ausführen.<br />
<br />
Es werden folgende Dateien benötigt:<br />
* Die Datei <code>RF_Receiver.ino</code> in einen Ordner <code>RF_Receiver</code>, am besten direkt ins <code>Arduino</code> Verzeichnis der IDE kopieren.<br />
* Im <code>libraries</code> Ordner der Arduino IDE am besten einen Ordner mit Namen <code>SIGNALduino</code> anlegen, dort müssen dann die Dateien <code>bitstore</code>, <code>output</code>, <code>signalDecoder</code>, <code>SimpleFIFO</code> und <code>TimerOne</code> (jeweils <code>.cpp</code> und <code>.h</code> Datei) abgelegt werden.<br />
* Im diesem <code>SIGNALduino</code> Verzeichnis ist dann noch ein Unterverzeichnis <code>config</code> anzulegen, dort muss die Datei <code>known_16bit_timers.h</code> abgelegt werden.<br />
<br />
Struktur der SIGNALduino libraries:[[Datei:SIGNALduino-ViaArduinoEnvironment.jpg]]<br />
<br />
<br />
In Der Arduino Entwicklungsumgebung unter <code>Werkzeuge</code> → <code>Board</code> <tt>'''"Arduino Nano"'''</tt> und unter <code>Werkzeuge</code> → <code>Prozessor</code> <tt>'''"ATmega328"'''</tt> angeben. Nach Einstecken des SIGNALduinos in die USB Buchse noch den entsprechenden <code>COM-Port</code> unter <code>Werkzeuge</code> → <code>Port</code> angeben, danach sollte sich der Scetch <code>RF_Receiver.ino</code> übersetzen und auf den SIGNALduino laden lassen.<br />
<br />
== SIGNALduino mit Makefile unter Linux ==<br />
Wer lieber auf der Kommandozeile arbeitet kann SIGNALduino auch mit einem Makefile übersetzen und laden.<br />
Benötigt werden dazu:<br />
* Der Cross-Compiler und alle Werkzeuge für Arduino bzw. AVR. Bei Ubuntu und Debian Systemen:<br />
<source lang=bash><br />
# Arduino pakete installieren:<br />
sudo apt-get install arduino arduino-core arduino-mighty-1284p arduino-mk<br />
# AVR<br />
sudo apt-get install flashrom gcc-avr avrdude avr-libc binutils-avr<br />
# Die Unterstützung der Braillezeile kann zu Konflikten um den seriellen Port führen<br />
sudo apt-get remove brltty brltty-x11<br />
# Arduino-Makefile verwendet YAML und serialport in Perl<br />
sudo apt-get libdevice-serialport-perl libyaml-perl<br />
</source><br />
In den Paketen sind die Arduino Quellen und Arduino-Makefile enthalten.<br />
Bei wem das aber nicht klappt, der sollte wie hier beschrieben die neusten Versionen verwenden.<br />
<br />
* [https://github.com/RFD-FHEM/SIGNALDuino.git SIGNALDuino Quelltexte]<br />
<source lang=bash><br />
# Hier kann man natürlich jedes beliebige Verzeichnis nehmen.<br />
mkdir -p ~/src/arduino; cd ~/src/arduino<br />
# SIGNALDuino von github clonen<br />
git clone https://github.com/RFD-FHEM/SIGNALDuino.git<br />
</source><br />
<br />
* Die [https://www.arduino.cc/en/Main/Software Arduino Quellen] (optional)<br />
<source lang=bash><br />
# siehe https://www.arduino.cc/en/Main/Software für neuste Version<br />
wget https://downloads.arduino.cc/arduino-1.8.5-linux64.tar.xz<br />
tar xvJf arduino-1.8.5-linux64.tar.xz<br />
</source><br />
<br />
* Die neuste Version Arduino-Makefile (optional)<br />
<source lang=bash><br />
# Neuste Version von github clonen<br />
git clone https://github.com/sudar/Arduino-Makefile.git<br />
</source><br />
<br />
Jetzt muss in <code>SIGNALDuino/RF_Receiver</code> noch ein <code>Makefile</code> erstellt werden:<br />
<source lang=make><br />
# Verzeichnis in dem die Arduino-Quellen liegen<br />
ARDUINO_DIR=$(HOME)/src/arduino/arduino-1.8.5<br />
# Verzeichnis mit dem Arduino-Makefile<br />
ARDMK_DIR=$(HOME)/src/arduino/Arduino-Makefile<br />
# Basisverzeichnis unter dem die AVR-Werkzeuge liegen<br />
AVR_TOOLS_DIR=/usr<br />
AVRDUDE_OPTS = -v<br />
# Ab Arduino 1.5 sollte man die Architektur angeben.<br />
ARCHITECTURE = avr<br />
BOARD_TAG = nano<br />
BOARD_SUB = atmega328<br />
USER_LIB_PATH += $(realpath ../src/_micro-api/libraries)<br />
ARDUINO_LIBS += bitstore output signalDecoder SimpleFIFO TimerOne EEPROM<br />
# Device des Arduino nano<br />
MONITOR_PORT = /dev/ttyUSB0<br />
# AVRDUDE = /usr/bin/avrdude<br />
AVRDUDE_CONF = /etc/avrdude.conf<br />
include $(ARDMK_DIR)/Arduino.mk<br />
</source><br />
Wer die Arduino Quellen und Arduino-Makefile aus der Paketverwaltung verwenden möchte, kann folgendes ändern:<br />
<source lang=make><br />
ARDUINO_DIR=/usr/share/arduino<br />
ARDMK_DIR=$(ARDUINO_DIR)<br />
</source><br />
<br />
Mit stand vom 17.02.2018 müssen jetzt noch ein paar kleine Fehler beseitigt werden:<br />
Präprozessor-Direktiven werden nicht mit Semikolon abgeschlossen<br />
* in <code>RF_Receiver/RF_Receiver.ino</code><br />
:* <code>#define CMP_NEWSD</code> statt <code>#define CMP_NEWSD;</code><br />
Linux unterscheidet Groß- und Kleinschreibung bei Dateien:<br />
* in <code>src/_micro-api/libraries/output/src/output.h</code><br />
* und in <code>src/_micro-api/libraries/signalDecoder/src/signalDecoder.h</code><br />
:* <code> #include "Arduino.h"</code> statt <code> #include "arduino.h"</code><br />
Das Makefile ignoriert Bibliotheken ohne <code>library.properties</code><br />
* in <code>src/_micro-api/libraries/signalDecoder</code> fehlt <code>library.properties</code>.<br />
<source lang=bash><br />
cd src/_micro-api/libraries/signalDecoder<br />
cp ../bitstore/library.properties .<br />
sed -i 's/bitstore/signalDecoder/g' library.properties<br />
</source><br />
<br />
Danach kann SIGNALDuino für den Arduino Nano übersetzt werden:<br />
<source lang=bash><br />
cd RF_Receiver<br />
make<br />
# Auf den Arduino laden (flashen)<br />
make upload<br />
# Aufräumen mit<br />
make clean<br />
</source><br />
<br />
== SIGNALDuino konfigurieren und testen ==<br />
[[Datei:Fhemduino_schematic.png|mini|FHEMduino bzw. SIGNALDuino Schaltplan]]<br />
In der Datei <code>RF_Receiver.ino</code> sind u.a. folgende Einstellungen:<br />
* <code>BAUDRATE</code> Die Datenrate mit der SIGNALDuino mit dem PC kommuniziert (Voreinstellung 57600). Man kann also z.B. mit <code>minicom -D /dev/ttyUSB0 -8 -b 57600</code> die Kommunikation testen.<br />
* <code>PIN_LED</code> Der Pin an dem die LED zur Signalisierung von Nachrichten angeschlossen ist (Voreinstellung D13 = LED <code>L</code> auf dem Nano).<br />
* <code>PIN_RECEIVE</code> Der Pin zum Empfang von Daten (Voreinstellung D2).<br />
* <code>PIN_SEND</code> Der Pin zum Senden von Daten (Voreinstellung D11).<br />
<br />
Öffnet man ein Terminal (z.B. <code>minicom</code> siehe oben) so kann man die Kommandoschnittstelle des SIGNALDuino probieren:<br />
* Eingabe "<code>?</code> Enter" listet die verfügbaren Kommandos: ''Use one of V i R t X F S P C G''<br />
:* <code>V</code>: Zeigt die Version der Software<br />
:* <code>i</code>: Präfix für ein Intertechno-Kommando.<br />
:* <code>R</code>: Zeigt den freien Arbeitspeicher (RAM) in Bytes<br />
:* <code>t</code>: Zeigt die Dauer des Betriebs seit dem letzten Start in Sekunden (uptime).<br />
:* <code>XQ</code>: Empfänger abschalten (RX Quit)<br />
:* <code>XE</code>: Empfänger einschalten (RX Enable)<br />
:* <code>F</code>: Filter wechseln (derzeit ohne Funktion)<br />
:* <code>S</code>: Präfix für das Aussenden von Nachrichten.<br />
:* <code>P</code>: Prüft die Kommunikation (Ping). Antwortet mit "OK".<br />
:* <code>CG</code>: Abfrage der Konfiguration (Config Get) aus dem EEPROM.<br />
:* <code>CES</code>: Aktiviere Nachrichten mit Sync Puls (Config Enable Sync).<br />
:* <code>CEC</code>: Aktiviere Nachrichten mit Manchester Code (Config Enable Manchester Code).<br />
:* <code>CEU</code>: Aktiviere nicht synchronisierte Nachrichten (Config Enable Unsync).<br />
:* <code>CD[SCU]</code>: Deaktivieren den entsprechenden Nachrichtentyp (z.B. <code>CDU</code> deaktiviert asynchron).<br />
:* <code>G</code>: Veraltete Abfrage der Konfiguration, sollte mit <code>CG</code> gemacht werden.<br />
<br />
Als erstes sollte man mit dem Terminalprogramm ein großes "P" gefolgt von den Eingabetaste eingeben.<br />
Bei korrekter Verbindung sollte der SIGNALDuino mit "OK" antworten.<br />
<br />
== Foren Links ==<br />
* {{Link2Forum|Topic=58396|LinkText=SIGNALDuino Empfänger Firm- und Hardware}}<br />
* {{Link2Forum|Topic=58397|LinkText=Signalduino Entwicklung Version 3.3.1 }}<br />
* [http://www.nemcon.nl/blog2/wiring Beschreibung zu diversen Empfängern und Verbesserung der Empfangsleistung]<br />
<br />
[[Kategorie:HOWTOS]]<br />
[[Kategorie:Other Components]]<br />
[[Kategorie:Interfaces]]<br />
[[Kategorie:Arduino]]</div>MGuhttp://wiki.fhem.de/w/index.php?title=SIGNALduino_Compilieren&diff=25364SIGNALduino Compilieren2018-02-18T13:45:58Z<p>MGu: /* SIGNALDuino konfigurieren und testen */</p>
<hr />
<div>__TOC__<br />
== SIGNALduino in die Arduino Entwicklungsumgebung einbinden ==<br />
Zur Inbetriebnahme von [[SIGNALduino]] auf der Arduino IDE (getestet mit auf Arduino V1.6.7) müssen die Quelltexte von [https://github.com/RFD-FHEM/SIGNALDuino/ GitHub] (Stand Feb. 2017) geladen werden.<br />
<br />
Dort <code>Clone or download</code> und danach <code>Download ZIP</code> klicken und das ZIP-Archiv auspacken oder auf der Kommandozeile <code>git clone https://github.com/RFD-FHEM/SIGNALDuino.git</code> ausführen.<br />
<br />
Es werden folgende Dateien benötigt:<br />
* Die Datei <code>RF_Receiver.ino</code> in einen Ordner <code>RF_Receiver</code>, am besten direkt ins <code>Arduino</code> Verzeichnis der IDE kopieren.<br />
* Im <code>libraries</code> Ordner der Arduino IDE am besten einen Ordner mit Namen <code>SIGNALduino</code> anlegen, dort müssen dann die Dateien <code>bitstore</code>, <code>output</code>, <code>signalDecoder</code>, <code>SimpleFIFO</code> und <code>TimerOne</code> (jeweils <code>.cpp</code> und <code>.h</code> Datei) abgelegt werden.<br />
* Im diesem <code>SIGNALduino</code> Verzeichnis ist dann noch ein Unterverzeichnis <code>config</code> anzulegen, dort muss die Datei <code>known_16bit_timers.h</code> abgelegt werden.<br />
<br />
Struktur der SIGNALduino libraries:[[Datei:SIGNALduino-ViaArduinoEnvironment.jpg]]<br />
<br />
<br />
In Der Arduino Entwicklungsumgebung unter <code>Werkzeuge</code> → <code>Board</code> <tt>'''"Arduino Nano"'''</tt> und unter <code>Werkzeuge</code> → <code>Prozessor</code> <tt>'''"ATmega328"'''</tt> angeben. Nach Einstecken des SIGNALduinos in die USB Buchse noch den entsprechenden <code>COM-Port</code> unter <code>Werkzeuge</code> → <code>Port</code> angeben, danach sollte sich der Scetch <code>RF_Receiver.ino</code> übersetzen und auf den SIGNALduino laden lassen.<br />
<br />
== SIGNALduino mit Makefile unter Linux ==<br />
Wer lieber auf der Kommandozeile arbeitet kann SIGNALduino auch mit einem Makefile übersetzen und laden.<br />
Benötigt werden dazu:<br />
* Der Cross-Compiler und alle Werkzeuge für Arduino bzw. AVR. Bei Ubuntu und Debian Systemen:<br />
<source lang=bash><br />
# Arduino pakete installieren:<br />
sudo apt-get install arduino arduino-core arduino-mighty-1284p arduino-mk<br />
# AVR<br />
sudo apt-get install flashrom gcc-avr avrdude avr-libc binutils-avr<br />
# Die Unterstützung der Braillezeile kann zu Konflikten um den seriellen Port führen<br />
sudo apt-get remove brltty brltty-x11<br />
# Arduino-Makefile verwendet YAML und serialport in Perl<br />
sudo apt-get libdevice-serialport-perl libyaml-perl<br />
</source><br />
In den Paketen sind die Arduino Quellen und Arduino-Makefile enthalten.<br />
Bei wem das aber nicht klappt, der sollte wie hier beschrieben die neusten Versionen verwenden.<br />
<br />
* [https://github.com/RFD-FHEM/SIGNALDuino.git SIGNALDuino Quelltexte]<br />
<source lang=bash><br />
# Hier kann man natürlich jedes beliebige Verzeichnis nehmen.<br />
mkdir -p ~/src/arduino; cd ~/src/arduino<br />
# SIGNALDuino von github clonen<br />
git clone https://github.com/RFD-FHEM/SIGNALDuino.git<br />
</source><br />
<br />
* Die [https://www.arduino.cc/en/Main/Software Arduino Quellen] (optional)<br />
<source lang=bash><br />
# siehe https://www.arduino.cc/en/Main/Software für neuste Version<br />
wget https://downloads.arduino.cc/arduino-1.8.5-linux64.tar.xz<br />
tar xvJf arduino-1.8.5-linux64.tar.xz<br />
</source><br />
<br />
* Die neuste Version Arduino-Makefile (optional)<br />
<source lang=bash><br />
# Neuste Version von github clonen<br />
git clone https://github.com/sudar/Arduino-Makefile.git<br />
</source><br />
<br />
Jetzt muss in <code>SIGNALDuino/RF_Receiver</code> noch ein <code>Makefile</code> erstellt werden:<br />
<source lang=make><br />
# Verzeichnis in dem die Arduino-Quellen liegen<br />
ARDUINO_DIR=$(HOME)/src/arduino/arduino-1.8.5<br />
# Verzeichnis mit dem Arduino-Makefile<br />
ARDMK_DIR=$(HOME)/src/arduino/Arduino-Makefile<br />
# Basisverzeichnis unter dem die AVR-Werkzeuge liegen<br />
AVR_TOOLS_DIR=/usr<br />
AVRDUDE_OPTS = -v<br />
# Ab Arduino 1.5 sollte man die Architektur angeben.<br />
ARCHITECTURE = avr<br />
BOARD_TAG = nano<br />
BOARD_SUB = atmega328<br />
USER_LIB_PATH += $(realpath ../src/_micro-api/libraries)<br />
ARDUINO_LIBS += bitstore output signalDecoder SimpleFIFO TimerOne EEPROM<br />
# Device des Arduino nano<br />
MONITOR_PORT = /dev/ttyUSB0<br />
# AVRDUDE = /usr/bin/avrdude<br />
AVRDUDE_CONF = /etc/avrdude.conf<br />
include $(ARDMK_DIR)/Arduino.mk<br />
</source><br />
Wer die Arduino Quellen und Arduino-Makefile aus der Paketverwaltung verwenden möchte, kann folgendes ändern:<br />
<source lang=make><br />
ARDUINO_DIR=/usr/share/arduino<br />
ARDMK_DIR=$(ARDUINO_DIR)<br />
</source><br />
<br />
Mit stand vom 17.02.2018 müssen jetzt noch ein paar kleine Fehler beseitigt werden:<br />
Präprozessor-Direktiven werden nicht mit Semikolon abgeschlossen<br />
* in <code>RF_Receiver/RF_Receiver.ino</code><br />
:* <code>#define CMP_NEWSD</code> statt <code>#define CMP_NEWSD;</code><br />
Linux unterscheidet Groß- und Kleinschreibung bei Dateien:<br />
* in <code>src/_micro-api/libraries/output/src/output.h</code><br />
* und in <code>src/_micro-api/libraries/signalDecoder/src/signalDecoder.h</code><br />
:* <code> #include "Arduino.h"</code> statt <code> #include "arduino.h"</code><br />
Das Makefile ignoriert Bibliotheken ohne <code>library.properties</code><br />
* in <code>src/_micro-api/libraries/signalDecoder</code> fehlt <code>library.properties</code>.<br />
<source lang=bash><br />
cd src/_micro-api/libraries/signalDecoder<br />
cp ../bitstore/library.properties .<br />
sed -i 's/bitstore/signalDecoder/g' library.properties<br />
</source><br />
<br />
Danach kann SIGNALDuino für den Arduino Nano übersetzt werden:<br />
<source lang=bash><br />
cd RF_Receiver<br />
make<br />
# Auf den Arduino laden (flashen)<br />
make upload<br />
# Aufräumen mit<br />
make clean<br />
</source><br />
<br />
== SIGNALDuino konfigurieren und testen ==<br />
In der Datei <code>RF_Receiver.ino</code> sind u.a. folgende Einstellungen:<br />
* <code>BAUDRATE</code> Die Datenrate mit der SIGNALDuino mit dem PC kommuniziert (Voreinstellung 57600). Man kann also z.B. mit <code>minicom -D /dev/ttyUSB0 -8 -b 57600</code> die Kommunikation testen.<br />
* <code>PIN_LED</code> Der Pin an dem die LED zur Signalisierung von Nachrichten angeschlossen ist (Voreinstellung D13 = LED <code>L</code> auf dem Nano).<br />
* <code>PIN_RECEIVE</code> Der Pin zum Empfang von Daten (Voreinstellung D2).<br />
* <code>PIN_SEND</code> Der Pin zum Senden von Daten (Voreinstellung D11).<br />
<br />
Öffnet man ein Terminal (z.B. <code>minicom</code> siehe oben) so kann man die Kommandoschnittstelle des SIGNALDuino probieren:<br />
* Eingabe "<code>?</code> Enter" listet die verfügbaren Kommandos: ''Use one of V i R t X F S P C G''<br />
:* <code>V</code>: Zeigt die Version der Software<br />
:* <code>i</code>: Präfix für ein Intertechno-Kommando.<br />
:* <code>R</code>: Zeigt den freien Arbeitspeicher (RAM) in Bytes<br />
:* <code>t</code>: Zeigt die Dauer des Betriebs seit dem letzten Start in Sekunden (uptime).<br />
:* <code>XQ</code>: Empfänger abschalten (RX Quit)<br />
:* <code>XE</code>: Empfänger einschalten (RX Enable)<br />
:* <code>F</code>: Filter wechseln (derzeit ohne Funktion)<br />
:* <code>S</code>: Präfix für das Aussenden von Nachrichten.<br />
:* <code>P</code>: Prüft die Kommunikation (Ping). Antwortet mit "OK".<br />
:* <code>CG</code>: Abfrage der Konfiguration (Config Get) aus dem EEPROM.<br />
:* <code>CES</code>: Aktiviere Nachrichten mit Sync Puls (Config Enable Sync).<br />
:* <code>CEC</code>: Aktiviere Nachrichten mit Manchester Code (Config Enable Manchester Code).<br />
:* <code>CEU</code>: Aktiviere nicht synchronisierte Nachrichten (Config Enable Unsync).<br />
:* <code>CD[SCU]</code>: Deaktivieren den entsprechenden Nachrichtentyp (z.B. <code>CDU</code> deaktiviert asynchron).<br />
:* <code>G</code>: Veraltete Abfrage der Konfiguration, sollte mit <code>CG</code> gemacht werden.<br />
<br />
Als erstes sollte man mit dem Terminalprogramm ein großes "P" gefolgt von den Eingabetaste eingeben.<br />
Bei korrekter Verbindung sollte der SIGNALDuino mit "OK" antworten.<br />
<br />
== Foren Links ==<br />
* {{Link2Forum|Topic=58396|LinkText=SIGNALDuino Empfänger Firm- und Hardware}}<br />
* {{Link2Forum|Topic=58397|LinkText=Signalduino Entwicklung Version 3.3.1 }}<br />
* [http://www.nemcon.nl/blog2/wiring Beschreibung zu diversen Empfängern und Verbesserung der Empfangsleistung]<br />
<br />
[[Kategorie:HOWTOS]]<br />
[[Kategorie:Other Components]]<br />
[[Kategorie:Interfaces]]<br />
[[Kategorie:Arduino]]</div>MGuhttp://wiki.fhem.de/w/index.php?title=SIGNALduino_Compilieren&diff=25360SIGNALduino Compilieren2018-02-18T12:20:51Z<p>MGu: </p>
<hr />
<div>__TOC__<br />
== SIGNALduino in die Arduino Entwicklungsumgebung einbinden ==<br />
Zur Inbetriebnahme von [[SIGNALduino]] auf der Arduino IDE (getestet mit auf Arduino V1.6.7) müssen die Quelltexte von [https://github.com/RFD-FHEM/SIGNALDuino/ GitHub] (Stand Feb. 2017) geladen werden.<br />
<br />
Dort <code>Clone or download</code> und danach <code>Download ZIP</code> klicken und das ZIP-Archiv auspacken oder auf der Kommandozeile <code>git clone https://github.com/RFD-FHEM/SIGNALDuino.git</code> ausführen.<br />
<br />
Es werden folgende Dateien benötigt:<br />
* Die Datei <code>RF_Receiver.ino</code> in einen Ordner <code>RF_Receiver</code>, am besten direkt ins <code>Arduino</code> Verzeichnis der IDE kopieren.<br />
* Im <code>libraries</code> Ordner der Arduino IDE am besten einen Ordner mit Namen <code>SIGNALduino</code> anlegen, dort müssen dann die Dateien <code>bitstore</code>, <code>output</code>, <code>signalDecoder</code>, <code>SimpleFIFO</code> und <code>TimerOne</code> (jeweils <code>.cpp</code> und <code>.h</code> Datei) abgelegt werden.<br />
* Im diesem <code>SIGNALduino</code> Verzeichnis ist dann noch ein Unterverzeichnis <code>config</code> anzulegen, dort muss die Datei <code>known_16bit_timers.h</code> abgelegt werden.<br />
<br />
Struktur der SIGNALduino libraries:[[Datei:SIGNALduino-ViaArduinoEnvironment.jpg]]<br />
<br />
<br />
In Der Arduino Entwicklungsumgebung unter <code>Werkzeuge</code> → <code>Board</code> <tt>'''"Arduino Nano"'''</tt> und unter <code>Werkzeuge</code> → <code>Prozessor</code> <tt>'''"ATmega328"'''</tt> angeben. Nach Einstecken des SIGNALduinos in die USB Buchse noch den entsprechenden <code>COM-Port</code> unter <code>Werkzeuge</code> → <code>Port</code> angeben, danach sollte sich der Scetch <code>RF_Receiver.ino</code> übersetzen und auf den SIGNALduino laden lassen.<br />
<br />
== SIGNALduino mit Makefile unter Linux ==<br />
Wer lieber auf der Kommandozeile arbeitet kann SIGNALduino auch mit einem Makefile übersetzen und laden.<br />
Benötigt werden dazu:<br />
* Der Cross-Compiler und alle Werkzeuge für Arduino bzw. AVR. Bei Ubuntu und Debian Systemen:<br />
<source lang=bash><br />
# Arduino pakete installieren:<br />
sudo apt-get install arduino arduino-core arduino-mighty-1284p arduino-mk<br />
# AVR<br />
sudo apt-get install flashrom gcc-avr avrdude avr-libc binutils-avr<br />
# Die Unterstützung der Braillezeile kann zu Konflikten um den seriellen Port führen<br />
sudo apt-get remove brltty brltty-x11<br />
# Arduino-Makefile verwendet YAML und serialport in Perl<br />
sudo apt-get libdevice-serialport-perl libyaml-perl<br />
</source><br />
In den Paketen sind die Arduino Quellen und Arduino-Makefile enthalten.<br />
Bei wem das aber nicht klappt, der sollte wie hier beschrieben die neusten Versionen verwenden.<br />
<br />
* [https://github.com/RFD-FHEM/SIGNALDuino.git SIGNALDuino Quelltexte]<br />
<source lang=bash><br />
# Hier kann man natürlich jedes beliebige Verzeichnis nehmen.<br />
mkdir -p ~/src/arduino; cd ~/src/arduino<br />
# SIGNALDuino von github clonen<br />
git clone https://github.com/RFD-FHEM/SIGNALDuino.git<br />
</source><br />
<br />
* Die [https://www.arduino.cc/en/Main/Software Arduino Quellen] (optional)<br />
<source lang=bash><br />
# siehe https://www.arduino.cc/en/Main/Software für neuste Version<br />
wget https://downloads.arduino.cc/arduino-1.8.5-linux64.tar.xz<br />
tar xvJf arduino-1.8.5-linux64.tar.xz<br />
</source><br />
<br />
* Die neuste Version Arduino-Makefile (optional)<br />
<source lang=bash><br />
# Neuste Version von github clonen<br />
git clone https://github.com/sudar/Arduino-Makefile.git<br />
</source><br />
<br />
Jetzt muss in <code>SIGNALDuino/RF_Receiver</code> noch ein <code>Makefile</code> erstellt werden:<br />
<source lang=make><br />
# Verzeichnis in dem die Arduino-Quellen liegen<br />
ARDUINO_DIR=$(HOME)/src/arduino/arduino-1.8.5<br />
# Verzeichnis mit dem Arduino-Makefile<br />
ARDMK_DIR=$(HOME)/src/arduino/Arduino-Makefile<br />
# Basisverzeichnis unter dem die AVR-Werkzeuge liegen<br />
AVR_TOOLS_DIR=/usr<br />
AVRDUDE_OPTS = -v<br />
# Ab Arduino 1.5 sollte man die Architektur angeben.<br />
ARCHITECTURE = avr<br />
BOARD_TAG = nano<br />
BOARD_SUB = atmega328<br />
USER_LIB_PATH += $(realpath ../src/_micro-api/libraries)<br />
ARDUINO_LIBS += bitstore output signalDecoder SimpleFIFO TimerOne EEPROM<br />
# Device des Arduino nano<br />
MONITOR_PORT = /dev/ttyUSB0<br />
# AVRDUDE = /usr/bin/avrdude<br />
AVRDUDE_CONF = /etc/avrdude.conf<br />
include $(ARDMK_DIR)/Arduino.mk<br />
</source><br />
Wer die Arduino Quellen und Arduino-Makefile aus der Paketverwaltung verwenden möchte, kann folgendes ändern:<br />
<source lang=make><br />
ARDUINO_DIR=/usr/share/arduino<br />
ARDMK_DIR=$(ARDUINO_DIR)<br />
</source><br />
<br />
Mit stand vom 17.02.2018 müssen jetzt noch ein paar kleine Fehler beseitigt werden:<br />
Präprozessor-Direktiven werden nicht mit Semikolon abgeschlossen<br />
* in <code>RF_Receiver/RF_Receiver.ino</code><br />
:* <code>#define CMP_NEWSD</code> statt <code>#define CMP_NEWSD;</code><br />
Linux unterscheidet Groß- und Kleinschreibung bei Dateien:<br />
* in <code>src/_micro-api/libraries/output/src/output.h</code><br />
* und in <code>src/_micro-api/libraries/signalDecoder/src/signalDecoder.h</code><br />
:* <code> #include "Arduino.h"</code> statt <code> #include "arduino.h"</code><br />
Das Makefile ignoriert Bibliotheken ohne <code>library.properties</code><br />
* in <code>src/_micro-api/libraries/signalDecoder</code> fehlt <code>library.properties</code>.<br />
<source lang=bash><br />
cd src/_micro-api/libraries/signalDecoder<br />
cp ../bitstore/library.properties .<br />
sed -i 's/bitstore/signalDecoder/g' library.properties<br />
</source><br />
<br />
Danach kann SIGNALDuino für den Arduino Nano übersetzt werden:<br />
<source lang=bash><br />
cd RF_Receiver<br />
make<br />
# Auf den Arduino laden (flashen)<br />
make upload<br />
# Aufräumen mit<br />
make clean<br />
</source><br />
<br />
== SIGNALDuino konfigurieren und testen ==<br />
In der Datei <code>RF_Receiver.ino</code> sind u.a. folgende Einstellungen:<br />
* <code>BAUDRATE</code> Die Datenrate mit der SIGNALDuino mit dem PC kommuniziert (Voreinstellung 57600). Man kann also z.B. mit <code>minicom -D /dev/ttyUSB0 -8 -b 57600</code> die Kommunikation testen.<br />
* <code>PIN_LED</code> Der Pin an dem die LED zur Signalisierung von Nachrichten angeschlossen ist (Voreinstellung D13 = LED <code>L</code> auf dem Nano).<br />
* <code>PIN_RECEIVE</code> Der Pin zum Empfang von Daten (Voreinstellung D2).<br />
* <code>PIN_SEND</code> Der Pin zum Senden von Daten (Voreinstellung D11).<br />
<br />
Öffnet man ein Terminal (z.B. <code>minicom</code> siehe oben) so kann man die Kommandoschnittstelle des SIGNALDuino probieren:<br />
* Eingabe <code>?</code> Enter listet die verfügbaren Kommandos: ''Use one of V i R t X F S P C G''<br />
<br />
== Foren Links ==<br />
* {{Link2Forum|Topic=58396|LinkText=SIGNALDuino Empfänger Firm- und Hardware}}<br />
* {{Link2Forum|Topic=58397|LinkText=Signalduino Entwicklung Version 3.3.1 }}<br />
* [http://www.nemcon.nl/blog2/wiring Beschreibung zu diversen Empfängern und Verbesserung der Empfangsleistung]<br />
<br />
[[Kategorie:HOWTOS]]<br />
[[Kategorie:Other Components]]<br />
[[Kategorie:Interfaces]]<br />
[[Kategorie:Arduino]]</div>MGuhttp://wiki.fhem.de/w/index.php?title=SIGNALduino_Compilieren&diff=25355SIGNALduino Compilieren2018-02-17T16:58:03Z<p>MGu: </p>
<hr />
<div>__TOC__<br />
== SIGNALduino in die Arduino Entwicklungsumgebung einbinden ==<br />
Zur Inbetriebnahme von [[SIGNALduino]] auf der Arduino IDE (getestet mit auf Arduino V1.6.7) müssen die Quelltexte von [https://github.com/RFD-FHEM/SIGNALDuino/ GitHub] (Stand Feb. 2017) geladen werden.<br />
<br />
Dort <code>Clone or download</code> und danach <code>Download ZIP</code> klicken und das ZIP-Archiv auspacken oder auf der Kommandozeile <code>git clone https://github.com/RFD-FHEM/SIGNALDuino.git</code> ausführen.<br />
<br />
Es werden folgende Dateien benötigt:<br />
* Die Datei <code>RF_Receiver.ino</code> in einen Ordner <code>RF_Receiver</code>, am besten direkt ins <code>Arduino</code> Verzeichnis der IDE kopieren.<br />
* Im <code>libraries</code> Ordner der Arduino IDE am besten einen Ordner mit Namen <code>SIGNALduino</code> anlegen, dort müssen dann die Dateien <code>bitstore</code>, <code>output</code>, <code>signalDecoder</code>, <code>SimpleFIFO</code> und <code>TimerOne</code> (jeweils <code>.cpp</code> und <code>.h</code> Datei) abgelegt werden.<br />
* Im diesem <code>SIGNALduino</code> Verzeichnis ist dann noch ein Unterverzeichnis <code>config</code> anzulegen, dort muss die Datei <code>known_16bit_timers.h</code> abgelegt werden.<br />
<br />
Struktur der SIGNALduino libraries:[[Datei:SIGNALduino-ViaArduinoEnvironment.jpg]]<br />
<br />
<br />
In Der Arduino Entwicklungsumgebung unter <code>Werkzeuge</code> → <code>Board</code> <tt>'''"Arduino Nano"'''</tt> und unter <code>Werkzeuge</code> → <code>Prozessor</code> <tt>'''"ATmega328"'''</tt> angeben. Nach Einstecken des SIGNALduinos in die USB Buchse noch den entsprechenden <code>COM-Port</code> unter <code>Werkzeuge</code> → <code>Port</code> angeben, danach sollte sich der Scetch <code>RF_Receiver.ino</code> übersetzen und auf den SIGNALduino laden lassen.<br />
<br />
== SIGNALduino mit Makefile unter Linux ==<br />
Wer lieber auf der Kommandozeile arbeitet kann SIGNALduino auch mit einem Makefile übersetzen und laden.<br />
Benötigt werden dazu:<br />
* Der Cross-Compiler und alle Werkzeuge für Arduino bzw. AVR. Bei Ubuntu und Debian Systemen:<br />
<source lang=bash><br />
# Arduino pakete installieren:<br />
sudo apt-get install arduino arduino-core arduino-mighty-1284p arduino-mk<br />
# AVR<br />
sudo apt-get install flashrom gcc-avr avrdude avr-libc binutils-avr<br />
# Die Unterstützung der Braillezeile kann zu Konflikten um den seriellen Port führen<br />
sudo apt-get remove brltty brltty-x11<br />
# Arduino-Makefile verwendet YAML und serialport in Perl<br />
sudo apt-get libdevice-serialport-perl libyaml-perl<br />
</source><br />
In den Paketen sind die Arduino Quellen und Arduino-Makefile enthalten.<br />
Bei wem das aber nicht klappt, der sollte wie hier beschrieben die neusten Versionen verwenden.<br />
<br />
* [https://github.com/RFD-FHEM/SIGNALDuino.git SIGNALDuino Quelltexte]<br />
<source lang=bash><br />
# Hier kann man natürlich jedes beliebige Verzeichnis nehmen.<br />
mkdir -p ~/src/arduino; cd ~/src/arduino<br />
# SIGNALDuino von github clonen<br />
git clone https://github.com/RFD-FHEM/SIGNALDuino.git<br />
</source><br />
<br />
* Die [https://www.arduino.cc/en/Main/Software Arduino Quellen] (optional)<br />
<source lang=bash><br />
# siehe https://www.arduino.cc/en/Main/Software für neuste Version<br />
wget https://downloads.arduino.cc/arduino-1.8.5-linux64.tar.xz<br />
tar xvJf arduino-1.8.5-linux64.tar.xz<br />
</source><br />
<br />
* Die neuste Version Arduino-Makefile (optional)<br />
<source lang=bash><br />
# Neuste Version von github clonen<br />
git clone https://github.com/sudar/Arduino-Makefile.git<br />
</source><br />
<br />
Jetzt muss in <code>SIGNALDuino/RF_Receiver</code> noch ein <code>Makefile</code> erstellt werden:<br />
<source lang=make><br />
# Verzeichnis in dem die Arduino-Quellen liegen<br />
ARDUINO_DIR=$(HOME)/src/arduino/arduino-1.8.5<br />
# Verzeichnis mit dem Arduino-Makefile<br />
ARDMK_DIR=$(HOME)/src/arduino/Arduino-Makefile<br />
# Basisverzeichnis unter dem die AVR-Werkzeuge liegen<br />
AVR_TOOLS_DIR=/usr<br />
AVRDUDE_OPTS = -v<br />
# Ab Arduino 1.5 sollte man die Architektur angeben.<br />
ARCHITECTURE = avr<br />
BOARD_TAG = nano<br />
BOARD_SUB = atmega328<br />
USER_LIB_PATH += $(realpath ../src/_micro-api/libraries)<br />
ARDUINO_LIBS += bitstore output signalDecoder SimpleFIFO TimerOne EEPROM<br />
# Device des Arduino nano<br />
MONITOR_PORT = /dev/ttyUSB0<br />
# AVRDUDE = /usr/bin/avrdude<br />
AVRDUDE_CONF = /etc/avrdude.conf<br />
include $(ARDMK_DIR)/Arduino.mk<br />
</source><br />
Wer die Arduino Quellen und Arduino-Makefile aus der Paketverwaltung verwenden möchte, kann folgendes ändern:<br />
<source lang=make><br />
ARDUINO_DIR=/usr/share/arduino<br />
ARDMK_DIR=$(ARDUINO_DIR)<br />
</source><br />
<br />
Mit stand vom 17.02.2018 müssen jetzt noch ein paar kleine Fehler beseitigt werden:<br />
Präprozessor-Direktiven werden nicht mit Semikolon abgeschlossen<br />
* in <code>RF_Receiver/RF_Receiver.ino</code><br />
:* <code>#define CMP_NEWSD</code> statt <code>#define CMP_NEWSD;</code><br />
Linux unterscheidet Groß- und Kleinschreibung bei Dateien:<br />
* in <code>src/_micro-api/libraries/output/src/output.h</code><br />
* und in <code>src/_micro-api/libraries/signalDecoder/src/signalDecoder.h</code><br />
:* <code> #include "Arduino.h"</code> statt <code> #include "arduino.h"</code><br />
Das Makefile ignoriert Bibliotheken ohne <code>library.properties</code><br />
* in <code>src/_micro-api/libraries/signalDecoder</code> fehlt <code>library.properties</code>.<br />
<source lang=bash><br />
cd src/_micro-api/libraries/signalDecoder<br />
cp ../bitstore/library.properties .<br />
sed -i 's/bitstore/signalDecoder/g' library.properties<br />
</source><br />
<br />
Danach kann SIGNALDuino für den Arduino Nano übersetzt werden:<br />
<source lang=bash><br />
cd RF_Receiver<br />
make<br />
# Auf den Arduino laden (flashen)<br />
make upload<br />
# Aufräumen mit<br />
make clean<br />
</source><br />
<br />
== Foren Links ==<br />
* {{Link2Forum|Topic=58396|LinkText=SIGNALDuino Empfänger Firm- und Hardware}}<br />
* {{Link2Forum|Topic=58397|LinkText=Signalduino Entwicklung Version 3.3.1 }}<br />
* [http://www.nemcon.nl/blog2/wiring Beschreibung zu diversen Empfängern und Verbesserung der Empfangsleistung]<br />
<br />
[[Kategorie:HOWTOS]]<br />
[[Kategorie:Other Components]]<br />
[[Kategorie:Interfaces]]<br />
[[Kategorie:Arduino]]</div>MGuhttp://wiki.fhem.de/w/index.php?title=SIGNALduino&diff=25354SIGNALduino2018-02-17T15:35:24Z<p>MGu: Link an umbenannten Artikel angepasst.</p>
<hr />
<div>{{Infobox Modul<br />
|ModPurpose=Empfang und Verarbeitung von digitalen Signalen<br />
|ModType=d<br />
|ModFTopic=38402<br />
|ModCmdRef=SIGNALduino<br />
|ModForumArea=Sonstige Systeme<br />
|ModTechName=00_SIGNALduino.pm<br />
|ModOwner=Sidey ({{Link2FU|8018|Forum}}/[[Benutzer Diskussion:Sidey|Wiki]])<br />
}}<br />
<br />
== Einleitung ==<br />
=== Übersicht ===<br />
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.<br />
<br />
Der SIGNALduino(-Stick) erkennt Signale anhand von Mustern und gibt sie (als maximal detaillierte Beschreibung einer Signalabfolge) dann schlicht sofort nur noch an FHEM zur Auswertung (Dekodierung) weiter. Auch nicht erkannte Signale werden an FHEM übergeben.<br />
Aufgabe des SIGNALduino (Firmware/Stick) ist es also nur, Signal-Aktivitäten zu erfassen und maximal präzise (als kurzer Text-String) zu beschreiben.<br />
Alles weitere (echte, finale Auswertung / Zuweisung dieser Signal-Daten) wird dann auf einer großen Box (Raspberry o.ä.) gemacht.<br />
<br />
=== Vorteil gegenüber einem CUL/FHEMduino ===<br />
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 (also auf flexibel direkt updatebarer Rechner-Seite!!). Änderungen am Arduino-Firmware-Code sind normalerweise nicht notwendig (sofern die grundsätzliche Signal-Klassifizierung des Sticks korrekt funktioniert - leider nicht immer, z.B.: [https://github.com/RFD-FHEM/SIGNALDuino/issues/65 MU-Nachrichten werden z.T. als MC erkannt]).<br />
<br />
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.<br />
<br />
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.<br />
<br />
== Hardware ==<br />
<br />
Der SIGNALduino (Hardware) wird über den USB Port angeschlossen, er kann aber auch mit zusätzlichen ESP Modulen über ein WLAN angebunden werden. <br />
<br />
Der SIGNALduino basiert auf einem [http://arduino.cc/de/Main/ArduinoBoardNano Arduino Nano], die Schaltung entspricht der des [[FHEMduino]] oder dem [[Selbstbau_CUL]]:<br />
* Entweder wird ein Arduino mit einfachen Sende- und Empfangsmodulen verwendet, dann ist die Verkabelung identisch zum [[FHEMduino]] <br />
* Oder es wird ein CC1101 Transceiver verwendet, dann ist die Verkabelung identisch zum [[Selbstbau_CUL]].<br />
* Zuletzt gibt es ein fertig konfektioniertes Modul von In-Circuit mit Radino CC1101 Varianten, link zum [http://shop.in-circuit.de/index.php Hersteller]. <br />
<br />
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. <br />
<br />
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. Die SW ist auf [https://github.com/RFD-FHEM/SIGNALDuino github]. Vorgesehen ist nur die Übersetzung unter Windows mit Visual Studio und dem Visual Micro Zusatz. Es gibt aber auch eine Anleitung, wie man mit der [[Arduino]] IDE oder einem Makefile [[SIGNALduino Compilieren]] kann.<br />
<br />
Es gibt auch eine Variante des SIGNALduino, die auf einem [[ESP8266]] nativ läuft, diese funktioniert seit Anfang 2018 annehmbar, allerdings befindet diese sich noch in einer Entwicklungsphase.<br />
<br />
An den "SIGNALESP" kann auch ein CC1101 via SPI angebunden werden:<br />
<br />
{||<br />
!CC1101 Bezeichnung<br />
!ESP Pin<br />
|-<br />
|CLK||GPIO14<br />
|-<br />
|MOSI||GPIO13<br />
|-<br />
|MISO||GPIO12<br />
|-<br />
|CSN||GPIO15<br />
|-<br />
|GDO0||GPIO4<br />
|-<br />
|GDO2||GPIO5<br />
|}<br />
<br />
<br />
Wird ein einfacher Empfänger / Sender Kombination verwendet, dann über die PINs:<br />
<br />
{||<br />
! Bezeichnung <br />
! ESP Pin<br />
|-<br />
|Transmitter||GPIO4<br />
|-<br />
|Receiver||GPIO5<br />
|}<br />
<br />
=== Einfache Module ===<br />
<br />
[[Datei:Fhemduino_schematic.png|200px|thumb|right|Beispielschaltplan SIGNAL(FHEM)duino]] <br />
<br />
Mit einem Arduino-Nano und folgenden, billigen Sende- und Empfangsmodulen können Sie einen SIGNALduino bauen:<br />
* FS1000A Dies ist das Sendemodul (TX) und wird oft im Set mit dem billigen XY-MK-5V-Empfänger angeboten (etwa 5€). <br />
* RXB6 Das ist das empfohlene Empfangsmodul (RX), statt XY-MK-5V, etwa 5€ aus Deutschland.<br />
<br />
Die Verkabelung erfolgt analog zum [[FHEMduino]] und das bedeutet (Arduino -> Modul):<br />
* PIN D2 an DATA des RX-Moduls<br />
* PIN D11 an DATA des TX-Moduls (PIN links mit Beschriftung ATAD)<br />
<br />
Zusätzlich muss noch jeweils GND und 5V des Arduino mit dem GND bzw. VCC des Moduls verbunden werden.<br />
<br />
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).<br />
<br />
== Software: Modul ==<br />
<br />
=== USB-ID ermitteln ===<br />
Bevor der SIGNALduino mit dem FHEM Server (im Beispiel hier ein Raspberry PI) verbunden werden kann, muss die USB-Schnittstelle ermittelt werden. Hierzu bitte auf dem Terminal den Befehl<br />
<pre> ls -l /dev/serial/by-id </pre><br />
ausführen. Beispielhaft sieht das Ergebnis etwa so aus: <br />
''lrwxrwxrwx 1 root root 13 Jan 31 00:02 '''usb-FTDI_FT232R_USB_UART_A903N5T5-if00-port''' -> ../../ttyUSB0'' <br />
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.<br />
<br />
=== FHEM-Modul laden ===<br />
Die SIGNALduino Module werden über das FHEM [[update]] verteilt, sobald die Änderungen einen "stabilen" und alltags tauglichen Zustand haben.<br />
<br />
Die in der Entwicklung befindliche Version kann mit folgenden Befehlen geladen werden:<br />
<br />
* FHEM aktualisieren: <code>update</code> <br />
* 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<br />
*Danach kann das Gerät wie folgt definiert werden (die Spezifikation des USB-Anschlusses muss dabei an die aktuellen Gegebenheiten angepasst werden):<br />
:<code>define <eigener-SIGNALduino-Name> SIGNALduino /dev/serial/by-id/usb-FTDI_FT232R_USB_UART_A903N5T5-if00-port0@57600</code><br />
Nach dem Einbinden wird der SIGNALduino, falls er erkannt wird, im Status "Opened" angezeigt. <br />
<br />
Für neuere Entwicklungen kann in FHEM auch dauerhaft die developer Version aktualisiert werden:<br />
<code>update add <nowiki>https://raw.githubusercontent.com/RFD-FHEM/RFFHEM/dev-r33/controls_signalduino.txt</nowiki></code> <br />
Danach wird FHEM bei dem normalen Update-Befehl immer automatisch die aktuelle dev Version laden.<br />
<br />
Die nachfolgenden Beispiel-Befehle verwenden "sduino" als <eigener-SIGNALduino-Name>.<br />
<br />
==== Flashen des Arduino mit der SIGNALduino Firmware ====<br />
Falls avrdude noch nicht vorhanden ist, kann es mit folgendem Befehl installiert werden:<br />
:<code>sudo apt-get install avrdude</code><br />
<br />
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<br />
<code>attr sduino hardware nanoCC1101</code><br />
sonst üblicherweise<br />
<code>attr sduino hardware nano328</code><br />
<br />
Anschließend kann der ''flash'' Befehl abgesetzt werden: <br />
<code>set sduino flash </code><br />
Dadurch wird der Arduino mit der gewählten Firmware geflasht. Das Ergebnis wird im Webinterface direkt angezeigt.<br />
<br />
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:<br />
:<code>set sduino flash FHEM/firmware/SIGNALduino_mega2560.hex</code><br />
(je nachdem wo und unter welchem Namen die .hex Datei abgelegt wurde)<br />
<br />
==== Flashen einer Firmware über HTTP ====<br />
Die Firmware wird in absehbarer Zeit nicht mehr über den Update Mechanismus verteilt werden. <br />
Damit die passende Firmware auf den SIGNALduiono geladen werden kann, wird diese dann über HTTP geladen.<br />
<br />
==== Vorabversion einer Firmware ====<br />
Die Firmware des SIGNALduino wird ebenso wie das FHEM Modul auch weiter entwickelt.<br />
Die Entwickler sind auf Tests und Rückmeldungen der Nutzer angewiesen, da leider nicht alle Sensoren vorher getestet werden können.<br />
<br />
Aktuell (Anfang 2018) ist noch die Version 3.3.1 in Entwicklung. Diese steht aktuell in einer Release Candidate Version zur Verfügung.<br />
<br />
Für die Folgenden Microcontroller kann man die Firmware downloaden.<br />
<br />
SIGNALDuino_nanoCC1101-331rc2.hex für einen Nano mit CC1101<br />
<code>set sduino flash https://drive.google.com/uc?export=download&id=1sIac8-Qhts4c7OEkFH72Lv6hhgbOadFQ<br />
</code><br />
<br />
SIGNALDuino_nano_331rc2.hex für einen Nano ohne cc1101<br />
<code>set sduino flash https://drive.google.com/uc?export=download&id=1FnnIjJhBI1mjxZKzMnNtnnYzHChyn0lk<br />
</code><br />
<br />
SIGNALDuino_promini_331rc2.hex für einen promini ohne cc1101<br />
<code>set sduino flash https://drive.google.com/uc?export=download&id=1-AJKmO2DjQPi9_O3XI6KqvE9oYLHOyl8<br />
</code><br />
<br />
<br />
SIGNALESP_331rc2.bin (mit cc1101) für einen ESP8266<br />
<code>set ipduino flash https://drive.google.com/uc?export=download&id=1V8ZfLnRnskc64XZkfL-qwmI7AsSd6KRG<br />
</code><br />
!Achtung, aktuell wird die Firmware für den ESP dadurch nur herunter geladen. Flashen müsst ihr leider immer noch über ein passendes Tool <br />
z.B. "ESP8266Flasher.exe" oder Esptool und einer seriellen Konsole.<br />
<br />
Nach dem Booten des ESPs, spannt dieser ein eigenes WLAN auf. Habt ihr euch damit verbunden, könnt ihr den ESP mit eurem vorhandenen WLAN verbinden.<br />
<br />
==== Flashen eines radino Boards mit ATmega32U4 ====<br />
<br />
Diese Funktion steht nur in der Entwicklungsversion dev-r33 zur Verfügung:<br />
Das Radino Board muss derzeit noch mit Angabe des Dateinamens geflasht werden:<br />
<code>set sduino flash FHEM/firmware/SIGNALDuino_radinoCC1101.hex</code><br />
<br />
Auch sind Berichte bekannt, dass der Radino beim Neustart von FHEM nicht korrekt initialisiert wird.<br />
<br />
=== Geräteerkennung ===<br />
==== Unterstützte Geräte ====<br />
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.<br />
{|class="wikitable"<br />
! style="text-align:left;"| Produkt <br />
! (E)mpfangen<br />(S)enden <br />
! Hinweise <br />
! Verwendetes Modul <br />
! Protokoll ID<br />
|-<br />
|TCM Wetterstation (97001 und 21xxx Serie)||E|| || CUL_TCM97001 || 0<br />
|-<br />
|ABS Wetterstation (ABS 700)||E|| || CUL_TCM97001 || 0<br />
|-<br />
|Prologue Wetterstation ||E|| ||CUL_TCM97001 || 0<br />
|-<br />
|Rubicson Wetterstation ||E|| ||CUL_TCM97001 ||0 <br />
|-<br />
|NC_WS Wetterstation ||E|| ||CUL_TCM97001 || 0<br />
|-<br />
|[http://www.gt-support.de/ GT-WT-02 Wetterstation]||E|| ||CUL_TCM97001 || 0<br />
|-<br />
|AURIOL Wetterstation ||E|| ||CUL_TCM97001 || 0<br />
|-<br />
|Mebus Wetterstation ||E|| ||CUL_TCM97001 || 0<br />
|-<br />
|Intertechno Funkschalter||E S|| ||IT || 3,4,5,17<br />
|-<br />
|<strike>Conrad RSL Funkschalter</strike>||E S|| Funktioniert aktuell nicht || SIGNALduino_RSL || <br />
|-<br />
|[http://global.oregonscientific.com/product_view.php?id=5 Oregon Scientific Wettersensoren]||E || Protokoll V2 & V3 implementiert || OREGON || 10<br />
|-<br />
|Bresser Temp/Hydro Sensor||E || || Hideki || 12<br />
|-<br />
|[https://de.hama.com/00104985/hama-aussensensor-ts33c-fuer-wetterstation Hama TS33C]||E || || Hideki || 12<br />
|-<br />
|TFA Temp/Hydro Sensor||E || || Hideki || 12<br />
|-<br />
|Lacrosse TX2/TX3 Sensoren||E || || CUL_TX || 8<br />
|-<br />
|TFA 30320902||E || || SD_WS07 || 7<br />
|-<br />
|Eurochron eas800z||E || || SD_WS07 || 7<br />
|-<br />
|Technoline WS6750/TX70DTH||E || || SD_WS07 || 7<br />
|-<br />
|FreeTec Außenmodul NC-7344||E || || SD_WS07 || 7<br />
|-<br />
|CTW600||E || || SD_WS09 || 9<br />
|-<br />
|WH1080||E || || SD_WS09 || 9<br />
|-<br />
|Visivon remote pt4450||E || || none || 24<br />
|-<br />
|Einhell HS 434/6||E || || none || 21<br />
|-<br />
|Flamingo FA20RF / FA21RF Rauchmelder||E || || none || 13<br />
|-<br />
|mumbi m-FS300||E || || none || 26,27<br />
|-<br />
|TFA 30.3200||E || || none || 33<br />
|-<br />
|Livolo||E|| || none || 20<br />
|-<br />
|Smartwares SH5-TSO-A||E S|| || IT || ?<br />
|-<br />
|X10 Security Devices||E|| || || 39<br />
|-<br />
|[[Somfy_via_SIGNALduino|Somfy RTS]]||E S|| || SOMFY || 43<br />
|}<br />
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 <br />
:<code>attr <Funksteckdose> ITclock 300</code> <br />
gesetzt werden, der Standardwert ist 250.<br />
<br />
==== Mein Gerät wird in FHEM nicht erkannt ====<br />
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:<br />
<br />
2. Eröffnet ein Thema unter [https://github.com/RFD-FHEM/RFFHEM/issues github] nach folgendem Muster:<br />
:''Thema : Protokoll für <Das verwendete Gerät><br />
:Inhalt: Eure Hardware z.B. Arduino Nano mit XYZ Empfänger, oder Arduino Nano direkt an Gerät x<br />
<br />
3. Auszug aus dem Logfile, welches zum Gerät gehört.<br />
:''Alles was ihr sonst noch über das Gerät und die übertragenen Daten wisst.<br />
<br />
Alternativ könnt ihr auch im Forum posten. Um einzelne Erweiterungen besser im Überblick zu behalten, eignet sich das github jedoch besser.<br />
<br />
==== Es wird ein Protokoll erkannt, Autocreate legt aber kein device an ====<br />
Im SIGNALduino sind >30 Protokolle implementiert. Jedoch gibt es nur wenige Module, welche diese Protokolle verarbeiten.<br />
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.<br />
<br />
Nehmen wir an, wir haben einen Schalter. Dieser kann einen oder zwei Zustände senden.<br />
Im FHEM Log tauchen Meldungen ähnlich dieser auf<br />
<br />
<code><br />
2015.11.15 15:52:23 4: SIGNALduino_unknown incomming msg: u85#FF8081<br />
</code><br />
<br />
Wir können mit Hilfe des Modules DOIF auf diese Nachricht eine Aktion ausführen:<br />
<br />
Entweder, wenn wir den Inhalt der Nachricht nur zu teilen wissen, da er sich ändert:<br />
<code><br />
define mydoif DOIF ([sduino:&DMSG] =~ "u85#FF8081") (set Lamp on)<br />
attr mydoif do always<br />
</code><br />
<br />
Oder, wenn wir den Inhalt exakt kennen, dann auch als Vergleichsstring<br />
<code><br />
define mydoif DOIF ([sduino:&DMSG] eq "u85#FF8081") (set relais on)<br />
attr mydoif do always<br />
</code><br />
<br />
Der Teil u85#FF8081 muss individuell angepasst werden, der Name eures SIGNALduino möglicherweise auch.<br />
<br />
=== Das Logfile ===<br />
Im Logfile ab [[Verbose]] 4 tauchen diverse Meldungen auf, deren Bedeutung kurz erläutert wird (verbose 3 unterdrückt diese Meldungen).<br />
<br />
Die Protokolle (von der SIGNALDuino-Firmware gesendete Signal-Beschreibungs-Strings) können wie folgt unterschieden werden:<br />
<br />
*MS - Nachricht mit Sync Puls: Hierzu ein Beispiel<br />
:<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 "1" also P1 mit 395 Mikrosekunden high (die Zeitdauer ergibt sich aufgrund der Mitteilung "P1=395") und anschließend ein Signal "5" also P5 mit 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.<br />
<br />
*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.<br />
:<code>MC;LL=-1066;LH=904;SL=-562;SH=385;D=332B4B4D54D5554B552CD2D554B2B5354A;C=429;</code><br />
<br />
*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.<br />
:<code>MU;P0=1372;P1=-580;P2=362;P3=-1047;D=01212321212321212121212121212123212123212321232121212121212321;CP=2;</code><br />
<br />
Es erscheinen viele Meldungen dieser Art:<br />
<br />
<pre><br />
Fingerprint for MU Protocol id xxxx -> yyy matches, trying to demodulate<br />
sduino: Starting demodulation at Position 1<br />
Fingerprint for MU Protocol id 28 -> IC Ledspot matches, trying to demodulate<br />
sduino: Starting demodulation at Position 1<br />
Fingerprint for MU Protocol id 29 -> HT12e remote matches, trying to demodulate<br />
</pre><br />
<br />
Dies sind nun Bemühungen, anhand der von der SIGNALDuino-Firmware gelieferten rohen aber detaillierten Signal-Strings eine Vor-Analyse / Fingerprinting vorzunehmen.<br />
Man könnte nun z.B. bei solchen Fingerprinting-Analysen erkennen:<br />
* dass der Basis-Takt-Wert innerhalb eines charakteristischen Zeit-Bereichs liegt<br />
* dass die Anzahl der Sync-Pulse eine präzise Zahl ist<br />
* dass Längen erkannter Puls-Typen innerhalb eines Bereichs liegen<br />
<br />
Mittels solcher Untersuchungen kann man also final hoffentlich hinreichend plausibel feststellen, "dass diese Aktivitäten offensichtlich(?) zu einer Funk-Komponente Rauchmelder von Hersteller XYZ gehören müssen, und man somit weiterleiten muss an ein (möglicherweise bereits existierendes) Userdaten-Dekodier-Modul für diese Herstellerkomponente".<br />
<br />
<br />
Bei einer dann erfolgenden Demodulation des noch rohen SIGNALDuino-Strings könnte man z.B. (hoffentlich richtigerweise) annehmen, dass eine Signalpegel-Typ-Folge "13" eine binäre 1 bedeuten soll, während eine Folge "12" eine binäre 0 bedeuten soll. Man erhält aus dem Gesamt-Puls-String also nach vollständiger Demodulation eine Abfolge von vielen 0/1 Bits, die insgesamt ein Datenwort darstellen, mit einer gewissen Länge von NN bits (diese Längen-Angabe könnte übrigens - neben Namenssuche nach Hersteller oder Produkt etc. - ein wichtiges Such-Merkmal sein, ob andere Frameworks tatsächlich bereits wissen, wie Daten dieser Funk-Komponente zu dekodieren sind!). Dieses demodulierte Datenwort ist nun das finale Datenwort, welches einen Container für die Funk-Komponenten-Informationen darstellt (in diesem Container also beispielsweise enthalten: Temperatur, Feuchte, Akku-Status, ID, Alarm, ... - zumindest wenn nicht dummerweise der ganze Container erst einmal CRC- oder Crypto-verschlüsselt ist...).<br />
<br />
Man muss an dieser Stelle unbedingt sagen, dass dieses Userdaten-Datenwort (einer bestimmten Hersteller-Funk-Komponente!) natürlich bei ''jeglichen'' Transceiver-Systemen ''immer'' gleich erkannt werden ''muss'' - an dieser Stelle ist also ganz klar, dass diese Daten an ''allgemeine'' FHEM-Module weitergeleitet (Dispatched) werden müssen, die nach Übernahme von Daten von ''jeglichen'' Transceiver-Systemen diese Daten immer auf die gleiche Weise ('''''generisch/zentral''''') für die jeweilige Hersteller-Funk-Komponente erledigen.<br />
<br />
Die Abfolge ist also ganz klar:<br />
Funk-Aktivität --> Transceiver-Gerät/Firmware (SIGNALDuino) --> maximal detailreich beschreibender Rx-Analyse-Output-String --> Fingerprinting-Grobzuordnung des (SIGNALDuino-Firmware-)Outputs (durch 00_SIGNALduino.pm) auf gerätespezifisches Verhalten --> generische/zentrale Dekodierung des gerätespezifischen Protokoll-Datenworts, in zentralen Grundsatz-Modulen wie z.B. <code>14_SD_WS.pm</code>).<br />
<br />
Und wenn dann bei einer solchen Schritte-Abfolge irgendetwas noch fehlen/unpassend sein sollte, dann muss eben entsprechendes Development an gewissen Stellen erfolgen ;-)<br />
<br />
====Minimieren (whitelist/blacklist) von unerwünschter Kommunikations-Aktivität/Einträgen====<br />
<br />
"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 (oder kein Weiterleitungs-Dispatch zu einem bereits existierenden), welches diese Daten jetzt in ihre Bedeutung umwandeln kann. <br />
:<code>sduino: Unknown code u1FFFFF0, help me!</code><br />
<br />
Außerdem kommt es gehäuft zu Logmeldungen und auch Events in ähnlicher Form:<br />
:<code>SIGNALduino_unknown incomming msg: u85#FF8081</code><br />
<br />
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.<br />
<br />
Derartige Einträge können mit dem Attribut WhitelistID minimiert werden. Dabei werden die Geräte, die nach Daten-Empfang tatsächlich verarbeitet werden sollen (also welche Protokolle vom FHEM Modul berücksichtigt werden), mit ihrer Protokollnummer in die WhitelistID aufgenommen.<br />
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. <br />
Die Protokollnummer kann Tabelle [[#Unterst.C3.BCtzte_Ger.C3.A4te]] 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>).<br />
{{Randnotiz|RNTyp=r|RNText=Achtung Schreibweise: Dokumentation oft als WhitelistID o.ä., aber Name ist whitelist_IDs!!<br />
}}<br />
Die Angabe erfolgt durch Komma getrennt: z.B.:<br />
:<code>1,2,5,10</code><br />
<br />
=== Senden mit dem SIGNALduino ===<br />
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:<br />
<br />
<code><br />
set sduino sendMsg P3#00111010#R4<br />
</code><br />
<br />
Dieser Befehl moduliert die Bitfolge 00111010 mittels Protokoll #3 und wiederholt die Nachricht 4x.<br />
Die Protokoll Nummer kann aus einer empfangenen Nachricht extrahiert werden. Ebenso die Bits.<br />
<code><br />
sduino: extracted data 00111010 (bin)<br />
sduino: Found Protocol id 3 <br />
</code><br />
<br />
Alternativ kann das Signal auch in einer "rohform" angegeben werden. Dies ist manchmal in speziellen Fällen notwendig:<br />
<code><br />
set sduino raw SR;;R=3;;P0=4742;;P1=-1554;;P2=286;;P3=-786;;P4=649;;P5=-420;;D=0123234545234545452323232323454523234523454523232345454523232323452345234523452345;;<br />
</code><br />
<br />
R=3 bedeutet, das Signal wird 3x gesendet.<br />
Die Übertragung besteht aus den in D angegeben Pulsen, welche in P0-P5 definiert werden.<br />
Die Daten kann man aus einer empfangenen MS oder MU Nachricht extrahieren.<br />
<br />
Alternativ kann ab Version 3.2 auch eine vereinfachte Form eingegeben werden.<br />
<br />
== Fehlerbehandlung ==<br />
Der SIGNALduino kann mit folgendem Befehl auf Werkseinstellungen zurückgesetzt werden:<br />
:<code>get raw e</code><br />
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.<br />
<br />
In der Firmware sind die folgenden Befehle eingebaut<br />
<br />
*:<code>get raw C<reg></code><br />
<reg> is a (two digit) hex number: return the value of the cc1101 register. <reg>=99 dumps the first 48 registers.<br />
Example: C35 -> C35 = 0D<br />
*:<code>get raw e</code><br />
EEPROM / factory reset. resets all eeprom values without reboot<br />
*:<code>get raw r<AA></code><br />
Read eeprom (da das "R" beim SIGNALDuino bereits mit freeram belegt ist, habe ich das "r" verwendet)<br />
*:<code>get raw r<AA>n</code><br />
Read 16 byte from eeprom (z.B. r00n)<br />
*:<code>get raw W<AA><DD></code><br />
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)<br />
<br />
Die Sendeleistung lässt sich mit <br />
:<code>get sduino ccreg 3E</code><br />
<br />
prüfen, wobei die Rückmeldung wie folgt zu lesen ist: <br />
"-10_dBm" => '34',<br />
"-5_dBm" => '68',<br />
"0_dBm" => '60',<br />
"5_dBm" => '84',<br />
"7_dBm" => 'C8',<br />
"10_dBm" => 'C0' <br />
Dabei wird die Sendeleistung dauerhaft mit dem Befehl<br />
:<code>set sduino cc1101_patable <value></code><br />
hochgeschaltet (<value> durch den Wert ersetzen).<br />
<br />
Weitere Firmware-Befehle sind im Thread-Beitrag {{Link2Forum|Topic=58396|Message=497921}} zu finden.<br />
<br />
== Foren Links ==<br />
* {{Link2Forum|Topic=38402|LinkText=Forenthread - Ankündigung}}<br />
* {{Link2Forum|Topic=58396|LinkText=SIGNALDuino Empfänger Firm- und Hardware}}<br />
* {{Link2Forum|Topic=58397|LinkText=Signalduino Entwicklung Version 3.3.1 }}<br />
* [http://www.rflink.nl/blog2/wiring Beschreibung zu diversen Empfängern und Verbesserung der Empfangsleistung]<br />
* [[SIGNALduino in die Arduino Entwicklungsumgebung einbinden]]<br />
* [[Somfy via SIGNALduino]]<br />
<br />
<br />
[[Kategorie:Interfaces]]<br />
[[Kategorie:Arduino]]</div>MGuhttp://wiki.fhem.de/w/index.php?title=SIGNALduino_in_die_Arduino_Entwicklungsumgebung_einbinden&diff=25353SIGNALduino in die Arduino Entwicklungsumgebung einbinden2018-02-17T15:31:38Z<p>MGu: MGu verschob die Seite SIGNALduino in die Arduino Entwicklungsumgebung einbinden nach SIGNALduino Compilieren: Nicht nur für Arduino IDE sondern auch mit Makefile. Hauptartikel enthält nicht zum Compilieren.</p>
<hr />
<div>#WEITERLEITUNG [[SIGNALduino Compilieren]]</div>MGuhttp://wiki.fhem.de/w/index.php?title=SIGNALduino_Compilieren&diff=25352SIGNALduino Compilieren2018-02-17T15:31:38Z<p>MGu: MGu verschob die Seite SIGNALduino in die Arduino Entwicklungsumgebung einbinden nach SIGNALduino Compilieren: Nicht nur für Arduino IDE sondern auch mit Makefile. Hauptartikel enthält nicht zum Compilieren.</p>
<hr />
<div>__TOC__<br />
== SIGNALduino in die Arduino Entwicklungsumgebung einbinden ==<br />
Zur Inbetriebnahme von [[SIGNALduino]] auf der Arduino IDE (getestet mit auf Arduino V1.6.7) müssen die Quelltexte von [https://github.com/RFD-FHEM/SIGNALDuino/ GitHub] (Stand Feb. 2017) geladen werden.<br />
<br />
Dort <code>Clone or download</code> und danach <code>Download ZIP</code> klicken und das ZIP-Archiv auspacken oder auf der Kommandozeile <code>git clone https://github.com/RFD-FHEM/SIGNALDuino.git</code> ausführen.<br />
<br />
Es werden folgende Dateien benötigt:<br />
* Die Datei <code>RF_Receiver.ino</code> in einen Ordner <code>RF_Receiver</code>, am besten direkt ins <code>Arduino</code> Verzeichnis der IDE kopieren.<br />
* Im <code>libraries</code> Ordner der Arduino IDE am besten einen Ordner mit Namen <code>SIGNALduino</code> anlegen, dort müssen dann die Dateien <code>bitstore</code>, <code>output</code>, <code>signalDecoder</code>, <code>SimpleFIFO</code> und <code>TimerOne</code> (jeweils <code>.cpp</code> und <code>.h</code> Datei) abgelegt werden.<br />
* Im diesem <code>SIGNALduino</code> Verzeichnis ist dann noch ein Unterverzeichnis <code>config</code> anzulegen, dort muss die Datei <code>known_16bit_timers.h</code> abgelegt werden.<br />
<br />
Struktur der SIGNALduino libraries:[[Datei:SIGNALduino-ViaArduinoEnvironment.jpg]]<br />
<br />
<br />
In Der Arduino Entwicklungsumgebung unter <code>Werkzeuge</code> → <code>Board</code> <tt>'''"Arduino Nano"'''</tt> und unter <code>Werkzeuge</code> → <code>Prozessor</code> <tt>'''"ATmega328"'''</tt> angeben. Nach Einstecken des SIGNALduinos in die USB Buchse noch den entsprechenden <code>COM-Port</code> unter <code>Werkzeuge</code> → <code>Port</code> angeben, danach sollte sich der Scetch <code>RF_Receiver.ino</code> übersetzen und auf den SIGNALduino laden lassen.<br />
<br />
== SIGNALduino mit Makefile unter Linux ==<br />
Wer lieber auf der Kommandozeile arbeitet kann SIGNALduino auch mit einem Makefile übersetzen und laden.<br />
Benötigt werden dazu:<br />
* Der Cross-Compiler und alle Werkzeuge für Arduino bzw. AVR. Bei Ubuntu und Debian Systemen:<br />
<source lang=bash><br />
# Arduino pakete installieren:<br />
sudo apt-get install arduino arduino-core arduino-mighty-1284p arduino-mk<br />
# AVR<br />
sudo apt-get install flashrom gcc-avr avrdude avr-libc binutils-avr<br />
# Die Unterstützung der Braillezeile kann zu Konflikten um den seriellen Port führen<br />
sudo apt-get remove brltty brltty-x11<br />
# Arduino-Makefile verwendet YAML und serialport in Perl<br />
sudo apt-get libdevice-serialport-perl libyaml-perl<br />
</source><br />
<br />
* SIGNALDuino Quelltexte<br />
<source lang=bash><br />
# Hier kann man natürlich jedes beliebige Verzeichnis nehmen.<br />
mkdir -p ~/src/arduino; cd ~/src/arduino<br />
# SIGNALDuino von github clonen<br />
git clone https://github.com/RFD-FHEM/SIGNALDuino.git<br />
</source><br />
<br />
* Die Arduino Quellen (optional man kann auch die aus der Paketverwaltung verwenden)<br />
<source lang=bash><br />
# siehe https://www.arduino.cc/en/Main/Software für neuste Version<br />
wget https://downloads.arduino.cc/arduino-1.8.5-linux64.tar.xz<br />
tar xvJf arduino-1.8.5-linux64.tar.xz<br />
</source><br />
<br />
* Die neuste Version Arduino-Makefile<br />
<source lang=bash><br />
# Neuste Version von github clonen<br />
git clone https://github.com/sudar/Arduino-Makefile.git<br />
</source><br />
<br />
Jetzt muss in <code>SIGNALDuino/RF_Receiver</code> noch ein <code>Makefile</code> erstellt werden:<br />
<source lang=make><br />
# Verzeichnis in dem die Arduino-Quellen liegen<br />
ARDUINO_DIR=$(HOME)/src/arduino/arduino-1.8.5<br />
# Verzeichnis mit dem Arduino-Makefile<br />
ARDMK_DIR=$(HOME)/src/arduino/Arduino-Makefile<br />
# Basisverzeichnis unter dem die AVR-Werkzeuge liegen<br />
AVR_TOOLS_DIR=/usr<br />
AVRDUDE_OPTS = -v<br />
BOARD_TAG = nano<br />
BOARD_SUB = atmega328<br />
USER_LIB_PATH += $(realpath ../src/_micro-api/libraries)<br />
ARDUINO_LIBS += bitstore output signalDecoder SimpleFIFO TimerOne EEPROM <br />
include $(ARDMK_DIR)/Arduino.mk<br />
</source><br />
<br />
Mit stand vom 17.02.2018 müssen jetzt noch ein paar kleine Fehler beseitigt werden:<br />
* <code>RF_Receiver/RF_Receiver.ino</code><br />
:* <code>#define CMP_NEWSD</code> statt <code>#define CMP_NEWSD;</code><br />
* <code>src/_micro-api/libraries/output/src/output.h</code><br />
* <code>src/_micro-api/libraries/signalDecoder/src/signalDecoder.h</code><br />
:* <code> #include "Arduino.h"</code> statt <code> #include "arduino.h"</code><br />
* in <code>src/_micro-api/libraries/signalDecoder</code> fehlt <code>library.properties</code><br />
:* <code>cd src/_micro-api/libraries/signalDecoder</code><br />
:* <code>cp ../bitstore/library.properties .</code><br />
:* <code>sed -i 's/bitstore/signalDecoder/g' library.properties</code><br />
<br />
Danach kann SIGNALDuino für den Arduino Nano übersetzt werden:<br />
<source lang=bash><br />
cd RF_Receiver<br />
make<br />
AUfräumen mit<br />
make clean<br />
</source><br />
<br />
== Foren Links ==<br />
* {{Link2Forum|Topic=58396|LinkText=SIGNALDuino Empfänger Firm- und Hardware}}<br />
* {{Link2Forum|Topic=58397|LinkText=Signalduino Entwicklung Version 3.3.1 }}<br />
* [http://www.nemcon.nl/blog2/wiring Beschreibung zu diversen Empfängern und Verbesserung der Empfangsleistung]<br />
<br />
[[Kategorie:HOWTOS]]<br />
[[Kategorie:Other Components]]<br />
[[Kategorie:Interfaces]]<br />
[[Kategorie:Arduino]]</div>MGuhttp://wiki.fhem.de/w/index.php?title=SIGNALduino_Compilieren&diff=25351SIGNALduino Compilieren2018-02-17T15:30:21Z<p>MGu: </p>
<hr />
<div>__TOC__<br />
== SIGNALduino in die Arduino Entwicklungsumgebung einbinden ==<br />
Zur Inbetriebnahme von [[SIGNALduino]] auf der Arduino IDE (getestet mit auf Arduino V1.6.7) müssen die Quelltexte von [https://github.com/RFD-FHEM/SIGNALDuino/ GitHub] (Stand Feb. 2017) geladen werden.<br />
<br />
Dort <code>Clone or download</code> und danach <code>Download ZIP</code> klicken und das ZIP-Archiv auspacken oder auf der Kommandozeile <code>git clone https://github.com/RFD-FHEM/SIGNALDuino.git</code> ausführen.<br />
<br />
Es werden folgende Dateien benötigt:<br />
* Die Datei <code>RF_Receiver.ino</code> in einen Ordner <code>RF_Receiver</code>, am besten direkt ins <code>Arduino</code> Verzeichnis der IDE kopieren.<br />
* Im <code>libraries</code> Ordner der Arduino IDE am besten einen Ordner mit Namen <code>SIGNALduino</code> anlegen, dort müssen dann die Dateien <code>bitstore</code>, <code>output</code>, <code>signalDecoder</code>, <code>SimpleFIFO</code> und <code>TimerOne</code> (jeweils <code>.cpp</code> und <code>.h</code> Datei) abgelegt werden.<br />
* Im diesem <code>SIGNALduino</code> Verzeichnis ist dann noch ein Unterverzeichnis <code>config</code> anzulegen, dort muss die Datei <code>known_16bit_timers.h</code> abgelegt werden.<br />
<br />
Struktur der SIGNALduino libraries:[[Datei:SIGNALduino-ViaArduinoEnvironment.jpg]]<br />
<br />
<br />
In Der Arduino Entwicklungsumgebung unter <code>Werkzeuge</code> → <code>Board</code> <tt>'''"Arduino Nano"'''</tt> und unter <code>Werkzeuge</code> → <code>Prozessor</code> <tt>'''"ATmega328"'''</tt> angeben. Nach Einstecken des SIGNALduinos in die USB Buchse noch den entsprechenden <code>COM-Port</code> unter <code>Werkzeuge</code> → <code>Port</code> angeben, danach sollte sich der Scetch <code>RF_Receiver.ino</code> übersetzen und auf den SIGNALduino laden lassen.<br />
<br />
== SIGNALduino mit Makefile unter Linux ==<br />
Wer lieber auf der Kommandozeile arbeitet kann SIGNALduino auch mit einem Makefile übersetzen und laden.<br />
Benötigt werden dazu:<br />
* Der Cross-Compiler und alle Werkzeuge für Arduino bzw. AVR. Bei Ubuntu und Debian Systemen:<br />
<source lang=bash><br />
# Arduino pakete installieren:<br />
sudo apt-get install arduino arduino-core arduino-mighty-1284p arduino-mk<br />
# AVR<br />
sudo apt-get install flashrom gcc-avr avrdude avr-libc binutils-avr<br />
# Die Unterstützung der Braillezeile kann zu Konflikten um den seriellen Port führen<br />
sudo apt-get remove brltty brltty-x11<br />
# Arduino-Makefile verwendet YAML und serialport in Perl<br />
sudo apt-get libdevice-serialport-perl libyaml-perl<br />
</source><br />
<br />
* SIGNALDuino Quelltexte<br />
<source lang=bash><br />
# Hier kann man natürlich jedes beliebige Verzeichnis nehmen.<br />
mkdir -p ~/src/arduino; cd ~/src/arduino<br />
# SIGNALDuino von github clonen<br />
git clone https://github.com/RFD-FHEM/SIGNALDuino.git<br />
</source><br />
<br />
* Die Arduino Quellen (optional man kann auch die aus der Paketverwaltung verwenden)<br />
<source lang=bash><br />
# siehe https://www.arduino.cc/en/Main/Software für neuste Version<br />
wget https://downloads.arduino.cc/arduino-1.8.5-linux64.tar.xz<br />
tar xvJf arduino-1.8.5-linux64.tar.xz<br />
</source><br />
<br />
* Die neuste Version Arduino-Makefile<br />
<source lang=bash><br />
# Neuste Version von github clonen<br />
git clone https://github.com/sudar/Arduino-Makefile.git<br />
</source><br />
<br />
Jetzt muss in <code>SIGNALDuino/RF_Receiver</code> noch ein <code>Makefile</code> erstellt werden:<br />
<source lang=make><br />
# Verzeichnis in dem die Arduino-Quellen liegen<br />
ARDUINO_DIR=$(HOME)/src/arduino/arduino-1.8.5<br />
# Verzeichnis mit dem Arduino-Makefile<br />
ARDMK_DIR=$(HOME)/src/arduino/Arduino-Makefile<br />
# Basisverzeichnis unter dem die AVR-Werkzeuge liegen<br />
AVR_TOOLS_DIR=/usr<br />
AVRDUDE_OPTS = -v<br />
BOARD_TAG = nano<br />
BOARD_SUB = atmega328<br />
USER_LIB_PATH += $(realpath ../src/_micro-api/libraries)<br />
ARDUINO_LIBS += bitstore output signalDecoder SimpleFIFO TimerOne EEPROM <br />
include $(ARDMK_DIR)/Arduino.mk<br />
</source><br />
<br />
Mit stand vom 17.02.2018 müssen jetzt noch ein paar kleine Fehler beseitigt werden:<br />
* <code>RF_Receiver/RF_Receiver.ino</code><br />
:* <code>#define CMP_NEWSD</code> statt <code>#define CMP_NEWSD;</code><br />
* <code>src/_micro-api/libraries/output/src/output.h</code><br />
* <code>src/_micro-api/libraries/signalDecoder/src/signalDecoder.h</code><br />
:* <code> #include "Arduino.h"</code> statt <code> #include "arduino.h"</code><br />
* in <code>src/_micro-api/libraries/signalDecoder</code> fehlt <code>library.properties</code><br />
:* <code>cd src/_micro-api/libraries/signalDecoder</code><br />
:* <code>cp ../bitstore/library.properties .</code><br />
:* <code>sed -i 's/bitstore/signalDecoder/g' library.properties</code><br />
<br />
Danach kann SIGNALDuino für den Arduino Nano übersetzt werden:<br />
<source lang=bash><br />
cd RF_Receiver<br />
make<br />
AUfräumen mit<br />
make clean<br />
</source><br />
<br />
== Foren Links ==<br />
* {{Link2Forum|Topic=58396|LinkText=SIGNALDuino Empfänger Firm- und Hardware}}<br />
* {{Link2Forum|Topic=58397|LinkText=Signalduino Entwicklung Version 3.3.1 }}<br />
* [http://www.nemcon.nl/blog2/wiring Beschreibung zu diversen Empfängern und Verbesserung der Empfangsleistung]<br />
<br />
[[Kategorie:HOWTOS]]<br />
[[Kategorie:Other Components]]<br />
[[Kategorie:Interfaces]]<br />
[[Kategorie:Arduino]]</div>MGuhttp://wiki.fhem.de/w/index.php?title=SIGNALduino_Compilieren&diff=25350SIGNALduino Compilieren2018-02-17T15:29:37Z<p>MGu: Compilieren unter Linux mit Makefile</p>
<hr />
<div>== SIGNALduino in die Arduino Entwicklungsumgebung einbinden ==<br />
Zur Inbetriebnahme von [[SIGNALduino]] auf der Arduino IDE (getestet mit auf Arduino V1.6.7) müssen die Quelltexte von [https://github.com/RFD-FHEM/SIGNALDuino/ GitHub] (Stand Feb. 2017) geladen werden.<br />
<br />
Dort <code>Clone or download</code> und danach <code>Download ZIP</code> klicken und das ZIP-Archiv auspacken oder auf der Kommandozeile <code>git clone https://github.com/RFD-FHEM/SIGNALDuino.git</code> ausführen.<br />
<br />
Es werden folgende Dateien benötigt:<br />
* Die Datei <code>RF_Receiver.ino</code> in einen Ordner <code>RF_Receiver</code>, am besten direkt ins <code>Arduino</code> Verzeichnis der IDE kopieren.<br />
* Im <code>libraries</code> Ordner der Arduino IDE am besten einen Ordner mit Namen <code>SIGNALduino</code> anlegen, dort müssen dann die Dateien <code>bitstore</code>, <code>output</code>, <code>signalDecoder</code>, <code>SimpleFIFO</code> und <code>TimerOne</code> (jeweils <code>.cpp</code> und <code>.h</code> Datei) abgelegt werden.<br />
* Im diesem <code>SIGNALduino</code> Verzeichnis ist dann noch ein Unterverzeichnis <code>config</code> anzulegen, dort muss die Datei <code>known_16bit_timers.h</code> abgelegt werden.<br />
<br />
Struktur der SIGNALduino libraries:[[Datei:SIGNALduino-ViaArduinoEnvironment.jpg]]<br />
<br />
<br />
In Der Arduino Entwicklungsumgebung unter <code>Werkzeuge</code> → <code>Board</code> <tt>'''"Arduino Nano"'''</tt> und unter <code>Werkzeuge</code> → <code>Prozessor</code> <tt>'''"ATmega328"'''</tt> angeben. Nach Einstecken des SIGNALduinos in die USB Buchse noch den entsprechenden <code>COM-Port</code> unter <code>Werkzeuge</code> → <code>Port</code> angeben, danach sollte sich der Scetch <code>RF_Receiver.ino</code> übersetzen und auf den SIGNALduino laden lassen.<br />
<br />
== SIGNALduino mit Makefile unter Linux ==<br />
Wer lieber auf der Kommandozeile arbeitet kann SIGNALduino auch mit einem Makefile übersetzen und laden.<br />
Benötigt werden dazu:<br />
* Der Cross-Compiler und alle Werkzeuge für Arduino bzw. AVR. Bei Ubuntu und Debian Systemen:<br />
<source lang=bash><br />
# Arduino pakete installieren:<br />
sudo apt-get install arduino arduino-core arduino-mighty-1284p arduino-mk<br />
# AVR<br />
sudo apt-get install flashrom gcc-avr avrdude avr-libc binutils-avr<br />
# Die Unterstützung der Braillezeile kann zu Konflikten um den seriellen Port führen<br />
sudo apt-get remove brltty brltty-x11<br />
# Arduino-Makefile verwendet YAML und serialport in Perl<br />
sudo apt-get libdevice-serialport-perl libyaml-perl<br />
</source><br />
<br />
* SIGNALDuino Quelltexte<br />
<source lang=bash><br />
# Hier kann man natürlich jedes beliebige Verzeichnis nehmen.<br />
mkdir -p ~/src/arduino; cd ~/src/arduino<br />
# SIGNALDuino von github clonen<br />
git clone https://github.com/RFD-FHEM/SIGNALDuino.git<br />
</source><br />
<br />
* Die Arduino Quellen (optional man kann auch die aus der Paketverwaltung verwenden)<br />
<source lang=bash><br />
# siehe https://www.arduino.cc/en/Main/Software für neuste Version<br />
wget https://downloads.arduino.cc/arduino-1.8.5-linux64.tar.xz<br />
tar xvJf arduino-1.8.5-linux64.tar.xz<br />
</source><br />
<br />
* Die neuste Version Arduino-Makefile<br />
<source lang=bash><br />
# Neuste Version von github clonen<br />
git clone https://github.com/sudar/Arduino-Makefile.git<br />
</source><br />
<br />
Jetzt muss in <code>SIGNALDuino/RF_Receiver</code> noch ein <code>Makefile</code> erstellt werden:<br />
<source lang=make><br />
# Verzeichnis in dem die Arduino-Quellen liegen<br />
ARDUINO_DIR=$(HOME)/src/arduino/arduino-1.8.5<br />
# Verzeichnis mit dem Arduino-Makefile<br />
ARDMK_DIR=$(HOME)/src/arduino/Arduino-Makefile<br />
# Basisverzeichnis unter dem die AVR-Werkzeuge liegen<br />
AVR_TOOLS_DIR=/usr<br />
AVRDUDE_OPTS = -v<br />
BOARD_TAG = nano<br />
BOARD_SUB = atmega328<br />
USER_LIB_PATH += $(realpath ../src/_micro-api/libraries)<br />
ARDUINO_LIBS += bitstore output signalDecoder SimpleFIFO TimerOne EEPROM <br />
include $(ARDMK_DIR)/Arduino.mk<br />
</source><br />
<br />
Mit stand vom 17.02.2018 müssen jetzt noch ein paar kleine Fehler beseitigt werden:<br />
* <code>RF_Receiver/RF_Receiver.ino</code><br />
:* <code>#define CMP_NEWSD</code> statt <code>#define CMP_NEWSD;</code><br />
* <code>src/_micro-api/libraries/output/src/output.h</code><br />
* <code>src/_micro-api/libraries/signalDecoder/src/signalDecoder.h</code><br />
:* <code> #include "Arduino.h"</code> statt <code> #include "arduino.h"</code><br />
* in <code>src/_micro-api/libraries/signalDecoder</code> fehlt <code>library.properties</code><br />
:* <code>cd src/_micro-api/libraries/signalDecoder</code><br />
:* <code>cp ../bitstore/library.properties .</code><br />
:* <code>sed -i 's/bitstore/signalDecoder/g' library.properties</code><br />
<br />
Danach kann SIGNALDuino für den Arduino Nano übersetzt werden:<br />
<source lang=bash><br />
cd RF_Receiver<br />
make<br />
AUfräumen mit<br />
make clean<br />
</source><br />
<br />
== Foren Links ==<br />
* {{Link2Forum|Topic=58396|LinkText=SIGNALDuino Empfänger Firm- und Hardware}}<br />
* {{Link2Forum|Topic=58397|LinkText=Signalduino Entwicklung Version 3.3.1 }}<br />
* [http://www.nemcon.nl/blog2/wiring Beschreibung zu diversen Empfängern und Verbesserung der Empfangsleistung]<br />
<br />
[[Kategorie:HOWTOS]]<br />
[[Kategorie:Other Components]]<br />
[[Kategorie:Interfaces]]<br />
[[Kategorie:Arduino]]</div>MGuhttp://wiki.fhem.de/w/index.php?title=SIGNALduino_Compilieren&diff=25349SIGNALduino Compilieren2018-02-17T11:09:32Z<p>MGu: Verzeichnisname falsch</p>
<hr />
<div>== Inbetriebnahme ==<br />
Zur Inbetriebnahme von [[SIGNALduino]] auf der Arduino IDE (getestet mit auf Arduino V1.6.7) müssen die Quelltexte von [https://github.com/RFD-FHEM/SIGNALDuino/ GitHub] (Stand Feb. 2017) geladen werden.<br />
<br />
Dort <code>Clone or download</code> und danach <code>Download ZIP</code> klicken und das ZIP-Archiv auspacken oder auf der Kommandozeile <code>git clone https://github.com/RFD-FHEM/SIGNALDuino.git</code> ausführen.<br />
<br />
Es werden folgende Dateien benötigt:<br />
* Die Datei <code>RF_Receiver.ino</code> in einen Ordner <code>RF_Receiver</code>, am besten direkt ins <code>Arduino</code> Verzeichnis der IDE kopieren.<br />
* Im <code>libraries</code> Ordner der Arduino IDE am besten einen Ordner mit Namen <code>SIGNALduino</code> anlegen, dort müssen dann die Dateien <code>bitstore</code>, <code>output</code>, <code>signalDecoder</code>, <code>SimpleFIFO</code> und <code>TimerOne</code> (jeweils <code>.cpp</code> und <code>.h</code> Datei) abgelegt werden.<br />
* Im diesem <code>SIGNALduino</code> Verzeichnis ist dann noch ein Unterverzeichnis <code>config</code> anzulegen, dort muss die Datei <code>known_16bit_timers.h</code> abgelegt werden.<br />
<br />
Struktur der SIGNALduino libraries:[[Datei:SIGNALduino-ViaArduinoEnvironment.jpg]]<br />
<br />
<br />
In Der Arduino Entwicklungsumgebung unter <code>Werkzeuge</code> → <code>Board</code> <tt>'''"Arduino Nano"'''</tt> und unter <code>Werkzeuge</code> → <code>Prozessor</code> <tt>'''"ATmega328"'''</tt> angeben. Nach Einstecken des SIGNALduinos in die USB Buchse noch den entsprechenden <code>COM-Port</code> unter <code>Werkzeuge</code> → <code>Port</code> angeben, danach sollte sich der Scetch <code>RF_Receiver.ino</code> übersetzen und auf den SIGNALduino laden lassen.<br />
<br />
== Foren Links ==<br />
* {{Link2Forum|Topic=58396|LinkText=SIGNALDuino Empfänger Firm- und Hardware}}<br />
* {{Link2Forum|Topic=58397|LinkText=Signalduino Entwicklung Version 3.3.1 }}<br />
* [http://www.nemcon.nl/blog2/wiring Beschreibung zu diversen Empfängern und Verbesserung der Empfangsleistung]<br />
<br />
[[Kategorie:HOWTOS]]<br />
[[Kategorie:Other Components]]<br />
[[Kategorie:Interfaces]]<br />
[[Kategorie:Arduino]]</div>MGuhttp://wiki.fhem.de/w/index.php?title=SIGNALduino_Compilieren&diff=25348SIGNALduino Compilieren2018-02-17T10:50:31Z<p>MGu: wikify and command line git</p>
<hr />
<div>== Inbetriebnahme ==<br />
Zur Inbetriebnahme von [[SIGNALduino]] auf der Arduino IDE (getestet mit auf Arduino V1.6.7) müssen die Quelltexte von [https://github.com/RFD-FHEM/SIGNALDuino/ GitHub] (Stand Feb. 2017) geladen werden.<br />
<br />
Dort <code>Clone or download</code> und danach <code>Download ZIP</code> klicken und das ZIP-Archiv auspacken oder auf der Kommandozeile <code>git clone https://github.com/RFD-FHEM/SIGNALDuino.git</code> ausführen.<br />
<br />
Es werden folgende Dateien benötigt:<br />
* Die Datei <code>RF_Receiver.ino</code> in einen Ordner <code>RF_Receiver</code>, am besten direkt ins <code>Arduino</code> Verzeichnis der IDE kopieren.<br />
* Im <code>libraries</code> Ordner der Arduino IDE am besten einen Ordner mit Namen <code>SIGNALduino</code> anlegen, dort müssen dann die Dateien <code>bitstore</code>, <code>output</code>, <code>signalDecoder</code>, <code>SimpleFIFO</code> und <code>TimerOnce</code> (jeweils <code>.cpp</code> und <code>.h</code> Datei) abgelegt werden.<br />
* Im diesem <code>SIGNALduino</code> Verzeichnis ist dann noch ein Unterverzeichnis <code>config</code> anzulegen, dort muss die Datei <code>known_16bit_timers.h</code> abgelegt werden.<br />
<br />
Struktur der SIGNALduino libraries:[[Datei:SIGNALduino-ViaArduinoEnvironment.jpg]]<br />
<br />
<br />
In Der Arduino Entwicklungsumgebung unter <code>Werkzeuge</code> → <code>Board</code> <tt>'''"Arduino Nano"'''</tt> und unter <code>Werkzeuge</code> → <code>Prozessor</code> <tt>'''"ATmega328"'''</tt> angeben. Nach Einstecken des SIGNALduinos in die USB Buchse noch den entsprechenden <code>COM-Port</code> unter <code>Werkzeuge</code> → <code>Port</code> angeben, danach sollte sich der Scetch <code>RF_Receiver.ino</code> übersetzen und auf den SIGNALduino laden lassen.<br />
<br />
== Foren Links ==<br />
* {{Link2Forum|Topic=58396|LinkText=SIGNALDuino Empfänger Firm- und Hardware}}<br />
* {{Link2Forum|Topic=58397|LinkText=Signalduino Entwicklung Version 3.3.1 }}<br />
* [http://www.nemcon.nl/blog2/wiring Beschreibung zu diversen Empfängern und Verbesserung der Empfangsleistung]<br />
<br />
[[Kategorie:HOWTOS]]<br />
[[Kategorie:Other Components]]<br />
[[Kategorie:Interfaces]]<br />
[[Kategorie:Arduino]]</div>MGuhttp://wiki.fhem.de/w/index.php?title=SIGNALduino&diff=25347SIGNALduino2018-02-17T10:18:25Z<p>MGu: Hinweis wie man selbst compilieren kann.</p>
<hr />
<div>{{Infobox Modul<br />
|ModPurpose=Empfang und Verarbeitung von digitalen Signalen<br />
|ModType=d<br />
|ModFTopic=38402<br />
|ModCmdRef=SIGNALduino<br />
|ModForumArea=Sonstige Systeme<br />
|ModTechName=00_SIGNALduino.pm<br />
|ModOwner=Sidey ({{Link2FU|8018|Forum}}/[[Benutzer Diskussion:Sidey|Wiki]])<br />
}}<br />
<br />
== Einleitung ==<br />
=== Übersicht ===<br />
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.<br />
<br />
Der SIGNALduino(-Stick) erkennt Signale anhand von Mustern und gibt sie (als maximal detaillierte Beschreibung einer Signalabfolge) dann schlicht sofort nur noch an FHEM zur Auswertung (Dekodierung) weiter. Auch nicht erkannte Signale werden an FHEM übergeben.<br />
Aufgabe des SIGNALduino (Firmware/Stick) ist es also nur, Signal-Aktivitäten zu erfassen und maximal präzise (als kurzer Text-String) zu beschreiben.<br />
Alles weitere (echte, finale Auswertung / Zuweisung dieser Signal-Daten) wird dann auf einer großen Box (Raspberry o.ä.) gemacht.<br />
<br />
=== Vorteil gegenüber einem CUL/FHEMduino ===<br />
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 (also auf flexibel direkt updatebarer Rechner-Seite!!). Änderungen am Arduino-Firmware-Code sind normalerweise nicht notwendig (sofern die grundsätzliche Signal-Klassifizierung des Sticks korrekt funktioniert - leider nicht immer, z.B.: [https://github.com/RFD-FHEM/SIGNALDuino/issues/65 MU-Nachrichten werden z.T. als MC erkannt]).<br />
<br />
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.<br />
<br />
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.<br />
<br />
== Hardware ==<br />
<br />
Der SIGNALduino (Hardware) wird über den USB Port angeschlossen, er kann aber auch mit zusätzlichen ESP Modulen über ein WLAN angebunden werden. <br />
<br />
Der SIGNALduino basiert auf einem [http://arduino.cc/de/Main/ArduinoBoardNano Arduino Nano], die Schaltung entspricht der des [[FHEMduino]] oder dem [[Selbstbau_CUL]]:<br />
* Entweder wird ein Arduino mit einfachen Sende- und Empfangsmodulen verwendet, dann ist die Verkabelung identisch zum [[FHEMduino]] <br />
* Oder es wird ein CC1101 Transceiver verwendet, dann ist die Verkabelung identisch zum [[Selbstbau_CUL]].<br />
* Zuletzt gibt es ein fertig konfektioniertes Modul von In-Circuit mit Radino CC1101 Varianten, link zum [http://shop.in-circuit.de/index.php Hersteller]. <br />
<br />
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. <br />
<br />
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. Die SW ist auf [https://github.com/RFD-FHEM/SIGNALDuino github]. Vorgesehen ist nur die Übersetzung unter Windows mit Visual Studio und dem Visual Micro Zusatz. Es gibt aber auch eine Anleitung, wie man [[SIGNALduino in die Arduino Entwicklungsumgebung einbinden]] kann.<br />
<br />
Es gibt auch eine Variante des SIGNALduino, die auf einem [[ESP8266]] nativ läuft, diese funktioniert seit Anfang 2018 annehmbar, allerdings befindet diese sich noch in einer Entwicklungsphase.<br />
<br />
An den "SIGNALESP" kann auch ein CC1101 via SPI angebunden werden:<br />
<br />
{||<br />
!CC1101 Bezeichnung<br />
!ESP Pin<br />
|-<br />
|CLK||GPIO14<br />
|-<br />
|MOSI||GPIO13<br />
|-<br />
|MISO||GPIO12<br />
|-<br />
|CSN||GPIO15<br />
|-<br />
|GDO0||GPIO4<br />
|-<br />
|GDO2||GPIO5<br />
|}<br />
<br />
<br />
Wird ein einfacher Empfänger / Sender Kombination verwendet, dann über die PINs:<br />
<br />
{||<br />
! Bezeichnung <br />
! ESP Pin<br />
|-<br />
|Transmitter||GPIO4<br />
|-<br />
|Receiver||GPIO5<br />
|}<br />
<br />
=== Einfache Module ===<br />
<br />
[[Datei:Fhemduino_schematic.png|200px|thumb|right|Beispielschaltplan SIGNAL(FHEM)duino]] <br />
<br />
Mit einem Arduino-Nano und folgenden, billigen Sende- und Empfangsmodulen können Sie einen SIGNALduino bauen:<br />
* FS1000A Dies ist das Sendemodul (TX) und wird oft im Set mit dem billigen XY-MK-5V-Empfänger angeboten (etwa 5€). <br />
* RXB6 Das ist das empfohlene Empfangsmodul (RX), statt XY-MK-5V, etwa 5€ aus Deutschland.<br />
<br />
Die Verkabelung erfolgt analog zum [[FHEMduino]] und das bedeutet (Arduino -> Modul):<br />
* PIN D2 an DATA des RX-Moduls<br />
* PIN D11 an DATA des TX-Moduls (PIN links mit Beschriftung ATAD)<br />
<br />
Zusätzlich muss noch jeweils GND und 5V des Arduino mit dem GND bzw. VCC des Moduls verbunden werden.<br />
<br />
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).<br />
<br />
== Software: Modul ==<br />
<br />
=== USB-ID ermitteln ===<br />
Bevor der SIGNALduino mit dem FHEM Server (im Beispiel hier ein Raspberry PI) verbunden werden kann, muss die USB-Schnittstelle ermittelt werden. Hierzu bitte auf dem Terminal den Befehl<br />
<pre> ls -l /dev/serial/by-id </pre><br />
ausführen. Beispielhaft sieht das Ergebnis etwa so aus: <br />
''lrwxrwxrwx 1 root root 13 Jan 31 00:02 '''usb-FTDI_FT232R_USB_UART_A903N5T5-if00-port''' -> ../../ttyUSB0'' <br />
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.<br />
<br />
=== FHEM-Modul laden ===<br />
Die SIGNALduino Module werden über das FHEM [[update]] verteilt, sobald die Änderungen einen "stabilen" und alltags tauglichen Zustand haben.<br />
<br />
Die in der Entwicklung befindliche Version kann mit folgenden Befehlen geladen werden:<br />
<br />
* FHEM aktualisieren: <code>update</code> <br />
* 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<br />
*Danach kann das Gerät wie folgt definiert werden (die Spezifikation des USB-Anschlusses muss dabei an die aktuellen Gegebenheiten angepasst werden):<br />
:<code>define <eigener-SIGNALduino-Name> SIGNALduino /dev/serial/by-id/usb-FTDI_FT232R_USB_UART_A903N5T5-if00-port0@57600</code><br />
Nach dem Einbinden wird der SIGNALduino, falls er erkannt wird, im Status "Opened" angezeigt. <br />
<br />
Für neuere Entwicklungen kann in FHEM auch dauerhaft die developer Version aktualisiert werden:<br />
<code>update add <nowiki>https://raw.githubusercontent.com/RFD-FHEM/RFFHEM/dev-r33/controls_signalduino.txt</nowiki></code> <br />
Danach wird FHEM bei dem normalen Update-Befehl immer automatisch die aktuelle dev Version laden.<br />
<br />
Die nachfolgenden Beispiel-Befehle verwenden "sduino" als <eigener-SIGNALduino-Name>.<br />
<br />
==== Flashen des Arduino mit der SIGNALduino Firmware ====<br />
Falls avrdude noch nicht vorhanden ist, kann es mit folgendem Befehl installiert werden:<br />
:<code>sudo apt-get install avrdude</code><br />
<br />
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<br />
<code>attr sduino hardware nanoCC1101</code><br />
sonst üblicherweise<br />
<code>attr sduino hardware nano328</code><br />
<br />
Anschließend kann der ''flash'' Befehl abgesetzt werden: <br />
<code>set sduino flash </code><br />
Dadurch wird der Arduino mit der gewählten Firmware geflasht. Das Ergebnis wird im Webinterface direkt angezeigt.<br />
<br />
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:<br />
:<code>set sduino flash FHEM/firmware/SIGNALduino_mega2560.hex</code><br />
(je nachdem wo und unter welchem Namen die .hex Datei abgelegt wurde)<br />
<br />
==== Flashen einer Firmware über HTTP ====<br />
Die Firmware wird in absehbarer Zeit nicht mehr über den Update Mechanismus verteilt werden. <br />
Damit die passende Firmware auf den SIGNALduiono geladen werden kann, wird diese dann über HTTP geladen.<br />
<br />
==== Vorabversion einer Firmware ====<br />
Die Firmware des SIGNALduino wird ebenso wie das FHEM Modul auch weiter entwickelt.<br />
Die Entwickler sind auf Tests und Rückmeldungen der Nutzer angewiesen, da leider nicht alle Sensoren vorher getestet werden können.<br />
<br />
Aktuell (Anfang 2018) ist noch die Version 3.3.1 in Entwicklung. Diese steht aktuell in einer Release Candidate Version zur Verfügung.<br />
<br />
Für die Folgenden Microcontroller kann man die Firmware downloaden.<br />
<br />
SIGNALDuino_nanoCC1101-331rc2.hex für einen Nano mit CC1101<br />
<code>set sduino flash https://drive.google.com/uc?export=download&id=1sIac8-Qhts4c7OEkFH72Lv6hhgbOadFQ<br />
</code><br />
<br />
SIGNALDuino_nano_331rc2.hex für einen Nano ohne cc1101<br />
<code>set sduino flash https://drive.google.com/uc?export=download&id=1FnnIjJhBI1mjxZKzMnNtnnYzHChyn0lk<br />
</code><br />
<br />
SIGNALDuino_promini_331rc2.hex für einen promini ohne cc1101<br />
<code>set sduino flash https://drive.google.com/uc?export=download&id=1-AJKmO2DjQPi9_O3XI6KqvE9oYLHOyl8<br />
</code><br />
<br />
<br />
SIGNALESP_331rc2.bin (mit cc1101) für einen ESP8266<br />
<code>set ipduino flash https://drive.google.com/uc?export=download&id=1V8ZfLnRnskc64XZkfL-qwmI7AsSd6KRG<br />
</code><br />
!Achtung, aktuell wird die Firmware für den ESP dadurch nur herunter geladen. Flashen müsst ihr leider immer noch über ein passendes Tool <br />
z.B. "ESP8266Flasher.exe" oder Esptool und einer seriellen Konsole.<br />
<br />
Nach dem Booten des ESPs, spannt dieser ein eigenes WLAN auf. Habt ihr euch damit verbunden, könnt ihr den ESP mit eurem vorhandenen WLAN verbinden.<br />
<br />
==== Flashen eines radino Boards mit ATmega32U4 ====<br />
<br />
Diese Funktion steht nur in der Entwicklungsversion dev-r33 zur Verfügung:<br />
Das Radino Board muss derzeit noch mit Angabe des Dateinamens geflasht werden:<br />
<code>set sduino flash FHEM/firmware/SIGNALDuino_radinoCC1101.hex</code><br />
<br />
Auch sind Berichte bekannt, dass der Radino beim Neustart von FHEM nicht korrekt initialisiert wird.<br />
<br />
=== Geräteerkennung ===<br />
==== Unterstützte Geräte ====<br />
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.<br />
{|class="wikitable"<br />
! style="text-align:left;"| Produkt <br />
! (E)mpfangen<br />(S)enden <br />
! Hinweise <br />
! Verwendetes Modul <br />
! Protokoll ID<br />
|-<br />
|TCM Wetterstation (97001 und 21xxx Serie)||E|| || CUL_TCM97001 || 0<br />
|-<br />
|ABS Wetterstation (ABS 700)||E|| || CUL_TCM97001 || 0<br />
|-<br />
|Prologue Wetterstation ||E|| ||CUL_TCM97001 || 0<br />
|-<br />
|Rubicson Wetterstation ||E|| ||CUL_TCM97001 ||0 <br />
|-<br />
|NC_WS Wetterstation ||E|| ||CUL_TCM97001 || 0<br />
|-<br />
|[http://www.gt-support.de/ GT-WT-02 Wetterstation]||E|| ||CUL_TCM97001 || 0<br />
|-<br />
|AURIOL Wetterstation ||E|| ||CUL_TCM97001 || 0<br />
|-<br />
|Mebus Wetterstation ||E|| ||CUL_TCM97001 || 0<br />
|-<br />
|Intertechno Funkschalter||E S|| ||IT || 3,4,5,17<br />
|-<br />
|<strike>Conrad RSL Funkschalter</strike>||E S|| Funktioniert aktuell nicht || SIGNALduino_RSL || <br />
|-<br />
|[http://global.oregonscientific.com/product_view.php?id=5 Oregon Scientific Wettersensoren]||E || Protokoll V2 & V3 implementiert || OREGON || 10<br />
|-<br />
|Bresser Temp/Hydro Sensor||E || || Hideki || 12<br />
|-<br />
|[https://de.hama.com/00104985/hama-aussensensor-ts33c-fuer-wetterstation Hama TS33C]||E || || Hideki || 12<br />
|-<br />
|TFA Temp/Hydro Sensor||E || || Hideki || 12<br />
|-<br />
|Lacrosse TX2/TX3 Sensoren||E || || CUL_TX || 8<br />
|-<br />
|TFA 30320902||E || || SD_WS07 || 7<br />
|-<br />
|Eurochron eas800z||E || || SD_WS07 || 7<br />
|-<br />
|Technoline WS6750/TX70DTH||E || || SD_WS07 || 7<br />
|-<br />
|FreeTec Außenmodul NC-7344||E || || SD_WS07 || 7<br />
|-<br />
|CTW600||E || || SD_WS09 || 9<br />
|-<br />
|WH1080||E || || SD_WS09 || 9<br />
|-<br />
|Visivon remote pt4450||E || || none || 24<br />
|-<br />
|Einhell HS 434/6||E || || none || 21<br />
|-<br />
|Flamingo FA20RF / FA21RF Rauchmelder||E || || none || 13<br />
|-<br />
|mumbi m-FS300||E || || none || 26,27<br />
|-<br />
|TFA 30.3200||E || || none || 33<br />
|-<br />
|Livolo||E|| || none || 20<br />
|-<br />
|Smartwares SH5-TSO-A||E S|| || IT || ?<br />
|-<br />
|X10 Security Devices||E|| || || 39<br />
|-<br />
|[[Somfy_via_SIGNALduino|Somfy RTS]]||E S|| || SOMFY || 43<br />
|}<br />
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 <br />
:<code>attr <Funksteckdose> ITclock 300</code> <br />
gesetzt werden, der Standardwert ist 250.<br />
<br />
==== Mein Gerät wird in FHEM nicht erkannt ====<br />
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:<br />
<br />
2. Eröffnet ein Thema unter [https://github.com/RFD-FHEM/RFFHEM/issues github] nach folgendem Muster:<br />
:''Thema : Protokoll für <Das verwendete Gerät><br />
:Inhalt: Eure Hardware z.B. Arduino Nano mit XYZ Empfänger, oder Arduino Nano direkt an Gerät x<br />
<br />
3. Auszug aus dem Logfile, welches zum Gerät gehört.<br />
:''Alles was ihr sonst noch über das Gerät und die übertragenen Daten wisst.<br />
<br />
Alternativ könnt ihr auch im Forum posten. Um einzelne Erweiterungen besser im Überblick zu behalten, eignet sich das github jedoch besser.<br />
<br />
==== Es wird ein Protokoll erkannt, Autocreate legt aber kein device an ====<br />
Im SIGNALduino sind >30 Protokolle implementiert. Jedoch gibt es nur wenige Module, welche diese Protokolle verarbeiten.<br />
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.<br />
<br />
Nehmen wir an, wir haben einen Schalter. Dieser kann einen oder zwei Zustände senden.<br />
Im FHEM Log tauchen Meldungen ähnlich dieser auf<br />
<br />
<code><br />
2015.11.15 15:52:23 4: SIGNALduino_unknown incomming msg: u85#FF8081<br />
</code><br />
<br />
Wir können mit Hilfe des Modules DOIF auf diese Nachricht eine Aktion ausführen:<br />
<br />
Entweder, wenn wir den Inhalt der Nachricht nur zu teilen wissen, da er sich ändert:<br />
<code><br />
define mydoif DOIF ([sduino:&DMSG] =~ "u85#FF8081") (set Lamp on)<br />
attr mydoif do always<br />
</code><br />
<br />
Oder, wenn wir den Inhalt exakt kennen, dann auch als Vergleichsstring<br />
<code><br />
define mydoif DOIF ([sduino:&DMSG] eq "u85#FF8081") (set relais on)<br />
attr mydoif do always<br />
</code><br />
<br />
Der Teil u85#FF8081 muss individuell angepasst werden, der Name eures SIGNALduino möglicherweise auch.<br />
<br />
=== Das Logfile ===<br />
Im Logfile ab [[Verbose]] 4 tauchen diverse Meldungen auf, deren Bedeutung kurz erläutert wird (verbose 3 unterdrückt diese Meldungen).<br />
<br />
Die Protokolle (von der SIGNALDuino-Firmware gesendete Signal-Beschreibungs-Strings) können wie folgt unterschieden werden:<br />
<br />
*MS - Nachricht mit Sync Puls: Hierzu ein Beispiel<br />
:<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 "1" also P1 mit 395 Mikrosekunden high (die Zeitdauer ergibt sich aufgrund der Mitteilung "P1=395") und anschließend ein Signal "5" also P5 mit 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.<br />
<br />
*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.<br />
:<code>MC;LL=-1066;LH=904;SL=-562;SH=385;D=332B4B4D54D5554B552CD2D554B2B5354A;C=429;</code><br />
<br />
*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.<br />
:<code>MU;P0=1372;P1=-580;P2=362;P3=-1047;D=01212321212321212121212121212123212123212321232121212121212321;CP=2;</code><br />
<br />
Es erscheinen viele Meldungen dieser Art:<br />
<br />
<pre><br />
Fingerprint for MU Protocol id xxxx -> yyy matches, trying to demodulate<br />
sduino: Starting demodulation at Position 1<br />
Fingerprint for MU Protocol id 28 -> IC Ledspot matches, trying to demodulate<br />
sduino: Starting demodulation at Position 1<br />
Fingerprint for MU Protocol id 29 -> HT12e remote matches, trying to demodulate<br />
</pre><br />
<br />
Dies sind nun Bemühungen, anhand der von der SIGNALDuino-Firmware gelieferten rohen aber detaillierten Signal-Strings eine Vor-Analyse / Fingerprinting vorzunehmen.<br />
Man könnte nun z.B. bei solchen Fingerprinting-Analysen erkennen:<br />
* dass der Basis-Takt-Wert innerhalb eines charakteristischen Zeit-Bereichs liegt<br />
* dass die Anzahl der Sync-Pulse eine präzise Zahl ist<br />
* dass Längen erkannter Puls-Typen innerhalb eines Bereichs liegen<br />
<br />
Mittels solcher Untersuchungen kann man also final hoffentlich hinreichend plausibel feststellen, "dass diese Aktivitäten offensichtlich(?) zu einer Funk-Komponente Rauchmelder von Hersteller XYZ gehören müssen, und man somit weiterleiten muss an ein (möglicherweise bereits existierendes) Userdaten-Dekodier-Modul für diese Herstellerkomponente".<br />
<br />
<br />
Bei einer dann erfolgenden Demodulation des noch rohen SIGNALDuino-Strings könnte man z.B. (hoffentlich richtigerweise) annehmen, dass eine Signalpegel-Typ-Folge "13" eine binäre 1 bedeuten soll, während eine Folge "12" eine binäre 0 bedeuten soll. Man erhält aus dem Gesamt-Puls-String also nach vollständiger Demodulation eine Abfolge von vielen 0/1 Bits, die insgesamt ein Datenwort darstellen, mit einer gewissen Länge von NN bits (diese Längen-Angabe könnte übrigens - neben Namenssuche nach Hersteller oder Produkt etc. - ein wichtiges Such-Merkmal sein, ob andere Frameworks tatsächlich bereits wissen, wie Daten dieser Funk-Komponente zu dekodieren sind!). Dieses demodulierte Datenwort ist nun das finale Datenwort, welches einen Container für die Funk-Komponenten-Informationen darstellt (in diesem Container also beispielsweise enthalten: Temperatur, Feuchte, Akku-Status, ID, Alarm, ... - zumindest wenn nicht dummerweise der ganze Container erst einmal CRC- oder Crypto-verschlüsselt ist...).<br />
<br />
Man muss an dieser Stelle unbedingt sagen, dass dieses Userdaten-Datenwort (einer bestimmten Hersteller-Funk-Komponente!) natürlich bei ''jeglichen'' Transceiver-Systemen ''immer'' gleich erkannt werden ''muss'' - an dieser Stelle ist also ganz klar, dass diese Daten an ''allgemeine'' FHEM-Module weitergeleitet (Dispatched) werden müssen, die nach Übernahme von Daten von ''jeglichen'' Transceiver-Systemen diese Daten immer auf die gleiche Weise ('''''generisch/zentral''''') für die jeweilige Hersteller-Funk-Komponente erledigen.<br />
<br />
Die Abfolge ist also ganz klar:<br />
Funk-Aktivität --> Transceiver-Gerät/Firmware (SIGNALDuino) --> maximal detailreich beschreibender Rx-Analyse-Output-String --> Fingerprinting-Grobzuordnung des (SIGNALDuino-Firmware-)Outputs (durch 00_SIGNALduino.pm) auf gerätespezifisches Verhalten --> generische/zentrale Dekodierung des gerätespezifischen Protokoll-Datenworts, in zentralen Grundsatz-Modulen wie z.B. <code>14_SD_WS.pm</code>).<br />
<br />
Und wenn dann bei einer solchen Schritte-Abfolge irgendetwas noch fehlen/unpassend sein sollte, dann muss eben entsprechendes Development an gewissen Stellen erfolgen ;-)<br />
<br />
====Minimieren (whitelist/blacklist) von unerwünschter Kommunikations-Aktivität/Einträgen====<br />
<br />
"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 (oder kein Weiterleitungs-Dispatch zu einem bereits existierenden), welches diese Daten jetzt in ihre Bedeutung umwandeln kann. <br />
:<code>sduino: Unknown code u1FFFFF0, help me!</code><br />
<br />
Außerdem kommt es gehäuft zu Logmeldungen und auch Events in ähnlicher Form:<br />
:<code>SIGNALduino_unknown incomming msg: u85#FF8081</code><br />
<br />
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.<br />
<br />
Derartige Einträge können mit dem Attribut WhitelistID minimiert werden. Dabei werden die Geräte, die nach Daten-Empfang tatsächlich verarbeitet werden sollen (also welche Protokolle vom FHEM Modul berücksichtigt werden), mit ihrer Protokollnummer in die WhitelistID aufgenommen.<br />
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. <br />
Die Protokollnummer kann Tabelle [[#Unterst.C3.BCtzte_Ger.C3.A4te]] 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>).<br />
{{Randnotiz|RNTyp=r|RNText=Achtung Schreibweise: Dokumentation oft als WhitelistID o.ä., aber Name ist whitelist_IDs!!<br />
}}<br />
Die Angabe erfolgt durch Komma getrennt: z.B.:<br />
:<code>1,2,5,10</code><br />
<br />
=== Senden mit dem SIGNALduino ===<br />
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:<br />
<br />
<code><br />
set sduino sendMsg P3#00111010#R4<br />
</code><br />
<br />
Dieser Befehl moduliert die Bitfolge 00111010 mittels Protokoll #3 und wiederholt die Nachricht 4x.<br />
Die Protokoll Nummer kann aus einer empfangenen Nachricht extrahiert werden. Ebenso die Bits.<br />
<code><br />
sduino: extracted data 00111010 (bin)<br />
sduino: Found Protocol id 3 <br />
</code><br />
<br />
Alternativ kann das Signal auch in einer "rohform" angegeben werden. Dies ist manchmal in speziellen Fällen notwendig:<br />
<code><br />
set sduino raw SR;;R=3;;P0=4742;;P1=-1554;;P2=286;;P3=-786;;P4=649;;P5=-420;;D=0123234545234545452323232323454523234523454523232345454523232323452345234523452345;;<br />
</code><br />
<br />
R=3 bedeutet, das Signal wird 3x gesendet.<br />
Die Übertragung besteht aus den in D angegeben Pulsen, welche in P0-P5 definiert werden.<br />
Die Daten kann man aus einer empfangenen MS oder MU Nachricht extrahieren.<br />
<br />
Alternativ kann ab Version 3.2 auch eine vereinfachte Form eingegeben werden.<br />
<br />
== Fehlerbehandlung ==<br />
Der SIGNALduino kann mit folgendem Befehl auf Werkseinstellungen zurückgesetzt werden:<br />
:<code>get raw e</code><br />
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.<br />
<br />
In der Firmware sind die folgenden Befehle eingebaut<br />
<br />
*:<code>get raw C<reg></code><br />
<reg> is a (two digit) hex number: return the value of the cc1101 register. <reg>=99 dumps the first 48 registers.<br />
Example: C35 -> C35 = 0D<br />
*:<code>get raw e</code><br />
EEPROM / factory reset. resets all eeprom values without reboot<br />
*:<code>get raw r<AA></code><br />
Read eeprom (da das "R" beim SIGNALDuino bereits mit freeram belegt ist, habe ich das "r" verwendet)<br />
*:<code>get raw r<AA>n</code><br />
Read 16 byte from eeprom (z.B. r00n)<br />
*:<code>get raw W<AA><DD></code><br />
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)<br />
<br />
Die Sendeleistung lässt sich mit <br />
:<code>get sduino ccreg 3E</code><br />
<br />
prüfen, wobei die Rückmeldung wie folgt zu lesen ist: <br />
"-10_dBm" => '34',<br />
"-5_dBm" => '68',<br />
"0_dBm" => '60',<br />
"5_dBm" => '84',<br />
"7_dBm" => 'C8',<br />
"10_dBm" => 'C0' <br />
Dabei wird die Sendeleistung dauerhaft mit dem Befehl<br />
:<code>set sduino cc1101_patable <value></code><br />
hochgeschaltet (<value> durch den Wert ersetzen).<br />
<br />
Weitere Firmware-Befehle sind im Thread-Beitrag {{Link2Forum|Topic=58396|Message=497921}} zu finden.<br />
<br />
== Foren Links ==<br />
* {{Link2Forum|Topic=38402|LinkText=Forenthread - Ankündigung}}<br />
* {{Link2Forum|Topic=58396|LinkText=SIGNALDuino Empfänger Firm- und Hardware}}<br />
* {{Link2Forum|Topic=58397|LinkText=Signalduino Entwicklung Version 3.3.1 }}<br />
* [http://www.rflink.nl/blog2/wiring Beschreibung zu diversen Empfängern und Verbesserung der Empfangsleistung]<br />
* [[SIGNALduino in die Arduino Entwicklungsumgebung einbinden]]<br />
* [[Somfy via SIGNALduino]]<br />
<br />
<br />
[[Kategorie:Interfaces]]<br />
[[Kategorie:Arduino]]</div>MGuhttp://wiki.fhem.de/w/index.php?title=SIGNALduino&diff=25190SIGNALduino2018-02-10T16:57:01Z<p>MGu: Link aktualisiert</p>
<hr />
<div>{{Infobox Modul<br />
|ModPurpose=Empfang und Verarbeitung von digitalen Signalen<br />
|ModType=d<br />
|ModFTopic=38402<br />
|ModCmdRef=SIGNALduino<br />
|ModForumArea=Sonstige Systeme<br />
|ModTechName=00_SIGNALduino.pm<br />
|ModOwner=Sidey ({{Link2FU|8018|Forum}}/[[Benutzer Diskussion:Sidey|Wiki]])<br />
}}<br />
<br />
== Einleitung ==<br />
=== Übersicht ===<br />
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.<br />
<br />
Der SIGNALduino(-Stick) erkennt Signale anhand von Mustern und gibt sie (als maximal detaillierte Beschreibung einer Signalabfolge) dann schlicht sofort nur noch an FHEM zur Auswertung (Dekodierung) weiter. Auch nicht erkannte Signale werden an FHEM übergeben.<br />
Aufgabe des SIGNALduino (Firmware/Stick) ist es also nur, Signal-Aktivitäten zu erfassen und maximal präzise (als kurzer Text-String) zu beschreiben.<br />
Alles weitere (echte, finale Auswertung / Zuweisung dieser Signal-Daten) wird dann auf einer großen Box (Raspberry o.ä.) gemacht.<br />
<br />
=== Vorteil gegenüber einem CUL/FHEMduino ===<br />
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 (also auf flexibel direkt updatebarer Rechner-Seite!!). Änderungen am Arduino-Firmware-Code sind normalerweise nicht notwendig (sofern die grundsätzliche Signal-Klassifizierung des Sticks korrekt funktioniert - leider nicht immer, z.B.: [https://github.com/RFD-FHEM/SIGNALDuino/issues/65 MU-Nachrichten werden z.T. als MC erkannt]).<br />
<br />
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.<br />
<br />
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.<br />
<br />
== Hardware ==<br />
<br />
Der SIGNALduino (Hardware) wird über den USB Port angeschlossen, er kann aber auch mit zusätzlichen ESP Modulen über ein WLAN angebunden werden. <br />
<br />
Der SIGNALduino basiert auf einem [http://arduino.cc/de/Main/ArduinoBoardNano Arduino Nano], die Schaltung entspricht der des [[FHEMduino]] oder dem [[Selbstbau_CUL]]:<br />
* Entweder wird ein Arduino mit einfachen Sende- und Empfangsmodulen verwendet, dann ist die Verkabelung identisch zum [[FHEMduino]] <br />
* Oder es wird ein CC1101 Transceiver verwendet, dann ist die Verkabelung identisch zum [[Selbstbau_CUL]].<br />
* Zuletzt gibt es ein fertig konfektioniertes Modul von In-Circuit mit Radino CC1101 Varianten, link zum [http://shop.in-circuit.de/index.php Hersteller]. <br />
<br />
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. <br />
<br />
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.<br />
<br />
Es gibt auch eine Variante des SIGNALduino, die auf einem [[ESP8266]] nativ läuft, diese funktioniert seit Anfang 2018 annehmbar, allerdings befindet diese sich noch in einer Entwicklungsphase.<br />
<br />
An den "SIGNALESP" kann auch ein CC1101 via SPI angebunden werden:<br />
<br />
{||<br />
!CC1101 Bezeichnung<br />
!ESP Pin<br />
|-<br />
|CLK||GPIO14<br />
|-<br />
|MOSI||GPIO13<br />
|-<br />
|MISO||GPIO12<br />
|-<br />
|CSN||GPIO15<br />
|-<br />
|GDO0||GPIO4<br />
|-<br />
|GDO2||GPIO5<br />
|}<br />
<br />
<br />
Wird ein einfacher Empfänger / Sender Kombination verwendet, dann über die PINs:<br />
<br />
{||<br />
! Bezeichnung <br />
! ESP Pin<br />
|-<br />
|Transmitter||GPIO4<br />
|-<br />
|Receiver||GPIO5<br />
|}<br />
<br />
=== Einfache Module ===<br />
<br />
[[Datei:Fhemduino_schematic.png|200px|thumb|right|Beispielschaltplan SIGNAL(FHEM)duino]] <br />
<br />
Mit einem Arduino-Nano und folgenden, billigen Sende- und Empfangsmodulen können Sie einen SIGNALduino bauen:<br />
* FS1000A Dies ist das Sendemodul (TX) und wird oft im Set mit dem billigen XY-MK-5V-Empfänger angeboten (etwa 5€). <br />
* RXB6 Das ist das empfohlene Empfangsmodul (RX), statt XY-MK-5V, etwa 5€ aus Deutschland.<br />
<br />
Die Verkabelung erfolgt analog zum [[FHEMduino]] und das bedeutet (Arduino -> Modul):<br />
* PIN D2 an DATA des RX-Moduls<br />
* PIN D11 an DATA des TX-Moduls (PIN links mit Beschriftung ATAD)<br />
<br />
Zusätzlich muss noch jeweils GND und 5V des Arduino mit dem GND bzw. VCC des Moduls verbunden werden.<br />
<br />
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).<br />
<br />
== Software: Modul ==<br />
<br />
=== USB-ID ermitteln ===<br />
Bevor der SIGNALduino mit dem FHEM Server (im Beispiel hier ein Raspberry PI) verbunden werden kann, muss die USB-Schnittstelle ermittelt werden. Hierzu bitte auf dem Terminal den Befehl<br />
<pre> ls -l /dev/serial/by-id </pre><br />
ausführen. Beispielhaft sieht das Ergebnis etwa so aus: <br />
''lrwxrwxrwx 1 root root 13 Jan 31 00:02 '''usb-FTDI_FT232R_USB_UART_A903N5T5-if00-port''' -> ../../ttyUSB0'' <br />
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.<br />
<br />
=== FHEM-Modul laden ===<br />
Die SIGNALduino Module werden über das FHEM [[update]] verteilt, sobald die Änderungen einen "stabilen" und alltags tauglichen Zustand haben.<br />
<br />
Die in der Entwicklung befindliche Version kann mit folgenden Befehlen geladen werden:<br />
<br />
* FHEM aktualisieren: <code>update</code> <br />
* 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<br />
*Danach kann das Gerät wie folgt definiert werden (die Spezifikation des USB-Anschlusses muss dabei an die aktuellen Gegebenheiten angepasst werden):<br />
:<code>define <eigener-SIGNALduino-Name> SIGNALduino /dev/serial/by-id/usb-FTDI_FT232R_USB_UART_A903N5T5-if00-port0@57600</code><br />
Nach dem Einbinden wird der SIGNALduino, falls er erkannt wird, im Status "Opened" angezeigt. <br />
<br />
Für neuere Entwicklungen kann in FHEM auch dauerhaft die developer Version aktualisiert werden:<br />
<code>update add <nowiki>https://raw.githubusercontent.com/RFD-FHEM/RFFHEM/dev-r33/controls_signalduino.txt</nowiki></code> <br />
Danach wird FHEM bei dem normalen Update-Befehl immer automatisch die aktuelle dev Version laden.<br />
<br />
Die nachfolgenden Beispiel-Befehle verwenden "sduino" als <eigener-SIGNALduino-Name>.<br />
<br />
==== Flashen des Arduino mit der SIGNALduino Firmware ====<br />
Falls avrdude noch nicht vorhanden ist, kann es mit folgendem Befehl installiert werden:<br />
:<code>sudo apt-get install avrdude</code><br />
<br />
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<br />
<code>attr sduino hardware nanoCC1101</code><br />
sonst üblicherweise<br />
<code>attr sduino hardware nano328</code><br />
<br />
Anschließend kann der ''flash'' Befehl abgesetzt werden: <br />
<code>set sduino flash </code><br />
Dadurch wird der Arduino mit der gewählten Firmware geflasht. Das Ergebnis wird im Webinterface direkt angezeigt.<br />
<br />
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:<br />
:<code>set sduino flash FHEM/firmware/SIGNALduino_mega2560.hex</code><br />
(je nachdem wo und unter welchem Namen die .hex Datei abgelegt wurde)<br />
<br />
==== Flashen einer Firmware über HTTP ====<br />
Die Firmware wird in absehbarer Zeit nicht mehr über den Update Mechanismus verteilt werden. <br />
Damit die passende Firmware auf den SIGNALduiono geladen werden kann, wird diese dann über HTTP geladen.<br />
<br />
==== Vorabversion einer Firmware ====<br />
Die Firmware des SIGNALduino wird ebenso wie das FHEM Modul auch weiter entwickelt.<br />
Die Entwickler sind auf Tests und Rückmeldungen der Nutzer angewiesen, da leider nicht alle Sensoren vorher getestet werden können.<br />
<br />
Aktuell (Anfang 2018) ist noch die Version 3.3.1 in Entwicklung. Diese steht aktuell in einer Release Candidate Version zur Verfügung.<br />
<br />
Für die Folgenden Microcontroller kann man die Firmware downloaden.<br />
<br />
SIGNALDuino_nanoCC1101-331rc2.hex für einen Nano mit CC1101<br />
<code>set sduino flash https://drive.google.com/uc?export=download&id=1sIac8-Qhts4c7OEkFH72Lv6hhgbOadFQ<br />
</code><br />
<br />
SIGNALDuino_nano_331rc2.hex für einen Nano ohne cc1101<br />
<code>set sduino flash https://drive.google.com/uc?export=download&id=1FnnIjJhBI1mjxZKzMnNtnnYzHChyn0lk<br />
</code><br />
<br />
SIGNALDuino_promini_331rc2.hex für einen promini ohne cc1101<br />
<code>set sduino flash https://drive.google.com/uc?export=download&id=1-AJKmO2DjQPi9_O3XI6KqvE9oYLHOyl8<br />
</code><br />
<br />
<br />
SIGNALESP_331rc2.bin (mit cc1101) für einen ESP8266<br />
<code>set ipduino flash https://drive.google.com/uc?export=download&id=1V8ZfLnRnskc64XZkfL-qwmI7AsSd6KRG<br />
</code><br />
!Achtung, aktuell wird die Firmware für den ESP dadurch nur herunter geladen. Flashen müsst ihr leider immer noch über ein passendes Tool <br />
z.B. "ESP8266Flasher.exe" oder Esptool und einer seriellen Konsole.<br />
<br />
Nach dem Booten des ESPs, spannt dieser ein eigenes WLAN auf. Habt ihr euch damit verbunden, könnt ihr den ESP mit eurem vorhandenen WLAN verbinden.<br />
<br />
==== Flashen eines radino Boards mit ATmega32U4 ====<br />
<br />
Diese Funktion steht nur in der Entwicklungsversion dev-r33 zur Verfügung:<br />
Das Radino Board muss derzeit noch mit Angabe des Dateinamens geflasht werden:<br />
<code>set sduino flash FHEM/firmware/SIGNALDuino_radinoCC1101.hex</code><br />
<br />
Auch sind Berichte bekannt, dass der Radino beim Neustart von FHEM nicht korrekt initialisiert wird.<br />
<br />
=== Geräteerkennung ===<br />
==== Unterstützte Geräte ====<br />
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.<br />
{|class="wikitable"<br />
! style="text-align:left;"| Produkt <br />
! (E)mpfangen<br />(S)enden <br />
! Hinweise <br />
! Verwendetes Modul <br />
! Protokoll ID<br />
|-<br />
|TCM Wetterstation (97001 und 21xxx Serie)||E|| || CUL_TCM97001 || 0<br />
|-<br />
|ABS Wetterstation (ABS 700)||E|| || CUL_TCM97001 || 0<br />
|-<br />
|Prologue Wetterstation ||E|| ||CUL_TCM97001 || 0<br />
|-<br />
|Rubicson Wetterstation ||E|| ||CUL_TCM97001 ||0 <br />
|-<br />
|NC_WS Wetterstation ||E|| ||CUL_TCM97001 || 0<br />
|-<br />
|[http://www.gt-support.de/ GT-WT-02 Wetterstation]||E|| ||CUL_TCM97001 || 0<br />
|-<br />
|AURIOL Wetterstation ||E|| ||CUL_TCM97001 || 0<br />
|-<br />
|Mebus Wetterstation ||E|| ||CUL_TCM97001 || 0<br />
|-<br />
|Intertechno Funkschalter||E S|| ||IT || 3,4,5,17<br />
|-<br />
|<strike>Conrad RSL Funkschalter</strike>||E S|| Funktioniert aktuell nicht || SIGNALduino_RSL || <br />
|-<br />
|[http://global.oregonscientific.com/product_view.php?id=5 Oregon Scientific Wettersensoren]||E || Protokoll V2 & V3 implementiert || OREGON || 10<br />
|-<br />
|Bresser Temp/Hydro Sensor||E || || Hideki || 12<br />
|-<br />
|[https://de.hama.com/00104985/hama-aussensensor-ts33c-fuer-wetterstation Hama TS33C]||E || || Hideki || 12<br />
|-<br />
|TFA Temp/Hydro Sensor||E || || Hideki || 12<br />
|-<br />
|Lacrosse TX2/TX3 Sensoren||E || || CUL_TX || 8<br />
|-<br />
|TFA 30320902||E || || SD_WS07 || 7<br />
|-<br />
|Eurochron eas800z||E || || SD_WS07 || 7<br />
|-<br />
|Technoline WS6750/TX70DTH||E || || SD_WS07 || 7<br />
|-<br />
|FreeTec Außenmodul NC-7344||E || || SD_WS07 || 7<br />
|-<br />
|CTW600||E || || SD_WS09 || 9<br />
|-<br />
|WH1080||E || || SD_WS09 || 9<br />
|-<br />
|Visivon remote pt4450||E || || none || 24<br />
|-<br />
|Einhell HS 434/6||E || || none || 21<br />
|-<br />
|Flamingo FA20RF / FA21RF Rauchmelder||E || || none || 13<br />
|-<br />
|mumbi m-FS300||E || || none || 26,27<br />
|-<br />
|TFA 30.3200||E || || none || 33<br />
|-<br />
|Livolo||E|| || none || 20<br />
|-<br />
|Smartwares SH5-TSO-A||E S|| || IT || ?<br />
|-<br />
|X10 Security Devices||E|| || || 39<br />
|-<br />
|[[Somfy_via_SIGNALduino|Somfy RTS]]||E S|| || SOMFY || 43<br />
|}<br />
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 <br />
:<code>attr <Funksteckdose> ITclock 300</code> <br />
gesetzt werden, der Standardwert ist 250.<br />
<br />
==== Mein Gerät wird in FHEM nicht erkannt ====<br />
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:<br />
<br />
2. Eröffnet ein Thema unter [https://github.com/RFD-FHEM/RFFHEM/issues github] nach folgendem Muster:<br />
:''Thema : Protokoll für <Das verwendete Gerät><br />
:Inhalt: Eure Hardware z.B. Arduino Nano mit XYZ Empfänger, oder Arduino Nano direkt an Gerät x<br />
<br />
3. Auszug aus dem Logfile, welches zum Gerät gehört.<br />
:''Alles was ihr sonst noch über das Gerät und die übertragenen Daten wisst.<br />
<br />
Alternativ könnt ihr auch im Forum posten. Um einzelne Erweiterungen besser im Überblick zu behalten, eignet sich das github jedoch besser.<br />
<br />
==== Es wird ein Protokoll erkannt, Autocreate legt aber kein device an ====<br />
Im SIGNALduino sind >30 Protokolle implementiert. Jedoch gibt es nur wenige Module, welche diese Protokolle verarbeiten.<br />
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.<br />
<br />
Nehmen wir an, wir haben einen Schalter. Dieser kann einen oder zwei Zustände senden.<br />
Im FHEM Log tauchen Meldungen ähnlich dieser auf<br />
<br />
<code><br />
2015.11.15 15:52:23 4: SIGNALduino_unknown incomming msg: u85#FF8081<br />
</code><br />
<br />
Wir können mit Hilfe des Modules DOIF auf diese Nachricht eine Aktion ausführen:<br />
<br />
Entweder, wenn wir den Inhalt der Nachricht nur zu teilen wissen, da er sich ändert:<br />
<code><br />
define mydoif DOIF ([sduino:&DMSG] =~ "u85#FF8081") (set Lamp on)<br />
attr mydoif do always<br />
</code><br />
<br />
Oder, wenn wir den Inhalt exakt kennen, dann auch als Vergleichsstring<br />
<code><br />
define mydoif DOIF ([sduino:&DMSG] eq "u85#FF8081") (set relais on)<br />
attr mydoif do always<br />
</code><br />
<br />
Der Teil u85#FF8081 muss individuell angepasst werden, der Name eures SIGNALduino möglicherweise auch.<br />
<br />
=== Das Logfile ===<br />
Im Logfile ab [[Verbose]] 4 tauchen diverse Meldungen auf, deren Bedeutung kurz erläutert wird (verbose 3 unterdrückt diese Meldungen).<br />
<br />
Die Protokolle (von der SIGNALDuino-Firmware gesendete Signal-Beschreibungs-Strings) können wie folgt unterschieden werden:<br />
<br />
*MS - Nachricht mit Sync Puls: Hierzu ein Beispiel<br />
:<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 "1" also P1 mit 395 Mikrosekunden high (die Zeitdauer ergibt sich aufgrund der Mitteilung "P1=395") und anschließend ein Signal "5" also P5 mit 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.<br />
<br />
*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.<br />
:<code>MC;LL=-1066;LH=904;SL=-562;SH=385;D=332B4B4D54D5554B552CD2D554B2B5354A;C=429;</code><br />
<br />
*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.<br />
:<code>MU;P0=1372;P1=-580;P2=362;P3=-1047;D=01212321212321212121212121212123212123212321232121212121212321;CP=2;</code><br />
<br />
Es erscheinen viele Meldungen dieser Art:<br />
<br />
<pre><br />
Fingerprint for MU Protocol id xxxx -> yyy matches, trying to demodulate<br />
sduino: Starting demodulation at Position 1<br />
Fingerprint for MU Protocol id 28 -> IC Ledspot matches, trying to demodulate<br />
sduino: Starting demodulation at Position 1<br />
Fingerprint for MU Protocol id 29 -> HT12e remote matches, trying to demodulate<br />
</pre><br />
<br />
Dies sind nun Bemühungen, anhand der von der SIGNALDuino-Firmware gelieferten rohen aber detaillierten Signal-Strings eine Vor-Analyse / Fingerprinting vorzunehmen.<br />
Man könnte nun z.B. bei solchen Fingerprinting-Analysen erkennen:<br />
* dass der Basis-Takt-Wert innerhalb eines charakteristischen Zeit-Bereichs liegt<br />
* dass die Anzahl der Sync-Pulse eine präzise Zahl ist<br />
* dass Längen erkannter Puls-Typen innerhalb eines Bereichs liegen<br />
<br />
Mittels solcher Untersuchungen kann man also final hoffentlich hinreichend plausibel feststellen, "dass diese Aktivitäten offensichtlich(?) zu einer Funk-Komponente Rauchmelder von Hersteller XYZ gehören müssen, und man somit weiterleiten muss an ein (möglicherweise bereits existierendes) Userdaten-Dekodier-Modul für diese Herstellerkomponente".<br />
<br />
<br />
Bei einer dann erfolgenden Demodulation des noch rohen SIGNALDuino-Strings könnte man z.B. (hoffentlich richtigerweise) annehmen, dass eine Signalpegel-Typ-Folge "13" eine binäre 1 bedeuten soll, während eine Folge "12" eine binäre 0 bedeuten soll. Man erhält aus dem Gesamt-Puls-String also nach vollständiger Demodulation eine Abfolge von vielen 0/1 Bits, die insgesamt ein Datenwort darstellen, mit einer gewissen Länge von NN bits (diese Längen-Angabe könnte übrigens - neben Namenssuche nach Hersteller oder Produkt etc. - ein wichtiges Such-Merkmal sein, ob andere Frameworks tatsächlich bereits wissen, wie Daten dieser Funk-Komponente zu dekodieren sind!). Dieses demodulierte Datenwort ist nun das finale Datenwort, welches einen Container für die Funk-Komponenten-Informationen darstellt (in diesem Container also beispielsweise enthalten: Temperatur, Feuchte, Akku-Status, ID, Alarm, ... - zumindest wenn nicht dummerweise der ganze Container erst einmal CRC- oder Crypto-verschlüsselt ist...).<br />
<br />
Man muss an dieser Stelle unbedingt sagen, dass dieses Userdaten-Datenwort (einer bestimmten Hersteller-Funk-Komponente!) natürlich bei ''jeglichen'' Transceiver-Systemen ''immer'' gleich erkannt werden ''muss'' - an dieser Stelle ist also ganz klar, dass diese Daten an ''allgemeine'' FHEM-Module weitergeleitet (Dispatched) werden müssen, die nach Übernahme von Daten von ''jeglichen'' Transceiver-Systemen diese Daten immer auf die gleiche Weise ('''''generisch/zentral''''') für die jeweilige Hersteller-Funk-Komponente erledigen.<br />
<br />
Die Abfolge ist also ganz klar:<br />
Funk-Aktivität --> Transceiver-Gerät/Firmware (SIGNALDuino) --> maximal detailreich beschreibender Rx-Analyse-Output-String --> Fingerprinting-Grobzuordnung des (SIGNALDuino-Firmware-)Outputs (durch 00_SIGNALduino.pm) auf gerätespezifisches Verhalten --> generische/zentrale Dekodierung des gerätespezifischen Protokoll-Datenworts, in zentralen Grundsatz-Modulen wie z.B. <code>14_SD_WS.pm</code>).<br />
<br />
Und wenn dann bei einer solchen Schritte-Abfolge irgendetwas noch fehlen/unpassend sein sollte, dann muss eben entsprechendes Development an gewissen Stellen erfolgen ;-)<br />
<br />
====Minimieren (whitelist/blacklist) von unerwünschter Kommunikations-Aktivität/Einträgen====<br />
<br />
"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 (oder kein Weiterleitungs-Dispatch zu einem bereits existierenden), welches diese Daten jetzt in ihre Bedeutung umwandeln kann. <br />
:<code>sduino: Unknown code u1FFFFF0, help me!</code><br />
<br />
Außerdem kommt es gehäuft zu Logmeldungen und auch Events in ähnlicher Form:<br />
:<code>SIGNALduino_unknown incomming msg: u85#FF8081</code><br />
<br />
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.<br />
<br />
Derartige Einträge können mit dem Attribut WhitelistID minimiert werden. Dabei werden die Geräte, die nach Daten-Empfang tatsächlich verarbeitet werden sollen (also welche Protokolle vom FHEM Modul berücksichtigt werden), mit ihrer Protokollnummer in die WhitelistID aufgenommen.<br />
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. <br />
Die Protokollnummer kann Tabelle [[#Unterst.C3.BCtzte_Ger.C3.A4te]] 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>).<br />
{{Randnotiz|RNTyp=r|RNText=Achtung Schreibweise: Dokumentation oft als WhitelistID o.ä., aber Name ist whitelist_IDs!!<br />
}}<br />
Die Angabe erfolgt durch Komma getrennt: z.B.:<br />
:<code>1,2,5,10</code><br />
<br />
=== Senden mit dem SIGNALduino ===<br />
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:<br />
<br />
<code><br />
set sduino sendMsg P3#00111010#R4<br />
</code><br />
<br />
Dieser Befehl moduliert die Bitfolge 00111010 mittels Protokoll #3 und wiederholt die Nachricht 4x.<br />
Die Protokoll Nummer kann aus einer empfangenen Nachricht extrahiert werden. Ebenso die Bits.<br />
<code><br />
sduino: extracted data 00111010 (bin)<br />
sduino: Found Protocol id 3 <br />
</code><br />
<br />
Alternativ kann das Signal auch in einer "rohform" angegeben werden. Dies ist manchmal in speziellen Fällen notwendig:<br />
<code><br />
set sduino raw SR;;R=3;;P0=4742;;P1=-1554;;P2=286;;P3=-786;;P4=649;;P5=-420;;D=0123234545234545452323232323454523234523454523232345454523232323452345234523452345;;<br />
</code><br />
<br />
R=3 bedeutet, das Signal wird 3x gesendet.<br />
Die Übertragung besteht aus den in D angegeben Pulsen, welche in P0-P5 definiert werden.<br />
Die Daten kann man aus einer empfangenen MS oder MU Nachricht extrahieren.<br />
<br />
Alternativ kann ab Version 3.2 auch eine vereinfachte Form eingegeben werden.<br />
<br />
== Fehlerbehandlung ==<br />
Der SIGNALduino kann mit folgendem Befehl auf Werkseinstellungen zurückgesetzt werden:<br />
:<code>get raw e</code><br />
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.<br />
<br />
In der Firmware sind die folgenden Befehle eingebaut<br />
<br />
*:<code>get raw C<reg></code><br />
<reg> is a (two digit) hex number: return the value of the cc1101 register. <reg>=99 dumps the first 48 registers.<br />
Example: C35 -> C35 = 0D<br />
*:<code>get raw e</code><br />
EEPROM / factory reset. resets all eeprom values without reboot<br />
*:<code>get raw r<AA></code><br />
Read eeprom (da das "R" beim SIGNALDuino bereits mit freeram belegt ist, habe ich das "r" verwendet)<br />
*:<code>get raw r<AA>n</code><br />
Read 16 byte from eeprom (z.B. r00n)<br />
*:<code>get raw W<AA><DD></code><br />
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)<br />
<br />
Die Sendeleistung lässt sich mit <br />
:<code>get sduino ccreg 3E</code><br />
<br />
prüfen, wobei die Rückmeldung wie folgt zu lesen ist: <br />
"-10_dBm" => '34',<br />
"-5_dBm" => '68',<br />
"0_dBm" => '60',<br />
"5_dBm" => '84',<br />
"7_dBm" => 'C8',<br />
"10_dBm" => 'C0' <br />
Dabei wird die Sendeleistung dauerhaft mit dem Befehl<br />
:<code>set sduino cc1101_patable <value></code><br />
hochgeschaltet (<value> durch den Wert ersetzen).<br />
<br />
Weitere Firmware-Befehle sind im Thread-Beitrag {{Link2Forum|Topic=58396|Message=497921}} zu finden.<br />
<br />
== Foren Links ==<br />
* {{Link2Forum|Topic=38402|LinkText=Forenthread - Ankündigung}}<br />
* {{Link2Forum|Topic=58396|LinkText=SIGNALDuino Empfänger Firm- und Hardware}}<br />
* {{Link2Forum|Topic=58397|LinkText=Signalduino Entwicklung Version 3.3.1 }}<br />
* [http://www.rflink.nl/blog2/wiring Beschreibung zu diversen Empfängern und Verbesserung der Empfangsleistung]<br />
* [[SIGNALduino in die Arduino Entwicklungsumgebung einbinden]]<br />
* [[Somfy via SIGNALduino]]<br />
<br />
<br />
[[Kategorie:Interfaces]]<br />
[[Kategorie:Arduino]]</div>MGuhttp://wiki.fhem.de/w/index.php?title=SUNRISE_EL&diff=24482SUNRISE EL2018-01-10T17:52:19Z<p>MGu: /* Steuerung */ Erklärung der Parameter zur Dämmerung</p>
<hr />
<div>{{SEITENTITEL:SUNRISE_EL}}<br />
{{Infobox Modul<br />
|ModPurpose=Funktionen für Sonnenstandsabhängige Aktionen <br />
|ModType=h<br />
<!-- |ModCategory=?? --><br />
|ModCmdRef=SUNRISE_EL<br />
|ModForumArea=Automatisierung<br />
|ModTechName=99_SUNRISE_EL.pm<br />
|ModOwner=rudolfkoenig ({{Link2FU|8|Forum}}] / [[Benutzer Diskussion:Rudolfkoenig|Wiki]])<br />
}}<br />
<br />
Das Hilfsmodul [[SUNRISE_EL]] bietet Funktionen, um Aktionen abhängig von Sonnenauf- und -untergangszeiten durchzuführen.<br />
<br />
== Voraussetzungen ==<br />
In der [[Konfiguration]] (fhem.cfg) muss der gewünschte Standort definiert werden, da der Sonnenauf- und -untergang nicht nur vom Datum, sondern auch vom Längen- und Breitengrad des Standortes abhängig sind. Dazu sind die folgenden Definitionen erforderlich:<br />
:<code>attr global latitude 52.51626 </code><br />
:<code>attr global longitude 13.37778 </code><br />
und zwar in genau dieser Schreibweise. Die Koordinaten können entweder mit Hilfe eines GPS-Systems oder über einen entsprechenden Internet-Dienst ermittelt werden.<br />
<br />
Als Internet-Dienst eignet sich beipielsweise [https://support.google.com/maps/answer/18539?source=gsearch&hl=de Google Maps-Hilfe (Breiten- und Längengrad finden oder eingeben)] oder [http://www.openstreetmap.org/#map=12/52.51626/13.37778 OpenStreetMap]. Die Werte ''latitude'' und ''longitude'' können aus der URL abgelesen werden. In diesem Beispiel ''latitude'' 52.51626 und ''longitude'' 13.37778 (Brandenburger Tor in Berlin).<br />
<br />
== Funktionen ==<br />
Das Modul SUNRISE_EL stellt die folgenden Funktionen zur Verfügung:<br />
* sunrise / sunset geben die absolute Zeit des nächsten Sonnenauf- bzw. -untergangs zurück, wobei 24 Stunden addiert werden, sofern das entsprechende Ereignis am nächsten Tag stattfindet<br />
* sunrise_rel / sunset_rel geben die relative Zeit bis zum nächsten Sonnenauf- bzw. -untergang zurück<br />
* sunrise_abs / sunset_abs geben die absolute Zeit für den aktuellen Tag zurück<br />
Diese Funktionen können jeweils mit einem speziellen und drei weiteren (optionalen) Parametern aufgerufen werden: <br />
: <code>...(offset,min,max)</code><br />
: mit der Bedeutung<br />
:* Horizont; nur einer der Werte REAL, CIVIL, NAUTIC, ASTRONOMIC (in genau dieser Schreibweise) bzw. HORIZON= ist erlaubt<br />
:* offset = Sekunden (Ganzzahl), die auf die Zeit addiert werden<br />
:* min = frühester Zeitpunkt (in Stunden:Minuten - hh:mm), der zurückgegeben werden soll<br />
:* max = spätester Zeitpunkt (in Stunden:Minuten - hh:mm), der zurückgegeben werden soll<br />
* isday() kann benutzt werden um festzustellen, ob der aktuelle Zeitpunkt nach Sonnenauf- aber vor Sonnenuntergang des aktuellen Tages liegt<br />
<br />
== Steuerung ==<br />
Mittels folgender Anweisungen in der Konfiguration:<br />
Außenlampe - Steuerung An-/Ausschaltzeit<br />
define AussenlampeAn1 at *{sunset(0,"17:00","22:00")} set EG.Diele.Aussenlampe on<br />
define AussenlampeAus1 at *{sunrise(0,"05:00","07:30")} set EG.Diele.Aussenlampe off<br />
<br />
wird der Funk-Lichtschalter für die Außenbeleuchtung (hier das FHEM-Gerät mit dem Namen ''EG.Diele.Aussenlampe'')<br />
<br />
* morgens zum Sonnenaufgang, aber nicht vor 05:00 und nicht nach 07:30 Uhr ausgeschaltet<br />
<br />
und<br />
<br />
* abends zum Sonnenuntergang eingeschaltet, aber nicht vor 17:00 Uhr und nicht nach 22:00 Uhr.<br />
<br />
Im FHEM-Standard wird der sogenannte bürgerliche Sonnenuntergang/-aufgang genutzt, der als Sonnenstand 6 Grad unter der Horizontalen definiert ist (entspricht <code>HORIZON=-6.0</code>). Bis bzw. ab dieser Zeit ist das Lesen ohne zusätzliche Beleuchtung möglich.<br />
<br />
Da dies nicht immer gewünscht ist, ist es möglich bei den sunrise/sunset-Funktionen *optional* als ersten Parameter vorne REAL, CIVIL, NAUTIC, ASTRONOMIC oder z.B. HORIZON=-6.0 oder "HORIZON -6.0" anzustellen.<br />
{| class="wikitable"<br />
! Parameter !! Bedeutung !! entspricht<br />
|-<br />
| <code>"REAL"</code> || Sonne in der Horizontalen || <code>"HORIZON=0.0"</code> <br />
|-<br />
| <code>"CIVIL"</code> || Bürgerliche Dämmerung || <code>"HORIZON=-6.0"</code><br />
|-<br />
| <code>"NAUTIC"</code> || Nautische Dämmerung || <code>"HORIZON=-12.0"</code><br />
|-<br />
| <code>"ASTRONOMIC"</code> || Astronomische Dämmerung || <code>"HORIZON=-16.0"</code><br />
|-<br />
|}<br />
<br />
# Normales Verhalten wie im obigen Beispiel: <br />
{sunset(0,"17:00","22:00")}<br />
Ergebnis (als Beispiel): 19:59:22 <br />
<br />
# Gleiches Beispiel mit CIVIL als 1. Parameter: <br />
{sunset("CIVIL",0,"17:00","22:00")} <br />
Ergebnis (als Beispiel): 19:59:22 <br />
<br />
# Gleiches Beispiel mit Eingabe der Höhe über Horizont als 1. Parameter: <br />
{sunset("HORIZON=-6.0",0,"17:00","22:00")} <br />
Ergebnis (als Beispiel): 19:59:22 <br />
<br />
# Gleiches Beispiel mit dem realen Sonnenuntergang auf 0 Grad als 1. Parameter: <br />
{sunset("REAL",0,"17:00","22:00");;} <br />
Ergebnis (als Beispiel): 19:22:07<br />
<br />
== Kontrolle ==<br />
Um die Zeiten zu kontrollieren können Sie in der FHEM-Befehlszeile den Befehl<br />
<br />
<code><br />
list AussenlampeAn1<br />
</code><br />
<br />
eingeben und mit der &lt;Enter&gt;-Taste (nicht "save-Button") bestätigen. Sie sehen dann (hier eine Ausgabe vom 17.01.2013) z.B. folgendes:<br />
<br />
<nowiki>Internals:<br />
DEF *{sunset(0,&quot;17:00&quot;,&quot;22:00&quot;)} set EG.Diele.Aussenlampe on<br />
NAME AussenlampeAn1<br />
NR 225<br />
NTM 17:37:09<br />
REP -1<br />
STATE Next: 17:37:09<br />
TRIGGERTIME 1358527029<br />
TYPE at<br />
Attributes:<br />
room Diele</nowiki><br />
Der Sonnenuntergang liegt am genannten Tag '''innerhalb''' des Start-/Ende-Zeitraums, so dass die Lampe um 17:37 Uhr eingeschaltet wird.<br />
<br />
Die Ausgabe (gleiches Datum) von<br />
<br />
<code><br />
list AussenlampeAus1<br />
</code><br />
<br />
lautet:<br />
<br />
<nowiki>Internals:<br />
DEF *{sunrise(0,&quot;05:00&quot;,&quot;07:30&quot;)} set EG.Diele.Aussenlampe off<br />
NAME AussenlampeAus1<br />
NR 228<br />
NTM 07:30:00<br />
REP -1<br />
STATE Next: 07:30:00<br />
TRIGGERTIME 1358490600<br />
TYPE at<br />
Attributes:<br />
room Diele</nowiki><br />
Hier liegt der Sonnenaufgang noch '''außerhalb''' des Start-/Ende-Zeitraums, so dass die Lampe um 07:30 Uhr ausgeschaltet wird.<br />
<br />
== Links ==<br />
* Workaround um die Zeiten für Sonnenaufgang und -untergang anpassen zu können: [[Trick der Woche#isday]]<br />
* Diskussion über das Modul im {{Link2Forum|Topic=8527|LinkText=Fhem Forum}}<br />
<br />
== Hinweise ==<br />
* Die ''sunset / sunrise'' Einstellungen arbeiten meist erst '''am nächsten Tag''' richtig. Das hängt zusammen mit einer Falschberechnung beim setzen dieses ''defines''. An einer Korrektur wird gearbeitet (Stand Januar 2013).</div>MGuhttp://wiki.fhem.de/w/index.php?title=CUL_HomeMatic_und_FS20&diff=24156CUL HomeMatic und FS202018-01-02T17:34:03Z<p>MGu: Kategorie fehlte</p>
<hr />
<div>== Frage ==<br />
ist es möglich über FHEM mit einer CUL HomeMatic und FS20 parallel zu betreiben?<br />
<br />
== Antwort ==<br />
Nein. FS20, FHT etc. ist amplitudenmoduliert (AM) und sendet/empfängt mit einer Datenrate von 1 khz, <br />
wärend HomeMatic frequenzmoduliert mit 20 khz Datenrate sendet/empfängt.<br />
<br />
Ein CUL mit culfw kann man '''entweder''' im [[SlowRF]] Mode betreiben, und damit einige<br />
Geraete mit 1kHz Datenrate, AM Modulation empfangen (FS20, S300, FHT, usw) '''oder''' im HomeMatic Mode mit 20kHz Datenrate, FM Modulation, aber nicht beides gleichzeitig.<br />
<br />
Überdies ist in älteren Versionen des CUL (namentlich V2 oder älter) zu wenig Speicherplatz, sodass<br />
die kombinierte culfw für beide Versionen nicht in den Speicher passt. Hier muss man sich dann für eine<br />
speziell auf SlowRF oder HM angepasste Version der culfw entscheiden.<br />
<br />
Es ist aber möglich, FHEM mit 2 CULs, eines im SlowFR (FS20/FHT) Modus und eines mit CUL_HM zu betreiben.<br />
Ebenso kann ein CUL im SlowFR (FS20/FHT) Modus mit einem [[HMLAN Konfigurator]] in Kombination betreiben werden.<br />
<br />
Siehe auch<br />
[http://fhem.de/commandref.html#rfmode]<br />
<br />
[[Kategorie:CUL]]<br />
[[Kategorie:FAQ]]</div>MGuhttp://wiki.fhem.de/w/index.php?title=ReadingsGroup&diff=23987ReadingsGroup2017-12-31T23:39:08Z<p>MGu: Typo</p>
<hr />
<div>{{SEITENTITEL:readingsGroup}}<br />
{{Infobox Modul<br />
|ModPurpose=Einfache zusammenfassende Darstellung von Informationen über mehrere Geräte und deren Steuerung<br />
|ModType=h<br />
|ModCmdRef=readingsGroup<br />
|ModForumArea=Frontends<br />
|ModTechName=33_readingsGroup.pm<br />
|ModOwner=Andre ({{Link2FU|430|Forum}} / [[Benutzer Diskussion:justme|Wiki]])}}<br />
<br />
Das FHEM-[[:Kategorie:Hilfsmodul|Hilfsmodul]] [[readingsGroup]] bietet eine einfache Möglichkeit, <code>Readings</code> (kein Präfix vor dem Reading-Namen), <code>Internals</code> (Präfix "+" vor dem Namen des internen Wertes) und <code>Attributes</code> (Präfix "?" vor dem Namen des Attributs) von einem oder mehreren <code>Devices</code> darzustellen und flexibel zu formatieren.<br />
<br />
Die Aktualisierung im Browserfenster geschieht per <code>longpoll</code> und überträgt nur die jeweils geänderten Zellen. Wenn eine <code>readingsGroup</code> in keinem Browserfenster angezeigt wird, findet keine <code>longpoll</code> Aktualisierung statt.<br />
<br />
== Definition == <br />
Siehe [http://fhem.de/commandref.html#readingsGroup commandref].<br />
<br />
== Attribute ==<br />
{{Randnotiz|RNText=In allen Mappings die einen Hash verwenden muss der Key (das was jeweils links von => Operator steht) in Anführungszeichen stehen. Die einzige Ausnahme hiervon sind Keys die aus einem String bestehen der mit einem Buchstaben beginnt und nur Buchstaben und Zahlen enthält.}}<br />
Weitergehende Erläuterungen zu einzelnen Attributen.<br />
<br />
Die komplette Liste der Attribute ist der commandref zu entnehmen.<br />
<br />
=== noheading ===<br />
[[Datei:ReadingsGroup_noheading.png|mini|rechts|400px|ReadingsGroup: rechts mit "noheading" Attribut, links der anklickbare Titel]]<br />
Das Attribut <code>noheading</code> führt dazu, dass der Alias der ReadingsGroup nicht mehr als Titel angezeigt wird. Das kann wünschenswert sein, wenn die ReadingsGroup auf einer [[Dashboard]]-Seite angezeigt werden soll, hat allerdings den Nachteil, dass die Detail-Ansicht der ReadingsGroup nicht mehr über einen Klick auf den Titel aufgerufen werden kann. Der Einstellungsdialog der ReadingsGroup ist dann nur noch (z.&nbsp;B.) über<br />
* <code>list TYPE=readingsGroup</code><br />
* einen "Probably associated with"-Link eines anderen Objekts oder über<br />
* manuelle Modifikation der URL eines anderen Objekts (<code>http:.../fhem?detail=<objektname></code>)<br />
erreichbar.<br />
<br />
=== nolinks ===<br />
Devicenamen und Titel der readingsGroup verlinken nicht mehr zur zugehörigen Detailansicht und sind nicht mehr anklickbar.<br />
<br />
=== nostate ===<br />
Das state-Reading wird bei regex match nicht berücksichtigt und nicht angezeigt.<br />
<br />
=== notime ===<br />
Es werden keine Timestamps für die Readings angezeigt. Nur für einspaltige readingsGroups sinnvoll.<br />
<br />
=== mapping ===<br />
mapping wird verwendet um Elemente einer Zeile auszutauschen, bspw. um<br />
* den Zeilentitel gegen den Raumnamen auszutauschen (zB. [[ReadingsGroup#Einfache Auswahl über Reading-Namen|einfach]], [[ReadingsGroup#Schriftgrößen, Farben, Icons|doppelt]], [[ReadingsGroup#Reading-Werte zuordnen (Icon / Text)|erweitert]], [[ReadingsGroup#Heizungsteuerung für HM Wand- und Heizkörperthermostate|noch mehr]], [[ReadingsGroup#Enigma Receiver|leer]])<br />
Weitere Anwendungsbeispiele finden sich in den div. Beispielen unten und in der commandref.<br />
<br />
=== valueFormat ===<br />
valueFormat wird klassischerweise dazu genutzt um die dargestellten Werte zu formatieren - bspw. um einem Wert ein Einheitensymbol zu verpassen (zB. [[ReadingsGroup#Ausgabestil (hier rechtsbündig)]]). Man kann valueFormat aber auch für dynamische Darstellungen oder gar kleine Programmierungen "missbrauchen", bspw. um<br />
* einen Wert dynamisch durch ein Symbol zu ersetzen ohne exzessiv [[ReadingsGroup#mapping|mappen]] (s.o.) zu müssen (zB. [[ReadingsGroup#Reading-Werte zuordnen (Icon / Text)|Reading-Werte zuordnen]])<br />
* unerwünschte Werte auszufiltern (zB. [[ReadingsGroup#Inhalte filtern|Inhalte filtern]])<br />
* kleine Berechnungen durchzuführen, ohne diese in [[99_myUtils_anlegen|99_myUtils.pm]] zu erstellen (zB. [[ReadingsGroup#Inhalte berechnen|Inhalte berechnen]])<br />
* größere Berechnungen in [[99_myUtils_anlegen|99_myUtils.pm]] aufzurufen (zB. [[ReadingsGroup#Enigma Receiver|Enigma Receiver]]).<br />
<br />
Weitere Anwendungsbeispiele finden sich in den div. Beispielen unten und in der commandref.<br />
<br />
=== valueIcon ===<br />
valueIcon wird verwendet um einer Zeile zusätzlich ein Symbol hinzuzufügen (zB. [[ReadingsGroup#Auswahl über Reading-Namen, Status als Symbol dargestellt|einfach]], [[ReadingsGroup#Heizungswerte, Status und Regelmöglichkeit|etwas mehr]]).<br />
<br />
Weitere Anwendungsbeispiele finden sich in den div. Beispielen unten und in der commandref.<br />
<br />
=== valueStyle ===<br />
valueStyle wird verwendet um die dargestellten Werte optisch anzupassen (zB. [[ReadingsGroup#Ausgabestil (hier rechtsbündig)|einfach]], [[ReadingsGroup#Internal Values ausgeben|erweitert]], [[ReadingsGroup#Wertabhängige Farbgebung|komplex]]).<br />
<br />
Weitere Anwendungsbeispiele finden sich in den div. Beispielen unten und in der commandref.<br />
<br />
== Beispiele ==<br />
Bitte beachten: die folgenden Beispiele enthalten keine Maskierungen oder Verdoppelungen für ; und Zeilenende, sondern sind so angegeben, wie sie im [[PGM2|Web Interface]] im Befehls-Eingabefeld, nach Klick auf DEF und im Attribut-Eingabefeld eingegeben werden. Beim manuellen Einfügen in eine [[Konfiguration|Konfigurationsdatei]] sind diese Maskierungen oder Verdoppelungen natürlich vorzunehmen.<br />
<br />
=== Einfache Auswahl über Reading-Namen ===<br />
{| class="wikitable"<br />
! Definition !! Erläuterungen !! Aussehen <br />
|-<br />
| style="width:40%" |<code>define battStatus readingsGroup .*:[Bb]attery</code><br />
| Alle readings mit Namen '''Battery''' oder '''battery''' von allen Devices. <br />
| rowspan=3 | [[Datei:rgBattery.png|thumb]]<br />
|-<br />
| <code>attr battStatus alias FHT Batteriestatus </code><br />
| Der Alias wird als Zeilentitel verwendet<br />
|-<br />
| <code>attr battStatus mapping %ROOM </code><br />
| ''Mapping %ROOM'' führt dazu, dass der Raumname als Zeilentitel angezeigt wird.<br />
|}<br />
<br />
=== Übersicht HomeMatic Geräte ===<br />
<br />
<nowiki>define HM_Components readingsGroup <Gerät>,<Name>,<Model>,<S/N> TYPE=CUL_HM:+NAME,?model,D-serialNr</nowiki><br />
<br />
=== Auswahl über Reading-Namen, Status als Symbol dargestellt ===<br />
{| class="wikitable"<br />
! Definition !! Erläuterungen !! Aussehen <br />
|-<br />
| style="width:40%" |<code>define rg_battery readingsGroup .*:battery</code><br />
| Alle readings mit Namen '''battery''' von allen Devices. <br />
| rowspan=4 | [[Datei:rgBattery2.png|thumb]]<br />
|-<br />
| <code>attr rg_battery alias Batteriestatus </code><br />
| Der Alias wird als Überschrift verwendet<br />
|-<br />
| <code>attr rg_battery valueIcon {'battery.ok' => 'batterie', 'battery.low' => 'batterie@red'}</code><br />
| Statt der reading Werte "ok" und "low" soll ein Icon angezeigt werden.<br />
|-<br />
|<code>attr rg_battery commands { "battery.low" => "set %DEVICE replaceBatteryForSec 60" }</code><br />
| Für LaCrosse devices kann man beim Klick auf ein rotes "battery low icon" direkt replaceBatteryForSec setzen.<br />
|}<br />
<br />
=== Reading-Werte zuordnen (Icon / Text) ===<br />
{| class="wikitable"<br />
! Definition !! Erläuterungen !! Aussehen <br />
|-<br />
| style="width:40%" |<code>define rg readingsGroup Contact.Dachboden_gross:sensed.*</code><br />
| Alle sensedreadings des Contact.Dachboden_gross device. <br />
| rowspan=4 | [[Datei:rgFenster.png|thumb]]<br />
|-<br />
| <code>attr rg mapping { 'sensed.A' => 'links', 'sensed.B' => 'rechts' }</code><br />
| Die Zuordnung rechts/links<br />
|-<br />
| <code>attr rg valueFormat {($VALUE eq '1')?"fts_window_roof":"fts_window_roof_open_2"}</code><br />
| Die Zuordnung von reading Wert zu Icon Namen.<br />
|-<br />
| <code>attr rg_battery valueIcon %VALUE </code><br />
| Statt des reading Werts soll ein Icon angezeigt werden.<br />
|}<br />
<br />
=== Formatvorgabe für Ausgabewerte ===<br />
{| class="wikitable"<br />
! Definition !! Erläuterungen !! Aussehen <br />
|-<br />
| style="width:40%" |<code>define TempHygro readingsGroup TYPE=CUL_WS:temperature,humidity,dewpoint</code><br />
| Alle readings mit Namen '''temperature''', '''humidity''', '''dewpoint''' von allen Devices des Typs '''CUL_WS'''<br />
| rowspan=4 | [[Datei:rgTemperatur.png|thumb|[[S300TH]]-Werte in einer readingsGroup]]<br />
|-<br />
| <code>attr TempHygro alias Temperatur / rel. Feuchte / Taupunkt</code><br />
| Der Alias der readingsGroup wird als Überschrift verwendet<br />
|-<br />
| <code>attr TempHygro mapping %ALIAS</code><br />
| ''Mapping %ALIAS'' führt dazu, dass der Alias des Geräts als Zeilentitel angezeigt wird.<br />
|- <br />
| <code>attr TempHygro valueFormat { temperature => "%.1f&amp;deg;C", humidity => "%.1f %%", dewpoint => "%.1f&amp;deg;C"}</code><br />
| Formatierung der Ausgabewerte. '''Achtung:''' "%" die in der Ausgabe erscheinen sollen, müssen verdoppelt werden!<br />
|}<br />
<br />
=== Ausgabestil (hier rechtsbündig) ===<br />
{| class="wikitable"<br />
! Definition !! Erläuterungen !! Aussehen <br />
|-<br />
| style="width:40%" |<code>define Wetter readingsGroup WetterXXX:<%temp_temperature>,<Temperatur>,temperature WetterXXX:<%weather_humidity>,<Luftfeuchte>,humidity WetterXXX:<%weather_barometric_pressure>,<Luftdruck>,pressure<br />
</code><br />
| Die readings mit Namen '''temperature''', '''humidity''' und '''pressure''' vom Device WetterXXX jeweils mit einem Icon und einem Label davor.<br />
| rowspan=3 | [[Datei:rgWetter.png|thumb]]<br />
|-<br />
| <code>attr Wetter valueFormat { temperature => '%1.f &amp;deg;C', humidity => '%1.f %%', pressure => '%i mbar' }</code><br />
| Die Formatierung der Readingswerte<br />
|-<br />
| <code>attr Wetter valueStyle style="text-align:right"</code><br />
| Die Readings sollen rechtsbündig dargestellt werden.<br />
|}<br />
<br />
=== Internal Value ausgeben ===<br />
Diese Beispiel könnte entfallen (nächstes Beispiel ist sehr ähnlich; es wird lediglich ein weiterer Wert ausgegeben).<br />
{| class="wikitable"<br />
! Definition !! Erläuterungen !! Aussehen <br />
|-<br />
| style="width:40%" |<code>define culRSSI readingsGroup cul_RSSI=.*:+cul_RSSI</code><br />
| Den RSSI Wert aller Devices (am IODev ''cul'') die einen solchen haben anzeigen.<br> '''Achtung''': "internal values" werden nicht per longpoll aktualisiert, sondern nur beim Seitenaufbau.<br />
| rowspan=1 | [[Datei:rgculRSSI.png|thumb]]<br />
|}<br />
<br />
=== Internal Values ausgeben ===<br />
{| class="wikitable"<br />
! Definition !! Erläuterungen !! Aussehen <br />
|-<br />
| style="width:40%" |<code>define culRSSI readingsGroup cul_RSSI=.*:+cul_RSSI,+cul_TIME</code><br />
| Den RSSI Wert mit der zugehörigen Zeit aller Devices (am IODev ''cul'') die einen solchen haben anzeigen.<br> '''Achtung''': "internal values" werden nicht per longpoll aktualisiert, sondern nur beim Seitenaufbau.<br>"Internal Values" werden durch das vorangestellte '''+''' (Pluszeichen) identifiziert.<br />
| rowspan=2 | [[Datei:rgculRSSI2.png|thumb]]<br />
|-<br />
|attr culRSSI valueStyle {return undef if($READING =~ m/TIME/); ($VALUE <= -85)?'style="color:red"':($VALUE <= -80)?'style="color:yellow"':undef}<br />
|Schlechte RSSI Werte sollen abhängig von zwei Schwellwerten gelb oder rot eingefärbt werden (auf dem Screenshot nicht zu sehen).<br />
|}<br />
<br />
=== Alle Readings eines Gerätes, mit Ausnahme von... ===<br />
{| class="wikitable"<br />
! Definition !! Erläuterungen !! Aussehen <br />
|-<br />
| style="width:40%" |<code>define Systemstatus readingsGroup sysstat</code><br />
| Alle readings des sysstat Device<br />
| rowspan=4 | [[Datei:rgSysstat.png|thumb]]<br />
|-<br />
| <code>attr Systemstatus nostate 1</code><br />
| Ohne state<br />
|-<br />
| <code>attr Systemstatus notime 1</code><br />
| Ohne readings timestamp<br />
|-<br />
| <code>attr Systemstatus mapping {'load' => 'Systemauslastung', 'temperature' => 'Systemtemperatur in &amp;deg;C'}</code><br />
| Die Zuordnung der reading Namen zu den Zeilentiteln<br />
|}<br />
<br />
=== Anzeige auf einem Floorplan ===<br />
{| class="wikitable"<br />
! Definition !! Erläuterungen !! Aussehen <br />
|-<br />
| style="width:40%" |<code>define Heizung readingsGroup t(1|2|3):temperature</code><br />
| Die Temperatur readings der Devices t1, t2 und t3<br />
| rowspan=6 | [[Datei:rgHeizung.png|thumb|220px]]<br />
|-<br />
| <code>attr Heizung mapping {'t1.temperature' => 'Vorlauf', 't2.temperature' => 'R&amp;&uuml;cklauf', 't3.temperature' => 'Zirkulation'}</code><br />
| Die Zuordnung der reading Namen zu den Zeilentiteln<br />
|-<br />
| <code>attr Heizung nameStyle style="text-align:left"</code><br />
| Zeilentitel linksbündig wegen floorplan<br />
|-<br />
| <code>attr Heizung style style="font-size:20px;color:lightgray"</code><br />
| Großer Font und Farbe passend für den floorplan<br />
|-<br />
| <code>attr Heizung notime 1</code><br />
| Ohne readings timestamp<br />
|-<br />
| <code>attr Heizung valueFormat : %.1f &amp;deg;C</code><br />
| Doppelpunkt zwischen Zeilentitel und Wert, eine Nachkommastelle plus Einheit<br />
|}<br />
<br />
<br />
=== LightScene DropDown-Menü für smallscreen Styles oder Floorplan ===<br />
<br />
{| class="wikitable"<br />
! Definition !! Erläuterungen !! Aussehen <br />
|-<br />
| style="width:40%" |<code>define lcDropDown readingsGroup meineLightScene:!state</code><br />
| Für die LightScene ''meineLightScene'' soll ein DropDown-Menü zur Auswahl der Szene erstellt werden.<br />
| rowspan=6 |<br />
|-<br />
| <code>attr lcDropDown commands { state => 'scene:' }</code><br />
| Die Anzeige des state Readings wird auf das DropDown-Menü für das scene Kommando gemapped.<br />
|-<br />
| <code>attr lcDropDown nonames 1</code><br />
| Keine Readingnamen<br />
|-<br />
| <code>attr lcDropDown notime 1</code><br />
| Kein Timestamp<br />
|}<br />
<br />
=== Schriftgrößen, Farben, Icons ===<br />
{| class="wikitable"<br />
! Definition !! Erläuterungen <br />
|-<br />
| colspan=2 | [[Datei:rgVerbrauchPCA301.png|links|mini|400px|Schriftgröße, Farbe, Icons...]]<br />
|-<br />
| style="width:40%" |<code>define Verbrauch readingsGroup TYPE=PCA301:state,power,consumption</code><br />
| Die readings state, power und consumption aller [[PCA301 Funkschaltsteckdose mit Energieverbrauchsmessung|PCA301]] Devices mit einer Zeile pro Device. <br />
|-<br />
| <code>attr Verbrauch mapping %ROOM %ALIAS</code><br />
| Der Raumname und der Alias werden als Zeilentitel verwendet<br />
|-<br />
| <code>attr Verbrauch nameStyle style="font-weight:bold"</code><br />
| Der Zeilentitel soll fett sein<br />
|-<br />
| <code>attr Verbrauch style style="font-size:20px"</code><br />
| Alles in einem größeren Font<br />
|-<br />
| <code>attr Verbrauch valueFormat {power => "%.1f W", consumption => "%.2f kWh"}</code><br />
| Die Formatierung für die power und consumption readings: eine Nachkommastelle plus Einheit.<br />
|-<br />
|<code>attr Verbrauch valueIcon { state => '%devStateIcon' }</code><br />
| Für die Dosen, die schaltbar sind, soll das anklickbare device icon gezeigt werden.<br />
|-<br />
|<code>attr Verbrauch valueStyle {($READING eq "power" && $VALUE > 40)?'style="color:red"':'style="color:green"'}</code><br />
|Wenn das power reading >40 ist, soll es in rot angezeigt werden, alle anderen Werte und readings in grün<br />
|}<br />
<br />
=== Wertabhängige Farbgebung ===<br />
{| class="wikitable"<br />
! Definition !! Erläuterungen <br />
|-<br />
| colspan=2 | [[Datei:TemperaturenRG.png|600px|mini|links|Wertabhängige Farben]]<br />
[[Datei:TemperaturenRG2.png|600px|mini|links|Andere Werte - andere Farben]]<br />
|-<br />
| style="width:40%" |<code>define wzTemperaturenRG readingsGroup Aussen:,<Temperatur>,temperature,<Luftfeuchte>,humidity Wohnzimmer:,<Temperatur>,temperature,<Luftfeuchte>,humidity Kasten_E_Geraete:,<Temperatur>,temperature,<Luftfeuchte>,humidity</code><br />
| Die readings temperatur und humidity der Devices Aussen, Wohnzimmer und Kasten_E_Geraete in einer Zeile pro Device. <br />
|-<br />
| <code>attr wzTemperaturenRG group 3. Temperaturen</code><br />
| Die readingsGroup kommt in eine Gruppe<br />
|-<br />
| <code>attr wzTemperaturenRG noheading 1</code><br />
| noheading<br />
|-<br />
| <code>attr wzTemperaturenRG nostate 1</code><br />
| nostate<br />
|-<br />
| <code>attr wzTemperaturenRG notime 1</code><br />
| notime<br />
|-<br />
| <code>attr wzTemperaturenRG valueFormat {temperature => "%.1f °C", humidity =>"%.1f %%" }</code><br />
| Die Formatierung für die temperatur und humidity readings: eine Nachkommastelle plus Einheit.<br />
|-<br />
|<code>attr wzTemperaturenRG valueStyle { if($DEVICE eq "Aussen" && $READING eq "temperature" && $VALUE > 30) { 'style="color:red"'}elsif($DEVICE eq "Aussen" && $READING eq "temperature" && $VALUE > 20) { 'style="color:orange"'}elsif($DEVICE eq "Aussen" && $READING eq "temperature" && $VALUE < 5) { 'style="color:blue"'}elsif($DEVICE eq "Wohnzimmer" && $READING eq "temperature" && $VALUE > 23) { 'style="color:red"'}elsif($DEVICE eq "Wohnzimmer" && $READING eq "temperature" && $VALUE > 21) { 'style="color:orange"'}elsif($DEVICE eq "Wohnzimmer" && $READING eq "temperature" && $VALUE < 20) { 'style="color:blue"'}elsif($DEVICE eq "Kasten_E_Geraete" && $READING eq "temperature" && $VALUE > 30) { 'style="color:red"'}elsif($DEVICE eq "Kasten_E_Geraete" && $READING eq "temperature" && $VALUE > 28) { 'style="color:orange"'}elsif($READING eq "humidity" && $VALUE > 65) { 'style="color:red"'}elsif($READING eq "humidity" && $VALUE > 60) { 'style="color:orange"'}else{'style="color:green"'} }</code><br />
| Diverse Farbkombinationen sind möglich<br />
|}<br />
<br />
=== Enigma Receiver ===<br />
{| class="wikitable"<br />
! Definition !! Erläuterungen <br />
|-<br />
| colspan=2 | [[Datei:ReceiverRG.jpg|600px|mini|links|Wertabhängige Farben]]<br />
[[Datei:ReceiverRGmute.jpg|600px|mini|links|Wertabhängige Farben]]<br />
|-<br />
| style="width:40%" |<code>define wzReceiverRG readingsGroup wzReceiver:,<Aktuell>,eventtitle,<Rest>,eventremaining_hr,<Dauer>,eventduration_hr wzReceiver:<Beschreibung>,eventdescription wzReceiver:,<Nächste>,eventtitle_next,<Start>,eventstart_next_hr,<Dauer>,eventduration_next_hr wzReceiver:,<HDD Kapazität>,hdd1_capacity,<Frei>,wzReceiver:hdd1_free wzReceiver:,<Lautstärke>,volume,<HDD>,hdd1_capacity,<Frei>,hdd1_free</code><br />
| Mehrere readings des Device wzReceiver in mehreren Zeilen. Wenn der Receiver auf mute ist, wird anstatt der Lautstärke, mute angezeigt. Farbige Anzeige des freien Speicherplatzes<br />
'''Benötigt:''' ENIGMA2 Receiver, 70_ENIGMA2.pm - Siehe: [[Enigma2 Receiver (Dreambox, VUplus etc.) steuern]]<br />
|-<br />
| <code>attr wzReceiverRG group Fernseher Receiver</code><br />
| Die readingsGroup kommt in eine Gruppe<br />
|-<br />
| <code>attr wzReceiverRG mapping &amp;nbsp;</code><br />
| mapping wird auf &amp;nbsp; (Leerzeichen) gesetzt, damit der Device Name nicht angezeigt wird<br />
|-<br />
| <code>attr wzReceiverRG noheading 1</code><br />
| noheading<br />
|-<br />
| <code>attr wzReceiverRG nostate 1</code><br />
| nostate<br />
|-<br />
| <code>attr wzReceiverRG notime 1</code><br />
| notime<br />
|-<br />
|-<br />
| <code>attr wzReceiverRG valueColumns { eventdescription => 'colspan="4"' }</code><br />
| Die Beschreibung soll über 4 Spalten gehen<br />
|-<br />
| <code>attr wzReceiverRG valueFormat { wzReceiverRGvalueFormat($DEVICE,$READING,$VALUE);; }</code><br />
| Die Formatierung wird in die 99_myUtils.pm ausgelagert. Siehe: [[99 myUtils anlegen]]<br />
|-<br />
|<code>attr wzReceiverRG valueStyle { if($READING eq "hdd1_free" && $VALUE < 200){ 'style="color:red"' }elsif( $READING eq "hdd1_free" && $VALUE < 500 ){ 'style="color:orange"' }elsif( $READING eq "volume" && ReadingsVal($DEVICE, "mute", "") eq "on" ){ 'style="color:red"' }else{ 'style="color:green"' } }</code><br />
| Diverse Farbkombinationen sind möglich. Wenn der Receiver auf mute ist, wird anstatt der Lautstärke <span style="color: red;">mute</span> angezeigt.<br />
|-<br />
|<syntaxhighlight lang="perl"><br />
sub<br />
wzReceiverRGvalueFormat($$$)<br />
{<br />
my ($DEVICE,$READING,$VALUE) = @_;<br />
<br />
if($READING eq 'hdd1_capacity') { <br />
return "%.2f MB";<br />
} elsif( $READING eq 'hdd1_free') {<br />
return "%.2f MB";<br />
} elsif( $READING eq 'volume' ) {<br />
if( ReadingsVal($DEVICE, "mute", "") eq "on") {<br />
return "mute";<br />
} else {<br />
return "%i %%";<br />
}<br />
}<br />
}</syntaxhighlight><br />
| Dieser Teil kommt in die [[99_myUtils_anlegen|99_myUtils.pm]]<br />
|}<br />
<br />
=== Heizungswerte inklusive Batterie- und Fensterstatus ===<br />
{| class="wikitable"<br />
! Definition !! Erläuterungen <br />
|-<br />
| colspan=2 | [[Datei:rgHeizung3.png|thumb|links|500px|Heizungswerte inklusive Batterie- und Fensterstatus]]<br />
|-<br />
| style="width:40%" |<code>define Heizungswerte readingsGroup <%sani_heating>,< >,<Act>,<Soll>,<Ist> TYPE=FHT:actuator,desired-temp,measured-temp,<%18>,<%20>,<%22>,window,battery</code><br />
| Diverse readings aller Devices des Typs <b>FHT</b>. <br />
|-<br />
| <code>attr Heizungswerte commands { 'Heizungswerte.18' => 'set $DEVICE desired-temp 18', 'Heizungswerte.20' => 'set $DEVICE desired-temp 20', 'Heizungswerte.22' => 'set $DEVICE desired-temp 22' }</code><br />
| Die Links/Kommandos die hinter den 18, 20 und 22 liegen sollen.<br />
|-<br />
| <code>attr Heizungswerte nameStyle style="color:yellow;font-weight:bold"</code><br />
| Die Überschriften sollen gelb sein.<br />
|-<br />
| <code>attr Heizungswerte valueIcon {'battery.ok' => 'batterie@lightgreen', 'battery.low' => 'batterie@red', 'window.closed' => 'fts_window_1w@lightgreen', 'window.open' => 'fts_window_1w_open@red'}</code><br />
| Für den Batteriestand und den Zustand der Fenster sollen jeweils Icons angezeigt werden.<br />
|}<br />
<br />
=== Heizungswerte inklusive Ventilposition ===<br />
{| class="wikitable"<br />
! Definition !! Erläuterungen <br />
|-<br />
| colspan=2 | [[Datei:Rg_Heizung_Valveposition.png|thumb|links|500px|Heizungswerte inklusive Statusinformationen (MAX!)]]<br />
|-<br />
| style="width:40%" |<code>define Heizungswerte readingsGroup <%sani_heating>,<Ventil>,<Soll>,<Ist>,<MaxV>,<GID>,<Mode>,<Batterie> TYPE=CUL_HM:ValvePosition,desired-temp,measured-temp,R-valveMaxPos,groupid,mode,battery</code><br />
| Diverse readings aller Devices des Typs <b>MAX</b>. <br />
|-<br />
| <code>attr Heizungswerte mapping %ROOM</code><br />
| Die Raumnamen werden angezeigt.<br />
|-<br />
| <code>attr Heizungswerte nameStyle style="color:yellow;font-weight:bold"</code><br />
| Die Überschriften sollen gelb (fett) sein.<br />
|-<br />
| <code>attr Heizungswerte room Heizung</code><br />
| Die "readingsgroup" wird dem Raum "Heizung" zugeordnet.<br />
|-<br />
| <code>attr Heizungswerte valueFormat {'temperature' => "%.0f °C", 'desiredTemperature' => "%.0f °C", 'valveposition' =>"%.0f %%", 'maxValveSetting' =>"%.0f %%" }</code><br />
| Es wird noch die Einheit °C hinter den Temperaturwerten angezeigt.<br />
|-<br />
| <code>attr Heizungswerte valueIcon {'battery.ok' => 'batterie@lightgreen', 'battery.low' => 'batterie@red'}</code><br />
| Für den Batteriezustand werden Icons anstatt Klartextwerte genommen!<br />
|-<br />
| <code>attr Heizungswerte valueStyle { if($READING eq "temperature" && $VALUE > 20){ 'style="color:green;;font-weight:bold"' }elsif( $READING eq "temperature" && $VALUE <= 20 ){ 'style="color:blue"' }elsif( $READING eq "temperature" && $VALUE > 23 ){ 'style="color:red"' }else{ 'style="color:gray"' } }</code><br />
| Die Temperaturwerte werden abhängig vom Wert farbig dargestellt.<br />
|-<br />
| <code>attr Heizungswerte valueIcon {'battery.ok' => 'batterie@lightgreen', 'battery.low' => 'batterie@red', 'window.closed' => 'fts_window_1w@lightgreen', 'window.open' => 'fts_window_1w_open@red'}</code><br />
| Für den Batteriestand und den Zustand der Fenster sollen jeweils Icons angezeigt werden.<br />
|}<br />
<br />
=== Heizungswerte, Status und Regelmöglichkeit ===<br />
{| class="wikitable"<br />
! Definition !! Erläuterungen <br />
|-<br />
| colspan=2 | [[Datei:rgHeizung2.png|thumb|500px|links|Anzeige + Regelmöglichkeit]]<br />
|-<br />
| style="width:40%" |<code>define Heizungswerte2 readingsGroup <%sani_heating>,< >,<Act>,<Soll>,<Ist> TYPE=FHT:actuator,desired-temp,measured-temp,<{myUtils_HeizungUpDown($DEVICE,"up")}@desired-temp>,desired-new,<{myUtils_HeizungUpDown($DEVICE,"down")}@desired-temp>,window,battery</code><br />
| Diverse readings aller Devices des Typs <b>FHT</b>. <br />
|-<br />
| <code>attr Heizungswerte2 nameStyle style="color:yellow;font-weight:bold"</code><br />
| Die Überschriften sollen gelb sein.<br />
|-<br />
| <code>attr Heizungswerte2 valueIcon {'battery.ok' => 'batterie@lightgreen', 'battery.low' => 'batterie@red', 'window.closed' => 'fts_window_1w@lightgreen', 'window.open' => 'fts_window_1w_open@red'}</code><br />
| Für den Batteriestand und den Zustand der Fenster sollen jeweils Icons angezeigt werden.<br />
|-<br />
| <code>attr Heizungswerte2 valueStyle {($VALUE eq "00")?'style="visibility:hidden"':''}</code><br />
| Nach dem Einstellen den Wert wieder ausblenden. <br />
|-<br />
| <syntaxhighlight lang="perl"><br />
#Heizung regeln in readingsGroup<br />
sub<br />
myUtils_HeizungUpDown($$)<br />
{<br />
my($DEVICE,$CMD) = @_;<br />
<br />
my $icon = $CMD;<br />
my $VALUE = ReadingsVal($DEVICE,"desired-new","20" );<br />
$VALUE = ReadingsVal($DEVICE,"desired-temp","20" )<br />
if( !$VALUE || $VALUE == 0 );<br />
my $link;<br />
<br />
if( $CMD eq "up" ) {<br />
$icon = "control_arrow_upward";<br />
$VALUE += 1;<br />
<br />
if( $VALUE <= 24 ) {<br />
$icon .= "\@red";<br />
$link = "setreading $DEVICE desired-new $VALUE";<br />
}<br />
} elsif( $CMD eq "down" ) {<br />
$icon = "control_arrow_downward";<br />
$VALUE -= 1;<br />
<br />
if( $VALUE >= 18 ) {<br />
$icon .= "\@blue";<br />
$link = "setreading $DEVICE desired-new $VALUE";<br />
}<br />
}<br />
<br />
my $notify = "notifyHeizungUpDown";<br />
if( !defined($defs{$notify}) ) {<br />
CommandDefine(undef,<br />
"$notify notify .*:desired-new.* "<br />
."{ myUtils_HeizungUpDownNotify(\$NAME,\$EVTPART1); }" );<br />
}<br />
<br />
my $ret = "%$icon";<br />
$ret .= "%$link" if( $link );<br />
<br />
return $ret;<br />
}<br />
<br />
sub<br />
myUtils_HeizungUpDownNotify($$)<br />
{<br />
my($DEVICE,$VALUE) = @_;<br />
<br />
return if( $VALUE == 0 );<br />
<br />
my $at = "triggerHeizungUpDown_$DEVICE";<br />
CommandDelete(undef, $at) if( defined($defs{$at}) );<br />
CommandDefine(undef,<br />
"$at at +00:00:03 "<br />
."{my \$v = ReadingsVal(\"$DEVICE\",\"desired-new\",undef);"<br />
."fhem(\"set $DEVICE desired-temp \$v\") if( \$v );"<br />
."fhem(\"setreading $DEVICE desired-new 00\");}" );<br />
<br />
return undef;<br />
}</syntaxhighlight><br />
| Dieser Teil kommt in die [[99_myUtils_anlegen|99_myUtils.pm]]: Hiermit werden die Icons zum Ändern der gewünschten Temperatur dargestellt und im Bereich >=18 und <= 24 Grad anklickbar gemacht. Zwischen den Pfeilen wird der gerade eingestellte Wert angezeigt. Wenn dieser drei Sekunden nicht mehr geändert wurde wird die desired-temp auf diesen Wert gesetzt und die Anzeige zwischen den Pfeilen ausgeblendet.<br />
|}<br />
<br />
=== Heizungswerte, Status, Steuerung und Wochenprofil ===<br />
Dieses Beispiel funktioniert nur mit HomeMatic HM-CC-RT-DN, für andere Thermostate müssen an diversen Stellen Änderungen vorgenommen werden.<br />
{{Todo|Überarbeiten: umstellen auf readingList oder setreading, label als readings in die readingsGroup selber stecken statt in einen extra dummy. oder !<reading> und mapping verwenden.}}<br />
{| class="wikitable"<br />
! Definition !! Erläuterungen <br />
|-<br />
| colspan=2 | [[Datei:RgThermostate.png|thumb|750px|links|Status, Steuerung und Wochenprofil]]<br />
|-<br />
| style="width:40%" |<pre><br />
define d_label dummy<br />
setreading d_label Heizung Heizung <br />
setreading d_label Temperatur Temperatur <br />
setreading d_label Status Status <br />
setreading d_label Wochenplan Wochenplan <br />
setreading d_label Werktag Werktag <br />
setreading d_label Samstag Samstag <br />
setreading d_label Sonntag Sonntag <br />
setreading d_label Zeitraum1 Zeitraum 1 <br />
setreading d_label Zeitraum2 Zeitraum 2 </pre><br />
|Erzeugen der Readings im Device [[dummy#d_label|d_label]]. (Zeilenweise in die Befehlszeile eintragen.)<br />
|-<br />
| <code> <br />
define rg_thermostate readingsGroup <>,Heizung@d_label,<|>,Temperatur@d_label,<|>,Status@d_label,<|>,Wochenplan@d_label,<|>,Werktag@d_label,<|>,Samstag@d_label,<|>,Sonntag@d_label,<|>,<> CUL_HM_HM_CC_RT_DN_......_Clima:<>,?alias,<|>,<Soll>,desired-temp,<Tag>,dayTemp@{rg($DEVICE."§clima")},impossible@{$DEVICE},<|>,controlMode,R-globalBtnLock@{rg($DEVICE."§device")},<|>,Zeitraum1@d_label,<|>,workday_period_1_start@{rg($DEVICE."§clima")},workday_period_1_stop@{rg($DEVICE."§clima")},<|>,saturday_period_1_start@{rg($DEVICE."§clima")},saturday_period_1_stop@{rg($DEVICE."§clima")},<|>,sunday_period_1_start@{rg($DEVICE."§clima")},sunday_period_1_stop@{rg($DEVICE."§clima")},<|>,impossible@{$DEVICE},<%system_fhem_update>,<nowiki><br></nowiki>,state@{rg($DEVICE."§device")},<%getConfig>,<|>,<Ist>,measured-temp,<Nacht>,nightTemp@{rg($DEVICE."§clima")},<|>,<Ventil>,ValvePosition,<|>,Zeitraum2@d_label,<|>,workday_period_2_start@{rg($DEVICE."§clima")},workday_period_2_stop@{rg($DEVICE."§clima")},<|>,saturday_period_2_start@{rg($DEVICE."§clima")},saturday_period_2_stop@{rg($DEVICE."§clima")},<|>,sunday_period_2_start@{rg($DEVICE."§clima")},sunday_period_2_stop@{rg($DEVICE."§clima")},<|>,impossible@{$DEVICE},impossible@{rg($DEVICE."§device")},<%burstXmit> </code><br />
| Diverse readings aller Devices <b>CUL_HM_HM_CC_RT_DN_......_Clima</b>, entsprechender [[Makefine#d_climaControl|d_climaControl]] (müssen vorher angelegt werden) und [[dummy#d_label|d_label]]. <br />
|-<br />
| <code>attr rg_thermostate commands { 'desired-temp' => 'desired-temp:', 'dayTemp' => 'dayTemp:', 'controlMode' => 'trigger ntfy_rg $DEVICE controlMode', 'R-globalBtnLock' => 'trigger ntfy_rg $DEVICE globalBtnLock', 'workday_period_1_start' => 'workday_period_1_start:', 'workday_period_1_stop' => 'workday_period_1_stop:', 'saturday_period_1_start' => 'saturday_period_1_start:', 'saturday_period_1_stop' => 'saturday_period_1_stop:', 'sunday_period_1_start' => 'sunday_period_1_start:', 'sunday_period_1_stop' => 'sunday_period_1_stop:', 'rg_thermostate.system_fhem_update' => 'trigger ntfy_rg $DEVICE setTimeTable', 'rg_thermostate.getConfig' => 'set $DEVICE getConfig', 'nightTemp' => 'nightTemp:', 'workday_period_2_start' => 'workday_period_2_start:', 'workday_period_2_stop' => 'workday_period_2_stop:', 'saturday_period_2_start' => 'saturday_period_2_start:', 'saturday_period_2_stop' => 'saturday_period_2_stop:', 'sunday_period_2_start' => 'sunday_period_2_start:', 'sunday_period_2_stop' => 'sunday_period_2_stop:', 'rg_thermostate.burstXmit' => 'set $DEVICE burstXmit'}</code><br />
| Temperaturen werden als DropDown Auswahl dargestellt, Icons triggern [[readingsGroup#sub_rg|ntfy_rg]]<br />
|-<br />
| <code>attr rg_thermostate mapping { 'desired-temp' => '', 'dayTemp' => '', 'workday_period_1_start' => '', 'workday_period_1_stop' => '', 'saturday_period_1_start' => '', 'saturday_period_1_stop' => '', 'sunday_period_1_start' => '', 'sunday_period_1_stop' => '', 'nightTemp' => '', 'workday_period_2_start' => '', 'workday_period_2_stop' => '', 'saturday_period_2_start' => '', 'saturday_period_2_stop' => '', 'sunday_period_2_start' => '', 'sunday_period_2_stop' => ''}</code><br />
| Ausblenden der Texte vor den DropDowns.<br />
|-<br />
| <code> <br />
attr rg_thermostate nameStyle{($READING eq "Soll" ||$READING eq "Tag" ||$READING eq "%getConfig" ||$READING eq "Ist" ||$READING eq "Nacht" ||$READING eq "Ventil" )?'style="text-align:right"' :($READING eq "%burstXmit" )?'style="text-align:center"' :'style=""'}<br />
</code><br />
| Ausrichten der Überschriften die keine readings sind.<br />
|-<br />
| <code>attr rg_thermostate nonames 1</code><br />
| Ausblenden der Device Namen.<br />
|-<br />
| <code>attr rg_thermostate valueColumns { 'Heizung' => 'colspan="2"', 'Temperatur' => 'colspan="4"', 'Status' => 'colspan="2"', 'Werktag' => 'colspan="2"', 'Samstag' => 'colspan="2"', 'Sonntag' => 'colspan="2"', 'alias' => 'colspan="2"'}</code><br />
| Diverse Readings sollen über mehrere Spalten dargestellt werden.<br />
|-<br />
| <code>attr rg_thermostate valueFormat { 'measured-temp' => "%0.1f &deg;C", 'ValvePosition' => "%0.1f %%"}</code><br />
| Formatierung für measured-temp und ValvePosition.<br />
|-<br />
| <code>attr rg_thermostate valueIcon { 'controlMode.auto' => 'sani_heating_automatic@green', 'controlMode.set_auto' => 'sani_heating_automatic@orange', 'controlMode.manual' => 'sani_heating_manual@red', 'controlMode.set_manual' => 'sani_heating_manual@orange', 'R-globalBtnLock.on' => 'secur_locked@green', 'R-globalBtnLock.on ' => 'secur_locked@green', 'R-globalBtnLock.set_on ' => 'secur_locked@orange', 'R-globalBtnLock.off' => 'secur_open@red', 'R-globalBtnLock.off ' => 'secur_open@red', 'R-globalBtnLock.set_off ' => 'secur_open@orange'}</code><br />
| Zuweisung der Icons.<br />
|-<br />
| <code><br />
attr rg_thermostate valueStyle{($READING eq "Heizung" ||$READING eq "Temperatur" ||$READING eq "Status" ||$READING eq "Wochenplan" ||$READING eq "Werktag" ||$READING eq "Samstag" ||$READING eq "Sonntag" )?'style="font-size:20px;;color:RoyalBlue;;text-align:center"' :($READING eq "alias" )?'style="font-size:11px;;font-weight:bold;;text-align:left"' :($READING eq "ValvePosition" &&$VALUE > 40 )?'style="font-weight:bold;;color:Orange;;text-align:left"' :($READING eq "desired-temp" ||$READING eq "measured-temp" )?'style="text-align:center"' :($READING eq "state" ||$READING eq "ValvePosition" )?'style="text-align:left"' :'style="text-align:right"'}<br />
</code><br />
| Ausrichten und Einfärben der Readings.<br />
|}<br />
<br />
=== Heizungsteuerung für HM Wand- und Heizkörperthermostate ===<br />
<br />
Dieses Beispiel wurde für HM-TC-IT-WM-W-EU / HM-CC-RT-DN Geräte erstellt. Verwendung anderer Thermostate wird ggf. Anpassungen erforderlich machen. Die Geräte werden nicht automatisch ermittelt, sondern sind einzeln angegeben.<br />
Es werden Soll- und Ist-Temperaturen angezeigt, Luftfeuchte und Ventilpositionen, Modus, Batterie und Global-Tastenlock.<br />
Steuerungsmöglichkeiten: Solltemperatur, Modus (Manual/Automatik), (globale) Tastenlock.<br />
Die Abweichung der Isttemperatur, die Ventilpositionen, Batteriestand etc. werden farblich hervorgehoben. <br />
<br />
Die Gerätenamen (EG_WZ_WT01_Climate / EG_WZ_WT01, EG_WZ_TT01_Clima / EG_WZ_TT01 / EG_WZ_TT02, OG_BZ_WT01_Climate / OG_BZ_WT01, OG_BZ_TT01_Clima / OG_BZ_TT01, OG_SZ_WT01_Climate / OG_SZ_WT01, OG_SZ_TT01_Clima / OG_SZ_TT01, OG_DZ_WT01_Climate / OG_DZ_WT01, OG_DZ_TT01_Clima / OG_DZ_TT01) müssen natürlich entsprechend angepasst werden.<br />
<br />
Hinweis: Bei den Geräten muss das Attribut „expert“ auf "1_on" gesetzt werden, andernfalls fehlt das Reading „R-globalBtnLock“. Dies hätte zur Folge, dass in der Spalte Lock der batteryLevel dargestellt wird.<br />
<br />
{| class="wikitable"<br />
! Definition !! Erläuterungen <br />
|-<br />
| colspan=2 | [[Datei:RgHMTh.jpg|thumb|500px|links|Status, Steuerung und Wochenprofil]]<br />
|-<br />
| <code>define heatingInfo readingsGroup <%sani_heating>,<Soll>,<Soll neu>,<Ist>,<Ventil / RH>,<Modus>,<Lock>,<Bat><br><br />
EG_WZ_WT01_Climate:desired-temp,<sollsetz>,measured-temp,humidity,controlMode,R-globalBtnLock@EG_WZ_WT01,batteryLevel@EG_WZ_WT01 \<br><br />
EG_WZ_TT01_Clima:desired-temp,<>,measured-temp,ValvePosition,controlMode,R-globalBtnLock@EG_WZ_TT01,batteryLevel@EG_WZ_TT01 \<br><br />
EG_WZ_TT02_Clima:desired-temp,<>,measured-temp,ValvePosition,controlMode,R-globalBtnLock@EG_WZ_TT02,batteryLevel@EG_WZ_TT02 \<br><br />
<>,<>,<>,<>,<>,<>,<>,<> \<br><br />
OG_BZ_WT01_Climate:desired-temp,<sollsetz>,measured-temp,humidity,controlMode,R-globalBtnLock@OG_BZ_WT01,batteryLevel@OG_BZ_WT01 \<br><br />
OG_BZ_TT01_Clima:desired-temp,<>,measured-temp,ValvePosition,controlMode,R-globalBtnLock@OG_BZ_TT01,batteryLevel@OG_BZ_TT01 \<br><br />
<>,<>,<>,<>,<>,<>,<>,<> \<br><br />
OG_SZ_WT01_Climate:desired-temp,<sollsetz>,measured-temp,humidity,controlMode,R-globalBtnLock@OG_SZ_WT01,batteryLevel@OG_SZ_WT01 \<br><br />
OG_SZ_TT01_Clima:desired-temp,<>,measured-temp,ValvePosition,controlMode,R-globalBtnLock@OG_SZ_TT01,batteryLevel@OG_SZ_TT01 \<br><br />
<>,<>,<>,<>,<>,<>,<>,<> \<br><br />
OG_DZ_WT01_Climate:desired-temp,<sollsetz>,measured-temp,humidity,controlMode,R-globalBtnLock@OG_DZ_WT01,batteryLevel@OG_DZ_WT01 \<br><br />
OG_DZ_TT01_Clima:desired-temp,<>,measured-temp,ValvePosition,controlMode,R-globalBtnLock@OG_DZ_TT01,batteryLevel@OG_DZ_TT01</code><br />
| ReadingsGoup anlegen. <br />
|-<br />
| <code>attr heatingInfo cellStyle { "r:1"=>'style="font-weight:bold;;font-size:16px"',<br><br />
"r:2,c:0"=>'style="font-weight:bold"',"r:6,c:0" =>'style="font-weight:bold"',<br><br />
"r:9,c:0"=>'style="font-weight:bold"',"r:12,c:0"=>'style="font-weight:bold"'}</code><br />
| Schrift fett setzen etc.<br />
|-<br />
| <code>attr heatingInfo commands {<br><br />
'heatingInfo.sollsetz'=>'desired-temp:5.0,12.0,18.0,19.0,20.0,20.5,21.0,21.5,22.0,22.5,23.0,23.5,24.0',<br><br />
"controlMode.manual"=>"set %DEVICE controlMode auto","controlMode.auto"=>"set %DEVICE controlMode manual",<br><br />
"R-globalBtnLock.on"=>"set %DEVICE regSet globalBtnLock off",<br><br />
"R-globalBtnLock.off"=>"set %DEVICE regSet globalBtnLock on"}</code><br />
| Heizungssteuerung ermöglichen<br />
|-<br />
| <code><br />
attr heatingInfo mapping {OG_BZ_WT01_Climate=>"Bad",<br><br />
OG_BZ_TT01_Clima=>"&amp;nbsp;;&amp;nbsp;;&amp;nbsp;;Regler",OG_SZ_WT01_Climate=>"Schlafzimmer",<br><br />
OG_SZ_TT01_Clima=>"&amp;nbsp;;&amp;nbsp;;&amp;nbsp;;Regler",OG_DZ_WT01_Climate=>"Duschbad",<br><br />
OG_DZ_TT01_Clima=>"&amp;nbsp;;&amp;nbsp;;&amp;nbsp;;Regler",EG_WZ_WT01_Climate=>"Wohnzimmer",<br><br />
EG_WZ_TT01_Clima=>"&amp;nbsp;;&amp;nbsp;;&amp;nbsp;;Regler1",EG_WZ_TT02_Clima=>"&amp;nbsp;;&amp;nbsp;;&amp;nbsp;;Regler2",'desired-temp' => ''}<br><br />
</code><br />
| Gewünschte Namen definieren.<br />
|-<br />
| <code><br />
attr heatingInfo valueFormat {if($READING eq "ValvePosition" && $VALUE ne "0"){$VALUE = int($VALUE/10)*10}<br><br />
elsif($READING eq "batteryLevel"){if($VALUE>=3){$VALUE=100}<br><br />
elsif($VALUE>=2.7){$VALUE=75}elsif($VALUE>=2.5){$VALUE=50}elsif($VALUE>=2.2){$VALUE=25}<br><br />
else{$VALUE=0}}}<br />
</code><br />
| Werte vorformatieren (für die Icon-Zuordnung).<br />
|-<br />
| <code><br />
attr heatingInfo valueIcon {'controlMode.manual' => 'sani_heating_manual@795CFF',<br><br />
'controlMode.auto' => 'sani_heating_automatic@FFC13A', 'controlMode.boost' => 'sani_heating_boost@FB0C02',<br><br />
'humidity'=>'humidity@6FD9FB', 'R-globalBtnLock.on'=>'secur_locked@F7301D', <br><br />
'R-globalBtnLock.off'=>'secur_open@0CFB0C','ValvePosition.0' => 'sani_heating_level_0@002AE0',<br><br />
'ValvePosition.10' => 'sani_heating_level_10@F8D53D','ValvePosition.20' => 'sani_heating_level_20@FF9341',<br><br />
'ValvePosition.30' => 'sani_heating_level_30@F17F3F','ValvePosition.40' => 'sani_heating_level_40@E46C3C',<br><br />
'ValvePosition.50' => 'sani_heating_level_50@DE3B3A','ValvePosition.60' => 'sani_heating_level_60@A30D2D',<br><br />
'ValvePosition.70' => 'sani_heating_level_70@B40A23','ValvePosition.80' => 'sani_heating_level_80@C40619',<br><br />
'ValvePosition.90' => 'sani_heating_level_90@D4030F','ValvePosition.100' => 'sani_heating_level_100@E50005',<br><br />
'batteryLevel.100'=>'measure_battery_100@0CFB0C','batteryLevel.75'=>'measure_battery_75@42BC0A',<br><br />
'batteryLevel.50'=>'measure_battery_50@F5FF10','batteryLevel.25'=>'measure_battery_25@FB5909',<br><br />
'batteryLevel.0'=>'measure_battery_0@E50005','controlMode.set_boost' => 'hourglass',<br><br />
'controlMode.set_auto' => 'hourglass','controlMode.set_manual' => 'hourglass',<br><br />
'R-globalBtnLock.set_on' => 'hourglass','R-globalBtnLock.set_off' => 'hourglass'}<br />
</code><br />
| Icons zuordnen.<br />
|-<br />
| <code><br />
attr heatingInfo valueStyle {if($READING eq "measured-temp")<br><br />
{my $t=$VALUE;;my $d=ReadingsVal($DEVICE,'desired-temp',0);;<br><br />
if($t-$d>=1){'style="color:rgb(251,63,11);;"'}elsif($t-$d<=-1){'style="color:rgb(79,58,251);;"'}<br><br />
else{'style="color:rgb(12,251,12);;"'}}}<br />
</code><br />
| Farben (zu kalt: blau, zu warm: rot, ok: grün).<br />
|-<br />
| <code><br />
attr heatingInfo valueSuffix {"desired-temp"=>" °C", "measured-temp"=>" °C", <br><br />
"ValvePosition"=>" (".ReadingsVal($DEVICE,$READING,0)." %)", <br><br />
"humidity"=>" ".ReadingsVal($DEVICE,$READING,0)." % RH", <br><br />
"batteryLevel"=>" (".ReadingsVal($DEVICE,$READING,0)." V)"}<br />
</code><br />
| Messeinheiten und Zahlenwerte.<br />
|}<br />
<br />
=== Readings aus zusätzlichen Devices ===<br />
Im folgenden Beispiel wird gezeigt wie sich Readings zusätzlicher Devices zu einer Zeile mit mehreren Readings hinzufügen lassen. Diese zusätzlichen Devices können z.b. die unterschiedlichen Channel eines HomeMatic Gerätes sein. Im folgenden Beispiel wird der Name des zugehörigen Geräts dynamisch bestimmt.<br />
{| class="wikitable"<br />
! Definition !! Erläuterungen <br />
|-<br />
| colspan=2 | [[Datei:rgHeizung4.png|thumb|750px|links|Anzeige + Regelmöglichkeit]]<br />
|-<br />
| style="width:40%" |<code>define myTemp readingsGroup <Raum>,<Tist>,<Tsoll>,<Mode>,<Tnight>,<Tday>,<Hum>,<BatTC>,<Vist>,<Vsoll>,<Verr>,<BatVD> Thermostat.(WZ|OZ|AZ|Bad|Kueche|SZ|GZ|Bad.OG):measured-temp,desired-temp,controlMode,night-temp,day-temp,humidity,battery,ValvePosition@{valveOfDevice($DEVICE)},ValveDesired@{valveOfDevice($DEVICE)},R-valveErrorPos@{valveOfDevice($DEVICE)},battery@{valveOfDevice($DEVICE)} Broetje:ToutIst </code><br />
| Diverse Readings aller Thermostat Devices und des jeweils zugehörigen Ventilantriebs. <br />
|-<br />
| <code>attr myTemp mapping { 'Broetje' => 'Garten','Thermostat.AZ' => 'EG Arbeitszimmer','Thermostat.SZ' => 'OG Schlafzimmer','Thermostat.WZ'=>'EG Wohnzimmer','Thermostat.Kueche' => 'EG Küche','Thermostat.GZ' => 'OG Gästezimmer','Thermostat.Bad' => 'EG Bad','Thermostat.Bad.OG' => 'OG Bad','Thermostat.OZ' => 'EG Kaminzimmer','desired-temp' => <nowiki>''</nowiki> }</code><br />
| Die Benennung der Zeilentitel (Das ist je nach Konfiguration auch über $ALIAS und/oder $ROOM lösbar).<br />
|-<br />
| <code>attr myTemp commands { 'desired-temp' => 'desired-temp:' }</code><br />
| desired-temp soll per dropDown einstellbar sein.<br />
|-<br />
| <code>attr myTemp nameStyle style="color:yellow"</code><br />
| Die Überschriften sollen gelb sein.<br />
|-<br />
| <code>attr myTemp valueIcon {'battery.ok' => 'batterie@lightgreen', 'battery.low' => 'batterie@red'}</code><br />
| Für den Batteriestand sollen jeweils Icons angezeigt werden.<br />
|-<br />
| <code>attr myTemp valueFormat { 'measured-temp' => "%0.1f &amp;deg;C",'ToutIst' => "%.1f &amp;deg;C",'night-temp' => "%.1f &amp;deg;C",'day-temp' => "%.1f &amp;deg;C",'humidity' => "%.0f <br />
%%",'ValvePosition' => "%.0f %%",'ValveDesired' => "%.0f %%",'R-valveErrorPos' => "%.0f %%" }</code><br />
| Die Formatierung der Werte. <br />
|-<br />
|<syntaxhighlight lang="perl"><br />
#namen des ventil device aus thermostat device ableiten<br />
sub valveOfDevice ($) {<br />
my ($DEVICE) = @_;<br />
<br />
if ($DEVICE =~ m/AZ/) {<br />
return "Ventil.".substr($DEVICE,11).".Nord";<br />
} else {<br />
return "Ventil.".substr($DEVICE,11); <br />
}<br />
}</syntaxhighlight><br />
| Dieser Teil kommt in die [[99_myUtils_anlegen|99_myUtils.pm]]: Hier wird aus dem Namen des Thermostaten der Name des zugehörigen Ventilantriebs abgeleitet.<br />
|}<br />
Da im {...} Teil des <reading>@<device> Arguments keine Leerzeichen oder Kommas vorkommen dürfen ist er in der Regel das Einfachste die Funktionalität wie in diesem Beispiel in eine eigene Routine auszulagern. Mit ein paar 'Tricks' lässt es sich aber manchmal auch ohne Leerzeichen oder Kommas lösen und dann direkt in die Definition schreiben:<code>...,ValvePosition@{$DEVICE=~s/Thermostat/Ventil/;$DEVICE;},...</code><br />
<br />
=== Inhalte filtern ===<br />
Wenn man gewisse Zeilen einer Readingsgroup nicht dargestellt haben möchte, so kann man diese mit Hilfe von <code>valueFormat</code> ausfiltern, bspw.:<br />
<br />
<code>attr rg valueFormat { return $VALUE if ( $VALUE > 0 );; return undef;; }</code><br />
<br />
In diesem Bsp. werden alle Zeilen/Devices, deren Value > 0 sind, angezeigt. Alle anderen werden als <code>undef</code> formatiert und erscheinen damit nicht im Listing.<br />
<br />
Dies kann man noch weiter ausbauen und dynamische Auswahllisten erstellen (s. [[ReadingsGroup#Dynamische Inhalte]]).<br />
<br />
=== Inhalte berechnen ===<br />
Will man nur kleine Berechnungen machen und möchte diese aus irgendeinem Grund nicht in die [[99_myUtils_anlegen|99_myUtils.pm]] auslagern (zB. der Übersicht halber), so kann man die Berechnung auch direkt in <code>valueFormat</code> einbauen. Ein ganz einfaches Bsp. dazu ist das Filtern von Inhalten ([[ReadingsGroup#Inhalte filtern|s.o.]]).<br />
<br />
Im konkreten Beispiel ist via caldav ein Abfallkalender eingebunden, der die folgenden Einträge erzeugt:<br />
<br />
<syntaxhighlight lang="text"><br />
t_001_bdate 06.02.2017 2017-02-04 14:40:49<br />
t_001_btime 00:00:00 2017-02-04 14:40:49<br />
...<br />
t_001_summary Gelber Sack 2017-02-04 14:40:49<br />
</syntaxhighlight><br />
<br />
Daraus lässt sich mit <code>readingsGroup</code> so direkt keine ordentliche Darstellung erzeugen. Gewünscht ist aber das folgende Format eines Zeilenentrags:<br />
<br />
<code>06.02.2017 Gelber Sack</code><br />
<br />
Dies lässt sich durch eine noch einigermaßen kurze Berechnung erzeugen - längere Berechnungen sollte man definitiv in myUtils auslagern (vgl. [[ReadingsGroup#Enigma Receiver|hier]]). Der folgende Code filtert zusätzlich weitere nicht erwünschte Einträge aus und macht noch eine Wortanpassung:<br />
<br />
<syntaxhighlight lang="perl"><br />
# die readingsGroup reagiert nur auf summary-Einträge ( .* steht für eine beliebige Anzahl beliebiger Zeichen)<br />
<br />
define Abfallkalender readingsGroup calvAbfallKalender:t_.*summary<br />
<br />
attr Abfallkalender valueFormat {<br />
use Time::Local;;<br />
# alle Einträge Bio... und 4-wöchige Rest... ignorieren<br />
if (not $VALUE =~ /Bio/ and <br />
not $VALUE =~ /Restmülltonne..4/) {<br />
# readingname für bdate zum summary erzeugen<br />
my $rBdate = $READING =~ s/summary/bdate/r;;<br />
# readingvalue für bdate auslesen<br />
my $vDate = ReadingsVal($DEVICE,$rBdate,"");;<br />
# wenn value 'tonne' enthält dieses entfernen<br />
if ($VALUE =~ /tonne/) {<br />
$vDate . " " . substr($VALUE,0,index($VALUE,'tonne'));;<br />
} else {<br />
"$vDate %VALUE";;<br />
}<br />
} else {<br />
undef;;<br />
}<br />
}<br />
</syntaxhighlight><br />
Der Code in der cfg-Datei würde bei valueFormat zwischen den Hauptklammern immer ;;;; statt ;; und an jedem Zeilenende ein \ haben.<br />
<br />
=== Dynamische Inhalte ===<br />
[[Datei:rgDynamic-1.png|mini|450px|readingsGroup mit umschaltbarem Inhalt 1]]<br />
[[Datei:rgDynamic-2.png|mini|450px|readingsGroup mit umschaltbarem Inhalt 2]]<br />
Es ist möglich, den in einer readingsGroup dargestellten Inhalt dynamisch von zusätzlichen Bedingungen abhängig zu machen. Im folgenden Beispiel lässt sich<br />
einstellen, dass nur die Devices angezeigt werden, die einen bestimmten Zustand (hier: on/off, open/tilted/closed) haben. Hier wird zum Umschalten ein dummy, der direkt über der readingsGroup dargestellt wird, verwendet. Über das links und/oder commands lässt sich auch eine Darstellung erzeugen, bei der das Umschalten direkt innerhalb der readingsGroup möglich ist.<br />
<br />
<pre><br />
define LXrg dummy<br />
attr LXrg group -<br />
attr LXrg setList mode1:on,off mode2:open,closed,tilted<br />
attr LXrg stateFormat 1=mode1 2=mode2<br />
attr LXrg webCmd mode1:mode2<br />
<br />
define rg readingsGroup Window.*:state Light.*:state<br />
attr rg group -<br />
attr rg valueFormat { return $VALUE if ( $VALUE eq ReadingsVal("LXrg","mode1","") || $VALUE eq ReadingsVal("LXrg","mode2","") );; return undef;;}<br />
<br />
define Watch_LX notify LX.*:.* {my $value = ReadingsVal($NAME,'state','');;;;fhem("setreading $NAME $value")}<br />
</pre><br />
<br />
=== Enable/Disable Button am Beispiel eines WeekdayTimer ===<br />
Dieses Beispiel zeigt die Anwendung einer readingsGroup, um im Frontend einen Enable/Disable Button für ein Objekt darzustellen. Für den [[WeekdayTimer]] gibt es hier spezielle Erweiterungen (set Routinen, um das Attribut ''disable'' zu setzen). Es gibt aber auch eine allgemeinere Variante (siehe {{Link2Forum|Topic=23655|Message=169141|LinkText=diesen Forumsbeitrag}}) für alle Objekte, die das FHEM Attribut ''disable'' unterstützen.<br />
{| class="wikitable"<br />
! Definition !! Erläuterungen <br />
|-<br />
| colspan=2 | [[Datei:rg_scheduling.png|thumb|500px|links|Enable/Disable Button]]<br />
|-<br />
| style="width:40%" |<code>define rg_Timer_Wasser readingsGroup timer_Wasser_..:disabled,+DEF,<{rg_timer_Wasser_show_conditional($DEVICE,"nextUpdate")}@disabled>,<{rg_timer_Wasser_show_conditional($DEVICE,"nextValue")}@disabled></code><br />
| Definition der angezeigten Readings. Das Attribut ''disabled'' wird mit weiteren Einstellungen (''commands'') zum Button, +DEF zeigt die Definition, d.h. die Schaltzeiten, des Timers an. Die Readings nextUpdate und nextValue sollen nur angezeigt werden, falls der Timer aktiv ist. Hierfür sorgt eine Routine <code>rg_timer_Wasser_show_conditional</code>, die in der 99_myUtils.pm definiert wird. Das abschließende @disabled sorgt dafür, dass der LongPoll Mechanismus die Anzeige sofort ändert, wenn der Button betätigt wird. <br />
|-<br />
| <code>attr rg_Timer_Wasser valueFormat { if ( $READING =~ m/.*DEF/ ) { my @text = split(" ", $VALUE); shift @text; return join(" ", @text) }}</code><br />
| Der Name des Timers wird aus dem Internal "+DEF" vorne abgeschnitten. Damit werden nur die definierten Schaltpunkte angezeigt. <br />
|-<br />
| <code>attr rg_Timer_Wasser valueIcon { 'disabled.0' => 'Restart', 'disabled.1' => 'Shutdown' }</code><br />
| Die beiden Zustände für den Button werden durch zwei Standard-Icons angezeigt.<br />
|-<br />
| <code>attr rg_Timer_Wasser commands { 'disabled.0' => 'set $DEVICE disable', 'disabled.1' => 'set $DEVICE enable' }</code><br />
| Toggle-Funktion für den Button. Wenn der Timer aktiv ("disabled.0") sorgt ein Klick auf den Button, dass der Timer deaktiviert wird ("set $DEVICE disable").<br />
|-<br />
|<syntaxhighlight lang="perl"><br />
sub rg_timer_Wasser_show_conditional($$)<br />
{<br />
my ($DEVICE,$READING) = @_;<br />
return ( ReadingsVal($DEVICE, "disabled", "1") eq "0" )? <br />
ReadingsVal($DEVICE, $READING, "reading_undef") : "disabled";<br />
}</syntaxhighlight><br />
| Dieser Teil kommt in die [[99_myUtils_anlegen|99_myUtils.pm]]: Hiermit wird das übergebene Reading des Timers nur angezeigt, wenn der Timer aktiv ist. Andernfalls wird der String "disabled" angezeigt.<br />
|}<br />
<br />
=== Ändern von Attributen: Noch ein WeekdayTimer Beispiel ===<br />
{{Randnotiz|RNTyp=y|RNText=Dieses Beispiel benutzt Funktionen, die erst ab [[version|Modulversion]] 8761/16.6.2015 verfügbar sind.}}<br />
Inzwischen ist es auch möglich das commands Mapping auf Attribute anzuwenden. Die Syntax ist die gleiche wie für die set Kommandos. Um das Beispiel übersichtlich zu halten werden hier die Werte und Icons auch für deaktiviert WeekdayTimer angezeigt. <br />
<br />
{| class="wikitable"<br />
! Definition !! Erläuterungen <br />
|-<br />
| colspan=2 | [[Datei:rg_timer.png|thumb|500px|links|FHEMWidget für das 'disable' Attribut]]<br />
|-<br />
| style="width:40%" |<code>define rgTimer readingsGroup <>,<Current>,<Update-Time>,<New>,<disable> TYPE=WeekdayTimer:state,nextUpdate,nextValue,?!disable</code><br />
| Definition der angezeigten Readings. Das Attribut ''disable'' wird mit weiteren Einstellungen (''commands'') zum Button. Durch das ! wird das Attribut auch dann angezeigt wenn es noch nicht gesetzt ist. <br />
|-<br />
| <code>attr rgTimer valueIcon { state => '%devStateIcon', nextValue => '{(split(":",Color::devStateIcon($DEVICE,"dimmer",undef,"nextValue")))[1]}' }</code><br />
| Für den aktuellen Zustand wird das devStateIcon angezeigt und für den nächsten Zustand das passende Lampen-Icon.<br />
|-<br />
| <code>attr rgTimer valueFormat '{(split(" ", $VALUE))[1]}'</code><br />
| Vom nächsten Schaltpunkt wird nur die Zeit angezeigt. <br />
|-<br />
| <code>attr rgTimer commands { disable => 'disable:' }</code><br />
| Für das disable attribut wird das normale dropDown mit 0 und 1 angezeigt das auch in der Device Detail Ansicht verwendet wird.<br />
|}<br />
<br />
=== Readings löschen ===<br />
Es kann vorkommen, dass Readings angezeigt werden, die garnicht existieren sollten - bspw. wenn man in einer HTTPMOD ein Reading umbeannt hat, kann auch der alte Readingsname immernoch angezeigt werden. Solche Readings können mit der globalen Funktion [http://fhem.de/commandref.html#deletereading deletereading] gelöscht werden.<br />
<br />
'''Achtung:''' Auf jeden Fall die [http://fhem.de/commandref.html#deletereading CommandRef dazu] lesen!<br />
<br />
Beispiel:<br />
Im HTTPMOD des [[Pollenflug]] war zuerst das <code>reading04Name Graeser</code> definiert und wurde später in <code>reading04Name Gräser</code> umbenannt. In der zugehörigen ReadingGroup wurden dann konsequent beide Varianten dargestellt - auch nachdem alle Alt-Einträge aus den Logs entfernt wurden. Erst ein <code>deletereading Pollenflug Graeser</code> in der fhem-Befehltszeile hat das veraltete Reading entfernt.<br />
<br />
<br />
=== Ausrichtung der Tabelle drehen (horizontal/vertikal) ===<br />
Eine Readingsgroup wird standardmäßig immer zeilenweise aufgebaut, zB. jedes Gerät in eine neue Zeile. Die Werte der Geräte werden dann in den Spalten dargestellt. <br />
Wenn man eine Readingsgroup für nur ein Gerät mit vielen Readings hat (zB. [[Allergy]]), so kann man die Darstellung horizontal oder vertikal ausrichten, indem man die Readingsgroup detailliert definiert. Ein Bsp. dazu liefert der Foreneintrag {{Link2Forum|Topic=37194|Message=440446}} :<br />
<br />
<pre><br />
define Pollenflugvorhersage allergy <PLZ><br />
attr Pollenflugvorhersage levelsFormat rc_dot@white,rc_dot@yellow,rc_dot@orange,rc_dot@red<br />
attr Pollenflugvorhersage stateFormat fc1_maximum<br />
attr Pollenflugvorhersage updateEmpty 1<br />
attr Pollenflugvorhersage updateIgnored 1<br />
<br />
# Pollen in Spalten, Tage in Zeilen<br />
define PollenAlarmHorizontal readingsGroup <>,<Ampfer>,<Ambrosia>,<Beifuß>,<Birke>,<Buche>,<Eiche>,<Erle>,<Gräser>,<Hasel>,<Pappel>,<Roggen>,<Ulme>,<Wegerich>,<Weide> \<br />
Pollenflugvorhersage:fc1_day_of_week,fc1_Ampfer,fc1_Ambrosia,fc1_Beifuß,fc1_Birke,fc1_Buche,fc1_Eiche,fc1_Erle,fc1_Gräser,fc1_Hasel,fc1_Pappel,fc1_Roggen,fc1_Ulme,fc1_Wegerich,fc1_Weide \<br />
Pollenflugvorhersage:fc2_day_of_week,fc2_Ampfer,fc2_Ambrosia,fc2_Beifuß,fc2_Birke,fc2_Buche,fc2_Eiche,fc2_Erle,fc2_Gräser,fc2_Hasel,fc2_Pappel,fc2_Roggen,fc2_Ulme,fc2_Wegerich,fc2_Weide \<br />
Pollenflugvorhersage:fc3_day_of_week,fc3_Ampfer,fc3_Ambrosia,fc3_Beifuß,fc3_Birke,fc3_Buche,fc3_Eiche,fc3_Erle,fc3_Gräser,fc3_Hasel,fc3_Pappel,fc3_Roggen,fc3_Ulme,fc3_Wegerich,fc3_Weide \<br />
Pollenflugvorhersage:fc4_day_of_week,fc4_Ampfer,fc4_Ambrosia,fc4_Beifuß,fc4_Birke,fc4_Buche,fc4_Eiche,fc4_Erle,fc4_Gräser,fc4_Hasel,fc4_Pappel,fc4_Roggen,fc4_Ulme,fc4_Wegerich,fc4_Weide \<br />
Pollenflugvorhersage:fc5_day_of_week,fc5_Ampfer,fc5_Ambrosia,fc5_Beifuß,fc5_Birke,fc5_Buche,fc5_Eiche,fc5_Erle,fc5_Gräser,fc5_Hasel,fc5_Pappel,fc5_Roggen,fc5_Ulme,fc5_Wegerich,fc5_Weide \<br />
Pollenflugvorhersage:fc6_day_of_week,fc6_Ampfer,fc6_Ambrosia,fc6_Beifuß,fc6_Birke,fc6_Buche,fc6_Eiche,fc6_Erle,fc6_Gräser,fc6_Hasel,fc6_Pappel,fc6_Roggen,fc6_Ulme,fc6_Wegerich,fc6_Weide \<br />
Pollenflugvorhersage:fc7_day_of_week,fc7_Ampfer,fc7_Ambrosia,fc7_Beifuß,fc7_Birke,fc7_Buche,fc7_Eiche,fc7_Erle,fc7_Gräser,fc7_Hasel,fc7_Pappel,fc7_Roggen,fc7_Ulme,fc7_Wegerich,fc7_Weide<br />
attr PollenAlarm nonames 1<br />
attr PollenAlarm valueFormat %VALUE<br />
attr PollenAlarm valueIcon %VALUE<br />
<br />
# Tage in Spalten, Pollen in Zeilen<br />
define PollenAlarmVertikal readingsGroup Pollenflugvorhersage:<Pollen>,fc0_day_of_week,fc1_day_of_week,fc2_day_of_week,fc3_day_of_week,fc4_day_of_week,fc5_day_of_week,fc6_day_of_week,fc7_day_of_week \<br />
Pollenflugvorhersage:<Ambrosia>,fc0_Ambrosia,fc1_Ambrosia,fc2_Ambrosia,fc3_Ambrosia,fc4_Ambrosia,fc5_Ambrosia,fc6_Ambrosia,fc7_Ambrosia\<br />
Pollenflugvorhersage:<Ampfer>,fc0_Ampfer,fc1_Ampfer,fc2_Ampfer,fc3_Ampfer,fc4_Ampfer,fc5_Ampfer,fc6_Ampfer,fc7_Ampfer\<br />
Pollenflugvorhersage:<Beifuß>,fc0_Beifuss,fc1_Beifuss,fc2_Beifuss,fc3_Beifuss,fc4_Beifuss,fc5_Beifuss,fc6_Beifuss,fc7_Beifuss\<br />
Pollenflugvorhersage:<<b>Birke<Birke</b>>,fc0_Birke,fc1_Birke,fc2_Birke,fc3_Birke,fc4_Birke,fc5_Birke,fc6_Birke,fc7_Birke\<br />
Pollenflugvorhersage:<Buche>,fc0_Buche,fc1_Buche,fc2_Buche,fc3_Buche,fc4_Buche,fc5_Buche,fc6_Buche,fc7_Buche\<br />
Pollenflugvorhersage:<Eiche>,fc0_Eiche,fc1_Eiche,fc2_Eiche,fc3_Eiche,fc4_Eiche,fc5_Eiche,fc6_Eiche,fc7_Eiche\<br />
Pollenflugvorhersage:<<b>Erle<Erle</b>>,fc0_Erle,fc1_Erle,fc2_Erle,fc3_Erle,fc4_Erle,fc5_Erle,fc6_Erle,fc7_Erle\<br />
Pollenflugvorhersage:<Gräser>,fc0_Graeser,fc1_Graeser,fc2_Graeser,fc3_Graeser,fc4_Graeser,fc5_Graeser,fc6_Graeser,fc7_Graeser\<br />
Pollenflugvorhersage:<<b>Hasel<Hasel</b>>,fc0_Hasel,fc1_Hasel,fc2_Hasel,fc3_Hasel,fc4_Hasel,fc5_Hasel,fc6_Hasel,fc7_Hasel\<br />
Pollenflugvorhersage:<Pappel>,fc0_Pappel,fc1_Pappel,fc2_Pappel,fc3_Pappel,fc4_Pappel,fc5_Pappel,fc6_Pappel,fc7_Pappel\<br />
Pollenflugvorhersage:<Roggen>,fc0_Roggen,fc1_Roggen,fc2_Roggen,fc3_Roggen,fc4_Roggen,fc5_Roggen,fc6_Roggen,fc7_Roggen\<br />
Pollenflugvorhersage:<Ulme>,fc0_Ulme,fc1_Ulme,fc2_Ulme,fc3_Ulme,fc4_Ulme,fc5_Ulme,fc6_Ulme,fc7_Ulme\<br />
Pollenflugvorhersage:<Wegerich>,fc0_Wegerich,fc1_Wegerich,fc2_Ulme,fc3_Wegerich,fc4_Wegerich,fc5_Wegerich,fc6_Wegerich,fc7_Wegerich\<br />
Pollenflugvorhersage:<Weide>,fc0_Weide,fc1_Weide,fc2_Weide,fc3_Weide,fc4_Weide,fc5_Weide,fc6_Weide,fc7_Weide<br />
</pre><br />
<br />
== Berechnungen ==<br />
{{Randnotiz|RNTyp=y|RNText=Dieses Beispiel benutzt Funktionen, die erst ab [[version|Modulversion]] 8761/16.6.2015 verfügbar sind.}}<br />
Das Rechnen funktioniert über das Flag "$", mit dem eine Funktion angegeben werden kann, die auf beliebige Kombinationen von Zeilen, Spalten und einzelnen Zellen angewendet wird. Ähnlich wie in einer Tabellenkalkulation.<br />
<br />
Ein Beispiel:<br />
:<code>define rg readingsGroup .*:temperature rg:$avg</code><br />
Damit wird eine readingsGroup über alle ''temperature'' Readings definiert. In einer zusätzlichen Zeile am Ende wird mit ''$avg'' der Durchschnittswert aller darüber liegenden Temperaturen angezeigt.<br />
<br />
Das genaue Format: <code>$<operator>[(<zellen>)]</code> mit<br />
*<code><operator></code>: sum, avg, min, max, scalar, count oder der Name einer beliebigen anderen Funktion, die ein Array mit allen Werten übergeben bekommt und ein Ergebnis zurückliefert.<br />
*<code><zellen></code> ist eine durch Semikolon getrennte Liste aus <code><zeilen>:<spalten></code> Paaren. <br />
*<code><zeilen></code> und <code><spalten></code> sind jeweils eine Perl Liste, d.h. hier können <br />
** einzelne Werte,<br />
** durch Komma getrennte Aufzählungen,<br />
** mit .. angegebene Wertebereiche<br />
** sowie <code>$ROW</code> und <code>$COLUMN</code> als Bezeichner für die aktuelle Zelle<br />
:verwendet werden.<br />
<br />
Alle Möglichkeiten sind kombinierbar. Die Zählung der Zeilen und Spalten beginnt bei 1. Eine nicht vorhandene Zeilenangabe wird durch den Bereich von Zeile 1 bis zur aktuellen Zeile ersetzt, eine nicht vorhandene Spalte durch die aktuelle Spalte.<br />
<br />
Es ergeben sich somit unter anderem folgende Möglichkeiten:<br />
*<code>$sum</code> equivalent zu <code>$sum(1..$ROW), $sum(:$COLUMN)</code> und <code>$sum(1..$ROW:$COLUMN)</code> die Summe der Werte in der Spalte über der aktuellen Zelle.<br />
*<code>$max($ROW:1..$COLUMN-1)</code> Maximum aller Werte links von der aktuellen Zelle (in der aktuellen Zeile)<br />
*<code>$avg(1..$ROW:1)</code> Durchschnitt aller Werte in Spalte 1 bis zur aktuellen Zeile<br />
*<code>$scalar(:1)</code> Anzahl der Werte in Spalte 1<br />
*<code>$min(1..5:1,2,4)</code> Minimum der Werte aus den Zeilen 1-5 in den Spalten 1, 2 und 4<br />
<br />
Eigene Funktionen lassen sich über 99_myUtils anlegen und z.B. verwenden um Häufigkeiten zu zählen oder mit nichtnumerischen Readings umzugehen.<br />
<br />
Die Ergebnisse werden im Weiteren wie normale Readings behandelt. Sie lassen sich von links oben nach rechts unten kaskadieren und lassen sich über valuePrefix, valueSuffix, valueFormat und valueStyle in der Darstellung beeinflussen. Also z.B. einfärben, als Balkendiagramm darstellen, ...<br />
<br />
Mit Hilfe der Funktionalität zum auf- und zu-klappen von Teilen einer readingsGroup lassen sich z.B. im zusammengeklappten Zustand Summen, Extremwerte oder andere Ausreißer anzeigen und die Details nur beim Aufklappen zeigen.<br />
<br />
Weitere Möglichkeiten:<br />
* Attribut <code>firstCalcRow</code>: Hiermit kann der Default für die Nummer der ersten Zeile vorgegeben werden (sofern im Ausdruck nichts genaueres angegeben ist). firstCalcRow sollte z.B. auf 2 gesetzt werden, wenn in der readingsGroup Spaltenüberschriften verwendet werden.<br />
* special <code><nowiki><hr></nowiki></code> um eine horizontale Linie über die volle Breite einzufügen<br />
* Über ein angehängtes <code>@<alias></code> kann einem Rechenergebniss ein Alias-Name gegeben werden. Über diesen kann der Wert dann zur Formatierung mit den value-Attributen angesprochen werden.<br />
* das <code>alwaysTrigger</code> Attribut kann jetzt auch den Wert 2 bekommen. Damit werden in der readingsGroup Readings für alle durch die Aggregation gebildeten Werte und entsprechende Events auch dann erzeugt wenn die readingsGroup nicht angezeigt wird. Wenn ein Alias-Name vergeben ist, wird dieser auch für den Reading-Namen verwendet.<br />
* Über den operator <code>$count(<wert>)(<zellen>)</code> um das Vorkommen von <code><wert></code> in den angegebenen Zellen zu zählen. <code><wert></code> kann enweder direkt der zu zählende Wert sein (ohne Anführungzeichen) oder eine in / eingeschlossene regex. Mit <code>!<wert></code> kann das Nicht-Vorkommen von <code><wert></code> gezählt werden.<br />
<br />
=== Ein interaktives Beispiel ===<br />
[[Datei:rgCalc.png|mini|right|400px|Beispiel-readingsGroup mit Berechnungen]]<br />
In drei [[dummy]] Objekten lässt sich jeweils ein Reading über einen Slider einstellen. In der darunter liegenden readingsGroup werden diese Readings und diverse daraus abgeleitete Werte dargestellt. Alle Readings und die daraus abgeleiteten Werte werden live per longpoll aktualisiert, wenn die slider bewegt werden.<br />
<br clear=all><br />
<pre><br />
define t1 dummy<br />
attr t1 room rg<br />
attr t1 setList state:slider,-10,1,30<br />
attr t1 webCmd state<br />
define t2 dummy<br />
attr t2 room rg<br />
attr t2 setList state:slider,-10,1,30<br />
attr t2 webCmd state<br />
define t3 dummy<br />
attr t3 room rg<br />
attr t3 setList state:slider,-10,1,30<br />
attr t3 webCmd state<br />
<br />
define rg readingsGroup <>,<value>,<sum>,<min>,<max>,<avg>\<br />
t\d:+NAME,state,$sum(1..$ROW:2),$min(1..$ROW:2),$max(1..$ROW:2),$avg(1..$ROW:2)\<br />
<hr>\<br />
rg:<>,$scalar,$sum(:2)@SUM,$min(:2)@MIN,$max(:2)@MAX,$avg(:2)@AVG\<br />
<hr>\<br />
t1:<t1,t2,t3>,state,state@t2,state@t3,$sum($ROW:2..4)@SUM,$count(/\d/)(2..$ROW-4:2)\<br />
<br />
attr rg nonames 1<br />
attr rg room rg<br />
attr rg style style='text-align:center'<br />
attr rg valueFormat { 'avg' => '%.2f', 'AVG' => '%.2f' }<br />
attr rg valuePrefix { 'rg.scalar' => '#', 'rg.SUM' =>'&Sigma;; ', 'rg.MIN' =>'Min: ', 'rg.MAX' =>'Max: ', 'rg.AVG' =>'&empty;; ', 'rg.count' => '#(X): ' }<br />
attr rg valueSuffix { state => '&deg;;C' }<br />
</pre><br />
<br />
== Links und Trigger ==<br />
=== readingsGroup mit Link ===<br />
[[Datei:rgPCA-detail.png|mini|400px|readingsGroup mit Link]]<br />
Das PCA301 Beispiel oben lässt sich mit einem ans Ende des define angehängten <br />
:<code><{appendTrigger($DEVICE,"clear","Alle löschen")}></code> <br />
und der folgenden appendTrigger Definition in 99_myUtils.pm um einen Link erweitern, der ein Event auslöst, an das z.B. ein notify gehängt werden kann, um die Verbrauchszähler der PCA301 Dosen zurückzusetzen. <br />
:<code>define clearVerbrauch notify Verbrauch:clear set TYPE=PCA301 clear</code><br />
<br />
<syntaxhighlight lang="perl"><br />
use vars qw($FW_ME);<br />
use vars qw($FW_subdir);<br />
sub<br />
appendTrigger($$$)<br />
{<br />
my ($name,$trigger,$label) = @_; <br />
<br />
my $ret .= "</table></td></tr>";<br />
<br />
my $link = "cmd=trigger $name $trigger";<br />
my $txt = "<a onClick=\"FW_cmd('$FW_ME$FW_subdir?XHR=1&$link')\">$label</a>";<br />
$ret .= "<td colspan=\"99\"><div style=\"cursor:pointer;color:#888888;text-align:right\">$txt</div></td>";<br />
<br />
return ($ret,0);<br />
}</syntaxhighlight><br />
<br />
wenn hierdurch Änderungen an einer readingsGroup erfolgen, die ein Neuladen der Seite erforderlich machen, kann dies so erfolgen:<br />
:<code>{myUtils_refresh("WEB")}</code><br />
mit folgendem code in 99_myUtils.pm:<br />
<syntaxhighlight lang="perl"><br />
sub <br />
myUtils_refresh($) <br />
{ <br />
my ($name) = @_; <br />
<br />
FW_directNotify("#FHEMWEB:$name", "location.reload(true);","" );<br />
}</syntaxhighlight><br />
<br />
<br />
Ein weiteres Beispiel für 'custom links und trigger' findet sich in {{Link2Forum|Topic=14425|Message=109383|LinkText=diesem Forenbeitrag}}: dort wird damit eine readingsGroup dynamisch umgeschaltet, um nur die eingeschalteten, nur die ausgeschalteten oder alle Lampen anzuzeigen.<br />
<br />
=== sub rg ===<br />
Damit beim klicken auf ein Icon oder einen Text in einer readingsGroup etwas passiert ist es möglich dies über das commands Attribut auf ein <code>'trigger ntfy_rg $DEVICE $READING'</code> oder Ähnliches zu mappen.<br />
Anlegen des ntfy_rg notify<br />
<pre><br />
define ntfy_rg notify ntfy_rg {rg($EVENT)}<br />
</pre><br />
Folgender Code muss noch in de [[99_myUtils_anlegen|99_myUtils.pm]]<br />
<syntaxhighlight lang="perl"><br />
sub rg($){<br />
my @input = split(/[§\s]+/,shift);<br />
my $device = $input[0];<br />
my $function = $input[1];<br />
<br />
if($function eq "clima"){<br />
my $room = AttrVal($device, 'room', 'undef');<br />
$room =~ s/\D//g;<br />
<br />
return(("d_climaControl_".$room));<br />
}<br />
elsif($function eq "device"){<br />
return InternalVal($device,"device","device error");<br />
}<br />
elsif($function eq "controlMode"){<br />
my $controlMode = ReadingsVal($device,"controlMode","controlMode error");<br />
<br />
if($controlMode ~~ /manual/)<br />
{fhem("set $device controlMode auto")}<br />
elsif($controlMode ~~ /auto/)<br />
{fhem("set $device controlMode manual")};<br />
}<br />
elsif($function eq "globalBtnLock"){<br />
my $globalBtnLock = ReadingsVal($device,"R-globalBtnLock","globalBtnLock error");<br />
<br />
if($globalBtnLock ~~ /off/){<br />
{fhem("set $device regSet globalBtnLock on")}<br />
{fhem ("set $device getConfig")}<br />
}<br />
elsif($globalBtnLock ~~ /on/){<br />
{fhem("set $device regSet globalBtnLock off")}<br />
{fhem ("set $device getConfig")}<br />
};<br />
}<br />
elsif($function eq "state"){<br />
my $state = Value($device);<br />
<br />
if($state ~~ /off/){<br />
{fhem("set $device on")}<br />
}<br />
elsif($state ~~ /on/){<br />
{fhem("set $device off")}<br />
};<br />
}<br />
elsif($function eq "setTimeTable"){<br />
my $room = AttrVal($device, 'room', 'undef');<br />
$room =~ s/\D//g;<br />
my $climaControl = ("d_climaControl_".$room);<br />
my $dayTemp = ReadingsVal( $climaControl, "dayTemp" , 21.0 );<br />
my $nightTemp = ReadingsVal( $climaControl, "nightTemp" , 17.0 );<br />
my $workday_period_1_start = ReadingsVal( $climaControl, "workday_period_1_start" , "06:30" );<br />
my $workday_period_1_stop = ReadingsVal( $climaControl, "workday_period_1_stop" , "18:00" );<br />
my $workday_period_2_start = ReadingsVal( $climaControl, "workday_period_2_start" , "24:00" );<br />
my $workday_period_2_stop = ReadingsVal( $climaControl, "workday_period_2_stop" , "24:00" );<br />
my $saturday_period_1_start = ReadingsVal( $climaControl, "saturday_period_1_start" , "06:30" );<br />
my $saturday_period_1_stop = ReadingsVal( $climaControl, "saturday_period_1_stop" , "12:00" );<br />
my $saturday_period_2_start = ReadingsVal( $climaControl, "saturday_period_2_start" , "24:00" );<br />
my $saturday_period_2_stop = ReadingsVal( $climaControl, "saturday_period_2_stop" , "24:00" );<br />
my $sunday_period_1_start = ReadingsVal( $climaControl, "sunday_period_1_start" , "24:00" );<br />
my $sunday_period_1_stop = ReadingsVal( $climaControl, "sunday_period_1_stop" , "24:00" );<br />
my $sunday_period_2_start = ReadingsVal( $climaControl, "sunday_period_2_start" , "24:00" );<br />
my $sunday_period_2_stop = ReadingsVal( $climaControl, "sunday_period_2_stop" , "24:00" );<br />
<br />
{fhem("set $device tempListMon prep $workday_period_1_start $nightTemp $workday_period_1_stop $dayTemp $workday_period_2_start $nightTemp $workday_period_2_stop $dayTemp 24:00 $nightTemp")};<br />
{fhem("set $device tempListTue prep $workday_period_1_start $nightTemp $workday_period_1_stop $dayTemp $workday_period_2_start $nightTemp $workday_period_2_stop $dayTemp 24:00 $nightTemp")};<br />
{fhem("set $device tempListWed prep $workday_period_1_start $nightTemp $workday_period_1_stop $dayTemp $workday_period_2_start $nightTemp $workday_period_2_stop $dayTemp 24:00 $nightTemp")};<br />
{fhem("set $device tempListThu prep $workday_period_1_start $nightTemp $workday_period_1_stop $dayTemp $workday_period_2_start $nightTemp $workday_period_2_stop $dayTemp 24:00 $nightTemp")};<br />
{fhem("set $device tempListFri prep $workday_period_1_start $nightTemp $workday_period_1_stop $dayTemp $workday_period_2_start $nightTemp $workday_period_2_stop $dayTemp 24:00 $nightTemp")};<br />
{fhem("set $device tempListSat prep $saturday_period_1_start $nightTemp $saturday_period_1_stop $dayTemp $saturday_period_2_start $nightTemp $saturday_period_2_stop $dayTemp 24:00 $nightTemp")};<br />
{fhem("set $device tempListSun exec $sunday_period_1_start $nightTemp $sunday_period_1_stop $dayTemp $sunday_period_2_start $nightTemp $sunday_period_2_stop $dayTemp 24:00 $nightTemp")};<br />
}<br />
}<br />
</syntaxhighlight><br />
Hier sind die benötigten CodeBlöcke für [[ReadingsGroup#Heizungswerte.2C_Status.2C_Steuerung_und_Wochenprofil|Heizungswerte, Status, Steuerung und Wochenprofil]] enthalten, aber auch um state zu triggern.<br />
<br />
== Sonstiges ==<br />
In der Regel werden die Parameter zu einem reading in den mappings unter <$DEVICE> und dann <$DEVICE>.<$READING> und dann unter <$READING>.<$VALUE> gesucht.<br />
<br />
=== Lesbar machen ===<br />
Für die meisten Attribute gilt:<br />
<br />
* Wenn es komplexer wird ist es einfacher, den Code in eine eigene Routine in (beispielsweise) [[99 myUtils anlegen|99_myUtils]] auszulagern und diese aufzurufen:<br />
:<code> attr <name> valueStyle {myValueToFormat($READING,$VALUE)}</code><br />
* code für unterschiedliche readings kann auch im mapping schon aufgeteilt werden:<br />
:<code>attr <name> valueStyle { SuperE5 => '{perl code}', Diesel => '{perl code}' }</code><br />
* Ifs lassen sich verschachteln und sortieren. So kann die Anzahl der Klammern und Else-Zweige reduziert werden:<br />
if( $READING eq ... ) {<br />
return xxx if( $VALUE < 1 );<br />
return yyy if( $VALUE < 1.5 );<br />
return zzz;<br />
} elsif( $READING eq ... ) {<br />
...<br />
}<br />
<br />
Da alles lässt sich natürlich auch kombinieren und so viel lesbarer machen als ein einziger langer Bandwurm.<br />
<br />
=== readingsGroup in einer Gruppe ===<br />
Wenn der doppelte Rahmen um eine readingsGroup bei Darstellung in einer Gruppe stört, lässt er sich mit dem passenden style entfernen: <br />
:<code>attr <rgName> style style="border:0px;background:none;box-shadow:none"</code> <br />
Für die readingsGroup ''rgName'' wird der Darstellungsstil verändert.<br />
<br />
Anwendungs-Bsp: [[Pollenflug]]<br />
<br />
=== Einfache Balkendiagramme ===<br />
[[Datei:rgBars.png|mini|400px|readingsGroup mit Balken]]<br />
Readings lassen sich mit einem valueStyle der folgenden Art mit einem "Füllstandsbalken" hinterlegen:<br />
:<code>attr <rgName> valueStyle style="width:200px; text-align:center; border: 1px solid #ccc; background:-webkit-linear-gradient(left, red $VALUE%, rgba(0,0,0,0) $VALUE%)"</code><br />
<br />
Die Balken werden bei Änderungen der Readings automatisch per longpoll aktualisiert.<br />
<br />
Diese direkte Definition des <code>valueStyle</code> ist allerdings sehr unflexibel - bspw. müsste der <code>$VALUE</code> zufällig max 100 erreichen und es darf nur ein Browsertyp eingesetzt werden, damit alles sauber funktioniert. <br />
<br />
Deutlich flexibler ist eine Auslagerung als eigenständige Funktion in die [[99_myUtils_anlegen|99_myUtils.pm]], die den valueStyle dynamisch generiert, bspw.:<br />
<br />
<syntaxhighlight lang="perl"><br />
sub Balkenanzeige($) <br />
{<br />
# Zuweisung der übergebenen Variablen<br />
my ($val) = @_;<br />
<br />
# Konfiguration des maximal übergebenen Werts (hier wäre der höchste zu erwartende Wert = 3)<br />
my $maxValue = 3;<br />
<br />
# Normalisierung auf 100%-Wert<br />
my $percent = $val / $maxValue * 100;<br />
<br />
# Definition des valueStyles<br />
my $stylestring = 'style="'.<br />
'width: 200px; '.<br />
'text-align:center; '.<br />
'border: 1px solid #ccc ;'. <br />
'background-image: -webkit-linear-gradient(left,red '.$percent.'%, rgba(0,0,0,0) '.$percent.'%); '.<br />
'background-image: -moz-linear-gradient(left,red '.$percent.'%, rgba(0,0,0,0) '.$percent.'%); '. <br />
'background-image: -ms-linear-gradient(left,red '.$percent.'%, rgba(0,0,0,0) '.$percent.'%); '. <br />
'background-image: -o-linear-gradient(left,red '.$percent.'%, rgba(0,0,0,0) '.$percent.'%); '. <br />
'background-image: linear-gradient(left,red '.$percent.'%, rgba(0,0,0,0) '.$percent.'%);"';<br />
<br />
# Rückgabe des definierten Strings<br />
return $stylestring;<br />
}<br />
</syntaxhighlight><br />
<br />
Der Aufruf sähe dann wie folgt aus:<br />
<br />
<code> attr <rgName> valueStyle { Balkenanzeige($VALUE) } </code><br />
<br />
Die einzelnen Werte des <code>$stylestring</code> haben folgende Bedeutungen:<br />
* width - Breite des Balkenrahmens<br />
* text-align - Ausrichtung des Texts<br />
* border - Format des Balkenrahmens<br />
* background-image - Format des Hintergrunds des Balkenrahmens, also des Balkens selbst<br />
** linear-gradient - css-Funktion zur Erstellung von Farbverläufen ''(*)''<br />
*** left - linksbündiger Balken<br />
*** red x% - roter Balken x% breit<br />
*** rgba(0,0,0,0) x% - farbloser Teil startet bei x%<br />
<br />
''(*) linear-gradient wird in verschiedenen Browsern unterschiedlich umgesetzt. Deshalb sollten immer alle Varianten zusammen angegeben werden, damit die Darstellung auf allen Browsern funktioniert. (vgl. Link unten)''<br />
<br />
Weitere Infos zu:<br />
* linear-gradient - [https://developer.mozilla.org/de/docs/Web/CSS/linear-gradient]<br />
* Farbanpassungen, z.B. auch unter Verwendung der [[Color#Skalenfarbe_mit_Color::pahColor|Color::pahColor]] Routine.<br />
* Anpassung von Werten s.o. [[ReadingsGroup#Lesbar_machen]]<br />
* weiteren Möglichkeiten zur Erzeugung von Balkendiagrammen in Forenbeiträgen {{Link2Forum|Topic=25313|LinkText=hier}} und {{Link2Forum|Topic=28318|LinkText=hier}}<br />
* [[99_myUtils_anlegen|99_myUtils.pm]]<br />
<br />
Anwendungs-Bsp: [[Pollenflug]]<br />
<br />
=== readingsGroup Styling mit CSS ===<br />
Jede readingsGroup lässt sich durch CSS individuell stylen. <br />
<br />
==== Allgemeines ====<br />
Damit der eigene CSS Code nach einem [[Update]] der FHEM-Style Dateien vorhanden bleibt, ist es notwenig eine eigene .css Datei (zB ios7ReadingsGroups.css) zu erstellen und ins Verzeichnis ''fhem/www/pgm2/'' zu kopieren. Anschließend muss in der [[FHEMWEB]] Instanz das Attribut ''CssFiles'' auf zB ''pgm2/ios7ReadingsGroups.css'' gesetzt werden.<br />
<br />
==== Erweiterte Device Übersicht ====<br />
Diese ReadingsGroup ist an der [[FHEMWEB]] Device-Übersicht angelehnt. Zusätzlich werden weitere Readings, hier Leistung, Betriebszeit Heute und Jahr, ein Link zu Detail-Seite der ReadingsGroup und Links zu den jeweiligen Device-Detail-Seite, dargestellt.<br />
<br />
{| class="wikitable"<br />
| [[Datei:RgStylingOhneCss.png|600px|mini|left|Device ReadingsGroup ohne CSS]] [[Datei:RgStylingMitCss.png|600px|mini|left|Device ReadingsGroup mit CSS]]<br />
|}<br />
<br />
===== Definition =====<br />
<pre><br />
define rg_devices readingsGroup <{rgLink($DEVICE,"konfigurieren","Details")}>,<Device>,<Status>,<Leistung>,<Heute>,<Jahr>\<br />
wzDeckenfluter:<%light_floor_lamp>,<{rgLink("wzDeckenfluter","detail","Deckenfluter")}>,state,<>,dauerHeute,dauerJahr\<br />
wzMacMini:<%it_nas>,<{rgLink("wzMacMini","detail","MacMini")}>,state,power,consumption,consumptionYear\<br />
attr rg_devices noheading 1<br />
attr rg_devices nonames 1<br />
attr rg_devices notime 1<br />
attr rg_devices room ReadingsGroup Styling<br />
attr rg_devices style class="block wide rgDevices"<br />
attr rg_devices valueFormat { 'power' => "%.1f W ", consumption => "%.2f kWh", 'consumptionYear' => "%.2f kWh" }<br />
attr rg_devices valueIcon { state => '%devStateIcon' }<br />
</pre><br />
<br />
Damit sich der CSS auf die richtige readingsGroup bezieht, ist es nötigt <br />
das Attribut ''style'' anzupassen.<br />
{| class="wikitable"<br />
! Definition !! Erläuterungen <br />
|-<br />
| style="width:40%" |<code>attr <rgName> style class="block wide rgDevices"</code><br />
| Die Klassen ''block'' und ''wide'' müssen eingetragen werden. Der Name der Nachfolgenden Klasse, hier ''rgDevices'', ist frei wählbar.<br />
|}<br />
===== Funktion rgLink() =====<br />
Die Funktion rgLink($name,$action,$label) liefert einen Link mit dem Namen $label zurück. Der Code gehört in die [[99 myUtils anlegen|99_myUtils.pm]].<br />
* $name - Name des Device das aufgerufen werden soll <br />
* $action - Aktion die Ausgeführt werden soll. <br />
**''konfigurieren'' erzeugt den kleinen ''Details'' Button links oben der einem zur Detail Seite der ReadingsGroup führt - nützlich wenn das ReadingsGroup-Attribut ''noheading'' gesetzt ist<br />
** ''detail'' erzeugt einen Link zu Device-Detail Seite<br />
* $label - Link-Name<br />
<syntaxhighlight lang="perl"><br />
sub rgLink($$$){<br />
my ($name,$action,$label) = @_; <br />
my $link = "";<br />
my $fhemLink = "";<br />
my $txt = "";<br />
my $ret = "";<br />
my $divStyle = "";<br />
my $aStyle = "";<br />
<br />
# FHEM Variablen einbinden<br />
use vars qw($FW_ME);<br />
use vars qw($FW_subdir);<br />
use vars qw($FW_ss);<br />
use vars qw($FW_tp);<br />
<br />
if( $action eq "konfigurieren" ){<br />
$fhemLink = "detail=$name";<br />
$divStyle = "cursor:pointer;font-size:11px;padding-bottom:2px;padding-left:3px;";<br />
}<br />
elsif( $action eq "detail" ){<br />
$fhemLink = "detail=$name";<br />
$divStyle = "cursor:pointer;display:inline;";<br />
}<br />
<br />
$link = '<a onclick="location.href=\'' . $FW_ME . $FW_subdir . '?' . $fhemLink . '\'" style="' . $aStyle . '">' . $label . '</a>';<br />
$txt = '<div style="' . $divStyle . '">' . $link . '</div>';<br />
$ret = "$txt";<br />
<br />
return $ret;<br />
}<br />
</syntaxhighlight><br />
<br />
{{Randnotiz|RNText=Tipp<br />
Verwende zum Bearbeiten der eigenen .css Dateien entweder den [[Konfiguration#Syntaxhervorhebung|Codemirror Editor]] oder einen eigenen Editor mit [http://de.wikipedia.org/wiki/Syntaxhervorhebung Syntax Highlighting] . Das hilft bei der Fehlersuche enorm. }}<br />
<br />
===== Styling =====<br />
Die eigene .css Datei erscheint in FHEM unter Edit-Files --> styles und kann direkt im FHEM-Editor oder mit eigenen Editor bearbeitet werden.<br />
<br />
ios7ReadingsGroups.css:<br />
<pre><br />
/* Readings Groups Devices */<br />
table.rgDevices tr td{ text-align: center; }<br />
table.rgDevices tr:first-child td:nth-child(2){ /* 1. Zeile 2. Spalte */ text-align: center; }<br />
table.rgDevices tr td:first-child{ /* 1. Spalte */ width: 45px; text-align: center; }<br />
table.rgDevices tr td:nth-child(2){ /* 2. Spalte */ width: 33%; text-align: left; }<br />
table.rgDevices tr td:nth-child(3){ /* 3. Spalte */ width: 15%; }<br />
table.rgDevices tr td:nth-child(4){ /* 4. Spalte */ width: 15%; }<br />
table.rgDevices tr td:nth-child(5){ /* 5. Spalte */ width: 15%; }<br />
</pre><br />
<br />
==== Auf Portrait / Landscape Modus des Smartphone unterscheiden ====<br />
Dieses Beispiel ist an das obige Beispiel [[#Erweiterte_Device_.C3.9Cbersicht|Erweiterte Device Übersicht]] angelehnt. <br />
<br />
{| class="wikitable"<br />
| style="width:40%" |[[Datei:RgStylingSmallscreenPortrait.png|300px|mini|center|Device ReadingsGroup im Portrait Modus]]<br />
|[[Datei:RgStylingSmallscreenLandscape.png|550px|mini|center|Device ReadingsGroup im Landscape Modus]]<br />
|}<br />
<br />
===== Allgemeines =====<br />
Mit CSS ist man in der Lage auf die aktuelle Bildschirmlage zu reagieren. Alle Anweisungen die in diesen beiden Funktionen zwischen den beiden { } stehen, werden je nach Bildschirmlage aufgerufen<br />
<pre><br />
/* Portrait Modus */<br />
@media all and (orientation:portrait) { }<br />
<br />
/* Landscape Modus */<br />
@media all and (orientation:landscape) { }<br />
</pre><br />
<br />
===== Styling =====<br />
{{Randnotiz|RNText=Info<br />
* ''width: xx%'' ändert die Breite der Spalte<br />
* ''display: none'' blendet die Spalte aus}}<br />
In der FHEMWEB_phone Instanz muss wie [[#Allgemeines|hier]] beschrieben eine neue eigene .css Datei eingetragen werden. In diesem Beispiel ios7smallscreenReadingsGroups.css<br />
<br />
ios7smallscreenReadingsGroups.css<br />
<pre><br />
/* landscape und portrait modus */<br />
table.rgDevices tr td { /* Zuerst alles centern */ text-align: center; }<br />
table.rgDevices tr:first-child td:nth-child(1){ /* 1. Zeile 1. Spalte */ text-align: center; }<br />
table.rgDevices tr td:first-child { /* 1. Spalte */ width: 5%; }<br />
table.rgDevices tr:first-child td:nth-child(2) { /* 1. Zeile 2. Spalte */ text-align: center; }<br />
table.block table tr td table.rgDevices tr td { border-bottom: 1px solid #cbcbcb; }<br />
<br />
/* Portrait Modus */<br />
@media all and (orientation:portrait) {<br />
table.rgDevices tr td:nth-child(2){ /* 2. Spalte */ width: 50%; text-align: left; }<br />
table.rgDevices tr td:nth-child(3){ /* 3. Spalte */ width: auto; text-align: right; display: table-cell; }<br />
table.rgDevices tr td:nth-child(4){ /* 4. Spalte */ width: 0; display: none; }<br />
table.rgDevices tr td:nth-child(5){ /* 5. Spalte */ width: 0; display: none; }<br />
table.rgDevices tr td:nth-child(6){ width: 0; display: none; } <br />
table.rgDevices tr td div a svg{ margin-left: 90px; }<br />
}<br />
<br />
/* Landscape Modus */<br />
@media all and (orientation:landscape) { <br />
table.rgDevices tr td:nth-child(2){ /* 2. Spalte */ width: 35%; text-align: left; }<br />
table.rgDevices tr td:nth-child(3){ /* 3. Spalte */ width: 15%; }<br />
table.rgDevices tr td:nth-child(4){ /* 4. Spalte */ width: 15%; }<br />
table.rgDevices tr td:nth-child(5){ /* 5. Spalte */ width: 15%; }<br />
table.rgDevices tr td:nth-child(5){ /* 5. Spalte */ width: 15%; } <br />
}<br />
</pre><br />
<br />
==== Plots im Portrait Modus des Smartphones ausblenden ====<br />
{| class="wikitable"<br />
| style="width:40%" |[[Datei:RgStylingSmallscreenPortraitPlot.png|350px|mini|center|Device ReadingsGroup im Portrait Modus]]<br />
|[[Datei:RgStylingSmallscreenLandscapePlot.PNG|550px|mini|center|Plot nur im Landscape]]<br />
|}<br />
<br />
Um die Plot und alle Steuerelemente im Portrait Modus auszublenden fügt man in seine eigene smallscreen.css wie [[#Allgemeines|hier beschrieben]] folgendes ein:<br />
<pre><br />
@media all and (orientation:portrait) {<br />
.SVGplot, .SVGlabel, .Zoom-in, .Zoom-out, .Prev { width: 0; display: none; }<br />
}<br />
</pre><br />
<br />
[[Kategorie:HOWTOS]]<br />
[[Kategorie:Code Snippets]]</div>MGuhttp://wiki.fhem.de/w/index.php?title=Alarmanlage&diff=23981Alarmanlage2017-12-31T13:12:45Z<p>MGu: /* Grenzen */</p>
<hr />
<div>Mit FS20 und/oder HM Komponenten lassen sich auch Alarmanlagen realisieren. Im Folgenden soll eine einfache Alarmanlage beschrieben werden. Die Beschreibung ist an manchen Stellen noch unvollständig und außerdem an konkrete Begebenheiten angepasst. Sie soll daher nur als Anregung dienen, ferner werden einige typische Probleme diskutiert.<br />
<br />
Alternativ kann eine Alarmanlage auch über das [[Modul_Alarmanlage]] realisiert werden, das einem einiges an Arbeit abnimmt.<br />
<br />
<br />
== Anforderung ==<br />
Die Alarmanlage soll mittels Taster im Innenraum und Fernbedienungen scharf und unscharf gestellt werden können. Die Scharfschaltung soll verzögert erfolgen. Der Zustand der Anlage soll auf dem Webinterface aber auch auf einer im Haus zu montierenden Anzeige sichtbar sein. Die Auslösung soll beim Verletzen der Aussenhaut und bei Bewegung im Innenraum erfolgen. Es soll im Moment der Auslösung grob angezeigt werden, in welchem Bereich ausgelöst wurde.<br />
<br />
== Vorausetzung ==<br />
Voraussetzung sind Sensoren. Vielfach sind aber Bewegungsmelder und Türkontakte vorhanden, unter Umständen muss nur wenig ergänzt werden. Im konkreten Fall waren auch schon mehrere [[FS20 PIRA Infrarot-Bewegungsmelder]] installiert.<br />
<br />
== Design / Anzeige / Schaltlogik ==<br />
Der Zustand der Anlage muss angezeigt werden. Dies kann zum Teil über einen Raum "Alarmanlage" geschehen, den man per WebGUI ansehen kann, denkbar ist aber auch eine Hardwareanzeige. Im konkreten Fall wurde ein [[FS20 SM8 8-Kanal-Schaltmodul]] realisiert. Dessen Ausgänge können direkt bis zu 12 Volt 1 Ampere schalten, was für Leuchtdioden und sogar 12 Volt Sirenen ausreicht. Wichtig ist vor allem, dass von außen zu sehen ist, dass die Anlage scharf ist. Hierzu kann im Bereich der Eingangstür eine Leuchtdiode angebracht werden, die durch einen Kanal des FS20SM8 angesteuert wird. Es empfiehlt sich eine blinkende LED zu verwenden, da Blinken über einen grösseren Zeitraum mit FHEM/FS20 kaum realisierbar ist.<br />
<br />
Zunächst muss die Anlage ein und auschaltbar sein, oder besser: scharf und unscharf.<br />
Ferner soll zwischen "scharf" und nur "scharf intern" unterschieden werden. Scharf intern soll dabei nur die Aussenhautsensoren überwachen (Türen, Fenster) nicht jedoch Innenraumsensoren (Bewegungsmelder, Taster)<br />
<br />
Scharf intern wird also eingeschaltet, wenn sich Bewohner im Gebäude aufhalten eine Grundsicherung aber dennoch erfolgen soll, typischerweise also nachts. Ebenso ist die interne Scharfschaltung sinnvoll, wenn z.B. Hunde alleine im Haus zurückbleiben, die sonst eventuell die Bewegungsmelder auslösen würden.<br />
<br />
Das Einschalten soll zwar per Fernbedienung passieren, zusätzlich aber über im Haus verdeckt angebrachte Taster. <br />
Die im Haus angebrachten Taster ermöglichen Scharf- und auch Unscharfschalten ohne Eingabe weiterer Berechtigungen, d.h. es ist derzeit kein Codeschloss oder dergleichen realisiert. Die Sicherheit ergibt sich auschliesslich dadurch, dass die Taster getarnt und als solche nicht erkennbar sind. Hierzu wurden nicht als Taster erkennbare Mechanismen mit einem [[FS20 S4M 2-/4-Kanal-Sendemodul|FS20 S4M]] verbunden, das als Sender dient.<br />
<br />
Um Fehlbedienungen zu erschweren sind Wartezeiten eingebaut: Nach der letzten Unscharfschaltung müssen 11 Sekunden vergehen, bis wieder scharf geschaltet werden kann. <br />
<br />
Die Scharfschaltung muss außerdem verzögert erfolgen, damit man bereits im Inneren des Hauses scharf schalten kann aber noch genug Zeit hat das Haus zu verlassen. Hier ist eine Minute ausreichend.<br />
<br />
Um diese diversen Zustände zu steuern, werden mehre Variablen (dummys) und FS20 Aktoren eingerichtet, nämlich:<br />
<br />
* ANLAGE_STATUS<br />
* ALARM_STATUS<br />
* ANLAGE_SCHARF<br />
* ALARM_AKTOR<br />
<br />
Zur Anzeige außerdem:<br />
<br />
* Scharfanzeige1<br />
* Scharfanzeige2<br />
<br />
<br />
Im Einzelnen:<br />
<br />
<br />
'''ANLAGE_STATUS'''<br />
<br />
Ein reiner Dummy, der folgende Werte annehmen kann<br />
<br />
* aus (Anlage initialisiert, ohne weitere Funktion)<br />
* 60sec (Anlage wurde scharf geschaltet, ein Minute Wartezeit bis Aktivierung)<br />
* scharf (Anlage ist scharf)<br />
* scharf_intern (Anlage ist intern scharf, es werden nurAussenhautsensoren überwacht)<br />
* warten (Anlage wurde unscharf geschaltet, kann aber die nächsten 11 Sekunden noch nicht erneut scharf geschaltet werden.<br />
* unscharf (Anlage ist unscharf)<br />
<br />
<br />
'''ALARM_STATUS'''<br />
<br />
Ein reiner Dummy, der folgende Werte annehmen kann<br />
<br />
* aus (Anlage initialisiert, ohne weitere Funktion)<br />
* bereit (Anlage scharf, keine Alarmauslösung)<br />
* ALARM (Anlage scharf, Alarmauslösung)<br />
* unscharf (Anlage unscharf)<br />
* IRausgeloest (Anlage ist scharf, Alarmauslösung durch Bewegungsmelder, letzte Bewegung vor mindestens 3 Minuten)<br />
<br />
Es ist möglich die Satus ANLAGEN_STATUS und ALARM_STATUS in einer Variabel zusammen zu fassen, was die Sache aber unübersichtlich macht.<br />
<br />
<br />
'''ANLAGE_SCHARF'''<br />
<br />
Ein FS20 Schalter, der dazu da ist, die Alarmanlage mit den Tastern im Haus, einer Fernbedienung oder ggf. über die Webseite zu schalten. ON soll die Anlage scharf schalten, OFF unscharf. <br />
Ferner kann überlegt werden, auch versehentlich zu lange Tastendrücke (dimup und dimdown) abzufangen und zum Schalten zuzulassen.<br />
<br />
<br />
'''ANLAGE_SCHARF_intern'''<br />
<br />
Ein FS20 Schalter, der dazu da ist, die Alarmanlage mit den Tastern im Haus, einer Fernbedienung oder ggf. über die Webseite zu schalten. ON soll die Anlage scharf_intern schalten, OFF unscharf. <br />
Ferner kann überlegt werden, auch versehentlich zu lange Tastendrücke (dimup und dimdown) abzufangen und zum Schalten zuzulassen.<br />
<br />
<br />
'''ALARM_AKTOR'''<br />
<br />
Ein FS20 Aktor, der dazu dient die Sirenensteuerung zu triggern.<br />
Die Signalisierung bei Alarm ist 2-stufig aufgebaut. ALARM_STATUS löst im Inneren des Hauses direkt eine Alarmanzeige (LED und/oder interne Sirene aus).<br />
Äussere Signaleinrichtungen unterliegen aber gesetzlichen Regelungen was die Länge der Alarmierung betrifft und werden daher durch eine eigene Logik bzw. einen eigene Aktor betrieben: ALARM_AKTOR <br />
<br />
<br />
Zur Anzeige ausserdem:<br />
<br />
Scharfanzeige1<br />
<br />
Scharfanzeige2<br />
<br />
<br />
FS20 Aktoren, die mittels LED den Zustand der Anlage zeigen:<br />
<br />
* Scharfanzeige1 leuchtet, wenn die Anlage scharf geschaltet wurde (nur intern oder komplett) und auch, wenn die Anlage zwar scharf geschaltet wurde, aber die eine Minute Wartezeit noch nicht um ist. Sie dient als sofortiges Feedback, dass die Einschaltung erfolgreich war. Wird die Anlage unscharf geschaltet, leuchtet Scharfanzeige1 noch so lange wie die Anlage im Status „warten“ ist, also nicht erneut scharf geschaltet werden kann.<br />
* Scharfanzeige2 hingegen leuchtet nur, wenn der Anlagenstatus „scharf“ ist (nur intern oder komplett), also 1 Minute nach dem Einschalten. Hier kann z.b. eine zweite LED im Aussenbereich angebracht werden, die von außen sichtbar anzeigt, dass die Anlage scharf ist. Scharfanzeige2 geht sofort aus, wenn die Anlage unscharf geschaltet wird, sodass von außen kontrollierbar ist, ob die Anlage erfolgreich unscharf gestellt wurde.<br />
<br />
<br />
Mit zwei LEDs (oder ähnlichen Aktoren) können also Zustände der Anlage (ausser dem eigentlichen Alarm) angezeigt werden:<br />
<br />
Nach einschalten:<br />
<br />
Scharfanzeige1 Scharfanzeige2 Status der Anlage<br />
aus aus unscharf <br />
an aus eingeschaltet, 1 Minute Wartezeit<br />
an an scharf<br />
<br />
Durch weitere Anzeigen ließe sich zwischen scharf und scharf_intern unterscheiden. Speziell von aussen betrachtet bringt dies aber wenig Erkenntnisgewinn, da ein versehentliches Öffnen der Tür in beiden Fällen Alarm auslösen würde.<br />
<br />
Nach ausschalten:<br />
<br />
Scharfanzeige1 Scharfanzeige2 Status der Anlage<br />
an aus unscharf, noch warten <br />
aus aus unscharf, einschaltbar<br />
<br />
== Praktische Probleme ==<br />
=== Grenzen ===<br />
<br />
Die Alarmanlage ist insgesamt nur so sicher wie die verwendeten Komponenten. Die hier eingesetzten FS20 Sensoren und Sender sind funktechnisch nicht sicher und könnten von Dritten, die über geeignete Kenntnisse, Geräte und Zeit verfügen, analysiert und dann bedient werden. Sie dient nur der Grundsicherung gegen "durchschnittlich begabte" Einbrecher. Sie ist besser als nichts, weil man wohl davon ausgehen kann, dass normale Einbrecher nicht über das notwendige Wissen verfügen, überdies würde der zeitliche Aufwand das Objekt eventuell weniger lohnend erscheinen lassen.<br />
Es ist aber definitiv möglich, die Anlage mit einer FHEM Installation auf einem Laptop inklusive z.B. einem CUL abzuschalten, wenn die nötige Kenntnisse vorliegen.<br />
Mit HomeMatic Komponenten kann höhere Sicherheit erreicht werden, insbesondere wenn der AES Signing Request mit eigenem Schlüssel verwendet wird.<br />
<br />
Neben der informationstechnischen Unsicherheit muss auch immer berücksichtigt werden, dass lizenzfreie Funkübertragung überwiegend in einigen wenigen Frequenzbereichen (433MHz, 868MHz, 2.4GHz) realisiert wird. Für alle diese Bereiche gibt es in zwischen Störsender. Diese werden z.B. von Autodieben verwendet um die GPS-Überwachung per Mobilfunk außer Betrieb zu setzen. Der Betrieb solcher Störsender ist wesentlich einfacher als die Analyse der IT-Komponenten. Jemand der sich durch einen Einbruch strafbar macht, hat keinerlei Grund sich an Fernmeldegesetze zu halten. Sogar die Datenübertragung über das eigene Stromnetz (HomePlug) lässt sich relativ einfach stören. Viele Häuser haben Außensteckdosen, Lampen diverse Gartenautomatisierung etc. die gut geeignet sind um Störungen ein zu koppeln. Selbst ohne direkten Zugang zu einer Stromleitung kann eine geeignet breitbandige Störung induktiv eingekoppelt werden.<br />
<br />
Nun könnte man den Betrieb eines Störsenders oder Manipulationen an Komponenten am Verbindungsverlust oder Statusänderungen merken. Doch was dann tun? Einfach mal auf Verdacht den Alarm auslösen auch wenn es dann doch nur eine gewöhnliche Störung war? Jeder einzelne Fehlalarm konditioniert die Nachbarn zum nichts tun.<br />
<br />
Wenn alles tut und die Heimautomatisierung einen Einbruch erkennt, bleibt immer noch die Frage was zu tun ist. Die Aufmerksamkeit der Nachbarn erregen? Einen SMS, e-Mail oder ähnliches absetzen? Wer hat nicht schon mal irgendwo eine Alarmsirene gehört und auch einfach nichts getan. Die typischen Sirenen mit rotem Blinklicht werden regelmäßig mit Bauschaum und einem Deckel deaktiviert. Derlei Sirenen aus denen noch der Bauschaum quillt, sind in großen Städten immer wieder zu sehen. Diese Methode funktioniert mit einem langen Röhrchen sogar an sehr schlecht zugänglichen Stellen und aktiviert in der Regel keine Sabotagekontakte. Langer Rede kurzer Sinn: Es muss die gesamte Meldekette bis zu einer Person die etwas unternimmt manipulationssicher und sehr schnell funktionieren, sonst sind Einbrecher mit dem was sie holen wollten weg bevor irgend jemand reagiert. Auch Videoaufzeichnungen von Leuten mit Sturmhauben nutzen nichts. Die polizeiliche Aufklärungsquote beim Straftatbestand Wohnungseinbruchdiebstahl in Deutschland schwankte von 1999 bis 2016 zwischen 15 und 20% [https://de.statista.com/statistik/daten/studie/152583/umfrage/entwicklung-der-polizeilichen-aufklaerungsquoten-bei-wohnungseinbruchdiebstahl-seit-1995/]. Vier von fünf Einbrüchen bleiben unaufgeklärt. Daran hat der in den letzten Jahren einsetzende Boom der Hausautomatisierung kaum etwas geändert. Im Gegenteil die Aufklärungsquote war noch nie so niedrig wie 2015.<br />
<br />
=== Abstraktionlayer ===<br />
Wenn die Haussteuerung vor dem „Bau“ der Alarmanlage bereits besteht und wenn verschiedene Sensortypen eingesetzt werden, so sind die Namen der Sensoren vermutlich nicht nach den Bedürfnissen der Alarmanlage strukturiert benannt.<br />
Ausserdem liefern z.b. FHT Türsensoren andere Ergebnisse als FS20 und HM Türsensoren:<br />
<br />
* FHT80TF -&gt; Open / Closed<br />
* HM-SEC-SC -&gt; open / closed<br />
* FS 20 TFK -&gt; on / off<br />
<br />
Dadurch ist eine einfache Abfrage, ob eine Tür oder ein Fenster offen ist nicht möglich, vielmehr müssten alle Kontakte einzeln per notify behandelt werden.<br />
<br />
Ausserdem:<br />
<br />
* Die [[FHT80TF]] senden ihren Status alle ca 2 Minuten. Ohne eine zusätzliche Logik würden simple notifys daher alle 2 Minuten ausgelöst. <br />
* PIRA/PIRIs sind meist so konfiguriert, dass sie zwar bei Bewegung ein Event senden (etwa um Licht einzuschalten) aber kein Event, wenn keine Bewegung (für eine bestimmte Zeit) erkannt wurde. Dies muss berücksichtigt werden.<br />
<br />
Um nicht nachträglich alle Sensoren umbennen zu müssen und um die Zustände zu vereinheitlichen, wurde eine Abstraktionschicht eingeführt. Dazu werden alle Sensoren einer Meldegruppe bzw Funktionsgruppe als Dummy mit strukturierten Namen neu angelegt und deren Zustand über notifys der eigentlichen Sensoren ausgelöst.<br />
<br />
Durch die Alarmanlage werden nur Events der Dummies abgefragt.<br />
<br />
Dieses Vorgehen hat folgende Vorteile:<br />
<br />
* Vereinheitlichung der Namen<br />
* Vereinheitlichung der Zustände.<br />
* zusätzliche Logik in den Notifies der Dummys, z.b. Rücksetzen der Bewegungsmelder, Verzögerungen<br />
* Anzeige aller Sensoren in einem Raum („Alarmanlage“) ohne weitere Strukture-Konstrukte und unabhängig vom eigentlichen Sensor.<br />
* Manipulation der Dummysensoren ohne dass ausserhalb der Alarmanlage Aktionen ausgelöst werden . (Es kann z.b. zu Testzwecken eine Bewegungsmelder auf ON gesetzt werden, ohne das die normalerweise ausgelöste Lichtschaltung erfolgt)<br />
<br />
=== Funklast ===<br />
Im Betrieb kann im Moment von Zustandsänderungen einiges an Funklast erzeugt werden. Die konkreten Installation wird mit zwei [[CUL]]s und einem [[HMLAN Konfigurator]] betrieben. Die Zustandsanzeige der Alarmanlage ist von beiden CULs mit vernünftigem RSSI erreichbar und daher konnten die Anzeigen auf die CULs per IOdev verteilt werden, um die Funklast zu senken.<br />
<br />
Dabei wurden die kritischen Signalisierungen (Scharfanzeige und Alarm) von den eher sekundären Anzeigen (Meldegruppen) getrennt, die aufgrund häufiger Statusänderungen oft ausgelöst werden. Die Auslösung des Alarmaktors (Sirene) wird über HM geroutet.<br />
<br />
== Kommentierter Code ==<br />
(Gegenwärtig sind Definitionen und zugehörige Funktionen zusammengefasst, eleganter ist es vermutlich, alle für die Anlage notwendigen Definitionen zusammen zu fassen)<br />
<br />
Der Code basiert auf PERL "if", nicht auf dem inzwischen verfügbaren FHEM Befehl DOIF.<br />
<br />
Der Code ist hier unstrukturiert als "Einzeiler" ausgeführt. Dies ist allein der Vorliebe des Erstellers geschuldet und hat keinen funktionalen Hintergrund. Im Code enthalten Zeilumbrüche sind vor Übernahme in eine eigene Konfiguration zu entfernen.<br />
<br />
=== Einschalten / auschalten ===<br />
<nowiki>#-----Scharf/unscharf--------------------------------<br />
define ANLAGE_STATUS dummy<br />
attr ANLAGE_STATUS room Alarmanlage<br />
define ANLAGE_SCHARF FS20 22224222 32<br />
attr ANLAGE_SCHARF dummy 1<br />
attr ANLAGE_SCHARF room Alarmanlage<br />
define ANLAGE_SCHARF_intern FS20 22224222 30<br />
attr ANLAGE_SCHARF_intern dummy 1<br />
attr ANLAGE_SCHARF_intern room Alarmanlage<br />
define Scharfanzeige1 FS20 22224222 01<br />
attr Scharfanzeige1 IODev CUL1<br />
define Scharfanzeige2 FS20 22224222 02<br />
attr Scharfanzeige2 IODev CUL1</nowiki><br />
Über diese Dummies und Aktoren wird die Anlage gesteuert. Die Anlage wurde mit einem von der sonstigen Installation abweichendem Hauscode versehen, als Beispiel 22224222<br />
<br />
<br />
<br />
==== Einschalten ====<br />
<nowiki>define act_on_ANLAGE_SCHARF_on notify ANLAGE_SCHARF:on { if (Value("ANLAGE_STATUS") ne &quot;scharf&quot; &amp;&amp;<br />
Value("ANLAGE_STATUS") ne &quot;60sec&quot; &amp;&amp; Value("ANLAGE_STATUS") ne &quot;warten&quot; ) { fhem(&quot;set Scharfanzeige1 on&#160;;; <br />
set ANLAGE_STATUS 60sec&#160;;; set ALARM_STATUS bereit&#160;;; define verzoegert_Heizung_absenken at +00:07:00 set <br />
Heizung_absenken on&#160;;; define verzoegert_scharf at +00:01:00 set ANLAGE_STATUS scharf&#160;;;;; <br />
set Scharfanzeige2 on&quot;) }}</nowiki><br />
Beim Betätigen des Tasters / Fernbedienung wird die Alarmanlage eingeschaltet, wenn:<br />
<br />
* der Taster ON gedrückt wurde<br />
* die Anlage nicht schon scharf ist (Vermeidung unnötiger Funklast)<br />
* die Anlage nicht innerhalb der letzten Minute scharf geschaltet wurde<br />
* die Anlage nicht innerhalb der letzten 11 Sekunden ausgeschaltet wurde.<br />
<br />
Das Scharfschalten löst folgende Aktionen aus:<br />
<br />
* die Scharfanzeige 1 wird aktiviert<br />
* Der Status der Anlage wird auf „60sec“ gesetzt, um anzudeuten, das sie noch nicht scharf ist, aber in einer Minute<br />
* der Alarmstatus wird auf „bereit“ gesetzt<br />
* die Heizung wird in 7 Minuten auf Absenkbetrieb gesetzt, in der Annahme, dass die Alarmanlage nur dann auf scharf gestellt wird, wenn alle das Haus verlassen haben. Die Verzögerung von 7 Minuten dient vor allem dazu, die erhebliche Funklast der Heizungsabsenkung – Brenner und alle FHTs werden verstellt - zeitlich von (auch mehrfachen) Scharfschaltungen zu entkoppeln. Dies erhöht die Zuerlässigkeit der Alarmanlage.<br />
* mittels ''define verzoegert_scharf at +00:01:00'' wird die Anlage eine Minute nach Scharfschaltung tatsächlich scharf geschaltet, gleichzeitig wird Scharfanzeige2 eingeschaltet, die eine auch im Außenbereich sichtbare Anzeige aktiviert.<br />
<br />
==== Einschalten intern ====<br />
<nowiki>define act_on_ANLAGE_SCHARF_intern_on notify ANLAGE_SCHARF_intern:on { if (Value("ANLAGE_STATUS") ne &quot;scharf_intern&quot; &amp;&amp;<br />
Value("ANLAGE_STATUS") ne &quot;60sec&quot; &amp;&amp; Value("ANLAGE_STATUS") ne &quot;warten&quot; ) { fhem(&quot;set Scharfanzeige1 on&#160;;; <br />
set ANLAGE_STATUS 60sec&#160;;; set ALARM_STATUS bereit&#160;;; define verzoegert_scharf at +00:01:00 set ANLAGE_STATUS scharf_intern&#160;;;;; set Scharfanzeige2 on&quot;) }}</nowiki><br />
Das Verhalten ist analog zur normalen Scharfschaltung. Jedoch wird die Heizung nicht abgesenkt.<br />
Die Alarmanlage kann auch ohne vorheriges Auschalten von einer Scharfschaltung in die andere überführt werden. <br />
Dies kann nützlich sein, wenn z.b. von aussen versehentlich nur intern scharf gestellt wurde. Es ist dann möglich direkt auf komplette Scharfschaltung zu erweitern.<br />
<br />
==== Ausschalten ====<br />
<nowiki>define act_on_ANLAGE_SCHARF_off notify ANLAGE_SCHARF.*:off { if (Value("ANLAGE_STATUS") eq &quot;scharf_intern&quot; || Value("ANLAGE_STATUS") eq &quot;scharf&quot;) <br />
{ fhem(&quot;set ALARM_Melder off&#160;;; <br />
set Scharfanzeige2 off&#160;;; delete verzoegert_scharf&#160;;; set ANLAGE_STATUS warten&#160;;; <br />
set ALARM_STATUS unscharf &#160;;; define Alarmanlage_aufraeumen <br />
at +00:00:11 set ANLAGE_STATUS unscharf&#160;;;;; set Scharfanzeige1 off&#160;;; <br />
delete verzoegert_Heizung_absenken&#160;;; set brenner on&#160;;; set ANLAGE_SCHARF_intern,ANLAGE_SCHARF off&quot;) } <br />
else { fhem(&quot;set ALARM_Melder off&#160;;; <br />
set Scharfanzeige2 off&#160;;; delete verzoegert_scharf&#160;;; set ANLAGE_STATUS warten&#160;;; <br />
set ALARM_STATUS unscharf &#160;;; define Alarmanlage_aufraeumen <br />
at +00:00:11 set ANLAGE_STATUS unscharf&#160;;;;; set Scharfanzeige1 off&#160;;; <br />
delete verzoegert_Heizung_absenken&quot;) }}</nowiki><br />
Beim Betätigen des Tasters / Fernbedienung wird die Alarmanlage ausgeschaltet, wenn der Taster OFF gedrückt wurde. Durch ANLAGE_SCHARF.* (also das angehängte ".*") werden dabei beide Schalter ausgewertet, also sowohl<br />
ANLAGE_SCHARF<br />
als auch <br />
ANLAGE_SCHARF_intern.<br />
Beide Schalter schalten die Anlage bei OFF also aus, egal auf welche Art sie scharf geschaltet wurde.<br />
<br />
<br />
Das Unscharfschalten löst - sofern die Alarmanlage vorher scharf war - folgende Aktionen aus:<br />
<br />
* Der ALARM_Melder (wird weiter unten definiert) wird abgeschaltet. (konkret schaltet dies die eventuell laufende Aussensirene aus)<br />
* die Scharfanzeige 2 wird deaktiviert, damit ist auch von aussen sichtbar, dass die Unscharfschaltung erfolgreich war.<br />
* „verzoegert_scharf“ wird gelöscht, sofern es existiert. Dies verhindert vor allem, das die Anlage sich unkontrolliert selber scharf schaltet, wenn die Unscharfschaltung innerhalb einer Minute nach Scharfschaltung erfolgt (Im Haus was vergessen eben nochmal rein...). Im Normalfall erzeugt dies eine Fehlermeldung, da „verzoegert_scharf“ nach finaler Scharfschaltung nicht mehr exisitert, die Fehlermeldung kann aber ignoriert werden.<br />
* Die Anlage wird auf „Warten“ gestellt . Dies soll verhindern, dass bei eventuell hektischem Manipulieren mit einer Fernbedienung die Anlage versehentlich sofort wieder scharf gestellt wird.<br />
* Der ALARM Status wird auf unscharf gesetzt (damit geht auch eine eventuell interne Sirene aus)<br />
* Die Scharfanzeige1 wird deaktiviert<br />
* Die Anlage wird per at +00:00:11 in 11 Sekunden in den finalen Zustand überführt und auf unscharf gestellt. Sie ist jetzt wieder bereit zum Einschalten. Sicherheitshalber wird außerdem die Scharfanzeige2 nochmal deaktiviert, ausserdem wird die eventuell noch vorhanden Absenkung der Heizung (letzte Scharfschaltung nur 7 Minuten oder weniger zurück) gelöscht. Im Normalfall erzeugt dies eine Fehlermeldung, da „verzoegert_Heizung_absenken“ 7 Minuten nach einer scharfschaltung nicht mehr existiert, die Fehlermeldung kann aber ignoriert werden. Zuletzt wird der Brenner eingeschaltet; hier sind weitere ähnliche „Willkommensaktionen“ denkbar, wie Licht im Hausflur einschalten oder dergleichen.<br />
* ANLAGE_SCHARF_intern und ANLAGE_SCHARF werden beide auf OFF gesetzt. Dies sorgt dafür das beide Schalter auf dem Webfrontend auf OFF stehen. Allerdings würde damit<br />
<nowiki>define act_on_ANLAGE_SCHARF_off notify ANLAGE_SCHARF.*:off</nowiki><br />
sich selbst auslösen. Um dies zu verhindern wird mit folgendem Abschnitt vorher geprüft, ob die Anlage überhaupt scharf war:<br />
<br />
<nowiki>define act_on_ANLAGE_SCHARF_off notify ANLAGE_SCHARF.*:off { if (Value("ANLAGE_STATUS") eq "scharf_intern" || (Value("ANLAGE_STATUS") eq "scharf")</nowiki><br />
<br />
<br />
Hier liesse sich eventuell auch mit "setstate" anstatt "set" arbeiten, da setstate nur den Status auf dem Webfrontend ändern würde.<br />
<br />
Ist die Anlage bei Betätigen eines Ausschalters nicht scharf, werden sicherheitshalber mit<br />
<br />
<nowiki>else { fhem(" ... ")</nowiki><br />
trotzdem alle Abschaltschritt ausgeführt, ausser ANLAGE_SCHARF_intern und ANLAGE_SCHARF auf OFF zu setzen (sowie den Brenner einzuschalten). Dies dient der höheren Robustheit, so können z.b. auch unklare Zustände der Anlage durch auschalten bereinigt werden. (Insbesondere der Fall, dass aus irgendwelchen Gründen die Sirenen an sind, obwohl die Anlage eigentlich aus ist.)<br />
<br />
==== Scharfanzeige aktualisieren ====<br />
<nowiki>define Scharfanzeige_update at +*00:10:00 { if (Value("ANLAGE_STATUS") eq &quot;scharf&quot; <br />
&amp;&amp; Value("ANLAGE_SCHARF") eq &quot;on&quot; ) { fhem (&quot;set Scharfanzeige2 on &quot;) }}</nowiki><br />
<nowiki>define Scharfanzeige_intern_update at +*00:30:00 { if (Value("ANLAGE_STATUS") eq &quot;scharf_intern&quot; <br />
&amp;&amp; Value("ANLAGE_SCHARF_intern") eq &quot;on&quot; ) { fhem (&quot;set Scharfanzeige2 on &quot;) }}</nowiki><br />
<br />
Diese Codeabschnitte dienen einzig dazu, sicherzustellen, dass die von außen sichtbare Scharfanzeige den Zustand der Alarmanlage auch korrekt anzeigt, selbst wenn die Auslösung bei der Scharfschaltung aufgrund von Funkstörungen nicht erfolgreich war.<br />
Nichts senkt die Akzeptanz einer Alarmanalge so nachhaltig wie eine Scharfschaltung z.b. per Weboberfläche (die die erfolgreiche Scharfschaltung anzeigt, auch wenn die Scharfanzeige2 nicht geschaltet werden konnte) und ein anschließend nach Hause zurückkehrendes Familienmitglied, das nicht sehen kann, dass die Anlage scharf ist und dann ohne Unscharfschaltung die Haustür aufmacht.<br />
<br />
Da dieser Teil im Falle einer scharfen Anlage regelmäßig Funklast erzeugt, ist der Abfrageabstand hinreichend gross zu wählen. Im Beispiel ist die Abfrage für internen Alarm länger, da angenommen wird, dass bei interner Scharfschaltung alle Bewohner sowieso im Haus sind.<br />
<br />
Beide Codeabschnitte könnten durch Verwendung von "oder" Bedingungen zusammengefasst werden was aber eventuell etwas unübersichtlich ist.<br />
<br />
=== Abstraktionsschicht für Türkontakte (Fensterkontakte) ===<br />
<nowiki>#------Tuerkontakte----Namen-und-Zustände vereinheitlichen-------<br />
define AussentuerEG_Eingang dummy<br />
attr AussentuerEG_Eingang room Alarmanlage<br />
attr AussentuerEG_Eingang loglevel 6<br />
<br />
define act_on_Eingang_TFK notify Eingang_TFK { if (Value("Eingang_TFK") eq &quot;off&quot;) <br />
{ fhem(&quot;define Eingangstuer_verzoegert_zu at +00:00:04 set AussentuerEG_Eingang zu&#160;;; set AussentuerEG_Eingang zu&quot;) } <br />
else { fhem(&quot;define Eingangstuer_verzoegert_offen at +00:00:04 set AussentuerEG_Eingang offen&quot;) }}<br />
define AussentuerEG_Terrasse dummy<br />
attr AussentuerEG_Terrasse room Alarmanlage<br />
attr AussentuerEG_Terrasse loglevel 6<br />
define act_on_Tuer_Wohn_u1 notify Tuer_Wohn_u { if (Value("Tuer_Wohn_u") eq &quot;Closed&quot;) <br />
{ fhem(&quot;set AussentuerEG_Terrasse zu&quot;) } else { fhem(&quot;set AussentuerEG_Terrasse offen&quot;) }}<br />
define AussentuerUG_Keller dummy<br />
attr AussentuerUG_Keller room Alarmanlage<br />
attr AussentuerUG_Keller loglevel 6<br />
define act_on_Tuer_Keller_Aussen1 notify Tuer_Keller_Aussen { if (Value("Tuer_Keller_Aussen") eq &quot;Closed&quot;) <br />
{ fhem(&quot;set AussentuerUG_Keller zu&quot;) } else { fhem(&quot;set AussentuerUG_Keller offen&quot;) }}<br />
define AussentuerUG_Heizungskeller dummy<br />
attr AussentuerUG_Heizungskeller room Alarmanlage<br />
attr AussentuerUG_Heizungskeller loglevel 6<br />
define act_on_Tuer_Heizungskeller1 notify Tuer_Heizungskeller { if (Value("Tuer_Heizungskeller") eq &quot;closed&quot;) <br />
{ fhem(&quot;set AussentuerUG_Heizungskeller zu&quot;) } else { fhem(&quot;set AussentuerUG_Heizungskeller offen&quot;) }}</nowiki><br />
Hier wird der Abstraktionslayer für die Türsensoren angelegt. Alle Dummies heißen „AussentuerXX_Ort“ und sind daher später mittels eines Events der Art notify Aussentuer.* abfragbar. Außerdem werden die verschiedenen Status der diversen Melder auf die Zusände „offen“ und „zu“ gemappt. Durch Loglevel= 6 wird verhindert, das die Zustandsänderungen gesondert im Log erscheinen, da die Zustandsänderungen der jeweiligen Sensoren bereits im Log vermerkt sind.<br />
<br />
Im Beispiel sind nur einige Türen aufgeführt, tatsächlich sind so alle Türen mit dem einen oder anderen Sensor einbindbar. Da die [[FHT80TF]] Sensoren (FHEM: FHTTK) nicht bei Statusänderungen senden, kann eine Alarmauslösung hier bis zu 2 Minuten verzögert erfolgen.<br />
<br />
<br />
Hier nicht ausgeführt, aber prinzipiell analog können Fenstersensoren aufgebaut werden. Mittels handelsüblicher Glasbruchsensoren, die an die externen Kontakte eines FS20 oder HM Türkontakts angeschlossen werden, lassen sich günstig Glasbruchmelder bauen. Bei Fenstern, die nicht optisch sichtbar sind (Kellerfenster) lässt sich anstatt eines „echten“ Glasbruchsensors der Glasbruch auch durch einen getrennt auf die Scheibe geklebten Magneten und HM-SEC-SC realisieren, bei Glasbruch fallen beide Komponenten höchstwahrscheinlich getrennt zu Boden und lösen dann aus.<br />
<br />
<br />
Die Eingangstür erfährt ausserdem eine Sonderbehandlung. Sie soll Alarm erst 4 Sekunden nach öffnen auslösen. Dies dient dazu bei z.b. vergessenem Sender das Haus dennoch betreten zu können. Und zwar hat man nach öffnen der Tür noch 4 Sekunden Zeit, die Alarmanlage mit dem innen verdeckt angebrachten Schalter unscharf zu schalten. Es liegt zunächst nahe, diese Verzögerung in die eigentliche (weiter unten beschriebene) Alarmauslösungsroutine einzubauen. Allerdings würde diese dadurch deutlich komplizierter, es wäre insbesondere nicht mehr möglich mit nur einem Ausdruck alle Türen auf einemal abzufragen.<br />
<br />
Anstelle dessen wird hier der Abstraktionslayer über dem eigentlichen Sensor verwendet um zusätzliche Funktionalität einzubauen:<br />
<br />
<nowiki>define act_on_Eingang_TFK notify Eingang_TFK { if (Value("Eingang_TFK") eq &quot;off&quot;)<br />
{ fhem(&quot;set AussentuerEG_Eingang zu ;; define Eingangstuer_verzoegert_zu at +00:00:04 set AussentuerEG_Eingang zu&quot;) } <br />
else { fhem(&quot;define Eingangstuer_verzoegert_offen at +00:00:04 set AussentuerEG_Eingang offen&quot;) }}</nowiki><br />
<br />
Hier wird einfach jeder Schaltvorgang des TFK 4 Sekunden verzögert. Wichtig ist es, dies auch beim Schliessen der Tür zu tun, da sonst bei einem (z.b. versehentlichen) schnellen Öffnen und Schliessen der Tür der Dummy "AussentuerEG_Eingang" den falschen Wert annehmen kann: Wird die Tür nämlich geöffnet, aber z.b. nach 2 Sekunden geschlossen, würde die AussentuerEG_Eingang zwar zunächst auf "zu" gesetzt, aber weitere 2 Sekunden später durch die 4 Sekunden Öffnungsverzögerung wieder auf "offen" gesetzt. Daher muss auch das Setzen von AussentuerEG_Eingang auf "zu" mit 4 Sekunden Verzögerung erneut erfolgen.<br />
<br />
Die zunächst naheliegend erscheinende Lösung, beim Schliessen das eventuelle noch vorhandene "Eingangstuer_verzoegert_offen" zu löschen, kann nicht verwendet werden, da dann ein Einbrecher, der es schaffen würden, die Tür zu öffnen und innerhalb von 4 Sekunden wieder zu schliessen keinen Alarm auslösen würde.<br />
<br />
=== Abstraktionsschicht für Bewegungsmelder ===<br />
<nowiki>#------Bewegungsmelder----Namen-und-Zustände vereinheitlichen-------<br />
define Bewegung_Wohnen_oben dummy<br />
attr Bewegung_Wohnen_oben room Alarmanlage<br />
define act_on_PIRI_WZ_o1 notify PIRI_WZ_o:on.* { fhem(&quot;set Bewegung_Wohnen_oben bewegung&#160;;; <br />
define reset_Bewegung_Wohnen_oben at +00:03:00 set Bewegung_Wohnen_oben keine &quot;) }<br />
<br />
define Bewegung_Bad_EG dummy<br />
attr Bewegung_Bad_EG room Alarmanlage<br />
<br />
define act_on_zk_pumpe1 notify zk_pumpe:on.* { fhem(&quot;set Bewegung_Bad_EG bewegung&#160;;; <br />
define reset_Bewegung_Bad_EG at +00:03:00 set Bewegung_Bad_EG keine &quot;) }<br />
define act_on_Licht1_Bad notify Licht1_Bad:on.* { fhem(&quot;set Bewegung_Bad_EG bewegung&#160;;; <br />
define reset_Bewegung_Bad_EG at +00:03:00 set Bewegung_Bad_EG keine &quot;) }</nowiki><br />
Hier wird der Abstraktionslayer für Bewegungsmelder definiert. Exemplarisch sind 2 Melder aufgehführt. Alle Dummies heissen „Bewegung_Ort1_ort1“ und sind daher mit „notify Bewegung.*“ abfragbar<br />
Alle Zustände werden auf „bewegung“ bzw „keine“ gemappt.<br />
Da Bewegungsmelder idR. Nur „on“ melden, aber nicht „off“ bei keiner Bewegung, wird hier 3 Minuten nach einer Auslösung der Zustand auf „keine“ gesetzt. Diese Zeit ist mit den eingestellten Sendezeiten des Bewegungsmelders abzustimmen.<br />
<br />
Ein Besonderheit ist Bewegung_Bad_EG: Historisch bedingt ist hier ein Bewegungsmelder direkt mit der Zirkulationspumpe gekoppelt, bzw über den zweiten Kanal mit dem Licht im Badezimmer. Eine Besonderheit ist dabei, dass die Zirkulationspumpe nach 2 Uhr bis 6 Uhr trotz Auslösung nicht eingeschaltet wird (nachts will keiner duschen) und Licht tagsüber nicht angeht.<br />
Zur Abdeckung von Bewegungen über den gesamten Tagesverlauf müssen daher sowohl Statusänderung der Zirkulationspumpe als auch des Badezimmerlichts abgefragt werden. Als Nebeneffekt würde das Einschalten der Zirkulationspumpe über andere Methoden im Falle einer scharfen Alarmanlage einen Alarm auslösen. Tatsächlich lässt sich die Zirkulationspumpe über Schalter im Schlafzimmer und in der Küche für 15 Minuten einschalten. Faktisch spiel dies allerdings keine Rolle, da das Betätigen von Schaltern im Haus bei scharfer Alarmanlage eigentlich nur von unberechtigten Personen erfolgen kann.<br />
<br />
Eine mögliche Erweiterung ist sogar, dass Betätigen aller Schalter (außer den Tastern zum Schalten der Alarmanlage selbst) zur Alarmauslösung zu nutzen. Das ist hier noch nicht realisiert, da bei umfangreichen Automatisonsszenarien peinlich genau geprüft werden muss, ob Schaltungen nicht automatisch durch Scripte in FHEM erfolgen, also welche Lichter z.b. bei Dämmerung von alleine eingeschaltet werden.<br />
<br />
=== Meldegruppen ===<br />
<nowiki>#------Meldegruppenueberwachung----------------------<br />
define MeldegruppeUG FS20 22224222 11<br />
attr MeldegruppeUG IODev CUL2<br />
define MeldegruppeEG FS20 22224222 21<br />
attr MeldegruppeEG IODev CUL2<br />
define Meldegruppe3 FS20 22224222 31<br />
attr Meldegruppe3 IODev CUL2</nowiki><br />
<br />
Hier werden verschiedene Meldegruppen definiert. Es werden diverse Melder so zusammengefasst, dass eine grobe Anzeige des Auslöseortes möglich ist.<br />
Im Beispiel werden die Türen im Keller, Türen im EG und Bewegungsmelder zusammengefasst. Die Meldegruppen lösen einen Aktor aus, der den Zustand der Meldegruppe anzeigt, hier eine LED am Ausgang des FS20 8-Kanal-Schaltmodul FS20SM8. Da die Schaltung bei Bewegung im Haus relativ häufig erfolgt, ist als IOdev das schwächer belastetes RFR CUL definiert. <br />
(im folgenden Codebeispiel finden sich auch Melder, die in den Beispielen weiter oben der Übersichtlichkeit halber weggelassen wurden)<br />
<br />
<nowiki>define check_MeldegruppeUG_klar notify AussentuerUG.* { if (Value("MeldegruppeUG") eq &quot;off&quot; &amp;&amp; <br />
Value("AussentuerUG_Keller") eq &quot;zu&quot; &amp;&amp; Value("AussentuerUG_Waschkeller") eq &quot;zu&quot; &amp;&amp; <br />
Value("AussentuerUG_Heizungskeller") eq &quot;zu&quot;) { fhem (&quot;set MeldegruppeUG on&quot;) }}<br />
<br />
define check_MeldegruppeUG_unklar notify AussentuerUG.*:offen { if (Value("MeldegruppeUG") eq &quot;on&quot;) <br />
{ fhem(&quot;set MeldegruppeUG off&quot;) }}<br />
<br />
define check_MeldegruppeEG_klar notify AussentuerEG.* { if (Value("MeldegruppeEG") eq &quot;off&quot; &amp;&amp; <br />
Value("AussentuerEG_Schlafen") eq &quot;zu&quot; &amp;&amp; Value("AussentuerEG_Terrasse") eq &quot;zu&quot; &amp;&amp; <br />
Value("AussentuerEG_Eingang") eq &quot;zu&quot;) { fhem (&quot;set MeldegruppeEG on&quot;) }}<br />
<br />
define check_MeldegruppeEG_unklar notify AussentuerEG.*:offen { if (Value("MeldegruppeEG") eq &quot;on&quot;) <br />
{ fhem(&quot;set MeldegruppeEG off&quot;) }}<br />
<br />
define check_Meldegruppe3 notify Bewegung.* { if (Value("Bewegung_Wohnen_oben") eq &quot;keine&quot; &amp;&amp; <br />
Value("Bewegung_Bad_EG") eq &quot;keine&quot; &amp;&amp; Value("Bewegung_Wohnen_unten") eq &quot;keine&quot;) <br />
{ fhem (&quot;set Meldegruppe3 on&quot;) } else { fhem (&quot;set Meldegruppe3 off&quot;) }}</nowiki><br />
Hier wird jede Meldegruppe behandelt. Zunächst wird bei jeder Veränderung einer Aussentür in der passenden Etage (durch strukturierte Namen der Dummies mit einem notify abfragbar) geprüft, ob alle Türen zu sind und ob die Meldegruppe bisher „off“ (also „unklar“) war. Wenn alle Bedingungen zutreffen wird die Meldegruppe auf „on“ (also „klar“) gesetzt. <br />
<br />
"notify AussentuerEG.*" wird dabei durch den Einsatz der FHT80TF ca. alle 2 Minuten ausgelöst. Um zu verhindern, dass alle zwei Minuten - oder beim Einsatz mehrerer FHT80TF in einer Meldegruppe auch öfters – Funksignale zum Schalten einer LED ausgesendet werden, obwohl die LED bereits den richtigen Zustand hat, wird nach dem Zustand der Meldegruppe gefragt und nur ein „on“ gesendet, wenn die Gruppe vorher „off“ war.<br />
Dies macht das Auschalten über ein „else“ Statement aber schwierig, da die Gruppe dann auf „off“ geschaltet würde, wenn bei einem Event alle Türen zu sind, aber auch vorher schon alle zu waren und die Gruppe daher schon „on“ war.<br />
<br />
Die Gruppe wird daher über eine seperates notify ausgeschaltet, hier wird nur gesendet, wenn irgendeine der Türen seinen Status zu offen ändert und die Gruppe vorher „on“ war.<br />
<br />
Die Bewegungsmelder senden nur bei einem tatsächlichen Event. Es muss daher streng genommen nicht überprüft werden, welchen Zustand die Meldegruppe vorher hatte. Jede Statusmeldung ist eine tatsächliche Änderung. Allerdings führt jede Auslösung eines Bewegungsmelders zu<br />
<nowiki>else { fhem (&quot;set Meldegruppe3 off&quot;) }</nowiki><br />
Sind viele Bewegungsmelder vorhanden und/oder werden diese oft ausgelöst (Wohnzimmer), kann hierdurch eine hohe Funklast entstehen. Es kann daher sinnvoll sein, diese Meldegruppe auch mit einer Zustandsüberprüfung zu versehen und die Meldegruppe nur dann auf "unklar" zu setzen, wenn sie vorher nicht schon "unklar" (=off) war:<br />
<nowiki>define check_Meldegruppe3 notify Bewegung.* { if (Value("Bewegung_Wohnen_oben") eq &quot;keine&quot; &amp;&amp; <br />
Value("Bewegung_Bad_EG") eq &quot;keine&quot; &amp;&amp; Value("Bewegung_Wohnen_unten") eq &quot;keine&quot;) <br />
{ fhem (&quot;set Meldegruppe3 on&quot;) } else { if (Value("Meldegruppe3") ne &quot;off&quot;) <br />
{ fhem (&quot;set Meldegruppe3 off&quot;) }}</nowiki><br />
<br />
Da die Meldegruppen den Zustand häufig ändern, kann überlegt werden, mit <br />
<nowiki>attr .... loglevel 6 </nowiki><br />
die Anzahl der Logeinträge zu reduzieren.<br />
<br />
=== Alarmauslösung und Behandlung ===<br />
<nowiki>#------Alarmauslösung-------------------------------<br />
define ALARM_STATUS dummy<br />
attr ALARM_STATUS room Alarmanlage<br />
define ALARM_Melder FS20 22224222 33</nowiki><br />
Hier wird der Dummy für den eigentlichen Alarm definiert sowie ein Aktor für den Alarmmelder, also typischerweise einen Aussensirene. <br />
ALARM_Melder ist dabei noch nicht der tatsächliche Aktor. In der konkreten Anlage ist der Aktor eine HM Schalter, da beim Auslösen der Aussensirene höchste Zuverlässigkeit gefordert ist. Die bidirektionale Kommunikation von HM ist daher vorteilhaft. Dieser HM Aktor wird durch ALARM_Melder per Notify ausgelöst. Die Abstraktion über den zusätzlichen FS20 Aktor dient hier nur dazu, die Sirene auch über andere FS20 Sender direkt auslösen zu können, z.b. durch einen Paniksender. Je nach gegebener Umgebung kann diese Abstraktion aufgegeben werden.<br />
<br />
==== Alarmauslösung durch Türöffnung ====<br />
<nowiki>define act_on_Aussentuer notify Aussentuer.*:offen <br />
{ if (Value("ANLAGE_STATUS") eq &quot;scharf&quot; || Value("ANLAGE_STATUS") eq &quot;scharf_intern&quot;) <br />
{ fhem(&quot;set ALARM_STATUS ALARM&#160;;; set Licht_an on&#160;;; set ALARM_Melder on&quot;) } }</nowiki><br />
Dieser Teil des Codes löst den Alarm aus, wenn eine Tür geöffnet wird. <br />
(Für Fenster gibt einen analogen Codeabschnitt)<br />
Hierbei verhalten sich die FHT80TF und "normale" FS20 Tür/Fensterkontakte unterschiedlich:<br />
Der FTH80TF löst Alarm aus, auch wenn er zum Zeitpunkt der Scharfschaltung schon offen war: eine nach spätestens ca. 4 Minuten kommende Meldung über den Zustand des Tür (oder des Fensters) löst den Alarm aus. Andere Sensoren ändern den Status jedoch nicht mehr, bis sie wieder geschlossen wurden und lösen daher keinen Alarm aus, wenn sie schon offen waren als die Alarmanlage scharf geschaltet wurde.<br />
<br />
In jedem Fall löst ein Wechsel des Zustandes als solches keinen Alarm aus. Wenn also z.b ein Fenster, das mit einem FHT80TF überwacht wird, erst vor kurzem geschlossen wurde und sein Zustand daher (innerhalb der ersten maximal 4 Minuten nach schliessen) noch auf "open" steht, so kann die Alarmanlage trotzdem scharf geschaltet werden. Die wenige Minuten später eintreffende Aktualisierung zu "closed" löst die Anlage nicht aus.<br />
<br />
Jedes „Tür offen“ Event löst die Prüfung aus, ob die Anlage scharf oder scharf_intern ist. <br />
(Dies geschieht durch den Perl-Ausdruck für "oder" " || ")<br />
<br />
Wenn die Anlage in einem der beiden Scharzfustände ist, wird<br />
<br />
* ALARM STATUS auf ALARM gesetzt. Damit wird die LED Anzeige für Alarm ausgelöst und eine ggf an den Aktor ebenfalls angeschlossene Sirene im Haus sofort ausgelöst. Für externe Sirenen wird jedoch der zusätzliche Aktor<br />
* ALARM_Melder auf „on“ gesetzt. Dies erlaubt abgestuft zu reagieren, z.b. den Hauptalarm verzögert auszulösen und mit Zeitbegrenzung zu versehen.<br />
* ausserdem wird mit dem in der normalen Automation definierten Dummy „Licht_an“ jedes im Haus schaltbare Licht eingeschaltet.<br />
<br />
Natürlich liessen sich auch weitere Aktionen auslösen.<br />
<br />
==== Alarmauslösung durch Bewegung ====<br />
<nowiki>define act_on_Bewegung notify Bewegung.*:bewegung { if (Value("ANLAGE_STATUS") eq &quot;scharf&quot; &amp;&amp; <br />
Value("ALARM_STATUS") ne &quot;ALARM&quot;) { fhem(&quot;set ALARM_STATUS ALARM&#160;;; set Licht_an on&#160;;; <br />
set ALARM_Melder on&#160;;; define ALARMIERT at +00:03:00 set ALARM_STATUS IRausgeloest&quot;) }}</nowiki><br />
Dieser Teil des Codes löst den Alarm aus, wenn eine Bewegung registriert wird.<br />
Weil Bewegungsmelder potentiell im Alarmfall häufiger ausgelöst werden als Türen, muss hier zur Vermeidung von Problemen mit dem Erreichen der maximalen Sendezeit nicht nur überprüft werden, ob die Anlage scharf ist, sondern auch, ob der Alarm bereits ausgelöst wurde. <br />
<br />
Ist dies nicht der Fall (also ist die Anlage unscharf oder ALARM_STATUS bereits auf „ALARM“) wird keine weitere Aktion ausgelöst. Dadurch wird die Anzahl der Funksignale deutlich reduziert.<br />
<br />
Dieser Teil reagiert ausserdem nicht, wenn die Anlage nur intern scharf ist.<br />
<br />
Ist die Anlage scharf und wurde bisher kein Alarm ausgelöst, dann erzeugt eine Bewegung:<br />
<br />
* ALARM_STATUS wird auf ALARM gesetzt<br />
* ALARM_Melder wird auf „on“ gesetzt. Dies erlaubt abgestuft zu reagieren, z.b. den Hautpalarm verzögert auszulösen und mit Zeitbegrenzung zu versehen.<br />
* ausserdem wird mit dem in der normalen Automation definiertem Dummy „Licht_an“ jedes im Haus schaltbare Licht eingeschaltet.<br />
<br />
Die Maßnahme zur Reduzierung der Funklast bei Bewegung im Haus wenn die Anlage scharf ist bewirkt jedoch, dass die Anlage stumm bleibt, nachdem die maximale (gesetzliche) Alarmdauer von 3 Minuten bei der Außensirene erreicht ist.<br />
Der Codeabschnitt:<br />
<br />
<nowiki>define ALARMIERT at +00:03:00 set ALARM_STATUS IRausgeloest</nowiki><br />
dient dazu, nach diesen 3 Minuten den Zustand der Anlage von „ALARM“ auf „IRausgeloest“ zu setzen. Somit würde nach 3 Minuten eine erneute Bewegung die Anlage erneut auslösen und die Sirene würde ebenso erneut ausgelöst.<br />
<br />
=== Sirene ===<br />
<nowiki>#------Sirene---------------------------------------<br />
define act_on_ALARM_Melder notify ALARM_Melder:on<br />
{ if (Value("ANLAGE_STATUS") eq &quot;scharf&quot;) { fhem(&quot;define EXT_SIRENE_AN <br />
at +00:00:15 set HM_SIRENE on-for-timer 176&quot;) }}</nowiki><br />
Es wird vor dem Einschalten der Sirene letztmalig überprüft, ob die Anlage scharf ist (Bei zusätzlicher Auslösemöglichkeit durch Panikschalter o.ä. müsste dieser Punkt angepasst werden). Wenn ja, wird die Sirene zeitverzögert um 15 Sekunden für 3 Minuten eingeschaltet. Da die interne Sirene direkt an die Alarmauslösung gekoppelt ist, erzeugt dies nach einem Fehlalarm (interne Sirene bereits an) noch etwas Zeit, die Alarmanlage schnell auszuschalten, bevor auch die externe Sirene aktiviert wird.<br />
<br />
== Praxis ==<br />
Es empfiehlt sich, die Anlage zunächst ohne externe Sirene zu betreiben, am Anfang eventuell sogar mit gedämpfter interner Sirene. Erfahrungsgemäss dauert es mindestens 2-3 Wochen, bis alle Familienmitglieder an die Anlage denken, bevor sie das Haus betreten.<br />
<br />
<br />
<br />
== Weitere Schritte ==<br />
* Bei externer Scharfschaltung löst das Betätigen von Schaltern (jemand macht das Licht an) Alarm aus<br />
* nach einem längeren Zeitraum ohne erkennbare Aktivität im Innenraum (keiner da, vergessen scharf zu schalten) schaltet sich die Anlage selber scharf.<br />
* Alarmierung bei Auslösung von Feuermeldern<br />
* diverse etwas unsaubere Stellen bereinigen (Defintion aller Dummies und Aktoren zusammenfassen, Code vereinheitlichen, Funklast weiter reduzieren, etc.)<br />
* In Zusammenhang mit im Wiki an anderer Stelle beschriebenen "Zuhause Status" Überprüfungen lässt sich eventuell eine vollautomatische Scharf/-Unscharfschaltung bei An- und Abwesenheit berechtigter Personen realisieren.<br />
* Hier wird eine LED-Anzeige auf 1-wire Basis beschrieben: [[1-Wire_LED-Statusmonitor]]<br />
* Hier wird eine Dual LED-Anzeige auf FS20 Basis beschrieben: [[FS20_Statusanzeige_mit_Dual-LED]]<br />
* Als Scharfanzeige im Aussenbereich eignet sich auch gut die [[HM-Dis-TD-T Retro Anzeige]]<br />
<br />
[[Kategorie:Code Snippets]]</div>MGuhttp://wiki.fhem.de/w/index.php?title=Alarmanlage&diff=23980Alarmanlage2017-12-31T13:09:44Z<p>MGu: Die Grenzen sind leder sehr deutlich.</p>
<hr />
<div>Mit FS20 und/oder HM Komponenten lassen sich auch Alarmanlagen realisieren. Im Folgenden soll eine einfache Alarmanlage beschrieben werden. Die Beschreibung ist an manchen Stellen noch unvollständig und außerdem an konkrete Begebenheiten angepasst. Sie soll daher nur als Anregung dienen, ferner werden einige typische Probleme diskutiert.<br />
<br />
Alternativ kann eine Alarmanlage auch über das [[Modul_Alarmanlage]] realisiert werden, das einem einiges an Arbeit abnimmt.<br />
<br />
<br />
== Anforderung ==<br />
Die Alarmanlage soll mittels Taster im Innenraum und Fernbedienungen scharf und unscharf gestellt werden können. Die Scharfschaltung soll verzögert erfolgen. Der Zustand der Anlage soll auf dem Webinterface aber auch auf einer im Haus zu montierenden Anzeige sichtbar sein. Die Auslösung soll beim Verletzen der Aussenhaut und bei Bewegung im Innenraum erfolgen. Es soll im Moment der Auslösung grob angezeigt werden, in welchem Bereich ausgelöst wurde.<br />
<br />
== Vorausetzung ==<br />
Voraussetzung sind Sensoren. Vielfach sind aber Bewegungsmelder und Türkontakte vorhanden, unter Umständen muss nur wenig ergänzt werden. Im konkreten Fall waren auch schon mehrere [[FS20 PIRA Infrarot-Bewegungsmelder]] installiert.<br />
<br />
== Design / Anzeige / Schaltlogik ==<br />
Der Zustand der Anlage muss angezeigt werden. Dies kann zum Teil über einen Raum "Alarmanlage" geschehen, den man per WebGUI ansehen kann, denkbar ist aber auch eine Hardwareanzeige. Im konkreten Fall wurde ein [[FS20 SM8 8-Kanal-Schaltmodul]] realisiert. Dessen Ausgänge können direkt bis zu 12 Volt 1 Ampere schalten, was für Leuchtdioden und sogar 12 Volt Sirenen ausreicht. Wichtig ist vor allem, dass von außen zu sehen ist, dass die Anlage scharf ist. Hierzu kann im Bereich der Eingangstür eine Leuchtdiode angebracht werden, die durch einen Kanal des FS20SM8 angesteuert wird. Es empfiehlt sich eine blinkende LED zu verwenden, da Blinken über einen grösseren Zeitraum mit FHEM/FS20 kaum realisierbar ist.<br />
<br />
Zunächst muss die Anlage ein und auschaltbar sein, oder besser: scharf und unscharf.<br />
Ferner soll zwischen "scharf" und nur "scharf intern" unterschieden werden. Scharf intern soll dabei nur die Aussenhautsensoren überwachen (Türen, Fenster) nicht jedoch Innenraumsensoren (Bewegungsmelder, Taster)<br />
<br />
Scharf intern wird also eingeschaltet, wenn sich Bewohner im Gebäude aufhalten eine Grundsicherung aber dennoch erfolgen soll, typischerweise also nachts. Ebenso ist die interne Scharfschaltung sinnvoll, wenn z.B. Hunde alleine im Haus zurückbleiben, die sonst eventuell die Bewegungsmelder auslösen würden.<br />
<br />
Das Einschalten soll zwar per Fernbedienung passieren, zusätzlich aber über im Haus verdeckt angebrachte Taster. <br />
Die im Haus angebrachten Taster ermöglichen Scharf- und auch Unscharfschalten ohne Eingabe weiterer Berechtigungen, d.h. es ist derzeit kein Codeschloss oder dergleichen realisiert. Die Sicherheit ergibt sich auschliesslich dadurch, dass die Taster getarnt und als solche nicht erkennbar sind. Hierzu wurden nicht als Taster erkennbare Mechanismen mit einem [[FS20 S4M 2-/4-Kanal-Sendemodul|FS20 S4M]] verbunden, das als Sender dient.<br />
<br />
Um Fehlbedienungen zu erschweren sind Wartezeiten eingebaut: Nach der letzten Unscharfschaltung müssen 11 Sekunden vergehen, bis wieder scharf geschaltet werden kann. <br />
<br />
Die Scharfschaltung muss außerdem verzögert erfolgen, damit man bereits im Inneren des Hauses scharf schalten kann aber noch genug Zeit hat das Haus zu verlassen. Hier ist eine Minute ausreichend.<br />
<br />
Um diese diversen Zustände zu steuern, werden mehre Variablen (dummys) und FS20 Aktoren eingerichtet, nämlich:<br />
<br />
* ANLAGE_STATUS<br />
* ALARM_STATUS<br />
* ANLAGE_SCHARF<br />
* ALARM_AKTOR<br />
<br />
Zur Anzeige außerdem:<br />
<br />
* Scharfanzeige1<br />
* Scharfanzeige2<br />
<br />
<br />
Im Einzelnen:<br />
<br />
<br />
'''ANLAGE_STATUS'''<br />
<br />
Ein reiner Dummy, der folgende Werte annehmen kann<br />
<br />
* aus (Anlage initialisiert, ohne weitere Funktion)<br />
* 60sec (Anlage wurde scharf geschaltet, ein Minute Wartezeit bis Aktivierung)<br />
* scharf (Anlage ist scharf)<br />
* scharf_intern (Anlage ist intern scharf, es werden nurAussenhautsensoren überwacht)<br />
* warten (Anlage wurde unscharf geschaltet, kann aber die nächsten 11 Sekunden noch nicht erneut scharf geschaltet werden.<br />
* unscharf (Anlage ist unscharf)<br />
<br />
<br />
'''ALARM_STATUS'''<br />
<br />
Ein reiner Dummy, der folgende Werte annehmen kann<br />
<br />
* aus (Anlage initialisiert, ohne weitere Funktion)<br />
* bereit (Anlage scharf, keine Alarmauslösung)<br />
* ALARM (Anlage scharf, Alarmauslösung)<br />
* unscharf (Anlage unscharf)<br />
* IRausgeloest (Anlage ist scharf, Alarmauslösung durch Bewegungsmelder, letzte Bewegung vor mindestens 3 Minuten)<br />
<br />
Es ist möglich die Satus ANLAGEN_STATUS und ALARM_STATUS in einer Variabel zusammen zu fassen, was die Sache aber unübersichtlich macht.<br />
<br />
<br />
'''ANLAGE_SCHARF'''<br />
<br />
Ein FS20 Schalter, der dazu da ist, die Alarmanlage mit den Tastern im Haus, einer Fernbedienung oder ggf. über die Webseite zu schalten. ON soll die Anlage scharf schalten, OFF unscharf. <br />
Ferner kann überlegt werden, auch versehentlich zu lange Tastendrücke (dimup und dimdown) abzufangen und zum Schalten zuzulassen.<br />
<br />
<br />
'''ANLAGE_SCHARF_intern'''<br />
<br />
Ein FS20 Schalter, der dazu da ist, die Alarmanlage mit den Tastern im Haus, einer Fernbedienung oder ggf. über die Webseite zu schalten. ON soll die Anlage scharf_intern schalten, OFF unscharf. <br />
Ferner kann überlegt werden, auch versehentlich zu lange Tastendrücke (dimup und dimdown) abzufangen und zum Schalten zuzulassen.<br />
<br />
<br />
'''ALARM_AKTOR'''<br />
<br />
Ein FS20 Aktor, der dazu dient die Sirenensteuerung zu triggern.<br />
Die Signalisierung bei Alarm ist 2-stufig aufgebaut. ALARM_STATUS löst im Inneren des Hauses direkt eine Alarmanzeige (LED und/oder interne Sirene aus).<br />
Äussere Signaleinrichtungen unterliegen aber gesetzlichen Regelungen was die Länge der Alarmierung betrifft und werden daher durch eine eigene Logik bzw. einen eigene Aktor betrieben: ALARM_AKTOR <br />
<br />
<br />
Zur Anzeige ausserdem:<br />
<br />
Scharfanzeige1<br />
<br />
Scharfanzeige2<br />
<br />
<br />
FS20 Aktoren, die mittels LED den Zustand der Anlage zeigen:<br />
<br />
* Scharfanzeige1 leuchtet, wenn die Anlage scharf geschaltet wurde (nur intern oder komplett) und auch, wenn die Anlage zwar scharf geschaltet wurde, aber die eine Minute Wartezeit noch nicht um ist. Sie dient als sofortiges Feedback, dass die Einschaltung erfolgreich war. Wird die Anlage unscharf geschaltet, leuchtet Scharfanzeige1 noch so lange wie die Anlage im Status „warten“ ist, also nicht erneut scharf geschaltet werden kann.<br />
* Scharfanzeige2 hingegen leuchtet nur, wenn der Anlagenstatus „scharf“ ist (nur intern oder komplett), also 1 Minute nach dem Einschalten. Hier kann z.b. eine zweite LED im Aussenbereich angebracht werden, die von außen sichtbar anzeigt, dass die Anlage scharf ist. Scharfanzeige2 geht sofort aus, wenn die Anlage unscharf geschaltet wird, sodass von außen kontrollierbar ist, ob die Anlage erfolgreich unscharf gestellt wurde.<br />
<br />
<br />
Mit zwei LEDs (oder ähnlichen Aktoren) können also Zustände der Anlage (ausser dem eigentlichen Alarm) angezeigt werden:<br />
<br />
Nach einschalten:<br />
<br />
Scharfanzeige1 Scharfanzeige2 Status der Anlage<br />
aus aus unscharf <br />
an aus eingeschaltet, 1 Minute Wartezeit<br />
an an scharf<br />
<br />
Durch weitere Anzeigen ließe sich zwischen scharf und scharf_intern unterscheiden. Speziell von aussen betrachtet bringt dies aber wenig Erkenntnisgewinn, da ein versehentliches Öffnen der Tür in beiden Fällen Alarm auslösen würde.<br />
<br />
Nach ausschalten:<br />
<br />
Scharfanzeige1 Scharfanzeige2 Status der Anlage<br />
an aus unscharf, noch warten <br />
aus aus unscharf, einschaltbar<br />
<br />
== Praktische Probleme ==<br />
=== Grenzen ===<br />
<br />
Die Alarmanlage ist insgesamt nur so sicher wie die verwendeten Komponenten. Die hier eingesetzten FS20 Sensoren und Sender sind funktechnisch nicht sicher und könnten von Dritten, die über geeignete Kenntnisse, Geräte und Zeit verfügen, analysiert und dann bedient werden. Sie dient nur der Grundsicherung gegen "durchschnittlich begabte" Einbrecher. Sie ist besser als nichts, weil man wohl davon ausgehen kann, dass normale Einbrecher nicht über das notwendige Wissen verfügen, überdies würde der zeitliche Aufwand das Objekt eventuell weniger lohnend erscheinen lassen.<br />
Es ist aber definitiv möglich, die Anlage mit einer FHEM Installation auf einem Laptop inklusive z.B. einem CUL abzuschalten, wenn die nötige Kenntnisse vorliegen.<br />
Mit HomeMatic Komponenten kann höhere Sicherheit erreicht werden, insbesondere wenn der AES Signing Request mit eigenem Schlüssel verwendet wird.<br />
<br />
Neben der informationstechnischen Unsicherheit muss auch immer berücksichtigt werden, dass lizenzfreie Funkübertragung überwiegend in einigen wenigen Frequenzbereichen (433MHz, 868MHz, 2.4GHz) realisiert wird. Für alle diese Bereiche gibt es in zwischen Störsender. Diese werden z.B. von Autodieben verwendet um die GPS-Überwachung per Mobilfunk außer Betrieb zu setzen. Der Betrieb solcher Störsender ist wesentlich einfacher als die Analyse der IT-Komponenten. Jemand der sich durch einen Einbruch strafbar macht, hat keinerlei Grund sich an Fernmeldegesetze zu halten. Sogar die Datenübertragung über das eigene Stromnetz (HomePlug) lässt sich relativ einfach stören. Viele Häuser haben aber Außensteckdosen, Lampen diverse Gartenautomatisierung etc. die gut geeignet sind um Störungen ein zu koppeln. Selbst ohne direkten Zugang zu einer Stromleitung kann eine geeignet breitbandige Störung induktiv eingekoppelt werden.<br />
<br />
Nun könnte man den Betrieb eines Störsenders oder Manipulationen an Komponenten am Verbindungsverlust oder Statusänderungen merken. Doch was dann tun? Einfach mal auf Verdacht den Alarm auslösen auch wenn es dann doch nur eine gewöhnliche Störung war? Jeder einzelne Fehlalarm konditioniert die Nachbarn zum nichts tun.<br />
<br />
Wenn alles tut und die Heimautomatisierung einen Einbruch erkennt, bleibt immer noch die Frage was zu tun ist. Die Aufmerksamkeit der Nachbarn erregen? Einen SMS, e-Mail oder ähnliches absetzen? Wer hat nicht schon mal irgendwo eine Alarmsirene gehört und auch einfach nichts getan. Die typischen Sirenen mit rotem Blinklicht werden regelmäßig mit Bauschaum und einem Deckel deaktiviert. Derlei Sirenen aus denen noch der Bauschaum quillt, sind in großen Städten immer wieder zu sehen. Diese Methode funktioniert mit einem langen Röhrchen sogar an sehr schlecht zugänglichen Stellen und aktiviert in der Regel keine Sabotagekontakte. Langer Rede kurzer Sinn: Es muss die gesamte Meldekette bis zu einer Person die etwas unternimmt manipulationssicher und sehr schnell funktionieren, sonst sind Einbrecher mit dem was sie holen wollten weg bevor irgend jemand reagiert. Auch Videoaufzeichnungen von Leuten mit Sturmhauben nutzen nichts. Die polizeiliche Aufklärungsquote beim Straftatbestand Wohnungseinbruchdiebstahl in Deutschland schwankte von 1999 bis 2016 zwischen 15 und 20% [https://de.statista.com/statistik/daten/studie/152583/umfrage/entwicklung-der-polizeilichen-aufklaerungsquoten-bei-wohnungseinbruchdiebstahl-seit-1995/]. Vier von fünf Einbrüchen bleiben unaufgeklärt. Daran hat der in den letzten Jahren einsetzende Boom der Hausautomatisierung kaum etwas geändert. Im Gegenteil die Aufklärungsquote war noch nie so niedrig wie 2015.<br />
<br />
=== Abstraktionlayer ===<br />
Wenn die Haussteuerung vor dem „Bau“ der Alarmanlage bereits besteht und wenn verschiedene Sensortypen eingesetzt werden, so sind die Namen der Sensoren vermutlich nicht nach den Bedürfnissen der Alarmanlage strukturiert benannt.<br />
Ausserdem liefern z.b. FHT Türsensoren andere Ergebnisse als FS20 und HM Türsensoren:<br />
<br />
* FHT80TF -&gt; Open / Closed<br />
* HM-SEC-SC -&gt; open / closed<br />
* FS 20 TFK -&gt; on / off<br />
<br />
Dadurch ist eine einfache Abfrage, ob eine Tür oder ein Fenster offen ist nicht möglich, vielmehr müssten alle Kontakte einzeln per notify behandelt werden.<br />
<br />
Ausserdem:<br />
<br />
* Die [[FHT80TF]] senden ihren Status alle ca 2 Minuten. Ohne eine zusätzliche Logik würden simple notifys daher alle 2 Minuten ausgelöst. <br />
* PIRA/PIRIs sind meist so konfiguriert, dass sie zwar bei Bewegung ein Event senden (etwa um Licht einzuschalten) aber kein Event, wenn keine Bewegung (für eine bestimmte Zeit) erkannt wurde. Dies muss berücksichtigt werden.<br />
<br />
Um nicht nachträglich alle Sensoren umbennen zu müssen und um die Zustände zu vereinheitlichen, wurde eine Abstraktionschicht eingeführt. Dazu werden alle Sensoren einer Meldegruppe bzw Funktionsgruppe als Dummy mit strukturierten Namen neu angelegt und deren Zustand über notifys der eigentlichen Sensoren ausgelöst.<br />
<br />
Durch die Alarmanlage werden nur Events der Dummies abgefragt.<br />
<br />
Dieses Vorgehen hat folgende Vorteile:<br />
<br />
* Vereinheitlichung der Namen<br />
* Vereinheitlichung der Zustände.<br />
* zusätzliche Logik in den Notifies der Dummys, z.b. Rücksetzen der Bewegungsmelder, Verzögerungen<br />
* Anzeige aller Sensoren in einem Raum („Alarmanlage“) ohne weitere Strukture-Konstrukte und unabhängig vom eigentlichen Sensor.<br />
* Manipulation der Dummysensoren ohne dass ausserhalb der Alarmanlage Aktionen ausgelöst werden . (Es kann z.b. zu Testzwecken eine Bewegungsmelder auf ON gesetzt werden, ohne das die normalerweise ausgelöste Lichtschaltung erfolgt)<br />
<br />
=== Funklast ===<br />
Im Betrieb kann im Moment von Zustandsänderungen einiges an Funklast erzeugt werden. Die konkreten Installation wird mit zwei [[CUL]]s und einem [[HMLAN Konfigurator]] betrieben. Die Zustandsanzeige der Alarmanlage ist von beiden CULs mit vernünftigem RSSI erreichbar und daher konnten die Anzeigen auf die CULs per IOdev verteilt werden, um die Funklast zu senken.<br />
<br />
Dabei wurden die kritischen Signalisierungen (Scharfanzeige und Alarm) von den eher sekundären Anzeigen (Meldegruppen) getrennt, die aufgrund häufiger Statusänderungen oft ausgelöst werden. Die Auslösung des Alarmaktors (Sirene) wird über HM geroutet.<br />
<br />
== Kommentierter Code ==<br />
(Gegenwärtig sind Definitionen und zugehörige Funktionen zusammengefasst, eleganter ist es vermutlich, alle für die Anlage notwendigen Definitionen zusammen zu fassen)<br />
<br />
Der Code basiert auf PERL "if", nicht auf dem inzwischen verfügbaren FHEM Befehl DOIF.<br />
<br />
Der Code ist hier unstrukturiert als "Einzeiler" ausgeführt. Dies ist allein der Vorliebe des Erstellers geschuldet und hat keinen funktionalen Hintergrund. Im Code enthalten Zeilumbrüche sind vor Übernahme in eine eigene Konfiguration zu entfernen.<br />
<br />
=== Einschalten / auschalten ===<br />
<nowiki>#-----Scharf/unscharf--------------------------------<br />
define ANLAGE_STATUS dummy<br />
attr ANLAGE_STATUS room Alarmanlage<br />
define ANLAGE_SCHARF FS20 22224222 32<br />
attr ANLAGE_SCHARF dummy 1<br />
attr ANLAGE_SCHARF room Alarmanlage<br />
define ANLAGE_SCHARF_intern FS20 22224222 30<br />
attr ANLAGE_SCHARF_intern dummy 1<br />
attr ANLAGE_SCHARF_intern room Alarmanlage<br />
define Scharfanzeige1 FS20 22224222 01<br />
attr Scharfanzeige1 IODev CUL1<br />
define Scharfanzeige2 FS20 22224222 02<br />
attr Scharfanzeige2 IODev CUL1</nowiki><br />
Über diese Dummies und Aktoren wird die Anlage gesteuert. Die Anlage wurde mit einem von der sonstigen Installation abweichendem Hauscode versehen, als Beispiel 22224222<br />
<br />
<br />
<br />
==== Einschalten ====<br />
<nowiki>define act_on_ANLAGE_SCHARF_on notify ANLAGE_SCHARF:on { if (Value("ANLAGE_STATUS") ne &quot;scharf&quot; &amp;&amp;<br />
Value("ANLAGE_STATUS") ne &quot;60sec&quot; &amp;&amp; Value("ANLAGE_STATUS") ne &quot;warten&quot; ) { fhem(&quot;set Scharfanzeige1 on&#160;;; <br />
set ANLAGE_STATUS 60sec&#160;;; set ALARM_STATUS bereit&#160;;; define verzoegert_Heizung_absenken at +00:07:00 set <br />
Heizung_absenken on&#160;;; define verzoegert_scharf at +00:01:00 set ANLAGE_STATUS scharf&#160;;;;; <br />
set Scharfanzeige2 on&quot;) }}</nowiki><br />
Beim Betätigen des Tasters / Fernbedienung wird die Alarmanlage eingeschaltet, wenn:<br />
<br />
* der Taster ON gedrückt wurde<br />
* die Anlage nicht schon scharf ist (Vermeidung unnötiger Funklast)<br />
* die Anlage nicht innerhalb der letzten Minute scharf geschaltet wurde<br />
* die Anlage nicht innerhalb der letzten 11 Sekunden ausgeschaltet wurde.<br />
<br />
Das Scharfschalten löst folgende Aktionen aus:<br />
<br />
* die Scharfanzeige 1 wird aktiviert<br />
* Der Status der Anlage wird auf „60sec“ gesetzt, um anzudeuten, das sie noch nicht scharf ist, aber in einer Minute<br />
* der Alarmstatus wird auf „bereit“ gesetzt<br />
* die Heizung wird in 7 Minuten auf Absenkbetrieb gesetzt, in der Annahme, dass die Alarmanlage nur dann auf scharf gestellt wird, wenn alle das Haus verlassen haben. Die Verzögerung von 7 Minuten dient vor allem dazu, die erhebliche Funklast der Heizungsabsenkung – Brenner und alle FHTs werden verstellt - zeitlich von (auch mehrfachen) Scharfschaltungen zu entkoppeln. Dies erhöht die Zuerlässigkeit der Alarmanlage.<br />
* mittels ''define verzoegert_scharf at +00:01:00'' wird die Anlage eine Minute nach Scharfschaltung tatsächlich scharf geschaltet, gleichzeitig wird Scharfanzeige2 eingeschaltet, die eine auch im Außenbereich sichtbare Anzeige aktiviert.<br />
<br />
==== Einschalten intern ====<br />
<nowiki>define act_on_ANLAGE_SCHARF_intern_on notify ANLAGE_SCHARF_intern:on { if (Value("ANLAGE_STATUS") ne &quot;scharf_intern&quot; &amp;&amp;<br />
Value("ANLAGE_STATUS") ne &quot;60sec&quot; &amp;&amp; Value("ANLAGE_STATUS") ne &quot;warten&quot; ) { fhem(&quot;set Scharfanzeige1 on&#160;;; <br />
set ANLAGE_STATUS 60sec&#160;;; set ALARM_STATUS bereit&#160;;; define verzoegert_scharf at +00:01:00 set ANLAGE_STATUS scharf_intern&#160;;;;; set Scharfanzeige2 on&quot;) }}</nowiki><br />
Das Verhalten ist analog zur normalen Scharfschaltung. Jedoch wird die Heizung nicht abgesenkt.<br />
Die Alarmanlage kann auch ohne vorheriges Auschalten von einer Scharfschaltung in die andere überführt werden. <br />
Dies kann nützlich sein, wenn z.b. von aussen versehentlich nur intern scharf gestellt wurde. Es ist dann möglich direkt auf komplette Scharfschaltung zu erweitern.<br />
<br />
==== Ausschalten ====<br />
<nowiki>define act_on_ANLAGE_SCHARF_off notify ANLAGE_SCHARF.*:off { if (Value("ANLAGE_STATUS") eq &quot;scharf_intern&quot; || Value("ANLAGE_STATUS") eq &quot;scharf&quot;) <br />
{ fhem(&quot;set ALARM_Melder off&#160;;; <br />
set Scharfanzeige2 off&#160;;; delete verzoegert_scharf&#160;;; set ANLAGE_STATUS warten&#160;;; <br />
set ALARM_STATUS unscharf &#160;;; define Alarmanlage_aufraeumen <br />
at +00:00:11 set ANLAGE_STATUS unscharf&#160;;;;; set Scharfanzeige1 off&#160;;; <br />
delete verzoegert_Heizung_absenken&#160;;; set brenner on&#160;;; set ANLAGE_SCHARF_intern,ANLAGE_SCHARF off&quot;) } <br />
else { fhem(&quot;set ALARM_Melder off&#160;;; <br />
set Scharfanzeige2 off&#160;;; delete verzoegert_scharf&#160;;; set ANLAGE_STATUS warten&#160;;; <br />
set ALARM_STATUS unscharf &#160;;; define Alarmanlage_aufraeumen <br />
at +00:00:11 set ANLAGE_STATUS unscharf&#160;;;;; set Scharfanzeige1 off&#160;;; <br />
delete verzoegert_Heizung_absenken&quot;) }}</nowiki><br />
Beim Betätigen des Tasters / Fernbedienung wird die Alarmanlage ausgeschaltet, wenn der Taster OFF gedrückt wurde. Durch ANLAGE_SCHARF.* (also das angehängte ".*") werden dabei beide Schalter ausgewertet, also sowohl<br />
ANLAGE_SCHARF<br />
als auch <br />
ANLAGE_SCHARF_intern.<br />
Beide Schalter schalten die Anlage bei OFF also aus, egal auf welche Art sie scharf geschaltet wurde.<br />
<br />
<br />
Das Unscharfschalten löst - sofern die Alarmanlage vorher scharf war - folgende Aktionen aus:<br />
<br />
* Der ALARM_Melder (wird weiter unten definiert) wird abgeschaltet. (konkret schaltet dies die eventuell laufende Aussensirene aus)<br />
* die Scharfanzeige 2 wird deaktiviert, damit ist auch von aussen sichtbar, dass die Unscharfschaltung erfolgreich war.<br />
* „verzoegert_scharf“ wird gelöscht, sofern es existiert. Dies verhindert vor allem, das die Anlage sich unkontrolliert selber scharf schaltet, wenn die Unscharfschaltung innerhalb einer Minute nach Scharfschaltung erfolgt (Im Haus was vergessen eben nochmal rein...). Im Normalfall erzeugt dies eine Fehlermeldung, da „verzoegert_scharf“ nach finaler Scharfschaltung nicht mehr exisitert, die Fehlermeldung kann aber ignoriert werden.<br />
* Die Anlage wird auf „Warten“ gestellt . Dies soll verhindern, dass bei eventuell hektischem Manipulieren mit einer Fernbedienung die Anlage versehentlich sofort wieder scharf gestellt wird.<br />
* Der ALARM Status wird auf unscharf gesetzt (damit geht auch eine eventuell interne Sirene aus)<br />
* Die Scharfanzeige1 wird deaktiviert<br />
* Die Anlage wird per at +00:00:11 in 11 Sekunden in den finalen Zustand überführt und auf unscharf gestellt. Sie ist jetzt wieder bereit zum Einschalten. Sicherheitshalber wird außerdem die Scharfanzeige2 nochmal deaktiviert, ausserdem wird die eventuell noch vorhanden Absenkung der Heizung (letzte Scharfschaltung nur 7 Minuten oder weniger zurück) gelöscht. Im Normalfall erzeugt dies eine Fehlermeldung, da „verzoegert_Heizung_absenken“ 7 Minuten nach einer scharfschaltung nicht mehr existiert, die Fehlermeldung kann aber ignoriert werden. Zuletzt wird der Brenner eingeschaltet; hier sind weitere ähnliche „Willkommensaktionen“ denkbar, wie Licht im Hausflur einschalten oder dergleichen.<br />
* ANLAGE_SCHARF_intern und ANLAGE_SCHARF werden beide auf OFF gesetzt. Dies sorgt dafür das beide Schalter auf dem Webfrontend auf OFF stehen. Allerdings würde damit<br />
<nowiki>define act_on_ANLAGE_SCHARF_off notify ANLAGE_SCHARF.*:off</nowiki><br />
sich selbst auslösen. Um dies zu verhindern wird mit folgendem Abschnitt vorher geprüft, ob die Anlage überhaupt scharf war:<br />
<br />
<nowiki>define act_on_ANLAGE_SCHARF_off notify ANLAGE_SCHARF.*:off { if (Value("ANLAGE_STATUS") eq "scharf_intern" || (Value("ANLAGE_STATUS") eq "scharf")</nowiki><br />
<br />
<br />
Hier liesse sich eventuell auch mit "setstate" anstatt "set" arbeiten, da setstate nur den Status auf dem Webfrontend ändern würde.<br />
<br />
Ist die Anlage bei Betätigen eines Ausschalters nicht scharf, werden sicherheitshalber mit<br />
<br />
<nowiki>else { fhem(" ... ")</nowiki><br />
trotzdem alle Abschaltschritt ausgeführt, ausser ANLAGE_SCHARF_intern und ANLAGE_SCHARF auf OFF zu setzen (sowie den Brenner einzuschalten). Dies dient der höheren Robustheit, so können z.b. auch unklare Zustände der Anlage durch auschalten bereinigt werden. (Insbesondere der Fall, dass aus irgendwelchen Gründen die Sirenen an sind, obwohl die Anlage eigentlich aus ist.)<br />
<br />
==== Scharfanzeige aktualisieren ====<br />
<nowiki>define Scharfanzeige_update at +*00:10:00 { if (Value("ANLAGE_STATUS") eq &quot;scharf&quot; <br />
&amp;&amp; Value("ANLAGE_SCHARF") eq &quot;on&quot; ) { fhem (&quot;set Scharfanzeige2 on &quot;) }}</nowiki><br />
<nowiki>define Scharfanzeige_intern_update at +*00:30:00 { if (Value("ANLAGE_STATUS") eq &quot;scharf_intern&quot; <br />
&amp;&amp; Value("ANLAGE_SCHARF_intern") eq &quot;on&quot; ) { fhem (&quot;set Scharfanzeige2 on &quot;) }}</nowiki><br />
<br />
Diese Codeabschnitte dienen einzig dazu, sicherzustellen, dass die von außen sichtbare Scharfanzeige den Zustand der Alarmanlage auch korrekt anzeigt, selbst wenn die Auslösung bei der Scharfschaltung aufgrund von Funkstörungen nicht erfolgreich war.<br />
Nichts senkt die Akzeptanz einer Alarmanalge so nachhaltig wie eine Scharfschaltung z.b. per Weboberfläche (die die erfolgreiche Scharfschaltung anzeigt, auch wenn die Scharfanzeige2 nicht geschaltet werden konnte) und ein anschließend nach Hause zurückkehrendes Familienmitglied, das nicht sehen kann, dass die Anlage scharf ist und dann ohne Unscharfschaltung die Haustür aufmacht.<br />
<br />
Da dieser Teil im Falle einer scharfen Anlage regelmäßig Funklast erzeugt, ist der Abfrageabstand hinreichend gross zu wählen. Im Beispiel ist die Abfrage für internen Alarm länger, da angenommen wird, dass bei interner Scharfschaltung alle Bewohner sowieso im Haus sind.<br />
<br />
Beide Codeabschnitte könnten durch Verwendung von "oder" Bedingungen zusammengefasst werden was aber eventuell etwas unübersichtlich ist.<br />
<br />
=== Abstraktionsschicht für Türkontakte (Fensterkontakte) ===<br />
<nowiki>#------Tuerkontakte----Namen-und-Zustände vereinheitlichen-------<br />
define AussentuerEG_Eingang dummy<br />
attr AussentuerEG_Eingang room Alarmanlage<br />
attr AussentuerEG_Eingang loglevel 6<br />
<br />
define act_on_Eingang_TFK notify Eingang_TFK { if (Value("Eingang_TFK") eq &quot;off&quot;) <br />
{ fhem(&quot;define Eingangstuer_verzoegert_zu at +00:00:04 set AussentuerEG_Eingang zu&#160;;; set AussentuerEG_Eingang zu&quot;) } <br />
else { fhem(&quot;define Eingangstuer_verzoegert_offen at +00:00:04 set AussentuerEG_Eingang offen&quot;) }}<br />
define AussentuerEG_Terrasse dummy<br />
attr AussentuerEG_Terrasse room Alarmanlage<br />
attr AussentuerEG_Terrasse loglevel 6<br />
define act_on_Tuer_Wohn_u1 notify Tuer_Wohn_u { if (Value("Tuer_Wohn_u") eq &quot;Closed&quot;) <br />
{ fhem(&quot;set AussentuerEG_Terrasse zu&quot;) } else { fhem(&quot;set AussentuerEG_Terrasse offen&quot;) }}<br />
define AussentuerUG_Keller dummy<br />
attr AussentuerUG_Keller room Alarmanlage<br />
attr AussentuerUG_Keller loglevel 6<br />
define act_on_Tuer_Keller_Aussen1 notify Tuer_Keller_Aussen { if (Value("Tuer_Keller_Aussen") eq &quot;Closed&quot;) <br />
{ fhem(&quot;set AussentuerUG_Keller zu&quot;) } else { fhem(&quot;set AussentuerUG_Keller offen&quot;) }}<br />
define AussentuerUG_Heizungskeller dummy<br />
attr AussentuerUG_Heizungskeller room Alarmanlage<br />
attr AussentuerUG_Heizungskeller loglevel 6<br />
define act_on_Tuer_Heizungskeller1 notify Tuer_Heizungskeller { if (Value("Tuer_Heizungskeller") eq &quot;closed&quot;) <br />
{ fhem(&quot;set AussentuerUG_Heizungskeller zu&quot;) } else { fhem(&quot;set AussentuerUG_Heizungskeller offen&quot;) }}</nowiki><br />
Hier wird der Abstraktionslayer für die Türsensoren angelegt. Alle Dummies heißen „AussentuerXX_Ort“ und sind daher später mittels eines Events der Art notify Aussentuer.* abfragbar. Außerdem werden die verschiedenen Status der diversen Melder auf die Zusände „offen“ und „zu“ gemappt. Durch Loglevel= 6 wird verhindert, das die Zustandsänderungen gesondert im Log erscheinen, da die Zustandsänderungen der jeweiligen Sensoren bereits im Log vermerkt sind.<br />
<br />
Im Beispiel sind nur einige Türen aufgeführt, tatsächlich sind so alle Türen mit dem einen oder anderen Sensor einbindbar. Da die [[FHT80TF]] Sensoren (FHEM: FHTTK) nicht bei Statusänderungen senden, kann eine Alarmauslösung hier bis zu 2 Minuten verzögert erfolgen.<br />
<br />
<br />
Hier nicht ausgeführt, aber prinzipiell analog können Fenstersensoren aufgebaut werden. Mittels handelsüblicher Glasbruchsensoren, die an die externen Kontakte eines FS20 oder HM Türkontakts angeschlossen werden, lassen sich günstig Glasbruchmelder bauen. Bei Fenstern, die nicht optisch sichtbar sind (Kellerfenster) lässt sich anstatt eines „echten“ Glasbruchsensors der Glasbruch auch durch einen getrennt auf die Scheibe geklebten Magneten und HM-SEC-SC realisieren, bei Glasbruch fallen beide Komponenten höchstwahrscheinlich getrennt zu Boden und lösen dann aus.<br />
<br />
<br />
Die Eingangstür erfährt ausserdem eine Sonderbehandlung. Sie soll Alarm erst 4 Sekunden nach öffnen auslösen. Dies dient dazu bei z.b. vergessenem Sender das Haus dennoch betreten zu können. Und zwar hat man nach öffnen der Tür noch 4 Sekunden Zeit, die Alarmanlage mit dem innen verdeckt angebrachten Schalter unscharf zu schalten. Es liegt zunächst nahe, diese Verzögerung in die eigentliche (weiter unten beschriebene) Alarmauslösungsroutine einzubauen. Allerdings würde diese dadurch deutlich komplizierter, es wäre insbesondere nicht mehr möglich mit nur einem Ausdruck alle Türen auf einemal abzufragen.<br />
<br />
Anstelle dessen wird hier der Abstraktionslayer über dem eigentlichen Sensor verwendet um zusätzliche Funktionalität einzubauen:<br />
<br />
<nowiki>define act_on_Eingang_TFK notify Eingang_TFK { if (Value("Eingang_TFK") eq &quot;off&quot;)<br />
{ fhem(&quot;set AussentuerEG_Eingang zu ;; define Eingangstuer_verzoegert_zu at +00:00:04 set AussentuerEG_Eingang zu&quot;) } <br />
else { fhem(&quot;define Eingangstuer_verzoegert_offen at +00:00:04 set AussentuerEG_Eingang offen&quot;) }}</nowiki><br />
<br />
Hier wird einfach jeder Schaltvorgang des TFK 4 Sekunden verzögert. Wichtig ist es, dies auch beim Schliessen der Tür zu tun, da sonst bei einem (z.b. versehentlichen) schnellen Öffnen und Schliessen der Tür der Dummy "AussentuerEG_Eingang" den falschen Wert annehmen kann: Wird die Tür nämlich geöffnet, aber z.b. nach 2 Sekunden geschlossen, würde die AussentuerEG_Eingang zwar zunächst auf "zu" gesetzt, aber weitere 2 Sekunden später durch die 4 Sekunden Öffnungsverzögerung wieder auf "offen" gesetzt. Daher muss auch das Setzen von AussentuerEG_Eingang auf "zu" mit 4 Sekunden Verzögerung erneut erfolgen.<br />
<br />
Die zunächst naheliegend erscheinende Lösung, beim Schliessen das eventuelle noch vorhandene "Eingangstuer_verzoegert_offen" zu löschen, kann nicht verwendet werden, da dann ein Einbrecher, der es schaffen würden, die Tür zu öffnen und innerhalb von 4 Sekunden wieder zu schliessen keinen Alarm auslösen würde.<br />
<br />
=== Abstraktionsschicht für Bewegungsmelder ===<br />
<nowiki>#------Bewegungsmelder----Namen-und-Zustände vereinheitlichen-------<br />
define Bewegung_Wohnen_oben dummy<br />
attr Bewegung_Wohnen_oben room Alarmanlage<br />
define act_on_PIRI_WZ_o1 notify PIRI_WZ_o:on.* { fhem(&quot;set Bewegung_Wohnen_oben bewegung&#160;;; <br />
define reset_Bewegung_Wohnen_oben at +00:03:00 set Bewegung_Wohnen_oben keine &quot;) }<br />
<br />
define Bewegung_Bad_EG dummy<br />
attr Bewegung_Bad_EG room Alarmanlage<br />
<br />
define act_on_zk_pumpe1 notify zk_pumpe:on.* { fhem(&quot;set Bewegung_Bad_EG bewegung&#160;;; <br />
define reset_Bewegung_Bad_EG at +00:03:00 set Bewegung_Bad_EG keine &quot;) }<br />
define act_on_Licht1_Bad notify Licht1_Bad:on.* { fhem(&quot;set Bewegung_Bad_EG bewegung&#160;;; <br />
define reset_Bewegung_Bad_EG at +00:03:00 set Bewegung_Bad_EG keine &quot;) }</nowiki><br />
Hier wird der Abstraktionslayer für Bewegungsmelder definiert. Exemplarisch sind 2 Melder aufgehführt. Alle Dummies heissen „Bewegung_Ort1_ort1“ und sind daher mit „notify Bewegung.*“ abfragbar<br />
Alle Zustände werden auf „bewegung“ bzw „keine“ gemappt.<br />
Da Bewegungsmelder idR. Nur „on“ melden, aber nicht „off“ bei keiner Bewegung, wird hier 3 Minuten nach einer Auslösung der Zustand auf „keine“ gesetzt. Diese Zeit ist mit den eingestellten Sendezeiten des Bewegungsmelders abzustimmen.<br />
<br />
Ein Besonderheit ist Bewegung_Bad_EG: Historisch bedingt ist hier ein Bewegungsmelder direkt mit der Zirkulationspumpe gekoppelt, bzw über den zweiten Kanal mit dem Licht im Badezimmer. Eine Besonderheit ist dabei, dass die Zirkulationspumpe nach 2 Uhr bis 6 Uhr trotz Auslösung nicht eingeschaltet wird (nachts will keiner duschen) und Licht tagsüber nicht angeht.<br />
Zur Abdeckung von Bewegungen über den gesamten Tagesverlauf müssen daher sowohl Statusänderung der Zirkulationspumpe als auch des Badezimmerlichts abgefragt werden. Als Nebeneffekt würde das Einschalten der Zirkulationspumpe über andere Methoden im Falle einer scharfen Alarmanlage einen Alarm auslösen. Tatsächlich lässt sich die Zirkulationspumpe über Schalter im Schlafzimmer und in der Küche für 15 Minuten einschalten. Faktisch spiel dies allerdings keine Rolle, da das Betätigen von Schaltern im Haus bei scharfer Alarmanlage eigentlich nur von unberechtigten Personen erfolgen kann.<br />
<br />
Eine mögliche Erweiterung ist sogar, dass Betätigen aller Schalter (außer den Tastern zum Schalten der Alarmanlage selbst) zur Alarmauslösung zu nutzen. Das ist hier noch nicht realisiert, da bei umfangreichen Automatisonsszenarien peinlich genau geprüft werden muss, ob Schaltungen nicht automatisch durch Scripte in FHEM erfolgen, also welche Lichter z.b. bei Dämmerung von alleine eingeschaltet werden.<br />
<br />
=== Meldegruppen ===<br />
<nowiki>#------Meldegruppenueberwachung----------------------<br />
define MeldegruppeUG FS20 22224222 11<br />
attr MeldegruppeUG IODev CUL2<br />
define MeldegruppeEG FS20 22224222 21<br />
attr MeldegruppeEG IODev CUL2<br />
define Meldegruppe3 FS20 22224222 31<br />
attr Meldegruppe3 IODev CUL2</nowiki><br />
<br />
Hier werden verschiedene Meldegruppen definiert. Es werden diverse Melder so zusammengefasst, dass eine grobe Anzeige des Auslöseortes möglich ist.<br />
Im Beispiel werden die Türen im Keller, Türen im EG und Bewegungsmelder zusammengefasst. Die Meldegruppen lösen einen Aktor aus, der den Zustand der Meldegruppe anzeigt, hier eine LED am Ausgang des FS20 8-Kanal-Schaltmodul FS20SM8. Da die Schaltung bei Bewegung im Haus relativ häufig erfolgt, ist als IOdev das schwächer belastetes RFR CUL definiert. <br />
(im folgenden Codebeispiel finden sich auch Melder, die in den Beispielen weiter oben der Übersichtlichkeit halber weggelassen wurden)<br />
<br />
<nowiki>define check_MeldegruppeUG_klar notify AussentuerUG.* { if (Value("MeldegruppeUG") eq &quot;off&quot; &amp;&amp; <br />
Value("AussentuerUG_Keller") eq &quot;zu&quot; &amp;&amp; Value("AussentuerUG_Waschkeller") eq &quot;zu&quot; &amp;&amp; <br />
Value("AussentuerUG_Heizungskeller") eq &quot;zu&quot;) { fhem (&quot;set MeldegruppeUG on&quot;) }}<br />
<br />
define check_MeldegruppeUG_unklar notify AussentuerUG.*:offen { if (Value("MeldegruppeUG") eq &quot;on&quot;) <br />
{ fhem(&quot;set MeldegruppeUG off&quot;) }}<br />
<br />
define check_MeldegruppeEG_klar notify AussentuerEG.* { if (Value("MeldegruppeEG") eq &quot;off&quot; &amp;&amp; <br />
Value("AussentuerEG_Schlafen") eq &quot;zu&quot; &amp;&amp; Value("AussentuerEG_Terrasse") eq &quot;zu&quot; &amp;&amp; <br />
Value("AussentuerEG_Eingang") eq &quot;zu&quot;) { fhem (&quot;set MeldegruppeEG on&quot;) }}<br />
<br />
define check_MeldegruppeEG_unklar notify AussentuerEG.*:offen { if (Value("MeldegruppeEG") eq &quot;on&quot;) <br />
{ fhem(&quot;set MeldegruppeEG off&quot;) }}<br />
<br />
define check_Meldegruppe3 notify Bewegung.* { if (Value("Bewegung_Wohnen_oben") eq &quot;keine&quot; &amp;&amp; <br />
Value("Bewegung_Bad_EG") eq &quot;keine&quot; &amp;&amp; Value("Bewegung_Wohnen_unten") eq &quot;keine&quot;) <br />
{ fhem (&quot;set Meldegruppe3 on&quot;) } else { fhem (&quot;set Meldegruppe3 off&quot;) }}</nowiki><br />
Hier wird jede Meldegruppe behandelt. Zunächst wird bei jeder Veränderung einer Aussentür in der passenden Etage (durch strukturierte Namen der Dummies mit einem notify abfragbar) geprüft, ob alle Türen zu sind und ob die Meldegruppe bisher „off“ (also „unklar“) war. Wenn alle Bedingungen zutreffen wird die Meldegruppe auf „on“ (also „klar“) gesetzt. <br />
<br />
"notify AussentuerEG.*" wird dabei durch den Einsatz der FHT80TF ca. alle 2 Minuten ausgelöst. Um zu verhindern, dass alle zwei Minuten - oder beim Einsatz mehrerer FHT80TF in einer Meldegruppe auch öfters – Funksignale zum Schalten einer LED ausgesendet werden, obwohl die LED bereits den richtigen Zustand hat, wird nach dem Zustand der Meldegruppe gefragt und nur ein „on“ gesendet, wenn die Gruppe vorher „off“ war.<br />
Dies macht das Auschalten über ein „else“ Statement aber schwierig, da die Gruppe dann auf „off“ geschaltet würde, wenn bei einem Event alle Türen zu sind, aber auch vorher schon alle zu waren und die Gruppe daher schon „on“ war.<br />
<br />
Die Gruppe wird daher über eine seperates notify ausgeschaltet, hier wird nur gesendet, wenn irgendeine der Türen seinen Status zu offen ändert und die Gruppe vorher „on“ war.<br />
<br />
Die Bewegungsmelder senden nur bei einem tatsächlichen Event. Es muss daher streng genommen nicht überprüft werden, welchen Zustand die Meldegruppe vorher hatte. Jede Statusmeldung ist eine tatsächliche Änderung. Allerdings führt jede Auslösung eines Bewegungsmelders zu<br />
<nowiki>else { fhem (&quot;set Meldegruppe3 off&quot;) }</nowiki><br />
Sind viele Bewegungsmelder vorhanden und/oder werden diese oft ausgelöst (Wohnzimmer), kann hierdurch eine hohe Funklast entstehen. Es kann daher sinnvoll sein, diese Meldegruppe auch mit einer Zustandsüberprüfung zu versehen und die Meldegruppe nur dann auf "unklar" zu setzen, wenn sie vorher nicht schon "unklar" (=off) war:<br />
<nowiki>define check_Meldegruppe3 notify Bewegung.* { if (Value("Bewegung_Wohnen_oben") eq &quot;keine&quot; &amp;&amp; <br />
Value("Bewegung_Bad_EG") eq &quot;keine&quot; &amp;&amp; Value("Bewegung_Wohnen_unten") eq &quot;keine&quot;) <br />
{ fhem (&quot;set Meldegruppe3 on&quot;) } else { if (Value("Meldegruppe3") ne &quot;off&quot;) <br />
{ fhem (&quot;set Meldegruppe3 off&quot;) }}</nowiki><br />
<br />
Da die Meldegruppen den Zustand häufig ändern, kann überlegt werden, mit <br />
<nowiki>attr .... loglevel 6 </nowiki><br />
die Anzahl der Logeinträge zu reduzieren.<br />
<br />
=== Alarmauslösung und Behandlung ===<br />
<nowiki>#------Alarmauslösung-------------------------------<br />
define ALARM_STATUS dummy<br />
attr ALARM_STATUS room Alarmanlage<br />
define ALARM_Melder FS20 22224222 33</nowiki><br />
Hier wird der Dummy für den eigentlichen Alarm definiert sowie ein Aktor für den Alarmmelder, also typischerweise einen Aussensirene. <br />
ALARM_Melder ist dabei noch nicht der tatsächliche Aktor. In der konkreten Anlage ist der Aktor eine HM Schalter, da beim Auslösen der Aussensirene höchste Zuverlässigkeit gefordert ist. Die bidirektionale Kommunikation von HM ist daher vorteilhaft. Dieser HM Aktor wird durch ALARM_Melder per Notify ausgelöst. Die Abstraktion über den zusätzlichen FS20 Aktor dient hier nur dazu, die Sirene auch über andere FS20 Sender direkt auslösen zu können, z.b. durch einen Paniksender. Je nach gegebener Umgebung kann diese Abstraktion aufgegeben werden.<br />
<br />
==== Alarmauslösung durch Türöffnung ====<br />
<nowiki>define act_on_Aussentuer notify Aussentuer.*:offen <br />
{ if (Value("ANLAGE_STATUS") eq &quot;scharf&quot; || Value("ANLAGE_STATUS") eq &quot;scharf_intern&quot;) <br />
{ fhem(&quot;set ALARM_STATUS ALARM&#160;;; set Licht_an on&#160;;; set ALARM_Melder on&quot;) } }</nowiki><br />
Dieser Teil des Codes löst den Alarm aus, wenn eine Tür geöffnet wird. <br />
(Für Fenster gibt einen analogen Codeabschnitt)<br />
Hierbei verhalten sich die FHT80TF und "normale" FS20 Tür/Fensterkontakte unterschiedlich:<br />
Der FTH80TF löst Alarm aus, auch wenn er zum Zeitpunkt der Scharfschaltung schon offen war: eine nach spätestens ca. 4 Minuten kommende Meldung über den Zustand des Tür (oder des Fensters) löst den Alarm aus. Andere Sensoren ändern den Status jedoch nicht mehr, bis sie wieder geschlossen wurden und lösen daher keinen Alarm aus, wenn sie schon offen waren als die Alarmanlage scharf geschaltet wurde.<br />
<br />
In jedem Fall löst ein Wechsel des Zustandes als solches keinen Alarm aus. Wenn also z.b ein Fenster, das mit einem FHT80TF überwacht wird, erst vor kurzem geschlossen wurde und sein Zustand daher (innerhalb der ersten maximal 4 Minuten nach schliessen) noch auf "open" steht, so kann die Alarmanlage trotzdem scharf geschaltet werden. Die wenige Minuten später eintreffende Aktualisierung zu "closed" löst die Anlage nicht aus.<br />
<br />
Jedes „Tür offen“ Event löst die Prüfung aus, ob die Anlage scharf oder scharf_intern ist. <br />
(Dies geschieht durch den Perl-Ausdruck für "oder" " || ")<br />
<br />
Wenn die Anlage in einem der beiden Scharzfustände ist, wird<br />
<br />
* ALARM STATUS auf ALARM gesetzt. Damit wird die LED Anzeige für Alarm ausgelöst und eine ggf an den Aktor ebenfalls angeschlossene Sirene im Haus sofort ausgelöst. Für externe Sirenen wird jedoch der zusätzliche Aktor<br />
* ALARM_Melder auf „on“ gesetzt. Dies erlaubt abgestuft zu reagieren, z.b. den Hauptalarm verzögert auszulösen und mit Zeitbegrenzung zu versehen.<br />
* ausserdem wird mit dem in der normalen Automation definierten Dummy „Licht_an“ jedes im Haus schaltbare Licht eingeschaltet.<br />
<br />
Natürlich liessen sich auch weitere Aktionen auslösen.<br />
<br />
==== Alarmauslösung durch Bewegung ====<br />
<nowiki>define act_on_Bewegung notify Bewegung.*:bewegung { if (Value("ANLAGE_STATUS") eq &quot;scharf&quot; &amp;&amp; <br />
Value("ALARM_STATUS") ne &quot;ALARM&quot;) { fhem(&quot;set ALARM_STATUS ALARM&#160;;; set Licht_an on&#160;;; <br />
set ALARM_Melder on&#160;;; define ALARMIERT at +00:03:00 set ALARM_STATUS IRausgeloest&quot;) }}</nowiki><br />
Dieser Teil des Codes löst den Alarm aus, wenn eine Bewegung registriert wird.<br />
Weil Bewegungsmelder potentiell im Alarmfall häufiger ausgelöst werden als Türen, muss hier zur Vermeidung von Problemen mit dem Erreichen der maximalen Sendezeit nicht nur überprüft werden, ob die Anlage scharf ist, sondern auch, ob der Alarm bereits ausgelöst wurde. <br />
<br />
Ist dies nicht der Fall (also ist die Anlage unscharf oder ALARM_STATUS bereits auf „ALARM“) wird keine weitere Aktion ausgelöst. Dadurch wird die Anzahl der Funksignale deutlich reduziert.<br />
<br />
Dieser Teil reagiert ausserdem nicht, wenn die Anlage nur intern scharf ist.<br />
<br />
Ist die Anlage scharf und wurde bisher kein Alarm ausgelöst, dann erzeugt eine Bewegung:<br />
<br />
* ALARM_STATUS wird auf ALARM gesetzt<br />
* ALARM_Melder wird auf „on“ gesetzt. Dies erlaubt abgestuft zu reagieren, z.b. den Hautpalarm verzögert auszulösen und mit Zeitbegrenzung zu versehen.<br />
* ausserdem wird mit dem in der normalen Automation definiertem Dummy „Licht_an“ jedes im Haus schaltbare Licht eingeschaltet.<br />
<br />
Die Maßnahme zur Reduzierung der Funklast bei Bewegung im Haus wenn die Anlage scharf ist bewirkt jedoch, dass die Anlage stumm bleibt, nachdem die maximale (gesetzliche) Alarmdauer von 3 Minuten bei der Außensirene erreicht ist.<br />
Der Codeabschnitt:<br />
<br />
<nowiki>define ALARMIERT at +00:03:00 set ALARM_STATUS IRausgeloest</nowiki><br />
dient dazu, nach diesen 3 Minuten den Zustand der Anlage von „ALARM“ auf „IRausgeloest“ zu setzen. Somit würde nach 3 Minuten eine erneute Bewegung die Anlage erneut auslösen und die Sirene würde ebenso erneut ausgelöst.<br />
<br />
=== Sirene ===<br />
<nowiki>#------Sirene---------------------------------------<br />
define act_on_ALARM_Melder notify ALARM_Melder:on<br />
{ if (Value("ANLAGE_STATUS") eq &quot;scharf&quot;) { fhem(&quot;define EXT_SIRENE_AN <br />
at +00:00:15 set HM_SIRENE on-for-timer 176&quot;) }}</nowiki><br />
Es wird vor dem Einschalten der Sirene letztmalig überprüft, ob die Anlage scharf ist (Bei zusätzlicher Auslösemöglichkeit durch Panikschalter o.ä. müsste dieser Punkt angepasst werden). Wenn ja, wird die Sirene zeitverzögert um 15 Sekunden für 3 Minuten eingeschaltet. Da die interne Sirene direkt an die Alarmauslösung gekoppelt ist, erzeugt dies nach einem Fehlalarm (interne Sirene bereits an) noch etwas Zeit, die Alarmanlage schnell auszuschalten, bevor auch die externe Sirene aktiviert wird.<br />
<br />
== Praxis ==<br />
Es empfiehlt sich, die Anlage zunächst ohne externe Sirene zu betreiben, am Anfang eventuell sogar mit gedämpfter interner Sirene. Erfahrungsgemäss dauert es mindestens 2-3 Wochen, bis alle Familienmitglieder an die Anlage denken, bevor sie das Haus betreten.<br />
<br />
<br />
<br />
== Weitere Schritte ==<br />
* Bei externer Scharfschaltung löst das Betätigen von Schaltern (jemand macht das Licht an) Alarm aus<br />
* nach einem längeren Zeitraum ohne erkennbare Aktivität im Innenraum (keiner da, vergessen scharf zu schalten) schaltet sich die Anlage selber scharf.<br />
* Alarmierung bei Auslösung von Feuermeldern<br />
* diverse etwas unsaubere Stellen bereinigen (Defintion aller Dummies und Aktoren zusammenfassen, Code vereinheitlichen, Funklast weiter reduzieren, etc.)<br />
* In Zusammenhang mit im Wiki an anderer Stelle beschriebenen "Zuhause Status" Überprüfungen lässt sich eventuell eine vollautomatische Scharf/-Unscharfschaltung bei An- und Abwesenheit berechtigter Personen realisieren.<br />
* Hier wird eine LED-Anzeige auf 1-wire Basis beschrieben: [[1-Wire_LED-Statusmonitor]]<br />
* Hier wird eine Dual LED-Anzeige auf FS20 Basis beschrieben: [[FS20_Statusanzeige_mit_Dual-LED]]<br />
* Als Scharfanzeige im Aussenbereich eignet sich auch gut die [[HM-Dis-TD-T Retro Anzeige]]<br />
<br />
[[Kategorie:Code Snippets]]</div>MGuhttp://wiki.fhem.de/w/index.php?title=HomeMatic_Devices_pairen&diff=23954HomeMatic Devices pairen2017-12-30T15:07:30Z<p>MGu: Link auf Abschnitt</p>
<hr />
<div>HomeMatic Geräte müssen mit dem für das HomeMatic-Protokoll eingesetzten IO-Device (zB [[CUL]], CUN, [[HomeMatic|Homematic IO's]]) ''[[Pairing (HomeMatic)|gepairt]]'' (deutsch: "gepaart") werden, damit sie von FHEM gesteuert oder ausgelesen werden können.<br />
<br />
<br />
Die Adresse eines HomeMatic Gerätes ist nicht frei einstellbar, sondern für jedes Gerät fest vorgegeben. Da die HM-Geräte über eine sehr komplexe Kanalstruktur verfügen, empfiehlt sich daher, die Geräte in FHEM per ''autocreate'' Funktion anlegen zu lassen, Eine nachträgliche Umbenennung oder manuelle Bearbeitung der erzeugten Konfigurationsdaten ist problemlos möglich.<br />
<br />
Zunächst mal muss man einen [[HomeMatic_Installieren|CUL/CUN/Homematic IO installieren]]. <br />
<br />
Einige Geräte werden mit aktivierter [[AES Encryption]] ausgeliefert (Meistens, aber nicht immer mit SEC im Namen). Das Anlernen an HM IO's funktioniert ohne Probleme, für alle CUL Derivate muss unbedingt der Hinweis im Artikel AES Encryption im Abschnitt [[AES_Encryption#I.2FO-Device_←→_Gerät|I/O-Device ←→ Gerät]] beachtet werden. '''Die dort beschriebene Installation sollte generell vorgenommen werden!'''<br />
<br />
Danach geht es hier weiter:<br />
<br />
= Grundlagen=<br />
Durch das Pairing wird ein HM-Gerät genau einem IO-Device (zB CUL) zugeordnet. Wenn ein Gerät mit dem IO-Device gepairt ist, kann es darüber gesteuert werden. <br />
<br />
Beim Pairing wird die HMID des IO-Device in das Gerät geschrieben. Das Pairing findet also im Wesentlichen im Gerät statt, nicht in FHEM selbst.<br />
<br />
Zu bemerken ist, dass ein IO-Device (zB CUL) standardmäßig die ID F11034 von FHEM erhält. Da viele HM-Geräte das IO-Device nur anhand der HMIDs erkennen, können alle in Reichweite der HM-Geräte befindlichen IO-Devices mit der in das HM-Gerät geschriebenen HMID das HM-Gerät steuern. Hinzu kommt, dass die ''autocreate'' Funktion die in Reichweite befindlichen HM-Geräte findet und automatisch einbindet. Nachbarn, die IO-Devices mit der gleichen HMID betreiben, können also HM-Geräte untereinander sehen und steuern!<br />
<br />
Es ist daher dringen zu empfehlen, die HMID vor dem Pairing der HM-Geräte mit: <br />
<br />
attr <CUL> hmId <6-stellige Hexadresse><br />
<br />
zu individualisieren. <br />
<br />
Gepairt wird nur das Device. Die Channels sind dem Device untergeordnet und somit implizit auch gepairt. <br />
<br />
'''Achtung:''' Ist ein Device gepairt werden Konfigurationsänderungen über die Zentrale (FHEM) vorgenommen. Man kann u.a. keine Kanäle mehr ''direkt'' peeren (verknüpfen). Stattdessen verwendet man Kommandos in FHEM. Siehe <u>[[Homematic_Peering_Beispiele|peeren]]</u><br />
<br />
= IO-Device in den Pairing-Modus versetzen =<br />
* CUL/CUN/HMLAN Konfigurator in den "Akzeptiere-Pairing-Requests-Modus" bringen:<br />
<br />
set <CUL> hmPairForSec 600<br />
<br />
600 bedeutet hier, dass das IO-Device 600 Sekunden, also 10 Minuten lang im Pairing-Modus ist.<br />
<br />
Bei aktivem Pairing-Modus gibt das IO-Device folgende ''Internals'' Variable zurück: <br />
<br />
hmPair 1<br />
<br />
Alternativ kann <br />
<br />
set <CUL> hmPairSerial <serial><br />
<br />
genutzt werden.<br />
<br />
= Devices pairen =<br />
<br />
Das Gerät wird in den Anlern- oder auch Konfigurationsmode versetzt. Es sendet hierzu eine entsprechende Nachricht an alle.<br />
<br />
Falls das Gerät einen separaten Anlernknopf hat, ist der normalerweise nur ganz kurz zu drücken. <br />
Danach beginnt die LED regelmäßig zu blinken. Eine Ausnahme sind Geräte, bei denen eine Taste im regulären Betrieb für andere Zwecke verwendet wird. Bei einem [[HM-CC-RT-DN Funk-Heizkörperthermostat|Heizkörperthermostat]] z.B. muss die Boost-Taste (Mitte) für mindestens 3 Sekunden gedrückt gehalten werden.<br />
<br />
{{Randnotiz|RNText=Hinweis: Das genaue Vorgehen ist vom Gerätetyp abhängig -> unbedingt das Handbuch genau lesen: Stichwort "anlernen".}}<br />
Hat das Gerät keinen separaten Anlernknopf, muss in der Regel eine Taste solange gedrückt werden, bis die LED anfängt regelmäßig zu blinken.<br />
<br />
Kommt der Anlernvorgang in Gang, wird dies durch ein wechselndes, schnelles Blinken signalisiert. Kommt kein Anlernvorgang zustande, blinkt die LED regelmäßig für einen bestimmten Zeitraum (ca. 20 sec). <br />
Ist das Gerät schon angelernt, werden bei batteriebetriebenen Geräten eventuell auch noch nicht übertragende Daten gesendet. Dabei blinkt die LED auch unregelmäßig.<br />
In FHEM werden nun:<br />
* alle fehlenden Devices und Channels angelegt<br />
* das Register <code>pairCentral</code> im Device gesetzt. <br />
<br />
Ein <code>save</code> danach sichert die neu angelernten Geräte in der Konfiguration.<br />
<br />
Hinweis: Auch mit <code>hmPairForSec</code> kann jeweils nur '''ein''' Gerät angelernt werden. Für mehrere Geräte den Vorgang bitte wiederholen.<br />
<br />
= Pairing verifizieren =<br />
Nur weil ein Gerät angelegt wurde, heißt das '''nicht''', dass es auch gepaired ist. In den Readings eines Devices muss stehen (list <name> oder im Webinterface):<br />
<br />
R_pairCentral 0xABCDEF<br />
<br />
ABCDEF steht dabei für die HMID des IO-Device (zB CUL). Wurde für das IO-Device kein attribute mit einer individuellen HMID gesetzt, sollte hier die Standard-ID F11034 stehen. Die führende 0x steht für den Hinweis auf eine HEX-Adresse. <br />
<br />
Ist das Pairing noch nicht abgeschlossen, kann man nach kurzer Pause den Befehl: <br />
<br />
set <HM-Gerät> getConfig <br />
<br />
absetzen, um zu prüfen, ob sich der Status zwischenzeitlich geändert hat. Wenn das Reading R_pairCentral nicht auftaucht oder der Wert mit set_ beginnt hat das Pairing '''nicht''' geklappt. Man kann entweder:<br />
* noch einmal probieren, ein getConfig auszulösen - vielleicht hat das Lesen nicht funktioniert<br />
* noch einmal pairen - das schadet nichts<br />
* die Anlerntaste / Configtaste / irgendeine Taste am Gerät (hängt vom konkreten Device ab) wiederholt drücken um die Datenübertragung anzustoßen.<br />
<br />
Alternativ kann man auch mit HMinfo einen Config check durchführen:<br />
<br />
define hm HMInfo<br />
get hm configCheck<br />
<br />
= Vorgehen bei Problemen =<br />
<br />
Wenn das Pairing nicht erfolgreich ist, das Gerät sich also nicht steuern lässt, ist es möglich, dass es schon bzw. noch mit einem anderen IO-Device gepairt ist. Dann das Gerät in den Auslieferungszustand bringen (siehe Handbuch, oft Knopf mindestens 5 Sekunden drücken, bis es blinkt, dann loslassen und nochmals 5 Sekunden drücken, bis es schneller blinkt) und danach erneut pairen. <br />
<br />
Alternativ kann das Pairing per Befehl gelöst werden. Siehe dazu unten. <br />
<br />
Wenn das zu pairende Geräte ein Empfänger ist, kann mit FHEM per Telnet oder in der Kommandozeile des Webinterfaces folgendes Kommando abgesetzt werden:<br />
<br />
set <CUL> hmPairSerial <10-stellige Seriennummer><br />
<br />
Die 10-stellige Seriennummer ist beim Empfängern idR. auf der Rückseite des Geräte aufgedruckt. Die Seriennummer fängt normalerweise mit Buchstaben an und endet mit Zahlen.<br />
<br />
Es gilt auch sicherzustellen, dass das zu pairende Gerät nicht bereits zuvor mit der Homematic Config Software gepairt wurde. Ist dies der Fall, so sollte das Pairing in der Homematic Config Software gelöscht und das Pairing in FHEM erneut durchgeführt werden.<br />
<br />
Beim Pairen ist, wie im normalen Betrieb auch, ein Mindestabstand (etwa 1-2 Meter) zwischen dem Sender der Zentrale (CUL, HMLAN etc.) einzuhalten, da die Funkempfänger sonst mit Übersteuerung reagieren und keine Kommunikation zustande kommt.<br />
Außerdem kann die Funklast beim Auslesen einer unfangreichen Konfiguration eines Gerätes bereits nach wenigen Versuchen das Limit der 1%-Regel erreichen. Sollte also scheinbar keine Kommunikation stattfinden können, ist auch zu prüfen, ob der Zentralensender sich deswegen temporär deaktiviert hat.<br />
<br />
= Gezieltes Pairing =<br />
Bei bereits bekanntem HM-Gerät kann man mit:<br />
<br />
set <Name HM-Gerät> pair<br />
<br />
das pairing überschreiben. Es funktioniert aber nur, wenn schon ein IO-Device eingetragen ist.<br />
<br />
= Pairing lösen =<br />
Das Pairing kann mit:<br />
<br />
set <Name HM-Gerät> unpair<br />
<br />
gelöst werden. Wichtig ist dabei, dass das IO-Device, das entpairt werden soll, mit der ursprünglich in das HM-Gerät geschriebenen HMID konfiguriert ist. <br />
<br />
Sollte man z.B. ein HomeMatic HM-CC-RT-DN Funk-Heizkörperthermostat und ein Fensterkontakt verbunden haben, so steht unter THERMOSTAT_WindowRec im Attribut peerIDs die ID des Fensterkontakts.<br />
Bei einem Defekt des Fensterkontakts sollte man wie im HM-CC-RT-DN beschrieben das unset durchführen. Hat man aber das Device Fensterkontakt gelöscht und das Pairing nicht durchgeführt, so kann man die Zuordnung im Heizkörperthermostat dennoch mit folgenden Befehl aufheben.<br />
<br />
set <Name HM-Gerät>_WindowRec peerBulk <peerID> unset<br />
<br />
<br />
[[Kategorie:HomeMatic Components]]<br />
[[Kategorie:HOWTOS]]</div>MGuhttp://wiki.fhem.de/w/index.php?title=HomeMatic_Devices_pairen&diff=23953HomeMatic Devices pairen2017-12-30T15:01:52Z<p>MGu: /* Pairing lösen */ Text an Kategorie ist wirkungslos.</p>
<hr />
<div>HomeMatic Geräte müssen mit dem für das HomeMatic-Protokoll eingesetzten IO-Device (zB [[CUL]], CUN, [[HomeMatic|Homematic IO's]]) ''[[Pairing (HomeMatic)|gepairt]]'' (deutsch: "gepaart") werden, damit sie von FHEM gesteuert oder ausgelesen werden können.<br />
<br />
<br />
Die Adresse eines HomeMatic Gerätes ist nicht frei einstellbar, sondern für jedes Gerät fest vorgegeben. Da die HM-Geräte über eine sehr komplexe Kanalstruktur verfügen, empfiehlt sich daher, die Geräte in FHEM per ''autocreate'' Funktion anlegen zu lassen, Eine nachträgliche Umbenennung oder manuelle Bearbeitung der erzeugten Konfigurationsdaten ist problemlos möglich.<br />
<br />
Zunächst mal muss man einen [[HomeMatic_Installieren|CUL/CUN/Homematic IO installieren]]. <br />
<br />
Einige Geräte werden mit aktivierter [[AES Encryption]] ausgeliefert (Meistens, aber nicht immer mit SEC im Namen). Das Anlernen an HM IO's funktioniert ohne Probleme, für alle CUL Derivate muss unbedingt der Hinweis im Artikel AES Encryption im Abschnitt I/O-Device <-> Gerät beachtet werden. '''Die dort beschriebene Installation sollte generell vorgenommen werden!'''<br />
<br />
Danach geht es hier weiter:<br />
<br />
= Grundlagen=<br />
Durch das Pairing wird ein HM-Gerät genau einem IO-Device (zB CUL) zugeordnet. Wenn ein Gerät mit dem IO-Device gepairt ist, kann es darüber gesteuert werden. <br />
<br />
Beim Pairing wird die HMID des IO-Device in das Gerät geschrieben. Das Pairing findet also im Wesentlichen im Gerät statt, nicht in FHEM selbst.<br />
<br />
Zu bemerken ist, dass ein IO-Device (zB CUL) standardmäßig die ID F11034 von FHEM erhält. Da viele HM-Geräte das IO-Device nur anhand der HMIDs erkennen, können alle in Reichweite der HM-Geräte befindlichen IO-Devices mit der in das HM-Gerät geschriebenen HMID das HM-Gerät steuern. Hinzu kommt, dass die ''autocreate'' Funktion die in Reichweite befindlichen HM-Geräte findet und automatisch einbindet. Nachbarn, die IO-Devices mit der gleichen HMID betreiben, können also HM-Geräte untereinander sehen und steuern!<br />
<br />
Es ist daher dringen zu empfehlen, die HMID vor dem Pairing der HM-Geräte mit: <br />
<br />
attr <CUL> hmId <6-stellige Hexadresse><br />
<br />
zu individualisieren. <br />
<br />
Gepairt wird nur das Device. Die Channels sind dem Device untergeordnet und somit implizit auch gepairt. <br />
<br />
'''Achtung:''' Ist ein Device gepairt werden Konfigurationsänderungen über die Zentrale (FHEM) vorgenommen. Man kann u.a. keine Kanäle mehr ''direkt'' peeren (verknüpfen). Stattdessen verwendet man Kommandos in FHEM. Siehe <u>[[Homematic_Peering_Beispiele|peeren]]</u><br />
<br />
= IO-Device in den Pairing-Modus versetzen =<br />
* CUL/CUN/HMLAN Konfigurator in den "Akzeptiere-Pairing-Requests-Modus" bringen:<br />
<br />
set <CUL> hmPairForSec 600<br />
<br />
600 bedeutet hier, dass das IO-Device 600 Sekunden, also 10 Minuten lang im Pairing-Modus ist.<br />
<br />
Bei aktivem Pairing-Modus gibt das IO-Device folgende ''Internals'' Variable zurück: <br />
<br />
hmPair 1<br />
<br />
Alternativ kann <br />
<br />
set <CUL> hmPairSerial <serial><br />
<br />
genutzt werden.<br />
<br />
= Devices pairen =<br />
<br />
Das Gerät wird in den Anlern- oder auch Konfigurationsmode versetzt. Es sendet hierzu eine entsprechende Nachricht an alle.<br />
<br />
Falls das Gerät einen separaten Anlernknopf hat, ist der normalerweise nur ganz kurz zu drücken. <br />
Danach beginnt die LED regelmäßig zu blinken. Eine Ausnahme sind Geräte, bei denen eine Taste im regulären Betrieb für andere Zwecke verwendet wird. Bei einem [[HM-CC-RT-DN Funk-Heizkörperthermostat|Heizkörperthermostat]] z.B. muss die Boost-Taste (Mitte) für mindestens 3 Sekunden gedrückt gehalten werden.<br />
<br />
{{Randnotiz|RNText=Hinweis: Das genaue Vorgehen ist vom Gerätetyp abhängig -> unbedingt das Handbuch genau lesen: Stichwort "anlernen".}}<br />
Hat das Gerät keinen separaten Anlernknopf, muss in der Regel eine Taste solange gedrückt werden, bis die LED anfängt regelmäßig zu blinken.<br />
<br />
Kommt der Anlernvorgang in Gang, wird dies durch ein wechselndes, schnelles Blinken signalisiert. Kommt kein Anlernvorgang zustande, blinkt die LED regelmäßig für einen bestimmten Zeitraum (ca. 20 sec). <br />
Ist das Gerät schon angelernt, werden bei batteriebetriebenen Geräten eventuell auch noch nicht übertragende Daten gesendet. Dabei blinkt die LED auch unregelmäßig.<br />
In FHEM werden nun:<br />
* alle fehlenden Devices und Channels angelegt<br />
* das Register <code>pairCentral</code> im Device gesetzt. <br />
<br />
Ein <code>save</code> danach sichert die neu angelernten Geräte in der Konfiguration.<br />
<br />
Hinweis: Auch mit <code>hmPairForSec</code> kann jeweils nur '''ein''' Gerät angelernt werden. Für mehrere Geräte den Vorgang bitte wiederholen.<br />
<br />
= Pairing verifizieren =<br />
Nur weil ein Gerät angelegt wurde, heißt das '''nicht''', dass es auch gepaired ist. In den Readings eines Devices muss stehen (list <name> oder im Webinterface):<br />
<br />
R_pairCentral 0xABCDEF<br />
<br />
ABCDEF steht dabei für die HMID des IO-Device (zB CUL). Wurde für das IO-Device kein attribute mit einer individuellen HMID gesetzt, sollte hier die Standard-ID F11034 stehen. Die führende 0x steht für den Hinweis auf eine HEX-Adresse. <br />
<br />
Ist das Pairing noch nicht abgeschlossen, kann man nach kurzer Pause den Befehl: <br />
<br />
set <HM-Gerät> getConfig <br />
<br />
absetzen, um zu prüfen, ob sich der Status zwischenzeitlich geändert hat. Wenn das Reading R_pairCentral nicht auftaucht oder der Wert mit set_ beginnt hat das Pairing '''nicht''' geklappt. Man kann entweder:<br />
* noch einmal probieren, ein getConfig auszulösen - vielleicht hat das Lesen nicht funktioniert<br />
* noch einmal pairen - das schadet nichts<br />
* die Anlerntaste / Configtaste / irgendeine Taste am Gerät (hängt vom konkreten Device ab) wiederholt drücken um die Datenübertragung anzustoßen.<br />
<br />
Alternativ kann man auch mit HMinfo einen Config check durchführen:<br />
<br />
define hm HMInfo<br />
get hm configCheck<br />
<br />
= Vorgehen bei Problemen =<br />
<br />
Wenn das Pairing nicht erfolgreich ist, das Gerät sich also nicht steuern lässt, ist es möglich, dass es schon bzw. noch mit einem anderen IO-Device gepairt ist. Dann das Gerät in den Auslieferungszustand bringen (siehe Handbuch, oft Knopf mindestens 5 Sekunden drücken, bis es blinkt, dann loslassen und nochmals 5 Sekunden drücken, bis es schneller blinkt) und danach erneut pairen. <br />
<br />
Alternativ kann das Pairing per Befehl gelöst werden. Siehe dazu unten. <br />
<br />
Wenn das zu pairende Geräte ein Empfänger ist, kann mit FHEM per Telnet oder in der Kommandozeile des Webinterfaces folgendes Kommando abgesetzt werden:<br />
<br />
set <CUL> hmPairSerial <10-stellige Seriennummer><br />
<br />
Die 10-stellige Seriennummer ist beim Empfängern idR. auf der Rückseite des Geräte aufgedruckt. Die Seriennummer fängt normalerweise mit Buchstaben an und endet mit Zahlen.<br />
<br />
Es gilt auch sicherzustellen, dass das zu pairende Gerät nicht bereits zuvor mit der Homematic Config Software gepairt wurde. Ist dies der Fall, so sollte das Pairing in der Homematic Config Software gelöscht und das Pairing in FHEM erneut durchgeführt werden.<br />
<br />
Beim Pairen ist, wie im normalen Betrieb auch, ein Mindestabstand (etwa 1-2 Meter) zwischen dem Sender der Zentrale (CUL, HMLAN etc.) einzuhalten, da die Funkempfänger sonst mit Übersteuerung reagieren und keine Kommunikation zustande kommt.<br />
Außerdem kann die Funklast beim Auslesen einer unfangreichen Konfiguration eines Gerätes bereits nach wenigen Versuchen das Limit der 1%-Regel erreichen. Sollte also scheinbar keine Kommunikation stattfinden können, ist auch zu prüfen, ob der Zentralensender sich deswegen temporär deaktiviert hat.<br />
<br />
= Gezieltes Pairing =<br />
Bei bereits bekanntem HM-Gerät kann man mit:<br />
<br />
set <Name HM-Gerät> pair<br />
<br />
das pairing überschreiben. Es funktioniert aber nur, wenn schon ein IO-Device eingetragen ist.<br />
<br />
= Pairing lösen =<br />
Das Pairing kann mit:<br />
<br />
set <Name HM-Gerät> unpair<br />
<br />
gelöst werden. Wichtig ist dabei, dass das IO-Device, das entpairt werden soll, mit der ursprünglich in das HM-Gerät geschriebenen HMID konfiguriert ist. <br />
<br />
Sollte man z.B. ein HomeMatic HM-CC-RT-DN Funk-Heizkörperthermostat und ein Fensterkontakt verbunden haben, so steht unter THERMOSTAT_WindowRec im Attribut peerIDs die ID des Fensterkontakts.<br />
Bei einem Defekt des Fensterkontakts sollte man wie im HM-CC-RT-DN beschrieben das unset durchführen. Hat man aber das Device Fensterkontakt gelöscht und das Pairing nicht durchgeführt, so kann man die Zuordnung im Heizkörperthermostat dennoch mit folgenden Befehl aufheben.<br />
<br />
set <Name HM-Gerät>_WindowRec peerBulk <peerID> unset<br />
<br />
<br />
[[Kategorie:HomeMatic Components]]<br />
[[Kategorie:HOWTOS]]</div>MGuhttp://wiki.fhem.de/w/index.php?title=HomeMatic_Devices_pairen&diff=23942HomeMatic Devices pairen2017-12-30T13:51:30Z<p>MGu: /* Devices pairen */ Benutzung der Taste korrigiert. Etwas einheitlicher deutsch.</p>
<hr />
<div>HomeMatic Geräte müssen mit dem für das HomeMatic-Protokoll eingesetzten IO-Device (zB [[CUL]], CUN, [[HomeMatic|Homematic IO's]]) ''[[Pairing (HomeMatic)|gepairt]]'' (deutsch: "gepaart") werden, damit sie von FHEM gesteuert oder ausgelesen werden können.<br />
<br />
<br />
Die Adresse eines HomeMatic Gerätes ist nicht frei einstellbar, sondern für jedes Gerät fest vorgegeben. Da die HM-Geräte über eine sehr komplexe Kanalstruktur verfügen, empfiehlt sich daher, die Geräte in FHEM per ''autocreate'' Funktion anlegen zu lassen, Eine nachträgliche Umbenennung oder manuelle Bearbeitung der erzeugten Konfigurationsdaten ist problemlos möglich.<br />
<br />
Zunächst mal muss man einen [[HomeMatic_Installieren|CUL/CUN/Homematic IO installieren]]. <br />
<br />
Einige Geräte werden mit aktivierter [[AES Encryption]] ausgeliefert (Meistens, aber nicht immer mit SEC im Namen). Das Anlernen an HM IO's funktioniert ohne Probleme, für alle CUL Derivate muss unbedingt der Hinweis im Artikel AES Encryption im Abschnitt I/O-Device <-> Gerät beachtet werden. '''Die dort beschriebene Installation sollte generell vorgenommen werden!'''<br />
<br />
Danach geht es hier weiter:<br />
<br />
= Grundlagen=<br />
Durch das Pairing wird ein HM-Gerät genau einem IO-Device (zB CUL) zugeordnet. Wenn ein Gerät mit dem IO-Device gepairt ist, kann es darüber gesteuert werden. <br />
<br />
Beim Pairing wird die HMID des IO-Device in das Gerät geschrieben. Das Pairing findet also im Wesentlichen im Gerät statt, nicht in FHEM selbst.<br />
<br />
Zu bemerken ist, dass ein IO-Device (zB CUL) standardmäßig die ID F11034 von FHEM erhält. Da viele HM-Geräte das IO-Device nur anhand der HMIDs erkennen, können alle in Reichweite der HM-Geräte befindlichen IO-Devices mit der in das HM-Gerät geschriebenen HMID das HM-Gerät steuern. Hinzu kommt, dass die ''autocreate'' Funktion die in Reichweite befindlichen HM-Geräte findet und automatisch einbindet. Nachbarn, die IO-Devices mit der gleichen HMID betreiben, können also HM-Geräte untereinander sehen und steuern!<br />
<br />
Es ist daher dringen zu empfehlen, die HMID vor dem Pairing der HM-Geräte mit: <br />
<br />
attr <CUL> hmId <6-stellige Hexadresse><br />
<br />
zu individualisieren. <br />
<br />
Gepairt wird nur das Device. Die Channels sind dem Device untergeordnet und somit implizit auch gepairt. <br />
<br />
'''Achtung:''' Ist ein Device gepairt werden Konfigurationsänderungen über die Zentrale (FHEM) vorgenommen. Man kann u.a. keine Kanäle mehr ''direkt'' peeren (verknüpfen). Stattdessen verwendet man Kommandos in FHEM. Siehe <u>[[Homematic_Peering_Beispiele|peeren]]</u><br />
<br />
= IO-Device in den Pairing-Modus versetzen =<br />
* CUL/CUN/HMLAN Konfigurator in den "Akzeptiere-Pairing-Requests-Modus" bringen:<br />
<br />
set <CUL> hmPairForSec 600<br />
<br />
600 bedeutet hier, dass das IO-Device 600 Sekunden, also 10 Minuten lang im Pairing-Modus ist.<br />
<br />
Bei aktivem Pairing-Modus gibt das IO-Device folgende ''Internals'' Variable zurück: <br />
<br />
hmPair 1<br />
<br />
Alternativ kann <br />
<br />
set <CUL> hmPairSerial <serial><br />
<br />
genutzt werden.<br />
<br />
= Devices pairen =<br />
<br />
Das Gerät wird in den Anlern- oder auch Konfigurationsmode versetzt. Es sendet hierzu eine entsprechende Nachricht an alle.<br />
<br />
Falls das Gerät einen separaten Anlernknopf hat, ist der normalerweise nur ganz kurz zu drücken. <br />
Danach beginnt die LED regelmäßig zu blinken. Eine Ausnahme sind Geräte, bei denen eine Taste im regulären Betrieb für andere Zwecke verwendet wird. Bei einem [[HM-CC-RT-DN Funk-Heizkörperthermostat|Heizkörperthermostat]] z.B. muss die Boost-Taste (Mitte) für mindestens 3 Sekunden gedrückt gehalten werden.<br />
<br />
{{Randnotiz|RNText=Hinweis: Das genaue Vorgehen ist vom Gerätetyp abhängig -> unbedingt das Handbuch genau lesen: Stichwort "anlernen".}}<br />
Hat das Gerät keinen separaten Anlernknopf, muss in der Regel eine Taste solange gedrückt werden, bis die LED anfängt regelmäßig zu blinken.<br />
<br />
Kommt der Anlernvorgang in Gang, wird dies durch ein wechselndes, schnelles Blinken signalisiert. Kommt kein Anlernvorgang zustande, blinkt die LED regelmäßig für einen bestimmten Zeitraum (ca. 20 sec). <br />
Ist das Gerät schon angelernt, werden bei batteriebetriebenen Geräten eventuell auch noch nicht übertragende Daten gesendet. Dabei blinkt die LED auch unregelmäßig.<br />
In FHEM werden nun:<br />
* alle fehlenden Devices und Channels angelegt<br />
* das Register <code>pairCentral</code> im Device gesetzt. <br />
<br />
Ein <code>save</code> danach sichert die neu angelernten Geräte in der Konfiguration.<br />
<br />
Hinweis: Auch mit <code>hmPairForSec</code> kann jeweils nur '''ein''' Gerät angelernt werden. Für mehrere Geräte den Vorgang bitte wiederholen.<br />
<br />
= Pairing verifizieren =<br />
Nur weil ein Gerät angelegt wurde, heißt das '''nicht''', dass es auch gepaired ist. In den Readings eines Devices muss stehen (list <name> oder im Webinterface):<br />
<br />
R_pairCentral 0xABCDEF<br />
<br />
ABCDEF steht dabei für die HMID des IO-Device (zB CUL). Wurde für das IO-Device kein attribute mit einer individuellen HMID gesetzt, sollte hier die Standard-ID F11034 stehen. Die führende 0x steht für den Hinweis auf eine HEX-Adresse. <br />
<br />
Ist das Pairing noch nicht abgeschlossen, kann man nach kurzer Pause den Befehl: <br />
<br />
set <HM-Gerät> getConfig <br />
<br />
absetzen, um zu prüfen, ob sich der Status zwischenzeitlich geändert hat. Wenn das Reading R_pairCentral nicht auftaucht oder der Wert mit set_ beginnt hat das Pairing '''nicht''' geklappt. Man kann entweder:<br />
* noch einmal probieren, ein getConfig auszulösen - vielleicht hat das Lesen nicht funktioniert<br />
* noch einmal pairen - das schadet nichts<br />
* die Anlerntaste / Configtaste / irgendeine Taste am Gerät (hängt vom konkreten Device ab) wiederholt drücken um die Datenübertragung anzustoßen.<br />
<br />
Alternativ kann man auch mit HMinfo einen Config check durchführen:<br />
<br />
define hm HMInfo<br />
get hm configCheck<br />
<br />
= Vorgehen bei Problemen =<br />
<br />
Wenn das Pairing nicht erfolgreich ist, das Gerät sich also nicht steuern lässt, ist es möglich, dass es schon bzw. noch mit einem anderen IO-Device gepairt ist. Dann das Gerät in den Auslieferungszustand bringen (siehe Handbuch, oft Knopf mindestens 5 Sekunden drücken, bis es blinkt, dann loslassen und nochmals 5 Sekunden drücken, bis es schneller blinkt) und danach erneut pairen. <br />
<br />
Alternativ kann das Pairing per Befehl gelöst werden. Siehe dazu unten. <br />
<br />
Wenn das zu pairende Geräte ein Empfänger ist, kann mit FHEM per Telnet oder in der Kommandozeile des Webinterfaces folgendes Kommando abgesetzt werden:<br />
<br />
set <CUL> hmPairSerial <10-stellige Seriennummer><br />
<br />
Die 10-stellige Seriennummer ist beim Empfängern idR. auf der Rückseite des Geräte aufgedruckt. Die Seriennummer fängt normalerweise mit Buchstaben an und endet mit Zahlen.<br />
<br />
Es gilt auch sicherzustellen, dass das zu pairende Gerät nicht bereits zuvor mit der Homematic Config Software gepairt wurde. Ist dies der Fall, so sollte das Pairing in der Homematic Config Software gelöscht und das Pairing in FHEM erneut durchgeführt werden.<br />
<br />
Beim Pairen ist, wie im normalen Betrieb auch, ein Mindestabstand (etwa 1-2 Meter) zwischen dem Sender der Zentrale (CUL, HMLAN etc.) einzuhalten, da die Funkempfänger sonst mit Übersteuerung reagieren und keine Kommunikation zustande kommt.<br />
Außerdem kann die Funklast beim Auslesen einer unfangreichen Konfiguration eines Gerätes bereits nach wenigen Versuchen das Limit der 1%-Regel erreichen. Sollte also scheinbar keine Kommunikation stattfinden können, ist auch zu prüfen, ob der Zentralensender sich deswegen temporär deaktiviert hat.<br />
<br />
= Gezieltes Pairing =<br />
Bei bereits bekanntem HM-Gerät kann man mit:<br />
<br />
set <Name HM-Gerät> pair<br />
<br />
das pairing überschreiben. Es funktioniert aber nur, wenn schon ein IO-Device eingetragen ist.<br />
<br />
= Pairing lösen =<br />
Das Pairing kann mit:<br />
<br />
set <Name HM-Gerät> unpair<br />
<br />
gelöst werden. Wichtig ist dabei, dass das IO-Device, das entpairt werden soll, mit der ursprünglich in das HM-Gerät geschriebenen HMID konfiguriert ist. <br />
<br />
Sollte man z.B. ein HomeMatic HM-CC-RT-DN Funk-Heizkörperthermostat und ein Fensterkontakt verbunden haben, so steht unter THERMOSTAT_WindowRec im Attribut peerIDs die ID des Fensterkontakts.<br />
Bei einem Defekt des Fensterkontakts sollte man wie im HM-CC-RT-DN beschrieben das unset durchführen. Hat man aber das Device Fensterkontakt gelöscht und das Pairing nicht durchgeführt, so kann man die Zuordnung im Heizkörperthermostat dennoch mit folgenden Befehl aufheben.<br />
<br />
set <Name HM-Gerät>_WindowRec peerBulk <peerID> unset<br />
<br />
<br />
[[Kategorie:HomeMatic Components|1toolsAndWork]]<br />
[[Kategorie:HOWTOS]]</div>MGuhttp://wiki.fhem.de/w/index.php?title=HM-CC-RT-DN_Funk-Heizk%C3%B6rperthermostat&diff=23941HM-CC-RT-DN Funk-Heizkörperthermostat2017-12-30T13:05:37Z<p>MGu: /* Betrieb mit FHEM */ Update als Link</p>
<hr />
<div>{{Infobox Hardware<br />
|Bild=HM-CC-RT-DN.jpg<br />
|Bildbeschreibung=HM-CC-RT-DN an Heizkörper montiert<br />
|HWProtocol=[[HomeMatic]]<br />
|HWType=[[HomeMatic Type Thermostat|thermostat]]<br />
|HWCategory=[[:Kategorie:Heizungsventile|Heizungsventile]]<br />
|HWComm=868 MHz<br />
|HWChannels=6<br />
|HWVoltage=3&nbsp;V<br />
|HWPowerConsumption=180&nbsp;mA<br />
|HWPoweredBy=2x LR6/Mignon/AA<br />
|HWSize=54x65x93 mm (BxHxT)<br />
|HWDeviceFHEM=[[CUL_HM]]<br />
<!-- |ModOwner= --><br />
|HWManufacturer=ELV / eQ-3<br />
}}<br />
<br />
'''HM-CC-RT-DN''' (häufig einfach '''RT''' genannt) ist ein Funk-''Heizkörperthermostate'' mit integriertem ''Stellantrieb''. Das Thermostat ist seit September&nbsp;2013 verfügbar und ist der Nachfolger des [[HM-CC-VD Funk-Stellantrieb]]s.<br />
<br />
== Vorbemerkungen ==<br />
: ''→ Einstellungen und Informationen, die alle [[HomeMatic]] Thermostate betreffen, sind unter [[HomeMatic Type Thermostat#Temperaturlisten|HomeMatic Type Thermostat]] zu finden.''<br />
<br />
Der HM-CC-RT-DN kann die Temperatur selbst messen (im Gegensatz zum [[HM-CC-VD Funk-Stellantrieb|Vorgänger]]) und verfügt über eine Fenster-Offen-Erkennung sowie eine Boost-Funktion. Der HM-CC-RT-DN ''kann'' von einem [[HM-TC-IT-WM-W-EU Funk-Wandthermostat AP]] gesteuert werden, das ist aber ''optional''.<br />
<br />
Das Gerät wird seit Anfang Oktober 2013 von FHEM unterstützt (siehe Diskussion im {{Link2Forum|Topic=14738|LinkText=Forum}}).<br />
<br />
Der HM-CC-RT-DN scheint das erste HomeMatic-Device zu sein, bei dem ein Update der Firmware auch vom Anwender durchgeführt werden kann. Ein Firmware-Update erfordert einen [[HM-CFG-USB_USB_Konfigurations-Adapter|USB Konfigurations-Adapter]] und eine auf der eQ-3 Webseite herunterladbare Firmwareupdate-Software. Weitere Details sind unter [[#Firmware Update|Firmware Update]] beschrieben.<br />
{{Hinweis|Die Solltemperaturen eines HM-CC-RT-DN lassen sich ''nicht'' durch einen [[HM-CC-TC Funk-Wandthermostat]] ''steuern''. Dieser kann nur die Ist-Temperatur an den HM-CC-RT-DN weitergeben, damit nicht die am HM-CC-RT-DN direkt gemessene Raumtemperatur zur Regelung verwendet wird.}}<br />
Mit einem HM-CC-RT-DN können maximal (neben der Zentrale/FHEM):<br />
* 7 HomeMatic Heizkörperthermostate<br />
* 8 HomeMatic Tür-Fensterkontakte / Fenster-Drehgriffkontakte<br />
* 8 Tastenpaare von HomeMatic Fernbedienungen bzw. Display-Wandtaster<br />
* 1 HomeMatic Innen-Temperatur-Sensor<br />
[[Peering (HomeMatic)|gepeert]] werden.<br />
<br />
{{Hinweis|Wird für Wartungs-/Umbaumaßnahmen das Wasser der Heizung abgelassen bzw. diese neubefüllt, sind alle Stellantriebe manuell dauerhaft auf '''on''' zu setzen: set <HM_Stellantrieb>_Clima controlManu on. Beim Einsatz eines Wandthermostaten ist der Wandthermostat entsprechend einzustellen.}}<br />
<br />
== Technische Daten ==<br />
* Betriebsspannung: 2 Stck. 1,5V LR6/Mignon/AA<br />
* Stromaufnahme: 180 mA max.<br />
* Abmessungen (B x H x T): 54 x 65 x 93 mm<br />
* Gewicht: 180 g (ohne Batterien)<br />
* Ventilanschluss: M30 x 1,5 mm<br />
<br />
Aktuelle Firmware: 1.4<br />
<br />
== Betrieb mit FHEM ==<br />
Der Funk-Heizkörperthermostat muss zuerst mit FHEM [[Pairing (HomeMatic)|gepairt]] werden. Stellen Sie sicher, dass FHEM aktuell ist ([[update]] durchführen)<br />
<br />
Das Pairing sollte wie in [[HomeMatic Devices pairen]] beschrieben durchgeführt werden <br />
<br />
=== Channels (Kanäle) ===<br />
==== Channel (Kanal) 01 _Weather ====<br />
<br />
Dieser Kanal dient zur Einspeisung der (gemessenen) ''Ist-Temperatur''. Als Sensor können zum Beispiel das [[HM-TC-IT-WM-W-EU Funk-Wandthermostat AP|HM-TC-IT-WM-W-EU Funk-Wandthermostat]] oder ein [[HM-WDS40-TH-I Funk-Temperatur-/Feuchtesensor innen (IT)|HM-WDS40-TH-I Funk-Temperatur-/Feuchtesensor]] dienen.<br />
<br />
Ein Temperatur-Sensor ''tempSensor'' kann mit dem ''_Weather''-Kanal wie folgt [[Peering (HomeMatic)|gepeert]] werden: <br />
<br />
set <HM-TC-IT-WM-W-EU>_Weather peerChan 0 <HM-CC-RT-DN>_Weather single set<br />
<br />
Beispiel:<br />
set EG_Buero_WANDTHERMOSTAT_Weather peerChan 0 EG_Buero_THERMOSTAT_Weather single set<br />
<br />
ACHTUNG: Das Wandthermostat sowie das Thermostat Ventil (Beispiel "EG_Buero_WANDTHERMOSTAT" und EG_Buero_THERMOSTAT) werden vorher in FHEM den Status "CMDs_done" anzeigen.<br />
Beim peerChan wird dann bei beiden "CMDs_pending" stehen. Wobei das Wandthermostat sehr schnell wieder auf CMDs_done zurück springt.<br />
Allerdings ist dingend darauf zu achten, dass das Thermostat Ventil auch wieder auf "CMDs_done" wechselt, bevor man den nächsten Befehl absendet.<br />
Das Heizkörper Ventile kann unter umständen 3 bis 5 min benötigen bis wieder "CMDs_done" steht. Evtl. kann man dies durch die BOOST Taste beschleunigen. Da das Ventil etwa alle 3 min aufwacht, prüft und Daten sendet / empfängt. Sollte man mit dem Befehlen weiter gemacht haben, so kann es zu Problemen führen, das einer nicht mehr mit dem Pending aufhört. In dem Fall empfiehlt es sich beide Devices von Fhem abzumelden und auf Werkseinstellung zu resetten. <br />
<br />
Zum Test haucht man das Wandthermostat an oder hält es einige Zeit in der Hand bis die Temperatur steigt, nach etwa 3 Minuten sollte man auch am Thermostat Ventil ein Temperaturanstieg sehen.<br />
<br />
==== Channel (Kanal) 02 _Climate ====<br />
Dieser Kanal erlaubt es dem [[HM-TC-IT-WM-W-EU Funk-Wandthermostat AP|HM-TC-IT-WM-W-EU Funk-Wandthermostat]] den HM-CC-RT-DN zu steuern. Dazu müssen die beiden Geräte gepeert werden:<br />
<br />
set <HM-TC-IT-WM-W-EU>_Climate peerChan 0 <HM-CC-RT-DN>_Climate single set<br />
<br />
==== Channel (Kanal) 03 _WindowRec ====<br />
Mit diesem Kanal können Fensterkontakte ([[HM-SEC-SC Tür-Fensterkontakt|HM-SEC-SC]] und [[HM-Sec-RHS Funk-Fenster-Drehgriffkontakt|HM-SEC-RHS]]) ihren Fensterstatus (geöffnet / gekippt) an ein oder mehrere Thermostate senden. Die Thermostate stellen anschließend die entsprechende (konfigurierbare) Temperatur ein. Der Temperaturwert kann je Fenster-Sensor unterschiedlich definiert werden. Sind mehrere Fenster gleichzeitig geöffnet, so wird der Thermostat auf die Temperatur des Sensors mit dem geringsten Temperaturwert eingestellt. <br />
Ferner wird empfohlen, bei Einsatz von externen Sensoren, die interne „Fenster auf Erkennung“ zu deaktivieren (weitere Details sind im [[HM-CC-RT-DN Funk-Heizkörperthermostat#Channel .28Kanal.29 04 _Clima|Channel (Kanal) 04 _Clima]] beschrieben).<br />
<br />
Der Befehl zum Peeren lautet, wobei <fensterSensor> die FHEM-Kanalbezeichnung für den Fensterkontakt ist und <rt_WindowRec> die Kanalbezeichnung für den entsprechenden Kanal des Heizkörperthermostates:<br />
set <fensterSensor> peerChan 0 <HM-CC-RT-DN>_WindowRec single set<br />
<br />
Zum Löschen (=unpeeren) dieser Kopplung:<br />
set <fensterSensor> peerChan 0 <HM-CC-RT-DN>_WindowRec single unset<br />
<br />
'''Achtung''': Der Peer-(Lösch)Vorgang muss erst am Fensterkontakt durch Drücken der Anlerntaste ausgelöst werden, und zwar auch dann, wenn der Fensterkontakt schon vorher mit FHEM gepairt wurde. Dann kann der oben genannte Befehl in FHEM abgesetzt werden. Wichtig scheint auch, dass der Fensterkontakt geschlossen ist wenn man die Anlerntaste drückt.<br />
<br />
Der Befehl zur Temperatureinstellung des Heizkörperthermostaten für den Zustand "Fenster offen" lautet, wobei <fensterSensor> die FHEM-Kanalbezeichnung für den Fensterkontakt ist und <rt_WindowRec> die Kanalbezeichnung für den entsprechenden Kanal des Heizkörperthermostates, sowie <Temp> die einzustellende Temperatur (ganzzahliger Wert):<br />
set <HM-CC-RT-DN>_WindowRec regSet winOpnTemp <Temp> <fensterSensor><br />
<br />
==== Channel (Kanal) 04 _Clima ====<br />
Dieser Kanal dient zum Einstellen der Betriebsparameter, auch [[#Temperaturlisten|Temperaturlisten]] sind hierauf zu übertragen.<br />
Mit dem Modul [[Weekprofile|Wochenplan / Weekprofile]] können die Wochenpläne komfortabel in FHEM erstellt und an die Thermostate übertragen werden.<br />
<br />
{{Hinweis|In älteren Versionen von FHEM wurde dieser Kanal durch ''autocreate'' als <code>_ClimRT_tr</code> angelegt. Der Hersteller hat hier offenbar die internen Bezeichnungen geändert, denn beim Vorläufernmodell HM-CC-TC mussten Temperaturlisten auf den Kanal ''Climate'' übertragen werden.}}<br />
<br />
Die maximale Öffnung des Ventils kann mittels folgendem Befehl eingestellt werden (hier auf 80 %):<br />
set <HM-CC-RT-DN>_Clima regSet valveMaxPos 80<br />
<br />
Die interne "Fenster-auf"-Erkennung kann man wie folgt abschalten:<br />
set <HM-CC-RT-DN>_Clima regSet winOpnMode off<br />
<br />
==== Channel (Kanal) 05 _ClimaTeam ====<br />
Dieser Kanal erlaubt es mehrere HM-CC-RT-DN zu einem "Team" zu gruppieren. Ein Mitglied des Teams meldet<br />
* Änderungen der Temperatur am Handrad<br />
* Einschalten des Boost-Modus am Taster<br />
an seine "Teamkollegen" weiter. Folgende Änderungen werden '''nicht''' weitergegeben:<br />
* Status der Fensterkontakte<br />
* Temperaturlisten/Wochenplan und daraus folgende Änderungen<br />
* Änderungen durch Fernbedienungen<br />
* Änderungen durch eine HomeMatic-Zentrale<br />
<br />
Befehl zum Peeren, wobei ''<HM-CC-RT-DN#1>_ClimaTeam'', ''<HM-CC-RT-DN#2>_ClimaTeam'', ..., ''<HM-CC-RT-DN#8>_ClimaTeam'' die Kanalbezeichnungen der jeweiligen ClimaTeam-Kanäle sind:<br />
set <HM-CC-RT-DN#1>_ClimaTeam peerChan 0 <HM-CC-RT-DN#2>_ClimaTeam single<br />
set <HM-CC-RT-DN#1>_ClimaTeam peerChan 0 <HM-CC-RT-DN#3>_ClimaTeam single<br />
set <HM-CC-RT-DN#2>_ClimaTeam peerChan 0 <HM-CC-RT-DN#3>_ClimaTeam single<br />
...<br />
<br />
==== Channel (Kanal) 06 _remote ====<br />
Dieser Kanal kann an eine Fernbedienung gekoppelt werden. Per Tastendruck kann man einen bestimmten Mode und/oder eine bestimmte Temperatur wählen. Dabei kann die Reaktion auf einen langen oder kurzen Tastendruck gesondert eingestellt werden.<br />
<br />
Der Befehl zum peeren lautet, wobei <button> die Kanalbezeichnung der Fernbedienung und <rt-remote> die Kanalbezeichnung des Heizkörperthermostates ist:<br />
set <button> peerChan 0 <HM-CC-RT-DN>_remote single<br />
<br />
=== Betriebsmodus Auto, Manu, Party (Urlaub) ===<br />
<br />
Der HM-CC-RT-DN verfügt über drei Betriebsmodus: Auto, Manu (Manuell) und Party (Urlaub).<br />
<br />
==== Modus Auto ====<br />
Das Gerät arbeitet gemäß des gespeicherten Wochenprogramms. Manuelle Änderungen sind möglich, werden aber beim nächsten Schaltpunkt überschrieben.<br />
<br />
==== Modus Manu ====<br />
Die Temperatur wird manuell eingestellt, das Wochenprogramm wird nicht abgearbeitet.<br />
<br />
==== Modus Party (Urlaub) ====<br />
Die eingestellte Temperatur gilt bis zu einem gegebenen Endzeitpunkt, anschließend wechselt das Thermostat in den ''Auto''-Modus. So kann beispielsweise bei Abwesenheit ein niedrigeres Temperaturprofil eingestellt werden ohne dass die Temperaturlisten verändert werden müssen.<br />
<br />
set <HM-CC-RT-DN>_Clima controlParty 16 06.12.13 16:30 09.12.13 05:00<br />
<br />
Dadurch wird <br />
* von 06.12.2013, 16:30 Uhr<br />
* bis 09.12.2013, 05:00 Uhr <br />
* die gewünschte Raumtemperatur auf 16 °C eingestellt.<br />
<br />
{{Hinweis|<br />
* Der Befehl muss auf dem Kanal 4 ''(_Clima)'' erfolgen.<br />
* Es werden nur Uhrzeiten zu jeder vollen oder halben Stunde angenommen (Minuten also 00 oder 30).}}<br />
<br />
Mit der folgenden Funktion <code>Urlaub()</code> kann man eine ganze Wohnung (also mehrere RTs) mit nur einem Befehl in den Party-Modus versetzen. Im Beispiel werden zwei Heizkörper ("Treppenhaus" und "Kammer") angesteuert.<br />
<br />
Zu beachten sind folgende Dinge:<br />
# Aktuelle Dateien (z.B. <code>10_CUL_HM</code>) verwenden!<br />
# Bei dem ''controlParty''-Befehl ''kein'' Komma zwischen den Parametern.<br />
# Bei der Funktion die Parameterübergabe definieren <code>($$$$$)</code><br />
<br />
'''Aufruf:'''<br />
:<code>{Urlaub ("16", "06.12.13", "16:30", "09.12.13" ,"05:00")}</code><br />
<br />
'''Funktion:'''<br />
<syntaxhighlight lang=perl><br />
my $Urlaub;<br />
sub<br />
Urlaub($$$$$)<br />
{<br />
my ($temp, $startDate, $startTime, $endDate, $endTime) = @_;<br />
<br />
# HM-CC-RT-DN akzeptiert nur Zeiten, die auf Minute 00 oder 30 enden.<br />
# Daher $startTime und $endTime abrunden<br />
$startTime =~ s/\:[0-2].$/:00/;<br />
$startTime =~ s/\:[3-5].$/:30/;<br />
$endTime =~ s/\:[0-2].$/:00/;<br />
$endTime =~ s/\:[3-5].$/:30/;<br />
<br />
# controlParty bei jedem HM-CC-RT-DN setzen.<br />
for my $rt (qw(Kammer Treppenhaus)) {<br />
fhem ("set $rt controlParty $temp $startDate $startTime $endDate $endTime");<br />
}<br />
}<br />
</syntaxhighlight><br />
<br />
=== Tastensperre ===<br />
<br />
Um zu verhindern, dass der Modus oder die Temperatur per Tasten bzw. Drehrad am HM-CC-RT-DN verändert wird, kann eine Tastensperre gesetzt werden. Dies erfolgt mittels des Befehls:<br />
<br />
set <HM-CC-RT-DN> regSet btnLock on<br />
<br />
Rückgängig machen geht per:<br />
<br />
set <HM-CC-RT-DN> regSet btnLock off<br />
<br />
Diese Tastensperre kann man aber am HM-CC-RT-DN durch eine Tastenkombination wieder zurücksetzen. Um sie nur per FHEM rücksetzen zu können, muss<br />
<br />
set <HM-CC-RT-DN> regSet globalBtnLock on<br />
<br />
eingegeben werden. Rückgängig geht wieder per:<br />
<br />
set <HM-CC-RT-DN> regSet globalBtnLock off<br />
<br />
Es gibt auch eine Tastensperre die nur das Umschalten des Modus (Auto, Manuell, Urlaub) am Gerät verhindert. Diese wird mit<br />
<br />
set <HM-CC-RT-DN> regSet modusBtnLock on<br />
<br />
eingeschaltet. Abschalten geht mit:<br />
<br />
set <HM-CC-RT-DN> regSet modusBtnLock off<br />
<br />
=== Burst-Modus ===<br />
Das ist ein '''Übertragungs'''modus für Nachrichten zwischen HM-Geräten und der Zentrale. Der RT erwacht alle 2,5 Minuten und dann überträgt die Zentrale die Kommandos. Wenn man einen Fensterkontakt oder eine Fernsteuerung nutzt, muss der RT sofort reagieren - dann muss man den Burst ''enablen''. Der RT kann in diesem Fall sofort aufgeweckt werden und bearbeitet die Anforderung (Request). Das kann man auch von der Zentrale aus nutzen (so man möchte). Das ist der '''Vorteil''' des eingeschalteten Burst-Modus.<br />
<br />
'''Nachteil:''' Der Burst-Modus benötigt mehr Leistung, das heißt die Batterien müssen häufiger gewechselt werden: Der RT muss den Receiver ständig empfangsbereit halten. Außerdem wachen bei jedem Burst wachen ''alle'' Burst-Empfänger auf – egal an wen die Kommunikation gerichtet war.<br />
<br />
'''Burst – wie es funktioniert'''<br />
<br />
Schickt ein Sender eine burst Sequenz, wachen alle burst-Empfänger auf und prüfen die Message. <br />
Wenn sie betroffen sind bleiben sie eine Zeit lang wach, ansonsten schlafen sie wieder ein. <br />
Man beachte also, dass Senden eines Burst Energie in ALLEN burst-Empfängern verbraucht, egal ob sie angesprochen sind.<br />
<br />
'''HMLAN und burst'''<br />
<br />
[[HMLAN]] hat ein Sendebudget das über eine Stunde berechnet wird. Burst belastet diese Konto deutlich - so können nicht mehr als 100 bursts /h gesendet werden - dann geht HMLAN in overload Wenn zusätzliche Nachrichten gesendet werden sind es entsprechend weniger. <br />
Es ist als nicht vorteilhaft, unnötig bursts zu senden.<br />
<br />
'''Burst devices'''<br />
<br />
Es gibt Devices, die immer auf burst reagieren und solche bei denen es abgeschaltet werden kann. So reagiert ein Rauchmelder immer auf Burst damit er seine Team-Kollegen hören kann. <br />
Ein TC oder RT hingegen hat diese Funktion abschaltbar. 'Per default ist dies ausgeschaltet um Batterie zu sparen'. Wenn ein VD gesteuert wird ist der TC ja selbst wach. Wird er aber mit einem Fensterkontakt gekoppelt muss es eingeschaltet werden – sonst verpasst er die Nachricht. <br />
<br />
'''ConditionalBurst devices'''<br />
<br />
Devices mit abschaltbarem Burst wie z.B. der ''HM-CC-RT-DN'' haben ein Register, ''burstRx'', mit dem das burst-Erwachen eingestellt werden kann. <br />
Sendern, die einen burst-Aktor erwecken sollen, muss man sagen, welcher Peer Burst benötigt. Hier kann ggf. das Register ''peerNeedsBurst'' nach dem Peeren gesetzt werden. FHEM versucht dies automatisch beim Peeren zu erledigen. Siehe [[HomeMatic HMInfo|HMinfo]] Befehl ''models'' um herauszufinden, welche Devices welchen Modus unterstützen.<br />
<br />
'''Attribut burstAccess''' <br />
<br />
Devices, die abschaltbaren burst haben kann man ein attribut bustAccess 1_auto setzen. Es wird beim Abschicken eines Kommandos versucht, das Device mit burst zu wecken. Sollte es nicht funktionieren wird gewartet, bis das Device aufwacht (meist reagieren solche Devices auch auf wakeup). Das Setzen des Attributs ist angenehm – es werden aber ggf. viele bursts gesendet.<br />
<br />
'''Kommando burstXmit'''<br />
<br />
Mit diesem Kommando, das bei Devices mit contitional-Burst zu Verfügung steht, wird der burst gezielt von User angestossen.<br />
<br />
Der User schickt erst seine Kommandos an das device. Die Kommandos werden im Command-stack gesammelt. <br />
<br />
Dann sendet der User ein set burstXmit.<br />
<br />
Es passiert das gleiche wie bei burstAccess.<br />
<br />
FHEM versucht mittels burst zu wecken und sendet bei Erfolg die Messages aus dem Kommandostack. <br />
<br />
Im Gegensatz zu burstAccess ist burstXmit gezielt einsetzbar und kann sparsamer verwendet werden.<br />
<br />
''' FHEM und burst devices'''<br />
<br />
FHEM sendet eine burst automatisch mit Kommandos zu Devices, die nur burst unterstützen.<br />
<br />
'''So aktiviert man den burst-Betrieb am HM-CC-RT-DN'''<br />
<br />
''Burst Mode einschalten'' (der Kanal 4 des Device WZ1 heisst hier WZ1_4)<br />
:<code>set WZ1_4 regSet burstRx on </code><br />
prüfen mit:<br />
:<code>get WZ1_4 reg burstRx </code><br />
''Nun in FHEM den Burst mode einschalten (sofern nicht burstXmit verwendet wird)''<br />
:<code>attr WZ1 burstAccess 1_auto</code><br />
<br />
Hinweis: Das Attribut im Device und nicht im Kanal setzen, ansonsten gibt es eine Fehlermeldung.<br />
<br />
=== Temperaturlisten ===<br />
Die Temperaturlisten des HM-CC-RT-DN werden identisch mit denen anderer HomeMatic Thermostate verwaltet (siehe [[HomeMatic Type Thermostat#Temperaturlisten|HomeMatic Type Thermostat]]). Beim HM-CC-RT-DN ist der Kanal 4 (_Clima) für die Temperaturlisten zuständig.<br />
<br />
==FHEM-Log==<br />
In den folgenden Logs heißt Kanal 4 noch "_ClimRT_tr". Inzwischen würde man dort "_Clima" sehen.<br />
<br />
=== Device-Log ===<br />
2013.10.10 20:03:24 3: CUL_HM Unknown device CUL_HM_HM_CC_RT_DN_2212BC, please define it<br />
2013.10.10 20:03:24 2: autocreate: define CUL_HM_HM_CC_RT_DN_2212BC CUL_HM 2212BC A1A0184002212BC0000001000954B4551303531303031375900FFFF<br />
2013.10.10 20:03:24 3: Device CUL_HM_HM_CC_RT_DN_2212BC added to ActionDetector with 000:10 time<br />
2013.10.10 20:03:24 3: CUL_HM pair: CUL_HM_HM_CC_RT_DN_2212BC thermostat, model HM-CC-RT-DN serialNr KEQ0510017<br />
2013.10.10 20:03:24 3: LANCUL pairing (hmPairForSec) not enabled<br />
2013.10.10 20:03:24 2: autocreate: define FileLog_CUL_HM_HM_CC_RT_DN_2212BC FileLog /usr/local/FHEM/var/log/CUL_HM_HM_CC_RT_DN_2212BC-%Y.log CUL_HM_HM_CC_RT_DN_2212BC<br />
2013.10.10 20:03:24 3: Device Heizung_Wohnzimmer added to ActionDetector with 000:10 time<br />
2013.10.10 20:03:24 3: CUL_HM pair: Heizung_Wohnzimmer thermostat, model HM-CC-TC serialNr JEQ0044286<br />
2013.10.10 20:03:24 3: Device CUL_HM_HM_CC_RT_DN_2212BC added to ActionDetector with 000:10 time<br />
2013.10.10 20:03:24 3: CUL_HM pair: CUL_HM_HM_CC_RT_DN_2212BC thermostat, model HM-CC-RT-DN serialNr KEQ0510017<br />
2013.10.10 20:03:25 2: autocreate: define CUL_HM_HM_CC_RT_DN_2212BC_Weather CUL_HM 2212BC01<br />
2013.10.10 20:03:25 2: autocreate: define FileLog_CUL_HM_HM_CC_RT_DN_2212BC_Weather FileLog /usr/local/FHEM/var/log/CUL_HM_HM_CC_RT_DN_2212BC_Weather-%Y.log CUL_HM_HM_CC_RT_DN_2212BC_Weather<br />
2013.10.10 20:03:25 2: autocreate: define FileLog_CUL_HM_HM_CC_RT_DN_2212BC_Weather FileLog /usr/local/FHEM/var/log/CUL_HM_HM_CC_RT_DN_2212BC_Weather-%Y.log CUL_HM_HM_CC_RT_DN_2212BC_Weather<br />
2013.10.10 20:03:26 2: autocreate: define CUL_HM_HM_CC_RT_DN_2212BC_Climate CUL_HM 2212BC02<br />
2013.10.10 20:03:26 2: autocreate: define FileLog_CUL_HM_HM_CC_RT_DN_2212BC_Climate FileLog /usr/local/FHEM/var/log/CUL_HM_HM_CC_RT_DN_2212BC_Climate-%Y.log CUL_HM_HM_CC_RT_DN_2212BC_Climate<br />
2013.10.10 20:03:26 2: autocreate: define FileLog_CUL_HM_HM_CC_RT_DN_2212BC_Climate FileLog /usr/local/FHEM/var/log/CUL_HM_HM_CC_RT_DN_2212BC_Climate-%Y.log CUL_HM_HM_CC_RT_DN_2212BC_Climate<br />
2013.10.10 20:03:27 2: autocreate: define CUL_HM_HM_CC_RT_DN_2212BC_WindowRec CUL_HM 2212BC03<br />
2013.10.10 20:03:27 2: autocreate: define FileLog_CUL_HM_HM_CC_RT_DN_2212BC_WindowRec FileLog /usr/local/FHEM/var/log/CUL_HM_HM_CC_RT_DN_2212BC_WindowRec-%Y.log CUL_HM_HM_CC_RT_DN_2212BC_WindowRec<br />
2013.10.10 20:03:27 2: autocreate: define FileLog_CUL_HM_HM_CC_RT_DN_2212BC_WindowRec FileLog /usr/local/FHEM/var/log/CUL_HM_HM_CC_RT_DN_2212BC_WindowRec-%Y.log CUL_HM_HM_CC_RT_DN_2212BC_WindowRec<br />
2013.10.10 20:03:28 2: autocreate: define CUL_HM_HM_CC_RT_DN_2212BC_ClimRT_tr CUL_HM 2212BC04<br />
2013.10.10 20:03:28 2: autocreate: define FileLog_CUL_HM_HM_CC_RT_DN_2212BC_ClimRT_tr FileLog /usr/local/FHEM/var/log/CUL_HM_HM_CC_RT_DN_2212BC_ClimRT_tr-%Y.log CUL_HM_HM_CC_RT_DN_2212BC_ClimRT_tr<br />
2013.10.10 20:03:28 2: autocreate: define FileLog_CUL_HM_HM_CC_RT_DN_2212BC_ClimRT_tr FileLog /usr/local/FHEM/var/log/CUL_HM_HM_CC_RT_DN_2212BC_ClimRT_tr-%Y.log CUL_HM_HM_CC_RT_DN_2212BC_ClimRT_tr<br />
2013.10.10 20:03:29 2: autocreate: define CUL_HM_HM_CC_RT_DN_2212BC_ClimaTeam CUL_HM 2212BC05<br />
2013.10.10 20:03:29 2: autocreate: define FileLog_CUL_HM_HM_CC_RT_DN_2212BC_ClimaTeam FileLog /usr/local/FHEM/var/log/CUL_HM_HM_CC_RT_DN_2212BC_ClimaTeam-%Y.log CUL_HM_HM_CC_RT_DN_2212BC_ClimaTeam<br />
2013.10.10 20:03:29 2: autocreate: define FileLog_CUL_HM_HM_CC_RT_DN_2212BC_ClimaTeam FileLog /usr/local/FHEM/var/log/CUL_HM_HM_CC_RT_DN_2212BC_ClimaTeam-%Y.log CUL_HM_HM_CC_RT_DN_2212BC_ClimaTeam<br />
2013.10.10 20:03:30 2: autocreate: define CUL_HM_HM_CC_RT_DN_2212BC_remote CUL_HM 2212BC06<br />
2013.10.10 20:03:30 2: autocreate: define FileLog_CUL_HM_HM_CC_RT_DN_2212BC_remote FileLog /usr/local/FHEM/var/log/CUL_HM_HM_CC_RT_DN_2212BC_remote-%Y.log CUL_HM_HM_CC_RT_DN_2212BC_remote<br />
2013.10.10 20:03:30 2: autocreate: define FileLog_CUL_HM_HM_CC_RT_DN_2212BC_remote FileLog /usr/local/FHEM/var/log/CUL_HM_HM_CC_RT_DN_2212BC_remote-%Y.log CUL_HM_HM_CC_RT_DN_2212BC_remote<br />
2013.10.10 20:03:35 3: Device CUL_HM_HM_CC_RT_DN_2212BC added to ActionDetector with 000:10 time<br />
2013.10.10 20:03:40 2: CUL_HM set CUL_HM_HM_CC_RT_DN_2212BC getSerial<br />
2013.10.10 20:03:40 2: CUL_HM set CUL_HM_HM_CC_RT_DN_2212BC getConfig<br />
2013.10.10 20:03:54 3: Device CUL_HM_HM_CC_RT_DN_2212BC added to ActionDetector with 000:10 time<br />
<br />
=== Event monitor ===<br />
2013-10-12 12:05:35.610 CUL_HM CUL_HM_HM_CC_RT_DN_2212BC_ClimRT_tr motorErr: ok<br />
2013-10-12 12:05:35.610 CUL_HM CUL_HM_HM_CC_RT_DN_2212BC_ClimRT_tr measured-temp: 18.4<br />
2013-10-12 12:05:35.610 CUL_HM CUL_HM_HM_CC_RT_DN_2212BC_ClimRT_tr desired-temp: 18<br />
2013-10-12 12:05:35.610 CUL_HM CUL_HM_HM_CC_RT_DN_2212BC_ClimRT_tr ValvePosition: 3 %<br />
2013-10-12 12:05:35.610 CUL_HM CUL_HM_HM_CC_RT_DN_2212BC_ClimRT_tr mode: manu<br />
2013-10-12 12:05:35.610 CUL_HM CUL_HM_HM_CC_RT_DN_2212BC_ClimRT_tr unknown0: 24<br />
2013-10-12 12:05:35.610 CUL_HM CUL_HM_HM_CC_RT_DN_2212BC_ClimRT_tr T: 18.4 desired: 18 valve: 3 %<br />
2013-10-12 12:05:35.646 CUL_HM CUL_HM_HM_CC_RT_DN_2212BC battery: ok<br />
2013-10-12 12:05:35.646 CUL_HM CUL_HM_HM_CC_RT_DN_2212BC batteryLevel: 3.1 V<br />
2013-10-12 12:05:35.646 CUL_HM CUL_HM_HM_CC_RT_DN_2212BC measured-temp: 18.4<br />
2013-10-12 12:05:35.646 CUL_HM CUL_HM_HM_CC_RT_DN_2212BC desired-temp: 18<br />
2013-10-12 12:05:35.646 CUL_HM CUL_HM_HM_CC_RT_DN_2212BC actuator: 3 %<br />
<br />
== Firmware Update ==<br />
Seit 24.10.2014 gibt es für den HM-CC-RT-DN die neue Firmware Version 1.4. Diese kann von der eQ-3 Webseite heruntergeladen werden. Genauere Informationen gibt es unter [[HomeMatic Firmware Update]].<br />
<br />
=== HM-CC-RT-DN spezifische Update Informationen ===<br />
Durch gleichzeitiges Drücken der "Auto-/Manu"-Taste und der "Comfort-/Eco"-Taste am HM-CC-RT-DN während man die Batterien wieder einlegt wird der updatemodus gestartet. Während des Updates steht "FUP" im Display. Nach erfolgreichem Update erscheint "Ins" im Display und es muss eine erneute Adaptierfahrt durch drücken der Boost-Taste ausgelöst werden. Anschließend sollte der HM-CC-RT-DN wieder normal funktionieren. Die eingestellten Parameter und das Pairing mit FHEM gehen beim Update nicht verloren. Sollte das Update fehlschlagen, erscheint "Err" bzw. "CrC" im Display.<br />
<br />
Normalerweise sollte dann durch erneutes starten der Prozedur am PC und HM-CC-RT-DN das ganze erneut durchführbar sein.<br />
<br />
Es gibt einige Readings, die nicht durch ein einfaches ''getConfig'' aktualisisert werden, z.B. "battery"(nicht batteryLevel). Um diese Readings zu bekommen, ist ein <br />
:<code>set Device_Channel04 controlMode auto </code><br />
notwendig. Daraufhin werden die Readings übertragen/aktualisiert.<br />
<br />
== Simulation von Fensterkontakten und externen Temperatursensoren ==<br />
grober Ablauf:<br />
* erstellen ein virtuelles Device<br />
* erstelle dazu einen virtuellen Kanal<br />
* peeren den Kanal mit dem RT (als fenster-kontakt oder als remote, wen du willst)<br />
* sende ein postEvent<br />
<br />
=== Fensterkontakte ===<br />
''Entnommen aus diesem {{Link2Forum|Topic=31078|Message=236245|LinkText=Forenbeitrag}}''<br />
define virSC CUL_HM 221133<br />
attr virSC autoReadReg 4_reqStatus<br />
attr virSC expert 2_full<br />
attr virSC model virtual_1<br />
attr virSC peerIDs <br />
attr virSC subType virtual<br />
attr virSC webCmd press short:press long<br />
<br />
define virtualKitchenDoor CUL_HM 22113301<br />
attr virtualKitchenDoor dummy 1<br />
attr virtualKitchenDoor expert 1<br />
attr virtualKitchenDoor group Virtual<br />
attr virtualKitchenDoor model virtual_1<br />
attr virtualKitchenDoor webCmd postEvent open:postEvent closed <br />
<br />
Anschließend peeren und Temperatur festlegen mit:<br />
set virtualKitchenDoor peerChan 0 <Thermostat_Window_Rec> single set<br />
set <Thermostat_Window_Rec> regSet winOpnTemp 5 virtualKitchenDoor<br />
<br />
Ggf noch interne "Fenster-auf" Erkennung abschalten<br />
set <HM-CC-RT-DN>_Clima regSet winOpnMode off<br />
<br />
Die virtuelle Tür wird dann entsprechend über ein Notify getriggert:<br />
define notify_virtualKitchenDoor notify (Fensterkontakt_1|Fensterkontakt_2) {if(Value("Fensterkontakt") eq "open" && Value("Fensterkontakt_2") eq "open"){fhem("set virtualKitchenDoor postEvent open")}else{fhem("set virtualKitchenDoor postEvent closed")}}<br />
<br />
=== Temperatursensoren ===<br />
''Entnommen aus diesem {{Link2Forum|Topic=19686|Message=233788|LinkText=Forenbeitrag}}''<br />
<br />
1. Virtuelles HomeMatic Device mit _deiner_ HM Id definieren:<br />
define wz_vT CUL_HM <hmId><br />
<br />
2. Dem Device einen virtuellen Kanal (Default ist ein virtueller Button) hinzufügen:<br />
set wz_vT virtual 1<br />
<br />
3. Es ist kein virtueller Button sondern ein virtueller Temperatursensor - darum rename:<br />
rename wz_vT_Btn1 wz_vT_Sensor1<br />
<br />
4. Virtuellen Peer Sensor mit dem Weather Channel des RT-DN peeren:<br />
set wz_vT_Sensor1 peerChan 0 <RT_DN>_Weather single<br />
<br />
5. Peering kontrollieren (Voraussetzung: Device ''hm'' vom Typ [[HomeMatic HMInfo|HMinfo]] existiert):<br />
:<code>set hm peerXref</code><br />
Beispiel-Ausgabe:<br />
peerXref done: <br />
x-ref list <br />
wz_Thermostat_Weather => wz_vT_Sensor1 <br />
wz_vT_Sensor1 => wz_Thermostat_Weather<br />
<br />
6. Gemessene Temperatur vom z.B. 1-Wire DS1820 dem virtuellen HM Sensor übergeben. Z.B. alle zwei Minuten per at:<br />
define at_wz_vT at +*00:02 { my $T=(ReadingsVal("<DS1820B>","temperature",20.0));; fhem "set wz_vT_Sensor1 virtTemp $T" }<br />
<br />
Fertig.<br />
<br />
Sollte es Probleme geben, dass der RT des Öfteren wieder auf seine eigenen Messwerte wechselt, so sollte das Attr cyclicMsgOffset im Virtuellen Kanal beachtet werden. Näheres dazu ist ca. ab {{Link2Forum|Topic=45735|Message=572806|LinkText=hier}} im Forum zu finden.<br />
<br />
== Bekannte Probleme ==<br />
=== TempList: Bad format ... ===<br />
Wenn Sie beim Setzen einer Temperaturliste nach dem o.a. Schema ("SetTempList...") die Meldung<br />
<br />
Bad format, use HH:MM TEMP ......<br />
<br />
erhalten, sollten Sie zunächst ein [[update]] von FHEM durchführen.<br />
<br />
=== Der Thermostat heizt über die Solltemperatur hinaus ===<br />
In der Regel ist das ein ganz normales Verhalten, wenn der Thermostat nicht mit einem externen Temperaturfühler oder einem Wandthermostat gepeert ist. In dem Fall muss sich der Thermostat auf den eingebauten Temperatursensor verlassen, der sehr nahe an der Heizung selbst sitzt. Dadurch ist die gemessene Temperatur höher, als sie z.B. in der Raummitte wäre. Der Hersteller hat hier einen mehr oder weniger intelligenten Algorithmus eingebaut, um diesen Effekt zu kompensieren. Das sieht dann so aus, als ob der Thermostat nicht richtig regelt.<br />
Dieses Verhalten kann man im Prinzip nur verhindern, indem man einen externen Temperatursensor oder einen Wandthermostat peert. Wie das geht ist hier beschrieben: [[#Channel (Kanal) 01 _Weather]]. Normalerweise regelt der Thermostat dann genau auf die Solltemperatur. <br />
Ansonsten sollte man sich auch fragen, ob das gezeigte Verhalten vielleicht doch gut genug ist. Dazu platziert man irgendein Thermometer möglichst in der Mitte des Raums und beobachtet den Temperaturverlauf eine Weile. Wenn man dann noch eine Abweichung feststellt, kann es sinnvoll sein, diese mittels des Registers R-tempOffset zu beheben.<br />
<br />
== Links ==<br />
* [http://www.eq-3.de/produkt-detail-aktoren/items/homematic-funk-heizkoerperthermostat.html Produktinfo]<br />
* [http://www.eq-3.de/Downloads/eq3/downloads_produktkatalog/homematic/bda/HM-CC-RT-DN_UM_GE_eQ-3_web.pdf Bedienungsanleitung (PDF)]<br />
* [http://www.eq-3.de/Downloads/eq3/downloads_produktkatalog/homematic/pdb/Funk-Heizkoerperthermostat_105155_Produktdatenblatt_V2.3.pdf Datenblatt (PDF)]<br />
* [http://www.eq-3.de/Downloads/eq3/downloads/Ventilkompatibilitaeten.pdf Ventil-Kompatibilitätsliste (zur Zeit nicht verfügbar)]<br />
* {{Link2Forum|Topic=14738|LinkText=Forenthema zum Thermostat}}<br />
* {{Link2Forum|Topic=64446|LinkText=Reparatur einer durch mechanischen Stoß von außen abgerissenen Lichtschranke}}<br />
<br />
[[Kategorie:HomeMatic Components]]<br />
[[Kategorie:Heizungsventile]]</div>MGuhttp://wiki.fhem.de/w/index.php?title=G-Homa&diff=21782G-Homa2017-07-01T16:49:43Z<p>MGu: /* Specs */</p>
<hr />
<div>{{Infobox Modul<br />
|Name=GHoma<br />
|ModPurpose=Anbindung der WIFI Steckdose G-Homa<br />
|ModCmdRef=GHoma<br />
|ModType=d<br />
|ModForumArea=Sonstige Systeme<br />
|ModTechName=53_GHoma.pm<br />
|ModOwner=klausw<br />
}}<br />
<br />
Die G-Homa oder GHoma Steckdose ist eine per WLAN schaltbare Steckdose. Diese Steckdose wird in vielen Baumärkten und im Internet vertrieben. Das Modul unterstützt die "set extensions".<br><br />
Es gibt sowohl eine Indoor, als auch eine Outdoor Variante.<br />
<br />
==Vorbereitung der Steckdose==<br />
Standardmäßig verbindet sich die Dose zu einem Server in der Cloud. Damit sie mit FHEM funktoiniert, muss diese Konfiguration angepasst werden.<br />
===WLAN konfigurieren===<br />
* Gerät in den AP Modus bringen (Knopf für mehr als 3s drücken, diesen Schritt wiederholen bis die LED permanent leuchtet)<br />
* Nun einen Computer mit der SSID <code>G-Homa</code> verbinden.<br />
* Im Browser zu http://10.10.100.254 (username:passwort = admin:admin)<br />
* In STA Setting WLAN Einstellungen eintragen<br />
<br />
'''Hinweis:''' Ab der Firmware 1.0.06 wird in diesen Geräten die Konfiguration über HTTP nicht mehr unterstützt. In diesem Fall muss die Konfiguration über die G-Homa App erfolgen.<br />
<br />
===Network Parameters settings===<br />
Other Setting -> Protocol auf TCP-Server<br><br />
Other Setting -> Port ID (wird später für FHEM benötigt)<br><br />
Other Setting -> Server Address (IP Adresse des FHEM Servers)<br><br />
===Optional===<br />
Im Router alle ausgehenden Verbindungen für G-Homa blockieren.<br />
<br />
===Allgemeines===<br />
Die Dose erfordert eine dauerhafte Verbindung zum Server (fhem). Wenn die Verbindung wegen Timeouts, WLAN Ausfall, ... abbricht, beginnt die LED an der Steckdose zu blinken und Schaltvorgänge werden unterbunden. Erst wenn die Verbindung wieder steht, reagiert die Dose wieder wie gewohnt. Ist die Verbindung per WLAN zu schwach, kann das zu dauerhaften Reconnects führen.<br />
<br />
==Define==<br />
<br />
:<code>define <name> GHoma <port></code><br />
Legt ein GHoma Server device an.<br><br />
Neue Zwischenstecker werden beim ersten verbinden automatisch angelegt.<br><br />
Diese können aber auch manuell angelegt werden:<br />
:<code>define <name> GHoma <Id></code><br />
Die Id besteht aus den letzten 6 Stellen der MAC Adresse des Zwischensteckers.<br><br />
Beispiel: MAC= AC:CF:23:A5:E2:3B -> Id= A5E23B<br />
<br />
==Set==<br />
<br />
:<code>set <name> <value></code><br />
Gültige Werte für value:<br />
:off<br />
:on<br />
Die [http://fhem.de/commandref#setExtensions set extensions] werden auch unterstützt.<br />
<br />
==Attribute==<br />
<br />
Für Zwischenstecker devices:<br />
:restoreOnStartup<br />
Wiederherstellen der Portzustände nach Neustart<br />
Standard: last, gültige Werte: last, on, off<br />
<br />
:restoreOnReinit<br />
Wiederherstellen der Portzustände nach Neustart<br />
Standard: last, gültige Werte: last, on, off<br />
<br />
:blocklocal<br />
Wert im Reading State sofort nach Änderung über lokale Taste wiederherstellen<br />
Standard: no, gültige Werte: no, yes<br />
<br />
Für Server devices:<br />
:allowfrom<br />
Regexp der erlaubten IP-Adressen oder Hostnamen. Wenn dieses Attribut gesetzt wurde, werden ausschließlich Verbindungen von diesen Adressen akzeptiert.<br />
<br />
==Specs==<br />
* Herstellerseite: [http://www.g-homa.com http://www.g-homa.com]<br />
* [https://files.elv.com/Assets/Produkte/12/1218/121893/Downloads/121893_wifi_funkschaltsteckdose_um.pdf Bedienungsanleitung WiFi Smart Steckdose IP44]<br />
* Typ: EMW302WFO<br />
* Spannung: 230V<br />
* Stecker/Dose: Schuko Typ-F<br />
* Strom: max 16A<br />
* Leistung: max 3680W<br />
* Schutzklasse (nur Outdoor): IP44<br />
* WiFi: 802.11 b/g/n<br />
* Von EverFlourish Europe GmbH, Robert-Koch-Str. 4, D-66299 Friedrichsthal<br />
* Das Gerät wird mit einem [http://www.iotworkshop.com/hf-lpt100f HF-LPT100F] realisiert, dass durch eine Spannungsaufbereitung, ein Relais nebst Treiber, einen Taster und einer LED auf zwei weiteren PCBs erweitert wurde.<br />
:* Darauf ist als SoC ein [https://www.generationrobots.com/media/MediaTek_MT5931_Wi-Fi_Data_Sheet_v1_0.pdf MT5931] verbaut, weshalb das Gerät eine MAC von ''Hi-flying electronics technology Co.,Ltd'' an der WLAN-Schnittstelle verwendet.<br />
:* Für technisch interessierte, lässt sich das Modul HF-LPT100F über eine UART-Schnittstelle (unbelegte Pins 5 und 6) am Pfostenstecker neu programmieren. Die Funktionen des Geräts sind realisiert durch:<br />
::# einem Taster gegen Masse mit Pull-Up-Widerstand an GPIO 18<br />
::# eine LED mit Vorwiderstand an GPIO 11<br />
::# ein Relais mit Treiber an GPIO 12<br />
:* Die UART und damit bei Bedarf auch GPIO 5 und 6 sind unbelegt.<br />
<br />
[[Kategorie:IP Components]]<br />
[[Kategorie:Schalter (Empfänger)]]</div>MGuhttp://wiki.fhem.de/w/index.php?title=G-Homa&diff=21781G-Homa2017-07-01T16:19:46Z<p>MGu: /* WLAN konfigurieren */</p>
<hr />
<div>{{Infobox Modul<br />
|Name=GHoma<br />
|ModPurpose=Anbindung der WIFI Steckdose G-Homa<br />
|ModCmdRef=GHoma<br />
|ModType=d<br />
|ModForumArea=Sonstige Systeme<br />
|ModTechName=53_GHoma.pm<br />
|ModOwner=klausw<br />
}}<br />
<br />
Die G-Homa oder GHoma Steckdose ist eine per WLAN schaltbare Steckdose. Diese Steckdose wird in vielen Baumärkten und im Internet vertrieben. Das Modul unterstützt die "set extensions".<br><br />
Es gibt sowohl eine Indoor, als auch eine Outdoor Variante.<br />
<br />
==Vorbereitung der Steckdose==<br />
Standardmäßig verbindet sich die Dose zu einem Server in der Cloud. Damit sie mit FHEM funktoiniert, muss diese Konfiguration angepasst werden.<br />
===WLAN konfigurieren===<br />
* Gerät in den AP Modus bringen (Knopf für mehr als 3s drücken, diesen Schritt wiederholen bis die LED permanent leuchtet)<br />
* Nun einen Computer mit der SSID <code>G-Homa</code> verbinden.<br />
* Im Browser zu http://10.10.100.254 (username:passwort = admin:admin)<br />
* In STA Setting WLAN Einstellungen eintragen<br />
<br />
'''Hinweis:''' Ab der Firmware 1.0.06 wird in diesen Geräten die Konfiguration über HTTP nicht mehr unterstützt. In diesem Fall muss die Konfiguration über die G-Homa App erfolgen.<br />
<br />
===Network Parameters settings===<br />
Other Setting -> Protocol auf TCP-Server<br><br />
Other Setting -> Port ID (wird später für FHEM benötigt)<br><br />
Other Setting -> Server Address (IP Adresse des FHEM Servers)<br><br />
===Optional===<br />
Im Router alle ausgehenden Verbindungen für G-Homa blockieren.<br />
<br />
===Allgemeines===<br />
Die Dose erfordert eine dauerhafte Verbindung zum Server (fhem). Wenn die Verbindung wegen Timeouts, WLAN Ausfall, ... abbricht, beginnt die LED an der Steckdose zu blinken und Schaltvorgänge werden unterbunden. Erst wenn die Verbindung wieder steht, reagiert die Dose wieder wie gewohnt. Ist die Verbindung per WLAN zu schwach, kann das zu dauerhaften Reconnects führen.<br />
<br />
==Define==<br />
<br />
:<code>define <name> GHoma <port></code><br />
Legt ein GHoma Server device an.<br><br />
Neue Zwischenstecker werden beim ersten verbinden automatisch angelegt.<br><br />
Diese können aber auch manuell angelegt werden:<br />
:<code>define <name> GHoma <Id></code><br />
Die Id besteht aus den letzten 6 Stellen der MAC Adresse des Zwischensteckers.<br><br />
Beispiel: MAC= AC:CF:23:A5:E2:3B -> Id= A5E23B<br />
<br />
==Set==<br />
<br />
:<code>set <name> <value></code><br />
Gültige Werte für value:<br />
:off<br />
:on<br />
Die [http://fhem.de/commandref#setExtensions set extensions] werden auch unterstützt.<br />
<br />
==Attribute==<br />
<br />
Für Zwischenstecker devices:<br />
:restoreOnStartup<br />
Wiederherstellen der Portzustände nach Neustart<br />
Standard: last, gültige Werte: last, on, off<br />
<br />
:restoreOnReinit<br />
Wiederherstellen der Portzustände nach Neustart<br />
Standard: last, gültige Werte: last, on, off<br />
<br />
:blocklocal<br />
Wert im Reading State sofort nach Änderung über lokale Taste wiederherstellen<br />
Standard: no, gültige Werte: no, yes<br />
<br />
Für Server devices:<br />
:allowfrom<br />
Regexp der erlaubten IP-Adressen oder Hostnamen. Wenn dieses Attribut gesetzt wurde, werden ausschließlich Verbindungen von diesen Adressen akzeptiert.<br />
<br />
==Specs==<br />
* Herstellerseite: [http://www.g-homa.com http://www.g-homa.com]<br />
* [https://files.elv.com/Assets/Produkte/12/1218/121893/Downloads/121893_wifi_funkschaltsteckdose_um.pdf Bedienungsanleitung WiFi Smart Steckdose IP44]<br />
* Typ: EMW302WFO<br />
* Spannung: 230V<br />
* Stecker/Dose: Schuko Typ-F<br />
* Strom: max 16A<br />
* Leistung: max 3680W<br />
* Schutzklasse (nur Outdoor): IP44<br />
* WiFi: 802.11 b/g/n<br />
* Von EverFlourish Europe GmbH, Robert-Koch-Str. 4, D-66299 Friedrichsthal<br />
* Das Gerät wird mit einem [http://www.iotworkshop.com/hf-lpt100f HF-LPT100F] realisiert, dass durch eine Spannungsaufbereitung, ein Relais nebst Treiber, einen Taster und einer LED auf zwei weiteren PCBs erweitert wurde.<br />
:* Darauf ist als SoC ist ein [https://www.generationrobots.com/media/MediaTek_MT5931_Wi-Fi_Data_Sheet_v1_0.pdf MT5931] verbaut, weshalb das Gerät eine MAC von ''Hi-flying electronics technology Co.,Ltd'' an der WLAN-Schnittstelle verwendet.<br />
:* Für technisch interessierte, lässt sich das Modul HF-LPT100F über eine UART-Schnittstelle (unbelegte Pins 5 und 6) am Pfostenstecker neu programmieren. Die Funktionen des Geräts sind realisiert durch:<br />
::# einem Taster gegen Masse mit Pull-Up-Widerstand an GPIO 18<br />
::# eine LED mit Vorwiderstand an GPIO 11<br />
::# ein Relais mit Treiber an GPIO 12<br />
:* Die UART und damit bei Bedarf auch GPIO 5 und 6 sind unbelegt.<br />
<br />
[[Kategorie:IP Components]]<br />
[[Kategorie:Schalter (Empfänger)]]</div>MGuhttp://wiki.fhem.de/w/index.php?title=G-Homa&diff=21780G-Homa2017-07-01T15:36:07Z<p>MGu: /* Specs */ Mehr Details</p>
<hr />
<div>{{Infobox Modul<br />
|Name=GHoma<br />
|ModPurpose=Anbindung der WIFI Steckdose G-Homa<br />
|ModCmdRef=GHoma<br />
|ModType=d<br />
|ModForumArea=Sonstige Systeme<br />
|ModTechName=53_GHoma.pm<br />
|ModOwner=klausw<br />
}}<br />
<br />
Die G-Homa oder GHoma Steckdose ist eine per WLAN schaltbare Steckdose. Diese Steckdose wird in vielen Baumärkten und im Internet vertrieben. Das Modul unterstützt die "set extensions".<br><br />
Es gibt sowohl eine Indoor, als auch eine Outdoor Variante.<br />
<br />
==Vorbereitung der Steckdose==<br />
Standardmäßig verbindet sich die Dose zu einem Server in der Cloud. Damit sie mit FHEM funktoiniert, muss diese Konfiguration angepasst werden.<br />
===WLAN konfigurieren===<br />
* Gerät in den AP Modus bringen (Knopf für mehr als 3s drücken, diesen Schritt wiederholen bis die LED permanent leuchtet)<br />
* Nun einen Computer mit der SSID <code>G-Homa</code> verbinden.<br />
* Im Browser zu http://10.10.100.254 (username:passwort = admin:admin)<br />
* In STA Setting WLAN Einstellungen eintragen<br />
<br />
===Network Parameters settings===<br />
Other Setting -> Protocol auf TCP-Server<br><br />
Other Setting -> Port ID (wird später für FHEM benötigt)<br><br />
Other Setting -> Server Address (IP Adresse des FHEM Servers)<br><br />
===Optional===<br />
Im Router alle ausgehenden Verbindungen für G-Homa blockieren.<br />
<br />
===Allgemeines===<br />
Die Dose erfordert eine dauerhafte Verbindung zum Server (fhem). Wenn die Verbindung wegen Timeouts, WLAN Ausfall, ... abbricht, beginnt die LED an der Steckdose zu blinken und Schaltvorgänge werden unterbunden. Erst wenn die Verbindung wieder steht, reagiert die Dose wieder wie gewohnt. Ist die Verbindung per WLAN zu schwach, kann das zu dauerhaften Reconnects führen.<br />
<br />
==Define==<br />
<br />
:<code>define <name> GHoma <port></code><br />
Legt ein GHoma Server device an.<br><br />
Neue Zwischenstecker werden beim ersten verbinden automatisch angelegt.<br><br />
Diese können aber auch manuell angelegt werden:<br />
:<code>define <name> GHoma <Id></code><br />
Die Id besteht aus den letzten 6 Stellen der MAC Adresse des Zwischensteckers.<br><br />
Beispiel: MAC= AC:CF:23:A5:E2:3B -> Id= A5E23B<br />
<br />
==Set==<br />
<br />
:<code>set <name> <value></code><br />
Gültige Werte für value:<br />
:off<br />
:on<br />
Die [http://fhem.de/commandref#setExtensions set extensions] werden auch unterstützt.<br />
<br />
==Attribute==<br />
<br />
Für Zwischenstecker devices:<br />
:restoreOnStartup<br />
Wiederherstellen der Portzustände nach Neustart<br />
Standard: last, gültige Werte: last, on, off<br />
<br />
:restoreOnReinit<br />
Wiederherstellen der Portzustände nach Neustart<br />
Standard: last, gültige Werte: last, on, off<br />
<br />
:blocklocal<br />
Wert im Reading State sofort nach Änderung über lokale Taste wiederherstellen<br />
Standard: no, gültige Werte: no, yes<br />
<br />
Für Server devices:<br />
:allowfrom<br />
Regexp der erlaubten IP-Adressen oder Hostnamen. Wenn dieses Attribut gesetzt wurde, werden ausschließlich Verbindungen von diesen Adressen akzeptiert.<br />
<br />
==Specs==<br />
* Herstellerseite: [http://www.g-homa.com http://www.g-homa.com]<br />
* [https://files.elv.com/Assets/Produkte/12/1218/121893/Downloads/121893_wifi_funkschaltsteckdose_um.pdf Bedienungsanleitung WiFi Smart Steckdose IP44]<br />
* Typ: EMW302WFO<br />
* Spannung: 230V<br />
* Stecker/Dose: Schuko Typ-F<br />
* Strom: max 16A<br />
* Leistung: max 3680W<br />
* Schutzklasse (nur Outdoor): IP44<br />
* WiFi: 802.11 b/g/n<br />
* Von EverFlourish Europe GmbH, Robert-Koch-Str. 4, D-66299 Friedrichsthal<br />
* Das Gerät wird mit einem [http://www.iotworkshop.com/hf-lpt100f HF-LPT100F] realisiert, dass durch eine Spannungsaufbereitung, ein Relais nebst Treiber, einen Taster und einer LED auf zwei weiteren PCBs erweitert wurde.<br />
:* Darauf ist als SoC ist ein [https://www.generationrobots.com/media/MediaTek_MT5931_Wi-Fi_Data_Sheet_v1_0.pdf MT5931] verbaut, weshalb das Gerät eine MAC von ''Hi-flying electronics technology Co.,Ltd'' an der WLAN-Schnittstelle verwendet.<br />
:* Für technisch interessierte, lässt sich das Modul HF-LPT100F über eine UART-Schnittstelle (unbelegte Pins 5 und 6) am Pfostenstecker neu programmieren. Die Funktionen des Geräts sind realisiert durch:<br />
::# einem Taster gegen Masse mit Pull-Up-Widerstand an GPIO 18<br />
::# eine LED mit Vorwiderstand an GPIO 11<br />
::# ein Relais mit Treiber an GPIO 12<br />
:* Die UART und damit bei Bedarf auch GPIO 5 und 6 sind unbelegt.<br />
<br />
[[Kategorie:IP Components]]<br />
[[Kategorie:Schalter (Empfänger)]]</div>MGuhttp://wiki.fhem.de/w/index.php?title=G-Homa&diff=21779G-Homa2017-07-01T14:39:22Z<p>MGu: SSID korrigiert und etwas Formatierung</p>
<hr />
<div>{{Infobox Modul<br />
|Name=GHoma<br />
|ModPurpose=Anbindung der WIFI Steckdose G-Homa<br />
|ModCmdRef=GHoma<br />
|ModType=d<br />
|ModForumArea=Sonstige Systeme<br />
|ModTechName=53_GHoma.pm<br />
|ModOwner=klausw<br />
}}<br />
<br />
Die G-Homa oder GHoma Steckdose ist eine per WLAN schaltbare Steckdose. Diese Steckdose wird in vielen Baumärkten und im Internet vertrieben. Das Modul unterstützt die "set extensions".<br><br />
Es gibt sowohl eine Indoor, als auch eine Outdoor Variante.<br />
<br />
==Vorbereitung der Steckdose==<br />
Standardmäßig verbindet sich die Dose zu einem Server in der Cloud. Damit sie mit FHEM funktoiniert, muss diese Konfiguration angepasst werden.<br />
===WLAN konfigurieren===<br />
* Gerät in den AP Modus bringen (Knopf für mehr als 3s drücken, diesen Schritt wiederholen bis die LED permanent leuchtet)<br />
* Nun einen Computer mit der SSID <code>G-Homa</code> verbinden.<br />
* Im Browser zu http://10.10.100.254 (username:passwort = admin:admin)<br />
* In STA Setting WLAN Einstellungen eintragen<br />
<br />
===Network Parameters settings===<br />
Other Setting -> Protocol auf TCP-Server<br><br />
Other Setting -> Port ID (wird später für FHEM benötigt)<br><br />
Other Setting -> Server Address (IP Adresse des FHEM Servers)<br><br />
===Optional===<br />
Im Router alle ausgehenden Verbindungen für G-Homa blockieren.<br />
<br />
===Allgemeines===<br />
Die Dose erfordert eine dauerhafte Verbindung zum Server (fhem). Wenn die Verbindung wegen Timeouts, WLAN Ausfall, ... abbricht, beginnt die LED an der Steckdose zu blinken und Schaltvorgänge werden unterbunden. Erst wenn die Verbindung wieder steht, reagiert die Dose wieder wie gewohnt. Ist die Verbindung per WLAN zu schwach, kann das zu dauerhaften Reconnects führen.<br />
<br />
==Define==<br />
<br />
:<code>define <name> GHoma <port></code><br />
Legt ein GHoma Server device an.<br><br />
Neue Zwischenstecker werden beim ersten verbinden automatisch angelegt.<br><br />
Diese können aber auch manuell angelegt werden:<br />
:<code>define <name> GHoma <Id></code><br />
Die Id besteht aus den letzten 6 Stellen der MAC Adresse des Zwischensteckers.<br><br />
Beispiel: MAC= AC:CF:23:A5:E2:3B -> Id= A5E23B<br />
<br />
==Set==<br />
<br />
:<code>set <name> <value></code><br />
Gültige Werte für value:<br />
:off<br />
:on<br />
Die [http://fhem.de/commandref#setExtensions set extensions] werden auch unterstützt.<br />
<br />
==Attribute==<br />
<br />
Für Zwischenstecker devices:<br />
:restoreOnStartup<br />
Wiederherstellen der Portzustände nach Neustart<br />
Standard: last, gültige Werte: last, on, off<br />
<br />
:restoreOnReinit<br />
Wiederherstellen der Portzustände nach Neustart<br />
Standard: last, gültige Werte: last, on, off<br />
<br />
:blocklocal<br />
Wert im Reading State sofort nach Änderung über lokale Taste wiederherstellen<br />
Standard: no, gültige Werte: no, yes<br />
<br />
Für Server devices:<br />
:allowfrom<br />
Regexp der erlaubten IP-Adressen oder Hostnamen. Wenn dieses Attribut gesetzt wurde, werden ausschließlich Verbindungen von diesen Adressen akzeptiert.<br />
<br />
==Specs==<br />
Herstellerseite: [http://www.g-homa.com http://www.g-homa.com]<br><br />
Spannung: 230V<br><br />
Stecker/Dose: Schuko Typ-F<br><br />
Strom: max 16A<br><br />
Leistung: max 3680W<br><br />
Schutzklasse (nur Outdoor): IP44<br><br />
WiFi: 802.11 b/g/n<br />
<br />
[[Kategorie:IP Components]]<br />
[[Kategorie:Schalter (Empfänger)]]</div>MGuhttp://wiki.fhem.de/w/index.php?title=AES_Encryption&diff=21732AES Encryption2017-06-18T17:06:54Z<p>MGu: Typo und Formatierung</p>
<hr />
<div>= Grundlagen =<br />
Anders als der Name vermuteten lässt, handelt es sich beim HM (HomeMatic) AES-Encryption Modus des "BidCos"-Protokolls nicht um verschlüsselten Funkverkehr, sondern um das Einschalten eines Signatur-Modus (AES-Challenge-Response (CR)). Hierbei muss sich der Sender durch das Signieren seiner Nachrichten mit einem allen Kommunikationspartnern bekannten AES-Schlüssel authentifizieren. Der Empfänger wird das Kommando nur ausführen, wenn die Authentifizierung korrekt ist.<br />
Die eigentliche Datenübertragung findet im Klartext statt und kann immer mitgelesen bzw. abgehört werden, jedoch werden keine Kommandos von nicht autorisierter Quellen ausgeführt.<br />
<br />
Der AES-Encryption Modus sichert, wenn eingeschaltet<br />
* das Ändern der Gerätekonfiguration<br />
* das Auslösen von Triggern (Tasten, Sensoren,...)<br />
* das Schalten von Aktoren<br />
<br />
== AES-Prinzip ==<br />
Der '''Advanced Encryption Standard''' (AES) ist ein im Auftrag der US-Regierung entwickeltes symmetrisches Verschlüsselungsverfahren, bei dem sowohl Sender als auch Empfänger über die Kenntnis eines ''geheimen'' Schlüssels verfügen müssen. Das AES-Verfahren ist öffentlich bekannt und erfüllt damit ein wesentliches Kriterium sicherer Verfahren, nämlich ihre Überprüfbarkeit. Bis heute ist kein Verfahren bekannt, mit dem man eine AES-Verschlüsselung ohne Kenntnis des Schlüssels "knacken" kann. Es gibt auch keine Hinweise darauf, dass die NSA dazu im Stande sein könnte.<br />
<br />
== Signatur ==<br />
Bei einer digitalen Signatur werden nicht Schlüssel verglichen, sondern das Ergebnis der Verschlüsselung bestimmter kurzer Datensätze. Ist das Ergebnis der Verschlüsselung bei Sender und Empfänger gleich, kennen bei den gleichen geheimen Schlüssel.<br />
<br />
= Kommunikationsstrecken =<br />
Der sichere Betrieb von Hausautomatisierungssystemen betrifft unterschiedliche Kommunikationspfade. <br />
* Von der SmartHome-Zentrale gibt es einen Weg zum Eingabeterminal (Web-Interface auf PC, Smartphone o.ä.), die Zentrale-Frontend-Schnittstelle. <br />
* Weiter gibt es einen Weg zum I/O-Gerät ([[HMLAN Konfigurator]], [[HM-CFG-USB USB Konfigurations-Adapter]], [[CUL]], [[CUN]], [[CUNO]]) welches die Brücke zur Funk- oder Kabelstrecke herstellt. Wenn FHEM die Zentrale bildet, ist das die FHEM-I/O-Schnittstelle.<br />
* Es folgt die I/O-Geräte-Schnittstelle, die Funk- oder Kabelstrecke.<br />
* Letztlich gibt es noch die Geräte-Geräte Schnittstelle für die direkte Kommunikation der HomeMatic-Geräte untereinander. <br />
<br />
== Zentrale ←→ Frontend ==<br />
Diese Schnittstelle ist in der Regel eine internetbasierte Verbindung, meist in Form eines Aufrufes im Web-Browser. Hier muss durch eines der standardisierten Sicherheitsverfahren im Internet für sichere Kommunikation gesorgt werden: Virtual Private Network (VPN), verschlüsseltes WLAN und HTTPS sind gängige Methoden, die hier nicht weiter diskutiert werden sollen.<br />
<br />
== Zentrale ←→ I/O-Device ==<br />
HomeMatic unterstützt auf dieser Strecke prinzipiell eine AES-Verschlüsselung, dies ist in FHEM allerdings nicht überall implementiert. Nutzt man stattdessen eine originale HomeMatic CCU2-Zentrale, kann hier AES aktiviert werden. Wenn FHEM die Zentrale ist, muss im [[HMLAN Konfigurator]] die netzwerkseitige AES-Verschlüsselung über die HM-PC-Software abgeschaltet werden, sonst kann FHEM nicht mit dem [[HMLAN Konfigurator]] kommunizieren. <br />
Das [[HM-LGW-O-TW-W-EU Funk-LAN Gateway]] kann mit und ohne LAN AES genutzt werden (Konfiguration mit LAN Konfigurator/Netfinder von eq3). Für LAN AES muss das Perl-Modul <code>Crypt::Rijndael</code> (Debian: <code>libcrypt-rijndael-perl</code>) installiert sein.<br />
<br />
Es sind 2 Schnittstellen zu betrachten: <br />
Nutzt man ein USB Interface besteht i.a. kein Sicherheitsproblem. Man muss sicherstellen, dass niemand in die Zentrale eindringen kann.<br />
Sollte man ein I/O-Device per LAN oder WLAN benutzen ([[HMLAN Konfigurator]], [[CUN]], [[CUNO]]) muss dieses Netz entsprechend gesichert sein. Entsprechende Verfahren (z.B. VLAN, Firewalls,...) werden hier nicht weiter besprochen.<br />
<br />
== I/O-Device ←→ Gerät ==<br />
Dieses Teilstück kann mit AES gesichert werden. <br />
Die Kommunikation auf Signaturbasis ist im Abschnitt [[#Ablauf|Ablauf]] beschrieben. <br />
<br />
Es kann ein [[HomeMatic#FHEM_als_Zentrale|HomeMatic]] IO oder ein [[CUL]] kompatibler Io genutzt werden. <br />
Die HomeMatic Module und IOs können AES von sich aus. Für alle [[CUL]]-kompatiblen Geräte muss das Perl-Modul <code>Crypt::Rijndael</code> (Debian: <code>libcrypt-rijndael-perl</code>) installiert sein.<br />
<br />
Bei CUL Kompatiblen Geräten kann es zu Timingproblemen kommen. Für CUL Geräte ist für HomeMatic generell die {{Link2Forum|Topic=31421|LinkText=TS Firmware}} angeraten!<br />
<br />
Beim Einsatz von AES-CBC, z.B. dem Rauchmelder HM-SEC-SD-2, wird generell das Perl-Modul <code>Crypt::Rijndael</code> (Debian: <code>libcrypt-rijndael-perl</code>) benötigt!<br />
<br />
== Gerät ←→ Gerät ==<br />
AES kann auch für die Kommunikation zwischen den Geräten aktiviert werden. Hierbei werden Trigger von Sensoren (z.B. Tasten) durch den Empfänger durch Anforderung einer AES-Signatur überprüft. Dies kann je Kanal aktiviert bzw. deaktiviert werden: Ein 2-Kanal Schalter kann also auf einem Kanal AES nutzen und auf dem anderen nicht.<br />
<br />
= Ablauf =<br />
Bei eingeschaltetem AES-Encryption Modus wird ein Kommando durch den Empfänger nicht sofort ausgeführt. Der Empfänger sendet vielmehr einen Binärwert mit Signaturanforderung an den Sender (Challenge), welche dieser mit seinem bekannten AES-Schlüssel kodieren und zurücksenden muss (Response). Der Empfänger vergleicht diese mit einem Wert, den er selbst aus der Verschlüsselung mit seinem Schlüssel erhält. Nur wenn beide verschlüsselten Datenwerte übereinstimmen, wird das zuerst erhaltene Kommando ausgeführt und der Empfänger quittiert mit einem ACK an den Sender.<br />
<br />
Die AES Challenge-Response Antwort wird mit dem System-Schlüssel erzeugt. Der System-Schlüssel wird von der Zentrale bzw. dem [[HMLAN Konfigurator]] auf alle gepairten HomeMatic Geräte verteilt. Ab Werk ist ein einheitlicher Standard-Schlüssel hinterlegt. Dieser ist in '''allen''' HM-Geräten gleich und '''muss''' somit vom User geändert werden um einen sinnvollen Schutz zu erreichen.<br />
<br />
== Overhead ==<br />
Es ist aus diesem Ablauf klar, dass der AES-Encryption Modus zu einer zusätzlichen Zeitverzögerung zwischen dem Absenden und dem Ausführen eines Kommandos führt. Im günstigen Fall kann diese etwa 200 ms betragen, in ungünstigen Fällen auch höher sein. Außerdem erhöht sich auf einer Funkstrecke mit AES-Encryption Modus die Funklast auf den dreifachen Wert. Wegen der 1%-Regel kann dies ein I/O-Gerät durchaus in die Überladung mit Befehlen steuern.<br />
<br />
Es ist deshalb zu empfehlen, den AES-Encryption Modus nur für sicherheitskritische HomeMatic-Geräte einzuschalten, etwa für Türöffner. Auch der Hersteller eQ-3 gibt diese Empfehlung.<br />
<br />
== Sicherheit ==<br />
Der genaue Ablauf des AES-Signaturverfahrens ist in "[https://git.zerfleddert.de/hmcfgusb/AES/ Dissecting HomeMatic AES]" beschrieben. Henryk Plötz hat die Sicherheit des Kommunikationsprotokolls in "[https://blog.ploetzli.ch/2015/on-the-security-of-aes-in-homematic/ On the Security of AES in HomeMatic]" näher betrachtet.<br />
<br />
= Aktivieren, Einrichten, Umgang in FHEM =<br />
== Zentrale ==<br />
*Der erste Schritt ist, in der virtuellen CCU von FHEM oder nur einem I/O-Device einen Schlüssel (Key) zu vergeben In FHEM kann mehr als ein Schlüssel hinterlegt sein (Attribute hmKey, hmKey2, hmKey3), als aktiv wird aber nur der Schlüssel mit dem höchsten Index betrachtet, und nur dieser wird, wie unten beschrieben, an ein Gerät übertragen. Fügt man einen neuen Schlüssel hinzu und ein Gerät ist gerade nicht aktiv, kann/muss das System den vorigen Schlüssel noch nutzen. <br />
** Der Systemverwalter muss sich den Schlüssel unbedingt merken. Er kann nicht aus den Geräten gelöscht werden! Im Zweifelsfall muss das Gerät kostenpflichtig von eQ-3 zurückgesetzt werden. <br />
** Die Schlüssel werden MD5 kodiert - man kann ihn im Klartext oder bereits kodiert eingeben. FHEM kodiert ihn, wenn er im Klartext eingegeben werden sollte. FHEM speichert das Attribut ausschließlich kodiert.<br />
:: <code>attr VCCU hmKey geheimerSchluessel</code><br />
*Der zweite Schritt besteht darin, den Schlüssel mit dem höchstenm Index mit dem gerätespezifischen FHEM-Kommando ''assignHmKey'' an alle gepairten Geräte zu übertragen, mindestens aber an diejenigen, bei denen der AES-Encryption Modus eingeschaltet werden soll. Es ist aber auch möglich, diese Aktion mit der HM Konfigurationssoftware (HM-PC-Software) oder einer CCU durchzuführen.<br />
:: <code>set Geraet assignHmKey</code><br />
:: <code>set Schalter assignHmKey</code><br />
Der aktuelle Schlüsselindex kann aus dem Reading <code>aesKeyNbr</code> des Geräts berechnet werden, wobei das Reading den im Funkprotokoll angeforderten Schlüssel wiederspiegelt, welcher den '''doppelten''' Wert des eigentlichen Schlüsselindex hat. Weiterhin muss beachtet werden, dass das Reading <code>aesKeyNbr</code> nur angepasst wird, wenn das Gerät eine Signatur anfordert, d.h. eine Schaltaktion ausgeführt oder ein Register geändert wird. '''Direkt nach dem <code>assignHmKey</code> hat das Reading noch einen veralteten Wert!'''<br />
<br />
== Geräte ==<br />
* Eine AES-Signatur muss vom Empfänger angefordert werden. Dementsprechend wird die Nutzung auch dort aktiviert. Dies wird durch das Setzen des Registers '''sign''' auf '''on''' erreicht, wobei es für jeden Kanal des Geräts separat gesteuert wird. <br />
:: <code>set Geraet sign on</code><br />
:: <code>set Schalter_Btn_01 sign on</code><br />
* Ein Sender, der mit einem Empfänger gepeert ist sollte wissen, dass dieser AES nutzen wird. Das Register '''expectAES''' ist hierbei auf on zu setzen. Hiermit kann der Sender überprüfen, ob tatsächlich eine AES-Transaktion stattgefunden hat und diese vom Gerät korrekt bestätigt wurde. Falls dies nicht der Fall ist, wird die Anfrage wiederholt bzw. dem Benutzer ein Fehler signalisiert.<br />
:: <code>set Schalter_Btn_01 regSet expectAES on Geraet</code><br />
* Die Zentrale kann ebenfalls eine AES-Signatur von einem Gerät anfordern, so sie einen Trigger empfängt. Hierzu ist im Device (und evtl. entsprechendem Kanal) eines Geräts das Attribut <code>aesCommReq</code> auf 1 zu setzen. Damit die Signatur angefordert wird, muss das Attribut auf jeden Fall auch im Gerät gesetzt werden, auch wenn nur ein einzelner Kanal betroffen ist. Hiermit kann die Überprüfung für ein Gerät sehr schnell deaktiviert werden, indem nur das Geräteattribut wieder entfernt wird (z.B. nach Factory-Reset nötig, wenn das Gerät den eigenen Schlüssel noch nicht kennt). Sollte die Signaturüberprüfung fehlschlagen, verarbeitet FHEM den Befehl nicht.<br />
:: <code>attr Geraet aesCommReq 1</code><br />
:: <code>attr Schalter aesCommReq 1</code><br />
:: <code>attr Schalter_Btn_01 aesCommReq 1</code><br />
<br />
= Nachteile, Einschränkungen =<br />
* Die zusätzliche Kommunikation führt zu einer Verzögerung von etwa 200ms je Vorgang.<br />
* Die erhöhte Nachrichtenlast schlägt sich in der Auslastung der IO-Devices nieder. Wenn zwischen Zentrale und dem Gerät AES-Signatur genutzt wird reduziert sich das stündliche Sendekontingent des IO-Devices, siehe [[1% Regel]]<br />
* Jedes Kommando und seine Bestätigung wird unverschlüsselt übertragen, so dass Beobachter von außen den Zustand jedes Aktors durch mitlesen des Funkverkehrs ermitteln können. Dies trifft auch bei selbst gesetztem Schlüssel zu.<br />
* Ein Sicherheitsgewinn ist nur gegeben, wenn ein eigener System-Sicherheitsschlüssel genutzt wird.<br />
<br />
== Hinweise ==<br />
Eine Steigerung der Sicherheit ergibt sich nur, wenn man den werksseitig vorgegeben Schlüssel ändert. Solange Angreifern der eigene Schlüssel unbekannt bleibt, ist ein Fremdschalten oder die Änderung der Konfiguration nicht mehr möglich, wohl aber ein Ermitteln des aktuellen Schaltzustandes.<br />
<br />
Wurde ein eigener Schlüssel vergeben der nicht mehr bekannt ist und wird dann die Zentrale zurückgesetzt oder ausgetauscht ohne die Komponenten vorher auf Werkseinstellung zurückzusetzen, sind die entsprechenden Komponenten '''nicht mehr verwendbar'''. Die Geräte müssen kostenpflichtig eingeschickt und zurückgesetzt werden. <br />
<br />
'''WICHTIG''': den eigenen Sicherheitsschlüssel gut und sicher aufbewahren.<br />
<br />
Wenn ein Gerät mit gesetztem eigenem Sicherheitsschlüssel an eine andere/neue CCU angelernt werden soll, wird während des Anlernvorgangs nach dem eigenen Sicherheitsschlüssel gefragt. Dieser muss also bereits in der neuen Zentrale vorliegen.<br />
<br />
Die AES-Signierung kann mit einigen Ausnahmen (hauptsächlich Dimmer mit älteren Firmware-Versionen) in jedem HM-Gerät separat je Kanal aktiviert/deaktiviert werden.<br />
In einigen Geräte wie z.B. KeyMatic kann die AES-Signierung nicht abgeschaltet werden. Diese Geräte kommunizieren '''immer''' AES-Signiert.<br />
<br />
== Bekannte Probleme ==<br />
* Durch Fehler in der Firmware einiger Aktoren/FW Versionen (HM-LC-Sw1-Pl und HM-LC-SW2-PB-FM) werden Toggle-Kommandos '''vor''' Eintreffen des Signingpaketes geschaltet. Beim HM-LC-SW1-PL mit Firmware Version 1.9 konnte dieses Verhalten nicht mehr reproduziert werden.<br />
*Die Schlüsselimplementation der CCU in älteren Firmwareversionen (vor 1.504) ist mit Bugs behaftet. Es ergeben sich Risiken selbst dann, wenn der Schlüssel bekannt ist. So darf der Schlüssel z.b. keinesfalls ein "&amp;" enthalten. Gelegentlich wird auch berichtet, dass garantiert richtig eingegebene Schlüssel bei Systemwechseln nicht akzeptiert wurden. '''WICHTIG''': Keine Sonderzeichen im eigenen Sicherheitsschlüssel verwenden.<br />
<br />
[[Kategorie:HomeMatic Components]]</div>MGuhttp://wiki.fhem.de/w/index.php?title=Notify&diff=20527Notify2017-03-04T19:15:55Z<p>MGu: Link zur Command-Ref angepasst. Also nichts wirklich externes.</p>
<hr />
<div>{{SEITENTITEL:notify}}<br />
{{Infobox Modul<br />
|ModPurpose=Ausführung von Anweisung(en) als Reaktion auf Ereignisse<br />
|ModType=h<br />
|ModCmdRef=notify<br />
|ModForumArea=Automatisierung<br />
|ModTechName=91_notify.pm<br />
|ModOwner=rudolfkoenig ({{Link2FU|8|Forum}} / [[Benutzer Diskussion:Rudolfkoenig|Wiki]])<br />
}}<br />
__TOC__<br />
{{Todo|generelle Überarbeitung, Fehlerkontrolle, Formatierung}}<br />
{{Randnotiz|RNTyp=[g|Info|RNText= Tipps<br />
* Weitere grundlegende Informationen/Beispiele zu notify enthält [http://fhem.de/Heimautomatisierung-mit-fhem.pdf Heimautomatisierung mit FHEM] <br> "Um Ihren Perlcode zu testen, verwenden Sie das [https://fhem.de/commandref.html#trigger trigger-Kommando]. [...] Wenn Sie also z.B. ein <code>define Testcode notify Schalter1:on {Perlcode}</code> testen möchten, können Sie Ihren Code mit <code>trigger Schalter1 on</code> testen. trigger simuliert das Eintreten eines Ereignisses [...]" (Tipp von S. 38 der Version 4.0)<br />
<!-- AUSKOMMENTIERT wegen derzeitiger Funktionsproblemen iZm codemirror * FHEM enthält für notify eine eingebaute Perl-Syntax-Prüfung. Diese ist nach [http://fhem.de/commandref.html#perlSyntaxCheck Aktivierung] aber nur aktiv, wenn die [[Konfiguration]] -wie empfohlen- nicht direkt bearbeitet wird. ({{Link2Forum|Topic=51744}}) --> }}<br />
== Notify, das mächtige Tool ==<br />
Die nachfolgenden Beispiele beziehen sich hauptsächlich auf [[EIB / KNX|KNX (EIB)]]. Sie sind aber auf alle anderen Systeme übertragbar.<br />
<br />
Was ist notify? <br />
Das Hilfsmodul notify dient dazu, Aktionen abhängig von einem anderen [[Event|Ereignis/Event]] auszulösen. Es ist damit möglich, Logikfunktionen im FHEM abzubilden.<br />
<br />
Z.B.: das Licht in der Küche wird eingeschaltet ====&gt; draus folgt, dass auch das Radio eingeschaltet wird.<br />
<br />
=== Syntax von notify ===<br />
<br />
define <name> notify <Suchmuster> <command> <br />
<br />
Das [[Regulärer Ausdruck|Suchmuster (auch Regexp = regulärer Ausdruck)]] ist sehr wichtig. Es ist entweder der Name des auslösenden ("triggernden") Gerätes oder die Kombination aus Gerät und auslösendem Ereignis (Event) Gerätename:Event. Die Events kann man dem [[Event_monitor|Event-Monitor]] entnehmen. Wenn da z.B. Rollo1 steht, dann reagiert notify auf Rollo1 on und off und was es sonst noch alles gibt.<br />
<br />
Wenn man mehrere Suchmuster möchte, kann man diese in Klammer schreiben (Rollo1|Rollo2|Steckdose5)<br />
als Trenner wird dann Pipe (|) genutzt.<br />
<br />
Man kann auch mit Platzhaltern arbeiten.<br />
<br />
* Rollo. ==> das notify reagiert auf alles was mit Rollo und '''einem''' weiteren beliebigen Zeichen anfängt. Also auf Rollo1 wie auch auf RolloG, aber nicht auf Rollo_wischundweg<br />
* Rollo.* ==> das notify reagiert auf alles das mit Rollo beginnt.<br />
* .*isch ==>; Reagiere auf alles das mit isch aufhört (Tisch, Fisch)<br />
<br />
Suchmuster/Regex kann man im Internet beispielsweise auf [http://regexpal.com/| http://regexpal.com/] testen.<br />
<br />
=== Regexp wizard - FHEMWEB-unterstützte Anlage eines notify ===<br />
Die Erstellung eines notify und insbesondere die korrekte Angabe des Suchmusters (Regex) führt gerade bei Einsteigern immer wieder zu Schwierigkeiten. Zur Fehlerminimierung empfiehlt es sich einmal die [[Konfiguration]] nicht direkt zu bearbeiten, sondern die "Befehl-Eingabezeile" und die "Objektdetails" zur Bearbeitung zu nutzen. Zudem enthält FHEM einen Regexp wizard mit dem Regex anhand der in FHEM vorhandenen Devices und deren Events aus einer Auswahlbox selektiert werden können. Voraussetzungen sind:<br />
* Aktivierung des Hilfsmoduls [[eventTypes]] (bei allen Neuinstallationen Standard) <br />
* das gesuchte Ereignis (Event) ist nach Aktivierung des Hilfsmoduls bereits mindestens einmal eingetreten<br />
<br />
Schrittweise Darstellung der Nutzung des Regexp wizard zur Anlage eines "notify":<br />
<br />
In das [[Konfiguration#Befehl-Eingabefeld|Befehls-Eingabefeld]] eingeben und mit {{Taste|Enter}} bestätigen:<br />
define ntest notify a b<br />
Als Beispiel wird ein notify mit <name> "ntest" angelegt. "a" und "b" sind beliebige Platzhalter für <Suchmuster> und <Command>, die bei der weiteren Bearbeitung mit dem endgültigen Werten ersetzt werden.<br />
Der Regexp wizard öffnet sich:<br />
[[Datei:Regexp wizard1.JPG|400px|thumb|center]]<br />
Nun in der Auswahlbox das auslösende Event (Ereignis) auswählen; zunächst das Device und dann das gewünschte Regex. Hier soll das notify bei jeder Veränderung der Temperatur (temperature.*) des Device BTHR918N reagieren. Abschließend mit einem Mausklick auf {{Taste|set}} bestätigen. Wählt man mehrere Regex in dieser Weise aus, so wird das "notify" bei Eintritt jedes dieser Events ausgeführt:<br />
[[Datei:Regexp wizard2.JPG|400px|thumb|center]]<br />
Anschließend den Platzhalter "a" mit Klick auf den Link "removeRegexpPart" löschen:<br />
[[Datei:Regexp wizard3.JPG|400px|thumb|center]]<br />
Den Link "DEF" anklicken, damit sich der DEF-Editor öffnet:<br />
[[Datei:Regexp wizard4.JPG|400px|thumb|center]]<br />
Jetzt den auszuführenden Befehl im "DEF"-Bereich durch Überschreiben des Platzhalters "b" eintragen und mit Klick auf {{Taste|modify ntest}} abschließen:<br />
[[Datei:Regexp wizard5.JPG|400px|thumb|center]]<br />
Das fertige und sofort aktive "notify" sieht abschließend folgendermaßen aus:<br />
[[Datei:Regexp wizard6.JPG|400px|thumb|center]]<br />
Am Schluss das Speichern über {{Taste|Save config}} nicht vergessen.<br />
<br />
=== Etwas schalten, wenn ein anderes Gerät geschaltet wird ===<br />
Wenn man das obige mit KNX abbilden möchte, benötigt man auf der KNX Seite:<br />
<br />
==== Vorbereitung ====<br />
* Gruppenadresse (GA) für die Steckdose vom Radio (0/0/10)<br />
* GA vom Licht (0/0/20)<br />
<br />
Auf der FHEM Seite wird benötigt:<br />
<br />
define RadioKueche EIB 0/0/10<br />
define LichtKueche EIB 0/0/20<br />
<br />
==== notify Befehl ====<br />
define LichtamRadioan notify LichtKueche { fhem "set RadioKueche $EVENT" } <br />
oder '''besser'''<br />
define LichtamRadioan notify LichtKueche set RadioKueche $EVENT <br />
<br />
==== Erklärung ====<br />
* Der Begriff "LichtamRadioan" ist nur ein Platzhalter, damit das notify in FHEM verwaltet werden kann.<br />
* "$EVENT" ist ein Platzhalter für den Zustand vom Pattern. $EVENT enthält ein "off" wenn das LichtKueche aus ist und ein "on" wenn das Licht eingeschaltet ist.<br />
* "{ &lt;perlcode&gt; }" alles was zwischen {} steht ist Perl code. Perl kennt das Schlüsselwort fhem. Das Schlüsselwort FHEM dient dazu, FHEM Befehle auszuführen. Es wird also der FHEM Befehl "set RadioKueche on/off" ausgeführt. on oder off ist abhängig vom Pattern. Der eigentliche FHEM Befehl muss in " " stehen.<br />
* Warum ist die 2. Variante besser? In der 1. Variante wechselt man von FHEM-Ebene des notify mittels {} auf Perl-Ebene, wo man mit dem Schlüsselwort fhem "" wieder einen Befehl auf FHEM-Ebene ausführt. In der 2. Variante werden diese unnötigen, resourcenverschwendenden Ebenen-Wechsel vermieden. Alles wird auf der FHEM-Ebene ausgeführt.<br />
<br />
=== Einschalten von mehreren Geräten/Lampen, wenn das Licht eingeschaltet wird ===<br />
==== Vorbereitung ====<br />
KNX:<br />
* 3 GAs für drei Geräten bzw Lampen (0/0/30 0/0/31 0/0/32)<br />
<br />
FHEM:<br />
define LichtWZ EIB 0/0/30<br />
define Steckdose1 EIB 0/0/31<br />
define Steckdose2 EIB 0/0/32<br />
<br />
==== notify Befehl ====<br />
define SteckdoseWZein notify LichtWZ { fhem "set Steckdose1 $EVENT;;set Steckdose2 $EVENT " } <br />
oder '''besser'''<br />
define SteckdoseWZein notify LichtWZ set Steckdose1,Steckdose2 $EVENT<br />
<br />
==== Erklärung ====<br />
Wenn das LichtWZ eingeschaltet wird, dann werden auch die Steckdosen (1 und 2) eingeschaltet.<br />
<br />
=== Einfache ODER Funktion ===<br />
Eine einfache ODER Funktion kann sehr einfach realisiert werden<br />
<br />
==== Vorbereitung ====<br />
KNX:<br />
* 3x GAs der abzufragende Werte (0/0/40 0/0/41 0/0/42)<br />
<br />
FHEM:<br />
define Licht1 EIB 0/0/40<br />
define Licht2 EIB 0/0/41<br />
define Steckdose EIB 0/0/42<br />
<br />
==== notify Befehl ====<br />
define SteckdoseWZein notify (Licht1|Licht2) set Steckdose $EVENT <br />
oder<br />
define SteckdoseWZein notify (Licht.) set Steckdose $EVENT<br />
<br />
==== Erklärung ====<br />
Die Werte in der Klammer (wichtig ist das »|«) sind die Rückgabewerte. Alternativ kann in diesem Beispiel auch »Licht.« (zu beachten ist der Punkt) geschrieben werden. Der Punkt ist ein Platzhalter für (genau) ein beliebiges Zeichen.<br />
<br />
Danach folgt der set Befehl.<br />
Wenn also das Licht1 oder Licht2 den Wert "on" hat, dann hat auch die Steckdose den Wert "on"<br />
<br />
Alternative: [[structure]]<br />
<br />
=== Einfache UND Funktion ===<br />
Ob man dieses Konstrukt noch als einfach bezeichnen kann, wage ich mal zu bezeifeln. In FHEM fehlen Loggingfunktionen, die man alle selber mit Perl Code erstellen kann (Danke an MAZ).<br />
Dadurch ist FHEM zwar mächtig, wird aber für viele sehr kompliziert.<br />
<br />
In diesem Beispiel soll - wenn drei Rollos geschlossen sind - am Taster eine LED eingeschaltet werden.<br />
<br />
==== Vorbereitung ====<br />
KNX:<br />
* 3x GDs für die Rückgabewert Rollo geschlossen == 1 (0/0/50 0/0/51 0/0/52)<br />
* GD LED am Lichtschalter (0/0/106)<br />
<br />
FHEM:<br />
define R1ZU EIB 0/0/50<br />
attr R1ZU dummy 1<br />
define R2ZU EIB 0/0/51<br />
attr R2ZU dummy 1<br />
define R3ZU EIB 0/0/52<br />
attr R3ZU dummy 1<br />
define LEDalleRolloZu EIB 0/0/106<br />
Durch das Atribut dummy werden keine Schaltfunktion angeboten. Es kann nur Werte anzeigen.<br />
<br />
==== notify Befehl ====<br />
define nt.allerolloszu notify (R1ZU|R2ZU|R3ZU) {<br />
my $r1 = Value("R1ZU");;<br />
my $r2 = Value("R2ZU");;<br />
my $r3 = Value("R3ZU");;<br />
if ($r1 eq "on" &amp;&amp; $r2 eq "on" &amp;&amp; $r3 eq "on") {<br />
fhem "set LEDalleRolloZu on"<br />
} else {<br />
fhem "set LEDalleRolloZu off"<br />
}<br />
}<br />
<br />
==== Erklärung ====<br />
Es werden die drei Rückgabewerte R1ZU, R2ZU und R3ZU ausgewertet. Danach folgt Perl Code, deswegen beginnt das ganze mit einer { und endet mit }<br />
<br />
my $r1 =&gt; Variable $r1 definieren<br />
= Value("R1ZU");; ==&gt; weist den Rückgabewert (on oder off) von R1ZU der Variable $r1 zu <br />
<br />
Der doppelte ;; ist ein FHEM Thema. Eigentlich würde für Perl ein ; reichen. Aber FHEM nutzt selbst das ; und daher wird ein ;; benötigt. Mit den ersten drei my Zeilen werden die Rückgabewerte den Variabeln zugewiesen.<br />
<br />
Danach erfolgt ein normales "if then else" Konstrukt. Die Zeile »($r1 eq "on" &amp;&amp; $r2 eq "on" &amp;&amp; $r3 eq "on")«&#160;kann man so lesen: Wenn $r1 den Wert "on" und (&amp;&amp;) $r2 den Wert "on" und $r3 den Wert "on" dann schalte die LEDalleRolloZu ein {fhem("set LEDalleRolloZu on")}<br />
ansonsten else schalte die LED aus. {fhem("set LEDalleRolloZu off")<br />
<br />
Alternative: [[structure]]<br />
<br />
=== Zeitverzögert schalten ===<br />
{| class="wikitable"<br />
| '''Aufgabe:''' || Zeitverzögert schalten<br />
|- <br />
| '''Beschreibung:''' || Mit einem Notify zeitverzögert eine Aktion auslösen.<br />
|- <br />
| '''Vorbereitung:''' || Gerät "Lampe" ist definiert und es gibt eine Situation, die ein Ereignis "Fernbedienung:.*" generiert.<br />
|-<br />
| '''Befehl:''' || <code>define ntfy1 notify Fernbedienung:.* sleep 7.5;; set Lampe $EVENT</code><br />
|-<br />
| '''Erläuterungen:''' || Bei Eintreten eines Ereignisses "Fernbedienung*" wird nach einer Pause von siebeneinhalb Sekunden der Befehl <set Lampe ??> ausgeführt, wobei der eigentliche Befehl aus dem auslösenden Ereignis übernommen wird.<br />
:''Quelle: [http://forum.fhem.de/index.php/topic,17161.0.html FHEM Forum]''<br />
|}<br />
<br />
<br />
=== Eine PV-Anlage (Solarstrom) zur Steuerung der Rollos nutzen (optional Zeit und Datums abhängig) ===<br />
Hier ein kleines Beispiel, wie man mit Hilfe einer PV-Anlage die Sonneneinstrahlung auf der Südseite ermittelt und dies zur Rolladensteuerung nutzt.<br />
Optional: Die Funktion soll allerdings nur zwischen 9:30 und 17:00 stattfinden. (zweites Beispiel)<br />
Optional: Die Funktion soll nur zwischen dem 6. und 9. Monat funktioneren. (drittes Beispiel)<br />
<br />
==== Vorbereitung ====<br />
PV Anlage mit SolarView abfragen.<br />
Per Hand ermitteln, ab wieviel erzeugtem Strom es sinnvoll ist die Rollos zu schließen.<br />
<br />
==== notify Syntax ====<br />
FHEM:<br />
<br />
define sv SolarView solarview 15000 wr1 wr2 wr3 wr4 <----vier Wechselrichter<br />
attr sv event-on-change-reading currentPower <br />
<br />
define nt.sonnenlichtpersolar notify (sv:currentPower.*) { <br />
if ($EVTPART1 &lt; 3000 ) {<br />
fhem('set Flur1 Auf');<br />
}else {<br />
if ($EVTPART1 &gt; 5000 ) {<br />
fhem('set Flur1 Ab');<br />
} <br />
}<br />
}<br />
<br />
Optional 1: Zeitabhängig<br />
<br />
(sv:currentPower.*) { <br />
my $hm = sprintf("%02d:%02d", $hour, $min);<br />
if ( $hm gt "09:30" &amp;&amp; $hm lt "17:00") { <br />
if ($EVTPART1 &lt; 5000 ) {<br />
fhem('set Flur1 Auf');<br />
}else {<br />
if ($EVTPART1 &gt; 8000 ) {<br />
fhem('set Flur1 Ab');<br />
} <br />
}<br />
}<br />
}<br />
<br />
Optional 2: Zeit und Datum<br />
<br />
(sv:currentPower.*) { <br />
my $hm = sprintf("%02d:%02d", $hour, $min);<br />
if ($month >= 6 &amp;&amp; $month <= 9) {<br />
if ( $hm gt "09:30" &amp;&amp; $hm lt "17:00") { <br />
if ($EVTPART1 &lt; 5000 ) {<br />
fhem('set Flur1,RBUERO1,RBUERO2 Auf');<br />
}else {<br />
if ($EVTPART1 &gt; 8000 ) {<br />
fhem('set Flur1,Flur2,RBUERO1,RBUERO2 Ab');<br />
} <br />
}<br />
}<br />
}<br />
}<br />
<br />
==== Erklärung ====<br />
* Das define wird in der Kommandozeile im Webbrowser eingegeben.<br />
* Anschliessend wird im Webbrowser die DEF bearbeitet, das erspart uns Probleme mit Perl<br />
* define sv SolarView ... <==== ist die Schnittstelle vom SolarView<br />
* define nt.sonnenlichtpersolar notify (sv:currentPower.*) { <==== hier wird ein notify angelegt, der auf das "define sv" Wert "currentPower.*" (.* ist irgendwas) reagiert<br />
if ($EVTPART1 &lt; 3000 ) {<br />
fhem('set Flur1 Auf');<br />
}else {<br />
if ($EVTPART1 &gt; 5000 ) {<br />
fhem('set Flur1 Ab');<br />
} <br />
}<br />
}<br />
Diese if-Funktion wertet den Rückgabewert von currentPower aus. Hierbei muss man wissen, dass $EVTPART1 das Splitergebnis vom Rückgabewert ist<br />
<br />
Beispiel: Der Rückgabewert (wie im Beispiel) ist "currentPower: 6000".<br />
Jetzt steht im "$EVTPART0 == currentPower:" und im "$EVTPART1 == 6000"<br />
Das bedeutet, dass man sich nicht selbst den richtigen split (Perl Befehl) Aufruf ausdenken muss, dies übernimmt vielmehr FHEM.<br />
<br />
Ergebnis: <br />
Das Rollo wird abhängig von der erzeugten IST_Strommenge auf und zu gefahren.<br />
Damit dies nicht dauernd hin und her pendelt, wurde der Auf Wert sehr klein und den Ab Wert sehr groß gewählt.<br />
<br />
'''Optional 1:''' Der Block "my $hm = sprintf("%02d:%02d", $hour, $min);" erzeugt die String-Variable $hm mit dem Inhalt $hour:$min. %02d begrenzt die Ausgabe auf zwei Stellen.<br />
Danach wird mit "if ( $hm gt "09:30" && $hm lt "17:00")" mit stringvergleichende Operatoren geprüft, ob die Uhrzeit zwischen 9:30 und 17:00 liegt (lt = kleiner als; gt = größer als). Es wäre auch ein le und ge möglich: le = kleiner/gleich als, ge = größer/gleich als.<br />
<br />
'''Optional 2:'''if( $month >= 6 && $month <= 9) {<br />
<br />
Hier wird die numerische FHEM-Standard-Variable $month (Monat) auf größer/gleich bzw kleiner/gleich mit den binären Operatoren überprüft.<br />
Die Funktion arbeitet also nur zwischen dem 6. und dem 9. Monat und dann auch nur zwischen 9:31 und 16:59.<br />
<br />
=== Hinweise ===<br />
* Entsprechend zu $EVENT gibt es auch noch $NAME und $TYPE. $NAME und $TYPE enthalten den Namen bzw. Typ des Ereignis auslösenden Gerätes.<br />
* Wird der Perl-Code in einem <code>notify</code> immer länger, lagere den Code wegen der Übersichtlichkeit in eine eigene Programmdatei aus, wie in [[99_myUtils anlegen]] beschrieben.<br />
* Achtung! Wenn man das Skript für den notify-Befehl über mehrere Zeilen schreibt, muss man anscheinend darauf achten, dass keine abschliessende Leerzeile mitgespeichert wird. Sonst wird der notify-Befehl ignoriert.<br />
* Dieser {{Link2Forum|Topic=38520|Message=307325}} enthält Vorschläge zur Vorgehensweise bei der Erstellung von komplexen ''notify'' Definitionen bzw. bei deren Fehlerbehebung.<br />
<br />
== Weiterführende Links ==<br />
* [[Escapen in Perlbefehlen]]<br />
* [[Klammerebenen]]<br />
* [[DOIF]] als Alternative<br />
<br />
[[Kategorie:HOWTOS]]<br />
[[Kategorie:Hilfsmodul]]</div>MGuhttp://wiki.fhem.de/w/index.php?title=Smartwares&diff=20521Smartwares2017-03-04T12:57:26Z<p>MGu: /* Bezugsquellen */</p>
<hr />
<div>{{Todo|Ausbauen, Struktur an FHEMWiki-Standard anpassen, IT-Komponente?}}<br />
<br />
{{Hinweis|Vorsicht: Es gibt nur wenige Infos zur Einsetzbarkeit der Komponenten mit FHEM}}<br />
<br />
Unter der Markenbezeichnung [[Smartwares]] werden verschiedenste Funkkomponenten für die Hausautomation vermarktet. Eine Übersicht bietet die [http://www.smartwaressafetylighting.eu/en-us/search?q=SH5 Internetseite von Smartwares]. Die Funkkomponenten arbeiten mit 433,92 MHz<br />
<br />
== Features ==<br />
=== Modelle ===<br />
* SH5-RBS-10A Einbau Funkschalter, max. 1000 Watt<br />
* SH5-RPS-36A Schuko Funkschalter, max. 3600 Watt (kann wie jede IT Funksteckdose angelernt werden) <br />
* SH5-TBD-02A Einbau Dimmer; max. 200 Watt<br />
* SH5-TSW-B Flacher Aufputz Doppeltaster<br />
* SH5-TSM-A Türsensor / Fensterkontakt<br />
* SH5-TDR-K Schlüsselanhänger-Fernbedienung<br />
<br />
=== Bezugsquellen ===<br />
Die Smartware Funkkomponenten gibt es in Baumaerkten, beispielsweise bei Obi. Zudem sind sie beispielsweise auch bei [https://www.conrad.de/de/smartwares-sh5-rbs-10a-funk-schalter-reichweite-max-im-freifeld-50-m-1399742.html Conrad] oder [http://www.elv.de/smartwares-smart-home-funk-einbauschalter-sh5-rbs-10a-fuer-smart-home-hausautomation.html Elv] erhältlich.<br />
<br />
== Hinweise zum Betrieb mit FHEM ==<br />
Es gibt kein Modul zur Unterstützung der Smartwares-Funkkomponenten. Bisher ist in FHEM nur in diesem {{Link2Forum|Topic=51206|Message=428529}} über eine Einbindung einer Smartwares-Funkkomponente in FHEM berichtet worden. Bei einem geplanten Einsatz in FHEM sollte man sich daher genau informieren, ob die gewünschte Komponente überhaupt mit FHEM nutzbar ist.<br />
Einige smartwares Komponenten sind vom Kommunikationsverhalten einfach [[Intertechno_Code_Berechnung#Selbstlernende_Intertechno_Funksteckdosen_.28z.B._ITR-1500.29|Intertechno V3]] Geräte (z.B. SH5-RPS-36A).<br />
<br />
=== Pairing ===<br />
Das Pairing zwischen Empfänger und Sender erfolgt durch aktivieren des Pairing Mode im Empfänger (Drucktaster 3 sec halten) und danach normales Drücken des Tasters auf der Sender Seite (z.B. Schalter)<br />
Es können wohl pro Empfänger(Dimmer, Relais, ...) maximal 6 Sender gleichzeitig angelernt werden. Ein Schalter kann auf beliebig viele Empfänger angelernt werden.<br />
Das Pairing kann durch halten der Pairingtaste von 10 sec. komplett gelöscht werden.<br />
<br />
==== Probleme ====<br />
Funktioniert das Pairing nicht, kann das verschiedene Ursachen haben.<br />
# Die smartwares Funksteckdosen mit Taster erfordern etwas Übung um in den Pairing-Betrieb zu gelangen. Die Taste schaltet bei kurzer Betätigung das Relais ein und aus. Bei 3 Sekunden Betätigung leuchtet mit dem Loslassen die LED und fängt an langsam zu blinken. Wenn die LED einfach an bleibt hat man zu kurz gedrückt. Bei smartwares kann "kurz" durchaus bis 2s sein. Blinkt die LED ist das der Pairing-Betrieb. Nach erfolgreichem Pairing blinkt die LED kurz schneller und erlöscht oder das Gerät und die LED schalten dauerhaft ein. Hält man die Taste zu lange (>10s), so dass schon wären der Betätigung die LED an geht, hat man alle bisherigen Pairings gelöscht.<br />
# Ein zweites Problem ist die Frequenzgenauigkeit der Geräte. Es hilft ggf. die Sendefrequenz des CUL zu verändert. Bei einem meiner Geräte war das Pairing erst nach <code>set CUL0 freq 433.910</code> möglich. Damit wird 10kHz tiefer als in der Voreinstellung gesendet. Das Problem mit der Sendefrequenz ist nicht speziell bei smartware sondern auch bei anderen IT Geräten. Man kann eine 3er Packung kaufen und zwei tun und der dritte erst nach Änderung der Frequenz. Das scheint eine Fertigungstoleranz zu sein.<br />
<br />
== Links ==<br />
<br />
[[Kategorie:Other Components]]</div>MGuhttp://wiki.fhem.de/w/index.php?title=Smartwares&diff=20520Smartwares2017-03-04T12:57:03Z<p>MGu: /* Hinweise zum Betrieb mit FHEM */</p>
<hr />
<div>{{Todo|Ausbauen, Struktur an FHEMWiki-Standard anpassen, IT-Komponente?}}<br />
<br />
{{Hinweis|Vorsicht: Es gibt nur wenige Infos zur Einsetzbarkeit der Komponenten mit FHEM}}<br />
<br />
Unter der Markenbezeichnung [[Smartwares]] werden verschiedenste Funkkomponenten für die Hausautomation vermarktet. Eine Übersicht bietet die [http://www.smartwaressafetylighting.eu/en-us/search?q=SH5 Internetseite von Smartwares]. Die Funkkomponenten arbeiten mit 433,92 MHz<br />
<br />
== Features ==<br />
=== Modelle ===<br />
* SH5-RBS-10A Einbau Funkschalter, max. 1000 Watt<br />
* SH5-RPS-36A Schuko Funkschalter, max. 3600 Watt (kann wie jede IT Funksteckdose angelernt werden) <br />
* SH5-TBD-02A Einbau Dimmer; max. 200 Watt<br />
* SH5-TSW-B Flacher Aufputz Doppeltaster<br />
* SH5-TSM-A Türsensor / Fensterkontakt<br />
* SH5-TDR-K Schlüsselanhänger-Fernbedienung<br />
<br />
=== Bezugsquellen ===<br />
Die Smartware Funkkomponenten gibt es in Baumaerkten, beispielsweise bei Obi. Zudem sind sie beispielsweise auch bei [https://www.conrad.de/de/smartwares-sh5-rbs-10a-funk-schalter-reichweite-max-im-freifeld-50-m-1399742.html Conrad] oder [http://www.elv.de/smartwares-smart-home-funk-einbauschalter-sh5-rbs-10a-fuer-smart-home-hausautomation.html Elv] erhaeltlich.<br />
<br />
== Hinweise zum Betrieb mit FHEM ==<br />
Es gibt kein Modul zur Unterstützung der Smartwares-Funkkomponenten. Bisher ist in FHEM nur in diesem {{Link2Forum|Topic=51206|Message=428529}} über eine Einbindung einer Smartwares-Funkkomponente in FHEM berichtet worden. Bei einem geplanten Einsatz in FHEM sollte man sich daher genau informieren, ob die gewünschte Komponente überhaupt mit FHEM nutzbar ist.<br />
Einige smartwares Komponenten sind vom Kommunikationsverhalten einfach [[Intertechno_Code_Berechnung#Selbstlernende_Intertechno_Funksteckdosen_.28z.B._ITR-1500.29|Intertechno V3]] Geräte (z.B. SH5-RPS-36A).<br />
<br />
=== Pairing ===<br />
Das Pairing zwischen Empfänger und Sender erfolgt durch aktivieren des Pairing Mode im Empfänger (Drucktaster 3 sec halten) und danach normales Drücken des Tasters auf der Sender Seite (z.B. Schalter)<br />
Es können wohl pro Empfänger(Dimmer, Relais, ...) maximal 6 Sender gleichzeitig angelernt werden. Ein Schalter kann auf beliebig viele Empfänger angelernt werden.<br />
Das Pairing kann durch halten der Pairingtaste von 10 sec. komplett gelöscht werden.<br />
<br />
==== Probleme ====<br />
Funktioniert das Pairing nicht, kann das verschiedene Ursachen haben.<br />
# Die smartwares Funksteckdosen mit Taster erfordern etwas Übung um in den Pairing-Betrieb zu gelangen. Die Taste schaltet bei kurzer Betätigung das Relais ein und aus. Bei 3 Sekunden Betätigung leuchtet mit dem Loslassen die LED und fängt an langsam zu blinken. Wenn die LED einfach an bleibt hat man zu kurz gedrückt. Bei smartwares kann "kurz" durchaus bis 2s sein. Blinkt die LED ist das der Pairing-Betrieb. Nach erfolgreichem Pairing blinkt die LED kurz schneller und erlöscht oder das Gerät und die LED schalten dauerhaft ein. Hält man die Taste zu lange (>10s), so dass schon wären der Betätigung die LED an geht, hat man alle bisherigen Pairings gelöscht.<br />
# Ein zweites Problem ist die Frequenzgenauigkeit der Geräte. Es hilft ggf. die Sendefrequenz des CUL zu verändert. Bei einem meiner Geräte war das Pairing erst nach <code>set CUL0 freq 433.910</code> möglich. Damit wird 10kHz tiefer als in der Voreinstellung gesendet. Das Problem mit der Sendefrequenz ist nicht speziell bei smartware sondern auch bei anderen IT Geräten. Man kann eine 3er Packung kaufen und zwei tun und der dritte erst nach Änderung der Frequenz. Das scheint eine Fertigungstoleranz zu sein.<br />
<br />
== Links ==<br />
<br />
[[Kategorie:Other Components]]</div>MGuhttp://wiki.fhem.de/w/index.php?title=Smartwares&diff=20519Smartwares2017-03-04T12:52:04Z<p>MGu: /* Probleme */</p>
<hr />
<div>{{Todo|Ausbauen, Struktur an FHEMWiki-Standard anpassen, IT-Komponente?}}<br />
<br />
{{Hinweis|Vorsicht: Es gibt nur wenige Infos zur Einsetzbarkeit der Komponenten mit FHEM}}<br />
<br />
Unter der Markenbezeichnung [[Smartwares]] werden verschiedenste Funkkomponenten für die Hausautomation vermarktet. Eine Übersicht bietet die [http://www.smartwaressafetylighting.eu/en-us/search?q=SH5 Internetseite von Smartwares]. Die Funkkomponenten arbeiten mit 433,92 MHz<br />
<br />
== Features ==<br />
=== Modelle ===<br />
* SH5-RBS-10A Einbau Funkschalter, max. 1000 Watt<br />
* SH5-RPS-36A Schuko Funkschalter, max. 3600 Watt (kann wie jede IT Funksteckdose angelernt werden) <br />
* SH5-TBD-02A Einbau Dimmer; max. 200 Watt<br />
* SH5-TSW-B Flacher Aufputz Doppeltaster<br />
* SH5-TSM-A Türsensor / Fensterkontakt<br />
* SH5-TDR-K Schlüsselanhänger-Fernbedienung<br />
<br />
=== Bezugsquellen ===<br />
Die Smartware Funkkomponenten gibt es in Baumaerkten, beispielsweise bei Obi. Zudem sind sie beispielsweise auch bei [https://www.conrad.de/de/smartwares-sh5-rbs-10a-funk-schalter-reichweite-max-im-freifeld-50-m-1399742.html Conrad] oder [http://www.elv.de/smartwares-smart-home-funk-einbauschalter-sh5-rbs-10a-fuer-smart-home-hausautomation.html Elv] erhaeltlich.<br />
<br />
== Hinweise zum Betrieb mit FHEM ==<br />
Es gibt kein Modul zur Unterstützung der Smartwares-Funkkomponenten. Bisher ist in FHEM nur in diesem {{Link2Forum|Topic=51206|Message=428529}} über eine Einbindung einer Smartwares-Funkkomponente in FHEM berichtet worden. Bei einem geplanten Einsatz in FHEM sollte man sich daher genau informieren, ob die gewünschte Komponente überhaupt mit FHEM nutzbar ist.<br />
<br />
=== Pairing ===<br />
Das Pairing zwischen Empfänger und Sender erfolgt durch aktivieren des Pairing Mode im Empfänger (Drucktaster 3 sec halten) und danach normales Drücken des Tasters auf der Sender Seite (z.B. Schalter)<br />
Es können wohl pro Empfänger(Dimmer, Relais, ...) maximal 6 Sender gleichzeitig angelernt werden. Ein Schalter kann auf beliebig viele Empfänger angelernt werden.<br />
Das Pairing kann durch halten der Pairingtaste von 10 sec. komplett gelöscht werden.<br />
<br />
==== Probleme ====<br />
Funktioniert das Pairing nicht, kann das verschiedene Ursachen haben.<br />
# Die smartwares Funksteckdosen mit Taster erfordern etwas Übung um in den Pairing-Betrieb zu gelangen. Die Taste schaltet bei kurzer Betätigung das Relais ein und aus. Bei 3 Sekunden Betätigung leuchtet mit dem Loslassen die LED und fängt an langsam zu blinken. Wenn die LED einfach an bleibt hat man zu kurz gedrückt. Bei smartwares kann "kurz" durchaus bis 2s sein. Blinkt die LED ist das der Pairing-Betrieb. Nach erfolgreichem Pairing blinkt die LED kurz schneller und erlöscht oder das Gerät und die LED schalten dauerhaft ein. Hält man die Taste zu lange (>10s), so dass schon wären der Betätigung die LED an geht, hat man alle bisherigen Pairings gelöscht.<br />
# Ein zweites Problem ist die Frequenzgenauigkeit der Geräte. Es hilft ggf. die Sendefrequenz des CUL zu verändert. Bei einem meiner Geräte war das Pairing erst nach <code>set CUL0 freq 433.910</code> möglich. Damit wird 10kHz tiefer als in der Voreinstellung gesendet. Das Problem mit der Sendefrequenz ist nicht speziell bei smartware sondern auch bei anderen IT Geräten. Man kann eine 3er Packung kaufen und zwei tun und der dritte erst nach Änderung der Frequenz. Das scheint eine Fertigungstoleranz zu sein.<br />
<br />
== Links ==<br />
<br />
[[Kategorie:Other Components]]</div>MGuhttp://wiki.fhem.de/w/index.php?title=Smartwares&diff=20518Smartwares2017-03-04T12:14:56Z<p>MGu: /* Pairing */ Pairing mit Hürden</p>
<hr />
<div>{{Todo|Ausbauen, Struktur an FHEMWiki-Standard anpassen, IT-Komponente?}}<br />
<br />
{{Hinweis|Vorsicht: Es gibt nur wenige Infos zur Einsetzbarkeit der Komponenten mit FHEM}}<br />
<br />
Unter der Markenbezeichnung [[Smartwares]] werden verschiedenste Funkkomponenten für die Hausautomation vermarktet. Eine Übersicht bietet die [http://www.smartwaressafetylighting.eu/en-us/search?q=SH5 Internetseite von Smartwares]. Die Funkkomponenten arbeiten mit 433,92 MHz<br />
<br />
== Features ==<br />
=== Modelle ===<br />
* SH5-RBS-10A Einbau Funkschalter, max. 1000 Watt<br />
* SH5-RPS-36A Schuko Funkschalter, max. 3600 Watt (kann wie jede IT Funksteckdose angelernt werden) <br />
* SH5-TBD-02A Einbau Dimmer; max. 200 Watt<br />
* SH5-TSW-B Flacher Aufputz Doppeltaster<br />
* SH5-TSM-A Türsensor / Fensterkontakt<br />
* SH5-TDR-K Schlüsselanhänger-Fernbedienung<br />
<br />
=== Bezugsquellen ===<br />
Die Smartware Funkkomponenten gibt es in Baumaerkten, beispielsweise bei Obi. Zudem sind sie beispielsweise auch bei [https://www.conrad.de/de/smartwares-sh5-rbs-10a-funk-schalter-reichweite-max-im-freifeld-50-m-1399742.html Conrad] oder [http://www.elv.de/smartwares-smart-home-funk-einbauschalter-sh5-rbs-10a-fuer-smart-home-hausautomation.html Elv] erhaeltlich.<br />
<br />
== Hinweise zum Betrieb mit FHEM ==<br />
Es gibt kein Modul zur Unterstützung der Smartwares-Funkkomponenten. Bisher ist in FHEM nur in diesem {{Link2Forum|Topic=51206|Message=428529}} über eine Einbindung einer Smartwares-Funkkomponente in FHEM berichtet worden. Bei einem geplanten Einsatz in FHEM sollte man sich daher genau informieren, ob die gewünschte Komponente überhaupt mit FHEM nutzbar ist.<br />
<br />
=== Pairing ===<br />
Das Pairing zwischen Empfänger und Sender erfolgt durch aktivieren des Pairing Mode im Empfänger (Drucktaster 3 sec halten) und danach normales Drücken des Tasters auf der Sender Seite (z.B. Schalter)<br />
Es können wohl pro Empfänger(Dimmer, Relais, ...) maximal 6 Sender gleichzeitig angelernt werden. Ein Schalter kann auf beliebig viele Empfänger angelernt werden.<br />
Das Pairing kann durch halten der Pairingtaste von 10 sec. komplett gelöscht werden.<br />
<br />
==== Probleme ====<br />
Funktioniert das Pairing nicht, kann das verschiedene Ursachen haben.<br />
# Die smartwares Funksteckdosen mit Taster erfordern etwas Übung um in den Pairing-Betrieb zu gelangen. Die Taste schaltet bei kurzer Betätigung das Relais ein und aus. Bei 3 Sekunden Betätigung leuchtet mit dem Loslassen die LED und fängt an langsam zu blinken. Das ist der Pairing-Betrieb. Nach erfolgreichem Pairing blinkt die LED kurz schneller und erlöscht oder das Gerät und die LED schalten dauerhaft ein. Hält man die Taste zu lange (>10s), so dass schon wären der Betätigung die LED an geht, hat man alle bisherigen Pairings gelöscht.<br />
# Ein zweites Problem ist die Frequenzgenauigkeit der Geräte. Es hilft ggf. die Sendefrequenz des CUL zu verändert. Bei einem meiner Geräte war das Pairing erst nach <code>set CUL0 freq 433.910</code> möglich. Damit wird 10kHz tiefer als in der Voreinstellung gesendet. Das Problem mit der Sendefrequenz ist nicht speziell bei smartware sondern auch bei anderen IT Geräten. Man kann eine 3er Packung kaufen und zwei tun und der dritte erst nach Änderung der Frequenz. Das scheint eine Fertigungstoleranz zu sein.<br />
<br />
== Links ==<br />
<br />
[[Kategorie:Other Components]]</div>MGuhttp://wiki.fhem.de/w/index.php?title=Smartwares&diff=20517Smartwares2017-03-04T12:02:15Z<p>MGu: /* Modelle */ Neues Modell eingefügt</p>
<hr />
<div>{{Todo|Ausbauen, Struktur an FHEMWiki-Standard anpassen, IT-Komponente?}}<br />
<br />
{{Hinweis|Vorsicht: Es gibt nur wenige Infos zur Einsetzbarkeit der Komponenten mit FHEM}}<br />
<br />
Unter der Markenbezeichnung [[Smartwares]] werden verschiedenste Funkkomponenten für die Hausautomation vermarktet. Eine Übersicht bietet die [http://www.smartwaressafetylighting.eu/en-us/search?q=SH5 Internetseite von Smartwares]. Die Funkkomponenten arbeiten mit 433,92 MHz<br />
<br />
== Features ==<br />
=== Modelle ===<br />
* SH5-RBS-10A Einbau Funkschalter, max. 1000 Watt<br />
* SH5-RPS-36A Schuko Funkschalter, max. 3600 Watt (kann wie jede IT Funksteckdose angelernt werden) <br />
* SH5-TBD-02A Einbau Dimmer; max. 200 Watt<br />
* SH5-TSW-B Flacher Aufputz Doppeltaster<br />
* SH5-TSM-A Türsensor / Fensterkontakt<br />
* SH5-TDR-K Schlüsselanhänger-Fernbedienung<br />
<br />
=== Bezugsquellen ===<br />
Die Smartware Funkkomponenten gibt es in Baumaerkten, beispielsweise bei Obi. Zudem sind sie beispielsweise auch bei [https://www.conrad.de/de/smartwares-sh5-rbs-10a-funk-schalter-reichweite-max-im-freifeld-50-m-1399742.html Conrad] oder [http://www.elv.de/smartwares-smart-home-funk-einbauschalter-sh5-rbs-10a-fuer-smart-home-hausautomation.html Elv] erhaeltlich.<br />
<br />
== Hinweise zum Betrieb mit FHEM ==<br />
Es gibt kein Modul zur Unterstützung der Smartwares-Funkkomponenten. Bisher ist in FHEM nur in diesem {{Link2Forum|Topic=51206|Message=428529}} über eine Einbindung einer Smartwares-Funkkomponente in FHEM berichtet worden. Bei einem geplanten Einsatz in FHEM sollte man sich daher genau informieren, ob die gewünschte Komponente überhaupt mit FHEM nutzbar ist.<br />
<br />
=== Pairing ===<br />
Das Pairing zwischen Empfänger und Sender erfolgt durch aktivieren des Pairing Mode im Empfänger (Drucktaster 3 sec halten) und danach normales Drücken des Tasters auf der Sender Seite (z.B. Schalter)<br />
Es können wohl pro Empfänger(Dimmer, Relais, ...) maximal 6 Sender gleichzeitig angelernt werden. Ein Schalter kann auf beliebig viele Empfänger angelernt werden.<br />
Das Pairing kann durch halten der Pairingtaste von 10 sec. komplett gelöscht werden.<br />
<br />
== Links ==<br />
<br />
[[Kategorie:Other Components]]</div>MGuhttp://wiki.fhem.de/w/index.php?title=Proteus_EcoMeter&diff=20486Proteus EcoMeter2017-03-03T13:33:16Z<p>MGu: /* Eventmonitorbeispiel */</p>
<hr />
<div>[[Proteus_EcoMeter]] ist ein Ultraschallsensor mit Monitor zur Pegelmessung von Heizöl- oder Wassertanks<br />
<br />
* Sensor zum Einbau in den Tank<br />
* Funkverbindung zwischen Sensor und Monitor<br />
* USB-Verbindung zwischen Monitor und FHEM<br />
* Für Wasser oder Öltanks<br />
<br />
EcoMeter für Heizöltanks<br><br />
EcoMeter S für Wassertanks<br><br />
<br />
{{Infobox Hardware<br />
|Bild=platzHalter.png<br />
|Bildbeschreibung=todo<br />
|HWProtocol=unknown<br />
|HWType=Sensor und Sender<br />
|HWCategory=Other Components<br />
|HWComm=Funk, 433,92MHz, USB<br />
|HWChannels=unknown<br />
|HWVoltage=1,5V LR2450, 5V USB<br />
|HWPowerConsumption=unknown<br />
|HWPoweredBy=Battery, USB<br />
|HWSize=21 x 18 x 6 cm<br />
|HWDeviceFHEM=[http://fhem.de/commandref.html#TEK603 TEK603]<br />
|HWManufacturer=Tekelek<br />
}}<br />
== Features ==<br />
EcoMeter liefert alle 60 Minuten einen Messwert<br />
EcoMeter liefert alle 30 Minuten einen Messwert und bei schnellen Änderungen<br />
<br />
== Hinweise zum Betrieb mit FHEM ==<br />
=== Definition/Anlernvorgang ===<br />
# eventuell im Linux fehlende Pakete installieren <code>sudo apt-get install libdigest-crc-perl </code><br />
# Monitor an das FHEM Gerät anschließen<br />
# Festellen, dass die Verbindung geht. Dazu auf der Kommandozeile eingeben: <code>ls -al /dev/serial/by-id <br> lrwxrwxrwx 1 root root 13 Jan 1 1970 usb-Silicon_Labs_CP2102_USB_to_UART_Bridge_Controller_0001-if00-port0 -> ../../ttyUSB0 </code> <br />
# ecometer definieren <code>define ecometer TEK603 /dev/serial/by-id/usb-Silicon_Labs_CP2102_USB_to_UART_Bridge_Controller_0001-if00-port0 </code><br />
# LogFile definieren <code>define FileLog_ecometer FileLog %Lecometer-%Y.log ecometer.* </code><br />
# Gerät wie in der Betriebsanleitung installieren<br />
<br />
=== Identifikation ===<br />
Das Proteus EcoMeter verwendet für die Anbindung der seriellen Kommunikation an die USB-Schnittstelle einen sehr weit verbreiteten Chip der Familie <code>CP210x UART Bridges</code>. Dieser Baustein hat die USB <code>ID 10c4:ea60</code> über die auch der Name in <code>/dev/serial/by-id</code> abgeleitet wird. Hat man mehrere Geräte die mit diesem Chip arbeiten (z.B. den optischen Adapter von Viessmann für [[Vitotronic_200_(Viessmann_Heizungssteuerung)|VCONTROL]]) am gleichen Rechner, so werden diese unter <code>lsusb</code> mit identischer ID gelistet, aber nur einer erhält den passenden Namen unter <code>/dev/serial/by-id</code>. Sie sind also auf diese Weise nicht unterscheidbar. Die kurzen Gerätenamen <code>/dev/ttyUSBx</code> werden willkürlich zugeordnet. Damit sind die Geräte auch nicht unterscheidbar.<br />
<br />
Bleibt noch der Pfad wenn man die Geräte immer in die gleiche Buchse steckt. Diese Pfade werden unter Linux in <code>/dev/serial/by-path</code> angelegt. Hier kann man einzelne Buchsen (auch von Hubs) identifizieren. Die Namen enthalten jedoch Doppelpunkte und FHEM verkraftet keine Gerätenamen mit Doppelpunkten. <small>''Wer weiß warum bitte hier Lösung eintragen.''</small> Um diese ohnehin unhandlichen Namen kürzer und verträglicher zu bekommen, kann man Symbolische Links anlegen. Dazu erzeugt man am besten in <code>/opt/fhem</code> ein Verzeichnis <code>dev</code> und verlinkt alle für FHEM relevanten Geräte dort hin. Also in meinem Beispiel TEK603 und VCONTROL:<br />
<source lang=bash><br />
cd /opt/fhem<br />
mkdir dev<br />
cd dev<br />
ln -s /dev/serial/by-path/pci-0000:00:14.0-usb-0:4.3:1.0-port0 heizung<br />
ln -s /dev/serial/by-path/pci-0000:00:14.0-usb-0:4.2:1.0-port0 oelpegel<br />
</source><br />
Solange man die beiden Geräte immer in die gleiche Buchse steckt, werden sie ab jetzt immer korrekt zugeordnet:<br />
<source lang=text><br />
defmod Oelpegel TEK603 /opt/fhem/dev/oelpegel<br />
defmod Heizung VCONTROL /opt/fhem/dev/heizung /opt/fhem/mycfg/vitoladens_300-C_J3Ra-24.cfg 120<br />
</source><br />
<br />
=== FHEM Config-Auszug ===<br />
Ein exemplarischer Auszug aus der [[Konfiguration]]:<br />
define ecometer TEK603 /dev/serial/by-id/usb-Silicon_Labs_CP2102_USB_to_UART_Bridge_Controller_0001-if00-port0<br />
define FileLog_ecometer FileLog %Lecometer-%Y.log ecometer.*<br />
<br />
=== Eventmonitorbeispiel ===<br />
<source lang=text><br />
2017-03-03_13:07:11 Oelpegel CONNECTED<br />
2017-03-03_13:08:27 Oelpegel Time: 13:05:21<br />
2017-03-03_13:08:27 Oelpegel Temperature: 18.33<br />
2017-03-03_13:08:27 Oelpegel Ullage: 100<br />
2017-03-03_13:08:27 Oelpegel RemainingUsableLevel: 3227<br />
2017-03-03_13:08:27 Oelpegel RemainingUsablePercent: 31.0<br />
2017-03-03_13:08:27 Oelpegel TotalUsableCapacity: 10414<br />
</source><br />
In den ersten 10 Minuten nach dem Anlernen, befindet sich das Gerät im Echtzeit-Modus. Das bedeutet es werden mehrere Messungen pro Sekunde übertragen. Das würde die Batterie sehr schnell lehren. Daher schaltet das Gerät nach 10 Minuten in den Normalbetrieb, in dem nur noch ganz grob alle 30 Minuten Werte übertragen werden. Die Übertragung zu FHEM findet auch nur statt, wenn über die Funkstrecke Daten vom Sensor kommen. Das führt zu der Situation, dass nach diesen 10 Minuten ein neu eingerichtetes <code>TEK603</code> Modul sehr lange (Stunden ?) keine Daten anzeigt, obwohl das Display der Proteus Daten anzeigt. Das liegt einfach daran, dass dieses Display den zuletzt gespeicherten Messwert anzeigt egal wie lange der her ist. Übertragen wird bis zum nächsten Wert auf der Funkstrecke nichts.<br />
<br />
== Einsatzbeispiel ==<br />
=== Anzeige des Ölstands in einem Öltank ===<br />
{{todo|Beispielunterlagen erstellen}}<br />
<br />
== Links ==<br />
* Hersteller: [https://proteus-meter.com/produkte/proteus-ecometer/ Shop]<br />
* Hersteller: [https://proteus-meter.com/faq/ Bedienanleitung]<br />
* Forenbeitrag zur FHEM-Einbindung: {{Link2Forum|Topic=27315}}<br />
<br />
[[Kategorie:Other Components]]<br />
[[Kategorie:Füllstandsmesser]]</div>MGuhttp://wiki.fhem.de/w/index.php?title=Proteus_EcoMeter&diff=20485Proteus EcoMeter2017-03-03T12:23:12Z<p>MGu: /* Eventmonitorbeispiel */</p>
<hr />
<div>[[Proteus_EcoMeter]] ist ein Ultraschallsensor mit Monitor zur Pegelmessung von Heizöl- oder Wassertanks<br />
<br />
* Sensor zum Einbau in den Tank<br />
* Funkverbindung zwischen Sensor und Monitor<br />
* USB-Verbindung zwischen Monitor und FHEM<br />
* Für Wasser oder Öltanks<br />
<br />
EcoMeter für Heizöltanks<br><br />
EcoMeter S für Wassertanks<br><br />
<br />
{{Infobox Hardware<br />
|Bild=platzHalter.png<br />
|Bildbeschreibung=todo<br />
|HWProtocol=unknown<br />
|HWType=Sensor und Sender<br />
|HWCategory=Other Components<br />
|HWComm=Funk, 433,92MHz, USB<br />
|HWChannels=unknown<br />
|HWVoltage=1,5V LR2450, 5V USB<br />
|HWPowerConsumption=unknown<br />
|HWPoweredBy=Battery, USB<br />
|HWSize=21 x 18 x 6 cm<br />
|HWDeviceFHEM=[http://fhem.de/commandref.html#TEK603 TEK603]<br />
|HWManufacturer=Tekelek<br />
}}<br />
== Features ==<br />
EcoMeter liefert alle 60 Minuten einen Messwert<br />
EcoMeter liefert alle 30 Minuten einen Messwert und bei schnellen Änderungen<br />
<br />
== Hinweise zum Betrieb mit FHEM ==<br />
=== Definition/Anlernvorgang ===<br />
# eventuell im Linux fehlende Pakete installieren <code>sudo apt-get install libdigest-crc-perl </code><br />
# Monitor an das FHEM Gerät anschließen<br />
# Festellen, dass die Verbindung geht. Dazu auf der Kommandozeile eingeben: <code>ls -al /dev/serial/by-id <br> lrwxrwxrwx 1 root root 13 Jan 1 1970 usb-Silicon_Labs_CP2102_USB_to_UART_Bridge_Controller_0001-if00-port0 -> ../../ttyUSB0 </code> <br />
# ecometer definieren <code>define ecometer TEK603 /dev/serial/by-id/usb-Silicon_Labs_CP2102_USB_to_UART_Bridge_Controller_0001-if00-port0 </code><br />
# LogFile definieren <code>define FileLog_ecometer FileLog %Lecometer-%Y.log ecometer.* </code><br />
# Gerät wie in der Betriebsanleitung installieren<br />
<br />
=== Identifikation ===<br />
Das Proteus EcoMeter verwendet für die Anbindung der seriellen Kommunikation an die USB-Schnittstelle einen sehr weit verbreiteten Chip der Familie <code>CP210x UART Bridges</code>. Dieser Baustein hat die USB <code>ID 10c4:ea60</code> über die auch der Name in <code>/dev/serial/by-id</code> abgeleitet wird. Hat man mehrere Geräte die mit diesem Chip arbeiten (z.B. den optischen Adapter von Viessmann für [[Vitotronic_200_(Viessmann_Heizungssteuerung)|VCONTROL]]) am gleichen Rechner, so werden diese unter <code>lsusb</code> mit identischer ID gelistet, aber nur einer erhält den passenden Namen unter <code>/dev/serial/by-id</code>. Sie sind also auf diese Weise nicht unterscheidbar. Die kurzen Gerätenamen <code>/dev/ttyUSBx</code> werden willkürlich zugeordnet. Damit sind die Geräte auch nicht unterscheidbar.<br />
<br />
Bleibt noch der Pfad wenn man die Geräte immer in die gleiche Buchse steckt. Diese Pfade werden unter Linux in <code>/dev/serial/by-path</code> angelegt. Hier kann man einzelne Buchsen (auch von Hubs) identifizieren. Die Namen enthalten jedoch Doppelpunkte und FHEM verkraftet keine Gerätenamen mit Doppelpunkten. <small>''Wer weiß warum bitte hier Lösung eintragen.''</small> Um diese ohnehin unhandlichen Namen kürzer und verträglicher zu bekommen, kann man Symbolische Links anlegen. Dazu erzeugt man am besten in <code>/opt/fhem</code> ein Verzeichnis <code>dev</code> und verlinkt alle für FHEM relevanten Geräte dort hin. Also in meinem Beispiel TEK603 und VCONTROL:<br />
<source lang=bash><br />
cd /opt/fhem<br />
mkdir dev<br />
cd dev<br />
ln -s /dev/serial/by-path/pci-0000:00:14.0-usb-0:4.3:1.0-port0 heizung<br />
ln -s /dev/serial/by-path/pci-0000:00:14.0-usb-0:4.2:1.0-port0 oelpegel<br />
</source><br />
Solange man die beiden Geräte immer in die gleiche Buchse steckt, werden sie ab jetzt immer korrekt zugeordnet:<br />
<source lang=text><br />
defmod Oelpegel TEK603 /opt/fhem/dev/oelpegel<br />
defmod Heizung VCONTROL /opt/fhem/dev/heizung /opt/fhem/mycfg/vitoladens_300-C_J3Ra-24.cfg 120<br />
</source><br />
<br />
=== FHEM Config-Auszug ===<br />
Ein exemplarischer Auszug aus der [[Konfiguration]]:<br />
define ecometer TEK603 /dev/serial/by-id/usb-Silicon_Labs_CP2102_USB_to_UART_Bridge_Controller_0001-if00-port0<br />
define FileLog_ecometer FileLog %Lecometer-%Y.log ecometer.*<br />
<br />
=== Eventmonitorbeispiel ===<br />
<source lang=text><br />
2017-03-03_13:07:11 Oelpegel CONNECTED<br />
2017-03-03_13:08:27 Oelpegel Time: 13:05:21<br />
2017-03-03_13:08:27 Oelpegel Temperature: 18.33<br />
2017-03-03_13:08:27 Oelpegel Ullage: 100<br />
2017-03-03_13:08:27 Oelpegel RemainingUsableLevel: 3227<br />
2017-03-03_13:08:27 Oelpegel RemainingUsablePercent: 31.0<br />
2017-03-03_13:08:27 Oelpegel TotalUsableCapacity: 10414<br />
</source><br />
In den ersten 10 Minuten nach dem Anlernen, befindet sich das Gerät im Echtzeit-Modus. Das bedeutet es werden mehrere Messungen pro Sekunde übertragen. Das würde die Batterie sehr schnell lehren. Daher schaltet das Gerät nach 10 Minuten in den Normalbetrieb, in dem nur noch sehr selten Werte übertragen werden. Die Übertragung zu FHEM findet auch nur statt, wenn über die Funkstrecke Daten vom Sensor kommen. Das führt zu der Situation, dass nach diesen 10 Minuten ein neu eingerichtetes <code>TEK603</code> Modul sehr lange (Stunden ?) keine Daten anzeigt, obwohl das Display der Proteus Daten anzeigt. Das liegt einfach daran, dass dieses Display den zuletzt gespeicherten Messwert anzeigt egal wie lange der her ist. Übertragen wird bis zum nächsten Wert auf der Funkstrecke nichts.<br />
<br />
== Einsatzbeispiel ==<br />
=== Anzeige des Ölstands in einem Öltank ===<br />
{{todo|Beispielunterlagen erstellen}}<br />
<br />
== Links ==<br />
* Hersteller: [https://proteus-meter.com/produkte/proteus-ecometer/ Shop]<br />
* Hersteller: [https://proteus-meter.com/faq/ Bedienanleitung]<br />
* Forenbeitrag zur FHEM-Einbindung: {{Link2Forum|Topic=27315}}<br />
<br />
[[Kategorie:Other Components]]<br />
[[Kategorie:Füllstandsmesser]]</div>MGuhttp://wiki.fhem.de/w/index.php?title=Proteus_EcoMeter&diff=20484Proteus EcoMeter2017-03-03T11:59:33Z<p>MGu: /* Definition/Anlernvorgang */ Unterscheidung</p>
<hr />
<div>[[Proteus_EcoMeter]] ist ein Ultraschallsensor mit Monitor zur Pegelmessung von Heizöl- oder Wassertanks<br />
<br />
* Sensor zum Einbau in den Tank<br />
* Funkverbindung zwischen Sensor und Monitor<br />
* USB-Verbindung zwischen Monitor und FHEM<br />
* Für Wasser oder Öltanks<br />
<br />
EcoMeter für Heizöltanks<br><br />
EcoMeter S für Wassertanks<br><br />
<br />
{{Infobox Hardware<br />
|Bild=platzHalter.png<br />
|Bildbeschreibung=todo<br />
|HWProtocol=unknown<br />
|HWType=Sensor und Sender<br />
|HWCategory=Other Components<br />
|HWComm=Funk, 433,92MHz, USB<br />
|HWChannels=unknown<br />
|HWVoltage=1,5V LR2450, 5V USB<br />
|HWPowerConsumption=unknown<br />
|HWPoweredBy=Battery, USB<br />
|HWSize=21 x 18 x 6 cm<br />
|HWDeviceFHEM=[http://fhem.de/commandref.html#TEK603 TEK603]<br />
|HWManufacturer=Tekelek<br />
}}<br />
== Features ==<br />
EcoMeter liefert alle 60 Minuten einen Messwert<br />
EcoMeter liefert alle 30 Minuten einen Messwert und bei schnellen Änderungen<br />
<br />
== Hinweise zum Betrieb mit FHEM ==<br />
=== Definition/Anlernvorgang ===<br />
# eventuell im Linux fehlende Pakete installieren <code>sudo apt-get install libdigest-crc-perl </code><br />
# Monitor an das FHEM Gerät anschließen<br />
# Festellen, dass die Verbindung geht. Dazu auf der Kommandozeile eingeben: <code>ls -al /dev/serial/by-id <br> lrwxrwxrwx 1 root root 13 Jan 1 1970 usb-Silicon_Labs_CP2102_USB_to_UART_Bridge_Controller_0001-if00-port0 -> ../../ttyUSB0 </code> <br />
# ecometer definieren <code>define ecometer TEK603 /dev/serial/by-id/usb-Silicon_Labs_CP2102_USB_to_UART_Bridge_Controller_0001-if00-port0 </code><br />
# LogFile definieren <code>define FileLog_ecometer FileLog %Lecometer-%Y.log ecometer.* </code><br />
# Gerät wie in der Betriebsanleitung installieren<br />
<br />
=== Identifikation ===<br />
Das Proteus EcoMeter verwendet für die Anbindung der seriellen Kommunikation an die USB-Schnittstelle einen sehr weit verbreiteten Chip der Familie <code>CP210x UART Bridges</code>. Dieser Baustein hat die USB <code>ID 10c4:ea60</code> über die auch der Name in <code>/dev/serial/by-id</code> abgeleitet wird. Hat man mehrere Geräte die mit diesem Chip arbeiten (z.B. den optischen Adapter von Viessmann für [[Vitotronic_200_(Viessmann_Heizungssteuerung)|VCONTROL]]) am gleichen Rechner, so werden diese unter <code>lsusb</code> mit identischer ID gelistet, aber nur einer erhält den passenden Namen unter <code>/dev/serial/by-id</code>. Sie sind also auf diese Weise nicht unterscheidbar. Die kurzen Gerätenamen <code>/dev/ttyUSBx</code> werden willkürlich zugeordnet. Damit sind die Geräte auch nicht unterscheidbar.<br />
<br />
Bleibt noch der Pfad wenn man die Geräte immer in die gleiche Buchse steckt. Diese Pfade werden unter Linux in <code>/dev/serial/by-path</code> angelegt. Hier kann man einzelne Buchsen (auch von Hubs) identifizieren. Die Namen enthalten jedoch Doppelpunkte und FHEM verkraftet keine Gerätenamen mit Doppelpunkten. <small>''Wer weiß warum bitte hier Lösung eintragen.''</small> Um diese ohnehin unhandlichen Namen kürzer und verträglicher zu bekommen, kann man Symbolische Links anlegen. Dazu erzeugt man am besten in <code>/opt/fhem</code> ein Verzeichnis <code>dev</code> und verlinkt alle für FHEM relevanten Geräte dort hin. Also in meinem Beispiel TEK603 und VCONTROL:<br />
<source lang=bash><br />
cd /opt/fhem<br />
mkdir dev<br />
cd dev<br />
ln -s /dev/serial/by-path/pci-0000:00:14.0-usb-0:4.3:1.0-port0 heizung<br />
ln -s /dev/serial/by-path/pci-0000:00:14.0-usb-0:4.2:1.0-port0 oelpegel<br />
</source><br />
Solange man die beiden Geräte immer in die gleiche Buchse steckt, werden sie ab jetzt immer korrekt zugeordnet:<br />
<source lang=text><br />
defmod Oelpegel TEK603 /opt/fhem/dev/oelpegel<br />
defmod Heizung VCONTROL /opt/fhem/dev/heizung /opt/fhem/mycfg/vitoladens_300-C_J3Ra-24.cfg 120<br />
</source><br />
<br />
=== FHEM Config-Auszug ===<br />
Ein exemplarischer Auszug aus der [[Konfiguration]]:<br />
define ecometer TEK603 /dev/serial/by-id/usb-Silicon_Labs_CP2102_USB_to_UART_Bridge_Controller_0001-if00-port0<br />
define FileLog_ecometer FileLog %Lecometer-%Y.log ecometer.*<br />
<br />
=== Eventmonitorbeispiel ===<br />
{{todo| Eventmonitor einfügen}}<br />
<br />
== Einsatzbeispiel ==<br />
=== Anzeige des Ölstands in einem Öltank ===<br />
{{todo|Beispielunterlagen erstellen}}<br />
<br />
== Links ==<br />
* Hersteller: [https://proteus-meter.com/produkte/proteus-ecometer/ Shop]<br />
* Hersteller: [https://proteus-meter.com/faq/ Bedienanleitung]<br />
* Forenbeitrag zur FHEM-Einbindung: {{Link2Forum|Topic=27315}}<br />
<br />
[[Kategorie:Other Components]]<br />
[[Kategorie:Füllstandsmesser]]</div>MGuhttp://wiki.fhem.de/w/index.php?title=Plot-Abriss_vermeiden&diff=19174Plot-Abriss vermeiden2017-01-28T12:53:50Z<p>MGu: /* Implementierung */ HTML escape entfernt</p>
<hr />
<div>== Motivation ==<br />
Bei Nutzung des Attributs <code>event-on-change</code> werden Log-Einträge nur bei Werteänderung geschrieben. Dies führt<br />
# zum Abriss der Logs zum Ende des alten und zum Beginn des neuen Tages<br />
# zu inadäquat langen Pausen zwischen Logeinträgen, z.B. für <code>actuator</code>, der z.B. in den Wintermonaten bei Anwesenheit durchgängig 100%, bei Abwesenheit durchgängig 0% betragen kann. Der Wechsel zwischen diesen Werten wird mit langen Flanken dargestellt.<br />
<br />
== Funktionsweise ==<br />
Aus diesem Grund wurde die Routine <code>addLog</code> erstellt (siehe [[#Implementierung|Implementierung]]).<br />
Sie fügt zu definierten Zeitpunkten Einträge im Log hinzu.<br />
Dadurch sollen die o.g. Effekte vermieden werden.<br />
Zusätzliche Einträge sind mit dem Anhang <code><< addLog</code> gekennzeichnet.<br />
Der Aufruf erfolgt sinnvollerweise aus einem <code>at</code> oder einem <code>DOIF</code>.<br />
Üblich ist der Aufruf für alle Geräte bzw. readings, für die <code>event-on-change</code> gesetzt ist.<br />
<br />
Die Routine hat zwei Aufrufparameter:<br />
<source lang=text><br />
addLog(<devicename>, <reading>)<br />
</source><br />
<br />
== Beispiele aus fhem.cfg ==<br />
<source lang=text><br />
### jede Stunde einen Eintrag für FHT actuator<br />
define a_actuator at +*01:00 {addLog("ez_FHT","actuator")}<br />
attr a_actuator room 99_System<br />
</source><br />
<br />
<code>addLog</code> für mehrere <code>devices</code> in einem "Makro" zusammenfassen:<br />
<source lang=text><br />
define addLog notify addLog {addLog("ez_Aussensensor","state");;\<br />
addLog("ez_FHT","actuator");;\<br />
addLog("ez_FHT","measured-temp");;\<br />
addLog("MunichWeather","humidity");;\<br />
addLog("MunichWeather","pressure");;\<br />
addLog("MunichWeather","temperature");;\<br />
addLog("MunichWeather","wind_chill");;}<br />
attr addLog room 99_System<br />
</source><br />
<br />
<source lang=text><br />
### Hier ist ein trigger des o.g. notify verwendet, um nicht in beiden at-defines alle Aufrufe listen zu müssen.<br />
define a_midnight1 at *23:59 trigger addLog<br />
attr a_midnight1 room 99_System<br />
define a_midnight2 at *00:01 trigger addLog<br />
attr a_midnight2 room 99_System<br />
# Alternativ können auch die Einzelaufrufe direkt im at erfolgen, z.B.<br />
define a_midnight_before at *23:59 {addLog("device","reading")}<br />
</source><br />
<br />
==Beispiele mit DOIF ==<br />
Seitdem es [[DOIF]] gibt, lässt sich das Ganze auch etwas anders umsetzen:<br />
<br />
<source lang=text><br />
define DF_addLogDaily DOIF ([23:59] or [00:01]) ({addLog("ez_FHT", "actuator")})<br />
attr DF_addLogDaily room 99_System<br />
attr DF_addLogDaily do always<br />
</source><br />
Da mit diesem Aufruf aber die Problematik nur nach unten verschoben wird (Zoom auf Stunde oder Vierteltag),<br />
ist folgendes möglich:<br />
<source lang=text><br />
define DF_addLogHourly DOIF ([:59] or [:01]) ({addLog("ez_FHT", "actuator")})<br />
attr DF_addLogHourly room 99_System<br />
attr DF_addLogHourly do always<br />
</source><br />
Das Ganze lässt sich auch noch auf minütlich runterbrechen, erzeugt dadurch ggf. eine große Menge Logeinträge. Dies sollte man stets bedenken.<br />
<br />
== Log-Beispiele ==<br />
<source lang=text><br />
2012-11-04_23:46:28 ez_Aussensensor T: 9.4 H: 78.5<br />
2012-11-04_23:59:00 ez_Aussensensor T: 9.4 H: 78.5 << addLog<br />
2012-11-04_23:59:00 ez_FHT actuator: 0% << addLog<br />
2012-11-04_23:59:00 ez_FHT measured-temp: 17.4 << addLog<br />
2012-11-05_00:01:00 ez_Aussensensor T: 9.4 H: 78.5 << addLog<br />
2012-11-05_00:01:00 ez_FHT actuator: 0% << addLog<br />
2012-11-05_00:01:00 ez_FHT measured-temp: 17.4 << addLog<br />
2012-11-05_00:24:31 ez_FHT actuator: 0% << addLog<br />
2012-11-05_00:42:32 ez_Aussensensor T: 9.1 H: 78.1<br />
2012-11-05_16:02:59 ez_Aussensensor T: 10.3 H: 65.9<br />
2012-11-05_16:05:56 ez_Aussensensor T: 10.2 H: 66.3<br />
2012-11-05_16:21:47 ez_Aussensensor T: 10.2 H: 66.3 << addLog<br />
2012-11-05_16:21:48 ez_FHT actuator: 100% << addLog<br />
2012-11-05_16:21:48 ez_FHT measured-temp: 18.5 << addLog<br />
2012-11-05_16:30:26 ez_FHT measured-temp: 18.7<br />
2012-11-05_16:44:18 ez_Aussensensor T: 9.9 H: 65.8<br />
</source><br />
<br />
== Nebeneffekte ==<br />
<code>addLog</code> verwendet die Funktion <code>trigger</code>.<br />
Für fhem ist das gleichwertig mit dem Eintreffen eines Ereignisses.<br />
Es werden also ggf. alle <code>notifies</code> ausgeführt, die für das relevante Gerät abzuarbeiten sind.<br />
Dies ist wohl zu bedenken, bevor man <code>addLog</code> verwendet.<br />
<br />
== Bekannte Probleme ==<br />
Das Modul [[dewpoint]] fügt dem <code>state</code> eines <code>device</code> den zusatz <code>D: xx</code> hinzu.<br />
Abhängig vom Timing kann dies zu "verwurschtelten" Darstellungen führen.<br />
Die Verwendung von <code>addLog</code> in Verbindung mit <code>dewpoint</code> ist daher nicht empfohlen.<br />
<br />
== Implementierung ==<br />
Die Routine wird in eine lokale Programmdatei integriert, z.B. <code>99_myUtils.pm</code> (siehe [[99 myUtils anlegen]]).<br />
Wird die Funktion dort mit einem externen Editor eingefügt, muss anschließend <code>reload 99_myUtils.pm</code> ausgeführt werden.<br />
Auf Fehlermeldungen im fhem.log achten.<br />
<source lang=perl><br />
#### Log-abriss vermeiden<br />
# called by<br />
# define addLog notify addLog {addLog("ez_Aussensensor","state");;\<br />
# addLog("ez_FHT","actuator");;\<br />
# addLog("MunichWeather","humidity");;\<br />
# addLog("MunichWeather","pressure");;\<br />
# addLog("MunichWeather","temperature");;\<br />
# addLog("MunichWeather","wind_chill");;}<br />
# define a_midnight1 at *23:59 trigger addLog<br />
# define a_midnight2 at *00:01 trigger addLog<br />
sub<br />
addLog($$) {<br />
my ($logdevice, $reading) = @_; # device and reading to be used<br />
my $logentry = ReadingsVal($logdevice,$reading,"addLog: invalid reading");<br />
if ($reading =~ m,state,i) {<br />
fhem "trigger $logdevice $logentry << addLog";<br />
} else {<br />
fhem "trigger $logdevice $reading: $logentry << addLog";<br />
}<br />
}<br />
</source><br />
<br />
[[Kategorie:Code Snippets]]</div>MGuhttp://wiki.fhem.de/w/index.php?title=Plot-Abriss_vermeiden&diff=19173Plot-Abriss vermeiden2017-01-28T12:51:00Z<p>MGu: Doppel ;; fehlt, etwas überarbeitet</p>
<hr />
<div>== Motivation ==<br />
Bei Nutzung des Attributs <code>event-on-change</code> werden Log-Einträge nur bei Werteänderung geschrieben. Dies führt<br />
# zum Abriss der Logs zum Ende des alten und zum Beginn des neuen Tages<br />
# zu inadäquat langen Pausen zwischen Logeinträgen, z.B. für <code>actuator</code>, der z.B. in den Wintermonaten bei Anwesenheit durchgängig 100%, bei Abwesenheit durchgängig 0% betragen kann. Der Wechsel zwischen diesen Werten wird mit langen Flanken dargestellt.<br />
<br />
== Funktionsweise ==<br />
Aus diesem Grund wurde die Routine <code>addLog</code> erstellt (siehe [[#Implementierung|Implementierung]]).<br />
Sie fügt zu definierten Zeitpunkten Einträge im Log hinzu.<br />
Dadurch sollen die o.g. Effekte vermieden werden.<br />
Zusätzliche Einträge sind mit dem Anhang <code><< addLog</code> gekennzeichnet.<br />
Der Aufruf erfolgt sinnvollerweise aus einem <code>at</code> oder einem <code>DOIF</code>.<br />
Üblich ist der Aufruf für alle Geräte bzw. readings, für die <code>event-on-change</code> gesetzt ist.<br />
<br />
Die Routine hat zwei Aufrufparameter:<br />
<source lang=text><br />
addLog(<devicename>, <reading>)<br />
</source><br />
<br />
== Beispiele aus fhem.cfg ==<br />
<source lang=text><br />
### jede Stunde einen Eintrag für FHT actuator<br />
define a_actuator at +*01:00 {addLog("ez_FHT","actuator")}<br />
attr a_actuator room 99_System<br />
</source><br />
<br />
<code>addLog</code> für mehrere <code>devices</code> in einem "Makro" zusammenfassen:<br />
<source lang=text><br />
define addLog notify addLog {addLog("ez_Aussensensor","state");;\<br />
addLog("ez_FHT","actuator");;\<br />
addLog("ez_FHT","measured-temp");;\<br />
addLog("MunichWeather","humidity");;\<br />
addLog("MunichWeather","pressure");;\<br />
addLog("MunichWeather","temperature");;\<br />
addLog("MunichWeather","wind_chill");;}<br />
attr addLog room 99_System<br />
</source><br />
<br />
<source lang=text><br />
### Hier ist ein trigger des o.g. notify verwendet, um nicht in beiden at-defines alle Aufrufe listen zu müssen.<br />
define a_midnight1 at *23:59 trigger addLog<br />
attr a_midnight1 room 99_System<br />
define a_midnight2 at *00:01 trigger addLog<br />
attr a_midnight2 room 99_System<br />
# Alternativ können auch die Einzelaufrufe direkt im at erfolgen, z.B.<br />
define a_midnight_before at *23:59 {addLog("device","reading")}<br />
</source><br />
<br />
==Beispiele mit DOIF ==<br />
Seitdem es [[DOIF]] gibt, lässt sich das Ganze auch etwas anders umsetzen:<br />
<br />
<source lang=text><br />
define DF_addLogDaily DOIF ([23:59] or [00:01]) ({addLog("ez_FHT", "actuator")})<br />
attr DF_addLogDaily room 99_System<br />
attr DF_addLogDaily do always<br />
</source><br />
Da mit diesem Aufruf aber die Problematik nur nach unten verschoben wird (Zoom auf Stunde oder Vierteltag),<br />
ist folgendes möglich:<br />
<source lang=text><br />
define DF_addLogHourly DOIF ([:59] or [:01]) ({addLog("ez_FHT", "actuator")})<br />
attr DF_addLogHourly room 99_System<br />
attr DF_addLogHourly do always<br />
</source><br />
Das Ganze lässt sich auch noch auf minütlich runterbrechen, erzeugt dadurch ggf. eine große Menge Logeinträge. Dies sollte man stets bedenken.<br />
<br />
== Log-Beispiele ==<br />
<source lang=text><br />
2012-11-04_23:46:28 ez_Aussensensor T: 9.4 H: 78.5<br />
2012-11-04_23:59:00 ez_Aussensensor T: 9.4 H: 78.5 << addLog<br />
2012-11-04_23:59:00 ez_FHT actuator: 0% << addLog<br />
2012-11-04_23:59:00 ez_FHT measured-temp: 17.4 << addLog<br />
2012-11-05_00:01:00 ez_Aussensensor T: 9.4 H: 78.5 << addLog<br />
2012-11-05_00:01:00 ez_FHT actuator: 0% << addLog<br />
2012-11-05_00:01:00 ez_FHT measured-temp: 17.4 << addLog<br />
2012-11-05_00:24:31 ez_FHT actuator: 0% << addLog<br />
2012-11-05_00:42:32 ez_Aussensensor T: 9.1 H: 78.1<br />
2012-11-05_16:02:59 ez_Aussensensor T: 10.3 H: 65.9<br />
2012-11-05_16:05:56 ez_Aussensensor T: 10.2 H: 66.3<br />
2012-11-05_16:21:47 ez_Aussensensor T: 10.2 H: 66.3 << addLog<br />
2012-11-05_16:21:48 ez_FHT actuator: 100% << addLog<br />
2012-11-05_16:21:48 ez_FHT measured-temp: 18.5 << addLog<br />
2012-11-05_16:30:26 ez_FHT measured-temp: 18.7<br />
2012-11-05_16:44:18 ez_Aussensensor T: 9.9 H: 65.8<br />
</source><br />
<br />
== Nebeneffekte ==<br />
<code>addLog</code> verwendet die Funktion <code>trigger</code>.<br />
Für fhem ist das gleichwertig mit dem Eintreffen eines Ereignisses.<br />
Es werden also ggf. alle <code>notifies</code> ausgeführt, die für das relevante Gerät abzuarbeiten sind.<br />
Dies ist wohl zu bedenken, bevor man <code>addLog</code> verwendet.<br />
<br />
== Bekannte Probleme ==<br />
Das Modul [[dewpoint]] fügt dem <code>state</code> eines <code>device</code> den zusatz <code>D: xx</code> hinzu.<br />
Abhängig vom Timing kann dies zu "verwurschtelten" Darstellungen führen.<br />
Die Verwendung von <code>addLog</code> in Verbindung mit <code>dewpoint</code> ist daher nicht empfohlen.<br />
<br />
== Implementierung ==<br />
Die Routine wird in eine lokale Programmdatei integriert, z.B. <code>99_myUtils.pm</code> (siehe [[99 myUtils anlegen]]).<br />
Wird die Funktion dort mit einem externen Editor eingefügt, muss anschließend <code>reload 99_myUtils.pm</code> ausgeführt werden.<br />
Auf Fehlermeldungen im fhem.log achten.<br />
<source lang=perl><br />
#### Log-abriss vermeiden<br />
# called by<br />
# define addLog notify addLog {addLog("ez_Aussensensor","state");;\<br />
# addLog("ez_FHT","actuator");;\<br />
# addLog("MunichWeather","humidity");;\<br />
# addLog("MunichWeather","pressure");;\<br />
# addLog("MunichWeather","temperature");;\<br />
# addLog("MunichWeather","wind_chill");;}<br />
# define a_midnight1 at *23:59 trigger addLog<br />
# define a_midnight2 at *00:01 trigger addLog<br />
sub<br />
addLog($$) {<br />
my ($logdevice, $reading) = @_; # device and reading to be used<br />
my $logentry = ReadingsVal($logdevice,$reading,&quot;addLog: invalid reading&quot;);<br />
if ($reading =~ m,state,i) {<br />
fhem &quot;trigger $logdevice $logentry &lt;&lt; addLog&quot;;<br />
} else {<br />
fhem &quot;trigger $logdevice $reading: $logentry &lt;&lt; addLog&quot;;<br />
}<br />
}<br />
</source><br />
<br />
[[Kategorie:Code Snippets]]</div>MGuhttp://wiki.fhem.de/w/index.php?title=Plot-Abriss_vermeiden&diff=19171Plot-Abriss vermeiden2017-01-28T12:08:33Z<p>MGu: /* Beispiele mit DOIF */ Syntax (siehe commandref.html); Substantivierung groß</p>
<hr />
<div>== Motivation ==<br />
Bei Nutzung des Attributs event-on-change werden Log-Einträge nur bei Werteänderung geschrieben. Dies führt<br />
a) zum Abriss der Logs zum Ende des alten und zum Beginn des neuen Tages<br />
b) zu inadäquat langen Pausen zwischen Logeinträgen, z.B. für actuator, der zB in den Wintermonaten bei Anwesenheit durchgängig 100%, bei Abwesenheit durchgängig 0% betragen kann. Der Wechsel zwischen diesen Werten wird mit langen Flanken dargestellt.<br />
<br />
== Funktionsweise ==<br />
Die Routine addLog fügt zu definierten Zeitpunkten Einträge im Log hinzu. Dadurch sollen die o.g. Effekte vermieden werden. Zusätzliche Einträge sind mit dem Anhang "&lt;&lt; addLog" gekennzeichnet.<br />
Der Aufruf erfolgt sinnvollerweise aus einem at. Üblich ist der Aufruf für alle Geräte bzw. readings, für die "event-on-change" gesetzt ist.<br />
<br />
Die Routine hat zwei Aufrufparameter:<br />
<br />
<nowiki>addLog(&lt;devicename&gt;, &lt;reading&gt;)</nowiki><br />
<br />
== Beispiele aus fhem.cfg ==<br />
<nowiki>### jede Stunde einen Eintrag für FHT actuator<br />
define a_actuator at +*01:00 {addLog(&quot;ez_FHT&quot;,&quot;actuator&quot;)}<br />
attr a_actuator room 99_System</nowiki><br />
<br />
addLog für mehrere devices in einem "Makro" zusammenfassen:<br />
<br />
<nowiki>define addLog notify addLog {addLog(&quot;ez_Aussensensor&quot;,&quot;state&quot;);;addLog(&quot;ez_FHT&quot;,&quot;actuator&quot;);;addLog(&quot;ez_FHT&quot;,&quot;measured-temp&quot;);;addLog(&quot;MunichWeather&quot;,&quot;humidity&quot;);;addLog(&quot;MunichWeather&quot;,&quot;pressure&quot;);;addLog(&quot;MunichWeather&quot;,&quot;temperature&quot;);;addLog(&quot;MunichWeather&quot;,&quot;wind_chill&quot;);;}<br />
attr addLog room 99_System</nowiki><br />
<br />
<nowiki>### Hier ist ein trigger des o.g. notify verwendet, um nicht in beiden at-defines alle Aufrufe listen zu müssen.<br />
define a_midnight1 at *23:59 trigger addLog<br />
attr a_midnight1 room 99_System<br />
define a_midnight2 at *00:01 trigger addLog<br />
attr a_midnight2 room 99_System<br />
# Alternativ können auch die Einzelaufrufe direkt im at erfolgen, zB<br />
# define a_midnight_before at *23:59 {addLog(&quot;device&quot;,&quot;reading&quot;)}</nowiki><br />
<br />
<br />
==Beispiele mit DOIF ==<br />
Seitdem es [[DOIF]] gibt, lässt sich das Ganze auch etwas anders umsetzen:<br />
<br />
<source lang=text><br />
define DF_addLogDaily DOIF ([23:59] or [00:01]) ({addLog("ez_FHT", "actuator")})<br />
attr DF_addLogDaily room 99_System<br />
attr DF_addLogDaily do always<br />
</source><br />
Da mit diesem Aufruf aber die Problematik nur nach unten verschoben wird (Zoom auf Stunde oder Vierteltag),<br />
ist folgendes möglich:<br />
<source lang=text><br />
define DF_addLogHourly DOIF ([:59] or [:01]) ({addLog("ez_FHT", "actuator")})<br />
attr DF_addLogHourly room 99_System<br />
attr DF_addLogHourly do always<br />
</source><br />
Das Ganze lässt sich auch noch auf minütlich runterbrechen, erzeugt dadurch ggf. eine große Menge Logeinträge. Dies sollte man stets bedenken.<br />
<br />
== Log-Beispiele ==<br />
<nowiki>2012-11-04_23:46:28 ez_Aussensensor T: 9.4 H: 78.5<br />
2012-11-04_23:59:00 ez_Aussensensor T: 9.4 H: 78.5 &lt;&lt; addLog<br />
2012-11-04_23:59:00 ez_FHT actuator: 0% &lt;&lt; addLog<br />
2012-11-04_23:59:00 ez_FHT measured-temp: 17.4 &lt;&lt; addLog<br />
2012-11-05_00:01:00 ez_Aussensensor T: 9.4 H: 78.5 &lt;&lt; addLog<br />
2012-11-05_00:01:00 ez_FHT actuator: 0% &lt;&lt; addLog<br />
2012-11-05_00:01:00 ez_FHT measured-temp: 17.4 &lt;&lt; addLog<br />
2012-11-05_00:24:31 ez_FHT actuator: 0% &lt;&lt; addLog<br />
2012-11-05_00:42:32 ez_Aussensensor T: 9.1 H: 78.1<br />
2012-11-05_16:02:59 ez_Aussensensor T: 10.3 H: 65.9<br />
2012-11-05_16:05:56 ez_Aussensensor T: 10.2 H: 66.3<br />
2012-11-05_16:21:47 ez_Aussensensor T: 10.2 H: 66.3 &lt;&lt; addLog<br />
2012-11-05_16:21:48 ez_FHT actuator: 100% &lt;&lt; addLog<br />
2012-11-05_16:21:48 ez_FHT measured-temp: 18.5 &lt;&lt; addLog<br />
2012-11-05_16:30:26 ez_FHT measured-temp: 18.7<br />
2012-11-05_16:44:18 ez_Aussensensor T: 9.9 H: 65.8</nowiki><br />
== Nebeneffekte ==<br />
addLog verwendet die Funktion trigger. Für fhem ist das gleichwertig mit dem Eintreffen eines Funktelegramms. Es werden also ggf. alle notifies ausgeführt, die für das relevante Gerät abzuarbeiten sind.<br />
Dies ist wohl zu bedenken, bevor man addLog verwendet.<br />
<br />
== Bekannte Probleme ==<br />
Das Modul dewpoint fügt dem state eines device den zusatz "D: xx" hinzu. Timing-abhängig kann dies zu "verwurschtelten" Darstellungen führen. Die Verwendung von addLog in Verbindung mit dewpoint ist daher nicht empfohlen.<br />
<br />
== Implementierung ==<br />
Die Routine wird in die lokale Programmdatei integriert, z.B. 99_myUtils.pm, siehe [[99 myUtils anlegen]].<br />
Nach dem hineinkopieren bitte daran denken, ein reload 99_myUtils.pm durchzuführen.<br />
Auf Fehlermeldungen im fhem.log achten.<br />
<br />
<nowiki>#### Log-abriss vermeiden<br />
# called by<br />
# define addLog notify addLog {addLog(&quot;ez_Aussensensor&quot;,&quot;state&quot;);addLog(&quot;ez_FHT&quot;,&quot;actuator&quot;);\<br />
# addLog(&quot;MunichWeather&quot;,&quot;humidity&quot;);addLog(&quot;MunichWeather&quot;,&quot;pressure&quot;);\<br />
# addLog(&quot;MunichWeather&quot;,&quot;temperature&quot;);addLog(&quot;MunichWeather&quot;,&quot;wind_chill&quot;);}<br />
# define a_midnight1 at *23:59 trigger addLog<br />
# define a_midnight2 at *00:01 trigger addLog<br />
sub<br />
addLog($$) {<br />
my ($logdevice, $reading) = @_; # device and reading to be used<br />
my $logentry = ReadingsVal($logdevice,$reading,&quot;addLog: invalid reading&quot;);<br />
if ($reading =~ m,state,i) {<br />
fhem &quot;trigger $logdevice $logentry &lt;&lt; addLog&quot;;<br />
} else {<br />
fhem &quot;trigger $logdevice $reading: $logentry &lt;&lt; addLog&quot;;<br />
}<br />
}</nowiki><br />
<br />
[[Kategorie:Code Snippets]]</div>MGuhttp://wiki.fhem.de/w/index.php?title=HM-CFG-USB_USB_Konfigurations-Adapter&diff=18149HM-CFG-USB USB Konfigurations-Adapter2016-12-31T13:49:13Z<p>MGu: /* Start als Daemon */ Datei muss ausführbar gemacht werden.</p>
<hr />
<div>{{Infobox Hardware<br />
|Bild=HM-CFG-USB-2.jpg<br />
|Bildbeschreibung=HomeMatic USB Konfigurationsadapter (Version 2)<br />
|HWProtocol=HomeMatic <br />
|HWType=Interface/Gateway<br />
|HWCategory=HomeMatic<br />
|HWComm=868,3 MHz<br />
|HWChannels=<br />
|HWVoltage=5 V<br />
|HWPowerConsumption=<br />
|HWPoweredBy=USB-Bus<br />
|HWSize=V1: 40 x 90 x 25 mm<br />V2: 28 x 84 x 11,5 mm<br />
|HWDeviceFHEM=[http://fhem.de/commandref.html#CUL_HM CUL_HM]<br />
<!-- |ModOwner= --><br />
|HWManufacturer=eQ-3<br />
}}<br />
Der [[HomeMatic]] '''USB Konfigurations-Adapter''' ist ein USB-Stick, der außer zur Konfiguration von HomeMatic-Komponenten auch als [[Interface]] zwischen Fhem und HomeMatic-Geräten benutzt werden kann. Er existiert in zwei Versionen: der älteren HM-CFG-USB und der neueren HM-CFG-USB2. Die folgenden Beschreibungen gelten für beide Versionen, es sei denn, es ist ausdrücklich eine spezifische Version genannt.<br />
<br />
== Einbindung in Fhem ==<br />
Im Fhem-Forum wird die Einbindung als Interface in diesem {{Link2Forum|Topic=13071}} beschrieben und diskutiert. Im {{Link2Forum|Topic=13071|Message=79872|LinkText=Eröffnungsbeitrag}} wird eine gut funktionierende HMLAN-Emulationssoftware [https://git.zerfleddert.de/cgi-bin/gitweb.cgi/hmcfgusb hmland] von ihrem Entwickler vorgestellt, um den HM-CFG-USB in Fhem zu integrieren. Die HMLAN-Emulationssoftware muss zunächst kompiliert und installiert werden. Anschließend wird der HM-CFG-USB (üblicherweise auf localhost) genau wie [[HM-CFG-LAN LAN Konfigurations-Adapter|HMLAN]] in Fhem eingebunden. <br />
<br />
=== Einrichtung unter Linux ===<br />
Die Schritte zur Kompilierung und Installation hat der hmland-Entwickler sowohl auf der [https://git.zerfleddert.de/cgi-bin/gitweb.cgi/hmcfgusb hmland-Internetseite] in Englisch (kurz) als auch im oben genannten {{Link2Forum|Topic=13071|Message=79872|LinkText=Eröffnungsbeitrag}} in Deutsch (ausführlich) dargestellt. Die dort gemachten Angaben werden auch bei Bedarf aktualisiert und sind deshalb der beste Anlaufpunkt für Kompilierung und Installation. <br />
<br />
{{Randnotiz|RNTyp=Info|RNText='''Skript zur Kompletteinrichtung unter Linux'''<br />
Dieser {{Link2Forum|Topic=13071|Message=190887|LinkText=Bericht}} im Forum stellt ein Script vor, das ''hmland'' herunterlädt, übersetzt (kompiliert), installiert sowie ein init-Script anlegt, so dass fast keine manuellen Eingriffe mehr notwendig sind.}}<br />
Die nachfolgenden Angaben in diesem Abschnitt sind rein zu Informationszwecken (noch) enthalten: <br />
<br />
Zunächst muss die HMLAN-Emulationssoftware kompiliert werden. Analog zu [https://git.zerfleddert.de/cgi-bin/gitweb.cgi/hmcfgusb dieser Beschreibung] ist die Vorgehensweise die folgende (in Debian/Ubuntu/Raspbian):<br />
<source lang="bash"><br />
cd /opt/<br />
apt-get install build-essential libusb-1.0-0-dev make gcc git-core<br />
git clone git://git.zerfleddert.de/hmcfgusb<br />
cd hmcfgusb<br />
make<br />
</source><br />
<br />
Danach kann der Dienst (zu Testzwecken sind Debugging-Ausgaben mit <code>-D</code> aktiviert) gestartet werden:<br />
:<code> /opt/hmcfgusb/hmland -p 1234 -D</code><br />
<br />
==== Start als Daemon ====<br />
Um ''hmland'' automatisch als Daemon zu starten, kann ein init-Script genutzt werden. Die Quellen von ''hmland'' enthalten ein solches Script im <code>debian/</code> Unterverzeichnis:<br />
<br />
<source lang="bash"><br />
cp /opt/hmcfgusb/debian/hmland.init /etc/init.d/hmland<br />
cp /opt/hmcfgusb/debian/hmland.default /etc/default/hmland<br />
</source><br />
<br />
Einstellungen, beispielsweise der Port, auf dem ''hmland'' hört, können (und sollten) in der Datei <code>/etc/default/hmland</code> vorgenommen werden. Die kopierte Datei mit <code>chmod 755 /etc/init.d/hmland</code> ausführbar machen, anschließend kann ''hmland'' mit folgendem Befehl gestartet werden:<br />
:<code>/etc/init.d/hmland start</code><br />
<br />
Bei Distributionen, die Upstart einsetzen (z.B. xbian) kann folgende Konfigurationsdatei verwendet werden:<br />
<source lang="bash"><br />
# HMLAND<br />
<br />
description "hmland"<br />
<br />
start on starting fhem<br />
stop on stopped fhem<br />
<br />
respawn<br />
expect fork<br />
<br />
chdir /opt/hmcfgusb<br />
exec /opt/hmcfgusb/hmland -d -l 127.0.0.1 -p 1234<br />
</source><br />
<br />
Die Datei sollte als <code>/etc/init/hmland.conf</code> angelegt werden. Mit dem Befehl<br />
:<code>initctl reload-configuration </code><br />
wird Upstart angewiesen, seine Konfiguration erneut einzulesen. Danach kann der Dienst ''hmland'' mit<br />
:<code>service hmland start </code><br />
gestartet werden. <code>hmland</code> wird jetzt immer vor Fhem gestartet und nach Fhem beendet.<br />
<br />
==== Start über Fhem Startskript ====<br />
Ausprobiert auf einem BBB mit Debian, eigentlich ist das alles von Betateilchen:<br />
<br />
Zunächst hmland kompilieren wie oben beschrieben, bis zum make. Das muss erfolgreich durchgelaufen sein.<br />
<br />
Dann geht es weiter:<br />
:<code>sudo cp hmcfgusb.rules /etc/udev/rules.d/ </code><br />
<br />
Jetzt das Fhem Startskript anpassen (in den Blöcken 'start' und 'stop' muss quasi nur jeweils 1 Zeile eingefügt werden:<br />
<br />
Damit editiert man das Fhem Startskript:<br />
:<code>sudo nano /etc/init.d/fhem </code><br />
<br />
Und so sollten die Blöcke anschließend aussehen (bitte nur jeweils die Zeile mit hmland einfügen)<br />
<source lang="bash"><br />
'start')<br />
echo "Starting fhem..."<br />
/opt/hmcfgusb/hmland -d -p 1234<br />
perl fhem.pl fhem.cfg<br />
RETVAL=$?<br />
;;<br />
<br />
'stop')<br />
echo "Stopping fhem..."<br />
perl fhem.pl $port "shutdown"<br />
RETVAL=$?<br />
pkill hmland<br />
</source><br />
<br />
So wird hmland vor Fhem gestartet und nach Fhem beendet. Letztlich erspart es Probleme mit den diversen Startskripten und ihren Rechten.<br />
<br />
Es dauert nach dem Start von Fhem noch einige Sekunden, bis hmland fertig geladen ist. In dieser Zeit kann es zu fehlerhaften Einträgen im Logfile kommen.<br />
<br />
=== Einrichtung auf Synology DiskStations ===<br />
Packages für DSM5.2 finden sich hier:<br />
https://github.com/mkunzmann/spksrc/releases/tag/0.101-3<br />
<br />
Welches Package für welche DS kann man hier sehen:<br />
https://github.com/SynoCommunity/spksrc/wiki/Architecture-per-Synology-model<br />
<br />
Einfach das passende Package installieren und dann kann man den hmland über den Synology Package-Manager starten und stoppen. Während der Installation kann man den Port für hmland festlegen. Bitte einen Port > 1024 wählen, da der hmland nicht als root läuft. Außerdem kann ein Logfile angegeben werden. Hier am besten eine Datei auf einem USB Stick angeben die für jedermann schreibbar sein muss. Damit sollten die Platten nach wie vor in den Standby gehen.<br />
<br />
=== Einrichtung unter Mac OS X ===<br />
Wie unter Linux braucht man die HMLAN-Emulationssoftware hmland, die man aus Quelltexten erstellen muss. Dazu muss man die Bibliothek libusb installieren, entweder mit einem der Paketmanager wie Fink, MacPorts oder Homebrew oder direkt aus den Quellentexten (Beispiel: "fink install libusb1-shlibs libusb1"). Hat man wie bei Linux das Quelltextarchiv für hmland heruntergeladen und ausgepackt, müssen die Dateien Makefile und hmcfgusb.c angepasst werden. <br />
<br />
Im Makefile muss man den Pfad zur libusb anpassen. Hat man libusb mit fink installiert, muss man, "/opt/local/" durch "/sw/" bei den CFLAGS und den LDFLAGS ersetzen und<br />
das "-lrt" aus den LDLIBS entfernen. Die Library librt gibt es bei Mac OS X nicht und wird anscheinend auch nicht gebraucht. (Stimmt das eigentlich?)<br />
<br />
In der Datei hmcfgusb.c muss man die Zeilen 130-134 mit dem Aufruf libusb_detach_kernel_driver auskommentieren oder löschen. Der geht nicht auf Mac OS X.<br />
<br />
Nach den Änderungen in den zwei Dateien, kann man wie bei Linux den Dämon hmland mit dem Kommando "make" erzeugen und mit "./hmland" ausführen. Automatisches Starten beim Booten mit launchd ist noch nicht probiert.<br />
<br />
Beim Start von hmland sollte man folgende Fehlermeldung in einer Endlos-Schleife erhalten:<br />
<source lang="text"><br />
Datum Zeit: Client 127.0.0.1 connected!<br />
Can't claim interface: Access denied (insufficient permissions)<br />
Can't find/open hmcfgusb!<br />
Datum Zeit: Connection to 127.0.0.1 closed!<br />
</source><br />
<br />
Auch ein Start von hmland mit Superuser-Rechten ändert daran nichts. Damit das claim interface klappt, muss man eine codeless kext in den Ordner /Library/Extensions legen. Ich habe dieses (http://mspdebug.sourceforge.net/misc/ex430rf2500-kext.zip) herunter geladen. Damit es funktioniert, muss man aber in der Datei Info.plist des Bundle die Properties idProduct und idVendor ändern, entweder mit dem Property List Editor oder einem anderen Texteditor. Die beiden Properties sind etwas versteckt bei Information Property List → IOKitPersonalities → ComIntf. Bei DebugIntf und DeviceDriver scheint man es nicht ändern zu müssen, aber schaden kann es nicht.<br />
<br />
<source lang="text"><br />
idProduct: 49167<br />
idVendor: 6943<br />
</source><br />
<br />
Die Rechte des kext-Bundles müssen auch noch gesetzt werden:<br />
<source lang="bash"><br />
chmod -R 755 ex430rf2500.kext<br />
chown -R root:wheel ex430rf2500.kext<br />
</source><br />
<br />
Danach die Datei ex430rf2500.kext in den Ordner /Library/Extensions legen und hmland sollte dann funktionieren.<br />
<br />
Es kann sein, dass ab Mac OS X 10.9 der Trick mit dem codeless kext nicht mehr funktioniert, aber noch ist das nicht getestet oder bestätigt. Langfristig kann man vielleicht auch eine kext mit einem Treiber für den HM-CFG-USB USB erstellen<br />
<br />
=== Einrichtung unter Windows ===<br />
Bei der Einrichtung und vermutlich auch dem Betrieb unter Windows 8.1 sind wegen der erweiterten Energieverwaltungsfunktionen die von eQ-3 [http://www.eq-3.de/Downloads/eq3/pdf_FAQ/Funk-Konfigurationsdapter-USB_Windos_8.1.pdf zusammengestellten Tipps] zu befolgen.<br />
<br />
=== Definition(en) in der Fhem-Konfiguration ===<br />
In der Fhem [[Konfiguration]] muss noch, sofern/sobald der ''hmland'' läuft, das Device eingerichtet werden mit den folgenden Anweisungen:<br />
:<code>define '''hmusb''' HMLAN 127.0.0.1:1234 </code><br />
wobei '''hmusb''' der frei wählbare Devicename ist. Anschließend sollte bzw. muss noch mit<br />
:<code>attr '''hmusb''' hmId <'''hmId'''> </code><br />
eine '''hmId''' zugeordnet werden (dabei bitte auch die Hinweise und Regeln beachten, die im Zusammenhang mit der [[Virtueller Controller VCCU|VCCU]] beschrieben sind!<br />
<br />
== Firmware Update ==<br />
Der Firmware Update (unter Linux) ist ebenfalls auf der [https://git.zerfleddert.de/cgi-bin/gitweb.cgi/hmcfgusb hmland-Internetseite] beschrieben. Auch die letzte bekannte Firmware-Version (0.967) steht dort zur Verfügung.<br />
<br />
== Bekannte Probleme ==<br />
=== Verbindung zu neueren hmland-Versionen nicht stabil ===<br />
Seit Version 0.100 meldet sich die HMLAN-Emulationssoftware als USB-Interface bei Fhem. Ältere Fhem-Versionen (vor dem 19.6.2015) brechen deshalb die Verbindung ab, da sie nur ein LAN-Interface erwarten.<br />
<br />
Lösung: Kommandozeilenparameter <code>-I</code> dem hmland-Aufruf hinzufügen, dann meldet sich dieser wieder als LAN-Interface.<br />
<br />
=== Stick nicht (mehr) ansprechbar ===<br />
Zitat aus dem {{Link2Forum|Topic=32502|Message=249122|LinkText=Fhem-Forum}}: <br />
:''... befürchte ich, dass dein Stick das Zeitliche gesegnet hat. Machen die Dinger leider sehr gerne... Ganz besonders beim Modus-Wechsel vom 10k- in den 100k-Modus, wenn man bei irgendeinem Device ein Firmwareupdate durchführt. <br />Die gute Nachricht ist, dass der Fehler bei sämtlichen Händlern bekannt ist und anstandslos getauscht wird.''<br />
<br />
=== Raspberry Pi ===<br />
Der USB-Stack am Raspberry Pi ist für viele Probleme verantwortlich. Daher sieht man öfter Fehlermeldungen:<br />
:<code>usb-transfer took more than 100ms (1039ms), this may lead to timing problems!</code><br />
<br />
Da das Timing bei HomeMatic wichtig ist führt das zu vielen Retransmits und zu unzuverlässigen Aktoren. Als Workaround kann man den USB-Stack auf die deutlich langsamere Version 1.1 stellen. Dazu fügt man folgenden Text am Anfang der Datei /boot/cmdline.txt ein:<br />
:<code>dwc_otg.speed=1</code><br />
<br />
== Weitergehende Informationen ==<br />
Es sind zwei Versionen des HM-CFG-USB im Umlauf:<br />
{{Randnotiz|RNTyp=r|RNText=Stand März 2016 ist allem Anschein nach kein HM-CFG-USB mehr im ELV Programm enthalten!}}<br />
* HM-CFG-USB-2: die aktuelle Version; Kennzeichen dieser Version: <br />
** Größe: 28 x 84 x 11,5&nbsp;mm<br />
** Gewicht: 18&nbsp;g<br />
** Antenne innenliegend<br />
* HM-CFG-USB: Vorgängerversion; Stand 12/2013 noch Restbestände im Handel verfügbar. Dokumentation ([http://files.voelkner.de/625000-649999/646462-an-01-ml-HM_Konfigurationsadapter_CFG_USB_de_en.pdf Völkner]); Kennzeichen:<br />
** Anschluss per separatem USB-Kabel<br />
** abstehende Stabantenne<br />
** Größe: 40 x 90 x 25&nbsp;mm<br />
** Gewicht: 45&nbsp;g<br />
<br />
== Links ==<br />
* Bedienungsanleitung [http://www.eq-3.de/Downloads/eq3/pdf_produkte/HM-CFG-USB-2_-UM-eQ-3-150129-web.pdf HM-CFG-USB-2, PDF]<br />
* Fhem-Forums {{Link2Forum|Topic=13071}}: HomeMatic USB Konfigurations-Adapter (HM-CFG-USB) in Fhem nutzen<br />
* [http://www.elv.de/homematic-usb-konfigurations-adapter-1.html ELV Shopseite] zum HM-CFG-USB<br />
* [http://www.eq-3.de/produkt-detail-zentralen-und-gateways/items/homematic-funk-konfigurationsadapter-usb.html eQ-3 Produktseite] zum "HomeMatic Funk-Konfigurationsadapter USB"; Downloads, technische Daten, etc.<br />
<br />
[[Kategorie:HomeMatic Components]]<br />
[[Kategorie:Interfaces]]<br />
[[Kategorie:OSX]]</div>MGuhttp://wiki.fhem.de/w/index.php?title=Anwesenheitssimulation&diff=15201Anwesenheitssimulation2016-04-23T18:25:56Z<p>MGu: /* Sonnenauf und -untergang */ Added Twilight</p>
<hr />
<div>Eine häufige Anwendung von Hausautomatisierungstechnik ist die Anwesenheitssimulation.<br />
Dabei sollen automatisch bei Abwesenheit Aktivitäten simuliert werden, die dem Beobachter von außen den Eindruck vermitteln das Haus sein bewohnt.<br />
__TOC__<br />
== Einleitung ==<br />
Denkbar sind eine ganze Reihe von Aktivitäten:<br />
* Lichter ein- und ausschalten<br />
* Geräusche abspielen<br />
* Rollläden bewegen<br />
* Betrieb eines Fernsehers simulieren<br />
* Rasensprenger ein- und ausschalten<br />
* Verstellbare Antennen, Kameras o.Ä. bewegen<br />
Jeder Aktor der von außen wahrnehmbar ist könnte zur Anwendung kommen.<br />
Entscheiden dabei ist die glaubwürdige Erscheinung dieser Aktivitäten.<br />
Ist die Simulation von außen als solche erkennbar, so bewirkt sie gerade das Gegenteil von dem, was man damit erreichen möchte.<br />
Ein potentieller Einbrecher würde durch die Anwesenheitssimulation nicht abgeschreckt sondern angelockt.<br />
<br />
Eher ungeeignete Beispiele sind Zeitschaltuhren die nur in ein oder zwei Räumen immer zur gleichen Zeit das Licht einschalten.<br />
Im Handel werden gerade für die Simulation von Fernsehern teilweise extrem schlechte Geräte angeboten.<br />
Sie spielen zyklisch immer das gleiche Muster mit teilweise harten, auffälligen und einprägsamen Farbwechseln.<br />
Ist dann der Zyklus auch noch relativ kurz, ist jedem Beobachter sehr schnell klar, dass in diesem Haus eine Simulation läuft.<br />
<br />
Betätigungszeiten von Lampen und Rollläden sollten den üblichen Gewohnheiten der Bewohner entsprechen, aber nicht mit messbar mechanischer Präzision durchgeführt werden.<br />
Gerade organisierte Banden reduzieren ihr Risiko durch sorgfältige Beobachtung, was sich heutzutage mit wetterfesten Action/Wild-Kameras sehr einfach und unauffällig bewerkstelligen lässt.<br />
Es sollte nie vergessen werden, dass die gegnerische Seite auch über technische Möglichkeiten verfügt.<br />
Zeigt ein solches Video präzise wiederkehrende Schaltzeiten, werden die Lichter wohl kaum von Bewohnern betätigt.<br />
<br />
Eine perfekte Anwesenheitssimulation ist extrem aufwändig wenn nicht unmöglich.<br />
Der Briefkasten müssten geleert werden, Vorhänge bewegt, die Einfahrt gefegt und nicht zuletzt sollte man ab und zu jemanden sehen der dort wohnt.<br />
Manche Einbrecher präparieren die Haustüre (stecken z.B. etwas in den Türspalt) um einige Tage danach sehen zu können ob die Türe überhaupt einmal bewegt wurde.<br />
Kaum jemand wird seine Hausautomatisierung hin und wieder die Haustüre entriegeln und öffnen lassen.<br />
<br />
== Methoden ==<br />
Anwesenheitssimulation ist immer ein Kompromiss zwischen Aufwand und Glaubwürdigkeit.<br />
<br />
=== Statistik ===<br />
Für Betätigungszeiten von Lampen und Jalousien gibt es Systeme die über die Betätigungszeiten der Bewohner eine Statistik erstellen.<br />
Sind die Bewohner nicht anwesend, führt das System zu ähnlichen aber eben nicht exakt gleichen Zeiten Betätigungen aus.<br />
Im einfachsten Fall werden für jedes Signal (z.B. Licht an/aus) Wahrscheinlichkeitsverteilungen bestimmt.<br />
Bei der Simulation wird dann regelmäßig "gewürfelt" ob das Signal betätigt werden soll.<br />
<br />
Komplizierter (aber auch glaubwürdiger) wird es, wenn man Zusammenhänge zwischen Signalen berücksichtigt.<br />
Ein Bewohner schaltet jeden Abend in einem bestimmten Raum das Licht an und lässt gleich darauf den Rollladen herunter.<br />
Bei der reinen Betrachtung einzelner Betätigungen könnte es vorkommen, dass erst der Rollladen herunter gelassen wird und man das danach eingeschaltete Licht nicht sieht.<br />
Die dafür nötigen Auswertungen des Verhaltens der Bewohner sind deutlich aufwändiger.<br />
<br />
Ein Kompromiss ist die explizite Vorgabe von Zusammenhängen, so dass das Hausautomatisierungssystem wieder nur die Verteilungen bestimmen muss.<br />
Geht z.B. nachts jemand auf die Toilette, so schaltet er erst das Licht im Gang an und etwas später in der Toilette.<br />
Auf dem Rückweg dann umgekehrt.<br />
Eine Simulation sollte also so eingestellt werden, dass vor dem Einschalten der Toilettenbeleuchtung auch der Gang eingeschaltet wird und auch etwas länger an bleibt.<br />
<br />
=== Vernetzung ===<br />
Die Vernetzung von Sensoren und Aktoren bei der Hausautomatisierung erlaubt es außerdem, Reaktionen wesentlich vielfältiger als üblich zu gestalten.<br />
Außenbeleuchtung mit Bewegungsmeldern sind jedem Einbrecher wohl bekannt.<br />
Es ist vielleicht lästig plötzlich im Licht zu stehen aber erschrecken kann man damit niemanden.<br />
Wesentlich irritierender ist es, wenn plötzlich im Haus ein Licht oder Geräusch an geht.<br />
In diesem Fall ist der Zusammenhang zum Bewegungsmelder nicht unmittelbar erkennbar<br />
Die einfache Vernetzung ermöglicht hier schon einen verbesserten Effekt.<br />
Mit etwas Fantasie lassen sich andere Anwendungen finden.<br />
Tagsüber könnte ein Bewegungsmelder statt eines Lichts z.B. den Rasensprenger einschalten.<br />
<br />
== Möglichkeiten in FEHM ==<br />
* [[RandomTimer|98_RandomTimer.pm]] ''Hilfsmodul, mit dem in einem bestimmten Zeitraum zu zufälligen Zeitpunkten Schaltvorgänge ausgelöst werden können''<br />
<br />
=== Beispiel: Lichter schalten ===<br />
Im Handle sind Schaltuhren mit Zufallsfunktion. Diese müssen aber oft umständlich eingestellt werden und lassen sich dann oft auch nicht anderweitig schalten. Man müsste immer wenn man das Haus länger verlässt die Schaltuhren alle aktivieren.<br />
Komfortabler und auch nicht unbedingt teurer geht das mit FHEM.<br />
Man benötigt <br />
# ein Gerät auf dem FHEM läuft (z.B. ein [[Raspberry_Pi|Raspberry Pi]] oder [[BeagleBone Black]]) mit<br />
# einem [[CUL]] und <br />
# ein paar preiswerte Funkschalter (z.B. intertechno ITR-1500 drei Stück für unter 28€).<br />
Damit lässt sich ein System zur zentralen Steuerung von Lampen, Fernsehern, Radios u.A. realisieren.<br />
Das FHEM installieren und den [[CUL]] konfigurieren.<br />
Dann die Funkschalter im FHEM mit einem frei gewählten 26-Bit Code anmelden (siehe [[Intertechno_Code_Berechnung#Definition]]).<br />
define sw_it_01 IT 01010101010101010101010101 0 0000<br />
define sw_it_02 IT 01010101010101010101010101 0 0001<br />
define sw_it_03 IT 01010101010101010101010101 0 0010<br />
Wer möchte kann auch jedem Schalter seinen eigenen 26-Bit Code geben.<br />
Dem Modul mitteilen, dass es sich um gewöhnliche Schalter (keine Dimmer) handelt.<br />
attr sw_it_XX model itswitch<br />
Das <code>XX</code> muss für jeden Schalter durch seine Nummer ersetzt werden.<br />
Jetzt kann man auf der Anzeige "Everything" die Schalter finden und durch klick auf <code>on</code> oder <code>off</code> betätigen. Um die Funkschalter an zu lernen muss man in den ersten 5 Sekunden nach dem Einstecken die Funktion <code>on</code> betätigen. Hat man das für alle Schalter durchgeführt, kann man sie jetzt über FHEM bedienen.<br />
<br />
==== Zufällig ====<br />
Um eine zufällige Betätigung zu erreichen, kann das Modul [[RandomTimer]] verwendet werden:<br />
define <name> RandomTimer <timespec_start> <device> <timespec_stop> [<timeToSwitch>]<br />
Wollen wir z.B. den Schalter <code>sw_it_01</code> zwischen 20:00 und 22:00 für eine Stunden einschalten können wir das mit diesem Befehl erreichen:<br />
define rand_sw_01 RandomTimer 20:00 sw_it_01 22:00 3600<br />
<br />
==== Sonnenauf und -untergang ====<br />
Das Modul [[SUNRISE_EL]] stellt die anhand der geographischen Position errechneten Zeiten für den Sonnenaufgang und den Sonnenuntergang zur Verfügung.<br />
Dazu stellt man zunächst die eigene Position ein (z.B. Berlin):<br />
attr global latitude 52.51861<br />
attr global longitude 13.40833<br />
Soll der Funkschalter <code>sw_it_01</code> immer Nachts eingeschaltet sein erreicht man das mit<br />
define sw_it_01_aus at *{sunrise(0)} set sw_it_01 off<br />
define sw_it_01_ein at *{sunset(0)} set sw_it_01 on<br />
Optional kann man den Zeitraum noch vorgeben (siehe [[SUNRISE_EL]]).<br />
Eine ähnliche Funktion unter Einbeziehung der Wetterlage bietet das Modul [[Twilight]].<br />
Mit ihm kann ein Twilight-Objekt für Berlin angelegt werden:<br />
define myTL Twilight 52.51861 13.40833 1 638242<br />
Die letzte Ziffer ist die Yahoo-Wetter-ID die man im [https://www.yahoo.com/news/weather/ Yahoo-Wetter-Dienst] ermitteln kann indem man {{Taste|Change location}} betätigt und dann die Nummer der URL entnimmt.<br />
Dieses Twilight-Objekt kann nun für Schaltaktionen verwendet werden.<br />
define sw_it_01_ein at *{twilight("myTL","sr_indoor","7:30","9:00")} set sw_it_01 on<br />
define sw_it_01_aus at *{twilight("myTL","ss_indoor","17:30","22:30")} set sw_it_01 off<br />
<br />
==== Kombination Zufall und Sonnenlauf ====<br />
Die Start- und Stopzeit des [[RandomTimer]] kann auch von rechnerischen Sonnenunter- oder -aufgang abhängig gemacht werden:<br />
define rand_sw_01 RandomTimer *{sunset_abs()} sw_it_01 *{sunset_abs(3*3600)} 3600<br />
<br />
== Hardware ==<br />
=== Lampen schalten ===<br />
* [[:Kategorie:Schalter (Empfänger)]]<br />
* [[FS20 ST Steckdosenfunkschalter]]<br />
* Funkschalter von Intertechno u.Ä. (siehe [[Intertechno Code Berechnung]])<br />
<br />
=== Rollläden, Jalousien u.Ä. ===<br />
* [[:Kategorie:Rollladensteuerung]]<br />
* [[EnOcean-FSB61-Aktor-Beschattungselemente-Rollladen]]<br />
* [[EnOcean-FSB14-RS485-Bus-Schaltaktor-2-Kanal-Beschattungselemente-Rollladen]]<br />
<br />
=== Betrieb eines Fernsehers simulieren ===<br />
* [[HM-LC-RGBW-WM Funk-RGBW-Controller]]<br />
<br />
== Links ==<br />
* [https://de.wikipedia.org/wiki/Anwesenheitssimulation Anwesenheitssimulation] in der deutsche Wikipedia<br />
* [http://www.elv.de/mein-elv-projekt-anwesenheitssimulation.html ELV - Wissen immer noch alle, dass Sie nicht da sind?]<br />
<br />
[[Kategorie:Code Snippets]]<br />
[[Kategorie:Glossary]]<br />
[[Kategorie:HOWTOS]]</div>MGuhttp://wiki.fhem.de/w/index.php?title=Anwesenheitssimulation&diff=15200Anwesenheitssimulation2016-04-23T18:06:27Z<p>MGu: /* Beispiel: Zufällig Lichter schalten */</p>
<hr />
<div>Eine häufige Anwendung von Hausautomatisierungstechnik ist die Anwesenheitssimulation.<br />
Dabei sollen automatisch bei Abwesenheit Aktivitäten simuliert werden, die dem Beobachter von außen den Eindruck vermitteln das Haus sein bewohnt.<br />
__TOC__<br />
== Einleitung ==<br />
Denkbar sind eine ganze Reihe von Aktivitäten:<br />
* Lichter ein- und ausschalten<br />
* Geräusche abspielen<br />
* Rollläden bewegen<br />
* Betrieb eines Fernsehers simulieren<br />
* Rasensprenger ein- und ausschalten<br />
* Verstellbare Antennen, Kameras o.Ä. bewegen<br />
Jeder Aktor der von außen wahrnehmbar ist könnte zur Anwendung kommen.<br />
Entscheiden dabei ist die glaubwürdige Erscheinung dieser Aktivitäten.<br />
Ist die Simulation von außen als solche erkennbar, so bewirkt sie gerade das Gegenteil von dem, was man damit erreichen möchte.<br />
Ein potentieller Einbrecher würde durch die Anwesenheitssimulation nicht abgeschreckt sondern angelockt.<br />
<br />
Eher ungeeignete Beispiele sind Zeitschaltuhren die nur in ein oder zwei Räumen immer zur gleichen Zeit das Licht einschalten.<br />
Im Handel werden gerade für die Simulation von Fernsehern teilweise extrem schlechte Geräte angeboten.<br />
Sie spielen zyklisch immer das gleiche Muster mit teilweise harten, auffälligen und einprägsamen Farbwechseln.<br />
Ist dann der Zyklus auch noch relativ kurz, ist jedem Beobachter sehr schnell klar, dass in diesem Haus eine Simulation läuft.<br />
<br />
Betätigungszeiten von Lampen und Rollläden sollten den üblichen Gewohnheiten der Bewohner entsprechen, aber nicht mit messbar mechanischer Präzision durchgeführt werden.<br />
Gerade organisierte Banden reduzieren ihr Risiko durch sorgfältige Beobachtung, was sich heutzutage mit wetterfesten Action/Wild-Kameras sehr einfach und unauffällig bewerkstelligen lässt.<br />
Es sollte nie vergessen werden, dass die gegnerische Seite auch über technische Möglichkeiten verfügt.<br />
Zeigt ein solches Video präzise wiederkehrende Schaltzeiten, werden die Lichter wohl kaum von Bewohnern betätigt.<br />
<br />
Eine perfekte Anwesenheitssimulation ist extrem aufwändig wenn nicht unmöglich.<br />
Der Briefkasten müssten geleert werden, Vorhänge bewegt, die Einfahrt gefegt und nicht zuletzt sollte man ab und zu jemanden sehen der dort wohnt.<br />
Manche Einbrecher präparieren die Haustüre (stecken z.B. etwas in den Türspalt) um einige Tage danach sehen zu können ob die Türe überhaupt einmal bewegt wurde.<br />
Kaum jemand wird seine Hausautomatisierung hin und wieder die Haustüre entriegeln und öffnen lassen.<br />
<br />
== Methoden ==<br />
Anwesenheitssimulation ist immer ein Kompromiss zwischen Aufwand und Glaubwürdigkeit.<br />
<br />
=== Statistik ===<br />
Für Betätigungszeiten von Lampen und Jalousien gibt es Systeme die über die Betätigungszeiten der Bewohner eine Statistik erstellen.<br />
Sind die Bewohner nicht anwesend, führt das System zu ähnlichen aber eben nicht exakt gleichen Zeiten Betätigungen aus.<br />
Im einfachsten Fall werden für jedes Signal (z.B. Licht an/aus) Wahrscheinlichkeitsverteilungen bestimmt.<br />
Bei der Simulation wird dann regelmäßig "gewürfelt" ob das Signal betätigt werden soll.<br />
<br />
Komplizierter (aber auch glaubwürdiger) wird es, wenn man Zusammenhänge zwischen Signalen berücksichtigt.<br />
Ein Bewohner schaltet jeden Abend in einem bestimmten Raum das Licht an und lässt gleich darauf den Rollladen herunter.<br />
Bei der reinen Betrachtung einzelner Betätigungen könnte es vorkommen, dass erst der Rollladen herunter gelassen wird und man das danach eingeschaltete Licht nicht sieht.<br />
Die dafür nötigen Auswertungen des Verhaltens der Bewohner sind deutlich aufwändiger.<br />
<br />
Ein Kompromiss ist die explizite Vorgabe von Zusammenhängen, so dass das Hausautomatisierungssystem wieder nur die Verteilungen bestimmen muss.<br />
Geht z.B. nachts jemand auf die Toilette, so schaltet er erst das Licht im Gang an und etwas später in der Toilette.<br />
Auf dem Rückweg dann umgekehrt.<br />
Eine Simulation sollte also so eingestellt werden, dass vor dem Einschalten der Toilettenbeleuchtung auch der Gang eingeschaltet wird und auch etwas länger an bleibt.<br />
<br />
=== Vernetzung ===<br />
Die Vernetzung von Sensoren und Aktoren bei der Hausautomatisierung erlaubt es außerdem, Reaktionen wesentlich vielfältiger als üblich zu gestalten.<br />
Außenbeleuchtung mit Bewegungsmeldern sind jedem Einbrecher wohl bekannt.<br />
Es ist vielleicht lästig plötzlich im Licht zu stehen aber erschrecken kann man damit niemanden.<br />
Wesentlich irritierender ist es, wenn plötzlich im Haus ein Licht oder Geräusch an geht.<br />
In diesem Fall ist der Zusammenhang zum Bewegungsmelder nicht unmittelbar erkennbar<br />
Die einfache Vernetzung ermöglicht hier schon einen verbesserten Effekt.<br />
Mit etwas Fantasie lassen sich andere Anwendungen finden.<br />
Tagsüber könnte ein Bewegungsmelder statt eines Lichts z.B. den Rasensprenger einschalten.<br />
<br />
== Möglichkeiten in FEHM ==<br />
* [[RandomTimer|98_RandomTimer.pm]] ''Hilfsmodul, mit dem in einem bestimmten Zeitraum zu zufälligen Zeitpunkten Schaltvorgänge ausgelöst werden können''<br />
<br />
=== Beispiel: Lichter schalten ===<br />
Im Handle sind Schaltuhren mit Zufallsfunktion. Diese müssen aber oft umständlich eingestellt werden und lassen sich dann oft auch nicht anderweitig schalten. Man müsste immer wenn man das Haus länger verlässt die Schaltuhren alle aktivieren.<br />
Komfortabler und auch nicht unbedingt teurer geht das mit FHEM.<br />
Man benötigt <br />
# ein Gerät auf dem FHEM läuft (z.B. ein [[Raspberry_Pi|Raspberry Pi]] oder [[BeagleBone Black]]) mit<br />
# einem [[CUL]] und <br />
# ein paar preiswerte Funkschalter (z.B. intertechno ITR-1500 drei Stück für unter 28€).<br />
Damit lässt sich ein System zur zentralen Steuerung von Lampen, Fernsehern, Radios u.A. realisieren.<br />
Das FHEM installieren und den [[CUL]] konfigurieren.<br />
Dann die Funkschalter im FHEM mit einem frei gewählten 26-Bit Code anmelden (siehe [[Intertechno_Code_Berechnung#Definition]]).<br />
define sw_it_01 IT 01010101010101010101010101 0 0000<br />
define sw_it_02 IT 01010101010101010101010101 0 0001<br />
define sw_it_03 IT 01010101010101010101010101 0 0010<br />
Wer möchte kann auch jedem Schalter seinen eigenen 26-Bit Code geben.<br />
Dem Modul mitteilen, dass es sich um gewöhnliche Schalter (keine Dimmer) handelt.<br />
attr sw_it_XX model itswitch<br />
Das <code>XX</code> muss für jeden Schalter durch seine Nummer ersetzt werden.<br />
Jetzt kann man auf der Anzeige "Everything" die Schalter finden und durch klick auf <code>on</code> oder <code>off</code> betätigen. Um die Funkschalter an zu lernen muss man in den ersten 5 Sekunden nach dem Einstecken die Funktion <code>on</code> betätigen. Hat man das für alle Schalter durchgeführt, kann man sie jetzt über FHEM bedienen.<br />
<br />
==== Zufällig ====<br />
Um eine zufällige Betätigung zu erreichen, kann das Modul [[RandomTimer]] verwendet werden:<br />
define <name> RandomTimer <timespec_start> <device> <timespec_stop> [<timeToSwitch>]<br />
Wollen wir z.B. den Schalter <code>sw_it_01</code> zwischen 20:00 und 22:00 für eine Stunden einschalten können wir das mit diesem Befehl erreichen:<br />
define rand_sw_01 RandomTimer 20:00 sw_it_01 22:00 3600<br />
<br />
==== Sonnenauf und -untergang ====<br />
Das Modul [[SUNRISE_EL]] stellt die anhand der geographischen Position errechneten Zeiten für den Sonnenaufgang und den Sonnenuntergang zur Verfügung.<br />
Dazu stellt man zunächst die eigene Position ein (z.B. Berlin):<br />
attr global latitude 52.51861<br />
attr global longitude 13.40833<br />
Soll der Funkschalter <code>sw_it_01</code> immer Nachts eingeschaltet sein erreicht man das mit<br />
define sw_it_01_aus at *{sunrise(0)} set sw_it_01 off<br />
define sw_it_01_ein at *{sunset(0)} set sw_it_01 on<br />
Optional kann man den Zeitraum noch vorgeben (siehe [[SUNRISE_EL]]).<br />
<br />
==== Kombination Zufall und Sonnenlauf ====<br />
Die Start- und Stopzeit des [[RandomTimer]] kann auch von rechnerischen Sonnenunter- oder -aufgang abhängig gemacht werden:<br />
define rand_sw_01 RandomTimer *{sunset_abs()} sw_it_01 *{sunset_abs(3*3600)} 3600<br />
<br />
== Hardware ==<br />
=== Lampen schalten ===<br />
* [[:Kategorie:Schalter (Empfänger)]]<br />
* [[FS20 ST Steckdosenfunkschalter]]<br />
* Funkschalter von Intertechno u.Ä. (siehe [[Intertechno Code Berechnung]])<br />
<br />
=== Rollläden, Jalousien u.Ä. ===<br />
* [[:Kategorie:Rollladensteuerung]]<br />
* [[EnOcean-FSB61-Aktor-Beschattungselemente-Rollladen]]<br />
* [[EnOcean-FSB14-RS485-Bus-Schaltaktor-2-Kanal-Beschattungselemente-Rollladen]]<br />
<br />
=== Betrieb eines Fernsehers simulieren ===<br />
* [[HM-LC-RGBW-WM Funk-RGBW-Controller]]<br />
<br />
== Links ==<br />
* [https://de.wikipedia.org/wiki/Anwesenheitssimulation Anwesenheitssimulation] in der deutsche Wikipedia<br />
* [http://www.elv.de/mein-elv-projekt-anwesenheitssimulation.html ELV - Wissen immer noch alle, dass Sie nicht da sind?]<br />
<br />
[[Kategorie:Code Snippets]]<br />
[[Kategorie:Glossary]]<br />
[[Kategorie:HOWTOS]]</div>MGuhttp://wiki.fhem.de/w/index.php?title=Benutzer:MGu&diff=15199Benutzer:MGu2016-04-23T17:03:34Z<p>MGu: /* Eigenes */ added Anwesenheitssimulation</p>
<hr />
<div>__NOTOC__<br />
__NOINDEX__<br />
== Persönliche Seite des Benutzers MGu ==<br />
''Kontaktaufnahme bitte durch <span class="plainlinks">[{{fullurl:{{TALKPAGENAME}}|action=edit&section=new}} {{Taste|Abschnitt Hinzufügen}}]</span> auf meiner [[{{TALKPAGENAME}}|Seite für Diskussionen]] oder per [[Special:EmailUser/MGu|e-Mail]].''<br />
=== Lesezeichen ===<br />
[[Datei:Kategoriestruktur.png|mini|Kategorien]]<br />
==== Dieses Wiki ====<br />
* [[Spezial:Version|Version dieses MediaWikis]]<br />
* [[Spezial:Präfixindex/Vorlage:|Vorlagen]]<br />
* [[Spezial:Präfixindex/Kategorie:|Kategorien]] (alt. [[Spezial:Kategorien|Kategorien]])<br />
* [[Spezial:Letzte_Änderungen|Neue Beiträge]]<br />
==== Inhalte hier ====<br />
* [[Erste Schritte in fhem]]<br />
* [[DevelopmentIntroduction]], [[Systemübersicht]]<br />
* [[:Kategorie:Code Snippets|Code Beispiele]], [[FHEM Command Beispiele]]<br />
* [[OpenWRT]], [[CUL]], [[BeagleBone Black]], [[Intertechno Code Berechnung]], [[RandomTimer]]<br />
==== Inhalte FHEM ====<br />
* [http://fhem.de/fhem_DE.html FHEM]<br />
:* [http://fhem.de/Heimautomatisierung-mit-fhem.pdf Heimautomatisierung mit fhem – Für Einsteiger]<br />
:* [http://fhem.de/commandref_DE.html Kommando Referenz]<br />
* [http://www.meintechblog.de/category/fhem HowTos in MeinTechBlog]<br />
* [http://www.meintechblog.de/2015/07/rudolf-koenig-im-interview-der-erfinder-von-fhem-zum-thema-smart-home/ Rudolf König im Interview]<br />
----<br />
{{/B|'''FHEM Forum'''}}<br />
==== FHEM Forum ====<br />
* Admins:<br />
:* [https://forum.fhem.de/index.php?action=profile;u=6 Martin Fischer], Administrator<br />
:* [https://forum.fhem.de/index.php?action=profile;u=10 Dr. Boris Neubert], Administrator<br />
* Moderatoren:<br />
* [https://forum.fhem.de/index.php?action=profile;u=8 Rudolf Koenig], Global Moderator<br />
* [https://forum.fhem.de/index.php?action=profile;u=86 UliM], Global Moderator<br />
* [https://forum.fhem.de/index.php?action=profile;u=825 krikan], Global Moderator<br />
* Aktive:<br />
* [https://forum.fhem.de/index.php?action=profile;u=430 justme1968], Developer<br />
* [https://forum.fhem.de/index.php?action=profile;u=12 Puschel74], Hero Member<br />
* [https://forum.fhem.de/index.php?action=profile;u=251 martinp876], Developer<br />
* [https://forum.fhem.de/index.php?action=profile;u=1996 frank], Hero Member<br />
* [https://forum.fhem.de/index.php?action=profile;u=9 eppi], Full Member<br />
* [https://forum.fhem.de/index.php?action=profile;u=13 borsti67], Full Member<br />
* ...<br />
{{/E}}<br />
----<br />
{{/B|'''Benutzer hier'''}}<br />
==== Benutzer hier ====<br />
===== <span class="plainlinks">[{{fullurl:Spezial:Benutzer|group=sysop}} Administratoren]</span> =====<br />
* [[FHEMWiki:Administratoren]]<br />
:* {{/U|Akw|Arno Willig|Autor von [http://www.bytefeed.com FHEMobile]}}<br />
:* {{/U|Ph1959de|[https://de.wikipedia.org/wiki/Peter_Henning_(Physiker) Peter A. Henning]|[http://forum.fhem.de/index.php?action=profile;u=376 Forum]}}<br />
::* {{/U|Pahenning|Peter}}<br />
:* {{/U|Soulman|Christian}}<br />
::* {{/U|Krikan|Christian}}<br />
:* {{/U|Generix}}<br />
===== [[Spezial:Aktive_Benutzer|Aktive Benutzer]] =====<br />
:* {{/U|Markusbloch|Markus Bloch|seit 4.5.2013, Autor [https://github.com/mhop/fhem-mirror/blob/master/fhem/FHEM/73_PRESENCE.pm <code>73_PRESENCE.pm</code>]}}<br />
:* {{/U|Muschelpuster|?|seit 29.4.2015}}<br />
:* {{/U|Krueuw|?|seit 19.2.2016}}<br />
:* {{/U|DS Starter|?|seit 21.3.2016}}<br />
{{/E}}<br />
==== Eigenes ====<br />
* [[/Archiv/]] Alte Beiträge aus der Diskussion<br />
* [[Spezial:Beiträge/MGu|Meine Beiträge]]<br />
* [[Spezial:Präfixindex/Benutzer:MGu|Meine eigenen Seiten]]<br />
* [[Spezial:Linkliste/Benutzer:MGu|Links auf mich (Signaturen u.ä.)]]<br />
* [[Anwesenheitssimulation]]<br />
* '''Beiträge (letzten 10):'''<br />
{{Special:Beiträge/MGu|limit=10}}</div>MGuhttp://wiki.fhem.de/w/index.php?title=Anwesenheitssimulation&diff=15198Anwesenheitssimulation2016-04-23T16:57:23Z<p>MGu: Erster Entwurf</p>
<hr />
<div>Eine häufige Anwendung von Hausautomatisierungstechnik ist die Anwesenheitssimulation.<br />
Dabei sollen automatisch bei Abwesenheit Aktivitäten simuliert werden, die dem Beobachter von außen den Eindruck vermitteln das Haus sein bewohnt.<br />
__TOC__<br />
== Einleitung ==<br />
Denkbar sind eine ganze Reihe von Aktivitäten:<br />
* Lichter ein- und ausschalten<br />
* Geräusche abspielen<br />
* Rollläden bewegen<br />
* Betrieb eines Fernsehers simulieren<br />
* Rasensprenger ein- und ausschalten<br />
* Verstellbare Antennen, Kameras o.Ä. bewegen<br />
Jeder Aktor der von außen wahrnehmbar ist könnte zur Anwendung kommen.<br />
Entscheiden dabei ist die glaubwürdige Erscheinung dieser Aktivitäten.<br />
Ist die Simulation von außen als solche erkennbar, so bewirkt sie gerade das Gegenteil von dem, was man damit erreichen möchte.<br />
Ein potentieller Einbrecher würde durch die Anwesenheitssimulation nicht abgeschreckt sondern angelockt.<br />
<br />
Eher ungeeignete Beispiele sind Zeitschaltuhren die nur in ein oder zwei Räumen immer zur gleichen Zeit das Licht einschalten.<br />
Im Handel werden gerade für die Simulation von Fernsehern teilweise extrem schlechte Geräte angeboten.<br />
Sie spielen zyklisch immer das gleiche Muster mit teilweise harten, auffälligen und einprägsamen Farbwechseln.<br />
Ist dann der Zyklus auch noch relativ kurz, ist jedem Beobachter sehr schnell klar, dass in diesem Haus eine Simulation läuft.<br />
<br />
Betätigungszeiten von Lampen und Rollläden sollten den üblichen Gewohnheiten der Bewohner entsprechen, aber nicht mit messbar mechanischer Präzision durchgeführt werden.<br />
Gerade organisierte Banden reduzieren ihr Risiko durch sorgfältige Beobachtung, was sich heutzutage mit wetterfesten Action/Wild-Kameras sehr einfach und unauffällig bewerkstelligen lässt.<br />
Es sollte nie vergessen werden, dass die gegnerische Seite auch über technische Möglichkeiten verfügt.<br />
Zeigt ein solches Video präzise wiederkehrende Schaltzeiten, werden die Lichter wohl kaum von Bewohnern betätigt.<br />
<br />
Eine perfekte Anwesenheitssimulation ist extrem aufwändig wenn nicht unmöglich.<br />
Der Briefkasten müssten geleert werden, Vorhänge bewegt, die Einfahrt gefegt und nicht zuletzt sollte man ab und zu jemanden sehen der dort wohnt.<br />
Manche Einbrecher präparieren die Haustüre (stecken z.B. etwas in den Türspalt) um einige Tage danach sehen zu können ob die Türe überhaupt einmal bewegt wurde.<br />
Kaum jemand wird seine Hausautomatisierung hin und wieder die Haustüre entriegeln und öffnen lassen.<br />
<br />
== Methoden ==<br />
Anwesenheitssimulation ist immer ein Kompromiss zwischen Aufwand und Glaubwürdigkeit.<br />
<br />
=== Statistik ===<br />
Für Betätigungszeiten von Lampen und Jalousien gibt es Systeme die über die Betätigungszeiten der Bewohner eine Statistik erstellen.<br />
Sind die Bewohner nicht anwesend, führt das System zu ähnlichen aber eben nicht exakt gleichen Zeiten Betätigungen aus.<br />
Im einfachsten Fall werden für jedes Signal (z.B. Licht an/aus) Wahrscheinlichkeitsverteilungen bestimmt.<br />
Bei der Simulation wird dann regelmäßig "gewürfelt" ob das Signal betätigt werden soll.<br />
<br />
Komplizierter (aber auch glaubwürdiger) wird es, wenn man Zusammenhänge zwischen Signalen berücksichtigt.<br />
Ein Bewohner schaltet jeden Abend in einem bestimmten Raum das Licht an und lässt gleich darauf den Rollladen herunter.<br />
Bei der reinen Betrachtung einzelner Betätigungen könnte es vorkommen, dass erst der Rollladen herunter gelassen wird und man das danach eingeschaltete Licht nicht sieht.<br />
Die dafür nötigen Auswertungen des Verhaltens der Bewohner sind deutlich aufwändiger.<br />
<br />
Ein Kompromiss ist die explizite Vorgabe von Zusammenhängen, so dass das Hausautomatisierungssystem wieder nur die Verteilungen bestimmen muss.<br />
Geht z.B. nachts jemand auf die Toilette, so schaltet er erst das Licht im Gang an und etwas später in der Toilette.<br />
Auf dem Rückweg dann umgekehrt.<br />
Eine Simulation sollte also so eingestellt werden, dass vor dem Einschalten der Toilettenbeleuchtung auch der Gang eingeschaltet wird und auch etwas länger an bleibt.<br />
<br />
=== Vernetzung ===<br />
Die Vernetzung von Sensoren und Aktoren bei der Hausautomatisierung erlaubt es außerdem, Reaktionen wesentlich vielfältiger als üblich zu gestalten.<br />
Außenbeleuchtung mit Bewegungsmeldern sind jedem Einbrecher wohl bekannt.<br />
Es ist vielleicht lästig plötzlich im Licht zu stehen aber erschrecken kann man damit niemanden.<br />
Wesentlich irritierender ist es, wenn plötzlich im Haus ein Licht oder Geräusch an geht.<br />
In diesem Fall ist der Zusammenhang zum Bewegungsmelder nicht unmittelbar erkennbar<br />
Die einfache Vernetzung ermöglicht hier schon einen verbesserten Effekt.<br />
Mit etwas Fantasie lassen sich andere Anwendungen finden.<br />
Tagsüber könnte ein Bewegungsmelder statt eines Lichts z.B. den Rasensprenger einschalten.<br />
<br />
== Möglichkeiten in FEHM ==<br />
* [[RandomTimer|98_RandomTimer.pm]] ''Hilfsmodul, mit dem in einem bestimmten Zeitraum zu zufälligen Zeitpunkten Schaltvorgänge ausgelöst werden können''<br />
<br />
=== Beispiel: Zufällig Lichter schalten ===<br />
Im Handle sind Schaltuhren mit Zufallsfunktion. Diese müssen aber oft umständlich eingestellt werden und lassen sich dann oft auch nicht anderweitig schalten. Man müsste immer wenn man das Haus länger verlässt die Schaltuhren alle aktivieren.<br />
Komfortabler und auch nicht unbedingt teurer geht das mit FHEM.<br />
Man benötigt <br />
# ein Gerät auf dem FHEM läuft (z.B. ein [[Raspberry_Pi|Raspberry Pi]] oder [[BeagleBone Black]]) mit<br />
# einem [[CUL]] und <br />
# ein paar preiswerte Funkschalter (z.B. intertechno ITR-1500 drei Stück für unter 28€).<br />
Damit lässt sich ein System zur zentralen Steuerung von Lampen, Fernsehern, Radios u.A. realisieren.<br />
Das FHEM installieren und den [[CUL]] konfigurieren.<br />
Dann die Funkschalter im FHEM mit einem frei gewählten 26-Bit Code anmelden (siehe [[Intertechno_Code_Berechnung#Definition]]).<br />
define sw_it_01 IT 01010101010101010101010101 0 0000<br />
define sw_it_02 IT 01010101010101010101010101 0 0001<br />
define sw_it_03 IT 01010101010101010101010101 0 0010<br />
Wer möchte kann auch jedem Schalter seinen eigenen 26-Bit Code geben.<br />
Dem Modul mitteilen, dass es sich um gewöhnliche Schalter (keine Dimmer) handelt.<br />
attr sw_it_XX model itswitch<br />
Das <code>XX</code> muss für jeden Schalter durch seine Nummer ersetzt werden.<br />
Jetzt kann man auf der Anzeige "Everything" die Schalter finden und durch klick auf <code>on</code> oder <code>off</code> betätigen. Um die Funkschalter an zu lernen muss man in den ersten 5 Sekunden nach dem Einstecken die Funktion <code>on</code> betätigen. Hat man das für alle Schalter durchgeführt, kann man sie jetzt über FHEM bedienen.<br />
<br />
Um eine zufällige Betätigung zu erreichen, kann das Modul [[RandomTimer]] verwendet werden:<br />
define <name> RandomTimer <timespec_start> <device> <timespec_stop> [<timeToSwitch>]<br />
Wollen wir z.B. den Schalter <code>sw_it_01</code> zwischen 20:00 und 22:00 für eine Stunden einschalten können wir das mit diesem Befehl erreichen:<br />
define rand_sw_01 RandomTimer 20:00 sw_it_01 22:00 3600<br />
<br />
== Hardware ==<br />
=== Lampen schalten ===<br />
* [[:Kategorie:Schalter (Empfänger)]]<br />
* [[FS20 ST Steckdosenfunkschalter]]<br />
* Funkschalter von Intertechno u.Ä. (siehe [[Intertechno Code Berechnung]])<br />
<br />
=== Rollläden, Jalousien u.Ä. ===<br />
* [[:Kategorie:Rollladensteuerung]]<br />
* [[EnOcean-FSB61-Aktor-Beschattungselemente-Rollladen]]<br />
* [[EnOcean-FSB14-RS485-Bus-Schaltaktor-2-Kanal-Beschattungselemente-Rollladen]]<br />
<br />
=== Betrieb eines Fernsehers simulieren ===<br />
* [[HM-LC-RGBW-WM Funk-RGBW-Controller]]<br />
<br />
== Links ==<br />
* [https://de.wikipedia.org/wiki/Anwesenheitssimulation Anwesenheitssimulation] in der deutsche Wikipedia<br />
* [http://www.elv.de/mein-elv-projekt-anwesenheitssimulation.html ELV - Wissen immer noch alle, dass Sie nicht da sind?]<br />
<br />
[[Kategorie:Code Snippets]]<br />
[[Kategorie:Glossary]]<br />
[[Kategorie:HOWTOS]]</div>MGuhttp://wiki.fhem.de/w/index.php?title=Intertechno_Code_Berechnung&diff=15191Intertechno Code Berechnung2016-04-23T14:13:51Z<p>MGu: /* Mit neuem Protokoll anlernen */</p>
<hr />
<div>'''Intertechno''' Systemkomponenten sind kostengünstige und weit verbreitete Funkschalter/-dimmer im 433 MHz Bereich, die man in fast jedem Baumarkt unter den Markennamen Intertechno, düwi, KlikAanKlikUit usw. erhalten kann. <br />
<br />
Es gibt eine Anzahl weiterer Hersteller/Handelsmarken mit ähnlicher Kodierung oder Einstellmöglichkeiten mit DIP Schaltern, die ebenfalls mit dem Intertechno Code geschaltet werden können. Dazu zählen von Usern bereits erfolgreich getestete Geräte von Elro AB440, FLS-100/m-e, Wetekom/Westfalia und weitere, theoretisch mögliche aber ungetestete Systeme wie Unitec oder Arctech Steckdosen (siehe [http://avr.börke.de/E-Funk.htm Börkes-HP])<br />
<br />
== Voraussetzungen in Fhem ==<br />
Schalten kann man die Intertechno Funkkomponenten in Fhem über verschiedene Wege. So z.B. über CUL/CUNO, Tellstick, [[AVR-NET-IO]].<br />
<br />
Hier beschrieben ist die Ansteuerung über CUL/CUNO, dessen Firmware für Intertechno erweitert wurde (Danke an Olaf Droegehorn). Momentan ist in CUL/CUNO das SENDEN von Intertechno Funk implementiert. Die Firmware muss mindestens den Stand 1.44 haben (Kontrolle der Version in den Fhem Detaildaten zum [[CUL]]/[[CUNO]]). Die CUL433/CUNO433 haben dabei volle Reichweite, die Versionen CUL868/CUNO868 funktionieren ebenfalls, haben aufgrund der nicht optimalen Antennenlänge und falschen Abstimmung für den Frequenzbereich aber nur eine eingeschränke Reichweite.<br />
<br />
=== Definition ===<br />
Die Definition des IT Gerätes in FHEM sieht für '''alte Geräte''' so aus:<br />
<source lang=text><br />
define myITSwitch IT <housecode><group_switch> <on-code> <off-code> [<dimup-code> <dimdown-code>]<br />
attr myITSwitch IODev CUL_x (CUNO_x)<br />
attr myITSwitch model itswitch<br />
</source><br />
Die weitere Anleitung soll die Bildung der Bitfolge für die Zusammensetzung des Schaltcodes erklären. <br />
Wichtig zu wissen ist auch, dass es sich um einen 3state code handelt, d.h. jedes Bit kann '''0,1 oder F''' sein!<br />
<br />
Die selbst '''lernenden''' neue '''Geräte''' definiert man in FHEM so:<br />
<source lang=text><br />
define <name> IT <26-Bit Adresse> <1-Bit Gruppen Bit> <4-Bit Gerät><br />
</source><br />
Dabei kann man die 26-Bit Adresse frei wählen, so dass Kollisionen mit Nachbarn sehr unwahrscheinlich werden.<br />
Einen GRR-3500 der über einen CUL gesteuert werden soll definiert man z.B. so<br />
<source lang=text><br />
define sw_it_outdoor IT 01010101010101010101010101 0 0000<br />
attr myITSwitch IODev CUL_0<br />
attr myITSwitch model itswitch<br />
</source><br />
Danach die {{Taste|CODE}}-Taste am Funkschalter betätigen (die LED blinkt) und über FHEM den Einschaltcode senden.<br />
<br />
== Original Intertechno System ==<br />
<br />
Durch Kombination von Hauscode und Geräetecode können maximal 256 Geräte verwendet werden. Dannn würde allerdings alle Hauscodes belegt, was eventuell zu Störungen mit Nachbarinstallationen führen könnte.<br />
<br />
=== Hauscode (die ersten vier Stellen (0-3) ===<br />
Der Hauscode wird auf dem Drehschalter auf der Rückseite eingestellt und hat die Bezeichnung '''A-P'''<br />
<br />
[[File:Img_3324_small.png|thumb|Intertechno Schalter]]<br />
{| class="wikitable"<br />
! Drehschalter !! Stelle 0-3<br />
|-<br />
| A || 0000<br />
|-<br />
| B || F000<br />
|-<br />
| C || 0F00<br />
|-<br />
| D || FF00<br />
|-<br />
| E || 00F0<br />
|-<br />
| F || F0F0<br />
|-<br />
| G || 0FF0<br />
|-<br />
| H || FFF0<br />
|-<br />
| I || 000F<br />
|-<br />
| J || F00F<br />
|-<br />
| K || 0F0F<br />
|-<br />
| L || FF0F<br />
|-<br />
| M || 00FF<br />
|-<br />
| N || F0FF<br />
|-<br />
| O || 0FFF<br />
|-<br />
| P || FFFF<br />
|}<br />
<br />
=== Gruppen-/Gerätecode (Stelle 4-7) ===<br />
Der zweite Drehschalter ist mit den Zahlen von 1-16 beschriftet. Das ist eine Zusammensetzung von Gruppe und Gerätecode und ergibt die nächsten 4 Stellen. Die dritte Spalte in der Tabelle zeigt die Zuordnung einer Intertechno YCT-100 / ITS-150 Fernbedienung. Diese ist mit Drehschalter auf der Rückseite (A-P), einem Gruppenschalter (1-4) , und je vier ein-/aus-Tasten belegt.<br />
<br />
[[File:Img_3325_small.png|right|thumb|Intertechno Fernbedienung]]<br />
<br />
{| class="wikitable"<br />
! Drehschalter !! Stelle 4-7 !! Fernbedienung Gruppe/Taste<br />
|-<br />
| 01 || 0000 || 1 - 1<br />
|-<br />
| 02 || F000 || 1 - 2<br />
|-<br />
| 03 || 0F00 || 1 - 3<br />
|-<br />
| 04 || FF00 || 1 - 4<br />
|-<br />
| 05 || 00F0 || 2 - 1<br />
|-<br />
| 06 || F0F0 || 2 - 2<br />
|-<br />
| 07 || 0FF0 || 2 - 3<br />
|-<br />
| 08 || FFF0 || 2 - 4<br />
|-<br />
| 09 || 000F || 3 - 1<br />
|-<br />
| 10 || F00F || 3 - 2<br />
|-<br />
| 11 || 0F0F || 3 - 3<br />
|-<br />
| 12 || FF0F || 3 - 4<br />
|-<br />
| 13 || 00FF || 4 - 1<br />
|-<br />
| 14 || F0FF || 4 - 2<br />
|-<br />
| 15 || 0FFF || 4 - 3<br />
|-<br />
| 16 || FFFF || 4 - 4<br />
|}<br />
<br />
=== Stellen 8-9 (Festwert 0F) ===<br />
<nowiki>Die Positionen 8-9 sind immer fest auf '''0F'''zu stellen</nowiki><br />
<br />
=== Stellen 10-11 (Ein/Aus) ===<br />
Bei den beiden letzten Stellen steht als Codierung für ON = FF und OFF = F0.<br />
<br />
=== Beispiele ===<br />
Drehschalter/Hauscode auf '''A'''<br />
<nowiki> Schalter 1 -&gt; 000000000F FF F0 (entspricht Fernbedienung Gruppe I und Schalter 1)<br />
Schalter 2 -&gt; 0000F0000F FF F0 (entspricht Fernbedienung Gruppe I und Schalter 2)<br />
Schalter 3 -&gt; 00000F000F FF F0 (entspricht Fernbedienung Gruppe I und Schalter 3)<br />
Schalter 4 -&gt; 0000FF000F FF F0 (entspricht Fernbedienung Gruppe I und Schalter 4)</nowiki><br />
<br />
Drehschalter/Hauscode auf '''L'''<br />
<nowiki> Schalter 11 -&gt; FF0F0F0F0F FF F0 (entspricht Fernbedienung Gruppe III und Schalter 3)<br />
Schalter 16 -&gt; FF0FFFFF0F FF F0 (entspricht Fernbedienung Gruppe IV und Schalter 4)</nowiki><br />
komplett für die fhem cfg also z.B. Hauscode A und Gruppe 1 Gerät/Schalter 1 und CUL Bezeichnung CUL1:<br />
<br />
<nowiki> define schalter1 IT 000000000F FF F0<br />
attr schalter1 IODev CUL1<br />
attr schalter1 model itswitch</nowiki><br />
<br />
=== Selbstlernende Intertechno Funksteckdosen (z.B. ITR-1500) ===<br />
Die selbst lernenden Intertechno Funksteckdosen haben ein neues erweitertes Protokoll bei dem ein 32-Bit Wort gesendet wird. Sie sind aber weiterhin kompatibel zum bisherigen 12-Bit Protokoll. In der culfw wird das alte Protokoll mit "Intertechno V1" und das neue mit "Intertechno V3" bezeichnet.<br />
<br />
==== Mit altem Protokoll anlernen ====<br />
{{Randnotiz|RNTyp=Fehl|RNText=Schon aus Gründen der Störsicherheit ist davon abzuraten bei neuen selbst lernenden Intertechno Geräten den alten 12-Bit Code zu verwenden. Dieser wird nur unterstützt um rückwärts kompatibel zu sein.}}<br />
Zum Anlernen der selbst lernenden Funksteckdosen muss ein gültiger(!) ON-Befehl in den ersten fünf Sekunden nach dem Einstecken der Funksteckdose in eine normalen Steckdose gesendet werden. Die Funksteckdosen haben drei Speicherplätze, so dass man beispielsweise ein ITR-1500 Set zuerst mit der Fernbedienung anlernen und anschließend eigene Codes von Fhem senden lassen kann. Damit man einen gültigen Code sendet, sucht man sich einfach eine beliebige Kombination aus der obigen Tabelle aus (z.B. C-1, C-2 und C-3) und ergänzt entsprechend um die immer identischen Stellen 8 und 9 (0F) und den ON- und OFF-Code (FF/F0).<br />
Das Senden der Codes von Fhem erfolgt am einfachsten, indem man sich die Steckdosen vorher in der Konfiguration so anlegt, wie man sie haben möchte und anschließend über die Weboberfläche den ON-Befehl gibt.<br />
<br />
Mitunter funktioniert das reine Senden des ON Befehls aber nicht, da einige dieser Steckdosen einen längeren ON Befehl benötigen und die Sendedauer bei Fhem/CUL/CUNO nicht beeinflusst werden kann. In diesem Fall nimmt man eine YCT-100 oder ITS-150 Fernbedienung, an der die gewünschte Adresse eingestellt werden kann. Zum Anlernen drückt man nun etwas länger auf den passenden Einschaltknopf, danach kann die Dose von Fhem normal geschaltet werden.<br />
<br />
==== Angelernten Code löschen ====<br />
Hier gibt es zwei Möglichkeiten.<br />
# Man sendet wie beim Anlernen innerhalb der ersten 5 Sekunden einen OFF-Befehl. Die Funksteckdosen quittiert diesen mit zweimaligem einschalten. Anschließend reagiert sie auf diesen Code nicht mehr.<br />
# Manche neueren Intertechno Geräte (z.B. GRR-3500) haben eine {{Taste|CODE}}-Taste. Durch kurzes drücken wird die Funksteckdose für 5 Sekunden in den Betrieb zum Anlernen gesetzt. Hält man diese Taste bis die LED hektisch blinkt, lässt sie dann los und drückt sie noch einmal kurz, so wird der gesammte Speicher für angelernte Codes gelöscht. Die Funksteckdose quittiert das wie üblich durch zweimaliges Einschalten.<br />
<br />
==== Mit neuem Protokoll anlernen ====<br />
Die neuen Funksteckdosen können laut Werbung ''"67 Millionen verschiedene Codes"'', das sind 26-Bits (2^26 = 67108864). Da hat die Werbung tatsächlich mal untertrieben. Tatsächlich arbeitet das neue Protokoll mit einem 32-Bit Wort. Jede neue Fernbedienung (z.B. ITT-1500) bekommt ab Werk einen fest einprogrammierten (und hoffentlich weltweit eindeutigen) ID-Code aus 26 Bits. Daran hängt sie ein 2-Bit Kommando und eine 4-Bit Geräte bzw. Tastenpaar Nummer:<br />
{| class="wikitable" style="border-style:solid; border-width:4px"<br />
|-<br />
|style="border-style:solid; border-width:4px"| 26-Bit ID des steuernden Geräts (Fernbedienung)<br />
|style="border-style:solid; border-width:4px"| 2-Bit Kommando <br />
|style="border-style:solid; border-width:4px"| 4-Bit Kanal-ID (Tastenpaar)<br />
|-<br />
|}<br />
Das 2-Bit Kommando ist ein ON oder OFF Befehl an ein einzelnes Gerät oder eine Gruppe.<br />
{| class="wikitable"<br />
|-<br />
! Befehl !! Bedeutung<br />
|-<br />
| 0 0 || Ein Gerät einschalten<br />
|-<br />
| 0 1 || Ein Gerät ausschalten<br />
|-<br />
| 1 0 || Alle Geräte (dieser Gruppe) einschalten<br />
|-<br />
| 1 1 || Alle Geräte (dieser Gruppe) ausschalten<br />
|-<br />
|}<br />
Die ITT-1500 hat zwar eine {{Taste|ALL OFF}}-Taste aber keine {{Taste|ALL ON}}.<br />
Ob das Einschalten als Gruppe generell unterstützt wird ist nicht bekannt.<br />
Einen gültiger Einschaltbefehl kann man am [[CUL]] z.B. mit diesem Kommando senden:<br />
<source lang=text><br />
is01010010101011101000000110010011<br />
</source><br />
Im Gegensatz zum alten Protokoll (Intertechno V1) wird das Binärwort hier nicht mit 0 und '''F''' sondern 0 und '''1''' gesendet.<br />
{| class="wikitable" style="border-style:solid; border-width:4px"<br />
|-<br />
|style="border-style:solid; border-width:4px"| '''is''' ''(Sende Intertechno Kommando)''<br />
|style="border-style:solid; border-width:4px"| '''01010010101011101000000110''' ''(Gerätecode Fernbedienung)''<br />
|style="border-style:solid; border-width:4px"| '''01''' ''(Kommando ON)''<br />
|style="border-style:solid; border-width:4px"| '''0011''' ''(Tastenpaar 4)''<br />
|-<br />
|}<br />
Die culfw unterscheidet anhand der Kommandolänge ob es sich um einen alten (12 Zeichen) oder neuen (32 Zeichen) Intertechno Befehl handelt.<br />
Genauso unterscheidet das IT-Modul in FHEM die beiden Formate:<br />
define <name> IT <10-bit-housecode> <off-code> <on-code> [<dimup-code>] [<dimdown-code>]<br />
und <br />
define <name> IT <26 bit Address> <1 bit group bit> <4 bit unit><br />
und setzt das Reading <code>protocol</code> auf <code>V3</code>.<br />
<br />
== FLS 100 ==<br />
[[File:FLS100.jpg|right|thumb|FLS100 - konfiguriert auf IV/3]]<br />
<br />
Beim FLS 100 von m-e.de gibt es nur 4 mögliche Einstellungen: '''I, II, III und IV'''. Dies entspricht der Gruppe auf der Fernbedienung.<br />
<br />
{| class="wikitable"<br />
! Drehschalter !! Stelle 0-3<br />
|-<br />
| I || 0FFF <br />
|-<br />
| II || F0FF<br />
|-<br />
| III || FF0F<br />
|-<br />
| IV || FFF0<br />
|}<br />
<br />
Die nächsten vier Stellen geben die Geräte ID an; diese ist identisch mit der Taste an der Fernbedienung.<br />
{| class="wikitable"<br />
! Drehschalter !! Stelle 4-7 !! Fernbedienung Taste<br />
|-<br />
| 1 || 0FFF || 1<br />
|-<br />
| 2 || F0FF || 2<br />
|-<br />
| 3 || FF0F || 3<br />
|-<br />
| 4 || FFF0 || 4<br />
|}<br />
<br />
Beim FLS 100 ist nur die letzte Stelle relevant, mit ON: F oder OFF: 0<br />
<br />
== REV Telecontrol ==<br />
[[File:Rev-funksteckdose-telecontrol-3500-w-008345.png|right|thumb|REV Telecontrol]]<br />
<br />
Die REV Telecontrol haben einen Dreh-Wahlschalter auf der Rückseite, mit dem sich der Hauscode (A - D) und der Gerätecode (1 - 3) bestimmen lässt. <br />
<br />
Die Codierung ist dabei:<br />
{| class="wikitable"<br />
! Hauscode !! Stelle 1-4<br />
|-<br />
| A || 1FFF<br />
|-<br />
| B || F1FF<br />
|-<br />
| C || FF1F<br />
|-<br />
| D || FFF1<br />
|}<br />
<br />
{| class="wikitable"<br />
! Gerätecode !! Stelle 5-7<br />
|-<br />
| 1 || 1FF<br />
|-<br />
| 2 || F1F<br />
|-<br />
| 3 || FF1<br />
|}<br />
<br />
Dazu (Stelle 8+9+10) noch drei statische Werte: 0FF.<br />
<br />
Der Code für '''An''' ist FF, für '''Aus''' 00.<br />
<br />
Beispiel: <br />
:<code>define My_Switch IT 1FFF1FF0FF FF 00 für A1</code><br />
Erfolgreich getestet mit CULfw V 1.49 CUL868.<br />
<br />
== Elro AB440 ==<br />
=== Möglichkeit 1: zu Intertechno-Codes umdippen ===<br />
[[File:ELRO-AB440_Funkschalter.jpg|right|thumb|Élro AB440 Funkschalter]]<br />
<br />
Günstige ELRO Funkschalter/Dimmer der Serie 440 lassen sich auch problemlos auf Intertechno Codierung "umdippen" und damit voll kompatibel mit allen möglichen A-P / 1-16 Intertechno Schaltcodes von Fhem aus nutzen. Dazu müssen die Dipschalter-Stellungen entsprechend Intertechno umgerechnet und gesetzt werden (1=ON, 0=OFF). <br />
<br />
Beispiele:<br />
{| class="wikitable"<br />
! Intertechno !! Elro Hauscode<br>1234 !! Elro Gerätecode<br>5ABCDE <br />
|-<br />
| A1 || 1111 || 111110 <br />
|-<br />
| A2 || 1111 || 011110 <br />
|-<br />
| A3 || 1111 || 101110 <br />
|-<br />
| A4 || 1111 || 001110 <br />
|-<br />
| A5 || 1111 || 110110 <br />
|-<br />
| A6 || 1111 || 010110 <br />
|-<br />
| A7 || 1111 || 100110 <br />
|-<br />
| A8 || 1111 || 000110 <br />
|-<br />
| A9 || 1111 || 111010 <br />
|-<br />
| A10 || 1111 || 011010 <br />
|-<br />
| A16 || 1111 || 000010 <br />
|-<br />
| C1 || 1011 || 111110 <br />
|-<br />
| C2 || 1011 || 011110 <br />
|}<br />
<br />
Weitere Erklärungen sind z.B. im [http://isn-systems.com/tools/it2elro Tool] der Fa. ISN-systems online berechnen lassen.<br />
<br />
Einziger Nachteil: Die originale Elro Fernbedienung funktioniert dann nicht mehr uneingeschränkt mit den Funkschaltern (eine Intertechno Fernbedienung funktioniert uneingeschränkt). Wenn man den Hauscode an der Fernbedienung einstellt, kann man durch drücken von z.T. mehreren Tasten gleichzeitig auch Intertechno schalten. Das ist aber nur was für den Notfall oder für Handakrobaten.<br />
<br />
<nowiki>15/16 -&gt; D<br />
13/14 -&gt; A+D<br />
11/12 -&gt; B+D<br />
09/10 -&gt; A+B+D<br />
07/08 -&gt; C+D<br />
05/06 -&gt; A+C+D<br />
03/04 -&gt; B+C+D<br />
01/02 -&gt; A+B+C+D</nowiki><br />
<br />
=== Möglichkeit 2: aus der vorhanden DIP-Schalterstellung den entsprechenden 10-digit InterTechno Code bestimmen ===<br />
Das ist prinzipiell ganz einfach. Hat man folgende DIP-Schalter-Stellung so muss man von links nach rechts einfach für jeden DIP gleich "ON" eine "0" und für "OFF" ein "F" definieren. Für die dargestellte DIP-Einstellung ergibt sich der damit der darunterstehende InterTechno Code:<br />
<br />
[[File:ELRO_0100101111.png]]<br />
<br />
<code>0F00F0FFFF</code><br />
<br />
Analog dazu ergeben sich für den gleichen Hauscode (Schalter 1-5) folgende Codes für die Funksteckdosen B bis E, wobei die Dose E mit der Originalfernbedienung nicht adressierbar ist, sich mit FHEM aber wunderbar schalten lässt.<br />
<br />
[[File:ELRO_0100110111.png]]<br />
<br />
<code>0F00FF0FFF</code><br />
<br />
[[File:ELRO_0100111011.png]]<br />
<br />
<code>0F00FFF0FF</code><br />
<br />
[[File:ELRO_0100111101.png]]<br />
<br />
<code>0F00FFFF0F</code><br />
<br />
[[File:ELRO_0100111110.png]]<br />
<br />
<code>0F00FFFFF0</code><br />
<br />
Dazu noch die Codes für AN = FF und AUS = F0 schaut eine vollständige Definition eines ELRO440 Funkschalters dann bsw. so aus:<br />
<br />
<nowiki> define ELRO_10110_A IT 0F00F0FFFF FF F0<br />
attr ELRO_10110_A IODev CUL_0<br />
attr ELRO_10110_A alias Stehlampe<br />
attr ELRO_10110_A fp_Grundriss 340,50,1,Stehlampe<br />
attr ELRO_10110_A group Schalter<br />
attr ELRO_10110_A model itswitch<br />
attr ELRO_10110_A room Wohnzimmer</nowiki><br />
<br />
[[File:b1-Funksteckdose-von-Toom.jpg|right|thumb|b1 Funksteckdose von Toom]]<br />
== b1 / Toom ==<br />
Das "Funksteckdosen-Set" der Marke b1 aus dem Toom-Baumarkt (3 Funksteckdosen + 1 Fernbedienung mit 4x ein/aus) funktioniert exakt wie ELRO, auch die DIP-Schalter sind genauso belegt. <br />
<br />
== Wetekom/Westfalia ==<br />
[[File:Westfalia-Funksteckdose.jpg|right|thumb|Westfalia Funksteckdose ZTC-S316A.]]<br />
Der eingestellte Hauscode ist F00F0FFF0F.<br />
<br />
In den Westfalia-Baumärkten gibt es Funksteckdosen mit Westfalia-Branding. Auf der Bedienungsanleitung steht aber Wetekom.<br />
<br />
Die Funksteckdosen selbst haben zehn DIP-Switches: 1234FEDCBA, während die Fernbedienung nur sechs hat: ABCDEF. Damit die Fernbedienung mit den Funksteckdosen funktioniert, darf man nur einen der DIP-Switches 1234 pro Funksteckdose auf ON schalten.<br />
<br />
Die Schaltung der DIP-Switches ABCDEF4321 entspricht direkt und in dieser Reihenfolge (also andersrum als direkt an der Funksteckdose) dem Hauscode und zwar entspricht ein Switch auf OFF einem F im Hauscode und ein Switch auf ON einer 0 im Hauscode.<br />
<br />
Die Steckdosen werden dann mit 01 ein- und mit 10 ausgeschaltet.<br />
<br />
Beispiel:<br />
define wf_steckdose IT F00F0FFF0F 01 10<br />
<br />
== Pollin Funksteckdosen ==<br />
<br />
Vom Aussehen sind die Steckdosen von Pollin (z.B. 3fach Set 550666) mit den Westfalia ZTC identisch, aber:<br />
<br />
* die DIP Schalter sind beschriftet von 0 bis 10;<br />
* der Adresscode entspricht dem invertierten ELRO 440 Code ->also (0=ON, 1=OFF)<br />
* der Code für "An" ist 0F, für "Aus" F0<br />
<br />
Beispiel für Adresse C2:<br />
<br />
define IT_C2 IT 0F00F0000F 0F F0<br />
<br />
== me micro-electric AS 73 ==<br />
<br />
[[Datei:Me_AS_73.JPG|right|thumb|micro-electric Funksteckdose AS 73]]<br />
<br />
Die micro-electric Funksteckdosen haben 10 DIP-Schalter: 123456ABCD.<br />
<br />
Der Hauscode wird an Sender und Steckdose mit 1-6 eingestellt, der Empfängercode A-D entspricht den Kanälen auf dem Handsender.<br />
<br />
DIP-Schalterstellung OFF entspricht F und ON entspricht 0.<br />
<br />
Die Steckdosen werden mit F0 ein- und mit 0F ausgeschaltet.<br />
<br />
Empfängercodes:<br />
{| class="wikitable"<br />
! Kanal !! Position 7-10<br />
|- <br />
| A || 0FFF <br />
|-<br />
| B || F0FF <br />
|-<br />
| C || FFF0 (Achtung: bei C und D sind die Codes vertauscht) <br />
|-<br />
| D || FF0F <br />
|}<br />
<br />
Beispiel:<br />
:<code>define Schalter_ME_A IT 0F0F000FFF F0 0F</code><br />
:<code>attr Schalter_ME_A IODev CUL1</code><br />
:<code>attr Schalter_ME_A model itswitch</code><br />
<br />
== Conrad / McPower Funkschaltset 3+1 ==<br />
Dieses Funkschaltset wird unter mehreren Namen in verschiedenen Bau- und Heimwerkermärkten sowie bei Conrad (Best Nr. 640475 - 62) vertrieben. Teilweise auch mit unterschiedlichen Schaltleistungen.<br />
Die Konfiguration funktioniert genauso wie beim [http://www.fhemwiki.de/wiki/Intertechno_Code_Berechnung#FLS_100 FLS100]<br />
<br />
== Noch nicht aufgeführte Geräte ==<br />
Wer ein Intertechno-ähnliches Gerät besitzt, das in dieser Liste noch nicht aufgeführt ist, muss die Kodierung selbst bestimmen. Dazu gibt es verschiedene Möglichkeiten, die in diesem Abschnitt aufgeführt werden. Die Ergebnisse bitte hier eintragen, um Nachfolgern die Arbeit zu ersparen!<br />
<br />
=== Audio-Eingang zur Messung ===<br />
Hier wird die Fernbedienung oder der Empfänger mit einer entsprechenden Schaltung an den Mikrofon-Eingang eines Rechners angeschlossen und mit einem Audio-Programm werden die Signalverläufe aufgenommen. Diese Methode wird [http://avr.börke.de/E-Funk.htm hier] näher erläutert.<br />
<br />
=== Platine analysieren ===<br />
[[File:Westfalia-Funkfernbedienung-hinten.jpg|right|thumb|Platine der Westfalia Funkfernbedienung ZTC-TC von hinten.]]<br />
[[File:Westfalia-Funkfernbedienung-vorne.jpg|right|thumb|Platine der Westfalia Funkfernbedienung ZTC-TC von vorne.]]<br />
<br />
Platine der Fernbedienung oder des Empfängers betrachten und so die Beschaltung des Decoder/Encoder Chips ermitteln. Bei der Wetekom-Fernbedienung wird beispielsweise der Chip LP801b verwendet, der funktional identisch zum PT2262 ist. Im [http://www.escol.com.my/Datasheets_specs/pt2262_1.pdf Datenblatt des PT2262] kann man dann die Beschaltung nachsehen. Nun betrachtet man den Verlauf der Leiterbahnen auf der Platine, um die Beschaltung des Chips zu ermitteln. So kann man beispielsweise bei der Wetekom-Fernbedienung sehen, dass die DIP-Switches A bis F auf die Eingänge A0 bis A5 geschaltet sind. Außerdem sieht man, mit welchen Eingängen die einzelnen Taster verbunden sind.<br />
<br />
Nun kann man messen, zwischen welchen Chip-Eingängen und Batteriepolen eine Spannung anliegt, bzw. (ohne Batterie) zwischen welchen Chip-Eingängen und Batteriepolen es einen Durchgang gibt, um zu ermitteln, wie die DIP-Switches schalten. Im Fall der Wetekom-Fernbedienung liegt keine Spannung zwischen den Eingängen und den beiden Batteriepolen an, wenn die DIP-Switches auf OFF stehen: Der Eingang liegt also auf F (Float). Wenn die DIP-Switches auf ON stehen, liegt nur eine Spannung zwischen dem Pluspol der Batterie und dem Eingang an, es gibt also einen Durchgang zwischen dem Minuspol und dem Eingang, so dass der Eingang auf V_SS liegt und damit 0 eingestellt ist.<br />
<br />
Bei den Eingängen D0 und D1 sieht man, dass der Batterie-Pluspol immer über einen Widerstand mit dem Dateneingang verbunden ist, also normalerweise 1 anliegt. Ist aber ein Ein-Taster gedrückt, wird der Eingang D1 direkt mit dem Minuspol der Batterie verbunden, bei den Aus-Tastern der Eingang D0 (die Verbindung der Aus-Taster ist auf den Bildern nicht besonders gut zu erkennen). Durch diese Verbindung wird der Eingang auf V_SS heruntergezogen und damit ist 0 eingestellt.<br />
<br />
=== Mit [[CUL]] im Debug-Modus Rohsignale empfangen und analysieren ===<br />
* Wurde im {{Link2Forum|Topic=5599|LinkText=Forum}} diskutiert.<br />
Ein 433MHz CUL kann mit dem Befehl <code>X67</code> Intertechno Kommandos mitlesen.<br />
Allerdings funktioniert das bei der "üblichen" Firmware nur lückenhaft.<br />
Dazu wurde bereits eine spezielle Variante der culfw entwickelt (siehe {{Link2Forum|Topic=24436|Message=105|LinkText=Forum}}).<br />
Die Ausgaben sind aber dann als doppelt so langes Binärwort im Hex-Format.<br />
Man muss quasi jedes zweite Bit streichen, da die einzelnen Bits als steigende bzw. fallende Flanken übertragen werden.<br />
Man kann aber damit auch einer neuen ITT-1500 ihre Kommandos und vor allem ihre 26-Bit ID entlocken.<br />
<br />
==== Mit CUL868 433MHz mitlesen ====<br />
Man kann auch mit der 868MHz Version des CUL Fernbedienungen von Intertechno mitlesen.<br />
Dazu die gewünschte Trägerfrequenz 433.92MHz * 2^16 / 26MHz = 1093745 = 0x10B071 als 24-Bit Teiler in die Register <code>FREQ[2-0]</code> schreiben und einen Reset ausführen.<br />
W0F10<br />
W10B0<br />
W1171<br />
B<br />
Danach kann man mit <code>X67</code> auf der Frequenz mitlesen. Mit <code>e</code> kann der EEPROM wieder auf den Default 0x21656A, 868.30MHz gestellt werden.<br />
<br />
[[Kategorie:Intertechno]]<br />
[[Kategorie:HOWTOS]]</div>MGu