M1G Rebooting

[Linwood]

I had version 5.3.0, and notice that 5.3.8 (despite notes above it reboots) did have some reboot fixes in it, so I decided to give it a try and install.    Then discovered I'd screwed up and installed Windows 10 and my ethernet wouldn't work (but was saved by their special updater).  
 
Anyway...
 
I was surprised after updating from 5.3.0 to 5.3.8 to find conflicts with things like zone names missing on the controller.  I resent from the database and at least all appears well.
 
I was having reboots maybe once a month, will report if this changes anything.  
 
Mike, in the above, I assume you meant V5.2 as your rollback?  Did you have any trouble rolling back, e.g. could you just send updates from the database afterwards, and/or did it preserve the settings when you flashed? 

 

[Linwood]

Ah, man, did I make a mess.  Installing 5.3.8 over 5.3.0 for some reason screwed up a lot of stuff.  I think what happened is somehow several devices, notably the auxiliary power supply and the RF (honeywell) adapter became not-enrolled.  This caused a pile of conflicts on first elkrp run, though I sent from database to controller.  ABout 15 minutes later I got an AC trouble from the power supply.  I resent the setting for the AC supply, and upon noticing the lack of devices I re-enrolled them.  That cleared the AC trouble but then the RF adapter started sending fire trouble.  I re-learned it to clear it, found my fobs wouldn't work either, and had to relearn them. The single zone I had on RF I just had to trigger to make it reset (i.e. open and close). 
 
I really don't understand what happened.  I say the fobs didn't work, but only had one handy, the other two are out with people, so am going to check those when they get back.
 
Oh, and little stuff -- the chime was off, somehow it went to voice.
 
But flashing the M1G software certainly didn't go as smoothly as I expected.  Now that I (think I) have it all re-enrolled and restored from the database correctly, I think things are working.  Will see if it reboots.   But just as an FYI be sure your database is updated before you flash so you can re-update if needed.
 
Maybe (speculation) this was some kind of timing issue?   Maybe I hit it with ElkRP too quickly before everything registered on the bus?     

 

[mikefamig]

I had version 5.3.0, and notice that 5.3.8 (despite notes above it reboots) did have some reboot fixes in it, so I decided to give it a try and install.    Then discovered I'd screwed up and installed Windows 10 and my ethernet wouldn't work (but was saved by their special updater).  
 
Anyway...
 
I was surprised after updating from 5.3.0 to 5.3.8 to find conflicts with things like zone names missing on the controller.  I resent from the database and at least all appears well.
 
I was having reboots maybe once a month, will report if this changes anything.  
 
Mike, in the above, I assume you meant V5.2 as your rollback?  Did you have any trouble rolling back, e.g. could you just send updates from the database afterwards, and/or did it preserve the settings when you flashed? 

Yes I meant to say v5.2 and corrected the typo.
 
I don't recall having any trouble rolling back but I also don't remember the exact procedure. I keep my customer account backed up so I may have restored the settings after the change. I think that I may have had to re-enroll the data bus devices.
 
This is from the firmware upgrade doc:
 
Warning: Some firmware updates make the control default its EEPROM memory. This will ERASE all customer programming, CANCEL all bypasses, CLEAR enrolled data bus devices, and TURN OFF the chime mode. It is always recommended to use ElkRP to do a “Receive All” prior to updating and save a permanent copy. After the firmware has been updated it may be necessary to do the following:
A. Re-enroll all data bus devices. Perform a “Bus Module Enrollment”
B. Re-connect ElkRP and use the “Send All” command to restore the saved customer data.
C. Restore any necessary bypasses, re-arm if needed, and re-enable chime if desired.
D. Retest the entire system including the telephone and communication reporting.
 
Mike.

 

[mikefamig]

Ah, man, did I make a mess.  Installing 5.3.8 over 5.3.0 for some reason screwed up a lot of stuff.  I think what happened is somehow several devices, notably the auxiliary power supply and the RF (honeywell) adapter became not-enrolled.  This caused a pile of conflicts on first elkrp run, though I sent from database to controller.  ABout 15 minutes later I got an AC trouble from the power supply.  I resent the setting for the AC supply, and upon noticing the lack of devices I re-enrolled them.  That cleared the AC trouble but then the RF adapter started sending fire trouble.  I re-learned it to clear it, found my fobs wouldn't work either, and had to relearn them. The single zone I had on RF I just had to trigger to make it reset (i.e. open and close). 
 
I really don't understand what happened.  I say the fobs didn't work, but only had one handy, the other two are out with people, so am going to check those when they get back.
 
Oh, and little stuff -- the chime was off, somehow it went to voice.
 
But flashing the M1G software certainly didn't go as smoothly as I expected.  Now that I (think I) have it all re-enrolled and restored from the database correctly, I think things are working.  Will see if it reboots.   But just as an FYI be sure your database is updated before you flash so you can re-update if needed.
 
Maybe (speculation) this was some kind of timing issue?   Maybe I hit it with ElkRP too quickly before everything registered on the bus?     

Did you back up your customer account? If yes then you should re-enroll the data bus and restore from that saved account by opening the account, signing into the elk and sending all.
 
Quote from installation procedure:
 
Warning: Some firmware updates make the control default its EEPROM memory. This will ERASE all customer programming, CANCEL all bypasses, CLEAR enrolled data bus devices, and TURN OFF the chime mode. It is always recommended to use ElkRP to do a “Receive All” prior to updating and save a permanent copy. After the firmware has been updated it may be necessary to do the following:
A. Re-enroll all data bus devices. Perform a “Bus Module Enrollment”
B. Re-connect ElkRP and use the “Send All” command to restore the saved customer data.
C. Restore any necessary bypasses, re-arm if needed, and re-enable chime if desired.
D. Retest the entire system including the telephone and communication reporting.

 

[Linwood]

I had not seen that, but I did have a backup of course.
 
What surprised me was the need to re-learn the RF devices.  Even after the RF adapter was re-enrolled and all database items sent down (and indeed checked and it showed the enrolled ID's), they would not work correctly, specifically the fob.  Just nothing when I pushed the button, and fire continually showed trouble.
 
I might believe the fire trouble was lack of recent transmit, but can't see any reason for the fob to not work, as those aren't supervised.
 
But... the (only) one RF contact I had worked by just opening and closing, as though it had forgotten its last state, which is not a surprise.
 
I'll know more when I get the other two fobs and see how they react, they are not on site at present.

 

[cowger]

I posted last month about having this same issue (random reboots) and around that time upgraded to 5.3.8.  At that same time, I upgraded my keypads and Ethernet expander all to the latest.  Since then, I haven't had a reboot.  (I added a rule to have it e-mail when it reboots, which works.)
 
I'm not going to declare victory, as that would certainly jinx me, but I am optimistic that the FW upgrade is a good thing.
 
BTW, as people know, the latest M1XEP firmware allows e-mail to finally work as expected.... nice!  : )
 

 

[mikefamig]

Thanks for the update. I rolled back to 5.2 months ago to get rid of the reboot problem and that worked for me but maybe I will try the latest 5.3 one day when I have some time to kill and feel that I haven't had enough pain that day.
 
Mike.

 

[Linwood]

Just a followup - since I installed 5.3.8 some months ago I have not had any further reboots.