Ok, trying to solve this right now. I didn’t tested it on arm archs, just amd64 and it worked fine… I will try now to create a Dockerfile for multiple architectures, including PI4 arm’s…
Right. Could you please try now? I just pushed a new version with a quick fix that will hopefully overcome that Numpy installation problem. If the problem persists I will later switch to official hass docker images for each arch.
Fantastic project and I look forward to getting things running.
Version 0.1.16 loaded correctly on my odroid n2+, which is the same hardware as HA Blue so that is a start.
I am not currently on my local network, and access HA via Nabu Casa, so I presume I cannot access EMHASS, which makes control difficult outside of LAN. Interesting other Add-On’s can still access localhost, so there maybe a way around that I haven’t identifed.
I have multiple inverters with multiple strings pointing in different directions, which doesn’t seem to be supported in the EMHASS configuration setup. I am also interested in the use of pvlib within EMHASS given the HA energy dashboard already has good support for solar forecasting though either the Solcast or Forecast.Solar integrations, which in my case are already setup.
EMHASS assumes that the solar compensation, TOU pricing and timings are constant, but there are other cases. I have forecast and actual feed in and general tariff pricing available in 30 minute blocks vi the Amber Electric Integration. That is OK, I can make a steady state approximation as to my TOU windows and pricing, but something to consider for the future, and something that would really benefit from the LP, although I suspect the calculations may need to occur more than once a day as my forecast pricing is updated every 30 minutes.
EMHASS assumes that the deferable loads needs to run for a fixed number of hours but there are other cases. My EV/ Home Battery charging time is an inverse function with its state of charge, the Power draw for EV charging can also be modulated to self consume excess solar, my Pool Heating time is a function of the temperature difference with the desired set point. My HVAC running time is a bizzare function of the temperature difference with the desired set point with an allowance for pre heating/ cooling before electricity price peak windows.
So looking forward to seeing how far we can push EMHASS.
1 Like
Great project ! I am really interested as I have to ideally maximize the usage of my solar production to minimize my electricity bill but also minimize the price for installing batteries in the future… EMHASS combined with the recording of the power consummed by some of my equipments (a total of 22), the battery simulator (battery_sim) and the energy dashboard, will allow me to meet my objectives I think.
Hi thanks for the feedback!
Version 0.1.16 loaded correctly on my odroid n2+, which is the same hardware as HA Blue so that is a start.
You will need to rebuild as I have just updated EMHASS (the module not the add-on)
I am not currently on my local network, and access HA via Nabu Casa, so I presume I cannot access EMHASS, which makes control difficult outside of LAN. Interesting other Add-On’s can still access localhost, so there maybe a way around that I haven’t identifed.
Ok so in version 0.1.16 (the latest) I’m using directly communication with the supervisor. So EMHASS should be able to communicate directly with your hass core instance. Have you tested the connection?
I have multiple inverters with multiple strings pointing in different directions, which doesn’t seem to be supported in the EMHASS configuration setup. I am also interested in the use of pvlib within EMHASS given the HA energy dashboard already has good support for solar forecasting though either the Solcast or Forecast.Solar integrations, which in my case are already setup.
Ok this is a very nice use case, I will definitely update the code in the near future to support multiple inverters. The core code is actually ready for this as everything is in lists, so you we could have a list of inverters with no problem. But I will need to work a little bit further on the add-on.
For you to use PVLib inside EMHASS you will have to provide and pass the irradiance and temperature forecasts provided by whatever service you want. As you said this is already implemented in HA, so it will be nice to retrieve these forecasts directly. This is already possible using your own CSV files with my EMHASS Python module but not the Add-on. I will also update the add-on for you to be able to import directly the variables from those forecasting services you mentioned. I will work on it.
EMHASS assumes that the solar compensation, TOU pricing and timings are constant, but there are other cases. I have forecast and actual feed in and general tariff pricing available in 30 minute blocks vi the Amber Electric Integration. That is OK, I can make a steady state approximation as to my TOU windows and pricing, but something to consider for the future, and something that would really benefit from the LP, although I suspect the calculations may need to occur more than once a day as my forecast pricing is updated every 30 minutes.
Again this is actually already implemented in the EMHASS Python module but still not in the add-on. I was trying to figure out how to possible import variable pricings. The Amber Electric integration is just for AU users, so I will need to find a more generalized solution. How to feed a forecast variable to EMHASS?
EMHASS assumes that the deferable loads needs to run for a fixed number of hours but there are other cases. My EV/ Home Battery charging time is an inverse function with its state of charge, the Power draw for EV charging can also be modulated to self consume excess solar, my Pool Heating time is a function of the temperature difference with the desired set point. My HVAC running time is a bizzare function of the temperature difference with the desired set point with an allowance for pre heating/ cooling before electricity price peak windows.
There are definitely a lot of using cases to take care of. For now an answer to the EV case. You can consider adding a battery to EMHASS and fix a discharging power to zero and a target SOC to whatever SOC you want the EV to be at the end of the day.
1 Like
Yes, that’s exactly the goal of this package. Looking to see what it can do for you. 
Please post your supervisor logs to be able to see what’s the actual problem.
I’m also aware of the Octopus Agile integration for UK users, which also has variable pricing. In both cases I think the generic use case is a sensor for current price, a sensor for forecast price and then attributes listing subsequent prices. A generic approach for forecast data would be useful across HA.
I can start/ stop EMHASS from the Addon tab, so yes they are connected, but I cannot access the Web UI though the http://xyzz.ui.nabu.casa:5000 address, it will be a few days before I can access my LAN directly, and then I anticipate I will be able to use the http://homeassistant.local:5000 address for the Web UI.
By comparison the File Editor, Studio Code Server. Terminal & SSH Addon does allow me access though the nabu.casa proxy:
https://xxyyy.ui.nabu.casa/hassio/ingress/core_ssh
Interesting to note I can telnet to localhost port 5000 from within the Telnet & SSH addon, but I presume EMHASS does not have a CLI available.
It looks like these other add on’s work remotely as they bind to the hassio/ingress file system space, rather than presenting on a different port (5000 in EMHASS case).
22-03-29 14:01:37 INFO (MainThread) [supervisor.store.git] Cloning add-on https://github.com/davidusb-geek/emhass-add-on repository
22-03-29 14:01:39 WARNING (SyncWorker_5) [supervisor.addons.validate] Add-on config 'auto_uart' is deprecated, use 'uart'. Please report this to the maintainer of deCONZ
22-03-29 14:01:39 INFO (MainThread) [supervisor.store] Loading add-ons from store: 67 all - 1 new - 0 remove
22-03-29 14:01:39 INFO (MainThread) [supervisor.resolution.evaluate] Starting system evaluation with state CoreState.RUNNING
22-03-29 14:01:39 INFO (MainThread) [supervisor.resolution.evaluate] System evaluation complete
22-03-29 14:01:45 INFO (MainThread) [supervisor.addons] Creating Home Assistant add-on data folder /data/addons/data/5b918bf2_emhass
22-03-29 14:01:45 INFO (SyncWorker_3) [supervisor.docker.addon] Starting build for 5b918bf2/armv7-addon-emhass:0.1.16
22-03-29 14:01:50 ERROR (SyncWorker_3) [supervisor.docker.addon] Can't build 5b918bf2/armv7-addon-emhass:0.1.16: The command '/bin/bash -o pipefail -c apt-get update && apt-get install -y --no-install-recommends libffi-dev python3 python3-pip python3-dev git build-essential && pip3 install --no-cache-dir -U setuptools wheel && pip3 install --no-cache-dir -r requirements.txt && apt-get purge -y --auto-remove git build-essential python3-dev && rm -rf /var/lib/apt/lists/*' returned a non-zero code: 100
22-03-29 14:01:50 ERROR (SyncWorker_3) [supervisor.docker.addon] Build log:
Step 1/19 : ARG BUILD_FROM
Step 2/19 : FROM ${BUILD_FROM}
---> 4227b8cc9f8d
Step 3/19 : WORKDIR /usr/src
---> Using cache
---> e953a1313722
Step 4/19 : COPY ./requirements.txt /usr/src/requirements.txt
---> Using cache
---> 81662027936f
Step 5/19 : RUN apt-get update && apt-get install -y --no-install-recommends libffi-dev python3 python3-pip python3-dev git build-essential && pip3 install --no-cache-dir -U setuptools wheel && pip3 install --no-cache-dir -r requirements.txt && apt-get purge -y --auto-remove git build-essential python3-dev && rm -rf /var/lib/apt/lists/*
---> Running in ced58ef1a383
Get:1 http://deb.debian.org/debian bullseye InRelease [116 kB]
Get:2 http://security.debian.org/debian-security bullseye-security InRelease [44.1 kB]
Get:3 http://deb.debian.org/debian bullseye-updates InRelease [39.4 kB]
Err:2 http://security.debian.org/debian-security bullseye-security InRelease
At least one invalid signature was encountered.
Err:1 http://deb.debian.org/debian bullseye InRelease
At least one invalid signature was encountered.
Err:3 http://deb.debian.org/debian bullseye-updates InRelease
At least one invalid signature was encountered.
Reading package lists...
W: GPG error: http://security.debian.org/debian-security bullseye-security InRelease: At least one invalid signature was encountered.
E: The repository 'http://security.debian.org/debian-security bullseye-security InRelease' is not signed.
W: GPG error: http://deb.debian.org/debian bullseye InRelease: At least one invalid signature was encountered.
E: The repository 'http://deb.debian.org/debian bullseye InRelease' is not signed.
W: GPG error: http://deb.debian.org/debian bullseye-updates InRelease: At least one invalid signature was encountered.
E: The repository 'http://deb.debian.org/debian bullseye-updates InRelease' is not signed.
Removing intermediate container ced58ef1a383
A generic approach for forecast will be much appreciated. For now manually feeding that data in json format could be an option, but it will be specific to each integration.
Oh yes I see! The webui is bound by default to localhost (host=‘0.0.0.0’).
Maybe a current solution can be to access your LAN using VPN.
What I may do is let the user to choose its desired host from the configuration pane. In your case: https://xxyyy.ui.nabu.casa/
Maybe related to not enough space on your system. For now it is just a guess.
See: docker - At least one invalid signature was encountered - Stack Overflow
Be careful applying any docker image volume or builder prune commands, as they can be destructive. But I’m not sure how can you perform this in HA OS
Some hints here?: Disk almost full - #38 by WTFoX74
1 Like
Just elaborating a little bit more on this. Right out the box EMHASS can be used for loads that are deferrable. This means that these loads can be “moved” around the day with “ideally” no impact on our everyday life. Good examples of these are: dishwasher, washing machine, etc. At my place I also considered as deferrable the water heater and the pool pump. For the water heater the time constant is quite slow, so as long as I respect a total number of working hours I know that I will have hot water all time regardless on the times that the water heater was on. For the pool pump is the same for me, I’m just looking to fixed total operating hours objective. I’m maybe taking a different approach with this. Of course that what you’re doing with the pool heating and the HVAC is totally valid as they need to be a function of temperatures and maybe other variables. These type of loads that are a function of other variables could be introduced and modeled in the LP formulation, as long as the relationship remains fairly linear. I may be introducing these different types of loads en the LP problem in the future.
For EV’s you’ll need to test as I said using the battery option and a discharging power. I’m guessing that this can work as the SOC evolution is well implemented in the LP formulation. I may test this myself in the near future as I’m waiting for my EV to be delivered 
Hello, I tried to add : GitHub - davidusb-geek/emhass-add-on: The Home Assistant Add-on for EMHASS: Energy Management Optimization for Home Assistant
but I got the message “Invalid Add-on repository !”
Any suggestions ?
Updated: After a few attemps, it worked… So discard this message… 
I have access to my LAN now and get an impressive set of optimization results, but not quite sure what I am looking at and how to best use the system.
I presume it would be good to start simply and then build complexity into the model, that seems to work best for me with HA.
Do you have a worked example for a simple model?
Maybe sensors for production, excess-production, prices and a switch for one deferable load?
My journey for EV charging might be useful here.
Level 1. Fixed time window charging 1000-1400 over solar soak window. Set EV charging rate fixed to 50% of max PV production, to allow for other household loads.
Level 2. Measure excess PV production and set EV charging rate to match, updated every minute. Optimizing use of unused Solar Power to charge a Tesla - #12 by markpurcell
Level 3. Sort the list of 30 minute price forecasts to find the relevant price for the cheapest fixed 2 hours daily (e.g. Car Charging) or 8 hours (e.g. Pool Pump). These 30 minute forecasts change during the day and this method constantly recalculates for the optimal solution.
Level 4.Based on EV/ Battery State of Charge/ Pool Temp difference and known charging rate determine how long (30 blocks) needs to be charged and then identify the relevant price. I.E. Lots of charging at low SOC and limited charging windows at high SOC.These 30 minute forecasts change during the day and this method constantly recalculates for the optimal solution.
3 Likes
Great you can see the UI. Although there are two missing buttons there, to manually launch the optimization and data publish task.
I have access to my LAN now and get an impressive set of optimization results, but not quite sure what I am looking at and how to best use the system.
You’re looking at the latests results stored in a csv file on the data folder inside the add-on. Each time that you launch the optimization task this csv file is rewritten and the graph and table in the UI can be refreshed. I left this initial csv there so that the user can check to what to expect when launching the optimization task. This initial csv was obtained with the default configuration presented in the configuration pane. The graph is interactive, so what you can do is use the legend turn off the visualization of all variables except the deferrable load powers. In that example we have two deferrable loads and what you’re seeing is the result of the optimization. This is giving you the optimal evolution and turn on/off times of those deferrable loads in order to maximize profit for example, depending on what objective function you choose.
Everything is explained in the docs here: https://emhass.readthedocs.io/
The steps to make this work:
- Define all the parameters in the configuration
- You most notably will need to define the main data entering EMHASS. This will be the
sensor_power_photovoltaicsfor the name of the your hass variable containing the PV produced power and the variablesensor_power_load_no_var_loadsfor the load power of your household excluding the power of the deferrable loads that you want to optimize. - Launch the actual optimization and check the results. This can be done manually using the buttons in the web ui or with a curl command like this:
curl -X POST http://localhost:5000/action/dayahead-optim - If you’re good with the optimization results then you can set the optimization and data publish task commands in an automation. You can read all this in the add-on docs pane.
- The final step is to link the deferrable loads variables to real switchs on your installation. Read the docs for an example code for this using automations and the shell command integration.
I presume it would be good to start simply and then build complexity into the model, that seems to work best for me with HA.
Do you have a worked example for a simple model?
Yes you’re right. The simplest example will contain just one deferrable load and no battery.
A study case and a comparison of the different possible objective function definitions is presented here: https://emhass.readthedocs.io/en/latest/study_case.html
Maybe sensors for production, excess-production, prices and a switch for one deferable load?
Follow the steps that I wrote before. Maybe the hardest part is the load data: sensor_power_load_no_var_loads. As we want to optimize the energies, the load forecast is a naive approach using persistence, this mean that the load data variable should not contain the data from the deferrable load itself. For example lets say that you set your deferrable load to be the washing machine. The variable that you should enter in EMHASS will be: 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 variable: sensor_power_load. This can be easily done with a new template sensor
1 Like
Thank you for this input.
That kind of forecast data can be shipped in a json and passed to EMHASS as a data parameter. I’m working on this so that users can be able to pass this kind of data.
What you’re describing is a rule-based approach to energy management. This is totally valid and based on the complexity of the rules it can be an efficient and robust approach. However, my claim with EMHASS, is that that kind of approach is by definition sub-optimal. In your case you are considering the load price forecast, so that’s great. But what about the PV power production in the future, or the house load demand, or the selling price evolution of excess PV power to the grid, the presence of a real battery like a power wall ??? All these are complex uncertainties. The goal of EMHASS is to propose an optimized approach to deal with all this complexity.
In EMHASS we have basically 4 forecasts to deal with:
- PV power production forecast (internally based on the weather forecast and the characteristics of your PV plant)
- Load power forecast: how much power on 30min blocks your house will demand on the next 24h
- PV production selling price forecast: at what price are you selling your excess PV production on the next 24h
- Load cost forecast: the price of the energy from the grid on the next 24h (the data that you already have)
The results of the optimization from EHMASS should help you to optimize even further your rule-based approach.
This further optimization based on forecast is needed the most when your system is complex, when you have storage devices and EVs and variable costs in time. The forecast will enable us to take action in advance in order to maximize profit or maximize auto-consumption from PV, etc.
3 Likes