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:
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.
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?
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.
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.
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
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.
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
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>
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
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.
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.