apostolakisl

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?

I don't understand. I have the counter starting after 5 seconds of run-time using the 'Wait 5 seconds' command. Watching it work, by starting it manually and monitoring the variables, it works like you'd expect. Only after 5 seconds have elapsed, does it add the first count. Wait 5 seconds Repeat Every 5 seconds $Cool_Cycle_Time_Daily_5Sec += 1 The only problem I see with this particular logic, is when the unit shuts off between counts, and you miss counting the last 1-5 seconds. Hence why I chose a small 5 second counting window. I suppose you could shorten the count time to as small as 1 second, but I assumed that that would use too much resources and might cause problems if another program tried to run at the same time. The way I see it is, if I miss a complete 5 seconds every cycle (not likely), my count is off (low) a max of 1 minute every 12 cycles. When the math is calculated, the variables get rounded down as well. From that, I could be as much as 59 seconds low per report also. I wonder if that wait statement shouldn't be removed as a way of compensating for the rounding down. Anyway, I do want things to be as accurate as possible, and if there is a quick and easy way to do it, I'm all for it. But at the end of the day, a couple of minutes either way isn't that big of a deal to me. When it's running for 8 or 10 hrs in the summer, 2-3 minutes is minor. Sorry, you are right, you are counting the 5 sec blocks at the end, which would result in undercounting. Just change the wait time to 2 or 3 seconds and then, on average, you would reduce your error to 1 sec per cycle on average. Or change your count interval to 6 seconds and use a 3 second wait to start things off, then (on average again) you would be dead on. It isn't a big deal, but if you are doing it, I figure you might as well make as dead on as possible. Wait 3 seconds Repeat Every 6 seconds $Cool_Cycle_Time_Daily_6Sec += 1 By having your counter flip at the middle of the cycle, on average, you would undercount the same number of times as you overcount and thus it would zero out. You could also go with much larger intervals while still maintaining accuracy but taxing the ISY less.

Is this because there will be one last count after the cooling stops (program goes false)? Meaning once the last repeat starts, the count will always increment one more time? Sort of. The progression is this 1) Units turns on 2) counter goes up by one immediately (even though 0 seconds of being on have actually happened, counter would indicate the full 5 sec have passed) 3) counter waits 5 sec (at the end of this, unit has been on 5 sec) 4) counter goes up by one again (at this point the unit has actually been on 5 sec, but the counter would indicate 10 sec) 5) counter waits 5 sec (at the end of this unit has been on 10 sec) The counter adds one at the beginning of the 5 sec interval, even though the unit could shut off before the 5 sec is up. So there is no difference between the unit shutting off .1 sec after the counter went up or 4.9 sec. Either way it looks like 5 full seconds of being on. Their are 2 ways to fix this. 1) Count the number of cycles, multiply by 2.5 seconds and subtract that from the total 2) Have the counter start counting 2.5 seconds after the unit turns on.

This may be a silly point, but your counter counts the 5 second blocks at the start of the 5 second time period. So you will be overcounting your usage by anywhere from 0 to 4.9 seconds on each cycle. You will never be undercounting. If you put a "wait" 2 seconds as the very first line, you would end up sometimes undercounting by up to 2 seconds and sometimes overcounting by 3 seconds, on average this would mostly cancel each other out and you would get a more accurate number. Of course, if you used 4 or 6 seconds as your interval, then you could use 2 or 3 seconds as your opening wait and even more accurately average out your under/over counting. Again, this won't change things that much, but just to be anal, that would be my suggestion.

Probably antivirus software. This is different than windows firewall.

Wow, come to think of it, I don't think there is. The admin console is the only local running app that I am aware of. Touchswitch runs through a webbrowser. So, kind of a windows user interface "app", but not really.

Also you can set the KPL into "radio" mode. I think the analogy is to presets on an old car radio where you push one in and the other pops out? Anyway, if all the buttons are to be used for scenes that are exclusive of one another (in other words only one button should ever be on at a time), then putting the KPL into "radio mode" automatically shuts off any buttons that are on when you turn a different one on.

You can not buy old/used Insteon stuff off of ebay. There are lots of bad switches out there (mostly the tact switch issues or "paddle issue" as SH calls it). SH is warrantying those for 7 years, but only if you were the original purchaser and got it from SH. They will even check the hardware version number to make sure it matches one that you had previously bought from them. So unless you happen to pick up a used/broken one on ebay that is the exact same version of one that you personally bought from SH in the past (and had not returned), you won't be able to get it replaced.

It should. Try logging off and rebooting the computer. Check to make sure your ISY firmware level and Java control panel are using the same firmware version. Clear your Java cache and reload the java console. Try rebooting ISY. Try updating your firmware. Now I am out of ideas.

2876db is programmable from isy the same as a 2476d is. I don't know what your issue is. Perhaps a factory reset will get you back in order?

The data connection between ISY and PLM is not ethernet. You can not run it into a LAN and pick it off somewhere else. It has to be a direct connection. The fact that it uses an rj45 is just becuase it is cheap and easy and universally available. Of course the ISY to LAN connection is just a normal ethernet connection.

http://apnews.excite.com/article/201201 ... FHR80.html Legionella happens.

You should try a factory reset on the swith and then use ISY to restore the switch. Also, I have 6 of the v27 switches which means that (unless they used that firmware on multiple hardwares) that it is post tact switch problem and probably not a member of the extended warranty. I have replaced every switch that was part of that "recall".

I don't know about that price though. Almost $1000.

I agree. You said your leds moved when you hit the button. The deal with the tact switch is that it doesn't register the button press at all. So if the leds moved, then the switch circuitry received the message that you pushed the button and thus the tact switch worked. But frankly, if you have a switch of that vintage (I have the actaul versions written down somewhere), you will have the tact switch problem sooner or later. And it doesn't need to be consistent. I had switches that would quit working for a few days, then start working, then work every other time, then work if a wacked it, then work normal again for a while, then not work. . . and so on.

It does not sound like you are having the tact/micro switch problem (also referred to as paddle issue). However, if your device is of the vintage that had that problem, it is generally pretty easy to get SH to replace it provided you actually bought it from SH. You don't need the receipt. Just call them up and tell them who you are and where you had it shipped. They keep all sales in their computer. As long as you bought a switch from them of the version you are returning, you should be in luck. It is probably easiest just to tell them you have the "paddle issue". The new switches are a lot nicer and have added features. I had to replace all of my switches and the new ones have been very good.

Now that my ISY is back to work, I just upgraded the firmware to 3.1.17 and was anxious to test this. My conclusion is that it still generates two events. In the following program, the counter is increased by 2 each time the light is turned on: If Status 'Etage / Salle de bain' is On Or Control 'Etage / Salle de bain' is switched On Then $TestCounter += 1 Else - No Actions - (To add one, press 'Action') And the control is always the first event. Sometimes, it may be desirable to combine control and status of the same device, if you AND a control and status from the same device, the program will run only once, and this will be during the control. When the status event occurs, it will run the else, because the control will always be false on that event. Also, during the control event, the evaluation occurs with the status PRIOR to the switch being pressed, not the new status (if that happens to actually change the status). Benoit. Yes, it is supposed to run twice, depending on the situation and how you wrote it, it will run the "then" twice, the "else" twice, or one of each, or it could run just once. Remember, "status" is a trigger when the status changes. If the program runs and that causes the status to change, the program will run a second time. Programs do not ignore the consequences of their own action (or the conseqeunces of actually hitting the on/off switch). When a program triggers, the entire "if" clause is evaluated at that instant in time, then, it is open to be evaluated again. It does not ignore the consequences of it's own "then" and "else" clauses or the consequences of pushing the switch paddle. This isn't a malfunction or bad logic. It is the correct logic. You just have to understand it so you can use it to your benefit.