LeeG

I think that has to be done locally. Otherwise it is too easy to hack. Corrected the words as the two sentences were obviously in conflict. If it could be done remotely it would be too easy to hack.

If the Folder condition is the same State variable as the Program have you tried and Folder xxxx is True as the second trigger condition in the Program. That way when the Folder turns True the Program is triggered. If the temp sensor is already On the Then clause will run. Or bumping the State variable twice, setting the value to 1, Wait 1 second, set the value to 2 with the Program and Folder checking for the State variable value greater than 0.

If the Folder is False when the EZIOxx Input turns On the Program is not triggered. Once the Folder is True the Input does have to change state before it will trigger the Program. That is the way If Status works. What is controlling the Folder Condition? Is it the same State Variable that is the second condition in the Program If section? I’m not sure that will work as the Folder is technically False when the State variable changes value. Perhaps seeing the Folder posted will help.

Can you clarify the point about the temp sensor true status not being recognized. The EZIOxx Input changing state should trigger the Program. Is the Input state correctly displayed by the Admin Console? If the temp alert triggers the Program before the Snow State variable is set to one the If will be False turning Off the heater. If the Snow State variable triggers the Program before temp alert turns On the If will be False turning Off the heater. Whichever comes first, Snow State variable or EZIOxx Input, when the second condition triggers the Program the first condition will still exist making the If True, turning On the heater.

Is the Variable $Snow.On.Roof an Integer or State variable?. The result would suggest it is an Integer Variable. If either condition changes, $Snow.On.Roof or Status 'Outdoor Temp Alarm', and either triggers the Program it does not matter which one comes first so long as both are On together. If $Snow.On.Roof were a State Variable the Program would get triggered when it is set to 1 and run the Then clause because the temp Input is already On.

Post the Folder and Program. Some IF conditions trigger only when it changes. For example, If Status xxxx is On triggers a Program only when Status changes. Once On Status occurs the program is not triggered again. Same with State variables. They trigger a Program only when the State variable changes value.

I don't know when it started but the Scene Test is now reporting Failed when the Report from the PLM showed it worked.

Thanks for that test. It was not meant as a functional alternative, only to help isolate the manual paddle operation. There is something wrong with the link records either in the SwitchLinc itself or the ISY PLM. The paddle will always manually control the load unless the switch is defective. The current issue is that the ISY PLM is not notified of the paddle press. When a device is added to the ISY the link records are created so that the ISY is notified that a paddle/button is pressed. This paddle/button notification is not happening. The next step is to run the Show Device Links Table and Compare I described a few posts back. If the Compare shows a link record problem (other than on last End of List record) a Restore Device should be done. Once the paddle notification problem is resolved I think the manual paddle operation will not cause a problem as it is now.

An alternate test method that will eliminate the manual use of the paddle. Change the Wait 10 minutes to Wait 5 seconds before issuing the Off for the door light. Be sure to wait say 10 seconds between door opening to insure the door light Off has a chance to execute after the Wait 5 seconds completes. Post the trace so the command flow can be verified. If the door light turns Off consistently and On again when the door is opened the next time when the paddle is not used that is more evidence the lack of a paddle press message is related.

I don't think my previous answer was correctly phrased (it was wrong!). When a device is added to an ISY Scene a link record is created in the Device Links Table and the device is added to the membership list. It is the adding of the device to the Scene that drives the process.

The Device Link Table creates/reflects the membership relationship. If the other devices were not removed from the Scene they still have half/broken links which can cause them to both respond and control the device that was Deleted and added back with erase existing links. It is best to add all devices using the erase existing links option to avoid half/broken links that can exist in devices. EDIT: sorry I missed a question. There is no facility to manage the device links table at the individual link level. Devices added to the ISY with the erase existing links option insures the link table will start clean and correct and remain that way. Trying to manipulate individual link records often results in more problems rather than solve them.

There are 6 On commands issued, 6 On commands ACKed by the device. Still no messages from device that paddle is being pressed. Only thing I can think of is the device is retrying the paddle Off press message being sent to the PLM. With nothing being received about the paddle Off press at the PLM it would not send an ACK back to the SwitchLinc so it will retry the paddle Off message 3 times. That may be having some effect as the last trace shows 6 On commands sent and ACKed by the device. Try a Show Device Links Table for the SwitchLinc and Compare when the link record display completes. If the link records are correct in the device the PLM could be missing the required Responder link record. Do you have any idea how full the PLM link database may be? Large number of devices and large number of ISY Scenes with a large number of devices in the Scenes.

Unfortunately the Event Viewer is not set for Level 3 so no commands are traced outbound and no inbound messages. Also there must be a comm issue or perhaps link record issue as the manual paddle operation did not appear in the first event trace at all. I'll do some testing of a Fast On with a comparable firmware to see if I can find anything the device does not like about Fast On. Have not heard of anything. Is there a slow ramp rate involved where the dimmer is still ramping the device Off when the next Fast On is received?

I do not think these are ISY messages that HS is simply logging. More likely they are the result of some condition the HS plugin has detected and logging. It may involve the ISY interface, something being returned by the ISY the plugin does not understand or like but HS will have to analyze the condition.

Some positive things from the trace. Each door open violation is triggering the Program and the Program is issuing the Fast On command to the device. Four Fast On commands are traced with the first three being received and ACKed. With the data in the trace showing the second Fast On was received and ACKed (with the light reported as not turning On) it would look like a timing problem between when the Fast On is sent and the light being turned Off manually. What type of device is controlling the front door light? What type of light, incandescent, LED, CFL? Also note that with the door being opened every 5 seconds or so the second Program Wait will not complete so the Off is not issued until the door remains closed for10 minutes.

This looks like the first front door open violation. Device 1D.50.B5 is sent a Fast On which the device received and ACKed. Thu 11/22/2012 11:16:36 AM : [ELK 0 1 0] Zone : Front Door : Violated (51/2/0) Thu 11/22/2012 11:16:36 AM : [iNST-TX-I1 ] 02 62 1D 50 B5 0F 12 00 Thu 11/22/2012 11:16:36 AM : [ Time] 11:16:40 0(0) Thu 11/22/2012 11:16:36 AM : [iNST-ACK ] 02 62 1D.50.B5 0F 12 00 06 LTON-F (00) Thu 11/22/2012 11:16:36 AM : [ELK 0 1 0] Zone : Front Door : Open (52/1/0) Thu 11/22/2012 11:16:36 AM : [ELK 1 0 0] Area : The Goldstein's : Not Ready To Arm (2/0/0) Thu 11/22/2012 11:16:37 AM : [iNST-SRX ] 02 50 1D.50.B5 0F.9D.50 2B 12 00 LTON-F (00) Thu 11/22/2012 11:16:37 AM : [standard-Direct Ack][1D.50.B5-->ISY/PLM Group=0] Max Hops=3, Hops Left=2 Thu 11/22/2012 11:16:37 AM : [ 1D 50 B5 1] ST 255 This looks like the second door open violation. Device 1D.50.B5 is sent another Fast On which the device received and ACKed. There is nothing in the trace to turn the device Off between the door open violations. What is being used to turn device 1D.50.B5 Off? Thu 11/22/2012 11:16:44 AM : [ELK 0 1 0] Zone : Front Door : Violated (51/2/0) Thu 11/22/2012 11:16:44 AM : [iNST-TX-I1 ] 02 62 1D 50 B5 0F 12 00 Thu 11/22/2012 11:16:44 AM : [ Time] 11:16:47 0(0) Thu 11/22/2012 11:16:44 AM : [iNST-ACK ] 02 62 1D.50.B5 0F 12 00 06 LTON-F (00) Thu 11/22/2012 11:16:44 AM : [ELK 0 1 0] Zone : Front Door : Open (52/1/0) Thu 11/22/2012 11:16:44 AM : [ELK 1 0 0] Area : The Goldstein's : Not Ready To Arm (2/0/0) Thu 11/22/2012 11:16:45 AM : [iNST-SRX ] 02 50 1D.50.B5 0F.9D.50 2B 12 00 LTON-F (00) Thu 11/22/2012 11:16:45 AM : [standard-Direct Ack][1D.50.B5-->ISY/PLM Group=0] Max Hops=3, Hops Left=2 This looks like the third door open violation. Device 1D.50.B5 is sent another Fast On which the device received and ACKed. Thu 11/22/2012 11:16:50 AM : [ELK 0 1 0] Zone : Front Door : Violated (51/2/0) Thu 11/22/2012 11:16:50 AM : [iNST-TX-I1 ] 02 62 1D 50 B5 0F 12 00 Thu 11/22/2012 11:16:50 AM : [ Time] 11:16:53 0(0) Thu 11/22/2012 11:16:50 AM : [iNST-ACK ] 02 62 1D.50.B5 0F 12 00 06 LTON-F (00) Thu 11/22/2012 11:16:50 AM : [ELK 0 1 0] Zone : Front Door : Open (52/1/0) Thu 11/22/2012 11:16:50 AM : [ELK 1 0 0] Area : The Goldstein's : Not Ready To Arm (2/0/0) Thu 11/22/2012 11:16:50 AM : [iNST-SRX ] 02 50 1D.50.B5 0F.9D.50 2B 12 00 LTON-F (00) Thu 11/22/2012 11:16:50 AM : [standard-Direct Ack][1D.50.B5-->ISY/PLM Group=0] Max Hops=3, Hops Left=2 This looks like the 4th door open violation. Device 1D.50.B5 is sent another Fast On which the device DOES NOT RESPOND TO. Thu 11/22/2012 11:16:55 AM : [ELK 0 1 0] Zone : Front Door : Violated (51/2/0) Thu 11/22/2012 11:16:55 AM : [iNST-TX-I1 ] 02 62 1D 50 B5 0F 12 00 Thu 11/22/2012 11:16:55 AM : [ Time] 11:16:59 0(0) Thu 11/22/2012 11:16:55 AM : [iNST-ACK ] 02 62 1D.50.B5 0F 12 00 06 LTON-F (00) Thu 11/22/2012 11:16:55 AM : [ELK 0 1 0] Zone : Front Door : Open (52/1/0) Thu 11/22/2012 11:16:55 AM : [ELK 1 0 0] Area : The Goldstein's : Not Ready To Arm (2/0/0) Thu 11/22/2012 11:16:58 AM : [ELK 1 0 0] Area : The Goldstein's : Ready To Arm (2/1/0) Thu 11/22/2012 11:16:58 AM : [ELK 0 1 0] Zone : Front Door : Normal (51/0/0) Thu 11/22/2012 11:16:58 AM : [ELK 0 1 0] Zone : Front Door : EOL (52/2/0) Thu 11/22/2012 11:16:59 AM : [ 1D 50 B5 1] ERR 1 With the other communication with the device being ACKed and the Hops Left=2 showing good powerline communication something must be interfering with communication this time. Again, what is being used to turn 1D.50.B5 Off as there is nothing in the trace to indicate an Off of any kind is being sent to the device.

I don't think these are ISY generated error messages. They look like something HS is producing. Where are you seeing these messages?

Changes are being made and saved to a running Program and the question is does this stop the execution of the current version? Yes. That is the only way for the changes to take effect. The fact that a comment is being changed does not matter. Of course if the running Program is not changed (moved to a second Program) it would not be stopped. Seems it would be simpler to just start the changed Program again since wherever the logic is moved it still cannot be changed and saved without it being interrupted.

Edit the event log with something like WordPad, Copy the event records and Paste into post. The event log file cannot be posted directly.

If the SwitchLinc is already On at a lower level a paddle press will turn it On full. SmartLabs considers that a feature. If the SwitchLinc was Off when the paddle is pressed and it goes to 100% rather than a lower value set in On Level (Applied Locally), it could be the Local On Level is not being set correctly. Right click the SwitchLinc node, select Diagnostics | Query Insteon Engine. Now set the On Level (Applied Locally) slider to some other position so the ISY will write a new value to the SwitchLinc. When the Progress Bar completes move the slider to the desired On Level. It is necessary to change the slider position as the ISY will not rewrite a value it thinks is already in the device. If the Show Links Table says Ignore it could be a deleted link record (22 or 62 in first byte) which the ISY is indicating is ignored or if the last record displayed, it is the End Of List record of which only the first byte being 00 is important. The other 7 bytes can have data left over from another link which has no functional value.

Sensitivity is the only MS option that cannot be set programmatically. Only the Jumper affects that. The other MS options can be set programmatically when Jumper 5 is in place and the MS has been put into linking mode with its Set button.

Take a look at the UDI Wiki, it has a good explanation on order of precedence. Order of precedence has to do with the default order and scope of evaluating ANDs and ORs. Without the parens the upper most ORs were being evaluated without being ANDed to the lower ANDed statements. Made the If true for most of the times because they were not ANDed with the last three conditions. By putting parens around the ORed statements all of them are now ANDed with the last three statements. Feel free to post back if the Wiki does not clear it up. Just trying to avoid duplicate posting of information.

If the night dimmer paddle is being pressed and the night can should come on dim it is the On Level (applied locally) value that affects the night dimmer On Level. Click the night dimmer node in the My Lighting tree. Adjust the On Level (applied locally) slider to the desired level.

I went back and read the posts again to see if there was something I missed. There was a problem some releases back with the file system that could have compromised some of the Insteon configuration data. It could go unnoticed until a device was restored. I noticed that at one point some of the devices were restored. This could have rolled incorrect data back to the device. The probability is low of this happening and it is not an issue with 3.3.4 itself as it is only restoring data it did not create. Try not to get to general in actions taken to resolve any remaining problems. Anything that is found to be wrong can be posted for evaluation of that specific. I feel certain the Insteon related things can be corrected although if there are powerline issues they can be harder to identify and resolve. Again, I am happy to work with any of the symptoms to help find solutions. Happy Thanksgiving

The If conditions need parens to correct the "order of precedence". Also the temp check will prevent execution at 80 and below, rather than below 80. If the check should be below 80 then ">= 80" is needed. If ( Time is 2:00:00AM Or Time is 4:00:00AM Or Time is 6:00:00AM Or Time is 8:00:00AM Or Time is 10:00:00AM Or Time is 12:00:00AM Or Time is 2:00:00PM Or Time is 4:00:00PM Or Time is 6:00:00PM Or Time is 8:00:00PM Or Time is 10:00:00PM Or Time is 12:00:00PM ) And Status 'HVAC / Downstairs / Downstairs' > 80° (Temperature) And Status 'HVAC / Downstairs / Downstairs' is Fan Auto And Elk Area 'Compound' 'Armed State' is Disarmed Then Run Program 'AutoCirc' (Then Path) Else - No Actions - (To add one, press 'Action')