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

Add-ons Bindings
1

I have successfully installed and have gotten the CM11a binding to work with openhab2 (v2.3.0).
I have created an item and thing for an X10 relay switch for a testing.

Test Setup:

I am using the openhab>console commands to send ON/OFF commands through the cm11a to the relay switch.
I have a RS232 light box in line with the RS232 USB dongle and the CM11a device to monitor TX / RX command activity .

Commands Being Sent:
smarthome:send Garage_Light OFF <-- I see activity on the RS232 light box, and the relay turns off
smarthome:send Garage_Light OFF <-- No activity on RS232 light box
smarthome:send Garage_Light OFF <-- No activity on RS232 light box
smarthome:send Garage_Light OFF <-- No activity on RS232 light box

smarthome:send Garage_Light ON <-- Activity on RS232 light box. Relay turns on
** I turn off the switch relay via it’s manual push button on the front of the unit. STATE= OFF

smarthome:send Garage_Light ON <-- No activity on RS232 light box. Switch Relay = OFF
smarthome:send Garage_Light ON <-- No activity on RS232 light box. Switch Relay = OFF

smarthome:send Garage_Light OFF <-- I see activity on the RS232 light box,
smarthome:send Garage_Light ON <-- Activity on RS232 light box. Relay turns on

Issue:

If I send two or more ON commands, or OFF commands, back-to-back, either the cm11a binding or something else is NOT sending the 2nd through n’th command to the cm11a.

It appears that something is saving the previous command state and seems to think that the additional commands don’t need to be sent.

Question:

Is this an artifact of the cm11a binding? or Openhabian2?
Is there a way to force sending a command?

I have tried to turn on DEBUG or TRACE, but there appears to be be logging levels (or it isn’t working) beyond INFO

Thx

2

How close together are you sending the commands? If it’s too fast the controller may be ignoring the command because its still processing the previous command. This is a common problem with a lot of wireless and older protocols like X10.

Beyond that I’ve no idea what would be causing this behavior.

3

I have waited several seconds in between sending the commands.
In some cases while moving the RS232 light box to a better location 10’s of seconds.

4

I really need to get the source for the cm11a binding, and add some debug to see if I can isolate it to this module or somewhere else. Thanks for the response.

5
6

I know it is a 2 years old topic, but I (think I) have the same issue even with the latest OH version and CM11A bindings.
It seems that OH (or the CM11A bindings?) will not send a command to CM11A modem if it assumes the item is already in the wanted state. Of course, if the item is actually not in the assumed state (due to the manual button operation on the physical switch and lack of state feedback, because unidirectional nature of X-10), that is a problem.
For example: since there is no item state update feedback from an physical X-10 switch thing, OH/CM11A will not send an OFF command to a switch assumed to be OFF (due to latest OH state update) even if the switch is actually ON due to manual operation => ligths turned ON manually, cannot be turned OFF via Alexa bindings.

Is this “OH state-aware behaviour” or simply a C11A bindings bug?
Is there a way to enforce the command transmission each time, i.e. independently of the assumed item state?

7

I found the problem and the solution:

In cm11a*Handler.java there are checks on three places “if (!desiredState.equals(currentState))” which make the binding send command only if there is a change in the assumed state. If this is commented out, every command is sent independently of the item & thing state. I had to download download the code from the zip repository from github, change the code of cm11a bindings, compile it mit maven and to install the resulting .jar file manually via addons folder copy, but it worked at the end.

8

Wow… Excellent job!!! That was my original suspicion as well. I just never found the time to dig through the code to determine exactly where the problem was.

When I get some time in the fall or later on this summer, I’ll get the code and do the same changes you did and deploy it the same way. Thank you very much.

9

I am having this same issue, would you be able to get me a copy of the compiled code you used?

I have never compiled code for Java and only a handful of times for other languages.

Would greatly appreciate if anyone could point me in the right direction to fix this. Thanks!

10

The proper way to handle this would be to make a new feature in the binding where the user could choose to set an optional flag to have commands be sent regardless of what state OH currently thinks the receiving item is in.

11

I agree but guessing we would need someone with some more experience with developing bindings to get this functionality added. I would just like to be able to resolve this on my system in the mean time.
Im not sure where to begin to add this myself.

Thanks!

12

Let me see if I find time over the weekend to dig it out. I know it is “quick and dirty” and when the first pain is relieved there is no pressure any more to make it properly :slight_smile:

13

Thank you for taking a look at what you have @vjeko I really appreciate it. Yeah I’m fine with quick and dirty haha

14

Hi Pugy3655

try the following quick & dirty solution:

  1. Uninstall the original “CM11A” binding via PaperUI

  2. Get file org.openhab.binding.cm11a-2.5.6-SNAPSHOT.jar from the link below:
    openhab.binding.cm11a-2.5.6-SNAPSHOT.jar

  3. Copy .jar file to /usr/share/openhab2/addons

     ls -al

 -rw-r--r--  1 openhabian openhabian 34662 Jun 27 00:05 org.openhab.binding.cm11a-2.5.6-SNAPSHOT.jar

  4. OH should now automatically recognize the new addon, install it, restart it and even reconnect the things previously connected to old binding to the new one, check the log.

In this one I have also changed how dimmer devices are set to 100% dim level - it goes down to zero from whatever level it was and then reliably to 100%. It’s a bit unusual/uncomfortable, but the only way to get deterministic 100% level.
Tell me if this worked for you. Maybe I can merge the complete binding with source code into git with nice configurable interface “legacy/vs. enforced state update” one day.

Enjoy!
Vjeko

15

Going to try this tonight,
Thank you!

16

@vjeko Worked perfectly, thank you very much! This works for me for now but that would be great one day if you ever have the time. I had issues with dimming before, and worked around it for now by just making everything use the switch control only and no dimming. Not idea but it worked for my needs.
I may play with this again with your modifications.

17

I’m just getting OH3 setup and using cm11a and am getting the same issue. If I switch a light off locally OH still thinks it’s on and wont send the on command, it’s very annoying when using with alexa’s.

I can’t see a setting to fix this in the binding to guess it was never implemented, does anyone know if the org.openhab.binding.cm11a-2.5.6-SNAPSHOT.jar attached above will work ok on OH3 and I just need to drop the jar into the plugin folder?

Thanks.

18

Just had a look at the current version and it’s 3.0, so assume this 2.5.6 jar will not work.

@vjeko if you have the time, is there any chance you could rebuild a new version for OH3?

19

The CM11a binding should theoretically work in OH3.

20

@digitalgeek.me I am still on OH2.5.10, so no chance to check if it runs under OH3, but you can test it at no risk. I have not followed the upgrade deltas OH2 => OH3, so I have no idea if something on the interfaces has been changed or not, but it’s easy to test - as @namraccr stated, the chances are high that it works. At the moment I do not have time to upgrade to OH3, but maybe I’ll find some next week.