search

wills106 / homeassistant-solax-modbus

SolaX Power Modbus custom_component for Home Assistant (Supports some AlphaESS, Growatt, Sofar, Solinteg, Solis, SRNE, Swatten)
317 stars 101 forks source link

[Bug]: "SolaX Inverter Battery Charge Upper SOC" can't be set by the Integration #1017

Open mobyline opened 2 months ago

mobyline commented 2 months ago

Describe the bug

"SolaX Inverter Battery Charge Upper SOC" can't be set by the SolaX Modbus Integration. After a few seconds it always falls back to the value set in the SolaX cloud app.

Integration Version

2024.08.12

Homeassistant core version

2024.8.3

Inverter brand

SolaX Power

Plugin used

plugin_solax.py

Serial prefix

H34A12

Inverter firmware versions

DSP v1.29 ARM v1.27

Connection Method

SolaX Pocket WiFi 3.0

Dongle firmware

3.008.10

Detailed Error Log

No response

Additional context

No response

olafseidel commented 2 months ago

I have the same problem. Wonder wether this is a problem from Solax or within Home Assistant. Would be nice to be able to change SolaX Battery Charge Upper SOC as it is positive for the health of the bettery to keep the SOC low over the lifetime (this is also true for LFP batteries).

olafseidel commented 2 months ago

Same Bug is described (but not solved) in https://github.com/wills106/homeassistant-solax-modbus/issues/713

mobyline commented 1 month ago

Yes, my intention is indeed building up a 'battery charging management flow'. Therefore I need to set 'SolaX Battery Charge Upper SOC' from HA (node-red).

johny-mnemonic commented 1 month ago

As a workaround, you can try setting number.solax_battery_charge_max_current to 0 when you want to stop battery charging.

MrJanD commented 1 month ago

As a workaround, you can try setting number.solax_battery_charge_max_current to 0 when you want to stop battery charging.

Yes, I know. But as described in https://homeassistant-solax-modbus.readthedocs.io/en/latest/automation-examples/ this comes with some drawbacks…

wills106 commented 1 month ago

Has anyone tried writing to this value when the Inverter is in "Unlocked - Advanced" instead of just the normal "Unlocked" ? Might need a higher level of access?

wills106 commented 1 month ago

@infradom has this ever worked on your Inverter?

Xoffroad commented 1 month ago

Has anyone tried writing to this value when the Inverter is in "Unlocked - Advanced" instead of just the normal "Unlocked" ? Might need a higher level of access?

Yes, my inverter is set to Advanced according to your integration. But I cannot change the value solax_battery_charge_upper_soc. If I change the value in the manufacturer app, the correct value is displayed in your integration.

johny-mnemonic commented 1 month ago

Yes, I know. But as described in https://homeassistant-solax-modbus.readthedocs.io/en/latest/automation-examples/ this comes with some drawbacks…

Yes. I am searching for a way how to stop charging using the PowerControl feature as described here, but so far I was unable to persuade the inverter to do so😞

I have moved almost all of my automations to Power Control, so setting this single parameter to EEPROM once a day at max should not cause significant wear🤞

steps56 commented 1 month ago

Some month ago I've asked SolaX/Qcells about Eeprom write Limits. They told me, its 1000000 (10x as stated by always just "assumed" values here)

I use a manual slider (see Screen at bottom) of number.solax_battery_discharge_max_current to cut battery draln by wallbox charging with Evcc via HA. Same could be used by an automation and number.solax_battery_charge_max_current with: If SOC is above 79%, set number.solax_battery_charge_max_current to fixed value 0 Second automation needed, to switch back to a save 10 or 15 A charge by setting number.solax_battery_charge_max_current to f. i. 15 A if SOC is reaching f. i. min. SOC. You decide at the 2. automation, which value may be your favorite min. SOC....50, 30, 20%... your choice. In automation set to: If min. SOC under 30% (example), set number.solax_battery_charge_max_current to 80%

This will write mostly no more as 2x a day, that's very safe to the Eeprom... if you don't use many other writing automations too 😉.

Screenshot_20240921_145322_Home Assistant

mobyline commented 1 month ago

As a workaround, you can try setting number.solax_battery_charge_max_current to 0 when you want to stop battery charging.

thx for the hint. Will give it a try.

mobyline commented 1 month ago

Has anyone tried writing to this value when the Inverter is in "Unlocked - Advanced" instead of just the normal "Unlocked" ? Might need a higher level of access?

Yes, but didn' work :(

DavidAntonin commented 1 month ago

I have the same problem with my Solax X3-Hybrid G4 inverter. Ulocked mode, when I change setting it is back to value set by cloud in few seconds

richie241 commented 1 month ago

same problem with 'upper SoC' on X3 Ultra. All other stuff works well :)

Henry1-github commented 4 weeks ago

I have the same problem with "Upper SOC". Please try to solve it. @PatrikTrestik

PatrikTrestik commented 4 weeks ago

I'll look on it. But I have only short time 13.10-22.10 for hobby work. If not solved by that time, please someone else look on it.

wills106 commented 4 weeks ago

I don't think it's an integration issue nor a firmware issue.

Either the docs are incorrect, but less likely as it's the same for Gen4 & Gen5. Or it's not the register we think we need, or it needs to be used in combination with another register / function.

viktorp75 commented 3 weeks ago

I was able to change the value of Battery Charge Upper SOC using local API through registry value 200. To set it to 0 for example you need to send following data to inverter, where $INV_SN is serial of your inverter.

'optType=setReg&pwd=$INV_SN&data={"num":1,"Data":[{"reg":200,"val":"0"}]}'

Perhaps it will help to fix the issue in the integration? If not then you can make that number selector using the restful integration instead.

PatrikTrestik commented 3 weeks ago

@viktorp75 this bug is for Modbus integration. All API rated stuff should be written to https://github.com/PatrikTrestik/homeassistant-solax-http

API has completely different mapping than Midbus.

johny-mnemonic commented 3 weeks ago

Did anyone try to report it as a bug to Solax? I remember in the past we had an issue with other variable on the Modbus and when I reported it to Solax I got reply, that it is known and fixed bug, which will be released in the next FW version. So in case this really doesn't look like an issue on the integration side, we can try it. Maybe no one reported this one yet.

viktorp75 commented 3 weeks ago

this bug is for Modbus integration. All API rated stuff should be written to https://github.com/PatrikTrestik/homeassistant-solax-http

API has completely different mapping than Midbus.

@PatrikTrestik I do understand, however I posted here so affected users can use it as a workaround before its fixed in Modbus. And also you know that it works somewhere else than cloud which would confirm that the issue is in the Modbus, perhaps vs. firmware. Btw. mine is DSP v1.43 ARM v1.42 and I have the same problem. I am not sure why you asked to report to your local api repo if it is not a bug?

steps56 commented 3 weeks ago

@viktorp75 this bug is for Modbus integration. All API rated stuff should be written to https://github.com/PatrikTrestik/homeassistant-solax-http

API has completely different mapping than Midbus.

Totally confusing and unlogic as your api http thing is about the SolaX Charger aka Wallbox and has nothing about SolaX System Battery SOC settings. What do you want to be asked, solved or whatever at your link, about max. SOC entity bug/not working regarding to yout Wallbox stuff ???

It's much more logic, like wills already asumed before...

steps56 commented 3 weeks ago

Did anyone try to report it as a bug to Solax? I remember in the past we had an issue with other variable on the Modbus and when I reported it to Solax I got reply, that it is known and fixed bug, which will be released in the next FW version. So in case this really doesn't look like an issue on the integration side, we can try it. Maybe no one reported this one yet.

Hmm, may be it's walking at thin ice... as I belive, SolaX has no real interest in its open modbus connection to be used widely by anybody and may perhaps close it in future 🤷🏼‍♂️. So I'm always one step to offline usage of everything (by just hitting one button in HA), if anything will be forced to unfree status or unwanted updates, implementing some "cut off" stuff.

I assume, its bug/error/wrong data in the modbus documentation, in conjunction by chained other entiies, like wills already assumed too.

insipiens commented 2 weeks ago

changing it works on my X4, I’m on a slightly older version of this integration but probably more relevant is I did have this issue a few months back, exactly as described…. so stopped changing it but now it works. Perhaps there is some limitation Solax have imposed as suggested above

steps56 commented 2 weeks ago

changing it works on my X4, I’m on a slightly older version of this integration but probably more relevant is I did have this issue a few months back, exactly as described…. so stopped changing it but now it works. Perhaps there is some limitation Solax have imposed as suggested above

Nope... still jumping back to always same value set by the Qcells/SolaX App. Changed setting f. i. from 100 % to 80% jumps back to 100% some seconds later as always before. Bug still exists.

olafseidel commented 2 weeks ago

changing it works on my X4, I’m on a slightly older version of this integration but probably more relevant is I did have this issue a few months back, exactly as described…. so stopped changing it but now it works. Perhaps there is some limitation Solax have imposed as suggested above

Nope... still jumping back to always same value set by the Qcells/SolaX App. Changed setting f. i. from 100 % to 80% jumps back to 100% some seconds later as always before. Bug still exists.

Same with me. Always jumps back... :-(

wills106 commented 2 weeks ago

I have marked this as "wont fix" as it's not an Integration issue. Someone needs to report that this register is not working to SolaX, or ask how it's meant to be used.

OrustEngineering commented 2 weeks ago

from Solax: Yes, out team has confirmed that this is a known issue and we are working on fixing this ASAP. The temporary firmware will be available next Monday and the formal version will be published by the end of Oct.