FHEMWiki - Benutzerbeiträge [de]

Mi vacuum

2024-06-16T15:25:57Z

Caldir65: Link zu fhempy zum Auslesen des Tokens hinzugefügt

{{Todo|Aktualiserung / Text weniger flapsig formulieren / Einbindung Info-Box. Information, die generell für das Modul [[XiaomiDevice]] gilt, sollte auf die Modulseite "verschoben" werden.}}
=Mi Vacuum=
Wie der preiswerte Staubsaugerroboter auch auf FHEM hört...

==Für wen ist die Anleitung gedacht?==
Ich gehe davon aus, dass ihr ein funktionierendes FHEM auf einem Linux Rechner (Debian) betreibt.

Weiterhin denke ich, dass euer Hauptarbeitsrechner unter Windows läuft.

Als Smartphone OS Android (wer Apple hat, kann gerne die Token-Auslese-Geschichte hier beschreiben).

Um das Teil auch von Alexa aus ein und aus zu schalten, sollte auch die Installation von Alexa in FHEM fertig sein.

==Die Einrichtung des Moduls==
===Vorarbeiten (Linux)===
Zunächst fangen wir mal auf unserem FHEM Rechner an. Mit Putty verbinden wir uns per SSH mit dem FHEM Computer (Todo: Das ist hier ist für Windows-Nutzer...)

Folgende Befehle können benötigt werden (Debian):
* <code>sudo apt-get install libjson-perl</code>
* <code>sudo apt-get install libdigest-md5-perl</code>
* <code>sudo apt-get install libcrypt-cbc-perl</code>
* <code>sudo apt install libcryptx-perl</code>

* <code>sudo apt-get install libcrypt-ecb-perl</code> (nur nötig, wenn ihr einen verschlüsselten Token mit 96 Zeichen habt)
* <code>sudo cpan Crypt::Rijndael_PP</code> (nur nötig, wenn libcryptx-perl aus irgendwelchen Gründen nicht funktioniert)
* <code>sudo cpan Crypt::Cipher::AES</code> (nur nötig, wenn Crypt::Rijndael_PP aus irgendwelchen Gründen nicht funktioniert)

Wenn bei dem ein oder anderen Modul die Meldung kommt, dass es schon installiert ist, einfach mit dem nächsten Befehl weiter machen. Das CPAN Teil würde ich am Schluss machen, das braucht ziemlich lang zum installieren.

===Vorarbeiten am Smartphone (Token)===
Das Problem ist folgendes:

Wenn der Roboter mit dem WLAN verbunden wird, generiert er einen Token. Das ist ein Schlüssel, ohne den er sich nicht steuern lässt. Damit FHEM drauf zugreifen kann, benötigt man diesen Token.

Mit den neueren Versionen der MiHome App klappt das Auslesen der Tokens leider nicht mehr.

====Auslesen bei Android Endgeräten====

Ich gehe davon aus, dass der Staubsauger mit der original MiHome App eingebunden ist und funktioniert. (Ich habe bei der Einrichtung des Servers => "other" gewählt. Offenbar wollen neuere Staubsauger sich mit "China Mainland" nicht mehr verbinden. Tut hier an dieser Stelle zwar nichts zur Sache, aber vielleicht hilft es dem ein oder anderen. Wenn man die Region gewechselt hat, muss man auch den Staubsauger neu einbinden)

* MiHome löschen
* alte MiHome suchen (APKMirror z.B., Version 5.0.19 hat bei mir funktioniert, unsichere Quellen müssen erlaubt sein)
* runtergeladene MiHome App öffnen und anmelden (sollte ganz normal den Sauger finden)
* USB-Debugging am Handy einschalten (Entwickleroptionen...)
* Handy mit USB Kabel und PC verbinden
* [https://github.com/ultrara1n/MiToolkit/releases MiToolkit] 1.6 runterladen und öffnen
* [https://github.com/ultrara1n/MiToolkit/releases MiToolkit] erzeugt nun am Handy ein Backup
* anschließend zeigt es den Token direkt am PC an

====Auslesen bei iOS Endgeräten====

Zum Auslesen des Tokens mit iOS Endgeräten kann die Anleitung unter folgendem Link befolgt werden: [https://forum.smartapfel.de/forum/thread/370-xiaomi-token-auslesen/]

'''Auslesen mit fhem / fhempy'''

In fhem gibt es auch noch das [https://github.com/fhempy/fhempy/blob/master/README.md fhempy-System], dafür gibt es auch ein Modul zum Auslesen von Xiaomi-Token aus deren Cloud, u.a. auch das Token für unseren Mi-Vacuum.

===Installation des inoffiziellen Moduls===
Das Modul ist seit 28.02.2018 ein offizielles Modul. Eine separates Installation ist nicht (mehr) notwendig.

==Einrichten des Moduls [[XiaomiDevice]] ==

<pre>
define Mi_Vacuum XiaomiDevice 192.168.222.77 55387753545937326a33396943557999

attr Mi_Vacuum subType VacuumCleaner
</pre>

Und schon (=etwa nach 10 Sekunden) sollte euer Roboter in FHEM mit ganz vielen Readings auftauchen.

==Anwendung: Sprachsteuerung mit Alexa (einfach, ein und aus)==
Wie bindet man das jetzt schnell in Alexa ein?

Wir legen uns in FHEM einen Dummy an. Dieser wird ein Switch (on off). Dazu noch ein DOIF oder ein notify, welches diesen Switch überwacht. Je nach Status des Dummys schalten wir den Roboter.

Ein List meines Dummys:
<pre>
Internals:
CFGFN
NAME Mi_Vacuum_Staubsauger
NR 719473
STATE on
TYPE dummy
Readings:
2017-09-18 21:10:12 state on
Attributes:
alexaName Mi_Vacuum_Staubsauger
genericDeviceType switch
room alexa
setList on off
</pre>

Mein DOIF:

<pre>
define di_Mi_Vacuum DOIF ([Mi_Vacuum_Staubsauger:"on"]) (set Mi_Vacuum start) DOELSE (set Mi_Vacuum charge)
</pre>

Das Attribut do always nicht vergessen!

Den Dummy setzen wir in den Raum, der unsere Alexa Geräte beinhaltet. Nun den Alexa FHEM Service neu starten. Anschließend sollte eine Suche nach neuen Geräten in Alexa unseren Dummy finden. Für diesen legen wir in Alexa einen neuen Raum an, z.B. Staubsauger.

Fertig.

Ein "Alexa schaltet den Staubsauger ein" lässt unseren Mi-Vacuum loslegen. "Alexa schalte den Staubsauger aus" schickt ihn wieder zurück zu seiner Station.

==Zonenreinigung==
Um nur Teilbereiche einer Wohnung zu reinigen, ist es möglich über das Modul Zonen zu definieren. Hierzu ist es notwendig, die Koordinaten der gewünschten Zone zu ermitteln. Hierzu eignet sich die [https://xiaomi.flole.de/ FloleVac App] die entweder auf einem Android Device oder auf einem Android Emulator (z.B. [https://www.bluestacks.com/download.html BlueStacks]) verwendet werden kann. In der App kann man in der Karte eine Zone für die Reinigung markieren und durch langes Gedrückthalten des "Reinigen-Buttons" in der FloleVac App die Koordinaten dieser Zone in die Zwischenablage kopieren.

Mit diesen Koordindaten im Format [16200,27250,31650,27650,1] kann man dann loslegen die Zonen in FHEM zu definieren:

Entweder direkt über die Werte:

<pre>
set vacuum zone 16200,27250,31650,27650,1 23700,23050,25200,24200,2
</pre>

Oder über die passenden Attribute erst ein Alias anlegen:

<pre>
attr vacuum zone_names home:[16200,27250,31650,27650,1],[23700,23050,25200,24200,2] livingroom:[16200,26250,23000,30150,1]
</pre>

Ein Alias kann dann wie folgt genutzt werden:

<pre>
set vacuum zone home
</pre>

==Probleme und Lösungen==
===Crypt::Cipher::AES or Crypt::Rijndael_PP is required!===
Die Meldung im STATE des Devices bedeutet, dass noch einige Debian/Perl-Module installiert werden müssen. Siehe [[#Vorarbeiten (Linux)]].

Danach ist darauf zu achten, dass das Device wieder aktiviert wird.
attr <devicename> disable 0
==Quellen==
* {{Link2Forum|Topic=73052|LinkText=Forums-Thread}}
* {{Link2Forum|Topic=76940|LinkText=Diskussionsthread}}
* [http://miniweb.sourceforge.net/ MiniWeb], kleiner WebServer für Windows
* [https://xiaomi.flole.de/ Flole], alternative App für Android, die das Token nach GoogleDrive exportiert
* [http://www.roboter-forum.com/forumdisplay.php?130-Xiaomi Roboter-Forum] deutschsprachiges Forum, welches sich mit dem Mi Vacuum beschäftigt (auch vor dem Kauf des Roboters lohnt sich ein Besuch dort)
[[Kategorie:Other Components]]

DbLog

2024-01-07T08:18:40Z

Caldir65: Bei Synology mit DSM 7.2 (z.B. beim DS923+) ist z.B. der Port der MariaDB wieder von Haus aus auf Standard gesetzt ...

{{Infobox Modul
|ModPurpose=Protokolliert Ereignisse in einer Datenbank
|ModType=h
|ModForumArea=Automatisierung
|ModTechName=93_DbLog.pm
|ModOwner=tobiasfaust ({{Link2FU|118|Forum}}/[[Benutzer Diskussion:Tobias.faust|Wiki]]) DS_Starter ({{Link2FU|16933|Forum}}/[[Benutzer Diskussion:DS_Starter|Wiki]])
}}
== Einleitung ==
Mit der Zeit entstehen in FHEM recht umfangreiche Log-Daten für die verschiedensten konfigurierten Devices. Die übliche Einstiegs-[[Konfiguration]] sieht vor, dass die Logs als {{Link2CmdRef|Lang=de|Anker=FileLog|Label=FileLog}} gespeichert werden - je nach Einstellung in wenigen sehr großen oder vielen kleineren Dateien. Der Datei-basierte Zugriff ist allerdings nicht wirklich performant und kann schnell zum Flaschenhals werden (z.B. bei der Darstellung von Graphen über einen längeren Zeitraum).

Alternativ kann FHEM die Log-Daten mittels {{Link2CmdRef|Lang=de|Anker=DbLog|Label=DbLog}} in einer Datenbank speichern. Diese kann lokal als einfache SQLite- oder als zentrale Server-Datenbank (s.u.) gestaltet sein. Schon eine lokale einfache SQLite-Datenbank ist in der Regel deutlich performanter als File-basierte Logs.

Damit eine Datenbank-Nutzung möglich ist, müssen folgende Anpassungen gemacht werden:
# [[#Datenbank|Erstellen einer entsprechenden Datenbank]]
# [[#Datenbank-Anbindung mittels db.conf|Konfiguration der Datenbank-Anbindung in FHEM]]
# [[#Konfiguration als Device in fhem.cfg|Anpassen aller (oder einzelner) Konfigurationen von FileLog nach DbLog]]
# [[#Anpassen der gplot-Konfigurationen|Ggf. Anpassen der gplot-Konfigurationen]]

Eine weitere Alternative bietet das Modul [[InfluxDBLogger]].

Reporting und Management von DbLog-Datenbankinhalten kann mit dem Modul [[DbRep - Reporting und Management von DbLog-Datenbankinhalten|DbRep]] stattfinden.

== Konfiguration ==
=== Datenbank-Anbindung mittels db.conf ===
{{Randnotiz|RNTyp=y|RNText='''Anmerkung''': MariaDB10 nutzt nicht Port 3306 sondern 3307. Dies ist zum Beispiel bei einigen Synology NAS der Fall.}}
DbLog wird durch 2 verschiedene Einträge aktiviert/definiert. In einer Datei namens '''db.conf''' werden die Parameter für eine Verbindung zur Datenbank (host, username, password, etc.) hinterlegt. Diese Datei kann in einem beliebigen Verzeichnis angelegt werden. Für eine MySQL-Datenbank sieht die db.conf folgendermaßen aus:

%dbconfig= (
connection => "mysql:database=fhem;host=db;port=3306",
user => "fhemuser",
password => "fhempassword",
);

Im Verzeichnis '''contrib/dblog''' der FHEM-Installation befindet sich eine Beispielkonfiguration mit der Syntax für jeden unterstützen Datenbanktyp.
Es wird empfohlen, diese Datei zu kopieren und erst dann entsprechend zu bearbeiten. Am Besten kopiert man diese Datei in das FHEM Home Directory /opt/fhem/ und achtet auf die entsprechenden Rechte!
<syntaxhighlight lang="bash">chown fhem:dialout /opt/fhem/db.conf</syntaxhighlight>

=== Konfiguration als Device ===
Das DbLog Device wird dann definiert mit
:<code>define <name> DbLog <configfilename> <regexp> </code>
wobei ''<configfilename>'' dem Pfad zur zuvor angelegten db.conf entspricht.
Ein Beispiel hierfür wäre:
:<code>define logdb DbLog ./db.conf .*:.* </code>
Die Angabe von <code>.*:.*</code> bedeutet, dass sämtliche DeviceMessages (Messwerte, Batteriestatus, KeepAlives, etc.) in die Datenbank geschrieben werden. Dies führt u.U. dazu, dass die Datenbank auch mit vielen teils irrelevanten Werten gefüllt wird. Man kann daher die zu loggenden Werte einschränken, indem man genau angibt welche Werte übertragen werden sollen. Dies ist in [[#Finetuning des Loggings]] beschrieben.

Unbedingt beachten: bei Verwendung des Moduls configdb wird die Konfigurationsdatei aus der '''''Datenbank''''' gelesen. Deshalb ist es erforderlich, die Datei mittels <code>configdb fileimport db.conf </code> vorher zu importieren !

=== Finetuning des Loggings ===
Bei der Konfiguration des Log-Devices werden die zu loggenden Daten definiert - in der einfachsten Form sieht das so aus: <code>define logdb DbLog ./db.conf .*:.* </code>. Die Angabe von <code>.*:.*</code> bedeutet, dass sämtliche DeviceMessages (Messwerte, Batteriestatus, KeepAlives, etc.) in die Datenbank geschrieben werden. Dies führt u.U. dazu, dass die Datenbank auch mit sehr vielen und teils nicht benötigten Werten gefüllt wird und schnell wächst. Die Datenbank ist zwar deutlich leistungsfähiger, was große Datenmengen angeht, Datensparsamkeit kann aber schnell sinnvoll werden...

Um das Log-Aufkommen einzugrenzen gibt es mehrere Ansätze:
* Einschränkung über den <code>define</code>-Eintrag
* Einschränkung über DbLogExclude-Einträge der jeweiligen Devices
* Einschränkung über DbLogInclude-Einträge des jeweiligen Devices
* Ausschluß von Device/Reading-Kombinationen über das Attribut "excludeDevs". Es können {{Link2CmdRef|Anker=devspec|Lang=de|Label=devspec}} verwendet werden.

==== Einschränkung über den zentralen <code>define</code>-Eintrag ====
Man kann die zu loggenden Werte einschränken, indem man genau angibt welche Werte übertragen werden sollen. Die erste Wildcard, also das erste <code>.*</code>, entspricht dem in FHEM verwendeten Device-Namen. Die zweite Wildcard entspricht dem vom Device ausgegebenen zu loggenden Wert. Separiert werden beiden Angaben durch einen Doppelpunkt.

Ein Beispiel, um zwar alle definierten Devices zu erfassen, aber nur die Werte Temperatur, Ventilposition und Luftfeuchte in die Datenbank zu schreiben wäre:
:<code>define myDbLog DbLog ./db.conf .*:(temperature|valveposition|humidity).* </code>

==== Einschränkung über die jeweiligen Devices ====
Man kann die zu loggenden Werte für einzelne Devices separat einschränken, ohne dies im zentralen define-Eintrag machen zu müssen. Dies kann interessant sein, wenn beispielsweise ein Device Fehlerwerte meldet, die uninteressant sind, oder es meldet unnötig häufig Werte - beides ist z.B. bei 1-wire-Temperatursensoren gerne der Fall.

Um das einzuschränken gibt es 2 Stellparameter, die als Attribute direkt zum jeweiligen Device konfiguriert werden:
* DbLogExclude - definiert Werte, die nicht geloggt werden sollen
* DbLogInclude - definiert Werte, die geloggt werden sollen ( siehe attr DbLogSelectionMode )
* event-min-interval, event-on-change-reading und event-on-update-reading beeinflussen, wie häufig Werte geloggt werden (vgl. {{Link2CmdRef|Lang=de|Anker=event-on-update-reading}})

Eine konkrete Konfiguration für einen sehr gesprächigen 1-wire-Temperatursensor könnte wie folgt aussehen:
<pre>
define EG_Balkon GPIO4 BUSMASTER
attr EG_Balkon DbLogExclude failures,T,85 # logge keine "failures", "T"-Werte und "85"-Werte (default-Werte, wenn keine Temperatur gelesen werden kann)
attr EG_Balkon event-on-change-reading state # logge nur, wenn sich ein Wert ändert (wenn sich die Temperatur nicht ändert, logge das nicht)
attr EG_Balkon event-min-interval state:900 # logge spätestens alle 900sec = 15min
attr EG_Balkon event-on-update-reading .* # logge alle Werte, die aktualisiert werden

attr <1-Wire-Device vom Typ OWTHERM oder OWSWITCH> DbLogExclude data.* # verhindert das Logging der state-Eintragungen
</pre>

Eine in diesem {{Link2Forum|Topic=33697|Message=264127}} vorgestellte Strategie zur Vermeidung unnötigen Loggings ist, dass bei der Definition von Devices durch das nachfolgende <code>notify</code> automatisch ein DbLogExclude für alle Werte (.*) des Devices zugewiesen wird und dies nur bei Interesse an geloggten Werten gelöscht bzw. angepasst wird:
<code>define nDbLogExclude notify global:DEFINED.* attr $EVTPART1 DbLogExclude .*</code>

Ebenso ist es mittlerweile möglich, lediglich erwünschte Werte (Positiv-Liste) zu loggen und alle anderen zu verwerfen. Hierfür wird im LogDevice das attribut DbLogSelectionMode Include verwendet. Nun kann für jedes Device mit DbLogInclude <Reading1>,<Reading2>,... angegeben werden, welche Readings geloggt werden sollen.
Integriert ist ebenfalls ein "min-interval", siehe {{Link2CmdRef}}.

== Datenbank ==
Unterstützte Datenbanksysteme (Auswahl):
* Sqlite
* MySQL
* PostGreSql

=== Tabellen ===
Die Datenbank ist relativ simpel gestaltet und besteht lediglich aus den folgenden beiden Tabellen:
* current
* history

DbLog ist auf eine feste Tabellenstruktur angewiesen. Man muss daher in seiner Datenbank eine Tabelle mit folgenden Spalten anlegen:
{| class="wikitable"
|-
! Spalte
! Beschreibung (en)
! Beschreibung (de)
! Beispiel
|-
| '''TIMESTAMP'''
| timestamp of event
| Zeitstempel
| 2007-12-30 21:45:22
|-
| '''DEVICE'''
| device name
| Device-Name
| Wetterstation
|-
| '''TYPE'''
| device type
| Device-Typ
| KS300
|-
| '''EVENT'''
| event specification as full string
| Eventspezifikation als Text
| humidity: 71 (%)
|-
| '''READING'''
| name of reading extracted from event
| Bezeichnung des Readings
| humidity
|-
| '''VALUE'''
| actual reading extracted from event
| Wert des Readings
| 71
|-
| '''UNIT'''
| unit extracted from event
| Einheit des Readings
| %
|-
|}

Die Vorlagen zur Anlage von Tabellen und Indizes sind für jeden unterstützten Datenbanktyp im Verzeichnis '''contrib/dblog''' der FHEM-Installation, oder hier zu finden: [https://svn.fhem.de/trac/browser/trunk/fhem/contrib/dblog/ Link]. Das MySQL-Skript (db_create_mysql.sql) legt eine neue Datenbank, das PostGres-Skript (db_create_postgresql.sql) ein neues Schema mit Namen "fhem" an.

==== current ====
Die Tabelle current enthält für jedes zu loggende Device lediglich den letzten Wert. Falls noch kein Wert geloggt wurde, ist diese Tabelle leer.
Falls der Inhalt gelöscht wird, bauen sich die Daten automatisch wieder auf. Es gehen durch das löschen der Tabelle current keine Log-Informationen verloren.
Der Inhalt wird aber u.a. für die Dropdown-Felder beim Plot-Editor verwendet.

Um doppelte Einträge in der Tabelle zu vermeiden, wurden die Möglichkeit geschaffen Primary Keys zu definieren. Da in der Spalte <code>READING</code> u.U. bei verschiedenen Geräten gleiche Namen vorkommen können, sollte der Primary Key um den Gerätenamen erweitert werden. Der Primary Key sollte also aus <code>DEVICE</code> und <code>READING</code> bestehen. Um in der Datenbank ''fhem'' diesen PK zu setzen, kann folgender SQL Code verwendet werden:

<syntaxhighlight lang="sql">
ALTER TABLE `fhem`.`current`
CHANGE COLUMN `DEVICE` `DEVICE` VARCHAR(64) CHARACTER SET 'utf8' COLLATE 'utf8_bin' NOT NULL ,
CHANGE COLUMN `READING` `READING` VARCHAR(64) CHARACTER SET 'utf8' COLLATE 'utf8_bin' NOT NULL ,
ADD PRIMARY KEY (`DEVICE`, `READING`);
</syntaxhighlight>Achtung: Die Tabelle "current" wird nur befüllt, wenn das Attribut DbLogType auf Current oder Current/History gesetzt ist.

==== history ====
Die Tabelle history enthält alle bisher geloggten Daten. Löschen in dieser Tabelle bedeutet automatisch Datenverlust (gewollt oder nicht ... )
Der Inhalt dieser Tabelle wird verwendet, um die Plots zu zeichnen oder Auswertungen mit [[DbRep - Reporting und Management von DbLog-Datenbankinhalten|DbRep]] anzufertigen

{{Todo|Ausbauen}}

Um Problem beim Import von cacheFiles zu vermeiden, kann in der Datenbank ein PK angelegt werden, welcher Timestamp, Device und Reading umfasst. Dadurch werden doppelte Einträge wirksam verhindert.

== Anpassen der gplot-Konfigurationen ==
Die meisten gplot-Konfigurationen sind bisher lediglich auf FileLog-Konfigurationen ausgelegt. Deshalb müssen sie für die Verwendung mit DbLog angepasst werden. Glücklicherweise beschränkt sich dies auf die reinen FileLog-Zeilen - es müssen die DbLog-Äquivalente hinzugefügt werden. Die FileLog-Einträge müssen zwar nicht gelöscht werden, wenn man aber FileLog und DbLog parallel betreibt, sollte man getrennte gplot-Dateien für beide Logging-Typen haben um Auswertungsprobleme erkennen zu können.

Für die fht.gplot Konfiguration sähe die Anpassung wie folgt aus (lediglich die vier DbLog-Zeilen wurden hinzugefügt):
<syntaxhighlight lang="Perl">
# Created by FHEM/98_SVG.pm, 2014-12-25 21:53:30
set terminal png transparent size <SIZE> crop
set output '<OUT>.png'
set xdata time
set timefmt "%Y-%m-%d_%H:%M:%S"
set xlabel " "
set title '<L1>'
set ytics nomirror
set y2tics
set grid y2tics
set ylabel "Actuator/Window (%)"
set y2label "Temperature in C"
set yrange 0:100
set y2range 5:25

#FileLog 4:.measured-temp\x3a:0:
#FileLog 4:.actuator\x3a:0:int
#FileLog 4:.desired-temp::
#FileLog 4:.window\x3a::

#DbLog <SPEC1>:.measured-temp:0:
#DbLog <SPEC1>:.actuator:0:int
#DbLog <SPEC1>:.desired-temp::
#DbLog <SPEC1>:.window::

plot "<IN>" using 1:2 axes x1y2 title 'Measured temperature' ls l0 lw 1 with lines,\
"<IN>" using 1:2 axes x1y1 title 'Actuator (%)' ls l1 lw 1 with lines,\
"<IN>" using 1:2 axes x1y2 title 'Desired Temperature' ls l2 lw 1 with steps,\
"<IN>" using 1:2 axes x1y1 title 'Window' ls l3 lw 1 with steps
</syntaxhighlight>

Des Weiteren ist zu beachten:

On-Off-Plots

EG_Bad:window:::$val=~s/(on|off)(\d*).*/$1eq"on"?1:0/eg

unter Berücksichtigung von dim-Werten:

EG_WoZi_Licht:value:::$val=~s/(on|off)(\d*).*/$1eq"on"?1:($1eq"dim"?$2*0.01:0)/eg

== Beispiel: Anlegen und Nutzung einer SQLite-Datenbank ==
Im folgenden wird eine lokale SQLite-Datenbank auf einen Ubuntu-System angelegt (nach Quelle: http://www.tatsch-it.de/fhem-dblog/)
<ol>
<li>''Installation von SQLite:''
<pre>sudo aptitude install sqlite3 libdbi-perl libdbd-sqlite3-perl

oder auf aktuellerem Stand

sudo apt install sqlite3</pre>
</li>
<li>''Anlegen der SQLite-Datenbank fhem.db'' (öffnet auch direkt eine SQL-Kommandozeile):
<pre>sudo sqlite3 /opt/fhem/fhem.db</pre>
In der geöffneten SQL-Kommandozeile eingeben:
<pre>
CREATE TABLE history (TIMESTAMP TIMESTAMP NOT NULL DEFAULT CURRENT_TIMESTAMP, DEVICE varchar(64), TYPE varchar(64), EVENT varchar(512), READING varchar(64), VALUE varchar(128), UNIT varchar(32));
CREATE TABLE current (TIMESTAMP TIMESTAMP, DEVICE varchar(64), TYPE varchar(64), EVENT varchar(512), READING varchar(64), VALUE varchar(128), UNIT varchar(32));
CREATE INDEX Search_Idx ON `history` (DEVICE, READING, TIMESTAMP);
</pre>
Die Kommandozeile verlässt man mit <code>.exit</code>.
</li>
<li>''Anpassen des Besitzers und der Rechte der Datenbank-Datei:''
<pre>
sudo chown fhem /opt/fhem/fhem.db
sudo chmod 600 /opt/fhem/fhem.db
</pre>
</li>
<li>''Datenbank-Anbindung des FHEM konfigurieren:''
<pre>sudo nano /opt/fhem/db.conf</pre>
Inhalt:
<pre>
%dbconfig= (
connection => "SQLite:dbname=/opt/fhem/fhem.db",
user => "",
password => ""
);
</pre>
</li>
<li>''Logging des FHEM auf die Datenbank konfigurieren:'' (hier sind nur die Anpassungen aufgeführt)
<pre>sudo nano /opt/fhem/fhem.cfg</pre>
<pre>
...
attr global userattr DbLogExclude ... # erlaubt es einzelne Einträge nicht zu loggen
...
define logdb DbLog ./db.conf .*:.* # logt alle(!) auflaufenden Events aller Konfigurationen
...
</pre>
Da durch diese <code>define</code>-Definition alle auflaufenden Events gelogt werden, müssen keine weiteren Anpassungen in der Konfiguration gemacht werden. Die FileLog-Einträge können bedenkenlos bestehen bleiben - dann wird in Datenbank und FileLog gelogt und man verliert keine Daten, falls etwas nicht klappt. Wenn alles wie geplant läuft, können die FileLog-Definitionen gelöscht werden (ebenso die Log-Dateien). Ebenso können die zu loggenden Daten später eingegrenzt werden (s. [[#Finetuning des Loggings]]).
</li>
<li>''FHEM neu starten:''
<pre>
sudo service fhem stop
sudo service fhem start
</pre>
</li>
<li>''Kontrollieren, ob Logs in die Datenbank geschrieben werden:''
<pre>sudo sqlite3 /opt/fhem/fhem.db</pre>
In der geöffneten SQL-Kommandozeile eingeben:
<pre>
select * from history order by TIMESTAMP; # dies gibt alle(!) Logs chronologisch aus (kann nach längerem Betrieb recht lange dauern)
</pre>
Die Kommandozeile verlässt man mit <code>.exit</code>.
</li>
<li>''Anpassung der glot-Dateien:'' siehe [[#Anpassen der gplot-Konfigurationen]]
</li>
</ol>

== Beispiel: Anlegen und Nutzung einer Mysql-Datenbank ==
Hierfür gibt es eine [[DbLog-MySQL|extra Seite]], die die Unterschiede und Feinheiten zwischen den verschiedenen Versionen berücksichtigt

Anstatt nano kann jeder andere kompatible Editor verwendet werden. Weiterhin bitte beachten, dass die hier genannten Befehle teilweise root-Rechte voraussetzen. Entweder komplett als root arbeiten, oder mittels sudo.

Unter Ubuntu/debian:
apt-get update && apt-get install mysql-server mariadb-client libdbd-mysql libdbd-mysql-perl

Bei der Installation sollte man aus Sicherheitsgründen ein Passwort für den mysql-root vergeben, wenn man nicht sogar ganz den Login verbietet.

Hinweis: im Folgenden ist "#" der normale Prompt und "mysql>" der prompt innerhalb mysql, dieser kann mit exit verlassen werden.

Eine erste Konfiguration von MariaDB / mySQL kann mit <pre>
# sudo mysql_secure_installation
</pre>vorgenommen werden.

Zum Test mal mit mysql verbinden:
# mysql -p -u root
Enter password:
mysql> exit

Jetzt die Tabellenstruktur anlegen.
Hierfür kann die Datei /opt/fhem/contrib/dblog/db_create_mysql.sql als Vorlage verwendet und das Passwort und der Benutzername geändert werden.
cd /opt/fhem/contrib/dblog/
nano db_create_mysql.sql
Dann wird die Datei eingelesen (root Passwort wird abgefragt):

# mysql -u root -p < db_create_mysql.sql

Jetzt kann man den Zugang testen:

# mysql -p -u <fhemuser>
Enter password: <fhempassword>
mysql> show databases;

Nun müsste eine Datenbank "fhem" angezeigt werden, die die Tabellen current und history enthält.

Nun in der Datei db.conf den mysql-Block auskommentieren und ebenfalls Benutzername, Passwort UND HOST anpassen. Leider ist hier nicht standardmäßig localhost eingestellt.
nano /opt/fhem/db.conf

Jetzt kann unter FHEM ein DbLog-Device angelegt werden (mit dem beispiel wird alles geloggt:
define logdb DbLog ./db.conf .*:.*
Als State muss ein "connected" angezeigt werden.

Ein rereadcfg in FHEM stellt sicher, dass die neue Konfiguration übernommen wird - ein Neustart ist nicht erforderlich.

Nun kann die Funktion noch einmal überprüft werden:
<syntaxhighlight lang="sql">
# mysql -u <fhemuser> -p
Enter password: <fhempassword>
mysql> use fhem;
Database changed
mysql> show tables;
+----------------+
| Tables_in_fhem |
+----------------+
| current |
| history |
+----------------+
2 rows in set (0,00 sec)
mysql> select * from history; # Achtung, kann sehr groß werden .... #
</syntaxhighlight>

Anscheinend gibt es bei der neuen Version MariaDB (im Gegensatz zu mysql) ein neues Anmeldeverfahren, so dass in der Datenbank selbst Veränderungen vorgenommen werden müssen, damit der Zugriff durch FHEM funktioniert: https://kofler.info/root-login-problem-mit-mariadb/

Die Daten im MySQL können auch für die längere Aufbewahrung partitioniert werden. Dabei wird pro Partition eine Datei erzeugt statt einer gemeinsamen Datei für alle Daten. Je nach Wunsch zum Beispiel partitioniert nach Jahr.
<syntaxhighlight lang="sql">
Alter table history PARTITION BY RANGE ( UNIX_TIMESTAMP(timestamp) ) (
PARTITION p0 VALUES LESS THAN ( UNIX_TIMESTAMP('2019-01-01 00:00:00') ),
PARTITION p1 VALUES LESS THAN ( UNIX_TIMESTAMP('2020-01-01 00:00:00') ),
PARTITION p2 VALUES LESS THAN ( UNIX_TIMESTAMP('2021-01-01 00:00:00') ),
PARTITION p3 VALUES LESS THAN ( UNIX_TIMESTAMP('2022-01-01 00:00:00') ),
PARTITION p4 VALUES LESS THAN ( UNIX_TIMESTAMP('2023-01-01 00:00:00') ),
PARTITION p5 VALUES LESS THAN ( UNIX_TIMESTAMP('2024-01-01 00:00:00') ),
PARTITION p6 VALUES LESS THAN ( UNIX_TIMESTAMP('2025-01-01 00:00:00') ),
PARTITION p7 VALUES LESS THAN (MAXVALUE) );
</syntaxhighlight>

== Beispiel: Abfragescript PHP/MySQL ==
Um eine schnelle Übersicht zu bekommen habe ich mir dieses Script geschrieben:
<syntaxhighlight lang="php">
<?php $pdo = new PDO('mysql:host=localhost;dbname=fhem', 'fhemuser', 'fhempasswort');
echo '<h2>Tabelle Current</h1> <table border="1">';
echo "<tr><th>Anzahl</th><th>Name</th><th>Readings</th></tr>";
$sql = "SELECT COUNT(*), DEVICE, GROUP_CONCAT(DISTINCT READING ORDER BY READING DESC SEPARATOR '</li><li>') FROM current GROUP BY DEVICE;"; foreach ($pdo->query($sql) as
$row) {
echo "<tr><td>" . $row[0] . "</td><td>" . $row[1] . "</td><td><ol><li>" . $row[2] . "</li></ol></td></tr>";
}
echo "</table>";

echo '<h2>Tabelle History</h1> <table border="1">';
echo "<tr><th>Anzahl</th><th>Name</th></tr>";
$sql = "SELECT COUNT(*), DEVICE FROM history GROUP BY DEVICE;"; foreach ($pdo->query($sql) as
$row) {
echo "<tr><td>" . $row[0] . "</td><td>" . $row[1] . "</td></tr>";
}
echo "</table>";
?>
</syntaxhighlight>

Bitte passt ''fhemuser'' und ''fhempasswort'' an. Das Ganze kommt dann nach <code>/var/www/html/fhemdb.php</code> und ist mit <code><nowiki><IP>/fhemdb.php</nowiki></code> aufrufbar. Wenn ihr den zweiten Block für die history Tabelle ausklammert oder entfernt, läuft das Script viel schneller ab - klar die history Tabelle ist meist randvoll.

== Integration von DBLog in eigene Module ==
=== Bereitstellung der UNITS ===
Mit der DbLog_splitFn kann der Modulautor selbst festlegen, wie die Events des Moduls in die Bestandteile Reading/Value/Unit zerlegt werden um ein korrektes Logging per DbLog zu gewährleisten.

Dazu muss der Modulautor in der [[DevelopmentModuleIntro#X_Initialize|Initialize-Funktion]] eine <code>DbLog_splitFn</code> bereitstellen:

<syntaxhighlight lang="perl">
sub X_Initialize($)
{
my ($hash) = @_;
...
$hash->{DbLog_splitFn} = "X_DbLog_splitFn";
}
</syntaxhighlight>

Die genaue Aufrufsyntax und Funktionweise einer DbLog_split-Funktion findet man [[DevelopmentModuleIntro#X_DbLog_split|hier]].

== Werte auslesen ==
Manchmal möchte man Daten aus den Logs abrufen ohne händisch in der Datenbank herumzuwühlen (s.u.). Dies ist insbesondere auch dann hilfreich, wenn man eigene Funktionen, Notifys oder spezielle Plots entwirft, bei denen man auf Logdaten zugreifen möchte.

Grundsätzlich beschrieben ist dies in der {{Link2CmdRef|Lang=de|Anker=DbLog}} und unterscheidet sich minimal (aber entscheidend) von der Struktur bei [[FileLog#Werte_auslesen|FileLogs]].

Hier ein paar Beispiele, was man damit anstellen kann:

* <code>get meineDB - - 2016-10-01 2016-10-03 meinSensor</code> alle Einträge des meinSensor vom 01.10.-03.10.2016
* <code>get meineDB - - 2016-10-01_08:00:00 2016-10-01_16:00:00 meinSensor</code> alle Einträge des meinSensor von 8-16 Uhr am 01.10.2016
* <code>get meineDB - - 2016-10-01_08:00:00 2016-10-01_16:00:00 meinSensor:temperature</code> nur die temperature Werte
* <code>{ ReadingsTimestamp("meinSensor","state","0") }</code> Timestamp des aktuellen state des meinSensor
* <code>{ OldTimestamp("meinSensor") }</code> Timestamp des letzten state des FHT_3a32
* <code>{ time_str2num(OldTimestamp("meinSensor")) }</code> Timestamp in Sekunden des letzten state des meinSensor
* ...

== Bearbeitung von Datenbank-Einträgen ==
{{Hinweis|Dieser Abschnitt soll lediglich eine kleine Einführung in die Datenbank-Bearbeitung liefern. Für vertiefende Informationen sollte man sich grundsätzlich mit SQL beschäftigen. Eine umfassende und gut verständliche Anleitung zu SQL bietet bspw. [http://www.w3schools.com/sql/default.asp w3schools].}}
Irgendwann wird der Fall eintreten, dass in der Datenbank Einträge drinstehen, die geändert oder gelöscht werden sollen (zB. fehlerhafte Sensor-Rückmeldungen, umbenannte Readings). In klassischen Log-Dateien würde man diese einfach bearbeiten und löschen/anpassen (wobei man aber tunlichst zuvor FHEM stoppt, um Datenfehler zu vermeiden). Eine Datenbank kann bearbeitet werden, ohne FHEM stoppen zu müssen.

Datenbanken kann man ohne weitere Hilfsmittel direkt von der Kommandozeile/Shell aus bearbeiten. Alternativ gibt es auch verschiedenste Tools (webbasiert oder als Applikation), die einen dabei unterstützen (Bsp. findet man u.a. [https://wiki.ubuntuusers.de/SQLite/#Grafische-Benutzeroberflaechen hier]). Für einfache Arbeiten reicht allerdings idR. Shell.

=== SQLite-Datenbanken ===
'''Öffnen der DB unter Linux:'''

(Es werden Schreibrechte benötigt,ohne kann man die DB zwar öffnen, aber nichts machen)
sudo sqlite3 fhem.db
Dadurch öffnet sich ein SQL-Konsole, auf der alle weiteren Befehle ausgeführt werden.

'''Schliessen der DB:'''

sqlite> .exit

'''Hilfe anzeigen:'''

sqlite> .help

'''Alle Tabellen anzeigen:'''

sqlite> .tables

'''Das Schema der DB anzeigen:'''

(vgl. oben [[DbLog#Datenbanken]] und [[DbLog#Beispiel: Anlegen und Nutzung einer SQLite-Datenbank]])

sqlite> .schema

'''Alle Eintäge anzeigen:'''

Die Einträge liegen alle in der Tabelle "History".

'''Ganz wichtig''' ist immer das ";" am Ende Zeile (bei allen Kommandos, die nicht mit einem "." anfangen). Wenn es vergessen wurde zeigt die Konsole solange neue Zeilen bis ein ";" eingegeben wird. So kann ein Befehl auch bequem über mehrere Zeilen geschrieben werden.

sqlite> select * from HISTORY;

Dies kann sehr lange dauern und kann ggf. mit <code>STRG-C</code> abgebrochen werden.

'''Alle Einträge eines Geräts anzeigen:'''

In <code>where</code>-Statements werden Strings in einfache Anführungsstriche gesetzt, Zahlen nicht.

sqlite> select * from HISTORY where DEVICE='Pollenflug';

'''Alle Einträge eines Readings eines Geräts anzeigen:'''

sqlite> select * from HISTORY where DEVICE='Pollenflug' and READING='Graeser';

'''Alle Einträge eines bestimmten Wertes eines Readings eines Geräts anzeigen:'''

sqlite> select * from HISTORY where DEVICE='Pollenflug' and READING='Graeser' and VALUE>1;

'''LÖSCHEN aller Einträge eines bestimmten Wertes eines Readings eines Geräts anzeigen:'''

'''Achtung:''' Löschen kann nicht rückgängig gemacht werden!! Also IMMER erst die entsprechenden SELECT-Statements solange verfeinern bis wirklich nur die gewünschten Einträge angezeigt werden. Dann das <code>select *</code> durch <code>delete</code> ersetzen.

sqlite> delete from HISTORY where DEVICE='Pollenflug' and READING='Graeser' and VALUE>1;

== Datenbank reparieren ==
Es kann immer wieder mal vorkommen, dass Datenbanken Fehler enthalten. Das muss im Alltag garnicht auffallen und auch nicht immer schlimm enden. Wenn man auf der SQL-Konsole aber bspw. eine Meldung <code>Error: database disk image is malformed</code> erhält, sollte man ein Reparatur vornehmen.

'''Hinweis:''' Ist ein DbRep-Device definiert, kann eine Reparatur einfach mit dem eingebauten Befehl '''set <name> repairSQlite''' ausgeführt werden.

=== SQLite-Datenbanken ===
Die folgenden Schritte beschreiben, wie man eine SQLite-DB reparieren kann (Quelle: [http://techblog.dorogin.com/2011/05/sqliteexception-database-disk-image-is.html]):

<ol>
<li>DB öffnen:
<pre>sudo sqlite3 fhem.db</pre>
</li>
<li>Integritäts-Check durchführen:
<pre>sqlite> pragma integrity_check;</pre>
Kommt hier ein "ok" ist die DB gesund. Ansonsten erscheint etwas wie
<pre>
*** in database main ***
On tree page 118786 cell 1: Rowid 75 out of order (previous was 816660)
On tree page 118786 cell 4: Rowid 815704 out of order (previous was 816727)
Corruption detected in cell 0 on page 118786
Multiple uses for byte 132 of page 118786
...
</pre>
</li>
<li>Datenbank-Dump erstellen (Export gesamten DB in die Datei "dump_all_20160516_1043.sql") und DB verlassen:
<pre>
sqlite> .mode insert
sqlite> .output dump_all_20160516_1043.sql
sqlite> .dump
sqlite> .exit
</pre>
</li>
<li>Neue Datenbank erstellen und den Dump einlesen, Integritäts-Check machen und verlassen:
<pre>sudo sqlite3 fhem-neu.db</pre>
<pre>
sqlite> .read dump_all_20160516_1043.sql
sqlite> pragma integrity_check;
ok
sqlite> .exit
</pre>
</li>
<li>Spätestens jetzt FHEM stoppen:
<pre>sudo service fhem stop</pre>
</li>
<li>Alte DB sichern und neue aktivieren:
<pre>
sudo mv fhem.db fhem.db.sv_20160516
sudo mv fhem-neu.db fhem.db
</pre>
</li>
<li>Kontrollieren, dass die neue DB die gleichen Rechte wie die alte DB hat (und ggf. korrigieren):
<pre>
~/fhem$ ls -lha
insgesamt 6,3G
drwxr-xr-x 12 fhem root 4,0K Mai 16 11:07 .
drwxr-xr-x 4 root root 4,0K Dez 25 17:50 ..
...
-rw-r--r-- 1 root root 1,4G Mai 16 11:04 fhem.db
-rw-r--r-- 1 fhem root 2,6G Mai 16 10:59 fhem.db.sv_20160516
...

~/fhem$ sudo chown fhem:root fhem.db

~/fhem$ ls -lha
insgesamt 6,3G
drwxr-xr-x 12 fhem root 4,0K Mai 16 11:07 .
drwxr-xr-x 4 root root 4,0K Dez 25 17:50 ..
...
-rw-r--r-- 1 fhem root 1,4G Mai 16 11:04 fhem.db
-rw-r--r-- 1 fhem root 2,6G Mai 16 10:59 fhem.db.sv_20160516
...
</pre>
</li>
<li>FHEM wieder starten (und natürlich kontrollieren):
<pre>sudo service fhem start</pre>
</li>
</ol>

=== Hinweise für sehr große Datenbanken ===
Wenn die SQLite-DB sehr groß wird, kann es sein, dass der oben beschriebene Weg nicht ohne manuelle Anpassungen funktioniert. Konkret war dies bei einem Nutzer für eine 15 GB große DB nicht möglich, der Prozess hat sich immer nach mehreren Stunden aufgehängt. Die Ursache liegt darin, dass ein Dump alle Daten in einer einzigen Transaktion einfügt. Das Problem kann man lösen, indem man den Dump in mehreren Transaktionen einfügt, also aufteilt. Konkret konnte eine 23GB große DB erfolgreich eingelesen und damit repariert werden, indem alle 10.000.000 Zeilen folgende 2 Zeilen eingefügt wurden:
<pre>BEGIN TRANSACTION;
COMMIT;
</pre>
* Hinweis 1: Mit dem Editor joe kann man unter Linux auch sehr große Dateien flüssig bearbeiten, das Springen zu hohen Zeilennumer dauert trotzdem.
* Hinweis 2: joe verwendet eine temporäre Kopie der Datei. Diese liegt per default unter /tmp. Der Ort kann aber auch durch <code>export TEMP=...</code> geändert werden. Falls also unter /tmp nicht Platz für eine Kopie des Datenbank-Dumps ist, sollte diese Variable vor dem Starten von joe entsprechend gesetzt werden.
* Hinweis 3: Beim Speichern legt joe im gleichen Verzeichnis eine Sicherungskopie an, d.h. im Verzeichnis des Datenbank-Dumps sollte weiterer Platz in Höhe der Dateigröße frei sein.
* Hinweis 4: Der reopen Mechanismus von DbLog kann verwendet werden, um eine manuelle Datenbankreparatur ohne Logunterbrechung durchzuführen (vor dem Wieder-Öffnen der DbLog Datei- und Verzeichnisrechte prüfen!). Damit kann man das harte Stoppen und Starten von FHEM in obiger Anleitung umgehen.
* Letzter Hinweis: Weiter gilt: bei großen DbLog-Datenbanken sollte man immer darüber nachdenken,
** Welche dieser Logdaten man wirklich braucht und im Zweifel per DbRep ausdünnen
** Zu einer echten Datenbank wie MySQL/MariaDB zu wechseln.

== Datenbank migrieren ==
Eine schöne Anleitung zur Migration von SQLite zu MySQL/MariaDB mit Hilfe von [[DbRep - Reporting und Management von DbLog-Datenbankinhalten|DbRep]] findet sich hier: [https://demaya.de/fhem-umzug-sqlite-mysql-mariadb/].

== Nützliche Codeschnipsel ==
Anbei ein paar nützliche Codeschnipsel rund um DbLog

=== Dateigrösse mitloggen ===
Da die Datenbank ins Unermessliche wachsen kann, empfiehlt es sich - je nach Speicherplatz - ab einer bestimmten Grösse tätig zu werden. Dazu muss diese Grösse allerdings ermittelt werden. Diese geschieht mittels des Userreadings, welches man vorteilshafterweise mit im DbLog-device anlegt:

<pre>attr myDbLog userReadings DbFileSize:reduceLogState.* { (split(' ',`du -m fhem.db`))[0] }</pre>

Mittels dieses Attributs wird die Grösse der .db-Datei immer nach dem Ausführen des ReduceLog in das Reading "DbFileSize" in ganzzahligen MByte abgelegt.

Basierend auf diesem Reading können dann weitere Aktionen, beispielsweise ein Plot, erstellt werden.

Die oben beschriebene Möglichkeit ist für SQLite verwendbar. Zur Ermittlung der DB-Größe andere DB-Typen (aber auch für SQLite nutzbar) kann wie [[DbRep_-_Reporting_und_Management_von_DbLog-Datenbankinhalten#Gr.C3.B6.C3.9Fe_der_FHEM-Datenbank_ermitteln | hier]] beschrieben vorgegangen werden.

== Performance-Optimierung ==
Auch eine Datenbank kann mit der Zeit langsamer werden. Dies hängt von mehreren Faktoren ab:
* Menge der gelogten Daten (zB. > 4-5 GB)
* Eingesetzte Hardware (zB. langsame SD-Karte vs. schnelle SSD)
* Eingesetztes Datenbanksystem (zB. SQLite, MySQL)
* Komplexität der Abfragen (zB. für aufwändige Graphen oder Berechnungen)

Diese Punkte sollen im folgenden diskutiert werden:

=== Komplexität der Abfragen ===
Dies ist kein Problem der Datenbank, sondern rein der Abfrage. Dem entsprechend muss die Optimierung auch in der Abfrage oder im Skript gesucht werden. Dies ist nicht Ziel dieses Abschnittes und wird hier nicht weiter behandelt.

=== Eingesetztes Datenbanksystem ===
Welches Datenbanksystem eingesetzt wird (zB. SQLite oder MySQL) hat auf die Performance der Datenbank gar keinen so großen Einfluss, wie vielleicht zuerst gedacht. Selbst SQLite kann problemlos Datenbanken mit etlichen GB Größe performant verarbeiten. Der Flaschenhals ist hier viel mehr die darunter liegende Hardware (s.u.).

Die Performance der Datenbank an sich, kann aber durch verschiedene Maßnahmen verbessert werden:
* Pflegemaßnahmen bzgl. der Daten
* '''Erstellung von Indizes'''

==== Menge der Daten und Pflegemaßnahmen bzgl. der Daten ====
Die Menge der geloggten Daten hat natürlich Einfluss auf die Geschwindigkeit von Abfragen - je mehr Daten vorhanden sind, desto mehr Daten müssen auch durchforstet werden um eine Abfrage zu bedienen. Die Reduzierung der geloggten Datenmenge hat also direkten Einfluss auf die Größe und damit auch die Geschwindigkeit der Datenbank. Die Menge der zu loggenden Daten lässt sich an zwei Stellen einschränken:
* bei der Definition jedes Devices (s. Kapitel oben)
* bei der Festlegung des FHEM-weiten Log-Levels (s. [[Loglevel]])

Die Menge der bereits geloggten Daten kann zB. mit Hilfe von [[DbRep - Reporting und Management von DbLog-Datenbankinhalten|DbRep]] verringert und optimiert werden, bspw.
* löschen unnötiger Daten
* vacuum der Datenbank

Insgesamt haben diese Maßnahmen aber nur einen eingeschränkten Effekt auf die Performance der DB. Deutlich effektiver ist die Erstellung eines Index (s.u.).

==== Erstellung von Indizes ====
Die Erstellung von Indizes hat mit Abstand den größten Einfluss auf die Performance einer Datenbank (auf unveränderter Hardware). Extrem zusammengefasst ist ein Index eine extrem optimiertes Nachschlageverzeichnis für einen bestimmten Typ Daten (ein Index wie im Buch halt). Eine wunderbare Einführung in Indizes bietet [[https://use-the-index-luke.com/de|https://use-the-index-luke.com]].

In FHEM sind Indizes sogar sehr einfach einzurichten da die Datenbank-Nutzung sehr stark vorgegeben ist. Nahezu jede Abfrage folgt dem Schema ''Device -> Reading -> Datum -> Wert''. Ein Index kann genau diese Abfrage bedienen und beschleunigen. Ein Index nur über die Devices wäre ein erster Schritt, brächte aber noch keinen großen Gewinn (wie um Link oben gut beschrieben). Über die gesamten ersten drei Schritte erstellt (Device -> Reading -> Datum) bringt der Index aber sofort eine deutliche Geschwindigkeitssteigerung.

Die Erstellung eines Index erfolgt direkt in der Datenbank (und nicht aus FHEM heraus), hier am Beispiel einer SQLite-DB:

Öffnen der DB:
<pre> sudo sqlite3 fhem.db </pre>

Erzeugen des Index auf der DB-Konsole (das Semikolon am Ende ist wichtig):
<pre> create index idx_device_reading_timestamp on history (device, reading, timestamp); </pre>

Verlassen der DB:
<pre> .exit </pre>

Einzig zu berücksichtigen ist, dass dieser Index die Datenbank um bis zu 1/3 vergrößert. Er kann aber bei Bedarf auch wieder entfernt werden. Bei meiner 15 GB SQLite-Datei (auf einem Mac Mini mit SSD) hat dies ca. 15 min gedauert (den FHEM hatte ich vorsichtshalber währenddessen deaktiviert).

Sollte jemand spezielle Berechnungen oder Skripte ausführen, die nach einem anderen Abfrage-Schema arbeiten, könnte man dafür spezialisierte zusätzliche Indizes erstellen. Das sollte aber dann mit dem Wissen des obigen Links erarbeitet werden, da dann etwas mehr Hintergrundwissen sehr hilfreich ist.

==== DB-Backup ====
Ein anderer Aspekt, der eigentlich nichts mit der Performance der DB zu tun hat, ist der Einfluss aufs Backup. Wird bspw. ein Systembackup per RSYNC gemacht, muss bei SQLite immer die komplette ggf. riesige Datei gesynct werden - bei MySQL würden nur die veränderten DB-Elemente gesynct. Dies soll hier nicht weiter vertieft werden, sollte aber bei einer Gesamtstrategie bedacht werden.

=== Eingesetzte Hardware ===
FHEM hat grundsätzlich sehr viele kleine Datenzugriffe, unabhängig davon ob FileLog oder DbLog eingesetzt wird. Deshalb ist der absolut größte Performance-Gewinn durch den Einsatz schneller Festplatten zu erreichen - ganz einfache Aussage: ''je schneller desto besser ;-)''. Konkret bietet eine SSD mit mind. 250MB/s Datenzugriff eine ordentliche Basis für jedes datengestützte System, wie den FHEM.

Wenn die Datenmenge größer und die Abfragen komplexer werden, müssen natürlich irgendwann auch die Prozessorleistung und der Arbeitsspeicher mit wachsen. Aber auch an einem Raspi wird eine SSD deutlich performanter sein, als eine einfache SD-Karte oder eine klassische rotierende Festplatte.

== Links ==
* [[Heizleistung_und_Gasverbrauch|Beispiel das DbLog-Daten für SVG-Plots verwendet]]
* [[SVG-Plots von FileLog auf DbLog umstellen]]
* Manchmal bereitet die Engine von mysql auf einem Raspberry Probleme: [https://forum.fhem.de/index.php/topic,131164.msg1253589.html#msg1253589|Link zum Forum]

[[Kategorie:Logging]]

FHEM User Interface Painter

2022-06-04T05:38:47Z

Caldir65: Hinweis auf FTUI-Version 2 eingefügt, da es mittlerweile eine V3 gibt...

[[Datei:FUIP_Symbolbild.png|mini|400px|FUIP in Aktion]]
Der '''FHEM User Interface Painter (FUIP)''' ist ein FHEM-Modul, mit dem man [[FHEM Tablet UI]] (FTUI) Seiten graphisch ("klickibunti") erstellen kann. D.h. man kann sich ein UI zusammenklicken, welches die Tablet UI Technik verwendet, aber ohne sich selbst unbedingt mit HTML und CSS herumschlagen zu müssen.
Hier ist ein kurzes Video, welches FUIP in Aktion zeigt:

[https://forum.fhem.de/index.php?action=dlattach;topic=85869.0;attach=98455 Einführungsvideo]

(Das Video zeigt nicht unbedingt den neusten Stand, aber es dürfte klar werden, wofür FUIP gut sein soll.)

== Installation und Upgrade in FHEM ==
Genau wie FTUI ist auch FUIP nicht automatisch Teil von FHEM. Es muss explizit installiert bzw. hinzugefügt werden. Die Installation funktioniert folgendermaßen:
* FUIP verwendet FTUI (v2.x - es gibt inzwischen auch eine FTUI v3.x). D.h. man sollte zuerst einmal FTUI installieren, falls noch nicht passiert. Wie das geht steht bei [[FHEM Tablet UI#Installation|FHEM Tablet UI]]. Dabei reicht der erste Schritt aus, da lediglich die FTUI-Dateien von FUIP benötigt werden.
* Dann das FUIP-Repository zum FHEM Update hinzufügen:
** <code>update add https://raw.githubusercontent.com/ThorstenPferdekaemper/FHEM-FUIP/master/controls_fuip.txt</code>
* Jetzt <code>update all fuip</code> machen.
* Warten, bis man ganz sicher ist, dass alles installiert ist. Das sieht man normalerweise an der Meldung <code>update finished, "shutdown restart" is needed to activate the changes.</code>. Das ganze kann etwas länger dauern, da FUIP aus einige Dateien besteht, von denen ein paar etwas größer sind.
* Jetzt erst <code>shutdown restart</code>.
* FUIP sollte jetzt installiert sein.

Zum Upgrade reicht ein <code>update</code>, wenn man FUIP wie oben beschrieben installiert hat. Will man nur den FUIP-Teil aktualisieren und nicht alles in FHEM, dann geht das mit <code>update all fuip</code>.

Falls es bei oder nach der Installation oder dem Upgrade Probleme gibt (welcher Art auch immer), sollten die folgenden Punkte geprüft werden:
* Wird das richtige Repository benutzt? Man kann das mit <code>update list</code> überprüfen. Wenn der Eintrag für fuip nicht genau so aussieht wie oben beschrieben, dann sollte er per <code>update delete</code> gelöscht werden und dann genau so eingetragen werden wie oben beschrieben.
* Ist der update-Prozess wirklich komplett durchgelaufen? Auch wenn es etwas länger dauert, muss man auf die Meldung <code>update finished, "shutdown restart" is needed to activate the changes.</code> warten, bevor man durchstartet. Im Zweifelsfall einfach noch einmal <code>update all fuip</code> machen und diesmal mehr Geduld haben.
* FHEM braucht Schreibrechte im Verzeichnis <fhem>/FHEM/lib/FUIP/config (<fhem> steht meistens für /opt/fhem) und allen enthaltenen Dateien. Auf Betriebssystemebene (Linux) kann man das mit <code>ls -ls</code> überprüfen. Meistens kann es mit folgendem Befehl repariert werden: <code>chown -R fhem:dialout /opt/fhem/FHEM/lib/FUIP/config</code>. (Dieser Punkt gilt nicht bzw. nicht genau so, wenn man die configDB benutzt.)
* Steht etwas verdächtiges im Logfile?

== Erste Schritte ==
Zuerst legt man ein "FUIP Device" an, also etwa <code>define ui FUIP</code>. Dieses Device meldet sich sozusagen als Webserver bei FHEM an (wie z.B. auch [[HTTPSRV]]), d.h. es erscheint im Menu oben links (über den Räumen) ein Link "ui". Beim Klick auf diesen Link generiert FUIP eine FTUI Übersichtsseite aus den Räumen im FHEM System. (Das kann ein bisschen dauern, wenn man viele Devices hat.) Nun kann man durch Verschieben und größer/kleiner-Ziehen der einzelnen Zellen bzw. durch Verschieben des Zelleninhalts die Gestaltung ändern. Außerdem kann man über das Zahnrad rechts oben in den Zellen neuen Inhalt hinzufügen, den bestehenden Inhalt ändern und vieles mehr.
Durch Klicken auf die Räume im Menu der Übersichtsseite werden einzelne Raum-Seiten generiert. Diese kann man ebenfalls entsprechend bearbeiten. Natürlich können auch eigene Seiten hinzugefügt werden. Wie das geht sieht man im Video, welches oben verlinkt ist.

Nachdem man die Seiten entsprechend bearbeitet hat sollte man ein <code>set ui save</code> machen. Ansonsten gehen die Änderungen beim nächsten FHEM-Neustart verloren. Ein normales <code>save config</code> reicht nicht aus und ist auch nicht notwendig.

Die folgenden detaillierten Informationen können zum Teil veraltet sein, da FUIP noch weitereintwickelt wird. Es sollten allerdings keine Funktionen verschwinden.

== Das Konfigurations-Popup ==
=== ...für Zellen ===
[[Datei:FUIP_KonfigZelle.png|mini|600px]]
Beim Klick auf das Zahnrad rechts oben in einer Zelle wird der Konfigurations-Dialog für diese Zelle geöffnet. Im Folgenden werden die Funktionen der einzelnen Elemente erklärt.
;Zur Seiten-Konfiguration: Damit kann man zum Konfig-Dialog für die ganze Seite wechseln.
;Zellen-Überschrift: Hier wird die Überschrift der Zelle festgelegt. Eine Zelle muss keine Überschrift haben. (Die Zahlen hinter der Überschrift in der Zelle selbst verschwinden, wenn man das Attribut ''locked'' setzt.)
;Neuer View: Hiermit fügt man einen neuen View, also neuen Inhalt, zu einer Zelle hinzu. Man wählt dann aus, welcher Art View angelegt werden soll und füllt die Details, wie z.B. das zugehörige Device. Der neue View wird an einer freien Stelle (falls möglich) in der Zelle eingefügt. Nach schließen des Konfig-Dialogs kann man den View dann per Drag&Drop geeignet positionieren.
;Neuer View (Device): Dies dient ebenfalls dazu, neue Views in die Zelle zu packen. Allerdings wählt man nicht die Art des Views aus, sondern die FHEM-Devices, die dargestellt werden sollen. Das System sucht dann jeweils einen geeigneten View aus. Bisher funktioniert das nur sehr eingeschränkt, hat aber den Vorteil, dass man gleich mehrere Devices auswählen kann.
;Abbrechen: Damit schließt man den Dialog ohne die Änderungen zu übernehmen.
;Details zum View: Hier klappt man die Details zum View aus und kann diese ändern. Was man damit genau machen kann kommt auf die Art des View an. Per Drag&Drop kann man auch die Reihenfolge der Views im Konfig-Dialog ändern. Das hat allerdings keinen Effekt auf die Positonierung bereits existierender Views in der Zelle.
;View löschen: Das löscht den View aus der Zelle. Wenn man den View eigentlich nicht löschen, sondern in einer anderen Zelle haben will, dann kann man ihn auch per Drag&Drop in die andere Zelle verschieben. Lässt man einen View in einer anderen Zelle "fallen", dann wird dieser automatisch der neuen Zelle zugeordnet.
;Übernehmen: Das schließt den Dialog und übernimmt die Änderungen. Dadurch kann man die Auswirkungen auf dem UI selbst sehen. Um die Änderungen allerdings den nächsten FHEM Neustart überleben zu lassen muss man noch ein <code>set ui save</code> machen.
;Auto-Anordnen: Hiermit kann man die einzelnen Views in der Zelle automatisch anordnen. Es kann momentan sein, dass dadurch Änderungen verloren gehen. D.h. dieser Button sollte nur benutzt werden, wenn man seit dem Öffnen des Dialogs keine Änderungen gemacht hat. Außerdem schließt der Button dan Dialog. FUIP ordnet die Views in der Reihenfolge an, in der sie im Konfig-Popup erscheinen. Das zugrunde liegende Layout ist sehr einfach gehalten und kann sich auch noch ändern. Diese Funktion ist vor Allem brauchbar für mehrere gleichartige Views in derselben Zelle, wie z.B. bei Menus.
;Neue Zelle: Legt eine neue (leere) Zelle auf der aktuellen Seite an. Der Konfig-Dialog wird dabei geschlossen und Änderungen gehen verloren.
;Zelle kopieren: Kopiert die aktuelle Zelle. Man muss eine Seite angeben, zu der die kopierte Zelle gehören soll. Das entsprechende Feld ist mit der aktuellen Seite vorbelegt. Falls man dies nicht ändert, wird einfach eine Kopie der Zelle auf derselben Seite erzeugt. Ansonsten wird die Zelle auf die angegebene Seite kopiert. Die Funktion schließt den Konfig-Dialog und Änderungen gehen verloren. Falls man eine andere Seite angegeben hat, wird zu dieser gewechselt.
;Zelle exportieren: Dies erlaubt die Definition der Zelle herunterzuladen und auf dem Client (also dem Rechner, auf dem der Browser läuft) zu speichern.
;Zelle importieren: Damit lädt man eine exportierte Zelle wieder hoch. FUIP erzeugt dann auf der aktuellen Seite eine neue Zelle mit dem entsprechenden Inhalt. Das funktioniert auch mit Zellen, die von einer anderen FUIP-Seite, einem anderen FUIP-Device oder von einer anderen FHEM-Installation kommen.
;Zelle löschen: Damit löscht man die aktuelle Zelle. Sie verschwindet dann von der aktuellen Seite.
;Toggle editOnly: Bei manchen Views ist es schwierig, sie mit der Maus "anzufassen", da sie sofort eine Aktion auslösen (z.B. bei Links). Mit "Toggle editOnly" wird eine graue "Schicht" über die Views gelegt. Dadurch weiß man besser, wo man den View anfassen kann und Mausklicks haben keine Wirkung mehr, außer Drag&Drop.

=== ...für Seiten ===
[[Datei:FUIP_SeitenKonfig.png|mini|600px]]
Drückt man im Konfig-Dialog für Zellen auf "Cell/Page" kommt man auf den Konfig-Dialog für ganze Seiten. Die Bedeutung der Einzelnen Elemente ist wie folgt.
;Zur Zellen-Konfiguration:Das bringt einen zurück zum Konfig-Dialog für Zellen.
;Seiten-Überschrift:Hier kann ein Titel für die Seite eingetragen werden. Das erscheint dann je nach Browser irgendwo oben. (Technisch ist es der Inhalt des <title> Tags in <head>.)
;Abbrechen:Damit schließt man den Dialog ohne die Änderungen zu übernehmen.
;Übernehmen: Das schließt den Dialog und übernimmt die Änderungen. Dadurch kann man die Auswirkungen auf dem UI selbst sehen. Um die Änderungen allerdings den nächsten FHEM Neustart überleben zu lassen muss man noch ein <code>set ui save</code> machen.
;Seite kopieren:Dadurch wird eine neue Seite angelegt, die so aussieht wie die aktuelle. Der Dialog wird dann geschlossen und automatisch zur neuen Seite gesprungen.
;Seite exportieren:Das ist dasselbe wie für Zellen, nur für die ganze aktuelle Seite.
;Seite importieren:Das ist im Prinzip auch wie für Zellen, nur dass eine neue Seite angelegt wird. Exportierte Zellen können nur als Zellen importiert werden und exportierte Seiten nur als Seiten.

== Das FUIP-Device ==
Wie in [[#Erste Schritte|Erste Schritte]] bereits beschrieben, muss man zur Verwendung von FUIP zuerst ein FUIP-Device anlegen. Alles, was man mit FUIP macht (bzw. was das System macht) passiert in Bezug auf ein FUIP-Device. Man kann auch jederzeit mehrere FUIP-Devices anlegen. Verschiedene Instanzen von FUIP stören sich nicht gegenseitig, man kann aber (z.B. in einem Menu) auf eine andere FUIP-Instanz verweisen (verlinken).

Das FUIP-Device hat die folgenden Eigenschaften.
=== Sets ===
Die folgenden set-Kommandos sind für den Benutzer gedacht. Es gibt noch weitere set-Kommandos, welche aber vor Allem für FUIP-interne Zwecke gedacht sind.
;save: Mit <code>set <name> save</code> wird der momentane Zustand der FUIP-Seiten zu diesem FUIP-Device gespeichert. Das betrifft nicht die Definition des FUIP-Device selbst (also auch nicht dessen Attribute). Diese müssen nach wie vor über <code>save</code> (also "Save config") gespeichert werden. Die FUIP-Seiten stehen in der Datei <fhem>/FHEM/lib/FUIP/config/FUIP_<name>.cfg. Dabei steht <fhem> in der Regel für /opt/fhem und <name> für den Namen des FUIP-Devices. Ohne ein <code>set <name> save</code> gehen alle Änderungen beim nächsten FHEM Restart verloren.
;load: Mit <code>set <name> load</code> stellt man den Zustand wieder her, der mit <code>set <name> save</code> gespeichert wurde. Das ist vor Allem dann nützlich, wenn man sich beim Bearbeiten der Seiten vertan hat. Ansonsten wird beim FHEM Start das "load" automatisch ausgeführt.
;pagedelete: Mit <code>set <name> pagedelete <page></code> wird die Seite <page> gelöscht. Das kann auch dazu genutzt werden, FUIP zum Neugenerieren einer Seite zu "zwingen", indem man die Seite nach dem Löschen einfach wieder aufruft. Auch das Löschen einer Seite geht ohne ein "save" verloren, d.h. die Seite ist dann nach einem FHEM Neustart wieder da.
;refreshBuffer: FUIP verwendet Informationen aus dem "eigentlichen" FHEM, wie z.B. die Liste aller Devices sowie bestimmte Readings, Internals und Attribute. Insbesondere bei "entferntem" FUIP, also bei Verwendung des Attributs ''fhemwebUrl'', kann die Ermittlung dieser Daten länger dauern. Daher wird praktisch alles durch FUIP zwischengespeichert ("gepuffert"). Wenn man nun neue Devices anlegt bzw. bestehende Devices ändert, dann bekommt das FUIP-Device davon unter Umständen nichts mit. In so einem Fall kann man mit <code>set <name> refreshBuffer</code> den Zwischenspeicher löschen, um FUIP dazu zu zwingen, die Informationen erneut zu ermitteln.

=== Gets ===
Alle Get-Kommandos sind nur für FUIP-interne Zwecke bestimmt.

=== Internals ===
;editOnly: Hier wird der "editOnly-Modus" gespeichert, der auf der Konfig-Oberfläche ein- und ausgeschaltet werden kann. Siehe auch [[#Das Konfigurations-Popup|Das Konfigurations-Popup]].

=== Readings ===
FUIP-Devices haben keine Readings.

=== Attribute ===
;baseHeight: Basishöhe einer Zelle, d.h. eine 1x1-Zelle ist ''baseHeight'' Pixel hoch. Standardwert ist 108.
;baseWidth: Basisbreite einer Zelle, d.h. eine 1x1-Zelle ist ''baseWidth'' Pixel breit. Standardwert ist 142. Diese Abmessungen beziehen sich nur auf die Zelle selbst, nicht auf den Zwischenraum zwischen zwei Zellen. Der Zwischenraum beträgt (horizontal und vertikal) 10 Pixel.
;pageWidth: Seitenbreite in Pixel. Wenn ''pageWidth'' nicht gesetzt ist (das ist der Default), dann wird die Seitenbreite nicht festgelegt. Sie ergibt sich dann aus ''baseWidth'' (d.h. die Breite einer 1er-Zelle) und der Anzahl der verwendeten Spalten plus die Breite der Zwischenräume. D.h. in der Regel muss man ''pageWidth'' nicht angeben.
:Die Angabe in ''pageWidth'' beeinflusst auch die Darstellung des Hintergrundbilds, falls das Attribut ''styleBackgroundImage'' gesetzt ist. Siehe ''styleBackgroundImage'' für Details.
;fhemwebUrl: Mit FUIP kann man sich auch an ein "entferntes" FHEM ankoppeln. Das Attribut ''fhemwebUrl'' hat dabei in etwa die Bedeutung wie ''fhemweb_url'' bei FTUI. (Siehe auch hier: [[FHEM Tablet UI#Verbindung zu FHEM|Verbindung zu FHEM (FTUI)]].) Genau wie beim "normalen" FTUI muss das Attribut ''CORS'' der FHEMWEB-Instanz des Ziels auf "1" stehen. Ansonsten würde schon FTUI nicht funktionieren. Außerdem darf die FHEMWEB-Instanz keine Passwort-Prüfung haben. Stattdessen kann man mit dem Attribut ''allowedfrom'' oder einer allowed-Instanz den Zugriff einschränken.
:Man darf ''fhemwebUrl'' auf keinen Fall setzen (auch nicht auf 127.0.0.1 oder so), wenn sich die FUIP-Instanz auf das lokale FHEM beziehen soll. In dem Fall würde FHEM ewig auf sich selbst warten.
:Wenn man ein "entferntes" FHEM benutzt, dann können einige Funktionen der Konfigurationsoberfläche etwas Zeit brauchen. Zum Beispiel müssen für die Eingabehilfe für Devices alle Devices aus dem entfernten FHEM gelesen werden. Das ist so implementiert, dass das entfernte FHEM möglichst wenig belastet wird, was aber zu Lasten des FUIP-FHEM geht. Siehe auch das Set-Kommando ''refreshBuffer'' zu diesem Thema.
;locked: Wenn ''locked'' auf "1" gesetzt wird, dann sind die FUIP-Seiten gegen Bearbeitung gesperrt. Das Zahnrad-Icon oben rechts erscheint dann nicht mehr. Dadurch kann ein reiner "Tablet-UI Benutzer" die Seiten nicht mehr ändern und die Oberfläche sieht komplett wie normalerweise bei FTUI aus. Zusätzlich verschwinden auch die Zellennummern rechts neben den Zellenüberschriften und Zellen ohne Überschrift haben dann auch keinen "Titelbalken" mehr.
;styleBackgroundImage: Dateiname des Hintergrundbilds. Die Bilddatei muss sich im Verzeichnis <fhem>/FHEM/lib/FUIP/images befinden. (<fhem> steht meistens für /opt/fhem) Unterstützt werden jpg- und png- Dateien. Nachdem eine neue Datei hochgeladen wurde, muss man im Browser (in FHEMWEB) die Seite einmal auffrischen (neu laden), um die neue Datei verwenden zu können.
:Falls das Attribut ''pageWidth'' gesetzt ist, dann wird die Breite des Hintergrundbilds auf die angegebene Größe gesetzt. Ansonsten (ohne ''pageWidth'') nimmt das Bild die Breite des Browser-Fensters ein. Die Höhe des Bilds wird entsprechend skaliert, man muss sich also selbst darum kümmern, dass das Bild ein passendes Seitenverhältnis hat.
:Bei Verwendung eines Hintergrundbilds werden die Zellenhintergründe automatisch auf halbtransparent gesetzt, so dass das Bild durchscheint.
;styleColor: Standard-Textfarbe (Vordergrundfarbe) für alle Views. Der Defaultwert ist #808080, also ein helles Grau. Man kann die Farbe nicht für alle FTUI-Widgets festlegen. D.h. ''styleColor'' funktioniert nicht unbedingt überall.

== Links ==
* {{Link2Forum|Topic=85869|LinkText=Foren-Thread zur Geburt von FUIP}}
* [https://www.youtube.com/watch?v=9DPrMOvZ1wo Youtube-Webinar von Thorsten]

[[Kategorie:FHEM Frontends]]

HM-LC-Sw4-SM 4fach Schaltaktor Aufputz

2022-03-11T17:21:44Z

Caldir65: Link zum Manual angepasst

== Features ==
* Funkfrequenz 868,3 MHz
* Typ. Freifeldreichweite: 300 m
* Spannungsversorgung: 230 V / 50 Hz
* Standby-Verbrauch: 0,5 W
* Schutzart: IP65
* Schutzklasse: II
* Gehäuse: PC, lichtgrau
* Relais: 4 Wechsler (potentialfreie Kontakte)
* Schaltvermögen: 16 A (ohmsche Last)
* Abm. (B x H x T): 171 x 55 x 121 mm

== Hinweise zum Betrieb mit FHEM ==

Das Pairing sollte wie unter HomeMatic Devices pairen beschrieben durchgeführt werden.
Das Gerät und seine 4 Kanäle werden vom Autodetect einwandfrei erkannt und initialisiert.

== Probleme ==

Bisher keine.

== FHEM Config-Auszug ==

<<< folgt >>>

== Event-Monitor ==

<<< folgt >>>

== Parameter-Liste ==

<<< folgt >>>

== FHEM Log-Auszug ==

<<< folgt >>>

== Links ==

https://www.eq-3.com/downloads/download/homematic/bda/hm-lc-sw4-sm-2_um_ge_eq-3_web.pdf

[[Kategorie:HomeMatic Components]]
[[Kategorie:Schalter (Empfänger)‏‎]]
[[Kategorie:868MHz]]

DbRep - Reporting und Management von DbLog-Datenbankinhalten

2021-01-01T19:11:46Z

Caldir65: Perl-Modul Time::HiRes bei Voraussetzungen doppelt vorhanden

{{Infobox Modul
|ModPurpose=Reporting und Management von DbLog-Datenbankinhalten
|ModType=h
|ModCmdRef=DbRep
|ModForumArea=Sonstiges
|ModTechName=93_DbRep.pm
|ModOwner=DS_Starter ({{Link2FU|16933|Forum}}/[[Benutzer Diskussion:DS Starter|Wiki]])}}

== Zweck und Einsatz des Moduls ==
Zweck des Moduls ist es, den Inhalt von [[DbLog]]-Datenbanken nach bestimmten Kriterien zu durchsuchen, zu managen, das Ergebnis hinsichtlich verschiedener Aggregationen auszuwerten und als Readings darzustellen. Die Abgrenzung der zu berücksichtigenden Datenbankinhalte erfolgt durch die Angabe von Device, Reading und die Zeitgrenzen für Auswertungsbeginn bzw. Auswertungsende.

Alle Datenbankoperationen werden nichtblockierend ausgeführt. Die Ausführungszeit der (SQL)-Hintergrundoperationen kann optional ebenfalls als Reading bereitgestellt werden (siehe Attribute).
Alle vorhandenen Readings werden vor einer neuen Operation gelöscht. Durch das Attribut "readingPreventFromDel" kann eine Komma separierte Liste von Readings angegeben werden die nicht gelöscht werden sollen.

'''Zur Zeit ist das Modul durch folgende Leistungsmerkmale gekennzeichnet:'''

* Selektion und Anzeige aller Datensätze innerhalb einstellbarer Zeitgrenzen.
* Darstellung der Datensätze einer Device/Reading-Kombination innerhalb einstellbarer Zeitgrenzen.
* Selektion der Datensätze unter Verwendung von dynamisch berechneter Zeitgrenzen zum Ausführungszeitpunkt.
* Dubletten-Hervorhebung bei Datensatzanzeige (fetchrows)
* Berechnung der Anzahl von Datensätzen einer Device/Reading-Kombination unter Berücksichtigung von Zeitgrenzen und verschiedenen Aggregationen.
* Die Berechnung von Summen-, Differenz-, Maximum-, Minimum- und Durchschnittswerten numerischer Readings in Zeitgrenzen und verschiedenen Aggregationen.
* Speichern von Summen-, Differenz- , Maximum- , Minimum- und Durchschnittswertberechnungen in der Datenbank
* Löschung von Datensätzen. Die Eingrenzung der Löschung kann durch Device und/oder Reading sowie fixer oder dynamisch berechneter Zeitgrenzen zum Ausführungszeitpunkt erfolgen.
* Export von Datensätzen in ein File im CSV-Format.
* Import von Datensätzen aus File im CSV-Format.
* Umbenennen von Device/Readings in Datenbanksätzen
* Änderung von gespeicherten Reading-Werten (VALUES) in der Datenbank (changeValue)
* automatisches Umbenennen (Autorename) von Device-Namen in Datenbanksätzen und DbRep-Definitionen nach FHEM "rename" Befehl (siehe [[#DbRep_Agent_-_automatisches_.C3.84ndern_von_Device-Namen_in_Datenbanken_und_DbRep-Definitionen_nach_FHEM_.22rename.22 | DbRep-Agent]])
* Ausführen von beliebigen benutzerspezifischen SQL-Kommandos
* Backups der FHEM-Datenbank im laufenden Betrieb erstellen (MySQL, SQLite) mit/ohne Komprimierung der Dumpfiles
* senden und versionieren Dumpfiles nach dem Backup an einen FTP-Server
* Restore von SQLite-Dumps und MySQL serverSide-Backups
* Optimierung der angeschlossenen Datenbank (optimizeTables, vacuum)
* Ausgabe der existierenden Datenbankprozesse (MySQL)
* leeren der current-Tabelle
* Auffüllen der current-Tabelle mit einem (einstellbaren) Extrakt der history-Tabelle
* Bereinigung sequentiell aufeinander folgender Datensätze (sequentielle Dublettenbereinigung)
* Reparatur einer korrupten SQLite Datenbank ("database disk image is malformed")
* Übertragung von Datensätzen aus der Quelldatenbank in eine andere (Standby) Datenbank (syncStandby)
* Reduktion der Anzahl von Datensätzen in der Datenbank (reduceLog)
* Löschen von doppelten Datensätzen (delDoublets)
* Löschen und (Wieder)anlegen der für DbLog und DbRep benötigten Indizes (index)

Zur Aktivierung der Funktion "Autorename" wird dem definierten DbRep-Device mit dem Attribut "role" die Rolle "Agent" zugewiesen. Die Standardrolle nach Definition ist "Client". Mehr ist dazu im Abschnitt [[#DbRep_Agent_-_automatisches_.C3.84ndern_von_Device-Namen_in_Datenbanken_und_DbRep-Definitionen_nach_FHEM_.22rename.22 | DbRep-Agent]] beschrieben.

DbRep stellt dem Nutzer einen UserExit zur Verfügung. Über diese Schnittstelle kann der Nutzer in Abhängigkeit von frei definierbaren Reading/Value-Kombinationen (Regex) eigenen Code zur Ausführung bringen. Diese Schnittstelle arbeitet unabhängig von einer Eventgenerierung. Weitere Informationen dazu ist unter [[#Attribute | Attribut]] "userExitFn" beschrieben.

FHEM-Forum:
{{Link2Forum|Topic=53584|Message=452567|LinkText=Modul 93_DbRep - Reporting und Management von Datenbankinhalten (DbLog)}}

== Voraussetzungen und Abgrenzungen ==
Das Modul setzt den Einsatz einer oder mehrerer DBLog-Instanzen voraus (bisher getestet mit PostgreSQL, MySQL und SQLite). Es werden die Zugangsdaten dieser Datenbankdefinition aus der Konfiguration des entsprechenden DbLog-Device genutzt.
Es werden nur Inhalte der Tabelle "history" berücksichtigt (Ausnahme Kommando "sqlCmd").

Überblick, welche anderen Perl-Module DbRep verwendet:

::POSIX
::Time::HiRes
::Time::Local
::Scalar::Util
::DBI
::Blocking (FHEM-Modul)
::Encode

== Definition ==
<pre>
define <name> DbRep <Name der DbLog-instanz>
</pre>

(*) '''<Name der DbLog-Instanz>:''' Es wird der Name der auszuwertenden DbLog-Datenbankdefinition angegeben, '''NICHT''' die Datenbank selbst.

Aus Performancegründen sollte der Index "Report_Idx" in der Datenbank (Tabelle history) angelegt sein. Ab der DbRep-Version 8.20.0 kann dieser Index, sowie die für DbLog benötigten Indizes, verwaltet werden.
Der Index "Report_Idx" wird einfach mit dem DbRep-Befehl:

<pre>
set <name> index recreate_Report_Idx
</pre>

auf der Datenbank angelegt. Ist er bereits vorhanden, wird er gelöscht und erneut angelegt.

== Set ==
Siehe {{Link2CmdRef|Lang=de|Anker=DbRepset}}

== Get ==
Siehe {{Link2CmdRef|Lang=de|Anker=DbRepget}}

== Attribute ==
Siehe {{Link2CmdRef|Lang=de|Anker=DbRepattr}}

== Readings ==
Siehe {{Link2CmdRef|Lang=de|Anker=DbRepreadings}}

== DbRep Agent - automatisches Ändern von Device-Namen in Datenbanken und DbRep-Definitionen nach FHEM "rename" ==

Mit dem Attribut "role" wird die Rolle des DbRep-Device festgelegt. Die Standardrolle ist "Client". Mit der Änderung der Rolle in "Agent" wird das Device veranlasst auf Umbenennungen von Geräten in der FHEM Installation zu reagieren.

Durch den DbRep-Agenten werden folgende Features aktiviert wenn ein Gerät in FHEM mit "rename" umbenannt wird:

* in der dem DbRep-Agenten zugeordneten Datenbank (Internal Database) wird nach Datensätzen mit dem alten Gerätenamen gesucht und dieser Gerätename in allen betroffenen Datensätzen in den neuen Namen geändert.

* in dem DbRep-Agenten zugeordneten DbLog-Device wird in der Definition das alte durch das umbenannte Device ersetzt. Dadurch erfolgt ein weiteres Logging des umbenannten Device in der Datenbank.

* in den existierenden DbRep-Definitionen vom Typ "Client" wird ein evtl. gesetztes Attribut "device = alter Devicename" in "device = neuer Devicename" geändert. Dadurch werden Auswertungsdefinitionen bei Geräteumbenennungen automatisch konsistent gehalten.

Mit der Änderung in einen Agenten sind folgende Restriktionen verbunden, die mit dem Setzen des Attributes "role = Agent" eingeschaltet und geprüft werden:

* es kann nur einen Agenten pro Datenbank in der FHEM-Installation geben. Ist mehr als eine Datenbank mit DbLog definiert, können ebenso viele DbRep-Agenten eingerichtet werden

* mit der Umwandlung in einen Agenten wird nur noch das Set-Komando "renameDevice" verfügbar sein sowie nur ein eingeschränkter Satz von DbRep-spezifischen Attributen zugelassen. Wird ein DbRep-Device vom bisherigen Typ "Client" in einen Agenten geändert, werden evtl. gesetzte und nun nicht mehr zugelassene Attribute glöscht.

Die Aktivitäten wie Datenbankänderungen bzw. Änderungen an anderen DbRep-Definitionen werden im Logfile mit verbose=3 protokolliert. Damit die renameDevice-Funktion bei großen Datenbanken nicht in ein timeout läuft, sollte das Attribut "timeout" entsprechend dimensioniert werden. Wie alle Datenbankoperationen des Moduls wird auch das Autorename nonblocking ausgeführt.

'''Beispiel''' für die Definition eines DbRep-Device als Agent:

<pre>
define Rep.Agent DbRep LogDB
attr Rep.Agent devStateIcon connected:10px-kreis-gelb .*disconnect:10px-kreis-rot .*done:10px-kreis-gruen
attr Rep.Agent icon security
attr Rep.Agent role Agent
attr Rep.Agent room DbLog
attr Rep.Agent showproctime 1
attr Rep.Agent stateFormat { ReadingsVal("$name","state", undef) eq "running" ? "renaming" : ReadingsVal("$name","state", undef). " » ProcTime: ".ReadingsVal("$name","sql_processing_time", undef)." sec"}
attr Rep.Agent timeout 86400
</pre>

== hilfreiche SQL Statements ==

In dieser Rubrik werden SQL-Statements zusammengetragen, die User für ihre Auswertungen hilfreich fanden und anderen Anwendern zur Verfügung stellen.

Im Folgenden wird MySQL auch stellvertretend für MariaDB verwendet.

Die Statements können mit dem Befehl:

set <DbRep> sqlCmd <SQL-Statement>

ausgeführt werden. Für die Anpassung der Ergebnisdarstellung ist das Attribut '''sqlResultFormat''' verfügbar.

'''Hinweis: '''
Die Statements sind durch den DbRep-Modulautor nicht in jedem Fall getestet und dem Anwender obliegt vor Anwendung der Statements eine Datenbanksicherung durchzuführen um im Fehlerfall diese wieder herstellen zu können.

 
=== Den ersten und den letzten Wert eines Zeitraums selektieren bzw. deren Differenz (MySQL) ===
Beispiel 1:

Den ersten und letzten Wert der durch die DB-Variablen bestimmten Parameter ausgegeben.

Verwendete DB-Variablen (@) : begin_time, end_time, device und reading
SET @begin_time='2020-06-02 12:30:00';SET @end_time='2020-06-02 18:00:00';
SET @device='shelly02';SET @reading='energy_0';

SELECT TIMESTAMP,READING,round(VALUE/1000,0) AS VALUE
FROM (
(SELECT TIMESTAMP,READING,VALUE FROM history WHERE DEVICE = @device AND READING = @reading AND TIMESTAMP >= @begin_time and TIMESTAMP <= @end_time ORDER BY TIMESTAMP LIMIT 1)
UNION ALL
(SELECT TIMESTAMP,READING,VALUE FROM history WHERE DEVICE = @device AND READING = @reading AND TIMESTAMP >= @begin_time and TIMESTAMP <= @end_time ORDER BY TIMESTAMP DESC LIMIT 1)
) AS X1;

+---------------------+----------+-------+
| TIMESTAMP | READING | VALUE |
+---------------------+----------+-------+
| 2020-06-02 12:31:01 | energy_0 | 69 |
| 2020-06-02 16:31:05 | energy_0 | 73 |
+---------------------+----------+-------+
Beispiel 2:

Berechnung der Differenz vom 1. Beispiel

Verwendete DB-Variablen (@) : begin_time, end_time, device und reading

Hierbei ist zu beachten, dass die einzelnen Selects vertauscht wurden um den TIMESTAMP des ersten Select zu bekommen.

Die Subtraktion wurde durch "mal Minus Eins" des kleineren Wertes erreicht.<pre>
SET @begin_time='2020-06-02 12:30:00';SET @end_time='2020-06-02 18:00:00';
SET @device='shelly02';SET @reading='energy_0';

SELECT TIMESTAMP,READING,round(sum(VALUE)/1000,0) AS VALUE
FROM (
(SELECT TIMESTAMP,READING,VALUE FROM history WHERE DEVICE = @device AND READING = @reading AND TIMESTAMP >= @begin_time and TIMESTAMP <= @end_time ORDER BY TIMESTAMP DESC LIMIT 1)
UNION ALL
(SELECT TIMESTAMP,READING,(VALUE * -1) AS VALUE FROM history WHERE DEVICE = @device AND READING = @reading AND TIMESTAMP >= @begin_time and TIMESTAMP <= @end_time ORDER BY TIMESTAMP LIMIT 1)
) AS X1;

+---------------------+----------+-------+
| TIMESTAMP | READING | VALUE |
+---------------------+----------+-------+
| 2020-06-02 16:31:05 | energy_0 | 4 |
+---------------------+----------+-------+
</pre>
Die Formatierung

<pre>
round(sum(VALUE)/1000,0) AS VALUE
</pre>

sollte eventuell angepasst werden, da diese natürlich zum zu erwartenden Ergebnis passen muss.

=== Temperaturdifferenz eines Pufferspeichers über die Zeit ermitteln (MySQL) ===
Beispiel 1:

Temperaturdifferenz des Pufferspeichers über die Zeit in Minuten

<nowiki>Referenz zum DBRep : set [device] sqlSpecial readingsDifferenceByTimeDelta</nowiki>

Verwendete DB-Variablen (@) : device und reading, diff und delta werden für Berechnungen benötigt und sind bei erneutem Aufruf zurück zu setzen

Anmerkungen:

- Der Zeitraum wird in diesem Beispiel als die letzten 24 Stunden festgelegt

- Die Zeitdifferenz für die Änderung steht in der Spalte DELTA in Minuten

- In FHEM wurde mit event-on-change-reading ins DBLog geschrieben

- Bei dieser Ausgabe kann man erkennen, dass die Temperaturänderung im Wärmespeicher oft sehr klein ist, was ja auch so gewollt ist

- Um 14:00 Uhr beginnt die Wärmepumpe das Warmwasser wieder aufzuheizen<pre>
SET @device='Heizung';SET @reading='hotWaterTemperature';
SET @diff=0;SET @delta=NULL;

SELECT t1.TIMESTAMP,t1.READING,t1.VALUE,t1.DIFF,t1.DELTA
FROM
(
SELECT TIMESTAMP,READING,VALUE,
if(@diff = 0,NULL, cast((VALUE-@diff) AS DECIMAL(3,1))) AS DIFF,
@diff:=VALUE AS curr_V,
TIMESTAMPDIFF(MINUTE,@delta,TIMESTAMP) AS DELTA,
@delta:=TIMESTAMP AS curr_T
FROM history
WHERE DEVICE = @device AND
READING = @reading AND
TIMESTAMP >= NOW() - INTERVAL 1 DAY
ORDER BY TIMESTAMP
) t1;
+---------------------+---------------------+-------+------+-------+
| TIMESTAMP | READING | VALUE | DIFF | DELTA |
+---------------------+---------------------+-------+------+-------+
| 2020-06-04 10:05:20 | hotWaterTemperature | 46.5 | NULL | NULL |
| 2020-06-04 10:35:31 | hotWaterTemperature | 46.4 | -0.1 | 30 |
| 2020-06-04 11:00:31 | hotWaterTemperature | 46.2 | -0.2 | 25 |
snip...
| 2020-06-04 13:50:42 | hotWaterTemperature | 44.5 | -1.0 | 5 |
| 2020-06-04 13:55:42 | hotWaterTemperature | 44.0 | -0.5 | 5 |
| 2020-06-04 14:00:42 | hotWaterTemperature | 43.9 | -0.1 | 5 |
| 2020-06-04 14:10:42 | hotWaterTemperature | 41.7 | -1.8 | 5 |
snip...
| 2020-06-04 14:51:05 | hotWaterTemperature | 51.3 | 0.1 | 5 |
| 2020-06-04 17:01:15 | hotWaterTemperature | 51.2 | -0.1 | 130 |
snip...
| 2020-06-04 22:10:30 | hotWaterTemperature | 50.5 | -0.2 | 5 |
snip...
| 2020-06-05 11:30:45 | hotWaterTemperature | 46.1 | -0.1 | 25 |
+---------------------+---------------------+-------+------+-------+

</pre>Beispiel 2:

Summieren der Temperaturdifferenz auf Stundenbasis

Verwendete DB-Variablen (@) : device und reading, diff und delta werden für Berechnungen benötigt und sind bei erneutem Aufruf zurück zu setzen

Anmerkungen:

- Der Zeitraum wird in diesem Beispiel als die letzten 24 Stunden festgelegt

- Die Zeitdifferenz wird bei diesem Beispiel nicht ausgegeben

- Alle Differenzen nach der Vollen Stunde werden der nächsten Stunde zugeschlagen

- In FHEM wurde mit event-on-change-reading ins DBLog geschrieben

- Um 14:00 Uhr beginnt die Wärmepumpe das Warmwasser wieder aufzuheizen

- Bei diesem Wärmespeicher sind Temperaturschwankungen im Bereich von Null Komma irgendwas, als Messwert recht ungenau, was im Beispiel 1 zu der Vielzahl an Messwerten geführt hat. Durch Beispiel 2 auf Stundenbasis lässt sich bereits mehr erkennen. Hier wäre der Wärmepumpeneinsatz um 14:00 Uhr mit dem Pumpenvorlauf (-1.8) und der Lauf der Zirkulationspumpe um 8:00 und 8:30 Uhr zu sehen, was den Wärmespeicher um 1,2 Grad abgekühlt hat.<pre>
SET @device='Heizung';SET @reading='hotWaterTemperature';
SET @diff=0;SET @delta=NULL;

SELECT xTIMESTAMP AS TIMESTAMP,READING,xVALUE AS VALUE,xDIFF AS DIFF
FROM
(SELECT DATE_FORMAT(DATE_ADD(t1.TIMESTAMP,INTERVAL (IF(MINUTE(t1.TIMESTAMP) > 0, 60, 0)-MINUTE(t1.TIMESTAMP)) MINUTE),'%Y-%m-%d %H:00:00') AS xTIMESTAMP,
t1.READING,
round(t1.VALUE) AS xVALUE,
sum(t1.DIFF) AS xDIFF,
sum(t1.DELTA) AS xDELTA
FROM
(SELECT TIMESTAMP,READING,VALUE,
if(@diff = 0,NULL, cast((VALUE-@diff) AS DECIMAL(3,1))) AS DIFF,
@diff:=VALUE AS curr_V,
TIMESTAMPDIFF(MINUTE,@delta,TIMESTAMP) AS DELTA,
@delta:=TIMESTAMP AS curr_T
FROM history
WHERE DEVICE = @device AND
READING = @reading AND
TIMESTAMP >= NOW() - INTERVAL 1 DAY
ORDER BY TIMESTAMP
) t1
GROUP BY xTIMESTAMP WITH ROLLUP) x1

WHERE xDELTA IS NOT NULL AND
xTIMESTAMP IS NOT NULL;
+---------------------+---------------------+-------+------+
| TIMESTAMP | READING | VALUE | DIFF |
+---------------------+---------------------+-------+------+
| 2020-06-04 12:00:00 | hotWaterTemperature | 46 | -0.1 |
| 2020-06-04 13:00:00 | hotWaterTemperature | 46 | -0.4 |
| 2020-06-04 14:00:00 | hotWaterTemperature | 44 | -1.8 |
| 2020-06-04 15:00:00 | hotWaterTemperature | 51 | 7.4 |
| 2020-06-04 18:00:00 | hotWaterTemperature | 51 | -0.1 |
snip...
| 2020-06-05 07:00:00 | hotWaterTemperature | 48 | -0.3 |
| 2020-06-05 08:00:00 | hotWaterTemperature | 48 | -0.2 |
| 2020-06-05 09:00:00 | hotWaterTemperature | 48 | -1.2 |
| 2020-06-05 10:00:00 | hotWaterTemperature | 47 | -0.3 |
snip...
+---------------------+---------------------+-------+------+
</pre>

=== Alle aktuellsten readings eines Device im letzten Tagesverlauf (MySQL) ===
Beispiel :

Verwendete DB-Variablen (@) : device

Anmerkungen:

- Der Zeitraum wird in diesem Beispiel als die letzten 24 Stunden festgelegt

- In FHEM wurde mit event-on-change-reading ins DBLog geschrieben, wodurch nicht alle readings immer zeitlich in der DB aufeinander folgen oder einige im Zeitraum mehrfach geschrieben wurden. Mit diesem Aufruf erscheinen immer die letzten Aktualisierungen.

- Sollten einige readings nicht erscheinen, so wurden diese vor dem Zeitraum letztmalig aktualisiert. Mit "INTERVAL [n] DAY könnten diese eventuell auch noch gefunden werden. Bitte hier die Laufzeit beachten!<pre>
SET @device = 'Heizung';

SELECT t1.TIMESTAMP,t1.DEVICE,t1.READING,t1.VALUE
FROM history t1
INNER JOIN
(select max(TIMESTAMP) AS TIMESTAMP,DEVICE,READING
from history
where DEVICE = @device and
TIMESTAMP > NOW() - INTERVAL 1 DAY
group by READING) x
ON x.TIMESTAMP = t1.TIMESTAMP AND
x.DEVICE = t1.DEVICE AND
x.READING = t1.READING;
</pre>

 
=== Device / Reading Daten in eine CSV-Datei exportieren (MySQL) ===

Grundsätzlich gibt es für diesen Zweck das eingebaute Set-Kommando '''exportToFile'''.

Eine weitere Möglichkeit ist die Verwendung von spezifischen Datenbankkommandos, die mit Set '''sqlCmd''' ausgeführt werden können.

Im Beispiel wird ein CSV File geschrieben, welches die Daten des Devices 'SMA_Energymeter' enthält.
Wichtig ist, nicht zur Trennung von SQL-Befehlen dienende Semikolons durch Verdopplung zu escapen (z.B. im String "...TERMINATED BY ';;'...").

<pre>
SET @TS = DATE_FORMAT(NOW(),'_%Y_%m_%d');

SET @FOLDER = '/volume1/ApplicationBackup/';
SET @PREFIX = 'export';
SET @EXT = '.csv';

SET @CMD = CONCAT(" SELECT *
FROM `fhemtest`.`history`
WHERE `DEVICE`='SMA_Energymeter' AND TIMESTAMP > DATE_SUB(CURRENT_DATE(),INTERVAL 1 DAY)
INTO OUTFILE '",@FOLDER,@PREFIX,@TS,@EXT,"'
FIELDS ENCLOSED BY '\"'
TERMINATED BY ';;'
ESCAPED BY '\"'","
LINES TERMINATED BY '\r\n';;
");

PREPARE statement FROM @CMD;

EXECUTE statement;
</pre>

'''Hinweis:''' der verwendete Datenbank-User benötigt das '''FILE''' Recht.

 

== Praxisbeispiele / Hinweise und Lösungsansätze für verschiedene Aufgaben ==
=== Definieren eines DbRep-Devices ===
[[Bild:DbRep_initialized.PNG|right|thumb|400px|]]

Das DbRep-Device wird bei der Definition mit der DbLog-Instanz verbunden, in deren angeschlossener Datenbank später die Auswertungen und Operationen stattfinden sollen. Es ist also nicht die Datenbank selbst, sondern das vorher definierte DbLog-Device anzugeben.
Die Definition erfolgt z.B. durch:

<pre>
define Rep.Energy DbRep LogDB #LogDB ist das zu verbindende DbLog-Device
</pre>

Bei der Definition werden die Zugangsdaten aus der DbLog-Instanz gelesen und das DbRep-Device mit der Datenbank verbunden. Nach der Definition ist der Status "initialized". Nach ca. 5 Sekunden wechselt er nach "connected" sofern die Verbindung zur Datenbank erfolgreich war. Zu welcher Datanbank das DbRep-Device sich verbunden hat, zeigt das ''Internal'' DATABASE.

Damit ist das DbRep-Device grundsätzlich einsatzbereit, aber noch nicht praxistauglich. Werden keine weiteren Eingrenzungen angegeben, kann mit dem so definierten Device mit dem Befehl

<pre>
set Rep.Energy countEntries
</pre>

die gesamte Anzahl der Datensätze in der Datenbank ermittelt werden.
Für eine weitere Verwendung sind weitere ''Attribute'' zu setzen.
Um die Funktionen von "Rep.Energy" nur auf z.B. Datensätze in der Datenbank anzuwenden die "STP_5000" im Feld "DEVICE" enthalten, wird das '''Attribut''':

<pre>
attr Rep.Energy device STP_5000
</pre>

gesetzt. Weitere Begrenzungen der gerätespezifischen Selektion erfolgt durch das '''Attribut''' "reading". So wird durch

<pre>
attr Rep.Energy reading etotal
</pre>

[[Bild:Rep_configured.PNG|right|thumb|300px|]]
festgelegt, dass sich die (allermeisten) Operationen auf die Kombination aus dem "device STP_5000" und dem "reading etotal" beziehen.
Eine zeitliche Eingrenzung der Ergebnisse erfolgt durch die '''Attribute''' "timeDiffToNow", "timeOlderThan", "timestamp_begin", "timestamp_end".
In dem Beispiel sollen sich die Selektionsergebnisse immer auf die letzten 120 Minuten beziehen.
Dazu wird das Attribut

<pre>
attr Rep.Energy timeDiffToNow 7200 #Der Wert für timeDiffToNow ist in Sekunden anzugeben
</pre>

gesetzt. Es wird dynamisch bei jeder Operation "<Selektionsbeginn> = <aktuelle Zeit> - 3600s" berechnet und die Datensätze bis zu <aktuelle Zeit> berücksichtigt.
Die gesamten Datenbankoperationen und teilweise auch Auswertungen von Selektionen erfolgt mit Blockingcall im Hintergrund. Der Timeout für die Operationen ist per Default auf 86400 Sekunden gesetzt. Über das ''Attribut'' "timeout" kann es den eigenen Bedingungen angepasst werden. In dem Beispiel wird timeout auf 300s geändert um auch bei sehr großen Selektionen und Auswertungen nicht in einen timeout zu laufen.

<pre>
attr Rep.Energy timeout 300
</pre>

Um auch die Verarbeitungszeiten im Hintergrund als Reading anzeigen zu lassen wird mit mit dem ''Attribut''

<pre>
attr Rep.Energy showproctime 1
</pre>

erreicht.
Mit diesen Einstellungen ist das Device für den konfiguriert und man kann sich zum Beispiel mit

<pre>
set Rep.Energy fetchrows
</pre>

die Datensätze mit der Gesamtenergierzeugung "etotal" des Wechselrichters "STP_5000" die in den letzten 2 Stunden in die DB geschrieben wurden.
Nachdem der Befehl in der Gerätedetailsicht ausgeführt wurde, wechselt der state im DeviceOverview auf "running". Sobald im DeviceOverview "done" angezeigt wird sieht man die Ergebnisse nach einem Browserrefresh.
Bei der Ausführung einer erneuten Operation werden alle Readings gelöscht. Sollen bestimmte Readings davon ausgenommen werden, kann dem ''Attribut'' eine kommaseparierte Liste von zu schützenden Readings übergeben werden.

Allgemein wird empfohlen sich für jede Aufgabe eine separates DbRep-Device anzulegen und entsprechend zu konfigurieren anstatt die Einstellungen ständig den neuen Aufgaben anzupassen.
Um den Prozess zu vereinfachen, kann das einmal angelegte Device für eine neue Selektionsaufgabe (zum Beispiel die Datensätze eines SMA Energymeters anzuzeigen bzw. auszuwerten) auf ein neues DbRep-Device kopiert

<pre>
copy Rep.Energy Rep.SMAMeter
</pre>

und entsprechend angepasst werden.

'''Hinweis zur Eventgenerierung:''' 
Je nach genutzter Funktion können sehr viele Readings als Ergebnis generiert werden. Zum Beispiel können mit "fetchrows", wobei jedes Reading einer selektierte Zeile aus der Datenbank entspricht, durchaus mehrere hundert Readings entstehen.
Sollte man nicht durch die Attribute "event-on-update-reading" bzw. "event-on-change-reading" die Eventerzeugung auf nur relevante Readings begrenzt haben, können in diesem Fall ebenso viele Events enstehen die das System entsprechend belasten können. 
Deswegen wird empfohlen die '''Eventerzeugung sofort''' auf z.B. "state" zu '''begrenzen'''.

 

=== Datensätze (Devices) von einer Datenbank in eine andere umziehen (Export/Import)===
==== Zweck ====

Oft ist es so, dass man zunächst eine DbLog-Datenbank anlegt um alle zu loggenden Events dort aufzuzeichnen. Mit zunehmender Größe bzw. mit dem Wunsch nach einer höheren Strukturierung werden weitere DbLog-Instanzen angelegt.
Die bereits geschriebenen Datensätze eines Gerätes müssen nun in eine andere Datenbank verlagert werden, weil das Device nunmehr in dieser Datenbank geloggt und ausgewertet werden soll.

Für das Beispielszenario gilt folgendes:

* Quelldatenbank aus der das Device entfernt werden soll ist "fhem" mit der DbLog-Instanz "LogDB"
* Zieldatenbank ist "fhemshort" mit der DbLog-Instanz "LogDBShort"
* das umzuziehende Device ist "MelderCP1"
* das definierte DbRep-Device ist "Rep.MelderCP1"

==== Vorbereitung ====

Zunächst wird ein DbRep-Device definiert (falls es noch nicht existiert) und für den Verwendungszweck vorbereitet (zur Definition siehe [[#Definieren_eines_DbRep-Devices | Definieren eines DbRep-Devices]]).

Das Attribut "reading" bzw. eventuell gesetzte Attribute zur Zeiteingrenzung werden gelöscht, damit alle Datensätze des Devices erfasst werden können.
Für den bevorstehenden Export wird mit dem Attribut "expimpFile" der (beschreibbare) Pfad und Dateiname festgelegt, hier im Beispiel ist es "/media/sf_Backup_FHEM/meldercp1.txt".

[[Datei:Rep_MelderCP1_count.PNG|right|thumb|200px|Anzahl Einträge von MelderCP1]]

Mit

<pre>
set Rep.MelderCP1 countEntries
</pre>

kann man sich nun einen Überblick verschaffen, wie viele Datensätze in der Quelldatenbank für "MelderCP1" enthalten sind und wie viele auch exportiert werden müssen. In dem Beispiel sind es, wie in dem Screenshot zu sehen, 1144 Datensätze.

Falls noch nicht geschehen, wird in der bisherigen DbLog-Definition das zu loggende Device entfernt und in der neuen DbLog-Definition aufgenommen, damit nun keine neuen Datensätze mehr für "MelderCP1" in die bisherige Datenbank geschrieben werden. Hierzu siehe die {{Link2CmdRef|Lang=de|Anker=DbLog}} zu DbLog.

==== Export ====
Nun werden die Datensätze des Devices "MelderCP1" mit dem folgenden set-Kommando in die Datei "/media/sf_Backup_FHEM/meldercp1.txt" exportiert.

<pre>
set Rep.MelderCP1 exportToFile
</pre>

Nach dem Export sollte natürlich im Reading von "Rep.MelderCP1" die gleiche Anzahl von exportierten Datensätzen ausgegeben werden wie vorher mit "countEntries" ermittelt wurde (siehe Screenshot).

[[Datei:Rep_MelderCP1_exported.PNG|right|thumb|300px|Anzahl exportierter Dataensätze]]

In der Export-Datei sind nun die Datensätze im CVS-Format enthalten.

Ein Ausschnitt:

<pre>
............
"2016-07-04 17:32:03","MelderCP1","FS20","on-old-for-timer 60","state","on-old-for-timer 60",""
"2016-07-05 07:47:50","MelderCP1","FS20","on-old-for-timer 60","state","on-old-for-timer 60",""
"2016-07-05 08:27:57","MelderCP1","FS20","on-old-for-timer 60","state","on-old-for-timer 60",""
"2016-07-05 08:28:25","MelderCP1","FS20","on-old-for-timer 60","state","on-old-for-timer 60",""
"2016-07-05 10:23:42","MelderCP1","FS20","on-old-for-timer 60","state","on-old-for-timer 60",""
"2016-07-05 10:27:35","MelderCP1","FS20","on-old-for-timer 60","state","on-old-for-timer 60",""
"2016-07-05 17:26:30","MelderCP1","FS20","on-old-for-timer 60","state","on-old-for-timer 60",""
"2016-07-06 07:46:31","MelderCP1","FS20","on-old-for-timer 60","state","on-old-for-timer 60",""
"2016-07-06 11:24:04","MelderCP1","FS20","on-old-for-timer 60","state","on-old-for-timer 60",""
"2016-07-06 11:25:43","MelderCP1","FS20","on-old-for-timer 60","state","on-old-for-timer 60",""
"2016-07-06 11:26:52","MelderCP1","FS20","on-old-for-timer 60","state","on-old-for-timer 60",""
...........
</pre>

In der bisherigen Datenbank "fhem" können die Datensätze nun gelöscht werden. Dazu versehen wir das DbRep-Device "Rep.MelderCP1" mit dem Attribut "allowDeletion" um die Löschfunktion des Moduls freizuschalten.
Nun werden die vorher exportierten Datensätze gelöscht mit:

[[Bild:Rep_MelderCP1_delrows.PNG|right|thumb|300px|Anzahl gelöschter Datensätze]]

<pre>
set Rep.MelderCP1 delEntries
</pre>

Auch jetzt ist wieder sicherzustellen dass in der Ausgabe der gelöschten Rows dieselbe Anzahl (1144) der exportierten Datensätze enthalten ist.

==== Import ====
Im nächsten Schritt werden die exportierten Daten in die neue Datenbank importiert. Dazu wird in unserem DbRep-Device "Rep.MelderCP1" zunächst das "allowDeletion"-Attribut sicherheitshalber gelöscht.
Zur Umstellung des DbRep-Devices auf die neue Datenbank wird die Definition von "Rep.MelderCP1" editiert und dort die neue DbLog-Instanz "LogDBShort" angegeben.

<pre>
modify Rep.MelderCP1 LogDBShort
</pre>

Nach einem kurzen Moment wird der state von "Rep.MelderCP1" sich wieder von "initialized" auf "connected" ändern sofern die Umstellung funktioniert hat. Mit einem Vergleichslauf durch
[[Datei:Rep_MelderCP1_Vergleichslauf.PNG|right|thumb|300px|Anzahl Einträge von MelderCP1 in neuer Datenbank nach Umstellung]]

<pre>
set Rep.MelderCP1 countEntries
</pre>

wird ersichtlich, dass sich in dieser Datenbank noch keine (oder vllt. bereits neu geloggte) Einträge von "MelderCP1" befinden.

Nun kann der Import erfolgen. Mit

<pre>
set Rep.MelderCP1 importFromFile
</pre>

werden die Daten aus der immer noch im Attribut "expimpFile" hinterlegten Datei "/media/sf_Backup_FHEM/meldercp1.txt" in die Datenbank "fhemshort" importiert. Dieser Vorgang wird als Transaktion ausgeführt. Es werden immer alle Daten oder, im Falle eines Fehlers, '''KEINE''' Daten importiert. Damit ist sichergestellt dass der Datenimport immer einen definierten Zustand hat. Sollte der Datenimport sehr umfangreiche Datensätze enthalten und somit schon absehbar sein dass der voreingestellte timeout-Wert von 86400 Sekunden nicht ausreichen wird, kann man vorsorglich das Attribut "timeout" höher setzen, z.B. auf das Doppelte).

Hier in dem Beispiel sind es lediglich 1144 Datensätze die sehr schnell importiert werden. Somit ist keine Anpassung des timeout-Parameters notwendig.
Auch nach dem Import wird wieder die Anzahl der verarbeiteten Dataensätze ausgegeben. Sie sollte natürlich ebenfalls mit den vorab ermittelten Zahlen der exportierten Datensätze übereinstimmen.

[[Datei:Rep_MelderCP1_importedrows.PNG|right|thumb|300px|Anzahl importierter Datensätze]]

==== Abschluss ====

Nach dem erfolgreichen Import sollte das Attribut "expimpFile" wieder entfernt werden damit man nicht versehentlich einen erneuten Import durchführt.
Das verwendete Rep.MelderCP1 kann nun wieder mit Zeitbegrenzungsattributen usw. versehen werden um die ursprüngliche Verwendung wieder herzustellen.

Die dargestellte Prozedur stellt einen Komplettumzug eines Devices dar, kann jedoch durch die Angabe der bekannten Attribute auch auf bestimmte Readings in der Datenbank oder Zeitgrenzen eingeschränkt werden. Dadurch würden nur bestimmte Datensätze exportiert und wieder importiert werden. Weiterhin sollte man daran denken die vorhandenen Auswertungsszenarien mit DbRep-Devices bzw. SVG-Diagrammen usw. auch auf die neue Datanbank umzustellen.

 
=== Inhalte einer primären Datenbank in eine andere Standby-Datenbank übertragen (syncStandby) ===

==== Zweck ====

Mit dem Export/Import Verfahren kann man, wie oben beschrieben, Daten zwischen verschiedenen Datenbanken austauschen. Mit dem Befehl "syncStandby" ist es aber mit relativ wenig Aufwand möglich, ein regelmäßig automatisch laufendes Übertragungsverfahren zwischen zwei Datenbanken zu etablieren.

Im vorliegenden Beispiel werden Datenbanken des gleichen Typs verwendet. Das Verfahren ist aber auch zwischen Datenbanken unterschiedlichen Typs anwendbar.

Anwendungsfälle dafür sind zum Beispiel:

* die Einrichtung eines Archivsystems
* die längerfristge Datenhaltung von Datensätzen eines bestimmten Devices/Readings in einer weiteren Datenbank um sie dort für umfangreiche Auswertungen zu nutzen (z.B. Daten einer PV-Anlage)
* Wechsel des Datenbanksystems, z.B. von SQLite zu MySQL/MariaDB
* säubern der Quelldaten von doppelten Datensätzen und nicht mehr benötigten Daten, Weiternutzung der aufgebauten Standbydatenbank als primäre Datenbank nach der Syncronisierung

Für das hier gezeigte Beispielszenario sollen Daten einer MariaDB-Quelldatenbank in einer andere MariaDB-Datenbank regelmäßig übertragen werden. Auf der Quelldatenbank werden die Daten aber nicht gelöscht, d.h. es entstehen zwei Datenbanken mit gleicher Datenbasis.

* Quelldatenbank ist eine MariaDB "fhemtest1" mit der DbLog-Instanz "LogDB1"
* Zieldatenbank ist eine MariaDB "fhemtest" mit der DbLog-Instanz "LogStby"

 

==== Die Quelldatenbank ====

Im vorliegenden Beispiel sind die Quelldatenbank und die Standby-Datenbank vom gleichen Typ MariaDB. Das Verfahren funktioniert ebenso zwischen Datenbanken unterschiedlichen Typs, also z.B. zur Übertragung von SQLite Daten in eine MariaDB.

Die Quelldatenbank ist im normalen Kontext die produktive FHEM-Logdatenbank. D.h. sie ist bereits eingerichtet und läuft mit einem entsprechenden DbLog-Device.
Die hier verwendete Quelldatenbank heißt "fhemtest1". Die Definition des dazu gehörenden DbLog-Devices "LogDB1" sei der Vollständigkeit halber hier erwähnt, wird aber natürlich bei jedem Nutzer individuell aussehen:

<pre>
define LogDB1 DbLog ./fhemtest1maria10.conf .*:(?!done).*
attr LogDB1 DbLogInclude CacheUsage
attr LogDB1 DbLogSelectionMode Exclude/Include
attr LogDB1 DbLogType History
attr LogDB1 addStateEvent 0
attr LogDB1 asyncMode 1
attr LogDB1 bulkInsert 1
attr LogDB1 cacheEvents 2
attr LogDB1 cacheLimit 2000
attr LogDB1 dbSchema fhemtest1
attr LogDB1 devStateIcon .*active:10px-kreis-gelb connected:10px-kreis-gruen .*disconnect:10px-kreis-rot
attr LogDB1 disable 0
attr LogDB1 room DbLog
attr LogDB1 showproctime 1
attr LogDB1 syncInterval 120
attr LogDB1 useCharfilter 1
attr LogDB1 verbose 2
</pre>

 

==== Die Standby Datenbank ====

Die Standby Datenbank ist das Synchronisationsziel.
Die Erstellung der Datenbank und die nachfolgende Definition des dazu gehörigen DbLog-Devices erfolgt weitgehend wie für eine "normale" Log-Datenbank wie in der Commandref beschrieben mit geringfügigen Anpassungen.

; 1. Anlegen der DB und Tabellen: wie in diesem [https://svn.fhem.de/trac/browser/trunk/fhem/contrib/dblog Link] hinterlegt, erfolgt die Erstellung mit den Befehlen für MySQL:
::: CREATE DATABASE `fhemtest` DEFAULT CHARACTER SET utf8 COLLATE utf8_bin;
::: CREATE USER 'fhemuser'@'%' IDENTIFIED BY 'fhempassword';
::: CREATE TABLE `fhemtest`.`history` (TIMESTAMP TIMESTAMP NOT NULL DEFAULT CURRENT_TIMESTAMP, DEVICE varchar(64), TYPE varchar(64), EVENT varchar(512), READING varchar(64), VALUE varchar(128), UNIT varchar(32));
::: ALTER TABLE `fhemtest`.`history` ADD PRIMARY KEY(TIMESTAMP, DEVICE, READING);
::: CREATE TABLE `fhemtest`.`current` (TIMESTAMP TIMESTAMP, DEVICE varchar(64), TYPE varchar(64), EVENT varchar(512), READING varchar(64), VALUE varchar(128), UNIT varchar(32));
::: GRANT SELECT, INSERT, DELETE, UPDATE ON `fhemtest`.* TO 'fhemuser'@'%';

Es wird zusätzlich zu der normalen Erstellung der history-Tabelle ein primary Key für die Tabelle erstellt. Dieser Key verhindert dass Duplikate in der Tabelle erstellt werden und erleichtert dadurch sehr das Verfahren der Datenübertragung in der Folge.

[[Datei:stb1.PNG|right|thumb|300px|DbLog-Device für Standby-Datenbank]]
; 2. Erstellung der Konfigurationsdatei und Definition des DbLog-Devices für die Standby-Datenbank: Die Konfigurationsdatei (mariastby.conf) beinhaltet die Verbindunginformationen für das DbLog-Device und wird genau wie in der DbLog-Commandref beschrieben angelegt. Das DbLog-Device für die Standby-Datenbank wird nur für die nachfolgende Definition des benötigten DbRep-Devices gebraucht und wird so definiert, dass keinerlei Events geloggt werden. Das kann auf verschiedenen Wegen erreicht werden. Im Beispiel wird der Regex im DEF entsprechend aufgebaut.
::: define LogStby DbLog ./mariastby.conf aaaaaa:bbbbbb
::: attr LogStby DbLogType History
::: attr LogStby asyncMode 1
::: attr LogStby bulkInsert 1
::: attr LogStby cacheEvents 2
::: attr LogStby devStateIcon .*active:10px-kreis-gelb connected:10px-kreis-gruen .*disconnect:10px-kreis-rot
::: attr LogStby disable 0
::: attr LogStby room DbLog
::: attr LogStby showNotifyTime 1
::: attr LogStby showproctime 1
::: attr LogStby syncEvents 1

Die Erstellung der current-Tabelle ist für den vorgesehenen Zweck eigentlich nicht nötig, wird der Vollständigkeit halber mit dokumentiert.
Ist das DbLog-Device definiert und erfolgreich verbunden, ist dessen state "connected".

 

==== Definition des DbRep-Devices zur Synchronisation Quell- und Standby-Datenbank ====

Es existieren nun das DbLog Device "LogDB1" für die produktive Quelldatenbank und das DbLog Device "LogStby" für die Standby-Datenbank.
Für die Synchronisation wird ein DbRep-Device erstellt, welches mit dem DbLog-Device der '''produktiven Quelldatenbank''', also LogDB1, verbunden wird.
Wie üblich, wird im DEF der Name des entsprechenden DbLog-Devices angegeben, hier "LogDB1".

<pre>
defmod Rep.LogDB1.syncStandby DbRep LogDB1
attr Rep.LogDB1.syncStandby aggregation no
attr Rep.LogDB1.syncStandby event-on-update-reading state
attr Rep.LogDB1.syncStandby fastStart 1
attr Rep.LogDB1.syncStandby role Client
attr Rep.LogDB1.syncStandby room DbLog
attr Rep.LogDB1.syncStandby showproctime 1
attr Rep.LogDB1.syncStandby stateFormat { (ReadingsVal($name,"state", ""))." : SQL-Zeit: ".(ReadingsVal($name,"sql_processing_time", "")) }
attr Rep.LogDB1.syncStandby timeDiffToNow d:6
attr Rep.LogDB1.syncStandby verbose 3
</pre>

Mit den verschiedenen möglichen Zeitattributen ('''time.*''') und den Attributen '''device''' und '''reading''' wird abgegrenzt, welche Datensätze in die Standby-Datenbak übertragen werden sollen. In dem vorliegenden Beispiel werden mit jedem Synchronisationslauf alle in der DB vorhandenen Datensätze, die nicht älter als 6 Tage Tage sind, in die Standby-Datenbank übertragen.

'''Hinweis:''' 
Würde man einen solchen Lauf z.B. alle 4 Stunden durchführen, würden viele doppelte Datensätze in der Datenbank entstehen. Der bei der Tabellenerstellung für die history-Tabelle angelegte primary Key verhindert das !
[[Datei:stb2.PNG|right|thumb|300px|syncStandby gestartet]]

Ein Synchronisationslauf wird nun gestartet mit:

<pre>
set <DbRep-Name> syncStandby <DbLog-Device Standby>
</pre>

In dem vorliegenden Beispiel ist das:

<pre>
set Rep.LogDB1.syncStandby syncStandby LogStby
</pre>

[[Datei:stb3.PNG|right|thumb|300px|syncStandby erfolgreich ausgeführt]]
Der Fortschritt der Datenübertragung sowie die evtl. eingefügten Datensätze (number of lines inserted) ist im Logfile mit verbose 3 ersichtlich:

<pre>
2020.01.24 17:12:41.186 3: DbRep Rep.LogDB1.syncStandby - total lines transfered to standby database: 6177
2020.01.24 17:12:46.411 3: DbRep Rep.LogDB1.syncStandby - total lines transfered to standby database: 23957
2020.01.24 17:12:51.710 3: DbRep Rep.LogDB1.syncStandby - total lines transfered to standby database: 24048
2020.01.24 17:12:57.733 3: DbRep Rep.LogDB1.syncStandby - total lines transfered to standby database: 24092
2020.01.24 17:13:03.505 3: DbRep Rep.LogDB1.syncStandby - total lines transfered to standby database: 24059
2020.01.24 17:13:08.891 3: DbRep Rep.LogDB1.syncStandby - total lines transfered to standby database: 23969
2020.01.24 17:13:13.420 3: DbRep Rep.LogDB1.syncStandby - total lines transfered to standby database: 17871
2020.01.24 17:13:13.421 3: DbRep Rep.LogDB1.syncStandby - number of lines inserted into "LogStby": 104
</pre>

[[Datei:stb4.PNG|right|thumb|300px|nur Daten der Devices SMA_Energymeter,MySTP_5000 werden übertragen]]
Nach dem erfolgreichen Sync-Lauf wird die benötigte Laufzeit und die Anzahl der übertragenen Datensätze in Readings angezeigt.

Mit dem Attribut '''aggragation''' wird gesteuert, in welchen '''Zeitscheiben''' die Selektion der Daten aus der Quelldatenbank und die Übertragung ausgeführt wird. Im Standard ohne gesetztes aggregation-Attribut ist es ein Tag. Stehen genügend Ressourcen zur Verfügung, kann dieser Wert auch auf "week" oder "month" gesetzt werden. Der Wert "hour" zur Verkleinerung des Datenpaketes ist ebenfalls möglich.

Bei jedem Lauf wird die Anzahl der eingefügten Datensätze im Reading '''number_lines_inserted_Standby''' angezeigt.

Die zu übertragenden Daten können natürlich sehr granular bestimmt werden. Sollen zum Beispiel nur die Daten der Devices SMA_Energymeter und MySTP_5000 übertragen werden, wird das Attribut '''device''' entsprechend gesetzt:

attr Rep.LogDB1.syncStandby SMA_Energymeter,MySTP_5000

Weiterhin bietet das Attribut '''reading''' eine Eingrenzung auf die gewünschten Readings und mit dem Attribut '''valueFilter''' kann eine Eingrenzung nur auf bestimmte vorkommende Werte vorgenommen werden.

Der Erfolg der Synchronisationsläufe kann sehr einfach mit einem separaten DbRep-Device (mit dem '''fetchrows''' Kommando) oder dem Tool phpMyAdmin (nebenstehend) überprüft werden.

 

==== regelmäßige Ausführung der Synchronisation ====

Ein einfaches AT kann dazu dienen den Synchronisationslauf mit dem Device '''Rep.LogDB1.syncStandby''' regelmäßig alle x-Stunden/Minuten auszuführen.

<pre>
define At.Sync.Stby at +*04:00:00 set Rep.LogDB1.syncStandby syncStandby LogStby
attr At.Sync.Stby room DbLog
</pre>

 

=== Ermittlung und Darstellung der täglichen Energieerzeugung eines Wechselrichters ===

Gegeben sei dass die Energiedaten eines Wechselrichters (STP_5000) mit SMAUtils in Verbindung mit SBFSpot in die Datenbank geschrieben werden.
Neben vielen anderen Werten liefert SMAUtils die Tageserzeugung in kWh als Reading "etoday". Der Wert dieses Readings wird alle paar Minuten in der Datenbank gespeichert.

Zur Auswertung wird ein DbRep-Device angelegt wie unter [[#Definieren_eines_DbRep-Devices | Definieren eines DbRep-Devices]]) beschrieben (z.B. Rep.etoday.STP_5000).

[[Datei:Rep.STP_5000.configured.PNG|right|thumb|300px|Rep.STP_5000 konfiguriert]]

Es soll die täglich erzeugte Energiemenge beginnend ab dem 01.10.2016 0 Uhr bis zum 13. Oktober angezeigt werden.

<pre>
attr Rep.etoday.STP_5000 timestamp_begin 2016-10-01 00:00:00
attr Rep.etoday.STP_5000 timestamp_end 2016-10-13 23:59:59
</pre>

Da es sich um eine tägliche Aggregation handelt (es soll pro Auswertung der Tag von 00:00:00 bis 23:59:59 betrachtet werden) und die Hintergrundverarbeitungszeit dargestellt werden soll, wird eingestellt:

<pre>
attr Rep.etoday.STP_5000 aggregation day
attr Rep.etoday.STP_5000 showproctime 1
</pre>

Die Eingrenzung der auszuwertenden Devices und der dazu gehörigen Readings wird durch die entsprechenden Attribute gewährleistet.
Es soll nur das Device "STP_5000" mit dem Reading "etoday" berücksichtigt werden. Dazu stellen wir ein:

<pre>
attr Rep.etoday.STP_5000 reading etoday
attr Rep.etoday.STP_5000 device STP_5000
</pre>

DbRep ist nun grundsätzlich zur Auswertung konfiguriert (siehe Screenshot).

Zur Selektion und Berechnung von numerischen Daten stehen die Funktionen average-, max-, min-, sum- und diffValue zur Verfügung.
Bei den in diesem Beispiel verwendeten Daten handelt es sich um einen täglich neu erzeugten und über 24 Stunden stetig steigenden Wert.
Demnach ist für diese Art Daten die Funktion "maxValue" geeignet. Sie gibt den maximalen Wert des Readings im eingestellten Aggregationszeitraum (day) aus.

[[Datei:Rep.STP_5000.max.PNG|right|thumb|300px|Rep.STP_5000 maxValue]]

Die Berechnung wird ausgeführt durch:

<pre>
set Rep.etoday.STP_5000 maxValue
</pre>

Danach kurzer Zeit ist die Berechnung erfolgt (state=done in DeviceOverview). Nach einem Browserrefresh in der Detailansicht sind die erzeugten Readings sichtbar.

Jedes Reading hat einen bestimmten Aufbau. Die Funktion "maxValue" erzeugt Readings folgenden Aufbaus.

<pre>
2016-10-07_18-19-03__STP_5000__etoday__MAX__2016-10-07
</pre>

Zunächst wird der Timestring "2016-10-07_18-19-03" ausgegeben der in diesem Kontext den höchsten (d.h. letzten) Wert von "etotal" an dem Tag markiert.
Bei dem Wechselrichter ist es damit auch der Zeitpunkt zu dem die Energieerzeugung eingestellt wurde (in dem Fall 07.10.2016 um 18:19:03).

'''Anmerkung:''' Die Notation des Timestrings wurde so gewählt, um die Regeln für in Readings erlaubte Zeichen einzuhalten. Wenn keine auswertbaren Daten vorliegen und berechnet werden konnten, werden Readings mit "-" ausgegeben. Im Beispiel sind es die Tagesaggregate 10.10.-13.10. da diese Tage in der Zukunft liegen.

Danach folgt im Reading die Angabe des Devices (STP_5000), des augewerteten Readings (etoday) und der Funktion die dieses Ergebnis ermittelt hat (MAX für maxValue).
Die letzte Angabe, hier "2016-10-07" definiert den Auswertungszeitraum. In dem Beispiel ist es der 07.10.2016. Würde die Berechnung mit aggregation=week durchgeführt werden, würde man als an dieser Stelle den Auswertungszeitraum "week_39" erhalten, also die Kalenderwoche 39.

Um die Auswertungsergebniss etwas benutzerfreundlicher zu gestalten, steht das Attribut "readingNameMap" zur Verfügung. [[Datei:Rep.STP_5000.max.namemap.PNG|right|thumb|300px|Rep.STP_5000 maxValue mit readingNameMap]]
Im Beispiel setzen wir es auf:

<pre>
attr Rep.etoday.STP_5000 readingNameMap Tageserzeugung_kWh
</pre>

Ein erneuter maxValue-Lauf erzeugt Readings des folgenden Aufbaus:

<pre>
2016-10-01_18-03-13__Tageserzeugung_kWh__2016-10-01 4.9870
</pre>

 

=== (regelmäßiges) Löschen von Datenbanksätzen ===

Dieses DbRep-Device dient dazu einmalig oder verbunden mit einem AT-Device Einträge aus einer Datenbank zu löschen.
Zunächst wird das Device wie im Abschnitt [[#Definieren_eines_DbRep-Devices | "Definieren eines DbRep-Devices"]] beschrieben definiert.
Dadurch wird das DbRep-Device mit einem DbLog-Device assoziiert und mit der Datenbank des DbLogs verbunden. Alle weiteren Operationen werden mit dieser Datenbank durchgeführt. In diesem Beispiel heißt das DbRep-Device "Rep.Del.DbShort" und das DbLog-Device "LogDBShort".

In diesem Beispiel sollen alle Datensätze gelöscht werden die älter als 180 Tage sind. Die Löschfunktion des Moduls ist standardmäßig ausgeschaltet und muß per Attribut enabled werden.
Dazu werden die Attribute [[Datei:Rep.Del.DbShort.PNG|right|thumb|300px|Rep.Del.DbShort konfiguriert]]

<pre>
attr Rep.Del.DbShort timeOlderThan d:180
attr Rep.Del.DbShort allowDeletion 1
</pre>

gesetzt. Die Zeitangabe erfolgt in Sekunden.

Insbesondere bei SQLite sollte während des Löschens kein paralleler Schreibprozess in Form des normalen Eventloggings stattfinden. MySQL/MariaDB kann es durchaus parallel verarbeiten. Um einen parallelen Zugriff durch DbLog-Loggging zu verhindern, kann das Logging vor der Löschung geschlossen und danach wieder geöffnet werden.
Dafür werden die Attribute mit z.B. diesen Werten gesetzt:

<pre>
attr Rep.Del.DbShort executeBeforeProc set LogDBShort reopen 7200
attr Rep.Del.DbShort executeAfterProc set LogDBShort reopen
</pre>

Dabei ist "LogDB" das mit dem DbRep-Device assoziierte DbLog-Device.

Der Löschvorgang wird mit

<pre>
set Rep.Del.DbShort delEntries
</pre>

gestartet. Nach Abschluß der Datenlöschung wird die Anzahl der deleted rows als Reading ausgegeben und auch im Log mit verbose=3 geschrieben.

Müssen sehr viele Datensätze gelöscht werden, könnte nach 86400 Sekunden der Standardtimeout erreicht werden und der Vorgang mit "error" enden.
In diesem Fall ist der timout mit dem Attribut:

<pre>
attr Rep.Del.DbShort timeout <timeout in Sekunden>
</pre>

entsprechend angepasst werden.

Ein fhem.cfg Eintrag für das beschriebene Beispieldevice sieht folgendermaßen aus:

<pre>
define Rep.Del.DbShort DbRep LogDBShort
attr Rep.Del.DbShort allowDeletion 1
attr Rep.Del.DbShort comment löschen aller Einträge in LogDBShort älter als 180 Tage
attr Rep.Del.DbShort devStateIcon connected:10px-kreis-gelb .*disconnect:10px-kreis-rot .*done:10px-kreis-gruen
attr Rep.Del.DbShort event-on-update-reading state
attr Rep.Del.DbShort room DbLog
attr Rep.Del.DbShort timeOlderThan 15552000
</pre>

Die Löschung der relevanten Datensätze kann weiterhin über Attribute "device" bzw. "reading" kann selektiv auf bestimmte Device- und/oder Readingloggings beschränkt werden. Wird keine Zeitbeschränkung (z.B. durch "timeOlderThan") vorgenommen, erfolgt die Löschung aller Datensätze der durch "device" bzw. "reading" spezifizierten Datenbankinhalte.

Als Argument der Attribute "device" bzw. "reading" kann SQL-Wildcard "%" verwendet werden.

<pre>
% substituiert ein oder mehrere Zeichen
_ Platzhalter für ein einzelnes Zeichen
</pre>

Beispiel:

<pre>
attr Rep.Del.DbShort device %5000
</pre>

Mit dieser Spezifikation werden alle Devices gelöscht die auf "5000" enden, also z.B. STP_5000 und MySTP_5000.
(siehe auch Attribut "reading" in der {{Link2CmdRef|Anker=DbRepattr|Lang=de|Label=Commandref}}).

Ein einfaches AT kann dazu dienen den Löschjob über das Device Rep.Del.DbShort regelmäßig alle x-Stunden/Minuten auszuführen. Dadurch werden nicht mehr benötigte Datenbankeinträge automatisiert und nicht FHEM blockierend im Hintergrund entfernt.

<pre>
define At.Del.DbShort at +*23:45:00 set Rep.Del.DbShort delEntries
attr At.Del.DbShort room DbLog
</pre>

==== erweiterte Anwendung von Selektionsbedingungen zur Löschung ====

Wie bei allen selektiven Funktionen im DbRep kann auch bei der Löschfunktion über die Attribute '''device''' und '''reading''' eine Beschränkung der zu löschenden Datensätze erfolgen. D.h. es werden nur Datensätze gelöscht, wenn die Selektionskriterien dieser Attribute erfüllt sind.

Im Attribut '''device''' können einzelne Geräte, Geräte-Spezifikationen ({{Link2CmdRef|Anker=devspec|Lang=de|Label=devspec}}) sowie Geräte mit Wildcards angegeben werden.
Ist eine devspec angegeben, werden die Devicenamen vor der Selektion aus der Geräte-Spezifikationen und den aktuell in FHEM vorhandenen Devices aufgelöst sofern möglich.
Wird dem Device bzw. der Device-Liste oder Geräte-Spezifikation ein "EXCLUDE=" vorangestellt, werden diese Devices von der Selektion und damit von dem Löschvorgang ausgeschlossen.

<pre>
attr <name> device TYPE=DbRep # es werden nur Datensätze der Geräte vom Modul-Typ "DbRep"
eingeschlossen
attr <name> device MySTP_5000 # nur Datensätze des Gerätes "MySTP_5000" werden selektiert/gelöscht
attr <name> device SMA.*,MySTP.* # Daten von Geräten die mit "SMA" oder "MySTP" beginnen, werden
selektiert/gelöscht
attr <name> device SMA_Energymeter,MySTP_5000 # nur Daten der beiden angegebenen Geräten werden selektiert/gelöscht
attr <name> device %5000 # Daten von Geräten die mit "5000" enden werden in die Operation
eingeschlossen
attr <name> device TYPE=SSCam EXCLUDE=SDS1_SVS # es werden Datensätze der Geräte vom Modul-Typ "SSCam" eingeschlossen,
aber das Gerät "SDS1_SVS" (auch vom Typ SSCam) wird ausgeschlosssen
attr <name> device EXCLUDE=SDS1_SVS # Datensätze aller Geräte mit Ausnahme des Gerätes "SDS1_SVS" werden
selektiert/gelöscht
attr <name> device EXCLUDE=TYPE=SSCam # Datensätze aller Geräte mit Ausnahme der Geräte vom Typ "SSCam" werden
selektiert/gelöscht
</pre>

Ähnlich erfolgt die Abgrenzung der DB-Selektionen auf ein bestimmtes oder mehrere Readings sowie exkludieren von Readings. Mehrere Readings werden als Komma separierte Liste angegeben. Es können SQL Wildcard (%) verwendet werden, aber '''keine Perl-Regex'''.
Wird dem Reading bzw. der Reading-Liste ein "EXCLUDE=" vorangestellt, werden diese Readings von der Selektion ausgeschlossen.

<pre>
attr <name> reading etotal # Datensätze mit dem Reading "etotal" werden eingeschlossen
attr <name> reading et% # Datensätze deren Reading mit "et" beginnt werden
eingeschlossen
attr <name> reading etotal,etoday # Datensätze mit den Readings "etotal" und "etoday" werden
in die Selektion eingeschlossen
attr <name> reading eto%,Einspeisung EXCLUDE=etoday # Datensätze mit Readings beginnend mit "eto" sowie das
Reading "Einspeisung" werden selektiert, aber das Reading
"etoday" wiederum ausgeschlossen
attr <name> reading etotal,etoday,Ein% EXCLUDE=%Wirkleistung # Datensätze mit Readings beginnend mit "Ein" sowie die
Readings "etotal" und "etoday" werden selektiert, wobei
Readings, die auf "Wirkleistung" enden, von der Löschung
ausgeschlossen werden
</pre>

Natürlich werden die Selektionsbedingungen durch eventuell gesetzte Zeiteingrenzungen mit den time*- Attributen ergänzt.
Die time*- Attribute sind mehrere im DbRep vorhandene Attribute, die alle mit "time" beginnen, z.B. timeOlderThan.

=== Auffinden von alten Devicenamen in der DB und versenden/loggen einer Negativliste ===

Wenn eine Datenbank längere Zeit gelaufen ist, Devices in FHEM hinzugefügt, geändert oder gelöscht wurden oder auch das DEF des DbLog-Devices angepasst wurde, befinden sich aller Wahrscheinlichkeit nach nicht mehr gewünschte/gebrauchte Datensätze von nicht mehr bestehenden Devices in der Datenbank.

Dieses Beispiel soll einen Weg zeigen, wie man mit Hilfe der DbRep-sqlCmd Funktion (ab Version 4.14.0) alle in der DB enthältenen Devicenamen ermitteln und mit einer Positivliste vergleichen kann.
Die Negativliste der nicht gewünschten Devices wird im Logfile ausgegeben bzw. mit TelegramBot versendet.

Zunächst wird das Device wieder wie im Abschnitt [[#Definieren_eines_DbRep-Devices | "Definieren eines DbRep-Devices"]] beschrieben definiert.
Dadurch wird das DbRep-Device mit einem DbLog-Device assoziiert und mit der Datenbank des DbLog-Device verbunden. In diesem Beispiel heißt das DbRep-Device "Report".

Nach der Definition setzen wir die Attribute:

<pre>
attr Report event-on-update-reading state
attr Report sqlResultFormat separated
</pre>

Es werden nun nur noch Events für "state" generiert. Das Attribut "sqlResultFormat = separated" bewirkt, dass das Ergebnis des SQL-Statements zeilenweise in Einzelreadings zur Verfügung gestellt wird.

Nun kann getestet werden, ob die Abfrage grundsätzlich funktioniert. Dazu wird das benutzerspezifische Kommando "sqlCmd" verwendet.

<pre>
set Report sqlCmd select device, count(*) from history group by DEVICE;
</pre>

Es sollte nun eine entsprechende Anzahl von Readings erzeugt werden (Browserrefresh), die als Wert eine Kombination aus <Device>|<Anzahl Datensätze in DB> enthalten wie im nebenstehenden Screenshot ersichtlich.

[[Datei:sqlCmd.PNG|right|thumb|300px|sqlCmd ausgeführt]]

Wenn das Ergebnis wie gewünscht vorliegt, wird nun die Benutzerschnittstelle aktiviert.

<pre>
attr Report userExitFn NaDevs .*:.*
</pre>

"NaDevs" ist die Funktion in 99_myUtils.pm die aufgerufen werden soll. Die Angabe des Regex ".*:.*" ist optional. Nähere Informationen zur Funktionsweise sind in der {{Link2CmdRef|Lang=de|Anker=DbRep}} zu finden.

Die "Positivliste" der in der Datenbank erlaubten Devices wird für das Beispiel in dem Attribut "comment" für den späteren Vergleich als String angegeben. Es ist natürlich auch z.B. eine Ableitung der im DEF-Regex des zugeordneten DbLog-Devices enthaltenen Device-Definitionen vorstellbar, sodass immer der aktuelle Stand dieser Definition als Grundlage für den Vergleich herangezogen wird.

<pre>
attr Report comment (sysmon|MyWetter|SMA_Energymeter|STP_5000|Cam.*)
</pre>

Somit werden die Devices "sysmon", "MyWetter", "SMA_Energymeter", "STP_5000" und alle Cam-Devices als in der DB erlaubt definiert.
Alle anderen gefundenen Devices sollen in einer Negativliste aufgeführt werden.

Im weiteren Schritt wird die aufzurufende Funktion in der vorhandenen 99_myUtils.pm ergänzt.

<syntaxhighlight lang="perl">
############################################################################
# $Id: myUtilsTemplate.pm 7570 2015-01-14 18:31:44Z rudolfkoenig $
#
# Save this file as 99_myUtils.pm, and create your own functions in the new
# file. They are then available in every Perl expression.

package main;

use strict;
use warnings;

sub
myUtils_Initialize($$)
{
my ($hash) = @_;
}

# Enter you functions below _this_ line.

my @dna;

...

######################################################
######## Not allowed Devs in DB ermitteln
######## UserExitFn in DbRep
######################################################
sub NaDevs {
my ($name,$reading,$value) = @_;
my $hash = $defs{$name};

# DB Namen ermitteln
my $dbconn = $hash->{dbloghash}{dbconn};
my $db = (split("=",(split(";",$dbconn))[0]))[1];

# Liste der erlaubten Devices aus Attribut "comment" lesen
my $adevs = AttrVal($name, "comment","-");

if($reading eq "state" && $value eq "running") {
# der Select wurde gestartet
Log3 $name, 1, "UserExitFn called by $name - new Select has been startet. Allowed devices in database are: $adevs";
@dna=();
return;
}

my $d = (split("\\|",$value))[0];

# das Selektionsergebnis bewerten und ggf. dem Ergebnisarray hinzufügen
if ( $reading =~ m/SqlResultRow.*/ && $d !~ m/$adevs/) {
push(@dna,$d."\n")
}

if ($reading eq "state" && $value eq "done") {
# Ergebnis versenden bzw. loggen
Log3 $name, 1, "UserExitFn called by $name - Devices not allowd found in $db: @dna";
fhem("set teleBot message Devices are not allowed found in $db: \n @dna");
}

return;
}

....
1;
</syntaxhighlight>

Die Schnittstelle übergibt der aufgerufenen Funktion den Namen des DbRep-Devices, den Namen des erstellten Readings und dessen Wert.
Der Aufruf erfolgt nach jeder Readingserstellung. Die Schnittstelle arbeitet OHNE Eventgenerierung bzw. benötigt keine Events.
Über den Namen des DbRep-Devices kann auf dessen Hash zugegriffen werden bzw. über $hash->{dbloghash}{...} ebenfalls auf den Hash des angeschlossenen DbLog-Devices.

In der Funktion "NaDevs" wird der Device-Teilstring des erzeugten Readings mit dem Wertevorrat aus dem "comment"-Attribut verglichen und bei einem negativen Ergebnis der Negativliste @dna hinzugefügt.

Nach Abschluss der Operation (signalisiert durch Reading "state = done") wird die erzeugte Liste im Logfile ausgegeben bzw. ein TelgramBot-Device versendet.

=== Größe der FHEM-Datenbank ermitteln ===

Zunächst wird das Device wie im Abschnitt [[#Definieren_eines_DbRep-Devices | "Definieren eines DbRep-Devices"]] beschrieben definiert.
Dadurch wird das DbRep-Device mit einem DbLog-Device assoziiert und mit der Datenbank des DbLogs verbunden. Alle weiteren Operationen werden mit dieser Datenbank durchgeführt. In diesem Beispiel heißt das DbRep-Device "Rep.Fhem.Size".

Um die Größe der Datenbank beziehungsweise der Tabellen "history" und "current" zu ermitteln steht das Kommando:
[[Datei:tableinfo.PNG|right|thumb|300px|get Rep.Fhem.Size tableinfo]]
<pre>
get Rep.Fhem.Size tableinfo (MySQL, PostgreSQL)
get Rep.Fhem.Size svrinfo (SQLite)
</pre>

zur Verfügung.

Mit diesem Befehl werden sehr viele Informationen bezüglich der Tabellen des FHEM-Schemas (MySQL) als Readings ausgegeben.

Um nur die relevanten bzw. interessierenden Selektionsergebnisse auszugeben, kann mit dem Attribut showTableInfo (MySQL, PostgreSQL) bzw. showSvrInfo (SQLite) eine kommaseparierte Liste der relevanten Tabellen angegeben werden.

<pre>
attr Rep.Fhem.Size showTableInfo %history%,%current% (MySQL, PostgreSQL)
</pre>

So wie in diesem Beispiel gesetzt, werden nur Informationen der Tabellen "history" und "current" ausgegeben.
Diese Ausgabe ich bereits recht übersichtlich, kann aber durch die Verwendung des Attributs suppressReading
weiter eingegrenzt werden.

Beispiele:

<pre>
attr Rep.Fhem.Size suppressReading ^(?!.*INFO_history.data_index_length_MB).*$
attr Rep.Fhem.Size suppressReading ^(?!.*(INFO_history.data_index_length_MB)|(state)).*$
attr Rep.Fhem.Size suppressReading ^(?!.*(INFO_history.data_index_length_MB)|(background_processing_time)|(state)).*$
</pre>

Mit diesen Attributwerten wird nur das Reading "INFO_history.data_index_length_MB" oder aber "INFO_history.data_index_length_MB"
und "state" bzw. "INFO_history.data_index_length_MB", "state" und "background_processing_time" dargestellt.

Die Datenbankgröße (MB) ist je nach DB-Typ in den Readings:

<pre>
INFO_current.data_index_lenth_MB
INFO_history.data_index_lenth_MB
SQLITE_FILE_SIZE_MB
</pre>

enhalten.

Wird z.B. über ein AT dieser Befehl regelmäßig durch Rep.Fhem.Size ausgeführt und die Ergebnisse wiederum in DbLog gespeichert kann die Größenentwicklung der Datenbank mittels SVG-Diagrammen dargestellt werden. [[Datei:tableinfo_SVG.PNG|left|thumb|300px|get Rep.Fhem.Size tableinfo]]

 
=== Readingwerte von DbRep in ein anderes Device übertragen ===

Um Readings aus DbRep in einen Dummy zu übertragen, können verschiedene Verfahren angewendet werden. Allen Verfahren ist gemeinsam, dass sie auf die Arbeitsweise der Funktionen von DbRep Rücksicht nehmen. Alle Funktionen von DbRep arbeiten, von Ausnahmen abgesehen, asynchron (non-blocking). Das hat den Vorteil, dass die Datenbankverarbeitungszeit bzw. eine Nichtverfügbarkeit der DB nicht hemmend auf FHEM wirkt, hat andererseits aber den Nachteil, dass die Ergebnisse einer Funktion nicht direkt nach dem Funktionsaufruf zur Verfügung stehen und somit nicht trivial innerhalb der FHEM-Hauptschleife weiterverarbeitet werden können.

 
==== Werte automatisch durch DbRep übertragen lassen (ab Version 8.40.0) ====

Ab DbRep Version 8.40.0 gibt es das Attribut '''autoForward''' mit dem eine integrierte Übertragung der DbRep-Ergebnissreadings in andere Devices (z.B. Dummy) eingerichtet werden kann. Diese Variante wird hier beschrieben.

Die weiteren manuellen Varianten werden in den nachfolgenden Abschnitten behandelt.

Um die integrierte Reading-Weiterleitung zu aktivieren wird des Attribut autoForward nach folgender Systematik gesetzt:
[[Datei:aforw1.PNG|right|thumb|300px|Übertragung aller Readings nach Dum.Rep.all]]
<pre>
{
"<source-reading> => "<destination device> [=> <destination-reading>]",
"<source-reading> => "<destination device> [=> <destination-reading>]",
...
}
</pre>
[[Datei:aforw2.PNG|right|thumb|300px|Übertragung Readings mit "SUM" nach Dum.Rep.Sum]]
In der Spezifikation von '''<source-reading>''' können Wildcards (.*) verwendet werden um nur eine Auswahl der erzeugten Readings an das Zieldevice '''<destination device>''' weiterzuleiten. Ist der optionale Zusatz '''<destination-reading>''' angegeben, erfolgt die Speicherung der übertragenen Readings im Zieldevice mit dem angegebenen Namen. 
Der angegebene Readingname muss den Regularien zur Namensgebung von Readings genügen. Eventuell vorhandene nicht erlaubte Zeichen werden durch "_" ersetzt.

Fehlt der Zusatz <destination-reading>, werden die in DbRep erzeugten Readings 1:1 in das Zieldevice übertragen.

'''Beispiel:'''

<pre>
attr DbRepDev autoForward {
".*" => "Dum.Rep.All",
".*AVGAM.*" => "Dum.Rep => average",
".*SUM.*" => "Dum.Rep.Sum => summary",
}
</pre>

Die Spezifikation erfüllt folgende Ziele:

# alle Readings werden zum Device "Dum.Rep.All" übertragen, der ursprüngliche Readingname bleibt im Ziel erhalten (Screenshot 1)
# Readings mit "AVGAM" im Namen werden zum Device "Dum.Rep" in das Reading "average" übertragen
# Readings mit "SUM" im Namen werden zum Device "Dum.Rep.Sum" in das Reading "summary" übertragen (Screenshot 2)

 
==== Werte mittels Event übetragen ====

Es sollen zum Beispiel die erzeugten Readings aus einem DbRep-Device in einen Dummy übetragen werden, die den Term "Grid" im Wortstamm tragen.

Ein Reading-Name der fetchrows-Funktion in DbRep ist immer nach folgendem Schema aufgebaut:

<Datum>_<Zeit>__<Unique-Index>__<Device>__<Reading>__<Dopplerindex>
z.B.: 2018-10-14_18-30-25__1__MyWetter__humidity

Datum und Zeit entsprechen dem Timestamp des gespeicherten Events in der Datenbank. Der Unique-Index identifiziert eventuell vorhandene Doubletten in der DB und der Dopplerindex ist ein Hilfsmittel, Datensätze die sich allein durch den Value-Wert unterscheiden, auch als unterschiedliche Readings erstellen zu können. Dieser Index wird nur bei Bedarf erstellt.

Im folgenden Beispiel werden alle erzeugten Readings mit "Grid" im Namen des DbRep-Devices "Rep.SMAEM" in den Dummy übertragen und heißen dann genauso. Zunächst wird der Dummy angelegt.

<pre>
define Dum.Rep dummy
attr Dum.Rep room DbLog
</pre>

Mit dem nachfolgend angelegten Notify wird auf die z.B. von fetchrows erzeugten Events reagiert, der Event entsprechend gesplittet und verarbeitet in den Dummy übertragen.

<pre>
define N.Dum.Rep notify Rep.SMAEM:(\d).*Grid.* { fhem "setreading Dum.Rep ".(split(":",$EVTPART0))[0]." $EVTPART1"}
attr N.Dum.Rep room DbLog
</pre>

Soll im Dummy ein Reading mit eigenem Namen gefüllt werden, sieht das Notify z.B. so aus:

<pre>
define N.Dum.Rep notify Rep.SMAEM:(\d).*Grid.* { fhem "setreading Dum.Rep DeinReading"." $EVTPART1"}
</pre>

==== Werte mittels Funktion DbReadingsVal übertragen ====

Sobald ein DbRep-Device definiert ist, wird die Funktion DbReadingsVal zur Verfügung gestellt. Mit dieser Funktion läßt sich, ähnlich dem allgemeinen ReadingsVal, der Wert eines Readings aus der Datenbank abrufen. Die Befehlssyntax ist:

DbReadingsVal("<name>","<device:reading>","<timestamp>","<default>")

Mit dieser Funktion kann ein Device/Reading-Wert aus der Datenbank gelesen und in einen Dummy gesetzt werden. "Name" ist dabei das abzufragende DbRep-Device.
Der Timestamp muss nicht genau bekannt sein. Es wird der zeitlich zu <timestamp> passendste Readingwert zurück geliefert, falls kein Wert exakt zu dem angegebenen Zeitpunkt geloggt wurde.
Um den aktuellsten in der Datenbank gespeicherten Wert eines Readings abzurufen, kann als Timestamp die aktuelle Zeit entsprechend formatiert verwendet werden.

Es soll z.B. der aktuellste Datenbankwert des Readings "etoday" vom Device "MySTP_5000" ausgelesen und im Dummy "Dum.Rep" als Reading "EnergyToday" gespeichert werden. Das beteilgte DbRep-Device heißt "Rep.Energy".

Für die Formatierung des aktuellen Timestamps kann die FHEM-Funktion FmtDateTime verwendet werden, welcher der aktuelle UNIX-Timestamp übergeben wird:

FmtDateTime(time)

Der Datenabruf aus der Datenbank sieht dann folgendermaßen aus:

DbReadingsVal("Rep.Energy","MySTP_5000:etoday",FmtDateTime(time),"")

Mit dem Befehl setreading kann der abgerufene Wert in dem Dummy-Device gespeichert werden:

{ fhem "setreading Dum.Rep EnergyToday ".DbReadingsVal("Rep.Energy","MySTP_5000:etoday",FmtDateTime(time),"") }

Damit der Datenabruf regelmäßig erfolgt und immer der aktuellste Wert von "etoday" in den Dummy eingtragen wird, kann dieses AT verwendet werden:

<pre>
define set.Dum.Rep_EnergyToday at +*00:01:00 { fhem "setreading Dum.Rep EnergyToday ".DbReadingsVal("Rep.Energy","MySTP_5000:etoday",FmtDateTime(time),"") }
</pre>

Somit erfogt eine Aktualisierung des Readings "EnergyToday" im Dummy "Dum.Rep" jede Minute.
Es ist zu beachten, dass die Funktionsausführung von DbReadingsVal blockierend erfolgt. Sollte die Datenbank nicht verfügbar sein oder lange Antwortzeiten besitzen, hat dies negative Auswirkungen auf FHEM, was sich in Blockierungszuständen äußert.
Möchte man solche eventuell möglichen Zustände vermeiden, kann die Befehlsausführung in die 99_myUtils unter Verwendung von [[Blocking_Call | Blocking Call]] ausgelagert werden.

Diese non-blocking Variante der Verwendung von DbReadingsVal wird nachfolgend skizziert.
In der 99_myUtils wird dazu der nachfolgende Code eingefügt, der drei kleine Subroutinen enthält:

<source lang="perl">
############################################################################################################
# DumRepEnergyToday (Reading mittels DbReadingsVal non-blocking setzen)
############################################################################################################
sub DumRepEnergyToday ($$$$$) {
# initiale Routine zum Aufruf von BlockingCall unter Berücksichtigung von "RUNNING_SET_READING"
my ($name,$device,$reading,$destdev,$destread) = @_;
my $hash = $defs{$name};

return if($hash->{HELPER}{RUNNING_SET_READING});
$hash->{HELPER}{RUNNING_SET_READING} = BlockingCall("DumRepEnergyTodayNbl", "$name|$device|$reading|$destdev|$destread", "DumRepEnergyTodayNblDone");

return;
}

sub DumRepEnergyTodayNbl($) {
# die eigentliche Routine in der die potentiell blockierende Funktion ausgeführt wird
my ($string) = @_;
my ($name,$device,$reading,$destdev,$destread) = split("\\|", $string);
my $hash = $defs{$name};

my $val = DbReadingsVal($name,"$device:$reading",FmtDateTime(time),"");
$val = encode_base64($val,"");

return "$name|$val|$destdev|$destread";
}

sub DumRepEnergyTodayNblDone($) {
# Rückkherfunktion zur Ergebnisauswertung und Löschen von "RUNNING_SET_READING"
my ($string) = @_;
my @a = split("\\|",$string);
my $hash = $defs{$a[0]};
my $name = $hash->{NAME};
my $val = decode_base64($a[1]);
my $destdev = $a[2];
my $destread = $a[3];

fhem "setreading $destdev $destread $val";
delete $hash->{HELPER}{RUNNING_SET_READING};

return;
}
</source>

Der oben gezeigte Code stellt die einfachste Form der BlockingCall-Implementierung dar. Weitere Informationen dazu sind im weiter oben angegebenen Link zum BlockingCall-Wiki enthalten.

Um non-blocking Funktion aufzurufen, ist das bereits beschriebene AT-Device wie folgt zu ändern:

<pre>
define set.Dum.Rep_EnergyTodayNbl at +*00:01:00 { DumRepEnergyToday("Rep.Energy","MySTP_5000","etoday","Dum.Rep","EnergyToday") }
</pre>

Der aufgerufenen Funktion "DumRepEnergyToday" werden hierbei der Name des abzufragenden DbRep-Devices, der Name des auszuwertenden Devices, der Name des auszuwertenden Readings sowie das Ziel-Device und das Ziel-Reading als Argumente mitgegeben. Dieser Aufruf kann dadurch universell zum Abruf und Setzen verschiedener auszuwertender Device/Reading-Kombinationen verwendet werden.

=== Ein Userreading anlegen und für stateformat verwenden ===

Eine Besonderheit beim Modul DbRep besteht darin, dass sich die Namen der generierten Readings ändern können. Dadurch kann man für die Erstellung eines eigenen Userreading nicht einfach den Namen eines erstellten Readings, z.B. in der Funktion ReadingsVal, verwenden um dessen Wert zu ermitteln.

Eine Möglichkeit besteht darin eine Funktion in 99_myUtils anzulegen und mit dem Attribut "userExitFn" diese Funktion zu aktivieren/zu verwenden.

Für das Beispiel soll ein Reading "power_max" für den erreichten Maximalwert im Monat und der Timestamp des Maximalwertes aus einem Beispielreading "2018-06-01_13-23-02__STP_5000__total_pac__MAX__no_aggregation" (Name kann sich durch das jeweilige Datum ändern) extrahiert werden.

Zunächst wird die Funktion "calcpomax" in 99_myUtils angelegt.

<source lang="perl">
############################################################################################################
######## power_max in DbRep erstellen
############################################################################################################
sub calcpomax {
my ($name,$reading,$value) = @_;
my $hash = $defs{$name};

if($reading =~ /^.*total_pac__MAX.*$/) {
$reading =~ /^(\d+)-(\d+)-(\d+)_(\d+)-(\d+)-(\d+)_.*$/;
my $pmts = "$3.$2.$1 $4:$5:$6";
my $fmtDateTime = FmtDateTime(gettimeofday());
setReadingsVal($hash,"power_max",$value,$fmtDateTime);
setReadingsVal($hash,"power_max_ts",$pmts,$fmtDateTime);
}
return;
}
</source>

Wie in der Commandref zu {{Link2CmdRef|Anker=DbRep|Lang=de|Label=DbRep}} zu lesen ist, werden der im Attribut "userExitFn" hinterlegten Funktion jeweils der Name des aufrufenden Devices, das Reading und dessen Wert übergeben. Mit ein paar Zeilen Code wird der übergebene Readingsname auf das Vorhandensein des statischen Namensteils (total_pac__MAX) geprüft und dementsprechend der Readingname "power_max" mit dem Wert angelegt, wenn der Regex auf den Readingnamen matched.
Gleiches gilt für das Reading "power_max_ts", welches den Zeitpunkt des erreichten Maximalwertes enthalten soll.

Die Aktivierung der Schnittstelle erfolgt im DbRep-Device mit

<pre>
attr <name> userExitFn calcpomax .*:.*
</pre>

Mit jedem Lauf von

<pre>
set <name> maxvalue
</pre>

wird nun das neue Reading mit angelegt und kann z.B. in einem stateformat verwendet werden:
[[Datei:Rep.powmax.PNG|right|thumb|500px|]]

<pre>
attr <name> stateformat
{
if(ReadingsVal($name,"power_max",0)) {
(ReadingsVal($name,"power_max",0)*1000)." Watt (erreicht am ".ReadingsVal($name,"power_max_ts","").")";
} else {
ReadingsVal($name,"state","done");
}
}
</pre>

Nachfolgend noch die Definition des verwendeten DbRep-Devices für diese Auswertung:

<pre>
defmod Rep.total_pac.currmonth DbRep LogDB
attr Rep.total_pac.currmonth aggregation no
attr Rep.total_pac.currmonth alias Peak WR-Leistung aktueller Monat
attr Rep.total_pac.currmonth allowDeletion 0
attr Rep.total_pac.currmonth devStateIcon connected:10px-kreis-gelb .*disconnect:10px-kreis-rot .*done:10px-kreis-gruen
attr Rep.total_pac.currmonth device STP_5000
attr Rep.total_pac.currmonth disable 0
attr Rep.total_pac.currmonth event-on-update-reading state
attr Rep.total_pac.currmonth group SMA Inverter
attr Rep.total_pac.currmonth reading total_pac
attr Rep.total_pac.currmonth room Energie
attr Rep.total_pac.currmonth showproctime 1
attr Rep.total_pac.currmonth stateFormat { \
if(ReadingsVal($name,"power_max",0)) {\
(ReadingsVal($name,"power_max",0)*1000)." Watt (erreicht am ".ReadingsVal($name,"power_max_ts","").")";;\
} else {\
ReadingsVal($name,"state","done");;\
}\
}
attr Rep.total_pac.currmonth timestamp_begin current_month_begin
attr Rep.total_pac.currmonth timestamp_end current_month_end
attr Rep.total_pac.currmonth userExitFn calcpomax .*:.*
attr Rep.total_pac.currmonth verbose 2
</pre>

 

=== datenbankgestützte Erstellung der Energiebilanz einer SMA PV-Anlage mit Überschußeinspeisung ===
[[datenbankgestützte Erstellung der Energiebilanz einer SMA PV-Anlage mit Überschußeinspeisung | Hier]] geht's zum Beitrag.

 
=== DbRep-Kommandos regelmäßig mit einem at-Device ausführen ===

Sollen DbRep-Kommandos regelmäßig zu bestimmten Zeiten bzw. Intervallen ausgeführt werden, kann ein at-Device (alternativ z.B. DOIF) dafür definiert und verwendet werden.

Als Beispiel soll die regelmäßige Ausführung des SQL-Statements

select device, count(*) from history group by DEVICE

über das Set-Kommando '''sqlCmd''' dienen.

Zunächst wird das DbRep-Device definiert welches zur Ausführung des Kommandos dienen soll.

<pre>
define Rep.LogDB.sqlResult DbRep LogDB
attr Rep.LogDB.sqlResult devStateIcon initialized:control_3dot_hor_s connected:10px-kreis-gelb .*disconnect:10px-kreis-rot .*done:10px-kreis-gruen
attr Rep.LogDB.sqlResult event-on-update-reading state
attr Rep.LogDB.sqlResult fastStart 1
attr Rep.LogDB.sqlResult room Datenbank
attr Rep.LogDB.sqlResult showproctime 1
attr Rep.LogDB.sqlResult sqlResultFormat table
attr Rep.LogDB.sqlResult verbose 2
</pre>

Die Definition Syntax wurde bereits weiter oben erläutert. Das Attribut '''sqlResultFormat''' legt fest in welcher Art und Weise das Ergebnis präsentiert werden soll. Auch andere Formate wie JSON sind implementiert.

Um das oben angegbene SQL-Statement zum Beispiel alle 6 Stunden 20 Minuten auszuführen, dient die folgende at-Definition:

<pre>
define At.LogDB.sqlResult at +*06:20:00 set Rep.LogDB.sqlResult sqlCmd select device, count(*) from history group by DEVICE
attr At.LogDB.sqlResult icon clock
attr At.LogDB.sqlResult room Datenbank->Produktiv
</pre>

Weitere Informationen sind in der [https://fhem.de/commandref_DE.html#at at-CommandRef] beschrieben.

Natürlich sind alle verfügbaren DbRep Set/Get-Befehle über diesen Weg ausführbar.
Es wird empfohlen das definierte DbRep-Device nur für Auswertungsaufgaben zu verwenden die eine gleiche Attributierung des Devices verlangen.
Für weitere Aufgaben sollten weitere DbRep-Devices definiert und entsprechend eingestellt werden.

 

=== Abarbeitung einer sequentiellen Befehlskette mittels non-blocking sqlCmd-Kommandos ===
Ein Vorteil von DbRep ist die nicht blockierende Arbeitsweise fast aller DbRep-Befehle (auf Ausnahmen wird in der Commandref hingewiesen).
Daraus ergibt sich aber auch das Merkmal, dass nach dem Funktionsaufruf nicht auf das Ergebnis gewartet wird und die FHEM-Schleife
unmittelbar nach dem Start des Befehls weiterläuft. Um mehrere voneinander abhängige Befehle, die eine festgelegte Reihenfolge erfüllen müssen, abzuarbeiten, kann die nachfolgend beschriebene Technik zur Kettenbildung angewendet werden. Diese Technik wird anhand einer einfachen Demo erläutert.

Das konstruierte Ziel der Kette ist folgendes:

* Es soll nacheinander der Insert eines Datensatzes durchgeführt, danach ein Select dieses Datensatzes, ein Update auf ein Feld und zuletzt ein delete dieses Datensatzes in dieser Reihenfolge ausgeführt werden

Demnach sich insgesamt vier SQL-Befehle nacheinander auszuführen (Insert, Select, Update, Delete).
Zunächst werden vier identische DbRep-Devices angelegt, die sich lediglich durch ihren Namen unterscheiden. Das wären die Devices:

<pre>
Rep.insert, Rep.select, Rep.update, Rep.delete
</pre>

Zur Anlage kann ein DbRep-Device als Vorlage erstellt und nachfolgend dreimal kopiert werden.

<pre>
define Rep.insert DbRep LogDB
attr Rep.insert allowDeletion 1
attr Rep.insert showproctime 1
attr Rep.insert userExitFn chain

copy Rep.insert Rep.select
copy Rep.insert Rep.update
copy Rep.insert Rep.delete
</pre>

Das wichtige Detail dieser Devices ist das gesetzte Attribut "userExitFn = chain". Dieses Attribut aktiviert eine Schnittstelle zum Aufruf von benutzereigenem Code nach dem Abschluß eines Datenbank-Calls (siehe Commandref).

Der benutzereigene Code wird nach folgendem Schema in die 99_myUtils.pm eingebaut:

<source lang="perl">
#############################################################################################
# sqlCmd Commandchain zur sequentiellen Abarbeitung von non-blocking DbRep-Befehlen
#
# genutzte werden vier DbRep-Devices: Rep.insert, Rep.select, Rep.update, Rep.delete
#
#############################################################################################
sub chain {
my ($name,$reading,$value) = @_;
my $hash = $defs{$name};
my $device = "Testdevice";
my $model = "Testmodel";
my $rc;

if ($name eq "Rep.insert" && $reading eq "chainstart") {
# Start der 1. Operation (insert)
CommandSet(undef,"Rep.insert sqlCmd insert into history (DEVICE, TYPE, EVENT, READING, VALUE, UNIT)
values (\"$device\", \"$model\", \"definition\", \"DEF\", \"Hugo\", \"Emma\")");
Log3 $name, 1, "$name - Start chain with insert";
return;
}

if($reading eq "state" && $value eq "done") {
if ($name eq "Rep.insert") {
# Auswertung der 1. Operation (insert)
$rc = ReadingsVal($name, "SqlResultRow_1", "");
Log3 $name, 1, "$name - number of inserts: $rc";

# Start der 2. Operation (select)
CommandSet(undef,"Rep.select sqlCmd select VALUE from history where device=\"$device\" and READING=\"DEF\" LIMIT 1;");
}

if ($name eq "Rep.select") {
# Auswertung der 2. Operation (select)
$rc = ReadingsVal($name, "SqlResultRow_1", "");
Log3 $name, 1, "$name - return of select: $rc";

# Start der 3. Operation (update)
CommandSet(undef,"Rep.update sqlCmd update history set UNIT=\"neu\" where DEVICE=\"$device\";");
}

if ($name eq "Rep.update") {
# Auswertung der 3. Operation (update)
$rc = ReadingsVal($name, "SqlResultRow_1", "");
Log3 $name, 1, "$name - number of updates: $rc";

# Start der 4. Operation (delete)
CommandSet(undef,"Rep.delete sqlCmd delete from history where device = \"$device\" and UNIT = \"neu\";");
}

if ($name eq "Rep.delete") {
# Auswertung der 4. Operation (delete)
$rc = ReadingsVal($name, "SqlResultRow_1", "");
Log3 $name, 1, "$name - number of deletes: $rc";
}
}

return;
}
</source>

Die gesamte Abarbeitung wird gestartet mit dem Aufruf:

<pre>
chain("Rep.insert", "chainstart")
</pre>

bzw. in der Kommandozeile im FHEMWEB mit:

<pre>
{chain("Rep.insert", "chainstart")}
</pre>

Nach dem initialen Aufruf des Insert wird die sub "chain" beendet und nach dem insert-Befehl durch das Device "Rep.insert" wieder aufgerufen. Dabei wird diese sub nach jedem erstellten Reading aufgerufen und dabei neben dem eigenen Devicenamen auch der Readingname sowie dessen Wert zur Auswertung übergeben.
Durch die if-Zweige wird bei jedem Durchlauf der richtige Entrypoint für den nachfolgenden Funktionsaufruf ermittelt und ausgeführt.

Nach der Abarbeitung aller vorgesehenen SQL-Statements ist die erfolgreiche Chainverkettung anhand der Ergebnisse im Logfile ersichtlich:

<pre>
2018.10.24 23:57:37.602 1: Rep.insert - Start chain with insert
2018.10.24 23:57:37.815 1: Rep.insert - number of inserts: 1
2018.10.24 23:57:37.901 1: Rep.select - return of select: Hugo
2018.10.24 23:57:38.033 1: Rep.update - number of updates: 1
2018.10.24 23:57:38.176 1: Rep.delete - number of deletes: 1
</pre>

=== Summe aller Einschaltzeiten eines Gerätes ===

[[Summe aller Einschaltzeiten eines Gerätes | Hier]] geht's zum Beitrag.

=== Welche Device/Reading-Kombinationen gibt es in der Datenbank ? ===
'''Hinweis:''' Im aktuellen DbRep-Release kann die nachfolgend beschriebene Auswertung alternativ durch die eingebauten Kommmandos:
set <DbRep-Device> sqlSpecial allDevCount
set <DbRep-Device> sqlSpecial allDevReadCount
ausgeführt werden.

Wenn eine Datenbank längere Zeit gelaufen ist und die zu loggenden Devices bzw. Readings immer mal wieder geändert wurden, wächst der Wunsch einen Überblick über die in der DB enthaltenen Devices/Reading-Kombinationen zu erhalten.
Dadurch können wiederum gezielt Auswertungen auf eine bestimmte Device/Reading-Kombination durchgeführt werden.

Um dieses Ziel zu erreichen, wird ein DbRep-Device erstellt welches für die Verwendung eines User-Command eingerichtet wird.
Je nach dem gewünschten Ergebnis wird eines der nachfolgenden SQL-Kommandos verwendet.

Selektion aller Device/Reading-Kombinationen in der Datenbank:
select device, reading, count(*) from history group by DEVICE, READING

Nur die geloggten Devices in der Datenbank reporten:
select device, count(*) from history group by DEVICE

Zur Einrichtung wird zunächst das DbRep-Device definiert:

define Rep.LogDB.sqlResult DbRep LogDB

Dabei ist "LogDB" '''nicht''' die Datenbank, sondern das DbLog-Device mit dem das DbRep-Device assoziiert und derüber mit der Datenbank verbunden wird !

Um die Ausgabe des späteren Ergebnisses zu formatieren wird das Attribut "sqlResultFormat" auf "table" gesetzt. Dadurch wird das Selektergebnis als Tabelle mit den Spalten Device, Reading und der Anzahl der enthaltenen Datensätze der jeweiligen Kombination erzeugt.

attr Rep.LogDB.sqlResult sqlResultFormat table

Natürlich kann auch ein anderes Ausgabeformat gewählt werden wenn gewünscht oder benötigt. Bei großen Ergebnismengen ist zur Erhöhung der Übersichtlichkeit das Attribut "sqlResultFormat = separated" wahrscheinlich eher geeignet.

Das Attribut stateFormat wird entsprechend gesetzt um nach einem erfolgten Selektionslauf die erzeugte Tabelle in der Raumansicht bzw. im DeviceOverview anzuzeigen:

<pre>
attr Rep.LogDB.sqlResult stateFormat { if (defined($defs{$name}{READINGS}{SqlResult})) {
ReadingsVal($name,"SqlResult",undef);
} else {
ReadingsVal($name,"state",undef);
}
}
</pre>

Damit ist das DbRep-Device vorbereitet und der Auswertungslauf kann gestartet werden mit:

set Rep.LogDB.sqlResult sqlCmd select device, reading, count(*) from history group by DEVICE, READING;

bzw. wenn nur die in der Datenbank enthaltenen Devices zu erhalten:

set Rep.LogDB.sqlResult sqlCmd select device, count(*) from history group by DEVICE;

[[Datei:sqlResult.PNG|right|thumb|600px|set Rep.LogDB.sqlResult sqlCmd select device, count(*) from history group by DEVICE;]]

Nebenstehender Screenshot zeigt das Ergebnis der Auswertung aller in der Datenbank enthalteten Devices und deren Anzahl von Datensätzen.

Zum leichteren Nachnutzung hier noch die Raw-Definition des fertigen DbRep-Devices:

<pre>
defmod Rep.LogDB.sqlResult DbRep LogDB
attr Rep.LogDB.sqlResult aggregation no
attr Rep.LogDB.sqlResult comment Device zum freien Report mit sqlCmd.\
- Auswahl von Statements -\
\
Device/Reading-Kombinationen in der Datenbank:\
select device, reading, count(*) from history group by DEVICE, READING\
\
geloggte Devices in der Datenbank:\
select device, count(*) from history group by DEVICE\

attr Rep.LogDB.sqlResult devStateIcon connected:10px-kreis-gelb .*disconnect:10px-kreis-rot .*done:10px-kreis-gruen
attr Rep.LogDB.sqlResult disable 0
attr Rep.LogDB.sqlResult event-on-update-reading state
attr Rep.LogDB.sqlResult group Datenbankauswertungen
attr Rep.LogDB.sqlResult room DbLog
attr Rep.LogDB.sqlResult showproctime 1
attr Rep.LogDB.sqlResult sqlResultFormat table
attr Rep.LogDB.sqlResult stateFormat { if (defined($defs{$name}{READINGS}{SqlResult})) {\
ReadingsVal($name,"SqlResult",undef);;\
} else {\
ReadingsVal($name,"state",undef);;\
} \
}
attr Rep.LogDB.sqlResult timeout 1000
attr Rep.LogDB.sqlResult verbose 2
</pre>

=== Die current-Tabelle mit einem Extrakt der history-Tabelle füllen (tableCurrentFillup) ===

Diese Funktion erweitert die Möglichkeiten der Verwendung der current-Tabelle des DbLog-Devices. In den meisten Fällen wird im DbLog das Attribut "DbLogType = Current/History" gesetzt sein um bei der Erstellung von SVG's entsprechende Vorschläge in der DropDown-Liste des Editors zur Verfügung zu haben.

Bei dieser Betriebsart werden in der current-Tabelle neu auftretende Events von Device/Reading-Kombinationen eingetragen, sofern sie noch nicht enthalten sind. Werden neue Geräte definiert, erscheinen deren Events in der current-Tabelle, auch wenn man später nicht benötigte Readings mit den Attributen "event-on-change-reading" oder "event-on-update-reading" ausgrenzt.
Die einmal gespeicherten Werte bleiben in der current Tabelle erhalten. Sicherlich wird deswegen der eine oder andere User den Inhalt der current Tabelle löschen um wieder eine leere und saubere current-Tabelle zu haben. Das führt dann natürlich dazu, dass nur die ab diesem Zeitpunkt auftretenden Events in der Vorschlagsliste aufgenommen werden und nur selten auftretende Device/Reading-Kombinationen erst nach längerer Zeit wieder in der Tabelle current gespeichert werden.

Darüber hinaus möchte man vielleicht nur für SVG-Diagramme relevante Device/Reading-Einträge in der Vorschagsliste vorfinden oder dort nur Einträge vorhalten, die in den letzten drei Monaten aufgetreten sind. Die Beweggründe können sehr vielfältig sein.
Um diesem Wunsch zu entsprechen, gibt es im DbRep die Funktion "set <DbRep-Device> tableCurrentFillup", die eng mit dem dem DbLog-Attribut "DbLogType = SampleFill/History" zusammenarbeitet.

Nachfolgend wird an einem Beispiel erläutert, welche Konfigurationen vorgenommen werden können, um aus der history-Tabelle alle vorhandenen Device/Reading-Kombinationen zu extrahieren und sie zur Verwendung als SVG-Vorschlagsliste in die current-Tabelle einzufügen.

Für das Beispiel wird folgendes angenommen:

* es gibt ein definiertes DbLog-Device "LogDB" welches in die Datenbank "fhem" loggt
* das DbRep-Device zur Ausführung der Funktion wird "Rep.FillCurr.fhem" genannt
* es sollen alle in der history-Tabelle vorkommenden Device/Reading-Kombinationen extrahiert und in die current-Tabelle eingetragen werden (Einschränkungen auf bestimmte Devices / Readings oder zeitliche Abgrenzungen werden nicht vorgenommen, aber es wird darauf hingewiesen, wie es gemacht werden kann)

==== a) Anlegen des DbRep-Devices ====

Die Definition des DbRep-Devices erfolgt unter Angabe des zu verbindenden DbLog-Devices (nicht der Datenbank selbst):

define Rep.FillCurr.fhem DbRep LogDB

In dem so definierten neuen Device sind die Attribute zu setzen, die für die beabsichtigte Funktion wichtig sind.
Da dieses Device auch für die Löschung der in der current-Tabelle gespeicherten Datensätze verwendet wird, muss das Attribut "allowDeletion = 1" gesetzt werden.

attr Rep.FillCurr.fhem allowDeletion 1

Ebenfalls wichtig ist die Erzeugung eines Events sobald der Löschvorgang der current-Tabelle abgeschlossen ist. Dazu wird im Beispiel "event-on-update-reading" verwendet:

attr Rep.FillCurr.fhem event-on-update-reading state,--DELETED_ROWS_CURRENT--

[[Datei:currdelete.PNG|right|thumb|300px|set Rep.FillCurr.fhem tableCurrentPurge]]
Für die Funktion nicht wichtig, aber durchaus interessant zu wissen wie lange die Laufzeit der Funktionen ist, wird noch das Attribut "showproctime = 1" gesetzt. Damit werden die Readings "background_processing_time" und "sql_processing_time" erzeugt welche die jeweilige Bearbeitungszeit in Sekunden darstellen.

attr Rep.FillCurr.fhem showproctime 1

Mit dem so vorbereiteten Device können schon die Funktionen "tableCurrentPurge" und "tableCurrentFillup" manuell getestet werden. Mit dem Kommando:

set Rep.FillCurr.fhem tableCurrentPurge

wird der gesamte aktuelle Inhalt der current-Tabelle gelöscht. Wie im nebenstehenden Screenshot sichtbar, wurden in dem Beispiel 170 Datensätze gelöscht und dazu rund 30ms benötigt. Mit Abschluß der Operation wird der Delete-Event erzeugt:

2018-01-05 13:38:14.596 DbRep Rep.FillCurr.fhem --DELETED_ROWS_CURRENT--: 170

[[Datei:currfillup.PNG|right|thumb|300px|set Rep.FillCurr.fhem tableCurrentFillup]]
Dieser Event wird später in einem Notify für die automatisierte Current-Auffüllung verwendet.
Eine Zählug der current-EInträge mit "set Rep.FillCurr.fhem countEntries current" ergibt "-", d.h. der Löschbefehl war erfolgreich. Im jetzigen Zustand würde bei der Erstellung eines SVG keine DropDown-Liste angezeigt werden und statt dessen die Felder im SVG-Editor frei bearbeitbar sein, weil die current-Tabelle keine Werte enthält.
Gleichermaßen kann bereits die Auffüllung der current-Tabelle getestet werden mit dem Befehl:

set Rep.FillCurr.fhem tableCurrentFillup

Je nach Größe der Datenbank kann diese Operation einige Zeit in Anspruch nehmen. Da dieser Befehl wie bei DbRep üblich non-blocking abgearbeitet wird, hat die Laufzeit keinen Einfluss auf die sonstige FHEM-Verfügbarkeit.

[[Datei:svgfillup.PNG|left|thumb|300px|set Rep.FillCurr.fhem tableCurrentFillup]]
Wie bereits erwähnt, wird in dem Beispiel die gesamte history-Tabelle ausgewertet. Sollen zum Beispiel nur die letzten 90 Tage zur Auswertung herangezogen werden, kann das '''Attribut "timeDiffToNow = d:90"''' gesetzt werden.

Weitere Eingrenzungen bzgl. der auszuwertenden Devices bzw. Readings können über die '''Attribute "device" und "reading"''' vorgenommen werden. Die Syntax für die genannten Attribute und deren Auswirkung entnehme bitte der {{Link2CmdRef|Lang=de|Anker=DbRepattr}}.

In unserem Beispiel wurde die current-Tabelle mit 170 Datensätzen aufgefüllt. Dazu wurden 291 Sekunden benötigt (die Tabelle history enthält insgesamt rund 11 Mio. Einträge)

Wird jetzt ein neues SVG erstellt, erscheinen alle in selektierten Device/Reading-Kombinationen alphabetisch sortiert als DopDown-Liste im SVG-Editor.

==== b) Konfiguration des DbLog-Devices ====

In dem bestehen DbLog-Device "LogDB" ist zur Vorbereitung lediglich das Attribut "DbLogType = SampleFill/History" zu setzen:

attr LogDB DbLogType SampleFill/History

Entgegen der Arebeitsweise mit "Current/History" wird die current-Tabelle nicht mehr durch die Logging-Engine aktiv mit jedem relevanten Event gefüllt, sondern kann durch externe Tools, in dem Fall dem DbRep-Device, beschrieben werden.
Die current-Tabelle wird aber, ob leer oder gefüllt, bei der Erstellung eines SVG-Devices ausgewertet und in Abhängigeit des Ergebnisses eine DropDown-Liste zur Verfügung gestellt, oder frei editierbare Felder angeboten falls die current-Tabelle leer ist.

==== c) Definition der at/notify-Devices zum automatisierten Ablauf ====

Die Löschung des Inhaltes der current-Tabelle und die erneute Ausffüllung soll natürlich autmatisiert regelmäßig erfolgen. Zu diesem Zweck wird ein at-Device (At.LogDB.currentPurge) und ein notify-Device angelegt. Das AT-Device soll alle 8 Stunden und 15 Minuten das Löschen des current-Inhaltes steuern und nach Abschluß der Löschung soll getriggert durch das "--DELETED_ROWS_CURRENT--"-Event die Neubefüllung der current-Tabelle veranlasst werden.

Zur Definition dieser Devices gibt es nicht viel zu erläutern. Die entsprechende Syntax kann bei {{Link2CmdRef|Lang=de|Anker=at|Label=at}} bzw. {{Link2CmdRef|Lang=de|Anker=notify|Label=notify}} in der {{Link2CmdRef|Lang=de}} nachgelesen werden.

'''at-Device:'''

define At.LogDB.currentPurge at +*08:15:00 set Rep.FillCurr.fhem tableCurrentPurge

'''notify-Device:'''

define N.LogDB.Fillup notify Rep.FillCurr.fhem:.*DELETED_ROWS_CURRENT.* sleep 5;set Rep.FillCurr.fhem tableCurrentFillup

Das nichtblockierende FHEM-sleep (sleep gefolgt von einem weiteren Befehl) wird lediglich dazu verwendet, um zwischen der Delete- und Auffüll-Operation eine kleine Pause einzufügen.

==== d) Arbeitsweise und Raw-Definitionen ====

Durch das "At.LogDB.currentPurge"-Device wird alle 8 Stunden und 15 Minuten ein Löschlauf der current-Tabelle gestartet. Dadurch wird dem darauf folgenden Auffüllprozess immer eine saubere leere current-Tabelle zur Verfügung gestellt. Nach dem Löschlauf wird durch das "N.LogDB.Fillup"-Device, getriggert durch den Event "Rep.FillCurr.fhem:.*DELETED_ROWS_CURRENT.*", die erneute Auffüllung der current-Tabelle gestartet.
Die Daten werden aus der histrory-Tabelle gelesen, wobei der Zeitraum der Selektion und die zu betrachtenden Devices / Readings durch die Zeit-Attribute bzw. device / reading-Attribute des DbRep-Devices "Rep.FillCurr.fhem" individuell beeinflußt werden können.

Hilfreich ist es auch, wenn das DbLog-Device "LogDB" im asynchronen Modus betrieben wird.

Abschließend sind hier noch die Raw-Definitionen der beteiligten Devices (außer LogDB) angehängt, um das Beispiel leicht nachvollziehbar zu gestalten.

'''DbRep-Device "Rep.FillCurr.fhem":'''

<pre>
defmod Rep.FillCurr.fhem DbRep LogDB
attr Rep.FillCurr.fhem allowDeletion 1
attr Rep.FillCurr.fhem comment Current Fillup für DB fhem
attr Rep.FillCurr.fhem devStateIcon connected:10px-kreis-gelb .*disconnect:10px-kreis-rot .*done:10px-kreis-gruen
attr Rep.FillCurr.fhem event-on-update-reading state,--DELETED_ROWS_CURRENT--
attr Rep.FillCurr.fhem icon icoTool
attr Rep.FillCurr.fhem room DbLog
attr Rep.FillCurr.fhem showproctime 1
attr Rep.FillCurr.fhem verbose 3
</pre>

'''at-Device "At.LogDB.currentPurge":'''

<pre>
defmod At.LogDB.currentPurge at +*08:15:00 set Rep.FillCurr.fhem tableCurrentPurge
attr At.LogDB.currentPurge comment Zeitgesteuertes Löschen der Current Tabelle. Nach dem Löschen wird \
Eventgesteuert (Notify N.LogDB.Fillup) ein tableCurrentFillup gestartet.
attr At.LogDB.currentPurge room DbLog
</pre>

'''notify-Device "N.LogDB.Fillup":'''

<pre>
defmod N.LogDB.Fillup notify Rep.FillCurr.fhem:.*DELETED_ROWS_CURRENT.* sleep 5;;set Rep.FillCurr.fhem tableCurrentFillup
attr N.LogDB.Fillup disable 1
attr N.LogDB.Fillup room DbLog
attr N.LogDB.Fillup verbose 2
</pre>

=== Backup/Restore einer SQLite Datenbank im laufenden Betrieb ===

In diesem Beitrag wird erläutert, wie man mit DbRep ein Backup der SQLite-Datenbank erstellen kann, welche Möglichkeiten es dabei gibt und wie man eine Datenbank aus einem Backup wieder herstellen kann.
Die Backup-Funktion nutzt die SQLite Online Backup API und ermöglicht es, konsistente Backups der SQLite-DB in laufenden Betrieb zu erstellen ohne die Datenbank schließen zu müssen.

Neben dem eigentlichen Backup kann optional einstellt werden, dass:

* vor dem Backup eine Datenbankoptimierung (Vacuum) ausgeführt werden soll. Dadurch wird Plattenplatz freigegeben sofern möglich.
* vor und nach dem Backup kann ein FHEM-Kommando oder eine Perl-Routine ausgeführt werden (eine Perl-Routine ist in {} einzuschließen)
* das erstellte Dumpfile kann über FTP(S) an einen FTP-Server übertragen werden
* über die interne Versionsverwaltung kann festgelegt werden, wieviele erstellte Backups auf dem Datenträger erhalten bleiben sollen (default: 3)

Für die Erläuterung des Beispiels soll ein DbRep-Device erstellt werden, welches:

* die SQLite Datenbank im Betrieb (Online) sichert
* vor dem Dump einen Vacuum-Lauf durchführt
* das erstellte Dumpfile auf einen FTP-Server überträgt
* 2 Versionen (Dumpfiles) nach einem erfolgreichen Backuplauf im Dumpverzeichnis verbleiben sollen

==== 1. Anlegen des DbRep-Devices ====

Das anzulegende Device wird sowohl für das (regelmäßige) Backup als auch für einen eventuellen Restore verwendet.
Die Definition des DbRep-Devices erfolgt unter Angabe des zu verbindenden DbLog-Devices (nicht der Datenbank selbst):

define Rep.SQLite DbRep LogSQLITE

Ist das Device definiert, verbindet es sich zu der Datenbank und wechselt in den state "connected", sofern die Verbindung erfolgreich verlief.
Prinzipiell funktioniert der hier beschriebene Backup-Prozess mit einem im synchronous Mode betriebenen DbLog-Device, aber es ist dringend angeraten das DbLog-Device (LogSQLITE) in den asynchronen Modus umzuschalten. Dadurch werden Blockierungen von FHEM und Verluste von Daten verhindert.

==== 2. Einstellungen des DbRep-Devices (Attribute) ====

Für die gewünschte Funktion müssen in diesem neu definierten Device einige relevante Attribute gesetzt werden.

:'''a) dumpDirLocal'''

Das zu erstellende Backupfile wird per default im log-Verzeichnis ./log (meist /opt/fhem/log) des FHEM-Rechners gespeichert. Um es an einer anderen Stelle zu speichern kann das Attribut "dumpDirLocal" gesetzt werdden. Dieses Verzeichnis kann sich auf dem lokalen Datenträger befinden, oder ein per NFS gemountetes Verzeichnis sein. In jedem Fall muss der User unter dem FHEM läuft Schreibrechte auf dieses Verzeichnis besitzen.

Für das Beispiel sollen die Dump-Files auf einen NFS-Mount einer Synology Diskstation gespeichert werden. Dazu wurde ein Mount in /etc/fstab erstellt um den Pfad "/sds1/backup" lokal verfügbar zu machen:

sds1.<fqdn>:/volume1/ApplicationBackup /sds1/backup nfs auto,defaults,tcp,intr 0 0

In diesem Verzeichnis exsitiert das Directory "dumps_FHEM", in dem die Backup-Files gespeichert werden sollen. Das Attribut wird entsprechend gesetzt auf:

attr Rep.SQLite dumpDirLocal /sds1/backup/dumps_FHEM

:'''b) dumpFilesKeep'''

Dieser Parameter stellt die Anzahl der aufzubewahrenden Backup-Files ein. Es werden immer die "x" neuesten bzw. letzten Files im Verzeichnis gehalten, wobei nur die zu der jeweiligen Datenbank gehörenden Files betrachtet werden.
Die Zugehörigkeit des Dump-Files zur Quelldatenbank wird anhand des Filenamens ermittelt, der sich zusammensetzt aus <DB-Name ohne Endung>_<Erstellungsdatum und Uhrzeit>.sqlitebkp

Beispiel: fhem_2018_01_12_17_15.sqlitebkp

Ist dieses Attribut nicht gesetzt, werden die 3 neuesten Backup-Files im Verzeichnis behalten.
Um nur 2 Files zu behalten wird das Attribut gesetzt auf:

attr Rep.SQLite dumpFilesKeep 2

:'''c) Aktionen vor und nach dem Backup ausführen'''

Vor und nach der Dump-Ausführung kann ein FHEM-Kommando bzw. Perl-Befehle ausgeführt werden. Perl-Befehle müssen in {} eingeschlossen werden.
Für das Beispiel soll vor dem Backup die Verbindung des DbLog-Devices LogSQLITE zur Datenbank getrennt werden. Dadurch werden keine neuen Daten in die Datenbank geschrieben. Wenn das DbLog-Device LogSQLITE im asynchronen Modus wie empfohlen betrieben wird, tritt auch kein Datenverlust ein, da die zu loggenden Daten im Cache verbleiben bis die Verbindung zur DB wieder hergestellt wird.

Es sei noch einmal darauf hingewiesen, dass das Backup-Verfahren ebenso im synchronen Modus und ohne das DbLog-Device von der Datenbank zu trennen, funktioniert und nur im Beispiel zur Demonstation der Möglichkeiten dient.

Um die Verbindung zu trennen wird ein "set LogSQLITE reopen <Zeit in Sekunden>" verwendet. Die Zeitspanne wird sehr großzügig gewählt und soll sicherstellen, dass innerhalb dieser Zeit das Backup abgeschlossen ist. Nach dem Backup wird sofort ein "set LogSQLITE reopen" ausgeführt, was die Verbindung des DbLog-Devices LogSQLITE zur Datenbank unmittelbar wieder herstellt..

attr Rep.SQLite executeBeforeProc set LogSQLITE reopen 3600
attr Rep.SQLite executeAfterProc set LogSQLITE reopen

:'''d) vor dem Backup Datenbank verkleinern (vacuum)'''

Diese optionale Funktion wird durch das Attribut "optimizeTablesBeforeDump" eingeschaltet. Dadurch die Vacuum-Funktion wird Platz innerhalb der Datenbank freigegeben der durch Löschvorgänge entstanden ist und dadurch die Größe des Datenbankfiles verringert.

attr Rep.SQLite optimizeTablesBeforeDump 1

:'''e) das Dump-File nach dem Backup zum FTP-Server übertragen'''

DbRep bietet die Möglichkeit, das erstellte Dump-File per FTP oder verschlüsselt per FTP(S) zum Server zu übertragen. Dazu gibt es einen Satz von Attributen um dem Device alle notwendigen Angaben für den FTP-Transfer zur Verfügung zu stellen. Es gibt dafür folgende Attribute:

* ftpUse : FTP Transfer nach dem Dump wird eingeschaltet (bzw. ftpUseSSL mit SSL Verschlüsselung)
* ftpUser : User zur Anmeldung am FTP-Server, default: anonymous
* ftpPwd : Passwort des FTP-Users, default nicht gesetzt
* ftpDir : Verzeichnis auf dem FTP-Server in welches das File übertragen werden soll (default: FTP-root)
* ftpPort : FTP-Port, default: 21
* ftpServer : Name oder IP-Adresse des FTP-Servers
* ftpTimeout : Timeout für die FTP-Verbindung in Sekunden (default: 30)
* ftpPassive : setzen wenn passives FTP verwendet werden soll
* ftpDebug : Debugging des FTP Verkehrs zur Fehlersuche

Gemäß dieser Beschreibung und dem Ziel dieses Beispiels werden die für FTP-Transfer relevanten Attribute wie folgt gesetzt:

attr Rep.SQLite ftpDir /ftp # Subdirectory ftp unter FTP-root als Zielverzeichnis
attr Rep.SQLite ftpPwd ftpftp1
attr Rep.SQLite ftpServer sds1.<fqdn>
attr Rep.SQLite ftpUse 1
attr Rep.SQLite ftpUser ftpuser

Der FTP-Server muss natürlich vorab eingerichtet und funktionsfähig sein. Sollten beim FTP-Transfer Fehler auftreten, kann das Attribut ftpDebug = 1 gesetzt werden um entsprechende Ausgaben zur Analyse des Problems im Log zu erhalten.

[[Datei:repsqlite_defined.PNG|right|thumb|300px|Fertig definiertes Device Rep.SQLite]]

:'''f) Hilfsattribute'''

Für die Funktion nicht relevant aber informativ ist das Attribut "showproctime = 1". Ist das Attribut gesetzt, wird das Reading "background_processing_time" angelegt. Es enthält nach der Ausführung die verbrauchte Prozesszeit.

Das fertig konfigurierte Device hier als RAW-Definition zur einfachen Nachnutzung. Die Angaben sind natürlich anzupassen:

<pre>
define Rep.SQLite DbRep LogSQLITE
attr Rep.SQLite devStateIcon connected:10px-kreis-gelb .*disconnect:10px-kreis-rot .*done:10px-kreis-gruen
attr Rep.SQLite dumpDirLocal /sds1/backup/dumps_FHEM
attr Rep.SQLite dumpFilesKeep 2
attr Rep.SQLite event-on-update-reading state
attr Rep.SQLite executeAfterProc set LogSQLITE reopen
attr Rep.SQLite executeBeforeProc set LogSQLITE reopen 3600
attr Rep.SQLite ftpDir /ftp
attr Rep.SQLite ftpPwd ftpftp1
attr Rep.SQLite ftpServer sds1.<fqdn>
attr Rep.SQLite ftpUse 1
attr Rep.SQLite ftpUser ftpuser
attr Rep.SQLite optimizeTablesBeforeDump 1
attr Rep.SQLite room DbLog
attr Rep.SQLite showproctime 1
attr Rep.SQLite verbose 3
</pre>

 

==== 3. Backup durchführen ====

Mit dem wie beschrieben eingerichteten DbRep-Device kann das Buckup gestartet werden mit:

set Rep.SQLite dumpSQLite

[[Datei:logsqlite_closeduntil.PNG|right|thumb|500px|LogSQLITE ist geschlossen bis ...]]

Zu Beginn des Vorgangs wird sofort die Verbindung des DbLog-Devices zur Datenbank getrennt.
Ein laufendes Backup kann mit "set Rep.SQLite cancelDump" abgebrochen werden.
Das laufende Backup wird im state angezeigt mit "SQLite Dump is running - be patient and see Logfile !". Dieser Satz ist ernst gemeint, wobei der Dump über die Online-API sehr schnell arbeitet. Im Logfile mit (mindestens) verbose 3 werden die relevanten Informationen zur Verfügung gestellt:

<pre>
2018.01.13 08:35:10.745 3: DbRep Rep.SQLite - ################################################################
2018.01.13 08:35:10.746 3: DbRep Rep.SQLite - ### New SQLite dump ###
2018.01.13 08:35:10.747 3: DbRep Rep.SQLite - ################################################################
2018.01.13 08:35:10.748 3: DbRep Rep.SQLite - execute command before dump: 'set LogSQLITE reopen 3600'
2018.01.13 08:35:10.883 2: DbLog LogSQLITE: Connection closed until 09:35:10 (3600 seconds).
2018.01.13 08:35:10.917 3: DbRep Rep.SQLite - Size of database /opt/fhem/fhem.db before optimize (MB): 2554
2018.01.13 08:35:10.918 3: DbRep Rep.SQLite - VACUUM database /opt/fhem/fhem.db....
2018.01.13 08:44:04.216 3: DbRep Rep.SQLite - Size of database /opt/fhem/fhem.db after optimize (MB): 2554
2018.01.13 08:44:04.280 3: DbRep Rep.SQLite - Starting dump of database 'fhem.db'
2018.01.13 08:45:03.810 3: DbRep Rep.SQLite - Size of backupfile: 2553.64 MB
2018.01.13 08:45:04.579 3: DbRep Rep.SQLite - FTP: transferring /sds1/backup/dumps_FHEM/fhem_2018_01_13_08_44.sqlitebkp
2018.01.13 08:45:48.838 3: DbRep Rep.SQLite - FTP: fhem_2018_01_13_08_44.sqlitebkp transferred successfully to sds1.myds.me into dir /ftp
2018.01.13 08:45:48.844 3: DbRep Rep.SQLite - Deleting old dumpfile 'fhem_2018_01_13_08_13.sqlitebkp'
2018.01.13 08:45:49.273 3: DbRep Rep.SQLite - Finished backup of database fhem - total time used: 638 seconds
2018.01.13 08:45:49.358 2: DbRep Rep.SQLite - command after dump message: "Reopen executed."
2018.01.13 08:45:49.370 3: DbRep Rep.SQLite - Database dump finished successfully.
</pre>

[[Datei:repsqlite_dumprunning.PNG|right|thumb|400px|das Backup läuft]]

Setzt man das Attribut "ftpDebug=1", erhält man im Log zusätzliche Informationen zum FTP-Transfer:

<pre>
2018.01.13 08:50:22.385 3: DbRep Rep.SQLite - Size of backupfile: 2553.82 MB
Net::FTP>>> Net::FTP(2.79)
Net::FTP>>> Exporter(5.72)
Net::FTP>>> Net::Cmd(2.30)
Net::FTP>>> IO::Socket::INET(1.35)
Net::FTP>>> IO::Socket(1.38)
Net::FTP>>> IO::Handle(1.35)
Net::FTP=GLOB(0xb12ed20)<<< 220 SDS1 FTP server ready.
Net::FTP=GLOB(0xb12ed20)>>> USER ftpuser
Net::FTP=GLOB(0xb12ed20)<<< 331 Password required for ftpuser.
Net::FTP=GLOB(0xb12ed20)>>> PASS ....
Net::FTP=GLOB(0xb12ed20)<<< 230 User ftpuser logged in, access restrictions apply.
Net::FTP=GLOB(0xb12ed20)>>> TYPE I
Net::FTP=GLOB(0xb12ed20)<<< 200 Type set to I.
Net::FTP=GLOB(0xb12ed20)>>> CWD /ftp
Net::FTP=GLOB(0xb12ed20)<<< 250 CWD command successful.
2018.01.13 08:50:22.880 3: DbRep Rep.SQLite - FTP: transferring /sds1/backup/dumps_FHEM/fhem_2018_01_13_08_49.sqlitebkp
Net::FTP=GLOB(0xb12ed20)>>> PORT 192,168,2,45,145,42
Net::FTP=GLOB(0xb12ed20)<<< 200 PORT command successful.
Net::FTP=GLOB(0xb12ed20)>>> ALLO 2677867520
Net::FTP=GLOB(0xb12ed20)<<< 202 ALLO command ignored.
Net::FTP=GLOB(0xb12ed20)>>> STOR fhem_2018_01_13_08_49.sqlitebkp
Net::FTP=GLOB(0xb12ed20)<<< 150 Opening BINARY mode data connection for 'fhem_2018_01_13_08_49.sqlitebkp'.
Net::FTP=GLOB(0xb12ed20)<<< 226 Transfer complete.
2018.01.13 08:51:06.859 3: DbRep Rep.SQLite - FTP: fhem_2018_01_13_08_49.sqlitebkp transferred successfully to sds1.myds.me into dir /ftp
</pre>

[[Datei:repsqlite_dumpfinished.PNG|right|thumb|500px|Backup ist erfolgreich abgeschlossen]]

In vorliegenden Beispiel wird nach einem erfolgreichen Backup im state "Warning - dump finished, but command after dump message appeared" angezeigt. Diese Warnung rührt daher, dass das Reopen-Kommando eine Rückkehrinfo mitteilt, die als Problem gewertet und im Reading "afterdump_message" ausgegeben wird. In diesem Fall ist es nur eine Information.

In den erstellten Readings wird zusammengetragen welches File mit welcher Größe ertsellt wurde, welche alten Files gelöscht wurden, Informationen zum FTP-Transfer und welche Zeit der Gesamtprozess benötgt hat.

Das so vorbereitete Backup kann nun z.B. täglich oder auch mit einer wesentlich kürzeren Wiederholungsperiode (alle x Stunden) über ein at-Device eingeplant werden:

define At.SQLite.Dump at *23:52:00 set Rep.SQLite dumpSQLite

==== 4. Restore ====

Sollte es einmal zur Korruption des Datenbankfiles kommen (database disk image is malformed) und Reparaturversuche erfolglos bleiben, kann ein Restore die einzigste oder vielleicht auch einfachste Möglichkeit sein die Datenbank wieder herzustellen.

Das kann mit dem angelegten DbRep-Device im laufenden Betrieb geschehen. Auch hier ist wieder wichtig, dass das DbLog-Device LogSQLITE im asynchronen Modus betrieben wird und die Reopen-Zeit (siehe Einstellung Attribut "executeBeforeProc") sehr großzügig eingestellt ist.

Zum Restore gibt es den Befehl "set ... restoreSQLite <File>".

[[Datei:sqliterestore_auswahl.PNG|right|thumb|500px|Auswahlmenü Files für Restore ]]

Im FHEMWEB öffnet sich dazu eine DropDown-Liste die alle vorhandenen und zur Quelldatenbank passenden Dumpfiles auflistet. Das herzustellende File
kann so bequem ausgewählt werden. Die Dumpfiles müssen sich in dem Verzeichnis befinden, welches durch das Attribut "dumpDirLocal" festgelegt wurde (default (./log). [[Datei:sqliterestore_running.PNG|left|thumb|500px|Restore läuft]]

Der restore wird demzufolge gestartet mit:

set Rep.SQLite restoreSQLite <File>

Wieder wird zu Beginn des Vorgangs das verbundene DbLog-Device von der Datenbank abgekoppelt und nach dem Restore wieder automatisch verbunden. Eine Datenbankoptimierung bzw. FTP-Transfer wird bei diesem Vorgang natürlich nicht ausgeführt.

Das Log zeigt den Prozessverlauf:

<pre>
2018.01.13 09:21:55.435 3: DbRep Rep.SQLite - ################################################################
2018.01.13 09:21:55.437 3: DbRep Rep.SQLite - ### New database Restore/Recovery ###
2018.01.13 09:21:55.437 3: DbRep Rep.SQLite - ################################################################
2018.01.13 09:21:55.438 3: DbRep Rep.SQLite - execute command before restore: 'set LogSQLITE reopen 3600'
2018.01.13 09:21:55.448 2: DbLog LogSQLITE: Connection closed until 10:21:55 (3600 seconds).
2018.01.13 09:21:55.477 3: DbRep Rep.SQLite - Starting restore of database 'fhem.db'
2018.01.13 09:30:12.533 3: DbRep Rep.SQLite - Restore of /sds1/backup/dumps_FHEM/fhem_2018_01_13_08_49.sqlitebkp into 'fhem.db' finished - total time used: 497 seconds.
2018.01.13 09:30:12.685 2: DbRep Rep.SQLite - command after restore message: "Reopen executed."
2018.01.13 09:30:12.700 3: DbRep Rep.SQLite - Database restore finished successfully.
</pre>

Der Restore wurde erfolgreich abgeschlossen und die Verbindung des DbLog-Device LogSQLITE zur Datenbank wiederhergestellt. Das Logging wird nahtlos fortgeführt.

[[Datei:sqliterestore_finished.PNG|right|thumb|300px|Restore erfolgreich abgeschlossen]]

Es ist natürlich zu beachten, dass die Daten zwischen dem Erstellungszeitpunkt des eingespielten Backups und der aktuellen Zeit verloren sind !
Die bestehende (korrupte) Datenbank wird überschrieben. Deswegen ist es ratsam immer ein aktuelles (zeitnahes) Backup zu haben um den Datenverlust möglichst gering zu halten.

 

==== 5. Links ====

Diskussionsthread im Forum: https://forum.fhem.de/index.php/topic,82674.0.html

 
=== Backup/Restore einer MySQL/MariaDB Datenbank im laufenden Betrieb ===

Das Backup einer MySQL/MariaDB Datenbank (im Folgenden stellvertretend als MySQL bezeichnet) kann als Varianten

* clientSide
* serverSide

Beim '''clientSide''' Backup werden die Daten über SQL-Statements aus der Datenbank gelesen, auf dem Client (dem FHEM-Server) verarbeitet und das Dumpfile geschrieben. Es werden history- und current-Tabelle gesichert, sowie eventuell weitere angelegte Tabellen und Views. Allerdings benötigt dieser Modus umfangreichere RAM und CPU-Ressorcen auf dem Client.

Die '''serverSide''' Option wird nachfolgend beispielhaft genauer erläutert.

==== serverSide Backup Option ====

Neben dem eigentlichen Backup kann optional einstellt werden, dass:

* vor dem Backup eine Tabellenoptimierung (optimizeTables) ausgeführt werden soll. Dadurch wird Plattenplatz freigegeben sofern möglich.
* vor und nach dem Backup kann ein FHEM-Kommando oder eine Perl-Routine ausgeführt werden (eine Perl-Routine ist in '''{ }''' einzuschließen)
* das erstellte Dumpfile kann komprimiert werden
* das erstellte Dumpfile kann über FTP(S) an einen FTP-Server übertragen werden
* über die interne Versionsverwaltung kann die Anzahl der im Backupverzeichnis zu verbleibenden Backup-Files festgelegt werden (default: 3)

Für die Erläuterung des Beispiels soll ein DbRep-Device erstellt werden, welches:

* die MySQL Datenbank im Betrieb (Online) sichert
* vor dem Dump die history-Tabelle optimiert
* das erstellte Dumpfile auf einen FTP-Server überträgt
* drei Versionen (Dumpfiles) nach der Übertragung auf dem FTP-Server belässt, ältere Files werden vom FTP-Server gelöscht
* eine Version (Dumpfile) nach einem erfolgreichen Backuplauf im Dumpverzeichnis verbleiben sollen

 

===== 1. Anlegen des DbRep-Devices =====

Das anzulegende Device wird sowohl für das (regelmäßige) Backup als auch für ein eventuelles Restore verwendet.
Die Definition des DbRep-Devices erfolgt unter Angabe des zu verbindenden DbLog-Devices (nicht der Datenbank selbst):

define Rep.fhemtest.Dump.ServerSide DbRep LogDB

Ist das Device definiert, verbindet es sich zu der Datenbank und wechselt in den state "connected", sofern die Verbindung erfolgreich verlief.
Prinzipiell funktioniert der hier beschriebene Backup-Prozess mit einem im synchronous Mode betriebenen DbLog-Device, aber es ist dringend angeraten das DbLog-Device (LogDB) in den asynchronen Modus umzuschalten. Dadurch werden FHEM-Blockierungen vermieden.

 

===== 2. Einstellungen des DbRep-Devices (Attribute) =====

Für die gewünschte Funktion müssen in diesem neu definierten Device einige relevante Attribute gesetzt werden.

:'''a) dumpDirRemote'''

Der Dump wird durch den MySQL-Server erstellt und per default im Home-Verzeichnis des MySQL-Servers gespeichert.
Es wird die gesamte history-Tabelle (nicht current-Tabelle) im '''CSV-Format''' ohne Einschränkungen exportiert.

Um es an einer anderen Stelle zu speichern, wird das Attribut "dumpDirRemote" gesetzt.

Auch wenn der MySQL-Server mit auf dem FHEM-Server läuft, also lokal, wird dieses Attribut zur Veränderung des Zielverzeichnisses verwendet.

 

:'''b) dumpDirLocal'''

Soll die interne Versionsverwaltung und die Dumpfilekompression des Moduls genutzt, sowie die Größe des erzeugten Dumpfiles ausgegeben werden, ist das Verzeichnis "dumpDirRemote" des MySQL-Servers auf dem Client zu mounten und im Attribut "dumpDirLocal" dem DbRep-Device bekannt zu machen.
Gleiches gilt wenn der FTP-Transfer nach dem Dump genutzt werden soll (Attribut "ftpUse" bzw. "ftpUseSSL").

Im Beispiel läuft der MySQL-Server auf einer Synology Diskstation und die Dump-Files werden dort im Verzeichnis

/volume1/ApplicationBackup/dumps_FHEM

angelegt. Dieses Verzeichnis wird auf dem FHEM-Server als Verzeichnis "/sds1/backup" gemountet.
Dazu wird ein Eintrag in /etc/fstab erstellt:

sds1.<fqdn>:/volume1/ApplicationBackup /sds1/backup nfs auto,defaults,tcp,intr 0 0

In diesem Verzeichnis existiert das Directory "dumps_FHEM", in dem die Backup-Files gespeichert werden sollen. Das Attribut wird entsprechend gesetzt auf:

attr Rep.fhemtest.Dump.ServerSide dumpDirLocal /sds1/backup/dumps_FHEM

'''Hinweis:''' 
Läuft der MySQL-Server mit FHEM lokal auf dem gleichen Server, zeigen die Attribute '''dumpDirRemote und dumpDirLocal''' auf das '''identische Verzeichnis'''. Trotzdem sind beide Attribute zu definieren.

 
:'''b) dumpFilesKeep'''

Dieser Parameter stellt die Anzahl der aufzubewahrenden Backup-Files ein. Es werden immer die "x" neuesten bzw. letzten Files im Verzeichnis gehalten, wobei nur die zu der jeweiligen Datenbank gehörenden Files betrachtet werden.
Die Zugehörigkeit des Dump-Files zur Quelldatenbank wird anhand des Filenamens ermittelt.

Er setzt sich zusammen aus <Datenbankname>_history_<Erstellungsdatum_Uhrzeit>.csv

Beispiel: fhemtest_history_2020_05_14_03_42.csv (+.gzip falls Dumpfiles komprimiert werden)

Ist dieses Attribut nicht gesetzt, werden die 3 neuesten Backup-Files im Verzeichnis behalten.
Um nur 2 Files zu behalten wird das Attribut gesetz:

attr Rep.fhemtest.Dump.ServerSide dumpFilesKeep 2

:'''c) Aktionen vor und nach dem Backup ausführen'''

Vor und nach der Dump-Ausführung kann ein FHEM-Kommando bzw. Perl-Befehle ausgeführt werden. Perl-Befehle müssen in '''{ }''' eingeschlossen werden.

Für das Beispiel soll vor dem Backup die Verbindung des DbLog-Devices LogDB zur Datenbank getrennt werden. Dadurch werden keine neuen Daten in die Datenbank geschrieben. Wenn das DbLog-Device LogDB im asynchronen Modus wie empfohlen betrieben wird, tritt auch kein Datenverlust ein, da die zu loggenden Daten im Cache verbleiben bis die Verbindung zur DB wiederhergestellt wird.

Um die Verbindung zu trennen wird ein

set LogDB reopen <Zeit in Sekunden>

verwendet. Die Zeitspanne wird sehr großzügig gewählt und soll sicherstellen, dass innerhalb dieser Zeit das Backup abgeschlossen ist. Nach dem Backup wird sofort

set LogDB reopen

ausgeführt, was die Verbindung des DbLog-Devices LogDB zur Datenbank unmittelbar wiederherstellt.

attr Rep.fhemtest.Dump.ServerSide executeBeforeProc set LogDB reopen 3600
attr Rep.fhemtest.Dump.ServerSide executeAfterProc set LogDB reopen

:'''d) vor dem Backup Datenbank verkleinern (optimizeTables)'''

Diese optionale Funktion wird durch das Attribut "optimizeTablesBeforeDump" eingeschaltet. Dadurch diese Funktion wird Platz innerhalb der Datenbank freigegeben der durch Löschvorgänge entstanden ist und dadurch die Größe des Datenbankfiles verringert.

attr Rep.fhemtest.Dump.ServerSide optimizeTablesBeforeDump 1

Durch die Tabellenoptimierung verlängert sich die Dumpzeit.

:'''e) das angelegte Dump-File nach dem Backup zum FTP-Server übertragen'''

DbRep bietet die Möglichkeit, das erstellte Dump-File per FTP oder verschlüsselt per FTPS zum FTP-Server zu übertragen. Dazu gibt es einen Satz von Attributen um dem Device alle notwendigen Angaben für den FTP-Transfer zur Verfügung zu stellen. Es gibt dafür folgende Attribute:

* ftpUse : FTP Transfer nach dem Dump wird eingeschaltet (bzw. ftpUseSSL mit SSL Verschlüsselung)
* ftpUser : User zur Anmeldung am FTP-Server, default: anonymous
* ftpPwd : Passwort des FTP-Users, default nicht gesetzt
* ftpDir : Verzeichnis auf dem FTP-Server in welches das File übertragen werden soll (default: FTP-root)
* ftpPort : FTP-Port, default: 21
* ftpServer : Name oder IP-Adresse des FTP-Servers
* ftpTimeout : Timeout für die FTP-Verbindung in Sekunden (default: 30)
* ftpPassive : setzen wenn passives FTP verwendet werden soll
* ftpDebug : Debugging des FTP Verkehrs zur Fehlersuche

Gemäß dieser Beschreibung und dem Ziel dieses Beispiels werden die für FTP-Transfer relevanten Attribute wie folgt gesetzt:

attr Rep.fhemtest.Dump.ServerSide ftpDir /ftp # Subdirectory ftp unter FTP-root als Zielverzeichnis
attr Rep.fhemtest.Dump.ServerSide ftpPwd ftpftp1
attr Rep.fhemtest.Dump.ServerSide ftpServer sds1.<fqdn>
attr Rep.fhemtest.Dump.ServerSide ftpUse 1
attr Rep.fhemtest.Dump.ServerSide ftpUser ftpuser

Der FTP-Server muss natürlich vorab eingerichtet und funktionsfähig sein. Sollten beim FTP-Transfer Fehler auftreten, kann das Attribut ftpDebug = 1 gesetzt werden um entsprechende Ausgaben zur Analyse des Problems im Log zu erhalten.

[[Datei:dumpmysql1.PNG|right|thumb|300px|Fertig definiertes Device Rep.fhemtest.Dump.ServerSide]]

 
:'''f) Hilfsattribute'''

Für die Funktion nicht relevant aber informativ ist das Attribut "showproctime = 1". Ist das Attribut gesetzt, wird das Reading "background_processing_time" angelegt. Es enthält nach der Ausführung die verbrauchte Prozesszeit.

Im Attribut "userExitFn" kann eine Perl-Routine hinterlegt werden, um zum Beispiel nach dem Backup eine Mail oder Telegram-Message mit dem Erfolgsstatus zu versenden.

Das fertig konfigurierte Device hier als RAW-Definition zur einfachen Nachnutzung. Die Angaben sind natürlich anzupassen:

<pre>
define Rep.fhemtest.Dump.ServerSide DbRep LogDB
attr Rep.fhemtest.Dump.ServerSide devStateIcon connected:10px-kreis-gelb .*disconnect:10px-kreis-rot .*done:10px-kreis-gruen .*Dump.*is.*running.*:remotecontrol/black_btn_PLAYgreen Database.*backup.*finished.*:remotecontrol/black_btn_GREEN tn_GREEN error.*:remotecontrol/black_btn_RED
attr Rep.fhemtest.Dump.ServerSide dumpCompress 1
attr Rep.fhemtest.Dump.ServerSide dumpDirLocal /sds1/backup/dumps_FHEM
attr Rep.fhemtest.Dump.ServerSide dumpDirRemote /volume1/ApplicationBackup/dumps_FHEM
attr Rep.fhemtest.Dump.ServerSide dumpFilesKeep 1
attr Rep.fhemtest.Dump.ServerSide event-on-update-reading state
attr Rep.fhemtest.Dump.ServerSide executeAfterProc set LogDB reopen
attr Rep.fhemtest.Dump.ServerSide executeBeforeProc set LogDB reopen 3600
attr Rep.fhemtest.Dump.ServerSide fastStart 1
attr Rep.fhemtest.Dump.ServerSide ftpDebug 0
attr Rep.fhemtest.Dump.ServerSide ftpDir /ftp
attr Rep.fhemtest.Dump.ServerSide ftpDumpFilesKeep 3
attr Rep.fhemtest.Dump.ServerSide ftpPwd ftpftp1
attr Rep.fhemtest.Dump.ServerSide ftpServer sds1.<fqdn>
attr Rep.fhemtest.Dump.ServerSide ftpUse 0
attr Rep.fhemtest.Dump.ServerSide ftpUser ftpuser
attr Rep.fhemtest.Dump.ServerSide optimizeTablesBeforeDump 1
attr Rep.fhemtest.Dump.ServerSide showproctime 1
attr Rep.fhemtest.Dump.ServerSide userExitFn doafterdump
</pre>

 

===== 3. Backup durchführen =====

Voraussetzung ist, dass der verwendete Datenbankuser das globale Privileg '''FILE''' besitzt.
Falls der User dieses Recht nicht hat, kann man es mit dem definierten DbRep-Device wie folgt erledigen.

:'''(optional) dem Datenbankuser das FILE Privileg zuweisen'''

Da die Rechtezuweisung nur mit einem administrativen DB-User (i.A. root) funktioniert, wird dieser User im DbRep-Device angelegt und aktiviert:

<pre>
set Rep.fhemtest.Dump.ServerSide adminCredentials <Admin-User> <Passwort>
attr Rep.fhemtest.Dump.ServerSide useAdminCredentials 1
</pre>

Nun kann dem verwendeten Datenbankuser das FILE Privileg zugeordnet werden:

<pre>
set Rep.fhemtest.Dump.ServerSide sqlCmd GRANT FILE ON *.* TO '<DB-User>'@'%';
</pre>

Dabei ist '''<DB-User>''' durch den in der DbLog-Konfiguration angegebenen User zu ersetzen da die gesamte Datenbankarbeit mit diesem User erfolgt.

Nach der Ausführung schaltet man die Nutzung des administrativen Users wieder ab mit:

<pre>
attr Rep.fhemtest.Dump.ServerSide useAdminCredentials 0
</pre>

Die Rechte können nun überprüft werden mit

<pre>
set Rep.fhemtest.Dump.ServerSide sqlCmd show grants;
</pre>

und werden im Ergebnis dargestellt (z.B. für den DB-User fhemtest):

<pre>
SqlResultRow_1 GRANTS FOR FHEMTEST@%
SqlResultRow_2 GRANT PROCESS, FILE, INDEX ON *.* TO 'fhemtest'@'%' IDENTIFIED BY PASSWORD '*...............'
SqlResultRow_3 GRANT SELECT, INSERT, UPDATE, DELETE, ALTER, EXECUTE, SHOW VIEW ON `fhemtest`.* TO 'fhemtest'@'%'
SqlResultRow_4 GRANT SELECT, INSERT, UPDATE, DELETE, CREATE, INDEX ON `fhemtest`.`fhemtest` TO 'fhemtest'@'%'
</pre>

 
:'''Backup starten'''

[[Datei:dumpmysql2.PNG|right|thumb|400px|Backup läuft ...]]
Mit dem wie beschrieben eingerichteten DbRep-Device kann das Backup gestartet werden mit:

set Rep.fhemtest.Dump.ServerSide dumpMySQL serverSide

Zu Beginn des Vorgangs wird sofort die Verbindung des DbLog-Devices zur Datenbank getrennt.
Ein laufendes serverSide Backup kann mit FHEM-Mitteln nicht abgebrochen werden !

Das laufende Backup wird im state angezeigt mit "serverSide Dump is running - be patient and see Logfile !".

Im Logfile mit (mindestens) verbose 3 werden die relevanten Informationen zur Verfügung gestellt:

<pre>
2020.05.14 22:59:18.610 3: DbRep Rep.fhemtest.Dump.ServerSide - ########################################
2020.05.14 22:59:18.611 3: DbRep Rep.fhemtest.Dump.ServerSide - ### New database serverSide dump ###
2020.05.14 22:59:18.611 3: DbRep Rep.fhemtest.Dump.ServerSide - ########################################
2020.05.14 22:59:18.612 3: DbRep Rep.fhemtest.Dump.ServerSide - execute command before dump: 'set LogDB reopen 3600'
2020.05.14 22:59:18.613 2: DbLog LogDB: Connection closed until 23:59:18 (3600 seconds).
2020.05.14 22:59:18.660 3: DbRep Rep.fhemtest.Dump.ServerSide - Searching for tables inside database fhemtest....
2020.05.14 22:59:18.664 3: DbRep Rep.fhemtest.Dump.ServerSide - Size of database fhemtest before optimize (MB): 8298.98
2020.05.14 22:59:18.665 3: DbRep Rep.fhemtest.Dump.ServerSide - Optimizing tables
2020.05.14 22:59:18.665 3: DbRep Rep.fhemtest.Dump.ServerSide - Optimizing table `current` (INNODB). It will take a while.
2020.05.14 22:59:19.560 3: DbRep Rep.fhemtest.Dump.ServerSide - Table 1 `current` optimized successfully.
2020.05.14 22:59:19.560 3: DbRep Rep.fhemtest.Dump.ServerSide - Optimizing table `history` (INNODB). It will take a while.
2020.05.14 23:30:09.183 3: DbRep Rep.fhemtest.Dump.ServerSide - Table 2 `history` optimized successfully.
2020.05.14 23:30:09.186 3: DbRep Rep.fhemtest.Dump.ServerSide - 2 tables have been optimized.
2020.05.14 23:30:09.253 3: DbRep Rep.fhemtest.Dump.ServerSide - Size of database fhemtest after optimize (MB): 8298.98
2020.05.14 23:30:09.254 3: DbRep Rep.fhemtest.Dump.ServerSide - Starting dump of database 'fhemtest', table 'history'
2020.05.14 23:39:47.566 3: DbRep Rep.fhemtest.Dump.ServerSide - compress file /sds1/backup/dumps_FHEM/fhemtest_history_2020_05_14_23_30.csv
2020.05.14 23:42:33.138 3: DbRep Rep.fhemtest.Dump.ServerSide - file compressed to output file: /sds1/backup/dumps_FHEM/fhemtest_history_2020_05_14_23_30.csv.gzip
2020.05.14 23:42:34.784 3: DbRep Rep.fhemtest.Dump.ServerSide - input file deleted: /sds1/backup/dumps_FHEM/fhemtest_history_2020_05_14_23_30.csv
2020.05.14 23:42:34.785 3: DbRep Rep.fhemtest.Dump.ServerSide - Number of exported datasets: 49032159
2020.05.14 23:42:34.787 3: DbRep Rep.fhemtest.Dump.ServerSide - Size of backupfile: 419.73 MB
2020.05.14 23:42:37.082 3: DbRep Rep.fhemtest.Dump.ServerSide - FTP: transferring /sds1/backup/dumps_FHEM/fhemtest_history_2020_05_14_23_30.csv.gzip
2020.05.14 23:42:47.511 3: DbRep Rep.fhemtest.Dump.ServerSide - FTP: fhemtest_history_2020_05_14_23_30.csv.gzip transferred successfully to sds1.myds.me into dir /ftp
2020.05.14 23:42:47.558 3: DbRep Rep.fhemtest.Dump.ServerSide - Deleting old dumpfile 'fhemtest_history_2020_05_14_22_12.csv.gzip'
2020.05.14 23:42:47.857 3: DbRep Rep.fhemtest.Dump.ServerSide - Finished backup of database fhemtest - total time used (hh:mm:ss): 00:43:29
2020.05.14 23:42:47.948 2: DbRep Rep.fhemtest.Dump.ServerSide - command message after dump: "Reopen executed."
2020.05.14 23:42:47.973 3: DbRep Rep.fhemtest.Dump.ServerSide - Database dump finished successfully.
</pre>

[[Datei:dumpmysql3.PNG|right|thumb|500px|Backup ist erfolgreich abgeschlossen]]

In vorliegenden Beispiel wird nach einem erfolgreichen Backup im state '''"Warning - dump finished, but command after dump message appeared"''' angezeigt.

Diese Warnung rührt daher, dass das Reopen-Kommando eine Rückkehrinfo mitteilt, die als Issue gewertet und im Reading "afterdump_message" ausgegeben wird. In diesem Fall ist es nur eine Information.

In den erstellten Readings wird zusammengetragen welches File mit welcher Größe erstellt wurde, welche alten Files gelöscht wurden, Informationen zum FTP-Transfer und welche Zeit der Gesamtprozess benötgt hat.

Das so vorbereitete Backup kann nun z.B. täglich oder auch mit einer wesentlich kürzeren Wiederholungsperiode (alle x Stunden) über ein at-Device eingeplant werden:

define At.MySQL.Dump at *23:52:00 set Rep.fhemtest.Dump.ServerSide dumpMySQL serverSide

 

===== 4. Restore =====

Voraussetzung für das Restore ist, dass der verwendete Datenbankuser das globale Privileg '''FILE''' besitzt.
Falls der User dieses Recht nicht hat, kann man es mit dem definierten DbRep-Device wie folgt erledigen.

:'''(optional) dem Datenbankuser das FILE Privileg zuweisen'''

Da die Rechtezuweisung nur mit einem administrativen DB-User (i.A. root) funktioniert, wird dieser User im DbRep-Device angelegt und aktiviert:

<pre>
set Rep.fhemtest.Dump.ServerSide adminCredentials <Admin-User> <Passwort>
attr Rep.fhemtest.Dump.ServerSide useAdminCredentials 1
</pre>

Nun kann dem verwendeten Datenbankuser das FILE Privileg zugeordnet werden:

<pre>
set Rep.fhemtest.Dump.ServerSide sqlCmd GRANT FILE ON *.* TO '<DB-User>'@'%';
</pre>

Dabei ist '''<DB-User>''' durch den in der DbLog-Konfiguration angegebenen User zu ersetzen da die gesamte Datenbankarbeit mit diesem User erfolgt.

Nach der Ausführung schaltet man die Nutzung des administrativen Users wieder ab mit:

<pre>
attr Rep.fhemtest.Dump.ServerSide useAdminCredentials 0
</pre>

'''Alternativ''' kann die Rechtezuweisung auf der Konsole des MySQL-Servers ausgeführt werden:

<pre>
sudo mysql -u root -p
GRANT File ON *.* TO '<DB-User>'@'%';
exit
</pre>

Die Rechte können nun überprüft werden mit

<pre>
set Rep.fhemtest.Dump.ServerSide sqlCmd show grants;
</pre>

Nun kann der Restore ausgeführt werden.

Ein mit der Option '''serverSide''' erstellter Dump enthält ausschließlich die Daten der history-Tabelle.
Der Restore kann nur in eine bestehende Datenabank und entsprechend angelegte history Tabelle erfolgen.
Ist nach einem Datenbankfehler die Tabelle/Datenbank zerstört, must sie zunächst mit den vorbereiteten Befehlen in den
[https://svn.fhem.de/trac/browser/trunk/fhem/contrib/dblog/db_create_mysql.sql SVN-Skripten] bereitgestellt werden.

Ist die history-Tabelle noch intakt und soll nur der Inhalt ersetzt werden, muss die Tabelle vorab geleert werden da sonst unter Umständen doppelte Datensätze enstehen wenn kein primary Key verwendet ist.
Das kann einfach mit dem Befehl

set <Name> sqlCmd truncate table history

erreicht werden. Damit werden '''alle''' Daten der history-Tabelle hochperformant gelöscht. Die Tabelle selbst bleibt erhalten.

Sollte der truncate Befehl wegen nicht ausreichender Rechte des DB-Users mit Fehler enden, kann ein administrativer Datenbankuser (i.A. 'root') mit dem Kommando und Attribut

set <Name> adminCredentials <Name> <Passwort>
attr <Name> useAdminCredentials 1

hinterlegt und aktiviert werden.

Ein Restore kann mit dem angelegten DbRep-Device im laufenden Betrieb geschehen. Auch hier ist wieder wichtig, dass das DbLog-Device im asynchronen Modus betrieben wird und die Reopen-Zeit (siehe Einstellung Attribut "executeBeforeProc") sehr großzügig eingestellt ist.

Zum Restore dient der Befehl

set <Name> restoreMySQL <File>

[[Datei:dumpmysql4.PNG|right|thumb|500px|Auswahlmenü Files für Restore ]]

Im FHEMWEB öffnet sich dazu eine DropDown-Liste die alle vorhandenen und zur Quelldatenbank passenden Dumpfiles auflistet.
Das herzustellende File kann so bequem ausgewählt werden. Die Dumpfiles müssen sich in dem Verzeichnis befinden, welches durch das Attribut '''dumpDirLocal''' festgelegt wurde (default (./log). [[Datei:dumpmysql5.PNG|left|thumb|500px|Restore läuft]]

Der restore wird demzufolge gestartet mit:

set Rep.fhemtest.Dump.ServerSide restoreMySQL <File>

Der Restore der history-Tabelle kann nun online im laufenden FHEM-Betrieb erfolgen.
Wieder wird zu Beginn des Vorgangs das verbundene DbLog-Device von der Datenbank abgekoppelt und nach dem Restore wieder automatisch verbunden. Eine Datenbankoptimierung bzw. FTP-Transfer wird bei diesem Vorgang natürlich nicht ausgeführt.

[[Datei:dumpmysql6.PNG|left|thumb|500px|Fortschrittsanzeige in einem zweiten DbRep Device]]
In einem zweiten (z.B. kopierten) DbRep Device kann mit Hilfe des Befehls

get Rep.fhemtest.Dump.ServerSide procinfo

der Fortschritt des Restores überwacht werden. In der Spalte '''PROGRESS''' wird der Fortschritt in '''%''' angegeben.

Das Log zeigt den Ablauf des Restores:

<pre>
2020.05.15 13:07:24.369 3: DbRep Rep.fhemtest.Dump.ServerSide - #######################################
2020.05.15 13:07:24.370 3: DbRep Rep.fhemtest.Dump.ServerSide - ### New database Restore/Recovery ###
2020.05.15 13:07:24.371 3: DbRep Rep.fhemtest.Dump.ServerSide - #######################################
2020.05.15 13:07:24.371 3: DbRep Rep.fhemtest.Dump.ServerSide - execute command before restore: 'set LogDB reopen 3600'
2020.05.15 13:07:24.429 3: DbRep Rep.fhemtest.Dump.ServerSide - uncompress file /sds1/backup/dumps_FHEM/fhemtest_history_2020_05_15_11_47.csv.gzip
2020.05.15 13:09:31.152 3: DbRep Rep.fhemtest.Dump.ServerSide - file uncompressed to output file: /sds1/backup/dumps_FHEM/fhemtest_history_2020_05_15_11_47.csv
2020.05.15 13:09:31.237 3: DbRep Rep.fhemtest.Dump.ServerSide - Size of uncompressed file: 5511.52 MB
2020.05.15 13:09:31.242 3: DbRep Rep.fhemtest.Dump.ServerSide - Starting restore of database 'fhemtest', table 'history'.
2020.05.15 14:42:28.566 2: DbLog LogDB: Connection closed until 16:42:28 (7200 seconds).
2020.05.15 14:46:22.391 3: DbRep Rep.fhemtest.Dump.ServerSide - Restore of /volume1/ApplicationBackup/dumps_FHEM/fhemtest_history_2020_05_15_11_47.csv into 'fhemtest', 'history' finished - total time used (hh:mm:ss): 01:38:57
2020.05.15 14:46:22.457 2: DbRep Rep.fhemtest.Dump.ServerSide - command message after restore: "Reopen executed."
2020.05.15 14:46:22.481 3: DbRep Rep.fhemtest.Dump.ServerSide - Database restore finished successfully.
</pre>

[[Datei:dumpmysql7.PNG|right|thumb|300px|Restore erfolgreich abgeschlossen]]

Der Restore wurde erfolgreich abgeschlossen und die Verbindung des DbLog-Device LogDB zur Datenbank wiederhergestellt. Das Logging wird nahtlos fortgeführt.

Es ist natürlich zu beachten, dass die Daten zwischen dem Erstellungszeitpunkt des eingespielten Backups und der aktuellen Zeit verloren sind !
Eventuell in der Tabelle '''history''' noch vorhandene Daten werden '''nicht''' überschrieben.

 

=== Speichern von Berechnungswerten in der Datenbank und Erstellen eines Plots (ab Version 7.5.1) ===

Es sollen aus in der Datenbank vorhandenen minütlichen Leistungswerten eines Wechselrichters die maximal-, minimal- und durchschnittlichen Leistungswerte pro Tag berechnet werden und diese Ergebnisse wieder in die Datenbank geschrieben werden um daraus einen Plot zu erstellen.
Diese Berechnung soll immer aktuell für den laufenden Monat erfolgen.

Die Ausgangswerte liegen in der Datenbank als minütliche kW-Einträge vor (Auszug DbRep fetchrows):

<pre>
2018-01-18_15-55-49__MySTP_5000__total_pac 0.200
2018-01-18_15-56-50__MySTP_5000__total_pac 0.218
2018-01-18_16-00-14__MySTP_5000__total_pac 0.209
2018-01-18_16-00-39__MySTP_5000__total_pac 0.198
2018-01-18_16-01-39__MySTP_5000__total_pac 0.142
2018-01-18_16-02-39__MySTP_5000__total_pac 0.130
2018-01-18_16-03-39__MySTP_5000__total_pac 0.117
2018-01-18_16-05-39__MySTP_5000__total_pac 0.087
2018-01-18_16-06-39__MySTP_5000__total_pac 0.071
2018-01-18_16-07-39__MySTP_5000__total_pac 0.076
2018-01-18_16-08-39__MySTP_5000__total_pac 0.065
2018-01-18_16-09-39__MySTP_5000__total_pac 0.069
2018-01-18_16-10-39__MySTP_5000__total_pac 0.060
2018-01-18_16-12-39__MySTP_5000__total_pac 0.065
2018-01-18_16-13-39__MySTP_5000__total_pac 0.068
2018-01-18_16-14-39__MySTP_5000__total_pac 0.054
2018-01-18_16-15-39__MySTP_5000__total_pac 0.041
2018-01-18_16-16-39__MySTP_5000__total_pac 0.027
2018-01-18_16-17-39__MySTP_5000__total_pac 0.026
2018-01-18_16-18-39__MySTP_5000__total_pac 0.021
2018-01-18_16-19-39__MySTP_5000__total_pac 0.018
2018-01-18_16-20-39__MySTP_5000__total_pac 0.012
</pre>

Für die Berechnung der Ergenisse stehen in DbRep die Kommandos maxValue, minValue und averageValue zur Verfügung.

 
==== 1. Anlegen des DbRep-Devices ====

Das anzulegende Device wird für alle notwendigen Berechnungen verwendet.
Die Definition des DbRep-Devices erfolgt unter Angabe des zu verbindenden DbLog-Devices (nicht der Datenbank selbst):

define Rep.total_pac DbRep LogDB

Ist das Device definiert, verbindet es sich zu der Datenbank und wechselt in den state "connected", sofern die Verbindung erfolgreich verlief.
Prinzipiell funktioniert der hier Ablauf mit einem im synchronous Mode betriebenen DbLog-Device, aber es ist dringend angeraten das DbLog-Device (LogDB) in den asynchronen Modus umzuschalten. Dadurch werden Blockierungen von FHEM verhindert.

 

==== 2. Einstellungen des DbRep-Devices (Attribute) ====
[[Datei:Rep.total_pac.PNG|right|thumb|400px|Device definiert]]
Für die gewünschte Funktion müssen in diesem neu definierten Device einige relevante Attribute gesetzt werden.

Da die Berechnungen immer für den aktuellen Monat erstellt werden sollen, wird das Attribut "timestamp_begin" so definiert, dass immer der Beginn des aktuellen Monats dynamisch ermittelt wird. Das ist gegeben durch den Eintrag:

attr Rep.total_pac timestamp_begin current_month_begin

Es soll ein Ergebniswert pro Tag erzeugt werden. Damit dies erreicht werden kann, wird das Attribut "aggregation" verwendet und auf den Wert "day" eingestellt. Würde zum Beispiel ein stündlicher Ergebniswert gewünscht sein, hätte "aggregation = hour" den benötigten Effekt.

attr Rep.total_pac aggregation day

Die Attribute "device" und "reading" legen das auszuwertende Device und Reading fest. Dabei ist zu beachten, dass im Gegensatz zur allgemein gültigen Möglichkeit devspec bzw. SQL-Wildcards zu verwenden bei dieser speziellen Detailfunktion dies nicht der Fall ist. Das heißt. es muß immer ein eindeutiges Device und ein eindeutiges Reading angegeben werden. Der Grund liegt in der Notwendigkeit, bei der Speicherung der Ergebnisdaten der Datenbank ebenfalls ein eindeutiges Device und Reading zu übergeben. In dem Beispiel wird das Device "MySTP_5000" und das Reading "total_pac" ausgewertet.

attr Rep.total_pac device MySTP_5000
attr Rep.total_pac reading total_pac

Hilfreiche Attribute sind noch "event-on-update-reading" zur Begrenzung der Events, "showproctime" zur Bestimmung der Prozesszeiten und "allowDeletion" um die Möglichkeit zu haben, irrtümlich gespeicherte Berechnungsergebnisse wieder über das DbRep-Device zu löschen.

attr Rep.total_pac event-on-update-reading state
attr Rep.total_pac showproctime 1
attr Rep.total_pac allowDeletion 1

Das so vorbereitete Device ist für die benötigten Funktionen ausreichend eingestellt.
Zur einfachen Nachnutzung nochfolgend die Raw-Definition des DbRep-Devices:

<pre>
define Rep.total_pac DbRep LogDB
attr Rep.total_pac aggregation day
attr Rep.total_pac allowDeletion 1
attr Rep.total_pac device MySTP_5000
attr Rep.total_pac event-on-update-reading state
attr Rep.total_pac reading total_pac
attr Rep.total_pac room DbLog
attr Rep.total_pac showproctime 1
attr Rep.total_pac timestamp_begin current_month_begin
attr Rep.total_pac verbose 3
</pre>

 
==== 3. Berechnung ausführen und Speicherung der Ergebnisse ====
[[Datei:average.PNG|right|thumb|300px|Average Berechnung]]
Die benötigten Funktionen sind:

averageValue - Berechnung des täglichen Durchschnittswert der Wechselrichterleistung (kW)
maxValue - Berechnung des täglichen Maximalwertes der Wechselrichterleistung (kW)
minValue - Berechnung des täglichen Minimalwertes der Wechselrichterleistung (kW)

[[Datei:minval.PNG|right|thumb|300px|MinVal Berechnung]]
Für jede dieser Kommandos stehen im DbRep die Optionen "display" und "writeToDB" zur Verfügung. Die Option "display" stellt die Ergenisse lediglich im Browser dar und kann dazu die Ergebnisse vor der Speicherung zu bewerten.
So ergeben die Kommandos:

set Rep.total_pac minValue display
set Rep.total_pac maxValue display
set Rep.total_pac avarageValue display

die täglichen Min-, Max- und Durchschnittswerte der WR-Leistung.

[[Datei:maxval.PNG|right|thumb|300px|MaxVal Berechnung]]
Entsprechen die Ergebnisse den Erwartungen bzw. dem Ziel, können die folgenden Kommandos verwendet werden um die Berechnung durchzuführen und dabei gleichzeitig in die Datenbank zu schreiben.

set Rep.total_pac minValue writeToDB
set Rep.total_pac maxValue writeToDB
set Rep.total_pac avarageValue writeToDB

Die Daten werden in der history-Tabelle gespeichert und, sofern das DbLog-Device das Attribut "DbLogType = Current..." gestzt hat, auch in der current-Tabelle gespeichert. Im letzteren Fall kann das Ergebnisreading bei der Erstellung des Plots sofort aus der DropDown-Liste ausgewählt werden.

Bei der Datenspeicherung wird der neue Readingnamen aus einem Präfix und dem originalen Readingnamen gebildet. Der Präfix setzt sich aus der Bildungsfunktion und der gewählten Aggregation zusammen, d.h. im Fall des Beispiels aus "min","max","avg" und "day".
Der Timestamp der neuen Readings in der Datenbank wird von der eingestellten Aggregationsperiode abgeleitet, sofern kein eindeutiger Zeitpunkt des Ergebnisses bestimmt werden kann. So kann der Zeitpunkt des Maximalwertes eines Tages wertes genau bestimmt werden und der resultierende Datensatz wird mit diesem Timestamp gespeichert.

Die resultierende Readingnamen werden somit wie folgt in der Datenbank gespeichert:

max_day_total_pac
min_day_total_pac
avg_day_total_pac

Die Berechnungen können regelmäßig über ein at eingeplant werden. Die Funktionen vermeiden dabei die Speicherung von doppelten Datensätzen. Wurde bei einem Berechnungslauf der Datensatz bereits gespeichert, wird dieser Datensatz beim nächsten Durchlauf nicht noch einmal gespeichert.

==== 4. Erstellung des Plots ====
[[Datei:dropdown.PNG|right|thumb|300px|Drop-Down Liste SVG]]
Wird durch das DbLog-Device die current-Tabelle genutzt, das Attribut "DbLogType = Current..." ist gesetzt, können die Ergebnisreadings max_day_total_pac, min_day_total_pac und avg_day_total_pac im SVG-Editor ausgewählt werden (siehe {{Link2CmdRef|Lang=de|Anker=SVG}} bei SVG).

Durch die Wahl des Plot-Typ "bars" und dem SVG-Attribut "fixedrange = month" entsteht der gewünschte Tageswert-Plot über den aktuellen Monat.

[[Datei:svg_calc.PNG|right|thumb|300px|Ergebnis SVG]]
Hier wiederum die Raw-Definition des SVG-Device:

<pre>
defmod SVG_LogDB_16 SVG LogDB:SVG_LogDB_16:HISTORY
attr SVG_LogDB_16 fixedrange month
attr SVG_LogDB_16 room Energie,SVG_MySQL
attr SVG_LogDB_16 title "Max Leistung: $data{max1} kW, Min Leistung: $data{min3} kW,Max. Durchschnittsleistung: $data{max2} kW "
</pre>

sowie des gplot-Files:

<pre>
# Created by FHEM/98_SVG.pm, 2018-01-18 21:45:27
set terminal png transparent size <SIZE> crop
set output '<OUT>.png'
set xdata time
set timefmt "%Y-%m-%d_%H:%M:%S"
set xlabel " "
set title '<TL>'
set ytics
set y2tics
set grid
set ylabel "kW"
set y2label "kW"
set yrange [0:6]
set y2range [0:6]

#LogDB MySTP_5000:max_day_total_pac
#LogDB MySTP_5000:avg_day_total_pac
#LogDB MySTP_5000:min_day_total_pac

plot "<IN>" using 1:2 axes x1y2 title 'Max-Leistung / Tag' ls l0fill lw 1 with bars,\
"<IN>" using 1:2 axes x1y2 title 'Average / Tag' ls l2fill lw 1 with bars,\
"<IN>" using 1:2 axes x1y2 title 'Min-Leistung / Tag' ls l1fill lw 1 with bars
</pre>

 
=== Öffnungszeiten von Fenster/Türen aus der Datenbank ermitteln ===

Ziel ist es, die Öffnungszeit eines Fensters oder einer Tür zu ermitteln sobald es wieder geschlossen wird und ein Reading mit der Zeit in dem entsprechenden Device (Fensterkontakt) zu setzen.

Für das Beispiel wird angenommen dass:

* der Status der Sensoren als "open" und "close" in der Datenbank gespeichert ist
* das verwendetet DbRep-Device "Rep.WindowOpenTime" heißt
* das verwendete DbLog-Device "LogDBShort" heißt (wird mit dem DbRep-Device bei der Definition assoziiert)

Zunächst wird zur Auswertung von closed-Events ein entsprechendes Notify definiert (Raw-Format):

<pre>
defmod N.WindowClosed notify (.*fenster.*|.*terrasse.tuer.*):closed \
{ \
if($NAME =~ /(.*fenster.*|.*terrasse.tuer.*)/) {\
fhem("set LogDBShort commitCache;; defmod calcse at +00:00:10 {SwitchEvent(\"$NAME\")};;");; \
}\
}
attr N.WindowClosed alias Starte Ermittlung der Fenster Öffnungszeiten
attr N.WindowClosed comment Wird verwendet um die letzte Öffnungszeit der Fenster aus der Datenbank zu ermitteln und im Reading "LastOpenTime" abzulegen.
attr N.WindowClosed room Datenbank->Produktiv
</pre>

Die zusätzlich if-Abfrage im Notify behob ein Problem bei den Fensterkontakten die mit einem Thermostat gepeert sind, da in diesem Fall der Event mehrfach auftrat. Der Teil '''"set LogDBShort commitCache"''' speichert den Cache der Datenbank vor der Berechnung sofern sie im asynchronen Modus betrieben wird (kann entfallen wenn im synchronen Mode betrieben). Um der DB Zeit zur Abspeicherung zu geben, wird die Berechnung über ein AT mit einer entsprechenden Verzögerung (hier 10 Sekunden) angestartet. Die Zeit im AT bitte entsprechend der eigenen Systembedingungen anpassen.

Im Notify wird die Funktion '''SwitchEvent($NAME)''' aufgerufen. Diese Funktion wird in der 99_myUtils.pm eingefügt:

<source lang="perl">
##########################################################################################################
# This function is used to start an SQL query for the given device "$name" and check
# how much time the device was in state defined by $usedVal1 today.
# The query is done by a DbRep device.
#
# In this example the name of the DbRep device is "Rep.WindowOpenTime"
##########################################################################################################
sub SwitchEvent($) {
my ($name) = @_;

Log3 $name , 5, "$name - SwitchEvent called";

my $usedReading = "\"state\""; # name of the reading which holds the state which has to be checked
my $usedVal1 = "\"open\""; # reading value which starts the time measuerement
my $usedVal2 = "\"closed\""; # reading value which stops the time measurement
my $device = "\"$name\""; # name of the device which state has to be checked
my $dbRepDevice = "Rep.WindowOpenTime"; # name of the DbRep device

# The query will check for the current day the cumulated time difference between $usedVal1 and $usedVal2
# the example here is a homemetic threeStateSensor (window contact) and the result of the query is
# the cumulated time which the window was open (in seconds) and the name of the device whic is
# used by the function SwitchQueryResult()
# Example: AZ_Fensterkontakt|433.2
my $sql = "SET \@topen = NULL,\@closed = NULL, \@popen = NULL;;".
" SELECT DEVICE ,SUM(TIMEDIFF(tclosed, topen)) AS duration FROM (".
" SELECT TIMESTAMP, VALUE, DEVICE,".
" \@topen := \@popen AS topen,".
" \@closed := IF(VALUE = $usedVal2, TIMESTAMP, NULL) AS tclosed,".
" \@popen := IF(VALUE = $usedVal1, TIMESTAMP, NULL) AS prev_open".
" FROM history WHERE".
" DATE(TIMESTAMP) = CURDATE() AND".
" DEVICE = $device AND".
" READING = $usedReading AND ".
" (VALUE = $usedVal1 OR VALUE = $usedVal2)".
" ORDER BY TIMESTAMP".
" ) AS tmp";

Log3 $name , 5, "$name - SwitchEvent start query: $sql";

fhem("set $dbRepDevice sqlCmd $sql"); # start the query now. Result will be processed in the function SwitchQueryResult() below

return;
}
</source>

Die Funktion '''SwitchEvent()''' bekommt den Namen des Gerätes übergeben welches Event ausgelöst hat. Damit wird eine SQL-Abfrage für dieses Gerät gestartet und ermittelt, wieviel Zeit (in Sekunden) für das übergebene Gerät zwischen dem Zustand "open" und "closed" verbracht wurde.

Das verwendete DbRep-Device wird wie folgt definiert:

<pre>
define Rep.WindowOpenTime DbRep LogDBShort
attr Rep.WindowOpenTime aggregation no
attr Rep.WindowOpenTime comment Öffnungszeit der Fenster ermitteln
attr Rep.WindowOpenTime initialized:control_3dot_hor_s connected:10px-kreis-gelb .*disconnect:10px-kreis-rot .*done:10px-kreis-gruen
attr Rep.WindowOpenTime reading state
attr Rep.WindowOpenTime showproctime 1
attr Rep.WindowOpenTime sqlResultFormat sline
attr Rep.WindowOpenTime event-on-update-reading state
attr Rep.WindowOpenTime userExitFn SwitchQueryResult
</pre>

Ganz wichtig ist die Zeile '''attr Rep.powerOnTime userExitFn SwitchQueryResult'''. Hier ist die Funktion '''SwitchQueryResult()''' angegeben, die nach erfolgreicher Bearbeitung der SQL-Query aufgerufen wird. Diese Funktion wird ebenfalls in der 99_myUtils.pm eingefügt:

<source lang="perl">
##########################################################################################################
# This function will be called from the DbRep device if the attribute
# attr Name_of_your_DbRep_device userExitFn SwitchQueryResult is set.
# This function create a new reading "LastOpenTime" at the device for which the query is done and
# set the cumulated time difference in seconds to the reading.
##########################################################################################################
sub SwitchQueryResult($$$) {
my ($name,$reading,$value) = @_; # $name is the name of the DbRep device which is calling this function
my $hash = $defs{$name};

# DbRep calls this function several times with different informations.
# if $reading is SqlResult, $value will hold the result of the query
if ($reading eq "SqlResult") {
my ($dev,$val) = split('\|',$value); # split the result in two parts
$dev = $dev?$dev:"";
$val = $val?$val:"";
if (!$val) {
$val = 0;
}
$val = DbRep_sec2hms($val); # calculate seconds to hms
Log3 $name , 5, "DbRep $name - SwitchQueryResult splitted result: $dev $val";

fhem("setreading $dev LastOpenTime $val") if($dev); # set the reading "LastOpenTime" with the time if device-Log was found
}

return;
}
</source>

Die Funktion SwitchQueryResult() rechnet das Ergebnis der query aus dem DbRep Device von Sekunden in das Format hh:mm:ss um und trägt die berechnete Zeit als Reading "'''LastOpenTime'''" im jeweiligen Fensterkontakt ein.

So kann man z.B. im Device mit dem Namen "eg.bad.fenster" das Reading "'''LastOpenTime 00:03:58'''" finden.
Die vorliegende Berechnung liefert immer die Zeit des letzten Öffnungszyklus des aktuellen Tages. Möchte man die Zeiten des gesamten Tages akkumulieren, kann nach der Beschreibung "[[Summe aller Einschaltzeiten eines Gerätes]]" verfahren werden.

[[Kategorie:Logging]]

Batterieüberwachung

2017-12-12T08:10:12Z

Caldir65:

Verschiedene batteriebetriebene Geräte ([[:Kategorie:HomeMatic Components|Homematic]], RFXtrx, ZWave,..) übermitteln unter anderem den Zustand der eingelegten Batterie. Bei diesen kann der Batteriestatus übersichtlich dargestellt und / oder aktiv überwacht werden. Bei Geräten ohne eigenen Batteriestatus muss man diesen "nachrüsten".

== Geräte mit Batteriestatus ==
=== Übersichtsdarstellung per readingsGroup ===
Mit Hilfe einer ReadingsGroup kann einfach eine Übersicht aller Geräte mit "battery"-Reading erstellt werden, s. [[ReadingsGroup#Auswahl_.C3.BCber_Reading-Namen.2C_Status_als_Symbol_dargestellt|hier]].

=== Benachrichtigung per notify ===
Um Ausfälle frühzeitig zu erkennen, kann man sich per E-Mail benachrichtigen lassen, sobald eine Batteriemeldung mit etwas anderem als "ok" gesendet wird (z.B. "low"). Zusätzlich erzeugt der unten stehende Code einen Eintrag im Logfile.

<nowiki>define n_batt_chk notify .*:[Bb]attery.* { if ($EVENT !~ m/ok/) { \
{ FB_mail('recipient@internet.de', 'FHEM Batteriewarnung', $NAME.': '.$EVENT)};; \
Log 3, "$NAME : Batteriewarnung $EVENT";; \
} \
}</nowiki>

'''Achtung:''' Für Nutzer eines [[HM-CC-RT-DN_Funk-Heizk%C3%B6rperthermostat|HM-CC-RT-DN]] muss der Code anders aussehen, da mit diesem Thermostat erstmalig der aktuelle Spannungswert der Batterie gesendet wird, also z.B.:

UG.Treppe.Heizung batteryLevel: 3.1 V

Man würde bei der Verwendung des o.g. Codes bei jeder Batteriemeldung eines HM-CC-RT-DN eine E-Mail erhalten. Daher muss der o.g. Code wie folgt geändert werden (Doppelpunkt hinter "[Bb]attery"):

<nowiki>define n_batt_chk notify .*:[Bb]attery:.* { if($EVENT !~ m/ok/) { \
{ FB_mail('recipient@internet.de', 'FHEM Batteriewarnung', $NAME.': '.$EVENT)};; \
Log 3, "$NAME: Batteriewarnung $EVENT";; \
} \
}</nowiki>

Achtung: FB_mail setzt die Installation auf einer FritzBox voraus. Für andere Hardware-/OS-Plattformen ist die Vorgehensweise unter dem Titel [[E-Mail_senden]] beschrieben.

Wer statt einer email lieber eine Pushover-Nachricht auf sein Smartphone bekommen möchte, kann diesen Code benutzen:

<nowiki>define n_batt_chk notify .*:[Bb]attery:.* { if($EVENT !~ m/ok/) { \
{ fhem ("set PushoverChristoph msg FHEM Batteriewarnung, $NAME: $EVENT:\nBatterien sollten demnächst gewechselt werden!");; \
Log 3, "$NAME: Batteriewarnung $EVENT";; \
} \
} \
}</nowiki>

Natürlich muß dafür eine Pushover-Installation in fhem vorhanden sein - sonst bitte gem. [[Pushover]] nachholen.

Testen kann man dies z.B. mit <code>trigger HeizungWZ Battery:low</code>

Man sollte auch darauf achten, dass sich das Ereignis, auf das man triggert, nicht zu häufig wiederholt (z.B. durch das Attribut <code>event-on-change-reading</code>).

== Geräte ohne Batteriestatus ==
Bei Geräten ohne Reading für den Batteriestatus kann man diesen auf verschiedene Weisen schätzen und als Reading eintragen. Dies funktioniert aber natürlich nur, wenn das Gerät sendet - bei einem rein empfangenden Aktor wie dem [[FHT 8v direkt ansprechen|FHT Stellantrieb]] klappt es also nicht...

=== Erweiterung des Geräts um battery-Reading ===
Mit Hilfe von [http://fhem.de/commandref_DE.html#userReadings userReadings] kann man recht einfach einen Batteriestatus schätzen und als Reading bereitstellen. Dann greift auch direkt die oben beschriebene Auswertung.

Die Idee ist, den zeitlichen Abstand des aktuellen Timestamps mit dem letzten geloggten Timestamp zu vergleichen und daraus auf den Batteriestatus zu schliessen - bspw. Abstand > 10min = Batterie low.

Dazu muss lediglich folgendes userReading für jedes batteriebetriebene Device (ohne Batteriestatus) angelegt werden (um bei >10min "low" zu setzen):

; Konfiguration:
Lediglich der Schwellwert (600) braucht nach Wunsch angepasst zu werden, alles andere passt automatisch (vgl. [[Notify#Hinweise]]).

; Im Webinterface:
<pre>
battery { return "ok" if ( (time_str2num(ReadingsTimestamp($NAME,"state","0")) - time_str2num(OldTimestamp($NAME))) < 600 ); return "low" }
</pre>

; Alternativ im Config-File:
<pre>
attr MeinSensor userReadings battery { return "ok" if ( (time_str2num(ReadingsTimestamp($NAME,"state","0")) - time_str2num(OldTimestamp($NAME))) < 600 ); return "low" }
</pre>

; Erläuterung:
: <code>$NAME</code> - ist die Variable für das Device (und braucht nicht angepasst zu werden)
: <code>battery {...}</code> - Name des userreadings mit Spezifikation, vgl. [http://fhem.de/commandref_DE.html#userReadings]
: <code>return "ok" if ( ... ); return "low"</code> - Spezifikation: Reading = "ok", wenn if erfüllt, sonst "low"
: <code>time_str2num(ReadingsTimestamp($NAME,"state","0")</code> - Aktueller Timestamp in Sekunden, vgl. [http://fhem.de/commandref_DE.html#perl], [[Notify#Hinweise]]
: <code>time_str2num(OldTimestamp($NAME))</code> - Letzter Timestamp im Log in Sekunden (egal ob FileLog oder DbLog), vgl. [http://fhem.de/commandref_DE.html#perl], [[Notify#Hinweise]]
: <code>600</code> - Schwellwert für "low" (600 sec = 10 min), nach Bedarf anpassen

=== Alternativ per Skript ===
Andere Komponenten, wie z. B. [[:Kategorie:FS20 Components|FS20 Komponenten]], übermitteln keinen Batteriestatus.

Um dort dennoch einen Test darauf zu machen, ob die Batterie evtl. leer ist, kann man z. B. prüfen, wann der letzte Status des jeweiligen Gerätes empfangen wurde, etwa mit folgender Funktion in [[99_myUtils_anlegen|99_myUtils.pm]]:

<pre>sub check_if_alive($$) {
# Expects:
# 1. Devicename to be checked
# 2. Age in hours, after the expiry of which with no new state the device will be considered as dead.
# Returns:
# 0 -> Device dead
# 1 -> Device alive
# 2 -> Error
my ($Device,$hours_threshold) = @_;
my ($Device) = @_;
my $now = time;
my $Timestamp = ReadingsTimestamp($Device,"state","0");
if ($Timestamp eq "0") {
return 2;
}

my @splitdatetime = split(/ /,$Timestamp);
my @splitdate = split(/-/, $splitdatetime[0]);
my @splittime = split(/:/, $splitdatetime[1]);
my $last_state_time = timelocal($splittime[2], $splittime[1], $splittime[0], $splitdate[2], $splitdate[1]-1, $splitdate[0]);
my $age_in_hours = ($now - $last_state_time) / 3600;

if ($age_in_hours > $hours_threshold) {
Log 1, ("check_if_alive: $Device dead, last state was $age_in_hours hours ago");
return 0;
} else {
return 1;
}

}</pre>

Diese Funktion kann man z.B. in einem at je zu prüfendem Gerät regelmäßig (z. B. einmal am Tag um 05:55 Uhr) aufrufen, und testen, ob die letzten 12 Stunden etwas empfangen wurde:

<pre>*05:55:55 {
check_if_alive("KS300", 12);
}</pre>

KS300 ist dabei der Name des Devices in fhem.

Wenn das Gerät nicht geantwortet hat, erzeugt die oben vorgeschlagene Funktion einen Logeintrag.

Hinweis: Dieser Batterietest schlägt natürlich auch an, wenn die FS20 Geräte noch funktionieren, aber der CUL zum Empfangen der Signale nicht mehr funktioniert. In dem Fall sind dann auf einen Schlag angeblich alle Batterien leer. Um dies zumindest teilweise abzufangen, könnte man vor dem Erzeugen des Logeintrags noch auf den state des CUL testen, dass dieser nicht "disconnected" ist.

==== Visualisierung ====
Der Abschnitt Links unten enthält einen Verweis, wie man den Batteriestatus visuell anzeigen kann. Das funktioniert mit der oben vorgeschlagenen Funktion mit einigen Ergänzungen auch, wenn das Gerät selbst keinen Batteriestatus anzeigt.

Dafür braucht man einen zusätzlichen Dummy je zu überwachendem Gerät, mit dem Namen dum_<zu_überwachendes_Gerät>_dead. Für das Gerät KS300 heißt dieser dummy also z. B. dum_KS300_dead:

<pre>Internals:
NAME dum_KS300_dead
NR 795
STATE nein
TYPE dummy
Readings:
2015-04-28 07:47:48 state nein
Attributes:
devStateIcon ja:measure_battery_50@red nein:measure_battery_100@green</pre>

Dieser dummy soll hier die Zustände "ja" und "nein" annehmen können. Bei ja ist ihm über devStateIcon ein rotes Icon einer eher leeren Batterie zugewiesen, bei nein ein grünes Icon einer vollen Batterie.

Nun muss noch die oben vorgeschlagene Funktion angepasst werden, um den Zustand des dummy entsprechend dem ermittelten Batteriestatus neu zu setzen. Dafür wird die Abfrage des Alters am Ende der Funktion um eine Zeile erweitert, die den Status des dummy setzt:

<pre> if ($age_in_hours > $hours_threshold) {
Log 1, ("check_if_alive: $Device dead, last state was $age_in_hours hours ago");
fhem("set dum_".$Device."_dead ja");
return 0;
} else {
fhem("set dum_".$Device."_dead nein");
return 1;
}</pre>

Den Dummy mit diesem devStateIcon kann man so der unter "Links" unten vorgeschlagenen readingsGroup hinzufügen, und damit auch Geräte ohne eigenen Batteriestatus überwachen.

== Links ==
* [[ReadingsGroup#Auswahl_.C3.BCber_Reading-Namen.2C_Status_als_Symbol_dargestellt|visuelle Batterieüberwachung mit readingsGroup]]
* [http://fhem.de/commandref_DE.html#userReadings commandref - userReadings]
* [http://fhem.de/commandref_DE.html#perl commandref - Perl specials]
* [[Notify#Hinweise|Hinweise zu Variablen]] (ansonsten auch an div. Stellen in der [http://fhem.de/commandref_DE.html commandref])

[[Kategorie:HOWTOS]]

HM-ES-TX-WM Zählersensor für Strom- und Gaszähler

2016-02-17T15:03:24Z

Caldir65: Bsp. für usereadings GAS etwas verallgemeinert

{{Infobox Hardware
|Bild=HM-EM-TX-WM.jpg
|Bildbeschreibung=HomeMatic Zählersensor
|HWProtocol=HomeMatic
|HWType=Powersensor
|HWCategory=HomeMatic
|HWComm=868 MHz
|HWChannels=1
|HWVoltage=6 V
|HWPowerConsumption=30 mA
|HWPoweredBy=4 Batterien LR6/AA/Mignon
|HWSize=68x105x30mm
|HWDeviceFHEM=[http://fhem.de/commandref.html#CUL_HM CUL_HM]
|HWManufacturer=ELV / eQ-3
}}

'''Dieses Device ist seit Anfang Feb. 2015 als Bausatz auf dem Markt - dieser Artikel ist im Aufbau - bitte Verständnis für Unvollständigkeiten und fehlende Bereiche '''

== Features ==
Der Zählersensor ist ein Datenerfassungssystem, das den Energieverbräuche (Strom, Gas) direkt am Zähler erfasst und in FHEM als laufender Saldo und als Momentanwerte verfügbar macht.

'''Technische Daten:'''

Gewicht: 195 g (inkl. 4 LR6/Mignon/AA-Batterien)

== Anwendungsszenarien ==
Mit den erfassten und gesammelten Daten lassen sich Aktionen beim Erreichen bestimmter Schwellwerte auslösen, Verbrauchs- und Kostenstatistiken ableiten sowie beliebige weitere Abhängigkeiten bilden. Durch die Funkdatenübertragung sowie den Batteriebetrieb (1 bis 2 Jahre Betriebsdauer verspricht der Hersteller mit einem Satz) ist die Installation denkbar einfach und erfordert lediglich beim Anbringen der Leseeinheit Genauigkeit.

Aktuell (Feb. 2015) hat die Auslieferung der Geräte als (einfacher) Bausatz begonnen, zu dem es einen Ferraris-Sensor (für Stromzähler mit den markanten Laufscheiben), LED-Sensor (für neue Zähler mit S0-Schnittstelle) sowie BK-G4-Gaszähler von Elster-Kromschröder, die an einer Ziffernrolle einen kleinen Magneten haben, der über einen Sensor mit Reedkontakt erfasst wird. Es ist laut Hersteller [http://www.elv.de/homematic-zaehlersensor-strom-gas-bausatz.html ELV] nur der Bausatz verfügbar. Ein Fertiggerät ist aktuell nicht geplant.

Die Zähler werden mit rückstandslos entfernbaren Klebepads angebracht.

== Parameter ==
'''list: register | range | peer | description'''
0: pairCentral | 0 to 16777215 | | pairing to central
1: mtrConstGas | 0 to 655.36 | | constant gas
1: mtrConstIr | 0 to 65536 | | constant IR
1: mtrConstLed | 0 to 65536 | | constant led
1: mtrSensIr | -99 to 99 | | sensiblity IR
1: mtrType | literal | | type of measurement options:LED,gas,unknown,IR

== Probleme ==

Der HM-ES-TX-WM sendet zyklisch im 3-Minuten Takt die aktuellsten Verbrauchsdaten. Dabei ist für das Reading "power" (aktuelle Stromleistung in Watt) zu beachten, dass aller 3 Minuten nur der zuletzt bekannte Wert gesendet. Das heisst im besonderen:

* sollten innerhalb der 3 Minuten mehrfache Impulse auftreten mit unterschiedlichen Leistungswerten, wird nur der zuletzt bekannte Wert genommen. Es findet keine Aggregation aller Impulse wie z.B. Mittelwert o.ä. statt.
* sollten innerhalb der 3 Minuten keinerlei Impulse auftreten, wird dennoch der zuletzt bekannte Leistungswert gesendet, auch wenn er mehrere Minuten/Stunden/Tage alt ist.

== Betrieb mit FHEM ==
Der Sensor wird mit einem FHEM im Update-Stand vom (mindestens) 7.2.2015 funktionsfähig eingebunden (getestet in der Variante mit Feraris-Fühler). Es werden der Fühlertyp und die Fühlerkonstante richtig ausgelesen und im Reading Energy die errechnete Energiemenge ausgegeben (bei Strom: Wattstunden, Wh).

Für die perfekte Konfiguration wird auf [[Heizleistung_und_Gasverbrauch]] verwiesen, wo eine vollständige Lösung für die Umrechnung von Gasverbrauch in kW/h, Graphen und Hilfsprogramme vorgestellt wird.

=== Readings ===
'''Reading: |Beispiel'''
D-firmware |1.0
D-serialNr |MEQ0025452
battery |ok
boot |off
current |0
eState |E: 6199.9 P: 1713 I: 0 U: 0 f: 50
energy |6199.9
energyOffset |84413.2
frequency |50
power |1713
powerOn |2015-03-26 14:57:48
voltage |0

=== Events Auszug ===
'''Event |Beispielswert'''
battery* |ok
energy |10186.6
power |283
current |0
voltage |0
frequency |50
eState |E: 10186.6 P: 283 I: 0 U: 0 f: 50
boot |off

<nowiki>*</nowiki> - Ein battery-Event wird nicht zyklisch getriggert. Erst wenn die Batterie tatsächlich leer ist, wird eine entsprechende Meldung vom Gerät selber gesendet und ein battery-Event getriggert (battery: low).

Mit einem Userreading lässt sich die Angabe aus Energy zum Beispiel für einen Stromzähler (Wh) in die auf dem Zähler übliche Angabe kWh umrechnen und zugleich mit dem Aufaddieren des Unterschieds beim Start (das Zählermodul beginnt ja mit 0 Wh, während der Zähler meist schon einige Jahre auf der "Rolle" hat) die Angaben gleichziehen:

attr <DeviceName> userReadings kWh {sprintf("%.1f",ReadingsVal("<DeviceName>","energy","???")/1000+72031.5639)}

=== Konfiguration ===
Nach dem Erkennen durch [[autocreate]] wird der Zählersensor mit diesen Angaben eingebunden:

define CUL_HM_HM_ES_TX_WM_353594 CUL_HM 353594
attr CUL_HM_HM_ES_TX_WM_353594 IODev CUL_0
attr CUL_HM_HM_ES_TX_WM_353594 actCycle 000:10
attr CUL_HM_HM_ES_TX_WM_353594 actStatus alive
attr CUL_HM_HM_ES_TX_WM_353594 expert 2_full
attr CUL_HM_HM_ES_TX_WM_353594 firmware 1.0
attr CUL_HM_HM_ES_TX_WM_353594 model HM-ES-TX-WM
attr CUL_HM_HM_ES_TX_WM_353594 subType powerSensor

Für den Betrieb mit den verschiedenen Zählern muß eines der Readings '''R-mtrConst'''XXX auf den jeweiligen verwendeten Zähler konfiguriert werden. Z.B. kann ein Ferraris-Stromzähler 100, 150 oder 200 Umdrehungen je kWh benötigen. Dies geschieht z.B. für 150 Meldungen je Einheit für einen Ferraris-Zähler mit dem Befehl

set CUL_HM_HM_ES_TX_WM_353594 regSet mtrConstIr 150

oder für einen Gaszähler auf der 1. Rolle (d.h. 1 Impuls je 0.1 m^3)

set CUL_HM_HM_ES_TX_WM_353594 regSet mtrConstGas 0.1

In fhem bis zum Anfang November 2015 war hier ein kleiner Bug enthalten, der diesen Wert nicht akzeptierte. In diesem Fall läßt sich die Anzahl der Impulse direkt am Gerät über das Display einstellen.

== Logging/Graph. Darstellung ==
[[Datei:PlotStromverbrauchProStunde.png|mini|400px|rechts|Beispiel der graph. Darstellung]]
Der Zähler wird ja fortlaufend aufaddiert. Mit der delta-Funktion von SVG-Plot können die Verbräuche sehr gut visualisiert werden.
Beispiel Stromzähler:

set terminal png transparent size <SIZE> crop
set output '<OUT>.png'
set xdata time
set timefmt "%Y-%m-%d_%H:%M:%S"
set xlabel " "
set title 'Stündlicher Stromverbrauch | aktuell: $data{currval1} ($data{min1} / $data{avg1} / $data{max1}) kWh'
set ytics
set y2tics
set grid ytics
set ylabel "kWh/h"
set y2label "kWh/h"
#FileLog 4:CUL_HM_HM_ES_TX_WM_353594.kWh\x3a:0:delta-h
plot "<IN>" using 1:2 axes x1y2 title 'Line 1' ls l0 lw 2 with bars

== Links ==
* Handbuch: [http://files.elv.de/Assets/Produkte/14/1401/140143/Downloads/140143_sensor_um.pdf]
* Produktseite ELV: [http://www.elv.de/homematic-zaehlersensor-strom-gas-bausatz.html]

[[Kategorie:HomeMatic Components]]
[[Kategorie:Energieverbrauchsmessung]]
[[Kategorie:Energieerzeugungsmessung]]

HM-ES-TX-WM Zählersensor für Strom- und Gaszähler

2016-02-17T14:59:53Z

Caldir65:

{{Infobox Hardware
|Bild=HM-EM-TX-WM.jpg
|Bildbeschreibung=HomeMatic Zählersensor
|HWProtocol=HomeMatic
|HWType=Powersensor
|HWCategory=HomeMatic
|HWComm=868 MHz
|HWChannels=1
|HWVoltage=6 V
|HWPowerConsumption=30 mA
|HWPoweredBy=4 Batterien LR6/AA/Mignon
|HWSize=68x105x30mm
|HWDeviceFHEM=[http://fhem.de/commandref.html#CUL_HM CUL_HM]
|HWManufacturer=ELV / eQ-3
}}

'''Dieses Device ist seit Anfang Feb. 2015 als Bausatz auf dem Markt - dieser Artikel ist im Aufbau - bitte Verständnis für Unvollständigkeiten und fehlende Bereiche '''

== Features ==
Der Zählersensor ist ein Datenerfassungssystem, das den Energieverbräuche (Strom, Gas) direkt am Zähler erfasst und in FHEM als laufender Saldo und als Momentanwerte verfügbar macht.

'''Technische Daten:'''

Gewicht: 195 g (inkl. 4 LR6/Mignon/AA-Batterien)

== Anwendungsszenarien ==
Mit den erfassten und gesammelten Daten lassen sich Aktionen beim Erreichen bestimmter Schwellwerte auslösen, Verbrauchs- und Kostenstatistiken ableiten sowie beliebige weitere Abhängigkeiten bilden. Durch die Funkdatenübertragung sowie den Batteriebetrieb (1 bis 2 Jahre Betriebsdauer verspricht der Hersteller mit einem Satz) ist die Installation denkbar einfach und erfordert lediglich beim Anbringen der Leseeinheit Genauigkeit.

Aktuell (Feb. 2015) hat die Auslieferung der Geräte als (einfacher) Bausatz begonnen, zu dem es einen Ferraris-Sensor (für Stromzähler mit den markanten Laufscheiben), LED-Sensor (für neue Zähler mit S0-Schnittstelle) sowie BK-G4-Gaszähler von Elster-Kromschröder, die an einer Ziffernrolle einen kleinen Magneten haben, der über einen Sensor mit Reedkontakt erfasst wird. Es ist laut Hersteller [http://www.elv.de/homematic-zaehlersensor-strom-gas-bausatz.html ELV] nur der Bausatz verfügbar. Ein Fertiggerät ist aktuell nicht geplant.

Die Zähler werden mit rückstandslos entfernbaren Klebepads angebracht.

== Parameter ==
'''list: register | range | peer | description'''
0: pairCentral | 0 to 16777215 | | pairing to central
1: mtrConstGas | 0 to 655.36 | | constant gas
1: mtrConstIr | 0 to 65536 | | constant IR
1: mtrConstLed | 0 to 65536 | | constant led
1: mtrSensIr | -99 to 99 | | sensiblity IR
1: mtrType | literal | | type of measurement options:LED,gas,unknown,IR

== Probleme ==

Der HM-ES-TX-WM sendet zyklisch im 3-Minuten Takt die aktuellsten Verbrauchsdaten. Dabei ist für das Reading "power" (aktuelle Stromleistung in Watt) zu beachten, dass aller 3 Minuten nur der zuletzt bekannte Wert gesendet. Das heisst im besonderen:

* sollten innerhalb der 3 Minuten mehrfache Impulse auftreten mit unterschiedlichen Leistungswerten, wird nur der zuletzt bekannte Wert genommen. Es findet keine Aggregation aller Impulse wie z.B. Mittelwert o.ä. statt.
* sollten innerhalb der 3 Minuten keinerlei Impulse auftreten, wird dennoch der zuletzt bekannte Leistungswert gesendet, auch wenn er mehrere Minuten/Stunden/Tage alt ist.

== Betrieb mit FHEM ==
Der Sensor wird mit einem FHEM im Update-Stand vom (mindestens) 7.2.2015 funktionsfähig eingebunden (getestet in der Variante mit Feraris-Fühler). Es werden der Fühlertyp und die Fühlerkonstante richtig ausgelesen und im Reading Energy die errechnete Energiemenge ausgegeben (bei Strom: Wattstunden, Wh).

Für die perfekte Konfiguration wird auf [[Heizleistung_und_Gasverbrauch]] verwiesen, wo eine vollständige Lösung für die Umrechnung von Gasverbrauch in kW/h, Graphen und Hilfsprogramme vorgestellt wird.

=== Readings ===
'''Reading: |Beispiel'''
D-firmware |1.0
D-serialNr |MEQ0025452
battery |ok
boot |off
current |0
eState |E: 6199.9 P: 1713 I: 0 U: 0 f: 50
energy |6199.9
energyOffset |84413.2
frequency |50
power |1713
powerOn |2015-03-26 14:57:48
voltage |0

=== Events Auszug ===
'''Event |Beispielswert'''
battery* |ok
energy |10186.6
power |283
current |0
voltage |0
frequency |50
eState |E: 10186.6 P: 283 I: 0 U: 0 f: 50
boot |off

<nowiki>*</nowiki> - Ein battery-Event wird nicht zyklisch getriggert. Erst wenn die Batterie tatsächlich leer ist, wird eine entsprechende Meldung vom Gerät selber gesendet und ein battery-Event getriggert (battery: low).

Mit einem Userreading lässt sich die Angabe aus Energy zum Beispiel für einen Stromzähler (Wh) in die auf dem Zähler übliche Angabe kWh umrechnen und zugleich mit dem Aufaddieren des Unterschieds beim Start (das Zählermodul beginnt ja mit 0 Wh, während der Zähler meist schon einige Jahre auf der "Rolle" hat) die Angaben gleichziehen:

attr <DeviceName> userReadings kWh {sprintf("%.1f",ReadingsVal("CUL_HM_HM_ES_TX_WM_353594","energy","???")/1000+72031.5639)}

=== Konfiguration ===
Nach dem Erkennen durch [[autocreate]] wird der Zählersensor mit diesen Angaben eingebunden:

define CUL_HM_HM_ES_TX_WM_353594 CUL_HM 353594
attr CUL_HM_HM_ES_TX_WM_353594 IODev CUL_0
attr CUL_HM_HM_ES_TX_WM_353594 actCycle 000:10
attr CUL_HM_HM_ES_TX_WM_353594 actStatus alive
attr CUL_HM_HM_ES_TX_WM_353594 expert 2_full
attr CUL_HM_HM_ES_TX_WM_353594 firmware 1.0
attr CUL_HM_HM_ES_TX_WM_353594 model HM-ES-TX-WM
attr CUL_HM_HM_ES_TX_WM_353594 subType powerSensor

Für den Betrieb mit den verschiedenen Zählern muß eines der Readings '''R-mtrConst'''XXX auf den jeweiligen verwendeten Zähler konfiguriert werden. Z.B. kann ein Ferraris-Stromzähler 100, 150 oder 200 Umdrehungen je kWh benötigen. Dies geschieht z.B. für 150 Meldungen je Einheit für einen Ferraris-Zähler mit dem Befehl

set CUL_HM_HM_ES_TX_WM_353594 regSet mtrConstIr 150

oder für einen Gaszähler auf der 1. Rolle (d.h. 1 Impuls je 0.1 m^3)

set CUL_HM_HM_ES_TX_WM_353594 regSet mtrConstGas 0.1

In fhem bis zum Anfang November 2015 war hier ein kleiner Bug enthalten, der diesen Wert nicht akzeptierte. In diesem Fall läßt sich die Anzahl der Impulse direkt am Gerät über das Display einstellen.

== Logging/Graph. Darstellung ==
[[Datei:PlotStromverbrauchProStunde.png|mini|400px|rechts|Beispiel der graph. Darstellung]]
Der Zähler wird ja fortlaufend aufaddiert. Mit der delta-Funktion von SVG-Plot können die Verbräuche sehr gut visualisiert werden.
Beispiel Stromzähler:

set terminal png transparent size <SIZE> crop
set output '<OUT>.png'
set xdata time
set timefmt "%Y-%m-%d_%H:%M:%S"
set xlabel " "
set title 'Stündlicher Stromverbrauch | aktuell: $data{currval1} ($data{min1} / $data{avg1} / $data{max1}) kWh'
set ytics
set y2tics
set grid ytics
set ylabel "kWh/h"
set y2label "kWh/h"
#FileLog 4:CUL_HM_HM_ES_TX_WM_353594.kWh\x3a:0:delta-h
plot "<IN>" using 1:2 axes x1y2 title 'Line 1' ls l0 lw 2 with bars

== Links ==
* Handbuch: [http://files.elv.de/Assets/Produkte/14/1401/140143/Downloads/140143_sensor_um.pdf]
* Produktseite ELV: [http://www.elv.de/homematic-zaehlersensor-strom-gas-bausatz.html]

[[Kategorie:HomeMatic Components]]
[[Kategorie:Energieverbrauchsmessung]]
[[Kategorie:Energieerzeugungsmessung]]

Diskussion:HM-EM-TX-WM Zählersensor für Strom- und Gaszähler

2016-02-17T14:57:41Z

Caldir65: Caldir65 verschob die Seite Diskussion:HM-EM-TX-WM Zählersensor für Strom- und Gaszähler nach Diskussion:HM-ES-TX-WM Zählersensor für Strom- und Gaszähler: HM-Bezeichnung im Seiten-Namen korrigiert

#WEITERLEITUNG [[Diskussion:HM-ES-TX-WM Zählersensor für Strom- und Gaszähler]]

Diskussion:HM-ES-TX-WM Zählersensor für Strom- und Gaszähler

2016-02-17T14:57:41Z

== Falscher Seitentitel? / Graphenerstellung ==
Sollte der Sensor nicht HM-ES-TX-WM heißen?

Frage: im Graphen wird der Titel auf

aktuell: $data{curval1} ($data{min1} / $data{avg1} / $data{max1}) kWh

gesetzt. Welches Modul erzeugt wie diesen Titel? Mit dem Einbinden des Statistik-Moduls alleine scheint es ja nicht getan zu sein....?
--[[Benutzer:Morgennebel|Morgennebel]] ([[Benutzer Diskussion:Morgennebel|Diskussion]]) 14:19, 29. Sep. 2015 (CEST)
<HR>
:Der Seitentitel=Sensorname ist auch mMn falsch (http://www.elv.de/HomeMatic%C2%AE-Energiez%C3%A4hler-Erfassungssystem/x.aspx/cid_726/detail_50043). Sie Seite müsste verschoben werden. (Peter?)
:
:Das sind "normale" get-Abfragen für FileLog ([[Creating_Plots#Data_Extraction]])
:Gruß, --[[Benutzer:Krikan|Christian]] ([[Benutzer Diskussion:Krikan|Diskussion]]) 14:53, 29. Sep. 2015 (CEST)

HM-EM-TX-WM Zählersensor für Strom- und Gaszähler

2016-02-17T14:57:41Z

Caldir65: Caldir65 verschob die Seite HM-EM-TX-WM Zählersensor für Strom- und Gaszähler nach HM-ES-TX-WM Zählersensor für Strom- und Gaszähler: HM-Bezeichnung im Seiten-Namen korrigiert

#WEITERLEITUNG [[HM-ES-TX-WM Zählersensor für Strom- und Gaszähler]]

HM-ES-TX-WM Zählersensor für Strom- und Gaszähler

2016-02-17T14:57:41Z

Caldir65: Caldir65 verschob die Seite HM-EM-TX-WM Zählersensor für Strom- und Gaszähler nach HM-ES-TX-WM Zählersensor für Strom- und Gaszähler: HM-Bezeichnung im Seiten-Namen korrigiert

{{Infobox Hardware
|Bild=HM-ES-TX-WM.jpg
|Bildbeschreibung=HomeMatic Zählersensor
|HWProtocol=HomeMatic
|HWType=Powersensor
|HWCategory=HomeMatic
|HWComm=868 MHz
|HWChannels=1
|HWVoltage=6 V
|HWPowerConsumption=30 mA
|HWPoweredBy=4 Batterien LR6/AA/Mignon
|HWSize=68x105x30mm
|HWDeviceFHEM=[http://fhem.de/commandref.html#CUL_HM CUL_HM]
|HWManufacturer=ELV / eQ-3
}}

'''Dieses Device ist seit Anfang Feb. 2015 als Bausatz auf dem Markt - dieser Artikel ist im Aufbau - bitte Verständnis für Unvollständigkeiten und fehlende Bereiche '''

== Features ==
Der Zählersensor ist ein Datenerfassungssystem, das den Energieverbräuche (Strom, Gas) direkt am Zähler erfasst und in FHEM als laufender Saldo und als Momentanwerte verfügbar macht.

'''Technische Daten:'''

Gewicht: 195 g (inkl. 4 LR6/Mignon/AA-Batterien)

== Anwendungsszenarien ==
Mit den erfassten und gesammelten Daten lassen sich Aktionen beim Erreichen bestimmter Schwellwerte auslösen, Verbrauchs- und Kostenstatistiken ableiten sowie beliebige weitere Abhängigkeiten bilden. Durch die Funkdatenübertragung sowie den Batteriebetrieb (1 bis 2 Jahre Betriebsdauer verspricht der Hersteller mit einem Satz) ist die Installation denkbar einfach und erfordert lediglich beim Anbringen der Leseeinheit Genauigkeit.

Aktuell (Feb. 2015) hat die Auslieferung der Geräte als (einfacher) Bausatz begonnen, zu dem es einen Ferraris-Sensor (für Stromzähler mit den markanten Laufscheiben), LED-Sensor (für neue Zähler mit S0-Schnittstelle) sowie BK-G4-Gaszähler von Elster-Kromschröder, die an einer Ziffernrolle einen kleinen Magneten haben, der über einen Sensor mit Reedkontakt erfasst wird. Es ist laut Hersteller [http://www.elv.de/homematic-zaehlersensor-strom-gas-bausatz.html ELV] nur der Bausatz verfügbar. Ein Fertiggerät ist aktuell nicht geplant.

Die Zähler werden mit rückstandslos entfernbaren Klebepads angebracht.

== Parameter ==
'''list: register | range | peer | description'''
0: pairCentral | 0 to 16777215 | | pairing to central
1: mtrConstGas | 0 to 655.36 | | constant gas
1: mtrConstIr | 0 to 65536 | | constant IR
1: mtrConstLed | 0 to 65536 | | constant led
1: mtrSensIr | -99 to 99 | | sensiblity IR
1: mtrType | literal | | type of measurement options:LED,gas,unknown,IR

== Probleme ==

Der HM-ES-TX-WM sendet zyklisch im 3-Minuten Takt die aktuellsten Verbrauchsdaten. Dabei ist für das Reading "power" (aktuelle Stromleistung in Watt) zu beachten, dass aller 3 Minuten nur der zuletzt bekannte Wert gesendet. Das heisst im besonderen:

* sollten innerhalb der 3 Minuten mehrfache Impulse auftreten mit unterschiedlichen Leistungswerten, wird nur der zuletzt bekannte Wert genommen. Es findet keine Aggregation aller Impulse wie z.B. Mittelwert o.ä. statt.
* sollten innerhalb der 3 Minuten keinerlei Impulse auftreten, wird dennoch der zuletzt bekannte Leistungswert gesendet, auch wenn er mehrere Minuten/Stunden/Tage alt ist.

== Betrieb mit FHEM ==
Der Sensor wird mit einem FHEM im Update-Stand vom (mindestens) 7.2.2015 funktionsfähig eingebunden (getestet in der Variante mit Feraris-Fühler). Es werden der Fühlertyp und die Fühlerkonstante richtig ausgelesen und im Reading Energy die errechnete Energiemenge ausgegeben (bei Strom: Wattstunden, Wh).

Für die perfekte Konfiguration wird auf [[Heizleistung_und_Gasverbrauch]] verwiesen, wo eine vollständige Lösung für die Umrechnung von Gasverbrauch in kW/h, Graphen und Hilfsprogramme vorgestellt wird.

=== Readings ===
'''Reading: |Beispiel'''
D-firmware |1.0
D-serialNr |MEQ0025452
battery |ok
boot |off
current |0
eState |E: 6199.9 P: 1713 I: 0 U: 0 f: 50
energy |6199.9
energyOffset |84413.2
frequency |50
power |1713
powerOn |2015-03-26 14:57:48
voltage |0

=== Events Auszug ===
'''Event |Beispielswert'''
battery* |ok
energy |10186.6
power |283
current |0
voltage |0
frequency |50
eState |E: 10186.6 P: 283 I: 0 U: 0 f: 50
boot |off

<nowiki>*</nowiki> - Ein battery-Event wird nicht zyklisch getriggert. Erst wenn die Batterie tatsächlich leer ist, wird eine entsprechende Meldung vom Gerät selber gesendet und ein battery-Event getriggert (battery: low).

Mit einem Userreading lässt sich die Angabe aus Energy zum Beispiel für einen Stromzähler (Wh) in die auf dem Zähler übliche Angabe kWh umrechnen und zugleich mit dem Aufaddieren des Unterschieds beim Start (das Zählermodul beginnt ja mit 0 Wh, während der Zähler meist schon einige Jahre auf der "Rolle" hat) die Angaben gleichziehen:

attr <DeviceName> userReadings kWh {sprintf("%.1f",ReadingsVal("CUL_HM_HM_ES_TX_WM_353594","energy","???")/1000+72031.5639)}

=== Konfiguration ===
Nach dem Erkennen durch [[autocreate]] wird der Zählersensor mit diesen Angaben eingebunden:

define CUL_HM_HM_ES_TX_WM_353594 CUL_HM 353594
attr CUL_HM_HM_ES_TX_WM_353594 IODev CUL_0
attr CUL_HM_HM_ES_TX_WM_353594 actCycle 000:10
attr CUL_HM_HM_ES_TX_WM_353594 actStatus alive
attr CUL_HM_HM_ES_TX_WM_353594 expert 2_full
attr CUL_HM_HM_ES_TX_WM_353594 firmware 1.0
attr CUL_HM_HM_ES_TX_WM_353594 model HM-ES-TX-WM
attr CUL_HM_HM_ES_TX_WM_353594 subType powerSensor

Für den Betrieb mit den verschiedenen Zählern muß eines der Readings '''R-mtrConst'''XXX auf den jeweiligen verwendeten Zähler konfiguriert werden. Z.B. kann ein Ferraris-Stromzähler 100, 150 oder 200 Umdrehungen je kWh benötigen. Dies geschieht z.B. für 150 Meldungen je Einheit für einen Ferraris-Zähler mit dem Befehl

set CUL_HM_HM_ES_TX_WM_353594 regSet mtrConstIr 150

oder für einen Gaszähler auf der 1. Rolle (d.h. 1 Impuls je 0.1 m^3)

set CUL_HM_HM_ES_TX_WM_353594 regSet mtrConstGas 0.1

In fhem bis zum Anfang November 2015 war hier ein kleiner Bug enthalten, der diesen Wert nicht akzeptierte. In diesem Fall läßt sich die Anzahl der Impulse direkt am Gerät über das Display einstellen.

== Logging/Graph. Darstellung ==
[[Datei:PlotStromverbrauchProStunde.png|mini|400px|rechts|Beispiel der graph. Darstellung]]
Der Zähler wird ja fortlaufend aufaddiert. Mit der delta-Funktion von SVG-Plot können die Verbräuche sehr gut visualisiert werden.
Beispiel Stromzähler:

set terminal png transparent size <SIZE> crop
set output '<OUT>.png'
set xdata time
set timefmt "%Y-%m-%d_%H:%M:%S"
set xlabel " "
set title 'Stündlicher Stromverbrauch | aktuell: $data{currval1} ($data{min1} / $data{avg1} / $data{max1}) kWh'
set ytics
set y2tics
set grid ytics
set ylabel "kWh/h"
set y2label "kWh/h"
#FileLog 4:CUL_HM_HM_ES_TX_WM_353594.kWh\x3a:0:delta-h
plot "<IN>" using 1:2 axes x1y2 title 'Line 1' ls l0 lw 2 with bars

== Links ==
* Handbuch: [http://files.elv.de/Assets/Produkte/14/1401/140143/Downloads/140143_sensor_um.pdf]
* Produktseite ELV: [http://www.elv.de/homematic-zaehlersensor-strom-gas-bausatz.html]

[[Kategorie:HomeMatic Components]]
[[Kategorie:Energieverbrauchsmessung]]
[[Kategorie:Energieerzeugungsmessung]]

HM-ES-TX-WM Zählersensor für Strom- und Gaszähler

2016-02-17T14:56:46Z

Caldir65: Korrektur Type-Bezeichnung in der Infobox

FHEM auf Raspberry PI mit COC betreiben

2015-07-05T11:55:28Z

Caldir65: /* FHEM Installieren */

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

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

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

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

== Raspberry OS auf die Speicherkarte übertragen ==
# Raspberry OS als Image von der Raspberry PI Webseite http://downloads.raspberrypi.org/raspbian_latest herunterladen
# Mit win32diskimager http://win32diskimager.sourceforge.net auf die Speicherkarte übertragen

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

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

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

SMAWechselrichter

2015-03-30T15:12:15Z

Caldir65: Installationsbefehl für die BT-Pakete zusammen gefasst ...

== Einbindung eines Wechselrichters von SMA in FHEM ==

Basierend auf diesem [http://forum.fhem.de/index.php/topic,14624.0.html Thread] im Fhem-Forum wird erklärt wie man seinen Wechselrichter von SMA in FHEM einbinden kann. Dafür kommt das Tool [http://sbfspot.codeplex.com/ SBFspot] (alter Name: SMASpot) zum Einsatz.

=== Vorbedingungen ===
Für die weitere Anleitung wird angenommen, dass FHEM auf einem RaspberryPi installiert wurde, funktioniert und genügend Platz für das kompilieren und die notwendigen Libraries zur Verfügung steht.

Die Tools make und g++ müssen installiert sein. Falls noch nicht vorhanden, müssen diese mit
:<code>sudo apt-get install make</code> und
:<code>sudo apt-get install g++</code> installiert werden.

=== Installation ===

==== Schritt 1 - Installation der notwendigen Libraries ====
Der Wechselrichter kann entweder per Bluetooth oder per Speedwire (Ethernet) ausgelesen werden. Unabhängig davon, wie der WR ausgelesen wird, müssen die folgenden Pakete installiert werden:
(Quelle: [http://sbfspot.codeplex.com/wikipage?title=SBFspot%20on%20Raspberry%20Pi&referringTitle=Documentation SBFSpot-Doku])

<pre>
sudo apt-get install bluetooth libbluetooth-dev libcurl3-dev libboost-all-dev
</pre>

Anschließend muss die Bluetooth Adresse des Wechselrichters ermittelt werden:
:<code>hcitool scan</code>

==== Schritt 2 - Installation von SBFSpot ====
Als erstes wird ein Verzeichnis erstellt, in das die Quellcode-Dateien heruntergeladen und anschließend kompiliert werden.

<pre>
cd /home/pi
mkdir sbfspot
cd sbfspot </pre>

Nun kann SBFSpot heruntergeladen,
:<code>wget [URL of latest version]</code>
entpackt,
:<code>tar -xvf [Dateiname]</code>
und abschließend kompiliert werden:
:<code>make release</code>

Danach werden das Programm SBFSpot und die Konfigurationsdatei noch in das FHEM Verzeichnis kopiert:
:<code>sudo cp SBFspot SBFspot.cfg /opt/fhem/FHEM/sbfspot/bin/Release</code>

und die Rechte setzen:
:<code>sudo chown -R fhem /opt/fhem/FHEM/sbfspot</code>

Um die Kompatibilität mit den diversen im Forum herumgeisternden Modulen zu gewährleisten, empfiehlt es sich ein paar Links zu erzeugen:
:<code>cd /opt/fhem/FHEM/; sudo ln -s sbfspot smaspot</code>
:<code>cd /opt/fhem/FHEM/sbfspot; sudo ln -s SBFspot SMAspot</code>

Möchte man nun Bluetooth nutzen, muss man schliesslich noch in der Datei ''/opt/fhem/FHEM/sbfspot/bin/Release/SBFspot.cfg'' die vorher mit ''hcitool'' gefundene Bluetooth-Adresse eintragen.

=== Einbindung in FHEM ===
==== Konfiguration in FHEM ====

Nun benötigen wir noch das Modul [http://forum.fhem.de/index.php/topic,14624.msg153006.html#msg153006 99_SMAUtils.pm] aus dem o.g. Thread. Dieses wird in das FHEM Verzeichnis (default wäre hier: /opt/fhem/FHEM) kopiert.

Als nächsten editieren wir die fhem.cfg und fügen die folgenden Zeilen hinzu:

<pre>
# Solar Wechselrichter
#
define Solar SMAUtils 00:80:25:2D:46:16 600
attr Solar delay 600
attr Solar icon measure_photovoltaic_inst
attr Solar room Energie
#
# FileLog Definition
#
define FileLog_Solar FileLog ./log/Solar-%Y-%m.log Solar:.*etod.*|Solar:.*string.*_pdc|Solar:.*total_pac|Solar:.*usage.*
attr FileLog_Solar icon icoLog
attr FileLog_Solar nrarchive 12
attr FileLog_Solar room Logfiles
#
# Chart
#
define SVG_FileLog_Solar_1 SVG FileLog_Solar:SVG_FileLog_Solar_1:CURRENT
attr SVG_FileLog_Solar_1 room Energie
attr SVG_FileLog_Solar_1 title "Solarleistung Min $data{min1}, Max $data{max1}, Last $data{currval1}"
</pre>

[[Datei:String performance.PNG|mini|400px|Beispielplot (SVG_FileLog_Solar_1.gplot)]]

In der ersten Zeile wird aktuell noch eine gültige Bluetooth Adresse benötigt, da das Modul SMAUtils diesen Parameter erwartet. Dies ist unabhängig davon, ob man den Wechselrichter per Bluetooth oder Ethernet anspricht. In letzterem Fall muss es nicht die richtige Bluetooth-Adresse des Wechselrichters sein, irgendeine Adresse ist ausreichend. Die eventuell auftretende Fehlermeldung "Solar: unknown attribute delay. Type 'attr Solar ?' for a detailed list." kann ignoriert werden.

==== Konfiguration des Plots ====
nun muss noch die Plotterkonfig für die Grafik erstellt werden. Dazu wird die Datei "''SVG_FileLog_Solar_1.gplot''" im FHEM Verzeichnis "''/opt/fhem/www/gplot''" mit folgendem Inhalt erzeugt:

<pre>
# Created by FHEM/98_SVG.pm, 2014-04-03 11:08:53
set terminal png transparent size <SIZE> crop
set output '<OUT>.png'
set xdata time
set timefmt "%Y-%m-%d_%H:%M:%S"
set xlabel " "
set title '<TL>'
set ytics
set y2tics
set grid
set ylabel "kW"
set y2label "kW"

#FileLog 4:Solar.string_1_pdc\x3a:0:
#FileLog 4:Solar.string_2_pdc\x3a:0:

plot "<IN>" using 1:2 axes x1y1 title 'String 1' ls l2 lw 1 with lines,\
"<IN>" using 1:2 axes x1y2 title 'String 2' ls l0 lw 1 with lines
</pre>

und nun sollte es im FHEM einen weiteren Menüpunkt "Energie" mit einer schönen Grafik geben :-)

=== Alternativen zum Auslesen der Daten ===
Es gibt ein Tool [https://github.com/Tommy-LSA/supoxy suproxy], welches die Daten des Sunny Portals ausliest. Damit erhält man nicht nur die Daten des Wechselrichters, sondern auch die Daten des Stromzählers.

== Links ==
* [http://forum.fhem.de/index.php/topic,14624.0.html Forenthread], in dem die Lösung vorgestellt / diskutiert wird
* [http://forum.fhem.de/index.php/topic,24876.0.html Forenthread], indem suproxy vorgestellt / diskutiert wird

[[Kategorie:Energieerzeugungsmessung]]

HM-SEC-KEY KeyMatic

2014-09-06T09:32:21Z

Caldir65: /* Links */ korrigiert

== Features ==
Das Gerät dient zum motorgesteuerten Betätigen von Zylinderschlössern in Türen.

== Hinweise zum Betrieb mit FHEM ==
Der HM-SEC-KEY Keymatic verwendet ausschließlich die AES authentifizierte Kommunikation. Daher kann die Steuerung nur zusammen mit dem [[HMLAN Konfigurator]] erfolgen.
Mit dem [[CUL]] ist jedoch auch eine Statusanzeige und das reagieren auf Events möglich.

Das Pairing sollte wie in [[HomeMatic Devices pairen]] beschrieben durchgeführt werden. An der KeyMatic muss dafür die Anlerntaste (Taste Schloss öffnen) betätigt werden.

Die KeyMatic-Unterstützung existiert derzeit in der aktuellen Entwicklerversion von FHEM

=== Sicherheitshinweis ===
Wenn die KeyMatic an einem aktiven HMLAN Konfigurator angelernt wurde, kann die entsprechende Tür per FHEM ver- / entriegelt bzw. geöffnet werden. Somit sollte das Netzwerk in dem FHEM läuft entsprechend gesichert sein. (Nicht nach Außen geöffnet, kein unsicheres WLAN usw.)

=== FHEM Config-Auszug ===
Beispiel für die Konfiguration:

ssssss -> 6-Stellige hexadezimale Seriennummer. (Siehe Logfile: CUL_HM Unknown device CUL_HM_keyMatic_ssssss, please define it)
xxxxxxx -> Seriennummer (vom Aufkleber auf dem Gerät)

define keymatic CUL_HM ssssss
attr keymatic devInfo 010100
attr keymatic firmware 2.4
attr keymatic hmClass receiver
attr keymatic model HM-SEC-KEY-S
attr keymatic room Flur
attr keymatic serialNr JEQxxxxxxx
attr keymatic subType keyMatic
attr keymatic webCmd lock:unlock:open

== Mögliche Zustände ==
KeyMatic hat folgende Schaltzustände:

locked -> Der Riegel des Türschlosses ist an die vorher festgelegte Verschlussstellung gefahren (Tür verschlossen)
unlocked -> Der Riegel des Türschlosses ist "eingefahren" (Tür nicht verschlossen)
uncertain (locked / unlocked) -> Das Schloss wurde am Handrad gedreht. Die Schlossposition ist somit nicht mehr als "zuverlässig erkannt" gemeldet.
== Links ==
Anleitung [http://www.eq-3.de/Downloads/eq3/pdf_produkte/HM-Sec-Key_UM_GE_eQ-3_081218.pdf] PDF

[[Kategorie:HomeMatic Components]]

HM-LC-Sw4-SM 4fach Schaltaktor Aufputz

2014-08-30T18:20:26Z

Caldir65: /* Links */

== Features ==
* Funkfrequenz 868,3 MHz
* Typ. Freifeldreichweite: 300 m
* Spannungsversorgung: 230 V / 50 Hz
* Standby-Verbrauch: 0,5 W
* Schutzart: IP65
* Schutzklasse: II
* Gehäuse: PC, lichtgrau
* Relais: 4 Wechsler (potentialfreie Kontakte)
* Schaltvermögen: 16 A (ohmsche Last)
* Abm. (B x H x T): 171 x 55 x 121 mm

== Hinweise zum Betrieb mit FHEM ==

Das Pairing sollte wie unter HomeMatic Devices pairen beschrieben durchgeführt werden.
Das Gerät und seine 4 Kanäle werden vom Autodetect einwandfrei erkannt und initialisiert.

== Probleme ==

Bisher keine.

== FHEM Config-Auszug ==

<<< folgt >>>

== Event-Monitor ==

<<< folgt >>>

== Parameter-Liste ==

<<< folgt >>>

== FHEM Log-Auszug ==

<<< folgt >>>

== Links ==

http://www.eq-3.de/Downloads/eq3/pdf_produkte/73951_HM-Aufputzaktoren_GE_V2.1_20140521_web.pdf

[[Kategorie:HomeMatic Components]]
[[Kategorie:Schalter (Empfänger)‏‎]]

HM-CC-VD Funk-Stellantrieb

2014-06-19T12:12:41Z

Caldir65: Anleitung zum Modul eingebunden

'''HM-CC-VD Funk-Stellantrieb'''

'''Achtung: Dieses Gerät ist abgekündigt (wird nicht mehr hergestellt). Nachfolgeprodukt ist der [[HM-CC-RT-DN]].'''

= Allgemeines =

Stellantrieb für den [[HM-CC-TC Funk-Wandthermostat|HM-CC-TC]]. Es können maximal 4 HM-CC-VD an ein HM-CC-TC angelernt werden.

Aktuelle Firmware: 2.0

Der HM-CC-VD '''misst nicht selbst''' die Temperatur. Diese wird von dem HM-CC-TC, mit dem der Stellantrieb gepairt wurde, gemessen.

= Probleme =

Bei Firmwareversionen vor 2.0 kann es vorkommen, dass sich der Stellantrieb bei einer bestimmten Stellung "festfährt" (z.B. 4%) und der Raum sich kontinuierlich erhitzt, obwohl eine niedrigere Temperatur am Wandthermostat eingestellt ist. Erst nach einem Reset des Stellantriebs oder manuellen Erhöhung der Temperatur am Wandthermostat/FHEM verrichtet der Stellantrieb wieder wie gewohnt seine Arbeit.

Quelle: [http://www.elv.de/output/controller.aspx?cid=834&detail=2&detail2=582 [1]]

Ein Firmwareupdate kann derzeit nur mittels Einschicken des Stellantriebs erfolgen.

Ist der Stellantrieb mit dem HM-CC-TC gepairt (zu sehen im Menü des HM-CC-TC als VST Nummer X), erscheint aber nicht in Fhem (hier mit HMLAN), dann hilft der Befehl ''set <HMLAN-Name> hmPairForSec 300'' und das Drücken des Anlernknopfes am HM-CC-VD für mind. 5 Sekunden.

= Betrieb mit FHEM =

HM-CC-VDs werden mit dem für ihren Betrieb/Raum zuständigen HM-CC-TC gepeert. Dadurch ist der TC für die Ansteuerung der Ventiltriebe da.

== Log-Daten ==
=== Device-Log ===

Zur Behebung des "1 bzw. 4 % Fehlers" wurde die Raumtemperatur über die Ansteuerung des HM-CC-TC temporär auf 28 °C erhöht. Nachdem das Thermostat (VD) laut Logs das Ventil auf hier 68 % geöffnet hat, wurde die Temperatur wieder auf die gewünschte (desired) Temperatur (am TC) gesetzt. Diese Befehle mussten allerdings einige Male wiederholt werden und es bedurfte einiger Minuten Wartezeit zwischen den Umstellungen.
<pre>
2013-03-18_22:34:57 OG.AZ.Thermostat set_0 %
2013-03-18_22:34:57 OG.AZ.Thermostat ValveDesired: 0 %
2013-03-18_22:34:58 OG.AZ.Thermostat ValvePosition: 1 %
2013-03-18_22:34:58 OG.AZ.Thermostat 1 %
2013-03-18_22:34:58 OG.AZ.Thermostat battery: ok
2013-03-18_22:34:58 OG.AZ.Thermostat motorErr: ok
2013-03-18_22:34:58 OG.AZ.Thermostat motor: stop
2013-03-18_22:34:58 OG.AZ.Thermostat operState: errorTargetNotMet
2013-03-18_22:34:58 OG.AZ.Thermostat operStateErrCnt: 1
2013-03-18_22:37:42 OG.AZ.Thermostat set_68 %
2013-03-18_22:37:42 OG.AZ.Thermostat ValveDesired: 68 %
2013-03-18_22:37:43 OG.AZ.Thermostat ValvePosition: 1 %
2013-03-18_22:37:43 OG.AZ.Thermostat 1 %
2013-03-18_22:40:20 OG.AZ.Thermostat set_68 %
2013-03-18_22:40:20 OG.AZ.Thermostat ValveDesired: 68 %
2013-03-18_22:40:22 OG.AZ.Thermostat ValvePosition: 68 %
2013-03-18_22:40:22 OG.AZ.Thermostat 68 %
2013-03-18_22:40:22 OG.AZ.Thermostat battery: ok
2013-03-18_22:40:22 OG.AZ.Thermostat motorErr: ok
2013-03-18_22:40:22 OG.AZ.Thermostat motor: stop
2013-03-18_22:40:22 OG.AZ.Thermostat operState: onTarget
2013-03-18_22:42:31 OG.AZ.Thermostat set_0 %
2013-03-18_22:42:31 OG.AZ.Thermostat ValveDesired: 0 %
2013-03-18_22:42:33 OG.AZ.Thermostat ValvePosition: 68 %
2013-03-18_22:42:33 OG.AZ.Thermostat 68 %
2013-03-18_22:42:33 OG.AZ.Thermostat battery: ok
2013-03-18_22:42:33 OG.AZ.Thermostat motorErr: ok
2013-03-18_22:42:33 OG.AZ.Thermostat motor: closing
2013-03-18_22:42:33 OG.AZ.Thermostat operState: adjusting
2013-03-18_22:44:34 OG.AZ.Thermostat set_0 %
2013-03-18_22:44:34 OG.AZ.Thermostat ValveDesired: 0 %
2013-03-18_22:44:36 OG.AZ.Thermostat ValvePosition: 0 %
2013-03-18_22:44:36 OG.AZ.Thermostat 0 %
</pre>

=== Event monitor ===
<pre>
2013-03-18 22:42:33 CUL_HM OG.AZ.Thermostat motor: closing
2013-03-18 22:42:33 CUL_HM OG.AZ.Thermostat operState: adjusting
</pre>

== Batteriealarme des HM-CC-VD in Verbindung mit HM-CC-TC ==
1. bei U-Bat. < 2,4 V erscheint im Display des VD und des TC das Batteriesymbol mit battery: low in den Readings und Events!
2. bei U-Bat. < 2,3 V erscheint im Display des VD zusätzlich F4 mit battery: critical in den Readings und Events!
Es wird dringend geraten, die Batterien bei battery: low zu tauschen!

= Links =
Anleitung: [http://www.eq-3.de/Downloads/eq3/pdf_produkte/HM-CC-VD_UM_GE_eQ-3_081013.pdf HM-CC-VD Funk-Stellantrieb]

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

E-Mail senden

2014-03-27T09:55:46Z

Caldir65: /* Keine Mail mit TLS Verschlüsselung */

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

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

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

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

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

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

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

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

'''Hinweis:''' Wenn der Aufruf der Mailfunktion aus einem notify oder at erfolgt, muss das @@ in der Adresse des Mailempfängers verdoppelt werden, da ein einfaches @ sonst durch den Namen des getriggerten Devices ersetzt würde. Bei Verwendung in der fhem-Kommandozeile oder einem eigenen *Utils.pm ist diese Doppelung nicht erforderlich. Bitte bei den ersten Mails ins Log schauen, ob die Mailadresse wie gewünscht verwendet wird.

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

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

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

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

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

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

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

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

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

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

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

=== Raspberry Pi ===
In der weezy-Version, wie sie von busware zur Verfügung gestellt wird, muss auf einem [[Raspberry Pi]] noch sendEmail nachinstalliert werden:

<pre>
sudo apt-get update
sudo apt-get install sendEmail
</pre>

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

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

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

Um die TLS Verschlüsselung (ehem. SSL) zu nutzen, muss in der 4. letzten Zeile tls=auto verwendet werden. Sollte anschließend keine Mail verschickt werden, siehe Probleme.

Beim Aufruf der Funktion gibt es zwei unterschiedliche Verhaltensweisen zu beachten. Wird DebianMail durch ein Fhem-Ereignis als Makro mit "Transferzeichen", wie @ oder % aufgerufen, so sind diese innerhalb des Aufrufs von DebianMail zu maskieren.

Siehe auch commandref:
* The character @ will be replaced with the device name. To use @ in the text itself, use the double mode (@@).
* The macro %<parameter> will expand to the current value of the named parameter. This can be either a parameter from the device definition or a parameter from the set or get command.

Beispiel:

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

in allen anderen Fällen muss die Maskierung entfallen:

Beispiel:

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

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

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

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

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

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

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

Vor dem testen der Routine oben kann sendEmail auch über die Konsole (z. B. via Putty) getestet werden:
:<code>sendEmail -f 'fhemsystem@meinedomain.tld' -t 'ich@meinedomain.tld' -u 'subject' -m 'body' -s 'meinmailserver.meinedomain.de' -xu 'fhemmailer' -xp 'geheimespassword' -o tls=no</code>

=== Keine Mail mit TLS Verschlüsselung ===
Den Test über die Konsole durchführen. Erhält man folgende Fehlermeldung:
''invalid SSL_version specified at /usr/share/perl5/IO/Socket/SSL.pm line 332''
muss auf dem Raspberry folgende Datei angepasst werden: ''/usr/share/perl5/IO/Socket/SSL.pm''.
In Zeile 1490 muss das '''$''' am Ende entfernt werden: m{^(!?)(?:(SSL(?:v2|v3|v23|v2/3))|(TLSv1[12]?))'''$'''}i

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

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

Anwesenheitserkennung - Remote Fritzbox

2014-01-20T16:51:37Z

Caldir65: Ergänzung zweite FB als Repeater

In Erweiterung des Beitrages [[Anwesenheitserkennung|Anwesenheitserkennung]] wird eine Beispiel-Lösung für folgendes Szenario vorgestellt:

* Eine (nicht modifizierte) Fritzbox wird als WLAN Access Point und Router genutzt, jedoch läuft auf dieser Box kein FHEM oder Perl.
* Ein Linux Rechner (in diesem Beispiel ein RPI) wird als FHEM host verwendet.
* Device Erkennung mittels PRESENCE - ident mit PRESENCE fritzbox

Die Lösung basiert auf dem PRESENCE Modul und nutzt die Funktion '''PRESENCE function { }'''.

Auch bei einem Repeater-Einsatz im WLan (zweite Fritzbox) kann diese Lösung eingesetzt werden - es ist nur eine Installation auf der Haupt-Fritzbox notwendig, nicht auf dem Repeater.

== Background / Motivation ==
Ich hatte während der letzten 12 Monate ein modifiziertes PRESENCE Modul im Einsatz, das jedoch immer wieder ein Hängen oder Reboots der Fritzbox verursacht hatte (speziell bei 7270), daher hatte ich es nicht veröffentlicht. Die Vermutung liegt nahe, dass das ständige Telnet ein/aus-loggen die Hänger/Reboots verursacht hat.

Diese Lösung basiert (wie auch die '''PRESENCE fritzbox''' Funktion) auf dem Fritzbox Befehl ''ctlmgr_ctl'', der jedoch von der "Ferne" ausgelöst werden muß, da FHEM ja nicht auf der Fritzbox läuft. Weiters wurden Ideen/Konzepte des presenced/collectord verwendet.

Die Lösung läuft bei mir seit Anfang Dez. 2013 stabil mit 12 abgefragten Devices / 120 Sekunden Intervall. (Env: FHEM auf RPI, Fritzbox 7390)

== Konzept ==

* Auf der Fritzbox wird ein '''shellscript''' installiert, dass von remote gestartet wird, Kommandos lokal ausführt und das Ergebniss zurückschickt.
* Am FHEM host läuft ein '''perl basierender daemon''' der Kommandos von FHEM empfängt, aufbereitet und das shellscript auf der Fritzbox (mit parameter) startet. Dieser Daemon hält auch die Telnet Verbindung zur Fritzbox permanent aufrecht. Gestartet wird dieser Daemon automatisch beim ersten Aufruf durch FHEM.
* ein Modul '''99_RFritzBox.pm''' ist die Schnittstelle zwischen FHEM und dem daemon.

== Installation / Debug ==
Der code ist als zip-file im thread [http://forum.fhem.de/index.php/topic,17957.0.html PRESENCE-RemoteFritzbox] abgelegt. Bitte in diesem thread auch Fragen/Feedback/Wünsche posten.

=== Voraussetzungen: ===
* Telnet auf der Fritzbox aktiviert
* perl NET::Telnet Modul auf dem Host wo FHEM läuft installiert. Beim Raspberry-PI geht das so:
<pre>sudo apt-get install libnet-telnet-perl</pre>
Folgende Reihenfolge ist empfehlenswert:
=== kopieren von Rpresence.sh in die Fritzbox ===
z.B. mittels FTP in folgendes Verzeichnis:
<pre>
/var/media/ftp/FRITZ/bin # Der Verzeichnispfad muß angepaßt werden! In diesem Beispiel ist das eine FB7390 im Internen Speicher.
chmod +x Rpresence.sh # shell script ausführbar machen.</pre>
Ein erster Test von der Telnet Konsole der Fritzbox:
<pre>./Rpresence.sh <FBdevicename></pre> sollte folgendes Ergebnis liefern: <pre>RFritzBox: <FBdevicename> y z</pre> wobei für <FBdevicename> der Name eines Gerätes, so wie in der Fritzbox Weboberfläche definert einzusetzen ist. y ist die Fritzbox interne Devicenummer dieses Gerätes (es sollte jedenfalls nicht 999 hier stehen, in diesem Fall hat die FB den Namen nicht gefunden. z ist der Status (0==abwesend/1==anwesend).
Falls bis hierher alles geklappt hat, ist die Einrichtung auf der Fritzbox fertig.

=== installation / konfig / test Daemon am FHEM host ===
kopieren von RFritzBoxScan.pl ins FHEM Verzeichnis (dort wo alle Module 00_xxx.pm - 99_yyy.pm sind)
<pre>sudo chmod +x RFritzBoxScan.pl # ausführbar machen
sudo chown fhem:root RFritzBoxScan.pl #for user fhem </pre>
Erstellen eines config- files für den daemon:
im root FHEM-Verzeichnis ( dort wo üblicherweise auch die fhem.pl zu finden ist )
ein file: '''credentials.cfg''' mit folgendem Inhalt erstellen (Adressen/User/Passwort/pfad anpassen):
<pre>
# PRESENCE credentials (only required for function RemoteFritzBox)
$credentials{RemoteFritzBox}{ipadress} = "192.168.1.254"; # FB LAN Adress
$credentials{RemoteFritzBox}{username} = "FritzBoxusername";
$credentials{RemoteFritzBox}{password} = "FritzboxPasswort";
$credentials{RemoteFritzBox}{shellcmd} = "/var/media/ftp/FRITZ/bin/Rpresence.sh"; # pfad anpassen!
$credentials{RemoteFritzBox}{serverhost} = "localhost"; # RFritzBoxScan.pl provides this service
$credentials{RemoteFritzBox}{serverport} = 7777;
$credentials{RemoteFritzBox}{serverbin} = "RFritzBoxScan.pl"; # Fritzbox daemon
</pre>
Das Format dieser cfg-file entspricht dem im Modul Webcam.
Ein erster Test:
<pre>./RFritzBoxScan.pl <fullpath and name> # of credentials.cfg eg: /opt/fhem/credentials.cfg</pre>
Damit wir der Daemon von Hand gestartet und alle debug-Meldungen kommen auf diese Konsole.
Beim Start sollte der Output so aussehen:
<pre>
RFritzBoxScan: server waiting for client connection on port 7777
RFritzBoxScan: Fritzbox login ok
### die folgenden Zeilen kommen erst ab dem nächsten Schritt !
### und zwar jedesmal wenn ein request von FHEM an den daemon kommt...
RFritzBoxScan: connection from 127.0.0.1:57595
RFritzBoxScan: ..from FHEM received data: Nokia-N810
RFritzBoxScan: ..sending to Fritzbox: Nokia-N810 17
RFritzBoxScan: ..cmdresult: RFritzBox: Nokia-N810 17 1
RFritzBoxScan: ..result to fhem: 1
</pre>

=== installation und konfiguration FHEM-Module ===
kopieren von 99_RFritzBox.pm ins FHEM Verzeichnis
<pre>sudo chown fhem:root 99_RFritzBox.pm # for user fhem</pre>
Im FHEM command-feld: <pre>reload 99_RFritzBox.pm</pre> eintippen (oder FHEM neu starten)
Die FHEM-PRESENCE Definition:
<pre>define <myName> PRESENCE function {RemoteFritzBox("<FBdevicename>")} 120 120</pre>
damit wird in 120 sec Abständen der Status abgefragt.
im Telnet Fenster sollten jetzt die requests / response - Meldungen kommen.

Zum Abschluß:
<pre><Strg-C></pre> im telnet Fenster eingeben, der Daemon wird dadurch gestoppt. Auf den nächsten Aufruf durch FHEM warten, der Daemon wird automatisch (im Hintergrund) gestartet. Überprüfen durch Eingabe von <pre>ps -e | grep RFritzBoxScan</pre>

== Debug Tip ==
Log Meldungen vom Daemon bekommt man im FHEM Log durch anlegen eines dummy devices mit dem Namen '''RemoteFritzBox''' :
<pre>
define RemoteFritzBox dummy
attr RemoteFritzBox verbose 5
</pre>
Den Daemon beenden, falls er im Hintergrund läuft:
<pre>sudo killall RFritzBoxScan.pl</pre>

have fun
erwin

[[Kategorie:Code Snippets]]
[[Kategorie:Glossary]]

HM-CC-TC Funk-Wandthermostat

2013-09-20T12:45:48Z

Caldir65: /* Temperaturlisten */

'''HM-CC-TC Funk-Wandthermostat'''
'''Achtung: Dieses Gerät ist abgekündigt (wird nicht mehr hergestellt). Nachfolgeprodukt ist der [[HM-CC-RT-DN]].'''
Programmierbarer Raumthermostat, der bis zu 4 [[HM-CC-VD Funk-Stellantrieb]] steuern kann.
= Features =
* Am Raumthermostat programmierbare Tages- und Nachttemperatur.
* Pro Wochentag können bis zu 24 Schaltpunkte definiert werden.
* Anbindung von <ins>jeweils</ins> '''maximal''' 4 Tür- bzw. Fensterkontakten ([[HM-Sec-RHS]]) zur Absenkung der Temperatur auf einen eigens eingestellten Temperaturwert (ab Werk: 12°C) bei offenem Fenster bzw. offener Tür.
* Anzeige der Temperatur und Luftfeuchtigkeit im Raum und Hintergrundbeleuchtung des Displays.

Alle 120 bis 184 Sekunden überträgt der Wandthermostat vorhandene Befehle zu den Stellantrieben. Jeder empfangene Befehl wird vom Stellantrieb bestätigt und dann ausgeführt. Täglich gegen Mitternacht synchronisiert ein HM-CC-TC seine Uhrzeit mit der HomeMatic-Zentrale (CCU, HMLAN).

= Hinweise zum Betrieb mit FHEM =
Vor dem Einsatz mit einer Zentrale sind erst alle Stellantriebe und Tür-/Fensterkontakte mit dem HM-CC-TC zu verbinden (P'''ee'''r).
Damit das ganze dann in FHEM auftaucht, muss der TC noch mit dem [[HMLAN Konfigurator]] gep'''ai'''rt werden.

Mit

<nowiki>set CUL hmPairForSec 300</nowiki>
setzt man das CUL / den HMLAN-Konfigurator für 5 Minuten in den Anlernmodus. Danach am Thermostaten 5 Sekunden lang die OK-Taste drücken und es wird eine Zeit von 20 auf 0 Sekunden gezählt:

* Klappt das Anlernen in diesen 20 Sekunden, wird der Countdown sofort beendet, anschließend für ca. 2-3 Sekunden "OK" angezeigt und der Thermostat ist in FHEM eingebunden.
* Gelingt das Anlernen nicht in den 20 Sekunden, erscheint nach Erreichen der "0" noch für 2 bis 3 Sekunden ein "NOK" ('''N'''ot '''OK''') im Display des TCs.

'''Alternativ'''(und so vom Entwickler des Fhem-HomeMatic-Moduls empfohlen) kann wie folgt vorgegangen werden:

* Alle Stellantriebe und Tür-/Fensterkontakte sowie den HM-CC-TC mit Fhem p'''ai'''ren (also ''set CUL hmPairForSec 300'' und an allen Devices den Anlernknopf drücken innerhalb des Zeitfensters von 300 Sekunden).
* Die Stellantriebe und Tür-/Fensterkontakte mit den ''Channels'' (siehe unten) p'''ee'''ren (siehe <nowiki>[http://fhem.de/commandref.html#CUL_HMpeerChan commandref :peerChan]</nowiki>). Hierzu werden die entsprechenden Fhem-Befehle über das Webinterface von Fhem erteilt.

'''Hinweis:'''
* Alle in der FHEM-Eingabezeile eingegebenen ''attr''-, ''define''-Befehle usw. müssen zum Schluss noch per Klick auf den "Save"-Button dauerhaft in der ''fhem.cfg'' gespeichert werden, sonst sind sie nach z.B. einem Systemabsturz verloren.
* Falls in der FHEM-Weboberfläche für ihren HM-CC-TC etwas wie ''X CMDs pending'' steht, sollten Sie ihren HM-CC-TC zur Hand nehmen und für 20 Sekunden auf die OK-Taste drücken. Dadurch werden alle noch ausstehenden Befehle eingelesen.
== Auszug aus der fhem.cfg ==
Die nachfolgenden Einstellungen zum HM-CC-TC werden von FHEM <ins>weitestgehend</ins> automatisch gesetzt. Die Pfadangaben für die Log-Dateien sind system-, die Raumbenennungen benutzerabhängig. Zu ''autoReadReg''und ''expert''siehe unten. Neben dem eigentlichen Basis-Gerät (HM-CC-TC) werden in FHEM automatisch noch 3 weitere "Unter"-Geräte (Channels/Kanäle), nämlich

* ''_Weather''
* ''_Climate''
* ''_WindowRec''

definiert (durch das Anlernen des TC an FHEM; siehe unten), deren Benennung sich (jeweils mit einem vorangestellten Unterstrich "_") am Namen des Basis-Gerätes orientiert.

'''Anmerkung:'''Die in den unten gezeigten ''fhem.cfg''-Auszügen markierten <ins>Peer</ins>-Einträge tauchen erst auf, sobald man die Daten aus dem TC mit ''set HM-CC-TC-Basisname getConfig''bzw. ''autoReadReg''ausgelesen hat.

=== Hauptgerät ===
<nowiki>define <HM-CC-TC>.Heizung CUL_HM 1DA491
attr <HM-CC-TC>.Heizung actCycle 000:10
attr <HM-CC-TC>.Heizung actStatus alive
attr <HM-CC-TC>.Heizung autoReadReg 1
attr <HM-CC-TC>.Heizung devInfo 00FFFF
attr <HM-CC-TC>.Heizung expert 2_full
attr <HM-CC-TC>.Heizung firmware 2.1
attr <HM-CC-TC>.Heizung hmClass receiver
attr <HM-CC-TC>.Heizung model HM-CC-TC
attr <HM-CC-TC>.Heizung room <IhrRaum>
attr <HM-CC-TC>.Heizung serialNr JE********
attr <HM-CC-TC>.Heizung subType thermostat</nowiki>
=== Channel (Kanal) 01 _Weather ===
<nowiki>define <HM-CC-TC>.Heizung_Weather CUL_HM 1DA49101 <<<=== 01 = Kanal 1
attr <HM-CC-TC>.Heizung_Weather model HM-CC-TC
attr <HM-CC-TC>.Heizung_Weather peerIDs
attr <HM-CC-TC>.Heizung_Weather room <IhrRaum>
define FileLog_<HM-CC-TC>.Heizung_Weather FileLog /opt/fhem/log/<HM-CC-TC>.Heizung_Weather-%Y-%m.log <HM-CC-TC>.Heizung_Weather
attr FileLog_<HM-CC-TC>.Heizung_Weather logtype text
attr FileLog_<HM-CC-TC>.Heizung_Weather room CUL_HM,<IhrRaum></nowiki>
=== Channel (Kanal) 02 _Climate ===
<nowiki>define <HM-CC-TC>.Heizung_Climate CUL_HM 1DA49102 <<<=== 02 = Kanal 2
attr <HM-CC-TC>.Heizung_Climate model HM-CC-TC
attr <HM-CC-TC>.Heizung_Climate peerIDs 1AD52B01,1B7A4C01,1C4CD101,1C48EC01, <<<=== gepeerte HM-CC-VDs
attr <HM-CC-TC>.Heizung_Climate room <IhrRaum>
define FileLog_<HM-CC-TC>.Heizung_Climate FileLog /opt/fhem/log/<HM-CC-TC>.Heizung_Climate-%Y-%m.log <HM-CC-TC>.Heizung_Climate
attr FileLog_<HM-CC-TC>.Heizung_Climate logtype text
attr FileLog_<HM-CC-TC>.Heizung_Climate room CUL_HM,<IhrRaum></nowiki>
=== Channel (Kanal) 03 _WindowRec ===
<nowiki>define <HM-CC-TC>.Heizung_WindowRec CUL_HM 1DA49103 <<<=== 03 = Kanal 3
attr <HM-CC-TC>.Heizung_WindowRec model HM-CC-TC
attr <HM-CC-TC>.Heizung_WindowRec peerIDs 1CFBB001, <<<=== gepeerte HM-Sec-SCs
attr <HM-CC-TC>.Heizung_WindowRec room <IhrRaum>
define FileLog_<HM-CC-TC>.Heizung_WindowRec FileLog /opt/fhem/log/<HM-CC-TC>.Heizung_WindowRec-%Y-%m.log <HM-CC-TC>.Heizung_WindowRec
attr FileLog_<HM-CC-TC>.Heizung_WindowRec logtype text
attr FileLog_<HM-CC-TC>.Heizung_WindowRec room CUL_HM,<IhrRaum></nowiki>
== Einstellungen eines HM-CC-TC lesen, anzeigen und sichern ==
=== expert ===
Anfang Februar 2013 wurde eine Änderung bei der Anzeige der so genannten ''Readings''(Register usw.), also der Einstellungen bzw. Eigenschaften eines HM-Devices, eingeführt. '''Alle'''Werte sieht man nur noch, wenn man am HM-CC-TC das Attribut ''expert''auf ''2_all''setzt. Per '''default'''(nicht in ''fhem.cfg''gesetzt) steht dieser Wert auf ''0_off''(nur die notwendigsten Readings/Eigenschaften werden angezeigt). Mittelweg ist der Wert ''1_on''.

Mittels

<nowiki>attr <HM-CC-TC-Name> expert 2_full</nowiki>
in der FHEM-Befehlszeile mit anschließendem <Enter> setzt man diesen Level.

Falls man mit '''Temperaturlisten'''arbeitet (siehe unten), dann kann man die komplette Liste im "Channel" (Kanal) ''<HM-CC-TC-Name>__Climate''einsehen. Auch für diesen Kanal ist evtl. ein setzen des Attributes ''expert 2_full''angeraten.

<ins>Anmerkung:</ins> Es gibt auch noch sogenannte "hidden datas" (versteckte interne Werte, Register oder Eigenschaften deren Namen mit einem "." beginnen). Diese sieht man nur dann, wenn auch das Attribut ''showInternalValues 1''gesetzt ist (default: 0 bzw. nicht gesetzt).

=== autoReadReg ===
Mitte Januar 2013 wurde das neue Attribut ''autoReadReg''eingeführt, welches auf ''0''voreingestellt ist (kein Eintrag in der ''fhem.cfg''). Das setzen dieses Attributes auf ''1''bewirkt, dass <ins>beim Neustart von FHEM</ins> die Einstellungen des entsprechenden HM-Gerätes ausgelesen werden. Dies wird bei mehreren ''autoReadReg''s automatisch zeitversetzt vorgenommen, um die Funk-Kommunikation nicht unnötig zu belasten.

Mittels

<nowiki>attr <HM-CC-TC-Name> autoReadReg 1</nowiki>
in der FHEM-Befehlszeile mit anschließendem <Enter> setzt man diesen Wert.

=== list ===
Um sich alle Eigenschaften/Readings eines Gerätes anzusehen, gibt es den Befehl ''list''.

Mittels

<nowiki>list <HM-CC-TC-Name></nowiki>
und Bestätigung mit <Enter> erhalten Sie die gewünschte Anzeige Ihres TCs <ins>incl.</ins> seiner 3 Channels. Über

<nowiki>list <HM-CC-TC-Name>_<Channel-Name></nowiki>
werden nur die Daten des angegebenen Channels angezeigt.

=== Einstellungen sichern ===
Die Durchführung von ''autoReadReg''kann durchaus mehrere Minuten dauern. Anschließend besteht die Möglichkeit, diese per

<nowiki>get HM-CC-TC-Basisname saveConfig [/Verzeichnis/mit/Schreibrechten/]<Dateiname></nowiki>
für jedes HM-CC-TC getrennt zu sichern (für eine später notwendige Wiederherstellung). Die Sicherungsdatei wird regulär im ''modpath''(siehe ''fhem.cfg'') abgelegt. Falls dies nicht zum Erfolg führt (es wird - ohne Fehlermeldungen bei regulärem ''verbose''und ''loglevel''- im ''modpath''keine Datei angelegt), müssen Sie vor dem Dateinamen einen vollständigen Pfad mit Schreibrechten für den Benutzer, unter dem FHEM läuft, angeben.

In der <ins>Log-Datei</ins> von FHEM erscheinen danach Meldungen folgender Art

<nowiki><Datum>_<Zeit> 2: CUL_HM set <HM-CC-TC-Name> statusRequest rxt:12
<Datum>_<Zeit> 2: CUL_HM set <HM-CC-TC-Name> getConfig rxt:12</nowiki>
Hierbei kann es (im <ins>Event monitor</ins> von FHEM) zu folgenden Fehlermeldungen kommen

<nowiki><Datum>_<Zeit> CUL_HM <HM-CC-TC-Name> RESPONSE TIMEOUT:RegisterRead
<Datum>_<Zeit> CUL_HM <HM-CC-TC-Name> RESPONSE TIMEOUT:PeerList
<Datum>_<Zeit> CUL_HM <HM-CC-TC-Name> RESPONSE TIMEOUT:StatusReq</nowiki>
Diese Meldungen können auch mehrfach pro Gerät auftreten. Dann hat das Auslesen der Einstellungen nicht geklappt und sollte nochmals durchgeführt werden. Dafür muss man FHEM aber nicht neu starten, sondern das HM-Device per

<nowiki>set <HM-CC-TC-Name> getConfig</nowiki>
in der Befehlszeile von FHEM und anschließendem <Enter> (nicht "save") darauf einstellen.

Die Channels (z.B. <HM-CC-TC-Name>_Climate, _Weather, _WindowRec) eines HM-Gerätes brauchen nicht (können aber bei Bedarf) separat ausgelesen bzw. gesichert zu werden, da sie Bestandteil der Basisabfrage sind.

== Funkprobleme auffangen ==
Der wohl am häufigsten an den HM-CC-TC gesendete Befehl ist "set desired-temp", mit dem die Wunschtemperatur neu gesetzt wird.
Funktioniert dieser Befehl jedoch nicht zuverlässig, wird die Wohnung ggf. zu lange oder nicht rechtzeitig beheizt.
Der folgende Mechanismus soll die Sicherheit erhöhen, indem die Antworten des HM-CC-TC geprüft werden und ggf. das Funktelegramm erneut gesendet wird.

Um den Sollwert zum erneuten Senden des Funktelegramms verfügbar zu haben, wird ein dummy definiert:

<nowiki>define HM_TC_Solltemperatur dummy</nowiki>
Wann immer die Solltemperatur geändert wird, setzt man die neue desired-temp nicht nur auf dem HM-TC-CC (hier HM_TC genannt), sondern auch auf dem dummy. Der Befehl (z.B. in der [http://www.fhemwiki.de/wiki/Zuhause-Status Routine zum HomeStatus]) sieht dann so aus:

<nowiki>set HM_TC desired-temp 21;set HM_TC_Solltemperatur 21</nowiki>
Falls das ausgehende Funktelegramm verlorengeht, fehlt die Antwort "command accepted". Dies kann mit einem watchdog aufgefangen werden, der dann den Befehl an den HM-CC-TC erneut sendet:

<nowiki>define w_HM_TC watchdog HM_TC:set_desired-temp.* 00:02:30 HM_TC_Climate:CommandAccepted:.yes { \
Log 1, ">>>>>>>>> w_HM_TC desired temp - missing response.";\
fhem("set HM_TC desired-temp ".Value("HM_TC_Solltemperatur"));\
}</nowiki>
Falls ein Fehler bei der Funkkommunikation auftritt, erhält man die Antwort "missing ACK" oder "NACK". Auch in diesem Fall soll das Telegramm zum Ändern der Wunschtemperatur erneut an den HM-CC-TC gesendet werden:

<nowiki>define n_HM_TC_err notify HM_TC:(MISSING.ACK.*|.*NACK.*) {\
Log 1, ">>>>>>>>> n_HM_TC desired temp - missing ack/nack.\n";\
fhem("set HM_TC desired-temp ".Value("HM_TC_Solltemperatur"));\
}</nowiki>
Mit diesen beiden Helfern ist die Funkkommunikation zum HM-CC-TC sehr zuverlässig.

== Plots / Grafiken ==
=== Problem ===
Durch ''autocreate''wird zwar ein Log angelegt, aber kein Plot (Grafische Auswertung). Dem kann man aber abhelfen (siehe unten).

=== Plots erzeugen ===
''PGM2''ist die Standardansicht des Fhem-Web-Interfaces. Um hier Plots/Grafiken zu erzeugen einfach unter dem ''Filelog''des Thermostaten das ''attr logtype''auf ''temp4hum6:Plot,text''setzen und es wird ein Plot-Link neben dem Text-Link angezeigt. Nun können Sie auf diesen Plot-Link klicken und ...

=== alternative Plots ===
Mit dem fht.gplot funktioniert die Anzeige der Ventilstellung (actuator) nicht.

Mit folgendem angepassten .gplot File wird die gemessene Temperatur und Ventilstellung angezeigt.

<nowiki>############################
# Display the measured temp and the actuator.
# Corresponding FileLog definition:
# define <filelogname> FileLog /var/log/fhem/actuator_name-%Y.log <actuator_name>:(measured-temp|actuator).*

set terminal png transparent size <SIZE> crop
set output '<OUT>.png'
set xdata time
set timefmt "%Y-%m-%d_%H:%M:%S"
set xlabel " "
set ytics nomirror
set y2tics
#set ytics
set title '<L1>'
set grid xtics y2tics

set y2label "Temperatur in C"
set ylabel "Ventil (%)"

#FileLog 4:measured:10:
#FileLog 4:actuator:50:

plot \
"< egrep 'temperature' <IN>"\
using 1:4 axes x1y2 title 'Temperatur in C' with lines,\
"< egrep 'actuator' <IN>"\
using 1:4 axes x1y1 title 'Ventil (%)' with lines\</nowiki>
=== Alles-drin-Plot ===
dazu nimmt man folgendes .gplot. Man/Fra beachte, dass hierfür alle Parameter nach der define-Anweisung in das Logfile geschrieben werden.

<nowiki>############################
# Display the measured temp and the actuator.
# Corresponding FileLog definition:
# define <filelogname> FileLog /var/log/fhem/HM_CC_TC-%Y.log <HM_CC_TC-name>
set terminal png transparent size <SIZE> crop
set output '<OUT>.png'
set xdata time
set timefmt "%Y-%m-%d_%H:%M:%S"
set xlabel " "
set ytics nomirror
set y2tics
#set ytics
set title '<L1>'
set grid xtics y2tics
set y2label "Temperature in C"
set ylabel "Actuator (%)"
#FileLog 4:temperature:0:
#FileLog 4:desired:0:
#FileLog 4:humidity:0:
#FileLog 4:actuator:0:int
plot \
"< awk '/temperature/{print $1, $4}' <IN>"\
using 1:2 axes x1y2 title 'Measured temperature' with lines lw 2,\
"< awk '/desired/{print $1, $4}' <IN>"\
using 1:2 axes x1y2 title 'Desired temperature' with steps,\
"< awk '/humidity/ {print $1, $4+0}' <IN>"\
using 1:2 axes x1y1 title 'Humidity (%)' with lines,\
"< awk '/actuator/ {print $1, $4+0}' <IN>"\
using 1:2 axes x1y1 title 'Actuator (%)' with lines\</nowiki>
== Steuerungsmodi ==
Das Wandthermostat hat 4 verschiedene Steuerungsmöglichkeiten:

* Auto (automatisch)
* Cent (Zentrale)
* Manu (manuell)
* Prog / Koffer-Symbol (Urlaubs/Party-Modus, wird hier nicht näher erörtert)

Der Steuerungsmodus wird über wiederholtes Drücken der linken Taste des HM-CC-TC ausgewählt bzw. gewechselt.

'''Hinweis:'''Durch das P'''ai'''ren des HM-CC-TC <ins>und</ins> der Stellantrieb sowie Tür-/Fensterkontakte an Fhem verlieren Sie '''nicht'''die Steuerungsmöglichkeiten. Im Gegenteil: Nur wenn auch die VDs usw. an Fhem gep'''ai'''rt sind, haben Sie die Möglichkeit, auch diese zu überwachen. Die Steuerung '''können'''Sie dennoch allein dem HM-CC-TC überlassen.

=== Auto-Modus ===
Im Modus '''Auto'''wird die Temperaturregelung über die im TC hinterlegten Temperaturlisten vorgenommen. Das Thermostat arbeitet also selbständig, somit unabhängig von einer Zentrale / FHEM. Nur in diesem Modus werden die evtl. per FHEM an das TC übermittelten "templist" abgearbeitet. Über das Senden von angepassten Temperatur-Listen kann eine indirekte Steuerung per FHEM erfolgen. '''Jederzeit'''kann zudem die Raumtemperatur über das Drehrad des Wandthermostaten oder die FHEM-Web-Oberfläche verändert werden. Diese ''Übersteuerung''der Temperaturliste gilt bis zur nächsten Temperaturänderung nach der vorgenannten Liste.

=== Cent-Modus ===
Im Modus '''Cent'''steuert eine HomeMatic-Zentrale (CCU) oder eben ein FHEM-Server mit z.B. [[HMLAN Konfigurator]] zu den in der FHEM-Config hinterlegten Zeiten und mit den dort festgelegten Temperaturen. Fällt also die HM-Zentrale aus, erfolgt keine Steuerung der Thermostaten bzw. Heizungsventile mehr.

<ins>Anmerkung</ins>: Der Modus ''cent''erscheint nur dann im Display des HM-CC-TC, wenn er an eine Zentrale bzw. das [[CUL]] angelernt (gepairt) wurde.

=== Manu-Modus ===
Der Modus '''Manu'''übersteuert die im TC hinterlegten Temperaturlisten und die evtl. von der HM-Zentrale / dem FHEM <ins>vor Umstellung auf ''Manu''</ins> gesendeten Einstellungen. Es wird also bis zur nächsten Modusumstellung bzw. manuellen Temperaturverstellung der per Einstellrad gesetzte Temperaturwert gefahren.

Aber auch in diesem Modus kann man die ''desired-temperature''per FHEM verstellen. Der dadurch eingestellte Wert gilt ab sofort als der neue im ''Manu-Modus''zu haltende Wert.

=== Auslesen des eingestellten Steuerungsmodus ===
Der eingestellte Steuerungsmodus erscheint normalerweise in den ''Readings'' des HM-CC-TC unter ''controlMode''. Zusätzlich haben Sie die Möglichkeit, diesen Modus auch in der FHEM-Weboberfläche ''everything'' => Abschnitt ''thermostat''zu sehen, '''wenn''' Sie für den HM-CC-TC das folgende Attribut setzen:

<nowiki>attr <HM-CC-TC-Name> stateFormat T:measured-temp, H:humidity, VD:actuator, controlMode</nowiki>
Erscheint dort selbst nach einem

<nowiki>set <HM-CC-TC-Name> getConfig</nowiki>
kein "Reading" ''controlMode''oder keine Angabe des aktuell eingestellten Modus bzw. nur das Wort "controlMode", dann setzen Sie ihren HM-CC-TC von Hand in einen anderen Kontrollmodus und machen einen Browser-Refresh. Klappt dies nicht, geben Sie bitte erneut den Befehl

<nowiki>set <HM-CC-TC-Name> getConfig</nowiki>
ein. Halten Sie anschließend die Taste <OK> am HM-CC-TC für 5 Sekunden gedrückt (oder warten ca. 5 Minuten) und machen in der FHEM-Weboberfläche einen Refresh (FF => <F5>). Jetzt sollte der manuell eingestellte Kontrollmodus erscheinen (ggfls. muss dieser Vorgang ein Mal wiederholt werden). Jetzt können Sie wieder den gewünschten Modus einstellen, erneut ein

<nowiki>set <HM-CC-TC-Name> getConfig</nowiki>
absetzen und nach erneutem Drücken der <OK>-Taste für 5 Sekunden mit nachfolgendem Browser-Refresh sollte alles richtig angezeigt werden.

Dies setzt natürlich voraus, dass der HM-CC-TC richtig gepairt ist.

== Temperaturlisten ==
Eine Temperaturliste für die Steuerung der Raumtemperatur im o.a. '''Auto-Modus'''kann man wie folgt erzeugen:

* Man legt sich eine eigene ''99_MyUtils.pm'' an (siehe <nowiki>[http://www.fhemwiki.de/wiki/99_myUtils_anlegen Link]</nowiki>). Dies ist wichtig, da es bei FHEM-Updates durchaus sein kann, dass die vorhandene ''99_Utils.pm'' erneuert und damit überschrieben wird und dann sind all ihre eigenen Subroutinen weg.
* Dort trägt man für '''jedes''' HM-CC-TC, dessen Werte man individuell einstellen will, eine '''eigene''' Subroutine ein, die z.B. wie folgt aussehen kann:
<nowiki>######################################################
# Temperatur-Liste für das Wohnzimmer
# setzen per Aufruf von "{SetTempList_EG_WZ_Heizung}"
######################################################
sub
SetTempList_EG_WZ_Heizung()
{
{ fhem ("set EG.WZ.Heizung_Climate tempListMon 05:30 17.0 07:00 21.0 16:00 19.0 20:30 20.5 24:00 17.0")};
{ fhem ("set EG.WZ.Heizung_Climate tempListTue 05:30 17.0 07:00 21.0 16:00 19.0 20:30 20.5 24:00 17.0")};
{ fhem ("set EG.WZ.Heizung_Climate tempListWed 05:30 17.0 07:00 21.0 16:00 19.0 20:30 20.5 24:00 17.0")};
{ fhem ("set EG.WZ.Heizung_Climate tempListThu 05:30 17.0 07:00 21.0 16:00 19.0 20:30 20.5 24:00 17.0")};
{ fhem ("set EG.WZ.Heizung_Climate tempListFri 05:30 17.0 07:00 21.0 15:00 19.0 20:30 20.5 24:00 17.0")};
{ fhem ("set EG.WZ.Heizung_Climate tempListSat 07:00 17.0 09:00 21.0 15:00 19.0 21:00 21.0 24:00 17.0")};
{ fhem ("set EG.WZ.Heizung_Climate tempListSun 07:00 17.0 09:00 21.0 15:00 19.0 21:00 21.0 24:00 17.0")};
}
# End SetTempList_EG_WZ_Heizung</nowiki>
* die Änderungen in der ''99_MyUtils.pm'' müssen jetzt abgespeichert werden
* in der FHEM-Befehlszeile ist ein ''reload 99_MyUtils.pm'' mit <Enter> / <Return> abzusetzen (erst dadurch werden die Eintragungen / Änderungen aktiviert)
* nun kann man in der Kommandozeile von FHEM den Befehl ''{SetTempList_EG_WZ_Heizung}'' eingeben und mit <Return> bzw. <Enter> bestätigen

Im FHEM-Logfile (das man vorher in einem weiteren Browser-Tab geöffnet hat) taucht danach folgendes auf:

<nowiki><Datum> <Zeit> CUL_HM EG.WZ.Heizung set_tempListMon 05:30 17.0 07:00 21.0 16:00 19.0 20:30 20.5 24:00 17.0
<Datum> <Zeit> CUL_HM EG.WZ.Heizung_Climate set_tempListTue 05:30 17.0 07:00 21.0 16:00 19.0 20:30 20.5 24:00 17.0
<Datum> <Zeit> CUL_HM EG.WZ.Heizung_Climate set_tempListWed 05:30 17.0 07:00 21.0 16:00 19.0 20:30 20.5 24:00 17.0
<Datum> <Zeit> CUL_HM EG.WZ.Heizung_Climate set_tempListThu 05:30 17.0 07:00 21.0 16:00 19.0 20:30 20.5 24:00 17.0
<Datum> <Zeit> CUL_HM EG.WZ.Heizung_Climate set_tempListFri 05:30 17.0 07:00 21.0 15:00 19.0 20:30 20.5 24:00 17.0
<Datum> <Zeit> CUL_HM EG.WZ.Heizung_Climate set_tempListSat 07:00 17.0 09:00 21.0 15:00 19.0 21:00 21.0 24:00 17.0
<Datum> <Zeit> CUL_HM EG.WZ.Heizung_Climate set_tempListSun 07:00 17.0 09:00 21.0 15:00 19.0 21:00 21.0 24:00 17.0</nowiki>
'''Zur Erläuterung:'''

Mittels

<nowiki>set EG.WZ.Heizung_Climate tempListMon 05:30 17.0 07:00 21.0 16:00 19.0 20:30 20.5 24:00 17.0</nowiki>
setzt man das HM-CC-TC-Channel mit dem Namen ''EG.WZ.Heizung_Climate'' für jeden folgenden Montag

von 00:00 bis 05:30 Uhr auf 17,0 °C
von 05:31 bis 07:00 Uhr auf 21,0 °C
von 07:31 bis 16:00 Uhr auf 19,0 °C
...

und so weiter. Dabei kann bei der Temperatur als Nachkommawert entweder eine 0 oder eine 5 stehen, ein Wert von z.B. 20,1 ist nicht erlaubt.

Beachten Sie, dass am Schluss der Liste immer eine Einstellung für 24:00 notiert sein muss. Ansonsten quittiert FHEM das Setzen der Liste mit einem solchen Eintrag im Logfile:

<nowiki>Last time spec must be 24:00</nowiki>
Im FHEM-Logfile-Browser-Tab sollten nach einigen Minuten folgende mehrfach wiederholten Einträge auftauchen:

<nowiki><Datum> <Zeit> CUL_HM EG.WZ.Heizung_Climate CommandAccepted: yes
<Datum> <Zeit> CUL_HM EG.WZ.Heizung_Climate CommandAccepted: yes
...
<Datum> <Zeit> CUL_HM EG.WZ.Heizung_Climate CommandAccepted: yes</nowiki>
Wichtig ist ein nachfolgendes "ACK". Steht dort "MISSING ACK", dann wurde der Empfang der Werte vom HM-CC-TC nicht bestätigt und man sollte die TempList noch einmal schicken. Kommt auch nach mehreren Sendeversuchen kein "ACK" sollten Sie in den ''Readings''des Devices die ''TempList''überprüfen (siehe unten), denn es kann sein, dass diese Antwort schlicht nicht empfangen werden konnte, weil der Empfänger gerade anderweitig beschäftigt war, die Einstellungen aber dennoch übernommen wurden. Wird jedoch ein "NACK" vom HM-CC-TC gesendet, dann wurde die Temperaturliste explizit nicht akzeptiert. Kontrollieren Sie in diesem Fall die Korrektheit der Temperaturliste.

Welche Werte '''aktuell eingestellt'''sind, sieht man in den "Readings" des jeweiligen Devices; im obigen Fall also z.B. im linken Menü von FHEM auf den default-Eintrag ''Everything''klicken und dann auf den Eintrag mit dem Namen ''EG.WZ.Heizung''.

== Batteriealarme des HM-CC-VD in Verbindung mit HM-CC-TC ==
1. bei U-Bat. < 2,4 V erscheint im Display des VD und des TC das Batteriesymbol mit '''battery: low''' in den Readings und Events!

2. bei U-Bat. < 2,3 V erscheint im Display des VD zusätzlich '''F4''' mit '''battery: critical''' in den Readings und Events!

Es wird dringend geraten, die Batterien bei battery: low zu tauschen!

== Log-Auszug ==
HM-CC-TC sendet alle 2 Minuten folgenden Statusbericht:

<nowiki>Datum-Zeit <Device Name> T: 17.3 H: 66 
Datum-Zeit <Device Name> measured-temp: 17.3 
Datum-Zeit <Device Name> temperature: 17.3 
Datum-Zeit <Device Name> humidity: 66 
Datum-Zeit <Device Name> actuator: 96 % </nowiki>
Bei Status-Änderungen sendet HM-CC-TC auch entsprechende Meldungen, z.b.:

<nowiki>Datum-Zeit <Device Name> desired-temp: 15.5 </nowiki>
= Firmware =
Aktuelle Firmware-Version: 2.1

= Links =
Anleitung [http://www.elv-downloads.de/service/manuals/76787_76175_HM_Wandthermostat_UM.pdf PDF]

[[Kategorie:HomeMatic Components]]
[[Kategorie:Feuchtigkeitssensor]]
[[Kategorie:Temperatursensor]]