[APP][Pro] Power by the Hour: Insights per hour, day, month and year

[Gruijter]

@Martin_Koning

dimmed” the solar-panels to self-consumption. But after a few seconds it automatic turned “Begrenzing actief” back to NO again.

The algorithm detects your panels still producing power, so it thinks the lower production is caused by a passing cloud. If you actively limit your solar production you should therefore repeatedly inhibit learning.

[Gruijter]

@Martin_Koning

because prices were netto-negative

In NL prices have NOT been negative yet due to energy taxes, unless you expect not being able to use ‘saldering’ this year. Do you expect to deliver more power back to the grid this year than what you use?

[Gruijter]

@Johan_Bruyn

Hold the maximum power of the PV installation on the vertical axis

Will be implemented in the next release.

[Gruijter]

@Jari_Peuhkurinen

he flow also runs and pushes a notification with “null” values.

Is this still happening with the latest stable version 8.7.5?

[OH2TH]

This is my work-around as I do not care when the price for “tomorrow” are updated at midnight.

For EET timezone there will be the rates for the first hour due to one hour time diff to CET which I guess is the market timezone reference.

And for me timeline says:
Mar 22 2026 15:59:07 Power by the Hour has been automatically updated to version 8.7.5.

I’ll add some logging to my exception handling for the true path so we will see tomorrow, if it still triggers.

[Martin_Koning]

yes. I can produce 41.000 kWh and will consume 20.000 kWh (12.000 kWh direct on Sunshine and 8.000 by “Salderen”). I will dimm this year ~13.000 kWh because of netto-negative and still be capable to use 100% “Salderen”

I have Eneco wich cost me €0,018/kWh by selling (the 21.000 kWh) outside “Salderen”.

[Jari_Peuhkurinen]

I have the test version 8.7.5.

[Jari_Peuhkurinen]

Next day prices are published around 14.00 hours at least here in Finland. I have to test the AND card. Thanks.

[Martin_Koning]

@Gruijter

inhibit learning.

I told him every switch. But it last only (10?) seconds.

[Gruijter]

@Martin_Koning

But it last only (10?) seconds

Mmh. Ok will try to think of a solution

[Ria_Banis]

This flow worked fine untill today. It did not start and it met the conditions

Also test does not work. Latest test version.

Boost Gestart | Homey

[Martin_Koning]

Last night strange behaviour.

10.00 and 11.00 expected behaviour.

[Gruijter]

@Martin_Koning

0.00 and 11.00 expected behaviour.

curtailment detection during twilight is improved in next release

[Gruijter]

@Martin_Koning

But it last only (10?) seconds.

next release: Curtailment setting via flow will be forced until reset via flow, and/or nightly.

[Gruijter]

@Ria_Banis

This flow worked fine untill today. It did not start and it met the conditions

Tripple checked, but code is fine. Maybe a one-time problem? Let me know if problem persists.

[Marcel_R]

Last night, my EV was supposed to start charging on the cheapest hours. But it didn’t and I can’t figure out why. See screenshots.

Process:

I use this flowchart. ‘LaadurenGwennus’ is calculated hours to charge (last night it was 2 and it will be updated while charging based on the data from the (Tesla) car). Calculation ‘UrenTotServiceWindow’:

• The user (car owner) sets the hour the car must be fully charged. Yesterday, it was set to 7 o’clock (this morning) and a variable Laadtijdwindow is set accordingly (to 7).
• When the car is connected before 24 hrs, the number of hours is calculated as 24 hrs - actual hour (=hourly calculated variable) + Laadtijdwindow (in this example 7). When 00 hrs is reached, the UrenTotServiceWindow = Laadtijdwindow - actual hour (UrenTotServiceWindow only calculated this way only once when car is connected).
• The car was connected to charger at 21.30 hrs, so the UrenTotServiceWindow was 24-21+7 = 10 hrs. The flowchart therefore is checking if the LaadurenGwennus (which was 2 yesterday) is one of the lowest in the next 10 hrs (till 7 this morning). Right?
• Every hour the UrenTotServiceWindow is reduced by one. So, at 22.00 hrs, UrenTotServiceWindow became 9 and at 00.00 it became 7.

However, the car started charging not before 05.00 hrs. Which is not correct, according to the cheapest hours last night:

Expected was charging should start at 02 hrs, when price was € 0,119 (in my case). Both on 15 and 60 min prices, the price was (surprisingly) exactly the same from 02.00 to 05.00 hours. From 05.15 hrs the price started increasing slightly (and of course the hourly price started increasing as well).

So, I wonder why my car started charging when the price started increasing (from 05 hrs) and didn’t start at 02 hrs (when the price was lower for 3 hrs). What is going wrong?

[Peter_Kawa]

First, I’d recommend to test again with manually entered values.
Next, you should make sure the calculated variable values are integers (no decimals), check it by adding log or notification cards with these variables added.
Something like:

[Marcel_R]

Thanks for suggestions. Unfortunately, check for integer was done and timeline notifications after many steps in flows were added. Nothing unexpected. I will do some additional tests again, as I removed all timeline notifications already. Let’s see.

[Ria_Banis]

This seems to me an unlikely measurement, since I have an installation of 3825 Wp.

[Peter_Kawa]

No problem!

@Marcel_R

as I removed all timeline notifications already.

Yeah I’d like to see a “disable” function for flow cards.
Second best is to just leave those cards, and only remove the connected line.