pv_opt icon indicating copy to clipboard operation
pv_opt copied to clipboard

Doesn't Charge from PV-OPT V5 SolarmanV2

Open Pyinthesky99 opened this issue 3 months ago • 14 comments

Describe the bug PV_OPT appears not to charge on scheduled slots To Reproduce

consistent

Expected behavior Charge during allocated slot

Image Image Image Image

From the last snip it appears to have set the current but not the time.

pv_opt.log

Desktop (please complete the following information): Win 11

  • Browser: Edge

Smartphone (please complete the following information): N/A

Additional context Add any other context about the problem here.

Pyinthesky99 avatar Oct 11 '25 12:10 Pyinthesky99

Pv_opt is reporting that the end time is set to 14:30.

Can you check the entity name of "Charge Time 1 End" please? (Click the spanner/clock icon, then the gear icon, then snapshot entity ID.

stevebuk1 avatar Oct 12 '25 22:10 stevebuk1

Ah, Interesting!

To check if it was something external, I rolled back to V4.11 where it used to be ok and it worked fine, In that version it is called Solis Timed Charge End.

Image

I have now reloaded v5.0.0-Beta-6 and it is the same there. Timers 2 and 3 are labelled 2 and 3 but Timer 1 is labelled just Timer.

Image

Would that have something to do with it? :-)

Pyinthesky99 avatar Oct 13 '25 10:10 Pyinthesky99

Re-installed v5 Beta 6 this morning. Set to Prevent discharge and it set an end time to 11:30 but switches show it then reset end time to same as start time.

Image

Nothing to reflect reset in log

pv_opt.log

Pyinthesky99 avatar Oct 25 '25 09:10 Pyinthesky99

Strange, everything that Pv_opt logs says the start and end entities are being updated correctly. The last bit of your most recent log is the readback from the inverter where it says the end time is at 11.30.

10:31:39     INFO:   charge            :
10:31:39     INFO:     start           : 25-Oct 10:21 BST
10:31:39     INFO:     end             : 25-Oct 11:30 BST
10:31:39     INFO:     current         : 0.0 A
10:31:39     INFO:     power           : 0.0 W
10:31:39     INFO:     active          : True 
10:31:39     INFO:   discharge         :
10:31:39     INFO:     start           : 25-Oct 09:00 BST
10:31:39     INFO:     end             : 25-Oct 09:00 BST
10:31:39     INFO:     current         : 0.0 A
10:31:39     INFO:     power           : 0.0 W
10:31:39     INFO:     active          : False 

Try setting prevent discharge again, wait for the end time to be cleared back to the same as start time on the dashboard, and then allow another optimisation run to finish, then send the log.

stevebuk1 avatar Oct 25 '25 20:10 stevebuk1

Thanks Steve,

Will give it a go tomorrow and report back.

Have reverted back to V4.11 so need to reload V5 tomorrow after tonight's cheap load.

nothing to do with numbering/names of Timers then?

Pyinthesky99 avatar Oct 25 '25 20:10 Pyinthesky99

nothing to do with numbering/names of Timers then?

Not that I can see. I compared the code between v4.11 and V5 but couldn't see any difference. I'll take another look.

stevebuk1 avatar Oct 25 '25 20:10 stevebuk1

That wasn't a barnstorming success. I reverted to V4.11 to take advantage of the -4p rate overnight and it didn't charge much at all, should have gassed up the batteries.

pv_opt.log

Wonder if it got confused by the clocks going back. This is the state of the timers/Charge this morning

Image

Looks a bit stuck, did it get confused by the clocks going back?

Have now loaded V5 Beta 6 and it cycled and stopped on "Status Updating Inverter" . I put into Read Only and it then cycled to Idle/Read only but taking out of Read Only stops at Updating Inverter and not doing 10 minute cycles

pv_opt.log

Put into Prevent discharge and it came up with a plan

Image

But no change to the Timers

Image

and no 10 minute cycle at 10:30

pv_opt.log

Pyinthesky99 avatar Oct 26 '25 10:10 Pyinthesky99

PS I put it into read only and did a manual charge from 10:33 to 11:30 at 80A. After it had finished, I took it out of read only and it has reset the timers and cycled to Idle. I will see if it doing regular cycles and then try Prevent Discharge

pv_opt.log

Pyinthesky99 avatar Oct 26 '25 11:10 Pyinthesky99

PPS now 12:01 and it hasn't cycled since 11:32

pv_opt.log

error.log

Pyinthesky99 avatar Oct 26 '25 12:10 Pyinthesky99

Added error.log to above as tz error

Pyinthesky99 avatar Oct 26 '25 13:10 Pyinthesky99

I don't know why but it is now cycling every 10 minutes on V5. I thought I had reverted to V4.11 but apparently not, according to the logs!

It did have a hiccup last night, was supposed to charge for 30 mins at 10:30 at 4000W as -0.9ppkWH, as cheapest in foreseeable future but gave up at 10:50. Don't really understand the logic in that. Looking at the Midnight charge in operation it appears to write the timings to the inverter, wait the 72 seconds and then write the current? I was quite surprised it charged at all if I was on V5

Have at last done as requested several messages ago, set to Prevent Discharge. It set Timings OK. On at 09:41 and off at 10:30 A few seconds later is set the off to the same time as on 9:41, without setting it to Prevent Discharge OFF. I then set PD to OFF at 9:46 and it did a cycle but no change to the timings, obviously as they were already equal.

At 9:50 it did an Optimization Cycle so here is the log.

pv_opt.log

Pyinthesky99 avatar Oct 27 '25 09:10 Pyinthesky99

Thanks for the log. Pv_opt is definitely clearing the end time.

A change I made between 4.0.11 and 5.X.X to fix hold logic I think is the cause of this issue. Try 5.0.0-Beta-7 to see if that clears it.

stevebuk1 avatar Oct 27 '25 20:10 stevebuk1

Thanks Steve

Will do.

Pyinthesky99 avatar Oct 28 '25 18:10 Pyinthesky99

Hi Steve

Have had no more instances of failing to charge so happy for you close this down. I have set to 30 minute cycles and am still trying to find a sweet spot by adjusting Solar Confidence, Daily Consumption, etc but still find it odd that some days it won't gas the batteries at dead cheap but will charge another day at 16.

I think it's best to ignore it and let it get on with it!

Pyinthesky99 avatar Nov 10 '25 11:11 Pyinthesky99

Hi Steve Hope you have been keeping out of the cold! I have been having a lot of grief with my Pylontechs, apart from Overvoltage Alarms they have been refusing to charge above 93%SOC. I thought we had nailed this, isolating to one of the stack of 4 batteries which was replaced last week. I have therefore been keeping an eye on SOC, last night, with prices around 10p, pv_opt was supposed to gas up the batteries to 100% so thought that would be another good test. It had last week got to 100 with grid and solar after the offending battery was swapped out, as per HA SOC Chart. This morning the SOC hadn't gone above 86% which was mildly disappointing, at 6:00 it was supposed to go from 78 to 97 at 7:00 but only got to 86. Is this likely to be the BMS throttling back? Seems a bit early, it used to come in around 89-90, do a bit of balancing and then jump to 99-100 after a few minutes. Or do my pv_opt settings need a tweak?

Image

pv_opt.log

Edit..... This is a Pylontech/Solis issue, this afternoon the sun is shining, panels producing 2.5kW but I have started exporting as the batteries are only charging at 500W

Image

Pyinthesky99 avatar Nov 30 '25 11:11 Pyinthesky99

Sounds like you are having a nightmare with Plyontech reliability. I'm also on Plylontech and getting distinctly nervous, as am on a fairly old Solis firmware version that allows 53.5V as a charge voltage which is way too high. Yes the BMS should protect, but I'm beginning to realise it doesn't!

For background Plyontechs charge to 89% and then the battery balancer kicks in. This is passive (not active) meaning that that it switches in parallel resistance on the cells that are charged the most to allow the cells that aren't quite up to voltage to get extra charge current. Assuming all is well then all cells continue to charge (but not at full charge rate) and the battery reports 100% when all cells report fully charged via voltage level. (Before 89%, it is coloumb counting i.e just noting energy transferred in and out to give a value of SOC). Whilst cell balancing I think it continuously reports 89% but I'm unsure exactly what releases from 89% to progress to 90, 91 etc all the way to 100.

Predbat does have a charge gradient function that attempts to compensate for slowing charge as batteries approach 100%, but Pv_opt doesnt have any of this. To be honest my Plyontechs dont spend long at 89% and curiously it only ever seems to happen when charging from solar rather than from grid.

If you arent getting to 100% then I suspect it means that certain cells arent getting to full voltage, which basically means I think there is cell damage. I noticed your questions to the Plyontech batteries facebook group (I'm a member), thats the right place to ask the question. The owner of the group runs a battery repair service and frankly if I had an issue with mine thats probably where I'd go first.

Honestly if it happens to me I'll be heading in the Fogstar direction, which have active battery balancers and the ability to replace individual cells. I'll probably do one of thier DIY kits.

stevebuk1 avatar Dec 02 '25 20:12 stevebuk1

Thanks for the info, Steve This charge voltage seems to be a 'thing'. So far, 3 of my 4 US2000C have been returned in the 3 and a half years since the install, the third was pulled last week and the original installer fitted a loan unit. I all worked well, charging to 100% for a couple of days until the problem on Sunday which I put on the Facebook group. For a change, I asked Solis for their input and they said the inverter was OK and the batteries were charging to 100%, which it did on Monday! I replied, asking if the firmware was Ok and they said early yesterday morning that they had changed some settings, but didn't say what, but I should keep an eye on it for 24 hours. A few hours later, when it was getting near 99% topping up with Solar I got a BMS Overvoltage alarm on the Inverter. I have a device built around https://github.com/hidaba/PylontechMonitoring with some changes so I can look at all 9 metrics for the 60 cells in my 4 batteries in Home Assistant but I am blowed if I can find the culprit this time. When it was alarming a couple of times a day it was quite easy. I started to put it my repo on Github but keep getting overtaken by events. I have been looking at Fogstar and have repeatedly informed my supplier I would be quite happy to sell my Pylontechs back to them, they would then have some relatively new spares.

Pyinthesky99 avatar Dec 02 '25 22:12 Pyinthesky99