Well they are the sensors I use. They can be manupulated to give me an average wattage output from PV per 30 minute time step which suits my tariff forecasts from Amber and prediction horizon which varies throught the day.
There will be examples out there that suite the Nordpool tariff data you are using. It may not be 30 minute, I don’t know. But what ever it is this particular data should be the forecast average wattage for that time step.
Like I said, you can leave it to EMHASS to extract this information and format it automatically by selecting one of the solar forecast providers in the config as long as you can describe you solar panels accuratly in the config.
I only go to the trouble of formatting pv_power_forecast in the API POST for historical reasons.
The pv_power_forecast data dictionary are in watts (W).
- EMHASS consistently works internally with power data (instantaneous rates) in watts or average watts per time step, not energy in kilowatt-hours.
- When you feed it Solcast forecast data (which yes, is in kWh per time step), EMHASS converts that to W by dividing by the forecast interval and multiplying by 1000.
So this code:
{#- Forecast of consumption price (demand tariff) -#}
"pv_power_forecast": {{
([states('sensor.sonnenbatterie_84324_production_w')|int(0)] +
state_attr('sensor.solcast_pv_forecast_forecast_today', 'detailedForecast')|selectattr('period_start','gt',utcnow()) | map(attribute='pv_estimate')|map('multiply',1000)|map('int')|list +
state_attr('sensor.solcast_pv_forecast_forecast_tomorrow', 'detailedForecast')|selectattr('period_start','gt',utcnow()) | map(attribute='pv_estimate')|map('multiply',1000)|map('int')|list
)| tojson
}},
should deliver something like this:
"pv_power_forecast": [946, 1319, 1802, 2354, 2841, 3201, 3489, 3705, 3853, 3950, 3945, 3907, 3750, 3544, 3269, 2931, 2442, 1896, 1379, 825, 198, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 5, 159, 643, 1166, 1698, 2213, 2786, 3188, 3478, 3700, 3843, 3913, 3927, 3869, 3736, 3521, 3241, 2894, 2343, 1820, 1312, 730, 141, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0],
and that data in W (or average W over the 30 min time step), in JSON foremat, is suitable to include in an API call to EMHASS MPC or dayahead models along with all the other data.
So my entire template produces this:
{"prod_price_forecast": [-0.0026, 0.0219, 0.0128, 0.0046, -0.0022, -0.0201, -0.0259, -0.0322, -0.0365, -0.0386, -0.0393, -0.0385, -0.0354, -0.03, -0.0207, 0.003, 0.017, 0.0711, 0.0984, 0.1399, 0.1797, 0.1977, 0.2029, 0.2019, 0.1982, 0.1937, 0.1891, 0.1445, 0.138, 0.1324, 0.129, 0.1249, 0.123, 0.1242, 0.1201, 0.1087, 0.1021, 0.1001, 0.0975, 0.0959, 0.0973],
"load_cost_forecast":[0.06, 0.0871, 0.077, 0.0679, 0.0605, 0.0544, 0.048, 0.0411, 0.0363, 0.034, 0.0332, 0.0342, 0.0375, 0.0435, 0.0537, 1.0, 1.0, 1.0, 1.0, 1.0, 1.0, 1.0, 1.0, 1.0, 1.0, 1.0, 1.0, 0.2219, 0.2147, 0.2085, 0.2048, 0.2004, 0.1982, 0.1995, 0.195, 0.1825, 0.1752, 0.173, 0.1701, 0.1684, 0.17],"pv_power_forecast": [1334, 1802, 2354, 2841, 3201, 3489, 3705, 3853, 3950, 3945, 3907, 3750, 3544, 3269, 2931, 2442, 1896, 1379, 825, 198, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 5, 159, 643, 1166, 1698, 2213, 2786, 3188, 3478, 3700, 3843, 3913, 3927, 3869, 3736, 3521, 3241, 2894, 2343, 1820, 1312, 730, 141, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0],
"load_power_forecast": [596, 552, 538, 550, 593, 2186, 708, 567, 662, 633, 590, 647, 576, 845, 1618, 1465, 498, 462, 436, 457, 584, 877, 1161, 1052, 1136, 921, 1034, 781, 626, 504, 420, 417, 390, 370, 370, 379, 359, 396, 425, 381, 388, 361, 313, 314, 310, 323, 844, 996, 682],
"prediction_horizon": 40,
"num_def_loads": 2,
"def_total_hours": [1,0],
"P_deferrable_nom": [1300, 920],
"treat_def_as_semi_cont": [1, 0],
"set_def_constant": [0, 0],
"soc_init": 0.01,
"soc_final": 0.08,
"alpha": 1,
"beta": 0,
"battery_charge_power_max": 3300,
"battery_discharge_power_max": 1200
}
In my system this data is recalculated every 30 seconds and POSTed to EMHASS via a node-red HTTP request node followed by a ‘publish-data’ POST.
And from 1/10 we will change to 15min tariffs, so I winder if i will get this going, until have to redo again 
Used tojson to ensure proper JSON arrays ([…]) rather than Python-like lists.
Question for you: do you want only prices passed as both load_cost_forecast and prod_price_forecast (as you’ve written), or should one of them instead be your solar forecast (from Solcast, etc.)?
With this in place, EMHASS won’t try to look for long_train_data.pkl anymore, because it sees the load_cost_forecast and prod_price_forecast you’re sending.
] )
