I don't get it. API (i.e. standardization; XKCD #927 issues aside) part is understandable - except it's not really a standard at this point. But… why would one need an intermediate party who would merely act as a proxy? Or I'm not understanding what kind of service Crownest provides? Intro pages are quite scarce on real technical details on how the whole thing works under the hood.
Sorry for skepticism, but I'd say it's certainly a better to invest the same money in making the same RPi (or alike device(s)) globally-addressable and accessible from the Internet. Indeed, this approach loses all fancy cloud buzzwords, but it brings much more practical value.
Perhaps this is just rephrasing ianawilson's reply, but it seems that if Crowsnest eventually supports fifty different cameras (or switches or thermostats or what have you), then (via the tumblr demo):
would be an abstraction layer over the internal functions of all of the cameras.
That way, if I wanted to, say, build an app that does mood lighting depending on how many people are in a room, I could use Crowsnest as my middleman, and then my app would support fifty different cameras and fifty different switches (hypothetically), instead of the one of each that I happen to own and test on. That way, I could swap out devices or distribute my code to others, without having to worry so much about hardware integration. That sounds valuable from my personal perspective.
At least, I think that's how it works, from browsing the site and demos. Feel free to correct me, ianawilson. :)
That way, I could swap out devices or distribute my code to others, without having to worry so much about hardware integration. That sounds valuable from my personal perspective.
It is valuable, but has the downside of coupling to a closed-source third-party cloud.
Perhaps a better goal would be to encourage a public collection of CoAP- or OSC-based interfaces for these various end-point devices.
Crowsnest is encouraging people to write and submit such end-point code; better that it be workable with OSS infrastructure.
The idea is that Crowsnest organizes what devices can do into capabilities, and anyone can build a plugin for anything using our device integration framework. A plugin maps between what Crowsnest knows as capabilities and the actual calls that need to be made to the device. Of course, we can't build something for every device, so this framework will be open source with the idea that anyone can use plugins already created for existing devices, and hopefully we can engage the community to contribute and maintain these for devices as new ones are created. As soon as we release this, we're going to seed the community with a handful of integrations that we'll maintain. And if there is anything of particular interest to our users, we'd love to support that.
We've also been toying with the idea of using some device discovery so that devices can tell Crowsnest what they are capable of without needing to build a formal plugin for it.
While part of the service is to act as a proxy between the RPi and the Internet, we're also trying to help save devs from needing to build out the device integrations (eg, lightbulbs, cameras, etc). We're trying to take care of these more boilerplate and reusable things, so that developers can focus on building their new and creative applications, rather than communication and infrastructure. Even if the device integration someone needs doesn't exist, we're hoping to make it easier and faster to get moving along that path with our open source device integration framework (we also call this the plugin system).
If you're curious for more technical details, there is some info in the docs (https://www.crowsnest.io/portal/docs/). Or if that's not enough, I'd be happy to talk more about it, here or in our IRC channel (#crowsnest on freenode).
Sorry for skepticism, but I'd say it's certainly a better to invest the same money in making the same RPi (or alike device(s)) globally-addressable and accessible from the Internet.
That's a nice idea, but unless you control the network - and if you're deploying devices for other people, you probably don't - it's just not feasible. You'll have layers of NAT and firewalls preventing it.
Sure, but wouldn't it be better to reduce those when possible, rather than adding another one, especially yet another under the control of a third party?
On the whole, yes, but that's not realistic if you're a developer and you want to deploy some devices. You can't just expect people to rearrange their whole networks for you.
This certainly was an issue in early days of P2P, but I thought it was already solved for good.
Doesn't P2P works nearly literally everywhere nowadays and aren't there loads of NAT-piercing and/or tunneling libraries that Just Work™? (Well, possibly, unless put behind some truly abysmal corporate firewalls where even plain outgoing HTTP isn't working all the time — but that would be another story.)
Indeed, NAT-piercing isn't new or even revolutionary. It's a small feature of our mission to make building IoT apps as painless and fast as possible.
Our main goal is to build an ecosystem of ready-to-use devices and a RESTful API around this ecosystem so devs can focus on building their awesome IoT application, rather than bothering with the infrastructure. This is a component of that effort.
I don't think NAT piercing works if both of the endpoints are behind NAT, which might happen in this case (e.g. RaspPi + controller app on smartphone).
You could run a server in the middle; but that's exactly what this is.
> I don't think NAT piercing works if both of the endpoints are behind NAT
It does, in many cases even without on any third party. That is a (mostly) solved issue for at least 5 years or maybe even more. Here are examples of such tools: http://samy.pl/chownat/ and http://samy.pl/pwnat/
There are cases such tricks won't work (like overly conscious connection tracking engine and all ICMP traffic blocked - but without ICMP one would have PMTU issues and those ain't fun), but there're always STUN and TURN. The distinction is, those is not middleman, but just a NAT piercing helpers. They don't pass your traffic through and they're generic and useable with any service.
Skynet provides cloud infrastructure for IoT applications, but Crowsnest is aiming to have a few additional things on top of that:
- a rich ecosystem of device integrations,
- a framework for quickly creating new integrations, and
- an API that abstracts these devices into organized classes with
their capabilities
We are actually strongly considering Skynet as a core tool of our backend to manage all of our machine-to-machine messaging.
Really brilliant idea and I can definitely see this taking off. We built something like this at Cisco for physical security purposes so there's definitely a use case but I can see many more use cases for this.
My only gripe is that this service sounds more geared towards businesses as the pricing model for consumers seems expensive. Nonetheless, I'm rooting for you guys and can't wait to see what happens.
Can someone clarify the value-add? Is it a polyfill for APIs?
If the device already has an HTTP interface over the network, I don't know if it makes sense to pay per device for translation of your API calls... Also, this kind of thing, I would hope was free -- working towards adoption of a standard (i.e. if you make a jquery-level standard that unified so much functionality, at some point, people will forget the semantics of the lower levels and hopefully go to one standard)
Not exactly polyfill, although the idea is related.
Crowsnest is trying to help reduce boilerplate for IoT / device-driven applications. Crowsnest provides cloud infrastructure, two-way communication with your devices that works across a NAT, and an ecosystem of plugins for devices that will work out of the box. Interacting with all of this is abstracted into an API where all you need to know is that "it is a light" and you can use the cloud API to "turn it on." Crowsnest takes care of the NAT traversal and the actual calls to the light on the local network, so that you can focus on building your application, rather than maintaining device infrastructure and integration.
As pointed out in another comment, it's hard to compete with existing standards, but we hope to act as a super set as much as we can, making use of existing standards in our implementation.
Projects like this will be important going forward. Making a robust API that can interface in a simple manner with all of the new types of fancy household gadgets (philips hue, lockitron, etc) as well as devices which are of practical business concern like alarm systems and cameras, is a sound goal. Anything that makes fidgeting with proprietary UIs of various household devices closer to a thing of the past gets a vote from me.
So I need an RPi (finally, a reason to use mine...) and a supported video camera? What other devices are you adding and when? Any other examples other than this: http://crowsnestdemo.tumblr.com.
We started out with cameras because they are pretty rich devices, and we wanted to start with just one device. We are currently working on an open source plugin system with the intention that anyone will be able to add IP devices to Crowsnest. We're aiming to have this out in about a month.
When we release the plugin system, we're also going to release a handful of integrations made using it, including things like the Wemo outlets / switches, Philips Hue, Nest Thermostat, and Libelium's air quality / water quality / smart agriculture sensors. We want to build things that the community and our customers need, so if there are things that would be particularly useful or interesting, we'd love to work on those first. We're always looking for feedback and ideas.
What protocols do you support? BACnet? Modbus? ZigBee? LON? X10? Does it integrate with SCADA systems? Home automation is a messy area with a dozen "standards".
The device integration framework is currently Python running on an RPi, so if you have Python libraries to talk on any of these protocols, we're trying to make it easy to build plugins that will support devices that talk via these different protocols. Because the integration framework is open source, we hope that developers will contribute these projects back to the community, so we can support as many of these as possible. And when we release the plugin system (soon!), we plan to seed the community with a handful of integrations to get it started.
Our API / cloud service is not. The device integration framework (which runs locally on the RPi) is going to be open source, so that anyone can create plugins / integrations for any IP device.
Although we don't have it specced out yet, we have been talking a lot internally about using some kind of discovery protocol so that devices can report their capabilities and get up and running without an explicit integration plugin.
If you have any ideas or best practice thoughts for doing the discovery, we'd love to hear them.
Not meant as anything but constructive observation - but not open sourcing the core means it could be seen as another closed platform play, with open source plugins being used as a way of getting free features. My guess is that if this idea is compelling enough to get traction, a FOSS version would emerge in any case - for reasons of privacy, price, technical roadmap ownership etc. and the real money would be in offering services and products around that (I'm thinking Wordpress/Automattic). It's an obvious pov and I could be completely wrong of course :p (I guess IFTTT is the counterexample)
Yeah, releasing parts of Crowsnest as FOSS is a hotly debated topic internally. We would certainly be interested to talk to anyone who has experience running a business with a core product that is open source, especially if they were able to raise capital.
At Singly, we raised about $9mm of VC with 100% of our code open source. We saw that as absolutely essential in creating an ecosystem and it was a huge benefit in reducing customer concerns around lock in.
I like what you guys are doing and would be happy to chat if it's helpful!
So, if I built out 10 RPi based thermometers, that would be $40/month just to get a quick API?
If I added a humidity sensor, that would add another $50/month?
That's pretty steep. Granted, you could be targeting corporate and this starts to make some sense. That kind of pricing really does make it impractical for home users. You're already targeting an audience with some tech savvy and it doesn't take much to write a Python app to serve an API.
Thanks, this is great feedback. We are considering a community tier of pricing aimed more at hobbyists to suit what you're talking about. We're currently targeting startups who are building creative IoT apps and want to iterate quickly and for whom enterprise platforms don't make sense. We're trying to help them move as fast as possible while they optimize their product/market fit.
Another Crowsnest founder here. We're bouncing around the idea of incentivizing contributors to be involved in the community with additional free devices (assuming we can mitigate abuse). For example, if someone contributes the integration library for a specific device then there number of free devices per month increases by 5. Good idea / bad idea? Hoping to get feedback on this.
Sorry for skepticism, but I'd say it's certainly a better to invest the same money in making the same RPi (or alike device(s)) globally-addressable and accessible from the Internet. Indeed, this approach loses all fancy cloud buzzwords, but it brings much more practical value.