Jump to content


Photo
- - - - -

Ethernet trouble/restore after recent firmware updates.


  • Please log in to reply
8 replies to this topic

#1 CORT

CORT

    Dedicated Cocooner

  • Registered
  • PipPipPip
  • 285 posts
  • Location:USA

Posted 31 March 2021 - 08:43 PM

With a recent round of firmware updates, my house's M1 system has gone a bit haywire.  My system now logs extremely frequent ethernet trouble/restore messages.  As soon as I arm the system, the cycle of ethernet trouble/restore goes away.  When I disarm the system the cycle of ethernet trouble/restore returns within 35 minutes.  It seems like there is something wrong with the communication between the M1 and the XEP when the system is disarmed.  I replaced the RS-232 cable and even tried a different M1 panel and a different XEP using my same config with no improvement.  I noticed the ethernet troubles after updating the firmware on my M1 and M1XEP (the M1 was updated to 5.3.10 and the XEP to 2.0.46).  To the best of my knowledge, this problem did not exist prior to the firmware updates.  I would like to keep the updated firmware if possible.

 

Has anyone else encountered this problem?

 

Regards.

 

 



#2 RAL

RAL

    Cocoonut

  • Registered
  • PipPipPipPip
  • 2339 posts
  • Location:New York State
  • Experience:average
  • Hardware:Elk M1
  • Tech:X10-PLC
  • Phone:POTS

Posted 31 March 2021 - 10:28 PM

There are a couple of old threads on Cocoontech about M1XEP trouble/restore problems.  But not quite like yours where armed state makes it go away.

 

http://cocoontech.co...hernet-restore/

http://cocoontech.co...itoring-errors/

 

Are you using the XEP for central station monitoring?

 

It's a bit strange that the problem persists with a different M1 and XEP.  That makes me think it could be a network problem that prevents the XEP from receiving a response from the CS.   But why that would be different depending on armed/disarmed state leaves me puzzled. 



#3 CORT

CORT

    Dedicated Cocooner

  • Registered
  • PipPipPip
  • 285 posts
  • Location:USA

Posted 01 April 2021 - 04:51 AM

There are a couple of old threads on Cocoontech about M1XEP trouble/restore problems.  But not quite like yours where armed state makes it go away.

 

http://cocoontech.co...hernet-restore/

http://cocoontech.co...itoring-errors/

 

Are you using the XEP for central station monitoring?

 

It's a bit strange that the problem persists with a different M1 and XEP.  That makes me think it could be a network problem that prevents the XEP from receiving a response from the CS.   But why that would be different depending on armed/disarmed state leaves me puzzled. 

Thank you. for the reply.  At the moment, I do not have CS monitoring.  I do not have a phone number in the field for monitoring either.  The XEP is enrolled (which is why the system is logging and alerting ethernet trouble/restore).  I have looked at this board and Elk's support forum extensively trying to figure out my system's problem.  I have tried powering the XEP from a different 12 volt wall wart PS.  I think I have even stumped BW at Elk.  My system is a bit unique in that the house's basement is defined as a separate "area" from the main house--the basement is left armed when vacant.  I am beginning to wonder if this is part of the problem--perhaps the updated firmware handles reporting to the XEP different from the old firmware causing a miscommunication across the RS-232 serial bus.   Tracing the RS232 bus with Elk's M1XEP utility shows a tremendous amount of "chatter" (zone reporting and handshaking, I guess) on the RS-232 serial bus that mostly goes away when the system is armed.  I don't know if it is the arming that makes the reports go away or if it is the lack of activity in the house that comes with arming.  I will leave the system unarmed one night and see what happens.



#4 RAL

RAL

    Cocoonut

  • Registered
  • PipPipPipPip
  • 2339 posts
  • Location:New York State
  • Experience:average
  • Hardware:Elk M1
  • Tech:X10-PLC
  • Phone:POTS

Posted 01 April 2021 - 12:19 PM

My understanding is that the trouble/restore events happen when the XEP fails to get a response to a ping to the CS.  If you aren't set up wfor CS monitoring, I'm not sure what the XEP would be trying to ping.

 

Is the M1 configured to communicate with any home automation system via ethernet?  Not sure why there would be RS232 traffic showing zone reporting otherwise.



#5 sionxct

sionxct

    Cocooner

  • Registered
  • PipPip
  • 72 posts

Posted 18 April 2021 - 02:23 PM

No CS monitoring here for years and no previous XEP comm trouble, except...
 
.. I recently added some new rules that caused my Elk to restart. I would lose comm with the XEP whenever a particular rule activated. Disabling the rule resolved the issue. The subject rule is just a simple counter update.
 
I too have two "independent" areas defined. I've already reached-out to Elk about the problem, but I wonder if out issues are related.

That said, my issue started after the rule update. I was running the previous XEP firmware. I updated the XEP firmware as a result, but it did not resolve the issue.

Edited by sionxct, 18 April 2021 - 02:28 PM.


#6 RAL

RAL

    Cocoonut

  • Registered
  • PipPipPipPip
  • 2339 posts
  • Location:New York State
  • Experience:average
  • Hardware:Elk M1
  • Tech:X10-PLC
  • Phone:POTS

Posted 18 April 2021 - 09:13 PM

No CS monitoring here for years and no previous XEP comm trouble, except...
 
.. I recently added some new rules that caused my Elk to restart. I would lose comm with the XEP whenever a particular rule activated. Disabling the rule resolved the issue. The subject rule is just a simple counter update.
 
I too have two "independent" areas defined. I've already reached-out to Elk about the problem, but I wonder if out issues are related.

That said, my issue started after the rule update. I was running the previous XEP firmware. I updated the XEP firmware as a result, but it did not resolve the issue.


Does the M1 reboot every time the rule is activated?   If so, that makes me think that somehow you've created an endless loop in the rules where your last-added rule interacts with some other rule.  Processing of the rules never ends, and eventually the watchdog timer times out and causes a reboot.



#7 sionxct

sionxct

    Cocooner

  • Registered
  • PipPip
  • 72 posts

Posted 19 April 2021 - 11:37 AM

It appears to reboot every time, and its immediate by human perception. Thank you for the suggestion. I'll have to study my logic again or maybe refactor it, but I don't think its an infinite loop. I'm not back on site for awhile, so my troubleshooting abilities are limited and since the panel is working now I'm kinda' afraid to mess with it too much until I can get back on site anyway.

 

I don't want to hijack this thread, but I have another issue that started at the same time: whenever I connect ElkRP to the Panel it complains of rule and text conflicts even though nothing changed. I think these issues on my panel are related, I just don't know that its related to the OP's issue. Maybe I need to start another thread.



#8 CORT

CORT

    Dedicated Cocooner

  • Registered
  • PipPipPip
  • 285 posts
  • Location:USA

Posted 09 May 2021 - 05:23 AM

I am the original poster of this thread and want to leave a bit of an update in case someone else is having similar troubles. I haven't figured out my M1 system's problem, but I have learned how to work around some of the issues. At the moment, my observations are not certain so take what I say with a grain of salt. I mis-identified the circumstances blaming firmware updates. Instead I think that adding a zone or two performed around the same time as the firmware updates was the tipping point. Years ago, I configured the system with two areas--one area for the main house and another area for the unfinished walk-out basement. The unfinished walk-out basement is left armed most of the time and only disarmed when needed.


Here is what is going on: When both areas are disarmed, my M1 reports ethernet trouble and ethernet restore with extreme frequency. When the basement area (common to the main house) is armed, the cycle of ethernet trouble/restore goes away. Also if the basement is disarmed, I have trouble connecting to the M1 with the XEP.  This problem too goes away when the basement is armed. What I have discovered is that my M1 constantly reports all zones status across the RS232 serial bus when the basement is disarmed. When the basement area is armed, the chatter across the RS232 bus drops to only real zone change. In other words, common area disarmed results in a constant cycle of full zone reporting and common armed results in only zone status change. I don't know why it does this. Sniffing the RS232 bus, I can see the handshake between the M1 and XEP when the common area is armed, but I cannot see the handshake when the common area is disarmed. I believe there is too much data going across the RS232 serial bus with the constant cycle of full zone reporting, and it disrupts the Q2 min requirement of handshaking between the M1 and XEP. My suspicion is that a large number of zones in the system being constantly and fully reported across the RS232 serial bus takes too much time interfering with the handshake. As of this writing, I have just turned off the error beeping and learned to live with the issues. My guess is that the troubles would go away if I set the globals to not report this much data across the RS232 serial bus. I have more troubleshooting to do with the system, so there will be more to the story.


Edited by CORT, 09 May 2021 - 05:36 AM.


#9 RAL

RAL

    Cocoonut

  • Registered
  • PipPipPipPip
  • 2339 posts
  • Location:New York State
  • Experience:average
  • Hardware:Elk M1
  • Tech:X10-PLC
  • Phone:POTS

Posted 09 May 2021 - 11:44 PM

It sounds like you've done some good detective work on figuring out what's going on.  Your theory on why that causes timeouts is reasonable. It's strange how having an area armed or disarmed changes the behavior.

 

One thing I'm puzzled about is that the Elk description for the global settings to send RS232 data seem like the M1 should only be sending status updates when there is a change in zone status.  Yet, from what you see, it appears to be sending data all the time.  Are you seeing requests from the XEP for data?  What data packet type is the M1 sending out to the XEP?

 

Have you tried contacting Elk to discuss this latest info with them?






0 user(s) are reading this topic

0 members, 0 guests, 0 anonymous users