bohdan-s / SunGather

GNU General Public License v3.0
164 stars 68 forks source link

SG8.0RS Support #199

Open bullantmm opened 1 month ago

bullantmm commented 1 month ago

It seems that in order to get Sungather working consistently with an SG8.0RS registers-sungrow.yaml needs to be modified to remove modbus entries that cause errors on the inverter. The bad requests to restricted/non-existent modbus addresses were crashing my Winet adapter almost daily and it would come back at midnight (looks like logs were maxing out and causing the module to freeze).

Comment out the following lines in the registers-sungrow.yaml file: 1993-1996 (Modbus #6099 and #6199) 1999-2006 (Modbus #6399, #6499, #6599 and #6699) 2011-2012 (Modbus #12999) 2020-2021 (Modbus #13000)

It's outlined in another issue [https://github.com/bohdan-s/SunGather/issues/191] but also commented out all #last_reset_value_template: "{{ value_json.last_reset }}" lines in config.yaml

@bohdan-s not sure if you plan on any further development but it would be awesome if this could be included natively in a future build?

jpwise9 commented 1 month ago

I've had a similar issue with the Winet module crashing out. Suspecting it's an issue with the illegal register read requests much like yours.

From my experience - the http connection method 'was' fine - right up until Sungrow "helped" by upgrading the WiNet firmware for me when troubleshooting some other issues and broke the http method. From @bohdan-s 's comment on the discord, sounds like there is a fix pending for that. If you're using the modbus method - then there's a bunch of registers which are valid over http (general parameter request) in the web interface - but don't appear to be supported by Sungrow over modbus. WiNet Firmware: M_WiNet-S_V01_V01_A

For the SH6.0RS even when set to level 1 - the following are included in the register scan list and all result in decode errors. I've re-tagged them as level 9 on my config.yaml to remove them from processing and will find out tomorrow if the module remains stable or not. 5113 6100 6196 6290 6386 6469 6565 6648 6744 13003 - edit: this ones probably fine, may have been a transient error.

Also edit: it's been stable for almost a week, and I've since found out - there's a more up to date hybrid modbus register map (1.1.4 from memory) which gives a list of registers for which "WINET-S forwarding via Ethernet TCP/IP is not supported" - 6100 -> 6826 all fall into this range.

They'd be find using the HTTP interface once it's running again, but for pure modbus - they're not valid, so the read errors are consistent with that, although the module crashing after a while is still unexpected.

Thx Jarad.

petesmc commented 1 month ago

+1