The general architecture of the paper tiger is built on the shoulders of giants. With Node Red being the orchestra master, InfluxDB plays in the data pit, and Grafana provides the dazzling optics.
By using these Open Source tools, we don't have to reinvent the wheel. Additionally, because of their popularity and the nature of Open Source, we can bennefit from their natural improvements & enhancements. Should we need something specific, we can provide it and contribute to the Open Source community. Further, by localizing everything you need for your system on manageable foundations, you keep control of your data. If you want to share aggragate data for better analysis, you can, but you have that option. Still another advantage is the ability to radically modify the stack. For example, the current implementation is based on WebSockets, due to the lightweight client and low network overhead. However, MQTT is a popular transport mechanism whose structure lends itself to simple parsers, and providing message guarantees.
Each microcontroler knows what sensors or actuators belong to it, and how to access them. It connects to the Node-Red WebSocket and waits for instructions. Some clients may have abstracted instructions that result in more detailed work at the microcontroller level. This enables things that require near real-time feedback to be functionalized. For example, a self-leveling platform might use 4 motors and a 9 axis gyroscope, and instead of putting the brains in node-red, they reside inside the microcontroller, accessable via a single command, which our dutiful programmer has called, "setLevel". Upon receiving the command, the microcontroler uses the feedback from the gyroscope to move the motors until the platform is level. This kind of decision making is left to the developer, and is usually based on acceptable latencies.
Microcontrollers communicate with node-red via a WebSocket. This enables fast bi-directional communications. A simple JSON protocol is used to deliver the command to the targeted sensor or actuator. One can think of "sensors" as read-only information sources, and "actuators" as anything that can be turned on or off, dimmed up or down, or physically moved in some way (like a motor making a 1/4 turn). In this way, a user who wants to control the temperature of their environment can read the temperature and turn on or off a heater or an air-conditioner. If the actuators (in this case, the heater & A/C) have variable levels (e.g. high, medium, low), those can be set as well.
Node Red (nodered.org) is a very extendable web-interface for all variety of things. More info on the specifics of Node Red can be found in their Users Guide documentation. Here, we'll document how we're using Node Red.
We've created a node-red node we call the "Device Manager". It takes it's input from a WebSocket (or an MQTT client). Each device is registered, and a simple web-interface is used to direct the interactions with the registered devices. This second part - the interface for device interaction - is effectively themeable for use in whatever system is being managed.
For example, a complex salt-water aquarium with multipule pumps and lights and sensors could be represented with an eye towards that kind of application. On the other hand, an outdoor garden watering system with pumps and valves and water flow sensors could have an entirely different representation that includes watering zones, and other amenities specific to that domain.
By enabling a kind of application plugin, old units can be easily re-purposed for a longer life, as well as reducing the effort to get running quickly. These can be further customized with all kinds of things, inlcuding activity logs, change management, process documentation, etc. The ability to extend the reach of the physical world becomes easy. And by embracing the web-interface, the server back-end and client front-end processing can be exploited in novel ways.