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.
The first thing your rule does is attempt to get a persisted state. If you have never yet previously stored any data, that will return null. Your rule does not deal gracefully with that situation, and fails with an error. Because it fails, it never gets to the part where it persists data. The next time you run the rule, you still have no stored data ā¦
Richās rule suggestion was a guide, it needs work to make it practical.
