My hardware is Generic x86-64.
Is it possible to run emhass add-on on this hardware?
I have to take back what I said as this morning I see that the prices at nordpool have not worked through. Tried running the shell script but no change.
2023-11-01 06:54:50,007 - web_server - ERROR - ERROR: The passed data is either not a list or the length is not correct, length should be 24
2023-11-01 06:54:50,008 - web_server - ERROR - Passed type is <class 'list'> and length is 18
2023-11-01 06:54:50,008 - web_server - ERROR - ERROR: The passed data is either not a list or the length is not correct, length should be 24
2023-11-01 06:54:50,008 - web_server - ERROR - Passed type is <class 'list'> and length is 18
2023-11-01 06:54:50,009 - web_server - INFO - Retrieving weather forecast data using method = scrapper
2023-11-01 06:54:50,877 - web_server - INFO - Retrieving data from hass for load forecast using method = naive
2023-11-01 06:54:50,878 - web_server - INFO - Retrieve hass get data method initiated...
2023-11-01 06:54:51,637 - web_server - INFO - >> Performing dayahead optimization...
2023-11-01 06:54:51,637 - web_server - INFO - Performing day-ahead forecast optimization
2023-11-01 06:54:51,639 - web_server - INFO - Perform optimization for the day-ahead
2023-11-01 06:54:51,689 - web_server - INFO - Status: Optimal
2023-11-01 06:54:51,689 - web_server - INFO - Total value of the Cost function = -7.28
2023-11-01 06:55:00,297 - web_server - INFO - Setting up needed data
2023-11-01 06:55:00,298 - web_server - INFO - >> Publishing data...
2023-11-01 06:55:00,298 - web_server - INFO - Publishing data to HASS instance
2023-11-01 06:55:00,451 - web_server - INFO - Successfully posted to sensor.p_pv_forecast = -3.0
2023-11-01 06:55:00,669 - web_server - INFO - Successfully posted to sensor.p_load_forecast = 2027.45
2023-11-01 06:55:00,898 - web_server - INFO - Successfully posted to sensor.p_deferrable0 = 0.0
2023-11-01 06:55:01,042 - web_server - INFO - Successfully posted to sensor.p_batt_forecast = 0.0
2023-11-01 06:55:01,069 - web_server - INFO - Successfully posted to sensor.soc_batt_forecast = 60.0
2023-11-01 06:55:01,174 - web_server - INFO - Successfully posted to sensor.p_grid_forecast = 2030.45
2023-11-01 06:55:01,518 - web_server - INFO - Successfully posted to sensor.total_cost_fun_value = -7.28
2023-11-01 06:55:01,540 - web_server - INFO - Successfully posted to sensor.unit_load_cost = 0.1907
2023-11-01 06:55:01,666 - web_server - INFO - Successfully posted to sensor.unit_prod_price = 0.065
Hi Johan, your error indicates you have 18 values available whilst the addon expects 24. This makes sense, at 6:55 am nordpool has 18 remaining values. Probably the error will have disappeared at 2 or 3pm and appear again at 1am.
Solution is to apply a reducing prediction horizon. I use entso-e but principle is the same, count the values in the array and cap the horizon at the lower of 24 or the number of prices available:
\"prediction_horizon\":{{min(24, ((state_attr('sensor.entso_e_api_average_electricity_price_today', 'prices_today') | map(attribute='price') | list + state_attr('sensor.entso_e_api_average_electricity_price_today', 'prices_tomorrow') | map(attribute='price') | list)[now().hour:][:24]|list|length))}},
Good luck!
ok thanks but where do i put it?
In your script, adjusted for your sensor.
Thanks everyone for the help
However, I feel that right now this is too complicated for me so I give up. I’ve tried and tried and sometimes it works but not all the time. The big problem is getting to Nordpool so the prices come into the schedule. it works once but not on restarting hass the next time. I’ll see if I can lay low and find a more detailed way to get everything going.
However, it looks very promising once it works, but right now, as I said, it’s a little too difficult for me to get it to work 100%
I have problems with nordpool pricing today aswell. Might be server related.
Have you had any joy?
Have you disabled all automations and just tried from the curl command line?
Have you changed in the Emhass addon configuration the time step from 30 to 60 minuts. Nordpool, Entsoe and Tibber are publishing the prices every 60 minuts.
The you use the Nordpool example shell script as documented here for passing the price data: The forecast module — emhass 0.5.0 documentation
After suceccsfull dayahead forecast you can publish the prices with this shell_command.
It’s been on 60 minutes the whole time. This is what I don’t understand. I have done this over and over again and now it works? I’ll let it roll until tomorrow and we’ll see. But if for some reason I have to restart HA does it lose the prices? Then I have to go in and restart the nordpool automation, is that normal?
Yes, thats normal. Just add “ha restart” as a trigger for your shell or rest command. That will help
As for Why it works now suddenly? I think you were just unlucky. Nordpool integration had issues, it ruined my charge last night (wanted to benefit from cheap wind energy but my charge automation failed). Reminder to also move my car charge into emhass 
hey mark,
I get the same behaviour if I execute the rest command via development tools. when I go back to a single load 6000W nominal power and 1 hr for def_total_hours I get an optimal result. This is good. So I guess I gradually ratchet up the def_total_hours?
How to reproduce is to pass current soc lower than set min soc.
New day same problem. Prices have not been updated. After a restart of emhass the same thing. I think the problem is that it doesn’t have the prices for tomorrow until after 1pm today. Can almost guarantee that after 13:00 today it will be fine.
2023-11-03 06:40:00,334 - web_server - INFO - Successfully posted to sensor.unit_prod_price = 0.065
2023-11-03 06:40:10,358 - web_server - INFO - EMHASS server online, serving index.html...
2023-11-03 06:40:56,789 - web_server - INFO - Setting up needed data
2023-11-03 06:40:56,790 - web_server - ERROR - ERROR: The passed data is either not a list or the length is not correct, length should be 24
2023-11-03 06:40:56,790 - web_server - ERROR - Passed type is <class 'list'> and length is 18
2023-11-03 06:40:56,790 - web_server - ERROR - ERROR: The passed data is either not a list or the length is not correct, length should be 24
2023-11-03 06:40:56,790 - web_server - ERROR - Passed type is <class 'list'> and length is 18
2023-11-03 06:40:56,791 - web_server - INFO - Retrieving weather forecast data using method = scrapper
2023-11-03 06:40:57,686 - web_server - INFO - Retrieving data from hass for load forecast using method = naive
2023-11-03 06:40:57,687 - web_server - INFO - Retrieve hass get data method initiated...
Det error message says the Python list [price1, price2, …] you are passing has 18 prices, but it should be 24 prices.
I you use template editor its easy to count how many prices you have in your list. I have 24 prices as it should be when using Tibber as price data supplier.
Nordpool are publising the pricedata each day at 13:20. Try to run dayahead optimization at 13:45?
Johan, see my earlier suggestion, if you shorten the prediction horizon dynamically by capping it at the available prices then it works. There are many examples on this forum, just search for “prediction_horizon”.
Ok but unfortunately I don’t know how to put it in. Unfortunately, my programming skills are lacking here
trigger_nordpool_forecast: "curl -i -H \"Content-Type: application/json\" -X POST -d '{\"load_cost_forecast\":{{((state_attr('sensor.nordpool_kwh_se3_sek_3_10_025', 'raw_today') | map(attribute='value') | list + state_attr('sensor.nordpool_kwh_se3_sek_3_10_025', 'raw_tomorrow') | map(attribute='value') | list))[now().hour:][:24] }},\"prod_price_forecast\":{{((state_attr('sensor.nordpool_moms', 'raw_today') | map(attribute='value') | list + state_attr('sensor.nordpool_moms', 'raw_tomorrow') | map(attribute='value') | list))[now().hour:][:24]}}}' http://localhost:5000/action/dayahead-optim"
There are fully worked out examples on the forum based on nordpool. All on MPC. Dont think day ahead is meant to be used on an hourly basis anyway. Alternatively if you want to stick to day ahead the suggest to run your day ahead at 3pm, once a day. That way there will be enough price observations to satisfy emhass
here an example which I use. It is an optimization from 07:00-19:00 and 19:00-07:00 and its horizon is preceding each time window:
seventoseven_optim: "curl -i -H \"Content-Type: application/json\" -X POST -d '{\"pv_power_forecast\":{{((state_attr('sensor.solcast_pv_forecast_prognose_heute', 'detailedHourly') | map(attribute='pv_estimate') | map('multiply', 1000) | list + state_attr('sensor.solcast_pv_forecast_prognose_morgen', 'detailedHourly') | map(attribute='pv_estimate') | map('multiply', 1000) | list))[now().hour:][:(12 - (5 + now().hour) % 12)] }},\"def_total_hours\":[{{states('sensor.heizung_laufzeit_anhebung') | int}}],\"prediction_horizon\":{{(12 - (5 + now().hour) % 12)}},\"load_cost_forecast\":{{((state_attr('sensor.awattar_bezug', 'prices') | list ))[now().hour:][:(12 - (5 + now().hour) % 12)]}},\"prod_price_forecast\":{{((state_attr('sensor.einspeiseverguetung_fake', 'prices') | list ))[now().hour:][:(12 - (5 + now().hour) % 12)]}}}' http://localhost:5000/action/naive-mpc-optim"
I run it at 7:00 and 19:00 and it will create an optimization for 12 hous, but if something failed, I could run it later again manually and it will calculate it for the missing hours.
the magic happens with:
(12 - (5 + now().hour) % 12)
… which will define the missing hours to 7:00 or 19:00
just to mention: sensor.awattar_bezug is a template sensor of the nordpool integration.
The problem in your case is, that it does not have 24 values anymore, when you run it. if you would run it at 00:00, it would be fine and then after 14:00 (when the new prices arrive) until 00:00 again.