Solar Edge Integration

[Londonlad95]

Hi Trefor,

As discussed, here are the list of entities etc of the solar edge mod bus multi-integration.

`

Name	Full Name
Solaredge B1 Maximum Energy	sensor.solaredge_b1_maximum_energy
Solaredge B1 State of Energy	sensor.solaredge_b1_state_of_energy
Solaredge B1 State of Health	sensor.solaredge_b1_state_of_health
Solaredge B1 Status	sensor.solaredge_b1_status
Solaredge B1 Version	sensor.solaredge_b1_version
Solaredge I2 AC Charge Limit	number.solaredge_i2_ac_charge_limit
Solaredge I2 AC Charge Policy	select.solaredge_i2_ac_charge_policy
Solaredge I2 AC Current	sensor.solaredge_i2_ac_current
Solaredge I2 AC Energy kWh	sensor.solaredge_i2_ac_energy_kwh
Solaredge I2 AC Frequency	sensor.solaredge_i2_ac_frequency
Solaredge I2 AC Power	sensor.solaredge_i2_ac_power
Solaredge I2 AC Voltage AB	sensor.solaredge_i2_ac_voltage_ab
Solaredge I2 Active Power Limit	sensor.solaredge_i2_active_power_limit
Solaredge I2 Active Power Limit	number.solaredge_i2_active_power_limit
Solaredge I2 Advanced Power Control	binary_sensor.solaredge_i2_advanced_power_control
Solaredge I2 Backup Reserve	number.solaredge_i2_backup_reserve
Solaredge I2 DC Current	sensor.solaredge_i2_dc_current
Solaredge I2 DC Power	sensor.solaredge_i2_dc_power
Solaredge I2 DC Voltage	sensor.solaredge_i2_dc_voltage
Solaredge I2 Device	sensor.solaredge_i2_device
Solaredge I2 Grid Control	switch.solaredge_i2_grid_control
Solaredge I2 Refresh	button.solaredge_i2_refresh
Solaredge I2 RRCR Status	sensor.solaredge_i2_rrcr_status
Solaredge I2 Status	sensor.solaredge_i2_status
Solaredge I2 Status Vendor	sensor.solaredge_i2_status_vendor
Solaredge I2 Storage Charge Limit	number.solaredge_i2_storage_charge_limit
Solaredge I2 Storage Command Mode	select.solaredge_i2_storage_command_mode
Solaredge I2 Storage Command Timeout	number.solaredge_i2_storage_command_timeout
Solaredge I2 Storage Control Mode	select.solaredge_i2_storage_control_mode
Solaredge I2 Storage Default Mode	select.solaredge_i2_storage_default_mode
Solaredge I2 Storage Discharge Limit	number.solaredge_i2_storage_discharge_limit
Solaredge I2 Temp Sink	sensor.solaredge_i2_temp_sink
Solaredge I2 Version	sensor.solaredge_i2_version
Solaredge M1 AC Current	sensor.solaredge_m1_ac_current
Solaredge M1 AC Current A	sensor.solaredge_m1_ac_current_a
Solaredge M1 AC Current B	sensor.solaredge_m1_ac_current_b
Solaredge M1 AC Current C	sensor.solaredge_m1_ac_current_c
Solaredge M1 AC Frequency	sensor.solaredge_m1_ac_frequency
Solaredge M1 AC Power	sensor.solaredge_m1_ac_power
Solaredge M1 AC Power A	sensor.solaredge_m1_ac_power_a
Solaredge M1 AC Power B	sensor.solaredge_m1_ac_power_b
Solaredge M1 AC Power C	sensor.solaredge_m1_ac_power_c
Solaredge M1 AC Voltage AB	sensor.solaredge_m1_ac_voltage_ab
Solaredge M1 AC Voltage AN	sensor.solaredge_m1_ac_voltage_an
Solaredge M1 AC Voltage BC	sensor.solaredge_m1_ac_voltage_bc
Solaredge M1 AC Voltage BN	sensor.solaredge_m1_ac_voltage_bn
Solaredge M1 AC Voltage CA	sensor.solaredge_m1_ac_voltage_ca
Solaredge M1 AC Voltage CN	sensor.solaredge_m1_ac_voltage_cn
Solaredge M1 AC Voltage LL	sensor.solaredge_m1_ac_voltage_ll
Solaredge M1 AC Voltage LN	sensor.solaredge_m1_ac_voltage_ln
Solaredge M1 Device	sensor.solaredge_m1_device
Solaredge M1 Exported A kWh	sensor.solaredge_m1_exported_a_kwh
Solaredge M1 Exported B kWh	sensor.solaredge_m1_exported_b_kwh
Solaredge M1 Exported C kWh	sensor.solaredge_m1_exported_c_kwh
Solaredge M1 Exported kWh	sensor.solaredge_m1_exported_kwh
Solaredge M1 Imported A kWh	sensor.solaredge_m1_imported_a_kwh
Solaredge M1 Imported B kWh	sensor.solaredge_m1_imported_b_kwh
Solaredge M1 Imported C kWh	sensor.solaredge_m1_imported_c_kwh
Solaredge M1 Imported kWh	sensor.solaredge_m1_imported_kwh
Solaredge M1 Meter Events	sensor.solaredge_m1_meter_events
Solaredge M1 Version	sensor.solaredge_m1_version

`

[Londonlad95]

I forgot to include the modbus device entities on the front end; here they are.

[springfall2008]

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?

[Londonlad95]

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.

[springfall2008]

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:

1. The house consumption in kWh - Givenergy calls that 'load'. This is used to predict future consumption in Predbat.
2. The amount of Solar energy produced in kWh so far.

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:

https://github.com/springfall2008/batpred/tree/solar_edge

[Londonlad95]

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.

[springfall2008]

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:

• Copy the the solaredge.yaml from here: https://github.com/springfall2008/batpred/blob/solar_edge/solaredge.yaml and overwrite config/appdaemon/apps/batpred/config/apps.yaml with this version.
• Copy the beta version of Predbat from here: https://github.com/springfall2008/batpred/blob/solar_edge/apps/predbat/predbat.py into config/appdaemon/apps/batpred/predbat.py

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:

logs:
  main_log: 
    filename: /config/appdaemon.log
    log_size: 10000000

[RobinXe]

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.

[fboundy]

Hi - I'm helping Trefor out with adding additional inverter brands. In addition to the above can you answer the following please?

• What format are the charge/discharge start/end entities? (i.e to they take a string as HH:MM(Givenerrgy) or are there separate entities for Hours and Minutes (Solis)
• Once you have set the start/end time entities, do they automatically get written to the inverter or do you have to press a button?
• Do you set Power or Current during a timed Charge/Discharge?
• Can you set a Target SOC for a timed charge or discharge period?
• Does the inverter report SOC in kWh or Percent?
• Is there a specific boolean entity to toggle to enable Timed Charge and/or Discharge?
• Can you set a Reserve or Backup SOC?
• Does the inverter have a specific Mode that needs setting for Timed Charge, Discharge or Backup?

[RobinXe]

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.

[fboundy]

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: @.***>

[Arachnid]

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.

[springfall2008]

@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?

[LupoLoopy]

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: ------------------------------------------------------------ 2024-02-12 23:45:09.618585 WARNING pred_bat: ------------------------------------------------------------ 2024-02-12 23:45:09.618916 WARNING pred_bat: Unexpected error in worker for App pred_bat: 2024-02-12 23:45:09.619220 WARNING pred_bat: Worker Ags: {'id': 'ef2f4d5f90f64a03b5644ab5fb85f01d', 'name': 'pred_bat', 'objectid': '33dccc4036124d8fba34c5e3b1505d40', 'type': 'scheduler', 'function': <bound method PredBat.run_time_loop of <predbat.PredBat object at 0x7f04675b5a50>>, 'pin_app': True, 'pin_thread': 0, 'kwargs': {'interval': 300, 'random_start': 0, 'random_end': 0, '__thread_id': 'thread-0'}} 2024-02-12 23:45:09.619443 WARNING pred_bat: ------------------------------------------------------------ 2024-02-12 23:45:09.621130 WARNING pred_bat: Traceback (most recent call last): File "/usr/lib/python3.11/site-packages/appdaemon/threading.py", line 1022, in worker funcref(self.AD.sched.sanitize_timer_kwargs(app, args["kwargs"])) File "/usr/lib/python3.11/site-packages/appdaemon/adbase.py", line 35, in f_app_lock return f(*args, **kw) ^^^^^^^^^^^^^^ File "/homeassistant/appdaemon/apps/batpred/predbat.py", line 12119, in run_time_loop raise e File "/homeassistant/appdaemon/apps/batpred/predbat.py", line 12115, in run_time_loop self.update_pred(scheduled=True) File "/usr/lib/python3.11/site-packages/appdaemon/adbase.py", line 35, in f_app_lock return f(*args, **kw) ^^^^^^^^^^^^^^ File "/homeassistant/appdaemon/apps/batpred/predbat.py", line 11122, in update_pred self.fetch_inverter_data() File "/homeassistant/appdaemon/apps/batpred/predbat.py", line 10694, in fetch_inverter_data inverter = Inverter(self, id) ^^^^^^^^^^^^^^^^^^ File "/homeassistant/appdaemon/apps/batpred/predbat.py", line 1081, in init self.inv_has_rest_api = INVERTER_DEF[self.inverter_type]["has_rest_api"] ~~~~~~~~~~~~^^^^^^^^^^^^^^^^^^^^ KeyError: 'SE'

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.

[LupoLoopy]

You can set a backup reserve, in %age.

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.

[RobinXe]

You can set a backup reserve, in %age.

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.

[duckfullstop]

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 sensor.solar_panel_production_w, sensor.solar_panel_production_daily, and sensor.solar_house_consumption_w) are calculated using template sensors, available here: https://github.com/ryanm101/hasolarcfg. Note that the aforementioned beta branch has been removed, so this uses the current stable build.

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_reserve

Control 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.

[marlon89br]

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.

[springfall2008]

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:

  pv_today:
    - sensor.solar_panel_production_kwh   # This is a custom sensor - documentation TBD

And this stuff you may want to add:

  charge_start_time:
   - "00:00:00"
  charge_end_time:
   - "00:01:00"
  charge_limit:
   - number.solaredge_i2_ac_charge_limit
  scheduled_charge_enable:
   - off
  scheduled_discharge_enable:
   - off
  discharge_start_time:
   - "00:00:00"
  discharge_end_time:
   - "00:01:00"

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?

[duckfullstop]

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 Consumption

All commands are targetted at the i1 device (the inverter).

Here are the valid modes for select.solaredge_i1_storage_command_mode / select.solaredge_i1_storage_default_mode, defined in the solaredge specification:

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 Mode

The control flow as discussed in https://github.com/springfall2008/batpred/issues/181#issuecomment-1798864049 is correct as far as I'm aware. storage_default_mode stays active until otherwise changed, storage_command_mode applies for number.solaredge_i1_storage_command_timeout seconds.

There's a couple of differences, this is probably another template:

 pv_today:
   - sensor.solar_panel_production_kwh   # This is a custom sensor - documentation TBD

This is likely https://gist.github.com/Ashpork/f80fb0d3cb22356a12ed24734065061c

---

One other thing: your extra config calls out number.solaredge_i2_ac_charge_limit - it may be pertinent to change to i1 as most setups use one inverter. See https://github.com/WillCodeForCats/solaredge-modbus-multi/wiki/Power-Control-Options-%E2%80%90-Configuration#ac-charge-policy for more information on this functionality.

[Londonlad95]

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.

[springfall2008]

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?

[duckfullstop]

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:

• INFO pred_bat: WARN: Inverter 0 Trying to write 4.0 to reserve didn't complete got 0 (where reserve is number.solaredge_i1_backup_reserve)
  • presumably this is an issue with the backup reserve setting as previously discussed, if I had to guess this is because we don't have a backup interface available on the modbus, so the inverter just ignores related commands.
  • Disabled by setting has_reserve_soc on the appropriate object to False for the interim.
  • This appears to potentially be affecting the charge / discharge rate registers too - requires investigation.
• Maximize Self Consumption may be a better default mode than Charge from Solar Power, which inhibits discharge for house load.
  • MSC allows charge and discharge as appropriate based on house load / PV production
  • Charge from Solar Power is the effective equivalent of Freeze Charge mode
  • Discharge to Minimize Import is the effective equivalent of Freeze Discharge mode
• discharge_stop_service - should we be setting this in config?
• Services call storage_command_mode by default, which is probably a good move as after the timeout it'll revert to the default mode - which means if predbat stops talking to the inverter for some reason it can use a sane default (like Maximize Self Consumption).
  • May be worth calling out an appropriate change to number.solaredge_i1_storage_command_timeout(3600 seconds is default, sounds sane?) in the documentation if this behaviour is indeed desired.
• Power Control Options, as well as Enable Battery Control, must be enabled in the Solaredge Modbus Multi integration configuration, and switch.solaredge_i1_advanced_power_control must be on.

Happy to contribute / flesh out setup documentation if it'd help!

[springfall2008]

Great news, please review my pull request that is now updated: https://github.com/springfall2008/batpred/pull/817/files

• I change the i2 to i1 in the template and cleaned it up a little
• I added documentation, please review and comment
• I changed the stop method to Maximise Self Consumption
• I also updated predbat so the inverter configuration options inside predbat.py can be overridden inside apps.yaml if need be, this can allow others to create new integrations quickly

Once we are happy with this and its merged I can look at charge and discharge freeze modes.

[duckfullstop]

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?

[Noodleyman]

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:

• Return bad float value unavailable from charge_rate

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.

  charge_rate:
    - number.solaredgemodbus_i1_storage_charge_limit
  discharge_rate:
    - number.solaredgemodbus_i1_storage_discharge_limit

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.

[gcoan]

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

[Noodleyman]

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

Good Morning, thank you for the feedback, very helpful. as you hit reply I had just finished opening a bug for this here: https://github.com/WillCodeForCats/solaredge-modbus-multi/issues/561

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.

[Noodleyman]

I figured it out. if the mode isnt set to "Remote Control" it won't populate those values. I had it still set to a time based plan. once it was changed it worked correctly.

I did notice however a miss in the templates for the SE inverter. the following should be added to allow Octopus saving sessions to be used

  # Octopus saving session points to the saving session Sensor in the Octopus plugin, when enabled saving sessions will be at the assumed
  # Rate is read automatically from the add-in and converted to pence using the conversion rate below (default is 8)
  octopus_saving_session: 're:(binary_sensor.octopus_energy([0-9a-z_]+|)_saving_session(s|))'
  octopus_saving_session_octopoints_per_penny:8

[gcoan]

I figured it out. if the mode isnt set to "Remote Control" it won't populate those values. I had it still set to a time based plan. once it was changed it worked correctly.

I did notice however a miss in the templates for the SE inverter. the following should be added to allow Octopus saving sessions to be used

  # Octopus saving session points to the saving session Sensor in the Octopus plugin, when enabled saving sessions will be at the assumed
...

Ah great. If there's extra guidance needed to the documentation please let me know and I'll add it in.

Yes the apps.yaml for the different inverter varieties is a problem because new features are not always copied into all the different configuration files. As part of documentation overhaul I'm planning on restructuring apps.yaml to better follow the documentation and also try to merge them into just one version that can be edited to be suitable for all the different inverter types that predbat supports

Geoffrey

[Noodleyman]

it appears there is a depenency on the option being "Remote Control", but for me, I wanted things to be essentially in read only mode, and left alone until my config is dialed in and I know it is good to cut over. the entities are only populated when it is in read only mode, thus... one or the other. It may be worth at least keeping the content in the file but commented out with a note to review, and the docs for SE may need a referecne to say that remote control mode is needed. it wasn't clear to me this was required, I only figured it out with a source code review.

as I am porting from the SE online platform, I'm coming from several seasonal profiles setup by date range, so it makes sense that this setting needs to be changed. I suspect this would be common of a lot of SE users.