EMHASS: An Energy Management for Home Assistant

does this person’s site help with your question? https://sigenergy.annable.me/

Have a look at some of the Home Assistant EMS settings such as battery discharge rate and SOC cutoff, that you might not normally be able to access through the SIgEnergy app.

Any idea what’s happening here? No changes were made at all, something about timezones which I did not change:

[2026-03-26 07:04:13,438] INFO in optimization: Perform an iteration of a naive MPC controller
[2026-03-26 07:04:13,438] DEBUG in optimization: Battery usage enabled. Initial SOC: 0.37, Final SOC: 0.35
[2026-03-26 07:04:13,439] DEBUG in optimization: Deferrable load 1: deactivated (no operating timesteps, not thermal)
[2026-03-26 07:04:13,439] DEBUG in optimization: Deferrable load 2: deactivated (no operating timesteps, not thermal)
[2026-03-26 07:04:13,439] INFO in optimization: Building CVXPY problem structure...
[2026-03-26 07:04:13,441] DEBUG in optimization: Processing deferrable load 0
[2026-03-26 07:04:13,442] DEBUG in optimization: Processing deferrable load 1
[2026-03-26 07:04:13,442] DEBUG in optimization: Processing deferrable load 2
[2026-03-26 07:04:13,443] DEBUG in optimization: Processing deferrable load 3
[2026-03-26 07:04:13,446] DEBUG in optimization: MIP gap tolerance disabled (exact optimal)
[2026-03-26 07:04:30,552] INFO in optimization: Total value of the Cost function = -4134.50
[2026-03-26 07:04:30,591] INFO in command_line: Publishing data to HASS instance
[2026-03-26 07:04:30,610] ERROR in app: Exception on request POST /action/naive-mpc-optim
Traceback (most recent call last):
  File "/app/.venv/lib/python3.12/site-packages/quart/app.py", line 1464, in handle_request
    return await self.full_dispatch_request(request_context)
           ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
  File "/app/.venv/lib/python3.12/site-packages/quart/app.py", line 1502, in full_dispatch_request
    result = await self.handle_user_exception(error)
             ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
  File "/app/.venv/lib/python3.12/site-packages/quart/app.py", line 1059, in handle_user_exception
    raise error
  File "/app/.venv/lib/python3.12/site-packages/quart/app.py", line 1500, in full_dispatch_request
    result = await self.dispatch_request(request_context)
             ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
  File "/app/.venv/lib/python3.12/site-packages/quart/app.py", line 1597, in dispatch_request
    return await self.ensure_async(handler)(**request_.view_args)  # type: ignore[return-value]
           ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
  File "/app/src/emhass/web_server.py", line 652, in action_call
    msg, status = await _handle_action_dispatch(
                  ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
  File "/app/src/emhass/web_server.py", line 518, in _handle_action_dispatch
    opt_res = await optim_actions[action_name](input_data_dict, logger)
              ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
  File "/app/src/emhass/command_line.py", line 1524, in naive_mpc_optim
    await publish_data(input_data_dict, logger, entity_save=True, dont_post=True)
  File "/app/src/emhass/command_line.py", line 2362, in publish_data
    opt_res_latest = _load_opt_res_latest(input_data_dict, logger, save_data_to_file)
                     ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
  File "/app/src/emhass/command_line.py", line 2052, in _load_opt_res_latest
    opt_res_latest.index = pd.to_datetime(opt_res_latest.index)
                           ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
  File "/app/.venv/lib/python3.12/site-packages/pandas/core/tools/datetimes.py", line 1049, in to_datetime
    result = convert_listlike(arg, format, name=arg.name)
             ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
  File "/app/.venv/lib/python3.12/site-packages/pandas/core/tools/datetimes.py", line 435, in _convert_listlike_datetimes
    return _array_strptime_with_fallback(arg, name, utc, format, exact, errors)
           ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
  File "/app/.venv/lib/python3.12/site-packages/pandas/core/tools/datetimes.py", line 470, in _array_strptime_with_fallback
    result, tz_out = array_strptime(arg, fmt, exact=exact, errors=errors, utc=utc)
                     ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
  File "pandas/_libs/tslibs/strptime.pyx", line 566, in pandas._libs.tslibs.strptime.array_strptime
  File "pandas/_libs/tslibs/strptime.pyx", line 317, in pandas._libs.tslibs.strptime.DatetimeParseState.check_for_mixed_inputs
ValueError: Mixed timezones detected. Pass utc=True in to_datetime or tz='UTC' in DatetimeIndex to convert to a common timezone.

Twice a year EMHASS has issues with daylight savings starting and ending.

My luck has it that my jurisdiction doesn’t support daylight savings, so I don’t see this issue.

1 Like

Yes, now I remember again, however, this time EMHASS does not update the sensors anymore. Probably because I have a prediction horizon of 3 days and Saturday night daylight savings starts. So now use 2 days, but it’s not a solution.

Thanks mate, it was the discharge setting at 0 :slight_smile:

Is there a fix or workaround for the timezone bug? or just wait 2 days?

I’m configuring EMHASS.
I see by default "influxdb_measurement": "W", but my inverter power is in W while the smart meter values are in kW.

How to handle this?

I’m checking the documentation and I read:

The sensor containing the load data should be specified in the parameter sensor_power_load_no_var_loads in the configuration file. …
For example, let’s say that you set your deferrable load to be the washing machine. The variables that you should enter in EMHASS will be: sensor_power_load_no_var_loads: 'sensor.power_load_no_var_loads' and sensor.power_load_no_var_loads = sensor.power_load - sensor.power_washing_machine . This is supposing that the overall load of your house is contained in the variable: sensor.power_load . The sensor sensor.power_load_no_var_loads can be easily created with a new template sensor in Home Assistant

The wording is not clear: does it mean I can use in EMHASS directly sensor.power_load - sensor.power_washing_machine and it will perform the calculation? because this would be awesome, it would gain access to a much longer history.

Likewise, can I put a multiplier for the sensor names? my historic data is partially in W (PV power) and partially in kW (household consumption). Being able to use a multiplier would give EMHASS access to years of data, while if I have to create a new helper sensor in HA well… it won’t go back to more than few days.

Can anyone assist me about this?

No that is not possible, you would need to create template sensors in Home Assistant for that. In those you can use calculations (and indeed build your history after that again), e.g.:

- sensor:
  - unit_of_measurement: W
    device_class: POWER
    default_entity_id: sensor.power_load_none_essential
    name: Power Load None Essential
    state: "{{  states('sensor.ec68ea5q_power') | int * 1000 + states('sensor.power_load_none_essential_pool') | float(0.0) }}"
    
- sensor:
  - unit_of_measurement: W
    device_class: POWER
    default_entity_id: sensor.power_load_no_var_loads
    name: Load Without Deferrable
    state: "{{ states('sensor.power_load') | int + states('sensor.eh_deye_sun3p_battery_output_power') | int(0)- states('sensor.power_load_none_essential') | float }}"
  

Thanks!
It’s quite a pity having to add new time series to influxdb when the same data could be calculated upon need, also way earlier than EMHASS was installed.

I’ll propose the feature in the Issue tracker.

Actually I asked Codex and it made a quite interesting proposal about a modification of the code to actually allow combination of existing timeseries! so that there’s no need to create extra helpers, and the whole existing InfluxDB historical data can be used immediately!

https://chatgpt.com/codex/tasks/task_e_69cb833f8e988332a115406855de727b

I’m not even finishing configuring EMHASS yet so I can’t test it, but maybe someone else might.
@davidusb might be interested too if he already has a working test setup.

1 Like

Sometimes I see in the p_grid prediction a value of zero, and a slight battery usage. Is anyone using this to put the battery into a ‘zero import/export’ mode? Probably that would work better then using the prediction, but I’m not sure this is what EMHASS actually means to do :slight_smile:

Why don’t you ask AI to help you backfill your InfluxDB time series from your existing historical loads data? You could then use it in EMHASS immediately.

That would be the last resort, since it’s about a huge duplication of data, and an extra script/operation to be performed… by every user interested in using existing data!

Thinking about the community and not only to my case, it seems to me that allowing arbitrary combination of timeseries is the best way and future proof way to proceed: for example, solar data and meter data are already basically always provided using different units, W and kW.

I’m not talking about an isolated use case… even the simple multiplication of meter data from kW to W via template as I proposed would be of use to so many users.

Think there is a bug in newest release. I have set no discharge to grid true from battery but my forcast shows that it want to do so anyway:


Just integrated EMHASS into my FoxESS set up and utilised the annabele synergy approach to do so. I am having issues with both the Automation and Curtailment integrations as they utilise sensors such as variable grid export limits that I can’t seem to find on Fox.

Does anyone have any tips or currently use an automation that works well for MPC and EMHASS with FoxEss via modbus??