Recommendations for a wifi thermostat

http://www.rsdtotalcontrol.com/fx/pdf/Communicating_T_stat_Wireless_Overview.pdf
 
http://cgproducts.johnsoncontrols.com/CAT_PDF/1900624.pdf
 
http://cgproducts.johnsoncontrols.com/CAT_PDF/1900625.pdf
 
@ Pete, it does exist, but typically in doing a setup like this you need to move into a common platform protocol, typically BACnet between system components.....otherwise it's not going to be economical or practical to manufacture or install. In the case of consumer grade hardware, how scalable are these platforms? What happens when X or Y component is NLA or the format not supported? It may be a matter of time for the trickle down of the protocols and hardware to happen, it may never happen....The largest issue is usually there's either not enough conductors or the wrong type are going to the wrong location. In the case of wireless comms from the units...what protocol that is presently available gets chosen and is it the right choice? Only time will tell.
 
Usually TCP/IP is going tp be the easiest to leverage in a building, unless you are building your own small network using some other protocol, then it becomes what sort of protocol and what will the unit(s) be able to communicate to.
 
@Apu
 
For the same price of purchasing consumer grade items or a small premium, all these system parts can be purchased over the counter. Occupancy sensing already integrated, but could be added to. Raspberry PI for running BACnet. Whether or not you need to provide network connectivity or it already exists was not brought up as a design criteria, but most buildings have some form of network, if not, a simple standalone TCP/IP deployment would easily support a modest BACnet network with no bandwidth issues.
 
While you disagreed and dismissed before...something along the lines of unscrupulous HVAC/controls contractor or practices, by minimizing what sort of actions an end user performs on the system, while still allowing reasonable control within a specific bandwidth, while still allowing and maintaining scheduling abilities,  the energy savings and efficiency will pay for the system itself, as it has been proven elsewhere many times over.
 
If you would like to forward specific design criteria , equipment installed and site information, the calculations and projections would speak for themselves. I'm sure the parish would have interest in the cost savings. I'll even do your homework and provide you a BOM for you to price and order through your friends, as you already mentioned yourself and them perform HVAC installations and service and would have access to common distribution.
 
No need to reinvent the wheel when it already exists....there's multiple manufacturers out there, I provided the most readily available.
 
Totally different direction here too, but if it's at all possible to just run wire, yet another option is to locate all the thermostats in one closet and use remote temperature sensors in each area of the building so all tstats can be adjusted at once... 
 
It might be out of budget... but maybe an OmniPro II should be in the roadmap.  It can handle up to 64 thermostats, and using ZigBee they can all be wireless, and could be more than just the main great hall.  Add in occupancy sensors and now you can kill most heating/cooling when no one is there, also eventually lighting, etc.
 
Using programming you could easily control all of the thermostats together, lock them out during certain times, set up schedules for times to be off, and with a single UPB scene switch you could have an easy "On" and "Off" for your A/C, and still have 4 other buttons to play with to perform actions.
 
@ Neil
 
The solution I threw up there is Zigbee and less the controls components at the units, which should already exist, all you are doing is giving comms between the stats and the Raspberry that is running BACnet and any sort of automation software you really want to...there's lots out there, free, licensed, what have you...you only need to look for it. 
 
Software example: http://www.reliablecontrols.com/products/software/RCST/
 
The amount an OPII and related hardware is going to cost combined with the other components....you're already well past what I'm looking at for cost...the HAI stats are already 2X the cost. Once you're on the BACnet protocol, you can do really whatever you want for automation and not be proprietary and locked with a single platform....hell, that's what BACnet was intended to do.
 
Example of Raspberry :http://www.youtube.com/watch?v=0TJIrnAPsw4
 
All that is being suggested is fine, but in terms of cost, ease of programming and utter robustness, taking the jump into a simple BAS setup would make the most sense to me....then you have the infrastructure and gateway to put whatever you want to control or monitor on it.....you're already speaking the "correct" language compared to the closed embedded platform, not to mention it's scalable and never going to be outgrown....not in our lifetime. Sure, there are some cons from moving into software and not an embedded setup, but for that matter, you could build an army of Raspberries and have a couple sitting on the shelf and ready to drop in if one if it failed. Any set of I/O's can be put on the BACnet, outdoor temps, remote temp senders.....
 
To play devil's advocate.....what happens should HAI/Leviton support evaporate on their T-stats? How about distribution? Say HAI decides to close their distribution to only "authorized" outlets....sure there will be the 3rd party resellers, but now you're stuck with an orphaned or difficult to support platform and further limited in what units and hardware the host controller supports. Say they do as some other vendors have with the dealer software, require software and component licensing, and only with a valid training certification to use the latest and greatest software and fixes.....
 
Well I would argue that the Zigbee HA protocol is semi-open, not an HAI specific deal.... and I also started with "It might be out of budget...."  :)
 
Interesting with the Pi though... now I want to go play with it.
 
Zigbee is open, however the native control, what is able to be controlled and the system it's going to be connected to is the variable....all the Zigbee is going to do is get the data from A to B using a known protocol, then you're stuck with whatever the native HA controller's programming format, protocol and software is and what it may or may not do.
 
Here's another way to play, albeit limited: http://www.inneasoft.com/Pages/en-US/Products/BACnet/InneaBACnetExplorer.aspx?goback=.gmp_114757.gde_114757_member_103625449.gna_114757.gde_114757_member_54892063 Supply your own PC and BACnet devices.
 
For Apu's application, while it's a little bit of programming, in the case of the upper loft, simplistically, what you would do is have the stat or BACnet object monitor the trend....such as TOD, occupancy, what have you, then should be able to, once the values are known, as long as the original system was designed appropriately, be able to counteract the swings and get the space to act as one coherent system....again, within the limitations of how the original system(s) were designed and installed....for all intents and purposes, the room and systems may not be able to be balanced, but you should be able to get close.
 
Enough inputs and data coming into the system to feed trending data (time of year, weather, humidity, etc) you wouldn't need any outside influence unless the weather really goes crazy. While it would be nice to push the alarms to someone monitoring and supervising the systems, it's not completely necessary....but I'm sure there's enough of a will and way via more hardware, even another Raspberry to be able to push the notifications out there through XYZ ISP based service, email, whatever you really want to choose.
 
Back
Top