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

spiff42 · June 21, 2019, 7:45am

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.

katerica · June 21, 2019, 8:54am

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

katerica · June 21, 2019, 8:58am

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.

spiff42 · June 21, 2019, 9:08am

I think @zmartify simply exposed all the data available through the Wavin modbus protocol.

somy · June 25, 2019, 10:46am

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?

spiff42 · June 26, 2019, 2:54pm

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

spiff42 · September 3, 2019, 6:53am

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

@somy:

Sorry I forgot all about that. I will try to dig out the information.

Best regards,
Mikkel Holm Olsen

Sthomas · September 8, 2019, 6:25pm

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?

zmartify · September 8, 2019, 10:23pm

Hi guys, time is flying. I ended up doing a lot re-work and finally there is 2.5.0-SNAPSHOT beta version available for testing. The next step will be to get the github open and add some documentation.

The new version is re-write - and the installation is now:
a) Add thing “ZmartModbus” select the “Modbus Serial Controller” and select the right port i.e. /dev/ttyUSB0 - all other parameters will normally do.
b) Add thing “ZmartModbus” select the “Wavin AHC-9000” and be sure to the select the bridge
c) Go to Inbox and discover the sub devices i.e. actuators and thermostats

https://1drv.ms/u/s!AjVxQMEeTLvohcJ0bN2ecTCQrqwJoQ?e=pt6rrA

Please leave a comment about how it goes.
Best regards,
Peter

spiff42 · September 9, 2019, 6:51am

I don’t remember which version of minimalmodbus I used, but that would be the first place I would look. Can you find the _embedPayload in minimalmodbus.py?

spiff42 · September 9, 2019, 6:54am

That is great news. I will give it a spin as soon as I get the chance.

Sthomas · September 9, 2019, 10:30am

Thanks for the pointer - it appears that in the version I have the functions are called
_embed_payload() and _extract_payload()
vs
_embedPayload() and _extractPayload()

Made the change in wavin_modbus.py and all working correctly.

Thanks a lot!

spiff42 · September 13, 2019, 7:53pm

Hi @zmartify,
Happy to report that I dropped the updated plugin into /usr/share/openhab2/addons and restarted OH2, and it seems to work at least to some extent (reading out temperatures).

There were quite a few messages in the log that seem like debug messages:

2019-09-13 21:32:16.515 [INFO ] [artmodbus.handler.ModbusThingHandler] - NODE -1: Controller status changed to ONLINE.
2019-09-13 21:32:16.516 [INFO ] [artmodbus.handler.ModbusThingHandler] - initializeNode: nodeClassKey = jablotrontp150
2019-09-13 21:32:16.518 [INFO ] [.zmartmodbus.ZmartModbusBindingClass] - Test: jablotrontp150 = Master
2019-09-13 21:32:16.519 [INFO ] [.zmartmodbus.ZmartModbusBindingClass] - Test: jablotrontp150 = Slave
2019-09-13 21:32:16.520 [INFO ] [.zmartmodbus.ZmartModbusBindingClass] - Test: jablotrontp150 = JablotronActuator
2019-09-13 21:32:16.520 [INFO ] [.zmartmodbus.ZmartModbusBindingClass] - Test: jablotrontp150 = JablotronTP150
2019-09-13 21:32:16.521 [INFO ] [tmodbus.internal.protocol.ModbusNode] - NODE 1: Creating a new modbus node
2019-09-13 21:32:16.521 [INFO ] [artmodbus.handler.ModbusThingHandler] - NODE -1: Controller status changed to ONLINE.
2019-09-13 21:32:16.522 [INFO ] [artmodbus.handler.ModbusThingHandler] - initializeNode: nodeClassKey = jablotrontp150
2019-09-13 21:32:16.523 [INFO ] [.zmartmodbus.ZmartModbusBindingClass] - Test: jablotrontp150 = Master
2019-09-13 21:32:16.523 [INFO ] [.zmartmodbus.ZmartModbusBindingClass] - Test: jablotrontp150 = Slave
2019-09-13 21:32:16.524 [INFO ] [.zmartmodbus.ZmartModbusBindingClass] - Test: jablotrontp150 = JablotronActuator
2019-09-13 21:32:16.525 [INFO ] [.zmartmodbus.ZmartModbusBindingClass] - Test: jablotrontp150 = JablotronTP150
2019-09-13 21:32:16.525 [INFO ] [artmodbus.handler.ModbusThingHandler] - NODE -1: Controller status changed to ONLINE.
2019-09-13 21:32:16.526 [INFO ] [artmodbus.handler.ModbusThingHandler] - NODE -1: Controller status changed to ONLINE.
2019-09-13 21:32:16.526 [INFO ] [artmodbus.handler.ModbusThingHandler] - initializeNode: nodeClassKey = jablotrontp150
2019-09-13 21:32:16.527 [INFO ] [.zmartmodbus.ZmartModbusBindingClass] - Test: jablotrontp150 = Master
2019-09-13 21:32:16.528 [INFO ] [.zmartmodbus.ZmartModbusBindingClass] - Test: jablotrontp150 = Slave
2019-09-13 21:32:16.528 [INFO ] [.zmartmodbus.ZmartModbusBindingClass] - Test: jablotrontp150 = JablotronActuator
2019-09-13 21:32:16.529 [INFO ] [.zmartmodbus.ZmartModbusBindingClass] - Test: jablotrontp150 = JablotronTP150
2019-09-13 21:32:16.529 [INFO ] [tmodbus.internal.protocol.ModbusNode] - NODE 2: Creating a new modbus node
2019-09-13 21:32:16.525 [INFO ] [artmodbus.handler.ModbusThingHandler] - NODE -1: Controller status changed to ONLINE.
2019-09-13 21:32:16.530 [INFO ] [tmodbus.internal.protocol.ModbusNode] - NODE 3: Creating a new modbus node
2019-09-13 21:32:16.531 [INFO ] [artmodbus.handler.ModbusThingHandler] - initializeNode: nodeClassKey = jablotrontp150
2019-09-13 21:32:16.532 [INFO ] [artmodbus.handler.ModbusThingHandler] - initializeNode: nodeClassKey = jablotrontp150

And then in the end some errors, although they may be caused by incompatible versions of the OH I am running (stable, 2.4.0-1) and your build:

2019-09-13 21:32:23.515 [ERROR] [org.openhab.binding.zmartmodbus     ] - FrameworkEvent ERROR - org.openhab.binding.zmartmodbus
org.osgi.framework.BundleException: Could not resolve module: org.openhab.binding.zmartmodbus [252]
  Unresolved requirement: Import-Package: com.google.gson; version="[2.8.0,3.0.0)"

        at org.eclipse.osgi.container.Module.start(Module.java:444) ~[?:?]
        at org.eclipse.osgi.container.ModuleContainer$ContainerStartLevel.incStartLevel(ModuleContainer.java:1634) ~[?:?]
        at org.eclipse.osgi.container.ModuleContainer$ContainerStartLevel.incStartLevel(ModuleContainer.java:1614) ~[?:?]
        at org.eclipse.osgi.container.ModuleContainer$ContainerStartLevel.doContainerStartLevel(ModuleContainer.java:1585) ~[?:?]
        at org.eclipse.osgi.container.ModuleContainer$ContainerStartLevel.dispatchEvent(ModuleContainer.java:1528) ~[?:?]
        at org.eclipse.osgi.container.ModuleContainer$ContainerStartLevel.dispatchEvent(ModuleContainer.java:1) ~[?:?]
        at org.eclipse.osgi.framework.eventmgr.EventManager.dispatchEvent(EventManager.java:230) [?:?]
        at org.eclipse.osgi.framework.eventmgr.EventManager$EventThread.run(EventManager.java:340) [?:?]
2019-09-13 21:32:26.914 [WARN ] [rtmodbus.handler.ModbusSerialHandler] - Recv timeout : 405 minimumLength=5 respIndex=0
2019-09-13 21:32:30.093 [INFO ] [ab.binding.velux.bridge.slip.SClogin] - velux bridge connection successfully established (login succeeded).
2019-09-13 21:32:31.200 [WARN ] [org.apache.felix.fileinstall        ] - Error while starting bundle: file:/usr/share/openhab2/addons/org.openhab.binding.zmartmodbus-2.5.0-SNAPSHOT.jar
org.osgi.framework.BundleException: Could not resolve module: org.openhab.binding.zmartmodbus [252]
  Unresolved requirement: Import-Package: com.google.gson; version="[2.8.0,3.0.0)"

        at org.eclipse.osgi.container.Module.start(Module.java:444) ~[?:?]
        at org.eclipse.osgi.internal.framework.EquinoxBundle.start(EquinoxBundle.java:383) ~[?:?]
        at org.apache.felix.fileinstall.internal.DirectoryWatcher.startBundle(DirectoryWatcher.java:1260) [10:org.apache.felix.fileinstall:3.6.4]
        at org.apache.felix.fileinstall.internal.DirectoryWatcher.startBundles(DirectoryWatcher.java:1233) [10:org.apache.felix.fileinstall:3.6.4]
        at org.apache.felix.fileinstall.internal.DirectoryWatcher.startAllBundles(DirectoryWatcher.java:1221) [10:org.apache.felix.fileinstall:3.6.4]
        at org.apache.felix.fileinstall.internal.DirectoryWatcher.doProcess(DirectoryWatcher.java:515) [10:org.apache.felix.fileinstall:3.6.4]
        at org.apache.felix.fileinstall.internal.DirectoryWatcher.process(DirectoryWatcher.java:365) [10:org.apache.felix.fileinstall:3.6.4]
        at org.apache.felix.fileinstall.internal.DirectoryWatcher.run(DirectoryWatcher.java:316) [10:org.apache.felix.fileinstall:3.6.4]
2019-09-13 21:32:34.118 [INFO ] [.velux.handler.VeluxBridgeHandlerOH1] - Found velux scenes:
        Scene "Markiser åben" (index 1) with non-silent mode and 0 actions
        Scene "Markiser luk" (index 0) with non-silent mode and 0 actions       .
2019-09-13 21:32:38.181 [INFO ] [.velux.handler.VeluxBridgeHandlerOH1] - velux Bridge is online, now.
2019-09-13 21:32:43.003 [WARN ] [rtmodbus.handler.ModbusSerialHandler] - Recv timeout : 402 minimumLength=5 respIndex=0

Keep up the good work, and I hope you can create a public repo soon, so we can all pitch in.

somy · September 26, 2019, 9:35am

It’s great news, just in time before winter Thanks a lot for the effort and look forward!

somy · September 26, 2019, 9:36am

I think (based on the version) this is for OH 2.5.0. Unfortunately I have no way to test as I’m running docker with 2.4 with very limited options

AndersV · October 4, 2019, 4:24pm

Hi @zmartify

The other day i restarted opehab and now ZmartModbus fails to start with this message.

2019-10-02 21:45:09.514 [INFO ] [rtmodbus.handler.ModbusSerialHandler] - Initializing Zmartify ModbusFunction Serial Controller.
2019-10-02 21:45:09.517 [ERROR] [rtmodbus.handler.ModbusSerialHandler] - ***** ZmartModbus test version has expired…

Any chance you will realease an official version that do not expire?

Thanks…

zmartify · October 5, 2019, 7:10am

Hi Anders,

version 2.5.0-SNAPSHOT should not have any expire limitations built in.

It looks like you are using an old version.

The new version is re-write - and the installation is now:
a) Add thing “ZmartModbus” select the “Modbus Serial Controller” and select the right port i.e. /dev/ttyUSB0 - all other parameters will normally do.
b) Add thing “ZmartModbus” select the “Wavin AHC-9000” and be sure to the select the bridge
c) Go to Inbox and discover the sub devices i.e. actuators and thermostats

https://1drv.ms/u/s!AjVxQMEeTLvohcJ0bN2ecTCQrqwJoQ?e=pt6rrA

Please leave a comment about how it goes.
Best regards,
Peter

somy · October 5, 2019, 6:55pm

Hi Peter,
Thank you, it looks like I experience the same problem as @AndersV, also saw the error:
ZmartModbus test version has expired… contact peter@zmartify.dk

I’m still running OH 2.4 as docker image and have no intention to upgrade to 2.5 at the moment. Does 2.5.0-SNAPSHOT work with OH 2.4? According to @spiff42 looks like there are some issues.

Would it be possible to make a new build based on the OH 2.4 version without the time limit?
Thank you in advance!

AndersV · October 6, 2019, 11:08am

Hi Peter

Seems you were right. Even if I thought that i used the latest 2.5.0 SNAPSHOT you had posted
and what i saw in openhab.log when starting up…

But now i got alot of errors about “Unresolved requirement” etc.

Error while starting bundle: file:/usr/share/openhab2/addons/org.openhab.binding.zmartmodbus-2.5.0-SNAPSHOT.jar
org.osgi.framework.BundleException: Could not resolve module: org.openhab.binding.zmartmodbus [265]
Unresolved requirement: Import-Package: com.thoughtworks.xstream.converters; version="[1.4.0,2.0.0)"

I did not manage to get this running on OH 2.4, so I actually ended up installing Openhab 2.5M3 instead as @somy stated it was probably intended for?

Now it starts without any errors or warings and i can detect all my actuators and thermostats on the Wavin AHC 9000 controller.
But somehow it does not show the state from the actuators output if they are active or not (“Output Active” value = ON/OFF)
Actually i dont get any data or value from these at all. All the TP-150 thermostats seem to be OK

Here is an example.

The TP-150 thermostat on channel 0 is set for 23.0 degrees and airtemp is currenctly 23.4
The actuator is closed at this point.

When i go to the TP-150 thermostat and set the temp for 24.0 I see this in the event.log:

2019-10-06 10:57:17.722 [vent.ItemStateChangedEvent] - zmartmodbus_jablotron_tp150_96ef7c0a_chn0e0_ManualTemp changed from 23.0 to 24.0
2019-10-06 10:57:17.728 [vent.ItemStateChangedEvent] - zmartmodbus_jablotron_tp150_96ef7c0a_chn0e0_DesiredTemp changed from 23.0 to 24.0

Shortly after i can see “visually” the actuator opens and in the log i see this (assume that the Wavin AHC 9000 have registered that the actuator is now open)?

2019-10-06 10:58:01.478 [vent.ItemStateChangedEvent] - zmartmodbus_jablotron_ac116_ed669c50_TotalActuatorWatts changed from 0.0 to 2755.555555555555

Closing the door to the room and then after 5min:

2019-10-06 11:02:16.732 [vent.ItemStateChangedEvent] - zmartmodbus_jablotron_tp150_96ef7c0a_chn0e0_AirTemperature changed from 23.2 to 23.3

But i never get the status that output is active for the actuator on channel 0

This was working flawless in the previous version (2.4 or 2.5 SNAPSHOT) or whatever i was using in OH 2.4

Any ideas what could be wrong?

And thanks for the great work and sharing the code.

/Anders

AndersV · October 6, 2019, 1:17pm

Small correction from the previous result.

Seems that some of the thermostats are not linked 100% correct. Values like set manual temp and airtemp does not always match with the correct channel.

5 out of 9 thermostats is like this. So 4 of them are OK.

I use simple linking mode in Configuration -> System -> Item Linking.
Maybe that is not supported?

However i still do not get data from any of the actuators

/Anders