dnl

Larryllix summed it pretty well. There is a link near the bottom of the first post. Follow that link to a thread that discusses using variables in the programming structure.

Hi Michel, Today I upgraded my local ISY99 to 3.1.17 without any difficulties but left my remote ISY99 running 2.8.16 -- didn't want to take a chance the upgrade might crash and I would have no way to recover remotely. So the two ISY are now running different versions. When I launch two browser windows to access the two systems concurrently, the first one I access appears to be OK. The second one I access appears OK in most respects. The areas I noticed that are not OK are (1) Help:About is blank and (2) program details shows only condition statements; statements in the THEN or ELSE clauses and comments are not shown. I expect this is caused by the wrong version of Java applets being in the cache for the second accessed system. If I close all browser windows and then launch the browser to access either one of the systems, everything appears to be OK. Can I assume everything is really OK or should I clear the cache every time I switch systems?

Agreed the complexity is greater but I can see some ways where this technique might be used to advantage. 1) The delay time can be the result of a calculation. The ability to do calculations right now is limited but not non-existant. 2) The delay code can be packaged as a subroutine and called from multiple places, reducing program maintenance. Of course, it may be necessary to take care not to call the routine again before it completes. 3) I don't know whether a variable can be set directly from a REST call but I believe it is possible to do it indirectly by controlling which programs execute and having those programs set a variable as desired. There may not be many instances where we need or want to do any of these things but if we do, some approach like what ergodic suggests is needed.

The advantage is that the delay time is programmable. Some day I am sure UDI will support the use of variables in a wait statement but until then something else is needed.

Hi ergodic, I think your example code could use the ELSE clause to achieve some synchronization. Execution of the following code would be initiated by setting $F = 0. What do you think? //___________________ //Program TestVarWait If $F = 0 Then $V = 30 Run Program 'Wait.V' (If) Else Run Program 'DoItNow' (If) //______________ //Program Wait.V If $V > 0 Then Wait 2 seconds $V -= 2 Run Program 'Wait.V' (If) Else $F = 1

Thanks Illusion. Right you are. Actually, there was more than one instance of "KPL A" in the first example and I updated the post to correct them.

I also look forward to having extended capabilities for using variables. I have an approach that controls repetition and wait times with variables. I admit it is a kludge but I think it is better than nothing. For repetition: (1) set a variable (REPLIMIT) to contain the number of repetitions you want (2) code the repeat loop in your program to repeat 999 times (or some number larger than you will ever want) (3) initialize another variable (REPCOUNT) to zero just before the repeat loop and increment it by one inside the repeat loop (3) run the IF clause of another program (REPCONTROL) inside the repeat loop (4) the IF clause in REPCONTROL compares REPCOUNT against REPLIMIT; when REPCOUNT > REPLIMIT, the THEN clause stops execution of the first program. This approach requires each pass through the repeat loop to run longer than it takes to run the other program so a short WAIT statement may be needed after the RUN command. Alternatively, you could make REPCOUNT a state variable and omit the RUN statement in the loop. Each increment of the variable would invoke the REPCONTROL program. For wait: This is a similar technique ... (a) using one variable (WAITLIMIT) to contain the length of the wait that you want, ( a repeat loop in your program to repeat some very large number or times © using another variable (WAITCOUNT) to count loops (d) running the IF clause of another program (WAITCONTROL) inside the repeat loop (e) putting a WAIT statement inside the repeat loop. I have not tried this but I suspect it will not be possible to achieve precise control for some small number of seconds but it should work fine for larger increments such as multiples of two- or three-second intervals.

Edited to remove a duplicate post.

Hi Lee and Michel, Sorry for the slow response -- busy weekend. You have diagnosed the situation perfectly. I mistakenly added them as 2475S. Mystery solved. Thank you so much for your help.

As an educational exercise, I was wondering if an ILL could be converted from responder to controller by ... 1. linking the ILL to another device outside the ISY 2. using ISY diagnostics to save the ILL table to a file 2. editing the saved XML file to change the title 4. running a comparison 5. loading the edited file into the ISY table Does the load function in the compare dialog box update the ISY table for the device or is just for diagnostic comparisons?

Help about shows ver 2.8.16. I did clear the cache and all UDI certificates. I followed Michel's instructions in the 2.8.16 post exactly. The device link table shows only one A200 entry for the PLM. I added the ILL by specifying address and device type, electing to clear all links. EDIT: Lee, I removed the device and added it again letting the ISY discover the type of device. It was added as a controller -- and as you indicated, status is now updated. I wish there was a way to convert all the other ILL I have to controllers without having to remove and add. 2ND EDIT: Lee, I forgot the most important part. Thank you very much for the help.

Hi LeeG, Thanks for the reply. I upgraded to 2.8.16, removed one of the ILL and added it again but it is still only a responder. I guess this is a new feature of 3.1.x? What is worse is that the ILL status is not updated unless I query it. This does not seem right.

Today for the first time I realized that all of my In-LineLinc modules appear in blue, meaning they are only responders. The ILL can control other devices so I would have expected it could also be a controller. I also noticed that the status of the ILL does not update automatically. I can query it to get proper status. My ISY is at ver 2.8.10. Is this normal or what?

Hi vbphil. I have been thinking about updating this post to cover the very thing you mentioned. The introduction of IF conditions using non-state variables allows for conditional logic that is not affected by changes in state. There are also a few optimizations that could be added. Maybe after taxes are done ...

Hi robin, I thought I would jump in to clarify one point and venture a guess about why your single program did not work as expected. An IF condition is not re-evaluated at the end of a WAIT. The IF condition is subject to re-evaluation at any time during a WAIT. All program statements run without interruption with two exceptions: WAIT and REPEAT. If you have a program with any kind of statements except WAIT or REPEAT, that program will run to completion (unless power fails during the few milliseconds or possibly seconds while it is running). If any event affects any of its IF conditions during execution, the program will run to completion and the IF condition will be evaluated for that program only after its completion. When a WAIT statement is executed, the program can be interrupted immediately if an event affects any of its IF conditions. The same is true for a REPEAT; the program can be interrupted at the bottom of a REPEAT loop. This subject has been discussed at great length on this forum. Except for the recently announced global variables that are not declared state variables, all IF conditions serve two functions. One - they control whether the THEN clause or the ELSE clause is executed. Two - they control when the IF clause is evaluated. Whenever an event affects a condition, the IF clause is evaluated and the program will execute accordingly (I am assuming the program is not disabled). As mentioned above, the next execution will not occur until after any current execution completes, or a WAIT or REPEAT is executed. If a particular condition affects the logic of a program AND you want to avoid having an associated event interrupt the execution of a program with a WAIT statement, then you must separate the code into two programs. One program has an IF clause that runs another program and the other program has code with the WAIT statement but an empty IF clause. I hope this makes sense. If you are familiar with programming, the ISY may fool you at first. Its programming model is not typical. Now for the speculation. You mentioned that your single program status changed to False after 5 minutes. I believe the only way that could have happened is that either there is a condition in its IF clause or some other program executed the else clause of the program. I hope this helps.