I’ve been using InfluxDB with OpenHAB2 for quite some time now and they play well together. However, I’ve recently had some issues where items that are supposed to be restored after system restart (set to restoreOnStartup in influxdb.persist) are getting set to NULL.
I’ve seen Influxdb do some occasional housekeeping on startup which can sometimes make it quite slow to start. I suspect this is the reason why OpenHAB is setting NULL values for these items when I reboot the system. (i.e. both OpenHAB and InfluxDB get started on reboot, but InfluxDB hasn’t completed its startup and isn’t ready before OpenHAB tries to read the initial values for the restoreOnStartup items). I can’t see anything in the OpenHAB logs to confirm this, other than NULL value errors in my rules, but I know if I restart OpenHAB once InfluxDB is running, then the restoreOnStartup items get initialised correctly.)
Can anyone confirm if OpenHAB expects to have to wait for its persistence providers and whether there is any way to configure this wait or if there is any retry mechanism?
Is it possible to redo the restoreOnStartup, e.g. from a rule?
It is possible to redo restoreOnStartup from a Rule I think. But you have to have some way of knowing when InfluxDB is back up even there.
Rules DSL:
rule "restorOnStartup second try"
when
System started
then
createTimer(now.plusMinutes(<enough time that you are sure InfluxDB has come back up>), [ |
// Create a Group with all your restoreOnStartup Items
Restore.members.filter[ i | i.state == NULL].forEach[ i | i.postUpdate(i.previousState().state)]
])
end
Python
from core.rules import rule
from core.triggers import when
from time import sleep
from core.actions import PersistenceExtensions
@rule("restoreOnStartup second try")
@when("System started")
restore(event):
sleep(<enough seconds that you are sure InfluxDB has come back up>)
[item.postUpdate(PersistenceExtensions.previousState(ir.getItem("Restore").state)) for item in ir.getItem("Restore").members if item.state == NULL]
Both examples are just typed in and likely contain typos. You might need to do some error checking as well.
That’s a good suggestion on the previousState() - I’d hadn’t considered that if the current state is NULL then the previous state should be the one I need!
I’m going to keep monitoring to see if this occurs again, as it looks like there may be something else happening here.
Another solution is to use mapdb to do the restore on startup and continue to use InfluxDB for other uses such as the charting. I’ve never had an issue with mapdb - perhaps it starts up much faster than InfluxDB.
Again, a good solution for remembering parameters, as mapdb is much more lightweight. However, since I’ve got Influxdb I’d prefer not to add more persistence providers.
I’ve been expanding the use of the InfluxDB TICK suite for monitoring various bits of network and devices outside of OpenHAB but perhaps haven’t got the housekeeping quite right yet, which is probably part of the slow start.
I just mention this as I don’t want to put people off using InfluxDB with OpenHAB as generally they work together very well and the integration with Grafana produces some really nice charts/dashboards.
