gregoryx

Awesome! Thank you! ... gotta go try it...

okay... I gotta chew on that for a bit. Effectively, it makes for two cases to run things if I can figure out how to use it right. Thanks!

Help! I'm having trouble figuring out the right programming for this. I want a motion to turn OFF lights only. Easy enough: not linked to the light, only to the ISY; use a program to trigger the OFF, and ignore the ON. This way I can control via ambient light levels or time of day or whatever whether it will go on or not. The challenge is that I want a "warning" before I turn it off based on the timer. I'm a bit stuck on how to do that AND have the warning work by calling OFF the "turn off the light" function if there is more motion.

I see a little "else" stuff here and there... and I feel like I'm really missing some program functions by not knowing how to use it right. It seems when I see it it's used something like "if control of a device turns ON then..." and the else is... uh... any other type of control? of that device? It confuses me. Can someone point me to examples where it's making the program work or work better?

I wouldn't say I "know" that... but that's what I was suspecting. So it'd look like this: If Control 'Dining' is switched On Or Control 'Dining' is switched Off Or Control 'Dining' is switched Fast On Or Control 'Dining' is switched Fast Off Or Control 'Dining' is switched Fade Up Or Control 'Dining' is switched Fade Down Or Control 'Dining' is switched Fade Stop Or Control 'Dining' is switched Bright Or Control 'Dining' is switched Dim Then - No Actions - (To add one, press 'Action') Else - No Actions - (To add one, press 'Action') Right?

Howdy, Michael. It is pretty confusing, I think. I've been dealing with Insteon stuff for three years or so. The basic functions haven't changed, but the way UD/ISY presents them is a little different from how the programming works. The approach I'm trying out right now is pretty simple: make the ISY act as a "controller" to keep KPL buttons in sync whenever anything happens. It seems to be working quite well so far; I'm sure it has more Insteon traffic than other ways, but it also works better for sync. If I hit problems, I'll change it. Case ONE - KPL controls loads AND is kept in sync by program: If Status 'Out.Back.LowMid' is not Off Or Status 'Out.Back.LowSide' is not Off Or Status 'Out.Back.Up' is not Off Or Status 'Out.DiningPatio' is not Off Or Status 'Out.Front' is not Off Or Status 'Out.GarageSide' is not Off Or Status 'Out.GuestPatio' is not Off Or Status 'Out.KitchenSide' is not Off Then Set Scene '-Status.Out.Lights' On Else Set Scene '-Status.Out.Lights' Off Scene '-Status.Out.Lights' has 14 KPL buttons in it. They all control the devices listed above and each other. The program does the cleanup for any direct control. Case TWO - KPLs do NOT control loads directly - only by program: If Status 'Dining' is not Off Or Status 'Dining.Table' is not Off Or Status 'Dining.Wall' is not Off Or Status 'Down.Land.Slave' is not Off Or Status 'Down.Land.Wall' is not Off Or Status 'Entry' is not Off Or Status 'Entry.Wall' is not Off Or Status 'Entry.Down.Land' is not Off Or Status 'Entry.Up.Land' is not Off Or Status 'Kitchen' is not Off Or Status 'Kitchen.Sink' is not Off Or Status 'Kitchen.Table' is not Off Or Status 'Livingroom' is not Off Or Status 'Livingroom.Wall' is not Off Or Status 'Livingroom.Mantle' is not Off Then Set Scene '-Status.Main.Lights' On Else Set Scene '-Status.Main.Lights' Off Looks exactly the same. Does the same thing. Only difference is pushing any KPL button in the '-Status.Main.Lights' group does nothing. Only a double-tap (Fast Off) does it: If Control 'Entry.Key.Down.A' is switched Fast Off Or Control 'Livingroom.Key.A' is switched Fast Off Or Control 'Master.Key.D' is switched Fast Off Or Control 'Office.Key.D' is switched Fast Off Then Set Scene '*Dining.Lights' Off Set Scene '*Entry.Lights' Off Set Scene '*Kitchen.Lights' Off Set Scene '*Kitchen.Sink' Off Set Scene '*Kitchen.Table.Lights' Off Set Scene '*Living.Lights' Off Else - No Actions - (To add one, press 'Action') Case THREE - as above, but different rooms may or may not be part of the controls: If Control 'Down.Land.Slave' is switched Fast Off Or Control 'Entry.Down.Land' is switched Fast Off Or Control 'Entry.Key.Door.C' is switched Fast Off Or Control 'Entry.Key.Down.C' is switched Fast Off Or Control 'Master.Key.F' is switched Fast Off Or Control 'Office.Key.F' is switched Fast Off Then Set Scene '-Down.Lights' Off Run Program 'Down.Guest.OFF' (If) Run Program 'Down.Office.OFF' (If) Wait 3 seconds Run Program 'Down.Status' (If) Else - No Actions - (To add one, press 'Action') In this case, the Fast Off may NOT turn off all lights if the guest status light is on: If Status 'Guest.Key.Door.B' is not On Then Set Scene '*Guest.Lights' Off Else - No Actions - (To add one, press 'Action') 'Guest.Key.Door.B' is part of a KPL button scene (all controllers, no loads), therefore if any ONE is on, guests are in the room and the lights should not be changed when a Downstairs lights command is run. HTH!

I'd like to trigger a program on ANY type of control from a device. Is that just a missing function? or is there another way to do it?

a thought on the low level / variable level thing and speed to turn on: perhaps a compromise with a slow ramp rate triggered directly so SOME light starts quickly followed by the program kicking in before it's finished ramping up?

Makes sense. Thanks!

Agreed. But with 3-5 status lights in sync, that's likely to be an issue, isn't it? Right now, they're all responders to a group that gets turned OFF or ON. If they were all controllers as well (which I could do, of course), then they'd likely be in sync... so I guess that might be the alternative / fix, eh?

COOL! I saw the lines in the logs and assumed it was doing a status request of the devices. If it's not doing one, then the only "more traffic" I'm creating is the traffic I wanted anyway: turn the "status indicator" lights on / off. Right? Rand, your suggestion was exactly what I was hoping for: re-sync the status at a timed interval but don't have sync's going otherwise. I think I'll run with it like it is for a bit and see how it goes. If it doesn't create too much traffic, I sure like the effect: actual "floor status" lights that work!

... so the additional elements are more like a bunch of 2420Ms then?

That's what SteveL said he'd done and had concluded that it was noise / signal absorption and was cured with APs and/or more devices or different placements. It'd be interesting to see what your therapy concludes.

... sorry to keep dragging this out... I get what you're saying; but what if I want it to be evaluated and change every time ANY of those devices change? I just don't want it to re-scan all of them every time one of them changes. The ISY already knows the status - typically accurately; is there some way to make the decision exactly as my method does /without/ re-querying the rest when one changes?

I'm following you so far WRT PLC traffic. Clearly, more is bad. I also understand that your total solution works with OFF and ON; just in two programs, right? So here's a question: it seems to me that the real problem with the way I was looking at it is the STATUS requests that go out every time a device changes status. ONE device changes status (with a control, typically, but could be by link), then a STATUS query goes out, hitting the line with more traffic. Is there a way to stop this from happening? Basically, a way to say "don't re-check the status, but if ISY thinks things match a given status, assume it to be true"? If that's possible, I can do a status cleanup every hour or whatever. FTR, I really appreciate the help on this. Once I saw your example and tried the variation, I finally have my four key "status light groups" working as I've long wanted: Upstairs, Downstairs, Main, Outside. They now accurately reflect if ANY device is on, making it easy to turn them off if I'm certain there's no-one there (and it checks another status indicator for rooms I'm unsure of).

I was afraid that might be the case. It looks like your solution involves two things: 1. Only do it once - from on to off, not off to on; 2. delay the status light change to decrease traffic. Gives me two questions: 1. when is traffic too much? 2. will the delay cause only one command to be sent?

Mike, thank you! Your scenario two inspired me to change some of my stuff - which leads to a question: first example, only do the OR statements and do them grouped; shouldn't need the first statement, and then an else works, right? Seems to do what scenario three does with less trouble. Any possible problem? If ( Status 'Dining' is not Off Or Status 'Dining.Table' is not Off Or Status 'Dining.Wall' is not Off Or Status 'Down.Land.Slave' is not Off Or Status 'Down.Land.Wall' is not Off Or Status 'Entry' is not Off Or Status 'Entry.Wall' is not Off Or Status 'Entry.Down.Land' is not Off Or Status 'Entry.Up.Land' is not Off Or Status 'Livingroom' is not 20% Or Status 'Livingroom.Wall' is not Off Or Status 'Livingroom.Mantle' is not Off Or Status 'Up.Land.Heart' is not Off Or Status 'Up.Land.Slave' is not Off ) Then Set Scene '-Living.Movie.C.State' Off Else Set Scene '-Living.Movie.C.State' On It seems to work really well and has a new advantage (for me) that if a light that should be off turns on the scene buttons turns off and if it gets turned bock off again the scene button goes back to on. Seems cool. Issues? I hope this is okay; 'cause I can do my upstairs and downstairs that way - as you mention.

Just put the 2420M and a light in a group with the 2420M as a controller. Done. Use the ISY to change the duration of the "off" timer if you like. Use the ISY to trigger an email when the battery on the 2420M gets low if you like. Use the 2420M light/dark in other ISY programs if you like. The great news is that the ISY now knows the state of the light when the 2420M controls it (since it's always part of the group).

Two ways I know of: 1, put all things in one scene, including all the KPL buttons and all load buttons; 2, use programs to clean up multiple scenes. It seems to me that any time there are devices that may or may not be controlled by different controllers, this will happen. I've seen it different ways and solved it different ways. Here's what I'm doing mostly. One KPL button, two load switches: use KPL button, all stays in sync all time; use one load button or other, KPL status follows neither or follows last controlled. In most cases, I want the loads to act separately, but the KPL button to be ON if any of the loads are ON. Here's what I've been doing (now working on the logic with ISY, previously with HS and then ML and even tried with ELK): If (control of load A turns OFF and status of B is ON) OR (control of load B turns OFF and status of A is ON) then turn KPL button ON. If someone has a better approach, lemme know!

Jim, I expect Michel will respond as well; but I thought I'd venture an explanation that doesn't seem super-clear from Michel's posting: - As I understand it, the new devices support i2 messaging and programming; old devices did not. - 2.6.13 started using i2 programming if the device supported it - ergo, newer devices would be programmed with i2, older devices with i1 I'd guess. - i2 programming seems to have been problematic - reasons for that aside for the moment - resulting in corrupt programming. - Hence, any newer device programmed with 2.6.13 might be susceptible to the corruption and the more programming we did with 2.6.13 the worse the problem slowly got. I hope I'm getting that right. If that's right, then the fixes are: 1) try to just rebuild the devices; or 2) factory default them and rebuild them. Again, if that's right then it indicates that all /should/ be well if we had not ventured into the i2 world with 2.6.13 WRT i1 capable devices. Last guess is that i2 has it's place and may have some issues or may not. It may well be that i2 is simply less robust than i1 because it's focus is different (more detail and data depth and speed, less assurance of accuracy) and requires a "cleaner" environment than we have had the luxury of getting away with in an i1-only world. That's a best-case guess, of course. I hope Michel will qualify my guesses.

Bravo on addressing and resolving issues - especially on the communication of findings and suspicions. On the "frustrating but good news" front, I've found that doing a restore doesn't seem to fix the problems that 2.6.13 created or encountered; but the full remove / default / start over works. I have yet to default all 50-some devices; but I may do that. Thanks again for owning up to the issues and addressing them and communicating.

Two things from what I think I heard: the current devices repeat i2; at some point, APs may not be the only way to get RF repeaters (think Appliance Linc, Lamp Link, PLM, etc). No plans, just that it makes sense, I guess.

It seems like it takes a lot longer to poll devices for link tables. Is that just because I'm back in automatic mode, not i1? or is something as different as it seems? We're talking minutes for things with a couple dozen links.

Not that I recall... but I'm not going to swear to anything. I realized later where the 100 links might have gone: I changed two rather large scenes and consolidated them into one; which I suspect lowered the link count quite a bit. I'll keep my eyes open for any other scene issues; that one really surprised me. Steve's coming by tomorrow to see that weird KPL in action; he has an idea what's going on (as Michel knows). Just thought I'd let others know. ON TO 2.6.14!

Correct. The scenes are no longer in the tree. I also have at least one scene that no longer has any devices in the scene at all - it has tens of them a couple of days ago. If I might have accidentally deleted a scene or two (which I did not), I most certainly did not accidentally remove tens of devices from a scene. Ugh. BTW, I reported a few days ago that I had over a hundred links reporting in the ISY; it's now a hundred less. I'm not sure where they all went; but I don't recall removing a hundred links.