gduprey

Yeah - seems so. Sort of surprised that for as long as the ISY was been around some sort of "build a scene from current state" thing hasn't been implemented (at least as part of the UI). Would seem like a pretty common way to build scenes. I'll prolly build something for the future and just make do for the meantime

Is there an easy way to "capture" the current state of a series of lights into a scene? It seems like one of those "there must be", but I can't find it. If I multi-select lights and add them a scene, they are all added with the light level at 100% vs where they are at the time I'm adding them. Given how long it takes to adjust each lamp (especially when adding like 20 lights or something), I was hoping to find a "quick" way to just select a subset and say "add to a scnee with the current levels as the scene levels". Am I dreaming? Gerry

Honestly, it's been a bit of a mess with this one as the install is remote and I have been having complications. I'll try to get in to take a look. But I'm excited that you can subscribe to the events! Can you give me a sample REST syntax and/or pointer to what to look at? That is fantastic and I'll be adding logging ability top the base management app ASAP! Gerry

I can't send any logs (which was kind of the whole point of this) as when the unit does stop, it needs a power cycle to come back and that clears the logs. If there was an rsyslog, I'd at least have logs until things died. And again, this has happened only twice in 8 months, so it's not common or a easy to reproduce - I have zero idea what went wrong and of course, cannot pull logs once it does go wrong. When you say I can subscrib to events, you mean normal REST device/program/variable events? Or system logging events (i.e. what you'd see int he event viewer). If there was a way to pull/subscribe to the system event view log, that would likely handle most of what I'm looking for. Gerry

True, though it depends on the ISY/portal being able to talk to each other. I don't know enough about to portal to know if event logs are continually streamed to it or it "polls" the ISY when it needs the data. If they are continuously streamed, then this could be a good solution (at least you can see the last few things that happened before things went south). If it's a polled solution, then when things do go wrong, you/portal is unlikely to be able to get through as the ISY is down/dead/unhappy. The real huge benefit for rsyslog style operation is the stream of actions/events/notices so that even if that stream stops, you at least know what was going on just before it did. And again, in general, the ISY is a rock and the least likely thing to not be working. But in a few edge/odd-ball cases, when it goes dark (yet still responds to pings), you have nothing to check/review/etc. And given how incredibly infrequent this is, waiting/watching is likely not going to bring any help. Gerry

UDI has says they have no plans to support remote syslog support. I think this is pretty unfortunate. It's one thing to write explicit event logging via Node API and/or REST, but that only works when you're not suffering a more systemic problem. I have a very remote ISY where twice in the last 6 months, it's just stopped responding. It replies to pings, but all ports show as closed and you cannot get to port 80 or 22 on it at all. Power cycle fixes it, but of course, also clears the system log. If there were a syslog option that dumped all system reporting (not just stuff someone explicitly logged), it would at least provide a clue as to what is going wrong. Explicit event reporting only works for things you expect. Remote system logging would be a huge boon both for day to day management of remote units and to provide at least some possible insight for when things just go wrong (which admitedly, is incredibly rare for the ISY, but.....)

Long time after followup - it was ZWave! Well, sort of. The order of my goodnight program was to send an Insteon Set Scene command (to which about 70 devices are programmed to respond) and immediately after, I send a series of ZWave commands to insure the doors are all locked for the evening. While debugging something else recently, I noticed (with the event viewer open and set to Device Communications Level) that when I ran my "Goodnight" program, even though the Insteon command was first, all I saw was a bunch of ZWave commands and then later, the Insteon traffic. Testing the idea that a later ZWave command has priority over an earlier Insteon command, I added a 'Wait 10 seconds' after the Insteon Set Scene command and before the ZWave commands. Bang! Seemingly instant response to my "Goodnight" button. Of course, overall, the total runtime is still about the same, but the WAIT allows the Insteon to do it's thing instantly and provide instant feedback/gratification to the family (door locks just need to happen, but can wait a little). I would be curious if anyone knows why the ZWave command preempt the Insteon command. My program (posted earlier) summarized (with no sneaky intermediate steps excepted) is Run Program "Set Goodnight Lights" -> "Set Scene "Lighting Scenes/Goodnight" On Run Program "Secure House" -> "Set 'Front Door' Lock (followed by 3 other ZWave Lock commands) so given that, I do not understand why the Insteon Set Scene command "loses" to subsequent ZWave commands -- shouldn't they all execute (or at least queue up) in the order the related command is executed? Gerry

You can, but depends on what you mean Programatically. From outside the ISY, the REST interface is well described and pretty easy to use. From within the ISY, you can use a network resource to basically execute the REST command and then trigger that from an ISY program.

The whole things is new and fresh in my mind. Implementation of the logic is less than a week old. There are only 2 places that set the variable and both set only a 0 or 1. No alternate values. To be 100%, abso-sure. I just did a find and those are the only two places. That said, even if there were alternate values, the original program at the start of this thread should still work -- it tests for zero, so else should be any change to any value other than 0. No programs run based on the state of the humidifer switch state/status - it is only turned on and then turned off in the example program. Again, using find, there are no other references to it. I will try to carve out some time this weekend to do additional debugging. I've already done quite a bit. Gerry

Howdy, I did similar testing and found the same -- in simple demo cases, it seemed to work reliably. As for something else changing the variable, my thinking is it shouldn't matter what changes the variable -- anytime the value changes, the IF should be evaluated. I completely understand (and never questioned) that simply setting the variable to the same value (no change) wouldn't trigger anything. I also doubt the WAIT has any impact -- according to the previous discussion I had about IF/THEN/ELSE a few weeks ago, a change to the conditions in an IF will interrupt a WAIT and "re-start" the IF, so if a change ocured during the WAIT, it should still be caught. In short, the example is short and the condition simple and based on what has been explained about how IF/THEN/ELSE works, there really should never be a case that a change to the state variable would ever not cause the correct evaluation and execution. I'm pretty sure all the "problems" were in the ELSE -- the THEN portion seemed to work OK. Breaking it into two IF/THEN blocks has worked perfectly now. The whole IF <event> AND NOT <event> to trigger the ELSE still makes me think there is some subtlety to the ELSE portion of a triggered ELSE, however I realize some part of that is the "instantaneous" nature of CONTROL events/triggers. Gerry

Yes, I'm on the same version for UI and ISY -- always am. Not sure why this would work (if var is x and var is not Y) but simply testing "var is 0" won't -- that seems less than obvious. Can you explain the rationale behind that? As for hungarian notation, never took to it (though I understand why you are suggesting it). Prolly from my rabid avoidance of all things Microsoft Gerry

That was my understanding as well -- an IF on something that can be monitored (events), is only evaluated if one of it's event/triggerable parts changes, then the logic evaluates and the THEN or ELSE runs. But that is not what I was seeing and you can see how small and clean the program is -- there is no nested programs, muddling with the event triggering variable, loops, or other subtleties. Just turn a device on or off based on a state variable changing. And it working about 70% of the time. I have to beleive there is something subtle that I either don't understand or missed here, but I cannot find it. For the record, this system is running 4.3.26. Gerry

Yep -- all I was looking at was the programs status and last run times and such. Definitely something goofy about ELSE on a IF with a state variable. Hopefully someone from UDI can clarify. My work-around/alternate-implementation has been working great no matter how the variable gets set (manual program that sets it, humidity level that sets it or just me altering the value in the admin console). So I have a solution, but again, utterly do not trust ELSE on a triggering/event-driven IF statement (right this minute, at least Gerry

So as a followup -- I got unhappy with the unreliability of this and broke it into two programs -- one which checks $humidity_call is 0 (and turns it off in the THEN) and one that checks $humidity_call is not 0 (and turns it on in the THEN). This seems to work reliably -- so far, 100%. That said, after all the discussion about how IF works, how triggers are determined and how ELSE is supposed to work with triggered IF conditions, this just further cements my "fear" of using ELSE statements. Everytime I've had janky triggering behavior and I split a single IF/THEN/ELSE triggered program into two IF/THEN programs with no ELSE, things got reliable. That said, I have never had a problem with IF/THEN/ELSE when the program is just run and either isn't enabled (manually run) or doesn't have trigger events. Just triggered/event IF's. I would really appreciate someone being able to suggest what might be going wrong with this (and, I assume, implicit actions of an ELSE on a triggered condition). Knowing might start to rebuild my currently zero-confidence in reliable ELSE use with triggering IF statements Gerry

Yes, and manually changing the variable (from the "State" tab of the variable tab of the Programs tab) does not seem to trigger the program - at least not always. Per my earlier note, the program is enabled, the variable is absolutely a state variable and the folder the program is in is enabled and has no other conditions on it. There is no connection between the actual humidifier (or the state of the switch) to the variable. The only things that set the state variable to 0 or 1 are 1) the humidity level in the main room falling under a certain level or 2) running a program (with no IF but not enabled) to manually call for humidity. And again, the variable is being changed, but the program that should run when the state changes is not always running. Even if something else was monkeying with the state variable, the program should run (possibly thrashing around under a bad feedback situation, but still should be running as the state variable is changed). Note sure what the "output module" is (I assume the switch), but the problem isn't that the switch isn't switching, it's that the program (which eventually commands the switch) is not running. Gerry

Turn on, start, or in this example, run the programs then or else based on a change to the state variable, when the state variable changes. I did mention (right above the code block) that I do this as a safety, especially with the OFF, to insure that the command is received if something were to get lost. That said, I've never had it happen, but for things where there are consequences to a missed command, it's cheap insurance. Most lighting and such I don't bother with such "safeties". No, it appears the program did not run (when I notice something should have happened but didn't). Me either. I develop HA systems and have been programming and building hardware for 30+ years, so presumably not a total noob, but this case is so "simple" but unreliable, I brought it up here.

Howdy, I have a state variable that I set to 1 or 0 to call for whole house humidification. The variable can be set by a number of things (from a "manual call" program that sets it to results of hygrometer readings via a program). The variable is consistently set (or cleared) as expected and triple checked it's a state variable. I've had numerous times when I've noticed humidity was low in the house, but the humidifier wasn't being called. When I check, the appropriate state variable was correctly set to be calling for the humidifier, but the program that was supposed to trip the humidifier didn't run. If I then manually run the "If" part of the program via the admin console, the humidifier immediately trips. And there are times, I can see by looking at my logs, that the program trips as expected, but plenty where it doesn't. 1) The program is based on testing the value in a STATE variable 2) The variable is only set to 1 (ON) or 0 (OFF) in a small number of places 3) The program is enabled as it's it's folder and the folder has no conditions 4) The actual state variable IS accurately tracking when the humidifier should be on or off. 5) The program does NOT kick over 100% of the time (but it does some of the time). 6) Based on recent discussion of IF/THEN/ELSE, since the only IF condition is testing the value of the state variable, the THEN/ELSE should trigger anytime that variable changes (the difference being the variable). Any ideas where to look for why this is not happening? Below is the program and it's pretty simple. The command/wait/command is just a "safety" - I never actually lose events/commands, but given I don't want the humidifier running when not needed, my paranoid side says to "double check" If $humidifer_call is 0 Then Set 'Humidifier Override Sensor / Humidifier Override Switch' Off Wait 15 seconds Set 'Humidifier Override Sensor / Humidifier Override Switch' Off Else Set 'Humidifier Override Sensor / Humidifier Override Switch' On Wait 15 seconds Set 'Humidifier Override Sensor / Humidifier Override Switch' On I have to assume I'm missing something. The ISY has always been rock solid and when it's not, I've been able to track it back to my mistake/misunderstanding. But this one seems so simple, I can't see where that could slip in. Gerry

Which is sort of what I thought. A "IF" condition is really two things -- a list of "triggerable" (things to look for changes in) and an expression. Once any triggerable item in the If statements causes the program to be triggered, then the condition is evaluated and if true, Then is run and if false, Else is run. Gerry

Okey doke -- details seem to be coming along well. Given all the discussion of when a program is triggered, when is the Else section triggered? For example, if you have a IF condition on a state variable (like $myState is 1), is the "else" section run constantly or only when the variable value changes but wasn't the value specified? How about in control conditions? What would be the "else" case for an "If Control 'Overhead Lights' is Switched On'? I could imagine it *might* be -- "if anything associated with the If statement changes but does not meet the conditions of the If statement, the Else statement runs". Gerry

This does help -- I appreciate all the comments. One last one -- if I have "program A" running (with some WAIT statement in it) and then another program attempts to run "program A" as well, will it stop the program and restart it? I get that the conditions for an If of an enabled program will stop the WAIT and restart it, but wanted to confirm that simply running the same program (perhaps running the Then) will also do that (my guess based on comments so far is Yes). Gerry

By evaluating, I mean the ISY looking over the programs IF statement and deciding to execute it or not. I totall understand that the ISY will not reach out to devices and query them as part of an IF statement. As for the later, the statement: 1) Except for non-state variables (i.e. if they are part of an IF and change, they do not trigger the "IF AND ONLY IF something happened"), right? 2) If this is the case and if a "Run Program (If)" only looks at the result of the last execution (i.e. last time something changed), what happens if something (like a non-state variable) did change and was part of a programs If? The Run Program (If) will not evaluate the logic in the IF statement and depend on the 'last result'? I can see this mostly working unless you use a non-state variable in an IF statement (excepting that the ISY will not trigger a program because of it, but Running a program from another program might). Consider if I have program that is not enabled (I only want to Run it, not have it respond to things), and has logic like New Program - [ID 0013][Parent 0001] If $Occupied is 0 Then Set 'Office Overhead Lights' On Else - No Actions - (To add one, press 'Action') and assume that the $Occupied is a non-state variable. If another program changes the variable value to 0 and then Runs the above program, the program will NOT re-evaluate the If condition (because you said it relies on the last true/false result and this program is both not enabled and using a non-state variable)? Gerry

Howdy Michael - so I appreciate your example, but does that confirm the fact that if a program is running and an event occurs that would "run" the program again, the original run is stopped and then the If re-evaluated/run? Gerry

So there are no other items you can include an in IF statement that will NOT trigger the program if they change? Only non-state variables? Also: So if I use Run (If) from another program, it does NOT evaluate the target program, it just uses the last known state for it? If true, does that means that the ISY is effectively evaluating all programs pretty much constantly so the last true/false state of a program is always "current"? Thanks, Gerry

Hmm -- if that is the case, how would you write a program where, after an event occurs, you want to insure it doesn't happen again for some period of time? For example, say you have some sort of pump or compressor that you are looking to avoid short-cycling. So when the device is turned on, you want to insure that device stays on for XX minutes. If the above answer is that case and a repeat of the triggering event occurred, depending on the program, it might run a timer again or do other actions that should not have happened? (note: this is just an imperfect example -- the basic is how to insure a program runs to completion if the above reply is how things are handled)? So again, if the above is true (anytime an IF statement trigger/statement becomes true, any current running version of the program is stopped and restarted/re-evaluated), is there any way to have a WAIT statement that will NOT be so interrupted? Gerry

Howdy, As part of my ongoing attempt to get clarity around fuzzier (to me) aspects of ISY programming, I'm wondering what happens when a program as is run as a result of an event (i.e. Control event) and while the program is executing, the event occurs again? Will a second version of the program be run concurrently? Will the event (from the standpoint of the program) be ignored? Consider New Program - [ID 0013][Parent 0001] If Control 'Office Overhead Lights' is switched On Then $Occupied += 1 Wait 10 minutes Run Program 'Doors Locked' (If) Else - No Actions - (To add one, press 'Action') If the trigger (Office Overhead Lights switched on) occurs and the program runs, during the 10 minute delay, if the office lights are turned on again, what happens? Does a 2nd instance of the same program start running? Does the current running program get stopped and restarted? Is the Control "event" ignored? Or might it be queued up to run after this current "instance" is complete? Thanks! Gerry