After lots of fiddling I think I’ve got my influx / grafana services working. However, I’m now not sure if / what it is persisting as I can’t seem to recall any data from it.
Info:
influxdb.persist
// influxdb persistence - store selected items in group
Strategies {
default = everyChange
}
Items {
gInfluxDB* : strategy = everyChange
}
But, the string item vGPCurrLoc doesn’t seem to be storing anything…as there is no data in there that I can see and when I try to recall it: (it gets its info from a case statement to say HOME / AWAY / WORK from my location data)
An error occurred during the script execution: Could not invoke method: org.eclipse.smarthome.model.persistence.extensions.PersistenceExtensions.previousState(org.eclipse.smarthome.core.items.Item,boolean) on instance: null
Which makes me think its null, ie has no values…both items were set up at the same time so I’d expect to have something in there, ie both items have had changes to them during the day.
As I’m new to this stuff could someone please point me in the direction of how to interrogate the influxdb a bit more to find out if there is any info in there and also tell me if I’m doing something else wrong please???
I was reading through the docs and sometimes it just uses previousState() and othertimes it need the (true) part…I like to understadn why I’m putting code in and not just c&p as that’s how you learn…
Any ideas why this is or in what cases you use true and what you don’t?
If only I had a penny for helping someone who did read the docs…
First rule of openHAB: READ THE DOCS
Second rule of openHAB: READ THE DOCS
Third rule of openHAB: When you have finished reading the docs, read them again
Ah, there are really (at least) two services involved here
openHAB persistence provides the common data handling - Items configuration and rules methods.
And then of course, the actual database.
Yes, to be honest for the past couple of days I wish I hadn’t started the whole persistence install, it’s been ‘bang head against wall’ awkward for many reasons and I’ve made mistakes that have meant that other rules have broken that I’ve had to fix so I think I need a few days away fom it all to let the dust settle before cracking back into it.
Desperation and annoyance cloud ones judgement and basic sensibilities, I got stuck in the rut of influxdb and just went down the route of everything should be in their docs, when the OH docs are probably better and more relevant!
Thanks both for your help, hopefully / I’m sure the vGPCurrLoc.previousState(true, “influxdb”).state.toString will work later when I get home.
I was going to tackle moving the influxdb on my NAS to stop read/write on my pi but I think that might be for another day!
yes, but my brain is already reeling from this install so unless there is an indiots step-by-step guide to this where I don’t have to think I’ll leave it until the another day soon…
I’m also thinking that getting the Amanada backup running first would be a better idea knowing how close I came to breaking lots of things on mny occasions over the past couple of days!
The top item works fine, and gives me the last changed state of vGPCurrLoc, (with the true statement in it), but to just get the last updated state the bottom item doesn’t give me anything.
The docs suggest:
<item>.previousState() Gets the previous State of a persisted Item (returns HistoricItem)
<item>.previousState(true) Gets the previous State of a persisted Item, skips Items with equal State values and searches the first Item with State not equal the current State (returns HistoricItem)
So in my mind it should be the same coding except just without the true in…any ideas?
Yes, I suppose you are right, in the real world it is the same as current state, I just wanted to work through the options in the previousState docs to learn what each option did so I could learn, understand and have the option to use each one if / when needed.
There must be a real life case for it sometime otherwise, why include it???
The results rather depend on the persist strategy for the Item in question. For example, if you choose to persist every 5 minutes the last stored state may or may not be the same as now.
Not all of the common functions make sense for every possible combination of “database” and strategy. As we’ve seen, previousState is nonsense for mapdb.
This is why I love coding, you think you’ve got something nailed on and then someone comes up with another way of looking at it and it opens it up to a whole different range of possibilities…
