apostolakisl Posted December 19, 2015 Posted December 19, 2015 (edited) Saving the Program from ADMIN will also make the PROGRAM TRUE and IDLE even if the IF logic contains all STATE VARIABLES that are true and yet you cannot tell the difference programatically from a program in that TRUE and IDLE condition from one that is TRUE and ACTIVE. The TRUE and ACTIVE will eventually complete its WAIT and execute its logic that comes after the WAIT. The TRUE and IDLE program will never do anything. From The Program logic checking TRUE you cannot distinguish between the two! If you restart the program because it is TRUE it will always be TRUE so you will constantly restart it because both situations are always TRUE. If you don't restart the TRUE and IDLE program it will never do anything more even though it should! I cannot believe you do not see through this simple logic? No, that is not true. The program being true occurs when the last execution of the program ran the "then" clause. Saving a program is not a trigger and does not itself force an evaluation of the "if" clause nor does it change the status from prior to the save. Again, your program being true means the "then" ran. If it did not finish running, you either "stopped" the program or the folder it was in turned false while it was running. EDIT: I suppose you could also have disabled the program while it was running then re-enabled it to get rid of the red slash. EDIT 2: And I am very much on board with OberKC. What the heck difference does it make after you save the program from the admin console. That would only matter if you are constantly saving it from the admin console. Which would make no sense. You write a good program, save it, then you don't touch it anymore. EDIT3: Just look at the program summary page. It tells you the last start time, the last finish time, and the outcome (true or false). If the start time and finish time are the same number of seconds apart that your wait is, then the program did finish and did do the stuff after the wait. Your problem as to why your stuff after the wait isn't the way you expect it lies with some other situation that is changing them after that. Edited December 19, 2015 by apostolakisl
oberkc Posted December 19, 2015 Posted December 19, 2015 No I think that requiring the ADMIN Panel to mess things up is short sighted. MOBILINC can do it or having a Program not run at startup or a change in an Integer variable that makes the logic true but does not trigger execution or any number of other ways it can happen. The point is when it happens (And you have allowed ways to make it happen) you do not provide a way to detect that the program is in that state Just because the Programs logic is TRUE does not mean it is ACTIVE and if it is TRUE and IDLE nothing will ever happen with the program so stack it up to just another one of the reasons why ISY is not usable by the common man! Cannot and will not recommend it to customers with this kind of illogical thinking! I continue to struggle to understand why this is an issue. The whole discussion, while intellectually interesting, seems based upon a use case where one needed to know whether a program that included wait states was active and some improbable ways to mess this up. I remain confident that there is a programmatic construct that can be created that will meet most any need for which insteon is a viable solution. I am even more confident that this is am issue that the "common man" will even recognize, much less care about. Of all the impediments that I have seen that seem to be stumbling blocks to the person new to the ISY, this is not even close. I remain curious, however, what it is that you are trying to accomplish where this has become such a critical factor.
LeeG Posted December 19, 2015 Posted December 19, 2015 OP has a programming style that does not match ISY capabilities. May also have comm issues. Not likely either is going to change which leaves the OP dissatisfied with the environment. Hard to see how this is going to change despite all the good information presented about how to program the ISY.
oberkc Posted December 19, 2015 Posted December 19, 2015 OP has a programming style that does not match ISY capabilities. May also have comm issues. Not likely either is going to change which leaves the OP dissatisfied with the environment. Hard to see how this is going to change despite all the good information presented about how to program the ISY. A pretty accurate summary, in my view.
db2ace2 Posted December 19, 2015 Author Posted December 19, 2015 Well here is an example of a program getting into this state that I have no idea how it got that way. But what I do know is that I cannot correct the issue programatically because I cannot detect Active vs Idle programatically. In this example NO STOP was issued to any Programs and no FOLDER Actions exist on the Folder. Both the "Christmas Front Yard Outdoor Deck Lights" Program and the "Christmas Tree and Indoor Lights" Programs exist in the same folder so if there were anything in the folder that would have affected this both Programs would have been affected. If you look at the logic of Both Programs they are slightly but in fact Both Programs have The Very same IF Logic and use the same variables in their IF. They also use the same From To times on the scheduled events. The THEN Logic is slightly different but only because one has three devices to SET and one has two. If you look at both of these you will notice that the Outdoor Program is TRUE and ACTIVE which you can tell because it is a Solid Green Square for its ICON. If you look at the Indoor Program you will notice it is Partial Green and White meaning it is TRUE but Inactive. True that in this example you have to take my word for it that there was no Program Changes/Saves and no STOP program issued. Both Programs should have triggered and Ran when their Scheduled Time was triggered but and in fact the Indoor Christmas Lights are ON so the Program did indeed get triggered. But as you can see one is Active and the other is not! If I write a new program to check to see if the OUTDOOR PROGRAM IS TRUE it would report back as it being TRUE, and I can expect that when its schedule is finished or its WAIT is exceeded then that program will become FALSE. I would not want to rerun the OUTDoor Program because if I did it would reset its WAIT. (In this example that would not matter but if its wait were say 1 hour it would). If I use that same check for TRUE on the INDOOR Program it too would report back as TRUE but in fact it will never end until I power rest the ISY or take other action to stop it. I have no way of knowing that with the simple TRUE FALSE check. It would require a TRUE and ACTIVE or TRUE and IDLE check in order for me to tell the difference. So either you have a problem you need to address to determine how one of these programs is TRUE and ACTIVE and the other is TRUE and IDLE and yet both were triggered on the same schedule and use the same STATE variables and no FOLDER LOGIC is present and NO STOP commands or Program SAVES have been issued. The CAPTURE1 attachment is the OUTDOOR PROGRAM logic the CAPTURE2 is the INDOOR Program logic and the CAPTURE 3 file is the SUMMARY showing last run times, etc. One interesting thing I noted is that the last run times are different and yet these programs were started using the exact same time schedules and use the same STATE variables so both should have started at the same time and yet they did not. These are the kinds of things we deal with all the time that make ISY so Quirky to deal with! That is why you need to be able to write Programs to correct these situations and to do that you have to know if it is TRUE and ACTIVE or TRUE and IDLE. Let me know how you explain this? Thanks Charles Seiler
db2ace2 Posted December 19, 2015 Author Posted December 19, 2015 I decided to go ahead and send my LOG and ERROR LOG files as well just in case you see anything that would cause one of these two programs to be TRUE and ACTIVE and the other to be TRUE and FALSE. ISY Log.v4.4.1__Fri 2015.12.18 10.35.02 PM 12-18 version.txt ISY Error Log.v4.4.1__Fri 2015.12.18 10.21.04 PM.txt
LeeG Posted December 19, 2015 Posted December 19, 2015 What ISY Firmware What ISY UI What OS Are there devices in the wrong state, if so which device(s) and state The Indoor Program Last Finish Time is before the Last Run Time suggesting the Program is active and Icon state may be inaccurate but need to know state of devices being controlled to verify. Also need to see Folder.
db2ace2 Posted December 19, 2015 Author Posted December 19, 2015 A pretty accurate summary, in my view. Just as the ALL ON's were USER errors too until I went to the UDI HUB and they went away!
db2ace2 Posted December 19, 2015 Author Posted December 19, 2015 Decided I should send the EVENTS log too! ISY-Events-Log.v4.4.1__Fri 2015.12.18 10.47.26 PM.txt
LeeG Posted December 19, 2015 Posted December 19, 2015 Based on the Last Run and Last Finish times the Outdoor Program was also Idle if the Summary page was captured at the right time.
db2ace2 Posted December 19, 2015 Author Posted December 19, 2015 I thought I should also send you the screenshot of the STATE Variables used by the program so you can see that they too have not changed since the programs started and thus should have nothing to do with why one Program is TRUE and ACTIVE and the other is TRUE and IDLE. The attached CAPTURE4 file shoes the variables and their last changed date.time. If this is a USER coding error or COMM error or anything I as a novice ISY programmer have done wrong please explain how this can happen. My take is that because it does happen we need to have the ability to detect TRUE and ACTIVE vs TRUE and IDLE! Thanks Charles Seiler
db2ace2 Posted December 19, 2015 Author Posted December 19, 2015 Thought I should also include the Devices used by the Programs. CAPTURE5 shows those devices. So now I cannot think of any more doc to send you, so based on all of this, can you explain what I did to cause two programs with nearly identical logic, both scheduled to start at SUNSET -1 Hour to start over three minutes apart and one be TRUE and ACTIVe and the other be TRUE and IDLE? I really want to hear an explanation for what I did if this is my fault! Again No Program saves, No manual run commands, No Program STOP commands everything on the ISY running normally and no SYSTEM Busy or other issues. I am waiting until 12:01 AM to see if both programs become FALSE after their Scheduled From and TO times expire. I will let you know. Obviously because I coded a large WAIT time that still has not expired but had this been a 10 minute wait the TRUE and IDLE program would still have the lights on while the TRUE and active program would have become FALSE. This is simply not working right even if it is working as designed! Thanks Charles Seiler
db2ace2 Posted December 19, 2015 Author Posted December 19, 2015 Well at least something worked. Both Programs became FALSE at 11:59:01 PM as they should have. Doesnt explain why they started over three minutes apart and one showed TRUE and ACTIVE all day and the other showed TRUE and IDLE all day! Totally Quirky! Thanks Charles Seiler
larryllix Posted December 19, 2015 Posted December 19, 2015 Perhaps the admin console has just timed out and his icons and summary page are just not updating as happens frequently to most of us.
oberkc Posted December 19, 2015 Posted December 19, 2015 Ah...the real mystery comes out! but in fact Both Programs have The Very same IF Logic and use the same variables in their IF I will start here. I know that I can stare at things and not see stuff, but it appears to me that the "IF Logic" is NOT the same. The variables in each are different, to start. The variables in one program start with $area_outdoor..... whereas the variables in the other start with $area_indoor.... I notice, also, that the FROM time in one is different (sunrise-9 minutes) than the other (sunrise). I notice, however, that the variables have not change since the day before, according to the variable list. I do not see this as a cause of the mystery logs, however, but thought I would mention it in case it rang a bell in your head. Like LeeG, I notice the indoor program last run time was after last finish time, yet the program is not active. Interesting (but I don't understand it). Does the "Device Control Programs" folder or the "Christmas" folder have any conditions associate with them? I agree that any changes in conditions should have affected both programs, so I don't see this as a factor. I don't see any real utility to the wait 999 hour statement in each program. The lights will cycle on and off many time before the 999 hours expire. Have you experienced times where the lights don't turn off as expected? If this is a USER coding error or COMM error or anything I as a novice ISY programmer These do not look like programs and variables from a "novice" programmer to me. Well at least something worked. Both Programs became FALSE at 11:59:01 PM as they should have. Are your programs consistently working as expected, even if the program status table has these unexplained or misunderstood anomalies? Are the devices coming on and off as expected? I don't see anything programs that depends on knowing whether a program is active.
apostolakisl Posted December 19, 2015 Posted December 19, 2015 The only way I can reproduce a situation where a program is listed as 1) True 2) Last finish time precedes last run time Is By altering the program while it was running and saving it. All other means of interrupting a running program and will update the finish time. I tested 1) using "stop" command while running 2) "disabling" program while running 3) causing the folder status to turn "false" while running My conclusion: Either ISY firmware has a bug that somehow your program is uniquely exploiting, or you are altering/saving the program while it is running. I suppose your console could also have lost sync with ISY, but that seems unlikely based on the status of other programs. CORRECTION: In an earlier post, I stated that saving a program doesn't trigger or change the status of a program. It does appear to change the status of a program if the status is indeed different than before the save, but it does not trigger the program.
paulbates Posted December 19, 2015 Posted December 19, 2015 (edited) The ISY is most like a state machine, and modifying the program could change what is considered the current state. The ISY stops execution and begins evaluating state from there. I have consistently found that saving a program stops it, When that happens, as pointed out: 1) You can rerun the IF to force the state check, or run the then to get it going again 2) Alternatively, the conditions like a variable change make the program true and it restarts on its own I've recently been modifying programs that read a heartbeat value, those restart automatically due to the heartbeat. I have other programs that cycle hvac fans based on how long since the last cycle. I re-run the THEN of those if I change them, or I have to wait for the state to reoccur, which means waiting for the next heat cycle to run,and then complete, which can be a long time. Paul Edited December 19, 2015 by paulbates
Recommended Posts