New Firmware for M1G and M1XEP on ELK website

[inline]

Just a FYI for everyone that new firmware has been posted. I plan on upgrading later today and will post results. From release notes, mostly looks like bug fixes and added support for honeywell wireless receiver.

 

[Monk]

If someone could post the release notes, It would be great. Can't get to my Elk password today.

 

[mustangcoupe]

If someone could post the release notes, It would be great. Can't get to my Elk password today.

It looks like the squeeking here at CT we get things done. #'s 10 and 16 I have seen mentioned here

Jan 18, 2010 - M1 new application firmware (4.5.24 and 5.1.24)
This new Firmware requires Bootware 3.3.2
* * ElkRP Software 1.6.16 or later is required for this new firmware * *
1. ASCII command - Changed “CD†to make it send the number of the command instead of a two character text identifier.
2. Found and resolved a problem with a 4-way EOL zone defined for periodic trip not being resettable.
3. Found and resolved a problem when a 4-way EOL zone was defined as interior follower.
4. Added a feature to “Ignore AC fail†whenever a battery test occurs. This allows an M1 to be operated from a DC ONLY
power supply. This is becoming more popular overseas due to strict energy efficient limits on AC transformers.
5. Modified 24hr panics to produce only a single beep on a trouble. The beep silences when trouble goes away.
6. When a listen-in zone alarm is reported the CID code 606 will be sent to indicate “listen-in†to the Central Station.
7. Added listen-in feature for Fire and Medical F-Key activations if/when listen-in is enabled.
8. Added capability to handle multiple Voice message phone numbers from a single rule.
9. ASCII command - Added ability to send a 0 or Null character in a text string by programming ^@.
10. CHIME - Eliminated the keypad audible tone produced when chime was enabled or disabled from a rule.
11. Made it possible to detect a missing temperature sensor by a rule checking for a value of zero (no sensor).
12. Added an internal adjustment for listen-in volume that will ONLY be available from a new version of Elk-RP, not from
keypad programming. NOTE: This also requires a new version of Elk-RP tentatively slated to be version 2.0.
13. Fixed a lighting command timing issue associated with the Universal Devices ISY controller.
14. Modifications can now be made to Wireless Zone Definitions. The following Zone Types are available:
Zone Type 0 “EOL Supervised/RF†- Alarm are caused if system is armed and either the sensor or tamper is violated.
Zone Type 1 “Normally Closed†- Tamper is DISABLED Only the sensor alarm function can cause an alarm when armed.
Zone Type 2 “Normally Open <not used>
Zone Type 3 or 4 “EOL Supervised Open/Short†- Same as Type 0 EXCEPT that tamper is also active while the system is
disarmed, and a tamper violation will cause a “Security Alert†notification, including an audible and visual at the keypad.
15. Added support for a new ELK-M1XRF2H Wireless Receiver. This new receiver will accept the Honeywell TM (Ademco TM)
5800 wireless transmitters. NOTE: This also requires a new version of Elk-RP tentatively slated to be version 2.0.
16. Due to requests from 3rd party developers Elk has modified the handling of an arm command (RS232 ASCII Protocol)
coming into the main serial port (or M1XEP).
A. If a zone is violated but NOT programmed to allow force arming then an ASCII command to arm will be denied. The
control will respond with an ASCII string of the current status clearly showing the control did not arm. In this situation the
only choice is to either manually hard bypass the zone or not arm at all.
B. If a zone is violated and programmed to allow force arming then an ASCII command to arm will be accepted and the
zone will be in soft bypassed. A soft bypassed zone can and will restore to active status if it restores to a non-violated
state while the system is force armed.
Be aware that you should NOT enable Force Arm unless you are willing to allow the system to be armed with zone(s) in a
violated state.
NOTE: Rule based arm commands, including the Autoarming feature and the Telephone Remote Control will arm the
system and automatically soft bypass (or force arm) any violated zones, regardless of whether those zones are
programmed for Force Arming or not. Elks point of view is that if a rule or Telephone remote arm command is triggered
then it is unlikely anyone is available to assess any problems and/or take any corrective action. Therefore, arming with
some zones is still better than no arming at all.
17. Added requirement that any wireless zone enrolled with a Keyfob MUST be program defined with the “Keyfob†definition.
18. Added a new program option for setting Phone Line Fault trouble delay. This delay cannot be programmed from the
keypad. It can only be programmed on the Globals page of the soon to be released NEW ElkRP2 software. The program
range is 1 to 31 minutes. The minimum setting of 1 minute is virtually the same as no delay.
19. Fixed a issue that often resulted in a false trouble and/or alarm whenever the definition of certain zone types was
changed via remote download.
20. ASCII command - Added “IC†command to be sent on a valid arm/disarm command.
21. Found and fixed an issue that could result in data bus lockout if the Installer anti-takeover was set to 3.
22. ASCII command - Added “zt†command. Sending this command with a zone number corresponding to a valid
programmed zone will cause that zone to be momentarily violated, just as if that zone had been physically violated.

TM Honeywell and Ademco are registered trademarks belonging to Honeywell Inc.

Jan 18, 2010 - ELK-IP232 Application Firmware (1.0.16)
Issues and Changes effective with this update.
Application Firmware:
1. Optimized for use with various brands of distributed audio controllers in conjunction with the M1 and M1XEP.
2. Found and corrected interpreter issue which could cause a message to be split into 2 or more sequential packets.
3.. Improved handling of “orphaned†socket connections by improper disconnects or resets of the remote IP device.
4. Improved data throughput.

Jan 18, 2010 - M1XEP New application firmware (1.3.10) and bootware (1.2.0)
Bootloader SHOULD FIRST be updated to version 1.2.0 before attempting to update application firmware.
1. Added communications support for specific brands and models of distributed audio controllers. The support
includes sending and receiving of “generic†audio commands “CD†of the M1 ASCII protocol.
Support currently includes Russound (RNET), Proficient (SpeakerCraft), and NUVO (Grand Concerto).
2. Added support for a “VN†command which returns the version of the M1XEP in addition to the M1 version.
3. Made improvements to the responsiveness and connection stability of the M1XEP..

In addition on teh main upgrade page it shows updates for teh following as of yesterday but the files in that download area are older ones...
so I do not know if they are real updates, or just addition of notes to the download web page.

• ELKRP version 2.0.4
• ELK-M1XRF2G Wireless Receiver - FIRMWARE UPDATE Ver. 1.0.26

 

[sic0048]

I know a lot of people have been waiting on #10.

10. CHIME - Eliminated the keypad audible tone produced when chime was enabled or disabled from a rule.

 

[mustangcoupe]

I have been waiting on #10 for a long time. now I will set chime off when I put my daughter to bed, and turn it back on after the alarm arms at night (via my HA software) where #16 will come into play once the driver is updated. I can now arm it remotely without a user code needing to be programmed in the the HA system

 

[signal15]

I installed it and everything is working. Interestingly enough, my wireless receiver and the XSP were already running the new firmware (purchased last year). Should I run the upgrade anyway on them?

The XEP didn't come back. I waited 30 mins or so. I could ping it, but it wasn't listening on 2101 or 2601. So I power cycled it and now it's working just fine.

The chime fix is great, since I use a door sensor on the baby's room to shut off the chime when his door is closed.

I wish there was volume control via rules, support for RFXCom, and a prettier or skinable web interface for the XEP.

 

[blmxm]

The XEP didn't come back. I waited 30 mins or so. I could ping it, but it wasn't listening on 2101 or 2601. So I power cycled it and now it's working just fine.

I had problems as well with the xep. At first no connection with anything. Then after a power cycle RP was happy, but dns test failed. Then I got a bunch of emails updating the dns from "unknown". However I still cannot connect with RMS. Either from the internal network, nor through dyndns. Anyone else having this problem?

 

[bphillips]

blmxm, the problem may be that after the XEP update the Unsecure Port became unchecked. There's a new note on the XEP release notes that talks about this. New memory locations were added to the XEP and the location that selects the unsecure port got cleared. ElkRM needs that to be checked. Connect with ElkRP and recheck that option on the XEP setup page.

 

[blmxm]

blmxm, the problem may be that after the XEP update the Unsecure Port became unchecked. There's a new note on the XEP release notes that talks about this. New memory locations were added to the XEP and the location that selects the unsecure port got cleared. ElkRM needs that to be checked. Connect with ElkRP and recheck that option on the XEP setup page.

Well I thought about that and after reconnecting I confirmed that was checked prior to sending all. Additionally I have unchecked and sent, then rechecked and sent. I suppose I can reflash and try again. Have you updated and gotten RMS to connect again?
I first updated the control, then the xep, just in case of a connection problem. My control did not default, nor did it appear the XEP did, but I resent all regardless. I have now confirmed it is sending emails out, and I can get in with pocket M1 which uses the secure port if I recall. Also the java applet works at the same IP address and it pings fine, so port 2101 sounds like the culprit, but as it is checked I'm not sure where to go from here. Maybe try a different port # ???
Thanks,
Mark

 

[blmxm]

blmxm, the problem may be that after the XEP update the Unsecure Port became unchecked. There's a new note on the XEP release notes that talks about this. New memory locations were added to the XEP and the location that selects the unsecure port got cleared. ElkRM needs that to be checked. Connect with ElkRP and recheck that option on the XEP setup page.

Well I thought about that and after reconnecting I confirmed that was checked prior to sending all. Additionally I have unchecked and sent, then rechecked and sent. I suppose I can reflash and try again. Have you updated and gotten RMS to connect again?
I first updated the control, then the xep, just in case of a connection problem. My control did not default, nor did it appear the XEP did, but I resent all regardless. I have now confirmed it is sending emails out, and I can get in with pocket M1 which uses the secure port if I recall. Also the java applet works at the same IP address and it pings fine, so port 2101 sounds like the culprit, but as it is checked I'm not sure where to go from here. Maybe try a different port # ???
Thanks,
Mark

Welp,
Brad had me change the RP port to 2101 on the main RP page and I couldn't connect. Switched back to 2601 and confirmed that unsecure port was checked on XEP setup page. Sent right from that page and wallah. So while I know I did both a send all, and sent from the XEP window itself having watched email updates roll across the screen, for what ever reason she is a happy camper again. This time I sent from the tcp/ip screen itself. I can't imagine that was the issue but... Anyway it's not broke so I am done. Thanks for the help as always!

 

[gatchel]

It's like christmas all over again.

 

[Smarty]

I too also had issues getting my XEP back online....but it now is....the extra hints helped.

However, my ability to send e-mails appears to be BROKEN. Anyone else seeing this? It was working fine right up to the point of upgrading bootware and firmware.

Ideas??? outgoing mail is smtp-server.satx.rr.com Nothing !! else was modified on the system.

 

[Monk]

I too also had issues getting my XEP back online....but it now is....the extra hints helped.

However, my ability to send e-mails appears to be BROKEN. Anyone else seeing this? It was working fine right up to the point of upgrading bootware and firmware.

Ideas??? outgoing mail is smtp-server.satx.rr.com Nothing !! else was modified on the system.

Me too for some issues -

Check ALL the settings - also, some might require that you hit SEND and reboot the M1XEP before they take effect.

 

[Smarty]

I too also had issues getting my XEP back online....but it now is....the extra hints helped.

However, my ability to send e-mails appears to be BROKEN. Anyone else seeing this? It was working fine right up to the point of upgrading bootware and firmware.

Ideas??? outgoing mail is smtp-server.satx.rr.com Nothing !! else was modified on the system.

Me too for some issues -

Check ALL the settings - also, some might require that you hit SEND and reboot the M1XEP before they take effect.

Thanks....I just needed to do a send and a reboot.

 

[Spanky]

As luck will have it, we found a minor issue in the Rule control of the Chime on the M1. Going from one of the chime modes to another with a Rule, it still annunciates instead of being silent. It will be fixed in the next release.