Writing my first app, it's sort of for turn-offable scenes. Lights revert to what they were before the scene was triggered. Two questions, a little one and a probably bigger one:
Do I need to test for each capability for each light before sending a value to that capability, or will it just harmlessly fail if the capability is not owned?
What do people do about storage of values that are going to be used later, when another event happens? These are not values that are intended for use outside the app.
NB I am sure someone's already written something like this but I am interested in this learning opportunity, so I don't want someone else's lol.
Yes. Or make the user choose them separately. Provide one input to select color changing bulbs, one to select dinmable, one for regular, etc. the. You know it has the capability already. [quote="Inge_Jones, post:1, topic:49673"]
What do people do about storage of values that are going to be used later
[/quote]
It depends a bit but in general the answer you’re looking for is state.
Done something similar in the past. I stored the previous state of a device in the state storage as a map using the device network id as the key and the state as the value.
And state storage is something that sits within the space of the app - the hub makes space for app instances to have their own storage space on demand? It doesn't involve creating a virtual device? I guess there has to be there to some extent for the preferences.
Correct. Every app has its own state storage to store data across executions. I believe it’s a modified map object so has some special characteristics as to what you can do with it.
So from top to bottom in that image, you have the settings for the app at the top which are the inputs to the app. Then most apps will setup event subscriptions to devices so they can react to things which is the middle part. Then the store state is shown at the bottom.
This is per installed instance, not per run instance isn't it? This alerts me to a potential problem, if for some reason more than one of the triggers go in quick succession, I could be having two runtime instances writing to the same storage, and the second one could be writing the new status of the devices not their previous which I want to store. Is there any way to mark an app as singleton - to not run if another instance is running? Tho for my own planned use, I can restrict it to just one trigger so it wouldn't be a problem unless I wanted to expand its use or share it.
This is a whole different can of worms. There are a number of threads on the forum about this that you might want to search for. It gets pretty technical and in depth.
For the most part this situation is rare and Only occurs in specific situations.
The main difference between state and atomicState is that state will save to the database at the end of the threads execution where AtomicState will write instantly but also introduces a performance hit. There are also a few other smaller differences with how you work with them but that info is also in the docs link I posted above.
Of all my apps and drivers I’ve written I’ve never ran into this situation or needed atomicState, but that doesn’t mean you won’t need it so it’s good info to know and understand.
I don't think either state or atomicstate would rescue me in the situation I am thinking of. The only comfort is that each of these executions are over so fast that it would be a very unlucky coincidence if more than one did run simultanously!
In that situation then there might be nothing you can do. Like I said, take a look at some of the threads that dive into it. There are replies from the main HE devs as well as other devs that obviously know more about this language than I do.
Here is an example of a thread that might have more info.
Personally I don’t like to overthink it too much. My hub is all custom code. I wrote all my own drivers and apps and haven’t had any thread issues.
Mmm. I'll just restrict it to single trigger. The other idea might have been to test and set the state of a virtual device upon launch, but as you say I am probably wasting worry on something not important.
