Neues Charting / Plotting - GUI Redesign?

[Johannes]

Hi,

Ich kann leider nicht den ganzen Eintrag der Spalte EVENT sehen auf deinem Screenshot.
Am besten wartest du noch auf das nächste Relase, ich habe das Speichern und Löschen da nochmal überarbeitet, vielleicht löst sich das Problem dann von selbst.

[Smooth]

... ich glaube das ist der gesamte Inhalt von Event....
evtl. ist dort auch das Problem zu finden ?!?

Könnte das sein, oder lese ich "Event" falsch aus?

Gruß Michael

[Johannes]

Ich kenne auch das Verhalten, dass die Anzeige u.U. abgeschnitten wird.
Bringt ein

select EVENT from history where READING = "savedchart";

das gleich Ergbnis?
Wenn ja, musst du mal schauen wieviele Zeichen in der Event Spalte bei dir erlaubt sind. Mit den SQLs mit denen man DbLog einrichtet sollten die mindestens 256 cahracters haben, unter MySQL aber eigentlich unendlich wenn nicht definert. Welches MySQL kommt zum Einsatz?

Du kannst auch mal einen insert prüfen mit einem langen String, über 256 Zeichen und schauen ob dieser abgeschnitten wird:

INSERT INTO history (EVENT, READING) VALUES ("1234567890testtester1234567890testtester1234567890testtester1234567890testtester1234567890testtester1234567890testtester1234567890testtester1234567890testtester1234567890testtester1234567890testtester1234567890testtester1234567890testtester1234567890testtester1234567890testtester", "savedchart");

Unter SQLite wird hier nicht gekürzt in diesem Beispiel (ca. 280 Zeichen).

[Smooth]

Hi,

ein...

select EVENT from history where READING = "savedchart";

ausprobiert.... das Ergebnis ist wie folgt auch abgeschnitten:

(siehe Anhang / see attachement)

Das Einfügen eines langen Stings mit...

INSERT INTO history (EVENT, READING) VALUES ("1234567890testtester1234567890testtester1234567890testtester1234567890testtester1234567890testtester1234567890testtester1234567890testtester1234567890testtester1234567890testtester1234567890testtester1234567890testtester1234567890testtester1234567890testtester1234567890testtester", "savedchart");

brachte folgendes Ergebnis... leider auch abgeschnitten:

(siehe Anhang / see attachement)

Und meine eingesetzte MYSQL-Version ist....

(siehe Anhang / see attachement)

Hast du noch eine Idee? Hab ich die Datenbank falsch eingerichtet?

Gruß Michael

[Smooth]

Hi Johannes,


es scheint an Mysql zu liegen.... Schau mal was ich gefunden habe...:

(siehe Anhang / see attachement)

Laut definition darf bei mysql ein Bezeichner lediglich 64 Zeichen lang sein. Und genau da schneidet er ab....

Wie können wir das Problem lösen?

Muss ich von mysql auf SQLlite umsteigen?

Viele Grüße

Michael

[Johannes]

Hi,

Du hast recht, das war mein Fehler, ich hatte 512 Zeichen im Kopf, aber das galt nur für PostgreSQL.
Das Script für DbLog legt bei MySQL tatäschlich nur eine Spalte mit 64 Zeichen an, das ist zu kurz für meine Bedürfnisse.
Ich werde das im SVN korrigieren, falls da niemand Einwände hat.

Du kannst das Problem relativ einfach lösen, indem du

ALTER TABLE history MODIFY EVENT VARCHAR(512)

abfeuerst. Danach solltest du deine bisherigen gespeicherten Charts löschen, da sie unbrauchbar sind.
Das was du rausgesucht hast gilt glaube ich für die Spaltenbezeichnung / Name, nicht aber für den Inhalt.

[Smooth]

Was soll ich sagen....


Länge mittels:

ALTER TABLE history MODIFY EVENT VARCHAR(512)

angepasst. Alte Save-Einträge aus Datenbank gelöscht.

Und siehe da es funktioniert....

Also alle die mySQL verwenden EVENT-Länge anpassen, dann klappt es auch mit dem Speichern bzw. Laden....

Vielen Dank für die Unterstützung... so macht FHEM riesen Spaß

Gruß Michael

[Johannes]

Super, dann ist das ja gelöst, ich werde dann das Script anpassen.

[Johannes]

Ich habe mal eine Abstimmung erstellt, was eurer Meinung nach als nächstes integriert werden soll.
Falls Ihr bestimmte Wünsche habt, nehme ich die gerne mit auf!

[erwin]

Hi Johannes,

ich hab deinen Beitrag bez. Ändern der SQL struktur im Developers Forum gelesen,
kann aber nur hier antworten:

Ich nehme an, daß es um die definition der charts geht, oder?
wär es nicht vernünftiger, eine eine eigene tabelle zu definieren,
mit exakt der struktur, die du fürs speichern der chart definitionen brauchst?

z. b. in etwa soo:
CREATE TABLE `fhem`.`charts` (TIMESTAMP TIMESTAMP, DEVICE varchar(32),CHARTNAME varchar (32) , CHARTTYPE varchar (xx), ...
Pro Argumente:
1) mit einer eigenen struktur nehme ich an, dass du nicht soo schnell auf das 512byte limit kommst....
2) Das würde auch das parsen beim speichern und laden der chart's vereinfachen, oder ?
3) ... ich kann jetzt nicht beurteilen, ob diese Änderung ein der history Tabelle einen Einfluß auf die DB-Performance hätte, aber ich hab schon viele records drin.... (10000+)
4) Wir würden nichts ändern brauchen, ;-)) , sondern eine table hinzufügen.....

l.g. erwin

[Smooth]

Hi Johannes,


mir ist da noch eine Kleinigkeit aufgefallen.....

Es war wieder etwas kälter heute Nacht ;-)

(siehe Anhang / see attachement)

Scheinbar möchte das Charting keine Temperaturen <0°C darstellen

Ist das schon mal aufgefallen?


Gruß Michael

[Johannes]

wär es nicht vernünftiger, eine eine eigene tabelle zu definieren,
mit exakt der struktur, die du fürs speichern der chart definitionen brauchst?

Hallo Erwin,
Daran habe ich natürlich schon gedacht. Bisher habe ich aber eigentlich vermeiden wollen, dass der Anwender, bevor er das Frontend nutzen kann, erstmal 10 Schritte tut.
Bzw. ich möchte den Installationsaufwand möglichst gering halten. Ich bin da noch nicht ganz entschlossen, auf lange Sicht ist ein eigener Table natürlich sinnvoller...

[Johannes]

Scheinbar möchte das Charting keine Temperaturen <0°C darstellen
Ist das schon mal aufgefallen?

Hi,

Ist mir bisher nicht aufgefallen. Ich habe bisher in erster Linie für meine eigene Hardware entwicklet, und dass sind Stromzähler.
Das die Werte da mal negativ ausfallen kommt leider ziemlich selten vor, wäre aber schön.... :-)

Ist aber klar ein Bug und auch schon ausfindig gemacht. Sollte im nächsten Release gefixed sein.

[erwin]

Hallo Erwin,
Daran habe ich natürlich schon gedacht. Bisher habe ich aber eigentlich vermeiden wollen, dass der Anwender, bevor er das Frontend nutzen kann, erstmal 10 Schritte tut.
Bzw. ich möchte den Installationsaufwand möglichst gering halten. Ich bin da noch nicht ganz entschlossen, auf lange Sicht ist ein eigener Table natürlich sinnvoller...

Johannes,

Mein Angebot: ich könnte das umbauen des DbLog moduls übernehmen, inklusive der doku.

Vorschlag zur Tabellen-struktur (aus der dzt. dblog):

Code Auswählen Erweitern

chartnane varchar(xx), starttime TIMESTAMP, endtime TIMESTAMP, device varchar(xx),
 userquery varchar(x), xaxis varchar(x), yaxis varchar(x)

... oder soo ähnlich ;-))

l.g. erwin

[Johannes]

Hallo Erwin,

Danke für das Angebot!
Änderungen am DbLog Modul kannst du mir gerne zukommen lassen, ich prüfe die dann und stelle sie zum Testen bereit.
Du kannst auch gerne helfen, z.B. die Table SQLs zu bauen. Ich habe derzeit nur SQLite greifbar und kann daher nur darauf testen.

Ich bräuchte einen Table "frontend" mit folgenden Attributen

id, timestamp, type, name, value

Die Spalte id sollte einen autoincrement haben und unique sein, also automatisch hochzählen bei einem insert und immer eindeutig sein. Bei Postgres macht man das z.b. mit dem Typ serial.
In der Spalte Value werden in der Regel Konfigurationsstrings abgelegt, so dass die Länge hier am besten unbegrenzt, bzw. maximal sein sollte.
Für type und name reicht ein varchar von 64 sicherlich aus.