Jump to content

frankv

Members
  • Posts

    12
  • Joined

  • Last visited

frankv's Achievements

Newbie

Newbie (1/6)

0

Reputation

  1. Thanks for your patience and continued assistance, oberkc! If From Sunset To Sunrise (next day) And Status 'Porch Lights' is Off Then Set 'Porch Lights' 50% Else Set 'MBR Light' On Set 'Porch Lights' Off Let me make sure I get this 100% correct. In the example above, will this program execute a. at sunset b. at sunrise c. every time the status of 'Porch Lights' changes (and evaluate to true and execute the "Then" statements if the current time is between sunset and sunrise AND the status of 'Porch Light' is off, or execute the "Else" statements any other time of day OR any other status) d. every time the status of 'Porch Lights' changes between sunset and sunrise only, and execute "Then" if the status of 'Porch Light' is Off, or "Else" if it is in any other state a,b, and c? a,b, and d? ? Not sure I like either answer, problem being is that the status change acts as a trigger in itself if I interpret you correctly. Here's an example UD shows in their manual: That statement makes you belief that the status is ONLY evaluated at the specified time, not every time the status changes. Now in my example we are dealing with a timeframe, so if we apply the logic from their example, you would think it's either only at sunset and sunrise, or sunset/sunrise/any time in between that the status changes. Then again, their statement "program will execute only..." is suspect to me as well, shouldn't it be "program will evaluate to true" or something to that effect? You almost have to know the internals of their code to figure out how this stuff works, or do a lot of experimenting which I'm trying to do as well as much as possible, but this evening I got a nice error message on my UD Admin console: Failing Communicating With Cannot Communicate With Front Porch Door Lights (3 17 93 1). Please check connections. OK Then it had the same error message for the foyer lamps, but those had come on nevertheless, whereas the porch lights did not (but their "current state" in the console shows 50%). Ok, got part of the answer. Just changed the status to 53% in the admin console to see if I could turn on the porch lights "manually", and they started going on, off, on, off, etc - checked the program and I had basically the same logic as above, so I deleted the "And" condition/trigger and saved the changes which stopped the madness. The status change is definitely a trigger, question remains if that trigger is valid all day or only during sunset to sunrise. Ran another test program with a from-to AND Status ... condition, the status change does indeed trigger the program to run at any time (it evaluates to false/else outside the from-to timeframe, and true/then inside the timeframe). For those of you still awake reading this, hope it helped a bit. Now I have to figure out what's causing these communication errors (still popping up even if issuing commands from the console, though some of them execute despite the error msg).
  2. So...this newest program has adds a second condition to the original.. The "trigger" for evaluation continues to include sunrise and sunset (from the original condition), but adds a trigger for any time the porch light status CHANGES. Therefore, this program will trigger an evaluation any time you change the status of your porch light. Also, be aware that you have just introduce a condition (status of porch lights) that is affected by one of your program actions (set porch light to 50%, set porch light off). This can result in some interesting complications at times. I assume that your porch light is on a dimmer, so beware that this introduces some interesting status possibilities. Consider "on" versus "not off". Or "off" versus "not on". Is a light "on" if it is set to 50%? Just beware that there are a lot more possible status than simply "on" or "off". The trigger effect of the status condition is not what I intended or would have expected, but interesting. I'm starting to see where some of the recommendations here for separate programs are coming from. How about this approach: If From Sunset To Sunrise (next day) Then Run Program 'Sunset' (If) Else Set 'MBR Light' On Set 'Porch Lights' Off Program Sunset: If Status 'Porch Lights' is Off Then Set 'Porch Lights' 50% Else - No Actions - The idea is that the Else statements get executed at sunrise irrespectively of the status of the porch lights, but that the porch lights (at sunset) ONLY get set to 50% IF they are presently off. Since the Sunset program now has a trigger AND condition, I have to disable it so that only the trigger in the calling program can run it. Correct? BTW, the porch lights did turn off this morning (with the Else statement turning it off explicitly).
  3. Haven't been able to test the porch lights as my family keeps turning them on/off manually. I have set up another program that is similar to turn on some other lights in the evening, and those lights came up as scheduled tonight. oberkc, I'm still trying to figure out exactly how the ISY translates these programs into triggers and actions, especially when you specify a timeframe. Based on your suggestion am I correct that the following program will create three events that will execute at the (translated based on locale) start and end times respectively: If From Sunset To Sunset (next day) Then Set 'Porch Lights' 50% Else Set 'MBR Light' On Set 'Porch Lights' Off (Logical) ISY event table: When Action 08:10:29pm Set 'Porch Lights' 50% 06:15:58am Set 'MBR Light' On 06:15:58am Set 'Porch Lights' Off What puzzles me is when I create (and save ) a program like the one above without any "Else" actions after sunset, the next scheduled runtime under Program Summary is 06:15:58am. Perhaps because it needs to run to set the status flag if nothing else? Taking this a bit further, what if I add another condition: If From Sunset To Sunset (next day) And Status 'Porch Lights' is Off Then Set 'Porch Lights' 50% Else Set 'MBR Light' On Set 'Porch Lights' Off Not that it matters, but the reason may be to ensure that the porch lights only get turned on to 50% if nobody has turned the lights on yet. But for this to work, the ISY has to evaluate the status when the events get triggered. So the scheduled time(s) just determine when the program executes, and it evaluates the conditions each time to determine which branch to run? Which means every program needs some kind of schedule defined for it to run, unless it's only called by other programs? Sorry for my ramblings, I'll post an update of what happens with my programs tomorrow.
  4. D'oh - but in my defense, that button is hidden by my laptop which sits in front of my big monitor, and its placement is a unique UI design choice. What surprises me is the fact that it was listed on the Program Summary tab with a status of "On" for "Enabled" prior to it being saved, but I just tried to duplicate it and now it shows blank for "Enabled". Thanks for your continued help!
  5. Tried this program to turn my porch lights on every night, but it's not executing: If From Sunset To Sunrise (next day) Then Set 'Front Porch Lights' 50% Else - No Actions - ... Program Summary shows: - Name: Front Porch Lights nightly - Enabled: On - Activity: Not Saved - Status: False - Next Scheduled Run: Mon 2011/08/08 08:12:49PM all other fields are blank Current time displayed is Tue 08/09/2011 01:21:10AM Any advice? Thx, Frank
×
×
  • Create New...