larryllix

On the rewrite note. I have found in the past that programs can get out-of-sync with their tokenized codes at some weird times (usually transferring systems) . I found the easy fix for that was to click/select each line of program code so that the parameters are all found in the edit section below and then click on update, so the ISY code compiler regrabs all the token codes and refreshes them. Do all lines of code and then click Save for the program. It's an easy to do trial. Of course you may want to disable and then re-enable your program before saving, also. It could be magically disabled and may explain the "works anyway". IIRC you posted you did a search for any other usages of your trigger variable. It really seems like there is another hidden program changing your variable on you.

I assume you may not use the GET protocol when using parameters then?

OK. I ran some testing to prove this out, one more time. The trigger logic is just as I have stated on my polISY v5.8.4. ISY program logic hasn't changed on my system. There must be something not right about your program logic, or eISY. When I run this program the result is a "2" count. This tells me logically that $sTestTrigger = $cTrue and $TestTriggerProgress lines are atomic, until the next Wait is encountered, which then allows the system (by surrendering it's time slice), causing the If section to re-evaluated, stopping the running of the True section and logically running the False section. The following True section lines (after the variable change and next Wait line) will never be executed. TestTaskSwitch - [ID 010D][Parent 0001] If $sTestTrigger is $cFALSE Then $sTestTriggerProgress = 0 Wait 5 seconds $sTestTriggerProgress = 1 Wait 5 seconds $sTestTrigger = $cTRUE $sTestTriggerProgress = 2 Wait 5 seconds $sTestTriggerProgress = 3 Wait 5 seconds $sTestTriggerProgress = 4 Wait 5 seconds $sTestTriggerProgress = 5 Wait 5 seconds $sTestTriggerProgress = 6 Else - No Actions - (To add one, press 'Action') However, when I run this program below, the end count, $sTestTriggerProgress, becomes "6". This tells me the time slice has not been surrendered until the end of the program True section and demonstrates the difference to the interrupted program above. TestTaskSwitch - [ID 010D][Parent 0001] If $sTestTrigger is $cFALSE Then $sTestTriggerProgress = 0 Wait 5 seconds $sTestTriggerProgress = 1 Wait 5 seconds $sTestTriggerProgress = 2 Wait 5 seconds $sTestTriggerProgress = 3 Wait 5 seconds $sTestTriggerProgress = 4 Wait 5 seconds $sTestTriggerProgress = 5 Wait 5 seconds $sTestTriggerProgress = 6 $sTestTrigger = $cTRUE Else - No Actions - (To add one, press 'Action')

Yes you need to use base64 encoded using username: password. However this format is basically obsolete and most browsers will not even send it anymore. I don't know anything about iOS. Does it support standard URL formats or is Steve Jobs still around yet?

You have to remember that ISY did not start out on a Unix-like platform but rather on their own home-brewed platform. Multi-tasking had to be created from the ground up. UDI choose to do it just like MS did with early Windows, by using voluntary releasing of your task's time slice mechanisms. That is where the Wait and While constructs came into the picture. Today's much faster multi-tasking O/S provide cleaner ways of providing methods of multi-tasking but ISY programs are already in place and to change the logic behind so many established ISY level programs would disrupt everybody's systems. Your first program with the $sLate_Arrival = 0 in the first few lines will never execute it's following lines, according to known ISY execution rules. If you are still getting some random action, perhaps we should be considering it is coming from somewhere else. Have you done a search for that variable through all your programs, using the search option provided in ISY? I usually find some forgotten program that is fiddling with the variable, maybe re-enabled by an update or transfer of programs to my new polisy box. I don't mark my Integer variable except my constants with a $cXXXXXXX eg. $sXXXXXXXX = $cTRUE $sKitchen.mode =$cVERYDIM

Only state variables can cause the re-evaluation of the If section. Integer variables will not. As a de facto standard, it is good practice to indicate your usage of state variables with a prefix, such as $sVariableName so that confusion, such as this is mostly avoided later.

Event triggered software systems can really screw up linear programmers. They definitely present some quirks. Think domino chains with lots of split out paths.

Any time a program executes a Wait or Repeat it allows the system engine to re-evaluate things and do I/O processes etc. When the ISY logic engine discovers your state variable has changed, it re-evaluates every program that contains that state variable. If it finds that variable in your If section has changed, it cancels any action already taking place in that program, and executes (starts over) the Then or Else section, depending on the outcome of that If logic. IOW You have created a monostable multivibrator oscillator that will never get past the next Wait 20 minutes line.

Well back working again...mostly. Suddenly started accepting my usual URL again on IoX Finder after about ten minutes. From inside ISY, I then found the HTTPS port and installed that URL. No IoX Finder icon on desktop. The only icon to be found and working is the old start.jnlp launch icon now. I can't find any option to install the IoX Finder. Seems similar to a few years ago, when it would be found in totally random places in folders. LOL More hunting to be done.

My IoX Finder just dropped out also. No changes were made. I have deleted all java files, uninstalled java completely, rebooted PC, reinstalled java latest version, loaded Iox Finder new copy. IoX cannot find either of my two polisys still. When I attempt to add a URL to the list I cannot remember the whole URL using the HTTPS format so I am locked out of my polisy(s). Very strange for a non-cloud dependent system this can happen without any local file changes to java, Windows, Iox, or polisy.

How many skills do you have loaded into your Alexa ap? My sister=in-law used to love to add every funny skill she could think of into my system and that seemed to slow down my HA system response while the Alexa servers would sort out where the commands needed to go. However, never that many minutes. I am talking 10-20 seconds, at times. With my blinds and other two server daisy-chained skills I ave experienced many "I cannot contact your xxx server". or "your server xxx seems to be offline" responses and then the device operates anyway, about 20-30 seconds later. Must be some sort of handshake back failure on those ones.

We have all been very surprised by the speed.

Interesting! However too small to read and browser magnification doesn't change video text size.

Maybe post your program here so that others can have a look at your logic. BTW: If Sunset would leave your program icon green after it ran the first time, until another logic triggered it False and turned it red. I am not sure what you are basing your deduction on.

As per @kzboray above. Open a ticket with UDI. I had the same problem a few years ago and it was just one module that didn't load properly. Michel sorted it out in a few minutes over the Internet.

Have you installed the IP address for your Eisy in you router's DHCP reservation table? This appears similar to what happens when two devices try to occupy the same IP address. Usually a power cycle of the router fixes that temporarily.

As per @IndyMike above, your If section is getting re-evaluated and running Else, which will stop the Then section from completing. Remove the time frame and make it a single time so it only can evaluate once per day, and not re-evaluate. There is no hysteresis in your temperature evaluation and the logic can bobble True/False quicky inside your five minute window. If 'WeatherLink / WeatherLink' Temperature > 97.0°F And At 2:45:00PM

@Chris Jahn

Are they both still freeBSD O/S?

Agreed. See you again in another years when somebody raises the need again.

Yeah I got it working eventually. However, that technique does not indicate the status of a scene. It only indicates the last scene command scene command sent out from ISY for the scene it is embedded into. Changing any component device inside the scene via another scene command or device control does not affect it's status despite the scene's resultant statuses not being true anymore. Again, people are attempting to assign a status to a trigger signal. It isn't really possible as they are different types of Insteon elements and not relatable to each other.

I saw no definitions or instructions to add any keys or values to it. That may be the problem??

I don't consider a state variable used for conversion into a pseudodevice as useful in an Insteon Scene. I find no way to incorporate these variables, or the pseudodevices the ISY Portal converts them into, even seen inside ISY at this point. Maybe I missed something there? However, it was mentioned about the Virtual device PG3 node server, that appears to be able to perform as a pseudodevices inside ISY, can be inserted into an Insteon Scene, and has intrigued me. I have installed the Virtual node server into my PG3 and it shows up inside ISY via IoX, but I cannot get it to perform anything except read one parameter that is permanently set to "True". I can drop it into an Insteon Scene and it appears as a valid device but never changes to show anything except "True", whatever parameter that is supposed to represent.

I am confused. Your original post showed it basically correct. Your program was sunset+30 minutes. Now you are complaining about sunset-30 minutes and it not operating today? I offered an explanation for the 2 minute calc error but now you are saying it didn't operate one evening but it did the next it did? Perhaps listen to some of the experienced helpers here, that have given advise, think about it, and respond to them. i see no problems except your story appears to be changing about what the problem is.

It may have been slow to come (as most UDI improvements) but the pseudodevice was an improvement made by UDI after much discussion over the years. Perhaps they just don't brag enough when they produce updates? However, it still doesn't solve all the scene monitoring possibilities that I can foresee. Now you have me interested to experiment with the technique (now that I am aware of it). I do not use many Insteon Scenes anymore, now that my lighting is almost all WiFi, ISY programs, and three MS IIs with buggy firmware in them.