Sensing Dryer Lint: Improving Apartment Complex Building Safety Through IoT

Project: Sensing Dryer Lint: Improving Apartment Complex Building Safety Through IoT

Elevator Pitch (synopsis): Apartment complex safety needs IoT-enabled buildings- I built an IoT device to monitor dryer lint buildup so that apartment managers can ensure the safety of their complexes’ buildings along yet another safety axis.

I produced a YouTube video explanation of the project that leans on this write-up for pictures.

Edit media

Dimensions x Small Medium Large Custom

Subject (required) Brief Description Tags (separated by comma) Video visibility in search results Visible Hidden

Parent content

Sensing Dryer Lint: Improving Apartment Complex Building Safety Through IoT

Poster

Upload Preview

Ok

Cancel

Here is a short video of the deployed sensor by my dryer exhaust.

Edit media

Dimensions x Small Medium Large Custom

Subject (required) Brief Description Tags (separated by comma) Video visibility in search results Visible Hidden

Parent content

Sensing Dryer Lint: Improving Apartment Complex Building Safety Through IoT

Poster

Upload Preview

Ok

Cancel

Here is a picture of the completed system outside its case, showing the custom mikroBUS board and remote sensor I developed for this contest:

I realized that a good many of the easily-internetted things are already connected.  I also realized I had ideas for connected sensors but few devices or situations that needed to be connected. I had to go a little deeper to uncover the thing and the deployment breadth.

I looked to Maslow’s hierarchy of needs.  I got a clue from the name of the Hackster.io sister contest, Secure Everything with Azure Sphere.  I think security in that context means computer security.  I took it, for this contest, to mean a person’s physical security or safety.

The device I chose will definitely improve the physical safety of its users: I built a device to telemeter apartment complex dryer lint buildup. 

A summary of this US government-issued document on dryer fires shows that lint is dangerous: there are many fires, they can be fatal, and the property loss is great enough that this sensor makes safety and financial sense.

One deployed device per user is merely a connected sensor.  Connected sensors belong on house alarms or integrated with home smart devices.  I decided that there are deployment situations where one would need several dryer monitors:  a landlord or an apartment complex has more than one facility with dryers. I later added insurance companies as customers, which could give a landlord/homeowner/renter a discount for deploying a dryer monitor and for reporting the status to a central monitoring station/console. The latter idea might fall flat due to individual information security needs or government laws, but I retain it here as a “design thinking” result.

Sensing lint is an interesting task.  My first approach wasn’t the best. I tried several ways:

1. I thought of sensing wind speed from the dryer hose:
   1. I soon discounted this idea because it is possible that wind speed could change when there is a new dryer, or a new tenant. 
   2. I could “learn” the dryer wind speed and sense a gradual decline in wind speed as an indicator of lint buildup.  This indirect method could really only tell me that the wind speed changed. Again, a dryer change could result in invalidation of previous data and probably no operator would go to the app to clean it out. (Who watches these watchmen?)
   3. Wind speed is out!

1. I thought of sensing heat and humidity:
   1. A warm exhaust is in the process of building up lint, yes-
   2. But this doesn’t detect the lint has built up- just that lint could be stuck to the hose.
   3. Heat and humidity are out!
2. I then decided to sense lint buildup:
   1. Lint buildup is uniform across the inside of the dryer hose, too.
   2. And thus I could sense lint build up with an obscured transmissive photo interrupter!
      1. When the receiver senses no light, the lint has built up between the LED and its sensor.
      2. This method directly senses lint.
      3. I could build a simple circuit with an LED to indicate when lint has built up. 
         1. IR LED to IR Phototransistor over air driving an LED
         2. 
   3. I could place the Transmissive Photo Interrupter Sensor in the dryer hose where it can gather the most lint.

Integration of the IR Circuit and the Azure Sphere Starter Kit

1. Hardware
   1. The MikroE Opto Encoder Click module supports one opto encoder.  Perfect.
   2. However, this Click module must go inside the dryer hose. That means you have to put the module, and the Azure Sphere Starter Kit in the dryer hose. This won’t cut it.
   3. 
   4. There are hundreds of Click mikroBUS boards out there, but none that suited my needs directly: I needed a simple LED and sensor board.  I couldn't find one that had a remote sensor wiring point.
   5. I built my own mikroBUS board and deployable IR sensor board. Notes:
      1. The mikroBUS standard is easy to use.
      2. Click modules names are trademarked so I did not build a Click module, I built a mikroBUS-compatible module. Also, I fought with Fritzing for a while to get the mikroBUS logo on the board, but I had to give up. I'll figure this out in future iterations.
      3. I built two boards for this project:
      4. mikroBUS interface module
      5. 
      6. Remote sensor module
      7. 
2. One deployment model is for inside the apartment:

   1. I made a cylindrical section of aluminum sheet configured such that a dryer hose could slide over it.  This forms a dryer hose “interstage” so that the sensors could be placed inside it. This would let me secure the Transmissive Photo Interrupter Sensors and further ensure I could sense what I wanted.

   2. The interstage should be connected between the dryer and the dryer hose.

   3. 

3. Another deployment model is for outside the apartment, and is shown installed here by my own house.
   1. A weatherproof case is attached outside the wall and where it can get power.  The US National Electric Code requires this appliance to have a separate circuit because it is permanently installed.   Apartment complexes have multiple dryer exhaust vents together, so one device can monitor several dryer hoses for lint.
   2. The deployable sensor is shoved right into the hose outlet.  It will collect lint inside there and eventually, the sensor will telemeter the fact that the hose requires cleaning.

Software

I’ve been a .NET programmer for a number of years and so Visual Studio 2019 was an easy play for me.  Brian Willess’s tutorials are fantastic. I ran all three of them and thus had my Azsphere board claimed and feeding to a simple Azure IoT Central console application. I borrowed Brian’s code via Github (MIT License) and forked it for my own purposes. All my code and changes are on that Github repo.

Changes

I rewrote the part of Brian’s code that builds the telemetry message out of the I2C data ReportTelemetry().  For giggles, I added the temperature data from the lps22hh and lsm6dso chips. That showed me that I understand how the system works. For the dryer monitor lint telemetry, I needed the I2C data and the information from the custom mikroBUS module I made-- which is not I2C. I added the code for my modules in a new function sense_lint(), and integrated the I2C messages and the analog messages into the telemetry message to Azure IoT Central.

lint_telemetry sense_lint() {

   lint_telemetry report;

   // flip the LED state

   ledState = (ledState == GPIO_Value_Low ? GPIO_Value_High : GPIO_Value_Low);

   int result = GPIO_SetValue(lintInfraredLedGpioFd, ledState);

   if (result != 0) {

      Log_Debug("ERROR: Could not set LED output value: %s (%d).\n", strerror(errno), errno);

      terminationRequired = true;

   }

   report.input = GPIO_Value_Low;

   // if we turned on the LED, sense the LED

  if (ledState == GPIO_Value_High) {

      if (GPIO_GetValue(lintInfraredSensorGpioFd, &report.input) != 0) {

         Log_Debug("ERROR: Could not read LED output value: %s (%d).\n", strerror(errno), errno);

         terminationRequired = true;

         report.input = GPIO_Value_Low;

   }

   else {

      // the connection to the circuit board is inverted, so flip the value

      report.input = report.input == GPIO_Value_High ? GPIO_Value_Low : GPIO_Value_High;

      lastSensorState = report.input;

      Log_Debug("Perfect! Sensed input is: %d.\n", report.input);

   }

}

   else { // didn't read the input, return what we knew last time

   report.input = lastSensorState;

   }

return report;

}

For the integration, I moved the code around that handles the initialization of the I2C components and starts a timer for device polling and telemetry reporting. Since the dryer monitor sends more telemetry than the accelerometers, I renamed the polling function to DeviceEventHandler() and moved the system and polling initialization to a function, setupDeviceAndStartPolling(), that initializes all components instead of just the I2C components.  You can add your own initialization components there like I did.

I created an Azure IoT Central application that receives and displays the dryer monitor lint telemetry. As part of the application, I created an alarm for when either or both lint sensor types declare there is lint. The below screenshot shows the activity going from "dirty" to "clean" because the lint_ok message changes from 0 to 1.   Apartment managers would see this when their cleaning crews perform their activities.

I wrote and updated an Azure Function to receive and log the dryer monitor lint rule result payload.

This Azure function allows easy expansion of the application outside of the pure Azure IoT Central capabilities.

I can now at least save my own life and property from lint buildup. (I built a connected sensor!)  Coincidentally, I recently replaced my dryer’s drum motor. There was a lot of lint in the dryer and the hose. Don’t think that your dryer is immune to lint-- all dryers collect lint inside them <photos> and thus they are all combustible.

Bill of Materials for Development Unit

1. Azure Sphere MT3620 Starter Kit
2. My own mikroBUS module
3. Sensor board
4. Screws and connecting wires
5. Taymac Pro-Grade Weatherproof Case MM2420G
6. A 5V 2.1A wall wart power supply that I had nearby or a battery
7. A dryer vent with aluminum connecting cylinder/pipe to use to create a cylindrical housing for the interstage sensor housing <photos of the build>
8. A dryer hose and clamps to allow the interstage to connect in between the dryer and the facility vent
9. My version of the IoT software
10. An Azure IoT Central Application, configured with my devices <screenshots>

Bill of Materials for Production Unit

1. MT3620 Module
2. My own mikroBUS module
3. Sensor board
4. Screws and connecting wires
5. Taymac Pro-Grade Weatherproof Case MM2420G
6. A 5V 2.1A wall wart power supply that I had nearby
7. A dryer vent with aluminum connecting cylinder/pipe to use to create a cylindrical housing for the interstage sensor housing <photos of the build>

Schematics

Interface Board Schematic:

Sensor Board Schematic:

A bit of philosophy for IoT

I had to think for a few days about the philosophy of IoT:

• The “thing” to be “internetted” has to be worth more after it has been internetted.
• The information you obtain from your thing has to add value to the thing, or your operations, or your life.
• Toy IoT devices- those that don’t deliver extra value- reduce the apparent value of the entire IoT field. Many eyes will roll and consumers will quit buying IoT products.
• The thing has to be more valuable than the cost of internetting it. 
• Key point: an IoT device deployed for one person or one thing is merely a connected sensor. You might do well by connecting the sensor to the house alarm. Implication: one portal operator should have many instances of the internetted thing.
• IoT Sensors can be direct or indirect.  Direct sensors are better than indirect sensors.
• Sometimes you can use an off-the-shelf sensor in a creative way to achieve a good result.  Sometimes you cannot.

Improvements

• Housing for the sensor module: it doesn't need a housing. It can function as a bare board. However, for durability purposes, I could 3D print one
• Deployed in an apartment complex, this device could be placed centrally to multiple exhausts that might be plumbed together.  Thus, the device could telemeter multiple units' lint status from one deployment

Lessons Learned

• You can't depend on a manufacturing estimate of 1 week. It took three weeks for my boards to be made.
• I bought three external sensors before I custom-designed my own
• An IR circuit acts invisibly.
• Microsoft's Azure IoT tools are still in beta and are not completely mature.  They updated several times during this project. I am sure my code will have to be updated 10 times before it actually goes to production.

New Skills Gained

• Fritzing: I'd never used this tool though I'd seen it for years. I ran into minor difficulties that I will overcome in the future. I made new components, built the schematic for my boards, and had the board fabbed straight through Fritzing.
• Integration with Azure IoT capabilities
• Integration with mikroBUS
• Ability to discuss IoT with strategists