How to Detect Harmful Gases in Your Home with ThingSpeak

This project allows wireless monitoring of up to eight remotely located sensors using an HC-12 wireless transceiver and a simple protocol, which supports both outbound remote control and inbound status and data to be forwarded and displayed in a ThingSpeak platform. The project includes a remoted, Arduino-based, MQ-7 carbon monoxide (CO) sensor with a matching HC-12 transceiver. The idea is to provide a central D1 Mini, ESP8266-based monitor with local display and a ThingSpeak interface for detecting odorless propane, butane, and volatile liquids and fuels in facilities or even in your place of work or living.

Several MQ series gas sensors are available for Arduino that detect many more common gases including CO, propane and natural gas, and ammonia (the MQ-37). Each of these sensors is characterized by a heater element with or without a defined power cycle variation.

Click HERE to download the CO Sensor source code. 

Click HERE to download the ThinkSpeak source code.

BUILD INSTRUCTIONS

CO is odorless and colorless and can be sickening and deadly, even in small concentrations. Using the HC-12 transceiver, this application allows multiple sensors to be located over a wide area, under floors, near furnaces and water heaters, and in garages. In addition, one of the features of the ThingSpeak platform is that it can be used to generate tweets and text message alerts on configured ‘over trip’ conditions.

The Arduino-based remote hardware takes care of the heater cycling and includes a DHT22 temperature and humidity sensor both reported and available to be used for the CO sensor calibration. The remote controller also provides the received request link processing over a HC-12 serial link. The HC-12 can be configured to any of 100 channels and can operate at over 1000 feet.

Referring to the schematic to the right, I have used an inexpensive up-converter to support the sensor heater switching hardware. This may be optional, depending on the specific gas sensor used or desired accuracies. I included this because most heater control schemes either don’t address the voltage cycle or they drop too much voltage to meet the sensor heater specs and they are relatively inexpensive to include. The converter shown operates with 4.5 volts in, 7 volts out. Several other similar sensors only spec a single 5-volt power source, which may not require any converter.

I have used a pulse-width modulation (PWM) scheme to change the heater/sensors’ voltage. This allows the resulting sensor voltage to be adjusted dynamically to any value between the regulator's reference and the maximum available at the regulator's output, as a function of its input voltage and its required differential input/output spec. While I am using an LM317 regulator, which is pretty old school, several more contemporary parts are also available—defined as adjustable, three or more pin, with a reference of less than the required minimum sensor voltage. For the MQ-7 CO sensor, this is 1.4 volts.

Sensor alarm trip setting, heater characteristics, and an alarm disable function are also provided on the remote sensor controller (entering ‘?’ on the serial link).

The sensor ID strap, labeled ‘ID’ on the schematic, is used to qualify and identify the sensor through the base transmission control.

The HC-12 channel and the alarm trip are configurable from the D1 Mini base. And the raw CO product, heater and alarm configuration, sensor temperature, and humidity status information are returned on demand, over the link, to the base. All wireless communications are initiated by the D1 Mini, ESP8266-based controller.

That controller is coded to provide a scheduler and the WiFi uplink to the ThingSpeak platform. It uses a serial-based configuration to set up to six application-based parameters and receive up to four characteristics forwarded to the ThingSpeak. The HC-12-based link can be connected to any sensor or other remote applications supporting the link protocol. For the CO remote app described here, ThingSpeak related parameters allow the displayed charts to include temperature, humidity, and (raw) CO sensor values and trip setting.

The D1 Mini base also provides an extended display driver, allowing dual color LEDs to indicate operational statuses. There are fixed and flashing green and red indicators, corresponding to “active” and “in alarm” for each of the up to eight remoted sensors.

The common anode, dual red/grn LED displays are coded per the table and are set and returned, from the remote application, as part of the response in function(id) 8:

off when sensor is disabled (channel set to 0)
grn when an active sensor is operating normal
alternate red/grn when active sensor is in alarm mode
red when active sensor is non responsive
flash red when active sensor response(s) do not match

request id

At the base, entering a ‘?’ through the D1 Mini’s serial link returns a parameter list and allows ThingSpeak, network names and passwords, and schedule and sensor configurations to be modified. Each sensor also allows a unique HC-12 channel to be assigned, in addition to the unique 3-bit ID set at the sensor. Entering Channel 0 sets the associated sensor as “disabled.”

Tabled functions 1 through 5 use a request id and the text entry terminated with a ‘$’ (eg: 2,magicwand$ would be entered, setting the WiFi password to “magicwand”).

Four ThingSpeak-related WrtKey entries are supported in this list, allowing eight sensors to be forwarded to the ThingSpeak platform. The ThingSpeak site provides labeling and charting resources as well as a capable MathWorks based processing/display tool.

Tabled functions 6-8 use an ID and numeric(s) with a delimiter only, eg:

6,5 sets the schedule to 6 minutes. (3 minute min)

7,3,25 sets sensor 3 to channel 25

8,2,75,0 sets sensor 2 trip to 75 and heater cycle to ‘normal’. Remote sensor heater cycles are coded as:

Normal (0) 90 sec high 60 seconds low

Short Cycle (1) 90 sec high 50 seconds low

StatusOnly(2) returns 3 parameters

Off (3)

Function 9 displays up to six named variables. Each compatible remoted sensor or application defines the parameter list displayed on the D1 Mini base and provides the status and these values, which are also displayed at the base. The base allows this list to be modified and forwarded back to the remote app. For the CO sensor, these included a heater mode and an alarm trip. For the modified attic controller, this list included mode, fan overrides, and an attic temperature alarm trip setting. Schedule, channel, passwords, and keys are maintained in the base controller's EEPROM. For the provided CO app, trip and heater values—forwarded to the base—are returned and saved in the remoted app’s EPROM.

RELATED ARTICLES:

The D1 Mini base, coded to be a generic central scheduler, includes features that allow the base to remain generic and permit applications to be added and forwarded to the ThingSpeak platform with only a serial link and no code-based reprogramming. I would hope readers would exploit it for their own remoted applications. In development, I had converted my Alexa Based Attic/Greenhouse Remote application to use the ThingSpeak based controller described in this project. Several other previously published projects, such as the 4-Channel Data Logger or the Wireless Depth Detector project, could be modified relatively easily to enjoy the benefits of a remoted, wireless ThingSpeak Internet-based display platform.

For the CO app, remote humidity, temperature, raw sensor data, and alarm status (four variables) are returned from the app, on demand from the base, and forwarded to the ThingSpeak platform. For the converted attic control app, outside temperature, fan1 and fan2 state, and attic alarm trip temperature are forwarded to ThingSpeak.

For any questions or help with documentation, William Grill can be reached at: [email protected]

(Images source: William Grill)