apostolakisl

Yes, I didn't read what you read careful enough. If you are OK with eliminating the other switches you will probably be OK as stated. You will need to splice wires and then cap the boxes. And if you have 3 switches on the light, you actually have a 4-way switch. And I could be wrong on this point, but I don't think anyone ever wires a 4-way switch by switching the neutral rather than the hot.

I also came to notice that using the light switch as a responder in a scene does not update the responding status in ISY. I had it listed as a non-responding switch in ISY by pulling the disconnect, then using ISY to try to turn it on. Then I reset the disconnect and used another switch that it was in a scene with. The switch in question changed status (and thus presumably should have updated ISY), but ISY continued to list it as a non-responding switch until I used ISY to control it or until I directly pushed it. This was repeatable. Shouldn't ISY have recognized that it was alive when it changed status responding to that scene?

Sorry, not possible. All 3 need to be Insteon.

This sounds exactly like every other STATUS condition, correct? Not exactly. The status of the light as far as on/off/x% does not trigger this program. Only if the status "responding/not responding" changes does it trigger.

Indeed. If Status 'Kitchen / Kitchen Micro-Island' is Responding Then $Int_56 = 10 Else $Int_56 = 5 This program ran false upon my first action taken on the switch after the hard disconnect was pulled and true upon the first action taken on the switch when the disconnect was restored. And changing the languange to "is not" simply swapped when the "then" or "else" happened. And forcing a "run if" after the switch was already in a hard disconnect also caused the "then" or "else" to execute properly.

I was able to get my connection back up. Indeed it appears that "status responding" is not a self triggering clause. I turned the device on/off and querried it and the program never ran. A "run if" got a "true" result. So it is like a regular "status" statement in that it checks the current status in the ISY database upon encountering the clause. It is not however like a regular "status" statement in that it does not self trigger on every change in status. I will pull the gap on one of my switches when I get home and see what happens. I would expect a "run if" to result in a false result provided I first try to communicate with the switch so that ISY has it as not responding in its database. EDIT: after reading the above post which happened during my writing of this post, it appears that he is saying that a change in the status of responding vs non-responding is a trigger. Other changes in the status of the device are not proving to be triggers.

That is, at least, the best working theory so far. If this is the explanation for why it is not returning TRUE when manually triggered, then that aspect of this statement is unlike other STATUS statements, and more like a CONTROL statement in this regards. I would be disappointed if this proves to be the case. I just checked it. It is like "status". I am at the office so I can't pull the disconnect on one of my switches to check what happens when it is not responding. However, unlike other "Status" events, the program does not run when the status of the light changes. As far as I can tell, "status is /is not responding" is not a self-triggering clause. EDIT: I need to play with this when I get home. My remote connection keeps dropping.

No...I find this consistent with other STATUS conditions. These all respond to any CHANGE in status. A CONTROL condition, by comparision, only responds to reciept of the expected (whether ON or OFF) command, regardless of whether this constitutes a change (receipt of two ON commands in a row would, for example, twice trigger the program, whereas only once for a STATUS). Neither will a CONTROL ON condition will trigger from receipt of an OFF command, or vice versa. Another difference is that CONTROL conditions respond only when the specified device is acted upon locally. STATUS will trigger whether initiated locally, or as a result of being a responder to another insteon device. Oberkc: I agree with everything above, with the addition that a STATUS condition can be queried to show the current state of the device. (For example a program with "If Status "Bedroom Light" = ON" can be run at anytime and will evaluate either True or False based on the CURRENT condition of the bedroom light). This is the part that the "Status = Not Responding" doesn't seem to follow (unless I'm missing something...). If I have a device showing a red ! (i.e. not responding), and I run the following program: If Status 'Device' is not Responding Then Send Notification to 'Brian E-Mail' content 'Not Responding' Else - No Actions - (To add one, press 'Action') It should return "True" and execute the "Then" for as long as the red ! is present. It does not do this, and according to TJF1960 this is by design. It should also (as you say) execute the "Then" anytime the device goes from Responding --> Not Responding. This works properly. "is not" means the same things as "is" except it runs the "else" clause. You would want to write your program as follows. If Status 'Device' is Responding Then - - Else Send Notification to 'Brian E-Mail' content 'Not Responding' If you force run the program, then it will be false if it is not responding

In this situation, And vs Or makes no difference. The result will be the same. An "on" command will drive the "then", an "off" command will drive the "else" If Control 'device' is switched On And Control 'device' is not switched Off Then If Control 'device' is switched On Or Control 'device' is not switched Off Then The logic is as follows. This stand alone program has only 2 possible triggers, 1) pushing the "on" paddle 2) pushing the "off" paddle If the "on" paddles is pushed, both clauses will be true. So it doesn't matter if they are connected by "and" or "or" If the "off" paddle is pushed, both clauses will be false. So, again, it doesn't matter if they are connected by "and" or "or" The purpose of the "is not" clause is to have a trigger for the "else" statement. Without the "control is not switched off" line, there would be nothing to trigger the program to run "else". So if you want one thing to happen when the "on" paddle is pushed, and a different thing to happen when the "off" paddle is pushed, you write it this way. The other choice of course is to have two separate programs.

CAI webcontrol is well suited to this. It uses 1-wire and can handle 8 temp sensors on one unit. The CAI has a built-in function for posting to ISY variables. It also has one humidity input, 8 ttl outputs, 8 digital inputs, and 3 analog inputs. ISY can also post directly to CAI variables or directly turn its outputs on/off.

How old are your switches? Some older switches require a power cycle when re-programmed. Try pulling the disconnect tab for 10 seconds and then popping it back in (don't hold it in or you will factory reset the switch. .. which may be the next step in fixing your issue anyway).

I'm not exactly sure what you mean by fast on. I think you mean that it is ramping up at the .1 second rate rather than actually being a "double tap" fast on. To set up a simple virtual 3 way where all the switches do the same thing. 1) Create a scene by clicking "link management" then "new scene" 2) Add the switches. Right click the switch in the main tree on the left and click "add to scene" then use the list of scene names and click on it. Check the box to make it a controller. You can also drag and drop it. Repeat for all switches in scene. 3) Click on the scene in the left column tree. 4) In the right pane in the middle, click "apply changes to all devices" 5) Slide the ramp rate and on level to where you want them. 6) Click on the individual devices under the scene name in the tree on the left. 7) For each device click in the right pane in the middle "copy scene attributes from. . " The 2 key steps are step 4 and step 7. Step 4 makes all the switches respond to the scene command the same. No matter what activates the scene, all the devices will do the same thing (except the switch you actually pushed, it may or may not respond the same, see next step). Obviously, don't click this if you want some switches to do different things. Step 7 makes each switch respond the same as the scene when you physically push on THAT SWITCH. When you physically push a switch, it responds to "applied locally" attributes, not per any scene it may be a part of. Again, don't click that button if you want the button to behave differently when you physically push it vs when it responds to a scene. Trying to break it down, if a switch is a controller, when you push that switch, it does 2 things, it sends out a scene command and it does its own local thing. The scene command is heard by all switches and if the switch recognizes the scene name, it responds. If not, it ignores it. Pushing a switch will always make that switch do what it is programmed to do when pushed locally, any behavior it has related to any scenes is irrelevant. While this may seem complex, it is what makes the Insteon network so uniquely programmable. You can have things behave very differently depending on your desires.

Yes, I now see that the "no variable in "if" comparisons" issue only happens with Elk objects. Variables can be compared with variables. My bad... Off to try 20 programs... One other idea. If you have the network module, you can post the voltage to a file on the built-in ISY webserver. From there, it is a matter of having an application that runs on some computer anywhere in the world that loads that file and then posts it to an ISY variable using the REST interface. Instructions: http://wiki.universal-devices.com/index ... Networking One note however, you'll have to wait for the next drop in the ISY firmware. See this: viewtopic.php?f=51&t=11981

Ouch... I quickly saw the issue with trying to assign Elk voltages to a variable, but the fact that we can't use variables at all on the conditional side of IF Compare statements was a real shock. My backup plan for the inability to assign Elk values to variables had been to create an improvised FOR loop, using IF statement to hunt down the Elk voltage level. Now that is out. Michael - any chance you will add variables for the conditions in IF Compare statements? That would add a lot of flexibility to the ISY, hopefully without a lot of extra effort. As for the CAI, I appreciate the guidance and I may have to go that route. It certainly looks like a good box and better resolultion and variable handling would be nice. The issue for us isn't the cost of the CAI board (that is cheap) but rather the cost of labour for installation and configuration. Its another trip for our electrician to the site (and another power supply, unless we can run it off the ELK databus - anyone know?), another day for one of our techs to learn new product and so on. This gets expensive. Plus it is one more device to fail, so it reduces the overall reliability of the system. So as ugly as it is, it might just be cheaper to write 100 compare programs. So if anyone else has any other ideas on how to get the ISY to interact with Analog values, great. I would be thrilled to get a solution that doesn't involve more hardware. The CAI board calls for 9vdc. From the manual "Any voltage greater than 12V applied to this input may require adding heatsink to regulator, otherwise it may overheat" I have run several of the boards off of 12vdc without adding a heat sink and haven't had any fail. So, using the Elk's 12v power supply is unlikely to be a problem, especially if the board has descent ventilation and is in a conditioned room. The amp draw is small, but I don't know it off the top of my head. If you are at the limit of the Elk, then you will need to consider it. The ISY has it's own 5v outputs so current draw is dependent on if you are using those, which I don't think you are. ISY does have "if" comparisons for variables, it is just that you can only compare to another variable or to a set value. Adding Elk voltages to that drop down menu (both on the condition side and the action side) is your wish. You might just settle on 20 programs with 1000 gallon resolution for now.

Your issue is one that has come up quite a bit recently in various forms. Basically it comes down to ISY lacking the ability to set the value of a variable using Insteon device input values, Elk input values, thermostat input values, and the like. The ISY firmware developers are working on additional variable functionality which may solve the problem, especially when combined with a program that io_guy wrote that logs ISY variable values. As a current fix, you could use a CAI webcontrol board with a 1-wire temperature sensor. Values from that can post directly to ISY variables, where they can be logged using the program from io_guy I mentioned. Also, ISY has added a new function that lets you write logs directly to a file on ISY's memory card. You need the network module for that to work. I haven't played with it yet so the details are not known to me. io_guy has written a number of really great utilities for ISY, there is no charge but he is happy to take donations. http://automationshack.com/

Bitwise operations have been there since day 1. With kind regards, Michel Ah. I just went back and looked at my post from ages ago. . . it appears other people responded to it, not you. The symbols rather than words make it somewhat less than obvious. What about bit shifting? Just curious, why aren't there just words there instead of the symbols. The + - * and / are somewhat obvious, but the others not so much. And also, how about the other variable changes that I have been hearing about. Like being able to compare variables to numbers aside from other variables (like percentage on levels) and being able to use variables to set Insteon devices. Also comparing Elk values to variables or setting variables based on Elk values (voltage).

I started off trying to use the variables, but I can't seem to find a way to assign a Elk voltage to a variable. I can create the IF compares with Elk voltages (as suggested by apostolakisl), but variables seem to be off limits for Elk values. As apostolakisl points out, to use Compares, I need 100 programs Perhaps there is a way to construct some sort of For Loop to iterate for 0.1 to 10.0 and stop when there is an hit. Anyone ever tried that? There just isn't a way to do that. ISY has no way to compare a variable to an Elk zone voltage or set a variable based on an Elk zone voltage. Perhaps Michel will chime in with a comment regarding details of some of the upgrades to variables that are in the works. I have no idea if Elk zones are part of those upgrades or what any time line would be. The CAI board is a pretty simple inexpensive solution and depending on noise levels and the accuracy of your range finder, you will be able to resolve down to 1/100 volt instead of 1/10. Since CAI added the webset function, it can directly post any of its values to ISY variables. You can have it post based on a timed schedule or you can have it post based on the value having changed by some amount, or other parameters which are too numerous and unlikely to discuss here. CAI board only costs about $35. You may also need a case for it if you aren't mounting it inside of the Elk enclosure, and you may need a wifi bridge if it is located somewhere you can't get an ethernet cable to it. Those would be about $35 more.

I had suggested adding bitwise operations quite a while ago but didn't think that it was part of the plan. Do I understand that bitwise operations are going to be added?

I am pretty sure there is no way to get a zone voltage directly from Elk into ISY variable. I think you need to go with the CAI which can internally convert the voltage value to gallons and then post that directly to an ISY variable. From there you can have ISY post the value to an Elk keypad. CAI board does not read milliamps, it reads volts. 0 to 10v is the range, but it is best to not go all the way up to 10v as CAI has some over-volt protection that sometimes interferes. Maybe you can change your resistor to make it more like 8v max. CAI will tell you how to modify the board to remove that protection if you like. It is not complicated. The only other option would be a slew of programs in ISY If Elk Zone 'cistern' 'Voltage' >= 2.9 Volts And Elk Zone 'cistern' 'Voltage' <= 3.1 Volts Then $iGallons = 2221 Else - No Actions - (To add one, press 'Action') Depending on how fine you wanted the resolution, you probably would need 30 or 40 programs, maybe more? Each tenth of a volt is about 220 gallons. So if you wanted to know to within 220 gallons you would need 100 programs to cover the full range of 20,000 gallons.

Yes. http://www.ebay.com/itm/2PCS-Waterproof ... 9167859%26

That is a great way to do it if you only want to measure one temp. If you want multiple temp sensors, you might consider using a cai webcontrol board and the one wire sensors. You may need a wifi adapter too if you don't have any wired ethernet in the area. The combo of all 3 of those things costs about the same price as the Insteon device but gives you 8 temp readings.

It is 40 minutes. Change your repeat to 20 minutes. And you need to do something to make your first program stop. Like "if time is 12am to 6am". Or, you can set the "then" clause to just repeat 12 times and quit and get rid of the second program. If Status 'Thermostats / Downstairs Thermostat' is Mode Cool And $Vacation is 0 And Time is 12:00:00AM Then Repeat 12 times Set 'Thermostats / Downstairs Thermostat' Fan On Wait 10 minutes Set 'Thermostats / Downstairs Thermostat' Fan Auto Wait 20 minutes Else - No Actions - (To add one, press 'Action')

It seems a bit odd that you would want to run the unit for 20 minutes and then go back to the old setpoint. What is the purpose of this? If you aren't comfortable at the set temp, why don't you just change it instead or turning it on for 20 minutes? There has got to be more to this story.

As far as the programming logic, I think that has been well addressed. However: Turning your hot water tank off from 1am to 4:30 is not going to do any good. It won't save electricity/gas. The hot water tank won't turn on anyway if no one is using hot water. It takes many hours for a hot water tank to cool off enough before it will need to re-heat the water when no one is using it. And even if your tank was going to turn on during those hours, it would not use any more energy then as compared to the energy it would use at 4:30 to catch up. The energy savings from your program will be so small it will not be measurable. Shutting off the hot water tank is only useful if you are not going to use it for at least 24 hours. In other words, when out of town. There have been a lot of people who have looked at this issue and they all come to the same conclusion. Cocoontech.com forum has a bunch of threads on the subject. The basic physics is as such: 1) Hot water tanks waste energy by leaking heat through the wall of the tank. 2) The rate of leaking heat is proportional to the difference in temp from the inside of the tank to the outside. 3) Hot water tanks don't lose heat fast enough for the inside temp to be appreciably different after just a few hours of non-heating. Thus the rate of loss is essentially unchanged by shutting down for a few hours. 4) If the tank is inside your house, and it is heating season, shutting off your tank makes almost no-difference in energy use at all for any amount of time. The only difference is if your furnace is more efficient than your tank.

Repeat starts the repeat from when it finishes. For example: If - No Conditions - (To add one, press 'Schedule' or 'Condition') Then Repeat Every 10 seconds Wait 10 seconds $sTest += 1 The above code takes 20 seconds between adding 1 to $sTest.