Standalone Intelligent Sensor (SIS)

Concept Document © Bob Glicksman and Jim Schrempp, revised October 2014

Product Concept.

The Standalone Intelligent Sensor (SIS) is an inexpensive device that allows several sensors or simple devices to be accessed from anywhere in the world. The sensors connect to the SIS via wires or low cost wireless connections. The SIS joins a local WiFi network to connect to the internet. The SIS is then available to be managed from anywhere in the world. The SIS contains a microcontroller that can be remotely programmed. Imagine a temperature sensor that can be easily read from anywhere in the world. Imagine a buzzer that can be turned on from anywhere in the world. Imagine 10 of these devices connected to one SIS and under your control. The Standalone Intelligent Sensor (SIS) is intended to fill a perceived market gap between (a) complex wireless centralized multi-sensor systems and (b) simple, single sensor systems with Internet connectivity (IoT). SIS would be a purchased item requiring no recurring charges (no “monthly monitoring” charge) and would cost less than $200 for a package of the module, sensors, internal application software (firmware) and associated app for a mobile device (IOS or Android).

SIS is envisioned as a small box that can be mounted to a wall or ceiling via double stick tape or velcro. The SIS box is flat with a proximity sensor on the top, a power connector on one side (connect to AC power via a “wall wart”), and a small number (e.g. 4) of RJ-11 connectors on the other side. Internally, SIS has a microcontroller module with WiFi connectivity and hardware configurable (e.g. via jumpers) I/O circuits that allow the external connectors to supply analog or digital inputs (or outputs) to whatever they are connected to. Additionally, the SIS has internal 315 MHz and/or 433 MHz receivers to receive data from low cost wireless sensors that are within a few hundred feet of the SIS unit. The idea is to have a module that can interact with the outside world via a small number of wired or wireless sensors and enough internal intelligence to (a) timestamp and log a limited number (e.g. 10 or 20 each) of individual sensor events, (b) derive “meaningful” real-world events from a combination of individual sensor events and timestamp and log these, (c) provide one or more registered users with a mobile app to access the sensor logs whenever they want, and (d) to optionally provide asynchronous event notifications to registered mobile devices in the event that on-board (to SIS) algorithms detect anomalous event conditions.

As an example of an SIS application, consider a product deployed in a kitchen consisting of an SIS box and one or more of the following sensors communicating with it:

• Proximity sensor (internal)
• Magnetic “door” sensor connected to refrigerator door.
• Magnetic “door” sensor connected to utensil drawer, pantry door, and/or plate/glass cabinet door.
• (optionally) a thermal sensor located on the stovetop to indicate when it is hot.
• (optionally) an AC current sensor on the plug to a microwave oven and/or toaster oven.

The intention of the product is to inform a caregiver or loved one as to whether or not an elderly person living alone at home is eating or not. Note that no single sensor is likely to provide a “reasonably accurate” answer to this question, but some combination of these sensors can be used in an algorithm that does provide a “reasonably accurate” indication of the event “meal taken”. The on-board algorithm inside the SIS firmware would compute this “derived event” and timestamp and log it along with individual sensor data. In addition, the SIS firmware can be configured, via the mobile app, to provide a text or phone alert in the event that no meal was taken between some pre-specified hours. Note the assumptions here that (a) WiFi is available on premise for the SIS to connect to and communicate over the Internet thereby, (b) there is a wall with a power outlet in the kitchen whereby a user must stand or pass by in order to prepare food, and (c) this same wall is convenient to (close by) the appliances and cabinets to which any wired sensors must connect. Note too the assumption that a caregiver or loved one can install the SIS, including mounting the sensors appropriately. Further, it is assumed that the caregiver or loved one can install the app on their mobile device and register the app to the SIS using a simple, Internet based procedure. These assumptions may not apply to every case, but are generally reasonable.

Background and Market Analysis.

This section examines the various market segments where the SIS might find a niche. We summarize what is presently known about these various market segments and investigate gaps and opportunities. Sensing Market In General.

The focus of this document is on in-home sensors and monitoring. The SIS is not envisioned to have a role in industrial or commercial settings.

The in-home sensor market utilizes a wide variety of low cost sensors, including (but not limited to):

• Contact sensors
• Magnetic proximity sensors
• IR motion/proximity sensors
• Ultrasonic distance sensors
• Temperature sensors
• Moisture/humidity sensors
• Heat sensors/IR sensors
• Visible light sensors
• Sound (audible and ultrasonic) sensors
• Acceleration sensors
• Position sensors
• Pressure/force sensors
• Liquid level sensors
• Electrical voltage and current sensors

In the past, these sensors were hardwired to electronics that processed the data from the sensors and/or communicated sensor data to the outside world. In many instances, these sensors were (and still are) used inside of consumer products to provide automation of the product, e.g.:

• Sensors for the water level in washing machines.
• Sensors for humidity to determine completion of clothes drying in dryers.
• Temperature sensors to control the baking heat in ovens.
• Fire and smoke sensors in safety alarm systems.
• Contact and motion sensors in home intrusion alarm systems.
• Temperature sensors in thermostats.

Increasingly, there is a push to place sensor data on the Internet to create the so-called Internet of Things (IoT).

A variety of technologies is currently being employed to improve the intelligence possible with data from a number of home sensors. Wired connections of security and home monitoring sensors is being replaced by low cost, battery operated RF technology to make sensor installation simple (stick it on the wall - no wiring on or through walls required). “Low cost”, in this context, means that a sensor that costs $1 all by itself will cost $20 - $40 when packaged with a low power RF transmitter, microcontroller (for the communication protocols), and battery. Low cost RF sensor packages generally communicate with an in-home base station using a vendor proprietary point to point communication technology. The sensors and base station must all come from the same vendor. The base station may process sensor data on its own, or may forward the sensor data (raw or processed) to a vendor specific central monitoring facility via phone line modem, built in cellular modem, or customer provided WiFi to the Internet. Most sensor packages that communicate this way obligate the customer to a pay a recurring monthly service fee in order to be effective, often with a multi-year contractual commitment.

Increasingly, the low cost proprietary RF wireless communications are being subsumed by more sophisticated open standards for short range RF networks, such as Z Wave, Zigbee, or even 802.11 WiFi. These newer, open standards allow systems to be built using different vendor’s sensors and base stations and support more resilient and longer range (through “routers” in “mesh networks”) communication capability. This comes at a price, however, as support for these communication standards increases product cost. Nevertheless, RF communication circuits are being bundled with sophisticated microcontrollers to make sensors that use these technologies smarter and more cost effective.

We believe that there is a gap in todays in-home sensor market and aim to fill that gap with SIS. We believe that processing raw sensor data in central base stations or, increasing, in the “cloud”, is wasting processing resources that are increasingly available in the microcontrollers that are packaged with sensors to provide communication protocol, but have a lot of processing power to spare. We believe that the push toward IoT and “cloud processing” is driving applications that use in-home sensors more and more to monthly subscription services with high cost over time, expensive multi-year contracts and commitments, and force consumers to commit to a single vendor over several years. In some cases, this is warranted. In other, simpler cases, we believe that a low cost platform that can integrate a few, wired or simple wireless sensors, when packaged with sophisticated processing and Internet connectivity, can avoid recurring costs and perform many desired and relevant jobs with direct (via the Internet) communication with mobile devices, bypassing the expensive and intrusive middleman.

The number of sensors and sophistication of the SIS is necessarily limited because non-professional installation generally mandates short wire or wireless runs. The next few subparagraphs look at specific applications for in-home sensors, examine what is presently available, and make the case for niches that SIS might fill. Specific use cases for SIS within these market segments is further explored in section 3 of this document.

Aging In Place Market Space.

Aging in Place (AIP) is a concept that postulates that technology can be used to help people stay in their homes safely longer than is common at the present time. It is desirable, both from a financial and emotional standpoint to do so. AIP covers a very broad area, including mobility and social isolation issues. SIS, in particular, is aimed at a specific sub-area: monitoring and communication to ensure that an elderly person is safe and continues to be able to perform necessary activities of daily living in their home. There are two broad categories of AIP technology that are being marketed today:

• Emergency monitoring and assistance technology.
• Activity tracking technology.

While there is some overlap between these technology categories, they take fundamentally different approaches to generally different problems. Emergency monitoring and assistance technologies employ a wearable device that allows the wearer to press a button and speak to a trained person, anytime 24x7. Some of these systems work only within the home, while others incorporate cellular phone technology (and often GPS technology as well) to allow the wearer to summon help from anywhere, inside or outside the home. Newer products are being announced that have the capability to automatically detect emergency conditions (e.g. a fall) and connect to the help service without the need for the wearer to push a button. Regardless of the details, all of these systems acknowledge that in an emergency, it is necessary to contact a support person 24x7 and that the contact have training and resources to know how to respond (summon police, paramedics, advice nurse, give directions, inform a caregiver or relative, etc.) It is not wise for the emergency contact to be to the mobile device of a friend or relative who is not actively monitoring 24x7; e.g. a relative that might be watching a movie and have their cell phone muted for 3 hours or more. SIS is not considered to be applicable to the Emergency monitoring and assistance subcategory.

Activity tracking technology aims to determine patterns of “normal” activity within the home and to detect and report aberrations from the norm that may indicate that an elderly person is “at risk”. This market segment has recently been surveyed and categorized in the report “Activity-tracking Home Sensor Systems” by Richard Caro and Mary Hulme (available from Amazon.com at: http://goo.gl/7HnxCO). Caro and Hulme analyse this market segment from a number of different perspectives (axes) and rate the products that are currently in this market space within each of these axes. We will not attempt to describe Caro and Hulme’s findings here; we recommend reading their excellent report. There are, however, a number of issues that jump out of the Caro and Hulme report that are relevant to SIS:

• All of the systems reported by Caro and Hulme are subscription based systems, with the high recurring costs and service supplier lock-in mentioned in section 2.1, above.
• All of the systems that Caro and Hulme found in this market segment attempt to instrument the home sufficiently to determine “normal” activity patterns for all activities of daily living. Some of these vendors even offer artificial intelligence algorithms to help ferret out normal activity patterns from a wealth of sensor data. The inevitable result is a highly intrusive home installation.
• Many of the vendors studied by Caro and Hulme justify high cost and high levels of intrusion by claiming that their systems allow the elderly to stay in their homes longer than without these systems installed. The cost and intrusiveness of moving a person to an elder care facility is much higher than the cost and intrusiveness of their systems, it is claimed.

We believe that the intrusiveness of the systems is likely to be less of an issue to relatives of the elderly person than to the the elderly person themselves! It is very comforting for loved ones to know that their elderly parent or grandparent is performing adequately and can be safely left in their home. Many testimonials by the elderly persons themselves, however, clearly show that these at risk people believe that they are safe and competent and do not believe that they need to be intrusively monitored to prove the point. We therefore conclude that there will be a lot of resistance to broadly instrumenting an elderly person’s home just to establish their normal activity patterns and detect and track changes therein. More likely, in our opinion, is that the elderly person will accept in-home monitoring only after some adverse event occurs that causes conflict between the elderly person (who believes that the adverse event was an anomaly and won’t happen again) and their relatives (who maintain that the adverse event was but a symptom of inability of the elderly person to continue to live alone at home). After such an event, the relatives will now have a specific case to use in insisting on the monitoring that the elderly person still does not want. In these instances, a compromise would be for the elderly person to permit installation of a simple monitoring system that was limited to monitoring only the condition(s) surrounding the adverse event, e.g.:

• Monitoring motion in the house because the person did not get out of bed some days
• Monitoring the kitchen because the person was found to be not eating regularly
• Monitoring the bathroom because the person had a period of irregular toilet activities
• Monitoring the front door because the person forgot to close or lock the door when leaving the house
• Monitoring the appliances because the person had left the stove on or the water running
• Monitoring medication compliance because the person was not taking their medications regularly

In each of the cases above it would be easier for the elderly person to accept a very limited amount of monitoring that addressed the specific problem that their relatives observed. It will also be easier for the relatives to convince the elderly person, if the other option presented was a whole-house, whole-life monitoring scheme.

In many such instances, SIS can provide the necessary level of monitoring, logging and reporting without high cost, without recurring charges, without long term contracts, and with a level of sensing and monitoring that everyone can recognize to be specifically aimed at a specific potential problem and not be general, widespread and intrusive. Section 3.1 presents some specific use cases to illustrate this point.

General Home Monitoring Market Space.

Today, the general home monitoring market is principally in the area of security: safety (smoke and fire sensing and alarming) and security (intrusion detection and alarming). These systems may involve a complex network of sensors with a central node connecting with a remote monitoring service, or single standalone sensors (e.g. smoke, fire, CO) that alarm locally. Some personal emergency capabilities may also be bundled with the ongoing monthly fee-based service model.

In addition, there is an emerging home automation model that networks home appliances together to act more cooperatively and intelligently; e.g.:

• Have the dishwasher coordinate with the washing machine to ensure that both aren’t using hot water at the same time and leaving no hot water for when the resident returns from a jog and is in need of a nice hot shower.
• Have the oven and microwave automatically come on at a specific time or based upon a specific event (“resident leaves office”) so that preloaded food is ready and hot when the resident arrives home.
• There is a lot of “buzz” surrounding the notion of tying these and other appliances (e.g. door locks, thermostats) to the Internet so that residents can remotely status and control them; e.g.:
• “Did I (or my teenager) forget to lock the front door when I left?” if so, allow me to remotely lock it.
• “Did I leave the water running or the stove on when I rushed out of the house?”. If so, allow me to remotely turn it off.
• “Allow me to unlock the front door automatically at 10:00 am so that the cleaners can come in and relock the door automatically at 11:00 am.” Allow me to override these automatic settings remotely.

In most instances, the products that exist in these market segments are only capable of performing a single function, based upon a single sensor. They cannot, for example, be set up to leave the front door unlocked but automatically lock it after someone leaves the house. The reason that they cannot do this is that the event “someone leaves the house” requires more than one sensor to determine that a person has left and not just opened the door to talk to a friend or vendor.

SIS is not presently envisioned as having applicability in the home automation space. In most instances, this requires sensors and intelligence to be built into appliances. It would take a serious hacker to re-instrument their washing machine with SIS, for example. However, SIS could fill a niche in the home sensing and automation market where several sensors that are in close proximity to each other are needed to make an actionable decision. For example: “Let the water run in the kitchen sink as long as the water level in the sink does not get too high or as long as someone is standing in front of the sink. Otherwise, automatically turn it off.” Some example use cases are presented in section 3.2.

Other Potential Applications.

SIS could fill voids in the marketplace by instrumenting areas around the home or office, such as locking/unlocking file cabinets containing sensitive information, keeping plants or gardens healthy, and outbuilding/garage security. Some example use cases are presented in section 3.3. Use Cases.

Aging In Place Use Cases.

“I am concerned that Grandpa is not eating.”

This use case was highlighted in Section 1. A caregiver or loved one is concerned that an elderly person is not eating regularly and needs to be moved to a facility where their dietary needs are met and monitored. The elderly person is pushing back, claiming that they are eating and are perfectly capable of living at home and of caring for themselves. A compromise position has the elderly person agreeing to SIS monitoring of their kitchen activities via proximity sensing and sensing of one or more food related activities:

• opening and closing the refrigerator door.
• running a microwave or toaster oven.
• running of the stovetop and/or oven.
• opening/closing silverware draw or flatware cabinet.
• running of the dishwasher.

It is entirely possible for the elderly person to “spoof” this system, but this isn’t really the point. The issue is that the elderly person believes that they are caring for themselves properly but in fact are having a series of days where they just don’t “feel” like eating anything. The family needs to know when and how often this happens, and perhaps also why it happens. It is entirely possible that the elderly person, when confronted with the facts of their kitchen activities (or lack thereof) will come to agree that they need help and supervision, either in their home or via a move to an assisted living facility. SIS can thus provide the bridge between family fears and an elderly persons denial.

“I called Mom when she should be home but the phone is not answered.”

The question here, of course, is whether Mom is in the house and unable to answer the phone (due to fall, stroke, or other serious problem) or whether she is just fine and decided to go out of the house or apartment, perhaps for socialization activities. The concern could be mitigated if the state of “in the house” and “out of the house” could be known. Without relying on the person wearing a certain NFC fob, the activities of “leaving the house” and “entering the house” could be timestamped, logged and accessed via the Internet. SIS can provide such information, particularly if the person lives alone. An SIS that is properly placed on a wall leading to the front door can detect and log motion in the vicinity of the front door via its proximity sensor. A contact or magnetic sensor can be placed on the door jam with a magnet affixed to the door that will detect and log door opening and closing actions. The SIS firmware can implement an algorithm that monitors the time sequence between activation of these sensors to determine if someone has left the house or entered the house, and when the activity occurred. This action can be queried remotely to alleviate concerns over why the phone is not answered -- someone left the house prior to the call and has not yet returned. Alternatively, if the resident is expected to leave the house at certain times (e.g. for therapy appointment), the SIS can be programmed to alert a caregiver or loved one of the exit/entry activity has not taken place, as expected.

This application works best if there is only one person residing in the house or apartment. Obviously, the SIS can easily be fooled if someone else enters and leaves, as this use case does not include person identification. However, there are a great many circumstances where a single person is the only one expected to enter and leave most of the time and can thus provide valuable and even life saving information.

“Last year Dad had a urinary tract infection but did not tell anyone about it. Ultimately, he had to be hospitalized”.

There were indications of this infection, of course, but Dad ignored them. He woke up ten times that night to go to the toilet. However, he didn’t think anything of this and didn’t tell anyone about it. Now, family has confronted Dad with this problem, suggesting that it is an indication that he can no longer live alone at home. Dad denies this and, although prone to these infections, insists that he “knows better now” and promises to tell family the “next time”. Family members remain concerned and believe that the problem will recur, perhap this time resulting in his death due to lack of timely treatment.

SIS can be mounted to the bathroom wall so that its internal proximity sensor detects and logs entry into the bathroom. A contact sensor on the toilet flush or a water level sensor inside the toilet tank can detect and log flushing activity. The combination of these sensor actions can be used, by SIS firmware, to log the activity of a toilet visit and the SIS can further be programmed to notify a family member in the event that a certain number of toilet visits has occurred within a prespecified period of time. The caregiver/loved one can contact Dad,in this event, to ascertain the reason and intervene proactively and in a timely manner in the event that a new infection is suspected.

“I am concerned that Mom is staying in bed all day with the lights off and the drapes drawn. She denies the depression.”

SIS can be mounted on a wall to detect and log motion into and out of the bedroom. The direction of the motion is unimportant -- it is only important that it occurs. Additionally, pressure and/or flex sensors can be installed in the bed or on a mat at the foot of the bed to detect and log activities coming off of or on to the bed. A light sensor can be added to detect and log periods when some light (natural or lamp) is in the bedroom and when the room is dark. A combination of these sensor detections can be programmed into the SIS to log the event of getting out of bed and possibly of getting into bed as well, and the lighting conditions during the day. SIS can be programmed to alert a caregiver or family member if the person is still in bed at a certain time of day, or has not gone to bed by a certain time at night, or if the lights are kept off during the daytime (possibly indicating depression).

“Beloved Aunt Millie has emphysema and is not allowed to smoke. She lives alone and her loved ones are concerned that she continues to smoke and is likely to die if her smoking is not monitored.”

SIS can be fitted with a smoke detector sensor and programmed to log instances of smoke detection and to alert a family member if the sensor is triggered. This case is a little different than other SIS use cases. In this case the SIS will be seen as quite intrusive by Aunt Millie and the SIS will have to be installed in a secure location and protected from vandalism by Aunt Millie. Uncle John has left the freezer door open several times. The food has spoiled and then refrozen. This is a health danger.

SIS can be fitted with a temperature sensor in the freezer. If the temperature rises above a preset safe limit for a period of time then a family member is alerted.

Home Monitoring Use Cases.

“I am getting forgetful and prone to leave the water running in the sink.”

SIS can be fitted with a water level sensor to detect if the sink is getting filled. The internal proximity sensor can be used to determine if someone is at or near the sink (thus intentionally filling it) or if the water has been left on and the sink unattended. In the latter, derived case, the person can be alerted via their mobile device. An enhancement of this use case would have SIS output a signal to a solenoid emergency shutoff valve either automatically or via a signal from the user’s mobile device, as configured via the user’s mobile app.

“My teenage kids have keys to the house so that they can get in after school. They are inattentive and forget to close and lock the front door when they leave.”

SIS can be used in the same way as in section 3.1.2. SIS’ internal timekeeping capability can be used to log instances of someone leaving the house after a certain time of day, e.g. after 3:00 pm. Then if the door sensor shows the door to be open after e.g. 10 minutes of an exit detection, SIS firmware can generate an alert to the user’s mobile device. In addition, if the door is locked via a deadbolt, a contact or magnetic sensor could be added to determine if the door has been locked, as well as closed. Alternatively, it might be possible to instrument a rotary lock with a lock position sensor, via a potentiometer or similar device.

“Rainwater collects under my house. I have an automatic sump pump to pump the water out, but the pump sometimes fails and I am concerned about the foundation being flooded in a rainstorm.”

An SIS can be installed under the house if power can be supplied to it. A water level sensor and/or a moisture sensor could be used to determine if water is building up under the house. If it is, then the sump pump is not operating properly and the user can be alerted.

Other Use Cases.

“I have a greenhouse in which I grow valuable plants. I need to know when the temperature or humidity get out of a predetermined range so that I can intervene to save the plants from dying.”

Assuming that the greenhouse has AC power, an SIS can be fitted with a temperature/humidity sensor and be programmed to log temperature and humidity and to alert the user whenever either measurement goes out of prespecified limits.

Detailed Product Requirements and Technical Description.

Detailed Product Requirements.

Size: The SIS shall be small enough and light enough to mount on a wall. Approximate size: less than 3” tall x 5” long x 1.5” high when wall mounted.

Mounting Options. The SIS shall have the provision to screw mount it to a wall, or to securely mount it without hardware via double stick tape or velcro tape.

Power. The SIS shall be able to be powered by a “wall wart” AC power transformer supplying regulated 5 volt power through a USB connector. It shall require a minimum of 500 ma or more of regulated 5V DC power from the wall wart power supply. The power shall be supplied to the SIS via a mini-usb connector as to be compatible with low cost commercial wall wart power supplies.

Environmental Requirements. The SIS shall be capable of operating in ambient temperature of between 0 deg C and 50 deg C and of operating in relative humidity of 0% to 100%, non-condensing. The SIS sensors are not required to operate over these full ranges -- they are only required to operate within environments for which they are intended to be used.

Internal sensor. The SIS shall contain an infrared proximity sensor that protrudes through the top of the unit, so that it can face out into a room when the SIS is wall mounted.

Connectivity. This SIS shall contain four (TBD) four pin external connectors, type RJ11 or similar. These connectors shall support a wide variety of external sensors by supplying the following signals and option on the 4 pins: Pin 1: power to external sensor - jumperable to supply regulated 5 volts or regulated 3.3 volts at up to 100 ma. polyfused; Pin 2: signal - jumperable to be an analog signal, digital logic signal, digital contact closure signal, digital DC current or DC voltage signal that is optically isolated within the SIS; short circuit protected; Pin 3: signal common - return signal for opto-isolator within the SIS and jumperable to IS internal ground for all other signal types; Pin 4: analog reference voltage - analog reference at 3.3 volt or other with option for an SIS internal resistor to form a voltage divider with the external sensor.

SIS shall have RF receivers for the unlicensed 315 Mhz and/or 433 MHz wireless bands. SIS shall be able to decode wireless signals from simple, low cost wireless sensors operating in these bands (e.g. PT2262 and EV1527 protocols).

Optional Connectivity. The external connectors may optionally be jumpered to provide digital, PWM and I2C outputs. The output need not be optically isolated -- they are intended to expand the capability of SIS to perform actions and not just monitoring. When performing such external actions, it can be presumed that logic level signals from the SIS will be appropriately buffered, isolated and amplified externally to the SIS. In addition to the external jacks, all digital and analog signals from the SIS internal microcontroller shall be available via internal pin headers for possible future expansion capability and testing.

Networking. The SIS shall communicate over WiFi, 802.11 a/b/g/n. It shall support WAP, WPA or WPA 2 security over the WiFi.

Internal timekeeping. The SIS shall be capable of keeping time internally, even through power disconnects and failure. The timekeeping shall either use Internet time or an internal standard that is accurate to within 30 minutes per year. The intent of the timekeeping is to provide timestamping of sensor hardware and computed events.

Internal programmability. The SIS shall support internal microcontroller programmability so that it can be tailored to a wide variety of applications. The SIS shall support at least 32 Kbytes of program memory and at least 2 Kbytes of data memory. The SIS shall also support at least 512 bytes of EEPROM or equivalent for non-volatile internal event logging. SIS Technical Description. The following is a baseline design for the SIS. It is provided as a concept discussion to validate feasibility of the requirements. A good candidate baseline technology for the SIS is the Spark Core from Spark.io. This product is a very small but highly capable microcomputer with built-in WiFi capability. The Spark Core provides 8 digital IO and 8 analog IO, with some pins doubling as USART serial, I2C, SPI and PWM. The spark IO uses the same “wiring” language as does the Arduino and is mostly (but not 100%) Arduino compatible. The Spark Core module can be powered via USB, using either an internal (to the module) USB connector or an external power pin. The Spark Core runs off of an internal regulator at 3.3 volts and can convert input power anywhere from 3.6 volts to 6 volts. We envision using an external USB connector for power supplying 5 volt power to the SIS, both for the Spark Core, for any added internal circuitry (e.g. RF receivers), and for use by external sensors that may require 5 volt, vs. 3.3 volt, DC power. The Spark Core configures easily to any consumer WiFi intranet through an iOS or Android application that sends the Wifi credentials to the Spark Core using a proprietary protocol to communicate over WiFi even when the Spark Core is not part of the WiFi network. The Spark Core connects to a cloud service (no cost to customers) that provides a proxy for other Internet connected devices to communicate with the Spark Core through firewalls and NAT traversals. Spark.io seems to be unique in regard to this capability. The Spark Core libraries include an Arduino compatible time library that uses Internet time for its standard. The Spark Core contains the ability to map Arduino (wiring) code on the microcontroller side to a RESTful interface on the Internet side. HTTP: GET commands sent to the Spark Core can be used to read up to 10 internal variables declared in a specific way in the wiring language (albeit limited to certain data type). Likewise, HTTP: POST commands sent to the Spark Core can be used to activate functions in the microcontroller side wiring language and to provide parameters needed in the function calls (and the function return type). HTTP: PUT commands are used to upload microcontroller software to the Spark Core, if desired.
The Spark Core also provides a way to register a callback to a URL through the cloud. <<This seems like a key piece of functionality. Does this mean that a web server could register a URL with Spark Cloud and receive a string when a specific Spark Core raises an event?>> The Spark Core can be programmed using the Arduino IDE or a very similar web based IDE provided by Spark.io (free of charge to customers). All Spark hardware, software, firmware and tools are released under open source licenses and production products can freely use Spark.io designs for complete compatibility (if used for commercial purposes, various fee structures apply, but production of Spark.io based products do not rely on Spark.io staying in business).

The analog and digital interfaces on the Spark Core more than meet the SIS requirements of the previous section. However, the integration of wired and wireless sensors and provision of power and signals to the external connectors, as well as integration of the internal proximity sensor and internal voltage regulator, require the development of a simple “motherboard” into which the Spark Core module can be plugged. The motherboard will accept the Spark Core module and bring out all of its I/O pins to pin headers for optional future use. It will bring out 4 of the analog/digital pin to opto-isolators with associated current limiting resistors and jumpers so that each of these pins can be individually provided to their respective RJ11 jacks to meet all of the requirements of section 4.1, above. It will also accept data from one or two RF receiver modules mounted on the motherboard. The RF signals from wireless sensors may be decoded by software on the Spark Core or, alternatively, via a small, dedicated microcontroller which is also mounted on the motherboard.

It is assumed that the motherboard will contain a micro-USB connector to provide regulated 5 volt power for jumpering out to sensors as well as to the Spak Core module (which requires 300 ma. max of the 5 volt input when fully powered and communicating via WiFi). It is assumed that the wall-wart power supply will provide well regulated 5 volt DC power so that a 5 volt require is not required on the motherboard. [Note: the Spark Core module can take 5 volt power from its USB connector and provide it out on one of its pins, but it does so via a protection diode that will drop the voltage by about 0.7 volts (i.e. to 4.3 volts), which may not meet the demands of some 5 volt devices. It may also be easier to mount the motherboard inside the SIS case if the USB connector is not hard mounted to the plug-in Spark Core module.]

Users will communicate with the SIS via apps that we will write for IOS and Android. The apps will use the REST interface to Spark Core from the Internet. Asynchronous alerts generated internal to SIS for external uses can be generated in a number of ways (selection of approach is presently TBD):

• Registered callback to an app on a GET, if supported by the underlying mobile OS.
• Activating the app on a timed (frequent) basis and polling the SIS via GET.

The SIS acts as a web client and uses RET to an Internet service that can send SMS text messages or text-to-voice phone calls to cell phones (e.g. Twillo). [Note: these services may charge a fee for this service]. Push Notification Service

In Push Notification, the smart phone application registers with a push notification service (Apple, Google, etc) and receives a token. The smart phone application sends this token to its own infrastructure. When the infrastructure wants to push a notification it sends this token and the message to the push notification service. The push notification service uses the token to send the message to the correct smart phone.

These push notification services require the cloud application to be registered and authenticated. There is not a per-notification fee, but there is a yearly fee on the order of $100. SIS could implement a cloud program to communicate with the push notification service.

Each SIS would be configured by a smart phone application. The smart phone application would register for push notifications and obtain a token. The app would then pass the token to the SIS module where it would be stored. When the SIS wanted to send a notification to the phone it would contact the SIS cloud service and pass the notification and the token. The SIS cloud service would format that information and pass it on the push notification service. The push notification service would then pass the notification on to the correct smart phone. SMS Email

While Email may be considered too slow for the kind of alerts the SIS might want to send, it turns out that all major phone carriers offer an email-to-SMS gateway. Sending an email to a specific email address will cause the message to show up as an SMS message on the cell phone.

The SIS could send an email in several ways. The SIS could send email directly to the destination email server, the way SendMail does. However, most commercial email services will not accept inbound email except from other commercial email services; if they did spammers would use it.

The SIS could send email to an SMTP server, but this will require it to have credentials that the SMTP server would accept. The user would need a way to add the SMTP server name, port, user account, password, etc. The SIS code would have to be ready to deal with any SMTP server, and some of them require odd configurations. It would be confusing.

A third way would be for us to create a free account at a service that supports POP/SMTP such as Yahoo, GMail, etc. Then the SIS would be configured to use our free account to send mail. Of course, as an open source project this would mean that other actors could read the account credentials and use it for spamming or other monkey wrenching.

We could require the user to create a free account at a specific service (Yahoo, GMail, etc) that we support. Then the only configuration to add would be their account and password; we would already know the specific SMTP configuration required. This is currently considered the best option.

Lastly, we could maintain an email relay web page. This page would answer a URL of the form http://xxx.yyy.zzz/[email protected]&msg=thetexttosend This URL would parse out the to address and the message and then send the email via an account we set up for that purpose. The credentials for this email account would only be known on the yyy.zzz server and thus not exposed to the public. Of course someone could read our SIS code and decide to spam through this email relay, but the php script could impose limits on the number of messages from any one SIS device.

Additional Investigations Needed.

Sensors.

The current SIS concept provides for both wired and low cost wireless sensors. The wireless sensors envisioned utilize a very simple protocol, either that of the PT2262 or of the EV1527 encoder types. A technical investigation has shown that we can decode these signals and thereby incorporate inexpensive (generally < $10) wireless sensors that can be purchased over the Internet. However, the wireless sensor capability is limited to sensors that supply one to four binary event notifications, e.g. “door opened” or “proximity detected”. These simple protocols do not support the wireless transmission of more complex data, such as analog readings of temperature, humidity, or fluid level. Wired sensors will have to be used to support these capabilities. At present, it appears that this combination of simple wireless and wired sensors is a good compromise that will support most SIS applications while maintaining low cost and sensor vendor neutrality. The use cases for SIS need to be flushed out and the applications tested in order to validate this presumption.

Alerts.

It is not known, at the moment, how asynchronous alerts to wireless devices will be generated, nor if this can be done without using a fee-based service. See section 4.2 for possible options.

5 Volt Logic Power.

The Spark Core accepts regulated 5 volt DC power, which can be supplied via a “wall wart” power supply. The Spark Core already has a micro-USB connector which can be used for this purpose. The Spark Core contains a 3.3volt regulator which can use the 5 volts from the USB to power the Spark Core module. This regulated 3.3 is available to the daughterboard and can thus be routed to the SIS RJ11 connectors to power sensors that required regulated 3.3 volt power. However, many low cost sensors require 5 volt regulated power. The VIN pin on the Spark Core module will route USB power to the module out from the module. However, the Spark Core schematic shows that there is a diode drop between the USB 5 volts in and the VIN pin routing it off board. This diode drop (approximately 0.7 volts) would make this voltage too low for many sensors.

The proposed solution is to place a mini-USB connector on the SIS box or daughter board to accept 5 volts regulated power from a wall wart power supply and the daughter board would then route this power out to RJ11 connectors (if so jumpered) and also to the VIN pin on the Spark Core module where it would directly power the module’s 3.3 volt regulator. In order to avoid confusion with the Spark Core’s own micro-USB connector, the latter would be placed inside the SIS case. This means that if the Spark Core USB were needed for communication (e.g. to reprogram the device) it would have to be removed from the SIS box. This is not a large issue, as the Spark Core can be programmed over the Internet and, in any event, should not require reprogramming after deployment. However, it ought to be confirmed by actual measurement on a Spark Core that there is indeed a diode drop between the micro-USB on the module and the VIN pin. If not, using the module’s USB would be preferred. LED indicators.

The current technical specification does not call for placing an LED or two on the top of the SIS box, wired to some digital pins on the Spark Core. The Spark Core contains two LEDs on the module, including one multi-color LED and the other a general purpose LED. However, these LEDs are only visible on the module and would not be visible from outside the SIS enclosure. Would it be handy to place an LED or two on the SIS enclosure? It might be useful to have this, e.g. to program the SIS to blink an LED when the proximity sensor is tripped or a contact sensor is broken, etc. This capability might be a big aid to SIS installation. If blinking LEDs are not desirable in some SIS application, the SIS software can be programmed to not blink them. Additionally, the LEDs can be made jumperable so that no Spark Core pin are wasted if the LEDs are not used. It seems useful to add these into the spec. The question is: how many? Note: there need not be one LED per sensor. The number of blinks or rate of blink of an LED can indicate several states of the SIS on one indicator. Outputs.

SIS is envisioned as a sensor platform; therefore, the RJ11 connectors are for inputs to the Spark Core module. However, it might be useful to have some outputs as well. Since all Spark Core pins will be connected to pin headers, and the signal circuits to the RJ11 jacks are to be jumperable, outputs can be provided wherever desired, but only via pin header connection inside the SIS enclosure. Would it be worthwhile to provide additional jumerability to allow Spark Core signals to be outputs to the RJ11 connectors? If so, should these be logic level or via opto-isolators. The more jumperability that is provided, the more time it will take in manufacturing and configuring an SIS for any given purpose.

Appendix A. Typical Sensors That Might Be Used With SIS.

Below are examples of low cost sensors (many under $10 in unit quantity) that can be used with SIS. This list is provided to demonstrate feasibility of the SIS project. A detailed technical evaluation of sensors and sources must be made for actual SIS product selection.

Magnetic sensor. This is a “hall effect” sensor that can detect the presence of a magnetic field. It can be used with a small magnet to detect the opening/closing of doors and windows and also of detecting AC and DC magnetic fields of wires carrying electrical current. https://www.sparkfun.com/products/9312

Magnetic door sensor. This is a reed switch that closes when in close proximity to a magnet. It is useful for detecting door and window open and closure states. http://www.adafruit.com/products/375

Optical contact sensor. This is an optical interrupter that can detect the presence of an opaque object through it’s open core. It can be used to detect door and window position (open closed), and for speed detection via a slotted wheel. https://www.sparkfun.com/products/9299

Microswitch position sensor. This is a mechanical switch with a roller ball actuator. It can be used to detect draw open/close, deadbolt in/out and other such contact actions. http://www.adafruit.com/products/819

Proximity motion sensor. This is a basic infrared motion sensor that can be used to detect people moving into or out of a room or hallway. http://www.adafruit.com/products/189

Ultrasonic range finder sensor. This device is useful to determine to range to a solid object, such as a car pulling into a garage. http://www.adafruit.com/products/980

Flex/bend sensor. This device can be used to detect and measure flexing and bending of objects and could be used in application such as determining if someone is getting into or out of bed (via flexing of the mattress). http://www.adafruit.com/products/1070

Temperature sensor. This is a basic analog temperature sensor that can be used to determine if a stovetop is hot, refrigerator is cold, etc. https://www.sparkfun.com/products/10988

Humidity sensor. This sensor detects both temperature and humidity and is useful, e.g., for indoor or greenhouse environmental monitoring. https://www.sparkfun.com/products/10167

Visible light sensor. This sensor detects and measures the intensity of visible light impinging on it. It can be used to determine if someone has left the lights on in a room, has turned off lights (e.g. to sleep), has the drapes /blinds open or closed, etc. This sensor is also useful outdoors, e.g. to detect if it is day or night at some remote location. https://www.sparkfun.com/products/9088

Pressure sensor. This sensor, and many light it in different sizes and shapes, can be used to determine if someone is lying in bed, is standing on a mat (with a platform underneath), etc. https://www.sparkfun.com/products/9375

AC current sensor. This sensor can detect the presence of AC power to an appliance or other AC powered device. It can be used to measure the current without contacting the AC and thu determine if an appliance is currently on or off. This particular type if sensor uses magnetic transformer-like coupling, but hall effect devices are available as well. http://www.ebay.com/itm/like/281150975569?lpid=82

Acceleration sensor. This sensor (and many like it) can measure acceleration in all three dimensions. It might be useful in fall detection and other similar applications. https://www.sparkfun.com/products/12756

Tilt sensor. This sensor can detect if an item is tilted over. It could be used to detect if an item that is usually upright is knocked over, e.g. a coffer maker. https://www.sparkfun.com/products/10988

Sound sensor. This sensor measures sound level. It might be used to determine if a TV or radio is on or off, or if someone has fallen and is shouting e.g. for help. https://www.sparkfun.com/products/12642

Dust/smoking sensor. This sensor can detect if air is dusty or smoke in it. It could be used to monitor dust buildup due to lack of cleaning a premises. It might also be used to detect if someone is smoking, contrary to their medical or safety restrictions. https://www.sparkfun.com/products/9689

Pulse sensor/heart rate monitor. This sensor detects a pulse and monitor heartrate. It is easily attached to someone for a quick measurement. It might be useful for monitoring heartrate during exercise. https://www.sparkfun.com/products/11574

Vibration sensor. This sensor might be useful to detecting someone walking, door slamming, earthquake or other significant event. https://www.sparkfun.com/products/9198

Liquid level sensor. This sensor could be used to check if a toilet tank is overflowing or running on. It might also be useful to detect an overflowing sink. http://www.adafruit.com/products/463

Capacitive touch sensor. This device could be useful as a push button for a person to signal some action. http://www.adafruit.com/products/1374

315/433 MHz wireless magnetic door sensor. This wireless and battery powered sensor can be stuck on a door, window or cabinet frame and send a signal to SIS whenever the target item is opened (removed from close proximity to its magnet). The sensor/magnet pair is small and very inexpensive. http://www.ebay.com/itm/370629635675

315/433 MHz wireless proximity infrared sensor. This wireless and battery powered sensor can be stuck on a door, wall or cabinet frame and send a signal to SIS whenever a person or animal comes into its field of view. http://www.ebay.com/itm/221068187723

315/433 MHz wireless water level/leak detection sensor. This wireless and battery powered sensor can be suspended into a bowl or toilet tank and positioned to send a wireless signal to SIS whenever the water level gets too high. http://www.ebay.com/itm/111049996563

315 MHz wireless key fob. This 4 button wireless key fob can be used in close proximity to SIS to inform the SIS software of user actions, e.g. to arm a sensor. http://www.adafruit.com/products/1095