OK, kann die3 Aussage von atweb bestätigen, sobald die direkte Kommunikation deaktiviert wurde ist direkt die Anzeige wieder wie es sein soll.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
GELÖST: Frage an Nutzer eines SMA SHM2.0 - keine Kommunikation nach Update
Re: Frage an Nutzer eines SMA SHM2.0 - keine Kommunikation nach Update
Re: Frage an Nutzer eines SMA SHM2.0 - keine Kommunikation nach Update
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.
"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.
-
- Beiträge: 693
- Registriert: Do Feb 20, 2020 1:16 pm
- Has thanked: 2 times
- Been thanked: 9 times
Re: Frage an Nutzer eines SMA SHM2.0 - keine Kommunikation nach Update
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...
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...
Gruß,
Jürgen
Jürgen
- Sonnenjunky
- Beiträge: 366
- Registriert: Fr Jun 26, 2020 9:27 am
- Wohnort: Wien Umgebung
- Has thanked: 1 time
Re: Frage an Nutzer eines SMA SHM2.0 - keine Kommunikation nach Update
Ganz einfachDie 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.
BROADCAST = Nachricht an ALLE
MULTICAST = Nachricht an eine bestimmte Gruppe
UNICAST = Nachricht von einem sender an EINEN Empfänger
Re: Frage an Nutzer eines SMA SHM2.0 - keine Kommunikation nach Update
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)
Von Node-Red geht´s dann per MQTT in openWB. (flow siehe Wissensammlung)
openWB series2 Buchse (2021)
go-eCharger HOME+ 22 kW (2022)
go-eCharger HOME+ 22 kW (2022)
Re: Frage an Nutzer eines SMA SHM2.0 - keine Kommunikation nach Update
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.
.
.
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.
.
.
60 kwp:
67x Aleo S18 220 an SMA STP15
12x Aleo X63 305 + 16x Canadian 370 an SMA STP10
147x Aleo S18 220/230/255 an SMA STP15, SB5000, 2x SB4000
1x SMA SBS5.0 mit 2x BYD HVM13.8
2x MyPV AC Thor9s
1x openWB Duo
1x Skoda Citigo iV
1x Skoda Enyaq Coupe RS iV
67x Aleo S18 220 an SMA STP15
12x Aleo X63 305 + 16x Canadian 370 an SMA STP10
147x Aleo S18 220/230/255 an SMA STP15, SB5000, 2x SB4000
1x SMA SBS5.0 mit 2x BYD HVM13.8
2x MyPV AC Thor9s
1x openWB Duo
1x Skoda Citigo iV
1x Skoda Enyaq Coupe RS iV
Re: GELÖST: Frage an Nutzer eines SMA SHM2.0 - keine Kommunikation nach Update
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
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
60 kwp:
67x Aleo S18 220 an SMA STP15
12x Aleo X63 305 + 16x Canadian 370 an SMA STP10
147x Aleo S18 220/230/255 an SMA STP15, SB5000, 2x SB4000
1x SMA SBS5.0 mit 2x BYD HVM13.8
2x MyPV AC Thor9s
1x openWB Duo
1x Skoda Citigo iV
1x Skoda Enyaq Coupe RS iV
67x Aleo S18 220 an SMA STP15
12x Aleo X63 305 + 16x Canadian 370 an SMA STP10
147x Aleo S18 220/230/255 an SMA STP15, SB5000, 2x SB4000
1x SMA SBS5.0 mit 2x BYD HVM13.8
2x MyPV AC Thor9s
1x openWB Duo
1x Skoda Citigo iV
1x Skoda Enyaq Coupe RS iV
- Sonnenjunky
- Beiträge: 366
- Registriert: Fr Jun 26, 2020 9:27 am
- Wohnort: Wien Umgebung
- Has thanked: 1 time
Re: GELÖST: Frage an Nutzer eines SMA SHM2.0 - keine Kommunikation nach Update
ist doch eine freundliche und offensichtlich aussagekräftige Antwort.
da gibt´s wenig zu meckern.
da gibt´s wenig zu meckern.
Re: GELÖST: Frage an Nutzer eines SMA SHM2.0 - keine Kommunikation nach Update
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.
Und wie sich die Offsets zum HM unterscheiden ? Also alles anders oder nur verschoben.
openWB series2 Buchse (2021)
go-eCharger HOME+ 22 kW (2022)
go-eCharger HOME+ 22 kW (2022)
Re: GELÖST: Frage an Nutzer eines SMA SHM2.0 - keine Kommunikation nach Update
Aktuell ist die 2.0.18.R
60 kwp:
67x Aleo S18 220 an SMA STP15
12x Aleo X63 305 + 16x Canadian 370 an SMA STP10
147x Aleo S18 220/230/255 an SMA STP15, SB5000, 2x SB4000
1x SMA SBS5.0 mit 2x BYD HVM13.8
2x MyPV AC Thor9s
1x openWB Duo
1x Skoda Citigo iV
1x Skoda Enyaq Coupe RS iV
67x Aleo S18 220 an SMA STP15
12x Aleo X63 305 + 16x Canadian 370 an SMA STP10
147x Aleo S18 220/230/255 an SMA STP15, SB5000, 2x SB4000
1x SMA SBS5.0 mit 2x BYD HVM13.8
2x MyPV AC Thor9s
1x openWB Duo
1x Skoda Citigo iV
1x Skoda Enyaq Coupe RS iV