How to define an unknown Insteon device (EZX10RF) to OH4

  • Platform information:
    • Hardware: RPI 4 (ARM, 8G, diskless/NFS)
    • OS: Debian Bullseye/11
    • Java Runtime Environment: openjdk-17-jre-headless
    • openHAB version: 4.3.2
  • Issue of the topic: How to define my unknown-to-OH insteon device

I have an Insteon EZX10RF device I want to define to OpenHab. I think this should be pretty easy, but I’m still finding my way around OH and need some pointers on where to begin.

The EZX10RF was designed to be an X10-RF/Insteon bridge. As designed, it receives X10 radio signals and translates them into Insteon commands that it sends out, or vice versa. In my case, it is only receiving X10 signals from X10 keyfobs, and translating them to Insteon on/off/dim signals to be received by my Insteon PLM (2413S). I don’t use its ability to go from Insteon to X10.

The EZX10RF can accept up to 16 different X10 device signals, which it turns into an Insteon message including its own Insteon address and a subdevice code of hex 01-10. My older home automation software treated it like a remote button pad with 16 buttons.

OH4 created a device for the EZX10RF, but shows it as an unsupported device. I imagine it will be pretty easy to create a definition for this device, especially since I only need inbound messages from it. I can probably clone a keypad definition, and add more channels for the additional “buttons”, but I’m not sure how to start. I’m currently doing most of my OH work through the UI, but I’m very familiar with the UNIX/Linux command line, so manipulating files or databases is fine, too. Can someone get me started?

I asked how to begin defining a new kind of device to OH4, and all I hear are crickets.

I haven’t found any developer guides, or even any answers in the forum on this. All the developers learned some how. Will someone please give me a first step?

Did you follow the documentation of the binding? There seem to be some useful information. If you already did, it would be easier for us to understand if you post here what went wrong and provide some debug logs of the binding.

I’m not really a developer so I can’t really help but:

  • Googleing “openhab developers guide” first hit took me here to the dev guide: Developer Guide | openHAB. This will walk you through setting up the dev environment and how to contribute code. I did this years ago and contributed some small changes to the old Insteon binding. It was sort of a PITA but I muddled my way through it.

  • There is a way to add devices and features without opening the hood on the binding, see the " Adding New Legacy Device Types (Using Existing Device Features)" section of openhab’s insteon page here: Insteon - Bindings | openHAB

  • I’m not sure if you are familiar with the Insteon-terminal project (GitHub - pfrommerd/insteon-terminal: A simple tool to allow modification of an insteonplm or a insteonhub) but I did a bunch of hacking here before doing anything on the openhab binding. Its python and didn’t need me to set up a bunch of stuff to play around with sending insteon commands. You might want to have a look if you haven’t already.

Thank you for the resources, Tom. Your Google-Fu is clearly working
better than mine was. I searched for “openhab writing device definition”
and a variety of other less successful searches. The link for “Adding
New Legacy …” sounds particularly interesting for my immediate need. I
appreciate the help.

                  -Brian M.
1 Like

@jeshab is the current owner of the Insteon binding as of OH 4.3.

If I understand correctly, you just want the ON/OFF events from that device to be reflected in OH? Out of curiosity, does this device transmit the X10 messages it receives on to the Insteon bus as well? I am asking because I am wondering if you add each of your keyfobs as X10 sensors, you would get these events in OH via X10 instead.

I found the below document that lists all the supported Insteon commands for this device. So it shouldn’t be too hard to implement although some of the standard commands are different compared to the more recent Insteon devices.

Thanks for the interest, Jeremy.

You’re right. I just want to receive the X10 on/off (and rarely, dim)
signals from the device. If I’m following you, you’re suggesting that I
listen for X10 commands received from the keyfobs by the Insteon PLM,
instead of converting them to Insteon in the EZX10RF.

It’s been a dozen or more years since I played with that arrangement,
but my recollection is that the PLM was often failing to receive the X10
signals. It may be as simple as the fact that the EXZ10RF has a roughly
18" telescopic antenna whereas the PLM is about 3" high with no external
antenna. Whatever the reason, receiving direct to the PLM was
unsatisfactory in my environment, whereas the EZX10RF worked. That in
spite of the fact that the two devices are probably only 8’ apart. It
might be a good solution for other folks, though.

I’m anticipating/dreading the day that my ancient EZX10RF dies. It’s
always been a quirky beast to configure, but I love the X10 keyfobs
because they last forever on their original battery. Usually a keyfob
will go 8-10 years, and then the buttons wear out, but the coin battery
was still good. Everything I’ve looked at “recently” (e.g. 5 years ago),
looked like it had a battery life of a few months. If they’re good for 6
months on a charge, and I have 8 keyfobs planted around the house in
strategic locations (which I do), that means discovering a dead battery
about every 3.25 weeks. Yuck.

Thanks for the contribution to the discussion, Jeremy.

-Brian M

I was just wondering if that bridge device was somehow also putting the X10 messages it received on the Insteon network it is connected to, along side with the converted Insteon messages, since an Insteon PLM and Hub can receive X10 messages. But it’s probably not the case.

Anyway, I can try to add support for it. Assuming you configured your PLM bridge and it is online, can you run the following console debug commands? (AA.BB.CC should be replaced by the actual address of your device)

# Start monitoring
insteon debug startMonitoring AA.BB.CC
# Send product id request
insteon debug sendStandardMessage AA.BB.CC 10 00
# Send code record read request
insteon debug sendStandardMessage AA.BB.CC F1 00
# Press a few times on couple of your keyfobs
# Tap on the device set button (no need to hold it)
# Stop monitoring
insteon debug stopMonitoring AA.BB.CC

Once done, please attach the generated event message log file to this thread. Thanks.

@jeshab Thank you for the offer to perhaps add support for the device. Two logs are below. The first are notes on the sequence of events, extracted from a console log. The other is the actual log file generated. I would have preferred my comments to be interleaved with the actual generated output, but I didn’t see a way I could accomplish that.

Having said that, I don’t think I can make a case for you spending a lot of time on this. The EZX10RF is an old device that I don’t think they sold a lot of. Of the few still in service, it may well be that mine is the only one present in the OpenHab world. It would be great for me if OpenHab supported it natively, but you may have more productive areas in which to spend your time. Though a noobie to OH, I have decades of experience convincing software to do what I want, and I’m not afraid of digging into code myself if someone can point me in the right direction.

So with that, work on this or not as you see fit. Here are the logs.

Sequence of events:

  1. Start openhab-cli console
  2. insteon debug startMonitoring 01.7f.58
  3. insteon debug sendStandardMessage 01.7f.58 10 00
  4. OUT:Cmd:0x62|toAddress:01.7F.58|messageFlags:0x0F=DIRECT:3:3|command1:0x10|command2:0x00|
  5. insteon debug sendStandardMessage AA.BB.CC F1 00
  6. OUT:Cmd:0x62|toAddress:01.7F.58|messageFlags:0x0F=DIRECT:3:3|command1:0xF1|command2:0x00|
  7. Keyfob #1 button 1 (on)
  8. Keyfob #1 button 1 (on)
  9. Keyfob #1 button 2 (off)
  10. Keyfob #1 dim
  11. Keyfob #2 button 2 (off) - note - different device code than fob 1
  12. tap EZX10RF set button - not sure if I got a light blink confirmation
  13. tap EZX10RF set button again - received blink confirmation
  14. Stopped monitoring.
2025-02-01 10:48:30.865 OUT:Cmd:0x62|toAddress:01.7F.58|messageFlags:0x0F=DIRECT:3:3|command1:0x10|command2:0x00|
2025-02-01 10:48:30.876 IN:Cmd:0x62|toAddress:01.7F.58|messageFlags:0x0F=DIRECT:3:3|command1:0x10|command2:0x00|ACK/NACK:0x06|
2025-02-01 10:48:38.003 IN:Cmd:0x50|fromAddress:01.7F.58|toAddress:41.EF.97|messageFlags:0x2B=ACK_OF_DIRECT:2:3|command1:0x10|command2:0x00|
2025-02-01 10:49:03.147 OUT:Cmd:0x62|toAddress:01.7F.58|messageFlags:0x0F=DIRECT:3:3|command1:0xF1|command2:0x00|
2025-02-01 10:49:07.978 IN:Cmd:0x62|toAddress:01.7F.58|messageFlags:0x0F=DIRECT:3:3|command1:0xF1|command2:0x00|ACK/NACK:0x06|
2025-02-01 10:49:08.182 IN:Cmd:0x62|toAddress:01.7F.58|messageFlags:0x0F=DIRECT:3:3|command1:0xF1|command2:0x00|ACK/NACK:0x06|
2025-02-01 10:49:08.187 IN:Cmd:0x50|fromAddress:01.7F.58|toAddress:41.EF.97|messageFlags:0x2B=ACK_OF_DIRECT:2:3|command1:0xF1|command2:0x00|
2025-02-01 10:49:08.191 IN:Cmd:0x62|toAddress:01.7F.58|messageFlags:0x0F=DIRECT:3:3|command1:0xF1|command2:0x00|ACK/NACK:0x06|
2025-02-01 10:49:08.195 IN:Cmd:0x50|fromAddress:01.7F.58|toAddress:41.EF.97|messageFlags:0x2B=ACK_OF_DIRECT:2:3|command1:0xF1|command2:0x00|
2025-02-01 10:49:08.199 IN:Cmd:0x62|toAddress:01.7F.58|messageFlags:0x0F=DIRECT:3:3|command1:0xF1|command2:0x00|ACK/NACK:0x06|
2025-02-01 10:49:08.203 IN:Cmd:0x62|toAddress:01.7F.58|messageFlags:0x0F=DIRECT:3:3|command1:0xF1|command2:0x00|ACK/NACK:0x06|
2025-02-01 10:49:08.207 IN:Cmd:0x50|fromAddress:01.7F.58|toAddress:41.EF.97|messageFlags:0x2B=ACK_OF_DIRECT:2:3|command1:0xF1|command2:0x00|
2025-02-01 10:49:08.212 IN:Cmd:0x62|toAddress:01.7F.58|messageFlags:0x0F=DIRECT:3:3|command1:0xF1|command2:0x00|ACK/NACK:0x06|
2025-02-01 10:49:08.217 IN:Cmd:0x50|fromAddress:01.7F.58|toAddress:41.EF.97|messageFlags:0x2B=ACK_OF_DIRECT:2:3|command1:0xF1|command2:0x00|
2025-02-01 10:49:08.582 IN:Cmd:0x50|fromAddress:01.7F.58|toAddress:41.EF.97|messageFlags:0x2B=ACK_OF_DIRECT:2:3|command1:0xF1|command2:0x00|
2025-02-01 10:50:05.405 IN:Cmd:0x50|fromAddress:01.7F.58|toAddress:41.EF.97|messageFlags:0x4B=ALL_LINK_CLEANUP:2:3|command1:0x11|command2:0x05|
2025-02-01 10:50:14.828 IN:Cmd:0x50|fromAddress:01.7F.58|toAddress:00.00.05|messageFlags:0xCB=ALL_LINK_BROADCAST:2:3|command1:0x11|command2:0x00|
2025-02-01 10:50:15.116 IN:Cmd:0x50|fromAddress:01.7F.58|toAddress:00.00.05|messageFlags:0xCB=ALL_LINK_BROADCAST:2:3|command1:0x11|command2:0x00|
2025-02-01 10:50:15.452 IN:Cmd:0x50|fromAddress:01.7F.58|toAddress:00.00.05|messageFlags:0xCB=ALL_LINK_BROADCAST:2:3|command1:0x11|command2:0x00|
2025-02-01 10:50:15.803 IN:Cmd:0x50|fromAddress:01.7F.58|toAddress:00.00.05|messageFlags:0xCB=ALL_LINK_BROADCAST:2:3|command1:0x11|command2:0x00|
2025-02-01 10:50:16.140 IN:Cmd:0x50|fromAddress:01.7F.58|toAddress:00.00.05|messageFlags:0xCB=ALL_LINK_BROADCAST:2:3|command1:0x11|command2:0x00|
2025-02-01 10:50:16.397 IN:Cmd:0x50|fromAddress:01.7F.58|toAddress:41.EF.97|messageFlags:0x41=ALL_LINK_CLEANUP:0:1|command1:0x11|command2:0x05|
2025-02-01 10:50:26.409 IN:Cmd:0x50|fromAddress:01.7F.58|toAddress:00.00.05|messageFlags:0xCB=ALL_LINK_BROADCAST:2:3|command1:0x13|command2:0x00|
2025-02-01 10:50:26.712 IN:Cmd:0x50|fromAddress:01.7F.58|toAddress:00.00.05|messageFlags:0xCB=ALL_LINK_BROADCAST:2:3|command1:0x13|command2:0x00|
2025-02-01 10:50:27.033 IN:Cmd:0x50|fromAddress:01.7F.58|toAddress:00.00.05|messageFlags:0xCB=ALL_LINK_BROADCAST:2:3|command1:0x13|command2:0x00|
2025-02-01 10:50:27.385 IN:Cmd:0x50|fromAddress:01.7F.58|toAddress:00.00.05|messageFlags:0xCB=ALL_LINK_BROADCAST:2:3|command1:0x13|command2:0x00|
2025-02-01 10:50:27.737 IN:Cmd:0x50|fromAddress:01.7F.58|toAddress:00.00.05|messageFlags:0xCB=ALL_LINK_BROADCAST:2:3|command1:0x13|command2:0x00|
2025-02-01 10:50:27.993 IN:Cmd:0x50|fromAddress:01.7F.58|toAddress:41.EF.97|messageFlags:0x41=ALL_LINK_CLEANUP:0:1|command1:0x13|command2:0x05|
2025-02-01 10:50:40.071 IN:Cmd:0x50|fromAddress:01.7F.58|toAddress:00.00.05|messageFlags:0xCB=ALL_LINK_BROADCAST:2:3|command1:0x16|command2:0x00|
2025-02-01 10:50:40.359 IN:Cmd:0x50|fromAddress:01.7F.58|toAddress:00.00.05|messageFlags:0xCB=ALL_LINK_BROADCAST:2:3|command1:0x16|command2:0x00|
2025-02-01 10:50:40.694 IN:Cmd:0x50|fromAddress:01.7F.58|toAddress:00.00.05|messageFlags:0xCB=ALL_LINK_BROADCAST:2:3|command1:0x16|command2:0x00|
2025-02-01 10:50:41.046 IN:Cmd:0x50|fromAddress:01.7F.58|toAddress:00.00.05|messageFlags:0xCB=ALL_LINK_BROADCAST:2:3|command1:0x16|command2:0x00|
2025-02-01 10:50:41.382 IN:Cmd:0x50|fromAddress:01.7F.58|toAddress:00.00.05|messageFlags:0xCB=ALL_LINK_BROADCAST:2:3|command1:0x16|command2:0x00|
2025-02-01 10:50:41.638 IN:Cmd:0x50|fromAddress:01.7F.58|toAddress:41.EF.97|messageFlags:0x41=ALL_LINK_CLEANUP:0:1|command1:0x16|command2:0x05|
2025-02-01 10:51:09.362 IN:Cmd:0x50|fromAddress:01.7F.58|toAddress:00.00.02|messageFlags:0xCB=ALL_LINK_BROADCAST:2:3|command1:0x13|command2:0x00|
2025-02-01 10:51:10.706 IN:Cmd:0x50|fromAddress:01.7F.58|toAddress:00.00.02|messageFlags:0xCB=ALL_LINK_BROADCAST:2:3|command1:0x13|command2:0x00|
2025-02-01 10:51:10.947 IN:Cmd:0x50|fromAddress:01.7F.58|toAddress:41.EF.97|messageFlags:0x41=ALL_LINK_CLEANUP:0:1|command1:0x13|command2:0x02|
2025-02-01 10:51:11.314 IN:Cmd:0x50|fromAddress:01.7F.58|toAddress:41.EF.97|messageFlags:0x4B=ALL_LINK_CLEANUP:2:3|command1:0x13|command2:0x02|

So commands sent to the device from the modem don’t get any responses. My guess is the device isn’t cross linked. The device is linked to the modem but probably not vice versa. Could you try to relink (manually) the modem to the device and run the first part of the test? Running the console command below you should have two records for your device (one controller and one responder)

insteon modem listDatabase --records | grep 01.7F.58

Regarding the keyfob events, I can see all of them coming in. Interestingly, your keyfob #1 is attached to group 5 and #2 to group 2.

Out of curiosity, can this device forward Insteon message it receives back to X10 device? The developer documentation isn’t clear about it. My understanding is that it only sends out events it received from the X10 devices attached to it.

So commands sent to the device from the modem don’t get any responses. My guess is the device isn’t cross linked. The device is linked to the modem but probably not vice versa. Could you try to relink (manually) the modem to the device and run the first part of the test? Running the console command below you should have two records for your device (one controller and one responder)

I don’t believe I can link them either way. The EZX10RF instructions only speak of how to link it to X10 devices. I’ve tried the normal procedures I would use to link it to the PLM (put the PLM in linking mode and then tap or tap-hold the set button on the EZX10RF) and the reverse link. In the forward direction, the PLM just keeps blinking, waiting for something to try to link to it. It never hears the EZX10RF if I tap set, and if I hold set the EZX10RF goes into X10 linking mode, listening for an X10 signal.

I get the same results if I try to place the EZX10RF in linking mode for the reverse link. Instead of listening for the PLM, it listens for X10. When I try to have the PLM link to it, a tap does nothing, and a hold puts the PLM in link (listening) mode.

If you’re seeing a linking record in the PLM, it was probably programmed there via my old home automation software, MisterHouse. MH was never able to talk to the EZX10RF, though. It could hear from it via the PLM, but could never program it. If OH can write links to the PLM, we could probably get a reverse link in that way.

The EZX10RF was only intended to hear X10 RF traffic and translate it to powerline or Insteon traffic. The only X10 RF devices I can think of are button pads of one sort or another, or motion sensors. All those are transmit-only, “deaf” in the X-10 terminology of the time. If that’s correct, there would be no reason for the EZX10RF to listen for Insteon signals, just send them.

Regarding the keyfob events, I can see all of them coming in. Interestingly, your keyfob #1 is attached to group 5 and #2 to group 2.

The EZX10RF just assigns whatever group number it finds free as each device is programmed, with no say from me. Those were obviously programmed at different times.

My understanding is that it only sends out events it received from the X10 devices attached to it.

I believe that is correct.

To anyone else who comes across this, the “Adding New Legacy Device …” topic mentioned above is on that page, but hidden. Find the " Legacy Device Customization" section and expand “Details” to find it.

1 Like

Also, correcting an earlier entry …

Reading the docs I see that the EZX10RF will actually support 20 X10 devices, not 16.

Thats interesting. I thought there were only 16 addresses per house code, does it do more than 1 HC?

From reading the document below, it doesn’t seem that the modem can be linked to the device.

I did some further research and it appears that no other third party application supporting Insteon was able to support that device. Some suggested to just use a X10 RF transceiver which can communicate directly with your PLM. If you go that route, I can add a X10 remote device type that would trigger events on ON/OFF and DIM/BRIGHT button press.

I think it’s 20 Insteon scenes.

You’re correct. 20 insteon scenes. I’m not sure how one triggers 20 scenes from 16 unit codes – perhaps multiple scenes can be triggered at the same time from a single X10 house code, or perhaps it handles multiple house codes. I’ve heard of larger X10 installations where they needed more than one house code to cover all their devices. In any case, 20 insteon scenes are promised, not 20 X10 codes.

As for …

Some suggested to just use a X10 RF transceiver which can communicate directly with your PLM. If you go that route, I can add a X10 remote device type that would trigger events on ON/OFF and DIM/BRIGHT button press.

… I think you are suggesting replacing the EZX10RF with a different device that speaks X10 to the PLM via power lines, instead of one that converts X10 to Insteon. That hasn’t worked well in the past (noise, dealing with 2-phase wiring, etc.), but technology has changed and I’m open to trying it again. It sounds like the EZX10RF is a non-starter. I don’t completely understand why the PLM needs to know that the device sending signals is an EZX10RF as opposed to a wireless keypad as long as the signals are correct, but I think you know this stuff better than about anyone I’m ever likely to find, so I’m sure you’re right.

Thank you for digging into this for me. And thanks for all the Insteon work for OpenHab.

@jeshab

Is there a reason that in this linking process described in the datasheet you couldn’t just link the PLM rather than a device? I’m thinking you would just have the device as a controller in the PLMs ALDB and the PLM as a responder in the devices ALDB, but since you cannot send insteon signals to the device to get X10 out, I think that would be all you need. You could then likely just add it as a switch that gets triggered on or off from the device when it receives the appropriate X10 RF signal.

I had a decently large X10 setup back in the day. I used different HCs on each floor of the house and also a different HC for sensors than things like lights.

BTW, I still use a couple X10 motion sensors. Since the PLM doesn’t support X10RF I have an x10 RF receiver (W800RF32A and used to use a super cheap X10 CM-19A) on a PC and software called Heyu. Heyu us linux based opensource software that has been around for decades and I used to use this for my whole X10 smart home before openHAB came along. Anyway, I now just receive the X10RF signals with this and then pass signals to my openHAB server over MQTT. If it proves that you can’t use this device for what you are looking for, you might want to do this. I’d be hally to walk you through details if you are interested.

@tommycw10 Thank you for the reference to the X10 RF receiver. When my EZX10RF dies, I appreciate having some other options.

I don’t really understand the concern regarding the reverse link between the PLM and the EZX10RF. The PLM is receiving the EZX10RF Insteon signals successfully, as did MisterHouse before. That would seem to be enough to allow OH to react when a signal comes in. Still, I’ve stuck my nose enough code behind apparently simple issues to know that the solutions can actually turn out to be difficult or impossible. Unless there’s a large EZX10RF community out there, I can’t make a case for the maintainer putting much time into this.

Also, a note to @jeshab while I’m writing. There’s a small bug in the Insteon debug code that I though I should bring to your attention. When I enter:

insteon debug startMonitoring 01.7f.58

I receive back a message:

Message events logged in [path]/messageEvents-017f58.log

However, the actual file name is:

[path]/messageEvents-017F58.log

Note the capital F instead of lower case. When I first went looking for the debug log I copied and pasted the file name from the message and receive “no such file or directory.” As I say, a minor bug, but I thought you’d like to know.