Domoticz Community Forum - Support & Discussion

Hi,

I recently experienced something with `dzVents` persistent data that I thought might be worth reporting, in case this is a known limitation or something that could be made more robust.

My Raspberry Pi had an unexpected reboot. After it came back up, I noticed that several values stored in `domoticz.globalData` had reverted to their `initial` values. These values are normally changed by my automation at least twice a day and had been persisted correctly for a long time.

At first I suspected that something in my scripts might have called `globalData.initialize()`, but I could not find anything doing so.

I then looked at the dzVents storage mechanism and noticed the following.

`EventHelpers.lua` loads the global persistent data with:
self.getStorageContext(globalsDefinition, '__data_global_data')
and eventually writes it through `persistence.store()`.

In `persistence.lua`, the file is opened as:
file, e = io.open(path, "w");

This means that the existing file is truncated before the new contents are completely written.

There is also recovery code in `EventHelpers.lua` which, if loading the data module fails, moves the existing file to `.faulty` and subsequently creates a new storage context using the `initial` values.

In my particular case, the timestamps are quite interesting:

* Domoticz started at `15:46:52` after the reboot.
* `__data_global_data.faulty` was created at `15:46:56.118`.
* The `.faulty` file is 0 bytes.
* The new `__data_global_data.lua` was created shortly afterwards and is about 30 KB.
* The new file contained the `initial` values for several variables which normally have different persisted values.
* There were no relevant Lua/dzVents errors in the Domoticz journal around the reboot.

This made me wonder whether the following could have happened:

1. `persistence.store()` started writing `__data_global_data.lua`.
2. The existing file was truncated because it was opened with `"w"`.
3. The Raspberry Pi rebooted while the new file was being written, leaving an empty or incomplete file.
4. On the next startup, dzVents could no longer load the persistence file.
5. The storage context was therefore recreated from the `initial` definitions.
6. A subsequent script execution then wrote those initial values back to `__data_global_data.lua`.

I cannot prove that this is exactly what happened in my case, so I'm posting this more as a question than as a bug report.

Is this a possible failure mode of the current dzVents persistence mechanism?

If so, would writing the data to a temporary file first and then atomically replacing the existing persistence file be a possible way to protect the stored data against an unexpected shutdown?

I'm happy to provide the relevant files, timestamps or any additional information if that would help investigate this.

### Environment

* **Domoticz:** `2026.3-stable`
* **Build:** `f734fde31` (2026-08-02)
* **Platform:** Raspberry Pi
* **Architecture:** `aarch64`
* **Linux kernel:** `6.12.75+rpt-rpi-v8`
* **OS:** Debian Bookworm
* **dzVents:** version included with this Domoticz installation

Thanks!

Thank you for the excellent analysis — you nailed it.

I traced it through the code and it is exactly as you described: persistence.store() opened the data file with mode "w", so the old content was truncated the moment the write started, and there was no flush or atomic rename. A reboot at the wrong moment (or a power cut, since nothing forced the data to disk) left an empty or partial file. On the next start dzVents preserved that empty file as .faulty (which is why yours was 0 bytes) and recreated the storage from the initial values — and since the global data file is rewritten after every script run, there were plenty of windows to hit.

This is now fixed in the development branch (dzVents 3.1.13):

• Atomic writes — data is serialized in memory, written to a temporary file, flushed, and then atomically renamed over the data file. There is never a moment without a complete file on disk.
• Automatic backup — the previous version of each data file is kept as .lua.bak. If a data file turns out to be corrupt, dzVents now restores your values from that backup automatically (the broken file is still preserved as .faulty for inspection). Worst case you lose the very last write instead of everything.
• Fewer writes — unchanged data is no longer rewritten after every script run, which also saves your SD card.
• Serialization now uses the maintained serpent library instead of the unmaintained 2010 persistence code. Your existing data files load unchanged.

Deleting a data file by hand still resets its storage to the initial values, so that documented way of resetting keeps working — the backup is only used when the file is present but unreadable.

While digging in I also found (and fixed) a second bug in the recovery path: with two or more variables in your data section, the .faulty handling itself crashed with a nil error, which is probably why you saw no useful message in the log.

The fix will be in the next beta. Thanks again for the detailed report — analyses like this one make fixing things a pleasure.

The commit message references your topic (t=45177), and everything is covered by ten new unit tests (all 888 pass).

Thank you for the kind words!

I'm really glad that I could make this tiny contribution to such an excellent piece of software. It was really just a matter of bad luck that this particular bug happened to manifest itself on my system after all this time.

I'm extremely grateful that you were able to track it down, fix it so thoroughly, and do so incredibly quickly. The atomic writes, backup and reduced number of writes are all great improvements — much more than I ever expected from my report.

It's a pleasure to be able to give something back, however small, to a project that I have been relying on for so many years.

Thanks again to you and the other developers for the great work on Domoticz and dzVents!