HCA Weekly Reader for the week of 31-May-2020

Home Control Assistant Newsletter for May 31

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

And if you are looking for answers to the most common questions about HCA check out our Frequently Asked Questions page.

Version 16

In case you missed it, HCA version 16 was released in October 2019. There are two big reasons to upgrade to this new version. First there are a lot of new features and a lot of stability improvements that make things go better and faster even if you make no changes in your design. Take a look at the release notes and you can see all the changes. Let me highlight two reasons to upgrade.

First, over the years we have had a lot of requests for ZWave and Zigbee device support. These wireless devices have their pluses and minuses and some people really like them. If this is what you are looking for, then you should look into Samsung SmartThings and Hubitat Elevation. Both offer hubs that provide the interface that HCA needs to talk to these kinds of devices.

The second big reason to upgrade is that you have a lot of time invested in HCA and by upgrading, at a nominal cost, you support the company that keeps this software going year after year. Recently the HCA Cloud got caught up in a bit of a squall when our hosting company came under attack. While it was nothing to do with HCA, our team was there over the weekend and sorted it out within a day. Upgrade now to keep this level of support going.

Debugging is a state of mind
As promised, this week I’ll continue with the discussion of the program debugger and how to use all its features. But first I want to talk about two support cases that came my way this week that I hope will illustrate that tools only help so much; it’s the plan of action when something doesn’t work that is your most important tool.

The first support issue was from a user whose Insteon PowerLinc was doing very odd things. It was doing something very unexpected that caused HCA to terminate. Now that is clearly a problem in HCA. Nothing a user does, or misbehaving attached hardware, should ever cause software to terminate unexpectedly. It should have reported some sort of error. Exactly what was happening to HCA we never found out. But even if we had found out about the HCA termination, the problem still would have remained: the PowerLinc either wasn’t connecting, or when it did connect it couldn’t control anything.

If I were the user, my first thought would have been that it probably wasn’t a general problem with PowerLinc support in the HCA as there must be many users out there using the same version of HCA with a PowerLinc. Now I admit that the software termination did obscure the point, but in general it really must work as PowerLinc support isn’t some obscure feature that only one person is using. Next, I would think perhaps the computer and USB are causing problems since Windows Update messes up so often I hear. The user reported that other USB devices were working ok. But still, not too much work to get HCA on another machine and try the PowerLinc there.

After many messages back and forth between us I suggested that given the cost of a PowerLinc and the value of his time, the best approach would be to get a new PowerLinc and try that. Turns out he had another one – not sure why he had not tried that sooner – and that worked ok.

So, what’s the story here? Something doesn’t work. What to try? First consider that it probably isn’t the software since using a PowerLinc can’t be that rare. Second, consider if it is the PowerLinc or the computer. And both were in reach of the user to try. We will come back to this in a minute.

The second issue I don’t have the full story on, but I think it is still illustrative of the need for a “problem solving” mind set. A user reported that he was using the Read-Data programmer element and it wasn’t working. Quick review: The Read-Data element reads a file where each line is of the form <name> = <value>. The file is read and global variables are created with the name and assigned the value.

He reported that some of the data was correctly read and other data wasn’t. What I would have done is to first check the log. Perhaps the Read-Data element reported an error. I don’t know if it did or not in his case, but I do know that it does report errors if it finds a line that is malformed. Next, I would have reduced the file from the 20 or so lines it was to a single line and see if that works. That would show if it works at all and I understood the format.

Next, I would have taken the original file and cut it down to maybe two lines and tried that. Then I would keep adding lines back in until it stopped working. At that point maybe it has a limitation on the number of lines (it doesn’t but maybe I didn’t know that), or maybe one of the lines I added was the problem. And that’s not hard to pursue! Just take the last added lines out and try again but this time one line at a time. If it fails, see what’s different about that last line added. I wish I had an ending to this one, but I never found out what was wrong.

In both cases there was a problem. Here are some thoughts on creating a debugging mindset:

Identify the problem. Sometimes this can be harder than it sounds especially with problems that happen infrequently. Try to get in your head a clear understanding of what the issue is beyond the “Nothing works”.

Strip out the non-essential elements. For example, is it something else in the design interfering? Maybe create a new file and try and recreate the problem there. Reduce as much as possible to the essential parts that show the problem. In the second case study, removing lines from the Read-Data file would have got down to the essential element – which line caused the problem.

Make changes one at a time. In my first case study, changing to a new computer and a new PowerLinc wouldn’t prove much, but changing to a new PowerLinc would validate (or not) the computer and changing to a new computer would validate (or not) the PowerLinc.

Work slowly. Problems are frustrating. After all you just want the damn thing to work, right? But working in a calm methodical manner will get you to that much quicker than haphazard changes.

Just because it works doesn’t mean it is correct. Years back at Microsoft the goal in development teams was always to execute new additions to software in the debugger step-by-step. Not to find a problem but in watching things “in action” often problems or potential problems would be observed.

No software is bug free. Come to accept that anything you create will always have, at some level, problems. Acceptance of that fact can hold down frustration when problems happen.

Why aren't you using the program debugger? Part 3: Variables!
NOTE: If you missed parts 1 or 2, they are available on the website weekly blog page.

We have now covered starting the debugger and going element by element. For simple programs that’s probably all you need. But programs that have state can, in general, do more. Why? With the use of variables to keep state a program can make more complex decisions or act differently depending upon what has gone on before.

When a program is running in the debugger you can view any local or global variables using a viewer. Press the 3rd button from the right in the debugger controls:

And the viewer opens.

A few points about this viewer:

You can leave it open as you go through the program step-by-step or run until a breakpoint and the viewer updates to show the change in any variables each time the program stops.
The colored dot in front of each line shows important information: Those that changed since the last time the program stopped show with a red dot. If not showing with a red dot, the then global variables show with a blue dot, local variables with a white dot, and program parameters with a black dot
In the “Use” column for local variables it shows in what program it is being used, and if you have stopped at a location in a program started by another program – in programmer speak you have 2 stack frames – it shows which frame you are in.
To change a variable’s value, you can select it and change the value in the lower section of the viewer and commit with the “Update” button. But there is a simpler method. All you need do is to click on a value and then you can edit it right in the row. Commit the edit with the [Enter] key. As the dialog says, this only works to change data of one type to a value of the same type. For example, if I clicked on the value of the local variable “days”, I could change the value 1 to a value of 2. If I want to change the value to something of another type, a string for example, then I would use the lower section of the dialog.

That’s about all that needs to be said about the variable viewer.

There is another tool you should get comfortable with called the “Explorer”. This is opened from the last button in the debugger control buttons. If you never have used the Compute or Compute-Test elements in a program, then I suppose you can skip this next section since it applies only then but more knowledge is always good, right? The Compute and Compute-Test elements are “Good things”, you really should learn and use them more. The Explorer opens as:

Let’s ignore the lower section first and just look at the top section by way of an example. Suppose I had this string in the variable named “data”:

Apple, banana, carrot, date

And I wanted to extract out the 3rd section and uppercase the first letter of it. That’s not hard in a Compute element and it looks like this:

_Ucase(_Left(_TextPiece(data, 3, “,”), 1)) + _Mid(_TextPiece(data, 3, “,”),2)

Now, I’ll be honest, it took me three times to get that correct – I counted! But rather than creating a program and putting that into a compute element and running it, fixing it, running again, fixing again, and running the 3rd time, I used the Explorer.

The top section of the Explorer is like a Compute element that you can run right away. Just enter in text of an expression and press the “Evaluate” button and you either get an error or you get the result shown in the box below the “Evaluate” button. And it works with current data of the program being debugged. That is, global variables, the parameters and local variables of the program where execution stopped.

The lower section of the Explorer I will only touch on very briefly. An HCA Program using the _DesignOpen, _FileOpen, and _JSONOpen functions lets you work with elements in your design, work with files on the disk, or decode JSON encoded data. When used, each of these functions provide a piece of state – which we call a “handle” – to use with other functions. For file operations the _WriteString function, for design elements the _DesignName function, and for JSON data the _JSON function.

There are only a limited number of handles for each kind of operation and the Explorer shows you which are in use and what they reference. In the image above of the Explorer, it shows that the program has one file open and the path to it.

If you are working with these functions then you already understand all about handles, their use, and limitations. And if you don’t use them, just tuck away in the back of your brain that the Explorer can help with this data, so if you start working with those functions you know where to go.

That’s it for this week’s dive into the debugger. Next week we will cover two other tools related to the debugger that can help a lot in the “getting programs to do what you want” project.

HCA Server machines - back in stock!
Managed to get a few more small footprint computers that are perfect for running the HCA Server. We now have both the Windows 10 and Windows 10 LTSC machines ready to go. What's the difference? Something you can find out along with all the info on the website HCA Server Computer page.

V17 Open beta now available - beta 12 now available
The HCA 17 open beta rolls on with a new beta this week with new features now available. Want in? All you need do is to enter your HCA registration code into the online form as usual, and the resulting page contains a link to the beta page for download. The beta zip file password is the same as your V16 password. Please read fully and carefully the build notes. One suggestion: If you are using SmartThings or Hubitat you really should get on board with the beta as there is new stuff heading your way that needs this beta version.

Want to watch instead of read?

If you are interested in watching some videos about how HCA and Insteon can work together, George De Luca, a HCA users of a few years and technology video creator, has started to add HCA videos to his channel. He has a good knowledge of HCA and its ins-and-outs.

His channel can be reached at: https://www.youtube.com/deluca2008. While I’ve offered him some thoughts on the videos, his opinions and advice on using HCA are his own. If you have questions about something you see, ask them in the video comment section and you may see a video with an answer.

User-to-User forum

An HCA User who wanted to set up a forum for user-to-user communication. I'm passing this on, but please know that this is not a HCA company project and I will not be spending much time there so I don't know how this will work out. Here is a link to what he set up.

https://www.reddit.com/r/HomeControlAssistant/

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.