LeeG

I just tried that URL and it brought up the 2.8.10 Admin Console from the USI server. Takes a bit to come up since the entire Admin Console has to move over the internet but it does come up. Sounds like a DNS issue or maybe firewall issue. The URL is valid. Two attempts to update from 2.8.9 to 2.8.10 were unsuccessful until I used the URL to bring up the Admin Console before doing the Manual Update.

The file size error sounds like the download was not successful. There is this step f. Go to http://www.universal-devices.com/99i/2.8.10/admin.jnlp that I missed and found the 2.8.10 upgrade would not work unless the Admin Console was at the 2.8.10 level to invoke the Manual Update from .

matapan Invoke Tools | Diagnostics | Event Viewer selecting the Device Communications Events options. The X10 messages should be traced by the Event Viewer. If they are there then post the Program. If nothing shows in the Event Viewer the X10 signals are not making it to the ISY PLM. X10 devices are not defined. They will appear in the Event Viewer if the PLM is receiving them. Insteon Access Points do not couple X10 messages. Perhaps the X10 receiver is on the opposite 120V leg as the ISY PLM. Lee

MY MISTAKE Thanks again Brian! I did not run the 2.8.10 Admin Console to invoke the Manual Update option. Updated using an image I had already downloaded and it now shows 2.8.10. I did delete the Certificate again before invoking the 2.8.10 Admin Console (PER INSTRUCTIONS which I DID NOT FOLLOW). Michel Sorry to have wasted your time on a USER ERROR. .

The update does appear not to have worked as the Telnet information is from an older build. I'll download a third time. http://192.168.2.2>VE Product: (1050) ISY 99i 1024 IR App: Insteon_UD99 Platform: ISY-C-99 Version: 2.8.9 Build Date: 2010-12-17-16:19:00 Other Services: - Programs Enabled - IR Enabled http://192.168.2.2>

Michel There were two Certificates before doing first 2.8.10 update. I deleted both before doing first 2.8.10 update. When the About showed 2.8.9 after update I downloaded again into a different subdirectory and did another update. Both downloaded images look full size, 3.19 at download. File size on XP shows 3,270K for both images. The Java Cache was cleared after each 2.8.10 update. There is now one Certificate with the following Validity property .... [From] Lee

Upgraded from 2.8.9 to 2.8.10 twice, with a different 2.8.10 download image each time. Both updates worked as expected. Deleted the Certificates as instructed (thanks Brian!) and cleared Java Cache after each update. Ran Restore Devices for reasons having nothing to do with the 2.8.10 update. Worked perfectly. Only minor problem is the About says 2.8.9 after both updates, each with a different download image.

jerlands The Wait and Repeat change that assumption. Any time a Wait or Repeat is encountered the If condition can be evaluated such that the Then is repeated from the beginning (such as could happen with If Control On and another On command is received) or the remaining statements are not executed at all because the If has changed from True to False. That is why Programs with Wait and Repeat often have no If statements. Lee

The ISY User Guide indicates an SD card issue when the ERR LED is blinking. The SD card contains a file system with configuration information. The User Guide describes the process for installing a new SD card. Before doing that I would remove the ISY power, unplug the SD card completely and reinsert the card in its slot.

Steiga Do not reset the ISY. Right click on the top node of a device with the red ! and select "Write Updates to Device". Could take a few minutes depending on how much is pending. If it works for that device, do the same thing for the next. It sounds like the ISY lost communication with the PLM somewhere along the line or the PLM is hung up and not communicating with the powerline. If the Write updates does not work, power cycle the PLM and try again after a few minutes to give the PLM a chance to get back up completely. Lee

Jerlands I had not paid attention to it until Rand noted it in his post. The motion sensor waits 3.5 minutes from the last motion message before sending a dusk/dawn message. The motion Off occurred at 11:04:53 with the dusk/dawn message occurring at 11:08:27. The motion sensor had been under a desk lamp for much more than 3.5 minutes but sent the dusk/dawn Off message only after 3.5 minutes of NO motion messages. Thanks Rand. I’ve said this many times before, hardly a day goes by where I don’t learn something new. Wed 12/22/2010 11:04:53 AM : [iNST-SRX ] 02 50 13.F2.57 00.00.01 C7 13 01 LTOFFRR(01) Wed 12/22/2010 11:04:53 AM : [standard-Group][13.F2.57-->Group=1] Max Hops=3, Hops Left=1 Wed 12/22/2010 11:04:53 AM : Duplicate: ignored Wed 12/22/2010 11:04:53 AM : [iNST-SRX ] 02 50 13.F2.57 00.00.01 C7 13 01 LTOFFRR(01): Process Message: failed Wed 12/22/2010 11:04:53 AM : [standard-Group][13.F2.57-->Group=1] Max Hops=3, Hops Left=1 Wed 12/22/2010 11:04:53 AM : [iNST-SRX ] 02 50 13.F2.57 12.9F.E4 41 13 01 LTOFFRR(01) Wed 12/22/2010 11:04:53 AM : [standard-Cleanup][13.F2.57-->ISY/PLM Group=1] Max Hops=1, Hops Left=0 Wed 12/22/2010 11:08:27 AM : [iNST-SRX ] 02 50 13.F2.57 00.00.02 C7 13 02 LTOFFRR(02) Lee

jerlands You can see definitively whether the motion sensor is sending a dusk/dawn message by turning on the Event Viewer with the Device communications events option and watching for a Group 2 message from the motion sensor. The Group 2 message indicates a dusk/dawn ambient light level change. Wed 12/22/2010 11:08:27 AM : [iNST-SRX ] 02 50 13.F2.57 00.00.02 C7 13 02 LTOFFRR(02) Wed 12/22/2010 11:08:27 AM : [standard-Group][13.F2.57-->Group=2] Max Hops=3, Hops Left=1 Wed 12/22/2010 11:08:27 AM : Duplicate: ignored Wed 12/22/2010 11:08:27 AM : [iNST-SRX ] 02 50 13.F2.57 00.00.02 C7 13 02 LTOFFRR(02): Process Message: failed Wed 12/22/2010 11:08:27 AM : [standard-Group][13.F2.57-->Group=2] Max Hops=3, Hops Left=1 Wed 12/22/2010 11:08:27 AM : [iNST-SRX ] 02 50 13.F2.57 12.9F.E4 41 13 02 LTOFFRR(02) Wed 12/22/2010 11:08:27 AM : [standard-Cleanup][13.F2.57-->ISY/PLM Group=2] Max Hops=1, Hops Left=0 A snippet from my Event Trace showing Group 2 Off. That 3.5 minutes is an approx time. I would give it at 5 minutes before looking at a motion sensor problem. Lee

jerlands Stop rebooting. I don't know about the motion part but for sure it takes ~3.5 minutes of consistent ambient light before it will signal dusk/dawn. The motion sensor documents this characteristic so that car lights and such will not change the dusk/dawn state. I place mine face down and cover with a dark paper to test dusk/dawn. Placing in a drawer is also a good idea. Lee

The device status is cleared when upgrading to a new image. The motion sensor will have to signal a dusk or dawn message based on current ambient light versus the dusk/dawn light level setting before the ISY knows the dusk/dawn state. If the node does not yet show status the motion sensor has not crossed a dusk/dawn threshold. The motion sensor cannot be Queried because a battery device sleeps.

eitheta The ISY does not automatically poll devices. There is a Query command that can be issued by the Program to obtain the current status but this should not be necessary under normal conditions. The Control option is reacting to a specific command coming from the device. If the motion sensor was set to Occupancy mode where an On command is sent for each motion detected regardless of the timeout interval, every time the motion sensor detects motion and sends an On command the If condition is True and the Program runs. The Status option is True based on the status/state the ISY is keeping for the device. The If Status On becomes True when the motion sensor status/state changes to On. This remains True for as long as the motion sensor status/state is On. A Program that is triggered from an If Status On will run when the device status changes to On. Subsequent On commands from the device do not change the Status from On so the Program will not run on subsequent On commands. Of course other If conditions could cause the Program to run. I hope that explanation is accurate. I am sure someone will jump in with another perspective if what I said is thought to be wrong. Lee EDIT: A Controller sends a command to each Responder in the Scene. Each command must be ACKed by the Responder before the Controller moves to the next Responder. Example: KPL button C is a Controller SwitchLinc1 is a Responder SwitchLinc2 is a Responder When KPL button C is pressed On, the KPL sends a Group Broadcast message on the powerline which ALL devices normally receive. Any device which has a Responder link matching the Controller device address and Controller Group/Scene number react simultaneously. The Group Broadcast cannot be ACKed by any device as it is not sent to any specific device. The KPL then sends a Group Cleanup message to SwitchLinc1. SwitchLinc1 will/should send an ACK back to the KPL. Then the KPL will send a Group Cleanup to SwitchLinc2 which will/should send an ACK back to the KPL. All of this happens without ISY intervention.

wwat, Michel has indicated something happened during the download of the 2.8.9 image. It should be downloaded again and another update done. The About should indicate 2.8.9. Also be sure to clear the Java cache again after the next update. Lee

Schlyguy Thank you for the Event Viewer trace. It shows the ISY did what is expected for a PLM that is configured with the large memory to support 2000+ link records. However, the PLM firmware is operating as though the PLM has the small memory configuration. I do not understand how an EZIO6I purchased at the end of 2008 would have this PLM. Smartlabs did ship some of these PLMs as they were making the transition from small memory (417 link records) to large memory (2000+ link records) but the only time I have encountered one was a device purchased in 2007. The PLM firmware will have to be reflashed. SHN offers this service which will update the EZIO6I firmware and the PLM firmware to the latest level. The Input status is not being updated in real time because the link records written by the ISY are not active as far as the EZIO6I internal PLM is concerned. Lee

Schlyguy That should have worked. I hate to do this but I need to see the command sequence and results when the EZIO6I is added to the ISY. Delete the EZIO6I from the ISY, start the Event Viewer with Device Communications events option set. Now add the EZIO6I using the New INSTEON Device, specifying Device Address, Name and selecting the EZIO6I from the Device Type pulldown. The SHN devices ship with an internal PLM. As Smartlabs began updating the PLMs to support what was then the new 2000+ link record variant, the size of the memory used by the internal PLM changed. Starting with the 2.8.x images the ISY uses an algorithm suggested by Smartlabs to determine the size of the PLM memory which is necessary to know where to write the link records. This algorithm is complex and done once at the time the EZIO6I is added to the ISY. Please post the Event Viewer trace. thanks Lee

Sorry, I took the steps you documented as the steps you followed. If after starting the Event Viewer the Admin Console was stopped nothing would be traced the next time you start the Admin Console. Is that the only thing that is not working on the PC. Can you do other Admin Console functions, displaying Programs, changing device status, etc. Sounds like the PC is not able to establish a good IP session with the ISY particularly if you can see the activity with another machine. Some issue with the firewall and the ISY IP address that prevents communication.

eitheta As soon as you close the Admin Console the Event Viewer is no longer active. The Event Viewer data is displayed in the Event Viewer window by the Admin Console function. Start the Event Viewer and set to Change level 3. Now press a device button that triggers a Program. You should see some activity in the Event Viewer window. Lee

simonsez Welcome to the ISY family. Define an ISY Scene using the Admin Console using Link Management | New Scene. Right click on the KeypadLinc button, select Add to Scene.. . selecting the KPL button as a Controller. Right click on the SwitchLinc, select Add to Scene… and add it to the Scene as a Controller. The ISY assumes a Controller is also a Responder. Once the Scene definition has been written into both devices all the necessary cross-links will have been established by the ISY. Lee

Schlyguy NO, it is not normal. It should not be necessary to refresh the EZIO6I firmware. First question, was the EZIO6I added to the ISY under one of the 2.8.x images. This is a requirement. Next would be that the Link Management | Advanced Options | Automatic option is selected. Lee

The Program triggers initially because the KPL button is Off. When the Status of the KPL becomes On the If condition has changed causing the If to be reevaluated because of the Wait. Separate the If and Then clauses in different Programs. That way the change in the If conditions during the Wait do not affect the Program containing the Then clause.

Illusion, Thanks for that added information. In the Powerhome case it would obviously be a third motion sensor. Also, that was a motion Off message sequence which would seem even less likely to trigger something that resulted in the SwitchLinc turning On. How the motion sensor sequence enters into this problem is not clear. There is a piece of information that is yet to be understood. Maybe something locked up in a confidential file at Smartlabs, something that makes this at least a theoretical failure. I'm sure less so from your perspective since you have a visual effect but this is a fascinating problem. Normally a symptom can be explained by some activity, some event that falls within the capability of the published protocol, even if it is very unlikely. In this case I cannot relate the end result to any known published capability. Lee

Thanks for the additional motion sensor traces. I’ll sum up what I see in the hopes it will generate some ideas from others. The symptom is a SwitchLinc physically turns On coincident with the SwitchLinc sending a Group Cleanup message to the PLM as though the paddle was pressed (there was no paddle press). This has occurred on three SwitchLincs at different firmware revisions (v27 & v39). Although only two failure traces, one from ISY and one from PowerHome, both occur at the same point in a motion sensor state change Group message sequence. One was a motion On and one was a motion Off. There have been rumors about a new command but to this point nothing has been documented that the motion sensor could send to the SwitchLinc to cause it to change from a Responder to a Controller and send the Group Cleanup message. In both traces the Group Broadcast from the SwitchLinc is not present. It is not a false message generated by the PLM to the ISY/PowerHome as that would not explain the SwitchLinc physically turning On. Group Broadcast from motion sensor – Group On and Off Group Broadcast from motion sensor = Group On and Off Group Broadcast from motion sensor – Group On and Off Group Cleanup from motion sensor to PLM – Group On and Off Group Cleanup from SwitchLinc to PLM – Group On To summarize, this is not a symptom that can be explained within the Insteon command protocol I am familiar with. The actual failure appears to be the SwitchLinc tact switch but it has occurred with three different SwitchLincs at two different firmware levels and so far always coincident with a motion sensor Group On or Off message sequence. Thoughts from others would be appreciated.