LeeG

"Is that true of the stock 4.3.26 firmware (what I'm running)." Yes, for all the years I've been using an ISY. The 4.4.2 Beta puts .... on the end of a node name that does not fit in available space. I think that change is associated with Font size support for large displays.. May be necessary to restart Admin Console at 4.4.2 to change .... to full name after moving vertical bar. Would be good to click Help | About to verify Firmware and UI (Admin Console) are 4.3.26.

I added a motion detector and gave it a reasonable name in the dialog box, it created three different nodes all with that name and no obvious way to differentiate which was the sensor, low-battery, and dusk/dawn nodes. After finding no guidance through a web search, I realized that the automatic names that you get if you leave the "name" field blank *do* include suffixes, and then the user is free to rename them from the UI. It was confusing to me at first and I wanted to point it out to other newbies who may be in a similar situation. Try moving vertical bar to right to have space for node suffixes the ISY automatically assigns.

MWareman I suggested a LEVEL 3 Event Trace in post #25 Jan 10th. No interest for doing that in 10 days so I gave up.

Try putting black tape over LED for button(s) that have no function. May not mask all of non-toggle Off double blink but should prevent most of visual blinking.

It looks okay if the I/O Linc Sensor is Off when the garage door is open. That is dependent on the type of magnet used. I do not recommend using Trigger Reverse with this type Program because the 3AM Query returns the actual state of the I/O Linc Sensor, not the Trigger Reverse value.

First the Program is not Enabled. Next, Backlight adjusts the LED On/Off brightness of all KPL buttons. It does not indicate a button is On or Off. Need an ISY Scene with the KPL buttons as Responders. Then turn the Scene On or Off to turn button LED On or Off Scene xxx Basement Keypad A / Basement Keypad H - Responder Kitchen Nook Lamp Keypad A / Kitchen Nook Lamp Keypad H - Responder Master Bed Keypad A / Master Bed Keypad H - Responder Then Set Scene 'xxx' On Else Set Scene 'xxx' Off

Any time. The actual PLM link count is 251 as the Show PLM Links Table function starts at 0. You do not have a total PLM link count issue. Would be happy to help with other symptoms.

Look for Wait/Repeat statements that are interrupt-able so statements after Wait/Repeat may not execute. Post one of the Programs having trouble. What email provider is being used? The UDI facility is not recommended by UDI. Does the Program issue the email some of the time?

If Control is triggered when the physical device is operated. That is the function of "If Control". Operating the device by other means does not cause "If Control" to trigger. Need to use If Status to monitor the device for activity from both physical operation and remote operation by Set 'xxxxx' Off

There are 250 links in the PLM. The Estimates information is not accurate. "The LampLinc is marked "inactive in the ISY Admin Console." Sorry but that does not tell me where it is marked "inactive". The node in Main, the node in a Scene, something in a Program. Since it unplugged it is not being used so not sure what the issue is. I am assuming the 250 PLM links are correct. A File | Restore Modem (PLM) will rebuild PLM link database if the 250 nmber is not considered accurate. Again, I think an actual issue should be explained an pursued.

The Links Estimate seems unreliable. I would ignore those numbers. Explain actual Failures.

The EZFlora has no reason by default to have a link record in the PLM unless it is a newer I2CS device. The Zones do not report state on their own initiative. Where is the LampLinc marked "inactive"? It will take some time to go through the posted files.

Need to look for other Insteon traffic. I'll look at the trace if you can post. The number of link records must be exactly the same for it to be useful. I don't use the calculator but 250 versus 700 seems too large for the 250 number to be close. The Show PLM Links Table uses a Get Next command to read the next link record. If records 1-50 are read successfully but an Insteon command that references device 500 comes over the network, the next Get Next command will read link 501. Records 51 through 499 will be skipped. No Insteon message can reach the PLM from the network. The Get Next approach is simple but very exposed to wrong information if any Insteon message reaches the PLM. Some folks actually disconnect active devices to get good Show PLM results. Others have plugged the PLM into the filtered port of a FilterLinc (some need 2 FilterLincs).

Run Tools | Diagnostics | Event Viewer at LEVEL 3. The 2413S holds a maximum of 992 links. The event trace will reflect some Insteon traffic not associated with reading the PLM link database. Anything over 992 is a false number. It only takes one Insteon message reaching the PLM from the network to alter the real PLM link count.

The Program was changed because the device being referenced is no longer there. The Program maintaining name of device is useful when a device is Deleted and immediately added back. This sequence is done at times when device is misbehaving and may be resolved by a delete/add sequence that does not require having to update the affected Programs.

Not normal. Did you click on Save Changes? This is from 4.4.2. AAAA0 - [iD 002E][Parent 0001] If From 3:00:00PM To 11:00:00PM (same day) And Control <Not Specified> is switched On Then Set 'ApplianceLinc' On Wait 10 seconds Set 'ApplianceLinc' Off Wait 10 seconds Run Program 'AAAA0' (If) Else Set 'SwitchLinc Dimmer DB' 3%

"It seems fairly basic to allow the controller to respond to the "Engage Scene 0x001" command as well. This is not a "status" so much as a one-time event." Triggering a Program has two aspects. First is the process of making the Program to run (trigger). The second is the command associated with the trigger. All Insteon conditions which trigger a Program have a True/False evaluation based on trigger command versus command being checked. It sounds like you want some aspects of Trigger conditions to apply and some aspects should be ignored (change of Status). That would be more new function added to the ISY. Trigger when Scene initially used but not trigger if Scene is changed. What should happen when a Scene On occurs and later a Scene Off occurs.. Does the Scene On trigger and the Scene Off is ignored. If the Scene Off triggers what should happen if the individual devices are turned Off. Both situations result in the devices being Off. If an application wants to know the devices are Off would not both situations result in a trigger.

It looks like something is missing but it is not that simple, unfortunately. Scene xxx Device 1 - On 100% Device 2 - On 50% Device 3 - Off If Status xxx is On Then do something because xxx is On Else do something else because all devices in xxx do not match definition. Seems straight forward. Now Device 3 is turned On to 50% - is Scene On or Off? - some say On, some say all devices must be Off if Scene Off Now Device 3 is turned Off - is Scene On or Off? This is a simple case that raises questions as to whether 'If' is True or False when devices do not match definition but devices are not Off as would be expected for a Set xxx Off. This discussion has been going on for years with no consensus of what Scene Status should mean.

The UDI Wiki has instructions for replacing a PLM. The order of the steps is very important. http://wiki.universal-devices.com/index.php?title=ISY-99i/ISY-26_INSTEON:File_Menu#Replace_Modem_.28PLM.29

There is no method for triggering on Scene execution. Pick a device that is part on the Scene and use device state to trigger a Program. How is the Scene being invoked?

That is the problem with making multiple changes. The Scene Test now works but what resolved the symptom. The most likely change that resolved the Scene Test was the Restore Modem (PLM). This rebuilt the PLM link database. That leaves the question of why the PLM did not have all the required link records. The two most likely causes of the PLM link database missing link records is a capacitor failing or simply years of use filled the PLM with no longer used link records. If a similar symptom appears (not necessary to be the same Scene) in the near future it is likely a PLM failure (capacitor issue). If things run normally then it is likely the PLM link database became full from years of normal maintenance which the Restore corrected by writing only active link records. A Tools | Diagnostics | Show PLM Links Table and then pressing Count will show number of link records in PLM. The issue in doing this is the Show PLM Links Table has to be done multiple times to insure Count is accurate. Any Insteon traffic that reaches the PLM during the Show processing will alter the link records read. Could skip records or read the same set of link records more than once. Only by reading the same number of link records multiple times is the Count accurate.

Changing the Icon from Controller to Responder has no affect on the ISY Scene communication when the PLM is functioning as a Controller. The Responder link records in the three devices exist whether the Icon device is added to the Scene as a Controller or Responder. That is an Insteon requirement. It certainly makes a difference in the additional link records defined when the Icon is a Controller. The other 2 devices will have an additional Responder link record that supports the Icon as a Controller as well as additional Controller link records in the Icon device itself. However, these link records in the Icon device and the other 2 devices have no affect on the Insteon Scene that has the PLM as a Controller and the 3 devices as Responders. From an Insteon perspective 18 link records are required. PLM is Controller pointing to device 1 as Responder PLM is Controller pointing to device 2 as Responder PLM is Controller pointing to device 3 as Responder Device 1 is Controller pointing to device 2 as Responder Device 1 is Controller pointing to device 3 as Responder Device 2 is Controller pointing to device 1 as Responder Device 2 is Controller pointing to device 3 as Responder Device 3 is Controller pointing to device 1 as Responder Device 3 is Controller pointing to device 2 as Responder The ISY Scene definition with 3 Controller devices actually represent 4 Insteon Scenes described above. Lots of Controller link records in the various Controller devices (PLM, device 1, device 2, device 3). Also lots of Responder link records in device 1, device 2 and device 3. The PLM Responder link records already exist so the ISY is aware when a device is manually operated.

The Restore Modem (PLM) only works with the PLM. No other devices are affected. Only if the PLM is physically replaced does a Restore Modem affect the other devices.

That is an older PLM (v.98) which could be experiencing the capacitor failure issue. The newest PLMs with better capacitors are hardware v2.1 (on white sticker), firmware v.9E.

The Scene On/Off traces do not show anything because there are no actual device responses expected. The ISY marks the Responder devices On/Off based on what should happen. The ISY receives no information about how the devices actually reacted. The Scene Test uses different commands for this test. Here is an example of a Scene test that worked. The actual device responses are marked in Blue. Fri 01/15/2016 10:33:26 AM : [GRP-RX ] 02 61 5C 13 00 06 Fri 01/15/2016 10:33:26 AM : [iNST-SRX ] 02 50 1D.23.6B 22.80.0B 61 13 5C LTOFFRR(5C) Fri 01/15/2016 10:33:26 AM : [std-Cleanup Ack] 1D.23.6B-->ISY/PLM Group=0, Max Hops=1, Hops Left=0 Fri 01/15/2016 10:33:26 AM : [CLEAN-UP-RPT] 02 58 06 Fri 01/15/2016 10:33:26 AM : [iNST-SRX ] 02 50 16.90.AB 22.80.0B 61 13 5C LTOFFRR(5C) Fri 01/15/2016 10:33:26 AM : [std-Cleanup Ack] 16.90.AB-->ISY/PLM Group=0, Max Hops=1, Hops Left=0 <html><font color="red">----- SceneCrossLink Test Results -----</font></html> <html><font color="red">[succeeded]</font> SwitchLinc Relay (16 90 AB 1)</html> <html><font color="red">[succeeded]</font> SwitchLinc Dimmer DB (1D 23 6B 1)</html> <html><font color="red">----- SceneCrossLink Test Results -----</font></html> Fri 01/15/2016 10:33:34 AM : [iNST-TX-I1 ] 02 62 00 00 5C CF 13 00 Fri 01/15/2016 10:33:34 AM : [iNST-ACK ] 02 62 00.00.5C CF 13 00 06 LTOFFRR(00) None of your devices respond to the Scene Test. Could be very poor comm to the three devices or it could be the PLM has lost some link records. Suggest doing an File | Restore Modem (PLM) to rebuild PLM link data base. Then try Scene Test again. What does Tools | Diagnostics | PLM Info/Status show for PLM firmware?