apostolakisl

My guess: ISY does not have dedicated trigonometric calculator built in. It therefore is lumping larger blocks of an earth grid together so that it doesn't eat up resources and since really who cares, a couple minutes this way or that.

Also don't forget that sunrise/sunset is based on perfectly flat land. It doesn't take much of a hill to change your times by a few minutes. But I also have to agree with the above. What kind of work are you doing that you need to know the sunset to the exact minute?

I actually decided to get the real answer, 1 minute change in sunset/sunrise is about 12.9 miles east or west at 42 degrees lattitude.

Perhaps you should look up your exact longitude/lattitude and enter that instead. A city like detroit might be 50 miles across and that could account for the difference. At that lattitude one minute is about 8 or 9 miles East/West.

If you own nothing, and your goal is to integrate your security panel with ISY, then you should wait until you have enough money to buy an Elk EZ8 or M1G. Anything else and I expect that you would be disappointed and end up wasting more time and money in the future than if you just got the right thing right off.

Disabled programs function very much the same as callable subroutines. One point, however, calling these "subroutines" does not necessarily happen in order. In other words, if you have 2 "run ifs", the first one doesn't necessarily execute before the second one.

No, if you have eol resistors that are significantly different than 2200ohm. Even if you do, you can still use the Elk, you will just have to make some adjustments.

You should be able to use all of the old contacts and wires. You would need an m1gold (ez8 I think works too), the keypads, and the m1xep (ethernet expander). The only issue you might have is if the original wiring had end of line (eol) resistors that are signifcintly different than Elk's 2200ohm spec. If there are no eol resistors at all then that is fine. You can unplug the wires from a few of you zones and put an ohm meter on them to see if the ohm out at roughly zero ohms or some other number. For exmple, take the pos/neg to a door or window off of your current panel, attach to the leads on the ohm meter. When the door is closed it will read something like 0, or a small number indicating no eol resistor. If it reads something like 1500 or 2000 then you have eol resistors. When the door is opened, it should read infinity or open circuit or whatever your ohm meter does in that case.

Certainly nothing that would be easy. If your system has a network interface and you have access to the protocols, you may be able to get some functionality between ISY and it. But it would require a high level of expertise to be successful (if it is even possible at all). If you value your time, you would be better off replacing the honeywell with an Elk.

Just make a scene and put every device in it as a responder.

Every time ISY sends an "on with timer" command it resets the timer. For example. Then turn output 4 on for 5 seconds wait 4 seconds turn output 4 on for 5 seconds This will turn it on for 9 seconds. Or these two programs would keep the output on continuosly Then Repeat every 4 seconds Run then of following program Then turn output 4 on for 5 seconds

The problem isn't repeating the wait, it is "repeat x times". So it may not affect "repeat every x seconds". But it is worth a look and an independent timing of things.

Nope. The following program counts up at exactly 3 second intervals. You can watch the variable screen and it shows the time the variable changes and it is right on at 3 seconds each time. If - No Conditions - (To add one, press 'Schedule' or 'Condition') Then Repeat 10 times $itest += 1 Wait 2 seconds Else - No Actions - (To add one, press 'Action')

It would be great if Jahn or Michell could chime in. I am suspecting that "repeat" has a 1 second delay built in for a reason. Perhaps it prevents a runaway loop from locking the system up?

This thread would definitely be affected by some thing being discussed in this thread. viewtopic.php?f=27&t=8166 Specifically, it would seem that the repeat statement delays roughly 1 second from the time it finishes executing the repeat statements to the time it starts over again. The smaller you make your time interval on measuring the hvac, the more this issue affects your results.

It would seem to me that there is a one second lag between execution of the commands after a repeat, and the restart of the repeat loop. The following program took 10 seconds. Setting the variable to 0 should take less than a millisecond, so the looping back around seems to be a one second process. If - No Conditions - (To add one, press 'Schedule' or 'Condition') Then Repeat 10 times $itest = 0 Else - No Actions - (To add one, press 'Action') The following program I watched execute from the variable screen. The variables ticked up at exactly 1/second. If - No Conditions - (To add one, press 'Schedule' or 'Condition') Then Repeat 10 times $itest += 1 Else - No Actions - (To add one, press 'Action')

If - No Conditions - (To add one, press 'Schedule' or 'Condition') Then Repeat 10 times Wait 1 second Else - no conditions A run then on this program took 19 seconds to complete. So there is more to this than the plm or comm issues since this program is completely contained in the ISY. If - No Conditions - (To add one, press 'Schedule' or 'Condition') Then Wait 1 second Wait 1 second Wait 1 second Wait 1 second Wait 1 second Wait 1 second Wait 1 second Wait 1 second Wait 1 second Wait 1 second Wait 1 second Wait 1 second Wait 1 second Wait 1 second Else Stop program 'Elk Temp' This took 13 seconds If - No Conditions - (To add one, press 'Schedule' or 'Condition') Then Repeat 10 times Else - no conditions This took 0 seconds. So combining repeat and wait seems to have a delay.

So is the wait 1 second command not executed until after an ack is received on the beep command?

I assume that the kpl you are using to trigger these programs is not a controller of the scene as that would mess things up. One issue would be that using a kpl button to trigger a program which triggers a scene will not be instant. There will be a small delay that you might find annoying. Personally I would use the values of how bright the light is for my variable instead of 0,1,2,3. Since you can use any number you want, it is just easier to know that 30 is 30% and so on.

I checked my log this AM. My daughters light is programmed to turn on at 6:30am to wake her up. This triggers the above program which should shut the light off at 7:00am (29 minute wait plus 60 1 second waits). The log shows the light turning on at 6:30:03 and then off at 7:01:03. That is a whole minute later than it should have gone off. I didn't have it on detail to know where it picked up the extra time, but something is running slow and I suspect it is the 60 wait 1 seconds. Also, the program summary shows the light turning on program running at 6:30:00 and the above program last run at 7:01:03

I just looked over your programs quickly but it seems like you are on track. As far as "how do I get a light to return to its previous state" question. Well, you can't easily. You would need to use a variable to store the status of the light. If (light x is switched on or switched off or is switched fade up or is switched fade down) and status is > 80 and status is <90 Then set variable light status to 85 So the above program would set the variable to 85 if the light was manually controlled to somewhere between 80 and 90. You would need 10 of these programs if you wanted to be accurate to within 10% light status. You would then need 10 programs to set the light back to that status when your timer ends. So, you see, not easy. Perhaps you are ok with just an off/not off status so that would be just two programs. Personally, when I have doors that turn lights on and then start a timer, I just don't let the program run at all unless the light starts in the off position. For example, my back door opening turns on the lights outside the door. But if the light is already "not off", the program won't run at all.

Based on your other comments to another post, I changed the program to If Control 'Alexis Room / Alexis BR-Overhead L' is switched On Or Control 'Alexis Room / Alexis BR-Overhead L' is switched Fast On Or Control 'Alexis Room / Alexis BR-Overhead L' is switched Fade Up Or Status 'Alexis Room / Alexis BR-Overhead L' is not Off Then Wait 29 minutes Repeat 60 times Set 'Alexis Room / Alexis BR-Overhead L' 14 (Beep Duration) Wait 1 second Repeat 1 times Set 'Alexis Room / Alexis BR-Overhead L' Off Else - No Actions - (To add one, press 'Action') I was able to elliminate two programs and maybe not having that other timer running at the same time will fix things. I have to ask, why is "repeat 0 times" an option??

AHHHH, I never knew that. I always used two programs. I kept trying to figure out how to "un-indent". Personally, I think this is kind of poorly done. I think a repeat should only apply to the next line unless you use parenthases.

One other program that was separately counting 60 seconds to turn the light off. I expected the two to end simultaneous, but the beeping continues for 5 or 10 seconds after the light turns off. Plus, the beeping is not "like clockwork". Sometimes they are closer together (probably truly 1 sec) and other times more widely spaced (probably where the extra 5 or 10 seconds come from). I ended up having the other program terminate this one so the beeping would stop at the same time the light went off.

If - No Conditions - (To add one, press 'Schedule' or 'Condition') Then - No Actions - (To add one, press 'Action') Else Repeat 60 times Set 'Alexis Room / Alexis BR-Overhead L' 14 (Beep Duration) Wait 1 second I would expect the else clause to run for 60 seconds and the switch to beep nice and steady once/sec. But it is not so. The beeps fluctuate greatly in timing and the entire 60 beeps takes more like 70 seconds. Comments?