New binding - Rego 6xx based heat pumps

Hi all!

I’m working on a new binding for a heat pump I own - an IVT Greenline 11e, based on a Rego600 (specifically rego637) unit. The Rego6xx units are used in many heatpumps, like IVT/Bosch/Autotherm/Carrier and others.

Based on information I was able to collect from various web sites:

I managed to implement a binding capable of accessing many parameters:

  • radiator return temperature,
  • outdoor temperature,
  • hot water temperature,
  • forward temperature,
  • room temperature,
  • compressor temperature,
  • heat fluid out temperature,
  • heat fluid in temperature,
  • cold fluid in temperature,
  • cold fluid out temperature,
  • external hot water temperature,
  • last error,
  • heating curve,
  • front display leds,
  • and many more…

The binding source code can be found here.

I haven’t build the hardware piece yet, but here are some details - the Rego6xx unit has a DB-9 serial interface. Due to it’s nature it can only operate on a really short distances. To overcome this, I plan to use a ESP-01 module (serial to wifi) and install a serial to wifi bridge firmware (there are a couple already available for the before mentioned board) - this way there will be no need to install additional wires between computer room and laundry (and therefore binding uses a tcp connection).

Since messing with the heat pump is not something to take lightly, I also build a simulator to test the binding before wiring everything up - if somebody is willing to play with it, source code can be found here - it’s a .Net project.

In order to use the binding, you need to add the following line to the .things file:

regoheatpump:ipRego6xx:ivt [ address="localhost", refreshInterval=60 ]

address is the ip address of of the heat pump and the refreshInterval is the interval in seconds used to refresh the values. One can also specify a tcp port to be used with the connection. So if one also runs the above mentioned simulator you are now able to read simulated values from the “heat pump”.

Adding something like to the .items file:

Number GT1_Temperature "Return temperature (GT1) [%.1f °C]" <temperature> { channel="regoheatpump:ipRego6xx:ivt:registers#radiatorReturnGT1" }
Number GT2_Temperature "Outdoor (GT2) [%.1f °C]" <temperature> { channel="regoheatpump:ipRego6xx:ivt:registers#outdoorGT2" }
Number GT3_Temperature "Hot water (GT3) [%.1f °C]" <temperature> { channel="regoheatpump:ipRego6xx:ivt:registers#hotWaterGT3" }
Number GT4_Temperature "Shunt, flow (GT4) [%.1f °C]" <temperature> { channel="regoheatpump:ipRego6xx:ivt:registers#shuntGT4" }

String Last_Error "Last error line [%s]"  { channel="regoheatpump:ipRego6xx:ivt:status#lastError" }

will give you some of the values. Last step, add those to the .sitemap file:

        Text item=GT1_Temperature
        Text item=GT2_Temperature
        Text item=GT3_Temperature
        Text item=GT4_Temperature
        Text item=Last_Error

As pointed out, before actually moving to the real device, I would really appreciate if somebody is willing to check to binding code to minimize any errors/issues since I really don’t want to mess the heat pump, specially not in the winter time :slight_smile:.

Any feedback greatly appreciated.

Disclaimer - I haven’t test the binding with a real device so use at you own risk. I will update the post and hopefully do a push request when I’m able to test the real thing. I will also add some schematic/wiring on how to build up the hardware part.

I would also like to thanks all the guys providing the details about how the Rego6xx devices work.

Note: this is still work in progress, but should be mature enough to start with initial testing. There are some endpoints I’m not 100% how data is formatted and will need an actual device in order to finalize, but this will come later.

Cheers!

3 Likes

Very interested in this project! However, I got a Rego 800 (IVT, Rego 800, Optima 3.24.2) - which only can be connected via canbus interface (own a canbus -> serial interface), so I guess it’s not at all the same binding :confused:?

The aim of this project is to add support for other Rego versions as well, specially since I come across details about Rego800/Rego1000 units. It might be more challenging since I don’t own one of those, but if there are “volunteers” who are willing to test it, I’m more than happy to provide support for those as well.

That said, I’m now focusing to finalize the initial version (Rego6xx) and than add support for others as well.

Thanks for your interest!

Very interested and keep us in the loop :slight_smile:

I would be glad to help out with your work towards Rego800 :wink:

Hello it will possible add support for Rego 2000. I have in IVT airx with Airmodule e9. thanks

Any progress or update of this planned binding :slight_smile: ?

Things are progressing slowly due lack of time, however I managed to build the experimental hardware board in the meantime and modified the simulator (see my first post for link to source code) so it simulates the Rego controller and communicates with the board using the COM port (same as the Rego unit will). For initial version I used the ESP-01 module and wrote a simple Arduino sketch app that connects to my WiFi, setup serial with 19200 bps, 8 bit, no parity, 1 stop bit, as needed by the Rego 6xx unit and acts as a transparent bridge between the two.

Those familiar with the ESP8266 (used within ESP-xx modules) will know, that at boot, it will print out (send over uart0) a message, something like:

rst cause:2, boot mode:(3,6)

and this cannot be turned off since it happens before (custom) firmware even starts. This came as a surprise since I don’t want to send something like this to the rego unit (really not sure if those bytes would actually cause any issues with the rego unit, but would rather not find out the hard way). Therefore I modified the original board design to workaround this and will not use the default ESP8266 uart, but rather MTCK/MTDO, as suggested by the chip designers in order to get rid of the boot up message.

Since ESP-01 does not expose those pins (MTCK/MTDO), I need to get my hands on an ESP-07 or similar to try it out.

However, I’m already testing the binding using my test environment:

openhab+rego binding <-(wifi)-> esp-01 transparent bridge <-(serial)-> desktop computer running rego simulator

Things are working rock solid for a couple of days now and if there would be no message at boot, as described above, I would already be testing with the real thing, that is, with the heat pump. So, I dare to say the binding code itself is ready, but I’ll wait until I test it with the heat pump and than make the pull request.

Some teasers


New board design

Really nice work you’ve done! Let me know when you are looking at the implementation for rego800 :wink:

I did a quick spike on how rego800/rego1000 work and in order to get started, I would really appreciate if somebody is willing to provide a binary dump of the can-bus traffic. As far as I understand, the rego units use 125kb/s with 29 bit extended IDs.

Really not sure what sniffer/capture tools with direct can-bus support exist, but I guess one can achieve the same even using a tool like Realterm. This would require initial setup to be made manually:

  • setup serial port with 57600baud, 8 databits, no parity, 1 stop bit;
  • setup can bus speed to 125 - send “S4[CR]”;
  • open the can channel - send “O[CR]”

As a note, [CR] stands for ASCII 13, which in fact is ASCII code produced when you hit the ENTER key. And " chars are not part of the command, while commands are case sensitive.

More info can be found below:


Please let me know if I missed something.

Ok - I’ll see if I can hook up a computer or an RPi (with ser2net) - if I dare :slight_smile:

Not sure how to set the following:

?

I’d say simply type S4 and hit enter within the terminal window.

The link provided above (pdf) says:

1.2 Testing the CAN232
Test the CAN232 by installing it to a PC’s COM port and power it up according to instructions on
previous page under section 1.1. When the CAN232 gets power the 2 LEDs (red & green) will blink
rapidly some times depening on what RS232 speed it is set up to (this works only on version
V1013 and later, V1012 had only one long blink and prior to that no blink at all). If the RS232 is set
to 57,600baud (default when delivered) both LEDs will blink 3 times (the higher RS232 speed the
less it blinks, see the U command for more info). Then start Windows Terminal software and set it
up to e.g. 57600baud, 8 databits, no parity, 1 stop bit (if the CAN232 is set to 57,600baud), also set
local echo on so you can see what you type and set the check flag so that it appends a line feed
when it receive and end of line. Then make sure you are connected and press >ENTER< and it will
make a new line, then press V and >ENTER< and it will print/reply Vhhss, where hh is the hardware
version and ss is the software version. Now you know you have full contact with the CAN232 unit
and can set it up with a CAN speed and open the CAN port, send and receive frames. Note that
the green LED indicates that a CAN frame is succesfully sent or received into the CAN232 unit.
Note that you must at least have 2 nodes to send/receive CAN frames and that the CAN cable
network is terminated at both ends with 120 ohms over the CANL and CANH lines plus that a
twisted pair CAN cable is used. The CAN232 is set to accept all frames, so no need to set filters
etc. for testing.

So you can first try to run the V for version command.

I’d recommend to first try one of the tools that already support can, maybe one of those listed here - CAN232 Support | canusb.com

A quick update - since testing the board and binding with the simulator worked without any issues, I finally decided to try out the board/binding on the heat pump.

Feeling really excited, I connected the DB9 to the heat pump and waited for values to pop up within the openhab UI - but unfortunately, there was none :frowning: Logs revealed that requests were send to the board/heat pump, but no response was coming back. Ow the horror! After a couple of days questioning every component involved it turned out that heat pump’s transmit (Tx) pin does not produce enough current and is not able to drive the diode within the optocopler directly. Therefore I added an OR gate (74HC32) which I had lying around between Tx and optocopler’s diode and voila - it started to work! Please note that a transistor or similar could be also used.

I’m still waiting for the ESP-07 to arrive to assemble the final board, currently I’m testing with ESP-01, which has some limitations, as described in my previous post + found a new one, which is actually a deal breaker - the Tx pin (GPIO1) of the ESP-01 must be pulled up on reboot, otherwise ESP8266 will enter chip test mode. However, Tx pin is tight to the optocopler’s diode, taking the pin to ground. To be able to test, I disconnected the Tx pin on power up and manually reconnected after ESP module is running. This should be fixed when I use the MTCK/MTDO pins.

Setup described above is running now for two days without any issues, so feeling happy! :slight_smile:

Bellow is the updated board:

Just wanted to share my results, please see the screenshots:

Paper UI:

Basic UI:

Grafana charts (last 24h):

Just created a pull request since binding seem to work really well without any issues - so wish you all the best in the upcoming new year!

Hi!

Long time no see :confused:

Well - now I have connected my interface to the Reg800 panel. Data seems to arrive when connecting and I can verify that it seems “valid” if I compare to the specifications. What I don’t know, if this is my interface “protocol” or if you will recognize it as something useful :slight_smile:

The data arriving when connecting is like:

XR000101C2
XR00010384
XR000101C2
XR00010384
XR000101C2
XR00010384
XR000101C2
XR000B0380
XR00010384
XR000101C2
XR0006FF93
XR0006FF94
XR0006FF96
XR00010384
XR0006FF97
XR000101C2
XR0006FF99
XR000EFFDC
XR000901F7
XR0006FF9A
XR0006FF9C
XR00010384
XR000101C2
XR00010384
XR000101C2
XR00010384
XR000101C2
XR00010384
XR000101C2
XR000EFFDD
XR00010384
XR00050199
XR000101C2
XR0006FF9A
XR000B0384
XR0006FF99
XR00010384
XR0006FF97
XR000101C2
XR0006FF96
XR000401E8
XR00030191
XR0006FF94
XR0006FF93
XR000B0380
XR0006FF91
XR0006FF90
XR0006FF8E
XR0007FFDF
XR00010384
XR000101C2
XR000101C3
XR00010384
XR000101C3
XR0006FF90
XR0006FF91

I have attached the PDF for the interface documentation here.

Is this something that could extend your binding, or are we looking at something completely different that needs a new binding :slight_smile: ?

H1 Manual 10.28.pdf (619.4 KB)

Thanks for provided information.

If I understand correctly, you didn’t connect your computer directly to the heat pump using i.e. canusb or can232. It seems that you own an interface that simplifies and unifies the communication between heat pump(s) and computer. Based on provided data, I guess the following is true:

XR000101C2 => Radiator return = 45°C
...

However, I’m after “raw” data coming from the heat pump, that is data, that were not modified by some 3rd party hardware or software - CAN packages, coming directly from the heat pump. This way binding should be able to communicate with the heat pump(s) using as little components as possible.

Please let me know if my assumptions about your setup are wrong.

My plan is to extend the existing binding and include support for rego8xx so beside

regoheatpump:serialRego6xx:ivtSerial [ portName="COM3" ]

we’ll also have i.e.

regoheatpump:serialRego8xx:optimaSerial [ portName="COM1" ]

I realised this just after posting the reply to you. I have a C1 interface developed by a company called “Husdata” (eng: House data). This interface simplifies the communication as well as offering the same interface independent of which heat pump you have (Nibe, IVT, etc).

So - unfortunatly I guess in my case, that I will need a “Husdata” binding.

Hm, so there is no way to connect to the heat pump “directly” without using the additional interface? Does this interface comes bundled with the heat pump or do you have to purchase it separately?

If you cannot directly connect to your heat pump CAN interface than I guess this calls for another binding :slight_smile: The bright side is that the Husdata interface seems to provide simple/clean data so implementing such a binding should be fairly simple and I guess it comes with software by itself. The only down side I see is the additional cost, while you could get similar functionality using software (binding) only, capable of decoding “raw” CAN packages coming from the rego8xx unit.

Exactly as you thought - for a while ago I bought that interface separetly … Will have to figure out if I should look for a different solution in order to take the raw data - or if I should develop the Husdata-protocol :slight_smile:

I guess you’ll need something similar to this if you want to connect the rego controller to your computer without the Husdata interface. I have to say I was a bit surprised since I thought that such can/rs232 or can/usb adapters would be much cheeper :disappointed: More links.

Please let me know if you’ll decide to try out the “direct” connection.

Absolutely - from what you have seen - would it be much work to extend the binding to support Rego 800?

It’s a bit of work to create a new binding - so if it’s a “no brainer” for you - I’ll might take that in consideration… :slight_smile: