MarkJames

Thanks, Lee, I always appreciate your posts. I've read that pdf file several times - or at least tried to. It reminds me very much of Stephen Hawking's 'A Brief History of Time'. I get about halfway through thinking I've got it but then it starts to slip away. The lag is still there regardless of the ioLinc. I'm going to move the LED's onto a different circuit and see if that matters. It's doubly confusing as I have to listen for the Switchlinc 'click' and ignore the LED lights as there's a lag between when the switch turns on, the transformer powers up, and the LED's glow. Oddly there's much less lag on an off command - almost none, really. mark

Well, now I'm not entirely sure as the lag is still there, though subjectively less. I think I'm gonna put the LED lights on a different circuit and see if that helps. They act very oddly on that circuit. If I cycle them on/off too quickly (and I don't mean very quickly - just on - 2 second pause - off - 2 second pause - on etc.) They fall out of sync with what I'm doing. This looks very much like what you were describing, Lee. How long do Insteon switches wait for an Ack before rebroadcasting? That might shed some light on this. mark

Well, that was interesting. I disconnected the LED's and found it made no difference to the lag. So I checked the leg it was connected to and noted an ioLinc plugged in to an outlet on that leg. I unplugged the ioLinc and the lag went away. That seems kinda counterintuitive as I would not have expected the ioLinc to cause a problem. Perhaps there's a problem with this particular ioLinc. Thanks for the help, Lee. I'm not certain what caused the problem but at least it's gone away. mark

Thanks, Lee, I'll give that a try. I thought perhaps it had something to do with the LED transformer load and maybe others had experienced a similar situation. Oddly if I turn it on and off from the ISY interface it responds quickly though repeated on/off cycles in close succession seems to 'confuse' it. That would support the idea of the ACKs not being received quickly. makr

I just installed 4 banks of LED lighting which I'm controlling through an Insteon scene. I've run into a strange issue which I've never encountered before and don't understand. The lights are all connected to a 2475S2 inlinelinc. I just switched it to this from a 2476S dimmer to make sure the problem wasn't somehow ramp rate related. The scene has 4 controllers - all keypadlincs - 3 are brand new kpl8's with the latest rev firmware and one is a couple of years old. The LED light switch is the only responder in the scene. When I turn the scene on from any of the controllers there's a several second lag before the switch turns on. Same thing when it turns off. It's reminiscent of how some of my x-10 used to work. Any thoughts as to why there might be this lag? mark

Well, I have to say that I was pleasantly surprised by the service I got from Aartech here in Canada today. They offered to replace both my PLM's with new 2413s even though the warranty was up on one of them. I wanted to post this because I know that I wouldn't hesitate to post if a supplier screwed me over. It seems only fair to post when one treats me nicer than I expected. mark

The quirkiest thing that really set me looking more closely was when the lights in my son's bedroom wouldn't turn off. You'd flip the switch and they'd turn off but within 5 seconds they'd turn back on. There were no motion sensors related to the room and no programs that could be doing it so it was a real hair-puller. At first I attributed it to the fact that those are among the only 'Icon' switches I have. I thought perhaps I'd 'gotten what I'd paid for' as I've noticed that the quality of Icon is considerably less than that of the Smartlinc switches. I've also noted that the ISY interface would crash quite regularly when the PLM was acting up. It 'looked' ok but many devices would sit there with the pending write icon beside them but I couldn't get them to write and when I'd try to close the interface it wouldn't close. I think I'll order a spare PLM this time as it's a real headache when things go for a dump like this. mark

The power supply issue looks pretty trivial - the ISY looks to have a standard plugin for a 9V wall-wart. I'm actually kinda looking forward to that change as I can plug the ISY into a UPS. It's a shame there's no way to filter the power to the 2412 or 2413 as I suspect it's surges that are taking their toll on the units. Thanks for the tip on the simplehomenet version. I think I'm gonna try the 2413 first, though. I suspect I can reconfigure my network to reduce the number of links. The advertising for it claims faster writes (though I would think there's a lot more involved in write speed than the qualities of the PLM). Mostly it kinda chokes me that I've had two of them fail already. When the PLM goes flaky all the scenes start to act up and I chase my tail for a week or two reestablishing links both through ISY and manually until I finally clue in to the 'real problem'. As I'm in Canada the warranty is all well and good but by the time I pay shipping and taxes for the bad one going back and the replacement coming here I may as well just buy a new one.

I've had my ISY for a couple of years now. My first PLM was a 2412S rev 3.3. It started acting quirky a year or so ago and I was getting poor communication and failed writes. I bought a new 2412S which turned out to be a rev 3.1 (don't ask me - must have been old stock?) It worked fine until last week. Last week that one failed completely to the point where ISY only starts in safe mode. I've reverted to my old PLM to get up and running again. To be honest I'd forgotten it wasn't working right so I pulled my hair out for a couple of days trying to troubleshoot the problems. I remember now, though, that it was fubar so I've given up on using it. Has anyone else had issues with PLM failure/bad PLM function? I know they've dropped the 2412S in favor of the 2413S now. I'm hoping it's more reliable as 2 PLMs in 2 years seems unreasonable. I haven't read the specs on the 2413 but I remember when they first came out they were capable of far fewer links than the 2412. I hope that's not the case now as my 2412 had well over a thousand links in it. mark

I've had my ISY for a couple of years now. My first PLM was a 2412S rev 3.3. It started acting quirky a year or so ago and I was getting poor communication and failed writes. I bought a new 2412S which turned out to be a rev 3.1 (don't ask me - must have been old stock?) It worked fine until last week. Last week that one failed completely to the point where ISY only starts in safe mode. I've reverted to my old PLM to get up and running again. To be honest I'd forgotten it wasn't working right so I pulled my hair out for a couple of days trying to troubleshoot the problems. I remember now, though, that it was fubar so I've given up on using it. Has anyone else had issues with PLM failure/bad PLM function? I know they've dropped the 2412S in favor of the 2413S now. I'm hoping it's more reliable as 2 PLMs in 2 years seems unreasonable. I haven't read the specs on the 2413 but I remember when they first came out they were capable of far fewer links than the 2412. I hope that's not the case now as my 2412 had well over a thousand links in it. mark

I have a reasonably large installation - about 125 Insteon devices at the moment not including motion sensors, remote lincs, access points, and signal bridges. The devices are extensively cross linked in large and complex scenes. It's the result of years of work and it works pretty much perfectly. I'm doing a major reno of the house right now and that involves lights not being where they once were, switches moving or becoming redundant and new switches and devices being added. Without the ISY removing a device and reconfiguring it was a HUGE task - one that invariably resulted in numerous switches 'blinking' as they looked for links that no longer existed. With the ISY it's as simple as deleting the device and then adding it back in - I can accomplish in a few minutes what would take me hours to do otherwise. ISY handles all the grunt work of dealing with the links. Thanks for that! When a product can simplify your life that much you know it's well thought out and designed - and when it's supported as well as this product is you have a real winner. mark

The http to https thing was what was messing me up. I've done lots with http but nothing with https. I'd assumed that if I browsed to a secure site via http it would refer me automagically to the https version but as I see now that's apparently not so. My carrier blocking non-standard ports is interesting too.... I'll have to contact them and find out if they block all or leave some for folks like us who port forward in to many different devices.

Good one, Brad! I changed to use the standard port 80 redirected to the non-secure ISY port on 80 and it got in right away. Then I tried forwarding 80 to the secure port on 443 via an http request (not https) and got the same error as before Next I tried forwarding 80 to 443 using an https request and that worked fine. Finally I tried external 443 to internal 443. http request doesn't work - https request does. So it seems that a) my carrier is blocking non-standard ports but 80 and 443 work fine. my bb browser won't forward an http request to an https server Thanks for the direction, Brad! mark

I can access my ISY from remote via web no problem. https:\\70.67.xxx.xxx:801 with a port forward in my router to port 192.168.xxx.xxx:443 where my ISY resides. For testing purposes I've also set up a port forward to port 80 so that http:\\70.67.xxx.xxx:806 forwards to 192.168.xxx.xxx:80. Both of these forwards work fine from any PC based web browser. For some reason, though, if I try to browse to that from my blackberry or from my buddy's iphone I get a gateway error. I can't connect from either of these devices. I don't have the iphone in my hands but the error on the bb is 'the selected server returned an error when attempting to fulfill your request'. Sometimes I get the message 'Gateway Timeout - The gateway timed out while waiting for a response from the server. Please try loading a different page'. If I ask for details of the message it tells me that the connection failed and that the system returned 'connection refused' I've telnetted in to the ISY and upped both the HTTP and HTTPS timeouts to max - 50,000ms. No difference. I've enabled and disabled java support on the bb browser (I saw something about this in another post) but no difference. Could this just be crappy 3g performance in my area? Or is there something else I'm missing? Thanks, mark

You want to use the status condition for your second condition - I imagine what you want is if the sensor is off and the switch is off then turn the light on You should have it read OR Control 'garage sensor is switched off' and status 'kitchen' is not on that will turn the light on if the sensor times out and AND kitchen is off. if that's not what you want - it may be that you want or status 'garage sensor' is off and status kitchen is off this will turn it on if both the sensor and the kitchen switch are off Note that this will not pay any attention to the time of day. If you want to know if it's dark you could also query the motion sensor dusk/dawn sensor to check. control ifs are only evaluated when they are sent by physically pressing the button and only if the right 'side' of the button is pressed - ie each time you press the on it will execute regardless of whether it is already on status ifs are evaluated everytime it switches state. So if it turns on or off either the then or the else will happen. But if it's off and you send another off nothing will happen at all - likewise if you send an on and it's already on - nothing will happen at all. ' an 'if control is switched on do this ELSE do that' will NEVER execute the 'else' part. To execute the 'else' part you'd need an 'if control is switched off' statement and put the actions in the THEN portion mark

I posted the thing my wife loves most about the ISY a few months back. When the temperature is below 50 outside the ISY turns her electric blanket on at 9pm so that by the time she gets into bed it's warm. She then hits a button at bedside and it stays on for an hour then turns off automagically. That one was worth a lot of 'atta boys'

I too have had the same problem with bathrooms. I almost swallowed my tongue laughing when I read IndyMike's statement that 'it only takes 1 Oh Sh$$ to erase a lot of atta-boys.' My wife - despite all the other seemingly magical things the ISY does for her - has been on my case something fierce over the motion sensor in the bathroom. Again - I'd run the gamut as have others - full lights on during early morning, dimmed late at night, short interval at night, long interval during AM showers - motion sensor sending on only, motion sensors with short intervals and ISY managing the delay - on and on and on. I had pretty much given up on it too. I guess, in a way, I have. I restrict my bathroom lights to the following now. Between midnight and 5am if there's motion the lights turn on at 30% for 4 minutes. Just enough for a mid-night pee with enough light to not miss the bowl. The rest of the day I do not turn the lights on with the motion sensor - if you want them you turn them on yourself. I do, however, watch for 30minutes since last movement in the bathroom at which point I turn the lights off for energy conservation. The thought here being that if you don't trip the sensor within a half hour either you've been in the tub too long and deserve to sit in the dark or you've died in which case it doesn't matter. There is yet another option which I use in my guest bathroom and that's to replace your switch with a timerlinc. If you press it once it's on for 15min - twice for 30, three times for 45 etc. At least that way if the light turns off on the occupant they have noone to blame but themselves. Anyways - there's my thoughts for what they're worth. mark

My apologies... I was paying no attention to the details of the program itself but rather to the concept involved. My example should have clearly used a STATUS check not a CONTROL check as there really isn't a reevaluation to a CONTROL check. I don't think I actually specified either - but I can see how what I wrote could be read that way. My point was that the fundamental concept you have to understand is that each and every time the condition in the IF changes and gets reevaluated then the program will terminate if it's running and the program re-executes the appropriate IF/THEN branch. In my admittedly bad example - the case of the CONTROL check, kingwr is right - the program will run when a control ON is sent but will never do anything when an OFF is sent. There is no reevaluation of the IF when the OFF is sent as there's been no change in the condition. Receiving an OFF is not an ELSE to receiving an ON unless, as kingwr pointed out, your condition has the control NOT OFF as a control sending OFF will cause a reevaluation of a NOT OFF control condition. This is a simple way to avoid writing two programs - one for control ON and another for control OFF. Of course, if you base the program on STATUS, the status does in fact change as the KPL switches ON or OFF and the whole thing becomes easier to read. This frequently leaves new ISY programmers scratching their heads wondering why their program didn't do what they thought it would. Personally, I'd prefer to see programs have an option where you could select a checkbox and not have the program reevaluate until it has completed its execution. This would clarify some aspects. On the other hand, the way it is works great for things like motion sensors where each and every time the sensor detects motion and sends an ON it can retrigger a program that does something WHILE the sensor is on. Anyways - I hope the part about the program terminating and starting over each time the program gets reevaluated helps - that's the part that gets most people. It's easy to write a program that does something like this If status kpl-a is on turn kpl-a back off turn on a bunch of lights turn on a bunch of other lights repeat flashing a light for a while turn off some lights do something else else do nothing The problem with it is the first line will cause the KPL to turn back off and cause the program to terminate and run the ELSE so nothing past that will happen (actually there will be a brief lag so some of it might).

If I can put in my 2 cents worth - the part that gets confusing for most (myself included) is related to the else and the constant reevaluation You see... if you have a condition like If switch is turned on then do something wait 5 minutes do something else else then when the switch turns on the do something will happen but - and here's the big but - if the switch turns off in the meantime then the whole condition will be reevaluated and the else will happen. The wait will never finish - whatever was happening will stop and the else will happen. So if you're counting on the something else happening after the wait you must be sure that the condition doesn't change in the meantime. This can be very confusing - for instance If button turns on wait 5 minutes turn aquarium off else is your program - when the button turns on the if will execute but if the button turns off before the 5 minutes are up the aquarium will NOT turn off. The else will happen and it's blank The simple explanation is this. Every time the evaluated condition changes and the condition must be reevaluated the program, if running, will be terminated. It will then be reevaluated and the appropriate If or Then will execute. So... The way around this is to code so that this doesn't 'getcha'. If you always want the wait and whatever else to happen when a button is pressed then you put those items in a different program. Like this prog1 If button turns on run prog 2 else blank prog2 wait 5 minutes turn aquarium off This will keep make the wait always happen when the button turns on and it won't stop when the button turns off. BUT - it will start the wait all over again if the button turns on again. See how it can get confusing? You have to keep this in mind when designing your logic and it WILL come back to bite you in the behind if you're not careful. mark

I've contemplated the benefits of systemwide restore numerous times and have felt like I would have benefitted from it. In retrospect, though, doing a systemwide restore would only benefit me if I knew for sure that there were no comm issues. In the presence of comm issues - which seems to be the #1 source of trouble for Insteon systems - you can't be sure that the restore gave you anything better than you had prior. While the ISY can confirm with an ACK that the write happened, it can't confirm that it deleted something that wasn't supposed to be there in the first place - you'd have to do a hard reset on the device to guarantee that and hard resets have their own problems (6 vs 8, grouping, toggle mode). I liken it to adding whacks of devices to a scene at once. If an error occurs you generally get the 101 write error messages (in recent versions, anyways - which is far improved from earlier ones). With comm errors those 101's can be a real pain to get rid of. It's really best to add 5 or 10 devices at a time to a scene. Trying to rewrite every link at once in an entire system is probably not practical Anyways.... not to denigrate the idea as on its face it has merit - just having gone down this road numerous times I can tell you from experience that your best bet is to simply do a restore on a device that's not doing what's expected - or restore the link between a device and scene if that is more appropriate.

Have you looked at the topology report? It does most of what you've described, I think.

I agree with you. Access points seem to have a variable range that depends very much on line of sight. I would tend to put one in each building that are electrically separate as close to each other as possible and then let the signal bridge do its job. access points, afaik, do not 'talk' on the network. They merely act as any other hardwired device relaying the insteon messages through the network. Of course, they also inject signals from RF devices and other APs as well. There are no communication analyzers for Insteon that I've found. X-10 had them but that was a different scenario as X-10 signal strength was something you could measure in mV. Insteon talks digitally so a comm analyzer wouldn't know much about the signal other than whether it's there or not. I've wanted a report like this myself but bear in mind that it's not that simple... it would have to be a fairly comprehensive report that would need to reference each device, its memberships, whether its linked membership exists in its paired device, and so on. In a complex network I betcha it would take it the better part of 24hrs to run. Docs are always a problem when you're on the bleeding edge. No sooner something is documented it's obsolete. The forum is probably your best friend for that as I've never come up short asking a question here. hope that helps, mark

There is no way to en-masse restore all the links in your system afaik. There's a couple of things you should keep in mind here, though. First - if your lights were flashing then knowing what we know about Insteon we can be certain that something within your own system was telling them to do so. Flashing can only be accomplished by programmatic control so that would be a starting point to troubleshoot that problem. Switching from software to software is a big PITA. I've switched from Insteon with x-10 addresses controlled by Stargate to Houselinc to Powerhome, to ISY and have had to troubleshoot the weirdnesses each time so I consider myself well experienced in this arena. The first thing you should know is if you go to Tools->diagnostics->device links you can read all the links in a device. There's then a compare button which will compare your links to the ISY table. They should read identical all the way down with an ignore at the bottom. If they don't then before you perform a restore on the device you'll want to make sure you have no comm problems. Be sure to let the read links routine run right to the end or you'll get a weird compare result. Working across multiple panels by RF can be difficult - I'd start by picking a simple switch with few links that's on the 'other' panel from your ISY and see if ISY communicates properly with it. If not you'll have to work on this problem first. Next - make sure you don't have any stray X-10 addresses left in your system if you were using X-10 before. X-10 isn't as robust or secure as Insteon so it's possible to get lights flashing and general weirdness if someone in your area has X-10 with the same house/unit addresses or, from what I've seen with X-10, you can get weirdness just because it feels like it. Then make sure you don't have programs doing things that you've forgotten about. Try and troubleshoot light by light and search for programs that are controlling that light. Insteon can't just 'turn on' by itself. The controller-responder link must match so you can be certain that if it's turned on or off then somehow, somewhere, you've told it to. Finally, if your device tables don't match you can hard reset them and restore them or simply rightclick the device and hit restore on it from the main screen. The latter is preferable as the former will kick your 6 or 8 button KPLs into their default which you may have changed. Restore will delete links that don't exist in the ISY table and rewrite the links that do. ISY will warn you that you'll need to have your RF devices that are linked to the hardwired devices in link mode when you do this but I've not found it necessary. I'd check after a restore with the diagnostic routine to make sure you got what you expected and now everything is identical. If you can't successfully perform a restore followed by a device link diagnostic that matches up then something is amiss with your communications. Lots of devices makes things better, not worse - so long as you don't max our your PLM. Lots of access points make things worse, not better, imho. The only err msgs I get pop in ISY is from my RF devices as they asynchronously communicate through multiple access points. Multiple panels is no big deal but I would definitely use the 2406h hardwired signal bridges in each panel - it may be overkill to use more than one but they're cheap and easy to install. Multiple METERS is hard and can only be done RF unless one meter feeds the other meter (as in a deducting system). Insteon seems to make it through the meter but you'll always want to be thinking FIRST about your communications whenever you do anything to your system. With multiple meters you can do it - I've done it - but every so often I'll change something and it will stop working properly and I have to go back and figure out what I've changed. Finally finally (oops), run the diagnostics on your PLM and make sure you don't have something funny going on with it. Your device count should be less (much less, hopefully) than 1024 If none of that helps, post back to the forum. The ISY users are the most helpful and knowledgeable of any I've ever encountered anywhere and the support from the UDI tech guys has got to be the best in the business. I saw that you had a bit of a time there with a previous problem but bear in mind that the last few months has seen some 24/7 coding/troubleshooting by the UDI gurus as they struggled to get the now stable 2.7.15 firmware out for us. mark

Hi there! Funny you should have posted that. I was just standing in the shower thinking to myself that it was working just right. Thanks very much for your help! I've since changed several other sensors in the house to work the same way - ones in hallways and in stairwells so that they turn on nice and dim during the early hours of the AM but full brightness during the pre-sleep evening hours. Running them like this is far better, in a sense, than running them purely off the sensor. Varying on levels, and adjustable durations make them far more 'personal'. The only drawback, of course, is that without the ISY running the lights will turn on but never turn off. Hopefully that won't end up being a problem. It's interesting that it worked using the MS as the controller in the program but not using the scene in which the MS was the controller - which is the way I first set out to do this. I'm not sure I entirely understand why that is but wtf... so long as it works. Thanks again, mark T

ahhh... ok.. that's something I've yet to try. I'll give that a whirl and see if it does what I'm after. I never thought of setting the scene level on the motion sensor. mark