Show HN: Crowsnest – API for the Real World
crowsnest.io
crowsnest.io
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.
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).
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.
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.)
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.
You could run a server in the middle; but that's exactly what this is.
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.
crowsnest_data = request.json
image = base64.b64decode(crowsnest_data['files']['image']['data'])
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. :)
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.
It would be nice if this turned out to be the "VLC Player" of home hardware, where you could fire it up and expect it to work with most devices.
That would take a ton of work on Crows Nest's part though.
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.
- 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
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.
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)
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.
Really cool idea, good luck with it.
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.
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.
I like what you guys are doing and would be happy to chat if it's helpful!
https://github.com/dandroid88/webmote
could use some api help though i suppose
Granted, we're still getting a feel for what our pricing structure should be, do you have any feedback about our pricing structure currently?
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.