No, I believe Wavin uses custom function codes, so I cannot be used with the Modbus binding, which is why @zmartify’s binding is needed 
I was thrown off by the examplecodes noted on the GitHub - zmartify/org.openhab.binding.zmartmodbus: Zmartify Modbus binding for OpenHAB 2
Ok so i tried changing to this:
Bridge zmartmodbus:serialbrigde:controller[ port="/dev/ttyUSB0", id=2, baud=38400, stopBits=“1.0”, parity=“none”, dataBits=8, encoding=“rtu”] {
which led to this responce in Frontail
2021-03-27 09:49:12.993 [INFO ] [el.core.internal.ModelRepositoryImpl] - Loading model ‘AHC9000.things’
Which i guess is good news… But how do then see or identify the individual things in the AHC 9000 system? I cant see any binding activated in the GUI nor things popping up… Sorry if i’m asking stupid questions but i dont quite understand the setup here???
BR
M Klitgaard
Sorry for asking all these questions but I have a feeling of beeing on the right track but still having something wrong, and i have read this complete thread several times without getting wiser
I have also tried to look at the Code at github but i’m not a SW engineer so its not easy…
Could someone please help me with a few comments on the following:
-
In my things file i have:
Bridge zmartmodbus:serialbrigde:controller[ port="/dev/ttyUSB0", id=2, baud=38400, stopBits=“1.0”, parity=“none”, dataBits=8, encoding=“rtu”] {
Bridge poller coils [ start=4, length=2, refresh=1000, type=“coil” ] {
// Note the zero based indexing: first coil is index 0.
Thing data do4 [ readStart=“4”, readValueType=“bit”, writeStart=“4”, writeValueType=“bit”, writeType=“coil” ]
Thing data do5 [ readStart=“5”, readValueType=“bit”, writeStart=“5”, writeValueType=“bit”, writeType=“coil” ]
}
}
Is this correct (assuming USB - RS485 converter is on /dev/ttyUSB0)? -
In my items file i have: Switch ReadDI4WriteDO5 “Coil 4/5 mix [%d]” { channel=“zmartmodbus:data:serialbrigde:controller:items:readDiscrete4WriteCoil5:switch” }
Is this correct?
It just seems odd to me that readDiscrete4WriteCoil5 is not mentioned in the Thing file but rather do5 is
Gennerally i’m trying to use the examples written on github: GitHub - zmartify/org.openhab.binding.zmartmodbus: Zmartify Modbus binding for OpenHAB 2
But they do not mention zmartify
Help is much apprecited as i’m somewhat confused about the whole thing
BR
M Klitgaard
OK, sorry if I added a lot of confusion here. I have only used Zmartify’s OH2 binding, with the Things configured using the GUI interface, and a manually added Items-file. From the readme on the Github it appears that is totally changed with OH3.
Hi, I can report Peter’s binding works for me (almost) with OH3, the setup isn’t as straightforward as OH2 though, mainly due to the new UI with OH3. Basically below is what I did:
- Install the binding by copying the files to addon folder
- Manually add the ModBus Serial Controller bridge
- Then add Wavin AHC 9000 and set the bridge in step 2)
- Scan for the thermostats, you should now have a list of them in inbox (Wavin TP-150 Channel XX Element XX)
I do encounter some issue setting the temperature through OpenHAB though, reading is no problem and works 100%, but I couldn’t seem to get writing work reliably, sometimes it works but most of the time it reverts back to the original setting. In log I can see the following which indicates OH3 tries to set the temperature, but for some reason the register isn’t changed and it revert back to the old value after some seconds. Any suggestion?
2021-04-10 20:04:08.041 [INFO ] [openhab.event.ItemCommandEvent ] - Item ‘WavinOfficeTargetTemp’ received command 21.5
2021-04-10 20:04:08.043 [INFO ] [penhab.event.ItemStatePredictedEvent] - Item ‘WavinOfficeTargetTemp’ predicted to become 21.5
2021-04-10 20:04:08.046 [INFO ] [openhab.event.ItemStateChangedEvent ] - Item ‘WavinOfficeTargetTemp’ changed from 21.0 to 21.5
2021-04-10 20:04:16.224 [INFO ] [openhab.event.ItemStateChangedEvent ] - Item ‘WavinOfficeTargetTemp’ changed from 21.5 to 21.0
Hi Somy
Thanks for your reply which made me try once again with OpenHAB3… Here is what i did while trying to follow you instructions…
-
Fresh install of Raspberry pi and OH3 (with no other binding installed than what is explained beneath)
-
Install the binding by copying the files to addon folder
- Copy the following files to RPI-IP-Addr\openHAB-addons folder
a. org.openhab.binding.zmartmodbus-3.1.0-SNAPSHOT.jar
b. reactive-streams-1.0.3.jar
c. rxjava-2.2.20.jar
- Copy the following files to RPI-IP-Addr\openHAB-addons folder
-
Reboot OpenHAB/Raspberry Pi
-
Enter the OpenHAB Webpage interface (IP-Addr:8080)
Login as Admin -
Manually add the ModBus Serial Controller bridge by:
a. Install ModBus binding 3.0.1 -
Add Things Zmartify Modbus Binding version 2.x by:
a. Press Things (in left menu) → + Sign (in lower left corner)
b. Chose Zmartify Modbus Binding version 2.x → select Modbus Serial Controller (Brigde)
c. Setup info
Serial Port = /dev/ttyUSB0
Id. = 1
Baud = 38400
Stopbits = 1
Parity = None
Databits = 8
Encoding = RTU
Discovery enables = Yes
Flow Control In = None
Flow Control Out = None
Time btw transactions = 35 ms
Transmission Mode = RTU
d. Press “Create Thing”
e. Modbus Serial Controller indicates a green “ONLINE” (so far so good) -
Then add Wavin AHC 9000 thing by:
a. Press Things (in left menu) → + Sign (in lower left corner)
b. Chose Zmartify Modbus Binding version 2.x → select Wavin AHC 9000
c. Set the bridge to Modbus Serial Controller
d. AC-116 Unit Address = 1
e. Discovery Enabled
f. Press “Create Thing”
g. Wavin AHC 9000 indicates a green “ONLINE” (so far so good) -
Scan for the thermostats, you should now have a list of them in inbox (Wavin TP-150 Channel XX Element XX)
a. Now this is here where the “chain starts to fall off”… as i Do not see the Thermostats nor the picture added by you on the 24 marts as a reply to Zmartify Peter Kristensens link to Github
b. As you can see on the attached picture i cannot see same as you. I hope you or someone else can guide me in the last steps or explain to me why I see a diffirent “picture”?
Thanks in Advance
M Klitgaard
Hi Morten,
Do you get the device info channel populated with data - this needs to be and will ensure that there is a connection with the AHC-9000. Without connection to the AHC-9000 you will not be able to locate the thermostats
Best regards,
Peter
Hi, glad I can help.
0. Manually add the ModBus Serial Controller bridge by:
a. Install ModBus binding 3.0.1
I don’t think you need to install ModBus binding, I installed it for my Nilan system but I believe it’s not needed for wavin.
Add Things Zmartify Modbus Binding version 2.x by
Mine doesn’t see version 2.x, where do you see it?
Can you show me where did you press the scan button? Just want to be sure you’re at the right plan.
I think you need to give it some time to sync before you can scan for the thermostat. Also please make sure under Wavin AHC 9000 thing enable “discover enabled”.
Anyways I think you’re very close to make it work. I’m still fighting with writing to the theromostats, sometimes it works other times it doesn’t. I suspect it has something to do with the settings, once you make it work let us know how does it work for you 
Hi Peter, thanks for the binding! I think I managed to get it work except that I have some issue when setting the temperature, it sometimes works sometime doesn’t. Below are the two examples which might tell you what could be the cause:
Example 1
I changed the setting from 22 to 23:
2021-04-15 07:10:51.729 [INFO ] [openhab.event.ItemCommandEvent ] - Item ‘WavinOfficeTargetTemp’ received command 23
2021-04-15 07:10:51.731 [INFO ] [penhab.event.ItemStatePredictedEvent] - Item ‘WavinOfficeTargetTemp’ predicted to become 23
2021-04-15 07:10:51.741 [INFO ] [openhab.event.ItemStateChangedEvent ] - Item ‘WavinOfficeTargetTemp’ changed from 22.0 to 23
After some seconds it reverted back to 22:
2021-04-15 07:11:05.114 [INFO ] [openhab.event.ItemStateChangedEvent ] - Item ‘WavinOfficeTargetTemp’ changed from 23 to 22.0
After another 30 seconds it reported back 23 (the correct value I set):
2021-04-15 07:12:35.864 [INFO ] [openhab.event.ItemStateChangedEvent ] - Item ‘WavinOfficeTargetTemp’ changed from 22.0 to 23.0
Heating started as the room temperature is 22.5:
2021-04-15 07:12:35.956 [INFO ] [openhab.event.ItemStateChangedEvent ] - Item ‘WavinOfficeActive’ changed from OFF to ON
In this example the change did happen, but there is a huge delay and initially after setting the temperature it revered back to 22 for 30 seconds.
Example 2
I changed from 23 to 21.5:
2021-04-15 07:17:45.707 [INFO ] [openhab.event.ItemCommandEvent ] - Item ‘WavinOfficeTargetTemp’ received command 21.5
2021-04-15 07:17:45.755 [INFO ] [penhab.event.ItemStatePredictedEvent] - Item ‘WavinOfficeTargetTemp’ predicted to become 21.5
2021-04-15 07:17:45.757 [INFO ] [openhab.event.ItemStateChangedEvent ] - Item ‘WavinOfficeTargetTemp’ changed from 23.0 to 21.5
2021-04-15 07:18:44.813 [INFO ] [openhab.event.ItemStateChangedEvent ] - Item ‘WavinOfficeCurrentTemp’ changed from 22.4 to 22.3
This time it didn’t flip back to 23 but the change also took around 30 seconds:
2021-04-15 07:19:13.137 [INFO ] [openhab.event.ItemStateChangedEvent ] - Item ‘WavinOfficeActive’ changed from ON to OFF
I think it has something to do with the interval settings in the configuration, and the delays seems to correspond to slow polling interval (I set to 30 seconds). I have tried to time how long it takes between when I change in OH and when it pops up in Thermostat, and it is around 30 seconds. So it looks to me like the binding wait for 30 seconds before writing to the register, and during the 30 seconds waiting window, it also polls the current value from the register, and hence it can revert back to the old value before the change is made. I can’t explain why in Example 2 the polling didn’t kick in though.
I’d also very much appreciate if you could help me to understand Fast polling interval and Time between updating OpenHAB counters (seconds). What are those settings used for?
I’m using Wavin with wired Thermostat and therefore the delay should be minimal. Appreciate if you could suggest a proper setting for wired Thermostats? I guess what I’m aiming at is when the change is made, it get written to the register asap, and the polling can be shortened to 5-10 seconds if possible.
Thank you very much for the effort and appreciate your help in advance!
Hi Peter
Thanks for you help and support it is much appreciated
Yes i should beleive so… I can read out the Model /HW ver. /SW Ver. / SN out of it
Please see attached picture
Is this what you where asking for?
Br
M Klitgaard
Hi Somy Mai
Thanks for you help and support it is much appreciated
You asked
Add Things Zmartify Modbus Binding version 2.x by
Mine doesn’t see version 2.x, where do you see it?
In the web interface under the menu:
http://Host-IP:8080/#!/settings/things/add
Please see picture
I did wait a long time (several hours) to see if anything is popping up
I tried to connect to RPI to the AHC 9000 both via the RS485 interface in the side for wired temperature sensors and in the bottom for displays (see attached pictures)
Both provides a connection that provides the device info as Peter is asking for
I have also attached the picture os my RS485 Interface to the RPI
Please note that on the picture with the RS485 interface it seems like the TX is constantly on… This in NOT the case but rather the Power LED that is visible through the TX LED indicator window.
Please also note that I can see that the USB to RS485 device is both transmitting and receiving some data… with an interval of approximately 10 seconds interval
BR
M Klitgaard
Hi All
To add to the above i get the following message every approximately 30 seconds:
2021-04-21 08:52:31.353 [ERROR] [odbus.internal.factory.ModbusHandler] - Response TimeOut: Recv timeout 10030 : minLength=5 respIndex=0 #11109 cmd=0143001C00020402
Sometimes a longe interval of several minutes is occurring but most often every 30 seconds
Hi All
I’m About to thow the towel on this solution but i really would like to have it working…
Could i ask you to describe the interface solution you have used i.e.:
- Which Device do you use to capture the RS485/modbus signal and send it to OpenHAB?
- Is it a RS485 to USB solution and if yes which Device/Model are you using?
- Or are you using a RS485 to Ethernet /MQTT Gateway?
Looking forward to hear from you
Br
M Klitgaard
/M Klitgaard
The org.openhab.binding.zmartmodbus-3.1.0-SNAPSHOT.jar (post 174)
- works for me on OH3.0.2
- but on 3.1.0 (M4) it doesnt:
2021-05-11 21:42:38.453 [WARN ] [org.apache.felix.fileinstall ] - Error while starting bundle: file:/usr/share/openhab/addons/org.openhab.binding.zmartmodbus-3.1.0-SNAPSHOT.jar
org.osgi.framework.BundleException: Could not resolve module: org.openhab.binding.zmartmodbus [303]
Unresolved requirement: Import-Package: org.apache.commons.io; version="[2.2.0,3.0.0)"
at org.eclipse.osgi.container.Module.start(Module.java:463) ~[org.eclipse.osgi-3.16.200.jar:?]
at org.eclipse.osgi.internal.framework.EquinoxBundle.start(EquinoxBundle.java:440) ~[org.eclipse.osgi-3.16.200.jar:?]
at org.apache.felix.fileinstall.internal.DirectoryWatcher.startBundle(DirectoryWatcher.java:1260) [bundleFile:3.6.8]
at org.apache.felix.fileinstall.internal.DirectoryWatcher.startBundles(DirectoryWatcher.java:1233) [bundleFile:3.6.8]
at org.apache.felix.fileinstall.internal.DirectoryWatcher.doProcess(DirectoryWatcher.java:520) [bundleFile:3.6.8]
at org.apache.felix.fileinstall.internal.DirectoryWatcher.process(DirectoryWatcher.java:365) [bundleFile:3.6.8]
at org.apache.felix.fileinstall.internal.DirectoryWatcher.run(DirectoryWatcher.java:316) [bundleFile:3.6.8]
2021-05-11 21:42:38.468 [INFO ] [org.apache.felix.fileinstall ] - Started bundle: file:/usr/share/openhab/addons/rxjava-2.2.20.jar
2021-05-11 21:42:38.474 [INFO ] [org.apache.felix.fileinstall ] - Started bundle: file:/usr/share/openhab/addons/reactive-streams-1.0.3.jar
Can you make a fix, for the requirement?
/peter
Hi All readers of this thread
As mentioned I had a lot of trouble getting this Modbus up and running with OH3 (did not try OH2 as it is no longer beeing developed on)
I have “throwned in the towel” on this methos and have tried another method via MQTT which I have gotten to work
A LOT of credit goes to the great work done by DKJonas as he made a code and a schematic for a ESP8266 interfacing through the Modbus: GitHub - dkjonas/Wavin-AHC-9000-mqtt: Esp8266 mqtt interface for Wavin AHC-9000/Jablotron AC-116
The Setup DKJonas made is designed for Home Assistant but is usable for OpenHab 3 also
I did struggle a lot with the trying to set it up via the new GUI interface in OpenHAB 3 which i’m to be honest is NOT a friend of so i ended up in using text based setup of the brigde, Things, items and Sitemap and rules
I Think i Will try to make a seperate topic on how to set this up in order not to make to much noise in here
Br
MKlitgaard
1 Like
Hi Morten, just saw your post and great you managed to make it work after all!
I only use openhab for my Nilan and Wavin devices, and I wish one day I can move to HA which seems to be more actively developed these days.
Good for you if you know how to assemble the HW, I saw that project before but couldn’t really find out how to make the hardware 
Nice work and hope you enjoyed the setup!
Just saw your post, also considering to upgrade, have you managed to solve the issue? Thanks
yes and no.
Though quite a bit over my head, i tried modifying Peters binding, to include missing jar’s.
Lot of trial&error, pretty dirty - but i managed out of pure luck to make it work in 3.1.M4
… but my workaround dont work in 3.1.0.stable
So for now, i will stay on M4, and wait for an update from Peter …
OK, thanks! I think I will stay with current version.
Do you experience delays when you set the temperature? Looks to me like sometime it works and sometimes doesn’t.
Really hope somebody can pick up the source code and fix those glitches, I don’t have the skills unfortunately.
Its a pity! I really wish that somebody with good Java skills could pick up Peter’s work and make it compatible with future releases of OH3 if Peter won’t have time himself.
BTW, just tried to upgrade to 3.1.0 and received the following error:
2021-08-08 15:27:39.606 [WARN ] [org.apache.felix.fileinstall ] - Error while starting bundle: file:/openhab/addons/org.openhab.binding.zmartmodbus-3.1.0-SNAPSHOT.jar
org.osgi.framework.BundleException: Could not resolve module: org.openhab.binding.zmartmodbus [236]
Unresolved requirement: Import-Package: org.openhab.core.io.transport.serial
at org.eclipse.osgi.container.Module.start(Module.java:463) ~[org.eclipse.osgi-3.16.200.jar:?]
at org.eclipse.osgi.internal.framework.EquinoxBundle.start(EquinoxBundle.java:440) ~[org.eclipse.osgi-3.16.200.jar:?]
at org.apache.felix.fileinstall.internal.DirectoryWatcher.startBundle(DirectoryWatcher.java:1260) [bundleFile:3.6.8]
at org.apache.felix.fileinstall.internal.DirectoryWatcher.startBundles(DirectoryWatcher.java:1233) [bundleFile:3.6.8]
at org.apache.felix.fileinstall.internal.DirectoryWatcher.doProcess(DirectoryWatcher.java:520) [bundleFile:3.6.8]
at org.apache.felix.fileinstall.internal.DirectoryWatcher.process(DirectoryWatcher.java:365) [bundleFile:3.6.8]
at org.apache.felix.fileinstall.internal.DirectoryWatcher.run(DirectoryWatcher.java:316) [bundleFile:3.6.8]
Are you seeing the same?
@zmartify, we’d very much appreciate if you could provide a jar that works with 3.1.0…
Hi guys,
Long time no show from my side and i see we are still in need of this binding and zmartify is still helping build and maintain it.
I finally transitioned to OH3.1.0 and tried to run this. I did not even try with the jar in zmartify’s repo as many of you reported that it does not work for OH 3.1.0. Instead i tried to rebuild it for OH3.1.0 and i believe i have succeeded.
See if it works for you: GitHub - b-r-y/org.openhab.binding.zmartmodbus: Zmartify Modbus binding for OpenHAB 2
It’s a fork from zmartify’s repo with some adjustment to make it build in OH3.1.0. I am no Java expert so my “fix” is probably not a correct one but it builds and it also works on my Synology DSM7 as a docker (only basic validation for now).
The instructions are as zmartify has said - get the zip, unzip in the addons folder and manually add the serial Modbus + Wavin bridge. After that the thermostats were discovered automatically for me.
I myself have not validated it fully - just got some basic temperature reads and i could control the thermostats. Don’t know if the rest will work. Let’s see.
In the forked repo i have only updated the zip. I build from another place. If there is interest i can put in the code changes but at this point i have no intention to maintain this fork - just a way to post the zip file here.
Let me know if it works for you.