ShowHN: dweet.io – Twitter for machines(dweet.io) 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 |
[1] Lightcube: https://github.com/chrissnell/Lightcube
[2] Lightcube protocol: https://github.com/chrissnell/Lightcube#lightcube-protocol
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>"}
This was my first project where I worked with binary and I learned some neat tricks. For example, the simulator that runs on the Arduino has to downsample the colors to work within the constraints of the 3-bit color that the "Ansiterm" library offers. When I first approached the problem, I was envisioning a complicated series of "if" statements to map the 8-bit color to 3-bit. Then it hit me: I could simply mask all but the highest bit of each of the 8-bit R/G/B colors and use that to generate my ANSI color blocks. This is something that I might not have learned if I was using JSON to pass the data.
"this": "succeeded",
"by": "getting",
"the": "dweets"
if(response['this'] == 'suceeded') print response['with']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 :)
It reminds me why we even make these things available online. Why do machines need to talk to each other? If they need to collaborate in order to complete some tasks, they should be controlled by human or program.
You can make these things online talking HTTP as toys you are playing with your childhood friends, but not for serious business products. It becomes a trend now. Kidding.
From two aspects:
1. Cost: in order to make them talk HTTP or API, you need all of them carry a web server which is installed on top of OS. It's not necessary. Machine needs very simple commands to drive them to perform certain tasks because they already know how to do it, you only need to give them instruction on what to do.
2. Security: machines at home should be controlled inside the home or by computer controlled by home users, which could be sitting in the cloud with other OS level of security instead of HTTP or HTTPS. If you are going to expose all of your device status to the internet, do you feel secure? If you do want to control remotely from home, you need to find some way to make schedule or via the cloud.
- Public swimming pool temperature
- Air quality information in city
- Traffic light status
- Train GPS position
BTW, I'm dweeting that outdoor temperature using SmartThings and this code - https://gist.github.com/alexking/8880479
@jheising Send me an email. I'd like to get a friendly conversation going on. :)
Very nice idea, by the way! Congrats!
> 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]
For example: Here let me show you how to delete that resource using our API... Oh wait, damn. I can't show you because I have no way of sharing a link with you because it requires the DELETE verb. Just go read this documentation and get back to me when you're done. ;)
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.
/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.
It's a pretty low-level product, right--basically a messaging fabric in the cloud that is easy to use. I can think of some delightfully perverse things to do with it, as can I imagine others.
The whole world sees your machines. :)
There's also something to be said for using a well-known protocol rather than something obscure which is likely to require time to debug because it's had many orders of magnitude less usage.
I agree with you that machines should not talk on the HTTP level, it's over kill. Machines only need very simple protocols to exchange current state if they do need to cooperate. To me, if devices can transfer state with the controlled program should be good enough so that the program will send the states to other machines for them to determine what's going to be the next step or directly give them instruction on what the next step to go.
I know it's a lot fun to build this type of cute machines, but it's not economic.
Lets start with performance. If you're trying to get a predicted 26 billion devices by 2020[2] on a Node.js/Socket.io Framework, you're going to need so many machines, the business case wont be viable. Socket.io is great for message passing, but at high throughput, it's going to fall short. Message busses like ØMQ (ZeroMQ) are a lot lighter and can bind to file descriptor without requiring spawning up an HTTP server. As for Node.js performance; It's great for JSON serialization (Which you're going to be doing a lot of), but it's far from the fastest. Node blows away languages/frameworks like Ruby/Rails and Python/Django in speed when it comes to JSON serialization (And almost anything else), but it's still in the 30th percentile for JSON serialization which is very low[3]. With this being one of your most performed operations, this is something that should be as fast as possible.
As far as concurrency is concerned; Node.js isn't an inherently concurrent language although it does have it's non-blocking I/O callback magic. Obviously, you can use modules like cluster, the native process spawning or backgrounder[4], but the weight of threads is going to be so expensive compared to the amount of work that's needed to be preformed. Supporting concurrent paradigms like RUN.At, RUN.Until, RUN.After, RUN.Every, RUN.WithTimeout, and RUN.BatchJobs are easy to do in Node.js, but then getting those individual processes to talk to each other in an orderly fashion using callbacks and Socket.io seems like duct tape and chewing gum over just using a language that supports concurrency natively.
Other than that, I love it, I understand the vision (because we're building something similar), and I'm very glad that you guys open sourced this project.
[1] - http://www.vroomtrap.com/downloads
[2] - http://www.gartner.com/newsroom/id/2636073
[3] - http://www.techempower.com/benchmarks/#section=data-r8&hw=i7...
Also, we only use socket.io for real-time pubsub, but you could just as easily use a polling mechanism with HTTP to get similar results if you're worried about the performance and overhead it carries.
I think perhaps the most important thing is to be very clear about our goals here. Dweet.io is NOT built for super low-latency pub/sub. IMHO most devices in the future of IOT won't need to communicate to the cloud more than a few times every minute or at the most once per second. For the devices that need low-latency (sub-second) pub/sub, I agree, you should look at other protocols like MqTT. But if I were a betting man, I'd say the vast majority of IOT devices in the future will not need this level of performance to warrant the extra headache.
An Arduino can run a web server. It's amazingly cheap to run HTTP.
> 2. Security: machines at home should be controlled inside the home or by computer controlled by home users, which could be sitting in the cloud with other OS level of security instead of HTTP or HTTPS. If you are going to expose all of your device status to the internet, do you feel secure? If you do want to control, you need to find some way to make schedule or via the cloud to control them.
My door lock, thermostat, and smoke/CO detectors are already controlled "via the cloud". In for a penny, in for a pound. You're always free to not buy the devices.
We can have centralized program to control all the things at home. Two usages:
1. Need to control from remote: we should control them via OS level security to reduce the unnecessary cost to speak HTTP no matter how cheap the OS is. If they can be controlled directly, why do we need them to understand HTTP?
2. Need to talk to each other: they can talk via the controlling program. They don't need to be that intelligent to talk to each other via HTTP.
By the time when we have every "thing" at home, you can see the difference. The cost must be reduced to almost nothing in order to make home automation popular with very low additional overall cost compared with the existing devices. Again, think about it, we'll have 100 things at home, are you going to buy every thing for $100? Not necessary, not scale.
Their way:
DELETE /something HTTP/1.1
My way:
GET /delete/something HTTP/1.1
Do you really think one is more secure than the other?
If I was phishing to get you to click on a link to delete a resource, then I would need to know that token, and if I knew that token, then I could just delete it myself. Note that the HAPI spec discourages the use of cookies (which I agree could allow a phishing attack if you were using cookies as a security mechanism).