InfluxDB measurement adding every couple seconds on it own?

[ThomDietrich]

You’ve got two things wrong.

Your every minute is actually “everySecond”

everyMinute : "0 * * * * ?"
everyHour : "0 0 * * * ?"
everyDay  : "0 0 0 * * ?"

* includes everything, including B_Power_energy_daily_log. That’s why your item is currently persisted every second as you defined it.

What you should do is use the above definitions and you should not persist everything. You should only persist specifically what you want to graph or analyze later.

[xsherlock (Maciej Eckstein)]

WOW! thats why influx is killing my RPI3! Thanks.
Is there a way to use default persist every minute and only take away one two sensors.
I want to persist 90% every minute as I graph almost everything with Grafana and it has some problems when the value does not change within the graph window. Setpoints or motion sensors are the most often ofenders that brake the graphs.

[ThomDietrich]

No it’s not possible. You should create groups and persist these. Here’s part of my config:

Strategies {
    everyMinute : "0 * * * * ?"
    everyHour : "0 0 * * * ?"
    everyDay  : "0 0 0 * * ?"
}

Items {
    gHeatAct*, gHeatSet*, gHeatValve*, gHeatMode*                   : strategy = everyChange, everyHour
    gPower*                                                         : strategy = everyChange, everyHour
    gRSSI*                                                          : strategy = everyChange
    Presence_Phone                                                  : strategy = everyChange
}

Persisting every minute is really not a good idea. You should use everyChange to catch actual changes and maybe everyHour to have support points for only seldomly updated items. As you can see I’m not even doing that for all items. I can’t imagine you really have the need for minutely accurate graphing!?

@xsherlock

brake the graphs

How do they do that? No change will normally not be of any harm.

[xsherlock (Maciej Eckstein)]

Ok I fixed my install and now my energy readout does sum() properly as there is no dupes. but it did break Grafana graphs in the thermostat section when I have valve states and setpoints.

So I have now manualy add those to persist every minute to fix the graphs.

[ThomDietrich]

Your graph looks just fine to me

You might want to play around with the Selection/Aggregation function as described in the tutorial: InfluxDB+Grafana persistence and graphing

For “Water Setpoint” you might want to use the last() selector.

[xsherlock (Maciej Eckstein)]

As you can see the water setpoint is missing both ends on the graph. last() selector is not fixing that.
fill (previous) is fixing the missing end near the now() (right part) but for the mising part on the left I could not find a fix other then provide more granular data into DB
Also if the value did not change over 24h it will be completely missing from the graph.
I had to open some valves by hand and change the setpoints to make them into the graph as they were totaly omitted despite the fact the metric on the graph was still there.

But I do have much more concerining issue related to the orginal post.
I have croned ruled that on 21:06 should write daily value to the DB. it is simple as possible

	rule "Update max daily energy value"
when 
	Time cron "0 6 22 1/1 * ? *"
then
	var Number tmp
	var Number today_max = B_Power_energy_today_float.state
	tmp=today_max.floatValue
	logDebug("TERMO","---------Daily solar max sent to db:" + tmp )
	postUpdate(B_Power_energy_daily_log, tmp)
end

In the log I see it gets called twice 4ms apart from each other and that results in 2 values in the DB.

2017-01-19 22:06:00.032 [DEBUG] [eclipse.smarthome.model.script.TERMO] - ---------Daily solar max sent to db:5.951
2017-01-19 22:06:00.036 [DEBUG] [eclipse.smarthome.model.script.TERMO] - ---------Daily solar max sent to db:5.951

Why is that?

[ThomDietrich]

@xsherlock

As you can see the water setpoint is missing both ends on the graph.

Ah that… Yes that’s “okay” as in expected. That is why I mentioned to go the middle way and add hourly points. This is the way Grafana draws diagrams and yes, that could be improved but it really doesn’t matter much if you look at the diagram with a range of one day or one week. Here’s an example from my system (hourly values, pay attention to the tiny space at the left):

At the end I believe for your Temperature diagram an hourly rule is okay. For other kinds of data or devices other settings might be beneficial.

Another Example: One of my “sensors” is sending data only periodically every 10 minutes and values in between can be linearly interpolated. I am only using the onChange strategy because a cron based strategy would actually inject false data.

@xsherlock

Why is that?

I’m not sure. Maybe @rlkoshak can jump in.

[rlkoshak (Rich Koshak)]

I’ve no idea. Its as if the rule is triggered twice. I see nothing wrong with that cron expression that would cause that though.

[ThomDietrich]

Same ruling.

I remember somebody once reporting rules triggering twice in some constellation… do not remember. Did a restart of your system change something?

[xsherlock (Maciej Eckstein)]

rebooted, waited nicely whole day and kaboom

2017-01-20 22:06:00.029 [DEBUG] [eclipse.smarthome.model.script.TERMO] - ---------Daily solar max sent to db:12.539
2017-01-20 22:06:00.058 [DEBUG] [eclipse.smarthome.model.script.TERMO] - ---------Daily solar max sent to db:12.539

It trigers twice! how can I debug that?

[ThomDietrich]

This could be a real bug… If we can find the cause we should file a bug report for it.

You are using a RPi3. Which way did you install openHAB and which revision are you on? WHat is the name of your rule file, are there any other rule files present that do not work correctly or empty? Please check the rule file for formatting error or similar…

Stop openHAB, clear out cache and tmp and start again.

Good luck!

[rlkoshak (Rich Koshak)]

There are other threads discussing this issue add well. I might be seeing this too but am not sure as I’ve been doing a lot of changes in how my rules are triggered.

[xsherlock (Maciej Eckstein)]

I did openhabian on RPI3, this night I updated from 653 to the latest snapshot 743.
I only have single rules.file called default.rules
I only have a single crone rule in the rules file, all other trigger on the sensor or input changes and generaly work ok. I’ll clrear tmp and wait until today trigger at the end of day.

[ThomDietrich]

Hey, seems you are not alone. Check the suggestions over there. After you found the problem, please report back so we can file the bug report

Rules executed twice

I’m running OH2 on RaspberryPi. While developing my rules I found in log file that rules seems to be executed several times.It look likes as the old version stays still in the configuration, even if the new version has the same name. Restart of OH2 or RaspPi also not helps. Here e.g. my rule trigger: rule "Shutters OG Triggers" when System started or Time cron "0 15 1 1/1 * ? *" then … than some computation of times and finally definition of timers via createTimer In the Log file I foun…

OH2 cron job executed twice - possible bug?

I have numerous cron jobs in my OH2 rules, but one of them (and only one) always fires twice: Time cron "59 0/30 * * * ?" usually the second job fires 100-104 milliseconds from the first Before anyone asks, it’s definitely not a duplicated rule (and the ‘59’ is intentional - I stagger different cron jobs slightly, so they don’t all fire at once and it makes logs/debugging clearer)

[xsherlock (Maciej Eckstein)]

GOT IT.
It was a typo in the rule file.
A trailing space after the “when” clause was the problem!

[rlkoshak (Rich Koshak)]

@xsherlock

A trailing space after the “when” clause was the problem!

That shouldn’t have caused a problem. Are you sure it was a space and not some sort of special character?

[xsherlock (Maciej Eckstein)]

Now That I deleted it I cant check that back. But I’m quite positive it looked like a space. I only edit rules files on the RPI one way. And that is with Notepad++ on the SMB share on the OH2 machine.
I can see that it was set to the Windows style of the line ends CR LF and not to the unix LF only

so that would be a “space CR LF”

[rlkoshak (Rich Koshak)]

Trailing white space should not cause an error and openHAB should be able to handle Windows style CR/LF endings.

If you add the space back in does the error return?

If so this needs to be filed as a bug.

[xsherlock (Maciej Eckstein)]

I’ll add that space and report tomorrow night when the rule kicks in.

[xsherlock (Maciej Eckstein)]

Ok so adding that space back did not break the rule again.

I reviewed the logs and found out that some other rules get executed twice. And that is unrelated to the suspected trailing space. That rule is not cron based but trigered by the sensor change and in the debug I can see that there was no change of the sensor state as the living temp is the same for both runs

2017-01-25 20:22:31.094 [DEBUG] [eclipse.smarthome.model.script.TERMO] - ----Termostat rule kicked in!---------
2017-01-25 20:22:31.105 [DEBUG] [eclipse.smarthome.model.script.TERMO] - ----Termostat rule kicked in!---------
2017-01-25 20:22:31.138 [DEBUG] [eclipse.smarthome.model.script.TERMO] - outside_cur_temp:2.43
2017-01-25 20:22:31.143 [DEBUG] [eclipse.smarthome.model.script.TERMO] - living_setpoint:23.0
2017-01-25 20:22:31.149 [DEBUG] [eclipse.smarthome.model.script.TERMO] - living_cur_temp:24.25
2017-01-25 20:22:31.149 [DEBUG] [eclipse.smarthome.model.script.TERMO] - outside_cur_temp:2.43
2017-01-25 20:22:31.156 [DEBUG] [eclipse.smarthome.model.script.TERMO] - living_setpoint:23.0
2017-01-25 20:22:31.162 [DEBUG] [eclipse.smarthome.model.script.TERMO] - living_cur_temp:24.25
2017-01-25 20:22:31.181 [DEBUG] [eclipse.smarthome.model.script.TERMO] - living valve OFF
2017-01-25 20:22:31.185 [DEBUG] [eclipse.smarthome.model.script.TERMO] - living valve OFF
2017-01-25 20:22:31.195 [DEBUG] [eclipse.smarthome.model.script.TERMO] - living temp_deficit raw:-1.25
2017-01-25 20:22:31.197 [DEBUG] [eclipse.smarthome.model.script.TERMO] - living temp_deficit raw:-1.25
2017-01-25 20:22:31.200 [DEBUG] [eclipse.smarthome.model.script.TERMO] - living temp_deficit adjusted:0
2017-01-25 20:22:31.206 [DEBUG] [eclipse.smarthome.model.script.TERMO] - living based new_water_setpoint:23.0