PV_KonsumpcjaDzisWoPC.postUpdate((PV_AutokonsumpcjaDzis.state as DecimalType) + (Ex9EMS_DayUsage.state as DecimalType) - (SDM_DayUsage.state as DecimalType))

Basing on that I have some notifications running when next tresholds are achieved (NORMAL, WARN, CRIT). Problem is that for first I’m getting info that level WARN is meet, and in few minutes that level goes back to normal - it’s not possible (same thing in case of WARN->CRIT->WARN).

I’ve mede some graph of values of above items, and strange is that fluctuations appers on “PV_KonsumpcjaDzisWoPC” item, but not on any other item on the basis of which the rule performs calculations. Any clue why?

Number PV_KonsumpcjaDzisWoPC “PV daily energy usage without Heat Pump [%s]”
Number PV_AutokonsumpcjaDzis “PV daily energy autoconsumption [%s]”
Number Ex9EMS_DayUsage “PV daily energy import [%s]”
Number SDM_DayUsage “Heat Pump daily usage [%s]”

Not really. We cannot see any of your rules, any of your Items. We can’t see any of your data and we don’t know where it comes from.

Is this by a rule? Put some logging in your rule so that you can see what data it is dealing with.

I’m not sure what we are supposed to see as fluctuations here? Is it the little downward steps?

So X = A + B - C
What happens if you expect A,B,C to come as a set of readings, but then A gets updated first? In other words, when you calculate is rather important. (Rule trigger conditions)
X = new A + old B - old C
or any combination.
Maybe it will run again in a moment
X = new A + old B - new C
You’d get some odd results from that.

Thanks for the point. Problem solved. In this case the source was that values of those 3 item came from 2 different power meters, even from 2 separate bindings and data refreshing at the same time is not possible.

different power meters → different manufactures → different accurancy,

multiple integration bindings (http/json, modbus) with different delays and not synced refresh intervals.

I managed problem differently on logical level of rule. Rule is blocking possibility of going back to previous state, so in sequence, NORM could only change to WARN, and WARN only to CRIT. After that going back from CRIT to NORM requires “PV_KonsumpcjaDzisWoPC” to have value near 0 (<3).