Ok, i think i will get this on my own. I can persist the data and so i get the values even if i restart openhab.
But what´s with the second part of my question? Can i read this data out of a persistence?
EDIT:
rule "Kompressor Starts zählen"
when
Item HeatPump_state_compressor1 changed from OFF to ON
then
HeatPump_compressor_count = HeatPump_compressor_count + 1
end
This is not working. Do i have to do this with variables? Or do i have to write it something like HeatPump_compressor_count.state as DecimalType ?
Number HeatPump_compressor_count "Verdichter Impulse [%d]"
Rule
rule "Kompressor Starts zählen"
when
Item HeatPump_state_compressor1 changed from OFF to ON
then
postUpdate(HeatPump_compressor_count, HeatPump_compressor_count.intValue + 1)
end
and if you put the HeatPump_compressor_count into the persistence cfg for rrd4j or mysql (or whereever) it is continously logged.
I guess you could also do it with a mapping linked to the heatpump_state_compressor1 and then mention it in the persistence cfg that it is written every change, or if you want to make a chart, every minute.
Will put the compressor starts of today into the item, which you can easily display. And of course this can be done for all times you want, but it is not that easy (for me to explain) to define the “when thing”
rule "Kompressor Starts zählen"
when
Item HeatPump_state_compressor1 changed from OFF to ON
then
postUpdate(HeatPump_compressor_count, HeatPump_compressor_count.intValue + 1)
end
I tested with some “val”, but this was also no success.
I made a logging-info to check, if the rule is triggered at all with “changed from off to on”.
If this will not work, i will have to make a helping rule to trigger, when compressor was off and first gets command on. If i only trigger received “command on”, i will get counts every 60 seconds.
Here’s a copy of my rule also counting starts of the heatpump compressor:
rule"Log kompressor start/stop"
when
Item Heatpump_Compressor_start changed to ON
then
postUpdate(Heatpump_start, (Heatpump_start.state as DecimalType + 1.0))
end
This works and can be displayed with persistence also…
Check your events.log if there is a change in HeatPump_state_compressor1
Do some logInfo(“TEST”;"Count: "+HeatPump_compressor_count.intValue) in your rule.
Is there anything in the openhab.log? Coming up with an error?
It seems, that the rule gets not triggered??? I made a logging on first position after the “then”-part. But since this time, compressor was off.
Count is alway 0. Formerly it was “-” , but i made a rule (and removed it afterwards) to send “0” as initial value to the item.
The problem is: I get “Compressor ON” every minute. Also if “Compressor” is not initiated and i get command “on”, i will get 1 count. (Maybe on openhab startup)
But i only want to get a count, when compressor was “off” and changes to"on".
I don´t think, there is any error in the log-files.
There is no longer support for db4o in OH 2. If you ever want to generate nice charts I would highly recommend InfluxDB and Grafana. Short of that I’d look into SQLite.
ItemName.state is how you get the current state of your Item.
Each type of Item has its own type of state. A Number Item has a DecimalType for its state whereas a DateTime Item will have a DateTimeType. When you want to do math with an Item’s state, you need to tell the Rules that the state is a DecimalType (as DecimalType).
.intValue is a method on DecimalType which returns the value of the state as a primitive int.
I use rrd4j for all charting this (Must!) and it is not rounding (or didn’t I get your point?).
So use this, but I would prefer mysql so you can do your own sql statements to check things. Calculation within rules would be the same.
rrd4j “compresses” the data as it gets older by taking several near by values and replacing them all with a single average of those values. So as your data gets older the values become more and more spare and less and less precise.
Therefore, for example, you may have a value every minute but once the data becomes a couple of days old you will have one value every ten minutes which is the average of the once per minute values in that ten minute period.
In practice for many if not most use cases this isn’t a problem because the precision of data a week, month, year or older doesn’t have to be as high as recent data. But some use cases do require all the precision for this older data.