How to structure my app

[DaAwesomeP]

I am creating a home automation system. There will be a central hub and smaller devices. The hub will run on a real computer, but the devices will be things like a Raspberry Pi. The web control panel will access the hub for sure via its API, but how should the smaller devices access it? I'm not really planning on scaling this, so I'm not worried about scheduling tasks either with cron or another node library, but I'm still trying to figure something out:

I have three options:

1. The smaller devices will be nodes in the cluster with the central hub. The problem with this solution is that Redis isn't necessary nor worth the memory consumption on a Raspberry Pi.
   
2. The devices will access the hub via its API. This is less efficient from a coding standpoint since much of the same code that runs on the hub will run on the devices and vice versa. THe hub will be a device itself.
   
3. The hub will have a server service and a client service. The client can run on any device including the hub. This is the best solution, except that I won't be able to take full advantage of Action Hero. On the hub, where I will definitely be using Redis, I will have to implement my own taks system and everything else.
   

The devices will be running SQLite for their task queues since it is lightweight, fast, and it will only need to be accessed synchronously. The hub will be running Redis. The idea is that a cron job will run a script with an ID argument that corresponds to a task (a JSON object) in Redis or SQLite. Tasks can run from either the hub or a specific device. The hub will be able to send a task to a device in realtime to run immeaditely as well as schedule tasks on them. Action Hero will manage assigning tasks/jobs/schedules to devices and the hub. It will also track uptime of devices and itself into a database (not SQLite). I will probably use a TCP sokcet since I can track connections and disconnections.

The system will be modular. Rather than implementing things that I don't own (i.e. a Nest thermostat or another home automation product), I will allow NPM modules to be installed that will interact with the system. They can be installed to a device or hub. Something that controls something else on the network would probably be installed on the hub, but a module to control a garage door with switches and relays would go on a device.

The hub will also run like IFTTT. If a device reports "Garage door 1 open," then the hub can respond with actions/tasks on itself or other devices immediately based on set options.

I suppose #3 is the best route unless Action Hero can use SQLite as a cache system. I don't want to use the "fake" Redis server either because it will build up memory too. Raspberry Pis don't have much memory (mine will have 512mb).

I know this is a lot to read, but I want to get this right the first time. I have a lot ahead of me and I don't want to have to do anything over. Thank you for your help!

[Evan Tahler]

I'm confused about why the devices need a task queue at all.  If you can run the "master" on a real computer (with real databases like reds or mySQL), why do the client applications need their own state?  As long as the clients can poll the master API with a "what should I do next", you can keep state and their individual queues in the master.  This is far better from terms of resiliency, the clients can then go on and offline randomly, etc.  

Actionhero can speak a number of protocols, and might be a good fit for your "master/hub" API, but I wouldn't suggest that each of the clients run a full actionhero server.  Your goals are probably to keep RAM low, and almost more importantly for battery life, to keep the networking overhead low too.  Take a look at the actionhero node client library which you can use in the clients.  It will keep a TCP connection open, but if you plan on having clients poll for state often (i.e.: more than once a minute), you can probably save bytes this way.  If you are polling for "what should I do next" less frequently than that, HTTP is probably better (you'll save battery life turning off the wifi chip between requests). 

Also keep in mind that it might be more efficient to write your clients in a language other than node.  You can't really boot up a node.js process in under 1MB, but you can with GO or C.  Actionhero just speaks JSON over TCP (and JSON over HTTP), so you can still use acitonhero as your hub no matter what you choose for the clients. 

Good luck! 

--
 Evan Tahler | evant...@gmail.com | 412.897.6361

 evantahler.com | actionherojs.com

--
You received this message because you are subscribed to the Google Groups "actionHero.js" group.
To unsubscribe from this group and stop receiving emails from it, send an email to actionhero-j...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[Evan Tahler]

Oh, also: IoT projects are the *opposite* of "I want to get this right the first time" In my experiences.  There is tons of iteration you need to do to get things working right, and there are so many chains of actions which can break at any point... but that's half the fun!

Some of my IoT projects:

- https://github.com/evantahler/nodePhidgets

- https://gist.github.com/evantahler/1574158

- http://blog.evantahler.com/blog/node_for_not_http.html

--
 Evan Tahler | evant...@gmail.com | 412.897.6361

 evantahler.com | actionherojs.com

[DaAwesomeP]

Thank you for your suggestions. As you said, I think I'll run Action Hero only on the hub. The client library will run on the devices. This is probably better since I can run the client on Windows, but not the Action Hero server. I I'm not worried about battery life (the devices will be plugged in and most likely on Ethernet), so I'll use the TCP socket. The devices will need their own queue so that network traffic isn't absurd and so that the hub can go offline at any time just as the devices can. I want it to be a very reliable system.

Also, I've had great experience with running node & SQLite on ARM devices. I'm fine with using a lot of memory, but Redis could cause a memory leak or other problems, as it's designed to use lots of memory.

So I guess that Action Hero will simply be directing traffic between devices, programming devices, logging, and etc. And about getting it right the first time, I do have a lot of work to do.