LeeG

The Wait was executed and the IF condition changed to False causing the Program to be reevaluated with the statements after the Wait not executed. The motion sensor may have sensed more than one motion. Is the motion sensor operating in Occupancy mode? EDIT: is that variable a state variable or integer variable

Was Device communications events selected? If not repeat with that option selected. If so there is a firewall/AV problem blocking data from the ISY. Need to understand this first before going forward with anything else. Could be just not selecting the choice in the Event Viewer but there are some firewall/AV issues in recent weeks with updates to AVAST that have been causing problem. Perhaps progress on the PLM links. It may be necessary to Restore Device for each device. If that gets the PLM links back (can see device state changes in the Admin Console when button/paddle is pressed) then take a new ISY backup at that point.

I just did a quick review of topic from the top. Michel raised a question that needs to be answered about a possible issue with firewall/AV blocking data being pushed from the ISY. Runs Tools | Diagnostics | Event Viewer with Device communications events selected and run a Restore Device on one of the devices. This should indicate if device messages are being pushed out from the ISY. Often we use a paddle/button press to test this but the lack of PLM link records prevents that approach.

Now that the PLM is recognized the problem is the PLM no longer has any link records. These are necessary for PLM to receive device state change messages which would eventually trigger programs. Confirmed by the lack of link records displayed by the Show PLM Link Table results. The PLM link records are also needed to drive Scenes. Various symptoms all associated with the lack of link information in the PLM. Not sure if this is the result of running commands that required a PLM (Restore) when none was connected or something before that. If the Restore Modem (PLM) command is not restoring the PLM link records then that information seems lost from ISY files. Go to an earlier backup and see if the Restore Modem (PLM) will restore PLM link information from an earlier copy of the configuration. If not then the only solution is to Delete devices and add them back. Recreating Scenes will not restore the link information the ISY established when each device was added to the ISY. These link records are necessary for the ISY to be aware of device state changes.

The Ramp Rate field in the device has a numeric range of 1 (8 minute ramp rate) to 31 (0.1 second ramp rate). Each number has a specific rate and there is nothing in-between. A value of 0 which is labeled 9 minutes is now actually 0.2 seconds on many devices. Smartlabs changed this to prevent a 0 value from looking like the device was not turning On when it was just taking 9 minutes to turn On. 24 is an 8.5 second ramp rate 23 is a 19 second ramp rate There is nothing possible in-between the number 23 and 24.

When the Delete/New INSTEON Device sequence does not work either the RemoteLinc is defective or the PLM link database has become corrupted. Install new batteries in the RemoteLinc, do another Delete/New INSTEON Device. If that does not work factory reset the PLM and do a Restore Modem (PLM).

dpower If the Event Viewer does not see any Insteon traffic when the RemoteLinc button is pressed usually means the link records in the RemoteLinc or the PLM related to the RemoteLinc are missing/damaged. This assumes the RemoteLinc RF is being received by a Dual Band device and the 120V phases are correctly coupled, and the Dual Band device is in range of the ISY PLM. First right click the top node of the RemoteLinc and select Restore Device. Be sure RemoteLinc is in linking mode by pressing Dim/Bright buttons until RemoteLinc LED blinks. If that does not restore RemoteLinc communication with the ISY PLM Delete the RemoteLinc and add it back to the ISY. Lee

buzzhazzard Having done that very change yesterday the first error message that the PLM could not be found is terminal. I would unplug everything. Remove the cable between the PLM and Port A, check that there are not pins bent. Reconnect being sure the cable clicks in on both ends. Plug in the PLM and verify the LED lights on the PLM. Then power the ISY. Login and check Tools | Diagnostics | PLM Info/Status. It should display the PLM address and firmware level. Until this condition is obtained no sense going further. Could be cable or perhaps a DOA PLM. The ISY will know the Insteon address and firmware level of the PLM if it can talk to it over the Serial connection. What is the exact PLM Type on the PLM label? 241x/y Once the ISY is able to communicate with the PLM then do a Restore Modem (PLM) to have the ISY adjust all the device link records to the new PLM address and write the necessary link records in the PLM itself. Lee

barclay A common technique is to put the Then logic in a separate Program that does not have an If condition. Program 1 is triggered by the current If condition (Time is Sunset) and the Then clause Runs Program 2 Then clause. Program 2 Then clause contains the existing Then clause. The Waits will not cause Program 2 to terminate due to reevaluation as Program 2 has nothing in the If section. This same approach is often used with Programs that are triggered on device status that can change over time before the Then clause completes and has Wait or Repeat Actions. Lee

TJF1960 Single Program for variable control is a much better idea. Thanks. oatflake The V3 images are Betas so there is some exposure. The same thing can be accomplished using a Program True/False state as a binary switch rather than using a variable. There are many examples on the Wiki for using Programs as binary switches. That was the technique before variables coma along in V3.

One approach is to use a variable that indicates Sunrise and use that variable in the first part of the If. Define a Program that sets an Integer variable to a value of 1 Sunrise. Add a check of the Integer variable not equal to 1 in the first part of the If. Define another Program to reset the variable to 0 at Sunset. If Time is Sunrise Then $IVar4 = 1 Else - No Actions - (To add one, press 'Action') If ( On Mon, Tue, Wed, Thu, Fri From 6:20:00AM To Sunrise + 10 minutes (same day) And $Ivar4 is not 1 ) If Time is Sunset Then $IVar4 = 0

IndyMike Disagree all you want. You are absolutely right! Must have changed a Program to a Set scene Query and not done a Save. I thought I had traced a Set Scene Query that issued a Group Broadcast with a Query command but running the same test with a new Program each device in the Scene is queried individually as your test clearly shows. My bad. Thanks IM Lee

It would be something like the DSCLink that is going through the REST interface. I assume the phone apps would do the same thing. Things running inside the ISY itself do not need to go through the REST interface to access ISY variables. The piece that I still cannot find is what turns those `170001 messages On and Off. Still looking.

I think the application that is using the REST interface would have to be running, at least doing something that required variable access before the 170001 messages related to rest variable access would be logged. What I don't remember and have not found is what turns those information messages on and what turns them off. I was thinking event viewer but that is ruled out when the event viewer was closed.

I don't think these are errors. The 170001 is an information message which in this case reflectes variable access through the REST interface. I saw a post from Michel some time ago (which I cannot immediately locate) about the 170001 messages which may come when the Event Viewer has been run. I’m still searching for that post. Did they stop when the Event Viewer was closed.

If the number of PLM link records counted has reached say 350 and an inbound Insteon message is received that resolves to a PLM link record that is near the beginning of the link database the Get Next command counting link records will return the next link record following the one that resolved to the inbound Insteon message. This results in double counting many of the link records. If more than one inbound message is received the count can be very high, much higher than can be physically held in the PLM memory because many link records can be counted multiple times. The number seems reasonable but it very much depends on the number of ISY Scenes and how many devices are responders in the Scene. Links between devices (not between PLM and device) can quickly increase the total ISY Link count but has nothing to do with the number of link records in the PLM itself. Only those link records needed for the PLM to be aware of button/paddle presses and those needed for the PLM to control Scene devices when the Scene name is used in Programs or the Admin Console are actually in the PLM itself. The ISY Links information is maintained in the ISY memory which is quite separate from the PLM link database memory.

gfridland There is no direct relation between the number of ISY link records scattered across the Insteon device inventory and the number of link records in the PLM. So long as the Show PLM Links Table is not interrupted by other Insteon traffic the PLM link record count is accurate. The 450 number should be the correct number when it can be obtained several times in a row. The problem with the PLM link count is inbound Insteon traffic to the PLM alters the Next Link Record pointer the PLM firmware is using during the Get Next command sequence used by the ISY. This results in the Next Link Record pointer being bumped ahead such that link records are skipped (link count low) or being reset to a link record that has already been retrieved such that link records are retrieved multiple times (link count high). If you have a spare FilterLinc the PLM can be plugged into the Filtered outlet on the FilterLinc to keep inbound Insteon traffic from reaching the PLM. It is not perfect as close by Insteon device signals may still get through but it does isolate most of the devices. Of course be sure to remove the FilterLinc when done. Lee

The Device Links are not correct. The mismatched link record is a duplicate of the Scene responder record before it and the Scene responder link record for what I think would be for the Floods 100% is missing. I suggest deleting both Scenes where this device is a Responder (probably a Controller acting as a Responder) and define both Scenes from scratch. If that does not resolve the problem then delete the Scenes and Delete the device and start from scratch.

The Scene responder link records from the device do not match what ISY has for the ISY Links information. Suggest doing a Restore Device. Then do another Show Device Links Table and click Compare on the results popup. Did you migrate through 3.1.10 and or 3.1.12?

Thanks, I'll go through both files. This will take some time as these files are in about the worst format possible for human analysis.

The Scene Responder levels are correct as displayed. There have been some problems reported where moving the slider was not recognized by Java. Move the slider to 50% and watch for a progress bar indicating the change is being written to the device. If so then move the slider back to 100% and see if another progress bar appears. If so then test the Scene. If the Floods do not turn On right click on the device node in the my lighting tree and select Diagnostics | Show Device Links Table and post Show popup.

The attached screen capture shows the On Level and Ramp Rate for the two SwitchLincs which are Controllers and Responders of the Scene. These sliders toward the botton of the display are the value in effect for each Responder when the Scene is turned On through the Admin Console. The On Level (applied localliy) and Ramp Rate (applied locally) values do not play a role when the Scene name is turned On.

Negative. The On Level (applied locally) and Ramp Rate (applied locally) are the values in effect at the device where paddle is pressed. If affects what is connected to Red load wire of the SwitchLinc when the On or Off paddle is pressed on that SwitchLinc. When the Scene name is selected there are other On Level and Ramp Rate values displayed for each Responder of the Scene (includes Controllers that are assumed to also be Responders). It is these values that are stored in the Responder link records in each Responder device. These values instruct the Responder device what to do when it receives an On command from the respective Controller (ISY PLM) in the case where the Scene is controlled through the Admin Console. The only time a device node name below the Scene name is selected is when the Responder On Level and Ramp Rate values for the other Responders of the Scene are being set for when the paddle on that Controller is used. Pressing the On paddle on the SwitchLinc will cause these values to be used by the other Responders of the Scene. Each Controller has a unique set of On Level and Ramp Rate values stored in each of the Responder devices.

Michel The Show ISY Links appears to be intermittent or very step specific. I ran several tests when IM made his initial post and could not recreate. Tried it again today and can reproduce with a specific sequence. Start Admin Console Show Device Links Table for ICON Dimmer Compare Show ISY Links Table for RemoteLinc2 The last Show ISY Links for RemoteLinc2 does not replace the ISY Links display from the Compare of the ICON Dimmer. Other sequences have run without any problems. Lee EDIT: it is NOT specific to the RemoteLinc2. Same sequence except the Show ISY LInks for an ICON Relay produces the same result; the Show ISY Links from Compare is not replaced. Also found it not necessary to restart Admin Console to recreate.

ricke How are you turning the House Lights Up Scene On? Each Scene Controller has a unique set of Responder On Level and Ramp Rate values. When the Scene name itself is selected the On Level and Ramp Rate values that are displayed and can be adjusted apply when the Scene name is controlled through the Admin Console or an ISY Program. When a Controller node name (SwitchLinc) below the Scene name is selected the Responder On Level and Ramp Rate values displayed and adjusted apply when that Controller paddle is pressed. It sounds like the On Level and Ramp Rate Responder values are being set for a specific Controller paddle press rather than for Scene name. When the Scene name is turned On/Off through the Admin Console or ISY Program the ISY PLM is the Controller. When an individual SwitchLinc paddle is pressed On/Off that SwitchLinc is the Controller. Each Controllers On Level and Ramp rate for the Responders in the Scene is unique. To make On Level and Ramp rates changes easier there is a check box "Apply Changes To All Devices". If this box is checked the On Level and Ramp Rate values are changed for all the Controllers at the same time rather than having to select each Controller name individually. Of course if each Controller should have a unique set of On Level and Ramp Rate values for its Responders this box should not be checked. Lee