I decided to refactor my scripts to Javascript so that I can reuse the code in different places. I hope to be able to share my rules and where I am either today or tomorrow.
What’s working so far, but I’m currently working to refactor the code:
Fetch spot prices from Entso-E API and store them as future-timestampped points to InfluxDB
Read the stored spot prices from InfluxDB and calculate the on/off hours for the waterheater based on that. These on/off hours are stored as different future-timestampped points to InfluxDB
An hourly rule that runs every full hour that checks if the waterheater should be turned on/off and controls the GPIO output. I currently have a simple buzzer connected to the GPIO but I should get my father-in-law (an electrician) to do the relay & contactor connections in the next week or so.
The blue area in the figure above represents the spot prices. The yellow bars indicate when the heating of the house will be ON and the red bars indicate when the water boiler will be ON to heat domestic hot water. The solution can be used with any devices you can control with openHAB.
The comments between this and comment #302 are related to the older version of the solution. Comments from #302 onwards are related to openhab-spot-price-optimizer linked above.
Thanks all who helped and pushed me to the right direction along the way!
If you have any suggestions to improve the code, I’m all ears.
And one more disclaimer: I promised myself 21 years ago that I will never ever touch javascript again and this is now the first time I broke that promise (I have to admit it was not that bad after all.) But having said this, this is literally the first time in more than 20 years that I’m writing JS so it might be that I’m not following some conventions properly…
I edited my own comment #13 (which has been marked as the solution) so that it now also includes the control logic for my Nibe ground source heat pump.
I read the weather forecast from the Finnish Meteorology Institute’s API and store the temperatures for each hour to Influx database.
Based on the average temperature for the day, I will determine how many hours the heat pump compressor must be allowed to run. When it’s -20 celsius, 22 hours will be required (I can avoid 2 most expensive hours). When it’s +20 celsius, 2 hours will be required for heating the hot water. This heat curve is configurable in the code.
Once the number of hours is known, I’ll determine the control points as “nibe_control” measurement points.
To avoid a situation during the winter where the heat pump is on for say 12 hours in a row and then off for the next 12 hours, the day can be split to a desired amount of “slices”, for example 2 x 12 hours or 3 x 8 hours.
For every slice, we can define a minimum percentage of the “on” hours. Example: Let’s say 10h of heating is required and the day is split into 2 slices. We can define that at least 10% of the 10 hours must be allocated to all slices. Meaning that both slices would have 0.1 x 10h = 1 hour of heating.
The slices and percentages are configurable in the code.
Looks like a really nice solution I will try to use the most of your solution, but will try to use mariadb instead of influxdb, I do not know if thats even possible but I will give it a try as soon vaccation is over and I’m at home.
Regarding the MariaDB vs. InfluxDB. The key gotcha here is that you must be able to write measurement points with future timestamps.
I decided to move my database to run on a NAS server instead of the Raspberry when openHAB runs so that I can minimize the write operations to the Raspberry SD card. When I did that transition, I tried to use MariaDB (which was available on my NAS with a point-and-click configuration) but I was not able to figure out how to write points with future timestamps, see Is it possible to use the JDBC service to access MariaDB from a script
If you’re able to crack where I went to the woods, feel free to comment on that thread.
I ended up installing InfluxDB on my NAS and it’s now up an running. The first results look quite promising. The screenshot below is from my electricity company. The black line is the price and bars are my consumption.
Hi now I am in the deed of getting this tested for my solution, and I am absolutley no professional programmer but I try to learn as we go.
I stole all your scripts and folder structure for testing, influxdb runs in a docker container on an synology nas and openhab succeccfully writes other data to it.
I did change database adress and token in influx and set token and area in entose.js
But when I create rules and launch them all rule fail with
Script execution of rule with UID ‘a8a539c0b4’ failed: ReferenceError: “require” is not defined in at line number 1
Do I need to install any extra script engine or will it run with ECAM 262 edition 5.1
It might be a problem with the xslt transformation. When I trigger the rule and use xml2json.xsl the following error occure that ´probably ends up not having any values there right now.
The value of attribute “test” associated with an element type “xsl:if” must not contain the ‘<’ character.
And I found documentation about that < was not allowed and nedded to be replace with < thats the correct operator. When I did that I do not get that error but still no data in influx.
FORECAST SCRIPT
Errors with
fmi.js: Making an API call to FMI API…
20:27:04.890 [ERROR] [org.openhab.automation.script ] - fmi.js: Temperatures parsing failed!
20:27:04.897 [INFO ] [org.openhab.automation.script ] - influx.js: Preparing to write points to the database
And fetch spotprice erros with
entsoe.js: Making an API call to Entso-E API…
20:30:35.173 [INFO ] [org.openhab.automation.script ] - entose.js: transforming XML to JSON and parsing prices…
20:30:35.283 [ERROR] [org.openhab.automation.script ] - entsoe.js: Exception parsing spot prices: Invalid JSON: :2:0 Invalid JSON: String contains control character
" :
^
20:30:35.287 [INFO ] [org.openhab.automation.script ] - influx.js: Preparing to write points to the database for spot_price
The error message here means that you are not able to read the forecaster temperatures from the the Finnish Meteorology Institute’s weather forecast. You most probably do not want to read the weather forecast from Finnish Meteorology Institute anyway?
To narrow things down, you can temporarily modify the rule script so that you don’t calculate the number of hours based on the weather forecast. Instead, just put there a static value like 5 when you’re debugging this:
dh = require('kolapuuntie/date-helper.js');
nibe = require('kolapuuntie/nibe.js');
start = dh.getMidnight('start');
stop = dh.getMidnight('stop');
// Comment out these two lines that fetch the weather forecast and calculate how many hours are needed.
// t = nibe.getForecastTemp(start, stop);
// n = nibe.calculateNumberOfHours(t);
// Temporarily define the number of hours as five.
n = 5;
nibe.determineHours(start, stop, n, 3, 0.1);
You can add a couple of debug messages so that you can see from your logs what is going on.
Add the debug lines like this to get the complete XML response written to your log:
function makeApiCall(start, end, area, token) {
[...]
priceXml = http.sendHttpGetRequest(url, 10000);
console.debug('Complete XML response:');
console.debug(priceXML);
return priceXml;
Add these debug lines to see if the XML to JSON transformation works:
If (when) you modify the javascript files, you need to “refresh” your rules so that openHAB will use the updated versions of the js files. This can be done as follows:
Go to edit the rule that uses the js file
Save the rule
Run the rule
If you don’t go to the edit mode and save the rule, openHAB will use the old version of the JS file it had read to memory before.
Thanks for your efforts to help me out, I managed to get some xml output after changing console.debug to console.log, but somewhere in xml2json there must be a problem, I don’t se any output from extensive console.log in xml2json function. Meybe it wasn’t right to change < to
<
In the xml2jsonfile, I downloaded an copy an pasted xml2json file again and now it works better. However influx db doesn’t contain much data spotprice came up but only one price point
The reason why you’re not seeing more than one value is that your Influx Query is searching for data for “past 1 hour”. Change the range to include tomorrow and you’ll see tomorrow’s spot prices
Thanks again for all your efforts of helping men out. I will be out travelling for next couple of days but wilöl have spotprice fetching rule up an running every hour for the moment I did indeed have more data if I set a different filer .
I did get FMI forecast script to runt but it didnt write an mesurement, and I beleive that thats the reason why nibe and waterboiler script fails theres no temperature forecast. I will probably convert this to my local realtime temperature but thought I will get this nice example up and running before I start modifying to much. And I will also integrate this with my Easee EV wallbox.
The last row means that “between the start midnight and stop midnight, find a 4 hour window when the spot prices are lowest”.
Our hot water consumption does not depend on the outside weather. Four hours should be easily enough to heat the water for the whole day.
1 kWh will be required to heat 864 liters of water by 1 degree
My water heater has a 300 liter tank so it will require 300/864 = 0,347 kWh to raise the water temperature by 1 degree
My water heater is 3 kW so letting it run for 4 hours means 12 kWh
Which means that 12 kWh can raise the water temperature by 12/0,347 = 34,5 degrees
This is easily more than enough because the water heater is “behind” or “after” the Nibe ground source heat pump which pre-warms the water in its 180 liter integrated tank to 48 degrees so the starting point for the water heater is barely ever under 40 degrees.
I’m currently planning to install a couple of DS18B20 temperature sensors to the outer shell of the tank of the water heater so that I could measure how cold / warm the water is already and then determine if I need to allow 1, 2, 3 or 4 hours of heating time for the water heater.
Here’s what I’ve been able to achieve so far. Blue bars is my consumption which I’m able to fetch from the power grid operator and green line are the spot prices. You can see nice consumption peaks when the prices are lowest.
July 26 and 27 were hugely exceptional days in Finland in terms of the spot prices as there was a lot of wind power and at the same time the Baltic countries had planned maintenance in their power grid which meant that they could not import electricity from Finland which they normally do. I think we washed laundry something like 4 or 5 times, cleaned the oven with pyrolysis and so on.
My electricity contract is not directly bound to the Nordpool spot prices (i.e. spot price + margin). Instead, I have a contract which is 14.8 c / kWh +/- “consumption factor”. The consumption factor is calculated as follows:
consumption factor = (A-B) / E, where
A is the sum of consumption * spot price over every hour of the month
B is the total consumption * average price in Nordpool for the month
E is the total consumption of the month
In other words, if I use power on hours which are cheaper than the month’s average spot price, the consumption factor will be negative and decrease the price that I pay of the whole month’s power. With these optimizations this means that the 14.8 c/kWh is effectively a ceiling price that I will have to pay under any circumstances, even if the Nordpool would be at 100c / kWh next winter.
Here’s a 7 day trend for the consumption factor. If I would be able to keep this trend, I would pay 14.8 - 5.9 c / kWh but it’s not going to be that much negative because the July 26-27 was so highly exceptional. But anyway, this I will have a double digit discount to the power bill, which is is quite nice
It seems like I’m having trouble to write measurments to influxdb other OH dta appears to be right but this data just doesn’t get in there. I’ve verified ip and api token org and bucket name but nothing really changes the game. Influx db version 2.3.0 snapshot.
Hi I was perhaps unclear, nothing writes for a certain I only got one days of spot price data even thoug logging looks good. I activated a log for whats written to influx db an theres a value=some price anf a blank anf a epoch time (maybe)
