walkman9999

Just getting started with this, and following instructions found in the link below. The goal is to have both the EISY and the included z-wave remote control the blinds. I added the blinds to EISY and can control them as expected. I then followed the instructions to pair the Bali premium remote control to the EISY and this succeeded as well. Following the instructions, I then paired the remote control to the blinds which is successful. The remote works as expected until I use EISY to control the shade, at that point the remote stops being able to control the blinds while the EISY still can. [minor edit to describe things better] It is as if the blinds can only be paired to a single controller, although the link (and Bali's support folks) say otherwise. I'm looking for any insight into what I should be looking for, any tests that may show what is happening, or really a better understanding of the process (e.g., why does remote have to be paired to EISY?) Haven't found much in the forum, hoping someone has worked through this and can help. Attached is a screenshot of the EISY console. TY

Older, single-band devices and some noise on the wire contributed to this. The devices have been replaced and comms are as expected. TY @IndyMike for the decoding help, I've found the explanations useful in other troubleshooting of I1 vs I2 devices. Marking solved.

As suggested by replies, combination of bad programming, older devices, and a questionable PLM contributed to this problem. I can't say specifically which of the changes solved the problem, but it no longer exists. A smoking gun would have been nice, but marking solved as the troubleshooting was helpful. Thanks all.

Not sure if it is implemented, but it would be possible to use the MAC/Insteon ID to get a FW update to the devices. Wouldn't work over a WAN, but within the local network the capability is there. (I rarely get to offer any expertise, but network guy by trade.)

That is a great answer, thank you. I think what you've said, along with @lilyoyo1's point about the upgradability of the new platform makes the decision for me. Appreciate the feedback. And, removing ALL ON from the command suite is ultimately a good marketing move. That uncommanded command was responsible for giving home automation a bad rep in my fam.

Thanks, all for the opinions and info. Does anyone know if the powerline protocol has been updated, similar to the way it was updated between I1 and I2? I'm not an expert on this category, but I2 devices perform noticeably better in my somewhat noisy environment and any additional improvement would be a consideration for me. Thanks again for the input so far.

@IndyMike, all good info. Making suggested changes to simplify programs. I was wondering about the "Link for responder XX.XX.XX not found" as well. I tracked down the MAC/Insteon ID and restored both the device and the PLM, but still they persist. I believe all of the devices listed are KPLs if that sheds any light. Looking at any logs of what happens "on the wire" always yields a few mysteries (I'm a network guy). Found that all mysteries do not need to be solved so taking that approach. Appreciate the insight as always, will post back if anything interesting happens. Otherwise, I'll close the thread in a week or so.

Should have specified, I have EISY.

Hello - I'm replacing some non-dual-link switchlinks in my network and ran across two choices, wondering if anyone has any insight on differences? Possible shortcutting the assignment, I'm interested in the best comms for the devices (I2 was a huge improvement over I1 in my environment), but I'd like to match the style of the 2477D if comms are not significantly improved in the PS01. I read reviews on Insteon website, but I didn't find mention of any new protocols. Maybe I missed something. Is there a compelling reason to go with PS01 over 2477D? All opinions welcomed. TY!@

Keeping the thread updated. I have existing Insteon filters on both of the UPSs (+ the refrigerator), but it is clear that there is still a wireline problem. As @Techman and @IndyMike pointed out, the devices that are problematic to write to are older, single band devices. I can eventually get them restored, but it takes multiple tries to do so. Because I have so much invested in the system, I'm going to replace those devices. I will also follow the steps I've found listed in this forum to try to isolate the offending device(s). Unfortunately, I have a number of 12v/24v LED drivers that I suspect, but have no remediation for. Hopefully, the dual-band addition will be enough to restore reliable comms. Will report back. Thanks for help so far.

At this point, when I attempt to restore *any* device on my network, I eventually get a "Failed writing to Devices" error. I am not proficient at decoding the messages I see on the attached log, but it seems that things work until we get to the SET-MSB(OF) packets. I get same behavior when reading the device links table. I'm saying "things work" because the exchange of TX and RX messages seems quick, and generally at least one and usually two hops left. Attached is the restore of a switchlink that seemed to cruise along for two minutes until the "Failed to write" message appeared. I'm concerned that there may be a new intermittent source of interference on the network, but I'd like to get a more experienced opinion if anyone has one. TY -restore_switchlink-ISY-Events-Log.v5.8.4__Thu 2025.02.13 07.49.44.txt

Always appreciate this community, thank you. @IndyMike you are correct, the older device is the powerline only switch that I have a replacement for but have yet to replace, glad it is not the PLM. @oberkc, I will ID the specific devices that are misbehaving and restore them and report back. Thanks again for insight

I did. It went well for the most part, one powerline device didn't come back but I replaced it. Everything worked fine for about a week after the replacement.

Hello - Very reliable install went south a few weeks ago. Determined problem was a bad PLM. Replaced PLM and things went back to normal for about a week. Now I have a problem where when a scene is triggered, multiple devices that are not part of the scene are switched ON. This happens for two scenes in particular. Should note that these scenes have been part of my install for years. I thought maybe restore of the new PLM would help, but that ran into a "failed to write" error (see log: _restore-ISY-Events-Log.v5.8.4__Wed 2025.02.12 16.46.25.txt). I am able to download the links table, but not sure what it is telling me (file: PLM Links Table.v5.8.4__Wed 2025.02.12 16.57.37.xml). I also captured a log of the scene running and triggering the switchlinks that are not part of it (log: scene-trigger-ISY-Events-Log.v5.8.4__Wed 2025.02.12 16.46.49.txt). The programs are included as well, but I don't believe this is a programming problem - although I'm open-minded. One program has the IF and second one has the THEN. North Gate.v5.8.4__Wed 2025.02.12 16.59.01.iox -> _North Gate.v5.8.4__Wed 2025.02.12 16.59.16.iox Any help is appreciated. @IndyMike, you have been great at helping me understand the logs in the past. Maybe some insight? Thanks in any case. _restore-ISY-Events-Log.v5.8.4__Wed 2025.02.12 16.46.25.txt scene-trigger-ISY-Events-Log.v5.8.4__Wed 2025.02.12 16.46.49.txt PLM Links Table.v5.8.4__Wed 2025.02.12 16.57.37.xml North Gate.v5.8.4__Wed 2025.02.12 16.59.01.iox _North Gate.v5.8.4__Wed 2025.02.12 16.59.16.iox

This is very useful, TY! I've decided to replace the device with a dual-link model.

Hello - I have a previously working switchlink dimmer v.40 that will not accept updates from EISY. This occurred after PLM replacement, not sure if coincidence or not. I have tried hard reset. Logs are attached for an attempt to write to device, and separate log for attempt to restore device. Neither is successful, but it does seem to be some comms between EISY and the device (I think). Comms to other devices in same are seem to be healthy. Let me know if an more info needed to help diagnose. Any insight is appreciated. TY EDIT: attached log from device query _restore-ISY-Events-Log.v5.8.4__Sun 2025.02.09 14.12.35.txt _write-updates-ISY-Events-Log.v5.8.4__Sun 2025.02.09 14.13.38.txt _Query-ISY-Events-Log.v5.8.4__Sun 2025.02.09 14.28.42.txt

Thank you for the decode. Swapped out PLM and looking much better. I am having a problem with the link tables on two devices after the swap out, but working on troubleshooting and will post in new topic if needed.

Hi all, Existing install, having some intermittent problems that seem to point to PLM (device triggers do not reliably run programs all of a sudden, but comms see OK). The PLM shows connected and I can control devices using the admin console, but I cannot read the device links table from the PLM. I have a spare and am going to swap tomorrow. In the meantime, is there another test to check comms between the PLM and the EISY? TY

Tentative results seem to indicate that the the new KPL has solved the problem. There is still the matter of the other KPL that had similar symptoms, but that one is behaving lately. Acknowledging that there are some logical leaps that have to be taken to blame the KPL, but for now that is the conclusion. Thanks again @IndyMike for assist.

This is all great advice and there is a lot I can work with here. KPL is next (should be here in 5 days), and I'll put some of the easier things on this list into my "best practices" list. The workaround of writing until it "sticks" should make this operationally acceptable, especially since the switch and KPL commands seems to work fine for now and I don't change things often. Will report back on new KPL for closure. Really appreciate the knowledge transfer and targeted troubleshooting.

The electrical environment hasn't changed in any macro way, there is a chance that a new device has been plugged in outside of my control. Any suggestions for testing this theory? An unfriendly/noisy electrical environment seems difficult to fix. I have been considering purchasing a new KPL (if it doesn't help, having a spare seems like a good idea). Will post results of the swap once I receive it. Thanks for your continued input.

I am noticing that two other devices are having same problem (if I'm interpreting the logs correctly). Started yesterday with one of them (another KPL), and now today with a on/off switch (2477s). Logs are attached. The devices do write eventually, so far. Editing to add. During this fail to write event, controlling the device seems to work fine. I've attached second log showing comms during on/off. And, I can read device links tables from devices not affected without problems. ON-OFF-SWITCH-FAIL-ISY-Events-Log.v5.3.4__Thu 2024.05.23 08.14.47.txt ON-OFF-SUCCESS-ISY-Events-Log.v5.3.4__Thu 2024.05.23 08.23.31.txt

Thank you for the insight. This problem occurred when changing attributes to a scene that includes the KPL, but all comms to this KPL seem inconsistent (e.g. changing ramp rate also resulted in a comm failure, when I manually retried to write to device it was successful) Reading link table from the device was also problematic. First attempt retrieved 4 links and then failed. The second attempt (which is attached, along with comm log) failed entirely. I do not mind going thru process of factory reset/restore. Let me know if more testing would help before I do. Thanks again for taking a look. LINK-TABLE-READ - ISY-Events-Log.v5.3.4__Thu 2024.05.23 07.24.03.txt

Hi, I'm having sporadic problems with an existing/stable install. Two of my KPL devices are giving "failed to write" errors about 50% of the time. Subsequent attempts will often succeed (although sometimes it take a few). Other comms in network are fine. I've attached two logs, one with success and one with failure. Can anyone give insight? Edit: Should note: the KPLs work as expected as responders. TY NO-WORK-ISY-Events-Log.v5.3.4__Wed 2024.05.22 08.43.50.txt WORKS-ISY-Events-Log.v5.3.4__Wed 2024.05.22 08.44.42.txt

I can remove the device from the remote and pair with EISY. However, I then cannot pair with remote. I can remove/find in any order, but cannot pair to both devices. Looking at on-line z-wave reference docs, it looks like the primary controller need to "allow" the second controller. I'm at a crossroads, I do not want to give up the remote, it is the friendly way to control the blinds for guests, etc. And I do not want to give up EISY, but this seems to be the choice. Any EISY advice on "allowing" a secondary controller? Thanks