Home Control Assistant Newsletter for April 4 2021

Have you looked over the version 17 release notes? Lots of changes that you can incorporate into your designs right away. Easy upgrade.

Looking for answers to the most common questions about HCA? Check out our
Frequently Asked Questions page.
"Class Program" or "Program as Device"?

Recently I got into a discussion with a user building support for some hardware he has. It is a shade controller I think, but that’s not important for this discussion. The hardware operates in the same manner as most dimmable devices. It can be sent, in effect, ON, OFF, Set-Percent, and Get-Status commands. This made it a candidate for a program that HCA treats as if it were a device. Let’s start with what that even means.

A program that operates as a device lets you use this program with all the features of HCA that work with devices. For example, besides on, off, set-percent, and get-status, it also has auto-off settings, periodic polling, device confirmation, participation in a room, and even power usage logging with the power track facilities. In short, HCA “thinks” it is a device. I will not get into the details of how to implement this because there is a technical note on it and an example in the library. Implementation isn’t what I want to discuss.

OK, so if that is a “program as device” then what’s a “Class Program”? A “Class program” is a program that implements all the same facilities as a program operating as a device with a key difference.

The difference is in what you are building and so how it is used. Take the case of this user. Suppose they have only one – and that is a key point – of these widgets. When the program that works with the widget is created, in that program is some means of identifying the widget installed in their home. Suppose the device is communicated with by sending commands to an IP address. Suppose that in their installation that widget gets IP address In the program, anytime they need to send a HTTP command to that widget to cause it to do something the program uses that specific IP address. That specific IP address is in the program someplace – probably in the configuration of the HTTP elements. 

But what happens if they get a second of these widgets? The second widget has a different IP address. They could just duplicate the program and change all the to the IP address of the new widget. That would also work ok. But what if they got a third one or maybe lots of them? And even with two, if they needed to change the program to make corrections or improvements, they would have to remember to change both copies. That’s not good.

A "Class program" is then the preferred solution. When the class program is used by HCA to do something – turn the widget off for example - the class program is supplied, in addition to the command, with a “piece of information” that identifies the specific widget. Let’s call that “piece of information” the device “ID”. Where did the ID come from and what does it look like? When HCA knows it has a class program in your design, when you create a new device in the “what is it” step of the create wizard it lists the name of the class as a choice. The ID is on one of the tabs of the device properties and you, knowing what the widget is and how it works, enter the ID in whatever format is expected.

When commanding the device to do something, HCA knows to run the class program to do it. It provides to the class program the ID along with telling the class program what to do. In the “Program as device” method, the program gets told what to do but is provided with no ID. HCA assumes that the program either doesn’t need it or already has it.

So “class program” or “program as device”? The key questions are two:
1.    Do you have more than one of the widgets you are supporting?
2.    Even if you have one widget, might others have them and you want to make your work available to them?

If either of these questions are answered with a yes, then you want to create a class. And, yes, there is an example class in the online library.

The Community at Work
A few weeks back I wrote about how much of the “action” these days in HCA is not in the executable itself but in the facilities that can be downloaded and added to your design from the library.

In the last week, a major piece of new support for Hubitat thermostats was created and added by a user. Also, several problems in the Venstar thermostat class were corrected by another user. And in a few weeks, support for a cool ZWave keypad with programmable button labels will get added. All this is not my work but the work of others. This is great stuff.

So, before you ask me for a new feature, ask yourself, “Can I build it or take something from the library and modify it or use it as a starting point?”. The answer will in many cases be “yes”.


When was the last time you made a backup of your HCA design? Not a month goes by without at least one tale of woe from a HCA user. Please use the "Design Backup Assistant" on the Tools ribbon category. The work you save will be your own.

Want to take the next step in automation? Want to get started with Amazon Alexa and Google Assistant and control HCA by voice commands? Even if you are a long-time user of HCA, the Getting Started guides have all the info you need on client-server, mobile applications, DDNS, and voice assistants.

All of the
Getting Started Guides are available on the support website.
Copyright © 2021 Advanced Quonset Technology, Inc, All rights reserved.

Want to change how you receive these emails?
You can update your preferences or unsubscribe from this list.

Email Marketing Powered by Mailchimp