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???
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!
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???