Error interacting via websockets

[filmackay]

On my inverter I am getting the following errors, when debugging SungrowMdbusWebClient in http mode. I have reduced it down to a websocat repro: (first JSON line is input to inverter, second line is output)

$ websocat ws://192.168.0.2:8082/ws/home/overview
{"lang": "en_us", "token": "**********", "service":"devicelist", "type": "0", "is_check_token": "0"}
{"result_code":401, "result_msg":"I18N_COMMON_INTER_ABNORMAL", "result_data":{"service":"devicelist"}}

I can't find any info on this error message - is this 401 error a HTTP status error standard, or something entirely different? Has anyone seen this before?

[kalaws]

Getting the same since I updated firmware in Winet-S module yesterday.

[bohdan-s]

Sorry guys. I know of this issue. trying to put some time to look into it. But busy personal life.

[kalaws]

Great, thanks for the excellent work!

[kalaws]

https://github.com/bohdan-s/SungrowModbusWebClient/compare/main...caliph9k:SungrowModbusWebClient:main

Is this the solution?

[kalaws]

@bohdan-s I have confirmed the issue is authentication, and the fork linked above resolves it. I suppose SunGather users would have to fill in credentials somewhere other than the .py file, though. Especially with HA installations.

[gemx]

Yep, can also confirm, that it's the login issue and solved by the fix

[kalaws]

It also seems that the service: connect call is redundant and/or can be substituted by service: login. But every service: login call registers a login event in the inverter log.

[danielHin]

main...caliph9k:SungrowModbusWebClient:main

Is this the solution?

I can confirm that this fixes the issue. I've tested with SH10.0RT-V112 + Winet-S and SH15T + Winet-S2

[filmackay]

Thanks for this - can someone explain what the comparison is between MODBUS and websocket?

MODBUS is polling - does anyone know how often new values are available? ie. are they changing on a constant cadence, and then it's up to you how often you poll?

Websocket - does anyone have a feel for how often new values are pushed to you in general? Can you control this at all? Do you get all values, or all requested values, pushed over a single connection?

It feels like Websocket could be way better for high-granularity data, but depends on implementation 🤷🏻

[bohdan-s]

From my testing websocket and modbus update the same time. None of the values are “instant” but I’m not sure how often they update. The web socket method actually just calls the modbus form in the dongles web interface. So all the values are mostly the same.

[filmackay]

Thanks @bohdan-s - what about other aspects: universal subscription (give me every register) is this easier on Websocket? Does the websocket operate on a perpetual push stream (updated when value changes) - unlike Modbus which is request-response?

Wasn't it hard to determine they update at the same time because of the push / request-response mismatch?

I'll try and do some testing to get a feel for how often the underlying data does update..

[bohdan-s]

So modbus method reads each register via modbus protocol. Web socket reads each register by logging into the web interface and using the modbus form to request the modbus registers. Both are modbus in the end. The websocket way just worked around a number of firmware versions where modbus did not work at all. As for the data. There should be no difference. Modbus method would be arguably better since it's not going through the extra websocket layer.

[filmackay]

I see - I was hoping that the websocket protocol would at least push new values to you, meaning you did not to continue to re-request everything on a regular cadence. Is the websocket protocol still request-response (effectively) just inside a bi-directional protocol?

[bohdan-s]

“My” implementation is using modbus stack. So it’s all polling. there are some community members using the websocket exposed by the dongle. But it’s not feature complete against the modbus.