Well, I can think of another instance where random in HA comes in handy and that is for lights to turn on and off when you’re away to simulate presence although for better AI, the system learns your routine and does the same. 
2 Likes
Random color with a delay between the change is fun for bulbs, as is color loop
4 Likes
Music shuffle. 
Holiday lights, including Halloween.
Cat toys.
Water fountains!
5 Likes
yeah yeah, I get the point, I WAS WRONG 
Again ha ha ha ha
3 Likes
At least being able to randomize the delay (up to the specified max value) would be great (for simulating presence by turning on/off lights at random intervals).
4 Likes
If ST fixes the platform, we can have a retro-st simulator using random executions and non-executions for those that seem to enjoy broken HA.
5 Likes
Done. (that easy?! you’ll ask…)
To all: updated the github CoRE app. Please UNINSTALL ANY AND ALL Pistons (child apps) before upgrading. Or simply remove the whole parent app altogether. Failing to do so may leave ghost Pistons floating around. You can still remove them from the ST IDE.
The action UI is almost done, but be aware that this is an alpha version. There is only one action you are working on, regardless on which THEN or ELSE THEN or whatever individual action you want to add. The action ID is currently hard coded to 1 so anywhere you go, you’re adding/editing the same action. Don’t get scared. Or do, your choice. Also, while you can add tasks, they don’t yet execute. I need to finish up the UI before I can get them to work.
Each action has a list of devices (the initial wizard is just a shell to selecting some devices). For ALL of these devices, you can set tasks. Each task is performed for each of the devices in the list and is stored in the tasks list I mentioned earlier. Then the Timing Belt takes care of them at that point. You can add as many actions with each having as many tasks as you wish per action group.
An action group contains two lists: DO actions and DO WHILE actions. Go easy on the DO WHILE… DO execute only when the piston flips between false and true. DO WHILE execute every time the piston is evaluated, for the current state of the piston (THEN block if the piston state is true, ELSE block if the piston state is false). Each condition or group of conditions can have one group of actions. The IF block is one condition group itself, as well as the ELSE IF (or BUT IF) block, that’s also one condition group itself.
NOTE: I haven’t yet added all the commands to the list of supported commands because for many of them I don’t yet have the parameter list (ST documentation is lacking, to say the least).
@bamarayne You still can’t get the actions to do things for you yet, but we’re much closer…
Have fun
1 Like
@JDRoberts Since you mentioned window shades, do you know if the presetPosition command has any parameters?! I would assume it does, either a preset # or name… documentation is scarce…
Same as with the timed sessions:
And there seems to be a new Capability added to the list:
powerSource is - obviously - missing. And locationMode is at least one that’s not on the list either…
@jim?
Dreams crushed…
3 Likes
Sorry, i’m dependent on text to speech and I can’t read code.
@tgauchat or one of the other master coders should know. Terry is particularly interested in capabilities.
1 Like
Oh sorry to hear that. Umm… the window shades capability describes the presetPosition function with no parameters. Same as for the set time remaining function for Timed Sessions. In my opinion, they both scream for a parameter… but the documentation says there’s none… any clue? @tgauchat? @slagle? @April? @jim?
For documentation questions, tag @jim. 
3 Likes
When the documentation falls short, the first thing to try to do is look for some existing example code:
-
Search the SmartThings Public GitHub: https://github.com/SmartThingsCommunity/SmartThingsPublic/search?utf8=✓&q=presetPosition
(no results). -
Search the Forum… I found one result…
Then (results or not), tag @jim and @unixbeast who are responsible for the Documentation so they can look into it for a possible quick answer, or at least make sure it is on their “to-do list”. (@yaimavaldivia was responsible for implementing the Capability, I believe, but she is no longer with SmartThings).
Frankly; I don’t hesitate to say that Capabilities are among the most neglected developer features of the Platform. Shameful, really. Sure… it’s a busy company, but this is a fundamental architectural feature. 
Capabilities should not be implemented without Community feedback; they should go though a “beta” phase, so to speak, so that reviewers can find shortfalls like this, and discuss missing features like “tilt(<angle>)” … which may be for “Blinds” instead of “Shades”, but, well… Blinds don’t exist as a Capability so… Grrrr. 
5 Likes
indicator is a worthless antique IMHO, it’s implemented on the st dimmers and switches and nothing else to my knowledge…
3 Likes
Well, sorry, I should do that, but I’m very busy at the moment doing something else 
So I am delegating… whoever wants to contribute
I’ll look up the code, thank you
2 Likes
Indicator is a parameter setting on a number of Z wave switches that let you say whether you want the LED to be on when the light is off (in which case it’s supposed to be a locator to help you find the light switch in the dark) or whether you want the LED to be on when the light is on (in which case it’s supposed to be an indicator to tell you that The light is on because these switches physically don’t have an on position and off position, they always return to the central position).
Since Smartthings doesn’t give us a standard way to configure device parameters, my guess would be that somebody stuck this into the device handler sometime when they wanted to simplify setting the parameter. But that’s just a guess.
These days it’s a useful parameter in many devices that have LED indicators, not necessarily just light switches.
3 Likes
Awesome work! You should consider making a new thread with this info at the top so more people can help.
Closed the poll and I guess Capture State / Restore State it is.
As explained before, a “rule truth change” can execute multiple actions. Each action allows for one or more devices to be selected and then one or more tasks added to the whole group of selected devices.
There will be three options for Capture and three for Restore:
- Capture Attribute to variable, requires a single device selected, takes two parameters, attribute (single selection) and variable
- Capture State to variable, requires a single device selected, takes one parameter, variable, saves ALL attributes to it as a map
- Capture State, takes no variables, saves all attributes of all devices in the device list individual variables (one for each device), name of the variable will be built based on each device name, no need to worry about this
The restore tasks:
- Restore Attribute from variable, allows multiple devices selected, takes two parameters, attribute and variable, applies it to all devices in the action
- Restore State from variable, allows multiple devices selected, takes two parameters, attribute list (multiple selection ok) and the variable name, applies the selected attributes to all devices in the action
- Restore State, same as 2, but I handle the variable name internally
Now the question:
Options 1 and 2 allow for a choice of local or global variables. Local variables are available within the Piston, two different Pistons can have the same variable name, but they will be two different variables, each with its own value. Global variables on the other hand, are stored in the CoRE and are written to/read by each Piston as they are needed. One Piston sets a value, another one can read that same value. Shared memory. Global variables always start with an @. Option 3 however, does not give you the option, but I do have the option. Should I “capture” and “restore” states into global memory - i.e. a stored state of one device in one piston can then be read by another piston - for the same device. Or should the scope be local? I.e. each piston can store its own copy of the state, independent of other pistons…
- capture and restore state locally - pistons are isolated, each can capture and restore their own version of the state
- capture and restore state globally - pistons are not isolated, capturing the state will modify it for all other pistons
0 voters
And another one, what character should be used for global variables?
- @myGlobalVariable
- $myGlobalVariable
- #myGlobalVariable
- %myGlobalVariable
- !myGlobalVariable
- &myGlobalVariable
0 voters
Thank you, I’ll start a new thread when I reach Beta
1 Like
The presetPosition() command takes no parameters. I don’t know why that is to be honest, just looking at the capability definition code.
/cc @unixbeast on this; Timed Session setTimeRemaining() does take a Number parameter. This was a recently added capability to the docs, not sure why it’s wrong but we’ll get it fixed.
1 Like