Lua : storage.set , storage.get
-
Hi
I’ve seen
storage.set
andstorage.get
used in some Lua code posted on the internet, where they need to store/retrieve somethings, e.g.iv = encdec.base64dec(challenge_Key) storage.set('IV', iv)
and then later on within another function I see..
iv = storage.get('IV')
It makes sense how this is meant to work, and it seems such a simple/elegant feature - hence I was wondering, is there an equivalent in Vera/OpenLuup? As I’d naturally go to use luup.variable_set and luup.variable_get - but that requires a device to be used etc.
-
Basically it's state variables on devices or the file system. I've done both, do both. I use state variables whenever I can, because managing the location of things on the filesystem can be a nuisance, especially given recent firmware changes to partitioning. Specifically, it's the versions of firmware pre- these changes that are the most troublesome, due to the highly constrainted space (Edge in particular) and high risk of filling a filesystem and causing other problems. This forces you to check versions of firmware and adjust behavior if you're at all interested in being a good citizen on the box.
You can create state variables on any device, and using any service ID, with minimal impact. Your Vera will unlikely show any signs of knowing or caring if, for example, you create state variables for your own data storage on device #1 (the ZWave network device, exists on all Veras from factory fresh). So while you are bound to devices, you don't have to create or manage them. I wouldn't say this is a "best practice," though, and I personally don't do it because it "breaks encapsulation" (the theoretical wall between devices and subsystems that is just short of canon to many programmers). You can do it. The system will let you do it. But now you've got data stored somewhere that that somewhere doesn't know how to manage, so if your subsystem is removed, for example, that data may remain and take up space forever more. But, that may not be different from the filesystem, either (but it's easier to spot and remove from the filesystem later).
The cost of storing large amounts of data in state variables can also be felt in the UI and other facilities, though. The
user_data
andstatus
requests used by many UI and dashboard integrations can grow very large, and size is time and memory. So if the data you intend to store in state variables is more than a handful of kilobytes (and rare at that), the filesystem may be your best alternative. Bring in the lfs (Lua File SYstem) and/or nixio libraries to help. You could write your ownstorage
module to isolate out the details and leave you with an interface like that shown. -
Thanks @toggledbits ,
I really do like the simplicity of that
storage.set
andstorage.get
.and the potential for a persistent store.I did find some discussions on the Vera site, https://community.ezlo.com/t/where-to-store-persistent-data-from-lua/184647/2. plus I did do a quick surf and found a few examples, sadly while the first one looked promising depends on SQLlite, which I’m not sure can run on Vera.
This seems to relate to what you said about using files.