Need help with Nest-HRV integration - Page 2

jeff5may · 01-21-16, 01:23 AM

It sounds like you have a good amount of time invested in the project already. From your story so far, you seem to have a good grasp on how the two units interact during operation. From your description, it sounds as if the panel issues commands and the main module either acknowledges the command or replies with an error message. There may be other communication going on that may seemingly have no effect on operation.

The tool you seek here is a logic analyzer. There are literally a jillion of these things on the market to suit many needs. In this case, the hrv controller probably runs in the single digit MHz range, and comms much slower. A cheap, USB-based probe will more than do the job here. Just search for "usb logic analyzer" or "pc logic oscilloscope" and the like. If the unit does indeed chat back and forth, it probably speaks i2c, spi, or some other common language. There are open-source interpreter programs on the web that can help you figure out the details. As with all software, the paid versions are usually better once you learn the process.

If you decide to go the other way, the manual does a pretty good job at spelling out most of the details behind the scenes. The unit seems to use a 10k nyc thermistor for the defrost sensor, so it wouldn't be super difficult to interface with. The relay and motor drivers could be found and tied into. Then you would have to write a firmware of your own.

bbro62 · 01-21-16, 09:55 AM

Quote:

Originally Posted by jeff5may

The tool you seek here is a logic analyzer. There are literally a jillion of these things on the market to suit many needs. In this case, the hrv controller probably runs in the single digit MHz range, and comms much slower. A cheap, USB-based probe will more than do the job here. Just search for "usb logic analyzer" or "pc logic oscilloscope" and the like. If the unit does indeed chat back and forth, it probably speaks i2c, spi, or some other common language. There are open-source interpreter programs on the web that can help you figure out the details. As with all software, the paid versions are usually better once you learn the process.

Thanks! This is exactly the information I was looking for. Do you have any thoughts about using an Arduino itself as a logic analyzer such as what is demonstrated here:

https://www.youtube.com/watch?v=vQ5TvnRdHMM

and provided here: https://github.com/gillham/logic_analyzer? This is appealing because it seems like I might be able to use the arduino to analyze the signals, then program it to replicate those signals, and pop the chip out to use in my new controller. And I'd still have the Arduino to use for other projects.

Quote:

If you decide to go the other way, the manual does a pretty good job at spelling out most of the details behind the scenes. The unit seems to use a 10k nyc thermistor for the defrost sensor, so it wouldn't be super difficult to interface with. The relay and motor drivers could be found and tied into. Then you would have to write a firmware of your own.

By this, are you talking about reprogramming the existing chip on the control board, replacing it with my own, or splicing in my own chip to the board while leaving the original in place? I'm actually waiting on delivery of a NOS control board that I picked up cheap on ebay so will soon have a spare to play around with.

Thanks much for your help. I'm finally feeling like I have a path forward.

jeff5may · 01-21-16, 02:29 PM

Yes, you can grab a sketch that will turn an arduino into a logic probe or analyzer, wire it up, and use it. I don't know how accurate or sensitive it would be. I do know the little 8 channel USB ones work, and can be found for less than 20 bucks. They can also be used as digital storage oscilloscopes, so if you don't have an oscilloscope they are definitely worth the purchase price right there. If you do much tinkering on electronic devices, you absolutely need an oscilloscope.

As for your "option 1" solution, the only way you could reprogram the existing chip (if it is programmable- some are burnt like a DVD or bootstrapped from a prom) is sort of like the ftdi method with the older arduino boards. You would have to have a complete programming studio for the chip in question. Not easy, plus you would need to come up with a sketch for the micro to work.

If you wanted to completely remove the micro from the main board, you could. Doing measurements while the micro was still in to figure out what signals come and go on what pins would save a ton of time in decoding the board. Using this method, once the stock micro is removed, you would have lots of easy to solder empty holes that would most likely directly plug and play with jumper wires and a generic dev board.

Going at the end of the trail is even easier. Letting the stock micro do its business and "jinxing" input and output signals is easier than writing a sketch to account for every possible situation. You could tap into certain points on the main board to keep tabs on signals and states of important aspects and ignore pretty much everything else. In this rig, the dev board would just sit and listen, allowing the factory micro to control everything while the unit is working like you think it should. When a condition came up where you wanted to change functional state, the dev board would either feed the factory micro a command to force the desired state, or switch output signals directly and feed the micro a signal to hide the change. Depending on how much redundancy is built into the stock micro, it may or may not go postal when its control is severed. Since a hrv is probably not programmed as a critical system, I'm thinking it wouldn't complain much.

Looking at the stock micro datasheet reveals it has a built in serial interface. The thing wires up using TWI (three wire interface) standards. It is 5 volt TTL and its pinout looks like this:

If the board is using the built in serial interface, you will see activity on pins 11, 12, and 13. Tying a logic analyzer to your wires between the main board and control panel, along with these 3 pins would quickly reveal whether or not (and how) the micro is using that port for comms. If not, other pins could be tapped to find out pdq which port is being used.

The easiest way to snoop on your micro is to grab a "piggyback" connector for your particular micro footprint. Most clamp on over top of the ic like a clothespin and have wires or sockets that you plug your analyzer into. Again, you can spend as much as you want on one of these. The expensive ones are more securely attached and are less fragile than the cheapo items. Depending on how clumsy you are with tiny probes and chips, a more expensive one would greatly reduce Murphy's law from showing up and ruining the day. Even then, you still have to be careful with static electrical charges and shorting pins and such.

bbro62 · 01-26-16, 06:39 PM

Quote:

Originally Posted by jeff5may

Yes, you can grab a sketch that will turn an arduino into a logic probe or analyzer, wire it up, and use it. I don't know how accurate or sensitive it would be. I do know the little 8 channel USB ones work, and can be found for less than 20 bucks. They can also be used as digital storage oscilloscopes, so if you don't have an oscilloscope they are definitely worth the purchase price right there. If you do much tinkering on electronic devices, you absolutely need an oscilloscope.

Got sidetracked for a few days but wanted to thank you again for this incredible information. The only logic analyzers I could find for under $50 were generic Saleae knock offs but they supposedly work according to reviews. So I have one on order. While I wait, I'm reading up on the basics of microcontrollers at that is the only mysterious black hole in this system for me. I'm sure I'll have more questions after the analyzer arrives.

But thanks again!

bbro62 · 03-14-16, 02:27 PM

This project has been moving forward (or backward) in fits and starts so I thought I'd post an update.

I got a cheap logic analyzer and did some sniffing of the commands being transmitted and received from the controller. Of course I had no idea of protocols, data frames, or baud rate used so I had to guess. I assumed the signals were asynchronous serial because of the wiring which is 12vin, Send, Receive, and Grnd. I set the analyzer at the defaults of 8 data bits, no parity, and 1 stop bit. After collecting some samples and filtering what appeared to be noise using the gliche filter, I measured the width of what appeared to be single bit pulses and calculated the baud rate to ~300 baud. When I plugged that into the protocol analyzer, I was able to see consistent bytes without framing errors so I'm hoping I've discovered the magic protocol.

The communication looks pretty simple. When a command is issued on the controller, a single byte is sent to the HRV unit and the HRV sends back what looks to be an acknowledgement (always 0xBC) and then a half second later, the HRV sends a 0x5C which the controller acknowledges with a 0xBC. That pattern is consistent for all commands issued from the controller with only the initial command byte changing. When an HRV cycle is started or stopped from one of the wall timer switches, the HRV sends a command to the controller and the controller acknowledges with a 0xBC. I'm assuming the timer start command initiates a countdown timer in the controller.

Because the communication sequence was consistent and made sense, I felt pretty confident I had correctly deciphered the logic signals I needed to replace the controller with my own. So I turned to the Arduino to see if I could replicate those bytes to talk with the HRV. The first step was just to test a simple serial loop using the Arduino Serial Monitor to read and send bytes and that's where I hit a problem. It turns out that the Arduino does not handle 300 baud communication well. All bit rates of 1200 and up work fine, but not 300, at least not over the hardware serial ports. It just spits out garbage at that speed. Because 300 baud isn't used any more, there doesn't seem to much incentive to fix it. One thread on the forums hinted that using the digital pins for serial communication might work so I set up software serial to test things out.

Unfortunately, I don't have a USB to TTL converter so no way to monitor the software serial ports directly with a terminal emulator. Instead, I wrote a sketch to read bytes on the software serial pins hooked up to my HRV controller and write those bytes out to the hardware serial to be read on the Serial Monitor. When I hook up the Arduino to the controller and issue a command from the controller, I do start reading bytes but it just spits out infinite 255 (decimal) until I reset the Arduino. The it reads nothing until another command is issued. I get that same result even if I change the baud rate on the software serial pins. So I think maybe the Arduino is still not communicating at 300 baud which means I picked the wrong dev board for this project. Alternatively, maybe I don't have the communication protocol as figured out as I thought. For now, I have ordered a USB to TTL converter so I can at least test the baud rate of the Arduino. If that fails, I guess I need to find a different dev board that can handle low bit rates.

If anyone has any other suggestions or advice about what I did wrong, I'd love to hear it.

lakereef · 01-10-18, 04:20 PM

Quote:

Originally Posted by bbro62

This project has been moving forward (or backward) in fits and starts so I thought I'd post an update.

If anyone has any other suggestions or advice about what I did wrong, I'd love to hear it.

I don't have suggestions but wondered if you ever figured this out? I'm looking to buy an HRV and was quoted for the same model you have, but don't like the controller at all. I would really like a "smart" or at least smarter option. I also have a gen3 Nest.

bbro62 · 11-24-19, 01:01 AM

My apologies for not updating this thread or responding. I did get this working but at the same time, was starting my own business which consumed most of my time. I'm happy to report that my controller has been humming along nicely for three years now and I really like it. I uploaded arduino sketches, schematics, etc. on Github https://github.com/blbrock/Smart_HRV

I really like the system. It monitors humidity in our two bathrooms and a third reference location in the house and compares these with outside temp/humidity to adjust the target indoor humidity and decide whether to run in recirculation mode or low or high fresh air exchange to obtain target humidity with minimal energy loss. The system consists of an arduino-based microcontrooler wired directly to the HRV and is controlled through a wall-mounted tablet via bluetooth. The arduino is also connected to a Nest thermostat via a relay to take advantage of the Nest fan controller. I have the nest set to run the HRV at low speed fresh air mode for 15 minutes every hour during the day to maintain indoor air quality.

The only thing I would do different is that I would wire the manual push button controls to the arduino and run them from there instead of leaving them wired to the HRV as they were originally. I was never able to capture the full command sequence from the manual controls and pushing the controls when the HRV is in an automatically triggered cycle can sometimes cause the HRV to go into error mode and have to be powered on and off. That rarely happens so not worth changing at this point.

Here's a couple images of the system:

https://raw.githubusercontent.com/bl...controller.png

Again, sorry for not updating or answering questions.

01-21-16, 02:29 PM	#13
jeff5may Supreme EcoRenovator Join Date: Jan 2010 Location: elizabethtown, ky, USA Posts: 2,431 Thanks: 431 Thanked 619 Times in 517 Posts	Yes, you can grab a sketch that will turn an arduino into a logic probe or analyzer, wire it up, and use it. I don't know how accurate or sensitive it would be. I do know the little 8 channel USB ones work, and can be found for less than 20 bucks. They can also be used as digital storage oscilloscopes, so if you don't have an oscilloscope they are definitely worth the purchase price right there. If you do much tinkering on electronic devices, you absolutely need an oscilloscope. As for your "option 1" solution, the only way you could reprogram the existing chip (if it is programmable- some are burnt like a DVD or bootstrapped from a prom) is sort of like the ftdi method with the older arduino boards. You would have to have a complete programming studio for the chip in question. Not easy, plus you would need to come up with a sketch for the micro to work. If you wanted to completely remove the micro from the main board, you could. Doing measurements while the micro was still in to figure out what signals come and go on what pins would save a ton of time in decoding the board. Using this method, once the stock micro is removed, you would have lots of easy to solder empty holes that would most likely directly plug and play with jumper wires and a generic dev board. Going at the end of the trail is even easier. Letting the stock micro do its business and "jinxing" input and output signals is easier than writing a sketch to account for every possible situation. You could tap into certain points on the main board to keep tabs on signals and states of important aspects and ignore pretty much everything else. In this rig, the dev board would just sit and listen, allowing the factory micro to control everything while the unit is working like you think it should. When a condition came up where you wanted to change functional state, the dev board would either feed the factory micro a command to force the desired state, or switch output signals directly and feed the micro a signal to hide the change. Depending on how much redundancy is built into the stock micro, it may or may not go postal when its control is severed. Since a hrv is probably not programmed as a critical system, I'm thinking it wouldn't complain much. Looking at the stock micro datasheet reveals it has a built in serial interface. The thing wires up using TWI (three wire interface) standards. It is 5 volt TTL and its pinout looks like this: If the board is using the built in serial interface, you will see activity on pins 11, 12, and 13. Tying a logic analyzer to your wires between the main board and control panel, along with these 3 pins would quickly reveal whether or not (and how) the micro is using that port for comms. If not, other pins could be tapped to find out pdq which port is being used. The easiest way to snoop on your micro is to grab a "piggyback" connector for your particular micro footprint. Most clamp on over top of the ic like a clothespin and have wires or sockets that you plug your analyzer into. Again, you can spend as much as you want on one of these. The expensive ones are more securely attached and are less fragile than the cheapo items. Depending on how clumsy you are with tiny probes and chips, a more expensive one would greatly reduce Murphy's law from showing up and ruining the day. Even then, you still have to be careful with static electrical charges and shorting pins and such. Last edited by jeff5may; 01-21-16 at 05:55 PM..

03-14-16, 02:27 PM	#15
bbro62 Lurking Renovator Join Date: Jan 2016 Location: N/A Posts: 10 Thanks: 2 Thanked 0 Times in 0 Posts	update This project has been moving forward (or backward) in fits and starts so I thought I'd post an update. I got a cheap logic analyzer and did some sniffing of the commands being transmitted and received from the controller. Of course I had no idea of protocols, data frames, or baud rate used so I had to guess. I assumed the signals were asynchronous serial because of the wiring which is 12vin, Send, Receive, and Grnd. I set the analyzer at the defaults of 8 data bits, no parity, and 1 stop bit. After collecting some samples and filtering what appeared to be noise using the gliche filter, I measured the width of what appeared to be single bit pulses and calculated the baud rate to ~300 baud. When I plugged that into the protocol analyzer, I was able to see consistent bytes without framing errors so I'm hoping I've discovered the magic protocol. The communication looks pretty simple. When a command is issued on the controller, a single byte is sent to the HRV unit and the HRV sends back what looks to be an acknowledgement (always 0xBC) and then a half second later, the HRV sends a 0x5C which the controller acknowledges with a 0xBC. That pattern is consistent for all commands issued from the controller with only the initial command byte changing. When an HRV cycle is started or stopped from one of the wall timer switches, the HRV sends a command to the controller and the controller acknowledges with a 0xBC. I'm assuming the timer start command initiates a countdown timer in the controller. Because the communication sequence was consistent and made sense, I felt pretty confident I had correctly deciphered the logic signals I needed to replace the controller with my own. So I turned to the Arduino to see if I could replicate those bytes to talk with the HRV. The first step was just to test a simple serial loop using the Arduino Serial Monitor to read and send bytes and that's where I hit a problem. It turns out that the Arduino does not handle 300 baud communication well. All bit rates of 1200 and up work fine, but not 300, at least not over the hardware serial ports. It just spits out garbage at that speed. Because 300 baud isn't used any more, there doesn't seem to much incentive to fix it. One thread on the forums hinted that using the digital pins for serial communication might work so I set up software serial to test things out. Unfortunately, I don't have a USB to TTL converter so no way to monitor the software serial ports directly with a terminal emulator. Instead, I wrote a sketch to read bytes on the software serial pins hooked up to my HRV controller and write those bytes out to the hardware serial to be read on the Serial Monitor. When I hook up the Arduino to the controller and issue a command from the controller, I do start reading bytes but it just spits out infinite 255 (decimal) until I reset the Arduino. The it reads nothing until another command is issued. I get that same result even if I change the baud rate on the software serial pins. So I think maybe the Arduino is still not communicating at 300 baud which means I picked the wrong dev board for this project. Alternatively, maybe I don't have the communication protocol as figured out as I thought. For now, I have ordered a USB to TTL converter so I can at least test the baud rate of the Arduino. If that fails, I guess I need to find a different dev board that can handle low bit rates. If anyone has any other suggestions or advice about what I did wrong, I'd love to hear it.

11-24-19, 01:01 AM	#17
bbro62 Lurking Renovator Join Date: Jan 2016 Location: N/A Posts: 10 Thanks: 2 Thanked 0 Times in 0 Posts	My apologies for not updating this thread or responding. I did get this working but at the same time, was starting my own business which consumed most of my time. I'm happy to report that my controller has been humming along nicely for three years now and I really like it. I uploaded arduino sketches, schematics, etc. on Github https://github.com/blbrock/Smart_HRV I really like the system. It monitors humidity in our two bathrooms and a third reference location in the house and compares these with outside temp/humidity to adjust the target indoor humidity and decide whether to run in recirculation mode or low or high fresh air exchange to obtain target humidity with minimal energy loss. The system consists of an arduino-based microcontrooler wired directly to the HRV and is controlled through a wall-mounted tablet via bluetooth. The arduino is also connected to a Nest thermostat via a relay to take advantage of the Nest fan controller. I have the nest set to run the HRV at low speed fresh air mode for 15 minutes every hour during the day to maintain indoor air quality. The only thing I would do different is that I would wire the manual push button controls to the arduino and run them from there instead of leaving them wired to the HRV as they were originally. I was never able to capture the full command sequence from the manual controls and pushing the controls when the HRV is in an automatically triggered cycle can sometimes cause the HRV to go into error mode and have to be powered on and off. That rarely happens so not worth changing at this point. Here's a couple images of the system: https://raw.githubusercontent.com/bl...controller.png Again, sorry for not updating or answering questions. Last edited by bbro62; 09-29-20 at 05:58 PM..

01-21-16, 01:23 AM	#11
jeff5may Supreme EcoRenovator Join Date: Jan 2010 Location: elizabethtown, ky, USA Posts: 2,431 Thanks: 431 Thanked 619 Times in 517 Posts	It sounds like you have a good amount of time invested in the project already. From your story so far, you seem to have a good grasp on how the two units interact during operation. From your description, it sounds as if the panel issues commands and the main module either acknowledges the command or replies with an error message. There may be other communication going on that may seemingly have no effect on operation. The tool you seek here is a logic analyzer. There are literally a jillion of these things on the market to suit many needs. In this case, the hrv controller probably runs in the single digit MHz range, and comms much slower. A cheap, USB-based probe will more than do the job here. Just search for "usb logic analyzer" or "pc logic oscilloscope" and the like. If the unit does indeed chat back and forth, it probably speaks i2c, spi, or some other common language. There are open-source interpreter programs on the web that can help you figure out the details. As with all software, the paid versions are usually better once you learn the process. If you decide to go the other way, the manual does a pretty good job at spelling out most of the details behind the scenes. The unit seems to use a 10k nyc thermistor for the defrost sensor, so it wouldn't be super difficult to interface with. The relay and motor drivers could be found and tied into. Then you would have to write a firmware of your own.