Battery not charging correctly overnight #1750
Comments
|
to add to this, i've just watched as again the battery has failed to start charging when the plan says it should be. i've managed to capture the logs for the time this happened. the charging window should have started at 2024-12-17 23:00:00 looking at the log, it seems that predbat thinks it activated the inverter to "charge from solar and grid" mode, however the "device_id" is missing from the command, and a warning to say the service call failed:
the inverter state (solaredge_panels_storage_command_mode) was never altered in the HA logbook until I manually triggered it I hope the added detail helps to diagnose the issue quickly! please let me know if you need any more detail thanks! |
|
I have Solaredge batteries and have seen the same problem over the last few days. 10% charging two nights ago, 0% the night before last, 20% charging last night. Target in logs is showing 100% The only changes I have made in the last few days is to apply several predbat updates. Happy to provide whatever log information would be useful. I expect a charging window to start at 23:50 for the Octopus lower rate window. For last night at this time I see a planned charge and a log for charge_start_service being called but no inverter register writes. Charging does start at 3:50 and there I see a call to charge_start_service and some inverter register writes. In between charge_start_service is skipped as already called. Successful charges on and before 15th December. Issues started at the charge attempt on late evening of 15th December with charge started ar 23:30 and stopped at 10%. Last night charging did not start until 03:50 (log above) |
|
Adding my logs for last night and some images that might also contain the same issues which have been ongoing. Plan of what was supposed to be happening Attached are the entity logs and then predate logs. |
|
I'm wondering if this relates to the service being used timing out after a period of time? Predbat assumes once the charge service is called that charging will continue until the stop service is called. |
Possibly, however often charging doesnt start at all for instance, the battery is at 0% at 23:30 when the cheap electricity rate starts, and predbat wants it to charge, and changes its state to charging, hoever the inverter doesnt get a call to start charging last night the battery got 21 minutes of charge from 03:00, then the inverter reset to defaut settings and the house load consumed thast charge. the plan said it should be charging from 23:30 previously, predbat would notice this change in state due to the reset, oor that the inverter hadnt started charging and change it's state again, ensuring the charge happens |
|
Similarly, I had a plan which should have started at 23:30 but there was no charging until 03:50 (in the log file above). I have not read into the detail of the log actions before but one difference I can see between 23:30 and 03:50 is that it is only at the later time there is an inverter write to set the inverter charge rate, there isn't one at 23:30. The correct charge window is set. start_charge_service is called at both 23:30 and 03:50 and a number of time after in the charging window ( but not at any time in between). Charging was working without issues up until the session at 23:30 on the 15th. I have taken Predbat updates as they appeared and there have been several over this period. Could it be that something has chnaged which leads to Predbat concluding charging is not to be started? (although there have been some Home Assistant core/OS changes as well). These are the only Inverter writes and charge starts from the log file for that day: 2024-12-17 23:00:08.039552: Inverter 0 Wrote 23:30:00 to idle_end_time, successfully now 23:30:00 |
|
Do you perhaps have charge_low_power on and and is it confusing things? What does your charge_start_service do as it should start charging? |
Is that "set_charge_low_power_mode" ? I do not have that on. The solaredge charge_start_service (from apps.yaml) is: As noted above the difference I can see between a successful start and a failed start is the issuing of a charge_rate write to the inverter prior to the charge_start_service. I'm not sure what triggers those inverter writes for charge rate? |
|
My settings are the same as jrviz. I can't see how to run that service from predbat, however when I manually change my storage command mode to charge from solar and grid then the battery starts to charge within 5 mins. |
|
I had a look at the entities not being available but it was always going to be the solaredge multi integration where this was an issue. I initially hardwired these values in apps.yaml to see if this would fix the charging (unlikely and it didn't!) but I then fixed the entities by changing the storgae control mode in the solaredge integration to another value and then back to remote control and the entities became available again. Last night I had charging start at the expected time (23:30) but then at 00:30 charging stopped. The solaredge integration had a change of storage command mode to "maximise self consumption". This is the command predbat issues to stop charging but I can't see this happening in the log where the stop command is logged as being skipped. (I wanted to get some charge in last night so I switched over to manual charging). There are (at least) three actors here which can change the battery charging state. SE integration, SE online platform and Predbat. Right now I'm suspecting that it isn't predbat that is the problem so am examining ways to check out the other candidates. For predbat is there more debug available which shows when there is a write to the inveter or the stop/start command that is issued? |
|
I suspect I've fixed the midnight issue in the latest release, can you re-test? |
|
Is that a newer version than 8.8.14? I have set up ready to go for tonight and predbat has a plan to start at 23:30 |
|
Today I have also set up a rates_import_override period and saw charging of batteries start and stop OK (using 8.8.14) |
|
The fix was in 8.8.14, I forgot to mention it in the release notes. The service API was not called again after midnight meaning a charge than spanned midnight that was split into two sections would not work. |
What do you mean by split into two sections? If I have a charge period of 23:30 to 05:30 would I expect this change to make a difference? Also, when I did te override charge today I got this entry in the log when stop was called: 2024-12-26 14:00:23.466700: Inverter 0 Calling service charge_stop_service domain charge with data {'device_id': ''} It did stop charging though. |
Right, if the inverter is set as 'can't span midnight' then it would be split in two. The warning seems to related to a select operation, is that in your charge_stop_service, what is it set as? |
|
Yes, that was the call to charge_stop_service at the end of my test rates_import_override period. It did stop though. How would I know if the inverter is set as can't span midnight. I'll see how the run goes tonight and look at the logs. I'm still a bit suspicious of the SolarEdge online platform having changed behaviour and it is changing the battery Storage Control Mode (held as an entity in the SE Multi Integration) from "Remote Control" to "Maximise Self Consumption" for some reason. Remote Control is needed for the integration to work with Predbat or anything else that wants to control the charge state. If this happens then that also explains the reported entities that become unavailable I have set up an automation to monitor state change on that entity and force it back to remote control and send me a notification if it happens. |
|
Still something odd going on with the charging. Two nights ago battery did actually charge to 100% but different to how the plan stated it. Given it being Christmas didn't get chance to get dogs etc. Last night charging didn't work correctly. Think Service calls didn't go through properly.
Here are logs and debug |
|
Last night the battery charged for about an hour and then stopped as command mode changed back to "Maximise Self Consumption" which stops charging. I changed back manually several times during the night and it kept switching back. As I have stated above I think it is the SE online platform change of behaviour and thinking it knows best and changing the mode. I found this discussion on the SE Multi integration. WillCodeForCats/solaredge-modbus-multi#705 The Predbat commands are getting through but the online is overriding it. From the discussion referenced here there are a couple of strategies: 1. Change the Predbat command to use the Storage Default Mode service or 2. Use an automation to monitor the Command Mode and change it to "Charge from Solar Power and Grid" while binary_sensor.predbat_charging is true. I'll try both today. I have done a quick test with strategy 1 but I think I saw this being overridden. I'll test this again as I like this as the commands can all stay in apps.yaml Otherwise I'll set up strategy 2 with a separate automation. |
|
There is a possible third strategy and that is Predbat issues (for this inverter) the start_charge command at the start of each 30min slot or every time the plan is run when charging should be active. I'm not sure what Trefor would think about that and I'm not sure I like it either as that would be getting Predbat to react to the behaviour of the online service - which has changed. |
|
In general we are trying to reduce the number of inverter commands that Predbat sends to avoid potential issues with excessive flash memory writes https://springfall2008.github.io/batpred/caution/#flash-memory Would seem better to try to understand what the online portal is doing and work with that - option 1? |
|
Good point. I knew I didn't like option 3. I have set up 1 to control charging now and 2 as a watchdog to make sure everything behaves as expected. I will report back. |
|
I think if there was a check done at every compute that the entities doing the inverter control are in the state they are supposed to be at based on predate state then that can be the control on whether or not to re-write the inverter service command. For Solaredge inverters there is a storage_command_mode which is linked to a timeout till default which is 3600s, this can be changed but reverts back to 3600 when the inverter resets twice a day. There is also storage_default_mode which I have assigned as what predate alters. Its reset behaviour I'm not too sure on. |
That is what Predbat does with my GivEnergy inverters, if you manually make an inverter config change then Predbat will change it back on the next run to match what it should be according to the plan. Might be a bit more complex for other inverter types if the changes are made via service calls, but would resolve your problem |
|
I have set up an automation that is triggered by mode entity changes from Charging to Self Consumption AND if predbat is signalling charging then the default mode will be set back to charging. |
|
Hi - I've fallen down this rabbit hole. My battery is charging for an hour and then discharging. I was wondering how you got on the service mode change and automation. I've just set my system up to follow this strategy. |
|
Changing the service calls to change the Default Storage Mode rather than Storage Command Mode has worked for me. I have the automation described above as a backstop but it does not seem to be needed at the moment but I will leave it there to pick up any odd changes that might come from the SE online service making changes |
|
This also works for me. The automations get called and default storage mode is set back correctly. Thanks for the help! |
|
Things do seem to be working again now and reliably end the night on a full charge. Did set up a backup automation which I’m trying to work out if it does kick in. Need to wait till I have more time for that but it’s looking positive. |
|
I don't know how to test from main. Do I just copy in the modified python files? |
you can copy the python files, or in Home Assistant, open the control select.predbat_version and select 'main' from the list and predbat will update itself to that version |
|
Thanks. All set up for testing tonight. |
|
Thanks, I was planning to have a look at the code tomorrow to see if I could figure out how to do it! I've pulled from main and added the repeat options, but got errors when triggered. I think the example is wrong @springfall2008 and it should actually be always and not repeat that is used in the service block: I'd actually gone a different way with the Automations to check this to the others, instead of having timers running, I setup checks for when the Storage Command Mode changes to Maximise Self Consumption. One checks if Predbat Is Charging and changes the mode back to 'Charge from Solar Power and Grid' The other checks Predbat Is Exporting and if true changes the mode back to 'Discharge to Maximize Export' Both have run today and I'll leave them enabled as if this works they shouldn't trigger overnight. |
|
OK, an hour after the inverter was set to Charge, it's still there with no automation triggered so the 'always' flag is working :) However, I'm seeing duplicate calls and some are failing with a Warn message. I'd noticed two calls happening earlier today when I added all the logging so it isn't new from this change. Earlier today I'd seen it change to Self Consumption on the first and then Charge/Export on the second. Debug from the SolarEdgeModbusMulti integration shows calls are made to set the state every run, twice on some and only once on the ones with the failure: |
|
I had a successful charge last night with my automations off and using "always". I just had one switch back to not charging during the night which was recovered by a charge start. I'm seeing two calls to charge_start on 10 minute boundaries (h:00, h:10, h:20...) but only one on 5 minute boundaries (h:05, h:15...). Are there two passes running on these boundaries? The only times I have seen Warnings in the logs for service calls no response have been on Predbat restarts after I made changes to apps.yaml but I will keep an eye open |
|
Glad to hear that worked for you - before I switch my service calls to storage_command_mode from storage_default_mode can you point to me to what 'always: True' means? I couldn't see that in the documentation - apologies if it is there and I didn't look hard enough :( |
|
It's an update to allow service calls to be repeated at each Predbat cycle during a charge/discharge active window. This is only in a test version of Predbat in main currently and not yet released. Documented above by @springfall2008 but there was a slight typo I think (doc still needs to be changed). For service calls you want to repeat to cope with Inverter reset, timeout etc. (start_charge, start_discharge) you would have: charge_start_service: For those that don't need it (stop_charge stop_discharge) you leave out the always clause. |
|
Overnight things worked fine, mode stayed as expected for the long charging period so I'm pretty sure this has fixed the issue, though my automation caught the inverter reset before Predbat had a chance to fix it (though I'm sure it would have). I've disabled all automations relating to checks/fixing the inverter state now and will monitor. As this was a breaking change for systems already setup, is it possible to default to 'always: True' for charge_start_service and discharge_start_service IF the Inverter type is SE? I'm not sure if it can be done selectively like that - if not, then having it for all services would be fine and those of use that know can disable it for the Stop services. I think this will have affected people who aren't active here, and may have had Predbat working for some time with a SolarEdge Inverter - this change will have broken long charge/discharge periods and unless they re-read the docs they won't know how/where to fix it, so if we can make it the default for SE inverters then it will fix those systems automatically. It doesn't matter for those of us reading this thread, so if it can't be done then that's fine, but being able to revert all the other SE systems to how they used to work seems like it is worth considering. I'm not sure what happens with all the other inverter types, I don't see other issues raised so I'm guessing they don't suffer from the resets/timeouts that SE has. |
|
@cyberkryten are you seeing two start_charge calls on round 10 minute run boundaries and only one on the interim 5 minute ones? |
Ah, good point. Yes I'm seeing one on 5min when the plan is not recalculated and two on 10min. The first appears early on and then there's a second after the plan is recalculated - that explains why at times I've seen different results with the first being Self Consumption and the second Export - it first sets it to 'what my current intent it' and then after the recalculation, sets it to 'what my new plan is'. The second one, after a new plan is created, always needs to be done, but the problem with removing the first one is that the first call happens before the check to see if the plan is going to be recalculated - it needs to be done (otherwise we'll be waiting 10min for the inverter to reset to the correct mode instead of five). I guess maybe the check could be added earlier, but that's a BIG change and could cause a lot of problems! |
|
Just a bit of thinking out loud :-) I guess we go to this point because Predbat does not check inverter status as a condition for the service call. The current once and skip model causes issues with SE timeouts/resets. The always model result in redundant calls and raises a possible concern about inverter writes. Is there an approach where the service api calls are not directly to selects on the SE Modbus entity but to a script which has the logic to check current status and minimise writes? Yes, it is logic outside of Predbat but could be better than automations that are "snooping" from the sidelines for unexpected states. |
|
I use my own input select helpers, and then an automation to spot that the helper has changed, to then drive the SEMulti selects. For me, this reduces how many times it sends the new command, as it only reacts to changes on the helper. I only really do this as I get fairly frequent failed commands talking to i1, so I use a retry service in the automation to help catch that. |
|
I was thinking something like this called for the start_charge service api to check status before a write to the SE Multi entity (apologies, very crude draft as this is new to me so this may need more work) sequence:
|
|
Here's an example where it isn't behaving as I'd expect - the plan changed from Export to Charge - this may be a legacy of how other inverters work, but as we're only changing the one parameter in SE there is no need to make the charge_stop_service call to reset to Maximise Self Consumption before making the charge_start_service call to go into Charge from Solar Power and Grid mode: |
|
Just 'updated' to the main branch, and now I have lost all control, the battery should be charging now ready for the saving session and keeps going back to 'maximise self consumtion' I've added the following in my apps.yaml (which can I confirm is still located in the root of the predbat folder, or does this now need to move to the config folder?) charge_start_service: Nothing in the log to say its even attempted to do anything **** Starting Standalone Predbat **** |
|
Further to the above, I've just noticed this in the log: 2025-01-08 18:30:44.573413: Warn: Service call select/select_option data {'entity_id': 'select.solaredge_i1_storage_command_mode', 'option': 'Maximize Self Consumption', 'always': True} failed with response None |
|
@leacho73 Was this all working before you updated? From the look of it, Predbat can't determine your IOG slots and that means it won't know when to charge. This change kicks in later and so you have other problems not caused by this update (unless there were other changes pushed to main with this one). I'd try a HA restart, check your Octopus integration is working and if not then open a new ticket with full debug logs. The 'failed with response None' has been seen by a few of us - not sure what it is yet, I'm away for a couple of days so won't get chance to debug until next week now. |
Hi @cyberkryten - yes all working before - no issues apart from the SE inverter mode disconnect - woke up to 25% battery this morning rather than 100% due to the inverter resetting overnight and predbat not seeing it. Re: octopus IOG - not sure why that logs - as it picks up my slots absolutely fine. Cheers |
|
Everything worked well last night. Command mode set to charge from 23:30 to 5:30 and default mode unchanged from maximize. Battery fully charged by 2:30. I had automations turned off to set mode. The two automations to detect a change for 30s by @cyberkryten did not trigger. |
|
Just upgraded to latest PredBat release and behavior is exactly the same as it was on main - mode goes to charging, and battery immediately reverts to discharging - I have resolved the Octopus IoC issue however: Latest Predbat Log: Bootstrap Predbat
|
|
Further update to this overnight - I removed 'Always: True' from 'charge_stop_service' - and Predbat now appears to behave as intended - however I have noticed that it takes up to 30 minutes to register a change - normally at 00 or 30 past the hour - when I restarted PredBat after making the change - it sat in 'Hold for Car' until 30 past the hour and then changed to Charge - not sure if this is intentional? |
|
My Default Storage Mode has always been Maximise Self Consumption, so that's not your issue - all that means is that after a reset or timeout that's the mode the inverter will be in if not told to do anything else. I think we need to figure out if this is a plan/calculation issue or a command issue putting the inverter into the correct mode - probably worth raising this as a new issue and attaching the full apps.yaml and a full debug predbat.log covering at least a couple of runs - there must be an issue reported in there somewhere |
|
One thing to note is the service here is a select option, so calling it every 5 minutes doesn't really matter it won't do anything if it selects the same option again. |
|
That's interesting. Are you saying the select option will not result in an inverter write if the option in the same as the current setting? I've just written a script to check the current value before in initiating a select - is this not needed? (although the script also allows a custom timeout to be set to avoid the annoying default 1hr SolarEdge timeouts :-) ) |
|
I've included it into my service call in the predbat configuration. |
|
I did read a post elsewhere that the timeout has to be set before a command is issued as any command picks up the timeout current value at the time of the command and runs the timer from that. I have not tested if that is true though!. My script changes the timeout first, a short delay and then the storage command |
I believe this is correct (for solaredge) |
Describe the bug
Battery is not charging correctly overnight.
no config changes have been made other than updating plugin / addon versions.
last working correctly around v8.6.0
also, have been getting a message from HA "The entity no longer has a state class"
Expected behaviour
Battery charges to 100% overnight during off peak import rate
Predbat version
v8.8.9
Environment details
HAOS v14.0
Core v2024.12.3
SolarEdge Modbus Multi v3.0.3
Octopus Energy v13.2.1
myenergi v0.0.29
Standard HAOS installer
apps.yaml.txt
Log file
predbat.log.txt
The text was updated successfully, but these errors were encountered: