If someone could post the release notes, It would be great. Can't get to my Elk password today.
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..
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.
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?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.
Welp,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?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.
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
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.
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.