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.
- 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
-
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.
-
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).
-
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 
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.
You’re right - I found another process upc_yec claims the ttyUSB0 device, after I kill the process it finds all my Thermostats (with a little delay). @spiff42 and @katerica, thank you both for guide me through!
I have two more questions:
- I need to map the device in HomeBridge Thermostat and for that purpose I need to know if the room is being heated. I found two channels “Thermostat Active” and “Magnetic Active” both are turned on when the target temp is set higher than air temp. What are the differences between them?
- After I have the setup running, one of my thermostat cannot display the current air temperature anymore. Not sure if it’s some sort of interference, but all all other thermostat seems to work well. I’d like to try to restart the Wavin system, would it be a problem to unplug/plug the power supply of the controller? Does anyone know a better way?
You are welcome, glad you made it work
Use the ThermostatActive, that is what I used for the bottom of the graph:
I don’t know about the MagneticActive.
Is it the LCD on the thermostat (wall-unit) that does not show the temperature? Or does it not show in OH? Is your setup with wired or wireless thermostats? I have only wired thermostats, so I don’t know about looking at the signal strength or battery level.
What happens if you try to change the temperature on the thermostat? That will usually trigger an update in OH within a couple of seconds.
Coming back to your question; Unplugging and plugging the power to the AHC9000 should be OK. I’m not entirely sure how well the OH plugin handles this communication loss. Maybe you need to restart OH afterwards.
Hi @somy,
I have only wireless thermostats and the update from OH is sometimes slow. I think this is intentional to save battery power but it does go through eventually - it can take up to 10-15 min to update. In any case floor heating is slow in general so i see no issue.
Rebooting the waving is fine and OH simply reconnects in my case. In fact it kind-a forces an update of all values.
I agree to the rest of what @spiff42 says. I don’t see how OH can interfere with your wired thermostat display - it must be something else…
cheers
btw a general question:
The binding supports all kinds of controls/status displays of the actuators. Has anyone found useful application of those? I don’t quite see what those are for…
@zmartify: I am fully on board with the comment from @spiff42 on the contact vs switch - i find it very confusing that i have a switch on my thermostat active. In the new binding we should change statuses to contacts.
Hi, just to report back, the issue with the thermostat has been resolved by resetting the thermostat. For wired thermostat the change seems to take effect quick fast - when I set the temperature from HomeKit the thermostat shows the new temperature almost instantly.
This UPS issue still bothers me, QNAP thinks the USB device is UPS and launch the process UPS_YEC, I haven’t found a way to kill the process automatially when NAS is restarted, it’s not related to OH so will look else where. Maybe it’s the time to get RPI 4B 
@spiff42: the grafana dashboard looks quick nice, are you willing to share the configure?
Hi @zmartify ,
I just wanted to say that in preparation for beta testing a new version of the plugin I have created a setup that allows me to inspect communication between OH and the AHC9000. It uses a second RS485 dongle, listening only, and with a python script dumping the raw hex data to a file. After this, I feed it into a Perl-script that parses the read and write commands.
For anyone interested in what i looks like, here is an example:
https://raw.githubusercontent.com/spiff42/wavin-python/master/openhab-parsed.txt
I will try to use this new tool to look into the problem regarding changing thermostat mode, which causes communication to stop working.
Hope to hear from you soon.
If I can find the time, I will try to make it as a short tutorial, as a separate post
Hi @zmartify,
Has there been any progress regarding the OH binding?
Most of us have probably not spent too much time thinking about heating for the past months, and I totally understand that such a project is low priority.
But this is a gentle nudge , hoping that I and others can soon start helping out getting the binding working even better.
As we are getting closer to the heating season, I guess at least I will be more motivated to work on the project 
Sorry I forgot all about that. I will try to dig out the information.
Best regards,
Mikkel Holm Olsen
Hi Spiff42,
Trying to get your python scripts to work from github.
The serdump.py script is working fine for seeing the messaging between the screen and the unit, however I get the following which to me seems to suggest that the _embedPayload method is not present which I don’t understand.
pi@raspberrypi:~/wavin-python $ python Python 2.7.13 (default, Sep 26 2018, 18:42:22) [GCC 6.3.0 20170516] on linux2 Type "help", "copyright", "credits" or "license" for more information. >>> from wavin_modbus import * File "<stdin>", line 1 from wavin_modbus import * ^ IndentationError: unexpected indent >>> from wavin_modbus import * >>> wa = WavinAHC9000('/dev/ttyUSB0',1) >>> wa.readRegisterFromIndex(5, 0, 0, 7) Traceback (most recent call last): File "<stdin>", line 1, in <module> File "wavin_modbus.py", line 39, in readRegisterFromIndex request = minimalmodbus._embedPayload(self.address, self.mode, functioncode, payload) AttributeError: 'module' object has no attribute '_embedPayload'
Can you suggest where I’m going wrong?