[SOLVED] Influx Persistence


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.



// influxdb persistence - store selected items in group

Strategies {
	default = everyChange
Items {
	gInfluxDB* : strategy = everyChange

Items file with persist group listed

String   vGPCurrLoc                          "Current Location [%s]"                                (gMapDB, gInfluxDB)
Number:Temperature GF_HW_TS_Temp       "Temperature [%.1f %unit%]"         <temperature>   (gThermostat, gInfluxDB) { channel="mythermostat channel" }

I’m sure the principle is working as I can get some basic data in grafana from the temperature one:

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)


Gives me the error in the log file:

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

Gives me the error in the log file:

An error occurred during the script execution: Could not invoke method: org.eclipse.sm


vGPCurrLoc.previousState("influxdb", true).state.toString


Influxdb does not store strings, only numeric data (including binaries, which are converted to 0/1)

EDIT - I’ll withdraw that, @vzorglub !
I did actually check at

and it says

All values are stored in a field called “value” using integers or doubles,

which reinforce my wrong remembering.

Wrong, influxdb does store all kinds of data, including strings


That doesn’t work either

Gives the same error with just a slightly different ending…

previousState(org.eclipse.smarthome.core.items.Item,boolean,**java.lang.String**) on instance: null

My apologies, it’s the other way around:

vGPCurrLoc.previousState(true, "influxdb").state.toString
1 Like

Thanks, I’ll try that tonight when I get home.

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?

Try this one, explains true/false

1 Like

Perfect thanks, I worked through the influxdb docs, if only I’d started there…makes perfect sense now!

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.

1 Like

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!

This is very much recommended

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!

Hi, so I’ve followed the docs in this from @rossko57above

And I’ve got most working…except one, (and it’s the one I now need - obviously)

        vGPPrevLoc.sendCommand(vGPCurrLoc.previousState(true, "influxdb").state.toString)

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?

No, sorry
But shouldn’t this be the same as the current state?


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.


Of course!!
I did not think about that. Clever!

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…