Mqtt brewery
| Projects | |
|---|---|
| Participants | |
| Skills | soldering electronics brewing |
| Status | Planning |
| Niche | |
| Purpose | Use in other project |
MQTT Brewery Components
Introduction
What
Small re-usable wifi-enabled devices that function as a part of a brewery-system. Sensing, displaying, controlling or a mix of these functions can all be tasks any particular device can be tasked to do. Using MQTT as a message-bus to send/receive data.
The expectation is that the functions of the devices will be kept 'simple'; adhering to the Unix philosophy of making things that do one task and do them well; encouraging re-use.
Why
There are multiple reasons why you would want to do this. A large reason can be to minimize cabling issues by allowing a sensor/actuator to be placed anywhere, only requiring a power-supply to be present. Power could be drawn from the same source as for the actuator the device is responsible for.
Another reason is because of the recent emergence of cheap IOT-devices coming onto the market that allow easy integration into this kind of control-scheme, some of them even allowing re-flashing to be an autonomous MQTT-node on the network; foregoing the need for a bridge/router to whatever 'native' protocol it might have had.
How
Initially, the idea is to look at the SONOFF line of devices from ITEAD studio. These devices are based on the ESP8266 series of processors, integrating a wifi-stack on a 40-80mhz 32-bit processor core. They can be made to be 'arduino compatible', and have an eco-system of alternate firmwares available at least one of which focuses on MQTT-functionality.
One of the devices, the SONOFF DH10/16 is a 10/16Amp switch that also includes capability for measuring temperature or humidity through connecting an external 1-wire sensor. In the case of temperature, it supports a D18B20.
Other devices in the SONOFF line of products focus on simply switching AC-loads, provide multiple relay-outputs, etc. A greatly beneficial aspect of these products is their incredibly low price-point.
Concluding
The above , when taken together, leads to a number of interesting observations regarding the use of cheap IOT-enabled/like devices to put a brewery together.
- They are easy to acquire; allowing a brewery-project to concentrate on the process/control instead of (all) the hardware
- They are cheap ; resulting in making it easy to stock up on spares
- They are 'cordless'; allowing application in places where it'd be unhandy to route wiring to
- Moving sensors/actuators around becomes easier. Only a power-source nearby is required. Even battery-based operation is an option for 'mobile' sensors/actuators
- Their low price and their cordlessness makes it feasible to integrate more actuators in more locations/applications; providing better process-monitoring and/or control.
Components
In a brewing system, most of the sensors/actuators in use focus on the tasks of temperature-control , liquid transfer- and flow-control, gas transfer- and ignition- control.
At the physical layer, these consist of
- Temperature sensors
- Flow-meters (fluids)
- Load-cells (weight of fluid/gas in reservoirs)
- Solid State Relays (AC)
- Coil-relays (Low-power/Low Voltage DC)
- FET-banks (High-Power Low Voltage DC)
- Coil-operated valves (gas/fluid-control)
- AMP-meter (for monitoring overload of infrastructure)
- PID-controller (integrating the task of temperature measurement/control in one device)
Architecture
Imagine a set of devices that all have the ability to join a (WPA-protected) wifi-network where they'd come to seek out a predesignated MQTT-broker where they'd be given the ability to report data they have collected or listen for data relevant to them.
It is anticipated that there's use for (at least) the following sets of data-flow:
Data
Periodic information about measured values/states, etc
Control
Any device with the ability to influence their environment (AKA: actuators) would listen on this data-flow for information relating to them; telling them what is expected
Config
A meta-channel that allows devices to be re-configured.
Display
A data-flow dedicated to the purpose of data-visualization on screens/panels/leds/etc, although it could be argued that the need for this channel is not there if one would regard a display to be within the 'CONTROL' information stream.
Alert
A channel that provides DEBUG and ERROR information , as well as CRITICAL ALERTS that could be used to help build failsafes
Usability and Safety Considerations
System critical processes
No system-critical process should require a communication-channel to be present via wifi to not result in some kind of catastrophic failure.
This means, in practice, that anything that controls 'anything dangerous' (to itself or to the user/brewery/environment) should have sensible fail-safe defaults when communication drops away AND/OR provide an alternate, direct-wired control-loop to prevent damage/fire/etc. Good examples are heating-devices that'd keep on heating even when there's no reports coming in from any of the temp-sensors telling them what's going on. A good failsafe would be to turn off; close gas, etc, and report on ALERT
Robustness
Related to the consideration above, the system should also be robust enough to recover from outages of mqtt-broker or wifi. It should be able to detect and handle these kinds of issues gracefully and have some fall-back to resort to. This could be through a process of:
- Detecting an issue
- Mitigating the consequences
- Waiting for services to return
- Provide fallback after enough time has passed
- (optional): provide manual override for controls to continue brewing 'by hand'
Usability/configurability
It should be made easy to 'add' a new device to the brewery, even in an ad-hoc manner if/when the need arises. A sensor/actuator might be moved from/to different installations/breweries; or might just not contain any config at all yet. No device should require re-flashing before (re-)use. As such, a device should:
- Generate a UID upon first boot and make this persistent over reboots AND re-flashes
- Provide an AP-mode that supplies a method of configuring it's parameters in a captured-portal
- Provide this captured-portal upon first boot
- Provide a manual way to trigger this reconfigure/portal. 10sec button-press is suggested.
A library is available for arduino/esp8266 called 'WifiManager' that provides configging of wifi-related params. Extending this to mqtt-credentials might be useful.
Component life-cycle
General
- Read stored config
- Check UID, if none present, generate and store
- Check AP-settings; connect, fall back to providing wifi-config AP if not present
- Connect to AP, fallback if not connecting
- Connect to MQTT, fallback if not connecting (also into AP mode ?)
- (periodically ?) Announce presence on CONFIG/Inventory in format that provides Function + UID , PLUS information about currently set config
- Proceed to device-specific activity.
Temperature probe
- Perform measurement(s)
- Publish measurement-result on 'DATA/Type/UID' periodically (at least every 10 seconds)
- If measurements are impossible to perform OR impossible results are returned , fire an alert on ALERT/CRITICAL
- Listen to CONFIG for re-configuration-messages and incorporate requested changes.
AC-Switch
- Switch to 'default' safe state
- Subscribe to CONTROL/Type/UID and install handler that takes requested action based on config and payload
- Subscribe to DATA/Type/UID according to config for direct sensor->actuator control
- Listen to CONFIG/UID for reconfiguration-requests and incorporate requested changes.
- Subscribe to ALERT/CRITICAL
- Perform fail-safe activity upon lacking data + publish on ALERT/CRITICAL
PID unit
- Switch to 'default' safe state; performing no driving actions.
- Subscribe to CONTROL/Type/UID and install handler that takes request action based on config and payload
- Subscribe to CONFIG/UID for reconfiguration-requests and incorporate requested changes.
- Publish DATA/Type/UID data with measured temperature values
- Perform fail-safe activity upon lacking data + publish on ALERT/CRITICAL
DISPLAY
- Switch to function according to stored config state. This is deemed 'safe' for a display
- Subscribe to CONTROL/Type/UID and install handler that forms a template for data-display
- Subscribe to any DATA/Type/UID feed and incorporate data
- Subscribe to ALERT/CRITICAL: display any critical state when received
- Publish on ALERT/NOTICE when data is lacking. Progress to ALERT/CRITICAL is possible. Reflect state on display