M1XEP Firmware

[gatchel]

Well...

I'd thought I'd post the its a very bad idea to roll back the firmware as part of the troubleshooting process.

IT BRICKS THE M1XEP. The only fix...Send it back.

It's very common with some of the other devices I work with to roll back the firmware as part of a troubleshooting process when all else has produced no results.

I had problems with verizon FIOS email. As part of the previous troubleshooting I updated from 1.3.10 to 1.3.20. Since them I have abandoned the verizon email to try gmx.com email as suggested. Nothing, I mean absolutely nothing would work as far as different settings, router reboots, DNS servers, email server IP, email server name, etc, etc...

I am so frustrated. I would think that RP2 would not let you roll back to an older version if it will destroy the XEP. GUESS NOT!!!!


It's hard to believe that there's no way to fix this, FTP, telnet, something. Tech support said NOPE!

 

[electron]

wow, sorry to hear about your trouble, thanks for the headsup! This topic has been pinned!

 

[mikejrc]

what if you disconnected your module prior to rolling back ?
or what if you rolled back the module firmware first then the control then update both?
it makes sense that sometimes both control and module have to operate with upgraded or downgraded firmwares.


its kind of like an iphone...you can downgrade the iphone os but you cant downgrade the baseband which is the internal iphone firmware that controls the hardware locking the phone sometimes useless.

so an elk module with a higher firmware wont work with a downgraded control firmware and it would lock it

 

[jschumann]

I see there is a new Firmware for the M1 Gold/EZ8 (4.6.8 or 5.2.10). I downloaded and installed with no issues. Release notes are posted on ELK website.

 

[treo650]

Bump.

Any new improvements that you
see?

Or anyone with a change log?

 

[jschumann]

July 9, 2012 - M1 Firmware 5.2.10 ** Not Evaluated by UL

ElkRP Software 2.0.14 or later is recommended with this firmware.

1. The firmware is required for utilization of ELK’s M1XRFTW "Two Way Wireless" products. NOTE: The first M1XRFTW must
be enrolled at data bus address 2 in order for the two-way and sensor auto-sync to work properly. Redundant M1XRFTW
receivers must be addressed as 3, 4, or 5. ElkRP version 2.0.14 or higher is required for enabling the two-way auto-sync.

2. Fixed a problem in the lighting section that occurred with an ISY controller. If a lighting rule was used to "Then Turn On for
xx min/sec" and the light was then manually turned off before that timer expired, the light would turn back at the end of the
timer due to the fact that the panel had mistakenly used the toggle function instead of the Off command.

3. Additional fixes were made to the daylight savings time section.

4. Fixed problem with 24 hr burg or box tamper zone being silenceable by the * key.

5. Fixed problem with with acces of submenus 13 and higher in the Installer Level Menu 08 programming.

6. Change - If the M1’s RS232 "Port O" is set at a baud rate lower than 9,600 then it will no longer broadcast state changes.

7. Fixed problem with the retriggering of box tamper zones.

8. Fixed problem with Thermostat Change of State Flags not being reset following a Rules or ASCII message activation.

9. Added time delay (similar to M1XIN) on the Output Expander (M1XOVR) code to make it more tolerant of an occassional
missed data bus response.

10. Fixed an issue with cancel report timer not getting set when the Ethernet reporting format was engaged.

11. Modified the Contact ID code to be 381 upon a loss of supervision on a Keyfob defined zone. It previously reported 150.

12. Fixed an issue with the ASCII "AS" command and common area repeat messages on the RS232 "Port O."

13. Fixed a problem with the Chime enable function from a rule.

14. Fixed a problem with the tamper on wireless glass break detectors.

15. Change - When enrolling wireless sensors there is now a mandatory 4 second wait between successive sensors.

16. Fixed a problem with Fire Restorals not not always being placed into the event log, especially after a 5 sec. Smoke Reset.

17. Added - Tamper switches on wireless sensors (GE and Honeywell format) can be disabled (ignored by M1) by setting the

Zone Type as "Type 1 - Normally Closed."

July 9, 2012 - SUNSET of support for Caddx firmware version (M1 Firmware 4.6.8)

Announcing the Sunset (end of updates) of support for the M1 firmware 4.x.x versions. The 4.x.x range of firmware supported
the Caddx Networx "NX" branded wireless receiver. 4.6.8 was the last and final version of this firmware. Customers wishing
to benefit from any new features and/or fixes are encouraged to replace their Caddx branded wireless receiver with an ELK-
M1XRFEG Wireless Receiver (GE compatible). Doing this will enable the M1 control to be updated to firmware version 5.x.x
which will continue to be supported with future firmware updates.

 

[crossbar]

Does anyone have a copy of the XEP firmware Version 1.3.24?  It is no longer available from the Elk web site.  The oldest is 1.3.26 in the 1.3.28 update.
 
If you performed a 1.3.26 update the 1.3.24 should be in your C:\ProgramData\RP\Updates directory.
 
I would like a copy of it for when I try to update to a newer version in case I need to roll it back (my current version is the 1.3.24).

 

[mikefamig]

Does anyone have a copy of the XEP firmware Version 1.3.24?  It is no longer available from the Elk web site.  The oldest is 1.3.26 in the 1.3.28 update.
 
If you performed a 1.3.26 update the 1.3.24 should be in your C:\ProgramData\RP\Updates directory.
 
I would like a copy of it for when I try to update to a newer version in case I need to roll it back (my current version is the 1.3.24).

Understand that you can't roll back the latest version

 

[Del91574]

Understand that you can't roll back the latest version

All in the release notes. One way process.

 

[crossbar]

The 2.x.x updates are the only ones that can't be undone.  1.3.26 and 1.3.28 should be able to be rolled back if needed.  I know the latest 2.x.x is supposed to fix the windows 10 issues but there are no other features of the ver 2 that I will need in the foreseeable future and if I need to try any of the 1.3.x updates I want to know I can come back to one that works for my current needs.

 

[Del91574]

The 2.x.x updates are the only ones that can't be undone.  1.3.26 and 1.3.28 should be able to be rolled back if needed.  I know the latest 2.x.x is supposed to fix the windows 10 issues but there are no other features of the ver 2 that I will need in the foreseeable future and if I need to try any of the 1.3.x updates I want to know I can come back to one that works for my current needs.

Not true. Has always been stated in the FW release notes for the XEP's, and I've been putting in M1's since there were M1 and M1G's and before the EZ8 came out. If you choose to gamble and attempt, that's your prerogative, but it has always been stated in the old documentation of the XEP's. I'd go with the guys that put it on the market as the experts.
 
XEP's are always a one way street. Bootware and firmware.

 

[apostolakisl]

From:  M1XEP TechNote
June 7, 2006
Updated April 2, 2007, October 15, 2007
 
 
IMPORTANT: Once the bootware has been updated to version 1.1.4, you cannot roll-back to an earlier version.  Earlier versions of application firmware will not operate with bootware 1.1.4.  ONLY version 1.2.2 and later versions of application firmware will operate on bootware 1.1.4.
 
It would appear that the bootware in this example is the part that cannot be rolled back and that the firmware is only compatible with certain bootwares.  Perhaps some firmwares can be rolled back to previous versions depending on the bootware/firmware compatibility.  But clearly there are restrictions with more than just the latest update.

 

[crossbar]

That is what I got from the 1.3.28 Release Notes as well.  Just the bootware can not be rolled back.  I am at 1.2.0 already.  The 1.3.28 firmware update includes the 1.3.26 file so that would be strange that ELK would include the old version to roll-back to if it can't be rolled back.
 
So far I don't have a compelling reason to upgrade from 1.3.24.  There is one ELK bug that breaks the ELKM1::Control module but I have adjusted the ElkM1::Control to accommodate it (and I think this is an ELK bug not an XEP bug).  At some point I will probably have to move up to V2 but I think I will wait it out as long as I can to give Elk more time to work out as many bugs as possible.