apostolakisl

Totally agree. UD mobile is great, but can never be an efficient place to do lots of editing.

Oh it would be so wonderful if the new version ditches the Java console. That thing stinks and has only gotten worse. Back in the old days, like 15 or 20 years ago, CTRL-ALT-Delete was something you just got used to doing to kill frozen apps. Skip to today, and CTRL-ALT-Delete is all but forgotten, but for the ISY Java console which, if left open for more than a few hours, requires a CTRL-ALT-Delete. You might say it is my computer, but then you would have to say it is all of my computers, like 5 of them that I commonly use for ISY. And it has gotten slower and slower. Trying to edit lots of programs just gets so painful waiting several seconds after every change to take affect and allow you to move on. Please let ISY have a snappy high quality browser based console!

In "From/To" programs, the "from" time and "to" time are both triggers. At those two times, the program will run. At the "from" time, when it runs, it will be true (and thus execute "then" clause), at the "to" time, it will be false (and thus execute the "else" clause. In between the from and and to time, the program will have a status of "true", and likewise, outside of those times, it will have a status of "false". Should the program be triggered from some other trigger besides the "From" and "to" times, it will execute the "then" or "else" accordingly. For example, you may have additional items in the "if" clause or you may have a separate program that calls the "if" clause on this program. However, without some 3rd party trigger, this program will do nothing except at those 2 times. So if the lights were somehow turned on at noon, this program would not try to turn them off until 11pm.

Re-entrant is correct terminology, however, around here we all call it "re-trigger". It looks like you have a handle on this and I am sure you will succeed in programming your ISY. There are lots of little tricks and best practices and unusual situations (like a reboot while a program is running) and the forum is a great resource to help you save time and avoid pitfalls.

I am doing essentially that exact same thing. It requires 2 programs so that it does not re-trigger and end the wait. Doing it this way avoids using variables. "All off" is the name of a scene that includes basically every light switch in my house. I use it to turn everything off with a single button press, but it also works great to have all the switches in the house beep. I also have a program that disables the program for an hour that I manually activate if I want to. Driveway Entry - [ID 0173][Parent 0172] If - No Conditions - (To add one, press 'Schedule' or 'Condition') Then Disable Program 'Driveway Entry Trigger' Set 'All Off' Beep Set 'All Off' Beep Set 'All Off' Beep Wait 5 minutes Enable Program 'Driveway Entry Trigger' Else - No Actions - (To add one, press 'Action') Action run by driveway trigger. Seperated to allow for a 5 minute time out between entries. Driveway Entry Trigger - [ID 00AA][Parent 0172] If 'Blue Iris / Front Entry' Triggered is True Then Run Program 'Driveway Entry' (Then Path) Else - No Actions - (To add one, press 'Action')

Lots of brands out there have an app that controls their devices and do it for free. The advantage to ISY is that it is a brand agnostic controller. You can mix and match all sorts of devices from all sorts of companies and have them work together as if they were all on the same platform. So there is no flipping through apps and a device from one company can, through ISY, control and respond to a device from another company. I am a big fan of local control, so that even if the company goes bankrupt or just up and decides to stop support, I can function. That is why I like Insteon. Companies like Yolink must continue to sell new products at a margin sufficient to support their servers. ISY servers are not necessary to use ISY locally, and even remotely (you can use open ports or VPN and go direct from your phone app to the ISY without the portal). And the portal has nothing to do at all with using all the other functions of ISY. With UD charging for the portal at a price that is consistent with the costs, you can have a reasonable degree of confidence that it will continue to function.

At one time PLM's were not available. So fixing it was of course your best option. Since you can just buy a new one, I would do that. They don't cost much more than sending an old one off for repair, and then you have a new one. If you have a soldering station and easy access to the correct capacitors then fix it. In summary, I would buy a new one to have as a spare and put this one someplace as a just-in-case unit that if worse came to worse, you could fix.

Here is an IFTTT webhook I use for reference. This is not to send a text, but how it is configured would be the same, you would just call a different webhook.

wow, way back in 2011, man am I getting old. LeeG hasn't been around in a long time, but that guy new ISY better than anyone. I don't think he was an official full time UD employee, but I do believe he was contracted or in some way privy to the ISY internal code. Whenever he said something, it was always correct. Michel would regularly defer to him.

The discussion i recall.was like 10 years ago and involved UD people. Certainly response time would affect observed order. But the issue was doing math where order of operations matter. A long time ago before node servers, I wrote a bunch of programs using variables and math to allow for wild card date programs. Order of operations mattered. But I still use those programs and they have never not worked.

status is always a trigger when the status changes.

I replaced almost all of our thermostats in the church with venstar Insteon ones. They are much better. Unfortunately, not made anymore so I had to troll ebay for a while. The Insteon one above is a heat pump version, but I assume the pcb layout is the same for the standard one.

As I mentioned, it works like it has indexed all of the events contained in all of the programs. Should something in the index match a current event (not a condition, but an event, or trigger if you will) then it executes the program(s) that contain the item in question. ISY receives an event => Event is checked against the indexed list of events => matches point to program(s) containing event => program evaluates "if". EDIT: If you think of it as looping through all the programs, you are going to expect it to execute on the status of the conditions instead of only the "event" of the condition. "For sure . . " Not according to the people at Universal Devices when this was discussed many years ago. But in my experience, I have never seen a then/else clause not execute in order. But I have been told it is possible. Perhaps if the first line is computationally complex and the second line is not, the second line might finish before the first line. But I haven't seen it.

@Guy Lavoie I have done a good bit of PLC programming and a ton of ISY programming. The PLC works quite differently. PLC clearly loops through the code and executes based on the state of any given line. ISY does not loop through the "if" statements looking for conditions. It works on triggers. Again, I don't know how the actual engine works, but if you think of it this way, it will get your programs to work as expected. So, here is how I think of it: Consider that all of the if statements' conditions are indexed. For every event that ISY encounters (a node value is changed or the clock ticks to the next second), it goes to that index and sees if any program matches that event. If so, it executes the entirety of the program. If two(or more) programs match that event, there is no telling which it will execute first. Within a program, I have been told that ISY will not necessarily execute then/else clauses in order. Meaning if you have 2 or more lines in a then clause, it could execute them in any order. However, it has always been my experience that the lines in an then/else clause do execute in order. I have a number of programs that do math where order of operations matter and they always work correctly.