'NoneType' object has no attribute 'split' after updating to v8.30.6

[DFEvans]

Describe the bug
After upgrading from v8.30.2 to v8.30.6, Predbat outputs the following error after each planning run, and fails to complete most of its activities afterwards (outputting to various entities, controlling the inverter, etc.):

42877 | 2025-12-24 20:50:05.935448:  Error: 'NoneType' object has no attribute 'split'
-- | --
42876 | 2025-12-24 20:50:05.935265:  Info: record_status Error: Exception raised 'NoneType' object has no attribute 'split'
42874 | AttributeError: 'NoneType'  object has no attribute 'split'
42873 | ^ ^^^^^^^^^^^^^^
42872 | domain, entity_name = e ntity_id.split(".")
42871 | File "/config/inverter.py ", line 1475, in write_and_poll_value
42870 | self.write_and_poll_val ue("charge_limit", self.base.get_arg("charge_limit", indirect=False, index=self.id, required_unit="%"), soc)
42869 | File "/config/inverter.py ", line 1404, in adjust_battery_target
42868 | inverter.adjust_battery _target(new_soc_percent, is_charging, is_exporting)
42867 | File "/config/execute.py" , line 639, in adjust_battery_target_multi
42866 | self.adjust_battery_tar get_multi(inverter, 0, isCharging, isExporting)
42865 | File "/config/execute.py" , line 565, in execute_plan
42864 | ^^^^^^^^^^^^^^^^^^^
42863 | status, status_extra =  self.execute_plan()
42862 | File "/config/predbat.py" , line 726, in update_pred
42861 | self.update_pred(schedu led=True)
42860 | File "/config/predbat.py" , line 1594, in run_time_loop
42859 | 2025-12-24 20:50:05.917186:  Error: Traceback (most recent call last):
42858 | 2025-12-24 20:50:05.913787:  Error: Exception raised 'NoneType' object has no attribute 'split'

The issue persists after a full restart of my HA server and hence Predbat. The issue doesn't reoccur after downgrading to v8.30.2.

Glancing at the lines of code in the traceback, the top-level issue seems to be not knowing the entity ID for charge_limit. That's defined as this in my apps.yaml which hasn't changed lately, and is apparently OK in v8.30.2:

  charge_rate:
    - input_number.charge_rate

So I suspect it's some underlying problem (or my config is janky and Predbat's now less tolerant).

Predbat version

v8.30.7

Environment details

Standard HAOS install

Log file
predbat(2).log

[gcoan]

charge_rate:
- input_number.charge_rate
So I suspect it's some underlying problem (or my config is janky and Predbat's now less tolerant).

can you include your complete apps.yaml or debug file please.

The error seems to be related to charge_limit not charge_rate

[DFEvans]

Apologies, reading comprehension impacted after some Christmas Eve drinks!

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

  # Timezone to work in
  timezone: Europe/London

  # XXX: Template configuration, delete this line once you have set up for your system
#  template: True

  # If you are using Predbat outside of HA then set the HA URL and Key (long lived access token here)
  #ha_url: 'http://homeassistant.local:8123'
  #ha_key: 'xxx'

  # Currency, symbol for main currency second symbol for 1/100s e.g. $ c or £ p or e c
  currency_symbols:
    - '£'
    - 'p'

  # Number of threads to use in plan calculation
  # Can be auto for automatic, 0 for off or values 1-N for a fixed number
  threads: auto

  #
  # 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.
  #
  inverter_type: "SIG"
  num_inverters: 1
  #
  # Controls/status - must by 1 per inverter
  #
  load_today:
    - sensor.sigen_plant_daily_load_consumption 
  import_today:
    - sensor.sigen_plant_daily_grid_import_energy
  export_today:
    - sensor.sigen_plant_daily_grid_export_energy
  pv_today:
    - sensor.sigen_plant_daily_pv_energy

  charge_rate:
    - input_number.charge_rate
  discharge_rate:
    - input_number.discharge_rate
  battery_power:
    - sensor.sigen_plant_battery_power
  pv_power:
    - sensor.sigen_plant_pv_power
  load_power:
    - sensor.sigen_plant_consumed_power
  grid_power:
    - sensor.sigen_plant_grid_active_power

  battery_power_invert: true
  grid_power_invert: true
  support_discharge_freeze: true

  soc_percent:
    - sensor.sigen_plant_battery_state_of_charge
  soc_kw:
    - sensor.sigen_plant_available_max_discharging_capacity
  soc_max:
    - sensor.sigen_plant_rated_energy_capacity
  battery_temperature:
    - sensor.sigen_inverter_battery_average_cell_temperature

  # Services to control the inverter
  charge_start_service:
    - service: input_select.select_option
      entity_id: input_select.predbat_requested_mode
      option: "Charging"
  charge_stop_service:
    - service: input_select.select_option
      entity_id: input_select.predbat_requested_mode
      option: "Demand"
  discharge_start_service:
    - service: input_select.select_option
      entity_id: input_select.predbat_requested_mode
      option: "Discharging"
  charge_freeze_service:
    - service: input_select.select_option
      entity_id: input_select.predbat_requested_mode
      option: "Freeze Charging"
  discharge_freeze_service:
    - service: input_select.select_option
      entity_id: input_select.predbat_requested_mode
      option: "Freeze Discharging"

  # Inverter max AC limit (one per inverter)
  # If you have a second inverter for PV only please add the two values together
  inverter_limit: 12000

  # Set the maximum charge/discharge rate of the battery
  battery_rate_max: 13200

  # Export limit is a software limit set on your inverter that prevents exporting above a given level
  # When enabled Predbat will model this limit
  #export_limit:
  #  - 3600
  #  - 3600
  #
  # The maximum rate the inverter can charge and discharge the battery can be overwritten, this will change
  # the register programming and thus cap the max rates. The default is to use the maximum supported rates (recommended)
  #
  #inverter_limit_charge:
  #  - 4000
  #inverter_limit_discharge:
  #  - 4000

  # 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:
  #  - 100

  # 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:
   54 : 1.00
   55 : 0.97
   56 : 0.96
   57 : 0.94
   58 : 0.92
   59 : 0.90
   60 : 0.88
   61 : 0.86
   62 : 0.83
   63 : 0.82
   64 : 0.81
   65 : 0.79
   66 : 0.74
   67 : 0.67
   68 : 0.63
   69 : 0.63
   70 : 0.64
   71 : 0.63
   72 : 0.63
   73 : 0.64
   74 : 0.65
   75 : 0.66
   76 : 0.65
   77 : 0.65
   78 : 0.65
   79 : 0.64
   80 : 0.64
   81 : 0.64
   82 : 0.64
   83 : 0.63
   84 : 0.61
   85 : 0.60
   86 : 0.59
   87 : 0.59
   88 : 0.59
   89 : 0.60
   90 : 0.59
   91 : 0.57
   92 : 0.46
   93 : 0.40
   94 : 0.36
   95 : 0.35
   96 : 0.34
   97 : 0.34
   98 : 0.34
   99 : 0.24
   100: 0.18

  battery_discharge_power_curve:
   0  : 0.49
   1  : 0.51
   2  : 0.67
   3  : 0.71
   4  : 0.74
   5  : 0.77
   6  : 0.80
   7  : 0.83
   8  : 0.85
   9  : 0.86
   10 : 0.88
   11 : 0.89
   12 : 0.89
   13 : 0.90
   14 : 0.92
   15 : 0.94
   16 : 0.94
   17 : 0.95
   18 : 0.96
   19 : 0.97
   20 : 1.00

  # 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

  # Solcast cloud interface, set this or the local interface below
  #solcast_host: 'https://api.solcast.com.au/'
  #solcast_api_key: 'xxxx'
  #solcast_poll_hours: 8

  # Set these to match solcast sensor names if not using the cloud interface
  # 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'

  # If you have Octopus Intelligent Go and are not using the Octopus Direct connection method, 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 the intelligent slot from the Octopus Energy integration
  # octopus_intelligent_slot: 're:(binary_sensor.octopus_energy([0-9a-z_]+|)_intelligent_dispatching)'
  # octopus_ready_time: 're:((select|time).octopus_energy_([0-9a-z_]+|)_intelligent_target_time)'
  # octopus_charge_limit: 're:(number.octopus_energy([0-9a-z_]+|)_intelligent_charge_target)'

  # Carbon Intensity data from National grid
  # carbon_intensity: 're:(sensor.carbon_intensity_uk)'

  # Example alternative configuration for Ohme integration release >=v0.6.1
  #octopus_intelligent_slot: 'binary_sensor.ohme_slot_active'
  #octopus_ready_time: 'time.ohme_target_time'
  #octopus_charge_limit: 'number.ohme_target_percent'

  # Set this to False if you use Octopus Intelligent slot for car planning but when on another tariff e.g. Agile
  #octopus_slot_low_rate: False

  # 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

  # 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
  # See the 'energy rates' part of the documentation for instructions on how to find the correct URL for your tariff and DNO region
  #
  # 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-24-10-01/electricity-tariffs/E-1R-AGILE-24-10-01-A/standard-unit-rates"

  # Overrides metric_octopus_export and rates_export
  # rates_export_octopus_url: "https://api.octopus.energy/v1/products/FLUX-EXPORT-23-02-14/electricity-tariffs/E-1R-FLUX-EXPORT-23-02-14-A/standard-unit-rates"
  # rates_export_octopus_url: "https://api.octopus.energy/v1/products/AGILE-OUTGOING-19-05-13/electricity-tariffs/E-1R-AGILE-OUTGOING-19-05-13-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:
    - 2
    - 3
    - 4
    - 5
    - 6
    - 7
    - 8


  # Days previous weight can be used to control the weighting of the previous load points, the values are multiplied by their
  # weights and then divided through by the total weight. E.g. if you used 1 and 0.5 then the first value would have 2/3rd of the weight and the second 1/3rd
  days_previous_weight:
    - 1
    - 1
    - 1
    - 1
    - 1
    - 2
    - 1

  # Number of hours forward to forecast, best left as-is unless you have specific reason
  forecast_hours: 72

  # 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: 48

  # 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

  # Nordpool market energy rates
  futurerate_url: 'https://dataportal-api.nordpoolgroup.com/api/DayAheadPrices?date=DATE&market=N2EX_DayAhead&deliveryArea=UK&currency=GBP'
  futurerate_adjust_import: True
  futurerate_adjust_export: True
  futurerate_peak_start: "16:00:00"
  futurerate_peak_end: "19:00:00"
  #futurerate_peak_premium_import: 14
  #futurerate_peak_premium_export: 6.5

  # 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
  
  # Tariff comparison feature
  #
  # Adjust this list to the tariffs you want to compare, include your current tariff also
  # DNO region code (see https://energy-stats.uk/dno-region-codes-explained/)
  dno_region: "D"
  compare_list:
    - id: 'current'
      name: 'Current Tariff'
    - id: 'cap_seg'
      name: 'Price cap import/SEG export'
      rates_import:
        - rate: 24.86
      rates_export:
        - rate: 4.1
    - id: 'eon_next_drive'
      name: 'Eon Next Drive import/Fixed export'
      rates_import:
        - rate: 6.7
          start: "00:00:00"
          end: "07:00:00"
        - rate: 24.86
          start: "07:00:00"
          end: "00:00:00"
      rates_export:
        - rate: 16.5
    - id: 'agile_fixed'
      name: 'Agile import/Fixed export'
      rates_import_octopus_url: 'https://api.octopus.energy/v1/products/AGILE-24-10-01/electricity-tariffs/E-1R-AGILE-24-10-01-{dno_region}/standard-unit-rates/'
      rates_export_octopus_url: 'https://api.octopus.energy/v1/products/OUTGOING-VAR-24-10-26/electricity-tariffs/E-1R-OUTGOING-VAR-24-10-26-{dno_region}/standard-unit-rates/'
    - id: 'agile_agile'
      name: 'Agile import/Agile export'
      rates_import_octopus_url: 'https://api.octopus.energy/v1/products/AGILE-24-10-01/electricity-tariffs/E-1R-AGILE-24-10-01-{dno_region}/standard-unit-rates/'
      rates_export_octopus_url: 'https://api.octopus.energy/v1/products/AGILE-OUTGOING-19-05-13/electricity-tariffs/E-1R-AGILE-OUTGOING-19-05-13-{dno_region}/standard-unit-rates/'
    - id: 'flux'
      name: 'Flux import/Export'
      rates_import_octopus_url: 'https://api.octopus.energy/v1/products/FLUX-IMPORT-23-02-14/electricity-tariffs/E-1R-FLUX-IMPORT-23-02-14-{dno_region}/standard-unit-rates'
      rates_export_octopus_url: 'https://api.octopus.energy/v1/products/FLUX-EXPORT-23-02-14/electricity-tariffs/E-1R-FLUX-EXPORT-23-02-14-{dno_region}/standard-unit-rates'
    - id: 'iflux'
      name: 'Intelligent Flux import/export'
      rates_import_octopus_url: 'https://api.octopus.energy/v1/products/INTELLI-FLUX-IMPORT-23-07-14/electricity-tariffs/E-1R-INTELLI-FLUX-IMPORT-23-07-14-{dno_region}/standard-unit-rates/'
      rates_export_octopus_url: 'https://api.octopus.energy/v1/products/INTELLI-FLUX-EXPORT-23-07-14/electricity-tariffs/E-1R-INTELLI-FLUX-EXPORT-23-07-14-{dno_region}/standard-unit-rates/'

[gcoan]

charge_limit isn't set in your apps.yaml, it should be set to

charge_limit:
    - number.sigen_plant_ess_charge_cut_off_state_of_charge

per the latest Sig template https://raw.githubusercontent.com/springfall2008/batpred/main/templates/sigenergy_sigenstor.yaml

Its the charge-to target for the inverter

There's been quite a few iterations of the template, probably worth double checking you have the latest updates included

[iangregory]

I hit this problem too, and have submitted a PR to avoid the crash #3117

@gcoan is right about the root cause. In my case I'd set has_target_soc to false in my config, but had messed up the indentation.

[gcoan]

Useful PR thanks @iangregory , good improvement for predbat to be more graceful in handling such config mismatches

@DFEvans we changed the sig definition to enable has target and has reserve, these changes were merged into the latest release

[DFEvans]

Thanks, I'll go make the changes.

What's the best way to work out that there are breaking/required changes to apps.yaml when upgrading between versions? Even with the knowledge of what's happened, I can't actually identify which commit was the one that made it a new required parameter: v8.30.2...v8.30.6

That they're all patch changes and there was no validation error in apps.yaml (I think - maybe it was buried in the log) lulled me into a false sense of security!

[DFEvans]

Digging deeper, it appears that the relevant change is this commit: aa180dc

Specifically, this line of many in the commit message, which altered config.py:

#2077 Sigenergy add charge target, revised automation

The cause is that the underlying defaults for a SigEnergy system were changed to has_target_soc=True rather than False, which caused Predbat to assume that the apps.yaml would have the sensor defined. I've today learnt that there are two levels of configuration for Predbat, and that the underlying defaults in config.py might change without warning, hence affecting apps.yaml.

[gcoan]

Yes correct, this inverter definition change came from my fork, was discussed and agreed in #2077. You must have missed it.

Unfortunately all the details of my changes get lost when it gets PR'd into Predbat and appears as a single line in the release history.

I try to look at the file changes for each release to see what has changed. New additions to apps.yaml for example you have to manually apply.

There is an underlying gap with Predbat that Predbat doesn't validate that your apps.yaml matches the inverter definition, it just causes a messy crash.