Hi, for the solar panels and inverter you can provide a list of elements like this:
- pv_inverter_model: my_first_inverter_model
- pv_inverter_model: my_second_inverter_model
For the batteries you can only consider one battery. However this can still be used considering the provoded optimized battery power as a lumped power. Then outside EMHASS you can use templates to separate that power for your individual batteries
Whats wrong this time?
The sensor is working in the UI :
You are passing values that seem to be sampled at 30 min time steps while you have configured the add-on to 60 min time steps
post_nordpool_forecast: "curl -i -H 'Content-Type: application/json' -X POST -d '{\"load_cost_forecast\":{{(
(state_attr('sensor.nordpool_kwh_oslo_nok_3_10_025', 'raw_tomorrow')|map(attribute='value')|list)[:24])
}},\"prod_price_forecast\":{{(
(state_attr('sensor.nordpool_kwh_oslo_nok_3_10_025', 'raw_tomorrow')|map(attribute='value')|list)[:24])}}}' http://localhost:5000/action/dayahead-optim"
This is what I use for price. and nordpool uses 60min.
Does that mean that my template sensor is messing this up?
Can you copy your command into the Developer Tools template section so it can expand all your sensors, it is very difficult to debug without knowing what it expands to.
Hi David,
is it possible to add emhass option to NOT charge from grid?
For example I don’t have low cost tariff. I have Goodwe ET series where logic on their General mode is to support load from PV and from batt, than charge batt (when enough PV for load) than grid.
Or is there another approach how to force emhass not to charge from grid?
Thanks Mirek
Hi @davidusb
We’ve been in contact regarding this project pretty much at the beginning of it.
Now after a lot of time, I’d like to start using it.
I am using your add-on but if necessary would also switch to a separate installation.
The following questions arose:
Thanks!
Hi, there is not a direct option or parameter to forbid charging from the grid. However we can force that using artificially high load cost values. If these load costs are high enough then the optimization will normally converge to a solution where charging from the grid is forbidden. You can play with that and see if that fits your needs, however the artificial load cost may lead to the loss of real cost energy values, if this was important to you for estimating for example your real $ saving, then this could be a problem. It can be a little challenge to add more equations to the linear programming formulation to properly solve problems like this, because we will found ourselves with too many equations to solve with our open-source LP solvers 
Hi,
Answering your questions:
shell_command. You have an example here: The forecast module — emhass 0.3.19 documentationprod_price_forecast
Thanks. Am I correct to assume that I can then prefix all these variables with pv_ and then repeat them for each solar installation?
- module_model: 'CSUN_Eurasia_Energy_Systems_Industry_and_Trade_CSUN295_60M' # The PV module model
- inverter_model: 'Fronius_International_GmbH__Fronius_Primo_5_0_1_208_240__240V_' # The PV inverter model
- surface_tilt: 30 # The tilt angle of your solar panels
- surface_azimuth: 205 # The azimuth angle of your PV installation
- modules_per_string: 16 # The number of modules per string
- strings_per_inverter: 1 # The number of used strings per inverter
And repeat them twice for my east-west facing solar panels, once for the east facing and once for the west facing panels?
You should repeat items in the lists for each of your inverter configurations.
For example if you have two inverters, one for east facing modules (with 8 modules) and another for west facing modules (with 12 modules) then it will be something like this:
list_pv_module_model:
- pv_module_model: my_inverter_model_for_east_facing_modules
- pv_module_model: my_inverter_model_for_west_facing_modules
list_pv_inverter_model:
- pv_inverter_model: my_module_model_for_east_facing_modules
- pv_inverter_model: my_module_model_for_west_facing_modules
list_surface_tilt:
- surface_tilt: 30
- surface_tilt: 45
list_surface_azimuth:
- surface_azimuth: 90
- surface_azimuth: 270
list_modules_per_string:
- modules_per_string: 8
- modules_per_string: 12
list_strings_per_inverter:
- strings_per_inverter: 1
- strings_per_inverter: 1
Again, I have done something to mess this up…
But I cant figure out what.
When I press “optimize” I get this :
I figured it out… stupid me had only one of these lines…
It works again now that I saw the mistake.
Thanks, I created a Node-Red flow to get the price data for the next day and to generate the shell_command.
If I want to pass prod_price_forecast and pv_power_forecast to EMHASS, which endpoint should I use in the curl? The sample for prod_price_forecast says dayahead-optim and prod_price_forecast says naive-mpc-optim.
Or do i need to run separate commands? If so, in which order?
As my modules and my inverter are not in the csv, I need to get the forecast data from solcast. In the add-on: Do I need to remove everything from list_pv_module_model and similar or will the command overwrite it?
In the prod_price_forecast there is plenty of “awattar”. As it is an energy provider: was this just used for naming / can I simply ignore that even though this data has nothing to do with awattar?
Thanks!
The endpoints are not specific to what type of data you are passing, they are specific to an optimization task. So you should use the endpoint for the optimization task that you want to achieve. A “dayahead-optim” is designed to launch an optimization just once a day, while “naive-mpc-optim” is designed to launch an optimization at a higher frequency, say every 10 minutes for example.
Or do i need to run separate commands? If so, in which order?
Each endpoint, for example “dayahead-optim”, will accept the four forecast needed by emhass at once. Read the documentation for this, it is well explained there.
As my modules and my inverter are not in the csv, I need to get the forecast data from solcast. In the add-on: Do I need to remove everything from list_pv_module_model and similar or will the command overwrite it?
If you use the solcast method, which is now supported directly inside emhass, then don’t worry about the list_pv_module_model and list_pv_inverter_model parameters in the configuration, they will not be used.
The example on how to use Solcast natively is here:
https://emhass.readthedocs.io/en/latest/forecasts.html#pv-power-production-forecast
Wow, I didn’t understood much of what you said here. I don’t know what an “awattar” is…
Thanks.
Regarding the awattar thing: The sample under The forecast module — emhass 0.7.8 documentation just includes “awattar” saveral times and my question was why it is included in the example if this example is about the pv production volume. Awattar is an energy provider.
When running
curl -i -H “Content-Type: application/json” -X POST -d ‘{“prod_price_forecast”:[“0.26”,“0.23”,“0.21”,“0.21”,“0.19”,“0.19”,“0.22”,“0.24”,“0.27”,“0.29”,“0.27”,“0.27”,“0.27”,“0.23”,“0.21”,“0.22”,“0.27”,“0.33”,“0.38”,“0.41”,“0.39”,“0.37”,“0.34”,“0.29”]}’ http://localhost:5000/action/dayahead-optim
I’m receiving a 500 error.
Tried it with localhost as well as with the actual IP. Any idea why this might happen? I’m using let’s encrypt to protect HA. HA is accessible via https using the internal IP with an SSL error and from external via a domain without SSL error. EMHASS frontend is accessible via http internally.
How many digits are allowed for prod_price_forecast?
EDIT: Just saw the " are not existent in your sample. will try without them.
Thanks
The awatter reference is just a variable name that I grabbed from another template, you can change the template variable to be anything you like.
There shouldn’t be a limitation on the number of digits, but I notice you are passing 24 values.
Have you setup 60 minutes timeslots?
You may also need to pass “prediction_horizon”: 24
Yes I set it to 60 minutes.
I now also removed the " from the prices but am still getting a 505 error. I’ll now try to add spaces between each value.
This is what my call looks like:
post_amber_forecast: "curl -i -H 'Content-Type: application/json' -X POST -d '{\"prod_price_forecast\":[0.01, -0.04, -0.05, -0.05, -0.06, -0.1, -0.16, -0.16, -0.14, -0.08, -0.06, -0.05, -0.05, -0.01, 0.01, 0.03, 0.07, 0.17, 0.3, 0.3, 0.3, 0.3, 0.25, 0.28, 0.23, 0.22, 0.21, 0.22, 0.21, 0.22, 0.22, 0.22, 0.22, 0.23, 0.21, 0.18, 0.16, 0.16, 0.16],\"load_cost_forecast\":[0.09, 0.04, 0.03, 0.02, 0.01, -0.03, -0.09, -0.09, -0.07, -0.0, 0.02, 0.02, 0.02, 0.07, 0.09, 0.12, 0.16, 0.27, 0.41, 0.41, 0.41, 0.41, 0.36, 0.39, 0.34, 0.33, 0.31, 0.33, 0.32, 0.33, 0.32, 0.33, 0.32, 0.34, 0.32, 0.28, 0.26, 0.26, 0.26]}' http://localhost:5000/action/dayahead-optim"