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

Thank you! Hardware ordered now, I will write back when I receive it (about a month from now). I could help with the Java project but need to get myself familiar with OH first :slightly_smiling_face:
Now I will have one month to crack Nilan CTS700, enjoy the summer!

Hi Katerica,
While I’m waiting for the hardware I started some experiement with running OpenHAB as docker container on my QNAP NAS. I have an RS232 adaptor but couldn’t seem to get it pass the data to the docker conatiner. Anything special you did to make it work? Thank you!

Hi @somy,

First of all i think you need RS485 and not RS232 - at least all of us here use RS485 i think. I don’t know if it will work over RS232. See the USB-RS485 controller spiff42 posted at the beginning of the thread. This is the device you need. I also posted another one from Amazon but the one spiff42 gave is better because of the optical isolation. Mine also works fine but carries some extra risk of runaway ground loops - mostly a concern in older buildings.

That being said, how are you with connections? Did you figure out how to wire things? If not let me know i will post a brief description.

Now to your actual question - docker.

You need to pass the entire device to docker - not only the data. On older Linux distros the FDTI driver might not be loaded - this is my case on an old Synology (>10 years). Funny enough the driver is part of the distro but not loaded. If you QNAP is new this should not be an issue.

You can tell if you need extra drivers loaded by checking your dmesg when you plug it in. If you get a new ttyUSBxx then all drivers are in place. Otherwise you need to load them.

If you need to load them insert this in your /etc/rc.local

insmod /lib/modules/usbserial.ko
insmod /lib/modules/ftdi_sio.ko

chmod 777 /lib/modules/usbserial.ko
chmod 777 /lib/modules/ftdi_sio.ko

chmod 777 /dev/ttyUSB0

The order of loading the drivers is important. The permissions are probably too high and some security guru will complain but i can never figure out these things and my NAS is not open to the world so i don’t mind. ttyUSB0 should of course be replaced by whatever dmesg says.

So after installing the device you can start the container and pass the device to openhab, I use this run command:

docker run
–name openhab
–net=host
–tty
-e “EXTRA_JAVA_OPTS=-Dgnu.io.rxtx.SerialPorts=-Dgnu.io.rxtx.SerialPorts=/dev/ttyUSB0:/dev/ttyS0:/dev/ttyUSB0:/dev/ttyS2:/dev/ttyACM0:/dev/ttyAMA
-v /path/to_local/openhab/conf:/openhab/conf
-v /path/to_local/openhab/userdata:/openhab/userdata
-v /path/to_local/openhab/addons:/openhab/addons
-d
–device=/dev/ttyACM0
–device=/dev/ttyUSB0
–restart=always
openhab/openhab:2.4.0-amd64-debian

The ttyACM0 here is my Zwave stick - nothing to do with the Wavin. The Extra java options i copied from some forum somewhere and i am not sure are really needed. Once it worked (and i don’t think those made it work) i never bothered to investigate further.

Note that the above raising of permissions is needed even if your drivers load by default. The openhab docker container has options to load with certain user name but i never managed to make it work. So now my docker runs with default user (i think that is openhab) but on my NAS this user shows up with id/group 9001:9001. So unless i allow everyone to use the ttyUSB0 openhab will not see it even if you use the run command from above.

There is clearly room for improvement in my set up from permissions point of view. I dont even know how vulnerable things become of you do as I do - just fair warning.

I hope this helps and good luck!

P.S. I did some tinkering with a Synology Surveilance station binding and managed to make it work. I was however doing only minor modifications based on other people’s framework. If you manage to get an open source binding started and can take care of the Java skeleton i can assist with the various feature development. I think forking the MODBUS binding already in Openhab should be a solid base but i doubt i can manage it. A far as i can tell Wavin is a special case of MODBUS.

Thank you! I know I need RS485, just can’t wait to try out something :slight_smile:
I will write again when I receive the device from China.

Hi all,
I am currently rewriting my binding which support Wavin AHC 9000 / Jablotron AC-116. Then plan is afterwards to make it available to the OpenHAB community. I know some of you have been using the current version for some time. Any known errors, suggestions for improvements etc.

Best regards,

Peter @zmartify

Hi @spiff42 and @katerica

I have now received the RS485 to USB dongle, and now I need some advice to wire the pins.
Please see the following diagrams with network cat pins marked from 1 to 8, and pins on USB dongle from A to E.

As I read from the posts, I should connect pin 3 to E and pin 6 to D, and I also need a short wire to connect pin A and B to enable 120ohms termination resistor, please correct me if I’m not doing the right thing.
Now the question about GND, both pin 1 and 2 from the RJ45 are marked GND, which one should I use?
Thank you in advance!

Hi @somy,

Your understanding is correct:

RJ45 pin 3 goes to RS485 pin 5
RJ45 pin 6 goes to RS485 pin 4
RJ45 pins 1/2 can be shorted together into RS485 pin 3

The terminating resistors are not always needed - I skipped them altogether.

Cheers

Hi @katerica and @spiff42 ,

Thanks a lot! Now I have made some progress: I seem to get connection to the device in Docker now. After I installed the binding I noticed the following:

  1. By default it sets Nilan On and Wavin off (see screenshot below).
  2. I then change Nilan off and Wavin On (Unit address 1), and it can find a thing called “slave1” but never managed to connect to that. The controller is in a strange state “Online_bridge_offline”
  3. Did some more experiment by trying different values, I found if I set Wavin On (Unit address 2) it seems to be able to connect to the device, a thing called “slave2” is created
  4. I didn’t manage to get states of connected thermostats - as I understand from previous posts they should appear as things automatically?

That’s what I’ve got so far. I tried to look into log and can see the it keeps disconnected from the device:

2019-06-19 20:12:43.307 [WARN ] [rtmodbus.handler.ModbusSerialHandler] - Recv timeout : 403 minimumLength=5 respIndex=0
2019-06-19 20:12:43.915 [WARN ] [rtmodbus.handler.ModbusSerialHandler] - Recv timeout : 405 minimumLength=5 respIndex=0
2019-06-19 20:12:44.523 [WARN ] [rtmodbus.handler.ModbusSerialHandler] - Recv timeout : 405 minimumLength=5 respIndex=0
2019-06-19 20:12:45.131 [WARN ] [rtmodbus.handler.ModbusSerialHandler] - Recv timeout : 403 minimumLength=5 respIndex=0
2019-06-19 20:12:45.739 [WARN ] [rtmodbus.handler.ModbusSerialHandler] - Recv timeout : 406 minimumLength=5 respIndex=0
2019-06-19 20:12:46.347 [WARN ] [rtmodbus.handler.ModbusSerialHandler] - Recv timeout : 405 minimumLength=5 respIndex=0
2019-06-19 20:12:46.956 [WARN ] [rtmodbus.handler.ModbusSerialHandler] - Recv timeout : 406 minimumLength=5 respIndex=0
2019-06-19 20:12:47.321 [INFO ] [rtmodbus.handler.ModbusSerialHandler] - Trying to connect to serial port /dev/ttyUSB0
2019-06-19 20:12:47.563 [WARN ] [rtmodbus.handler.ModbusSerialHandler] - Recv timeout : 403 minimumLength=5 respIndex=0
2019-06-19 20:12:48.170 [WARN ] [rtmodbus.handler.ModbusSerialHandler] - Recv timeout : 404 minimumLength=5 respIndex=0
2019-06-19 20:12:48.776 [WARN ] [rtmodbus.handler.ModbusSerialHandler] - Recv timeout : 403 minimumLength=5 respIndex=0
2019-06-19 20:12:49.322 [INFO ] [rtmodbus.handler.ModbusSerialHandler] - Connected to serial port /dev/ttyUSB0
2019-06-19 20:12:49.323 [INFO ] [rtmodbus.handler.ModbusSerialHandler] - Trying to connect to serial port /dev/ttyUSB0
2019-06-19 20:12:49.382 [WARN ] [rtmodbus.handler.ModbusSerialHandler] - Recv timeout : 403 minimumLength=5 respIndex=0
2019-06-19 20:12:49.988 [WARN ] [rtmodbus.handler.ModbusSerialHandler] - Recv timeout : 403 minimumLength=5 respIndex=0
2019-06-19 20:12:51.324 [INFO ] [rtmodbus.handler.ModbusSerialHandler] - Connected to serial port /dev/ttyUSB0
2019-06-19 20:12:51.325 [INFO ] [rtmodbus.handler.ModbusSerialHandler] - Trying to connect to serial port /dev/ttyUSB0
2019-06-19 20:12:53.326 [INFO ] [rtmodbus.handler.ModbusSerialHandler] - Connected to serial port /dev/ttyUSB0
2019-06-19 20:12:53.326 [INFO ] [rtmodbus.handler.ModbusSerialHandler] - Trying to connect to serial port /dev/ttyUSB0
2019-06-19 20:12:55.328 [INFO ] [rtmodbus.handler.ModbusSerialHandler] - Connected to serial port /dev/ttyUSB0
2019-06-19 20:12:55.592 [WARN ] [rtmodbus.handler.ModbusSerialHandler] - Recv timeout : 401 minimumLength=5 respIndex=0
2019-06-19 20:12:56.201 [WARN ] [rtmodbus.handler.ModbusSerialHandler] - Recv timeout : 405 minimumLength=5 respIndex=0
2019-06-19 20:12:56.807 [WARN ] [rtmodbus.handler.ModbusSerialHandler] - Recv timeout : 403 minimumLength=5 respIndex=0
2019-06-19 20:12:57.415 [WARN ] [rtmodbus.handler.ModbusSerialHandler] - Recv timeout : 405 minimumLength=5 respIndex=0
2019-06-19 20:13:00.331 [INFO ] [rtmodbus.handler.ModbusSerialHandler] - Trying to connect to serial port /dev/ttyUSB0
2019-06-19 20:13:02.333 [INFO ] [rtmodbus.handler.ModbusSerialHandler] - Connected to serial port /dev/ttyUSB0
2019-06-19 20:13:02.353 [INFO ] [rtmodbus.handler.ModbusSerialHandler] - Trying to connect to serial port /dev/ttyUSB0
2019-06-19 20:13:03.022 [WARN ] [rtmodbus.handler.ModbusSerialHandler] - Recv timeout : 403 minimumLength=5 respIndex=0
2019-06-19 20:13:03.627 [WARN ] [rtmodbus.handler.ModbusSerialHandler] - Recv timeout : 402 minimumLength=5 respIndex=0
2019-06-19 20:13:04.233 [WARN ] [rtmodbus.handler.ModbusSerialHandler] - Recv timeout : 403 minimumLength=5 respIndex=0
2019-06-19 20:13:04.355 [INFO ] [rtmodbus.handler.ModbusSerialHandler] - Connected to serial port /dev/ttyUSB0
2019-06-19 20:13:04.356 [INFO ] [rtmodbus.handler.ModbusSerialHandler] - Trying to connect to serial port /dev/ttyUSB0
2019-06-19 20:13:04.840 [WARN ] [rtmodbus.handler.ModbusSerialHandler] - Recv timeout : 404 minimumLength=5 respIndex=0
2019-06-19 20:13:06.357 [INFO ] [rtmodbus.handler.ModbusSerialHandler] - Connected to serial port /dev/ttyUSB0
2019-06-19 20:13:06.358 [INFO ] [rtmodbus.handler.ModbusSerialHandler] - Trying to connect to serial port /dev/ttyUSB0
2019-06-19 20:13:08.358 [INFO ] [rtmodbus.handler.ModbusSerialHandler] - Connected to serial port /dev/ttyUSB0
2019-06-19 20:13:10.448 [WARN ] [rtmodbus.handler.ModbusSerialHandler] - Recv timeout : 405 minimumLength=5 respIndex=0
2019-06-19 20:13:11.055 [WARN ] [rtmodbus.handler.ModbusSerialHandler] - Recv timeout : 403 minimumLength=5 respIndex=0
2019-06-19 20:13:11.661 [WARN ] [rtmodbus.handler.ModbusSerialHandler] - Recv timeout : 403 minimumLength=5 respIndex=0
2019-06-19 20:13:12.269 [WARN ] [rtmodbus.handler.ModbusSerialHandler] - Recv timeout : 404 minimumLength=5 respIndex=0
2019-06-19 20:13:13.360 [INFO ] [rtmodbus.handler.ModbusSerialHandler] - Trying to connect to serial port /dev/ttyUSB0
2019-06-19 20:13:15.361 [INFO ] [rtmodbus.handler.ModbusSerialHandler] - Connected to serial port /dev/ttyUSB0
2019-06-19 20:13:15.362 [INFO ] [rtmodbus.handler.ModbusSerialHandler] - Trying to connect to serial port /dev/ttyUSB0
2019-06-19 20:13:17.363 [INFO ] [rtmodbus.handler.ModbusSerialHandler] - Connected to serial port /dev/ttyUSB0
2019-06-19 20:13:17.364 [INFO ] [rtmodbus.handler.ModbusSerialHandler] - Trying to connect to serial port /dev/ttyUSB0
2019-06-19 20:13:17.875 [WARN ] [rtmodbus.handler.ModbusSerialHandler] - Recv timeout : 403 minimumLength=5 respIndex=0
2019-06-19 20:13:18.536 [WARN ] [rtmodbus.handler.ModbusSerialHandler] - Recv timeout : 401 minimumLength=5 respIndex=0
2019-06-19 20:13:19.142 [WARN ] [rtmodbus.handler.ModbusSerialHandler] - Recv timeout : 402 minimumLength=5 respIndex=0
2019-06-19 20:13:19.365 [INFO ] [rtmodbus.handler.ModbusSerialHandler] - Connected to serial port /dev/ttyUSB0
2019-06-19 20:13:19.366 [INFO ] [rtmodbus.handler.ModbusSerialHandler] - Trying to connect to serial port /dev/ttyUSB0
2019-06-19 20:13:19.748 [WARN ] [rtmodbus.handler.ModbusSerialHandler] - Recv timeout : 404 minimumLength=5 respIndex=0
2019-06-19 20:13:21.367 [INFO ] [rtmodbus.handler.ModbusSerialHandler] - Connected to serial port /dev/ttyUSB0
2019-06-19 20:13:25.357 [WARN ] [rtmodbus.handler.ModbusSerialHandler] - Recv timeout : 406 minimumLength=5 respIndex=0
2019-06-19 20:13:25.964 [WARN ] [rtmodbus.handler.ModbusSerialHandler] - Recv timeout : 404 minimumLength=5 respIndex=0
2019-06-19 20:13:26.369 [INFO ] [rtmodbus.handler.ModbusSerialHandler] - Trying to connect to serial port /dev/ttyUSB0
2019-06-19 20:13:26.569 [WARN ] [rtmodbus.handler.ModbusSerialHandler] - Recv timeout : 402 minimumLength=5 respIndex=0
2019-06-19 20:13:27.175 [WARN ] [rtmodbus.handler.ModbusSerialHandler] - Recv timeout : 403 minimumLength=5 respIndex=0
2019-06-19 20:13:28.370 [INFO ] [rtmodbus.handler.ModbusSerialHandler] - Connected to serial port /dev/ttyUSB0
2019-06-19 20:13:28.371 [INFO ] [rtmodbus.handler.ModbusSerialHandler] - Trying to connect to serial port /dev/ttyUSB0
2019-06-19 20:13:30.372 [INFO ] [rtmodbus.handler.ModbusSerialHandler] - Connected to serial port /dev/ttyUSB0
2019-06-19 20:13:30.373 [INFO ] [rtmodbus.handler.ModbusSerialHandler] - Trying to connect to serial port /dev/ttyUSB0
2019-06-19 20:13:32.375 [INFO ] [rtmodbus.handler.ModbusSerialHandler] - Connected to serial port /dev/ttyUSB0
2019-06-19 20:13:32.377 [INFO ] [rtmodbus.handler.ModbusSerialHandler] - Trying to connect to serial port /dev/ttyUSB0
2019-06-19 20:13:32.779 [WARN ] [rtmodbus.handler.ModbusSerialHandler] - Recv timeout : 401 minimumLength=5 respIndex=0
2019-06-19 20:13:33.386 [WARN ] [rtmodbus.handler.ModbusSerialHandler] - Recv timeout : 403 minimumLength=5 respIndex=0
2019-06-19 20:13:34.003 [WARN ] [rtmodbus.handler.ModbusSerialHandler] - Recv timeout : 405 minimumLength=5 respIndex=0
2019-06-19 20:13:34.379 [INFO ] [rtmodbus.handler.ModbusSerialHandler] - Connected to serial port /dev/ttyUSB0
2019-06-19 20:13:34.379 [INFO ] [rtmodbus.handler.ModbusSerialHandler] - Trying to connect to serial port /dev/ttyUSB0
2019-06-19 20:13:34.610 [WARN ] [rtmodbus.handler.ModbusSerialHandler] - Recv timeout : 404 minimumLength=5 respIndex=0
2019-06-19 20:13:36.382 [INFO ] [rtmodbus.handler.ModbusSerialHandler] - Connected to serial port /dev/ttyUSB0
2019-06-19 20:13:36.383 [INFO ] [rtmodbus.handler.ModbusSerialHandler] - Trying to connect to serial port /dev/ttyUSB0
2019-06-19 20:13:38.384 [INFO ] [rtmodbus.handler.ModbusSerialHandler] - Connected to serial port /dev/ttyUSB0
2019-06-19 20:13:38.385 [INFO ] [rtmodbus.handler.ModbusSerialHandler] - Trying to connect to serial port /dev/ttyUSB0
2019-06-19 20:13:40.214 [WARN ] [rtmodbus.handler.ModbusSerialHandler] - Recv timeout : 401 minimumLength=5 respIndex=0
2019-06-19 20:13:40.386 [INFO ] [rtmodbus.handler.ModbusSerialHandler] - Connected to serial port /dev/ttyUSB0
2019-06-19 20:13:40.388 [INFO ] [rtmodbus.handler.ModbusSerialHandler] - Trying to connect to serial port /dev/ttyUSB0
2019-06-19 20:13:40.822 [WARN ] [rtmodbus.handler.ModbusSerialHandler] - Recv timeout : 404 minimumLength=5 respIndex=0
2019-06-19 20:13:41.427 [WARN ] [rtmodbus.handler.ModbusSerialHandler] - Recv timeout : 402 minimumLength=5 respIndex=0
2019-06-19 20:13:42.033 [WARN ] [rtmodbus.handler.ModbusSerialHandler] - Recv timeout : 403 minimumLength=5 respIndex=0
2019-06-19 20:13:42.390 [INFO ] [rtmodbus.handler.ModbusSerialHandler] - Connected to serial port /dev/ttyUSB0

Could it be because I only wire the pin 0 (instead of pin 0+1) to GND? And I don’t quite understand why I can connect to slave2 but not slave1, and why it doesn’t detect the thermostats in the rooms :frowning:
Any suggestion?

Hi @somy,

The binding defaults to Nilan for all - @spiff42 I think discussed this a bit earlier in the thread but basically just switch over to wavin as you have done and it should work. The slave 1 or 2 is I think a bit dependent on the config of the wavin but most cases it would be 1. From the log I don’t think you are connected in a stable mode - I see a lot of re-connects.

Please check your wiring one more time!
I have about 20 m CAT5E cable from my wavin to the USB stick and don’t use termination resistor. Yet if everything else fails you can try that - connect pins 4 and 5 of the RS485 with 120 ohm resistor. But this is should be the last thing you try.

Before that :

  • make.sure you have downloaded the latest binding by @zmartify. He posted several links!
    • try switching over to the other RJ45 port on the wavin
  • short the GND pins at the RS485

I cannot check this now but I have this wierd feeling that the binding always sees slave 1/2 even if you unplug everything. So ultimately this can be a wrong ttyUSB config to the docker.

Good luck!

Oh yes the timeouts in the log we all see so ignore those. Whatever those are they are not causing your issue.

That does not make much sense. According to chapter 2 of Wavin Modbus beskrivelse for AHC 9000 styreenhed_14082013.pdf:
“Every control unit responds at address 0x01 regardless of its assigned logical address for compatibility reasons. Besides that, a unit can be assigned to a specific logical address to which the unit responds as well, so that the assigned logical address should be always higher than 0x01.”
In other words, if you have only one device connected on the modbus, you can use address 1 (this is what I am using).

Edit: Either use a 120 ohm resistor connected to pins 4 and 5 (along with the green/white and green wires, respectively).

Or alternatively (easier) connect pins 1 and 2 (with a wire). The 120 ohm resistor is on the circuit board, and gets connected in this way. I have been running with this setup.

Hi, I now switch to another rj45 port and looked a little further into it.
@katerica, I think you’re right, once the controller is configured slave1/slave2 will show online even though it’s not connected.
When I configure Wavin On with address 1, the modbus controller state is online_bridge-offline, and I see a lot of reconnects in the log file:

2019-06-20 05:43:24.725 [INFO ] [rtmodbus.handler.ModbusSerialHandler] - Trying to connect to serial port /dev/ttyUSB0
2019-06-20 05:43:24.727 [INFO ] [rtmodbus.handler.ModbusSerialHandler] - Connected to serial port /dev/ttyUSB0
2019-06-20 05:43:24.728 [INFO ] [rtmodbus.handler.ModbusSerialHandler] - Trying to connect to serial port /dev/ttyUSB0
2019-06-20 05:43:24.730 [INFO ] [rtmodbus.handler.ModbusSerialHandler] - Connected to serial port /dev/ttyUSB0
2019-06-20 05:43:29.731 [INFO ] [rtmodbus.handler.ModbusSerialHandler] - Trying to connect to serial port /dev/ttyUSB0
2019-06-20 05:43:29.732 [INFO ] [rtmodbus.handler.ModbusSerialHandler] - Connected to serial port /dev/ttyUSB0
2019-06-20 05:43:29.733 [INFO ] [rtmodbus.handler.ModbusSerialHandler] - Trying to connect to serial port /dev/ttyUSB0
2019-06-20 05:43:29.735 [INFO ] [rtmodbus.handler.ModbusSerialHandler] - Connected to serial port /dev/ttyUSB0
2019-06-20 05:43:29.736 [INFO ] [rtmodbus.handler.ModbusSerialHandler] - Trying to connect to serial port /dev/ttyUSB0
2019-06-20 05:43:29.737 [INFO ] [rtmodbus.handler.ModbusSerialHandler] - Connected to serial port /dev/ttyUSB0
2019-06-20 05:43:29.738 [INFO ] [rtmodbus.handler.ModbusSerialHandler] - Trying to connect to serial port /dev/ttyUSB0
2019-06-20 05:43:29.740 [INFO ] [rtmodbus.handler.ModbusSerialHandler] - Connected to serial port /dev/ttyUSB0

Screenshot of the modbus controller:

Edit: Looks like now slave1 can also obtain a connection - I didn’t do anything except for restart the docker container a few times, strange.

If I change to use address 2, it can obtain the connection but not able to detect all the thermostats, and I see lots of timeouts in the log (which is normal I assume):

019-06-20 06:03:52.148 [INFO ] [rtmodbus.handler.ModbusSerialHandler] - Initializing Zmartify ModbusFunction Serial Controller.
2019-06-20 06:03:52.163 [INFO ] [artmodbus.handler.ZmartModbusHandler] - Initialising Network Zmartify ModbusFunction controller zmartmodbus:serialbridge:ccf34852
2019-06-20 06:03:52.177 [INFO ] [us.internal.factory.ModbusActionFeed] - LaunchPublisher
2019-06-20 06:03:52.760 [INFO ] [internal.controller.ModbusController] - Starting ModbusFunction controller 0
2019-06-20 06:03:52.772 [INFO ] [tmodbus.internal.protocol.ModbusNode] - NODE 0: Creating a new modbus node
2019-06-20 06:03:52.773 [INFO ] [tmodbus.internal.protocol.ModbusNode] - modbusFunction standard defined
2019-06-20 06:03:52.777 [INFO ] [internal.controller.ModbusController] - ModbusActionQueue
2019-06-20 06:03:52.852 [INFO ] [us.internal.factory.ModbusActionFeed] - register actionListener
2019-06-20 06:03:52.853 [INFO ] [g.zmartmodbus.internal.ModbusHandler] - register Action listener
2019-06-20 06:03:52.854 [INFO ] [odbus.internal.factory.ModbusFactory] - Factory register Action listener
2019-06-20 06:03:52.896 [INFO ] [internal.controller.ModbusController] - ModbusStateFromModbusQueue
2019-06-20 06:03:52.898 [INFO ] [g.zmartmodbus.internal.ModbusHandler] - register Message listener
2019-06-20 06:03:52.909 [INFO ] [internal.controller.ModbusController] - ModbusStateFromModbusQueue
2019-06-20 06:03:52.911 [INFO ] [odbus.internal.factory.ModbusFactory] - Factory register State listener
2019-06-20 06:03:52.915 [INFO ] [internal.controller.ModbusController] - ModbusStateToModbusQueue
2019-06-20 06:03:52.948 [INFO ] [artmodbus.handler.ModbusThingHandler] - NODE -1: Controller status changed to ONLINE.
2019-06-20 06:03:52.953 [INFO ] [artmodbus.handler.ModbusThingHandler] - initializeNode: nodeClassKey = jablotronac116
2019-06-20 06:03:52.955 [INFO ] [.zmartmodbus.ZmartModbusBindingClass] - Test: jablotronac116 = Master
2019-06-20 06:03:52.956 [INFO ] [.zmartmodbus.ZmartModbusBindingClass] - Test: jablotronac116 = Slave
2019-06-20 06:03:52.957 [INFO ] [.zmartmodbus.ZmartModbusBindingClass] - Test: jablotronac116 = JablotronActuator
2019-06-20 06:03:52.958 [INFO ] [.zmartmodbus.ZmartModbusBindingClass] - Test: jablotronac116 = JablotronTP150
2019-06-20 06:03:52.959 [INFO ] [.zmartmodbus.ZmartModbusBindingClass] - Test: jablotronac116 = JablotronAC116
2019-06-20 06:03:52.960 [INFO ] [tmodbus.internal.protocol.ModbusNode] - NODE 1: Creating a new modbus node
2019-06-20 06:03:52.985 [INFO ] [rtmodbus.handler.ModbusSerialHandler] - Trying to connect to serial port /dev/ttyUSB0
2019-06-20 06:03:53.255 [INFO ] [artmodbus.handler.ModbusThingHandler] - NODE 1: Controller status changed to ONLINE.
2019-06-20 06:03:53.260 [INFO ] [rtmodbus.handler.ModbusSerialHandler] - Connected to serial port /dev/ttyUSB0

Now some magic happened, slave1 also seems to get connection, but again no auto detection of all thermostat. Guess it shows the wiring and docker setup is correct?

2019-06-20 06:09:32.849 [INFO ] [iscovery.ModbusSlaveDiscoveryService] - Adding new ModbusFunction Thing zmartmodbus:jablotronac116:a0fdc0c0:slave1 to smarthome inbox (jablotronac116)
2019-06-20 06:09:32.866 [INFO ] [g.discovery.internal.PersistentInbox] - Added new thing 'zmartmodbus:jablotronac116:a0fdc0c0:slave1' to inbox.
2019-06-20 06:09:40.772 [INFO ] [artmodbus.handler.ModbusThingHandler] - initializeNode: nodeClassKey = jablotronac116
2019-06-20 06:09:40.773 [INFO ] [.zmartmodbus.ZmartModbusBindingClass] - Test: jablotronac116 = Master
2019-06-20 06:09:40.774 [INFO ] [.zmartmodbus.ZmartModbusBindingClass] - Test: jablotronac116 = Slave
2019-06-20 06:09:40.775 [INFO ] [.zmartmodbus.ZmartModbusBindingClass] - Test: jablotronac116 = JablotronActuator
2019-06-20 06:09:40.776 [INFO ] [.zmartmodbus.ZmartModbusBindingClass] - Test: jablotronac116 = JablotronTP150
2019-06-20 06:09:40.776 [INFO ] [.zmartmodbus.ZmartModbusBindingClass] - Test: jablotronac116 = JablotronAC116
2019-06-20 06:09:40.778 [INFO ] [tmodbus.internal.protocol.ModbusNode] - NODE 1: Creating a new modbus node
2019-06-20 06:09:40.779 [INFO ] [rtmodbus.handler.ModbusSerialHandler] - Trying to connect to serial port /dev/ttyUSB0
2019-06-20 06:09:40.794 [INFO ] [artmodbus.handler.ModbusThingHandler] - NODE 1: Controller status changed to ONLINE.
2019-06-20 06:09:40.803 [INFO ] [rtmodbus.handler.ModbusSerialHandler] - Connected to serial port /dev/ttyUSB0
2019-06-20 06:09:41.407 [WARN ] [rtmodbus.handler.ModbusSerialHandler] - Recv timeout : 401 minimumLength=5 respIndex=0
2019-06-20 06:09:45.029 [WARN ] [rtmodbus.handler.ModbusSerialHandler] - Recv timeout : 402 minimumLength=5 respIndex=0
2019-06-20 06:09:57.649 [WARN ] [rtmodbus.handler.ModbusSerialHandler] - Recv timeout : 403 minimumLength=5 respIndex=0
2019-06-20 06:10:04.062 [WARN ] [rtmodbus.handler.ModbusSerialHandler] - Recv timeout : 401 minimumLength=5 respIndex=0
2019-06-20 06:10:41.577 [WARN ] [rtmodbus.handler.ModbusSerialHandler] - Recv timeout : 403 minimumLength=5 respIndex=0```


PS: Strangely the NAS detect the RS485 USB dongle as UPS device and it keeps triggering shutdown of the system.

Hi @spiff42,
We have the same RS485 adapter, when you say connect pin 4 and 5, I assume you meant pin 1 and 2? I have done so.
Can you confirm how to wire GND? Should I wire both pin 1 and 2 from rj45 cable or one of the pins is good enough? This is the only thing I’m doing differently from @katerica.

Hi @zmartify,

Here are a few things, off the top of my head.

  1. There is a lot of Recv timeout warnings in the log:
2019-06-20 07:41:23.167 [WARN ] [rtmodbus.handler.ModbusSerialHandler] - Recv timeout : 405 minimumLength=5 respIndex=0
2019-06-20 07:41:33.863 [WARN ] [rtmodbus.handler.ModbusSerialHandler] - Recv timeout : 401 minimumLength=5 respIndex=0
2019-06-20 07:41:44.611 [WARN ] [rtmodbus.handler.ModbusSerialHandler] - Recv timeout : 401 minimumLength=5 respIndex=0
2019-06-20 07:42:18.073 [WARN ] [rtmodbus.handler.ModbusSerialHandler] - Recv timeout : 401 minimumLength=5 respIndex=0
  1. I am using mainly ManualTemp and AirTemperature, and those seem to work. However, when I tried to change ThermostatMode, it seems the connection was lost and no longer responded correctly. I would like to set HolidayTemp, StandbyTemp, PartyTemp, etc. and select which one is used with ThermostatMode. I believe the DesiredTemp should reflect the setting selected by ThermostatMode.

  2. I seem to remember some problems regarding IntLock and/or CtrlLock, being reversed. If I recall correctly, I sent you a more detailed description about this a long time ago (probably in a PM).

  3. For the items that are binary inputs (such as ThermostatActive), the correct item type in OH is a Contact, although the states OPEN and CLOSED are not very elegant. A Switch is only supposed to be used for something that OH can control/command (We had a lengthy discussion about this topic over here: Discussion about OpenHAB Item types)

What is the expected time frame of next release? If there is a chance of some quicker release cycle, I can try to do some more investigations. For instance if you could look into the ThermostatMode problem, I would be happy to beta-test. I can even rig up a second RS485 adapter listening in on the bus. But I am a little reluctant to spend a lot of time finding bugs in the currently released plugin, if release of a new plugin is months away.

Could you please elaborate on this:

Will you make the binding (binary) available, or will you release the source code (possibly trying to get it merged into the official OpenHAB bindings repository)? I ask because I am concerned that when the source is closed, we (the users of your binding with OH) risk that an upgrade of OpenHAB breaks compatibility, meaning that we no longer have Wavin support (or alternatively forcing us to either keep running an old OH and not have support for newer developments)

I would like to help out improving the binding. I am a software developer (mainly C on embedded systems, and Linux), so I am confident I can read/review code, although it’s been a long time since I coded in Java. I have substantial experience with low-level communication and various serial protocols, such as modbus.

Yes, looking at your picture, the pins are 1 and 2. I will edit my post, so others don’t misunderstand.

I can understand why you put the red labels A-E on the picture, to make it more explicit, but it can get a little confusing because because the RS485 signals on pins 4 and 5 are also called A and B. Since I had not originally noticed your red labels on the picture, I thought you suggested short-circuiting those :slight_smile:

My best guess is that they are both connected at the AHC9000 end. Probably on the display one is used for RS485 signal ground and the other one is used for the 24V supply. However, in this case (where we are not using the 24V supply), connecting both orange and orange/white wires to GND terminal 3 on the RS485 adapter seems the easiest (and I think that is what I have done).

Remember to check that your RJ45 connector uses T-568B coloring scheme, and not T-568A, otherwise the orange and green pairs are swapped. But I guess in that case you would not get any connection at all.

I think your hardware setup is fine. My guess is that your problems are related to:

Apparently something else (e.g. a different service on your NAS) is connecting to the USB device, and possibly interfering with the communication.

Hi Mikkel,
To answer your last question first - open source and try to get it merged into the official OpenHAB binding repository. Will appreciate any help going forward. First step is to get the updated release fully functional - which I hope to do during next week. Thereafter I will invite you and maybe others to take it further. It’s freetime project so timetable? - but hopefully we can a beta-release available for general testing within a few weeks. Will get back to you.
Best regards,
Peter Kristensen

That’s great news, thank you very much for the effort!
I’m a Java developer so let me know if anything I can help - I still haven’t managed to get the system running though, will try to make the current binding work. For some reason it can connect to the controller but can’t find the thermostats.

Hi Peter,

It’s great news you plan to make it available! I am also volunteering to help.

I think integrating into OH is a bit trickier than it seems and does not provide for a straight forward way for bug fixes. But an open GitHub repo with regular bug fixing releases is more than enough. There are many great binding using this model.

Cheers

Good point about an open GitHub repo - let that be the starting target and we will take it from there.