As for the project, I've got some overview documentation up on github. Basically I'm using a Raspberry Pi as a gateway device which can connect to multiple Arduinos via Bluetooth. The Arduinos collect data (temp, ph), switch relays, do leak detection, etc. controlled by the Pi. The system itself is managed via Azure IoT hub. Everything is fed into a mobile app (cross platform) on which you get a realtime feed of how things are, notifications and some options to control the things like relays and stuff. At the moment I'm monitoring temp inside and outside of the tank, pH and leak detection (basic water / conductivity sensors). Flow would be a nice addition for maintenance warnings. I've also got some simple float sensors ordered which I want to use to check my stock solutions. Lots of ideas
I can open up a new thread about that one if you think more people will be interested? I know I'm not the first one with such a project, but I think I might be the first one with a multi-tenant back-end service.
Looks like an interesting project. Why did you decide to have separate arduino modules to run sensors? I can see potential advantages but it just seems to complicate the design.
I've been meaning to post some details of my own project for some time.
The code is available here:
https://github.com/mark-kendall/torc
and documentation (what there is at the moment - and slightly out of date):
http://mark-kendall.github.io
Hardware wise, it's built around Raspberry Pi's but it's a c++/QT5 based application - so runs on any linux distro, OSX and windows. Support for other platforms such as beagle bone should only require writing some low level GPIO classes. Current external hardware support includes any simple input (buttons, switches, PIR sensors etc), simple outputs (switches, relays etc) and 1Wire temperature probes. PWM outputs are either software driven, 'hardware' via the supported pin or via external PCA96585 (I2C) PWM devices. I'll be adding native hardware PWM on any pin via the servo blaster code at some point (reduces the need for external devices). There is also code stubbed out for pH and lux sensors. All input and output types have a network 'equivalent' as well - which allows for external input/output and setting values for dimmers etc.
Software wise, configuration assumes one of four device types - input, logic, output and notification.
Inputs and outputs obviously define how your pi is connected to the real world and notifications update external devices (current support is for PushBullet notifications to your mobile device and ThingSpeak for external data logging and analysis).
Logic devices add the 'intelligence' - timers for lights/pumps etc, transitions for fading/sunset/sunrise effects and comparison/logic devices for 'decision' making (greater than, less than etc).
There is a built in web server for querying and controlling the state (every device is exported as a service) and a 'built in' HTML5 web app for your viewing pleasure
The web page is dynamically updated, as it uses a web socket to talk to the pi. The web interface is password protected and I'm working on SSL encryption. There is full support for translations in the web interface - just needs people to translate it
.
Each server advertises itself on the network via Bonjour and UPnP and servers are aware of each other on the network. At some point I'll finish the code that allows them to control and report on one another (e.g. to allow one pi to act as the interface to the web or allow a server to report that another has gone offline).
The web app still needs work to make it a little (lot) more user friendly - but the core code has been working for 18 months now. I'll post some screen grabs at some point to show the current web interface - which will make much of the above a little more comprehensible.
Cheers, Mark