Payload problem when containing both battery sensor definitions and a def_load_config #587
Description
Have been trying to get a script working that models battery soc as well as thermal model as a deferrable load. Using AI I have summarised the findings below. Happy to help share more logs, and also would be very happy if it's actually just a problem my side and not a bug.
This is on Core 2025.9.4, Supervisor 2025.09.0, Operating System 16.2. HAOS on intel i7 running on ProxMox.
Detailed Bug Report for EMHASS Add-on Developer
This report details a series of reproducible bugs encountered in the EMHASS add-on (version 0.13.5) when configuring an optimization plan that includes both a battery model with custom-named sensors and a thermal model as a deferrable load.
The core issue is that the /action/publish-data endpoint appears to have a bug that prevents it from correctly processing a payload containing both custom battery sensor definitions and a def_load_config.
Finding 1: Optimization is Successful, but Publisher Drops Battery Data
The most critical issue is that while the optimization runs perfectly, the publisher fails to create the custom-named battery sensors when the thermal model is active.
Evidence:
The log consistently shows that the optimization completes with a Status: Optimal and that the correct runtime parameters (including the definitions for custom_batt_forecast_id and custom_batt_soc_forecast_id) are passed to the publisher.
Log Snippet: Successful Optimization and Parameters Passed This log confirms the script sent the correct instructions.
Code snippet
[2025-09-28 14:50:48 +1000] [21] [INFO] Status: Optimal
[2025-09-28 14:50:48 +1000] [21] [INFO] Optimization status: Optimal
[2025-09-28 14:50:48 +1000] [21] [INFO] >> Obtaining params:
[2025-09-28 14:50:48 +1000] [21] [INFO] Passed runtime parameters: {
'custom_pv_forecast_id': {'entity_id': 'sensor.mpc_pv_power', ...},
'custom_load_forecast_id': {'entity_id': 'sensor.mpc_load_power', ...},
'custom_batt_forecast_id': {'entity_id': 'sensor.mpc_batt_power', ...}, // Correctly passed
'custom_grid_forecast_id': {'entity_id': 'sensor.mpc_grid_power', ...},
'custom_batt_soc_forecast_id': {'entity_id': 'sensor.mpc_batt_soc', ...}, // Correctly passed
'def_load_config': [{'P_deferrable0': {'entity_id': 'sensor.p_deferrable0', ...}}]
}
However, the subsequent log entries from the publisher show that while other custom sensors are created, the battery sensors are silently ignored.
Log Snippet: Incomplete Publishing Results This log shows the battery sensors are missing from the final published data.
Code snippet
[2025-09-28 14:50:48 +1000] [21] [INFO] >> Publishing data...
[2025-09-28 14:50:48 +1000] [21] [INFO] Publishing data to HASS instance
[2025-09-28 14:50:48 +1000] [21] [INFO] Successfully posted to sensor.mpc_pv_power = 3587.0
[2025-09-28 14:50:48 +1000] [21] [INFO] Successfully posted to sensor.mpc_load_power = 1344.0
[2025-09-28 14:50:48 +1000] [21] [INFO] Successfully posted to sensor.p_deferrable0 = 0.0
[2025-09-28 14:50:48 +1000] [21] [INFO] Successfully posted to sensor.mpc_grid_power = -3587.0
// ... other sensors
// NOTICE: No "Successfully posted" messages for mpc_batt_power or mpc_batt_soc
This behavior is 100% reproducible. If the def_load_config is removed from the payload, the custom battery sensors are created correctly. This proves a direct conflict within the publisher's code.
Finding 2: Predicted Temperature Data is Not Published
A related issue is the complete absence of the predicted indoor temperature data in the final published results.
Evidence:
The optimization is correctly configured to include the thermal model. However, the publisher never creates a sensor for the predicted temperature. Furthermore, the temperature forecast data is not attached as an attribute to the thermal power sensor (sensor.p_deferrable0).
Attributes of sensor.p_deferrable0: As you can see, the deferrables_schedule only contains power data.
YAML
device_class: power
unit_of_measurement: W
friendly_name: Deferrable Load 0
deferrables_schedule:
- date: '2025-09-28 16:30:00+10:00'
p_deferrable0: '3000.0' - date: '2025-09-28 18:00:00+10:00'
p_deferrable0: '3000.0'
... and so on, with no temperature data included.
We attempted to explicitly define the temperature sensor using the correct internal key (T_state_deferrable0) in the publish payload, but the publisher ignored this as well, confirming the bug.
Finding 3: Time Step Mismatch in Publisher
A separate bug exists where the /action/publish-data endpoint appears to have a hardcoded default time_step of 30 minutes, which overrides any other configuration.
Evidence:
When the optimization is run with optimization_time_step: 5, both in the script's payload and in the add-on's optim_conf, the optimization step succeeds, but the publishing step fails with a clear error.
Log Snippet: ValueError on Publishing
Code snippet
[2025-09-28 14:06:11 +1000] [21] [ERROR] Exception on /action/publish-data [POST]
Traceback (most recent call last):
...
ValueError: Inferred frequency 5min from passed values does not conform to passed frequency 30min
This proves the publisher is incorrectly enforcing a 30-minute frequency. The only workaround was to change the entire optimization to use a 30-minute interval, which sacrifices granularity.
Conclusion
The evidence strongly suggests a series of bugs within the /action/publish-data function of this EMHASS version. The code appears unable to handle a payload with both custom battery sensors and a thermal load simultaneously, fails to publish all calculated thermal data, and incorrectly defaults to a 30-minute time step. These issues cannot be resolved with user-side configuration and likely require a code fix in the add-on.