Persistence past reboot issues - dresden-elektronik/deconz-rest-plugin GitHub Wiki

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:

SQLite not getting unlocked due to corruption

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).

Symptoms

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).

Fix 1

Recreate the main database file by rerunning the SQL statements dumped from the locked database.

  1. Make sure deCONZ isn't running.

  2. Open terminal and cd to the folder containing zll.db.

Run

echo ".dump" | sqlite3 zll.db | sqlite3 zll-recreated.db
mv zll.db zll.bkp.db
mv zll-recreated.db zll.db
  1. Start deCONZ.
  2. Try making a change and rebooting deCONZ.

Fix 2 specific to CIFS mounts

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.