93_DbLog - Überlegungen zur Optimierung (RPI und andere Systeme)

Begonnen von JoeALLb, 27 Januar 2017, 22:16:19

Vorheriges Thema - Nächstes Thema

JoeALLb

@Heiko, @All,

Vorschlag für neuen Standardindex.

Nach einigen Tests ist für mich dieser Index der geeignetste.
Er unterstützt sämtliche Anfragen, die in meinem Alltag und auch bei Serviceabfragen benutzt werden,
da in sämtlichen Abfragen eigentlich immer eine Zeiteinschränkung enthalten ist.
Getestet habe ich:
# Plots (=> immer mit Zeitangabe)
# DbRep (=> mit Zeitangabe)
# reduceLog (=> immer mit Zeitangabe)
# deleteOldDays (=> immer mit Zeitangabe)
# @Friesenjung: Auch deine letzte Abfrage, die ich in ähnlicher Form durchaus häufiger nutze, ist mit diesem viel schneller.
Durch diesen Index wird auch kein zweiter eigener Index für DbRep mehr benötigt.

Vorschlag:
PRIMARY KEY (`TIMESTAMP`, `DEVICE`, `READING`)

Daher die allgemeine Frage an die Runde: Sieht jemand andere Anwendungsfälle, in welchen dieser Index einen
größeren Nachteil zum bisherigen Index hat?

@Heiko: Da es jedoch ein Primary Key-Index meine Frage: Denkst Du, wir können meinen Patch von oben in die aktuellen Testversionen integrieren?
Dieser sollte ohne dem Attribut usePK keinerlei Änderungen für die Anwendung bedeuten, mit dem gesetzten Attribut jedoch den primary-Key
problemlos unterstützen? Zusätzlich könne ich dadurch Testversionen deutlich einfacher bei mir einspielen...

Fazit: Sämtliche von mir getesteten und gefundenen SQLs aus den Modulen werden dadurch beschleunigt oder bleiben zumindest gleich schnell.
Die einzige gefundene Ausnahme für FLOORPLAN ist unten dokumentiert. Wenn diese Abfrage wichtig ist, kann für diese und für Verwender von Floorplan ein
zusätzlicher Index eingefügt werden. Alternativ kann dieser jedoch durch eine Unterstützung aus dem Cache sogar noch beschleunigt werden.

===========================================================
folgende Abfragen werden dadurch langsamer:

aus DbLog:
  weiß jemand, wann "getreadings" für diesen Select genau benötigt wird? Ich denke, dies fürd nur für Benutzer
  von "FLOORPLAN" benötigt. Diese könnten sich dann zusätzlich einen weiteren Index mit anlegen.
SELECT distinct(reading) FROM history WHERE device = '".$device.


Anhang: zusätzlich zu DbLog geprüfte SQL_Statements aus anderen FHEM-Modulen, die durch diese Änderung profitieren:

aus DbRep:
SELECT AVG(VALUE) FROM `history` where DEVICE LIKE '$device' AND READING LIKE '$reading' AND TIMESTAMP >= '$runtime_string_first' AND TIMESTAMP < '$runtime_string_next' ;
SELECT COUNT(*) FROM `history` where ...
SELECT VALUE,TIMESTAMP FROM `history` where ...  TIMESTAMP >= '$runtime_string_first' AND TIMESTAMP < '$runtime_string_next' ORDER BY TIMESTAMP;
FHEM-Server auf IntelAtom+Debian (8.1 Watt), KNX,
RasPi-2 Sonos-FHEM per FHEM2FHEM,RasPi-3 Versuchs-RasPi für WLAN-Tests
Gateways: DuoFern Stick, CUL866 PCA301, CUL HM, HMLan, JeeLink, LaCrosse,VCO2
Synology. Ardurino UNO für 1-Wire Tests, FB7270

DS_Starter

Hallo Joe,

ZitatDenkst Du, wir können meinen Patch von oben in die aktuellen Testversionen integrieren?

Ja, ich denke das kriegen wir gut integriert mit diesem Attribut. Habe aber erst am WE wieder Zeit etwas am Modul zu tun.

Kann der neue neue "PRIMARY KEY (`TIMESTAMP`, `DEVICE`, `READING`) " kann (zunächst) neben dem bisherigen Index existieren oder muß man den alten Index dafür zwingend löschen ? Das wäre sicherlich für die Kompatibilität wichtig, falls Nutzer erst nach und nach auf Primary Key umstellen wollen.
Das Ganze funktioniert in dieser Form sicherlich nur für Nicht-SQLite DBs, d.h. für Postgre sollte es eigentlich auch passen oder ?

Wenn der Primary Key de facto Standard werden soll, wären natürlich diverse Anleitungen, Hinweise und  die Beispiel-SQL's im contrib Verzeichnis anzupassen usw. Mal schauen was Tobias dazu sagt.

Grüße und schönen Abend zusammen
Heiko





ESXi@NUC+Debian+MariaDB, PV: SMA, Victron MPII+Pylontech+CerboGX
Maintainer: SSCam, SSChatBot, SSCal, SSFile, DbLog/DbRep, Log2Syslog, SolarForecast,Watches, Dashboard, PylonLowVoltage
Kaffeekasse: https://www.paypal.me/HMaaz
Contrib: https://svn.fhem.de/trac/browser/trunk/fhem/contrib/DS_Starter

JoeALLb

#47
Hallo Heiko,

aus verschiedenen Gründen (Performance, doppelte Einträge zur selben Zeit machen keinen Sinn, können auch nicht geplottet werden, etc..., zuverlässigeres Löschen von Einträgen (damit auch in SQL-Browsern möglich, ...)
Würde ich dazu plädieren, den PK als standard zumindest für neue Datenbanken zu empfehlen.

Bei bereits bestehenden kann dieser Index natürlich einfach als normaler Index verwendet werden.
INDEX `DbLog2.13` (`TIMESTAMP`, `DEVICE`, `READING`) USING BTREE;

Achtung: Diese Indexe sind aktuell vorschläge und werden im Moment noch sehr ausgiebig in unterschiedlichsten Konstellationen getestet!

Denn im Updatefall müssten zuvor bereits bestehende doppelte Einträge bereinigt werden.
Mit der Umkopier-Methode, die hier schon mehrmals beschrieben war, ist dies im Prinzip auch leicht möglich.

Eventuell ergänzen wir sogar eine Funktion: "verifyDB" und "upgradeDB", die diese Schritte für den User übernimmt.

Warum denkst Du, sollte das bei SQLite nicht funktionieren?

CREATE TABLE [history](
    [TIMESTAMP] TIMESTAMP,
    [DEVICE] varchar(64),
    [TYPE] varchar(64),
    [EVENT] varchar(512),
    [READING] varchar(64),
    [VALUE] varchar(128),
    [UNIT] varchar(32),
    PRIMARY KEY([TIMESTAMP], [DEVICE], [TYPE]) ON CONFLICT IGNORE) WITHOUT ROWID;


Sollte genauso funktionieren, jedoch habe ich das noch nicht getestet.


Das Updatescript für SqLite würde in etwa so aussehen:
SAVEPOINT [dblog_db_upgrade_transaction];

CREATE TABLE [historyTMP](
    [TIMESTAMP] TIMESTAMP,
    [DEVICE] varchar(64),
    [TYPE] varchar(64),
    [EVENT] varchar(512),
    [READING] varchar(64),
    [VALUE] varchar(128),
    [UNIT] varchar(32),
    PRIMARY KEY([TIMESTAMP], [DEVICE], [TYPE]) ON CONFLICT IGNORE) WITHOUT ROWID;

ALTER TABLE [history] RENAME TO [historyWORK]; ALTER TABLE [historyTMP] RENAME TO [history];
RELEASE [dblog_db_upgrade_transaction];

SAVEPOINT [dblog_db_upgrade_transaction];

CREATE TABLE [historyNEW](
    [TIMESTAMP] TIMESTAMP,
    [DEVICE] varchar(64),
    [TYPE] varchar(64),
    [EVENT] varchar(512),
    [READING] varchar(64),
    [VALUE] varchar(128),
    [UNIT] varchar(32),
    PRIMARY KEY([TIMESTAMP], [DEVICE], [TYPE]) ON CONFLICT IGNORE) WITHOUT ROWID;

INSERT INTO [historyNEW]([TIMESTAMP], [DEVICE], [TYPE], [EVENT], [READING], [VALUE], [UNIT])
SELECT [TIMESTAMP], [DEVICE], [TYPE], [EVENT], [READING], [VALUE], [UNIT]
FROM [historyWORK];

ALTER TABLE [history] RENAME TO [historyTMP2]; ALTER TABLE [historyNEW] RENAME TO [history];
RELEASE [dblog_db_upgrade_transaction];

INSERT INTO [history]([TIMESTAMP], [DEVICE], [TYPE], [EVENT], [READING], [VALUE], [UNIT])
SELECT [TIMESTAMP], [DEVICE], [TYPE], [EVENT], [READING], [VALUE], [UNIT]
FROM [historyTMP2];


Am Update der Anleitungen würde ich mich natürlich beteiligen!

schönen Abend,
Joe
FHEM-Server auf IntelAtom+Debian (8.1 Watt), KNX,
RasPi-2 Sonos-FHEM per FHEM2FHEM,RasPi-3 Versuchs-RasPi für WLAN-Tests
Gateways: DuoFern Stick, CUL866 PCA301, CUL HM, HMLan, JeeLink, LaCrosse,VCO2
Synology. Ardurino UNO für 1-Wire Tests, FB7270

DS_Starter

Hi Joe,

ZitatWarum denkst Du, sollte das bei SQLite nicht funktionieren?

Könnte sagen ... gebranntes Kind  ;) Nein, ich dachte eher an deinen Patch. Die Syntax für den Insert passt, glaube ich, nicht für SQLite.
Müssen wir nochmal checken.

Muß jetzt aber echt los . Bis später mal ...

Grüße
Heiko
ESXi@NUC+Debian+MariaDB, PV: SMA, Victron MPII+Pylontech+CerboGX
Maintainer: SSCam, SSChatBot, SSCal, SSFile, DbLog/DbRep, Log2Syslog, SolarForecast,Watches, Dashboard, PylonLowVoltage
Kaffeekasse: https://www.paypal.me/HMaaz
Contrib: https://svn.fhem.de/trac/browser/trunk/fhem/contrib/DS_Starter

ghayne

#49
Zitat von: DS_Starter am 31 Januar 2017, 19:44:29
Hallo Garry, @all,

mit der angehängten Version 2.11.2 gelten die Feldlängenbegrenzungen mit den Attributen colEvent, colReading und colValue auch für SQLite Datenbanken. Es wird nun auch bei SQLite mit colEvent=0 das Feld EVENT nicht gefüllt.

HINWEIS:
Um die Kompatibilität mit dem bisherigen Verhalten keine Feldlängenbegrenzung bei SQLite vorzunehmen zu erhalten, gelten die Feldlängenbegrenzungen bei SQLite erst dann wenn eines der oben genannten Attribute gesetzt wird. Dann gelten aber ALLE im Internal COLUMNS angezeigten Feldlängen.
Unter Umständen sind sie dann anzupassen.

Garry, probiers mal bei dir aus. Denke es passt so...  :)

Grüße
Heiko

Hallo Heiko,

funktioniert bei mir (AsyncMode=1)

Regards, Garry

Edit
Habe aber jetzt teilweise extrem hohe messungen wieder (400kW)
Nicht optimal!

Garry

DS_Starter

#50
Hallo Joe, @all,

anbei die Version 2.12.1_Test.
In dieser Version ist der Support für die Verwendung von Tabellen mit Primary Key für Nicht-SQLite DB's implementiert.
DbLog erkennt automatisch ob die Tabelle history und/oder current einen primary key gesetzt haben und verwendet dementsprechende Statements.
Das ist sowohl im synchronen als auch asynchronen Mode der Fall. Wird der PK wieder gelöscht und durch normale Indexe ersetzt, verwendet
DbLog wieder automatisch die bisherigen Statements.

Ich habe bei meinen MySQLs die bisherig verwendeten Indexe (mehrere weil DbRep verwendet) gelöscht und durch einen primary key auf der Tabelle
history ersetzt. Auf der current-Tabelle habe ich auch einen PK gesetzt (über die Sinnfälligkeit kann man sich sicherlich streiten, aber
ich wollte es probieren ).

Für die history-Tabelle habe ich diese Syntax verwendet:
ALTER IGNORE TABLE `history` ADD PRIMARY KEY(TIMESTAMP, DEVICE, READING);

Das "IGNORE" war bei mir nötig um auf der bereits gefüllten Tabelle den PK anlegen zu können da bereits duplicate rows vorhanden
waren. Sonst klappt es nicht und die Key Erstellung läuft auf Fehler.

Für die Current-Tabelle habe ich verwendet:

ALTER TABLE `current` ADD PRIMARY KEY (DEVICE, READING);

Vorher habe ich den Inhalt der Einfachneit halber mit "delete from current" gelöscht, da sie ja sofort wieder aufgebaut wird.

Die Erstellung der PK auf der history (ca. 950 MB) dauerte nur ein paar Minuten.
Die Ergebnisse sind bisher sehr positiv. Umfangreiche Kalkulationen (Jahresauswertungen) mit DbRep die ohne PK ca. 12s im Hintergrund
liefen, benötigen jetzt nur noch ca. 1,5s.

@Joe, schau dir mal den Code an ob du diesbzgl. noch etwas verändern würdest.

viele Grüße und einen schönen Sonntag
Heiko
ESXi@NUC+Debian+MariaDB, PV: SMA, Victron MPII+Pylontech+CerboGX
Maintainer: SSCam, SSChatBot, SSCal, SSFile, DbLog/DbRep, Log2Syslog, SolarForecast,Watches, Dashboard, PylonLowVoltage
Kaffeekasse: https://www.paypal.me/HMaaz
Contrib: https://svn.fhem.de/trac/browser/trunk/fhem/contrib/DS_Starter

DS_Starter

Hi Garry,

ZitatEdit
Habe aber jetzt teilweise extrem hohe messungen wieder (400kW)
Nicht optimal!

Deine message kann ich nicht einordnen. Ich vermute es handelt sich um deine Messungen am Energiezähler an sich, d.h. die gemessenen Werte sind zu hoch.

best regards,
Heiko
ESXi@NUC+Debian+MariaDB, PV: SMA, Victron MPII+Pylontech+CerboGX
Maintainer: SSCam, SSChatBot, SSCal, SSFile, DbLog/DbRep, Log2Syslog, SolarForecast,Watches, Dashboard, PylonLowVoltage
Kaffeekasse: https://www.paypal.me/HMaaz
Contrib: https://svn.fhem.de/trac/browser/trunk/fhem/contrib/DS_Starter

JoeALLb

Hallo Heiko,

Das klingt schon mal sehr vielversprechend,
vielen Dank für die Version! Ich bin am testen!! kurze Rückfrage: Du nutzt aktuell immer noch mehrere Indexe, oder?

Bezüglich Index zur current: Lt. meinen Tests ist das zumindest effizienter als die
separatem update und insert-Befehle, bei mySQL.
Generell könnte ich mir aber vorstellen, dass wir diese Tabelle gar nicht mehr benötigen, und vielleicht einen neuen Modus:
"History/Mem" statt (oder zusätzlich zu) "Hostpry/Current" anbieten.
Kann man testen, wieviel Speicher 4000 Datensätze in einer Memcache-Tabelle benötigt?
Ich denke, das sollten die meisten Systeme leisten können...

sG
Joe
FHEM-Server auf IntelAtom+Debian (8.1 Watt), KNX,
RasPi-2 Sonos-FHEM per FHEM2FHEM,RasPi-3 Versuchs-RasPi für WLAN-Tests
Gateways: DuoFern Stick, CUL866 PCA301, CUL HM, HMLan, JeeLink, LaCrosse,VCO2
Synology. Ardurino UNO für 1-Wire Tests, FB7270

DS_Starter

Hi Joe,

ZitatDu nutzt aktuell immer noch mehrere Indexe, oder?

Nein, habe alles gelöscht und nur noch die oben beschriebenen PK im Einsatz.

ZitatGenerell könnte ich mir aber vorstellen, dass wir diese Tabelle gar nicht mehr benötigen, und vielleicht einen neuen Modus:
"History/Mem" statt (oder zusätzlich zu) "Hostpry/Current" anbieten.

Keine schlechte Idee. Die current braucht man ja nur wenn man die Vorschläge bei der Plot-erstellung haben möchte. Nachteil des Lesens aus dem Mem
ist für diesen Einsatzfall dass selten generierte Device/Reading-Kombinationen im Mem nicht enthalten sein können. Aber wenn man als User die Zusammenhänge kennt sollte eine zusätzliche "History/Mem"-Auswahl für DbLogType eine hilfreiche Möglichkeit sein.

ZitatKann man testen, wieviel Speicher 4000 Datensätze in einer Memcache-Tabelle benötigt?

Wüßte ad hoc nichts brauchbares. Aber wenn wir pro zu loggenden Event durchschnittlich 500 Byte annehmen (wahrscheinlich eher weniger), wären das ca. 2MB. Sollte m.M. nach kein Prob sein.

Grüße
Heiko

ESXi@NUC+Debian+MariaDB, PV: SMA, Victron MPII+Pylontech+CerboGX
Maintainer: SSCam, SSChatBot, SSCal, SSFile, DbLog/DbRep, Log2Syslog, SolarForecast,Watches, Dashboard, PylonLowVoltage
Kaffeekasse: https://www.paypal.me/HMaaz
Contrib: https://svn.fhem.de/trac/browser/trunk/fhem/contrib/DS_Starter

JoeALLb

Hallo Heiko,

Danke für die Info!
Hast Du vor, die schon vorhandenen "doppelten" Einträge in der History zu finden und sie ggf. zu bereinigen?

Zitat von: DS_Starter am 05 Februar 2017, 16:32:38
... Nachteil des Lesens aus dem Mem
ist für diesen Einsatzfall dass selten generierte Device/Reading-Kombinationen im Mem nicht enthalten sein können. Aber wenn man als User die Zusammenhänge kennt sollte eine zusätzliche "History/Mem"-Auswahl für DbLogType eine hilfreiche Möglichkeit sein.

Nun, ein SQL der sämtliche Device/Reading_Kombinationen generiert, dauert bei mir aktuell 9 Sekunden.
Diesen könnte man ja nach dem Start von FHEM auslesen und damit die Memcache-Tabelle füllen, somit würde es diesen Nachteil erst gar nicht geben.
Gerade im ASync-Modus wäre es auch egal, wenn nach dem Systemstart diese Daten einmalig aus der DB gelesen werden würden.... nicht?

Eventuell sollten wir ein Reading erzeugen "dbLocked", auf das andere Module prüfen können. Wenn die DB durch ein Modul gelocked (also benutzt)
wird, können andere Module ihre Abfragen an die DB verschieben (vorallem wenn sie nicht zeitkritisch sind).... aber ich merke schon... ideen gibt es viele :D

schöne Grüße
Joe
FHEM-Server auf IntelAtom+Debian (8.1 Watt), KNX,
RasPi-2 Sonos-FHEM per FHEM2FHEM,RasPi-3 Versuchs-RasPi für WLAN-Tests
Gateways: DuoFern Stick, CUL866 PCA301, CUL HM, HMLan, JeeLink, LaCrosse,VCO2
Synology. Ardurino UNO für 1-Wire Tests, FB7270

DS_Starter

#55
Hi Joe,

ZitatHast Du vor, die schon vorhandenen "doppelten" Einträge in der History zu finden und sie ggf. zu bereinigen?

Wenn ich die Doku unter https://dev.mysql.com/doc/refman/5.7/en/alter-table.html richtig verstanden habe, werden allein schon durch den Einsatz dieser Option die duplicate rows deleted und (ich glaube) die erste vorhandene wird behalten.

Auszug aus der Doku:

Zitat.... If IGNORE is specified, only one row is used of rows with duplicates on a unique key. The other conflicting rows are deleted. Incorrect values are truncated to the closest matching acceptable value......

Ich sehe schon ... du hast viele Ideen  :D  Vielleicht hilft noch mal jemand mit das umzusetzen sonst wird das einen never ending story für mich (wollte ja eigentlich nur das Logging non-blocking gestalten)   ;)

EDIT: Joe, nur beim Start sämtliche Device/Reading_Kombinationen auszulesen und im Mem bereitzustellen reicht nicht. Neue Device/Readings müssen
auch während des Betriebes bereitgestellt werden wenn sie erzeugt wurden. Ist also noch etwas mehr. Aber machbar sollte es sein.


Grüße,
Heiko
ESXi@NUC+Debian+MariaDB, PV: SMA, Victron MPII+Pylontech+CerboGX
Maintainer: SSCam, SSChatBot, SSCal, SSFile, DbLog/DbRep, Log2Syslog, SolarForecast,Watches, Dashboard, PylonLowVoltage
Kaffeekasse: https://www.paypal.me/HMaaz
Contrib: https://svn.fhem.de/trac/browser/trunk/fhem/contrib/DS_Starter

stromer-12

Mit dem Index Time,Device,Reading werden meine Plots langsamer erstellt als mit Device,Reading,Time.
FHEM (SVN) auf RPi1B mit HMser | ESPLink
FHEM (SVN) virtuell mit HMLAN | HMUSB | CUL

ToKa

Hallo zusammen,

erst einmal danke für Eure Überlegungen und Optimierungen an DBLog. Die Idee mit dem PK und dem Löschen der Duplikate finde ich sehr gut. Werde das auch bei mir machen, da immer mal wieder mehrfache, gleiche Einträge entstehen.

Spannend ist nur, wie der PK aufgebaut sein muss bzw. ob es weitere Indexe geben muss. Ein interessanter Artikel ist hier zu finden http://use-the-index-luke.com/de/sql/where/gleichheit/zusammengesetzte-schluessel. Hängt also ganz stark davon ab, wie auf die Daten bzw. auf welche Spalten zugegriffen wird.

Beste Grüße
Torsten
RaspberryPi3 mit RaZberry2 und Conbee II
Fibaro: FGWPE/F-101 Switch & FIBARO System FGWPE/F Wall Plug Gen5, FGSD002 Smoke Sensor
EUROtronic: SPIRIT Wall Radiator Thermostat Valve Control
Shelly2.5 Rollladenaktoren
Zipato Bulb 2, Osram und InnrLight

JoeALLb

#58
Zitat von: stromer-12 am 05 Februar 2017, 20:43:43
Mit dem Index Time,Device,Reading werden meine Plots langsamer erstellt als mit Device,Reading,Time.
Das sind leider sehr wenige Informationen, hast Du mehr für uns?!
Ist das gefühlt oder gemessen?
Hast Du den Index als normalen, oder mit PK angelegt? Hast Du auch das Modul aus #50 installiert? Nur dieses unterstützt PKs und würde eine Verlangsamerung erklären.
Waren das ältere readings oder gar Auswertungen über besonders lange Zeiträume? (Jahre, etc?)
War im Device eventuell sogar eine Wildcard enthalten?
Ich würde das dann in meine Testumgebung mit aufnehmen um ggf. weitere Änderungen aufzunehmen!

Oder Bitte um nähere Details!

sG
Joe
FHEM-Server auf IntelAtom+Debian (8.1 Watt), KNX,
RasPi-2 Sonos-FHEM per FHEM2FHEM,RasPi-3 Versuchs-RasPi für WLAN-Tests
Gateways: DuoFern Stick, CUL866 PCA301, CUL HM, HMLan, JeeLink, LaCrosse,VCO2
Synology. Ardurino UNO für 1-Wire Tests, FB7270

JoeALLb

Zitat von: ToKa am 05 Februar 2017, 20:58:31
erst einmal danke für Eure Überlegungen und Optimierungen an DBLog. Die Idee mit dem PK und dem Löschen der Duplikate finde ich sehr gut. Werde das auch bei mir machen, da immer mal wieder mehrfache, gleiche Einträge entstehen.
Hallo Torsten,
Danke fürs einbringen und die Rückmeldung!
FHEM selbst nutzt eigentlich sehr wenige Abfragen an die DB, ausgenommen Plots.
Hier sind mehrere Indexe sicherlich nicht zu empfehlen.
Aktuell betreibe ich eine recht große Testinstallation, um mehr oder weniger automatisiert tausende Tests durchzuführen.
Hauptziel ist es, ein performantes System auch für kleinere Rechner (zB RPI) zu erhalten, was ohne jeglicher Änderung leider mit
Datenbanksystemen nicht so direkt tauglich ist. Verschiedene Datenbankkonfigurationen spielen hier ebenfalls eine Rolle.
Ob alle Spezialmodule mit dem Standardindex auskommen können oder für diese Zwecke ein zusätzlicher Index (wie es ja im Moment auch schon der Fall ist)
empfohlen werden, hängt von den einzelnen Tests ab.
Hast Du einen konkreten Anwendungsfall, dessen Performance zu wünschen übrig lässt?

sG
Joe
FHEM-Server auf IntelAtom+Debian (8.1 Watt), KNX,
RasPi-2 Sonos-FHEM per FHEM2FHEM,RasPi-3 Versuchs-RasPi für WLAN-Tests
Gateways: DuoFern Stick, CUL866 PCA301, CUL HM, HMLan, JeeLink, LaCrosse,VCO2
Synology. Ardurino UNO für 1-Wire Tests, FB7270