Introducing the CastleHUB powered by CastleOS, now on Kickstarter!

[az1324]

I'm talking about this answer:  http://cocoontech.com/forums/topic/27899-introducing-the-castlehub-powered-by-castleos-now-on-kickstarter/#entry228471
 
I didn't ask the question.
 

The CastleHUB supports ALL open APIs.

 
This is misleading too as it implies there are existing drivers/integrations for every open API.  As Archer would say, "Phrasing!".

 

[az1324]

As I stated in the response you quote about HomeKit, we'll support it as an open API. If it's not an open API, no one will be supporting it. It's seems pretty clear to me though that the Apple TV is intended as a bridge, and there will be some sort of cloud interconnect with the rest of the internet of things.

 
If you had provided a qualified response like that I probably wouldn't have posted.  All you said was "Absolutely!".  It seems just as clear to me that there will not be an open cloud API to homekit through aTV anytime soon.
 
 

I think you've missed the point of the Kickstarter... between what we have done currently, what we're doing as part of the Kickstarter, and our new API that's nearly complete, that statement is 100% accurate.

 
In the context of a product like this, "supported" means "just works".  So as far as I can tell, "user integration between CastleOS's open API and third party open APIs" is supported via custom code. 

 

[az1324]

What I'm saying is that a device or an API is not "supported" until the driver is written and tested.  So RadioRA2 is not currently "supported" by CastleOS but "support is planned".  And if support is not planned then "user integration is possible via custom code".  Statements like "The CastleHUB supports ALL open APIs" are misleading because they are poorly worded and ambiguous.  And if that ambiguity causes a person to make a purchase under false assumptions then that is not cool.

 

[az1324]

Sure, and that's fine.  But even forum posts should be consistent and accurate when you're representing (marketing) a product/service.

 

[az1324]

That's where I disagree.  I say the following posts are misleading:
 
>>Question<< Will it support homekit?
>>Original Reply<< Absolutely! It's an open API.
At this point someone clicks the buy button.
>>Later Amendment<< we'll support it as an open API. If it's not an open API, no one will be supporting it.
Oops, sorry buyer.


>>Statement<< The CastleHUB supports ALL open APIs.
>>Kickstarter<< Currently, CastleOS supports the following brands and protocols: (10 listed) CastleOS is committed to integrally support the following brands and protocols: (7 listed)
Inconsistent. Misleading since additional work/code/hardware may be required by the user to bridge certain APIs.

 

[az1324]

No problem, as long as there are not any additional posts that I think are potentially misleading and would benefit from clarification.

 

[elvisimprsntr]

Wow! It was a simple question, but I think I got my answer.

No, because you didn't get the device MFi certified and include the proprietary HomeKit crypto chips. Too bad. Maybe Gen 2.

 

[az1324]

How do you think IFTTT, Nest, Ecobee, Z-Wave, Control4, et al will connect to HomeKit?

 
Have any of those companies announced homekit support?
 
 

"Apple has contacted us with some additional information. The Apple TV is acting as an intermediary when you're issuing Siri voice commands to your home from a remote location, but the company says the device is less of a "hub" meant to tie all of your devices together and more of an entry point to your local network. To avoid the complicated networking configuration sometimes needed to access your private network from the outside world, iOS devices will send your voice commands to your Apple TV, and the set-top box will then pass that command on to the relevant HomeKit device. Both your iDevice and your Apple TV will need to be signed in to the same Apple ID for this to work, much like Handoff, Back to My Mac, and other services that facilitate communication between Apple devices.

 
Quote needs citation.  Does not imply any third-party access.

 

[RAL]

As an impartial reader of this thread, I'll jump in with a few comments.
 
It's obvious that you, Chris, know a ton of stuff about home automation and hubs and whatnot.  But I think AZ raised a few reasonable points about where you could explain things more clearly.  With your in-depth knowledge, perhaps you think what you've written is crystal clear, but for those with less experience, it might not be, or might be interpreted incorrectly.
 
The back and forth discussion between you and AZ has actually been enlightening - at least to me, and I'm glad to have read it. I now have a better understanding of what your hub does and does not do, and might do someday.
 
I understand, you're a businessman who wants to see his just-launched Kickstarter campaign be successful.  But it gives me pause about your company when I see you telling someone who raised some simple issues to go away, rather than saying "thanks for the suggestion, I'll rewrite the description to make that more clear."

 

[elvisimprsntr]

I was hoping you added the proprietary MFi crypto chips to the CastleHUB so that it could function as the bridge between legacy protocols and the homekit framework.

 

[elvisimprsntr]

There are two predominate open source projects which aim to allow one to create a bridge on a raspberry pi or Intel Edison. One is written in C the other in Nodejs. Of course it's a bit of a hack since it doesn't require the crypto chips. Your HUB likely can run either implementation. You would have to get a MFi license to get legitimate access to the HAP protocol and add the crypto chips to be certified by Apple.

Repos stared at my GitHub page. https://github.com/elvisimprsntr

 

[elvisimprsntr]

Look at it this way. It's an opportunity to fill a huge void left by Apple and DIY HAs with legacy devices.

 

[123]

Chris,

1. Congratulations on meeting your Kickstarter goal.
2. The discussion between you and az was interesting to me.
3. I sought the same clarification az did.
4. My initial reading of CastleHUB's capabilities led me to believe it supported multiple protocols from the moment the HUB is unboxed. CastleHUB requires the requisite radios/interfaces for most of the listed protocols. A Kickstarter comment raised the same issue and indicated this aspect of the HUB's capabilities needs clarification.
5. The CastleOS web-site refers to C# as a "scripting language". I can't say I agree with that characterization (Wikipedia disagrees as well). It suggests C# is as simple to learn and code as say VBScript. 
6. CastleHUB indicates support for several media repositories as well as streaming services. Does CastleOS provide any programmable control of the media and streaming (without resorting to custom C# coding)? If it does not, then the HUB's stated "feature" is simply native to Windows.

You'll find us Cocooners to be a jaded lot. We've seen a lot of stuff come and go, claims made and undelivered, products functioning far below their promised potential, and oversimplification of complex issues. Red flags are raised when a new product appears that claims to do everything with ease. Out of habit, we will ask probing questions that may seem like trolling but are nothing more than a dogged attempt to clear away the smoke and mirrors.

 

[123]

I think we'll have to agree to disagree on what constitutes a "scripting language". I've never considered strongly typed programming languages, like C#, to be easy-going scripting languages.
 
You indicated CastleOS has "direct programmable control" of media repositories. Your Kickstarter page indicates "CastleHUB supports media servers like MediaBrowser, Plex, Kodi/XBMC". So one gets direct programmable control of Plex?
 
Based on your previous reply (above), I'll assume, by omission, that there is no direct programmable control of streaming services. Therefore listing CastleHUB's ability to play Hulu, Netflix, Pandora, YouTube, and Amazon Instant Video isn't truly a function of Home Automation (controlled by CastleOS) but the CastleHUB's ability, as a vanilla Windows-based PC, to render these services. 
 
The Kickstarter page indicates:
"CastleOS is available on every major mobile platform, including Apple iOS, Android, Windows Phone, Blackberry, Firefox OS, and Linux-based phones. To accomplish this CastleOS has built a powerful HTML5 app that works across platforms and screen sizes. The CastleHUB inside your home serves up the app to mobile devices - no cloud required!"
Would I be mistaken in summarizing this statement as "CastleOS is accessible from any device with a modern browser?"
 
The Kickstarter page indicates:
"...the CastleHUB ships with fully integrated support for more smart devices than any other home automation controller"
I think the "fully integrated support" is the phrase that led me to believe CastleHUB, right out of the box, will control UPB, zwave, Insteon, X10, WeMo, Sonos, and all the other logos depicted. I believe (and so does at least one other Kickstarter supporter) "fully integrated support" suggests the appropriate hardware interfaces are baked into the HUB (like on some competing products). I realized this was not the case when I saw a higher pledge of $649 includes CastleHUB plus a zwave starter kit. 

 

[tmbrown97]

I will be asking BSR to remove this entire exchange and I ask you to refrain from commenting here further. 

 
I'm glad things seem to have settled down... but personally I wouldn't (and won't) lock/block this thread.  ChrisCicc - you posted the info here and opened yourself up for the questions, and I don't think they were unfair questions.  There seems to be some passion behind some responses but I don't see that as a bad thing.  Good information came from it. 
 
Congrats on the successful funding!