LeeG

eximer168 Okay, I think I understand the question. Why did the ISY annotate that particular Group Cleanup Direct message with DOF 3 and did not annotate the Group Cleanup Direct messages before that one. I don't know what drives the ISY to log that message at that point when it did not for the other Group Cleanup Direct messages. I don't see any error condition that would explain the difference but I will lay out that trace in detail to see if I can determine why. What is the Insteon address of the IO Linc for the cat-feeder? Lee

eximer168 I am confused. I was counting the number of Set 'AP Music Family' Fast Off Set 'AP Music Kitchen' Fast Off Set 'AP Music Dining' Fast Off Set 'AP Music Office' Fast Off sequences in the trace as a reflection of the number of times the Program was being triggered. The Program that is posted has two sets of the Set statements so it is normal for twice the number outbound sequences. The DOF (3) is not a failure. The annotation is the ISY display of the information in the Group Cleanup Direct command which is a normal message for any button press. The DOF is referring to the Insteon Off command (13) and the (3) is the Group number (referring to button 3). Fri 05/20/2011 12:29:26 PM : [iNST-SRX ] 02 50 14.20.EC 14.85.AF 4B 13 03 LTOFFRR(03) Fri 05/20/2011 12:29:26 PM : [standard-Cleanup][14.20.EC-->ISY/PLM Group=3] Max Hops=3, Hops Left=2 Fri 05/20/2011 12:29:26 PM : [ 14 20 EC 1] DOF 3 The DOF (0) is also normal. The annotation is the ISY display of the information in the Group Broadcast message. It is the same display as the DOF 3. The difference is the Group Broadcast message does not include the button number in the last byte. It is 00 in the Insteon message and 0 in the ISY message. The button number in the Group Broadcast is located earlier in the message 00.00.03. Fri 05/20/2011 12:29:14 PM : [iNST-SRX ] 02 50 14.20.EC 00.00.03 CB 13 00 LTOFFRR(00) Fri 05/20/2011 12:29:14 PM : [standard-Group][14.20.EC-->Group=3] Max Hops=3, Hops Left=2 Fri 05/20/2011 12:29:14 PM : [ 14 20 EC 3] DOF 0 What is failure when the RemoteLinc button is pressed multiple times. There will be some differences between a single press and multiple presses. A single button press normally resutls in 4 messages being sent from the RemoteLinc. Pressing the button again before those 4 messages are sent cancels the current Group On/Off message sequence and starts a new Group On/Off sequence. I thought the issue was seeing more outbound messages to the ApplianceLincs than could be accounted for by button presses. That does not look like the case when 2 sets of Set statements exist in the Program. Lee

DirkM Try changing the Folder condition to If Status rather than If Control. Edit: the If Control is an event based condition, used to trigger a Program when a particular command flows from a device. The If Status checks for the current state of the device. Lee

jerlands The Adjust Scene statements generate an actual Insteon command only when the ISY thinks the value being set is different than what the device is currently set to. This saves issuing unnecessary powerline traffic. Looking at the event trace from the last post only the On Level is being updated. The Ramp Rate is not being updated because the ISY thinks the Ramp Rate is already set to .3 seconds. I think the testing got the ISY value and the device value out of sync such that it did not think it had to change to 100%. I set up a similar Program using a From/To with the Then and Else setting the Local On Level to different values. The Then Clause ran at the From time and the Else Clause ran at the To time. Be sure the Local On Level is at 100% before midnight and have the Event Trace with Device communications event selected running before midnight. Leave the trace running through the To time. I think what you have will work. Lee EDIT: also do a Save Changes to be sure the latest changes are actually in effect.

eximer168 Can you post the actual Program that is being triggered by the RemoteLinc button press. I keep going over this and with the number of tests I’ve run here that do not reproduce the results you are seeing, I’m thinking there is another variable involved that I do not have in my test Program. Lee

eximer168 An alternative to the current Closet arrangement would be to make the motion sensor and the TriggerLinc controllers of the closet scene. As with the RemoteLinc, the motion sensor and TriggerLinc also send multiple Group Broadcast messages to the linked Responders. This would provide several Group Broadcast commands from both devices which would improve reliability. The motion sensor would probably have to be in On Only mode so it did not turn off the closet light if motion stopped. The TriggerLinc Off would be okay if someone closed the closet door. Should also see what else electrically is on the closet circuit. Could be some specific appliance that is reducing the reliability of that particular circuit. Lee

jerlands Glad it looks like it is working. The Action statements can be tested simply by doing a Run Then, exercise the SwitchLinc paddle, then Run Else and exercise the paddle again. That will not test the time aspects of the If but it should confirm the Adjust Scene statements in both the Then and Else clauses work as expected. Then if something does not work the If is about the only thing left. Lee

eximer168 The Event Viewer is expected to show 3 Group Broadcast messages and 1 Group Cleanup message when a RemoteLinc button is pressed without generating multiple button presses. The first Group Cleanup message triggers the Program with an If Control. The remaining 2 Group Broadcast messages and the 1 Group Cleanup message should not cause a Program to be triggered. A simple 1 button press should show a single Program trigger even though multiple Group Broadcast messages are received for that single button press. I initially added the Queries to my test Program and see the Query activity in the Event Trace. That is why I mentioned it. Eventually deleted the Queries thinking maybe it made a difference but it did not change the overall result. The Closet scenario involves a Set Scene as the Action statement. A Set Scene can be less reliable when there powerline issues because the Scene command is not ACKed by any of the Responders so the ISY does not know if the Responder(s) actually reacted. The change in Responder device Status is what should have happened based on the Scene definition rather than a positive ACK from each Responder. There is no indication in the Event Viewer trace whether the Set Scene was received by the Responder(s). The trace entries showing resultant device status is what should have happened rather than a knowledge that it did happen. Lee

jerlands I think you can ignore that error message. Once you define variables (if you define variables) that message will go away. That message is there as a debug because it is a Beta drop. It would not be in an Official release. Lee

jerlands The Adjust Scene should be defined as follows … The In Scene field is the name of the SwitchLinc Dimmer The Set field is the name of the SwitchLinc Dimmer My SwitchLinc Dimmer is v38 so I would expect your v40 Dimmer to work when the Adjust Scene is defined correctly. The following is the Event Trace from a Program that issues an Adjust Scene defined as indicated above, setting the Local On Level to 50% (0x7F). Note that an I2 Extended Set/Get is used to set the Local On Level which takes effect immediately on my V38 SwitchLinc Dimmer. Fri 05/20/2011 01:28:24 AM : [ Time] 01:28:39 2(0) Fri 05/20/2011 01:28:24 AM : [All ] Writing 1 bytes to devices Fri 05/20/2011 01:28:24 AM : [16 3F 93 1 ] Memory : Write dbAddr=0x0032 [7F] Fri 05/20/2011 01:28:24 AM : [iNST-ACK ] 02 62 16.3F.93 1F 2E 00 01 06 7F 00 00 00 00 00 00 00 00 00 00 00 06 (00) Fri 05/20/2011 01:28:25 AM : [iNST-SRX ] 02 50 16.3F.93 12.9F.E4 2B 2E 00 (00) Fri 05/20/2011 01:28:25 AM : [standard-Direct Ack][16.3F.93-->ISY/PLM Group=0] Max Hops=3, Hops Left=2 Fri 05/20/2011 01:28:25 AM : [ 16 3F 93 1] OL 127 Lee

jerlands The trace shows the Responder link record On Level and Ramp Rate are being changed, not the Local On Level and Local Ramp Rate. That makes the issue the way the Adjust Scene is defined. Can't say I have ever tried dynamically changing the Local On Level with an Adjust Scene. The problem I was describing before was related to statically changing the Local On Level through the Admin Console. Let me run some tests here to see how that is defined. May be tomorrow before I get back. Getting pretty late on the East coast. Lee

jerlands Does the Admin Console show a v.00 or an actual v.xx number for the firmware level of the Dimmer? There is a question about what 3.1.2 is using for updating the Local On Level and Local Ramp Rate. Another user tried to change the Local On Level through the Admin Console and found it necessary to power cycle the device for the changes to take effect. This is the result of 3.1.2 using the old I1 Peek/Poke method for setting the Local values. The I1 technique requires some devices to be power cycled. For now I am assuming 3.1.3 will resolve this. This drop should be out very soon. If the firmware version is v.00 then the Dimmer was not added using Auto Discover. The only way to correct this is to delete the Dimmer and add it back using Auto Discover. Although this is ultimately necessary it may not resolve the problem because of the possible glitch at 3.1.2. First, fix the device such that the firmware level is understood by the ISY. Second, change the Local On Level through the Admin Console and see if it takes effect without the power cycle. If not set the Local On Level again and pull the air-gap switch for 30 seconds. Be care when pushing the sir-gap back in not to push it past being flush with the frame as that can factory reset the Dimmer and the new Local On Level will be lost. If the power cycle works then the Local On Level cannot be changed programmatically because the power cycle would be required twice each day. Hopefully 3.1.3 will resolve. At this point we really do not know for sure what the issue is on your system. To get definitive information run Tools | Diagnostics | Event Viewer with the Device communications events selected from the pulldown (important). From the Admin Console, under Program summary, right click on the Program that is changing the Local On Level, select Run Then. Post the event trace. That will show if the I1 or I2 method is being used to update the Local information. The alternative is to wait a few days for the 3.1.3 drop and see if that resolves the problem. Either way if the firmware level for the Dimmer is v.00, the Dimmer should be deleted and added back using Auto Discovery. May not fix the problem now but will likely be a requirement at 3.1.3. Let us know what you want to do. I’ll be happy to look at the Event Trace if you want to spend some time on it at 3.1.2. Lee

andyf0 FYI - A Program with an If status is triggered only when there is a 'change' in the status, in this case when LightA status changes to On will run the Then clause once. The Program does not loop nor get triggered again just because the status stays On. I have not stayed up with this topic so if this is redundant, my apologies. Lee

eximer168 I’ve done more testing and analysis of the RemoteLinc multiple button press trace. The RemoteLinc button press events cover a 4 second period which is not consistent with pressing the button 3 times in less than 1 second. Is there any chance this trace is not related to the test where the RemoteLinc button was pressed 3 times in under 1 second. The Group Broadcast message is what triggers a Program with an If Control. Because the RemoteLinc generates so many Group Broadcast messages a problem with the ISY recognizing the multiple Group Broadcast messages as duplicates could theoretically cause a Program to be triggered more times than the button is pressed. There is no indication this happened as the trace is labeling the extra Group Broadcast messages a Duplicates and Process Message: failed. Also I would have thought I would be able to reproduce the situation. I am running 3.1.2. Wed 05/18/2011 09:23:59 PM : [iNST-SRX ] 02 50 14.20.EC 00.00.03 CB 13 00 LTOFFRR(00) Wed 05/18/2011 09:23:59 PM : [iNST-SRX ] 02 50 14.20.EC 00.00.03 CB 13 00 LTOFFRR(00) Wed 05/18/2011 09:23:59 PM : [iNST-SRX ] 02 50 14.20.EC 00.00.03 CB 13 00 LTOFFRR(00): Process Message: failed Wed 05/18/2011 09:23:59 PM : [iNST-SRX ] 02 50 14.20.EC 14.85.AF 41 13 03 LTOFFRR(03) Wed 05/18/2011 09:24:01 PM : [iNST-SRX ] 02 50 14.20.EC 00.00.03 C7 13 00 LTOFFRR(00) Wed 05/18/2011 09:24:02 PM : [iNST-SRX ] 02 50 14.20.EC 14.85.AF 4B 13 03 LTOFFRR(03) Wed 05/18/2011 09:24:03 PM : [iNST-SRX ] 02 50 14.20.EC 00.00.03 C7 13 00 LTOFFRR(00) Lee

eximer168 All the tests I run against the IO Linc relay show a -2 error if the IO Linc does not respond with an ACK. This is logged using the Sensor node in the Log but it is always there. Of course if the IO Linc ACKs the On command the -2 entry is not logged. IO Linc1-Relay On Thu 2011/05/19 02:44:02 PM Web Log IO Linc1-Sensor Thu 2011/05/19 02:44:06 PM System -2 The next time the IO Linc relay does not activate the cat-feeder I think the Log will differentiate whether the IO Linc ACKed the On command. If it did but the cat-feeder did not cycle the IO Linc and associated equipment is the place to look. If the -2 entry against the Sensor node is in the Log then the IO Linc did not receive the On command. I don’t think it can be a failure of the ISY to receive the ACK as the IO Linc relay would drive the cat-feeder regardless. Lee

eximer168 I cannot explain why what looks to be 5 iterations of the Program from 3 button presses of the RemoteLinc. Pressing the button that quickly does change the messages that are flowing. The normal 3 Group Broadcast message sequence for press 2 and 3 are cut off. Looks like the RemoteLinc does not stack the outbound commands. Simply aborts the currently working Group for the next Group. This would be consistent in some respects with Insteon architecture as multiple Groups are not permitted to be active at the same time. I see no Query operations in that first trace. Also created a Program that matches the first example and cannot reproduce the sequence you are seeing. Perhaps my RemoteLinc is at a different firmware level. What ISY image are you running? I’m looking at the next sequence in the last post. Lee

eximer168 Enable the Program and delete all the statements in the Program that produce Insteon traffic. The result will be the same as when the Program is disabled. The PLM has no awareness of any application construct, be it ISY Program, Powerhome2 Macro, HouseLinc2 Event, etc. It is what the Program does when it is enabled, not the enable/disable state itself. "1) ISY sends out an ON command, reports status as ON in the Java-Applet, but device does not go on (theoretical message lost)." If the ON command is to the specific device this is not a lost message. Insteon Direct message requires an ACK from the device. If the ACK does not come back the device status is not changed. If the ON command is for a Scene it could be the message did not get to the Responder. If this is a Direct command look into the device itself. If a Direct command and the status changed the device ACKed the command indicating it was received and acted upon. "2) Separate programs which actively command on the same timeline (within 1second) interfere in unpredictable ways w/re to INSTEON/command-output." Here again it depends on whether a Direct command or Scene command is involved. Direct commands should be retried by the Controller (which would be the PLM in this case). The retry is automatic. Do you have a trace of this you can post? Lee

eximer168 The PLM has no knowledge of ISY Programs. It is not the Program being enabled/disabled. It is the Insteon commands the Program issues when enabled. For most devices when a button/paddle is pressed an Insteon Controller sends two messages. Group Broadcast message Group Cleanup Direct message For RF devices the messages generated are different Group Broadcast message [iNST-SRX ] 02 50 14.20.83 00.00.03 CB 11 00 LTONRR (00) Group Broadcast message Group Broadcast message Group Cleanup Direct message [iNST-SRX ] 02 50 14.20.83 14.85.AF 07 11 03 LTONRR (03) Group Cleanup Direct message (sometimes) Why the Group Broadcast message is sent multiple times has not been explained by Smartlabs that I have ever seen. It is normal with RemoteLincs, TriggerLincs, and Motion Sensors. The Group Cleanup Direct message being received multiple times varies. The most times I see this is when there is other Insteon traffic occurring at the same time. With RF devices it is possible for multiple RF receivers to process the message from the RemoteLinc. In theory only one will actually be propagated over the powerline to the application. In practice duplicate messages can be produced. The condition is benign. The duplicate message might be avoided by putting a delay (Wait) at the beginning of the Program such that all the RemoteLinc inbound messages are processed before starting outbound traffic. I do not suggest that as a permanent solution. The message sequence is not causing any unwanted device behavior and the Wait would introduce an unnecessary delay. From the trace it looks like multiple individual devices are being turned on with a Fast On. The devices will turn On in sequence when done that way. Defining a Scene with the same devices as Responders, turning the Scene Fast On, would turn all the Responders on nearly simultaneously, Lee

tome Thanks for the information on the IO Linc. After doing a Query and the device status is correct in the Admin Console, does it stay in sync as the device is manually turned On and Off. If the device status change is not updated it could be a link record problem. Each device must have a Controller link record pointing to the ISY PLM and the ISY PLM must have a Responder link record pointing back to the individual device. If the device status is not being updated and a Restore Modem (PLM) resolves the problem it is a link record problem. If this is the case and with multiple devices having the same issue the likely cause is the PLM. If the device does report status after the Query the link records are intact and powerline issues are suspect. Do devices always control each other but the ISY Admin Console does not correctly reflect status. This would point to some sort of noise or signal attenuation in the area of the PLM plug point. Not uncommon considering the equipment that is often also plugged at the same location. May need FilterLincs to isolate that equipment. Lee

AustinKirby The following conclusion “Anything that triggers the if section to be reassesed (a trigger) kills the program, period. So any then/else statement that has not already been sent off, will not happen.†Is not correct. I hate to get into such a detailed explanation but cannot let you go away with that idea. Using the following actual Program as a demonstration when I turn ICON ON OFF device to On the Program is triggered and the Then clause Runs. Eight devices are turned On in the Then Clause. When ICON ON OFF is turned OFF in the middle of the Then clause the remaining Then clause statements DO execute. Using the terminology in the Wiki the statements are atomic because no Wait or Repeat statement . If Status 'ICON ON OFF' is On Then Set 'ICON Dimmer 1' On Set 'ICON xxxx' On Set 'InLineLinc' On Set 'KeypadLinc White Box' On Set 'KeypadLinc-3' On Set 'KeypadLinc-4' On Set 'KeypadLinc6Bas8B' On Set 'Keypadlinc6Button' On Else Send X10 'A8/Off (11)' Event Viewer trace – ICON ON OFF is turned ON, Program is triggered, Then Clause starts The first 4 Set statement are executed ICON ON OFF is turned OFF, Program is triggered, Else Clause starts Original Then Clause statements continue execution, the remaining statements in the Then Clause are NOT aborted/cancelled. Tue 05/17/2011 11:39:23 AM : [iNST-SRX ] 02 50 04.56.50 00.00.01 CB 11 00 LTONRR (00) 'ICON ON OFF' turned On Program is triggered by 'ICON ON OFF' turning ON - Then Clause begins execution because If is True Tue 05/17/2011 11:39:23 AM : [iNST-ACK ] 02 62 15.B2.6A 0F 11 FF 06 LTONRR (FF) 'ICON Dimmer 1' On Tue 05/17/2011 11:39:24 AM : [iNST-ACK ] 02 62 15.52.C8 0F 11 FF 06 LTONRR (FF) ‘ICON xxxx' On Tue 05/17/2011 11:39:24 AM : [iNST-ACK ] 02 62 13.28.91 0F 11 FF 06 LTONRR (FF) 'InLineLinc' On Tue 05/17/2011 11:39:25 AM : [iNST-ACK ] 02 62 0C.8C.3B 0F 11 FF 06 LTONRR (FF) 'KeypadLinc White Box' On Tue 05/17/2011 11:39:25 AM : [iNST-SRX ] 02 50 04.56.50 00.00.01 CB 13 00 LTOFFRR(00) 'ICON ON OFF' turned Off Program is triggered by 'ICON ON OFF' turning OFF - Else Clause begins execution because If is False The previous Program execution continues until all Tnen Clause statements are executed Tue 05/17/2011 11:39:25 AM : [iNST-ACK ] 02 62 14.71.3C 0F 11 FF 06 LTONRR (FF) 'KeypadLinc-3' On Tue 05/17/2011 11:39:25 AM : [ X10] A8 Else Clause statement executes from ICON ON OFF Off trigger Tue 05/17/2011 11:39:25 AM : [ X10] A8/Off (11) Tue 05/17/2011 11:39:26 AM : [iNST-ACK ] 02 62 0B.4A.AD 0F 11 FF 06 LTONRR (FF) 'KeypadLinc-4' On Tue 05/17/2011 11:39:26 AM : [iNST-ACK ] 02 62 08.49.E7 0F 11 FF 06 LTONRR (FF) 'KeypadLinc6Bas8B' On Tue 05/17/2011 11:39:27 AM : [iNST-ACK ] 02 62 15.9A.F9 0F 11 FF 06 LTONRR (FF) ' Keypadlinc6Button' On It is okay not to follow all the detail of the actual Program execution and Event Trace. That will come with time. The key thing to remember is the change in If Trigger does not abort/cancel atomic group of statements that do not contain a Wait/Repeat. Lee

AustinKirby This is from the Wiki. There is a lot of good information there. "Within the Then or Else clause of a program, statements are executed from top to bottom in the order in which they occur. When a statement calls another program, the called program begins executing, and the calling program immediately continues execution with the next statement in sequence--it does not wait for the called program to complete before continuing. A series of statements within a Then clause (or within an Else clause), up to the next Wait or Repeat statement, are atomic. In other words, all such statements are executed before the conditions of the program are retested. The program's conditions are reevaluated each time a Wait or Repeat statement is encountered, and at the end of each iteration of a Repeat loop. What this means is that if a program's Then clause changes a condition which causes the program's overall condition to become false (or if the program's Else clause changes a condition which causes the program's overall condition to become true), the current atomic statement group will complete, and at that point execution will transfer from the Then clause (or the Else clause) to the Else clause (or the Then clause). Therefore, if a Then clause (or an Else clause) contains no Wait or Repeat statements, the entire clause is atomic, and will complete before the program's conditions are reevaluated." Changing the conditions the If checks DOES NOT in and of itself cause execution of the clause to stop. It must encounter a Wait or Repeat for the If to be reevaluated. Lee

tome Does the IO Linc have the Trigger Reverse option set? Using Trigger Reverse reverses the On/Off commands the IO Linc sends but does not reverse the Query response. If Query is used with Trigger Reverse the results can be what you describe. Could also be a simple powerline communication problem as the IO Linc is often one of the most distant devices in the network. Lee EDIT; reread your post and realized the status issue is not limited to the IO Linc. The Trigger Reverse can be a problem. However, if multiple devices are not maintaining accurate status it is likely you have powerline issues. Could be a PLM problem but that is less probable than noise or signal attenuation problems.

AustinKirby That is the problem. Statements in the Then clause execute sequentially even if the statements change the status the If is checking for. The exception is the Wait and Repeat statements. When a Wait or Repeat statement is encountered the If is reevaluated. Because the status of the Rope Lights has changed from Off to On (because of Fast On) the If evaluates to False so the statements after the Wait are not executed. The interaction of Wait and Repeat relative to If reevaluation is well explained in the Wiki section on Programming. This is different from most programming models and catches most folks. There are various solutions to this problem. The standard solution is to break the logic into two programs. The first has the If statement and a Then that invokes the second program. The second program has no If statement so the Wait is not affected by the Rope Light status change. Lee

AustinKirby A Program that contains a Wait and affects the status of the device in the If often has problems. Because of the Wait the If is reevaluated and often is False the next time. Post the two Programs. I am sure someone can suggest a solution. Lee

cmaciag Official support for the EZIOxx line of devices was added in the beginning of the 2.8.x images. Might want to try them again. I have many SHN devices installed on my ISY. There are some older devices that have a PLM combination that have to be updated using the SHN update service but all the new devices are working. Happy to work with you to analyze any problems that exist. Lee