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

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

Vorheriges Thema - Nächstes Thema

DS_Starter

Hi Joe,

na dann gute Besserung !!
Vielleicht findet sich ja noch ein weiterer Mitstreiter ...

LG,
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

Pyromane

Hallo Heiko,

läuft seit gestern auf meinem Testfhem problemlos.

Grüße
Pyro

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

DS_Starter

Habe die Version 3.12.0 eingecheckt und aus contrib wieder entfernt.
Ist morgen früh im regulären Update.

Danke nochmal fürs mittesten Pyro !

LG,
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

Danke fürs einchecken! Blieb bei mir bisher unauffällig, was j aein gutes Zeichen ist ;-)

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

Guten Morgen zusammen,

für das Winterhalbjahr habe ich geplant eine neue DbLog-Version speziell für MariaDB aufzubauen.
Arbeitsname wäre z.B. MDbLog für (Maria DbLog).
Das bisherige DbLog bleibt so erhalten wie es jetzt ist. Bis auf Bugfixes würde ich aber nichts mehr implementieren.

Das neue MDbLog würde dann ausschließlich MariaDB unterstützen und dafür wäre es aber möglich die speziellen Features von MariaDB einzusetzen.
Für MDbLog hätte ich bis jetzt folgende Merkmale im Sinn:

* Count, reducelog und Co. fällt weg. Reducelog überführe ich in DbRep damit die Funktion weiterhin zur Verfügung steht.
* Anlegen der DB, Tabellen, Indizes erfolgt automatisiert
* Das Db-Konfigfile wird automatisch erstellt und ggf. geändert. Der User muss selbst keine Datei vorher erstellen
* Unterstützung von Partitionen
* Strukturänderungen (Feldbreiten) sollen einfach über set für den User änderbar sein
* Unterstützung eigener Felder, die z.B. für Löschmerkmale etc. verwendet werden könnten
* ....

Was haltet ihr davon ? (Ich will mir keine Arbeit machen die anschließend niemand braucht ;) )
Ihr seid gern eingeladen Ideen einzubringen und an der Umsetzung mitzuwirken.

LG,
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 sehr spannend! Finde es auch gut, das Modul "sauber" zu halten.
Eventuell könnten wir in diesem Zusammenhang auch mit DbLogExclude und DbLogINclude aufräumen?
Das wäre denke ich auch mein einziger Vorschlag einer größeren Änderung...
Die Verwendung davon vorallem auch mit der Treshold-Angabe ist etwas verwirrend und wird daher meiner Meinung nach nicht wirklich genutzt.Ich denke, man benötigt das alles etwas anders.
zB. sollte man nicht auf "event-on-change" Einträge angewiesen sein, wenn man gewisse Werte nicht doppelt in der DB haben möchte. Ich habe da mehrtere Fälle als Beispiel, wo ich das so gar nicht nutzen kann.
(zB benötigt mein Heizaktor vom Termostat mind. alle 20 Minuten einen Temperaturwert, sonst geht eh auf Störung. Somit kann ich "event-on-change" nicht wirklich nutzen, da ich ja die events benötige. In der Datenbank selbst benötige ich jedoch keine doppelten Temperaturwerte. Daher denke ich, sollte das getrennt werden.

Den Code dafür hätte ich sogar schon mal geschrieben, und wäre auch bereit, den für das neue Modul nochmal umzuschreiben, soweit es meine Fähigkeiten entspricht.


Mein Vorschlag wäre also ein Attribut in etwa in der Form:

attr MDbLogconfig
[+-][reading]:[all (default)|onchange]:[range]

Beschreibung:

Add or Exclude from Log  # readingname # mode # range: optional, benötigeich nicht unbedingt: angabe eines ranges, außerhalb dessen ein Wert nochmals geloggt wird.
zB. um Temperatursprünge von 0.1° auszuschließen




also zB
attr MDbLogconfig
+temperatur:onchange
+state
+humidity:all:5
-last-sender


Ich denke, so wäre eine Steuerung des Loggings sehr einfach und klar verständlich möglich und er wäre deutlich logischer aufgebaut als die DBLog-Bariante.
Eine Überführung des Attributes wäre theoretisch sogar automatisch möglich von DbLogExclude/include nach MDbLogconfig.




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

raimundl

Bin gerne dabei und wünsche mir eine anfängerfreundliche Anleitung zur Inbetriebnahme.

Danke und LG
Homematic: Licht, Heizung, Alarm, Alexa ... auf einen RaspberryPi3+mit OS "Stretch" und RPI-RF-MOD mit piVCCU3 (HMCCU), ca. 40 HM Komponenten, alexa, MobileAlerts, Hue Ledstripes....

DS_Starter

Hallo zusammen,

danke für eure Wortmeldungen.
Ich denke zu gegebener Zeit mache ich einen separaten Thread dafür auf.

@Joe, wäre es so zu verstehen, dass "+" das bisherige DbLogInclude und "-" das bisherige "DbLogExclude" ersetzen soll ?
Irgenwie müsste es auch noch eine Verknüpfung mit dem Device-Namen geben, der in deiner bisherigen Darstellung fehlt. Hattest du dir darüber auch schon Gedanken gemacht ? Da es dann kein gesetztes Attribut mehr in den Quelldevices gibt, müsste alles in dem DbLog-Device gehalten werden ... Übersichtlichkeit ??

LG,
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,

es war auch nur eine Idee. Aber gerade die Übersichtlichkeit denke ich sollte damit deutlich steigen! UNd wir hätten auch Platz für weitere Parameter.

Den Devicenamen habe ich nur vergessen!

Ich würde pro Device es so handhaben:

attr <Device> MDbLogconfig
+temperatur:onchange:partition9
+state:partition8
+humidity:all:5
-last-sender


und im Logdevice selbst ein
attr <Device> MDbLogconfigGlobal
nutzen, was weitestgehend dem jetzigen
excludeDevs
entspricht und ja genau dafür genutzt werden kann, Global gewisse Devices, Typen oder Readings zu sperren, auszuschließen, verhindern....

Im Beispiel oben für die Devices könne man so locker gewisse Attribute ergänzen, wie zB eben auch in welcher Partition es gespeichert werden soll. (Eben direkt in die "Kurzzeitpartition", weil man schon weiß, dass man diesen Wert nur zur Berechnung des Stundenmittels benötigt und ihn danach wegwerfen kann).

Im Extremfall könnte man dort sogar eine Wertänderung erlauben, ähnlich wie valueFn nur eben Devicespezifisch:

+temperatur:onchange:partition9:$value=($value=~'^true'?1:0)

Aber das alles wäre sicherlich nur zukunftsmusik und nicht direkt notwendig. Ich möchte damit nur aufzeigen, wie flexibel dies wäre.
Im Zusammenhang mit dem neuen direkten Einblenden der Hilfe in FHEM (siehe Screenshot), ist sicherlich auch die Notation keine große Hürde mehr!


Auch der Name ist natürlich nur eine schnelle Idee.... vielleicht gibts da was prägnanteres?!?


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

Ah, ok. Jetzt ist es mir klarer geworden. Finde ich gut !
Würde ich mit vorsehen und wir schauen dann wie es sich in der Praxis gestaltet.
Die neuen Attributhilfen habe ich auch schon gesehen, aber weiß noch nicht wie man die im eigenen Modul einblendet.
"Einfach so" passiert es jedenfalls nicht.
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

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

Ja, das kenne ich. Hat bei meinen Experimenten aber bis jetzt nicht funktioniert.

So habe ich es mal probiert in der Commandref:

<a name="addStateEvent"></a>

Irgendwas stimmt da noch nicht.
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

Ha, jetzt habe ich es mal komplett für ein ganzes Modul durchgezogen (Log2Syslog) und nun funktioniert es.  ;)
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

Zitat von: DS_Starter am 02 Oktober 2018, 14:09:23
Ah, ok. Jetzt ist es mir klarer geworden. Finde ich gut !
Würde ich mit vorsehen und wir schauen dann wie es sich in der Praxis gestaltet.
Die neuen Attributhilfen habe ich auch schon gesehen, aber weiß noch nicht wie man die im eigenen Modul einblendet.
"Einfach so" passiert es jedenfalls nicht.

Habe ein bisschen überlegt, und denke, man könnte eventuell auch über dieses Konstrukt einfach mehrere unterschiedliche Tabellen anstatt Partitionen nutzen Punkt eine Tabelle Kurzzeitspeicher wäre genauso schnell gelöscht. Die Berechnungen davon die History zu übertragen wäre ebenfalls schnell Punkt lediglich Abfragen für Plots müsste man wohl über alle Tabellen einzeln laufen lassen oder Union nutzen...
Nur mal so als Überlegung ;-)

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