RemoteLinc 2440's really not working with eisy

[Frank_YYZ]

A previous post described some issues users had with the Model 2440 RemoteLinc after upgrading to the eisy.

https://forum.universal-devices.com/topic/42484-remote-linc-2440/#comment-375646

However, this post doesn't solve my situation.

I have six Model 2440 RemoteLincs of various F/W revs.  (1xV.33, 2xV.35, 3xV.7C)  Before upgrading to the eisy, I had a couple of units that simply wouldn't update with my isy994 , but the other 4 updated fine.  (I was running isy994 V4.8.x  All six units used to update fine using older isy FW.) 

I am now running an eisy (v5.8.3)  with a brand new USB 2413U PLM. (V9E).

My six controllers can still control most of my scenes, although they will always report back with a flashing LED status after every keypress since they are still trying to communicate with the old isy994 serial PLM that no longer exists!  All of my old 2440's have transmitters that work perfectly since they can control scenes from quite a distance.

The eisy can program all of my other wireless devices. (2x2342 remotes, 1x2843 open/close sensors, 6x2852 Water Sensors) whether they are located right beside the PLM or across the house near a dual-band device. (A 2635 ON/OFF module). 

But whenever I try to either Restore or Write Updates to a RemoteLinc, it makes a half hearted attempt to write the first link and then quietly stops without any sort of error message.  (The "Writing" icons simply switch back from green to gray.

I have tried the following:

1) Replacing the 1.2 V rechargeable batteries with new 1.5 volt batteries in case it was a signal strength issue.  No change.   (I should note that I've used 1.2 volt rechargeable AAA cells in these remotes for 16 years with no problems.)

2) Placing the 2440's directly beside my dual-band PLM.  (At various distances.)  I even unplugged all of the dual band devices near the PLM in case the repeated RF signals were causing confusion.  I normally program my wireless devices across the house, near my PC and close to a dual-band device.  This used to work for all wireless devices.  It still works for everything except the Model 440 remotes.

I'm reluctant try to delete and re-add one of these remotes from scratch .  This would remove a lot of the links in my wired devices that still allow my existing remotes to control some of my scenes, rendering them completely useless.

I believe that this is a SW issue with the Insteon module in the eisy, but would like to try any suggestions before I start a ticket.

Frank

 

[Brian H]

Long shot but what I found maybe a small help.

I found with mine I had similar issues with an ISY994i. In my case I had to move the 2440 to the other side of the house. So that it  had to go through a dual band modules RF receiver and did not directly go through the PLM's RF receiver connected to the ISY994i.

Glad yours still are working. All of mine have died and are ready for the electronic recycling bin.

Edited June 16 by Brian H

[Frank_YYZ]

Hi Brian,

Weirdly, I had the opposite effect here.  With my old isy994i, I had a slightly easier time programming my 2440's when I placed them close to the isy's PLM.  But since my upgrade, I've tried both the direct PLM approach (using my new USB PLM) and placing them next to a remote dual-band device.

Nothing works.  As I mentioned, the eisy simply gives up while trying to write the first link without any sort of error message.

Unless anyone else has had success, it's time to contact support.

Frank

 

[Brian H]

Support sounds like  way to go. If no other ideas are given.

It may help if you can do a few tests with the Event Viewer at Level 3. That may give us information. That would help users here and UDI Support Ticket team.

Edited June 17 by Brian H
Add a thought

[Frank_YYZ]

Great idea.  I created a log and sent it to support. (Also included, below.)

Don't junk your RemoteLincs just yet, in case they come up with a fix.  Maybe I'm old fashioned, but I really like these older remotes.  Good range.  Large enough to not be easily lost between the seat cushions.  Easy to prepare a fancy label so you know what the six buttons do.  And all six of them still worked reliably after more than a decade.

By the way, here is the Level 3 Event log.  I tried to do a full RESTORE.  Then a WRITE UPDATES.  Both failed really quickly, with no error message.  (The address of my Remotelinc is 0A.1F.56 )

 

Mon 06/17/2024 10:53:22 : [VAR  2    1     ]       82

Mon 06/17/2024 10:53:30 : [INST-TX-I1  ] 02 62 0A 1F 56 0F 0D 00

Mon 06/17/2024 10:53:30 : [INST-ACK    ] 02 62 0A.1F.56 0F 0D 00 06                 (00)

Mon 06/17/2024 10:53:39 : [INST-TX-I1  ] 02 62 0A 1F 56 0F 0D 00

Mon 06/17/2024 10:53:39 : [INST-ACK    ] 02 62 0A.1F.56 0F 0D 00 06                 (00)

Mon 06/17/2024 10:53:48 : [INST-TX-I1  ] 02 62 0A 1F 56 0F 0D 00

Mon 06/17/2024 10:53:48 : [INST-ACK    ] 02 62 0A.1F.56 0F 0D 00 06                 (00)

Mon 06/17/2024 10:54:09 : [INST-TX-I1  ] 02 62 0A 1F 56 0F 0D 00

Mon 06/17/2024 10:54:09 : [INST-ACK    ] 02 62 0A.1F.56 0F 0D 00 06                 (00)

Mon 06/17/2024 10:54:18 : [INST-TX-I1  ] 02 62 0A 1F 56 0F 0D 00

Mon 06/17/2024 10:54:18 : [INST-ACK    ] 02 62 0A.1F.56 0F 0D 00 06                 (00)

Mon 06/17/2024 10:54:20 : [VAR  2    1     ]       81

Mon 06/17/2024 10:54:27 : [INST-TX-I1  ] 02 62 0A 1F 56 0F 0D 00

Mon 06/17/2024 10:54:27 : [INST-ACK    ] 02 62 0A.1F.56 0F 0D 00 06                 (00)

[Brian H]

Gee I thought my Developers Group information was forgotten.  😀 The viewer output.

Shows the PLM being told to send a command to the RemoteLinc's ID and the PLM acknowledged the request as a valid command and it was sent. It does not show any returned message from the RemoteLinc back to the PLM. Looks like the  command for the module to report its Insteon Engine version.

INSTEON Engine Version command (0x0D) will return 0x02 in cmd2 for I2CS.
0x00 = I1 INSTEON device
0x01 = I2 INSTEON device
0x02 = I2CS enabled device
NAK 0xFF = I2CS enabled device and sender ID not in responder dB

Maybe it did not reply, the message was not received by an Insteon RF device [PLM or dual band module], the message was sent to the PLM and it was ignored.

Mine are dead not just problems programming them.

Edited June 17 by Brian H
Add Information

[Brian H]

I made an error. I have four in total.

I have one 2440 and 2440BK that have dead buttons. Also one 2440 and 2440BK in a storage box. Both of the 2440BK unit with the nice black coating. Have gotten a very sticky coating on them. I have other devices like a Comcast remote and a wireless temperature reader that also have similar sticky surface. All made in China. 😁

[Brian H]

Firmware v5.3.4. Add a RemoteLink choice in the drop down list. Automatic writes to RF devices not turned on.

Here is a RemoteLink added to my ISY994i. Got what you got when it was near the PLM. Was OK at the other end of the house next to a Access Point. Notice the modules [INST-SRX] replies to the communications from the PLM. Original V1.0 RemoteLink Firmware V.33. I forgot the enable automatic writes to an RF device so it ended up writes pending.

 

RemoteLink.txt

Edited June 18 by Brian H

[xlurkr]

I don't have any original RemoteLincs to test with anymore, but the last time I tried to link them my experience was exactly like Brian H described.  I had to go out to the courtyard of my condo about 50-100ft from the PLM.  I recommend trying to link/update far away from the PLM's wireless reach, at the perimeter of the entire wireless range reachable by your dualband devices.

-Tom

 

p.s. I also had the sticky coating problem.  It happened to several other handheld remote devices from other companies, about the same time.  That sucked.

 

[Frank_YYZ]

I sent in a request to Support@.....  and this is what I got back. (See below.)

I will send in an official ticket after I've spent some time doing further testing.  I unearthed some older posts (dating back to 2020!) that show that this issue was affecting the 2440 back in the isy days.  Seems odd that the 2440 will only accept programming commands from a remote dual-band device, not from any PLM.

The unusual thing below is the statement that the 2440 should be placed into "multi-link" mode (fast flashing) rather than normal link mode.  There is no indication on how to do this in the 2440 manual.  Or anywhere else that I could find.  Simply pressing the DIM - BRIGHT buttons again, or each individually, doesn't work.  (It exits Link mode.)  However, by futzing around with one of my units, I somehow got it into a state where I had a fast flashing LED. (The LED was on 95% of the time.)  I have no idea how to replicate this!

I was well away from the PLM and managed to get it to accept all 17 links.  It took most of an afternoon, since it would only program one or two links before bombing out.  (I used multiple "Write Updates to Device" operations.)  The interesting thing is that, when the 2440 timed out, pressing DIM-BRIGHT caused it to reenter this fast flashing mode!  I verified the links using the "Show Device Links Table" with the Start option to verify one or two links at a time.

No luck replicating this with any of my other units yet.  But I learned long ago that writing/verifying links has to be done during the day when most of my LED/CFL lights are off and there is little background Insteon traffic.

Frank,

 -- Response from UD --

Thank you for the details. Please note:

1. We never use the forum for details. Too many exchanges cause more confusion
2. In order to better serve you, you must submit a ticket: https://www.universal-devices.com/my-tickets
3. If you have changed your PLM, I suspect you have green/gray 1011 icons next to your RemoteLincs. What you need to do is to put them in programming mode (Press/hold till blinks. Click again till it blinks faster) and then right mouse click | Write updates to device.

 

[Brian H]

That information on the added click for a faster LED blinking. Manual indicates that is the multi-linking mode. That may stop it from timing out while programming it. Though my full users manual has no mention of it but mine is one of the oldest age and firmware wise.

Edited June 19 by Brian H
change a statement