Software apps and online services
Hand tools and fabrication machines
Nobody likes running out of toilet paper. For a main bathroom it may not be such an issue, although resupply is easily forgotten. However, for guest or rarely used bathrooms the TP shortage can easily go unnoticed until disaster.
The Roll Pole solves these potentially embarrassing TP shortages by combining an internet connected Photon with IFTTT to automatically add toilet paper to your Tesco.com shopping list.
The Roll Pole uses reflective Infrared sensors to detect the presence of a toilet roll through the clear acrylic tube that holds the PCBs.
It runs from battery and to save power, spends most of its time in deep sleep mode (60 minutes off, 5-10 seconds on). It wakes, measures the number of rolls and publishes the current state. If the number of rolls has changed, a message is published to indicate this and if the roll count is below the desired minimum, a warning message is also sent.
These special messages are picked up by IFTTT and used to trigger the Tesco.com channel to put toilet paper into your shopping basket. The low battery message could also be used to put batteries into your basket.
Battery voltage, IR sensor values and time taken to wake and sense the rolls is also published and captured by Tinamous.
I had hoped to include water sensing but not having fully read the manual I got the WKP pin logic wrong. Additionally, a temperature and humidity sensor is included; however this is unused so far and is a pain to solder.
The version presented here is very much a version 1 bit of fun and it is not without its issues. I hope you enjoy the project and can learn from it, but I certainly would not recommend building this version.
The design as it stands has issues with:
- Power usage
- Roll sensing
- Water sensing
- Ease of build
Yes, that is most of its functionality. Fortunately, even with flat batteries the Roll Pole still performs well at its primary task of toilet paper storage and if nothing else, provides an amusing talking point.
Roll Pole may also be used for kitchen roll dispensing, if you prefer your IoT craziness conversations to happen in the kitchen.
Yes, it's a battery powered WiFi internet connected Thing and risks the batteries needing to be replaced more often than the toilet rolls!
Power usage is the more interesting part of the project. I could have used a Bluz for BLE radio rather than WiFi (although mine arrived after the first build), or lower power radios (e.g. Zigbee & SmartThings); however for a development proof of concept project, the Photon is a great platform to build with and the ease of firmware deployment makes it great for this purpose.
Fortunately toilet paper usage tends to be very slow and not something you need to track in real-time. This allows us to place the Photon into deep sleep mode and only wake occasionally to check the roll count.
This version is powered from 4x AAA (1.2 - 1.5V batteries) which have a capacity of about 1000 mAh. The Photon offers a few power save modes. The largest saving is using deep sleep where current consumption drops to under 0.1 mA, and stop mode which runs about 1-2 mA.
Stop mode is the nicer option as all the variables are kept intact and the loop function continues where it left off. With the firmware in automatic cloud connection mode, the cloud connection is restored automatically on wake. Stop mode, also allows us to define the interrupt signal and pin to wake the processor. However at 1 mA in stop mode, this left the Roll Pole with a maximum run time of about 40 days, if it never used the WiFi, I'm sure nobody wants to replace the batteries more frequently than the toilet paper!
Deep sleep, however, offers a much better power saving mode. With the AAA batteries and just in standby, we may well see a good year's worth of operation. Swapping the AAA's for a 2,000 mAh LiPol battery might keep us going for a few years.
However, deep sleep isn't without its issues and the application needs to be written to handle this. Waking the processor is done either by a real time clock (you specify the number of seconds to sleep for) or by a rising edge on the WKP pin.
Sadly, the water sense module used a falling edge on the WKP pin, which not only means that water detection wouldn't wake the processor to allow the owner to be alerted, it also blocked the RTC from waking the CPU.
When in deep sleep, the processor no longer controls the IO pins either. These are left floating, therefore requiring a bodge resistor (no project is complete without at-least one bodge resistor) to pull the LED drive low, as this gradually crept high and started powering the IR LEDs. Each of these use 20 mA, so a drain of 60 mA was seen when in deep sleep, causing a bit of an issue.
When the photon resumes from deep sleep, all the variable values are lost, the
setup() method is called and then loop(). Fortunately, the Photon has some special battery backed retained variables. This feature needs to be enabled as it requires a little more power; however, by using it, we are able to store settings such as the current roll count and have them available when the processor wakes. I also used EEPROM for calibration values, but kept ram for values that need to be written frequently, rather than risk wearing out the storage.
The biggest challenge of using high power saving modes is having the Photon awake long enough to be able to update the firmware during development. Care needs to be taken to prevent the photon going into deep sleep before you can push new firmware. Fortunately, the Photons have a safe mode that allows you to recover easily if you do this. Particle appear to support queued/pull requested firmware updates for Photons that are assigned as a product but not for development builds (hopefully one day).
On power up, the Roll Pole enters a high power (cloud connected) mode which allows firmware to be flashed, calibration of the sensors and basic debugging to happen. Once this time is over (about 2 minutes or so), the Photon is set to go into deep sleep as soon as it has finished sensing the rolls and publishing the status. Other options could have included a switch or jumper or the sensing of the battery voltage to tell if it's above an expected level and hence running from a bench PSU.
Additional power saving could be made by only publishing when the roll count has actually changed; however, I felt it more useful to have regular updates from the Roll Pole, so I could tell that it was actually alive. I also want to have temperature (and possibly humidity) reported and an hourly update on these is useful.
The roll detection algorithm isn't very clever. It simply counts the rolls present, as well as the circuit having only a single LED drive which sees 60 mA of LED power consumed during the sensing and not 20 mA per roll. It could be further optimized by sensing the second roll first. If it is present, you know the bottom roll is there (or gravity has failed) so you only need to sense the top roll. If the second roll is absent, you need sense only the bottom roll and not the top, saving a 20 mA pulse. Fortunately, these pulses are very brief (milli-seconds every hour) so won't contribute greatly to power usage compared to sleep mode and the WiFi usage.
From the outset, I included a simple potential divider (R5+R6 as 2x 100k resistors on the top board) to measure battery voltage. These also contribute to power consumption (I = V/R -> 5V / 200k = 0.025mA that's about 25% of the power usage). This can be significant when optimizing for power usage. High value resistors can be used; these also need to be balanced with the input impedance of the ADC channel as this will affect the reading.
I have also included two time values in the measured data being published: "TConn" (Time to connect - how long the photon takes to power up and go through the setup() method) and "TTS" (Time to sleep - how long the entire process takes until the photon is put back to sleep mode). WiFi on and measuring the Roll Pole runs about 100+ mA, so the shorter the time taken to do this the better. The TConn and TTS measurements help assess this and if the Photon is having issues connecting. I could have used manual mode for cloud connection, but as I wanted to publish on every wake there seemed little point; however, without a timeout on cloud connect, a failed WiFi connection could easily kill the battery.
Infrared reflectance sensing - not just for Robots!
I used SMD QRE1113 sensors for this project; I probably could have spent an extra month and found some sensors even worse suited to this application, but QRE1113 is what I went with. After deciding to fit the batteries to the PCBs, I was left with no choice but to use the SMD version of the QRE1113 sensor. The leaded version would have been slightly better, as that could have been placed closer to the tube wall, but the battery holders got in the way of the leads through the PCB.
As it stands, worst case sensing distance is about 25 mm from sensor to roll tube; the QRE1113 is designed for about 1 mm. Amazingly, it works reasonably well; however the difference between roll present and absent is very small.
The chart below shows the ADC readings from the A2 sensor (bottom most roll). Here the intersection of the green and yellow bands is the threshold for roll sensing; in and above the yellow band no roll is present; in the green and below there is a roll present. The bands were determined by calibration and as you can see, it's easy to fall outside; above and below don't matter, but values around the middle can be tricky and lead to false sensing.
To help detection of rolls, the Roll Pole needs calibrating and this is done by calling the calibrate function in the Roll Pole firmware. Fortunately, the Particle cloud makes it ridiculously simple to expose functions via Particle.function() which can then be called via their API onto the Photon with only a few lines of code. Tinamous exposes these functions and allows them to be called either manually or as part of a notification. Here we simply enter 1 or 2 into the calibrate parameters and press Invoke and the Roll Pole calibrate function gets called. NB: This needs to be done when it's cloud connected and not sleeping.
This triggers a calibration on the Roll Pole. Cal 1 should be done with no rolls present to get a base line value (this is a high ADC reading as their is no current flowing through the IR photo transistor), then with the pole populated a Cal 2 is performed to get the level when IR light is reflected from the roll to the sensor, the reflected IR light lets current flow through the photo-transistor and reduces the voltage seen at the ADC. The trigger threshold for roll present/absent is set at the midpoint of these two values and stored in EEPROM so it survives power cycles.
An increase in LED drive current helps the dynamic range. The LED is rated for 50mA continuous and you can pulse LEDs at higher currents; however, in the interest of battery life and current consumption, I decided to leave the drive current at 20mA per LED - how well would AAA batteries stand up to 300mA pulses?
Other IR reflectance sensors are available with a longer range and you can expect to see them feature in V2 of the Roll Pole.
As the Roll Pole sits on the floor, it is an ideal candidate for sensing floods in the bathroom. The bottom PCB was designed to do that via a simple transistor switch that senses current flow. However ...
The end of PCB pad sensing design didn't really work as it needed to be a few mm off the floor for the base 3D print to work and hold it in place. A couple of wires would have done the job much better.
The signal needed to be active high to trigger the WKP interrupt on the photon; it was active low. It also caused the RTC's interrupt not to trigger the photon wake. Hence the options are either stop mode with a 20 day battery life or no flood sensing in this version.
I also planned on fitting a buzzer but, like the batteries, it didn't fit the tube.
The eagle-eyed of you may well notice that the PCB has pads for AA battery holders, and by looking at the dev board, you can see I've actually fitted them; however, it turns out they are ever so slightly too big to fit into the acrylic tube. Therefore, for the real version, I needed to short the connections out and fit the battery pack into the base of the Roll Pole. This actually works better as it's easier to replace the batteries and Roll Pole V2 is likely to see a LiPol battery used here rather than AAAs.
Pro Tip: Always build n+1 versions, as once you've deployed your prototype(s) to be used you will not want to be fiddling with them. It's very handy to have a spare to try things out on and update the firmware before you do it to the real one.
I decided to make the Roll Pole from three different PCBs, the main ones being the height of a roll (well, 3 mm short at 100 mm to save a small fortune on PCB fab). This design means that 0-3 middle boards can be fitted giving a 1-4 roll capacity pole. Each board has a sensor select to set which sensor (analog input) pin to use. This works really well for an expandable system, but it means that pin connections are limited between boards (12 connections with the style used) and it's also difficult to connect the boards easily. However, for a prototype version it has worked well. Version 2 will be a single board so that each LED can be driven individually; I2C can be routed to the lower part of the board for possible battery monitoring.
I put the photon aerial facing up as I needed to run tracks under the Photon and didn't want to violate the keep out zone; however, this means that a USB plug may get in the way of the top sensor and it is difficult to get to in the tube. As I've not used the USB connection, it's not been an issue - OTA firmware updates save the day!
The thing I love most about the Photons (and Electrons) is not having to think about how the device will connect to the internet. For this project, the only thoughts are around power consumption, not which protocol, or how to implement the security, or all the other concerns.
I've used the name "
status" to publish status messages; these then appear on the Tinamous timeline view of my devices and the name "
senml" with a SenML formatted message body. Again, this is picked up by Tinamous and turned into measurement values that can then be plotted.
Whilst Particle.variable()'s are nice and easy to use, they need the Photon to be cloud connected and are (as far as I can tell) queried from the cloud when requested via the API rather than pushed. This works well for many situations, particularly with fast changing values that don't need real-time updates to the internet; however, without keeping the Photon connected and draining the battery in less than a day, this would not work for the Roll Pole.
I also wrapped the publishing functionality in their own methods to allow any delays to be added or flags to be set if messages needed to be published, so the Photon could allow a little time for that to happen before deep sleeping.
Overall, the Roll Pole has performed well. I see occasional triggering issues down to the sensitivity and calibration of the IR sensors and battery life is untested outside of high power (max 1 day) tests, however, I think this definitely deserves a second version.
Success - Toilet paper magically added to my shopping basket!