M1G Rebooting

[Linwood]

A couple weeks ago I updated the firmware in the Elk M1G to the latest version.  I did it just to get on the UL version, not for any good reason.
 
Today I've had two (or three) reboots.  I can find no reasons - power has not been interrupted, nor any indications of power supervision problems.  The panel is otherwise working fine.  I have no particular reason to assume it is the new firmware except, well, it has never rebooted on its own in 2+ years.
 
The only other thing unusual is I recently had two smokes fail, and have reset their zones to disabled and removed the circuit board from them while waiting for replacement.  Nothing unusual happened when I did that, it was a week ago. 
 
Any thoughts about what I should look for?   All that appears in the log is a System Startup.  I notice because two lights are programmed to turn on when a door opens, and when it starts up it shows open long enough to turn those lights on.
 
That happened three times, but there are only two restarts, so not sure what that means.
 
Anyone else see a reboot?   Or maybe more precisely, anyone else running the new UL approved version and NOT having any problems? 
 
PS. Yes, I may just go back to the old version, but want to see if it keeps happening and is repeatable before I do.  But for absolutely no good reason I thought being on the UL version was a good thing.
 

 

[video321]

Hey Linwood-
 
Don't know if it's possible, but have you tried to re-install the firmware?
You may want to setup a computer to log all events via the M1XEP diagnostics software or just use hyperterminal.
 
Settings for hyperterminal:
Winsock (TCP/IP)
Port: 2101
Baud: 115200

 

[Linwood]

Hey Linwood-
 
Don't know if it's possible, but have you tried to re-install the firmware?
You may want to setup a computer to log all events via the M1XEP diagnostics software or just use hyperterminal.
 
Settings for hyperterminal:
Winsock (TCP/IP)
Port: 2101
Baud: 115200

 
Haven't.  And it hasn't rebooted again.  I did add a rule to get email when it does to make sure I don't miss it.  I don't want to start making changes unless the problem is repeatable.  The idea of monitoring is a very good one, had done that before, but had not considered it here.  Maybe there's something just before a reboot.  Thanks.

 

[Del91574]

Maybe your aux power is kicking out the PTC and causing a brief hiccup which is making the system reboot....are keypads rebooting?

 

[Linwood]

Maybe your aux power is kicking out the PTC and causing a brief hiccup which is making the system reboot....are keypads rebooting?

 
I don't know, is there an after-the-fact way to tell? 
 
But another day has gone by with no more reboots.  Three within a few hours, now all quiet.  And no events on any of the computers or other electronics in the house either.
 
Cosmic rays? 

 

[Linwood]

I'd like to re-awaken this thread.  I continue very sporadically to have reboots.  I thought they stopped entirely then realized that my email from the XEP had stopped entirely (long story unrelated to the XEP itself but with my linux server).
 
See I find out about these reboots by having it send email on a reboot.  Otherwise you might never notice - sometimes there's a beep or a lighting change, but mostly it just happens silently.  So yours may be rebooting as well!
 
To the question asked before by DELInstallations -- can you elaborate on any way to tell, after the fact, what happens?  
 
Here's what I know from the last one (about 15 minutes ago):
 
- If the keypads beeped it was briefly (I was not in the same room so they might have beeped once or twice but would have heard anything continuous). There are no keypad events in the log (I use Nav keypads) 
 
- The system log showed the reboot also, so it was not a spurious email, it just says 1367=System Start UP (control).  There is no prior log related.
 
- I use TCP monitoring to Alarm Relay as well as cellular - they did not see an interruption (they do log every time my internet hiccups so that means the outage was quite brief, probably under a minute)
 
- The system was idle, no events/controls active, in a disarmed state.
 
- No obvious power issues, my PC UPS did not detect anything, noticed no power flickers, no storms in the area.
 
I went back through the log and found prior reboots: 
 
5/10/15
4/27/15
3/22/15
10/20/14
10/14/14
9/6/2014
 
I did some rewriting sometime late last year so at least one of those was me actually powering it off -- but only one.  The other 5 times were not, and each one stands alone in the log with no other events adjacent to give a clue.
 
Not sure if the word "Control" under "Extended data" has meaning on the reboots.
 
I do not arm often, but wonder what happens if it reboots like this while armed -- does it disarm?   Alarm? 

 

[Del91574]

Control means the host panel.

 

[Linwood]

Control means the host panel.

Obvious in retrospect and now that I see a keyboard in one, thanks.
 
I just wish the log was capturing more useful info, some kind of reason-for-reboot, to point to power or software crash or ... 
 
I guess it's good it does it very seldomly, but that also makes it harder to do any kind of debugging.
 
So if anyone with an M1G is bored (especially if running the latest UL firmware), retrieve the whole log and scroll through (easy in Elkrp) and see if you have any reboots.  Maybe it's happening to you also and you don't notice, because the only time I actually did notice was when it interrupted a running lighting program timer.

 

[RAL]

I'll speculate a bit and say that when you see the panel reboot and there are no other errors in the log that it might be due to the watchdog timer.  The M1 contains a hardware timer that the firmware needs to reset periodically to indicate that things are working ok.  If something goes wrong, either due to a hardware error or a firmware bug and the panel gets hung up and is unable to run anymore, the watchdog timer causes a hardware reset and reboots the panel.   In that case, there would be no other errors in the log since the panel was in a state where it was unable to operate before the reboot.

 

[Linwood]

RAL, makes good sense, though can you speculate just a bit further on things to check relative to cause?   I assume (and main reason I resurrected this thread) that if others are not seeing it when they look, it is more likely hardware than software.  But then again, it could be specific hardware or settings combinations. 
 
My main concern from it is whether it is "smart" about the reboot if it was in an armed state.  I'd hate to leave it armed, have it reboot, and then do something a bit too conservative like go immediately into an alarm state.  While I can simulate this with turning it off and on, I'm not certain that a power cycle will prompt the same behavior as whatever kind of reboot this is.
 
Any insight on how that is likely to be handled? 
 
If it just wakes up in the same state as (approximately) when it failed, this is largely a non-issue given the infrequency with which it occurs.  But if it will send an armed state into alarm (for example) that would be bad.  Our trips out of town have been brief lately, but the longer the trip the more likely to hit this. 

 

[RAL]

I'm pretty sure that the M1 will come back up into the same state it was in after it reboots.  It stores the current state (armed, disarmed, etc) in nonvolatile memory and after the reboot will return to the stored state.
 
Tracking down the cause can be difficult.  It's possible that it is due to a firmware problem, but could also be caused by power problems, or even random hardware errors.  Even things like cosmic rays can cause errors in microprocessors and memory.   This sort of problem can be really hard to diagnose.

 

[Linwood]

Well, if you're right about the former I won't worry about the latter until it gets worse.

 

[TrojanHorse]

Hi, I know this is an older thread but also seems to be an issue for some, including me now.  My wife woke me up recently when the keypads beeped at 5am.  Found the 1367 system start up event in the log.  No other events at the time.    I know the following, hopefully this is helpful and informative:
 
*System was armed at the time, and upon reboot it remained armed.  No alarm condition or anything, just keypad beeping.
*The log goes back 2+ months, and this is the only time I've seen the 1367 restart by the control only, rather than also having keypad or wireless expander restart events (when I see all keypads and wireless expander have restarted I believe it's when I did manual hard restarts, installed firmware, etc.)
*I recently upgraded all firmware (running 5.3.8 on the control)
*Have a KP3 with hardware 1.6 rather than the other 2 with hardware 1.4.  This was causing "Lost Comm" issues before the recent firmware update for this keypad.
*I don't have a complex system in my view. No remote expanders on other buildings or anything. 
--*PS, thanks to those here that recently helped me on my last post about a secondary power supply. I still haven't gotten around to installing it..  I speculate this isn't the issue, but mention it to reduces the possible variables.
 
I know many have said that once the entire system is working, don't touch firmware.  Hopefully I can get this dialed in to that point sometime   
I have to again give a thanks to all the people more knowledgable than me who share their knowledge here. 

 

[cowger]

And I'll add my name to this list.  About every other day or so my alarm panel reboots, with the same, lone 1367 message in the log.
 
I just updated to 5.3.8 but, based on this thread, I'm not optimistic that this will fix anything...

 

[mikefamig]

Firmware version 5.3 is known to have the rpanel estart problem. Elk had me roll back to V5.2 and I haven't had a 1367 in many months.
 
Mike.