Scene as database

[jgab 1,950]

Here is a way to misuse the scene structure while we wait for a database...

Persistent key-value store that doesn't suffer from global variables accidentally being destroyed...

Please login or register to see this code.

Much more efficient to keep the lock in a fibaro global but wanted to keep the example "clean"...

Empirical tests with two competing scenes writing and reading data doesn't seem to destroy data for each other. Beware, the lock mechanism is not fool-proof, but seems to work in practice. With only one writer (instance) there is no problem.

Maybe a better place for the HomeTable...

Edited January 24, 2019 by jgab

[jgab 1,950]

The above example is a generalised key/value persistent store. It can be used instead of fibaro globals when you want to store data that the fibaro globals where not meant to store and that gets destroyed whenever something is saved in the variables panel. The performance is worse than fibaro globals (especially writing) but for storing scene configurations and setups it works well - data that is typically set up once when the scene is deployed and then mostly read.

The background is that I used to have a scene that built me a hometable. Over time I have moved away from automatically trying to build and update the table as the table consisted of more and more hand-tweaked data anyway. And I have it formatted in a way I like with keys in the order that makes sense to me.

So, I more or less ended up with a scene that just declared a big table and then stored it in a fibaro global. Why don't read that table direct from the scene then? and avoid the problem of accidentally destroying the fibaro global holding the value?

Ex, scene with ID 14 (only text in scene)

Please login or register to see this code.

Code to retrieve the table

Please login or register to see this code.

(the table has to be written in json format)

Edited January 24, 2019 by jgab