xPL sCU

I actually finished this app before xPLHALi. It's an xPL-starCOMUltra bridge. It was extremely easy to build an app to do this since all the events and methods worked as they were supposed to. Since I only have a TimeCommander+, I have not implemented the phone, alarm and tstat features of Stargate. My app generates xPL stat.basic messages for changes to timers, variables, flags, relays, digital and analog inputs and ASCII output. It generates remote.basic for IR generated and x10.basic for X10 commands issued. It accepts control.basic to set variables, flags, relays and user variables, x10.basic to send X10 and remote.basic to have sCU issue IR commands.

In the screen cap below, you can see in the DCM xPL logger that a command was sent to my app to set a flag. It set the flag in starCOMUltra and generated a status.basic message in response to the set command. There is also another status.basic message for a flag that sCU set on its own. Finally, I issued an IR command through my app and you can see the remote.basic xpl-trig generated in response. You can also see the events issued by sCU in its window.

More HAL Bugs

Hard to imagine I've been playing with HALi for about a week and I keep finding problems. Why does the SensorStateChanged event fire even though the sensor was set to the same value (it hasn't actually changed)? This brings me to another problem, which uncovered this one.

I have a simple rule NewVM that should set a flag when I have new voice mail. If a call comes in and the caller leaves a voicemail, this rule fires 3 times! Why?

NewVM
IF:
  NewVoice Message in All Mailboxes >= 1 (TE)
THEN:
  SetFlag NEWVMAIL to TRUE

On the other hand, if I have no voicemail, I want to clear that flag via this rule:

NoVM
IF:
  NewVoice Message in All Mailboxes = 0 (TE)
THEN:
  SetFlag NEWVMAIL to FALSE

What's retarded about this is if you playback all the messages and have them automatically changed from NEW to SAVED, this rule doesn't trigger despite there being no more new messages. Also, if you delete all messages from the phone pad app the rule still won't trigger. If you delete new messages one at a time from the phone pad it finally does trigger.

I came up with these rules so HAL generates events that my xPLHALi app can translate to xPL messages, informing other devices/apps in my system. But HAL can't actually generate a reliable NEWVMAIL flag so it's pretty much useless to me.

HAL guru posted on the HAL message board that a "new" feature in 4.0 will be ability to check if something actually changed! HALi 4.0 now won't waste extra CPU cycles generating the same events for things that haven't actually changed. Hooray. WinEVM for my TimeCommander+ added that feature in 1997.

My First VB.net App

I've been testing out the VB.net app I wrote despite the problems I was finding with HALi. I ended up writing an xPL bridge to HAL and called it xPLHALi (I know, it will be confused with xPLHAL, but only if I release it). I started off using xAP but stopped because I wasn't sure how to go about implementing subUIDs for all the HAL sensors, since each would be it's own target in xAP. I figured it out later so I may finish it at some point. Anyway, here's a screen shot of the xPL logger of DCM showing the messages generated by my app. You can see status of what's going on in the application window. HAL sensor events are generated as sensor.basic messages and can be changed by sending control.basic messages to my app. Not sure I'll release it as I haven't figured out how to bundle it all up and I don't think people who use HAL know what xPL is. It is useful to me however. I am no longer limited to HAL's point and click interface to create tasks. I'll write my own VBscripts in xAP Floorplan (its built-in xPL bridge makes me not sure I'll need to create a xAP version, especially since I run a hybrid xAP/xPL system anyway).

Differing Opinions on Software Development

I was having a heated discussion with a HAL "guru" over on their forums regarding the silly bugs I was finding in HALi. Basic properties like Sensors.Timer and Sensors.Counter are broken and completely untested. I asked why Automated Living doesn't have a regression test these basic features and I was told by "guru" that testing is not worth a developers time, developers don't have time to do any testing, regressions would be thrown away every major release, and it's better to just throw the software to the public and let them beta test than to do any extensive testing in house.

QA engineers cost just as much as software engineers ($95k average vs $115k average in Silicon Valley) so it's absurd to assume software engineers are too expensive to use testing their software. Not only that, who do you think would have a better idea on how the software is supposed to work? Any testing they can do would be huge benefit. Also, HAL guru feels it's not even worth testing HALi if the test engineer doesn't understand "Visual Studio, including C#, C++, Visual Basic. And also understands Perl, VB Script, Java Script and HTML." That's quite a list. I wonder if AL really has developers that understand all that. Funny thing is the bugs found were using Visual Basic and jscript - and those bugs would be found in ANY language.

Furthermore, most HAL users are out of the box users. They're not going to be programming in C# or C++ - more than likely VB and VB Script. Why not write regressions in the languages that will get the most use? Especially if you can't cover ALL those languages above. Better to test something than nothing right?

For over 14 years, I've worked in "large" (1000+ employees), medium (200 employees) and small (20+ employees) Silicon Valley companies in ASIC design. I know software engineers have down time between major releases in every company I've worked at. It's the same for all my friends & old co-workers at other companies too. HAL guru says AL engineers don't have down time between major releases. "Hummmmmmmm...."

How are regressions a bad thing? Imagine if I had a script that tested all the basic objects and methods:

flagCount = HAL.Sensors.flag.Count;
varCount = HAL.Sensors.Variable.Count;
ctrCount = HAL.Sensors.Counter.Count;
timCounter = HAL.Sensors.Timer.Count;

etc.

Then, it would have been REALLY easy to see that the Counter and Timer properties aren't even functional. HAL guru insists such an effort will be tossed in the next major release but claims that everybody who wrote HALi apps will be able to just "update the HALi reference and recompile". If that's the case, how would a script like above be a waste of time? It wouldn't even have to be compiled and you'll have the benefit of testing all the features from previous releases that are moving forward. Sounds like a no-brainer to me.

HAL guru is very fond of public betas with minimal or no internal testing. But public betas are like random testing - there's no guarantee that these end users will even exercise 10% of the code. Especially since HALi only has a handful of active users. How good is the quality of their testing? How can you measure what they've tested? Sure it's "free", but at what cost?

On the other hand, if you have a QA engineer creating a testplan of DIRECTED tests for the basic methods, events and properties you know what's being tested. You get the low hanging fruit out the way. This helps your beta testers be more efficient as they're not thrashing with bugs on basic features. This keeps your software engineers from going into panic mode when you release a crappy beta and there are 25 bug reports a day coming in, many of them the same filed by different users. Plus you leverage the regressions written for future releases. Also, your QA engineer works with the developers to find what else there is to test, features/behaviors your random beta testers have no clue about or care about. You'll have a shorter beta, get product to market sooner with better quality and you'll have happier customers. That doesn't sound bad right?

Learning VB.net

I've been playing around with the free Visual Studio 2008 Express learning how to create an app in VB.net. I started off trying to do something with HAL and it's HALi ActiveX interface. I've already uncovered a couple bugs in HALi - fairly basic features - that somehow have made it through all the beta tests that started in 2003! It's bad enough I'm trying to learn Visual Studio and VB.net, I'm uncovering bugs in basic features. Now I'm going to have to figure out how to work around these bugs and restructure my code.

Installed Rain/Freeze Sensor

While work was closed for the holiday shutdown, I did one more thing to the system, adding an Orbit Rain/Freeze Sensor. It's connected to a DS10A and relays to the system whether or not to turn on the sprinklers. I've been mainly relying on weather forecasts to control the sprinklers but this adds an extra data point, especially since we're having voluntary water rationing in our area.

I'm back at work now, so updates will be as sparse as before. It was a productive week and a half though.

More Needed Maintenance

We're using the CheaperTronics 8 meter RFID transmitters for vehicle tracking. The problem is they are really sensitive to voltage levels and as the 2032 battery output drops, the transmitters start dropping out. The batteries become useless after several months so today I picked up some AAA battery holders from Radio Shack. I soldered the battery holder wires to the transmitter circuit board loaded it up with a couple batteries and rubber banded it to the case. They work great now. We'll see how long the batteries and reliability last.

Back to 2000

After doing the Audrey upgrades, I decided to update the rest of my hacks from 2000. We still have the Series 1 TiVo which was hacked back then when a 30GB drive was added to the 14GB original. Later the 14GB drive died and the 30GB was made the lone drive. This time around I added an 80GB drive to bump the capacity up to 128 hours.

Today, I got rid of Win98 on the I-Openers I had hacked and took out the hard drives. Since I was only using these as digital picture frames, I didn't really need a full OS and all the functionality. I loaded the internal flash with the Midori Linux build from here, loaded pics on a USB flash drive and put everything back. Now, it's much quieter without the hard drive and more reliable given that those HDs were refurbs (they have lasted a long time just fine though).

Summary of New Audrey Hacks

This is just a note to myself to document the hacks I added to the Audrey:

Enable access to Audrey internal web server http://www.3rdmoon.com/crusso/audrey/remotecontrol/remotefrompc.htm
Edit file /config/rm-apps, change this line
rb,/kojak/kojak-slinger, -c -e -s -i 127.1
to look like this
rb,/kojak/kojak-slinger, -c -e -s

Installed Plus pack (http://www.audreyhacking.com/wiki/index.php/Plus_pack)
This adds some Unix commands like mv, grep, and especially fs-cifs which lets us mount windows file shares. Added these lines to the bottom of /kojak/boot.sh to mount the mp3 directory on our windows server:

sleep 10 # wait for networking to come up
/nto/bin/fs-cifs -a //mywindowsservername:192.168.1.2:/mp3 /mp3 user password

Installed telnetd/inetd (http://www.audreyhacking.com/wiki/index.php/Telnetd/inetd)
This lets us telnet into the Audrey so we don't have to sit typing at it. Made installing all these hacks easy to do from the comfort of a real keyboard.

Added the ability to push WAVs by installing playsound_noph from here http://planetwebb.com/audrey and added this file (/data/XML/playsound.shtml) to the Audrey web server:

 <html><head><title>WAV Push</title></head></body>
 <!--#exec cmd="playsound_noph $QUERY_STRING &" -->
 </body></html>

Now WAVs can be remotely pushed to the Audrey by loading this URL: http://audrey.ip.address/playsound.shtml?http://windows.server/wavs/abc.wav

Installed GUI MP3 Player phplay (http://www.geocities.com/flipflop7146/audrey.html also relevent http://www.audreyhacking.com/wiki/index.php/MP3_Playing)
So now we can play music off our server.

Created my own icon for phplay and added it to the Audrey Options menu (http://3rdmoon.com/crusso/audrey/interface/addbuttons.htm)

Installed the Mr. Audrey package manager (http://www.mraudrey.net/pkgs/ins-utils.zip)
This is necessary to install the gui-less MP3 player (plaympegaudio_noph) to push MP3s to the Audrey since I couldn't find it anywhere except in an install package for Mr. Audrey. Just transfer this file to the Audrey, chmod +x ins-utils.zip and then execute it to install the package manager

Installed plaympegaudio_noph (http://www.mraudrey.net/pkgs/apps/ins-mpgnoph.zip). Same thing, transfer it to the Audrey, make it executable and run it. Created /data/XML/playmp3.shtml:

 <html><head><title>MP3 Push</title></head></body>
 <!--#exec cmd="plaympegaudio_noph $QUERY_STRING &" -->
 </body></html>

Similar to the WAV push, the MP3 push can be done by accessing the URL. It can be automated in a script using wget to download the URL.

I think that's all. I replicated the changes to 3 other Audreys by dumping an image to a CF and installing it on the other 3. Not bad for an evening's work :)

Shoehorned a High Efficiency PS into the kitchen PC

I picked up the smaller SPI180LE power supply for this PC. It doesn't fit nicely into the chassis so I dremeled and drilled and wedged it in pretty good. Now it runs about 35 watts in idle. Not as great a savings as I expected but in the long run, it'll add up.

I'm also working on some long delayed integration of our 3Com Audreys. They've been nice touch screen control panels for the various ASP scripts on our HA server, but I've added some of the more common HA fixes: being able to set the LEDs remotely, pushing WAV files to them, MP3 playing capability and the ability to mount Windows shares.

The Audrey's blinking LEDs will now signify there is a voicemail in HAL. I added this code to the starCOMUltra hosted script to run a script to blink all the Audrey's LEDs when there are new messages:

function HALVM() {
    HalNewMsgCountOld = HalNewMsgCount;
    HalMsg = HAL.Phone.Mailboxes.ItemByName("Main").Messages;
    HalMsgCount = HalMsg.Count;
    HalNewMsgCount=0;
    for (i=HalMsgCount;i<=HalMsgCount;i++) {
        if (HalMsg.Item(i).IsNew) {
            HalNewMsgCount++;
        }
    }
    if (HalNewMsgCountOld!=HalNewMsgCount) {
        if (HalNewMsgCount>0) {
            ShellCmd.Run("perl site/scripts/audrey_light.pl 1",7);
        } else {
            ShellCmd.Run("perl site/scripts/audrey_light.pl 0",7);
        }
    }
}

The Perl script just accesses the Audreys' internal web server to toggle the lights:

`wget "http://xx.yy.zz.1/cgi-bin/SetLEDState?$ARGV[0]" -t 1 -O c:/ftp/audrey_light.out`;
`wget "http://xx.yy.zz.2/cgi-bin/SetLEDState?$ARGV[0]" -t 1 -O c:/ftp/audrey_light.out`;
`wget "http://xx.yy.zz.3/cgi-bin/SetLEDState?$ARGV[0]" -t 1 -O c:/ftp/audrey_light.out`;

I still need to figure out how to take advantage of the WAV pushing feature...

GTalk Babble Bot

Ok, this is not HA related but we use Google Talk as our primary chat too. They've just announced that they've created bots that can translate conversations on the fly. VERY COOL. Check it out!

D201GLY2 Kitchen PC built

I've got the kitchen PC built and running Win2k although text is kinda crappy on the Vizio 20" TV. I tried all sorts of drivers and even loaded up XP to see if it would make a difference. Doesn't appear to. Native resolution of the TV is 1366x768 and I can't get the card to do that - best I get is 1280x720. It's OK for now.

Anyway, it's running with a 160GB HD and 1 GB RAM. I'm leaving the DVD out to save some power. It peaks around 55 watts and idles around 48 watts. I'm hoping to pick up a high efficiency power supply like the SPI220LE to see if I can get the power down even further.