If for some reason (for example being able to do a restart of my garden-watering app after a reboot) or another I want to have
What are my options on Hubitat ?
On Vera someone had created an app called "multiString" which I could use ….
Is it possible to write to a file and read from it?
I have experience in application programming, but not in systems programming ….
Rule Machine has global variables and now "global variable connectors," which basically create devices that you can manipulate (and read) as normal from any app. They are, of course, still usable from Rule Machine (as that global variable), though you don't have to use RM at all with it if you don't want to. Their original intent was likely to make global variables accessible (and changeable) from Dashboard, but there's no reason you couldn't use one in any app.
Before these were created, lots of people used other creative workarounds. For what are effectively global Boolean variables, you could use a virtual switch. For numeric values from 1-100, you could use a virtual dimmer. You can exploit standard attributes in any (virtual) device for this purpose if you need other ranges and there's an attribute that would work, and I guess there's nothing to stop you from writing a custom virtual device with a custom attribute that can take whatever values you want, but the downside is that custom attributes are by definition not as universally usable in standard apps. If theseapps are custom, you'll have quite a bit of freedom (lots of the virtual device workarounds are for things where you need them to,interact in standard ways with other apps).
It's hard to give more specific advice without knowing exactly how they work, but hopefully some of this would help. If you're not sure where to start, global variables in RM with global variable connectors sound like a good place to start to me.
I'm also not sure what you mean with "restarting" an app after reboot. Hubitat apps aren't always running; they wake up when something happens, in most cases either a scheduled job (something you created in the app) or an event subscription (e.g., most motion lighting apps will subscribe to motion events on a motion sensor). Then they do something (run your handler or callback in this case), exit, and wait for the next time they wake up. There are other possibilities (e.g., if an app creates devices, they are child devices of that app and can invoke methods on the parent app that will also wake it up when called), but the idea is the same: do something then exit. A hub reboot will generally not affect this, though obviously if it missed a time-based scheduled job because the hub was off or rebooting at the time, then that particular one will not have happened.
Yes, the reason I need to restart (and pick up where I left) is because with reboot my future execution (run once at a specified time) will be lost. (I don't want my garden watering stick at sector #4 and keep watering) And this way I won't miss a scheduled job, instead I can see I'm past a certain time and adjust my schedule and the parts to follow (6 cycles total).
(My application will at least run 3 hours, and watering has to terminate eventually, so possible reboots should by taken into account.)
Thanks for the suggestions, I will work on them.
If the data is only needed by one App, then you can store the data in a STATE variable within that App. No need to make it any more complicated than required. State variables are stored in the hub’s persistent database, and are reloaded when the App is run.
I agree. But for the broader perspective: I also needed a kind of status-variable shared by 2 apps....
Are they your own (custom) apps? If so, would it make sense for them to both be child apps of the same parent app? If that is the case, another alternative would be either storing what you want in the parent app's state or at least having a method in the parent app that could retrieve the desired value from a child app. The other child app could then call this method on the parent app (it would have to be a method either way because child apps cannot directly access the state of a parent app, but where the value ultimately lies or how it's calculated/stored is up to you). If it's not something that users need to interact with/view directly, a device attribute is probably not the right solution, but if it is, that's still an option.
One way to share data between apps is have a parent app
You can push the data to the parent which can then be shared with different children
You can also use a virtual device to hold data which can be access by multiple apps
Thanks. Most important: it can be done on Hubitat (couldn't find how to do it on Smartthings, have it running on Vera but am moving away), in various ways. I will work on it.
Download the Hubitat app
