Developing a LoRaWAN smoke alarm

Julian Tait

Initiator for Manchester, UK

Posted on 07-12-2016

Since developing the Things Network as Things Manchester in 2015 we have been talking to anyone and everyone who we think could benefit from the creation of an open, crowdsourced Internet of Things network. This has ranged from local government and businesses to voluntary organisations and community groups. Greater Manchester Fire and Rescue Service (GMFRS) saw the potential of developing a region-wide network that could help them experiment with new ideas and services.

Trying to get people to understand the opportunities of the network means identifying and developing use cases is essential. Through conversations with GMFRS we expanded the network so that it covered a large proportion of Salford in Greater Manchester to create an IoT testbed where different devices and sensors could be tested. This was done by installing three Gateways onto redundant fire towers. The advantage of these towers is that they tend to be taller than surrounding buildings and well distributed, allowing good network coverage.

The attraction of the Things Network is that it allows the development, deployment and testing of different devices at low cost. Two areas of interest were flood sensors (we have been getting a lot of flooding recently) and smoke alarms.

There are many challenges that exist with smoke alarms in their current form and most of these are based around human behaviour. GMFRS distributes smoke alarms to people so that they can install them into their homes. These may or may not be optimally placed, also when the battery runs out, alarms are often discarded rather than the battery being replaced. There are also challenges associated with houses that have been converted into flats and bedsits called homes of multiple occupancy - where not all residents have a smoke alarm. It was desirable that the alarm would also give an indication of the temperature when the alarm was triggered.

This identified problems allowed us to create a specification for the alarm.
The alarm had to be inexpensive to mass produce (£15-£20 per unit)
The alarm had to allow the current temperature to be detected
The alarm had to periodically test the level of the battery
It had to be low maintenance and self contained
The alarm needed to work over a long range 1-2km

To see if a mass produced alarm would be inexpensive we looked at component costs. There are a number inexpensive smoke alarm chips available that have the functionality we needed. Commonly smoke is detected in two ways through an ionisation chamber or by using an infrared emitter/receiver. The LoRaWAN functionality was provided by a Microchip RN2483 although a mass produced alarm would use Semtech chips with an inexpensive MCU. The temperature sensor would be an integrated circuit that could be directly mounted to the PCB.

The proof of concept device was configured so that it would send a status packet every six hours. Data contained in the packet would be battery level and temperature. Metadata would also be used to detect the quality of signal and whether packets were being lost. When the alarm was triggered, packets would be sent every 40 seconds and these would include the alarm status, temperature and battery level.

A simple user interface was also created using NodeRed that showed the location on a Google Map, installation details and a temperature graph. The addition of the graph allows temperature to be monitored over time and shows the temperature profile of the alarm event potentially indicating the severity of the fire.

Testing was done at a local fire station with the device working as expected. Further tests were done regarding range which appeared to be within the range specified.

As a proof of concept the device was a success but there would need to be a lot more work to make a viable prototype. The form factor and the materials used in the device would need to be changed and the circuitry needs to be redesigned so everything sits on one circuit board. The interface has the potential to

A challenge with any device that offers a ‘safety of life’ function is the certification of the device. It is uncertain if LoRaWAN is robust enough to offer a ‘safety of life’ service, but what it does do is provide what could be valuable information if a smoke alarm is triggered. A spin-off of using temperature detecting smoke alarms is the potential to help vulnerable people who might be experiencing fuel poverty. There are number of ethical and consent challenges around such devices in people’s homes but potentially the development of one kind of service will open the doors for others.

You are the network. Let's build this thing together.