Project Logs

Collapse

• Hardware Block Diagram

  Steven • 06/02/2015 at 18:37 • 0 comments

  Quick and simple update. This is the hardware block diagram, which acts as a rough outline for the entirety of hardware design.

  
  

• Distributed UI Concept

  Steven • 05/27/2015 at 23:49 • 0 comments

  One more design post before I move on to the electronics.

  When we design a UI for a device, the UI is contained within the device. If we think of a house as a device, then, everything within the home should be part of the home UI, which includes light switches, wall plugs, phones, computers, etc.

  There are staple feature sets in every smart home. It is a mistake to try and cram every feature into a single device, the worst offender being a smart phone. Instead, we need to distribute the features into different devices with different form factors in a complementary fashion (i.e., for every additional device, new features are added, and the existing devices are enhanced by the newly available data). This makes sure the features are designed to be accessed in the most convenient locations, and not take away convenience just to trap users into the UI of a smart phone.

  This is the Distributed UI Concept, and this is one of the central design philosophies of my smart home system.

• Mechanical Design

  Steven • 05/20/2015 at 15:38 • 0 comments

  Here we go again.

  As with all my projects, I begin with the design of the physical object based on the functional specifications. In this case, the specs are roughly as follows:

  - Central command, invisible butler, constantly working in the background

  - Minimal user interaction

  - Simple setup process (set up everything with a single action)

  - Contains a permanent power source

  The power supply basically limits the unit to be tethered to a wall in some way. In order to force myself to design a single click user interface, the first concept for the hub was a round, screen-less button, which I called "the puck"

  The next issue was to determine the best way to connect the device to wi-fi. There were two options:

  1. connect to wi-fi through a smart phone (no screen required)

  2. connect directly on the device (needs a screen)

  I went back and forth on these two options for a few months. The biggest problem here was usability.

  Option 1 would be easier from a hardware design stand point. However, the setup process would be slightly more complex (it would not pass the grandma test)

  Option 2 makes the unit more self contained, and will be easier to setup. The extra screen can also bring some extra functionality in the future. The drawback is that the hardware will be much more complex, and a lot more design work is needed to utilize the screen so that it doesn't feel useless after connecting to wi-fi.

  In order to find an "useful idle state" that feels functional yet requires minimal interaction, I went through a few options. In the end, the best option (which turned out to be the most complex) is to disguise the hub as a thermostat. After all, every home has a thermostat, so we might as well put the space to good use.

  And thus, Mk. II was born.

• Philosophy

  Steven • 05/11/2015 at 22:42 • 0 comments

  If the whole point of Smart Homes is to make lives easier, then what is the right approach? This problem is more philosophical than technical, so a philosophy must be established and a set of rules erected and strictly followed.

  Rules:

  1. Never take away what's already convenient for a gimmick. Case in point: Phillips Hue. In order to use the "smart" features on the bulb, the physical light switch must be on all the time. Users are forced to buy a other switch (unnecessary and expensive), or use the Hue app (very slow). Phillips took away the speed and convenience of flipping a light switch for some gimmicks, and it is very frustrating.

  2. Never make users plan what they will or should do at some point in the future, because nothing will go according to plan. This is why schedule and simple rule based systems cannot handle complex scenarios, and will often get things wrong, even if the intention is right.

  3. Remote control is not smart. I can't stress this enough. Shipping a product that let's you do things on the phone and calling it smart doesn't solve any problems. It just add more things for the user to do.

  The most important thing is to delegate as much scheduling, planning, rule making, etc. to a computer as possible, with very little human intervention, which means an A.I. of some sort is needed.

  If we think of the A.I. as a young child trying to learn new things, then some methods of teaching can be adapted, namely:

  - Show through action

  - Learn from mistakes

  Show through action is, simply put, pattern recognition. Humans like to form routines because it's an efficient way of remembering. However, we are going to add some complexity here: when we recognize a pattern, for example, the sequence of lights that are switched on and off, there are other factors that can have an effect as well: time of day, location before/after, number of people in the house, climate indoor/outdoor, etc. Hopefully, with the extra data, the A.I. will be able to read your intentions better, and therefore produce better effects.

  Learning from mistakes is perhaps the fastest way to learn the right way to do things. If we give the A.I. some room for experimentation and make little mistakes that can be easily fixed, (for example, the A.I. can play with the room temperature around the temperature you set it to, to find the upper and lower limit of your comfort zone), then the A.I. can learn faster, be more adaptable, and produce better results.

  In summary, keep things simple, and let a computer do all the work. After all, nothing is impossible in software.

View all 4 project logs