Anwendungen zu Vis-Inventwo & Icontwo

[legro]

@humidor said in Anwendungen zu Vis-Inventwo & Icontwo:

.. Shelly 25, Ausgänge schalten Tore, Eingänge (Rollenschalter) für geschlossen. ..

Mit dem Aktor stehen dir ja alle Möglichkeiten offen. Aber musst du nicht den Motor in diesem Fall direkt mit 230V ansteuern. Der Shelly 2.5 kann doch gar nicht potentialfrei schalten.

Du machst mich neugierig. Wie sieht deine Schaltung aus?

Zwei Anmerkungen ..

Mit den Mittel unserer Android Geräten (Samsung) hatte das Ganze nie vernünftig funktioniert. Wir fühlten uns regelrecht veräppelt. Daher haben wir uns selbst verAPPLEt. Wir nutzen seit Monaten das von Apple bereitgestellte Geofencing. Das funktioniert sehr zuverlässig.

Mit der von mir vorgeschlagenen Lösung kannst du aus jedem Zustand (auf/zu) dein Tor steuern und mittels YAHKA auch gleich das Ganze in HomeKit von Apple einbinden. Zwei Vorteile sind der Lohn: Du bist dein Geofencing Problem los und sowohl in ioBroker als auch HomeKit wird dir der Torzustand korrekt angezeigt.

[Humidor]

@legro mit dem Shelly 25 werden Koppelrelais geschalten (230V Spule, Kurzschluss am Kontakt - wie mit dem Schalter in der Garage, der Garagenantrieb hat da eine Kleinspannung und erkennt bzw. reagiert auf den geschlossenen Kreislauf, wird wohl bei den meisten Antriebe so sein).

Hört sich interessant an, wir haben Samsung & iPhone und damit bin ich gebunden beide Welten zu benutzen. Aktuell läuft es über Life360 und doch sehr unbeständig. Was ist dieses Geofence von Apple? Wie kann ich das im ioBroker nutzen?

[legro]

@humidor said in Anwendungen zu Vis-Inventwo & Icontwo:

.. mit dem Shelly 25 werden Koppelrelais geschalten (230V Spule, Kurzschluss am Kontakt - wie mit dem Schalter in der Garage, ..
.. Was ist dieses Geofence von Apple? Wie kann ich das im ioBroker nutzen?

Dann nutzt du das Ganze ähnlich wie unsereiner es unter MagentaSmartHome (MSH) realisiert hat. Da in diesem Schrottsystem eine Torsteuerung gar nicht vorgesehen war, habe ich einen Rollladenaktor von Homematic zweckentfremdet. Der Rollladenaktor betreibt bei mir ebenfalls ein Relais (230V), das als Schließer arbeitet. Das potentialfreie Relais schaltet die zwei Steuerleitungen des Torantriebes kurz und löst so die gewünschten Aktionen aus. Hier habe ich meine Lösung dokumentiert, wie ich sie in MSH umgesetzt habe.

Da ich bei uns ja Rollladenaktor und Schließer bereits verbaut hatte, nutze ich natürlich nach wie vor den Rollladenaktor um das Schließerrelay zu betätigen. Nur wäre es unsinnig, diese Lösung hier vorzustellen, geht's mit dem Shelly 1 nicht nur einfacher, sondern zudem auch noch viel preiswerter.

Und nun zu Geofencing und Apple HomeKit ..

Das Ganze funktioniert nicht nur recht zuverlässig, sondern auch überraschend einfach: YAHKA macht's möglich.

Im HomeKit definiere ich vier Automationen, die einen (virtuellen) Schalter betätigen. Diese beiden Schalter verknüpfe ich mittels YAHKA mit ioBroker. So ist eine An-/Abwesenheit in beiden Welten sichtbar.

In ioBroker/YAHKA sieht das Ganze so aus ..

Hierbei ist userdata.0.Alarmanlage.Anwesenheit.<Name> ein Datenpunkt, der durch den (virtuellen) Schalter geändert wird.

[Humidor]

@legro sagte in Anwendungen zu Vis-Inventwo & Icontwo:

YAHKA

interessant, ganz hab ichs aber noch nicht, YAHKA ist ein Adapter vom Github OK, aber das Pendant ? ein echtes Homekit Gerät
im iPhone/Homekit kann ich kein leeres Gerät anfügen?

[legro]

@humidor said in Anwendungen zu Vis-Inventwo & Icontwo:

..
interessant, ganz hab ichs aber noch nicht, YAHKA ist ein Adapter vom Github OK, aber das Pendant ? ein echtes Homekit Gerät ..

Die Konfiguration geht vom ioBroker hin zum HomeKit.

Zunächst im ioBoker ..

• YAKHA Instanz in ioBroker erzeugen.
• Schalter in YAHKA definieren (siehe oben!)

.. und anschließend im HomeKit ..

• YAHKA als Bridge einbinden und ..
• .. schon stehen die in ioBroker definierten Schalter im Homekit zur Verfügen (siehe oben!)

Wenn du noch Fragen hast, nur her damit!

[Humidor]

@legro super danke habe ihn schon aktiv
wie mache ich den Switch nun im Homekit zum GPS Geo Fence?

[legro]

@humidor said in Anwendungen zu Vis-Inventwo & Icontwo:

wie mache ich den Switch nun im Homekit zum GPS Geo Fence?

Das hatte ich in diesem Thread versucht aufzuzeigen.

In der Definition der Automationen findet die Verknüpfung zwischen (virtuellem) Schalter und Geofencing statt. Die beiden Bilder aus dem HomeKit zeigen die (virtuellen) Schalter als Tasterflächen, im nebenstehenden Bild ist die Verknüpfung zu den erforderliche Automationen zu sehen.

Ist das nicht phantastisch, was all die Entwickler uns so an die Hand geben?

[Humidor]

@legro hmm, dann hat sich das schon wieder erl. für mich, ein HomeKit Gerät habe ich nicht.

[legro]

@humidor said in Anwendungen zu Vis-Inventwo & Icontwo:

.., ein HomeKit Gerät habe ich nicht. ..

Als Steuerzentrale kannst du ein iPad, HomePod oder AppleTV verwenden. Ein HomePod mini kostet nicht die Welt. Der ist - für Apple unglaublich günstig - schon für 99€ zu haben.

In Anbetracht des Mehrwertes, den so eine kleine Kugel kostet, ist dies ganz gewiss eine Überlegung wert.

[Humidor]

@legro ja korrekt, ich hab aber schon zuviel von dem ganzen Zeugs rumstehen...
der AppleTV 3 kanns nicht, bis ein anderes ins Haus kommt, muss ich dann warten, extra deswegen werde ich wohl keines kaufen.

[legro]

Ermittlung der Regenmengen

So sieht das Ergebnis unter Verwendung von Netatmo aus ..

Konfiguration des UniversalWidgets

Das Widget sollte als Background konfiguriert werden; es soll ja bei einem Klick keinerlei Reaktion ausführen. Das Feld Objekt ID bleibt leer. Auf diese Weise wird stets der Eintrag aus dem Feld Beschriftung bei falsch angezeigt (s.unten!).

Im Bereich Inhalt wird als Inhaltstyp HTML/Text gewählt. Dies bewirkt, dass lediglich all das angezeigt wird, was im Bereich Beschriftung bei falsch (bzw. wahr) eingetragen ist.

Die angezeigten Werte sind Datenpunkte, die mittels des Regenmessers von NETATMO ermittelt werden.

Das zur Ermittlung der Daten verwendete Skript überwacht den Datenpunkt Rain in the last 24 hours von dem Regenmesser, in dem von Netatmo saldierend der Regen eines Tages eingetragen wird. Um Mitternacht (0:00 Uhr) wird dieser von NETATMO zurück auf 0 gesetzt. Netatmo sendet ca. alle 8 - 10 Minuten den Wert dieses Datenpunktes, auch wenn zwischenzeitlich keine Änderung zu verzeichnen war. Das Skript schreibt nur dann diesen Wert von Rain in the last 24 hours in den Datenpunkt TempRegenTag, wenn der alte Wert in diesem Datenpunkt übertroffen wird.

verwendete Datenpunkte

Es werden insgesamt folgende Datenpunkte verwendet, die in zwei Gruppen eingeteilt sind: Regenmengen in den gerade laufenden Zeiträumen Tag, Woche, Monat, Jahr und jene Regenmengen, die nach Ablauf der jeweiligen Zeiträume angefallen sind, bezeichnet mit RegenTag, RegenWoche, RegenMonat und RegenJahr. Beispiel: RegenWoche enthält die Regenmenge der vorgegangenen Woche.

• TempRegenTag: Regenmenge des laufenden Tages
• TempRegenWoche: Regenmenge der laufenden Woche
• TempRegenMonat: Regenmenge des laufenden Monats
• TempRegenJahr: Regenmenge im laufenden Jahr
• RegenTag: Regenmenge des vorangegangenen Tages
• RegenWoche: Regenmenge der vorangegangenen Woche
• RegenMonat: Regenmenge des vorangegangenen Monats
• RegenJahr: Regenmenge im vorangegangenen Jahr

Auswertungen mittels InfluxDB und Grafana

Um graphische Darstellungen der Regenverteilung über Tage, Wochen, Monate und Jahre zu erhalten, werden die Datenpunkte RegenTag, RegenWoche, RegenMonat und RegenJahr bei deren Änderung in InfluxDB eingetragen.

Da der Regenmesser desöfteren sehr viele Nachkommastellen liefert, die eine übersichtliche Darstellung innerhalb des Widget verunmöglichen, werden die über Rain in the last 24 hours gelieferten Werte auf drei Nachkommastellen gerundet und dem Datenpunkt TempRegenTag bei Änderung zugewiesen.

Die übrigen Datenpunkte werden mittels CRON-Jobs verwaltet. Täglich um 0:00 Uhr wird ..

• .. der Inhalt von TempRegenTag in den Datenpunkt RegenTag geschrieben, sodass in diesem Datenpunkt stets die Regenmenge des Vortages zu finden ist.
• .. der Inhalt von TempRegenTag saldierend in den Datenpunkt TempRegenWoche abgelegt.
• .. TempRegenTag saldierend in TempRegenMonat gespeichert.
• .. TempRegenTag im Datenpunkt TempRegenJahr aufaddiert.
• .. zum Schluss wird TempRegenTag wieder auf 0 gesetzt.

Wöchentlich (d.h.: Sonntag Abend bzw. 0:00 Uhr) wird der Inhalte von TempRegenWoche in RegenWoche abgespeichert. Anschließend wird TempRegenWoche wieder auf 0 gesetzt.

Entsprechend werden die monatlich und jährlich auszuführenden Arbeiten durchgeführt.

Hier nun ein Beispiel, wie die anschließende Darstellung sich in Grafana darbietet:

Aufbereitung des HTML-Textes

Im HTML-Format werden hier die Werte der Datenpunkt aufbereitet, formatiert, .. eingetragen.

[zurück]

[sigi234]

@legro
Hallo, kann man deine Widget wo runterladen? Oder bin ich blind?

[legro]

@sigi234 said in Anwendungen zu Vis-Inventwo & Icontwo:

@legro
Hallo, kann man deine Widget wo runterladen? Oder bin ich blind?

Keine Angst! Du bist nicht blind.

Ich ging/gehe davon aus, dass es sich nicht lohnen mag, diese Kombinationen von Inventwo-Widgets zum Download einzustellen. Schließlich muss man doch ohnehin Größen, Datenpunkte, Code, .. anpassen.

Aber ich lasse mich durchaus eines Besseren belehren.

[Humidor]

@legro meine Bilder sind weg
mit dem Update…

[FredF]

@humidor

[legro]

=========================================================

[9] DAIKIN - Klimaanlage

=========================================================

So sieht das fertige Ergebnis unserer Installation aus. Es werden drei Klimageräte gesteuert.

Die Steuerung eines Klimageräts wird durch mehrere in einander verschachtelte Widgets realisiert. Diese werden im Folgenden ausführlich beschrieben.

Als Hintergrund wird ein sog. Background-Widget verwendet, auf dem alle übrigen Widgets dargestellt werden und der Text Wohnen angezeigt wird.

Zum Aus-/Einschalten des Klimagerätes wird ein Widget verwendet, das mit der Option Switch konfiguriert wird.

Als Datenpunkt wird power aus dem DAIKIN-Adapter verwendet. Ein Icon aus dem VIS-ICONTWO-Adapter wird zur Visualisierung verwendet, das schwarz/grün dargestellt wird, um die Zustände AUS/AN gut sichtbar anzuzeigen.

Zur Regelung der Zieltemperatur und der relativen Zielfeuchtigkeit werden zwei horizontale Schieberegler verwendet, deren IDs an die entsprechenden Datenpunkte im DAIKIN-Adapter gebunden werden. Für die Temperatur wird der Bereich auf 0 - 40 °C und für die Feuchtigkeit auf 0 - 50% eingeschränkt.

Die von dem Klimagerät gelieferten Statuswerte für die relative Luftfeuchtigkeit, Innen- und Außentemperatur werden mittels eines Background-Widgets mittels Binding der entsprechenden Datenpunkte des DAIKIN-Adapters angezeigt.

In den nachfolgenden Steuerungselemente werden sowohl Option Buttons (rechteckformig) als auch Radio Buttons (kreisförmig) verwendet. Können die Option Buttons völlig unabhängig von einander (de)aktiviert werden, so bilden die Radio Buttons Felder, in denen immer nur genau eine Option aktiv sein kann. Für beide Arten wird stets ein Widget vom Typ CheckBox/RadioButton verwendet; allein die Konfiguration in den Optionsfeldern bestimmt deren Verhalten:

• Option Button: Jedes Widget erhält seinen eigenen Datenpunkt.
• Radio Button: Alle Schaltflächen werden an denselben Datenpunkt gebunden.

Unser Gerät vermag die Betriebsarten zu modifizieren. Hierzu stehen drei Optionen zur Verfügung. Die Schaltflächen werden als eigenständige Optionsschaltflächen (Option Buttons) implementiert, indem jedem Widget ein eigener Datenpunkt zugeordnet wird.

Nicht in jeder Betriebsart sind alle Modi verfügbar. Näheres bitte der jeweiligen Gerätebeschreibung entnehmen! Das Gerät setzt ggf. eine gewählte Option wieder zurück.

• ECO (Econo): Diese Funktion ermöglicht einen möglichst effizienten Betrieb, indem der Wert für maximale Stromaufnahme begrenzt wird.
• kräftig (powerful): Bei jeder Betriebsart wird durch diesen Modus schnell die Wirkung maximiert.
• STREAMER: Reinigt die Luft mittels eines Hochgeschwindigkeits-Elektronenstrom mit hoher Oxidationskraft, beseitigt schlechte Gerüche und Viren usw.

Diese Optionen werden als Gruppe von Radio Buttons implementiert, da jeweils nur eine Auswahl möglich ist. Hierzu wird an alle sog. Boxen in der Widget-Konfiguration derselben Datenpunkt angebunden. Die zu verwendenden Werte kann man dem DAIKIN-Adapter entnehmen.

Die beiden übrigen Felder werden analog eingebunden.

Usw. .. usf. ..

[zurück]

[sigi234]

@legro sagte in Anwendungen zu Vis-Inventwo & Icontwo:

Ich ging/gehe davon aus, dass es sich nicht lohnen mag, diese Kombinationen von Inventwo-Widgets zum Download einzustellen. Schließlich muss man doch ohnehin Größen, Datenpunkte, Code, .. anpassen.
Aber ich lasse mich durchaus eines Besseren belehren.

Ein Download als Vis wäre trotzdem Super, die DP kann man ja leicht mit Notepad++ ändern.
Ich habe alle meine Vis hochgeladen, und diese müssen ja auch angepasst werden.
Abgesehen davon lernt ein Anfänger auch damit.

[legro]

@sigi234

Na gut, ich werde mich einmal daransetzen und die Widgets als Download bereitstellen.

Allerdings tue ich mich bei jenen eingebunden Geräten schwer, die eindeutig über ihre Seriennummer angesprochen werden, wie dies etwa bei Homematic-Geräte der Fall ist. Ich möchte eigentlich nicht die Seriennummern meiner Geräte hier veröffentlicht wissen.

[sigi234]

@legro sagte in Anwendungen zu Vis-Inventwo & Icontwo:

Ich möchte eigentlich nicht die Seriennummern meiner Geräte hier veröffentlicht wissen.

Ja, dachte ich mir. Bei heiklen DP ersetze ich einfach die SN/DP mit XXXXXXXXXXXXX und exportiere die Vis/Widgets mit einen anderen Namen.

Beispiel:

Widget_test_anonym.txt

[legro]

=========================================================

[10] PV Anlage

=========================================================

Vorab ..

Anfang Februar wurde unsere PV Anlage in Betrieb genommen. Hier entsteht die Dokumentation zu deren Visualisierung, die auf einem Fronius Wechselrichter (GEN24) mit zugehörigem Smartmeter (TS 65A-3) und einer BYD Batterie mit 7,7KWh basiert.

Anfänglich war's sehr zeitaufwendig herauszufinden, was die einzelnen Datenpunkte eigentlich beinhalten und anhand dessen eine leidlich korrekte und stimmige Darstellung der Daten zu erstellen. Lassen die Angaben zu den Leistungsflüssen kaum Wünsche offen, so blieben bei den Energiewerten aufgrund unzureichender Angaben anfangs vielfach Unstimmigkeiten.

Datenpunkte für Leistung und Energie versus Anzeigen in solarweb

Warum überhaupt eine eigene Visualisierung, schließlich gibt's doch von Fronius bereits gute Software (Solarweb, Fronius-App)? Die Antwort ist einfach: Ich wollte (absolut) realistische Ergebnisse. Als Lohn für meine Bemühungen, darf ich nun mit 10 - 20% weniger Ertrag auskommen., nur die Einspeisewerte stimmen mit den Angaben von Fronius bis auf die Kilowattstunde überein.

Verwenden Solarweb und die Fronius App nach meinen Beobachtungen die von den Solarmodulen erzeugte DC-seitigen Energien, so fließen in der hier vorgestellten Lösung ausschließlich die AC-seitigen ins Haus und Netz eingespeisten Leistungen bzw. Energiewerte ein. Schließlich tragen nur diese zum Ertrag bei - d.h.: Bestimmen, was man unmittelbar mehr oder weniger am Jahresende im Portemonnaie hat. Die Software von Fronius berücksichtigt im Prinzip offenbar keinerlei Verluste in Batterie und bei der DC/AC-Umwandlung.

Nach langen und intensiven Beobachtungen gehe ich von folgender Interpretation der Datenpunkte aus:

• TOTAL_ENERGY enthält die tatsächliche AC-seitige, vom GEN24 erzeugte (Wechselstrom)Energie, die aus Batterie und PV-Modulen bereitgestellt werden. Jegliche Verluste sind an dieser Stelle bereits berücksichtigt. Diese Energie fließt ins Haus oder wird ins Netz eingespeist.
• EnergyReal_WAC_Sum_Produced erfasst den Anteil von TOTAL_ENERGY, der ins Netz des Versorgers eingespeist wird.

Grenzen der hier vorgestellten Lösung

Der Vorteil, dass hierbei die Wandlungsverluste bereits berücksichtigt sind, ist mit Vorsicht zu genießen. Wie die Erfahrung zeigt, kann es vorkommen, dass die Batterie durch den Wechselrichter aus dem Netz nachgeladen wird, wenn der Wert für SoC unter den minimalen Sollwert fällt. Diese Energie, die aus dem Netz stammt, wird dann fälschlicherweise zum Wert in TOTAL_ENERGY hinzugezählt.

Darüber hinaus kommt es durch die Vermischung von Solarenergie aus Modulen und Batterie vor, dass die am Vortag in die Batterie gespeicherte Energie, die aber erst in der Nacht verbraucht wird, dem falschen Tag zugeordnet wird. Eine auf den Tag genaue Zuordnung ist somit nicht möglich. Wird jedoch die Batterie am Tag stets voll geladen, sollte sich das Ganze über die Tagesgrenzen hinweg jedoch ausgleichen.

Adapter in ioBroker

Wer lieber das Ganze über Modbus/TCP steuern möchte, findet hier die TSV-Datei zum direkten Importieren in den Modbus-Adapter von ioBroker: GEN24&Smartmeter

Es stehen gleich zwei Adapter für Fronius Geräte zur Verfügung. Basiert der erste auf den Daten vom Fronius Server (Cloud), so greift der zweite ausschließlich auf die lokal verfügbaren Daten zu. Ich habe mich zunächst für den zweiten Adapter entschieden. Wenn ich mich tiefer in die Materie eingefunden habe, werde ich wohl auch Zugänge über Modbus verwenden.

Elemente der Visualisierung

• Die Messinstrumente am rechten Rand zeigen die Werte für Spannung U, Stromstärke I und Leistung P an den beiden MPPT Eingängen des Fronius GEN24, wobei natürlich U x I = P gilt. An MPPT1, der 20A Eingangsstrom akzeptiert, wird ein Strang aus parallel geschalteten Modulen von Meyer Burger mit 4,62KWp angeschlossen. Mit dem zweiten MPPT ist eine sog. Solarterasse mit nur 1,96KWp verbunden. Diese Angaben gilt es bei den Konfigurationen der Messinstrumente zu berücksichtigen.
• Im Widget für die Solarmodule wird die Gesamtleistung P_PV = U1 x I1 + U2 x I2 angezeigt. Liefern die Module Energie, so wird dieses Widget grün (aktiv) ansonsten inaktiv (schwarz) dargestellt.
• Das Widget des Wechselrichters kennt drei Anzeigenmodi: aktiv/grün (Normalbetrieb), inaktiv/schwarz (Bereitschaft/standby) und aktiv (grün) mit blinkendem Symbol (P_AC < 0). Der letzte Zustand tritt ein, wenn die Leistung von den PV-Modulen geringer ist als die Verlustleistung des Wechselrichters.
• Das Widget für den Netzversorger: grün = Einspeisung, rot = Netzbezug
• Batterie-Widget: rot = Batterie wird entladen, grün = Batterie wird geladen
• die Orientierungen der Pfeile passen sich der Flussrichtung der Leistungen an.
• Das Diagramm spiegelt die PV-Leistung im Verlaufe des Tages wider.

Die vier Diagramme in der zweiten Abbildung zeigen alle möglichen Energieverhältnisse.

• Bezug: Stellt die aus dem Netz des Versorgers bezogene Energie dar, die zum geltenden Tarif bezahlt werden muss.
• Verkauf: Die ins Netz des Versorgers abgegebene Energie, für die man eine Vergütung erhält.
• Solar: Die von der Anlage aus Modulen und Batterie erzeugte Energie nach der Wandlung in Wechselstrom. Hierbei sind ggf. Verluste in Batterie und AC/DC-Umwandlung berücksichtigt. Diese Energien beinhalten auch die ins Netz eingespeiste Energie (siehe blaues Diagramm).
• Konsum: Solar [grün] abzüglich Verkauf [blau] ergibt die ins Haus eingespeiste, insgesamt verbrauchte Energie.

Die dritte Abbildung dient zur Erfassung der Kosten und Erträge für unsere im Haushalt benötigten Energien.

• Ertrag: die insgesamt im Haushalt verbrauchte Energie (Bezug+Verkauf)
• Autarkie: Quotient aus (selbst genutzte Solarenergie) / (insgesamt verbrauchte Energie)
• Eigenquote: (selbst genutzte Solarenergie) / (insgesamt erzeugte Solarenergie)

Tarifangaben (Bezug, Verkauf) und die errechneten Werte beziehen sich auf das laufende Kalenderjahr (s. unten!).

Datenpunkte des GEN24

Hierbei den Überblick zu gewinnen, ist eine echte Herausforderung, zumal Fronius seinerseits kräftig zu Verwirrung beiträgt. Einige scheinen doppelt vorhanden zu sein, während andere gar nicht gepflegt werden. Sind die Leistungsangaben noch leidlich umfassend, so sieht's bei den Energiewerten regelrecht traurig aus.

Nachfolgend wird die Sammlung dieser Datenpunkte beschrieben. Es werden nur jene näher betrachtet, die auch für die Visualisierung verwendet werden. Die oberste Ebene umfasst ..

.. wobei lediglich aus den Ordnern inverter, inverterinfo, meter und powerflow Datenpunkte verwendet werden.

Aus dem Ordner fronius.0.inverter.1 werden folgende Datenpunkte verwendet ..

• UDC, IDC : Spannung und Stromstärke am MPPT1 Eingang
• UDC_2, IDC_2 : Spannung und Stromstärke am MPPT2 Eingang
• PAC : vom GEN24 AC-seitig erzeugte Leistung. Als Energiequellen dienen hierbei die DC-seitig verfügbaren Energien aus Batterie und PV-Modulen.
• TOTAL_ENERGY : AC-seitige aus den PV-Modulen und/oder Batterie erzeugte Gesamtenergie. D.h.: Dieser Datenpunkt kann nicht dazu verwendet werden, die von den Solarmodulen erzeugte Energie direkt zu erfassen, denn die in die Batterie fließende Energie wird nicht in diesem Datenpunkt mitgezählt. Die in der Batterie gespeichrte Energie geht erst in die Zählung ein, wenn sie wieder aus dieser entnommen wird.

Aus UDC, IDC, UDC_2 und IDC_2 werden die Leistungswerte durch Produktbildung aus Spannungen und Stromstärke an den Eingängen MPPT1 und MPPT2 ermittelt. UDC_3 und IDC_3 enthalten stets bloß null, werden also nicht verwendet.

Da die Datenpunkte YEAR_ENERY und DAY_ENERGY nicht vom GEN24 gepflegt werden, muss man diese Energien aus TOTAL_ENERGY errechnen. Dazu später mehr.

Aus dem Ordner Inverterinfo.1 ..

.. wird lediglich der Datenpunkt InverterCode, der den Arbeitszustand des Wechselrichters widerspiegelt (7 = running, 14 = sleeping, .. siehe auch InverterState), verwendet. Dieser Datenpunkt regelt die Darstellung des Icons des Wechselrichters.

Aus dem Ordner fronius.0.meter.1 ..

.. werden die folgenden Werte benötigt ..

• fronius.0.meter.1.EnergyReal_WAC_Sum_Consumed = aus dem Netz bezogene Energie
• fronius.0.meter.1.EnergyReal_WAC_Sum_Produced = ins Netz eingespeiste Energie
• fronius.0.meter.1.PowerReal_P_Sum = aus dem Netz bezogene Leistung
• [ fronius.0.meter.1.EnergyReal_WAC_Minus_Absolute = .. (offenbar identisch mit Produced)]

Aus dem letzten verbliebenen Ordner fronius.0.powerflow.1 ..

.. werden die folgenden Werte ..

• P_Akku : in die Batterie fließende Leistung
• P_Grid : aus dem Netz bezogene Leistung (für die man zahlen muss).
• P_Load : ins Hausnetz abgegebene Leistung als Summe von P_AC und P_Grid. Anm.: Hieraus lässt sich der Eigenverbrauch des GEN24 ermitteln.
• P_PV : von den Solarmodulen DC-seitig gelieferte Leistung

.. entnommen.

Die hier aufgeführten Datenpunkte E_Total, E_DAY und E_YEAR sind redundant zu jenen aus fronius.0.Inverter.1, die dort als TOTAL_ENERGY, YEAR_ENERGY und DAY_ENERGY bezeichnet werden. Auch hier verbleiben die letzten beiden leer (null).

eigene Datenpunkte

Aus diesen Datenpunkten werden weitere, eigene Datenpunkte abgeleitet. Diese werden in mehreren Ordnern unterteilt eingruppiert: Einspeisung, Netzversorger, PVAnlage, Inverter, und Zähler. Skripte sorgen für das korrekt Befüllen der Datenpunkte. Dazu später mehr.

Die ersten drei Ordner besitzen stets die gleiche Struktur. Exemplarisch wird daher hier nur der Inhalt des Ordners Einspeisung erläutert.

• Wh_Abgabe_startTag : enthält den Wert des Datenpunktes fronius.0.meter.1.EnergyReal_WAC_Minus_Absolute, der täglich um 0:00 Uhr genommen wird.
• Wh_Abgabe_tmpTag : Energie, die täglich ab 0:00 Uhr ins Netz des Versorgers abgegeben wurde
• Entsprechend werden die temporären Werte für Woche, Monat und Jahr am Ende der jeweiligen Zeiträume ermittelt und abgespeichert.
• Die Datenpunkte vTag, vWoche, .. enthalten die Werte der jeweiligen vorangegangenen Zeiträume.

Im Ordner ..

.. werden die Werte der Leistungen für die beiden MPPT-Stränge sowie die Zustandswerte für den GEN24 abgelegt.

Visualisierung der Leistungsflüsse

Die verwendeten Icons stammen aus der Sammlung /icons-fatcow-hosting/caution_high_voltage.png sowie vis.icontwo.

Die Flussrichtungen werden durch die Vorzeichen geregelt. So gilt beispielsweise für die Leistungen Batterie: laden < 0 entladen > 0; Netz: einspeisen < 0; beziehen > 0 usw.

Zur Darstellung der unterschiedlichen Orientierung der Pfeile werden wie in der Abbildung aufgezeigt Transformationen in CSS global dem Projekt hinzugefügt.

Um die unterschiedlichen Flussrichtungen zu visualisieren, werden zwei entgegengesetzt orientierte Pfeile übereinander gelegt und deren Sichtbarkeit an die Vorzeichen der jeweiligen Leistungen geknüpft.

Zur Darstellung des Icons für den Wechselrichter werden zwei Widgets verwendet. Aus der Sammlung Icontwo ein sog. als Background konfiguriertes Multi-Widget mit drei Zuständen für die unterschiedlichen Ansichten des GEN24 und ein aus der Sammlung basic stammendes HTML-Widget zur Anzeige der AC-Leistung des Wechselrichters.

Die Anzeige der Leistung wird mittels des sog. Bindings realisiert.

Das Multi-Widget bewertet den Inhalt des Datenpunktes InverterZustand und erzeugt hiermit die gewünschten Anzeigen.

Exemplarisch wird hier der Zustand dargestellt, in dem der GEN24 Energie verbraucht statt zu liefern.

Der ins Haus eingehende Leistungsfluss wird durch ..

.. ein einfaches, als Background konfiguriertes Widget aus der Sammlung Icontwo und wiederum einem HTML-Widget visualisiert, das nur (aktiv/grün) angezeigt wird, wenn Energie ins Haus fließt, was jedoch im Normalfall stets der Fall ist.

Das als Background konfigurierte Standard-Widget aus Icontwo für den Netzzugang ..

.. ist analog zu dem Haus-Widget aufgebaut. Jedoch werden hier zwei Zustände angezeigt: aktiv/grün = Einspeisung ins Netz, inaktiv/rot = Netzbezug.

Alles rund um die Batterie ist hier zu finden ..

Angabe des SoC in Prozent ..

Leistung, die aus der Batterie entnommen bzw. in diese hinein fließt. rot = Entnahme, grün = Aufladung

Die in der Batterie verfügbare Energie wird ermittelt aus SoC und der maximalen Kapazität abzüglich einer Restladung von 10%.

Die Widgets zur Anzeige von typischen Betriebswerten sind vergleichbar aufgebaut. Exemplarisch wird hier nur das Widget ..

.. ausführlich besprochen. Die Umrechnung der Einheiten Wh in KWh gerät hier etwas aufwendig, da man bekanntlich in HTML eigentlich nicht ohne Weiteres Berechnungen ausführen kann. Die Codierung wird im Folgenden in Code-From angegeben ..

<h2>Bilanz</h2>
Zukauf : 
{x:0_userdata.0.Fronius.Netzversorger.Wh_Grid_tmpTag;parseFloat(x/1000).toFixed(3)} KWh <br>
Verkauf: {x:0_userdata.0.Fronius.Einspeisung.Wh_Abgabe_tmpTag;parseFloat(x/1000).toFixed(3)} KWh</br>
Konsum: 
{x:0_userdata.0.Fronius.Netzversorger.Wh_Grid_tmpTag;y:0_userdata.0.Fronius.PVAnlage.Wh_PV_tmpTag;z:0_userdata.0.Fronius.Einspeisung.Wh_Abgabe_tmpTag;parseFloat((parseFloat(x)+parseFloat(y)-parseFloat(z))/1000).toFixed(3)} KWh

Autarkie: {a:0_userdata.0.Fronius.Netzversorger.Wh_Grid_tmpTag;x:0_userdata.0.Fronius.Einspeisung.Wh_Abgabe_tmpTag;y:0_userdata.0.Fronius.PVAnlage.Wh_PV_tmpTag;z:0_userdata.0.Fronius.Einspeisung.Wh_Grid_tmpTag;parseFloat(100*(parseFloat(y)-parseFloat(x))/(parseFloat(y)-parseFloat(x)+parseFloat(a))).toFixed(1)} %

• heute = Wh_PV_tmpTag enthält die Energie aus der PV-Anlage, die AC-seitig ins Haus eingespeist wird abzüglich der ins Netz des Vorsorgesystems abgegebene Energie wurde. Üblicherweise wird diese Energie als Eigenverbrauch bezeichnet.
• Woche = Wochensumme der Werte aus heute
• Monat = Monatssumme
• Jahr = Jahressumme

Anmerkung: Die hier angezeigten aktuellen Tageswerte umfassen nicht die gesamte in die Batterie eingespeicherte Energie. Die Energie aus der Batterie ist in diesen Werten nur inkludiert, wenn sie aus dieser entnommen und durch den Wechselrichter in Wechselstrom AC-seitig umgewandelt zur Verfügung gestellt wurde. Der Vorteil: Die Verluste durch Umwandlungen sind hierbei berücksichtigt. Daher zeigt die hier vorgestellte Visualisierung immer deutlich kleinere Werte für die Erträge an, wie die App von Fronius, in der die primären Energie auf er DC-Seite verwendet werden.

Diese Schwierigkeiten lassen insbesondere das Widget Bilanz in seiner Ausgestaltung recht aufwendig werden.

Auch hier wird die zugehörige Kodierung dieses Widgets wieder in Code-Form angegeben.

<h2>Bilanz</h2>
Zukauf : 
{x:0_userdata.0.Fronius.Netzversorger.Wh_Grid_tmpTag;parseFloat(x/1000).toFixed(3)} KWh <br>
Verkauf: {x:0_userdata.0.Fronius.Einspeisung.Wh_Abgabe_tmpTag;parseFloat(x/1000).toFixed(3)} KWh</br>
Konsum: 
{x:0_userdata.0.Fronius.Netzversorger.Wh_Grid_tmpTag;y:0_userdata.0.Fronius.PVAnlage.Wh_PV_tmpTag;z:0_userdata.0.Fronius.Einspeisung.Wh_Abgabe_tmpTag;parseFloat((parseFloat(x)+parseFloat(y)-parseFloat(z))/1000).toFixed(3)} KWh
Autarkie: {a:0_userdata.0.Fronius.Netzversorger.Wh_Grid_tmpTag;x:0_userdata.0.Fronius.Einspeisung.Wh_Abgabe_tmpTag;y:0_userdata.0.Fronius.PVAnlage.Wh_PV_tmpTag;z:0_userdata.0.Fronius.Einspeisung.Wh_Grid_tmpTag;parseFloat(100*(parseFloat(y)-parseFloat(x))/(parseFloat(y)-parseFloat(x)+parseFloat(a))).toFixed(1)} %

Die folgenden Angaben umfassen ausschließlich die Energien auf der AC-Seite und berücksichtigen somit sowohl Verlust in DC/AC-Wandlung und Batterie.

• Zukauf = Wh_Grid_tmpTag enthält die aus dem Netz ins Haus eingespeiste Energie
• Verkauf = Wh_Abgabe_tmpTag enthält die ans Netz abgegebene Energie
• erzeugt = Wh_PV_tmpTag entspricht der Energie aus der PV-Anlage und ggf. Entnahme der Batterie.
• Konsum = Wh_Grid_tmpTag + Wh_PV_tmpTag - Wh_Abgabe_tmpTag

Die AC-seitige Energie Wh_PV_tmpTag ist also die tatsächlich von der PV-Anlage generierte Energie, die man einspart.

Zur Visualisierung der Leistungen der PV-Anlage über den Tag wird ein mittels Grafana und InfluxDB erstelltes Diagramm in einem iFrame-Widget dargestellt.

Zur Darstellung der Betriebswerte der PV-Anlage wird direkt auf die Daten im Fronius-Adapter zugegriffen. Exemplarisch sieht das für die Leistungsanzeige zu MPPT1 wie folgt aus ..

Verwaltung der eigenen Datenpunkte

Diese eigenen Datenpunkt werden durch Blockly-Skripte gepflegt. Da wiederum viele Teile von identischer Struktur sind, werden die entsprechenden Teile nur exemplarisch behandelt.

Zwei Trigger werden definiert, um die Werte im Ordner 0_userdata.0.Fronius.Inverter zu füllen.

Das folgende Skript verwaltet die Datenpunkte im Ordner 0_userdata.0.Fronius.Zähler ..

Da die Energiewerte nur als saldierte Gesamtsummen erfasst werden, muss zur Berechnung der Werte für einen einzelnen Tag um 0:00 Uhr ein Schnappschuss (siehe Startwerte) der Werte gemacht werden. Die Tageswerte ergeben sich dann als Differenz aus aktuellem Zählerstand und diesen Startwerten.

Bei diesem Vorgehen gilt es jedoch den Fall zu berücksichtigen, dass das Skript am Tag erneut gestartet wird. Um die hiermit verbundenen Schwierigkeiten zu umschiffen, dienen die bei jedem Neustart des Skriptes ausgeführten drei Anweisungen, welche dafür sorgen, dass die Startwerte für den aktuellen Tag korrekt bleiben.

Für den Fall, dass man diese Werte in InfluxDB schreiben möchte, sollte man dies nicht via Adapter durchführen, da die über Tag angesammelten Werte dem Folgetag zugemessen würden. Um dies zu korrigieren, gibt es die Funktion, ..

.. welche dafür sorgt, dass die Daten mit einem um zwölf Stunden früheren Zeitstempel in InfluxDB geschrieben werden. Da dies nicht mittels Blockly möglich ist, wurde das Ganze in JavaScript kodiert ..

function (ziel, wert, zeit)

zeit=zeit-12*3600*1000 // Vortag 12:00 Uhr mittags
sendTo('influxdb.0', 'storeState', {
    id: ziel,
    state: {ts: zeit, val: wert, ack: false, from: ziel}
}, result => console.log('added'));

.. und kann wie im nachfolgenden CRON-Job gezeigt aufgerufen werden.

Täglich um 0:00 Uhr wird dieser CRON-Job ausgeführt und füllt die temporären Werte in den Ordnern 0_userdata.0.Fronius.Einspeisung/Netzversorger/PV-Anlage

Um die Werte der vergangenen Zeiträume (_vWoche, _vMonat, usw.) zu aktualisieren müssen an jedem dieser Zeiträume die nachfolgenden CRON-Jobs ausgeführt werden ..

täglich ..

wöchentlich ..

monatlich ..

jährlich ..

=========================== noch nicht überarbeitete Teile ===========================

Visualisierung der Energien

VORSICHT! Hinsichtlich der richtigen Interpretationen der Datenpunkte bin ich mir nach zwei Tagen Betrieb der Anlage alles Andere als sicher. Wer hier sein Wissen einbringen kann, ist herzlich willkommen.

Und nun wird's kompliziert. Die Energien werden von Fronius äußerst spartanisch behandelt. Es stehen nur die Gesamtwerte der von der PV Anlage gelieferten Energie (TOTAL_ENERGY = E_Total), die vom Netz bezogene (ENERGIYREAL_WAC_SUM_CONSUMED) und die ins Netz eingespeiste Energie (ENERGYREAL_WAC_SUM_PRODUCED) zur Verfügung. Werden die ersten beiden vom Wechselrichter geliefert, so werden die letzten beiden vom Smartmeter zur Verfügung gestellt, wobei das Smartmeter natürlich am sog. Übergabepunkt zum Netz positioniert sein muss. Hieraus gilt es nun durch tägliche Schnappschüsse und geeignete Differenzbildungen die gewünschten Werte zu erzeugen. Noch schlimmer steht's um die in die Batterie einspeisten Energien. Da hier nur Leistungswerde und Zeiten zur Verfügung stehen, muss man wohl oder übel eine (Art Riemann)Summe über die Produkte von P*t bilden.

Diese mathematisch exakte Ermittlung lässt sich jedoch nicht realisieren, da die Größen der Zeitintervalle von dem System vorgegeben werden; man muss nehmen, was man kriegen kann: Schnappschüsse.

Da über Modbus diese Daten voraussichtlich doch zugänglich sind, dürfte sich das Ganze entspannen.

Fortsetzung folgt!

[zurück]