Is there any limitations when it comes to global variables?
Maybe storing this info into files and being used with other child apps could be beneficial in some sort ?
Hmmm or used to dump data to be used for parsing for more info... perhaps something that can limit the need to make multiple call outs to the internet to parse the same data over again... no clue if this would speed things up, be of any benefit etc...
For now, you can't create a global variable that represents a /local file -- only a local variable can do that. But, any rule can do that, so in effect a /local file is available globally,
The only child app that can access /local files is Rule-4.0, for now. There are not methods available to user apps to reference /local files.
I can see massive potential for this once it becomes available to custom apps/drivers
For example: setting a variable in one app or driver and it being available to other apps/drivers.
Once the methods for read/write from apps etc are available, I can also see serious problems where two developers use the same filename.
Perhaps if/when the methods are created for custom apps, either the app.label or app.id could be prepended to the filename (although sensible devs could easily do this as ābest practiceā on write)
There is already this potential name conflict between developers when creating data values in drivers. An agreed approach would be beneficial. app name or namespace prepend would be sensible
Works great for playing local mp3 files (have not tried other file formats).
I have a rule that plays dogs barking triggered by the doorbell if everyone is not home from the Amazon cloud but now I can play it locally!
So while not immediately available for apps, could an intermediary device be created and rm could pass the data in? Apps can subscribe to all devices now correct?
I can think a few ways to use this ability. One is to capture the current state of my Yamaha Receiver mute state and volume and some of the harmony settings so I can restore them later.