ISY no longer accessible via network / lights on solid

[CPRail1]

Although this unit has been working without issue until now, my ISY994IR is no longer accessible via our network.

My observations/troubleshooting:

 

- Prior to this I gave the unit the static address 192.168.0.125 for unrelated reasons. Worked fine for months under this.

- The router also has the same IP reserved for the ISY's MAC to ensure my DHCP doesn't accidentially create a conflict

- I did replace the SD card a few months back with a larger one but all worked ok after that.

- I have not done any electrical nor ISY changes for a while.

- It is @ 4.0.5. I do have backups if needed.

 

- Accessing it explicitly at it's IP address times out.

- Using the ISY finder comes up empty handed.

- When the ISY boots, after a phase of flashing and loading with the memory LED showing activity as expected, the unit settles into a state with all blue LEDs on solid.

- Based on the troubleshooting advice about Rx being solid, I checked out the PLM and cable and as far as I can tell without swapping out the PLM all appears to be OK.

 

- Does Tx being on solid indicate anything useful ?

 

- The Ethernet activity light on both the ISY and it's network counterpart is active and flashing

- I've tried rebooting the ISY of course and in fact the whole router network just in case.

 

Any thoughts appreciated.

[Michel Kohanim]

Hi Peter,

 

If all LEDs are on, then there's a flash error. If only RX is on and them error is blinking, then the problem is that the SD Card is either loose or defective. If Error/Mem blink simultaneously, then the problem is network related (probably an IP conflict).

 

If you are still having problems please do not hesitate to submit a ticket (links below) and we'd be delighted to help.

 

With kind regards,

Michel

[CPRail1]

Hi Michael,

 

I was able to dig up a fully replacement PLM and - at least from my remote vantage point - swapping out the original meant things are better now as I can see the unit across the network. I have restored to this PLM and while I have not observed the result of programs working yet, everything else seems to be including writes and querys.

 

Thanks for the additional LED info and fingers crossed it was something squirrely with the PLM.

 

Although I really don't understand why a squirrely PLM causes me to loose by web/router admin access to the ISY ? Does it get caught in a loop and ignore the inbound web ping traffic ? Would have been nice to know the ISY was sane and be able to look at logs as it would have sent me to the PLM faster. Blind is inefficient...

 

Cheers, Peter

[Michel Kohanim]

Hi Peter,

 

The only reason why a defective PLM might cause issues with network is if you have programs that do a lot of things with INSTEON devices and thus put a lock on the communications task.

 

With kind regards,

Michel

[CPRail1]

May I ask the technical definition of a "lock" in this instance (I'm an EE and Computer Science guy)

 

It seems odd that the ISY would not continuing to monitor inbound requests on it's eithernet/web interface while communicating with the insteon PLM (dead or not) and through that the Insteon network. I can certainly understand things slowing down but i'm surpriced it would not at least serially multitask - monitoring the ethernet interface , then the insteon, then ethernet, etc given (as I understand it) the relatively slow speeds of the insteon network.

 

Anyway, I'd just like to understand so as to avoid it in future.

 

I have (guessing) 100 odd insteon devices in the Insteon network and most rely on self contained, ISY independant, scenes and while the daily "query" program would be intensive ( not enabled to run at start up) , these remaining few would seem pretty low impact.

 

Cheers, Peter

[Michel Kohanim]

Peter,

 

ISY does multi-tasking and does everything that's necessary to keep it functioning. HTTP tasks are not network related; they are application layer tasks that have to get a lock before they can do something to INSTEON. The same lock is needed for all other tasks that need to do something with INSTEON. If the PLM is defective, getting that lock gets pretty difficult because a) the queues get full and the reach a timeout.

 

With kind regards,

Michel

[CPRail1]

Hi Michael,

 

OK, so the communication path to the Insteon side via the PLM is held up with its related impact on the modules - makes perfect sense - however it doesn't (unless I'm missing something) explain why the ethernet networking side - which is doing nothing with Insteon but rather only communicating with a PC via said network - stops responding unless the ISY has stopped too.

 

I am trying to understand why what you say is a fully functioning and multitasking ISY stops communicating with the administration consol, thereby severely impacting any basic troubleshooting, because of delays or even complete stalling of an interaction on a completely different interface.

 

Having the ISY unable to even talk to the admin consol, much less deliver useful information to it, made troubleshooting more difficult. I would simply like to understand why so that next time something like this happens I know when to start looking at the PLM when symptoms of no response by the ISY logically points to its being the problem.

 

Thanks, Peter

[Michel Kohanim]

Peter,

 

I think you and I are on different realms and it would be rather difficult to speak the same language let alone help with troubleshooting.

 

Tasks are blocked = they will NOT respond till they get the lock. If all tasks are blocked, then nothing will respond till at least one gets the lock. If you have a dead PLM while many different things (including web and programs) are trying to control INSTEON things, then all HTTP task will be waiting for the lock and thus will not respond.

 

With kind regards,

Michel

[CPRail1]

Hi Michael,

 

Ok, thanks, cheers, Peter