CM11a - Won't send same command two times in a row

Add-ons Bindings
21

Thanks for getting back. I have just tried the jar on OH3 and get the following warning.

2020-12-30 11:04:41.802 [WARN ] [org.apache.felix.fileinstall        ] - Error while starting bundle: file:/usr/share/openhab/addons/org.openhab.binding.cm11a-2.5.6-SNAPSHOT.jar

org.osgi.framework.BundleException: Could not resolve module: org.openhab.binding.cm11a [241]

      Unresolved requirement: Import-Package: org.eclipse.smarthome.config.core
    	at org.eclipse.osgi.container.Module.start(Module.java:444) ~[org.eclipse.osgi-3.12.100.jar:?]
    	at org.eclipse.osgi.internal.framework.EquinoxBundle.start(EquinoxBundle.java:383) ~[org.eclipse.osgi-3.12.100.jar:?]
    	at org.apache.felix.fileinstall.internal.DirectoryWatcher.startBundle(DirectoryWatcher.java:1260) [bundleFile:3.6.4]
    	at org.apache.felix.fileinstall.internal.DirectoryWatcher.startBundles(DirectoryWatcher.java:1233) [bundleFile:3.6.4]
    	at org.apache.felix.fileinstall.internal.DirectoryWatcher.startAllBundles(DirectoryWatcher.java:1221) [bundleFile:3.6.4]
    	at org.apache.felix.fileinstall.internal.DirectoryWatcher.doProcess(DirectoryWatcher.java:515) [bundleFile:3.6.4]
    	at org.apache.felix.fileinstall.internal.DirectoryWatcher.process(DirectoryWatcher.java:365) [bundleFile:3.6.4]
    	at org.apache.felix.fileinstall.internal.DirectoryWatcher.run(DirectoryWatcher.java:316) [bundleFile:3.6.4]

If you do decide the rebuild the cm11a plugin when you upgrade, I would be very very appreciative if you share it :grinning:

All the best,
Allan

22

Can you see if you get the same error from this jar?

23

Thanks for this, but I’m having the same issue. If I switch a light off locally OH still thinks it’s ON and won’t send the ON signal.

I’m a bit new to this, but I think the new jar is installed. I uninstalled the binding via the web UI that broke x10. then I copied the jar into the plugin folder, this seemed to do nothing, then I rebooted and the x10 things are back but is complaining no com port. I rebooted again and x10 was back working as normal, the 3.0 binding in the web ui does not show as installed, I guess it’s because it’s picked up the new jar.

My install is on Debian via openhabian-config.

24

Then that’s the right result. This does not have any changes to send duplicate messages. The reason the new jar from @vjeko doesn’t work is a namespace change in OH3. This shows that all he has to do is recompile from the main branch and you should get a fully functional binding with his change included


1 Like
25

Hi guys, I am working on this - currently just struggling to get OH3 running on my PI, but the first step afterwards will be to recompile and test the binding. Do not despair :slight_smile: yet.

26

Thanks for the update, hope you get it sorted on the pi.

Don’t rush on my account. My cm11 seemed to be really flakey and was also not receiving the codes (only sending), so have now managed to get it working with my RFXtrx to send the codes to a TM13 transceiver module. It’s surprisingly working really well and more reliable then the cm11a, so might leave it like this as I also use the RFXtrx for homeeasy and byon lights. Going forward and new devices will be zigbee!

27

I have compiled the cm11a binding “stateless” patch for OH3. Here the installation procedure:

  1. First install the “official” cm11a binding from the OH3 distribution (using Main UI => Settings => Add-ons => Bindings) and configure at least few (or all, but you can do this later) X10 things & items and test them - all must be ONLINE. This binding version will of course “suffer” from stateful (out-of-sync) behaviour. Note that you will replace the binding version later on, but all your things & items will remain there and will reconnect to the new (patched) binding. However, this step is important to verify your X10 and OH3 environment.

  2. Generally, after migration from OH2 to OH3, but also in case of initial/clean installation, the cm11a binding may complain that configured CM11A serial port is not known/accessible for JVM. In my case I had to enable the access rights by “sudo nano /etc/default/openhab” and update the EXTRA_JAVA_OPTS variable - take care to list your ttyXXX devices there such as: EXTRA_JAVA_OPTS="-Xms192m -Xmx320m -Dgnu.io.rxtx.SerialPorts=/dev/ttyUSB_CM11A:/dev/ttyUSB_RFXCOM:/dev/ttyACM0"

  3. Uninstall the official cm11a binding (using Main UI). Do not worry, all your configured X10 things & items will remain there, will be just UNINITIALIZED/OFFLINE in the mean time.

  4. Download the patched cm11a OH3.1.0 JAR file from here: org.openhab.binding.cm11a-3.1.0-SNAPSHOT.jar

  5. Copy JAR file to this folder on your machine: /usr/share/openhab/addons

  6. OH3 will automatically recognize the new JAR and start the installation.

  7. Check the OH3 log that new binding version has been recognized and all X10 things & items are INITIALIZED and finally ONLINE. No need to restart OH3 unless your CM11A HW or USB/serial adapter did not like the switchover - in such case I recommend full power recycle of CM11A and RASPI.

  8. Note that this binding patch is - unlikely the original version - NOT visible in the list of bindings in the Main UI, this is OK.

  9. Test your X10 items. Note that both X10 switch and X10 dimmer are implemented state-less. This means, if you dim to e.g. 70%, the item will go always first from whatever current dim level was down to 0% and then back to 70%. Since X10 devices cannot report the real dim level (which may be changed manually or by a second X10 controller), this was the only way to set it reliably.

  10. Enjoy your retro home automation setup!

FYI the sources you can unzip from here: org.openhab.binding.cm11a-3.1.0-SNAPSHOT-sources.jar