Open littleyoda opened 4 days ago
littleyoda
commented
4 days ago Speedwire communication runs via port 9522. This includes both discovery as multicast and ‘normal’ queries via simple UDP packets.
There can be many causes:
joshiste
commented
4 days ago > 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-inverterBut 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
---------------------------------------------------------------------------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
commented
4 days ago 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
commented
4 days ago 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
commented
4 days ago 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
commented
4 days ago 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
commented
4 days ago 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
commented
4 days ago I've increased the timeout up to 10. Doesn't make a difference.
littleyoda
commented
3 days ago 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
commented
16 hours ago 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?
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 https://github.com/littleyoda/ha-pysmaplus/issues/18#issuecomment-2495392497