apostolakisl

Generally speaking, ISY is the place to put your programs. It is much easier to organize them and edit them. ISY is more versatile and actually lets you do more with Elk's own stuff than Elk can do it. Like include zone status in an email or text. ISY also has way more programming space. Of course this is only possible with the Elk module. Which I highly suggest. The only caveat is that if your router goes down, your Elk and ISY connection will go down. So I would avoid putting any program that is mission critical in ISY. Like arming and disarming functions. Also if you are controlling outputs that do things that could go horribly wrong.

That's interesting to hear. I had wondered about that and even asked it before but it never was responded to. Is that number published by SH?

I do the same thing and it works very well. I do a bench test on all my new devices and program them prior to installing them. In the event of a defective unit, it saves the hassle of installing/uninstalling/reinstalling (which can be quite the PITA in a multi-switch gang box). Just remember to cap the red wire as it becomes hot when the switch is turned on. And of course don't plug it in until after all the wires are connected and capped.

I kind of assumed the switch was dead based on your original post, but now that I re-read I understand that the double tap worked. The simplest thing to try first is just pull the hard disconnect on the switch for 5 or 10 seconds and then push it back in. If that doesn't work, try factory resetting the switch and restoring it with the ISY.

It is possible that the hot for that switch is daisy chained through one of the boxes you were working in and you may have inadvertently disconnected it. I would suggest pulling the non-working switch and checking the hot to see if it has power.

If From 5:00:00AM To 11:50:00AM (same day) Or From 7:05:00PM To 10:00:00PM (same day) Then Run Program 'Hot Water Loop' (Then Path) Else Set 'Garage / Garage Hot Water' Off Stop Program 'Hot Water Loop' Also, I am not sure what you meant with this? Then Repeat Every 1 minute Set 'Garage / Garage Hot Water' Fast On Wait 8 minutes Set 'Garage / Garage Hot Water' Fast Off Wait 2 minutes By putting a wait 2 minutes at the end, then having it repeat every 1 minute, it will be on for 8 minutes, shut off, wait 2 minutes, then wait 1 minute for the repeat, then turn back on for 8 minutes. It would be cleaner to do the following Then Repeat Every 3 minute Set 'Garage / Garage Hot Water' Fast On Wait 8 minutes Set 'Garage / Garage Hot Water' Fast Off

Did you get the rolling code model? If not, and your vehicle buttons are currently programmed with rolling codes, then it won't work. You would have to erase your vehicle memory and reteach using a non-rolling code hand held remote and then use your vehicle or that same remote to teach the liftmaster device you just bought. I received my two devices several days ago but have just been too busy to hook them up. I got the rolling code model.

OK, now I get what you are asking. ISY started supporting that function a while ago and that issue was discussed back then. There was never a good answer as far as I can recall about setting the brightness of the led's on the switch. It would make sense that 255 is as bright as it gets and 128 is half as bright and so on. But it doesn't follow that logic and I don't know why and I really don't know what the actual logic is. The handful of switches I have altered the led's on I just did random trial and error until it looked the way I wanted. And you do have to realize that Insteon switches that are a bit older don't support that function at all.

Do they all have the same exact bulbs? LED's and compact fluorescents differ by manufacturer/bulb model as to the progression of lumen output as the input voltage goes up. Two bulbs may look the same at 100% but very different at 50%. I would assume that 2 Insteon switchlincs at the same % brightness would both put through the same voltage, but Lee has indicated that different firmwares aren't the same. I don't really know anything about that. It seems to me that it would be pretty dumb for the Insteon folks to have done that. But I wouldn't put it past them. OHH, I just read your post again. Relays are either on or off. There is no 50%. If you send a 50% on to a relay it just turns on. It is after all a RELAY, not a dimmer.

0 - 255 is 256 possible values which is 2 to the 8th power which in computer binary talk is 8 bit which means ISY developers chose to reserve 8 bits worth of memory to store the value. 0-255 represents 0-100% brightness. You can do the math to figure out the percentage. Be advised that just because the Insteon switch is turned half way up doesn't mean the lumens are 50% of full brightness. This mostly works with incandescent bulbs but fluorescent and led operate a bit differently.

The only way I know is to not have the bulb connected to the load of that switch but rather a different switch or inline linc.

Power a relay off of the light bulb socket in the garage door opener. Connect the relay to an IO linc. The ISY can then monitor the built-in light on the garage door and thus know when it has operated. Or, you could just use the sense portion of this. http://www.smarthome.com/2475S2/INSTEON ... nse/p.aspx You would need to use the garage door openers light power to trip the sense.

Blake, As Lee mentioned. Be very careful using "wait". You need to look at every line of your "if" clause and if any of them could trigger during the "wait" it will reset the program and the "wait" will end. You can do this on purpose, but it tends mostly to happen as an unintended issue that causes your program to behave other than as intended. Using a wait on a program where the only "if" is something like "time is . . ." will not be a problem since the program would not be re-triggered (unless your wait is more than 24 hours). Using "status" or "control" in your "if" clause could be trouble. If the status of the light changes or someone pushes the switches button, the wait will end right then. Again, this can be used on purpose. To use "wait" where you also want other if conditions that might re-trigger, you need to write two programs where the first program calls the second program containing the "wait".

The error log has no errors since August 3. There was a stretch on Aug 3 lasting several hours where there were a ton of errors including lots of ntp errors. Probably my internet was down or something. I opened the console this morning. The clock on the console seems to be the problem. I opened it at 6:51:50. Over the course of the next 6 minutes, the clock only ticked forward by 11 seconds to 6:52:01. Mostly it is just sitting there doing nothing, but every once in a while it ticks forward a tick or two. For example, in the time it took to write the last couple sentences, the clock still says 6:52:02. Otherwise the console is working like normal. EDIT: It is now 7:36 and the console clock says 7:01:48. It is ticking now roughly 1/sec. Since it appears to be the console clock only, it isn't that big of a deal. But during program debugging it is pretty inconvenient to not know what time the system clock thinks it is. EIDT:Now at 7:56, the ISY clock is showing 7:54. So somewhere in there it must have updated to the system clock, but still has fallen behind again. EDIT: The console clock has stopped ticking again. But if I open the "configuration" tab it syncs to the ISY. But it still doesn't tick. If I go to a different tab, then back to the configuration tab, it updates again, but again still doesn't keep ticking. EDIT: I opened the java console on my office computer and logged in. It is displaying the same behavior.

The error log has no errors since August 3. There was a stretch on Aug 3 lasting several hours where there were a ton of errors including lots of ntp errors. Probably my internet was down or something.

I don't recall how long the console was open. Perhaps a day, perhaps a few minutes. I just did a test. I opened the console a couple hours ago and hit the NTP update. The clock was off, but I didn't notice by how much. I closed the console and then just reopened it (about 2 hours later) hit the sync button again. The clock corrected by about 15 seconds. So either ISY clock is running quite a bit off or the NTP server isn't giving good numbers. I'll try again in another hour and see what it does.

I am pretty sure the 315mhz does not use rolling codes. I did buy two of the ones with rolling codes off amazon for a total of $46. So you only save about $10 going with the non-rolling model. Also, don't forget, that you will need to be able to train your car. The only way to do that is to have an RF transmitter that works on the 315mhz system.

I believe that is the same thing that caused my programs to misfire. But another possible issue. I just noticed that the clock was off by over 10 minutes. I have it set to sync with ntp every 24 hours. I clicked the "synchronize now" button and it successfully updated and corrected the time. But that begs the question. .. how was it 10 minutes off if it is syncing every 24 hours. It should have at least one sync since I updated the firmware.

This firmware appears to be bug free in my applications. The issue with improper "true" execution of the "if status off and control off" programs has not happened since the upgrade. The Elk module is working well and is populating the values at start up. Thanks.

Correct me if I'm wrong, but that x10 rf device is not rolling code. Assuming I am right, I would avoid using that to control your alarm system. I found this on amazon. http://www.amazon.com/635LM-Craftsman-L ... B000F5IL7Y It is rolling code and only $25 with shipping. It will connect to the IO link you already have so $25 should be your only cost. I think I might get one myself.

Your car almost certainly has a homelink system. You need a homelink receiver. They make kits designed to convert non-homelink garage doors into homelink garage doors. This same kit could instead be used with an IO link. These kits start at about $70. Maybe you can find one cheaper. If you can figure out how to tear apart an old homelink compatible garage door opener and use the receiver, then go for it. But the time involved may not justify the $70 savings. EDIT: I just googled it and found a "lear car2u" device that seems to be what you want for about $25. I didn't really scour the instructions but at first glance it appears to accept the rolling codes from homelink to close a momentary contact (which you could connect to an iolink) EDIT: Also this one looks like it should work http://www.northshorecommercialdoor.com ... nplre.html

I don't know how to directly turn a device off with a REST command. But you can quite easily program the ISY to respond to the change in the variable (executed by REST) by programmatically creating an "off" command. If $sTest is "x" Then Set Scene 'Test Light' Off Else - No Actions - (To add one, press 'Action')

Upgrade went smoothly.

So you are saying that the Java console is expecting something from the ISY and not getting it. Thus it shows the red flag and greys out. But the Java console is still sending commands that are reaching their destination. So, assuming I understand correctly, what would block it the comm in just the one direction? And why would it not block all the time?

Hi Lou, This is key because a loss of connection definitely explains the blinking problem, so I'm wondering if your Elk connection has been dropping off more often with the new build. In looking at the code, we weren't always do a query after reconnect, so we'll fix that. Is it possible for you to recreate the problem without the connection dropping? WOOOOHOOOO I FIGURED IT OUT. OK, so here is the deal. I switched to U-verse last week. U-verse appears to either be blocking port 25 or the old dns server address I had it set to may not have worked since it was a road runner server and I was no longer on road runner. Either way, the would hang when it tried to send an email. Since I have it set to send me an email every time the system arms, it was hanging every time I armed it. Eventually it recovers, but not until after the exit timer finished. . .and thus the exit timer completion message never gets through. Sorry to trouble you. But, hopefully you will find this sort of info helpful. Frankly, I find the xep to be a pretty temperamental item. I have never had something crash so often when the settings don't work. It took me close to 2 hours to get it working since I had to reboot the thing like 20 times at like 2 or 3 minutes per boot. ERRRRRR. If you hit "test" on it, and it doesn't like the settings, it just crashes and reboots.