Mein Forum
Registrieren
Neu hier?
Baukonstruktionen
Fertighaus
Fenster
Dämmung
Dichtheit
Passivhaus
Schimmel
Energieausweis
Heizung
Pellets
Erdwärme
Warmwasser
Stromsparen
Solaranlagen
Photovoltaik
Lüftungsanlagen
Energiespartipps
Berechnungen
|
|
||
PV-relevante habe ich zwei. Das erste habe ich für das Balkonkraftwerk erstellt, das zweite danach für Balkonkraftwerk+große PV, angelehnt an die openwb-Anzeige, ergänzt mit Verbrauchsanzeige der Wärmepumpe. Angezeigt auf einem 10" Tablett mit Wandhalterung von Vidabox. Wobei das nur die Openhab-Unterseiten sind mit den Grafanaeinbettungen.   |
||
|
||
|
Cool, danke! was ist das am ersten Bild ganz unten für ein Widget? bezüglich "stationäre Visualisierung" schwanke ich noch zwischen einem tablet so wie du (das sollte allerdings "günstig" sein, weil "übrig" hab ich keines) oder einem normalen Display mit zB eine Raspi... |
||
|
||
|
Das am ersten Bild unten (oder am zweiten Bild oben) sind Openhab2-Buttons, Grafana selbst ist hier nur in Openhab eingebettet. |
||
|
|
||
|
||
|
Ah, ok, jetzt verstehe ich... |
||
|
||
Einmal Stromproduktion  |
||
|
||
Heizbetrieb Übersicht  |
||
|
||
Heizung und Solarthermie (dailies)  |
||
|
||
Solarthermie Detail  |
||
|
||
|
Woher ziehts du deine solaren estimates? |
||
|
||
|
Ich mag deine Schildkröte! 😁 Wie geht denn das? |
||
|
||
 mit value mappings, hier ist die Pumpe nur aus oder ein, gemappt auf 0 und 1. Das value kann jeder 'Text' sein und damit auch ein unicode Zeichen. Meine Lüftungsanlage hat da mehr mappings, hier in der nodered-ui, der erste Wurf einer Billigsdorferübersicht für's Handy:  |
||
|
||
|
@taliesin Wow, danke! ich sehe schon da stht mir noch viel Arbeit bevor ich nutze https://solcast.com/ man muss sich zwar anmelden es gibt dann aber eine kostenlose API (ist halt beschränkt auf ca. 10 Abfragen pro Tag, aber das ist ausreichend) Was mir gefällt ist dass man mit Est(10) und Est(90) eine Art "Konfidenzband" mitbekommt. Ich hab mich auch kurz mit https://forecast.solar/ beschäftigt, aber dort ist die Datenqualität signifikant schlechter. |
||
|
||
|
Danke für den Thread, hier kann man sich austauschen und brauchbare Darstellungen teilen. Im Home Assistant hat man viele Einzelwerte, im Grafana wirds dann optisch ansehlich, bin auch erst am Start. 😉 Angefangen hats mal so:  Hier mal aktuell Speicher, bisschen PV:  Wo ich mich erst einarbeiten muss, was aber ziemlich nervig ist: Die Aufzeichnungen laufen seit Jänner, die influxDB gut gefüllt, nett zum Spielen. Dann kommt irgendein Update, man denkt sich nix, nach der Installation fehlen gleich Daten, Grafana zu vergessen: Vom 13/14/15.08. als Beispiel die Solarproduktion (siehe rechts oben) - Grafana/InfluxDB meinens dann nett und fassen die Menge am 16.08. zusammen. Damit mag zwar die Summe stimmen, aber wie ich das grafisch wieder hinbekomme - noch keine Ahnung, wird man sich in der DB spielen müssen. Selbes dann in der Grafik gleich drunter - 29.08. ein Minusertrag von 6,39MWh, toll - ganze Grafik für die Fisch... 😌  Neu neben PV soll jetzt die Panasonic Aquarea ordentlich rein, am besten noch diese Woche vor der Saison. Ich spiel mich gerade, welche Werte überhaupt interessant wären:  Muss aber ehrlich sagen wenn man Monate/Jahresweise die PV Werte präsentieren möchte, finde ich die Sankey Diagramme direkt in Home Assistant besser herzeigbar als ich Klick mich da durch Grafana durch...  die goldene Mitte wäre vielleicht ein kombinierter One-Pager mit Grafana und HA kombiniert... Freu mich auf eure Dashboards, da kann man sich viel Abschauen - DANKE fürs Teilen! 👍 |
||
|
||
|
Danke für deine Beiträge! Echt spannend, ich konnte schon viele ideen abgreifen! Das ist natürlich schlecht... deswegen liegen meine Daten in einer Postgres-Datenbank, da sollte es solche probleme nicht geben. |
||
|
||
|
So schaut bei uns die Basisansicht für die PV-Insel aus. Heute leider eher traurig ☁️ Nicht ganz so fancy wie andere hier, aber ich sehe auf einen Blick, ob Klimaanlage einschalten drin ist oder nicht.  |
||
|
||
|
Wandern die forecasts dann auch einfach in die Datenbank? Wenn du die Energiedaten verwendest, kommt das natürlich so zustande, hat gar nichts mit der Datenbank zu tun. Werden die Leistungsdaten über den Tag integriert, dann passiert dieser Fehler so nicht. Das hat aber andere Nachteile, z.B. ist die Genauigkeit durch das Zeitinterval begrenzt. Datenverlust hatte ich trotz zig updates bei InfluxDB noch nie, aber gut - nix verschreien. Mehr als die Sicherung restoren sollte es in keinem Fall sein. Mich stört öfter mal die Eingeschränktheit von InfluxQL, Flux wäre sicher besser, aber ich konnte mich zu der Umstellung nicht aufraffen. Einen echten monthly query kann man mit InfluxQL meiner Meinung nach nicht machen, aktuell sind das 30-Tages Daten, mit Flux kein Problem. Flux ist aber im 'maintenance mode', also ist dieser Umstieg auch nicht mehr sinnvoll. Sankey gibt es für Grafana übrigens als plugin, habe das aber noch nicht probiert. |
||
|
||
|
Ja die landen auch in der Datenbank, damit hab ich auch "historische" Forecasts. Da man nur Werte alle 30 Minuten bekommt, tut das nicht weiter weh (im Vergleich zu vielen anderen Daten, die ich alle 10 Sekunden speichere). Da mein Server aber eh 16 TB Kapazität hat, ist mir das im Moment ziemlich egal Energie- vs. leistungsdaten: da mach ich's mir einfach un dspeichere (soweit verfügbar) beides (best of both worlds) Selber zu integrieren wäre mir zu riskant und zu ungenau. Ich kenne InfluxDB nur vom Namen her - was hat es mit den "30 tagen" auf sich? |
||
|
||
|
Ich speichere auch Leistung und Energie, aber je nach chart verwende ich andere Daten. InfluxQL unterstützt kein 'group by datepart(month, ...)' , daher steht da aktuell 'group by time(30d)'. Wenn also 'Löcher' in den Daten erlaubt sind, die größer als das Anzeigeintervall sein können, dann tendiere ich zum selber integrieren, sonst bekommt man den Effekt, dass 2 Tage leer sind und der dritte dann die Summe aller 3 Tage hat. Es gibt wohl auch eine 'range' calculation in den transforms in Grafana, die das Problem mit den Energiedaten sauber löst, der Standardansatz ist da halt immer 'difference' und da passiert dann obiger Effekt. |
||
|
||
|
Ah, ich verstehe... da hat Postgres sicher seine Stärken und Vorteile. Übrigens bin ich voll begeistert wie effizient man die Abfragen gestalten kann... Grafana stellt in einer Variable das "Intervall" zwischen zwei Punkten einer Grafik zur Verfügung (abhängig vom anzuzeigenden Zeitraum und der Bildschirmauflösung) und das kann man wunderbar verwenden: SELECT date_bin() funktioniert ähnlich wie datepart(month, ...) (in PSQL halt "date_trunc()" nur dass das Intervall mehr oder weniger beliebig sein kann. |
||
|
||
|
Influxdb 3.0 bietet ein normales SQL interface an, aber ich habe das noch nicht migriert, bei mir läuft influxdb aktuell nicht im docker container sondern nativ am Linux server und die Datenmigrierei ist auch noch so eine Sache. |
Beitrag schreiben oder Werbung ausblenden?
Einloggen
Kostenlos registrieren [Mehr Infos]
