One of our distilling clients wanted a no-frills but technological way to conduct surveys during taste tests. The idea was to link up a front end displayed via a mobile browser client navigating to a URI (preferably through QR code scanning) to a back end that was mostly just a Google Sheets spreadsheet with one tab per survey, saved off manually. Our solution was a simple JavaScript web app provisioned with AWS Amplify and using AWS Lambda to translate back and forth between the Google JSON response. Example survey format and interpreted visualization based on this paper.
Sparky is the prototype for a generic hardware and software system to be dropped into a static industrial environment and handle data ingestion, transformation, and storage. The hardware consists of a 3d printed chassis that fits 6 Raspberry PI SBCs horizontally into a 19" 1U rack tray. A narrower vertical configuration is possible, however the smaller form became more of a liability when trying to enclose or mount it vs the widespread availability and durability of small server racks. The rack configuration also simplifies PoE injection or conversion to power adapters if not using PoE.
The software is 100% open source, designed to be provisioned via shell scripts and generic enough to slot into a variety of systems. Data ingest is handled by RabbitMQ or open62541 for messaging (MQTT or OPC respectively) from an industrial gateway and handed off to NiFi, which also handles static file ingest (i.e. spreadsheets) from NAS. Kafka and Spark are provisioned but are only used if we need to transform data in-flight; and NiFi is providing the handshake with them. All of those routes lead to Druid (at the time of creation Cassandra was not working reliably with SBCs), which is aggregating and storing the disparate [enriched] streams and provides a [relatively] simple API into Superset, that we will employ as an operational dashboard.
Using all this Apache software may seem like using a nuclear weapon to kill a fly- and it would be if we were concerned with telemetry throughput. However, our goal here was to come up with a data monitoring system that could be quickly and cheaply implemented across a broad spectrum of industrial use cases. This broad applicability precludes the use of cloud native services and relies on an air gapped network as its primary form of security. To go a more secure route and provide native cloud functionality we would go the route of a Sphere MT3620 for Azure or FreeRTOS MCU for AWS; however these would obviously be fit for purpose builds- requiring more time and a higher cost to the client.
All mechanics have favorite tools; and most industrial operators (or brewers!) have their preferred interfaces. Sometimes ditching equipment you've grown accustomed to in favor of 'smarter' equipment is not an option. We were approached by a client who found themselves in this situation: loving a specific temperature controller but just wanting the ability to interact with it remotely.
Our solution in this case was to modify the component board itself, replacing the buttons with MOSFETs and emulating menu entries (i.e. the pressing of multiple buttons) by discretizing those sequences into atomic functions exposed to the operator as individual components in a web app formatted for mobile devices.
Credit where credit is due, this project was shamelessly inspired by this but modified to wrap around AWS instead of Google.
Commercial SIM (Snow Ice Melt) systems tend to be extraordinarily expensive- mostly due to the monitoring and control hardware. This control system is necessary mostly to ramp the temperature to avoid concrete degradation; but the commercial sensors and components are overkill for a residential system. We were approached by a client that was planning on a full driveway renovation and was interested in a SIM system. We designed a monitoring and control system using only consumer grade hardware, with the caveat of an industrial thermostatic valve installed in a bypass loop downstream of the supply pump as a failsafe for manual control.
For the sensors, we 3d printed an enclosure housing a PoE-flavored Arduino Nano pinned out to a capacitive moisture sensor, thermocouple, and basic photocell. The module is adhered to the concrete substrate (including the bottom of the capacitive sensor) with the expectation of a 3 year lifecycle; and one mounted into the center of the drain pipe at the bottom of grade. These sensors are blended using a Python script in the Pi and combined with OpenWeather API information to determine whether the pumps should be activated.