Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Show HN: Crowsnest – API for the Real World

crowsnest.io

Post reply on HN
Print view View original

11–20 of 39 posts

Re: Show HN: Crowsnest – API for the Real World

#11

Post by ianawilson »

rmah wrote: post #10

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.

Re: Show HN: Crowsnest – API for the Real World

#13

Post by jamesbritt »

icebraining wrote: post #8
drdaeman wrote: post #5

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 i…

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?

Re: Show HN: Crowsnest – API for the Real World

#14

Post by vorsgald »

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.

Re: Show HN: Crowsnest – API for the Real World

#15

Post by chch »

drdaeman wrote: post #5

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 i…

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):

    crowsnest_data = request.json
    image = base64.b64decode(crowsnest_data['files']['image']['data'])
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. :)

Re: Show HN: Crowsnest – API for the Real World

#16

Post by ianawilson »

chch wrote: post #15
drdaeman wrote: post #5

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 i…

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): crowsnest_data = request.json image = base64.b64decode(crowsnest_data['files']['image']['data']) would be an abstraction layer over the internal functions of all of the cameras. That way, if I wanted to, say, build an…

Yup, that's exactly it!

Re: Show HN: Crowsnest – API for the Real World

#17

Post by icebraining »

jamesbritt wrote: post #13
icebraining wrote: post #8

Earlier quoted context omitted.

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.

Re: Show HN: Crowsnest – API for the Real World

#19

Post by dreamfactory2 »

ianawilson wrote: post #9
dreamfactory2 wrote: post #7

Is it fully open source e.g. can I run my own crowsnest server for free, fork etc? And is there anything around federation and discovery?

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 p…

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)

Re: Show HN: Crowsnest – API for the Real World

#20

Post by jamesbritt »

chch wrote: post #15
drdaeman wrote: post #5

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 i…

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): crowsnest_data = request.json image = base64.b64decode(crowsnest_data['files']['image']['data']) would be an abstraction layer over the internal functions of all of the cameras. That way, if I wanted to, say, build an…

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.

Post reply on HN