2487S no longer supported?

[Envirogreen]

I had two 2487s keypads, one of which I had to replace and during the reinstall I went into the drop down and no longer could find 2487s, used auto discover and its showing up as unsupported. I also found that my other 2487s is showing as not supported.

 

I'm sure I'm doing something wrong - is there something I need to do to get this to work properly?

[LeeG]

What does Help | About show for Firmware and UI levels.

 

What does the unsupported message show for the cat/subcat 2.xx?

 

The 2487s is listed in the 3.3.10 device type pulldown.

[Envirogreen]

v 3.3.9

unsupported device 2.44

 

I'll try updating to 3.3.10 and see if that helps

[LeeG]

I do not know why 3.3.9 would have dropped that device definition.

 

It is in 3.3.10 - 2.44 [02.2C]

[znuttyone]

had a similar experience.

 

Module: 944i

release: v3.3.8

 

Replace function does not work

Reproduction:

2473SWH/v4.9 removed to simulate bad unit

Add new 2473SWH with new address

Link to ISY, new unit shows up in console

Attempt to replace using replace function.

system will warn not to power off..

behavior:

newly discovered module will disappear in the console and old unit will remain in the console with no changes.

subsequently if you attempt to discover the module again, it will discover, but never shows up in the console again.

Now cannot get the new module to add, and the old module cannot be deleted, renamed.

[znuttyone]

Just updated to 3.3.10 , after the reboot, noticed a status window popped up with ISY attempting to write to the new module I had installed and discovered under 3.3.8, now the original named module was truly replaced and functions as expected. Not sure if this was some 3.3.8 issue or if it still exist in 3.3.10 and the reboot for the upgrade solved the problem.

[LeeG]

znuttyone

 

The steps described are what should happen except for the second part of the last item.

 

behavior:

newly discovered module will disappear in the console and old unit will remain in the console with no changes.

subsequently if you attempt to discover the module again, it will discover, but never shows up in the console again.

Now cannot get the new module to add, and the old module cannot be deleted, renamed.

 

The existing node, the one where the Replace xxxx with …. function is invoked against, is the node that should remain after the Replace completes. The idea is that the old node name remains, references to the old node name in Programs and Scenes remain unchanged. However, the Insteon address assigned to the old node name is changed to the new device Insteon address and the new device node is removed from the defined list of devices because two nodes cannot have the same Insteon address. The new device cannot be added to the ISY again after the Replace because the existing node definition in the ISY has been assigned the Insteon address of the new device.

 

Programs and Scenes and old node definition that may have existed for years continue to exist as before. Programs continue to reference the old node name, Scenes continue to reference the old node name, the only difference is the old node name has the Insteon address of the new device. If you click on the old node name the information in the right pane should show the Insteon address of the new device.

 

The part that is not normal is the old node name cannot be deleted, renamed. Unless there were pending updates that had not completed which were generated as a result of the Replace xxxx with …. function then certainly new changes would not be accepted/allowed until all the updates associated with the Replace completed. All link records with the old node Insteon address have to be updated with the Insteon address of the new device. This can take some time depending on how much linking the old node is associated with.

[znuttyone]

Your description of the expected behavior is what I would have expected. The deviation from this is that the named device address did not get changed and remained pointed to the address of the device that went bad, which seems to indicate that something went wrong and so there were pending updates that prevented any new changes to that named device.

Is there a log that you want to determine root cause?

[znuttyone]

BTW prior to replacing the old device I removed it from all scenes and controllers so timing should have been fast for the activities. I did wait for over ~10mins prior to giving up and upgrading.

 

I would like to see one or both of the following enhancements to allow users better understanding of what is occurring and self diagnostics.

 

1) a log that shows all events initiated and responses and or errors. Think Call stack with parameters passed to sub routines and response

2) better status displayed on device updates and completion that are being requested by ISY

[LeeG]

Not to question the conclusion but are you sure the old node name was not assigned the new address. Something must have been assigned the new address, otherwise that new address could be added to the ISY.

 

The Event Viewer would show “1)†if it had been running during the Replace xxxx with .....

 

It was not necessary to remove the old node name from Programs and Scenes. Now all Program and Scene changes have to be restored manually after the Replace. The idea behind Replace xxxx with .... is that none of that is necessary. There are link records not related to user defined Scenes that require changing. For “2)â€, pending changes would normally be noted by Green Icons to the left of affected nodes. These Green pending Icons change to Green updating Icons as updates to each node are being done.

 

EDIT: can you run a Show Device Links Table request against the old node name, Save the file which will be in XML tag format and copy/paste the XML lines to a post. The forum is not currently accepting images unless you can store the image somewhere else and post a link to the Show Device Links Table image.

[znuttyone]

Positive ,I was expecting it to change but it never did until after I upgraded and only after the reboot of ISY and restarting the console, at that point the writing device xx.xx.xx dialog came up which was the address of the new device, at that point when I checked the address associated with the named device I replaced, the address was changed from the old to the new.

 

Was not sure what the replace function would do, so I took precautions, on the next one will attempt without making changes to see the real benefit of the feature as I really like the design of the feature.

 

The console show now pending changes (writes) green icon.

The old device is no longer show anywhere in the console that i can see now that the replacement is complete.

[LeeG]

"Positive ,I was expecting it to change but it never did until after I upgraded and only after the reboot of ISY and restarting the console, at that point the writing device xx.xx.xx dialog came up which was the address of the new device, at that point when I checked the address associated with the named device I replaced, the address was changed from the old to the new."

 

Okay, thanks. Since the changes have completed with the reboot there is nothing to look back on. The Admin Console does close with a Replace xxxx with .... function. Otherwise there would be two device definitions with the same Insteon address. There is a popup that is now displayed describing the Admin Console shutdown as part of the Replace. The reboot of the ISY should not have been necessary. Perhaps there was an issue with the earlier image. I have run a Replace on the latest image with success.

[znuttyone]

I had not seen the event log, nice.

looks like it is of limited duration, seems to shows only 1 hour, is that expected?

[LeeG]

The event viewer should run for as long as the Admin Console session is up. The Admin Console subscription can be terminated do to time. If that happened no more events could be pushed out from the ISY to the Admin Console (event viewer) so it could look the event viewer has a limited on time. It does not unless it is something very new.

[znuttyone]

Ok, that explains it. So if you perform an upgrade of ISY from one version to the next and then viewed the event log you would only see the event since the reboot as you would need to establish a new console session.

 

Would be nice if this was persistent across console sessions.

 

It also would be nice to view the 'Tools/Log' and 'Tools/ Error Log', without the need to actually download it and open with separate viewer

[Envirogreen]

updated to 3.3.10 and issue resolved

[duderino]

I am new to ISY-99i and to INSTEON devices in general, so please go easy on me. I have been able to get all my 2477D dimmers working with my ISY-99i, but my 2487S isn't recognized. I also do NOT see it listed in the device pulldown despite my firmware being version v.3.3.10. I've also tried rebooting the system. When I add the device using the address and allowing auto discovery, it shows as "Unsupported Device:2.44". What am I missing?

 

From the About dialog:

Firmware: Insteon_UD994 v.3.3.10 ( 2013-01-17-01:13:50 )

UI: Insteon_UD99 v.3.2.6 ( 2012-05-04-00:26:24 )

Product: ISY 994i/IR PRO (1110) - Open-Auto-DR (21010)

 

 

Thanks for any insight you can offer me.

Ryan

[LeeG]

You have identified the problem with the Help | About information. The UI which is the Admin Console is still at 3.2.6 where the cat/subcat for the Dual Band 2487S did not exist. Thus the unsupported device message. Clear the Java cache and be sure the URL being used to invoke the Admin Console is for 3.3.10. Once Help | About shows 3.3.10 for the UI delete the device and add it back using the correct level of the Admin Console. It will be added as a supported device.

[duderino]

Thanks, that did the trick!

I was wondering about that, but didn't know how to update the UI part of the firmware.

 

Cheers,

Ryan