There are a couple of approaches here but even the automatic retry won’t guarantee that we have prices for tomorrow. Entso-E might be down for a longer period i.e. tomorrow starts before Entso-E / spot prices becomes available.
One way would be to create a new Item called “Last successful spot price fetch” or something similar.
Then the Fetch Spot Prices Rule could be running every 30 mins and the first thing the Rule Script would do is to check whether the “Last successful spot price fetch” contains a value that the spot prices have not been fetched yet. If they have not been fetched yet, then proceed with the fetching. If they have been fetched already, we would have an early exit.
Another approach, which I actually like better is that we would not have that extra Item, the Feych spot price Rule Script would check directly from the database if we already have prices for tomorrow. If yes, exit early. If not, proceed.
Finally, there could be a separate Rule which would be executed for example 15 mins before midnight. If we still don’t have spot prices at that time, clone the control values from yesterday.
I don’t have time to implement these at the moment (curling season is at full swing at the moment + I’m building a sauna at the moment) but these concepts are here so if anyone wants to implement these.
I haven’t changed the published files in comment #13 in many months. In other words, the scripts behave exactly the same as these versions have been behaving earlier. In yet other words, either this behavior has been there forever (in theee versions) or your local setup has something that causes your unexpected behavior.
If you have 3 slices, those are 00-08, 08-16 and 16-24. If you’re forcing that each slice must have at least some heating, isn’t this expected behavior?
I updated the nibe.js.txt published in #13 and it should now be working as expected. Would be kind enough to test it? (First back up the version you are currently using).
Finland is changing to winter time today. Maybe the rest of Europe is partaking in this ritual, too? In addition to all other problems this outdated redundant practice causes, it also prevents this script from calculating heating hours correctly today and twice a year when the change between summer and winter time happens. See the post this post is a comment to how to get heating to work right during the transition.
Something strange happened to me too. I use nibe.js to control the electric floor heating (fixed 8 hours, 1 slice), and also waterheater.js (3h) to control the electric boiler. The boiler control (on: 29.10 03:00, off 29.10 06:00) seemed to work but the electric heater had stayed on (on: 28.10 23:00) and is still on (29.10 15:21). Certainly will be corrected at the end of the day.
Does anyone have experience from Ohmigo?
They seem to have some nice spotprice devices and also an analog temperature sensor (resistance)
that can be controlled over Wi-Fi.
Many thanks for this great add on. I’m gradually integrating this to my OH4. I have Nibe S1255 heat pump, small 35l Haato electrical boiler and a circulation pump which circulates the water through a small radiator. This consumes a lot of electricity on a yearly basis. I’m now replacing my Ouman EH686 controllers with Ouman Ouflex A XL controller so it is really easy to setup a time program for the circulation pump. I’m using Modbus TCP for the heat pump because the Nibe binding doesn’t work with S series pumps. I haven’t thought yet how to control the heat pump using your rules.
I’m now on your comment #13 and I can now fetch the spot prices and save them into influxdb. Also the FMI rule works well. I haven’t tried yet the rules for determining the cheapest hours but I don’t see any major problems at the moment.
My question is related to your script for an hourly rule that updates the spot_price Item. At first the value for spot_price was 1 yesterday evening and I thought that I hadn’t configured influx.js correctly. This morning I noticed that the rule had fetched the hourly prices correctly. I don’t want to use Grafana because it would make my OH setup even more complex so I want to stick with OH charts. My chart for spot_price shows the values until now but are there any possibilities to show all the future values as well?
For all non-finns that are watching this thread. Today is the most absurd day in the history of the NordPool day ahead market.
The spot price from this afternoon 15.00 EET onwards until 01:00 tomorrow is -0.62 c / kWh. Yes, you read that correctly, that is a 10 hour window where electricity users are paid for consuming electricity.
Kinect Energy AS from Norway made an erroneous bid yesterday and promised to sell 5787 MWh of electricity to Finland for every single hour today. Nordpool made a decision yesterday that the bid is binding. So they are now in a position where they are have promised to sell 10h * 5787 MWh = 57 870 MWh with a negative price of -500 € / MWh. That’s -28.9 millions of euros.
Many other producers decided to cut their production in the day-ahead auction yesterday (because they did not want to pay for producing electricity) so now Kinect Energy needs to buy the capacity they don’t have from other producers from the intraday market in addition to selling it onwards with a negative price. This small error is going to cost them tens if not hundreds of millions of euros on top of that 28.9 millions.
I have this consumption factor based agreement where the discount I get depends on how much our consumption is below the monthly average of the spot market.
Before today:
We have consumed 976 kWh so far this month. The avearge spot price before today was 9.18 c/kWh and we were 2.09 c/kWh below this. If the
If the month would have continued like this, we would have ended up paying 8.8-2.09 = 6,71 c/kWh this month. Extrapolating the consumption, that would have landed at 1330 kWh so our bill for the energy would have been 90 euros.
Do nothing today
Because of this Black Friday discount, the monthly average price drops from 9.18 to 7.8 c/kWh. If we do nothing special with our consumption, that means that our consumption factor would go from -2.09 to -0.72 c/kWh. Meaning that with the 1330 kWh consumption we would end up paying 108 euros instead of the 90 euros.
Go to sauna today
If we would have for example 100 kWh of extra consumption, our consumption factor would go from -2.09 to -5.55 so our monthly price would be 8.8 - 5.55 = 3,25 c/kWh. Taking the extra 100 kWh consumption into account, we would end up paying 48 euros instead of the 108 euros.
We’re probably not going to consume 100 kWh extra but the car needs to be charged and we’re definitely going to sauna this evening (it’s Friday evening, after all). In addition to this, there is some laundry to do and dishes to wash and our kids love to bath. And the house needs some heating. So completely normal consumption for us, just like Fingrid recommends.
On 23/07/02 13:00, German stock price was -59,5ct (yes, minus) and Tibber charged me -42ct.
The variant of your question in the country of Autobahns this has brought up was: should I charge my car or should I sympathize with a stock listed company.
Unfortunately I still have a fixed price contract (5.4c/kWh) until end of December so I can’t enjoy these negative spot prices.
As I said couple of weeks ago I can fetch the Entso prices but I can’t plot the future values with OH4 and I don’t want to use Grafana. I haven’t had any time since then to look at this issue again. So, how I can plot the future values?
I’m now programming one of my Ouman Ouflex units and I got an application for the Ouflex unit which allows me to control my Nibe heat pump (compressor and hot water) using the Ouflex hardware so I don’t necessarily need to use the OH rule option discussed in this thread.
