Speedwire STP8.0SE (SUNNY TRIPOWER 8.0 SE)

[littleyoda]

          I'm not sure wether this is the correct issue to report this on, but I tried to connect my STP8.0SE (SUNNY TRIPOWER 8.0 SE) using the speedwire protocol integration and it yields the following error:

Logger: homeassistant.config_entries
Source: config_entries.py:635
First occurred: 8:57:25 AM (1 occurrences)
Last logged: 8:57:25 AM

Error setting up entry STP8.0SE (SUNNY TRIPOWER 8.0 SE) (sw3015639757) for pysmaplus
Traceback (most recent call last):
  File "/usr/src/homeassistant/homeassistant/config_entries.py", line 635, in __async_setup_with_context
    result = await component.async_setup_entry(hass, self)
             ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
  File "/config/custom_components/pysmaplus/__init__.py", line 95, in async_setup_entry
    sma = await getPysmaInstance(hass, entry.data)
          ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
  File "/config/custom_components/pysmaplus/__init__.py", line 88, in getPysmaInstance
    await sma.new_session()
  File "/usr/local/lib/python3.12/site-packages/pysmaplus/device_speedwire.py", line 434, in new_session
    raise SmaConnectionException(
pysmaplus.exceptions.SmaConnectionException: No connection to device: sma-inverter.fritz.box:9522  (3/3)

Afaik the port 9522 is used for the discovery of the Speedwire protocol and I wonder why it is used directly?
According to https://cdn.sma.de/fileadmin/content/www.developer.sma.de/docs/SpeedwireDD-TI-en-10.pdf?v=1699275967 it should be used on the multicast address?

Do let me know if you need additional information.

Originally posted by @joshiste in #18 (comment)

[littleyoda]

Speedwire communication runs via port 9522. This includes both discovery as multicast and ‘normal’ queries via simple UDP packets.

There can be many causes:

• What does the discovery mode return?
• You could try the IP address instead of the host name?
• Do you have access to the switcher with the Sunnyexplorer (https://www.sma.de/produkte/monitoring-control/sunny-explorer)?

[joshiste]

> What does the discovery mode return?

From the log:

{"discovery": [{"addr": "192.168.179.67", "port": 9522, "identify": [{"access": "ennexos", "status": "found", "tested_endpoints": "https://192.168.179.67/api/v1/system/info", "exception": "None", "remark": "https", "device": "Unknown: 19136"}, {"access": "speedwireinv", "status": "failed", "tested_endpoints": "192.168.179.67:9522", "exception": "No connection to device: 192.168.179.67:9522 (3/3)", "remark": "", "device": ""}, {"access": "webconnect", "status": "failed", "tested_endpoints": "https://192.168.179.67", "exception": "", "remark": "https://192.168.179.67", "device": ""}, {"access": "webconnect", "status": "failed", "tested_endpoints": "http://192.168.179.67", "exception": "", "remark": "http://192.168.179.67", "device": ""}, {"access": "speedwireem", "status": "failed", "tested_endpoints": "192.168.179.67", "exception": "None", "remark": "no multicast packet received.", "device": ""}, {"access": "shm2", "status": "failed", "tested_endpoints": "192.168.179.67", "exception": "Could not connect to 192.168.179.67:502", "remark": "needs Installer Grid Guard Code. Usage not recommended.", "device": ""}]}, {"addr": "192.168.179.38", "port": 9522, "identify": [{"access": "speedwireem", "status": "found", "tested_endpoints": "192.168.179.38:53369", "exception": "None", "remark": "", "device": "Sunny Home Manager 2 (3017708591)"}, {"access": "ennexos", "status": "failed", "tested_endpoints": "https://192.168.179.38/api/v1/system/info", "exception": "Could not connect to SMA at https://192.168.179.38 -- Cannot connect to host 192.168.179.38:443 ssl:default [Connect call failed ('192.168.179.38', 443)]", "remark": "https", "device": ""}, {"access": "ennexos", "status": "failed", "tested_endpoints": "http://192.168.179.38/api/v1/system/info", "exception": "None", "remark": "http", "device": ""}, {"access": "speedwireinv", "status": "failed", "tested_endpoints": "192.168.179.38:9522", "exception": "No connection to device: 192.168.179.38:9522 (3/3)", "remark": "", "device": ""}, {"access": "webconnect", "status": "failed", "tested_endpoints": "https://192.168.179.38", "exception": "Could not connect to SMA at https://192.168.179.38: Cannot connect to host 192.168.179.38:443 ssl:default [Connect call failed ('192.168.179.38', 443)]", "remark": "https://192.168.179.38", "device": ""}, {"access": "webconnect", "status": "failed", "tested_endpoints": "http://192.168.179.38", "exception": "Server at http://192.168.179.38 disconnected 3 times.", "remark": "http://192.168.179.38", "device": ""}, {"access": "shm2", "status": "failed", "tested_endpoints": "192.168.179.38", "exception": "Could not connect to 192.168.179.38:502", "remark": "needs Installer Grid Guard Code. Usage not recommended.", "device": ""}]}, {"addr": "192.168.179.69", "port": 9522, "identify": [{"access": "ennexos", "status": "failed", "tested_endpoints": "https://192.168.179.69/api/v1/system/info", "exception": "None", "remark": "https", "device": ""}, {"access": "ennexos", "status": "failed", "tested_endpoints": "http://192.168.179.69/api/v1/system/info", "exception": "None", "remark": "http", "device": ""}, {"access": "speedwireinv", "status": "failed", "tested_endpoints": "192.168.179.69:9522", "exception": "No connection to device: 192.168.179.69:9522 (3/3)", "remark": "", "device": ""}, {"access": "webconnect", "status": "failed", "tested_endpoints": "https://192.168.179.69", "exception": "", "remark": "https://192.168.179.69", "device": ""}, {"access": "webconnect", "status": "failed", "tested_endpoints": "http://192.168.179.69", "exception": "", "remark": "http://192.168.179.69", "device": ""}, {"access": "speedwireem", "status": "failed", "tested_endpoints": "192.168.179.69", "exception": "None", "remark": "no multicast packet received.", "device": ""}, {"access": "shm2", "status": "failed", "tested_endpoints": "192.168.179.69", "exception": "Could not connect to 192.168.179.69:502", "remark": "needs Installer Grid Guard Code. Usage not recommended.", "device": ""}]}], "status": {}}

> You could try the IP address instead of the host name?

Same result:

Error setting up entry STP8.0SE (SUNNY TRIPOWER 8.0 SE) (sw3015639757) for pysmaplus
Traceback (most recent call last):
  File "/usr/src/homeassistant/homeassistant/config_entries.py", line 635, in __async_setup_with_context
    result = await component.async_setup_entry(hass, self)
             ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
  File "/config/custom_components/pysmaplus/__init__.py", line 95, in async_setup_entry
    sma = await getPysmaInstance(hass, entry.data)
          ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
  File "/config/custom_components/pysmaplus/__init__.py", line 88, in getPysmaInstance
    await sma.new_session()
  File "/usr/local/lib/python3.12/site-packages/pysmaplus/device_speedwire.py", line 434, in new_session
    raise SmaConnectionException(
pysmaplus.exceptions.SmaConnectionException: No connection to device: 192.168.179.69:9522  (3/3)

Tried multiple times. Some times got "invalid host/ip address" when configuring

> Do you have access to the switcher with the Sunnyexplorer (https://www.sma.de/produkte/monitoring-control/sunny-explorer)?

Mac OS user here ... can't try.

But when I test using the littleyoda/pysma/example.py

It gives me (4 of 5 times):

$ ./example.py speedwire installer ******** sma-inverter
   ERROR:                       __main__:  Unable to connect to device at sma-inverter

But also (1 out of 5 times)

$ ./example.py speedwire installer ******** sma-inverter
Library version: unknown
               id               3015639757
           serial               3015639757
             nameSTP8.0SE (SUNNY TRIPOWER 8.0 SE)
             type         Hybrid Inverters
     manufacturer                      SMA
       sw_version                 3.5.26.R
=====================================================================================
Device-ID: 3015639757
           inverter_class           8009  Hybrid Inverters 
            inverter_type          19050  STP8.0SE (SUNNY TRIPOWER 8.0 SE) 
                    total         21.128 kWh  
                    today            744 Wh  
       pvEnergyProduction         44.971 kWh  
           spot_dc_power1            548 W  
           spot_dc_power2            344 W  
                 pv_power            837 W  
               grid_power            532 W  
             ChargeStatus              3 %  
         spot_dc_voltage1          402.9 V  
         spot_dc_voltage2         275.69 V  
         spot_dc_current1           1.36 A  
         spot_dc_current2          1.247 A  
              batteryTemp            4.0 °C  
        battery_voltage_a          313.9 V  
        battery_current_a         -0.856 A  
       BatteryInfo_Charge            305 W  
    BatteryInfo_DisCharge              0 W  
     BatteryInfo_Capacity            100 %  
        EM3 BatteryInfo_4           7700 Wh  
           grid_frequency          50.02 Hz  
          GridRelayStatus             51  Closed 
        BackupRelayStatus            311  Open 
          OperatingStatus            235  235 
   GeneralOperatingStatus            569  activated 
          inverter_status            307  OK 
          SpotBatteryLoad         13.834 kWh  
        SpotBatteryUnLoad         11.047 kWh  
              meter_yield          0.334 kWh  
EM1_1 Identifier.metering_total_absorbed        257.882 kWh  
EM3 Identifier.metering_power_supplied              0 W  
EM3 Identifier.metering_power_absorbed              2 W  
     active_power_feed_l1            125 W  
     active_power_feed_l2              0 W  
     active_power_feed_l3            145 W  
     active_power_draw_l1              0 W  
     active_power_draw_l2            273 W  
     active_power_draw_l3              0 W  
             Insulation_1             28 mA  
             Insulation_2         1668.0 kOhm  
                 Firmware       3.5.26.R   
           spot_ac_power1            178 W  
           spot_ac_power2            178 W  
           spot_ac_power3            177 W  
         spot_ac_voltage1          238.3 V  
            ac_voltage_l1          237.7 V  
            ac_voltage_l2          238.8 V  
            ac_current_l1          0.746 A  
            ac_current_l2          0.748 A  
            ac_current_l3          0.741 A  
---------------------------------------------------------------------------

[joshiste]

So I've played around a bit with the example.py here are some findings:

using --count 5
When the first one is successful all subsequent are also successful

running example.py in a loop (no delay)
First one is successful, subsequent calls failing

running example.py in a loop (30s delay between)
All successfull

conclusion
I've also looked at the debug output, and it occurs to me that the problem is foremost the login call.
If login is successful, all subsequent calls are too.
As with a delay of 30s between the script invocations, it is also fine. So could it be that there is a security mechanism in the inverter that rate limits the login calls?

[littleyoda]

I'm not sure about your conclusion.

However, I have reduced the number of login packages to a minimum as a test.

Can you test the example.py again with the latest GIt version?

[joshiste]

The behavior is still the same.

Reducing the unneeded login calls reduces overhead but doesn't change the behavior.
Because before the change: If the first login was successful, you store the serial. For subsequent logins this serial is not reset, so it doesn't matter if they fail. (There was always only a single Login rppsonse received message, so handle_login was just called a single time.

And imho therefore the --count 5 works (as the serial is not cleared) and looping the script doesn't.

[littleyoda]

Unfortunately, I don't understand what you're trying to tell me.

There was a significant change. The login command is now only sent once and not up to 4 times per loop.
I had surmised from your description that sending the login command multiple times could be a problem.

The script waits for a response for each command (including login). If there is no response, a timeout is thrown at some point. So I don't understand what you mean by saying that there were no responses.
I am open to suggestions on how to fix the problem.

[Wir können gerne auch in Deutsch weiter reden]

[joshiste]

There was a significant change. The login command is now only sent once and not up to 4 times per loop.
Yes. I second that. And I can confirm the login calls were reduced from 4 to 1.

The repetitive calls in the same example.py invocations were never really an issue; either all were successful or none.

The script waits for a response for each command (including login). If there is no response, a timeout is thrown at some point.

I got it. I was misreading the code. Also, I thought the serial number stored in the login would be used to authenticate subsequent requests, but it's simply the device's serial number.

So I don't understand what you mean by saying that there were no responses.

If I invoke the example.py a second time without delay, the handle_login is never called after sending the login. Thus, the device does not send a message with authentication failure. I guess this is some kind of brute-force protection?

I am open to suggestions on how to fix the problem.

Yeah, so right now I do think my assumption doesn't hold true, as it looks like the login does work differently then I've thought....

So I don't have any idea what the cause for the weird behavior is and hence no idea how to fix this.
But actually I've just hit the "reload" button for the device multiple times, it's now working. Maybe it's just the device behaving weird. So you may want to close the ticket...

[littleyoda]

Could you try something else?

With the command from below, pysma waits longer for a response from the inverter. I would like to rule out the possibility that the waiting time of 0.5 seconds is too short.

python3 example.py speedwire -ocommandTimeout=3 installer pwd 192.168.2.XX

[joshiste]

I've increased the timeout up to 10. Doesn't make a difference.

[littleyoda]

Can you please try with the latest version the following command?
python3 example.py speedwire -ologinRetries=10 installer pwd 192.168.2.XX

It increases the number of login attempts.

[joshiste]

Sorry for the late response.

Two findings:

1. it helped to set -ologinRetries=60. When invoking the example.py twice, the second iteration had a login success for retry for 50-60 succeeded. So you may want to introduce some delay between retries.

2. I first had to disable the device in Home Assistant, to be able to login at all. May be number of logins is restricted?

[littleyoda]

Just wanted to let you know that I haven't forgotten the bug.

But I still don't know how I'm going to implement it.

If it can only establish a connection after ~60 attempts, that would be 2 minutes that the user would have to wait when setting up, given a waiting time of 2 seconds.

[littleyoda]

Can you test the latest version (0.4.8.2)?

On the one hand, I changed something in the Speedwire implementation.
On the other hand, when you delete and add the device again to home assistant, you can set the number of connection attempts. In your case, you would have to play around with the values.

[joshiste]

I've had to hit the reload button three times to make it work.
From the log: