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

Alert

A channel that provides DEBUG and ERROR information , as well as CRITICAL ALERTS that could be used to help build failsafes

Considerations

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