SMA Home Manager Firmware 2.07.5.R Peaks

[cars10wi]

Moin Moin, bisher lief das Script super und ermöglichte eine entspannte 0-Einspeisung. Seit dem Update des SHM auf die neue Firmware werden in unregelmäßigen Abständen komische Werte empfangen (SMA hat wohl ein neues Protokoll/Paket hinzugefügt). Dies sorgt für kurze Leistungswerte im MW-Bereich. Kann das Script ggf dahingehend angepasst werden, dass unrealistische Werte ignoriert werden? (siehe auch OpenWB-Forum https://openwb.de/forum/viewtopic.php?f=9&t=4215&start=10 )

[mitchese]

Hm do you have any details on what exactly is causing the peaks? I'll take a look when I get home of getting an update to the home manager and seeing if I can re-create this. It sounds like if it's getting MW-sized peaks, maybe a counter isn't properly calculating or transmitting.

Is it possible to get a traffic capture of the broadcasts from your meter? You can do this with

sudo tcpdump -w sma-meter.cap -ni <your-ethernet> host 239.12.255.254

Let it run for a while until a weird MW peak comes, then stop with ctrl+c.

[ricott]

I have observed the same but didn't realize it could be linked to a firmware upgrade. I attach a screenshot of how it looks like in VRM. I have an app for the Homey platform and see similarities there, something is changed and I get (due to my own logic I assume) zeros for all values when this broken(?)/different datagram is captured. I will see what I can find there

[ricott]

No more time to look at it now, but it is a different type of message. The first part is the same, so possible to extract the serial number (position 20, length 4)

Normal one 534d4100000402a000000001024c001060690174b32dd9353781c06e00010400000000a8000108000000001c5afe19080002040000000000000208000000000b36ded708000304000000000000030800000000059fdb8680000404000000104400040800000000057038d9780009040000001047000908000000001f0d15fa78000a040000000000000a08000000000c33131e08000d040000000028000e04000000c32e001504000000000a001508000000000992b7688000160400000000000016080000000003eb8ea9d80017040000000000001708000000000199aad9e000180400000004c1001808000000000210736740001d0400000004c1001d08000000000a7c98d088001e040000000000001e08000000000440a2b680001f04000000032000200400000388aa002104000000000800290400000000a500290800000000094c354710002a040000000000002a080000000003a353b4d8002b040000000000002b080000000001a59084f8002c04000000083c002c080000000002d027bcd00031040000000842003108000000000a9d5e6a08003204000000000000320800000000042132172800330400000004580034040000039721003504000000004e003d040000000000003d08000000000a0b411210003e040000000006003e080000000004372c1f88003f040000000000003f080000000002b7e5913800400400000003480040080000000000e6e31ef80045040000000000004508000000000af57a9388004604000000034800460800000000047dbd5d90004704000000028d00480400000392380049040000000007900000000207055200000000

New one that breaks the logic 534d4100000402a00000000100260010606509a0ffffffffffff0000740135d92db3000000000000b3ac00020000000000000000000000000000

[ricott]

You can ignore my previous message with the hex values. The "new" one is most likely from my SMA inverter. It is not the correct protocol version, should be 6069

[mitchese]

I've got this confirmed / recreated on my setup. There's an odd UDP broadcast called "Adwin config" which is messing it up

0000   ff ff ff ff ff ff 00 d0 93 45 57 ed 08 00 45 00  .........EW...E.
0010   00 32 13 4d 40 00 40 11 da 4b c0 a8 8c 7a ff ff  .2.M@.@..K...z..
0020   ff ff be c8 50 50 00 1e d3 8c ff ff ff ff ff ff  ....PP..........
0030   45 44 49 4d 41 58 00 00 00 00 00 00 00 a1 ff 5e  EDIMAX.........^

It should be easy to integrate a fix, as this doesn't start with SMA (0x534d41) as the regular meter updates do

Edit (+1h later), this Adwin thing is only part of the story. The Adwin packet is actually a broadcast and not actually caught by our listener. However after an Adwin packet, sometimes this weird one comes through as found by @ricott. Below is a capture around where it breaks, green are valid, blue is the ignored AdWin broadcast, and red is the one which breaks

[ricott]

I assume you have the sma energy meter protocol spec already, thinking of this one. On page 6, I added to my Homey SMA app to filter also on the protocol version (offset 16), to make sure what I accept is an energy meter datagram. As it shows from my above comment with hex strings, other SMA products use the same multicast address and port - so we need to know it is an energy meter datagram - the others we should ignore.

[ricott]

Seems to work like charm 👍