ShowHN: dweet.io – Twitter for machines

[Bug_Labs]

We created an amazingly simple IOT utility and are giving it away for free. We constantly found ourselves needing an easy way to get machines, sensors, and Things online and quickly get data from them. So we built Dweet.io, a simple websocket-based utility for connecting your things to the Internet. And we're opening it up to everyone. We'd love to hear your thoughts and suggestions for it.

Http://Dweet.io

- Bug Labs

[chrissnell]

Interesting idea but I would offer an alternative to JSON for device<-->dweet communication. JSON parsing on small embedded processors is often memory- and CPU-prohibitive. A small (preferably binary) protocol is lighter and faster to work with on these little microproccessors. When I built my Lightcube[1], I designed a binary protocol[2] that is easily parsed on the Arduino or even the smaller ATtiny microprocessors. Designing and implementing the protocol was a learning process for me but I ended up with something that didn't tax the CPU, leaving me more processing cycles to interact with my hardware.

[1] Lightcube: https://github.com/chrissnell/Lightcube

[2] Lightcube protocol: https://github.com/chrissnell/Lightcube#lightcube-protocol

[c4miloo]

I'm curious about why MQTT didn't work for you.

[angersock]

So, it's ugly, but just treat single-level JSON as a really oddly-padded binary blob, right?

Match on opening bracket, skip forward to third double-quote, ingest string until hit unescaped double-quote, process string.

EDIT: You're looking at up to like 6 bytes of overhead:

{"a":"<blob>"}

[Fasebook]

NEVERMIND THAT, APIS IN THE CLOUD MY FELLOW ENTREPRENEURES

[sthatipamala]

Why does the API respond with keys like this?

    "this": "succeeded",
    "by": "getting",
    "the": "dweets"

It's cute that it's human readable but one would have to write awkward code like:

    if(response['this'] == 'suceeded') print response['with']

[jheising]

Agreed, in the code-readability sense it's a little on the strange side, but I wouldn't call it completely nonsense either. My thinking behind the design was that developers are a lot easier to deal with than end-users/laypeople who you might rely on to help debug things. Besides, it's easy enough to write wrapper functions or use DEFINE (in the case of C/C++) to make the code more code-readability-friendly.

Nothing is perfect for everyone, and I think the response is probably the least important aspect of HAPI. The biggest bang for the buck in my mind is self documenting URLs and support for only HTTP-GET verbs. Just my $0.02 :)

[telecuda]

Cool and good luck! I'd be cautious about the name sounding so close to Tweet, especially when you advertise it's "like Twitter." Less impact changing the name now than later.

[toomuchtodo]

bark.io? People tweet, machines bark orders at each other :D

[adamb_]

Very cool. One suggestion for the product page is some simple use-cases for why you'd use such a service. Also, are there size constraints for the dweets?

[filiwickers]

Ya, perhaps I am being thick, but what would this be useful for?

[primitivesuave]

This is awesome! It used to be somewhat inconvenient to set up a simple message-passing backend for my Arduino Ethernet. This is exactly what I needed to eliminate that mundane task. To the creator, my eternal gratitude!

[Bug_Labs]

Thank you for the kind words. Please let us know how you fare.

[alexnking]

Nice! One thing I would like to see is some way to reserve names so that only I can use them – right now if I'm publishing data to http://dweet.io/follow/outdoors , anyone can easily override that with http://dweet.io/dweet/for/outdoors?no=temp&for=you - so that'd be a neat feature. Unless the idea is that handles would be shared between devices...

BTW, I'm dweeting that outdoor temperature using SmartThings and this code - https://gist.github.com/alexking/8880479

[Bug_Labs]

Hey, this is awesome. Would you mind if we sent a tweet about what you did and link to that code? Any chance you might be interested in writing a guest blog on how you connected?

[jheising]

Yes this is by design to make it easy. Being able to lock things to make them private is an upcoming feature. No promises, but probably will be available this coming week.

[psemme]

Just curious - are you accessing your SmartThings device directly or via their API? Thx.

[bdcravens]

So it's a pub-sub over HTTP. Attaching Twitter to the name makes it sound like something Web 2.0, I suppose.

[jheising]

Yeah that's pretty much it. We're not claiming anything earth shattering or new here— just something that is dead simple, and works.

[bliti]

I'm currently working on a similar system aimed at robotics. M2M is rapidly growing under the radar due to mobile phones making a lot of the technology needed cheaper. The interesting bit here is the protocol. Which still feels a bit off to me, but still works well. Designing protocols is not an easy task. Well done Bug Labs.

@jheising Send me an email. I'd like to get a friendly conversation going on. :)

[jheising]

Will do mate.

[terabytest]

I kind of like the HAPI concept but it feels strangely redundant. Especially in the responses, where almost half of the k/v pairs are just for "decoration" purposes. I concede that it does make things a slight bit easier to read, but are you guys sure it isn't bordering on redundancy for the sake of redundancy?

Very nice idea, by the way! Congrats!

[jheising]

It might seem like it, but it's actually not that different from a lot of REST APIs I know of. Most REST APIs return a status (in our case "this":"succeeded"), and some sort of wrapper for the actual data (in our case "with":{}). The only thing that might be redundant is the "by" property, but I think it's useful to have in cases where you want to make doubly sure that the API did what you thought it was going to do.

[dchuk]

This is the first time I've come across the HAPI spec. Does anyone know of other projects that are using that style of API?

[ville]

Many parts of the HAPI spec seem to be in outright conflict with the established best practices and standards. E.g.

> A HAPI must support the HTTP GET verb on all operations.[1]

Contrast this with HTTP/1.1 RFC 2616:

> In particular, the convention has been established that the GET and HEAD methods SHOULD NOT have the significance of taking an action other than retrieval. These methods ought to be considered "safe".[2]

[1]: https://github.com/jheising/HAPI#general-rules

[2]: http://www.w3.org/Protocols/rfc2616/rfc2616-sec9.html

[josephwegner]

Do you guys make any promises about latency between when a dweet is sent and when a following client will receive it?

Among other things, this seems like it could be a free pub/sub system.. If the latency is low that would make this incredibly useful.

[jheising]

No promises yet, but we plan on offering paid plans that could offer SLAs on latency. Although I will say we architected it from the get-go to be high throughput and low latency— it's all using redis in-memory on the back-end.

[cpr]

Nice, but the API seems pretty non-RESTifarian.

/get/latest/dweet/for would more naturally be /get/dweet with a time parameter, or some such.

/for/[device] would more naturally just be a device parameter.

Etc.

[robdor]

The first line of the documentation says that it uses a "HAPI-REST API". https://github.com/jheising/HAPI

[Bug_Labs]

Today we are launching dweet.io, an amazing IOT utility. We are giving it away for free, so please try it. Thank you!

[crymer11]

Will this always be a free service? Who will pay for operational costs?

[s_kennedy]

So cool. Such a simple yet revolutionary concept to enable open and extensible connectivity for IoT.

[jchulce]

Why on earth are you not using HTTPS?

[jheising]

Right now there is nothing to protect because the API is inherently open (on purpose to make it easy). But next week we will be introducing a security token mechanism to be able to "lock" machines. In this case HTTPS will be important and will be required. So yes, it's coming...

[ChuckMcM]

Oh this is very cool. I am so going to plug this into my Electric Imp when I get home.

[Bug_Labs]

Awesome! Please let us know it goes. Thank you.

[angersock]

Would you all be interested on hosting a contest to do something cool with this?

[Bug_Labs]

We certainly would. Please let us know what you are thinking. Thank you.

[jkarneges]

Interesting idea. How about documenting the real-time updates protocol?

[jheising]

It's socket.io. But we can/will document more on it soon.

[elwell]

Maybe once a week does a website design make me smile. Thank you.

[angersock]

"What's the catch?"

The whole world sees your machines. :)

[jheising]

Private machines are coming soon...