ianawilson

I just added both a more detailed description of the product (based on this question, actually) and a couple of screens we have. Hopefully that helps to give a better idea of what we're doing!

Glad you're interested!

My email is ian (at) crowsnest (dot) io. Alternatively, you can signup on the front page, and I'll reach out to you a little later today.

Hi, yes, I'm a cofounder from Crowsnest.

There are two pieces: 1) A firmware library that runs on the device that has APIs for logging, assertions, and we're planning some other features to help gather data from the device (configurable by your firmware engineers, according to your resources). 2) A cloud backend that collects and analyzes the data sent from the device, with an interface for you to be able to search for a particular device, look at trends, or set up notifications. Is there something I can elaborate on in more detail?

I will look at putting some screens up shortly. Thanks for the suggestion!

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.

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.

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.

If you're available, we would love to set up a call or video chat to hear more about your experience! Send me an email: ian at crowsnest dot io

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.

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.

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.

Yup, that's exactly it!

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.