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

Add-ons Bindings
, ,
21

So status is:

  • tested with resistors in both ends, 100 and 120 ohm
  • made new cable from scratch and tested connections
  • tried to swap A and B
  • bought a display to check the firmware version (it worked fine)

so im pretty tired of it right now… I want it to work, so i guess i have to order a new USB dongle. Is the link above the exact dongle you use. I see several similar version on ebay, but at a much lower price. I just want to be sure its the same you have used with success.

Can you attach a photo of the wires going into the skrew terminals. To validate in future how its should be connected ?

22

Yes, I can confirm that this is the exact one I am using:

I hadn’t even noticed the cheaper ones that look much like it, but I think they use CH340 chipset instead of FTDI (don’t know if that works with TX enable), and they are surely not isolated. In the one I link above you can clearly see the FTDI chip (near the USB connector, with more pins than CH340), and the ADM2587 isolation driver along with the isolation on the circuit board.

I am pretty sure some of the other (cheaper) ones will also work, but of course I cannot say for sure without having tested it. Maybe someone else here (i.e. someone with an RS485 adapter and a Wavin AHC9000 controller) can try it out and pitch in?

I will see if I can take a picture and attach it, but until then, I can say that I have a short piece of wire connected between pins 1 and 2 (the ones labeled RT). This effectively enables the termination resistor.

Also, since you have bought the display, I can say that I have used the RS485 adapter to sniff the traffic between the display and AHC9000, which helps in understanding some of the features (as the documentation does not really explain how the various registers should be used together). It would be possible for the openhab binding to run in passive mode, where it just listens in on the display communication, and reports temperatures from the thermostats, etc.

In fact, let me add a small python program to the repo, which can be used to sniff the RS485 traffic. This is the one I used to create the “dispdump decoded.txt” file. I will put it up when I get home from work (if I remember), then you can try that and see if your RS485 can receive, but is just not sending (e.g. transmit enable problem).

23

Thank you for helping… I have ordered your recommended USB dongle, but unfortunately delivery takes a month like anything else from China :slight_smile:

Great if you cound upload the sniffer to GitHub. How is it connected, and how flows data ? Do you simply connect both display and modified RJ45 cable to AHC9000 at the same time… Then runs the sniffer on computer ? So dataflow would be like “Display” -> “RJ45 port 1 on AHC9000” -> “RJ45 port 2 on AHC9000” -> “RS485 adaptor” ?

24

I put serdump on github with a short instruction in the README.

Yes, I have connected the display on one port of AHC9000, and the RS485 dongle on the other.

25

Hi,

I’m also having trouble connecting to my AHC 9000 - can anyone tell me which baud and so on you hare using to connect?

26

38400 baud. But how are you trying to “connect”? Did you look at wavin_modbus.py, or something different?

27

did not see that. I will look into it…

28

I have bought this USB-to-RS485 adapter as well (much cheaper, and can be bought from UK to avoid the long delivery times from China):
http://www.ebay.co.uk/itm/USB-To-TTL-RS485-Serial-Converter-Adapter-FTDI-FT232RL-Downloader-Module-TE661/142450693286
I was able to make the communication work with the Python code. When I connected the display as well, the display could not communicate with the AHC9000. I am not entirely sure what caused this problem, but it seems display is transmitting on the bus, but AHC9000 did not reply. I really don’t know what causes this problem (could be a ground loop or maybe the adapter I got is faulty), but I thought I would share my findings.

If anyone has managed to get the python code working, please let us know about your hardware.

BTW: This adapter has a built-in termination resistor (R5), which cannot be disabled (unless using a soldering iron, or otherwise destructive action). However, I don’t think that is the problem, as I am also using a termination resistor with the other adapter, and that is working fine.

29

Finally i received my dongle… jesus it takes time sometimes.
I have been looking so much up to get things running… and now there seems to be some kind of connection.
If shortcircut pin 1 and 2, and connect gnd, + and - to the respective on a LAN cable… Thats a good start. I start python, and loads the lib + map the port. Just like described on Github. I tried to run eg. wa.readRegisterFromIndex(2, 0, 3, 17) but i just get random responses: Example:

Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
  File "wavin_modbus.py", line 43, in readRegisterFromIndex
    reply = minimalmodbus._extractPayload(response, self.address, self.mode, functioncode)		
  File "/usr/local/lib/python2.7/dist-packages/minimalmodbus.py", line 1075, in _extractPayload
    raise ValueError(text)
ValueError: Checksum error in rtu mode: 'C\x1e' instead of '\xc3\x97' . The response is: '\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00Iz\x02C\x01\x00#\x0f\x1c\xfe\x02C\x1e' (plain response: '\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00Iz\x02C\x01\x00#\x0f\x1c\xfe\x02C\x1e')

If i start serdump in a seperate terminal, and then run the exact same code i get a fine and 95% consistent response.

wa.readRegisterFromIndex(2, 0, 3, 17)
repl 35
[220, 210, 190, 150, 60, 250, 0, 16384, 60, 400, 220, 270, 30, 500, 2, 0, 220]

But sometimes serdump then crashes, and needs to be restartet to provide with a response. Seems to make no difference if display is connected or not.

Can spiff42 help me out here ?? seems to be pretty close.

30

I think I can explain:

If you have the display connected, it is constantly polling the AHC9000, and the reply from the controller gets into the receive buffer and messes up. If serdump.py is running at the same time, that will empty the receive buffer. This modbus interface is NOT designed for multiple masters, so you should use serdump.py with the display connected, and wavin_modbus.py only when the display is not connected.

The two python scripts are not really meant to be run at the same time. I actually hadn’t expected it would work at all.

Finally, I discovered another buffering problem. I was running a loop reading the time from the controller. Occasionally it failed to receive the response, leaving it in the serial RX buffer, so the next call got the response. But then when I sent a different command, I got the wrong response. This has been fixed in the python-script by flusing the RX buffer before sending a new request. Updated on github. You may be seeing this problem if you disconnect the display without clearing the buffer, which could possibly explain why you are seeing problems when the display is not connected.

Try using the new version of wavin_modbus.py , which I committed just now, run without the display connected, and see if you can get the expected response.

31

YES… finally its up and running… I have built a bit of json for in and output for mass updating a resultfile… works okay, but also need to run a couple of time for all value to be updated successfully. I guess its the entire interface to the wavin thats a bit buggy, as it may result in an error once, but next time it works fine. Had to set a timeout for 1 sec to get things rolling a bit better.
I think the manual is a bit hard to figure out. I am looking for data from the thermostats, but i cannot seem to get the result from wavin to match the value in the display. Do you have a good mapping table or something for the parameters to lookup ?

32

You have to look at the “elements” (those are thermostats, window switches, etc.)

Look at https://github.com/spiff42/wavin-python/blob/master/dispdump%20decoded.txt#L4986 (line 4986).

I have only wired thermostats, so battery and RSSI make no sense. If you have wireless thermostats, I would like to see the data.

33

Sure… Currently i poll all data from Elements and Packed Data for my 11 channels. See link below.
Do you know where to get info about if the acurator is currently open (heating) og Closed. Cannot seem to find it.
http://dreamnet.dk/test/wavin/data.json

Any ideas for more data to poll ?

34

If you look at the channels category, the first register has various flags. Bit 4 is “OUTP ON”. Getting the value of bit 4 is equivalent to ANDing with 16. Here is an example of reading the register, first when not heating, then after turning up the setpoint so heating started.

>>> wa.readRegisterFromIndex(3, 0, 0, 4)
[8481, 0, 196, 2153]
>>> 8481 & 16
0
>>> wa.readRegisterFromIndex(3, 0, 0, 4)
[8631, 83, 196, 10]
>>> 8631 & 16
16

You can also look at the second value (83 above), which indicates the current consumption of the actuator. You will see 0 when actuator is off, a high value (5-8W) when it just turns on, and then decaying to a lower value after a couple of minutes, when the actuator is fully open. In this case the actuator is using 3.69W.

>>> 83 * 24 /540.0
3.688888888888889

I don’t think there is much else worth polling. We need to get this into openhab, so we can have it run a schedule, set the various modes (holiday, party, etc.) :slight_smile:

35

Hi Jakob, I have a fully working Wavin AHC 9000 binding, have only tested it with one controller. Are you interested in trying it? Best regards, Peter Kristensen

36

Hello Peter,

That sounds great, could you share a few details about what you have implemented (e.g. reading temperatures and setpoints, changing setpoints, etc.)?

Are you using wired or wireless thermostats?

I would gladly participate in testing, although my setup is fairly basic (one AHC9000 with 16 actuators and 12 wired thermostats).

37

Wavin AHC 9000 using wireless thermostats. Reading and writing all possible values - i.e. setpoints, RSSI level, battery status, weekly calendar for setting i.e. holiday mode etc.

Tested it on RPI3, Windows and MacBook - not all details are fully tested.

It has auto discovery of thermostats, actuators etc.

Modbus is a bridge with the following devices connected

  • Main controller AHC 9000
  • Actuator
  • Wireless Thermostat

Best regards,

Peter

38

Hello Peter

Yes, I would like to test the binding :slight_smile:

Please advise what is needed (or where I can find more info?). Currently I have openHAB on an RPi3, however, that one is physically not close to the Wavin controller. - So I guess I could/should get another RPi3 and some adapter to connect to the the Wavin controller?

Best Regards
Jakob

39

Hi Peter,

I would also be very interested in testing your binding. Having OH2.2 running already on PI3 with various bindings installed. IHC binding and ComfoAir binding for Zehnder WHR960 ventilation (serial comms) being my primary used.
Using Python script provided by “spiff42” (Mikkel Holm Olsen), I have already the basic serial comms up running, and can read various registers. Therefor next step would be a starting OH binding :smile:

Best regards
Torben

40

Hi All.

Nice progress on Wavin AHC 9000 :slight_smile:

Anyone know if AHC 8014 can/will be supported?

Would also be interested in a “How-To” for connecting it to a computer.

/Morten