32 temp sensors & 12 thermostat network

I am in the brainstorming phase here. Any help is appreciated.

Here in the 35,000 ft2 school we have 12 2-stage HVAC rooftop units (RTUs), each with a thermostat attached. The current thermostats are controlled with 24VAC, supplied by the RTUs, with battery backup. I would like to accomplish the following:

  1. Consolidate all of the thermostat controls to one central location with a display and buttons for control.
  2. Take temperature readings in a maximum of 35 locations in the building and deliver them back to the central location (master arduino?) for logging/analysis/and thermostat operation.

In its most simple form, that is the idea. The end goal will include a bank of 7 segment or lcd displays and a set of buttons for the different units to allow control similar to a traditional wall-mounted thermostat. Perhaps one day a web interface with graphs, etc.

I am pretty sure I will need an arduino for each RTU, although, perhaps I can get enough close together to consolidate two or three units to be controlled by the same board. In other words, I don't think I can run 200 feet of cable from the contacts in the furthest RTU directly to an arduino in the central location. (I think there are some distance limitations for the cable here.) Hence a separate arduino for each unit, I am thinking a pro mini, perhaps?

Physically connecting things will not be a problem, nor will running any additional low voltage for arduinos or sensors, we have a drop ceiling and plenty of space to play with.

Now for my questions:

  1. For sensors, should I go the route of 1-wire devices, and if so, can I control them with an adapter like the HA7S or the DS2482-800? Or should I look into something else?
  2. Am I beyond the capabilities of an arduino network, should I jump to something more robust like a Raspberry Pi? Or maybe combine the two?
  1. Consolidate all of the thermostat controls to one central location with a display and buttons for control.
  2. Take temperature readings in a maximum of 35 locations in the building and deliver them back to the central location (master arduino?) for logging/analysis/and thermostat operation.

A1: has your HVAC contractor for maintenance contract an "answer" for the consolidation that s/he will support in your maintenance contract? If maintenance is in house or county Plant, have they any suggestions? Unless you own and have complete control over the facility, you could design and implement yourself into an unsupported nightmare.

If you are the big cheese in charge of everything in a private school, you must first consider redundancy ... Bringing 12 RTU controls into one location must be considered. Secondly, what is the existing control methodology; that is, make-break temperature thermostat or is there logic in them controllers?

Are any of the current units set-up in "zone" configurations? Should there be zones?

And lots more questions...

My suggestion is to seek out as licensed professional to work through your concerns and also deal with city/county codes and license requirements.

Ray

Thanks for the reply. Don't worry, a lot of the information I have gathered so far on this topic has been of the "caveat emptor" variety. While I am not an HVAC expert, I know that throttling a blower or continuously cycling a unit can slug a compressor or burn up the heating elements. I don't plan on doing anything drastic, certainly not at this point.

you could design and implement yourself into an unsupported nightmare.

Part of the design is to make the connections for the arduinos in place of the existing thermostats, allowing for them to be removed and replaced at any time.

If you are the big cheese in charge of everything in a private school, you must first consider redundancy ... Bringing 12 RTU controls into one location must be considered.

Yes, I am the Operations big cheese, if you want to call me that!

Locating all of these into a central location is part of the design to more closely monitor them and watch for problems. I am the one who is responsible for making service calls, scheduling maintenance, etc. I am also the one who gets the call when someone is cold or too hot. So that means that these days I am hauling myself around the building half the day. Also in unoccupied parts of the building, a unit could run for weeks without anyone being aware.

Another example, one group switched classrooms. The old room is now unoccupied, and is controlling the temp based on the conditions in an unoccupied room, not the conditions in the other five rooms that it services. And those other five teachers know where to find me...

I will be starting with the temp sensor network to gather data before anything else begins.

Secondly, what is the existing control methodology; that is, make-break temperature thermostat or is there logic in them controllers?

Well, this one is more difficult to answer. Regarding the thermostats: I am concerned because we have multi stage units, but the "licensed professional" that does "non-in-house" repairs has been replacing our old thermostats with models that do not support two stage control. So, yes, I plan on asking him why he is doing this. The old units were Honeywells which I am almost sure had software that could track their progress to the set temp an account for overshoot, etc.

For the unit closest to my office I plan on connecting to the 24v lines and logging when the thermostat calls for each stage, etc. Nothing too invasive.

Basically, I want to know the answer to the question before I ask the question. I want to know what the temperature swing is in the building at different times, how does it relate to weather conditions, in other words, a lot of data gathering before I start slapping relays onto things I shouldn't.

Are any of the current units set-up in "zone" configurations? Should there be zones?

.

No zones as such, see above.

Thanks again and I look forward to your reply.

Basically, I want to know the answer to the question before I ask the question. I want to know what the temperature swing is in the building at different times, how does it relate to weather conditions, in other words, a lot of data gathering before I start slapping relays onto things I shouldn't.

I like your style and data gathering is the right start. http://jeelabs.org is well about physical computing and offers some possibly interesting products, too, for data logging. Some are wireless but others just make use of SD cards. All have well vetted power management for long battery life. This will give you lots of ideas. You may elect to build your own depending on budget. Adafruit http://www.adafruit.com and Sparkfun https://www.sparkfun.com are also good sources of inspiration for diversity thinking.

Idea: investigate the thermostat options offered by the HVAC manufacturer for your equipment model. Even 10 years back, many were uC controlled and mayy have more sophistication than you realize (or, "had" as some devices have been downgraded.)

As you likely know, pulling and terminating the wiring will require a low-voltage licensed entity. Local regulations may specify plenum cable.

HVAC is really a study in PID controllers and there are some Arduino libraries, one GitHub - br3ttb/Arduino-PID-Library which may be useful for study.

I would give serious consideration to RTOS. Let me say that again, I would give serious consideration to RTOS. There are a few gurus in the forum on this subject. Unfortunately, I am not one.

It's all a bit nebulous, but it is not too early to start putting down your requirements and priorities.

Ray

Thanks I like my style too.

That jeelabs seems to be pretty close to what I might be looking for. That would beat running another 2k feet of cat5e, and it would also beat paying $$$ for xbee modules. Do I understand that right, the data hops from one sensor to the other until it gets to where it is going?

I haven't looked into options offered by the manufacturer for thermostats. Although my research a couple of years ago revealed an aftermarket option for a Ethernet enabled thermostat system, the cost being about $200 per unit. Along the lines of the Nest thermostat, but hard wired. Wireless could be an option, but since we have no wireless infrastructure in place it would mean having to deploy that first.

That PID approach seems like exactly like what I would be looking for if/when I get to that stage.

I hear you on the RTOS, but that sounds pretty involved. What can an RTOS do that a sketch cannot?

And nebulous is definitely a good way to describe it.

I've been doing more thinking about this issue of the temp sensor network. Here are my preliminary options:

Option A: 1Wire sensor network

Costs:
32 1Wire temp sensors
Master chip for 1wire
Cat5e cable running in a ~2000 ft loop
Associated connectors, etc.

Advatanges:
Possibly cheaper than other options?
1 run of cable
no low voltage at each location using parasitic power? (probably just wishful thinking)

Disadvantages:
1 run of cable
Possibly more difficult to troubleshoot?

Option B: Jeelink/RF "WSN"

Costs:
32 less expensive sensors
Arduinos w/ RF or Jeelink nodes at every temp location
Low voltage at each location

Advantages:
Minimal/no cable runs

Disadvantages:
Unforseen RF interference?
More costly
unreliable?

Option C: Ethernet arduino network of arduinos w/ sensors

Costs:
5000 ft of cat5e :astonished: plus other infrastructure
Ethernet enabled Arduinos at every location
low voltage at each location
32 less expensive temp sensors

Advantages:
Most reliable?
Less code to write to enable communication? (just my perception, maybe not correct)

Disadvantages:
most costly
Lots of cable to run.

Option D: Hybrid of A&C or B&C

Hardwire arduino units that are used for actual RTU control with connected sensor networks via RF or 1wire

Thoughts on reliability, feasibility, costs, difficulty, available software, reinventing the wheel, etc?

I cannot see 1-wire working reliably in that situation, and especially not with parasitic power.

IMO Ethernet is way over kill and expensive with Arduinos and shields (or Yuns) at every node.

I've always thought of wireless as being less than reliable, but I admit I don't know much about it and things have got better of late. Will you have local power? If not you'll probably have to run a wire anyway, although the Jeenodes seem to run on the smell of a lithium battery.

There is another option, a DIY RS-485 network just using async serial.

Will the cable run really be 5000ft? In the 1-wire section you say 2000.


Rob

I cannot see 1-wire working reliably in that situation, and especially not with parasitic power.

Yeah I figured it would require local power or at least power sent down a different set of conductors.

IMO Ethernet is way over kill and expensive with Arduinos and shields (or Yuns) at every node.

I think it's probably overkill too, but it is technically an option, so I thought I'd throw it out there.

I've always thought of wireless as being less than reliable,

I am concerned about this too. And for clarity, we are talking about RF, not WiFi. I have no existing WiFi infrastructure in the building.

Will you have local power?

Yes, I can arrange for local power with minimal wire runs in each room.

There is another option, a DIY RS-485 network just using async serial.

I had considered this and I have two RS-485 modules on order. Is there a way to connect the temp sensor directly to an RS-485 module without an arduino present?? I would still have to run wire, although it would be less expensive, presumably than cat5e. And could I deliver low voltage power via different conductors in the same cable perhaps?

Will the cable run really be 5000ft? In the 1-wire section you say 2000.

For the 1wire solution I imagine using a master such as this: HA7S - ASCII TTL 1-Wire Host Adapter SIP, which says is can support runs of up to 100 devices and 1000 ft of cable. I estimate two runs around the perimeter of the building would take 2000 ft, think of a big curly @ symbol, starting in the central location and spiraling out into the classrooms with sensors all along the wire. Although, I have no idea what software would allow this device to interface to the arduino, but we can get to that later, I suppose.

If I do an wired ethernet network with the associated hardware, it would be a "star" style network with each sensor on its own arduino "node". And that would take 5000+ feet of cable. I know this because we recently deployed an IP phone system which required such a network and we used 5+ 1000ft spools of cat5e.

Unless I am missing something?

Thanks.

put on each thermostat a arduino or a simple atmega 328
make simple serial communications in a network in same cable power suply of 9 volts
use rs485 or simpler i2c on slower speeds the master is the clock ! two simple resistors are enough.
if AHU have a valve or fan you can control every room separate. the roofunit can be switched on demand.of pressure.
for temp sensors use with a high resolution to avoid big tempswings
for outputs use small relais.

Quote
I've always thought of wireless as being less than reliable,

I am concerned about this too. And for clarity, we are talking about RF, not WiFi. I have no existing WiFi infrastructure in the building.

An academic article (no need to sigh-up, just close and read online):

Maybe this will answer some of the questions... or promote others!

Ray

Added:
The non-academic article:
http://www.johnhenryshammer.com/WOW2/pagesHowTo/networkOverview.php#index

I just read the last para

Overall, the performance analysis shows that the XBee ZBmodule is more suitable for low data rate applications not having very high reliability and real-time deadlines

Maybe "real time" doesn't matter in this case but reliability always matters.


Rob

Overall, the performance analysis shows that the XBee ZBmodule is more suitable for low data rate applications not having very high reliability and real-time deadlines

Maybe "real time" doesn't matter in this case but reliability always matters.

From what I get, reliability is not compromised, but may be time-displaced if we assume that the XBee is allowed to sleep. But, this decision has not been made. Surely electricity is available in many locations (maybe all) due to regulatory requirements for such items as EXIT signs, smoke detectors, etc. If the mess network is always awake, the bias changes. If the mess network is allowed to sleep, then perhaps some computing resources need to be allocated on a rule-based override. Example: If home-base has not communicated in 30 minutes and the temperature is (above X) or (below N) take this action... etc.

There are different kinds of reliability. Quality design and prudent implementation ensures that redundancy exists as required to support the system metrics.

Ray

I would absolutely love to help you implement this! Sounds like a lot of fun.

Have you considered one Ethernet enabled Arduino per, say, five rooms? Would that save you any cable? One Arduino would monitor and control 5 rooms. Then you would only need to run ethernet cable from the Arduino to the nearest Ethernet jack if there is one available and some more cable to each sensor/thermostat relay.

Have you considered one Ethernet enabled Arduino per, say, five rooms? Would that save you any cable? One Arduino would monitor and control 5 rooms.

Yeah this was secret option D from my post on the 9th. I already figure that to bring the thing to completion I will have to Ethernet hardwire at a minimum the 12 thermostat arduinos. So that would cut my number of independent temp sensors to 20. If I divide those up across the 12 ""thermostats" then I would be essentially be adding two additional sensors per, maybe more depending on the physical layout of the network. One here, three there, and so on.

...some more cable to each sensor/thermostat relay.

This is the part that I am freaked out about now. When connecting the temp sensors, what kind of master chip do I use, and what one has the library already written? Do I even need one, or can I connect them right to he arduino? What kind of cable length limits are we talking? I'm not looking to reinvent the wheel here. I can find bits and pieces of this puzzle around on the forums and with various Google searches, but no one who has documented something similar from start to finish.

mrburnette:

Overall, the performance analysis shows that the XBee ZBmodule is more suitable for low data rate applications not having very high reliability and real-time deadlines

Maybe "real time" doesn't matter in this case but reliability always matters.

From what I get, reliability is not compromised, but may be time-displaced if we assume that the XBee is allowed to sleep. But, this decision has not been made. Surely electricity is available in many locations (maybe all) due to regulatory requirements for such items as EXIT signs, smoke detectors, etc. If the mess network is always awake, the bias changes. If the mess network is allowed to sleep, then perhaps some computing resources need to be allocated on a rule-based override. Example: If home-base has not communicated in 30 minutes and the temperature is (above X) or (below N) take this action... etc.

There are different kinds of reliability. Quality design and prudent implementation ensures that redundancy exists as required to support the system metrics.

Ray

My takeaway was the same as Robs. The other thing that concerns me is that this building is built like a brick you-know-what house. Plenty of cinder block and metal joists, metal studs in all of the walls, other types of cable, all kinds of interference potential. The more I think about it, the more I can't see paying $$$ for an xbee network when hardwire of some nature would be more reliable and responsive, albeit more work up front.

While that JeeLabs stuff looked interesting, I couldn't find anything that really set it apart from a hybrid of hard wired Ethernet with hard wired 1wire over (relatively) short runs.

I can find bits and pieces of this puzzle around on the forums and with various Google searches, but no one who has documented something similar from start to finish.

That could be natures warning sign that the project is impractical or has fundamental flaws. I suggest you get the bare minimum equipment (two sensors, a thermostat, wire, etc.) to test your theory of operation.

That could be natures warning sign that the project is impractical or has fundamental flaws. I suggest you get the bare minimum equipment (two sensors, a thermostat, wire, etc.) to test your theory of operation.

True, so at this point I would take anyone who has ever completed my step 1: a long distance (75-125 meter) 1wire temp sensor "run". See my second post, the first thing I will do is gather the temp data. I just don't want to start using technology X and get halfway in only to have someone tell me, "hey stupid, you should have used technology/method Y".

  1. Take temperature readings in a maximum of 35 locations in the building and deliver them back to the central location (master arduino?) for logging/analysis/and thermostat operation.

You may want to start out with an inexpensive data logger to log the desired data at each HVAC unit to see if you really need to pursue your project in its current form.

When connecting the temp sensors, what kind of master chip do I use, and what one has the library already written? Do I even need one, or can I connect them right to he arduino?

I would think I2C devices would work best for this. You should only need 2 pair cable to run the sensor to each location, one pair for pwr/grn and the other for SDA/SCL. In fact, if you wanted an LCD at each station, Adafruit makes a great shield with an LCD and six buttons that you could use as a standalone board and the sensors all on the same bus.

I would think I2C devices would work best for this. You should only need 2 pair cable to run the sensor to each location, one pair for pwr/grn and the other for SDA/SCL. In fact, if you wanted an LCD at each station, Adafruit makes a great shield with an LCD and six buttons that you could use as a standalone board and the sensors all on the same bus.

LCD Shield Kit w/ 16x2 Character Display - Only 2 pins used! [BLUE AND WHITE] : ID 772 : Adafruit Industries, Unique & fun DIY electronics and kits

According to this tutorial the length of the i2c bus can be up to 30 meters.

I think that may be a good place to start.