New binding suggestion: Wavin AHC 9000 / Jablotron AC-116

I am considering making a binding for Wavin AHC 9000 floor heating controller (same as Jablotron AC-116):

The controller has a modbus RTU interface, which is used by the optional display unit for things like weekly schedules and special modes. I have the modbus register description, and have managed to whip up some python code to communicate with the controller. I am using an FTDI-based USB-to-RS485 adapter.

It does not seem easy to get this working with the existing low-level modbus binding, because the controller uses non-standard function codes and register addressing.

I guess I will start out with simply reading the room temperatures into OpenHAB, then the next step could be changing setpoints.

I am new to OpenHAB (just installed it), so any suggestions for how to get started will be welcome (of course there is no need to repeat the tutorials). Any pointers to other bindings implementing multi-zone heating, to get some inspiration from?


Hey Spiff42,

I have as well been looking seriously into creating a Wavin AHC 9000 binding, or simply using existing Modbus bindings. However, as you also discovered the Modbus implementation made by Wavin, uses none standard Modbus function codes (typically 0x60H instead og 0x6H). Expect we need some good Java coder to make a new binding based on Modbus + Wavin specific implementation of same.

Any ideas?


Well, it’s been quite some time since I coded Java, but it’s just another language, right?

I work as embedded SW developer, and have done a lot of different serial communication, so I really don’t think that will pose a problem.

As I said, I already have some Python code that can read and write registers, so the initial steps of reading temperatures and adjusting the set-points will pose no problems.

I think the largest obstacle for me is finding the time to get this done, among my other projects and my family :slight_smile:

But perhaps knowing that others are interested could help me getting it done :wink:

And surely someone willing to test it and come with suggestions for improvements will help as well.

I can start saying Im also very interested in such a binding, and is willing to assist with the testing.

I’m interested in supporting such a solution. I can’t do any programming but I can help out testing.

Sorry about the late reply. There have been so much else to do, and not much need for floor heating, so I have had this on the back-burner for now.

But for those who have replied that they would be interested in testing, you will need the hardware:
An USB-to-RS485 adapter.

The ones using an FTDI FT232 chip are probably easiest to get working, since this chip has logic to handle the transmit-enable on RS485. Once we have something basic working, we can try getting other USB-to-RS485 adapters integrated.

Personally I used an isolated version:

Then you do not need to worry about ground loops etc., but of course there is a substantial price difference compared to non-isolated versions:

Apart from this, all that is needed is a CAT5 or similar network cable with an RJ45 plug. Just buy a cheap network cable and cut off one end.


Searching the web gives some interesting documents:

Wavin’s Modbus Specification
Modbus address

and Physical connection (sorry in Danish only)

Yeah, I have those.

I also have python code to interact with the controller (I can read out temperatures, adjust setpoints, and enter the special modes like holiday and party).

My plan for openhab is to start with just reading temperatures from the thermostats, and then changing the setpoints.

However, further down the road, I want to have some more intelligence in the openhab plugin, because if everything has to be written with rules, even a simple weekly schedule gets quite complicated.

Hi Mikkel,

Any chance you want to share your Phyton code? In case, I could ask some friends with Java knowledge, to support with a code migration to Java for later OpenHab binding implementation?

Code credit of course remain yours :slight_smile:

OK, I put up the python code on github:

Unfortunately it seems I cannot find my notes from looking into it, I will try to re-create it.

One thing, though, I remember off the top of my head is, that the “Elements” described in the Wavin modbus specification document are the thermostats, and you read the “assignment map” from each to find out which channels (telestats/heating circuits) are controlled by the thermostat.

Added a few examples of reading (and understanding) the data from the controller.

I would like to mention that I am very interested in the development of a Wavin AHC 9000. I’m not experienced with openHAB binding development, but I would very much like to be a tester and otherwise participate in the binding development.

My personal setup is two Wavin AHC 9000 controllers connected to each other, so maybe that setup may be of interest for the development / testing of the binding. - Currently the main controller has a touchscreen attached to it, from which I can control both controllers. From my understanding I would need to remove the touchscreen and connect a Modbus interface instead (i.e. a RaspberryPi?).

@jakobjp: I can confirm that you would need to disconnect the display, and have openhab be the modbus master instead. Great with a tester with a somewhat more special configuration.

I also have the touch display, and have sniffed a lot the communication between the display and AHC9000, in order to work out how to set various modes, etc. in the AHC9000 (if anybody is interested, see , some of it has my notes/comments)

Great with some progress here… good job.

Can you elaborate a bit on which RJ45 pinouts you are using ? - “+” to “+” and “-” to “-” i expect… But are you also using ground and 24V ? - Currently i have only wired ground along with +/-.

If I test using the enclosed read examples i get: “No communication with the instrument (no answer)” as response

if i wire “-” -> “+” and “+” -> “-” and using ground i get “Too short Modbus RTU response (minimum length 4 bytes). Response: ‘\x00’”

Would we great with a bit of input here :slight_smile: - thanks in advance

I use to communicate with Wavin. I run another one directly to my Nilan CTS602 without any problem.

Yes, “-” to “-” and “+” to “+” (also known as A to A and B to B). And normally you need to connect GND as well. The only case where you should not do so is if the two devices already have a common ground connection, e.g. because they are using the same power supply, but that is not likely here, because wavin has its own 24V power supply.

The 24V is not used here, but is there to power e.g. the touch screen.

One possible cause of it not working is that you may need a termination resistor. My USB-to-RS485 adapter has one built in, that can be enabled or disabled, I have it enabled. I suspect the AHC9000 does not have one, because that would not work well when daisy-chaining multiple controllers. The correct way to terminate an RS485 bus is with a 120 ohm resistor across A and B at each end of the cable. However, with a short bus and low speeds it seems to work with just one termination resistor. Since the characteristic impedance of CAT5 cable is 100 ohm I guess a 100 ohm resistor would be equally fit in this case.

Roger that. Good input

Does the usb adapter you mention above have built in resistor?

If you disable the built-in resistor, will you get the same error as I do?

Will try and get some resistors 100 and 120 ohm

The adapter I have (and that I linked above) has built in termination resistor (120 ohms), which is enabled by connecting a wire between screw terminals 1 and 2. I haven’t tried without the termination resistor.

Just got some 120 and 100 ohm resistors… Tried with both between A and B on the dongle side. All with the same result as before. Just gets the respond:
IOError: No communication with the instrument (no answer)

Which Python are you using ? - Im using Python 2.7.9 on a Raspberry Pi.
What is your cable length ? im running 1,5m CAT 5E

Any other ideas ?

I’m using 2.7.13 on Debian Stretch x64. My cable length is also about 1.5-2 meters.

My only suggestion is that your USB-to-RS485 adapter is not working correctly, either not driving TX-enable at the right time, or not driving RX-enable at the right time. Even though you have one based on an FTDI-chip it could be wired in a way that requires you to drive TX enable or RX enable from the control lines.

Unfortunately the AHC9000 does not have an LED to indicate modbus activity. You don’t happen to have access to an oscilloscope or similar, to actually see if something is on the line?

The minimalmodbus documentation has some considerations regarding hardware: