Hello Olli,

I got a strange large negative value sent to InfluxDB for the hour 2023-05-25 12:00 SE3, it shows -2147483.75 cent/kw.
It should have been -0.61 cent/kw.
I have not yet checked the Arska-Node, I´ll do that later this evening.
At entso-e's site it looks normal.

//Jonas

Hello Olli,

"p diff to avg 9h" were missing in the selection list and for "Show variable details", I found that I needed to add:
{VARIABLE_PRICEDIFF_9, "p diff to avg 9h", CONSTANT_TYPE_DEC1, VARIABLE_DEPENDS_PRICE},
to "variable_st" and raise VARIABLE_COUNT from 29 to 30 in main.cpp.

I am not to familiar yet with all git functions to push back changes to your project, do not want to mess things upp.

//Jonas

Hello Olli,

I had another idéa about that in some cases it could be good to know and set channel rules that looks at how long time it is left until some channel turnes on.
In my case I use one channel to initiate loading of the accumulator tank via the heatpump and another channel to initiate unloading from the accumulatortank to the heating system via a shunt valve.
The ending of the loading sequence is done in a way that when loading command from Arska turns low the heatpump continues to load the upper part of the accumulator tank where the hotwater coil is and after that goes in to radiator heating if needed.
This can take anywhere from 1 minute to 2 hours dependant if hotwater/radiator heating is needed or not after Arska loading of tank.

So then it could be good to a variable that look at how many hours is left until channel "xx" turns on, so that the loading of the tank could be terminated in advance and the stopping sequence have time to do it´s job before unloading of tank is started.
Useful when the price has a "saw tooth" profile to create dead time betwen channels.

Some sort of precalculation (schedule?) of the relays on/off times against the channel rules on a hourly base or upon change is then probably needed in order to do this.

//Jonas

Hello Olli,

I just discovered that there is something strange with the "p diff" calculation, price were 6,1 c/Kw and 9h avg was 6,6 and 24h avg was 6,3.
The p diff for 24H should have been -0,2 and p diff 9H should have been -0,5, but instead they showed 0,0 and -0,3.

//Jonas

Running with version 1.00.0-rc1.3486 - 2023-10-20 18:23:22.

Channel rules are not saved completely. For example Rule 1 I cannot get Up mode saved, it all way returns back to Down when page refreshed.

Hello Olli,

as it is now Arska writes to influxdb once every hour how many seconds a channel has been up, this creates a hour of lag before you see a status change of a channel in influxdb.
It would be good to timestamp and send to influxdb directly when a channel has been changed, 0 or 1, and also keep the once an hour writing to be able to make more effective queries in influxdb.
The "chup" variable could be as it is, maybe a new "ch_status" or something like that is needed.

//Jonas

I had an idea about that if you calculated ( when needed ) and stored actual variables and future variables in individual arrays they could be presented in the chart for visualization, so you for instance could see how the trend for "p ratio to avg 24h" would look like for the whole avaliable timeperiod, maybe it should have a tickboxes to select?
If that is in place it should also be possible to do future calculations for the channel states and have arrays for that so it also could be visualized in chart?

//Jonas

Hello Olli,

The priceinfo from entso-e seems wrong, priceinfo is there when I look at the serial monitor but timeseries is invalid.
I created a new issue instead of continuing at the old one since this is probably a new behaviour.

#29 (comment)

It´s the same problem at both my newer 0.99.0-beta4.3344 - 2023-08-04 14:54:34 and my old 0.92.0-rc2.
My old 0.92 says the date is 1905 in the pricegraf.

//Jonas

Hello Olli,

there seems to be missing/delayed priceinfo from the entso-e platform, probably something to do with this: https://transparency.entsoe.eu/news/widget?id=63ee08ae5092e77e4d3d7bf8

Could there be an idéa to have the possibility to manually enter the prices when this happen, since they exists in Nordpool?

//Jonas

If I enter a negative target value for a channel rule it increase by approx 0.1 every time I press enter in the some of the targetboxes or select save at the bottom of the channels page.
It allso affect the other target value during save.
If I for instance enter -3 as target and save the it will show -2.900000095 after save and page update, if I save again it will show -2.799999952 and so on.
Positive values is unafected during save besides that if you for instance enter 5.1 as target it will show 5.099999905 after save, I guess it´s a floating point issue that could be rounded to 1 or 2 decimals before displaying.

Hi,
I had a thought about the "p diff to avg" variables and as you stated before that is good for deciding when the fixed costs ( transmission, fixed taxes etc., in the area of 6 cent/kw) is dominant, i.e. when price is low. For instance when price is fluctuating between 1-4 cent/kw and diff need to be bigger than 2 cents or so dependent of the deal you have with your grid operator.

But when the price is in the high range a ratio diff also need to be in place as we discussed in earlier.
The difference between radiator mode, cop 3.5 and tank loading mode, cop 2.8 is 1,25 so for instance if the 24h average price is 50 cent/kw the actual price need to be below 40 cent/kw (50/1,25) or (50*0,8) before it´s beneficial to operate in tank loading mode.

So if we add variables "p diff % to avg 24h" and "p diff % to avg 9h" ( ratio diff * 100 ) it could be set as a rule for a separate channel and connecting the channel with the "p diff to avg" in series would cover both cases.

For the future it might be an idea to select if channel rules should be treated with "OR" or "AND", then you do not need to have channel´s connected in series if you need an "AND" statement between channel rules.

I live in SE3 area so the price is all over the place during a day, between a couple of cents/kw in the early morning to 80 cents/kw during the day, looking at last week.

Moi.

1.1.0-beta3.5097 - 2024-02-10 22:25:21 Filesystem version '1.1.0-beta3.5103 - 2024-02-11 19:41:35' differs!

Tuntuu kyllä pelaavan ihan ok.

Päivittelin ensin automaatilla, ja sitten vielä manuaalisesti varmuuden vuoksi, mutta tuollaista herjaa tulee päivitys sivulle.

In order to get an Arska-Node installation to work on a Wemos d1 R32 I at first need to install Arska and from there put it to OTA uppdate mode and install littlefs and firmware for Arska-Node.
Once that is done I can change code and build/upload/monitor from Visual Studio, but if try to build filesystem and download that first in the Arska-Node project and then upload code my esp32 just restarts constantly every 2
Upload via the webbpage gives same result.

So it’s just like the setup of the filesystem is different between Arska and Arska-Node and by some reason it causes my board to crash, or my building enviroment is missing something needed in Arska-Node but not in Arska.

Hello Olli,

if we could have one variable that look at the price ratio between current hour vs next hour and one variable that look at the price ratio between current hour vs previous hour.
It could be used to detect top of next price peak or bottom of next price valley.

If you for instance want to run your dishwasher during the night or day and start during the lowest possible price before the next price peak it would be good to have a valley detection, ie if p-ratio current vs next hour < 100 and p-ratio current vs previous hour < 100.
In most cases that would detect the lowest price before next peak, most days seems to have 2 or 3 valleys and peaks and they vary in time when they occur so scheduling is tricky and this would probably work better.

//Jonas

Hello Olli,

could Open-Meteo be a road to look at to collect weather forecast such as cloud cover and solar radiation?, it has an open API and seems to be free for personal usage and it´s open source.
It could be more universal since you use latitude and longitude in the question to their API.
https://open-meteo.com/

// Jonas

Hello Olli,

I added some stuff in my local version to make the internal pcb mounted LED connected to gpio 2 to show status of the wifi connection, for easier first approach troubleshooting.
Many boards seem to have the internal LED connected to GPIO2, I do not know if all have.
Led off = wifi not connected and ESP still in setup, Led solid on = wifi connected, Led blinking = in AP mode.

//So in the end of the definitions I added:
#define onboard_led 2
bool onboard_led_state = LOW;
unsigned long last_millis = 0;

//In the beginning of setup I added:
pinMode(onboard_led, OUTPUT);

//Outside the loop I created the blink_led_or_not void:
void blink_led_or_not(){
if(wifi_in_setup_mode == true){
if(millis()-last_millis > 500){
onboard_led_state = !onboard_led_state;
digitalWrite(onboard_led, onboard_led_state);
}
}
if(wifi_in_setup_mode == false){
digitalWrite(onboard_led, HIGH);
}
}

//And in the beginning of loop I added:
blink_led_or_not();

//Jonas

Hello Olli,

by some reason the values in variables looks shifted forward 1 hour but the values in chart looks ok.
I have not seen this before so maybe it´s a behaviour that appears at dayshifting, hour 23 -> 00?

//Jonas

Hello Olli,

is there a reason to why timestamp of the data sent to InfluxDB is offset by 30 minutes so they are represented in the middle of each hour?
I started to use Grafana to build trends and currently I need to use bars with center alignment to have a good representation, if the data instead were timestamped without the offset I could use lines with "step after" interpolation and it would look more like the price graph in Arska.
Maybe that also make more sense if you later on want to do calculations, since the price in reality is valid in steps of hours.

//Jonas

Hello,
looking thru the schematics of many of the relayboards with optoisolaters available for arduino/esp/rpi etc. most of them need a low pulldown signal to activate the relay.
So maybe there should be an option of some kind that the output could be inverted?

//Jonas

Hello Olli,

I know this situation is kind of odd but not to uncommon when "price" and/or "price avg" is negative, the "p ratio" calculations is mathematically correct but the result demands different compare conditions due to what price is positive or negative.
Let´s say that the average price is 2 and current price is 1 then the "p ratio" is 50%, if I have a rule that compares "p ratio" <= 50% it would not behave as expected if average price is negative ( negative result but in reality higher price ).
Or if both are negative I would need to compare for >= 200% instead of <= 50%.

So my question is if it´s possible to have more control rules in order to have different compare conditions to cover more cases?
For some relays I have 2 rules today but to cover all cases I would then need 8 rules and 2 more conditions/rule.

//Jonas

Hello Olli,

there seem to be a large price peak tomorrow at 2023-08-13 08:00 in SE3 and the rest of the Nordic countries, it shows 1691839,7.
Entso-e´s site looks ok.

Looking at the serial monitor shows that there is something wrong with hour 32.
The value inserted in hour 32 seems to have something do do with the time?

Arska_debug_snapshot.txt

Maybe garbage values should be replaced by a average of the valid values?

//Jonas

Could it be possible to use http-get commands to control smartplugs directly like Shelly or other that support that type of commands?, as an option instead of the conventional gpio pins?
Given that they are connected to the same router as the Arska-Node.
https://shelly-api-docs.shelly.cloud/gen2/ComponentsAndServices/Switch#switchset-example
It could be easier to use for a wider audiance without the need of an electrician.

We have just noticed that Entso-E Transparency API has changed to a new server address and Nordpool price update does not work without updating Arska. More info about update at the discussion

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.

Hello Olli,

I discovered another strange thing, if I do not monitor the serial output it will not connect to wifi, it remains in AP mode.
I do not know if my router is to sluggish and is´s some timeout combined with serial not available doing this.

//Jonas

Hello Olli,

Today there seem to be something weird with getting tomorrows prices, possibly something wrong with return from Entso-e?
Since I got the"Garbage removed" string in the serial printout.
Serial dump as follows:

request sent
client_https connected
headers received
Waiting the document
Garbage removed [e73] (4)
period_start: 1666562400 record_start: 1666476000 - period_end: 1666648800
period_idx 24, price: 49.669998
period_idx 25, price: 48.380001
period_idx 26, price: 37.160000
period_idx 27, price: 25.080000
period_idx 28, price: 38.070000
period_idx 29, price: 51.970001
period_idx 30, price: 68.290001
period_idx 31, price: 103.690002
period_idx 32, price: 122.099998
period_idx 33, price: 108.910004
period_idx 34, price: 104.750000
period_idx 35, price: 81.489998
period_idx 36, price: 68.099998
period_idx 37, price: 67.820000
period_idx 38, price: 68.190002
period_idx 39, price: 76.160004
period_idx 40, price: 82.500000
period_idx 41, price: 109.980003
period_idx 42, price: 119.339996
period_idx 43, price: 125.989998
period_idx 44, price: 59.720001
period_idx 45, price: 50.500000
period_idx 46, price: 29.080000
period_idx 47, price: 23.740000
end_reached
Prices are not saved, end_reached 1, price_rows 24
Price query OK
next_query_price_data: 1666633134
time_idx_now: 43, price now: 125.989998
record_start: 1666476000, record_end_excl: 1666648800
calculate_price_ranks start: 1666476000, end: 1666648800, time_idx_now: 43
time: 1666630800, time_idx: 43 , 2022-10-24 20:00, price: 125.000000
price rank: 43 in [39 - 48[ --> rank: 9, price ratio 1674
price rank: 43 in [24 - 48[ --> rank: 24, price ratio 1757
price rank: 43 in [23 - 47[ --> rank: 24, price ratio 1719
time: 1666634400, time_idx: 44 , 2022-10-24 21:00, price: 59.000000
price rank: 44 in [39 - 48[ --> rank: 4, price ratio 793
price rank: 44 in [24 - 48[ --> rank: 10, price ratio 832
price rank: 44 in [23 - 47[ --> rank: 9, price ratio 815
time: 1666638000, time_idx: 45 , 2022-10-24 22:00, price: 50.000000
price rank: 45 in [39 - 48[ --> rank: 3, price ratio 671
price rank: 45 in [24 - 48[ --> rank: 8, price ratio 704
price rank: 45 in [23 - 47[ --> rank: 7, price ratio 689
time: 1666641600, time_idx: 46 , 2022-10-24 23:00, price: 29.000000
price rank: 46 in [39 - 48[ --> rank: 2, price ratio 386
price rank: 46 in [24 - 48[ --> rank: 3, price ratio 405
price rank: 46 in [23 - 47[ --> rank: 2, price ratio 396
time: 1666645200, time_idx: 47 , 2022-10-25 00:00, price: 23.000000
price rank: 47 in [39 - 48[ --> rank: 1, price ratio 315
price rank: 47 in [24 - 48[ --> rank: 1, price ratio 331
price rank: 47 in [24 - 48[ --> rank: 1, price ratio 331
Finished succesfully update_price_rank_variables.
Forecast location undefined. Quitting
20:15:28 Reading sensor and meter data... update_price_variables, current period 20:00
20:16:28 Reading sensor and meter data... update_price_variables, current period 20:00
Forecast location undefined. Quitting
20:17:28 Reading sensor and meter data... update_price_variables, current period 20:00
20:18:28 Reading sensor and meter data... update_price_variables, current period 20:00
Forecast location undefined. Quitting
20:19:28 Reading sensor and meter data... update_price_variables, current period 20:00
20:20:28 Reading sensor and meter data... update_price_variables, current period 20:00
Forecast location undefined. Quitting
20:21:28 Reading sensor and meter data... update_price_variables, current period 20:00
20:22:28 Reading sensor and meter data... update_price_variables, current period 20:00
Forecast location undefined. Quitting

//Jonas

Edit: Problem most likely within Entso-e since there is no graph for tomorrow at their site.

//Jonas

Estimation of effort

TBD

Acceptance criteria

TBD