I managed to troubleshoot this myself, my issue was that I have several persitence services and influxdb is not the default, so I had to specify which persitance service I wanted to use influxdb. Below is my modified funstion for reading prices and save controlpoints.
// Read prices from the database, optimize and save the control points.
var delayedFunction = function() {
console.log(priceItem);
var prices = priceItem.persistence.getAllStatesBetween(start,end,"influxdb");
optimizer.setPrices(prices);
optimizer.allowPeriod(hours);
optimizer.blockAllRemaining();
var timeseries = optimizer.getControlPoints();
controlItem.persistence.persist(timeseries,"influxdb");
console.log(prices);
};
However it seems like I have the same issue with the heatingperiod-optimizer, script doesn’t return any prices and I cant figure out where to define persitence service for items or why I need to define that. I have tried to set influxdb as default service but that didn’t help and I have a persitence group AllforcastItems only enabled in influx db service as forecast strategy.
Is there any ideas of why I get this trouble and where to change it?
I’m on a training camp at the moment preparing for the World Championships which start at the end of this month so I have very limited possibility to debug this at the moment.
Based on what you are describing, I believe this starts to boil down here, on line 57 of the HeatinPeriodOptimizer.
Could you please check if this assumption is correct? If it is, I can modify the module (after the Worlds) so that we could pass an optional input parameter for explicitely defining which persistence service to use.
This is to inform all community members who are still using the 3.x version, that I just updated the end-of-life date from 31 July to 10 June 2025.
Nordpool is expected to switch to 15 minute price resolution on 11 June 2025. The internal logic of version 3.x is using 15 minute resolution and the entsoe.js which fetches the prices from Entso-E API should be able to fetch prices with that resolution if the structure of their API response will be what I expect it will be. But there’s no way to be sure before we see it. But in plain English, I won’t update the 3.x version to be compatible with the new API responses if it breaks.
I highly recommend everybody to plan their upgrade to 4.x well in advance before 11 June.
I started the migration to version 4 as we have a couple of days off during Easter. One change I noticed is that the scripts used to force car charging on and off are refering to influx.js. Are there updates for these scripts somewhere?
The first line comment in the “OFF script” is wrong, you may want to correct this for clarity:
// Read the hour that should be forced ON.
var item = items.getItem("HeatPumpCompressorForceOff");
var datetime = time.toZDT(item.state);
console.log(datetime);
I noticed the script for the control point cloner failsafe was also missing an example for 4.x. I also remembered that @ruxu pointed this documentation gap already earlier but I forgot to update the docs then even though the functionality was there.
Anyway, the control point cloner example is now available at
Now that I updated the failsafe control point cloner documentation, I realized that the example controller scripts for version 4.x have not had the same failsafe mechanism that we had with 3.x.
I’m talking about the controller Rules that run every 15 minutes and toggle the devices ON or OFF based on the control point values.
In version 3.x we queried the most recent control point value directly from the influx database. If the database was not available, our influx.js returned value 1 so that the device would be turned ON as a failsafe.
Version 4.x accesses the database via openHAB persistence layer, but the documented example did not have any handling for a situation where the database would be unavailable. The result of this would be that the state of the device would remain unchanged, meaning that heating might not go ON at the night.
The wiki docs have now been updated to have proper error handling. If you are controlling a critical device such as heating or a water boiler, I would highly recommend to update your controller Rules and have the failsafe configured so that the device will be turned ON if the database is unavailable.
