Key thing to note about my suggestion is having a parameter to choose the graph type. I agree this shouldn’t be a change that applies to ALL graphing types.
I don’t disagree that the chart is doing what normal charting would do. BUT, there is no easy way to get the intermediate data into the database in a reliable method. Simply adding functionality to the chart would save lots of intermediate data from being jammed into everybody’s database to make the graphs more readable.
From my perspective (I’m neither a developer nor a maintainer for OH so my opinion isn’t worth much) OH is designed for and does a good job of solving the problem of home automation, not data analysis. Presenting data in all sorts of charts and graphs with lots of options for how it makes and formats the chart to me still sounds like something where a third party tool would provide a far superior product and experience than we should ever expect from OH.
That having been said, Habmin2 has some nice charting options built in.
Also, now that I think about it, if you create a parallel Item for charting and a rule to update it you can get the behavior you want through a rule.
#Items:
Switch mySwitch
Switch persisted_mySwitch
#Rule:
rule "Persist mySwitch"
when
Item mySwitch received update
then
persisted_mySwitch.update(mySwitch.previousState.state.toString)
persisted_mySwitch.persist
persisted_mySwitch.update(mySwitch.state.toString)
persisted_mySwitch.persist
end
Make sure to exclude persisted_mySwitch from your .persist file so it doesn’t get persisted automatically. Make sure to include mySwitch in your .persist file so previousState works.
This will drop the previous value into the DB right before the new value as @Derka described above.
Unfortunately given the behavior of rule triggers with Groups I don’t think there will be a good way to avoid writing a separate rule for each Item you want to chart.
In your chart, use persisted_mySwtich instead of mySwitch.
I don’t disagree… but I don’t think we are talking data analysis. More just suggesting an extension to the charting.
An argument could be made that the current charting is somewhat inadequate for a good portion of items even in a very basic setting. My charts for when my heat was on or off are painful to look at. I don’t need to pump data into cacti or something so that I can drill into it for greater detail. I just want to glance and see if my basement heat is coming on enough during a cold snap to keep the pipes from freezing and I need to be able to do so from my phone.
Your solution is a decent workaround but adds extra database tables and entries as well as extra items and rules to build, maintain and hold in memory. I maintain the “proper” solution is to extend charts rather than find ways to modify data to feed to the chart. That being said, I may use it myself at least as a fill in until graphs are extended
Don’t get me wrong, I’m not arguing or finding fault with OH, I’m merely seeing a way that I think myself and others would enjoy an enhancement to OH and that’s what OH and these forums are about in my opinion.
But it works now and stores far less data than storing something every minute or something.
My personal approach to these sorts of things boil down to if is a real problem solve it. If it is a theoretical problem or if it is an aesthetic problem don’t solve it until it becomes a real problem. To me, having to store some extra values in a DB, particularly if you are using something like rrd4j, isn’t even a theoretical problem, it is one of aesthetics. It doesn’t look right to store redundant data.
If we are talking about something like a switch or any other discrete item and we store the value every minute it amounts to a few kilobytes of extra data over a year. And if you are using rrd4j, the DB self compresses so you never risk running out of space. But even if you are not using db4o or the like and you use the rule above a few extra KB or even MB a year isn’t something I’d be willing to spend time on. Even on a Raspberry Pi, I just don’t see that being a real problem. Particularly if you are using a DB that compresses its data like MySQL.
But if DB storage is really a problem or you have concerns about storing lots of extra tables and such you should be finely tuning your persistence anyway to store as little as needed.
For example, I use the following tiered approach:
Everything gets persisted to mapdb for restore on startup
Anything I want to chart or get historical values from gets stored in rrd4j. For rrd4j you will have to store values every minute no matter what for charting and DB queries anyway so the workaround above wouldn’t be needed.
Anything that I want to really study and have accurate historical data or I want to chart without storing lots of intermediate values which rrd4j would require gets stored in something like db4o or MySQL. Though this DB will continue to grow forever so you will need to plan on maintenance (i.e. deleting old values) at some point.
Using the scheme above, mySwitch would only be stored in mapdb, persisted_mySwitch would be stored in db4o or MySQL using the rule above or rrd4j using the every minute strategy.
And don’t get me wrong, I’m not arguing that the discussion shouldn’t be taking place or doesn’t belong here. I’m merely presenting a counter opinion. There are lots of problems to solve with OH and a lot of problems are simply not going to be fixed any more on OH 1. So we are in a period of transition where workarounds like the one I posted above will be very common until OH 2 is officially released and stabilized. So I tend to be a bit down on supporting proposals for changes to OH (right now) that do not really address OH’s core mission. I tend to put tweaks to the charting servlet into that category.
I’d love to hear your experience with letsencrypt and why you chose nginx versus something a little less heavy weight like Apache. I’ve had the security of my deployment in the back of my mind but I’ve not really done much with it yet beyond auditing the logs periodically. I like to hear what others are doing.
Possibly due to the built in reverse proxy? I certainly hope it isn’t for its scaleability
rikoshak, your points are valid and I suppose waiting for OH2 makes sense. I have tweaked my rules similar to your suggestion in the meantime. Something if I had taken half a second to look at my rules I could have done months ago but sometimes it takes the kick in the pants.
Some of my “passion” may be emotionally linked to my frustration with persistence in OH. I’m hoping part of the user friendly approach to OH 2, it will be better.
I’d like to revive this topic.
My suggestion is to add a new strategy like ‘everyChangeExtended’, that persists like everyUpdate, but overvrites the last record in the database (updates the date stamp of the last entry), if the value is the same.
P.S. I tried to find the definition of the persistence strategies, or at least to understand the github structure of openhab repository, but w/o success… Can somebody advise?
Thus destroying the record of when the change to current state occurred.
I’m in agreement with the others, this is not a data problem. Everything you need to construct graphs as required is already recorded with everyChange. It’s purely a presentation issue.
I’m sure you’ve seen this, but it seems clear enough - what was you issue?
Rich,
I came across your post since Grafana rendering is causing me a lot of trouble.
I am trying to chart a numerical value and would like to see the same result as Derka posted in the first post of this thread.
I see your suggestion is for a Switch item, how would that look if working with a Number item?
It’s always better to create a new thread than to reopen a thread that was started over four years ago.
Anyway, if you are using Grafana, just use the settings that come with Grafana. There is a fill attribute or something like that where you can tell it how to fill in the gaps between points. Choose “last value” and it will repeat the last entry as a level line until a new value appears. Then there is another attribute you can use to set the graph to use a stair step. This is all in the Graphana docs and it is outside the scope of OH really. The above was in scope because OP was asking about the OH built in charting which fas far fewer options compared to Graphana.
2020-03-29 22:50:42.101 [ERROR] [ntime.internal.engine.RuleEngineImpl] - Rule ‘Persist SwitcherCurrent’: ‘update’ is not a member of ‘org.eclipse.smarthome.core.library.items.NumberItem’; line 67, column 5, length 78
2020-03-31 20:37:44.362 [ERROR] [ntime.internal.engine.RuleEngineImpl] - Rule ‘Persist SwitcherCurrent’: cannot invoke method public abstract org.eclipse.smarthome.core.types.State org.eclipse.smarthome.core.persistence.HistoricItem.getState() on null
item persisted_SwitcherCurrent is not in .persist file, only SwitcherCurrent
rule:
rule "Persist SwitcherCurrent"
when
Item SwitcherCurrent received update
then
persisted_SwitcherCurrent.postUpdate(SwitcherCurrent.previousState.state.toString)
persisted_SwitcherCurrent.persist
persisted_SwitcherCurrent.postUpdate(SwitcherCurrent.state.toString)
persisted_SwitcherCurrent.persist
end
items:
Number SwitcherCurrent
Number persisted_SwitcherCurrent
I’m not sure what your rule is supposed to do, but note that postUpdate, and I think persist, are asynchronous. The rule will not stop and wait for that action to complete before moving on to following lines.
I’m also worried a bit about the granularity of whichever database you are using; some will regard two updates within a second as being the same moment in time I think.
