I spend most of my time on the Devices page, which lists all of the devices in all home automation networks on my account.  (Right now I only have a single Z-Wave network, but in theory I could have a potpourri of different networks that include other existing home automation frameworks, IR transceivers, and—I dunno—USB missile launchers?)

Anyway, the UI all works, and dynamically updates when a devices state changes.  Cool!

After merging all of Roomie’s desktop and web components into one self-aware Visual Studio solution, learning a ton of new technology, and a little trial and error, I now have the Roomie desktop client talking directly to the new website.  Best of all, I can locally debug everything which means that I can get quicker feedback on code changes and (shrug?) even develop offline.  Below I have a simple example pictured.  A more impressive example is when I tell the Roomie desktop client to say something using text-to-speech, but obviously that would not convey over a screenshot.

The Roomie desktop client communicates with the Roomie web service using a custom protocol that I developed.  Both the server side (web service) and client side (Roomie desktop client) reference the same Visual Studio project to do the communication, so I am guaranteed protocol agreement.  It’s really satisfying to add some functionality or refactor in one place and have the changes propagate to every related component.

Yaaaaay programming!

Needless to say, I was daunted by the huge task of migrating the whole Roomie website over from an old technology.  I also wanted to take the opportunity to learn more about CSS, and JavaScript, jQuery, AJAX, LINQ, the .NET Entity Framework, and anything else that I didn’t know I needed to know.  All of that is still in progress, but I am not to the point where I have started a new website, though it is not live yet.

Pretty!

Here’s a sample of the main layout using the Razor view engine:

But enough technical talk.  Lets get to serious business.  Here I have a little RoomieScript that I wrote, just as a proof of concept.

<RoomieScript>
  <ZWave.PowerOff DeviceName="Coffee Pot" />
  <Core.Loop>
    <ZWave.WaitForChange DeviceName="Coffee Pot" PollInterval="5 Seconds" />
    <ZWave.PowerOff DeviceName="Coffee Pot" />
    <RoomieBot.TextDavid Text="No coffee!" />
  </Core.Loop>
</RoomieScript>

Here Roomie waits until the coffee maker is turned on, then turns it off and sends me a terse text message. Yes, it works!  And yes, I do use Roomie for legitimate things, but ah… it’s so just that much fun to be dumb.

Interested in beta testing Roomie?  Send me a message.

As you can see above, I have the Roomie website’s main page displaying on an iPad.  The first two controls are an example of the new feature.  Before I go to bed I might want to click the “set alarm” button, which would run a RoomieScript that I wrote that wakes me up in the morning.  The same deal goes for coffee. (Of course, making coffee is also part of the alarm routine.)  It would be easy to imagine many other virtual devices.  Eventually I will likely make a “basement” device, which would have buttons like “Movie” for nice movie lighting, “all on”, “all off”, and of course, “PAAARRTAAYY!”

I mentioned that these controls were highly customizable in code.  In the C# code-behind I can set the size of these controls with pixel precision.  That came in really handy when I made an iPad-specific page, which resizes the controls to be just the right width to fill the screen horizontally and high enough for easy pressing with a finger.  A tweak of the sizes only takes a few seconds.

All of this has been a really good learning experience for me, and of course I am far from done.  I’ve applied so much of what I’ve learned writing Roomie, which is just for fun, to other projects at work and in school.  If you want to help test Roomie, send me an email.

I was making some very benign changes to the navigation bar on the left side of the website, when I refresh the page to see the “on/off” buttons interchanged for the favicon (stretched horribly, of course).  I refreshed the page in Chrome, verified the URL of the image, and finally looked at just the image.  Then I looked at the URL.  The favicon?  How strange.  I viewed the URL in Firefox, and saw the correct picture.  Next I viewed the URL in Incognito Mode in Chrome.  Again the correct picture.  How could the image appear differently?

I can’t be sure, but I think the problem could be with Google Chrome’s updating mechanism.  After trying various troubleshooting techniques, including restarting the browser, I went to the about page to see if the thing had updated.  It seemed like it had, but to make sure I went to my laptop.

So that seems to be it.  Restarting and/or clearing the browsing cache fixed the problem.  It’s nice that Chrome updates so transparently, but apparently it doesn’t always work perfectly.

This morning RoomieRemake woke me up with two short scripts.  And hey, more news!  I used the recently-updated website (which I’ve apparently never directly blogged about) to write the scripts.  Here’s a screenshot of that.

Here’s the script that ran on Dreaming Nest, my Home Server, which has a ThinkStick USB Z-Wave controller.

<RoomieScript>
  <Timing.WaitUntil Hour="8" Minute="50" />
  <ZWave.PowerOn DeviceName="Coffee Pot" />
  <Timing.WaitUntil Hour="8" Minute="59" />
  <ZWave.PowerOn DeviceName="Monitor and Speakers" />
  <Timing.WaitUntil Hour="9" Minute="15" />
  <ZWave.PowerOff DeviceName="Coffee Pot" />
</RoomieScript>

Here is the script that ran on Rory, the desktop computer in my bedroom.

<RoomieScript>
  <Timing.WaitUntil Hour="9" />
  <Output.OpenFile Path="F:/music/playlists/Driving in Spring.wpl" />
</RoomieScript>

I’m not sure why I instinctively personify computers as needy and with low self esteem, but anyway…

In rewriting Roomie, I built up the infrastructure in the core engine to allow me to easily add commands.  In the old Roomie, I tried to organize commands’ code as best I could, but I still ended up with big files with lots of functions, and a hulking switch statement at the top.

Here is the switch statement for the Z-Wave commands code file:

There was also another junction point higher up the line that would decide which kind of command was being called.  In RoomieRemake, I do things a bit more generically.  Every command is represented by a class, which all derive from a “Command” class.  That means I can just have this:

As I continue development I will optimize things like command selection, but the point here is that I don’t have a whole bunch of special cases for different kinds of commands.  This is just part of the code that makes a command run, of course, but part of the redesign included breaking up functionality into neat, orderly bundles.  The master list of commands is populated dynamically with reflection.

A big time-waster in the old Roomie was validating variables, so in my new approach that is all handled in the definition of a higher-level “Command” class, while subclasses of Command register what arguments they expect, their types, and even default values if applicable.

Here is the old code for the ZWave.PowerOn and ZWave.PowerOff commands.  Look at all of the duplicate code.  Several times after redesigns I would have to go and manually change many lines of very similar code.

Comparing that to the new approach, here is the ZWave.PowerOn command:

By the time the command class is actually defined, Command has been abstracted into ZWave command, which has been further abstracted to SingleZWaveDeviceControlCommand.  Verbose, sure, but by the time I get to defining the command, I know that all of the validating of variables and finding of the device and connecting to the ZWave controller have already been taken care of.  Plus, if I ever want to add functionality to a group of similar commands, I can just write in the code in a parent class’s definition.  That’s inheritance and type safety at work.

You might have noticed that I didn’t include the whole method signature in the above screenshot.  That’s because it’s reaaallly long.  Some might see this as a disadvantage, but a big problem I had with the old Roomie is not having enough information to work with to make the proper decisions.  Basic commands recieve as arguments the CommandInterpreter that is calling them, a Scope object that represents the nested scopes containing variables, and an XmlNode containing the original command XML.  (Did you remember that RoomieScript is an XML based scripting language?)

That Z-Wave command was already really abstracted, with arguments defined in higher abstract classes, so here’s an example of a command that derives directly from Command:

Here the constructor calls a method defined in the Command class that defines an argument of type String.  By the time Execute_Definition is called, the engine has already verified that the Text argument is specified.  If there’s a problem, the engine reacts appropriately.  The CommandInterpreter, which represents a thread, doesn’t care about all of these extensions to Comamnd, of course.  It simply calls the selected command’s “Execute” method, which is concrete in the base Command class.

Finally, here’s a shot of the two Solution Explorer windows.  On the left is the old Roomie, and on the right is RoomieRemake.  You can see that in the remake, extra functionality is in other projects, which RoomieRemake hooks into as plugins at runtime.  That way, anyone could write a pluggin for Roomie.

SO that’s what I’m working on.  I hope to release this sometime in the near future.  If you’re interested in testing, either Roomie or Arcadia, shoot me an email.  If you think I’m a huge nerd, well you’re wrong.  I’m more accurately a gigantic geek, but you could call me a dork anyway.

(link)

<roomieScript>

  <!–  this sends a script to the Desktop Computer  –>

  <!–  it’s really just to confirm that both computers are turned on  –>

  <webScripts.sendScript targetComputerName="Desktop Computer">

    <speak>

       

         all set!

    </speak>

  </webScripts.sendScript>

  <!– wait until the morning  –>

  <waitUntil hour="6" minute="0" second="0" />

  <!–  send a script to Home Server to handle the lights –>

  <webScripts.sendScript targetComputerName="Home Server">

    <!–  dim the Door Lamp and Desk Light on slowly and simultaniously  –>

    <insertScript runInNewThread="yes">

      <!–  dim the Bed Lamp on faster than the Bed Lamp  –>

      <zWave.slowDimOn module="Bed Lamp" durration="280" />

    </insertScript>

    <insertScript runInNewThread="yes">

      <zWave.slowDimOn module="Door Lamp" durration="120" />

    </insertScript>

    <!–  wait an hour and a half, then turn off all the lights  –>

    <waitFor seconds="5400" />

    <zWave.powerOff module="Desk Light" />

    <zWave.powerOff module="Door Lamp" />

    <zWave.powerOff module="Bed Lamp" />

  </webScripts.sendScript>

  <webScripts.sendScript targetComputerName="Desktop Computer">

    <!–  wait three minutes after the light dimming has begun, then play music  –>

    <waitFor seconds="180" />

    <openFile path="F:/music/playlists/Wake Up.wpl" />

  </webScripts.sendScript>

</roomieScript>

Here’s a video:

YouTube link