johnnyt

All of a sudden none of my 4 motion sensors are being recognized by ISY. I don't know if it's related but it happened right after I added the network resources module and set up ISYAJAX for use with my iPod Touch as well as used the Function Exporter for some Sonos interaction. I suspect a pure coincidence but mention it - and post here - just in case there's a link. I have 2 access points plus a dual band PLM and a dual Switchlinc in a ~2400 sq ft home that has been working almost flawlessly since I moved to Insteon last fall after 10 years of using X10. Have unplugged and re-plugged the access points (after waiting at least 10 secs off) and confirmed (again) that there are on different phases, for what that’s worth. I did notice that the access points are quite warm on the wall side when I unplugged them. Could they be working too hard for some reason? How can I find out? I’ve not added any motors or other electrically noisy equipment to my house. Also the ISY does not show any abnormal activity (with event viewer set to "Device communications events".) Any suggestions, or known issues with network module use?

actually one is able (in fact forced) to add a sensor as a responder when it is already a controller in another scene. I was going to use that as a workaround but I ended up doing things differently.

Sorry that I've made this confusing. Re-adding the "bad" IO Linc (17.78.CF), creating a scene with it's sensor and all the other IO Lincs then deleting that scene deleted the rogue records and fixed the problem. I've also learned that: 1) putting an IO Linc sensor as a controller in a scene makes the manual tapping of the set button on the IO Linc activate that scene. 2) one cannot add an IO Linc sensor as a responder to a scene (e.g. for querying purposes) until it has already been added to a scene once as a controller because ISY assumes one wants/needs it to be a controller the first time around. Perhaps the right assumption most of the time but not always, particularly given the behavior mentioned in 1) above. Thanks.

I think my basic request is getting lost. I don't want anything responding to 17.78.CF so I want to delete the record with 17.78.CF in it from the five IO Lincs it currently exists in. How do I do that? (a quick reminder that removing/re-installing/re-moving the device didn't do it.)

The "bad" IO Linc relay did not lead back to its own sensor, if that's what you mean. The sensor was used to detect an AC call. I'm currently using another IO Linc to do this job and everything is working fine. When the sensor is activated (i.e. Call for AC) I have a scene to turn on some of the relays on other IO Lincs (close basement dampers, etc.) but that scene is controlled by an ISY program, not the sensor input. Have attached a screenshot showing the device and ISY links table of one of the five IO Lincs that responds when I activate the relay on the bad IO Linc. I circled the address of the "bad" IO Linc which has been removed (twice now) from ISY and sits unplugged/unused on my workshop bench. By the way I can just plug the "bad" IO Linc in, not link it to anything and the other IO Lincs respond when I tap the set button. This by itself is strange to me given my understanding that the manual activation of an IO Linc relay did not broadcast it's state. (which was the reason I needed to create a scene to query my IO Lincs in the first place). Am less concerned at this point about the apparent inconsistency in behavior or in my understanding as I am about deleting the rogue record.

sorry, that's not accurate. None of the scenes include the sensor input from the "bad" IO Linc but some do include the relay in case that makes a difference.

I should mention this likely occurred a number of firmware versions ago. I created the scene that probably created the now rogue link record several months ago and have upgrade a few times since then.

am running firmware 3.1.3 I think I know what you're asking but I'm not sure. I generated the topology and the first thing I did was look for the "bad" IO linc. Not found. I then picked a couple of the IO Lincs that respond to the "bad" one and looked at each one of the scenes it said they belong to. None of the scene include either the sensor or the relay from the "bad" IO Linc in them. Would you like me to provide you screenshots of the scenes that include some the responding IO Lincs to validate this?

yes. the address is both in the devices and in the ISY Links table. I did compares while I was checking the deive and just checked the ISY links table again now for a few of them.

I've since tried completely removing the problematic IO Linc (I'll call it IO Linc "A") from ISY but the responder record for it remained in at least 2 of the other IO Lincs. (Am only checking 2 of the 5 "other" IO Lincs but all of them behave in the undesired way.) Then I tried re-linking IO Linc A since the last step in that process is to "remove existing links". Even after removal of IO Linc A, which is supposed to remove all links, and re-linking it, which is also supposed to remove all links, the "responder" record entry remains in the other IO Lincs. When I tap the set button on IO Linc A the others all go ON / OFF in sync with the activation state of IO linc A. All these IO Lincs are related to HVAC stuff (Furnace Fan High Speed, HRV High Speed, HRV Low Speed, Humidifier, Motorized Dampers). I used the sensor input of IO Linc A to monitor a furnace AC call with a low voltage detector probe and believe the problem stems from a scene I created for the purpose of querying all the devices periodically (since manual activation and sensor activation wasn't updating ISY). I added the input sensor of IO Linc to the scene intended for this query and it added it as a controller (I had no choice in the matter - I would have chosen responder if given the choice since the intent of the scene was to query the devices, not control them) The problem of IO Linc A activating the other ones must have started happening after that scene was created (I'm not sure). In my attempts to fix the issue I think I likely reset/restored the IO Linc, removed and added the device, and I don't know what else but I did struggle with it for a while myself. The bottom line, though, is that a responder record remains to this day in 5 IO Lincs and gets updated by ISY to match a new IO Linc device address however doesn't similarly delete the record when I delete the device. All the IO Linc are configured per the attached screen shot. The offending IO Linc (A) was configured with "Relay follows Input" at first but that was removed later. This doesn't prevent the activation of IO Linc A from activating the other IO Lincs. I likely messed up something in my attempts to recover after the scene I created did the unexpected/unwanted but something else is messed up and the record has gone rogue on me. Is there a way (e.g. command line?) to surgically remove a record from a device?

A responder link for an IO Linc? Two things seem weird to me about the programming that has entered in these IO Lincs. One, the other IO Lincs would react to my pushing the set button, which is inconsistent with the behavior of an IO Linc - the other IO Lincs I have certainly don't broadcast a manual push or sensor input change. (I have to query them for ISY to know they changed.) Why is this one doing it? Also, I've removed the offending IO Linc by manually adding a new one to every scene the other one belonged to and replacing the old one for the new one in every program then DELETED the offending IO Linc (17.78.CF) yet a record remains in the other IO linc devices and in the main links table... What's going on? How do I kill this mummy? Do I have to remove and re-add every "other" IO Linc manually? (yuk) I assume just doing a device restore will only add the responder link back in... Thanks

One of my IO Lincs when its relay activates cause all my other IO Lincs to activate (all control some HVAC related stuff). They are not part of a scene and they are not set to respond to X10 addresses. (FWIW, I did set the misbehaving one to *send* an X10 address at one point but I removed it and see no evidence of X10 going out on the line - but still the other IO Lincs aren't set to respond to an X10 address so this should be irrelevant) I replaced the misbehaving IO Linc with a new one (using ISY) and the behavior continues with the new one (indicating it's not a h/w problem) so I checked the device links file for a couple of the "other" IO Lincs and noted one record related to the misbehaving IO Linc (17.78.CF). The (sole) record is A2 01 17.78.CF 00 00 00 in both other devices. Can someone tell me what that means? Am guessing it's a remnant from a scene I might have toyed with that is not longer around but didn't get deleted for some reason. Or it's some kind of linking sequence gone bad where all IO Lincs somehow got linked to the one. Assuming that's the case, how do I delete the record? Any info / other suggestions as to what might be happening would be appreciated.

Thanks for the reply. I know the logic works to turn the light on (since it's the only program I have to turn the light on) If I didn't know better (and I guess yesterday I didn't) I'd say that ISY was not recognizing that I've switched the light off (or fast off) but I'm realizing it's that the condition gets re-evaluated immediately after I clicked off (or fast off) because the light status changes from on to off; it then sees all conditions as true again and turns the light on again. In other words it has, within milliseconds, completely "forgotten" about the off or fast off event. It's brilliantly logical but not as intuitive as I might have liked. I've created a second program for "switched off" OR "switched fast off" that disables my first program, resets my bathroom motion flag, waits 2 seconds and re-enables the first program. Now everything works fine.

Here's a link to the current iteration of an older version of X10 mini timer I use to send an X10 signal that ISY programs then respond to. The only additional module needed might be an X10 phase coupler but you could try without one if your PLM is on a circuit on the same phase. Not sure. I happen to have one since I do have some other X10 stuff I haven't moved to Insteon - and may never. http://www.smarthome.com/1091/X10-XPMT4 ... MT4/p.aspx I use one X10 code for alarm 1, which simply turns a floor lamp on very slowly (using Lamplinc). Then I set another X10 code later to turn on a radio (using applicancelinc). Finally I sometimes set the mini timer's internal buzzer as a failsafe - and much less pleasant - third alarm in case the programming fails but more likely because I think the "users" will need a little extra push to wake up (e.g. short night). I haven't had an X10 alarm fail to work but wouldn't bet on it never happening because it is X10. I think, however, it would be very unlikely both X10 triggers would not work unless I've got some kind of programming-induced power line comms flooding going on and then even Insteon might not work either. Finally, I also have a button on a Keypadlinc in a desktop enclosure on both my and my wife's night tables to do 2 things: 1) turn the alarm on/off so we don't have to reprogram the mini timer to turn it off (maybe the new one is better at that but the old one requires reprogramming to disable the sending of an X10 code), and 2) to kill any running programs when we forget and the "alarm" goes off on the weekend. (You still need to turn off the mini timer's buzzer manually but there's an easy button for that on mine.)

I have a bathroom light that I turn on when the program "bathroom motion flag" is true and the light is off. I also have logic I had hoped would keep it from going on if it's just been turned off but that part doesn't work. my logic is: if status "bathroom motion flag" is true and status "bathroom light" is off and control "bathroom light" is not switched off and control "bathroom light is not switched fast off then set "bathroom light" to 80% as I leave the room whether I press "off" or "fast off", the light does go off but then goes back on within seconds. the "flag" is set by homeseer, which accesses the DSC alarm panel that knows about the bathroom motion sensor. I deliberately delay setting the flag to false to minimize comm traffic so it will always be true for a period of time after motion has stopped but as I understand it that shouldn't matter with respect to turning the light off at the switch. but then again it isn't working as I understand it should be working. any help would be appreciated.

Thanks for your replies. Has anyone replaced an older keypadlinc with a newer one? Are those more sensitive to hardware or firmware differences? (I have some with a lot of links to redo if I needed to.) I do keep an extra switch on hand for quick turnaround (fix or addition) and think the idea of a spare PLM is a good one as far as getting back up quickly but hardware/firmware wise do PLMs remain well supported by ISY as they mature or is a "current-to-me" model key to recovering my setup as painlessly as possible? Also, if I follow the extra PLM train of thought, should I be keeping a spare ISY too? I was assuming the ISY is less likely to fail than one of the 120V hardware devices. Is that a correct assumption? (it's of course much more expensive insurance to buy) Thanks again for your thoughts.

Just thinking about the longer term and wondering if I should stock some extra "current" hardware to make my life easier if/when something fails. I know there's a tool (and I have used it once) that allows me to replace a device relatively easily. It's my understanding, though, that the replacement device must have the same firmware for this to work. In 2 years (or whatever) I'm thinking that isn't likely to be true in most cases. To be sure I am able to easily replace a device in the future, should I be stocking a current-to-me spare? Am particularly concerned about my keypadlincs, which have many scenes and programs associated. Is this really a concern? What are people's recommendations for this issue?

local LAN, e.g. 192.168.x.x (assuming that's what your asking)

Would replacing the memory card in my ISY with fastest available stuff on the market speed up loading of the ISY console and programs? Is there anything else that will - not including deleting devices and programs? Am scrounging for anything I can do to make the process quicker. Right now it takes about 11-13 secs for GUI to load initially after entering userid/password and 6-7 secs to load programs. That's on top of the time it takes to load Java, which varies more widely, and it doesn't include the time it takes when I have to login twice (once into a Java dialogue box I think and again into the ISY console dialogue box), which happens to me a lot for some reason. (I wish logging in could be turned off when connecting from LAN addresses like HomeSeer allows but I know it's not an option) I have about 110 devices and about 250 programs with maybe 35 of those being used as variables only. Am running firmware 2.8.16 and Java 6 update 23 on 2.13 GHz Core 2 Duo Vista machine with 4GB RAM and (FWIW) a Gb NIC on a Gb LAN.

Excel 2007 seems to work differently than the low/medium/high concept. The options in Excel 2007's "Trust Center" is either a variation of "disable" all (with and without notification) or enable all, which is explicitly not recommended. an alternative seems to be to provide a trusted directory. The problem I see is that ISY sends the log file to the temp directory used by all (trusted or not) apps by default. Setting that directory would be the equivalent of enabling all macros, I would think. Is there a way to change the directory where ISY sends the file for Excel, then I can add that directory as trusted for macros and not open up a huge security hole? Unless I'm just missing something about the macro security options in Excel 2007 (and latter?)

will do. (not sure when) Note that I don't have any firewall s/w running right now on my Vista machine but I do have Windows Firewall running on my W7 laptop (I uninstalled TrendMicro soon after your post and after TM support said I had to buy an upgrade to be able to add exclusions, etc.)

just to post an update static IP does not fix the problem (went back to DHCP). still happens regularly. often okay for a couple of logins on the same day but rarely do I *not* have to login twice when I've been "off" for a day or more. Have been upgrading as they've been coming out and have been at 2.8.10 for a couple of days now. Have been running Java 6 update 22 for quite a while on both my W7 64-bit and Vista 32-bit machines (same thing happening on both). Just noticed there's an update 23 so will try that and post back if it somehow fixes the problem.

Just to post an update. I got a new ISY a month ago or so, and a new router a couple of weeks ago and I've been upgrading along the way as they came up to 2.8.10 a couple of days ago but I'm still having "New Programs" end up in the root folder many, if not most, times (but not always). It doesn't happen if it's one of the first things I do after a login but once I've done a few things I can't get a new program to create in the folder I'm working in (or even show up at all - I have to "save and undo" to see it.) This happens on both my W7 64-bit and Vista 32-bit machines. I've had Java 6 update 22 installed for some time now. I just noticed there's an update 23 and will update to that for what it's worth and post back if that fixes things (no news means bad news...)

spoke too soon. static IP address did not fix the problem. I upgraded to 2.8.5, which I understand adds network error info but so far the problem, which is intermittent or at least was in 2.8.4, has not re-occured (but it hasn't been tested much yet.) - Note: I went back to DHCP too.

spoke too soon. static IP address did not fix the problem. have upgraded to 2.8.5, which did not fix the problem either but from what I understand if it's a network related issue, there may be some useful info in the error logs at some point. Although none came up tonight after the problem happened again, I'll check periodically in case something shows up. I tried exporting the "New Program" and re-importing it and it created a duplicate (empty) New Program in the root folder. Also exported another program and imported it into the root folder. Just made a duplicate of the same program in the root folder. Tried creating another New Program after this and it still did not come up until I did save-undo and then it comes up in the root folder (i.e. same problem). I don't know if this provides any more clues as to what's happening.