Friday, October 24, 2014

Trying out HouseAgent

For the last couple of years I've been looking for some Home Automation software to run the hardware that I'm slowly building to automate my house. There are so many choices that I'm not sure where to start.  I discovered HouseAgent mostly because it's written in Python, and I really like Python, so I thought I'd give it a test drive.

HouseAgent is a python-based home automation tool, with a promising architecture.  It appears that plugins are separate processes that communicate via AMQP, which means they can be written in (almost) any programming language.  It has a web interface, and a simple rules engine.

I installed the latest daily build of House Agent on a Windows 7 machine and ran into some problems.  The main problem was that it wouldn't launch.

After poking around for a while I figured out that you could run the House Agent daemon at the command line to get more info.  Just run 'houseagent.exe debug' to display debug messages.  I quickly discovered that there were files missing, namely houseagent.conf.  I grabbed these files from the git repo and put them in the places the error messages referred to.  The next error I had was that the port it was trying to use was already in use (8080) so I changed that in houseagent.conf.

At this point House Agent successfully launched, and I could get to the main web interface.  Then I went to the git repo for the JeeLabs plugin and grabbed all of the files there.  There wasn't any documentation so I made a directory called JeeLabs in the plugins folder in the House Agent install directory and copied all the files from the git repo there.  I then restarted the HouseAgent daemon and was able to successfully add a JeeLabs device.

I stopped at this point since I'll need to actually tie in some JeeNode hardware to continue my investigation.  There is a .conf file in the JeeLabs plugin directory that can be used to set the COM port to use and various other things.

There is also a fork of the JeeLabs which appears to be a little more up-to-date here. Even with those changes, when compared to another more up-to-date plugin, like ZWave, it looks like the JeeLabs plugin has been somewhat abandoned.

The web UI is also pretty plain and if I decide to use HouseAgent I'd like to modify it to look a little more snazzy. Right now it looks like an "admin" interface, rather than one that a user would really appreciate.  There does seem to be a branch where someone is working on mobile interface here.

At this point I kind of gave up since it seemed like getting HouseAgent to run was just fixing one bug after another.  HouseAgent seems like a great architecture but would probably take too much time and effort to make usable.

Pros:
  • Written in python (yeah!)
  • Good plugin architecture
  • Web-based UI
Cons: 
  • It doesn't look like HouseAgent has been under active developement in several years.  Has the project been abandoned?
  • In general, it appears to be a little rough around the edges
  • Web UI is a little ugly and not mobile friendly

Wednesday, October 22, 2014

embeddedWorld 2014

I was lucky enough to get chosen to speak at embeddedWorld 2014 in Nuremburg, Germany.  I gave a short presentation on using Yocto to develop a commercial product.  If you're not sure what Yocto is, don't worry, most people don't; it's a tool that helps Linux run on embedded hardware (like your WiFi router, for instance).  Rather than talk about a bunch of technical stuff I'll just stick mostly to just how the trip itself, impressions of Germany, etc.

General Observations
As I was flying from Dusseldorf to Nuremberg, I could see at least 4 nuclear reactors, quite a few windmills, and lots of solar panel installations (many on the roofs of houses and businesses and some empty fields with lots of solar panels in rows).  I also noticed lots of large-scale greenhouses in the farm fields, I couldn't tell if these were permanent installations or just temporary structures built over top of farm fields.  At least from the air, Germany looks very "green".

Once I got to Germany, the language barrier was not a problem at all.  I'd been told that there were alot of English speakers in Germany, but it really seemed that everyone spoke English.  It was funny too because most people would say "my English is not very good" and then they would go on to speak nearly flawless English.

Germany just felt very comfortable to me for some reason that's hard for me to articulate.  And I guess the Germans thought so too, because they almost always would initially speak German to me, until I asked "Sprechen Sie Englisch?".  The other people that came over with me from the States would usually get English right off the bat from the Germans they met.

We had several people also attending the conference from NI's Munich Office, and they were outstanding hosts, taking us to dinner each night and generally helping us out in any way.

I also found that business etiquette was a bit different:
  1. It's expected to wear a suit and tie, the US standard of a button up shirt and khakis doesn't cut it.
  2. Don't be late.  You'll get some very disapproving stares if you aren't punctual.
And this should surprise no one: Germans know beer.  Every beer I had there was excellent (and I had quite a few).  Don't worry about getting something you won't like; just drink it and it will be good.

I didn't have any time for sight-seeing so this is a crappy pic I took in downtown Nuremburg


Embedded World Exhibition Floor
The Exhibition part of Embedded World was crazy-huge, with 856 exhibitors and 26,000+ visitors.   It took me a long time just to do a relatively quick walkthrough of the floor.

I kept my eyes open for any LabVIEW front panels and I saw quite a few.  One of particular interest was a cool looking demo from Intel.  It's a slightly creepy looking insectile robot that plays the Chinese mandolin (not sure what the real name of the instrument is).  You can see the LabVIEW front panel on the monitor in the picture below.  The Intel guy running the demo couldn't say enough good things about developing in LabVIEW.



Presentation
My presentation went really well.  Almost every seat was filled; probably around 50 people.  I got some good questions and some compliments after it was over.  I also talked for a while with a couple of Intel guys that are heavily involved in the Yocto project.

Flight Back
The flight back was the only negative part of the whole trip. Coming in through Customs Stateside is no fun.  'Nuf said.

Wednesday, October 15, 2014

First open source patch accepted

I was about to post about my first patch accepted to an upstream open source project, but then I started digging around and discovered this one was actually my first!

I'm not trying to toot my own horn (ok, I am a little), I was just proud that I actually have some small, insignificant bits of code contributed to the open source community.

If anyone is remotely interested the first patch is to the Busybox project to fix a bug whereby a linked local network interface will keep getting a different IP between reboots when it should be getting the same IP on subsequent boots.  I can see your eyes glazing over...

The second patch is to the Yocto project and has to do with the generated entropy on an embedded Linux system.  Basically, if there's not enough entropy in the system then random numbers become much less random which can be a security risk if those random numbers are used for something related to cryptography.

And I guess to add to that I have lots of commits submitted to repos here and here, but those are repos owned by the company I work for so I wasn't counting those.




Wednesday, October 30, 2013

Wolverine claws for Halloween

A friend is wearing a Wolverine costume for Halloween, and he asked me to help him make some wooden claws.  He wanted them made out of thin (brittle) wood so no one would mistake them as actual weapons.  Although we haven't tested them, we're pretty sure the claws would break very easily if anyone tried to use them as a weapon.

I didn't think to take any pictures while we were making them but here are the final results:



Sunday, February 03, 2013

Scale results, round 2

I made a second run on my scale tester.  This time I used a 10KOhm thermistor as my temperature sensor.  This gave me around 0.15 degrees (F) of resolution, compared with the 1 degree resolution of the previous temperature sensor I used for the last test run.



Figure 1: Weight and Temperature vs. Time

The first graph this time is the usual weight and temperature over time.  You can see that the weight and temperature appear to be highly correlated just like the first test run. The other thing is that the temperature appears much less noisy then in the previous run.

Figure 2: Nominal weight minus weight vs. Average temperature
In Figure 2, I graphed the delta in weight vs nominal against a moving average of temperature.  I also threw down a best-fit linear trend line.  I can immediately see that the point cloud is much tighter than in the previous test run, which seems good.

Figure 3: Adjusted weight

The last graph is a plot of the weight reading adjusted by the trend line equation from Figure 2.  The ideal line is a straight line at 55 lb. Clearly the line is not straight but it certainly improves the data.  The weight reading varies by +/- 0.2 lb instead of +/- 0.75 lb for the unadjusted weight readings.

Conclusions

The adjusted weight did not seem much different from the previous test run, but it still seems useful.  I think I can now go on to implement the data logger for this project which will convert weight and temperature sensor readings to specific gravity.

There are still some unknowns here.  One is that the test runs have only been run on a constant 55 lb test weight.  It's certainly possible that the numbers will change if a different weight is used.  It might be worth re-testing with weights of 45, 65, and 75 lb weights.

Additionally, there seems to sometimes be a lag between temperature changes and weight changes.  This could be attributable to the temperature sensor and scale having different thermal mass, which is almost certainly true.  I could account for this by attaching the temperature sensor to the scale with thermal paste to ensure that they are at relatively the same temperature.

Tuesday, January 22, 2013

First scale test results

I took some time to analyze the results from my scale test.  If you like graphs, then keep reading.  If you don't like graphs then skip to my conclusion at the bottom.  I happen to like graphs...

To summarize the previous post, I wanted to see if there were two effects happening to my fancy new RS232 scale: 1) temperature and 2) sensor drift (or creep).  The easiest way to track this was to measure the weight of an object with a constant mass over time, while also measuring temperature over the same time span.  I did that and now have a week's worth of measurement data to sift through.

Figure 1: Temperature and Weight vs. Time
First I graphed weight and temperature each versus time.  Figure 1 shows this graph.  You can immediately see that the measured weight correlates closely with the temperature, so clearly I was right that there is a temperature effect.  The second thing to note is that the weight line shows clear quantization, but this is to be expected as the scale only specifies to have a 0.1 lb resolution (but it's still nice to see it clearly in the graph).  Another thing to note is that the temperature is pretty noisy.
Figure 2: Average Temperature and Weight vs. Time
Figure 2 is the same graph but with a moving averaged temperature.  Perhaps a "moving average" is not the correct term for this; I never did much with formal statistics.  I basically just calculated each reading by taking the mean of the previous 6 readings.  You can see the temperature line looks much less noisy now and the correlation between temperature and weight still remains.

Figure 3
My next task was to try and figure out the mathematical relationship between weight and temperature, so that I can then (hopefully) correct for temperature and get a more accurate weight reading.  The graph for weight versus temperature is shown in Figure 3.  There are several interesting things here.  The first is that you can see that both the weight and the temperature are quantized since all the blue points in the graph come out on grid lines.  The next thing to note is that the point cloud is pretty widely distributed (which isn't good).  I had Excel generate a best fit linear trend line.
Figure 4
Next up I repeated that graph (Figure 4) but with the the averaged temperature data from Figure 2.  Now you can see that the quantization in the temperature data has disappeared but remains for the weight, which is what we'd expect.  The trend line has changed a little based on this adjustment.  I also threw a 6th order polynomial fit trend line on the data to see if that would fit the data better, but as you can see that is nearly a straight line, so we'll stick with the linear fit line for future calculations since it seems to be a pretty good approximation (at least compared with a polynomial fit).
Figure 5
Now from this we can use the calculated trend line to create a mathematical attempt at canceling out the temperature effect of the scale readings.  Figure 5 is a graph of the temperature-adjusted weight plotted over time.  The ideal line would be a line that is constant at 55 lb.  The adjusted weight line is clearly not a straight line but if you compare it to Figure 2 we have certainly made an improvement over the raw weight readings.

As it stands this temperature correction is probably useful enough that I could start using the scale for continuous weight measurements, however I'd like to make it better if I can.  I think one improvement I can make (which I mentioned in my previous post) was that my temperature sensor has pretty low resolution (about 1 degree Fahrenheit). I suspect that having a sensor with 0.1 degree resolution would help, and might bring the point cloud in Figure 3 into a tighter cloud which would make the generated trend line more accurate.  So now I'm going to start looking around for a more suitable temperature sensor (I might already have one on hand in my parts library) and re-run the test to gather fresh data.

Zeo sleep monitor




My wife got me a new toy for Christmas this year, a Zeo Sleep Monitor. It's a device that fits on your forehead while you sleep and measures your brain waves while you sleep. Based on your brain waves it logs what phase of sleep you're in (light, REM, deep, or awake). I got some time to try it out a few nights ago and I was pretty impressed!

Above, you can see a screenshot from the app on my phone. You can see for yourself what each of the colors means on the graph above.  The fun thing to note for me is that it lines up perfectly with what happened that night.  At around 1AM (the second set of red lines) my dog woke me up to be let outside.  Then around 2AM my wife woke up which woke me up for a little while.  Then at around 6:30AM my wife woke up to get ready for work which again woke me up.  So that correlates the data with reality nicely.

The interesting things in the graph are what I wouldn't ordinarily be able to determine for myself, namely differentiating between light sleep, deep sleep, and REM sleep.  I find this pretty fascinating.  I think this also means that I don't have sleep apnea (or at least not this night), since I would assume there would be many more red lines throughout the night.

I'm going to keep using this as much as possible for the next few weeks to get an idea of what my sleep habits look like over time.  The Zeo Android app also has another feature whereby you can set an alarm and the app will try to wake you when you're in an optimal sleep state.  This works on the theory that you feel better and more alert if you're awakened when you're in a light sleep state.  I haven't tried that feature yet, but I will soon.

When I find some time I'd like to find a way to use the Zeo sensor to monitor my sleep cycles and when I'm in a REM sleep cycle trigger subtle lights or sounds that might allow me to experience lucid dreaming.  I found this Android API which may aid me in doing that.

Update: I tried the alarm feature last night and it is amazing!  It delayed my wakeup time by about 15 minutes to wait for the REM cycle I was in to end.  I woke up feeling fantastic!  I may have to start using it every night.

Wednesday, January 09, 2013

Testing an RS232 scale

To further the experiments I've been doing with measuring specific gravity, I needed to take long-term continuous weight measurements (5-10 days total). I started searching for a scale or load cell that would be appropriate.
My specific use case involves monitoring the weight of an object in the range of 50-70 lbs for 2 weeks.  Since we have a heavy weight on the scale for a long time a problem that could come up is sensor drift (also sometimes called creep).  This effect is similar to what happens if you hang an object from a suspended spring.  Over time the spring will slowly deform.  The rate of the deformation depends on many factors like the weight of the object and the physical properties of the spring.  The same thing happens with a scale.  Although mechanically different from a suspended spring, in many other ways it's very much like a spring.

Another factor that can throw off the readings from a scale is temperature.  As the temperature changes the properties of the components in the scale also change.  If these changes aren't compensated for in some fashion then they will affect the scale's readings.

I initially tried to measure a 55 lb test weight using a 75 lb maximum capacity digital scale.  Within minutes the scale's readings started drifting.  I assumed that this was probably due to creep and was probably so prominent because I was weighing something close to the rated capacity of the scale.  This scale also had the additional failing that it did not have a way to communicate externally (which as you'll see soon was an important requirement) so I decided to look for a different scale.

I reasoned that if I found a scale that had a maximum capacity that was significantly larger than object I was weighing, then it might not display significant effect from creep (or at least for the 2 week period that I needed continuous readings).


Luckily I found a 300 lb capacity shipping scale (MyWeigh HD-300), and a well-written tutorial from Adafruit.  This scale was a little more expensive than what I had in mind, but it's worth the price considering all of its features:
  • 300 lb capacity
  • RS232 communication
  • ability to disable auto-off (most scales turn off automatically which sucks for continuous measurements)
I quickly started an "eyeball" test by again placing my 55 lb weight on the new scale.  I kept a log book near the scale and roughly every 60 minutes I would write down the time and the displayed weight.  I left this experiment running for about 4 days.  I should note that I didn't stick to the 60 minute test interval that closely.  Sometimes I would leave several hours between readings, sometimes it was more like 30 minutes, and I didn't wake up to take readings in the middle of the night; I like science but I like sleep more.

The results of this test told me that something was causing the displayed weight to vary by about 1 lb over the course of 4 days.  I had a suspicion that temperature was causing much of the variation (the weight would be lower when it was cooler in my house and higher when the temperature was higher).  I couldn't really tell if there was any effect from sensor creep.

Next I decided to repeat the above experiment but make it a little more scientific.  For this run I wanted to run for at least 10 days and gather temperature and weight readings every 10 minutes.  Of course, this is exactly what computers are made for.

The test set up consists of a python script running on an old laptop.  The script communicates with the scale via its RS232 interface to gather weight readings.  To get the temperature I decided to use an Analog Devices TMP36 sensor that I already had on hand.  Coincidentally, Adafruit had another tutorial on using this sensor with an Arduino.  I used some of the ideas from the tutorial but wrote my own Arduino firmware to make it act as a serial thermometer.

The test script on the laptop was modified to also query the Arduino for the temperature and log the returned value along with the measured weight value to a file every ten minutes.  

The test setup from left to right: laptop power supply, USB wifi dongle, scale control box, laptop, plywood to act as stable platform for scale, Arduino with TMP36 sensor, MyWeigh HD-300 scale with 55 lb test weights
I put the source code for the python test script and the Arduino firmware on github.  Keep in mind that the script was written to run on Windows and would need to be ported to run on another operating system.  Also, since I implemented the script very quickly I didn't spend much time or effort on error checking so it's not very robust in that respect.  You have been warned.


At this point you may be wondering why I didn't just use the Arduino by itself to do the data logging.  I have a few reason for that:
  • I needed a circuit to convert the RS232 voltage levels of the scale to TTL voltages that the Arduino can understand.  I already had the hardware to do that but I didn't want to waste time assembling it when I had a laptop with a perfectly good RS232 port available.
  • I didn't have an Real-Time clock to keep track of time or anything to use for large data storage (SD card socket).  The Adafruit data logging shield would have been ideal for this but I didn't want to wait to run the test.
After I was half way through implementing the test I realized that the TMP36 sensor used in combination with the Arduino's 10-bit resolution ADC only gives a resolution of about 1 degree Fahrenheit.  I would have preferred to have 0.1 degree of resolution but decided to run the experiment anyway and see how the numbers looked.

I'll create an additional post with the results from the first test run.

Improved Security Node

I've spent some time recently polishing the Security Node demo I made a while back to the point where it is no longer a demo.  It's now installed and functioning in my house.

Here are some of the changes:

  • Integrated catisith2's keypad interface code
  • Added logic so alarm system is run completely by the JeeNode
  • Replicated original functionality of the DSC alarm control board
  • Added circuit to control the (very loud) siren
  • Send radio packets when events occur (alarm, arm, disarm, doors open/close)
  • Handle remote commands via radio (mainly arm/disarm commands)
  • Made a small "cheatsheet" with all the commands to attach inside the keypad panel

I've update the source code in my github repo.

I'm pretty satisfied with how the Security Node turned out but I have some things I'd like to change:

  1. The alarm system runs fine locally but my ultimate goal is to have an external interface so I can receive texts when events occur and remotely arm/disarm the system.  I'm still trying to figure out how I want to do that.  JC Wippler is doing some interesting research along these lines.
  2. There isn't much security with the arm/disarm radio messages, though I could encrypt the radio traffic pretty easily.
  3. The final board works well but it looks ugly.  I'd like to redraw everything in EagleCAD and have a proper PCB made.
  4. Adding a battery backup so the alarm will still work when there is a power outage.
Here are some pictures:

Security Node without JeeNode installed

Security Node installed

Keypad communicating with JeeNode