Announcement

Collapse

Contacting HomeSeer This Week

HomeSeer is open and operational this week. All orders are being processed and shipped as usual. However, some staff are working from home. If you need to contact HomeSeer for support or customer service, please use our Email or Chat options. https://homeseer.com/contact-us/
See more
See less

HAI Important Information

Collapse
This is a sticky topic.
X
X
 
  • Filter
  • Time
  • Show
Clear All
new posts

  • HAI Important Information

    The timing of Ross' recent post is quite interesting because I saw it just when I came to the board to post this message...

    As many of you long-timers are well aware, I have struggled with the HAI serial protocol for years - about 5 years with HomeSeer at least. Although HAI has well defended their use of a polling protocol (although they are the only ones who ever agreed with their defense of it!) it has been a source of much frustration for application developers. In short, the problem has been that when you are trying to poll the panel every 500ms so that changes at least "appear" to be realtime, but you have ad-hoc events causing interruptions in that from time to time and a protocol that does not match responses with requests, the results can be quite horrific at times. The Ethernet interface was suppose to fix all of that, but their DLL to make communication for us developers "easy" used a very tricky communication method and was rooted in programming languages I did not have much experience with (not since college at least, and that was too long ago).

    After hitting a lull in the HomeSeer project I have been working on for months and with a little holiday time, I decided to bite the bullet and write my own network interface implementation from scratch using their protocol documentation. I had enough written within a few days to do some testing and I made good progress. Recently though, I ran into a roadblock when, after connecting with the panel and establishing a new session, I could not get a secure connection acknowledged. I contacted HAI with all of the data, and I was quite surprised (and a little worried) when they wanted to CALL me to discuss it...

    Well, the call was good news - it was word of their upcoming new protocol that Ross already mentioned. I won't let any more cats out of the bag because I am sure HAI intends to do a full announcement at CES, but just as Ross stated, it appears that they finally made massive changes that were due (IMHO) at least 10 years ago.

    What I will add to what Ross mentioned about the protocol good news is this - they also have a new .NET compatible interface DLL that they will be providing me, so all of the low-level communication and encryption hassles I have been coding will not be needed. They are doing away with the very touchy Windows messages based DLL that they previously used.

    What does this mean? Here are my current plans:
    • I will get the current plug-in to a stable state, which means I will take care of as many of the current issues as possible, and then I will "freeze" that code.
    • I will write a new plug-in that will use the new protocol exclusively, but will have all of the features of the old plug-in, and thus will be a drop-in replacement for the older plug-in. This code will be the new one maintained until it hits some sort of end point like its predecessor.
    • The initial release of the new protocol will not have support for the serial interface, and so even when HAI provides it, I will still not put it in the new plug-in unless a poll of existing users deems it necessary. Since the new protocol is only available for the newer panels, and the newer panels have Ethernet interfaces, I am not sure that RS-232 will be needed at all.


    I am really looking forward to the new protocol - it is even giving me incentive to replace my home's HAI panel with one of the newer models!

    I believe HAI charges between $20-$30 for firmware upgrades, and I have no idea what the board level upgrade will cost to get the flash upgradable system, but do existing owners see any issue with upgrading to the new protocol?
    Regards,

    Rick Tinker (a.k.a. "Tink")

  • #2
    Rick, this is fantastic news. I did hear about the HAI change, but maybe you know more than what I read. I read that they will have a new panel that will be firmware upgradeable, instead of one which requires a firmware replacement. The part I didn't hear was about a possible FW chip upgrade for current panels, but it sounds like this is true. At least for the Omni Pro II. Any timeframe given?

    Also, just wondering, when this upgrade occurs, does this mean to old interface will no longer be supported, or will panels support both old and new interfaces? Or will they need to support two versions of all their programs, one for upgraded users and one for non-upgraded users?

    Also, one comment. While I'm very encouraged by this news, past experience with HAI has taught me that their software/firmware programming experience was weak at best. Hopefully they have been successful at hiring real programming help, which they have lacked in the past.

    I have to wonder WHY they are making this move? The present protocol must be so screwed up that it doesn't even support what they have planned. I can't imagine that HAI is changing it for the sole purpose of 3rd parties like HomeSeer and others.

    In any case, again, this is really good news.

    Comment


    • #3
      The timeframe for the EEProm is a couple of weeks, which is why I assumed its release was tied to a CES announcement. However, that may not be the general release date - I do not know the answer to that.

      I do not know if the new protocol shoves the old one out - good question for HAI - I know in the past they balked at adding some features because of tight EEProm space, so it would make sense if that were true that they could not support both protocols at the same time. From a software standpoint, they will release a new version of PC Access that will surely support both protocols - I doubt that they will even think about ending support for the old protocol anytime soon.

      HAI has made use of 3rd party developers for their software, but firmware was always done in-house. The software always had strict adherance to Microsoft programming standards for a reason. ;-)

      I cannot speculate what finally caused them to make this move, but I can only assume that they are tired, very very tired of hearing the request over and over again - I was not kidding (nor was Ross) when we said it was 10 years late - I have requested many changes in the protocol over the years, but the very first one I requested was to make it non-polling, and that was around 10 years ago. They may be doing it to IMPROVE 3rd party relations because simple ASCII non-polling protocols is what has allowed us to support competitor panels so easily, and for third parties to support competitor panels but not HAI. The only reason HAI panels are supported is because they are unique and popular - if they were not unique and popular, then I am sure a lot of companies would not even think of adding support for it. Besides being a polling protocol, the whole thing is binary too, which means that external interfaces often cannot use Omni-Link because they can only send ASCII. (HAI's PRO-Link interface is ASCII, but is super, super limited in what can be done compared with Omni-Link.)

      So whatever their reason, and despite how late it is, we all share the feeling that this is very good news and is well overdue.
      Regards,

      Rick Tinker (a.k.a. "Tink")

      Comment


      • #4
        FYI: When firmware 2.16 is released it will support BOTH the old and new protocols. So you can upgrade the firmware at any time and still use the current plugin (current omni protocol).

        Comment


        • #5
          So in a quick recap - new firmware will be plug-n-play. Questions:
          1 - new firmware will need to be purchased via HAI directly? Or distributors?
          2 - Flash HW upgrade (I have an Omni-Pro II) - currently we know it will be standard on new HW - but at this time there is no documentation relating to upgrade of Omni Pro II series HW to flashable firmware? I am assuming this might be a HW trade-up deal of sorts eh?

          Reason I am asking is that I am looking at my panel and wondering how long it would take to disconnect all of the connections and remove board to upgrade. I have 20 plus zones (with daughter card). It would be beneficial to have new board in hand while doing the swap. Or even easier to just flash chips with new firmware on a separate device.
          - Pete

          Auto mator
          Homeseer 3 Pro - 3.0.0.548 (Linux) - Ubuntu 18.04/W7e 64 bit Intel Haswell CPU 16Gb- Mono 6.8X
          Homeseer Zee2 (Lite) - 3.0.0.548 (Linux) - Ubuntu 18.04/W7e - CherryTrail x5-Z8350 BeeLink 4Gb BT3 Pro - Mono 6.8X
          HS4 pro - 4.0.3.0 - Ubuntu 18.04/W7e 64 bit Intel Kaby Lake CPU - 32Gb - Mono 6.8X

          X10, UPB, Zigbee, ZWave and Wifi MQTT automation. OmniPro 2, Russound zoned audio, Smartthings hub, Hubitat Hub, and Home Assistant

          Comment


          • #6
            Regards,

            Rick Tinker (a.k.a. "Tink")

            Comment


            • #7
              HAI sells firmware upgrade chips directly, and at a cheaper price than resellers. You don't need to be a dealer.

              Comment


              • #8
                Needless to say... this is GREAT news for us long time sufferers of HAI's ignoring Rick's requests....

                As I have an Omni II Pro with an Ethernet interface, it sounds like I won't need to upgrade the board only the firmware chip.

                Although flashing would be nice.... I don't see it worth a board upgrade at this point.

                Now hopefully this will solve my long-standing mystery zone trips....

                Comment


                • #9
                  Originally posted by Wazoo View Post
                  Now hopefully this will solve my long-standing mystery zone trips....
                  I am actually trying to do something about that now... There are mysterious zone trips caused by expansion zones (zones on a separate expansion board) which I put some code in to fix a while ago, and then there are mysterious zone trips caused by some flawed code. It goes back to a bad decision on the plug-in API architecture...

                  When you change the value of a device via the Web UI, using hs.SetDeviceValue in a script, or callback.ValueChange in a plug-in, it all results in the same change on the device. However, when the device changes, an event is raised in the plug-in. This is because if you changed the device by changing a drop-down value in the HTML UI, then the plug-in needs to send a command to the panel to match the device. However, it does not matter which method is used to make the change - the callback notifying the plug-in of the change is the same, so the challenge is to find a way to know when the change was made by the plug-in versus the user making a change. Obviously on some unit devices, the code I have in there is not working 100% of the time.

                  I have to get creative and find a really foolproof way to fix this. This is one of the things I mentioned that I would like to get resolved before the old code that works with the old protocol is frozen. The workaround is to not create those devices and to use the built-in event or script methods of interacting with those units, but I know that is not pleasant for some of you based upon how you use HS so I do need to fix this.
                  Regards,

                  Rick Tinker (a.k.a. "Tink")

                  Comment


                  • #10
                    Outputs Not Controllable

                    Rick, I just tried controlling outputs through the plug-in. No response, no errors at all; they don't respond as devices and they do not respond through script commands.

                    My system is OmniP2 w/2 hardwire expanders and 1 expantion enclosure. Using plug-in: 2.1.2746.29695.

                    Is this a known issue?

                    -Ron

                    Comment


                    • #11
                      Originally posted by basshook View Post
                      Rick, I just tried controlling outputs through the plug-in. No response, no errors at all; they don't respond as devices and they do not respond through script commands.

                      My system is OmniP2 w/2 hardwire expanders and 1 expantion enclosure. Using plug-in: 2.1.2746.29695.

                      Is this a known issue?

                      -Ron
                      Ron,

                      This is not a known issue. The only known issue related to outputs is an echo effect - you close the output, re-open it, and then it closes again automatically. (Or visa versa) Controlling outputs should work fine.

                      You mentioned devices and scripts - how about an event action?
                      Regards,

                      Rick Tinker (a.k.a. "Tink")

                      Comment


                      • #12
                        Originally posted by Rick Tinker View Post
                        Ron,

                        This is not a known issue. The only known issue related to outputs is an echo effect - you close the output, re-open it, and then it closes again automatically. (Or visa versa) Controlling outputs should work fine.

                        You mentioned devices and scripts - how about an event action?
                        Hi Rick,

                        No luck in activating the outputs with events, devices, or via scripts. Buttons seem to work so the workaround is to activate the outputs with a button that is programmed and use HS script to press the button.

                        As I mentioned in my other post, some auxilary devices seem to toggle between "Secure, Disarmed" and just "Secure"; or "Not Ready, Disarmed" and just "Not Ready". Makes it impossible to trigger on a consistent status change.

                        -Ron

                        PS The device status always reads correct on the HAI Security page but is inconsistent on the Device status page and affects event triggers

                        Rick an update:
                        Basically I am trying to build specific events with a script. The script contructs an event trigger using an HAI plug-in created device triggering on a value of 1(Secure). I noticed that when I build the event manually and use "HAI Zone Triggers" with a zone status of "secure" the event works and strangely enough the device status on the Status page stays Secure or Not Ready (no "Disarmed").

                        Here is a code snippet:
                        'set up trigger
                        HAIRef2=hs.GetDeviceRefByName("HAI Zones " & CloseHAIDevice)
                        ev.ev_abs_time=12
                        ev.ev_trig_hc=HAIRef2
                        ev.ev_trig_dc=0
                        ev.ev_time=1

                        Here is the resulting trigger from the event:
                        Device HAI Zones Large Garage Upper (56) value becomes equal to Secure
                        Everyday
                        Last ran: Unknown

                        Basically building events based on "HAI Zone Triggers" works but building events based on "Device Values" for HAI devices is a problem for me.
                        Last edited by basshook; January 14th, 2008, 09:11 PM.

                        Comment


                        • #13
                          Originally posted by basshook View Post
                          No luck in activating the outputs with events, devices, or via scripts. Buttons seem to work so the workaround is to activate the outputs with a button that is programmed and use HS script to press the button.
                          To the best of my knowledge over the past 5 years there has never been a problem activating an output via event action. Either the number of outputs you are using is configured improperly, you have a version of the firmware that I have not seen/tested, or there is some other new problem associated with expansion outputs that I have never seen.

                          Originally posted by basshook View Post
                          As I mentioned in my other post, some auxilary devices seem to toggle between "Secure, Disarmed" and just "Secure"; or "Not Ready, Disarmed" and just "Not Ready". Makes it impossible to trigger on a consistent status change.
                          Now THIS is the known issue with expansion zones I mentioned earlier. This probably only happens on zones above the base 16 that come with the panel.

                          Originally posted by basshook View Post
                          PS The device status always reads correct on the HAI Security page but is inconsistent on the Device status page and affects event triggers

                          Rick an update:
                          Basically I am trying to build specific events with a script. The script contructs an event trigger using an HAI plug-in created device triggering on a value of 1(Secure). I noticed that when I build the event manually and use "HAI Zone Triggers" with a zone status of "secure" the event works and strangely enough the device status on the Status page stays Secure or Not Ready (no "Disarmed").
                          I have had issues with devices in the past, but this is a little extreme that they are not working at all - it appears more like the devices are disconnected from the plug-in. That is, they lost their association. This sometimes happens when another plug-in steals the letter code (long story). However, because of the stress already present on the protocol, I have said for a while that you should only use/create devices for those things that you must have devices for - e.g. if you were using MainLobby and wanted to show the status of a door zone. For the first 2-3 years this plug-in never had devices for anything except the main panel status. There is no need for devices except for situations as I mentioned above. The evidence of this is in your next statement:
                          Originally posted by basshook View Post
                          Basically building events based on "HAI Zone Triggers" works but building events based on "Device Values" for HAI devices is a problem for me.
                          I am thinking of posting the final version of the plug-in that works with the old Omni protocol after I remove support for devices!

                          To fix this:
                          1. Go to the configuration page for the plug-in and turn off all devices.
                          2. Delete all devices created by the plug-in except for those in HAI_System
                          3. Find a way to do everything you want with the plug-in's built in triggers and actions.
                          4. For everything that you cannot get working with the built-in triggers and actions, try harder to find a way to use them!
                          5. If you must have devices, set the number of zones, units, etc. that you USE (configuration page) to the lowest value(s) possible, then...
                          6. Create devices only for those areas where you need them - e.g. do not create thermostat devices if you are not using them. (Configuration page creates devices when you save the changes.)


                          If this still does not work, please open a helpdesk ticket.
                          Regards,

                          Rick Tinker (a.k.a. "Tink")

                          Comment


                          • #14
                            Originally posted by Rick Tinker View Post
                            To the best of my knowledge over the past 5 years there has never been a problem activating an output via event action. Either the number of outputs you are using is configured improperly, you have a version of the firmware that I have not seen/tested, or there is some other new problem associated with expansion outputs that I have never seen.


                            Now THIS is the known issue with expansion zones I mentioned earlier. This probably only happens on zones above the base 16 that come with the panel.



                            I have had issues with devices in the past, but this is a little extreme that they are not working at all - it appears more like the devices are disconnected from the plug-in. That is, they lost their association. This sometimes happens when another plug-in steals the letter code (long story). However, because of the stress already present on the protocol, I have said for a while that you should only use/create devices for those things that you must have devices for - e.g. if you were using MainLobby and wanted to show the status of a door zone. For the first 2-3 years this plug-in never had devices for anything except the main panel status. There is no need for devices except for situations as I mentioned above. The evidence of this is in your next statement:

                            I am thinking of posting the final version of the plug-in that works with the old Omni protocol after I remove support for devices!

                            To fix this:
                            1. Go to the configuration page for the plug-in and turn off all devices.
                            2. Delete all devices created by the plug-in except for those in HAI_System
                            3. Find a way to do everything you want with the plug-in's built in triggers and actions.
                            4. For everything that you cannot get working with the built-in triggers and actions, try harder to find a way to use them!
                            5. If you must have devices, set the number of zones, units, etc. that you USE (configuration page) to the lowest value(s) possible, then...
                            6. Create devices only for those areas where you need them - e.g. do not create thermostat devices if you are not using them. (Configuration page creates devices when you save the changes.)

                            If this still does not work, please open a helpdesk ticket.
                            The out of sync zone status/devices do seem to be on the hardwire expanders and expansion controller.

                            On the outputs, I am testing the base controller output 1 (385) and output 2 (386), not outputs on the expansion controller.

                            Comment


                            • #15
                              Originally posted by Rick Tinker View Post
                              To the best of my knowledge over the past 5 years there has never been a problem activating an output via event action. Either the number of outputs you are using is configured improperly, you have a version of the firmware that I have not seen/tested, or there is some other new problem associated with expansion outputs that I have never seen.


                              Now THIS is the known issue with expansion zones I mentioned earlier. This probably only happens on zones above the base 16 that come with the panel.



                              I have had issues with devices in the past, but this is a little extreme that they are not working at all - it appears more like the devices are disconnected from the plug-in. That is, they lost their association. This sometimes happens when another plug-in steals the letter code (long story). However, because of the stress already present on the protocol, I have said for a while that you should only use/create devices for those things that you must have devices for - e.g. if you were using MainLobby and wanted to show the status of a door zone. For the first 2-3 years this plug-in never had devices for anything except the main panel status. There is no need for devices except for situations as I mentioned above. The evidence of this is in your next statement:

                              I am thinking of posting the final version of the plug-in that works with the old Omni protocol after I remove support for devices!

                              To fix this:
                              1. Go to the configuration page for the plug-in and turn off all devices.
                              2. Delete all devices created by the plug-in except for those in HAI_System
                              3. Find a way to do everything you want with the plug-in's built in triggers and actions.
                              4. For everything that you cannot get working with the built-in triggers and actions, try harder to find a way to use them!
                              5. If you must have devices, set the number of zones, units, etc. that you USE (configuration page) to the lowest value(s) possible, then...
                              6. Create devices only for those areas where you need them - e.g. do not create thermostat devices if you are not using them. (Configuration page creates devices when you save the changes.)
                              If this still does not work, please open a helpdesk ticket.
                              The out of sync zone status/devices do seem to be on the hardwire expanders and expansion controller.

                              On the outputs, I am testing the base controller output 1 (385) and output 2 (386), not outputs on the expansion controller.

                              Comment

                              Working...
                              X