Month: July 2015

Yesterday, I had lunch with a friend and had an opportunity to share our summer experiences. The typical response I get when I say I am working on “Internet of Things” and “Smart Homes” is “That is so cool! I would never be able to do CS.”

This friend, keen on knowing more details, asked what exactly a Smart Home is. With vague details, I mentioned that it is a house that can learn behaviors of people and automate certain repeated patterns and can communicate with people living in it.

She raised a question, “So would it turn lights off automatically after averaging out the time I go to bed?” I acknowledged that is one possibility. Then, she quickly asked, “What if one day I go to bed at a different time?”

Yes. This is the nature of humans. More prone to pick out faults then appreciating what works. Even if a smart home correctly learns patterns and does things 99% correctly, people will take it for granted. However, they will pick up on 1% that didn’t meet their expectations.

Machine learning is in a sense an “averaging” process. An “average” is bound to have standard deviation, or margin of error. Will people be generous to accept these margins of error?

Let’s say a student’s bed time is on average, 1:16AM. One day he decides to go to bed at 1:15AM. Will he be patient enough to wait for 60 seconds until lights turn off automatically? And he almost always has coffee right after he takes a shower in the morning, so the smart home brews coffee while he is taking a shower after detecting motion and water usage in the bathroom. What if he decides not to drink coffee that day because he has a stomachache? Will he turn a blind eye to the coffee that was automatically brewed, or complain about wasted coffee beans and electricity?

Recalling the papers on Nest thermostat, people were more unhappy about Nest picking up on exceptional cases rather than it learning the completely wrong patterns. If Nest works as it should, people will gradually forget about the need to control temperature manually, forget that Nest is doing all the work for them, and then get mad when Nest does one thing wrong.

So maybe we don’t want automation. No one’s life follows a fixed schedule to the second 24/7, so there will be that 1% that makes people unhappy.  Maybe all we want is just a house that listens to what we want — as opposed to making decisions on its own —  and obediently follows directions.

Although being tracked doesn’t feel comfortable, today is one of those days where I wish I lived in a smart home that tracked my patterns. Currently my roommate and I are living in a big house with 6 rooms (4 of which are empty) and together in a month apparently used 800 kWh of electricity and had to pay \$160 together. Given that we did not use our air-conditioner, we were very surprised. Since we could hear the air-conditioner running almost all day long from the other side of the house (our 6 rooms are one half of the house), we were wondering if their air-conditioner was connected to ours. We are looking into whether that is true or not. In the mean time, I thought I would do a little research on how much electricity home appliances use to get a sense of what the most likely culprits that drained energy would be.

Below are what I found online as average usage of kWh in households per year:

• Circulating fan =  4 kwh
• Coffee Maker= 9 kwh
• Frying Pan= 8 kwh
• Microwave Oven= 16 kwh
• Self-Clean Oven= 61kwh
• Toaster= 3 kwh
• Blender= less than 1 kwh
• Refrigerator 14-17 cu. ft.= 170 kwh
• Washing Machine= 9 kwh
• Dryer= 75 kwh
• Lighting 4-5 Room= 50 kwh
• Outdoors, 1 Spotlight, All Night= 45 kwh
• Vacuum Cleaner= 4 kwh
• Hair Dryer= 2 kwh

Now I generally get a sense that ovens, fridges, and dryers use a lot of energy. With power meters available, smart homes would be able to tell me where most of my energy use is coming from. It would be even better if it analyzed my living pattern and told me when I use most electricity.

This is exactly what Kamin Whitehouse envisioned — that smart homes would be beneficial for the environment — and I can do nothing but agree. Right now, my roommate and I know that we used a lot of electricity(although we are both usually out working), but we have no idea what to do in order to fix it.

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.

Today we devoted time on finishing up a crash course development for new members to recruit for UPOD. This crash course covers topics from JSON parsing, API, and making HTTP requests, to writing data models in SQL Alchemy. We believe that this will allow for a much more efficient transition for new members.

We also completed writing door sensor models and views. It is up on Helios-dev website. We documented each step taken on Helios wiki, so new members who went through the apprenticeship process can leave their marks by adding a new device to Helios.

Tomorrow we will tackle writing a SmartApp so that SmartThings devices will send data to Helios directly. Professor Kraska introduced to us a Masters student, Giselle, who has a complete kit of SmartThings installed at her house and wrote numerous SmartApps, so we plan show her the system we have and receive feedback.

Overall, very productive day!

© 2018 UPOD Blog

Theme by Anders NorenUp ↑