DbLog mit numerischer Spalte

Begonnen von plin, 19 November 2020, 09:48:03

Vorheriges Thema - Nächstes Thema

plin

Hi,

die DbLog-Tabellen werden aktuell wie folgt angelegt:
CREATE TABLE `fhem`.`history` (TIMESTAMP TIMESTAMP, DEVICE varchar(32), TYPE varchar(32), EVENT varchar(512), READING varchar(32), VALUE varchar(32), UNIT varchar(32));
CREATE TABLE `fhem`.`current` (TIMESTAMP TIMESTAMP, DEVICE varchar(32), TYPE varchar(32), EVENT varchar(512), READING varchar(32), VALUE varchar(32), UNIT varchar(32));


Bei Auswertung mittels Grafana bedeutet dies, dass die Spalte VALUE immer mit CAST(value) angegeben werden muss, weil die Inhalte ansonsten von Grafana nicht als numerisch erkannt werden.

Wunsch: eine zusätzliche Spalte VALUEN mit dem numerischen Wert von VALUE sofern der Inahlt numerisch ist.

VG Peter
FHEM1 (Main) Raspi4 mit CUL, Homematic, SDUINO 433/OOK, zentrale Steuerung
FHEM2 (Keller) x86 mit CUL/hmland, IP-basierte Module
FHEM3 (Erdgeschoss) Raspi2 mit SDUINO 868/GFSK
FHEM4 (Hausanschlussraum), USV und OBIS-Modul
FHEM5 (Docker) mit FHEM2FHEM, InfluxDB

betateilchen

*dagegen*

warum?

  • Weil die Funktion cast() genau dafür gedacht ist, an dieser Stelle eingesetzt zu werden.
  • Weil somit schon eine verwendbare Lösung existiert
  • Weil es keinen Sinn macht, redundate Daten in die Datenbank zu schreiben, die von FHEM selbst nicht benutzt werden
  • ... es gibt noch ca. 728 weitere Gründe ...
-----------------------
Formuliere die Aufgabe möglichst einfach und
setze die Lösung richtig um - dann wird es auch funktionieren.
-----------------------
Lesen gefährdet die Unwissenheit!

DS_Starter

#2
Ich gebe betateilchen grundsätzlich Recht. Von meinem Standpunkt aus vor allem in Hinblick darauf, dass eine solche Strukturänderung mit ziemlicher Sicherheit viel Arbeit (für mich) bezüglich Kompatibilität zum Bestand bereiten würde.
Zumal, wie betateilchen schon anmerkte, damit quasi eine Schnittstelle zu einer Nicht-FHEM Komponente gebaut werden soll.

Aber abgesehen davon ich habe auch mal selbst darüber nachgedacht. Im Prinzip kann man bereits mit der vorhandenen Struktur eine solche Nutzung einstellen. Dazu bedarf es im Modul nur einer kleinen unwesentlichen Anpassung.

Und zwar betrifft es  das Attribut valueFn (bzw. DbLogValueFn) mit dem man die zu loggenden Werte verändern kann.
Im Prinzip kann man das Feld/Spalte EVENT für diesen Zweck nutzen.
Normalerweise braucht man die in EVENT geloggten Werte nicht und könnte deswegen die Spalte für eigene Zwecke nutzen.

(Anmerkung: Es kamen vereinzelt auch schon Fragen wieso es diese Spalte überhaupt gibt weil die darin enthaltenen Infos redundant vorhanden sind und sich in den anderen Spalten wiederfinden. @Udo, weißt du welche Historie die Spalte hat ? )

Die individuelle Nutzung von Feld EVENT würde in dem Ansatz von Peter sehr einfach so gehen:


valueFn = {
           $EVENT = <extrahierte Zahl aus $VALUE>;          # Regex auf übergebenen $VALUE anwenden
          }


Mit Grafana holt man sich dann die Werte aus EVENT.

Ich muß nur noch die übergebene Variable $EVENT änderbar machen. Zur Zeit hat man lediglich Lesezugriff darauf, wohingehend aktuell $TIMESTAMP, $READING, $VALUE und $UNIT bereits beschreibbar sind.
Ich muß aber nochmal eingehender prüfen wieso ich $EVENT nicht auch beschreibbar eingerichtet habe, aber ich glaube das hat keinen tieferen Sinn, es gab diese Anforderung nur noch nicht.

@plin, würde diese Lösungsvariante deine Anforderung erfüllen ?

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

betateilchen

#3
aber EVENT ist doch auch als alphanumerisches Feld definiert...

Zitat von: DS_Starter am 21 November 2020, 12:14:04
@Udo, weißt du welche Historie die Spalte hat ?

Vermutlich, um irgendwo mit eigenen Funktionen auf einen gesamten Event zugreifen zu können. In FileLog steht ja schließlich auch der gesamte Event drin.
-----------------------
Formuliere die Aufgabe möglichst einfach und
setze die Lösung richtig um - dann wird es auch funktionieren.
-----------------------
Lesen gefährdet die Unwissenheit!

DS_Starter

Ja richtig. Ich war jetzt der Meinung es würde ausreichen wenn der Inhalt ausschließlich numerisch ist. Wenn das nicht der Fall ist klappt es dann natürlich leider 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

plin

#5
Zitat von: DS_Starter am 21 November 2020, 13:34:11
Ich war jetzt der Meinung es würde ausreichen wenn der Inhalt ausschließlich numerisch ist. Wenn das nicht der Fall ist klappt es dann natürlich leider nicht.
Genau. Grafana ist der Inhalt erst mal relativ egal. Wenn die Spalte als alpha definiert ist mag es die Werte nicht auswerten...

P.S. Ich habe zunächst das (nicht gepflegte) 93_InfluxDBLog.pm Modul zur Bereitstellung der Daten für die Grafana-Grafiken genutzt und überlege nun zum Standard DbLog zu wechseln.
P.P.S. Grafana ist kein Bestandteil von FHEM, liefert aber Super-Grafiken und bietet die Möglichkeit Daten aus verschiedenen Quellen in einer Grafik zusammenzufassen.
FHEM1 (Main) Raspi4 mit CUL, Homematic, SDUINO 433/OOK, zentrale Steuerung
FHEM2 (Keller) x86 mit CUL/hmland, IP-basierte Module
FHEM3 (Erdgeschoss) Raspi2 mit SDUINO 868/GFSK
FHEM4 (Hausanschlussraum), USV und OBIS-Modul
FHEM5 (Docker) mit FHEM2FHEM, InfluxDB

DS_Starter

ZitatGenau. Grafana ist der Inhalt erst mal relativ egal. Wenn die Spalte als alpha definiert ist mag es die Werte nicht auswerten...
Ok, dann hab ich zu simpel gedacht.

Also aus den oben genannten Gründen würde ich den gegenwärtigen Standard nicht verändern wollen.

Allerdings gab es immer mal wieder, aus unterschiedlichen Beweggründen, den Wunsch zusätzliche Felder für eigene Verwendungen verfügbar zu haben. Ich könnte mir vorstellen über die oben erwähnte valueFn zusätzliche Felder beschreibbar zu machen, sagen wir CUSTOM1, CUSTOM2, CUSTOM3 zum Beispiel.

Der (advanced) User wäre dann in der Lage sich diese Felder mit einem Datentyp seiner Wahl in der history-Tabelle anzulegen und über den beschriebenen Mechanismus zu befüllen. Eine solche optionale Möglichkeit könnte ich mir vorstellen, da der aktuelle Standard nicht verändert wird, keine zusätzlichen Daten per default in die DB geschrieben werden und in die etablierte Zusammenarbeit mit SVG, SVG-Editor, DbRep etc. auch nicht beeinflusst.
Der User ist dann natürlich mehr gefordert wenn er sich so etwas einrichten will. Es wäre also etwas für den engagierten Datenbankanwender, für den "Normaluser" würde sich nichts ändern.

Ich habe es mir noch nicht bis in die letzte Konsequenz durchdacht, aber vorstellbar wäre wohl eine solche optionale Möglichkeit.
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

betateilchen

Heiko, ich glaube, damit würdest Du eine ähnlich schwer zu supportende Lösung schaffen, wie das schon bei userReadings und userAttr der Fall ist.
Allerdings mit dem sehr gravierenden Unterschied, dass diese Manipulation in einer der zentralen Komponente (dem Log) von FHEM passieren würde.

Du solltest Dir genau überlegen, ob Du dieses Risiko wirklich eingehen willst. Du kannst als Entwickler gar nicht so doof denken, wie manche Anwender vor sich hin wurschteln.

Es gibt doch mit cast() bereits eine komplett funktionierende Lösung für die Aufgabenstellung, aus alphanumerischen Daten numerische darzustellen. Man muss doch in FHEM nicht immer wieder bereits bestehende Möglichkeiten nachbauen.
-----------------------
Formuliere die Aufgabe möglichst einfach und
setze die Lösung richtig um - dann wird es auch funktionieren.
-----------------------
Lesen gefährdet die Unwissenheit!

DS_Starter

Ich bin ganz bei dir Udo und auch dementsprechend vorsichtig und nicht enthusiastisch. Habe nun auch schon einiges erlebt und weiß wie manch gut gemeinte Möglichkeit sich später in die Büchse der Pandora verwandelt hat.  :o
DbLog läuft nun schon geraume Zeit sehr gut und es gibt kaum Fehlermeldungen bzw. Supportbedarf. Das schont das (mein) Zeitbudget und soll auch so bleiben. Stabilität hat absolute Prio vor Features.
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