Solar Edge Integration #181
Labels
enhancement
New feature or request
Comments
|
I forgot to include the modbus device entities on the front end; here they are.
|
|
Thanks, I'll try to work up a configuration for a read-only version at first Do you know how you set the charge time? |
|
In order to charge from the Grid, I have to set the AC charge policy to "Always Allowed", and then set the storage command mode to "Charge from Solar Power and Grid" Then it charges from the grid. I don't have a way of setting a time on that apart from the automation running and looking at the octopus target and then updating those statuses. |
|
I'm having trouble tallying some of the pictures to the table, not all seem to match. Do you have the name for 'Available Energy' as shown in the picture? I also need two sensors I can't see here:
If you can find these I'll do the updates and we can give it a try. I've created a branch here with a few minor updates to Predbat and an example configuration (solaredge.yaml) which would be used instead of the default apps.yaml The code from Predbat with the update and the template configuration is on this branch: |
|
Hi, So the available energy as seen above, is from: sensor.solaredge_b1_available_energy As for the house load, I believe it's sensor.solaredge_i2_ac_power Now as for the Solar Energy produced, that's a tricky one, I think. I had to create custom sensor of that from memory, as I use this sensor for that which is an accumulative total ever produced; solar_panel_production_kwh. I got that from one of the guides on how to use the Solare edge multi-integration on the home assistant forums. |
|
Okay great, I think I have something to test. Can you go through the normal Predbat install as if it was a GE inverter (install AppDaemon, enable AppDaemon in HACS, installed Predbat). Then rather than changing the template configuration it installs:
And have a look at the appdaemon log file to see what happens. I'd recommended in appdaemon.yaml to point your logs to a separate file so that you can copy/paste them easily, just add this to the bottom on appdaemon.yaml: |
Closed
|
For info, the B1 'available energy' sensor doesn't seem to be indicative of the live state of charge. Instead, it appears to be an indicator of what the BMS thinks 100% is, so the live charge level of the battery, in kWh, would be B1 available energy * ( B1 state of energy/100). M1's 'AC power', positive or negative, indicates the flow out/in at the grid feed (normally). It does not distinguish, on its own, whether the import is to the house or to the battery, if it's being charged from the grid. I1's 'AC power' sensor would be negative in that case, however. Hope that all makes sense. |
|
Hi - I'm helping Trefor out with adding additional inverter brands. In addition to the above can you answer the following please?
|
|
Hi! Let's see: There isn't the ability to write timed slots to the inverter. The process for triggering a grid charge/discharge is as follows: One time only, unless reverted:
At slot time:
You can set 'Storage Charge Limit'/'Storage Discharge Limit', both in watts. These are not specific to any slot, and will persist until midnight-ish, when they'll revert to 11400W, which I believe is just the maximum value of the register, as the max for the battery is 5000W. You cannot set a target SoC, just the power limit and duration. The inverter reports SoC as a %age, but an energy can be derived using that and the 'available energy'. You can set a backup reserve, in %age. Hopefully that covers all your queries, happy to expand/clarify as required. It sounds like, if other inverters manage timed charging/discharging onboard, then SolarEdge might require an additional control component too keep track of slots within HA, and trigger them at the appropriate time. |
|
Thanks! Every inverter really does do things differently…
I’ll have a dig through what you’ve sent and see it I can set up a test setup.
…On 7 Nov 2023 at 15:25 +0000, RobinXe ***@***.***>, wrote:
Hi! Let's see:
There isn't the ability to write timed slots to the inverter. The process for triggering a grid charge/discharge is as follows:
One time only, unless reverted:
• Set 'Storage Control Mode' to 'Remote Control'.
At slot time:
• Set 'Storage Command Timeout' to length of slot, in seconds.
• Set 'Storage Command Mode' to 'Charge from Solar Power and Grid' or 'Discharge to Maximise Export'.
You can set 'Storage Charge Limit'/'Storage Discharge Limit', both in watts. These are not specific to any slot, and will persist until midnight-ish, when they'll revert to 11400W, which I believe is just the maximum value of the register, as the max for the battery is 5000W.
You cannot set a target SoC, just the power limit and duration.
The inverter reports SoC as a %age, but an energy can be derived using that and the 'available energy'.
You can set a backup reserve, in %age.
Hopefully that covers all your queries, happy to expand/clarify as required. It sounds like, if other inverters manage timed charging/discharging onboard, then SolarEdge might require an additional control component too keep track of slots within HA, and trigger them at the appropriate time.
—
Reply to this email directly, view it on GitHub, or unsubscribe.
You are receiving this because you commented.Message ID: ***@***.***>
|
|
Any progress on this? I'll soon have an installation with a SolarEdge inverter, and would be happy to help debug this and try it out. |
|
@Arachnid if you want to try then maybe get together a predbat config using one of the templates from something like Sofar and see what you can get working, then come back with the bits you are stuck on? |
|
Hi I've tried to set this up on my install, renaming sensors and creating the required Solar_Panel_Energy sensor. I'm currently facing this error in the AppDaemon log. 2024-02-12 23:43:53.879437 WARNING pred_bat: ------------------------------------------------------------ The log file seems to be demonstrating generally good discoveries being performed, but ultimately no plan is being generated, the plan card outputting NULL. I'm happy to keep plugging away at this over the next few weeks as a platform tester, as I'm 99% sure my config file and install are correct. I'll disable AppDaemon for tonight (revert to crude NodeRed battery management). If I can get past this bit, I'm sure I can help you guys generalise your code. |
You can but it doesn't appear to anything on my ModBus install! If you set the value, it invariably resets to its default. This makes me question if it's a universibly reliable element. |
Yes, I've found that my SE inverter resets itself at least once a day, restoring defaults to all the settings. My solution to this has been a watchdog component to any automations, that is triggered by a change in that setting, to ensure it gets reset as desired following a reversion. |
|
I have a semi-working, read-only installation up and running - I'll post the relevant config snippets below for those that it helps. Note that some of the sensors (namely I'm only classing this as semi-working as for some reason my 24h battery depletion forecast is woefully pessimistic - I'm presuming I've probably just screwed up somewhere and not implemented either my iboost or EV charging scenario properly, but if you see similar (past 24h is fine!) please do chime in. load_today:
- sensor.solaredge_i1_ac_energy_kwh
import_today:
- sensor.solaredge_m1_imported_kwh
export_today:
- sensor.solaredge_m1_exported_kwh
pv_today:
- sensor.solar_panel_production_daily # Custom template sensor
num_inverters: 1
# Inverter type stubbed to SX4 to allow execution - SE is an invalid type in current head version
inverter_type: "SX4"
# inverter_type: "SE"
# auto_restart:
# - service: homeassistant.reload_config_entry
# entity_id: sensor.solaredge_i1_status
battery_rate_max:
- sensor.solaredge_b1_max_charge_power
charge_rate:
- number.solaredge_i1_storage_charge_limit
discharge_rate:
- number.solaredge_i1_storage_discharge_limit
battery_power:
- sensor.solaredge_b1_dc_power
pv_power:
- sensor.solar_panel_production_w # Custom template sensor
load_power:
- sensor.solar_house_consumption_w # Custom template sensor
soc_kw:
- sensor.solaredge_b1_available_energy
soc_percent:
- sensor.solaredge_b1_state_of_energy
soc_max:
- sensor.solaredge_b1_maximum_energy
reserve:
- number.solaredge_i1_backup_reserveControl will require changes to predbat's codebase, but as previously discussed, should be relatively trivial to implement and can probably (I'm guessing!) be implemented by extending off the Home Assistant entity control that already exists. |
|
I'm having a SolarEdge system installed in the next few weeks, so I'll follow this thread and I'm also happy to help once I have the system in place. |
|
Looking at the template here: https://github.com/springfall2008/batpred/blob/main/templates/solaredge.yaml There's a couple of differences, this is probably another template: And this stuff you may want to add: I've re-created the branch : https://github.com/springfall2008/batpred/tree/solar_edge and added the missing 'SE' configuration table, however I don't know how to control the inverter. How can Predbat start a charge and how can it start a discharge? Can you provide an example automation in HA to show how this is done and then I can add it to the code? |
Here you go! choose:
- conditions:
- condition: state
entity_id: binary_sensor.octopus_energy_a_<redacted>_intelligent_dispatching
state: "on"
alias: Intelligent Octopus block / Off-Peak
sequence:
- device_id: a0f1da08c6f00368315c3c7bed85f2db
domain: select
entity_id: bb33d53355844f55e69380b2f11b4ed5
type: select_option
option: Charge from Solar Power and Grid
alias: Charge from Grid
alias: Intelligent Boost
- conditions:
- alias: Zappi charging from PV
condition: state
entity_id: sensor.myenergi_zappi_status
state: Charging
enabled: true
sequence:
- device_id: a0f1da08c6f00368315c3c7bed85f2db
domain: select
entity_id: bb33d53355844f55e69380b2f11b4ed5
type: select_option
option: Charge from Solar Power
alias: Charge from Solar only
alias: Inhibit discharging house battery for EVSE load
default:
- device_id: a0f1da08c6f00368315c3c7bed85f2db
domain: select
entity_id: bb33d53355844f55e69380b2f11b4ed5
type: select_option
option: Maximize Self Consumption
alias: Maximise Self ConsumptionAll commands are targetted at the Here are the valid modes for options:
- Solar Power Only (Off)
- Charge from Clipped Solar Power
- Charge from Solar Power
- Charge from Solar Power and Grid
- Discharge to Maximize Export
- Discharge to Minimize Import
- Maximize Self Consumption
friendly_name: Solaredge I1 Storage Command ModeThe control flow as discussed in #181 (comment) is correct as far as I'm aware.
This is likely https://gist.github.com/Ashpork/f80fb0d3cb22356a12ed24734065061c One other thing: your extra config calls out |
|
The reason the i2 is called out is because my inverter for some bizarre reason that I cannot resolve is that it’s i2 and not i1. I have tried changing it to i1 but to no avail. |
|
Please find on the branch an updated template with the charge/discharge service settings and an updated predbat.py to support this. Can you give it a try please? |
|
I've just switched to the branch and command seems to be working as expected: I'll observe it over the next 24-48h and report back if there's any serious issues. Initial observations:
Happy to contribute / flesh out setup documentation if it'd help! |
|
Great news, please review my pull request that is now updated: https://github.com/springfall2008/batpred/pull/817/files
Once we are happy with this and its merged I can look at charge and discharge freeze modes. |
|
Sorry for the delay, life's been happening 😵💫 The functionality in #817 seems to be working perfectly after a week's testing (still getting strange expected load but that's out of scope for this issue and I'll tackle it another time) 🎉 I guess just charge / discharge freeze to consider now? |
|
Morning All, firstly a thank you for your efforts! loving the way this is coming along and I am very much looking forward to using it in anger :) I have been trying to get it up and running this week and I am mostly there, but had a couple issues that I couldn't find the solution to. I was hoping that somebody may be able to kindly offer some advice on what I should review next. PredBat status shows errors:
I have the following setup in my apps.yaml config (note, I added a "modbus" prefix to the solaredge-modbus-multi install rather than leave it default. Checking those entities in HA, I see both report a value of undefined which explains the error. solaredge-modbus-multi is setup per the guides, with power control options enabled, butI did not check "allow battery energy to reset". Storage control and site limit control are also enabled. I suspect this question should likely be directed to the solaredge-modbus-multi issues instead, but wanted to raise it here first in case the entity being referenced needs to be revised/reviewed. I'm using a SE6000H (soon to be upgraded to SE1000H), with 11kWp and a home battery. |
|
charge_rate and discharge_rate should be configured in apps.yaml to an HA control that allows you to control the inverter charge and discharge rate. e.g. on my givenergy inverter it points to a control that can be set to a value between 2600 and zero, representing full rate charge/discharge down to no charge/discharge. Predbat uses this to control the rate of battery charge and discharge. So yes, it does sound like a question for the Solaredge modbus integration. If the answer is that there is no equivalent of charge/discharge rate for your inverter type then will need to find a different way of turning the inverter charge/discharge on/off and Trefor will have to adapt the code. But if you can ask the question first |
3 tasks
Good Morning, thank you for the feedback, very helpful. as you hit reply I had just finished opening a bug for this here: I am suspecting that the entities are correct, but the modbus integration seems to not populate them. The debug log shows it is pulling the values which the entities should be populated with. It may be an issue due to me using a prefix rather than standard config. I shall see what feedback that gets. I am curious what values others have for the entities from their SE inverter via modbus. I'll hard code the values for now to 5000, which are the correct values for the battery charge rates. |
|
Further updates. would appreciate if anybody could offer some guidance on what else I should review? From the Predbat AppDaemon v4.4.2 engine (on port 5051), this is likley showing the issue with the never ending charge issue. Firstly, the charge_rate and discharge_rate entities always show 5000w or 11400w, never any other numerical value. I am curios if this is part of the issue. I suspect this should be showing more real time data about the actual rate of charge, or rate of discharge of the battery? The other bit that stands out is the charge & discharge freeze is listed as not supported thus disabled.I'm assuming this is why it won't actually hold properly. In this scenario I would assume it should set Max Self Consumption mode instead, but perhaps it isn't able to do that? |
|
Could you check the logs on the Home Assistant side? A 500 response implies something's going wrong on that side. |
|
Ah, good shout. Checking those logs and there are a few issues. Failed to connect errors to the modbus around the same time as the 500 errors
This is an interesting one, although all of those entities are avilable and have values. It seems the comms to the inverter reports as unstable, although cross checking the UniFi network logs I can see the connection looks stable so I don't think it's a network issue. Given that "SolarEdge inverters only support one Modbus/TCP connection at a time. Additional attempts to connect to the inverter will fail until the last connection is closed", it could just be unfortunate timing with the online platform checking in. I'm tempted to block the inverters internet access to see if that improves things on this front. |
This is going to sound like I'm going crazy, but are you using a PoE switch (unifi or otherwise), and is the inverter connected directly to it? The online platform doesn't use Modbus so it won't be that conflicting. |
|
Happy to explore any and all options :) No PoE switches in my network, although I am using PoE injectors for 3 access points which are in the roof of the building. I am connecting directly over WiFi to the Inverter. Ah, good to know about theonline platform, thank you. I can cross that thought off the list. |
|
Sounds like your issue is more with the Modbus implementation than batpred in that case, so you might want to try jumping into their support channels for further thoughts. Do triple check that you don't have any other software running that might be trying to talk to the inverter locally (EVCC, for example). If you're connecting to the inverter over WiFi, is there any way you can hardwire for a while just to rule out wireless issues? |
|
Unfortunately there is no method to connect via ethernet. I'll do some more monitoring and see if I can gather some more useful information from logs so I can make sure whatever story they tell ends up in the appropriate place. I don't have anything else on the network that will talk to the SE kit. Thanks for the feedback, appreciated as always. I'm still learning how the solution works, and thus where to gather various data and logs from the combined solutions, so will get there eventually |
|
I'm making an assumption, because I can't seem to find it documented clearly. I've set the following extra config in apps.yaml based upon the example "other inverter" config. I've set it on the assumption that with those lines defined, PredBat will no longer consider Hold/Freeze as viable options, thus not attempt them. With a SE inverter, Freeze/Hold seems to set the storage command as "Charge from Solar Power and Grid", but this forces battery charging from grid in real time, rather than for any shortfall. Thus, there is no concept of "freeze" for SolarEdge kit per the definitions (https://springfall2008.github.io/batpred/what-does-predbat-do/#predbat-status), Freeze/Hold won't work on SolarEdge kit. The closest the SolarEdge offers, will be the "Charge from clipped solar power". I've used this setting before, and essentialy it will first cover the home consumption from PV, then export to the limit, and anything above export+usage goes into the battery. Does anybody know for sure if setting the above config will disable freeze and hold functionality? |
|
I've decide to disable control for the time being until the charging concerns are isolated and resolved. I caught it again attempting to "Hold Charge", however, Hold Charge means it sets the mode to "Charge from Solar Power and Grid", thus it doesn't hold anything, it instead just pulls power from the grid to charge the battery to full when it shouldn't be using the grid at all. Here is a more refined example. Storage Command Mode history: The log shows the problem below, it should't be setting "Charge from Solar Power and Grid" for any holds, since this tells it to charge from the grid at whatever rate is needed to hit the max charge rate of 5kWh (IE, that's not a hold). I'm assuming there are some other refinements required for wider support for the SE kit? I would appreciate if those with more knowledge in this area would be able to case an eye over the log below and offer an opinion. My guess, it thinks charging is no longer active, for example, "Current SOC 55% is greater than Target SOC 0. Grid Charge disabled.", but it writes this to the log right after telling it to charge from the grid. |
|
Had an idea from the log I shared, which might solve the problem. Hold sets Target SOC 0. can apps.yaml accept templates? I was thinking of trying to add some logic to the charge_start_service / option property. Essentially, see if I can get it to do the following: I'm on the fence about using "Charge From Clipped Solar Power", , "Charge from Solar Power"or "Solar Power Only (Off)" as the option, but that's a detail to revise later.. Any idea if the above is possible? |
|
Answering your question, no apps.yaml for python code can’t accept Jinja or HA templates. You need to supply proper entity names in the file, but you can of course create a template sensor in HA with the logic you need, and pass the name of that template sensor to predbat in apps.yaml
…On 11 Apr 2024 at 13:04 +0100, Noodleyman ***@***.***>, wrote:
Had an idea from the log I shared, which might solve the problem. Hold sets Target SOC 0. can apps.yaml accept templates? I was thinking of trying to add some logic to the charge_start_service / option property.
Essentially, see if I can get it to do the following:
IF current_charge_limit is 0, option = "Charge From Clipped Solar Power"
ELSE
"Charge from Solar Power and Grid"
I'm on the fence about using "Charge From Clipped Solar Power", , "Charte from Solar Power"or "Solar Power Only (Off)" as the option, but that's a detail to revise later..
Any idea if the above is possible?
is the current charge_start_service any any availabile entity for reference?
—
Reply to this email directly, view it on GitHub, or unsubscribe.
You are receiving this because you commented.Message ID: ***@***.***>
|
|
Thanks for the feedback, very helpful. So I think I've got it working (pending confirmation). Custom sensor (may need refinement) and apps.yaml The only thing I need to verify is does Predbat make the service call to the inverter, THEN set the status, or status first then the service call. If status updates after the service call then there will be a delay setting the appropriate mode so it will likely charge for 5 mins. Will see if this does the trick anyway and go from there |
My observation not from looking at the code but seeing what happens on my givenergy inverter is that predbat updates the status as the last thing it does. I often see the inverter changing and then the status changing to reflect the current mode. There are a couple of binary sensors predbat_charging and predbat_discharging you could try, but these may not be granular enough for you - charging is set when charging or hold charging I think |
|
Thank you, I think it did that as well but need to watch it to verify. I was thinking of adding some extra clauses, such as I think those get set before the service call is made. thanks for sharing your thoughts. |
|
ok, so managed to find some quality time to play around this morning. Firstly, a correction. The SE inverter DOES support charging at a slower rate and this can be controlled directly using the entity number.solaredge_i1_storage_charge_limit. I did some manual testing with it today and found it does work correctly and will limit the battery charging rate. I was wrong when I previously said the battery charging rate was binary, either on at max or off, it can be controlled. The same is true for the discharge rates as well, via entity solaredge_i1_storage_discharge_limit. I did some better quality testing this morning, and in doing so think I found the actual root cause of the problem. If a value of 0 is set for number.solaredge_i1_storage_charge_limit or solaredge_i1_storage_discharge_limit it is considered an invalid value. The entity will get reset to the default value of 5000w, thus charging or discharging limits get reset to the max allowed rate. If I set it to a value of 1w, it effectively turns off charging or discharging, but prevents the entity from resetting, thus will work correctly as a Hold Charge status. Cross checking the logs I shared recently, I can see the following: And that's the issue. 0 is not a valid value for the SE setup. If I have understood correctly (please can somebody sanity check me!) then a Hold ideally should set: Thus will enable charging mode, with essentially no charging or discharging. |
|
Feedback on the bespoke sensor passing the storage command.. I wasn't able to get that working properly. whatever I did it always passed the name of the sensor itself, rather than the value. Likely just an issue with how I've set it up but I tried what I thought were all valid options with no success. Without fail, whatever variation was used the service call ended up as: I've removed that config for now, and instead trying an automation to set the charge and discharge limit to 1 when set to 0 instead. and |
|
Thought I would add an update to share what I finally chose to settle on, as this works for how I want my system operating. I've setup an automation to flip the read only setting of Predbat. between 05:10 and 14:30 the read only flag is on. This lets the battery get charged to a suitable time overnight, and also allows a charge from grid before 4PM if needed (peak rate times on Flux), or discharge to max exports. I've also got the charge and discharge automations per my previous post in place to set 0 to 1 if they get set. I also have another automation which tracks the PV generation. Once generation is covering the consumption requirements, it flips the battery into "Charge from Clipped Solar Power" mode, thus exporting is a priority rather than battery charging. Given the size of the array I have (quite large), I want to export before charging. Once my export limit is reached then exccess power goes into the battery. This is the most effecient method for me. The same automations also listens for the storage command being changed to "Maximize Self Consumption", as I've noted a couple of times if flipped itself back into this mode. I think it might be down to the SolarEdge monitoring platform changing it as the source of the change wasn't anything from HA. So if it changes to Maximize Self Consumption mode, and PV generation is still covering the needs then it will delay 15 seconds, and put it back into Chrge from Clipped Solar Power mode. Those automations seemd to have worked well this morning, and it's done exactly what I wanted. optimal battery charging overnight, priority to exports before battery charging once viable in the morning and a control window later in the day where if it's been a terrible solar day the battery can be charged as needed by PredBat. I'm going to run with this config for the summer unless I find a reason to change it. |
|
Okay, I had a working setup going, but for whatever reason as of last night it's decided to self immolate and is now refusing to charge or discharge the battery from 100%, regardless of what knobs or dials I tweak ( Here's my config - I'm hoping people can learn off this (as I made some tweaks to things like pred_bat:
module: predbat
class: PredBat
# Sets the prefix for all created entities in HA - only change if you want to run more than once instance
prefix: predbat
# XXX: This is a configuration template, delete this line once you edit your configuration
# template: True
# Timezone to work in
timezone: Europe/London
#
# Sensors, currently more than one can be specified and they will be summed up automatically
# however if you have two inverters only set one of them as they will both read the same.
#
load_today:
- sensor.solar_house_consumption_kwh
import_today:
- sensor.solaredge_m1_imported_kwh
export_today:
- sensor.solaredge_m1_exported_kwh
pv_today:
- sensor.solar_panel_production_daily # This is a custom sensor - documentation TBD
#
# Controls/status - must by 1 per inverter
#
num_inverters: 1
# inverter_type: "SX4"
inverter_type: "SE"
auto_restart:
- service: homeassistant.reload_config_entry
entity_id: sensor.solaredge_i1_status
battery_rate_max:
- sensor.solaredge_b1_max_charge_power
charge_rate:
- number.solaredge_i1_storage_charge_limit
discharge_rate:
- number.solaredge_i1_storage_discharge_limit
battery_power:
- sensor.solaredge_b1_dc_power
pv_power:
- sensor.solar_panel_production_w
load_power:
- sensor.solar_house_consumption_w
soc_kw:
- sensor.solaredge_b1_available_energy
soc_percent:
- sensor.solaredge_b1_state_of_energy
soc_max:
- sensor.solaredge_b1_maximum_energy
#reserve:
# - number.solaredge_i1_backup_reserve
#inverter_mode:
# - select.givtcp_{geserial}_mode
#inverter_time:
# - sensor.givtcp_{geserial}_invertor_time
charge_start_time:
- "00:00:00"
charge_end_time:
- "00:01:00"
# charge_limit:
# - number.solaredge_i1_storage_charge_limit
scheduled_charge_enable:
- off
scheduled_discharge_enable:
- false
discharge_start_time:
- "12:25:00"
discharge_end_time:
- "13:55:00"
# Inverter max AC limit (one per inverter)
# If you have a second inverter for PV only please add the two values together
inverter_limit:
- 5000
charge_start_service:
service: select.select_option
entity_id: "select.solaredge_i1_storage_command_mode"
option: "Charge from Solar Power and Grid"
charge_stop_service:
service: select.select_option
entity_id: "select.solaredge_i1_storage_command_mode"
option: "Maximize Self Consumption"
discharge_start_service:
service: select.select_option
entity_id: "select.solaredge_i1_storage_command_mode"
option: "Discharge to Maximize Export"
discharge_stop_service:
service: select.select_option
entity_id: "select.solaredge_i1_storage_command_mode"
option: "Maximize Self Consumption"
# Export limit is a software limit set on your inverter that prevents exporting above a given level
# When enabled Predbat will model this limit
#export_limit:
# - 3600
# The maximum rate the inverter can charge and discharge the battery can be overwritten, this will change
# the register programming and thus cap the max rates. The default is to use the maximum supported rates (recommended)
#
#inverter_limit_charge:
# - 2000
#inverter_limit_discharge:
# - 2600
# Some inverters don't turn off when the rate is set to 0, still charge or discharge at around 200w
# The value can be set here in watts to model this (doesn't change operation)
#inverter_battery_rate_min:
# - 200
# Some batteries tail off their charge rate at high soc%
# enter the charging curve here as a % of the max charge rate for each soc percentage.
# the default is 1.0 (full power)
battery_charge_power_curve:
95 : 1
96 : 1
97 : 0.5
98 : 0.33
99 : 0.25
100 : 0.125
# Inverter clock skew in minutes, e.g. 1 means it's 1 minute fast and -1 is 1 minute slow
# Separate start and end options are applied to the start and end time windows, mostly as you want to start late (not early) and finish early (not late)
# Separate discharge skew for discharge windows only
inverter_clock_skew_start: 0
inverter_clock_skew_end: 0
inverter_clock_skew_discharge_start: 0
inverter_clock_skew_discharge_end: 0
# Clock skew adjusts the Appdaemon time
# This is the time that Predbat takes actions like starting discharge/charging
# Only use this for workarounds if your inverter time is correct but Predbat is somehow wrong (AppDaemon issue)
# 1 means add 1 minute to AppDaemon time, -1 takes it away
clock_skew: 0
# Set these to match solcast sensor names
pv_forecast_today: sensor.solcast_pv_forecast_forecast_today
pv_forecast_tomorrow: sensor.solcast_pv_forecast_forecast_tomorrow
pv_forecast_d3: sensor.solcast_pv_forecast_forecast_day_3
pv_forecast_d4: sensor.solcast_pv_forecast_forecast_day_4
# car_charging_energy defines an incrementing sensor which measures the charge added to your car
# is used for car_charging_hold feature to filter out car charging from the previous load data
# Automatically set to detect Wallbox and Zappi, if it doesn't match manually enter your sensor name
# Also adjust car_charging_energy_scale if it's not in kwH to fix the units
car_charging_energy: sensor.myenergi_zappi_charge_added_session
num_cars: 2
# car_charging_planned is set to a sensor which when positive indicates the car will charged in the upcoming low rate slots
# This should not be needed if you use Octopus Intelligent Slots which will take priority if enabled
# The list of possible values is in car_charging_planned_response
# Auto matches Zappi and Wallbox, or change it for your own
car_charging_planned:
- sensor.myenergi_zappi_plug_status
- binary_sensor.car1_connection_status
- binary_sensor.car2_charging_cable_connected
car_charging_planned_response:
- 'yes'
- 'on'
- 'true'
- 'connected'
- 'ev connected'
- 'charging'
- 'paused'
- 'waiting for car demand'
- 'waiting for ev'
- 'scheduled'
- 'enabled'
- 'latched'
- 'locked'
- 'plugged in'
# To make planned car charging more accurate, either using car_charging_planned or Octopus Intelligent
# specify your battery size in kwh, charge limit % and current car battery soc % sensors/values
# If you have intelligent the battery size and limit will be extracted from Intelligent directly
# Set the car SOC% if you have it to give an accurate forecast of the cars battery levels
# One entry per car if you have multiple cars
car_charging_battery_size:
- 80
- 32
car_charging_limit:
- sensor.car1_charging_target
- 100
car_charging_soc:
- sensor.car1_remaining_battery_percent
- sensor.car2_battery_level
# If you have Octopus intelligent, enable the intelligent slot information to add to pricing
# Will automatically disable if not found, or comment out to disable fully
# When enabled it overrides the 'car_charging_planned' feature and predict the car charging based on the intelligent plan (unless octopus intelligent charging is False)
# This matches either the intelligent slot from the Octopus Plugin or from the Intelligent plugin
# octopus_intelligent_slot: 're:(binary_sensor.octopus_intelligent_slot|re:binary_sensor.octopus_energy_intelligent_dispatching)'
octopus_intelligent_slot: binary_sensor.octopus_energy_a_[REDACTED]_intelligent_dispatching
octopus_ready_time: time.octopus_energy_a_[REDACTED]_intelligent_ready_time
octopus_charge_limit: number.octopus_energy_a_[REDACTED]_intelligent_charge_limit
# Energy rates
# Please set one of these three, if multiple are set then Octopus is used first, second rates_import/rates_export and latest basic metric
# Set import and export entity to point to the Octopus Energy plugin
# automatically matches your meter number assuming you have only one
# Will be ignored if you don't have the sensor
# Or manually set it to the correct sensor names e.g:
# sensor.octopus_energy_electricity_xxxxxxxxxx_xxxxxxxxxxxxx_current_rate
# sensor.octopus_energy_electricity_xxxxxxxxxx_xxxxxxxxxxxxx_export_current_rate
metric_octopus_import: sensor.octopus_energy_electricity_[REDACTED]_[REDACTED]_current_rate
metric_octopus_export: sensor.octopus_energy_electricity_21l4608479_2000060363490_export_current_rate
metric_octopus_gas: sensor.octopus_energy_gas_[REDACTED]_[REDACTED]_current_rate
# Standing charge can be set to a sensor (e.g. Octopus) or manually entered in pounds here (e.g. 0.50 is 50p)
metric_standing_charge: sensor.octopus_energy_electricity_[REDACTED]_[REDACTED]_current_standing_charge
octopus_saving_session: event.octopus_energy_a_[REDACTED]_octoplus_saving_session_events
# Or set your actual rates across time for import and export
# If start/end is missing it's assumed to be a fixed rate
# Gaps are filled with 0
#rates_import:
# - start: "23:30:00"
# end: "05:30:00"
# rate: 7.5
# - start: "05:30:00"
# end: "23:30:00"
# rate: 30.0
#rates_export:
# - rate: 15.0
# Can be used instead of the plugin to get import rates directly online
# Overrides metric_octopus_import and rates_import
# rates_import_octopus_url : "https://api.octopus.energy/v1/products/FLUX-IMPORT-23-02-14/electricity-tariffs/E-1R-FLUX-IMPORT-23-02-14-A/standard-unit-rates"
# rates_import_octopus_url : "https://api.octopus.energy/v1/products/AGILE-FLEX-BB-23-02-08/electricity-tariffs/E-1R-AGILE-FLEX-BB-23-02-08-A/standard-unit-rates"
# Overrides metric_octopus_export and rates_export
# rates_export_octopus_url: "https://api.octopus.energy/v1/products/FLUX-EXPORT-BB-23-02-14/electricity-tariffs/E-1R-FLUX-EXPORT-BB-23-02-14-A/standard-unit-rates"
# rates_export_octopus_url: "https://api.octopus.energy/v1/products/AGILE-OUTGOING-BB-23-02-28/electricity-tariffs/E-1R-AGILE-OUTGOING-BB-23-02-28-A/standard-unit-rates/"
# rates_export_octopus_url: "https://api.octopus.energy/v1/products/OUTGOING-FIX-12M-BB-23-02-09/electricity-tariffs/E-1R-OUTGOING-FIX-12M-BB-23-02-09-A/standard-unit-rates/"
# Import rates can be overridden with rate_import_override
# Export rates can be overridden with rate_export_override
# Use the same format as above, but a date can be included if it just applies for a set day (e.g. Octopus power ups)
# This will override even the Octopus plugin rates if enabled
#
#rates_import_override:
# - date: '2023-09-10'
# start: '14:00:00'
# end: '14:30:00'
# rate: 5
# For pv estimate, leave blank for central estimate, or add 10 for 10% curve (worst case) or 90 or 90% curve (best case)
# If you use 10 then disable pv_metric10_weight below
# pv_estimate: 10
# Days previous is the number of days back to find historical load data
# Recommended is 7 to capture day of the week but 1 can also be used
# if you have more history you could use 7 and 14 (in a list) but the standard data in HA only lasts 10 days
days_previous:
- 7
- 14
# Days previous weight can be used to control the weighting of the previous load points, the values are multiplied by their
# weights and then divided through by the total weight. E.g. if you used 1 and 0.5 then the first value would have 2/3rd of the weight and the second 1/3rd
days_previous_weight:
- 1
- 1
- 1
# Number of hours forward to forecast, best left as-is unless you have specific reason
forecast_hours: 48
# The number of hours ahead to count in charge planning (for cost estimates)
# It's best to set this on your charge window repeat cycle (24) but you may want to set it higher for more variable
# tariffs like Agile
forecast_plan_hours: 24
# Specify the devices that notifies are sent to, the default is 'notify' which goes to all
notify_devices:
- mobile_app_iphone_duck
# Set the frequency in minutes that this plugin is run
# recommend something that divides by 60 (5, 10 or 15) or you won't trigger at the start of energy price slots
run_every: 5
# Battery scaling makes the battery smaller (e.g. 0.9) or bigger than its reported
# If you have an 80% DoD battery that falsely reports it's kwh then set it to 0.8 to report the real figures
battery_scaling: 1.0
# Can be used to scale import and export data, used for workarounds
import_export_scaling: 1.0
# Export triggers:
# For each trigger give a name, the minutes of export needed and the energy required in that time
# Multiple triggers can be set at once so in total you could use too much energy if all run
# Creates an entity called 'binary_sensor.predbat_export_trigger_<name>' which will be turned On when the condition is valid
# connect this to your automation to start whatever you want to trigger
export_triggers:
- name: 'large'
minutes: 60
energy: 1.0
- name: 'small'
minutes: 15
energy: 0.25
# If you have a sensor that gives the energy consumed by your solar diverter then add it here
# this will make the predictions more accurate. It should be an incrementing sensor, it can reset at midnight or not
# It's assumed to be in Kwh but scaling can be applied if need be
# this sensor combines both the Eddi and Zappi divert
iboost_energy_today: sensor.myenergi_[REDACTED]_green_energy_today_2
iboost_energy_scaling: 1.0
watch_list:
- binary_sensor.octopus_energy_a_[REDACTED]_intelligent_dispatching
- time.octopus_energy_a_[REDACTED]_intelligent_ready_time
- number.octopus_energy_a_[REDACTED]_intelligent_charge_limit
- event.octopus_energy_a_[REDACTED]_octoplus_saving_session_events
# zappi
- sensor.myenergi_zappi_plug_status
# cars
- binary_sensor.car1_connection_status
- binary_sensor.car2_charging_cable_connected
# - '+[car_charging_planned]'
# - '+[car_charging_soc]'
# - '{car_charging_now}'and my plan looks like this, which makes zero sense nothing obvious in the logs either, other than it dropping the inverter charge / discharge rate to 0 whenever I try to encourage it back to 5000w. Mode is set to Control Charge & Discharge. Anyone got any ideas? |
|
Is your battery discharging and charging normally outside of HA? I've had an issue in the past where the battery comms stopped (moistuer in the comms), I had to reset the inverter and things just work up agian. was a common issue last year until I had it fixed. Open the side panel on the battery, and check the comms lights as well, perhaps it's moaning. maybe power cycle it and see. The ole' classic switch it off and on :) Which modbus are you using as well? I've had those lock up a couple of times before as well. same thing, off/on to check |
|
I don't think it's a simple comms issue - all entities seem to be updating fine and I can manually change the inverter state through HA and the battery responds as expected. Did cycle both the battery and inverter just for a sanity check (and restarted HA) with no change - seems to be a predbat issue due to the completely MIA plan. |
|
some of your entries like charge limit and battery charge start/stop times don't look to be valid YAML it should be charge_start_time:
- "00:00:00"
charge_end_time:
- "00:01:00"
scheduled_charge_enable:
- off
scheduled_discharge_enable:
- false
discharge_start_time:
- "12:25:00"
discharge_end_time:
- "13:55:00"
inverter_limit:
- 5000two spaces before the dash, no tabs Be worth seeing what's in the logfile |
99.9% sure it's valid YAML, think maybe something got crunched when I copied it out of my terminal into vscode. (I didn't touch the config before it broke!)
Here you go! |
|
Oh, you will want to set those discharge rate automations I shared in an earlier update, looks like it set to 0 in your update and that isn't going to play nicely. Don't think it's the issue though. Seems to have called the service properly, did you update the SolarEdge Modbus Multi module? there was an update for newer HA versions I think this or last week. could always try and uninstall and re-install SolarEdge Modbus Multi. I've done that a few times without an issue. |
|
Definitely not a Modbus Multi issue (I've recreated it earlier in the day with no change), and I don't think it's to do with the discharge rate automation (you report an issue where setting to 0 sets it to 5000w, I'm not seeing that behaviour?) - my main concern is that it's refusing to even plan the charge (or discharge) for the low rate tonight (and indeed wants to just maintain SoC at 100%). The only thing I can think is that some bad data got into the system yesterday (we had some network downtime) but I don't see why that would make it want to stick to 100% for days on end? |
|
Looking at the logfile it appears to just not be planning any charge or discharge of the battery, its running off grid all the time. I'm not familiar with Solar Edge inverters, mine is a GivEnergy, but looking at your apps.yaml: charge_rate:
- number.solaredge_i1_storage_charge_limit
discharge_rate:
- number.solaredge_i1_storage_discharge_limitIs this right? charge rate and discharge rate are looking for something like 2600, the rate the battery will charge or discharge at in watts. Yours are called "limit" so wondered if these were the right entities? Check the value and unit of measurement for them You have one too many entry in days_previous_weight, but don't think that'd cause the problem. |
Yup, just solaredge parlance for the same thing (limit of rate).
Well caught, fixed with no change sadly :( (I was tinkering with dropping a few days worth of history) |
|
Okay, I have no idea what changed, but I fully power cycled everything (inverter, battery, you name it) and now predbat is making appropriate plans again. 🤷 The flipside to this is that my battery is now stuck in fault with code Update: Fixed by resetting the battery (the how-to is tucked way deep away inside Setapp, but you hold the P-I-O switch on the battery in the P position for between 4 to 10 seconds, no less, no more - that clears faults) |
|
I probably should have been more specific earlier, as that's what I was implying by an off/on/reset. I've had that same problem a few times in the past. super annoying if it happens and you're away! but, I've only had that happen in winter, never when it was dry (my inverter and battery are outside). glad it's resolved. :) |
|
Just to put a sock in that saga: the plan was resolving in such an unusual pattern because it was reading battery_rate_max:
- sensor.solaredge_b1_max_charge_powerThis is correct - the plan was correctly planning for the fact that the available charge power during So I'm pretty sure my config is correct - maybe one to be merged into the documentation? (though @Noodleyman's workaround is interesting, I don't have to do that on my SE5000H...) |
Sounds like an automation might be required to alert if this happens again. Very bizarre. |
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Hi Trefor,
As discussed, here are the list of entities etc of the solar edge mod bus multi-integration.
`
<style> </style>The text was updated successfully, but these errors were encountered: