apostolakisl

I believe the reason your original program doesn't work is as follows. ISY evaluates everything in an if clause simultaneously. When the program triggers it looks at all the conditions at that moment as a single block. So, lets say it is night, the light is on, and you switch it off. If Status 'Main Floor / Garage Light' is not On <<<< this is false, And Control 'Main Floor / Garage Light' is not switched Off <<<< And Control 'Main Floor / Garage Light' is not switched Fast Off <<< And Program 'Nightime Flag' is True <<<< And Program 'Garage Door Outside Open Flag' is True <<<< Probram evaluates false, else clause is empty, so program does nothing, however light turns off because you pushed "off" at the switch However, ISY then receives a status change from the light to "off" If Status 'Main Floor / Garage Light' is not On << And Control 'Main Floor / Garage Light' is not switched Off <<<<< And Control 'Main Floor / Garage Light' is not switched Fast Off <<<< And Program 'Nightime Flag' is True <<<< And Program 'Garage Door Outside Open Flag' is True <<<< All conditions are TRUE and the program triggered. The light is thus set to "on" Take this program If Status 'Alexis Room / Alexis BR-Overhead L' is Off And Control 'Alexis Room / Alexis BR-Overhead L' is switched Off Then Set 'Alexis Room / Alexis BR-Overhead L' 25% Else - No Actions - (To add one, press 'Action') It runs true when the light is off and you switch it off. But, a split second later it changes to false. The Else clause is empty, so it doesn't matter. But it switched to false because the light status changed to "25%" when it executed its own then clause. The initial act of turning the light "off" when "off" and then the light status comming on to 25% are two different events and thus the program runs twice. In this case, it simply doesnt matter that it ran the second time. In your case, it does.

I have a situation that I control as follows. It is essentially identical to yours, however I also have a included a shut off timer. The timer can be interupted by pushing the "on" paddle (or off paddle), this is what the "if" clause is for in program 3 and why I put the timer in the "else" clause. . so it could be interupted. If Elk Zone 'Gar Overhead Lou' is Violated Or Elk Zone 'Gar Overhead Ell' is Violated Then Run Program 'Garage Lights 2' (If) Else - No Actions - (To add one, press 'Action') ****GARAGE LIGHTS 2***** **THIS IS DISABLED*** If Status 'Garage / Garage-Floures L' is not On And Program 'Dark Outside' is True Then Run Program 'Garage Lights 3' (Else Path) Else - No Actions - (To add one, press 'Action') *****GARAGE LIGHTS 3***** If Control 'Garage / Garage-Floures L' is switched On Or Control 'Garage / Garage-Floures L' is not switched On Then - No Actions - (To add one, press 'Action') Else Set 'Garage / Garage-Floures L' On Wait 10 minutes Set 'Garage / Garage-Floures L' 250 (Beep Duration) Wait 30 seconds Set 'Garage / Garage-Floures L' Off Program 1 and 2 are separated because I didn't want the light to turn on if the door was open and then it became dark outside. I wanted the only trigger for this program to be the opening of the garage door.

This isn't really true. ISY does know how to properly execute programs where control and status refrencing the same switch co-exist. However, there were quite a number of firmware versions that status/control didn't behave properly. This was a result of homes where the communication was one step below perfect. The problem was that if the switch didn't get an ack from the plm, it resent the message causing a faulty running of the program when the PLM thought someone pushed the button again. See this for a more detailed description. viewtopic.php?f=27&t=7622 For example, I have lots of programs like this: If Status 'Alexis Room / Alexis Bath-Cans L' is Off And Control 'Alexis Room / Alexis Bath-Cans L' is switched Off Then Set 'Alexis Room / Alexis Bath-Cans L' 25% Else - No Actions - (To add one, press 'Action') They have all been running perfectly since firmware 3.1.16. Starting in either the last 2. versions or first 3. version these programs started misbehaving. They would turn the light on to 25% virtually every time you turned the light off.

What firmware are you running? 3.1.16 fixed some issues with the combo of status/control combos on the same switch that could have easily caused your probs.

My program is not counting minutes, it is counting 30 second intervals. Divide your final answer by 2 to get minutes. However, it is possible that ISY counts the extra 15 second wait before doing the repeat. So it would be counting 45 sec intervals. I wouldn't think it would, but maybe it does. If you skip the wait 15 seconds it will for sure be counting 30 sec intervals. You could also make it repeat every 15 seconds, then divide the final by 4. The smaller you make your count interval, the more accurate your final answer will be.

How about If status Icon switch is not off and control icon switch is switched on then set table lamp on If status icon switch is off and control icon switch is switched off then set table lamp off You would want to delete the scene connecting the two switches. If the switch were on and you clicked on again, it would turn the table lamp on. If the switch were off and clicked off again, it would tunr the table lamp off. You could play with this general theme using fast on/fast off as well for different combos. But, as mentioned, the light connected directly to the switch will always turn on when you click on or fast on, and always turn off when you click off or fast off.

Can't you Repeat Every 1 Minute and get rid of the Wait? This program will underestimate your light usage by a fair amount depending on your typical length of leaving the light on. If you have a low time on, you will miss most of your minutes. For example, if you only turn it on for 50 seconds at a time, your variable will never count anything. Have the counter click up one in the middle of the time slot and make your time slot shorter, so on average you will undercount the same number of times you overcount. If status light is not off then repeat every 30 sec wait 15 sec variable =+1

probably would want your second program to also have "and elk is armed away" as a provision, unless you want it to shut the lights off at 1130 even when you are home.

I use my elk to detect power failure and make sure everything else is on a UPS... If you have an Elk and the Elk module that is the most obvious and most bullet proof way, but I don't think the OP has an Elk. If conversatons between UD and CAI go well, perhaps we will have a CAI module for ISY anyway, which will make for an great (and cheap) way to have I/O and 1-wire connections across IP for our ISY's.

I did run a couple of SL relays (non dual band) on a ups with a passive coupler coupling the battery back up side of the ups and the wall outlet where the ups was plugged in for about a year with no comm. failures. I don't remember trying the plm on the ups however. Tim Interesting. Did you make the passive coupler or did you purchase something. I suspect you could link it with a capacitor hot to hot across the UPS, correct?

I would like to add another comment pertaining to my above solution. I don't know what happens to an Insteon PLM when you put it on a UPS. Has anyone tried this? Obviously it will not communicate via PLC when it is running on battery (at least not to the other side of the UPS). Has anyone tried connecting to a UPS while not on battery and experienced success or failure as far as PLC getting past it without suck/noise? I imagine there would be problems. This would lead me towards using a non-insteon device such as the cai to detect power faiulres. Running ISY and a CAI on a UPS should not present a problem.

Michel, Both IndyMike and I had similar problems updating to 3.1.13. We both corrected the problem by re-entering our Elk passwords into ISY. viewtopic.php?f=25&t=7401

Lee, aLF, or others, Any comments on how well dual band works while on a non-perfect sine wave? How about the "inverter" style generators. Are they clean enough for Insteon?

In your second program, move the wait 1 second in front of the +=1 line. The reason it is running up too fast is because every time 1 gets added to that variable, the program triggers again and it re-evals the if. You actually don't need the repeat clause at all in either program. They are both getting reset every time the variable changes and the program starts all over from scratch.

That would work. You would want to power the inline lincs with a UPS. You wouldn't necessarily need to have these programs run at startup. If status inline linc generator is on then send email generator power on If status inline linc city power is on Then send email city power on Else send email city power off These programs will run every time the status of the in line lincs change. When you first install the programs or boot the ISY, these will both be "on". No email will be sent at that time if you don't have a "run at startup" checked. If power goes out, both will change to off, and both programs will run, but the first program won't do anything (else is empty). The second program will send the else email (city power off). When the generator turns on a few seconds later, the first program will run again, and this time it will send the then email (generator on). When power is restored, I assume your generator will switch off and back to city power seamlessly so first program does nothing. The second program will run sending the "city power on" email. The cai solution could also work the same and be cheaper, it would only cost about $40 plus some random wall warts you probably already have sitting around. Except, you need a computer running all the time for io-guy's program. However, there might be a chance that ISY adds some direct linking to the CAI board, we shall see.

Nice work. Here is another way. Io_guys program has a "heart beat" it sends to ISY. If the cai is plugged into a regular plug (not a ups), when the power fails the heartbeat will stop. You could use this to trigger an email. Of course your router/modem/ISY would all need to be on UPS.

I went through my box of old wall warts, found one with the right plug, cut it off, and wired it up to my terminal strip 5v lead. The terminal strip is fed by an ATX power supply and powers all of my 5v (and 12v stuff on a second terminal strip). It works beautifully. Very clean, reliable, stable voltage through all amps power supply. And I was able to retire about a dozen bulky, ugly, old, in-effecient second rate wall warts and open all kinds of new plugs.

I do have the elk module and it would appear based on your screen shot that it has added some pages that you don't have. The Elk module appears to add the ability to control what is in your export file. You don't need the Elk module to have the same basic Elk integration that you had before. I assumed you tried hitting the refresh topology button before exporting as well. I assume that hitting that button generates a new export file adding any new devices/scenes and subtracting any removed ones. I am sure Michel can confirm if true. In short, I don't know why you can't connect with your updated firmware. I did not have any trouble communicating with my Elk with the earlier 3.1.<15 versions prior to adding the module. EDIT: WAIT, yes I did. It had something to do with the password. I was not the only one. To fix it, I purposefully entered the wrong one password, saved it, then re-entered the correct password, saved it, and it worked.

Check under Configuration/Elk/Export and add the new lights to the export file. Check under Configuration/Elk/Configuration and make sure the ip/ports are all correct.

but this does not send multiple OFF commands, as reqested earlier. I read this to mean "multiple" as in 3 different lights, not multiple "offs" to each light. Perhaps I am speaking incorrectly to that point, but I think the OP doesn't understand exactly how scenes work. A scene instruction (on/off) sends a SINGLE Intseon power line command. All Insteon devices in your home will hear that command (barring bad communication issues). When a particular device "hears" that command it will check its link records to see if it is supposed to do something (it asks itself "am I in this scene"). If the answer is "yes" then it does whatever you programmed it to do as part of that scene. If it is not in the scene, it just ignores it (actually will repeat it depending on the hop count).

If you really want to monitor your kegerator send me a PM. I have just patented a system for monitoring kegs using a special coupler I designed and a wifi enabled control board. It posts to our webserver and the user can log on and see how much beer is in the keg as well as the temp, all in graphical form over user specified time periods. It does not monitor consumption directly, it monitors liquid still in the keg and consumption is then calculated from that. It also will send email alerts according to user preference. It also has an optional feature for untapping the keg the instant it goes empty keeping gas out of the beer lines (this is primarily for long glycol systems). I am testing the first prototype right now and it is working quite well. Version 2 should be ready to test next month which I will place in our test bar/restaurants (and my own kegerator of course). If that goes well we will go retail in the early summer. It creates usage reports and notifies the distributer for re-stocking as well. The system is geered mainly for inventory control at bars and restaurants, but we plan on having a scaled down version for the private kegerator.

You can do that with a scene but you need to think backwards. Create a scene and put all of those lights in it. Set the level of all the devices that you want "off" when you go to bad as "0". Set the bedroom light you want on to "x%" where x is however bright you want it. Include whatever ramp rates you want on each device. When you go to bed you need a keypad linc or some other insteon device or a program to turn that scene "on", which counter intuitively will actually turn most of the lights off. If you want a delay, you can use slow ramp rates, or you can use a program with a "wait" command. When you get into bed, turn the scene "off", then that one light in your bedroom will turn off, the other lights will stay off.

I would actually tell you to skip the program alltogether and just link the triggerlinc to the light switch. This would do the same thing as the program but do it directly, no middle man. Since you have no delays or other complex issues programmed in, just on when open, off when closed, a direct link would 100% cover you. EDIT: Never mind, I forgot about the sunrise/sunset thing. OK, so try checking your log and see when ISY is receiving the status "on" and when it is sending the "on" to the switch. That would rule out ISY as the delay source. Also, you could try direct linking it to the switch temporarily and see if the delay still exists. I own no triggerlincs so I don't know for sure, but it is also possible that they have a purposeful delay there to prevent false openings from vibrations and the like.

It has been a couple weeks now with not a single malfunction. I believe you have fixed it!

The best way to solve the problem is to have a thermometer that clicks on at one temp and off at another. For example, on at 70, off at 73. Then a simple link would do the trick (no programs). No matter what program you use, you need to set the primary program to run at boot and you will want to run it manually any time you make an edit. Otherwise, if it is already "on" when you start things off and the heater is "off", you will never get a trigger to turn on the heater (a status change, or control on) I think oberkc program will do the trick more simply than mine.