CoRE and Piston Rules Engine, first design steps

I can’t remember where I ran into the last one so I was unable to verify it, but the rest of the list should be correct:

playSoundAndTrack(uri, duration, selectedSong, volume)
playTrackAndResume(uri, duration, volume)
playTrackAndRestore(uri, duration, volume)
playTextAndRestore(text, volume)
playTextAndResume(text, volume) ?

1 Like

Thank u. Is volume a 0-100%? How about selectedSong? String?

Yes, volume appears to be integer 1-100.

The Notify w/ Sound SmartApp appears to be using a value retrieved from the trackData attribute as the song so I’m thinking the selectedSong parameter is JSON.

Quick question, maybe I missed the answer along the way…

Will there be a way to disable a Piston when we don’t want it to run vs. deleting it and recreating it at a later time?

Holiday or special lights come to mind or when I am trying to figure stuff out, it’s nice to be able to go back and compare and have it disabled.

Thanks in advance
Rick

3 Likes

These aren’t commands defined on any capability. Perhaps they are custom commands for particular devices?

If that’s the case then why are SHM, Speaker Notify with Sound, and Speaker Weather Forecast calling those commands on a musicPlayer input?

All of those SmartApps were written by SmartThings and there’s even a comment in one of them that says the attribute “description” is there for backwards compatibility and will be removed in the future.

Also, the playText command doesn’t work on the Samsung M5 or Samsung M7 Speakers, but the playTrackAndRestore command does.

1 Like

Yes, pausing is a planned-for feature. There will also be a global maintenance mode where all pistons will come to a halt…

3 Likes

Are you going through the RM thread and picking up all of the requests that Bruce didn’t get a chance to implement, or what??? lol

1 Like

I haven’t. Said before, trying to not to be biased… This idea came to me when you asked for count of pistons under statistics. That’s when I added Paused pistons in the stats… Lol

1 Like

Devices can specify custom commands outside of any capability, and that is the case with the commands listed above. They are not capability-based commands, but device-specific commands.

Just remember if attempting to use non-capability commands on a capability-based input to check that the specific device supports that command using hasCommand().

The question of if they should be part of the capability definition is valid, and is something I’ll raise for consideration.

2 Likes

Hmmm…

3 Likes

You might want to remind the developers at SmartThings of this because Speaker Notify w/ Sound and Speaker Weather Forecast are both using non-capability commands against a musicPlayer input without using that function. (assuming the template code is current)

Thanks for looking into whether they should be part of the capability definition.

3 Likes

Playtextandresume uses the same parameters as playtextandrestore

1 Like

Every musicPlayer device and app uses the undocumented commands, every single one.

3 Likes

I really like this stats page.

5 Likes

Thank you, these are execution times, though no actions actually run… But steadier than event delay…
Both charts extend 24h

3 Likes

@ule may be able to help.

Since there were people asking for globally stored states, I’ve broken the task into two, one for local and one for global.

Also, @ will be the global variable prefix.

The piston will also set some “system” variables, these will have the “$” prefix. Example of system set variables:

$state - the current state of the piston, either true or false
$stateSince - the date/time at which the state of the piston last changed
$nextScheduledTime - the date & time of the next time scheduled to execute. This is obviously outside of device triggered events which may happen before or after that time

Any other ideas? Any information that you need available to variables? I guess we’ll keep adding as we find more we need.

2 Likes

This is absolutely f’ing amazing.

7 Likes