-
Notifications
You must be signed in to change notification settings - Fork 496
Persistence past reboot issues
Device addition / deletions getting lost and rolling back to a previous state after a restart is a telltale sign of problems with persistence.
Here are some things to try:
It's possible for the main SQLite database to get into a permanently locked state, but not in a way that'd prevent deCONZ from starting up.
Issue might be caused by corruption, seen most commonly if the filesystem is not completely POSIX-compliant (eg. CIFS mounts or risky mount flags).
These are the signs to look for in the logs after making device changes:
bool DB ExistsRestDevice(quint64),86: assertion 'rc == SQLITE_OK' failed
bool DB ExistsRestDevice(quint64),118: assertion 'stmt' failed
DB sqlite3_exec failed: COMMIT former transaction, error: database is locked (5)
void DeRestPluginPrivate::saveDatabaseTimerFired(),6143: assertion 'saveDatabaseltems == 0' failed
And / or zll.db
last file modification timestamp is old (meaning that changes are not written to the filesystem).
Recreate the main database file by rerunning the SQL statements dumped from the locked database.
-
Make sure deCONZ isn't running.
-
Open terminal and
cd
to the folder containingzll.db
.
Run
echo ".dump" | sqlite3 zll.db | sqlite3 zll-recreated.db
mv zll.db zll.bkp.db
mv zll-recreated.db zll.db
- Start deCONZ.
- Try making a change and rebooting deCONZ.
Disclaimer - CIFS is unreliable and fundamentally unsafe for running a database on.
It will at some point result in the corruption of the
zll.db
database file.Reconsider other methods, eg. running locally with a cron-based backup.
Using the nobrl
mount option mitigates filesystem level locking issues.
This will make it even more prone to corruption by disabling byte-range locks.
Home Remember : Not all devices listed here are supported by deconz.