Mystery Light Turning On

[apostolakisl]

Can the images be posted inline rather than hosted. Attempts to expand image makes them unreadable.

 

Note that some of the differences are the result of a Restore versus no restore. The link records are in a different order between the two systems which looks like many mismatches when it is really a different order.

 

The above images are links, if you click on them they should open up in imgur.com and then you can click on the image there and it opens a full size shot. I'll post them straight up on the forum, but please let me know if they dosn't work for you. I just started using imgur and maybe it doesn't work as well on other machines as it does on mine.

[apostolakisl]

This should show up full size right on the forum

 

 

 

You can see on the breakfast room light that the highlighted link references the upstairs light. Those two switches are not supposed to share any links.

 

It would be nice if there were a function that turned those links tables into responder/controller lists so you could check the validity. Also, it would be nice if you could edit out extra links that aren't part of any proper scene without deleting the device and starting over.

[LeeG]

Thanks for the new posts, that helps the old eyes. Unfortunately those compares are not helpful. Besides being in a different order note the last byte of each record is a 01 in the device. That was a change made a few images back to support another Insteon change not related to I2CS. The ISY link database in the 99i does not reflect that change as well as being in a different order.

[apostolakisl]

If you look at breakfast light, I didn't put the side by side up with the ISY table, but suffice it to say that the "extra recored" items are indeed completely extra with nothing similar currently on the device. The current links on the actual switch properly enroll it in all of the same scenes in the same capacity as prior, so i would expect the same number of links.

 

So those 4 links must truly be extra links which would not be necessary to be part of the same group of scenes. As I mentioned, the highlighted line references the upstairs 2476d's address which should in no way have anything to do with breakfast room light. I would assume that this is the particular link that was causing the problem. But I do not know what all of the code means, I can only pick out device addresses.

 

NOTE: 19.75.34 is my PLM.

[LeeG]

Three of the link records that are labeled missing in Breakfast Rm are Controller records (start with an E2) which the device does not look at when responding to a command from another device. The fourth is a Responder record that has the PLM address and Group 255 which would be an All On/All Off from the PLM.

 

The link record in Upstairs Frt Bed Hall that is labeled extra actually matches the link record in the ISY database, only one record above. The link records are in a different order and there is one more link record in the device now than in the old 99i ISY link database.

[Michel Kohanim]

apostolakisl,

 

Based on our releases, it seems that you were on 3.1.10 or lower. We'll do a root cause analysis to see if anything could cause ISY to keep a record that has been deleted from the device. If you have your error logs going back that far, please look for any -11000x errors during the same time frame.

 

With kind regards,

Michel

[apostolakisl]

apostolakisl,

 

Based on our releases, it seems that you were on 3.1.10 or lower. We'll do a root cause analysis to see if anything could cause ISY to keep a record that has been deleted from the device. If you have your error logs going back that far, please look for any -11000x errors during the same time frame.

 

With kind regards,

Michel

 

Thanks,

 

It appears that I have about 40,000 -170001 errors filling my log. I believe it has something to do with an outside service trying to access my ISY and failing authentication. Not sure what to make of that. The log is only going back to March, I assume since the 170001 error is so numerous it has filled all available memory?

[apostolakisl]

Michel,

 

I do have backups going back to 2009 corresponding to most every frimware update. Would you be interested in any of these? I assume you would be able to pick up exactly when the extra links showed up. Or if you would like, I can restore some myself to my old ISY and pull the links tables.

 

I do see that on 11/23/11 (the day I bought the new dual band switches) I saved a 3.1.12 which means on that day I would have installed whatever the current release was. My next backup on this computer was 3.1.17 in March 2012, but I also do updates from my office computer so there are probably some more in between.

 

Edit: I installed 3.1.13 on Nov 23, 2011. I found that firmware version on my computer and that was the "date last modified".

[Michel Kohanim]

Hello apostolakisl,

 

First of all, if you have so many 17000 entries with num=x authorization problems, then I think it would be best to address that first especially since your ISY is connected to your ELK. If you telnet to ISY and issue DON, you will also get the IP address of the intruder in the file. This has to be fixed soon!

 

Unfortunately it would not be easy to go through your backups since the problem is NOT that ISY lost a link (which would be a little easier to find) but that you are suggesting ISY did NOT remove a link. The same link that got perpetuated ...

 

With kind regards,

Michel

[apostolakisl]

Michel,

 

First thing. This is what the error read.

Sat 3/24/2012 3:42:36 "PM System -170001 [Auth]" 66.96.210.17:51237->80, Num=3

Is this someone trying to hack in or something else?

I'm not getting those errors anymore so if it is a hack, they either succeeded and now have access or they quit trying.

 

Secondly, I was thinking of restoring the backup from just before I swapped out the switches and checking the links. Then restoring to just after I swapped out the switches and checking the links. I would expect that the links should be identical. I assume that a difference in those two sets of links would indicate that the swapping out process put them there erroneously. Yes? Is it worth my time to do that?

[Michel Kohanim]

Hello apostolakisl,

 

Michel,

 

First thing. This is what the error read.

Sat 3/24/2012 3:42:36 "PM System -170001 [Auth]" 66.96.210.17:51237->80, Num=3

Is this someone trying to hack in or something else?

I'm not getting those errors anymore so if it is a hack, they either succeeded and now have access or they quit trying.

First problem is that you have port forwarding to port 80. Please disable as soon as possible because all your traffic is going on the Internet in clear text. Please use only the HTTPS port, and now that we have seen this, I strongly suggest:

1. Change your https port to something other than 443

2. It would be safe to change your ELK access codes

 

 

Secondly, I was thinking of restoring the backup from just before I swapped out the switches and checking the links. Then restoring to just after I swapped out the switches and checking the links. I would expect that the links should be identical. I assume that a difference in those two sets of links would indicate that the swapping out process put them there erroneously. Yes? Is it worth my time to do that?

I really do not think it's worth the time. The only situation where you would have extra links is if there was a file error and since we do not have your error logs, all we are going to verify is that there are extra links (which we know there are).

[apostolakisl]

Hello apostolakisl,

 

Michel,

 

First thing. This is what the error read.

Sat 3/24/2012 3:42:36 "PM System -170001 [Auth]" 66.96.210.17:51237->80, Num=3

Is this someone trying to hack in or something else?

I'm not getting those errors anymore so if it is a hack, they either succeeded and now have access or they quit trying.

First problem is that you have port forwarding to port 80. Please disable as soon as possible because all your traffic is going on the Internet in clear text. Please use only the HTTPS port, and now that we have seen this, I strongly suggest:

1. Change your https port to something other than 443

2. It would be safe to change your ELK access codes

 

 

Secondly, I was thinking of restoring the backup from just before I swapped out the switches and checking the links. Then restoring to just after I swapped out the switches and checking the links. I would expect that the links should be identical. I assume that a difference in those two sets of links would indicate that the swapping out process put them there erroneously. Yes? Is it worth my time to do that?

I really do not think it's worth the time. The only situation where you would have extra links is if there was a file error and since we do not have your error logs, all we are going to verify is that there are extra links (which we know there are).

 

There was an application that I used to use that resided on the ISY that needed port 80. I haven't used it in years and forgot about it. I will disable.

 

Are you looking for errors at a specific point in time? If a restore a backup from just after that time, then the error log would also restore to that time, yes?

[Michel Kohanim]

Hi apostolakisl,

 

I am looking for file errors which could explain that the links were removed from the device but not from ISY. Unfortunately none of the logs are backed up nor restored. Only configuration information.

 

With kind regards,

Michel

[apostolakisl]

Hi apostolakisl,

 

I am looking for file errors which could explain that the links were removed from the device but not from ISY. Unfortunately none of the logs are backed up nor restored. Only configuration information.

 

With kind regards,

Michel

 

 

I don't think I explained those screen shots properly.

 

Those screen shots are with the old 99i links table being compared to the newly configured device I created with my new 994i. Here is the flow of what happened.

 

1) Before anything (device not working properly), the 994i links and device links were compared and were identical.

2) Device was deleted from 994i and rebuilt from scratch with the same exact scene setup.

3) Problem is now fixed

4) Now I wanted to know why the device didn't work before.

5) I knew the device links and ISY links were identical a few weeks ago before I took the 99i offline and replaced it with the 994i. One of the links that used to be on the device must have been the problem. So, I wanted to compare the old (problematic links) to the new (and proper links) to see what used to be there compared to what is now there.

6) I took the 994i offline and put my old 99i back online.

7) Then I crosschecked the current device links table against the old 99i links table and that is what you see above.

 

The extra links in the ISY links table above (4 of them) would presumably be not necessary (same device/same scenes as before) and at least one of them must have caused the improper behavior. Probably the one highlighted since it contains a reference to the other device that it should not have been linked to at all.

 

Lou

[Michel Kohanim]

Hello apostolakisl,

 

Thank you for the detailed explanation. At this point, I only have two hypotheses:

1. File system problem prevented ISY from updating the table ... for this I need the error log which you don't have

2. I went back through our release cycles and we did indeed modify database handling (pin/cache/flush) routines with the fix being in 3.1.15 and above ... so, if any of these operations were done before 3.1.15, then that could be one other remote explanation

 

There's another report of extra link here:

viewtopic.php?f=27&t=8657

 

I wonder what's common between the two cases. This would help us figure out where to look for solution.

 

With kind regards,

Michel

[apostolakisl]

OK, well let me know if you decide you do want anything. I do have the unused 99i so I can restore old backups (and I have a lot because I run backups with every firmware update and I update the firmware nearly every time one comes out).

 

I don't know if the error log gets backed up and restored or not, but if it does, that would be there also.

[Michel Kohanim]

Hi apostolakisl,

 

The most important question would be if you know whether or not the firmware that caused the problem was 3.1.14 and below. Based on the date, I think it was 3.1.11 but can't be sure.

 

Error logs do not get backed up.

 

With kind regards,

Michel

[LeeG]

apostolakisl

 

Memory test. When a device was deleted by the Replace With function, and the deleted device was added back to the ISY were there occasions when "keep existing links" was used to avoid having to add the device back to a Scene?

[apostolakisl]

apostolakisl

 

Memory test. When a device was deleted by the Replace With function, and the deleted device was added back to the ISY were there occasions when "keep existing links" was used to avoid having to add the device back to a Scene?

 

99% sure I did factory resets prior to bringing them back into ISY. 100% sure that I did NOT use "keep existing links". I have never used that function ever.