ergodic

Never mind. I upgraded to 3.1.1 thinking that might resolve the matter. Naturally all I did was break it again. So for the benefit of anyone searching this thread, I simply did what I should have done in the first place: uninstalled both 32-bit & 64-bit Java, deleted all folders and registry entries Sun/Java-ish, rebooted, downloaded & reinstalled both Java editions. All works fine now in ISY-land. In all browsers. Thanks again.

Thank you very much Rand. When I run that it displays the console. Is there some way to get back the browser integration?

They're both installed. I tracked down the Java debug log. It does sort of suggest that the app is started succesfully though it's a bit murky. I'll try it tonight when I get home.

Hah! That's clever. I'll give it a try. Maybe that frame thing again, I'll check task manager and snoop around. The thing that's odd is the Java icon which appears and vanishes (I have it set to always-show and as I remember it's usually there while the ISY console is running, but who knows?)

Since doing an install (clean) of Win7 64-bit Ultimate I'm no longer able to access the ISY99. The Java icon flashes briefly in the task tray and then disappears and no ISY console. This happens with IE8 and Chrome. I've also loaded IE9 64-bit and Java 64-bit with no difference either. Cleared the browser caches and the Java cache, no difference. Nothing in the event logs. Am running AVG Business Internet security, but I disabled online shield and the firewall to no effect either. Everything is on the LAN anyway. Any ideas to try? Any Java log anywhere to look at maybe?

People DO intuitively understand the concept of conditions and triggers. But they understand them - quite correctly - as two entirely separate concepts. And therein is exactly the problem. Unfortunately the current ISY model and syntax largely conflate the two, making it difficult to write even modest programs. All you have to do is look at the various 6-page posts here discussing how to turn lights on and off with motion sensors to recognize the problem. You can do anything with a Turning machine or assembly code or directly enter the binary p-code the ISY generates internally. Anything beyond that is I suppose 'friendliness.' But obviously most people couldn't. Or wouldn't bother even if they could. Which is to say: there are points where 'friendliness' becomes a synonym for useability. So to me, and I happily presume from this post many others, almost ANY change that provides concurrent conditionals and event triggers of equal stature in the ISY programming would be most welcome. If for no other reason simply than it comports with the way people generally think about these things. Variables certainly would be useful, but to me they are definitely second on the list.

You've done this before, I'd guess Thanks & best wishes for the holidays

Upgraded from 2.8.5 to 2.8.7. Clicked OK to close when the upgrade was done. All looked OK. The console closed. I then cleared the Java cache. The admin console didn't show when I restarted. So I repowered the ISY. When I start the console I now get a totally minimized console admin window in the upper left of the screen - which is non-responsive (just dings when you click on it). All that's visible is a small title bar and the window's border. The icon for the admin console appears in the task tray but is also non-responsive. Help!

Thanks. I should say I'm assuming it's an inductive load from the transformer block diagram I have - that waveform looks more like a capacitive load characteristic to me. But the unit is labeled as triac-dimmable (as long as the input is balanced), and so far that seems true. The Foster claims to have some sort of internal protection to handle 15 days of a direct short. And aside from that, the thing's totally potted and about the size and weight of a 200W landscape transformer so I imagine there's lots of margin with a 60W rating. Not a cheap unit either and so the cost of doing RGB with LEDs this way isn't exactly economical, but - stupidly - I just have to see if it's possible.

Thanks. You motivated me to hook up a V2 (V28) Lamplinc and scope it. The first image is on the output at 50% into a pure resistive load. Almost no DC bias with this unit. The second image is the 120V side of the 60W Foster LED transformer, again at about 50% dim with the same Lamplinc. A lot of overshoot, harmonics, and general bouncing around as I'd expect into an inductive load. But still nothing at all worrisome - in fact no discernable shift at all between AC and DC coupling. All things considered a pretty clean waveform. I'm pretty comfortable with using it for this at this point, especially as it will only be at about 20% load. In fact, from what I see I'm not entirely sure why SH doesn't just label for MLV. But I guess that's a complex issue involving NEC 110, UL approvals, etc. etc. and all sorts of other stuff I know little of. Still, it would be interesting to know if there is any kind of phase balancing in the newer units. Looks possible.

I'll be getting new inlinlincs for this.

I'm starting a back patio remodel. The lighting will be connected to the ISY. Part of it will include LED RGB strip accent lighting in various places. To test this, I've obtained one of the Foster 60W dimmable 12V LED transformers, and connected it to 40W of LED strips - a little more than the max I would intend to put on any one transformer. It dims nicely and evenly with an Insteon SL dimmer, remarkably down to about 5-10%. So far, great. Now, these transformers are officially spec'ed for standard triac dimmers only with symmetric forward phase (ie Lutron.) I rather doubt the Insteon dimmers have symmetric control circuitry. But does anyone know? Has anyone actually checked the DC component on the Switchlinc dimmers? I've been using them for several years on my incandescent landscape lighting (running every night at 66%) with no issue other than a minor buzz from the transformer. I'm thinking if I just 1A fuse the 120V side for safety that should be enough. I've already run the Foster for several hours at 50% dim without any meaningful temperature rise showing on my little IR gun. Anyone else tried this?

I have not found internal program delays to be noticeable or even discernable. The delay seems to be the initial response of the ISY program system to the Insteon commands. Perhaps Chris or Michel can illuminate the question better.

ingeborgdot: I'm responding to your PM to me here in the public thread. The logic I posted above on 11/1 is what I'd personally use for the pure ISY program approach, only because it is easiest to understand and easiest to change (for me). YMMV and the other approaches are all perfectly fine. In the end pick whatever style makes the most sense to you. If you want to add the time-of-day to the logic you can do that in the program conditions, in the motion sensor dusk-dawn setting, as a separate enable/disable program, or as a folder condition on M1On/M2On. I prefer to just use programs for everything so I've added the 'enable/disable' approach here. Program M1On If Control M1 is switched on Wait 5 minutes Run Program M1On (Else) Program M2On If Control M2 is switched on Wait 5 minutes Run Program M2On (Else) Program ControlTheLight If (Program M1On is True) or (Program M2On is True) Turn the light on Else Turn the light off Program OnlyAtNight If time is between x and y (next day) disable program ControlTheLight run program ControlTheLight (else) run program M1On (else) run program M2On (else) enable program ControlTheLight Else disable program ControlTheLight run program ControlTheLight (else) run program M1On (else) run program M2On (else) Set OnlyAtNight to run at ISY boot to initialize. If you have the option of a coarse 'on' timing and disabling 'off' in your MSen then I'd recommend it as it will reduce network traffic here.

There are kind of three general ways to deal with motion sensors in the ISY. You can create a scene and simply let the scene and the motion sensor programming control things going on and off. This is the pure-Insteon, non-ISY-program approach. The ISY is just used to create and manage the scene, but it will work even with the ISY turned off. The flexibility here is limited to whatever Insteon devices permit you to do. You can still write ancillary ISY programs to respond to the MS on/off commands in other ways if, for example, you want to send yourself an email or whatever. Second, you can set the MS to on-only and still link the scene, then let the ISY programs control the off side of your logic. The advantage is that you get the instant-on scene response, while still retaining a lot of program control. You also don't have to worry about setting or changing the off timer setting in the MS itself. The downside is that you usually have to write extra program hair to deal with getting "on" commands while your programs are waiting/running. The third way is to just write programs to handle both the on (and perhaps off) MS commands, and not bother with scenes at all. I've generally come to this place, mainly because I get tired of having to round up, open, and set motion sensors into link mode every time I need to adjust the scene or reprogram any device involved in the scene. The small program response delay is barely noticeable and in most cases not an issue. The extra flexibility is worth it to me.

You're right, you can't do this with a single program. Try writing a separate program to track the state of each motion sensor. Then a third program to use that state to control the light's on/off status. So perhaps something like this (I'm inferring from your post the sensors aren't sending explicit off signals.) Program M1On If Control M1 is switched on Wait 5 minutes Run Program M1On (Else) Program M2On If Control M2 is switched on Wait 5 minutes Run Program M2On (Else) Program ControlTheLight If (Program M1On is True) or (Program M2On is True) Turn the light on Else Turn the light off M1On and M2On simply track the state of their respective motion sensor, going false (else) 5 minutes after being triggered on/true. ControlTheLight uses that program state (not the sensor triggers themselves) to manage the light. You'll also need to incorporate a little ISY bootup-time initialization to set the programs' state initially and make sure the light doesn't trigger when the ISY boots. While this is simple, the one problem with this kind of design is that you will be sending Insteon commands down the wire every time a motion sensor or timer triggers, and some of those will be redundant (ie turning the light on when it is already on). You can add more hair (programs) to track the state of the light and get around this. But with 5 minute timers and simple on/off I personally wouldn't worry about it. (If your motion sensors constantly chatter "on" commands like the X10s then that could be a different matter.)

Have you tried the simple, two single-statement program approach? if status sw1 is off then set control sw1 on if status sw2 is off then set control sw2 on I can't think of any reason this wouldn't work to do what you ask, but as with any ISY programming you have to try it. Forget about the time-of-date and date-range checks for now. That can be dealt with easily by adding program or folder conditions. But ignoring the time-of-day, does this do what you want?

First, think hard. Really, really hard. Do you really want Insteon controlling your car's engine? Keep in mind: Insteon is not in any way a secure protocol, nor would I think of it as nearly reliable enough to trust for something like this. Car remotes are not like garage door openers - they are proprietary and specific to particular manufacturers and models (sometimes shared across a few models and model years, but still quite specific to your car.) So you start with the presumuption you need to use a specific remote from your manufacturer for your model, and that you've then programmed to your vehicle. Definitely a DIY project, though not really that hard. Take off the shell of the remote and rig a pair of thin (26ga) solid, insulated wires to each set of switch pads inside in order to be able to electrically toggle the contact(s) for the internal membrane switches you want to activate. You might only need n+1 wires since there is probably one trace in common for all the buttons. Coil up some considerable excess around a pencil so you have slack in the wires when you need to move the remote around to change the battery. And you'll likely have to snap the shell back together to lock the battery in, so ream out some small gaps for the wires to run through when you do that. (This destroys the watertight integrity of the unit, but we're way, way past that.) Now that you have those wires coming out, you connect them to an EZIO or IOLinc and plug that in to the line. Presto! Insteon control of your car. (But again I repeat: be careful what you wish for.) I'd get a small mounting board, put Velcro on the backs of everything to keep them in place together and bolt that somewhere in range you can plug it in. You can use a micro-soldering station to attach the wires. If you don't have that I'd probably opt for conductive silver epoxy - just be sure to clean the contact surface carefully first. Possibly a cold-soldering unit could do it - I personally hate them but here it might be an option. Anyway, those remotes are expensive if you mess it up and have to toss it so you want to be careful. Or... you could put a "halloween finger" (i.e. some sort of relay-controlled poker.) and connect that to an IOLinc and have it push the remote's buttons mechanically. That would be kind of fun to show people at least!

As you've discovered, writing programs is the easy part. Getting them to work right is the challenge. Unfortunately, you have to run back and forth to see what's happening, and you have to be there for that. Besides, where's the fun in having somebody else do it? When I was building our new house, I put in the ISY and some webcams so I could program the system during construction over the Internet from where we were living and see what was happening while I did it. I did it in the AM so as not to irritate the crew any more than I already had. So I get an excited call from my neighbor at about 2AM one morning. "You need to get over here NOW! Somebody's in your new house and they're TOTALLLY SCREWING WITH THE LIGHTS!!"

Yes, sorry. Didn't notice the "status" instead of "control." Three programs might work: Exit P2 true when it is done, leaving P1 disabled and unable to trigger. Then use another, 3rd program that triggers on the status or control change to run P2 else/false, thereby re-enabling P1. It's hard for me to mentally emulate whether the four-program solution works. You can kind of drive yourself crazy trying to chase these ad-hoc solutions, each one often leading to some other, weird, Copernican cycle of yet another unexpected behavior to be puzzled out and patched around. I did post a while back on a more formal method I use to diagram the logic and then mechanically translate that to ISY programs that do what I want. That post is here if you want to wade through it: http://forum.universal-devices.com/viewtopic.php?t=4650 It is unfortunately long, but if nothing else it might help understand how the ISY works. In your case you seem to have just two "states" - or maybe three depending on how you look at it. That would actually be four or six programs using that method. HTH

One problem is that I don't see any parentheses in your condition, which means... Well, I honestly don't know what it means since I don't remember the implied precedence of ISY conditions. But certainly not what you want it to mean. You can just put the program in a folder with the sunset-to-10:30pm condition on the folder and eliminate that test from the program itself. Or use parens to group the condition tests explicitly. The bigger issue is you are changing what you are triggering on. Those device changes cause the ISY to immediately stop the program and re-evaluate the program's conditions all over again. In ISY-land, programs like that almost never do what you want. There are different ways to handle an ISY program interfering with itself. My own suggestion is to break the program into two: a trigger program (P1) and another with the actual program statements (P2). You then add a condition to prevent P1 from re-triggering P2 while P2 is already running. (Program P1): If Program P2 is false and time is between sunset and 10:30 PM same day and (outlet is OFF or lantern is OFF) Then run program P2 (Then Part) (Program P2): If (no conditions) Then Turn outlet On Turn Lantern On Run Program P2 (else part) You can also add a startup statement to your ISY to 'run P2 (else part)' to explicitly initialize P2 false when the ISY boots. This isn't necessarily the simplest solution here; I prefer it simply because it works for all cases as a general ISY technique and it is easy to understand and change the programs. Another solution here would be to break the program into two parts, one program for the outlet and one for the lantern. That will work only because each program then becomes only one statement. So by the time it interferes with itself it is already done. But add just one more device or one more statement to the mix and you're right back to hair-pulling.

A couple of things: As I remember it, "tail" waits - that is a wait at the very end of a program body will be ignored by the ISY. Somebody from UDI can verify that. So usually what is happening in cases like yours is that the execution of the program itself is changing something that causes the ISY to then stop the program and re-evaluate the program's conditions all over again. This 'self-interference' leads to partial execution, oddly repeated executions, all sorts of strange and undesired things. Now if there were a simple program flag in the ISY to say "don't recheck my conditions while I'm running" this would be easy. But there isn't. So you have to code it yourself. Break the programs into two: a test/trigger program (P1) and an execution program (P2) that gets called from it. For example: //(Program P1) If Program P2 is false and (If Status 'Garage Door-Inside Sensor' is Off Or Status 'Garage Door-Outside is Off) Then Run Program P2 (Then Part) //(Program P2) Set Scene 'Kitchen Lighting' Fast On Send Notification to 'Me' Wait 30 seconds Run Program P2 (Else Part) The basic idea is that P1 triggers on the status changes, but only when P2 isn't already active. P2 does the work, but can't get interrupted by P1 while it is running ("If Program P2 is false and (...)"). The last thing P2 does is set itself false, allowing P1 to trigger again. This also neatly solves the problem of the 'tail wait' not doing anything since it is now no longer the final command. Once you get this basic logic in place I think the rest will come together pretty quickly for you. I think what is happening now is that the program is re-executing over and over, but you don't see the lighting change since it is already on. Lastly, you might also want to use a dawn-to-dusk folder condition to save a little testing if you have several programs that are all only active during that time.

For ISY programs like this that require any sort of "memory" or sequencing, I usually diagram what I want and then translate that to ISY programs. I find that if I try any sort of ad-hoc approach I end up with programs that do something like what I want, as well as a raft of weird things I don't want. And I inevitably spend hours trying to figure out why. I wrote a post a while back to explain one method I use in (overly-excruciating) detail here: http://forum.universal-devices.com/viewtopic.php?t=4650&postdays=0&postorder=asc&start=0 Though a little tedious at first, this method gives you what you want, and provides at least a little 'debuggability' - if there is such a word. It also makes it easier to enhance or change things later. In your case, assuming I understand it, you have three states. One idle state (state0) where you're just waiting. A second (state1) where you've received the first (driveway) sensor. And a third state (state2) where the door sensor is tripped while you're in state1. Something like this: State0: (waiting) If Sensor Driveway is turned On then jump to State1 State1: (waiting for door sensor) If Sensor Door is turned On then jump to State2 If Sensor Driveway is turned Off then jump to State0 Or After 1 minute (or whatever timeout) jump to State0 State2: (both tripped) set load entrance hall light on wait 3 min set load entrance hallight off go back to State0 This will translate into 6 little ISY programs. One "condition" program and one "body" program for each of the three states. The condition program for each state is just a collection of all the explicit jumps that can take you into that state. The body program sets all the other programs/states false and then does whatever you want to do in that state. If you wade through the post you should get the idea.

I have been having no real problems to speak of. I was a little surprised that the IR sensor was able to handle a warm bathroom OK, but really no difficulty I've seen. I will say if the steamer is active in the shower the IR doesn't see anything, but I wouldn't expect it to. I put a little X10 keychain button in there in a plastic bag to use if you really want to control the light under those circumstances. It rarely comes up: the shower motion there triggers off a 15-minute timer which is about as long as any normal human could stand being cooked. My biggest problem with the standard X10/Insteon PIR motion sensors is with the *#@! cats setting them off. I haven't seen any directly-compatible Insteon ultrasonic motion sensors. Possibly someone more knowledgeable here knows of something. You could always use a commercial unit like Leviton in conjunction with an IOLinc, but that would get expensive as well as being a pretty bulked-up collection of hardware. I definitely doubt you would find any battery-powered ultrasonic sensor, so it would be a wired-in solution.

I have two or three 2420Ms in my bathrooms to handle the programs, with one located inside each shower. I do keep the screw tightened in the battery covers (unlike my other inside sensors), and they are located up higher where there is less moisture. One of them is actually inside a glassed-in steam shower where I never really expected it to last long. While it probably doesn't do them any good, I've seen no problems for over a year now. If you're really concerned you could probably fashon something out of a clear j-box cover or something like that but it would be kind of ugly and probably not needed.