Home Control Assistant Newsletter for December 4 2022

Have you read the Important Announcement posted on August 1, 2021? If you haven't you need to.

The latest version of HCA is 17.0.48 with new features!
Read about how you can download it.
Problems in programs? Seeing Alerts? It’s OK. Seeing Program errors? Not good.

Nothing works 100% of the time. Communication fails. Devices don’t respond. Files that should exist don’t. Email can’t be sent. Networks are offline.

Because of this it is important to handle those sorts of failures in your programs. In doing so you first have to consider what’s an “expected error” and what is an “unexpected error”? 

An unexpected error is simply a mistake you made in creating the program. For example, you put this in a Compute element:
Void = _On(“No such room-no such device”);

Unless you are into strangely named rooms and devices, I think you get the point that your design doesn’t have that room and device.  In a less obvious case, you probably tried to use the correct name and just mistyped it. What does HCA do when it encounters this? It creates an error and starts the program debugger if you have that option enabled. For “expected errors”, whatever operation the program is doing always fails, and the program is terminated at that element.

Now consider a HTTP element sending to something and waiting for a response. What if the network or the device is offline? That is what I would call an unexpected error. Most of the time it works but sometimes – probably rarely – it doesn’t.

Now that we have divided the world of errors into two classes, how do we handle them? 

Expected errors are found through testing. Over time all the paths through the program get used and as those sorts of errors happen you find and fix them. 

Unexpected errors take work to handle gracefully. What does that mean? You don’t want the program to just terminate or the debugger to start. You probably want to record that the problem happened and then move on. The key point is that the problem is handled within the program.

Some program elements have direct support for this: The test, thermostat, thermostat-test, weather-test, http, hue, camera, email, and port I/O elements all have configuration to say what happens if that element fails due to a communication error. Instead of moving to the next element, the program can resume at a connector element. What does that new path of the program do? It could just exit, or if you want to make a record of the failure, it can use the _AddAlert Compute element function. It could even implement some sort of retry mechanism, but that’s all up to you.

There is one additional piece of configuration you need to make this work. On the program Advanced Options tab is an option that must be enabled:

Why doesn’t HCA just always do this? During development you may well want those sorts of failures to start the debugger. But after you deploy your program that option needs to be enabled.

Finally, there are other “expected errors” that you should handle in a different way. Suppose you are using the Read-Data programmer element and the file doesn’t exist? HCA terminates the program with an error. But you could proceed that element with a Compute-Test element using _FileExists to check for the existence of the file. If it doesn’t exist, then that path from the Compute-Test doesn’t go to the Read-Data element. Your program should do something to alert you to that fact the file is missing, or time will pass, and you will never know that it isn’t working.

There are similar methods for other cases. In a program if you are assembling a device name using some mechanism and then using an action function (_On, _Off, etc), the _IsValidObject function can be used to check that name before doing an operation with it. That way the action function will never fail because of a bad name.

The goal should be that your automation design runs quietly in the background making your life better. It should gracefully handle problems that come up in a planned manner. What you create shouldn’t hide problems, but it shouldn’t generate program errors

Last week I wrote about a technical note written by a HCA User that describes how to integrate a water metering system with HCA using Hubitat (technical note #706).

This week I have another technical note also created by a very experienced HCA user that describes how to use Alexa to accept events from Ring devices and to send those on to HCA using Hubitat. Check it out as it is now available on the HCA support site:
 technical note #707.

What I really like about all this work is that HCA users are working with Hubitat and Alexa to do device integration in a way that lets HCA do what it does best: monitoring, reporting, and advanced control.
If you are using a version of HCA prior to version 17, you may have questions about the wisdom of upgrading to version 17 given the future of HCA. Here is something to consider:

The support policy for older HCA versions has been changed
 as I can no longer devote time to past version users. Support will only be available for HCA 17 users.

If you are on version 16 or earlier and want to continue using the cloud features and want to be assured that if you have a question that it gets answered, it is indeed time to upgrade.

HCA is fully operational for several more years so the update cost, spread out over that time, is very little. Knowing support is available when you need it is worth it.
Upgrade to HCA 17
Anyone who is using Hubitat with HCA – not SmartThings – please drop me a note as I would like to add you to a discussion list for those users. I have some Hubitat ideas that I would like to “kick around” and it would help to have a group of users who have experience with Hubitat. Please just send a note to the regular support address saying you would like to be added to that discussion list.
Copyright © 2022 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