http://wiki.fhem.de/w/api.php?action=feedcontributions&feedformat=atom&user=GRZBRZFHEMWiki - Benutzerbeiträge [de]2026-05-01T12:32:02ZBenutzerbeiträgeMediaWiki 1.43.6http://wiki.fhem.de/w/index.php?title=ECMD&diff=33423ECMD2020-06-27T13:37:21Z<p>GRZBRZ: </p>
<hr />
<div>ECMD bedeutet "Ethersex Command"<ref>[http://www.ethersex.de/index.php/Main_Page_%28Deutsch%29 Ethersex.de]</ref> und ist laut FHEM-Dokumentation<br />
<br />
"Any physical device with request/response-like communication capabilities over a TCP connection"<ref>{{Link2CmdRef|Anker=ECMD|Label=FHEM Commandref}}</ref>,<br />
<br />
das heisst, irgendein physisches Gerät, welches request/response-artige Kommunikationsfähigkeiten aufweist, sei es über eine TCP-Verbindung (Netzwerk) oder eine serielle Schnittstelle.<br />
<br />
In FHEM sind enthalten:<br />
* Modul [[ECMD (Modul)|ECMD]] für die Bearbeitung physischer I/O-Schnittstellengeräte und<br />
* Modul [[ECMDDevice]] für einzelne logische Geräte, deren Kommunikation über ein ECMD-Gerät läuft<br />
<br />
==Beispiele & Links==<br />
<br />
=== Links ===<br />
Siehe {{Link2Forum|Topic= 60753 |Message=521462|LinkText=Thread im FHEM-Forum}}<br />
<br />
Siehe [[Radioaktivitätsmessung mit DIYGeigerCounter]]<br />
<br />
=== Beispiel DIY Sensor via HC-12 ===<br />
Ein BME280 Temperatur/Druck/Feuchte-Sensor liefert via eines HC-12 Pärchens seine Daten an der seriellen Schnittstelle eines RasPi ab. Der Sketch im Nano, an dem sowohl der BME280 als auch einer der HC-12 hängen, liefert alle 10 Minuten ein Datagramm ab und schickt seinen Wirt in den Tiefschlaf bis zum nächsten Datagramm, um mit den notwendigen Batterien über ein Jahr aushalten zu können.<br />
<br />
Das Datagramm hat die Form <br />
DevId T-3.45°C P995.31hPa H63.27%RH\r\n<br />
<br />
====== Klassendefinition ======<br />
Daraus werden die notwendigen Definitionen für eine Klassendefinition abgeleitet. Die z.B. unter '/opt/fhem/BME280.classdef' abgelegte Datei erhält den Inhalt<syntaxhighlight line="1"><br />
params devId<br />
reading temperature match "%devId[^\n]+\n"<br />
reading temperature postproc { /%devId[^T]+T([-+.,0-9]+).*/; $1 }<br />
reading airpressure match "%devId[^\n]+\n"<br />
reading airpressure postproc { /%devId[^P]+P([-+.,0-9]+).*/; $1 }<br />
reading humidity match "%devId[^\n]+\n"<br />
reading humidity postproc { /%devId[^H]+H([-+.,0-9]+).*/; $1 }<br />
state humidity<br />
</syntaxhighlight>Die regex für match ist in allen Zeilen gleich gestaltet. Alle Werte werden durch diese Vorgehensweise gleichzeitig und erst dann gelesen, wenn das gesamte Datagramm eingetroffen ist. Es ließe sich auch auf Teil-Strings abfragen, Konflikte bei mehreren Sensoren sind dann denkbar. <br />
<br />
Die letzte Zeile sorgt dafür, dass der state nur dann einen neuen Wert erhält, wenn (in diesem Fall) 'humidity' ein Update erfährt. Bei den gewählten regex trift das hier eigentlich für alle zu, aber da humidity der letzte übertragene Wert ist, ist die Wahl auf ihn gefallen. Außerdem steht nun nur ein Wert im state ohne einleitenden reading Namen, der wäre hier im Beispiel erwartungsgemäß 'humidity', was hier insofern irritiert, weil ja 3 Werte gelesen wurden und man sich unwillkürlich fragt, wo den die anderen geblieben sind. Zum state daher später unter Notify noch weiteres.<br />
<br />
====== Schnittstelle ======<br />
Sollte bereits eine ECMD Schnittstelle bestehen, kann nun die Definition hinzugefügt werden. Z.B. die ECMD Schnittstelle namens 'SerDevDef' erhält eine zusätzliche Klasse 'BME280' mit den Definitionen aus der vorher generierten Datei, Beispiel siehe oben.<syntaxhighlight><br />
set SerDevDef classdef BME280 /opt/fhem/BME280.classdef<br />
<br />
</syntaxhighlight>Ist noch keine ECMD Schnittstelle definiert, wird diese erstellt und gleich mit passenden Attributen versehen.<syntaxhighlight><br />
define SerDevDef ECMD serial /dev/ttyS0@9600<br />
set SerDevDef classdef BME280 /opt/fhem/BME280.classdef<br />
attr SerDevDef partial 2<br />
<br />
</syntaxhighlight>Die letzte Zeile ist für die serielle Schnittstelle gerade bei längeren Datagrammen ein Muss. Sie sorgt dafür, dass die kleineren Informationsbröckchen zu einer vollständigen Einheit werden. Kommt das nächste Päckchen innerhalb von (hier) 2 Sekunden, wird das neue Päckchen an die bereits gelesenen Daten angehängt, ansonsten startet eine neue Aufzeichnung beginnend mit dem Päckchen.<br />
<br />
Für den Start kann noch zur Erleichterung der Fehlersuche folgendes ergänzt werden<syntaxhighlight><br />
attr SerDevDef logTraffic 5<br />
attr SerDevDef verbose 5<br />
</syntaxhighlight>Rückstelllen dieser Attribute nicht vergessen, so ist's reichlich gesprächig und füllt schnell das Log !!!<br />
<br />
====== Device ======<br />
Damit ist alles vorbereitet den ECMD Device zu erstellen.<syntaxhighlight><br />
define BME280_42356 ECMDDevice BME280 42356<br />
attr BME280_42356 alias Gartenhaus<br />
attr BME280_42356 room Grundstück<br />
attr BME280_42356 IODev SerDevDef <br />
attr BME280_42356 userReadings airpressure_sealevel:humidity:.* { sprintf("%.2f", ReadingsVal("BME280_42356","pressure",0)*1.023);; }<br />
</syntaxhighlight>Der fragliche Sensor beginnt seine Datagramme immer mit '42356', das ist seine DevId, die über den Parameter 'devId' in der Klassendefinition (siehe oben) Eingang in die readings findet. Über 'BME280' wird die Klassendefinition festgelegt, über '42356' die devId. Sinnigerweise wird im Beispiel hier 'BME280_42356' als Devicename festgelegt, Systematik ist Trumpf.<br />
<br />
Die letzte Zeile macht aus dem vom Sensor gemessenen Luftdruck noch den auf NormalNull Bezogenen. Nicht jeder wohnt direkt am Meer und kann auf diesen Schritt verzichten. Ansonsten weichen die Werte des Sensors immer von der Wettervorhersage ab, je höher der Sensor, um so markanter. Das Beispiel hier gilt für ca. 180m üNN. Die Erzeugung des Wertes für "airpressure_sealevel" ist übrigens an den Event "humidity geknüpft, sonst hat man im Event-Log in diesem Fall 3 Einträge, nämlich den beim Temperatur-, beim Druck- und beim Feuchte-Event (siehe auch beim folgenden Notify und dem linken Teil des Beispiel-Plots weiter unten).<br />
<br />
====== Notify ======<br />
Da der state nach einer Übermittlung aufgrund der Festlegungen aus der Klassendefinition nun nur den Wert der Luftfeuchte enthält, ist es hilfreich ein 'notify' für eine gefälligere Darstellung zu definieren.<syntaxhighlight><br />
define ECMDDevState notify BME280_42356:humidity:.* { Log 1, "$NAME has new values";;sleep 1;;fhem "setstate BME280_42356"." T:".ReadingsVal("BME280_42356","temperature",0)." P:".ReadingsVal("BME280_42356","airpressure_sealevel",0)." H:".ReadingsVal("BME280_42356","humidity",0) }<br />
</syntaxhighlight>Für die Übersicht zerlegt:<syntaxhighlight lang="perl" line="1" start="1"><br />
define ECMDDevState notify BME280_42356:humidity:.* <br />
{<br />
Log 1, "$NAME has new values";;<br />
sleep 1;;<br />
fhem "setstate BME280_42356".<br />
" T:".ReadingsVal("BME280_42356","temperature",0).<br />
" P:".ReadingsVal("BME280_42356","airpressure_sealevel",0).<br />
" H:".ReadingsVal("BME280_42356","humidity",0)<br />
}<br />
<br />
</syntaxhighlight>&#x2460; 'ECMDDevState' wird immer dann benachrichtigt und ausgeführt, wenn der Device 'BME280_42356' ein reading 'humidity' mit einem beliebigen (.*) Wert hat. &#x2462; Dies wird zunächst im Log vermerkt und &#x2463; als nächstes ein wenig gewartet, damit eine Änderung des state auf jeden Fall nach dem Befüllen des state durch das humidity reading stattfindet und auch der Luftdruck fertig berechnet ist. Dann wird &#x2464; der state mit einer Verkettung der gerade gelesenen bzw. berechneten Daten aller Werte &#x2465;,&#x2466;,&#x2467; versorgt.<br />
<br />
====== Log HISTORY ======<br />
Die Werte sammeln sich nun im Log. Dort haben die Werte ebenfalls eine Einheit, in diesem Fall "°C" für reading-Namen, die mit "temperature" beginnen und "%" für reading-Namen, die mit "humidity" beginnen. Andere Einheiten oder andere reading-Namen lassen sich entweder über ein Attribut in der Log-Definition<syntaxhighlight><br />
attr myDbLog valueFn {<br />
if ($DEVICE eq "BME280_42356"){<br />
if ($READING=~ m(^airpressure)){<br />
$UNIT = "hPa";<br />
}<br />
if ($READING=~ m(^pressure)){<br />
$UNIT = "Pa";<br />
}<br />
}<br />
}<br />
</syntaxhighlight>oder direkt im Device ergänzen bzw. beeinflussen.<syntaxhighlight><br />
attr BME280_42356 DbLogValueFn {<br />
if ($READING=~ m(^airpressure)){<br />
$UNIT = "hPa";<br />
}<br />
if ($READING=~ m(^pressure)){<br />
$UNIT = "Pa";<br />
}<br />
}<br />
</syntaxhighlight>Damit lassen sich freilich auch ungewöhnliche Einheiten festlegen, Blutdruck wird z.B. in "mmHg" gemessen.<br />
<br />
====== Weiterführend ======<br />
Abschließend soll noch ein Plot der Messwerte gemacht werden, eine Kurve liest sich leichter. Als Erstes wird eine Datei z.B. '/opt/fhem/www/gplot/SVG_BME280_42356.gplot' mit folgendem Inhalt erstellt, der anzuzeigenden Linien und Beschriftungen des Plots beschreibt.<syntaxhighlight><br />
set terminal png transparent size <SIZE> crop<br />
set output '<OUT>.png'<br />
set xdata time<br />
set timefmt "%Y-%m-%d_%H:%M:%S"<br />
set xlabel "Verlauf"<br />
set title 'Wetter'<br />
set ylabel "Temperatur"<br />
set y2label "Luftdruck"<br />
#myDbLog BME280_42356:temperature:0:<br />
#myDbLog BME280_42356:airpressure_sealevel:0::$val=$val>1100?1100:$val<800?800:$val<br />
#myDbLog BME280_42356:humidity:0::$val=$val/2-10<br />
plot "<IN>" using 1:2 axes x1y1 title 'Temperatur' ls l0 lw 1 with lines,\<br />
"<IN>" using 1:2 axes x1y2 title 'Luftdruck' ls l1 lw 1 with lines,\<br />
"<IN>" using 1:2 axes x1y1 title 'Feuchte' ls l2 lw 1 with lines<br />
</syntaxhighlight>Dabei wird der Luftdruck auf einen plausiblen Bereich eingegrenzt, Drücke außerhalb dieses Bereichs hat es noch nicht gegeben auf diesem Erdball (:$val=$val>1100?1100:$val<800?800:$val). Der Wert der Feuchte wird dem zu erwartenden Temperaturbereich (-10 bis 40) angeglichen, das ergibt eine schönere Kurve (:$val=$val/2-10). Eine Y-Achse für die Feuchte wäre ja die dritte Y-Achse, die haben wir also nicht. Also landet 100% Feuchte bei 40°C und 0% Feuchte bei -10°C.<br />
<br />
Dann wird der Plot definiert. In diesem Fall mit den Daten aus DbLog, für FileLog muss geringfügig angepaßt werden. Dann fehlten freilich auch die FileLog -Definitionen für 'BME280_42356'.<syntaxhighlight><br />
defmod SVG_BME280_42356 SVG myDbLog:SVG_BME280_42356:HISTORY<br />
</syntaxhighlight>Der Term 'SVG_BME280_42356' liest dabei die Definitionen aus der vorher angelegten Datei 'SVG_BME280_42356.gplot'.<br />
<br />
[[Datei:GHplotECMD.png|rahmenlos|1197x1197px]]<br />
<br />
====== FIN ======<br />
Viel Spaß bei den eigenen Experimenten.<br />
<br />
==Quellen==<br />
<references /><br />
<br />
[[Kategorie:Glossary]]</div>GRZBRZhttp://wiki.fhem.de/w/index.php?title=ECMD&diff=33422ECMD2020-06-25T14:47:37Z<p>GRZBRZ: </p>
<hr />
<div>ECMD bedeutet "Ethersex Command"<ref>[http://www.ethersex.de/index.php/Main_Page_%28Deutsch%29 Ethersex.de]</ref> und ist laut FHEM-Dokumentation<br />
"Any physical device with request/response-like communication capabilities over a TCP connection"<ref>{{Link2CmdRef|Anker=ECMD|Label=FHEM Commandref}}</ref>, das heisst, irgendein physisches Gerät, welches request/response-artige Kommunikationsfähigkeiten aufweist, sei es über eine TCP-Verbindung (Netzwerk) oder eine serielle Schnittstelle.<br />
<br />
In FHEM sind enthalten:<br />
* Modul [[ECMD (Modul)|ECMD]] für die Bearbeitung physischer I/O-Schnittstellengeräte und<br />
* Modul [[ECMDDevice]] für einzelne logische Geräte, deren Kommunikation über ein ECMD-Gerät läuft<br />
<br />
==Beispiele & Links==<br />
<br />
=== Links ===<br />
Siehe {{Link2Forum|Topic= 60753 |Message=521462|LinkText=Thread im FHEM-Forum}}<br />
<br />
Siehe [[Radioaktivitätsmessung mit DIYGeigerCounter]]<br />
<br />
=== DIY Sensor via HC-12 ===<br />
Ein BME280 Temperatur/Druck/Feuchte-Sensor liefert via eines HC-12 Pärchens seine Daten an der seriellen Schnittstelle eines RasPi ab. Der Sketch im Nano, an dem sowohl der BME280 als auch einer der HC-12 hängen, liefert alle 10 Minuten ein Datagramm ab und schickt seinen Wirt in den Tiefschlaf bis zum nächsten Datagramm, um mit den notwendigen Batterien über ein Jahr aushalten zu können.<br />
<br />
Das Datagramm hat die Form <br />
DevId T-3.45°C P995.31hPa H63.27%RH\r\n<br />
<br />
====== Klassendefinition ======<br />
Daraus werden die notwendigen Definitionen für eine Klassendefinition abgeleitet. Die z.B. unter '/opt/fhem/BME280.classdef' abgelegte Datei erhält den Inhalt<syntaxhighlight line="1"><br />
params devId<br />
reading temperature match "%devId\sT([-+.,0-9]+)\S+\sP([-+.,0-9]+)\S+\sH([-+.,0-9]+)\S+\r?\n"<br />
reading temperature postproc { /%devId\sT([-+.,0-9]+)\S+\sP([-+.,0-9]+)\S+\sH([-+.,0-9]+)\S+\r?\n/; $1 }<br />
reading airpressure match "%devId\sT([-+.,0-9]+)\S+\sP([-+.,0-9]+)\S+\sH([-+.,0-9]+)\S+\r?\n"<br />
reading airpressure postproc { /%devId\sT([-+.,0-9]+)\S+\sP([-+.,0-9]+)\S+\sH([-+.,0-9]+)\S+\r?\n/; $2 }<br />
reading humidity match "%devId\sT([-+.,0-9]+)\S+\sP([-+.,0-9]+)\S+\sH([-+.,0-9]+)\S+\r?\n"<br />
reading humidity postproc { /%devId\sT([-+.,0-9]+)\S+\sP([-+.,0-9]+)\S+\sH([-+.,0-9]+)\S+\r?\n/; $3 }<br />
state humidity<br />
</syntaxhighlight>Die regex ist in allen Zeilen der Einfachheit zuliebe gleich gehalten, bei den match könnte man freilich die Klammern löschen und bei den postproc auf ein Paar reduzieren und $_ gleichmäßig mit $1 befüllen. Geschmackssache. Alle Werte werden durch diese Vorgehensweise gleichzeitig und erst dann gelesen, wenn das gesamte Datagramm eingetroffen ist. Es ließe sich auch auf Teil-Strings abfragen, Konflikte bei mehreren Sensoren sind dann denkbar.<br />
<br />
Die letzte Zeile sorgt dafür, dass der state nur dann einen neuen Wert erhält, wenn (in diesem Fall) 'humidity' ein Update erfährt. Bei den gewählten regex trift das hier eigentlich für alle zu, aber da humidity der letzte übertragene Wert ist, ist die Wahl auf ihn gefallen. Außerdem steht nun nur ein Wert im state ohne einleitenden reading Namen, der wäre hier im Beispiel erwartungsgemäß 'humidity', was hier insofern irritiert, weil ja 3 Werte gelesen wurden und man sich unwillkürlich fragt, wo den die anderen geblieben sind. Zum state daher später unter Notify noch weiteres.<br />
<br />
====== Schnittstelle ======<br />
Sollte bereits eine ECMD Schnittstelle bestehen, kann nun die Definition hinzugefügt werden. Z.B. die ECMD Schnittstelle namens 'SerDevDef' erhält eine zusätzliche Klasse 'BME280' mit den Definitionen aus der vorher generierten Datei, Beispiel siehe oben.<syntaxhighlight><br />
set SerDevDef classdef BME280 /opt/fhem/BME280.classdef<br />
<br />
</syntaxhighlight>Ist noch keine ECMD Schnittstelle definiert, wird diese erstellt und gleich mit passenden Attributen versehen.<syntaxhighlight><br />
define SerDevDef ECMD serial /dev/ttyS0@9600<br />
set SerDevDef classdef BME280 /opt/fhem/BME280.classdef<br />
attr SerDevDef partial 2<br />
<br />
</syntaxhighlight>Die letzte Zeile ist für die serielle Schnittstelle gerade bei längeren Datagrammen ein Muss. Sie sorgt dafür, dass die kleineren Informationsbröckchen zu einer vollständigen Einheit werden. Kommt das nächste Päckchen innerhalb von (hier) 2 Sekunden, wird das neue Päckchen an die bereits gelesenen Daten angehängt, ansonsten startet eine neue Aufzeichnung beginnend mit dem Päckchen.<br />
<br />
Für den Start kann noch zur Erleichterung der Fehlersuche folgendes ergänzt werden<syntaxhighlight><br />
attr SerDevDef logTraffic 5<br />
attr SerDevDef verbose 5<br />
</syntaxhighlight>Rückstelllen dieser Attribute nicht vergessen, so ist's reichlich gesprächig und füllt schnell das Log !!!<br />
<br />
====== Device ======<br />
Damit ist alles vorbereitet den ECMD Device zu erstellen.<syntaxhighlight><br />
define BME280_42356 ECMDDevice BME280 42356<br />
attr BME280_42356 alias Gartenhaus<br />
attr BME280_42356 room Grundstück<br />
attr BME280_42356 IODev SerDevDef <br />
attr BME280_42356 userReadings airpressure_sealevel:humidity:.* { sprintf("%.2f", ReadingsVal("BME280_42356","pressure",0)*1.023);; }<br />
</syntaxhighlight>Der fragliche Sensor beginnt seine Datagramme immer mit '42356', das ist seine DevId, die über den Parameter 'devId' in der Klassendefinition (siehe oben) Eingang in die readings findet. Über 'BME280' wird die Klassendefinition festgelegt, über '42356' die devId. Sinnigerweise wird im Beispiel hier 'BME280_42356' als Devicename festgelegt, Systematik ist Trumpf.<br />
<br />
Die letzte Zeile macht aus dem vom Sensor gemessenen Luftdruck noch den auf NormalNull Bezogenen. Nicht jeder wohnt direkt am Meer und kann auf diesen Schritt verzichten. Ansonsten weichen die Werte des Sensors immer von der Wettervorhersage ab, je höher der Sensor, um so markanter. Das Beispiel hier gilt für ca. 180m üNN. Die Erzeugung des Wertes für "airpressure_sealevel" ist übrigens an den Event "humidity geknüpft, sonst hat man im Event-Log in diesem Fall 3 Einträge, nämlich den beim Temperatur-, beim Druck- und beim Feuchte-Event (siehe auch beim folgenden Notify und dem linken Teil des Beispiel-Plots weiter unten).<br />
<br />
====== Notify ======<br />
Da der state nach einer Übermittlung aufgrund der Festlegungen aus der Klassendefinition nun nur den Wert der Luftfeuchte enthält, ist es hilfreich ein 'notify' für eine gefälligere Darstellung zu definieren.<syntaxhighlight><br />
define ECMDDevState notify BME280_42356:humidity:.* { Log 1, "$NAME has new values";;sleep 1;;fhem "setstate BME280_42356"." T:".ReadingsVal("BME280_42356","temperature",0)." P:".ReadingsVal("BME280_42356","airpressure_sealevel",0)." H:".ReadingsVal("BME280_42356","humidity",0) }<br />
</syntaxhighlight>Für die Übersicht zerlegt:<syntaxhighlight lang="perl" line="1" start="1"><br />
define ECMDDevState notify BME280_42356:humidity:.* <br />
{<br />
Log 1, "$NAME has new values";;<br />
sleep 1;;<br />
fhem "setstate BME280_42356".<br />
" T:".ReadingsVal("BME280_42356","temperature",0).<br />
" P:".ReadingsVal("BME280_42356","airpressure_sealevel",0).<br />
" H:".ReadingsVal("BME280_42356","humidity",0)<br />
}<br />
<br />
</syntaxhighlight>&#x2460; 'ECMDDevState' wird immer dann benachrichtigt und ausgeführt, wenn der Device 'BME280_42356' ein reading 'humidity' mit einem beliebigen (.*) Wert hat. &#x2462; Dies wird zunächst im Log vermerkt und &#x2463; als nächstes ein wenig gewartet, damit eine Änderung des state auf jeden Fall nach dem Befüllen des state durch das humidity reading stattfindet und auch der Luftdruck fertig berechnet ist. Dann wird &#x2464; der state mit einer Verkettung der gerade gelesenen bzw. berechneten Daten aller Werte &#x2465;,&#x2466;,&#x2467; versorgt.<br />
<br />
====== Weiterführend ======<br />
Abschließend soll noch ein Plot der Messwerte gemacht werden, eine Kurve liest sich leichter. Als Erstes wird eine Datei z.B. '/opt/fhem/www/gplot/SVG_BME280_42356.gplot' mit folgendem Inhalt erstellt, der anzuzeigenden Linien und Beschriftungen des Plots beschreibt.<syntaxhighlight><br />
set terminal png transparent size <SIZE> crop<br />
set output '<OUT>.png'<br />
set xdata time<br />
set timefmt "%Y-%m-%d_%H:%M:%S"<br />
set xlabel "Verlauf"<br />
set title 'Wetter'<br />
set ylabel "Temperatur"<br />
set y2label "Luftdruck"<br />
#myDbLog BME280_42356:temperature:0:<br />
#myDbLog BME280_42356:airpressure_sealevel:0::$val=$val>1100?1100:$val<800?800:$val<br />
#myDbLog BME280_42356:humidity:0::$val=$val/2-10<br />
plot "<IN>" using 1:2 axes x1y1 title 'Temperatur' ls l0 lw 1 with lines,\<br />
"<IN>" using 1:2 axes x1y2 title 'Luftdruck' ls l1 lw 1 with lines,\<br />
"<IN>" using 1:2 axes x1y1 title 'Feuchte' ls l2 lw 1 with lines<br />
</syntaxhighlight>Dabei wird der Luftdruck auf einen plausiblen Bereich eingegrenzt, Drücke außerhalb dieses Bereichs hat es noch nicht gegeben auf diesem Erdball. Der Wert der Feuchte wird dem zu erwartenden Temperaturbereich (-10 bis 40) angeglichen, das ergibt eine schönere Kurve (:$val=$val>1100?1100:$val<800?800:$val). Eine Y-Achse für die Feuchte wäre die dritte Y-Achse, die haben wir also nicht. Also landet 100% Feuchte bei 40°C und 0% Feuchte bei -10°C (:$val=$val/2-10).<br />
<br />
Dann wird der Plot definiert. In diesem Fall mit den Daten aus DbLog, für FileLog muss geringfügig angepaßt werden. Dann fehlten freilich auch die FileLog -Definitionen für 'BME280_42356'.<syntaxhighlight><br />
defmod SVG_BME280_42356 SVG myDbLog:SVG_BME280_42356:HISTORY<br />
</syntaxhighlight>Der Term 'SVG_BME280_42356' liest dabei die Definitionen aus der vorher angelegten Datei 'SVG_BME280_42356.gplot'.<br />
<br />
[[Datei:GHplotECMD.png|rahmenlos|1197x1197px]]<br />
<br />
====== FIN ======<br />
Viel Spaß bei den eigenen Experimenten.<br />
<br />
==Quellen==<br />
<references /><br />
<br />
[[Kategorie:Glossary]]</div>GRZBRZhttp://wiki.fhem.de/w/index.php?title=ECMD&diff=33421ECMD2020-06-25T14:36:54Z<p>GRZBRZ: </p>
<hr />
<div>ECMD bedeutet "Ethersex Command"<ref>[http://www.ethersex.de/index.php/Main_Page_%28Deutsch%29 Ethersex.de]</ref> und ist laut FHEM-Dokumentation<br />
"Any physical device with request/response-like communication capabilities over a TCP connection"<ref>{{Link2CmdRef|Anker=ECMD|Label=FHEM Commandref}}</ref>, das heisst, irgendein physisches Gerät, welches request/response-artige Kommunikationsfähigkeiten aufweist, sei es über eine TCP-Verbindung (Netzwerk) oder eine serielle Schnittstelle.<br />
<br />
In FHEM sind enthalten:<br />
* Modul [[ECMD (Modul)|ECMD]] für die Bearbeitung physischer I/O-Schnittstellengeräte und<br />
* Modul [[ECMDDevice]] für einzelne logische Geräte, deren Kommunikation über ein ECMD-Gerät läuft<br />
<br />
==Beispiele & Links==<br />
<br />
=== Links ===<br />
Siehe {{Link2Forum|Topic= 60753 |Message=521462|LinkText=Thread im FHEM-Forum}}<br />
<br />
Siehe [[Radioaktivitätsmessung mit DIYGeigerCounter]]<br />
<br />
=== DIY Sensor via HC-12 ===<br />
Ein BME280 Temperatur/Druck/Feuchte-Sensor liefert via eines HC-12 Pärchens seine Daten an der seriellen Schnittstelle eines RasPi ab. Der Sketch im Nano, an dem sowohl der BME280 als auch einer der HC-12 hängen, liefert alle 10 Minuten ein Datagramm ab und schickt seinen Wirt in den Tiefschlaf bis zum nächsten Datagramm, um mit den notwendigen Batterien über ein Jahr aushalten zu können.<br />
<br />
Das Datagramm hat die Form <br />
DevId T-3.45°C P995.31hPa H63.27%RH\r\n<br />
<br />
====== Klassendefinition ======<br />
Daraus werden die notwendigen Definitionen für eine Klassendefinition abgeleitet. Die z.B. unter '/opt/fhem/BME280.classdef' abgelegte Datei erhält den Inhalt<syntaxhighlight line="1"><br />
params devId<br />
reading temperature match "%devId\sT([-+.,0-9]+)\S+\sP([-+.,0-9]+)\S+\sH([-+.,0-9]+)\S+\r?\n"<br />
reading temperature postproc { /%devId\sT([-+.,0-9]+)\S+\sP([-+.,0-9]+)\S+\sH([-+.,0-9]+)\S+\r?\n/; $1 }<br />
reading airpressure match "%devId\sT([-+.,0-9]+)\S+\sP([-+.,0-9]+)\S+\sH([-+.,0-9]+)\S+\r?\n"<br />
reading airpressure postproc { /%devId\sT([-+.,0-9]+)\S+\sP([-+.,0-9]+)\S+\sH([-+.,0-9]+)\S+\r?\n/; $2 }<br />
reading humidity match "%devId\sT([-+.,0-9]+)\S+\sP([-+.,0-9]+)\S+\sH([-+.,0-9]+)\S+\r?\n"<br />
reading humidity postproc { /%devId\sT([-+.,0-9]+)\S+\sP([-+.,0-9]+)\S+\sH([-+.,0-9]+)\S+\r?\n/; $3 }<br />
state humidity<br />
</syntaxhighlight>Die regex ist in allen Zeilen der Einfachheit zuliebe gleich gehalten, bei den match könnte man freilich die Klammern löschen und bei den postproc auf ein Paar reduzieren und $_ gleichmäßig mit $1 befüllen. Geschmackssache. Alle Werte werden durch diese Vorgehensweise gleichzeitig und erst dann gelesen, wenn das gesamte Datagramm eingetroffen ist. Es ließe sich auch auf Teil-Strings abfragen, Konflikte bei mehreren Sensoren sind dann denkbar.<br />
<br />
Die letzte Zeile sorgt dafür, dass der state nur dann einen neuen Wert erhält, wenn (in diesem Fall) 'humidity' ein Update erfährt. Bei den gewählten regex trift das hier eigentlich für alle zu, aber da humidity der letzte übertragene Wert ist, ist die Wahl auf ihn gefallen. Außerdem steht nun nur ein Wert im state ohne einleitenden reading Namen, der wäre hier im Beispiel erwartungsgemäß 'humidity', was hier insofern irritiert, weil ja 3 Werte gelesen wurden und man sich unwillkürlich fragt, wo den die anderen geblieben sind. Zum state daher später unter Notify noch weiteres.<br />
<br />
''(Nachtrag: Zum Zeitpunkt der Erstellung dieses Artikels gibt es Probleme in dem Fall, dass die bei "partial" übliche Zusammensetzung der Lesung versagt, wenn das abschließende "\n" als einzelnes Zeichen übertragen wird. Beim DISPATCH des gerade gelesenen Fragments durch fhem.pm wird ein einzelnes "\n" verschluckt und es kommt in Folge zu keinem match mit den dokumentierten match-Ausdrücken.)''<br />
<br />
====== Schnittstelle ======<br />
Sollte bereits eine ECMD Schnittstelle bestehen, kann nun die Definition hinzugefügt werden. Z.B. die ECMD Schnittstelle namens 'SerDevDef' erhält eine zusätzliche Klasse 'BME280' mit den Definitionen aus der vorher generierten Datei, Beispiel siehe oben.<syntaxhighlight><br />
set SerDevDef classdef BME280 /opt/fhem/BME280.classdef<br />
<br />
</syntaxhighlight>Ist noch keine ECMD Schnittstelle definiert, wird diese erstellt und gleich mit passenden Attributen versehen.<syntaxhighlight><br />
define SerDevDef ECMD serial /dev/ttyS0@9600<br />
set SerDevDef classdef BME280 /opt/fhem/BME280.classdef<br />
attr SerDevDef partial 2<br />
<br />
</syntaxhighlight>Die letzte Zeile ist für die serielle Schnittstelle gerade bei längeren Datagrammen ein Muss. Sie sorgt dafür, dass die kleineren Informationsbröckchen zu einer vollständigen Einheit werden. Kommt das nächste Päckchen innerhalb von (hier) 2 Sekunden, wird das neue Päckchen an die bereits gelesenen Daten angehängt, ansonsten startet eine neue Aufzeichnung beginnend mit dem Päckchen.<br />
<br />
Für den Start kann noch zur Erleichterung der Fehlersuche folgendes ergänzt werden<syntaxhighlight><br />
attr SerDevDef logTraffic 5<br />
attr SerDevDef verbose 5<br />
</syntaxhighlight>Rückstelllen dieser Attribute nicht vergessen, so ist's reichlich gesprächig und füllt schnell das Log !!!<br />
<br />
====== Device ======<br />
Damit ist alles vorbereitet den ECMD Device zu erstellen.<syntaxhighlight><br />
define BME280_42356 ECMDDevice BME280 42356<br />
attr BME280_42356 alias Gartenhaus<br />
attr BME280_42356 room Grundstück<br />
attr BME280_42356 IODev SerDevDef <br />
attr BME280_42356 userReadings airpressure_sealevel:humidity:.* { sprintf("%.2f", ReadingsVal("BME280_42356","pressure",0)*1.023);; }<br />
</syntaxhighlight>Der fragliche Sensor beginnt seine Datagramme immer mit '42356', das ist seine DevId, die über den Parameter 'devId' in der Klassendefinition (siehe oben) Eingang in die readings findet. Über 'BME280' wird die Klassendefinition festgelegt, über '42356' die devId. Sinnigerweise wird im Beispiel hier 'BME280_42356' als Devicename festgelegt, Systematik ist Trumpf.<br />
<br />
Die letzte Zeile macht aus dem vom Sensor gemessenen Luftdruck noch den auf NormalNull Bezogenen. Nicht jeder wohnt direkt am Meer und kann auf diesen Schritt verzichten. Ansonsten weichen die Werte des Sensors immer von der Wettervorhersage ab, je höher der Sensor, um so markanter. Das Beispiel hier gilt für ca. 180m üNN. Die Erzeugung des Wertes für "airpressure_sealevel" ist übrigens an den Event "humidity geknüpft, sonst hat man im Event-Log in diesem Fall 3 Einträge, nämlich den beim Temperatur-, beim Druck- und beim Feuchte-Event (siehe auch beim folgenden Notify und dem linken Teil des Beispiel-Plots weiter unten).<br />
<br />
====== Notify ======<br />
Da der state nach einer Übermittlung aufgrund der Festlegungen aus der Klassendefinition nun nur den Wert der Luftfeuchte enthält, ist es hilfreich ein 'notify' für eine gefälligere Darstellung zu definieren.<syntaxhighlight><br />
define ECMDDevState notify BME280_42356:humidity:.* { Log 1, "$NAME has new values";;sleep 1;;fhem "setstate BME280_42356"." T:".ReadingsVal("BME280_42356","temperature",0)." P:".ReadingsVal("BME280_42356","airpressure_sealevel",0)." H:".ReadingsVal("BME280_42356","humidity",0) }<br />
</syntaxhighlight>Für die Übersicht zerlegt:<syntaxhighlight lang="perl" line="1" start="1"><br />
define ECMDDevState notify BME280_42356:humidity:.* <br />
{<br />
Log 1, "$NAME has new values";;<br />
sleep 1;;<br />
fhem "setstate BME280_42356".<br />
" T:".ReadingsVal("BME280_42356","temperature",0).<br />
" P:".ReadingsVal("BME280_42356","airpressure_sealevel",0).<br />
" H:".ReadingsVal("BME280_42356","humidity",0)<br />
}<br />
<br />
</syntaxhighlight>&#x2460; 'ECMDDevState' wird immer dann benachrichtigt und ausgeführt, wenn der Device 'BME280_42356' ein reading 'humidity' mit einem beliebigen (.*) Wert hat. &#x2462; Dies wird zunächst im Log vermerkt und &#x2463; als nächstes ein wenig gewartet, damit eine Änderung des state auf jeden Fall nach dem Befüllen des state durch das humidity reading stattfindet und auch der Luftdruck fertig berechnet ist. Dann wird &#x2464; der state mit einer Verkettung der gerade gelesenen bzw. berechneten Daten aller Werte &#x2465;,&#x2466;,&#x2467; versorgt.<br />
<br />
====== Weiterführend ======<br />
Abschließend soll noch ein Plot der Messwerte gemacht werden, eine Kurve liest sich leichter. Als Erstes wird eine Datei z.B. '/opt/fhem/www/gplot/SVG_BME280_42356.gplot' mit folgendem Inhalt erstellt, der anzuzeigenden Linien und Beschriftungen des Plots beschreibt.<syntaxhighlight><br />
set terminal png transparent size <SIZE> crop<br />
set output '<OUT>.png'<br />
set xdata time<br />
set timefmt "%Y-%m-%d_%H:%M:%S"<br />
set xlabel "Verlauf"<br />
set title 'Wetter'<br />
set ylabel "Temperatur"<br />
set y2label "Luftdruck"<br />
#myDbLog BME280_42356:temperature:0:<br />
#myDbLog BME280_42356:airpressure_sealevel:0::$val=$val>1100?1100:$val<800?800:$val<br />
#myDbLog BME280_42356:humidity:0::$val=$val/2-10<br />
plot "<IN>" using 1:2 axes x1y1 title 'Temperatur' ls l0 lw 1 with lines,\<br />
"<IN>" using 1:2 axes x1y2 title 'Luftdruck' ls l1 lw 1 with lines,\<br />
"<IN>" using 1:2 axes x1y1 title 'Feuchte' ls l2 lw 1 with lines<br />
</syntaxhighlight>Dabei wird der Luftdruck auf einen plausiblen Bereich eingegrenzt, Drücke außerhalb dieses Bereichs hat es noch nicht gegeben auf diesem Erdball. Der Wert der Feuchte wird dem zu erwartenden Temperaturbereich (-10 bis 40) angeglichen, das ergibt eine schönere Kurve (:$val=$val>1100?1100:$val<800?800:$val). Eine Y-Achse für die Feuchte wäre die dritte Y-Achse, die haben wir also nicht. Also landet 100% Feuchte bei 40°C und 0% Feuchte bei -10°C (:$val=$val/2-10).<br />
<br />
Dann wird der Plot definiert. In diesem Fall mit den Daten aus DbLog, für FileLog muss geringfügig angepaßt werden. Dann fehlten freilich auch die FileLog -Definitionen für 'BME280_42356'.<syntaxhighlight><br />
defmod SVG_BME280_42356 SVG myDbLog:SVG_BME280_42356:HISTORY<br />
</syntaxhighlight>Der Term 'SVG_BME280_42356' liest dabei die Definitionen aus der vorher angelegten Datei 'SVG_BME280_42356.gplot'.<br />
<br />
[[Datei:GHplotECMD.png|rahmenlos|1197x1197px]]<br />
<br />
====== FIN ======<br />
Viel Spaß bei den eigenen Experimenten.<br />
<br />
==Quellen==<br />
<references /><br />
<br />
[[Kategorie:Glossary]]</div>GRZBRZhttp://wiki.fhem.de/w/index.php?title=ECMD&diff=33417ECMD2020-06-22T18:33:24Z<p>GRZBRZ: </p>
<hr />
<div>ECMD bedeutet "Ethersex Command"<ref>[http://www.ethersex.de/index.php/Main_Page_%28Deutsch%29 Ethersex.de]</ref> und ist laut FHEM-Dokumentation<br />
"Any physical device with request/response-like communication capabilities over a TCP connection"<ref>{{Link2CmdRef|Anker=ECMD|Label=FHEM Commandref}}</ref>, das heisst, irgendein physisches Gerät, welches request/response-artige Kommunikationsfähigkeiten aufweist, sei es über eine TCP-Verbindung (Netzwerk) oder eine serielle Schnittstelle.<br />
<br />
In FHEM sind enthalten:<br />
* Modul [[ECMD (Modul)|ECMD]] für die Bearbeitung physischer I/O-Schnittstellengeräte und<br />
* Modul [[ECMDDevice]] für einzelne logische Geräte, deren Kommunikation über ein ECMD-Gerät läuft<br />
<br />
==Beispiele & Links==<br />
<br />
=== Links ===<br />
Siehe {{Link2Forum|Topic= 60753 |Message=521462|LinkText=Thread im FHEM-Forum}}<br />
<br />
Siehe [[Radioaktivitätsmessung mit DIYGeigerCounter]]<br />
<br />
=== DIY Sensor via HC-12 ===<br />
Ein BME280 Temperatur/Druck/Feuchte-Sensor liefert via eines HC-12 Pärchens seine Daten an der seriellen Schnittstelle eines RasPi ab. Der Sketch im Nano, an dem sowohl der BME280 als auch einer der HC-12 hängen, liefert alle 10 Minuten ein Datagramm ab und schickt seinen Wirt in den Tiefschlaf bis zum nächsten Datagramm, um mit den notwendigen Batterien über ein Jahr aushalten zu können.<br />
<br />
Das Datagramm hat die Form <br />
DevId T-3.45°C P995.31hPa H63.27%RH\r\n<br />
<br />
====== Klassendefinition ======<br />
Daraus werden die notwendigen Definitionen für eine Klassendefinition abgeleitet. Die z.B. unter '/opt/fhem/BME280.classdef' abgelegte Datei erhält den Inhalt<syntaxhighlight line="1"><br />
params devId<br />
reading temperature match "%devId\sT([-+.,0-9]+)\S+\sP([-+.,0-9]+)\S+\sH([-+.,0-9]+)\S+\r?\n"<br />
reading temperature postproc { /%devId\sT([-+.,0-9]+)\S+\sP([-+.,0-9]+)\S+\sH([-+.,0-9]+)\S+\r?\n/; $1 }<br />
reading airpressure match "%devId\sT([-+.,0-9]+)\S+\sP([-+.,0-9]+)\S+\sH([-+.,0-9]+)\S+\r?\n"<br />
reading airpressure postproc { /%devId\sT([-+.,0-9]+)\S+\sP([-+.,0-9]+)\S+\sH([-+.,0-9]+)\S+\r?\n/; $2 }<br />
reading humidity match "%devId\sT([-+.,0-9]+)\S+\sP([-+.,0-9]+)\S+\sH([-+.,0-9]+)\S+\r?\n"<br />
reading humidity postproc { /%devId\sT([-+.,0-9]+)\S+\sP([-+.,0-9]+)\S+\sH([-+.,0-9]+)\S+\r?\n/; $3 }<br />
state humidity<br />
</syntaxhighlight>Die regex ist in allen Zeilen der Einfachheit zuliebe gleich gehalten, bei den match könnte man freilich die Klammern löschen und bei den postproc auf ein Paar reduzieren und $_ gleichmäßig mit $1 befüllen. Geschmackssache. Alle Werte werden durch diese Vorgehensweise gleichzeitig und erst dann gelesen, wenn das gesamte Datagramm eingetroffen ist. Es ließe sich auch auf Teil-Strings abfragen, Konflikte bei mehreren Sensoren sind dann denkbar.<br />
<br />
Die letzte Zeile sorgt dafür, dass der state nur dann einen neuen Wert erhält, wenn (in diesem Fall) 'humidity' ein Update erfährt. Bei den gewählten regex trift das hier eigentlich für alle zu, aber da humidity der letzte übertragene Wert ist, ist die Wahl auf ihn gefallen. Außerdem steht nun nur ein Wert im state ohne einleitenden reading Namen, der wäre hier im Beispiel erwartungsgemäß 'humidity', was hier insofern irritiert, weil ja 3 Werte gelesen wurden und man sich unwillkürlich fragt, wo den die anderen geblieben sind. Zum state daher später noch weiteres.<br />
<br />
====== Schnittstelle ======<br />
Sollte bereits eine ECMD Schnittstelle bestehen, kann nun die Definition hinzugefügt werden. Z.B. die ECMD Schnittstelle namens 'SerDevDef' erhält eine zusätzliche Klasse 'BME280' mit den Definitionen aus der vorher generierten Datei, Beispiel siehe oben.<syntaxhighlight><br />
set SerDevDef classdef BME280 /opt/fhem/BME280.classdef<br />
<br />
</syntaxhighlight>Ist noch keine ECMD Schnittstelle definiert, wird diese erstellt und gleich mit passenden Attributen versehen.<syntaxhighlight><br />
define SerDevDef ECMD serial /dev/ttyS0@9600<br />
set SerDevDef classdef BME280 /opt/fhem/BME280.classdef<br />
attr SerDevDef partial 2<br />
<br />
</syntaxhighlight>Die letzte Zeile ist für die serielle Schnittstelle gerade bei längeren Datagrammen ein Muss. Sie sorgt dafür, dass die kleineren Informationsbröckchen zu einer vollständigen Einheit werden. Kommt das nächste Päckchen innerhalb von (hier) 2 Sekunden, wird das neue Päckchen an die bereits gelesenen Daten angehängt, ansonsten startet eine neue Aufzeichnung beginnend mit dem Päckchen.<br />
<br />
Für den Start kann noch zur Erleichterung der Fehlersuche folgendes ergänzt werden<syntaxhighlight><br />
attr SerDevDef logTraffic 5<br />
attr SerDevDef verbose 5<br />
</syntaxhighlight>Rückstelllen dieser Attribute nicht vergessen, so ist's reichlich gesprächig und füllt schnell das Log !!!<br />
<br />
====== Device ======<br />
Damit ist alles vorbereitet den ECMD Device zu erstellen.<syntaxhighlight><br />
define BME280_42356 ECMDDevice BME280 42356<br />
attr BME280_42356 alias Gartenhaus<br />
attr BME280_42356 room Grundstück<br />
attr BME280_42356 IODev SerDevDef <br />
attr BME280_42356 userReadings airpressure_sealevel { sprintf("%.2f", ReadingsVal("BME280_42356","pressure",0)*1.023);; }<br />
</syntaxhighlight>Der fragliche Sensor beginnt seine Datagramme immer mit '42356', das ist seine DevId, die über den Parameter 'devId' in der Klassendefinition (siehe oben) Eingang in die readings findet. Über 'BME280' wird die Klassendefinition festgelegt, über '42356' die devId. Sinnigerweise wird im Beispiel hier 'BME280_42356' als Devicename festgelegt, Systematik ist Trumpf.<br />
<br />
Die letzte Zeile macht aus dem vom Sensor gemessenen Luftdruck noch den auf NormalNull Bezogenen. Nicht jeder wohnt direkt am Meer und kann auf diesen Schritt verzichten. Ansonsten weichen die Werte des Sensors immer von der Wettervorhersage ab, je höher der Sensor, um so markanter. Das Beispiel hier gilt für ca. 160m üNN.<br />
<br />
====== Notify ======<br />
Da der state nach einer Übermittlung aufgrund der Festlegungen aus der Klassendefinition nun nur den Wert der Luftfeuchte enthält, ist es hilfreich ein 'notify' für eine gefälligere Darstellung zu definieren.<syntaxhighlight><br />
define ECMDDevState notify BME280_42356:humidity:.* { Log 1, "$NAME has new values";;sleep 1;;fhem "setstate BME280_42356"." T:".ReadingsVal("BME280_42356","temperature",0)." P:".ReadingsVal("BME280_42356","airpressure_sealevel",0)." H:".ReadingsVal("BME280_42356","humidity",0) }<br />
</syntaxhighlight>Für die Übersicht zerlegt:<syntaxhighlight lang="perl" line="1" start="1"><br />
define ECMDDevState notify BME280_42356:humidity:.* <br />
{<br />
Log 1, "$NAME has new values";;<br />
sleep 1;;<br />
fhem "setstate BME280_42356".<br />
" T:".ReadingsVal("BME280_42356","temperature",0).<br />
" P:".ReadingsVal("BME280_42356","airpressure_sealevel",0).<br />
" H:".ReadingsVal("BME280_42356","humidity",0)<br />
}<br />
<br />
</syntaxhighlight>&#x2460; 'ECMDDevState' wird immer dann benachrichtigt und ausgeführt, wenn der Device 'BME280_42356' ein reading 'humidity' mit einem beliebigen (.*) Wert hat. &#x2462; Dies wird zunächst im Log vermerkt und &#x2463; als nächstes ein wenig gewartet, damit eine Änderung des state auf jeden Fall nach dem Befüllen des state durch das humidity reading stattfindet und auch der Luftdruck fertig berechnet ist. Dann wird &#x2464; der state mit einer Verkettung der gerade gelesenen bzw. berechneten Daten aller Werte &#x2465;,&#x2466;,&#x2467; versorgt.<br />
<br />
====== Weiterführend ======<br />
Abschließend soll noch ein Plot der Messwerte gemacht werden, eine Kurve liest sich leichter. Als Erstes wird eine Datei z.B. '/opt/fhem/www/gplot/SVG_BME280_42356.gplot' mit folgendem Inhalt erstellt, der anzuzeigenden Linien und Beschriftungen des Plots beschreibt.<syntaxhighlight><br />
set terminal png transparent size <SIZE> crop<br />
set output '<OUT>.png'<br />
set xdata time<br />
set timefmt "%Y-%m-%d_%H:%M:%S"<br />
set xlabel "Verlauf"<br />
set title 'Wetter'<br />
set ylabel "Temperatur"<br />
set y2label "Luftdruck"<br />
#myDbLog BME280_42356:temperature:0:<br />
#myDbLog BME280_42356:airpressure_sealevel:0::$val=$val>1100?1100:$val<800?800:$val<br />
#myDbLog BME280_42356:humidity:0::$val=$val/2-10<br />
plot "<IN>" using 1:2 axes x1y1 title 'Temperatur' ls l0 lw 1 with lines,\<br />
"<IN>" using 1:2 axes x1y2 title 'Luftdruck' ls l1 lw 1 with lines,\<br />
"<IN>" using 1:2 axes x1y1 title 'Feuchte' ls l2 lw 1 with lines<br />
</syntaxhighlight>Dabei wird der Luftdruck auf einen plausiblen Bereich eingegrenzt, Drücke außerhalb dieses Bereichs hat es noch nicht gegeben auf diesem Erdball. Der Wert der Feuchte wird dem zu erwartenden Temperaturbereich (-10 bis 40) angeglichen, das ergibt eine schönere Kurve (:$val=$val>1100?1100:$val<800?800:$val). Eine Y-Achse für die Feuchte wäre die dritte Y-Achse, die haben wir also nicht. Also landet 100% Feuchte bei 40°C und 0% Feuchte bei -10°C (:$val=$val/2-10).<br />
<br />
Dann wird der Plot definiert. In diesem Fall mit den Daten aus DbLog, für FileLog muss geringfügig angepaßt werden. Dann fehlten freilich auch die FileLog -Definitionen für 'BME280_42356'.<syntaxhighlight><br />
defmod SVG_BME280_42356 SVG myDbLog:SVG_BME280_42356:HISTORY<br />
</syntaxhighlight>Der Term 'SVG_BME280_42356' liest dabei die Definitionen aus der vorher angelegten Datei 'SVG_BME280_42356.gplot'.<br />
<br />
[[Datei:GHplotECMD.png|rahmenlos|1197x1197px]]<br />
<br />
====== FIN ======<br />
Viel Spaß bei den eigenen Experimenten.<br />
<br />
==Quellen==<br />
<references /><br />
<br />
[[Kategorie:Glossary]]</div>GRZBRZhttp://wiki.fhem.de/w/index.php?title=ECMD&diff=33416ECMD2020-06-22T18:30:19Z<p>GRZBRZ: </p>
<hr />
<div>ECMD bedeutet "Ethersex Command"<ref>[http://www.ethersex.de/index.php/Main_Page_%28Deutsch%29 Ethersex.de]</ref> und ist laut FHEM-Dokumentation<br />
"Any physical device with request/response-like communication capabilities over a TCP connection"<ref>{{Link2CmdRef|Anker=ECMD|Label=FHEM Commandref}}</ref>, das heisst, irgendein physisches Gerät, welches request/response-artige Kommunikationsfähigkeiten aufweist, sei es über eine TCP-Verbindung (Netzwerk) oder eine serielle Schnittstelle.<br />
<br />
In FHEM sind enthalten:<br />
* Modul [[ECMD (Modul)|ECMD]] für die Bearbeitung physischer I/O-Schnittstellengeräte und<br />
* Modul [[ECMDDevice]] für einzelne logische Geräte, deren Kommunikation über ein ECMD-Gerät läuft<br />
<br />
==Beispiele & Links==<br />
<br />
=== Links ===<br />
Siehe {{Link2Forum|Topic= 60753 |Message=521462|LinkText=Thread im FHEM-Forum}}<br />
<br />
Siehe [[Radioaktivitätsmessung mit DIYGeigerCounter]]<br />
<br />
=== DIY Sensor via HC-12 ===<br />
Ein BME280 Temperatur/Druck/Feuchte-Sensor liefert via eines HC-12 Pärchens seine Daten an der seriellen Schnittstelle eines RasPi ab. Der Sketch im Nano, an dem sowohl der BME280 als auch einer der HC-12 hängen, liefert alle 10 Minuten ein Datagramm ab und schickt seinen Wirt in den Tiefschlaf bis zum nächsten Datagramm, um mit den notwendigen Batterien über ein Jahr aushalten zu können.<br />
<br />
Das Datagramm hat die Form <br />
DevId T-3.45°C P995.31hPa H63.27%RH\r\n<br />
<br />
====== Klassendefinition ======<br />
Daraus werden die notwendigen Definitionen für eine Klassendefinition abgeleitet. Die z.B. unter '/opt/fhem/BME280.classdef' abgelegte Datei erhält den Inhalt<syntaxhighlight line="1"><br />
params devId<br />
reading temperature match "%devId\sT([-+.,0-9]+)\S+\sP([-+.,0-9]+)\S+\sH([-+.,0-9]+)\S+\r?\n"<br />
reading temperature postproc { /%devId\sT([-+.,0-9]+)\S+\sP([-+.,0-9]+)\S+\sH([-+.,0-9]+)\S+\r?\n/; $1 }<br />
reading airpressure match "%devId\sT([-+.,0-9]+)\S+\sP([-+.,0-9]+)\S+\sH([-+.,0-9]+)\S+\r?\n"<br />
reading airpressure postproc { /%devId\sT([-+.,0-9]+)\S+\sP([-+.,0-9]+)\S+\sH([-+.,0-9]+)\S+\r?\n/; $2 }<br />
reading humidity match "%devId\sT([-+.,0-9]+)\S+\sP([-+.,0-9]+)\S+\sH([-+.,0-9]+)\S+\r?\n"<br />
reading humidity postproc { /%devId\sT([-+.,0-9]+)\S+\sP([-+.,0-9]+)\S+\sH([-+.,0-9]+)\S+\r?\n/; $3 }<br />
state humidity<br />
</syntaxhighlight>Die regex ist in allen Zeilen der Einfachheit zuliebe gleich gehalten, bei den match könnte man freilich die Klammern löschen und bei den postproc auf ein Paar reduzieren und $_ gleichmäßig mit $1 befüllen. Geschmackssache. Alle Werte werden durch diese Vorgehensweise gleichzeitig und erst dann gelesen, wenn das gesamte Datagramm eingetroffen ist. Es ließe sich auch auf Teil-Strings abfragen, Konflikte bei mehreren Sensoren sind dann denkbar.<br />
<br />
Die letzte Zeile sorgt dafür, dass der state nur dann einen neuen Wert erhält, wenn (in diesem Fall) 'humidity' ein Update erfährt. Bei den gewählten regex trift das hier eigentlich für alle zu, aber da humidity der letzte übertragene Wert ist, ist die Wahl auf ihn gefallen. Außerdem steht nun nur ein Wert im state ohne einleitenden reading Namen, der wäre hier im Beispiel erwartungsgemäß 'humidity', was hier insofern irritiert, weil ja 3 Werte gelesen wurden und man sich unwillkürlich fragt, wo den die anderen geblieben sind. Zum state daher später noch weiteres.<br />
<br />
====== Schnittstelle ======<br />
Sollte bereits eine ECMD Schnittstelle bestehen, kann nun die Definition hinzugefügt werden. Z.B. die ECMD Schnittstelle namens 'SerDevDef' erhält eine zusätzliche Klasse 'BME280' mit den Definitionen aus der vorher generierten Datei, Beispiel siehe oben.<syntaxhighlight><br />
set SerDevDef classdef BME280 /opt/fhem/BME280.classdef<br />
<br />
</syntaxhighlight>Ist noch keine ECMD Schnittstelle definiert, wird diese erstellt und gleich mit passenden Attributen versehen.<syntaxhighlight><br />
define SerDevDef ECMD serial /dev/ttyS0@9600<br />
set SerDevDef classdef BME280 /opt/fhem/BME280.classdef<br />
attr SerDevDef partial 2<br />
<br />
</syntaxhighlight>Die letzte Zeile ist für die serielle Schnittstelle gerade bei längeren Datagrammen ein Muss. Sie sorgt dafür, dass die kleineren Informationsbröckchen zu einer vollständigen Einheit werden. Kommt das nächste Päckchen innerhalb von (hier) 2 Sekunden, wird das neue Päckchen an die bereits gelesenen Daten angehängt, ansonsten startet eine neue Aufzeichnung beginnend mit dem Päckchen.<br />
<br />
Für den Start kann noch zur Erleichterung der Fehlersuche folgendes ergänzt werden<syntaxhighlight><br />
attr SerDevDef logTraffic 5<br />
attr SerDevDef verbose 5<br />
</syntaxhighlight>Rückstelllen dieser Attribute nicht vergessen, so ist's reichlich gesprächig und füllt schnell das Log !!!<br />
<br />
====== Device ======<br />
Damit ist alles vorbereitet den ECMD Device zu erstellen.<syntaxhighlight><br />
define BME280_42356 ECMDDevice BME280 42356<br />
attr BME280_42356 alias Gartenhaus<br />
attr BME280_42356 room Grundstück<br />
attr BME280_42356 IODev SerDevDef <br />
attr BME280_42356 userReadings airpressure_sealevel { sprintf("%.2f", ReadingsVal("BME280_42356","pressure",0)*1.023);; }<br />
</syntaxhighlight>Der fragliche Sensor beginnt seine Datagramme immer mit '42356', das ist seine DevId, die über den Parameter 'devId' in der Klassendefinition (siehe oben) Eingang in die readings findet. Über 'BME280' wird die Klassendefinition festgelegt, über '42356' die devId. Sinnigerweise wird im Beispiel hier 'BME280_42356' als Devicename festgelegt, Systematik ist Trumpf.<br />
<br />
Die letzte Zeile macht aus dem vom Sensor gemessenen Luftdruck noch den auf NormalNull Bezogenen. Nicht jeder wohnt direkt am Meer und kann auf diesen Schritt verzichten. Ansonsten weichen die Werte des Sensors immer von der Wettervorhersage ab, je höher der Sensor, um so markanter. Das Beispiel hier gilt für ca. 160m üNN.<br />
<br />
====== Notify ======<br />
Da der state nach einer Übermittlung aufgrund der Festlegungen aus der Klassendefinition nun nur den Wert der Luftfeuchte enthält, ist es hilfreich ein 'notify' für eine gefälligere Darstellung zu definieren.<syntaxhighlight><br />
define ECMDDevState notify BME280_42356:humidity:.* { Log 1, "$NAME has new values";;sleep 1;;fhem "setstate BME280_42356"." T:".ReadingsVal("BME280_42356","temperature",0)." P:".ReadingsVal("BME280_42356","airpressure_sealevel",0)." H:".ReadingsVal("BME280_42356","humidity",0) }<br />
</syntaxhighlight>Für die Übersicht zerlegt:<syntaxhighlight lang="perl" line="1" start="1"><br />
define ECMDDevState notify BME280_42356:humidity:.* <br />
{<br />
Log 1, "$NAME has new values";;<br />
sleep 1;;<br />
fhem "setstate BME280_42356".<br />
" T:".ReadingsVal("BME280_42356","temperature",0).<br />
" P:".ReadingsVal("BME280_42356","airpressure_sealevel",0).<br />
" H:".ReadingsVal("BME280_42356","humidity",0)<br />
}<br />
<br />
</syntaxhighlight>&#x2460; 'ECMDDevState' wird immer dann benachrichtigt und ausgeführt, wenn der Device 'BME280_42356' ein reading 'humidity' mit einem beliebigen (.*) Wert hat. &#x2462; Dies wird zunächst im Log vermerkt und &#x2463; als nächstes ein wenig gewartet, damit eine Änderung des state auf jeden Fall nach dem Befüllen des state durch das humidity reading stattfindet und auch der Luftdruck fertig berechnet ist. Dann wird &#x2464; der state mit einer Verkettung der gerade gelesenen bzw. berechneten Daten aller Werte &#x2465;,&#x2466;,&#x2467; versorgt.<br />
<br />
====== Weiterführend ======<br />
Abschließend soll noch ein Plot der Messwerte gemacht werden, eine Kurve liest sich leichter. Als Erstes wird eine Datei z.B. '/opt/fhem/www/gplot/SVG_BME280_42356.gplot' mit folgendem Inhalt erstellt, der anzuzeigenden Linien und Beschriftungen des Plots beschreibt.<syntaxhighlight><br />
set terminal png transparent size <SIZE> crop<br />
set output '<OUT>.png'<br />
set xdata time<br />
set timefmt "%Y-%m-%d_%H:%M:%S"<br />
set xlabel "Verlauf"<br />
set title 'Wetter'<br />
set ylabel "Temperatur"<br />
set y2label "Luftdruck"<br />
#myDbLog BME280_42356:temperature:0:<br />
#myDbLog BME280_42356:airpressure_sealevel:0::$val=$val>1100?1100:$val<800?800:$val<br />
#myDbLog BME280_42356:humidity:0::$val=$val/2-10<br />
plot "<IN>" using 1:2 axes x1y1 title 'Temperatur' ls l0 lw 1 with lines,\<br />
"<IN>" using 1:2 axes x1y2 title 'Luftdruck' ls l1 lw 1 with lines,\<br />
"<IN>" using 1:2 axes x1y1 title 'Feuchte' ls l2 lw 1 with lines<br />
</syntaxhighlight>Dabei wird der Luftdruck auf einen plausiblen Bereich eingegrenzt, Drücke außerhalb dieses Bereichs hat es noch nicht gegeben auf diesem Erdball. Der Wert der Feuchte wird dem zu erwartenden Temperaturbereich (-10 bis 40) angeglichen, das ergibt eine schönere Kurve (:$val=$val>1100?1100:$val<800?800:$val). Eine Y-Achse für die Feuchte wäre die dritte Y-Achse, die haben wir also nicht. Also landet 100% Feuchte bei 40°C und 0% Feuchte bei -10°C (:$val=$val/2-10).<br />
<br />
Dann wird der Plot definiert. In diesem Fall mit den Daten aus DbLog, für FileLog muss geringfügig angepaßt werden. Dann fehlten freilich auch die FileLog -Definitionen für 'BME280_42356'.<syntaxhighlight><br />
defmod SVG_BME280_42356 SVG myDbLog:SVG_BME280_42356:HISTORY<br />
</syntaxhighlight>Der Term 'SVG_BME280_42356' liest dabei die Definitionen aus der vorher angelegten Datei 'SVG_BME280_42356.gplot'.<br />
[[Datei:GHplotECMD.png|links|rahmenlos|1197x1197px|Voila]]<br />
<br />
====== FIN ======<br />
Viel Spaß bei den eigenen Experimenten.<br />
<br />
==Quellen==<br />
<references /><br />
<br />
[[Kategorie:Glossary]]</div>GRZBRZhttp://wiki.fhem.de/w/index.php?title=Datei:GHplotECMD.png&diff=33415Datei:GHplotECMD.png2020-06-22T18:27:44Z<p>GRZBRZ: Plot aus ECMD Daten</p>
<hr />
<div>== Beschreibung ==<br />
Plot aus ECMD Daten</div>GRZBRZhttp://wiki.fhem.de/w/index.php?title=Datei:GHplotECMD.svg&diff=33414Datei:GHplotECMD.svg2020-06-22T18:15:59Z<p>GRZBRZ: Plot aus Daten ECMD</p>
<hr />
<div>== Beschreibung ==<br />
Plot aus Daten ECMD</div>GRZBRZhttp://wiki.fhem.de/w/index.php?title=ECMD&diff=33413ECMD2020-06-22T18:02:05Z<p>GRZBRZ: </p>
<hr />
<div>ECMD bedeutet "Ethersex Command"<ref>[http://www.ethersex.de/index.php/Main_Page_%28Deutsch%29 Ethersex.de]</ref> und ist laut FHEM-Dokumentation<br />
"Any physical device with request/response-like communication capabilities over a TCP connection"<ref>{{Link2CmdRef|Anker=ECMD|Label=FHEM Commandref}}</ref>, das heisst, irgendein physisches Gerät, welches request/response-artige Kommunikationsfähigkeiten aufweist, sei es über eine TCP-Verbindung (Netzwerk) oder eine serielle Schnittstelle.<br />
<br />
In FHEM sind enthalten:<br />
* Modul [[ECMD (Modul)|ECMD]] für die Bearbeitung physischer I/O-Schnittstellengeräte und<br />
* Modul [[ECMDDevice]] für einzelne logische Geräte, deren Kommunikation über ein ECMD-Gerät läuft<br />
<br />
==Beispiele & Links==<br />
<br />
=== Links ===<br />
Siehe {{Link2Forum|Topic= 60753 |Message=521462|LinkText=Thread im FHEM-Forum}}<br />
<br />
Siehe [[Radioaktivitätsmessung mit DIYGeigerCounter]]<br />
<br />
=== DIY Sensor via HC-12 ===<br />
Ein BME280 Temperatur/Druck/Feuchte-Sensor liefert via eines HC-12 Pärchens seine Daten an der seriellen Schnittstelle eines RasPi ab. Der Sketch im Nano, an dem sowohl der BME280 als auch einer der HC-12 hängen, liefert alle 10 Minuten ein Datagramm ab und schickt seinen Wirt in den Tiefschlaf bis zum nächsten Datagramm, um mit den notwendigen Batterien über ein Jahr aushalten zu können.<br />
<br />
Das Datagramm hat die Form <br />
DevId T-3.45°C P995.31hPa H63.27%RH\r\n<br />
<br />
====== Klassendefinition ======<br />
Daraus werden die notwendigen Definitionen für eine Klassendefinition abgeleitet. Die z.B. unter '/opt/fhem/BME280.classdef' abgelegte Datei erhält den Inhalt<syntaxhighlight line="1"><br />
params devId<br />
reading temperature match "%devId\sT([-+.,0-9]+)\S+\sP([-+.,0-9]+)\S+\sH([-+.,0-9]+)\S+\r?\n"<br />
reading temperature postproc { /%devId\sT([-+.,0-9]+)\S+\sP([-+.,0-9]+)\S+\sH([-+.,0-9]+)\S+\r?\n/; $1 }<br />
reading airpressure match "%devId\sT([-+.,0-9]+)\S+\sP([-+.,0-9]+)\S+\sH([-+.,0-9]+)\S+\r?\n"<br />
reading airpressure postproc { /%devId\sT([-+.,0-9]+)\S+\sP([-+.,0-9]+)\S+\sH([-+.,0-9]+)\S+\r?\n/; $2 }<br />
reading humidity match "%devId\sT([-+.,0-9]+)\S+\sP([-+.,0-9]+)\S+\sH([-+.,0-9]+)\S+\r?\n"<br />
reading humidity postproc { /%devId\sT([-+.,0-9]+)\S+\sP([-+.,0-9]+)\S+\sH([-+.,0-9]+)\S+\r?\n/; $3 }<br />
state humidity<br />
</syntaxhighlight>Die regex ist in allen Zeilen der Einfachheit zuliebe gleich gehalten, bei den match könnte man freilich die Klammern löschen und bei den postproc auf ein Paar reduzieren und $_ gleichmäßig mit $1 befüllen. Geschmackssache. Alle Werte werden durch diese Vorgehensweise gleichzeitig und erst dann gelesen, wenn das gesamte Datagramm eingetroffen ist. Es ließe sich auch auf Teil-Strings abfragen, Konflikte bei mehreren Sensoren sind dann denkbar.<br />
<br />
Die letzte Zeile sorgt dafür, dass der state nur dann einen neuen Wert erhält, wenn (in diesem Fall) 'humidity' ein Update erfährt. Bei den gewählten regex trift das hier eigentlich für alle zu, aber da humidity der letzte übertragene Wert ist, ist die Wahl auf ihn gefallen. Außerdem steht nun nur ein Wert im state ohne einleitenden reading Namen, der wäre hier im Beispiel erwartungsgemäß 'humidity', was hier insofern irritiert, weil ja 3 Werte gelesen wurden und man sich unwillkürlich fragt, wo den die anderen geblieben sind. Zum state daher später noch weiteres.<br />
<br />
====== Schnittstelle ======<br />
Sollte bereits eine ECMD Schnittstelle bestehen, kann nun die Definition hinzugefügt werden. Z.B. die ECMD Schnittstelle namens 'SerDevDef' erhält eine zusätzliche Klasse 'BME280' mit den Definitionen aus der vorher generierten Datei, Beispiel siehe oben.<syntaxhighlight><br />
set SerDevDef classdef BME280 /opt/fhem/BME280.classdef<br />
<br />
</syntaxhighlight>Ist noch keine ECMD Schnittstelle definiert, wird diese erstellt und gleich mit passenden Attributen versehen.<syntaxhighlight><br />
define SerDevDef ECMD serial /dev/ttyS0@9600<br />
set SerDevDef classdef BME280 /opt/fhem/BME280.classdef<br />
attr SerDevDef partial 2<br />
<br />
</syntaxhighlight>Die letzte Zeile ist für die serielle Schnittstelle gerade bei längeren Datagrammen ein Muss. Sie sorgt dafür, dass die kleineren Informationsbröckchen zu einer vollständigen Einheit werden. Kommt das nächste Päckchen innerhalb von (hier) 2 Sekunden, wird das neue Päckchen an die bereits gelesenen Daten angehängt, ansonsten startet eine neue Aufzeichnung beginnend mit dem Päckchen.<br />
<br />
Für den Start kann noch zur Erleichterung der Fehlersuche folgendes ergänzt werden<syntaxhighlight><br />
attr SerDevDef logTraffic 5<br />
attr SerDevDef verbose 5<br />
</syntaxhighlight>Rückstelllen dieser Attribute nicht vergessen, so ist's reichlich gesprächig und füllt schnell das Log !!!<br />
<br />
====== Device ======<br />
Damit ist alles vorbereitet den ECMD Device zu erstellen.<syntaxhighlight><br />
define BME280_42356 ECMDDevice BME280 42356<br />
attr BME280_42356 alias Gartenhaus<br />
attr BME280_42356 room Grundstück<br />
attr BME280_42356 IODev SerDevDef <br />
attr BME280_42356 userReadings airpressure_sealevel { sprintf("%.2f", ReadingsVal("BME280_42356","pressure",0)*1.023);; }<br />
</syntaxhighlight>Der fragliche Sensor beginnt seine Datagramme immer mit '42356', das ist seine DevId, die über den Parameter 'devId' in der Klassendefinition (siehe oben) Eingang in die readings findet. Über 'BME280' wird die Klassendefinition festgelegt, über '42356' die devId. Sinnigerweise wird im Beispiel hier 'BME280_42356' als Devicename festgelegt, Systematik ist Trumpf.<br />
<br />
Die letzte Zeile macht aus dem vom Sensor gemessenen Luftdruck noch den auf NormalNull Bezogenen. Nicht jeder wohnt direkt am Meer und kann auf diesen Schritt verzichten. Ansonsten weichen die Werte des Sensors immer von der Wettervorhersage ab, je höher der Sensor, um so markanter. Das Beispiel hier gilt für ca. 160m üNN.<br />
<br />
====== Notify ======<br />
Da der state nach einer Übermittlung aufgrund der Festlegungen aus der Klassendefinition nun nur den Wert der Luftfeuchte enthält, ist es hilfreich ein 'notify' für eine gefälligere Darstellung zu definieren.<syntaxhighlight><br />
define ECMDDevState notify BME280_42356:humidity:.* { Log 1, "$NAME has new values";;sleep 1;;fhem "setstate BME280_42356"." T:".ReadingsVal("BME280_42356","temperature",0)." P:".ReadingsVal("BME280_42356","airpressure_sealevel",0)." H:".ReadingsVal("BME280_42356","humidity",0) }<br />
</syntaxhighlight>Für die Übersicht zerlegt:<syntaxhighlight lang="perl" line="1" start="1"><br />
define ECMDDevState notify BME280_42356:humidity:.* <br />
{<br />
Log 1, "$NAME has new values";;<br />
sleep 1;;<br />
fhem "setstate BME280_42356".<br />
" T:".ReadingsVal("BME280_42356","temperature",0).<br />
" P:".ReadingsVal("BME280_42356","airpressure_sealevel",0).<br />
" H:".ReadingsVal("BME280_42356","humidity",0)<br />
}<br />
<br />
</syntaxhighlight>&#x2460; 'ECMDDevState' wird immer dann benachrichtigt und ausgeführt, wenn der Device 'BME280_42356' ein reading 'humidity' mit einem beliebigen (.*) Wert hat. &#x2462; Dies wird zunächst im Log vermerkt und &#x2463; als nächstes ein wenig gewartet, damit eine Änderung des state auf jeden Fall nach dem Befüllen des state durch das humidity reading stattfindet und auch der Luftdruck fertig berechnet ist. Dann wird &#x2464; der state mit einer Verkettung der gerade gelesenen bzw. berechneten Daten aller Werte &#x2465;,&#x2466;,&#x2467; versorgt.<br />
<br />
====== Weiterführend ======<br />
Abschließend soll noch ein Plot der Messwerte gemacht werden, eine Kurve liest sich leichter. Als Erstes wird eine Datei z.B. '/opt/fhem/www/gplot/SVG_BME280_42356.gplot' mit folgendem Inhalt erstellt, der anzuzeigenden Linien und Beschriftungen des Plots beschreibt.<syntaxhighlight><br />
set terminal png transparent size <SIZE> crop<br />
set output '<OUT>.png'<br />
set xdata time<br />
set timefmt "%Y-%m-%d_%H:%M:%S"<br />
set xlabel "Verlauf"<br />
set title 'Wetter'<br />
set ylabel "Temperatur"<br />
set y2label "Luftdruck"<br />
#myDbLog BME280_42356:temperature:0:<br />
#myDbLog BME280_42356:airpressure_sealevel:0::$val=$val>1100?1100:$val<800?800:$val<br />
#myDbLog BME280_42356:humidity:0::$val=$val/2-10<br />
plot "<IN>" using 1:2 axes x1y1 title 'Temperatur' ls l0 lw 1 with lines,\<br />
"<IN>" using 1:2 axes x1y2 title 'Luftdruck' ls l1 lw 1 with lines,\<br />
"<IN>" using 1:2 axes x1y1 title 'Feuchte' ls l2 lw 1 with lines<br />
</syntaxhighlight>Dabei wird der Luftdruck auf einen plausiblen Bereich eingegrenzt, Drücke außerhalb dieses Bereichs hat es noch nicht gegeben auf diesem Erdball. Der Wert der Feuchte wird dem zu erwartenden Temperaturbereich (-10 bis 40) angeglichen, das ergibt eine schönere Kurve (:$val=$val>1100?1100:$val<800?800:$val). Eine Y-Achse für die Feuchte wäre die dritte Y-Achse, die haben wir also nicht. Also landet 100% Feuchte bei 40°C und 0% Feuchte bei -10°C (:$val=$val/2-10).<br />
<br />
Dann wird der Plot definiert. In diesem Fall mit den Daten aus DbLog, für FileLog muss geringfügig angepaßt werden. Dann fehlten freilich auch die FileLog -Definitionen für 'BME280_42356'.<syntaxhighlight><br />
defmod SVG_BME280_42356 SVG myDbLog:SVG_BME280_42356:HISTORY<br />
</syntaxhighlight>Der Term 'SVG_BME280_42356' liest dabei die Definitionen aus der vorher angelegten Datei 'SVG_BME280_42356.gplot'.<br />
<br />
====== FIN ======<br />
Viel Spaß bei den eigenen Experimenten.<br />
<br />
==Quellen==<br />
<references /><br />
<br />
[[Kategorie:Glossary]]</div>GRZBRZhttp://wiki.fhem.de/w/index.php?title=ECMD&diff=33412ECMD2020-06-22T17:35:40Z<p>GRZBRZ: </p>
<hr />
<div>ECMD bedeutet "Ethersex Command"<ref>[http://www.ethersex.de/index.php/Main_Page_%28Deutsch%29 Ethersex.de]</ref> und ist laut FHEM-Dokumentation<br />
"Any physical device with request/response-like communication capabilities over a TCP connection"<ref>{{Link2CmdRef|Anker=ECMD|Label=FHEM Commandref}}</ref>, das heisst, irgendein physisches Gerät, welches request/response-artige Kommunikationsfähigkeiten aufweist, sei es über eine TCP-Verbindung (Netzwerk) oder eine serielle Schnittstelle.<br />
<br />
In FHEM sind enthalten:<br />
* Modul [[ECMD (Modul)|ECMD]] für die Bearbeitung physischer I/O-Schnittstellengeräte und<br />
* Modul [[ECMDDevice]] für einzelne logische Geräte, deren Kommunikation über ein ECMD-Gerät läuft<br />
<br />
==Beispiele & Links==<br />
Siehe {{Link2Forum|Topic= 60753 |Message=521462|LinkText=Thread im FHEM-Forum}}<br />
<br />
Siehe [[Radioaktivitätsmessung mit DIYGeigerCounter]]<br />
<br />
=== DIY Sensor via HC-12 ===<br />
Ein BME280 Temperatur/Druck/Feuchte-Sensor liefert via eines HC-12 Pärchens seine Daten an der seriellen Schnittstelle eines RasPi ab. Der Sketch im Nano, an dem sowohl der BME280 als auch einer der HC-12 hängen, liefert alle 10 Minuten ein Datagramm ab und schickt seinen Wirt in den Tiefschlaf bis zum nächsten Datagramm, um mit den notwendigen Batterien über ein Jahr aushalten zu können.<br />
<br />
Das Datagramm hat die Form <br />
DevId T-3.45°C P995.31hPa H63.27%RH\r\n<br />
<br />
====== Klassendefinition ======<br />
Daraus werden die notwendigen Definitionen für eine Klassendefinition abgeleitet. Die z.B. unter '/opt/fhem/BME280.classdef' abgelegte Datei erhält den Inhalt<syntaxhighlight line="1"><br />
params devId<br />
reading temperature match "%devId\sT([-+.,0-9]+)\S+\sP([-+.,0-9]+)\S+\sH([-+.,0-9]+)\S+\r?\n"<br />
reading temperature postproc { /%devId\sT([-+.,0-9]+)\S+\sP([-+.,0-9]+)\S+\sH([-+.,0-9]+)\S+\r?\n/; $1 }<br />
reading airpressure match "%devId\sT([-+.,0-9]+)\S+\sP([-+.,0-9]+)\S+\sH([-+.,0-9]+)\S+\r?\n"<br />
reading airpressure postproc { /%devId\sT([-+.,0-9]+)\S+\sP([-+.,0-9]+)\S+\sH([-+.,0-9]+)\S+\r?\n/; $2 }<br />
reading humidity match "%devId\sT([-+.,0-9]+)\S+\sP([-+.,0-9]+)\S+\sH([-+.,0-9]+)\S+\r?\n"<br />
reading humidity postproc { /%devId\sT([-+.,0-9]+)\S+\sP([-+.,0-9]+)\S+\sH([-+.,0-9]+)\S+\r?\n/; $3 }<br />
state humidity<br />
</syntaxhighlight>Die regex ist in allen Zeilen der Einfachheit zuliebe gleich gehalten, bei den match könnte man freilich die Klammern löschen und bei den postproc auf ein Paar reduzieren und $_ gleichmäßig mit $1 befüllen. Geschmackssache. Alle Werte werden durch diese Vorgehensweise gleichzeitig und erst dann gelesen, wenn das gesamte Datagramm eingetroffen ist. Es ließe sich auch auf Teil-Strings abfragen, Konflikte bei mehreren Sensoren sind dann denkbar.<br />
<br />
Die letzte Zeile sorgt dafür, dass der state nur dann einen neuen Wert erhält, wenn (in diesem Fall) 'humidity' ein Update erfährt. Bei den gewählten regex trift das hier eigentlich für alle zu, aber da humidity der letzte übertragene Wert ist, ist die Wahl auf ihn gefallen. Außerdem steht nun nur ein Wert im state ohne einleitenden reading Namen, der wäre hier im Beispiel erwartungsgemäß 'humidity', was hier insofern irritiert, weil ja 3 Werte gelesen wurden und man sich unwillkürlich fragt, wo den die anderen geblieben sind. Zum state daher später noch weiteres.<br />
<br />
====== Schnittstelle ======<br />
Sollte bereits eine ECMD Schnittstelle bestehen, kann nun die Definition hinzugefügt werden. Z.B. die ECMD Schnittstelle namens 'SerDevDef' erhält eine zusätzliche Klasse 'BME280' mit den Definitionen aus der vorher generierten Datei, Beispiel siehe oben.<syntaxhighlight><br />
set SerDevDef classdef BME280 /opt/fhem/BME280.classdef<br />
<br />
</syntaxhighlight>Ist noch keine ECMD Schnittstelle definiert, wird diese erstellt und gleich mit passenden Attributen versehen.<syntaxhighlight><br />
define SerDevDef ECMD serial /dev/ttyS0@9600<br />
set SerDevDef classdef BME280 /opt/fhem/BME280.classdef<br />
attr SerDevDef partial 2<br />
<br />
</syntaxhighlight>Die letzte Zeile ist für die serielle Schnittstelle gerade bei längeren Datagrammen ein Muss. Sie sorgt dafür, dass die kleineren Informationsbröckchen zu einer vollständigen Einheit werden. Kommt das nächste Päckchen innerhalb von (hier) 2 Sekunden, wird das neue Päckchen an die bereits gelesenen Daten angehängt, ansonsten startet eine neue Aufzeichnung beginnend mit dem Päckchen.<br />
<br />
Für den Start kann noch zur Erleichterung der Fehlersuche folgendes ergänzt werden<syntaxhighlight><br />
attr SerDevDef logTraffic 5<br />
attr SerDevDef verbose 5<br />
</syntaxhighlight>Rückstelllen dieser Attribute nicht vergessen, so ist's reichlich gesprächig und füllt schnell das Log !!!<br />
<br />
====== Device ======<br />
Damit ist alles vorbereitet den ECMD Device zu erstellen.<syntaxhighlight><br />
define BME280_42356 ECMDDevice BME280 42356<br />
attr BME280_42356 alias Gartenhaus<br />
attr BME280_42356 room Grundstück<br />
attr BME280_42356 IODev SerDevDef <br />
attr BME280_42356 userReadings airpressure_sealevel { sprintf("%.2f", ReadingsVal("BME280_42356","pressure",0)*1.023);; }<br />
</syntaxhighlight>Der fragliche Sensor beginnt seine Datagramme immer mit '42356', das ist seine DevId, die über den Parameter 'devId' in der Klassendefinition (siehe oben) Eingang in die readings findet. Über 'BME280' wird die Klassendefinition festgelegt, über '42356' die devId. Sinnigerweise wird im Beispiel hier 'BME280_42356' als Devicename festgelegt, Systematik ist Trumpf.<br />
<br />
Die letzte Zeile macht aus dem vom Sensor gemessenen Luftdruck noch den auf NormalNull Bezogenen. Nicht jeder wohnt direkt am Meer und kann auf diesen Schritt verzichten. Ansonsten weichen die Werte des Sensors immer von der Wettervorhersage ab, je höher der Sensor, um so markanter. Das Beispiel hier gilt für ca. 160m üNN.<br />
<br />
====== Notify ======<br />
Da der state nach einer Übermittlung aufgrund der Festlegungen aus der Klassendefinition nun nur den Wert der Luftfeuchte enthält, ist es hilfreich ein 'notify' für eine gefälligere Darstellung zu definieren.<syntaxhighlight><br />
define ECMDDevState notify BME280_42356:humidity:.* { Log 1, "$NAME has new values";;sleep 1;;fhem "setstate BME280_42356"." T:".ReadingsVal("BME280_42356","temperature",0)." P:".ReadingsVal("BME280_42356","airpressure_sealevel",0)." H:".ReadingsVal("BME280_42356","humidity",0) }<br />
</syntaxhighlight>Für die Übersicht zerlegt:<syntaxhighlight lang="perl" line="1" start="1"><br />
define ECMDDevState notify BME280_42356:humidity:.* <br />
{<br />
Log 1, "$NAME has new values";;<br />
sleep 1;;<br />
fhem "setstate BME280_42356".<br />
" T:".ReadingsVal("BME280_42356","temperature",0).<br />
" P:".ReadingsVal("BME280_42356","airpressure_sealevel",0).<br />
" H:".ReadingsVal("BME280_42356","humidity",0)<br />
}<br />
<br />
</syntaxhighlight>&#x2460; 'ECMDDevState' wird immer dann benachrichtigt und ausgeführt, wenn der Device 'BME280_42356' ein reading 'humidity' mit einem beliebigen (.*) Wert hat. &#x2462; Dies wird zunächst im Log vermerkt und &#x2463; als nächstes ein wenig gewartet, damit eine Änderung des state auf jeden Fall nach dem Befüllen des state durch das humidity reading stattfindet und auch der Luftdruck fertig berechnet ist. Dann wird &#x2464; der state mit einer Verkettung der gerade gelesenen bzw. berechneten Daten aller Werte &#x2465;,&#x2466;,&#x2467; versorgt.<br />
<br />
====== Weiterführend ======<br />
Abschließend soll noch ein Plot der Messwerte gemacht werden, eine Kurve liest sich leichter. Als Erstes wird eine Datei z.B. '/opt/fhem/www/gplot/SVG_BME280_42356.gplot' mit folgendem Inhalt erstellt, der anzuzeigenden Linien und Beschriftungen des Plots beschreibt.<syntaxhighlight><br />
set terminal png transparent size <SIZE> crop<br />
set output '<OUT>.png'<br />
set xdata time<br />
set timefmt "%Y-%m-%d_%H:%M:%S"<br />
set xlabel "Verlauf"<br />
set title 'Wetter'<br />
set ylabel "Temperatur"<br />
set y2label "Luftdruck"<br />
#myDbLog BME280_42356:temperature:0:<br />
#myDbLog BME280_42356:airpressure_sealevel:0::$val=$val>1100?1100:$val<800?800:$val<br />
#myDbLog BME280_42356:humidity:0::$val=$val/2-10<br />
plot "<IN>" using 1:2 axes x1y1 title 'Temperatur' ls l0 lw 1 with lines,\<br />
"<IN>" using 1:2 axes x1y2 title 'Luftdruck' ls l1 lw 1 with lines,\<br />
"<IN>" using 1:2 axes x1y1 title 'Feuchte' ls l2 lw 1 with lines<br />
</syntaxhighlight>Dabei wird der Luftdruck auf einen plausiblen Bereich eingegrenzt, Drücke außerhalb dieses Bereichs hat es noch nicht gegeben auf diesem Erdball. Der Wert der Feuchte wird dem zu erwartenden Temperaturbereich (-10 bis 40) angeglichen, das ergibt eine schönere Kurve (:$val=$val>1100?1100:$val<800?800:$val). Eine Y-Achse für die Feuchte wäre die dritte Y-Achse, die haben wir also nicht. Also landet 100% Feuchte bei 40°C und 0% Feuchte bei -10°C (:$val=$val/2-10).<br />
<br />
Dann wird der Plot definiert. In diesem Fall mit den Daten aus DbLog, für FileLog muss geringfügig angepaßt werden. Dann fehlten freilich auch die FileLog -Definitionen für 'BME280_42356'.<syntaxhighlight><br />
defmod SVG_BME280_42356 SVG myDbLog:SVG_BME280_42356:HISTORY<br />
</syntaxhighlight>Der Term 'SVG_BME280_42356' liest dabei die Definitionen aus der vorher angelegten Datei 'SVG_BME280_42356.gplot'.<br />
<br />
====== FIN ======<br />
Viel Spaß bei den eigenen Experimenten.<br />
<br />
==Quellen==<br />
<references /><br />
<br />
[[Kategorie:Glossary]]</div>GRZBRZhttp://wiki.fhem.de/w/index.php?title=ECMD&diff=33411ECMD2020-06-22T17:27:23Z<p>GRZBRZ: </p>
<hr />
<div>ECMD bedeutet "Ethersex Command"<ref>[http://www.ethersex.de/index.php/Main_Page_%28Deutsch%29 Ethersex.de]</ref> und ist laut FHEM-Dokumentation<br />
"Any physical device with request/response-like communication capabilities over a TCP connection"<ref>{{Link2CmdRef|Anker=ECMD|Label=FHEM Commandref}}</ref>, das heisst, irgendein physisches Gerät, welches request/response-artige Kommunikationsfähigkeiten aufweist, sei es über eine TCP-Verbindung (Netzwerk) oder eine serielle Schnittstelle.<br />
<br />
In FHEM sind enthalten:<br />
* Modul [[ECMD (Modul)|ECMD]] für die Bearbeitung physischer I/O-Schnittstellengeräte und<br />
* Modul [[ECMDDevice]] für einzelne logische Geräte, deren Kommunikation über ein ECMD-Gerät läuft<br />
<br />
==Beispiele & Links==<br />
Siehe {{Link2Forum|Topic= 60753 |Message=521462|LinkText=Thread im FHEM-Forum}}<br />
<br />
Siehe [[Radioaktivitätsmessung mit DIYGeigerCounter]]<br />
<br />
=== DIY Sensor via HC-12 ===<br />
Ein BME280 Temperatur/Druck/Feuchte-Sensor liefert via eines HC-12 Pärchens seine Daten an der seriellen Schnittstelle eines RasPi ab. Der Sketch im Nano, an dem sowohl der BME280 als auch einer der HC-12 hängen, liefert alle 10 Minuten ein Datagramm ab und schickt seinen Wirt in den Tiefschlaf bis zum nächsten Datagramm, um mit den notwendigen Batterien über ein Jahr aushalten zu können.<br />
<br />
Das Datagramm hat die Form <br />
DevId T-3.45°C P995.31hPa H63.27%RH\r\n<br />
Daraus werden die notwendigen Definitionen für eine Klassendefinition abgeleitet. Die z.B. unter '/opt/fhem/BME280.classdef' abgelegte Datei erhält den Inhalt<syntaxhighlight line="1"><br />
params devId<br />
reading temperature match "%devId\sT([-+.,0-9]+)\S+\sP([-+.,0-9]+)\S+\sH([-+.,0-9]+)\S+\r?\n"<br />
reading temperature postproc { /%devId\sT([-+.,0-9]+)\S+\sP([-+.,0-9]+)\S+\sH([-+.,0-9]+)\S+\r?\n/; $1 }<br />
reading airpressure match "%devId\sT([-+.,0-9]+)\S+\sP([-+.,0-9]+)\S+\sH([-+.,0-9]+)\S+\r?\n"<br />
reading airpressure postproc { /%devId\sT([-+.,0-9]+)\S+\sP([-+.,0-9]+)\S+\sH([-+.,0-9]+)\S+\r?\n/; $2 }<br />
reading humidity match "%devId\sT([-+.,0-9]+)\S+\sP([-+.,0-9]+)\S+\sH([-+.,0-9]+)\S+\r?\n"<br />
reading humidity postproc { /%devId\sT([-+.,0-9]+)\S+\sP([-+.,0-9]+)\S+\sH([-+.,0-9]+)\S+\r?\n/; $3 }<br />
state humidity<br />
</syntaxhighlight>Die regex ist in allen Zeilen der Einfachheit zuliebe gleich gehalten, bei den match könnte man freilich die Klammern löschen und bei den postproc auf ein Paar reduzieren und $_ gleichmäßig mit $1 befüllen. Geschmackssache. Alle Werte werden durch diese Vorgehensweise gleichzeitig und erst dann gelesen, wenn das gesamte Datagramm eingetroffen ist. Es ließe sich auch auf Teil-Strings abfragen, Konflikte bei mehreren Sensoren sind dann denkbar.<br />
<br />
Die letzte Zeile sorgt dafür, dass der state nur dann einen neuen Wert erhält, wenn (in diesem Fall) 'humidity' ein Update erfährt. Bei den gewählten regex trift das hier eigentlich für alle zu, aber da humidity der letzte übertragene Wert ist, ist die Wahl auf ihn gefallen. Außerdem steht nun nur ein Wert im state ohne einleitenden reading Namen, der wäre hier im Beispiel erwartungsgemäß 'humidity', was hier insofern irritiert, weil ja 3 Werte gelesen wurden und man sich unwillkürlich fragt, wo den die anderen geblieben sind. Zum state daher später noch weiteres.<br />
<br />
Sollte bereits eine ECMD Schnittstelle bestehen, kann nun die Definition hinzugefügt werden. Z.B. die ECMD Schnittstelle namens 'SerDevDef' erhält eine zusätzliche Klasse 'BME280' mit den Definitionen aus der vorher generierten Datei, Beispiel siehe oben.<syntaxhighlight><br />
set SerDevDef classdef BME280 /opt/fhem/BME280.classdef<br />
<br />
</syntaxhighlight>Ist noch keine ECMD Schnittstelle definiert, wird diese erstellt und gleich mit passenden Attributen versehen.<syntaxhighlight><br />
define SerDevDef ECMD serial /dev/ttyS0@9600<br />
set SerDevDef classdef BME280 /opt/fhem/BME280.classdef<br />
attr SerDevDef partial 2<br />
<br />
</syntaxhighlight>Die letzte Zeile ist für die serielle Schnittstelle gerade bei längeren Datagrammen ein Muss. Sie sorgt dafür, dass die kleineren Informationsbröckchen zu einer vollständigen Einheit werden. Kommt das nächste Päckchen innerhalb von (hier) 2 Sekunden, wird das neue Päckchen an die bereits gelesenen Daten angehängt, ansonsten startet eine neue Aufzeichnung beginnend mit dem Päckchen.<br />
<br />
Für den Start kann noch zur Erleichterung der Fehlersuche folgendes ergänzt werden<syntaxhighlight><br />
attr SerDevDef logTraffic 5<br />
attr SerDevDef verbose 5<br />
</syntaxhighlight>Rückstelllen dieser Attribute nicht vergessen, so ist's reichlich gesprächig und füllt schnell das Log !!!<br />
<br />
Damit ist alles vorbereitet den ECMD Device zu erstellen.<syntaxhighlight><br />
define BME280_42356 ECMDDevice BME280 42356<br />
attr BME280_42356 alias Gartenhaus<br />
attr BME280_42356 room Grundstück<br />
attr BME280_42356 IODev SerDevDef <br />
attr BME280_42356 userReadings airpressure_sealevel { sprintf("%.2f", ReadingsVal("BME280_42356","pressure",0)*1.023);; }<br />
</syntaxhighlight>Der fragliche Sensor beginnt seine Datagramme immer mit '42356', das ist seine DevId, die über den Parameter 'devId' in der Klassendefinition (siehe oben) Eingang in die readings findet. Über 'BME280' wird die Klassendefinition festgelegt, über '42356' die devId. Sinnigerweise wird im Beispiel hier 'BME280_42356' als Devicename festgelegt, Systematik ist Trumpf.<br />
<br />
Die letzte Zeile macht aus dem vom Sensor gemessenen Luftdruck noch den auf NormalNull Bezogenen. Nicht jeder wohnt direkt am Meer und kann auf diesen Schritt verzichten. Ansonsten weichen die Werte des Sensors immer von der Wettervorhersage ab, je höher der Sensor, um so markanter. Das Beispiel hier gilt für ca. 160m üNN.<br />
<br />
Da der state nach einer Übermittlung aufgrund der Festlegungen aus der Klassendefinition nun nur den Wert der Luftfeuchte enthält, ist es hilfreich ein 'notify' für eine gefälligere Darstellung zu definieren.<syntaxhighlight><br />
define ECMDDevState notify BME280_42356:humidity:.* { Log 1, "$NAME has new values";;sleep 1;;fhem "setstate BME280_42356"." T:".ReadingsVal("BME280_42356","temperature",0)." P:".ReadingsVal("BME280_42356","airpressure_sealevel",0)." H:".ReadingsVal("BME280_42356","humidity",0) }<br />
</syntaxhighlight>Für die Übersicht zerlegt:<syntaxhighlight lang="perl" line="1" start="1"><br />
define ECMDDevState notify BME280_42356:humidity:.* <br />
{<br />
Log 1, "$NAME has new values";;<br />
sleep 1;;<br />
fhem "setstate BME280_42356".<br />
" T:".ReadingsVal("BME280_42356","temperature",0).<br />
" P:".ReadingsVal("BME280_42356","airpressure_sealevel",0).<br />
" H:".ReadingsVal("BME280_42356","humidity",0)<br />
}<br />
<br />
</syntaxhighlight>&#x2460; 'ECMDDevState' wird immer dann benachrichtigt und ausgeführt, wenn der Device 'BME280_42356' ein reading 'humidity' mit einem beliebigen (.*) Wert hat. &#x2462; Dies wird zunächst im Log vermerkt und &#x2463; als nächstes ein wenig gewartet, damit eine Änderung des state auf jeden Fall nach dem Befüllen des state durch das humidity reading stattfindet und auch der Luftdruck fertig berechnet ist. Dann wird &#x2464; der state mit einer Verkettung der gerade gelesenen bzw. berechneten Daten aller Werte &#x2465;,&#x2466;,&#x2467; versorgt.<br />
<br />
Abschließend soll noch ein Plot der Messwerte gemacht werden, eine Kurve liest sich leichter. Als Erstes wird eine Datei z.B. '/opt/fhem/www/gplot/SVG_BME280_42356.gplot' mit folgendem Inhalt erstellt, der anzuzeigenden Linien und Beschriftungen des Plots beschreibt.<syntaxhighlight><br />
set terminal png transparent size <SIZE> crop<br />
set output '<OUT>.png'<br />
set xdata time<br />
set timefmt "%Y-%m-%d_%H:%M:%S"<br />
set xlabel "Verlauf"<br />
set title 'Wetter'<br />
set ylabel "Temperatur"<br />
set y2label "Luftdruck"<br />
#myDbLog BME280_42356:temperature:0:<br />
#myDbLog BME280_42356:airpressure_sealevel:0::$val=$val>1100?1100:$val<800?800:$val<br />
#myDbLog BME280_42356:humidity:0::$val=$val/2-10<br />
plot "<IN>" using 1:2 axes x1y1 title 'Temperatur' ls l0 lw 1 with lines,\<br />
"<IN>" using 1:2 axes x1y2 title 'Luftdruck' ls l1 lw 1 with lines,\<br />
"<IN>" using 1:2 axes x1y1 title 'Feuchte' ls l2 lw 1 with lines<br />
</syntaxhighlight>Dabei wird der Luftdruck auf einen plausiblen Bereich eingegrenzt, Drücke außerhalb dieses Bereichs hat es noch nicht gegeben auf diesem Erdball. Der Wert der Feuchte wird dem zu erwartenden Temperaturbereich (-10 bis 40) angeglichen, das ergibt eine schönere Kurve (:$val=$val>1100?1100:$val<800?800:$val). Eine Y-Achse für die Feuchte wäre die dritte Y-Achse, die haben wir also nicht. Also landet 100% Feuchte bei 40°C und 0% Feuchte bei -10°C (:$val=$val/2-10).<br />
<br />
Dann wird der Plot definiert. In diesem Fall mit den Daten aus DbLog, für FileLog muss geringfügig angepaßt werden. Dann fehlten freilich auch die FileLog -Definitionen für 'BME280_42356'.<syntaxhighlight><br />
defmod SVG_BME280_42356 SVG myDbLog:SVG_BME280_42356:HISTORY<br />
</syntaxhighlight>Der Term 'SVG_BME280_42356' liest dabei die Definitionen aus der vorher angelegten Datei 'SVG_BME280_42356.gplot'.<br />
<br />
Viel Spaß bei den eigenen Experimenten.<br />
<br />
==Quellen==<br />
<references /><br />
<br />
[[Kategorie:Glossary]]</div>GRZBRZhttp://wiki.fhem.de/w/index.php?title=ECMD&diff=33409ECMD2020-06-22T16:16:28Z<p>GRZBRZ: </p>
<hr />
<div>ECMD bedeutet "Ethersex Command"<ref>[http://www.ethersex.de/index.php/Main_Page_%28Deutsch%29 Ethersex.de]</ref> und ist laut FHEM-Dokumentation<br />
"Any physical device with request/response-like communication capabilities over a TCP connection"<ref>{{Link2CmdRef|Anker=ECMD|Label=FHEM Commandref}}</ref>, das heisst, irgendein physisches Gerät, welches request/response-artige Kommunikationsfähigkeiten aufweist, sei es über eine TCP-Verbindung (Netzwerk) oder eine serielle Schnittstelle.<br />
<br />
In FHEM sind enthalten:<br />
* Modul [[ECMD (Modul)|ECMD]] für die Bearbeitung physischer I/O-Schnittstellengeräte und<br />
* Modul [[ECMDDevice]] für einzelne logische Geräte, deren Kommunikation über ein ECMD-Gerät läuft<br />
<br />
==Beispiele & Links==<br />
Siehe {{Link2Forum|Topic= 60753 |Message=521462|LinkText=Thread im FHEM-Forum}}<br />
<br />
Siehe [[Radioaktivitätsmessung mit DIYGeigerCounter]]<br />
<br />
=== DIY Sensor via HC-12 ===<br />
Ein BME280 Temperatur/Druck/Feuchte-Sensor liefert via eines HC-12 Pärchens seine Daten an der seriellen Schnittstelle eines RasPi ab. Der Sketch im Nano, an dem sowohl der BME280 als auch einer der HC-12 hängen, liefert alle 10 Minuten ein Datagramm ab und schickt seinen Wirt in den Tiefschlaf bis zum nächsten Datagramm, um mit den notwendigen Batterien über ein Jahr aushalten zu können.<br />
<br />
Das Datagramm hat die Form <br />
DevId T-3.45°C P995.31hPa H63.27%RH\r\n<br />
Daraus werden die notwendigen Definitionen für eine Klassendefinition abgeleitet. Die z.B. unter '/opt/fhem/BME280.classdef' abgelegte Datei erhält den Inhalt<syntaxhighlight line="1"><br />
params devId<br />
reading temperature match "%devId\sT([-+.,0-9]+)\S+\sP([-+.,0-9]+)\S+\sH([-+.,0-9]+)\S+\r?\n"<br />
reading temperature postproc { /%devId\sT([-+.,0-9]+)\S+\sP([-+.,0-9]+)\S+\sH([-+.,0-9]+)\S+\r?\n/; $1 }<br />
reading airpressure match "%devId\sT([-+.,0-9]+)\S+\sP([-+.,0-9]+)\S+\sH([-+.,0-9]+)\S+\r?\n"<br />
reading airpressure postproc { /%devId\sT([-+.,0-9]+)\S+\sP([-+.,0-9]+)\S+\sH([-+.,0-9]+)\S+\r?\n/; $2 }<br />
reading humidity match "%devId\sT([-+.,0-9]+)\S+\sP([-+.,0-9]+)\S+\sH([-+.,0-9]+)\S+\r?\n"<br />
reading humidity postproc { /%devId\sT([-+.,0-9]+)\S+\sP([-+.,0-9]+)\S+\sH([-+.,0-9]+)\S+\r?\n/; $3 }<br />
state humidity<br />
</syntaxhighlight>Die regex ist in allen Zeilen der Einfachheit zuliebe gleich gehalten, bei den match könnte man freilich die Klammern löschen und bei den postproc auf ein Paar reduzieren und $_ gleichmäßig mit $1 befüllen. Geschmackssache. Alle Werte werden durch diese Vorgehensweise gleichzeitig und erst dann gelesen, wenn das gesamte Datagramm eingetroffen ist. Es ließe sich auch auf Teil-Strings abfragen, Konflikte bei mehreren Sensoren sind dann denkbar.<br />
<br />
Die letzte Zeile sorgt dafür, dass der state nur dann einen neuen Wert erhält, wenn (in diesem Fall) 'humidity' ein Update erfährt. Bei den gewählten regex trift das hier eigentlich für alle zu, aber da humidity der letzte übertragene Wert ist, ist die Wahl auf ihn gefallen. Außerdem steht nun nur ein Wert im state ohne einleitenden reading Namen, der wäre hier im Beispiel erwartungsgemäß 'humidity', was hier insofern irritiert, weil ja 3 Werte gelesen wurden und man sich unwillkürlich fragt, wo den die anderen geblieben sind. Zum state daher später noch weiteres.<br />
<br />
Sollte bereits eine ECMD Schnittstelle bestehen, kann nun die Definition hinzugefügt werden. Z.B. die ECMD Schnittstelle namens 'SerDevDef' erhält eine zusätzliche Klasse 'BME280' mit den Definitionen aus der vorher generierten Datei, Beispiel siehe oben.<syntaxhighlight><br />
set SerDevDef classdef BME280 /opt/fhem/BME280.classdef<br />
<br />
</syntaxhighlight>Ist noch keine ECMD Schnittstelle definiert, wird diese erstellt und gleich mit passenden Attributen versehen.<syntaxhighlight><br />
define SerDevDef ECMD serial /dev/ttyS0@9600<br />
set SerDevDef classdef BME280 /opt/fhem/BME280.classdef<br />
attr SerDevDef partial 2<br />
<br />
</syntaxhighlight>Die letzte Zeile ist für die serielle Schnittstelle gerade bei längeren Datagrammen ein Muss. Sie sorgt dafür, dass die kleineren Informationsbröckchen zu einer vollständigen Einheit werden. Kommt das nächste Päckchen innerhalb von (hier) 2 Sekunden, wird das neue Päckchen an die bereits gelesenen Daten angehängt, ansonsten startet eine neue Aufzeichnung beginnend mit dem Päckchen.<br />
<br />
Für den Start kann noch zur Erleichterung der Fehlersuche folgendes ergänzt werden<syntaxhighlight><br />
attr SerDevDef logTraffic 5<br />
attr SerDevDef verbose 5<br />
</syntaxhighlight>Rückstelllen dieser Attribute nicht vergessen, so ist's reichlich gesprächig und füllt schnell das Log !!!<br />
<br />
Damit ist alles vorbereitet den ECMD Device zu erstellen.<syntaxhighlight><br />
define BME280_42356 ECMDDevice BME280 42356<br />
attr BME280_42356 alias Gartenhaus<br />
attr BME280_42356 room Grundstück<br />
attr BME280_42356 IODev SerDevDef <br />
attr BME280_42356 userReadings airpressure_sealevel { sprintf("%.2f", ReadingsVal("BME280_42356","pressure",0)*1.023);; }<br />
</syntaxhighlight>Der fragliche Sensor beginnt seine Datagramme immer mit '42356', das ist seine DevId, die über den Parameter 'devId' in der Klassendefinition (siehe oben) Eingang in die readings findet. Über 'BME280' wird die Klassendefinition festgelegt, über '42356' die devId. Sinnigerweise wird im Beispiel hier 'BME280_42356' als Devicename festgelegt, Systematik ist Trumpf.<br />
<br />
Die letzte Zeile macht aus dem vom Sensor gemessenen Luftdruck noch den auf NormalNull Bezogenen. Nicht jeder wohnt direkt am Meer und kann auf diesen Schritt verzichten. Ansonsten weichen die Werte des Sensors immer von der Wettervorhersage ab, je höher der Sensor, um so markanter. Das Beispiel hier gilt für ca. 160m üNN.<br />
<br />
Da der state nach einer Übermittlung aufgrund der Festlegungen aus der Klassendefinition nun nur den Wert der Luftfeuchte enthält, ist es hilfreich ein 'notify' für eine gefälligere Darstellung zu definieren.<syntaxhighlight><br />
define ECMDDevState notify BME280_42356:humidity:.* { Log 1, "$NAME has new values";;sleep 1;;fhem "setstate BME280_42356"." T:".ReadingsVal("BME280_42356","temperature",0)." P:".ReadingsVal("BME280_42356","airpressure_sealevel",0)." H:".ReadingsVal("BME280_42356","humidity",0) }<br />
</syntaxhighlight>Für die Übersicht zerlegt:<syntaxhighlight lang="perl" line="1" start="1"><br />
define ECMDDevState notify BME280_42356:humidity:.* <br />
{<br />
Log 1, "$NAME has new values";;<br />
sleep 1;;<br />
fhem "setstate BME280_42356".<br />
" T:".ReadingsVal("BME280_42356","temperature",0).<br />
" P:".ReadingsVal("BME280_42356","airpressure_sealevel",0).<br />
" H:".ReadingsVal("BME280_42356","humidity",0)<br />
}<br />
<br />
</syntaxhighlight>&#x2460; 'ECMDDevState' wird immer dann benachrichtigt und ausgeführt, wenn der Device 'BME280_42356' ein reading 'humidity' mit einem beliebigen (.*) Wert hat. &#x2462; Dies wird zunächst im Log vermerkt und &#x2463; als nächstes ein wenig gewartet, damit eine Änderung des state auf jeden Fall nach dem Befüllen des state durch das humidity reading stattfindet und auch der Luftdruck fertig berechnet ist. Dann wird &#x2464; der state mit einer Verkettung der gerade gelesenen bzw. berechneten Daten aller Werte &#x2465;,&#x2466;,&#x2467; versorgt.<br />
<br />
.<br />
<br />
Abschließend soll noch ein Plot der Messwerte gemacht werden, eine Kurve liest sich leichter. Als Erstes wird eine Datei z.B. '/opt/fhem/www/gplot/SVG_BME280_42356.gplot' mit folgendem Inhalt erstellt, der anzuzeigenden Linien und Beschriftungen des Plots beschreibt, .<syntaxhighlight><br />
set terminal png transparent size <SIZE> crop<br />
set output '<OUT>.png'<br />
set xdata time<br />
set timefmt "%Y-%m-%d_%H:%M:%S"<br />
set xlabel "Verlauf"<br />
set title 'Wetter'<br />
set ylabel "Temperatur"<br />
set y2label "Luftdruck"<br />
#myDbLog BME280_42356:temperature:0:<br />
#myDbLog BME280_42356:airpressure_sealevel:0::$val=$val>1100?1100:$val<800?800:$val<br />
#myDbLog BME280_42356:humidity:0::$val=$val/2-10<br />
plot "<IN>" using 1:2 axes x1y1 title 'Temperatur' ls l0 lw 1 with lines,\<br />
"<IN>" using 1:2 axes x1y2 title 'Luftdruck' ls l1 lw 1 with lines,\<br />
"<IN>" using 1:2 axes x1y1 title 'Feuchte' ls l2 lw 1 with lines<br />
</syntaxhighlight>Dann wird der Plot definiert. In diesem Fall mit den Daten aus DbLog, für FileLog muss geringfügig angepaßt werden. Dann fehlten freilich auch die FileLog -Definitionen für 'BME280_42356'.<syntaxhighlight><br />
defmod SVG_BME280_42356 SVG myDbLog:SVG_BME280_42356:HISTORY<br />
</syntaxhighlight>Der Term 'SVG_BME280_42356' liest dabei die Definitionen aus der vorher angelegten Datei 'SVG_BME280_42356.gplot'.<br />
<br />
Viel Spaß bei den eigenen Experimenten.<br />
<br />
==Quellen==<br />
<references /><br />
<br />
[[Kategorie:Glossary]]</div>GRZBRZhttp://wiki.fhem.de/w/index.php?title=ECMD&diff=33408ECMD2020-06-22T12:11:23Z<p>GRZBRZ: </p>
<hr />
<div>ECMD bedeutet "Ethersex Command"<ref>[http://www.ethersex.de/index.php/Main_Page_%28Deutsch%29 Ethersex.de]</ref> und ist laut FHEM-Dokumentation<br />
"Any physical device with request/response-like communication capabilities over a TCP connection"<ref>{{Link2CmdRef|Anker=ECMD|Label=FHEM Commandref}}</ref>, das heisst, irgendein physisches Gerät, welches request/response-artige Kommunikationsfähigkeiten aufweist, sei es über eine TCP-Verbindung (Netzwerk) oder eine serielle Schnittstelle.<br />
<br />
In FHEM sind enthalten:<br />
* Modul [[ECMD (Modul)|ECMD]] für die Bearbeitung physischer I/O-Schnittstellengeräte und<br />
* Modul [[ECMDDevice]] für einzelne logische Geräte, deren Kommunikation über ein ECMD-Gerät läuft<br />
<br />
==Beispiele & Links==<br />
Siehe {{Link2Forum|Topic= 60753 |Message=521462|LinkText=Thread im FHEM-Forum}}<br />
<br />
Siehe [[Radioaktivitätsmessung mit DIYGeigerCounter]]<br />
<br />
=== DIY Sensor via HC-12 ===<br />
Ein BME280 Temperatur/Druck/Feuchte-Sensor liefert via eines HC-12 Pärchens seine Daten an der seriellen Schnittstelle eines RasPi ab. Der Sketch im Nano, an dem sowohl der BME280 als auch einer der HC-12 hängen, liefert alle 10 Minuten ein Datagramm ab und schickt seinen Wirt in den Tiefschlaf bis zum nächsten Datagramm, um mit den notwendigen Batterien über ein Jahr aushalten zu können.<br />
<br />
Das Datagramm hat die Form <br />
DevId T-3.45°C P995.31hPa H63.27%RH\r\n<br />
Daraus werden die notwendigen Definitionen für eine Klassendefinition abgeleitet. Die z.B. unter '/opt/fhem/BME280.classdef' abgelegte Datei erhält den Inhalt<syntaxhighlight line="1"><br />
params devId<br />
reading temperature match "%devId\sT([-+.,0-9]+)\S+\sP([-+.,0-9]+)\S+\sH([-+.,0-9]+)\S+\r?\n"<br />
reading temperature postproc { /%devId\sT([-+.,0-9]+)\S+\sP([-+.,0-9]+)\S+\sH([-+.,0-9]+)\S+\r?\n/; $1 }<br />
reading airpressure match "%devId\sT([-+.,0-9]+)\S+\sP([-+.,0-9]+)\S+\sH([-+.,0-9]+)\S+\r?\n"<br />
reading airpressure postproc { /%devId\sT([-+.,0-9]+)\S+\sP([-+.,0-9]+)\S+\sH([-+.,0-9]+)\S+\r?\n/; $2 }<br />
reading humidity match "%devId\sT([-+.,0-9]+)\S+\sP([-+.,0-9]+)\S+\sH([-+.,0-9]+)\S+\r?\n"<br />
reading humidity postproc { /%devId\sT([-+.,0-9]+)\S+\sP([-+.,0-9]+)\S+\sH([-+.,0-9]+)\S+\r?\n/; $3 }<br />
state humidity<br />
</syntaxhighlight>Die regex ist in allen Zeilen der Einfachheit zuliebe gleich gehalten, bei den match könnte man freilich die Klammern löschen und bei den postproc auf ein Paar reduzieren und $_ gleichmäßig mit $1 befüllen. Geschmackssache. Alle Werte werden durch diese Vorgehensweise gleichzeitig und erst dann gelesen, wenn das gesamte Datagramm eingetroffen ist. Es ließe sich auch auf Teil-Strings abfragen, Konflikte bei mehreren Sensoren sind dann denkbar.<br />
<br />
Die letzte Zeile sorgt dafür, dass der state nur dann einen neuen Wert erhält, wenn (in diesem Fall) 'humidity' ein Update erfährt. Bei den gewählten regex trift das hier eigentlich für alle zu, aber da humidity der letzte übertragene Wert ist, ist die Wahl auf ihn gefallen. Außerdem steht nun nur ein Wert im state ohne einleitenden reading Namen, der wäre hier im Beispiel erwartungsgemäß 'humidity', was hier insofern irritiert, weil ja 3 Werte gelesen wurden und man sich unwillkürlich fragt, wo den die anderen geblieben sind. Zum state daher später noch weiteres.<br />
<br />
Sollte bereits eine ECMD Schnittstelle bestehen, kann nun die Definition hinzugefügt werden. Z.B. die ECMD Schnittstelle namens 'SerDevDef' erhält eine zusätzliche Klasse 'BME280' mit den Definitionen aus der vorher generierten Datei, Beispiel siehe oben.<syntaxhighlight><br />
set SerDevDef classdef BME280 /opt/fhem/BME280.classdef<br />
<br />
</syntaxhighlight>Ist noch keine ECMD Schnittstelle definiert, wird diese erstellt und gleich mit passenden Attributen versehen.<syntaxhighlight><br />
define SerDevDef ECMD serial /dev/ttyS0@9600<br />
set SerDevDef classdef BME280 /opt/fhem/BME280.classdef<br />
attr SerDevDef partial 2<br />
<br />
</syntaxhighlight>Die letzte Zeile ist für die serielle Schnittstelle gerade bei längeren Datagrammen ein Muss. Sie sorgt dafür, dass die kleineren Informationsbröckchen zu einer vollständigen Einheit werden. Kommt das nächste Päckchen innerhalb von (hier) 2 Sekunden, wird das neue Päckchen an die bereits gelesenen Daten angehängt, ansonsten startet eine neue Aufzeichnung beginnend mit dem Päckchen.<br />
<br />
Für den Start kann noch zur Erleichterung der Fehlersuche folgendes ergänzt werden<syntaxhighlight><br />
attr SerDevDef logTraffic 5<br />
attr SerDevDef verbose 5<br />
</syntaxhighlight>Rückstelllen dieser Attribute nicht vergessen, so ist's reichlich gesprächig und füllt schnell das Log !!!<br />
<br />
Damit ist alles vorbereitet den ECMD Device zu erstellen.<syntaxhighlight><br />
define BME280_42356 ECMDDevice BME280 42356<br />
attr BME280_42356 alias Gartenhaus<br />
attr BME280_42356 room Grundstück<br />
attr BME280_42356 IODev SerDevDef <br />
attr BME280_42356 userReadings airpressure_sealevel { sprintf("%.2f", ReadingsVal("BME280_42356","pressure",0)*1.023);; }<br />
</syntaxhighlight>Der fragliche Sensor beginnt seine Datagramme immer mit '42356', das ist seine DevId, die über den Parameter 'devId' in der Klassendefinition (siehe oben) Eingang in die readings findet. Über 'BME280' wird die Klassendefinition festgelegt, über '42356' die devId. Sinnigerweise wird im Beispiel hier 'BME280_42356' als Devicename festgelegt, Systematik ist Trumpf.<br />
<br />
Die letzte Zeile macht aus dem vom Sensor gemessenen Luftdruck noch den auf NormalNull Bezogenen. Nicht jeder wohnt direkt am Meer und kann auf diesen Schritt verzichten. Ansonsten weichen die Werte des Sensors immer von der Wettervorhersage ab, je höher der Sensor, um so markanter. Das Beispiel hier gilt für ca. 160m üNN.<br />
<br />
Da der state nach einer Übermittlung aufgrund der Festlegungen aus der Klassendefinition nun nur den Wert der Luftfeuchte enthält, ist es hilfreich ein 'notify' für eine gefälligere Darstellung zu definieren.<syntaxhighlight><br />
define ECMDDevState notify BME280_42356:humidity:.* { Log 1, "$NAME has new values";;sleep 1;;fhem "setstate BME280_42356"." T:".ReadingsVal("BME280_42356","temperature",0)." P:".ReadingsVal("BME280_42356","airpressure_sealevel",0)." H:".ReadingsVal("BME280_42356","humidity",0) }<br />
</syntaxhighlight>Für die Übersicht zerlegt:<syntaxhighlight lang="perl" line="1" start="1"><br />
define ECMDDevState notify BME280_42356:humidity:.* <br />
{<br />
Log 1, "$NAME has new values";;<br />
sleep 1;;<br />
fhem "setstate BME280_42356".<br />
" T:".ReadingsVal("BME280_42356","temperature",0).<br />
" P:".ReadingsVal("BME280_42356","airpressure_sealevel",0).<br />
" H:".ReadingsVal("BME280_42356","humidity",0)<br />
}<br />
<br />
</syntaxhighlight>&#x2460; 'ECMDDevState' wird immer dann benachrichtigt und ausgeführt, wenn der Device 'BME280_42356' ein reading 'humidity' mit einem beliebigen (.*) Wert hat. &#x2462; Dies wird zunächst im Log vermerkt und &#x2463; als nächstes ein wenig gewartet, damit eine Änderung des state auf jeden Fall nach dem Befüllen des state durch das humidity reading stattfindet und auch der Luftdruck fertig berechnet ist. Dann wird &#x2464; der state mit einer Verkettung der gerade gelesenen bzw. berechneten Daten aller Werte &#x2465;,&#x2466;,&#x2467; versorgt.<br />
<br />
Abschließend soll noch ein Plot der Messwerte gemacht werden, eine Kurve liest sich leichter. Als Erstes wird eine Datei z.B. '/opt/fhem/www/gplot/SVG_BME280_42356.gplot' mit folgendem Inhalt erstellt, der anzuzeigenden Linien und Beschriftungen des Plots beschreibt, .<syntaxhighlight><br />
set terminal png transparent size <SIZE> crop<br />
set output '<OUT>.png'<br />
set xdata time<br />
set timefmt "%Y-%m-%d_%H:%M:%S"<br />
set xlabel "Verlauf"<br />
set title 'Wetter'<br />
set ylabel "Temperatur"<br />
set y2label "Luftdruck"<br />
#myDbLog BME280_42356:temperature:0:<br />
#myDbLog BME280_42356:airpressure_sealevel:0::$val=$val>1100?1100:$val<800?800:$val<br />
#myDbLog BME280_42356:humidity:0::$val=$val/2-10<br />
plot "<IN>" using 1:2 axes x1y1 title 'Temperatur' ls l0 lw 1 with lines,\<br />
"<IN>" using 1:2 axes x1y2 title 'Luftdruck' ls l1 lw 1 with lines,\<br />
"<IN>" using 1:2 axes x1y1 title 'Feuchte' ls l2 lw 1 with lines<br />
</syntaxhighlight>Dann wird der Plot definiert. In diesem Fall mit den Daten aus DbLog, für FileLog muss geringfügig angepaßt werden. Dann fehlten freilich auch die FileLog -Definitionen für 'BME280_42356'.<syntaxhighlight><br />
defmod SVG_BME280_42356 SVG myDbLog:SVG_BME280_42356:HISTORY<br />
</syntaxhighlight>Der Term 'SVG_BME280_42356' liest dabei die Definitionen aus der vorher angelegten Datei 'SVG_BME280_42356.gplot'.<br />
<br />
Viel Spaß bei den eigenen Experimenten.<br />
<br />
==Quellen==<br />
<references /><br />
<br />
[[Kategorie:Glossary]]</div>GRZBRZhttp://wiki.fhem.de/w/index.php?title=ECMD&diff=33407ECMD2020-06-22T12:08:31Z<p>GRZBRZ: </p>
<hr />
<div>ECMD bedeutet "Ethersex Command"<ref>[http://www.ethersex.de/index.php/Main_Page_%28Deutsch%29 Ethersex.de]</ref> und ist laut FHEM-Dokumentation<br />
"Any physical device with request/response-like communication capabilities over a TCP connection"<ref>{{Link2CmdRef|Anker=ECMD|Label=FHEM Commandref}}</ref>, das heisst, irgendein physisches Gerät, welches request/response-artige Kommunikationsfähigkeiten aufweist, sei es über eine TCP-Verbindung (Netzwerk) oder eine serielle Schnittstelle.<br />
<br />
In FHEM sind enthalten:<br />
* Modul [[ECMD (Modul)|ECMD]] für die Bearbeitung physischer I/O-Schnittstellengeräte und<br />
* Modul [[ECMDDevice]] für einzelne logische Geräte, deren Kommunikation über ein ECMD-Gerät läuft<br />
<br />
==Beispiele & Links==<br />
Siehe {{Link2Forum|Topic= 60753 |Message=521462|LinkText=Thread im FHEM-Forum}}<br />
<br />
Siehe [[Radioaktivitätsmessung mit DIYGeigerCounter]]<br />
<br />
=== DIY Sensor via HC-12 ===<br />
Ein BME280 Temperatur/Druck/Feuchte-Sensor liefert via eines HC-12 Pärchens seine Daten an der seriellen Schnittstelle eines RasPi ab. Der Sketch im Nano, an dem sowohl der BME280 als auch einer der HC-12 hängen, liefert alle 10 Minuten ein Datagramm ab und schickt seinen Wirt in den Tiefschlaf bis zum nächsten Datagramm, um mit den notwendigen Batterien über ein Jahr aushalten zu können.<br />
<br />
Das Datagramm hat die Form <br />
DevId T-3.45°C P995.31hPa H63.27%RH\r\n<br />
Daraus werden die notwendigen Definitionen für eine Klassendefinition abgeleitet. Die z.B. unter '/opt/fhem/BME280.classdef' abgelegte Datei erhält den Inhalt<syntaxhighlight line="1"><br />
params devId<br />
reading temperature match "%devId\sT([-+.,0-9]+)\S+\sP([-+.,0-9]+)\S+\sH([-+.,0-9]+)\S+\r?\n"<br />
reading temperature postproc { /%devId\sT([-+.,0-9]+)\S+\sP([-+.,0-9]+)\S+\sH([-+.,0-9]+)\S+\r?\n/; $1 }<br />
reading airpressure match "%devId\sT([-+.,0-9]+)\S+\sP([-+.,0-9]+)\S+\sH([-+.,0-9]+)\S+\r?\n"<br />
reading airpressure postproc { /%devId\sT([-+.,0-9]+)\S+\sP([-+.,0-9]+)\S+\sH([-+.,0-9]+)\S+\r?\n/; $2 }<br />
reading humidity match "%devId\sT([-+.,0-9]+)\S+\sP([-+.,0-9]+)\S+\sH([-+.,0-9]+)\S+\r?\n"<br />
reading humidity postproc { /%devId\sT([-+.,0-9]+)\S+\sP([-+.,0-9]+)\S+\sH([-+.,0-9]+)\S+\r?\n/; $3 }<br />
state humidity<br />
</syntaxhighlight>Die regex ist in allen Zeilen der Einfachheit zuliebe gleich gehalten, bei den match könnte man freilich die Klammern löschen und bei den postproc auf ein Paar reduzieren und $_ gleichmäßig mit $1 befüllen. Geschmackssache. Alle Werte werden durch diese Vorgehensweise gleichzeitig und erst dann gelesen, wenn das gesamte Datagramm eingetroffen ist. Es ließe sich auch auf Teil-Strings abfragen, Konflikte bei mehreren Sensoren sind dann denkbar.<br />
<br />
Die letzte Zeile sorgt dafür, dass der state nur dann einen neuen Wert erhält, wenn (in diesem Fall) 'humidity' ein Update erfährt. Bei den gewählten regex trift das hier eigentlich für alle zu, aber da humidity der letzte übertragene Wert ist, ist die Wahl auf ihn gefallen. Außerdem steht nun nur ein Wert im state ohne einleitenden reading Namen, der wäre hier im Beispiel erwartungsgemäß 'humidity', was hier insofern irritiert, weil ja 3 Werte gelesen wurden und man sich unwillkürlich fragt, wo den die anderen geblieben sind. Zum state daher später noch weiteres.<br />
<br />
Sollte bereits eine ECMD Schnittstelle bestehen, kann nun die Definition hinzugefügt werden. Z.B. die ECMD Schnittstelle namens 'SerDevDef' erhält eine zusätzliche Klasse 'BME280' mit den Definitionen aus der vorher generierten Datei, Beispiel siehe oben.<syntaxhighlight><br />
set SerDevDef classdef BME280 /opt/fhem/BME280.classdef<br />
<br />
</syntaxhighlight>Ist noch keine ECMD Schnittstelle definiert, wird diese erstellt und gleich mit passenden Attributen versehen.<syntaxhighlight><br />
define SerDevDef ECMD serial /dev/ttyS0@9600<br />
set SerDevDef classdef BME280 /opt/fhem/BME280.classdef<br />
attr SerDevDef partial 2<br />
<br />
</syntaxhighlight>Die letzte Zeile ist für die serielle Schnittstelle gerade bei längeren Datagrammen ein Muss. Sie sorgt dafür, dass die kleineren Informationsbröckchen zu einer vollständigen Einheit werden. Kommt das nächste Päckchen innerhalb von (hier) 2 Sekunden, wird das neue Päckchen an die bereits gelesenen Daten angehängt, ansonsten startet eine neue Aufzeichnung beginnend mit dem Päckchen.<br />
<br />
Für den Start kann noch zur Erleichterung der Fehlersuche folgendes ergänzt werden<syntaxhighlight><br />
attr SerDevDef logTraffic 5<br />
attr SerDevDef verbose 5<br />
</syntaxhighlight>Rückstelllen dieser Attribute nicht vergessen, so ist's reichlich gesprächig und füllt schnell das Log !!!<br />
<br />
Damit ist alles vorbereitet den ECMD Device zu erstellen.<syntaxhighlight><br />
define BME280_42356 ECMDDevice BME280 42356<br />
attr BME280_42356 alias Gartenhaus<br />
attr BME280_42356 room Grundstück<br />
attr BME280_42356 IODev SerDevDef <br />
attr BME280_42356 userReadings airpressure_sealevel { sprintf("%.2f", ReadingsVal("BME280_42356","pressure",0)*1.023);; }<br />
</syntaxhighlight>Der fragliche Sensor beginnt seine Datagramme immer mit '42356', das ist seine DevId, die über den Parameter 'devId' in der Klassendefinition (siehe oben) Eingang in die readings findet. Über 'BME280' wird die Klassendefinition festgelegt, über '42356' die devId. Sinnigerweise wird im Beispiel hier 'BME280_42356' als Devicename festgelegt, Systematik ist Trumpf.<br />
<br />
Die letzte Zeile macht aus dem vom Sensor gemessenen Luftdruck noch den auf NormalNull Bezogenen. Nicht jeder wohnt direkt am Meer und kann auf diesen Schritt verzichten. Ansonsten weichen die Werte des Sensors immer von der Wettervorhersage ab, je höher der Sensor, um so markanter. Das Beispiel hier gilt für ca. 160m üNN.<br />
<br />
Da der state nach einer Übermittlung aufgrund der Festlegungen aus der Klassendefinition nun nur den Wert der Luftfeuchte enthält, ist es hilfreich ein 'notify' für eine gefälligere Darstellung zu definieren.<syntaxhighlight><br />
define ECMDDevState notify BME280_42356:humidity:.* { Log 1, "$NAME has new values";;sleep 1;;fhem "setstate BME280_42356"." T:".ReadingsVal("BME280_42356","temperature",0)." P:".ReadingsVal("BME280_42356","airpressure_sealevel",0)." H:".ReadingsVal("BME280_42356","humidity",0) }<br />
</syntaxhighlight>Für die Übersicht zerlegt:<syntaxhighlight lang="perl" line="1" start="1"><br />
define ECMDDevState notify BME280_42356:humidity:.* <br />
{<br />
Log 1, "$NAME has new values";;<br />
sleep 1;;<br />
fhem "setstate BME280_42356".<br />
" T:".ReadingsVal("BME280_42356","temperature",0).<br />
" P:".ReadingsVal("BME280_42356","airpressure_sealevel",0).<br />
" H:".ReadingsVal("BME280_42356","humidity",0)<br />
}<br />
<br />
</syntaxhighlight>&#x2460; 'ECMDDevState' wird immer dann benachrichtigt und ausgeführt, wenn der Device 'BME280_42356' ein reading 'humidity' mit einem beliebigen (.*) Wert hat. &#x2462; Dies wird zunächst im Log vermerkt und &#x2463; als nächstes ein wenig gewartet, damit eine Änderung des sttate auf jeden Fall nach dem Befüllen des state durch das humidity reading stattfindet und auch der Luftdruck fertig berechnet ist. Dann wird &#x2464; der state mit einer Verkettung der gerade gelesenen bzw. berechneten Daten aller Werte &#x2465;,&#x2466;,&#x2467; versorgt.<br />
<br />
Abschließend soll noch ein Plot der Messwerte gemacht werden, eine Kurve liest sich leichter. Als Erstes wird eine Datei z.B. '/opt/fhem/www/gplot/SVG_BME280_42356.gplot' mit folgendem Inhalt, der die Inhalte des Plots beschreibt, erstellt.<syntaxhighlight><br />
set terminal png transparent size <SIZE> crop<br />
set output '<OUT>.png'<br />
set xdata time<br />
set timefmt "%Y-%m-%d_%H:%M:%S"<br />
set xlabel "Verlauf"<br />
set title 'Wetter'<br />
set ylabel "Temperatur"<br />
set y2label "Luftdruck"<br />
#myDbLog BME280_42356:temperature:0:<br />
#myDbLog BME280_42356:airpressure_sealevel:0::$val=$val>1100?1100:$val<800?800:$val<br />
#myDbLog BME280_42356:humidity:0::$val=$val/2-10<br />
plot "<IN>" using 1:2 axes x1y1 title 'Temperatur' ls l0 lw 1 with lines,\<br />
"<IN>" using 1:2 axes x1y2 title 'Luftdruck' ls l1 lw 1 with lines,\<br />
"<IN>" using 1:2 axes x1y1 title 'Feuchte' ls l2 lw 1 with lines<br />
</syntaxhighlight>Dann wird der Plot definiert. In diesem Fall mit den Daten aus DbLog, für FileLog muss geringfügig angepaßt werden. Dann fehlten freilich auch die FileLog -Definitionen für 'BME280_42356'.<syntaxhighlight><br />
defmod SVG_BME280_42356 SVG myDbLog:SVG_BME280_42356:HISTORY<br />
</syntaxhighlight>Der Term 'SVG_BME280_42356' liest dabei die Definitionen aus der vorher angelegten Datei 'SVG_BME280_42356.gplot'.<br />
<br />
Viel Spaß bei den eigenen Experimenten.<br />
<br />
==Quellen==<br />
<references /><br />
<br />
[[Kategorie:Glossary]]</div>GRZBRZhttp://wiki.fhem.de/w/index.php?title=ECMD&diff=33401ECMD2020-06-22T01:05:08Z<p>GRZBRZ: </p>
<hr />
<div>ECMD bedeutet "Ethersex Command"<ref>[http://www.ethersex.de/index.php/Main_Page_%28Deutsch%29 Ethersex.de]</ref> und ist laut FHEM-Dokumentation<br />
"Any physical device with request/response-like communication capabilities over a TCP connection"<ref>{{Link2CmdRef|Anker=ECMD|Label=FHEM Commandref}}</ref>, das heisst, irgendein physisches Gerät, welches request/response-artige Kommunikationsfähigkeiten aufweist, sei es über eine TCP-Verbindung (Netzwerk) oder eine serielle Schnittstelle.<br />
<br />
In FHEM sind enthalten:<br />
* Modul [[ECMD (Modul)|ECMD]] für die Bearbeitung physischer I/O-Schnittstellengeräte und<br />
* Modul [[ECMDDevice]] für einzelne logische Geräte, deren Kommunikation über ein ECMD-Gerät läuft<br />
<br />
==Beispiele & Links==<br />
Siehe {{Link2Forum|Topic= 60753 |Message=521462|LinkText=Thread im FHEM-Forum}}<br />
<br />
Siehe [[Radioaktivitätsmessung mit DIYGeigerCounter]]<br />
<br />
=== DIY Sensor via HC-12 ===<br />
Ein BME280 Temperatur/Druck/Feuchte-Sensor liefert via eines HC-12 Pärchens seine Daten an der seriellen Schnittstelle eines RasPi ab. Der Sketch im Nano, an dem sowohl der BME280 als auch einer der HC-12 hängen, liefert alle 10 Minuten ein Datagramm ab und schickt seinen Wirt in den Tiefschlaf bis zum nächsten Datagramm, um mit den notwendigen Batterien über ein Jahr aushalten zu können.<br />
<br />
Das Datagramm hat die Form <br />
DevId T-3.45°C P995.31hPa H63.27%RH\r\n<br />
Daraus werden die notwendigen Definitionen für eine Klassendefinition abgeleitet. Die z.B. unter '/opt/fhem/BME280.classdef' abgelegte Datei erhält den Inhalt<syntaxhighlight line="1"><br />
params devId<br />
reading temperature match "%devId\sT([-+.,0-9]+)\S+\sP([-+.,0-9]+)\S+\sH([-+.,0-9]+)\S+\r?\n"<br />
reading temperature postproc { /%devId\sT([-+.,0-9]+)\S+\sP([-+.,0-9]+)\S+\sH([-+.,0-9]+)\S+\r?\n/; $1 }<br />
reading airpressure match "%devId\sT([-+.,0-9]+)\S+\sP([-+.,0-9]+)\S+\sH([-+.,0-9]+)\S+\r?\n"<br />
reading airpressure postproc { /%devId\sT([-+.,0-9]+)\S+\sP([-+.,0-9]+)\S+\sH([-+.,0-9]+)\S+\r?\n/; $2 }<br />
reading humidity match "%devId\sT([-+.,0-9]+)\S+\sP([-+.,0-9]+)\S+\sH([-+.,0-9]+)\S+\r?\n"<br />
reading humidity postproc { /%devId\sT([-+.,0-9]+)\S+\sP([-+.,0-9]+)\S+\sH([-+.,0-9]+)\S+\r?\n/; $3 }<br />
state humidity<br />
</syntaxhighlight>Die regex ist in allen Zeilen der Einfachheit zuliebe gleich gehalten, bei den match könnte man freilich die Klammern löschen und bei den postproc auf ein Paar reduzieren und $_ gleichmäßig mit $1 befüllen. Geschmackssache. Alle Werte werden durch diese Vorgehensweise gleichzeitig und erst dann gelesen, wenn das gesamte Datagramm eingetroffen ist. Es ließe sich auch auf Teil-Strings abfragen, Konflikte bei mehreren Sensoren sind dann denkbar.<br />
<br />
Die letzte Zeile sorgt dafür, dass der state nur dann einen neuen Wert erhält, wenn (in diesem Fall) 'humidity' ein Update erfährt. Bei den gewählten regex trift das hier eigentlich für alle zu, aber da humidity der letzte übertragene Wert ist, ist die Wahl auf ihn gefallen. Außerdem steht nun nur ein Wert im state ohne einleitenden reading Namen, der wäre hier im Beispiel erwartungsgemäß 'humidity', was hier insofern irritiert, weil ja 3 Werte gelesen wurden und man sich unwillkürlich fragt, wo den die anderen geblieben sind. Zum state daher später noch weiteres.<br />
<br />
Sollte bereits eine ECMD Schnittstelle bestehen, kann nun die Definition hinzugefügt werden. Z.B. die ECMD Schnittstelle namens 'SerDevDef' erhält eine zusätzliche Klasse 'BME280' mit den Definitionen aus der vorher generierten Datei, Beispiel siehe oben.<syntaxhighlight><br />
set SerDevDef classdef BME280 /opt/fhem/BME280.classdef<br />
<br />
</syntaxhighlight>Ist noch keine ECMD Schnittstelle definiert, wird diese erstellt und gleich mit passenden Attributen versehen.<syntaxhighlight><br />
define SerDevDef ECMD serial /dev/ttyS0@9600<br />
set SerDevDef classdef BME280 /opt/fhem/BME280.classdef<br />
attr SerDevDef partial 2<br />
<br />
</syntaxhighlight>Die letzte Zeile ist für die serielle Schnittstelle gerade bei längeren Datagrammen ein Muss. Sie sorgt dafür, dass die kleineren Informationsbröckchen zu einer vollständigen Einheit werden. Kommt das nächste Päckchen innerhalb von (hier) 2 Sekunden, wird das neue Päckchen an die bereits gelesenen Daten angehängt, ansonsten startet eine neue Aufzeichnung beginnend mit dem Päckchen.<br />
<br />
Für den Start kann noch zur Erleichterung der Fehlersuche folgendes ergänzt werden<syntaxhighlight><br />
attr SerDevDef logTraffic 5<br />
attr SerDevDef verbose 5<br />
</syntaxhighlight>Rückstelllen dieser Attribute nicht vergessen, so ist's reichlich gesprächig und füllt schnell das Log !!!<br />
<br />
Damit ist alles vorbereitet den ECMD Device zu erstellen.<syntaxhighlight><br />
define BME280_42356 ECMDDevice BME280 42356<br />
attr BME280_42356 alias Gartenhaus<br />
attr BME280_42356 room Grundstück<br />
attr BME280_42356 IODev SerDevDef <br />
attr BME280_42356 userReadings airpressure_sealevel { sprintf("%.2f", ReadingsVal("BME280_42356","pressure",0)*1.023);; }<br />
</syntaxhighlight>Der fragliche Sensor beginnt seine Datagramme immer mit '42356', das ist seine DevId, die über den Parameter 'devId' in der Klassendefinition (siehe oben) Eingang in die readings findet. Über 'BME280' wird die Klassendefinition festgelegt, über '42356' die devId. Sinnigerweise wird im Beispiel hier 'BME280_42356' als Devicename festgelegt, Systematik ist Trumpf.<br />
<br />
Die letzte Zeile macht aus dem vom Sensor gemessenen Luftdruck noch den auf NormalNull Bezogenen. Nicht jeder wohnt direkt am Meer und kann auf diesen Schritt verzichten. Ansonsten weichen die Werte des Sensors immer von der Wettervorhersage ab, je höher der Sensor, um so markanter. Das Beispiel hier gilt für ca. 160m üNN.<br />
<br />
Da der state nach einer Übermittlung aufgrund der Festlegungen aus der Klassendefinition nun nur den Wert der Luftfeuchte enthält, ist es hilfreich ein 'notify' für eine gefälligere Darstellung zu definieren.<syntaxhighlight><br />
define ECMDDevState notify BME280_42356:humidity:.* { Log 1, "$NAME has new values";;sleep 1;;fhem "setstate BME280_42356"." T:".ReadingsVal("BME280_42356","temperature",0)." P:".ReadingsVal("BME280_42356","airpressure_sealevel",0)." H:".ReadingsVal("BME280_42356","humidity",0) }<br />
</syntaxhighlight>Für die Übersicht zerlegt:<syntaxhighlight lang="perl" line="1" start="1"><br />
define ECMDDevState notify BME280_42356:humidity:.* <br />
{<br />
Log 1, "$NAME has new values";;<br />
sleep 1;;<br />
fhem "setstate BME280_42356".<br />
" T:".ReadingsVal("BME280_42356","temperature",0).<br />
" P:".ReadingsVal("BME280_42356","airpressure_sealevel",0).<br />
" H:".ReadingsVal("BME280_42356","humidity",0)<br />
}<br />
<br />
</syntaxhighlight>1 'ECMDDevState' wird immer dann benachrichtigt und ausgeführt, wenn der Device 'BME280_42356' ein reading 'humidity' mit einem beliebigen (.*) Wert hat. 3 Dies wird zunächst im Log vermerkt und 4 als nächstes ein wenig gewartet, damit eine Änderung des sttate auf jeden Fall nach dem Befüllen des state durch das humidity reading stattfindet und auch der Luftdruck fertig berechnet ist. Dann wird 5 der state mit einer Verkettung der gerade gelesenen bzw. berechneten Daten aller Werte 6,7,8 versorgt.<br />
<br />
Abschließend soll noch ein Plot der Messwerte gemacht werden, eine Kurve liest sich leichter. Als Erstes wird eine Datei z.B. '/opt/fhem/www/gplot/SVG_BME280_42356.gplot' mit folgendem Inhalt, der die Inhalte des Plots beschreibt, erstellt.<syntaxhighlight><br />
set terminal png transparent size <SIZE> crop<br />
set output '<OUT>.png'<br />
set xdata time<br />
set timefmt "%Y-%m-%d_%H:%M:%S"<br />
set xlabel "Verlauf"<br />
set title 'Wetter'<br />
set ylabel "Temperatur"<br />
set y2label "Luftdruck"<br />
#myDbLog BME280_42356:temperature:0:<br />
#myDbLog BME280_42356:airpressure_sealevel:0::$val=$val>1100?1100:$val<800?800:$val<br />
#myDbLog BME280_42356:humidity:0::$val=$val/2-10<br />
plot "<IN>" using 1:2 axes x1y1 title 'Temperatur' ls l0 lw 1 with lines,\<br />
"<IN>" using 1:2 axes x1y2 title 'Luftdruck' ls l1 lw 1 with lines,\<br />
"<IN>" using 1:2 axes x1y1 title 'Feuchte' ls l2 lw 1 with lines<br />
</syntaxhighlight>Dann wird der Plot definiert. In diesem Fall mit den Daten aus DbLog, für FileLog muss geringfügig angepaßt werden. Dann fehlten freilich auch die FileLog -Definitionen für 'BME280_42356'.<syntaxhighlight><br />
defmod SVG_BME280_42356 SVG myDbLog:SVG_BME280_42356:HISTORY<br />
</syntaxhighlight>Der Term 'SVG_BME280_42356' liest dabei die Definitionen aus der vorher angelegten Datei 'SVG_BME280_42356.gplot'.<br />
<br />
Viel Spaß bei den eigenen Experimenten.<br />
<br />
==Quellen==<br />
<references /><br />
<br />
[[Kategorie:Glossary]]</div>GRZBRZhttp://wiki.fhem.de/w/index.php?title=ECMD&diff=33400ECMD2020-06-22T01:03:22Z<p>GRZBRZ: /* Beispiele & Links */</p>
<hr />
<div>ECMD bedeutet "Ethersex Command"<ref>[http://www.ethersex.de/index.php/Main_Page_%28Deutsch%29 Ethersex.de]</ref> und ist laut FHEM-Dokumentation<br />
"Any physical device with request/response-like communication capabilities over a TCP connection"<ref>{{Link2CmdRef|Anker=ECMD|Label=FHEM Commandref}}</ref>, das heisst, irgendein physisches Gerät, welches request/response-artige Kommunikationsfähigkeiten aufweist, sei es über eine TCP-Verbindung (Netzwerk) oder eine serielle Schnittstelle.<br />
<br />
In FHEM sind enthalten:<br />
* Modul [[ECMD (Modul)|ECMD]] für die Bearbeitung physischer I/O-Schnittstellengeräte und<br />
* Modul [[ECMDDevice]] für einzelne logische Geräte, deren Kommunikation über ein ECMD-Gerät läuft<br />
<br />
==Beispiele & Links==<br />
Siehe {{Link2Forum|Topic= 60753 |Message=521462|LinkText=Thread im FHEM-Forum}}<br />
<br />
Siehe [[Radioaktivitätsmessung mit DIYGeigerCounter]]<br />
<br />
=== DIY Sensor via HC-12 ===<br />
Ein BME280 Temperatur/Druck/Feuchte-Sensor liefert via eines HC-12 Pärchens seine Daten an der seriellen Schnittstelle eines RasPi ab. Der Sketch im Nano, an dem sowohl der BME280 als auch einer der HC-12 hängen, liefert alle 10 Minuten ein Datagramm ab und schickt seinen Wirt in den Tiefschlaf bis zum nächsten Datagramm, um mit den notwendigen Batterien über ein Jahr aushalten zu können.<br />
<br />
Das Datagramm hat die Form <br />
DevId T-3.45°C P995.31hPa H63.27%RH\r\n<br />
Daraus werden die notwendigen Definitionen für eine Klassendefinition abgeleitet. Die z.B. unter '/opt/fhem/BME280.classdef' abgelegte Datei erhält den Inhalt<syntaxhighlight line="1"><br />
params devId<br />
reading temperature match "%devId\sT([-+.,0-9]+)\S+\sP([-+.,0-9]+)\S+\sH([-+.,0-9]+)\S+\r?\n"<br />
reading temperature postproc { /%devId\sT([-+.,0-9]+)\S+\sP([-+.,0-9]+)\S+\sH([-+.,0-9]+)\S+\r?\n/; $1 }<br />
reading airpressure match "%devId\sT([-+.,0-9]+)\S+\sP([-+.,0-9]+)\S+\sH([-+.,0-9]+)\S+\r?\n"<br />
reading airpressure postproc { /%devId\sT([-+.,0-9]+)\S+\sP([-+.,0-9]+)\S+\sH([-+.,0-9]+)\S+\r?\n/; $2 }<br />
reading humidity match "%devId\sT([-+.,0-9]+)\S+\sP([-+.,0-9]+)\S+\sH([-+.,0-9]+)\S+\r?\n"<br />
reading humidity postproc { /%devId\sT([-+.,0-9]+)\S+\sP([-+.,0-9]+)\S+\sH([-+.,0-9]+)\S+\r?\n/; $3 }<br />
state humidity<br />
</syntaxhighlight>Die regex ist in allen Zeilen der Einfachheit zuliebe gleich gehalten, bei den match könnte man freilich die Klammern löschen und bei den postproc auf ein Paar reduzieren und $_ gleichmäßig mit $1 befüllen. Geschmackssache. Alle Werte werden durch diese Vorgehensweise gleichzeitig und erst dann gelesen, wenn das gesamte Datagramm eingetroffen ist. Es ließe sich auch auf Teil-Strings abfragen, Konflikte bei mehreren Sensoren sind dann denkbar.<br />
<br />
Die letzte Zeile sorgt dafür, dass der state nur dann einen neuen Wert erhält, wenn (in diesem Fall) 'humidity' ein Update erfährt. Bei den gewählten regex trift das hier eigentlich für alle zu, aber da humidity der letzte übertragene Wert ist, ist die Wahl auf ihn gefallen. Außerdem steht nun nur ein Wert im state ohne einleitenden reading Namen, der wäre hier im Beispiel erwartungsgemäß 'humidity', was hier insofern irritiert, weil ja 3 Werte gelesen wurden und man sich unwillkürlich fragt, wo den die anderen geblieben sind. Zum state daher später noch weiteres.<br />
<br />
Sollte bereits eine ECMD Schnittstelle bestehen, kann nun die Definition hinzugefügt werden. Z.B. die ECMD Schnittstelle namens 'SerDevDef' erhält eine zusätzliche Klasse 'BME280' mit den Definitionen aus der vorher generierten Datei, Beispiel siehe oben.<syntaxhighlight><br />
set SerDevDef classdef BME280 /opt/fhem/BME280.classdef<br />
<br />
</syntaxhighlight>Ist noch keine ECMD Schnittstelle definiert, wird diese erstellt und gleich mit passenden Attributen versehen.<syntaxhighlight><br />
define SerDevDef ECMD serial /dev/ttyS0@9600<br />
set SerDevDef classdef BME280 /opt/fhem/BME280.classdef<br />
attr SerDevDef partial 2<br />
<br />
</syntaxhighlight>Die letzte Zeile ist für die serielle Schnittstelle gerade bei längeren Datagrammen ein Muss. Sie sorgt dafür, dass die kleineren Informationsbröckchen zu einer vollständigen Einheit werden. Kommt das nächste Päckchen innerhalb von (hier) 2 Sekunden, wird das neue Päckchen an die bereits gelesenen Daten angehängt, ansonsten startet eine neue Aufzeichnung beginnend mit dem Päckchen.<br />
<br />
Für den Start kann noch zur Erleichterung der Fehlersuche folgendes ergänzt werden<syntaxhighlight><br />
attr SerDevDef logTraffic 5<br />
attr SerDevDef verbose 5<br />
</syntaxhighlight>Rückstelllen dieser Attribute nicht vergessen, so ist's reichlich gesprächig und füllt schnell das Log !!!<br />
<br />
Damit ist alles vorbereitet den ECMD Device zu erstellen.<syntaxhighlight><br />
define BME280_42356 ECMDDevice BME280 42356<br />
attr BME280_42356 alias Gartenhaus<br />
attr BME280_42356 room Grundstück<br />
attr BME280_42356 IODev SerDevDef <br />
attr BME280_42356 userReadings airpressure_sealevel { sprintf("%.2f", ReadingsVal("BME280_42356","pressure",0)*1.023);; }<br />
</syntaxhighlight>Der fragliche Sensor beginnt seine Datagramme immer mit '42356', das ist seine DevId, die über den Parameter 'devId' in der Klassendefinition (siehe oben) Eingang in die readings findet. Über 'BME280' wird die Klassendefinition festgelegt, über '42356' die devId. Sinnigerweise wird im Beispiel hier 'BME280_42356' als Devicename festgelegt, Systematik ist Trumpf.<br />
<br />
Die letzte Zeile macht aus dem vom Sensor gemessenen Luftdruck noch den auf NormalNull Bezogenen. Nicht jeder wohnt direkt am Meer und kann auf diesen Schritt verzichten. Ansonsten weichen die Werte des Sensors immer von der Wettervorhersage ab, je höher der Sensor, um so markanter. Das Beispiel hier gilt für ca. 160m üNN.<br />
<br />
Da der state nach einer Übermittlung aufgrund der Festlegungen aus der Klassendefinition nun nur den Wert der Luftfeuchte enthält, ist es hilfreich ein 'notify' für eine gefälligere Darstellung zu definieren.<syntaxhighlight><br />
define ECMDDevState notify BME280_42356:humidity:.* { Log 1, "$NAME has new values";;sleep 1;;fhem "setstate BME280_42356"." T:".ReadingsVal("BME280_42356","temperature",0)." P:".ReadingsVal("BME280_42356","airpressure_sealevel",0)." H:".ReadingsVal("BME280_42356","humidity",0) }<br />
</syntaxhighlight>Für die Übersicht zerlegt:<syntaxhighlight lang="perl" line="1" start="1"><br />
define ECMDDevState notify BME280_42356:humidity:.* <br />
{<br />
Log 1, "$NAME has new values";;<br />
sleep 1;;<br />
fhem "setstate BME280_42356".<br />
" T:".ReadingsVal("BME280_42356","temperature",0).<br />
" P:".ReadingsVal("BME280_42356","airpressure_sealevel",0).<br />
" H:".ReadingsVal("BME280_42356","humidity",0)<br />
}<br />
<br />
</syntaxhighlight>1 'ECMDDevState' wird immer dann benachrichtigt und ausgeführt, wenn der Device 'BME280_42356' ein reading 'humidity' mit einem beliebigen (.*) Wert hat. 3 Dies wird zunächst im Log vermerkt und 4 als nächstes ein wenig gewartet, damit eine Änderung des sttate auf jeden Fall nach dem Befüllen des state durch das humidity reading stattfindet und auch der Luftdruck fertig berechnet ist. Dann wird 5 der state mit einer Verkettung der gerade gelesenen bzw. berechneten Daten aller Werte 6,7,8 versorgt.<br />
<br />
Abschließend soll noch ein Plot der Messwerte gemacht werden, eine Kurve liest sich leichter. Als Erstes wird eine Datei z.B. '/opt/fhem/www/gplot/SVG_BME280_42356.gplot' mit folgendem Inhalt, der die Inhalte des Plots beschreibt, erstellt.<syntaxhighlight><br />
set terminal png transparent size <SIZE> crop<br />
set output '<OUT>.png'<br />
set xdata time<br />
set timefmt "%Y-%m-%d_%H:%M:%S"<br />
set xlabel "Verlauf"<br />
set title 'Wetter'<br />
set ylabel "Temperatur"<br />
set y2label "Luftdruck"<br />
#myDbLog BME280_42356:temperature:0:<br />
#myDbLog BME280_42356:airpressure_sealevel:0::$val=$val>1100?1100:$val<800?800:$val<br />
#myDbLog BME280_42356:humidity:0::$val=$val/2-10<br />
plot "<IN>" using 1:2 axes x1y1 title 'Temperatur' ls l0 lw 1 with lines,\<br />
"<IN>" using 1:2 axes x1y2 title 'Luftdruck' ls l1 lw 1 with lines,\<br />
"<IN>" using 1:2 axes x1y1 title 'Feuchte' ls l2 lw 1 with lines<br />
</syntaxhighlight>Dann wird der Plot definiert. In diesem Fall mit den Daten aus DbLog, für FileLog muss geringfügig angepaßt werden. Dann fehlten freilich auch die FileLog -Definitionen für 'BME280_42356'.<syntaxhighlight><br />
defmod SVG_BME280_42356 SVG myDbLog:SVG_BME280_42356:HISTORY<br />
</syntaxhighlight>Der Term 'SVG_BME280_42356' liest dabei die Definitionen aus der vorher angelegten Datei 'SVG_BME280_42356.gplot'.<br />
<br />
==== Viel Spaß bei den eigenen Experimenten. ====<br />
<br />
==Quellen==<br />
<references /><br />
<br />
[[Kategorie:Glossary]]</div>GRZBRZhttp://wiki.fhem.de/w/index.php?title=MAX!CubeMigrationToFHEM&diff=33397MAX!CubeMigrationToFHEM2020-06-20T12:40:51Z<p>GRZBRZ: /* Planned changes */</p>
<hr />
<div>{{todo|Fertigstellung des Artikels oder zumindest Löschung der ADD Me-Einträge}}<br />
== WORK IN PROGRESS / NOT FINISHED: HowTo Migrate from MAX!Cube to FHEM ==<br />
'''Summary:''' This pages describes the steps required to migrate a house installation from MAX!Cube solution (using a Cube and MAX! Software from ELV/EQ-3) to FHEM on a Raspberry Pi combined with a CUL. The benefit of such a migration is to gain better logfiles, to get graphs (Desired vs. Actual temperature and Valve position) and more reliable software.<br />
<br />
----<br />
<br />
<br />
=== Initial situation ===<br />
The appartment has 125 sqm and five rooms (child 1, child 2, livingroom, bedroom, working room), one bathroom, a kitchen and a toilette. Each room has one heater below the window, the living room has two heaters. Two rooms require multiple window shutter contacts: bedroom and living room due to the amount of windows. MAX!Cube software is running since a year controlling all heaters, all windows and in combination with one wall thermostat in the living room and one ECO-switch at the main door to bring the full house to ECO mode when leaving.<br />
<br />
=== Desired situation ===<br />
MAX!Cube software was unstable and the update to v1.3.10 triggered the decision to move to a new setup: keep the MAX system, but control it via FHEM. Have the ability to add more sensors, more actors from other brands than MAX (looking for Homematic due to the amount of different sensors and 1-Wire to avoid the unreliable radio transmission). Have the ability to better see what the system is doing (logfiles) and graph it out (diagrams for each room). Get some more flexibility for home-cinema setup, for light controls, etc. Increase the ''WAF'' (Women's Acceptance Factor) for the wife who was complaining about the MAX!Cube solution.<br />
<br />
=== Procurement list ===<br />
While it is possible to use the existing MAX Cube with FHEM certain features would not be available. Therefore I decided to go with a Rasperry Pi and a CUL. Here is the shopping list:<br />
<br />
# Rasperry Pi from G3 with cooling kit for enhanced reliability ([http://www.amazon.de/pi3g-Raspberry-Betriebssystem-Coolkit-installiert/dp/B00CB1C96E])<br />
# 32 GB SDHX Card Class 10 from SANDisk<br />
# CC1101-USB-Lite 868MHz ([http://shop.busware.de/product_info.php/cPath/1/products_id/29]) with 36cm antenna (+8dBi) for MAX protocol<br />
# 8 Channel 1-Wire Daughterboard without RTC with some sensors for testing ([http://www.sheepwalkelectronics.co.uk/product_info.php?cPath=22&products_id=33])<br />
<br />
(Note: The 1-Wire board has not yet arrived and may not fit into the supplied case - but I am too lazy to attach the cooling modules myself).<br />
<br />
=== Installation of Raspberry Pi ===<br />
Please follow one of the many documentations how to install Linux on your Raspberry Pi - a good starting point would be [http://www.raspberrypi.org/downloads]. I tried to install Raspbian using the advanced method of copying the image directly to the SD-card but it did not worked out well as many perl/python-modules were missing, had to be identified and installed to use FHEM.<br />
<br />
For my second approach I used the provided image from busware.de, which also includes drivers for their COC daughter board. Available for download here [http://files.busware.de/RPi/README.kernel]. Unfortunately this has a slightly outdated FHEM installation, but works for all other parts. Please note that there is no HDMI output enabled during the first boot. Just use <code>ssh pi@fhem</code> or <code>ssh pi@<IP-address></code> to login and use raspi-config for initial setup of passwords, timezone and disk size. Do not forget to install an ntp-client using <code>apt-get install ntp-client</code>, an editor of your choice (I selected vim <code>apt-get install vim</code>) and edit <code>/etc/ntp.conf</code> to adjust ntpservers and select a country-pool (see [http://www.pool.ntp.org/zone/europe]).<br />
<br />
==== Upgrade of FHEM ====<br />
Once the initial setup is completed reboot your Raspberry and login into FHEM using your web browser at <code><IP-address>:8083</code>. Enter the <code>upgrade</code> command to upgrade your FHEM-installation to the latest revision. Use <code>shutdown restart</code> to start the new code version.<br />
<br />
==== CUL firmware flashing ====<br />
Login using ssh and become root using <code>su -</code> or <code>sudo -i</code> to flash the empty CUL. This only works as root from the directory <code>/opt/fhem</code> using the command string<br />
<br />
dfu-programmer atmega32u4 erase && dfu-programmer atmega32u4 flash ./FHEM/CUL_V3.hex && dfu-programmer atmega32u4 start<br />
<br />
If the application dfu-programmer is not installed, install using <code>apt-get install dfu-programmer</code>.<br />
<br />
=== Migration Preparation ===<br />
ADD ME<br />
==== Documentation ====<br />
If you have not done it before now it's a good start to document your existing MAX!Cube solution. Room for room write each device, the MAX address, location and intended profile into an Excel file. It could look like<br />
<br />
Roomname DeviceName DeviceAddress Location WeekDayProfile WeekendProfile Dependencies<br />
<br />
where WeekDayProfile and WeekendProfile only make sense for actors like Heaters within the MAX-solution. Dependencies can indicate Window Contacts to Heater actors or Wall Thermostat to Heater actors. Document as well your current heating profile configuration with MAX!Cube.<br />
<br />
Make a backup.<br />
<br />
==== Selecting the right time of the year ====<br />
ADD ME<br />
==== What do you want to archive ====<br />
ADD ME<br />
=== Migration Execution ===<br />
ADD ME<br />
==== MAX!Cube Configuration ====<br />
ADD ME<br />
==== fhem Configuration ====<br />
===== CUL Setup =====<br />
First step to setup FHEM is to define the protocol and adaptor FHEM should use. You need one CUL for each protocol (e.g. FS20, Homematic and MAX) as the CUL can listen to the same frequency, but does not understand multiple protocols. The <fhem.cfg> comes pre-installed with some default configuration. At the end add<br />
<br />
#### CUL Definition, MAX!Cube<br />
define CUL0 CUL /dev/ttyACM0@9600 1234<br />
attr CUL0 rfmode MAX<br />
define cm CUL_MAX 123456<br />
<br />
and save fhem.cfg. After a reload FHEM will start to ''listen'' to MAX-commands sent by your still active MAX-Cube.<br />
<br />
===== Find MAX devices =====<br />
As each MAX device communicates with the MAX!Cube over the time of two-three days, FHEM will detect in use MAX-devices like Heaters, Thermostats and WindowsContacts (but not the ECO wall switch) and create alias definitions within the fhem.cfg file. To get all devices including addresses in use let FHEM listen for a two-three days while the MAX!Cube is still in use and working.<br />
<br />
===== Identify MAX devices =====<br />
Login into MAX!Cube using one browser window (or tab) and into FHEM using a second browser window (or tab). For each room change the temperature within the MAX!Software to an unsual value (like 27.5), change to the FHEM window and identify the change in FHEM. This allows you to detect one heater actor by the other.<br />
<br />
To identify the Window Contacts just open one window, swap to FHEM and see which contact reports an ''Open'' status.<br />
<br />
===== Define alias names =====<br />
Open a third browser window (or tab), login to FHEM webpage and select Edit Files, fhem.cfg. You can now add the alias by adding lines like<br />
<br />
define MAX_Bathroom_Heating MAX HeatingThermostat 05615b<br />
define MAX_Bathroom_WindowSensor MAX ShutterContact 053767<br />
<br />
room by room, one by one. Just identify the fhem-name in the "MAX"-room in FHEM and adjust the address (last hex-number in the line).<br />
<br />
If you already have meaningfull names in the MAX-Software you can try to use the code from this {{Link2Forum|Topic=19473|Message=131095|LinkText=forum post}} to automaticaly use these as the alias names for all MAX devices.<br />
<br />
===== Assigning a room name =====<br />
For better structure create and assign devices of one physical room into one room within FHEM. Rooms are managed by the ''attribute'' room for a specific device. Each defined devices require one or more room attributes:<br />
<br />
attr MAX_Bedroom_Heating room Bedroom<br />
<br />
===== Understanding the setup =====<br />
The rooms are still controlled from the MAX!Cube and MAX-software. FHEM only listens and has useable names. FHEM does not communicate with the devices and it cannot configure devices. However you have useable and human-understandable names instead of hex-codes.<br />
<br />
===== Migration =====<br />
As MAX!Cube will interfere with CUL (both sending the same protocol on the same frequency) and due to the sending restrictions (1%-rule) we need to<br />
<br />
# Remove all rooms in MAX!Cube (which deletes the devices in MAX!Cube)<br />
# Reset all heaters and window contacts to factory settings<br />
# Pair the device to FHEM<br />
# Define the week heating program<br />
# Define the connectivity between heater and window sensors<br />
<br />
Make a backup of your MAX!Cube configuration in case something goes seriously wrong. Have the family out of the house for 1-2 days while you run around to re-pair devices. While resetting the devices the PI-learned heating curves will be lost and the heaters need to adopt again to your house-specific heating curves.<br />
<br />
===== Re-setting devices =====<br />
Remove batteries and wait 45 seconds. For<br />
<br />
# Heater actors: Press all three buttons at the same time, insert battery until <code>reS</code> is displayed. Press Boost for installation menu<br />
# Window contacts: Press button while inserting battery and keep pressed until LED is flashing again<br />
# ECO-Wallcontact: Press Eco or AUTO button while inserting battery and keep pressed until LED is flashing again<br />
# Wallthermostats: Press "Moon", "OK" and "-" at the same time, then insert the battery [http://www.elv.de/controller.aspx?cid=824&detail=10&detail2=3537]<br />
<br />
===== Pairing devices with FHEM =====<br />
Enter<br />
<br />
set cm pairmode 45<br />
<br />
into the command field on top of the FHEM page to configure the CUL into pairing mode for 45 seconds. Initiate the pair sequence on the device by:<br />
<br />
# Heater actors: Pressing Boost for about 3 seconds until <code>30</code> is displayed. The pairing succeeded when the timer is gone.<br />
# Window contacts: Press button, LED starts flashing. Success is reported by one last long LED signal.<br />
# ECO-Wallcontact: Press one button three seconds, LED starts flashing. Success is reported by one last long LED signal<br />
# Wallthermostat: First click several times "OK" to set a random date and time until you see the temperature again. Then press OK button three seconds until <code>30</code> is displayed. The pairing succeeded when the timer is gone.<br />
<br />
==== FHEM One-Time Device-specific configuration ====<br />
Certain information about FHEM are stored in the fhem.cfg which you can edit using a text editor and ssh or using the webfront. A big other, device-specific part is entered as part of commands into the webfrontend, but not documented and not stored within fhem.cfg. You will end up in a documented, structure information stored in fhem.cfg (like any other UNIX related configuration file in /etc) and a un-documented part which is stored within the devices of your appartment only.<br />
<br />
My solution for this was to add the relevant commands into fhem.cfg as ''comments'', so after a multiple month pause on playing with FHEM I do still see which commands belonged into which room and what I have done. However if you follow this route is important to understand that changes to these ''comments'' will never take place and change your configuration unless you copy and paste them into the command-field and execute your change.<br />
<br />
The information stored in devices and not in fhem.cfg are<br />
<br />
# Heating weekProfiles - which temperature you want when<br />
# Associations between WindowContacts and Heaters to detect open windows.<br />
<br />
Within the FHEM forums you find a longer discussion if windows sensors really make sense. The statement there is as the heaters have a decreasing temperature sensor they are not. It is hard for me to follow this argumentation as:<br />
<br />
# The heating water temperature will be impacted when it keep running while windows is open<br />
# The WAF (Women's Acceptance Factor) is lowered as the house should be smart<br />
# You may wish to have open windows longer than 10-15 minutes<br />
# I can document the time of getting fresh air into the rooms (for any discussions with the landlord in a rented appartment)<br />
<br />
===== Window Contacts and Heaters =====<br />
To connect a window contact with a heater to decrease the temperature they need to be ''associated'' to each other:<br />
<br />
set MAX_Bedroom_WindowSensor1 associate MAX_Bedroom_Heating<br />
set MAX_Bedroom_Heating associate MAX_Bedroom_WindowSensor1<br />
<br />
As you can see the associations is called twice for both directions and you need to call both commands for each Window Contact in the room. FHEM will ask you in the logfile for each command to press the MAX Window Contact button when you open the Window Contact. If you have (against advice) already configured the graphing you need to disable the graphing to get the command being transmitted.<br />
<br />
===== Open Window Temperature =====<br />
Configure the desired Open Window temperature for that room using<br />
<br />
set MAX_Bedroom_Heating windowOpenTemperature 5.5<br />
<br />
You may have to wait a couple of minutes until the command has been transmitted.<br />
<br />
Test your room by opening each Window with a Window Contact, the heater should immediately change temperature in both directions.<br />
<br />
===== The Heating Profile =====<br />
Device-specific configuration also includes the weekProfile, e.g. the desired temperature for each day and each hour. The format is quite simple and starts with an implicit 00:00 (midnight) and ends with an implicit 24:00 (midnight next day). In between desired temperatures are specificed interleaving with hours, seperated by ''','''s. Temperature is specific in degrees celsius. Example:<br />
<br />
17,06:00,21,20:00,17<br />
<br />
will set 17 degrees from midnight to 06:00am, 21 degrees 06:00am to 20:00 (8:00pm) and then again 17 degrees until midnight. Such profiles are defined for each day (Mon, Tue, Wed, Thu, Fri, Sat, Sun) and set with the weekProfile command:<br />
<br />
set MAX_Child1_Heating weekProfile Mon 17,05:00,19,06:00,22,07:15,19,15:30,21,19:00,19,21:00,17 Tue 17,05:00,19,06:00,22,07:15,19,15:30,21,19:00,19,21:00,17 Wed 17,05:00,19,06:00,22,07:15,19,15:30,21,19:00,19,21:00,17 Thu 17,05:00,19,06:00,22,07:15,19,15:30,21,19:00,19,21:00,17 Fri 17,05:00,19,06:00,22,07:15,19,15:30,21,19:00,19,21:00,17 Sat 17,06:00,21,20:00,17 Sun 17,06:00,21,20:00,17<br />
<br />
Do not attempt to break this line into multiple lines for better reading. Just one single long line. Transmission may take a couple of minutes.<br />
<br />
==== Testing and Verifying ====<br />
ADD ME<br />
<br />
=== Add-Ons ===<br />
ADD ME<br />
==== Graphs using 99_UtilsMaxScan.pm ====<br />
There is a Wiki-articel how to use the [[MAX! Temperatur-Scanner]] with FHEM. At the time of writing this article v1.05a has been published.<br />
<br />
Few people have published changes to this version within the forum, which enables the use of ECO wall button and multiple WindowShutter contacts.<br />
<br />
If you consider to create graphs for your installation your migration (as outlined above) should '''work stable'', e.g.<br />
<br />
# week programs for all rooms are active and working<br />
# open windows are detected and the desired temperature is decreased<br />
# you do not face any logfile entries like: <code>CUL_MAX_SendQueueHandler: Not enough credit! credit10ms is 101, but we need 110. Waiting 9 seconds.</code><br />
# you do not face any logfile entries like: <code>CUL_MAX_SendQueueHandler: Missing ack from 020341 for 0f010403123456020341000e18003655</code><br />
# you do not plan any changes to week programs any time soon.<br />
<br />
Do not '''even think''' about starting to graph out heaters and rooms while migration is still in progress.<br />
<br />
Do download the Scanner Module you need to register and login into the forum. The Scanner Module is attached to the post linked at [[MAX! Temperatur-Scanner]]. Copy this file to <code>/opt/fhem/FHEM</code> and change ownership to fhem.<br />
<br />
(Original Articles: {{Link2Forum|Topic=11624|Message=114140}} und {{Link2Forum|Topic=11624|Message=119519}})<br />
<br />
==== ECO-Wallswitch ====<br />
According to an extensive Google search it is currently not possible to group all Heater actors and send a single command to the group to save communication credits.<br />
<br />
A workaround is to define a FHEM ''structure'' with a speaking name and type which includes all Heaters, assign it to a new room labelled "House" and add a web control button to FHEM:<br />
<br />
# Define House to control all Heaters at once<br />
define AllHeaters structure AllMyHeaters MAX_Child2_Heating MAX_Workingroom_Heating MAX_Child1_Heating MAX_Livingroom_THSensor MAX_Bedroom_Heating MAX_Toilette_Heating MAX_Kitchen_Heating MAX_Bathroom_Heating<br />
attr AllHeaters room House<br />
attr AllHeaters webCmd desiredTemperature<br />
<br />
The ECO Wall button has a type PushButton and is easily defined using (you have to update the address of course):<br />
<br />
### 9.1 ECO-Wallbutton<br />
define MAX_WallButton MAX PushButton 0521c4<br />
<br />
To set all heaters into ECO mode until the AUTO mode is pressed on the button or the AUTO mode is called from the webpage use:<br />
<br />
<nowiki>define MAX_HouseECOHeating notify MAX_WallButton:(onoff).* { if ($EVTPART1 eq 0) { Log(3,"Setting ECO-Mode") && fhem("set AllHeaters desiredTemperature eco");;} else { Log(3,"Setting AUTO-Mode") && fhem("set AllHeaters desiredTemperature auto");;}} </nowiki><br />
<br />
(Original discussion: {{Link2Forum|Topic=17128|Message=112191}})<br />
<br />
=== Full fhem.cfg file (all rooms) ===<br />
This is the full example of all discussed settings for the specific outlined room. If you want to adopt this setup you need to replace all MAX addresses with the addresses of your devices.<br />
<br />
attr global autoload_undefined_devices 1<br />
attr global logfile ./log/fhem-%Y-%m.log<br />
attr global modpath .<br />
attr global motd Remember to set passwords<br />
attr global statefile ./log/fhem.save<br />
attr global userattr MAX_Child2_Heating MAX_Child2_Heating_map devStateIcon devStateStyle icon sortby webCmd<br />
attr global verbose 3<br />
<br />
<nowiki>####</nowiki> Telnet<br />
define telnetPort telnet 7072 global<br />
<br />
<nowiki>####</nowiki> Screen setup<br />
define WEB FHEMWEB 8083 global<br />
attr WEB stylesheetPrefix dark<br />
<br />
define WEBphone FHEMWEB 8084 global<br />
attr WEBphone stylesheetPrefix smallscreen <br />
<br />
define WEBtablet FHEMWEB 8085 global<br />
attr WEBtablet stylesheetPrefix touchpad <br />
<br />
<nowiki>####</nowiki> Logfile<br />
<nowiki>#</nowiki> Fake FileLog entry, to access the FHEM log from FHEMWEB <br />
define Logfile FileLog ./log/fhem-%Y-%m.log fakelog <br />
<br />
<nowiki>####</nowiki> Autocreate<br />
define autocreate autocreate<br />
attr autocreate autosave 1<br />
attr autocreate device_room %TYPE<br />
attr autocreate filelog ./log/%NAME-%Y.log<br />
attr autocreate weblink 1<br />
attr autocreate weblink_room Plots <br />
<br />
<nowiki>#</nowiki> Disable this to avoid looking for new USB devices on startup<br />
define initialUsbCheck notify global:INITIALIZED usb create <br />
<br />
<nowiki>####</nowiki> CUL Definition, MAX!Cube<br />
define CUL0 CUL /dev/ttyACM0@9600 1234<br />
attr CUL0 rfmode MAX<br />
define cm CUL_MAX 123456 <br />
<br />
<nowiki>####</nowiki><br />
<nowiki>####</nowiki> Room Definitions<br />
<nowiki>####</nowiki> Heating Control = MAX<br />
<nowiki>####</nowiki><br />
<br />
<nowiki>##</nowiki> 1.1 Bathroom (Heating Thermostat)<br />
define MAX_Bathroom_Heating MAX HeatingThermostat 05615b<br />
attr MAX_Bathroom_Heating MAX_Child2_Heating AllHeaters<br />
attr MAX_Bathroom_Heating room Bathroom<br />
attr MAX_Bathroom_Heating scanTemp 1<br />
define FileLog_MAX_Bathroom_Heating FileLog ./log/MAX_Bathroom_Heating-%Y.log MAX_Bathroom_Heating<br />
attr FileLog_MAX_Bathroom_Heating icon heizung.0<br />
attr FileLog_MAX_Bathroom_Heating logtype text<br />
attr FileLog_MAX_Bathroom_Heating room MAX<br />
<br />
<nowiki>###</nowiki> 1.2 Bathroom (Window Sensor)<br />
define MAX_Bathroom_WindowSensor MAX ShutterContact 053767<br />
attr MAX_Bathroom_WindowSensor room Bathroom<br />
define FileLog_MAX_Bathroom_WindowSensor FileLog ./log/MAX_Bathroom_WindowSensor-%Y.log MAX_Bathroom_WindowSensor<br />
attr FileLog_MAX_Bathroom_WindowSensor logtype text<br />
attr FileLog_MAX_Bathroom_WindowSensor room MAX<br />
<br />
<nowiki>###</nowiki> 1.3 One-Time Configuration (only stored in actors, not in fhem.cfg) - commented just to document<br />
<nowiki>#</nowiki> Activate Open Window detection<br />
<nowiki>#</nowiki> set MAX_Bathroom_WindowSensor associate MAX_Bathroom_Heating<br />
<nowiki>#</nowiki> set MAX_Bathroom_Heating associate MAX_Bathroom_WindowSensor<br />
<nowiki>#</nowiki><br />
<nowiki>#</nowiki> Define Week Profile<br />
<nowiki>#</nowiki> set MAX_Bathroom_Heating weekProfile Mon 17,05:00,19,06:00,22,07:15,21,08:30,17,19:00,21,20:45,17 Tue 17,05:00,19,06:00,22,07:15,21,08:30,17,19:00,21,20:45,17 Wed 17,05:00,19,06:00,22,07:15,21,08:30,17,19:00,21,20:45,17 Thu 17,05:00,19,06:00,22,07:15,21,08:30,17,19:00,21,20:45,17 Fri 17,05:00,19,06:00,22,07:15,21,08:30,17,19:00,21,20:45,17 Sat 17,06:00,21,10:00,19,19:00,21,20:45,17 Sun 17,06:00,21,10:00,19,19:00,21,20:45,17<br />
<nowiki>#</nowiki><br />
<nowiki>#</nowiki> Temperatur Scanner (Graphical)<br />
<nowiki>#</nowiki> attr MAX_Bathroom_Heating scanTemp 1<br />
<nowiki>#</nowiki> attr MAX_Bathroom_Heating userReadings onlyAutoMode { return "1";;}<br />
<nowiki>#</nowiki> attr MAX_Bathroom_Heating userReadings watchShutter { return "MAX_Bathroom_WindowSensor";;}<br />
<nowiki>#</nowiki><br />
<nowiki>#</nowiki> WindowOpenTemperature (4.5 = OFF, No Window Detection)<br />
<nowiki>#</nowiki> set MAX_Bathroom_Heating windowOpenTemperature 5.5<br />
<nowiki> </nowiki><br />
<br />
<nowiki>###</nowiki> 2.1 Bedroom (Heating Thermostat)<br />
define MAX_Bedroom_Heating MAX HeatingThermostat 020341<br />
attr MAX_Bedroom_Heating MAX_Child2_Heating AllHeaters<br />
attr MAX_Bedroom_Heating room Bedroom<br />
attr MAX_Bedroom_Heating scanTemp 1<br />
attr MAX_Bedroom_Heating userReadings onlyAutoMode { return "1";;}<br />
define FileLog_MAX_Bedroom_Heating FileLog ./log/MAX_Bedroom_Heating-%Y.log MAX_Bedroom_Heating<br />
attr FileLog_MAX_Bedroom_Heating icon heizung.0<br />
attr FileLog_MAX_Bedroom_Heating logtype text<br />
attr FileLog_MAX_Bedroom_Heating room MAX <br />
<br />
<nowiki>###</nowiki> 2.2 Bedroom (Window Sensor)<br />
define MAX_Bedroom_WindowSensor1 MAX ShutterContact 053fdd<br />
attr MAX_Bedroom_WindowSensor1 room Bedroom<br />
define FileLog_MAX_Bedroom_WindowSensor1 FileLog ./log/MAX_Bedroom_WindowSensor1-%Y.log MAX_Bedroom_WindowSensor1<br />
attr FileLog_MAX_Bedroom_WindowSensor1 logtype text<br />
attr FileLog_MAX_Bedroom_WindowSensor1 room MAX<br />
<br />
<nowiki>###</nowiki> 2.3 One-Time Configuration (only stored in actors, not in fhem.cfg) - commented just to document<br />
<nowiki>#</nowiki> Activate Open Window detection<br />
<nowiki>#</nowiki> set MAX_Bedroom_WindowSensor1 associate MAX_Bedroom_Heating<br />
<nowiki>#</nowiki> set MAX_Bedroom_Heating associate MAX_Bedroom_WindowSensor1<br />
<nowiki>#</nowiki><br />
<nowiki>#</nowiki> Define Week Profile<br />
<nowiki>#</nowiki> set MAX_Bedroom_Heating weekProfile Mon 17,05:00,19,06:00,21,07:15,17,19:00,19,21:00,17 Tue 17,05:00,19,06:00,21,07:15,17,19:00,19,21:00,17 Wed 17,05:00,19,06:00,21,07:15,17,19:00,19,21:00,17 Thu 17,05:00,19,06:00,21,07:15,17,19:00,19,21:00,17 Fri 17,05:00,19,06:00,21,07:15,17,19:00,19,21:00,17 Sat 17,07:00,19,09:00,21,10:00,17 Sun 17,07:00,19,09:00,21,10:00,17<br />
<nowiki>#</nowiki><br />
<nowiki>#</nowiki> Temperatur Scanner (Graphical)<br />
<nowiki>#</nowiki> attr MAX_Bedroom_Heating scanTemp 1<br />
<nowiki>#</nowiki> attr MAX_Bedroom_Heating userReadings onlyAutoMode { return "1";;}<br />
<nowiki>#</nowiki> attr MAX_Bedroom_Heating userReadings watchShutter { return "MAX_Bedroom_WindowSensor1";;}<br />
<nowiki>#</nowiki><br />
<nowiki>#</nowiki> WindowOpenTemperature (4.5 = OFF, No Window Detection)<br />
<nowiki>#</nowiki> set MAX_Bedroom_Heating windowOpenTemperature 5.5<br />
<br />
<br />
<nowiki>###</nowiki> 3.1 Child 1 (Heating Thermostat)<br />
define MAX_Child1_Heating MAX HeatingThermostat 05034f<br />
attr MAX_Child1_Heating MAX_Child2_Heating AllHeaters<br />
attr MAX_Child1_Heating room Child1<br />
attr MAX_Child1_Heating scanTemp 1<br />
attr MAX_Child1_Heating userReadings onlyAutoMode { return "1";;}<br />
define FileLog_MAX_Child1_Heating FileLog ./log/MAX_Child1_Heating-%Y.log MAX_Child1_Heating<br />
attr FileLog_MAX_Child1_Heating icon heizung.0<br />
attr FileLog_MAX_Child1_Heating logtype text<br />
attr FileLog_MAX_Child1_Heating room MAX <br />
<br />
<nowiki>###</nowiki> 3.2 Child 1 (Window Sensor)<br />
define MAX_Child1_WindowSensor MAX ShutterContact 053f76<br />
attr MAX_Child1_WindowSensor room Child1<br />
define FileLog_MAX_Child1_WindowSensor FileLog ./log/MAX_Child1_WindowSensor-%Y.log MAX_Child1_WindowSensor<br />
attr FileLog_MAX_Child1_WindowSensor logtype text<br />
attr FileLog_MAX_Child1_WindowSensor room MAX <br />
<br />
<nowiki>###</nowiki> 3.3 One-Time Configuration (only stored in actors, not in fhem.cfg) - commented just to document<br />
<nowiki>#</nowiki> Activate Open Window detection<br />
<nowiki>#</nowiki> set MAX_Child1_WindowSensor associate MAX_Child1_Heating<br />
<nowiki>#</nowiki> set MAX_Child1_Heating associate MAX_Child1_WindowSensor<br />
<nowiki>#</nowiki><br />
<nowiki>#</nowiki> Define Week Profile<br />
<nowiki>#</nowiki> set MAX_Child1_Heating weekProfile Mon 17,05:00,19,06:00,22,07:15,19,15:30,21,19:00,19,21:00,17 Tue 17,05:00,19,06:00,22,07:15,19,15:30,21,19:00,19,21:00,17 Wed 17,05:00,19,06:00,22,07:15,19,15:30,21,19:00,19,21:00,17 Thu 17,05:00,19,06:00,22,07:15,19,15:30,21,19:00,19,21:00,17 Fri 17,05:00,19,06:00,22,07:15,19,15:30,21,19:00,19,21:00,17 Sat 17,06:00,21,20:00,17 Sun 17,06:00,21,20:00,17<br />
<nowiki>#</nowiki><br />
<nowiki>#</nowiki> Temperatur Scanner (Graphical)<br />
<nowiki>#</nowiki> attr MAX_Child1_Heating scanTemp 1<br />
<nowiki>#</nowiki> attr MAX_Child1_Heating userReadings onlyAutoMode { return "1";;}<br />
<nowiki>#</nowiki> attr MAX_Child1_Heating userReadings watchShutter { return "MAX_Child1_WindowSensor";;}<br />
<nowiki>#</nowiki><br />
<nowiki>#</nowiki> set MAX_Child1_Heating windowOpenTemperature 5.5 <br />
<br />
<br />
<nowiki>###</nowiki> 4.1 Child 2 (Heating Thermostat)<br />
define MAX_Child2_Heating MAX HeatingThermostat 050352<br />
attr MAX_Child2_Heating room Child2<br />
attr MAX_Child2_Heating scanTemp 1<br />
attr MAX_Child2_Heating userReadings onlyAutoMode { return "1";;}<br />
define FileLog_MAX_Child2_Heating FileLog ./log/MAX_Child2_Heating-%Y.log MAX_Child2_Heating<br />
attr FileLog_MAX_Child2_Heating icon heizung.0<br />
attr FileLog_MAX_Child2_Heating logtype text<br />
attr FileLog_MAX_Child2_Heating room MAX<br />
define SVG_FileLog_MAX_Child2_Heating_1 SVG FileLog_MAX_Child2_Heating:SVG_FileLog_MAX_Child2_Heating_1:CURRENT<br />
attr SVG_FileLog_MAX_Child2_Heating_1 room Child2<br />
<br />
<nowiki>###</nowiki> 4.2 Child 2 (Window Sensor)<br />
define MAX_Child2_WindowSensor MAX ShutterContact 053fce<br />
attr MAX_Child2_WindowSensor room Child2<br />
define FileLog_MAX_Child2_WindowSensor FileLog ./log/MAX_Child2_WindowSensor-%Y.log MAX_Child2_WindowSensor<br />
attr FileLog_MAX_Child2_WindowSensor logtype text<br />
attr FileLog_MAX_Child2_WindowSensor room MAX <br />
<br />
<nowiki>###</nowiki> 4.3 One-Time Configuration (only stored in actors, not in fhem.cfg) - commented just to document<br />
<nowiki>#</nowiki> Activate Open Window detection<br />
<nowiki>#</nowiki> set MAX_Child2_WindowSensor associate MAX_Child2_Heating<br />
<nowiki>#</nowiki> set MAX_Child2_Heating associate MAX_Child2_WindowSensor<br />
<nowiki>#</nowiki><br />
<nowiki>#</nowiki> Define Week Profile<br />
<nowiki>#</nowiki> set MAX_Child2_Heating weekProfile Mon 17,05:00,19,06:00,22,07:15,19,15:30,21,19:00,19,21:00,17 Tue 17,05:00,19,06:00,22,07:15,19,15:30,21,19:00,19,21:00,17 Wed 17,05:00,19,06:00,22,07:15,19,15:30,21,19:00,19,21:00,17 Thu 17,05:00,19,06:00,22,07:15,19,15:30,21,19:00,19,21:00,17 Fri 17,05:00,19,06:00,22,07:15,19,15:30,21,19:00,19,21:00,17 Sat 17,06:00,21,20:00,17 Sun 17,06:00,21,20:00,17<br />
<nowiki>#</nowiki><br />
<nowiki>#</nowiki> Temperatur Scanner (Graphical)<br />
<nowiki>#</nowiki> attr MAX_Child2_Heating scanTemp 1<br />
<nowiki>#</nowiki> attr MAX_Child2_Heating userReadings onlyAutoMode { return "1";;}<br />
<nowiki>#</nowiki> attr MAX_Child2_Heating userReadings watchShutter { return "MAX_Child2_WindowSensor";;}<br />
<nowiki>#</nowiki><br />
<nowiki>#</nowiki> set MAX_Child2_Heating windowOpenTemperature 5.5<br />
<br />
<br />
<nowiki>###</nowiki> 5.1 Kitchen (Heating Thermostat)<br />
define MAX_Kitchen_Heating MAX HeatingThermostat 06546c<br />
attr MAX_Kitchen_Heating MAX_Child2_Heating AllHeaters<br />
attr MAX_Kitchen_Heating room Kitchen<br />
attr MAX_Kitchen_Heating scanTemp 1<br />
attr MAX_Kitchen_Heating userReadings onlyAutoMode { return "1";;}<br />
define FileLog_MAX_Kitchen_Heating FileLog ./log/MAX_Kitchen_Heating-%Y.log MAX_Kitchen_Heating<br />
attr FileLog_MAX_Kitchen_Heating icon heizung.0<br />
attr FileLog_MAX_Kitchen_Heating logtype text<br />
attr FileLog_MAX_Kitchen_Heating room MAX<br />
<br />
<nowiki>###</nowiki> 5.2 Kitchen (Window Sensor)<br />
define MAX_Kitchen_WindowSensor MAX ShutterContact 0612ce<br />
attr MAX_Kitchen_WindowSensor room Kitchen<br />
define FileLog_MAX_Kitchen_WindowSensor FileLog ./log/MAX_Kitchen_WindowSensor-%Y.log MAX_Kitchen_WindowSensor<br />
attr FileLog_MAX_Kitchen_WindowSensor logtype text<br />
attr FileLog_MAX_Kitchen_WindowSensor room MAX<br />
<br />
<nowiki>###</nowiki> 5.3 One-Time Configuration (only stored in actors, not in fhem.cfg) - commented just to document<br />
<nowiki>#</nowiki> Activate Open Window detection<br />
<nowiki>#</nowiki> set MAX_Kitchen_WindowSensor associate MAX_Kitchen_Heating<br />
<nowiki>#</nowiki> set MAX_Kitchen_Heating associate MAX_Kitchen_WindowSensor<br />
<nowiki>#</nowiki><br />
<nowiki>#</nowiki> Define Week Profile<br />
<nowiki>#</nowiki> set MAX_Kitchen_Heating weekProfile Mon 17,05:00,19,06:00,21,07:30,19,19:00,21,20:00,17 Tue 17,05:00,19,06:00,21,07:30,19,19:00,21,20:00,17 Wed 17,05:00,19,06:00,21,07:30,19,19:00,21,20:00,17 Thu 17,05:00,19,06:00,21,07:30,19,19:00,21,20:00,17 Fri 17,05:00,19,06:00,21,07:30,19,19:00,21,20:00,17 Sat 17,07:00,21,20:00,17 Sun 17,07:00,21,20:00,17<br />
<nowiki>#</nowiki><br />
<nowiki>#</nowiki> Temperatur Scanner (Graphical)<br />
<nowiki>#</nowiki> attr MAX_Kitchen_Heating scanTemp 1<br />
<nowiki>#</nowiki> attr MAX_Kitchen_Heating userReadings onlyAutoMode { return "1";;}<br />
<nowiki>#</nowiki> attr MAX_Kitchen_Heating userReadings watchShutter { return "MAX_Kitchen_WindowSensor";;}<br />
<nowiki>#</nowiki><br />
<nowiki>#</nowiki> set MAX_Kitchen_Heating windowOpenTemperature 5.5<br />
<br />
<br />
<nowiki>###</nowiki> 6.1 Livingroom (Heating Thermostats - Two)<br />
define MAX_Livingroom_Heating1 MAX HeatingThermostat 065531<br />
attr MAX_Livingroom_Heating1 room Livingroom<br />
define FileLog_MAX_Livingroom_Heating1 FileLog ./log/MAX_Livingroom_Heating1-%Y.log MAX_Livingroom_Heating1<br />
attr FileLog_MAX_Livingroom_Heating1 icon heizung.0<br />
attr FileLog_MAX_Livingroom_Heating1 logtype text<br />
attr FileLog_MAX_Livingroom_Heating1 room MAX <br />
<br />
define MAX_Livingroom_Heating2 MAX HeatingThermostat 06563a<br />
attr MAX_Livingroom_Heating2 room Livingroom<br />
define FileLog_MAX_Livingroom_Heating2 FileLog ./log/MAX_Livingroom_Heating2-%Y.log MAX_Livingroom_Heating2<br />
attr FileLog_MAX_Livingroom_Heating2 icon heizung.0<br />
attr FileLog_MAX_Livingroom_Heating2 logtype text<br />
attr FileLog_MAX_Livingroom_Heating2 room MAX <br />
<br />
<nowiki>###</nowiki> 6.2 Livingroom (Window Sensors - Two)<br />
define MAX_Livingroom_WindowSensor_Balcony MAX ShutterContact 0618ce<br />
attr MAX_Livingroom_WindowSensor_Balcony room Livingroom<br />
define FileLog_MAX_Livingroom_WindowSensor_Balcony FileLog ./log/MAX_Livingroom_WindowSensor_Balcony-%Y.log MAX_Livingroom_WindowSensor_Balcony<br />
attr FileLog_MAX_Livingroom_WindowSensor_Balcony logtype text<br />
attr FileLog_MAX_Livingroom_WindowSensor_Balcony room MAX<br />
<br />
<nowiki>###</nowiki> 6.3 Livingroom (Wall Thermostat)<br />
define MAX_Livingroom_THSensor MAX WallMountedThermostat 01c93f<br />
attr MAX_Livingroom_THSensor MAX_Child2_Heating AllHeaters<br />
attr MAX_Livingroom_THSensor room Livingroom<br />
define FileLog_MAX_Livingroom_THSensor FileLog ./log/MAX_Livingroom_THSensor-%Y.log MAX_Livingroom_THSensor<br />
attr FileLog_MAX_Livingroom_THSensor logtype text<br />
attr FileLog_MAX_Livingroom_THSensor room MAX<br />
<br />
<nowiki>###</nowiki> 6.4 One-Time Configuration (only stored in actors, not in fhem.cfg) - commented just to document<br />
<nowiki>#</nowiki> Activate Open Window detection<br />
<nowiki>#</nowiki> set MAX_Livingroom_WindowSensor_Balcony associate MAX_Livingroom_Heating1<br />
<nowiki>#</nowiki> set MAX_Livingroom_Heating1 associate MAX_Livingroom_WindowSensor_Balcony<br />
<nowiki>#</nowiki> set MAX_Livingroom_WindowSensor_Balcony associate MAX_Livingroom_Heating2<br />
<nowiki>#</nowiki> set MAX_Livingroom_Heating2 associate MAX_Livingroom_WindowSensor_Balcony<br />
<nowiki>#</nowiki> set MAX_Livingroom_WindowSensor_Balcony associate MAX_Livingroom_THSensor<br />
<nowiki>#</nowiki> set MAX_Livingroom_THSensor associate MAX_Livingroom_WindowSensor_Balcony<br />
<nowiki>#</nowiki> set MAX_Livingroom_THSensor associate MAX_Livingroom_Heating1<br />
<nowiki>#</nowiki> set MAX_Livingroom_Heating1 associate MAX_Livingroom_THSensor<br />
<nowiki>#</nowiki> set MAX_Livingroom_THSensor associate MAX_Livingroom_Heating2<br />
<nowiki>#</nowiki> set MAX_Livingroom_Heating2 associate MAX_Livingroom_THSensor<br />
<nowiki>#</nowiki><br />
<nowiki>#</nowiki> Define Week Profile<br />
<nowiki>#</nowiki> set MAX_Livingroom_THSensor weekProfile Mon 17,05:00,19,06:00,22,07:15,21,22:30,17 Tue 17,05:00,19,06:00,22,07:15,21,22:30,17 Wed 17,05:00,19,06:00,22,07:15,21,22:30,17 Thu 17,05:00,19,06:00,22,07:15,21,22:30,17 Fri 17,05:00,19,06:00,22,07:15,21,22:30,17 Sat 17,06:00,21,22:30,17 Sun 17,06:00,21,22:30,17<br />
<nowiki>#</nowiki><br />
<nowiki>#</nowiki> Temperatur Scanner (Graphical)<br />
<nowiki>#</nowiki> attr MAX_Livingroom_Heating1 scanTemp 1<br />
<nowiki>#</nowiki> attr MAX_Livingroom_Heating2 scanTemp 1<br />
<nowiki>#</nowiki> attr MAX_Livingroom_Heating1 userReadings onlyAutoMode { return "1";;}<br />
<nowiki>#</nowiki> attr MAX_Livingroom_Heating1 userReadings watchShutter { return "MAX_Livingroom_WindowSensor_Balcony";;}<br />
<nowiki>#</nowiki> attr MAX_Livingroom_Heating2 userReadings onlyAutoMode { return "1";;}<br />
<nowiki>#</nowiki> attr MAX_Livingroom_Heating2 userReadings watchShutter { return "MAX_Livingroom_WindowSensor_Balcony";;}<br />
<nowiki>#</nowiki> attr MAX_Livingroom_THSensor userReadings onlyAutoMode { return "1";;}<br />
<nowiki>#</nowiki> attr MAX_Livingroom_THSensor scanTemp 1<br />
<nowiki>#</nowiki><br />
<nowiki>#</nowiki> set MAX_Livingroom_Heating1 windowOpenTemperature 5.5<br />
<nowiki>#</nowiki> set MAX_Livingroom_Heating2 windowOpenTemperature 5.5<br />
<nowiki>#</nowiki> set MAX_Livingroom_THSensor windowOpenTemperature 5.5 <br />
<br />
<br />
<nowiki>###</nowiki> 7.1 Toilette (Heating Thermostat)<br />
define MAX_Toilette_Heating MAX HeatingThermostat 06b990<br />
attr MAX_Toilette_Heating MAX_Child2_Heating AllHeaters<br />
attr MAX_Toilette_Heating room Toilette<br />
attr MAX_Toilette_Heating scanTemp 1<br />
attr MAX_Toilette_Heating userReadings onlyAutoMode { return "1";;}<br />
define FileLog_MAX_Toilette_Heating FileLog ./log/MAX_Toilette_Heating-%Y.log MAX_Toilette_Heating<br />
attr FileLog_MAX_Toilette_Heating icon heizung.0<br />
attr FileLog_MAX_Toilette_Heating logtype text<br />
attr FileLog_MAX_Toilette_Heating room MAX<br />
<br />
<nowiki>###</nowiki> 7.2 Toilette (Window Sensor)<br />
define MAX_Toilette_WindowSensor MAX ShutterContact 053d50<br />
attr MAX_Toilette_WindowSensor room Toilette<br />
define FileLog_MAX_Toilette_WindowSensor FileLog ./log/MAX_Toilette_WindowSensor-%Y.log MAX_Toilette_WindowSensor<br />
attr FileLog_MAX_Toilette_WindowSensor logtype text<br />
attr FileLog_MAX_Toilette_WindowSensor room MAX<br />
<br />
<nowiki>###</nowiki> 7.3 One-Time Configuration (only stored in actors, not in fhem.cfg) - commented just to document<br />
<nowiki>#</nowiki> Activate Open Window detection<br />
<nowiki>#</nowiki> set MAX_Toilette_WindowSensor associate MAX_Toilette_Heating<br />
<nowiki>#</nowiki> set MAX_Toilette_Heating associate MAX_Toilette_WindowSensor<br />
<nowiki>#</nowiki><br />
<nowiki>#</nowiki> Define Week Profile<br />
<nowiki>#</nowiki> set MAX_Toilette_Heating weekProfile Mon 17,05:00,19,06:00,21,07:30,19,19:00,21,20:00,17 Tue 17,05:00,19,06:00,21,07:30,19,19:00,21,20:00,17 Wed 17,05:00,19,06:00,21,07:30,19,19:00,21,20:00,17 Thu 17,05:00,19,06:00,21,07:30,19,19:00,21,20:00,17 Fri 17,05:00,19,06:00,21,07:30,19,19:00,21,20:00,17 Sat 17,07:00,21,20:00,17 Sun 17,07:00,21,20:00,17<br />
<nowiki>#</nowiki><br />
<nowiki>#</nowiki> Temperatur Scanner (Graphical)<br />
<nowiki>#</nowiki> attr MAX_Toilette_Heating scanTemp 1<br />
<nowiki>#</nowiki> attr MAX_Toilette_Heating userReadings onlyAutoMode { return "1";;}<br />
<nowiki>#</nowiki> attr MAX_Toilette_Heating userReadings watchShutter { return "MAX_Kitchen_WindowSensor";;}<br />
<nowiki>#</nowiki><br />
<nowiki>#</nowiki> set MAX_Toilette_Heating windowOpenTemperature 5.5<br />
<br />
<br />
<nowiki>###</nowiki> 8.1 Working room (Heating Thermostat)<br />
define MAX_Working_Heating MAX HeatingThermostat 020551<br />
attr MAX_Working_Heating room Workingroom<br />
attr MAX_Working_Heating scanTemp 1<br />
attr MAX_Working_Heating userReadings onlyAutoMode { return "1";;}<br />
define FileLog_MAX_Working_Heating FileLog ./log/MAX_Working_Heating-%Y.log MAX_Working_Heating<br />
attr FileLog_MAX_Working_Heating icon heizung.0<br />
attr FileLog_MAX_Working_Heating logtype text<br />
attr FileLog_MAX_Working_Heating room MAX<br />
define SVG_FileLog_MAX_Working_Heating_1 SVG FileLog_MAX_Working_Heating:SVG_FileLog_MAX_Working_Heating_1:CURRENT<br />
attr SVG_FileLog_MAX_Working_Heating_1 room Workingroom<br />
<br />
<nowiki>###</nowiki> 8.2 Working room (Window Sensor)<br />
define MAX_Working_WindowSensor MAX ShutterContact 06102b<br />
attr MAX_Working_WindowSensor room Workingroom<br />
define FileLog_MAX_Working_WindowSensor FileLog ./log/MAX_Working_WindowSensor-%Y.log MAX_Working_WindowSensor<br />
attr FileLog_MAX_Working_WindowSensor logtype text<br />
attr FileLog_MAX_Working_WindowSensor room MAX <br />
<br />
<nowiki>###</nowiki> 8.3 One-Time Configuration (only stored in actors, not in fhem.cfg) - commented just to document<br />
<nowiki>#</nowiki> Activate Open Window detection<br />
<nowiki>#</nowiki> set MAX_Working_WindowSensor associate MAX_Working_Heating<br />
<nowiki>#</nowiki> set MAX_Working_Heating associate MAX_Working_WindowSensor<br />
<nowiki>#</nowiki><br />
<nowiki>#</nowiki> Define Week Profile<br />
<nowiki>#</nowiki> set MAX_Working_Heating weekProfile Mon 17,05:00,19,06:00,21,07:15,19,15:30,21,19:00,19,21:00,17 Tue 17,05:00,19,06:00,21,07:15,19,15:30,21,19:00,19,21:00,17 Wed 17,05:00,19,06:00,21,07:15,19,15:30,21,19:00,19,21:00,17 Thu 17,05:00,19,06:00,21,07:15,19,15:30,21,19:00,19,21:00,17 Fri 17,05:00,19,06:00,21,07:15,19,15:30,21,19:00,19,21:00,17 Sat 17,06:00,21,09:00,19,16:00,21,20:00,17 Sun 17,06:00,21,09:00,19,16:00,21,20:00,17<br />
<nowiki>#</nowiki><br />
<nowiki>#</nowiki> Temperatur Scanner (Graphical)<br />
<nowiki>#</nowiki> attr MAX_Working_Heating scanTemp 1<br />
<nowiki>#</nowiki> attr MAX_Working_Heating userReadings onlyAutoMode { return "1";;}<br />
<nowiki>#</nowiki> attr MAX_Working_Heating userReadings watchShutter { return "MAX_Working_WindowSensor";;}<br />
<nowiki>#</nowiki><br />
<nowiki>#</nowiki> set MAX_Working_Heating windowOpenTemperature 5.5 <br />
<br />
define SVG_FileLog_MAX_Bedroom_Heating_1 SVG FileLog_MAX_Bedroom_Heating:SVG_FileLog_MAX_Bedroom_Heating_1:CURRENT<br />
define SVG_FileLog_MAX_Child1_Heating_1 SVG FileLog_MAX_Child1_Heating:SVG_FileLog_MAX_Child1_Heating_1:CURRENT<br />
define SVG_FileLog_MAX_Bedroom_Heating_2 SVG FileLog_MAX_Bedroom_Heating:SVG_FileLog_MAX_Bedroom_Heating_2:CURRENT <br />
<br />
<nowiki>###</nowiki> 9.1 ECO-Wallbutton<br />
define MAX_WallButton MAX PushButton 0521c4<br />
<nowiki>#</nowiki><br />
<nowiki>#</nowiki> Define House to control all Heaters at once<br />
define AllHeaters structure AllMyHeaters MAX_Child2_Heating MAX_Workingroom_Heating MAX_Child1_Heating MAX_Livingroom_THSensor MAX_Bedroom_Heating MAX_Toilette_Heating MAX_Kitchen_Heating MAX_Bathroom_Heating<br />
attr AllHeaters room House<br />
attr AllHeaters webCmd desiredTemperature<br />
<nowiki>#</nowiki><br />
define MAX_HouseECOHeating notify MAX_WallButton:(onoff).* { if ($EVTPART1 eq 0) { fhem("set AllHeaters desiredTemperature eco") && Log(3,"===> ECO-Mode set");;} else { fhem("set AllHeaters desiredTemperature auto") && Log(3,"===> AUTO-Mode set");;}}<br />
<nowiki>#</nowiki><br />
<nowiki>#</nowiki><br />
define SVG_FileLog_MAX_Bathroom_Heating_1 SVG FileLog_MAX_Bathroom_Heating:SVG_FileLog_MAX_Bathroom_Heating_1:CURRENT<br />
define SVG_FileLog_MAX_Bedroom_Heating_3 SVG FileLog_MAX_Bedroom_Heating:SVG_FileLog_MAX_Bedroom_Heating_3:CURRENT<br />
define SVG_FileLog_MAX_Child1_Heating_2 SVG FileLog_MAX_Child1_Heating:SVG_FileLog_MAX_Child1_Heating_2:CURRENT<br />
define SVG_FileLog_MAX_Child2_Heating_2 SVG FileLog_MAX_Child2_Heating:SVG_FileLog_MAX_Child2_Heating_2:CURRENT<br />
define SVG_FileLog_MAX_Kitchen_Heating_1 SVG FileLog_MAX_Kitchen_Heating:SVG_FileLog_MAX_Kitchen_Heating_1:CURRENT<br />
define SVG_FileLog_MAX_Livingroom_THSensor_1 SVG FileLog_MAX_Livingroom_THSensor:SVG_FileLog_MAX_Livingroom_THSensor_1:CURRENT<br />
define SVG_FileLog_MAX_Toilette_Heating_1 SVG FileLog_MAX_Toilette_Heating:SVG_FileLog_MAX_Toilette_Heating_1:CURRENT<br />
define SVG_FileLog_MAX_Working_Heating_2 SVG FileLog_MAX_Working_Heating:SVG_FileLog_MAX_Working_Heating_2:CURRENT<br />
<br />
=== Planned changes ===<br />
ADD ME<br />
<br />
[[Kategorie:MAX]]</div>GRZBRZ