So, what good is a 24/7 home sensor base station if it loses messages?
I originally planned to run the beagle board based station as an AMQP client talking to a cloud server where data would be correlated and presented to users. Unfortunately, from a design perspective, this doesn't address temporary "internet outages". What does the station do with a bunch of events when it can't reach the cloud server?
Well, how about running RabbitMQ on a Beaglebone? This local instance of RabbitMQ would act as a cache and shovel events/messages to the cloud server RabbitMQ when it is available. By using a local "work" queue, I can utilize a different delivery path in case the internet connection has gone south (power outage?) for a pre-defined duration. This backup path could be a cellular modem.
I am using the nerve erlang distribution and after building a bunch of supplemental Erlang packages, I was able to get the latest RabbitMQ (2.8.2) running on the Beaglebone. I haven't put it through its paces, but it does seem to run the management plug-in and I can navigate it with a web browser.
Resource-wise, the "freshly" launched RAM footprint is around 30MB. Performance may be an issue, but it looks like I have some room for at least a few sensor event messages. And, I don't need spectacular performance, I need reliability.
I will put it through some stress tests, but I like the overall architectural approach: Erlang/OTP and RabbitMQ in the home base station.
Hi, could you please describe the process you went through to get rabbitmq server going?
ReplyDeleteThis comment has been removed by the author.
ReplyDelete