Thanks for your quick reply. My suburb worked as well, perhaps I should’ve just tested myself in the first place 
Today I found a strange error in my log:
2024-10-29 14:37:57.921 [INFO ] [nhab.automation.script.ui.dfa34a1333] - -----------------------------------------------------------------
2024-10-29 14:37:58.017 [ERROR] [nhab.automation.script.ui.dfa34a1333] - generic-optimizer.js: Not enough prices for optimizations!
2024-10-29 14:37:58.020 [INFO ] [nhab.automation.script.ui.dfa34a1333] - heating-period-optimizer.js: Calculating heating need for the heating periods.
2024-10-29 14:37:58.170 [INFO ] [nhab.automation.script.ui.dfa34a1333] - heating-period.js: 2024-10-29T16:00+02:00[SYSTEM]: temperature 0.06, heating hours 2.47, flexibility: 0.25
2024-10-29 14:37:58.302 [INFO ] [nhab.automation.script.ui.dfa34a1333] - heating-period.js: 2024-10-30T00:00+02:00[SYSTEM]: temperature 1.29, heating hours 2.30, flexibility: 0.25
2024-10-29 14:37:58.434 [INFO ] [nhab.automation.script.ui.dfa34a1333] - heating-period.js: 2024-10-30T08:00+02:00[SYSTEM]: temperature -1.01, heating hours 2.62, flexibility: 0.25
2024-10-29 14:37:58.566 [INFO ] [nhab.automation.script.ui.dfa34a1333] - heating-period.js: 2024-10-30T16:00+02:00[SYSTEM]: temperature -2.32, heating hours 2.80, flexibility: 0.25
2024-10-29 14:37:58.741 [INFO ] [nhab.automation.script.ui.dfa34a1333] - heating-period.js: 2024-10-31T00:00+02:00[SYSTEM]: temperature -2.22, heating hours 2.79, flexibility: 0.25
2024-10-29 14:37:58.942 [INFO ] [nhab.automation.script.ui.dfa34a1333] - heating-period.js: 2024-10-31T08:00+02:00[SYSTEM]: temperature -0.92, heating hours 2.61, flexibility: 0.25
2024-10-29 14:37:58.944 [INFO ] [nhab.automation.script.ui.dfa34a1333] - heating-period-optimizer.js: Checking for significant temperature drops...
2024-10-29 14:37:58.947 [INFO ] [nhab.automation.script.ui.dfa34a1333] - heating-period-optimizer.js: Temperature drop detected after period starting at 2024-10-30T00:00+02:00[SYSTEM], adjusting flexibility of this and next period.
2024-10-29 14:37:58.949 [INFO ] [nhab.automation.script.ui.dfa34a1333] - heating-period-optimizer.js: Heating periods after temperature drop compensations:
2024-10-29 14:37:58.951 [INFO ] [nhab.automation.script.ui.dfa34a1333] - heating-period.js: 2024-10-29T16:00+02:00[SYSTEM]: temperature 0.06, heating hours 2.47, flexibility: 0.25
2024-10-29 14:37:58.953 [INFO ] [nhab.automation.script.ui.dfa34a1333] - heating-period.js: 2024-10-30T00:00+02:00[SYSTEM]: temperature 1.29, heating hours 2.30, flexibility: 0
2024-10-29 14:37:58.955 [INFO ] [nhab.automation.script.ui.dfa34a1333] - heating-period.js: 2024-10-30T08:00+02:00[SYSTEM]: temperature -1.01, heating hours 2.62, flexibility: 0
2024-10-29 14:37:58.957 [INFO ] [nhab.automation.script.ui.dfa34a1333] - heating-period.js: 2024-10-30T16:00+02:00[SYSTEM]: temperature -2.32, heating hours 2.80, flexibility: 0.25
2024-10-29 14:37:58.959 [INFO ] [nhab.automation.script.ui.dfa34a1333] - heating-period.js: 2024-10-31T00:00+02:00[SYSTEM]: temperature -2.22, heating hours 2.79, flexibility: 0.25
2024-10-29 14:37:58.961 [INFO ] [nhab.automation.script.ui.dfa34a1333] - heating-period.js: 2024-10-31T08:00+02:00[SYSTEM]: temperature -0.92, heating hours 2.61, flexibility: 0.25
2024-10-29 14:37:58.962 [INFO ] [nhab.automation.script.ui.dfa34a1333] - heating-period-optimizer.js: Optimizing the non-flexible heating need.
2024-10-29 14:37:58.977 [ERROR] [omation.script.javascript.dfa34a1333] - Failed to execute script: i: otherDuration must not be null
at <js>.m(@openhab-globals.js:2)
at <js>.n.compareTo(@openhab-globals.js:2)
at <js>.validateRequestedHours(/etc/openhab/automation/js/node_modules/openhab-spot-price-optimizer/generic-optimizer.js:697)
at <js>.optimizeInPieces(/etc/openhab/automation/js/node_modules/openhab-spot-price-optimizer/generic-optimizer.js:264)
at <js>.allowInPieces(/etc/openhab/automation/js/node_modules/openhab-spot-price-optimizer/generic-optimizer.js:81)
... 82 more
2024-10-29 14:37:58.979 [ERROR] [internal.handler.ScriptActionHandler] - Script execution of rule with UID 'dfa34a1333' failed: org.graalvm.polyglot.PolyglotException: i: otherDuration must not be null
Is this the result of not getting price information on time?
The first error suggests that you did not have spot prices available when the rule was executed.
1 Like
Hi, I have been using old version of FetchSpotPrices and it seems that prices for few hours are missing as reported earlier. I’m now trying to install the new version but I don’t know how to navigate to openHAB automation/js directory.
Are you using openhabian SD image on Raspberry Pi or how have you installed openHab? If you are using openhabian, they are under /etc/openhab
Also notice the recommendqtion to usec64 bit operating system, see System requirements and pre‐requisites · masipila/openhab-spot-price-optimizer Wiki · GitHub
Markus
I’m planning to develop a new optional feature which includes a feedback loop from the indoor temperature.
Conceptually something like this: in the parameters, we add a new optional parameters for setting a target average indoor temperature (this would obviously be read from an Item).
Then, if the price optimization has been too aggressive for example during the day when prices are too high, we would detect that the indoor temperature has dropped too much and we would take this into account and add more heating need.
Do the other users have indoor temperature sensors so that you could share screenshot of days when this kind of drop has happened?
I’m running openHAB 4.2 under windows 11. So, do I need to navigate to automation/js directory under openHAB console? This is what I don’t understand.
This is a good option. You could also use the indoor sensor for switching off the heat pump if the indoor temp is getting too high.
Does this help: Windows | openHAB
And no, you do not need to run the openhab console, we are taking about the file system of you operating system.
Markus
I have tried to run npm install openhab-spot-price-optimizer both in Win11 command prompt and under Karaf console but in both cases npm is not recognized so I’m getting really confused. I have been running your original scripts without any issues but now it seems that few hours in the afternoon are missing.
In the very early versions we copied the files to the correct folder manually but I later learned that this is a Bad Idea ™ because the node_modules folder under automation/js is meant for packages installed with npm. If you have placed there something manually bypassing npm and you then later run npm to install something else, all your files there would be deleted.
So you want to google next how to install npm on Windows.
October energy bill came: 291 € saved this year so far. October price 58% below spot average.
More data here.
If you need data, I can be of assistance. However, I’m still tuning in my system so not very representative. But let me know what you would like to see
Also, I could share some info about my prerequisite (if someone is interested 
). I have an older Nibe on/off geothermal heat pump. I have radiators in most rooms, but floor heating in two rooms. It feels like my walls are made of cardboard, so the inertia in my house is not very high (meaning the temperature drops pretty fast when heating is off). I can’t control the compressor directly, but instead I turn the whole pump on or off and then the logic of the pump starts working, turning the compressor on and off in cycles.
Therefore, I won’t turn the pump on and off, but instead I will change the heating curve offset based on the output of this script. By this I hope that the temperature will not swing as much. Tuning will continue!
Thanks @masipila for pointing me to this project! For sure actually I only want to visualize the day aghead prices. So I stripped down the script from the git repo to only show weather and spot price. Unfortunately the data is only shown up the the current hour 
The item itself seems to have the whole timeline data, as the next hour is shown without any update. So I assume that there must be an other issue.
The stuff is running on openhab 4.2.2 on raspi 4. All installed packages are updated. Do I have to confire something outside to have a complete image?
Christoph
@chr15 I’m no expert in this, but two things
- You could check from influxdbs data explorer tool how much data you have, preferably do it in the afternoon so the next day’s prices have come in
- Regarding the script you stripped down. It would be easier to find the problem if you share your version of the script
Thanks @kosken to pointing me to further analyzing steps. Interestingly the flux data explorer shows the same data as the visualisation above. After a full hour and a reload of the explorer the next hour value appears without an update from the item. Don’t know, if I found the correct terms.
This is the code of the page:
config:
chartType: day
label: Strompreise
sidebar: true
slots:
grid:
- component: oh-chart-grid
config: {}
legend:
- component: oh-chart-legend
config:
orient: horizontal
show: true
series:
- component: oh-time-series
config:
areaStyle:
opacity: "0.4"
gridIndex: 0
item: Dayahead_prices_Spot_Price
markLine:
data:
- label:
distance: -150
name: Avg
type: average
name: Spot Price
step: middle
type: line
xAxisIndex: 0
yAxisIndex: 0
- component: oh-time-series
config:
gridIndex: 0
item: OpenWeatherMap_One_Call_API_Weather_and_Forecast_ForecastTomorrow_Apparentday
markLine:
data:
- label:
distance: -75
name: Avg
type: average
name: Weather forecast
type: line
xAxisIndex: 0
yAxisIndex: 1
tooltip:
- component: oh-chart-tooltip
config:
orient: horizontal
show: true
xAxis:
- component: oh-time-axis
config:
gridIndex: 0
yAxis:
- component: oh-value-axis
config:
gridIndex: 0
name: c/kWh
- component: oh-value-axis
config:
gridIndex: 0
splitLine:
show: false
name: ° C
Is it possible that this issue is the result of using influxdb 1.x?
Sorry for answering my own question, but maybe someone else will fall into the same trap. It was the persistence strategy I’ve had to change to ‘forecast’. And that did the trick. Data is visible in influx explorer as well as in the page posted above.
Great that you got it working! I upgraded to influxDBv2 before starting to use this, but I think there’s some limitations in the functionality on V1. But apparently your limited scope works with v1
Just a quick note to those users who would like to use the openHAB spot price optimizer so that the spot prices are fetched with the EntsoE Binding.
The current version of the openHAB spot price optimizer assumes that the price data is stored with 15 minute resolution. EntsoE API provides the data with 60 minute resolution for most countries, and in these cases the openHAB spot price optimizer’s price fetching mechanism will “fill the gaps” and write an entry for 15, 30 and 45 minutes past the full hour.
As the opening post of this thread says, the roadmap for version 4.0 is to start using the EntsoE binding (and any weather forecast binding) so that the openHAB spot price optimizer would only focus on the optimization algorithms and the fetching of the price and weather forecast data would be the responsibility of separate bindings. But that is the roadmap for version 4.0, we’re currently in version 3.x where the openHAB spot price optimizer is having it’s own spot price fetching mechanism.
Cheers,
Markus
Dear @masipila,
first of all again: thank you very much for your work!
I used V1 of your spotprice optimizer last winter.
I did some workarounds to use my own provided spotprices from tibber. I did not use Entso-E for this.
It worked so far but i never finished it completely and i wasn’t completly satisfied with my integration.
I now upgraded everything to InfluxDBv2. I use timeseries for temperature and spotprice delivery.
I had an issue with this yesterday and i think this is an bug in your script - I’m using heating-priod-optimizer.
In influx.js on line 93 you have this code:
'|> filter(fn: (r) => not exists r["item"])';
I always got empty response from influx with error “query did not return any data”.
I changed this line to:
'|> filter(fn: (r) => not exists r["'+measurement+'"])';
And then it worked.
My only problem right now is, that even if its about 3°C Calculation always predicts the Heatpump needs to run all the time.
Can you please double check this?
Here is the code i added / changed in HeatinPriodOptimizer constructor to upgrade my price-timeseries to 15min slots:
let prices = this.influx.getPoints(this.priceItem, this.start, this.end);
let pricesnew = [];
//Upgrade prices to 15 min slots
for (let i = 0; i < prices.length; i++){
var currtime = time.toZDT(prices[i]["datetime"]);
var currprice = prices[i]["value"];
var nexttime = currtime;
if (i < prices.length -1)
{
nexttime = time.toZDT(prices[i+1]["datetime"]);
}
let pricePoint = {
datetime: currtime.format(time.DateTimeFormatter.ISO_INSTANT),
value: currprice
};
pricesnew.push(pricePoint);
while (currtime.plusMinutes(15).isBefore(nexttime))
{
currtime = currtime.plusMinutes(15);
let pricePoint = {
datetime: currtime.format(time.DateTimeFormatter.ISO_INSTANT),
value: currprice
};
pricesnew.push(pricePoint);
}
}
this.genericOptimizer.setPrices(pricesnew);
This is just a quick codeing. I didn’t test this further. But maybe it is a base for your implementation.