|
Scott Goffman Posts: 111
11/24/2016
|
This seems like a really stupid question, but I'm stumped. I have no problem getting an AutomationDevice, but how do I actually turn it on/off? I can set .currentState to whatever string I like (and it sticks), but that doesn't actually trigger a device state change.
Specifically, I'm testing with an Insteon ApplianceLinc (on/off). In the WCF API I would use ToggleDevicePower or SetDeviceDimLevel, but those aren't in the scripting API. I must be missing something here.
Thanks,
-Scott
|
|
|
0
link
|
|
Chris Cicchitelli Administrator Posts: 3390
11/24/2016
|
For reasons I don't immediately know, it appears none of device level methods are in the Scripting API in this release, but the group/scene methods are. I'll get them back in there for tonight's release. Sorry about that.
|
|
|
0
link
|
|
Chris Cicchitelli Administrator Posts: 3390
11/26/2016
|
Andddd I remember. Those methods were pulled because they are now internal to AutomationDevice. When you have the device object you should be able to call AutomationDevice.ToggleDevicePower etc. Let me know if you don't see those methods for some reason...
|
|
|
0
link
|
|
Scott Goffman Posts: 111
11/26/2016
|
Looks like the reference API needs to be updated. ToggleDevicePower did work, but according to the reference API, AutomationDevice only has three Methods: CreateEmptyAutomationDeviceDataTable, GetCustomSettingsValue, and SetCustomSettingsValue. (Plus a whole bunch of Properties.)
|
|
|
0
link
|
|
Chris Cicchitelli Administrator Posts: 3390
11/26/2016
|
Yup, you're right, that's it. Thanks for that!! I'll get that updated tomorrow.
|
|
|
0
link
|
|
Kevin Mathews Posts: 138
11/29/2016
|
Scott, you think you asked a stupid question, but is sounds like both of you guys are talking Greek to me... jus' sayin'
|
|
|
0
link
|
|
Chris Cicchitelli Administrator Posts: 3390
11/29/2016
|
Kevin:  Scott: I did post that update to the API reference files, thanks again!
|
|
|
0
link
|
|
Scott Goffman Posts: 111
11/29/2016
|
Thanks Chris, I'll grab it!
In case anyone else is interested, this is a small script I call when shutting down my theater system. All it does it wait 30 seconds (time for me to leave), then turn off the lights. If you want to use it for yourself, just set the "delayTime" and "deviceName" to whatever you like. You can also rename the class to something unique to the device it's targeting.
Oh, and be aware that the error logger in this script doesn't actually work; the built-in CastleOS error handler intercepts the Catch first and dumps it to Errors.xml.
|
|
|
+1
link
|
|
Chris Cicchitelli Administrator Posts: 3390
11/29/2016
|
Very cool Scott!
A couple of notes...
The separate calls you are making to SetDeviceDimLevel and ToggleDevicePower aren't needed, as CastleOS is doing the same thing for you already. So if your intent is to simply turn the device off regards of whether it's a dimmer or relay, you can just call ToggleDevicePower. The dimmer will get set to zero by default in the process.
Also, it looks like you are doing only one global delay. I just wanted to note for others you don't need a script to do a global delay, you can add a delay via our Events screen in the app. But adding more than one delay, or delays with if/then logic etc., you do need to use a script.
Awesome job!!
|
|
|
0
link
|
|
Scott Goffman Posts: 111
11/30/2016
|
Great info, thanks!
|
|
|
0
link
|
|
Scott Goffman Posts: 111
11/30/2016
|
Regarding the delay: My event turns on the lights and runs this script, which then delays before turning off the lights. I couldn't figure out a way to do that without a script, since adding a delay to the Event would delay everything. Just a thought: If you were to add the ability to call other Events from an Event, then this would be possible. I could have a "DelayedOff" event (with a built-in delay), and the "Leave Theater" Event would turn on the lights, then call DelayedOff. Throw that on the future-features pile.
|
|
|
0
link
|
|
Chris Cicchitelli Administrator Posts: 3390
11/30/2016
|
Ah, yes, you are doing it the correct way.
Regarding adding complexity to the event builder to handle nesting like you describe, I think we're about where it's going to go with respect that. What we may do in the future is add a graphical script builder to make it easier to write simple scripts like the one you have, so non coders can do that too.
|
|
|
0
link
|