SmartVISU + fronthem - Plotübergabe (gelöst)

blitz94 · 10 Februar 2021, 17:22:22

Hallo zusammen,

arbeite aktuell an der Visualisierung von Graphen (Plots) mit SmartVISU über FHEM.
Habe dazu die Anleitung in folgendem Threat durchgearbeitet:
https://forum.fhem.de/index.php/topic,86584.0.html

Nach erfolgreichem Update der benannten Dateien war es nun möglich, in den GADs auch Plots zu bearbeiten.
Leider bekomme ich es nicht her, dass die Daten im Logfile auch tatsächlich ausgelsen und in SmartVISU angezeigt werden. Ich habe mittlerweile dutzende Kombinationen erfolglos versucht miteinander zu verbinden.

Mein Wunsch wäre es, das in FHEM definierte Element "WZ_Istwert", welches ins Logfile schreibt "FileLog_WZ_Heizung".

Ich habe im Anhang Screenshots der GAD Konfiguration und einen Logfileauszug angehängt. Ich wäre sehr für eure Ideen dankbar.

Zudem habe ich noch eine Fehlermeldung im Logfile finden können, mit der ich leider nicht viel anfangen kann.
2021.02.10 17:06:20 1: Devices: error doing $result = fronthem::Plotfile($param); Undefined subroutine &main::timelocal called at ./FHEM/99_fronthemUtils.pm line 38.

GammaTwin · 11 Februar 2021, 09:30:00

Grüße,

Deine Einstellung im Screenshot sollte funktionieren. Wie viele Einträge hat den der Logfile? Kopiere mal die Datei, kürze diese mal drastisch auf den letzten Tag und probiere es dann mal mit der gekürzten Version.

blitz94 · 11 Februar 2021, 17:03:46

Hallo, vielen Dank für deine Antwort.

Ich habe für diesen Zweck extra ein Versuchslogfile angelegt, das aktuell ca. 300 Einträge umfasst. Auch nach dem Löschen und Befüllen mit ca. 10 Werten kommt leider keine Grafik zustande.

Was mich etwas stuzig macht sind zwei Dinge
- Wenn ich den Browser mit SmartVisu offen habe, werden die aktuellsten Datensätze übergeben und in der Grafik dargestellt. Diese scheinen aber nur temporär zu sein, da sie nach einem Refreh der Seite wieder verschwinden.
- Die Fehlermeldung in der FHEM Log.
"Devices: error doing $result = fronthem::Plotfile($param); Undefined subroutine &main::timelocal called at ./FHEM/99_fronthemUtils.pm line 38."

GammaTwin · 11 Februar 2021, 22:28:09

Hänge hier mal die Bsp-Datei an. Ich versuche das mal nachzustellen.

blitz94 · 12 Februar 2021, 00:07:07

Vielen Dank, das wäre sehr nett

Ich habe dir im Anhang die LogDatei angehängt, wie sie in FHEM generiert wird. Kann dir bei bedarf gerne noch weitere Dateien zukommen lassen.

GammaTwin · 12 Februar 2021, 09:27:52

Grüße,

ich habe die Datei in mein Log-Verzeichnis gelegt und folgendes FileLog-Device angelgt.

Code Auswählen

defmod FileLog_WZ_Sollwert FileLog ./log/autocreate/WZ_Sollwert-%Y.log test

Meine fronthem-Einstellungen: Diese entsprechen Deinen Einstellungen aus dem ersten Post, angepasst auf Sollwert und anderen Dateinamen

Code Auswählen

"type" : "plot",
"reading" : "getG1",
"converter" : "Plotfile FileLog_WZ_Sollwert",
"device" : "WZ_Sollwert",

Und dann erhalte ich auch eine Grafik in smartVISU. Ich erhalte auch keinen Fehler im Log.

$:-\$ Also, die Einstellungen stimmen, es sollte funktionieren. Der Fehler liegt also wo anders.

blitz94 · 12 Februar 2021, 10:58:30

Vielen Dank für deine Hilfe! Habe mir - da wir die Konfiguration ausschließen konnten - nochmal die Fehlermeldung " &main::timelocal" genauer angesehen und bin irgendwo im Forum auf einen ähnlichen Fehler gestoßen.

Kurzum: Falls so etwas bei jemandem auftreten sollte, ist die Lösung eine der obersten Zeilen "use Time::HiRes qw(gettimeofday);" im File "99_fronthemUtils.pm" durch folgende zu ersetzen:
use Time::Local;

Jetzt kommen die Daten in SmartVISU an.

Danke nochmal und lg

Boe3eh · 22 August 2021, 20:04:01

Hallo,
ich habe das Problem, dass meine Logfiles zu groß werden (ich logge jede Stunde einen Wert, also 24*365=8760 pro Jahres-File), irgendwann sind um die 3000 Werte in dem File und dann bekomme ich in der SmartVISU den Plot nicht mehr angezeigt. Reduziere ich die Einträge in dem File ist der Plot wider da.
Hat jemand eine Idee, wo ich anpassen muss, dass ich das Jahresfile mit den 8760 Zeilen in SmartVisu als Plot dargestellt bekomme.
Hier mein Plot in Smartvisu:
{{ plot.period('AT',
         'AT',
         'avg',
         '1y',
         'now',
         '-25',
         '45',
         '100',
         ['Außentemperatur Süd'],
         ['#0000FF'],
         ['line'],
         '',
         'advanced',
         '',
         '',
         '',
         '',
         ['°'],
         { yAxis: [ { tickInterval: 1} ], legend: { verticalAlign: 'bottom', y: -5 }, rangeSelector: {selected: '2'}})
         }}

wvhn · 23 August 2021, 09:50:54

Der Aufruf des Plot-Widgets ist in Ordnung. Die eckigen Klammern brauchst Du nur, wenn Du mehrere Datenreihen oder y-Achsen hast und dafür Parameter als Arrays angeben musst. Sie schaden aber nicht.

Die Anzahl der Datenpunkte im Plot könntest Du von 100 auf 365 stellen, um für jeden Tag einen Temperaturwert zu halbwegs konstanten Uhrzeiten zu bekommen. So wie Du es jetzt eingestellt hast, bekommst Du alle 87-88 Stunden einen Wert, also Werte, die von ganz unterschiedlichen Uhrzeiten stammen.

Das Problem der fehlenden Daten liegt vermutlich auf der fronthem-Seite, dort wo das Logfile aufbereitet wird. Da kann ich Dir nicht weiter helfen. Wenn Du im Treiber (./driver/io.fhem.js) den Loglevel auf 2 stellst, wird beim Aufrufen der betreffenden Seite der Datenverkehr zwischen smartVISU und fronthem auf der Entwicklerkonsole des Browsers ausgegeben. Poste mal das Ergebnis. Vielleicht gibt das weiteren Aufschluss.

Gruß
Wolfram

Boe3eh · 23 August 2021, 19:23:05

Hallo,
prinzipiell wird ja der Plot angezeigt. Jedoch scheint es an der Anzahl der Einträge im File zu liegen, dass der dann nicht mehr dargestellt werden kann?
GammaTwin hatte in diesem Post am 11 Februar 2021, 09:30:00 geziehlt nach der Anzahl der Einträge gefragt, daher meine Hoffnung das dazu die Lösung schon bekannt ist?!
Ich schau dann aber mal, ob über das Log wie du beschrieben hast was zu sehen ist...

GammaTwin · 29 August 2021, 12:43:42

Grüße,

das Problem mit der Anzahl ist noch vorhanden. Ob es aber das gleiche Problem ist, weiß ich nicht. Ich beschreibe meine Auffälligkeit.
Ich nutze als Quelle allerdings eine SQL-DB und nicht den Logfile.

##############Einstellung "raw"

Ich habe ein Diagramm, welches meinen Strombezug bzw. -lieferung darstellt. Es werde alle 5 Sekunden beide Werte geliefert.
Ich stelle die letzten 11 Minuten mit der Einstellung "raw" dar, neue Werte werden schön hinzugefügt - sieht toll aus, wenn man sich einen Kaffee rauslässt und die dazugehörige Stromspitze sieht

Code Auswählen

{{ plot.period('pAktLiefBezugFein', ['Strom.aktLieferung.plot', 'Strom.aktBezug.plot'], 'raw', '11i', 'now', '', '', '', ['Lieferung', 'Bezug'], ['#aa0', '#ce7f2b'], ['area', 'area'], '', '') }}

Erhöhe ich die Zeit von 11i passiert folgendes:
- 5h: es kommen keine Werte
- 4h: Es erscheinen Werte
- 240i (entspricht 4h in Minuten): es kommen keine Werte
- 99i ist die Grenze, da werden Werte angezeigt

Vereinfacht: Für "raw" scheinen folgende Grenzen zu gelten:
Stunden: 4h
Minuten: 99i

Was übrigens immer klappt: Es werden neue Werte hinzugefügt.

##############Einstellung "avg"

In Deinem angehängten Beispiel hast Du ja "avg" verwendet und ein Jahr "1y" als Zeitraum gewählt.

Ich habe das gleiche Diagramm noch als "Langzeit-Chart": 72h

Code Auswählen

{{ plot.period('pAktLiefBezugGrob', ['Strom.aktLieferung.plot', 'Strom.aktBezug.plot'], 'avg', '72h', 'now', '', '', '', ['Lieferung', 'Bezug'], ['#aa0', '#ce7f2b'], ['area', 'area'], '', '1h') }}

Wenn ich da auf "1y" stelle, bleibt mein FHEM ca. eine Minute stehen und dann wird das Chart angezeigt. Es werden dafür so grob 21.000.000 Werte genutzt (2 Daten * 365 Tage * 24 Stunden * 60 Minuten * 20 Sekunden (alle 5 Sek kommt ein Wert)). Es werden 12 Schritte (Monate) auf der x-Achse dargestellt.

Für mich heißt das aber, dass für die Einstellung "avg" keine Grenze für die Darstellung der Werte gibt.

Wie am Anfang gesagt, es könnte auch ein völlig anderes Phänomen für Einstellung "raw" sein.

wvhn · 29 August 2021, 23:40:11

Das smartVISU Widget Plot.period macht nichts anderes, als die Daten beim Backend anzufordern und 1:1 an Highcharts weiter zu leiten. Highcharts kann Hunderttausende von Punkten darstellen und sollte in Euren Fällen keine Begrenzung darstellen. Die Aufbereitung der Daten (Zeitbereich, Anzahl, Wertearten 'raw', 'avg' usw.) ist Aufgabe des Backends. Zur Lösung des Problems wäre es deshalb wichtig, zu sehen, welche Daten das Backend bei der Anfrage liefert. Dazu brauche ich die Logs von der Konsole.

Gruß
Wolfram

wvhn · 09 Dezember 2021, 11:32:58

Leider sind wir hier noch nicht weiter gekommen und die benötigten Konsolenausgaben zum Eingrenzen des Fehlers habe ich bisher nicht gesehen.

Ich habe deshalb nochmal den Code des fhem-Treibers untersucht und es bestätigt sich meine obige Aussage, dass die Aufbereitung der Plot-Daten komplett im fhem/fronthem gemacht wird.

Innerhalb von smartVISU wird ein Plot-Item wie folgt benannt:

Code Auswählen


hcs.data.OilLevelPlot.avg.5y 6m.0.100 -- count
|-------------------||--||----||-| 
        item           \    \    \ end
                        \    \ start
                         \ mode

Mit diesem Namen ist das item im Objekt "widget.buffer" abgelegt, aus dem sich die smartVISU-Widgets bedienen. Das Objekt kann man sich auf der Entwicklerkonsole des Browsers ausgeben lassen.
Der Treiber io.fhem.js zerlegt diesen String anhand der Punkte und schickt die Einzelteile in json-Format an fronthem. Im Beispiel sieht das so aus:

Code Auswählen


{"cmd": "plot", "items":{ 
                "item": "hcs.data.OilLevelPlot",
                "mode": "avg",
                "start": "5y 6m",
                "end": "now",                        // 0 wird durch "now" ersetzt
                "count": "100"
                "interval": "OnChange",
                "minzoom": "irgendwas"        // der im Widget unter 'data-zoom' festgelegte Wert
                "updatemode": "additional"
              }
      }

Das heißt die durations für Start und Ende werden unverändert an fronthem übertragen und müssen dort korrekt weiterverarbeitet werden. Wenn bei Euch mit den durations 240i und 4h unterschiedliche Ergebnisse herauskommen, dann liegt die Ursache in fhem/fronthem im Parser, der die durations in das Zeitformat der Datenbank wandelt.

Nach Erhalt der Log-Daten im nächsten Post kann ich den folgenden Absatz nicht mehr voll bestätigen. ich lasse ihn zu Dokuzwecken aber als Zitat stehen. Richtig ist, dass die mit dem Kommando ,,plot" bei fronthem angefragten Daten mit einer vollständigen Series-ID zurück geliefert und so auch eindeutig zugeordnet werden. Es gibt im Treiber jedoch noch eine Routine für Daten, die mit dem Kommando ,,series" zurück kommen. Ob dies aus dem addon-Treiber kommt, oder eine Leiche im Treiber ist, kann ich aktuell nicht beurteilen. Für diese Daten gilt das nachfolgend gesagte.

ZitatWenn smartVISU von fronthem die angeforderten Daten erhält, fehlen leider die Angaben für mode, start, end und count in der Rückmeldung, d.h. Der Name des Plot-items ist unvollständig. Der Treiber sucht dann in allen geladenen Seiten nach Plot-Widgets, die das item abonniert haben (ohne Berücksichtigung der fehlenden Angaben) und versorgt diese mit den Daten. Da smartVISU seit v2.8 auf jQuery mobile basiert, das die einmal geladenen Seiten im Speicher behält (Multipage Document), kann es hier zu Konflikten kommen, wenn dasselbe item in einem weiteren Plot mit anderen modi, durations oder counts abonniert ist. Wünschenswerte Abhilfe wäre eine Rückübermittlung der fehlenden Daten, so dass der item-Name mit allen Angaben komplett vorliegt. Und natürlich müsste fhem/fronthem die Anfragen mit unterschiedlichen Parametern auch wie separate Anfragen behandeln.

In smarthomeNG haben wir die Funktion ,,seriesCancel" eingeführt, mit der Abonnements von Serien beendet werden können. SmartVISU ruft diese bei jedem Seitenwechsel auf. Das machen wir aus Performancegründen, aber für fhem wäre dies IMHO wichtig, um Klarheit in die abonnierten Plots zu bekommen. Im fhem-Treiber ist die zugehörige Funktion io.stopseries() zwar vorhanden, aber noch leer. Ich wäre bereit, diese zu realisieren, wenn jemand den Part auf der Seite von fhem/fronthem übernimmt.

Gruß
Wolfram

Johann.S · 12 Dezember 2021, 16:39:57

Hallo,

ich habe leider das gleiche Problem!

2 Systeme:

fhem auf RPI 3,
WEB/Datenbankserver Debian Buster Apache2 php8 smartVISU und nextcloud
RPI 3 mit fhem Apache2 php7.3 smartvisu
lesender Datenbankzugriff auf die gleiche Datenbank wie 1

Bei beiden Systemen das gleiche Ergebnis.

smartVISU:

Code Auswählen

/**
* -----------------------------------------------------------------------------
* @package     smartVISU
* @author      Johann Schierl
* @copyright   2019
* @license     GPL [http://www.gnu.de]
* -----------------------------------------------------------------------------
*/

{% extends "base.html" %}

{% block content %}

{{ plot.period('', 'ws.windspeed.plot', 'raw', '47h', now, 0, 20, 100, 'Windgeschwindigkeit', '#a00', 'spline', ['raw 47h', 'Geschwindigkeit in km/h']) }}

{{ plot.period('', 'ws.windspeed.plot', 'raw', '48h', now, 0, 20, 100, 'Windgeschwindigkeit', '#a00', 'spline', ['raw 48h', 'Geschwindigkeit in km/h']) }}

{% endblock %}

Webausgabe siehe Bild.

Log aus fhem siehe Datei.

Firefox-Konsolenausgabe siehe Datei.

Die Namensänderung des Items im 2. Plot bringt auch keine Besserung.

Wen noch weiter Daten benötigt werden stehe ich gerne zur Verfügung!

Gruß

Johann

PS: musste noch mal schreiben weil zu viele Zeichen!

wvhn · 12 Dezember 2021, 23:19:17

Vielen Dank für die gute Auswertung!

Aus dem fhem Log ist zu erkennen, dass beide Serien angefragt und zunächst aus der Datenbank geliefert werden. Danach geht aber in der Übermittlung etwas schief:
fronthem erhält die Anweisung für den 47h-Plot

Code Auswählen

{"log":{"text":"ws send to client{"cmd":"plot", "items":[{"updatemode":"additional", "plotdata":[[1639152698000,1.1], ... ,[1639321759000,8.6]], "item":"ws.windspeed.plot.raw.47h.now.100"}]}", "cmd":"log", "level":4}}

und führt dies anschließend aus. Im smartVISU-Log sieht man, dass die Daten ankommen.
Als nächstes erhält fronthem die Anweisung für den 48h-Plot:

Code Auswählen

{"log":{"level":4,"cmd":"log","text":"ws send to client{"items":[{"item":"ws.windspeed.plot.raw.48h.now.100","updatemode":"additional", "plotdata":[[1639149147000,1.1], ... , [1639321808000,6.1]]}], "cmd": "plot"}"}}

Auch dies scheint laut fhem Log ausgeführt zu werden, aber in smartVISU kommen die Daten nicht an. Auffällig ist, dass die Inhalte beider Messages gleich sind, aber die Reihenfolge der einzelnen Elemente in der Message unterschiedlich ist. Kann es sein, dass die Daten innerhalb von fronthem noch abgefangen werden - evtl. wegen der veränderten Struktur? Dass smartVISU die Daten nicht erhält, ist ziemlich eindeutig. Erste Aktion des fhem-Treibers beim Empfang von Daten ist deren Ausgabe auf die Konsole, bevor die Daten weiter verarbeitet werden.

Ein weiterer Fehler ist, dass die Anzahl der angefragten Datensätze ignoriert wird. Das passiert offenbar schon bei der Datenbankabfrage. Die Datenbank sendet einfach alle Werte im angefragten Zeitraum.

Auffällig sind noch die folgenden items. Dort fehlt der Modus (z.B. "avg"). Vermutlich bleiben sie deshalb leer.

Code Auswählen

{"items":[{"item":"ws.windguest.plot..10d.now.100","updatemode":"point","plotdata":[]}],"cmd":"plot"}
{"items":[{"updatemode":"point","plotdata":[],"item":"WZ_th.temp.plot..3m.now.100"}],"cmd":"plot"} 
{"cmd":"plot","items":[{"updatemode":"point","plotdata":[],"item":"WZ_th.humidity.plot..3m.now.100"}]} 
{"cmd":"plot","items":[{"item":"ws.windguest.plot..10d.now.100","plotdata":[],"updatemode":"point"}]}

Wie werden die Plots für diese items in Deinen Seiten aufgerufen? Normalerweise ersetzt das Plotwidget von smartVISU fehlende mode-Angaben im Aufruf durch "avg".

Gruß
Wolfram