OH3, restoreOnStartup not working?

Add-ons Persistence Services
1

Hi,

it looks like restoreOnStartup is not working for me on openHAB 3 (RC2, and before).

Here is part of my influxdb.persist file:

gSettings* : strategy = everyChange, restoreOnStartup

And here one of the items:

Switch Lampen_Buero_Automatik "Bürolampen bei Bewegung anschalten" (gSettings)

I set that to ON earlier today and rebootet, afterwards it was OFF. I also just set it back to on before upgrading from RC1 to RC2, afterwards it was again OFF.

What’s wrong here?

2

OH3 also does rrd4j persistence with RestoreOnStartup by default that might interfere with your InfluxDB.
Try if it helps to define a rrd4j.persist WITHOUT restoreOnStartup to override the default.

3

I tried creating an “empty” rrd4j.persist file like this:

Strategies {
	everyMinute : "0 * * * * ?"
	everyHour : "0 0 * * * ?"
	everyDay : "0 0 0 * * ?"
	default = everyChange
}

Items {
    
}

After reboot my settings items still don’t get restored.

1 Like
4

I have the same problem thats seems ramdom and I am trying to understand the issue…

  • First of all I have all items in .item file
  • I notice that during the first starting after upgrade to a new snapshot the influx.persistance is load before the items file and I receive a lot of influx errors since the item does not exist. None of the items are restored
  • I notice that during normal restart command the items files are loaded before the influxdb.persistance but some items are restored and some others doesn’t … it seems the ones that are restored have not a chanel while the others (in my case they have MQTT channels) are not.

I also notice that the load sequence at start-up is the following: .items , .persistance, .things , .rules … maybe should be better things, items, persistance, rules ? I am not an expert but this seems strange

Please check if this is the same to you

5

following this, i got the same, but with mapdb not restoring on startup, mapdb is default persistance.

1 Like
6

The same problem and symptoms (influxdb, states not restored/badly restored with switches)

Log from openhab startup:

2020-12-25 19:04:04.993 [TRACE] [.influxdb.InfluxDBPersistenceService] - Query SELECT value FROM autogen.Enable_Home_Automation ORDER BY time DESC LIMIT 1;
2020-12-25 19:04:05.012 [TRACE] [rnal.influx1.InfluxDB1RepositoryImpl] - series Series [name=Enable_Home_Automation, tags=null, columns=[time, value], values=[[1.608918431066E12, 1.0]]]
2020-12-25 19:04:05.022 [TRACE] [rnal.influx1.InfluxDB1RepositoryImpl] - columns [time, value]
2020-12-25 19:04:05.034 [TRACE] [rnal.influx1.InfluxDB1RepositoryImpl] - adding historic item Enable_Home_Automation: time 2020-12-25T17:47:11.066Z value 1.0

events.log, selected entries related to Enable_Home_Automation

2020-12-25 18:52:23.429 [INFO ] [openhab.event.ItemStateChangedEvent ] - Item 'Enable_Home_Automation' changed from NULL to OFF
2020-12-25 18:57:44.105 [INFO ] [openhab.event.ItemStateChangedEvent ] - Item 'Enable_Home_Automation' changed from NULL to OFF

As you can see in above logs, state is properly read from db as 1.0 (checked - when I set to OFF it saves 0 value to db). Numeric values are properly restored to numeric items so I think there could be problem with translating 1.0 to true.
In OH3 there was a change in storing int/double or similar value in db (don’t remember) so I had to remove whole measurements from influx. So maybe something changed in recognition of true/false stored as number? (tried to remove Enable_Home_Automation measurements and didn’t work)

Edit: Added events.log entry

7

I’m having the exact same issue. Values seems to get stored, but after an Openhab restart, all switches are OFF again. Values like numbers (Electricity meter) are shown after a restart.

8

It’s caused by this issue: [influxdb] historic states of switch items are always OFF with influxdb v1 · Issue #9455 · openhab/openhab-addons · GitHub

At least for those of using influxdb for persistence.

9

Thanks for posting!
So as we see appropriate fix has been made but not merged. We just need to wait.

10

mapdb not restoring on startup for me too. But this fix looks like for influxdb only.
Is there any other ideas why restoreOnStartup (mapdb) does not work after migrating from 2.5 to 3.0?

11

Hello,

The problem seems always here even with the influxdb fix.
I have opened this issue for the influxdb binding:

12

I am on 3.0.1 - Release Build and influx restore on startup does not work.
Is this fix already included in 3.0.1 - Release Build?
I just upgraded and don’t know what to do with it.
I am on openhabian with influx 1.8.4

Also clearing the cache din’t help

Without that funcionality OH3 is useless now.

13

People if you use restoreOnStartup with InfluxDB that’s where the problem is.
Don’t - Influx is unsuited for this, fix or not.
Move to MapDB with restoreOnStartup and you’re set.

14

I upgraded to the latest snapshot today after reading those bugs mentioned above.
My engine heaters was restored as OFF (disabled) after a power outage this weekend. Discovered when the wife could not get her car going this morning…
I was using a snapshot from around 3.0.1 before.
All my switches (Items) came back to the expected state, so they where stored in influxdb.
I cleaned the cache while I was at it, as it was mentioned in one of the bug reports

15

What do you mean? I’ve used it for years without problems. Then it get’s broken by an openHAB update and InfluxDB is the problem?

16

Yes. A DBMS is the wrong tool to (permanently) store the set of current item states and has ever been so, regardless of whether you used it for that purpose.

17

What are the technical reasons for Mapdb being better than Influxdb to provide persistence?
One of the reasons I use a NUC and not a Rpi is that Influxdb/Grafana is a great troubleshooting combo.
So a double storage for Item persistence made litle sense (for me).

18

more efficient, integrated with OH etc
Note it’s not about general persistence, just to restoreOnStartup. You can use both in parallel.

19

Ok, I must read more into this.
I see why Mapdb is more efficient. At least I think I do :slight_smile:

21

You should have been using mapdb for years then. My opinion, like it or not.
Feel free to use whatever you want but then don’t complain if it does not work the way you want it to. None of the people responding here including myself are responsible for your issue(s), just you yourself are. And most including myself don’t share your point of view.

Indeed this is an inacceptable communication style of yours we don’t tolerate here.
Go kick a tree and learn to keep your frustration with yourself rather than to direct it at voluntary responders.

It only took you a record setting half an hour to get in conflict with a moderator by ignoring Guidelines - openHAB Community.
Feel free to proceed then it’ll be just another half an hour and you will be removed from the forum.