lstorm2003
New Member
(scroll down to my "START HERE" note if you don't want to read the preface)
PREFACE:
I'm posting this message in the hopes that I can save someone else the headache I just went through for 2 hours...
So I'm sure many of you are using the M1XEP to get ethernet connectivity to your M1G.
Well I have long been disappointed in this unit, I actually find it to be pretty badly designed. WIth all due respect to the engineers who designed it and wrote the software, I do not believe they are really software engineers. I work for a software company and this XEP would never get through the way it is now...
It really needs to have some better logging and error reporting / handling capabilities.
I've always had trouble using the email feature on the M1XEP, but today I ran into one that had me banging my head against the wall for hours..
I got a new camera & DVR system, so after getting that all online of coarse the first thing I wanted to do was connect it to my Elk alarm system (I made it Zone 13) so if someone tampers with a camera the alarm goes off...
That all worked fine, although the DVR alarm output is "Normally Opened" instead of "Normally Closed" like all my other zones.. Don't understand why they did this.... But anyway.. getting to the point...
I wanted to get an email message sent to me anytime that zone 13 is tripped (my DVR/camera system).
START HERE IF YOU HAVE LIMITED TIME:
So I made a new email message, created the rule, etc etc...
Started testing and it all worked fine, until suddenly it just stopped working... (The email was not being sent)
Then I tried rebooting the XEP. No luck.
Pulling the power, no luck. Rebooting M1, no luck.
Tried everything I could think of, went crazy for 2 hours... Even changed my email password (I'm using GMX as my email provider).
Nothing worked... So I tried the "TEST" feature in the M1XEP Setup/Email Tab.
Anytime I Clicked it the XEP would disconnect. Strange. Did some research and found out that when the XEP sees something it doesn't know how to cope with, it will reboot.
So I logged into my GMX email account with my laptop (outlook) and configured the settings exactly how they are in my XEP, then tried to send an email and voila, I get this error:
The server responded: 450 4.3.2
I looked up this error message (which apparently is specific to the GMX mail service) and it means:
Too many mails (mass delivery by gmx user), try again in 47 minute(s)
Soooooo.... I must have caused this problem myself while I was doing testing and having the M1XEP send out multiple emails at once... The test that caused the problem was:
Arm Alarm - 1 email sent for this "System Armed"
Unplug DVR - 1 email sent for this "DVR Signal Loss"
Alarm tripped - 1 email sent for this "ALARM ALARM ALARM!"
Plug in DVR - 1 email sent for this "DVR Signal Restored"
Disarm Alarm - 1 email sent for this "ALARM DISARMED"
So sending out those emails so fast pissed off the GMX server so it would reject my XEP with error 450 4.3.2 which the XEP didn't know how to respond to, so it just kept rebooting.
If anyone else is having XEP problems with email I suggest you duplicate your settings between outlook and your XEP then try some tests with outlook. If it fails in outlook that should give you the error code, or return code so you can trouble shoot....
To the developers at Elk of the XEP:
Why is it so dumb? And if it does have to be dumb, then why is there no LOG?!?!?!??! There should be a log file that tells me the return code from the SMTP server. And if I can look in a log and see the REASON the XEP is having a problem I think a lot of people would not have to go through so many headaches with getting their XEPs configured.
Please please please ELK add a feature that lets me see what is actually happening (either in real time or via a log file) on the XEP so we can troubleshoot.
Right now the way that thing is its like trying to troubleshoot a problem totally BLIND and it sucks!
As I mentioned I work for a software company and all of our software has detailed log files available if enabled... usually an ini setting for LOGLEVEL, where LOGLEVEL=1 is minimal logging and LOGLEVEL=5 is maximum logging....
PREFACE:
I'm posting this message in the hopes that I can save someone else the headache I just went through for 2 hours...
So I'm sure many of you are using the M1XEP to get ethernet connectivity to your M1G.
Well I have long been disappointed in this unit, I actually find it to be pretty badly designed. WIth all due respect to the engineers who designed it and wrote the software, I do not believe they are really software engineers. I work for a software company and this XEP would never get through the way it is now...
It really needs to have some better logging and error reporting / handling capabilities.
I've always had trouble using the email feature on the M1XEP, but today I ran into one that had me banging my head against the wall for hours..
I got a new camera & DVR system, so after getting that all online of coarse the first thing I wanted to do was connect it to my Elk alarm system (I made it Zone 13) so if someone tampers with a camera the alarm goes off...
That all worked fine, although the DVR alarm output is "Normally Opened" instead of "Normally Closed" like all my other zones.. Don't understand why they did this.... But anyway.. getting to the point...
I wanted to get an email message sent to me anytime that zone 13 is tripped (my DVR/camera system).
START HERE IF YOU HAVE LIMITED TIME:
So I made a new email message, created the rule, etc etc...
Started testing and it all worked fine, until suddenly it just stopped working... (The email was not being sent)
Then I tried rebooting the XEP. No luck.
Pulling the power, no luck. Rebooting M1, no luck.
Tried everything I could think of, went crazy for 2 hours... Even changed my email password (I'm using GMX as my email provider).
Nothing worked... So I tried the "TEST" feature in the M1XEP Setup/Email Tab.
Anytime I Clicked it the XEP would disconnect. Strange. Did some research and found out that when the XEP sees something it doesn't know how to cope with, it will reboot.
So I logged into my GMX email account with my laptop (outlook) and configured the settings exactly how they are in my XEP, then tried to send an email and voila, I get this error:
The server responded: 450 4.3.2
I looked up this error message (which apparently is specific to the GMX mail service) and it means:
Too many mails (mass delivery by gmx user), try again in 47 minute(s)
Soooooo.... I must have caused this problem myself while I was doing testing and having the M1XEP send out multiple emails at once... The test that caused the problem was:
Arm Alarm - 1 email sent for this "System Armed"
Unplug DVR - 1 email sent for this "DVR Signal Loss"
Alarm tripped - 1 email sent for this "ALARM ALARM ALARM!"
Plug in DVR - 1 email sent for this "DVR Signal Restored"
Disarm Alarm - 1 email sent for this "ALARM DISARMED"
So sending out those emails so fast pissed off the GMX server so it would reject my XEP with error 450 4.3.2 which the XEP didn't know how to respond to, so it just kept rebooting.
If anyone else is having XEP problems with email I suggest you duplicate your settings between outlook and your XEP then try some tests with outlook. If it fails in outlook that should give you the error code, or return code so you can trouble shoot....
To the developers at Elk of the XEP:
Why is it so dumb? And if it does have to be dumb, then why is there no LOG?!?!?!??! There should be a log file that tells me the return code from the SMTP server. And if I can look in a log and see the REASON the XEP is having a problem I think a lot of people would not have to go through so many headaches with getting their XEPs configured.
Please please please ELK add a feature that lets me see what is actually happening (either in real time or via a log file) on the XEP so we can troubleshoot.
Right now the way that thing is its like trying to troubleshoot a problem totally BLIND and it sucks!
As I mentioned I work for a software company and all of our software has detailed log files available if enabled... usually an ini setting for LOGLEVEL, where LOGLEVEL=1 is minimal logging and LOGLEVEL=5 is maximum logging....
