Solar Edge Integration - Githubissues

springfall2008 / batpred

Home battery prediction and charging automation for Home Assistant, supporting many inverter types

https://springfall2008.github.io/batpred/

94 stars 32 forks source link

Solar Edge Integration #181

Open Londonlad95 opened 8 months ago

Londonlad95 commented 8 months ago

Hi Trefor,

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

`<html xmlns:v="urn:schemas-microsoft-com:vml" xmlns:o="urn:schemas-microsoft-com:office:office" xmlns:x="urn:schemas-microsoft-com:office:excel" xmlns="http://www.w3.org/TR/REC-html40">

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

2023-10-14 15_47_48-Settings – Home Assistant and 114 more pages - Personal - Microsoft Edge 2023-10-14 15_49_37-Settings – Home Assistant and 114 more pages - Personal - Microsoft Edge 2023-10-14 15_49_52-Settings – Home Assistant and 114 more pages - Personal - Microsoft Edge

Londonlad95 commented 8 months ago

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

2023-10-14 15_53_50-Settings – Home Assistant and 114 more pages - Personal - Microsoft Edge 2023-10-14 15_54_15-

springfall2008 commented 8 months ago

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 commented 8 months ago

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 commented 8 months ago

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:

The house consumption in kWh - Givenergy calls that 'load'. This is used to predict future consumption in Predbat.
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 commented 8 months ago

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 commented 8 months ago

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 commented 8 months ago

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 commented 7 months ago

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 commented 7 months ago

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 commented 7 months ago

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 commented 5 months ago

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 commented 4 months ago

@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 commented 4 months ago

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 commented 4 months ago

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 commented 4 months ago

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 commented 4 months ago

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 commented 4 months ago

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 commented 4 months ago

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 commented 4 months ago

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 commented 4 months ago

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 commented 3 months ago

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 commented 3 months ago

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 commented 3 months ago

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 commented 3 months ago

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 commented 3 months ago

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 commented 3 months ago

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 commented 3 months ago

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 commented 3 months ago

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 commented 3 months ago

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 commented 3 months ago

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.

Noodleyman commented 3 months ago

Thought I would follow up on my efforts as I hit a couple more snags. I'm likely doing something wrong but wanted to share the experience in case there is a gap in documentation.

Firstly, I am aware that the updates i #843 caused an issue for SolarEdge config and I have applied the changes in #875 to my install. It's possible I've missed some other changes required from other threads?

I am still seeing the following error within the PredBat logs on startup:

2024-03-22 11:33:09.784235 WARNING pred_bat: ------------------------------------------------------------
2024-03-22 11:33:09.784724 WARNING pred_bat: Unexpected error in worker for App pred_bat:
2024-03-22 11:33:09.785112 WARNING pred_bat: Worker Ags: {'id': 'a67685a1ec8a4358b968f0d8e781eff0', 'name': 'pred_bat', 'objectid': 'e63d4f43bbf3455087e866ad97f58d82', 'type': 'scheduler', 'function': <bound method PredBat.update_time_loop of <predbat.PredBat object at 0xb4700bb0>>, 'pin_app': True, 'pin_thread': 0, 'kwargs': {'interval': 15, 'random_start': 0, 'random_end': 0, '__thread_id': 'thread-0'}}
2024-03-22 11:33:09.785478 WARNING pred_bat: ------------------------------------------------------------
2024-03-22 11:33:09.792103 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 "/config/apps/predbat.py", line 12650, in update_time_loop
    raise e
  File "/config/apps/predbat.py", line 12645, in update_time_loop
    self.update_pred(scheduled=False)
  File "/usr/lib/python3.11/site-packages/appdaemon/adbase.py", line 35, in f_app_lock
    return f(*args, **kw)
           ^^^^^^^^^^^^^^
  File "/config/apps/predbat.py", line 11665, in update_pred
    status, status_extra = self.execute_plan()
                           ^^^^^^^^^^^^^^^^^^^
  File "/config/apps/predbat.py", line 10466, in execute_plan
    inverter.adjust_charge_window(charge_start_time, charge_end_time, self.minutes_now)
  File "/config/apps/predbat.py", line 3610, in adjust_charge_window
    self.press_and_poll_button(entity_id)
  File "/config/apps/predbat.py", line 3643, in press_and_poll_button
    entity = self.base.get_entity(entity_id)
             ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
  File "/usr/lib/python3.11/site-packages/appdaemon/adapi.py", line 3188, in get_entity
    self._check_entity(namespace, entity)
  File "/usr/lib/python3.11/site-packages/appdaemon/utils.py", line 231, in inner_sync_wrapper
    f = run_coroutine_threadsafe(self, coro(self, *args, **kwargs))
        ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
  File "/usr/lib/python3.11/site-packages/appdaemon/utils.py", line 313, in run_coroutine_threadsafe
    result = future.result(self.AD.internal_function_timeout)
             ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
  File "/usr/lib/python3.11/concurrent/futures/_base.py", line 456, in result
    return self.__get_result()
           ^^^^^^^^^^^^^^^^^^^
  File "/usr/lib/python3.11/concurrent/futures/_base.py", line 401, in __get_result
    raise self._exception
  File "/usr/lib/python3.11/site-packages/appdaemon/adapi.py", line 588, in _check_entity
    if "." not in entity:
       ^^^^^^^^^^^^^^^^^
TypeError: argument of type 'NoneType' is not iterable

2024-03-22 11:33:09.792627 WARNING pred_bat: ------------------------------------------------------------

I've rolled back to Time of Use config for now

duckfullstop commented 3 months ago

Can you copy your relevant config yaml? If I had to guess you've got an entity either set wrong or not providing correct data (either way we might need documentation updates...)

Noodleyman commented 3 months ago

Sure, thank you. here is my apps.yaml config file. I've likely got someting wrong, but do appreciate another pair of more experienced eyes who may be able to spot the issue without hours of trial and error :)

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.solaredge_i1_ac_energy
    #- sensor.solaredge_i1_ac_energy_kwh
  import_today:
    - sensor.solaredge_m1_imported
    #- sensor.solaredge_m1_imported_kwh
  export_today:
    - sensor.solaredge_m1_exported
    #- sensor.solaredge_m1_exported_kwh
  pv_today:
    - sensor.solar_panel_production_kwh   # This is a custom sensor - see Readme on how to create or comment out
  #
  # Controls/status - must by 1 per inverter
  #
  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"

  # Can be enabled if you have a backup interface
  #inverter:
  #  has_reserve_soc: True

  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 # This is a custom sensor - see Readme on how to create or comment out
  load_power:
    - sensor.solar_house_consumption_w # This is a custom sensor - see Readme on how to create or comment out
  soc_percent:
    - sensor.solaredge_b1_state_of_energy
  soc_max:
    - sensor.solaredge_b1_maximum_energy
  # Can be enabled you have a backup interface
  #reserve:
  #  - number.solaredge_i1_backup_reserve
  charge_start_time:
   - "02:00:00"
  charge_end_time:
   - "05:00:00"
  charge_limit:
   - number.solaredge_i1_ac_charge_limit
  scheduled_charge_enable:
   - off
  scheduled_discharge_enable:
   - off
  discharge_start_time:
   - "18:30:00"
  discharge_end_time:
   - "19:00:00"

  # Services to control charging/discharging
  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"

  # Inverter max AC limit (one per inverter)
  # If you have a second inverter for PV only please add the two values together
  #inverter_limit:
  # - 3600
  # - 3600
  # 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:
   - 3670
  #  - 3670
  #
  # 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:
   - 5000
  inverter_limit_discharge:
   - 5000

  # 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:
    91 : 0.91
    92 : 0.81
    93 : 0.71
    94 : 0.62
    95 : 0.52
    96 : 0.43
    97 : 0.33
    98 : 0.24
    99 : 0.24
    100 : 0.24

  # 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
  # The regular expression (re:) makes the solcast bit optional
  # If these don't match find your own names in Home Assistant
  pv_forecast_today: re:(sensor.(solcast_|)(pv_forecast_|)forecast_today)
  pv_forecast_tomorrow: re:(sensor.(solcast_|)(pv_forecast_|)forecast_tomorrow)
  pv_forecast_d3: re:(sensor.(solcast_|)(pv_forecast_|)forecast_(day_3|d3))
  pv_forecast_d4: re:(sensor.(solcast_|)(pv_forecast_|)forecast_(day_4|d4))

  # 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: 're:(sensor.myenergi_zappi_[0-9a-z]+_charge_added_session|sensor.wallbox_portal_added_energy)'

  num_cars: 0

  # 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:
    - 're:(sensor.wallbox_portal_status_description|sensor.myenergi_zappi_[0-9a-z]+_plug_status)'
    - '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:
    - 75
  car_charging_limit:
    - 're:number.tsunami_charge_limit'
  car_charging_soc:
    - 're:sensor.tsunami_battery'

  # 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

  # 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: 're:binary_sensor.octopus_energy_intelligent_dispatching'
  octopus_ready_time: 're:time.octopus_energy_intelligent_ready_time'
  octopus_charge_limit: 're:number.octopus_energy_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: 're:(sensor.(octopus_energy_|)electricity_[0-9a-z]+_[0-9a-z]+_current_rate)'
  metric_octopus_export: 're:(sensor.(octopus_energy_|)electricity_[0-9a-z]+_[0-9a-z]+_export_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: 're:(sensor.(octopus_energy_|)electricity_[0-9a-z]+_[0-9a-z]+_current_standing_charge)'

  # 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
    - 21

  # 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

  # 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_treforsiphone12_2

  # 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
  #iboost_energy_today: 'sensor.xxxxx'
  #iboost_energy_scaling: 1.0

gcoan commented 3 months ago

charge_start_time:

"02:00:00" charge_end_time:

"05:00:00" charge_limit:

number.solaredge_i1_ac_charge_limit scheduled_charge_enable:

off scheduled_discharge_enable:

off discharge_start_time:

"18:30:00" discharge_end_time:

"19:00:00"

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:

3670
- 3670

#

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:

5000 inverter_limit_discharge:

5000

The above bits are not valid YAML. You need two spaces indented in the line before the dash

i.e.

  inverter_limit_charge:
    - 5000

not

  inverter_limit_charge:
   - 5000

By the way, you may want to extend your days_previous at the moment its weighting the same day this week, the previous week and the previous week (assuming you have enough history in home assistant). You may want to blend that with some days of the current week to get a more even average

Noodleyman commented 3 months ago

Thank you for calling out those indent issues. I did run the code through a couple of online YAML validators and neither of them reported that was an issue so I thought it was in good shape. I have fixed those two items and shall see if things are looking healthier.

I will 100% review days_previous_weight further, thank you for the advice. I had left it at the current default value from the copy/paste template.

It would be nice if days of the week could be grouped, as week day usage will be very different to weekend usage. so grouping week days and weekends would (in our case) make more sense. I've not read about this being an option yet, but that's something I'll research more. If I still have an issue I'll report back. thank you for taking the time to help a n00bie :)

Noodleyman commented 3 months ago

still seeing some oddities. I suspect it is because number.solaredge_i1_storage_discharge_limit returns "unavailable" from the modbus, but their documentation says this is expected in some cases:

https://github.com/WillCodeForCats/solaredge-modbus-multi/wiki/Template-Design-Notes

2024-03-22 13:57:03.238696 WARNING pred_bat: ------------------------------------------------------------
2024-03-22 14:40:36.313949 WARNING pred_bat: ------------------------------------------------------------
2024-03-22 14:40:36.315066 WARNING pred_bat: Unexpected error in worker for App pred_bat:
2024-03-22 14:40:36.317212 WARNING pred_bat: Worker Ags: {'id': 'b03316b5ffbd4be58166c4d675b847b2', 'name': 'pred_bat', 'objectid': '12a07a489c9b4d6d960e342bf2e280ca', 'type': 'scheduler', 'function': <bound method PredBat.run_time_loop of <predbat.PredBat object at 0xb314aa70>>, 'pin_app': True, 'pin_thread': 0, 'kwargs': {'interval': 300, 'random_start': 0, 'random_end': 0, '__thread_id': 'thread-0'}}
2024-03-22 14:40:36.318294 WARNING pred_bat: ------------------------------------------------------------
2024-03-22 14:40:36.325933 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 "/config/apps/predbat.py", line 12672, in run_time_loop
    raise e
  File "/config/apps/predbat.py", line 12668, 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 "/config/apps/predbat.py", line 11665, in update_pred
    status, status_extra = self.execute_plan()
                           ^^^^^^^^^^^^^^^^^^^
  File "/config/apps/predbat.py", line 10600, in execute_plan
    inverter.adjust_discharge_rate(inverter.battery_rate_max_discharge * MINUTE_WATT)
  File "/config/apps/predbat.py", line 2925, in adjust_discharge_rate
    self.write_and_poll_value("discharge_rate", entity, new_rate, fuzzy=(self.battery_rate_max_discharge * MINUTE_WATT / 25))
  File "/config/apps/predbat.py", line 3036, in write_and_poll_value
    matched = abs(float(current_state) - new_value) <= fuzzy
                  ^^^^^^^^^^^^^^^^^^^^
ValueError: could not convert string to float: 'unavailable'

2024-03-22 14:40:36.328391 WARNING pred_bat: ------------------------------------------------------------

Noodleyman commented 3 months ago

ok, so here's a silly thing to add to the docs... If you've previously been using the Solar Edge monitoring platform, and/or you manage your own storage profiles then you need to make sure the only applicable profile is "Max Self Consumption".

the SE platform will overwrite the config in place. I've a variety of seasonal profiles with schedules setup which seems to modify the ModBus module back to "time of use" from "remote control", thus why the entities are now unavailable.

SE online platform -> Site Admin -> Energy Manager: set to Maximize self-consumption

duckfullstop commented 3 months ago

@Noodleyman

  # Inverter type stubbed to SX4 to allow execution - SE is an invalid type in current head version
  inverter_type: "SX4"
  #inverter_type: "SE"

The latest revisions (since v7.16.5) use the SE inverter type - so flip the commented line!

- inverter_type: "SX4"
+ #inverter_type: "SX4"

- #inverter_type: "SE"
+ inverter_type: "SE"

(and also check that you have the custom sensors available and reporting in HA)

I think some better setup docs (probably with a walk-through) specifically for SE users would be a good idea because there's seemingly tonnes of little gotchas / pitfalls that are easy to fall down. I might be able to spend a bit of time on it at some point over the coming week, but if someone else wants to tackle it then go for it!

Noodleyman commented 3 months ago

Ah ha! inverter type. I hadn't realised that had changed between versions. Thank you, will try that as well. I was still getting issues with the earlier changes. I ran out of time to experiment today, so will likely play with this again next week. Thank you for your feedback, I really do appreciate you taking the time :)

gcoan commented 3 months ago

I think some better setup docs (probably with a walk-through) specifically for SE users would be a good idea because there's seemingly tonnes of little gotchas / pitfalls that are easy to fall down.

I've been working to improve and deepen the Predbat documentation and am happy to help merge what ever text is produced into the documentation and sample apps.yaml, but it needs to be written by someone who has a Solax inverter as mine are GivEnergy!

A step by step would be a good idea. The install instructions are at the moment centred on GivEnergy, they make a nod to the different dependent inverter control software but there's no real detail on these as no-one has written it.

As much as possible I am aiming to have just one set of comprehensive Predbat documentation (and ultimately apps.yaml file) rather than having different forks and variants for different setups and inverters. Not to say that we can't have specific documentation for specific inverters but this is a clear 'side street' rather than a different 'main road'. This should make it much easier to maintain and control going forward and ensures that things don't get missed out - having 3 or 4 different template apps.yaml's for example means new features are easy to miss getting added. If we can have 1 consolidated file with sections for the different inverters it'll make it much clearer.

Noodleyman commented 3 months ago

I managed to find a little time this morning over a coffee to review the inverter_type change. It does appear this was the last piece of the puzzle. with this changed things now seem to be behaving (at least so far today). I'll keep an eye on it but after a few hours it does appear to be working without errors. Exciting times, special thanks to you all for helping out and checking my config. I doubt I would have got it working without your input. I really do appreciate it.

Noodleyman commented 3 months ago

I thought I would share another "gotcha" when setting up for SolarEdge, in case anybody else wonders or has the same concern.

I use various seasonal profiles to manage the SE system from the online monitoring platform. When setting up the Modbus module it is required to be in "Remote Control" mode to update some of the entities PredBat requires. If in any other mode, those entities have "undefined" values.

So, in my case I kept it as "time of use" and left PredBat to learn my usage. However, this has caused issues with the data it collected as dueing battery charge events, or export battery to grid events the "undefined" entities are a problem. IE, PredBat doesn't see the event... so currently, all of my overnight battery charge windows (somewhere between 2-5AM for Octopus Flux) are reporting 0kWh load predicted.

in my case, I didn't want to run the system until it had learnt my usage patterns, but to learn the usage pattersn you have to give up your existing profiles.. So there will be a period of disruption to normal usage whilst the system gets up to speed. It might be a good idea to have SE systems use a different config for days_previous for the first week or so (learn from previous day etc), then evolve it into a more deep config as data is accumulated.

The other oddity, is if you do not change "SE online platform -> Site Admin -> Energy Manager: set to Maximize self-consumption" then the online monitor platform will change your modbus mode from remote control to "time of use" at the time of your next profile scheduled event, which in turn makes those entities unavaialble again and predbat can't learn your usage... (URG!).

So you have to give PredBat full control of the system (with read only enabled) at the very start and give up the schedules to do a nice cutover.

LupoLoopy commented 3 months ago

To feedback, I've got this working on my setup nicely.

I have however seen a new issue. Specifically, the minimum battery charge variables are not being honoured for my SE setup, it having driven the battery down to zero.

This error was showing in the logbook at the time- not sure if it's relevant:

Status changed to ERROR: Exception raised argument of type 'NoneType' is not iterable

Where do the richer logs live, so I can take a look so I might feedback in more fully please.

gcoan commented 3 months ago

yes that is relevant, Predbat crashed

Logfile location is covered in the documentation:

https://springfall2008.github.io/batpred/output-data/#predbat-logfile

Noodleyman commented 3 months ago

I also wanted to follow up to confirm after the recent recommended changes, things see to be working correctly. thank you!

time to tune the forecasts :)

springfall2008 commented 3 months ago

@Noodleyman are there any changes I need to roll back into Predbat?

Can you share your final config.yaml so I can put it into Predbat as a template? Some words with this on how to set things up would be very useful for other users.

Noodleyman commented 3 months ago

Good morning @springfall2008 , below is my existing apps.yaml config from my working configuration on version 7.16.8 of PredBat, with the change noted in #875 manually applied to predbat.py. Sharing what I can now, but have limited time this week for any further details.

I am using:

Octopus Energy addon in Home Assistant, and we are on Octopus Flux
Solcast for PV forecast
Using an SE6000H inverer (upgrading to SE8000H shortly), with 11.07kWp (upgrading to 15 shortly) and a single 10kWh battery
I have an enforced export limit of 3.68kWh (legal in allowed by DNO in the UK)
I do not have an electric vehicle so have EV related stuff disabled

I will screen dump some screen shots of my other config below (I am still adjusting these, but they are working for now). I have very limited time to play with it this week :(

Config:

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.solaredge_i1_ac_energy
    #- sensor.solaredge_i1_ac_energy_kwh
  import_today:
    - sensor.solaredge_m1_imported
    #- sensor.solaredge_m1_imported_kwh
  export_today:
    - sensor.solaredge_m1_exported
    #- sensor.solaredge_m1_exported_kwh
  pv_today:
    - sensor.solar_panel_production_kwh   # This is a custom sensor - see Readme on how to create or comment out
  #
  # Controls/status - must by 1 per inverter
  #
  num_inverters: 1
  # Inverter type stubbed to SX4 to allow execution - SE is an invalid type in current head version
  inverter_type: "SE"

  # Can be enabled if you have a backup interface
  #inverter:
  #  has_reserve_soc: True

  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 # This is a custom sensor - see Readme on how to create or comment out
  load_power:
    - sensor.solar_house_consumption_w # This is a custom sensor - see Readme on how to create or comment out
  soc_percent:
    - sensor.solaredge_b1_state_of_energy
  soc_max:
    - sensor.solaredge_b1_maximum_energy
  # Can be enabled you have a backup interface
  #reserve:
  #  - number.solaredge_i1_backup_reserve
  charge_start_time:
   - "02:00:00"
  charge_end_time:
   - "05:00:00"
  charge_limit:
   - number.solaredge_i1_ac_charge_limit
  scheduled_charge_enable:
   - off
  scheduled_discharge_enable:
   - off
  discharge_start_time:
   - "18:30:00"
  discharge_end_time:
   - "19:00:00"

  # Services to control charging/discharging
  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"

  # Inverter max AC limit (one per inverter)
  # If you have a second inverter for PV only please add the two values together
  #inverter_limit:
  # - 3600
  # - 3600
  # 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:
    - 3670
  #  - 3670
  #
  # 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:
    - 5000
  inverter_limit_discharge:
    - 5000

  # 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:
    91 : 0.91
    92 : 0.81
    93 : 0.71
    94 : 0.62
    95 : 0.52
    96 : 0.43
    97 : 0.33
    98 : 0.24
    99 : 0.24
    100 : 0.24

  # 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
  # The regular expression (re:) makes the solcast bit optional
  # If these don't match find your own names in Home Assistant
  pv_forecast_today: re:(sensor.(solcast_|)(pv_forecast_|)forecast_today)
  pv_forecast_tomorrow: re:(sensor.(solcast_|)(pv_forecast_|)forecast_tomorrow)
  pv_forecast_d3: re:(sensor.(solcast_|)(pv_forecast_|)forecast_(day_3|d3))
  pv_forecast_d4: re:(sensor.(solcast_|)(pv_forecast_|)forecast_(day_4|d4))

  # 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: 're:(sensor.myenergi_zappi_[0-9a-z]+_charge_added_session|sensor.wallbox_portal_added_energy)'

  num_cars: 0

  # 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:
    - 're:(sensor.wallbox_portal_status_description|sensor.myenergi_zappi_[0-9a-z]+_plug_status)'
    - '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:
    - 75
  car_charging_limit:
    - 're:number.tsunami_charge_limit'
  car_charging_soc:
    - 're:sensor.tsunami_battery'

  # 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

  # 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: 're:binary_sensor.octopus_energy_intelligent_dispatching'
  octopus_ready_time: 're:time.octopus_energy_intelligent_ready_time'
  octopus_charge_limit: 're:number.octopus_energy_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: 're:(sensor.(octopus_energy_|)electricity_[0-9a-z]+_[0-9a-z]+_current_rate)'
  metric_octopus_export: 're:(sensor.(octopus_energy_|)electricity_[0-9a-z]+_[0-9a-z]+_export_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: 're:(sensor.(octopus_energy_|)electricity_[0-9a-z]+_[0-9a-z]+_current_standing_charge)'

  # 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
    - 21

  # 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
    - 0.75
    - 0.5
    - 0.25

  # 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_treforsiphone12_2

  # 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
  #iboost_energy_today: 'sensor.xxxxx'
  #iboost_energy_scaling: 1.0

SolarEdge Monitoring Platform Config Note: I have an installer account whic may open up more options than others. If you need one, raise a support case with SolarEdge support and tell them you are a self-installer who wants full control of your own system

SolarEdge Modbus Multi: MUST BE IN REMOTE CONTROL MODE (See my notes earlier in this thread for GOTCHAS), and in this screen shot the battery was charting / being held at 100% at the time

PredBat Switches:

PredBat Input Variables: Note: SE kit is very effecient compared to others. If you check out their effeciency charts you can expect over 99.x% effeicnecy from PV. battery however is around 94.5 - 95% because of the 400v. I have added 10% load scaling (I think I eat power, so have upscaled it to be cautious), and I have scaled my PV by 10%, although I will likely change this to about 3-5% later. It will all change when I upgrade the system within the next few weeks.

marlon89br commented 3 months ago

@duckfullstop mentioned their predictions were very pessimistic and I was observing the same thing on my setup. I think I figured it out… the load_today variable is set to the inverter AC load, and what I observe in my setup is that it includes both import and export, so my load was massively overestimated now that I’m away on holiday. I changed it to the template sensor solar_house_consumption_kwh that I got with the other custom sensors and it looks sensible now.

Noodleyman commented 3 months ago

Thank you @marlon89br , I was just looking into the same kind of issue and think you're suggestion will fix it. I've been seeing my expected daily usage over estimate, because the exports are going up.

I had to start over, because my home assistant instance entirely died a week ago, so had to restore which meant I lost some data :/ so am playing catchup now.

marlon89br commented 3 months ago

Hopefully that fixes it for you. I’ll also keep an eye out when I come back home if it tracks the actual house load, but looking at the historical data that looks like the right sensor.

I guess if you confirm it working as well we can update the template.

On Tue, 2 Apr 2024 at 18:51, Noodleyman @.***> wrote:

Thank you @marlon89br https://github.com/marlon89br , I was just looking into the same kind of issue and think you're suggestion will fix it. I've been seeing my expected daily usage over estimate, because the exports are going up.

I had to start over, because my home assistant instance entirely died a week ago, so had to restore which meant I lost some data :/ so am playing catchup now.

— Reply to this email directly, view it on GitHub https://github.com/springfall2008/batpred/issues/181#issuecomment-2031837015, or unsubscribe https://github.com/notifications/unsubscribe-auth/AACTZJ4GK2C7BXJVSKBCDDLY3KLUNAVCNFSM6AAAAAA6AJYZTOVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDAMZRHAZTOMBRGU . You are receiving this because you were mentioned.Message ID: @.***>