Understood, but using your device 24.F2.7E as an example, I don’t think local key press events would be picked up by the modem (unless you have monitor mode enabled on your PLM). Only commands can be sent from the modem to that device, based the links in your modem database. Anyway, I don’t recommend using the addMissingLinks command at the moment as I need to release a fix.
Thanks for providing that information. To be clear, the modem database records for that device are downloaded consistently but it’s the product information that isn’t. On the first load, the product request timed out while on the second one, it got a response. I will look to add some retry logic.
From the logs you provided, I was able to confirm that monitor mode is enable on your PLM. This explains why your modem picked up these events. I will add this condition to the missing links determination logic.
2025-01-11 07:37:54.013 [DEBUG] [ternal.device.feature.MessageHandler] - IMConfigMsgHandler: IM monitorMode is ON
For reference: “In Monitor Mode, the IM will also notify the host of received INSTEON messages that contain a From Address matching any INSTEON ID in the IM’s ALL-Link Database, even if the To Address does not match the IM’s INSTEON ID or the IM does not belong to an ALL-Link Group associated with the message. In other words, if the message originator is in the IM’s ALL-Link Database as either a Controller or Responder, the IM will pass the message to the host even if it is not specifically directed to the IM. In this way you can monitor messages between other INSTEON devices as long as the sender is in the IM’s ALL-Link Database.”
I am not sure if you had the chance to run this test.
I just uploaded a new beta release build including the fix for missing links. This includes trying to get product data, during the modem database loading process, up to 3 times before giving up, considering the monitor mode state to determine which links are missing in the modem database, and allowing default link data3 (component id) mismatch on device that only have one component. I would expect no missing links for your device 24.F2.7E.
I started from scratch again, and this appears to solve the problem I had with random devices staying in CONFIGUATION_PENDING state during initial configuration of the plm.
Yes, I don’t see any for 24.F2.7E, but I’m getting missing links for a couple other devices:
Here you go, the devices have been giving faulty data for awhile and haven’t used them for awhile. I just plugged them in to see how they would behave with your version of the binding.
I’m now seeing intermittent COMMUNICATION_ERROR for devices after I restart OH. Initially, all devices show up ONLINE. I enabled TRACE logs and when I restarted, none of the things are loading in the OH UI, it’s keeps showing loading… and is flashing. I stopped OH after 6 minutes. I shared the logs with you.
Using the data returned by the device, the energy and power are reported as negative values. Although I would still expect values to be published, 0 kWh and -7W.
