MadMax219 hat geschrieben: Di Dez 21, 2021 3:11 pm
@ALDI-Tuete
Kannst/Magst Du mal den Traffic des SMA-EM mitschneiden (wireshark) und anschauen oder mir zukommen lassen?
Order magst Du den Code einfach mal in die Richtung Len <> 58 anpassen und dann beim SMA-EM testen?
Ich besitze keinen SMA-EM.
Ok, ich versuche mal mein Glück mit wireshark - ist schon eine Zeitlang her...
MadMax219 hat geschrieben: Di Dez 21, 2021 3:11 pm
PS: Es gibt ja auch noch eine 3 Stelle, wo Pakete mit 608er Länge erwartet werden, da hab ich aber die Finger von gelassen.
Es gibt jedoch einen PR #1846 dazu (der ist aber nicht von mir).
Der PR 1846 ist von mir , ich habe deine Anpassung in "meinem" EnergyMeter-Modul direkt übernommen. Das werde ich zurücknehmen und später entsprechend anpassen.
2 x openWB Standard+ + SMA HM 2.0 + PV 8,8 kWp SMA WR + PV 5,3 kWp SMA WR + BYD HV 10.2 mit SMA SBS 3.7
Tesla Model Y LR
Becker hat geschrieben: Di Dez 21, 2021 10:39 pm
Du könntest mit NodeRed auch Mal ein Paket vom Energy Meter abfangen bzw. durch meinen Dekoder laufen lassen.
Würde mich interessieren.
Mit NodeRed habe ich mich erst aufgrund deines Beitrags mal beschäftigt
Inzwischen ist es installiert und der Flow wirft zumindest keine Fehler mehr - aber nutzen tue ich es noch nicht. Wie kann ich denn damit ein EM-Paket abfangen?
In der function wird ja alles kleiner 608 Byte verworfen - das kann ich natürlich abändern. Aber wie komme ich dann an die Ergebnisse/Daten?
2 x openWB Standard+ + SMA HM 2.0 + PV 8,8 kWp SMA WR + PV 5,3 kWp SMA WR + BYD HV 10.2 mit SMA SBS 3.7
Tesla Model Y LR
Becker hat geschrieben: Mi Dez 22, 2021 9:30 am
Du kannst einen Debug direkt an UDP Ausgang ("SMA EM") packen und schauen was da raus kommt jede Sekunde: download/file.php?id=9086&mode=view
Hast du denn Home Manager + Energy Meter bei dir?
Da wüsste ich nicht welche Gruppe + Port dann welches Gerät ist.
Ja, ich habe 1 x SHM2 und 2 x EM im Netzwerk. In jedem Datenpaket steckt die Seriennummer des Senders drin, darüber erfolgt die Unterscheidung.
Den Debug habe ich dran und aktiviert aber irgendwie startet da nichts, es scheint das der UDP Node nichts empfängt. Der Node "Objekt" beschwert sich auch entsprechend: msg : string[63] "Message missing msg.parts property - cannot join in 'auto' mode"
Muss ich da noch irgendwas aktivieren/starten? Sorry, mit NodeRed habe ich noch nichts gemacht...
Dateianhänge
2 x openWB Standard+ + SMA HM 2.0 + PV 8,8 kWp SMA WR + PV 5,3 kWp SMA WR + BYD HV 10.2 mit SMA SBS 3.7
Tesla Model Y LR
import base64
import socket
import struct
ipbind = '0.0.0.0'
MCAST_GRP = '239.12.255.254'
MCAST_PORT = 9522
sock = socket.socket(socket.AF_INET, socket.SOCK_DGRAM, socket.IPPROTO_UDP)
sock.setsockopt(socket.SOL_SOCKET, socket.SO_REUSEADDR, 1)
sock.bind(('', MCAST_PORT))
mreq = struct.pack("4s4s", socket.inet_aton(MCAST_GRP), socket.inet_aton(ipbind))
sock.setsockopt(socket.IPPROTO_IP, socket.IP_ADD_MEMBERSHIP, mreq)
def parse(packet: bytes):
packet_pos = 0
while packet_pos < len(packet):
channel, key, type, tarif = struct.unpack(">BBBB", packet[packet_pos : packet_pos + 4])
print(f"received: ({channel},{key},{type},{tarif})")
packet_pos += 4 + type
def chunkstring(string, length):
return (string[0+i:length+i] for i in range(0, len(string), length))
while True:
buffer = sock.recv(1024)
if buffer[0:4] == b"SMA\0":
print("-----")
for s in chunkstring(base64.b64encode(buffer).decode('utf-8'), 77):
print(s)
print(".....")
Und schon bekommt ihr am laufenden Band Datagramme an den Kopf geworfen. Da dann gerne mal das "zu kurze" Datagram rausfischen und hier posten. Dann können wir schauen was mit dem los ist.
Der "Fix" einfach Pakete mit weniger als 608 Bytes zu ignorieren sagt mich nicht so zu. Nicht nur weil mein Energy EM nur 600 Bytes produziert, sondern auch weil das für zukünftige Änderungen sehr anfällig sein könnte sich darauf zu verlassen.
Mein Problem mit Node-RED war vermutlich durch meine Docker-Installation / Port-Zuweisung verursacht.
Ich habe jetzt Node-RED nochmal auf einem separaten Raspberry installiert und nun empfange ich auch Datenpakete.
msg.payload : buffer[600] (wie vermutet vom Energy Meter)
[83,77,65,0,0,4,2,160,0,0,0,1,2,68,0,16,96,105,1,14,113,67,126,95,7,222,178,22,0,1,4,0,0,0,0,0,0,1,8,0,0,0,0,0,15,105,234,96,0,2,4,0,0,0,53,199,0,2,8,0,0,0,0,23,212,160,204,136,0,3,4,0,0,0,3,80,0,3,8,0,0,0,0,0,157,36,114,8,0,4,4,0,0,0,0,0,0,4,8,0,0,0,0,1,15,107,238,224,0,9,4,0,0,0,0,0,0,9,8,0,0,0,0,1,11,158,211,24,0,10,4,0,0,0,53,225,0,10,8,0,0,0,0,23,237,127,24,144,0,13,4,0,0,0,3,230,0,21,4,0,0,0,0,0,0,21,8,0,0,0,0,0,12,170,113,200,0,22,4,0,0,0,27,14,0,22,8,0,0,0,0,11,216,158,44,96,0,23,4,0,0,0,1,240,0,23,8,0,0,0,0,0,94,148,226,72,0,24,4,0,0,0,0,0,0,24,8,0,0,0,0,0,127,42,19,232,0,29,4,0,0,0,0,0,0,29,8,0,0,0,0,0,129,212,67,72,0,30,4,0,0,0,27,31,0,30,8,0,0,0,0,11,232,139,141,32,0,31,4,0,0,0,12,167,0,32,4,0,0,3,127,201,0,33,4,0,0,0,3,229,0,41,4,0,0,0,0,0,0,41,8,0,0,0,0,0,2,240,106,72,0,42,4,0,0,0,26,185,0,42,8,0,0,0,0,11,252,54,252,136,0,43,4,0,0,0,1,96,0,43,8,0,0,0,0,0,64,12,20,24,0,44,4,0,0,0,0,0,0,44,8,0,0,0,0,0,145,189,57,104,0,49,4,0,0,0,0,0,0,49,8,0,0,0,0,0,53,131,159,32,0,50,4,0,0,0,26,195,0,50,8,0,0,0,0,12,90,253,146,144,0,51,4,0,0,0,12,144,0,52,4,0,0,3,122,109,0,53,4,0,0,0,3,231,0,61,4,0,0,0,0,0,0,61,8,0,0,0,0,0,0,3,101,16,0,62,4,0,0,0,0,0,0,62,8,0,0,0,0,0,0,0,0,0,0,63,4,0,0,0,0,0,0,63,8,0,0,0,0,0]
2 x openWB Standard+ + SMA HM 2.0 + PV 8,8 kWp SMA WR + PV 5,3 kWp SMA WR + BYD HV 10.2 mit SMA SBS 3.7
Tesla Model Y LR
yankee hat geschrieben: Mi Dez 22, 2021 1:29 pm
Der "Fix" einfach Pakete mit weniger als 608 Bytes zu ignorieren sagt mich nicht so zu. Nicht nur weil mein Energy EM nur 600 Bytes produziert, sondern auch weil das für zukünftige Änderungen sehr anfällig sein könnte sich darauf zu verlassen.
Hab den fix nochmal umgebaut, so daß er ins Multicast-Paket schaut und die Protocol-ID abfragt.
Die ist beim SMA-SHM und SMA-EM 0x6069, bei den unerwünschten 58er Paketen jedoch 0x6065.
Dies entspricht auch der Doku von SMA.
ALDI-Tuete hat den SMA-EM-Teil verifiziert, ich habe den SMA-SHM-Teil getestet.
Weitere Tests sind gerne willkommen.