HAI SDK example application Issues with any system other than OmniPro II

Posted: April 6, 2012 in Home Automation

I recently joined the HAI (Home Automation Incorporated) developer program and started messing with their SDK. I have managed an OmniPro II system for my boss, for several years, and recently purchased an HAI Omni IIe system for a house I am having built. Being that I’m a C# developer, I decided to tear down their example program, and start rebuilding it to suit my needs. Their example gives you the resources to connect to the system, get the basic configuration, and monitor certain functions within the home.

The only problem with this SDK example application is that they have a method called “HandleIdentifyController”, and it contains a check to see if the system in OmniPro II. If it is not, it simply throws the error “model does not match file”, and disconnects. Wow, a lot of good that does me. After a bit of research, and understanding behind the error, I came to find that within the HAC object (clsHAC instantiation), it is set to OmniPro II by default. I came up with a little snippet of code that will fix this problem.

Within this HandleIdentifyController method, are two sections depending on the protocol used to connect. You need to add this snippet of code to both sections, unless you don’t care about one of the protocols. The upper portion is UDP and the lower portion is TCP (Omni-link II).

There is a line of code

if (HAC.Model == MSG.ModelNumber)

Right before that line of code, add this:

foreach (enuModel enu in Enum.GetValues(typeof(enuModel)))
    {
        if (enu == MSG.ModelNumber)
        {
            HAC.Model = enu;
            break;
        }
    }

so it looks like this:

clsOL2MsgSystemInformation MSG = new clsOL2MsgSystemInformation(HAC.Connection, B);
foreach (enuModel enu in Enum.GetValues(typeof(enuModel)))
    {
        if (enu == MSG.ModelNumber)
        {
            HAC.Model = enu;
            break;
        }
    }
if (HAC.Model == MSG.ModelNumber)
{...}

What this does is loop through available system types within the HAI SDK, and tries to match it to a system type. If it can’t match it, it will continue to throw the same “model does not match file” error. This means the SDK does not support that system.

Advertisements
Comments
  1. compucore says:

    That’s always good to know. I have touched C#. I’ve always learnt on C++, Delphi and a few other programming languages.

  2. Fred says:

    Hi Rick,

    I’m glad to see that you are using HAI products and our SDK. I see that you are having a few problems and would like to see if I can help you.

    First let me say that the SDK works with all models of HAI and HAO/OEM controllers. This is the same code that is used by all of our own products just in a DLL wrapper, so anything and any model supported by PC Acceess 3 is supported by the SDK.

    You are correct in that when a controller object is instantiated the default controller type is an HAI OmniPro II. It has to default to something. Typically in an application you would read some sort of config file with information about the controller you want to connect to. You would then create an instance of a controller object and set the properties from the config file. In PC Access for example the config file is the account file for a particular controller.

    After creating a controller object, at a minimum you should:
    1. Set the controller Model. This must be done first because it initializes all of the data structures and validation rules for the controller. When the structures are initialized any existing data will be lost.
    2. Specify the network connection information (IP and port).
    3. Specify the encryption key.

    Once you have done this you can connect to a controller and read all of the other settings from the controller itself.

    I see your code example, but if you know the address and encryption information for the controller you could/should have specified it after instantiation and before connection. The code in the HandleIdentifyController section of the example program shows how to disconnect gracefully if you connect to a controller that is not the one you were expecting.

    This is what PC Access would do. If PC Access opened a file for an OmniPro II then tried to connect and found that the system was not and OmniPro II PC Access would disconnect. PC Access is intended to configure a controller and writing the configuration from a different controller model or sending commands for a different model would not work, so it will not connect to a controller of the wrong type.

    On the other hand OmniTouch Pro which is designed to connect to any controller and let you control it uses code similar to yours. It connect, determines the type of controller, sets the model appropriately then retrieves the setup, then presents a user interface. OmniTouch Pro never writes setup back to the controller and does not send any commands until it knows what it is talking to, so this is OK.

    Which method is right for you depends on how your application works.

    I guess I should have documented this better in the example program. It is a fairly basic program and was written specifically for my OmniPro II. If I get some spare time (LOL) I will see if I can add an example of how to handle other models.

    I hope this helps and would love to hear what people are doing with our SDK so once completed why don’t you post something in our developers forum.

    Fred.

    • Ricky says:

      Thanks so much! I’ve had quite a bit of success so far with the SDK, and am enjoying working with it, while learning quite a few new things. I have updated the article title and where I’ve referred to the sdk itself, when really I was speaking of the example application. After working on a new monitoring application over the last few days, I’ve come to realize how huge a task this is.

      I plan on making my application available to the public, for free, as soon as it’s a bit more complete. My intentions are to have a good monitoring application that give the user the ability to set up notifications of certain actions that occur within the system… zone changes, unit changes, security, whatever. I’m really building it for myself, but I’d like to share it with others, and get feedback to make it a great application.

      And thanks for all the suggestions!

      • JonW says:

        I’ve just started playing with the HAI SDK myself. I’ve been using Delphi for quite a while, but with the SDK only being supplied with a C# example, I think I’ll take this opportunity to learn some C#. Your description above about creating a monitoring app to send notifications is exactly what I’m looking to do. Would you be able to share some of what you have going already?

        In addition to the notifications, I’m thinking of doing a SQL logging function as well. That was something I did many years ago on my HomeVision system and I really liked the ability to look back at temps/times/access, etc. for events around the house.

        Regards,
        Jon

  3. Mike says:

    Hi Ricky,

    Great to see the work you are doing with the HAI SDK. I’m very new to programming and C# especially. I’m very keen to learn how to build an event logger for an omni controller and have it write the events to a csv file.
    I have been going through the SDK and HAI’s example to try and learn how to do this but was wondering if you have any tips or code snippets you would like to share?

    Thanks
    Mike

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s