SVG mit dblog extrem langsam

Begonnen von RockThisParty, 06 Januar 2023, 10:07:54

Vorheriges Thema - Nächstes Thema

RockThisParty

Danke für Deine Geduld. Bin jetzt auch noch die nächste Stunde durchgängig am Rechner ;-)
checkConfig blockiert nach meinem Eindruck FHEM komplett. Auch in anderen Browser-Sessions geht nichts mehr mit FHEM. bzgl. Fehlermeldung bin ich mir nicht sicher. Habe nie mehr als 10 Minuten gewartet.  :-[

Habe dnsServer jetzt gesetzt. War vorher nicht da. Hat leider nach erstem Eindruck nix geändert. Starte FHEM gleich noch mal neu.

dns hatte ich auch schon im Blick. Update funktioniert immer reibungslos. Ich habe sehr sporadisch unten in der Statusleiste, wenn ich was mit FHEM versuche einen cloudflare-Aufruf stehen, ebenso sehr sporadisch wird mein lokaler Aufruf vom NAS nicht korrekt aufgelöst. Alle DB-Anfragen gehen aber m.E. über feste IP im lokalen Netz.

RockThisParty

Logfile rund um configcheck von gerade eben:
2023.01.06 22:48:54 4: DbLog logdb - ################################################################
2023.01.06 22:48:54 4: DbLog logdb - ###      New database processing cycle - SBP asynchronous    ###
2023.01.06 22:48:54 4: DbLog logdb - ################################################################
2023.01.06 22:48:54 4: DbLog logdb - MemCache contains 1 entries to process
2023.01.06 22:48:54 4: DbLog logdb - DbLogType is: History
2023.01.06 22:48:54 5: DbLog logdb - MemCache contains:  985 -> 2023-01-06 22:48:53|jonathan_Heizung_HMIP|HMCCUDEV|temperature_soll: 5|temperature_soll|5|
2023.01.06 22:48:54 4: DbLog logdb - Operation: log_asynch
2023.01.06 22:48:54 5: DbLog logdb - DbLogType: History
2023.01.06 22:48:54 4: DbLog logdb - AutoCommit: ON, Transaction: ON
2023.01.06 22:48:54 4: DbLog logdb - Insert mode: Array
2023.01.06 22:48:54 4: DbLog logdb - Primary Key used in history: TIMESTAMP,DEVICE,READING
2023.01.06 22:48:54 4: DbLog logdb - Primary Key used in current: DEVICE,READING
2023.01.06 22:48:54 5: DbLog logdb - processing 985 -> TS: 2023-01-06 22:48:53, Dev: jonathan_Heizung_HMIP, Type: HMCCUDEV, Event: temperature_soll: 5, Reading: temperature_soll, Val: 5, Unit:
2023.01.06 22:48:54 4: DbLog logdb - begin Transaction
2023.01.06 22:48:54 4: DbLog logdb - commit inserted data table history
2023.01.06 22:48:54 4: DbLog logdb - 1 of 1 events inserted into table history using PK on columns TIMESTAMP,DEVICE,READING
2023.01.06 22:49:03 4: DbLog logdb - configCheck: Got remote controls_fhem.txt with 2495 entries.
2023.01.06 22:49:03 4: DbLog logdb - configCheck: Got local controls_fhem.txt with 2495 entries.
2023.01.06 22:49:03 4: DbLog logdb - configCheck: local version from last update - creation time: 2022-12-30_07:45:03 - bytes: 469411
2023.01.06 22:49:03 4: DbLog logdb - Executing SQL: SHOW VARIABLES LIKE 'character_set_connection'
2023.01.06 22:49:23 4: DbLog logdb - SQL result: character_set_connection utf8
2023.01.06 22:49:23 4: DbLog logdb - Executing SQL: SHOW VARIABLES LIKE 'character_set_database'
2023.01.06 22:49:43 4: DbLog logdb - SQL result: character_set_database utf8
2023.01.06 22:49:43 4: DbLog logdb - Executing SQL: SHOW FIELDS FROM history where FIELD='DEVICE'
2023.01.06 22:50:03 4: DbLog logdb - SQL result: DEVICE varchar(64) NO PRI 
2023.01.06 22:50:03 4: DbLog logdb - Executing SQL: SHOW FIELDS FROM history where FIELD='TYPE'
2023.01.06 22:50:23 4: DbLog logdb - SQL result: TYPE varchar(64) YES   
2023.01.06 22:50:23 4: DbLog logdb - Executing SQL: SHOW FIELDS FROM history where FIELD='EVENT'
2023.01.06 22:50:43 4: DbLog logdb - SQL result: EVENT varchar(512) YES   
2023.01.06 22:50:43 4: DbLog logdb - Executing SQL: SHOW FIELDS FROM history where FIELD='READING'
2023.01.06 22:51:03 4: DbLog logdb - SQL result: READING varchar(64) NO PRI 
2023.01.06 22:51:03 4: DbLog logdb - Executing SQL: SHOW FIELDS FROM history where FIELD='VALUE'
2023.01.06 22:51:23 4: DbLog logdb - SQL result: VALUE varchar(128) YES   
2023.01.06 22:51:23 4: DbLog logdb - Executing SQL: SHOW FIELDS FROM history where FIELD='UNIT'
2023.01.06 22:51:43 4: DbLog logdb - SQL result: UNIT varchar(32) YES   
2023.01.06 22:51:43 4: DbLog logdb - Executing SQL: SHOW FIELDS FROM current where FIELD='DEVICE'
2023.01.06 22:52:03 4: DbLog logdb - SQL result: DEVICE varchar(64) NO PRI 
2023.01.06 22:52:03 4: DbLog logdb - Executing SQL: SHOW FIELDS FROM current where FIELD='TYPE'
2023.01.06 22:52:23 4: DbLog logdb - SQL result: TYPE varchar(64) YES   
2023.01.06 22:52:23 4: DbLog logdb - Executing SQL: SHOW FIELDS FROM current where FIELD='EVENT'
2023.01.06 22:52:43 4: DbLog logdb - SQL result: EVENT varchar(512) YES   
2023.01.06 22:52:43 4: DbLog logdb - Executing SQL: SHOW FIELDS FROM current where FIELD='READING'
2023.01.06 22:53:03 4: DbLog logdb - SQL result: READING varchar(64) NO PRI 
2023.01.06 22:53:03 4: DbLog logdb - Executing SQL: SHOW FIELDS FROM current where FIELD='VALUE'
2023.01.06 22:53:23 4: DbLog logdb - SQL result: VALUE varchar(128) YES   
2023.01.06 22:53:23 4: DbLog logdb - Executing SQL: SHOW FIELDS FROM current where FIELD='UNIT'
2023.01.06 22:53:43 4: DbLog logdb - SQL result: UNIT varchar(32) YES   
2023.01.06 22:53:43 4: DbLog logdb - Executing SQL: SHOW INDEX FROM history where Key_name='Search_Idx'
2023.01.06 22:54:03 4: DbLog logdb - SQL result: history 1 Search_Idx 1 DEVICE A 12    BTREE 
2023.01.06 22:54:03 4: DbLog logdb - Executing SQL: SHOW INDEX FROM history where Key_name='Search_Idx' and Column_name='DEVICE'
2023.01.06 22:54:23 4: DbLog logdb - SQL result: history 1 Search_Idx 1 DEVICE A 12    BTREE 
2023.01.06 22:54:23 4: DbLog logdb - Executing SQL: SHOW INDEX FROM history where Key_name='Search_Idx' and Column_name='READING'
2023.01.06 22:54:43 4: DbLog logdb - SQL result: history 1 Search_Idx 2 READING A 12    BTREE 
2023.01.06 22:54:43 4: DbLog logdb - Executing SQL: SHOW INDEX FROM history where Key_name='Search_Idx' and Column_name='TIMESTAMP'
2023.01.06 22:55:03 4: DbLog logdb - SQL result: history 1 Search_Idx 3 TIMESTAMP A 368832    BTREE 
2023.01.06 22:55:03 5: DbLog logdb - DbRep-Device 'dbrep' uses logdb.
2023.01.06 22:55:03 4: DbLog logdb - Executing SQL: SHOW INDEX FROM history where Key_name='Report_Idx'
2023.01.06 22:55:23 4: DbLog logdb - SQL result:
2023.01.06 22:55:44 5: DbLog logdb: Table current present : 0 (0 = not present or no content)
2023.01.06 22:55:44 3: abfahrt_st_heinrich: Read callback: Error: reiseauskunft.bahn.de: Connection reset by peer (104)
2023.01.06 22:55:44 2: deconz: http request failed: read from http://192.168.178.10:80 timed out
2023.01.06 22:55:53 4: DbLog logdb - ################################################################
2023.01.06 22:55:53 4: DbLog logdb - ###      New database processing cycle - SBP asynchronous    ###
2023.01.06 22:55:53 4: DbLog logdb - ################################################################
2023.01.06 22:55:53 4: DbLog logdb - MemCache contains 11 entries to process
2023.01.06 22:55:53 4: DbLog logdb - DbLogType is: History
2023.01.06 22:55:53 5: DbLog logdb - MemCache contains:  986 -> 2023-01-06 22:55:24|aussenfuehler_HMIP|HMCCUDEV|1.HUMIDITY: 99|1.HUMIDITY|99|
2023.01.06 22:55:53 5: DbLog logdb - MemCache contains:  987 -> 2023-01-06 22:55:24|aussenfuehler_HMIP|HMCCUDEV|state: 6.9|state|6.9|
2023.01.06 22:55:53 5: DbLog logdb - MemCache contains:  988 -> 2023-01-06 22:55:24|aussenfuehler_HMIP|HMCCUDEV|1.ACTUAL_TEMPERATURE: 6.9|1.ACTUAL_TEMPERATURE|6.9|
2023.01.06 22:55:53 5: DbLog logdb - MemCache contains:  989 -> 2023-01-06 22:55:24|jonathan_Heizung_HMIP|HMCCUDEV|temperature_soll: 5|temperature_soll|5|
2023.01.06 22:55:53 5: DbLog logdb - MemCache contains:  990 -> 2023-01-06 22:55:44|aussenfuehler_HMIP|HMCCUDEV|1.HUMIDITY: 99|1.HUMIDITY|99|
2023.01.06 22:55:53 5: DbLog logdb - MemCache contains:  991 -> 2023-01-06 22:55:44|aussenfuehler_HMIP|HMCCUDEV|state: 6.8|state|6.8|
2023.01.06 22:55:53 5: DbLog logdb - MemCache contains:  992 -> 2023-01-06 22:55:44|aussenfuehler_HMIP|HMCCUDEV|1.ACTUAL_TEMPERATURE: 6.8|1.ACTUAL_TEMPERATURE|6.8|
2023.01.06 22:55:53 5: DbLog logdb - MemCache contains:  993 -> 2023-01-06 22:55:44|jonathan_Heizung_HMIP|HMCCUDEV|temperature_soll: 5|temperature_soll|5|
2023.01.06 22:55:53 5: DbLog logdb - MemCache contains:  994 -> 2023-01-06 22:55:44|aussenfuehler_HMIP|HMCCUDEV|state: 6.8|state|6.8|
2023.01.06 22:55:53 5: DbLog logdb - MemCache contains:  995 -> 2023-01-06 22:55:44|aussenfuehler_HMIP|HMCCUDEV|1.ACTUAL_TEMPERATURE: 6.8|1.ACTUAL_TEMPERATURE|6.8|
2023.01.06 22:55:53 5: DbLog logdb - MemCache contains:  996 -> 2023-01-06 22:55:44|aussenfuehler_HMIP|HMCCUDEV|1.HUMIDITY: 99|1.HUMIDITY|99|

RockThisParty

Nach dem Klick auf den Aufruf für das SVG erscheint in der Statuszeile

"Warten auf d36m9g8osz0lpw.cloudfront.net..."

Das macht mich massiv stutzig...

DS_Starter

#18
Zitat
checkConfig blockiert nach meinem Eindruck FHEM komplett.
Wenn das passiert ist es eine heiße Spur das etwas nicht stimmt. Frage ist nur was.

Neben dem angesprochenen Versions-check werden Verbindungen zur DB aufgerufen die grundlegende Dinge abrufen, Spaltenbreiten, Indizes usw.

Deine Ausgaben ...

Zitat
...
2023.01.06 22:55:03 4: DbLog logdb - Executing SQL: SHOW INDEX FROM history where Key_name='Report_Idx'
2023.01.06 22:55:23 4: DbLog logdb - SQL result:
2023.01.06 22:55:44 5: DbLog logdb: Table current present : 0 (0 = not present or no content)
2023.01.06 22:55:44 3: abfahrt_st_heinrich: Read callback: Error: reiseauskunft.bahn.de: Connection reset by peer (104)
2023.01.06 22:55:44 2: deconz: http request failed: read from http://192.168.178.10:80 timed out
Der configCheck läuft bis zum Ende durch. SHOW INDEX FROM history where Key_name='Report_Idx' ist der letzte Check, danach kommt nur noch die Browserausgabe.

Nun fallen mir gleich die Timeouts von deconz bzw. abfahrt_st_heinrich ins Auge. Man sieht auch ziemlich genau 20 Sekunden zwischen 2023.01.06 22:55:23 4: DbLog logdb - SQL result:   und   2023.01.06 22:55:44 3: abfahrt_st_heinrich: Read callback: Error: reiseauskunft.bahn.de: Connection reset by peer (104).

Ich würde mal abfahrt_st_heinrich disablen.

Zitat
Nach dem Klick auf den Aufruf für das SVG erscheint in der Statuszeile

"Warten auf d36m9g8osz0lpw.cloudfront.net..."

Das macht mich massiv stutzig...
Da bin ich 100%ig bei dir.  :o
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

#19
Schau mal hier -> https://dieviren.de/d2ucfwpxlh3zh3-cloudfront-net/

Und ...

Zitat
Ich habe sehr sporadisch unten in der Statusleiste, wenn ich was mit FHEM versuche einen cloudflare-Aufruf stehen, ebenso sehr sporadisch wird mein lokaler Aufruf vom NAS nicht korrekt aufgelöst.

Es verdichten sich m.M. nach die Zeichen die auf ein Virenproblem hindeuten ...
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

RockThisParty

Danke. Das cloudflare-Thema schaue ich mir separat mal an. Könnte auch sein, dass das mit installierten Erweiterungen in Chrome zu tun hat.
Scheint aber mit dem SVG-Thema nichts zu tun zu haben. Das Phänomen tritt identisch in Chrome on MacOS, Safari on MacOS und Safari on iPadOS auf.

Das httpmod abfahrt_ ... habe ich disabled. Leider ohne Erfolg. Ich tippe darauf, dass das eher Folgefehler des Problems vorher sind? Allerdings neigt die Abfahrtstafel tatsächlich dazu, ein paar mal am Tag auf einen timeout zu laufen, aber auf keinen Fall so regelmäßig.
:-\

Edit:
Sonst müsste das Virenproblem ja im docker-Container stecken ...

DS_Starter

#21
Naja, wenn der Browser blockiert bekommst du keine Ausgaben von FHEM(WEB), keine Return-Ausgabe des configCheck , der SVG über Javascript ....
Ist jetzt ein bisschen schwierig für mich mir eine eindeutige Meinung zu bilden. Aber ich denke all das was du bisher beschrieben hast, sind Folgeerscheinungen eines noch versteckten Verursachers der wahrscheinlich nicht im FHEM selbst steckt.

Vllt. gibt es Mitleser (Rudi?) die noch Ideen dazu haben ?

Noch zur Ergänzung ... Timeouts bei FHEM-Modulen sind per se nicht problematisch, nur dann wenn das entsprechende Modul nicht non-blocking gebaut wurde, was der Anwender wiederum nicht unbedingt erkennen kann. Das nur damit du die Timeouts richtig einordnest.
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

RockThisParty

Auf alle Fälle erstmal ein riesiges Dankeschön für heute!!  :) :) :) Und eine gute Nacht!

DS_Starter

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

rudolfkoenig

ZitatVllt. gibt es Mitleser (Rudi?) die noch Ideen dazu haben ?

Da die 20 Sekunden nach sowas wie
Executing SQL: SHOW VARIABLES LIKE 'character_set_connection'
auftreten, also bei einer Operation, was keinen Plattenzugriff oder Rechnzeit benoetigt, habe ich die DB in Verdacht, die 20 Sekunden lang versucht einen Rechnernamen fuer den Client (d.h. FHEM) zu finden, um den Zugriff protokollieren zu koennen.

DS_Starter

Zitat
Da die 20 Sekunden nach sowas wie
Code: [Auswählen]

Executing SQL: SHOW VARIABLES LIKE 'character_set_connection'

auftreten, also bei einer Operation, was keinen Plattenzugriff oder Rechnzeit benoetigt, habe ich die DB in Verdacht, die 20 Sekunden lang versucht einen Rechnernamen fuer den Client (d.h. FHEM) zu finden, um den Zugriff protokollieren zu koennen.

Ja, könnte der TE mal prüfen ob die Namensauflösung auf der Synology funktioniert. Allerdings verwendet er IP-Adressen soweit ich gesehen habe.

Die Zeit zwischen Anfrage und Ergebnis ist schon verdächtig:

2023.01.06 22:54:43 4: DbLog logdb - Executing SQL: SHOW INDEX FROM history where Key_name='Search_Idx' and Column_name='TIMESTAMP'
2023.01.06 22:55:03 4: DbLog logdb - SQL result: history 1 Search_Idx 3 TIMESTAMP A 368832    BTREE
 
2023.01.06 22:55:03 5: DbLog logdb - DbRep-Device 'dbrep' uses logdb.
2023.01.06 22:55:03 4: DbLog logdb - Executing SQL: SHOW INDEX FROM history where Key_name='Report_Idx'
2023.01.06 22:55:23 4: DbLog logdb - SQL result:


Es gibt zwei Anfragen bzgl. evtl. Indizes. In beiden Fällen vergehen genau 20 Sekunden bis zu einer Antwort der DB.
Auch bei anderen Abfragen wie hier

2023.01.06 22:49:03 4: DbLog logdb - Executing SQL: SHOW VARIABLES LIKE 'character_set_connection'
2023.01.06 22:49:23 4: DbLog logdb - SQL result: character_set_connection utf8
2023.01.06 22:49:23 4: DbLog logdb - Executing SQL: SHOW VARIABLES LIKE 'character_set_database'
2023.01.06 22:49:43 4: DbLog logdb - SQL result: character_set_database utf8
2023.01.06 22:49:43 4: DbLog logdb - Executing SQL: SHOW FIELDS FROM history where FIELD='DEVICE'
2023.01.06 22:50:03 4: DbLog logdb - SQL result: DEVICE varchar(64) NO PRI 
2023.01.06 22:50:03 4: DbLog logdb - Executing SQL: SHOW FIELDS FROM history where FIELD='TYPE'
2023.01.06 22:50:23 4: DbLog logdb - SQL result: TYPE varchar(64) YES   
2023.01.06 22:50:23 4: DbLog logdb - Executing SQL: SHOW FIELDS FROM history where FIELD='EVENT'
2023.01.06 22:50:43 4: DbLog logdb - SQL result: EVENT varchar(512) YES   
2023.01.06 22:50:43 4: DbLog logdb - Executing SQL: SHOW FIELDS FROM history where FIELD='READING'
2023.01.06 22:51:03 4: DbLog logdb - SQL result: READING varchar(64) NO PRI 
2023.01.06 22:51:03 4: DbLog logdb - Executing SQL: SHOW FIELDS FROM history where FIELD='VALUE'
2023.01.06 22:51:23 4: DbLog logdb - SQL result: VALUE varchar(128) YES   
2023.01.06 22:51:23 4: DbLog logdb - Executing SQL: SHOW FIELDS FROM history where FIELD='UNIT'


vergehen zwischen "Executing" und "SQL result" immer genau 20 Sekunden.

Ich bin relativ ratlos was eine DB dazu bringen könnte derart genau und regelmäßig zu verzögern.
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

#26
Ich ahne etwas.
Die Abfragen im configCheck sind Einzelabfragen, d.h. es wird vor dem Exec jeweils die Datenverbindung aufgebaut und danach wieder abgebaut.

Das gleiche findet statt wenn Daten für die SVG Erstellung abgerufen werden.

Ich könnte das Verfahren abändern und die Datenverbindung offen lassen. Dann würde der TE wahrscheinlich beim ersten Abruf eine Verzögerung feststellen und sich wundern. Dem aber keine Bedeutung beimessen weil die nächsten Abrufe dann zügig ablaufen.

Wenn die Vermutung stimmt, ist nur der Verbindungsaufbau zur DB lahm und wird durch Connecting Verfahren offensichtlich.
Mit dem Attr plotfork = 1 im FHEMWEB wird auf jeden Fall für den nebenläufigen Prozess jeweils eine neue DB-Verbindung aufgebaut.

Ich werde eine V erstellen um diese Theorie prüfen zu lassen.
Dennoch sollte RockThisParty m.M. nach die DB prüfen.
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

RockThisParty

Guten Morgen  :)

Ich habe heute Vormittag nur noch eine halbe Stunde, um was auszuprobieren.
Schaue mir gerade MariaDB - Konfig an, bin aber ziemlich ratlos.

Wenn es etwas gibt, wo ich direkt prüfen könnte, wäre ich für einen Hinweis dankbar.

Was mir rund um DNS noch eingefallen ist: Ich habe in der letzten Zeit meine Fritz!Box tauschen müssen, die neue aber aus dem Backup der alten aufgesetzt. Vielleicht hängen da noch irgendwelche falschen internen DNS-Einträge?


DS_Starter


Ich habe heute Vormittag nur noch eine halbe Stunde, um was auszuprobieren.

So schnell bin ich nicht. Ggf. heute Abend.

Zitat
Was mir rund um DNS noch eingefallen ist: Ich habe in der letzten Zeit meine Fritz!Box tauschen müssen, die neue aber aus dem Backup der alten aufgesetzt. Vielleicht hängen da noch irgendwelche falschen internen DNS-Einträge?

Das solltest du auf jeden Fall überprüfen.
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

RockThisParty

Supi! Ich schaue auf alle Fälle heute Abend rein.