Insteon 2342-2 8 button remote issues

I just set up an Insteon 8 button remote and am having a few issues.

First, buttons a/b and c/d are swapped.

Second, buttons e-h do not appear to work. No events are triggered in the OH logs, and I also get errors in the logs on startup that those buttons aren’t defined.

It seems like the binding only works for the 4-button remote? The documentation also makes no mention of an 8 button remote. The remote has the same model number 2342-2, apparently.

Other than the swaping, butons a-d are working fine.

Does the binding need some kind of update for this remote?

I only have the 4-button version. This will need some work on your end to get this working, but there is a good chance you can make this work without changes to the source code. Most likely a change to the xml files is sufficient.

First, please find out exactly what messages your remote is sending when you press the various buttons. For that, switch on debug logging for your insteonplm binding (see wiki), and search the log for the incoming messages. They should be ALL_LINK_BROADCAST messages like the one below. In particular the “toAddress” field is interesting. That one should change depending on what button you press.

2016-08-13 08:20:23 DEBUG o.o.b.i.InsteonPLMActiveBinding[:522]- got msg: IN:Cmd:0x50|fromAddress:2E.7C.9A|toAddress:00.00.01|messageFlags:0xCB=ALL_LINK_BROADCAST:3:2|command1:0x11|command2:0x00|

From these messages you can establish a map: button pressed -> toAddress. Once you post that I can provide you with an xml file for your device. Or you can try hacking in the device itself. There are instructions towards the end of the wiki (“adding new device types”) that explain how to do that.


It appears that the model # was changed. The 4 button is a 2342-232 and 8 button is a 2342-222.

Ok, I nuked my rules and items to simplify the output and captured the results of hitting each button. They can be found at:

The toAddress fields of the broadcasts seem to vary from button to button. I did actually push them in the order indicated (a-h). I have no idea why each pair’s numbering seems to be swapped.

Hopefully this is helpful…

Good, this was what I was looking for. Try putting this into your device_types.xml (see wiki instructions). This should create a new device type F00.00.20 that you can reference from your .items file:

<device productKey="F00.00.20">
     <description>Mini Remote (8 Button)</description>
     <feature name="buttonA">RemoteButton2</feature>
     <feature name="buttonB">RemoteButton1</feature>
     <feature name="buttonC">RemoteButton4</feature>
     <feature name="buttonD">RemoteButton3</feature>
      <feature name="buttonE">RemoteButton6</feature>
     <feature name="buttonF">RemoteButton5</feature>
     <feature name="buttonG">RemoteButton8</feature>
     <feature name="buttonH">RemoteButton7</feature>
      <feature name="lastheardfrom">GenericLastTime</feature>

And then in device_features.xml

<feature name="RemoteButton1">
	<message-handler cmd="0x03" group="1">NoOpMsgHandler</message-handler>
	<message-handler cmd="0x11" button="1" group="1">LightOnSwitchHandler</message-handler>
	<message-handler cmd="0x13" button="1" group="1">LightOffSwitchHandler</message-handler>
<feature name="RemoteButton2">
    	<message-handler cmd="0x03" group="2">NoOpMsgHandler</message-handler>
    	<message-handler cmd="0x11" button="2" group="2">LightOnSwitchHandler</message-handler>
    	<message-handler cmd="0x13" button="2" group="2">LightOffSwitchHandler</message-handler>

<feature name="RemoteButton3">
    	<message-handler cmd="0x03" group="3">NoOpMsgHandler</message-handler>
    	<message-handler cmd="0x11" button="3" group="3">LightOnSwitchHandler</message-handler>
    	<message-handler cmd="0x13" button="3" group="3">LightOffSwitchHandler</message-handler>
<feature name="RemoteButton4">
    	<message-handler cmd="0x03" group="4">NoOpMsgHandler</message-handler>
    	<message-handler cmd="0x11" button="4" group="4">LightOnSwitchHandler</message-handler>
    	<message-handler cmd="0x13" button="4" group="4">LightOffSwitchHandler</message-handler>
<feature name="RemoteButton5">
    	<message-handler cmd="0x03" group="5">NoOpMsgHandler</message-handler>
    	<message-handler cmd="0x11" button="5" group="5">LightOnSwitchHandler</message-handler>
    	<message-handler cmd="0x13" button="5" group="5">LightOffSwitchHandler</message-handler>
<feature name="RemoteButton6">
    	<message-handler cmd="0x03" group="6">NoOpMsgHandler</message-handler>
    	<message-handler cmd="0x11" button="6" group="6">LightOnSwitchHandler</message-handler>
    	<message-handler cmd="0x13" button="6" group="6">LightOffSwitchHandler</message-handler>
<feature name="RemoteButton7">
    	<message-handler cmd="0x03" group="7">NoOpMsgHandler</message-handler>
    	<message-handler cmd="0x11" button="7" group="7">LightOnSwitchHandler</message-handler>
    	<message-handler cmd="0x13" button="7" group="7">LightOffSwitchHandler</message-handler>
<feature name="RemoteButton8">
    	<message-handler cmd="0x03" group="8">NoOpMsgHandler</message-handler>
    	<message-handler cmd="0x11" button="8" group="8">LightOnSwitchHandler</message-handler>
    	<message-handler cmd="0x13" button="8" group="8">LightOffSwitchHandler</message-handler>

Your device_types.xml changes have been working great for me! Thanks!

I’m not sure how things like this eventually make their way into the official releases.

I will submit a pull request. Thanks for testing!

It looks like your change has been merged, thank you for working on this! Do you think that a new version of the Insteon binding will be released for OH 1.9 or will it only be included once the bindings are ported to OH2? If not is it worth trying to do a local build from ToT (I’m a software developer, I don’t mind doing local builds etc), or should I just use the “insteonplm:more_features=” feature from the config file?

(not that I really mind using the extra device XML files, I’m just curious about the development cycle)

Sorry that I can’t be of help with this. I am totally confused about the development cycle. I usually build the binding myself, then drop it into the addons directory. There used to be cloudbees where you could pick up the insteonplm jar file from the nightly build and just drop it in. It is backwards compatible, so you can drop it into an existing OH1.8 installation.

Thank you for the prompt reply! I’ll try to do a local build then, it might be fun to contribute to the project if I can.