apostolakisl

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.

Certainly if you had your clock set to sync with ntp at or near midnight it would lead credence to this theory.

Do you have any other programs set to trigger at or just before the time this program triggers? Or any other programs that are running, possibly in some sort of loop? That might explain the delay, but I don't know how to explain a complete failure to run, except if ISY is off at the time. I have had those programs running for a long time (like 3 years) and it has never failed to run, not even once. And you have had 6 in the past 6 months. Of course a failure to run at a specified time would not be specific to any particular program, but I am unaware of any scheduled program not running at the scheduled time on my ISY, though I might not notice some of them failing. I do like your idea to have the program trigger just prior to midnight and execute just after midnight. That is a clever way to leave your "catch up at restart" on without screwing up the date programs. Although I have my ISY on a UPS so it shouldn't be necessary. But ISY just completely blanking on running a scheduled program. . . Hmmm. Another possibility is a bug or error in the firmware. Have you tried updating the firmware? Lastly I suppose there could be a fault in the hardware, but it seems like that would fail more consistently. EDIT: Also, you are quoting the log as your source of runtime. But the log is generated separately. It could be that only the log time is delayed, not the actual run time. Have you checked your "last run time" in your program summary page to see if it is the same as your log time?

It sounds to me like you want to create schedules for your thermostat that are specific to a time of year (season). The following set of programs http://wiki.universal-devices.com/index ... _Variables allows you to create programs for your thermostat that are season dependent. for example If $i.month >= 1 and $i.month <= 4 and time is 8am Then Set thermostat to 70 Else - - So from Jan to April of every year the thermostat would set to 70 at 8am. Obviously you create as many programs like this as you want and include whatever parameters you want. Like if you have weather bug you could have the thermostat also depend on the outside temp in deciding the inside temp.

Interesting item. Do I understand correctly that this product requires that you use their server to use it? If so, is there a subscription or is it "free" for anyone who buys the hardware? And also, are you sol if the company goes belly-up? I have a couple of "chumby" items that are now pretty close to useless since they went belly-up.

Maybe I misunderstood, but I thought the original request was to detect whether the vehicle was IN the garage, not whether it is coming or leaving. Still, if the sensor was off and suddenly turned on, I think one could reasonably infer that the car just arrived. Obviously, a combination of sensors and logic would be required to ensure that it was a car, and not a lawnmower (or a person), but this is an issue not necessarily unique to this particular solution. Perhaps you meant that you would put the gizmo where the car normally sits instead of a couple inches from the door, where they normally are. Basically just an IR beam. That would work, and I suppose you could write some program to ignore if it just briefly gets interrupted (like if someone walks through it) versus if it were continuously blocked for maybe a continuous minute. This actually might be the easiest way to do it if you are willing to accept the outside chance that something besides a car could block it long term.

Except that it can't tell the difference between coming and going, or even if it is just a person breaking the beam as they walk in or out. If there were a wireless Insteon device that you could query, that would do the trick. Just put it in your car and connect it to the battery. Have ISY query it once every couple minutes, if it responds, then the car is there, if not, car is gone. The water detector might do that, but I don't think it is query-able.

The one I listed uses magnetic field to detect the presence of the vehicle, not ultra sound. I only could figure that out because it lists all the sensing specs in units of gauss. I did find how it receives signals. They sell "gateways". Unfortunately it looks like this is a subscription service that costs at minimum $39/year for them to send you texts or emails when the thing is triggered. You might be able to hack it? Hard to say. The usb gateway is $49 and the detector is $79.

I found this http://www.monnit.com/Products/Wireless ... ce-Sensors I can't figure out what receives the 900mhz signal it sends however. The documentation is quite vague on that. I was also thinking of a pad that one of the vehicles wheels would drive onto. This would close a connection which would trigger an IO linc. You could build something like that with a simple open/close circuit.

http://wiki.universal-devices.com/index ... _Variables I wrote this about 2 years ago. I just wrote some programs that do hour and minute a couple weeks ago too. They are in a forum post. All of these programs are most reliable if you have a ups.

There is no "flash" command in insteon, so the only way I know to do this is through a program. I forget the exact program language, but it is something like: repeat three times turn light on wait x seconds turn light off Yes, and if you want it to work so that it stays in the same state. If status basement light is not off and driveway sensor goes off Then turn light off wait 1 sec turn light on If status basement light is off and driveway sensor goes off Then turn light on wait 1 sec turn light off Although I tend to think the second program is not necessary since I'm guessing the basement light off means you aren't in the basement.

As Lee mentioned, those programs I wrote above are using "control". I really should copy real programs to keep things technically correct. They demonstrate the only time you use that combo of "is on, and is not off". This is because "control" programs only trigger when you do the exact thing listed (like push the "on" button of the actual device for a program stating "control is switched on"). Dimming or pushing off will be ignored by the program. That is why you need the "control is not switched off" line, to trigger the program when "off" is pushed. "Status is not" is often times used to encompass all of the states of a device being on. Since "status is on" means 100% on, and you might want to include all amounts of on from 1 to 100%, then you say "status is not off" to include all of those. In these programs status is not off and status is on are both saying the same thing for a device that is either on or off. For a device that could be in between, then the "status is not off" line becomes irrelevant since the program will behave exactly the same without it. It will be true when something is on 100% and false at any other time. It will trigger the same as well (with any change in state).

Including the "not off" statement is to drive the "else" clause. If you don't have an else clause, it serves no purpose. For example: If x is switched on Then do a Else do b This program will never run an else clause. the only trigger is it turning on. If x is swithched on and x is not switched off Then do a Else do b Now switching "off" the device is also a trigger. So, switching "on" runs the "true" and switching "off" runs the "else". Pretty much any time you use "not" anything, you are using it to drive an else clause.

The only way ISY will be able to control speed is by getting a fanlinc. The only possible caveat to that is that you could train an irlinc or global cache unit to shine the ir commands to the fan from a nearby location. This assumes that the remote that came with the fan is ir based.

That program doesn't do exactly what you asked, but it might be what you meant. "(changed from Off to On) I want to wait 10 minutes and check that sensor again. If it is still on I want to send an sms notification." Taken literally, this could mean you want it to ignore any off/on cycles that happen during those 10 minutes. This won't be the case. That program will only send you an SMS if the i/o linc were continuously on for 10 minutes.