|
Chris Cicchitelli Administrator Posts: 3390
2/3/2015
|
Hey Everyone!
We're actively building our new plugin infrastructure. This will allow the community to create drivers for devices and protocols we don't natively support. Our goal is to natively support all major protocols such as INSTEON, Z-Wave, RadioRa2, etc., but there are many devices that fall outside this.
How this will work:
We'll provide base code classes for each device type we support. Let's say you want to support a WiFi thermostat. What you'll do is download our thermostat skeleton, which is a code class in C#. Then you'll fill in methods like SetCoolSetpoint or SetMode to allow control of the thermostat - this is where your custom code would come in. Then you'll just drop the file in the plugin folder, CastleOS will load the driver, and you're off to the races!
We'd like to know if you have any ideas, concerns, or requests. We plan to launch this functionality in a few weeks.
Thanks!
Chris & Chris
|
|
|
0
link
|
|
Dominique Garcia Posts: 55
2/3/2015
|
SmartThings. Integrating SmartThings will open up CastleOS because SmartThings already has Insteon, Z-Wave, etc. integration built in it.
|
|
|
0
link
|
|
Nick Bento Posts: 221
2/3/2015
|
Globalcache GCIR if it isn't already in there  Also are voice commands auto generated by the skeleton, or would there be API methods to generate them? Are the plugins limited to just hardware? For instance could I code something to interface with Google Calendar? edited by nikku on 2/4/2015
-- -Nick B.
|
|
|
0
link
|
|
Landon Beasley Posts: 11
2/4/2015
|
Building on what Dominique said in his post, and I know you mentioned in the past that support for hubs like the smartthings and the wink are coming but still a few months off (at least for wink, I know you said you were holding off on smartthings until you see what direction they are going). Supporting these things will reduce the some of requests you are getting for most of the devices and it will open up the the audience you can market your software and new hardware (The hub) to. Home automation is quickly becoming the buzz for 2015 for general consumers because they are see at places like Home Depot and Best Buy and the general consumer is looking to expand their new HA system they picked up from Home Depot, Amazon, Lowes, Staples... non of which support any kind of decent voice control out of the box (all of them support switching things on and off via your phone which is just another light switch if you have to dig through you apps on your phone, and IFTTT or some other form of robot/automation), by not supporting any of these systems people are going to pass your software up for options that do support them like the Ubi for smartthings (which by the way is $299 so it is more than your software and only supports one room voice communication which might be great if we all lived in one room but if you ever wanted to use voice in another room you would be shelling out another $299 for that room, I know I personally wouldn't be doing that if I was a general consumer and another option was available).
edited by malnical on 2/4/2015
|
|
|
0
link
|
|
Assistive Tech Dad Posts: 114
2/5/2015
|
Provide us an abstract object hierarchy that has some very low level base object types (e.g. BaseToggleSwitch object with a get/set property IsEnabled and single method Toggle(), or a BaseMotor object). There may be some devices we want to automate that do not fall into a more specific category, at least not one you can foresee (especially in the assistive tech world).
Access to voice output.
Event listener registration. To allow our added drivers to interact with the rest of the house and understand the current state of the house or special context of those commands it may be necessary for our drivers to receive notifications of various events that occur within CastleOS. I assume since you are pulling these drivers into you process (unless you are using a sandboxes AppDomian) you are not overly concerned with security issues.
On security issues, maybe a way to certify plug-ins and a configuration in CastleOS to limit access to uncertified plug-ins or refuse to load them all together.
Client side API to write custom clients for these new devices as well as CastleOS as a whole.
How's that for a start?
|
|
|
0
link
|
|
Christopher Macnichol Posts: 37
2/9/2015
|
Would it be possible to create a HTTP GET Command Set plugin? As of right now my Insteon network is running primarily on an ISY994i and the Voice Functionality of CastleOS is a perfect counterpoint. However all of the issues I currently have are with the Insteon Hub that CastleOS uses. I would love to just be able to use the voice functionality and have it send the proper commands over to the ISY for it to enact. The API for the ISY Rest Interface also allows the polling of its entire node structure to get their current status. From what I can tell it does not take long at all to update as the links are actively managed. So as long as the Device ID exists within CastleOS it should be possible to parse that out periodically to update status. My testing shows that the ISY has no issues serving up this information every few seconds, not that it is really needed that quickly. I understand that CastleOS is meant to be a replacement or equivalent to the ISY, but for someone like me who is just using the Voice portion then the ability to pass the commands onto the ISY would simplify my link management by a large margin. As I have found out, having multiple Insteon controllers on the same network is just asking for trouble. Thoughts? Details on the ISY API can be found here. http://wiki.universal-devices.com/index.php?title=ISY_Developers
|
|
|
0
link
|
|
Christopher Macnichol Posts: 37
2/27/2015
|
Any progress or thoughts on this?
|
|
|
0
link
|
|
Chris Cicchitelli Administrator Posts: 3390
2/27/2015
|
Nothing official yet, but we tentatively plan to natively support the ISY with CastleOS...
|
|
|
0
link
|
|
Christopher Macnichol Posts: 37
2/27/2015
|
Chris Cicchitelli wrote: Nothing official yet, but we tentatively plan to natively support the ISY with CastleOS... Thank you! I really appreciate that. Getting that Hub off my network will make things so much simpler.
|
|
|
0
link
|
|
Chris Cicchitelli Administrator Posts: 3390
2/27/2015
|
Christopher Macnichol wrote: Chris Cicchitelli wrote:
Nothing official yet, but we tentatively plan to natively support the ISY with CastleOS...
Thank you! I really appreciate that. Getting that Hub off my network will make things so much simpler. What do you mean by off your network?
|
|
|
0
link
|
|
Joe Kosharek Posts: 1
2/2/2016
|
Chris Cicchitelli wrote: Nothing official yet, but we tentatively plan to natively support the ISY with CastleOS... Any update on ISY support?
|
|
|
0
link
|
|
Phil Hawthorne Posts: 400
2/2/2016
|
A year later, and custom drivers still aren't released
|
|
|
0
link
|
|
Chris Cicchitelli Administrator Posts: 3390
2/2/2016
|
Joe Kosharek wrote: Chris Cicchitelli wrote:
Nothing official yet, but we tentatively plan to natively support the ISY with CastleOS...
Any update on ISY support? While we don't yet have a native driver for the ISY, we do now offer virtual devices, which can call an URL for on, off, and dim commands. The ISY supports HTTP calls, so you can do this!
|
|
|
0
link
|
|
Phil Hawthorne Posts: 400
2/2/2016
|
Chris Cicchitelli wrote: While we don't yet have a native driver for the ISY, we do now offer virtual devices, which can call an URL for on, off, and dim commands. Hey Chris, This sounds awesome. How do we create these?
|
|
|
0
link
|
|
Chris Cicchitelli Administrator Posts: 3390
2/2/2016
|
In the latest Beta from the private beta folder here: https://drive.google.com/open?id=0B5j6VE4C-S-Ga21NNVlldVREODQGo to Add Device, and then in the Protocol selection list, choose "Virtual". You'll then be given boxes to put URLs for when On and Off commands are called. If you enable dimming, you can also put in an URL to call when a Dim command is given. Optionally, you can include the text {value} anywhere in the URL, to have {value} replaced with the dim value, 1-100.
|
|
|
0
link
|
|
Phil Hawthorne Posts: 400
2/2/2016
|
Chris Cicchitelli wrote: In the latest Beta from the private beta folder here: https://drive.google.com/open?id=0B5j6VE4C-S-Ga21NNVlldVREODQ
Go to Add Device, and then in the Protocol selection list, choose "Virtual". You'll then be given boxes to put URLs for when On and Off commands are called. If you enable dimming, you can also put in an URL to call when a Dim command is given. Optionally, you can include the text {value} anywhere in the URL, to have {value} replaced with the dim value, 1-100. AWESOME
|
|
|
0
link
|
|
Chris Cicchitelli Administrator Posts: 3390
2/2/2016
|
It should be noted the "dim" value can be used for anything that needs a level, i.e. curtains/shades, motors, etc.
|
|
|
0
link
|