apostolakisl

I don't have the official Elk keyfob, but based on your description, it sounds like it is not currently a supported device for ISY. Simple solution is to use an Elk rule that turns an elk output on when you hit the keyfob as go-between to ISY. ie Whenever keyfob x is pressed Then turn output y on for 1 second Now in ISY If Elk output y is on Then Set scene z on

I just realized I made a logic error above. So I edited it.

The most common use of "else" command is as follows. If From x time to y time Then set light on Else set light off This program has 2 triggers, the from time, and the else time. At the "from" time, it runs true, at the "to" time it runs false. So the above program would be a simple timer turning the light on at time x and off at time y. You can redo your above program as follows If From Sunrise + 1 second To Sunset - 46 minutes (same day) Then Set Integer variable to 1 Else Set Integer variable to 0 If Control 'Remote Entrance' is switched Off And Integer variable is 1 Then Set 'Condition' On Set 'Foyer' 1 (Beep Duration) Set 'Foyer' 1 (Beep Duration) Set 'Foyer' 1 (Beep Duration) Set 'Foyer' 1 (Beep Duration) Else Set 'Condition' On Set Scene 'ALL LIGHTS and PLUGS - CONDIT' Fast Off Wait 2 seconds Set Scene 'Sunset OUT OF HOUSE' On This fixes the problem because an integer variable is not a trigger. So you don't get the extra triggers of the "from" and "to" times running false. This can be a nice solution if you have multiple programs running on that same time schedule since you can use that variable in all those programs. And an additional solution would be to put your original program into a folder with conditions

Yes...all the stuff on the same circuit are "the same hot and same neutral" whether they're in the same box or not. It's just one continuous flow out from the breaker (along the "hot" wires) and then back to the breaker (along the neutrals). Agreed. Just that if they are both load bearing switches then the watt capacity gets downgraded. Too much heat too close together. Yeah, I've done that. And I never turn the power off either. But I don't suggest those things to other people. By the way, if you so choose to not turn the power off (at your own risk of course), be sure to pull the air gap on the Insteon switches first. The arcing is not good for them.

The xep will almost certainly put your Elk over the current limit if you use the regular Elk power supply and battery. Even if it doesn't, it will bring you battery backup time down. You can download the Elk current calculation forms from their website. So, assuming a UPS doesn't fit in the cabinet, then you will need to mount one outside of it and bring a wire out.

ethernet switch. The Elk can directly send you emails for all of those things. But I know some people can't get Elk email to work because of their email server or whatever. But if Elk works with your email, I would go direct from Elk. The main benefit of ISY email is the ability to input variables like zone status and stuff but you didn't mention that. For sure xep has to be on UPS to get anything sent to you during a power failure except "loss of comm" which would come from ISY.

Is this the only reason you need ISY to keep working during a power failure? Here is what I see. Mandatory UPS item: your router/switches/modem/gateway/whatever stuff you own that makes your internet work Then the either your xep or your ISY has to be on a UPS. If xep is on UPS, then use Elk's email function to send you a text or email when it experiences AC outage (this is a direct rule located under the whenever/misc. system/troubles/AC power failure) If ISY only is on UPS, then use ISY program option Elk/system/status is not connected to send you a message when the Elk loses comm. This of course will be a generic warning that could have other causes beside AC failure, but AC failure would cause a loss of comm if the xep were not on backup power. IF ISY and XEP are on backup power, and you want ISY to send the email, you will need to have Elk trigger a rule on power failure that changes an output (used as a flag). Then ISY responds to the output change by sending you an email. But unless you really can't get Elk to send you the email, this is extra work that serves no purpose.

If all 6 wires are disconnected (both of the 3 way switches were unhooked and the wires not connected to anything), then just one of the 6 wires should have 120v on it. So, if the red in one box tested 120v, and the others are 0v, then indeed that is your hot. There is no other way about it. There are normal ways to color code these things, but that doesn't mean the normal way was followed. But regardless of color, there will always be 2 travelers and a load at one box, and 2 travelers and a hot at the other. There is no other way for standard 3 way wiring to work. So when in doubt, it always work to actually test. Here is the theory: Both switches need an unswitched hot. In a 3 way switch, you will only have this at one box. You need to find that hot and connect it to one of the travelers. Now what used to be a traveler, is an unswitched hot providing the second box with its unswitched hot. Both of those hots are use to power the insteon switch and thus connected to the Insteon black wire. The other traveler wire will typically not be needed and should just be capped at each end. The neutrals are local to both boxes and will be connected to the Insteon neutral. If by chance one box did not have a neutral, you could use the other traveler to bring neutral over. Finally, the box with the load gets connected to the Insteon red (this is where the switch outputs power when you turn it on). In the other box, the Insteon switch has no connection to any load, so you MUST cap off that red wire. Whenever that switch is on, the red load wire on the Insteon switch will be hot.

Specifically, how I used the resistor solution is as follows. I used some old christmas tree lights and cut the wire off about 1/4 inch from the passthrough plug. Then I soldered on the resistor and sealed it up with some heat shrink insulation. I made a couple to have around Then you plug that into the lamp linc and then whatever else you want. It pretty much is the closest thing to an invisible cure for this problem without cutting into your actual load device.

From what you said, you have neutrals. It is very hard for someone who is not there to make heads or tails of the wire colors and if they are jacketed together what that means. If you follow the protocol I spelled out, you should have success no matter whether the wires go through the load box or go directly from switch box to switch box with another wire going off to the load box.

The big "if" that you have here is: do you have a neutral in each box. This will be a white wire and it will not be one of the 3 wires connected to the switch. If you don't have any whites like this, then you really don't need to read on. Just let us know about that. In a triple gang box, you will usually have several of them spliced together and tucked in the back of the box, not connected to any switches. In a 3 way switch, at one box, one of the 3 wires is "hot", or in other words, always has 120vac. At that same box, the other 2 wires will be travelers (wires that run between the 2 boxes). At the other box, 2 will be travelers and the third is the load. NOTE: Travelers can be black and red, or black and white with the white re-purposed as a hot. They should have tagged a white used like this, but probably didn't. Also, the traveler wires may run through the box at the lamp and may be spliced. So, just because the travelers are black and white at one box doesn't mean they will be black and white at the other. Basic procedure to figure this out in most cases. This requires a multi meter. This also requires working with hot wires, so if you aren't skilled to do this, hire an electrician. 1) Turn off breaker 2) Unhook both switches completely 3) Hang the wires out of the box with the bare ends well away from anything else and put wire nuts on them. 4) Turn the breaker back on 5) Uncap the wires one at a time and touch your volt meter to the bare metal tip and the other lead to the bare ground wire in the box. 6) You should find that one of the 6 wires is hot. Tag it as such. 7) Turn the breaker off again. Now you need to figure out which is the load (wire to the light itself) and which 2 are the travelers. In the box with the hot, set your meter on ohms and attach it to the 2 wires that aren't the hot (leave the hot capped off). Then have your buddy go to the other box and touch together the wires, 2 at a time until you see the circuit close (ohms drop to ~0). Now you know those 2 are the travelers, tag them. 9) Now you know the only wire left over goes to the load, tag it as such. Now putting your Insteon switches in. 1) Connect your Insteon Neutral to a neutral in the box. This is a white wire in the box that is NOT connected to a switch. Usually in a 3 gang box there will be several of them spliced together and tucked in the back of the box. 2) Connect your ground. 3) In the box with the hot, connect one of your traveler wires (use a black or red), the Insteon hot, and the house hot together and cap it off. 4) At the box without the load, cap the red wire on the insteon switch 5) At the other box, connect your ground and neutral the same way. 6) Connect your Insteon load (red) to the load wire we labeled earlier in the box. 7) Now you have 2 figure out which of the 2 travelers is now your new hot. With both wires capped, turn the breaker back on. Your first switch should turn on. Now at the other location, uncap one wire and touch your meter (now set to volts) to the wire and the other lead to a ground. If it reads 0, test the other. One of them should be 120vac. Once you know which it is, cap it and turn the power off. Now connect that wire to your Insteon hot. 9) Turn power back on, both switches should light up. The switch at the load will have control of the light. The other switch will need to be linked using your ISY to create a scene for it to work.

No harm in rebooting the ISY and PLM. I suspect that this won't fix it, but nothing lost by trying. I don't know why the Elk would be causing this. But again, no harm in temporarily taking it out of the equation and testing. Since my system runs the program fine, and since I also have an Elk with the Elk module, if Elk is somehow the problem for you, it is not an inherent problem of the Elk/ISY system. If this proves fruitless, I suspect you would need to start an official service ticket with Michel. The fact that you can run the program fine with your 6 button kpl makes me doubt it is any kind of general system issue such as an overloaded processor from something running in a loop or getting overwhelmed by some Elk bombardment. It also makes me doubt it is an ISY issue since ISY doesn't really handle a "control on" command any different on a switchlinc vs a kpl.

Remember, provided you don't make any changes to your devices after installing the 994i, you can always unplug it and plug the 99i back in and nothing will have changed. So, I wouldn't bother waiting to start running the 994i.

The simple way to do this is to use the weatherbug module. At my home weatherbug is almost always within 1 degree of what my thermometer reads outside my house. Other options are more complicated and go along with the discussion related to the freezer/fridge monitoring you posted on. Another option is to use a CAI board and one-wire temp sensors. It will need an internet connection so you either pull a wire to it or you need a wireless bridge. The new firmware can post values directly to variables in ISY without any outside intervention. This is relatively low cost. . . around $50 without a wifi bridge, add another $30 or $40 for that if you need it. Also, if you have an Elk security system and the Elk module you can use Elk sensors. You would also need to pull a wire. Elk temp sensors are seemingly overpriced to me at nearly $100 and they will need an open zone on your panel (I also believe it has to be one of the 16 main zones) Otherwise you would perhaps use a system that reports to a PC which then posts to ISY.

Vyrolan's approach is excellent. By including a "control not fast off" in the if clause he has created a second trigger (fast off). In the event that a "fast off" command is received, the program re-triggers. A program that re-triggers always terminates any current activity (the wait clause here) and starts over from scratch. Since the "fast off" is preceded by "not" this results in a "fast off" command received causing a false if condition which runs the else clause. So, in summary, if upon leaving the house, should you do a fast off on that switch, the wait currently running terminates, the program re-evaluates to false, the else clause runs, and the lights shut off.

This is a bit complex to try to describe the logic behind all this (what Lee said), but I'll try. Devices need to function independently because each device can be the member of a great number of scenes. So you could not have it that a device turning on turns all other linked devices on. If this were the case, anytime a switch turned on, every device linked to that device as part of any scene it had membership with would turn on. The result would be that there are no independent scenes and it would be the same as hardwiring all the switches together ala typical 3/4 way wiring. Insteon uses "controller" and "responder" designation to make this work. When you phyically act on a device (push the button), the device itself always responds, and, if the device is a controller of a scene, all the other devices in that scene respond as programmed to. A device can only be a controller for one scene. If you think about it, you will realize that if a device were a controller for 2 scenes, you will have effectively just merged those 2 scenes into one scene. So no point in that. When a device turns on as a responder, it is not the same thing as turning on by direct action on the device. If it did, you would realize that should that device be a responder to one scene, and a controller of another scene, the effect of a device responding to one scene by turning on, would then propagate through to any devices that the switch controlled, which could snow ball through your setup potentially turning every device in your system on. Also I will point out, when you turn a device on using ISY, you are turning the device on as a responder to a scene with two members: ISY and the device. ISY is the controller of that scene. All devices added to ISY are a member of at least one scene, the ISY scene (technically it is joined with the PLM). ISY is unique in the sense that it is a controller of multiple scenes. The reason for this is that ISY can uniquely control all those scenes independently. So in the end, there are two ways to turn a device on. Either directly act on it (push the button), or turn a scene on that it is a member of (either via ISY or using another switch linked to it as a controller).

I just wrote that same program for one of my switchlincs and it works perfectly. It's v38 2476D. So, I don't know whats up. What switchlinc are you using? If I have any of the same ones I'll test them.

I agree with what Lee is saying in principle, but am having a hard time thinking of what other program would interfere like that. Perhaps the variable is going up but another program runs off the same trigger and drops it back down. With two programs running nearly simultaneous, you would not see the up, down, it would appear to stay the same. Well, when all other programs are disabled, we will know soon enough. Also, you can look at the last run time on all of your programs and see if any other program runs at the same time this one runs. Also, that program should always run "true". It might be worth checking that indeed it is always stating "true". A program whose only "if" line is "control on" can never be anything but true (at least not without some other program doing a force run of the else clause).

Hmmm, Well, if the keypad linc executes with every "on" press, this would seem to indicate the ISY's execution of the program is not where the problem is. A switchlinc should also send an "on" command with each press without having to wait 5 seconds (also realize that 2 presses very quickly will send a "fast on" rather than an "on", but to do that you have to double click in a fraction of a second). If you open event viewer and set it to level 3, you should see an entry every time you push the button. If every press does not produce an "on" event in the viewer, it is either not being sent by the switch, or not being received by ISY.

Also, is this program in a folder? And if so, does the folder have any conditions?

Status only triggers with a change in status. So once it is on, it would have to be changed to some other status then back to on to run the program. Control on should work. I can't really think of any reason why it is only running every other time. Try changing the program to a different switch and see if it also only runs every other time.

Is the program running every time? Take a wifi laptop with the admin console running and watch the program summary page and see if every time you click "on" the program updates the run time.

I have been thinking about this. I have a couple of the wireless modules that post the temperature to their servers and can be pulled down. Can the ISY be programmed to poll a website with some of the extension modules? Refresh this page to get the latest values for your TX-60 devices. Name Probe Device Hum Last Seen Batt Link Greenhouse 31.2 °F 30.2 °F 86% 12/18 10:19 PM OK 100 % Shop 64.5 °F 45.6 °F 64% 12/18 9:25 PM OK 100 % ISY can receive data via GET commands. I don't believe any module is necessary to do that, but it might require the network module. If you want ISY to initiate the conversation it would need to be generated by an ISY network module posting to your server which then runs a script that separately runs a GET posting of a value to an ISY variable. In other words, you can't query a table of values and then have ISY parse it out.

Large scenes should not pose a problem and in fact should alleviate problems. A mix of device types should also not be a problem. When a single activity (like a going to bed activity) puts all devices into a single scene, there is only a single Insteon command to run that activity. One command means less traffic which tends to reduce problems.

A webcontrol board would do the trick, but you would need to have it on a UPS (as well as your ISY and your router/modem/gateway). You also would need to find a wired pathway into the fridge. The Lacrosse technology wireless thermometer/humidity sensors work quite well, even when closed up in a fridge. The battery lasts many many months (perhaps more than a year). However, I have yet to figure out a good way to get the data out of the receiver and into something else (like ISY) automatically.