Legacy HVAC controls (what the industry calls "24 volt") are relatively
>trivial -- battery is provided to some number of control signals that
>interact with the plant.
>
>Note that the interface doesn't even provide a complete closed circuit;
>the "return" is implied in the plant and not carried in the control
>signals from the thermostat.
>
>I'd *assumed* (bane of all designs!) that keeping track of how *I*
>was driving those control signals would allow me to know the state of
>the plant; if I've applied battery to the Green lead, then the fan
>should be running (RSN), etc.
>
>But, newer systems apparently leverage this interface and piggyback
>their own controls on it. I.e., even if *I* don't call for the
>fan to be running, another system can power the Green lead and cause >the fan to run.
>
>So, I now need to be able to sense the states of these signals, in addition
>to controlling them.
>
>And, do so in a legacy-compatible manner.
>
>I'd not like to have to decouple those piggy-backed systems as that
>adds to the installation cost AND puts me in a bigger liability position.
>And, would like to limit my interface to the "legacy" control cable
>from the thermostat (replacing the thermostat, if you will).
>
>If I assume that I can't tell if anything else is driving a control
>signal WHILE that signal is also being driven by myself, would the
>safest way to sense just be (AC) voltage mode referenced to the power
>lead(s) -- no returns -- available at the thermostat?
>
>[I don't see how to determine the state of those signals while also
>trying to drive them, myself -- not without climbing deeper into
>the controls and exposing myself to the vagaries of their different >applications]
I've run into hardware designs that predict state by integrating commands, without verification by measurement. These designs have proven flaky in practice - real hardware makes mistakes, and even small mistakes will accumulate into significant divergence between predicted and actual, and bad things soon happen.
War Story: Circa 1994, I needed a backup drive for my Mac workstation, and bought an Iomega Zip 250 SCSI drive:
It did work, but had a reputation for abruptly crashing, destroying both the read/write heads and the disk it was using. Nobody knew why, and people just prayed and carried on, and so did I.
One day, I was in the process of unmounting the disk cartridge. The sequence was that one first commanded the volume be unmounted, waited for it to spin down, and then pushed a purely mechanical eject button. I had done this many times without drama. One day, I was going through the sequence and was about to push that eject button but stopped in mid-motion, with finger hanging just above button -- something wasn't right, but what? It wasn't silent...
I could still hear that the disk was still rotating at normal speed - it had not spun down. I backed up and re-ran the sequence, and the disk spun down and was ejected without drama. But what the hell just happened? If I had pushed the eject button before, there would have been a full crash.
So I dug in. It turned out that the Zip drive interface hardware had no reporting path for the I/O driver to tell if the spindle was rotating or not, so the I/O driver was forced to rely on tracking commands. Which almost worked.
Iomega still make Zip drives, but I bet that they now have the hardware path for the I/O driver to have situational awareness.
Joe