FHEMWiki - Benutzerbeiträge [de]

DevelopmentOpenIssues

2014-11-06T13:52:07Z

Generix: /*  ;; und %% */

= Open Issues =
== Vor Entwicklungsbeginn von fhem 5.x zu klären ==
;Informationsumfang von xmllist
xmllist muss alle Werte mitnehmen, da sonst diese nie angezeigt werden.

xmllist hat auch weitere Daten:

* die Liste aller möglichen set Werte
* die Liste aller möglichen Attribute

Variante: Optionales Argument bei xmllist, das die Detailstufe oder der Informationsumfang eingrenzt.

;Aufbau einer Polling-Infrastruktur für Geräte, die nicht aktiv den Zustand melden
Beispiele: EMEM, M232.
Denkbar auch zur Identifikation von toten Geräten (USF1000 muss alle 30 Minuten einen Wert liefern; bleibt der n mal aus, wird eine Warnung erzeugt).

;Multithreading/Parallelisierung
Nähe zur Polling-Infrastruktur

;Dokumentation
Standardfunktionen:
AttrFn
AttrList
Clients
DefFn
GetFn
ListFn
Match
MatchList
NotifyFn
ParseFn
ReadFn
ReadyFn
SetFn
ShutdownFn
StateFn
UndefFn
WriteFn

;Erstellung eines Template-Moduls
Kommentierte Vorlage nn_Modul.pm fuer fhem 5.x.

== Erweiterungen/Verbesserungen ==
;Auslagerung der Funktionen für die Bildung von Mittelwerten über Zeitintervalle in ein eigenes Modul
z.B. Niederschlag pro Tag, Woche, Monat
Module: CUL_WS,KS300,CUL_EM

;contrib/dblog/93_DBLog ins FHEM-Verzeichnis aufrücken lassen

Kann benutzt werden, um Events in Datenbanken zu loggen.

Todos:

* FileLog-artigen Getter implementieren
* Komplettdump
* Auflistung der gespeicherten Daten
;Logs und Zeitreihen

Derzeit erfüllen Logs u.a. zwei grundverschiedene Aufgaben:

* der Benutzer kann sehen, was zu einem bestimmten Zeitpunkt passiert ist
* ein Frontend kann daraus eine Zeitreihe ableiten für eine Grafik

Es sollte geklärt werden, wie mit den daraus entstehenden Anforderungen an die Logs (möglichst gut menschenlesbar vs. möglichst gut maschinenverarbeitbar) optimal erfüllt werden können.

= Martins Liste der Readings, Internals, etc. =
Beispiele:
local, LOCAL
po, PortObj
socket, SOCKET
Type, TYPE

weitere teils unklare Bezeichnungen, die evtl. harmonisiert werden könnten:
DELTAUNIT, NUMUNITS, RAINUNIT, UNIT, UNITS, WINDUNIT
CODE, FamilyCode, HOUSE
INTERVAL, Timer, TRIGGERTIME
NAME, DeviceName
NR, DEVNR

dann sind da die Standardfunktionen bei Initialize, die einfach mal
dokumentiert werden müssten:
AttrFn
AttrList
Clients
DefFn
GetFn
ListFn
Match
MatchList
NotifyFn
ParseFn
ReadFn
ReadyFn
SetFn
ShutdownFn
StateFn
UndefFn
WriteFn

einer weiteren Betrachtung bedarf der Trigger für notify's:
CHANGED
sowie der eigentlichen
READINGS
die aber in einem anderen Kontext behandelt werden sollten.

einige feste Parameter können vorab schonmal gefiltert werden:
DEF
IODev
NAME
NR
STATE
TYPE

je nach IODev können weitere dazu kommen:
CUN868_MSGCNT
CUN868_RAWMSG
CUN868_RSSI
CUN868_TIME
LASTIODev
MSGCNT
RAWMSG
RSSI

bei X10 fiel auf, das in den Internals
MODEL
gesetzt wird, aber explizit noch einmal
model
in den Attributes vorkommen.

bei CUL_WS fiel auf, das die STATE summary sowohl in den Internals als auch in
den Readings auftaucht, obwohl in den Readings einzelne Werte vorhanden sind:
Internals:
STATE T: 16.7 H: 66.7
Readings:
humidity 66.7
state T: 16.7 H: 66.7
temperature 16.7

verbleibende Internals:

ALARM
ATTR
BasicFeePerMonth
BTN
CHANGETIME
Cmd
CONTENT
corr1
corr2
corr3
corr4
CostPerUnit
currentlogfile
DELTAFACTOR
DELTAUNIT
DeviceName
DEVNR
DIAMETER
FACTOR
FamilyCode
FD
FH
FHTID
FIXNEW
FIXRENUMBER
GEOMETRY
HEIGHT
Host
HOUSE
ID
IDX
INATTR
INPUT
INSET
INTERVAL
INTV_ALARM
INTV_CHECK
LENGTH
LINK
LircObj
local
LOCAL
LOCATION
logfile
MAX
MOBILE
MODEL
NEXT_OPEN
NR_CMD_LAST_H
NR_EMSG
NR_FMSG
NR_KMSG
NR_RMSG
NR_TMSG
NTM
NUMUNITS
OFFSET
OLDDEF
OW_FAMILY
OWFS_ID
OW_ID
OW_PATH
OW_SCALE
PARTIAL
pipeopentime
po
PortObj
pos
PRESENT
PREV
QUEUE
RAINUNIT
RA_Timeout
RE
REGEXP
REP
RExt
ROUTERID
SelectObj
SENSOR
SERIAL
SERIALS
socket
SOCKET
STEP
TCPDev
Timer
TRIGGERTIME
ttytype
Type
UNIT
UNITS
USBDev
VERSION
VOLATILE
WIDTH
WINDUNIT
XMIT
XMIT_TIME

==  ;; und %% ==
Das Problem ist, dass sowohl

<nowiki>define lampoff at 07:00 set Lamp1 off;; set Lamp2 off</nowiki>
als auch später (um 07:00)

<nowiki>set Lamp1 off; set Lamp2 off</nowiki>
vom gleichen AnalyzeCommandChain verarbeitet werden.

Diese erkennt an dem ;;, dass die erste Zeile nicht zu trennen ist, die zweite
aber schon. In der ersten Zeile wird dann auch ;; nach ; gewandelt, und intern
speichert das "at" nur noch "set Lamp1 off; set Lamp2 off". Bevor
AnalyzeCommand den Befehl ausführt, müssen perl- und shellskripte wieder ein ?? bekommen, um nicht von AnalyzeCommand an falscher Stelle zersägt zu werden.

Die "richtige" Lösung wäre so etwas wie

<nowiki>define lampoff at 07:00 [ set Lamp1 off; set Lamp2 off ]</nowiki>
erfordert aber einen Parser, der den passenden Klammer-zu findet, und das ist
aufwendig.

Uns gefällt @, %, %EVTPART1, usw. immer weniger, wir
finden "magische" Variablen wie $DEVICE, $EVENT, $EVTPART1, usw.
logischer - sie würden keinen Stress mit @@/%% verursachen. Wir wissen nicht, wie man einen schmerzlosen
Übergang durchführt, insb. mit den vielen fhemwiki-Beispielen.

[[Kategorie:Development]]

DevelopmentOpenIssues

2014-11-06T13:51:15Z

Generix: /* Erweiterungen/Verbesserungen */

= Open Issues =
== Vor Entwicklungsbeginn von fhem 5.x zu klären ==
;Informationsumfang von xmllist
xmllist muss alle Werte mitnehmen, da sonst diese nie angezeigt werden.

xmllist hat auch weitere Daten:

* die Liste aller möglichen set Werte
* die Liste aller möglichen Attribute

Variante: Optionales Argument bei xmllist, das die Detailstufe oder der Informationsumfang eingrenzt.

;Aufbau einer Polling-Infrastruktur für Geräte, die nicht aktiv den Zustand melden
Beispiele: EMEM, M232.
Denkbar auch zur Identifikation von toten Geräten (USF1000 muss alle 30 Minuten einen Wert liefern; bleibt der n mal aus, wird eine Warnung erzeugt).

;Multithreading/Parallelisierung
Nähe zur Polling-Infrastruktur

;Dokumentation
Standardfunktionen:
AttrFn
AttrList
Clients
DefFn
GetFn
ListFn
Match
MatchList
NotifyFn
ParseFn
ReadFn
ReadyFn
SetFn
ShutdownFn
StateFn
UndefFn
WriteFn

;Erstellung eines Template-Moduls
Kommentierte Vorlage nn_Modul.pm fuer fhem 5.x.

== Erweiterungen/Verbesserungen ==
;Auslagerung der Funktionen für die Bildung von Mittelwerten über Zeitintervalle in ein eigenes Modul
z.B. Niederschlag pro Tag, Woche, Monat
Module: CUL_WS,KS300,CUL_EM

;contrib/dblog/93_DBLog ins FHEM-Verzeichnis aufrücken lassen

Kann benutzt werden, um Events in Datenbanken zu loggen.

Todos:

* FileLog-artigen Getter implementieren
* Komplettdump
* Auflistung der gespeicherten Daten
;Logs und Zeitreihen

Derzeit erfüllen Logs u.a. zwei grundverschiedene Aufgaben:

* der Benutzer kann sehen, was zu einem bestimmten Zeitpunkt passiert ist
* ein Frontend kann daraus eine Zeitreihe ableiten für eine Grafik

Es sollte geklärt werden, wie mit den daraus entstehenden Anforderungen an die Logs (möglichst gut menschenlesbar vs. möglichst gut maschinenverarbeitbar) optimal erfüllt werden können.

= Martins Liste der Readings, Internals, etc. =
Beispiele:
local, LOCAL
po, PortObj
socket, SOCKET
Type, TYPE

weitere teils unklare Bezeichnungen, die evtl. harmonisiert werden könnten:
DELTAUNIT, NUMUNITS, RAINUNIT, UNIT, UNITS, WINDUNIT
CODE, FamilyCode, HOUSE
INTERVAL, Timer, TRIGGERTIME
NAME, DeviceName
NR, DEVNR

dann sind da die Standardfunktionen bei Initialize, die einfach mal
dokumentiert werden müssten:
AttrFn
AttrList
Clients
DefFn
GetFn
ListFn
Match
MatchList
NotifyFn
ParseFn
ReadFn
ReadyFn
SetFn
ShutdownFn
StateFn
UndefFn
WriteFn

einer weiteren Betrachtung bedarf der Trigger für notify's:
CHANGED
sowie der eigentlichen
READINGS
die aber in einem anderen Kontext behandelt werden sollten.

einige feste Parameter können vorab schonmal gefiltert werden:
DEF
IODev
NAME
NR
STATE
TYPE

je nach IODev können weitere dazu kommen:
CUN868_MSGCNT
CUN868_RAWMSG
CUN868_RSSI
CUN868_TIME
LASTIODev
MSGCNT
RAWMSG
RSSI

bei X10 fiel auf, das in den Internals
MODEL
gesetzt wird, aber explizit noch einmal
model
in den Attributes vorkommen.

bei CUL_WS fiel auf, das die STATE summary sowohl in den Internals als auch in
den Readings auftaucht, obwohl in den Readings einzelne Werte vorhanden sind:
Internals:
STATE T: 16.7 H: 66.7
Readings:
humidity 66.7
state T: 16.7 H: 66.7
temperature 16.7

verbleibende Internals:

ALARM
ATTR
BasicFeePerMonth
BTN
CHANGETIME
Cmd
CONTENT
corr1
corr2
corr3
corr4
CostPerUnit
currentlogfile
DELTAFACTOR
DELTAUNIT
DeviceName
DEVNR
DIAMETER
FACTOR
FamilyCode
FD
FH
FHTID
FIXNEW
FIXRENUMBER
GEOMETRY
HEIGHT
Host
HOUSE
ID
IDX
INATTR
INPUT
INSET
INTERVAL
INTV_ALARM
INTV_CHECK
LENGTH
LINK
LircObj
local
LOCAL
LOCATION
logfile
MAX
MOBILE
MODEL
NEXT_OPEN
NR_CMD_LAST_H
NR_EMSG
NR_FMSG
NR_KMSG
NR_RMSG
NR_TMSG
NTM
NUMUNITS
OFFSET
OLDDEF
OW_FAMILY
OWFS_ID
OW_ID
OW_PATH
OW_SCALE
PARTIAL
pipeopentime
po
PortObj
pos
PRESENT
PREV
QUEUE
RAINUNIT
RA_Timeout
RE
REGEXP
REP
RExt
ROUTERID
SelectObj
SENSOR
SERIAL
SERIALS
socket
SOCKET
STEP
TCPDev
Timer
TRIGGERTIME
ttytype
Type
UNIT
UNITS
USBDev
VERSION
VOLATILE
WIDTH
WINDUNIT
XMIT
XMIT_TIME

==  ;; und %% ==
Das Problem ist, dass sowohl

<nowiki>define lampoff at 07:00 set Lamp1 off;; set Lamp2 off</nowiki>
als auch später (um 07:00)

<nowiki>set Lamp1 off; set Lamp2 off</nowiki>
vom gleichen AnalyzeCommandChain verarbeitet werden.

Diese erkennt an dem ;;, dass die erste Zeile nicht zu trennen ist, die zweite
aber schon. In der ersten Zeile wird dann auch ;; nach ; gewandelt, und intern
speichert das "at" nur noch "set Lamp1 off; set Lamp2 off". Bevor
AnalyzeCommand den Befehl ausführt, müssen perl- und shellskripte wieder ein

<dl><dt><dl><dt> bekommen, um nicht von AnalyzeCommand an falscher Stelle zersägt zu werden.
</dt></dl>
</dd></dl>
Die "richtige" Lösung wäre so etwas wie

<nowiki>define lampoff at 07:00 [ set Lamp1 off; set Lamp2 off ]</nowiki>
erfordert aber einen Parser, der den passenden Klammer-zu findet, und das ist
aufwendig.

Uns gefällt @, %, %EVTPART1, usw. immer weniger, wir
finden "magische" Variablen wie $DEVICE, $EVENT, $EVTPART1, usw.
logischer - sie würden keinen Stress mit @@/%% verursachen. Wir wissen nicht, wie man einen schmerzlosen
Übergang durchführt, insb. mit den vielen fhemwiki-Beispielen.

[[Kategorie:Development]]

DevelopmentOpenIssues

2014-11-06T13:50:28Z

Generix: /* Vor Entwicklungsbeginn von fhem 5.x zu klären */

= Open Issues =
== Vor Entwicklungsbeginn von fhem 5.x zu klären ==
;Informationsumfang von xmllist
xmllist muss alle Werte mitnehmen, da sonst diese nie angezeigt werden.

xmllist hat auch weitere Daten:

* die Liste aller möglichen set Werte
* die Liste aller möglichen Attribute

Variante: Optionales Argument bei xmllist, das die Detailstufe oder der Informationsumfang eingrenzt.

;Aufbau einer Polling-Infrastruktur für Geräte, die nicht aktiv den Zustand melden
Beispiele: EMEM, M232.
Denkbar auch zur Identifikation von toten Geräten (USF1000 muss alle 30 Minuten einen Wert liefern; bleibt der n mal aus, wird eine Warnung erzeugt).

;Multithreading/Parallelisierung
Nähe zur Polling-Infrastruktur

;Dokumentation
Standardfunktionen:
AttrFn
AttrList
Clients
DefFn
GetFn
ListFn
Match
MatchList
NotifyFn
ParseFn
ReadFn
ReadyFn
SetFn
ShutdownFn
StateFn
UndefFn
WriteFn

;Erstellung eines Template-Moduls
Kommentierte Vorlage nn_Modul.pm fuer fhem 5.x.

== Erweiterungen/Verbesserungen ==
<dl><dt> Auslagerung der Funktionen für die Bildung von Mittelwerten über Zeitintervalle in ein eigenes Modul
</dt></dl>
z.B. Niederschlag pro Tag, Woche, Monat
Module: CUL_WS,KS300,CUL_EM

<dl><dt> contrib/dblog/93_DBLog ins FHEM-Verzeichnis aufrücken lassen
</dt></dl>
Kann benutzt werden, um Events in Datenbanken zu loggen.

Todos:

* FileLog-artigen Getter implementieren
* Komplettdump
* Auflistung der gespeicherten Daten
<dl><dt>Logs und Zeitreihen
</dt></dl>
Derzeit erfüllen Logs u.a. zwei grundverschiedene Aufgaben:

* der Benutzer kann sehen, was zu einem bestimmten Zeitpunkt passiert ist
* ein Frontend kann daraus eine Zeitreihe ableiten für eine Grafik

Es sollte geklärt werden, wie mit den daraus entstehenden Anforderungen an die Logs (möglichst gut menschenlesbar vs. möglichst gut maschinenverarbeitbar) optimal erfüllt werden können.

= Martins Liste der Readings, Internals, etc. =
Beispiele:
local, LOCAL
po, PortObj
socket, SOCKET
Type, TYPE

weitere teils unklare Bezeichnungen, die evtl. harmonisiert werden könnten:
DELTAUNIT, NUMUNITS, RAINUNIT, UNIT, UNITS, WINDUNIT
CODE, FamilyCode, HOUSE
INTERVAL, Timer, TRIGGERTIME
NAME, DeviceName
NR, DEVNR

dann sind da die Standardfunktionen bei Initialize, die einfach mal
dokumentiert werden müssten:
AttrFn
AttrList
Clients
DefFn
GetFn
ListFn
Match
MatchList
NotifyFn
ParseFn
ReadFn
ReadyFn
SetFn
ShutdownFn
StateFn
UndefFn
WriteFn

einer weiteren Betrachtung bedarf der Trigger für notify's:
CHANGED
sowie der eigentlichen
READINGS
die aber in einem anderen Kontext behandelt werden sollten.

einige feste Parameter können vorab schonmal gefiltert werden:
DEF
IODev
NAME
NR
STATE
TYPE

je nach IODev können weitere dazu kommen:
CUN868_MSGCNT
CUN868_RAWMSG
CUN868_RSSI
CUN868_TIME
LASTIODev
MSGCNT
RAWMSG
RSSI

bei X10 fiel auf, das in den Internals
MODEL
gesetzt wird, aber explizit noch einmal
model
in den Attributes vorkommen.

bei CUL_WS fiel auf, das die STATE summary sowohl in den Internals als auch in
den Readings auftaucht, obwohl in den Readings einzelne Werte vorhanden sind:
Internals:
STATE T: 16.7 H: 66.7
Readings:
humidity 66.7
state T: 16.7 H: 66.7
temperature 16.7

verbleibende Internals:

ALARM
ATTR
BasicFeePerMonth
BTN
CHANGETIME
Cmd
CONTENT
corr1
corr2
corr3
corr4
CostPerUnit
currentlogfile
DELTAFACTOR
DELTAUNIT
DeviceName
DEVNR
DIAMETER
FACTOR
FamilyCode
FD
FH
FHTID
FIXNEW
FIXRENUMBER
GEOMETRY
HEIGHT
Host
HOUSE
ID
IDX
INATTR
INPUT
INSET
INTERVAL
INTV_ALARM
INTV_CHECK
LENGTH
LINK
LircObj
local
LOCAL
LOCATION
logfile
MAX
MOBILE
MODEL
NEXT_OPEN
NR_CMD_LAST_H
NR_EMSG
NR_FMSG
NR_KMSG
NR_RMSG
NR_TMSG
NTM
NUMUNITS
OFFSET
OLDDEF
OW_FAMILY
OWFS_ID
OW_ID
OW_PATH
OW_SCALE
PARTIAL
pipeopentime
po
PortObj
pos
PRESENT
PREV
QUEUE
RAINUNIT
RA_Timeout
RE
REGEXP
REP
RExt
ROUTERID
SelectObj
SENSOR
SERIAL
SERIALS
socket
SOCKET
STEP
TCPDev
Timer
TRIGGERTIME
ttytype
Type
UNIT
UNITS
USBDev
VERSION
VOLATILE
WIDTH
WINDUNIT
XMIT
XMIT_TIME

==  ;; und %% ==
Das Problem ist, dass sowohl

<nowiki>define lampoff at 07:00 set Lamp1 off;; set Lamp2 off</nowiki>
als auch später (um 07:00)

<nowiki>set Lamp1 off; set Lamp2 off</nowiki>
vom gleichen AnalyzeCommandChain verarbeitet werden.

Diese erkennt an dem ;;, dass die erste Zeile nicht zu trennen ist, die zweite
aber schon. In der ersten Zeile wird dann auch ;; nach ; gewandelt, und intern
speichert das "at" nur noch "set Lamp1 off; set Lamp2 off". Bevor
AnalyzeCommand den Befehl ausführt, müssen perl- und shellskripte wieder ein

<dl><dt><dl><dt> bekommen, um nicht von AnalyzeCommand an falscher Stelle zersägt zu werden.
</dt></dl>
</dd></dl>
Die "richtige" Lösung wäre so etwas wie

<nowiki>define lampoff at 07:00 [ set Lamp1 off; set Lamp2 off ]</nowiki>
erfordert aber einen Parser, der den passenden Klammer-zu findet, und das ist
aufwendig.

Uns gefällt @, %, %EVTPART1, usw. immer weniger, wir
finden "magische" Variablen wie $DEVICE, $EVENT, $EVTPART1, usw.
logischer - sie würden keinen Stress mit @@/%% verursachen. Wir wissen nicht, wie man einen schmerzlosen
Übergang durchführt, insb. mit den vielen fhemwiki-Beispielen.

[[Kategorie:Development]]

RFXtrx

2014-02-05T14:38:15Z

Generix: /* FHEM-Modul: TRX_SECURITY */

Fhem unterstützt viele durch einen '''RFXtrx'''433 Transceiver erreichbare Geräte durch eigene Module.

== Übersicht ==
[[File:Rfxtrx433.png|500px|right]]

RFXtrx433 ist ein Transceiver (Funkempfänger und Funksender) mit USB-Anschluss für den Frenzbereich 433,92 MHz. Die Stromversorgung erfolgt über USB. Das Gerät hat einen FTDI-FT232R-USB-Interface-Chip installiert. Um RFXtrx433 nutzen zu können, muss das Betriebssystem einen entsprechenden Treiber für diesen Chip haben. Genutzt wird RFXtrx433 von Anwendern mit FHEM unter Linux, Fritzbox 7390 oder Windows.

Mit der mitgelieferten Firmware können viele Funksensoren in diesem Frequenzbereich empfangen werden und es ist möglich bestimmte Protokolle auch zu senden. Die unterstützten Protokolle sind von der installierten Firmware abhängig, die über das Windows-Programm [http://www.rfxcom.com/Downloads RFXflash] aktualisiert werden kann. Die neueste Firmware ist unter [http://www.rfxcom.com/Downloads http://www.rfxcom.com/Downloads] zu finden.

Weitere Informationen zu den von diesem Transceiver verfügbaren Protokolle beim Hersteller unter [http://www.rfxcom.com www.rfxcom.com]. Da der Hersteller die Anzahl der Geräte ständig aktualisiert und die FHEM-Treiber in der Freizeit des Autors geschrieben werden, sind in den FHEM-Treibern nur eine Untermenge implementiert. Sollte ein Gerät/Protokoll fehlen, das die Firma RFXCOM unterstützt, können Sie im [http://forum.fhem.de/ FHEM-Forum] in der Untergruppe RFXTRX nachfragen, ob dieses implementiert werden kann.

TRXtrx433 wird derzeit von FHEM mit den Modulen TRX, TRX_LIGHT, TRX-SECURITY und TRX_WEATHER für eine Reihe von Protokollen unterstützt.

Nachfolgend werden nur Geräte aufgezeigt, die bei der Erstellung dieses WIKI-Eintrages eingepflegt werden.

== FHEM-Modul: TRX_WEATHER ==
Dieses Modul unterstützt Wettersensoren, insbesondere Sensoren des Herstellers Oregon-Scientific. Unter [http://www.rfxcom.com/oregon.htm Wetter-Sensoren] finden Sie eine Liste der von der RFXtrx433-Firmware unterstützten Wetter-Sensoren (Oregon-Scientific, Cresta, La Crosse, TFA, UPM, ...). Das FHEM-Modul TRX_WEATHER implementiert derzeit den Empfang folgender Sensorentypen und Sensoren:

- '''Temperatursensoren''':

* "THR128": Oregon-Scientific THR128/138, THC138
* "THGR132N": Oregon-Scientific THC238/268,THN132,THWR288,THRN122,THN122,AW129/131
* "THWR800": Oregon-Scientific THWR800
* "RTHN318": Oregon-Scientific RTHN318
* "TS15C": TS15C
* "VIKING_02811" : Viking 02811
* "WS2300" : La Crosse WS2300
* "RUBICSON" : RUBiCSON
* "TFA_303133" : TFA 30.3133

- '''Temperatur-/Luftffeuchtigkeitssensoren''':

* "THGR228N": Oregon-Scientific THGN122/123, THGN132, THGR122/228/238/268 [[File:Thgr228n.png|92px|right|thumb|THGR228N]]
* "THGR810": Oregon-Scientific THGR810
* "RTGR328": Oregon-Scientific RTGR328
* "THGR328": Oregon-Scientific THGR328
* "WTGR800_T": Oregon-Scientific WTGR800
* "THGR918": Oregon-Scientific THGR918, THGRN228, THGN500
* "TFATS34C": TFA TS34C (Kat. Nr. 30.3150)
* "WT450H": UPM WT450H
* "TX3_T": LaCrosse TX3, TX4, TX17
[[File:TX3TH.jpg|92px|right|thumb|TX3TH]]

* '''Nicht unterstützt werden von der RFXCOM-Firmware:''' TFA 30.3166

- '''Temperatur-/Luftffeuchtigkeits-/Luftdrucksensoren''':

* "BTHR918": Oregon-Scientific BTHR918
* "BTHR918N": Oregon-Scientific/Huger BTHR918N, BTHR968 [[File:Bthr918n.png|96px|right|thumb|BTHR918N]]

- '''Regensensoren''':

* "RGR918": Oregon-Scientific RGR126/682/918
* "PCR800": Oregon-Scientific PCR800
* "TFA_RAIN": TFA-Regensensor (Kat. Nr. 30.3148)
* "RG700": UPM RG700

- '''Windsensoren''':

* "WTGR800_A": Oregon-Scientific WTGR800
* "WGR800_A": Oregon-Scientific WGR800
* "WGR918": Oregon-Scientific STR918, WGR918
* "TFA_WIND": TFA-Windsensor (Kat. Nr. 30.3149)
* "WDS500" : UPM WDS500

- '''UV-Sensoren''':

* "UVN128": Oregon UVN128, UV138
* "UVN800": Oregon UVN800
* "TFA_UV": TFA_UV-Sensor

- '''Waagen''':

* "BWR101": Oregon Scientific BWR101
* "GR101": Oregon Scientific GR101

- '''Energiesensoren''':

* "CM160": OWL CM119 und CM160
* "CM180": OWL CM180

Der Autor des Module setzt derzeit folgende Sensoren ein:

* Oregon Scientific: BTHR918, BTHR918N, PCR800, RGR918, THGR228N, THR128, THWR288A, WTGR800, WGR918

Von Nutzern wurde die Funktion folgender weiterer Sensoren gemeldet:

* Oregon Scientific GR101
* Oregon Scientific RTGR-328 (T/H)
* Honeywell TF-ATS34C (T/H)
* TFA Regensender 433 MHz, Kat. Nr. 30.3148, siehe [http://tfa-dostmann.de/index.php?id=57 TFA]
* TFA Windsender 433 MHz, Kat. Nr. 30.3149, siehe [http://tfa-dostmann.de/index.php?id=57 TFA]
* TFA T/H-Sender 433 MHz, Kat. Nr. 30.3150, siehe [http://tfa-dostmann.de/index.php?id=57 TFA]
* OWL CM160

=== FAQ: Wie bringe ich FHEM dazu nicht alle paar Sekunden den Zustand der Sensoren zu loggen? ===

Den ein oder anderen hat es schon genervt, dass die Oregon-Sensoren sehr gesprächig sind und damit das Filelog sehr groß wird.

Abhilfe: Hierzu kann man event-min-interval verwenden, um festzulegen, dass Events nur alle x Minuten generiert werden. event-on-change-reading kann man verwenden, dass Änderungen trotzdem sofort bemerkt werden.

Nachfolgend wird ein Oregon-Sensor BTHR918 so konfiguriert, dass er nur alle 10 Minuten loggt, aber beim State die Änderungen sofort geloggt werden.

define Alte_Garage TRX_WEATHER BTHR918
attr Alte_Garage event-min-interval state:600
attr Alte_Garage event-on-change-reading state
attr Alte_Garage event-on-update-reading .*

Damit man nicht alles loggt, kann man das Logging auf die Zeilen beschränken, die mit T: beginnen:

define FileLog_Alte_Garage FileLog /var/log/fhem/Alte_Garage-%Y.log Alte_Garage:T\x3a.*
attr FileLog_Alte_Garage logtype temp4press8:Temp/Press,temp4hum6dew10:Temp/Hum,text

Damit hat man dann folgendes im Log:

2013-08-27_12:21:29 Alte_Garage T: 19.9 H: 69 P: 1005 BAT: low
2013-08-27_12:31:37 Alte_Garage T: 19.9 H: 69 P: 1005 BAT: low
2013-08-27_12:41:45 Alte_Garage T: 19.9 H: 69 P: 1005 BAT: low
2013-08-27_12:47:27 Alte_Garage T: 20 H: 68 P: 1005 D: BAT: low
2013-08-27_12:57:35 Alte_Garage T: 20 H: 68 P: 1005 D: BAT: low

Wie man sieht, wird normalerweise alle 10 Minuten geloggt. Um 12:47:27 hat sich die Temperatur verändert und damit wurde ausserhalb der Reihe sofort ein Event generiert.

Ja, stimmt, ich muss noch die Batterie des Sensors wechseln (BAT: low) ;-)

== FHEM-Modul: TRX_SECURITY ==
Empfängt Security-Sensoren der Protokolle X10-Security, KD101 und Visonic.

'''KD101 kompatible Rauchmelder'''
Es wurden folgende KD101-Versionen gemeldet, die mit RXFtrx433 empfangen werden können:

* KD101LD
* KD101LA
* Flamingo FA20RF
* Elro RM150RF
* Unitec 46779

Die Rauchmelder KD101 (KD101LD, KD101LA, Flamingo FA20RF, Elro RM150RF) haben folgendes Verhalten:

* Wenn der KD101 selbst Rauch feststellt, kann man diesen Alarm über Funk nicht stoppen. Er sendet "alert" über Funk.
* Wenn man "alarm" über Funk an einen Rauchmelder sendet, dauert der Alarm nur wenige Sekunden. Für einen dauerhaften Alarm muss man also "alert" immer wieder senden.
* Wenn man die KD101 pairt, bekommen alle gepairten KD101 dieselbe ID.
* Wenn einer Rauch erkennt, triggert er alle KD101 mit derselben ID (also die gepairten).
* Nach Drücken der Taste "Test" am Rauchmelder sendet dieser "alert". Dadurch wird per autocreate der Rauchmelder angelegt.
* Ein KD101 sendet kein Keepalive-Signal. Man kann also nur testen, ob ein Rauchmelder noch funktioniert, indem man die Test-Taste drückt.

Mittels RFXtrx433 kann man die Befehle "alert" und "pair" an einen Rauchmelder senden.

Beispiel:

* set TRX_KD101_a5ca00 alert

Dies sendet den panic-Befehl an den Rauchmelder. Damit hört man ca. 3 Sekunden lang den nervigen Ton des Rauchmelders. Wer diesen länger haben will, muss das set nach ca. 3 Sekunden erneut auslösen.
Wer man also ein "set DEVICE alert" an einen Rauchmelder schickt, der mit anderen gepairt ist, dann wird der Alarm bei allen gepairten Rauchmeldern ausgelöst.

'''X10-Security-Sensoren'''
Folgende X10-Security-Sensoren werden erfolgreich eingesetzt:

* Türsensoren:
** X10 Türsensor Powerhouse DS10A ([http://www.domotica.famschenk.eu/DS10A_op_433Mhz.html Umbau auf 433 Mhz])
** Marmitek Türsensor DS90
* Bewegungssensoren:
** X10 Bewegungssensor Powerhouse MS10A ([http://www.domotica.famschenk.eu/MS10A-433.html Umbau auf 433 Mhz])[[File:Ms10a.png|70px|right|thumb|MS10A]]<div class="tright" style="clear:none">[[File:Ms90.png|82px|mini|ohne|MS90]]</div>
** Marmitek Bewegungssensor MS10E/BNL (kompatibel mit X10 MS10)
** Marmitek Bewegungssensor MS90
* Rauchmelder:
** Marmitek Rauchmelder SD90

Die oben genannten Sensoren können auch parallel zum RFXtrx433 mit der Marmitek-Alarmanlage SC9000 eingesetzt werden.

* Fernbedienungen:
** Marmitek KR21E [[File:Kr21e.png|60px|right|thumb|KR21E]]<div class="tright" style="clear:none">[[File:Sh624.png|75px|mini|ohne|SH624]]</div>
** Marmitek SH624

X10-Security-Sensoren senden etwa jede Stunde ein Keepalive-Paket, welches auch Informationen über den Batterieladestand enthält.

== FHEM-Modul: TRX_LIGHT.pm ==
Empfängt die Protokolle X10, ARC, ELRO AB400D, Waveman, Chacon EMW200, IMPULS, RisingSun, Philips SBC, AC, HomeEasy EU sowie ANSLUT lighting devices (switches and remote control).

ARC ist ein a Protokoll, welches von Geräten HomeEasy, KlikAanKlikUit, ByeByeStandBy, Intertechno, ELRO, AB600, Duewi, DomiaLite und COCO genutzt wird. Typisch ist, dass diese Geräte einen Drehschalter haben, um die Protkolladresse einzustellen.

Das ARC-Protokoll kennt keinen Dim-Befehl. Daher hat die Firmware vom RFXtrx433 und auch das FHEM-Modul TRX_LIGHT keinen solchen Befehl. Die verkauften Dimmer mit ARC-Protokoll starten gemäß meiner Information das Hoch-Dimmen nach Empfang zweier ON-Kommandos. Sobald dann das nächste ON oder OFF Kommando empfangen wird, wird das Dimmen beendet.
Das ganze ist also zeitabhängig und eigentlich nicht für die Hausautomatisierung gedacht, sondern für den Menschen, der sieht, ob der Dim-Level ok ist. Automatisiert bekommt man keine exakte prozentuale Dimmung hin, da man Dimmen nur über Timing erreichen kann.
Da FHEM nicht sehen kann wie weit gedimmt wurde, ist das allerdings nicht wirklich praktikabel und auch vom Gerät abhängig.
Unterschiedliche Geräte auch unterschiedliches Zeitverhalten.

AC ist ein Protokoll, welches verschiedene Hersteller nutzen, die die Adresse über einen LEARN-Button lernen: KlikAanKlikUit, NEXA, CHACON, HomeEasy UK.

''Achtung:''Es sollte beachtet werden, dass Tür- und Bewegungssensoren des AC-Protokolls (HomeEasy alt, Chacon, KlikAanKlikUit, NEXA...) teilweise für 3-5 Sekunden etwa 50 Funkpakete generieren, was zu Kollisionen mit anderen Paketen führen kann. Siehe [http://www.domoticaforum.eu/viewtopic.php?f=7&t=7276 Hinweis zur Nutzung von Bewegungssensoren]. Ich rate daher vom Einsatz von Bewegungssensoren mit dem AC-Protokoll ab.

Der Autor des Moduls setzt derzeit folgende Geräte ein:

* Eagle EyeMS14a Bewegungssensor ([http://www.domotica.famschenk.eu/MS14A_OP_433.92.html Umbau auf 433 Mhz])
* Elro AB600 Funksender und Steckdosen

Nutzer haben die Funktion folgender Geräte gemeldet:

* KAKU AWST-6000 (Bewegungsmelder, sendet on/off)
* KAKU AMST-606 (Tür-/Fenster-Kontakt, sendet all_level/off)
* KAKU AWMT-230 (Unterputzsender, sendet on/off)
* KAKU APA3-1500R (Schalter & Handsender, nur on/off/all_off)
* KAKU CDB-6500AC (Türklingel, sendet nur chime)

== PT2262 empfangen und senden mit TRX_LIGHT.pm ==
'''WARNUNG:'''PT2262-Codes sollten nur verwendet werden, wenn unbedingt erforderlich. Normalerweise reicht die Nutzung der von RFXCOM vordefinierten Dekodierungen wie das ARC-Protokoll aus. Bei manchen Geräten mit dem Chip PT2262 kann dies evtl. nicht ausreichen. Sinnvollerweise sollte man prüfen, ob das Gerät wirklich einen Funk-Encoder-IC PT2262 oder SC2262 enthält.

'''ACHTUNG:''' Es können nur PT2262-Codes empfangen werden, wenn das Pulse-Timung 350 usec ist (Siehe Kapitel 8 im RFXtrx User Guide). Gemäß Seite 6 im Dokument http://www.escol.com.my/Datasheets_specs/pt2262_1.pdf‎ sollte für den Oszillator normalerweise ein 3,3 Mega-Ohm-Widerstand eingebaut sein.

=== PT2262-Format empfangen ===
Das Funk-Encoder-IC PT2262 der Firma PTC Taiwan (siehe [http://pdf.dzsc.com/88889/21967.pdf http://pdf.dzsc.com/88889/21967.pdf]) wird häufig in Fernbedienungen von Funksteckdosen und auch anderen Funkgeräten im 433-Mhz-Bereich verwendet. Es gibt viele PIN kompatible ICs wie z.B. der SC2262.

Es werden hierbei 12 Zeichen im Tristate-Format (0, 1, 2 bzw. f) übertragen. Der erste Teil der Zeichen stellt die Adresse und die darauffolgenden Zeichen die Datenbits (Zeichen 0 oder 1) dar.
Die verwendeten Fernbedienungen haben häufig Dip-Schalter mit drei Zuständen (also 0,1,2), mit denen sich die Adressen einstellen lassen.

Das Protokoll ist vom Aufbau ähnlich zum ARC-Protokoll.

Dabei lassen sich die ersten 6-12 Zeichen als Adressen (A0 bis A11) und die letzten 0-6 Zeichen (D5-D0) als Datenbits nutzen. Es sind damit insgesamt folgende Kombinationen der Bits möglich:

<nowiki>A0 A1 A2 A3 A4 A5 A6 A7 A8 A9 A10 A11
A0 A1 A2 A3 A4 A5 A6 A7 A8 A9 A10 D0
A0 A1 A2 A3 A4 A5 A6 A7 A8 A9 D1 D0
A0 A1 A2 A3 A4 A5 A6 A7 A8 D2 D1 D0
A0 A1 A2 A3 A4 A5 A6 A7 D3 D2 D1 D0
A0 A1 A2 A3 A4 A5 A6 D4 D3 D2 D1 D0
A0 A1 A2 A3 A4 A5 D5 D4 D3 D2 D1 D0</nowiki>
Damit lassen sich also maximal 6-Bit-Daten übertragen. Dies reicht für einfache Schaltaufgaben, aber nicht für Anwendungen wie beispielsweise Thermometer.

RFXtrx433 läßt sich über RFXmngr so konfigurieren, dass die 12-Zeichen-Datagramme des PT2262-Formats als 24-Bit-Nutzdaten bzw. 3 Bytes empfangen werden können. Dazu kann man in RFXmngr das Protokoll Lighting4 einschalten, wodurch gleichzeitig die Verarbeitung des ARC-Protokolls ausgeschaltet wird.
Hinweise zur Nutzung sind in [http://www.rfxcom.com/Documents/RFXtrx%20User%20Guide.pdf http://www.rfxcom.com/Documents/RFXtrx%20User%20Guide.pdf] (Kapitel "8. Transmit undecoded ARC commands") zu finden.

Das FHEM-Modul TRX_LIGHT erlaubt die Verarbeitung des PT2262-Formates.

Sobald Lighting4 eingeschaltet wird, werden die einzelnen Bits dem Gerät TRX_PT2262 zugeordnet. Sofern dieses noch nicht vorhanden ist, wird diesen per Autocreate definiert und ein entsprechendes Filelog angelegt.

Wenn beispielsweise ein Nutzer einen Taster einer ELRO AB600 Fernbedienung drückt, werden je nach Codierung der Adresse folgende Codes im Filelog generiert:

* Drücken der Taste "on":
<nowiki>2012-12-30_21:40:42 TRX_PT2262 111101110111</nowiki>
* Drücken von "off":
<nowiki>2012-12-30_21:40:47 TRX_PT2262 111101110110</nowiki>
Auf diese Weise kann ein Nutzer sehen, welche PT2262-Codes von RFXtrx433 empfangen werden.

Der Nutzer muss danach selbst entscheiden, welche Zeichen Adressen und welche Daten darstellen und was die Daten bedeuten. Im oben genannten Beispiel ist dies relativ einfach. Man sieht, dass sich nur das letzte Bit ändern und die Zustände 0 und 1 annimmt. Es ist daher anzunehmen, dass die ersten 11 Zeichen die Adresse repräsentieren.

TRX_LIGHT bietet die Möglichkeit den Adressprefix, die sogenannte deviceid selbst in einem define-Statement festzulegen.
Die Konvention ist dabei, dass die einzelnen Zeichen der Base4-Codierung angegeben werden müssen:

<nowiki>define <name> TRX_LIGHT PT2262 <deviceid> <devicelog> [<commandcodes>]</nowiki>
In commandcodes gibt man optional an wie die Ziffern Strings wie beispielsweise "on" oder "off" zugeordnet werden sollen. Dabei können über Komma getrennt wie die Ziffern den einzelnen Strings zugeordnet werden sollen. Jede einzelne Zuordnung wird über : angegeben. Zusätzlich sollte ein entsprechendes FileLog definiert werden.

Beispiel:

define TRX_MYREMOTE1 TRX_LIGHT PT2262 11110111011 light 0:off,1:on

define FileLog_TRX_MYREMOTE1 FileLog /var/log/fhem/TRX_MYREMOTE1-%Y.log TRX_MYREMOTE1

In diesem Fall wird die Ziffer 0 "off" und die Ziffer 1 "on" zugeordnet.

Damit werden nach Drücken der Tasten on und off folgende Einträge im Filelog wie folgt generiert:

==> TRX_MYREMOTE1-2012.log <==
2012-12-30_21:54:56 TRX_MYREMOTE1 light: on
2012-12-30_21:54:56 TRX_MYREMOTE1 on

==> TRX_MYREMOTE1-2012.log <==
2012-12-30_21:54:59 TRX_MYREMOTE1 light: off
2012-12-30_21:54:59 TRX_MYREMOTE1 off

=== PT2262-Format senden ===
Mit dem Funk-Decoder-IC PT2272 lassen sich Signale von PT2262-Sendern empfangen.
RFXtrx433 ist in der Lage Funksignale im PT2262-Format zu senden, die dann mit Geräten empfangen werden können, die über den Funk-Decoder-IC PT2272 verfügen. Dazu ist es nicht erforderlich in RFXmngr das Protokoll Lighting4 einzuschalten.

PT2262-Codes können über ein set-Kommando des vorher zu definierenden PT2262-Devices gesendet werden. Die Definition wurde auch schon bei "PT2262-Format empfangen" beschrieben.

<nowiki>define <name> TRX_LIGHT PT2262 <deviceid> <devicelog> [<commandcodes>]</nowiki>
Beispiel:

<nowiki>define TRX_MYREMOTE1 TRX_LIGHT PT2262 11110111011 light 0:off,1:on</nowiki>
Sobald das Device definiert wurde, kann der Code mittels set gesendet werden. Dabei kann man entweder der Base4-Code direkt angegeben werden oder der String der in <commandcodes> definiert wurde.

Beispiele (senden von 1):

<nowiki>set TRX_MYREMOTE1 1</nowiki>
<nowiki>set TRX_MYREMOTE1 on</nowiki>
<nowiki>set TRX_MYREMOTE1 off</nowiki>
Damit ein PT2262 Code gesendet werden kann, muss der Base4-Code bestehend aus <deviceid> und den Daten genau 12 Base4-Zeichen haben.

Die mittels <commandcodes> definierten Strings werden in der Auswahlliste von set in der Weboberfläche von FHEM berücksichtigt.

== Fragen und Antworten (FAQ) ==

=== Warum wird mein RFXtrx433 nicht erkannt? ===

Das Gerät hat einen FTDI-FT232R-USB-Interface-Chip installiert. Um RFXtrx433 nutzen zu können, muss das Betriebssystem einen entsprechenden Treiber für diesen Chip haben. Dies ist normalerweise bei Linux oder Fritzbox 7390 der Fall. Bei Windows muss ein entsprechender Treiber installiert werden. Siehe auch http://www.rfxcom.com/Documents/RFXtrx%20User%20Guide.pdf .

Bei Fritzbox 7270 und 7170 werden vom Hersteller AVM mit der Firmware keine Treiber für den FTDI-FT232R-USB-Interface-Chip mitgeliefert.

=== Warum werden die Tasten meiner Fernbedienung nicht alle erkannt? ===
Ist geklärt, dass die Fernbedienung von der Firmware supportet wird? Gerade beim ARC-Protokoll ist es häufig so, dass die Hersteller unterschiedliche Codierungen verwenden.

Es wurde berichtet, dass die Tasten folgende Fernbedienungen von der Firnware des RFXtrx433 nicht alle richtig erkannt werden:
* ELRO AB440RA
Bei folgende Fernbedienungen wurden berichtet, dass diese richtig erkannt werden:
* ELRO AB600RA

Bitte weitere Fernbedienungen melden!
[[Kategorie:Interfaces]]

Notify

2014-01-07T10:58:53Z

Generix: /* Erklärung */

== Notify, das mächtige Tool ==
Ein Versuch, die Funktionsweise von Notify verständlich zu erklären.
Da ich nur ein [[EIB / KNX|KNX (EIB)]] System habe, beziehen sich alle meine Beispiele auf KNX.



WICHTIG: per Web editieren und den DEF Knopf benutzten.
Damit wird der Perlcode einfacher.

Was ist notify?
Notify ist eine der mächtigsten Funktionen bei Fhem. Sie dient dazu, Aktionen abhängig von einem anderen Status bzw. Ereignis auszulösen. Es ist damit möglich, Logikfunktionen im Fhem abzubilden.

Z.B.: das Licht in der Küche wird eingeschaltet ====> draus folgt, dass auch das Radio eingeschaltet wird.

=== Syntax von notify ===
:<code>define <name> notify <pattern> <command></code>

Das Pattern ist sehr wichtig. Hier steht der Name einer Definition auf die das notify reagiert.
Wenn da z.B. Rollo1 steht, dann reagiert notify auf Rollo1 on und off und was es sonst noch alles gibt.

Wenn man mehrere Patterns möchte, kann man diese in Klammer schreiben (Rollo1|Rollo2|Steckdose5)
als Trenner wird dann Pipe (|) genutzt.

Man kann auch mit Platzhaltern arbeiten.

* 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
* Rollo.* ==> das notify reagiert auf alles das mit Rollo beginnt.
* *isch ==> Reagiere auf alles das mit isch aufhört (Tisch, Fisch)

=== Etwas schalten, wenn ein anderes Gerät geschaltet wird ===
Wenn man das obige mit KNX abbilden möchte, benötigt man auf der KNX Seite:

==== Vorbereitung ====
* Gruppenadresse (GA) für die Steckdose vom Radio (0/0/10)
* GA vom Licht (0/0/20)

Auf der Fhem Seite wird benötigt:

* define RadioKueche EIB 0/0/10
* define LichtKueche EIB 0/0/20

==== notify Befehl ====
:<code>define LichtamRadioan notify LichtKueche { fhem "set RadioKueche %" }</code>
oder
:<code>define LichtamRadioan notify LichtKueche set RadioKueche %</code>

==== Erklärung ====
* Der Begriff "LichtamRadioan" ist nur ein Platzhalter, damit das notify in Fhem verwaltet werden kann.
* "%" ist ein Platzhalter für den Zustand vom Pattern. % enthält ein "off" wenn das LichtKueche aus ist und ein "on" wenn das Licht eingeschaltet ist.
* "{ <perlcode> }" 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.

=== Einschalten von mehreren Geräten/Lampen, wenn das Licht eingeschaltet wird ===
==== Vorbereitung ====
KNX:
* 3 GAs für drei Geräten bzw Lampen (0/0/30 0/0/31 0/0/32)

Fhem:
* define LichtWZ EIB 0/0/30
* define Steckdose1 EIB 0/0/31
* define Steckdose2 EIB 0/0/32

==== notify Befehl ====
:<code>define SteckdoseWZein notify LichtWZ { fhem "set Steckdose1 %;;set Steckdose2 %" }</code>
oder
:<code>define SteckdoseWZein notify LichtWZ set Steckdose1,Steckdose2 %</code>

==== Erklärung ====
Wenn das LichtWZ eingeschaltet wird, dann werden auch die Steckdosen (1 und 2) eingeschaltet.

=== Einfache ODER Funktion ===
Eine einfache ODER Funktion kann sehr einfach Realisiert werden

==== Vorbereitung ====
KNX:
* 3x GAs der abzufragende Werte (0/0/40 0/0/41 0/0/42)

Fhem:
define Licht1 EIB 0/0/40
define Licht2 EIB 0/0/41
define Steckdose EIB 0/0/42

==== notify Befehl ====
:<code>define SteckdoseWZein notify (Licht1|Licht2) set Steckdose %</code>
oder
:<code>define SteckdoseWZein notify (Licht.) set Steckdose %</code>

==== Erklärung ====
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 ein Zeichen (kommt glaube ich von Perl)

Danach folgt der set Befehl.
Wenn also das Licht1 oder Licht2 den Wert "on" hat, dann hat auch die Steckdose den Wert "on"

=== Einfache UND Funktion ===
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).
Dadurch ist Fhem zwar mächtig, wird aber für viele sehr kompliziert.

In diesem Beispiel soll - wenn drei Rollos geschlossen sind - am Taster eine LED eingeschaltet werden.

==== Vorbereitung ====
KNX:
* 3x GDs für die Rückgabewert Rollo geschlossen == 1 (0/0/50 0/0/51 0/0/52)
* GD LED am Lichtschalter (0/0/106)

Fhem:
<nowiki>define R1ZU EIB 0/0/50
attr R1ZU dummy 1</nowiki>
<nowiki>define R2ZU EIB 0/0/51
attr R1ZU dummy 1</nowiki>
<nowiki>define R3ZU EIB 0/0/52
attr R1ZU dummy 1</nowiki>
<nowiki>define LEDalleRolloZu EIB 0/0/106</nowiki>
Durch das Atribut dummy werden keine Schaltfunktion angeboten. Es kann nur Werte anzeigen.

==== notify Befehl ====
<nowiki>define nt.allerolloszu notify (R1ZU|R2ZU|R6ZU) {
my $r1 == $value{"R1ZU"};;
my $r2 == $value{"R2ZU"};;
my $r3 == $value{"R6ZU"};;
if ($r1 eq "on" && $r2 eq "on" && $r3 eq "on") {
fhem "set LEDalleRolloZu on"
} else {
fhem "set LEDalleRolloZu off"
}
}</nowiki>

==== Erklärung ====
Es werden die drei Rückgabewerte R1ZU, R2ZU und R3ZU ausgewertet. Danach folgt Perl Code, deswegen beginnt das ganze mit einer { und endet mit }

<nowiki>my $r1 ==> Variable $r1 definieren
== $value{"R1ZU"};; ==> weist den Rückgabewert (on oder off) von R1ZU der Variable $r1 zu</nowiki>

Der doppelte ;; ist ein Fhem Thema. Eigendlich 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.

Danach erfolgt ein normales "if then else" Konstrukt. Die Zeile »($r1 eq "on" && $r2 eq "on" && $r3 eq "on")« kann man so lesen: Wenn $r1 den Wert "on" und (&&) $r2 den Wert "on" und $r3 den Wert "on" dann schalte die LEDalleRolloZu ein {fhem("set LEDalleRolloZu on")}
ansonsten else schalte die LED aus. {fhem("set LEDalleRolloZu off")

=== Zeitverzögert schalten ===
{| class="wikitable"
| '''Aufgabe:''' || Zeitverzögert schalten
|-
| '''Beschreibung:''' || Mit einem Notify zeitverzögert eine Aktion auslösen.
|-
| '''Vorbereitung:''' || Gerät "Lampe" ist definiert und es gibt eine Situation, die ein Ereignis "Fernbedienung:.*" generiert.
|-
| '''Befehl:''' || <code>define ntfy1 notify Fernbedienung:.* sleep 7.5;; set Lampe $EVENT</code>
|-
| '''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.
:''Quelle: [http://forum.fhem.de/index.php/topic,17161.0.html Fhem Forum]''
|}

=== Eine PV-Anlage (Solarstrom) zur Steuerung der Rollos nutzen (optional Zeit und Datums abhängig) ===
Hier ein kleines Beispiel, wie ich mit Hilfe meiner PV-Anlage die Sonneneinstrahlung auf der Südseite ermittele.
Optional: Die Funktion soll allerdings nur zwischen 9:30 und 17:00 stattfinden. (zweites Beispiel)
Optional: Die Funktion soll nur zwischen dem 6 und 9 Monat funktioneren. (drittes Beispiel)

==== Vorbereitung ====
PV Anlage mit SolarView abfragen.
Per Hand ermitteln, ab wieviel erzeugtem Strom es sinnvoll ist die Rollos zu schließen.

==== notify Syntax ====
Fhem:

:<code>define sv SolarView solarview 15000 wr1 wr2 wr3 wr4</code> (ich habe vier Wechselrichter)
:<code>attr sv event-on-change-reading currentPower</code> (weis nicht ob es wirklich benötigt wird)

<nowiki>define nt.sonnenlichtpersolar notify (sv:currentPower.*) {
if (%EVTPART1 < 3000 ) {
fhem('set Flur1 Auf');
}else {
if (%EVTPART1 > 5000 ) {
fhem('set Flur1 Ab');
}
}
}</nowiki>
Optional 1: Zeitabhängig

<nowiki>(sv:currentPower.*) {
my $hm == sprintf("%%02d:%%02d", $hour, $min);
if ( $hm gt "09:30" && $hm lt "17:00") {
if (%EVTPART1 < 5000 ) {
fhem('set Flur1 Auf');
}else {
if (%EVTPART1 > 8000 ) {
fhem('set Flur1 Ab');
}
}
}
}</nowiki>
Optional 2: Zeit und Datum

<nowiki>(sv:currentPower.*) {
my $hm == sprintf("%%02d:%%02d", $hour, $min);
if( $month ge "6" && $month le "9") {
if ( $hm gt "09:30" && $hm lt "17:00") {
if (%EVTPART1 < 5000 ) {
fhem('set Flur1,RBUERO1,RBUERO2 Auf');
}else {
if (%EVTPART1 > 8000 ) {
fhem('set Flur1,Flur2,RBUERO1,RBUERO2 Ab');
}
}
}
}
}</nowiki>

==== Erklärung ====
* Das define wird in der Kommandozeile im Webbrowser eingegeben.
* Anschliessend wird im Webbrowser die DEF bearbeitet, das erspart uns Probleme mit Perl
* define sv SolarView ... <==== ist die Schnittstelle vom SolarView
* define nt.sonnenlichtpersolar notify (sv:currentPower.*) { <==== hier wird ein notify angelegt, der auf das "define sv" Wert "currentPower.*" (.* ist irgendwas) reagiert
<nowiki>if (%EVTPART1 < 3000 ) {
fhem('set Flur1 Auf');
}else {
if (%EVTPART1 > 5000 ) {
fhem('set Flur1 Ab');
}
}
}</nowiki>
Diese IF Funktion wertet den Rückgabewert von currentPower aus. Hierbei muss man wissen, dass %EVTPART1 das Splitergebnis vom Rückgabewert ist

Beispiel: Der Rückgabewert (wie im Beispiel) ist "currentPower: 6000".
Jetzt steht im "%EVTPART0 == currentPower:" und im "%EVTPART1 == 6000"
Das bedeutet wir müssen uns nicht selbst den richtigen split (Perl Befehl) Aufruf ausdenken, das übernimmt Fhem.

Ergebnis der ganzen Aktion:
Das Rollo wird abhängig von der erzeugten IST_Strommenge auf und zu gefahren.
Damit dies nicht dauernd hin und her pendelt, habe ich den Auf Wert sehr klein und den Ab Wert sehr groß gewählt.

'''Optional 1:''' Der Block "my $hm == sprintf("%%02d:%%02d", $hour, $min);" erzeugt die Variable $hm mit dem Inhalt $hour:$min. %02d (wegen Fhem besonderheit %%02d) begrenzt die Ausgabe auf zwei Stellen (hab jetzt hoffentlich nichts Falsches geschrieben).
Danach wird mit "if ( $hm gt "09:30" && $hm lt "17:00") " 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.

'''Optional 2:'''if( $month ge "6" && $month le "9") {

Hier frage ich die Default Variable $month (Monat) auf größer/gleich bzw kleiner/gleich ab.
Die Funktion arbeitet also nur zwischen dem sechsten und dem neunten Monat und dann auch nur zwischen 9:31 und 16:59.

=== Hinweise ===
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.

== Weiterführende Links ==
* [[Escapen in Perlbefehlen]]
* [[Klammerebnen|Klammerebenen]]

[[Kategorie:HOWTOS]]
[[Kategorie:Hilfsmodul]]

Creating Plots - caching SVG's

2013-10-29T13:52:16Z

Generix: /* Definition eines weblinks: */

= Creating Plots - caching SVG's =
== Das Problem: ==
Die Anzeige von Grafiken in FHEM benötigt relativ lange Zeit. Speziell, wenn es um längere Zeiträume (Monat/Jahr) geht, und viele Werte gespeichert sind, kann das schon in die 10+ Sekunden gehen.

Die Anleitung geht davon aus, dass grundsätzliches knowhow über fhem und wie Grafiken erstellt werden besteht. Grundlegende Infos sich unter: [http://www.fhemwiki.de/wiki/Creating_Plots Creating_Plots] zu finden.

== Der Lösungsansatz: ==
Alle Grafiken, die sich auf Werte in der Vergangenheit beziehen, ändern sich nicht mehr, werden aber dennoch jedesmal neu abgefragt und neu berechnet.
Für diese Art von Grafiken wird eine caching Lösung aufgezeigt.

== Voraussetzungen: ==
dieses Beispiel geht von folgendener Situation aus:

* es gibt ein DbLog (in diesem Beispiel myDbLog), dass alle readings speichert.
* es gibt einen Sensor (in diesem Beispiel '''AussenTempHum'''), der die readings '''temperature''' und '''humidity''' liefert.
* Das Beispiel geht davon aus, dass FHEM unter dem User fhem läuft.

== Definitionen: ==
=== Definition eines weblinks: ===
<nowiki>define AussenTempHum_current_day weblink dbplot myDbLog:TempHum_MH
attr AussenTempHum_current_day label "Temp- min: $data{min1}, max: $data{max1}, last: $data{currval1}, Feuchte- min: $data{min2}, max: $data{max2}, last: $data{currval2}"
attr AussenTempHum_current_day plotfunction AussenTempHum
attr AussenTempHum_current_day title "Aussen"</nowiki>
Das Attribut '''plotfunction''' bestimmt welches device in der Datenbank selektiert wird (in diesem Beispiel AussenTempHum).

Das Attribut '''title''' und '''label''' bestimmt was in der Überschriftszeile des Plots steht.

=== Definition des gplotfile (TempHum_MH.gplot): ===
<nowiki># TempHum_MH.gplot
# MH 12/2012 support both dblog and filelog
# Attribute 'small' is useful for gnuplot/-scroll only,
# if plotsize is less than 800,400
#set terminal png transparent small size <SIZE> crop
set terminal png transparent size <SIZE> crop
set output '<OUT>.png'
set xdata time
set timefmt "%Y-%m-%d_%H:%M:%S"
set xlabel " "
set ytics nomirror
set y2tics
#set ytics
set title '<TL> <L1>'
set grid xtics y2tics
set y2label "Temperature (°C)"
set ylabel "Humidity (%RF)"
set yrange [0:99]
#FileLog 4:temperature:10:
#FileLog 4:humidity:50:
#DbLog <SPEC1>:temperature:10:
#DbLog <SPEC1>:humidity:50:
plot \
ls l0 axes x1y2 title 'Measured temperature' with lines
ls l1fill axes x1y1 title 'Humidity' with lines</nowiki>
Nachdem diese beiden Definitionen erledigt sind, sollte es in FHEM eine Grafik geben, die in etwa so aussieht:

[[File:Cachesvg.png|800px]]

'''Bis hierher war alles standard fhem, das sollte also funktionieren bevor es zum schwierigen Teil kommt ;-)'''
Wir brauchen ein Verzeichnis, um die Grafiken zu speichern, wo FHEM sie nachher auch wieder finden kann und darf:
In diesem Beispiel (telnet/SSH auf Raspberry PI):

<nowiki>sudo mkdir /opt/fhem/svgcache/
sudo chown -R fhem:root /opt/fhem/svgcache/</nowiki>

[[Kategorie:HOWTOS]]

== erster Test ==
Ein erster Test (von der telnet/SSH commandline):

<nowiki>cd /opt/fhem/svgcache/
sudo -u fhem wget -O testx.svg 'http://localhost:8083/fhem?cmd=showlog AussenTempHum_current_day myDbLog TempHum_MH -&pos=zoom=month;off=0'</nowiki>
<nowiki>Die wesentlichen Parameter sind:
sudo -u fhem - damit läuft das wget unter dem user 'fhem', damit es keine Probleme mit Dateiberechtigungen gibt.
-O testx.svg - das ist der filename, unter dem die erstellte svg gespeichert wird.
[http://localhost:8083 http://localhost:8083] - muß jeweils angepasst werden....
&pos=zoom=xxx;off=yyy
xxx: year, month, week, day - die Zeitspanne
yyy: 0, -1, -2, ... - wieviel Zeitspannen zurück, 0==aktuell
Beipiel: &pos=zoom=month;off=-1 - ergibt die Grafik des vorigen Monats.</nowiki>
Und das Ergebnis bewundern (im Browser):

<nowiki>http://localhost:8083/fhem/svgcache/testx.svg</nowiki>
Es sollte jetzt die gewünschte Grafik aufgebaut werden.

=== Todo ===
Automatisieren der Grafikerstellung mittels fhem at....

== Die gespeicherten SVG's von FHEM anzeigen lassen ==
=== Definitionen: ===
<nowiki>define AussenTempHum_lastmonth weblink htmlCode <br/><object data="/fhem/svgcache/AussenTempHum_month-last.svg" type="image/svg+xml" width="800" height="160" name="weblink_test"></object> <br/> <a href="/fhem?detail=AussenTempHum_lastmonth">AussenTempHum last month</a><br/></nowiki>
Damit teilen wir fhem mit, wo die Grafik zu finden ist (object data="'''/fhem/svgcache/Au...''').
Der file-name muß natürlich mit dem aus dem vorigen wget übereinstimmen!

== Fazit ==
Damit können beliebige plots definert und gepeichert werden und von fhem relativ schnell abgerufen werden.
Grundsätzlich wäre diese Lösung auch ohne DbLog möglich, allerdings müssten dazu die Beispiele überarbeitet werden.

Have fun
Erwin.

Creating Plots - caching SVG's

2013-10-29T13:52:00Z

Generix: /* Definition eines weblinks: */

= Creating Plots - caching SVG's =
== Das Problem: ==
Die Anzeige von Grafiken in FHEM benötigt relativ lange Zeit. Speziell, wenn es um längere Zeiträume (Monat/Jahr) geht, und viele Werte gespeichert sind, kann das schon in die 10+ Sekunden gehen.

Die Anleitung geht davon aus, dass grundsätzliches knowhow über fhem und wie Grafiken erstellt werden besteht. Grundlegende Infos sich unter: [http://www.fhemwiki.de/wiki/Creating_Plots Creating_Plots] zu finden.

== Der Lösungsansatz: ==
Alle Grafiken, die sich auf Werte in der Vergangenheit beziehen, ändern sich nicht mehr, werden aber dennoch jedesmal neu abgefragt und neu berechnet.
Für diese Art von Grafiken wird eine caching Lösung aufgezeigt.

== Voraussetzungen: ==
dieses Beispiel geht von folgendener Situation aus:

* es gibt ein DbLog (in diesem Beispiel myDbLog), dass alle readings speichert.
* es gibt einen Sensor (in diesem Beispiel '''AussenTempHum'''), der die readings '''temperature''' und '''humidity''' liefert.
* Das Beispiel geht davon aus, dass FHEM unter dem User fhem läuft.

== Definitionen: ==
=== Definition eines weblinks: ===
<nowiki>define AussenTempHum_current_day weblink dbplot myDbLog:TempHum_MH
attr AussenTempHum_current_day label "Temp- min: $data{min1}, max: $data{max1}, last: $data{currval1}, Feuchte- min: $data{min2}, max: $data{max2}, last: $data{currval2}"
attr AussenTempHum_current_day plotfunction AussenTempHum
attr AussenTempHum_current_day title "Aussen"</nowiki>
Das Attribut '''plotfunction''' bestimmt welches device in der Datenbank selektiert wird (in diesem Beispiel AussenTempHum).

Das Attribut '''title''' und ''' label'''bestimmt was in der Überschriftszeile des Plots steht.

=== Definition des gplotfile (TempHum_MH.gplot): ===
<nowiki># TempHum_MH.gplot
# MH 12/2012 support both dblog and filelog
# Attribute 'small' is useful for gnuplot/-scroll only,
# if plotsize is less than 800,400
#set terminal png transparent small size <SIZE> crop
set terminal png transparent size <SIZE> crop
set output '<OUT>.png'
set xdata time
set timefmt "%Y-%m-%d_%H:%M:%S"
set xlabel " "
set ytics nomirror
set y2tics
#set ytics
set title '<TL> <L1>'
set grid xtics y2tics
set y2label "Temperature (°C)"
set ylabel "Humidity (%RF)"
set yrange [0:99]
#FileLog 4:temperature:10:
#FileLog 4:humidity:50:
#DbLog <SPEC1>:temperature:10:
#DbLog <SPEC1>:humidity:50:
plot \
ls l0 axes x1y2 title 'Measured temperature' with lines
ls l1fill axes x1y1 title 'Humidity' with lines</nowiki>
Nachdem diese beiden Definitionen erledigt sind, sollte es in FHEM eine Grafik geben, die in etwa so aussieht:

[[File:Cachesvg.png|800px]]

'''Bis hierher war alles standard fhem, das sollte also funktionieren bevor es zum schwierigen Teil kommt ;-)'''
Wir brauchen ein Verzeichnis, um die Grafiken zu speichern, wo FHEM sie nachher auch wieder finden kann und darf:
In diesem Beispiel (telnet/SSH auf Raspberry PI):

<nowiki>sudo mkdir /opt/fhem/svgcache/
sudo chown -R fhem:root /opt/fhem/svgcache/</nowiki>

[[Kategorie:HOWTOS]]

== erster Test ==
Ein erster Test (von der telnet/SSH commandline):

<nowiki>cd /opt/fhem/svgcache/
sudo -u fhem wget -O testx.svg 'http://localhost:8083/fhem?cmd=showlog AussenTempHum_current_day myDbLog TempHum_MH -&pos=zoom=month;off=0'</nowiki>
<nowiki>Die wesentlichen Parameter sind:
sudo -u fhem - damit läuft das wget unter dem user 'fhem', damit es keine Probleme mit Dateiberechtigungen gibt.
-O testx.svg - das ist der filename, unter dem die erstellte svg gespeichert wird.
[http://localhost:8083 http://localhost:8083] - muß jeweils angepasst werden....
&pos=zoom=xxx;off=yyy
xxx: year, month, week, day - die Zeitspanne
yyy: 0, -1, -2, ... - wieviel Zeitspannen zurück, 0==aktuell
Beipiel: &pos=zoom=month;off=-1 - ergibt die Grafik des vorigen Monats.</nowiki>
Und das Ergebnis bewundern (im Browser):

<nowiki>http://localhost:8083/fhem/svgcache/testx.svg</nowiki>
Es sollte jetzt die gewünschte Grafik aufgebaut werden.

=== Todo ===
Automatisieren der Grafikerstellung mittels fhem at....

== Die gespeicherten SVG's von FHEM anzeigen lassen ==
=== Definitionen: ===
<nowiki>define AussenTempHum_lastmonth weblink htmlCode <br/><object data="/fhem/svgcache/AussenTempHum_month-last.svg" type="image/svg+xml" width="800" height="160" name="weblink_test"></object> <br/> <a href="/fhem?detail=AussenTempHum_lastmonth">AussenTempHum last month</a><br/></nowiki>
Damit teilen wir fhem mit, wo die Grafik zu finden ist (object data="'''/fhem/svgcache/Au...''').
Der file-name muß natürlich mit dem aus dem vorigen wget übereinstimmen!

== Fazit ==
Damit können beliebige plots definert und gepeichert werden und von fhem relativ schnell abgerufen werden.
Grundsätzlich wäre diese Lösung auch ohne DbLog möglich, allerdings müssten dazu die Beispiele überarbeitet werden.

Have fun
Erwin.

Creating Plots - caching SVG's

2013-10-29T13:51:31Z

Generix: /* Voraussetzungen: */

= Creating Plots - caching SVG's =
== Das Problem: ==
Die Anzeige von Grafiken in FHEM benötigt relativ lange Zeit. Speziell, wenn es um längere Zeiträume (Monat/Jahr) geht, und viele Werte gespeichert sind, kann das schon in die 10+ Sekunden gehen.

Die Anleitung geht davon aus, dass grundsätzliches knowhow über fhem und wie Grafiken erstellt werden besteht. Grundlegende Infos sich unter: [http://www.fhemwiki.de/wiki/Creating_Plots Creating_Plots] zu finden.

== Der Lösungsansatz: ==
Alle Grafiken, die sich auf Werte in der Vergangenheit beziehen, ändern sich nicht mehr, werden aber dennoch jedesmal neu abgefragt und neu berechnet.
Für diese Art von Grafiken wird eine caching Lösung aufgezeigt.

== Voraussetzungen: ==
dieses Beispiel geht von folgendener Situation aus:

* es gibt ein DbLog (in diesem Beispiel myDbLog), dass alle readings speichert.
* es gibt einen Sensor (in diesem Beispiel '''AussenTempHum'''), der die readings '''temperature''' und '''humidity''' liefert.
* Das Beispiel geht davon aus, dass FHEM unter dem User fhem läuft.

== Definitionen: ==
=== Definition eines weblinks: ===
<nowiki>define AussenTempHum_current_day weblink dbplot myDbLog:TempHum_MH
attr AussenTempHum_current_day label "Temp- min: $data{min1}, max: $data{max1}, last: $data{currval1}, Feuchte- min: $data{min2}, max: $data{max2}, last: $data{currval2}"
attr AussenTempHum_current_day plotfunction AussenTempHum
attr AussenTempHum_current_day title "Aussen"</nowiki>
Das Attribut '''plotfunktion'''bestimmt welches device in der Datenbank selektiert wird (in diesem Beispiel AussenTempHum).

Das Attribut '''title'''und '''label'''bestimmt was in der Überschriftszeile des Plots steht.

=== Definition des gplotfile (TempHum_MH.gplot): ===
<nowiki># TempHum_MH.gplot
# MH 12/2012 support both dblog and filelog
# Attribute 'small' is useful for gnuplot/-scroll only,
# if plotsize is less than 800,400
#set terminal png transparent small size <SIZE> crop
set terminal png transparent size <SIZE> crop
set output '<OUT>.png'
set xdata time
set timefmt "%Y-%m-%d_%H:%M:%S"
set xlabel " "
set ytics nomirror
set y2tics
#set ytics
set title '<TL> <L1>'
set grid xtics y2tics
set y2label "Temperature (°C)"
set ylabel "Humidity (%RF)"
set yrange [0:99]
#FileLog 4:temperature:10:
#FileLog 4:humidity:50:
#DbLog <SPEC1>:temperature:10:
#DbLog <SPEC1>:humidity:50:
plot \
ls l0 axes x1y2 title 'Measured temperature' with lines
ls l1fill axes x1y1 title 'Humidity' with lines</nowiki>
Nachdem diese beiden Definitionen erledigt sind, sollte es in FHEM eine Grafik geben, die in etwa so aussieht:

[[File:Cachesvg.png|800px]]

'''Bis hierher war alles standard fhem, das sollte also funktionieren bevor es zum schwierigen Teil kommt ;-)'''
Wir brauchen ein Verzeichnis, um die Grafiken zu speichern, wo FHEM sie nachher auch wieder finden kann und darf:
In diesem Beispiel (telnet/SSH auf Raspberry PI):

<nowiki>sudo mkdir /opt/fhem/svgcache/
sudo chown -R fhem:root /opt/fhem/svgcache/</nowiki>

[[Kategorie:HOWTOS]]

== erster Test ==
Ein erster Test (von der telnet/SSH commandline):

<nowiki>cd /opt/fhem/svgcache/
sudo -u fhem wget -O testx.svg 'http://localhost:8083/fhem?cmd=showlog AussenTempHum_current_day myDbLog TempHum_MH -&pos=zoom=month;off=0'</nowiki>
<nowiki>Die wesentlichen Parameter sind:
sudo -u fhem - damit läuft das wget unter dem user 'fhem', damit es keine Probleme mit Dateiberechtigungen gibt.
-O testx.svg - das ist der filename, unter dem die erstellte svg gespeichert wird.
[http://localhost:8083 http://localhost:8083] - muß jeweils angepasst werden....
&pos=zoom=xxx;off=yyy
xxx: year, month, week, day - die Zeitspanne
yyy: 0, -1, -2, ... - wieviel Zeitspannen zurück, 0==aktuell
Beipiel: &pos=zoom=month;off=-1 - ergibt die Grafik des vorigen Monats.</nowiki>
Und das Ergebnis bewundern (im Browser):

<nowiki>http://localhost:8083/fhem/svgcache/testx.svg</nowiki>
Es sollte jetzt die gewünschte Grafik aufgebaut werden.

=== Todo ===
Automatisieren der Grafikerstellung mittels fhem at....

== Die gespeicherten SVG's von FHEM anzeigen lassen ==
=== Definitionen: ===
<nowiki>define AussenTempHum_lastmonth weblink htmlCode <br/><object data="/fhem/svgcache/AussenTempHum_month-last.svg" type="image/svg+xml" width="800" height="160" name="weblink_test"></object> <br/> <a href="/fhem?detail=AussenTempHum_lastmonth">AussenTempHum last month</a><br/></nowiki>
Damit teilen wir fhem mit, wo die Grafik zu finden ist (object data="'''/fhem/svgcache/Au...''').
Der file-name muß natürlich mit dem aus dem vorigen wget übereinstimmen!

== Fazit ==
Damit können beliebige plots definert und gepeichert werden und von fhem relativ schnell abgerufen werden.
Grundsätzlich wäre diese Lösung auch ohne DbLog möglich, allerdings müssten dazu die Beispiele überarbeitet werden.

Have fun
Erwin.

FHEM und FritzBox 7240

2013-10-26T11:09:43Z

Generix: /* Fritz!Box 7240 */

Instructions and recommendations for running '''Fhem on a FritzBox 7240'''.
== CUL ==
* flash CUL_V3.hex (from [http://www.atmel.com/ Atmel] page)
* attach CUL to Fritz!Box (with a USB Hub to have USB-Memory stick and CUL running at the same time)

'''Note''': to check if CUL works, in FritzBox settings enable ''USB-Fernanschluss''.
Now it gets recognized as CUL868. Remember to disable it again.
The CUL should be recognized as <code>Es handelt sich um ein nicht unterstütztes USB-Gerät</code>. This is OK!

== Fritz!Box 7240 ==
* Update Fritz!Box to Firmware-Version >= 73.05.05
* download [http://www.fhem.de Fhem]
* unzip and store at root of your USB-Memory stick in the folder "fhem" (this will be <code>/var/InternerSpeicher/<yourUsbStickName>/fhem/</code> on you Fritz!Box lateron.
* in this folder, adapt the file "startfhem" if you use more than one storage device (e.g. USB memory stick and 1&1 Online Speicher") with hardcoded destination folder for your fhem path:
*: <code>home=/var/InternerSpeicher/SanDisk-Cruzer-01/fhem</code>
* Alternatively, disable "1&1 Online Speicher" and use USB memory stick only. This way you don't have to adapt startfhem.
* to use telnet, it needs to be enabled via phone by dialing #96*7*. To login, use the same password as for Fritz!Box webfrontend. Now you can edit all of your files using vi in telnet.
* Now define your "fhem.cfg" to match your configuration, e.g. starting with your housecode:
*: <code> define myCUL CUL /dev/ttyACM0 1234 </code>
*: ...
* finally start fhem in telnet:
*: <code>/var/InternerSpeicher/SanDisk-Cruzer-01/fhem/startfhem</code>
* or use autostart => see [http://www.fhemwiki.de/wiki/FHEM_und_FritzBox_7170#Autostart_fhem #Autostart fhem]

== Open issues ==
Daily resets with big log files

After 1 week running perfectly I was seeing regular/daily resets. The problem in my setting is that I am using several [[FS20 STR Raumthermostat|FS20-STR]]. These devices send every 2-3 minutes off-for-timer or on-for-timers signals. These events get logged in the monthly log file. After this log was bigger then 1MB I have seen these resets. After I emptied/deleted the file the box is running stable again.


After looking into the details, it seems that the 7240 gets a memory problem when log files get bigger than ~800KB. I changed the logging from monthly files to weekly files (using <code>./log/fhem-%Y-%m-%V.log</code>). This way, files should no longer get that big. Since then, 7240 runs stable without any problems.


See also [http://groups.google.com/group/fhem-users/browse_thread/thread/8acca4c2a63e1dce GoogleGroups:FHEM auf Fritzbox - Logfile - Info wenn wenig Speicher]

[[Kategorie:FritzBox]]

Zuhause-Status

2013-10-10T10:05:21Z

Generix:

Abhängig davon, ob man sich zuhause aufhält, schläft oder ausser Haus ist, sollen Geräte unterschiedlich geschaltet werden.

Dabei sollen

# beim Statuswechsel (also "ich komme nach hause", "ich gehe schlafen" etc) Geräte geschaltet werden
# regelmäßig geplante "at *" -Vorgänge ihr Verhalten auch davon abhängig machen, ob jemand zuhause ist oder nicht.

Der Status kann z. B. per Schalter gesetzt werden.
Automatisiert geht das auch mit dem [[PRESENCE]] Modul

== Lösungsansatz ==
Es wird eine Variable HomeStatus als dummy-device, also als Variable definiert.

Desweiteren werden ein 4-Tasten-Wandschalter fs20-s4a und eine 4-Tasten-Fernbedienung fs20-s4 mit identischem Hauscode und Tastencodes versehen, die Tasten angelernt und benannt in HomeStat1, HomeStat2, HomeStat3, HomeStat4.
Der Wandschalter kommt neben die Wohnungstür, die Fernbedienung ans Bett.

Beim Drücken dieser Tasten wird HomeStatus auf 1, 2, 3 oder 4 gesetzt. Ausserdem werden die gemäß dem neuen Status benötigten bzw. nicht mehr benötigten Geräte ein- oder ausgeschaltet:

;Bei Setzen von HomeStatus 1 (ich komme zuhause an)
: Media an
: Heizung auf Tagtemperatur
: WLAN an

;Bei Setzen von HomeStatus 2 (ich gehe schlafen)
: Alle Lampen aus ausser Schlafzimmer
: Media aus
: Heizung auf Nachttemperatur
: WLAN aus

;Bei Setzen von HomeStatus 3 (verlassen der Wohnung für kurze Zeit)
: Alle Lampen aus
: Media aus
: Heizung auf Nachttemperatur
: WLAN aus

;Bei Setzen von HomeStatus 4 (ich verlasse die Wohnung für längere Zeit)
: Alles aus
: Heizung runterregeln auf 'Ferienprogramm'
: WLAN aus

Regelmäßig geschaltete Geräte berücksichtigen ebenfalls den HomeStatus, z.B. startet das Wakeuplight nur an Wochentagen und nur wenn ich zuhause bin, also der HomeStatus < 3 ist.

== Codings ==
<nowiki>define HomeStatus dummy
attr HomeStatus room Wohnung
define whg_HomeStat1 FS20 696c 00
define whg_HomeStat2 FS20 696c 01
define whg_HomeStat3 FS20 696c 02
define whg_HomeStat4 FS20 696c 03

define Zuhause notify whg_HomeStat1 set HomeStatus 1;;trigger whg_Audio on;;set whg_WLAN,wz_MacMini on;;set ez_FHT desired-temp 21.0
define Schlafen notify whg_HomeStat2 set HomeStatus 2;;trigger whg_MediaAus off;;set ez_FHT desired-temp 19.0;;set ez_LichtAlle,wz_LichtAlle,ku_LichtAlle,whg_WLAN off
define KurzWeg notify whg_HomeStat3 set HomeStatus 3;;set ez_FHT desired-temp 18.5;;trigger whg_MediaAus off;;set whg_WLAN,Wohnung_Licht off
define LangeWeg notify whg_HomeStat4 set HomeStatus 4;;trigger whg_MediaAus off;;set Wohnung_Licht,whg_WLAN,wz_MacMini off;;set ez_FHT desired-temp 17.0

define wakeup at *07:00 {\
{Log 3, ('wakeupLOG WE: '.$we)}\
{Log 3, ('wakeupLOG HomeStatus: '.(Value("HomeStatus")))}\
if ((!$we) '''and (Value("HomeStatus") < 3''') {\
{fhem("define wakeup2 at +00:18:00 set sz_Stehlampe on") }\
{fhem("define wakeupOff at +00:45:00 set sz_Leselampe,sz_Stehlampe off") }\
{fhem("set sz_Leselampe dim100% 1280") }\
{Log 4, ("wakeupLOG: define wakeupOff at +00:45:00 set sz_Leselampe,sz_Stehlampe off")}\
}\
else {\
{Log 3, ("wakeupLOG: no wakeup today.")}\
}\
}</nowiki>

== Weitere Beispiele ==
[[Wakeuplight]]
[[Licht bei Bedingungen einschalten]]
[[Kategorie:Code Snippets]]

Alarmanlage

2013-10-10T09:46:10Z

Generix:

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.

== Anforderung ==
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.

== Vorausetzung ==
Voraussetzung sind Sensoren. Vielfach sind aber Bewegungsmelder und Türkontakte vorhanden, unter Umständen muss nur wenig ergänzt werden. Im konkreten Fall konnte auf mehrere [[FS20 PIRA Infrarot-Bewegungsmelder]] installiert.

== Design / Anzeige / Schaltlogik ==
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 kann 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 Fhem/FS20 kaum realisierbar ist.

Zunächst muss die Anlage ein und auschaltbar sein, oder besser: scharf und unscharf.
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)

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.

Das Einschalten soll zwar per Fernbedienung passieren, zusätzlich aber über im Haus verdeckt angebrachte Taster.
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.

Um Fehlbedienungen zu erschweren sind Wartezeiten eingebaut: Nach der letzten Unscharfschaltung müssen 11 Sekunden vergehen, bis wieder scharf geschaltet werden kann.

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.

Um diese diversen Zustände zu steuern, werden mehre Variablen (dummys) und FS20 Aktoren eingerichtet, nämlich:

* ANLAGE_STATUS
* ALARM_STATUS
* ANLAGE_SCHARF
* ALARM_AKTOR

Zur Anzeige außerdem:

* Scharfanzeige1
* Scharfanzeige2

Im Einzelnen:

'''ANLAGE_STATUS'''

Ein reiner Dummy, der folgende Werte annehmen kann

* aus (Anlage initialisiert, ohne weitere Funktion)
* 60sec (Anlage wurde scharf geschaltet, ein Minute Wartezeit bis Aktivierung)
* scharf (Anlage ist scharf)
* scharf_intern (Anlage ist intern scharf, es werden nurAussenhautsensoren überwacht)
* warten (Anlage wurde unscharf geschaltet, kann aber die nächsten 11 Sekunden noch nicht erneut scharf geschaltet werden.
* unscharf (Anlage ist unscharf)

'''ALARM_STATUS'''

Ein reiner Dummy, der folgende Werte annehmen kann

* aus (Anlage initialisiert, ohne weitere Funktion)
* bereit (Anlage scharf, keine Alarmauslösung)
* ALARM (Anlage scharf, Alarmauslösung)
* unscharf (Anlage unscharf)
* IRausgeloest (Anlage ist scharf, Alarmauslösung durch Bewegungsmelder, letzte Bewegung vor mindestens 3 Minuten)

Es ist möglich die Satus ANLAGEN_STATUS und ALARM_STATUS in einer Variabel zusammen zu fassen, was die Sache aber unübersichtlich macht.

'''ANLAGE_SCHARF'''

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.
Ferner kann überlegt werden, auch versehentlich zu lange Tastendrücke (dimup und dimdown) abzufangen und zum Schalten zuzulassen.

'''ANLAGE_SCHARF_intern'''

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.
Ferner kann überlegt werden, auch versehentlich zu lange Tastendrücke (dimup und dimdown) abzufangen und zum Schalten zuzulassen.

'''ALARM_AKTOR'''

Ein FS20 Aktor, der dazu dient die Sirenensteuerung zu triggern.
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).
Ä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

Zur Anzeige ausserdem:

Scharfanzeige1

Scharfanzeige2

FS20 Aktoren, die mittels LED den Zustand der Anlage zeigen:

* 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.
* 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.

Mit zwei LEDs (oder ähnlichen Aktoren) können also Zustände der Anlage (ausser dem eigentlichen Alarm) angezeigt werden:

Nach einschalten:

Scharfanzeige1 Scharfanzeige2 Status der Anlage
aus aus unscharf
an aus eingeschaltet, 1 Minute Wartezeit
an an scharf

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.

Nach ausschalten:

Scharfanzeige1 Scharfanzeige2 Status der Anlage
an aus unscharf, noch warten
aus aus unscharf, einschaltbar

== Praktische Probleme ==
=== Grenzen ===
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 geeignetes Equipment, Know How und etwas 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.
Es ist aber definitiv möglich, die Anlage mit einer FHEM Installation auf einem Laptop inclusive z.B. einem CUL abzuschalten, wenn die nötige Kenntnisse vorliegen.
Mit HomeMatic Komponenten kann höhere Sicherheit erreicht werden, insbesondere wenn der AES Signing Request mit eigenem Schlüssel verwendet wird.

=== Abstraktionlayer ===
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.
Ausserdem liefern z.b. FHT Türsensoren andere Ergebnisse als FS20 und HM Türsensoren:

* FHT80TF -> Open / Closed
* HM-SEC-SC -> open / closed
* FS 20 TFK -> on / off

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.

Ausserdem:

* <nowiki> Die [[FHT80TF]] werden diese notifys nämlich alle 2 Minuten ausgelöst. </nowiki>
* 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.

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.

Durch die Alarmanlage werden nur Events der Dummies abgefragt.

Dieses Vorgehen hat folgende Vorteile:

* Vereinheitlichung der Namen
* Vereinheitlichung der Zustände.
* zusätzliche Logik in den Notifies der Dummys, z.b. Rücksetzen der Bewegungsmelder, Verzögerungen
* Anzeige aller Sensoren in einem Raum („Alarmanlage“) ohne weitere Strukture-Konstrukte und unabhängig vom eigentlichen Sensor.
* 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)
=== Funklast ===
Im Betrieb kann im Moment von Zustandsänderungen einiges an Funklast erzeugt werden. Die konkreten Installation wird mit 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.

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.

== Kommentierter Code ==
(Gegenwärtig sind Definitionen und zugehörige Funktionen zusammengefasst, eleganter ist es vermutlich, alle für die Anlage notwendigen Definitionen zusammen zu fassen)

Im Code enthalten Zeilumbrüche sind vor Übernahme in eine eigene Konfiguration zu entfernen.

=== Einschalten / auschalten ===
<nowiki>#-----Scharf/unscharf--------------------------------
define ANLAGE_STATUS dummy
attr ANLAGE_STATUS room Alarmanlage
define ANLAGE_SCHARF FS20 22224222 32
attr ANLAGE_SCHARF dummy 1
attr ANLAGE_SCHARF room Alarmanlage
define ANLAGE_SCHARF_intern FS20 22224222 30
attr ANLAGE_SCHARF_intern dummy 1
attr ANLAGE_SCHARF_intern room Alarmanlage
define Scharfanzeige1 FS20 22224222 01
attr Scharfanzeige1 IODev CUL1
define Scharfanzeige2 FS20 22224222 02
attr Scharfanzeige2 IODev CUL1</nowiki>
Über diese Dummies und Aktoren wird die Anlage gesteuert. Die Anlage wurde mit einem von der sonstigen Installation abweichendem Hauscode versehen, als Beispiel 22224222

==== Einschalten ====
<nowiki>define act_on_ANLAGE_SCHARF_on notify ANLAGE_SCHARF:on { if (Value("ANLAGE_STATUS") ne "scharf" &&
Value("ANLAGE_STATUS") ne "60sec" && Value("ANLAGE_STATUS") ne "warten" ) { fhem("set Scharfanzeige1 on ;;
set ANLAGE_STATUS 60sec ;; set ALARM_STATUS bereit ;; define verzoegert_Heizung_absenken at +00:07:00 set
Heizung_absenken on ;; define verzoegert_scharf at +00:01:00 set ANLAGE_STATUS scharf ;;;;
set Scharfanzeige2 on") }}</nowiki>
Beim Betätigen des Tasters / Fernbedienung wird die Alarmanlage eingeschaltet, wenn:

* der Taster ON gedrückt wurde
* die Anlage nicht schon scharf ist (Vermeidung unnötiger Funklast)
* die Anlage nicht innerhalb der letzten Minute scharf geschaltet wurde
* die Anlage nicht innerhalb der letzten 11 Sekunden ausgeschaltet wurde.

Das Scharfschalten löst folgende Aktionen aus:

* die Scharfanzeige 1 wird aktiviert
* Der Status der Anlage wird auf „60sec“ gesetzt, um anzudeuten, das sie noch nicht scharf ist, aber in einer Minute
* der Alarmstatus wird auf „bereit“ gesetzt
* 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.
* mittels at +00:01:00 wird die Anlage in eine Minute nach Scharfschaltung tatsächlich scharf geschaltet, gleichzeitig wird Scharfanzeige2 eingeschaltet, die eine auch im Außenbereich sichtbare Anzeige einschaltet.
==== Einschalten intern ====
<nowiki>define act_on_ANLAGE_SCHARF_intern_on notify ANLAGE_SCHARF_intern:on { if (Value("ANLAGE_STATUS") ne "scharf_intern" &&
Value("ANLAGE_STATUS") ne "60sec" && Value("ANLAGE_STATUS") ne "warten" ) { fhem("set Scharfanzeige1 on ;;
set ANLAGE_STATUS 60sec ;; set ALARM_STATUS bereit ;; define verzoegert_scharf at +00:01:00 set ANLAGE_STATUS scharf_intern ;;;; set Scharfanzeige2 on") }}</nowiki>
Das Verhalten ist analog zur normalen Scharfschaltung. Jedoch wird die Heizung nicht abgesenkt.
Die Alarmanlage kann auch ohne vorheriges Auschalten von einer Scharfschaltung in die andere überführt werden.
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.

==== Ausschalten ====
<nowiki>define act_on_ANLAGE_SCHARF_off notify ANLAGE_SCHARF.*:off { if (Value("ANLAGE_STATUS") eq "scharf_intern" || Value("ANLAGE_STATUS") eq "scharf")
{ fhem("set ALARM_Melder off ;;
set Scharfanzeige2 off ;; delete verzoegert_scharf ;; set ANLAGE_STATUS warten ;;
set ALARM_STATUS unscharf  ;; define Alarmanlage_aufraeumen
at +00:00:11 set ANLAGE_STATUS unscharf ;;;; set Scharfanzeige1 off ;;
delete verzoegert_Heizung_absenken ;; set brenner on ;; set ANLAGE_SCHARF_intern,ANLAGE_SCHARF off") }
else { fhem("set ALARM_Melder off ;;
set Scharfanzeige2 off ;; delete verzoegert_scharf ;; set ANLAGE_STATUS warten ;;
set ALARM_STATUS unscharf  ;; define Alarmanlage_aufraeumen
at +00:00:11 set ANLAGE_STATUS unscharf ;;;; set Scharfanzeige1 off ;;
delete verzoegert_Heizung_absenken") }}</nowiki>
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
ANLAGE_SCHARF
als auch
ANLAGE_SCHARF_intern.
Beide Schalter schalten die Anlage bei OFF also aus, egal auf welche Art sie scharf geschaltet wurde.

Das Unscharfschalten löst - sofern die Alarmanlage vorher scharf war - folgende Aktionen aus:

* Der ALARM_Melder (wird weiter unten definiert) wird abgeschaltet. (konkret schaltet dies die eventuell laufende Aussensirene aus)
* die Scharfanzeige 2 wird deaktiviert, damit ist auch von aussen sichtbar, dass die Unscharfschaltung erfolgreich war.
* „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.
* 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.
* Der ALARM Status wird auf unscharf gesetzt (damit geht auch eine eventuell interne Sirene aus)
* Die Scharfanzeige1 wird deaktiviert
* 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.
* 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
<nowiki>define act_on_ANLAGE_SCHARF_off notify ANLAGE_SCHARF.*:off</nowiki>
<dl><dd>sich selbst auslösen. Um dies zu verhindern wird vorher geprüft, ob die Anlage überhaupt scharf war:
</dd></dl>
<nowiki>define act_on_ANLAGE_SCHARF_off notify ANLAGE_SCHARF.*:off { if ("$value{ANLAGE_STATUS}" eq "scharf_intern" || "$value{ANLAGE_STATUS}" eq "scharf")</nowiki>
<dl><dd>Hier liesse sich eventuell auch mit "setstate" anstatt "set" arbeiten, da setstate nur den Status auf dem Webfrontend ändern würde.
</dd></dl>
Ist die Anlage bei Betätigen eines Ausschalters nicht scharf, werden sicherheitshalber mit

<nowiki>else { fhem(" ... ")</nowiki>
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, das aus irgendwelchen Gründen die Sirenen an sind, obwohl die Anlage eigentlich aus ist.)

==== Scharfanzeige aktualisieren ====
<nowiki>define Scharfanzeige_update at +*00:10:00 { if (Value("ANLAGE_STATUS") eq "scharf"
&& Value("ANLAGE_SCHARF") eq "on" ) { fhem ("set Scharfanzeige2 on ") }}</nowiki>
<nowiki>define Scharfanzeige_intern_update at +*00:30:00 { if (Value("ANLAGE_STATUS") eq "scharf_intern"
&& Value("ANLAGE_SCHARF_intern") eq "on" ) { fhem ("set Scharfanzeige2 on ") }}</nowiki>

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

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.

Beide Codeabschnitte könnten durch Verwendung von "oder" Bedingungen zusammengefasst werden was aber eventuell etwas unübersichtlich ist.

=== Abstraktionsschicht für Türkontakte (Fensterkontakte) ===
<nowiki>#------Tuerkontakte----Namen-und-Zustände vereinheitlichen-------
define AussentuerEG_Eingang dummy
attr AussentuerEG_Eingang room Alarmanlage
attr AussentuerEG_Eingang loglevel 6

define act_on_Eingang_TFK notify Eingang_TFK { if (Value("Eingang_TFK") eq "off")
{ fhem("define Eingangstuer_verzoegert_zu at +00:00:04 set AussentuerEG_Eingang zu ;; set AussentuerEG_Eingang zu") }
else { fhem("define Eingangstuer_verzoegert_offen at +00:00:04 set AussentuerEG_Eingang offen") }}
define AussentuerEG_Terrasse dummy
attr AussentuerEG_Terrasse room Alarmanlage
attr AussentuerEG_Terrasse loglevel 6
define act_on_Tuer_Wohn_u1 notify Tuer_Wohn_u { if (Value("Tuer_Wohn_u") eq "Closed")
{ fhem("set AussentuerEG_Terrasse zu") } else { fhem("set AussentuerEG_Terrasse offen") }}
define AussentuerUG_Keller dummy
attr AussentuerUG_Keller room Alarmanlage
attr AussentuerUG_Keller loglevel 6
define act_on_Tuer_Keller_Aussen1 notify Tuer_Keller_Aussen { if (Value("Tuer_Keller_Aussen") eq "Closed")
{ fhem("set AussentuerUG_Keller zu") } else { fhem("set AussentuerUG_Keller offen") }}
define AussentuerUG_Heizungskeller dummy
attr AussentuerUG_Heizungskeller room Alarmanlage
attr AussentuerUG_Heizungskeller loglevel 6
define act_on_Tuer_Heizungskeller1 notify Tuer_Heizungskeller { if (Value("Tuer_Heizungskeller") eq "closed")
{ fhem("set AussentuerUG_Heizungskeller zu") } else { fhem("set AussentuerUG_Heizungskeller offen") }}</nowiki>
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.

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.

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.

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.

Anstelle dessen wird hier der Abstraktionslayer über dem eigentlichen Sensor verwendet um zusätzliche Funktionalität einzubauen:

<nowiki>define act_on_Eingang_TFK notify Eingang_TFK { if (Value("Eingang_TFK") eq "off")
{ fhem("define Eingangstuer_verzoegert_zu at +00:00:04 set AussentuerEG_Eingang zu ;; set AussentuerEG_Eingang zu") }
else { fhem("define Eingangstuer_verzoegert_offen at +00:00:04 set AussentuerEG_Eingang offen") }}</nowiki>
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.

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.

=== Abstraktionsschicht für Bewegungsmelder ===
<nowiki>#------Bewegungsmelder----Namen-und-Zustände vereinheitlichen-------
define Bewegung_Wohnen_oben dummy
attr Bewegung_Wohnen_oben room Alarmanlage
define act_on_PIRI_WZ_o1 notify PIRI_WZ_o:on.* { fhem("set Bewegung_Wohnen_oben bewegung ;;
define reset_Bewegung_Wohnen_oben at +00:03:00 set Bewegung_Wohnen_oben keine ") }

define Bewegung_Bad_EG dummy
attr Bewegung_Bad_EG room Alarmanlage

define act_on_zk_pumpe1 notify zk_pumpe:on.* { fhem("set Bewegung_Bad_EG bewegung ;;
define reset_Bewegung_Bad_EG at +00:03:00 set Bewegung_Bad_EG keine ") }
define act_on_Licht1_Bad notify Licht1_Bad:on.* { fhem("set Bewegung_Bad_EG bewegung ;;
define reset_Bewegung_Bad_EG at +00:03:00 set Bewegung_Bad_EG keine ") }</nowiki>
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
Alle Zustände werden auf „bewegung“ bzw „keine“ gemappt.
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.

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

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.

=== Meldegruppen ===
<nowiki>#------Meldegruppenueberwachung----------------------
define MeldegruppeUG FS20 22224222 11
attr MeldegruppeUG IODev CUL2
define MeldegruppeEG FS20 22224222 21
attr MeldegruppeEG IODev CUL2
define Meldegruppe3 FS20 22224222 31
attr Meldegruppe3 IODev CUL2</nowiki>

Hier werden verschiedene Meldegruppen definiert. Es werden diverse Melder so zusammengefasst, dass eine grobe Anzeige des Auslöseortes möglich ist.
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.
(im folgenden Codebeispiel finden sich auch Melder, die in den Beispielen weiter oben der Übersichtlichkeit halber weggelassen wurden)

<nowiki>define check_MeldegruppeUG_klar notify AussentuerUG.* { if (Value("MeldegruppeUG") eq "off" &&
Value("AussentuerUG_Keller") eq "zu" && Value("AussentuerUG_Waschkeller") eq "zu" &&
Value("AussentuerUG_Heizungskeller") eq "zu") { fhem ("set MeldegruppeUG on") }}
define check_MeldegruppeUG_unklar notify AussentuerUG.*:offen { if (Value("MeldegruppeUG") eq "on")
{ fhem("set MeldegruppeUG off") }}

define check_MeldegruppeEG_klar notify AussentuerEG.* { if (Value("MeldegruppeEG") eq "off" &&
Value("AussentuerEG_Schlafen") eq "zu" && Value("AussentuerEG_Terrasse") eq "zu" &&
Value("AussentuerEG_Eingang") eq "zu") { fhem ("set MeldegruppeEG on") }}
define check_MeldegruppeEG_unklar notify AussentuerEG.*:offen { if (Value("MeldegruppeEG") eq "on")
{ fhem("set MeldegruppeEG off") }}

define check_Meldegruppe3 notify Bewegung.* { if (Value("Bewegung_Wohnen_oben") eq "keine" &&
Value("Bewegung_Bad_EG") eq "keine" && Value("Bewegung_Wohnen_unten") eq "keine")
{ fhem ("set Meldegruppe3 on") } else { fhem ("set Meldegruppe3 off") }}</nowiki>
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.

"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.
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.

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.

Die Bewegungsmelder senden nur bei einem tatsächlichen Event. Hier muss daher nicht überprüft werden, welchen Zustand die Meldegruppe vorher hatte. Jede Statusmeldung ist eine tatsächliche Änderung.

Da die Meldegruppen den Zustand häufig ändern, kann überlegt werden, mit attr .... loglevel 6 die Anzahl der Logeinträge zu reduzieren.

=== Alarmauslösung und Behandlung ===
<nowiki>#------Alarmauslösung-------------------------------
define ALARM_STATUS dummy
attr ALARM_STATUS room Alarmanlage
define ALARM_Melder FS20 22224222 33</nowiki>
Hier wird der Dummy für den eigentlichen Alarm definiert sowie ein Aktor für den Alarmmelder, also typischerweise einen Aussensirene.
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.

==== Alarmauslösung durch Türöffnung ====
<nowiki>define act_on_Aussentuer notify Aussentuer.*:offen
{ if (Value("ANLAGE_STATUS") eq "scharf" || Value("ANLAGE_STATUS") eq "scharf_intern")
{ fhem("set ALARM_STATUS ALARM ;; set Licht_an on ;; set ALARM_Melder on") } }</nowiki>
Dieser Teil des Codes löst den Alarm aus, wenn eine Tür geöffnet wird.
(Für Fenster gibt einen analogen Codeabschnitt)
Hierbei verhalten sich die FHT80TF und "normale" FS20 Tür/Fensterkontakte unterschiedlich:
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.

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.

Jedes „Tür offen“ Event löst die Prüfung aus, ob die Anlage scharf oder scharf_intern ist.
(Dies geschieht durch den Perl-Ausdruck für "oder" " || ")

Wenn die Anlage in einem der beiden Scharzfustände ist, wird

* 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
* ALARM_Melder auf „on“ gesetzt. Dies erlaubt abgestuft zu reagieren, z.b. den Hauptalarm verzögert auszulösen und mit Zeitbegrenzung zu versehen.
* ausserdem wird mit dem in der normalen Automation definierten Dummy „Licht_an“ jedes im Haus schaltbare Licht eingeschaltet.

Natürlich liessen sich auch weitere Aktionen auslösen.

==== Alarmauslösung durch Bewegung ====
<nowiki>define act_on_Bewegung notify Bewegung.*:bewegung { if (Value("ANLAGE_STATUS") eq "scharf" &&
Value("ALARM_STATUS") ne "ALARM") { fhem("set ALARM_STATUS ALARM ;; set Licht_an on ;;
set ALARM_Melder on ;; define ALARMIERT at +00:03:00 set ALARM_STATUS IRausgeloest") }}</nowiki>
Dieser Teil des Codes löst den Alarm aus, wenn eine Bewegung registriert wird.
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.

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.

Dieser Teil reagiert ausserdem nicht, wenn die Anlage nur intern scharf ist.

Ist die Anlage scharf und wurde bisher kein Alarm ausgelöst, dann erzeugt eine Bewegung:

* ALARM_STATUS wird auf ALARM gesetzt
* ALARM_Melder wird auf „on“ gesetzt. Dies erlaubt abgestuft zu reagieren, z.b. den Hautpalarm verzögert auszulösen und mit Zeitbegrenzung zu versehen.
* ausserdem wird mit dem in der normalen Automation definiertem Dummy „Licht_an“ jedes im Haus schaltbare Licht eingeschaltet.

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.
Der Codeabschnitt:

<nowiki>define ALARMIERT at +00:03:00 set ALARM_STATUS IRausgeloest</nowiki>
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.

=== Sirene ===
<nowiki>#------Sirene---------------------------------------
define act_on_ALARM_Melder notify ALARM_Melder:on
{ if (Value("ANLAGE_STATUS") eq "scharf") { fhem("define EXT_SIRENE_AN
at +00:00:15 set HM_SIRENE on-for-timer 176") }}</nowiki>
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.

== Praxis ==
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.

== Weitere Schritte ==
* Bei externer Scharfschaltung löst das Betätigen von Schaltern (jemand macht das Licht an) Alarm aus
* nach einem längeren Zeitraum ohne erkennbare Aktivität im Innenraum (keiner da, vergessen scharf zu schalten) schaltet sich die Anlage selber scharf.
* Alarmierung bei Auslösung von Feuermeldern
* diverse etwas unsaubere Stellen bereinigen (Defintion aller Dummies und Aktoren zusammenfassen, Code vereinheitlichen, Funklast weiter reduzieren, etc.)
* 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.

[[Kategorie:Code Snippets]]

MAX

2013-09-26T19:59:03Z

Generix: /* IST-Temperaturwerte */

MAX! Heizungssteuerung
== Features ==
* Bidirektionale Kommuniktion (jeder Befehl wird mit ACK quittiert)
* Heizkörperthermostate übertragen auch die gemessene Temperatur
== FHEM Module ==
Die MAX Komponenten können über den MAX!Cube per Modul 00_MAXLAN,
oder über einen [[CUL]] oder [[CUNO]] per 14_CUL_MAX gesteuert werden.
In beiden Fällen werden die einzelnen MAX! Geräte vom Modul 10_MAX
bereitgestellt.

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

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

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

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

und das Auslesen

* der gemessenen Temperatur. (Hinweis: Wird bei Verwendung des MAX CUBE nicht regelmäßig aktualisiert)
=== Fensterkontakte ===
Der aktuelle Status (offen/geschlossen) wird (praktisch ohne Verzögerung) angezeigt.
Falls wir nicht mit Ack antworten, wird er mehrmals wiederholt.

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

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

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

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

und das Auslesen

* der gemessenen Temperatur.
=== Eco-Taster ===
'''Achtung''': Zumindest über MAXLAN lässt sich der Zustand weder auslesen, noch wird
man über Veränderungen informiert.<br /><br />
Per CUL_MAX funktioniert der Eco-Taster problemlos.

==== Beispielhafte Definition ====
define BUTTON.EG MAX PushButton 069d33

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

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

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

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

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

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

=== MAXLAN ===
Minimale Konfiguration:

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

=== CUL_MAX ===
Minimale Konfiguration:

<nowiki>define CUL0 CUL /dev/ttyACM0@9600 0000
attr CUL0 rfmode MAX
define cm CUL_MAX 123456</nowiki>
=== Anlernen ===
Dazu muss der "pairmode" auf MAXLAN/CUL_MAX per

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

=== Geräte untereinander anlernen ===
Es gibt einen anderen Befehl, um Devices untereinander anzulernen (in neueren Versionen des MAX Moduls enthalten, heißt "associate").

Wenn ich z.B.
set MAXFensterKontakt0 associate MaxHeizkörperthermostat3
ausführe, dann
sendet der MAXFensterKontakt0 jede Änderung zusätzlich (direkt über Funk, ohne Cube oder FHEM)
an das MaxHeizkörperthermostat3.

Damit MaxHeizkörperthermostat3 auch auf die Nachrichten vom MAXFensterKontakt0 hört, muss noch ein
set MaxHeizkörperthermostat3 associate MAXFensterKontakt0
erfolgen.

Dann wechselt MaxHeizkörperthermostat3 immer dann auf die windowOpenTemperature, wenn der MAXFensterKontakt0 offen ist.
Dabei muss die groupId von beiden Geräte gar nicht gleich sein! (Die Semantik der groupId erschließt sich mir deshalb noch nicht ganz.
Ich glaube, man kann damit Befehle (ala set desiredTemperature) an mehrere Thermostate gleichzeitig richten. Im Moment sendet FHEM einfach an jedes Thermostat einen Befehl.)

Wahrscheinlich funktioniert associate genauso zwischen Heizkörper/Wandthermostaten. Das müsste mal eine ausprobieren und dann hier berichten.

=== Temperatursturzerkennung ===
Die Heizkörperthermostate verfügen über eine interne "Fenster-offen Erkennung" (Temperatursturzerkennung). Wird diese ausgelöst regeln sie für die Zeit die unter "windowOpenDuration" festgelegt wurde auf die als "windowOpenTemperature" festgelegt Temperatur herunter und danch wieder auf die zuvor eingestellte Temperatur zurück.
Nachteil: Die Erkennung benötigt etwas Zeit und reagiert nicht sofort wie es beim Fensterkontakt oben der Fall ist
Vorteil: Es ist kein Fensterkontakt erforderlich

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

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

<nowiki>define CUL0 CUL /dev/ttyACM0@9600 0000
define cm CUL_MAX 123456
define Heizung MAX HeatingThermostat abcdef
attr Heizung IODev cm</nowiki>
Wir müssen einmalig den internen Fake-Fensterkontakt mit dem Heizkörper assozieren

<nowiki>set Heizung associate fakeShutterContact</nowiki>
damit dieser die Nachrichten vom Fensterkontakt akzeptiert.

Nun können wir per

<nowiki>set cm fakeSC Heizung 1</nowiki>
die Nachricht "Fenster offen" an die Heizung senden und per

<nowiki>set cm fakeSC Heizung 0</nowiki>
die Nachricht "Fenster zu".

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

<nowiki>define CUL0 CUL /dev/ttyACM0@9600 0000
define cm CUL_MAX 123456
define Heizung MAX HeatingThermostat abcdef
attr Heizung IODev cm</nowiki>
Wir müssen einmalig das interne Fake-Wandthermostat mit dem Heizkörper assozieren:

<nowiki>set Heizung associate fakeWallThermostat</nowiki>
damit dieser die Nachrichten vom Wandthermostat akzeptiert. Achtung: Dies schaltet im
Heizkörperthermostat die Regelung mit dem internen Temperaturfühler aus. Ohne die gleich kommenden "fakeWT" Nachrichten wird das Heizkörperthermostat nicht mehr regeln.

Nun können wir per

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

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

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

<nowiki>define SendExtTemp notify WS300:temperature.* {
MaxFakeWallThermostat("Heizung", %EVTPART1);
}</nowiki>
Dazu die Funktion, bitte in 99_MyUtils.pm eintragen:

<nowiki>sub MaxFakeWallThermostat($$)
{
my ($heizung, $aktTemp) = @_;
my $CULMAX = $defs{$heizung}{LASTInputDev};
my $desiredTemp = ReadingsVal($heizung, "desiredTemperature", undef);
my $windowOpenTemp = ReadingsVal($heizung, "windowOpenTemperature", undef);
my $lastTemp = ReadingsVal($heizung, "LastExtTemperature", 0);
my $lastSet = ReadingsTimestamp($heizung, "LastExtTemperature", 0);
if($desiredTemp && $windowOpenTemp &&
$desiredTemp != $windowOpenTemp &&
(time()-time_str2num($lastSet) >= 600 || abs($aktTemp-$lastTemp)>=0.2 )) {
Log 3, "set $CULMAX fakeWT $heizung $desiredTemp $aktTemp";
readingsSingleUpdate($defs{$heizung}, "LastExtTemperature", $aktTemp, 0);
fhem("set $CULMAX fakeWT $heizung $desiredTemp $aktTemp");
}
}</nowiki>
In diesem Beispiel heißt das zu steuernde Thermostat "Heizung". Die vom externen Sensor gemessene Temperatur wird nur unter den folgenden Voraussetzungen gesendet:
- Das Thermostat befindet sich nicht im "Fenster-offen" Modus, und
- das letzte Senden liegt mindestens 10min zurück
- oder die gemessene Temperatur weicht um mindestens 0.2°C von der letzten gesendeten Temperatur ab

=== Wochenheizplan für Wandthermostat erstellen ===
Ein Heizplan, den der Wandthermostat versteht und speichern kann, sieht folgendermaßen aus:

<nowiki>set WZ_Wandthermostat weekProfile
Mon 17,17:30,20,23:00,17
Tue 17,17:30,20,23:00,17
Wed 17,17:30,20,23:00,17
Thu 17,17:30,20,23:00,17
Fri 17,15:00,20,23:00,17
Sat 17,11:00,20,23:00,17
Sun 17,11:00,20,23:00,17</nowiki>
Genauer erläutert wird die Funktionsweise auch unter [http://fhem.de/commandref.html#MAX http://fhem.de/commandref.html#MAX].
Der gesamte Block kann kopiert und als FHEM Befehl abgesetzt werden. Unter Umständen benötigt das Speichern, bzw Übertragen wegen der Größe etwas Zeit, bevor die aktuellen, neu gesetzten Werte wieder ausgelesen werden können.

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

Inhalt der LOG-Datei eines Heizkörperthermostates:

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

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

<nowiki>set terminal png transparent size <SIZE> crop
set output '<OUT>.png'
set xdata time
set timefmt "%Y-%m-%d_%H:%M:%S"
set xlabel " "
set y2tics
set title '<L1>'
set grid xtics y2tics
set y2label "Temperatur in Grad Celsius"
set ylabel "Signal in %"
#FileLog 4:desiredTemperature:0:
#FileLog 4:temperature:0:
#FileLog 4:valveposition:0:
plot \
"< egrep 'desiredTemperature' <IN>"\
using 1:4 axes x1y2 title 'Soll-Temperatur (C)' with lines lw 2 \
"< egrep 'temperature' <IN>"\
using 1:4 axes x1y2 title 'Ist-Temperatur(ungenau)(C)' with lines lw 2 \
"< egrep 'valveposition' <IN>"\
using 1:4 axes x1y1 title 'Ventil (%)' with lines lw 2</nowiki>
Einbinden eines Plots in der fhem.cgf

<nowiki>#Werte plotten
define MAX_017840_weblink weblink fileplot FileLog_MAX_017840:max_temp:CURRENT
attr MAX_017840_weblink label "Kueche Soll-Temperatur Min $data{min1}, Max $data{max1}, Last $data{currval1}"
attr MAX_017840_weblink room MAX</nowiki>
=== Nützliche kleine Erweiterungen ===
'''Einen Alias-Namen vergeben für eine bessere Lesbarkeit im Webinterface'''
<nowiki>attr MAX_018d3f alias Kueche</nowiki>
'''Die Anzeigen für die einzelnen File-Logs füllen das Webinterface schnell und machen es unübersichtlich.''' Die File-Logs können einfach in einen separaten Raum verbannt werden.
<nowiki>attr FileLog_MAX_018d3f room LOG</nowiki>
'''Einstellmöglichkeit für die Soll-Temperatur direkt in der „Raum-Seite“ schaffen.''' Die Temperatur wird dauerhaft auf einen bestimmten Wert gestellt. Das Wochenprogramm in dem Thermostat wird deaktiviert.

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

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

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

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

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

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

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

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

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

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

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

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

<nowiki>2013.03.20 15:21:43 5: Got matching ack</nowiki>
auftauchen.

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

CUL

2013-05-17T19:15:06Z

Generix: /* Hinweise zum Betrieb mit FHEM */

'''CUL'''
= Beschreibung =
CUL ('''C'''C1101 '''U'''SB '''L'''ite) ist ein RF-Device im Formfaktor eines USB-Dongles mit externer Antenne. Die über das ISM/SRD Band empfangenen Daten werden durch einen Onboard 8bit Atmel Prozessor vorverarbeitet. Mit verfügbarer Opensource Firmware (im Umfeld von FHEM die "culfw") kann das CUL verschiedene 868MHz Protokolle empfangen und senden, insbesondere die FS20/FHT/S300/EM/HMS sowie durch kurzfristiges Umschaltung auf 433 MHz Intertechno (z.b. viele Baumarkt Funksteckdosen) Protokolle.

Im Umfeld von FS20/FHT/EM/S300/HMS ("[[SlowRF]] - Mode") wird die Dekodierung der per AM in 1KHz übertragenen Signale per culfw auf dem Atmel Prozessor direkt erledigt und dann per USB an den Hostrechner weitergegeben.

Das CUL kann mittels des CULModuls von FHEM angesprochen und somit wie eine FHZ1X00PC verwendet werden.

Das CUL kann auch im HM-Mode als HomeMatic Zentrale alternativ zur CCU oder dem [[HMLAN Konfigurator]]). Bei CULs älter als Version 3 ist außerdem der Speicher zu klein, um die Software für FS20/FHT/S300/EM/HMS und HomeMatic zugleich im Speicher zu halten, hier muss man sich beim Flashen der Firmware für eine Protokollfamilie entscheiden. Mit zwei CULs ist aber auch der Mischbetrieb an einem FHEM Hostrechner möglich.

Ferner ist der Einsatz eines CUL als [[RFR CUL]] für den SlowRF Mode (jedoch nicht für den HM Mode) möglich, um die Reichweite zu erhöhen. Die Verbindung erfolgt hierbei über Funk, sodass keine USB Verbindung zum FHEM Hostrechner erforderlich ist.

Seit Ende 2012 gibt es ausserdem ein Modul zur Ansteuerung der [[MAX]]! Heizungsteuerung. Auch hier ist ein Mischbetrieb (MAX! und z.B. FS20 gleichzeitig über ein CUL) wohl [http://forum.fhem.de/index.php?t=msg&th=10510&start=0&rid=417 nicht angeraten].

Obwohl die eigentliche Betriebsfrequenz der FHT und FS20-Komponenten 868,35 MHz ist, ist bei den aktuellen CUL Firmwareversionen zum Betrieb mit FHEM die Frequenz auf 868,30 MHz eingestellt. Dies stellt einen Kompromiss zum besseren Empfang von EM1000EM (Energiemonitor) Geräten dar.

Falls keine RP-SMA-Antenne verfügbar ist, kann (nur für erste Tests) auch die abschraubbare Antenne für 802.11b/g WLAN-Geräte (2,4 GHz) benutzt werden, so diese anschlusstechnisch auf den RP-SMA-Stecker des CUL passt (dies funktioniert zumindest mit FS20- und EM-Geräten). Besser ist auf jeden Fall eine speziell auf den Einsatzzweck (Frequenz) abgestimmte Antenne.

Frequenz und Bandbreite können aber im SlowRF Mode frei angepasst und somit für örtlichen Empfangsgegebenheiten optimiert werden.

= Hinweise zum Betrieb mit FHEM =
'''Anmerkung:'''Nachfolgende Beispiele sind so wie dargestellt in die FHEM-Eingabezeile oder per Telnet auf FHEM zu übertragen und per <Enter> abzuschicken (nicht "save" klicken). "myCUL" ist nur ein Platzhalter und mit dem Namen '''Ihres''' CUL zu ersetzen:

* Ist Empfang eingeschaltet ?
*: <code> get myCUL raw C35</code> (13 = ja, z.b.: C35 = 0D / 13)
* Auslesen der CULFW Version:
*: <code>get myCUL raw V</code>
* LED soll nur bei Senden / Empfangen blinken
*: <code>set myCUL raw l00</code>
* LED soll regelmäßig (1Hz) und beim Senden / Empfangen blinken
*: <code>set myCUL raw l02</code>
* Reboot / Reset des CUL:
*: <code>get myCUL raw B00. Andere Werte als 00 starten das CUL im Bootloader-Modus (=> neue Firmware)</code>
* Freie CUL Sendezeit ([[1% Regel]]):
*: <code>get myCUL raw X</code> 2. Wert ist Sendezeit in 10ms slots, ein FS20 Befehl braucht ca. 210ms, eine FHT Kommunikation wesentlich mehr.
* Freie Kapazität des FHT Buffers
*: <code> get myCUL raw T03</code> Ergebniss bytes in HEX. Leer = 4a
* Inhalt des FHT Buffers
*: <code> get myCUL raw T02</code> (CUL V2 Buffer ist 74 Bytes gross, Platz für 14 bis 31 FHT Messages)
* Eingestellte Frequenz, Bandbreite etc. Ausgeben
*: <code> get myCUL ccconf</code>. Rückgabe z.B.:
<nowiki>myCUL ccconf => freq:868.300MHz bWidth:325KHz rAmpl:42dB sens:4dB</nowiki>
* Einstellen der Sendestärke:
*: <code>set myCUL raw x09</code> Einstellen der Sendeleistung.

Gültige Werte sind 00-09. Verwendet werden sollten nur die Werte 05-09, diese entsprechen
-10/-5/0/5/10 Sendeleistung in db. Default ist x08 = + 5db. Bitte im Interesse von Nachbarn und der Abhörsicherheit kleinsten problemlos funktionierenden Wert einstellen. Dies ist meistens x07 oder x08. Da speziell die Kommunikation mit den FHTs bidirektional ist, kann die Kommunikation durch höhere Werte oft nicht verbessert werden, da die FHTs selber dadurch nicht stärker senden. Besser versuchen, Lage und Antennenausrichtung des CUL zu verändern. Siehe auch Diskussion unter [https://groups.google.com/group/cul-fans/browse_thread/thread/683ca5c892eae1c3/c682a640f1ba863c?lnk=gst&q=bWidth+freq#c682a640f1ba863c GoogleGroups-CUL-Fans]

Werte x00-x04 sind MIT Ramping und führen zum Verlust der Kommunikationsfähigkeit mit anderen CULs, z.b. [[RFR CUL]].

'''Hinweis:'''Beim CUL im HM-Modus kann man (ohne firmware-mod) die Empfangs-/Sendeparameter '''nicht'''verstellen. Die üblichen freq/x09 etc. haben hier keine Wirkung ([http://forum.fhem.de/index.php?t=msg&th=10203&goto=57191&rid=417#msg_57191 Quelle]).

Weiterhin kann man zunehmend mehr Debuggingoutput auf dem CUL einschalten mit :

* *: <code> set CUL1 raw X61</code> Communication wird im Detail angezeigt
* *: <code>set CUL1 raw X25</code> auch checksum Fehler / unerkannte Protokolle werden gemeldet
* *: <code>set CUL1 raw X2F</code> alle empfangenen Flanken werden gemeldet
* *: <code>set CUL1 raw X80</code> RSSI / Signalstaerke jeder Flanke wird gemeldet
* *: <code>set CUL1 raw X21</code>normal Modus

Achtung: Auf Gross- und Kleinschreibung des "x,X" achten!

Die kompletten Kommandos mit Erklärung für CUL stehen hier: [http://culfw.de/commandref.html http://culfw.de/commandref.html]

= Versionen =
Das CUL gibt es in mehreren Versionen, die sich überwiegend in Prozessor und Speicherkonfiguration unterscheiden.

* CUL V1 - AT90USB162 Prozessor, 0,5Kb RAM, 16Kb Flashmemory, 0,5 kByte EEPROM. Einsatzfähigkeit unbekannt (aber vermutlich wie V2). Wird nicht mehr hergestellt.
* CUL V2 - AT90USB162 Prozessor, 0,5Kb RAM, 16Kb Flashmemory, 0,5 kByte EEPROM. Einsatzfähig. Der Flashspeicher ist jedoch zu klein für eine culfw (CUL Firmware), die Code für SlowRF Geräte und zugleich HM Geräte enthält. Es muss also vor dem Flashen der Firmware zwischen zwei jeweils reduzierten Versionen gewählt werden. Da ein CUL ohnehin nicht beide Sendemodi '''zeitgleich''' betreiben kann, ist dies keine wirkliche Einschränkung. Wird nicht mehr hergestellt.
* CUL V3 - ATMega32U4 Prozessor, 2,5 Kb RAM, 32 Kb Flashmemory, 1 kByte EEPROM). Voll einsatzfähig.
* CUL V4 - ATMega32U2 Prozessor, 1 Kb RAM 32 Kb Flashmemory, 1 kByte EEPROM. Voll einsatzfähig. Genau genommen ein "Sparmodell" des V3, um Lieferengpässe des atmega32u4 Prozessors zu umgehen. Der reduzierte RAM-Speicher verursacht (zumindest gegenwärtig) beim Betrieb mit culfw und Fhem keine Einschränkungen oder Nachteile. Achtung: Flashen des CULv4 setzt DFU-Programmer 0.5.4 oder höher voraus.
= Sendefrequenz =
Das CUL gibt es in Ausführungen für 868 und 433 MHz.
Die Sende- und Empfangsfrequenz des CUL sind in weiten Bereichen einstellbar, im SlowRF Mode auch durch direkte Befehle aus Fhem (im HM Mode derzeit nicht unterstützt). Der wesentliche Unterschied der 868 und 433 MHz CULs ist ein auf die Frequenz richtig abgestimmter HF-Eingangskreis inklusive Antennenlänge.
Es ist es durchaus möglich, ein 868 MHz CUL auf 433 MHz einzustellen. Da dann aber die HF-Eingangskreis-Abstimmung und Antennenlänge nicht korrekt sind, ist Empfangs- und Sendeleistung suboptimal, die Reichweite sinkt. Dennoch wird diese Möglichkeit des freien Einstellens durch das Fhem Intertechnomodul genutzt, da Intertechnokomponenten mit 433 MHz arbeiten. Dazu wird beim Senden eines Intertechno-Befehls die Frequenz eines 868 MHz CULs kurz umgestellt.

Denkbar ist auch der Einsatz eines CUL 433 MHz im Zusammenhang mit HomeMatic. Hier wird das CUL normalerweise im HM Mode betrieben, dessen Frequenz auf 868 MHz fest eingestellt ist. Die verminderte Sendeleistung aufgrund der falschen Antenne fällt je nach örtlicher Gegebenheit eventuell nicht ins Gewicht, da HomeMatic aufgrund seiner besseren Empfänger grundsätzlich etwas bessere Reichweiten hat als die empfangsseitig simplen Intertechnomodule. Soll nun ein Intertechnomodul geschaltet werden, wird das CUL kurzzeitig auf SlowRF umgeschaltet und dann in 433 MHz betrieben, jetzt mit optimaler Antennenabstimmung zur Reichweitenoptimierung der Intertechno-Komponenten, danach wird sofort in den HM Modus zurückgeschaltet, wodurch sich die Frequenz auch automatisch wieder auf 868 MHz ändert. Theoretisch ist hierbei allerdings der Verlust von HM-ACK Meldungen möglich, wenn diese dem Moment eintreffen, in dem das CUL gerade auf Intertechno umgeschaltet ist.

= Bekannte Probleme =
Im Gegensatz zu den original FHZ Zentralen ist das CUL recht flankensteil, d.h. die Sende- und Empfangsfrequenz wird genauer eingehalten als z.b. bei einer FHZ1x00PC. Dies kann im Zusammenhang mit den eher ungenauen Sendern z.b. der FHTs Raumregler zu Empfangsproblemen führen. Es kann daher mitunter sinnvoll sein, die Sende und Empfangsbandbreite des CUL etwas zu erhöhen. Dies senkt jedoch gleichzeitig die Empfindlichkeit.

Bei Empfangsproblemen von z.B. HEM-Sensoren oder dem S300TH kann man folgendes testen:

* Man kann die Frequenz des CUL auf genau 868,35MHz einstellen. Standardmäßig ist hier aus Kompatibelitätsgründen 868,30MHz eingestellt. Diese Einstellung wird fest im NVRAM gespeichert und braucht nur einmal vorgenommen zu werden.
*: <code>set CUL_0 freq 868.350</code>
* Es ist möglich die "decision boundary" zu vergrößern, frei beschrieben: die "Entscheidungsgrenze" ob die empfangene Signalflanke digital "0" oder "1" darstellte (<nowiki>[https://groups.google.com/forum/#!msg/fhem-users/HAaBri3eQgk/pqxHlN1aHkIJ%7Csie Diskussion hier]</nowiki>). Möglich sind die Werte "4", "8" und "16". Default-Einstellung ist hier "4". Zur Steigerung der Empfangsqualität soll es hilfreich sein hier "8" einzustellen. Mitunter bringt jedoch erst die Einstellung auf "16" signifikante Verbesserungen beim Empfang von S300TH-Sensoren.
*: <code>set CUL_0 sens 8</code>
* Oft hilft auch, die Bandweite auf z.B. 464 khz aufzuweiten.
= Links =
* [[:Kategorie:CUL]] - weitere Seiten rund um CUL
* Hersteller / Bezugsquelle für CUL: [http://www.busware.de/tiki-index.php?page=CUL busware.de]
* [http://culfw.de/culfw.html culfw.de] - Homepage der CUL firmware
** [http://culfw.svn.sourceforge.net/viewvc/culfw/trunk/culfw/ Sourceforge CUL firmware]
* Google groups [https://groups.google.com/group/cul-fans/ CUL fans]

[[Kategorie:Other Components]]
[[Kategorie:CUL]]
[[Kategorie:Glossary]]

HM-CFG-LAN LAN Konfigurations-Adapter

2013-05-10T21:22:30Z

Generix: /* HMLAN versus CUL / CUNO / COC */

== Vorbemerkungen ==
Der HomeMatic LAN Konfigurations-Adapter (HMLAN) stellt eine Alternative zum [[CUN" class="mw-redirect]]O im HomeMatic Modus dar. Er ist eigentlich als Konfigurationstool gedacht, kann aber von der HomeMatic CCU zur Verbesserung der Funksituation genutzt werden. Deshalb kann er auch von FHEM als Funkadapter verwendet werden.

=== HMLAN versus CUL / CUNO / COC ===
Stand 17.01./12.03.2013 können folgende Homematic-Geräte nur mit einem HMLAN (aber nicht mit [[CUN" class="mw-redirect]]O / COC) <ins>umfassend</ins> mit FHEM betrieben werden:

* KeyMatic, Funk-Türschlossantrieb - (HM-Sec-Key, HM-Sec-Key-S, HM-Sec-Key-O, HM-Sec-Key-Generic)
* Bausatz, Schaltaktor für Batteriebetrieb - (HM-LC-Sw1-Ba-PCB)
* WinMatic, Funk-Fensterantrieb - (HM-Sec-Win)
* Funk-Rauchmelder - (HM-Sec-SD, HM-Sec-SD-Generic)
* Statusanzeige "im Retro-Design" - (HM-Dis-TD-T)
* <nowiki> [[HM-LC-SW1-BA-PCB]] </nowiki>
* <nowiki> [[HM-Sec-SFA-SM]] </nowiki>
* HM-RC-19
* HM-RC-19-B
* HM-RC-19-SW
* ...
* [[HM-LC-SW1-BA-PCB]]

Grund ist die im CUL / CUNO / COC fehlende AES-Übertragung (KeyMatic) und / oder ein fehlender (sogenannter) Burst-Modus (z.B. HM-Dis-TD-T).

'''Achtung:'''<ins>Diese Liste erhebt keinen Anspruch auf Vollständigkeit und die Angaben sind ohne Gewähr.</ins>

Siehe z.B. [http://forum.fhem.de/index.php?t=rview&goto=68226#msg_68226 diesen].

== Vorbereitung ==
Der HMLAN Konfigurator ist ähnlich wie der CUN(O) ein Netzwerkgerät. Er beherrscht DHCP und bezieht bei einem im Netzwerk erreichbaren DHCP Servers von diesem eine IP-Adresse. Da FHEM zwecks Kommunikation die IP-Adresse wissen muss, kann es sinnvoll sein, dem HMLAN Konfigurator zunächst eine statische Adresse zuzuweisen, da bei einer per DHCP vergebenen Adresse nicht sicher ist, dass diese sich nie ändert. Dies ist mit der auf der CD mitgelieferten "HM Lan-Interface Konfigurator" Software möglich. Eleganter ist es natürlich, dem HMLAN im DHCP-Server eine feste Adresse zuzuweisen - sofern dies vom gegeben DHCP Server als Konfigurationsoption unterstützt wird.

Wichtig ist aber vor allem, dass vor Verwendung die "AES Encryptet LAN Communication" abgeschaltet wird, da diese von FHEM nicht beherrscht wird. Dies ist unter "Change IP Settings" der "HM Lan-Interface Konfigurator" Software möglich (Achtung: Dem HMLAN Konfigurator liegen zwei Konfigurationsprogramme bei, bitte darauf achten, das Richtige zu verwenden).

Dies hat nichts mit der HM "[[AES Encryption]]" zu tun, die mit dem HMLAN Konfigurator genutzt werden könnte, mit CUL oder CUN(O) aber nicht.

Wenn das Konfigurationsprogramm Probleme hat das HMLAN zu finden, sollten alle nicht benutzten Netzwerkinterfaces vorübergehend deaktiviert werden, siehe [http://forum.fhem.de/index.php?t=msg&th=10933&goto=62960&rid=42#msg_62960 FHEM-Foren-Beitrag].

Da die Konfigrationssoftware nur unter Windows läuft, braucht man z.B. für OS X eine Windows Emulation.
Damit ist die Konfiguration jedoch problemlos möglich, sieh z.b. hier:
[http://forum.fhem.de/index.php?t=msg&th=11506&goto=67417&rid=417#msg_67417 Anleitung für OS X].

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

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

HMLAN kennt mehrere Attribute (siehe commandref), wichtig ist vor allem, für den HMLAN eine Adresse festzulegen, die HM-ID. Diese muss hexadezimal und 6 stellig sein. 000000 und FFFFFF sind nicht gültig. Jedes Wechseln dieser Adresse erfordert neues pairen '''aller'''HM Geräte!

Die Adresse sollte in fhem.cfg in Grossbuchstaben eingegeben werden, siehe [[HMLAN Konfigurator]].

Ein '''gleichzeitiger'''Zugriff von FHEM und der HomeMatic-Software auf den HMLAN-Konfigurator ist nicht möglich, da letzterer nur eine Verbindung zulässt. Müssen oder wollen Sie temporär also z.B. mit der Windows-Software von HomeMatic zugreifen, ist FHEM zu deaktivieren.

== Pairen von Geräten ==
Jedes HM Geräte muss vor Verwendung mit der HM-Zentrale, hier also dem HMLAN Konfigurator gepairt werden. Die Adresse der HM Geräte ist nicht frei wählbar, sondern fest in den Geräten eingestellt. Details zum Pairen hier: [[HomeMatic Devices pairen]]

== Bekannte Probleme ==
Die hexadezimale Adresse sollte in der ''fhem.cfg''in Großbuchstaben eingegeben werden, da der HMLAN-Konfigurator seine eigene Adresse ebenfalls in Großbuchstaben zurück gibt.
''HMLAN.pm''überprüft alle 30 Sekunden, ob die Adresse des HMLAN-Konfigurators von der in FHEM eingestellten abweicht und setzt sie ggf. neu. ''HMLAN.pm''in Versionen vor Februar 2012 unterscheidet zwischen Upper- und Lowercase, sodass z.b. 123abc für ''HMLAN.pm''eine andere Adresse als 123ABC ist. Dies führt zum Neusetzen der an sich gleichen Adresse alle 30 Sekunden.

Selten lehnt der HMLAN-Konfigurator ohne erkennbaren Grund nach monatelangem störungsfreien Betrieb die Verbindung ab:

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

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

* deaktivieren Sie das CUL in der ''fhem.cfg''.
* konfigurieren Sie den HMLAN Konfigurator '''von Hand''' direkt unterhalb der alten CUL-Definition in der ''fhem.cfg'' und zwar '''vor''' allen referenzierten HM Geräten ("save" nicht vergessen). Falls Sie den HMLAN von FHEM automatisch erkennen und anlegen lassen, dann wird dieser in der ''fhem.cfg'' '''nach''' den HM-Geräten angelegt und es kann keine Zuweisung der Geräte vorgenommen werden.
** der HMLAN '''muss''' die gleiche ''hmID'' wie das bisherige CUL erhalten (ansonsten müssen alle Geräte neu gepairt / angelernt werden).
** AES muss im HMLAN abgeschaltet werden (das CUL arbeitet auch ohne).
</li><li> verbinden Sie den HMLAN Konfigurator mit ihrem Netzwerk und ziehen das CUL aus der USB-Buchse.
</li><li> geben Sie in der FHEM-Befehlszeile ''shutdown restart''gefolgt von <Enter> (nicht "save") ein (evtl. reicht auch ein ''rereadcfg'').
</li><li> kontrollieren Sie im Event-Monitor und in den HM-Device-Logs von FHEM die Kommunikation.
</li></ul>
Bitte beachten: Falls man dem CUL keine explizite hmID per Attribut zugewiesen hat, wird diese ID aus "F1<housecode>" zusammengebaut. Die hmID muss man auf dem HMLAN explizit setzen.

== Links ==
Details zu HMs "[[AES Encryption]]"

1% Regel

2013-05-10T20:55:17Z

Generix: Die Seite wurde neu angelegt: „= 1% Relative Frequenzbelegungsdauer = Die Bundesnetzagentur schreibt für die Nutzung verschiedener ansonsten frei nutzbarer Frequenzbereiche sogenannte maxim…“

= 1% Relative Frequenzbelegungsdauer =
Die Bundesnetzagentur schreibt für die Nutzung verschiedener ansonsten frei nutzbarer Frequenzbereiche sogenannte maximale relative Frequenzbelegungsdauern fest. Sinn dieser Maßnahme ist es, die Nutzung der Frequenzbänder durch mehrere Nutzer auch bei Reichweitenüberlagerung zu ermöglichen. Für 868,35 MHz, also der Frequenz, in dem das HM, FS20 und FHT System arbeitet, sind ≤ 1% vorgeschrieben. Dies ergibt 36 Sekunden Sendedauer je Stunde. Besonders bei der eher langsamen Datenübertragung der FHT und FS20 Protokolle kann es zu Engpässen kommen.

== Details ==
Um einen Kommunikationskanal durch mehrere Teilnehmer effektiv zu nutzen, bieten sich mehrere Verfahren an. Im Wesentlichen sind dies:

* Token Verfahren. Senden darf nur, wer gerade eine von Teilnehmer zu Teilnehmer herumgereichtes "Pfand" (=Token) besitzt. Tokenverfahren sind aufwändig zu implementieren und erfordern bidirektionale Kommunikation.
* <nowiki> LBT Verfahren. Senden darf ein Teilnehmer nur, wenn er sich vorher durch "lauschen" vergewissert hat, dass sonst niemand sendet, der Kanal also frei ist. (LBT = Listen before talk). Es ist theoretisch jedoch denkbar, dass zwei Sender zugleich lauschen, den Kanal frei vorfinden und zugleich anfangen zu senden. LBT Verfahren sind in frei nutzbaren Kanälen mit vielen Teilnehmern schwierig zu implementieren. (Die Kommunikation zwischen [[RFR CUL]] arbeitet aber z.b. nach diesem Verfahren.) </nowiki>
* Zeitbeschränkung. Jeder Teilnehmer darf nur sehr kurz senden. Die Sendedauer ist so zu wählen, dass jeder Teilnehmer eine signifikante Chance hat, zufällig auf einen freien Kanal zu treffen. Dies ist beispielsweise gegeben, wenn der Kanal zu 90 oder mehr Prozent frei ist.

Bei LBT und Zeitbeschränkung sind außerdem Verfahren zu implementieren, die greifen wenn der Kanal nicht frei war, die Aussendung also durch Überlagerung einer anderen Sendung gestört wurde. In der Regel wird man den erfolglosen Sendeversuch nach einer zufälligen Zeit wiederholen.

Die Verfahren sind in der obigen Reihenfolge weniger aufwändig zu implementieren, d.h. Zeitbeschränkung erfordert den geringsten Aufwand.

Die Bundesnetzagentur schreibt vor, dass im Frequenzbereich von 868,000 bis 868,600 MHz 1% "Duty cycle" ODER die Nutzung von LBT-Verfahren implementiert sind, wobei sie definiert:

<dl><dd>''Die relative Frequenzbelegungsdauer (duty cycle) in % kennzeichnet die Dauer der Aussendungen eines Senders auf einer Frequenz bezogen auf 1 Stunde. Die Gesamtsendezeit kann auf mehrere Intervalle aufgeteilt werden.''</dd></dl>
und

<dl><dd>''LBT: Verfahren, mit dem die Kanalbelegungssituation vor Beginn und während der Aussendung geprüft wird. Aussendung erfolgt nur bei freiem Kanal.''</dd></dl>
Zumindest wegen des geringen Implementierungsaufwandes hat ELV als Entwickler der FS20 / FHT Funkkomponenten kein LBT verwendet, sondern beachtet vielmehr die maximale Frequenzbelegungsdauer.

== Bedeutung für das FS20 / FHT Funksystem ==
Aus der relativen Frequenzbelegungsdauer von 1% je Stunde, also nur 36 Sekunden je Stunde, ergeben sich für das FS20 / FHT System deutliche Einschränkungen. Insbesondere ist die [[Maximal nutzbare Geräte]] stark eingeschränkt. Wegen der umfangreichen bidirektionalen Kommunikation zwischen Raumreglern und der Zentrale mit einer im Vergleich zu HomeMatic eher geringen Bandbreite lassen sich beispielsweise sinnvoll nur etwa 10-12 Räume mit FHT über Funk steuern.

Problematisch kann die 1% Regel auch in Debuggingphasen sein, wenn also neue FHEM Konfigurationen mehrfach in kurzer Folge ausprobiert werden.

Praktisch umgesetzt ist das 1% Sendelimit z.b. im [[LOVF]] (= Limit-overflow). Eine FS20 Übertragung benötigt mindestens ca. 220ms also ca. 22 Sendeeinheiten. Ist die maximale Frequenzbelegungsdauer erreicht, dauert es also mindestens 22 Sekunden, bis erstmals wieder gesendet werden kann.

Daraus ergibt sich, dass maximal 163 FS20 Kommandos pro Stunde gesendet werden können. Wird dieser Wert überschritten, meldet FHEM '''CUL TRANSMIT LIMIT EXCEEDED'''. Eine weitere Schaltung von FS20 Komponenten ist dann nicht mehr möglich.

HomeMatic verwendet eine höhere Datenübertragungsrate, sodass die Kommunikation wesentlich schneller abläuft und die Grenzen wesentlich weiter sind.

== Links ==
Bundesnetzagentur [http://www.bundesnetzagentur.de/cae/servlet/contentblob/134184/publicationFile/2570/FundstelleId5772pdf.pdf [1]]Vfg. 20 / 2006
[http://www.bundesnetzagentur.de/cae/servlet/contentblob/38206/publicationFile/2580/ShortRangeDevicesSRD_ID17299pdf.pdf [2]]Vfg 30 / 2006 geändert mit Vfg. 39/2009

OWServer & OWDevice

2013-05-10T20:55:14Z

Generix: Die Seite wurde neu angelegt: „'''Einleitung:''' Bei OWServer handelt es sich um eine 1-Wire Server Komponente und bei OWDevice um eine Geräte-Komponente, welche die angeschlossenen Module …“

'''Einleitung:'''
Bei OWServer handelt es sich um eine 1-Wire Server Komponente und bei OWDevice um eine Geräte-Komponente, welche die angeschlossenen Module definiert-
Die Module benötigen die Serverkomponente von [http://www.owfs.org OWFS].

'''Wichtig:'''
Die Module sind eine eigenständige Möglichkeit, den 1-Wire Bus anzusteuern und kommen ohne die Module aus, deren Namen aus Großbuchstaben bestehen (wie OWX, OWSWITCH, OWTHERM, etc.).
Umgekehrt können die Module OWX, OWSWITCH, OWTHERM, etc. auch mit dem Backendmodul OWServer zusammenarbeiten, siehe dazu die commandref der betreffenden Module.

'''Vorbereitung:'''
Wie oben erwähnt, setzt OWServer/OWDevice auf OWFS auf. Dazu ist eine funktionierende OWFS Installation notwendig. Die Installation ist auf der selben Plattform (Debian-based) möglich oder auch Remote (zBsp Dockstar oder RPi). Eine gute [http://owfs.org/index.php?page=standard-devices Liste der Standard Devices]auf der Homepage von OWFS einzusehen. Nicht alle Standard Devices sind in OWDevice verfügbar (siehe unten).Wenn OWFS funktioniert kann's weiter gehen...

'''owfs Pakete installieren'''
1)entweder sind die Pakete bereits vorpaketiert und man muss nur das [http://owfs.davromaniak.eu/ Repository] noch in /etc/apt/sources.list eintragen

2)oder man muss selber kompilieren ([http://www.navitron.org.uk/forum/index.php?topic=12604.msg151750#msg151750 Quelle]).
Für den RaspberryPi wurde dies schon durchgeführt: [http://forum.fhem.de/index.php?t=getfile&id=2742&rid=118 owfs_2.8p17-1_all.zip ]

<nowiki>sudo apt-get install automake autoconf autotools-dev gcc g++ libtool libusb-dev fuse-utils libfuse-dev swig python-dev tcl-dev php5-dev
sudo apt-get install git git-buildpackage dh-make quilt php5-cli
git clone [git://git.debian.org/collab-maint/owfs.git git://git.debian.org/collab-maint/owfs.git] git
git-buildpackage -uc -us
cd ..
sudo dpkg -i ./owserver_2.8p7+cvs20110310-1_i386.deb ./libow-2.8-7_2.8p7+cvs20110310-1_i386.deb ./owfs-common_2.8p7+cvs20110310-1_all.deb
sudo dpkg -i ./owhttpd_2.8p7+cvs20110310-1_i386.deb</nowiki>
diese Pakete werden alle gebaut:

<nowiki>libow-2.8-7_2.8p7+cvs20110310-1_i386.deb owfs-common_2.8p7+cvs20110310-1_all.deb
libowcapi-2.8-7_2.8p7+cvs20110310-1_i386.deb owfs-dbg_2.8p7+cvs20110310-1_i386.deb
libow-dev_2.8p7+cvs20110310-1_i386.deb owfs-doc_2.8p7+cvs20110310-1_all.deb
libownet-2.8-7_2.8p7+cvs20110310-1_i386.deb owfs-fuse_2.8p7+cvs20110310-1_i386.deb
libownet-dev_2.8p7+cvs20110310-1_i386.deb owftpd_2.8p7+cvs20110310-1_i386.deb
libownet-perl_2.8p7+cvs20110310-1_all.deb owhttpd_2.8p7+cvs20110310-1_i386.deb
libownet-php_2.8p7+cvs20110310-1_all.deb owserver_2.8p7+cvs20110310-1_i386.deb
libow-perl_2.8p7+cvs20110310-1_i386.deb ow-shell_2.8p7+cvs20110310-1_i386.deb
libow-php5_2.8p7+cvs20110310-1_i386.deb python-ow_2.8p7+cvs20110310-1_i386.deb
libow-tcl_2.8p7+cvs20110310-1_i386.deb python-ownet_2.8p7+cvs20110310-1_all.deb
owfs_2.8p7+cvs20110310-1_all.deb</nowiki>

'''Unterstütze Geräte:'''
Eine aktuelle Liste der von OWDevice unterstützen Geräte findet man im [http://fhem.de/commandref.html#OWDevice FHEM-Commandref].

'''Konfiguration in FHEM:'''
Als erstes definiert man OWServer. Hiermit wird ein logischer OWServer definiert, auf welchem OWFS installiert ist

<nowiki>define <name> OWServer <protocol></nowiki>
<protocol> hat das Format <hostname>:<port>.

zBsp:

<nowiki>define myOWServer OWServer 192.168.14.100:4304</nowiki>
oder wenn sich OWFS auf dem gleichen Server befindet wie FHEM:

<nowiki>define myOWServer OWServer localhost:4304</nowiki>
Nach erfolgreichem "define" ist ein Klick auf den "Save" Button notwenig. Wenn nun der Status von myOWServer auf "Initialized" steht, ist der Server verbunden. Um sicher zu sein, dass der OWServer funktioniert, kann eine manuelle Abfrage der Device durchgeführt werden mit:

<nowiki>get myOWServer devices</nowiki>
Danach werden sämtliche angeschlossene Geräte angezeigt, inkl. Busmaster

'''OWServer Set Befehle:'''
<nowiki>set <name> <value>
value:
timeout/directory
timeout/ftp
timeout/ha7
timeout/network
timeout/presence
timeout/serial
timeout/server
timeout/stable
timeout/uncached
timeout/usb
timeout/volatile
timeout/w1
units/pressure_scale
units/temperature_scale</nowiki>
Weitere Informationen zu den Set Befehlen sind im [http://owfs.org/uploads/owserver.1.html#sect41 OWServer Manual] zu entnehmen.

'''OWServer Get Befehle:'''
<nowiki>get <name> <value>
value:
/settings/timeout/directory
/settings/timeout/ftp
/settings/timeout/ha7
/settings/timeout/network
/settings/timeout/presence
/settings/timeout/serial
/settings/timeout/server
/settings/timeout/stable
/settings/timeout/uncached
/settings/timeout/usb
/settings/timeout/volatile
/settings/timeout/w1
/settings/units/pressure_scale
/settings/units/temperature_scale</nowiki>
Zusätzlich stehen die FHEM-internen Befehle "errors" und "devices" zur Verfügung.
zBsp:

<nowiki>get <Devicename> errors #listet die Fehler des Device auf
get <Devicename> devices #scan den Server nach Device</nowiki>

'''Angeschlossene Geräte auslesen:'''
Grundsätzlich werden die am Busmaster von OWFS angeschlossenen 1-Wire Geräte durch aktives autocreate nach einem Neustart (erfordert shutdown restart) selber in FHEM definiert.
Der Busmaster (zBsp ein DS9490r) selbst wird ebenfalls eingelesen und angezeigt.

Definition von Geräten:
Es ist auch möglich, Geräte manuell anzulegen. Dies erfolgt in folgendem Format:

<nowiki>define <name> OWDevice <address> [<interval>]</nowiki>
zBsp:

<nowiki>define Vorlauftemp OWDevice 28.334F2B040000 60</nowiki>
Wobei der Wert 60 als Abfrageintervall in Sekunden zu verstehen ist.

'''OWDevice State:'''
Bei Temperaturfühler wie DS18S20 wird das Reading "state" wie folgt ausgegeben:

<nowiki>temperature: 56.1875 alarm: 1</nowiki>
Um die Temperatur wie bei anderen Temperatur-Sensoren (zBsp. CUL_WS) anzuzeigen, hilft das Attribut "stateFormat". Dies kann wie folgt definiert werden:

<nowiki>attr <Devicename> stateFormat T: <wert></nowiki>
zBsp:

<nowiki>attr Boiler stateFormat T: temperature</nowiki>
alternativ

<nowiki>attr <Devicename> stateFormat {sprintf("%.1f",ReadingsVal("<Devicename>","temperature",0))."°C"}</nowiki>
Zusätzlich rundet das obenstehende Attribut mit "%.1f" die Temperatur auf eine Kommastelle.

'''Tips und Tricks'''
1-wire-Geräte sind häufig generische Geräte, wie Zähler und Spannungsmesser (A/D-Wandler), an denen Sensorik hängt. Die rohen Werte vom 1-wire-Gerät (Zählimpulse, Spannungen) sind dann noch in menschenlesbare Werte zu verwandeln. Hier helfen userReadings, z.B.

<nowiki>attr myEnergyMeter userReadings energy { (ReadingsVal("myEnergyMeter","count.A",0)+AttrVal("myEnergyMeter","myBasis",0))/1250.0;; }</nowiki>

EIB / KNX

2013-05-10T20:55:03Z

Generix: Die Seite wurde neu angelegt: „Fhem kann auch Geräte über EIB bzw KNX steuern. '''Hinweis''': Obwohl hier explizit ein Raspberry Pi verwendet wird, sollte die Ableitung für jedes Debian-…“

Fhem kann auch Geräte über EIB bzw KNX steuern.

'''Hinweis''': Obwohl hier explizit ein Raspberry Pi verwendet wird, sollte die Ableitung für jedes Debian-Basierte (also auch Ubuntu) anwendbar sein.

Zu diesem Zweck habe ich mir einen Raspberry Pi und einen TUL ([http://busware.de/tiki-index.php?page=TUL http://busware.de/tiki-index.php?page=TUL]) besorgt.
Der TPUART ist ein Baustein, der die Verbindung zwischen dem EIB und einer seriellen Schnittstelle herstellt. In dem USB TUL ist dem TPUART ein Microcontroller vorgeschaltet, der eine Wandlung von USB nach seriell vornimmt.
== Vorbereitung ==
Der TUL wird ohne Firmware ausgeliefert und muss entsprechend vor der ersten Benutzung programmiert werden. Dies kann direkt über den Raspberry Pi geschehen:

<nowiki>sudo apt-get install dfu-programmer
wget -O TPUARTtransparent.hex [http://busware.de/tiki-download_file.php?fileId=54 http://busware.de/tiki-download_file.php?fileId=54]
sudo dfu-programmer atmega32u4 erase
sudo dfu-programmer atmega32u4 flash TPUARTtransparent.hex
sudo dfu-programmer atmega32u4 reset
sudo reboot</nowiki>
Der Raspberry Pi wird wie auf [http://www.fhemwiki.de/wiki/Kategorie:Raspberry_Pi http://www.fhemwiki.de/wiki/Kategorie:Raspberry_Pi] beschrieben vorbereitet.

Den TUL kann man wohl per eibd oder direkt einbinden. Die direkte Einbindung erfolgt über ein

<nowiki>define EIB TUL tul:/dev/ttyACM0@57600 1.1.255</nowiki>
in der fhem.cfg . Der letzte Parameter ist die EIB-Adresse unter der sich der TUL einbucht. Somit sollte es eine freie Adresse sein.

In diesem Fall ist die Adresse in der Punkt-Notation angegeben. Die Fhem versteht diese Notation, verwendet aber meist folgende Notation:

<nowiki>abcc</nowiki>
wobei a und b hexadezimale Werte von 0-f und cc hexadezimale Werte von 0-255 einnehmen können. Dies entspricht dann der Adresse

<nowiki>a.b.cc</nowiki>
genaueres kann man in der Dokumentation unter [http://fhem.de/commandref.html#EIB http://fhem.de/commandref.html#EIB] nachlesen.

== Inbetriebnahme ==
Jetzt ist es Zeit das Web-Interface von Fhem aufzurufen. Der RaspberryPi sollte jetzt schon im eigenen Intranet unter [http://raspberrypi:8083/ http://raspberrypi:8083/] erreichbar sein. Durch das autocreate feature kennt das System schon einige Geräte.

=== Lampen ===
Wenn man nun mal alle Lichtschalter betätigt, kennt das System schon die Adressen der im EIB eingebundenen Lampen. Diese sind die einfachsten Geräte im Fhem - sie lassen sich sofort über das Webinterface steuern. Über das Attribut "Raum" können die Lampen den verschiedenen Räumen zugeordnet werden, wobei das Interface nur ein Dropdown mit den schon bekannten Räumen anbietet - also erstmal nicht brauchbar ist :-(

Die Lösung besteht darin die "attr"-Zeile im Interface in das obere Eingabefeld abzutippen - also z.B.

<nowiki>attr EIB_abcd room Wohnzimmer</nowiki>
und anschliessend '''die Eingabetaste drücken'''. Der "save" Button neben dem Eingabefeld führt nicht zum gewünschten Ergebnis. Er scheint dem Festschreiben der neuen Konfiguration in der fhem.cfg zu dienen und sollte somit ab und zu betätigt werden.

Nach dieser Eingabe taucht der neue Raum auch im entsprechenden Dropdown auf.

Den kryptischen Namen der Lampe ändert man auf gleichem Weg über die Eingabe von

<nowiki>rename EIB_abcd wohnzimmer.deckenleuchte</nowiki>
Auch hier ein Achtung: der Name aller Objekte muss in Fhem eindeutig sein. Eine Bezeichnung 'deckenleuchte' wird es für mehrere Räume geben und reicht somit nicht aus.

=== Temperatursensoren ===
Definiert werden die Sensoren zunächst wie die Lampen. Damit das System allerdings weiss, dass sie als Temperatur angezeigt werden sollen, muss noch ein

<nowiki>attr <name temp sensor> model tempsensor</nowiki>
gesetzt werden. Für Heizungsventile gilt das gleiche, nur dass man dem System hier sagen muss, dass es sich um einen Prozent-Wert handelt. Je nach Information entweder

<nowiki>attr <name ventil> model percent</nowiki>
oder

<nowiki>attr <name ventil> model percent255 (noch nicht von mir getestet)</nowiki>
Um zu verhindern, dass Fhem für diese Sensoren Schaltflächen anzeigt, kann man

<nowiki>attr <name sensor> dummy 1</nowiki>
setzen. Achtung: sollte für dieses Element schon ein webCmd gesetzt sein, werden die Schaltschlächen _nicht_ deaktiviert.

=== Tipps ===
Die Fhem Kommandos unterstützen anscheinend reguläre Ausdrücke. Hat man z.B. viele Temperatursensoren mit dem Namen "ist.<raum>" angelegt und möchte ihnen nun das attribut "dummy" setzen, kann man das mit

<nowiki>attr ist.* dummy 1</nowiki>
vereinfachen.

Raspberry Pi & HTTPS

2013-05-10T20:55:03Z

Generix: Die Seite wurde neu angelegt: „Damit das Kennwort verschlüsselt übertragen wird, ist eine HTPPS Verbindung wichtig. Zunächst müssen folgende Pakete nachinstalliert werden: <nowiki>sud…“

Damit das Kennwort verschlüsselt übertragen wird, ist eine HTPPS Verbindung wichtig.

Zunächst müssen folgende Pakete nachinstalliert werden:

<nowiki>sudo apt-get update
sudo apt-get install perl-io-socket-ssl
sudo apt-get install libio-socket-ssl-perl</nowiki>
Dann muss im modpath Verzeichnis (Das liegt beim RPi unter /usr/share/fhem/certs/) das Verzeichnis "certs" erstellt werden. In dieses Verzeichnis kommen zwei Dateien die mithilfe von OpenSSL erstellt werden: server-key.pem und server-cert.pem. Unter Linux und MacOSX kommen wir über das Terminal an die Dateien.

Im Terminal und Linux/OSX geht dies mit folgendem Befehl:

<nowiki>openssl req -new -x509 -nodes -out server-cert.pem -days 3650 -keyout server-key.pem</nowiki>
Ihr könnt mit dem Terminal auch direkt in das modpath und mit mkdir certs und cd certs das Verzeichnis erstellen. Oder einfach die Dateien irgendwo erstellen und mit dem Finder oder Windows Explorer dort hin kopieren.

Anschließend in FHEM mit dem Befehl

<nowiki>attr WEB HTTPS</nowiki>
Für das Smartphone Interface entsprechend

<nowiki>attr WEBphone HTTPS</nowiki>
HTTPS aktivieren, nach einem Neustart erfolgt der Zugriff per HTTPS über [https://192.168.n.n:8083/fhem https://192.168.n.n:8083/fhem] . Es ist wichtig die Adresse mit https:// aufzurufen, da es keine automatische Weiterleitung von http auf https existiert.

Ölverbrauchsanzeige / Betriebsstundenzähler

2013-05-10T20:55:03Z

Generix: Die Seite wurde neu angelegt: „Problem: oft weiß man nicht wie viel Öl man tatsächlich verbraucht und welche Veränderungen an der Heizungen welche Auswirkungen haben. Die Lösung: eine …“

Problem: oft weiß man nicht wie viel Öl man tatsächlich verbraucht und welche Veränderungen an der Heizungen welche Auswirkungen haben.
Die Lösung: eine Ölverbrauchsanzeige direkt in FHEM.
Hierfür habe ich ein Relais (Finder 55.34.8.230.0040 [http://www.elv.de/elv-fs20-kse-funk-klingelsignal-erkennung.html ELV] angeschlossen. So dass wenn der Brenner einschaltet sich der Kontakt am anderen ende öffnet, dadurch kein Strom mehr zum KSE fließt und der dann "on" an FHEM sendet. Logischerweise hätte ich gedacht es muss so angeschlossen, dass Strom zum KSE fließt wenn der Brenner an ist, dies hat aber nicht funktioniert, daher andersrum. Das Relais ist ein Wechsler, daher kein Problem.
FHEM erstellt durch autocreate automatisch ein neues Device, definiert sieht es bei mir so aus:

<nowiki>define fs_boiler FS20 1be4 00
attr fs_boiler devStateIcon on:HeizungOn off:HeizungOff
attr fs_boiler dummy 1
attr fs_boiler eventMap on:off off:on
attr fs_boiler icon icoHEIZUNG
attr fs_boiler model fs20kse</nowiki>
Und der entsprechende Plot:

<nowiki>define FileLog_fs_boiler FileLog ./log/fs_boiler-%Y.log fs_boiler
attr FileLog_fs_boiler logtype fs20:Window,text
define weblink_fs_boiler weblink fileplot FileLog_fs_boiler:fs20:CURRENT</nowiki>
Die Icons für die Heizung habe ich irgendwo aus dem Forum, weiß allerdings nicht mehr welcher Thread.

So, nun wird zumindest schonmal dargestellt wann die Heizung an oder aus ist.
Um den Ölverbauch zu messen werden einige weitere Codes benötigt:
Zuerst ein Notify:

<nowiki>define boiler_consumption notify fs_boiler {\
if("%" eq "on") {\
$data{boiler_last} = time();;\
} elsif("%" eq "off") {\
$data{boiler_min} = (time()-$data{boiler_last})/60*0.03626;;\
fhem "trigger boiler_consumption $data{boiler_min}";;\
}\
}</nowiki>
Dieser berechnet aus der Differenz zwischen on und off Minutengenau den Verbrauch. Hierfür muss man wissen welche Düse verbaut ist und was für einen Durchsatz sie hat. Unsere hat 2,5kg/Stunde Durchsatz (steht auf der Düse) dies habe ich in Liter umgerechnet (laut Wikipedia besitzt Heizöl eine Dichte von 0,820–0,860 kg/l [http://de.wikipedia.org/wiki/Heizöl [1]]) und dies anschließend durch 60 geteilt um es als Liter/Minute darzustellen. Daher kommt der Wert 0.03626 im Notify.
Hierzu nun der Log und Plot:

<nowiki>define boiler_log FileLog ./log/boiler-%Y-%m.log boiler_consumption
define Oilconsumption weblink fileplot boiler_log:oil:CURRENT
attr Oilconsumption label sprintf("Consumption (l) today: %.2f total %.2f avg/h", $data{sum1}, ($data{sum1}/$hour))</nowiki>
Der Gplot-Syntax folgt gleich. Zuerst eine kurze Erklärung. Ich lasse im Label den Tagesverbrauch auf 2 Nachkommastellen gerundet sowie den aktuellen Durschnittsverbrauch Anzeigen. Leider funktioniert der Durschnittsverbrauch nur für den aktuellen Tag und nicht für vorherige, da immer durch die Aktuelle Stunde geteilt wird, bei vorherigen Tagen müsste aber durch 24 geteilt werden. Habe ich noch nicht geschafft.
Die gplot für den Plot:

<nowiki>############################
# Display the oil consumption.
# 2012-12-24_14:48:31 boiler_consumption 0.2634893333
set terminal png transparent size <SIZE> crop
set output '<OUT>.png'
set xdata time
set timefmt "%Y-%m-%d_%H:%M:%S"
set xlabel " "
set ytics
set y2tics
set title '<L1>'
set grid xtics y2tics
set y2label "Oilconsumption (l)"
set ylabel "Oilconsumption (l)"
#FileLog 3::0:
plot "<IN>" using 1:3 title 'Oilconsumption (l)' with lines</nowiki>
Das wärs für die Verbrauchsanzeige. Das meiste hiervon basiert auf verschiedene Beiträge aus dem Forum und google-groups.

Zur Kontrolle oder Alternativ kann man auch einen Betriebsstundenzähler programmieren:

<nowiki>define boiler_time notify fs_boiler {\
if("%" eq "on") {\
$data{boiler_last} = time();;\
} elsif("%" eq "off") {\
$data{boiler_min} = (time()-$data{boiler_last})/60;;\
fhem "trigger boiler_time $data{boiler_min}";;\
}\
}
define boiler_time_log FileLog ./log/boiler_time-%Y-%m.log boiler_time</nowiki>
Hier lasse ich nur ein Log schreiben, ich benötige kein Plot, müsste aber mit leichter Anpassung des oberen gplot-Syntaxes eicht zu bewerkstelligen.

Zusätzlich binde ich noch eine Grafik mit dem Ölpreisverlauf direkt von Tecson ein:

<nowiki>define Heizoel weblink image http://www.tecson.de/tl_files/pepesale/bilder_inhalt/_hoel.gif
attr Heizoel htmlattr width="551" height="594"</nowiki>

Zuhause-Status per WLAN Anmeldung (Fritzbox)

2013-05-10T20:55:02Z

Generix: Die Seite wurde neu angelegt: „Wer eine FritzBox für FHEM und als WLAN Access Point nutzt, kann die Anmeldung eines WLAN Gerätes (z. B. Smartphone) in FHEM als Trigger nutzen. == fhem.cfg…“

Wer eine FritzBox für FHEM und als WLAN Access Point nutzt, kann die Anmeldung eines WLAN Gerätes (z. B. Smartphone) in FHEM als Trigger nutzen.

== fhem.cfg: ==
<nowiki>define testwlan_at at +*00:01:00 trigger testwlan
define testwlan notify testwlan {my $aaa="";;\
$aaa=qx(/usr/bin/ctlmgr_ctl r landevice settings/landevice'''X'''/active );;\
$aaa=$aaa * 1;;\
fhem "set ErwinatHome $aaa";;}
define ErwinatHome dummy</nowiki>
== Kurze Erklärung: ==
* Jede Minute wird das Testwlan notify getriggert.
* im Testnotify wird ein FritzBox-ctlmgr Befehl abgesetzt, der entweder 0 oder 1 zurückliefert.
* Das Dummy device ErwinatHome bekommt im state 0 oder 1
=== Hilfe ===
Das '''X'''im '''landeviceX'''müsst ihr selbst herausfinden, welches WLAN Gerät bei euch welche Nummer hat.
Evtl. hilft zum herausfinden, welche Zahl für '''X'''die richtige ist, auf der FritzBox-Telnet Befehlszeile auch folgendes:

<nowiki>/usr/bin/ctlmgr_ctl r landevice settings/landeviceX/name</nowiki>
Eine gute Quelle für FB spezifische Info ist: [http://www.wehavemorefun.de/fritzbox/index.php/Ctlmgr_ctl http://www.wehavemorefun.de/fritzbox/index.php/Ctlmgr_ctl] AVM-Wiki

Ich hab getestet mit FB7270, Feedback bestätigt, dass es auch mit FB7390 funktioniert

Have fun!
<a href="/w/index.php?title=Benutzer:Erwin111&action=edit&redlink=1" class="new" title="Benutzer:Erwin111 (Seite nicht vorhanden)">Erwin111</a>

Zuhause-Status

2013-05-10T20:55:00Z

Generix: Die Seite wurde neu angelegt: „Abhängig davon, ob man sich zuhause aufhält, schläft oder ausser Haus ist, sollen Geräte unterschiedlich geschaltet werden. Dabei sollen # beim Statuswec…“

Abhängig davon, ob man sich zuhause aufhält, schläft oder ausser Haus ist, sollen Geräte unterschiedlich geschaltet werden.

Dabei sollen

# beim Statuswechsel (also "ich komme nach hause", "ich gehe schlafen" etc) Geräte geschaltet werden
# regelmäßig geplante "at *" -Vorgänge ihr Verhalten auch davon abhängig machen, ob jemand zuhause ist oder nicht.

Der Status kann z. B. per Schalter gesetzt werden.
Automatisiert geht das auch z. B. [[Zuhause-Status per WLAN Anmeldung (Fritzbox)]]

== Lösungsansatz ==
Es wird eine Variable HomeStatus als dummy-device, also als Variable definiert.

Desweiteren werden ein 4-Tasten-Wandschalter fs20-s4a und eine 4-Tasten-Fernbedienung fs20-s4 mit identischem Hauscode und Tastencodes versehen, die Tasten angelernt und benannt in HomeStat1, HomeStat2, HomeStat3, HomeStat4.
Der Wandschalter kommt neben die Wohnungstür, die Fernbedienung ans Bett.

Beim Drücken dieser Tasten wird HomeStatus auf 1, 2, 3 oder 4 gesetzt. Ausserdem werden die gemäß dem neuen Status benötigten bzw. nicht mehr benötigten Geräte ein- oder ausgeschaltet:

<dl><dt>Bei Setzen von HomeStatus 1 (ich komme zuhause an)
</dt><dd> - Media an
</dd><dd> - Heizung auf Tagtemperatur
</dd><dd> - WLAN an
</dd></dl>
<dl><dt> Bei Setzen von HomeStatus 2 (ich gehe schlafen)
</dt><dd> - Alle Lampen aus ausser Schlafzimmer
</dd><dd> - Media aus
</dd><dd> - Heizung auf Nachttemperatur
</dd><dd> - WLAN aus
</dd></dl>
<dl><dt>Bei Setzen von HomeStatus 3 (verlassen der Wohnung für kurze Zeit)
</dt><dd> - Alle Lampen aus
</dd><dd> - Media aus
</dd><dd> - Heizung auf Nachttemperatur
</dd><dd> - WLAN aus
</dd></dl>
<dl><dt>Bei Setzen von HomeStatus 4 (ich verlasse die Wohnung für längere Zeit)
</dt><dd> - Alles aus
</dd><dd> - Heizung runterregeln auf 'Ferienprogramm'
</dd><dd> - WLAN aus
</dd></dl>
Regelmäßig geschaltete Geräte berücksichtigen ebenfalls den HomeStatus, z.B. startet das Wakeuplight nur an Wochentagen und nur wenn ich zuhause bin, also der HomeStatus < 3 ist.

== Codings ==
<nowiki>define HomeStatus dummy
attr HomeStatus room Wohnung
define whg_HomeStat1 FS20 696c 00
define whg_HomeStat2 FS20 696c 01
define whg_HomeStat3 FS20 696c 02
define whg_HomeStat4 FS20 696c 03</nowiki>
<nowiki>define Zuhause notify whg_HomeStat1 set HomeStatus 1;;trigger whg_Audio on;;set whg_WLAN,wz_MacMini on;;set ez_FHT desired-temp 21.0
define Schlafen notify whg_HomeStat2 set HomeStatus 2;;trigger whg_MediaAus off;;set ez_FHT desired-temp 19.0;;set ez_LichtAlle,wz_LichtAlle,ku_LichtAlle,whg_WLAN off
define KurzWeg notify whg_HomeStat3 set HomeStatus 3;;set ez_FHT desired-temp 18.5;;trigger whg_MediaAus off;;set whg_WLAN,Wohnung_Licht off
define LangeWeg notify whg_HomeStat4 set HomeStatus 4;;trigger whg_MediaAus off;;set Wohnung_Licht,whg_WLAN,wz_MacMini off;;set ez_FHT desired-temp 17.0</nowiki>
<nowiki>define wakeup at *07:00 {\
{Log 3, ('wakeupLOG WE: '.$we)}\
{Log 3, ('wakeupLOG HomeStatus: '.(Value("HomeStatus")))}\
if ((!$we) '''and (Value("HomeStatus") < 3''') {\
{fhem("define wakeup2 at +00:18:00 set sz_Stehlampe on") }\
{fhem("define wakeupOff at +00:45:00 set sz_Leselampe,sz_Stehlampe off") }\
{fhem("set sz_Leselampe dim100% 1280") }\
{Log 4, ("wakeupLOG: define wakeupOff at +00:45:00 set sz_Leselampe,sz_Stehlampe off")}\
}\
else {\
{Log 3, ("wakeupLOG: no wakeup today.")}\
}\
}</nowiki>
== Weitere Beispiele ==
[[Wakeuplight]]
[[Licht bei Bedingungen einschalten]]

Zeitschaltuhr

2013-05-10T20:54:58Z

Generix: Die Seite wurde neu angelegt: „== Anforderung == Eine Umwälzpumpe, die an einem FS20 Schalter hängt, soll zu bestimmten Tageszeiten alle 15 Minuten für jeweils 5 Minuten eingeschaltet wer…“

== Anforderung ==
Eine Umwälzpumpe, die an einem FS20 Schalter hängt, soll zu bestimmten Tageszeiten alle 15 Minuten für jeweils 5 Minuten eingeschaltet werden - mit unterschiedlichen Zeiträumen je Wochentag.

== Lösungsansatz 1 ==
Es wird der [http://fhem.de/commandref.html#at at-Befehl] verwendet.

Täglich zur gewünschten Startzeit wird geprüft, ob die Voraussetzungen erfüllt sind. Ist dies der Fall, wird die Pumpe n mal alle 15 Minuten für 5 Minuten eingeschaltet.
Die jeweilige Laufzeit der Pumpe wird durch on-for-timer in Sekunden angegeben (300 Sekunden).

* Täglich 17 Uhr bis 23 Uhr (6 Stunden = 24 Wiederholungen à 15 Minuten)
<nowiki>define PumpeAbendsStart at *17:00:00 {
{ fhem("define PumpeAbends at +*{24}00:15:00 set Umwaelzpumpe on-for-timer 300") }
}</nowiki>
* An Wochentagen 7 Uhr bis 9 Uhr (8 Wiederholungen), an Wochenenden 7 Uhr bis 17 Uhr (36 Wiederholungen)
<nowiki>define PumpeMorgensStart at *07:00:00 {
if (!$we) {
{ fhem("define PumpeMorgens at +*{8}00:15:00 set Umwaelzpumpe on-for-timer 300") }
}
else {
{ fhem("define PumpeMorgens at +*{36}00:15:00 set Umwaelzpumpe on-for-timer 300") }
}
}</nowiki>
== Lösungsansatz 2 ==
Es wird ein dauerhafter Prüflauf genutzt, der alle 15 Minuten prüft, ob der Zeitpunkt der Ausführung erreicht ist.

* An Wochentagen 7 Uhr bis 9 Uhr
<nowiki>define pumpe_wd78 at +*00:15 { fhem("set Umwaelzpumpe on-for-timer 300") if(!$we && $hour>=7 && $hour<9) }</nowiki>
== Weitere Beispiele ==
[http://fhemwiki.de/wiki/AT_zu_einem_absoluten_Datum_ausführen AT-Beispiele]

[http://fhemwiki.de/wiki/Wakeuplight Wakeup-Light]

Wochenende, Feiertage und Schulferien

2013-05-10T20:54:52Z

Generix: Die Seite wurde neu angelegt: „FHEM bietet mehrere Möglichkeiten, Komponenten in Abhängigkeit von Wochenenden, Feiertagen oder sogar Schulferien zu steuern. Eine simple Rollladensteuerung…“

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

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

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

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

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

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

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

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

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

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

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

Windows - CPU Temperatur und Co mit FHEM

2013-05-10T20:54:44Z

Generix: Die Seite wurde neu angelegt: „(von kleene 1503) Hier mal eine Möglichkeit, wie man auf Windows-Systemen die CPU-, HDD-, und andere Temperaturen / Systemdaten in FHEM anzeigen und grafisch…“

(von kleene 1503)

Hier mal eine Möglichkeit, wie man auf Windows-Systemen die CPU-,
HDD-, und andere Temperaturen / Systemdaten in FHEM anzeigen und
grafisch darstellen kann.

Voraussetzungen:
- Cygwin installiert
- SpeedFan installiert
- Einen WIRKLICH Unix fähigen Editor. Vergesst hierbei Wordpad und
Notepad!!! Ich nutze Proton (ist kostenlos und frei verfügbar). Bei
Proton müsst ihr UNBEDINGT darauf achten, dass ihr unter „Datei ->
Zeilenumbruchformat“ auf Unix umstellt. Sonst sucht ihr wie ich zwei
Wochen nach einem Fehler wo eigentlich gar keiner ist. Das Umstellen
unter Syntaxschema auf Unix Shell ist hilfreich aber kein muss.

Auf die Installation von Cygwin werde ich hier nicht eingehen. Dazu
gibt es genug im www.

Laufen tut das ganze bei mir auf Windows 7 Home Premium 64bit.
== Installiert Cygwin ==
== Installiert SpeedFan ==
- Um später Leerzeichen in den Pfadangaben zu vermeiden, habe ich nach
der Installation von SpeedFan einfach den kompletten
Installationsordner direkt nach C: kopiert. Im Klartext heißt das, aus
„C:\Programme (x86)\SpeedFan\“ wurde bei mir „C:\SpeedFan\“.

- SpeedFan selbst habe ich so eingerichtet, dass er mir das Logfile
MIT Header schreibt. Das Logfile von SpeedFan findet ihr direkt in dem
Installationsordner von SpeedFan.

== Script zum bearbeiten des SpeedFan Logfiles und speichern eines FHEM tauglichen Logfiles erstellen ==
- Die Logfiles von SpeedFan sind noch nicht FHEM tauglich. Also müssen
wir uns die Files mit Hilfe eines kleinen Scriptes in ein FHEM
taugliches Format umwandeln. Dieses Script sieht bei mir wie folgt
aus:

<nowiki>#!/bin/sh
date=`date +"%Y-%m-%d_%H:%M:%S"`
log="/cygdrive/c/fhem/tmp/system.log"
cat /cygdrive/c/SpeedFan/SFLog*.csv \
| grep "" \
| sed '/Seconds/d' \
| sed 's/[\t]/ /g' \
| sed 's/ \+/ /g' \
| sed '$!d' \
| sed "s/^/$date /" >> $log
#</nowiki>
Erklärung:

!/bin/sh <- sollte klar sein

date=`date +"%Y-%m-%d_%H:%M:%S"` <- sollte auch klar sein

log="/cygdrive/c/fhem/tmp/system.log" <- /cygdrive sagt unserem PC,
dass wir Cygwin nutzen (um es mal grob auszudrücken); /c/fhem/tmp/
system.log ist der Pfad wo unser fertiges und FHEM taugliches logfile
später gespeichert werden soll.

cat /cygdrive/c/SpeedFan/SFLog*.csv \ <- sagt unserem script, wo das
SpeedFan Logfile liegt welches wir bearbeiten wollen.

| grep "" \ <- liest das komplette SpeddFan Logfile ein.

| sed '/Seconds/d' \ <- Entfernt die komplette Zeile in der das Wort
Seconds vorkommt was in unserem Fall der Header des SpeedFan Logfiles
ist.

| sed 's/[\t]/ /g' \ <¬- Entfernt alle Tabs aus dem Speedfan Logfile.

| sed 's/ \+/ /g' \ <- Entfernt alle Leerzeichen aus dem SpeedFan
Logfile.

| sed '$!d' \ <- kopiert immer nur die letzte Zeile des SpeedFan
Logfiles und kopiert uns diese samt Datum mit

| sed "s/^/$date /" >> $log in unser FHEM taugliches Logfile.

Dieses Script speichert ihr nun als system.sh in eurem Cygwin Home
Ordner.

Übrigens: Wenn man sich mit dem "sed" Kommando auseinandersetzt, kann man so
auch Logfiles von anderen Windowsprogrammen zum Temperatur- und
Systemdaten auslesen wunderbar in ein FHEM taugliches Format bringen.

== .bat erstellen zum ausführen der .sh – Datei ==
- Erstellt euch eine .bat mit folgendem Inhalt:

<nowiki>@echo off</nowiki>
<nowiki>C:
chdir C:\cygwin\bin</nowiki>
<nowiki>bash --login -i ./system.sh</nowiki>
und speichert diese als system.bat in eurem fhem Ordner.

== Aufrufen der system.bat durch FHEM ==
- Erstellt in eurer fhem.cfg folgenden Eintrag:

<nowiki>define SystemDaten at +*00:02:00 { fhem `system`}</nowiki>
Dieser Eintrag startet alle 2 Minuten die Datei system.bat welche
wiederum das Script system.sh ausführt.

Wenn ihr es so wie ich gemacht habt, sollte nun innerhalb der nächsten
2 Minuten) in dem Ordner „C:\fhem\tmp\“ ein Logfile namens system.log
auftauchen welches alle nötigen Daten enthält und FHEM tauglich ist.

== Plot Datei erstellen ==
- Als Vorlage habe ich die Datei cpulog.gplot aus dem FHEM Ordner
genommen. Wichtig ist hier für uns der untere Teil ab set ylabel. Der
obere Teil kann bleiben wie er ist.

Wir müssen uns nun Überlegen, was wir uns anzeigen lassen wollen. In
diesem Fall nehmen wir mal die Temperaturen von Core 0 und Core 1.

Als erstes sehen wir uns noch einmal das SpeedFan Logfile an welches
bei mir folgendermasen aussieht:

Seconds HD0 Core 0 Core 1
71180 34.0 36.0 34.0

Core 0 und 1 ist also an 3. und 4. Stelle nach Seconds.

Nun sehe ich mir unser erstelltes system.log Logfile an:

2012-03-19_22:33:15 71180 34.0 36.0 34.0

Wir haben also vor dem Wert für Seconds noch das Datum und die Uhrzeit
und den Temperaturwert für Core 0 und 1 finden wir nun an der 4. und
5. Stelle. Wichtig ist, dass ihr Leerzeichen nicht mit zählt.

Gehen wir nun zurück zur Datei cpulog.gplot und Tragen folgendes ein:

<nowiki>set ylabel "Temperatur in C"
set y2label "Temperatur in C"</nowiki>
<nowiki>#FileLog 4::0:
#FileLog 5::0:</nowiki>
<nowiki>plot "<IN>" using 1:4 title 'Temperatur Core 0' with lines,\
"<IN>" using 1:5 title 'Temperatur Core 1' with lines</nowiki>

Erklärung:

set ylabel "Temperatur in C" <- Ist die linke, senkrechte Bezeichnung
des Plot-Fensters.

set y2label "Temperatur in C" <- Ist die rechte, senkrechte
Bezeichnung des Plot-Fensters.

FileLog 4::0: <- liest die 4 Stelle unseres Logfiles aus.

FileLog 5::0: <- liest die 5. Stelle unseres Logfiles aus.

plot "<IN>" using 1:4 <- zeigt die 4. Stelle unseres Logfiles im Plot-
Fenster.
title 'Temperatur Core 0' with lines <- Zeigt im Plot-Fenster den
Titel unserer Linie.

,\ <- Sagt FHEM das noch eine weitere Linie kommt.

Speichert dies nun Beispielsweise als core01.gplot

== Plot in FHEM anzeigen lassen ==
- Nun Tragen wir in unserer fhem.cfg folgendes ein:

define SystemLog FileLog C:/fhem/tmp/system.log SystemDaten
attr SystemLog logtype core01

define Sys weblink fileplot SystemLog:core01:CURRENT

Wenn alles geklappt hat, solltet ihr nun die Temperaturen grafisch in
FHEM dargestellt bekommen.

Ich übernehme keine Garantie. Kann nur sagen, dass es bei mir so
geklappt hat. Ich hoffe ich kann dem einen oder anderen damit helfen
oder wenigstens einen Denkanstoß geben.

Es gibt bestimmt noch elegantere Lösung allerdings habe ich für
Windows bis jetzt noch nichts gefunden.

(von kleene 1503)

Was ist der Hauscode?

2013-05-10T20:54:44Z

Generix: Die Seite wurde neu angelegt: „== Frage: == Verschiedentlich ist vom Hauscode die Rede, mal im Kontext FS20 und mal im Zusammenhang mit FHT. Ist das der selbe Hauscode? Wozu dient der Hausco…“

== Frage: ==
Verschiedentlich ist vom Hauscode die Rede, mal im Kontext FS20 und mal im Zusammenhang mit FHT.
Ist das der selbe Hauscode? Wozu dient der Hauscode?

== Antwort: ==
FS20-Hauscode und FHT-Hauscode aka "FHT-ID" ist *nicht* das Selbe.

Leider wurde und wird in FHEM Diskussionsgruppen, im Wiki und auch in der [[Commandref" class="mw-redirect]] einheitlich von FHTID gesprochen)

Wenn man also irgendwo im Zusammenhang mit FHEM "Hauscode" liest... erstmal innehalten und versuchen rauszubekommen, was in dem Moment gemeint ist: Hauscode des FS20 Adresssystems oder FHT-ID?

Bei ELV und Conrad ist mit "Hauscode" immer der FS20 Hauscode gemeint, da der normale ELV/Conrad Nutzer die FHT-ID nie zu Gesicht bekommt. Die FHT-ID ist in der Standalone Zentrale FHZ1000 fest einprogrammiert und muss nicht gesetzt werden.

Dem CUL/CUN (und ebenso den Zentralen FHZ1X00PC) aber muss man einen FHT-Hauscode (FHT-ID) zuweisen, sonst kann er sich nicht mit FHTs pairen, denn die default FHT-ID des CUL/CUN ist 0000 und das bedeutet soviel wie: "an FHT Kommunikation nicht teilnehmen".

Daher ist im Zusammenhang mit FHEM mit "Hauscode" oft die FHT-ID gemeint, wärend der FS20 Hauscode nur als Adressbestandteil der FS20 Geräte aufgefasst wird.

In CUL oder CUN muss man den Hauscode 1x einkonfigurieren (wird ins EPROM geschrieben), das macht man z.b. mit

<nowiki>set CUL raw T01abcd"</nowiki>
wobei abcd die FHT-ID (hex) ist und für CUL der Name des Remoten CUL/ CUNs eingesetzt werden muss.

Die FHT-ID kann frei gewählt werden. (Wertepaare von hex00-62, entsprechend dezimal 0-99) Hat man mehrere
CUN/CULs (oder RFR-CULs) müssen die FHT-ID unterscheidlich sein, um "Zuständigkeitskonflike" zu vermeiden.
Siehe auch [[FHT mit RFR CUL pairen]]

Eine FHT-ID muss man dem CUL/CUN also nur zuweisen, wenn man FHTs pairen will.

Der tatsächliche FS20 Hauscode hingegen sieht anders aus und wird auch nur bei der Definition der Devices angegeben.
Das sieht dann z.B. so aus:

<nowiki>define Licht1_Bad FS20 11112244 34</nowiki>
wobei hier "11112244" der FS20 Hauscode in ELV Notation ist.
(FHEM beherrscht die Angabe des Hauscodes in ELV Notation und Hexadezimal. Die Verwendung der ELV Notation auch in FHEM hat den Vorteil, dass die erforderlichen Tastendrücke sofort ablesbar sind und sich so bei der Nachprogrammierung von Geräten weniger leicht Fehler einschleichen.)

Tatsächlich wird NUR dieser Teil in den ELV und Conrad (etc.) Handbüchern je "Hauscode" genannt.
Faktisch ist das aber nur ein Bestandteil des Adressraumes der FS20 Geräte.
Im Gegensatz zu z.b. einer [[FHZ1000" class="mw-redirect]], wo der FS20 Hauscode eingegeben
werden muss und dann für alle gesteuerten Geräte gleich sein muss, ist es im Umfeld FHEM mit CUL/CUN egal, welche Hauscodes verwendet werden.
Man kann also z.b. sowas machen:

<nowiki>define Licht1_Bad FS20 11112244 34
define Licht2_Bad FS20 11112242 34</nowiki>
also Schalter im selben Raum nicht durch eine andere Adresse, sondern durch einen anderen Hauscode unterscheiden.
In der Ideenwelt von ELV ist es vorgesehen, dass Aktoren andere Adressen, aber innerhalb einer Zentrale einen Hauscode haben. Zwingend ist das aber nicht. Vielmehr ist der Hauscode eigentlich einfach nur eine Bestandteil des Adressraumes, den man frei verwenden kann um Devices zu adressieren.

Dabei geht allerdings die Funktionalität der Masteradresse verloren, die nur innerhalb eines Hauscodes wirkt.
Im Zusammenhang mit FHEM ist eine "Masterschalter" (ALLE Lichter mit einem Befehl aus) aber leicht zu realisieren, sodass dieser Nachteil weniger bedeutend ist.

Vielfach wird der Hauscode aber dennoch als ordnendes Element verwendet, als z.b. alle Lichtschalter und Aktoren mit einem Hauscode, alle Beweggungsmelder mit einem anderen Hauscode.

==== siehe auch ====
* <nowiki>[[FHT-ID der FHZ1300 herausfinden]] </nowiki>
* <nowiki>[[FS20 Allgemein]] </nowiki>

Wakeuplight

2013-05-10T20:54:41Z

Generix: Die Seite wurde neu angelegt: „Set up a wakeup light which will slowly dim-up a lamp, e.g. at your bedside, and will switch it off again after a certain time. The solution requires a dimmer …“

Set up a wakeup light which will slowly dim-up a lamp, e.g. at your bedside, and will switch it off again after a certain time.
The solution requires a dimmer hardware device, e.g. FS20-di. In the example below the dimmer is named Lamp1.

== Code ==
<nowiki>define wakeup at *07:00:00 {\
if (!$we) {\
{fhem("set Lamp1 dim100% 1280") }\
{fhem("define wakeupOff at +00:40:00 set Lamp1 off") }\
}\
}</nowiki>
Explanation:

The time indicated for wakeup (here: 7am) is the starting-time of the dim-procedure. The asterisk indicates this procedure shall be executed every day.

The program uses the variable $we (weekend), so your wakeuplight will only turn on on weekdays. If you implement holiday2we, the wakeuplight will also remain off on holidays.

The set-command 'dim100% 1280' will dim the lamp to 100% over a timespan of 1280 seconds, i.e. 21 minutes.

Finally, the off-command is scheduled for 40 minutes from wakeuptime.

== Change of wakeuptime ==
To change the wakeuptime to e.g. 8am, type the following into the input-field on the fhem-frontend:

<nowiki>modify wakeup *08:00:00</nowiki>

== Change of wakeuptime using sliders ==
Setting the wakeuptime using the "modify wakeup" command is inconvenient. Especially forgetting to set the asterisk (*) is a pain, as the wakeup-definition will disappear after next execution.
To avoid this pitfall, there is an option to add an additional pseudo-device which offers sliders to set the wakeup time:

<nowiki>define wakeupChange dummy
attr wakeupChange setList state:time
attr wakeupChange webCmd state
define n_wakeupChange notify wakeupChange {fhem("modify wakeup *%");;}</nowiki>

Explanation: A dummy device wakeupChange is defined. It carries sliders to select the wakeuptime. Subsequently, a notify is defined, which gets triggered whenever a time is selected using the sliders. This chosen time is then used to execute the 'modify wakeup'-command for the actual wakeup-device.

VoIP to FHEM

2013-05-10T20:54:41Z

Generix: Die Seite wurde neu angelegt: „= VoIP2FHEM or HOWTO control the FHEM with Asterisk = == Description == This is a HOWTO about the use of a VoIP-DECT-Telephone (or every phone of a fritzbox) a…“

= VoIP2FHEM or HOWTO control the FHEM with Asterisk =
== Description ==
This is a HOWTO about the use of a VoIP-DECT-Telephone (or every phone of a fritzbox) as a remote controller for the FHEM-Devices.
The provided scripts are under the GPL.

The Goal is

* Switching the FS20-Devices
* text2speach, the Telephone reads e.g. the measured-temp
* Possibility to start scripts with the Remote Telephone
* AND EVERYTHING SHOULD RUN ON THE NSLU2 (or other small machines):-)
== Technical Overview ==
On the NLSU2 (or every other Linux Box) runs an Asterisk. This machine needs not to be the machine with the FHEM. I bought the Voip-DECT-Telephone Siemens Gigaset C470 IP (80.-EUR). It has a nice Webinterface and it is possible to read in a self made telephone book. If you have a Fritzbox you do not need such special devices (see below).

The Asterisk calls depending on the dialed number a bash skript. After that Asterisk plays two soundfiles < text >< value > in a loop.

The NSLU2 is a weak machine. It always only creates a soundfile 1x and then stores it on the harddisk. A set of prebuild voices (e.g. digits from -20 to 90) are included. Some scripts for creating soundfiles and automatically the telephone book are provided too.

== Installation ==
Go to [http://fhem.dnsalias.net/voip2fhem [1]] and download the files.

* Install with your package manager asterisk, sox, espeak, libsox-fmt-gsm. On Debian based Machines: "apt-get install asterisk sox espeak libsox-fmt-gsm"

Debian: activate asterisk in the /etc/default/asterisk

* copy the scripts voip2fhem voip2fhem_create_telefonlist voip2fhem_create_txt2gsm to /usr/local/bin/ and be shure that they are executable (chmod +x /usr/local/bin/voip2fhem*)
* extract the prepared voices "tar -xvzf voip2fhem_voices.tar.gz -C /" and give the correct rights "chown -R asterisk.asterisk /var/tmp/voip2fhem"
* cp extensions.conf and sip.conf to /etc/asterisk/ and edit these files and the bash script /usr/local/bin/voip2fhem
* restart/reload asterisk (/etc/init.d/asterisk restart or asterisk -r and then "extensions reload" and "sip reload")
== Example extensions.conf ==
this is an example of an extensions.conf

<nowiki>[FHEM]
; after every change of this file make "asterisk -r" and then "extensions reload"
exten => 3001,1,Answer()
exten => 3001,2,System(/usr/local/bin/voip2fhem ks300 "Aussentemperatur ." KS300)
exten => 3001,3,Playback(/tmp/asterisk1)
exten => 3001,n,Playback(/tmp/asterisk2)
exten => 3001,n,Wait(3)
exten => 3001,n,Goto(3)
exten => 3002,1,Answer()
exten => 3002,2,System(/usr/local/bin/voip2fhem kesselu "Kesseltemperatur kesselu ." HMS100)
exten => 3002,3,Playback(/tmp/asterisk1)
exten => 3002,4,Playback(/tmp/asterisk2)
exten => 3002,n,Wait(3)
exten => 3002,n,Goto(3)
exten => 3003,1,Answer()
exten => 3003,2,System(/usr/local/bin/voip2fhem wz "Wohnzimmertemperatur ." FHT)
exten => 3003,3,Playback(/tmp/asterisk1)
exten => 3003,4,Playback(/tmp/asterisk2)
exten => 3003,n,Wait(3)
exten => 3003,n,Goto(3)
exten => 3004,1,Answer()
exten => 3004,2,System(/usr/local/bin/voip2fhem nachto "Nachtlicht oben" FS20)
exten => 3004,3,Playback(/tmp/asterisk1)
exten => 3004,n,Wait(3)
exten => 3004,n,Goto(3)
exten => 3005,1,Answer()
exten => 3005,2,System(/usr/local/bin/voip2fhem stuwz1 "Fernsehlicht" FS20)
exten => 3005,3,Playback(/tmp/asterisk1)
exten => 3005,n,Wait(3)
exten => 3005,n,Goto(3)
exten => 3006,1,Answer()
exten => 3006,2,System(/usr/local/bin/voip2fhem ofen "Status Ofen ." FS20STATE)
exten => 3006,3,Playback(/tmp/asterisk1)
exten => 3006,n,Playback(/tmp/asterisk2)
exten => 3006,n,Wait(3)
exten => 3006,n,Goto(3)</nowiki>
== Example sip.conf ==
this is an example of a sip.conf

<nowiki>[general]
context=FHEM
port=5060
bindaddr=0.0.0.0

; FHEM: VoIP-Telephone with the Name/Number 2000 and the password 1234
[2000]
type=friend
context=FHEM
secret=1234
host=dynamic</nowiki>

== Alternative use of the Fritzbox ==
If you have a Fritzbox you can register your Asterisk there. After that you can use every telephone, which is registered on the Fritzbox. In this case you do not need further devices like a special VOIP-Device.

Go to something like "Internettelefonie" and register Asterisk. The Registrar is the IP-Address of the Asterisk-Box. The Calling-Number is the internal number like 2000 in this example. User name (2000) and password (1234) are from the sip.conf:

<nowiki>##############
; Example:
; FHEM: VoIP-Telephone with the Name/Number 2000 and the password 1234
[2000]
type=friend
context=FHEM
secret=1234
host=dynamic</nowiki>

The Fritzbox will give you a short number (e.g. *123#) -- after that you can call your skripts with '''*123#3001#'''with every telephone of your Fritzbox.

== Hints ==
* if there isn't the required soundfile then the NSLU2 creates it. This needs on this weak machine minutes (example: the word "asterisk" needs 3 min). voip2fhem stores this file and the next time it will be used.
* Use the script voip2fhem_create_txt2gsm on a faster machine to create the sounds. Usage: voip2fhem_create_txt2gsm "I love FHEM". The soundfile is then automatically copied to /var/tmp/voip2fhem/
* it is also possible to connect the ASTERISK with the rest of the world (e.g. Sipgate, 1und1) :-)
* for debug asterisk: "asterisk -r", "sip debug"

Velux KUX 100

2013-05-10T20:54:33Z

Generix: Die Seite wurde neu angelegt: „Einbindung von Velux io-homecontrol Rollos (Velux KUX 100) lässt sich ohne Weiteres nicht mit FHEM erreichen. Bei mir habe ich folgende Lösung in der Umsetz…“

Einbindung von Velux io-homecontrol Rollos (Velux KUX 100) lässt sich ohne Weiteres nicht mit FHEM erreichen.

Bei mir habe ich folgende Lösung in der Umsetzung:
Die originalen Handsender der KUX100 werden zerlegt. Die 3 Kontakte für Auf - Stop - Ab werden mit 3 Relais verbunden.
Die Relais wiederum werden von einem FS20 SM8 Modul geschaltet.

Die notwendigen Auslöseschritte für das Auf - Ab Schalten der Relais werden dann in einem neuen FS20 Dummy Device zusammengefasst.

Anbei der Code aus meiner Fhem.cfg für 1 Rollo.

Update 04-Mai-2012:
Die 50% Auf und Ab Lösung mit Verwendung der Sleep Funktion bereitete einige Probleme, daher hier eine angepasste Version mit "Notify at" anstatt Sleep, um die Rollo Auf/Ab Bewegung nach einer definierten Zeit zu stoppen.

Der Aufruf mehrerer Verketter Rollo Auf Aufrufe funktioniert dann auch wieder (war mit Sleep schwierig).

<nowiki># ---------- START Definition Schlafzimmer_Oben_Nord ROLLLADEN -------------
# Definition Schalter AUF Adresse vom FS20 SM8 - Kanal1 / Über Relais den "Auf" Schalter der OriginalFernbedienung schalten
define RS_SZO_N_Auf FS20 ab01 00
attr RS_SZO_N_Auf IODev CUNO_O
attr RS_SZO_N_Auf model fs20
attr RS_SZO_N_Auf room 5_SYSTEM
# Definition Schalter AB Adresse vom FS20 SM8 - Kanal2 / Über Relais den "Ab" Schalter der OriginalFernbedienung schalten
define RS_SZO_N_Ab FS20 ab02 00
attr RS_SZO_N_Ab IODev CUNO_O
attr RS_SZO_N_Ab model fs20
attr RS_SZO_N_Ab room 5_SYSTEM
# Definition Schalter STOP Adresse vom FS20 SM8 - Kanal3 / Über Relais den "Stop" Schalter der OriginalFernbedienung schalten
define RS_SZO_N_Stop FS20 ab03 00
attr RS_SZO_N_Stop IODev CUNO_O
attr RS_SZO_N_Stop model fs20
attr RS_SZO_N_Stop room 5_SYSTEM
# Definition eines Dummy FS20 der im entsprechenden Raum (OG) angezeigt wird, und die Schaltvorgänge triggert
#define Rollo_SchlafZ_O_N FS20 f1f1 00
define Rollo_SchlafZ_O_N dummy
attr Rollo_SchlafZ_O_N eventMap /on:Ab/off:Auf/dim06%:Ab50/dim93%:Auf50/
attr Rollo_SchlafZ_O_N room 2_ROLLLADEN
attr Rollo_SchlafZ_O_N webCmd Ab:Auf:Ab50:Auf50
#Rollo AB 100% - AB Taste 1 Sekunde auslösen
define RSZO_N_Ab notify Rollo_SchlafZ_O_N.Ab set RS_SZO_N_Ab on-for-timer 1
attr RSZO_N_Ab room 5_SYSTEM
#Rollo AUF 100% - AUF Taste 1 Sekunde auslösen
define RSZO_N_Auf notify Rollo_SchlafZ_O_N.Auf set RS_SZO_N_Auf on-for-timer 1
attr RSZO_N_Auf room 5_SYSTEM
#Rollo AB50% - 15 Sekunden Rolladen Abwärts - ggf. die Sleep Zeit anpassen
define RSZO_N_Ab50 notify Rollo_SchlafZ_O_N.Ab50 {\
fhem "set RS_SZO_N_Ab on-for-timer 1";;\
fhem "define Rollo_SZO_N_Stop at +*{1}00:00:41 set RS_SZO_N_Stop on-for-timer 1";;\
fhem "attr Rollo_SZO_N_Stop room 5_SYSTEM";;\
}
attr RSZO_N_Ab50 room 5_SYSTEM
#Rollo AUF50% - 15 Sekunden Rolladen Aufwärts - ggf. die Sleep Zeit anpassen
define RSZO_N_Auf50 notify Rollo_SchlafZ_O_N.Auf50 {\
fhem "set RS_SZO_N_Auf on-for-timer 1";;\
fhem "define Rollo_SZO_N_Stop at +*{1}00:00:30 set RS_SZO_N_Stop on-for-timer 1";;\
fhem "attr Rollo_SZO_N_Stop room 5_SYSTEM";;\
}
attr RSZO_N_Auf50 room 5_SYSTEM
# ---------- ENDE Definition Schlafzimmer_Oben_Nord ROLLLADEN -------------
# ---------- Routine um mehrere Rollos zeitversetzt nach Sunrise / Sunset Notify zu steuern (um SM8 Befehle zeitlich zu entspannen).
define Rollladen_OG_Morgens_Auf at *{sunrise(-210,'05:30','08:00')} {\
fhem "set Rollo_ArbeitsZ Auf50%";;\
fhem "define Rollladen_OG_Morgens_Timer_N at +*{1}00:00:30 set Rollo_SchlafZ_O_N Auf50";;\
fhem "attr Rollladen_OG_Morgens_Timer_N room 5_SYSTEM";;\
fhem "define Rollladen_OG_Morgens_Timer_SL at +*{1}00:01:00 set Rollo_SchlafZ_O_SL Auf50";;\
fhem "attr Rollladen_OG_Morgens_Timer_SL room 5_SYSTEM";;\
fhem "define Rollladen_OG_Morgens_Timer_SR at +*{1}00:01:30 set Rollo_SchlafZ_O_SR Auf50";;\
fhem "attr Rollladen_OG_Morgens_Timer_SR room 5_SYSTEM";;\
}
attr Rollladen_OG_Morgens_Auf room 2_ROLLLADEN
define Rollladen_OG_Abends_Ab at *{sunset(330,'19:00','22:00')} {\
fhem "set Rollo_ArbeitsZ Ab";;\
fhem "define Rollladen_OG_Morgens_Timer_N at +*{1}00:00:30 set Rollo_SchlafZ_O_N Ab";;\
fhem "attr Rollladen_OG_Morgens_Timer_N room 5_SYSTEM";;\
fhem "define Rollladen_OG_Morgens_Timer_SL at +*{1}00:01:00 set Rollo_SchlafZ_O_SL Ab";;\
fhem "attr Rollladen_OG_Morgens_TimerSL room 5_SYSTEM";;\
fhem "define Rollladen_OG_Morgens_Timer_SR at +*{1}00:01:30 set Rollo_SchlafZ_O_SR Ab";;\
fhem "attr Rollladen_OG_Morgens_Timer_SR room 5_SYSTEM";;\
}
attr Rollladen_OG_Abends_Ab room 2_ROLLLADEN</nowiki>

Ultraschallsensor für Heizöltank mit USF1000 Emulation

2013-05-10T20:54:32Z

Generix: Die Seite wurde neu angelegt: „alt=Heizölmessung 1.JPG '''Als Sensor wollte ich ursprünglic…“

[[File:/w/images/4/4d/Heiz%C3%B6lmessung_1.JPG|960px|link=/wiki/Datei:Heiz%C3%B6lmessung_1.JPG|alt=Heizölmessung 1.JPG]]
'''Als Sensor wollte ich ursprünglich den Ultraschallsensor SRF01 verwenden.'''
'''Dazu hatte mir Maz Rashid seinen Sourcecode für den SRF02 mit CC1101-Processor-Module (CPM) bereitgestellt.'''
'''Nachdem ich aber den Heizölstand messen wollte, habe ich dann doch lieber einen wasserresistenten Sensor der Schutzart IP-67 ausgewählt. '''

'''Zudem habe ich anstatt des abgekündigten CPM Modules, das neue CSM Modul von Busware verwendet.'''
'''Dazu gibt es eine Superinfo. Einfach bei der Bestellung des CSM Moduls die Verwendung als Heizölstandmesser angeben. '''
'''Dann wird das CSM schon richtig programmiert geliefert und keiner muss sich um einen Programmieradapter sorgen.'''
[[File:/w/images/d/d4/Heiz%C3%B6lmessung_2.JPG|960px|link=/wiki/Datei:Heiz%C3%B6lmessung_2.JPG|alt=Heizölmessung 2.JPG]]
--<a href="/w/index.php?title=Benutzer:Caesar_2&action=edit&redlink=1" class="new" title="Benutzer:Caesar 2 (Seite nicht vorhanden)">Caesar 2</a> (<a href="/w/index.php?title=Benutzer_Diskussion:Caesar_2&action=edit&redlink=1" class="new" title="Benutzer Diskussion:Caesar 2 (Seite nicht vorhanden)">Diskussion</a>) 23:17, 5. Sep. 2012 (CEST)

Ultraschallsensor

2013-05-10T20:54:31Z

Generix: Die Seite wurde neu angelegt: „alt=SRF06 Ansicht fertig bestückte Platine (Bild robot-electronics.co.uk) = Analog = Bei […“

[[File:/w/images/d/db/Srf06.jpg|300px|link=/wiki/Datei:Srf06.jpg|alt=]]SRF06 Ansicht fertig bestückte Platine (Bild robot-electronics.co.uk)

= Analog =
Bei [http://www.robot-electronics.co.uk/acatalog/Ultrasonic_Rangers.html SRF06 - 4-20mA Current Loop Ultrasonic Range Finder]
Dieser stellt je nach Messweite einen Ausgangsstrom von 4-20mA bereit. Mittels A/D Wandler (1wire, zb. DS2438) kann das Signal bequem eingelesen werden.
Deutsche Distributoren sind zb:

[http://www.exp-tech.de/Sensoren/SRF06-4-20mA-Current-Loop-Ultrasonic-Ranger-Finder.html http://www.exp-tech.de/Sensoren/SRF06-4-20mA-Current-Loop-Ultrasonic-Ranger-Finder.html]

[http://de.manu-systems.com/SRF06.shtml http://de.manu-systems.com/SRF06.shtml]

[http://www.lipoly.de/index.php?main_page=product_info&cPath=880_2631_2632&products_id=161191 http://www.lipoly.de/index.php?main_page=product_info&cPath=880_2631_2632&products_id=161191]

[http://nodna.de/Devantech-SRF06-Current-Loop-Ultraschall-Sensor http://nodna.de/Devantech-SRF06-Current-Loop-Ultraschall-Sensor]

nach folgendem Plan wird der Sensor an einen A/D Wandler angeschlossen, das originale Manual ist [http://www.robot-electronics.co.uk/htm/srf06tech.htm hier] nachzulesen.

[[File:/w/images/e/e7/Srf06_connect.gif|460px|link=/wiki/Datei:Srf06_connect.gif|alt=SRF06 Beschaltungsplan (Bild robot-electronics.co.uk)]]

= Digital =
Bei [http://www.pollin.de/shop/dt/MTQ5OTgxOTk-/Bausaetze_Module/Bausaetze/Bausatz_AVR_NET_IO.html">[4]</a>) über Ethersex/<a href="/wiki/ECMD" title="ECMD ECMD] zur Ansteuerung eines Magnetventils der Nachspeisung schalten. Damit soll ein Trockenlaufen der Pumpe vermieden werden und auch in Trockenzeiten Wasser über die Brauchwasserleitung zur Verfügung stehen.

Das Protokoll ist ziemlich einfach (5 Ziffern im Abstand von ca. 100 ms senden und die Ausgabe des Sensors seriell einlesen), sodass eine Verarbeitung mit Fhem, Nagios/Icinga oder Cacti jederzeit möglich ist.

Durch den (Mindest-)Abstand von 100 ms zwischen den Zeichen verbietet sich der Einsatz von ECMD, da dieses Modul die Zeichen immer mit der vollen Baudrate sendet und bisher kein "Pausenzeichen" (delay) dort möglich ist.

Deshalb habe ich ein kleines (aber nicht sehr elegantes) Pearl-Skript für die serielle Schnittstelle geschrieben, welches momentan zwar im Verzeichnis /usr/share/fhem/FHEM/ liegt, aber noch nicht in FHEM eingebunden ist. Ich verwende dieses aber bereits für das [[Statusdisplay" class="mw-redirect]].

<nowiki>#!/usr/bin/perl
#
# Ultrasonic sensor value retrieval using Mini3-Sensor from icplan.de
# Copyright (C) 2011 Jens Wagner
#
# This program is free software: you can redistribute it and/or modify
# it under the terms of the GNU General Public License as published by
# the Free Software Foundation, either version 3 of the License, or
# (at your option) any later version.
#
# This program is distributed in the hope that it will be useful,
# but WITHOUT ANY WARRANTY; without even the implied warranty of
# MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
# GNU General Public License for more details.
#
# You should have received a copy of the GNU General Public License
# along with this program. If not, see <[http://www.gnu.org/licenses/ http://www.gnu.org/licenses/]>.
#
#
use strict;
use Device::SerialPort;
#
my $seriel = Device::SerialPort->new('/dev/ttyS1') || die "Kann /dev/ttyS1 nicht öffnen! ($!)\n";
#
$seriel->baudrate(9600);
$seriel->parity("none");
$seriel->databits(8);
$seriel->stopbits(1);
#
print "Entfernung Sensor 1: ";
#
$seriel->write('1');
select(undef, undef, undef, 0.2);
$seriel->write('2');
select(undef, undef, undef, 0.2);
$seriel->write('0');
select(undef, undef, undef, 0.2);
$seriel->write('0');
select(undef, undef, undef, 0.2);
$seriel->write('0');
#
#
$|=1;
my $exit=0;
while($exit < 2000)
{
my ($cin, $sin) = $seriel->read(1);
if($cin)
{
print $sin;
$exit=0;
}
else
{$exit++}
}
print "\n";
#
exit(0);</nowiki>
Verwendet man an Stelle der Zeichenfolge '1 2 0 0 0' die Zeichenfolge '1 1 0 0 0' bekommt man die Temperatur des Sensors angezeigt.

Das Skript muss zwingend verbessert werden, da derzeit nur der Abstand in cm zum Wasserspiegel ausgegeben wird und nicht das enthaltene Volumen. Hierzu braucht man entweder (da meist liegende Zylinder oder Kugeln zum Einsatz kommen) etwas Mathematik oder man nutzt eine Tabelle in Form einer CSV-Datei. Ich habe bereits letzteres in Vorbereitung aber noch nicht in das Skript eingebaut.

-- wird fortgesetzt
--<a href="/w/index.php?title=Benutzer:Mick&action=edit&redlink=1" class="new" title="Benutzer:Mick (Seite nicht vorhanden)">Mick</a> 00:03, 21. Jan. 2012 (CET)

Uhr auf FHEM-Seite

2013-05-10T20:54:30Z

Generix: Die Seite wurde neu angelegt: „Das "lächelnde Haus" ist natürlich das FHEM-Logo. Doch könnte es ja sein, dass eine eher nüchterne Seitendarstellung gewünscht ist, etwa, indem dort eine …“

Das "lächelnde Haus" ist natürlich das FHEM-Logo. Doch könnte es ja sein, dass eine eher nüchterne Seitendarstellung gewünscht ist, etwa, indem dort eine sekundengenaue Uhr eingeblendet wird.

Dazu sind - bei Verwendung von pgm2 - folgende Schritte vorzunehmen.

'''1.Modifikation der Datei svg.js'''Ans Ende wird der folgende Code gestellt:

<nowiki>function GetClock(){
d = new Date();
nhour = d.getHours();
nmin = d.getMinutes();
if(nmin <= 9){nmin="0"+nmin}
document.getElementById('logo').innerHTML=nhour+":"+nmin;
setTimeout("GetClock()", 1000);
}
window.onload=GetClock;</nowiki>
Selbstverständlich könnte man die Anzeige auf Sekunden ausdehnen, oder noch etwas komplizierter gestalten - der obige Code soll nur als Beispiel dienen. Auch erfolgt die Abfrage hier alle 1000 Millisekunden - das kann man bei reduziertern Genauigkeitsanforderungen auch heraufsetzen.

'''2. Modifikation der Datei style.css'''(bzw. von <xxx>style.css, wenn man einen anderen als den Default-Style verwendet)

Der Selektor für den Bereich des Logos wird ausgetauscht gegen:

<nowiki>#logo { position:fixed; top:30px; left:20px;
width:100px; height:105px; text-align:center;
font-family:Times-Roman; font-size:xx-large; font-weight:bold;
}</nowiki>
Selbstverständlich kann man hier noch verschiedene eigene Attribute einbauen, etwa die Farbe und Schriftgröße an eigene Wünsche anpassen.

Tuxradio 2

2013-05-10T20:54:30Z

Generix: Die Seite wurde neu angelegt: „== Hardware == Das 8,5 x 5,5 cm große TuxRadio Version 2 der Firma [http://busware.de/tiki-index.php?page=TuxRadio">busware.de</a> ist der Nachfolger des <a h…“

== Hardware ==
Das 8,5 x 5,5 cm große TuxRadio Version 2 der Firma [http://busware.de/tiki-index.php?page=TuxRadio">busware.de</a> ist der Nachfolger des <a href="/wiki/TuxRadio" title="TuxRadio TuxRadio] und kommt in einem Alugehäuse mit einem minimalen Debian-Betriebssystem daher,
welches auf einer microSDHC-Karte vorinstalliert ist. Verbaut sind ein ARM9 Chip mit 450MHz, 64MB Arbeitsspeicher, ein USB Host, ein CSM 868MHz Radio Modul, ein 10/100MBit LAN
Anschluss sowie sechs LED von denen vier frei programmiert werden können. Der Stromverbrauch liegt laut Hersteller bei ca. 2 Watt.

== TuxRadio Startup ==
Die Verbindung zum Router wird über den Lan Anschluss hergestellt.
Beim ersten booten werden ggf. neue SSH Schlüssel generiert, daher kann dieser Bootvorgang etwas Zeit beanspruchen.

Um auf TuxRadio zugreifen zu können benötigt man auf seinem Computer einen SSH-Clienten.
Verschiedene dazu geeignete SSH-Clienten findet man für die verschiedenen Betriebssysteme unter [http://www.fhemwiki.de/wiki/Kommandozeilentools Kategorien/Software/Komandozeilentools] erklärt.
Bei dem gestarteten SSH-Clienten wählt man "verbinden", in dem geöffneten Fenster SSH, als Rechner gibt man die vom Router zugewiesene IP-Adresse von TuxRadio ein (Erkennbar ist das TuxRadio ggf. an der MAC-Adresse die mit A4:50:55... beginnt).
Benutzername ist "root" das Passwort lautet "busware" und sollte als erstes geändert werden:

<nowiki>passwd root</nowiki>
Jetzt wird man zweimal zur Eingabe des neuen Passwortes aufgefordert. Ist beide Male das Passwort korrekt eingegeben worden, wird die erfolgreiche Änderung bestätigt.

Danach sollte eine Aktualisierung des Systems mit folgenden Befehlen durchgeführt werden.

<nowiki>apt-get update
apt-get upgrade</nowiki>
Aktualisierungen sollten regelmäßig durchgeführt werden, um immer auf dem aktuellen Stand zu sein.

== Fhem aufrufen ==
Fhem ist bereits vorinstalliert und der integrierte CUL versieht auch schon seinen Dienst,
über den Browser kann mit '''http://<IP-Adresse_von_TuxRadio>:8083/fhem'''auf die Bedienoberfläche von fhem zugegriffen werden.
Ein "updatefhem" ist zu empfehlen, um mit der neuesten Version arbeiten zu können.

Folgende Pfade werden standardmäßig genutzt:

<table class="wikitable toptextcells">
<tr>
<th> Inhalt
</th>
<th> Pfad
</th></tr>
<tr>
<td> LogFiles </td>
<td> /var/log/fhem
</td></tr>
<tr>
<td> Programm </td>
<td> /usr/share/fhem
</td></tr>
<tr>
<td> fhem.cfg </td>
<td> /etc/
</td></tr>
</table>
Falls Fhem mit "shutdown" beendet wurde lässt es sich wie folgt von der Shell aus starten:

<nowiki>/etc/init.d/fhem start</nowiki>
Beenden:

<nowiki>/etc/init.d/fhem stop</nowiki>
Status:

<nowiki>/etc/init.d/fhem status</nowiki>
== LED ==
Die vier LED an der Vorderseite lassen sich frei programmieren, im Auslieferungszustand zeigt die
obere linke LED einen Heartbeat an und die darunter liegende LED zeigt Lese-/Schreibvorgänge auf der SD-Karte an.

Beispiel obere rechte LED anschalten:

<nowiki>echo 1 > /sys/class/leds/ro:green/brightness</nowiki>
Beispiel obere rechte LED ausschalten:

<nowiki>echo 0 > /sys/class/leds/ro:green/brightness</nowiki>
Die LED sind wie folgt benannt:
lo:green ro:green
lu:orange ru:orange

== RFXtrx433 ==
Soll der RFXtrx433 der Firma [http://www.rfxcom.com/transceivers.htm RFXCOM] mit TuxRadio V2 verwendet werden ist wie folgt vorzugehen:

in der Datei /etc/modules ist eine neue Zeile hinzuzufügen damit der Treiber beim booten geladen wird:

<nowiki>ftdi_sio</nowiki>
Damit der Name des USB-Gerätes bei jedem ein und ausstecken identisch bleibt sollte eine Datei in
/etc/udev/rules.d angelegt werden z.B. 10-udev.rules die folgenden Inhalt hat:

<nowiki>ATTRS{product}=="RFXtrx443", ATTRS{manufacturer}=="RFXCOM", SYMLINK+="usbRFX"</nowiki>
Nach einem reboot <nowiki>shutdown -r now</nowiki>
und der entsprechenden Konfiguration von Fhem sollte der RFXtrx nun Daten melden. Sollte im Logfile "Permission denied" auftauchen, so ist die Berechtigung
des USB Devices so zu ändern, dass der Benutzer FHEM darauf Zugriff hat.

== E-Mail Konfiguration ==
Empfehlenswert ist die Einrichtung einer E-Mailfunktionalität z.B. mittels Exim4:

Installation:

<nowiki>aptitude install exim4</nowiki>
Konfiguration:

<nowiki>dpkg-reconfigure exim4-config</nowiki>
Exim4 wird typischerweise mit der Einstellung "smarthost" konfiguriert, entsprechende Beispiele
finden sich bei Google mit den Suchwörtern: debian exim4 smarthost gmail (oder GMX etc...)

Testen:

<nowiki>echo "test nachrichtentext" | mail -s "test betreff" myusername@myAnbieter.com</nowiki>
Logfile zur Fehleranalyse:

<nowiki>tail /var/log/exim4/mainlog</nowiki>
Anzeigen ob Mails nicht versendet werden konnten:

<nowiki>mailq</nowiki>
Alle frozen Mails löschen:

<nowiki>mailq | awk '/frozen/{print "exim4 -Mrm "$3}' | /bin/sh</nowiki>
== Weblinks ==
* <nowiki>[http://busware.de/tiki-index.php?page=TuxRadio2_Installation Busware Tiki]</nowiki> (Information des Herstellers zur Installation, Version vom 08. Oktober 2012, abgerufen 09. Oktober 2012)
* <nowiki>[http://www.tickerverbot.de/tuxradio-mit-fhem-neu-aufsetzen HowTo zum Neuaufsetzen des Tuxradio 2 FHEM-Systems]</nowiki>

SYSSTAT

2013-05-10T20:54:27Z

Generix: Die Seite wurde neu angelegt: „'''FHEM-Modul sysstat''' = Vorbemerkungen = Seit dem 06.02.2013 gibt es ein neues und offizielles FHEM-Modul namens ''sysstat''. Es ermöglicht das Logging und…“

'''FHEM-Modul sysstat'''
= Vorbemerkungen =
Seit dem 06.02.2013 gibt es ein neues und offizielles FHEM-Modul namens ''sysstat''. Es ermöglicht das Logging und die (grafische) Anzeige der Auslastung (load) ihres '''Linux'''-Systems, auf dem FHEM läuft. Daneben ermöglicht es auch die gleichen Auswertungsmöglichkeiten für die Belegung (in Bytes oder Prozent) einer von Ihnen anzugebenden Festplatten-Partition. Gleiches kann auch mit einem Remote-System durchgeführt werden (per SSH mittels Key).

Weitere Informationen zum Modul und zur Syntax finden Sie in der [http://fhem.de/commandref.html#SYSSTAT commandref].

= Beispiel =
Die Definitionen und Eigenschaften (Attribute) müssen von Hand in der ''fhem.cfg''eingetragen werden, da hier der ''autocreate''-Mechanismus nicht greift (greifen kann).

Aus der ''fhem.cfg'':

<nowiki>define BBxM SYSSTAT 120 600
attr BBxM filesystems /dev/mmcblk0p2
attr BBxM room <Ihr Raum>
attr BBxM showpercent 1</nowiki>
<ins>Anmerkungen:</ins>

* Die Load-Daten werden alle 120 (Default-Wert: 60) '''Sekunden''' gelesen und es wird dabei die Partition ''/dev/mmcblk0p2'' alle 600 Sekunden überwacht. Die Belegung der Partition wird in Prozent angegeben. Wie die Partitionen auf ihrem Linux-System benannt sind erfahren Sie z.B. über den ''mount''-Befehl.
* Wird kein Auslese-Interval für die Partitionen angegeben, so wird dieses auf den ersten Wert <ins>mit 60 multipliziert</ins> gesetzt. So würde im o.a. Beispiel aus dem ersten Wert 120 (für das System-load) ein Auslesewert von 7.200 Sekunden, also 120 Minuten bzw. 2 Stunden.

Weitere Definitionen in der ''fhem.cfg'':

<nowiki>define FileLog_BBxM FileLog /opt/fhem/log/BBxM-%Y-%m.log BBxM
attr FileLog_BBxM archivedir /opt/fhem/archive/
attr FileLog_BBxM logtype sysstat:Plot,text
attr FileLog_BBxM nrarchive 1
attr FileLog_BBxM room <Ihr Raum>
define Stats_BBxM weblink fileplot FileLog_BBxM:mysysstat:CURRENT <<<==== siehe unten
attr Stats_BBxM alias Systemlast
attr Stats_BBxM label "Systemlast von BBxM Min: $data{min1}, Max: $data{max1}, Aktuell: $data{currval1}"
attr Stats_BBxM room <Ihr Raum></nowiki>
= Plot =
Standard ist die Angabe von ''define Stats_BBxM weblink fileplot FileLog_BBxM:'''sysstat''':CURRENT''. Dadurch wird nur die Systemlast grafisch (Plot) dargestellt. Wenn Sie auch die Belegung einer Partition im Plot sehen wollen, können Sie folgende Datei (die Sie sich als ''mysysstat.gplot''unterhalb von ''<Ihr-FHEM-Verzeichnis>/www/gplot''speichern müssten, damit die o.a. Konfiguration greift) verwenden:

<nowiki>############################
# Display the sysload and diskusage values
# Corresponding FileLog definition:
# define deviceLog FileLog ./log/device-%Y-%m.log device
set terminal png transparent size <SIZE> crop
set output '<OUT>.png'
set xdata time
set timefmt "%Y-%m-%d_%H:%M:%S"
set xlabel " "
set title '<L1>'
set ylabel "Load"
set y2label "/ belegt %"
set y2range [0:100]
#FileLog 4:load:0:
#FileLog 4:/\x3a:0:
plot "< awk '/load:/ {print $1, $4}' <IN>" using 1:2 ls l0 axes x1y1 title 'Load' with lines
plot "< awk '//:/ {print $1, $4}' <IN>" using 1:2 ls l2fill axes x1y2 title 'Disk' with lines</nowiki>
<ins>Anmerkungen:</ins>

* Die Zeile "#FileLog 4:/\x3a:0:" muss evtl. an ihre Gegebenheiten angepasst werden, wenn Sie nicht das root-Volume überwachen (wollen).
* Beachten Sie, dass die Sequenz "\x3a" der vorgenannten Zeile den Filter auf "/:" legt. Eine Angabe wie "#FileLog 4:/:''':'''0:" funktioniert nicht, da der Doppelpunkt eine besondere Bedeutung hat. Er muss also "maskiert" werden. Die ''awk''-Sequenz ("awk '//:/") ist für die Plot-Ausgabe nicht relevant.
* Regulär würde ein "#FileLog 4:/:0:" für die root-Partition ausreichen (was den Filter auf "/" legt), aber spätestens, wenn Sie ein 2. Volume (z.B. "/mount/usb") im Plot anzeigen wollen, trifft der Filter "/" auf beide Volumes zu. Dies führt dann zu eigenartigen Effekten im Plot.
= Links =
FHEM-Forum: [http://forum.fhem.de/index.php?t=msg&th=10888&start=0&rid=417 Ankündigung als offizielles Modul]

FHEM-Forum: [http://forum.fhem.de/index.php?t=msg&th=10573&start=0&rid=417 Inoffizielles Modul]

Synology NAS

2013-05-10T20:54:22Z

Generix: Die Seite wurde neu angelegt: „There is a German version of this description already under FHEM auf dem Synology DS408.“

There is a German version of this description already under [[FHEM auf dem Synology DS408]].

SUNRISE EL

2013-05-10T20:54:21Z

Generix: Die Seite wurde neu angelegt: „'''Lichtsteuerung per sunset / sunrise''' == Voraussetzungen == In der ''fhem.cfg''müssen Sie vorher Ihren Wohnsitz definieren, da der Sonnenauf- und -unterga…“

'''Lichtsteuerung per sunset / sunrise'''
== Voraussetzungen ==
In der ''fhem.cfg''müssen Sie vorher Ihren Wohnsitz definieren, da der Sonnenauf- und -untergang ja nicht nur vom Datum, sondern auch vom Längen- und Breitengrad Ihres Standortes abhängig ist. Hierzu tragen Sie folgende Zeilen in die ''fhem.cfg''ein:

<nowiki>attr global latitude 5X.XYZ
attr global longitude 6.XYZ</nowiki>
und zwar in genau dieser Schreibweise. Entweder benutzen Sie zur Bestimmung ein GPS-System oder sie befragen einen entsprechenden Internet-Dienst.

== Steuerung ==
Mittels folgender Skriptzeilen in der ''fhem.cfg''
<nowiki># Außenlampe - Steuerung An-/Ausschaltzeit
define AussenlampeAn1 at *{sunset(0,"17:00","22:00")} set EG.Diele.Aussenlampe on
define AussenlampeAus1 at *{sunrise(0,"05:00","07:30")} set EG.Diele.Aussenlampe off</nowiki>
wird der Funk-Lichtschalter für die Außenbeleuchtung (hier das FHEM-Gerät mit dem Namen ''EG.Diele.Aussenlampe'')

* morgens zum Sonnenaufgang, aber nicht vor 05:00 und nicht nach 07:30 Uhr ausgeschaltet

und

* abends zum Sonnenuntergang eingeschaltet, aber nicht vor 17:00 Uhr und nicht nach 22:00 Uhr.
== Kontrolle ==
Um die Zeiten zu kontrollieren können Sie in der FHEM-Befehlszeile den Befehl

<code>
list AussenlampeAn1
</code>

eingeben und mit der <Enter>-Taste (nicht "save-Button") bestätigen. Sie sehen dann (hier eine Ausgabe vom 17.01.2013) z.B. folgendes:

<nowiki>Internals:
DEF *{sunset(0,"17:00","22:00")} set EG.Diele.Aussenlampe on
NAME AussenlampeAn1
NR 225
NTM 17:37:09
REP -1
STATE Next: 17:37:09
TRIGGERTIME 1358527029
TYPE at
Attributes:
room Diele</nowiki>
Der Sonnenuntergang liegt am genannten Tag '''innerhalb'''des Start-/Ende-Zeitraums, so dass die Lampe um 17:37 Uhr eingeschaltet wird.

Die Ausgabe (gleiches Datum) von

<code>
list AussenlampeAus1
</code>

lautet:

<nowiki>Internals:
DEF *{sunrise(0,"05:00","07:30")} set EG.Diele.Aussenlampe off
NAME AussenlampeAus1
NR 228
NTM 07:30:00
REP -1
STATE Next: 07:30:00
TRIGGERTIME 1358490600
TYPE at
Attributes:
room Diele</nowiki>
Hier liegt der Sonnenaufgang noch '''außerhalb'''des Start-/Ende-Zeitraums, so dass die Lampe um 07:30 Uhr ausgeschaltet wird.

== Hinweise ==
* Da es <nowiki>[https://groups.google.com/forum/?fromgroups=#!topic/fhem-users/y2CbOQmTVsg Eintrag in der ehemaligen FHEM-Google-Group]</nowiki> entnehmen.
* 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).

Squeezebox

2013-05-10T20:54:12Z

Generix: Die Seite wurde neu angelegt: „Um eine Logitech Squeezebox (ein Netzwerk-Musikplayer) fernzusteuern muss diese mit einem Logitech Media Server verbunden sein. (Weitere Informationen wie man …“

Um eine Logitech Squeezebox (ein Netzwerk-Musikplayer) fernzusteuern muss diese mit einem Logitech Media Server verbunden sein. (Weitere Informationen wie man die Squeezebox mit einem Server verbindet findet man auf [http://www.mysqueezebox.com/download MySqueezeBox.de].)

Getestet wurde das folgende auf einer FB7390 mit FHEM [[AVM Fritz!Box" class="mw-redirect]].

Einfach in ein Utils Skript ([[99 myUtils anlegen]]) folgende Funktion einfügen:

<nowiki>sub squeezebox($) {
my ($state) = @_;
if ($state eq "on")
{
system("wget -O /dev/null -q http://[SqueezeboxServerIP]:[SqueezeboxServerPort]/status.html?p0=play");
}
else
{
system("wget -O /dev/null -q http://[SqueezeboxServerIP]:[SqueezeboxServerPort]/status.html?p0=power&p1=0");
}
}</nowiki>
Ein Aufruf erfolgt mit <code>{ squeezebox("on") }</code> oder <code>{ squeezebox("off") }</code>

= Hinweise =
* In dem Skript muss die IP sowie der Port ersetzt werden. Der Standardport ist 9000.
* Es gibt noch weitere Befehle um die Squeezebox zu steuern (Lautstärke erhöhen, Pause, Stop,...)
** Lautstärke setzen: <code>http://[SqueezeboxServerIP]:[SqueezeboxServerPort]/status.html?p0=mixer&p1=volume&p2=YY</code>, wobei YY die Lautstärke auf einer Skala von 0-100 ist.
</li><li> Falls mehrere Squeezeboxen mit dem Server verbunden sind, kann mittels Parameter <code>&player=XX%3AXX%3AXX%3AXX%3AXX%3AXX</code> eine spezielle verwendet werden. XX= MAC-Adresse der Squeezebox.
</li><li> Mehr Befehle können aus den Links der Statusseite ausgelesen werden: <code>http://[SqueezeboxServerIP]:[SqueezeboxServerPort]/status.html</code>
</li></ul>
= Quelle =
Grundlagen in folgendem Beitrag entdeckt: [http://www.squeezebox-forum.de/viewtopic.php?f=13&t=1521#p12286 [1]]

SML

2013-05-10T20:53:19Z

Generix: Die Seite wurde neu angelegt: „== Einleitung == Das Smart Metering Language (SML, auf XML basierende Syntax) Modul ('''''70_SML.pm''''') ist ein Modul zur Auswertung von über LAN (TCP/IP) a…“

== Einleitung ==
Das Smart Metering Language (SML, auf XML basierende Syntax) Modul ('''''70_SML.pm''''') ist ein Modul zur Auswertung von über LAN (TCP/IP) abfragbaren Stromzählern.

== Voraussetzung ==
Der Stromzähler muß von FHEM aus über das Netzwerk erreichbar sein, üblich ist der Port 80, es ist aber auch jeder andere Port denkbar.

Zur Zeit bekannte Stromzähler, die abgefragt werden können:

* "Intelligenter Strom Zähler" (ENBW)
* "Sparzähler" (Yellow Strom)
== Benutzung ==
Die Definition eines SML Devices erfolgt mit dem Befehl:

<nowiki>define <name> SML <host> <port> [<interval> [<timeout>]]</nowiki>
Wobei <host> der Hostname und <port> der angegebene TCP Port des Zählers sind.

Das <interval> ist per default 300 sec. Das bedeutet, es wird der Durchschnitt aus den letzten 300 sec (5 min) ausgegeben.

Der <timeout> gibt an, wie lange ein Verbindungsaufbau versucht wird, default ist hier 4 sec.

Zählerstand einzutragen:

<nowiki>set <name> TOTALPOWER <wert></nowiki>
== Loggen ==
<nowiki>define SML_log FileLog /var/log/fhem/enbw-%Y.log sml:.*</nowiki>
So schaut dann eine log Zeile aus die pro intervall erzeugt wird:

<nowiki>2012-08-08_19:03:08 enbw min: 441 max: 1935 last: 672 avg: 771.35 day: 5.124356 month: 66.241639 year: 11834.708207 total: 11834.708207</nowiki>
Day: das ist die Tagessumme, und wird um 24 Uhr wieder auf 0 KW gesetzt.
Month: das ist die Monatssumme und wird jeden Monat wieder auf 0 KW gesetzt.
Year: das ist die Jahressumme und wird jedes Jahr auf 0 KW gesetzt.
Total: das ist der Zählerstand und wird nicht verändert.

== Plotten ==
<nowiki>define wl_ENBW weblink fileplot SML_log:smartmeter:CURRENT</nowiki>
[[File:/w/images/c/ca/SML2.png|808px|link=/wiki/Datei:SML2.png|alt=Beispiel eines SML-Plots]]

smartmeter.gplot:

<nowiki>set terminal png transparent size <SIZE> crop
set output '<OUT>.png'
set xdata time
set timefmt "%Y-%m-%d_%H:%M:%S"
set xlabel " "
set title '<TL>'
set y2label "currentPower (W)"
set ylabel "totalEnergyDay (kWh)"
#FileLog 12:enbw:0:
#FileLog 10:enbw:0:
#FileLog 8:enbw:0:
#FileLog 6:enbw:0:
#FileLog 4:enbw:0:
plot \
"< awk '/enbw:/ {print $1, $12}' <IN>"\
using 1:2 ls l9 axes x1y1 title 'day' with filledcurve,\
"< awk '/totalEnergyDay:/ {print $1, $10}' <IN>",\
using 1:2 ls l2 axes x1y2 title 'averange' with histeps,\
"< awk '/totalEnergyDay:/ {print $1, $8}' <IN>",\
using 1:2 ls l3 axes x1y2 title 'last' with histeps,\
"< awk '/totalEnergyDay:/ {print $1, $6}' <IN>",\
using 1:2 ls l1 axes x1y2 title 'max' with histeps,\
"< awk '/totalEnergyDay:/ {print $1, $4}' <IN>",\
using 1:2 ls l0fill axes x1y2 title 'min' with histeps</nowiki>

== Kontakt ==
Bei Problemen/Fragen bitte per Mail an: gabriel AT bentele DOT de, wenden.

Slider für HM-Rollladensteuerung anzeigen

2013-05-10T20:53:17Z

Generix: Die Seite wurde neu angelegt: „Wenn eine Homematic Rolladensteuerung gepaart wird, wird sie normalerweise wie ein Schalter angezeigt, also mit on off. Der State ist aber eine Prozentzahl, al…“

Wenn eine Homematic Rolladensteuerung gepaart wird, wird sie normalerweise wie ein Schalter angezeigt, also mit on off. Der State ist aber eine Prozentzahl, allerdings wird bei ganz oben "off" und bei ganz unten "on" angezeigt. Da die Icons für "on" und "off" die Glühbirne sind, werden diese auch hier angezeigt.

[[File:/w/images/2/22/Rolladen_switches.png|247px|link=/wiki/Datei:Rolladen_switches.png|alt=Rolladen switches.png]]

== UP / Down Buttons ==
Wenn man lieber einen Rolladen als einen Rolladen darstellen möchte, dann kann mann die icons ändern. Dazu wird zuerst das eventMap des devices geändert:

<nowiki>attr <Gerätename> eventMap on:down off:up</nowiki>
Nun kann man neue icons in den Ordner für die Bilder legen (auf meiner Fritzbox ist das \\Fritz!nas\fritz.nas\fhem\www\images\default), die down.png und up.png heißen und wie Rolläden aussehen (Achtung, muss noch in up.png und down.png umbenannt werden, sonst geht's nicht!):

[[File:/w/images/a/a5/Blind_Up.png|28px|link=/wiki/Datei:Blind_Up.png|alt=Blind Up.png]][[File:/w/images/7/72/Blind_Down.png|28px|link=/wiki/Datei:Blind_Down.png|alt=Blind Down.png]]
Nun wird der Zustand schon mal nicht mehr durch Glühbirnen angezeigt.

[[File:/w/images/2/23/Roll%C3%A4den_up_down.png|251px|link=/wiki/Datei:Roll%C3%A4den_up_down.png|alt=Rolläden up down.png]]
Wer dies so ausreichend findet, kann hier aufhören.

== Slider ==
Möchte man anstelle der Schalter für "ganz nach unten" oder "ganz nach oben" lieber einen slider anzeigen, so kann man diesen entweder in den Gerätedetails finden oder direkt auf dem Raum anzeigen lassen. Dazu muss das Attribut WebCMD gesetzt werden:

<nowiki>attr <Gerätename> webCmd pct</nowiki>
Dann wird anstelle der Schalter ein slider angezeigt:

[[File:/w/images/d/de/Rolladen_slider.png|457px|link=/wiki/Datei:Rolladen_slider.png|alt=Rolladen slider.png]]
Ich empfehle, die eventMap für die Verwendung eines sliders anders zu setzen, da sonst der slider aus unbekannten Gründen bei on auf 0 springt:

<nowiki>attr <Gerätename> eventMap on:100% off:0%</nowiki>
Um wieder die richtigen Icons zu erhalten, ändern wir einfach die devStateIcons:

<nowiki>attr <Gerätename> devStateIcon 0%:up 100%:down</nowiki>
Achtet beim Ersetzen von <Gerätename> genau auf Eure Groß- und Kleinschreibung, sonst geht's nicht.

== Prozentleiste ==
Nun noch eine letzte Möglichkeit: Eine Prozentleiste, auf der man direkte Prozentwerte tippen kann, wenn der slider nicht gefällt.

Dazu wird ebenfalls ein webCmd Attribut gesetzt:

<nowiki>attr <Gerätename> webCmd stop:up:90:80:70:60:50:40:30:20:10:down</nowiki>
Das sieht dann so aus:

[[File:/w/images/e/e7/Roll%C3%A4den_Prozentleiste.png|656px|link=/wiki/Datei:Roll%C3%A4den_Prozentleiste.png|alt=Rolläden Prozentleiste.png]]
Da es von dem Anschluss der Motorwicklungen des Rolladenantriebs abhängig ist, wo 0% und wo 100% ist, kann es sein, dass die gezeigten Icons für Eure Installation falschherum sind. Daher entweder up/down umdrehen oder die beiden Anschlussleitungen des Motors tauschen...

Sensoren mit Schaltkontakt, Anschluss an FS-20

2013-05-10T20:53:15Z

Generix: Die Seite wurde neu angelegt: „= Sensoren mit Schaltkontakt, Anschluss an FS-20 = == Motiv == Das FS-20 System bietet nur eine eingeschränkte Auswahl an Sensoren an. Andererseits gibt es ei…“

= Sensoren mit Schaltkontakt, Anschluss an FS-20 =
== Motiv ==
Das FS-20 System bietet nur eine eingeschränkte Auswahl an Sensoren an. Andererseits gibt es eine große Auswahl an kostengünstigen Sensoren, die aber nicht "funkfähig" sind. Gesucht wird deshalb eine Kopplungsmöglichkeit zum FS-20 System, um diese Sensorik über das FS-20 System und FHEM auswerten zu können.

Die hier dargestellte Lösung stellt eine einfache Möglichkeit dar, um den Schaltkontakt von 230V AC bis 12 V DC Sensoren an den Sender FS20 S4U (siehe [[FS20 S4U Unterputz-Sender]]) anzuschließen.

Getestet worden sind folgende Sensoren mit Schaltkontakt:

* Bewegungsmelder (Baumarkt)
* Wassermelder (M158, Fa. Kemo)
* Rauchmelder( ABUS RM1000)
* Thermostatschalter zur Temperaturüberwachung z.B. bei Heizungsausfall(Finder 7T.81)
== Problem ==
Das FS-20 System bietet als Sender den 2/4-Kanal-Unterputz-Sender FS20 S4U an. Dieser Sender kann im 4-Kanal-Betrieb bis zu 4 Taster auswerten.

Ist der potentialfreie Schaltkontakt eines Sensors direkt am Tastereingang des Funksenders angeschlossen, so sendet dieser bei Betätigung ständig ein „Dimupdown“.

Sind aber mehrere Schaltkontakte von Sensoren direkt an dem Sender angeschlossen und dauerhaft betätigt, so hat der Sender leider die Eigenschaft, nicht für alle Schaltkontakte das „Dimupdown“- Kommando zu senden, so dass die FHEM-Steuerung als Empfänger nicht von jedem Sensor die Schalterbetätigung mitbekommt. Informationen gehen also verloren.

[[File:/w/images/thumb/c/c9/Schaltung230VAC.JPG/200px-Schaltung230VAC.JPG|200px|link=/wiki/Datei:Schaltung230VAC.JPG|alt=]]<a href="/wiki/Datei:Schaltung230VAC.JPG" class="internal" title="vergrößern"><img src="/w/skins/common/images/magnify-clip.png" width="15" height="11" alt="" /></a>
Prinzipschaltung, Anschluss eines 230V AC-Sensors mit Schaltkontakt

[[File:/w/images/thumb/a/ac/Schaltung12VDC.JPG/200px-Schaltung12VDC.JPG|200px|link=/wiki/Datei:Schaltung12VDC.JPG|alt=]]<a href="/wiki/Datei:Schaltung12VDC.JPG" class="internal" title="vergrößern"><img src="/w/skins/common/images/magnify-clip.png" width="15" height="11" alt="" /></a>
Prinzipschaltung, Anschluss eines 12V DC-Sensors mit Schaltkontakt

== Lösung ==
Der Schaltkontakt wird über einen asynchronen Taktgeber an den Tastereingang geführt. Ist der Schaltkontakt (z.B. bei einem Thermostat wegen Untertemperatur) dauerhaft betätigt, emuliert der Taktgeber daraus ein periodisches „ Tippen auf einen Taster“.

Vorteil: Sollte tatsächlich mal ein Takt nicht gesendet und somit „verloren gehen“, wird das Ereignis nach Beendigung der Pausenzeit erneut gesendet . Aufgrund dieser Redundanz ist eine hohe Zuverlässigkeit gegeben.

Erprobt worden ist diese Schaltung mit asynchronen Taktgebern von Finder, Typ 80.91.

Dieser Taktgeber bietet weitere Vorteile:

* Die Impulsdauer und die Pausenzeit zwischen den Impulsen ist einstellbar
* Der Taktgeber arbeitet auch bei 12V DC (Umin = 10.8 V AC/DC)
* Der Taktgeber wird auf einer Hutschiene befestigt, so dass dieser in jeden Hausverteilerkasten eingebaut werden kann.

Als 12V DC –Hutschienennetzteil könnte das Gerät DSP10-12 von TDK-Lambda verwendet werden.

''(HINWEIS: Zu Arbeiten an netzspannungsführenden Teilen sind nur Personen berechtigt, die über eine geeignete Ausbildung verfügen)''
== Praktischer Einsatz dieser Schaltung ==
* Der Sender FS20 S4U wird im 4-Kanal-Betrieb betrieben.
* Die Impulsdauer wird so klein wie möglich eingestellt. Dann liefert der Sender nur ein einziges „Toggle“- oder "DimUpDown" Kommando pro Impuls, wenn der Schaltkontakt geschlossen ist.
* Die Pausenzeit sollte nach der Priorität eingestellt werden: (z.B. 2 min bei wichtigeren Meldungen wie z.B. Rauchmelder, 10 min bei unwichtigeren, wie z.B. Untertemperatur)
== Programmauswertung ==
Beispiel: Erkennt ein Wasssermelder Feuchtigkeit, so sollen über die Fritzbox 7390 eine Mail gesendet und 2 Telefonanrufe ausgeführt werden.

Um den Schaltkontakt abzufragen, reicht eine „notify“ Anweisung aus. Diese wird jedes Mal dann aufgerufen, wenn der Schaltkontakt geschlossen ist und der Impulsgeber einen Impuls erzeugt hat.

Sofern die Impulsdauer sehr klein (nahe dem Minimum) eingestellt ist, wird entweder als Ereignis ein „toggle“ oder „dimupdown“ pro Impuls generiert.

Ein Wassermelder könnte in der ''fhem.cfg''wie folgt ausgewertet werden :

<nowiki>define dvce_HausBekommtNasseFuesse FS20 11111111 1234
attr dvce_HausBekommtNasseFuesse Alarm

define cm_AlarmWasser notify dvce_HausBekommtNasseFuesse \
{FritzBoxSendMail("Wasseralarm")};;\
{FritzBoxEmergencyCall()}</nowiki>
Die Funktionen ''FritzBoxSendMail()''und ''FritzBoxEmergencyCall()''können in einer z.B. ''99_MyUtilsUserDef.pm''(siehe [[99 myUtils anlegen]] ) heißenden Datei wie folgt ausgeführt werden:

<nowiki># Mail und Telefonanruf ++++++++++++++++++++++++++++++++++++++++++++++++++++++
sub
FritzBoxEmergencyCall ()
{
InternalTimer(gettimeofday()+5, "FritzBoxCallnr", 'TelefonNr1', 0);
InternalTimer(gettimeofday()+30, "FritzBoxCallnr", 'TelefonNr2', 0);
return
}
sub
FritzBoxCallnr ($)
{
my ($callnr) = @_;

$callnr = "ATDT".$callnr."#";
my $ret = "ATD: " . `echo $callnr | nc 127.0.0.1 1011` ;
InternalTimer(gettimeofday()+8, "FritzBoxHangOn", "", 0);
return
}
sub
FritzBoxHangOn ()
{
my $ret = " ATH: " . `echo "ATH" | nc 127.0.0.1 1011` ;
$ret =~ s,[\r\n]*,,g;
return
}
sub FritzBoxSendMail
{
my $subject = $_[0];
system(" /sbin/mailer -s $subject ");
}</nowiki>

Lothar Wohlgemuth, 24. 10. 2012

Script mit Webschalter auslösen

2013-05-10T20:53:08Z

Generix: Die Seite wurde neu angelegt: „== Aufgabe: == Es soll auf der Weboberfläche einen Schalter geben, der mehrere Lampen zugleich einschaltet. Ausserdem soll diese Aktion auch per Fernbedienung…“

== Aufgabe: ==
Es soll auf der Weboberfläche einen Schalter geben, der mehrere Lampen zugleich einschaltet.
Ausserdem soll diese Aktion auch per Fernbedienung ausgelöst werden können.

== Voraussetzungen: ==
Es seien in FHEM drei Geräte Licht_1 - Licht_3 definiert, also z.b. 3 FS20 Schaltsteckdosen, Unterputzschalter o.ä. oder deren HM-Equivalent.

== Vorgehen: ==
Zunächst ist ein FS20 Dummy anzulegen:

<nowiki>define Licht_an FS20 11114444 1a
attr Licht_an dummy 1
attr Licht_an room HAUS</nowiki>
Wobei:

11114444 de
ist der FS20 Hauskode und "1a" ist die Kanaladresse in Hex, also in ELV Notation 12 33

Das erzeugt auf der Weboberfläche erstmal einen normal aussehenden FS20 Schalter im Raum
HAUS.

Den kann man auf der Weboberfläche schalten oder auch mit einer Fernbediehnung, die die Werte 11114444 1a hat.

Als nächstes muss ein Script angelegt werden, das auf Betätigung des Schalters reagiert. Dazu nimmt man "notify".

<nowiki>define act_on_Licht_an notify Licht_an {\
if ("%" ne "off") {\
fhem("set Licht_1 on ;; set Licht_2 on ;; set Licht_3 on")\
}\
else {\
fhem("set Licht_1 off ;; set Licht_2 off ;; set Licht_2 off")\
}\
}</nowiki>
== Erläuterungen: ==
define act_on_Licht_an

es wird eine Aktion definiert die "act_on_Licht_an" heisst. Der Namen hat keine spezielle Bedeutung, er könnte auch "Blabberschnalz33" lauten, aber sprechende Namen sind leichter zu lesen.

notify Licht_an

reagiere wenn der Schalter "Licht_an" betätigt wird. Beachte, dass es egal ist, ob der an- oder ausgeschaltet oder gedimmt wird. Sobald er ''''irgendwas''''macht, wird die folgende Aktion ausgelöst.

{

was jetzt kommt ist keine reines "FHEM Kommando" mehr, sondern PERL

if (

prüfen ob der Ausdruck in der Klammer gleich zutrifft, nur dann die Kommandos ausführen.

"%" ne "off")

"%" ist der Wert des letzten Kommandos. Den Kram in der nächsten Klammer NUR machen, wenn dieser Wert nicht gleich (ne = not equal) "off" ist. Mit anderen Worten: Den folgenden Kram nur machen, wenn auf der Weboberfläche ON gedrückt wurde, oder auf der Fernbedienung ein ON oder DIM UP Befehl ausgelöst wurde. Man könnte auch auf ("%" eq "on") testen. Nachteil ist aber, wenn jemand an der Fernbedienung versehentlich zu lange drückt und damit einen Dimmbefehl auslöst, geht das Licht nicht an!

{ fhem("set Licht_1 on ;; set Licht_2 on ;; set Licht_3 on") }

PERL soll FHEM mitteilen, dass FHEM "set Licht_1 on ; set Licht_2 on ; set Licht_3 on" ausführen soll, also alle drei Lampen an. Beachte die Verdoppelung der Semikolons, das ist nötig, weil so PERL mitgeteilt wird, dass die Dinger nicht irgendwelche PERL Bedeutung haben, sondern an FHEM weitergereicht werden sollen; das nennt man "Escapen"

else

Falls der Test am Anfang NICHT erfolgreich war (mit anderen Worten jemand OFF gedrückt hat - egal ob auf Weboberfläche oder Fernbedienung), dann mach was jetzt kommt.

{ fhem("set Licht_1 off ;; set Licht_2 off ;; set Licht_2 off") }

PERL soll FHEM mitteilen (etc, analog oben)

}

Ende mit PERL-Kram

== Anmerkungen: ==
Es ist unerheblich, ob die Aktionen in den Scripten FS20 Aktoren ansprechen oder Licht_1 z.B. eine HomeMatic (HM) Komponente ist. Der Dummyschalter muss auch nicht ein FS20 Schalter sein. Es lassen sich alle Welten beliebig mischen.

Mit den obigen Beispielen lassen sich also z.B. auch HM Komponenten mit einer FS20 Fernbedienung betätigen. Voraussetzung ist jedoch, dass am FHEM Host Funkzentralen für beide Systeme angeschlossen sind, also z.b. zwei [[CUL]], einer in SlowRF Mode und einer im HM Mode, oder ein CUN(O) in SlowRF Mode und ein HM LAN Konfigurationsadapter.

Schalten von 2 Lampen mit einem Taster

2013-05-10T20:53:08Z

Generix: Die Seite wurde neu angelegt: „== Aufgabe == Mit nur einem Taster sollen 2 Stromverbraucher (hier an dem Beispiel von 2 Lampen) der Reihe nach durchgeschaltet werden Dabei können verschiede…“

== Aufgabe ==
Mit nur einem Taster sollen 2 Stromverbraucher (hier an dem Beispiel von 2 Lampen) der Reihe nach durchgeschaltet werden
Dabei können verschiedene Schaltreihenfolgen eingerichtet werden.

== Script ==
Die beiden Lampen werden im Script jeweils als L1 und L2 bezeichnet, der Taster als T1

=== Schaltreihenfolge 1 ===
<table border="1px solid #aaa" style="text-align:center" class="wikitable">
<tr>
<th> Tastendruck </th>
<th> Lampe 1 </th>
<th> Lampe 2
</th></tr>
<tr>
<td> 1 </td>
<td> an </td>
<td> aus
</td></tr>
<tr>
<td> 2 </td>
<td> an </td>
<td> an
</td></tr>
<tr>
<td> 3 </td>
<td> aus </td>
<td> an
</td></tr>
<tr>
<td> 4 </td>
<td> aus </td>
<td> aus
</td></tr></table>

<nowiki>define MyNotify notify T1:Btn1.on.* {if(Value("L1") eq "off" && Value("L2") eq "off"){fhem "set L1 on"}
elsif(Value("L1") eq "on" && Value("L2") eq "off") {fhem "set L2 on"}
elsif(Value("L1") eq "on" && Value("L2") eq "on") {fhem "set L1 off"}
else{fhem "set L1,L2 off"}}</nowiki>
=== Schaltreihenfolge 2 ===
<table border="1px solid #aaa" style="text-align:center" class="wikitable">
<tr>
<th> Tastendruck </th>
<th> Lampe 1 </th>
<th> Lampe 2
</th></tr>
<tr>
<td> 1 </td>
<td> an </td>
<td> aus
</td></tr>
<tr>
<td> 2 </td>
<td> an </td>
<td> an
</td></tr>
<tr>
<td> 3 </td>
<td> aus </td>
<td> aus
</td></tr></table>

<nowiki>define MyNotify notify T1:Btn1.on.* {if(Value("L1") eq "off" && Value("L2") eq "off"){fhem "set L1 on"}
elsif(Value("L1") eq "on" && Value("L2") eq "off") {fhem "set L2 on"}
else{fhem "set L1,L2 off"}}</nowiki>

Dieses Beispiel lässt sich auch für mehr als 2 Stromverbraucher erweitern, allerdings wird die Abfrage dann sehr komplex.

Schalten mit mehreren Bedingungen

2013-05-10T20:53:07Z

Generix: Die Seite wurde neu angelegt: „== Aufgabe: == Der FHT heizung_bad soll morgens mit Aktivierung des Bewegungsmelders piri_schlafzimmer für eineinhalb Stunden die Temperatur auf 23 Grad Celsi…“

== Aufgabe: ==
Der FHT heizung_bad soll morgens mit Aktivierung des Bewegungsmelders piri_schlafzimmer für eineinhalb Stunden die Temperatur auf 23 Grad Celsius erhöhen und danach wieder auf 18 Grad absenken.

Allerdings nur, wenn folgende Bedingungen erfüllt sind:

* Es ist zwischen 4:30 Uhr und 9:00 Uhr,
* der Fensterkontakt Fenster_bad ist "Closed"
* der Türkontakt tfk_tuer ist "on".

Sinn soll sein, bei Bewegung im Schlafzimmer zu möglichen Aufstehzeiten (also z.b. nach dem Wecker greifen) das Bad vorzuheizen, aber nur wenn das Fenster nicht auf ist und die Tür zu (also überhaupt jemand im Schlafzimmer ist, da Tür sonst auf). Die Badheizung soll nach 1,5 Stunden von alleine wieder ausgehen.

Die Abfrage des Fensterkontakts TF ist auch dann sinnvoll wenn er mit dem FHT80b gepaired ist. Beim Öffnen des Fensters wird zwar die aktuelle Temperatur des gepairten FHT auf die Window-Temp abgesenkt, nachträgliche Änderungen werden aber als erwünschte Anhebung der Window-Temp interpretiert und auch ausgeführt. D.H. bei Auslösung des notify würde der Bad-FHT auf 23 Grad stellen, obwohl das Fenster auf ist. Daher muss der TF einzeln abgefragt werden. Dazu den TF trotz pairing vorher mit

<nowiki>define Fenster_bad CUL_FHTTK <TF ID></nowiki>
definieren.
Die (fest im TF eingestellte) TF ID ist vor dem Pairen dem Logfile zu entnehmen:

<nowiki>FHTTK unknown device <TF ID>, please define it</nowiki>

== Voraussetzungen: ==
Definierter [[FHT80TF]] (gepairt oder ungepairt mit dem Bad FHT), Türkontakt TFK.

== Script ==
<nowiki>define badbenutzung_on notify piri_schlafzimmer:on.* {\
my $hm = sprintf("%%02d:%%02d", $hour, $min);;\
if( $hm gt "04:30" && $hm lt "09:00" &&\
$value{tfk_tuer} eq "on" &&\
$value{Fenster_bad} eq "Closed" &&\
 !$data{badbenutzung_on}) {\
$data{badbenutzung_on} = 1;;\
fhem "set heizung_bad desired-temp 23.0";;\
fhem "define at_badbenutzung_off at +01:30 trigger
badbenutzung_off"\
}\
}
define badbenutzung_off notify badbenutzung_off {\
fhem "set heizung_bad desired-temp 18.0";;\
delete($data{badbenutzung_on})\
}</nowiki>
== Erläuterungen ==
<nowiki>notify piri_schlafzimmer:on.*</nowiki>
Filtert die Events des piri_schlafzimmer so, das nur bei Events die mit "on" beginnen notified wird. Die RegEx ".*" akzeptiert dabei auch bieliebige Zeichen (".") in beliebiger Menge ("*") nach "on", sodasss auch events wie "on-for-timer" auslösen, nicht jedoch z.b. "off".

Zu beachten ist, dass ";" und "%" innerhalb der perl expressions "{ }", z.b. "sprintf { } " verdoppelt (escaped) werden müssen , um zu verhindern, dass die Zeichen als FHEM-Kommando interpretiert werden.

Garagentorsteuerung

2013-05-10T20:53:05Z

Generix: Die Seite wurde neu angelegt: „== Aufgabe: == Es soll ein Garagentor geschaltet werden. Die toreigene Steuerung kennt keinen absoluten Zustand, das Betätigen eines Tasters öffnet das Tor w…“

== Aufgabe: ==
Es soll ein Garagentor geschaltet werden. Die toreigene Steuerung kennt keinen absoluten Zustand, das Betätigen eines Tasters öffnet das Tor wenn es zu ist und schliesst es, wenn es offen ist. Mit FHEM soll die Möglichkeit geschaffen werden, das Tor in einen definierten Zustand zu bringen. Der Garagentormotor ist so konstruiert, dass eine kurzers Drücken des Tasters ausreicht um den Schliess- Öffenvorgang auszulösen, der Taster muss nicht gehalten werden bis das Tor auf oder zu ist. Das Tor soll über Schaltflächen auf der Weboberfläche von FHEM betätigt werden.

== Voraussetzungen: ==
Ein Tür/Fensterkontakt, der prüft ob das Tor auf oder zu ist.

Im konkreten Fall sei eine [[FHT80TF]] eingesetzt.

Dieser ist zu definieren:

<nowiki>define Einfahrt CUL_FHTTK 3b8823
attr Einfahrt room Aussen</nowiki>
Ausserdem muss der Schaltaktor definiert werden, der auf Funkbefehl den Taster des Garagentormotors betätigt. (im konkreten Fall wurde ein [[FS20 AS1" class="mw-redirect]] eingesetzt)

<nowiki>#------EinfahrtsTor---------------
define tor_sw FS20 11114444 23
attr tor_sw follow-on-for-timer 1</nowiki>
==== Erläuterungen: ====
* define tor_sw FS20 11114444 23

Der Name "tor_sw" ist frei vergeben und könnte auch z.b. "Garagentor_Schalter" heissen. Der Hauscode der Installation ist 11114444, der Schaltaktor hat die Adresse 23. Dies ist der hexadezimale Wert, der der ELV-Notation 1314 entspricht.

* attr tor_sw follow-on-for-timer 1

Weiter unten werden wir für den Aktor " tor_sw FS20 11114444 23" einen Timer definieren, also dafür sorgen, das er für nur eine Sekunde auf ON geschaltet wird. Dies soll den Taster simulieren. Die Anzeige auf dem Webinterface zeigt immer den letzten Schaltzustand. Im Falle eines Timers wäre dieser nach Betätigung "on for timer 1", man könnte am Webinterface also nicht erkennen, ob der FS20 Schalter aktuelle aus oder an ist.

"follow-on-for-timer 1" sorgt nun dafür, das die Anzeige im Webinterface nach Ende des Timers wieder korrekt auf "off" geht. Die ist für die eigentliche Funktion unerheblich und dient nur einer besseren Visualisierung des Schaltzustandes im Webinterface. Besonders interessant kann dieses Attribut bei Schaltungen ein, die länger als nur eine paar Sekunden dauern.

Zuletzt müssen Aktionen definiert werden, die als Schalter auf der Weboberfläche von FHEM dienen, bzw. mit einer Fernbedienung ausgelöst werden können.

<nowiki>define Einfahrt_ZU FS20 11114444 de
attr Einfahrt_ZU dummy 1
attr Einfahrt_ZU room Aussen</nowiki>
<nowiki>define Einfahrt_AUF FS20 11114444 da
attr Einfahrt_AUF dummy 1
attr Einfahrt_AUF room Aussen</nowiki>
==== Erläuterungen: ====
* define Einfahrt_ZU FS20 11114444 de

Der Name "Einfahrt_ZU" ist frei vergeben und könnte auch z.b. "Garagentor_Schliessen" heissen. Der Hauscode der Installation ist 11114444, die Aktion hat die Adresse da. Diese Adresse ermöglicht es, die Aktion mittels einer auf diese Adresse programmierten Fernbedienung auszulösen. "de" ist der hexadezimale Wert, der der ELV-Notation 4243 entspricht.

* attr Einfahrt_AUF room Aussen

Ordnet die Schalter auf der Weboberfläche dem Raum "Aussen" zu, dieser könnte auch beliebig anders heissen, er dient nur der Übersichtlichkeit.

* dummy bewirkt, das beim Betätigen des Schalters auf der Weboberfläche keine Funksignal gesendet wird.Dies ist nicht erwünscht, da "Einfahrt_ZU" erst im folgenden die eigentlichen Aktionen auslöst.
== Script ==
Es gibt zwei veschiedene Aktionen. Ziel ist es, dass das Einschalten von "Einfahrt_AUF" den Taster des Tores nur betätigt, wenn es zu ist - aber nichts tut, wenn das Tor schon offen ist (respektive "Einfahrt_ZU" entsprechend umgekehrt).

Dazu dienen die folgenden Teile der Konfiguration, die die Aktionen unter bestimmten Bedingungen mit dem definierten Aktor "tor_sw FS20 11114444 23" verbinden:

<nowiki>#------Einfahrtstor ZU, wenn es noch auf ist--------
define act_on_Einfahrt_ZU notify Einfahrt_ZU { if ("$value{Einfahrt}" eq "Open" && "%" ne "off")
{ fhem("set tor_sw off ;; set tor_sw on-for-timer 1 ;; set Einfahrt_AUF off") } }</nowiki>
<nowiki>#------Einfahrtor auf, wenn es noch zu ist--------
define act_on_Einfahrt_AUF notify Einfahrt_AUF { if ("$value{Einfahrt}" eq "Closed" && "%" ne "off")
{ fhem("set tor_sw off ;; set tor_sw on-for-timer 1 ;; set Einfahrt_ZU off") } }</nowiki>
==== Erläuterungen (exemplarisch Einfahrt_ZU, Einfahrt_AUF funktioniert analog): ====
* act_on_Einfahrt_ZU

Ist nur der Name der anschliessend definierten Aktion. Er könnte auch "MyName77" oder "Blubber" heissen. Es ist aber sicher sinnvoll einen selbsterklärenden Namen zu wählen.

* notify Einfahrt_ZU

Es passiert erst etwas, wenn "Einfahrt_ZU" betätigt wird, also auf Weboberfläche oder Fernbedienung mit passender Adresse eine Taste gedrückt wird. (zur Beachtung: Auch ein Drücken der OFF Taste von "Einfahrt_ZU" auf der Weboberfläche oder entsprechend der linken Taste des Tastenpaares einer Fernbedienung ist eine Betätigung!)

* {

Alles was jetzt folgt ist eine PERL Expression (PERL Expressions werden in geschweifte Klammern eingefasst.)

* if ("$value{Einfahrt}" eq "Open" && "%" ne "off")

Falls der Wert von "Einfahrt" (mithin der Zustand des am Anfang definierten Türkontakts FHT80TF) gleich ("eg" = equal) "Open" ist (der FHT80TF kennt die beiden Werte Open und Closed) und zugleich die gedrückte Taste von "Einfahrt_ZU" nicht gleich ("ne" = Not equal) "off" (also "on") ist, dann mache folgendes...
Dieser Teil dient dazu, zwei Dinge abzufragen:

1. Ist das Tor überhaupt offen? Durch Abfrage des durch den Türkontakt gemeldeten Zustandes wird dies festgestellt.

2. Wurde die "on" Taste auf dem Webinterface (entsprechend der rechten Taste auf der zugeordneten Fernbedienung) betätigt? Dies wurde durch Abfragen der Variablen "%" erledigt. Diese enthält den Wert der zuletzt betätigten Taste der definierten Aktion. Diese Bedingung ist für die Funktion nicht zwingend. Sie soll nur verhindern, das die Aktion auch dann gestartet wird, wenn die OFF Taste gedrückt wurde, was vielleicht nicht den Erwartungen des Benutzers entspricht.

Die Form "not equal off" klingt zunächst wie ein etwas komplizierter Weg von "equal on". Diese beiden Abfragen sind aber nicht identisch, da FS20 Dim-Befehle kennt.
Wenn man die Taste einer Fernbedienung versehentlich länger als 0,4 Sekunden betätigt, wir anstatt einem ON Befehl eine Dim-Befehl gesendet. Wird nun auf Tastendruck "on" geprüft, wird in diesem Falle die Aktion nicht ausgeführt, obwohl der Nutzer die richtige Taste drückte. Der Dim-Befehl hat für eine Garagentorsteuerung keine Bedeutung, wenn er gesendet wird kann das eigentlich nur heissen, das der Nutzer versehentlich zu lange gedrückt hat. Das die Aktion nicht ausgeführt wird, weil der Nutzer die richtige Taste (nur) zu lange gedrückt gehalten hat, entspricht aber nicht den Erwartungen des normalen Nutzers. Es ist daher besser darauf zu testen, dass der Nutzer nicht die falsche Taste gedrückt hat.

Nur wenn beide Bedingungen zutreffen, also das Garagentor offen ist, und die richtige Taste (in beliebieger Länge) gedrückt wurde, werden die nachfolgenden Aktionen ausgeführt:

* { fhem("set tor_sw off ;; set tor_sw on-for-timer 1 ;; set Einfahrt_AUF off") } }

FHEM soll nacheinander ausführen:

* set tor_sw off

tor_sw auschalten. Dies ist streng genommen nicht erforderlich, da tor_sw nach Ende der Aktion immer auf OFF stehen sollte. Sollte allerdings aus irgendeinem Grunde tor_sw doch auf ON stehen, hat das nachfolgende kurze Einschalten zur Simulation eines Tastendrucks am Garagentor keine Wirkung. Das vorherige Ausschalten erhöht also die Zuverlässigkeit der Aktion und fängt fehlerhafte oder unklare Zustände und Störungen ab.

* set tor_sw on-for-timer 1

der Aktor tor_sw soll er für eine Sekunde einschalten und dann wieder auschalten. Dies simuliert einen kurzen Tastendruck.

* set Einfahrt_AUF off

Im ganzen "Einfahrt_ZU" Skript wird "Einfahrt_ZU" zwar unter bestimten Bedingungen eingeschaltet (und damit die oben beschriebnen Aktionen ausgeführt) aber nie AUSgeschaltet. Das Script steht also im Webinterface auch nach Ausführung der Aktionen auf ON. Dies hat den Sinn, dass man am Webinterface am Schaltzustand des Scriptes den Zustand des Garagentors erkennen kann. Die Zustandsanzeige von "Einfahrt_ZU" (dargestellt durch eine kleine Glühbirne) leuchtet, wenn das Skript abgelaufen und das Tor somit zu ist. Analog leuchtet die Anzeige des Scripts "Einfahrt_AUF" wenn das Tor zuletzt geöffnet wurde. Damit nicht nach jeweils einer Betätigung beide Scripte im Webinterface beide Glühbirnen leuchten, schalten die Scripte sich gegenseitig aus. "set Einfahrt_AUF off" dient also dazu, nachdem das Tor geschlossen wurde, die Anzeige von "Einfahrt_AUF" auszuschalten. Dies ist eine rein optische Massnahme: Der Schaltzustand von "Einfahrt_AUF" und "Einfahrt_ZU" gibt nur die letzte Betätigung wieder, nicht den tatsächlichen Zustand des Tores. In der Praxis stimmt dies aber überein. Wenn jedoch z.b. jemand das Tor manuell öffnet, stimmt die Anzeige nicht mehr. Die Ausführung von Einfahrt_AUF / Einfahrt_ZU hängt aber nicht von dieser Anzeige ab, sondern prüft den Türkontakt. Dadurch ist die eigentliche Funktion der Scripte nicht gestört.

== Vorteile der besprochenen Konfiguration: ==
* das Tor kann mit Weboberfläche und Fernbedienung eindeutig auf oder zu gemacht werden, obwohl der Torantrieb selber nur toggelt.
* der Zustand des Tores muss nicht bekannt sein. Wenn man das Tor öffnen will, genügt es, auf Einfahrt_AUF zu drücken. Wenn das Tor schon auf ist passiert nichts, ansonsten wird es geöffnet.
* Manuelle Eingriffe am Garagentor selbst behindern die Schaltung nicht.
* der Zustand des Tores lässt sich in der Regel am Schaltzustand der Aktionen im Webinterface feststellen. Dadurch ist es nicht zwingend, den Türkontakt dem selben Raum zuzuordnen (obwohl es in diesem Beispiel so gemacht wurde)
* Fehlbedienungen an der Fernbedienung (falsche Taste, zu lange gedrückt) werden abgefangen (dies ist insbesondere ein Vorteil gegenüber der Lösung, mit einer Fernbedienung den FS20 Aktor direkt anzusprechen, in dem ein Timer programmiert wurde. Das Auslösen des Dim-Befehles deaktiviert nämlich FS20 Timer.)
== Nachteile der besprochenen Konfiguration: ==
* <nowiki> der Einsatz des [[FHT80TF]]. </nowiki>
* belegt zwei Adressen und damit zwei Tastenpaare auf einer Fernbedienung. Ein Umschreiben auf ein Tastenpaar wäre aber möglich.

S555TH

2013-05-10T20:52:40Z

Generix: Die Seite wurde neu angelegt: „= Temperatur-/Feuchte-Außensensor = Der batteriebetriebene (2x Mignon) Außensensor S555TH misst die gegenwärtigen Temperatur- und Luftfeuchtigkeitswerte und…“

= Temperatur-/Feuchte-Außensensor =
Der batteriebetriebene (2x Mignon) Außensensor S555TH misst die gegenwärtigen Temperatur- und Luftfeuchtigkeitswerte und sendet sie per Funk. So lassen sich auch abgelegene Orte wie Gewächshäuser oder Weinkeller komfortabel zentral überwachen.
''Dieser Sensor scheint leider nicht mehr verfügbar zu sein.''Er wurde von Conrad vertrieben und ist baugleich mit [[S300TH]] von ELV.

== Lieferumfang ==
* Temperatur-/Feuchte-Außensensor
* Bedienungsanleitung
== Highlights ==
* 868-MHz-Funkübertragung bis 100m
* Misst Temperatur und Luftfeuchte
* Passend für Wetterstationen [/w/index.php?title=WS_555&action=edit&redlink=1 WS 555] und [/w/index.php?title=WS_222&action=edit&redlink=1 WS 222]
* Ideal für Gewächshäuser, Wintergärten und Weinkeller
* <nowiki> Der Sender kann über [[CUL]] empfangen werden. </nowiki>
* <nowiki> Siehe [[FHEM Command Reference]] unter CUL_WS </nowiki>
* Werte werden alle 3 Minuten gesendet
== Hinweise zum Betrieb mit FHEM ==
Definition in fhem.cfg:

<nowiki>define <name> CUL_WS <code> [corr1,corr2]</nowiki>
* '''<code>''' ist die Einstellung die innerhalb des Sensors durchgeführt werden muss um die einzelnen Sensoren zu unterscheiden. Es können bis zu 8 Sensoren genutzt werden.
* '''[corr1,corr2]''' Hier können Korekturfaktoren eingeben werden um beim Einsatz mehrerer Sensoren alle Sensoren zu kalibrieren.
** corr1: Korektur des Temperatur Sensors
** corr2: Korektur des Feuchte Sensors
</li></ul>
== Bekannte Probleme ==
Bei einzelnen Produktionsreihen ist es anscheinend nicht möglich, mit den DIP Switches eine andere Adresse als 5 (Voreinstellung) einzustellen. D.H. egal welche Stellung die DIP-Switche haben, der Sensor sendet immer auf Adresse 5.

== Sonstiges ==
Das Geräte ist baugleich mit dem ELV [[S300TH]] Sensor.

S300TH

2013-05-10T20:52:32Z

Generix: Die Seite wurde neu angelegt: „= Temperatur-/Feuchte-Außensensor = Der batteriebetriebene (2x Mignon) Außensensor S 300 TH von eQ-3 (ELV) misst die gegenwärtigen Temperatur- und Luftfeuch…“

= Temperatur-/Feuchte-Außensensor =
Der batteriebetriebene (2x Mignon) Außensensor S 300 TH von eQ-3 (ELV) misst die gegenwärtigen Temperatur- und Luftfeuchtigkeitswerte und sendet sie per Funk.

== Lieferumfang ==
* Funk-Temperatur- und -Luftfeuchtesensor mit Universal-Aufstell- und -Montagefuß
* Bedienungsanleitung
== Highlights ==
* Passend für Wetterstationen ELV WS 200/300 und ELV WS 300 PC oder Empfangsmodule USB-WDE1 und IPWE 1
* <nowiki> Der Sender kann über [[CUL]] empfangen werden. </nowiki>
* <nowiki> Siehe [[FHEM Command Reference]] unter CUL_WS </nowiki>
== Technische Daten ==
* Temperaturbereich: -20°C bis +55°C
** Auflösung: 0,1˚ C
** Genauigkeit: ±0,8˚ C
</li><li> Luftfeuchtebereich: 5 bis 95% rel. Luftfeuchte
* Auflösung: 0,1%
* Genauigkeit: ±5%
</li><li> Spannungsversorgung: 2 x 1,5 V, LR6 (AA/Mignon)
</li><li> Abmessungen (B x H x T, Sensor): 38 x 138 x 20 mm, Tiefe mit Montagefuß 50 mm
</li><li> Sendefrequenz: 868,35 MHz
* Freifeld-Reichweite: 100 m
* Datenübertragungszyklus: 3 Min.
</li></ul>
== Hinweise zum Betrieb mit FHEM ==
Definition in fhem.cfg:

<nowiki>define <name> CUL_WS <code> [corr1,corr2]</nowiki>
* '''<code>''' ist die Einstellung die innerhalb des Sensors (DIP Switche unter dem Batteriedeckel) durchgeführt werden muss, um die einzelnen Sensoren zu unterscheiden. Es können bis zu 8 Sensoren genutzt werden. Default ist Adresse 5 (Beide DIP-Switches in mittlerer Postition)
* '''[corr1,corr2]''' Hier können Korekturfaktoren eingeben werden, um die Sensoren zu kalibrieren.
** corr1: Korektur des Temperatur Sensors
** corr2: Korektur des Feuchte Sensors
</li></ul>
== Log-Auszug ==
S300TH senden ihre Werte in sehr unregelmäßigen Abständen.

<nowiki>2012-10-15_17:30:01 ez_Aussensensor T: 9 H: 70.3
2012-10-15_17:47:44 ez_Aussensensor T: 8.9 H: 70.2
2012-10-15_17:50:41 ez_Aussensensor T: 9 H: 70.3
2012-10-15_17:56:35 ez_Aussensensor T: 8.9 H: 70.2
2012-10-15_18:08:23 ez_Aussensensor T: 8.8 H: 70.2
2012-10-15_18:40:50 ez_Aussensensor T: 8.6 H: 70.6
2012-10-15_18:43:47 ez_Aussensensor T: 8.6 H: 70.6
2012-10-15_18:49:41 ez_Aussensensor T: 8.5 H: 70.5
2012-10-15_18:52:38 ez_Aussensensor T: 8.6 H: 70.6
2012-10-15_18:55:35 ez_Aussensensor T: 8.5 H: 70.5
2012-10-15_19:01:29 ez_Aussensensor T: 8.5 H: 70.5
2012-10-15_19:13:17 ez_Aussensensor T: 8.4 H: 70.9</nowiki>

== Bekannte Probleme ==
Bei einzelnen Produktionsreihen ist es anscheinend nicht möglich, mit den DIP Switches eine andere Adresse als 5 (Voreinstellung) einzustellen. D.H. egal welche Stellung die DIP-Switche haben, der Sensor sendet immer auf Adresse 5.

== Sonstiges ==
Das Geräte ist baugleich mit dem Conrad [[S555TH]] Sensor, der allerdings inzwischen nicht mehr verkauft wird.

== Links ==
* Bedienungsanleitung bei ELV <nowiki>[http://www.elv-downloads.de/service/manuals_hw/75702_S300TH_UM_G_eQ_3.pdf PDF]</nowiki>

RSL 2-Draht Einbauschalter

2013-05-10T20:52:19Z

Generix: Die Seite wurde neu angelegt: „Conrad Funk-Einbauschalter 2 Draht RSL (Intertechno kompatibel), zum Einbau in Montagedosen auch ohne Nulleiter und unter Verwendung des normalen Schalters. ==…“

Conrad Funk-Einbauschalter 2 Draht RSL (Intertechno kompatibel), zum Einbau in Montagedosen auch ohne Nulleiter und unter Verwendung des normalen Schalters.
== Eigenschaften ==
Der Conrad Funk-Einbauschalter 2 Draht hat als wesentlichen Vorteil, dass er nur mit Phase betrieben werden kann. In vielen Installationen befindet sich in der Unterputzwanddose für den Lichtschalter kein Nullleiter, sodass die üblichen FS20 oder HM Unterputzschalter nicht verwendet werden können. In der klassischen Elektroinstallation wird in der Wandose nur die Phase geschaltet und der Rückleiter auf anderem Wege zur Lichtfassung geführt. Der Conrad Funk-Einbauschalter 2 Draht benötigt tatsächlich nur die ankommende und abgehende (geschaltete) Phase. Er bezieht seine Stromversorgung vermutlich aus den Potentialunterschieden der beiden Phasenstränge auch im ausgeschaltetem Zustand, hierbei wird wahrscheinlich das Neutralleiterpotential durch den zu schaltenden Verbraucher genutzt. Vermutlich aus diesem Grunde kann der Schalter nicht verwendet werden, wenn der zu schaltende Verbraucher eine Leuchtstoffröhre ist.

Überdies benötigt der Conrad Funk-Einbauschalter 2 Draht keinen Taster zur Vor-Ort-Betätigung, sondern die 2 herausgeführten Schaltdrähte können mittels des vorher verbauten Schalters aus einem normalen Schalterprogramm betrieben werden. Der Schalter wird hierbei wie ein Toggle verwendet. D.H. egal welche Stellung der Schalter hat, der Conrad Funk-Einbauschalter 2 Draht kann vollständig per Funk geschaltet werden, der lokale mechanische Schalter ändert bei jeder Betätigung den Schaltzustand.

Vorteile des Conrad Funk-Einbauschalter 2 Draht gegenüber FS20 und HM Unterputzshaltern wie [[FS20 SU Unterputz-Funk-Schalter]]

* benötigt nur Phase zur Stromversorgung
* dünner als FS20 Unterputzschalter, daher leichter auch hinter dem normalen Lichtschalter einbaubar.
* benötigt keinen Taster, sondern kann mit (vorhandenem) Schalter betrieben werden.
* RSL Funk, also kompatibel mit Intertechno 433 Mhz.
== Hinweise zum Betrieb mit FHEM ==
Conrad Funk-Einbauschalter 2 Draht hat keine Kodierschalter, sondern muss angelernt werden. Da dazu der gewünschte Intertechnokanal 3 Sekunden lang senden muss, ist ein Anlernen mit FHEM nicht möglich, da FHEM ununterbrochenes senden nicht beherrscht. Der Schalter kann aber leicht mit einer gängigen Intertechno Fernbedienung wie z.b. einer YCT-100 angelernt werden. Einmal angelernt, ist eine Schaltung per FHEM kein Problem.

== Bekannte Probleme ==
Die Schaltleistung des Conrad Funk-Einbauschalter ist mit 300 Watt ohmsche Last und 100 Watt induktiv deutlich geringer als die anderer Produkte, für Licht aber völlig ausreichend.
Nicht geeignet wenn im zu schaltetenden Stromkreis nur Leuchtstoffröhren zu schalten sind.

== Links ==

Rolladensteuerung mit FS20SM8

2013-05-10T20:52:17Z

Generix: Die Seite wurde neu angelegt: „== Aufgabe: == Steuerung von Rolladen, die über zwei externe Taster bedient werden können. Die hier beschriebene Lösung wurde für einen Lott/Uniroll-Gurtw…“

== Aufgabe: ==
Steuerung von Rolladen, die über zwei externe Taster bedient werden können.

Die hier beschriebene Lösung wurde für einen Lott/Uniroll-Gurtwickler entwickelt. Dieser kann über zwei Taster, die am Pfostenstecker des Sonnensensors angeschlossen werden, mit einem Tastendruck von 500 bis 1000ms Dauer geschaltet werden. Ein zweiter Tastendruck stoppt den Vorgang.
Da die Anschlussbelegung nicht direkt auf der Lott/Uniroll-Webseite zur Verfügung steht, bitte ich darum, diese von der dortigen Hotline zu erfragen.

== Voraussetzungen: ==
Für dieses Projekt ist zunächst etwas Bastelarbeit erforderlich. Benötigt werden ein FS20SM8, je 2 Relais und 2 Freilaufdioden pro Rolladen, ein Gehäuse und ein Netzteil. Ggf. kommen Steckverbinder nach Belieben für den Anschluss des Kabels zum Gurtwickler hinzu.
Der FS20SM8 kann mit 3V oder zwischen 5V und 12V betrieben werden. Ich habe ein altes 5V-Gleichspannungsnetzteil und je 2 5V-Subminiaturralais verbaut.
Die Schaltung kann schnell auf einer Loch- oder Streifenrasterplatine aufgebaut werden. Wie die Relais und Freilaufdioden angeschlossen werden, ist in der Bedienungsanleitung des FS20SM8 beschrieben.
Die Relais erzeugen bei der unten beschreibenen Ansteuerung den benötigten Tastendruck.

== Umsetzung: ==
Die Steuerung wird hier beispielhaft für ein Rollo beschrieben.
Es werden 2 Ausgänge des FS20SM8 als Devices (1x für "Ab" und 1x für "Auf") in fhem angelegt. Der benötigte Schaltimpuls wird mit "set rollo.xxx on-for-timer 0.5" erzeugt. Mit eventMap wird der Befehl nach "Ab" bzw. "Auf" umbenannt. Im Webinterface wird jeweils nur ein Schaltzustand mit webCmd "Ab" bzw. "Auf" angezeigt.
Damit beide Schaltzustände in einer Zeile angezeigt werden, ist ein FS20-Dummy-Device erforderlich. Hier können zusätzlich eine oder mehrere Zwischenstufen (z.B. "Ab80") definiert werden.
Zur Steuerung des Dummy-Devices wird ein Notify eingerichtet, welches auf die Eingaben reagiert.

== fhem.cfg: ==
Schalte Relais am Ausgang 5 des FS20SM8 zum Rollo-Schließen für 0,5 Sekunden ein:

<nowiki>define sm8.5 FS20 <housecode> <button>
attr sm8.5 comment Rollo xxx Ab
attr sm8.5 eventMap /on-for-timer 0.5:Ab/
attr sm8.5 model fs20sm8
attr sm8.5 room hidden
attr sm8.5 webCmd Ab
define FileLog_sm8.5 FileLog ./log/sm8.5-%Y.log sm8.5
attr FileLog_sm8.5 logtype text
attr FileLog_sm8.5 room hidden</nowiki>
Schalte Relais am Ausgang 6 des FS20SM8 zum Rollo-Öffnen für 0,5 Sekunden ein:

<nowiki>define sm8.6 FS20 <housecode> <button>
attr sm8.6 comment Rollo xxx Auf
attr sm8.6 eventMap /on-for-timer 0.5:Auf/
attr sm8.6 model fs20sm8
attr sm8.6 room hidden
attr sm8.6 webCmd Auf
define FileLog_sm8.6 FileLog ./log/sm8.6-%Y.log sm8.6
attr FileLog_sm8.6 logtype text
attr FileLog_sm8.6 room hidden</nowiki>

FS20-Dummy-Device für das Webinterface:

<nowiki>define rollo.xxx FS20 <housecode> <button>
attr rollo.xxx comment Rollo xxx
attr rollo.xxx dummy 1
attr rollo.xxx eventMap /on-for-timer 15:Ab80/off:Ab/on:Auf/
attr rollo.xxx model dummySimple
attr rollo.xxx room FS20
attr rollo.xxx webCmd Auf:Ab80:Ab
define FileLog_rollo.xxx FileLog ./log/rollo.xxx-%Y.log rollo.xxx
attr FileLog_rollo.xxx logtype text
attr FileLog_rollo.xxx room FS20</nowiki>

Notify zur Reaktion auf die Eingabe im Webinterface:

<nowiki>define rollo.xxx.ntfy notify rollo.xxx:.* {\
if('%' eq 'Ab') {\
fhem 'set sm8.5 Ab';;\
fhem 'setstate rollo.xxx Ab';;\
} elsif('%' eq 'Auf') {\
fhem 'set sm8.6 Auf';;\
fhem 'setstate rollo.xxx Auf';;\
} else {\
if(OldValue('rollo.xxx') eq 'Auf') {\
fhem 'set sm8.5 Ab';;\
fhem 'define rk80 at +00:00:15 set sm8.5 Ab';;\
fhem 'setstate rollo.xxx Ab80';;\
}\
} \
}</nowiki>

Steuerung mit Sonnenauf-/untergang:

Öffnet Rollo bei Sonnenaufgang aber nicht vor 7:00 Uhr

<nowiki>define Rollo.hoch at *{sunrise(0,'07:00',)} set rollo.xxx Auf</nowiki>
Schließt Rollo 15 Minuten vor Sonnenuntergang:

<nowiki>define Rollo.runter at *{sunset(-900)} set rollo.xxx Ab</nowiki>

== Erläuterungen ==
Die "else"-Anweisung im Notify ist für eine Beschattungssteuerung gedacht. Dazu werden 2 Tastendrücke im Abstand von 15 Sekunden ausgeführt, um das Rollo ca 80% herunterzufahren. Weitere Zwischenstellungen könnten mit elseif eingefügt werden. Der Wert von 15 Sekunden in der Anweisung "fhem 'define rk80 at +00:00:15 set sm8.5 Ab';;" muss ggf. an die eigenen Bedürfnisse angepasst werden.

Im Artikel [http://fhemwiki.de/wiki/Rolladensteuerung_mit_fs20rsu_und_fs20bs http://fhemwiki.de/wiki/Rolladensteuerung_mit_fs20rsu_und_fs20bs] ist eine Beschattungssteuerung beschrieben. Wer beide Arten von Rollos gleichzeitig schalten möchte, braucht nur "rollo.xxx" in die Zeile "fhem 'set rollo.wz Ab80';;" einzufügen.

Icons für das Webinterface können ebenso von diesem Projekt genommen werden.

Rolladensteuerung mit fs20rsu und fs20bs

2013-05-10T20:52:16Z

Generix: Die Seite wurde neu angelegt: „Die '''Beschattungssteuerung'''FS20bs dient dazu, Rolläden bei Sonne herunter- und bei Schatten heraufzufahren. Wenn sie mit einem FS20-Rolladenschalter (z.B.…“

Die '''Beschattungssteuerung'''FS20bs dient dazu, Rolläden bei Sonne herunter- und bei Schatten heraufzufahren. Wenn sie mit einem FS20-Rolladenschalter (z.B. [[FS20RSU" class="mw-redirect]]) gepairt ist, ist eine manuelle Steuerung nur begrenzt möglich.

Meine Lösung sieht so aus:

FS20bs und FS20rsu sind als Devices im FHEM angelegt, aber nicht miteinander gepairt. Die FS20bs wird im Mode 2 betrieben. Sie liefert dann beim Wechsel von dunkel nach hell ein "off 2.5" und beim Wechsel von hell nach dunkel ein "on 2". Diese Werte werden mit einem CUL empfangen und mit "eventMap /off 2.5:hell/on 2:dunkel/" wegen der enthaltenen Leerzeichen in "hell" bzw. "dunkel" umgewandelt. Dazu habe ich mir 2 Icons gebastelt, die statt der Glühlampen im Webinterface angezeigt werden.

Per notify wird der Rolladen mit FS20rsu bei Sonne mit "set rollo.wz off-for-timer 12" so weit heruntergefahren, dass der Sensor noch von der Sonne beschienen wird. Mit "attr fs20bs webCmd xxx" wird nur der aktuelle Status im Webinterface angezeigt. Für das Rollo habe ich Icons für die Zustände "Auf", "Ab80" und "Ab" erstellt.

Morgens und abends wird der Rolladen mit sunrise bzw. sunset gesteuert.

Die Beschattungssteuerung wird nur ausgeführt, wenn der Rolladen in der "Auf"-Stellung ist.

Hier ist der zugehörige Ausschnitt aus meiner fhem.cfg:

Definition des FS20rsu:

<nowiki>define rollo.wz FS20 <housecode> <button>
attr rollo.wz eventMap /off-for-timer 12:Ab80/off:Ab/on:Auf/
attr rollo.wz model fs20rsu
attr rollo.wz room Wohnzimmer
attr rollo.wz webCmd Auf:Ab80:Ab</nowiki>
Definition des FS20bs:

<nowiki>define fs20bs FS20 <housecode> <button>
attr fs20bs comment Beschattungssteuerung on=dunkel off=hell
attr fs20bs dummy 1
attr fs20bs eventMap /off 2.5:hell/on 2:dunkel/
attr fs20bs model fs20bs
attr fs20bs room Wohnzimmer</nowiki>
Zeitsteuerung mit sunset und sunrise:

<nowiki>define Rollo.wz.runter at +*{sunset_rel()} set rollo.wz off
define Rollo.wz.hoch at +*{sunrise_rel(0,"07:00",)} set rollo.wz on</nowiki>
Beschattungssteuerung:

<nowiki>define rollo.wz.sonne notify fs20bs:* {\
if('%' !~ m/dunkel/) {\
if(Value('rollo.wz') eq 'Auf') {\
fhem 'set rollo.wz Ab80';;\
}\
} else { \
fhem 'set rollo.wz Auf';;\
} \
}</nowiki>
Hier sind die Icons:

<nowiki>dunkel:
[[File:/w/images/0/02/Fs20bs_dunkel.png|32px|link=/wiki/Datei:Fs20bs_dunkel.png|alt=Fs20bs dunkel.png]]hell:
[[File:/w/images/4/48/Fs20bs_hell.png|32px|link=/wiki/Datei:Fs20bs_hell.png|alt=Fs20bs hell.png]]Ab:
[[File:/w/images/d/da/Fs20bs_Ab.png|32px|link=/wiki/Datei:Fs20bs_Ab.png|alt=Fs20bs Ab.png]]Ab80:
[[File:/w/images/b/bd/Fs20bs_Ab80.png|32px|link=/wiki/Datei:Fs20bs_Ab80.png|alt=Fs20bs Ab80.png]]Auf:
[[File:/w/images/0/0a/Fs20bs_Auf.png|32px|link=/wiki/Datei:Fs20bs_Auf.png|alt=Fs20bs Auf.png]]</nowiki>
Zum Hochladen ins Wiki habe ich den Dateinamen "fs20bs_" vorangestellt, weil eine Datei bereits unter dem von mir verwendeten Namen existierte. Dieser Teil muss entfernt werden. Bitte Groß/Kleinschreibung beachten. Die Dateien gehören ins Verzeichnis /fhem/FHEM bzw. /fhem/www/pgm2 bei der neuen Verzeichnisstruktur.

Ich hoffe, dass auch andere etwas damit anfangen können, da die Steuerung nicht auf FS20-Aktoren beschränkt ist. Der Wert für "off-for-timer" muss natürlich auf die jeweilige Konfiguration angepasst werden. Verbesserungsvorschläge sind jederzeit willkommen.

Rolladensteuerung KNX ABB Aktor JRA S 4.230.5.1

2013-05-10T20:52:15Z

Generix: Die Seite wurde neu angelegt: „= Rolladensteuerung mit KNX ABB Aktor JRA S 4.230.5.1 = Hallo, ich versuch mal meine Erfahrung mit KNX (EIB) und der Rollosteuerung niederzuschreiben. Die Steu…“

= Rolladensteuerung mit KNX ABB Aktor JRA S 4.230.5.1 =
Hallo, ich versuch mal meine Erfahrung mit KNX (EIB) und der Rollosteuerung niederzuschreiben.
Die Steuerung funktioniert, die Position des Rollos wird in Prozent zurückgegeben.

Verwendet wird ein Aktor für KNX von ABB JRA S 4.230.5.1.
Dieser Aktor hat eine Fahrzeitermittlung und eine prozentuale Positionierung sowie 4 Preset Speicherplätze.
Der Aktor kann auch Jalousien ansteuern.

== Vorgehen ==
=== KNX Konfig ===
Ich habe fünf Gruppenadressen je Rollo angelegt.

<nowiki>0/0/10 = Auf/Ab
0/0/11 = Stop
0/0/12 = Preset 1 und 2 (Low und High Bit)
0/0/13 = Preset 3 und 4
0/0/17 = Status Höhe 0...255</nowiki>
=== fhem ===
<nowiki>define Rollo1 EIB 0/0/17 0/0/10 0/0/11 0/0/12 0/0/13
attr Rollo1 alias Rollo 1 Arbeitszimmer
attr Rollo1 model percent
attr Rollo1 eventMap /on g3:Stop/off g2:Auf/on g2:Ab/off g4:Pos1/on g4:Pos2/off g5:Pos3/on g5:Pos4
attr Rollo1 webCmd Ab:Stop:Auf:::Pos1:Pos2:Pos3:Pos4
attr Rollo1 room Rollos</nowiki>
[[File:/w/images/0/04/Rollo1.png|644px|link=/wiki/Datei:Rollo1.png|alt=Rollo1.png]]== Funktionsweise ==
Ich habe lange gebraucht bis ich die eventMap kapiert habe.

* gX (g1 ... g4) beziehen sich auf die EIB Adresse in der define Zeile (sollte mit anderen Systemen genauso funktionieren). Auf g1 kann verzichtet werden.
* Jeder Eintrag beginnt mit einem "/"

/on g3:Stop ==> An die EIB Adresse 3 (0.0.11) ein High Bit senden und das ganze als Stop bezeichnen (Ansicht)

Die webCmd sorgt für die Web-Darstellung im fhem.
Wie man gut sehen kann, beziehen sich die Schlüsselworte auf die eventMap.

Dadurch, dass die Rückgabeadresse (0/0/17) an erster Stelle steht, wird anstatt der Lampe ein Prozentwert ausgegeben.

= Anpassen des Moduls 10_EIB.pm um das Model percent255 =
(Danke an Ines)

Es gibt Aktoren die geben die Position von 0 bis 255 zurück. Damit das im fhem richtig angezeigt wird, muss das Modul 10_EIB.pm erweitert werden.
Es wird das Model percent255 hinzugefügt.

Das Model percent muss durch percent255 ersetzt werden.

<nowiki>attr Rollo1 model percent255</nowiki>
Anbei ein Diff-File:

das diff wird mit dem Tool Patch eingespielt.

cat 10_EIB_Percent255.diff |patch

<nowiki>--- /usr/src/fhem/FHEM/10_EIB.pm 2012-05-10 11:22:45.932001898 +0200
+++ /usr/share/fhem/FHEM/10_EIB.pm 2012-06-06 09:59:55.796006787 +0200
@@ -31,7 +31,8 @@

# 1-Octet unsigned value (handled as dpt7)
"dpt5" => {"CODE"=>"dpt7", "UNIT"=>""},
- "percent" => {"CODE"=>"dpt7", "UNIT"=>"%"},
+ "percent" => {"CODE"=>"dpt7", "UNIT"=>"%"},
+ "percent255" => {"ADJUSTMENT"=>"255", "CODE"=>"dpt7", "UNIT"=>"%"},

# 2-Octet unsigned Value (current, length, brightness)
"dpt7" => {"CODE"=>"dpt7", "UNIT"=>""},
@@ -346,14 +347,16 @@
my $code = $eib_dpttypes{"$model"}{"CODE"};
my $unit = $eib_dpttypes{"$model"}{"UNIT"};
my $transval = undef;
+ my $adjustment = $eib_dpttypes{"$model"}{"ADJUSTMENT"};

Log(4,"EIB parse $value for $name model: $model dpt: $code unit: $unit");
if ($code eq "dpt7")
{
my $fullval = hex($value);
- $transval = $fullval;
-
+ $transval = $fullval;
+ $transval = ($fullval / 2.55) if($adjustment eq "255");
+ $transval = sprintf("%.0f",$transval);
+
Log(5,"EIB $code parse $value = $fullval translated: $transval");

} elsif($code eq "dpt9")</nowiki>

RFR CUL und FHT80

2013-05-10T20:51:36Z

Generix: Die Seite wurde neu angelegt: „Der Einsatz eines FHT80b Devices kann jedoch zu Problemen führen, da hier das Timing entscheidend ist. == Herausforderungen der FHT Kommunikation an RFR …“

Der Einsatz eines [[FHT80b]] Devices kann jedoch zu Problemen führen, da hier das Timing entscheidend ist.

== Herausforderungen der FHT Kommunikation an RFR CULs ==
Die CUL/FHZ <-> FHT [[Maximal nutzbare Geräte]] ist sehr fragil, und braucht für die Übermittlung von N Werten etwa 5+N ungestörte Nachrichtenübermittlungen - abwechselnd von beiden Teilnehmer - mit der langsamen 1kHz Technik. Falls während dieser langen "Diskussion" eine Nachricht nicht klar empfangen wird, dann wird der gesamte Austausch in ca. 2 Minuten wiederholt.
Dies schränkt bereits im Normalbetrieb die Anzahl der [[Maximal nutzbare Geräte]] (insbesondere FHT80) deutlich ein.

Nur falls ein Austausch komplett abgearbeitet ist, kommt der nächste Austausch aus dem CUL Puffer (T02) dran.

Auf der anderen Seite ist die [[RFR CUL]] Übertragung, die erst auf eine Sendepause wartet, bevor auf 250kHz umgeschaltet wird und die Daten zwischen den CULs übertragen werden. Dem RFR Code ist aber nicht bekannt, dass eine FHT-Übertragung unterwegs ist. Er kann daher in kleinen Sendepausen während einer FHT Kommunikation umschalten, um in den Pausen die Kommunikation vom RFR zum CUL abzuwickeln. Dadurch kann es zu Verzögerungen bei der Kommunikation mit dem FHT80 kommen, die zum Abbruch führen. Die Kommunikation wird dann ca. 2 Minuten später wiederholt.
Solange keine Sendepause vorliegt, werden alle empfangenen Daten in einem 64 Byte grossen lokalen Puffer geschrieben.

== Lösung ab CULfw 1.45 ==
Seit Firmware Version 1.45 (2012-07-11) versucht das RFR jedoch eine laufende FHT Kommunikation zu erkennen und solange einen RFR Kommunikation zu unterbinden.

Im Detail:
RFR sendet erst, wenn "rf_isreceiving" 2-mal im Abstand von 24ms Stille meldet.

Seit Version 1.45 wurde die Prüfung erweitert.
"rf_isreceiving" prüft nun zusätzlich, ob das FHT Modul auf Daten wartet:
(fht80b_timeout != FHT_TIMER_DISABLED)
fht80b_timeout wird beim Empfang eines FHT Telegramms mit 41 (== 328ms)
initialisiert, auch wenn FHT in CUL deaktiviert ist.

Dadurch sollte erkannt werden, ob eine laufende FHT Communikation stattfindet, die nicht unterbrochen werden sollte.

== Lösungsansätze vor CULfw 1.45 ==
Es ist Erfahrungsgemäss durchaus möglich (auch mit Firmware vor 1.45), FHTs an einem RFR CUL zu betreiben, es wird jedoch häufiger zu Problemen mit Verbindungsabbrüchen kommen. Problematisch sind insbesondere längere Kommunikationen mit FHTs wie z.b. die Übertragung von Wochenprogrammen.

Besonders problematisch sind die diversen Methoden, die FHTs regelmässig zum Senden der Temperaturdaten zu bewegen. Bekanntermassen stellen die FHTs nach 5-10 Tagen das Übermitteln von Daten ein. Zum "Aufrischen" der Kommunikation werden verschiedene Tips gehandelt:

* 1. Methode: Täglich ein
<nowiki>define fht_report at +*06:00:00 set <name> report1 255 report2 255</nowiki>
abzusetzen. (Alternativ "refreshvalues", was die selbe Bedeutung hat). Dies erzeugt jedoch eine nicht unerhebliche Funklast und lange Kommunikationen, ca. 8 Nutznachrichtenübermittlungen (plus 5 Nachrichtenübermittlung bei der Kommunikationsanbahnung) zwischen FHT80 und dem CUL sind notwendig. Bei der Kommunikation mit einem RFR CUL ist die Wahrscheinlichkeit einer Störung hoch.

* 2. Methode: Jede Nacht mit
<nowiki>set ... time</nowiki>
die [[FHT: Datum und Zeit von fhem setzen lassen]] Dies kann bei vielen FHTs die als IOdev eine RFR CUL haben problematisch sein.

Eine Reduzierung der Funklast kann erreicht werden, in dem mittels report1/2 nur der tatsächliche Bitwert der benötigten Informationen angefordert werden, insbesondere das Wochenprogramm (report1 = 255) ändert sich idR. selten und wird meist nicht regelmässig benötigt.
Ausserdem kann es sinnvoll sein, die Werte nur alle 5 oder 7 Tage anzufordern (bzw die Uhr nur alle 5-7 Tage zu stellen), und für verschiedene FHTs zeitlich versetzt, um die Wahrscheinlickeit sich kreuzender Kommunikation zu reduzieren.

* 3. Methode: Einrichtung eines Watchdog ("Wachundes") mit
<nowiki>define wd_FHT1 watchdog FHT1:measured-temp.* 01:00 SAME set FHT1 time</nowiki>
Der Watchdog überprüft, ob die alle 15 Minute gesendeten Temperaturmeldungen eintreffen. Falls nicht setzt er die Uhrzeit des FHT um ihn so wieder zur Kommunikation anzuregen.