Designing a General Purpose Heat Pump Controller

[jeff5may]

Originally Posted by Ormston

I fully understand the advantage of a whole bunch of sensors only using 1 pin, however i like any system i implement to be maintainable.

It may be possible for the system to detect a missing sensor, find the new one on the bus and replace the missing one with the address of new one and store in it to eprom.

But what if a 2 sensors need replacing, or if you get the plumber in to replace you're water cylinder and he puts all the sensors back in the wrong place or damages several whilst working(i have 5 DS18B20's on my current water cylinder alone).
That piece of software you wrote and kinda kept notes on may make perfect sense in 6 months time, what about in 5 or 10 years.
Will you still remember how to re-code all the sensors, will you even have a PC with the Arduino software and all those obscure library's you found on that eco something forum that no longer exists?

Everyone can have their own method/documentation for keeping their system maintained/repaired.
I intend to keep spares of everything, Arduino's already programmed with the sketch, sensors with a plug fitted ready to swap after the plumber visits.

Steve

That's where the tmp or LM sensors come in. They can be packaged exactly like the Dallas or maxim sensors. But they spit out analog voltag like a thermistor. If one fails you just change it. No funky serial numbers or anything.

[takyka]

Hello,

First of all thank you for kind welcome!
I added my source code to github. As I can't add links yet, please go to https:// github dot com slash takyka slash heatpump to get it.

The starting point is "heatpump.ino"
I know, the code is ugly looking, sorry for that. But at least no goto used at all. :-)

There is Hungarian text in some places (presented by the software on the web status page) I will translate it to English sometime.

I will start a new thread here to discuss the sw in detail (if you want to).

T.

[Ormston]

Last year i wrote a overly complicated weather compensation function to control our ASHP (we have no internal thermostat).
It was based on the method Worcester Bosch(Rebadged IVT) GSHP's use and matched the heat curves in their manual perfectly.
All winter i adjusted the settings, the heat curve, the ofset, the hysteresis and sometimes the house was the correct temperature. Then the weather would change and we'd be too hot again, more adjustment and a week later it'd be chilly in the house.
By march when i turned the heating off we had is sussed and the only time the system didn't cope well was after a few days with very high solar gain.

The short version, it took a whole winter of messing to get the weather compensation set correctly.

Towards the end of winter i was asked to look at a GSHP and a ASHP at 2 properties owned by a local builder, both were alarming due to incorrectly set weather compensation with the heat pumps objecting to the return temp or the water being far higher than they expected. The heat pumps were fighting the internal thermostats.

The GSHP used the system i had copied(I had commissioned the heat pump for him 2 years earlier) so i made a guess at how much to turn it down and told him to call me if it still alarmed. Nothing yet

The ASHP (by the same manufacturer) had a complete different method of setting up the weather compensation. One that doesn't involve picking a number between 1 and 10 and waiting to see what happens and even better in can be re-created in Arduino with only line of code.

For anyone that wants weather compensation and hasn't fallen asleep yet.


DesiredWaterTemp = map(osTemp, coldOS, hotOS, coldWater, hotWater);

Descriptions

DesiredWaterTemp is the return temp from your heat emitter or buffer tank.

osTemp it the current outside temp

coldOS is the outside temp on a cold day, you need to record this value and the required water return temp needed to heat your house.
coldWater is the return water temp you recorded on the above cold day

hotOS is the outside temp on a warm day (that still requires heating), you need to record this value and the required water return temp needed to heat your house.
hotWater is the return water temp you recorded on the above hot day

Hope someone finds this useful

Steve

[jeff5may]

AC,

OK, I did some research about the RS485 serial, and it seems to be almost just like standard (RS232) serial, only with balanced line output. The arduinos don't natively support it, so you're going to have to add an adapter. The bad new is if you use the built in serial port to translate, you will need 3 pins: D0, D1, and 1 more digital pin. So for a generic MAX485 board, you will connect the 3 digital pins, 5V, and ground to the module, totaling 5 pins.

[AC_Hacker]

Originally Posted by jeff5may

AC,

OK, I did some research about the RS485 serial, and it seems to be almost just like standard (RS232) serial, only with balanced line output. The arduinos don't natively support it, so you're going to have to add an adapter. The bad new is if you use the built in serial port to translate, you will need 3 pins: D0, D1, and 1 more digital pin. So for a generic MAX485 board, you will connect the 3 digital pins, 5V, and ground to the module, totaling 5 pins.

Good work.

I've been ripping & rending on my house lately, to move things in the direction of a highly insulated room with a low-temperature hydronic floor (in preparation for the heat pump install). So, I've been more focused on nail pounding, than keyboard pounding.

So, I think I'll build a board using the hardware you choose, but my application will be a bit different... so that will get us at least that much closer closer to a GPC board, made from very widely available hardware.

I understand the thinking behind having a serial port because that can
not only allow monitoring & logging, but it opens the possibility of making a standalone controller become a sub controller in a more complex setup... right?

So jeff5may, if you think we have enough pins to do the job, let's go with it.

Keep me current as to what you consider to be the hardware requirements, and I'll do an order...

So far, it looks like:

• Arduing Mega R3
• DFRobot LCD Shield
• RS485 adapter (shield? chip?)
• 4-relay shield

...am I up to date?

* * *

BTW, I was having a bit of trouble getting to takyka's code at 'github', so HERE_IS_A_LINK to his code, which he has generously shared with us. Thank you so much!

-AC

[NiHaoMike]

STM32 is cheaper and more capable than Arduino Mega.

[takyka]

What functionality is planned here for the controller, a 32bit microcontroller is not mandatory. However a good thing.
I don't have any problem, handling floating point numbers by Mega even it has to deal lot's of stuff concurrently. Having a 32bit controller is good thing, but
huge advantage of arduino, the popularity, convenient, beginner friendly development, wide range of shields and libraries. These things help work off 8bit controller's handicap.
Can be I'm wrong here, I don't know nothing about STM32 ecosystem.

Related to 1wire, I'm not afraid to share one 1w line with multiple sensors. To (re)place new sensor and assign it to any function is easy from my config menu. No need to reprogram the controller. Any time attached sensor is detected automatically and listed as unused. I like ds18b20 because it's calibrated out of factory and high resolution. However it's quite slow.

rs485 does not specify any protocol, used for communication. It is specification to the electrical characteristics of the communication. If you want to use rs485 to communicate to remote PC I would recommend ethernet and TCP/IP instead. You may avoid PC side programming and implementation of a communication protocol.

If I would start the development of my controller with my current experience, I would go with beagle bone black instead of any microcontroller. To implement concurent tasks, having web interface is a pain in microcontrollers. Why I didn't choose BBB in the begining, I was afraid about realtime processing capabilities. Meanwhile I realised, there are two PRUs (32bit independent microcontrollers capable to reach I/O and shared memory) in BBB. Those could handle easily time critical tasks.

T.

[jeff5may]

AC,

For the first version of a controller, I would like to use an uno. Having less pins isn't a bad thing unless you want to do something like takyka did, and have gobs of sensors and comms in lots of platforms at once. Actually, i kinda picked the lcd shield i did because it gobbles up some pins, while making others available to directly wire to the shield. That way, the uno can be easily yanked to change sketches or whatever and be put right back into the unit. While it's running, the keypad is available to mess with "user" functions and menus built into the sketch. Or you can use an icsp connector in situ (or usb - hopefully: not 100% sure until i see it work with serial comms off pins)to program. Either way, the shield will still fit on a mega and have more pins open for expansion later.

I have a good question for you: what kind of data is the thing you will be controlling this unit with going to be sending and receiving? Switch states? readings of what frequency? Keep alive sgnals?

When we get this uno version working, a mega version can be built with a massive amount of possibilities (aka huge configuration file, a handful of libraries, and massive setup/conditions/states/ menus) built in. By then, it will be easier for me to attack and manage the beast.

[NiHaoMike]

Use a RTOS (such as FreeRTOS) to handle multiple tasks at once.

[AC_Hacker]

Originally Posted by NiHaoMike

Use a RTOS (such as FreeRTOS) to handle multiple tasks at once.

NiHaoMike,

These are such splendid ideas.

Don't you really think they belong on your "Advanced Heat Pump Controller" thread?

You did start one, right?

-AC