gregoryx

Michel, it appears now that the weirdness is related to switches' link tables not acting as they should - possibly the known issues, though I'm seeing it in a KPL. MikeB, thanks for the code, I thought I'd tried all the variations; that didn't even occur to me.

On a related note, is there any reason to believe this may affect ISY configuration? In trying to deal with these problem devices, I'm now seeing scenes that I know were there a day ago no longer exist. Is it possible that my recent changing of scenes and restoring of devices in chasing this bug is causing me to lose ISY scenes as well? EDIT: yeah... that's a nearly 100% sad fact at this point. I've got scenes missing and empty that were valid and working a day ago.

I've posted details in the other thread on this. I have spares and I'm near SH, let me know what you want me to do with the offending device(s).

I'm using programs instead of groups to deal with RemoteLinc weirdness. I'm using one program for "on" and another for "off". Is there a way I can make a single program where the "then" is ON and the "else" is OFF (or vice-versa)?

Sorry for the delayed response; I wanted to be sure I wasn't just losing my mind on this. As I've posted, I recently replaced almost everything I had with the newer devices. I figured any issues I'd seen - since they were intermittent - must be noise related, so I bought a bunch of Filterlincs and went after things that had not been a problem in the past and started filtering them again (as I had not done since X10 days). Other than DOAs, the new devices had been more reliable than the old ones - which were often working in a scene but the paddles were dead or dead-ish. Initially, all was well and I figured - I didn't get any of these bad ones everyone is complaining about. Now, that has changed. Things that were working in simple groups are spotty and when removed from a group can not be re-added. They still control from ISY perfectly but can not even join a group that ISY is the sole controller on. As an example, I have one 4-gang box with three SWL v.35 switches and a KPL-8 v.29. Two of the SWLs will not join a group controlled solely by ISY but the other two devices will. Suspecting noise and knowing it seems higher when there are other devices on, I've tried multiple times of day and such... but these two don't seem to want to join the group. I also have groups that seem to be "deteriorating" where the "flashing lights on the controller" (if you know what I mean) started happening and don't seem to be getting better but worse. I'll start doing the default and restore thing and I'll go all i1 and leave out the RemoteLinc from anything suspect this time; but I'm thinking my devices have some variation of this disease. Post-script: ok... weird... I removed the Remote Linc from things and went to i1 only and those two devices described above link promptly and well now. The Remote Linc didn't have any enrollment in that scene. Go figure. I'm going to go back and see if any of the other weird things are better or worse.

I currently have 490 links in the PLM. I have lots of filter Lincs. I have 2 APs. I have a Remote Linc. I don't have a clear problem device; but I have odd scene stuff starting to show... and I'm only a couple miles from SH HQ. Lemme know how I can help. Devices: ApplianceLinc (2456S3) v.23 1 Icon On/Off Switch (2876S) v.60 1 Icon RemoteLinc (2843) v.00 1 INSTEON Motion Sensor (2420M) v.00 1 KeypadLinc Dimmer (2486D) v.26 2 v.29 5 v.2D 8 LampLinc (2456D3) v.28 1 SwitchLinc Dimmer (2476D) v.24 10 v.35 21 SwitchLinc Dimmer (2476DH) v.28 1 KeypadLinc Dimmer 8 Button (2486DWH8) v.2D 1 Grand Total 53

"not queryable"? Just not possible in the devices?

I use Elk logic to do the same thing you're doing (and integrate doors opening and alarm state and light outside, etc). I use a KPL button to stop the automatic OFF or ON function. It seems like you could probably add a similar "and" to your rules if you have a KPL that you could use a key as a control / toggle. If that's an option, I'm sure we can figger the program. If that's not an option - barring the introduction of the eventual "variables" or "phantom device" options - you could use any toggle device (like an appliance linc) to hold the "state" and you could activate it with faston/fastoff of any switch(es) you like, while keeping their function for other things. The bummer with this is no simple visual feedback... unless you plugged a nightlight into it or something...

perhaps worth pointing out that (in the panels I've looked in) the neutrals typically all go to ONE neutral bar; only the hots go through breakers... meaning ANY neutral is the same as the next. I am no expert or professional electrician; I have installed a hundred switches in the last couple of houses I've had (had the Switchlinc V1s previously ) and I dealt with what you're doing a few times. I found that Sub-Routine's advice a couple posts up was right on: if you can find a hot and a neutral in the box, there's a way to make it work; if there's a traveller between multi-switch installs, they make a great way to bring a hot (or neutral) to the other end. The other alternative seemed to be to get up to the light box itself and put in an inline and use both the old hot/load to become hot/neutral to power the switch. Based on the pix you posted, it doesn't look to me like you need to do that; it looks like box one is the only potential problem, but it has another pair of wires tied together in the box. It /could/ be that pair is hot on a different circuit, but I'd bet not. If it's a common (though weird that it's a black tied to a white - I hate that), then you're in business on that box. You already established that you're in business in box two since there's live switchlincs in that box. $.02, as usual.

gotta love that i2...

Just push the white button after a jumper change is all it says.

All the buttons be responders? to the same thing? Yeah, I guess so... but I don't see why. They can also all be controllers and/or responders to individual stuff. In short, they each act the same as any single / load on/off switch. The things I like them best for: - Control / status of remote things or groups: like all my outside lights are always the "D" or "H" on every KPL; or my espresso machine - "C" button on both the Kitchen KPLs and in the master bedroom (and turns on automatically in the early AM). - Scene stuff: set a bunch of lights off and dim one for movie time. - Off group: turn off everything downstairs - but check first to see if there's someone in the office or in the guest room. HTH.

Sorry if this has been covered, but I gotta ask: with all that cool information coming in, can it be shared to the Elk somehow? My irrigation is through Elk; I'd love to get the rain data (or other weather elements) integrated to my irrigation. If not today, might this be something that the (future) virtual devices / variables would do? Uh... that makes me think... in terms of Elk, there'd be a pretty big difference between an ISY-only variable and a virtual device that could be shared with Elk. Anyway... what's the answer? Now? Later?

Which has worked pretty well for me, FTR. I had previously tried to decide whether to put KPL control buttons into links with devices that MIGHT operate independently or not. Programs do it nicely: every time a potentially-link-able device (in some way associated with a relevant scene to a KPL button) goes off, I run an ISY program to decide whether to turn the KPL button on or off. Example: three lights in the master bath; one KPL button near the master bedroom door for "bath lights". If I link the KPL button as a controller, all turn off or on when I push it. Cool. That's fine. But if I make one of the three a controller, then turn that one off, the KPL button is OFF even though there might be two lights on. Solution: ISY programs that run when ANY of them are turned off to set the KPL button to ON if any of them are NOT OFF.

Clever usage! FTR, "defaulting" an Insteon switch refers to pulling the "air gap" thingy at the bottom of the switch OUT for a few seconds, then pushing it in for a few seconds. This "factory defaults" the switch, clearing its settings and links. I've had a few times this was the best and easiest (and only?) way to fix weirdness.

So far, I have not had anything that took more than 15 minutes at most - and that was with 20+ devices to link (so what... twenty factorial links to build?) Perhaps the old default them and try again game?

You may have a bug or a failure to communicate between the motion and the ISY, as my config with a simliar lay-out works well. Just double-checked: ISY shows on and off correctly. One difference in mine just occurred to me: I have a single switch controlled... and there are posts of some weirdness with multi-link controls on recent switches. But it seems that would be a problem even if you switched one of them one (the others would probably still exhibit the problem, I'd think), so you may be looking at bug or communication issue.

Thanks, Eric. I was thinking "on" meant "not off", so this is quite helpful.

Indeed. I think the "no OFF" is what I was missing. Works perfect! Thank you! =D>

I have NO idea what changed, but after going back and forth on the secure / non-secure Elk thing, it did finally start working in secure mode without blinking. Go figure. I just figured I was doing something wrong so I kept trying and fiddling with the M1XEP settings as well.

Huh. Maybe a version thing, then.

Hmmm... meaning if ISY helped create the scene and/or triggers the scene then STATUS should work just as well as CONTROL? What I did to get around it was to add and/or statements for each device in the scene: If Control 'Up.Bath' is switched Off And Control 'Up.Bath' is not switched On OR Control 'Up.Bath.Sink' is switched Off And Control 'Up.Bath.Sink' is not switched On OR Control 'Up.Bath.Bath' is switched Off And Control 'Up.Bath.Bath' is not switched On Then Wait 5 minutes Set 'Up.Bath.Lights' Off Else - No Actions - (To add one, press 'Action') The three light switches are all part of the 'Up.Bath.Lights' scene, so it does what I'd hope: if any of them are switched on, start the timer. Still, there are other ways to turn the light on, so I'd prefer it just watch for it turning on ANY way - such as if the ISY does it. You're saying that SHOULD work with STATUS instead of CONTROL but "will take a change before the program triggers". What do you mean? Any change? Like a control / switch turning it off or on? One that the ISY is aware of should have the same effect, right? It doesn't seem to.

Point of note: if looking at the "Devices" page on the web interface (not the "Main" tab of the "Adminsitrative Console") you will NOT see non-load KPL buttons.

No kidding? And a few of these running at once won't cause a problem? Why does "control" work but not "status"? I'd like it to work regardless of whether the button turns it on or something else.

That will require a program in ISY and won't require the KPL to be part of a scene. Just a program where "control" of the RL button initiates the scene. I haven't played with RL "on" versus "fast on" signals (double-click); but I've got stuff just like that: an RL key initiates a program which kicks off a scene. It's taking me a bit to figger the diffs in ISY; one of them seems to be a diff between "status" and "control" of an Insteon device. The "becomes" logic of HS seems somewhat similar to these... though not directly. Just as an FYI, since you mention coming from HS. For comparison, when I had used a load on / off to initiate a program (when "Master.Bath is Off") it worked if the light was on then got turned off; I had to change to control ("Control 'Master.Bath' is switched Off") to get it to work as I wanted even if the light was initially off. HTH.