Monday, October 19, 2015

I have a motion sensor in my mother-in-law's room, her bathroom (down the hall from her bedroom) and an open/close sensor on the house front door (which is next to her room). With just these two (cheap) X10-RF sensors I can tell a lot about the nightly activity of my dementia suffering guest.

If you haven't been following this blog's "elder care" stories: My mother-in-law has dementia so she lives with me and my family. She is apt to get confused and wander. Her room (the only available extra room in the house) is unfortunately next to the front door. The rest of the bedrooms are one floor up. Mother-in-law needs constant monitoring. She has "escaped" our house several times (at night and at dawn -- when we are still asleep) with the idea that she is going to walk to "her house". She also complains of insomnia and chronic pain. Is she sleeping at night? Is she up wandering the house?

So, I've designed a cheap sensor-based monitoring system. I explained that tech setup elsewhere. Here I want to posit the question: What kind of "story" can you tell with a couple of sensors?

With just a bedroom, bathroom motion sensor and a sensor to alert us when she opens the front door, I can talk about the following:

Did she leave the house or is she just "checking the weather" (door opens but is followed by movement in her bedroom)?

Is she restless at night (motion in bedroom)?

How many times did she visit the bathroom?

Is she in the bathroom for an unusually long time? (Bathrooms are where a high incident of heart attacks tend to occur)

When did she get up in the morning? (Motion in bedroom, then bathroom, then bedroom again)

Now, my current software doesn't tell a complete story (yet), but with the reports/alerts it generates, my wife and I can determine with a quick view of the data on our smartphone, any of the above scenarios.

I'd like to add a couple more sensors, maybe a light sensor and temperature monitor for the bedroom to help flesh these stories out.

The moral (of this post) is: You can tell a lot with just a few sensors and a lot of common sense. It isn't about the "hardware tech". It is, ultimately, about making sense of data. I want to get my software to the point where it "tells the story" rather than just provide data for my wife and I to review. Here is my ideal morning report (sent to my phone instead of the raw data events):

Betty slept between 9:30pm and 6:15am, awaking at 11:15pm and 2:30am to go to the bathroom. At 6:30am she opened the front door, closed it and went back into her room. Her room light has been on since 6:45am and there is currently no movement in her room.

I don't need this report in verbose english (like above), but I should be able to quickly derive the above story from summarized data points. All of this can be surmised by the current three sensors.

I've so far have 2 semi-working (new) implementations for each of these projects. I started developing both in a high level programming language (Clojure) and ended up runnng into a few walls that caused me to look at alternative implementation languages (in both cases Lua(JIT)).

With Clojure I got to swing around futures, core.async and rich data structure manipulation, but I hit implementation walls involving libraries (mostly Java) that don't quite do what I want. Soon I was finding myself installing broken, old or incompatible packages.

Abandoning Clojure, I headed back to LuaJIT. Here I had much more control over my environment, but greatly missed builtin things like futures, core.async and rich data structure manipulation.

Clojure and LuaJIT represents the opposite ends of the spectrum but they do have the ability to overlap (I can drop down to Java/JNI in Clojure and I can evolve Lisp-like richness out of Lua).

Thursday, October 01, 2015

In my copious free time I am working on a new system I am (tentatively) calling Confab.
Confab is an adhoc (on demand) VOIP conference call system utilizing the popular gamer VOIP/chat system Mumble.

Confab will use any Mumble client (iOS, Android, Windows, Linux, etc) but will only implement enough of a subset of a Mumble server to allow for quick conference calls. (Mumble certs won't be used for authentication, so you won't have to install certs on your Mumble client.)

The idea is that there is no conference call service running until you need one. And, once you are done, it goes away.

With Confab, you point your browser to the Confab Website, enter a conference start time and you are provided with a server name, a port number and a small once use password (e.g. a23gHYz). The Confab Mumble server (tied to the designated port) doesn't accept connections until the startup time.
Because each session is tied to a unique port number, there is more security than can be offered by a single server with "channels" or "rooms".

You give your participants the server name, the port number and password so they can join. Once people join you can chat(text) or talk(voip). The Confab session terminates after 10 minutes of idleness (no one is talking or chatting). You can also configure an absolute call duration time (e.g. 60, 90 minutes, etc). Each Confab session should support a couple of dozen participants.

Why not just use a normal Mumble server? I want to drop the gaming oriented features, but I plan to add unique server-side features such as:

Voicemail (and text message) capabilities (call in and leave a message for others)

Possible support of POTS (plain old telephone service) bridges

I'm finishing up the basic Mumble-compatible server right now (not yet supporting the above features). It is designed to be lightweight and fairly scale-able. I have no intention on providing or modifying existing client side software.

My server software will be released as open source. I am planning on setting up a small test server on Amazon AWS or Digital Ocean. I'll let you know (here) when it is stood up. If this works out, maybe I can get some donations (Amazon, PayPal, etc) to offset the costs...