Energy rule

rlkoshak · February 14, 2018, 9:11pm

withTimeAtStartOfDay

I have no idea why they use with instead of to.

tomhag · February 16, 2018, 8:49pm

Thanks! Updated rule now, and will see if it works.
Week and month is maybe OK as it is. But i’m using day every day to see my 40 meeters

tomhag · February 18, 2018, 6:01pm

Hi again Andreas,

And thanks for the answer.
The complete line for this, should it be like this? I still need three bracket at the end to close the previosly?

    BilVarmeDag.postUpdate(BilVarme.deltaSince(now.toDateTimeAtStartOfDay()))

I cant get it to work as intended. Or maybe i misunderstand. My goal is to show the value in realtime of how much i use today. So if i use 1kw/h, then it should say 0 at 00.00 and 1 at 01.00, then at 17.00 when i look at all my meeters this one shows 17kw/h.

Josar · February 18, 2018, 6:20pm

@tomhag maybe you missed what @rlkoshak posted and yes you will need the closing brackets.

withTimeAtStartOfDay != toDateTimeAtStartOfDay

So it should look like this

BilVarmeDag.postUpdate( BilVarme.deltaSince( now.withTimeAtStartOfDay() ) )

tomhag · February 18, 2018, 6:30pm

Thanks Josar, i read what Rick was reading but then i started to copy/past and forgot
Updated now and will see tonight if it works, thanks also for clearifying about the brackets.

imhofa · February 19, 2018, 9:17am

Hi Tommy,

sorry, you are right about the brackets. You Need for every opened bracket a closing one. So you need one for:

withTimeAtStartOfDay
deltaSince
postUpdate

The other problem about “realtime” values:
Your rule triggers every night at midnight (“0 0 0 * * ? *”), so your calculated items are updated once a day at midnight.
If you want to update the items more frequently, you have to change the trigger condition.
For the energy consumption for the current day I would suggest a second rule, which is triggered on every Change of BilVarme. So if your power meter updates the value, the consumption for the current day is also updated.

Andreas

tomhag · February 19, 2018, 9:31am

Hi again Andreas,

Ofcourse as calculation is done at midnight, so for this solution the “day” should be a standalone rule.
But is there a better way to do this? I do have the “total” counter and also a reset.
If i reset the total at midnight the “total” will only count that day.
But will that be a problem for week, month and year?

I tried with a simple rule at the end for this.

BilVarmeReset.sendCommand(ON)
BilVarmeReset.sendCommand (OFF)

But that did not do it, dont know if my rule is wrong or if it happens so quick that it does not reset? Maybe there should be a “wait” for 5 seconds?

imhofa · February 20, 2018, 6:48am

Hi Tommy,

if you reset your total value each day you will have a problem showing your weekly/monthly/yearly values.
The assumption for this kind of usage is, that you have an energy Counter which is counting up without reset. If you reset the counter, you will get negative values for your weekly/monthly/yearly values which are indeed wrong in this situation.

I did not get the logic for resetting the counter and why you want to reset the counter.

You have energy meters which are:

counting up
overflow at 65556 (to start at 0 again)
some of them you can reset manually

I would use two items for each energy meter:

the actual value of the energy meter
the sum/total of the energy meter

The first item represents the value you get from the counter. Via rule you update the second item from the first item with respect to overflows. Therefore your second item has the actual value since you started your measurement. So if your energy meter had the third Overflow, the second item should have a value around 196.668

Your reporting is done with the second item, which has no overflows and shows the real values for week/month/year.

With this Approach you don’t need any manual reset of the energy meters…

Andreas

tomhag · February 23, 2018, 7:52am

Thanks for all the input.
My solution ended up with this rule, this way i get the energy comsumption today(updating at every change), yesterday, week, month and year. I think the information you get from one sensor makes it valuable with this rule. Hope this can be usefull for someone else.

rule "Update power BilLading"
when
    Time cron "0 0 0 * * ? *"
then
    BilVarme.postUpdate(BilVarme.state as Number)
    BilVarmeDag.postUpdate(BilVarme.deltaSince(now.minusDays(1)))
    BilVarmeUke.postUpdate(BilVarme.deltaSince(now.minusWeeks(1)))
    BilVarmeManed.postUpdate(BilVarme.deltaSince(now.minusMonths(1)))
    BilVarmeAr.postUpdate(BilVarme.deltaSince(now.minusYears(1)))	    
end

rule "Update power BilLadingNa"
	when
		Item BilVarme changed
then
	BilVarme.postUpdate(BilVarme.state as Number)
    BilVarmeDagNa.postUpdate( BilVarme.deltaSince( now.withTimeAtStartOfDay() ) )
    
end

imhofa · February 23, 2018, 12:24pm

Hello Tommy,

good to hear you got it working. As exlanation to others:

BilVarmeDag   : consumption yesterday
BilVarmeUke   : consumption since last week (from yesterday) / 1 week
BilVarmeManed : consumption since last month (from yesterday) / 1 month
BilVarmeAr    : consumption since last year (from yesterday) / 1 year
BilVarmeDagNa : consumption today

But can you tell me, why you are Setting
BilVarme.postUpdate(BilVarme.state as Number)
in both rules ?

Andreas

tomhag · February 23, 2018, 1:17pm

For me it just makes sense to not to this at all, because in items its a Number Item.
But this was to input i got at the start from Rich, and also Eclipse Smart home designer i got an error that it was undefined.
Do i need it?

The reason i keep it in both rules is that some meeters will not change in days, so days will trigger before change of value, but other will trigger with change up to every minute.

imhofa · February 23, 2018, 3:45pm

The idea from Rich was to store your (running) meter value to the “Last Day” item at midnight… The source and target items were different in this very early post…

I think, you don’t need this anymore…

Andreas

tomhag · February 23, 2018, 9:17pm

Ok, will delete it and test it.

My next step now is to try to categorize the meeters in “Heat”, “Lightning” and “Others”.
Do you have an advice on how to do this? My first thought is to tag it somehow and then use a rule that sum all meeters that are tagged with “Heat”.

imhofa · February 24, 2018, 7:00am

You can use groups to manage this. Have a look here:

Andreas

tomhag · February 24, 2018, 6:09pm

Thanks Andreas.
If you have any tips on how to understand rules better im always looking to learn as this way of doing it is new for me. I have been using block engineering for 10 years but not “script”.

imhofa · February 24, 2018, 6:56pm

Hi Tommy,

to get used to writing rules I recommend to read as much of examples as possible. Just search for topics you are interested in and give it a go. Or look within the rules topics to read about different rules: what they are doing and how they are programmed.

If you have specific problems, just give it a go and ask the community.

Try to read about groups and sums. You will get a lot of information. Try to adapt the examples to your like. If it is not working the way you thougt it should, try to read more or ask…

Andreas

tomhag · March 6, 2018, 1:39pm

Hi again,

I got values on week/month/year, but it did not make any sense and then it stopped.
I did not do any changes to the script, and also i have tried make a new .rule file with only this rule to make sure nothing else made this.
Database seems to be working and for day everything is perfect.

Any ideas?

imhofa · March 7, 2018, 9:52am

How is your continuous meter value (= Item BilVarme) in this time frame?
Can you check the values for BilVarme in the given time period?
If you have the values you can just calculate “by hand” which should be the correct value…

The graph shows that the difference between the value from now and one month ago is 124 kWh.

OR: the rule is not working / called any more and you get no more updates to your Item BilVarmeManed…

Just add a log entry at the beginning of the rule (first line after “then”):

logInfo('logEnergy', 'Rule Update power BilLading executing. BilVarme = {}', BilVarme.state)

Every time your rule is triggered, you get a log entry with the actual value of BilVarme. With these logs you can see what is going on… (if the rule is triggered and which actual value is used to calculate the difference)

Andreas

tomhag · March 7, 2018, 12:15pm

Hi again Andreas,

Thanks again for a very detaled help.
The BilVarme is continuing to count, so thats not it.
I also made this rule for a seperate meeter, i see that today i got the “week”, maybe because it did not have enough datasampled for a week? Month and Year is still just “- kwh” (today it was 7 days since i added it)

Also the usage on BilVarme is almost the same every week so that could also explane why the log is also showing the same there. But for year it does not make sense.

Will try the loginfo and continue investigate.

Thanks again.

imhofa · March 7, 2018, 3:17pm

If you don’t have enough data in your persistence service, then openHab can obviously not calculate the difference… (as you can’t either )

If you have measured values since 7 days, then you should have values today for the weekly value. For month and year you can’t get a value until you have values for a month / for a year… But the weekly value should be correct… Maybe you can Chart the original value to see how this value changed the last 7 days…

For the monthly/yearly values you can do a work-around:
compare the updated values if they are ‘-’ or undefined and then you can do a Approximation with the weekly value:
BilVarmeManed.postUpdate( (BilVarmeUke.state as Number) / 7 * 30 )
BilVarmeAr.postUpdate( (BilVarmeUke.state as Number) / 7 * 365 )

With this workaround you can extrapolate the values which can’t be calculated because of missing historical values from your actual weekly values…
From the time you have enough historical values, the accurate values are used…