Announcement

Collapse
No announcement yet.

Honeywell Enviracom Zone Controllers

Collapse
X
 
  • Filter
  • Time
  • Show
Clear All
new posts

    Honeywell Enviracom Zone Controllers

    Has anyone tried to make Homeseer talk to a Honeywell Enviracom system? I have three units with zone controllers attached to Honeywell Enviracom Serial Adapters and I am looking over the protocol documents.

    I just wondered if anyone had tried this before I tackle trying to write some kind of plugin.

    Mitch

    #2
    This is only the second time I've ever heard these stats mentioned. The other time was here:
    http://board.homeseer.com/showthread...well+Enviracom
    💁‍♂️ Support & Customer Service 🙋‍♂️ Sales Questions 🛒 Shop HomeSeer Products

    Comment


      #3
      So I'll have to look at doing it myself I guess -- is there source code available to a good skeleton plugin I can look at for T-Stat interfacing?

      The Enviracom system uses a serial RS232C interface transmitting ascii text so it should be reasonably easy to parse.

      I've tried to put together a stand alone application using the Enviracom API sources, but there are some threading contortions needed to tie their C api to a Windows GUI -- using overlapped I/O I am making progress -- reading byte by byte.

      However, I am thinking it would be better to take advantage of the fact that the protocol is always ASCII with a CRLF terminator and just try reading messages as strings.

      Rupp -- any thoughts on how to approach this?

      Comment


        #4
        The HomeSeer SDK has a "sample" plugin you can use as a startup project. The SDK is available via the HomeSeer updater.
        💁‍♂️ Support & Customer Service 🙋‍♂️ Sales Questions 🛒 Shop HomeSeer Products

        Comment


          #5
          If you are referring to the Acme Widgets security panel example, I have looked at that one -- nothing about Thermostats in it. I have a much better one written in C# that I have been referencing, but again no thermostat info.

          Looks like I will have to poke around the docs some more...

          Comment


            #6
            Originally posted by mitchmitchell1616 View Post
            If you are referring to the Acme Widgets security panel example, I have looked at that one -- nothing about Thermostats in it. I have a much better one written in C# that I have been referencing, but again no thermostat info.

            Looks like I will have to poke around the docs some more...
            The thermostat "info/sdk" is in the HomeSeer SDK's documentation.
            💁‍♂️ Support & Customer Service 🙋‍♂️ Sales Questions 🛒 Shop HomeSeer Products

            Comment


              #7
              Yes, I looked over that information. Correct me if my assumptions are incorrect here:

              1. It looks like homeseer doesn't care if any two thermostats happen to be attached to the same or different units. e.g. The fact that two thermostats are on the same zone controller would not be relavent information for homeseer's thermostat model.

              2. The Thermostat API doesn't appear to support programmable thermostats with scheduling. I'm wondering how these settings could be modeled == essentially each thermostat has a cool and heat set point, plus 4x7 additional heat and cool set points that have day of week and time associated with them (Sun-Sat, Wake, Leave, Return, Sleep). Could this be modeled with meta data associated to the thermostat devices in homeseer?

              3. Since the plugin does need to know which zone controller each thermostat is attached to (since this changes the com port it has to issue commands to for that thermostat), could this be stored in the devices in homeseer even though the API does not directly support this information?

              Thanks!

              Mitch

              Comment


                #8
                Originally posted by mitchmitchell1616 View Post
                So I'll have to look at doing it myself I guess -- is there source code available to a good skeleton plugin I can look at for T-Stat interfacing?

                The Enviracom system uses a serial RS232C interface transmitting ascii text so it should be reasonably easy to parse.

                I've tried to put together a stand alone application using the Enviracom API sources, but there are some threading contortions needed to tie their C api to a Windows GUI -- using overlapped I/O I am making progress -- reading byte by byte.

                However, I am thinking it would be better to take advantage of the fact that the protocol is always ASCII with a CRLF terminator and just try reading messages as strings.

                Rupp -- any thoughts on how to approach this?
                i found some source code on sourceforge that a PHD guy wrote and built a API. i am no programmer but i think its what you are looking for. I have a Control4 system in my home but still trying to figure out how to build the driver to control the HVAC system. know anoyne that is a wizard at this stuff? i can email or send you a link ot the source files if you want. just email me thejoeloomis@gmail.com

                joe

                Comment


                  #9
                  Ok, progress -- I have a skeleton plugin up and logging the serial messages received from the adapter. Now I have to work on setting up the thermostat devices. After that, I have to figure out how to deal with schedules on the programmable thermostats and make them available to homeseer since it looks like the thermostat api doesn't support that natively.

                  Comment


                    #10
                    Originally posted by mitchmitchell1616 View Post
                    Ok, progress -- I have a skeleton plugin up and logging the serial messages received from the adapter. Now I have to work on setting up the thermostat devices. After that, I have to figure out how to deal with schedules on the programmable thermostats and make them available to homeseer since it looks like the thermostat api doesn't support that natively.
                    good work mitch. i am keeping my eye on this. hopefully you get it working becuase we both know, if you do, we all do. i wish i knew more about programming serial devices. ha

                    Comment


                      #11
                      It all depends upon whether I can puzzle out the thermostat interface, but if I get it working I will certainly share!

                      Comment


                        #12
                        I looked at the sourceforge code for the Enviracom and, well, lemme just say that I am writing my own. I opted to do more-or-less as mitchmitchell1616 speculated and just read newline-terminated strings and handle complete packets. It greatly simplifies the logic and improves the readability of the code.

                        This is for Unix systems, so I doubt the code would be of much value to Windows folks, though I am happy to share in any case.

                        Unfortunately, the sourceforge code only understands a few message types, and not even all message instance types, and even *then* only a few bytes out of most of the messages it *does* handle. If somebody could point me toward a more-complete doc for the Enviracom, I'd really appreciate it.

                        (For example, I'm trying to figure out from the sourceforge code how to detect whether the "Aux Heat" (in my case, a 5000W electric) is turned on, but the code just doesn't seem to do that.)

                        Thanks.

                        Comment


                          #13
                          A little more progress. I have the Thermostat APIs in place and have verified that I can call them from a script. I'm assuming they have to be methods off of the HSPI class.

                          I discovered that when debugging checksum routines in Homeseer it is necessary to have a ratio of one line of code to three lines of debug print statements. I'm going to have to see about setting up a development instance of homeseer on my dev machine.

                          So messages are being decoded, checksum verified and logged. Not doing anything with the data yet, but I will probably have to build an in-memory representation of the thermostats and tie them to Homeseer devices.

                          Still not sure how to handle multiple instances of the plugin -- essentially in homes with more than one HVAC unit (and therefore more than one controller and more than one serial interface) the plugin has to talk to mulitple com ports and keep the thermostat assignments sorted out. I'm hoping for suggestions on this one!

                          Comment


                            #14
                            RS-232C communication in an uncertain world

                            Originally posted by mitchmitchell1616 View Post
                            However, I am thinking it would be better to take advantage of the fact that the protocol is always ASCII with a CRLF terminator and just try reading messages as strings.
                            I hope I'm not speaking out of turn here, but ...

                            Reading the serial line as newline-terminated ASCII strings (with or without C standard I/O) works. That's how my program is doing it right now, and my monitor has been working just fine for the last couple of days since I consed it up.

                            To be really robust, however, you may wish to account for the fact that the serial line can be noisy, and might also get unplugged in the middle of transmitting a packet. You'll have to decide for yourself how much you really want to worry about this, but I've dealt with this sort of thing in hospitals and mechanical rooms (which are both really EM-noisy).

                            The correct approach would be to read the serial port one byte at a time and build up the newline-terminated packets yourself. This should be done in raw rather than cooked mode, because if the line gets noisy, you'll get all kinds of bogus and unexpected "characters" as input. You'll then need to detect when things go south (illegal characters, too-long packets, etc.), and have some way of recovering from that and resyncing with the protocol (for the Enviracom, you might consider throwing away data until you see one of H or M or L).

                            To account for unplugging the serial cable, you might want to set a short timer at the beginning of a protocol packet. You then cancel the timer when you see the terminating newline. If, instead, the timer goes off, you can presume that something somewhere has abruptly stopped talking. A response to that might simply be to do a blocking read for a single character in order to wait for communication to come back to life.

                            Edit: I should also mention that a way to do this without requiring nearly so many read() system calls would be to have the read accumulate characters for a hundred milliseconds or so (plenty long enough to receive entire packets at 19.2k baud) at each read. That way, you'll tend to get full packets on each read, but at the same time won't wind up blocking forever if the comm goes sour.
                            Last edited by ; January 15, 2010, 04:47 PM. Reason: added information

                            Comment


                              #15
                              Originally posted by astrotrf View Post
                              To be really robust, however, you may wish to account for the fact that the serial line can be noisy, and might also get unplugged in the middle of transmitting a packet.
                              Definitely not out of turn at all, thank you for your comments!

                              I have the com port doing a callback on its own thread so the read does not block the plug in. I'm really wanted to avoid byte by byte reads to keep things simple if possible.

                              The messages have a well defined structure so I can detect most problems that way, and they are checksummed so I don't think it likely to treat bad messages as valid data.

                              One thing I need to watch out for are the cases where (for example) a USB to Serial adapter is pulled out and the device simply disappears or where line noise causes a read to terminate before a full message is received. I'm going to have to carefully use try/catch blocks to handle that.

                              A more interesting problem will be insuring that the plug-in only transmits data when the Enviracom adapter is ready to accept it. There are some comments in the Enviracom API sources that make it seem like the bus does not like getting message sent to it at the same time it is transmitting through the serial adapter. I'm going to have to experiment a bit to check that out.

                              Keep the notes coming! I'll be working on the thermostat object model tonight.

                              Comment

                              Working...
                              X