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.

If I simply unplug the network cable, the MEM and ERROR lights blink steadily. That is not the behavior I was observing previously, where the flashing of the lights seemed to be traffic-dependent. Anyway, I tried replacing the cable, not really expecting it to make any difference. But ... it did! No more flashing of ERROR during startup, and the Error Log reports "-170001 [Network] Established" instead of "-100 No network connection". I switched between good and bad cables several times and the problem definitely followed the cable. I then noticed that with the bad cable, one of the green lights at the connector does not turn on, although the other light still flashes when there is network traffic. With the good cable, the former light is on solidly. Not sure exactly what this means. It's curious that my PC can still communicate with the ISY, even with the bad cable. Perhaps the data link operates in some degraded mode. I checked the continuity of the cable and it is OK; perhaps a connector is flaky or something. Anyway, it is going right into the trash. Thank you for your help. I learn something new every day.

When I turn on my ISY-99i/IR Pro, I see the following sequence of lights on the ISY status panel: For 30 seconds or so, TX, RX, and MEM are on almost continuously. I assume that this is while the ISY is querying the status of all of the Insteon devices. After that, MEM and ERROR flash slowly (about every 2 seconds), along with slight flickering of TX and RX. This repeats maybe 20 times. This is not a regular blinking; it is irregular, as if it is accompanying some communication activity. After this, the light show ceases. The Quick Start Guide at the Wiki states that MEM and ERROR blinking means that there is no network connectivity. But, in fact, I can connect to the ISY from my PC, and the ISY can access the Internet just fine for things like NTP and MobiLinc Connect. (I have incoming Internet access disabled.) The Log shows Start followed by a flurry of Insteon Queries. The Error Log shows "-5 Start" followed by "-100 No network connection" 4 seconds later. No other error messages. I don't know what to make of this, since there clearly is a network connection and it is working. (By the way, codes -5 and -100 don't seem to be documented.) Just wondering what this all means and whether there is anything to be concerned about.

I thought about possible firewall or antivirus issues, but, as you say, the intermittent nature of the problem would seem to rule them out. I will continue to look into it, though. As it turns out, there is another thread that already discusses the same issue: http://forum.universal-devices.com/viewtopic.php?f=27&t=9883. In that thread, there was a speculation that the problem was introduced in a recent beta release of the firmware. But I am observing it in the released 3.2.6 firmware. Anyway, that thread gave some suggestions of other things to investigate. I will follow up and report on anything that I find. Thank you for your help.

Not sure what you mean by "the last two icons on the right". Are you talking about the system status bar at the bottom, where Ready / System Busy appear? If so, I see no other icons. If these icons are in some other place, please tell me where to look. My ISY is an ISY-99i/IR Pro, if that is what you mean by "Pro version". Repeatedly restarting the Admin Console does eventually resolve the problem, after an unpredictable number of tries. Looking at the system status bar has revealed another clue. When the Admin Console is behaving normally, the system status flips momentarily to System Busy and then back to Ready whenever I invoke a command. When the Admin Console is behaving abnormally, the status stays continuously Ready. I have discovered one other interesting clue. I also have the MobiLinc Portal integration installed, so that I can access the ISY from a smart phone running MobiLinc. When the Admin Console is behaving normally, MobiLinc works fine. When the Admin Console is behaving abnormally, MobiLinc fails to display any device status. This suggests that some process in the ISY is failing to serve up device status to network clients, whether the client be the Admin Console or MobiLinc. This is in spite of the fact that device status is known internally and is available to a web browser client.

I have occasionally encountered a strange communication problem between the ISY-99i and the Administrative Console. When started up, the Admin Console fails to display the status of any device, either in the My Lighting summary or in the individual device screens. When I issue On and Off commands from the Admin Console, the devices respond correctly, but their status still doesn't show up on the screen. No error messages appear on the screen or in any log file. The ISY itself is functioning normally -- timers, programs, etc., execute as they should. Furthermore, if I connect to the ISY with my browser and look at Devices or Scenes, the device status is displayed correctly. It is only the Admin Console that is having a problem. This problem occurs only upon startup of the Admin Console. It is an all-or-nothing thing -- either none of the devices or all of the devices have their status displayed. Once it has been started and has successfully displayed status of the devices, it works solidly during sessions lasting hours or days. This suggests to me that there is a software or configuration problem affecting the startup of communication between the ISY and the Java-based Admin Console running on my PC. When this happens, I have tried many things -- restarted the ISY and PLM, cleared the Java cache, restarted my PC, etc. Eventually, the problem goes away, but not as a result of any particular action. Details: ISY-99i/IR Pro running firmware 3.2.6. Java Runtime is current (1.7 and 1.6 installed). PC runs Windows 7 x64 SP1. I'm open to suggestions about how to troubleshoot this problem next time it occurs.