Sunday, January 27, 2008


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.

Thursday, January 24, 2008

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?

  NewVoice Message in All Mailboxes >= 1 (TE)

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

  NewVoice Message in All Mailboxes = 0 (TE)

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.

Monday, January 21, 2008

My First App

I've been testing out the 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).

Sunday, January 20, 2008

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;


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?

Friday, January 18, 2008


I've been playing around with the free Visual Studio 2008 Express learning how to create an app in 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, 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.

Wednesday, January 2, 2008

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.