Closed joe-ave closed 2 years ago
Giving formulas is not possible as such, because the software does not have a parser/engine that could interpret user-given formulas. So you can compare variables only with constants. We do not want to have too many variables, but it is basically possible to add a new variable that could solve this kind of case.
Price rank variables "price rank 9h" and "price rank 24h" are maybe not good enough in your case If "price rank 9h" value is 1, you know that it is the cheapest hour within the 9-hour sliding window, but you do not know the difference between the average and current value. So you are interested in relative difference (current value/average), not absolute (current-average)? If you also pay for the transmission of electricity (per kWh), small absolute differences in the price of energy are not necessarily significant even if the relative difference is large.
One solution could be to add variables showing the ratio of the current price to the average price. E.g., if the current price is 5 and the average within a sliding window (9/24 hours) is 10, the variable value would be 0.5 and you could compare it to a constant value. But when the additional fixed cost (transmission, taxes...) per kWh is dominant, the absolute difference between average and current energy could work better.
The solution with ratio would work!, for the average calculation maybe it should be possible to select average current day or average current day + next day to get as long average as possible. For a function with a sliding average, I guess it should always be looking into the following 9/24 hours, some kind of workaround or freeze of calculation probably need to be done if not enough datapoints is avaliable for calculation.
And absolute difference probably behaves better, with relative difference you probably need to have a ”break even” point so that the it’s not active below a cetrain price.
The sliding time window is from the current hour forward 9/24 hours, if price info is available. In normal conditions, there should be always future price info for 9 hours. Because price data for the next day comes in the afternoon, 24 h sliding window uses hours from history to get 24 hours data, until price data for the next day is updated.
I will check first, what it takes to calculate absolute difference variable values (current-average) for the sliding time windows.
4 new variables, average price, and current price difference (higher than) average are added to 9 hours and 24 hours sliding windows. For example: "p diff to avg 9 h" < 5 matches if the current price is at least 5 cents/kWh lower than the average price within future (including current hour) 9 hours.
Build versions updated to the install page
It seem to be working!, thank you!
I used the files for the ESP32 Dev Kit for my Wemos D1 R32 board, I have seen other suggestions for boardtype to use in the PlatformIO file but this also seem to work. Now I just need to do some calculation about break even for the fixed costs / kW when operating the heatpump in floating ( radiator ) vs fixed ( tank ) mode.
Great!
The demos are made with cards with relay modules which allow basic setup without soldering of relays. But your board is fine if it works 😀. Channel count (-DCHANNEL_COUNT) and channel gpio numbers (-DCH_GPIOS) are hardcoded into the build program code - that is basically the main difference between the versions in platformio.ini . You should be able to run software with a "wrong" version, but relays are probably not working. And if you accidentally upload a new version with a different channel count, it will break stored settings - resetting settings from the admin page will help in this case.
New variables (see variables # 5,6,9 and 10 ) added to the system. Variables 9 and 10 allow comparing the current price with the average price of the sliding window of 9 or 24 hours.
Hi, In channel rules could it be possible to compare variabels against other variabels and for instance have it multiplied by a fixed value?, something like : if(average_price_today >= current_price * 0.7)? This is because I want to switch my heatpump between radiator mode with floating condensation that has a COP value of approx 3.5 and accumulator tank charging mode with fixed condensation and approx 2.8 in COP due to higher temp output. During tank charging mode and as long as there is energy to deliver from the accumulator tank radiator heating is controlled by a schunt valve. So the pricedifferance need to be big enough before it becomes beneficial to operate the heatpump in accumulator mode.