Solaranzeige und FHEM

[Funkboje]

Das Open Source Projekt Solaranzeige [ solaranzeige.de ] kann die Verschiedensten Photovoltaik Geräte wie z.B. Laderegler, Wechselrichter, BMS, Zähler auslesen und die Daten grafisch anzeigen. Auch die Daten des Sonoff POW R2 kann angezeigt werden. Alle ausgelesenen Daten können per MQTT an Smart Home Zentralen gesendet werden. Über MQTT können Steuerbefehle auch wieder zurück an die PV Geräte gesendet werden.
Hier sieht man die Anzeige eines Sonoff POW R2. Vom Bildschirm aus kann das Relais auch betätigt werden. Die Solaranzeige wird auf einem Raspberry Pi 3B oder 4B installiert. Es können bis zu 6 Geräte angeschlossen werden. Mehr Informationen gibt es auf unserem Support Forum.

-----------------------------------------------------------------
Ulrich
(Admin von solaranzeige.de)

[KölnSolar]

Nicht schlecht, wenngleich wir mit FHEM ähnliches(allerdings individuell konfigurierbar) für einige PV-devices bieten. 

Warum in einem image "versteckt" ?  Kaum jemand wird einen Rpi nur für Euren Dienst nutzen wollen.  Ich persönlich werde argwöhnisch, wenn ich ein image in meinem Netzwerk installieren soll. Da kann man ja ne Menge "Böses" drin verstecken.
Grüße Markus

[Funkboje]

Ca. 500 zufriedene Nachbauer sprechen eine andere Sprache.

Schöne Grüße aus Essen

Ulrich

[CoolTux]

Wusste gar nicht das unser Forum seit neusten eine Werbeplattform ist.
Du solltest Dich wenigstens als kommerzieller User markieren.

Irgendwie sieht das Bild aus wie meine Grafana Dashboard Anzeige.

[pnewman]

Und was hat die Solaranzeige mit FHEM zu tun?

Liest sich auf der Webseite eher wie ein eigenständiges Programm.


Gruß
Ralf

[KölnSolar]

Ca. 500 zufriedene Nachbauer sprechen eine andere Sprache.

Klingt überheblich und beantwortet nicht meine Frage u. Bedenken.

Und ich bin kein Lemming....

[Funkboje]

Die Solaranzeige beinhaltet jetzt auch eine Solar-Überschuß-Steuerung für verschiedene Wallboxen.

[gvzdus]

Ich würde ganz gerne mehr über "SolarAnzeige" diskutieren.

Einst hatte mir pah mal empfohlen, für mehr Steuerungslogiken und Energiemanager bezogene Fragen auch photovoltaikforum.com zu durchstöbern.
Nach ein paar Stunden durch die Seiten stolpern (man tut sich ja auch bei FHEM bisweilen etwas schwer) ist mein Eindruck: Da sind eher Anwender, die ihren SMA Home Manager mit dem 200 Euro teureren Bosch "FlexStart"-Wäschetrockner zusammen bringen wollen.

Und letztlich bin ich auf "solaranzeige" dort im Forum gestoßen, und dann jetzt wieder hier.

Ich habe ja nun so einige Zeit in die PV-Überschusssteuerung der Tiefkühltruhe und der HK-Pumpe gesteckt und hier vorgestellt: Tendenziell not for the masses zum Nachbau. Aber wenn ich ab Februar eine OpenWB steuern will, dann ist es sinnvoll, dass meine Basteleien auch anderen nutzen. Und da ist Ulrichs Ansatz mit dem DiskImage und guter GUI einfach endkundengerechter. Meinetwegen darf auch gerne sogar das Ganze ("Raspi + Display + D0-Stecker + FlashImage") verkauft werden, solange die Software OpenSource *und* frei ist.

Zudem ist EEBUS spannend, und das Verdikt von "pah" dazu war: "Eher nicht in FHEM, zu enge Timings etc."

Daher:

• Wie "kommerziell" ist "solaranzeige"? Unter welcher Lizenz steht Dein Code?
• Ulrich, D0-Schnittstelle am Stromzähler wird nicht unterstützt, richtig? Schon da könnte man den Nutzern doch Kosten für Hardware ersparen, oder?
• Gibt es andere Vorschläge, wie denn Dinge wie EEBUS & Co gemacht werden sollen? Denn das die Zukunft dahin geht, ist doch m.E. klar.
• Auf Anhieb finde ich sonst noch OpenEnergyMonitor, da scheint die Lizenz des Code GPLv3 zu sein

Nur zu meinem Fokus: Ich interessiere mich eher, an einem EnergyManager zu basteln. Aber in die Tendenz geht solaranzeige ja klar.

Update:
M.E. wird man SolarAnzeige gerechter, wenn man es als Distribution und nicht als Software (die irgendwie in Konkurrenz zum FHEM steht) ansieht. Ja, natürlich ist da auch Software-Code dabei (PHP im 1-Sekunden-Takt aufgerufen?), und Software für Setup. Und wenn ich es richtig sehe: Eine Distribution, die frei kopierbar ist, und für die recht liebevoll Anleitungen geschrieben wurden.

Ich habe mir jetzt OpenEnergyMonitor angesehen: Einerseits sind sie recht geschäftstüchtig im Verkauf von Hardware - die aber scheinbar eher auf den UK-Markt ausgelegt ist. Englisch muss ja nicht unbedingt "international zielen" bedeuten. Auch hier viel PHP (nicht gerade meine Lieblingssprache). Abgesehen davon spielen sie lieber mit OpenHAB und NodeRed.

Das bedeutet für mich: FHEM ist selbst am nächsten am "Energiemanager" dran. Schließlich steht das "EM" ja auch für Energie-Messung.

M.E. wird das Thema in den nächsten 2 Jahren enorm an Fahrt aufnehmen: Wir haben den Durchbruch bei der Elektromobilität in den Zulassungszahlen, die Wallboxen werden gefördert. Und es ist m.E. unvermeidlich, dass darauf die dynamischen Stromtarife wie von Awattar folgen: Denn der Börsenstrompreis für den frühen Abend wird, wenn wie jetzt, wenn bei Dunkelheit die BEVs nach Hause zurückkommen und an die Wallbox angeschlossen werden, ins ziemlich schmerzhafte steigen. Lösungen, um daraus für die Wallbox eine Ladestrategie aus eigener Solarproduktion und günstigem Nachtstrom zu bilden, werden nötig und gefragt sein. Beispiel für heute: Strompreis um 17 Uhr > 5,5 Ct teurer als um 23 Uhr. Entspricht Diesel für 82 Ct statt 99 Ct: Wie lange wäre da wohl die Schlange vor der Tanke? Wir müssen uns aber nicht in die Schlange stellen oder am Abend tanken fahren: Wir brauchen nur eine intelligente Steuerung für die Wallbox.

Und m.E. sollte nicht alles von E3/DC oder SMA aus einer Hand gekauft werden müssen, sondern die Integration herstellerübergreifend sein. Das sehen ja auch die Hersteller selber so, und arbeiten an Themen wie EEBUS. Da sehe ich im Moment das spannendste Feld für FHEM: BEV-Ladeoptimierung.

[Funkboje]

Hallo gvzdus,

ich möchte gerne auf deine Fragen antworten:

Wie "kommerziell" ist "solaranzeige"? Unter welcher Lizenz steht Dein Code?

Die Solaranzeige ist nicht kommerziell. Die Software steht unter der GNU Lizenz GPLv3. Steht in jedem PHP Script am Anfang.

Ulrich, D0-Schnittstelle am Stromzähler wird nicht unterstützt, richtig? Schon da könnte man den Nutzern doch Kosten für Hardware ersparen, oder?

S0 und D0 Schnittstellen sind in der Solaranzeige nicht angedacht. Wohl aber solche "Hilfsmittel"

Gibt es andere Vorschläge, wie denn Dinge wie EEBUS & Co gemacht werden sollen? Denn das die Zukunft dahin geht, ist doch m.E. klar.

EEBUS ist schon angedacht. Sobald er mehr an Bedeutung gewinnt, werde ich ihn umsetzen.  Ich habe mein Ohr auf der Schiene.

Auf Anhieb finde ich sonst noch OpenEnergyMonitor, da scheint die Lizenz des Code GPLv3 zu sein

Kenne ich nicht. Scheint in Deutschland nicht im Fokus zu liegen.

Ich sehe weder OpenWB noch FHEM noch HomeMatic als Konkurrenz. Obwohl wir uns alle in manchen Funktionen etwas überschneiden, wird das keine Auswirkungen, bei dem in Zukunft riesiegen Markt, haben. Ich arbeite gerne mit jedem zusammen, der daran Interesse hat und achte mehr darauf, dass die verschiedenen Projekte sich untereinander unterhalten können.

Proprietäre Software sehe ich eher als veraltet an und setze auf offene Schnittstellen.

Der Fokus der Solaranzeige liegt im Moment auf der Überschuß-Steuerung für eine Vielzahl von Wallboxen und demnächst auch auf einem Lastmanagement. Beides wird in der Zukunft ein großes Thema mit viel Potential.

[KölnSolar]

•Ulrich, D0-Schnittstelle am Stromzähler wird nicht unterstützt, richtig? Schon da könnte man den Nutzern doch Kosten für Hardware ersparen, oder?

Ich denke das ist genau der richtige Ansatz. Es gibt eine Vielzahl proprietärer Messsysteme. Die braucht kein Mensch und natürlich erst recht niemand, der ein FHEM-System hat.

Der Hintergrund ist relativ simpel. Der Gesetzgeber hat 2016 das MSbG eingeführt. Demnach werden ALLE ans öffentliche Stromnetz angeschlossene Verbraucher/Erzeuger mit einer "modernen Messeinrichtung"(Gesetzesbegriff  ) ausgerüstet werden. Ab einem bestimmten Verbrauch und bei Erzeugungsanlagen > 7 kWp ist der Anschluss mit einer "intelligenten Messeinrichtung" auszurüsten. Diese ist nichts anderes als eine "moderne Messeinrichtung" mit einem zusätzlichen Gateway zur Übertragung der Messdaten an den Messstellenbetreiber(in der Regel der Verteilnetzbetreiber).
Die "moderne Messeinrichtung" ist nichts anderes als ein digitaler Zähler, der die üblichen Ferraris-Zähler(analoge Drehscheibe) ersetzt. Alle mir bekannten digitalen Zähler haben 2 IR-Schnittstellen: eine, die nach der Installation verplombt/unzugänglich ist. Dort installiert der MsB ggfs. seinen Lesekopf für sein Gateway. Die Zweite Schnittstelle ist eine Kundenschnittstelle. Dort darf der Kunde seinen eigenen IR-Lesekopf installieren. Auslesbarer Datenumfang unterscheiden sich nach Gerätehersteller u. Verteilnetzbetreiber.

In FHEM haben wir mehrere Lösungen, um die Daten auszulesen. Am weitesten verbreitet ist sicherlich der Einsatz des OBIS-Moduls.

Und ich denke ich muss keinem FHEMler erklären, was er alles machen kann, wenn er die Daten in seinem FHEM-System verfügbar hat.

Bei der Anschaffung von Wallbox, Batteriespeicher, Solaranlage..... ist somit darauf zu achten, dass die Gerätschaft offene Schnittstellen hat, dass deren Daten ebenfalls in FHEM verfügbar sind, ggfs. mit Daten aus FHEM gefüttert und gesteuert werden können. U.U. lassen sich so bereits beim Erwerb einige hundert EUR für eigentlich überflüssige Zusatzhardware einsparen.

Grüße Markus

[gvzdus]

Mir wird der Unterschied im Denken allmählich klar:

SolarAnzeige ist eine Anzeige. Ein Display. Das Projekt wird vorgestellt mit "Raspi mit 7 Zoll Touch-Display" oder auch "Raspi hinten per VEGA-Anschluss an einen TFT-Monitor geschraubt". Bei Ulrich gehört der Raspi ans Display. Bei uns fühlt sich der Raspi u.a. im Zählerschrank am wohlsten, Lieblingsplatz Hutschiene. Deswegen auch das Widerstreben, das aus unserer Sicht Nahestliegende zu tun: Den 20-Euro-Opto-Kopf an den Raspi stecken und - wie Du, Markus, schreibst, z.B. 250-20 Euro ggü. der Kostallösung sparen (die natürlich für den Speicherbetrieb zum Millisekunden schnellen Reagieren trotzdem nötig sein kann).

Ulrich hat nun eine Lösung realisiert - ganz bevorzugt über das IP-LAN - minütlich den WR & Co. auszulesen, die Daten wegzuschreiben und vor allem gut zu visualisieren. Wenn ich's richtig verstehe, indem per crontab einmal pro Minute eine PHP-Seite aufgerufen wird, die alle Magie enthält. Das hat seine Berechtigung, wenn es eben nur "das Display" gibt, und weil sich eine Menge Leute schon mal grundsätzlich nicht an FHEM herantrauen, und schon gar nicht mit der Sicherheit, mal eben eine Lösung zu schaffen, die vor dem Schönheitsempfinden der Ehefrau Bestand hat.

Unsereins würde sagen: Die Treiber für die Datenerhebung sind in FHEM - wo auch sonst. Mit "minütlich" sind "wir" ja in "unserer" Welt auch nicht zufrieden. "Wir" füttern gerne ein Display über MQTT, dass auch gerne visualisieren, analysieren kann, etc.

Zur Koexistenz dann im nächsten Beitrag...

[gvzdus]

Zur Koexistenz / Entwicklung

Markus, wir beide haben uns mal locker über unsere Systeme unterhalten, aber wir haben noch nicht mal gemeinsame Objekte definiert, die z.B. "solarleistung" oder "netzbezug" heißen. Nicht die beste Voraussetzung dafür, dass daraus eine große Lösung für die Menschheit entsteht. Ulrich macht Leute glücklich und bietet ihnen eine hübsche Anzeige - und im solaranzeige.de-Forum hilft er nach Kräften.

M.E. ist eine Solaranzeige ohne Visualisierung, was am Netzübergang los ist, außer bei Inselanlagen allenfalls teilfertig. Ob Ulrich sich des Themas annimmt, ist seine Sache. Er könnte das lokal auf dem Raspi über vzlogger mit MQTT lösen, oder z.B. über FHEM, oder etwas Drittes, was auf der seriellen Schnittstelle horcht. Oder über einen zweiten Raspi im Zählerschrank mit vzlogger oder FHEM. "Seine" Nutzer brauchen dafür tendenziell eher Hilfe als ein FHEMler.

Ulrich hat auch eine "Standardlösung" mit einem vServer vorgestellt und dokumentiert. Diese Lösung sieht so aus, dass der lokale Raspi über das Internet authentifiziert und verschlüsselt in die InfluxDB auf dem vServer schreibt. Ich persönlich finde das schade, weil Influx proprietärer als MQTT ist.

Skizze 1:
Ob Influx (dank InfluxDBLogger) oder eleganter mit MQTT: "Wir FHEMler" könnten ganz flott einen Feed von FHEM in die Cloud aufsetzen. Beispiel: Ulrich erstellt neben seinem Flash-Karten-Image von SolarAnzeige ein AMI-Image für die Amazon-EC2-T4G-Reihe (die preislich bei 1,90 USD/Monat reserved losgehen), man (Otto-Normal-FHEMler) zieht "seine" Instanz hoch, füttert sie aus FHEM und kümmert sich weiterhin nicht um Grafana & Co., so wie ich das bis jetzt auch nicht tue, hat aber eine schicke Darstellung - auch jederzeit unterwegs erreichbar.

Skizze 2:
Der Weg anders herum: "Erst war SolarAnzeige, dann kam FHEM dazu" ist auch denkbar. Ulrich sieht das in dem Sinne: Einmal pro Minute erhält FHEM per MQTT die WR-Daten, die SolarAnzeige gelesen hat. Aber das ergibt eben m.E. nur Nachteile ggü. anders herum.

[Funkboje]

Warum ich derzeit nicht selber die S0 / D0 Schnittstellen verarbeite hat folgenden Grund:

Der Raspberry wird in der Regel nahe dem Wechselrichter installiert, da der Großteil (70-80%) der WR direkt oder indirekt mittels USB ausgelesen wird und somit nicht allzu weit vom Wechselrichter entfernt installiert werden muss. Die meisten Wechselrichter passen nicht und gehören auch nicht in den Strom-Verteilerschrank. Deshalb setze ich auf eine dezentrale Lösung. Ich suche noch eine Lösung, die die S0 / D0 Schnittstelle ausließt und die Datendann per WLAN / LAN weiterleiten kann. In welchem Protokoll ist nicht so wichtig. das würde ich dann schon integrieren.
Für die S0 Schnittstelle gibt es so ein "Gerät". Das wird in den nächsten Wochen integriert. Für die D0 Schnittstelle suche ich noch eine Lösung. Da ist noch etwas Geduld angesagt. Parallel dazu lese ich ja schon einige EnergyMeter per MODBUS aus.

Aus meiner Erfahrung benötigt man für eine gut funktionierende Solar-Überschuß-Steuerung keine Watt genauen Überschuß Daten. Das ist an der Realität vorbei gedacht. Vielmehr eine Kombination zwischen PV-Modul-Produktion und aWATTar Preisinformationsverarbeitung. (aWATTar Preise werden demnächst mit verarbeitet werden können.)

[gvzdus]

> Aus meiner Erfahrung benötigt man für eine gut funktionierende Solar-Überschuß-Steuerung keine Watt genauen Überschuß Daten.

Wattgenau nicht, aber kilowattgenau. Und ob nun die Waschmaschine heizt (2 kW), oder Wärmepumpe läuft, oder der Herd (oder gar ein Durchlauferhitzer) macht für die <= 10 kW-Solaranlagen im Spätherbst bisweilen einen Unterschied wie Tag und Nacht

[Funkboje]

Da hast Du Recht. Für FHEM ist das enorm Wichtig. Für die Solaranzeige spielt das aber derzeit keine Rolle.
Die Solaranzeige unterstützt zur Zeit solche Geräte noch nicht.