ergodic

FWK, LeeG is correct. I've done this more than once with no issues. (If the LED blinks fast it is normally a comm issue with the PLM in my experience.) I've more or less moved most of my motion sensors to programs, but I still have a bathroom with two scene-linked MSen (one inside the shower) and it works fine.

What ISY manual would that be? Again, if a simple design change can reduce confusion and make things more intuitive without affecting anything existing, where's the harm?

All I can say is review again the endless, continual posts about it on this forum. Call it my opinion if you like, but I sense an awful lot of company. And I'm not exactly a newbie. When something has to be explained over and over and over and re-examined over and over it's a pretty good clue that something's not right in the basic design. And understand, I'm not saying ELSE isn't useful. A bifurcated THEN-ELSE logic is great when you need it. And when you don't need it, you get it anyway, and that is plainly confusing to no good purpose. Especially given the limited debugging available in the ISY. You own posts on that latest thread illustrate the complex subtleties of this, and you're hardly a newbie either. I'm only saying is there should be the option to not have the ELSE. That's it. Keep doing it they way you are, nothing changes. But programs without an ELSE wouldn't self-cancel and so will work the way most people expect them to. Where's the harm? I would pose a question: what percentage of successful consumer tech devices on the market these days require you to carefully "read the manual?"

For situations where you the the ELSE clause is useful, I'd agree. The problem is that the semantics of the ISY ELSE also are a source of endless, baffling confusion. (As evidenced by yet one more current thread on its convoluted logic http://forum.universal-devices.com/viewtopic.php?f=27&t=12160 that would do Bertrand Russell proud.) Most people's minds simply don't work this way. I've been programming the ISY for years, and I still have to sit there and think about "If On AND NOT Off..." Apparently so do many others. What would be most helpful is to be able to simply delete the ELSE clause. Or just make that the default and allow one to add one. This obviously wouldn't affect existing programs or the ability to use an ELSE if you want to. But programs with no ELSE would only evaluate their THEN clause and start or re-start execution if true as one would expect. A FALSE evaluation would have no effect. The ELSE is not used more often than it is used, yet as currently implemented a null ELSE affects execution in some often unexpected ways. In this case one could define such a program as always TRUE. Or I think much more usefully as TRUE when it is executing and FALSE otherwise. So it could still be used as a status test.

LeeG is right - using program state as a true/false indicator is mostly obsolete. There is a newer (and better) methodology using variables here: viewtopic.php?f=26&t=6395 A number of people have made nice refinements to this since, regrettably I don't have those links but they should be easy enough to find.

Whazza "2334-2" and a "5-button dimmer"?

FWIW I ran this test on both an SL dimmer and a 6-button KPL using an integer (non-state) variable. It behaved as I expected, incrementing the variable by 1 on each "on" press, regardless of the current state of the device. (This was ISY FW V3.3.7 -- The SL dimmer was V.38 and the KPL was V.36) I regret I can't come up with idea that would explain your particular anomaly with this. But ISY problems can be very subtle. Make sure you have reasonably recent firmware.

I had a very similar problem after installing a whole-house generator. I wanted it to message me when it tripped on or off. The problem is that as the generator fires on and off, the AC output wobbles around before finally settling in at a steady 120V. Because of that AC spiking, the InlineLinc I installed to sense generator power and then trigger the ISY to send messages would fire off about a dozen messages each time the generator turned on or off. ("Generator is on"... "Generator is off"... I wrote programs to smooth this out. Which is what I think you're looking to do. So quite possibly they will be of help. That post is here: http://forum.universal-devices.com/viewtopic.php?f=26&t=8805&p=66991&hilit=generac#p66991 You may need to adjust the wait times for your situation.

The answer to your questions is mostly "yes". What you want is a "Set to At Least xx" command. You can't of course accomplish this with Insteon scenes as they aren't sensitive to the current state of the device. So, yes. You would need to create little programs for each light you want to check and possibly change or not change. As LeeG says, this isn't exactly elegant. But at least is isn't all that difficult. The skeletal ISY program logic would be something like this: If Then run program 'SetDevice1' (If Part) run program 'SetDevice2' (If Part) ... //program SetDevice1: (Disabled) If Status 'Device1' < 30% Then Set 'Device1' 30% //program SetDevice2: (Disabled) If Status 'Device2' < 50% Then Set 'Device1' 50% ... It is important that these little "SetDevice#" programs be set to Disabled so they can only get activated explicitly by the main, triggering event program. You do not want these programs activating or self-activating every time status of the device changes. In the end, whether this kind of thing is workable depends mostly on how many devices there are, and whether the small program delays bother you. If you do try it out, you should give it a little time to see if you get used to the small lag time - we all have.

I had this problem quite often with my 99i at some point after V3 firmware came out. Though mine behaved a bit differently -- restarting the admin console would eventually fix it, but I'd sometimes have to restart 3 or 4 times. As in your case it was not an security software or firewall problem, and the ISY itself worked fine. As I understand it, it isn't a comm problem as such, but rather a problem related to subscribing the ISY. Michel can probably offer more insight into this. The problem vanished as soon as I upgraded to a 994. I have not seen it happen since that. I did post on it in the firmware threads somewhere.

Sure. The variable was just to illustrate the general idea. Once you trigger off the status you should be able to have the program do whatever you want.

If you do a program "Status" condition on a KPL controller or responder button in a scene, the program will trigger when the scene triggers the status change on that button. For example: If Status 'KPLTest A' is switched on Then $Var = 100 Else $Var = 0 Presuming "KPLTest A" is linked to the scene, the variable $Var changes between 0 and 100 as the scene is switched off and on. This is true regardless of how the scene is initiated since any way it happens will change the button status -- assuming it is a controller or responder in the scene. Note this doesn't work if you use a "Control" test instead of "Status". And of course if you remove the program-triggering button from the scene you still need to update your code to sync with that change.

ELA: I can tell you in my case the fluorescent issue was definitely noise. I tried two different electronic ballasts and scoped both. One that came with the fixture and another I bought at the local wholesale electric. The backfeed powerline noise from both was absolutely incredible. (I actually started laughing when I first saw it.) If you could post your ballast mfr/model/part # -- the ones that work with Insteon - it would be useful info. With Insteon it is usually easy to check if there is a noise problem. Just turn the the circuit off. If the comm. problem goes away it is almost certain to be noise. With the two ballasts I tried, everything worked fine as long as they were off. My guess is that a magnetic ballast would not cause comm problems - it never did in my previous house, but those are almost impossible now.

ixlr8, good to hear it worked out. Also, it may not help much, but take a look at a Crestron or Control4 to see what a home automation control system can really cost. It's no fun to spend $140. But it beats having to hire somebody to even do it. I can second the LED suggestion. The dimmable LED bulbs are getting very close. I've just installed the FEIT floods (sold at Costco) in all my outside soffits. The warm white looks very nice outside, and they use less than 1/5 the power of the incandescent floods I had in there. Given that they're on about 50% all evening, they'll pay for themselves in a few months at my marginal energy price here (about 32 cents/kwh). They also dim down almost to off, and no detectable Insteon interference so far though I'm still checking that. I think these would work well in a shop environment, and I'm thinking about replacing the fluorescents in my garage with these too. There's also a FEIT narrow-angle spot (the light from that is noticeably bluer though). And of course LEDs don't give off that life-sucking illumination of fluorescents or CFLs. But at $20+/bulb, this route isn't exactly cheap either, though of course you benefit from the lower energy cost if you use them a lot. I still haven't found a decent LED replacement for my inside 12V halogens MR16s, though I keep looking. Most of the ones I've tried have stupid little fans inside for one thing. They also don't dim well at the bottom end. And the color temp doesn't change with dimming which doesn't come across all that nice for inside light. Plus the LV halogens are pretty efficient on their own so the cost benefit isn't as big. But I'll also admit I'm fussy and I expect to see better in a couple of years. The stuff is still very much a work in progress. I'd be very surprised if anyone is even installing fluorescent fixtures five years from now. I was talking to a contractor working in the local Target parking lot a few weeks ago. They were replacing all the arc floods in the lot with LEDs. (And man, are these things BRIGHT!) What he told me was that the bulbs cost about $600 apiece, but they pay for themselves fast because the cost of bringing in a crew and cherry picker to replace bulbs is so expensive. He said they're booked up for months, including hotels with big atriums etc. That demand should ramp up the technology and bend the cost curve.

I've had this problem - much more frequently in the past than now. As Michel says, it just indicates that the MS says it had a comm problem. But with which particular device(s) is hard to know, unless it is only linked to the ISY. That's one of several reason I almost always use programs rather than scenes for motion sensors. (Updating scenes is another.) In my case - when it was happening a lot - it was a symptom of a bigger Insteon comm. issue with certain devices and branch circuits. That problem got fixed with a newer rev dual-mode PLM, and then placing that PLM behind a filterlinc so it is forced to use only RF to communicate out. Reliability went back to nearly 100% and I rarely see these MS pop-ups now. A few things I've found helpful in individual cases when I keep seeing this message for a particular MS: 1) Replace its battery (duh). 2) Do a "restore device" on the MS and also all devices that are linked in scenes to it. 3) If you can, move the MS to a location where the RF has a better shot at any nearby AP or dual-mode device. Now I did have this as a chronic problem in my kitchen area for a while, where there were a pair of older MSen to cover it. But I simply couldn't figure out what the problem was. Even a factory reset on the MSen and all of the above didn't make any difference. I finally replaced both with new ones (rev 2 or whatever they are) and there are no problems now. Of course I can't believe both devices failed, but who knows? It was either spend the $70 or the rest of my life trying to figure it out. I opted for the former.

Just to amplify on what Illusion said: you are describing a classic case of Insteon powerline interference. When the fluorescent lights are on, the ballasts (I'm betting electronic ones, yes?), will generate a truly astonishing level of HF noise. That noise feeds back into the powerline. That is why things work when the lights are off, but unreliable when they're on. I wouldn't spend a lot of time trying to analyze this past that - there are too many variables and "X" factors. In my experience even dual-band devices are no guarantee of immunity from this problem when the line noise level is high enough. What I finally had to do in my garage to fix this same problem was wire an outlet J-box in the ceiling where the wiring to the fluorescents begins. I then plugged in a Filterlinc to that and wired up a little pigtail 120V plug to the fluorescent wiring chain. That's plugged into the Filterlinc and that setup took care of it. The Filterlinc keeps the ballast noise off the powerline -- at least most of it. I had to do a similar thing in my kitchen remodel which uses undercabinet fluorescents with an electronic driver, though the plug was already present for that so it was simple. As a plus, taking all that noise junk off your powerline might well improve your overall Insteon reliability, even though it's 100+ feet away from the house and the noise should be reduced a lot over that distance. I'll also mention in first attempting to solve this, I did try a couple of different X10 inline filters. None of them were successful. Also, not sure exactly what topology you were describing, but my experience is that the dual-band devices do not provide the line signal level that the true Insteon access points do. And 140 ft is a long way to run the signal anyway. So if you don't have true access points on each leg, I'd consider installing them.

Sorry. LV = Low Voltage.

Should not be that hard, or maybe I'm not fully understanding what you need to do. There are lots of low-voltage dimmable LED strip and bar lights available. elementalled.com has a nice selection, along with LED driver modules that can run off a regular leading-edge 120V dimmer like a KPL dimmer. I have a Foster 16192 12V LED-rated transformer sitting on the output of a KPL dimmer I use for a little entertainment patio lighting. At the time it was the only LED transformer I could find. A web search should turn it up. If you want to use line voltage LEDs I don't have any experience to share. I'd probably consider LV bars or strips instead. The LV LED space has a lot more available and LV installs are easier anyway. You'd also want to use a recent vintage Insteon dimmer, not something from your dusty parts bin. The older SL dimmers I scoped weren't well-balanced, so you could end up with more than a little DC getting coupled through the LED driver/transformer with those. The newer SL dimmers seem to be redesigned and much better. (I also use several SL dimmers connected to regular magnetic 12V transformers for my landscape lighting and I have no issue with that either.) It isn't hard to issue web requests in the ISY triggered by a button press or any other event. You just need the ISY network module and a bit of ISY programming to trigger on whatever you want to. There could be a bit of lag time between the button press and the actual dim. Homeseer 2 might be another option if you feel like buying it. I use HS2 with the ISY plug-in and it's easier to do some things with that interface and response time can sometimes be quicker with HS programs.

Thanks. I'll modify the commentary on the original post to explain this. I don't usually like retroactive edits like this, but in this case it seems Since this is the defined behavior, I'd like to renew my suggestion for some kind of mini-wait (sub-second wait or that just puts current execution at the end of the queue with no other delay.) It is a much simpler way to solve this kind of thing.

Thanks. So at what point is Test.C0's condition getting evaluated, relative to its body execution? I'm not quite getting it. The condition basically says "and only execute this if $Test.Code is not 1234." But the body appears to gets executed anyway when $Test.Code IS 1234. I'm sure of that because I stuck an assignment of $Test.Code to a diagnostic variable at the beginning of the Test.C0, and sure enough: 1234. Really just trying to wrap my head around why this happens, it's very counter-intuitive.

I did use a non-state variable, though I should make that clear. Do I understand correctly that ISY variable assignment processing is handled asynchronously and so can interrupt the program at the point of the assignment, or is this something different?

I've re-worked and re-posted the original code. In working it up again, I ran into what I think may be an ISY variable processing bug. I've noted it in the revised code posting. This workaround I'm very sure wasn't necessary with the original ISY firmware when I first did it, so something's changed. Maybe someone from UDI can shed some light on this problem. It's left me baffled, but I've spent as much time as I can to trying to figure it out. The workaround in the code I posted takes care of it in this case.

It's a mess all right. No idea what's happened, it used to be OK - maybe the forum move had some impact. I'm not sure I even have that code around anymore, so I'll need to look at this when I have some time and just post a new one from scratch. Sorry and thanks for pointing it out.

I have never had a problem with a GFI and I have lots of them. Some others have occasionally reported they suspected a problem, but I don't believe anything definite has ever been demonstrated. Getting a few commands successfully through and then total comm. failure doesn't really feel much like a noise problem to me, though of course anything is possible with Insteon signaling. Smarthome support usually goes to the noise / signal strength issue first -- it's easy, and to be fair it is common. The simple way to find out is to test by plugging the pump through a filterlinc and see if that resolves it. Have you tried putting an access point somewhere on that branch? Also, is the pump control device dual-mode (RF/Powerline). Either of these might help - if not to solve the problem, at least to narrow it down. Also if you haven't, try to find out if the comm issue is with the ISY (which is to say PLM comm.), or generally. The easy way to do that is to link the pump device with a KPL button or other device somewhere as a controller in a scene and see if pump control works when you press the button.

There are a deep NEMA 3 and 4X outdoor-rated enclosure boxes you could configure an outlet in. The non-metallic ones run about $20-$30. Your local electric supply house will have them. I'm a little surprised that the pump motor is an issue. I have three fountains and a waterfall with various pump sizes, and I've never had an Insteon noise problem with any of them, including the half-dozen other pumps I've taken out of service over the years. It's not impossible of course but I would definitely want to test a temporary setup with a filterlinc before concluding that's the real issue. Also, understand if you put a filter upstream you'll problems if you want to put any control devices on that branch past the filter. The dual-mode devices can help, but there are distance limits and of course if the pump is really generating noise they may not work anyway. I would try to find a solution that places the filter on just the pump circuit if you can. I've not had a much success with any of the wire-in X10 filters on Insteon devices, but others report they work. It probably depends on the degree of noise/signal-sucking. Testing before you start bolting things down is advised.