Are You Okay? Widget
What The Software Does (Agent)
The goal of the agent software is to send user messages if the device fails in some way. For debugging, it is often easier to get messages when something does happen. Thus, there are two output message methodologies.
When debugging, you don’t necessarily want to flood your debug mechanism. If you keep tapping on the unit because you are fine tuning the color of the LED, you don’t want to get 1000 emails or twitter messages.
These next settings control how often you get messages and prevent message flurries:
The next setting is the most important.
These should be set according to how often your device needs attention before it sends you email. If you set it to be too frequent, the person you are monitoring will find it intrusive. If you set it too long, you may not be able to alleviate your worry. Here are some settings I like:
|User needs to move it||Hours||dtNoMotionDetected Setting|
|Three times a day||12||43200|
|Every couple days||60||216000|
With the most frequent setting, remember the user needs to sleep so 12 hours represents a couple hours on either side of night’s rest. As for “every day”, it isn’t 24 hours because that would require the user to interact with the device every day at the same time (or a minute earlier). Using 36 hours instead means that one day can be 8am but the next can be 8pm. The “every couple days” has a similar buffer.
The next setting configures how long the device can fail to communicate before you get an error message. This is likely because the device has lost power or its WiFi is not available.
Peace of mind sometimes means knowing that everything is still working. I updated my system to send a note every few days to say everything is ok.
Actually, everything may be working fine but you should know the device’s batteries are getting low. To that end, we have to decide when the “everything is fine” messages should include “but my battery is getting low”:
Communicating With the Caregiver
The different ways to communicate with the device require permissions. Electric Imp has example code for a number of web services: Xively, Twillio, Twitter, etc. I used the agent code from their repository. For twitter, you’ll need to use the Twitter Developer Center. Then you’ll need the keys to work:
These are at the top of my
agent.nut but the code is a little further down (marked with a section break). It’s relevant function is
Note: if you have trouble with twitter, modify the
twitterDebug function to output messages to the Electric Imp
server.log. Those messages get tedious to look at but are nice when starting out.
Monitoring Multiple Devices
Once you have one of these devices, you may want another. Right after the Settings sections, there is an area to help with monitoring multiple devices:
If you only want one unit, and you want to skip the next steps, edit the code directly and fix the name of the unit and where to send caregiver messages.
The other way to set these server-stored variables is to set up your unit the first time by putting the information in a URL of the form:
If you look at the top of the Imp editor for you agent URL, you'll see something like:
Copy the URL from the editor and add the necessary information in place of the curly braces, so it looks like:
Maxwell is the name of the unit and
@logicalelegance is where I want messages to be sent.
Once the agent code is running, put that URL into a browser and it will write the information into server storage. The next block of code handles the HTTP interaction. After that is the twitter-handling code.
Messages to the User
As noted above, there are two types of output:
userMessage. You may turn off
debugMessage entirely once you are happy with how it is working.
For me, debug messages go to the server log and to my general account at twitter. User messages are called out in the server log (prefaced with "!!!!") and go to the
attn in twitter.
Since these functions are separated, it is straightforward to modify them to email, text, or use another media to inform you of events.
There are three asynchronous timers, each monitoring for things to happen (or not):
- Battery update -- If this times out, we received no battery update: something is wrong since the device isn’t communicating.
- Motion update -- If this times out, the user has not moved the device: send a message to the caregiver to check on their loved one.
- Everything is fine -- If this times out, no errors occurred: send a reassurance message to the caregiver that all is working normally.
These all have the same elements:
- Modifiable timeout from the settings section on the top of the file (
- Timer variable used to start and stop the timer (
- Function that is called when something happens that resets the timer, such as a motion is received from the device (
motionOnDevice), this often causes a debug message.
- Callback when the timer expires (
noMotionFromDevice), this causes a user message.
- Timer creation (
motionUpdateFromDeviceTimer = imp.wakeup(dtNoMotionDetected, noMotionFromDevice);).
Once you see the symmetry between them, it is less of an impenetrable wall of code