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
I am looking forward to the further optimization that the LP model will provide, the rules based approach is OK, but the complexity is getting difficult to manage and I currently have no way to consider future PV production, so the price might be right to turn on a deferable load, but I may not have sufficient PV at that time to switch on without drawing from the grid.
HA has been really good in bringing together disparate systems, which goes a long way towards populating the EMHASS model.
- PV power production forecast (internally based on the weather forecast and the characteristics of your PV plant)
SolCast & Forecast Solar gives me good hourly forecasts with 10/50/90 percentiles:
- ‘06:00’:
pv_estimate: 52.7
pv_estimate10: 24.1
pv_estimate90: 55.3- ‘07:00’:
pv_estimate: 852.6
pv_estimate10: 347.3
pv_estimate90: 895.2- ‘08:00’:
pv_estimate: 2440.2
pv_estimate10: 1318.5
pv_estimate90: 2542.2
- Load power forecast: how much power on 30min blocks your house will demand on the next 24h
This is the tricky one.
I know what I used yesterday and last week, but a bit more difficult to predict tomorrow as this is a function of how many people are going to be home over what times, external climate, km driven in my EV,…
- PV production selling price forecast: at what price are you selling your excess PV production on the next 24h
Feed In Forecasts Price
state_attr(‘sensor.amber_feed_in_forecast’, ‘forecasts’) |map(attribute=‘per_kwh’)|list}}[0.22, 0.32, 0.29, 0.32, 0.32, 0.27, 0.21, 0.27, 0.21, 0.21, 0.13, 0.13, 0.13, 0.13, 0.13, 0.13, 0.13, 0.21, 0.25, 0.32, 0.32, 0.29, 0.3, 0.29, 0.13, 0.21, 0.13, 0.11, 0.1, 0.1, 0.1, 0.1, 0.11, 0.11, 0.1, 0.13, 0.29, 0.32, 0.32, 0.32, 0.29, 0.33, 0.37, 0.51, 0.51, 0.37, 0.37, 0.37]
- Load cost forecast: the price of the energy from the grid on the next 24h (the data that you already have)
General Price Forecasts
state_attr(‘sensor.amber_general_forecast’, ‘forecasts’) |map(attribute=‘per_kwh’)|list}}[0.33, 0.44, 0.42, 0.44, 0.44, 0.39, 0.33, 0.39, 0.33, 0.33, 0.24, 0.24, 0.24, 0.24, 0.24, 0.24, 0.24, 0.33, 0.38, 0.44, 0.44, 0.42, 0.42, 0.42, 0.24, 0.33, 0.24, 0.21, 0.21, 0.21, 0.21, 0.21, 0.21, 0.21, 0.21, 0.24, 0.42, 0.44, 0.45, 0.44, 0.42, 0.46, 0.5, 0.66, 0.66, 0.5, 0.5, 0.5]
1 Like
HA has been really good in bringing together disparate systems, which goes a long way towards populating the EMHASS model.
Agree…
SolCast & Forecast Solar gives me good hourly forecasts with 10/50/90 percentiles
I’m using a scrapping method on the clearoutside webpage. From what I see they are using the same weather forcast data from Forecsat solar, dar sky, etc… So that’s ok. The advantage that I see with EMHASS is that I’m using PVLib, which is proven to work really well using the actual physical model of I-V curves for PV modules and the actual inverter efficiency curve. So the converted PV power from EMHASS will be more precise at least than Forecast Solar. For SolCast I don’t know.
This is the tricky one.
Yes this is the tricky one!
For now as I said I’m just using the persistence model. It is far from perfect but is giving me some decent results. This is a very complex task what I’m willing to give it a shot to provide my own load forecast service. The good thing is that the framework to do it is there: the add-on environment with Python + a good forecast module. I’ve tried to achieve this with facebook prophet module with mitigated results and at the end not better than the persistance model. My conclusion at the time was that I needed to provide the forecast model with more regression variables, such as those that you cited: km driven with EV, expected number of people at home, the date (week-days/week-end), etc etc… I will try in the near future to obtain better load forecast results with this package: Time Series Made Easy in Python — darts documentation
It seems nice an very intuitive.
In any case for each of these 4 forecasts, the user will be able to directly provide their forecasts using other services and passing the data using json to EMHASS.
By the way with new version 0.1.17 you will be able to access the web ui from outside your LAN.
Hi; version v0.1.18 of this add-on is out.
You should be able to pass all your own forecast data from other HA services. The data can be simply passed as a numeric list using json data. Take a look at the add-on documentation for more information on how to achieve this.
Leave a message or open an issue on github if you encounter any problem.
Hi. I just released v0.1.19. Fixed a bunch of errors.
Enjoy!
thanks! Can you post a screenshot? Why would i want to use yours over the built in energy tab?
Hi! Just because they are not at all the same thing. You may find an explanation of what is this in the add-on documentation. There is also a screenshot of the web ui. Take a look here:
Essentially the built-in energy tab is just a dashboard of yours different power flows and energies. It will help you to visualize and understand how is the energy flow in your house at each hour of the day. You can then possibly build some automation rules to try to optimize you energy bill. This is however manual and the optimality is not guaranteed.
The emhass package and the add-on perform an actual mathematical optimization of the future energy flow of your home using linear programming. Is an optimal dispatch of your home energy. This is interesting as your home system will be more complex and a bunch of manual automations won’t guarantee you the best optimal solution. As an input you can provide your home load forecast, your PV power production forecast, your energy prices forecasts (consumed and produced), your systems characteristics, etc. As an output emhass will give you the optimal dispatch of your defined deferrable loads, for example: hot water rod, pool pump, storage battery, etc.
1 Like
Just working my way through the PVLib settings.
I have two SolarEdge 7 kW 3 phase inverters model SE7K-AUBTEBEU4
and 18.5 kW of panels (50x370W Winaico panels) arranged in four strings east/ west facing on 10 deg tilts.
I have checked in the pvlib library and cannot see these models:
How can I specify generic system parameters on the add-on configuration dialog/ yaml?
Hi, if you cannot find your exact models then just pick one with similar nominal power sizes for both the inverter and the panels. You should be able to find this. This is not ideal but it will still be much better than simpler PV modeling approaches. For our purposes PV panels IV curves and power inverters efficiencies curves are fairly similar from one model to another.
These libraries are regularly updated and they add the new inverters and panels models. So let’s hope that they include yours in a next update.
BTW v0.1.38 is released: Release EMHASS add-on v0.1.38 · davidusb-geek/emhass-add-on · GitHub
Hi, in your case you should be almost good with this model from the PVLib CEC database: SolarEdge Technologies Ltd : SE7600A-US [240V]
There are two important things that will be considered when modeling the PV array:
-
The inverter efficiency. In this case if you choose a similar inverter from the same manufacturer and in a similar power range it should be good enough. The efficiency curve as a function of the inverter power will be fairly similar.
-
The maximum AC output from the inverter. This should be a little bit more problematic because a different max nominal power will mean that the simulation may throw a higher (or lower) power output that you may actually get on your real system. I can see that for the present model on the CEC database it will differ from yours on roughly 625W. That may not be much and for our purposes sufficiently low to get some good usable results from this simulation. I may introduce a user given max PV output parameter to the add-on configuration to deal with these special cases.
1 Like
Thanks,
I ended up with that model. The trick is getting all the special characters and replacing them with ‘_’.
I have two inverters each with one string of 25 panels on each, challenge is I have 21 panels East facing and 29 West facing, so it doesn’t exactly line up with my strings as SolarEdge uses optimisers so each panel more or less runs independently. You can see here inverter 1 is not reporting.
I have Winaico 370W mono panels so I just picked something close and set up with 21 & 29 panels on each string, which seems to give pretty close results.
pv_module_model: Advance_Power_API_M370,Advance_Power_API_M370
pv_inverter_model: >-
SolarEdge_Technologies_Ltd___SE7600A_US__208V_,SolarEdge_Technologies_Ltd___SE7600A_US__208V_
surface_tilt: 10,10
surface_azimuth: 90,270
modules_per_string: 29,21
strings_per_inverter: 1,1
1 Like
This emhass module is now on its version >> v0.3.11: Release EMHASS version 0.3.11 · davidusb-geek/emhass · GitHub
Lots of improvements since v0.3.0… A new docker standalone mode is now fully functional.