[Upcycle It] WiFi Connected Smoke Detector #10: Addressing False Positives

Nobody likes false positives

I don't like them too, especially where I have control and can address them. I had two cases in the past 10 days when my connected smoke detector generated false positives. So I decided to address them.

Options: Neural networks vs. traditional approach

I was doing some machine learning courses in the past and have some ideas how to apply neural networks (NN) for sound detection. NN is the most popular way to recognize voice. But with all advantages of NN it is still considered a "black box" approach.

Alternatively I've collected statistics from the detector logs by using system journal.

journalctl -b|grep node|grep above >/tmp/logs.csv

Then I looked in the log at times when alarm was raised (value of the counter above 50).

May 18 18:09:31 gate1 node[306]: Above threshold 489 counter 10
May 18 18:09:31 gate1 node[306]: Above threshold 497 counter 18
May 18 18:09:31 gate1 node[306]: Above threshold 492 counter 26
May 18 18:09:32 gate1 node[306]: Above threshold 488 counter 36
May 18 18:09:32 gate1 node[306]: Above threshold 487 counter 44
May 18 18:09:32 gate1 node[306]: Above threshold 488 counter 52

May 20 22:56:20 gate1 node[306]: Above treashold 478 counter 10
May 20 22:56:21 gate1 node[306]: Above treashold 485 counter 17
May 20 22:56:21 gate1 node[306]: Above treashold 493 counter 23
May 20 22:56:21 gate1 node[306]: Above treashold 485 counter 32
May 20 22:56:23 gate1 node[306]: Above treashold 486 counter 28
May 20 22:56:23 gate1 node[306]: Above treashold 492 counter 37
May 20 22:56:23 gate1 node[306]: Above treashold 489 counter 46
May 20 22:56:24 gate1 node[306]: Above treashold 492 counter 53

The log file only contains entries when the microphone captures a loud signal above predefined threshold, which is now defined as 470. The signal gets measured every 100 ms. If the signal above 470 the counter get increased by 10. If it is below 470, it gets decreased by 1 while its value is above 0. And when the counter is above 50 it is raising alarm, Here is the code of my audio processing function in Node.js:

function processAudio(){
  // read the value to start off
  var level = audio.read();

  // If the sound is higher than the threshold, make the request
  if(level >= threshold){
    audioCounter=audioCounter+10;
    console.log('Above threshold ' + level + ' counter ' + audioCounter);
    if(audioCounter>50){
        state = true;
        setTimeout(processAudio, 60*1000); //wait 60 seconds before activating it again
        client.publish(kitchen_alarm_state_topic, 'true', {qos: 2, retain: true}, function() {
            console.log('Audio alarm detected ' + level + ' counter ' + audioCounter);
        });
        audioCounter=0; //reset counter
    }
    else {
        setTimeout(processAudio, 100);
    }
  } else {
    if(audioCounter>0){
        audioCounter--;
    }else if(state){
        state = false; //switch off alarm
        client.publish(kitchen_alarm_state_topic, 'false', {qos: 2, retain: true}, function() {
            console.log('Audio alarm switched off ' + level + ' counter ' + audioCounter);
        });
    }
    setTimeout(processAudio, 100);
    //console.log(level + ' counter ' + audioCounter);
  }
}

In both cases of false positives value of the counter was 52 and 53. So I've changed the threshold to be just above these values and set it to 53 instead of 50 (line 9).

I've pushed the code, restarted the detector service and verified its status after restart.

root@gate1:~# sudo systemctl restart smoke-detector
root@gate1:~# sudo systemctl status smoke-detector
● smoke-detector.service - SmokeDetectorApp
   Loaded: loaded (/lib/systemd/system/smoke-detector.service; enabled)
   Active: active (running) since Sun 2017-05-28 22:06:03 EDT; 9s ago
 Main PID: 5603 (node)
   CGroup: /system.slice/smoke-detector.service
           └─5603 /usr/bin/node /home/root/detector.js

May 28 22:06:03 gate1 systemd[1]: Started SmokeDetectorApp.
May 28 22:06:06 gate1 node[5603]: /home/root/node_modules/mraa/build/Release/mraa.node
May 28 22:06:06 gate1 libmraa[5603]: libmraa version v1.6.1 initialised by user 'root' with EUID 0
May 28 22:06:06 gate1 libmraa[5603]: edison: Arduino board detected
May 28 22:06:06 gate1 libmraa[5603]: libmraa initialised for platform 'Intel Edison' of type 2
May 28 22:06:06 gate1 node[5603]: MRAA Version: v1.6.1
May 28 22:06:06 gate1 node[5603]: Kitchen alarms detector connected

I'll keep looking to see if false positive will reappear again. But in this case it seems the simple approach of adjusting thresholds based on statistical data is good enough.