This sounds interesting enough that I would give the app a try. But have you tested it with multiple kinects connected by USB over cat5, and if so, what extenders do you use? I have 2 different USB extenders and could not get either to be reliable for my touch screen, I would think the quality requirement for the microphone would be much higher.
CastleOS - new home automation software with Kinect voice control
- Thread starter ChrisCicc
- Start date
ChrisCicc
Active Member
picta said:
The current beta version only allows for one Kinect per computer. We'll be lifting that limitation soon, once we do, the only limit would be the bandwidth of the USB ports on the PC they connect to. Generally speaking, USB controllers on motherboards can only support 1-2 Kinects each, and each motherboard typically has 1-4 controllers. For large houses that want one central PC, they might need some add-on PCI USB cards to add new ports and controllers, but for a handful of Kinects that shouldn't be an issue.
Unfortunately, not all USB over Ethernet adapters are created equally. Some promise bandwidth they can't deliver. But a USB adapter that hits its benchmark for USB 2.0 should work just fine. We'll be making some specific product recommendations after we do some more testing ourselves and hear from the community about their experiences - there's just a lot of extenders out there.
One other thing to keep in mind in large whole-house installations is to try to avoid using switches and routers. Most homes that are wired for Ethernet have all the feeds come direct to a central patch panel. To roll out Kinect over Ethernet, you'll need to change the patch from the main switch of your house, and move it to a dedicated feed to the PC. Otherwise anything much more than a handful of Kinects would overload Ethernet switches and cause network collisions. Hopefully this doesn't sound confusing, it's pretty easy to do.
I'm also interested but with limited device support right now and no way for me to do my own drivers, I'll be watching for a while. Elk, UPB, Aprilaire, Brultech and some other odds and ends.
For the USB side take a look at Silex. You completely bypass the motherboard and it emulates the USB device directly on the host complete with driver loading and plug-n-play. I use one for real-time control of a Yamaha mixing console and it is the only one so far that works reliably. I do see some postings where the wireless Silex doesn't work with Kinect but some of the newer ones claim isochronous support and with a switched gig network they may be work a try.
Jay
For the USB side take a look at Silex. You completely bypass the motherboard and it emulates the USB device directly on the host complete with driver loading and plug-n-play. I use one for real-time control of a Yamaha mixing console and it is the only one so far that works reliably. I do see some postings where the wireless Silex doesn't work with Kinect but some of the newer ones claim isochronous support and with a switched gig network they may be work a try.
Jay
ChrisCicc
Active Member
jdale said:
The longest we've tested it is about 35 feet away. This is a large great room. Even at 35 feet it works very reliably, albeit depending on the acoustics of the room you may have to speak a little louder. In the event a room is too large for one Kinect, you can easily add a second to provide more coverage. I routinely use it from 25 feet away reliably every day.
As far as line of sight and reliability, no, it does not need to be line of sight. As far as the reliability outside of a room, it's very dependent on the acoustics of the area it's installed. Carpets tend to do better than hardwood floors when not in immediate proximity (same room) or line of sight to the Kinect, as you voice travels smoothly over carpet, and echoes over hardwood.
All device management is build in to CastleOS, it's designed as a replacement for, rather than a complement to, HouseLinc, HomeSeer, ISY, etc.
ChrisCicc
Active Member
JayH said:
Thanks for your interest Jay! Thanks for the tip about the USB devices from Silex. They look very interesting. They will definitely help some people out, so I'll be sure we get one from Silex for testing.
As far as the drivers, just to clarify, we do offer the ability for users to write drivers, albeit it's not an open platform you can just plug in to. Here's how it works: users can write their own drivers in C# (preferred), VB.NET or Java in which case we'll do the conversion for you, or C++ (in which case we'll build a C# managed wrapper around the C++ DLL, this latter choice is what OpenZWave does). They then would have to either assign us the code, or license the code via something like the LGPL, which is what OpenZWave uses. At that point we'll integrate the code by hand in to our API.
The reason for this manual integration is because CastleOS doesn't have a concept of "plugins", it's a fully integrated solution. When we add a capability to communicate with a new device, we're adding it as equally integrated as all others. To the end user, they'd see one single flat list of possible protocols and devices therein.
So if you already have drivers written, they should be convertible, if you don't, you can write and prototype the driver using free tools from Microsoft without needing to touch CastleOS, and then we'll just integrate it. And with the LGPL and other licenses, you can retain ownership over your code if you choose to do so.
Thanks again!!
ChrisCicc
Active Member
az1324 said:
I understand (though am disappointed) if it's a deal-breaker for you, we knew it might be for some, but we think we have a pretty robust and reliable model in place. Ultimately we need to gate what code goes in to CastleOS, as our market is not just enthusiasts and installers like the ISY. We hope that we have found a good balance for most enthusiasts though, and we will continue to adapt as the community responds with new requests.
Why? No code is going in. Just creating virtual devices that can show up on the UI and be in the device list. You can still control the scope of those virtual devices. If someone is using the API or installing third-party software they have an obvious intent and it is not going to ruin the user experience for anyone else. It's like saying third-party ROMs ruined Android for basic users. A large number of inexperienced users install those ROMs and enjoy them.
ChrisCicc
Active Member
az1324 said:
Well I was referring more to allowing others to publish plugins for widespread us, we'd have no control over the quality or the user experience. For your specific idea of virtual devices, there is the two way communication to consider, status updates, etc. We think it makes more sense for the interested party to simply develop a clean API and let us integrate it into the UI. Less development time for them, better integration for us and our users, etc...
So what? Third-party software/plugins are ubiquitous and it doesn't ruin products/systems. In fact in the majority of cases it makes them better. What is to consider? The virtual device only gets updated through the API and any actions related to the virtual device are passed out through the API through registered callbacks. If the external program crashes then the device and its associated properties becomes unresponsive. Add some handlers for that situation if you want to alert the user that a device has become unresponsive. It's the same as if a battery has died or a hardware device has failed in some other manner. There is no way you are going to have the time to integrate everything people want and there are people out there who would do a better job themselves (gasp). Nevertheless, that is just an opinion and it is possible that is not the best path for you so grain of salt.
ChrisCicc
Active Member
az1324 said:
There is certainly a lot of merit to what you have mentioned. Ultimately it comes down to a combination of our ability to guarantee a certain level of service and capability to customers, and our ability to develop all of the "like to have" features with the resources available. Can we do what you describe on a technical level? Yes, I'm sure we can with enough time, but that would take away resources from other features we'd like to work on. That's why we think our model is a good compromise for both sides, developers can focus on creating APIs and interfaces to whatever protocol or device they want, and we can make sure it's integrated tightly with the overall system in addition to working on other features.
I think you are also going to miss out on the community-building aspect that it would bring. Without the opportunity for true collaboration then you only have the client provider relationship instead of the multi-dimensional interactive community. It discourages participation when you always want to carry the torch the final few meters. Plus it should take far less time to build the virtual device capability once than to integrate all the individual use cases. As far as guaranteeing quality, there is the umbrella of recommended,official,approved usage and then everything outside it. People seem to understand the whole "this will void your warranty" concept pretty well. But it will be interesting to see what happens.
<2 cents>
FYI, the home automation software world is extremely competitive. There are only a few major (and commercial) players in this field, some great open source projects, and many failed/abandoned projects.
If you want to become a major player, you need to offer something which others don't. Homeseer, CQC, Elve, have been around for a while, and that's only because they listened to what their customers wanted. Plenty of projects out there which think they can do it better, and no matter how right they think they might be, you don't hear anyone talk about them.
So you need to figure out who your audience is (DIY or Pro?), and if you are serious about making this stand out from the many many other custom solutions out there, or if this is just for fun/time filler.
Many of us have tried most of the better software solutions out there, so if you want to improve your product, you really should consider our feedback. Most of us WANT you to succeed, competition is good for everyone, and we are all still looking for that holy grail of software which does everything we want it to do.
The portal is down right now, but there is a list of all home automation software on the market, and that list is HUGE!
</2 cents>
FYI, the home automation software world is extremely competitive. There are only a few major (and commercial) players in this field, some great open source projects, and many failed/abandoned projects.
If you want to become a major player, you need to offer something which others don't. Homeseer, CQC, Elve, have been around for a while, and that's only because they listened to what their customers wanted. Plenty of projects out there which think they can do it better, and no matter how right they think they might be, you don't hear anyone talk about them.
So you need to figure out who your audience is (DIY or Pro?), and if you are serious about making this stand out from the many many other custom solutions out there, or if this is just for fun/time filler.
Many of us have tried most of the better software solutions out there, so if you want to improve your product, you really should consider our feedback. Most of us WANT you to succeed, competition is good for everyone, and we are all still looking for that holy grail of software which does everything we want it to do.
The portal is down right now, but there is a list of all home automation software on the market, and that list is HUGE!
</2 cents>
AZ1234 brings up a good point about the community as that is why I PERSONALLY decided to not use Elve as the community wasn't as active as CQC and Homeseer. The second most important thing - what devices does the software support. For CastleOS it will be a catch-22, you won't have the drivers to bring the community and the community won't be able to bring the drivers. I do sincerely hope CastleOS is successful though.
David
David