v. 1.5.10 ready for testing:
- Fixed date handling
1 Like
Hello,
thank You. Though, in my case now the time-zone issue seems to be back, e.g this night the midnight (00-01) data is missing again (for EET timezone). The max of the yesterday’s peaks seemed to catch the right values.
Could You please comment also about the ‘price ratio’ usage and limits.
1.5.11:
- fix for missing price at 00-01 for EET timezone
1 Like
Check the post 92 that I wrote before for price ratio usecase.
Thank You. I saw that post as well. What I mean is that is the gain of this app in range from 0…1, or from 1…0, or something else? Gain itself uniform or exponential or something else, etc?
Aah ok, misunderstood.
The gain is evenly distributed along the 24 hours of the day based on the price of the current hour. During highest price hour it’s 0 and during lowest it’s 1.
Hello again.
I looked at the price ratio / gain values from the app, from the last 24h (02.11.2021), for EE area, and I am still not too confident of what does the ‘price ratio’ mean, or how it is calculated. So, I took the stock prices, and computed by hand, assumably with linear scale, from 0…1, as described earlier, and then I also took the values from app for the same period and put them to the same graph. The outcome is below (blue: price, red: calculated gain, green: gain from app). PS the 00-01 hour value from the app was missing, so I used the calculated value. I noticed, that the max and min values match for 0 and 1 notations, but all the others are different. Also, it would be great to get some comments of why the price ratio value could fluctuate quite much, while during daytime the stock-price was rather unchanged?
(I used such formula for calculation: Gain = (Pmax-P)/(Pmax-Pmin), where Pmax and Pmin are max and min values of that 24h period, and the P is the current Price value). Of course, it could be totally incorrect, so please comment…
Hi
The price ratio is evenly distributed along the hours of the day. So it is not the price difference normalized between 0…1 like you have calculated, but it is the days prices sorted based on the price and given running number based on the index like so:
- sorted prices
- calculated price ratio as
1 - index / 23, rounded to 6 digits
If the price ratio is calculated your way, there might come a following situation in the intended usecase:
01.00 hour price is 0,01€/kWh and all other hours are 0,5€/kWh. The price ratio is used to control thermostat with calculation ThermostatSetValue=16+(26-16)*(1-PriceRatio). Then the thermostat set value is 26degrees at 01.00 hour and 16 degrees in all other hours. This will end up in cold house. Or this could be also other way around and you end up heating the house 23h of the day. If the price ratio would be evenly distributed over the days hours, the heating would commence with lower setting with other hours.
Hope this clears the idea of the price ratio.
Oh, understood, I think. The ratio shows then the price’s position/ranking on the asending/descending list of the 24h prices. E.q. if some price is on the top third (lowest), then gain = 1-2/23 = 0.913043 (and indexing is from 0…23). So the ratio values are fixed figures and do not depend on the actual price.
So, in this particular case of 02.11 prices, then the system would change the target temperature quite much, even when the price could be only a fraction lower from the other high prices before and after (e.g. at 09:00 and 17:00 on the graph)?
Correct. In the case you presented the setting temperature changes a lot. But for example in my usecase I set the underfloor heating temperature so the changes doesn’t affect so much. See the picture below. So it depends on the usecase and the “variation” limits you use. For example you could use the calculation 20+(22-20)*PriceRatio to give more moderate changes.
If you want to use the normalized value instead maybe you can convince @balmli to implement that too.
Hello,
I think that the differentiated price ratio is not too important. I would be more happy, if the delivery-pricing for double-tariff scenario could be implemented. E.g. by defining the ‘working hours’ and ‘nonworking hours’ as tariff-zones, and having additional price parameters there for both tariffs, which are added to the stock price before the ratio is computed. Though, in our case the tariff starting-ending times during DST (summer/winter) are shifted, so e.g winter time the “day” is 7-23, and in summer 8-24. Of course, there is an option of creating two controller instances…
1 Like
Hi @balmli
I have tested the triggers again after your corrections:
The high price 6 hours of the day (flow 1) trigger and other one with utility price change trigger and 6h high price condition (flow 2) . I also made the same trigger with the CLI installed nordpool app (flow 3) .
The flows 2 and 3 seem similar, so they work. But the flow 1 shows quite a different behavior. (See the picture below) Have I understood the operation wrong or is there some error in it. The low price triggers with these same kind of flows work correctly.
I also think that the delivery-pricing would be nice addition. In the meanwhile I make the control over spot price only and change the delivery pricing tarif if needed.
The “High prices X hours of the day” trigger and the “Current price is among the X hours of the days highest prices” condition do not behave the same.
For the trigger:
- Only hours where ‘ECO mode’ is enabled are controlled
- If there are two consecutive hours with high prices the second hour is skipped, to avoid having heaters turned off too long, or having thermostat temperatures to low too long
1 Like
I´m struggeling a bit with wrapping my head around how “Low prices x hours of the day” relates to the two variables heating and low_price. Are those variables set by the app when the price changes every hour based on nordpol without me having to create a flow for them to change?
If heating and low_price is set by the Heating Controller app, will this flow make sense?
«Heating» is a flow token, and set to Yes if in the comfort hours of the day.
«Low price» is set to Yes if among the lowest X hours.
So, this flow will trigger every hour, and turn on if in the comfort period, and among the X hours with lowest price. Otherwise turn off.
Thank you for the quick reply. I´ll try to go with this flow for a while and see how it turns out.
Many thanks for great app.
It is possible to add strømpriser for Sandnes and Stavanger aswell also?
All five Norwegian priceareas are supported
