Daten visualisieren

[daja64]

Kann mir mal jemand erklären, wie die Daten auf einem Handy zeigen kann. So mit Diagramm oder so, also was der WR so den ganzen Tag gemacht hat. Diese MQTT Sache kapier ich nicht. Und was ich im Netz gefunden habe, hat nicht wirklich geholfen. Hilfe ist von Nöten. Danke

[ahinrichs]

Der ESP speichert - aktuell und auf absehbar - keine Datenreihen, sondern kennt nur den aktuellen Ist-Zustand, also Leistung jetzt gerade und Spannung jetzt gerade. Diese Werte kannst Du dir in der Weboberfläche angucken. Für Diagramme musst Du die Daten extern sammeln. Also auf irgendeinem Server die Daten regelmäßig per HTTP abholen (oder eben per MQTT dorthin verschicken lassen) und dort in einer Datenbank oder ähnliches sammeln. Und dann mit einer Weboberfläche Deiner Wahl visualisieren. Viele haben schon eine Steuerzentrale, die das kann. Sonst wird oft die Kombi Influx und Grafana genutzt. Aber wenn Du Dich mit MQTT schwer tust, wird das nicht ganz leicht.

Das ist bei Hoymiles ja nicht anders. Die Orginal-DTU sammelt die Daten und schickt sie an die Cloud. Charts gibt es dann nur von dort. Vielleicht findest Du einen anderen Cloud-Dienst, in den Du Deine Daten reinfüttern kannst.

[gcPhil]

Also auf irgendeinem Server die Daten regelmäßig per HTTP abholen (oder eben per MQTT dorthin verschicken lassen) und dort in einer Datenbank oder ähnliches sammeln.

Mich beschäftigt die selbe Frage zur Visualisierung und Archivierung der Daten, deshalb einmal kurz zwei Fragen zum besseren Verständnis:

• Für das "Daten regelmäßig per HTTP abholen" gibt es aber aktuell keine Schnittstelle in OpenDTU, oder?
• mit MQTT habe ich mich bislang nicht beschäftigt, läuft ein MQTT-Broker immer auf einem Server im Heimnetzwerk oder gibt es auch "MQTT-Cloud-Dienste" an die ich die Daten senden könnte?

[ahinrichs]

Also auf irgendeinem Server die Daten regelmäßig per HTTP abholen (oder eben per MQTT dorthin verschicken lassen) und dort in einer Datenbank oder ähnliches sammeln.

Mich beschäftigt die selbe Frage zur Visualisierung und Archivierung der Daten, deshalb einmal kurz zwei Fragen zum besseren Verständnis:

• Für das "Daten regelmäßig per HTTP abholen" gibt es aber aktuell keine Schnittstelle in OpenDTU, oder?

Doch. Du kannst alle API endpoints des Webinterface ja auch direkt abfragen. Also bsp http://.../api/livedata/status. Ist halt für den ESP aufwendiger und erzeugt mehr Last. Das würde ich jetzt nicht alle 5 Sekunden laufen lassen. Schicken lassen per MQTT ist etwas effizienter.

Dazu gibt es inzwischen ja einen Prometheus Endpunkt (/api/prometheus/metrics). Für mich klingt es so, als wäre das die Richtung für Dich. Irgendwo ein Prometheus+Grafana. Ich hab nur Erfahrung mit selbstgehostet, wäre aber verwundert, wenn man das nicht auch in der Cloud kriegt. Und wenn es irgendwie geht, ein HTTPS-Proxy im Lokalen Netz für den Zugriff durch Prometheus von außen auf den OpenDTU. Falls das gar nicht geht, dann halt HTTPS auf dem OpenDTU aber mit großem Abfrage-Intervall.

• mit MQTT habe ich mich bislang nicht beschäftigt, läuft ein MQTT-Broker immer auf einem Server im Heimnetzwerk oder gibt es auch "MQTT-Cloud-Dienste" an die ich die Daten senden könnte?

Der Broker ist normal das kleinere Problem. Die Datenbank und die Visualisierung sind entscheidender und größer. Wenn Du Dich da entschieden hast was und wo das läuft, dann kannst Du da normal den MQTT auch drauf packen. Mosquitto ist simpel und sparsam.

Google hatte einen Broker als Dienst, ist aber deprecated und wird (oder ist schon) eingestellt.

[ottelo9]

Mhhh könnte man das Projekt irgendwie mit Tasmota verbinden/integrieren dann könnte man die Daten sogar via deren Script Support mit Google Chart visualisieren. So habe ich es jedenfalls bei mir mit Tasmota und meinem Stromzähler gemacht. https://ottelo.jimdofree.com/stromz%C3%A4hler-auslesen/

Allerdings ist Tasmota ja für was ganz anderes gemacht.

[Franks2505]

Gibt es eine Möglichkeit, dass der Tasmota die Daten aus OpenDTU bzw. MQTT regelmäßig ausliest und dann in eine Cloud sendet?

[ottelo9]

Ja, via der web API können die Daten im JSON Format von Tasmota (via Script) abgerufen werden.
Beispielscript gibt es hier (Tesla Powerwall Daten abrufen via JSON). Aber statt gpwl() musst du gjp() verwenden, z.B.
gjp("http://192.168.178.50" "/api/file/get")

in der >jp Sektion können die empfangenen Daten verarbeitet werden.

Die Leistung kann dann via WebQuery z.B. an clever-pv.com gesendet werden.
->WebQuery EURE-PUSH-API-URL POST [Content-Type:application/json] {"watt": %0sml[1]%}

Script commands:
gjp("host" "path") = trigger HTTPS JSON page read as used by Tesla Powerwall (if defined SCRIPT_GET_HTTPS_JP)

Man muss ein speziell erstelles Image verwenden. Das könnte ich dir sonst erstellen.

[battifreund]

Ich mag Tasmota nicht so richtig. Es ist mittlerweile ein ganz schöner Verhau.

Ich finde ESPHome wesentlich strukturierter und durch die Anbindung an HomeAssistant / ioBroker können die Daten dort sehr gut visualisiert oder langfristig gespeichert werden.

Wenn, dann sollte in eine ESPHome-Komponente investiert werden. Ich weiß allerdings nicht, ob das aufgrund der Architektur von ESPHome immer problemlos funktioniert.

---

I don't really like Tasmota. It's quite a mess now.

I find ESPHome much more structured and through the connection to HomeAssistant / ioBroker the data can be visualized very well there or stored long-term.

However, I do not know whether this always works without problems due to the architecture of ESPHome.

[ottelo9]

Ja klar gibt es Alternativen. Es war auch nur ein Wunsch "nice2have" für eine Option, die man ja z.b. extra aktivieren muss um sich ein kleines Diagramm anzeigen zu lassen.

Ich finde aber so Einzellösungen wie Tasmita + Google Chart ganz gut, wenn man keine Hausautomatisierung ala Home Assistant und Co hat. Wie bei meinen Eltern z.B.. Mein Vater wollte eigentlich nur den Stromzähler bequem via Handy auslesen. Und da kommt ein einzelner Lesekopf inkl. ESP + Tasmota + Webseite mit Google Chart genau richtig. Wenn es nicht mehr sein soll ist doch solch eine einfache Lösung ideal. Für alles weitere hast du natürlich Recht, ESPHome + HA.

[c1328]

Wer doch die MQTT Schiene geht und außerdem noch Telegraf/Grafana nutzen möchte, für den gibt es hier vielleicht ein interessantes Dashboard (für Ahoy gebaut, aber kann man sicher auch für openDTU nutzbar machen): https://grafana.com/grafana/dashboards/16850-pv-power-ahoy/

[HacksBugsAndRockAndRoll]

Ich habe die Daten in meinem Setup über einen MQTT Broker in Home Assistant eingebunden. OpenDTU unterstützt das Einbinden in HomeAssistant hier ziemlich gut, so dass man die einzelnen MQTT topics nicht manuell interpretieren muss. Visualisierung findet dann über die HomeAssistant dashboards statt, die Handy App gibts dann umsonst dazu.
Um so ein setup aufzubauen hilft es, wenn ein SoC (wie ein raspberry >= 3), eine NAS mit Docker Support (mein setup) oder ein anderer home server zur Verfügung steht.

[mobiljoe]

Hallo, kannst du verraten was ich bei mqtt in die configuration.yaml eintragen muss, dass es läuft. Ich raff`s irgenwie nicht. Danke

[battifreund]

Vielleicht hilft das ...
#156 (comment)

[HacksBugsAndRockAndRoll]

Ich meine das geht in HA über eine mqtt Integration. Also rein über die UI.
edit (wieder daheim):
https://www.home-assistant.io/integrations/mqtt/
und dann in den HA Einstellungen->Integrationen UI die MQTT Integration entsprechend mit den Verbindungsdaten zu deinem Broker versorgen

[daja64]

Das ist ja alles gut und schön, aber ich versteh nur Bahnhof. Ich brauch jetzt mal ein Feedback von euch, bitte keine Diskussion anfangen einfach nur sagen ob das so richtig ist oder nicht, eventuell nur kommentieren.
Ich habe eine FRITZ-Box als Router. Daran hängt per WLAN der ESP, der mit dem WR redet. Dann will ich jetzt keine weiter Hardware schon wieder kaufen müssen, um diese MQTT Geschichte zu nutzen. Geht das denn nicht mit eine Tablett(Android8.1) ?
Und ist das so richtig: wenn ich Home-assistant nehme, brauch ich noch einen Server (der wäre dann dem Router untergeordnet?), der die Daten vom ESP holt oder wie geht das ? Beschreibt mir doch mal wie ihr das gelöst habt. Danke für eure Mühen.

[syssi]

1. Es geht nicht mit einem Tablet. Es muss ein Gerät geben, welches über den gesamten Tag einzelne Sensorwerte sammelt. Also ein Topf, der kontinuierlich gefuellt wird.
2. Home Assistant kann z.B. dieser Topf sein und danach aus diesen Daten ein Diagramm rechnen. Er laeuft dann auf zusaetzlicher Hardware. Weiteres Gerät im Netzwerk. Der Router ist auch nur ein dummer Datenschaufler und koennte sich langfristig nicht viel merken. Nur ganz punktuell hat der Hersteller ihm beigebracht z.B. Faxe auf einen USB-Stick zu schreiben.
3. Der ESP ist nur eine Funkbruecke und stellt die IST-Daten zur Verfügung. Sammeln muss jemand anderes.

Hier ein paar denkbare Standard-Setups:

1. Der ESP schickt die IST-Daten (über MQTT als Übertragungsschicht) an Home Assistant. Hier stellt man ein, wie viele Datenpunkte sich Home Assistant merken soll (werfe alles weg was aelter ist als 30 Tage etc.). Danach kannst du dir in Home Assistant Graphen bauen lassen, welche die letzten letzten 60 Minuten, die letzten 24 Stunden und die letzten 30 Tage zeigen. Alles was älter ist koennte man weg werfen (viele sammeln auf ewig).

2. Der ESP schickt die IST-Daten an den MQTT-Broker hier koennen sie von beliebigen Anwendungen konsumiert/abgeholt werden. Zum Beispiel Telegraf (eine Datenschaufel) um Daten in eine InfluxDB (Zeitreihendatenbank) + Grafana (Visualisierung) zu schaufeln.

3. Dieses Szenario habe ich hier die Tage aus der Tasmota-Welt gelesen: Der ESP postet die Daten ins Internet gegen ein Google-Spreadsheet. Mit jedem Datenpunkt kommt in der "Exceldatei" eine Zeile hinzu. Man kuemmert sich im Anschluss manuell um die Weiterverarbeitung (Diagramm über einen Ausschnitt der Zahlen erstellen). Dieses Szenario ist glaube ich nur ein Wunsch-Feature. Aktuell unterstuetzt OpenDTU nur das Daten schicken an einen MQTT-Broker. (Bitte korrigiert mich!)

[daja64]

Super das habe ich verstanden. Danke.

[avandorp]

Ich war in der Situation, dass ich keine weitere Hardware in meinem Netz betreiben wollte. Darum hab ich Home Assistant mit MQTT-Broker auf einer winzigen VM "in der Cloud" laufen. OpenDTU schickt die MQTT-Pakete per TLS verschlüsselt und mit Username/Passwort authentifiziert raus in meine VM. So muss ich auch keine Firewall bei mir öffnen oder dergleichen.

[avandorp]

Bzgl. Tablet: Man kann durchaus eine App bauen für Android, welche im lokalen Netzwerk als MQTT-Broker fungiert (gibt diverse Libraries, die man da verwenden kann). Etwas aufwändig könnte werden, die App immer im Hintergrund am laufen zu halten. Hab ich mir nie näher angesehen.

[quangnguyen]

Ich habe mir sowas eingebaut wobei die Daten des aktuellen Tages stundenweise in Memory gespeichert werden. Also das Diagramm zeigt immer den Verlauf der aktuellen Tages. Somit ist kein externe System erforderlich. Wenn jemand Interesse hat, kann ich die Code auch teilen.

Screenshot

[gcPhil]

Interesse!
Warum hatte das bisher niemand umgesetzt, wird der Speicher des ESP dadurch überdurchschnittlich stark belastet?

[quangnguyen]

Hier ist ein Git Patch Patch dazu.

Feature__add_day_yield_chart.patch

[Demophobie]

Huhu,

Diese Darstellung würde mir auch schon voll ausreichen! Wenn es jetzt noch eine Monatsdarstellung geben würde, wäre ich wunschlos glücklich.

Ist das schon gemerged worden? Das wäre doch mal etwas!

[ghost]

Hallöchen,

ich hänge mich mal mit rein.
Auf SD zu speichern, eine Statistik-Unterseite zu machen und Googe Charts zur Aufbereitung zu nutzen, sollte machbar sein.
Allerdings kann ich aus meiner eigenenen und sehr laienhaften Erfahrung sagen, das macht Mühe.

Leider habe ich erhebliche Probleme die Programierung mit Visual Studio Code nachzuverfolgen, geschweige zu verstehen. Ich würde gern dabei unterstützen. Ich kapiere aber leider nur zu höchstens 0,01%, wie der Code funktioniert.
Bisher habe ich nur das eine oder andere nur mit der Arduino IDE bewerkstelligt.

Vor OpenDTU hatte ich eigene Ambitionen herauszufinden, was jedes Solarmodul meines Balkonkraftwerkes so produziert.
Bewerkstelligen wollte ich das mit direkter Messung des Stromes und Schätzung (späterer Messung) der Spannung eines jeden Moduls.
Der Vorteil dieser Variante ist, das funktioniert herstellerunabhängig mit jedem Wechselrichter.
Zu überlegen war, wie oft wird gespeichert. Flashspeicher macht ein Schreiben so ca. 10000 Mal mit (+/-). Ein Jahr hat ca. 8760 Stunden. Bei stündlicher Speicherung und Berücksichtigung, das der Wechselrichter auch an ist, ist nach 3 Jahren der Flash hin.
Daher hatte ich mich von Anfang an dafür entschieden, auf SD zu speichern, im Fehlerfall auf den ESP auszuweichen und bei neuer SD wieder auf diese zu wechseln. (Davon habe ich aber noch nicht alles realisiert.)
Gespeichert zur grafischen Darstellung habe ich den Ertrag für:
Jede Stunde eines Tages, jeden Tag einer Woche, jeden Tag eines Monats, jeden Monat eines Jahres und für die letzten 10 Jahre.
Die Strommessung für 3 Module, die Daten aufzubereiten und auf dem ESP eine Webseite zu gestalten, habe ich mit der Arduino IDE und der bekanntesten Suchmaschine hinbekommen.
Abgestorben bin ich bei den Kompfortfunktionen:
Gleichzeitiger Betrieb von AP- und STA-Modus des WLANs oder ein vernünftiges Menü auf der Webseite mit Web-Update.
Teilweise weicht im Internet oder in der Arduino IDE gefundener Beispiel-Code erheblich von einander ab; besonders bei den jeweils verwendeten Bibliotheken. Schwierigkeiten hatte ich mit allem, was Mit WLAN, HTML und so weiter zu tun hat.
Wenn man keine Ahnung hat, fressen Code-Anpassungen, bzw. ein Neuschreiben massenhaft Zeit, die ich leider nicht habe.
Bis zu einer funktionierenden Darstellung im Browser hat es aber gereicht,

Den noch unfertigen Arduino IDE Code hier reinzustellen traue ich mich allerdings nicht. Das ich von Programmierung wirklich keine Ahnung habe, sieht man ganz sicher meinem Code an.
Sofern aber entwicklerseitig Interesse besteht, schicke ich den gerne zu.

[ghost]

Hi,

Ich hätte mich daran versucht:
Link zu anderer Diskussion:

[MichaMEG]

Ich würde mir so etwas wie bei ahoy-dtu auch für die OpenDTU wünschen:

[Artikel14]

Ein zusätzlicher Vorschlag:
Daten visualisieren mit Excel-Funktionalität (Grafiken) ohne Zusatz-Hardware via Google-Tabellen.
https://ottelo.jimdofree.com/stromz%C3%A4hler-auslesen-tasmota/
lumapu/ahoy#627

Gibt es den Prometheus-Endpunkt auch bei openDTU?

Für Ansätze, um OpenDTU ohne Zusatzhardware mit Google Tabellen zu verbinden, wäre der Schlüssel die Nutzung der APIs und Skripte, um Daten von OpenDTU direkt an Google Sheets zu senden:

1. Nutzung der Google Sheets API

Die Google Sheets API erlaubt es, Daten programmgesteuert in eine Google-Tabelle zu schreiben oder daraus zu lesen. OpenDTU kann so konfiguriert werden, dass es regelmäßig Daten über HTTP-POST-Anfragen an die API sendet. Dazu sind folgende Schritte erforderlich:

• Google API aktivieren: In der Google Cloud Console müssen die Google Sheets API und die Drive API aktiviert werden. Außerdem wird ein OAuth-Client erstellt, um Zugriffstokens zu generieren[3][6].
• Authentifizierung und Zugriff: Ein Service-Account kann verwendet werden, um OpenDTU zu authentifizieren. Die entsprechenden Anmeldedaten (Client-ID und Private Key) werden in OpenDTU hinterlegt[9].
• Datenübertragung: Mit der Methode values.append der API können neue Datenzeilen in eine Tabelle eingefügt werden[6].

2. Nutzung von Google Apps Script

Eine einfachere Alternative zur direkten Nutzung der API ist die Erstellung eines Google Apps Scripts:

• Ein Apps Script kann erstellt werden, das die Tabelle als REST-API verfügbar macht.
• OpenDTU sendet dann JSON-Daten an diese API, die das Skript verarbeitet und in die Tabelle einfügt[7][10].

3. Beispiel mit ESP32

Da OpenDTU auf ESP32 basiert, gibt es bereits Projekte, die zeigen, wie Daten von einem ESP32 direkt an Google Sheets gesendet werden können:

• Ein Beispielcode für ESP32-Geräte zeigt, wie man Daten mit einem HTTPS-Request an Google Sheets sendet. Dies erfordert keine zusätzliche Hardware außer dem ESP32 selbst[9][10].
• Alternativ kann ein einfacher HTTP-Request an ein Google Formular gesendet werden, das die Daten automatisch in eine Tabelle einträgt[10].

4. Integration über MQTT oder HTTP

OpenDTU unterstützt auch HTTP-basierte APIs, um Daten an externe Server zu senden. Diese Funktionalität kann genutzt werden, um Daten direkt in eine Tabelle zu schreiben:

• Eine kleine API wie /api/livedata/status kann verwendet werden, um Live-Daten abzurufen und diese in regelmäßigen Intervallen an Google Sheets zu senden[13].

Vorteile dieser Ansätze

• Keine zusätzliche Hardware erforderlich.
• Flexibilität bei der Anpassung der Datendarstellung.

Quellen:
[1] https://www.home-assistant.io/integrations/google_sheets/
[2] https://www.googlecloudcommunity.com/gc/Looker-Studio/Unable-to-Connect-Google-Sheets-as-a-Data-Source-in-Looker/m-p/820693
[3] https://developers.google.com/sheets/api/guides/concepts?hl=en
[4] https://www.heyflow.help/en/articles/5469473-google-sheets
[5] https://mediarath.de/en/products/opendtu-hoymiles-diy-kit-display-ssd1306-esp32-nrf24l01plus-socket-kabel
[6] https://developers.google.com/sheets/api/reference/rest?apix=true
[7] https://www.youtube.com/watch?v=pJOcRSEqhDk
[8] https://blog.helmutkarger.de/balkonkraftwerk-teil-8-opendtu-und-ahoydtu-fuer-hoymiles-wechselrichter/
[9] #1123
[10] https://www.reddit.com/r/esp8266/comments/mua3aw/log_data_directly_to_google_sheets_without_the/
[11] https://community.particle.io/t/pushing-data-to-google-sheets-new-thread/60138
[12] #735
[13] #1713
[14] https://community.thunkable.com/t/thunkable-doesnt-function-well-with-the-google-spreadsheet-data-source/831565
[15] https://www.iobroker.net
[16] #618