ein kleine Ertragsgrafik im Display

[Henrik-Ingenieur]

Hallo und danke für das wundervolle OpenDTU Projekt,

Ich gucke jetzt schon seit Monaten auf meine OpenDTU mit Display und erfreue mich jeden Tag aufs neue daran. In letzter Zeit hatte ich immer wieder den Gedanken das doch ein kleines Diagramm des Tagesertrages schön wäre. Also hab ich mich mal daran gemacht und eine Diagram-Klasse geschrieben.

Aktuell sieht das ganze so aus:

Der zus. RAM verbrauch liegt derzeit bei 816Byteund es läuft bereits stabil. ROM-Verbrauch ist grob 4kB.

Was noch nicht fertig ist ist das zurücksetzten des Diagramms wenn der/die Inverter am morgen wieder Strom liefern. Ich hab noch nicht verstanden wie ich die SunRise-Funktion in C++ nutzen kann. Hat jemand hilfreiche Tipps?

Und eine Frage an die Offiziellen : Wie stehen die Chancen das dieses Feature in einem zukünftiger PullRequest übernommen würde? Also natürlich erst wenn es final ist. Wenn die Chancen gut stehen werde ich mich um weitere Tests mit anderen Displays kümmern.

[Freesee-10]

Hallo Henrik,

gibt es schon Neuigkeiten bei deinen Projekt?

[Henrik-Ingenieur]

Am Diagramm kann man ganz gut erkennen das es den ganzen Tag über im Schnitt kaum über 50W gegeben hat... Winter halt. 😢
Die Watt-Achse skaliert übrigens dynamisch damit man auch an miesen Tagen mehr als ein Flat-line sieht. Außerdem ist es so egal ob jemand ein 2kW oder eine 300W Anlage betreibt, es passt sich automatisch an und sieht Sommer wie Winter gut aus.

[Freesee-10]

Sieht sehr gut aus, was du zeigst. 9 Watt ist bei mir im Augenblick sehr oft zu sehen, wenn ich die überhaupt erreiche. :-)
Planst du deine SW mal irgendwann hier zum download einzustellen und damit zum Test freizugeben, oder willst du erst alle Fehler und Probleme klären?

[Henrik-Ingenieur]

Bei mir läuft's seit zwei Wochen fehlerfrei, ohne das ich exzessiv andere Displays getestet hätte. Wenn du Interesse hast erstelle ich einen Fork und sag hier bescheid. Wird aber erst heute Abend.

[Freesee-10]

Aber sicher habe ich Interesse. Ich komme aber erst zischen den Feiertagen dazu es zu testen. Natürlich würde ich dann auch ein Feedback geben.

[Henrik-Ingenieur]

tbnobody hat mein Diagram in den Hauptbranch übernommen. Eingecheckt unter dem tag: v23.12.19 ist das Diagramm nun für jedermann verfügbar. 🥳

[Henrik-Ingenieur]

Ich hab meinen aktuellen Stand eingecheckt, er findet sich im Branch: Ertragsdiagram
Durch meine eigene Unachtsamkeit findet sich der Branch nicht nur im meinem Fork sondern auch in diesem Repo. 😇
Ich hab vollstes Verständnis wenn der Branch in diesem Repo gelöscht wird, aber in meinem Repo ist er sicher.
Über Rückmeldungen würde ich mich sehr freuen. 👍

[Marc9485]

Ich bin froh, dass ich mir selbst eine "config" schreiben konnte und daher meine Frage als newbie: Muss ich die Zeilen kopieren und in der Firmware einfügen? Datei hatte ich keine gefunden

[Henrik-Ingenieur]

Hallo Marc,
in include/defaults.h solltest du den WLAN Zugang konfigurieren. Damit kann sich, nach dem Flashen, das Board direkt mit deinem WLAN verbinden.
Wenn du auf die Webseite deiner OpenDTU gehst kannst du dort, unter Einstellungen->Konfigurationsverwaltung dein config.json hoch laden.

[Marc9485]

Ich hab auch kein benehmen, sorry.
Gude erst mal✌🏻
Nee, meine config läuft, aber danke😉 Meinte damit, dass ich keine Ahnung hab was, wie und wo ich aus deinem Branch(Ertragsgrafik) brauche um die Grafik aufs Display zu bekommen

[Henrik-Ingenieur]

Ah verstehe, wenn du keine eigenen Anpassung gemacht hast kannst du einfach meinen Branch Auschecken, kompilieren und auf das Board flashen.
Wenn du eigene Anpassung gemacht hast: nimm die Displayklasse und die Diagrammklasse (cpp+h-dateien) aus meinem Branchen und füge sie in dein Projekt ein. Jetzt wieder kompilieren, auf's Board flashen, fertig.

[frank-tanne]

Könnte man von der Version eine Bin Datei bekommen. Mit kompilieren komme ich leider nicht zurecht. Ich hätte großes Interesse.

[Marc9485]

[Marc9485]

[Marc9485]

So klappts beim iPhone. Müssen dann aber zip-Dateien sein

[Henrik-Ingenieur]

Danke für den Hinweis, ich war aber auch zu doof den ganzen Hinweistext von GitHub zu lesen.. 👼
Hier die Bin_files zum selber flashen:
generic_esp32.zip

[Marc9485]

Vielen Dank 🙏

[frank-tanne]

Nach Stunden habe ich es selbst hinbekommen. Danke für das Projekt.

[Henrik-Ingenieur]

Ich Thread oben drüber hab ich jetzt die BIN-files hoch geladen:
generic_esp32.zip

[frank-tanne]

Dankeschön ! Könnte man das auch in Open DTU on Battery einfügen ? (https://github.com/helgeerbe/OpenDTU-OnBattery)

[Henrik-Ingenieur]

Wen meinst du mit "man"? 😏 Ohne das ich den Code von DTU on Battery kenne sollte das kein Problem sein.
Man braucht lediglich etwas Platz im Display. Wenn der vorhanden ist muss nur die DisplayDiagramClass zum Projekt hinzu gefügt- und in der DisplayGraphicClass aufgerufen werden (das sind nur zwei Zeilen im 'Display_Graphic.h' und fünf Zeilen im 'Display_Graphic.cpp').
Fertig.
Im 'Display_Diagram.cpp' in Zeile 5-8 kannst du die Größe und Position des Diagrams anpassen. Pfeile und Berechnungen passen sich automatisch daran an.

[frank-tanne]

Ich werde es versuchen.

[Henrik-Ingenieur]

tbnobody hat mein Diagram in den Hauptbranch übernommen. Eingecheckt unter dem tag: v23.12.19 ist das Diagramm nun für jedermann verfügbar. 🥳

[kinichahau2023]

Hallo Henrik,
Dank für Deine Grafik!
Ich selbst verstehe nicht so viel von den Programm Details, aber Frage:
Ist es ggf. möglich, wie Ralf in https://github.com/RaBa64/OpenDTU-Database/releases/
eine kleine Datenbank zum Download zu ermöglichen für Menschen, die kein übergeordnetes System haben aber dennoch tagsüber die Daten einsammeln möchten, um sie ggf. später anderweitig auszuwerten.
Ich denke, für Deine Grafik musst Du ja auch schon (wenigstens für den laufenden Tag) bestimmte Datenwerte zwischenspeichern.

[kinichahau2023]

DAS wäre die ultimative Kombination :)

Dann - sofern möglich - auch ein upload/restore der Database mit vorsehen, das es bei Ralf (noch?) nicht gibt. Seit Sept.2023 gab's von ihm keine Neuerungen mehr...

HAT SICH ERLEDIGT - RaBa hat upgedatet.

[frank-tanne]

Super

[seisfeld]

Gefällt mir auch echt super! Props dafür! Eine Frage habe ich allerdings: Wenn man die OLED Bildschirmschoner Funktion aktiviert hat bewegt sich alles hin und her wie es soll - nur der Graph nicht. Ist das Absicht? Irgendwie ist doch dann die Bildschirmschoner Funktion nicht mehr so richtig wirksam oder?

Edit: Es gibt scheinbar schon ein Issue dazu - #1581

[Henrik-Ingenieur]

Richtig, ich hab sogar schon ein Diagramm-wackel-funktion im Testsystem implementiert, sie hat nur noch nicht ihren Weg in den OpenDTU-Code gefunden. Wenn ich Zeit finde merge ich das in den Code und verteile ihn hier.

[seisfeld]

Super! Wäre dann aber gut wenn es auch den Weg in den offiziellen Code findet. Ich denke die wenigsten hier flashen regelmässig ein 3rd party image.

[NintendoTito]

@Henrik-Ingenieur Danke für diesen tollen Beitrag zur OpenDTU. Cool auch von @tbnobody dass das jetzt offiziell integriert ist.

Eine Frage zum Verständnis: Um die Grafik anzeigen zu können muss OpenDTU jetzt dann doch auch die gemessenen Daten speichern, oder nicht? Könnte man damit nicht dann auch so eine Funktion realisieren?

#954

[Henrik-Ingenieur]

Die Diagrammwerte liegen lediglich in einem lokalen RAM-Array und werden am Ende des Tages gelöscht. Das hält den RAM-Verbrauch in Grenzen. Von hier aus zu einer kleinen Datenbank ist es noch ein weiter Weg.
Wofür die Daten allerdings reichen wäre ein TagesErtragsDiagram auf der Webseite. Der Web-Part ist mir aber ein Buch mit sieben Siegeln. Da brauche ich jemanden der den implementiert und ich stelle das Array aus input-Daten zu Verfügung.

[kinichahau2023]

Henrik,
Du musst das Rad nicht neu erfinden. Ralf hat ein Update gemacht, nun haben wir Deine Grafik UND eine Database.
https://github.com/RaBa64/OpenDTU-Database/releases/tag/v23.12.21-Database
Vielleicht kannst Du Ralf unterstützen, er will noch die Google-Graphic und -Calender durch open-source ersetzen, wenn er mit seiner Neuinstallation fertig ist...

[huste511]

Das die Grafik stehten bleibt ist ja einigen schon aufgefallen. Vielleicht könnte man den Scrennsaver in diesem Zug auch etwas langsamer machen. Das häufige hin- und hergehopse macht einen schon etwas kirre.

Gibt es zu der Grafik auch eine kleine Funktionsbeschreibung?
Was geben die Punkte auf der x-Achse an?
Wann startet der Graph?
Wie und wie schnell wird die y-Achse skaliert?
Werden die Werte gemittelt?

Ich hatte heute morgen z.B. eine "Lücke" von ca. 2 Stunden wo die WR keine Leistung lieferten aber der Graph schon lief.
Oder die Skalierung der Leistung hing Faktor 2 der realen Einspeisung hinterher.

[frank-tanne]

Nochmal zum Max-Wert der setzt sich ja bei dir jetzt schon in der Nacht zurück.

[Henrik-Ingenieur]

@huste511: Danke für die Bilder: Ich denke du hast das richtig verstanden. Im ersten Bild(20.12.2023) zähle ich zwei Punkte unterhalb der X-Achse. Das heißt das Programm läuft seit etwas mehr als 2h. Der erste Ausschlag im Diagram kommt nach ~2h20min. Also müsstest du das Board gegen um kurz vor 7 Uhr an den Strom gehangen haben.
Im zweite Diagram (21.12.2023) läuft die DTU schon seit >9 h (wohl seit dem dem Vortag) aber weil es dunkel war ist natürlich nichts in den 9 h zu sehen.

[huste511]

@frank-tanne
Wann es sich genau zurück setzt, kann ich aktuell nicht sagen. Vormittags ergibt die Grafik für mich noch nicht so recht sinn, Nachmittags schaue ich wenig drauf und "Nachts" ist dort eh nur "Offline" zu lesen.

@Henrik-Ingenieur
Eigentlich nicht. Das Board hängt 24/7 am Strom. Version vom 19.12. hatte ich noch früh in der Nacht geflasht.
Aufgrund dieser unterschiedlichen Anzeigen war die Ausgabe für mich ja etwa unklar.

Bei mehr und längerer Sonne wird es mit der Darstellung sicherlich besser. Diese sollte aber auch z.Z. reproduzierbar sein.

[Henrik-Ingenieur]

Für das Verständnis: Das Diagramm läuft von rechts nach links durch. Deswegen ist morgens ~9h flat line.

Der Max-Wert wird aus der angezeigten Diagrammperiode bestimmt.
const float maxWatts = *std::max_element(_graphValues.begin(), _graphValues.end());

[huste511]

@Henrik-Ingenieur
Eine durchlaufenden Graph hat man doch eher bei "unendlichen" Daten, die immer wieder frisch rein kommen.
Geht es um die Darstellung eines Zeitraumes (vgl. Börse: DAX). Da wäre ein fester Anfang und Ende doch besser.
Dafür würde sich doch der Sonnenaufgang und Sonnenuntergang anbieten.

[NintendoTito]

Ok, Grafik bewegt sich nicht, ist ja bekannt. Habe gerade trotzdem das Update geflasht, dachte aber, dass die Grafik nur Optional wäre. Falsch gedacht... 😬

Muss man jetzt befürchten, dass sich die Linie auf dem Display einbrennt? 🤔 😬

[Henrik-Ingenieur]

Muss man jetzt befürchten, dass sich die Linie auf dem Display einbrennt? Nein. Nicht heute, nicht diese Woche, nicht im nächsten Monat.

Und bevor trotzdem jemand in Panik verfällt möchte ich zwei Punkte zu bedenken geben:

1. Soo schnell brennt ein OLED nicht ein. Das Internet weiß das ein Einbrennen nicht innerhalb von wenigen Tagen passiert. Bei Fernseher und Monitore spricht man von >6 Monaten bis es zu Effekten kommt (nicht zu verwechseln mit Ausfällen).
2. Die beanspruchten Pixel werden langsam dunkler. Bei einem TV/Monitor kann das auffallen da sich der Bildschirminhalt ändert. Bei unserem Anwendungsfall, das OpenDTU Display, können höchstens die Diagram Achsen, ganz zart und ganz langsam dunkler werden.

Ein Update wird bald kommen aber ich kann nicht garantieren das es heute oder morgen wird. Frau + Kinder + Weihnachten... ihr kennt das.😉

Wer sich selbst überzeugen möchte: Auf meinem oben bereits gezeigten Foto von Mitte Nov läuft das Diagram schon seit >2 Wochen. Ein Einbrenneffekt würde die Achsen dunkler zeigen als die Ertragslinie. Man kann hier aber keinen Unterschied ausmachen. Der grau braun verfärbte Streifen im zweiten viertel des Displays hat die Kamera zu verantworten, nicht das Display. 😉

Quellen:

• OLED-Burn-in wird bei Ultrawide-Monitoren zum Problem
• Longevity And Burn-In Investigation 10-Month Results

[tbnobody]

The graph should move every 30 seconds or so by one pixel in the one or the other direction.
I am not at home at the moment so I cannot verify.

[Schaefers]

The code has

if (Configuration.get().Display.ScreenSaver) {
        _graphPosX = DIAG_POSX - (_graphValuesCount % 2);
    }

in it. Even though I'm not sure if this stops burn in on x-axis of the graph. This also might be confusing because the behaviour of the graph is different from the other text on the screen when screensaver is enabled.

[Henrik-Ingenieur]

There's a bug in the Screensaver code: _graphValuesCount is always == CHART_WIDTH as soon as if (_graphValuesCount >= CHART_WIDTH) is TRUE. That's why _graphPosX = DIAG_POSX - (_graphValuesCount % 2); has no effect right now.
Suggestion: instead of _iRunningAverageCnt use _graphValues[_iRunningAverageCnt] to determine the pixel shift. Additionally shift the Y-Position too.

Sample Code:
if (Configuration.get().Display.ScreenSaver) {
        _graphPosX = DIAG_POSX - (_graphValues[_graphValuesCount] % 2);
        _graphPosY = DIAG_POSY + (_graphValues[_graphValuesCount] % 2);
 }

[ms1958]

wer Angst vorm einbrennen hat, Vorschlag an den Entwickler:
man kann doch zyklisch das Graph mit der Momentanten Watt-Anzeige Tauschen z.B. im Minutentakt.
wenn die Option "bildschirmschoner aktiviert ist.
Oder: das Display zyklisch invertieren -

Mein Display ist mal kaputgegagen, der Einschalttransistor war defekt, ich hatte ihn überbrückt, um bis zum eintreffen des neuen Displays etwas sehen zu können. Nebeneffekt war, bei dem defekten Display, das das Display zeitweise ein Invertiertes Bild zeigte, also Schwarze Schrift auf hellem Grund. - Durch zyklisches invertieren kann man einbrennen auch verhindern.

[kinichahau2023]

Wer hilft einem Anfänger: Mein Diagramm scheint rechts als dem Display hinauszuragen... ?  Was muss ich ändern, dass es vollständig angezeigt wird. Bedankt!

[Henrik-Ingenieur]

Second try: firmware.zip
Gebt mir bescheid ob das Diagramm damit zappelt oder nicht.

[frank-tanne]

In v23.12.24 zappelt es . In firmware.zip nicht . Habe mich geirrt es zappelt auch, nur nicht so oft (ist aber besser so).
Danke und Frohe Weihnachten an alle.

[tm-107]

Bei mir genauso.
Außerdem habe ich bemerkt, dass ich mit der firmware.zip von vor 2 Tagen ca. 20x am Tag die Daten nicht per Web-API auslesen konnte (macht bei mir ein Script alle 60 Sekunden).
Ob die OpenDTU nicht erreichbar war oder nur keine korrekten JSON-Werte lieferte kann ich jedoch leider nicht sagen. Soweit ist die Fehlerauswertung in meinem Script nicht gediehen.

[Henrik-Ingenieur]

@tm-107 besteht das Problem immer noch?

[tm-107]

Mit den seither veröffentlichten offiziellen Versionen gab es keine übermäßigen Auffälligkeiten.
Ab und an klappt es schon immer 1-2x am Tag nicht, aber wirklich selten. Das würde ich aber eher auf WLAN-Probleme zurückführen.

[fred777]

Erstmal ein frohes Weihnachtsfest an alle!

Thema Einbrennen - da habe ich mir auch schon einige Gedanken gemacht die ich hier gern mal noch als Anstoß loswerden möchte...

Im Prinzip geht es ja nur darum dass man alle Pixel gleichmäßig "belasten" will damit sie gleichmäßig altern (=Helligkeitsverlust).

Also spielt die Zappelfrequenz eigentlich kaum eine Rolle. Man könnte den Shift auch nur aller 1 Minute ausführen. Oder stündlich. (Änderung der angezeigten Daten mal außen vorgelassen).

Wichtig ist nur dass jedes Pixel mal was anzeigt und auch mal wieder aus ist. Und durch das Zappeln lässt sich das gar nicht 100% garantieren - es gibt bedingt durch den Zeichensatz Pixel die statistisch gesehen häufiger und länger leuchten als andere.

Alternativ könnte man aber auch an stelle des Gezappels einfach hin und wieder das Display invertieren. Das dürfte eine etwas gleichmäßigere Abnutzung bewirken.

Aber letztendlich ist das auch optisch Geschmackssache.

Hab hier ansonsten ein Radon-Messgerät seit über 5 Jahren 24/7 laufen - dort zeigt OLED-Display langsam etwas Abnutzung, d.h. manche Pixel sind dunkler als andere. Erkennen kann aber trotzdem noch alles.

[NintendoTito]

Ich fände einen Wechsel der beiden Bildschirmarten auch sinnvoll. Oder alternativ die Grafik abschaltbar machen, da es in der jetzigen Form den kleinen Screen irgendwie überfüllt.

Aber meinen Hinweis nicht falsch verstehen: Danke für eure Arbeit, die Ideen und Updates! Ich möchte nicht als "Nörgler" rüber kommen.

[Henrik-Ingenieur]

Ich hab gerade den Code angepasst so das man Diagramm auch per GUI de/aktivieren kann. Jetzt muss ich nur noch heraus bekommen wir man die webapp\src\views\DeviceAdminView.vue "kompiliert". Die WebSite von OpenDTU zeigt meine zusätzliche Checkbox nämlich noch nicht an.
❓ Hat jemand sachdienlichen Hinweise?

[Fribur]

Visual Studio Code baut die webapp automatisch neu (kann man auch manuell machen...siehe Readme.md in webapp folder)...das Problem ist das Google Chrome/Edge etc die Website aus dem Cache lädt, und nicht von der OpenDTU...daher einfach Google Chrome Cache löschen und schon geht's. Irgendwo in den Tiefen des Internets findet man wie das alles automatisch geht (irgendwas mit Hashes und Versionsnummern in der Webapp)...

[Marc9485]

@Henrik-Ingenieur
Hier wird ja mittlerweile ein riesen Fass wegen einer kleinen Grafik aufgemacht...

Auch wenn ich früher als erwartet jetzt alles über HA abrufe und somit Display, LED's und Taster nicht mehr brauche schaue ich dennoch wenn ich in der Garage an der Werkbank stehe gerne noch drauf. Joa, Diagramm als Vollbild im Wechsel wäre nicht unschick aber kein muss. Aber ich wollte einfach mal "Danke" sagen dass du dir die Arbeit machst. TBNobody konnte ich für seine Arbeit etwas spenden dir aber nicht und das vergessen die Leute hier die alle eine so schlaue Meinung haben aber keine Ahnung (ich auch nicht) davon was das für ein Aufwand ist der dann dahinter steckt ein Programm dann zu ändern. Statt die X-Wünsche noch zu berücksichtigen könntest du ja genauso einfach Zeit mit (z.B.) deinen Kindern verbringen oder dir am dicken Zeh spielen und einfach alles so lassen wie du es wolltest oder die Idee einfach für dich behalten. Sollen se sich doch mal ne originale DTU kaufen. Ich glaub in China antwortet denen keiner vom Support. Aber denjenigen ist die originale eh zu teuer und obwohl der esp, display und nrf nur nen Bruchteil gekostet haben und openDTU besser ist ist man dann noch zu geizig 5, 10 oder 20€ zu spenden. Aber dann bei "Problemen" am lautesten schreien. Ich bin ehrlich, ich würde mir an deiner Stelle "LMAA, seht selber zu..." denken. Danke auch nochmal an @tbnobody und allen anderen die noch dahinter mit rum werkeln. So... Ich bin fertig mit meinem Brandbrief und ich wollte auch niemanden beleidigen sondern einfach zum nachdenken anregen. ✌🏻

[Henrik-Ingenieur]

Ich hab Code und WebApp angepasst so dass man das Diagram auf Wunsch deaktivieren kann. Aktuell sind die Änderungen noch in meinem Repo.

@Fribur Gereade hab ich etwas gelernt: Visual Studio Code linkt nur die vorcompilierte WebApp in das Binary. Die WebApp muss man vorher händisch mittels yarn build compilieren.

[anpalama1]

was und in welcher Datei muss ich tun um das Diagramm komplett im Display zu deaktivieren? Mich persönlich stört es und bringt kein Nutzen. Vielen Dank

[frank-tanne]

Einfach eine frühere Version nehmen z.b. v23.12.18

[Tiese]

Ich bin auch dafür, diese sinnbefreite Grafik wenigstens deaktivieren zu können!

[NintendoTito]

@Tiese Bißchen positivere Wortwahl wäre angebracht. Die Entwickler machen hier alles umsonst in Ihrer Freizeit. Die Grafik ist nicht "sinnbefreit" nur weil du Sie nicht benötigst. Ja, deaktivierbar fände ich auch schön, aber man muss hier nicht so "rum motzen".

[Tiese]

@NintendoTito
Ob (m)eine Wortwahl positiv oder negativ ist, sollte man jedem selbst überlassen!
Ich habe hier keinen beleidigt, sondern nur meine Meinung geäußert: diese Grafik hat für mich nun mal keinen Sinn, weil sie nichts aussagt.

Der einzige, der hier ausfällig wird, bist du @NintendoTito - nämlich mir gegenüber!

[NintendoTito]

Ja, sicher. Bestimmt.

[ms1958]

Also, ich finde die Grafik ok. hab mich jedenfalls drüber gefreut. - Das geschmäcker unterschiedlich sind ist klar, deshalb wäre die Parametrierung ob ja oder nein sinnvoll. Sinvoll fand ich auch, das die LED Helligkeit regelbar ist (seit wann eigentlich ?). Denn meine verwendeten 3mm LED waren doch sehr hell. - Kann man diese verlaufsgrafik in die Weboberfläche einbauen ? (abschaltbar, wegen den Nörglern ;-) )
Ansonsten , tolles Projekt und Danke an den Entwicklern.
Manfred

[NintendoTito]

Ich finde die Vollbild-Grafik im Wechsel mit den Daten bislang auch richtig cool, danke nochmal dafür!

Tatsächlich habe ich den Thread gerade nochmal aufgesucht, weil ich auch fragen wollte, ob man die Daten, welche ja anscheinend für die Grafik auf der DTU vorhanden sind, ggf. auch in die Weboberfläche einbauen kann?

[schneeer]

Hi,

fände ich auch geil.

Sowas in der Art?

Für aktuellen Tag, Woche, Monat Jahr und letzten 10 Jahre?
Ich versuche es gerade für mich zu implementieren...
Die Grafik wird mit Google Charts realisiert.
Benötigt werden eine handvoll Arrays, wo die Daten reingeschrieben werden.
Etwas Code zum Aufbereiten der Daten.
Gelegentlich mal speichern, zumindest Abends und bei openDTU Systemereignissen (openDTU Reset, Firmwareuptate).
Zum Speichern würde ich eine externe SD-Karte einsetzen, um den ESP nicht kaputt zu schreiben.
Speichern 1x pro Stunde schlägt mit 8670 Schreibvorgängen in den Flash pro Jahr zu buche; wenn man das bei Nacht weg lässt, sind es bestimmt immer noch so 4000-5000 mal. Dann ist der Speicher im ESP nach 2-3 Jahren hin. Vielleicht kann man das noch irgendwie optimieren um auf die SD verzichten zu können.

Allerdings sieht es so aus, das ich wohl wegen mangelnder Ahnung von HTML, CSS, PHP u.s.w. an der Web-App scheitere. Im Bild ist ein mit einer fertigen Datentabelle gefüttertes Demodiagramm zu sehen. Vom Datenaufbereiten und an die App zu übergeben bin ich noch richtig weit weg!
Momentan scheitere ich schon daran, das die Web-App das Diagram beim 1. Aufruf der Seite anzeigt. Ich muss immer die Seite erst neu laden.

[Struessje]

Danke schön für dieses coole Feature. Da ich hauptsächlich Remote auf OpenDTU zugreife: Wäre es möglich, dieses kleine Diagramm auch auf der Webseite anzuzeigen. Es müsste auch nicht Größer sein, zeigt aber die grundsätzlichen Tendenzen und den Maximalwert, einfach gut!!

[Tobbz2k]

Würde ich auch cool finden!

[cactus-online]

Es gibt diesen guten Ansatz. Auf jeden Fall hätte ich auch großes Interesse an einer Darstellung im WebUI.

[ms1958]

muss nun noch ins Gehäuse ...

[ms1958]

Hallo, Ich hätte da noch eine Idee.......
Da ich eine Zero-Regelung über Homeassistant mit NodeRed am laufen habe,
die über das Temporäre Wechselricherlimit eine Einspeisung ins Netz auf 0 Ausregelt,
fände ich es Sinnvol, wenn das Wechselricherlimit (zuschaltbar) im Display angezeigt würde.
Gruss, ms1958

oben: gelb: erzeugte Leistung , blau: Leistung am Haushaltszähler / unten: Blau: Limit HMS-8002T