Hacker News new | ask | show | jobs
by PaulHoule 1658 days ago
Ordering is an expensive property.

I built a system where

  1. Sensor events were picked up by a ZWave device connected to Samsung SmartThings
  2. SmartThings would call a AWS lambda function I wrote (SmartThings lives in AWS so this is efficient)
  3. My lambda function posts an event to an SQS queue
  4. My home server takes the event off SQS and posts it to RabbitMQ
  5. A queue listener takes events from RabbitMQ and takes an action
So long as I was using ordered SQS queues I would sometimes get a 5 second delay to turn on a light. When I turned off ordering the latency was perceptible but didn't make me want to jam the button multiple times.
3 comments

But why would the signal to switch on the light ever leave the building?
Because SmartThings was born out of a software consultancy that knew how to do backend cloud services, but not embedded. The v1 hub was just a pic microcontoller that sent raw radio messages up to the cloud for all parsing and processing.
(1) If you are letting people code their own event handlers you wouldn't trust them to run them on a tiny machine like that.

(2) A system like that probably wants to be able to respond to events both inside and outside the house. For instance, turn on your lights remotely with a phone. A cloud component is the reliable way to do that.

(3) At the time I couldn't find decent Zigbee or ZWave hubs other than the SmartThings hub. The cloud dependence is silly, but other than that the hub is great and connects to almost everything. I could go with a Kickstarter hack or try to roll my own but I don't think it would be much better.

> If you are letting people code their own event handlers you wouldn't trust them to run them on a tiny machine like that.

Actually, you can do exactly that now: https://developer-preview.smartthings.com/docs/devices/hub-c... Though that's only for device integrations, so not an exact solution to removing the cloud from the loop on your stuff.

ST is slowly getting away from being totally cloud-centric.

That is a good example. Off topic, but what is the reason to post the event to SQS and then to RabbitMQ? Why not take the events from SQS directly and take the action?
Events that originate from inside the house go into the RabbitMQ. RabbitMQ is the central bus for all sorts of things. In the process of diagnosing that latency I found that part was pretty fast.
One thing I will say is if you need queuing, very few people actually need global queuing, they only need per-user queuing. Have fixed a number of systems where EVERY event in the world was going through the same queue, and replaced that with an array of queues sort of solution. At the end of the day this usually doesn't even need a real queue, just some database transactions and atomic ordering columns that ensure consistency and order of the events within some very specific scope (like a user). If the most events you'll ever see in a row where their order (with respect to each other) matters is like 5-20, you probably don't even need a real queuing service.
If there only was another way to turn on a lamp…