SMA Home Manager

[chmeyer]

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.

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]

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.

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]

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

[openWB]

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!

[chmeyer]

Danke für die Info.

Heute nur ein kurzes Update:
Im wesentlichen funktioniert "es" (SMA Speedwire "out of the box" statt Modbus mit vorheriger Aktivierung mit Installateurs-Passwort) bei mir.
Als "Modul" würde ich es (noch) nicht bezeichnen, höchstens "Alpha"-Status, deshalb poste ich es auch nicht.
Andererseits bin ich für's Erste zufrieden und mein Urlaub ist zu Ende. ... Falls also jemand Interesse hat (und selbst bzw. weiter-basteln möchte): Bitte um kurze Mail.

Bei den Speichern ist es etwas übersichtlicher,

speicheri bzw e sind geladene (Import) / entladene (export) Wh als Zählerstand für das Losging.

Streng genommen wird mit SBFspot nicht der Speicher selbst ausgelesen, sondern der zum Speicher gehörende SMA-Wechselrichter (bei mir: Sunny Island 6.0H).
Mit vier isolierten Dateien (also ohne git o.ä.) von SBFspot im speicher_sbfspot-Verzeichnis erhalte ich:
speicherleistung, speichersoc und speicherekwh. Noch nicht entdeckt habe ich speicherikwh.
SBFspot sollte unproblematisch sein, es steht unter der Lizenz:
Creative Commons - Attribution-NonCommercial-ShareAlike 3.0 Unported http://creativecommons.org/licenses/by-nc-sa/3.0/

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

Das sind die nötigen.

Auch diese Informationen bekomme ich mit SBFspot (s.o.).
Es geht aber auch einfacher (=kleinerer wr_speedwire-Ordner):
Mit einem kleinen (von mir angepassten) Python-Script (Quelle: https://gist.github.com/hdo/6027504) und ein paar Python-Abhängigkeiten sind die beiden Werte beim "Sunny Tripower" schon für unter 5 kB Python (statt 560 kB SBFspot) auszulesen.


Die SMA-Speedwire-Discovery liefert die IP-Adressen der Speedwire-Geräte. Inwieweit sich das "aufbohren" lässt, um auch die Geräteart (PV-WR bzw. Speicher-WR) zu ermitteln weiß ich nicht.
Quelle: https://www.sma.de/fileadmin/content/gl ... -de-10.pdf


Wie sich das Ganze (also: Speedwire-Discovery, wr_speedwire und speicher_sbfspot) dann aber automatisiert (mit der modulconfig.php) in die openwb.conf bringen lässt weiß ich auch (noch?) nicht.


Viele Grüße
Christian

[chmeyer]

Hallo zusammen,

nachdem mir mein "Hilf-Raspberry" (ohne Sicherung) abgeschmiert ist, habe ich wenigstens die Speedwire-Abfrage (wie gesagt: ohne Modbus!) für den SMA-Tripower PV-Wechselrichter in ein 4 kb kleines Python-Script gepackt, SBF-Spot ist somit nicht mehr nötig.
Für eine "Sunny Island"-Speedwire-Batterie-Abfrage hat es in Ermangelung von echtem Verstehen und aus Zeitgründen nicht gereicht.


Also, für alle Interessierten:
1. Python Abhängigkeiten installieren:

Code: Alles auswählen

sudo apt-get install python-twisted python-twisted-web

2. Die Datei /var/www/html/openWB/modules/wr_http/main.sh anpassen, hier nur die Änderungen
(ja und natürlich muss man dann dieses Modul auch auswählen):

Code: Alles auswählen

# Das geht auch noch eleganter. ;)
/var/www/html/openWB/modules/wr_http/wr_speedwire.py > /var/www/html/tmp/wr_speedwire
wattwr=$(grep pvwatt /var/www/html/tmp/wr_speedwire | cut -d\  -f2)
ekwh=$(grep total /var/www/html/tmp/wr_speedwire | cut -d\  -f2)
rm /var/www/html/tmp/wr_speedwire

3. Das eigentliche Python-Script /var/www/html/openWB/modules/wr_http/wr_speedwire.py:

Code: Alles auswählen

#!/usr/bin/python

# sudo apt-get install python-twisted python-twisted-web

# Für openWB zusammengehackt von chmeyer aus den Quellen von:
# https://gist.github.com/hdo/6027504
# https://github.com/mhop/fhem-mirror/blob/master/fhem/FHEM/76_SMAInverter.pm
# Inspirationen aus SBFSpot.cpp
# https://github.com/SBFspot/SBFspot/blob/master/SBFspot/SBFspot.cpp

import struct
import sys
import time
import json
from struct import *
from twisted.web import server, resource
from twisted.internet.protocol import DatagramProtocol
from twisted.internet import reactor
from twisted.application.internet import MulticastServer


user_pw = '0000' # default is '0000'

code_login = 0xfffd040d
code_total_today = 0x54000201
code_spot_ac_power = 0x51000201

src_serial = 987193143 # = 37 5F D7 3A (intel format, little endian)
dst_serial = 4294967295 # = ff ff ff ff = anySerial, Abgeschaut von SMASpot...

comm_port = 9522
comm_dst = '192.168.2.103'


def get_encoded_pw(password):
    # user=0x88, install=0xBB
    encpw=[0x88,0x88,0x88,0x88,0x88,0x88,0x88,0x88,0x88,0x88,0x88,0x88]
    for index in range(min(len(encpw), len(password))):
        encpw[index] = encpw[index] + ord(password[index])
        
    ret = ""
    for ch in encpw:
        ret = ret + hex(ch).replace('0x','')
    return ret

cmd_login = '534d4100000402a000000001003a001060650ea0ffffffffffff00017800%s00010000000004800c04fdff07000000840300004c20cb5100000000%s00000000' % (struct.pack('<I', src_serial).encode('hex'), get_encoded_pw(user_pw))
cmd_logout = '534d4100000402a00000000100220010606508a0ffffffffffff00037800%s000300000000d7840e01fdffffffffff00000000' % (struct.pack('<I', src_serial).encode('hex'))
cmd_query_total_today = '534d4100000402a00000000100260010606509e0b500%s00007800%s000000000000f1b10002005400002600ffff260000000000' % (struct.pack('<I', dst_serial).encode('hex'), struct.pack('<I', src_serial).encode('hex'))
cmd_query_spot_ac_power = '534d4100000402a00000000100260010606509e0b500%s00007800%s00000000000081f00002005100002600ffff260000000000' % (struct.pack('<I', dst_serial).encode('hex'), struct.pack('<I', src_serial).encode('hex'))


sma_data = {}

query_list = []
rea = 0

class MulticastClientUDP(DatagramProtocol):

   def datagramReceived(self, datagram, address):
      global sma_data, data_available
      data = datagram.encode('hex')

      code = get_code(datagram)      
      if code == code_login:

         send_command(cmd_query_total_today)
      if code == code_total_today:
         total = get_long_value_at(datagram, 62)
         today = get_long_value_at(datagram, 78)
         print "total: %d" % total
         print "today: %d" % today
         sma_data['total'] = total
         sma_data['today'] = today

         send_command(cmd_query_spot_ac_power)
      if code == code_spot_ac_power:
         pvwatt = get_long_value_at(datagram, 62)
         if pvwatt == 0x80000000:
            pvwatt = 0
         print "pvwatt: %d" % pvwatt
         sma_data['spotacpower'] = pvwatt

         reactor.stop()

def send_command(cmd):
   data = cmd.decode('hex')
   rea.write(data, (comm_dst, comm_port))
   
def get_code(data):
   c = unpack('I', data[42:46])
   return c[0]   

def get_long_value_at(data, index):
   v = unpack('I', data[index:index+4])
   return v[0]

def callfunc(x):
    reactor.stop()
    
rea = reactor.listenUDP(0, MulticastClientUDP())
_DelayedCallObj = reactor.callLater(5, callfunc, "callfunc called after 4 sec")
send_command(cmd_login)
reactor.run()

4. Für ein "richtiges Modul" sollte man natürlich noch zwei Variablen über das UI setzen können, für meine eigene Umgebung habe ich sie einfach im Python-Script festgelegt: IP-Adresse des PV-Wechselrichters und Speedwire-Benutzer-Passwort

Code: Alles auswählen

comm_dst = '192.168.2.123'
user_pw = '0000' # default is '0000'

Viel Spaß und Erfolg damit, viele Grüße
Christian

[sw1002]

Es handelt sich um ein reines Auslesen der Werte von SHM in Richtung OpenWB.

Der SHM "weiß" nichts von dem EV.

Mit dem Smart Appliance Enabler habe ich mich noch nicht beschäftigt.
Theoretisch spricht nichts gegen die parallel auf einem Raspberry laufen zu lassen.

Hallo hole den Post wieder hoch....
hat schon jemand Erfahrungen damit die OpenWB als Gerät im Sunnyportal anzeigen zu lassen über SHM 2.0?

Den SAE würde ich separat auf einen 2. raspi aufsetzen, ht das schon jemand gemacht?
@KevinW wäre das nicht ein prima Modul/Erweiterung für SHM?

[mrinas]

ich hab' zwar noch keine openWB sondern nur einen POC mit einem Raspberry während ich auf den Liefertermin für den e-2008 warte. Bei mir läuft SAE auf dem gleichen Raspberry und liefert fleißig fake-werte an SMA.

[Bubbagump]

Verstehe ich es richtig, dass der SAE in der Lage wäre den Verbrauch so an den SHM zu liefern, dass die wallbox dann als separat ausgewiesener Verbraucher angezeigt werden kann?
Das fände ich sehr interessant.

[mrinas]

ja das geht, hab' ich hier als POC mit simulierten Werten schon mal gemacht, hat gut geklappt. Hatte nur Probleme mit dem SAE da mein Raspberry zwei IPs hatte, da musste man die Bindings in einer Konfig-Datei anpassen. Findet sich zwischenzeitlich in der Doku zum SAE.