MarkJames

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

Thanks, Oberkc... I'd actually gone down the path of enabled folders depending on time of day. The thing is that I'm really trying to avoid programs for turning the light on because of the lag issue. I see your point, Rand, as far as making the ramp rate longer but personally I don't much care for the ramp on effect outside of things like a movie mode or dinner mode or something like that. I like having the sensor turn it on as part of the scene as that's pretty much instantaneous. The light switch is just inside the door - so when you walk in and the light doesn't pop right on - which is what happens with programs - you tend to hit the button - which isn't a big deal but it defeats the purpose of the sensor. The other issue with the sensor is that if you have a long off time and someone manually turns the light off then the sensor won't send another ON until the delay times out - so a short delay is preferable. On the other hand, if you go out of sight of the sensor - like in the shower - a long delay is needed. It gets unwieldy. What I'm trying to accomplish is to have the sensor turn on a different scene depending on the time of day. I'd hoped that I could use the ISY adjust scene program control to change the on level for a scene. What I'd originally written was simply a program so that at 10pm an adjust scene happened that turned the level of the bathroom light to 20% and then at 6am it turned it back to 100%. But I misunderstood this function and it doesn't work the way I'd anticipated - it just turns the light on to the level I specify at that time - in other words it's not changing the on level associated with the responder link - it's merely adjusting the scene light levels. This is also a useful function - but doesn't help me. So what I'm doing now is making the sensor the controller of a scene with the bathroom light in it set to 20% So the sensor will always turn it on at 20% but during the day the program will jump in a moment later and ramp it up to 100%. This works for the most part - I'm just trying to come up with a more creative way. I don't know if it's been suggested before but it might be a nice function to add to ISY so that you could actually have the ISY write or change links and scene memberships programatically. That would allow you to have scene levels change depending on device settings or even allow you to change it so a button controls one light during the day but another during the evening.... could be very cool. It wouldn't entirely solve my motion sensor issue as the sensor wouldn't be in linking mode so it couldn't be changed directly... ie I wouldn't be able to change the timeout, but the responder record in the controlled light could have its on level changed without needing the sensor record changed. I'll look at the motion sensor programs recommended and see if that helps me any. [edit] I just looked through the bathroom programs in the wiki. They are, indeed, very complete. Makes me want to add a wireless contact to the bathroom door just to run the fan The only thing is it still has the issue of program lag. I'm going to have to do some benchmarks and see how long it takes as a scene member vs as a program and decide what to do. Thanks, mark

OK.. that makes sense..... and it's an easy enough change. Can you think of a more efficient way to do this, though? Have a motion sensor trigger a scene with different on levels and different time outs dependent on the time of day? I had originally done this with programs alone - not letting the motion sensor directly control the light. The only problem with that is there is a slight lag between the sensor message and the program execution. I'd also tried setting a program to adjust the on level of the scene dependent on the time of day but it seems that the adjusted on level only 'sticks' till the light is turned off - so the next time it turns on it goes back to the local on level. The two things that drive me craziest with HA are motion sensors and trying to determine if someone is coming into the house or leaving the house. mark

Well, I've run into a bit of an understanding problem. I have a 2420 that I'm using in my masterbathroom to turn on the lights. The thing of it is that I'm trying NOT to use the 2420's built in off command. The reason for this is that I'm trying to get the lights to turn on for say 15 minutes at 100% during the morning - it has to be long enough so that the lights don't turn off while the sensor can't see you in the shower. Then on for like 5 minutes during the day, again at 100%, but for only 3 minutes at 20% during the early hours for when you get up at night for a quick pee. So my sensors are Rev 2.0 so I can program them using ISY. I've set the jumpers so that they don't send an off command, and they're programmed from ISY. The basic setup I've chosen and there's probably a better way is this... The sensor is controller of a scene with the bathroom light as responder but the light is set for 20%. When the sensor turns the light on a program runs and checks the time. If the time is daytime it runs a different program that adjusts the scene to 100%, waits 15 or 5 minutes depending on the time of day and then turns it off. If the time is nighttime then it runs a program that simply waits 3 minutes then turns it off., leaving the scene at 20% The reason for the second program running is a bit legacy in that I didn't want the sensor OFF message retriggering the program and running the else effectively canceling the wait. The problem is that with the motion sensor jumpered to not send an off - I'm confused as to whether ISY will ALWAYS see it as on. Any thoughts on a better way to accomplish this? and any thoughts on the limitations of using a 2420 in ISY that doesn't send an OFF? Actually, I guess more significantly, what does it mean to ISY when the sensor doesn't send an OFF?. Does this mean that it won't send an OFF message to its responders but will still report its own status as OFF? Or does it simply not send an OFF anymore? Can ISY still expect to see the sensor status OFF after the timeout delay set in the sensor? mark

My upgrade went smoothly. I think I upgraded too quickly, though, and got a brain freeze. This might be related to the code freeze you mentioned earlier. I'll try upgrading more slowly and see if it's reproducible. mark

Hi, Michel, I reset the PLM and did a restore. My count is now 565 and my motion sensor status is reading correctly. Thanks for the help! mark

Hi, Michelle, Yes... I've been away a bit.... we've had some health issues in the family to deal with so HA has been on the back burner for a while. Things are back to 'normal' now so I have some more time. I think you've hit the nail on the head as far as links. I'm using a 2412S and the PLM link table count is now at 4228 and still counting! That's just wrong! This is odd as I haven't added that much recently and my count was down in the 500's a while ago. I had an issue trying to restore one KPL and ran the restore multiple times before it finally 'took'. That KPL had an 'all lights off' scene attached to it which contained some 90-100 links. I must have run the restore at least 5 times. Could it be possible that each time I ran the restore it duplicated the link records in the PLM? I ask because if that's the case then wiping my PLM and letting ISY restore it should fix my problem and bring my count back down. mark

I don't think so... I have 5 other 2420s and ISY shows all of their states for motion sensor on/off, dusk/dawn on/off and low batt on/off. With this one I don't see a state for any of them. It does, indeed, work as I can link it to devices manually and control them. ISY sees it too, as it will add it as a device and set/read its options. I wonder if it's faulty....

Any idea why a 2420m that I just added to my system won't display it's state? It's a version 2.0 but I have the jumper off so it' just using its default settings. It added fine but I can't see it's status (on/off) from the ISY Mark

Teenage daughter and her friend. I thought my daughter was bad... her friend made her look like an angel. By the second day of a 4 day Easter weekend stay I'd blocked the mac address of her laptop and her ipod touch and blocked all cell access. Before I did she spent 8pm to 3am laughing and skyping with her boyfriend - spent every waking moment texting and every other moment on either facebook or skype. I love technology but I HATE social networking sites, texting, skype, and MSN and its relatives. Kids these days have lost the ability to be by themselves and don't seem to grasp how rude it is to sit at a table with one person while texting a different one. Fortunately if it comes down to a battle of technology I'm a very well armed individual. Knowledge IS power.

hahahahahahahaha never mind... I figured it out. I've been running a high powered cell phone jammer for the last couple of days. It seems to interfere with the RF capabilities of Insteon. I turned it off and all returned to normal mark

Well... I recently upgraded to pro - but I'm having issues that I didn't have before. At the moment I'm trying to add back a 2420m that I could not restore the links in. I cannot add it back, though. Here's the log of the attempt Sun 04/04/2010 08:30:40 PM : ---- Initializing the linked devices ---- Sun 04/04/2010 08:30:40 PM : ---- All Linked Devices are now initialized ---- Sun 04/04/2010 08:30:40 PM : ---- Add remaining devices ---- Sun 04/04/2010 08:30:40 PM : [ 11 A6 36 1] Removing all links Sun 04/04/2010 08:30:40 PM : [11 A6 36 1 ] Querying engine version Sun 04/04/2010 08:30:40 PM : [iNST-ACK ] 02 62 11.A6.36 0F 0D 00 06 (00) Sun 04/04/2010 08:30:48 PM : [iNST-ACK ] 02 62 11.A6.36 0F 0D 00 06 (00) Sun 04/04/2010 08:30:57 PM : [iNST-ACK ] 02 62 11.A6.36 0F 0D 00 06 (00) Sun 04/04/2010 08:31:00 PM : [11 A6 36 1 ] Failed getting engine version. Reverting to i1. Sun 04/04/2010 08:31:00 PM : [11 A6 36 1 ] Using engine version i2 Sun 04/04/2010 08:31:00 PM : [iNST-ACK ] 02 62 11.A6.36 1F 2F 02 00 00 0F FF 01 00 00 00 00 00 00 00 00 00 06 (02) Sun 04/04/2010 08:31:09 PM : [iNST-ACK ] 02 62 11.A6.36 1F 2F 02 00 00 0F FF 01 00 00 00 00 00 00 00 00 00 06 (02) Sun 04/04/2010 08:31:17 PM : [iNST-ACK ] 02 62 11.A6.36 1F 2F 02 00 00 0F FF 01 00 00 00 00 00 00 00 00 00 06 (02) Sun 04/04/2010 08:31:21 PM : [ 11 A6 36 1] ** Not added ** Remove Device Links failed Sun 04/04/2010 08:31:21 PM : ---- All Remaining Device Added ---- I'm on 2.7.14 I've hard reset the motion sensor twice already There are 563 devices in my PLM link table I put the device into linking mode prior to adding it I believe this is a symptom of a more general communication problem as I seem to be having a hard time restoring/writing to devices all of a sudden even though everything is functioning properly. I can't understand why, as nothing I can think of has changed. I have two devices which are not functioning but I've disabled them. Thanks for any insight. mark

Earlier this week I was testing an old KPL I had lying around the house. I took a power cord off an old pc and cut the female end off. I left the ground wire on it - stripped - plus it has a reinforcement wire running its length to prevent stretch. This wire is also hooked to ground. I wirenutted the load and neutral to the KPL and cord to energize it and was programming it. I had just finished programming it in ISY (it was plugged into the wall - wirenuts on load, hot, and neutral - no wire nuts on the loose ground wire or reinforcement wire). I flipped it over to see what labels it had and when I flipped it back the bare ground end slid up inside the wirenut on the load wire. The KPL literally exploded. So much for a $60 KPL - but a good lesson to cap/tape any wires not in use. mark

but be sure and put a wirenut on the load wire - it'll still go hot when you press the on button. mark

ahhh... Thank you. You prompted me to look on smarthome.com - There's a newer manual for the rev 2.0 which shows J5 jumpered for remote management. Much appreciated! Mark

They are reasonably new (past 6 months) - rev 2.0 They have adjustment pots but I don't have any jumpers on. My 2420 manual shows J1 - sensitivity J2 - disable LED J3 - night-only J4 - on-only J5 - not used.