Announcement

Collapse
No announcement yet.

HAI or ELK plugin

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

    HAI or ELK plugin

    Hi -
    I currently have an Omni LT on my vacation house and am doing construction on my primary residence so I'm in the market for a new panel for the primary residence. I've done loads of research on both the Elk M1Gold and the Omni Pro II and haven't come to the conclusion that one is that much better than the other for my needs. Being that I have experience with the HAI I'm sort of leaning in that direction.

    So my question is not which is better HAI or ELK, but rather, is there a big difference in how the plugins for the respective panels work with Homeseer? Maybe this can be my deciding factor :-)

    The one thing I noticed when using the HAI plugin was that the integration with UPB wasn't great (based on comments from Rick about how HAI implemented their UPB). I really want to have as much of this controlled by either the Omni or the Elk and not rely on a PC running Homeseer.

    Any comments on one or the other of the plugins being much better than the other?

    Thanks for your help.

    Pat

    #2
    You will never get tight UPB integration with an HAI panel - you will get all of the features of UPB accessible with our UPB plug-in, but that requires a PC. If you look at the HAI protocol and how they fit new lighting technologies into it, you will see it is the same formula every time, and additional features such as scenes, broadcast commands, etc. are rarely implemented.

    The base level UPB features are probably covered in what the HAI plug-in provides, so it probably is not much of a trade-off, but I think you are still limiting yourself considerably compared to running the standalone UPB plug-in which exposes pretty much everything you can do with the technology.

    Need I repeat my rants about PC reliability?
    Regards,

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

    Comment


      #3
      Hi Rick -

      Thanks for the reply. I agree on the UPB functionality. In fact so much that I did buy the UPB plugin for Homeseer. And I'm with you on the PC reliability so no need to go down that path :-)

      What I'm really hoping for though is some opinions on both plugins and how they work with their respective panels. The UPB comment was just an example of one of the challenges on the HAI side.

      Thanks.

      Pat

      Comment


        #4
        The HAI plug-in has been a CONSTANT challenge since the HAI protocol is binary, requires that the panel be polled to get information (e.g. does not notify you when something changes), and their Ethernet interface implementation in their own DLL is so strange that I have yet to conquer it.

        My guess is that the HAI panel plug-in has much more functionality supported at this time, but reliability of the communications is probably with the Elk one, but I have no data to back that up as I have no experience with the panel or the plug-in. I am working on adding Ethernet support to the HAI plug-in and am rewriting the serial communications now that I have the plug-in written in .NET.
        Regards,

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

        Comment


          #5
          The ELK panel plug-in is getting better. It is now quite robust. Between the rules, variables, and virtual I/O there is verry little that can not be done. The ELK transmits on a device change so it is pretty snappy, just a bit faster at recognizing motion sensor trips than my X10 RF sensors going into a W800.

          I have also been able to fully utilize the 2nd display line of the ELK keypads to allow the display of any text I like from HomeSeer without disturbing the normal security system display. Scrolling weather warnings and the like.

          The UPB support in the ELK is pretty basic (like HAI) but the fact is that UPB devices control each other pretty well so if HomeSeer goes down I still get reasonable lighting control.

          Jon


          Originally posted by Rick Tinker
          The HAI plug-in has been a CONSTANT challenge since the HAI protocol is binary, requires that the panel be polled to get information (e.g. does not notify you when something changes), and their Ethernet interface implementation in their own DLL is so strange that I have yet to conquer it.

          My guess is that the HAI panel plug-in has much more functionality supported at this time, but reliability of the communications is probably with the Elk one, but I have no data to back that up as I have no experience with the panel or the plug-in. I am working on adding Ethernet support to the HAI plug-in and am rewriting the serial communications now that I have the plug-in written in .NET.
          Jon Ort
          JonOrt@The--Orts.com
          (Remove the dashes in the address, spam is getting out of hand)

          Comment


            #6
            Hi Jon -

            Thanks for the response. I was reading through the Serial Expander manual for the Elk and came across this warning:

            "Limitations: UPB modules will not send their recent status changes in response to link commands. Therefore, the status displayed by the M1 Controller may not always match the true status of UPB devices if they have been controlled by a Link command."

            As far as you know is this really the case? That would seem to be a real problem. Currently I use Links for a significant amount of logic in the UPB switches and would hate to lose the ability to keep track of the light status. In the UPB plugin for Homeseer the status seems to work perfect. I haven't tested how it works in my OmniLT but will do so this weekend.

            Thanks,

            Pat

            Comment


              #7
              Originally posted by beerguy
              Hi Jon -

              Thanks for the response. I was reading through the Serial Expander manual for the Elk and came across this warning:

              "Limitations: UPB modules will not send their recent status changes in response to link commands. Therefore, the status displayed by the M1 Controller may not always match the true status of UPB devices if they have been controlled by a Link command."

              As far as you know is this really the case? That would seem to be a real problem. Currently I use Links for a significant amount of logic in the UPB switches and would hate to lose the ability to keep track of the light status. In the UPB plugin for Homeseer the status seems to work perfect. I haven't tested how it works in my OmniLT but will do so this weekend.

              Thanks,

              Pat
              I use link commands EXTENSIVELY, and Homeseer always seems to know the status of the devices, so I believe that your "limitations" quote is not accurate, at least as far as the UPB underlying hardware is concerned. I cannot commetn on Elk's UPB support. Now there are a couple problems with link commands. Since the sending unit does not know which devices are going to respond, it cannot wait for an acknowledgement from each device. With device commands, the transmission is pretty sure, becaue there is an acknowledge protocol. Second, I'm not sure the status updatres are acknowledfged and retried, as I do sometime see HS out of sync with reality (but this may still be errors in my rather extensive and complicated event triggers and scripts).

              But my overall experience is that link commadns are very reliable and the status feedback from the devvices is siumilarly reliable (maybe not quite as good, but still 95%+ and maybe higher once I figure out my evvent problems).

              Pete

              Comment


                #8
                The logic that the HomeSeer plug-in uses to understand all device states and changes based on all UPB traffic is extremely complex and requires a complete system description (provided by the UPStart export file).

                All of the current "panel" systems use basic X10 like mapping to support their lighting systems. It would simply require too much processing and memory to do anything else.

                Therefore they won't interpret link / group commands, they will only interpret direct commands. They can generally send a link command to do complex lighting control but they can't interpret what that command will do.

                This is why I have HomeSeer :>


                Jon


                Originally posted by pete@malibubeach.com
                I use link commands EXTENSIVELY, and Homeseer always seems to know the status of the devices, so I believe that your "limitations" quote is not accurate, at least as far as the UPB underlying hardware is concerned. I cannot commetn on Elk's UPB support. Now there are a couple problems with link commands. Since the sending unit does not know which devices are going to respond, it cannot wait for an acknowledgement from each device. With device commands, the transmission is pretty sure, becaue there is an acknowledge protocol. Second, I'm not sure the status updatres are acknowledfged and retried, as I do sometime see HS out of sync with reality (but this may still be errors in my rather extensive and complicated event triggers and scripts).

                But my overall experience is that link commadns are very reliable and the status feedback from the devvices is siumilarly reliable (maybe not quite as good, but still 95%+ and maybe higher once I figure out my evvent problems).

                Pete
                Jon Ort
                JonOrt@The--Orts.com
                (Remove the dashes in the address, spam is getting out of hand)

                Comment


                  #9
                  So Jon, are you saying that the devices do not sned back status after they process a link command? But instead, the plug-in processes link commands (both from Homeseer and those that it sees on the line) and anticipates what devices will respond and what their response will be, bBased on the info in the export file?

                  Pete

                  Comment

                  Working...
                  X