I'd like to hear your thoughts on a Thermostat kit design

[blueroomelectronics]

Working software... Hmmm it's an experimenters kit but I'll be happy to post user software on my site.

 

[bigkim100]

Misunderstood

Sorry about my comments guys, I thought that this was a practical kit, that would end up being a finished item (like a Heathkit...circuit boards, components, and a case), not a experimenters unit.

 

[blueroomelectronics]

It certainly could be a build it and use it thermostat but it's going to begin life as an educational (no firmware) kit

 

[arhi]

It will have to have at least some firmware ... at least a menu, sensor readout, display something on the glass ... for the HVAC the firmware is the important part .. very important

 

[blueroomelectronics]

Well I will include example code but you'll need a programmer. It will be the only user firmware updateable thermostat I'm aware of. Target price tbd but of course that depends on options and the case costs. The non cased base model should be very affordable.

Another thought might be going with the 80pim TQFP and adding a 20 key keypad and more user IO
It could then be built as a alarm system keypad or controller.

 

[arhi]

no way my wife would allow me to have a box with keypad on the wall acting as a HVAC ... nice, small, push wheel, glass lcd ... == nice ... keypad == ugly

I agree the standard junebug connector on board so you need to have a programmer to programm the kit but, you need to be able to program it with something when you assemble it ... I hate when I purchase something, spend hours (days) assembling it, and then it do not work!!! ... for e.g. I'm right now in process of ordering reprap (full kit with everything) and I asked they guy's if kit have "everything" I need to test it after I assemble it .. the answer was "yes of course" ... then I asked - ok, how much plastic are you sending? and they got stunned .... "you need to purchase a plastic at local store" ... well, yeah, I will, but I do not want to finish assembling the device in 3am and waiting 10 hours to test the darn thing ... send the 1m of plastic so I can test it....

same thing here ... when kit builder assembles the HVAC, he will like to see it in action immediately and then he will want to change the fw and do more ... so if no firmware comes with it .. ppl are going to get disappointed ..also, the example firmware source must have function that control all devices that come with the kit (so RTC, Display, encoder, sensors, relays...) additional staff that user can add himself are different story ....

for example, if you look your mongoose kit ... what is the point of those IR encoders if you have no example on how to use them. (to be honest, I have no idea how to use single ir per wheel, how do you know if the wheel is going forward or reverse if you only have 1010101010 ... I always used 2 sensors per wheel)

 

[3v0]

May I suggest you restrict this one to a networked thermostat.

After this one is done a more complex family member with keypad, better display, etc is always an option. After they get the first one working they will be hungry for the second.

@arhi
What would you think of Bill selling the kits with a USB based bootloader? That way people without programing skills or equipment could download programs supplied by other users.

EDIT: If the USB port is there some clever body may setup a PC based UI to configure the thing, log data, or integrate with a larger system.

 

[arhi]

3v0, what to tell ya .. the preloaded usb bootloader crossed my mind but
0. it is extra work (you need to preprogram every single chip you send out)
1. he want to increase sales so making junebug needed is kinda good for business
2. this is ment to be "fancy HVAC learning platform" first and "usable device" later, how do you expect them to learn embedded systems if they download something from internet and upload to device ... it is like modern day hackers, browse the net for scripts and then use them without even the basic knowledge on how the hack that works

I even wanted to suggest a bootloader that will use IRDA to load firmware but then decided to skip that (because 0-2)

 

[3v0]

The sales potential for this kit, if it does not require programming skills, is thousands of times greater then that of the junebug.

 

[blueroomelectronics]

There's the rub, I believe a thermostat especially an open source software design (I don't give away PCB artwork but the rest will be published) has the potential to go far beyond the scope of a typical setback thermostat. It would be possible to include a serial bootloader such as tiny bootloader in the device.
I've wanted to offer a thermostat kit as the first kit, it was among my first posts here when I joined as MyBlueRoom including an schematic (shown below in its last version from 2006).
One of the problems with that design were the LED displays did affect the temperature by about 2c after they were running for awhile. Also trying to squeeze so much out of a tiny PIC made for many compromises and I wanted the kit to be our flagship kit and a kit I would put to use controlling our homes Furnace & AC.
A zone based design seems the most logical and energy efficient but zoned thermostats are not nearly as cheap as a typical home thermostat and I love to tinker but your typical Honeywell or White Rogers are custom single chip designs and not exactly hack friendly.
Hopefully this new concept Cricket will attract firmware engineers that know something about temperature control (not as simple as it sounds) and will be willing to share.

On a side note I'll leave the design as simple and elegant as possible. No keypad (but I'll have to hunt down a low power encoder, or 3 pushbutton (UP,DN,SET) or gasp a joystick, or maybe IR. After all it can be connected to your PC... (Did someone mention XBee?)

**broken link removed**

 

[3v0]

Bill I agree with with your thinking on the design. It is possible to expand the potential market and sales without changing it.

As the software base for the device grows it will attract increasingly less capiable people.

In time the vast majority of users will buy a preassembled unit and flash it with user contributed code using the boot loader.

It would be easier for the user to have it preprogrammed, but then you may be looking at liability for the code. I understand not wanting to go there.

3v0

 

[JBrock]

DUDE, you are having too much fun programming your little processor.
There are a lot of dynamics in trying to control the temperature of a dwelling with a heater that can only run ON or OFF. The heater has to pre-warm before turning on the blower, during which time the home continues to cool. Then when the fan turns on, at first it has to blow all the cold air through the vents before the hot air comes. On the reverse end of the cycle, once the target temperature has been reached and the heater shuts off, the fan still has to blow for a while to clear out the vents, cool down the heater, and make use of the stored energy.
How will you control hysteresis and rate of change reponse?
I am sick of squinting at LCDs. Light that sucker up!
I put a "nice" honeywell digital control up to replace a rusty old mechanical device. It has so much trouble trying to do it's job I constantly imagine putting the old thing back up.
BTW, very cool schematic. What software did you use, and what is that "Crickett" font?

 

[blueroomelectronics]

That font is so old I've long forgotten its name I use ORCAD 10.3 to draw the schematic. It's old but I'm used to it.

The programming of most digital thermostats is mystery meat, who knows what's it's doing. Almost all under $100 thermostats only knowledge of the outside world is temperature (usually a cheap thermistor) and if it's a setback thermostat then time too.
I would think a smart thermostat with open source software could exceed most thermostat efficiency especially when connected to the internet.
So many options come to mind.
As for the hardware simple and extremely low power (unfortunately not battery as the communications circuitry would gobble up the battery relatively fast)
XBee is certainly on the table and might be a better choice than RS485, after all running wiring is more expensive than a $20 RF adapter.
The tough choice for me is the best use of the few pins remaining on the PIC.
Also KISS (keep it simple stupid) should apply, the more straight forward the design the less to go wrong.

PS I forgot how easy it would be to cheat on a jumper config till I looked at the old Cricket 88
Example: the DS1721 & LM75A (and most I2C temperature sensors) have a programmable address. But it doesn't have to be used that way.
Switch
1 = gas / elec
2 = C / F
3 = setup / run

and it costs zero IO on the PIC.

PS I may throw the PCB pads down for a couple or more I2C EEPROMs, seems some like data loggers.

Here's an example of a 14 segment font.
**broken link removed**

 

[arhi]

The programming of most digital thermostats is mystery meat, who knows what's it's doing. Almost all under $100 thermostats only knowledge of the outside world is temperature (usually a cheap thermistor) and if it's a setback thermostat then time too.

For starters a simple averaging function without weights is not hard to implement

(avg = ∑ i=1,n (T) / n )

thermostat response can be simple on / off with fixed offset so
if on and temp > avg +X => turn off
if off and temp < avg -X => turn on

set X as 3degrees and you have a simple implementation with multiple sensors....

now, adding weight system for sensors (so the avg function is not simple arithmetic average), adding some better response function ... that can be left for the "kit builder / community" to work on... if the firmware is already "functionalised" so you have each "calculation" in separate function, then everyone can only work on the functionality he understands...

I cannot comment on the wifi, the only "standard" wireless mode I ever used was BT (ESD* from SENA).... I saw zigbee/xbee... I also saw some other wireless modules but never tried them so cannot comment... ESD* is easy as it can get .. but BT modules are kinda expensive

Thinking more about this ... to be honest, I know PIC is "wast hobby market" but if you decide to go SMD I'd use MSP430F4* for this ... The price is same as PIC, you already decided to go smd so there's no difference and MSP430F* is imho much easier to work with, tools are much cheaper (mspgcc is free and as good as IAR or any other C compiler, programmers are fairly cheap too .. OLIMEX Ltd. - Electronic Design and PCB sub-contract assembly OEM/ODM service or build them yourself).. not to mention, if you really want to, you can use headers from olimex ( MSP430F449 HEADER PROTOTYPE DEVELOPMENT BOARD ) (starter kit also available: MSP430F449 DEVELOPMENT PROTOTYPE BOARD ) .. prices are great... now, it is not junebug compatible (it's not PIC) but ..

not to rain on parade, I notice that very small amount of hobby sites are TI based and I know almost no hobbyist who use them (expect me) ... Microchip and ATMEL are kinda holding the 95% of the hobby market, so I get the idea of making it with PIC.

 

[blueroomelectronics]

Yes I'll stick with PICs for the design.
I'm trying to avoid using TQFP just for the sake of kit building and yes I can solder TQFP I wouldn't expect everyone else to.
I was thinking of splitting the design into two parts much like the RCS-TR16. This has the head unit (2 digit display, temperature sensor and pushbuttons) in one part and uses the same 4 wire cable your existing thermostat uses but reassigns it to +,-,A,B
Where the relay and control unit are located near the furnace.
This would allow me to use the a PIC16F917 DIP with a simple 2.5digit LCD (as in my Cricket 2 design) in the head unit and a more powerful PIC18F on the control unit. It also would allow for mutiple thermostat head units to work with a single control. I could also mount a single relay in the head unit for aux control ie curtains or registers.
**broken link removed**
RCS-TR16 RS-485 thermostat.

 

[arhi]

more powerful PIC18F on the control unit

yup, also, if you do not have a temp sensor in the control unit, you can go with backlit 16x1 or 16x2 char display, saving pins and ... and ... and ...

ah soooo many ideas ... it is easy for you, sparkfun, digikey .. a phonecall / email away .. I'm trying to find a drill press for my dremel / ainhell / proxxon drill for last 4 weeks but was unable to find a company that want to ship here (and of course, was unable to find one locally ) ...

All in all, I agree that control unit do not have to have any sensors, it is even better not to have any in the control unit and to have a sensor as a separate "device" and of course, way to connect many of them to the control station ...

What bug's me dough is that
- zigbee is expensive but it is kinda standard for sensor network
- IR is easy & cheap but it really is no "standard"
- wires are easy, they are standard, but they are UGLY, I want to be able to put the sensor where it is "best place to measure temperature" and not to hide it because it is ugly, wires sticking from it etc etc ...

Regarding the uC for the control station, as you do not need lcd driver imho there (better to use standard 16x1 or 16x2) some "fast" 24F or even 30F 40pin dip would be my preference ... dual serial port, dual pwm, maybe CAN support (donno how CAN is conforming to the standards I mentioned) .. anyhow .. 40pin is what I'd go with

 

[arhi]

btw, look at this: **broken link removed**
It looks like it is some "standard" HVAC sensor talking to "control unit" via zigbee .. interesting

 

[blueroomelectronics]

Very nice, I'd love to design a kit that looked like the ZigBee SuperStat. I couldn't find a price on it though.

XBee is only $19US doesn't seem to pricey. Another problem with wireless is where do you get the power? ZigBee is not going to last long on a pair of AA cells. As for horsepower in the sensor; why? IMO it should be just enough to get the sensor data to the control unit, not really expected to do much more. Now the control unit could contain some power and possibly Ethernet.

It would be easy to use a 16x2 display but they are so common and so ugly. The wall box should be really basic IMO as the real power will be in the controller and your PC (web interface would be something)

Many PICs support LIN bus but it's single wire design is rated for only 30m

Another thought would be those low power Microchip ZigBee modules, they're $10US and use SPI and could be shut off except to transmit. The Thermostat head would only transmit on change and this could allow for a battery operated wireless unit.

 

[arhi]

ZigBee® Smart Energy Profile certified for full compatibility with Smart Energy meter or Energy Service Portal

this part is interesting ... I have no idea what it stands for .. is this the "Standard for the communication packets so they can understand each other" or this has to do with "energy consumption" and the problem you raised about power consumption of the sensor ...

Hardwire (24VAC) or “power-stealing” power option

what the .. "power stealing" ... ?!?!?!? I don't think google will show anything useful so if anyone can shed some light .. please do

anyhow .. if you use zigbee module only to "send data changes" .. it should last ..

the microchip zigbee modules 10$ .. donno .. never used one ..

as for the lcd .. you can always go wild and use GLCD + TOUCHSCREEN ... I got some from mikroe.com .. Easy Buy | Buy mikroElekronika Boards with a single click | mikroElektronika search for Graphic LCD 128x64 with TouchScreen .... the TouchScreen ( https://www.electro-tech-online.com/custompdfs/2009/02/touch_screen_specification.pdf ) works perfectly with mikroC ... have not yet had time to try to make it work with C18 (of course mikroC comes with closed sources support for it )

That would give you freedom to draw menus, buttons, be very user friendly ...

as for connecto to PC ... without reprogramming the device, the "input from PC" ain't gonna be any "more powerfull" nor easier to implement in PIC then a good menu .. IMHO

EDIT: with regards to network (point to multipoint or mesh) I opened https://www.electro-tech-online.com/threads/inexpensive-mesh-network.89291/ ... might show up something useful if someone with experience show up

 

[TheNthDegree]

what the .. "power stealing" ... ?!?!?!? I don't think google will show anything useful so if anyone can shed some light .. please do

Many older HVAC systems (especially residential systems) are designed where there is no common (ground) wire between the thermostat and the main HVAC unit. Thus, you only get a +24VAC supply wire (aka. "Red" or RH / RC), and the return wires-- for switching the relays and such in the HVAC unit.

There are digital thermostats which are designed to take power from such HVAC systems without the need for a ground. They act as a small "phantom" load of sorts across the RH / RC wire and the return wire(s). I believe this is what the "power stealing" was referring to...

Hope that helps,
-Nick