Why does ISY99i sometimes lose ability to show device status

[SunSentry]

First of all, I've spend a lot of time on the board in the last few days to see postings and learn as much as I can to help Dad. Lots of nice information on here.

 

I did not see a posting about this situation. Sometimes we open the UI and see that NONE of our devices are showing their current state. Then at other times we open the UI and it mysteriously seems to reappear. I am not understading why that happens. I hope you can see the image I attach. We just noticed this after updating to firmware 3.3.4 and UI 3.3.4. It could have occurred on 3.2.6, yet we did not noticed. I'm looking around to see if I can undertand why this occurs and how to fix it.

Wondering if anyone has run across this situation.

[LeeG]

If it happens all the time the cause is generally AV such as Kaspersky or Avast blocking the push of data from the ISY to the Admin Console app. If it happens the first time up with the Admin Console and then works when the Admin Console is restarted it is some timing situation that happens very rarely on mine and has across years of images. If my PC has been doing other things were some of the memory has been rolled out the Java based Admin Console is a little slower starting the very first time up and sometimes has blank status as the connection between the Admin Console and ISY did not get connected in time.

 

Generally Exit the Admin Console and restart will bring it up with Status the next time. Sometimes I can go months and not see a blank Current State column. Other times after Norton has done a background virus scan and rolled out lots of memory pages during the scan I see it.

[SunSentry]

Thanks Lee for that information. I had not thought about AV issues, but we did consider it could be a firewall problem. Thus, I deactivated those services on the computer while testing. In our case, it does not seem to be the problem.

 

It almost never happens the first time up. Just this morning for example, we turned on the computer and ran the admin console and saw everything reporting status just fine. I closed the panel. Some two hours later I opened admin again to make a change to a scene, but there was the problem again. Closing and restarting the admin almost never solves the problem. If we wait long enough, the problem goes away. We are pretty sure we never saw this problem occur in ver 3.2.6. It was only afer upgrading to 3.3.4 that we noticed this issue. Sometimes we can open and close the admin panel several times during a day (while we are testing and changing thing), and never see the problem. This is why it is so unpredictable.

 

The interesting thing is that everything seems to work during this condition. If we turn a device on or off in the admin or run a scene, the devices seem to respond and all is well. Programs appear to run as expected. It's just that we can't see the state of any devices, so we don't know their status, ramp rate, etc. It sure is annoying and unpredictable. As of now it is doing this again, so we aren't going to change anything in the programs or scenes for fear of screwing up something. We just end up waiting until the gremlin goes away.

[LeeG]

What AV is being used? Is Kaspersky or Avast used?

[SunSentry]

What AV is being used? Is Kaspersky or Avast used?

 

At the moment on the computer where we see this issue, there is no AV installed and the only firewall is Windows firewall (which we disabled). That is why we are certain this is not an AV problem. That computer is mainly for controlling home functions and not connected to the internet unless we manually connect it.

 

It also wouldn't make sense to me that the problem would come and go at various times of the day if it were an AV issue. Also very little software is on it. I am thinking it is some sort of other issue communicating with the ISY. From my experience, an AV problem doesn't block communications. It's the firewall that usually does.

[LeeG]

There are other computers that have no issue connecting to the ISY and seeing device status?

 

If you do consider using Kaspersky or Avast in the future consult the forum for the solution to lack of status before using. They are common blocking sources to the ISY pushing data to the Admin Console.

 

It may be time to open a ticket with UDI tech support. Any post by Michel has a link at the end of the post for opening a support ticket.

[SunSentry]

Two other computers in the house have the same issue.

I am going to try and gather more information before bothering UD about it.

Much thanks for your suggestion. We'll keep that info in mind about the AV stuff

[ergodic]

I had this problem quite often with my 99i at some point after V3 firmware came out. Though mine behaved a bit differently -- restarting the admin console would eventually fix it, but I'd sometimes have to restart 3 or 4 times.

 

As in your case it was not an security software or firewall problem, and the ISY itself worked fine. As I understand it, it isn't a comm problem as such, but rather a problem related to subscribing the ISY. Michel can probably offer more insight into this.

 

The problem vanished as soon as I upgraded to a 994. I have not seen it happen since that. I did post on it in the firmware threads somewhere.

[Michel Kohanim]

Hello everyone,

 

My next question is what if you use https instead of http. Does it solve the problem?

 

With kind regards,

Michel

[gascop69]

I have the exact, same problem. I've been fighting through it for months, searching these forums thinking someone else has had to have had it. I'm using a 994I/IR Pro running 3.2.6. I was just experiencing it too, when I came here and found this thread but the problem cleared before I could disable my AV or try https. The one thing I've noticed is that when it happens, I also don't have the batch write icons....

[SunSentry]

Hello everyone,

 

My next question is what if you use https instead of http. Does it solve the problem?

 

With kind regards,

Michel

 

No, it makes no difference how I access the control panel, http, https, or local.

[Michel Kohanim]

Thanks SunSentry.

 

Do you have your ISY configured to communicate with ELK?

 

With kind regards,

Michel

[SunSentry]

Gee, I have to type this all over again, since the board didn't take my reply the first time.

 

No we don't use Elk. We only have Insteon devices and a couple X10 devices. The thing is that Dad reports everything working perfectly with no flaws during the first 6 months of using this device with firmware 3.2.6. After upgrading to 3.3.4, strange things like this are happening, so he wants me to move it back to 3.2.6.

 

When I mean strange things happening, example, a 3-way chandelier only comes on at about 15% brightness when the program fires the scene, yet the scene and chandelier is set to 40%. Another lamp doesn't come on at sunset like it used to. Wall button lights don't stay in sync with actual lamp when a program turns on the lamp (wall button stays off).

 

We have tried all sorts of things like restoring all the devices, making sure we set scenes with ISY (not at the device), comparing the program in devices to ISY, etc.

 

Dad is not dumb at this stuff. He was an electronic design engineer and software engineer for 30 years, so he understands electronics and software well. However, this device and interface seems to not be working well. The fact that it recently started during an upgrade seems too much of a coincidence. I don't think we will ever upgrade again once this is fixed. We will be experimenting more tomorrow.

[LeeG]

I can't tell you how many hundreds of times I hear the same thing. Insteon was working 100% correctly until the upgrade and now some things are not working. Most of the time when each individual symptom is diagnosed and corrected it has nothing to do with an upgrade. I'm not referring to 3.3.4 specifically, it applies to just about every release of every product (not just ISY) that I am involved with. Not to say that applies here but it is good to maintain an open mind and analyze each situation.

 

Note that if you do go back to 3.2.6 (which is not my suggestion) 3.3.x changes the ISY configuration information so it is necessary to restore the 3.2.6 backup taken before the upgrade once back on 3.2.6.

 

It sounds like some communications problems have crept into the Insteon mesh network over time. A common occurrence as new electronics, new appliances are installed over time.

 

For the device(s) that are turning On to a lower On Level that information (On Level and Ramp Rate) is maintained in the individual devices link records in the device itself making a change to the ISY firmware an unlikely candidate. Look at the link records in one of the devices link database (Show Device Link Table) for the specific ISY Scene if driven from a Program or the Responder record for the Controller device if the Scene is activated from another Controller. The information in the next to last two bytes contain the On Level and Ramp Rate for the Scene

 

A2 xx yy.yy.yy aa bb cc

 

xx is the ISY Scene number or Controller button number

yy.yy.yy is the address of the PLM or the Controller device

aa is the On Level

bb is the Ramp Rate

 

A device that is responding to a Scene at 15% must have an On Level value that represents 15% rather than the expected 40%. It could have a value that represents 40% and coming on at 15% which makes it a device problem where the load (Red wire) is connected. If the On Level in the device is set to 15% change the Scene Responder On Level to something different than the current slider position. When that update is complete move the slider to 40%. The ISY will not rewrite a value it thinks is already in the device.

 

The device not turning on at Sunset has more possible failure points. Did the Program trigger at Sunset which can be seen in the Programs | Summary tab Last Run Time. Also check the Sunset time at the top of the Admin Console display. With the change from DST Sunset might be wrong. If the Program triggered correctly run a Scene Test on the Scene. Scenes driven from Programs can be adversely affected by Insteon mesh network problems. If the Scene Test fails then there is a link record issue either in the PLM or the device itself. If Scene Test runs successfully (link records correct) and a device does not respond to a Set Scene On it is likely an Insteon mesh network issue.

 

The wall button not in sync with the Program turning on the Responder controlled from the wall button depends on how the device was turned On. If from an ISY Scene it could be either a link record issue or more likely an Insteon mesh network issue. Same analysis as before. Does a Scene Test show correct results. If no, look at the link records first and then a significant powerline issue second. Unless something happened to device or PLM link records Scene Test normally works and Set Scene activation is unreliable because of mesh network problems.

 

I'm happy to work with you on the Insteon symptoms. The lack of device status on Admin Console startup is something UDI will work. When firewall and AV have been eliminated I am out of my element.

[LeeG]

Example of link records with 15% versus 40% Responder On Levels

 

A2 45 19.70.06 26 1F 01

 

A2 – Responder link record

45 - ISY Scene number

19.70.06 – my PLM address

26 – 15% On Level

1F – 0.1 second Ramp Rate

 

A2 45 19.70.06 66 1F 01

 

Same Responder link record with 40% (66) On Level

 

EDIT: to determine the ISY Scene number (45 in my example) run Tools | Diagnostics | Event Viewer at Level 3. Using the Admin Console turn the ISY Scene On with the Scene On button. The event trace will look like the following with the red 45 in my example being the ISY Scene number

 

Tue 11/20/2012 01:58:38 PM : [iNST-TX-I1 ] 02 62 00 00 45 CF 11 00

Tue 11/20/2012 01:58:38 PM : [iNST-ACK ] 02 62 00.00.45 CF 11 00 06 LTONRR (00)

[SunSentry]

Wow, nice email Lee. Dad and I will be digesting this today. We understand and agree with practically everything you are saying, yet there are a couple areas where he would disagree. One example is that every device worked well for months without failure and started acting up literally the same day of the upgrade, so we are doubtful that the issue is due to changes creeping into our home system over time. We will reply within a couple of days about our findingf for the benefit of other users here. We are determined to fine solutions

 

We have lots of backups and yes we figured that if we went back to 3.2.6 as an experiment, that it would require retoring a backup of ISY made from that version. Thus, we have several snapshots to experiment with.

 

One thing for sure, this is a really great forum !!!

[LeeG]

I went back and read the posts again to see if there was something I missed. There was a problem some releases back with the file system that could have compromised some of the Insteon configuration data. It could go unnoticed until a device was restored. I noticed that at one point some of the devices were restored. This could have rolled incorrect data back to the device. The probability is low of this happening and it is not an issue with 3.3.4 itself as it is only restoring data it did not create.

 

Try not to get to general in actions taken to resolve any remaining problems. Anything that is found to be wrong can be posted for evaluation of that specific. I feel certain the Insteon related things can be corrected although if there are powerline issues they can be harder to identify and resolve.

 

Again, I am happy to work with any of the symptoms to help find solutions.

 

Happy Thanksgiving

[SunSentry]

Lee, GREAT INFO to know. You are really smart.

Dad loves to experiment with electronics and software. No doubt, he will resolve it with the information given here.

By the way, most of the devices in our house are dual-band light switches, so I would have hoped that power-line issues would not be a factor, yet understand it might still play a role in the issues.

 

Thanks for sharing this valuable information. I'm sure other people are looking at this and thinking how to solve their similar issues.

[gascop69]

Well I'm fortunate that I do not have any other Insteon communications issues with any device. My problem is simply being able to log onto the Admin Console and seeing device status, just like in SunSentry's original post. And like I said, everytime I have the problem, the batch write icons are also not present. Sometimes I need to reload the Admin Console several times before it restores. I've also tried clearing my browsing history and Java cache.

 

I've now also verified that disabling AV and the firewall has had no effect. I haven't been able to try https yet, but will happily post the results from that as I would love to find a solution to this.

 

Thanks to all who are helping to find a solution.

[Michel Kohanim]

Hello gascop69,

 

I must emphasize that simply turning off anti virus/firewall is not going to help. Your ISY's IP address MUST be included in the white list/exclusion list/trusted zone in your firewall.

 

HTTPS will certainly help a lot since most firewall software are more lenient with https.

 

With kind regards,

Michel

[SunSentry]

Well I'm fortunate that I do not have any other Insteon communications issues with any device. My problem is simply being able to log onto the Admin Console and seeing device status, just like in SunSentry's original post. And like I said, everytime I have the problem, the batch write icons are also not present. Sometimes I need to reload the Admin Console several times before it restores. I've also tried clearing my browsing history and Java cache.

 

I've now also verified that disabling AV and the firewall has had no effect. I haven't been able to try https yet, but will happily post the results from that as I would love to find a solution to this.

 

Thanks to all who are helping to find a solution.

 

Let me say quickly that Dad and I have solved all problems, but we will post information after a couple of days more testing. There are two issues in this thread... one if the irritating lost of the admin panel that you and i and other are experiencing, and the second issue is device communication failures after an upgrade. Until we verify the exact cause, please check your internet browser settings. We noticed that FireFox was not giving us any issues but MSIE was causing a problem. Dad made several changes in the MSIE browser settings and now the admin panel works EVERY TIME. I am not sure exactly what settings were made, but if we determine it, we will post it.

 

More info about device communications to follow in a couple days after we confirm the source of problem. Right now it appears to be due to ISY firmware changes.

[Michel Kohanim]

Hi SunSentry,

 

Please do let your dad know what we added new color schemes/themes in 3.3.5 (our next release) and would appreciate his feedback.

 

With kind regards,

Michel

[SunSentry]

Hi SunSentry,

 

Please do let your dad know what we added new color schemes/themes in 3.3.5 (our next release) and would appreciate his feedback.

 

With kind regards,

Michel

 

 

Oh gee, we will check that out today. He is going to be really excited to hear this. The timing is good because I go back off to college today. I appreciate it too because I'm the one doing all the gui changes for him.

[LeeG]

Release 3.3.5 is the next one available. It has not been released yet.

[SunSentry]

I just thought I'd take a few minutes to come back in here and mention what we have learned thus far. I can't really do anything more on this until my son gets back from college at Christmas since I need him to help with the interface.

 

For now, I went back to using firmware and UI version 3.2.6. For whatever reason, it works perfectly. In the last 5 days I have opened the UI multiple times (more than 10 times) each day and it never locked up. For whatever reason, everything works fine, UI, devices, etc. I'm just going to keep it at this level for awhile since I don't see any reason to go back to 3.3.4.

 

Since I changed some of the settings in my web browser (MSIE 9) at the same time as going back to 3.2.6, I don't really know if that had an effect on fixing the UI lockup issue or not, however, I think it is not related because we temporary upgrade the firmware back to rev 3.3.4 on Sunday for testing purpose, and the spooks returned.