eataft

Today, one of my Insteon KPLs failed and I needed to replace it. This is something I have done successfully many times before. When I went to update the configuration in Admin Console, I discovered that the right-click menu for the old device is missing the "Replace <device> with..." command. It is supposed to be immediately below the "Restore Device", but it is just not there. Upon further investigation, I discovered that this problem occurs for ALL existing devices in my system! However, the "Replace <device> with..." command IS present for the new device that I just installed and linked. Of course, having it on that device doesn't do me any good. Thinking back to recent change that I had made, I remembered that I moved all of my Insteon devices from My Lighting into a Devices folder in Admin Console. (This was recommended in these forums to allow easier navigation of folders and scenes in UD Mobile.) So, I tried removing the device I was trying to replace from its folder, so that it reappears in My Lighting. Sure enough, the "Replace <device> with..." command reappeared for that device. It appears that it isn't possible to replace a device that is in a folder. This seems like a bug to me. But if there is a reason for it, perhaps the "Replace <device> with..." command should still be present in this situation, but leading to an alert saying that it's necessary to remove the device from its folder before replacing it.

I moved all the "My Lighting" devices to a Devices folder. That worked great and it solved my problem. Thank you.

That is not what I am seeing. I have moved all the scenes into a Scenes folder. But the devices are already in a My Lighting folder. This is how it appears in Admin Console when the folders are collapsed: That is approximately what I formerly saw in MobiLinc. But in UD Mobile, My Devices opens the entire list of devices, with the Scenes folder at the very end of the list (as if it were one of the devices). There doesn't appear to be a way to collapse the list of devices to replicate what I see in Admin Console. ("My Lighting" is something that was created automatically when I first set up my system over a decade ago. It has been migrated through three generations of ISYs.)

I recently switched from MobiLinc to UD Mobile, following a migration of my system from ISY-994i to eISY. Overall, UD Mobile is a huge improvement in functionality and reliability. However, I have noticed one significant inconvenience. On the Home screen, the My Devices button opens a single list of all the Devices followed by all the Scenes. To reach the Scenes, I need to scroll through a long list of Devices. This is a nuisance for accessing a Scene that I haven't previously designated as a Favorite. MobiLinc had separate buttons for accessing Devices and accessing Scenes. I don't see any way to do that in UD Mobile. I thought to group Scenes into a Folder, then designate the Folder as a Favorite. Unfortunately, it seems that there is no way to designate an existing Folder as a Favorite; only individual Devices and Scenes can be designated as Favorites. There IS a way to create a Favorite of type "Folder", but there doesn't seem to be a way to place more than one node in this Folder. Also, this Folder doesn't seem to correspond to anything I can see or manipulate in the ISY Admin Console, so this approach would be a maintenance headache as Scenes are added and removed. I don't understand the purpose of this feature, but it doesn't seem relevant to my need to access the list of Scenes directly. Unless there's existing feature that I'm missing, I suggest that UD mobile should have (1) separate access to Devices and Scenes from the Home screen, and (2) a way to designate an existing Folder as a Favorite.

Sorry about that -- I'm still learning how to include attachments.

Here is a screen shot. If this is not what you want to see, please tell me what to do.

Here is a photo, showing the incorrect label and my hand-scribbled correction.

I have four old RemoteLinc 2s (2444A2), three of which the ISY994i programmed successfully but one refused to program. The symptom was "Cannot determine Insteon engine". This device worked fine for manual linking, but the ISY994i could not communicate with it. Eventually, I determined that the address label on the back of the device was incorrect. It said 1C.1F.0E, but the correct address was 1C.1E.0E. Once I entered the correct address, everything worked fine. (There was another post in the UDI forums with a similar finding. Incorrect address labels on Insteon devices may be a more common problem than people realize. Perhaps this should be added as a troubleshooting tip.) I have two questions: 1. What is the easiest way to find out a device's actual address? The way I did it was to manually link it to another device, then to read out the other device's link table using the ISY Admin's diagnostic tool. Is there a better way? 2. The message "Cannot determine Insteon engine" has got to be the most obscure way of saying that the ISY simply can't communicate with the device. There is even a YouTube video by a UDI engineer acknowledging this. Can the message be changed? As it stands now, the message seems to indicate some obscure compatibility issue, rather than outright inability to communicate.

In past couple of months, I have twice needed to replace a failed KPL (6 or 8 button). Each time the ISY's Replace Device procedure did not work correctly on the first try. Here is what I did: 1. Installed the new KPL. 2. Put Admin Console into linking mode to discover the new device -- success. 3. Invoked Replace Device function to replace the old device with the new one. 4. Admin Console was busy for several minutes, writing to devices. (This KPL has links to many, many devices.) 5. Admin Console exited on its own (as the instructions say it will). 6. I restarted Admin Console and observed that all of the buttons for the old device had been changed to refer to the new device. So far, so good. But then: 7. Admin Console spontaneously resumed being busy for several more minutes, writing to devices. 8. When things finally went quiet, I tested the new KPL. Nothing worked -- not even the on-off for the KPL's own load. 9. To recover from this, I invoked Restore Device on the new KPL. 10. Now the KPL functioned correctly. So, I am back in business now. Clearly, all of the links for the new device had been correctly recorded in the ISY and in other devices, but they were not successfully written into the newly installed device. This was corrected by manually invoking Restore Device. Is the Replace Device procedure supposed to complete before the Admin Console exits, or is there supposed to be more work to do after Admin Console restarts? The instructions on the UDI wiki make no mention of the latter behavior, so perhaps it is a sign of trouble. Not sure what I might have done to cause this, though. Also, just out of curiosity, why does the Admin Console need to exit as part of the Replace Device procedure?

My ISY994i is plugged into a UPS, but the PLM is plugged into a dedicated circuit without a UPS. As the installation instructions recommend, the PLM isn't behind a UPS, since that would block the PLM's power-line signaling to other Insteon devices. When a power failure occurs, the ISY remains up, but the PLM goes down until the power is restored. After that, I sometimes find that the ISY has lost contact with the PLM, or at least it has lost the ability to control Insteon devices or track their status. I need to restart both the ISY and the PLM to restore normal operation. Since the PLM also has RF capability, I wonder if the power-line signaling from the PLM is really all that important. Would it make sense to plug the PLM into the UPS and to depend on RF connectivity to nearby AccessPoints and dual-band Insteon devices? I would be interested to hear if other people have tried this and if there are any pitfalls to keep in mind.

Michel, Thank you for the definitive answer. It is interesting that you found that sending scenes from the PLM worked poorly. It seems that we are dealing with a PLM deficiency more than an ISY deficiency. My PLM is on a dedicated circuit and it has RF connectivity to AccessPoints on each phase of every sub-panel in my home. I've experimented with moving it to other places and it made no difference. The real issue in my network is that occasional Insteon messages are lost due to interference. Scenes initiated from a KPL are reliable, in spite of the interference, because the KPL retries lost commands. Scenes initiated from the PLM are not reliable, because lost commands are not retried. I don't really know the source of the interference, but I suspect that it is a combination of things that together are degrading the signal to noise ratio for Insteon powerline communication. CFL and LED lights are high on my list of suspects; I've noticed a gradual decrease in reliability as I've installed more of them in place of incandescents. Ultimately, I suspect that the only solution will be to replace all of my Insteon powerline devices with dual-band devices. Anyway, I do have a workaround (described in my earlier post) that seems to be effective.

LeeG, Thank you for describing in detail how a scene works. You have essentially confirmed my previous understanding, but I was unsure about what is done by the ISY and what is done by the PLM. You have clarified the picture there. What I think you are saying is that if the ISY commands the PLM to perform a Scene command, the PLM becomes busy until all devices have acknowledged the Group Cleanup messages (or have timed out). This could tie up the PLM for quite some time and would delay subsequent ISY activities. I can see that this would be a real problem for a scene that includes many devices. But for a scene that includes only a few devices, the time required for the PLM to perform the scene protocol is comparable to the time to perform direct commands to the devices -- a few seconds at most. This seems as if it should be manageable. I wonder if it would be possible for the ISY to provide an option to issue a Scene instead of a Group Broadcast in select cases -- say, for specific scenes that I designate, or for all scenes that are smaller than a certain threshold number of devices, or something like that. This would be a great help in my situation, where there are only certain scenes that are troublesome. It would be a lot cleaner and less clunky than my current workaround, which is to follow each scene command with direct commands to the individual devices in order to ensure that they respond. Can someone at UDI say if this idea would be practical to include in a future firmware release? On a related matter, I think that the ISY documentation could be a lot better on this matter. It was very puzzling to me -- and I'm sure to lots of other people -- why scenes invoked from the ISY are unreliable, even though the same scenes invoked from a KPL are reliable. It is especially misleading that the ISY log file shows that the devices in the scene changed status, when in fact the ISY has no way of knowing what the status of those devices is.

Based on my limited understanding of the Insteon protocol, the way scenes work is: 1. The controller issues a scene command, which normally all responders act upon immediately. 2. The controller issues a "group cleanup" command to each responder in turn. The responder acknowledges this to report whether it acted upon the scene command. (I'm not sure what is the remedial action if the responder missed the scene command.) This protocol has the benefit that scene commands ordinarily take effect immediately. But if a responder missed the scene command, the "group cleanup" phase of the protocol takes care of the problem eventually. This combines the immediacy of a scene with the reliability of a sequence of direct commands. When I asked "why the ISY doesn't retry scene commands", I really meant to ask "why the ISY doesn't follow the regular Insteon protocol for issuing scene commands reliably". I have employed the workaround of creating ISY programs to issue a scene command followed by direct commands to the devices in the scene. But this seems rather clunky and really shouldn't be necessary if the ISY were following the normal Insteon scene protocol in the first place.

Glad I discovered this post, because it sheds light on a matter that has long puzzled me. I have a large home whose electrical system is noisy, not to mention having another power-line communication system using it. Consequently, it is understandable that occasional Insteon commands will be lost and need to be retried. I am depending on the Insteon protocol to achieve reliability in this environment. Scene commands sent from KPLs work reliably. Occasionally, I notice a delay of a second or two after pressing a KPL button before the controlled device responds. I attribute this to a lost Insteon command that is automatically retried. In other words, the Insteon protocol is operating as designed. Scene commands sent from the ISY to certain devices do not work reliably. From this forum post (and others), I have learned that ISY scene commands are not retried, although direct commands are. In other words, Insteon is not working as designed when controlled from the ISY. Ideally, I would clean up my home power network so as to eliminate loss of Insteon commands, but this is easier said than done. I have replaced some Insteon devices with dual-band devices, but this has limited benefit for devices that are mounted in metal boxes. I have installed filters to eliminate the most obvious problems, but this becomes impractical to do everywhere as I replace incandescent lighting with CFLs and LEDs and as home electronics become more ubiquitous. The fact of the matter is that portions of my network are marginal, but they are well within the Insteon protocol's capabilities when it is being operated as designed. I am sure that many other people will encounter similar issues as they install more electronic devices in their homes. I am curious to learn why the ISY doesn't retry scene commands, as it does for direct device commands. I suspect that there is a concern about tying up the PLM for too long while checking the status of all devices in a large scene. But it would be useful for the ISY to provide an option to retry specific scenes, or to retry scenes only up to a certain size, or something of that sort.

Thank you for the offer, but it wasn't your cable. It was a bright yellow cable that I think came with a router.