12/15/2014
Topic:
Events not firing
Scott Goffman
|
You got it; I updated the files here: http://goffman.net/docs/CastleOS_Files/ |
12/16/2014
Topic:
Events not firing
Scott Goffman
|
It did; the 11pm event failed to trigger last night (but did fire twice again this morning at sunrise).
Config is unchanged, but I updated Log.sdf here: http://goffman.net/docs/CastleOS_Files/
-Scott |
12/16/2014
Topic:
Events not firing
Scott Goffman
|
Excellent, thank you Chris.
-Scott |
12/18/2014
Topic:
Events not firing
Scott Goffman
|
After updating to the new version, I'm still seeing the same behavior where an event doesn't fire, and the nextScheduledRunTime is then set to tomorrow morning at 6:53 am. |
12/22/2014
Topic:
Events not firing
Scott Goffman
|
Chris,
Events are now firing correctly.
However, if I edit an existing daily event that hasn't triggered yet, upon saving it the nextScheduledRunTime is set to the following day, so it does not fire on the day that I edit it.
-Scott |
12/31/2014
Topic:
commandline arguments
Scott Goffman
|
Chris, is this still a planned feature? Being able to Process.Start an exe with args (or a .bat script) would solve a lot of my integration needs.
-Scott |
8/16/2015
Topic:
Running script from an event
Scott Goffman
|
Not sure whether this feature is supposed to be implemented or if some WIP UI leaked into the release, but...
1) Add a new event (scheduled or triggered)
2) Set up the event schedule/trigger
3) At Step 4, select Add Other Actions -> Run a Script
4) Click "Add Selection(s)"
A new "Voice Announcement" (not a script) gets added to the event's actions list.
Also...
1) Edit any event
2) At Step 4, select Add Other Actions
"Run a script" is not listed as an available option.
This is in version 1.3.1715 (5/6/2015).
-Scott |
8/16/2015
Topic:
Running script from an event
Scott Goffman
|
Ah, got it, thanks Chris!
That fixes the first issue (can now call a script when creating the event), but "Run a script" is still not an available option when Editing an event.
BTW, the Changelog thread and the Downloads page show the current version as 1.3.1720 (5/26/2015). Also CastleOS's "About" didn't pick up on the new release ("Upgrade Available: no").
-Scott |
8/16/2015
Topic:
Debugging Scripts
Scott Goffman
|
I've had no luck with getting CastleOS scripts to write to the system logs. E.g., after calling this simple test script from an event, I never see any results in the application log:
using System;
using CastleOSKinectService;
using System.Diagnostics;
public class COSScript
{
static EventLog eLog = new EventLog();
static readonly string eLogSource = "CastleOS Custom Script";
static readonly string eLogType = "Application";
public void Main(string[] args)
{
if (!EventLog.SourceExists(eLogSource))
{
EventLog.CreateEventSource(eLogSource, eLogType); // register custom Log Source name
}
eLog.Source = eLogSource;
eLog.WriteEntry("running script: TestScript.cs", EventLogEntryType.Information);
}
}
I know the script has run (from Log.sdf). There are no errors reported in Errors.xml.
Any suggestions?
-Scott |
8/17/2015
Topic:
Debugging Scripts
Scott Goffman
|
D'oh! You're right, that was it. That'll teach me to double-check my copy/pastes!
Thanks Chris! |
8/18/2015
Topic:
Scripted devices
Scott Goffman
|
Feature req: Scripted devices.
I'd like to be able to define a "device" by specifying an "On" script and an "Off" script.
-Scott |
8/18/2015
Topic:
Script args
Scott Goffman
|
Scripting feature req: Arguments
I would love to be able to pass arguments when calling a script.
This would mostly be a convenience feature, allowing us to write a single script that can do multiple things (rather than lots of single scripts with duplicate code).
-Scott |
9/12/2015
Topic:
Climate Sensors
Scott Goffman
|
Under the "climate" section of COS, there is a category for "Climate Sensors". What devices of this type are supported by CastleOS? Can they be used as Conditionals for events?
Thanks,
-Scott |
10/31/2015
Topic:
Scripts don't work in 1.3.2130
Scott Goffman
|
Chris,
Ever since my CastleOS updated itself to 1.3.2130 yesterday, scripts fail to run, instead reporting this to Errors.xml (xml tags removed because they seem to freak out the forum software):
error timestamp="10/29/2015 11:39:38 PM"
noteError in ToggleScenePower, device: /note
dataSystem.Collections.ListDictionaryInternal/data
messageIndex and length must refer to a location within the string.
Parameter name: length/message
innerException/innerException
sourcemscorlib/source
stackTrace at System.String.InternalSubStringWithChecks(Int32 startIndex, Int32 length, Boolean fAlwaysCopy)
at z.a(ag A_0, String A_1)
at ah.b(String address, Boolean power)
at CastleOSCoreService.AutomationDevice.ToggleDevicePower(Boolean power)
at m.b(String groupId, Boolean power)
at m.a(String sceneId, Boolean power)/stackTrace
targetSiteSystem.String InternalSubStringWithChecks(Int32, Int32, Boolean)/targetSite
/error
-Scott |
10/31/2015
Topic:
Scripts don't work in 1.3.2130
Scott Goffman
|
None of the scripts actually call TogglePower; I assumed that error was coming from CastleOSCoreService when the interpreter tries to load it. For example, this script now causes that error (but worked fine until yesterday evening):
using System;
using CastleOSCoreService;
using System.Diagnostics;
public class COSScript
{
public void Main(string[] args)
{
WebReq("http://brazil:8082/ajax_sendevent.lhtml?event=OpenMBRDrapes&device=18");
}
public static void WebReq(string url)
{
using (var wb = new WebClient())
{
var response = wb.DownloadString(url);
}
}
} |
10/31/2015
Topic:
Scripts don't work in 1.3.2130
Scott Goffman
|
Figured it out!
I have two scripts, one that opens the drapes, a second that closes them. ONE of them (opendrapes.cs) was missing the reference to System.Net, so "new WebClient()" was failing.
But the CastleOS error reporting seems to only work correctly once; after it hits an error, all future errors seem to trigger the "type or namespace name `CastleOSCoreService' could not be found" error from ToggleScenePower. Restarting the CastleOS service seems to be the only way to reset the error handler.
The reason I never ran into this problem before was due to run order: As long as the first script to execute after a CastleOS restart was closedrapes.cs (which DID contain "using System.Net"), the System.Net reference would remain loaded, so subsequent calls to opendrapes.cs would work.
At least I think those were all the factors involved.
Thanks for the assistance, Chris!
-Scott |
10/31/2015
Topic:
Scripts don't work in 1.3.2130
Scott Goffman
|
The drapes are on Makita control kits, which accept IR inputs. For manual control, they come with a remote, or you can program a Harmony with the correct IR codes. For timed automation, I use mini-PCs in each room with IR transmitters, running Girder software.
Since switching to CastleOS, I'm using a (very hacky) system where CastleOS events call a script that sends a web command to Girder, which then transmits the IR code. It's ugly and has lots of failure points, but I haven't found a better solution yet. Ideally, I would use Insteon's IR transmitters, but the reviews of them are awful so I haven't been willing to go that route.
Let me know if you have any other questions.
-Scott |
11/2/2015
Topic:
Scripts don't work in 1.3.2130
Scott Goffman
|
Every time I look at the Global Cache option I balk at the pricing. 
>$100 per location is a bit steep, especially when I already have the hardware I need (PC w/IR blaster) in the relevant locations. |
11/13/2015
Topic:
Opening screen
Scott Goffman
|
It's just a web UI, so you should be able to save your shortcut to open to any page you like (/m/scenes.aspx, /m/devices.aspx, etc.). |
12/30/2015
Topic:
WCF Authentication
Scott Goffman
|
Chris,
I tried playing around with the CastleOS API just for fun. I was able to use svcutil.exe to retrieve CastleOSService.cs and the app.config with the ServiceModel data.
I set up a new CastleOSClient instance, and quickly ran into the issue that .ClientCredentials is, for some reason, Read-Only.
Well, no biggie, my good friend Google found me some code for overriding the credentials in the Endpoint, so that's all fine.
But... After opening the connection (using security mode "TransportCredentialOnly", transport clientCredentialType "Basic", as specified in both the client app.config and CastleOSCoreService.exe.config), the server immediately responds with a (403) Forbidden error: "The HTTP request was forbidden with client authentication scheme 'Basic'."
It's not an SSL connection, I can't find any logical reason why it's being denied, so I'm wondering if it's due to this bug in WCF, where WCF is responding to the initial query with a 403 forbidden instead of a 401 unauthorized (which would trigger sending authentication).
If that IS the issue, there are some workarounds posted in that same thread, but they would have to be done on your end.
-Scott |