upstatemike

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.

OK this is definitely part of the reason this is so frustrating. I ran the reports and the PLM link table did not show the basement stair switch at all and was also missing a lot of other switches as well. Total link count was 658. I closed the ISY console and cleared the Java cache and then opened the ISY console and ran the PLM link table report again. This time the missing switches were there and the total link count was 773. Here are the results: PLM Link Table: E2 00 E2 34 E2 39 E2 6C A2 01 ISY Link Table: A2 00 A2 34 A2 39 A2 6C E2 01 Switch Link Table: A2 00 A2 34 A2 39 A2 6C E2 01 Even though the links are there, local changes are not seen by the ISY. So next I deleted the switch from the ISY. I did a factory reset on the switch and then reinstalled it. It still does not report local status changes.

I will test the double tap on the new switch later tonight. I can wait for a fix on the new switch but I have too many old switches not reporting to let that go unresolved. I will go back to the one at the top of the basement stairs and revew the links once again. If I can get that fixed then I will be in a much better place.

I have already done a "PLM replace hardware and restore" so that variable should be resolved. I have done "switch delete/factory reset/add back to ISY" and eliminated that variable. (many many many times) I have done "replace switch with new product" and eliminated the variable of faulty switch hardware. I have done "plug directly into PLM" to eleminate the variable of noise. Based on your analysis, what are you suggesting is my next step? I guess I can take this new switch and go through the link verification process again but other than that...?

Update- I got a brand new switch in today. I connected it to my test cord and plugged it directly into the PLM. I added it to the ISY and and confirmed that I can query the switch to discover the correct status. It does NOT however report status when operated locally. The switch says Ver. 4.1 on the sticker and the ISY reports it as "SwitchLinc relay V .35 At this point I do NOT think this issue is due to problems with my switches. Nor is noise a problem based on the fact that none of my problem switches work when plugged directly into the PLM. Having replaced the PLM last month I am concerned the problem is most likely within the ISY database itself since that is the one common element that gets carried forward each time I restore a device, replace a PLM, etc. Is it possible for the ISY database to get scrambled up somehow?

I just got a new controLinc for my kitchen to replace the old one that would not control the switches linked to button 1. I added the controlinc to ISY and was surprised that it did not prompt me to press any butoons on the controlinc befor proceeding as I recall having to do in the past (I am using the most recent version of ISY firmware). After the new ControLinc was added, I right clicked on button one of the old ControLinc and selected and replaced it with the new ControLinc button 1. Again, I was not prompted to press any buttons on the ControLinc before proceeding. The replacement took much longer than normal and I got many strange messages during the process such as: "LR RMT Failed Getting engine version. Reverting to I1." This was strange because the Living Room remotelinc is not part of any scene in common with the kitchen ControLinc and does not have any links whatsoever with any switch controlled by the kitchen ControLinc. So why was the ISY99 even looking at the LR RMT remotelinc during the eplace process? I got the same message in reference to a couple of other remotelincs as well as my test switch which was not plugged in and which also has no links to the ControLinc being swapped. After the process completed the buttons on the new Controlinc did not work at all although if I press All ON or All Off the sitches linked to button 1 will turn On and Off. The switch linked to button 2 does not respond to anything I do on the ControLinc. Do I need to follow a different proceedure to get the ContrLinc programmed correctly?

These are the same symptoms that I see. The correct links exist in the PLM, ISY, and Switch, but local operations never register in the GUI or event viewer. Other linked modules always activate reliable (so the switch is transmitting) and all other operations including query, restore, replace, and operation from the GUI controls, work perfectly.