AT&T DSL Pricing Going Up

We have Comcast at our main house and AT&T DSL at our other. The price of DSL is going up $5 per month starting this month! That's a 25% increase over what we're paying for 1.5Mbps service. The service is pretty bad as it is but we don't use it that much. No wonder the US has the worst/priciest Internet experience - pretty sad considering we invented the Internet. That's what happens when there's no competition and you allow all the regional bells to merge together. Funny that AT&T announced "free" hotspot access for many of their broadband customers a few weeks before they announced their raising broadband prices. Free my ass.

If you are staying with AT&T, like we are, because there's no cheaper alternative, then hit this link to lock in your current rate for 1 year before you start financing their "free" wifi hotspots.

More Details on xPL HALi App

You can edit the enclosed XML file (xpl_doghouse-hali.instance0.3.0) to change the name of your xPL HALi instance. In the file, the key newconf is set to "home", but you can change that to anything you want.

To install more than one xPL app on your PC, you'll need an xPL hub. Here's one.

A good thing to have around is the xPL command line sender or the GUI xPL sender.

Another helpful app is DCM. The message logger is a great utility for debugging.

So what can you do with all this? Let's just start with something simple. Send an xPL message to xPL HALi to change a flag using the command line sender. From the command shell type (all on one line with a space after 'home' and before 'control'):

xplsend xpl-cmnd doghouse-hali.home control.basic device=testflag\ntype=flag\ncurrent=1

This issues an xPL command to application doghouse-hali.home (where home is the default name in the XML file mentioned above). The command is a control.basic type that sets the flag named 'testflag' to 1 or TRUE. You can try out the other commands that xPL HALi supports by following the command guide in the previous post. Have fun.

xPL HALi App Available for Download

So I've decided to release my xPL HALi application that I mentioned here. You can get it here. I only implemented portions of HAL I use (no X10, no DMC, no alarm panels, etc.) Just the basics. Don't know what xPL is? Read this and visit the xPL Forums. You'll need to install .NET 2 and .NET 3.5

It issues xpl-trig sensor.basic commands in response to the following events:

Listening state changed
sensor.basic
{
  device=listen
  type=mic
  current=1
}
This message is sent when HAL is listening via microphone. Type will change if VR is via handset.

Macro Executed
sensor.basic
{
  device=macro
  current=macroname
}
Execute 'macroname' macro.

New Voice Mail
sensor.basic
{
  device=newvmail
  current=1
}

Phone Hook Changed
cid.meteor
{
  CallType=outgoing
  CCS=initiated
}
Outgoing call started.

Phone Ringing
cid.meteor
{
  CallType=incoming
  CCS=ring
}
Incoming call.

Sensor State Changed
sensor.basic
{
  device=sensorname
  type=flag
  current=1
}
Flag 'sensorname' set to 1. Type can be flag, counter, variable or timer.

Speech Notify
sensor.basic
{
  device=VR
  current="phrase recognized"
}
Recognize the listed phrase via VR.


The app responds to control.basic xpl-cmnd messages allowing some control of HAL devices:

Setting a Flag
control.basic
{
  device=sensorname
  type=flag
  current=1
}
Set a flag to 1.

Setting a Variable
control.basic
{
  device=sensorname
  type=variable
  current=1
}
Set a variable to 1

Setting a Timer
control.basic
{
  device=sensorname
  type=timer
  current=60
}
Set timer to 60 seconds.

Increment a Counter
control.basic
{
  device=sensorname
  type=counter
  current=+1
}

Decrement a Counter
control.basic
{
  device=sensorname
  type=counter
  current=-1
}

Set a Counter
control.basic
{
  device=sensorname
  type=counter
  current=20
}

VOIP VR Video

Here's another video I made. It shows how we use TeamSpeak voice chat software from remote PCs to talk to HAL.

The video shows an RDP session to the HA server on the left of the screen and on the right is the TS client running on a laptop. In the RDP client, you'll see the HAL monitor, the xPL HALi app I wrote, starCOMUltra and our web based GUI. HAL, named Sara since the wife likes the show Eureka, responds to her name spoken into the laptop microphone. The TS client blinks as it hears me. The HAL monitor shows the name was recognized and enters listening mode. xPL HALi sends an xPL control.basic message with the listening status. xAP Floorplan (via its xPL bridge) sees the message and sends message.display to all OSD devices (in this case xAP Intranet Launcher) informing them that the system is listening. This is necessary since HAL's audio is not routed back through TS to the laptop and we may not be within earshot of HAL. A couple commands are spoken to turn on & off the kitchen light. You can hear the click of the switch as it toggles, see the commands being issued by starCOMUltra and see the kitchen light go on & off in the GUI.

Home Automation GUI Video

Here's a video of the HA interface I've been building. It's a few months old now and has been posted on a few HA forums here & there. Since Comcast bumped web page capacity, I decided to leave the video up and link to it from here

This pretty much represents all systems interacting together - starCOMUltra, xPL, xAP, HAL - and tied together with AJAX, MySQL, PHP and DHTML running on Apache.

Farewell kJ :(

Our beloved kJ passed away yesterday at the age of 13 years, 8 months. kJ has been with me since my interest in home automation began. He witnessed the mad wiring, connecting, soldering and programming, and was also the reason for a few automation tasks (ie: the computer yelling at him in his doghouse when he howled at night). He was always there to tilt his head when asked if he thought this was a safe spot to drill in the wall. When he didn't like something I did, like leave the landscape lighting wires exposed, he would promptly chew them up and make me do it better. Of course, his expert assistance was the reason behind how kJ's Doghouse came to be :) We miss you so much kJ.

http://www.doghouselabs.com

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.