Hardware components | ||||||
 |
| × | 1 | |||
| × | 1 | ||||
Software apps and online services | ||||||
| ||||||
Introduction
My wife is always concerned that when we leave the house we may have left one of our garage doors open. So this app was created on a Particle Photon ($19) to monitor the garage doors using reed switches, and to report if any door is left open more than 5 minutes (or whatever value you fix into the program). It sends a text message / SMS to multiple smartphones to alert the open status of any of the garage doors and sends reminders every 15 minutes that at least one door is still open. If the door stay open for less than 5 minutes there is no alert.
A reed switch is connected to each of the garage doors. These are the same type of switches that are used by alarm companies to attach to a window to determine if it is open or closed. One switch is connected to each door. A magnet fixed to the garage door keeps the reed switch closed when the garage door is closed. This closed circuit sends 3.3 volts through the switch and causes a HIGH on input lines on the Photon. A LOW indicates the door is open.
The Blue LED of the Photon shows the status of the doors. A slow 2 seconds on and 2 seconds off is when all doors are closed and being monitored. A 1 second on and 1 second off indicates a door has been open but an alert has not been sent. If the door remains open more than 5 minutes, the LED will blink 4 times per second to indicate that an alert has been sent.
The form of the message that is sent is:
Lft- OPEN Mid-CLOSED Rgt-OPEN on Wed Sep 9, 16:21:38
Summary
This application uses a combination of the ability of the WiFi connected Photon to send an 'event' (which in this case is a "message" we would like to display) up to the Particle Cloud where we have programmed IFTTT.com to wake up whenever a new event arrives. IFTTT sends a the message to a Google Gmail account that is set up to forward a copy of the message to the Email address associated with multiple Smartphones. Most wireless carriers provide an Email address to send a text message / SMS to a Smartphone. In this case, we used smartphone_telephone_number@txt.att.net as the forwarding address in the special Gmail account set up, to send to multiple phones. We refer to this address as the "smartphone text Email address".
IFTTT does have the ability to send a text message, but limits users to a specific number of them per month. So we did not wish to use their service. So the messages were sent to a Google account instead. The Google account is set up to forward any messages sent to that Gmail address, to the smartphone text Email address then delete the message from Gmail. But Gmail normally only allows a single forwarding address. In order to have that Gmail address sent to multiple smartphones, a Gmail backdoor is used to program this. Instead of setting up the account for forwarding, filters are set up instead. The Gmail filter is set up to allow all messages to pass through the filters and as part of each filter, one can insert a Forwarding Email address. So using filters, the single Gmail account now acts like a group Emailer, by sending a copy of the message to the smartphone addresses inserted into each filter.
Details
The application maintains the current time through the use of the millis() clock of the Photon. But to insure there is no drift in the internal clock time, it periodically reads the current time of day from the Particle Cloud.
There is a Debug mode built into the app. If a computer is connected through the USB port, it can monitor the flow of the app through debug messages that are displayed, While in debug mode (set via a #define), the user can set debugTimers to 1 if they wish the internal timers for how long a garage door can remain open, how often reminders are sent and how often the time of day clock is read, to be small values so operations happen more quickly than the normal operating parameters of the application. When in debug mode, a time stamp is written to the console every 10 seconds to show that the app is still running and to allow one to easily see how much time occurs between various events. One can manually open and close reed switches during debug and see the various status messages. The debug code is supported by a separate debug.h and debug.cpp file with the code supporting it. Again, since it was originally from the Arduino, it had special code to grab messages out of flash memory instead of RAM, but this is taken care of automatically in the Photon. This code, as written for the Arduino, operates properly on the Photon.
The function called readSwitch() has debounce logic built in as any switch, especially a reed switch, has a tendency to bounce (open and close a few times in rapid succession) as it is opening an closing. That function insures the setting of the switch is stable before calling a switch open or closed.
The formatDoorStatusAndConditionallySend() function, includes a time stamp on the message created. That stamp depends on the time of day clock being read properly at least once. Until the correct time of day is read, it time stamps using the running time of the app. In the Arduino version we were reading the clock off the web which took some time. In this version this should run quickly.
There are 13 different steps in the processing loop for this app. If after a modification something seems to be causing the app to crash, the #define debug_step can be set to 1. In this case, the step number about to be executed is displayed making it easy to see how far the app progressed before failing.
Currently, in the setup(), the time zone is set to USA Eastern Time (-4).
This app was used in different locations. One in the lab were it was created and debugged and the other at the garage. Two different WiFi access points where used due to the difference in location. The app was programmed to set the WiFi credentials into the Photon so either network could be used. But a problem in the Photon at the time of development, did not allow one to write credentials for an Access Point that was unreachable at that point in time. So this code was commented out. Instead, the Photon was set up using the Particle set up procedure at one location, then moved to the other where the second WiFi network was located. So both networks remained programmed in its memory. During startup, the Photon will display which network it is connected to, its IP address and that of its gateway.
Processing steps of the application
The processing steps are as follows. Most steps display a debug message if something important happened.
0 - Process loop starting. Read switches. One time initialization. Read time of day clock.
1 - Start 5 minute timer if any door just opened.
2 - Stop clock if a door closed before a timeout.
3 - Check if a door open too long if not already alerted to an open door
4 - Send alert if necessary and one not already sent. Comments refer to sending a Tweet which is how the Arduino version worked. But the Photon version publishes an event and using IFTTT to monitor events, is much more flexible than just sending a tweet. In fact we don't send a tweet in this version, we just send an SMS. But using IFTTT one can do all sorts of things.
5 - If in alert state and all doors close, send a message to indicate everything is OK again.
6 - If in alert state for 15 minutes, send a reminder that at least one door is still open. Send the status of each door.
7 - Update the time of day every hour to insure our internal clock does not drift from real time.
8 - Update the internal time of day based on how much time has passed since the last time the processing loop executed.
9 - Blink the Blue LED at a rate based on the alert state. The on/off cycle of the LED transcends multiple processing loops. Timers are set to insure the LED blinks at the correct rate.
10 - Check if any door is open or if all doors are closed.
11 - In debug mode print a time stamp every 10 seconds. Also display how many processing loops have been executed and how many milliseconds had passed since the app was started or since the last wrap around of the clock (49+ days).
12 - Delay for 10 milliseconds before returning to step 0.
13 - Show that we are about to return to the Particle firmware for it to do its processing (such as keeping a connection to the Particle cloud alive) before it returns control to the app at step 0.
Photon Clock Wrap Around Considerations
The app flashed onto the Photon is designed with the expectation that it will operate 24 x 7 x 365. The important part of this is to keep in mind that the millisecond clock used to track time on the Photon, will wrap around every 49 days, 17 hours, 2 minutes and 47.295 seconds. So a simple test of timeout normally of the form:
while ( millis() - timeoutTime ) < 0 {};
will timeout immediate or loop forever (depending upon the way this type of check is coded) when the timeout has a small value and the current timer has a large value, which occurs just around the clock wrap around time. So the code takes care of insuring it operates at the wrap around time. The set_next_timeout() function keeps the wrap around condition in mind while the check_for_timeout() function properly checks for timeouts considering the clock might be wrapping around.
The use of the set_next_timeout() and check_for_timeout() functions only require that a single unsigned long be stored to represent the timeout time. There is an alternate way of insuring that clock wrap around is taken care of. The timer can be changed to consist of a struct with two elements, the time the timer started, and the time interval that one needs to wait before the timer is considered to have timed out. If we save this struct as the timer, then the check)_for_timeout() test becomes:
if (struct_data.start_time - millis()) < struct_data.interval) return TRUE;
else return FALSE;
This will wait the proper interval of time since unsigned arithmetic will properly take care of the clock wrap around.
Comments