apostolakisl
Members-
Posts
6756 -
Joined
-
Last visited
Recent Profile Visitors
The recent visitors block is disabled and is not being shown to other users.
apostolakisl's Achievements
-
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.
-
Blue Iris Node Server Disconnected after Software update
apostolakisl replied to pkauf's topic in BlueIris
status is always a trigger when the status changes. -
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.
-
Need clarification on From/To program running after boot
apostolakisl replied to smorgasbord's topic in eisy
Yeah, I should have been more clear. No two "control switched x" can ever be true simultaneously, but the "if" clause can be true if you connect them with "or". And for anyone new to ISY, a little trick is to connect two opposites with control. In this fashion, one program will be able to do 2 things. In this way, both hitting the on paddle and hitting the off paddle are triggers. The on paddle goes true, the off paddle goes false. If control switched on or not control switched off then do something else do something else -
Need clarification on From/To program running after boot
apostolakisl replied to smorgasbord's topic in eisy
I'm pretty sure a blank "if" clause evaluates as true during a "run at startup" and hence, you get execution of the "then" without any "else" clause needed. -
I would have to open it up and I'm not at the location currently. But it is on the PCB and it is small. Black if memory serves. I have the heat pump version but I believe they all have it. Power outages consistently put these thermostats in a messed up state. I believe the issue is that a power outage causes a gradual drop in voltage from the transformer and an improper shutdown. The secret button wipes out any residual states and forces a boot from scratch. It does not however clear settings.
-
Typically you disable the program rather than using lots of variables. Also, for flags, just use a PGM status rather than a 0/1 variable. Pgm1 If motion And PGM on vacation false Then Run then pgm2 Pgm2 disabled If blank Then Disable pgm1 Turn on pump Wait 15 minutes Enable pgm1 Turn off pump Only caveat is if you happen to reboot during the 15 minute wait, the program will be disabled at start and be stuck. So I use a single program that runs at startup to ensure that all of those programs are set to the correct state. As a side note, programs with blank if will run true if set to run at startup.
-
I didn't do an update. I put it in the same slot as the previous, but completely different Tesla node was. Then did a fresh install of the new one. I just drove the car and it currently shows good data. I will see what happens in a bit and send a log.
-
If I put it in a different location I will need to rewrite all of my programs. I just don't see why it would have a problem at one node location and not another. They all function the same using the same code and same hardware. And yes, unknown and not reported is what it says on the admin console until I hit the update button. Then after a period of time, maybe 10 or 15 minutes, it reverts to unknown/not reported