Hi folks
I’m on V4.0.3 and haven’t encounterd any problem yet, use multiple scripts for diffrent stuff, EVcharger,P Pool heating x2, Pool filtration x2, Nibe heatpump.
Hi
I am on OpenHAB 4.0.2 and it works and is stable. 5/5
Hi,
I’ve revived my old EntsoE binding for testing if you’re interested:
1 Like
Anyone else having trouble getting day ahead spot prices for Finland today? I can not download them.
Edit: It would be nice to have this automated, so that the rule retries with e.g. 30 minute intervals until the spot price can be fetched. Any ideas how to implement?
Edit2: @gitMiguel s EntsoE Binding Thing gives “Offline” error when the Entso-E does not provide data. This could be used to recognize failure.
Edit 3: I still have not figured out how to get this to retry upon failure.
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.
Markus
1 Like
Seems this bug has crept back in?
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.
1 Like
I updated the script to the one this post is a comment to. Does anyone else still see this behavior:
For some reason the algorithm selects the expensive hour at 15:00 instead of the cheaper hour at 20:00.
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?
Indeed. I thought I had 2 slices, but alas, it was 3.
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).
Cheers,
Markus
1 Like
Tested it. Seems to work as exptected with both 2 and 3 slices.
1 Like
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.
1 Like
There is now a moral question many finns have tonight: Should I heat the sauna tonight or should I sympathize with a stock listed company. 
I think the decision is easily made.