apostolakisl

I know what he is talking about. Sometimes the java console just looses it's connection. It only happens when the java console has been running for a long time, like a day or two. As far as I know, no, when it looses it's comm, you just have to shut it down and re-open. If you are loosing comm often, then you should look into the cause of that, not how to refresh out of it. I have also noticed that sometimes the java consolue starts eating up processor. Again, only if it is up for a long time. Perhaps it has some endless loop running away. If I notice that my fan has kicked into high gear, I will check the task manager and see that java is running the processor at 50% or more. I shut it down and re-open fixing the issue.

There is a "random" box that you can check on the "wait" and "repeat" commands. So, write your program to execute at some time, say 8pm, then the first "then" line is a wait command for say 20 minutes. Then put a line to do something like turn a light on. The result will be that the light will turn on at some random time between 8 and 8:20. If Time is 8:00:00PM Then Wait 20 minutes (Random) Set 'Light' On Else - No Actions - (To add one, press 'Action')

Another way to say this would be that this: If From 7:00:00AM For 1 hour Then Set 'light' On Else - No Actions - (To add one, press 'Action') Would be the same as these two programs: If Time is 7:00:00AM Then Set 'Light' On Else - No Actions - (To add one, press 'Action') If Time is 8:00:00AM Then Set 'Light' Off Else - No Actions - (To add one, press 'Action')

You need a 3.x.x firmware. Don't forget to clear your java cache. You may consider 3.1.10 rather than the most recent if you would prefer to stay clear of all the brand new Elk stuff which still has a few bugs.

Two things: 1) The "fins" are the extensions of alluminum at the top and bottom that extend out further than the width of the plastic housing. They can be snapped off if you are putting multiple switches next to each other, but that reduces the heat sink. 2) The chandalliers you have are different than I thought. I was thinking the small bare-bulb ones with the small base. I think your bulbs may have the full size base (a19). Plus, they look like they are hidden by a decorative glass piece. My point being, if indeed this is the case, you should definitely think about going with LED. You can get 60 watt eq in those bulbs that only use about 10. Insteon works just great with every led bulb I have ever tried and LED's usually dim pretty well. Make sure you get 2700k bulbs, however.

It could be the type of load. Resistance vs Inductance. Usually wattage is listed for resistance loads and amps or volt-amps for inductance. They may also be hedging a little on the wattage since they assume an in-line linc is going to be in a sealed up space.

Questions: 1) I am using 4.6.8 firmware on the Elk. Elk has the 4 series and the 5 series depending on which wireless system you use. I use neither, so 4 or 5 are both fine for me. It seems that most people are running the 5 series. Should I switch? Was the ISY firmware/module designed more for one or the other? 2) Also, my bootware is one revision old. According to the release notes, very little changed. In addition, there isn't anywhere on Elk's website to download the latest bootware. Could the bootware be having any impact? (3.3.2)

I agree. I think you need to go up the ladder. If you have incandescent bulbs, you will need to head up there anyway every 2000 hours of use. I don't think you can switch to led. I have never seen a chandallier bulb that is more than 25 watt equivalent (3 watts). Maybe I'm not looking in the right place. Putting an in-line linc at one or more of the chandalliers is the only option I can see. Or using 45 watt incandescents instead of 60.

Same here I submitted a ticket with access details. Did you try power cycling the ISY?

Did you clear your java cache?

I think I am going to skip the export/import and just re-write the rules as programs in ISY and delte them from Elk. It looks like the module does not include any provision for "tasks". I am trying to figure out how it would work to get ISY programs to respond to a task executed from an Elk keypad.

Is it possible that installing the Elk module has changed the indexing of lights on elk side? Since installing the module, Elk executed rules are now controlling the wrong lights.

So far this all seems very simple and self explanatory. You guys included a ton of stuff, even individual keystrokes on the keypads. The main question I have at this point is what things will act as triggers. So far, everything I have tested behaves as a trigger.

Installed 3.1.12. It needed a power cycle after the install as it locked up. After the power cycle all seems to be fine. Installed Elk module. No problems there. So far so good on playing with the Elk zones/outputs/status'/etc. Just doing some stupid stuff right now. ISY makes the security system say "seven" when I open the back door. Good news is, that is what I programed it to do!

Your program is written properly. I have multiple programs with an identical if section that work. There is something else wrong.

I have several programs like that using icon dimmers, so it isn't the icon dimmer. Just to be sure, check that the program is saved and is enabled. The ISY might not be getting good com with the switch so it may think the light status is not "off" when you are hitting the "off" side of the switch. Check the status of the light on the ISY console before hitting the "off" button. Then check to be sure the program ran by looking at the "last run time" in the program summary page and make sure the program ran.

Please copy and paste the actual program from ISY. In the program details screen, right click on the program in the three on the left and hit "copy to clipboard". Then paste it to the forum. The program should be true any time it is triggered between those time slots by turning on either of those two lights. The other possibility is that you are not turning those things "on" but rather have them at some percentage of on. You could try changing the language to "not off" instead of "on". If From Sunset + 1 hour and 20 minutes To Sunset + 2 hours and 22 minutes (same day) And ( Status 'Kitchen Ceiling Keypad - A' is not off Or Status 'Fam Rm Table' is not off )

Yes, for all intents and purposes, unlimited. It recovers just fine from power outages with accurate time and date. It also will checks an NTP server per your instruction. It also gives you options on how to handle recovering from a power outage regarding execution of programs that may have been missed. In addition, it only draws a few watts (7 seems to ring a bell) so you can put it on a UPS and it could run for days without killing the battery.

You may be having some conflicts. Your program 1 and program 2 share many of the same triggers and could be in conflict with one another. As an experiment, try disabling program 1 at some point during that time period after sunset and then turn on that keypad or lamp listed in the program. I suspect the program will work (must have those parenthesis properly placed). Assuming it does, this points to program 1 as being in conflict.

I don't fully understand what it is you want. But one error I see for sure is that program 2 needs a set of parenthesis. If From Sunset + 1 hour and 20 minutes To Sunset + 2 hours and 22 minutes (same day) And ( Status 'Kitchen Ceiling Keypad - A' is On Or Status 'Fam Rm Table' is On )

If you push and hold the slave switch, that will ramp the master switch up the rest of the way in unison with the slave (and vice-versa). But as Lee said, as far as Insteon commands go, when you click "on", it sends an "on" signal over the power line. And "on" means 50% per your scene definition. Scenes don't know the difference between "on" clicked when light is already at 50% and "on" clicked when light is off. So whichever button you click "on" it will cause the other switch to go to 50%.

There is no way to do what you ask directly. Indirectly you could use variables. io_guy has written programs that set ISY variables from outside sources. Namely, cai webcontrol board and a dsc alarm. The applications run in the background on a pc. So, you could have some other device set a variable in ISY and the variable change would trigger the action. In your example, it would be something like this In your example, the if would say something like if variable x is 1, then turn on light. A second program could be used to turn it off. If variable x is 0, then turn light off. You would use state variables for this so the programs would trigger with the change in the variable. You would need two things here. Another network enabled device that has some way of knowing what to do, and an io_guy style application to serve as the intermediary between your other network enabled device and your ISY.

If you changed your state variables to integer variables, you could turn it into one program. Or just leave well enough alone

Lee, So, again not owning one of these devices, when it sends an "on" statement, is it equivalent to pushing an "on" on a switchlinc? In other words, would simply replacing "status on" to "control switched on" be recognized? This would avoid needing two programs and would keep resetting the 45 sec timer every time it picks up movement and then finish the 45 sec's once 45 seconds with no motion detected passes. Plus the "state variables" need to be changed to integer or else that will mess things up on one of those random days where the variable happens to change state within 45 seconds of motion detection.

Excuse my ignorance here, not owning an insteon motion sensor. But how does it only trigger on "on". Do you mean that it only sends out an "on" PLC command and never anything else? In ISY, a program with an if clause containing "status", will only trigger when the status changes. So, if the sensor only sends "on" commands, it would never trigger the program since it only receives repeat "on" messages. For the program to trigger, you would need it to be a control statement ("if switched on"). But again, I don't know how ISY motion sensors do their com. Your variables being state variables will also trigger the program if they change while the program is running. I don't know what could change them or when, but that is a possibility. Integer variables would not have that problem. I still would bet your motion sensor is changing state during the 45 seconds and causing the program to terminate prematurely. EDIT: OK, I just saw that you included what sets your two variables. I would suggest that you change those to integer variables since I don't see that you ever want them to be triggers.