Bringing analog hvac system into home automation.
To make the experience fit your profile, pick a username and tell us what interests you.
CAD rendering of the thermostat and HVAC mode encoders, along with the stepper motor mounting plate.
Portable Network Graphics (PNG) - 386.30 kB - 10/30/2020 at 05:02
Another 3D printed project prototyping board and a working design that bridged the Nest to the pycom microcontroller.
All AC circuitry to the left of the orange line, isolated from the digital logic to the right.
Here's the full schematic which includes two-stage cooling and heating.
I originally had assumed that in order for the Nest to believe it was controlling an actual HVAC system, it would need equivalent 24V AC outputs. Note that the base plate has 10 wire inputs for HVAC connections but the Nest-to-base-plate is a 20-pin connector. As it turns out that to detect what kind of HVAC system that its being used to control, in each HVAC connection is a mechanical switch which determines if there's a wire that's been inserted into the location. Instead of actually running AC HVAC signals, it could be possible to insert wires into the appropriate locations and then leverage the Google Home API to know if the state of the thermostat.
Since I had the Nest already, had become fairly enamored with its great design and liked its ability to learn my schedule, the next step of this project was to figure out how to use it to control my HVAC stepper motors. A 24V AC power supply was an easy find.
Next was turning the AC control signals from the nest into a digital 3.3V signal. In previous projects, I had used optocouplers to isolate a digital control signal from a triac to control an AC signal. But this was the reverse of using an AC signal to drive a digital input.
As it turns out the HCPL-3700 is great because it can isolate either AC or DC inputs from its logical outputs with a fairly straightforward design of a diode-bridge rectifier powering an optocoupler. The datasheet by fairchild, avago or hp/agilent are very similar, differing only in some of their operating voltages at various temperatures.
All of the datasheets also include an AC threshold-voltage-to-external-resistance chart. [0033mer]'s youtube video shows a version of this chart, however, which I couldn't find in any of the datasheets. When using an AC input (pins 1 & 4), it recommends using a capacitor on pins 2 & 3 to smooth out the bridge rectifier "output". With this application, the resistance for 24V AC is low and in that range, the capacitance variance is negligible.
In my previous apartment, a mid-70s honeywell bi-metallic thermostat controlled the 24V circuit connected to the oil-filled baseboard electrical heat. And like many systems of that era, it consisted of only a two-wire configuration - red and white wires.
For many HVAC system installation, only the R & W wires were run from the heating unit to through the wall to the thermostat.; and since it wasn't needed by mechanical thermostats, the common wire wasn't. It probably also saved on building construction costs. However, it was a challenge for thermostats with electronics that required a power source.
Two techniques have been used to circumvent this limitation. If the resistive load of the electronics is placed in parallel with the thermostatic switch (left), it could provide enough current to power the electronics as long as it wasn't sufficient to trigger the heating relay. The other possibility is if the resistive load of a battery charging circuit is in series with the thermostatic switch (right) then during the heating cycle enough power could be stored to run the electronics while not heating. Neither are great solutions as the former solution is challenging given that the relay's current draw is not known. And the latter relies on enough heating cycles to charge a large enough battery to sustain the electronics in between heating cycles.
I imagine that manufacturers decided to avoid this kind of challenge and focus on home automation in newer construction where common wires are more often available. For older constructions, the recommendation is to supplement the two-wire system with an external 24V AC power supply.
The one exception is the Nest thermostat; it is based on the in-series battery charging design with a micro-usb charging port as a backup in case the battery dies between heating cycles. And with its simple user interface, I've always been a fan of the Nest thermostat so I was happy to install it.
From research, this seemed like a more "modern" (after 1980s) wiring for a combined hot-air and A/C unit that shared common ductwork:
If the heating and A/C units were separate -- such as a baseboard water heater and A/C ducts -- the wiring configuration might have two 24V AC transformers with an RH from the heating system and an RC from the cooling system. Other systems also offered a second heating or cooling stage. For common setups, check out this extensive guide.
A single breadboard is great when prototyping with a microcontroller and a couple of small DIP packages. And the wonderful, little 5V/3V breadboard power supplies definitely help keep the project organized. And with breadboards that snap together, expanding is definitely possible.
But needing to move the project from one workspace to another is a recipe for breadboards separating and countless connections needing to be mended. Coupled with a growing number of projects that also need multiple voltages or multiple power supplies for servos and stepper motors, decided to "design a better mousetrap".
More information on building can be found on thingiverse.
Lots of progress has been made but have fallen behind in posting...
With the encoder more or less figured out and the basic circuitry understood, I set out to build a fully working breadboard prototype.
Once again, not the prettiest of prototypes but workable to develop the software.
The green boxes each represent the 3-bit encoders needed for the thermostat knob and the mode selection knob. Two DRV8255 stepper drivers are in blue. Since the pycom has an onboard voltage regulator, it likes to run above the 3.3V recommended for its own inputs. The dc-to-dc step downs that are on the prototyping board are lousy at maintaining a constant voltage (I tried several manufacturers too!) if there is any sort of load; if set to 3.3V, there is enough of a voltage drop (~50-150 mV) under load that the pycom won't run. To avoid an issues of having the IO pins being driven above their safe limit, pycom's input voltage is 4.5V and then the LM393s are powered off of the pycom's 3.3V regulated output. Vmot for the stepper motor drivers are regulated separately at 12.5V.
To verify that the encoder disc design would work, I started with a single-bit of the eventual 3-bit encoder and just the one stepper motor.
In this first pass, I didn't have any LM393s in my parts bin. So while I awaited delivery, I used an op-amp (LM386) and a 2N2222 transistor to get the digital input needed for the microcontroller. Above the pycom microcontroller is a DRV8825 for the stepper motor.
DEFAULT_SPEED = 100 enc0 = Pin('P3', mode=Pin.IN) step_pin = Pin('P11', mode=Pin.OUT), dir_pin = Pin('P12', mode=Pin.OUT) # turn the stepper motor n degrees def turnKnob(degrees, cw=True, speed=DEFAULT_SPEED): # set direction dir_pin.value(0 if cw else 1) # adjust for the 5:1 planetary gear reduction steps = int(degrees * (1036/360)) delay = 1 / speed # create a pulse for each step needed for i in range(0, steps): step_pin.value(0) time.sleep(0.0001) step_pin.value(1) time.sleep(0.0001) step_pin.value(0) # time between pulses sets speed # short delay, faster rotation # longer delay, slower rotation time.sleep(delay) # run until the encoder hits a slot def runUntil(cw=True, speed=DEFAULT_SPEED): while enc0.value() != 0: turnKnob(1, cw, speed)
This snippet turns the stepper motor until a slot in the encoder disk triggers the IR/photodiode comparator
The IR LED / photodiode pair circuitry is simple and is the same found on the ubiquitous line folllowing sensor boards (far right).
The photodiode (in reverse bias) acts as the upper half of a voltage divider. When exposed to the IR LED, the voltage increases. The other leg of the LM393N comparator input is another voltage divider with a variable potentiometer. Usually used to adjust the sensitivity of the circuit and change reflected distance, it is less needed in this case; the distance between the two diodes is fixed and the diodes face each other thereby removing any IR loss due to the not-perfect-reflective surface.
Since this is this board schematic, it doesn't include the IR LEDs and photodiodes as they'll be off-board.
It'd be nice to have the skill (aka patience) to design this as an SMD board but for this project, I'm going to do a through-hole PCB. Three of the dual comparator LM393s will take a fair amount of real estate on the final board; but there isn't a size constraint and the low-volume (there are only three HVAC units in the apartment) won't make the the extra PCB board real estate cost prohibitive.
Next step: creating a mount to hold the IR LEDs and photodiodes.
The middle plate attaches to the stepper motors and holds the photodiodes. Once assembled, the encoder disks are friction fitted to the shaft of the stepper motor. Followed by the IR LEDs held opposite the photodiodes on a raised "tab". I had hoped to make this more compact but the LEDs needed to clear the stepper motor housing so the disks ended up being ~2.5" diameter.
Here is the first working prototype. In lieu of small PCB boards to hold the photodiodes in place, a little CA glue did the trick with a very clumsy soldering of the leads to a flat, multicolored cable that was lying around.
A side view of the prototype. Even more clumsy underside with some electrical tape protecting the LEDs from shorting out against the metal case of the planetary gear casing on the stepper motor.
I had long been a fan of the Teensy series of arduino compatible boards and have used them in a variety of projects. Reasonable cost and a small form factor with plenty of supported libraries and plenty of I/O pins. But by the time you add bluetooth and/or wifi, one quickly starts approaching the costs of the many ESP-8266 and ESP-32 based chips.
Also, my C programming skills aren't what they used to be. I truly miss the days of the C fluency that I had when I designed UltraSPARC chips for Sun Microsystems. But too much time building web applications in java and python has softened me. And the (re)learning curve of getting back into C is daunting when I'm feeling more like creating something than skill building.
Yes, writing in python yields code that is not nearly as fast. And, yes, it feels like cheating to avoid memory allocation and typed variables on such low-level, embedded hardware. But with clock rates running faster on microcontrollers than the Sparc Workstations I used to develop on, it just doesn't seem necessary to program in C any longer for my use cases.
Python is more than capable of doing the simple calculations and stepper motion that I need. While I think there is room for micropython to be more "pythonic" (more to come in later posts), the allure of using a higher-level language is too difficult to pass up.
To ease into this new paradigm, I had an Adafruit Circuit Playground lying around after being curious about micropython a year or so ago. I then played around with Adafruit's line of Huzzah Feathers but they can only be powered by either USB or LiPo battery. The stepper motors were going to draw more current than either of those could provide. And the thought of having two DC power supplies for one project seemed silly.
There are certainly plenty of super low-cost ESP32s on ebay and amazon but without a specific company (or a dedicated community) to get help from, I was hesitant to go down that route for my first micropython project. While exploring Adafruit's website, I came across PyCom's line of development boards (and their eco-system and community) seems to be the best of the micropython microcontroller contenders. While their base-level WiPy boards is perfect for this application, it's been good to invest in getting to know a platform that has room for growth since their line includes 3, 4 & 5-network (SigFox, LoRa, WiFi, LTE, BLE) microcontrollers.
I had done quite a bit of research into rotary encoders during a digital read-out project for my vertical mill. The most available (and lower cost) varieties were shaft-based encoders -- either with specific detents (left) or in fairly large packaging (middle) -- are difficult to integrate where two shafts are already connected. The next best alternative is the AMT-102 which, at $20, slips nicely over an existing shaft-to-shaft connection and has remarkable precision (up to 0.08 degrees of accuracy).
But all of those are incremental encoders and, at best, have a single index point per revolution. Upon startup of the microcontroller, determining where that index position is without hitting the limit of the 270 degree arc couldn't be guaranteed. It could, perhaps, work with the mode selector since you could do a full revolution at startup, but aligning the encoder with the heat-cool mode select knob is not without its challenges.
Options for oiff-the-shelf absolute encoders were even more limited than incremental, most exceeding any sort of reasonable budget ($100+). I did find a reasonably priced magnetic position sensor which had potential, but with only a surface mount package, it was a little out of reach for my limited fabrication tools. Perhaps for the next project.
Left with building my own absolute encoders seemed like a possible solution. Typical designs seemed to follow an optical pattern of alternating light-dark pattern with each ring offset by some set of degrees to differentiate the position. With multiple sensors, one positioned at each ring, it creates a binary code for each location: black representing zero, white a one.
Additionally, the infrared sensor (far-right) is ubiquitous in most beginner sensor kits for line following; it contains an IR led / photo-diode pair along with a comparator and variable resistor to tune the IR reflection. Mostly used for line following robot exercises, it worked as a tachometer reflecting off a printed piece of paper for my lathe DRO project quite well.
Not compact enough for the tight spaced HVAC console, but closer to a solution. My second iteration's attempt was to put the IR led and photo-diode opposite each other with a slotted disc (left) which followed the optical pattern.
While this provided the necessary number of index points, the resolution meant that the position could be within a 22.5 degree range. For this application, I really needed to know at specific positions and then "don't cares" for the ranges in between.
The next iteration (middle) fixed this problem but with equally sized slots for each ring, as the disk rotated, the inner most slot illuminated its photo-diode before the middle and outer slots. From this picture, you can see that the vertical white line showing up in the lower slot but not in the upper.
Final design (right) created openings that were "pizza" shaped improved the situation, although some software "debouncing" was still required to make sure that the photo-diodes were all being exposed to their respective IR LEDs at the same time. I'll cover in a future post the software for signal debouncing that was still required.
It was also interesting, although perhaps not surprising, that different colors of the PLA were not necessarily opaque to IR wavelengths, hence the change to the darker colors.
Become a member to follow this project and never miss any updates