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

Per the quick start manual, you can connect multiple scenes per X10 device.

That’s was my expectation but unless I am missing something, this is not possible based on the quick start manual. The device can only be linked one way as a controller to another device part of scene as responder. For the binding to work, it needs to be able to communicate with the device by having a link in opposite direction.

If the binding cannot identify the device by getting a response to the product id request 0x10, it won’t be able to determine its device type. At this time, there is no way to manually override at the device thing level. The expectation with the new implementation is that it should be able to communicate with the device to get the information necessary to integrate with the other devices.

@bpmartin20 maybe you could try to link programmatically? The developer documentation for EZX10RF indicates that it supports the standard linking command 0x09.

# Confirm if there are records for that device in the modem database
insteon modem listDatabase --records | grep 01.7F.58
# Start monitoring
insteon debug startMonitoring 01.7F.58
# Start modem linking as responder on group 1 (if modem responder link missing)
insteon debug sendIMMessage StartALLLinking 00 01
# Start device linking on group 1 (if modem responder link missing)
insteon debug sendStandardMessage 01.7F.58 09 01
# Start modem linking as controller on group 0 (if modem controller link missing)
insteon debug sendIMMessage StartALLLinking 01 00
# Start device linking on group 0 (if modem controller link missing)
insteon debug sendStandardMessage 01.7F.58 09 00
# Cancel modem linking (if linking doesn't happen)
insteon debug sendIMMessage CancelALLLinking
# Stop monitoring
insteon debug stopMonitoring 01.7F.58
# Confirm if the records were added to the modem database
insteon modem listDatabase --records | grep 01.7F.58

Thanks for reporting. This has already been fixed in the PR below which is improving the debug monitoring support. It will be released in OH 5.0.

First, a little more background. I’m trying to migrate off of MisterHouse to OpenHab. MH is currently the production system. I only have one PLM and one EZX10RF. I take MH down in order to reallocate the serial link for the PLM to OH, and then I enable the PLM in OH. No configuration changes are made to the PLM or the EZX10RF at all. The configuration works in MH and has worked that way since I installed the EZX10RF in 2008. So, we know the hardware is good as-is.

Regarding your test instructions, I don’t think the initial database was as you expected, and you probably would have changed the instructions if you’d been with me at the time. Basically it looks to me like every group is already in the database. Not sure how to proceed, I just ran through your instructions verbatim even though nothing appeared to be missing. The listDatabase output produced lots of redundant blocks which I’ve edited down and annotated for brevity, but otherwise here is the console log:

openhab> insteon modem listDatabase --records | grep 01.7F.58 
01.7F.58 RESP group: 0x01 data1: 0x00 data2: 0x00 data3: 0x00
01.7F.58 RESP group: 0x02 data1: 0x00 data2: 0x00 data3: 0x00
01.7F.58 RESP group: 0x03 data1: 0x00 data2: 0x00 data3: 0x00
01.7F.58 RESP group: 0x04 data1: 0x00 data2: 0x00 data3: 0x00
01.7F.58 RESP group: 0x05 data1: 0x00 data2: 0x00 data3: 0x00
01.7F.58 RESP group: 0x06 data1: 0x00 data2: 0x00 data3: 0x00
01.7F.58 RESP group: 0x07 data1: 0x00 data2: 0x00 data3: 0x00
01.7F.58 RESP group: 0x08 data1: 0x00 data2: 0x00 data3: 0x00
01.7F.58 RESP group: 0x09 data1: 0x00 data2: 0x00 data3: 0x00
01.7F.58 RESP group: 0x0A data1: 0x00 data2: 0x00 data3: 0x00
01.7F.58 RESP group: 0x0B data1: 0x00 data2: 0x00 data3: 0x00
01.7F.58 RESP group: 0x0C data1: 0x00 data2: 0x00 data3: 0x00
01.7F.58 RESP group: 0x0D data1: 0x00 data2: 0x00 data3: 0x00
01.7F.58 RESP group: 0x0E data1: 0x00 data2: 0x00 data3: 0x00
01.7F.58 RESP group: 0x0F data1: 0x00 data2: 0x00 data3: 0x00
01.7F.58 RESP group: 0x10 data1: 0x00 data2: 0x00 data3: 0x00
01.7F.58 RESP group: 0x01 data1: 0x00 data2: 0x00 data3: 0x00
01.7F.58 RESP group: 0x02 data1: 0x00 data2: 0x00 data3: 0x00
01.7F.58 RESP group: 0x03 data1: 0x00 data2: 0x00 data3: 0x00
01.7F.58 RESP group: 0x04 data1: 0x00 data2: 0x00 data3: 0x00
01.7F.58 RESP group: 0x05 data1: 0x00 data2: 0x00 data3: 0x00
01.7F.58 RESP group: 0x06 data1: 0x00 data2: 0x00 data3: 0x00
01.7F.58 RESP group: 0x07 data1: 0x00 data2: 0x00 data3: 0x00
01.7F.58 RESP group: 0x08 data1: 0x00 data2: 0x00 data3: 0x00
01.7F.58 RESP group: 0x09 data1: 0x00 data2: 0x00 data3: 0x00
01.7F.58 RESP group: 0x0A data1: 0x00 data2: 0x00 data3: 0x00
01.7F.58 RESP group: 0x0B data1: 0x00 data2: 0x00 data3: 0x00
01.7F.58 RESP group: 0x0C data1: 0x00 data2: 0x00 data3: 0x00
01.7F.58 RESP group: 0x0D data1: 0x00 data2: 0x00 data3: 0x00
01.7F.58 RESP group: 0x0E data1: 0x00 data2: 0x00 data3: 0x00
01.7F.58 RESP group: 0x0F data1: 0x00 data2: 0x00 data3: 0x00
01.7F.58 RESP group: 0x10 data1: 0x00 data2: 0x00 data3: 0x00

—above appear to be two complete lists of every group address supported. In fact, I counted 21 actual complete lists in the output—

insteon debug startMonitoring 01.7F.58
Started monitoring the device 01.7F.58.
Message events logged in /var/lib/openhab/insteon/messageEvents-017F58.log
openhab> insteon debug sendIMMessage StartALLLinking 00 01
IM message sent to the modem.
OUT:Cmd:0x64|LinkCode:0x00|ALLLinkGroup:0x01|
openhab> insteon debug sendStandardMessage 01.7F.58 09 01
Direct message sent to device 01.7F.58.
OUT:Cmd:0x62|toAddress:01.7F.58|messageFlags:0x0F=DIRECT:3:3|command1:0x09|command2:0x01|
openhab> insteon debug sendIMMessage StartAllLinking 01 00
Error while trying to create message.
openhab> insteon debug sendIMMessage StartALLLinking 01 00                                                                                                                                  
IM message sent to the modem.
OUT:Cmd:0x64|LinkCode:0x01|ALLLinkGroup:0x00|
openhab> insteon debug sendStandardMessage 01.7F.58 09 00
Direct message sent to device 01.7F.58.
OUT:Cmd:0x62|toAddress:01.7F.58|messageFlags:0x0F=DIRECT:3:3|command1:0x09|command2:0x00|
openhab> insteon debug sendIMMessage CancelALLLinking
IM message sent to the modem.
OUT:Cmd:0x65|
openhab> insteon debug stopMonitoring 01.7F.58
Stopped monitoring the device 01.7F.58.
openhab> insteon modem listDatabase --records | grep 01.7F.58
01.7F.58 RESP group: 0x01 data1: 0x00 data2: 0x00 data3: 0x00
01.7F.58 RESP group: 0x02 data1: 0x00 data2: 0x00 data3: 0x00
01.7F.58 RESP group: 0x03 data1: 0x00 data2: 0x00 data3: 0x00
01.7F.58 RESP group: 0x04 data1: 0x00 data2: 0x00 data3: 0x00
01.7F.58 RESP group: 0x05 data1: 0x00 data2: 0x00 data3: 0x00
01.7F.58 RESP group: 0x06 data1: 0x00 data2: 0x00 data3: 0x00
01.7F.58 RESP group: 0x07 data1: 0x00 data2: 0x00 data3: 0x00
01.7F.58 RESP group: 0x08 data1: 0x00 data2: 0x00 data3: 0x00
01.7F.58 RESP group: 0x09 data1: 0x00 data2: 0x00 data3: 0x00
01.7F.58 RESP group: 0x0A data1: 0x00 data2: 0x00 data3: 0x00
01.7F.58 RESP group: 0x0B data1: 0x00 data2: 0x00 data3: 0x00
01.7F.58 RESP group: 0x0C data1: 0x00 data2: 0x00 data3: 0x00
01.7F.58 RESP group: 0x0D data1: 0x00 data2: 0x00 data3: 0x00
01.7F.58 RESP group: 0x0E data1: 0x00 data2: 0x00 data3: 0x00
01.7F.58 RESP group: 0x0F data1: 0x00 data2: 0x00 data3: 0x00
01.7F.58 RESP group: 0x10 data1: 0x00 data2: 0x00 data3: 0x00
01.7F.58 RESP group: 0x01 data1: 0x00 data2: 0x00 data3: 0x00
01.7F.58 RESP group: 0x02 data1: 0x00 data2: 0x00 data3: 0x00
01.7F.58 RESP group: 0x03 data1: 0x00 data2: 0x00 data3: 0x00
01.7F.58 RESP group: 0x04 data1: 0x00 data2: 0x00 data3: 0x00
01.7F.58 RESP group: 0x05 data1: 0x00 data2: 0x00 data3: 0x00
01.7F.58 RESP group: 0x06 data1: 0x00 data2: 0x00 data3: 0x00
01.7F.58 RESP group: 0x07 data1: 0x00 data2: 0x00 data3: 0x00
01.7F.58 RESP group: 0x08 data1: 0x00 data2: 0x00 data3: 0x00
01.7F.58 RESP group: 0x09 data1: 0x00 data2: 0x00 data3: 0x00
01.7F.58 RESP group: 0x0A data1: 0x00 data2: 0x00 data3: 0x00
01.7F.58 RESP group: 0x0B data1: 0x00 data2: 0x00 data3: 0x00
01.7F.58 RESP group: 0x0C data1: 0x00 data2: 0x00 data3: 0x00
01.7F.58 RESP group: 0x0D data1: 0x00 data2: 0x00 data3: 0x00
01.7F.58 RESP group: 0x0E data1: 0x00 data2: 0x00 data3: 0x00
01.7F.58 RESP group: 0x0F data1: 0x00 data2: 0x00 data3: 0x00
01.7F.58 RESP group: 0x10 data1: 0x00 data2: 0x00 data3: 0x00

—again 21 copies of the above total, followed by one new record—

01.7F.58 CTRL group: 0x00 data1: 0x03 data2: 0x0D data3: 0x1C

The log file contained:

2025-02-02 14:44:58.810 OUT:Cmd:0x62|toAddress:01.7F.58|messageFlags:0x0F=DIRECT:3:3|command1:0x09|command2:0x01|
2025-02-02 14:44:58.828 IN:Cmd:0x62|toAddress:01.7F.58|messageFlags:0x0F=DIRECT:3:3|command1:0x09|command2:0x01|ACK/NACK:0x06|
2025-02-02 14:44:59.180 IN:Cmd:0x50|fromAddress:01.7F.58|toAddress:41.EF.97|messageFlags:0x2B=ACK_OF_DIRECT:2:3|command1:0x09|command2:0x01|
2025-02-02 14:46:14.082 OUT:Cmd:0x62|toAddress:01.7F.58|messageFlags:0x0F=DIRECT:3:3|command1:0x09|command2:0x00|
2025-02-02 14:46:14.095 IN:Cmd:0x62|toAddress:01.7F.58|messageFlags:0x0F=DIRECT:3:3|command1:0x09|command2:0x00|ACK/NACK:0x06|
2025-02-02 14:46:14.448 IN:Cmd:0x50|fromAddress:01.7F.58|toAddress:41.EF.97|messageFlags:0x2B=ACK_OF_DIRECT:2:3|command1:0x09|command2:0x00|

He could do this using a legacy device where you chose the device type manually. Did I see each X10 device then corresponds to a different group? I’m not sure which device currently in the DB would be able to handle this. I guess we’d have to create a new device type. I had also been wondering if it makes sense give the user to select a device type manually (for the new, non legacy devices too) if it can’t pull down the device type programmatically. Fro example when users have some flaky devices this might help.

1 Like

You can’t have the legacy and the new implementation running at the same. So if going legacy, all your other devices will need to be configured using the legacy implementation.

A new device type would need to be created as well to monitor all the different event groups coming from that device.

I thought about it. I could add configurable device and sub category parameters. But this would only get over the first hurdle. The binding will keep trying to poll and download the device database after that. Ultimately the device status would end up showing as offline. So, there would be some work involved to get the binding to support such use case.

As far as the flaky devices use case, I may consider adding the override parameters but the whole point of the caching feature is that the device information only need to be loaded once and then the binding can keep using the cached information going forward.

How does MisterHouse identify your device? Did you configure it?

I expected that these responder links would be in place but I wasn’t sure because your PLM could have been in monitor mode and these wouldn’t have been necessary for the event from that device to be picked up by the modem. That’s why I added the “if” comments.

This means the cross link was added. Your device should respond to commands now. Can you run the previous test?

# Start monitoring
insteon debug startMonitoring 01.7F.58
# Send product id request
insteon debug sendStandardMessage 01.7F.58 10 00
# Send code record read request
insteon debug sendStandardMessage 01.7F.58 F1 00
# Stop monitoring
insteon debug stopMonitoring 01.7F.58

In the narrow case of the EZX10RF, as far as I know all it can send is ON, OFF, and brightness adjustments (e.g. “BRIGHTER”, “DIMMER”). For that, we could treat it as a bridge and each of the 20 possible groups as dimmer switches attached to it.

Alternatively, the EZX10RF could be a thing of it’s own. Then one can write rules whenever it triggers, assessing which of its group codes fired and what command they received. That’s how my MQTT listener works.

I’m too much of an OH noob to know if any of that is workable or not, but maybe there’s something useful in there for the people that do know.

How does MisterHouse identify your device? Did you configure it?

The EZX10RF assigns an available but predictable group to an X10 device. Then I trigger the X10 device and check the logs to see which group code it sent. The mappings are constant until the EZX10RF is reprogrammed, so it’s just a matter of finding the mapping the first time. All incoming messages are from the EZX10RF Insteon device code, but with individual group codes attached.

This means the cross link was added. Your device should respond to commands now. Can you run the previous test?

Here the console:

openhab> insteon debug startMonitoring 01.7F.58                                                                                                                                             
insteon debug startMonitoring 01.7F.58
Started monitoring the device 01.7F.58.
Message events logged in /var/lib/openhab/insteon/messageEvents-017F58.log
openhab> insteon debug sendStandardMessage 01.75.58 10 00                                                                                                                                   
insteon debug sendStandardMessage 01.75.58 10 00
Direct message sent to device 01.75.58.
OUT:Cmd:0x62|toAddress:01.75.58|messageFlags:0x0F=DIRECT:3:3|command1:0x10|command2:0x00|
openhab> insteon debug sendStandardMessage 01.7F.58 F1 00                                                                                                                                   
insteon debug sendStandardMessage 01.7F.58 F1 00
Direct message sent to device 01.7F.58.
OUT:Cmd:0x62|toAddress:01.7F.58|messageFlags:0x0F=DIRECT:3:3|command1:0xF1|command2:0x00|
openhab> insteon debug stopMonitoring 01.7F.58                                                                                                                                              
insteon debug stopMonitoring 01.7F.58
Stopped monitoring the device 01.7F.58.

Here’s the log file:

2025-02-02 19:01:23.834 OUT:Cmd:0x62|toAddress:01.7F.58|messageFlags:0x0F=DIRECT:3:3|command1:0xF1|command2:0x00|
2025-02-02 19:01:23.860 IN:Cmd:0x62|toAddress:01.7F.58|messageFlags:0x0F=DIRECT:3:3|command1:0xF1|command2:0x00|ACK/NACK:0x06|
2025-02-02 19:01:25.076 IN:Cmd:0x50|fromAddress:01.7F.58|toAddress:41.EF.97|messageFlags:0x23=ACK_OF_DIRECT:0:3|command1:0xF1|command2:0x00|

The logs look truncated. It’s missing the first message. That’s the important one. Messages could have been sent out of sequence if you run the command close to each other. Maybe wait a bit before issuing the stop monitoring command.

I thought that looked too short. Here’s the log from the retest:

2025-02-02 20:52:43.974 OUT:Cmd:0x62|toAddress:01.7F.58|messageFlags:0x0F=DIRECT:3:3|command1:0x10|command2:0x00|
2025-02-02 20:52:43.988 IN:Cmd:0x62|toAddress:01.7F.58|messageFlags:0x0F=DIRECT:3:3|command1:0x10|command2:0x00|ACK/NACK:0x06|
2025-02-02 20:52:44.371 IN:Cmd:0x50|fromAddress:01.7F.58|toAddress:41.EF.97|messageFlags:0x2B=ACK_OF_DIRECT:2:3|command1:0x10|command2:0x00|
2025-02-02 20:53:11.161 OUT:Cmd:0x62|toAddress:01.7F.58|messageFlags:0x0F=DIRECT:3:3|command1:0xF1|command2:0x00|
2025-02-02 20:53:11.183 IN:Cmd:0x62|toAddress:01.7F.58|messageFlags:0x0F=DIRECT:3:3|command1:0xF1|command2:0x00|ACK/NACK:0x06|
2025-02-02 20:53:11.535 IN:Cmd:0x50|fromAddress:01.7F.58|toAddress:41.EF.97|messageFlags:0x2B=ACK_OF_DIRECT:2:3|command1:0xF1|command2:0x00|

It seems that the cross-link didn’t work after all since the device is still not responding to command requests. The new record on the modem side may be an artifact. Can you reload the modem database and see if you still see the new record?

# Reload modem database
insteon modem reloadDatabase
# Confirm if the controller record is still available (wait until the database is fully loaded)
insteon modem listDatabase --records | grep 01.7F.58 | grep CTRL

Nope. It was gone. So I went through the linking process again, immediately followed by the two commands you are looking for. Here’s the console log:

openhab> insteon modem reloadDatabase
Reloading all-link database for modem 41.EF.97.
openhab> insteon modem listDatabase --records | grep 01.7F.58 | grep CTRL
openhab> insteon debug startMonitoring 01.7F.58
Started monitoring the device 01.7F.58.
Message events logged in /var/lib/openhab/insteon/messageEvents-017F58.log
openhab> insteon debug sendIMMessage StartALLLinking 00 01                                                                                                                                  
Not ready to send messages yet.
openhab> insteon debug sendIMMessage StartALLLinking 00 01                                                                                                                                  
IM message sent to the modem.
OUT:Cmd:0x64|LinkCode:0x00|ALLLinkGroup:0x01|
openhab> insteon debug sendStandardMessage 01.7F.58 09 01                                                                                                                                   
Direct message sent to device 01.7F.58.
OUT:Cmd:0x62|toAddress:01.7F.58|messageFlags:0x0F=DIRECT:3:3|command1:0x09|command2:0x01|
openhab> insteon debug sendIMMessage StartALLLinking 01 00                                                                                                                                  
IM message sent to the modem.
OUT:Cmd:0x64|LinkCode:0x01|ALLLinkGroup:0x00|
openhab> insteon debug sendStandardMessage 01.7F.58 09 0                                                                                                                                    
Direct message sent to device 01.7F.58.
OUT:Cmd:0x62|toAddress:01.7F.58|messageFlags:0x0F=DIRECT:3:3|command1:0x09|command2:0x00|
openhab> insteon debug sendIMMessage CancelALLLinking                                                                                                                                       
IM message sent to the modem.
OUT:Cmd:0x65|
openhab> insteon modem reloadDatabase
Reloading all-link database for modem 41.EF.97.
openhab> insteon modem listDatabase --records | grep 01.7F.58 | grep CTRL
openhab> insteon modem listDatabase --records | grep 01.7F.58 | grep CTRL                                                                                                                   
01.7F.58 CTRL group: 0x00 data1: 0x03 data2: 0x0D data3: 0x1C
openhab> insteon debug sendStandardMessage 01.7F.58 10 00                                                                                                                                   
Direct message sent to device 01.7F.58.
OUT:Cmd:0x62|toAddress:01.7F.58|messageFlags:0x0F=DIRECT:3:3|command1:0x10|command2:0x00|
openhab> insteon debug sendStandardMessage 01.7F.58 F1 00                                                                                                                                   
Direct message sent to device 01.7F.58.
OUT:Cmd:0x62|toAddress:01.7F.58|messageFlags:0x0F=DIRECT:3:3|command1:0xF1|command2:0x00|
openhab> insteon debug stopMonitoring 01.7F.58                                                                                                                                              
Stopped monitoring the device 01.7F.58.

And here’s the debug log:

2025-02-03 09:28:37.023 IN:Cmd:0x50|fromAddress:01.7F.58|toAddress:41.EF.97|messageFlags:0x2B=ACK_OF_DIRECT:2:3|command1:0x10|command2:0x00|
2025-02-03 09:28:37.231 IN:Cmd:0x50|fromAddress:01.7F.58|toAddress:03.0D.1C|messageFlags:0x8B=BROADCAST:2:3|command1:0x01|command2:0x00|
2025-02-03 09:30:07.775 OUT:Cmd:0x62|toAddress:01.7F.58|messageFlags:0x0F=DIRECT:3:3|command1:0x09|command2:0x01|
2025-02-03 09:30:07.793 IN:Cmd:0x62|toAddress:01.7F.58|messageFlags:0x0F=DIRECT:3:3|command1:0x09|command2:0x01|ACK/NACK:0x06|
2025-02-03 09:30:08.144 IN:Cmd:0x50|fromAddress:01.7F.58|toAddress:41.EF.97|messageFlags:0x2B=ACK_OF_DIRECT:2:3|command1:0x09|command2:0x01|
2025-02-03 09:30:48.810 OUT:Cmd:0x62|toAddress:01.7F.58|messageFlags:0x0F=DIRECT:3:3|command1:0x09|command2:0x00|
2025-02-03 09:30:48.827 IN:Cmd:0x62|toAddress:01.7F.58|messageFlags:0x0F=DIRECT:3:3|command1:0x09|command2:0x00|ACK/NACK:0x06|
2025-02-03 09:30:49.178 IN:Cmd:0x50|fromAddress:01.7F.58|toAddress:41.EF.97|messageFlags:0x2B=ACK_OF_DIRECT:2:3|command1:0x09|command2:0x00|

I think you ran the list database records too fast. The error indicates that the database wasn’t loaded yet.

This looks promising. The device responded to a product id request prior to you issuing the linking commands. I suspect your device has the proper device information listed under the thing property. Maybe the device is far away from your PLM?

Geographically, they’re about 10 feet apart. Powerline-wise, they’re on different circuits of the same phase, so maybe 60-80 feet of powerline total between the two outlets and the power panel.

The thing properties are:

    productId               0x03 0x0D
    firmwareVersion         0x1C
    modelId                 EZX10RF
    hardwareVersion         0xFF
    serialNumber            017F58
    vendor                  Compacta

If that’s what you were looking for, those properties have been populated for a long time. Oops.

I was referring to that distance. Depending on how old is your electric system, it can impact the communication where messages aren’t reliably sent between the two devices. In your case, I think the issue is that you were sending two messages at the same time most likely preventing the device to respond to the product id request.

That’s good news as I can add support for that device since the binding can identify it. Can you run the following commands? I need to determine if the database is retrievable.

# Start monitoring
insteon debug startMonitoring 01.7F.58
# Get insteon engine version
insteon debug sendStandardMessage 01.7F.58 0D 00
# Retrieve the first record bytes @ 0x00FF from the device database
# Set MSB to 0x00
insteon debug sendStandardMessage 01.7F.58 28 00
# Peek 8 bytes 0xF8-FF
insteon debug sendStandardMessage 01.7F.58 2B FF
insteon debug sendStandardMessage 01.7F.58 2B FE
insteon debug sendStandardMessage 01.7F.58 2B FD
insteon debug sendStandardMessage 01.7F.58 2B FC
insteon debug sendStandardMessage 01.7F.58 2B FB
insteon debug sendStandardMessage 01.7F.58 2B FA
insteon debug sendStandardMessage 01.7F.58 2B F9
insteon debug sendStandardMessage 01.7F.58 2B F8
# Stop monitoring
insteon debug stopMonitoring 01.7F.58

Very good. Here’s the console log…

openhab> insteon debug startMonitoring 01.7F.58                                                                                                                                             
Started monitoring the device 01.7F.58.
Message events logged in /var/lib/openhab/insteon/messageEvents-017F58.log
openhab> insteon debug sendStandardMessage 01.7F.58 0D 00                                                                                                                                   
Direct message sent to device 01.7F.58.
OUT:Cmd:0x62|toAddress:01.7F.58|messageFlags:0x0F=DIRECT:3:3|command1:0x0D|command2:0x00|
openhab> insteon debug sendStandardMessage 01.7F.58 28 00                                                                                                                                   
Direct message sent to device 01.7F.58.
OUT:Cmd:0x62|toAddress:01.7F.58|messageFlags:0x0F=DIRECT:3:3|command1:0x28|command2:0x00|
openhab> insteon debug sendStandardMessage 01.7F.58 2B FF                                                                                                                                   
Direct message sent to device 01.7F.58.
OUT:Cmd:0x62|toAddress:01.7F.58|messageFlags:0x0F=DIRECT:3:3|command1:0x2B|command2:0xFF|
openhab> insteon debug sendStandardMessage 01.7F.58 2B FE
Direct message sent to device 01.7F.58.
OUT:Cmd:0x62|toAddress:01.7F.58|messageFlags:0x0F=DIRECT:3:3|command1:0x2B|command2:0xFE|
openhab> insteon debug sendStandardMessage 01.7F.58 2B FD
Direct message sent to device 01.7F.58.
OUT:Cmd:0x62|toAddress:01.7F.58|messageFlags:0x0F=DIRECT:3:3|command1:0x2B|command2:0xFD|
openhab> insteon debug sendStandardMessage 01.7F.58 2B FC
Direct message sent to device 01.7F.58.
OUT:Cmd:0x62|toAddress:01.7F.58|messageFlags:0x0F=DIRECT:3:3|command1:0x2B|command2:0xFC|
openhab> insteon debug sendStandardMessage 01.7F.58 2B FB
Direct message sent to device 01.7F.58.
OUT:Cmd:0x62|toAddress:01.7F.58|messageFlags:0x0F=DIRECT:3:3|command1:0x2B|command2:0xFB|
openhab> insteon debug sendStandardMessage 01.7F.58 2B FA
Direct message sent to device 01.7F.58.
OUT:Cmd:0x62|toAddress:01.7F.58|messageFlags:0x0F=DIRECT:3:3|command1:0x2B|command2:0xFA|
openhab> insteon debug sendStandardMessage 01.7F.58 2B F9
Direct message sent to device 01.7F.58.
OUT:Cmd:0x62|toAddress:01.7F.58|messageFlags:0x0F=DIRECT:3:3|command1:0x2B|command2:0xF9|
openhab> insteon debug sendStandardMessage 01.7F.58 2B F8
Direct message sent to device 01.7F.58.
OUT:Cmd:0x62|toAddress:01.7F.58|messageFlags:0x0F=DIRECT:3:3|command1:0x2B|command2:0xF8|
openhab> insteon debug stopMonitoring 01.7F.58                                                                                                                                              
Stopped monitoring the device 01.7F.58.
openhab>                           

And here’s the debug log…

2025-02-03 15:26:42.051 OUT:Cmd:0x62|toAddress:01.7F.58|messageFlags:0x0F=DIRECT:3:3|command1:0x0D|command2:0x00|
2025-02-03 15:26:42.078 IN:Cmd:0x62|toAddress:01.7F.58|messageFlags:0x0F=DIRECT:3:3|command1:0x0D|command2:0x00|ACK/NACK:0x06|
2025-02-03 15:26:42.430 IN:Cmd:0x50|fromAddress:01.7F.58|toAddress:41.EF.97|messageFlags:0x2B=ACK_OF_DIRECT:2:3|command1:0x0D|command2:0x01|
2025-02-03 15:27:10.831 OUT:Cmd:0x62|toAddress:01.7F.58|messageFlags:0x0F=DIRECT:3:3|command1:0x28|command2:0x00|
2025-02-03 15:27:10.842 IN:Cmd:0x62|toAddress:01.7F.58|messageFlags:0x0F=DIRECT:3:3|command1:0x28|command2:0x00|ACK/NACK:0x06|
2025-02-03 15:27:11.194 IN:Cmd:0x50|fromAddress:01.7F.58|toAddress:41.EF.97|messageFlags:0x2B=ACK_OF_DIRECT:2:3|command1:0x28|command2:0x00|
2025-02-03 15:27:37.899 OUT:Cmd:0x62|toAddress:01.7F.58|messageFlags:0x0F=DIRECT:3:3|command1:0x2B|command2:0xFF|
2025-02-03 15:27:37.909 IN:Cmd:0x62|toAddress:01.7F.58|messageFlags:0x0F=DIRECT:3:3|command1:0x2B|command2:0xFF|ACK/NACK:0x06|
2025-02-03 15:27:38.261 IN:Cmd:0x50|fromAddress:01.7F.58|toAddress:41.EF.97|messageFlags:0x2B=ACK_OF_DIRECT:2:3|command1:0x2B|command2:0x00|
2025-02-03 15:27:52.798 OUT:Cmd:0x62|toAddress:01.7F.58|messageFlags:0x0F=DIRECT:3:3|command1:0x2B|command2:0xFE|
2025-02-03 15:27:52.818 IN:Cmd:0x62|toAddress:01.7F.58|messageFlags:0x0F=DIRECT:3:3|command1:0x2B|command2:0xFE|ACK/NACK:0x06|
2025-02-03 15:27:58.677 OUT:Cmd:0x62|toAddress:01.7F.58|messageFlags:0x0F=DIRECT:3:3|command1:0x2B|command2:0xFD|
2025-02-03 15:28:02.497 IN:Cmd:0x62|toAddress:01.7F.58|messageFlags:0x0F=DIRECT:3:3|command1:0x2B|command2:0xFD|ACK/NACK:0x06|
2025-02-03 15:28:02.900 IN:Cmd:0x62|toAddress:01.7F.58|messageFlags:0x0F=DIRECT:3:3|command1:0x2B|command2:0xFD|ACK/NACK:0x06|
2025-02-03 15:28:03.100 IN:Cmd:0x50|fromAddress:01.7F.58|toAddress:41.EF.97|messageFlags:0x2B=ACK_OF_DIRECT:2:3|command1:0x2B|command2:0x00|
2025-02-03 15:28:03.101 IN:Cmd:0x62|toAddress:01.7F.58|messageFlags:0x0F=DIRECT:3:3|command1:0x2B|command2:0xFD|ACK/NACK:0x06|
2025-02-03 15:28:03.102 IN:Cmd:0x62|toAddress:01.7F.58|messageFlags:0x0F=DIRECT:3:3|command1:0x2B|command2:0xFD|ACK/NACK:0x06|
2025-02-03 15:28:03.103 IN:Cmd:0x50|fromAddress:01.7F.58|toAddress:41.EF.97|messageFlags:0x2B=ACK_OF_DIRECT:2:3|command1:0x2B|command2:0x00|
2025-02-03 15:28:03.105 IN:Cmd:0x62|toAddress:01.7F.58|messageFlags:0x0F=DIRECT:3:3|command1:0x2B|command2:0xFD|ACK/NACK:0x06|
2025-02-03 15:28:03.106 IN:Cmd:0x50|fromAddress:01.7F.58|toAddress:41.EF.97|messageFlags:0x2B=ACK_OF_DIRECT:2:3|command1:0x2B|command2:0x00|
2025-02-03 15:28:03.520 IN:Cmd:0x50|fromAddress:01.7F.58|toAddress:41.EF.97|messageFlags:0x2B=ACK_OF_DIRECT:2:3|command1:0x2B|command2:0x00|
2025-02-03 15:28:04.116 OUT:Cmd:0x62|toAddress:01.7F.58|messageFlags:0x0F=DIRECT:3:3|command1:0x2B|command2:0xFC|
2025-02-03 15:28:04.128 IN:Cmd:0x62|toAddress:01.7F.58|messageFlags:0x0F=DIRECT:3:3|command1:0x2B|command2:0xFC|ACK/NACK:0x06|
2025-02-03 15:28:04.496 IN:Cmd:0x50|fromAddress:01.7F.58|toAddress:41.EF.97|messageFlags:0x2B=ACK_OF_DIRECT:2:3|command1:0x2B|command2:0x11|
2025-02-03 15:28:09.300 OUT:Cmd:0x62|toAddress:01.7F.58|messageFlags:0x0F=DIRECT:3:3|command1:0x2B|command2:0xFB|
2025-02-03 15:28:09.327 IN:Cmd:0x62|toAddress:01.7F.58|messageFlags:0x0F=DIRECT:3:3|command1:0x2B|command2:0xFB|ACK/NACK:0x06|
2025-02-03 15:28:09.760 IN:Cmd:0x50|fromAddress:01.7F.58|toAddress:41.EF.97|messageFlags:0x2B=ACK_OF_DIRECT:2:3|command1:0x2B|command2:0x01|
2025-02-03 15:28:12.668 OUT:Cmd:0x62|toAddress:01.7F.58|messageFlags:0x0F=DIRECT:3:3|command1:0x2B|command2:0xFA|
2025-02-03 15:28:14.798 IN:Cmd:0x62|toAddress:01.7F.58|messageFlags:0x0F=DIRECT:3:3|command1:0x2B|command2:0xFA|ACK/NACK:0x06|
2025-02-03 15:28:15.983 IN:Cmd:0x50|fromAddress:01.7F.58|toAddress:41.EF.97|messageFlags:0x2B=ACK_OF_DIRECT:2:3|command1:0x2B|command2:0x00|
2025-02-03 15:28:18.082 OUT:Cmd:0x62|toAddress:01.7F.58|messageFlags:0x0F=DIRECT:3:3|command1:0x2B|command2:0xF9|
2025-02-03 15:28:18.109 IN:Cmd:0x62|toAddress:01.7F.58|messageFlags:0x0F=DIRECT:3:3|command1:0x2B|command2:0xF9|ACK/NACK:0x06|
2025-02-03 15:28:18.478 IN:Cmd:0x50|fromAddress:01.7F.58|toAddress:41.EF.97|messageFlags:0x2B=ACK_OF_DIRECT:2:3|command1:0x2B|command2:0x76|
2025-02-03 15:28:23.153 OUT:Cmd:0x62|toAddress:01.7F.58|messageFlags:0x0F=DIRECT:3:3|command1:0x2B|command2:0xF8|
2025-02-03 15:28:23.164 IN:Cmd:0x62|toAddress:01.7F.58|messageFlags:0x0F=DIRECT:3:3|command1:0x2B|command2:0xF8|ACK/NACK:0x06|
2025-02-03 15:28:24.412 IN:Cmd:0x50|fromAddress:01.7F.58|toAddress:41.EF.97|messageFlags:0x2B=ACK_OF_DIRECT:2:3|command1:0x2B|command2:0xC0|
root@haserver:/etc/systemd/system# 

Interesting, it’s using Insteon engine I2. That’s more recent than I would have thought such device would be. It should support the new way to download the database.

# Start monitoring
insteon debug startMonitoring 01.7F.58
# Get all link records
insteon debug sendExtendedMessage 2F 00
# Wait a few minutes for all the database record messages to be received
# Stop monitoring
insteon debug stopMonitoring 01.7F.58

This doesn’t look promising. Console:

openhab> insteon debug startMonitoring 01.7F.58                                                                                                                                             
Started monitoring the device 01.7F.58.
Message events logged in /var/lib/openhab/insteon/messageEvents-017F58.log
openhab> insteon debug sendExtendedMessage 2F 00                                                                                                                                            
Usage: openhab:insteon debug sendExtendedMessage <address> <cmd1> <cmd2> [<data1> ... <data13>] - send an Insteon extended message with standard crc to a device
openhab> insteon debug sendExtendedMessage 01.7F.58 2F 00                                                                                                                                   
Direct message sent to device 01.7F.58.
OUT:Cmd:0x62|toAddress:01.7F.58|messageFlags:0x1F=DIRECT:3:3|command1:0x2F|command2:0x00|userData1:0x00|userData2:0x00|userData3:0x00|userData4:0x00|userData5:0x00|userData6:0x00|userData7:0x00|userData8:0x00|userData9:0x00|userData10:0x00|userData11:0x00|userData12:0x00|userData13:0x00|userData14:0xD1|

Waited 3 minutes here, but tailing the debug log I could see nothing was happening.

openhab> insteon debug stopMonitoring 01.7F.58                                                                                                                                              
Stopped monitoring the device 01.7F.58.

The debug log:

2025-02-03 16:26:06.075 OUT:Cmd:0x62|toAddress:01.7F.58|messageFlags:0x1F=DIRECT:3:3|command1:0x2F|command2:0x00|userData1:0x00|userData2:0x00|userData3:0x00|userData4:0x00|userData5:0x00|userData6:0x00|userData7:0x00|userData8:0x00|userData9:0x00|userData10:0x00|userData11:0x00|userData12:0x00|userData13:0x00|userData14:0xD1|
2025-02-03 16:26:06.104 IN:Cmd:0x62|toAddress:01.7F.58|messageFlags:0x1F=DIRECT:3:3|command1:0x2F|command2:0x00|userData1:0x00|userData2:0x00|userData3:0x00|userData4:0x00|userData5:0x00|userData6:0x00|userData7:0x00|userData8:0x00|userData9:0x00|userData10:0x00|userData11:0x00|userData12:0x00|userData13:0x00|userData14:0xD1|ACK/NACK:0x06|

I just reran that test again, and got a little more. I sent the extended message twice, with several minutes inbetween, in case it was a matter of needing time to populate. Interestingly, I received less log output from the second command than the first.

Recall also that I’m transferring control of the PLM from MisterHouse to OH to run these tests. If you think I need more time after enabling the PLM on OH for something to populate before I send the command, please let me know how much time and I can run it again.

In any case, here’s the console log:

openhab> insteon debug startMonitoring 01.7F.58
Started monitoring the device 01.7F.58.
Message events logged in /var/lib/openhab/insteon/messageEvents-017F58.log
openhab> insteon debug sendExtendedMessage 01.7F.58 2F 00
Direct message sent to device 01.7F.58.
OUT:Cmd:0x62|toAddress:01.7F.58|messageFlags:0x1F=DIRECT:3:3|command1:0x2F|command2:0x00|userData1:0x00|userData2:0x00|userData3:0x00|userData4:0x00|userData5:0x00|userData6:0x00|userData7:0x00|userData8:0x00|userData9:0x00|userData10:0x00|userData11:0x00|userData12:0x00|userData13:0x00|userData14:0xD1|
openhab>                                                                                                                                                                                    
openhab>                                                                                                                                                                                    
openhab> insteon debug sendExtendedMessage 01.7F.58 2F 00                                                                                                                                   
Direct message sent to device 01.7F.58.
OUT:Cmd:0x62|toAddress:01.7F.58|messageFlags:0x1F=DIRECT:3:3|command1:0x2F|command2:0x00|userData1:0x00|userData2:0x00|userData3:0x00|userData4:0x00|userData5:0x00|userData6:0x00|userData7:0x00|userData8:0x00|userData9:0x00|userData10:0x00|userData11:0x00|userData12:0x00|userData13:0x00|userData14:0xD1|
openhab> insteon debug stopMonitoring 01.7F.58
Stopped monitoring the device 01.7F.58.

And here’s the debug log:

2025-02-06 08:52:52.835 OUT:Cmd:0x62|toAddress:01.7F.58|messageFlags:0x1F=DIRECT:3:3|command1:0x2F|command2:0x00|userData1:0x00|userData2:0x00|userData3:0x00|userData4:0x00|userData5:0x00|userData6:0x00|userData7:0x00|userData8:0x00|userData9:0x00|userData10:0x00|userData11:0x00|userData12:0x00|userData13:0x00|userData14:0xD1|
2025-02-06 08:52:55.056 IN:Cmd:0x62|toAddress:01.7F.58|messageFlags:0x1F=DIRECT:3:3|command1:0x2F|command2:0x00|userData1:0x00|userData2:0x00|userData3:0x00|userData4:0x00|userData5:0x00|userData6:0x00|userData7:0x00|userData8:0x00|userData9:0x00|userData10:0x00|userData11:0x00|userData12:0x00|userData13:0x00|userData14:0xD1|ACK/NACK:0x06|
2025-02-06 08:52:55.261 IN:Cmd:0x62|toAddress:01.7F.58|messageFlags:0x1F=DIRECT:3:3|command1:0x2F|command2:0x00|userData1:0x00|userData2:0x00|userData3:0x00|userData4:0x00|userData5:0x00|userData6:0x00|userData7:0x00|userData8:0x00|userData9:0x00|userData10:0x00|userData11:0x00|userData12:0x00|userData13:0x00|userData14:0xD1|ACK/NACK:0x06|
2025-02-06 08:52:55.266 IN:Cmd:0x62|toAddress:01.7F.58|messageFlags:0x1F=DIRECT:3:3|command1:0x2F|command2:0x00|userData1:0x00|userData2:0x00|userData3:0x00|userData4:0x00|userData5:0x00|userData6:0x00|userData7:0x00|userData8:0x00|userData9:0x00|userData10:0x00|userData11:0x00|userData12:0x00|userData13:0x00|userData14:0xD1|ACK/NACK:0x06|
2025-02-06 08:52:55.270 IN:Cmd:0x50|fromAddress:01.7F.58|toAddress:41.EF.97|messageFlags:0x2B=ACK_OF_DIRECT:2:3|command1:0x2F|command2:0x00|
2025-02-06 08:52:55.273 IN:Cmd:0x50|fromAddress:01.7F.58|toAddress:41.EF.97|messageFlags:0x23=ACK_OF_DIRECT:0:3|command1:0x2F|command2:0x00|
2025-02-06 08:52:55.277 IN:Cmd:0x62|toAddress:01.7F.58|messageFlags:0x1F=DIRECT:3:3|command1:0x2F|command2:0x00|userData1:0x00|userData2:0x00|userData3:0x00|userData4:0x00|userData5:0x00|userData6:0x00|userData7:0x00|userData8:0x00|userData9:0x00|userData10:0x00|userData11:0x00|userData12:0x00|userData13:0x00|userData14:0xD1|ACK/NACK:0x06|
2025-02-06 08:52:55.282 IN:Cmd:0x62|toAddress:01.7F.58|messageFlags:0x1F=DIRECT:3:3|command1:0x2F|command2:0x00|userData1:0x00|userData2:0x00|userData3:0x00|userData4:0x00|userData5:0x00|userData6:0x00|userData7:0x00|userData8:0x00|userData9:0x00|userData10:0x00|userData11:0x00|userData12:0x00|userData13:0x00|userData14:0xD1|ACK/NACK:0x06|
2025-02-06 08:52:55.423 IN:Cmd:0x50|fromAddress:01.7F.58|toAddress:41.EF.97|messageFlags:0x2B=ACK_OF_DIRECT:2:3|command1:0x2F|command2:0x00|
2025-02-06 08:52:56.096 IN:Cmd:0x50|fromAddress:01.7F.58|toAddress:41.EF.97|messageFlags:0x2B=ACK_OF_DIRECT:2:3|command1:0x2F|command2:0x00|

[pause for a few minutes]

2025-02-06 08:59:16.263 OUT:Cmd:0x62|toAddress:01.7F.58|messageFlags:0x1F=DIRECT:3:3|command1:0x2F|command2:0x00|userData1:0x00|userData2:0x00|userData3:0x00|userData4:0x00|userData5:0x00|userData6:0x00|userData7:0x00|userData8:0x00|userData9:0x00|userData10:0x00|userData11:0x00|userData12:0x00|userData13:0x00|userData14:0xD1|
2025-02-06 08:59:16.290 IN:Cmd:0x62|toAddress:01.7F.58|messageFlags:0x1F=DIRECT:3:3|command1:0x2F|command2:0x00|userData1:0x00|userData2:0x00|userData3:0x00|userData4:0x00|userData5:0x00|userData6:0x00|userData7:0x00|userData8:0x00|userData9:0x00|userData10:0x00|userData11:0x00|userData12:0x00|userData13:0x00|userData14:0xD1|ACK/NACK:0x06|
2025-02-06 08:59:16.864 IN:Cmd:0x50|fromAddress:01.7F.58|toAddress:41.EF.97|messageFlags:0x2B=ACK_OF_DIRECT:2:3|command1:0x2F|command2:0x00|

Thanks. The device is acknowledging the commands but it is not sending the records. Probably need to fallback to the old method. The test you ran previously wasn’t conclusive as it seems you didn’t leave enough time between command to allow your device to respond. It could also be that the communication between between your device and PLM is that great.

As long as you don’t have two applications connected to your PLM, it should be fine.

Just to make sure I run the test correctly, is this what you want me to rerun:

# Start monitoring
insteon debug startMonitoring 01.7F.58
# Get insteon engine version
insteon debug sendStandardMessage 01.7F.58 0D 00
# Retrieve the first record bytes @ 0x00FF from the device database
# Set MSB to 0x00
insteon debug sendStandardMessage 01.7F.58 28 00
# Peek 8 bytes 0xF8-FF
insteon debug sendStandardMessage 01.7F.58 2B FF
insteon debug sendStandardMessage 01.7F.58 2B FE
insteon debug sendStandardMessage 01.7F.58 2B FD
insteon debug sendStandardMessage 01.7F.58 2B FC
insteon debug sendStandardMessage 01.7F.58 2B FB
insteon debug sendStandardMessage 01.7F.58 2B FA
insteon debug sendStandardMessage 01.7F.58 2B F9
insteon debug sendStandardMessage 01.7F.58 2B F8
# Stop monitoring
insteon debug stopMonitoring 01.7F.58

And as for timing, how much time between commands, and how much time after the last one until I turn off monitoring? I’m afraid I don’t know what I should be looking for to know when it’s done responding to a command.