Home› AMX User Forum› AMXForums Archive Threads› AMX Hardware
Options

HVAC control

amxhobbyistamxhobbyist Posts: 90
in AMX Hardware
Can anyone give me advice on HVAC controllers that work with AMX systems? I need automated control of my system...

edit, this probably should have been posted in AMX Hardware. My bad. Could a moderator move it for me, please?

Comments

  • Options
    Joe HebertJoe Hebert Posts: 2,159
    Hi amxhobbyist,

    Are you referring to T-Stats you can integrate with? If you have a normal forced air HVAC system you may want to check out the AMX HVAC Controls - Viewstat

    Cheers,
    Joe
  • Options
    jeffacojeffaco Posts: 121
    Right. AMX resells these.

    AMX's product is based on Aprilaire's communicating thermostat. The only difference is that AMX's product has an ICSnet interface (it's a device on the NetLinx bus). That's done via a "mini-verter", or "phast-verter" (I never got the exact name of what they called it) that converts from RS-485 (or 422, don't remember) to ICSnet.

    I worked with Aprilaire to test these very early on (before AMX picked up these models), so I don't have the AMX version. End result: I use a single RS-485 communications line to communicate to the thermostats, and each thermostat is a "unit number" on it's bus. Unit 1 controls upstairs, unit 2 controls downstairs, unit 3 controls theatre room, unit 4 controls master bedroom. The protocol is very simple.

    If you're looking to buy these, I prefer that we help AMX, so buy AMX's version! ;-)
  • Options
    DHawthorneDHawthorne Posts: 4,584
    I've used the Aprilaire product quite a lot, and the Viewstat is pretty much the same. A few caveats:

    Out of the box, these are not smart thermostats. They have no internal setback timers or anything of that nature. You will need to track and control all of that in code. If the network goes down, or the controller goes off line, they will happily just keep doing what they were doing until manually changed, or the system comes back up. I learned with complex settings data (I have a customer who wanted 6 time periods per day for each of 18 thermostats) it is critical to store your setback times and values in a persistent variable, or drop it on the drive so they restore themselves on a reset or code change.

    I can't say how well the ICSNET ones work, but the RS-422 buss is delicate on these things. If you poll too frequently, or send too much communications at once, they go into a continuous reboot cycle, and every stat on the buss follows suit. Very irritating, and I had a heck of a time finding the cause of it.
  • Options
    Joe HebertJoe Hebert Posts: 2,159
    Originally posted by DHawthorne
    I can't say how well the ICSNET ones work, but the RS-422 buss is delicate on these things. If you poll too frequently, or send too much communications at once, they go into a continuous reboot cycle, and every stat on the buss follows suit. Very irritating, and I had a heck of a time finding the cause of it.

    I've used the ISCNET versions and I can attest that if you send some commands too quickly they will get missed or misinterpreted. You can blast away sending setpoint up or down commands to one Viewstat but you can't do that with other commands.

    As Dave alluded to, the buss doesn?t do well when it?s flooded. For example if you want to push a button and have several Viewstats change HVAC mode, change fan mode, and have new setpoints, then you really need to build a queue and throttle the commands to be issued.

    I really haven't found the need to poll the stats on a regular basis since they can be configured to interrupt you when changes occur.

    As Jeff mentioned previously the protocol is simple ASCII strings or you can just use the AMX module which works quite well (as long as you throttle the commands in your own code)

    Hope this helps,
    Joe
  • Options
    jeffacojeffaco Posts: 121
    Hmm. Since my HVAC code isn't a module (it's an include file), I never put it on SourceForge. Perhaps I should change that.

    I have a queue in my HVAC include file. You can blast (within limits) commands to the HVAC code, and it works. My HVAC code will queue the command, send it when possible, and wait for the response from the thermostat. If there was no response from the thermostat, it tries again (up to 3 times for a total of 4 attempts). One the confirmation comes in, my module will send the next command in the queue. This covers collisions or other issues that can come up from time to time. I rarely see more than one retry unless a thermostat is offline for some reason.

    I've never observed that the thermostats will lock up if you send commands too often. Is this because you're not waiting for the response/confirmation? If you want for the response/confirm, do you still get that?

    When my system boots, it queries each thermostat (4 of them) for about 10 different parameters. That's 40 messages (and responses) that I'm after. I've never experienced any problem, but then (as I say) I send one message and WAIT for the response. If the response doesn't come, I retry. If the queue is busy when my mainline code tries to send something, then that command is added to the queue, but nothing is transmitted (until the queue is otherwise empty).

    Do you guys do this and still have problems? Or do you just blast data without regards to what's happened lately? If you do that, then that violates the protocol. The protocol is quite specific in terms of when you can send commands, and how long you must wait to retransmit.

    Thanks for the clarification.
  • Options
    amxhobbyistamxhobbyist Posts: 90
    Thanks for all of the info. This looks to be exactly what I need, so I'm buying one.

    I merely have the one thermostat and don't require any sort of complex timing. My main reason for purchasing is to automatically turn the HVAC system off if a door or window is opened for more than x seconds. People keep opening the windows for fresh air and forget to turn the cooling system off. My power bill was about $80 higher than it should have been last month, I suspect due exactly to this issue.

    So, it will no longer be an issue. As a bonus I'll be able to adjust the settings from my bedside touchpanel. ;-)
  • Options
    Joe HebertJoe Hebert Posts: 2,159
    Originally posted by jeffaco
    Do you guys do this and still have problems? Or do you just blast data without regards to what's happened lately? If you do that, then that violates the protocol.

    I found no need to talk to the Viewstats directly since the AMX module works fine for me so I don't know if the protocol is being violated or not. I have no problems at all as long as I put the commands that I send to the module in my own queue first and then pace them out.
  • Options
    Reese JacobsReese Jacobs Posts: 347
    HCAV Control - ViewStats

    As some people have pointed out, the Viewstats can be a problem particularly when there are numerous stats all connected to the same bus and where there is a good deal of communication taking place at the same time. I queue all commands sent to the AMX ViewStat module and the AMX module also carefully times its commands to the ViewStats but I have seen instances where a command does not receive a response. Therefore, I write my module interface for the ViewStat to deal with these conditions by re-issuing commands when necessary. AMX does have a good Netlinx/Axcess module and code block for the stat and it integrates well so the ViewStat is an obvious good choice and represents a significant improvement over the OPStat predecessor.

    A couple of notes - be sure to correctly configure the thermostat when installing it to set the 'Number of Stats' on the network correctly. By default, the thermostat ships with this value set to 32 but it should be lowered to the maximum number of stats in your configuration. The reason is that this affects the time required by the stats to process the commands and to respond to commands. The ViewStats, like the OPStat series that preceeded them, use a time slice mechanism for command and response processing. The ViewStat is much better than the OPStat models but this parameter can make a real difference in response time. Also, number your stats starting at 1 and number them sequentially as this optimizes the time for command and response processing. The AMX ViewStat module throttles commands to the stats it is managing based on the number of stats you tell it to control but observing these setup guidelines can make a real difference in performance.

    By the way, did anyone see the next generation AprilAire thermostat at CEDIA? It has a much different footprint than the ViewStat as well as communication improvements. I am not sure if or when it will be part of the AMX product line.
  • Options
    DHawthorneDHawthorne Posts: 4,584
    Originally posted by jeffaco
    I have a queue in my HVAC include file. You can blast (within limits) commands to the HVAC code, and it works. My HVAC code will queue the command, send it when possible, and wait for the response from the thermostat. If there was no response from the thermostat, it tries again (up to 3 times for a total of 4 attempts). One the confirmation comes in, my module will send the next command in the queue. This covers collisions or other issues that can come up from time to time. I rarely see more than one retry unless a thermostat is offline for some reason.

    I've never observed that the thermostats will lock up if you send commands too often. Is this because you're not waiting for the response/confirmation? If you want for the response/confirm, do you still get that?
    My module was modified legacy code originally written for the Statnet series, which did not properly report changes unless polled. I had re-written a lot of it, but the polling stayed in, and that was what caused the trouble I had. Greating increasing the interval fixed it. I also use a single panel screen for all the thermostats, and, for the sake of insuring up-to-date data, will poll the thermostat when the target stat changes, but this doesn't constitute much of a load on buss traffic. But it was polling I was warning about; if you have a lot of thermostats and are tracking a lot of data, you have to be careful about it, and, as suggested, wait for respones before sending the next command. You can't simply ask the entire buss for every parameter and wait for it all to come in.
  • Options
    Spire_JeffSpire_Jeff Posts: 1,917
    Originally posted by jeffaco
    Hmm. Since my HVAC code isn't a module (it's an include file), I never put it on SourceForge. Perhaps I should change that.

    Jeff,

    If you don't mind, I would love to look at the code you have for HVAC. I have some code that is functional, but still could be improved and looking at your code may give me some new ideas. I'm not sure which would be easier for you, posting on sourceforge or posting the in ACE code section of these forums, but if you get a chance, let me know so I can grab a copy.

    Thanks,
    Jeff
  • Options
    jeffacojeffaco Posts: 121
    HVAC Source Code

    Okay, I've checked in my HVAC source code to SourceForge as requested.

    There was more there as I took a look. I have a .txt file to explain how it works, some sample code, even a .TPD file.

    That said, the bits were there, but I didn't really look at them. I *KNOW* that the .axi file works - I use that daily. The .txt file looked fine. But I didn't look at the sample driver or the .TPD file, so I can't comment on that (I'm sure they were fine at one time, at least I'd think, unless they were work in progress that I never got around to finishing).

    I spent a fair amount of time tuning the transmission code to deal with retries and the like. If you have problems blasting all the commands that you want (i.e. if you get lockups, consistently missed commands, etc), then by all means let me know, and I'll take a look. If you need to increase the size of the queue, feel free to modify the .axi file. The power of open source and all that.

    The file works well for me with four zones, and I'm quite confident that I follow the protocol rules correctly (I chatted with the firmware developer about that before their documentation was improved).

    It's bogus to have to have your own queue head of this code; I call that a "bug", and you shouldn't need that. You should be able to just queue a command and, if the thermostat is on the bus, it should get the command and process it.

    Any problems, let me know.

    If I were to write this today, I'd make it a module for sure. But the .AXI file works fine. Who knows, perhaps rather than a NetLinx module, this may be rewritten as a Duet module sometime? ;-)
  • Options
    Spire_JeffSpire_Jeff Posts: 1,917
    Re: HVAC Source Code
    Originally posted by jeffaco
    Okay, I've checked in my HVAC source code to SourceForge as requested.

    I appreciate the posting, and I hate to be a bother, but could you post a link to your sourceforge site again? I tried the one that was posted a while back by you, but I am not seeing anything regarding the HVAC code. Or is that the correct address and I just have to wait for sourceforge to update?

    Thanks again,
    Jeff
  • Options
    jeffacojeffaco Posts: 121
    Hi Jeff,
    I appreciate the posting, and I hate to be a bother, but could you post a link to your sourceforge site again?

    I'm not sure why you didn't find the HVAC stuff. When you browse CVS, you browse CVS - it's the actual source code.

    In any case, here's the link:

    http://cvs.sourceforge.net/viewcvs.py/netlinx-modules/NetLinx-Modules/

    -- Jeff
  • Options
    Spire_JeffSpire_Jeff Posts: 1,917
    Thanks, I am guessing that it was an issue of timing.... I was at the right site, but the HVAC folder wasn't showing up. Got it now and I'll take a look at it.

    Thanks again,
    Jeff

    Originally posted by jeffaco
    Hi Jeff,



    I'm not sure why you didn't find the HVAC stuff. When you browse CVS, you browse CVS - it's the actual source code.

    In any case, here's the link:

    http://cvs.sourceforge.net/viewcvs.py/netlinx-modules/NetLinx-Modules/

    -- Jeff
Sign In or Register to comment.