Jenny and I divided our prioritized tasks for the week. I drew the short straw and ended up with all the Helios related tasks. Thus begins this tale of woe.
Helios (the version running on upod-dev) currently is unable to communicate with Hue lights, and the OpenWeather functionality is also down. While the Hue light logging is working on the local version of Helios — suggesting that the problem is more on the system admin side — the OpenWeather feature is not working on upod, upod-dev and local instances, hinting that the problem is code-centeric.
T-staff says that all the ports we requested to be opened, were already open and functional. The situation is at somewhat of an impasse, and until we learn of new ports to open/configurations to change the Hue problem will likely remain unresolved. The OpenWeather problem hopefully will be simpler to fix (their API is extremely straightforward).
Now for some good news! (Transitions between emotions are abrupt when working on Helios.)
The Helios master branch merged with the multisensor branch bringing about the long-awaited version 2.0 of Helios. This also made it easier to test the door-sensor model for Helios which is also slated for merging. Even better, the door sensor logging is now live and fully functional. By writing a custom SmartApp we were able to make the necessary HTTP requests to get SmartThings and Helios talking. This alliance allows for fairly rapid device addition, and the number of devices available to us will only continue to grow as does the SmartThings platform.
LabRoom security just got an upgrade.
Further, given our new understanding of APIs it will be possible to design an API that taps into the device control functionality of SmartThings, allowing for end-user interface prototyping (getting there will be time-consuming, but it is certainly now in the adjacent possible).
Jenny will be posting later in the week (or to be more accurate — next week) with the progress on the other priority items.
After spending a few days with the new gadgets the following facts emerged:
- The Lenovo laptop has Windows 7 pre-installed. Kinect SDK 2.0 requires Windows 8. Though the laptop came with a Windows 8 OS recovery CD we were unable to get Windows 8 working on it, which makes it of limited use for development purposes.
- The new Surface Pro 2 we got has severe Visual Studio installation issues. It also seems to be stack overflowing — as of writing is has become unusable since only 15 MB of hard disk space is left (our Skype meeting with Blase was temporarily cut off due to this issue).
- The HP tablet we ordered turned out to be our best purchase. It has Windows 8 out-of-box, a decent touchscreen and a great ergonomic keyboard. It’s perfect for deployment and development and currently HomeOS, the Z-wave stick and Kinect are all running on it simultaneously without a hitch so far (touchwood).
In conclusion we’ll probably need to return the laptop and Surface 2, and order more HP tablets in lieu.
Salient points from our meeting with Blase:
- Print out comment cards and run pilot study in lab with Jenny and I as guinea pigs.
- Make crash course for Anavi (which can also later be used for new UPOD members) to get her up to speed on the basics so that she can develop a clean Web-based interface for controlling lights and even answering survey questions.
- Fix Helios Hue light logging to only happen when the light state changes. Like all things Helios this won’t be as straightforward as it should be, and will require a foray into Python’s DB modelling and the Hue API. Currently all data models including lights inherit from a single class and changing the save behaviour for only the lights will require an override — which will also mean looking into SQLAlchemy’s ORM.
Helios dev is back up! The supervisor script had been stopped and just needed to be restarted (followed by restart Helios and nginx reload).
With Helios back up multisensor data is logging (from the Z-wave stick connected to the blue Surface). However, the blue Surface seems to not be recognizing Kinect any more (even when plugged in directly) which is problematic to say the least. To get around these we’re using the black Surface (Surface 2) to log Kinect data. So the LabRoom now has multisensor, Kinect and light data being logged! (One caveat Hue lights are not working on the dev version, though they are on production, but hopefully with the ports open this will be easy to debug.)
We’re also setting up all the new devices we got today, and the Wi-Fi is clogging up a bit but the HP tablet and Lenovo laptop should be ready by tomorrow (which will allow testing of Kinect and Z-wave stick on same machine).
With Helios working again and HomeOS working, we can turn our attention to SmartThings. Jenny got hold of Professor Kraska’s SmartThings details, we’re thinking of writing a door-sensor-to-Helios app for SmartThings as one of the main targets for the week (as that will open up a large number of devices for logging and controlling).
Oh, and we also need to finish reading the API book, perhaps next week.
Several small bugs in Helios were fixed (related to the Multisensor view). Jenny and I had talked about trying to add functionality for trying to make an auto-device-addition-code-generator for Helios but the idea was squashed given the time required vs. the low number of further devices we intend to add (the automation idea could take up to 20 hours while adding a new device to Helios is 1-2 hours).
We also now have to stable test websites for Helios: upod.cs.brown.edu and upod-dev.cs.brown.edu . The dev version is for testing experimental features and allows us to try functionality that’s potentially broken.
Friday deployment at Professor Littman’s house nears…
Having got Helios one step closer to working (the bug is on Nick’s side now) the rest of the day was spent cleaning out the lab (it looks great now…we just need to configure the Hue Tap, and hide the gently decaying walls somehow) and reading up on Kamin Whitehouse‘s research group and their projects.
Whitehouse’s group had several interesting projects underway, and even though they weren’t using machine learning on end-user programming they had stumbled upon some powerful innovations. I want to talk about my favorite so far, the Marauder’s Map.
With the intentions of ending the week well, I decided to go through Mozer’s paper. Our seniors and professor considered this to be a model paper given the extensive use of reinforcement learning by the researchers.
After a quick but brain-boggling look at Machine Learning yesterday, we returned to more HCI oriented papers today. I chose to read CAMP: A Magnetic Poetry Interface for End-User Programming of Capture Applications for the Home (Truong et al.).
The secret to controlling your smart home?
Yesterday we’d asked Professor Littman for a text on machine learning. The result of our query was a hefty tome – Artificial Intelligence, a Modern Approach by Peter Norvig (one of my role-models) and Stuart Russell. The concepts were straightforward enough to understand but the text was littered with forehead-wrinkle-inducing jargon (eg: classification, regression, realizable hypothesis spaces). I managed to get through a section or two, stopping at ‘learning decision trees’; it was slow going especially since I was making a personal (metaphor filled) summary on my research wiki.
Today I waded through a paper outlining the shortcomings of the Nest smart thermostat and its limited success at learning users’ preferences. I also read a long rant from a tech blogger who had tried and failed at basic home automation. The combined (albeit limited) picture I got from the two articles conjured a somewhat bleak status quo for machine learning and user-programming in smart homes. Which of course, is just what an eager young researcher wants to hear (I’ll also try reading some more upbeat literature tomorrow).
It looks good, doesn’t it?