openWB Forum

atweb hat geschrieben: ↑Mi Jan 26, 2022 8:24 am Ausm photovoltaikforum hab ich diese Info:


Wer die "Direkte Zähler Kommunikation" (=Unicast) eingestellt hat, um evtl. IGMP-Problematiken im eigenen Netz zu umgehen, der erhält seit dem Update vom SHM 2.0 Datagramme mit der Länge von 608 Bytes (=identischer Aufbau zu den Multicast-Datagrammen) anstelle von wie bislang 610 Byte. Das Parsing muss also angepasst werden bzw. erfordert es keine Unterscheidung mehr zwischen Multicast- und Unicast-Datagrammen.


Wäre natürlich schick gewesen von SMA, das auch kundzutun,

https://www.photovoltaikforum.com/threa ... ost2481917

OK, kann die3 Aussage von atweb bestätigen, sobald die direkte Kommunikation deaktiviert wurde ist direkt die Anzeige wieder wie es sein soll.

Hier noch ne Info aus dem PV Forum. Da SMA ja wie so oft eine überragende Dokumentation *kotz* seiner Änderungen preisgibt hat ein User mal die Änderung beschrieben:

"Auch die Zählerkommunikation basiert auf Speedwire."

"Das bestreitet niemand, hat aber mit dem Problem nichts zu tun. Oder ist in der Speedwire-Doku beschrieben, welches Zählerprotokoll (Protocol-ID) in welchem Fall verwendet wird?

Die Information, die seitens SMA bzgl. des Zählerprotokolls fehlt, ist:

SHM 2.0 FW 2.07.xxx

- Multicast: Protocol-ID 0x6069 "Energy Meter Protocol" 608 Byte Datagramm

- Unicast (="Direkte Zählerkommunikation"): Protocol-ID 0x6081 "Extended Energy Meter Protocol" 610 Byte Datagramm

SHM 2.0 FW 2.08.5R

- Multicast UND Unicast (="Direkte Zählerkommunikation"): Protocol-ID 0x6069 "Energy Meter Protocol" 608 Byte Datagramm

----
Ich hoffe mal die Info stimmt. Als Laie kann ich es nicht prüfen.

Die Frage die sich mir aber stellt. OpenWB greift doch den Multicaststream und seine Daten ab. Wieso verschluckt sich die WB nur weil ein zusätzliches Unicast Datagramm im Netzwerk auftaucht.

Klingt alles schlüssig.
Aber soweit ich das verstehe kommt da kein Unicast Paket zusätzlich, sondern es wurde die Größe der Pakete geändert. Evtl nutzen die betroffenen User also eben Unicast statt Multicast, denn bei vielen (wie auch bei mir) läuft es ja auch nach dem Update problemlos weiter.
Und bei den Betroffenen funktioniert ja teils selbst die Komunikation zwischen SMA Produkten nicht mehr...

Die Frage die sich mir aber stellt. OpenWB greift doch den Multicaststream und seine Daten ab. Wieso verschluckt sich die WB nur weil ein zusätzliches Unicast Datagramm im Netzwerk auftaucht.

Ganz einfach
BROADCAST = Nachricht an ALLE
MULTICAST = Nachricht an eine bestimmte Gruppe
UNICAST = Nachricht von einem sender an EINEN Empfänger

ich nutze Multicast und decodiere selber in Node-Red (mit festen Offsets) - alles ohne Probleme vor/nach dem Update.
Von Node-Red geht´s dann per MQTT in openWB. (flow siehe Wissensammlung)

Problem ist "gelöst" - siehe Foto / Anhang

Mit der neuen Software auf dem SMA SHM2.0 gibt es ein neues Konfigurationsfeld für Geräte, welche Zählerdaten neben Multicast auch noch direkt mit Unicast erhalten sollen. Das macht z.B. in Netzen mit VLANs/Routing durchaus Sinn, um hier nicht mit IGMP-Routing anfangen zu müssen.

Jedoch scheint (in gewissen Fällen?) der SMA SunnyBoy Storage ein Problem damit zu haben (bei mir mit Firmware 3.12.33.R). Warum? -> SMA fragen.

Nimmt man diese Einstellung raus (Felder "direkte Kommunikation" leer lassen = nur Multicast), funktionieren der SBS und auch die openWB wieder.

Dass die openWB auf die Nase fällt, wenn neben Multicast- auch Unicast-Pakete im Netz unterwegs sind, ist aber auch nicht sauber.
Das sollten sich die Entwickler mal anschauen.
.
.

und hier noch die Antwort von SMA:

Sehr geehrter Herr x,

die direkte Zählerkonfiguration sollte nur verwendet werden, wenn es Übertragungsstörungen der Zählerwerte im Netzwerk gibt. Die Option selbst kann, je nach Netzwerkkonfiguration und verwendeter Geräte, weitere Kommunikationsstörungen nach sich ziehen.
Die Länge des Datenstreams der Zählerwerte variiert je nach verwendetem Gerät und Firmwareversion. In älteren Versionen des Sunny Home Managers und auch beim Energy Meter konnte der Stream z.B. 600 Byte lang sein. Deshalb empfiehlt es sich nicht nach der Position im Stream zu filtern und dort den gewünschten Wert auszulesen, sondern nach den OBIS Kennzahlen (z.B. 1.8.0 und 2.8.0) zu suchen und den dazugehörigen Wert auszulesen.

Mit freundlichen grüßen,
Ihr SMA Service Team

ist doch eine freundliche und offensichtlich aussagekräftige Antwort.

da gibt´s wenig zu meckern.

Weiß Jemand welche Firmwareversion beim Energy Meter die aktuelle ist ? (EM20)

Und wie sich die Offsets zum HM unterscheiden ? Also alles anders oder nur verschoben.

Aktuell ist die 2.0.18.R