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)
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.
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?
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
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.
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
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.
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).
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.
Not all persistence services support every persistence feature, although on the face it influxdb appears to support restoreOnStartup.
If it doesn’t work for you, you could create a Github issue, and provide useful information for someone to track it down, something beyond “me too” and more like @Foxejoe observations.
On that subject -
Yes, the startup sequence is pretty messed up after an upgrade, because the upgrade deletes the openHAB cache. Other stuff can go wrong here too. This is/was the case in OH2 as well, though obviously exact timings and so exact symptoms will vary.
Wait a bit for cache to rebuild, then reboot again and see what is left that doesn’t work.
