upstatemike

Does the chatter eventually settle down? Sometimes repeated power glitches can cause the ISY to restart which would kick off the polling to check the status of your devices. With 80 of them it will take awhile, especially if it keeps restarting due to flaky power. Another thing to look for is a bad Access Point.

I'm not sure why you would expect that they would. If you don't use the ISY to set up your links then it has no way of knowing about them to display in the topology. The correct way to set up a 3-way switch, for example, is to create a scene and then add each switch to the scene as a controller. This creates the same links you were doing manually PLUS it updates the ISY database so that the topology and switch status displays correctly.

This reminds me of the lengthy Scene vs Group discussions of long ago.

I would think a good reason to link to an Access Point would be so it would be polled each night along with the other devices so you could be alerted if there was a communication problem (somebody unplugged it or it failed). This assumes an AP will respond to a status request which I don't know if it does.

What about connecting a 2410 to the Stargate and using ASCII to send and receive Insteon signals directly?

I think the TC/Stargate and the ISY are equally reliable pieces of hardware. It is just that the ISY does not have direct inputs and the TC/Stargate does not support Insteon. To use the ISY for monitoring inputs you can use your Existing TC to trigger X-10 messages to the ISY or use an I/O linc to send Insteon messages to the ISY or you can use an Elk alarm panel to send network messages to the ISY. Regardless of what you do the state of your input will be held in a table in the ISY and will only be as accurate if every single trigger message gets through. With the TC, if a state change is missed there will be several opportunities per second for it to be noticed and corrected through polling. It is a different hardware implementation for a different mission. In reality, you will probably never again see truly "all-in-one" automation hardware the likes of TC, Stargate, or Homevision. HAI has stretched their security platform to cover most of what a dedicated HA box can do but their programming command set is very limited which in turn limits their ability to do some things that can be done easily with a TC. The same could be said for the Elk M1. Your best bet is to focus on separate subsystems that can work together but also stand alone if needed. A typical example is: ISY - Lighting admin, dusk/dawn and timer control, low criticality inputs through RF motion sensors and I/O lincs. Elk M1 or TC or Homevision - critical hard wired sensors and inputs, keypads, thermostats, telephone interface, relay outputs Homeseer or other PC based system - touch screens, text to speech alerts and messages (weather forecasts etc.), security camera interface, etc. Sonos or Slimserver - Whole house audio These systems all coordinate with each other across your home network but will continue operate independently if the other systems are off line. I guess this is a long way to make the point that you can't expect to replace a TC with another single product. It will likely take a combination of things since there is no product that combines high reliability wired inputs with Insteon management and control.

I think ou find the 2 systems complement each other without too much overlap. I use a Stargate because I use voice prompts extensively but apart from that our situations are similiar. As an example of how I use the two together: My garage door is connected to a Stargate Input. If the door is open and it gets to be sunset the stargate senda an X-10 On command to an address. ISY sees the X-10 command and turns on the garage lights. Another Stargate input tracks the bulb on the garage door opener. If the gargae door closes AND the bulb on the opener times out then Stargate sends and X-10 OFF command which ISY sees and then turns off the Garage lights. Sounds makeshift but the operation is very solid. Over the past several years I have come to appreciate the solid performance of the Stargate and would have to think long and hard before replacing it with something else. Also be very aware of the advantages of high reliability inputs like on your TC which are polled for status many times per second. Replacing these with devices that simply detect a state change once and update a status table is likely to lead to disappointment. With the TC you always know an input is what the TC says it is. With other systems you are never sure if an event was missed and the status table is incorrect.

Also related to this. If you add a motion sensor to a scene that has a RemoteLinc already in it you will be asked to put the RemoteLinc into linking mode even though there will be no links written to the RemoteLinc for the motion sensor. (The RemoteLinc should not expect a cleanup response from the motion sensor when the RemoteLinc activates the scene). Shouldn't you be able to add a motion sensor to a scene without putting any RemoteLincs that are already in the scene into linking mode?

Sorry if this was already answered but I'm confused about the the way the motion sensor is displayed as a responder in a scene. While the MS is actually only a controller, I can understand it being displayed as a responder in order to see when it has been activiated. My confusion comes when the motion sensor is part of a scene and the scene is activated by a different controller such as a ControLinc Button and the MS is shown to turn on along with the rest of the scene even though it has not been tripped. Wouldn't it be more logical if the motion sensor showed on only if it is tripped by motion? In other words, if I turn on a scene from the GUI that includes a motion sensor, shouldn't all of the devices in the scene turn on EXCEPT the motion sensor which has not actually been tripped?

I would like to suggest another approach as a workaround until SH is able to reproduce the problem. If the Restore Modem routine was changed so that after restoring RemoteLinc and Motion Sensor links it then added the remaining devies to the PLM link table alphabetically by name instead of sorted by Insteon address, this would help in the short term. Those of us with many devices could simply rename those switches that are a priority for us with a leading "A" or "0" and then restore the modem so that they end up in the lower part of the PLM link table. This would also be useful in troubleshooting since we could easily demonstrate how the same switch acts differently depending on where it is in the table. I don't think there is any negative impact to other folks with smaller link counts and the code could always revert back to the old sort method at some future time when the PLM firmware has been fixed. Would something like this be possible?

No, there is nothing at all in the Event Viewer. I can see the traffic generated in the flashing LEDs of other Insteon devices repeating the signal but there is NO entry in the Event Viewer at all. It seems that the PLM simply does not pass anything on to the ISY.

I'm afraid the new PLM did not resolve anything.

There is a chance that this will put the switch in series with the load and underpower the switch.

There is a ground wire on the grounding point of the metal box. Newer installations would also have a ground pigtail to the device itself but that was not always a requirement. Not having a neutral is certainly the challenge here.

So I assume there is no chance of a solution in the near future? If Smarthome has to find the problem, create a firmware fix, apply it to current PLM stock, and then I would have to go through another exchange cycle... maybe 60 days? I suppose I can delete all of my devices that do not participate in scenes and then restore the PLM so that everything that remains hopefully ends up in a low enough point in the PLM link table to work correctly. ***edit*** I just checked and I only see 1 switch that is not in a scene so I guess that idea is not going to work.

I do not think this proves that I have reached a link limit. It only shows that links in higher memory locations are not registering properly. The cause could still be: 1- The PLM really is hitting a link limit. (Unlikely since the links are visible when you view the PLM link table). 2- The PLM does not pass information about local activation for links in higher memory locations. (Unlikely because other operations such as link creation, query, etc all work fine.) 3- The PLM transmits local activation messages for links in upper memory locations in an unexpcted format that ISY does not recognize. This seems most likely and would exactly fit all of the symptoms. There could be some header or attribute in the message syntax that is different for higher memory locations. ISY would simply ignore these "invalid" local activation messages.

Update- I removed the new test switch from the ISY and then shut the ISY down. I did a factory reset on my old PLM and brought the ISY back up with that. I then added the test switch back into the ISY so that the only link in the PLM was for that one switch. The ISY now tracks local control for that switch perfectly. I even operated it on and off relatively quickly and it never missed a single change.

Yes I will still do that on the weekend but I was hoping for a rapid fix. I can't spend any extended time on this during the week and did not want to delay a possible solution if I could just swap the unit. On Saturday i will remove the test switch from ISY, factory reset the old PLM (which is the one we want to do this test on anyway) and then add the test switch back to ISY with the empty PLM to see if it works correctly.

My new PLM came sooner than expected. It is a rev. 2.9 and ISY reports the firmware as v72. I did a replace modem and then tested the basement stair switch. It still does not report local operation. I then tested the brand new switch that I have plugged directly into the PLM. It reported the first paddle press and then nothing after that. I guess it is not a PLM problem.

I tried to do a walk through to see if I could confirm the theory. I sorted my insteon devices by address so it matched the PLM link table and then started testing which switchtches report and which don't to see if I could identify a clear boundry point in the PLM link table. Unfortunately I am running into paddle problems in clusters of switches that are seldom operated manually (I just found that 3 out of 4 in a particular 4-gang box have a paddle issue... I can't even get them to operate if I tap a bunch of times in a row!) so this test is not really working out. My new plan is to install a replacement PLM next Saturday and see what that does for the reporting problem. I will also do a full walk-through on Saterday to see how many switches now have to be replaced for paddle issues. (I really thought I was past that!) If the PLM does not help my reporting situation and/or the number of physical switch failures turns out to be high, then I will need to pull back and re-evaluate where I'm going with this whole thing.

Unfortunately I have already sent the old PLM back to SmartHome. I will have to wait until next Saturday when I have the new one before I can do any more testing. If I were to identify a switch that is working OK and then replace it with the new switch that does not work, would that move the new switch's links into the old switch's position in the PLM link table? Or would it leave it where it is and change some pointers? How about if I delete a switch near the beginning of the table and then add a new switch. Will the new switch be added in the slot vacated by the one I just deleted?

I just had another thought. Most of the switches that are giving me problems are towards the end of the PLM link table. The switches in the basement worked for a long time and were some of the first switches installed so the links for them were near the beginning of the PLM link table. When I replaced my PLM to resolve the problem with my other switches, the links were sorted before being written to the new PLM and the basement links ended up close to the end because their addresses mostly start with 9. Also any new switches I try to add for testing get linked at the very end of the PLM link table. I wonder if there is a point in the PLM link table above which local control links do not work correctly? Maybe when I "fixed" those other switches by installing a new PLM, the real fix was that their links got sorted to a lower point in the PLM link table? And if the basement links moved up past the boundry point they would have stopped working for no obvious reason.

I fixed it by deleting from ISY/facory reset/ add back to ISY/add each button back to its scene. Seems to be working now.

No I did not always have this problem. The basement lights "Off" routines were the first programs I created on the ISY and they worked raliably for many months and at least up to September. I am not certain exactly when those problems started because at first when I noticed them being left on I assumed it was just an intermittent communication problem of some sort. Then I tried adding some new programs upstairs and ran into reporting problems there just after Thanksgiving. I eventually fixed those by swapping the PLM and thought that everything was Ok again. Later in December I noticed the basement lights were still staying on so I did some troubleshootong and discovered it was not intermittent but rather a hard failure. No lights in the basement were reporting status. After that I added several test switches from my remaining spares to move around to different locations as a test for noise issues. The spares would not report local operation even when plugged directly into the PLM. I tested many of the other switches in my system and found the number that did not report to be very high (over a dozen) which made individual switch failure statistically unlikely. Many of the switches that were not reporting used to work reliably to trigger programs. No major changes to electrical loads in the house. Many changes in ISY devices (renaming, reconfiguring scenes, etc) plus maybe 6 or 7 new devices added during the Fall months.

Just a reminder that I have ruled out noise by plugging switches with this problem directly into the PLM with no change resulting. I also already replaced the PLM last month but I have ordered another one anyway which will be here by next weekend. I'll see what happens with that.