The Roof Is on Fire?

Hi there. I hope you're enjoying the conference so far. My name is Teodor. I'm a web developer building Proxima, an open source analytics platform. During my free time though, I also enjoy building stuff and experimenting a lot with different technologies. And through my talks, I really like telling stories.

Our story begins in June 2021, when a wildfire burned down a huge area close to my house in Athens. Since 2021, wildfires have burned down three times the area of New York City. And that's just for Greece. Incidentally, and the main reason behind such a disaster is that we cannot truly understand how fires are working. Although they're a natural phenomenon and part of some ecosystems, they are getting more and more out of control due to human activity and the climate change. They can spread really quickly. And once they hit a critical point, they are almost unstoppable. Also, their sources are unpredictable, from cigarettes to thunderstorms and farm chores. So immediate response is crucial, and alerting and deploying aerial or ground units is the only way to avoid disaster.

A few months ago, I had an idea to build a device that would be able to monitor an area and alert the authorities if there is a fire starting. In order to do so, we need to set up some ground rules for the first prototype. So our device should be low cost because we need to cover huge areas and we need lots of them. It should also be as open and accessible as possible so we can let people build and deploy them in the wild. When it comes to prototyping an IoT device, the first essential component you'll need is a microcontroller, the brain and heart of our system. You might be familiar with the term and some popular options out there like the Raspberry Pi or Arduino. Our choice is the ESP32, a low-cost, low-power controller that offers both Bluetooth low energy and Wi-Fi capabilities out of the box. Developing on low-end hardware requires obviously writing code using the device's core fundamentals. We can write code in C or C++ using the Arduino IDE or use high-level languages like Python or Node.js.

There is a huge advantage because we can actually use the same code for targeting different devices or even platforms. We can run JavaScript, compile a code and run it on different devices, but there is actually more. Let's talk a little bit more about JavaScript. Using JavaScript for microcontrollers might sound a little bit tricky but totally worth it. By design it's event-driven and most of the IoT applications are event-based. The board itself is barebones but we can attach additional components so listening to button presses or sensor readings is actually event-based. JavaScript also has a huge registry of libraries that we can use to interact with the core APIs of the board or even mix and match technologies like pairing the board with a browser or mobile applications. And there are many great frameworks that make it even easier like Johnny-5, Scilor, Nesprino and so on.

Our choice though is DeviceScript, a really versatile framework developed by Microsoft. DeviceScript is a TypeScript-first framework that allows us to write code targeting different IoT development boards. It has great VS Code support and works along with Platform.IO, the go-to for embedded software development. It also supports simulation and debugging from VS Code to prototype and finally has lots of built-in APIs for sensors, additional components as well as communication protocols.

Now, if you have no experience with electronics, don't worry, we will cover just basics. So let me just show you what I have over here. So this is the hello world of hardware prototyping. It's a simple LED blinking on and off when a button is pressed. There is also a battery, a resistor and a few wires to connect them together. This is a prototype board that allows us to quickly put all the components together. And just to give you a perspective, this is also the development board. As you can see, it's extremely tiny. The board itself has a few pins on the right and the left that allows us to extend its functionality and attach additional components. It also has right here a USB connector to connect it to our development system and program directly and on the bottom it also has connections for battery and additional components as well. So we can take the hello world from the prototype board and move it to our development board. The code is fairly simple, just a few lines. The pins of the board are labeled with identifiers like T3 for the LED and T10 for the button. The labels have some sort of semantics, so D stands for Digital Input and Output pins. Using the start light bulb and start button core APIs from device script, we can initialize the components and subscribe to events like button presses. Once a button press is detected, we can turn the LED on. Although the previous example is a good start, it also shows us how more or less electronics work. The controller can only understand voltage changes as digital signals.

A physical event like pressing a button or turning a knob is translated into a voltage change that the controller can understand and act upon. Based on that principle, we can also add additional components. So in our device I have decided to move on with the AEST20 sensor. That's a temperature and humidity sensor developed by Idafruit Industries. The device script has a built-in driver for it so we can initialize it and read the values. We can also use the schedule API to read the values every five seconds and log on.

The sensor works by measuring changes in the humidity and temperature of the air. In the same principle, we can start detecting wildfires by attaching a gas sensor and a flame sensor. So over here, like this component over here, is the flame sensor. It's a really simple component that can detect if there is a flame nearby by reading the infrared changes using the infrared changes using this black bulb over here. The gas sensor over here is a bit more complex. It's a metal oxide semiconductor that can detect a variety of gases like CO2, methane, propane, hydrogen, and so on. So we can modify the previous example from the humidity sensor and start reading the sensor values and detect if there is a fire. The sensors are connected to the serial pins of the board and the checks are done every five seconds. If there is an open flame or gas detected, we can raise an alert and basically that's more or less the core functionality of our device.

Now if we want to extend our setup to cover a larger area, obviously, we can do that by adding more devices. But there is a problem struggle here. If we want to cover a bigger area, we want to have the devices spread out and also we need to establish a communication pattern between the devices. Each device can cover a small area, around 20 meter radius based on the sensor. These limits are due to the actual nature of the sensors. If we want to monitor a forest or a park, for example, we can spread the device a little bit more and let them communicate with each other as a cluster. So in order to have a network of devices, we can establish a mess network. Each device can send, receive, or broadcast messages. For that purpose, we're using a massive topology and a library called Painless Mess. It's a plug and play, ultra robust solution, but also it's self-healing. If one device goes down, the network will automatically adjust and find the new path for the messages. At the edges of the network, we can add gateways that can connect to the wider network and also relay messages to the cloud, other device mess networks, or external services. So if there is an alert, we can actually trigger an alert to the outer network using Wi-Fi, Bluetooth, or plain old SMS messages.

Now, let's see how we can take our device from prototype up to production. All the deployed devices are solar powered, running on batteries and can be deployed in remote areas.

There is a custom board designed to fit the sensors and the internals are packed in a 3D printed case. Our first cluster is already operating in Athens and tested on the field since March 2024. But we're not done, since we're building on top of such versatile technologies, we can extend our prototype in many kind of interesting ways.

Our clusters are mostly designed for off-grid emergency setups, so we can extend the range using LoRa. LoRa is a low power wide area network technology that can cover distances up to 30 kilometers. The devices can also work as emergency communication channels for firefighters or other units deployed in the field. And this is the great thing about using AlphaCell microcontrollers, we can extend our capabilities with these by attaching different modules, in our example a LoRa module. If you're interested in the details about this off-grid setup, you should definitely check out the MSTAT project, a community-driven project about radio signals and communication with really cheap devices.

Moving on, we also need to be along with the cool kids and kind of use some sort of AI, right? Well, I have some really good news for you. AI has been widely used in industrial applications for a while now. Most factories or industrial plants are using failure forecasting to predict when a machine or device will fail. We can apply the same principle to predict when one of our devices in our clusters will start failing and replace them before they become a problem. For that purpose, we are using the Prophet library from Meta. Essentially, that part is crucial. If we have deployed clusters, we need to do regular maintenance, and since all the devices are exposed to harsh weather conditions, that can be a real problem with defecting devices out in the wild. Also, we can use TinyML to run some inference on the device itself. TinyML is a way to deploy TensorFlow Lite models microcontrollers. We can extend the boards by adding cameras or other sensors as well. Based on the metrics, we can tune our sensor readings and predict how humidity and temperature will change, for example, in the future, or even adjust the readings to improve the accuracy of our metrics. But that's not the most interesting part at all. VALS is developing a sensor called BME 688 that has true gas detection capabilities. Using that sensor, we can more accurately predict and detect wildfires.

As you can see in the video, it can detect different gases or even smells. Essentially, smells are just gases in thin air. The sensor is exposed to open air, and based on the readings, we can create tiny models identifying the type of the gas. In their demo, in the video, they're using the sensor to recognize espresso coffee by the smell. So, besides providing an alert mechanism for wildfires, we can train our device and monitor the life cycle of the forest based on the decomposition gases. We can monitor that. We can actually monitor that leaves are decaying or that bees are moving around and pollinating. That step is kind of so amazing because initially, besides having an alert system, we can actually use the device for environmental monitoring in order to have better growth of forests or better recovery on a recently burned area.

And since we're talking about AI, here is the one million dollar question. Can we actually detect wildfires before they happen? Well, the answer is more or less yes and no. Although we have data in place like historical data, satellite images, and more, it's really hard to correlate them together. Wildfires are, as we said before, unpredictable and triggered by multiple factors that are hard to bring together. For example, we have to take in mind weather, the terrain, the changing humidity, along with the population base, the ventilation, traffic networks, and more.

But I think we're closely getting there because there are different teams. For example, there's the USC team from the university team from USC that they're working together to bring a model that it would be able to get fed with data and predict when an area is in high danger for a wildfire.

So if you have been following along, I hope you actually enjoyed the talk and picked up a few new insights. It's been quite a journey in the past few months exploring these concepts together, but the takeaway I'm about to share with you may be a bit different from what you expected. Beyond the technical details, there is something deeper that I hope resonates with you, an idea about what truly drives innovation and how we can each contribute to it in our own unique way. The main theme of this talk is not to brag about building something cool, but to show how technology can be used to solve real-world problems. When we bring together different perspectives, we push beyond the limits of what's known, creating solutions that are not only functional, but transformative as well.

So whether you are prototyping with a microcontroller, writing JavaScript for your daily job, developing software, designing the next breakthrough, remember that innovation thrives where ideas intersect, and you can actually embrace that process of going through all these new pieces of information, all these ideas, and getting strong back from the community. So next time someone's telling you that you cannot do this or that, they somehow might be absolutely wrong. We have moved along for so many years while building together, growing together, and learning from each other, and I think that's what makes us strong. The title for my talk is from a song that constantly asks, is the roof on fire? Is it on fire? And I think that once the roof is on fire, well sometimes it's better to let it burn. So guys, thanks a lot for your time and patience. I hope you have a great time with the conference. If you have any questions, you can find all the material from this talk as well, and the slides as well, on my website. So, until the next one, stay safe and keep building!