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

Add-ons Bindings
, ,
141

@zmartify,
After some unrelated SW changes today, my machine was rebooted, and the binding no longer works:

2019-10-29 16:23:12.024 [INFO ] [rtmodbus.handler.ModbusSerialHandler] - Initializing Zmartify ModbusFunction Serial Controller.
2019-10-29 16:23:12.026 [ERROR] [rtmodbus.handler.ModbusSerialHandler] - ***** ZmartModbus test version has expired... contact peter@zmartify.dk ****
2019-10-29 16:23:18.325 [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-10-29 16:23:28.377 [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]

Honestly I am not sure I understand what is going, but my theory is that OH has been using an old (cached) version of the binding (Probably 2.4.0.201810010932, judging from the karaf console bundle:list), although that had been removed from the addons-folder and replaced with the 2.5.0-SNAPSHOT. The 2.5.0-SNAPSHOT causes the second error above (due to version incompatibilities).

After several hours of messing with bundle:uninstall, clearing the cache, etc. my conclusion is that the 2.4 snapshot I have been using is no longer functional due to the expiration logic, and the 2.5-SNAPSHOT is not functional on OH2.4.

It seems a part of the user base is running OH2.4 (stable), and I guess they are seeing the same problems as I am. Does anyone know if it is possible to use the 2.5-SNAPSHOT binding with OH2.4?

Right now I cannot make any version work, so I have lost integration between OH and my floor heating :frowning:

@zmartify: Any news regarding availability of the source code?

142

Hi @spiff42

I encountered the same issue. zmartify has released a new 2.5 SNAPHOT version that only works with OH 2.5. This version works flawless with both the Wavin AHC 9000 and Nilan CT300 controller and does not expire as i was told.

143

OK, thanks. I am a little hesitant to switch to OH2.5, though, but perhaps there is no other way :frowning:

144

Hi Mikkel, although the software needs a lot of documentation, comments etc. you can now find the source code at this location: https://github.com/zmartify/org.openhab.binding.zmartmodbus

145

I will see if I have the old 2.4 version available in working version.

146

Hi again guys,

After some break, where my NAS was moved away from the modbus connection, i can now also start contributing to the new binding bring up process. Before i start though can i perhaps make a small summary of what i read so far - i think it can be beneficial to clarify few things.

Old binding status:

  • old binding is closed source
  • it is based on OH2.4
  • it has an expiration timer and few people have now hit it (myself included)
  • @zmartify is looking onto making it without the timer at some point when time allows

New binding status:

  • open source here: https://github.com/zmartify/org.openhab.binding.zmartmodbus
  • based on OH2.5 and REQUIRES OH2.5 - just to be clear you can use OH2.5 snapshot binding and still run it on OH2.4 but not in this case. Is this because you use some new features?
  • no expiration this time
  • assuming OH2.5 is installed with the new binding it works ā€œflawlessā€ :wink:

@zmartify - i guess youā€™re in best position to confirm / reject this understanding.

Please check this understanding while i figure out how to upgrade to OH2.5ā€¦

Cheers
Boyan

147

Hi,

I installed 2.5 using openhabian and changed to testing to get 2.5. installed zigbee binding to get the serial binding pre-req.

I was able to read the air temps into items. After a reboot I got the following in the log:

    2019-11-02 17:47:31.705 [INFO ] [internal.controller.ModbusController] - Starting ModbusFunction controller org.openhab.binding.zmartmodbus.handler.ModbusBridgeHandler@184cdfe - {}

2019-11-02 17:47:31.792 [WARN ] [mmon.WrappedScheduledExecutorService] - Scheduled runnable ended with an exception: 

java.util.ConcurrentModificationException: null

	at java.util.HashMap$KeySpliterator.forEachRemaining(HashMap.java:1561) ~[?:?]

	at java.util.stream.AbstractPipeline.copyInto(AbstractPipeline.java:482) ~[?:?]

	at java.util.stream.AbstractPipeline.wrapAndCopyInto(AbstractPipeline.java:472) ~[?:?]

	at java.util.stream.ReduceOps$ReduceOp.evaluateSequential(ReduceOps.java:708) ~[?:?]

	at java.util.stream.AbstractPipeline.evaluate(AbstractPipeline.java:234) ~[?:?]

	at java.util.stream.ReferencePipeline.collect(ReferencePipeline.java:566) ~[?:?]

	at org.eclipse.smarthome.io.transport.serial.internal.SerialPortRegistry.getPortProvidersForPortName(SerialPortRegistry.java:86) ~[?:?]

	at org.eclipse.smarthome.io.transport.serial.internal.SerialPortManagerImpl.getIdentifier(SerialPortManagerImpl.java:85) ~[?:?]

	at org.openhab.binding.zmartmodbus.internal.transceiver.ModbusSerialTransceiver.connect(ModbusSerialTransceiver.java:70) ~[?:?]

	at org.openhab.binding.zmartmodbus.handler.ModbusBridgeHandler.initTransceiver(ModbusBridgeHandler.java:127) ~[?:?]

	at org.openhab.binding.zmartmodbus.handler.ModbusBridgeHandler$1.run(ModbusBridgeHandler.java:109) ~[?:?]

	at java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:511) ~[?:?]

	at java.util.concurrent.FutureTask.runAndReset(FutureTask.java:308) ~[?:?]

	at java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.access$301(ScheduledThreadPoolExecutor.java:180) ~[?:?]

	at java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.run(ScheduledThreadPoolExecutor.java:294) ~[?:?]

	at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1149) [?:?]

	at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:624) [?:?]

	at java.lang.Thread.run(Thread.java:748) [?:?]

2019-11-02 17:47:31.883 [INFO ] [artmodbus.handler.ModbusThingHandler] - Initialize Bridge OFFLINE for thing zmartmodbus:jablotron_actuator:3dfdc0b0:chn5

2019-11-02 17:47:31.886 [INFO ] [artmodbus.handler.ModbusThingHandler] - Initialize Bridge OFFLINE for thing zmartmodbus:jablotron_actuator:3dfdc0b0:chn6

2019-11-02 17:47:31.903 [INFO ] [artmodbus.handler.ModbusThingHandler] - Initialize Bridge OFFLINE for thing zmartmodbus:jablotron_ac116:83d6df69

2019-11-02 17:47:31.928 [INFO ] [artmodbus.handler.ModbusThingHandler] - Initialize Bridge OFFLINE for thing zmartmodbus:jablotron_tp150:3dfdc0b0:chn7e5
148

The OH2.5 version is updated to use the latest libraries and hence is not supported on OH2.4. Sorry for the inconvenience. But at decision I made when decided to rewrite the whole binding in July '19.
And yes there is no expiration time in the new version.

So far no problem has been identified and it also supports Nilan CT300 Air ventilation system.

Cheers
Peter

149

I will have a look at it. Havenā€™t seen it before.

150

Even after multiple reboots I no longer have a serial link. Stopping openhab2 service and just trying spiff42 python serial dump tool I get nothingā€¦

next stop reboot ahc9000 unitā€¦

Iā€™m not doing any writes, just reading temps via binding at the momentā€¦

151

Excellent, I canā€™t wait to dig into it :wink:

Actually, I went ahead and updated to 2.5M4, so I donā€™t need it anymore. But thanks anyway.

There were some problems updating to 2.5M4, but I think they are all solved now. Regarding the Wavin-binding, I had a little problem assigning the correct serial port. After that was solved I was able to follow your instructions and detect all actuators and thermostats.

I was able to link Items to the things, to make it fit in with my old naming scheme, so OH is now again able to send temperature readings to influxdb :wink:

152

The problems with selecting serial port is now fixed :slight_smile:

153

Iā€™m all working well too. Couple of receive timeout errors in the logs but running for 24 hr now and stable.

154

OK, just for the record, let me describe the problem I encountered, and the work-around.

After updating to OH2.5M4, the binding started up, and I noticed the following in the log:

2019-11-01 15:18:24.268 [ERROR] [rtmodbus.handler.ModbusBridgeHandler] - IOException Could not find a gateway on given path '/dev/cu.SLAB_USBtoUART', 10 ports available.

I first tried to change the serial port using PaperUI, but saving caused an exception to appear in the log.

The work-around was to create /dev/cu.SLAB_USBtoUART as a symlink to /dev/ttyUSB2 (which is the actual device). Then I restarted OH, and the bridge connection was established.

After this, changing the serial port via PaperUI was successful, and I was able to go to the inbox and discover all actuators and thermostats.

Your summary is on par with my understanding. Perhaps I can add that one thing that had me confused is that it seems like OH2.4 was caching the old binding somewhere, so it was able to run the old binging even though I removed the JAR-file from /usr/share/openhab2/addons/.

The new plugin was attempted started by OH but resulted in an exception in the log due to the missing prerequisites.

This meant that the reading of temperatures was working (with the old binding), and I was led to believe that I was using the new binding (since the old JAR-file had been removed). In the end this showed up after restarting OH, which resulted in the old binding no longer working, due to the expiration logic.

So, when attempting to move to the new plugin, remember to uninstall the old binding:

  1. Connect to karaf console, use bundle:list and find the ID of the old binding, then use bundle:uninstall <ID>.
  2. Stop openhab and run this command in a console: openhab-cli clean-cache

Hope this helps someone :slight_smile:

I took a brief look at the source, and I think it looks reasonably clear. Perhaps some of us here can pitch in with the documentation, now that the source is open. I guess the next step for me will be to set up a development environment, and see if I can build the binding from the current source. Iā€™m really excited about it!

155

Hi,

@zmartify on the AHC9000 is it possible to collect the ā€œmodeā€ of the thermostat? Typically, Party/Comfort/Eco etc?

Thanks,
Steve

156

It is already supported

157

Hi,

Can you advise where?

Under a thermostat I have the following channels:
Set Temp, Air Temp, Floor Temp, Dew Point Temp, Relative Humidity, Alive, Lost, Magnetic Contract, Magnetic Active, Low on Battery, Battery LEvel, Floor Sensor, Enable Floor Sensing, Desired Temp, RSSI Element Side, RSSI Controller Side

158

Ah ignore me ā€¦ found the ā€œShow Moreā€ button in PaperUI, sorry :pensive:

159

I now see the links to defined modes - I get a 6 returned but the manual shows 0-5? Is there an offset?

160

Hi Steve, I have made an updated version (available in the link and on github), which should solve the problem. Havenā€™t had time to test it fully yet. You need to delete the TP150s and do a new discovery. Best regards, Peter.