LeeG

Need parens If Control 'Basement / Basement - Front MS-Low Bat' is switched On And ( Time is 3:00:00PM Or Time is 6:00:00PM ) Then Send Notification to 'Cassius' content 'Basement Front Motion Sensor Low Battery' Else - No Actions - (To add one, press 'Action') The "switched On" is Anded with the first time of 3 PM. The second time 6 PM is not Anded with the "switched On" without the parens

I do not see comm failures in any of the traces.

The number of buttons must match (6 replaces 6, 8 replaces 8 ) for the Group (Scene) numbers behind the buttons to function. An original 8 button can be converted to 6 button but an actual 8 button KPL cannot Replace an actual 6 button (nor the other way) as the Group (Scene) numbers do not support moving the existing Scenes over.

The post at 01:12AM shows the link table starting at 0400. That is invalid. After the factory reset the link data base display at 12:12 AM shows the link data base starting at 0FF8 which is the correct location. How the device decided that 0400 was the starting address is unknown. That is why I suggested deleting the device from the ISY and doing a factory reset to see if that would correct the link data base starting address. I would think along the lines of a power issue when the device was installed or before a Restore Device was done since the first link records created when the device was added to the ISY are in the wrong 0400 location.

For low volume events the query should be okay. With all the ICs available there might be a simple way to electronically delay the signal to the Input. Been too many years since doing fabrication like that to suggest a particular IC.

Communication from the EZIO8SA Inputs is done with Scene commands. The ISY assigned Group/Scene numbers 9-F to Inputs 1-7. Normally the EZIO8SA uses Group/Scene 1-7 for Inputs 1-7. Does not change the fact that the EZIO8SA will use Scene commands, only what Group/Scene number the EZIO8SA uses. Sun 09/07/2014 01:25:20 PM : [ 21 1F E2 4] ST 255 - RELAY 4 ON Sun 09/07/2014 01:25:22 PM : [INST-SRX ] 02 50 21.1F.E2 00.00.0A C7 13 00 LTOFFRR(00) - INPUT 2 OFF- Group/Scene Broadcast message Sun 09/07/2014 01:25:22 PM : [Std-Group ] 21.1F.E2-->Group=10, Max Hops=3, Hops Left=1 Sun 09/07/2014 01:25:22 PM : [D2D EVENT ] Event [21 1F E2 A] [DOF] [0] uom=0 prec=-1 Sun 09/07/2014 01:25:22 PM : [ 21 1F E2 A] DOF 0 Sun 09/07/2014 01:25:22 PM : [VAR 2 8 ] 298 Sun 09/07/2014 01:25:22 PM : [INST-SRX ] 02 50 21.1F.E2 2F.B8.09 41 13 0A LTOFFRR(0A) - INPUT 2 OFF-Group/Scene Cleanup Direct message Sun 09/07/2014 01:25:22 PM : [Std-Cleanup ] 21.1F.E2-->ISY/PLM Group=10, Max Hops=1, Hops Left=0 Sun 09/07/2014 01:25:22 PM : [INST-DUP ] Previous message ignored.

Use the Repeat statement. If ( From 1:00:00PM To 11:00:00PM (same day) ) Then Repeat 9 times Set 'Hardware / POE Fan' On Wait 1 hour Set 'Hardware / POE Fan' Off Wait 20 minutes Else Set 'Hardware / POE Fan' Off

In general Insteon allows only one Scene to communicate. Insteon does not permit multiple Scene traffic to interleave on the Insteon network nor does a device hold its traffic for what could be several seconds for another Scene to complete. A device seeing Insteon traffic will abort its Scene communication. That is explained in the insteondetails.pdf doc at insteon.com. Press two KPL buttons at the same time, only one Scene will complete. Not the exact situation with the activity going on with the EZIO8SA Relays and Inputs but I believe it applies. An earlier post indicated applying +12 to each Input caused it to turn On and report that to the ISY so the necessary link records exist and the Inputs work. Official confirmation would have to come from the device owner, Smartenit.

The only difference I see is Relay 4 turning On is followed by Input 2 turning Off. The previous device trace shows Relay 4 turning On followed by Input 4 turning Off.

Although from ISY view point it is a single ISY Scene with multiple Controllers (PLM, KPL button x, KPL button y, ....), from an Insteon view point each Controller (PLM, KPL buttonx, ....) has its own unique Insteon Scene. This means what happens when KPL button x is pressed can be different from what happens when KPL button y is pressed as far as Responder On Levels and Responder Ramp Rates. Link records are an Insteon construct. Look at insteon.com where there is an insteondetails.pdf doc that covers link records as well as many other Insteon details.

The new EZIO8SA PLM is an I2CS device. The Advanced | PLM Communication allows the retry count for Input state change messages to be controlled because the PLM is I2CS. Before I2CS the Input state change messages would have a retry count of 3. With I2CS the retry count can be adjusted. I set the retry count to 2, then set the retry count to 3. Sun 09/07/2014 03:50:10 PM : [17 6F 77 9 ] Link 0 : 1FF8 [E20922800B021F09] Saving [..........02....] Sun 09/07/2014 03:50:10 PM : [All ] Writing 1 bytes to devices Sun 09/07/2014 03:50:11 PM : [17 6F 77 1 ] Link 0 : 1FF8 [E20922800B021F09] Writing [..........02....] Sun 09/07/2014 03:50:11 PM : [iNST-TX-I2CS] 02 62 17 6F 77 1F 2F 00 00 02 1F FF 08 E2 09 22 80 0B 02 1F 09 E7 Sun 09/07/2014 03:50:11 PM : [iNST-ACK ] 02 62 17.6F.77 1F 2F 00 00 02 1F FF 08 E2 09 22 80 0B 02 1F 09 E7 06 (00) Sun 09/07/2014 03:50:11 PM : [iNST-SRX ] 02 50 17.6F.77 22.80.0B 2B 2F 00 (00) Sun 09/07/2014 03:50:11 PM : [std-Direct Ack] 17.6F.77-->ISY/PLM Group=0, Max Hops=3, Hops Left=2 Sun 09/07/2014 03:51:50 PM : [17 6F 77 9 ] Link 0 : 1FF8 [E20922800B031F09] Saving [..........03....] Sun 09/07/2014 03:51:51 PM : [All ] Writing 1 bytes to devices Sun 09/07/2014 03:51:51 PM : [17 6F 77 1 ] Link 0 : 1FF8 [E20922800B031F09] Writing [..........03....] Sun 09/07/2014 03:51:51 PM : [iNST-TX-I2CS] 02 62 17 6F 77 1F 2F 00 00 02 1F FF 08 E2 09 22 80 0B 03 1F 09 E6 Sun 09/07/2014 03:51:51 PM : [iNST-ACK ] 02 62 17.6F.77 1F 2F 00 00 02 1F FF 08 E2 09 22 80 0B 03 1F 09 E6 06 (00) Sun 09/07/2014 03:51:51 PM : [iNST-SRX ] 02 50 17.6F.77 22.80.0B 2B 2F 00 (00) Sun 09/07/2014 03:51:51 PM : [std-Direct Ack] 17.6F.77-->ISY/PLM Group=0, Max Hops=3, Hops Left=2

dpmaher Suggest opening a Ticket with UDI support. Moving to the 4.2.10 Admin Console (which I am using on my 99i and 994i) requires the Java cache to be cleared including checking the Application check box. The same Java process that was followed to clear the Java cache during the last 99i update.

MikieBro The 99i with 3.3.10 firmware is both a discontinued device and also well past its End of Life date. The 99i does not have the program storage for it to be updated past 3.3.10 level. Not that UDI does not want too, the 99i device reached its programming limits. The upgrade from a 99i to a 994i was available for $100 a long time. That update option may have been discontinued by now. I think UDI is suggesting trying the 4.2.10 level of the Admin Console.

Each KPL button should be a Controller in the Scene and as such listed in Red below the ISY Scene name. Click on the Red KPL button listed below the ISY Scene name and set the appropriate On Level and ramp rate values for that KPL button. Insteon supports a unique set of On level and ramp rate values for each Red Controller. The KPL button On Level for the responder has not been set to something other than the default 100% On. Clicking the ISY Scene name displays the responder ON Levels for when the PLM is the Controller

The 170001 is an information message that does not indicate a failure/problem. Nothing about the ELK file message in the event viewer.

The "is responding" check for the red ! along side a device node is dependent on the ISY sending something to the device and the device did not respond. Battery powered devices such as the Leak Sensor do not have commands sent to them on any regular basis because battery powered devices sleep to save battery life. In other words "is Responding" does not apply to Controller only nodes. The MS sensor Dusk/Dawn node will be blank until a change in state occurs. How much light/dark must exist for a minimum of 3.5 minutes is dependent on the value in Darkness Sensitivity in combination with ambient light. I set the Darkness Sensitivity to 100, placing the MS under a desk light. Covering the MS with opaque cloth for 3.5 minutes caused the MS to send On to the Dusk/Dawn node. Uncovering the MS with the desk light on for 3.5 minutes caused the MS to send Off to the Dusk/Dawn node. Night mode: is checked so the MS signals motion all the time. The MS sets/extends the timeout value for each motion sensed regardless of whether it sends On Only or On/Off commands (when using the timeout value). Not sure all folks call it linking mode (which it is). It keeps the battery powered device awake for 4 minutes so some might think of it as keeping a battery device awake. So long as you understand why it is needed what it is called is not so important. Linking mode is a good description. Under Tools | Generate Topology a file is created but I don't think it is sorted by Insteon address

1- Simple answer is "If Control" and "If Status" functional characteristics do not change with device type. Certainly the commands any given device type can issue varies but how "If Control" and "If Status" react is the same across all devices. "If Control xxxx is switched On" triggers a Program when xxxx sends an On command. There is no negative or Else flow with an "If Control" that drives the Then clause. An "If Control xxxx is not switched Off" drives the Else clause because of the "not". "If Status xxxx is On" triggers a Program when the status of xxxx changes. When status changes to On the Then clause is driven. When status changes to something else such as from On to Off the Else clause is driven. A simple If using "If Control xxxx is switched On" or "If Status xxxx is On" with logic in the Then clause only operates the same. 2 - Responding/not Responding was added so a Program can check for a node that has a Red ! next to the node. 3 - I'll have to test this as I though Dusk/Dawn node changed. The Dusk/Dawn condition must exist for more than 3.5 minutes for the node to change states. The Dusk/Dawn node does indicate lighting environment even when not using Dusk/Dawn mode. 4 - The countdown timer is set for each motion detected (assuming the timer is being used). MS does not need to send an Off command before the next motion resets to a new timeout value. 5 - The second fast flashing mode is for unlinking when not using an HA app. Step through it when using an ISY. 6 - Putting two devices (not limited to MS) into linking mode links the two devices together. Not something to be done when using the ISY. SmartLabs builds into all devices means for building an Insteon network without an HA application. Certainly easier using HA and some device functions/features require HA to manage.

The Scene device status reflects what the Scene should have done rather than what it actually did. According to the Link Table display the first link record starts at 0400 which would indicate the device supports approx 200 links (actually less than 128 link records). The specs for both the SwitchLinc Dimmer and SwitchLinc Relay indicates the expected approx 400 links. Note the 0FF8 starting address from one of my SwitchLincs. I would Delete the device, do a factory reset on the device and add it back to the ISY. Then do another Show xxxxx Links Table to see if it now shows the link table starting at 0FF8. EDIT: also note the Red Kitchen Lights Controller node has to be clicked to see the On Level and Ramp Rate in effect when the Kitchen Lights device is the Controller.

Suggest doing a Tools | Diagnostics | Show switchlinc Link Table. Post the results with the Insteon address of the Controller. The ramp rate will not matter if there is a link with a 0 On Level. The Show is for the SwitchLinc that does not respond.

Sounds like the Program If section needs some additional work. Please paste the Program into a post.

The 3.3.10 firmware does not deal with the expired certificate. The suggested link in the above UDI post is using a 4.2.10 Admin Console. The 99i is not only discontinued, it is past End of Life state. Best to move to a 994i to have the latest function and features.

The problem with the OutletLinc Relay is that it functions as a Responder Only. If something is linked to the OutletLinc and that link is known to the ISY the ISY knows the OutletLinc Relay should be On and triggers the "If Status" Program. If the OutletLinc Relay turns On because of noise or with a link not known to the ISY the Program is not triggered because the OutletLinc Relay has no Controller function.

What type OutletLinc is being used? An OutletLinc Dimmer does support "If Control" If Control 'OutLetLinc Dimmer' is switched On Then - No Actions - (To add one, press 'Action') Else - No Actions - (To add one, press 'Action')

Look at the circuit(s) the KPLs are powered from. Is the circuit(s) the same or near each other if multiple circuits. With multiple KPLs it could be something on the same circuit such as a noisy CFL or some other device that is generating interference. Since the KPL plugs in it can be moved to a different circuit to verify an issue with the circuit now being used. No harm is swapping ("Replace xxxx with") to a new KPL. It is a simple sequence to implement. However, since the KPL is easily moved to a different 120v circuit I would use that as a means of verifying the KPL.

Deleting a device from the ISY affects related Scenes and Programs. If you want, Factory Reset one of the KPLs. Then do a Restore Device to have the ISY restore the device information. Another approach is to "Replace xxxx With ....." using a different KPL. Add the new KPL to the ISY using some dummy name. This new KPL can physically replace the KPL being "Replace xxxx With .....". Right click on original KPL Main A/ON button node and select "Replace oldKPLname With" function. A popup will display listing the new KPLs that can "Replace" the old KPL. Select the KPL with the dummy name. The ISY will change all the references of the old KPL to the new KPL Insteon address. When the Replace is done the Admin Console will terminate as the new KPL dummy name has been removed from the list of devices. The old KPL Insteon address is not used during this process which is why the new KPL can physically replace the old KPL being replaced. No changes to Scenes or Programs are needed because the old KPL node names remain but with the new KPL Insteon address. It is not likely that the old KPLs suddenly developed comm issues. It is very possible the new KPLs will have the same comm issues which will have to be resolved.