SMA Home Manager

Anfragen zum Erstellen von Modulen, Fragen zu Modulen
chmeyer
Beiträge: 4
Registriert: Sa Nov 30, 2019 12:34 pm

Re: SMA Home Manager

Beitrag von chmeyer » So Dez 01, 2019 11:15 pm

KevinW hat geschrieben:
So Dez 01, 2019 7:46 pm
Zu 3.
Heißt du hast einen nicht modbusTCP fähigen WR?
Doch, der WR kann schon ModbusTCP. Eigentlich. Ich bekomme es eben nur nicht ohne Solateur hin.
KevinW hat geschrieben:
So Dez 01, 2019 7:46 pm
SBFspot mag klappen, eine Automatisierung seitens openWB wird aber nicht kommen. Massiver Aufwand für wenige Nutzer.
Wenn das jemand als Modul implementieren möchte, natürlich gerne.
...
Wenn du den selbst installiert hast kannst du die Daten von SBFSpot z.B. in die Ramdisk der openWB schreiben lassen.
Dann in openWB das http Modul nehmen und auf die Datei verweisen damit openWB den Wert einliest.
Das verrückte ist: Es scheint wirklich einfach so zu klappen, und zwar ohne ModbusTCP und nur mit SBFspot und dem Default-User-PW des Geräts, naja und der IP-Adresse eben.
Ich will es nicht beschwören (es ist dunkel=kein Ertrag=kein Test), aber das PV-Modul: "WR mit URL abfragen" läuft mit Deinem Vorschlag super und zumindest den pvewh-Wert bekomme ich auch schon, für pvwatt steht im Moment eben "0" da:

Code: Alles auswählen

echo "-$(/usr/local/bin/sbfspot.3/SBFspot -nocsv -nosql -finq -v | grep ETotal | sed 's/.*: *//' | sed 's/kW.*//')*1000" | bc | sed 's/\..*//' > /var/www/html/openWB/ramdisk/pvewh

echo "-$(/usr/local/bin/sbfspot.3/SBFspot -nocsv -nosql -finq -v | grep "Total Pac" | sed 's/.*: *//' | sed 's/kW.*//' )*1000" | bc | sed 's/\..*//' > /var/www/html/openWB/ramdisk/pvwatt
Naja, mal sehen ob das mit dem Auslesen des PV-Ertrags bei Sonnenschein auch funktioniert. Werde mal eine Zeit lang ein paar cronjobs laufen lassen und Bericht erstatten.

chmeyer
Beiträge: 4
Registriert: Sa Nov 30, 2019 12:34 pm

Re: SMA Home Manager

Beitrag von chmeyer » Mi Dez 04, 2019 8:58 pm

Hallo zusammen,

es klappt: Mit Hilfe von SBFspot kann man OHNE Modbus (und damit ohne das Freischalten seitens des Solateurs) die Daten der SMA-Wechselrichter (Tripower STP 8000TL-20) und Batteriesysteme (mit Sunny Island 6.0H) abfragen und in OpenWB verwenden.
KevinW hat geschrieben:
So Dez 01, 2019 7:46 pm
SBFspot mag klappen, eine Automatisierung seitens openWB wird aber nicht kommen. Massiver Aufwand für wenige Nutzer.
Wenn das jemand als Modul implementieren möchte, natürlich gerne.
Das ist verständlich.
Da ich aber einerseits zu wenig über die Interna von openWB weiß und andererseits nicht wirklich mit Python und PHP umgehen kann, werde ich dieses Modul ebenfalls nicht implementieren (zumindest nicht jetzt).

Trotzdem empfinde ich das Abfragen der WR ohne Modbus als wesentlich eleganter (SMA-ähnlicher), sicherer (kleinerer Angriffsvektor, unverschlüsselte Modbus-Kommunikation mit schreibender Möglichkeit) und einfacher (kein Solateur-"Installer"-Passwort nötig) als die bisherige Lösung. Es ist lediglich das Benutzerpasswort der Wechselrichter nötig (bei mir war es das unveränderte SMA-Default-Passwort "0000"). Alternativ kann aber natürlich auch der "Installer"-Zugang mit dem Installer-Passwort verwendet werden.

Deshalb möchte ich hier für andere einfach festhalten (zumindest so ungefähr), was ich getan habe um meine WR in das openWB-Setup einzubinden:
  • openWB auf einem Raspi installieren.
  • Unter Einstellungen - Modulkonfiguration das Strombezugsmessmodul für den Sunny Homemanager mit Seriennummer einrichten
  • Beim Speicher Modul den SMA Sunny Island Speicher auswählen. Dieses Modul braucht zwar eigentlich Modbus, doch ich habe später die nötigen Textdateien einfach mit den SBFSpot-Werten überschrieben.
  • Unter Einstellungen - Misc - SMA Support aktivieren und neu starten (das habe ich noch öfter gemacht).
  • SBFspot installieren und (mehrfach?) konfigurieren, aber ich glaube das war gar nicht nötig, weil ich später eigene Config-Dateien (für beide WR) erstellt habe.
  • Ein eigenes kleines Abfrage-Script schreiben (s.u.) und einen cronjob dafür anlegen, der es jede Minute ausführt.
  • Unter Einstellungen - Modulkonfiguration das PV Modul "WR mit URL abfragen" eingerichtet, so dass es http://192.168.x.xxx/openWB/ramdisk/pvwattsbf und http://192.168.x.xxx/openWB/ramdisk/pvewhsbf abfragt.
Konfigurationsdateien:
  • Die IP-Adressen lassen sich auch automatisiert mittels Speedwire Device Discovery ermitteln
  • Das Passwort sollte ggfs. in der openWB-Oberfläche abgefragt werden ("0000" ist Factory-Default)
  • Ohne Plantname, OutputPath und Timezone läuft SBFspot nicht, auch wenn wir es nicht brauchen.

Code: Alles auswählen

# /usr/local/bin/sbfspot.3/SBFspot.Batt.cfg
IP_Address=192.168.2.106
Password=0000
Plantname=Batterie
OutputPath=/home/pi/smadata/%Y
Timezone=Europe/Berlin

Code: Alles auswählen

# /usr/local/bin/sbfspot.3/SBFspot.PV.cfg
IP_Address=192.168.2.103
Password=0000
Plantname=SMA-PV-WR
OutputPath=/home/pi/smadata/%Y
Timezone=Europe/Berlin

Code: Alles auswählen

#!/bin/bash
#set -e
# Datei: /var/www/html/openWB/sbfspot.sh, mittels chmod +x ausführbar machen!
# TODO: sbfspot Fehlermeldungen und leere Rückgabewerte abfangen, z.B. bei Netzwerkproblemen o.ä..
n=0;
while [ $n -lt 6 ] ; do
   /usr/local/bin/sbfspot.3/SBFspot -nocsv -nosql -finq -v -cfg/usr/local/bin/sbfspot.3/SBFspot.PV.cfg > /tmp/SMA
   echo "-1*$(grep ETotal /tmp/SMA | sed 's/.*: *//' | sed 's/kW.*//')*1000" | bc | sed 's/\..*//' > /var/www/html/openWB/ramdisk/pvewhsbf;
   echo "-1*$(grep "Total Pac" /tmp/SMA | sed 's/.*: *//' | sed 's/kW.*//')*1000" | bc | sed 's/\..*//' > /var/www/html/openWB/ramdisk/pvwattsbf;

   /usr/local/bin/sbfspot.3/SBFspot -nocsv -nosql -finq -v -cfg/usr/local/bin/sbfspot.3/SBFspot.Batt.cfg > /tmp/SMABatt
   echo "$(grep "Batt. Charging Status" /tmp/SMABatt | sed 's/.*: *//' | sed 's/%.*//')" > /var/www/html/openWB/ramdisk/speichersoc;
   echo "-1*$(grep "Total Pac" /tmp/SMABatt | sed 's/.*: *//' | sed 's/kW.*//')*1000" | bc | sed 's/\..*//' > /var/www/html/openWB/ramdisk/speicherleistung;

   rm /tmp/SMA /tmp/SMABatt;
   sleep 9; n=$(($n+1));
done
und schließlich mit crontab -e folgendes ergänzen:

Code: Alles auswählen

* * * * * /var/www/html/openWB/sbfspot.sh
Viele Grüße
Christian

Edit: das geht auch noch einfacher: Als Modul-Script (über regel.sh und loadvars.sh) spart man sich den Weg über cron:
/var/www/html/openWB/modules/wr_sbfspot/main.sh

chmeyer
Beiträge: 4
Registriert: Sa Nov 30, 2019 12:34 pm

Re: SMA Home Manager

Beitrag von chmeyer » So Dez 08, 2019 9:28 pm

Hallo zusammen,

nach etwas "herumspielen" sieht es mir im Moment nach gar nicht so ganz dramatisch viel Arbeit aus, ein Modul zu erstellen.

Dabei bin ich aber über ein paar Dinge gestolpert, die mir unklar sind. Die Referenz zum Erstellen von Modulen gibt es ja bei github. Klar, Sinn und Zweck der Module ist es "ein paar Variablen" in die ramdisk zu schreiben.

Auf der github-Seite steht wörtlich, ein Modul "besteht aus einem Shell script mit dem Namen main.sh. Sollten weitere Dateien benötigt werden liegen diese mit im Ordner".
Das stimmt ja z.B. für das "SMA-SunnyHomemanager" Modul smashm nicht so ganz. Hier ist noch ein systemd-Service mit an Bord, der ein Python-Script daemonisiert, das vorher via GIT heruntergeladen wird.
Mal abgesehen davon, das der SMA-EnergyMeter-Daemon gut funktioniert hätte ich eher vermutet, dass das Python-Programm im Modul-Ordner liegt und jedesmal von main.sh aufgerufen wird. Klar hat die Daemonisierung auch Vorteile, z.B. sind die Werte "sofort" da, da sie ja nur lokal ausgelesen werden müssen.
Aktuell läuft die Installation der Dependencies und die GIT-"Magie" über den UI-Button "SMA Support" unter Einstellungen - Misc.
Die Frage ist natürlich, ist das eine Ausnahme, ist das ein Vorbild oder soll das möglichst in dem Modul-Ordner untergebracht werden? Wie sollen Dependencies "korrekt" installiert werden?


Zum Anderen bin ich überfordert und verwirrt mit den Variablen, die die verschiedenen Module erheben, verarbeiten und speichern.
Gibt es irgendwo eine Auflistung, welches Modul welche Informationen liefern muss, sollte und/oder kann?
Die github Referenz gibt an, "Bei PV Modulen muss geschrieben werden: ... /var/www/html/openWB/ramdisk/pvwatt, /var/www/html/openWB/ramdisk/pvkwh"

Klar, alle vorhandenen Bezugsmodule schreiben in /var/www/html/openWB/ramdisk/wattbezug, teilweise bin ich bei meinen Experimenten aber auch über ganz andere Variablen gestolpert.
Bei einigen kann ich mir den Nutzen zwar vorstellen, weiss aber nicht, ob openWB diese systematisch weiterverarbeitet.
Natürlich haben verschiedene Hersteller verschiedene Messparameter und jeder Wert ist sicherlich auch für einen Teilaspekt nötig oder hilfreich.
Mir geht es mit dieser Frage aber NUR darum, was für openWB Sinn macht, sprich für das Laden von Elektrofahrzeugen, gerne PV geführt und mit einer "netten" (z.B. grafischen) Auswertung.
Alles was openWB verarbeiten kann und möchte ist dabei definitionsgemäß sinnvoll.
Zugegeben: Ich habe keine Ahnung von der Materie, aber mir scheint das bei ein paar Modulen ziemlich viel erhoben wird (eben das was technisch möglich ist).
Als Anfänger (oder zum Nachvollziehen) ist das unübersichtlich:

Bezugsmodule:
Klar braucht openWB /var/www/html/openWB/ramdisk/wattbezug. bezugkwh und einspeisungkwh mögen auch noch Sinn machen, aber wie ist das mit Schein- und Wirkleistung, Phasenverschiebung, Aufschlüsselung nach Phasen, ...? Folgendes habe ich gefunden:
- evuv1, evuv2, evuv3
- bezuga1, bezuga2, bezuga3
- bezugw1, bezugw2, bezugw3
- evupf1, evupf2, evupf3
- bezugwatt (was ist der Unterschied zu wattbezug?)
- pvwatt, pvkwh, pvkwhk (pv* -> vielleicht bei PV-Insellösungen?)
- evuhz
- lla1, lla2, lla3
- llas11, llas12, llas13


Bei den Speichern ist es etwas übersichtlicher, hier ist
/var/www/html/openWB/ramdisk/speichersoc und /var/www/html/openWB/ramdisk/speicherleistung sicherlich sinnvoll und "Pflicht", es findet sich aber auch
pvwatt, speicherikwh, speicherekwh
pvwatt hätte ich eher bei den PV-Wechselrichtern gesucht, die beiden anderen Werte sind sicherlich für eine Speicher-Auswertung gut, aber für openWB?


Auch die Wechselrichter-Module liefern unterschiedliche Informationen:
Klar ist:
/var/www/html/openWB/ramdisk/pvwatt
/var/www/html/openWB/ramdisk/pvkwh

Aber was ist mit:
- pva1, pva2, pva3
/var/www/html/openWB/ramdisk/pvkwhk
/var/www/html/openWB/ramdisk/daily_pvkwhk
/var/www/html/openWB/ramdisk/yearly_pvkwhk
/var/www/html/openWB/ramdisk/monthly_pvkwhk

Wenn es eine Archivfunktion gibt, dann sollte diese openWB zur Verfügung stellen und nicht die einzelnen Module.

Oder ist es so, dass jedes Modul die Informationen liefert, die der jeweilige Programmierer für sinnvoll hält, egal was openWB damit macht?

Mir fehlt ein wenig die Orientierung und der Blick für's "große Ganze".
"Eigentlich" habe ich nicht vor, ein Modul für openWB zu entwickeln (fehlende Kenntnisse in PHP, Perl, Python, ...). Falls ich aber mal etwas in dieser Richtung "herumspielen" möchte, ist es dann sinnvoller ein "SMA-Speedwire-Modul" für SMA-SHM, PV-WR und Speicher-WR gemeinsam "all-in-one" (wegen gemeinsamem Code, z.B. der "Speedwire-Discovery", anschließend eine selbst gebaute "Speedwire Autokonfiguration") ins Auge zu fassen oder (wie in openWB erkennbar) als drei separate Module?
Ist es sinnvoll/okay weitere systemd-Dienste zu "kreieren"? Schöner abzufragen, für mein Empfinden aber "böse".
Wie können Perl/Python-Abhängigkeiten sichergestellt werden?
Sind externe GIT-Repositories (wie bei smaemd) erwünscht? ("böse"?)
Oder ist es okay, wenn zusätzliche Programme (SBFspot) einfach als Binary im Modul-Ordner liegen? (auch "böse")
Oder sollten sie aus dem Sourcecode gebaut werden? Wie? (Build-Dependencies, aufwendig)

Am liebsten würde ich statt dessen den 76_SMAInverter.pm von FHEM umbauen und auch Code von FHEM-SMA-Speedwire verwenden.

Natürlich könnte man dann auch gleich die "FHEM Werte an openWB übergeben"
aber ohne den Umweg über FHEM wäre es schöner: Einfacher Anwendungsfall (openWB) - einfache Lösung.

Viele Grüße
Christian

KevinW
Site Admin
Beiträge: 1373
Registriert: So Okt 07, 2018 1:50 pm

Re: SMA Home Manager

Beitrag von KevinW » Mo Dez 09, 2019 7:41 am

Auf der github-Seite steht wörtlich, ein Modul "besteht aus einem Shell script mit dem Namen main.sh. Sollten weitere Dateien benötigt werden liegen diese mit im Ordner".
Das stimmt ja z.B. für das "SMA-SunnyHomemanager" Modul smashm nicht so ganz. Hier ist noch ein systemd-Service mit an Bord, der ein Python-Script daemonisiert, das vorher via GIT heruntergeladen wird.
Mal abgesehen davon, das der SMA-EnergyMeter-Daemon gut funktioniert hätte ich eher vermutet, dass das Python-Programm im Modul-Ordner liegt und jedesmal von main.sh aufgerufen wird. Klar hat die Daemonisierung auch Vorteile, z.B. sind die Werte "sofort" da, da sie ja nur lokal ausgelesen werden müssen.
Aktuell läuft die Installation der Dependencies und die GIT-"Magie" über den UI-Button "SMA Support" unter Einstellungen - Misc.
Die Frage ist natürlich, ist das eine Ausnahme, ist das ein Vorbild oder soll das möglichst in dem Modul-Ordner untergebracht werden? Wie sollen Dependencies "korrekt" installiert werden?
SMA ist hier die Ausnahme.
Der Daemon ist hier nötig da die Werte per Multicast kommen.
Heißt erst lauschen wenn die Werte benötigt werden würde bei jedem Regeldurchlauf Sekunden an Zeit kosten.
Davon ab tut das Tool gut, deshalb lag es nahe dies zu nutzen.
Bezugsmodule:
Klar braucht openWB /var/www/html/openWB/ramdisk/wattbezug. bezugkwh und einspeisungkwh mögen auch noch Sinn machen, aber wie ist das mit Schein- und Wirkleistung, Phasenverschiebung, Aufschlüsselung nach Phasen, ...? Folgendes habe ich gefunden:
- evuv1, evuv2, evuv3
- bezuga1, bezuga2, bezuga3
- bezugw1, bezugw2, bezugw3
- evupf1, evupf2, evupf3
- bezugwatt (was ist der Unterschied zu wattbezug?)
- pvwatt, pvkwh, pvkwhk (pv* -> vielleicht bei PV-Insellösungen?)
- evuhz
- lla1, lla2, lla3
- llas11, llas12, llas13
Für das Bezugsmodul als Vorlage:
https://github.com/snaptec/openWB/blob/ ... dmpm3pm.py
pf = power factor, hz = frequent, Einspeisung/bezug = in WattStunden, bezuga = Ampere je Phase, bezugw = Watt je phase, evuv = Spannung

Bei den Speichern ist es etwas übersichtlicher,
speicheri bzw e sind geladene (Import) / entladene (export) Wh als Zählerstand für das Losging.
Auch die Wechselrichter-Module liefern unterschiedliche Informationen:
Klar ist:
/var/www/html/openWB/ramdisk/pvwatt
/var/www/html/openWB/ramdisk/pvkwh
Das sind die nötigen. pvkwhk wird bald verschwinden, reiner UI Wert der nicht mehr benötigt wird.
Oder ist es so, dass jedes Modul die Informationen liefert, die der jeweilige Programmierer für sinnvoll hält, egal was openWB damit macht?
Nicht alles wird verwertet. Das wichtige s.o. der Rest ist optional, z.B. für die Status Seite. Wird aber nicht gespeichert.
Falls ich aber mal etwas in dieser Richtung "herumspielen" möchte, ist es dann sinnvoller ein "SMA-Speedwire-Modul" für SMA-SHM, PV-WR und Speicher-WR gemeinsam "all-in-one" (wegen gemeinsamem Code, z.B. der "Speedwire-Discovery", anschließend eine selbst gebaute "Speedwire Autokonfiguration") ins Auge zu fassen oder (wie in openWB erkennbar) als drei separate Module?
Einzelne Module sind der richtige Weg. Bedenke das immer Kombinationen möglich sind.
SMA SHM, SMA WR, LG Speicher... usw..
Ist es sinnvoll/okay weitere systemd-Dienste zu "kreieren"? Schöner abzufragen, für mein Empfinden aber "böse".
Ungern wenn nicht unbedingt nötig.
Wie können Perl/Python-Abhängigkeiten sichergestellt werden?
Abfrage durch runs/atreboot.sh
Das wichtigste sollte aber schon alles an Board sein.
Sind externe GIT-Repositories (wie bei smaemd) erwünscht? ("böse"?)
Ungern, hat in der Vergangenheit durch Updates (bei smaemd ändern der Var Namen) schon zu Problemen geführt.
Oder ist es okay, wenn zusätzliche Programme (SBFspot) einfach als Binary im Modul-Ordner liegen? (auch "böse")
Das, als fixe Version, ist mir lieber. Lizenzbestimmungen beachten!

Antworten