No announcement yet.

mcsControl Systems - Heat Monitoring and Control

  • Filter
  • Time
  • Show
Clear All
new posts

    mcsControl Systems - Heat Monitoring and Control

    and some rooms are either completely unheated or heated by individual baseboard or plug-in room heaters controlled by an appliance module. Will there be any provision for such independent zones? It's not entirely clear from the layout on the HVAC and Zone tabs as they now exist but it looks to me like you contemplate everything to be heated/cooled from one central source, with an auxiliary source available but covering the same area and zone control through dampers (as any sane Architect would design it - but my house just grew and may not be all that atypical).

    What will live behind the Control Criteria button? Is that another setup GUI with tabs, allowing complete day-of-week/time-of-day thermostat programming, with no-occupancy setbacks, etc.? (just asking for information - initially I will have no conrtol over my primary furnace and complete control over the room heaters via X-10)


    I't been months since I last thought about the HVAC portion. My model was a primary and secondary heat source with adjacent zones and outside/sun as additional contributors to energy input. The Heat/AC tab can be generalized just as the Zones are now generalized.

    The control strategy is expected to be something like the Sprinkler control where enablers and disablers are identified to provide a strategy and the primary user interface is via the web to get status and manual/interactive control.

    When I was working on it I could not come up with a good user interface. I did not want to mimic a thermostat since I generally do not find them intuitive. I always need to reference instructions to know how to setup temporary settings.

    I also struggled with the graph of the temperature control bands. Turns out that V3 of chart director is needed to do what I wanted to do. I downloaded it, but have not yet explored.

    Like mcsTemperature the product will evolve base upon user preferences. My focus is on collection and analysis of data and how control strategies can be applied to close a control loop. Open loop/time-based controls will also exist just as with the Sprinkler controller.

    When heating season approaches then I will again start tinking about this part of the plugin. Collect your ideas.


      release date?


        Pacific Northwest Winter


          It was last winter when I started working on it, then did the sprinklers which still have some closed-loop control deficiencies.

          I need to refresh my mind as to what my status is and what I expected to do with it. I know one of my problems was the user interface for the control parameters. I find the traditional thermostat difficult to program, review the program, and know what will happend when manual overrides are taken. This is an area that needs a little brainstorming.

          I know I was working on the graphics of the control bands. I have subsequently found out that I could not do what I wanted with V2.5 of chart director, but a newer version is now out that can accomplish it.

          There are also the thermostatic conrollers (e.g. RCS). How the plugin will handle these or how it will interface with other software that controls them needs to be discussed.

          I know my model for control was a central power plant with secondary backup. Bill Walton mentioned a more distributed model. This needs to be discussed.

          It is probably time to start the discussions.


            My house 1st floor is hotwater pipe in floor
            2nd floor is radiators with thermo valve.
            my idea 2 regulation in central heating and 1 control, and ds18s20 in all room and 1 ds18s20 outdoor
            1th regulation: the boyler cirkulation pump
            2nd regulation: the boylet thermostat
            1th control: the pipe cirkulation with pump very slow reaction


              I may not understand what you mean by regulation. What is the objective of the regulation? Is it any different that a basic thermostat? Are you trying to minimize temperature under/overshoot? Are you trying to account for outside temperature to anticipate when each unit should be turned on? Are you trying to do occupancy-based heat control? Are you trying to understand energy transfer between first and second floors?


                My heating problems:
                1. The 1st floor water only 40 Celsius, and the room temp level up only 1-1,5 hour after circulation pump start.
                2. The house has been 11 windows +1 glass door the first floor and 7 windows +1 glass door the 2nd floor, "greenhouse" effect with sunshine
                3. In boyler only one circulation pump, one thermostat swiching point for 2 heating circle.
                Attached Files


                  The slow transfer function for the water implies that you are looking for something that will learn how long it takes to reach a designated termerature and start the system sufficiently early to reach it.

                  Higher-end typical house thermostats will engage many minutes before the "on" time and then pulse the furnace/boiler so the heat will gradually arrive at the desired temperature and overshoot will be minimized. I do not know what the efficiency of the furnace/boiler is in this mode vs a control strategy that learns how much energy transfer will occur after the furnace is turned off and then turn the furnace off early in anticipation. I suspect the only way to know for certain is to have the fuel use instrumented.

                  The greenhouse effect is also quite feasible to include in the control strategy. One way to anticipate solar energy is by the weather forecast such as is done for the sprinkler control calculation of ET0. It kind of depends upon how much you trust the weatherman and how tolerant you are if the sun does not behave as predicted.

                  Even without forecast you will likely want to measure the amount of solar energy that is being generated. Two parts to this. One is the amount that actually gets throught the windows. This can be done empirically. The second is to know when the sun is out and how intense it is. For this you will want to add a second outside temp sensor at the same approximate location as the first, but exposed to the sun and covered by a clear jar. The temperature delta between the two will represent the solar energy available to supplement house heating.

                  I do not know what you want to do about two heating loops and one thermostat. This can be managed if a valve is installed so a loop can be bypassed. But you may not have the freedom to make plumbing changes. If you do something make certain it is a bypass control rather than on ON/OFF control because you never want to have the boiler on an no means for it to circulate the water.


                    Now, and first step mod heating sheme
                    Attached Files


                      Only inside DS18s20 with DS9097
                      Attached Files


                        I'm starting this thread to try to organize mcsControlSystems related to the design requirements for the heating control aspect of the plugin.

                        I'm going to try to copy prior discussions on this subject into this thread and later remove the original postings. I've "applied" for privledges to do this.

                        [This message was edited by Michael McSharry on Tue, 23 September 2003 at 01:11 AM.]


                          I've looked at using Events with Temperature Controls in combination with DooMotion Occupancy sensors to control infividual room heaters. In general, this approach can work, but it takes several events per room. It would work better if it were integrated with a more general zoning scheme, I think.

                          I also have a problem when I try to combine plugin-provided controls with conditions in an event. I reported this once before, but I think it's a HomeSeer problem. If you set up a Temperature Control, and then add conditions, you can never get back to the Temperature Control to modify its settings. I see this with DooMotion controls as well, so I think it's a general problem with controls supplied by plugins. I did find a workaround - you have to change the Temperature Control to something else, and then back to a Temperature Control. This loses some of the settings but at least you get back to the settings of the control and can make modifications.



                            It would be nice if you could elaborate what works as a "kludge" and what would make it better.

                            I looks to me as if conditions are and after-thought to the homeseer architecture. I've always found them to not be intuitive. Especially when getting into OR conditions. I also noticed that every plugin gets called to evaluate a condition on an event. With a lot of plugins and events and conditions this might start addding up to some overhead.

                            In my case I use scripts for almost all conditional logic, but I suspect that the typical user would like to have a more graphical view.

                            There is nothing of which I am aware that a plugin can do to change the navigation on the homeseer event page. The plugin simply provides a set of controls for homeseer to format in the allocated GUI window and then responds with a yes/no when called to evaluate a trigger or condition.

                            It seems that plugins are becomming a preferred solution over scripts for many applications. There has got to be some cross-over point where the overhead of all the plugin being called for every potential action overcomes any performance advantage that a compiled program has over a tokenized script run under script control that is only called when necessary. From a browser-view perspective there is no difference between a script or a plugin. From the console-view the setup screens are nice, but I'm getting the impression that HS is moving more to a browser-view and what we know today as the GUI may not be around tomorrow.


                              For my office, I've set up three events: one ON event that has a Condition of Office Occupancy IsON and a Temperature Control with decreases to 68, persists for 1 minute and retrigger after 5 minutes; and two OFF events - one that triggers on the Temperature Control with increases to 72 and persists for 1 minute and retrigger after 5 minutes, and one that triggers on DooMotion Trigger Office Occupancy Vacant. These last two might be able to be combined but I culdn't see how, and I was unsure how the two Plugin Controls would interact.

                              I've toyed with DooMotion Custom Action Code, but wasn't sure how to get the Temperature conditions via this method, so haven't finished anything there.

                              To work as a zone control I think I would need to be able to incorporate an Occupancy condition as well as a temperature band, and possibly also time-of-day limits in more than one range (i.e. 5:00 AM to 7:00 AM and 4:00 PM to 11:00 PM M-F, 8:00 AM to 11:00 PM Saturday, 8:00 AM to 10:00 AM and 2:00 PM to 11:00 PM Sunday, or separate 7-day multiple ranges). My furnace thermostat is old and low-tech, but it gives me multipe home, away and asleep modes on a 7-day basis. I like this, and haven't gone to a communicating thermostat because I can't find one at a reasonable price that has this internal programmability. I want Homeseer to give me this kind of control over my separate room heaters as well, but with room occupancy on top.